Bug 2290542

Summary: Unexpected behavior on array in FriBiDi
Product: [Fedora] Fedora Reporter: Akira TAGOH <tagoh>
Component: gccAssignee: Jakub Jelinek <jakub>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 40CC: dmalcolm, fweimer, jakub, jlaw, josmyers, jwakely, mcermak, mpolacek, msebor, nickc, nixuser, sipoyare
Target Milestone: ---Keywords: Regression
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2024-06-05 11:27:34 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 2279842    

Description Akira TAGOH 2024-06-05 09:59:24 UTC 
This originally reported as Bug#2279842 and I was investigating why it happened even though there was no code changes in upstream between 1.0.13 and 1.0.14. I found strange behavior on array then. It happens on https://github.com/fribidi/fribidi/blob/bca04dc3cd3af85a9d9220c430737333634d622a/lib/fribidi-mirroring.c#L46 and this macro is defined like:

#define FRIBIDI_GET_MIRRORING_DELTA(x) \
        ((x) >= 0x10000 ? 0 :  \
        MirLev1[((x) & 0x3f) + \
        MirLev0[((x) >> 6)]])

in the generated mirroring.tab.i at gen.tab directory.

Let's see how it looks like. This is correct behavior:

Breakpoint 1, fribidi_get_mirror_char (ch=11262, mirrored_ch=0x7fffffffdb94) at ../lib/fribidi-mirroring.c:44
47        result = FRIBIDI_GET_MIRRORING (ch);
(gdb) p MirLev0
$1 = {0, 64, 128, 192 <repeats 57 times>, 256, 192 <repeats 29 times>, 320, 192 <repeats 37 times>, 384, 448, 512, 
  192, 192, 192, 192, 192, 576, 640, 704, 768, 832, 192 <repeats 16 times>, 896, 192, 960, 192, 192, 192, 192, 192, 
  192, 1024, 1088, 1152, 1216, 1280, 1344, 192, 192, 192, 1408, 192, 192, 192, 192, 192, 192, 192, 192, 1472, 1536, 
  192, 192, 192, 192, 192, 192, 1600, 192 <repeats 824 times>, 1664, 192, 192, 1728, 1792, 192, 192}
(gdb) p ch >> 6
$2 = 175
(gdb) p $1[$2]
$3 = 1408

And this is not:

Breakpoint 1, fribidi_get_mirror_char (ch=11262, mirrored_ch=0x7fffffffdbb4) at ../lib/fribidi-mirroring.c:44
44      {
(gdb) p MirLev0
$1 = {0, 64, 128, 192 <repeats 57 times>, 256, 192 <repeats 29 times>, 320, 192 <repeats 37 times>, 384, 448, 512, 
  192, 192, 192, 192, 192, 576, 640, 704, 768, 832, 192 <repeats 16 times>, 896, 192, 960, 192, 192, 192, 192, 192, 
  192, 1024, 1088, 1152, 1216, 1280, 1344, 192 <repeats 12 times>, 1408, 192, 192, 192, 192, 192, 192, 192, 1472, 
  192 <repeats 824 times>, 1536, 192, 192, 1600, 1664, 192, 192}
(gdb) p ch >> 6
$2 = 175
(gdb) p $1[$2]
$3 = 192

I see some compiler options for package build may affects this. In fact, I can't reproduce this by simply doing `meson setup` and 'meson compile`.

Reproducible: Always
Comment 1 Jakub Jelinek 2024-06-05 10:19:51 UTC 
MirLev0/MirLev1 are const arrays generated by some generator from whatever Unicode data.
Do you see differences in mirroring.tab.i between the two fribidi versions if you build them with the same gcc version?
If so, why do you suspect gcc?  If not and you see differences in mirroring.tab.i when you build the same fribidi version
with different gcc versions, then it would be interesting to see what differences you see, with what options the generator has been compiled etc.
Comment 2 Akira TAGOH 2024-06-05 11:27:34 UTC 
Okay, I tracked this down. some *.tab.i was supposed to be generated at the build time but tarball contains older files.

I got confused that it works on git and presumed that they are the same. but they aren't actually. After removing them, it works as expected.

Sorry to trouble you.