[LLVMdev] OT: intel darwin losing primary target status

[Jack Howarth]

On Fri, Sep 18, 2009 at 02:40:17PM -0700, Nick Kledzik wrote:
> I thought of another work around.  The FSF gcc driver can implicitly  
> add -no_compact_unwind to the link line.  This tells the linker to not  
> produce compact unwind information from the dwarf unwind info in .o  
> files.  Then at runtime the darwin unwinder will fallback and use the  
> slow dwarf unwind info.
> 
> -Nick
> 

Nick,
   Thanks! I have asked Richard to propose a patch to disable the
additional epilog info on darwin. While we are on the topic of
eh issues on darwin, could you take a look at PR37012? On darwin9/10.
we have the following remaining failures in gcc-4.4.1 at -m32...

FAIL: g++.dg/torture/stackalign/eh-alloca-1.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/eh-vararg-1.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/eh-vararg-2.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/throw-1.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/throw-2.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/throw-3.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/eh-alloca-1.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/eh-vararg-1.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/eh-vararg-2.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/throw-1.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/throw-2.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/throw-3.C  -O3 -g  execution test

These eh failures are really weird because they are triggered by the
-g option. Without -g, the resulting test cases pass their execution
tests fine. The problem doesn't exist for -m64 (with or without -g).
I posted assembly files for these testcases at the various 
combinations (-m32 -O3, -m32 -O3 -g, -m64 -O3 -g, -m64 -O3)...

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37012#c48
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37012#c49
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37012#c50
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37012#c51

Perhaps if you diff the assembly files, you might recognize the
problem in that one as well.
              Jack