[Bug rtl-optimization/58034] [4.8/4.9 Regression] glibc nptl/tst-cleanup2 fail due to scheduling

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58034

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #7 from Jakub Jelinek  ---
I agree this looks like a glibc test issue rather than gcc bug.

[Bug rtl-optimization/58034] [4.8/4.9 Regression] glibc nptl/tst-cleanup2 fail due to scheduling

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58034

--- Comment #6 from joseph at codesourcery dot com  ---
On Wed, 31 Jul 2013, amodra at gmail dot com wrote:

> The relevant test case source:
> 
>   if (setjmp (jmpbuf))
> {
>   puts ("Exiting main...");
>   return 0;
> }
> 
>   sprintf (p, "This should segv\n");
> 
>   return 1;
> }
> 
> The sprintf is optimised to three loads and stores.  The problem occurs due to
> the assignment of 1 to the REG holding the function return value being
> scheduled before the sprintf expansion.

Well, in valid code this sprintf can't trap (sprintf using glibc 
extensions to register format extensions might).  Optimizing to three 
loads and stores, and then scheduling them, seems a valid optimization to 
me.  Does -fnon-call-exceptions help?  (Though I'd prefer 
-fno-builtin-sprintf as a fix for the glibc test.)