Libitm issues porting to POWER8 HTM

[Peter Bergner]

I'm currently implementing support for hardware transactional memory in
the rs6000 backend for POWER8.  Things seem to be mostly working, but I
have run into a few issues I'm wondering whether other people are seeing.

For me, all of the libitm execution test cases in libitm/testsuite/libitm.c/
compile and execute without error, except for reentrant.c, which hangs for me.
My gdb hasn't been ported to support HTM on Power yet, so debugging has been
slow, but what I've learned is, that my tbegin. instruction succeeds, but I
fail the test (meaning someone has the write lock) at beginend.cc:200:

if (unlikely(serial_lock.is_write_locked()))
  htm_abort();

...so we abort the transaction.  The failure is not persistent, so we do
not break out of the loop due to:

if (!htm_abort_should_retry(ret))
  break;

We then fall into the following code, where we hang trying to get the
read lock:

serial_lock.read_lock(tx);

I have yet to track down who has the write lock and why, but I am working
towards that.  Talking with Andreas, he said he is seeing the same failure
on S390, so I'm wondering whether this might be a generic libitm issue
and it might hit Intel too.  Does anyone know whether this executes correctly
on Intel hardware with RTM?  I'll note that if I hack the call to
htm_abort_should_retry(ret) so that we break of of the loop and fallback
to SW TM, then the test case executes correctly.


Secondly, many of the test cases in libitm/testsuite/libitm.c++/ fail
to build for me when I use -static with the following error:

/home/bergner/gcc/install/gcc-fsf-mainline-htm/lib64/libitm.a(method-serial.o):(.opd+0x1098):
 multiple definition of `__cxa_pure_virtual'
/home/bergner/gcc/install/gcc-fsf-mainline-htm/lib64/libstdc++.a(pure.o):(.opd+0x0):
 first defined here
collect2: error: ld returned 1 exit status

The comment in method-serial.cc says it's trying to avoid a dependency
on libstdc++.  Is the __cxa_pure_virtual workaround in method-serial.cc
supposed to work with -static?


Finially, when compiling (static or non-static) static-ctor.C, I'm seeing:

/home/bergner/gcc/gcc-fsf-mainline-htm/libitm/testsuite/libitm.c++/static_ctor.C:12:18:
 error: unsafe function call 'void __cxa_guard_release(long long int*)' within 
'transaction_safe' function
   static int y = x;
  ^
/home/bergner/gcc/gcc-fsf-mainline-htm/libitm/testsuite/libitm.c++/static_ctor.C:12:18:
 error: unsafe function call 'int __cxa_guard_acquire(long long int*)' within 
'transaction_safe' function

Does x86 not get calls to __cxa_guard_acquire and __cxa_guard_release for
this access, so it doesn't see this error?  To be honest, I'm not sure
what we're supposed to do with this error.


Peter

Re: Instruction scheduling question

[Steve Ellcey]

On Sat, 2013-06-15 at 00:06 +0200, Eric Botcazou wrote:
> > The part of the scheduling change that I am interested in is the change in
> > where the addiu instruction occurs and the related changes from the positive
> > offsets to the negative offsets.  Can anyone tell me where the code that
> > decides to do that is?  Extra bonus points for any answer not including the
> > word 'reload'.
> 
> Very likely in sched-deps.c:find_modifiable_mems and related functions.

That looks like the right place.  It seems to be triggered by the
DONT_BREAK_DEPENDENCIES flag in the haifa scheduler.  As an experiment,
I added DONT_BREAK_DEPENDENCIES to the scheduling flags and it no longer
did that transformation.

Thanks.

Steve Ellcey
sell...@mips.com

Re: Instruction scheduling question

[Eric Botcazou]

> The part of the scheduling change that I am interested in is the change in
> where the addiu instruction occurs and the related changes from the positive
> offsets to the negative offsets.  Can anyone tell me where the code that
> decides to do that is?  Extra bonus points for any answer not including the
> word 'reload'.

Very likely in sched-deps.c:find_modifiable_mems and related functions.

-- 
Eric Botcazou

Instruction scheduling question

[Steve Ellcey]

I have an instruction scheduling question I was hoping someone could help me
with.  Specifically, I am trying to figure out where and how GCC is deciding
to move the add of a constant to a register above the use of that register and
then changing the register usage by change the offsets associated with it.

For example, I am compiling the following memcpy code for MIPS:

void *memcpy_word_ptr(int * __restrict d, int * __restrict s, unsigned int n )
{
  int i;
  for(i=0; i

Re: Hurd port for GCC Go

[Svante Signell]

On Fri, 2013-06-14 at 16:42 +0200, Thomas Schwinge wrote:
> Hi!
> 
> On Thu, 13 Jun 2013 10:39:58 +0200, I wrote:
> > On Wed, 12 Jun 2013 15:36:39 +0200, Svante Signell 
> >  wrote:
> > > On Tue, 2013-06-11 at 10:31 +0200, Thomas Schwinge wrote:
> > > > On Fri, 07 Jun 2013 11:14:31 +0200, Svante Signell 
> > > >  wrote:
> > > > > Attached are patches to enable gccgo to build properly on Debian
> > > > > GNU/Hurd on gcc-4.7 (4.7.3-4).
> > > > 
> > > > Thanks!  I've begun integrating them into my GCC tree (based on upstream
> > > > GCC trunk, so some changes to be done to your patches), and get it in a
> > > > state for Fotis to base his GSoC work on.
...
> I have now pushed my working branch to tschwinge/t/hurd/go, and will
> update this from time to time, both for integrating further changes (my
> own as well as those that you send me), and merge in GCC trunk changes.
> On that branch, use something like »git diff :/refs/top-bases/baseline«
> to diff your working tree against the branch's base.  When reviewing the
> commit history on that branch, it may be helpful to exclude any bulk
> merges from trunk, so use something like »git log HEAD ^origin/trunk«.
> 
> Fotis and Svante, please base any futher work for the Hurd port for GCC
> Go on that branch.  Send patches by email, for now.
> 
> > I got as far as having GCC Go compiling with GCC trunk sources; more to
> > come later.

Sorry, I'm not fluent in git. Which command to use to check out your
branch tschwinge/t/hurd/go? Cannot find it at
http://git.savannah.gnu.org/cgit/hurd/glibc.git/

GNU Tools Cauldron 2013 - Schedule

[Diego Novillo]

An update on this year's Cauldron.

The schedule is now available at http://gcc.gnu.org/wiki/cauldron2013

We will start on Fri 12/Jul at 19:00.  Presentations will run Sat
all day and Sun until about 17:00.

We have a very packed schedule, so it is unlikely that we will be
able to add more presentations. However, we will have additional
rooms for impromptu meetings, if needed.


Diego.

Re: Hurd port for GCC Go

[Thomas Schwinge]

Hi!

On Thu, 13 Jun 2013 10:39:58 +0200, I wrote:
> On Wed, 12 Jun 2013 15:36:39 +0200, Svante Signell  
> wrote:
> > On Tue, 2013-06-11 at 10:31 +0200, Thomas Schwinge wrote:
> > > On Fri, 07 Jun 2013 11:14:31 +0200, Svante Signell 
> > >  wrote:
> > > > Attached are patches to enable gccgo to build properly on Debian
> > > > GNU/Hurd on gcc-4.7 (4.7.3-4).
> > > 
> > > Thanks!  I've begun integrating them into my GCC tree (based on upstream
> > > GCC trunk, so some changes to be done to your patches), and get it in a
> > > state for Fotis to base his GSoC work on.
> > 
> > Where to find your GCC tree?
> 
> Only locally at the moment; will find a place to publish it.  As the .git
> directory weighs in the order of 1 GiB, I don't just want to push that
> onto darnassus (for example); even if we told people to first clone the
> upstream Git repository and only then add darnassus as an additional
> remote, I bet some would forget doing that.  Hmm, it seems that I might
> be able to host Git branches upstream, so I'll explore that:
> .

I have now pushed my working branch to tschwinge/t/hurd/go, and will
update this from time to time, both for integrating further changes (my
own as well as those that you send me), and merge in GCC trunk changes.
On that branch, use something like »git diff :/refs/top-bases/baseline«
to diff your working tree against the branch's base.  When reviewing the
commit history on that branch, it may be helpful to exclude any bulk
merges from trunk, so use something like »git log HEAD ^origin/trunk«.

Fotis and Svante, please base any futher work for the Hurd port for GCC
Go on that branch.  Send patches by email, for now.

> I got as far as having GCC Go compiling with GCC trunk sources; more to
> come later.


> > Also I had problems to tracing this commit:
> > .
> > I did not find anything related to context_functions at
> > http://git.savannah.gnu.org/cgit/hurd/glibc.git/
> 
> Follow »[...]« in the Branches section to see all branches.  Anyway, it's
> a TopGit branch,
> , so for
> getting a patch out of that, you'll need to diff the top of that branch
> against its base branch, using »tg patch t/context_functions« if you have
> TopGit installed, or something like »git diff
> top-bases/t/context_functions t/context_functions« manually.
> 
> > Furthermore, for testing purposes, is it straight-forward to add the new
> > functions getcontext/setcontext/makecontext*/movecontext to the debian
> > sources, e.g. 2.13-39+hurd.3 or 2.17-6 (when that is released?).
> 
> It is, and Samuel is already building 2.17-3+hurd.4 packages, so you
> might just wait for these to appear on debian-ports.

These packages are available now.  Thanks Samuel!


Grüße,
 Thomas


pgp93l2K5nxkI.pgp
Description: PGP signature

Re: [GCC PR55056] Re: [RFC patch] testsuite: Workaround issues with GCC 4.8.0pre + gdb.trace new KFAIL

[Jan Kratochvil]

On Fri, 14 Jun 2013 15:02:47 +0200, Thomas Schwinge wrote:
> On Sun, 3 Feb 2013 18:27:21 +0100, Jan Kratochvil  
> wrote:
> > gdb/testsuite/
> > 2013-02-02  Jan Kratochvil  
> > 
> > Workaround GCC PR debug/55056 and GDB PR server/15081.
> > * gdb.base/restore.c (caller3): Protect l1 by GCC_PR_55056 #ifdef.
> > (caller4): Protect l1 and l2 by GCC_PR_55056 #ifdef.
> > (caller5): Protect l1, l2 and l3 by GCC_PR_55056 #ifdef.
> > * gdb.base/restore.exp: New variable opts.  Test caller3, caller4 and
> > caller5 for l1, l2 and l3.  New prepare_for_testing.
> > * gdb.base/store.c (wack_longest, wack_float, wack_double)
> > (wack_doublest): Protect l and r by GCC_PR_55056 #ifdef.
> > * gdb.base/store.exp: New variable opts.  Test longest, float, double
> > and doublest functions for l and r.  New prepare_for_testing.
> > * gdb.trace/collection.c (reglocal_test_func): Protect locf and locd by
> > GCC_PR_55056 #ifdef.  Protect locar by GDB_PR_15081 #ifdef.
> > * gdb.trace/unavailable.c: Likewise.
> > * gdb.trace/collection.exp: New variable opts.  Test reglocal_test_func
> > for locf, locd and locar.  New prepare_for_testing.
> > (gdb_collect_locals_test): Increase list size to 43.
> > * gdb.trace/unavailable.exp: Likewise.
> 
> As far as I can tell, no consensus has yet been reached about the
> approach to fix this issue discussed in this thread.  (I have not looked
> at the proposed patch in detail.)

I have found now I posted the testsuite workaround for GDB
http://sourceware.org/ml/gdb-patches/2013-01/msg00688.html
but it has never been checked-in (neither in Fedora) which explains why you
see PASS->FAIL (which I also see on Fedora 19).


Jan

[GCC PR55056] Re: [RFC patch] testsuite: Workaround issues with GCC 4.8.0pre + gdb.trace new KFAIL

[Thomas Schwinge]

Hi!

To highlight this issue again, , now that
Debian testing has switched to GCC 4.8:

On Sun, 3 Feb 2013 18:27:21 +0100, Jan Kratochvil  
wrote:
> gdb/testsuite/
> 2013-02-02  Jan Kratochvil  
> 
>   Workaround GCC PR debug/55056 and GDB PR server/15081.
>   * gdb.base/restore.c (caller3): Protect l1 by GCC_PR_55056 #ifdef.
>   (caller4): Protect l1 and l2 by GCC_PR_55056 #ifdef.
>   (caller5): Protect l1, l2 and l3 by GCC_PR_55056 #ifdef.
>   * gdb.base/restore.exp: New variable opts.  Test caller3, caller4 and
>   caller5 for l1, l2 and l3.  New prepare_for_testing.
>   * gdb.base/store.c (wack_longest, wack_float, wack_double)
>   (wack_doublest): Protect l and r by GCC_PR_55056 #ifdef.
>   * gdb.base/store.exp: New variable opts.  Test longest, float, double
>   and doublest functions for l and r.  New prepare_for_testing.
>   * gdb.trace/collection.c (reglocal_test_func): Protect locf and locd by
>   GCC_PR_55056 #ifdef.  Protect locar by GDB_PR_15081 #ifdef.
>   * gdb.trace/unavailable.c: Likewise.
>   * gdb.trace/collection.exp: New variable opts.  Test reglocal_test_func
>   for locf, locd and locar.  New prepare_for_testing.
>   (gdb_collect_locals_test): Increase list size to 43.
>   * gdb.trace/unavailable.exp: Likewise.

As far as I can tell, no consensus has yet been reached about the
approach to fix this issue discussed in this thread.  (I have not looked
at the proposed patch in detail.)

I had already been configuring my native GDB builds with CC=gcc-4.8
CXX=g++-4.8, and naively assumed the same compiler as specified on the
configure command-line would be used for the GDB testsuite -- which is
not true, as it now turns out.  Is this to be considered a bug in the GDB
build/test harness?

Anyway, upon Debian testing/unstable just switching the default system
compiler from 4.7 to 4.8, the following new FAILs appear in my native x86
GNU/Linux and GNU/Hurd testing:

--- [...]/gdb.base2/gdb.sum
+++ [...]/gdb.base2/gdb.sum
@@ -1395,31 +1395,31 @@ PASS: gdb.base/restore.exp: run to caller3
 PASS: gdb.base/restore.exp: caller3 calls callee1; tbreak callee
 PASS: gdb.base/restore.exp: caller3 calls callee1; continue to callee
 PASS: gdb.base/restore.exp: caller3 calls callee1; return callee now
-PASS: gdb.base/restore.exp: caller3 calls callee1; return restored l1 to 
32492
+FAIL: gdb.base/restore.exp: caller3 calls callee1; return restored l1 to 
32492
 PASS: gdb.base/restore.exp: caller3 calls callee1; return restored l2 to 
32493
 PASS: gdb.base/restore.exp: caller3 calls callee1; return restored l3 to 
32494
 PASS: gdb.base/restore.exp: caller3 calls callee2; tbreak callee
 PASS: gdb.base/restore.exp: caller3 calls callee2; continue to callee
 PASS: gdb.base/restore.exp: caller3 calls callee2; return callee now
-PASS: gdb.base/restore.exp: caller3 calls callee2; return restored l1 to 
32492
+FAIL: gdb.base/restore.exp: caller3 calls callee2; return restored l1 to 
32492
 PASS: gdb.base/restore.exp: caller3 calls callee2; return restored l2 to 
32493
 PASS: gdb.base/restore.exp: caller3 calls callee2; return restored l3 to 
32494
 PASS: gdb.base/restore.exp: caller3 calls callee3; tbreak callee
 PASS: gdb.base/restore.exp: caller3 calls callee3; continue to callee
 PASS: gdb.base/restore.exp: caller3 calls callee3; return callee now
-PASS: gdb.base/restore.exp: caller3 calls callee3; return restored l1 to 
32492
+FAIL: gdb.base/restore.exp: caller3 calls callee3; return restored l1 to 
32492
 PASS: gdb.base/restore.exp: caller3 calls callee3; return restored l2 to 
32493
 PASS: gdb.base/restore.exp: caller3 calls callee3; return restored l3 to 
32494
 PASS: gdb.base/restore.exp: caller3 calls callee4; tbreak callee
 PASS: gdb.base/restore.exp: caller3 calls callee4; continue to callee
 PASS: gdb.base/restore.exp: caller3 calls callee4; return callee now
-PASS: gdb.base/restore.exp: caller3 calls callee4; return restored l1 to 
32492
+FAIL: gdb.base/restore.exp: caller3 calls callee4; return restored l1 to 
32492
 PASS: gdb.base/restore.exp: caller3 calls callee4; return restored l2 to 
32493
 PASS: gdb.base/restore.exp: caller3 calls callee4; return restored l3 to 
32494
 PASS: gdb.base/restore.exp: caller3 calls callee5; tbreak callee
 PASS: gdb.base/restore.exp: caller3 calls callee5; continue to callee
 PASS: gdb.base/restore.exp: caller3 calls callee5; return callee now
-PASS: gdb.base/restore.exp: caller3 calls callee5; return restored l1 to 
32492
+FAIL: gdb.base/restore.exp: caller3 calls callee5; return restored l1 to 
32492
 PASS: gdb.base/restore.exp: caller3 calls callee5; return restored l2 to 
32493
 PASS: gdb.base/restore.exp: caller3 calls callee5; return restored l3 to 
32494
 PASS: gdb.base/restore.exp: tbreak caller4
@@ -1427,