Commit Message

> Sorry, my mistake. The gcc.dg/stack-usage-1.c scan-file> foo\\t(256|264)\\tstatic and gcc.target/i386/stack-usage-realign.c> scan-file main\\t48\\tdynamic,bounded tests always compile and then fail on> execution at -m32. Their code generation is always consistent.
Not on execution but on scanning of the stack usage file. Adjusted thusly,
applied on the mainline.
* gcc.dg/stack-usage-1.c: Adjust on i386/Darwin.
* gcc.target/i386/stack-usage-realign.c: Skip on i386/Darwin.
> It is the gcc.c-torture/execute/builtins/sprintf-chk.c compilation which is> exhibiting three behaviors...>> 1) consistent code> 2) random differences in code> 3) compiler ICE>> My main concern is if this bug will spill over into production code> generation.
Sure, but I don't really see the relationship with my patch. It has been used
for more than 4 years in AdaCore compilers based on 3 different GCC versions
on a wide range of architectures and OSes (including Darwin) so I've a hard
time believing it could be responsible for random failures like this one,
especially if you don't pass -fstack-usage to the compiler.

Comments

On Thu, Sep 02, 2010 at 01:01:48PM +0200, Eric Botcazou wrote:
> > > It is the gcc.c-torture/execute/builtins/sprintf-chk.c compilation which is> > exhibiting three behaviors...> >> > 1) consistent code> > 2) random differences in code> > 3) compiler ICE> >> > My main concern is if this bug will spill over into production code> > generation.> > Sure, but I don't really see the relationship with my patch. It has been used > for more than 4 years in AdaCore compilers based on 3 different GCC versions > on a wide range of architectures and OSes (including Darwin) so I've a hard > time believing it could be responsible for random failures like this one, > especially if you don't pass -fstack-usage to the compiler.>
Eric,
Looking at the patch, it seems to me that I could strip out everything
wrappered in if flag_stack_usage statements and still end up with very
significant code changes in the compiler execution even without -fstack-usage
being used. For example, the calls to allocate_dynamic_stack_space() in
calls.c and changes like...
@@ -1223,13 +1255,28 @@
insns. Since this is an extremely rare event, we have no reliable
way of knowing which systems have this problem. So we avoid even
momentarily mis-aligning the stack. */
+ if (!known_align_valid || known_align % PREFERRED_STACK_BOUNDARY != 0)
+ {
+ size = round_push (size);
- /* If we added a variable amount to SIZE,
- we can no longer assume it is aligned. */
-#if !defined (SETJMP_VIA_SAVE_AREA)
- if (MUST_ALIGN || known_align % PREFERRED_STACK_BOUNDARY != 0)
-#endif
- size = round_push (size);
+ if (flag_stack_usage)
+ {
+ int align = PREFERRED_STACK_BOUNDARY / BITS_PER_UNIT;
+ stack_usage_size = (stack_usage_size + align - 1) / align * align;
+ }
+ }
+
+ /* The size is supposed to be fully adjusted at this point so record it
+ if stack usage info is requested. */
+ if (flag_stack_usage)
+ {
+ current_function_dynamic_stack_size += stack_usage_size;
+
+ /* ??? This is gross but the only safe stance in the absence
+ of stack usage oriented flow analysis. */
+ if (!cannot_accumulate)
+ current_function_has_unbounded_dynamic_stack_size = 1;
+ }
do_pending_stack_adjust ();
It seems like a leap of faith to say this code executes identically
to the previous in the absence of the -fstack-usage flag.
Jack

> It seems like a leap of faith to say this code executes identically> to the previous in the absence of the -fstack-usage flag.
No, it isn't, just look at both codes and you'll be convinced as well. The
only (possible) changes are for SETJMP_VIA_SAVE_AREA targets, i.e. SPARC.