[Bug other/51124] New: libitm failures

[Bug other/51124] New: libitm failures

[hjl.tools at gmail dot com]

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

             Bug #: 51124
           Summary: libitm failures
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: other
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: hjl.tools@gmail.com


On Linux/x86-64, revision 181353 gave

FAIL: libitm.c/clone-1.c execution test
WARNING: libitm.c++/static_ctor.C compilation failed to produce executable

On Linux/ia32:

FAIL: libitm.c/clone-1.c execution test
FAIL: libitm.c/memcpy-1.c execution test
FAIL: libitm.c/memset-1.c execution test
WARNING: libitm.c++/static_ctor.C compilation failed to produce executable

[Bug other/51124] libitm failures

[howarth at nitro dot med.uc.edu]

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

Jack Howarth <howarth at nitro dot med.uc.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |howarth at nitro dot
                   |                            |med.uc.edu

--- Comment #1 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-11-23 19:58:36 UTC ---
Did these tests ever pass on the trans-mem branch? If so could these failures
be due to an incomplete merge?

[Bug other/51124] libitm failures

[howarth at nitro dot med.uc.edu]

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

--- Comment #2 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-12-16 15:19:55 UTC ---
On x86_64-apple-darwin11, the failure of...

FAIL: libitm.c/clone-1.c execution test

at -m32/-m64 appears to be due to the -pie linker default when targeting
darwin11.
If I append -Wl,-no_pie to the compilation of the clone-1.exe testcase, the
resulting
binaries for both -m32 and -m64 execute fine. For...

/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/gcc/
/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20111215/libitm/testsuite/libitm.c/clone-1.c
-B/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/x86_64-apple-darwin11.2.0/./libitm/
-I/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/x86_64-apple-darwin11.2.0/./libitm
-I/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20111215/libitm/testsuite/..
-shared-libgcc -fmessage-length=0 -fgnu-tm -O2
-L/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/x86_64-apple-darwin11.2.0/./libitm/.libs
-litm -lm -m64 -o ./clone-1.exe

the failing PIE executable debugs in gdb (with aslr enabled) as...

gdb ./clone-1.exeGNU gdb 6.3.50-20050815 (Apple version gdb-1708) (Thu Nov  3
21:59:02 UTC 2011)Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared
libraries .... done

(gdb) set disable-aslr 0
(gdb) r
Starting program:
/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/x86_64-apple-darwin11.2.0/libitm/testsuite/clone-1.exe 
Reading symbols for shared libraries + done
Reading symbols for shared libraries ++++........................ done

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x00000001000010a8
clone_entry_compare (a=0x100001098, b=0x1000010a8) at
../../../gcc-4.7-20111215/libitm/clone.cc:105
105      if (aa->orig < bb->orig)
(gdb) bt
#0  clone_entry_compare (a=0x100001098, b=0x1000010a8) at
../../../gcc-4.7-20111215/libitm/clone.cc:105
#1  0x00007fff8ddd4894 in _qsort ()
#2  0x0000000104e388e6 in _ITM_registerTMCloneTable (xent=0x100001098, size=2)
at ../../../gcc-4.7-20111215/libitm/clone.cc:155
Current language:  auto; currently c++
(gdb) 

The remaining failures at -m64-only of...

FAIL: libitm.c/memcpy-1.c execution test
FAIL: libitm.c/memset-1.c execution test

are not solved with -Wl,-no_pie and the binaries fail with the output...

libitm: pr_undoLogCode not supported

[Bug other/51124] libitm failures

[howarth at nitro dot med.uc.edu]

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

--- Comment #3 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-12-16 15:44:36 UTC ---
Could the memcpy-1.exe/memset-1.exe execution failures be related to those seen
on i386-pc-solaris2.9?

http://gcc.gnu.org/ml/gcc-testresults/2011-12/msg01261.html

We also seem to share the failure of...

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

on darwin11 with i386-pc-solaris2.9.

[Bug other/51124] libitm failures

[howarth at nitro dot med.uc.edu]

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

--- Comment #4 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-12-16 17:21:57 UTC ---
Xcode 4.2 on x86_64-apple-darwin10, produces the failures...

Running target unix/-m32
FAIL: libitm.c/memcpy-1.c execution test
FAIL: libitm.c/memset-1.c execution test
FAIL: libitm.c++/eh-1.C execution test
WARNING: libitm.c++/static_ctor.C compilation failed to produce executable

Running target unix/-m64
FAIL: libitm.c++/eh-1.C execution test
WARNING: libitm.c++/static_ctor.C compilation failed to produce executable

where memcpy-1.exe and memset-1.exe both fail with the output...

libitm: pr_undoLogCode not supported

The failing eh-1.C execution test at -m32 back traces in gdb as...

(gdb) r
Starting program:
/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/x86_64-apple-darwin10.8.0/libitm/testsuite/eh-1.exe 
Reading symbols for shared libraries ++++. done

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
0x0000a074 in ITM_WU4 (this=<value temporarily unavailable, due to
optimizations>, ptr=0x0, val=1) at
../../../../gcc-4.7-20111216/libitm/method-serial.cc:90
90      CREATE_DISPATCH_METHODS(virtual, )
(gdb) bt
#0  0x0000a074 in ITM_WU4 (this=<value temporarily unavailable, due to
optimizations>, ptr=0x0, val=1) at
../../../../gcc-4.7-20111216/libitm/method-serial.cc:90
#1  0x000058d3 in _ITM_WU4 (ptr=0x0, val=1) at
../../../../gcc-4.7-20111216/libitm/barrier.cc:43
#2  0x00001b6d in f2 ()
#3  0x00001bbe in main ()

[Bug other/51124] libitm failures

[ro at gcc dot gnu.org]

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

Rainer Orth <ro at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2011-12-16
                 CC|                            |ro at gcc dot gnu.org
     Ever Confirmed|0                           |1

--- Comment #5 from Rainer Orth <ro at gcc dot gnu.org> 2011-12-16 17:36:26 UTC ---
Right, I'm seeing exactly the same output for libitm.c/memcpy-1.c and
libitm.c/memset-1.c on 32-bit Solaris 8-11/x86, and also in an
i686-unknown-linux-gnu
bootstrap with --enable-targets=all.

  Rainer

[Bug other/51124] libitm failures

[howarth at nitro dot med.uc.edu]

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

--- Comment #6 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-12-16 17:45:38 UTC ---
(In reply to comment #5)
> Right, I'm seeing exactly the same output for libitm.c/memcpy-1.c and
> libitm.c/memset-1.c on 32-bit Solaris 8-11/x86, and also in an
> i686-unknown-linux-gnu
> bootstrap with --enable-targets=all.
> 
>   Rainer

What sort of backtrace in gdb do you get on 32-bit Solaris 8-11/x86 for the
execution failure
in the libitm.c++/eh-1.C test?

[Bug other/51124] libitm failures

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> 2011-12-16 17:55:22 UTC ---
> What sort of backtrace in gdb do you get on 32-bit Solaris 8-11/x86 for the
> execution failure
> in the libitm.c++/eh-1.C test?

This one:

[Thread debugging using libthread_db enabled]
terminate called after throwing an instance of 'int'
terminate called recursively
[New Thread 1 (LWP 1)]

Program received signal SIGABRT, Aborted.
[Switching to Thread 1 (LWP 1)]
0xfffffd7fff26b82a in _lwp_kill () from /lib/64/libc.so.1
(gdb) where
#0  0xfffffd7fff26b82a in _lwp_kill () from /lib/64/libc.so.1
#1  0xfffffd7fff260009 in thr_kill () from /lib/64/libc.so.1
#2  0xfffffd7fff211169 in raise () from /lib/64/libc.so.1
#3  0xfffffd7fff1e7bd2 in abort () from /lib/64/libc.so.1
#4  0xfffffd7ff93e6201 in __gnu_cxx::__verbose_terminate_handler ()
    at /vol/gcc/src/hg/trunk/local/libstdc++-v3/libsupc++/vterminate.cc:50
#5  0xfffffd7ff93e3649 in __cxxabiv1::__terminate (handler=<optimized out>)
    at /vol/gcc/src/hg/trunk/local/libstdc++-v3/libsupc++/eh_terminate.cc:40
#6  0xfffffd7ff93e3693 in std::terminate ()
    at /vol/gcc/src/hg/trunk/local/libstdc++-v3/libsupc++/eh_terminate.cc:50
#7  0xfffffd7ff93e390e in __cxxabiv1::__cxa_rethrow ()
    at /vol/gcc/src/hg/trunk/local/libstdc++-v3/libsupc++/eh_throw.cc:116
#8  0xfffffd7ff93e61c5 in __gnu_cxx::__verbose_terminate_handler ()
    at /vol/gcc/src/hg/trunk/local/libstdc++-v3/libsupc++/vterminate.cc:80
#9  0xfffffd7ff93e3649 in __cxxabiv1::__terminate (handler=<optimized out>)
    at /vol/gcc/src/hg/trunk/local/libstdc++-v3/libsupc++/eh_terminate.cc:40
#10 0xfffffd7ff93e2699 in __cxa_call_terminate (ue_header=0x41bb90)
    at /vol/gcc/src/hg/trunk/local/libstdc++-v3/libsupc++/eh_call.cc:56
#11 0xfffffd7ff93e3243 in __cxxabiv1::__gxx_personality_v0 (
    version=<optimized out>, actions=6, exception_class=<optimized out>, 
    ue_header=0x41bb90, context=0xfffffd7fffdff478)
    at /vol/gcc/src/hg/trunk/local/libstdc++-v3/libsupc++/eh_personality.cc:665
#12 0xfffffd7fff26a171 in _Unwind_RaiseException_Body () from /lib/64/libc.so.1
#13 0xfffffd7fff26a2a5 in _Unwind_RaiseException () from /lib/64/libc.so.1
#14 0xfffffd7ff93e38a9 in __cxxabiv1::__cxa_throw (obj=<optimized out>, 
    tinfo=<optimized out>, dest=<optimized out>)
    at /vol/gcc/src/hg/trunk/local/libstdc++-v3/libsupc++/eh_throw.cc:78
#15 0x000000000040313a in f1 ()
    at /vol/gcc/src/hg/trunk/local/libitm/testsuite/libitm.c++/eh-1.C:12
#16 0x0000000000403069 in f2 ()
    at /vol/gcc/src/hg/trunk/local/libitm/testsuite/libitm.c++/eh-1.C:18
#17 0x00000000004030b4 in main ()
    at /vol/gcc/src/hg/trunk/local/libitm/testsuite/libitm.c++/eh-1.C:29

This happens when configuring with gas, which does understand the .cfi
directives.  I think (but cannot easily verify) that the error doesn't
occur when using as instead, which is unexpected.

    Rainer

[Bug other/51124] libitm failures

[torvald at gcc dot gnu.org]

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

torvald at gcc dot gnu.org changed:

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

--- Comment #8 from torvald at gcc dot gnu.org 2012-01-09 10:06:53 UTC ---
Can this be closed?

clone-1.c works for me on x86_64 at least, what about the other
architectures/platforms?

static_ctor.C is now PR 51173

[Bug other/51124] libitm failures

[dominiq at lps dot ens.fr]

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

--- Comment #9 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2012-01-09 10:23:06 UTC ---
libitm.c/memcpy-1.c and memset-1.c are still failing in 32 bit mode on
*86*-*-*. From
http://glutton.geoffk.org/HEAD/native-logsum/i686-pc-linux-gnu/libitm/testsuite/libitm.log.gzip
, the failure is

libitm: pr_undoLogCode not supported
FAIL: libitm.c/memcpy-1.c execution test

I also see that on x86_64-apple-darwin10. This comes from line 163 of
libitm/beginend.cc

 // ??? pr_undoLogCode is not properly defined in the ABI. Are barriers
  // omitted because they are not necessary (e.g., a transaction on thread-
  // local data) or because the compiler thinks that some kind of global
  // synchronization might perform better?
  if (unlikely(prop & pr_undoLogCode))
    GTM_fatal("pr_undoLogCode not supported");

[Bug other/51124] libitm failures

[iains at gcc dot gnu.org]

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

--- Comment #10 from Iain Sandoe <iains at gcc dot gnu.org> 2012-01-09 10:55:06 UTC ---
Just for once, all the tests pass on powerpc-darwin9 (m32 & m64) [last tested
182949].

[Bug other/51124] libitm failures

[patrick.marlier at gmail dot com]

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

--- Comment #11 from Patrick Marlier <patrick.marlier at gmail dot com> 2012-01-09 14:27:18 UTC ---
> libitm.c/memcpy-1.c and memset-1.c are still failing in 32 bit mode on
*86*-*-*.
Fix proposed here: http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01784.html
Torvald, what was decided about the API?

[Bug other/51124] libitm failures

[torvald at gcc dot gnu.org]

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

torvald at gcc dot gnu.org changed:

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

--- Comment #12 from torvald at gcc dot gnu.org 2012-01-09 15:03:37 UTC ---
So the variadic-args vs. regparm(2) issue is the only blocker here?

There's no decision yet about this one so far, AFAIK.  As I said before,
combining the vararg with regparm seemed to be a thought-through decision, so
the question is really whether it makes sense conceptually and is just not
implemented properly in GCC, or whether the combination doesn't make sense at
all and we should drop regparm(2) from _ITM_beginTransaction.

[Bug other/51124] libitm failures

[patrick.marlier at gmail dot com]

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

--- Comment #13 from Patrick Marlier <patrick.marlier at gmail dot com> 2012-01-09 15:22:45 UTC ---
As posted here http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01804.html, GCC
explicitly change the calling convention to stdcall when variable arguments in
x86/32 bits mode. So I am sure a calling convention document specifies that
even if I cannot find it.

[Bug other/51124] libitm failures

[patrick.marlier at gmail dot com]

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

--- Comment #14 from Patrick Marlier <patrick.marlier at gmail dot com> 2012-01-09 16:52:47 UTC ---
>From http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html
regparm (number)
... Functions that take a variable number of arguments will continue to be
passed all of their arguments on the stack.

>From IRC: Do you know if variadic function and regparm(2) are compatible on
x86/32?
Quoting ktietz:
no they aren't (at least for IA-32).  As variadic functions require
reserved-stack-region, as va_list is in fact a stack-pointer for this target.
there might be case variadic could work, but these are exceptions. It depends
on signature. For regparm(2) the varidic would need to be at the 4th argument,
as va_start need prior argument to get proper stack-location. But this is just
a special-case.
it is a consequence of the way variadic is defined for IA-32 targets.
if calling-conventions using register(s) for argument passing, we would need to
know amount of variable part on runtime to calculate stack-clone region for it.
 In fact this would be for IA-32 possible, if function has pascal argument
ordering.

The variadic-args vs. regparm(2) issue is the blocker for
memcpy-1.c/memset-1.c.
No clue for clone-1.c since I cannot reproduce.
The eh-1.C on darwin seems to be a problem with XCode 4+
(http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00329.html). Probably a different
PR should be filled.

Patrick.

[Bug other/51124] libitm failures

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez <aldyh at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |aldyh at gcc dot gnu.org
         Resolution|                            |WONTFIX

--- Comment #15 from Aldy Hernandez <aldyh at gcc dot gnu.org> 2012-01-10 17:53:25 UTC ---
Folks, I am going to close this PR since it is a potpourri of failures across
different architectures, some of which have already been fixed.

If there are still issues to be resolved in the libitm testsuite, please file a
separate PR with a distinct failure that can be fixed individually.

[Bug other/51124] libitm failures

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #16 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> 2012-01-11 11:16:56 UTC ---
> --- Comment #15 from Aldy Hernandez <aldyh at gcc dot gnu.org> 2012-01-10 17:53:25 UTC ---
> Folks, I am going to close this PR since it is a potpourri of failures across
> different architectures, some of which have already been fixed.
>
> If there are still issues to be resolved in the libitm testsuite, please file a
> separate PR with a distinct failure that can be fixed individually.

I've now filed

other/51822    libitm.c++/eh-1.C FAILs

for that failure on Solaris (and probably others) (still using other for
lack of a libitm category).

    Rainer

[Bug other/51124] libitm failures

[dominiq at lps dot ens.fr]

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

--- Comment #17 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2012-01-11 21:45:35 UTC ---
> --- Comment #15 from Aldy Hernandez <aldyh at gcc dot gnu.org> 2012-01-10 17:53:25 UTC ---
> Folks, I am going to close this PR since it is a potpourri of failures across
> different architectures, some of which have already been fixed.
>
> If there are still issues to be resolved in the libitm testsuite, please file a
> separate PR with a distinct failure that can be fixed individually.

I've now filed

other/51830 - FAIL: libitm.c/mem(cpy|set)-1.c execution test