[Bug target/42313] FAIL: gcc.target/i386/builtin-unreachable.c scan-assembler-not %e[bs]p on i686 darwin

2010-09-07 Thread howarth at nitro dot med dot uc dot edu 


--- Comment #11 from howarth at nitro dot med dot uc dot edu  2010-09-08 
01:05 ---
Fixed on trunk at r163971.


-- 

howarth at nitro dot med dot uc dot edu changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug target/42313] FAIL: gcc.target/i386/builtin-unreachable.c scan-assembler-not %e[bs]p on i686 darwin

2010-09-07 Thread hjl at gcc dot gnu dot org 


--- Comment #10 from hjl at gcc dot gnu dot org  2010-09-07 21:19 ---
Subject: Bug 42313

Author: hjl
Date: Tue Sep  7 21:18:55 2010
New Revision: 163971

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163971
Log:
Redefine STACK_BOUNDARY/PREFERRED_STACK_BOUNDARY for Darwin/x86.

gcc/

2010-09-07  H.J. Lu  
Jack Howarth 

PR target/36502
PR target/42313
PR target/44651
* gcc/config/i386/darwin.h (STACK_BOUNDARY): Redefine as 128 for
profiling or 64-bit MS_ABI and as BITS_PER_WORD otherwise.
(PREFERRED_STACK_BOUNDARY): Replace STACK_BOUNDARY with 128 in
MAX macro.

gcc/testsuite/

2010-09-07  Jack Howarth 

PR target/36502
* gcc.target/i386/pr36502.c: New test.

PR target/42313
PR target/44651
* gcc.target/i386/builtin-unreachable.c: Don't skip on darwin.
* gcc/testsuite/gcc.dg/stack-usage-1.c: Use default on i386/Darwin.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr36502.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/darwin.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/stack-usage-1.c
trunk/gcc/testsuite/gcc.target/i386/builtin-unreachable.c


-- 


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

[Bug target/42313] FAIL: gcc.target/i386/builtin-unreachable.c scan-assembler-not %e[bs]p on i686 darwin

2010-09-04 Thread howarth at nitro dot med dot uc dot edu 


--- Comment #9 from howarth at nitro dot med dot uc dot edu  2010-09-04 
21:20 ---
Updated patch to reflect the wider coverage of PRs fixed...
http://gcc.gnu.org/ml/gcc-patches/2010-09/msg00365.html


-- 


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

[Bug target/42313] FAIL: gcc.target/i386/builtin-unreachable.c scan-assembler-not %e[bs]p on i686 darwin

2010-09-04 Thread howarth at nitro dot med dot uc dot edu 


--- Comment #8 from howarth at nitro dot med dot uc dot edu  2010-09-04 
19:13 ---
(In reply to comment #7)
> I fixed the test case to not expect the unimplemented optimization in r157197,
> however, it would be nice to ensure the async signal handlers can handle
> unaligned stacks and to perform this optimization.  I'm fairly certain the
> signal handers have to cope as code gen can do:
> 
> _h:
> subl$12, %esp
> movl$1, %eax
> addl$12, %esp
> ret
> 
> for int h () { return 1; } and certainly we can take a signal at _h+0, where
> esp isn't aligned.  Given that, we can omit sp alignments for leaf functions
> (and no tail calls either), even on machines where otherwise an alignment is
> required, as long as any variables on the stack are correctly aligned.
> 
> When this optimization is added, we can undo the r157197 change. 
> 

My proposed patch to fix PR36502...

http://gcc.gnu.org/ml/gcc-patches/2010-09/msg00237.html

that enables stack realignment on intel darwin also solves this PR as well.
Comparing the output from gcc trunk before and after my patch, I see...

--- builtin-unreachable.s   2010-09-04 15:12:40.0 -0400
+++ builtin-unreachable.trunk_patched   2010-09-04 15:02:45.0 -0400
@@ -3,11 +3,7 @@
.globl _h
 _h:
 LFB0:
-   subl$12, %esp
-LCFI0:
movl$1, %eax
-   addl$12, %esp
-LCFI1:
ret
 LFE0:
.section
__TEXT,__eh_frame,coalesced,no_toc+strip_static_syms+live_support
@@ -39,16 +35,6 @@
.set L$set$2,LFE0-LFB0
.long L$set$2
.byte   0
-   .byte   0x4
-   .set L$set$3,LCFI0-LFB0
-   .long L$set$3
-   .byte   0xe
-   .byte   0x10
-   .byte   0x4
-   .set L$set$4,LCFI1-LCFI0
-   .long L$set$4
-   .byte   0xe
-   .byte   0x4
.align 2
 LEFDE1:
.subsections_via_symbols


-- 


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

[Bug target/42313] FAIL: gcc.target/i386/builtin-unreachable.c scan-assembler-not %e[bs]p on i686 darwin

2010-03-03 Thread mikestump at comcast dot net 


--- Comment #7 from mikestump at comcast dot net  2010-03-03 16:56 ---
I fixed the test case to not expect the unimplemented optimization in r157197,
however, it would be nice to ensure the async signal handlers can handle
unaligned stacks and to perform this optimization.  I'm fairly certain the
signal handers have to cope as code gen can do:

_h:
subl$12, %esp
movl$1, %eax
addl$12, %esp
ret

for int h () { return 1; } and certainly we can take a signal at _h+0, where
esp isn't aligned.  Given that, we can omit sp alignments for leaf functions
(and no tail calls either), even on machines where otherwise an alignment is
required, as long as any variables on the stack are correctly aligned.

When this optimization is added, we can undo the r157197 change. 


-- 

mikestump at comcast dot net changed:

   What|Removed |Added

 CC||mikestump at comcast dot net


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

[Bug target/42313] FAIL: gcc.target/i386/builtin-unreachable.c scan-assembler-not %e[bs]p on i686 darwin

2009-12-08 Thread pinskia at gcc dot gnu dot org 


--- Comment #6 from pinskia at gcc dot gnu dot org  2009-12-08 19:51 ---
I think this comes down to an alignment issue. On darwin, the stack has to be
aligned to 16bytes so something inside i386.c is deciding that we to allocate
the stack frame as there was something on the stack and we have to align it
again.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
  Component|testsuite   |target
  GCC build triplet|i686-apple-darwin*  |
   GCC host triplet|i686-apple-darwin*  |
 GCC target triplet|i686-apple-darwin*  |i?86-apple-darwin*
   Keywords||missed-optimization


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