[Bug libitm/55648] New: [4.8 Regression] FAIL: libitm.c++/eh-1.C execution test

[Bug libitm/55648] New: [4.8 Regression] FAIL: libitm.c++/eh-1.C execution test

[dominiq at lps dot ens.fr]

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

             Bug #: 55648
           Summary: [4.8 Regression] FAIL: libitm.c++/eh-1.C execution
                    test
    Classification: Unclassified
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libitm
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: dominiq@lps.ens.fr
                CC: howarth@bromo.med.uc.edu, iains@gcc.gnu.org,
                    rth@gcc.gnu.org
              Host: x86_64-apple-darwin*
            Target: x86_64-apple-darwin*
             Build: x86_64-apple-darwin*


Between revisions 193270 (OK) and 193279 (fail, likely r193271) the test
libitm.c++/eh-1.C has started to fail with -m32/-m64:

FAIL: libitm.c++/eh-1.C execution test

I think this pr is different from pr52220. Valgrind gives

==41280== Memcheck, a memory error detector
==41280== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==41280== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==41280== Command: a.out
==41280== 
==41280== Invalid write of size 4
==41280==    at 0x1000016D3: f1() (eh-1.C:12)
==41280==    by 0x100001715: f2() (eh-1.C:18)
==41280==    by 0x100001780: main (eh-1.C:29)
==41280==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==41280== 
==41280== 
==41280== Process terminating with default action of signal 11 (SIGSEGV)
==41280==  Access not within mapped region at address 0x0
==41280==    at 0x1000016D3: f1() (eh-1.C:12)
==41280==    by 0x100001715: f2() (eh-1.C:18)
==41280==    by 0x100001780: main (eh-1.C:29)
==41280==  If you believe this happened as a result of a stack
==41280==  overflow in your program's main thread (unlikely but
==41280==  possible), you can try to increase the size of the
==41280==  main thread stack using the --main-stacksize= flag.
==41280==  The main thread stack size used in this run was 67104768.
==41280== 
==41280== HEAP SUMMARY:
==41280==     in use at exit: 7,192 bytes in 10 blocks
==41280==   total heap usage: 10 allocs, 0 frees, 7,192 bytes allocated
==41280== 
==41280== LEAK SUMMARY:
==41280==    definitely lost: 0 bytes in 0 blocks
==41280==    indirectly lost: 0 bytes in 0 blocks
==41280==      possibly lost: 24 bytes in 1 blocks
==41280==    still reachable: 7,080 bytes in 8 blocks
==41280==         suppressed: 88 bytes in 1 blocks
==41280== Rerun with --leak-check=full to see details of leaked memory
==41280== 
==41280== For counts of detected and suppressed errors, rerun with: -v
==41280== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Segmentation fault

[Bug libitm/55648] [4.8 Regression] FAIL: libitm.c++/eh-1.C execution test

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|4.4.0                       |4.8.0
   Target Milestone|---                         |4.8.0

[Bug libitm/55648] [4.8 Regression] FAIL: libitm.c++/eh-1.C execution test

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |DUPLICATE

--- Comment #1 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2012-12-14 19:54:15 UTC ---
Dup.

*** This bug has been marked as a duplicate of bug 55693 ***