[Bug target/47324] New: g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin

[Bug target/47324] New: g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin

[howarth at nitro dot med.uc.edu]

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

           Summary: g++.dg/torture/stackalign failures with -O3 -g at -m32
                    on darwin
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: howarth@nitro.med.uc.edu


This is the last remaining breakage with the stackalign tests on x86 darwin10.
We are failing...

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/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

These tests don't fail their execution tests if the -g is omitted. However if I
take a failing test and strip the eh-alloca-1.o object file created with -g
using 'strip -S eh-alloca-1.o' and relink the testcase it still fails. So the
failure is dependent on -g being passed to the testcase but not the debug code
generated.

Comparing the disassembled eh-alloca-1.o file (using 'otool -tv eh-alloca-1.o')
created with -g0 to that created with -g and then stripped with 'strip -S', I
find the following diff.

--- disasm_g0.txt    2011-01-16 16:33:15.000000000 -0500
+++ disasm_g_stripped.tex    2011-01-16 16:52:28.000000000 -0500
@@ -76,10 +76,10 @@ 
 000000ed    calll    0x100000000
 000000f2    movl    $0x00000004,(%esp)
 000000f9    calll    0x100000000
-000000fe    movl    0x000002cb(%ebx),%edx
+000000fe    movl    0x00000d50(%ebx),%edx
 00000104    addl    $0x0c,%edx
 00000107    movl    %edx,(%eax)
-00000109    movl    0x000002d3(%ebx),%edx
+00000109    movl    0x00000d58(%ebx),%edx
 0000010f    movl    $0x00000000,0x08(%esp)
 00000117    movl    %eax,(%esp)
 0000011a    movl    %edx,0x04(%esp)

[Bug target/47324] g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #1 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-01-16 22:04:59 UTC ---
Created attachment 22988
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22988
assembly for g++.dg/torture/stackalign/eh-alloca-1.C  -O3 -g at -m32

[Bug target/47324] g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #2 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-01-16 22:05:25 UTC ---
Created attachment 22989
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22989
assembly for g++.dg/torture/stackalign/eh-alloca-1.C  -O3 -g0 at -m32

[Bug target/47324] g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #3 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-01-16 22:07:47 UTC ---
Created attachment 22990
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22990
diff between assembly for g++.dg/torture/stackalign/eh-alloca-1.C  -O3 with -g0
and -g at -m32

[Bug target/47324] g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #4 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-01-16 22:13:53 UTC ---
Created attachment 22991
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22991
disassembly of eh-alloca-1.o created with -O3 -g0 using 'otool -tv'

[Bug target/47324] g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #5 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-01-16 22:15:19 UTC ---
Created attachment 22992
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22992
disassembly of eh-alloca-1.o created with -O3 -g using 'otool -tv' after
stripping with 'strip -S'

[Bug target/47324] g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #6 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-01-16 22:17:07 UTC ---
Created attachment 22993
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22993
diff of disassembly of eh-alloca-1.o at -g0 and stripped eh-alloca-1.o at -g

[Bug target/47324] g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #7 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-01-17 00:04:47 UTC ---
These failures appear to be unrelated to stack realignment. I find that...

[MacPro:~/eh_bug] howarth% g++-fsf-4.6
/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20110116/gcc/testsuite/g++.dg/torture/stackalign/eh-alloca-1.C
-nostdinc++ -O3 -multiply_defined suppressed -g -lm -m32 -o ./eh-alloca-1.exe
[MacPro:~/eh_bug] howarth% ./eh-alloca-1.exe
terminate called after throwing an instance of 'A'
Abort
[MacPro:~/eh_bug] howarth% g++-fsf-4.6
/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20110116/gcc/testsuite/g++.dg/torture/stackalign/eh-alloca-1.C
-nostdinc++ -O3 -multiply_defined suppressed -g0 -lm -m32 -o ./eh-alloca-1.exe
[MacPro:~/eh_bug] howarth% ./eh-alloca-1.exe                                   
                                                                        
[MacPro:~/eh_bug] howarth% 

This behavior is seen for all optimization levels (-O0,-O1, -O2,-O3,-Os).
Without -g, the resulting testcase runs fine and with -g it aborts.

[Bug target/47324] g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin

[danglin at gcc dot gnu.org]

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

John David Anglin <danglin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2011.01.17 00:58:35
                 CC|                            |danglin at gcc dot gnu.org
     Ever Confirmed|0                           |1

[Bug target/47324] g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #8 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-02-07 21:07:59 UTC ---
The Apple linker developer has looked at the failing eh-alloc-1.C case and had
the following comments...

> Also, did you ever get a
> chance to look at the stackalign_testcase2.tar.bz2 test case from radar ID 6407474, "stackalign
> failures for -O3 -g at -m32 with Xcode 3.1.2 and 3.2A number of gcc 4", in a debug version of
> the Snow Leopard unwinder? This bug is still very confusing.

I just took a look at the eh-alloc.exe case.  The case built with -g fails when
running on Lion
 (with the darwin unwinder) and the case built without -g works fine.  I
stepped through the 
unwinding.  The function foo() uses dynamic stack alignment and the dwarf
unwind info uses 
expressions to specify where the CFA is.   In the bad case (with -g) the
expression has a push 
of register 5 (ESP) where as the good case has a push of register 4 (EBP) in
the expression.

I recall that some bug cropped up long ago with the register numbering for
i386.  
Two register numbers were swapped.  The end result is the eh_frame register
numbering and 
DWARF debug info registering number are different.

I suspect that using -g is forcing the eh_frame creation to use the DWARF debug
info register 
numbering.  You can see the difference with dwarfdump:

[/tmp]> dwarfdump --eh-frame
stackalign_testcase2/stackalign_with_g/eh-alloca-1.exe | grep -A8 __Z3fooi
    start_addr: 0x00001d20 __Z3fooi
    range_size: 0x000000b8 (end_addr = 0x00001dd8)
  LSDA address: 0x00002094
  Instructions: 0x00001d20: CFA=esp+4     eip=[esp]
                DW_CFA_advance_loc4 (4)
                DW_CFA_def_cfa (ecx, 0)
                0x00001d24: CFA=ecx       eip=[ecx-4]
                DW_CFA_advance_loc4 (7)
                DW_CFA_expression (esp, expr(esp0))         
[/tmp]> dwarfdump --eh-frame
stackalign_testcase2/stackalign_without_g/eh-alloca-1.exe | grep -A8 __Z3fooi
    start_addr: 0x00001d20 __Z3fooi
    range_size: 0x000000b8 (end_addr = 0x00001dd8)
  LSDA address: 0x00002094
  Instructions: 0x00001d20: CFA=esp+4     eip=[esp]
                DW_CFA_advance_loc4 (4)
                DW_CFA_def_cfa (ecx, 0)
                0x00001d24: CFA=ecx       eip=[ecx-4]
                DW_CFA_advance_loc4 (7)
                DW_CFA_expression (ebp, expr(ebp0))
[/tmp]>

[Bug target/47324] g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin

[mrs at gcc dot gnu.org]

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

mrs@gcc.gnu.org <mrs at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mrs at gcc dot gnu.org

--- Comment #9 from mrs at gcc dot gnu.org <mrs at gcc dot gnu.org> 2011-02-07 22:38:42 UTC ---
Did this ever work?  :-(

[Bug target/47324] g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #10 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-02-08 00:45:31 UTC ---
If this is a problem exposed because...

/* Darwin uses the standard DWARF register numbers but the default
   register numbers for STABS.  Fortunately for 64-bit code the
   default and the standard are the same.  */
#undef DBX_REGISTER_NUMBER
#define DBX_REGISTER_NUMBER(n)                                  \
  (TARGET_64BIT ? dbx64_register_map[n]                         \
   : write_symbols == DWARF2_DEBUG ? svr4_dbx_register_map[n]   \
   : dbx_register_map[n])

...uses write_symbols, we may have to go to winnt or cygming to reproduce it 
on another target as they appear to be the only other i386 targets using
write_symbols.

[Bug target/47324] g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #11 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-02-08 02:18:30 UTC ---
(In reply to comment #9)
> Did this ever work?  :-(

This appears to work for Apple gcc 4.2.1 in SL...

g++ eh-alloca-1.C -nostdinc++ -O3 -multiply_defined suppressed -lm -m32 -o
./eh-alloca-1.exe

which creates a non-crashing executable with or without -g.

[MacPro:g++.dg/torture/stackalign] howarth% dwarfdump --eh-frame
eh-alloca-1.exe.withg | grep -A9 __Z3fooi
    start_addr: 0x00001c90 __Z3fooi
    range_size: 0x000000c8 (end_addr = 0x00001d58)
  LSDA address: 0x00001e50
  Instructions: 0x00001c90: CFA=esp+4     eip=[esp]
                DW_CFA_advance_loc4 (1)
                DW_CFA_def_cfa_offset (8)
                DW_CFA_offset (ebp, -8)
                0x00001c91: CFA=esp+8     ebp=[esp]  eip=[esp+4]
                DW_CFA_advance_loc4 (2)
                DW_CFA_def_cfa_register (ebp)
[MacPro:g++.dg/torture/stackalign] howarth% dwarfdump --eh-frame
eh-alloca-1.exe.withoutg | grep -A9 __Z3fooi
    start_addr: 0x00001c90 __Z3fooi
    range_size: 0x000000c8 (end_addr = 0x00001d58)
  LSDA address: 0x00001e50
  Instructions: 0x00001c90: CFA=esp+4     eip=[esp]
                DW_CFA_advance_loc4 (1)
                DW_CFA_def_cfa_offset (8)
                DW_CFA_offset (ebp, -8)
                0x00001c91: CFA=esp+8     ebp=[esp]  eip=[esp+4]
                DW_CFA_advance_loc4 (2)
                DW_CFA_def_cfa_register (ebp)

[Bug target/47324] g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #12 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-02-08 02:28:04 UTC ---
A couple historical commits...

http://gcc.gnu.org/ml/gcc-patches/2006-02/msg00874.html
http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01704.html

So Geoff introduced...

/* Unfortunately, the 32-bit EH information also doesn't use the standard
   DWARF register numbers.  */
#define DWARF2_FRAME_REG_OUT(n, for_eh)                                 \
  (! (for_eh) || write_symbols != DWARF2_DEBUG || TARGET_64BIT ? (n)    \
   : (n) == 5 ? 4                                                       \
   : (n) == 4 ? 5                                                       \
   : (n) >= 11 && (n) <= 18 ? (n) + 1                                   \
   : (n))

as a hack and we have been living with it ever since.

[Bug target/47324] g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #13 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-02-08 10:45:31 UTC ---
The audit trail is a little fuzzy here but it seems like this wasn't present at
r137753 but was at r138906 for -m32 on i686-apple-darwin9. We also had PR37012
opened for this at one point.

[Bug target/47324] g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin

[mrs at gcc dot gnu.org]

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

--- Comment #14 from mrs at gcc dot gnu.org <mrs at gcc dot gnu.org> 2011-02-08 10:50:43 UTC ---
157762 seems to have new code that outputs a dwarf register number without
going though DWARF2_FRAME_REG_OUT which I think is wrong.

I fixed that and played around for a bit, the closest I could come up with was
something like the below...  but I'm certain it is wrong.  :-(  We need someone
to puzzle over the dwarf/stabs/unwind/eh_frame debug info and come up with the
right solution.  Also, at lower optimizations the test still failed.

I'm wondering if we are even wondering around in the right area yet.

Index: dwarf2out.c
===================================================================
--- dwarf2out.c    (revision 169905)
+++ dwarf2out.c    (working copy)
@@ -474,7 +474,7 @@
 static void dwarf2out_frame_debug_expr (rtx, const char *);

 /* Support for complex CFA locations.  */
-static void output_cfa_loc (dw_cfi_ref);
+static void output_cfa_loc (dw_cfi_ref, bool);
 static void output_cfa_loc_raw (dw_cfi_ref);
 static void get_cfa_from_loc_descr (dw_cfa_location *,
                     struct dw_loc_descr_struct *);
@@ -3317,7 +3317,7 @@

     case DW_CFA_def_cfa_expression:
     case DW_CFA_expression:
-      output_cfa_loc (cfi);
+      output_cfa_loc (cfi, for_eh);
       break;

     case DW_CFA_GNU_negative_offset_extended:
@@ -5451,14 +5451,16 @@
    description based on a cfi entry with a complex address.  */

 static void
-output_cfa_loc (dw_cfi_ref cfi)
+output_cfa_loc (dw_cfi_ref cfi, bool for_eh)
 {
+  unsigned long r;
   dw_loc_descr_ref loc;
   unsigned long size;

   if (cfi->dw_cfi_opc == DW_CFA_expression)
     {
-      dw2_asm_output_data (1, cfi->dw_cfi_oprnd1.dw_cfi_reg_num, NULL);
+      r = DWARF2_FRAME_REG_OUT (cfi->dw_cfi_oprnd1.dw_cfi_reg_num, for_eh);
+      dw2_asm_output_data (1, r, NULL);
       loc = cfi->dw_cfi_oprnd2.dw_cfi_loc;
     }
   else
Index: config/i386/darwin.h
===================================================================
--- config/i386/darwin.h    (revision 169905)
+++ config/i386/darwin.h    (working copy)
@@ -252,17 +252,12 @@
 #undef DBX_REGISTER_NUMBER
 #define DBX_REGISTER_NUMBER(n)                     \
   (TARGET_64BIT ? dbx64_register_map[n]                \
-   : write_symbols == DWARF2_DEBUG ? svr4_dbx_register_map[n]    \
-   : dbx_register_map[n])
+   : darwin_dbx_register_number(n))

 /* Unfortunately, the 32-bit EH information also doesn't use the standard
    DWARF register numbers.  */
 #define DWARF2_FRAME_REG_OUT(n, for_eh)                    \
-  (! (for_eh) || write_symbols != DWARF2_DEBUG || TARGET_64BIT ? (n)    \
-   : (n) == 5 ? 4                            \
-   : (n) == 4 ? 5                            \
-   : (n) >= 11 && (n) <= 18 ? (n) + 1                    \
-   : (n))
+  darwin_dwarf2_frame_reg_out (n, for_eh)

 #undef REGISTER_SUBTARGET_PRAGMAS
 #define REGISTER_SUBTARGET_PRAGMAS() DARWIN_REGISTER_TARGET_PRAGMAS()
Index: config/darwin.c
===================================================================
--- config/darwin.c    (revision 169905)
+++ config/darwin.c    (working copy)
@@ -3094,4 +3094,47 @@
   fputs (":\n", fp);
 }

+static bool
+darwin_will_use_eh ()
+{
+  if ()
+    return true;
+  return 0;
+}
+
+int
+darwin_dbx_register_number(n)
+{
+#if 1
+  /* Without -O3, eh-alloc-1.c -m32 fails.  */
+  /* Works! */
+  if (write_symbols == DWARF2_DEBUG && !dwarf2out_do_frame())
+    return svr4_dbx_register_map[n];
+#else
+  /* Works! */
+  if (!(write_symbols == DWARF2_DEBUG
+    || write_symbols == NO_DEBUG))
+    return svr4_dbx_register_map[n];
+#endif
+  return dbx_register_map[n];
+}  
+
+int
+darwin_dwarf2_frame_reg_out (n, for_eh)
+{
+  if (! (for_eh)
+      /* WTF, if we are doing this for_eh, and the eh uses the pre-svr4
numbers, then
+     we must convert the svr4 numbers back.  */
+      || (write_symbols != DWARF2_DEBUG, 0)
+      || TARGET_64BIT)
+    return n;
+  if (n == 5)
+    return 4;
+  if (n == 4)
+    return 5;
+  if (n >= 11 && n <= 18)
+    return n + 1;
+  return n;
+}
+
 #include "gt-darwin.h"

[Bug target/47324] g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #15 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-02-08 10:57:38 UTC ---
These probably were failing since added here...

http://gcc.gnu.org/ml/gcc-patches/2008-07/msg00647.html

[Bug target/47324] g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #16 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-02-08 19:30:46 UTC ---
It is interesting that llvm-gcc42 still uses DWARF2_FRAME_REG_OUT but I don't
see anything like that in clang. Perhaps it would help if we asked about that
issue with the llvm developers to see if they did anything special to
transition off of DWARF2_FRAME_REG_OUT for clang?

[Bug target/47324] g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #17 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-02-09 00:59:37 UTC ---
Author: jakub
Date: Fri Mar 26 20:53:58 2010
New Revision: 157762

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157762
Log:
    PR debug/43540
    * dwarf2out.c (reg_save): For DW_CFA_expression put regnum
    into first operand and location into second.
    (dw_cfi_oprnd1_desc): Return dw_cfi_oprnd_reg_num instead of
    dw_cfi_oprnd_loc for DW_CFA_expression.
    (dw_cfi_oprnd2_desc): Return dw_cfi_oprnd_loc for DW_CFA_expression.
    (output_cfa_loc, output_cfa_loc_raw): For DW_CFA_expression
    assume first argument is regnum and second argument is location.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/dwarf2out.c

[Bug target/47324] r157762 caused g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #18 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-02-09 02:03:46 UTC ---
It may be...

--- trunk/gcc/dwarf2out.c    2010/03/26 19:21:13    157761
+++ trunk/gcc/dwarf2out.c    2010/03/26 20:53:58    157762
@@ -1115,8 +1115,8 @@
       && sreg == INVALID_REGNUM)
     {
       cfi->dw_cfi_opc = DW_CFA_expression;
-      cfi->dw_cfi_oprnd2.dw_cfi_reg_num = reg;
-      cfi->dw_cfi_oprnd1.dw_cfi_loc
+      cfi->dw_cfi_oprnd1.dw_cfi_reg_num = reg;
+      cfi->dw_cfi_oprnd2.dw_cfi_loc
     = build_cfa_aligned_loc (offset, fde->stack_realignment);
     }
   else if (sreg == INVALID_REGNUM)

a cursory examination of dwarf2out.c shows that the calls of
DWARF2_FRAME_REG_OUT are related to either dw_cfi_oprnd1 or dw_cfi_oprnd2
depending on the location. I don't see changes associated to r157762 making
sure that the existing DWARF2_FRAME_REG_OUT calls were corrected for the
reversal of the operands.

[Bug target/47324] r157762 caused g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #19 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-02-09 02:50:21 UTC ---
Could this be the problem code?

static void
output_cfa_loc (dw_cfi_ref cfi)
{
  dw_loc_descr_ref loc;
  unsigned long size;

  if (cfi->dw_cfi_opc == DW_CFA_expression)
    {
      dw2_asm_output_data (1, cfi->dw_cfi_oprnd1.dw_cfi_reg_num, NULL); <======
      loc = cfi->dw_cfi_oprnd2.dw_cfi_loc;
    }
  else
    loc = cfi->dw_cfi_oprnd1.dw_cfi_loc;

  /* Output the size of the block.  */
  size = size_of_locs (loc);
  dw2_asm_output_data_uleb128 (size, NULL);

  /* Now output the operations themselves.  */
  output_loc_sequence (loc);
}

dw_cfi_oprnd1.dw_cfi_reg_num is being passed to dw2_asm_output_data() directly
with out being processed through DWARF2_FRAME_REG_OUT first.

[Bug target/47324] r157762 caused g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #20 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-02-09 05:10:26 UTC ---
Tested...

Index: gcc/dwarf2out.c
===================================================================
--- gcc/dwarf2out.c    (revision 169960)
+++ gcc/dwarf2out.c    (working copy)
@@ -5454,11 +5454,12 @@ static void
 output_cfa_loc (dw_cfi_ref cfi)
 {
   dw_loc_descr_ref loc;
-  unsigned long size;
+  unsigned long r, size;

   if (cfi->dw_cfi_opc == DW_CFA_expression)
     {
-      dw2_asm_output_data (1, cfi->dw_cfi_oprnd1.dw_cfi_reg_num, NULL);
+      r = DWARF2_FRAME_REG_OUT (cfi->dw_cfi_oprnd1.dw_cfi_reg_num, 1);
+      dw2_asm_output_data (1, (cfi->dw_cfi_opc | (r & 0x3f)), NULL);
       loc = cfi->dw_cfi_oprnd2.dw_cfi_loc;
     }
   else

which bootstraps but the g++.dg/torture/stackalign/eh-alloca-1.C  -O0 
execution test just hangs.
I passed 1 to DWARF2_FRAME_REG_OUT because for_eh wasn't available which I
guess isn't correct.

[Bug target/47324] r157762 caused g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin

[ian at airs dot com]

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

Ian Lance Taylor <ian at airs dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ian at airs dot com

--- Comment #21 from Ian Lance Taylor <ian at airs dot com> 2011-02-09 05:31:11 UTC ---
output_cfa_loc is only called from output_cfi, and output_cfi does have a
for_eh parameter, so you should just pass for_eh to output_cfa_loc.

[Bug target/47324] r157762 caused g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #22 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-02-09 08:23:36 UTC ---
The #c14 dwarf2out.c hunks look reasonable, though I'd probably just declare
the r variable inside of the if block (i.e.
...
    {
      unsigned long r
        = DWARF2_FRAME_REG_OUT (cfi->dw_cfi_oprnd1.dw_cfi_reg_num, for_eh);
...
).  And for consistency DWARF2_FRAME_REG_OUT should be probably used in
output_cfa_loc_raw too, just with unconditional 1 as for_eh.

That said, I very much doubt r157762 did anything here, for this purpose it
just swapped the two operands, but the code wasn't using DWARF2_FRAME_REG_OUT
before that check in either.  r157762 would only matter in output_cfis which is
called when doing hot/cold section partitioning (which eh-alloca-1.C is not).

[Bug target/47324] r157762 caused g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #23 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-02-09 12:31:27 UTC ---
Any comments on this bit of Mike's patch...

+int
+darwin_dbx_register_number(n)
+{
+#if 1
+  /* Without -O3, eh-alloc-1.c -m32 fails.  */
+  /* Works! */
+  if (write_symbols == DWARF2_DEBUG && !dwarf2out_do_frame())
+    return svr4_dbx_register_map[n];
+#else
+  /* Works! */
+  if (!(write_symbols == DWARF2_DEBUG
+    || write_symbols == NO_DEBUG))
+    return svr4_dbx_register_map[n];
+#endif
+  return dbx_register_map[n];
+}

[Bug target/47324] r157762 caused g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin

[ian at airs dot com]

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

--- Comment #24 from Ian Lance Taylor <ian at airs dot com> 2011-02-09 14:10:25 UTC ---
The first branch of darwin_dbx_register_number looks like it will use the wrong
register numbers in debug info.  The second branch looks like it will do the
wrong thing for -gstabs.  I don't think either change is necessary at all given
your other patch.

[Bug target/47324] r157762 caused g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #25 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-02-09 14:25:23 UTC ---
Ian, does that mean you believe we should just need...

int
darwin_dbx_register_number(n)
 return dbx_register_map[n];

[Bug target/47324] r157762 caused g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin

[ian at airs dot com]

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

--- Comment #26 from Ian Lance Taylor <ian at airs dot com> 2011-02-09 15:13:22 UTC ---
I think the patch to dwarf2out.c is all you need and I don't understand why you
are thinking about any patch to config/i386/darwin.h and config/i386/darwin.c
at all.

[Bug target/47324] r157762 caused g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #27 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-02-09 16:28:55 UTC ---
Ian,
   Just using...

Index: gcc/dwarf2out.c
===================================================================
--- gcc/dwarf2out.c    (revision 169978)
+++ gcc/dwarf2out.c    (working copy)
@@ -474,8 +474,8 @@ static bool clobbers_queued_reg_save (co
 static void dwarf2out_frame_debug_expr (rtx, const char *);

 /* Support for complex CFA locations.  */
-static void output_cfa_loc (dw_cfi_ref);
-static void output_cfa_loc_raw (dw_cfi_ref);
+static void output_cfa_loc (dw_cfi_ref, bool);
+static void output_cfa_loc_raw (dw_cfi_ref, bool);
 static void get_cfa_from_loc_descr (dw_cfa_location *,
                     struct dw_loc_descr_struct *);
 static struct dw_loc_descr_struct *build_cfa_loc
@@ -3317,7 +3317,7 @@ output_cfi (dw_cfi_ref cfi, dw_fde_ref f

     case DW_CFA_def_cfa_expression:
     case DW_CFA_expression:
-      output_cfa_loc (cfi);
+      output_cfa_loc (cfi, for_eh);
       break;

     case DW_CFA_GNU_negative_offset_extended:
@@ -3422,7 +3422,7 @@ output_cfi_directive (dw_cfi_ref cfi)
     case DW_CFA_def_cfa_expression:
     case DW_CFA_expression:
       fprintf (asm_out_file, "\t.cfi_escape %#x,", cfi->dw_cfi_opc);
-      output_cfa_loc_raw (cfi);
+      output_cfa_loc_raw (cfi, 1);
       fputc ('\n', asm_out_file);
       break;

@@ -5451,14 +5451,15 @@ output_loc_sequence_raw (dw_loc_descr_re
    description based on a cfi entry with a complex address.  */

 static void
-output_cfa_loc (dw_cfi_ref cfi)
+output_cfa_loc (dw_cfi_ref cfi, bool for_eh)
 {
   dw_loc_descr_ref loc;
   unsigned long size;

   if (cfi->dw_cfi_opc == DW_CFA_expression)
     {
-      dw2_asm_output_data (1, cfi->dw_cfi_oprnd1.dw_cfi_reg_num, NULL);
+      unsigned long r = DWARF2_FRAME_REG_OUT
(cfi->dw_cfi_oprnd1.dw_cfi_reg_num, for_eh);
+      dw2_asm_output_data (1, r, NULL);
       loc = cfi->dw_cfi_oprnd2.dw_cfi_loc;
     }
   else
@@ -5475,14 +5476,15 @@ output_cfa_loc (dw_cfi_ref cfi)
 /* Similar, but used for .cfi_escape.  */

 static void
-output_cfa_loc_raw (dw_cfi_ref cfi)
+output_cfa_loc_raw (dw_cfi_ref cfi, bool for_eh)
 {
   dw_loc_descr_ref loc;
   unsigned long size;

   if (cfi->dw_cfi_opc == DW_CFA_expression)
     {
-      fprintf (asm_out_file, "%#x,", cfi->dw_cfi_oprnd1.dw_cfi_reg_num);
+      unsigned long r = DWARF2_FRAME_REG_OUT
(cfi->dw_cfi_oprnd1.dw_cfi_reg_num, for_eh);
+      fprintf (asm_out_file, "%#lx,", r);
       loc = cfi->dw_cfi_oprnd2.dw_cfi_loc;
     }
   else

still gives you the failures at -O3 -g for -m32.

[Bug target/47324] r157762 caused g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin

[ian at airs dot com]

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

--- Comment #28 from Ian Lance Taylor <ian at airs dot com> 2011-02-09 16:53:22 UTC ---
Then let's find out why that is.

The patch in comment #23 looks clearly incorrect to me.

[Bug target/47324] r157762 caused g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #29 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-02-10 02:18:36 UTC ---
(In reply to comment #28)
> Then let's find out why that is.
> 
> The patch in comment #23 looks clearly incorrect to me.

Okay. The problem with the patch in Comment 27 is that it only partially fixes
the output for DW_CFA_expression. With the partial patch the failing test cases
still fail but now produce...

terminate called after throwing an instance of 'A'

The output now shows...

[MacPro:~/work] howarth% dwarfdump --eh-frame eh-alloca-1.exe | grep -A8
__Z3fooi                                                                       
                                start_addr: 0x00001d20 __Z3fooi    range_size:
0x000000b5 (end_addr = 0x00001dd5)  LSDA address: 0x00002094  Instructions:
0x00001d20: CFA=esp+4     eip=[esp]                DW_CFA_advance_loc4 (4)
                DW_CFA_def_cfa (ecx, 0)
                0x00001d24: CFA=ecx       eip=[ecx-4]
                DW_CFA_advance_loc4 (7)
                DW_CFA_expression (ebp, expr(esp0))

with -O3 -g. Before the partial patch we had....

                DW_CFA_expression (esp, expr(esp0))

but we want

               DW_CFA_expression (ebp, expr(ebp0))

[Bug target/47324] r157762 caused g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #30 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-02-10 03:03:21 UTC ---
Don't we have to change cfi->dw_cfi_oprnd2.dw_cfi_loc before it is assigned to
loc in output_cfa_loc when for_eh?

[Bug target/47324] r157762 caused g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin

[jakub at gcc dot gnu.org]

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

--- Comment #31 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-02-10 08:43:02 UTC ---
You really don't need to add for_eh argument to output_cfa_loc_raw, you can
assume it is 1.

If you need to still adjust the register numbers inside of expressions, I guess
for the current targets using DWARF2_FRAME_REG_OUT (rs6000 and darwin/i386)
this is solvable by passing for_eh parameter down to output_loc_sequence and
output_loc_operands, in output_loc_sequence adjust for output dw_loc_opc for
DW_OP_{,b}reg0 .. 31 using DWARF2_FRAME_REG_OUT (and perhaps assert that
it is still <= 31; don't modify loc->dw_loc_opc though) and in
output_loc_operands adjust DW_OP_{,b}regx argument and assert that
size_of_uleb128 of the first argument is the same as of the adjusted argument
using DWARF2_FRAME_REG_OUT.  Additionally, in output_loc*raw* variants don't
pass for_eh down, just use DWARF2_FRAME_REG_OUT with unconditional 1 second
argument.

[Bug target/47324] r157762 caused g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #32 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-02-10 14:38:22 UTC ---
(In reply to comment #31)

I don't see how we can directly use DWARF2_FRAME_REG_OUT in
output_loc_operands, except as a template for the desired register changes. How
about this strategy for that part of the patch?


@@ -5291,16 +5291,44 @@ output_loc_operands (dw_loc_descr_ref lo
 /* Output a sequence of location operations.  */

 static void
-output_loc_sequence (dw_loc_descr_ref loc)
+output_loc_sequence (dw_loc_descr_ref loc, bool for_eh)
 {
+  unsigned int dw_op;
   for (; loc != NULL; loc = loc->dw_loc_next)
     {
       /* Output the opcode.  */
-      dw2_asm_output_data (1, loc->dw_loc_opc,
-               "%s", dwarf_stack_op_name (loc->dw_loc_opc));
+      dw_op = loc->dw_loc_opc; 
+      if (for_eh)
+         switch (dw_op)
+           {
+       case DW_OP_reg4:
+        dw_op = DW_OP_reg5;
+       case DW_OP_reg5:
+        dw_op = DW_OP_reg4
+       case DW_OP_reg11:
+            dw_op = DW_OP_reg12;
+       case DW_OP_reg12:
+        dw_op = DW_OP_reg13;
+           case DW_OP_reg13:
+        dw_op = DW_OP_reg14;
+       case DW_OP_reg14:
+        dw_op = DW_OP_reg15; 
+       case DW_OP_reg15:
+        dw_op = DW_OP_reg16;
+       case DW_OP_reg16:
+        dw_op = DW_OP_reg17;
+       case DW_OP_reg17:
+        dw_op = DW_OP_reg18;
+       case DW_OP_reg18:
+        dw_op = DW_OP_reg19;
+       default:
+        ;
+           }
+        dw2_asm_output_data (1, loc->dw_loc_opc,
+                "%s", dwarf_stack_op_name (dw_op));

       /* Output the operand(s) (if any).  */
-      output_loc_operands (loc);
+      output_loc_operands (loc, for_eh);
     }
 }

[Bug target/47324] r157762 caused g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin

[iains at gcc dot gnu.org]

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

--- Comment #33 from Iain Sandoe <iains at gcc dot gnu.org> 2011-02-10 14:39:46 UTC ---
in addition to Mike's fix,

the dw_loc_descr_ref reg numbers need to be adjusted in the loc lists,

below is a hack which works - I don't know the code well enough to know if the
dw_loc_opc should just be written to the translated version in the first place.

=====

Index: gcc/dwarf2out.c
===================================================================
--- gcc/dwarf2out.c    (revision 170000)
+++ gcc/dwarf2out.c    (working copy)
@@ -474,7 +474,7 @@ static bool clobbers_queued_reg_save (const_rtx);
 static void dwarf2out_frame_debug_expr (rtx, const char *);

 /* Support for complex CFA locations.  */
-static void output_cfa_loc (dw_cfi_ref);
+static void output_cfa_loc (dw_cfi_ref, int);
 static void output_cfa_loc_raw (dw_cfi_ref);
 static void get_cfa_from_loc_descr (dw_cfa_location *,
                     struct dw_loc_descr_struct *);
@@ -3317,7 +3317,7 @@ output_cfi (dw_cfi_ref cfi, dw_fde_ref fde, int fo

     case DW_CFA_def_cfa_expression:
     case DW_CFA_expression:
-      output_cfa_loc (cfi);
+      output_cfa_loc (cfi, for_eh);
       break;

     case DW_CFA_GNU_negative_offset_extended:
@@ -5291,13 +5291,21 @@ output_loc_operands (dw_loc_descr_ref loc)
 /* Output a sequence of location operations.  */

 static void
-output_loc_sequence (dw_loc_descr_ref loc)
+output_loc_sequence (dw_loc_descr_ref loc, int for_eh)
 {
   for (; loc != NULL; loc = loc->dw_loc_next)
     {
       /* Output the opcode.  */
-      dw2_asm_output_data (1, loc->dw_loc_opc,
-               "%s", dwarf_stack_op_name (loc->dw_loc_opc));
+      if (for_eh && loc->dw_loc_opc >= DW_OP_breg0 && loc->dw_loc_opc <=
DW_OP_breg31)
+    {
+      unsigned r = (loc->dw_loc_opc - DW_OP_breg0);
+      r = DWARF2_FRAME_REG_OUT (r, for_eh) ;
+      dw2_asm_output_data (1, (r+DW_OP_breg0),
+                 "%s", dwarf_stack_op_name (r+DW_OP_breg0));
+    }
+      else
+    dw2_asm_output_data (1, loc->dw_loc_opc,
+                 "%s", dwarf_stack_op_name (loc->dw_loc_opc));

       /* Output the operand(s) (if any).  */
       output_loc_operands (loc);
@@ -5451,14 +5459,16 @@ output_loc_sequence_raw (dw_loc_descr_ref loc)
    description based on a cfi entry with a complex address.  */

 static void
-output_cfa_loc (dw_cfi_ref cfi)
+output_cfa_loc (dw_cfi_ref cfi, int for_eh)
 {
   dw_loc_descr_ref loc;
   unsigned long size;

   if (cfi->dw_cfi_opc == DW_CFA_expression)
     {
-      dw2_asm_output_data (1, cfi->dw_cfi_oprnd1.dw_cfi_reg_num, NULL);
+      unsigned long r = 
+    DWARF2_FRAME_REG_OUT (cfi->dw_cfi_oprnd1.dw_cfi_reg_num, for_eh);
+      dw2_asm_output_data (1, r, NULL);
       loc = cfi->dw_cfi_oprnd2.dw_cfi_loc;
     }
   else
@@ -5469,7 +5479,7 @@ static void
   dw2_asm_output_data_uleb128 (size, NULL);

   /* Now output the operations themselves.  */
-  output_loc_sequence (loc);
+  output_loc_sequence (loc, for_eh);
 }

 /* Similar, but used for .cfi_escape.  */
@@ -11075,7 +11085,7 @@ output_loc_list (dw_loc_list_ref list_head)
       gcc_assert (size <= 0xffff);
       dw2_asm_output_data (2, size, "%s", "Location expression size");

-      output_loc_sequence (curr->expr);
+      output_loc_sequence (curr->expr, 0);
     }

   dw2_asm_output_data (DWARF2_ADDR_SIZE, 0,
@@ -11153,7 +11163,7 @@ output_die (dw_die_ref die)
       else
         dw2_asm_output_data (constant_size (size), size, "%s", name);

-      output_loc_sequence (AT_loc (a));
+      output_loc_sequence (AT_loc (a), 0);
       break;

     case dw_val_class_const:

[Bug target/47324] r157762 caused g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin

[jakub at gcc dot gnu.org]

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

--- Comment #34 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-02-10 15:01:44 UTC ---
For #c32, you obviously can't hardcode darwin ugly hacks into generic code.
The #c33 patch looks much better, but still
1) in output_loc_sequence, you need to use DWARF2_FRAME_REG_OUT even if
!for_eh,
   so that conditional has to go (on ppc, DWARF2-FRAME_REG_OUT changes the
value
   only if !for_eh.  On the other side, you want to handle
   DW_OP_reg0 ... DW_OP_reg31 similarly.  So something like:

    enum dwarf_location_atom opc = loc->dw_loc_opc;
    if (opc >= DW_OP_breg0 && opc <= DW_OP_breg31)
      {
        unsigned r = (opc - DW_OP_breg0);
        r = DWARF_FRAME_REG_OUT (r, for_eh);
        gcc_assert (r <= 31);
        opc = (enum dwarf_location_atom) (DW_OP_breg0 + r);
      }
    else if (opc >= DW_OP_reg0 && opc <= DW_OP_reg31)
      {
        unsigned r = (opc - DW_OP_reg0);
        r = DWARF_FRAME_REG_OUT (r, for_eh);
        gcc_assert (r <= 31);
        opc = (enum dwarf_location_atom) (DW_OP_reg0 + r);
      }
    dw2_asm_output_data (1, opc, "%s", dwarf_stack_op_name (opc));

2) you need to handle DW_OP_bregx and DW_OP_regx operand in output_loc_operands
(this time with assertion that size_of_uleb128 is the same).

3) the *raw* routines need similar changes, just with for_eh argument not
passed around (instead assumed to be 1).

[Bug target/47324] r157762 caused g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin

[iains at gcc dot gnu.org]

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

--- Comment #35 from Iain Sandoe <iains at gcc dot gnu.org> 2011-02-10 15:59:27 UTC ---
(In reply to comment #34)
> For #c32, you obviously can't hardcode darwin ugly hacks into generic code.
> The #c33 patch looks much better, but still
> 1) in output_loc_sequence, you need to use DWARF2_FRAME_REG_OUT even if
> !for_eh,
>    so that conditional has to go (on ppc, DWARF2-FRAME_REG_OUT changes the
> value

Thanks Jakub, yeah that was an oversight - was looking at the ppc code this
morning...

so -- something like this?

Index: gcc/dwarf2out.c
===================================================================
--- gcc/dwarf2out.c    (revision 170000)
+++ gcc/dwarf2out.c    (working copy)
@@ -474,7 +474,7 @@ static bool clobbers_queued_reg_save (const_rtx);
 static void dwarf2out_frame_debug_expr (rtx, const char *);

 /* Support for complex CFA locations.  */
-static void output_cfa_loc (dw_cfi_ref);
+static void output_cfa_loc (dw_cfi_ref, int);
 static void output_cfa_loc_raw (dw_cfi_ref);
 static void get_cfa_from_loc_descr (dw_cfa_location *,
                     struct dw_loc_descr_struct *);
@@ -3317,7 +3317,7 @@ output_cfi (dw_cfi_ref cfi, dw_fde_ref fde, int fo

     case DW_CFA_def_cfa_expression:
     case DW_CFA_expression:
-      output_cfa_loc (cfi);
+      output_cfa_loc (cfi, for_eh);
       break;

     case DW_CFA_GNU_negative_offset_extended:
@@ -5056,7 +5056,7 @@ static void get_ref_die_offset_label (char *, dw_d
 /* Output location description stack opcode's operands (if any).  */

 static void
-output_loc_operands (dw_loc_descr_ref loc)
+output_loc_operands (dw_loc_descr_ref loc, int for_eh)
 {
   dw_val_ref val1 = &loc->dw_loc_oprnd1;
   dw_val_ref val2 = &loc->dw_loc_oprnd2;
@@ -5227,14 +5227,24 @@ static void
       dw2_asm_output_data_sleb128 (val1->v.val_int, NULL);
       break;
     case DW_OP_regx:
-      dw2_asm_output_data_uleb128 (val1->v.val_unsigned, NULL);
+      {
+    unsigned r = DWARF2_FRAME_REG_OUT (val1->v.val_unsigned, for_eh);
+    gcc_assert (size_of_uleb128 (r) 
+            == size_of_uleb128 (val1->v.val_unsigned));
+    dw2_asm_output_data_uleb128 (r, NULL);    
+      }
       break;
     case DW_OP_fbreg:
       dw2_asm_output_data_sleb128 (val1->v.val_int, NULL);
       break;
     case DW_OP_bregx:
-      dw2_asm_output_data_uleb128 (val1->v.val_unsigned, NULL);
-      dw2_asm_output_data_sleb128 (val2->v.val_int, NULL);
+      {
+    unsigned r = DWARF2_FRAME_REG_OUT (val1->v.val_unsigned, for_eh);
+    gcc_assert (size_of_uleb128 (r) 
+            == size_of_uleb128 (val1->v.val_unsigned));
+    dw2_asm_output_data_uleb128 (r, NULL);    
+    dw2_asm_output_data_sleb128 (val2->v.val_int, NULL);
+      }
       break;
     case DW_OP_piece:
       dw2_asm_output_data_uleb128 (val1->v.val_unsigned, NULL);
@@ -5291,16 +5301,32 @@ static void
 /* Output a sequence of location operations.  */

 static void
-output_loc_sequence (dw_loc_descr_ref loc)
+output_loc_sequence (dw_loc_descr_ref loc, int for_eh)
 {
   for (; loc != NULL; loc = loc->dw_loc_next)
     {
+      enum dwarf_location_atom opc = loc->dw_loc_opc;
       /* Output the opcode.  */
-      dw2_asm_output_data (1, loc->dw_loc_opc,
-               "%s", dwarf_stack_op_name (loc->dw_loc_opc));
+      if (opc >= DW_OP_breg0 && opc <= DW_OP_breg31)
+    {
+      unsigned r = (opc - DW_OP_breg0);
+      r = DWARF2_FRAME_REG_OUT (r, for_eh);
+      gcc_assert (r <= 31);
+      opc = (enum dwarf_location_atom) (DW_OP_breg0 + r);
+    }
+      else if (opc >= DW_OP_reg0 && opc <= DW_OP_reg31)
+    {
+      unsigned r = (opc - DW_OP_reg0);
+      r = DWARF2_FRAME_REG_OUT (r, for_eh);
+      gcc_assert (r <= 31);
+      opc = (enum dwarf_location_atom) (DW_OP_reg0 + r);
+    }

+      dw2_asm_output_data (1, opc,
+                 "%s", dwarf_stack_op_name (opc));
+
       /* Output the operand(s) (if any).  */
-      output_loc_operands (loc);
+      output_loc_operands (loc, for_eh);
     }
 }

@@ -5361,9 +5387,18 @@ output_loc_operands_raw (dw_loc_descr_ref loc)
       }
       break;

+    case DW_OP_regx:
+      {
+    unsigned r = DWARF2_FRAME_REG_OUT (val1->v.val_unsigned, 1);
+    gcc_assert (size_of_uleb128 (r) 
+            == size_of_uleb128 (val1->v.val_unsigned));
+    fputc (',', asm_out_file);
+    dw2_asm_output_data_uleb128_raw (r);
+      }
+      break;
+      
     case DW_OP_constu:
     case DW_OP_plus_uconst:
-    case DW_OP_regx:
     case DW_OP_piece:
       fputc (',', asm_out_file);
       dw2_asm_output_data_uleb128_raw (val1->v.val_unsigned);
@@ -5414,10 +5449,15 @@ output_loc_operands_raw (dw_loc_descr_ref loc)
       break;

     case DW_OP_bregx:
-      fputc (',', asm_out_file);
-      dw2_asm_output_data_uleb128_raw (val1->v.val_unsigned);
-      fputc (',', asm_out_file);
-      dw2_asm_output_data_sleb128_raw (val2->v.val_int);
+      {
+    unsigned r = DWARF2_FRAME_REG_OUT (val1->v.val_unsigned, 1);
+    gcc_assert (size_of_uleb128 (r) 
+            == size_of_uleb128 (val1->v.val_unsigned));
+    fputc (',', asm_out_file);
+    dw2_asm_output_data_uleb128_raw (r);
+    fputc (',', asm_out_file);
+    dw2_asm_output_data_sleb128_raw (val2->v.val_int);
+      }
       break;

     case DW_OP_GNU_implicit_pointer:
@@ -5435,8 +5475,24 @@ output_loc_sequence_raw (dw_loc_descr_ref loc)
 {
   while (1)
     {
+      enum dwarf_location_atom opc = loc->dw_loc_opc;
       /* Output the opcode.  */
-      fprintf (asm_out_file, "%#x", loc->dw_loc_opc);
+      if (opc >= DW_OP_breg0 && opc <= DW_OP_breg31)
+    {
+      unsigned r = (opc - DW_OP_breg0);
+      r = DWARF2_FRAME_REG_OUT (r, 1);
+      gcc_assert (r <= 31);
+      opc = (enum dwarf_location_atom) (DW_OP_breg0 + r);
+    }
+      else if (opc >= DW_OP_reg0 && opc <= DW_OP_reg31)
+    {
+      unsigned r = (opc - DW_OP_reg0);
+      r = DWARF2_FRAME_REG_OUT (r, 1);
+      gcc_assert (r <= 31);
+      opc = (enum dwarf_location_atom) (DW_OP_reg0 + r);
+    }
+      /* Output the opcode.  */
+      fprintf (asm_out_file, "%#x", opc);
       output_loc_operands_raw (loc);

       if (!loc->dw_loc_next)
@@ -5451,14 +5507,16 @@ output_loc_sequence_raw (dw_loc_descr_ref loc)
    description based on a cfi entry with a complex address.  */

 static void
-output_cfa_loc (dw_cfi_ref cfi)
+output_cfa_loc (dw_cfi_ref cfi, int for_eh)
 {
   dw_loc_descr_ref loc;
   unsigned long size;

   if (cfi->dw_cfi_opc == DW_CFA_expression)
     {
-      dw2_asm_output_data (1, cfi->dw_cfi_oprnd1.dw_cfi_reg_num, NULL);
+      unsigned r = 
+    DWARF2_FRAME_REG_OUT (cfi->dw_cfi_oprnd1.dw_cfi_reg_num, for_eh);
+      dw2_asm_output_data (1, r, NULL);
       loc = cfi->dw_cfi_oprnd2.dw_cfi_loc;
     }
   else
@@ -5469,7 +5527,7 @@ static void
   dw2_asm_output_data_uleb128 (size, NULL);

   /* Now output the operations themselves.  */
-  output_loc_sequence (loc);
+  output_loc_sequence (loc, for_eh);
 }

 /* Similar, but used for .cfi_escape.  */
@@ -5482,7 +5540,9 @@ output_cfa_loc_raw (dw_cfi_ref cfi)

   if (cfi->dw_cfi_opc == DW_CFA_expression)
     {
-      fprintf (asm_out_file, "%#x,", cfi->dw_cfi_oprnd1.dw_cfi_reg_num);
+      unsigned r = 
+    DWARF2_FRAME_REG_OUT (cfi->dw_cfi_oprnd1.dw_cfi_reg_num, 1);
+      fprintf (asm_out_file, "%#x,", r);
       loc = cfi->dw_cfi_oprnd2.dw_cfi_loc;
     }
   else
@@ -11075,7 +11135,7 @@ output_loc_list (dw_loc_list_ref list_head)
       gcc_assert (size <= 0xffff);
       dw2_asm_output_data (2, size, "%s", "Location expression size");

-      output_loc_sequence (curr->expr);
+      output_loc_sequence (curr->expr, 0);
     }

   dw2_asm_output_data (DWARF2_ADDR_SIZE, 0,
@@ -11153,7 +11213,7 @@ output_die (dw_die_ref die)
       else
         dw2_asm_output_data (constant_size (size), size, "%s", name);

-      output_loc_sequence (AT_loc (a));
+      output_loc_sequence (AT_loc (a), 0);
       break;

     case dw_val_class_const:

[Bug target/47324] r157762 caused g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin

[jakub at gcc dot gnu.org]

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

--- Comment #36 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-02-10 16:04:46 UTC ---
Yes (though, I'm not a dwarf2out maintainer, so you'll need to ask for
approval).

[Bug target/47324] r157762 caused g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin

[iains at gcc dot gnu.org]

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

--- Comment #37 from Iain Sandoe <iains at gcc dot gnu.org> 2011-02-10 17:40:57 UTC ---
(In reply to comment #36)
> Yes (though, I'm not a dwarf2out maintainer, so you'll need to ask for
> approval).

unfortunately, this causes problems for some PPC cases with -g ... 
.. lots of ices in rs6000_dbx_register_number () ...

will have to investigate...

[Bug target/47324] r157762 caused g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at redhat dot com

--- Comment #38 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-02-10 17:48:50 UTC ---
Wonder what do the debug consumers on PowerPC do currently...
If they actually have separate register number decoders for .debug_frame and
other .debug_* sections, or .debug_frame except for locations in
.DW_CFA_expression and for other .debug_* sections + DW_CFA_expression, or
something else.
Perhaps DW_CFA_expression isn't used that often on powerpc{,64} currently...

[Bug target/47324] r157762 caused g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin

[iains at gcc dot gnu.org]

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

--- Comment #39 from Iain Sandoe <iains at gcc dot gnu.org> 2011-02-10 18:29:46 UTC ---
(In reply to comment #38)
> Wonder what do the debug consumers on PowerPC do currently...
> If they actually have separate register number decoders for .debug_frame and
> other .debug_* sections, or .debug_frame except for locations in
> .DW_CFA_expression and for other .debug_* sections + DW_CFA_expression, or
> something else.
> Perhaps DW_CFA_expression isn't used that often on powerpc{,64} currently...

the first ICE I looked at is caused by the regno 108 (last altivec) being
translated into a large number which fails the assert at dwarf2out.c:5232.

I wonder if extended regs can validly take part in a DW_CFA_expression?

[Bug target/47324] r157762 caused g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #40 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-02-10 18:48:07 UTC ---
What happens if you replace all the instances of DWARF2_FRAME_REG_OUT in the
proposed patch with a new DWARF2_FRAME_REG_OUT_EH macro that is a no-op on
anything but i386 darwin (where is defined to DWARF2_FRAME_REG_OUT)?

[Bug target/47324] r157762 caused g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin

[jakub at gcc dot gnu.org]

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

--- Comment #41 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-02-10 18:49:08 UTC ---
Ugh, it is a mess.  DW_CFA_expression/DW_CFA_def_cfa_expression location list
comes from 3 different routines:
1) build_cfa_loc
2) build_cfa_aligned_loc
3) mem_loc_descriptor
In 1) and 2) created location lists the register numbers embedded in it are GCC
internal hard register numbers transformed using DWARF_FRAME_REGNUM(reg) (and
it relies on being those, as it analyzes them and reconstructs from them too).
So, that is something that DWARF2_FRAME_REG_OUT macro should be applied on.
Then 3) contains GCC internal hard register numbers transformed using
DBX_REGISTER_NUMBER(reg).  That is generally something that is supposed to be
usable only in .debug_* sections and DWARF2_FRAME_REG_OUT shouldn't be applied
on it.  3) happens just for REG_CFA_EXPRESSION, which is currently used only on
i386.  And then output_loc_sequence is called also from places other than
output_cfa_loc*, and those again have mem_loc_descriptor like register numbers
in it and thus shouldn't be transformed using DWARF2_FRAME_REG_OUT.

Now, if we say rs6000 just can't use REG_CFA_EXPRESSION, we can simplify things
slightly.  output_loc_sequence could have a 3 state parameter rather than bool,
-1 meaning don't use DWARF2_FRAME_REG_OUT macro, 0 use it with 0 as second
argument and 1 with 1 as second argument.  Then output_loc_sequence callers
other than output_cfa_loc would pass in -1 and output_cfa_loc would pass in
for_eh.  It is very ugly, but mainly because on those two targets we've screwed
things up.

[Bug target/47324] r157762 caused g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #42 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-02-10 19:55:37 UTC ---
The Apple linker maintainer says as far as he knows just i386 has the register
numbering schism.

[Bug target/47324] r157762 caused g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin

[iains at gcc dot gnu.org]

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

--- Comment #43 from Iain Sandoe <iains at gcc dot gnu.org> 2011-02-10 20:13:59 UTC ---
Created attachment 23302
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23302
tri-stated output_loc_sequence

I agree it's ugly, we need to find a Better Way for 4.7 ...

.. what to do about raw?

[Bug target/47324] r157762 caused g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin

[iains at gcc dot gnu.org]

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

--- Comment #44 from Iain Sandoe <iains at gcc dot gnu.org> 2011-02-10 20:16:42 UTC ---
(In reply to comment #43)
> Created attachment 23302 [details]
> tri-stated output_loc_sequence
> 
> I agree it's ugly, we need to find a Better Way for 4.7 ...
> 
> .. what to do about raw?

I can test on powerpc-darwin (so far, looks OK) 
-- but I don't have a ppc-linux install - and I assume that this would affect
all rs6000 targets.

[Bug target/47324] r157762 caused g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin

[jakub at gcc dot gnu.org]

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

--- Comment #45 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-02-10 20:24:54 UTC ---
The raw stuff in the patch looks ok to me, it is always used just in the for_eh
case.  The for_eh argument to output_loc_operands should be still also *_skip
and you shouldn't adjust DW_OP_regx and DW_OP_bregx argument if the parameter
is -1.  And the for_eh_or_skip argument needs documentation in the comment
above the function.
Yeah, on powerpc*-* all targets are affected I think, but I guess it is enough
if you test on i?86-*-darwin and powerpc*-*-darwin, one representative for each
of the DWARF2_FRAME_REG_OUT special targets is enough.  On other targets the
macro is a nop...

[Bug target/47324] r157762 caused g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin

[iains at gcc dot gnu.org]

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

Iain Sandoe <iains at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #23302|0                           |1
        is obsolete|                            |

--- Comment #46 from Iain Sandoe <iains at gcc dot gnu.org> 2011-02-10 20:45:00 UTC ---
Created attachment 23303
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23303
tri-state output_loc_sequence V2

yeah, obv. really, too many things on the go today, (poor excuse, but)...

If this builds OK - I'll reg-strap {i386,powerpc}-darwin9 overnight.

I'd welcome any editing of the comments -- hard to think of a succinct way to
express the problem.

[Bug target/47324] r157762 caused g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin

[dominiq at lps dot ens.fr]

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

--- Comment #47 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2011-02-11 07:47:52 UTC ---
> Created attachment 23303 [details]
> tri-state output_loc_sequence V2

I have updated revisions 170022 on x86_64-apple-darwin10.6.0 and
powerpc-apple-darwin9 with the patch attachment 23303. On
x86_64-apple-darwin10.6.0 the patch fixes this PR without regression. On
powerpc-apple-darwin9, I am currently testing gfortran without anything
obviously wrong for gcc and g++. I am bootstrapping revision 170044 on
x86_64-apple-darwin10.6.0 and I'll do it for powerpc-apple-darwin9 as soon as
the testing is finished (probably tonight).

Thanks for the patch.

[Bug target/47324] r157762 caused g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #48 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-02-11 10:09:15 UTC ---
Also eliminates PR47324 on x86_64-apple-darwin10 without additional regressions
for --enable-build-with-cxx BOOT_CFLAGS="-g -O3" CFLAGS_FOR_TARGET="-g -O3"
CXXFLAGS_FOR_TARGET="-g -O3".

http://gcc.gnu.org/ml/gcc-testresults/2011-02/msg01176.html

[Bug target/47324] r157762 caused g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin

[iains at gcc dot gnu.org]

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

--- Comment #49 from Iain Sandoe <iains at gcc dot gnu.org> 2011-02-11 10:13:13 UTC ---
(In reply to comment #48)
> Also eliminates PR47324 on x86_64-apple-darwin10 without additional regressions
> for --enable-build-with-cxx BOOT_CFLAGS="-g -O3" CFLAGS_FOR_TARGET="-g -O3"
> CXXFLAGS_FOR_TARGET="-g -O3".
> 
> http://gcc.gnu.org/ml/gcc-testresults/2011-02/msg01176.html

thanks guys, also OK on i386-darwin9 (and powerpc-darwin9 as a second point).

I will post shortly -- also doing a stage1 on i386-linux just in case.

[Bug target/47324] r157762 caused g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin

[iains at gcc dot gnu.org]

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

--- Comment #50 from Iain Sandoe <iains at gcc dot gnu.org> 2011-02-12 16:52:01 UTC ---
Author: iains
Date: Sat Feb 12 16:51:58 2011
New Revision: 170077

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170077
Log:

gcc:
    PR target/47324
    * dwarf2out.c (output_cfa_loc): When required, apply the
    DWARF2_FRAME_REG_OUT macro to adjust register numbers.
    (output_loc_sequence): Likewise.
    (output_loc_operands_raw): Likewise.
    (output_loc_sequence_raw): Likewise.
    (output_cfa_loc): Likewise.
    (output_loc_list): Suppress register number adjustment when
    calling output_loc_sequence()
    (output_die): Likewise.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/dwarf2out.c

[Bug target/47324] r157762 caused g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin

[mrs at gcc dot gnu.org]

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

mrs@gcc.gnu.org <mrs at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #51 from mrs at gcc dot gnu.org <mrs at gcc dot gnu.org> 2011-02-13 01:48:26 UTC ---
Fixed.  Thanks a ton Iain.

[Bug target/47324] r157762 caused g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #52 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-02-13 16:31:36 UTC ---
Even those this problem appears latent on gcc-4_5-branch, the problematic code
is identical. Shouldn't we backport this for gcc 4.5.3?

[Bug target/47324] r157762 caused g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin

[mrs at gcc dot gnu.org]

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

mrs@gcc.gnu.org <mrs at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |4.6.0

--- Comment #53 from mrs at gcc dot gnu.org <mrs at gcc dot gnu.org> 2011-02-13 18:38:20 UTC ---
I'd rather know two things, that we have a lot of time on the new code and it
works fine znd why the branch doesn't have the problem in similar cases.  If
one cannot find a bug to fix, a bug might not exist.  If it doesn't exist,
there is nothing to fix.

[Bug target/47324] r157762 caused g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #54 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-02-13 18:56:48 UTC ---
(In reply to comment #53)
> I'd rather know two things, that we have a lot of time on the new code and it
> works fine znd why the branch doesn't have the problem in similar cases.  If
> one cannot find a bug to fix, a bug might not exist.  If it doesn't exist,
> there is nothing to fix.

Looking at the x86_64-apple-darwin10 results on gcc-testresults, PR47324
appeared after r162035 and by r162199. I can do a regression hunt through those
to see which exact commit triggered them and verify that this hasn't been
backported to gcc-4_5-branch.

[Bug target/47324] r157762 caused g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #55 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-02-13 20:29:49 UTC ---
It appears that is was present at r162030 and the r162035 used
--enable-build-with-cxx...

http://gcc.gnu.org/ml/gcc-testresults/2010-07/msg00872.html
http://gcc.gnu.org/ml/gcc-testresults/2010-07/msg00898.html

which indicates it certainly can go latent.

[Bug target/47324] r157762 caused g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #56 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-02-13 23:29:01 UTC ---
A regression hunt reveals the PR47324 was actually triggered by...

r160124 | hubicka | 2010-06-01 17:55:49 -0400 (Tue, 01 Jun 2010) | 4 lines

        * ipa-pure-const.c (local_pure_const): Do NORETURN discovery.

        * testsuite/gcc.dg/noreturn-8.c: New testcase.

which explains why it is latent on gcc-4_5-branch. The question remains if that
is a
sufficient reason to not fix the obviously incorrect code residing there for
gcc 4.5.3.
That is, are we certain that the testsuite is sufficient to capture any
potential failures from this
incomplete code in dwarf2out.c.

[Bug target/47324] r160124 caused g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #57 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-02-14 03:21:00 UTC ---
Created attachment 23330
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23330
assembly for eh-alloca.1 at r160123 with -O3 -g (working)

[Bug target/47324] r160124 caused g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #58 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-02-14 03:21:47 UTC ---
Created attachment 23331
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23331
assembly for eh-alloca.1 at r160124 with -O3 -g (failing)

[Bug target/47324] r160124 caused g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #59 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-02-14 03:23:19 UTC ---
Created attachment 23332
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23332
diff in assembly for eh-alloca.1 at r160123 vs r160124 both with -O3 -g

[Bug target/47324] r160124 caused g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #60 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-02-14 11:56:59 UTC ---
Backport for gcc 4.5.3...

http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00869.html
http://gcc.gnu.org/ml/gcc-testresults/2011-02/msg01536.html