https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82569

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2017-10-16
     Ever confirmed|0                           |1

--- Comment #1 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> So, if I compare the parameter values at this point in the working (r253529)
> and failing (r253530) code r6 holds the bad parm value:
> 
> failing:
> (gdb) info registers
> ...
> r6             0xfff0000007a  17587891077242
> 
> Works:
> (gdb) info registers
> ...
> r6             0x7a   122
> 
> 
> Why does this happen?  When it fails the value that is computed earlier in
> the code for the parameter
> 
>   iy = ((fy) >> 11);
> 
> is stored via an "stw" and then loaded via a "ld".  If there is any leftover
> garbage in the memory it will fail.  It doesn't always fail as sometimes the
> memory has 0 in the bytes not stored to via the stw and loaded via the ld.
> 
> So, looking at the assembly output:
> 
> works:
>    0x10094f9c <.general_textured_triangle+2092>:      srawi   r8,r4,11
>    0x10094fa0 <.general_textured_triangle+2096>:      std     r8,29256(r1)
> ...
>    0x100952c0 <.general_textured_triangle+2896>:      ld      r10,29256(r1)
>    (this is then stored again and loaded into r6 for the function call via
> std/ld)
> 
> fails:
>    0x10094d84 <.general_textured_triangle+2052>:      srawi   r9,r3,11
>    0x10094d88 <.general_textured_triangle+2056>:      stw     r9,29268(r1)
> ...
>    0x10095094 <.general_textured_triangle+2836>:      ld      r10,29264(r1)
>    (this is then stored again and loaded into r6 for the function call via
> std/ld)
> 
> Something in this revision causes the (working) std to be replaced by a stw.

Thanks for the preliminary analysis.  The change is supposed (1) to have an
effect only when there is an uninitialized variable in the code and (2) to
disable an unwarranted optimization.  That being said, it might also be
far-reaching enough to either expose another bug or trigger a conflict with
another part of the RTL back-end.  Can you attach a preprocessed testcase and a
command line?  FWIW I have access to gcc110 in the Compile Farm.

Reply via email to