Reverting r155171 allows gcc-4.4-20091215 to build a working libjava again.

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155171
Log:
2009-12-11  Ramana Radhakrishnan  <ramana.radhakrishnan@arm.com>

        PR target/42263
        2009-08-11  Andrew Haley  <aph@redhat.com>
        * config/arm/arm.c (arm_init_libfuncs): Add __sync_synchronize.

I suspect ARM's "static libgcc has more symbols than the shared one" bug is involved here (see PR40133 and PR40134).

The correct fix is potentially a version of the fix for PR40133 / PR40134 for arm-linux-gnueabi. Looking at this.

Yes, unless Matthias has a good explanation and fix for what's going on, those changes should be immediately reverted, I will do that anyway in 3-4 days max.

Note, however, that something is definitely wrong in the analysis: PR40133 and PR40134 have been fixed **only in mainline**, thus per se those changes cannot be involved in a breakage involving 4_4-branch. As far as libstdc++ is concerned, in particular, in 4_4-branch we are not trying to do link-test anywhere, we cannot make mistakes about static libgcc symbols. Still, I'm seeing something puzzling and alarming here from the point of view of those issues and I would recommend Matthias to also have a look.

(In reply to comment #4)
> Note, however, that something is definitely wrong in the analysis: PR40133 and
> PR40134 have been fixed **only in mainline**, thus per se those changes cannot
> be involved in a breakage involving 4_4-branch.

I believe it's the *absence* of the PR40134 fix on 4_4-branch that's causing the backport of __sync_synchronize() support to regress. I'm currently testing 4.4-20091215 with relevant bits of PR40134 backported (r151568 + r152975): that cured the build failure, but the testsuite run is not yet finished.

Thus you mean only 40134 is involved. Because 40133 *assumes* that on the relevant linux targets there are no surprises with shared vs static libgcc. 

In general, I want to make sure nothing changes in the compiler-proper that breaks the assumptions of 40133, which then would have to be reverted. For now mainline seems still ok, I think Matthias tests regularly those targets.

(In reply to comment #5)
> I believe it's the *absence* of the PR40134 fix on 4_4-branch that's causing
> the backport of __sync_synchronize() support to regress. I'm currently testing
> 4.4-20091215 with relevant bits of PR40134 backported (r151568 + r152975): that
> cured the build failure, but the testsuite run is not yet finished.

The testsuite run now finished with no regressions compared to 4.4 snapshots from before this regression.

Created attachment 19399 [details]
pr40134 for 4.4

Mikael's analysis seems to be right; the __sync_synchronise backport requires the backport of pr40134. I'm attaching the patch that I do apply for the Debian gcc-4.4 build, based on Jakub's initial patch including the powerpc chunk and the bits for arm and parisc.

Good. To clarify, I have no personal objections to that specific kind of backport to 4_4-branch... seems a bit late, but still, since the basic issue is a wrong-code... up to the maintainers.

Matthias, your Debian patch includes the following, which is not part of the trunk fix for PR40134 but instead appears to be a fragment from an early version of the PR41175/PR40677 fix (which seems to depend on PR40134):

--- a/src/gcc/config/rs6000/rs6000.c    (revision 151558)
+++ b/src/gcc/config/rs6000/rs6000.c    (working copy)
@@ -15869,7 +15869,7 @@
 no_global_regs_above (int first, bool gpr)
 {
   int i;
-  for (i = first; i < gpr ? 32 : 64 ; i++)
+  for (i = first; i < (gpr ? 32 : 64) ; i++)
     if (global_regs[i])
       return false;
   return true;

(In reply to comment #7)
> (In reply to comment #5)
> > I believe it's the *absence* of the PR40134 fix on 4_4-branch that's causing
> > the backport of __sync_synchronize() support to regress. I'm currently testing
> > 4.4-20091215 with relevant bits of PR40134 backported (r151568 + r152975): that
> > cured the build failure, but the testsuite run is not yet finished.
> 
> The testsuite run now finished with no regressions compared to 4.4 snapshots
> from before this regression.
> 

Can you or Matthias submit this patch to gcc-patches@gcc.gnu.org ? 

Created attachment 19413 [details]
pr40134 generic + arm bits

This is the version of the PR40134 patch I intend to submit, unless Matthias wants to submit his version. This version only adds t-slibgcc-libgcc support and enables it for arm-linux-gnueabi. Mainline and debian also enables it for some powerpc and hppa targets, I'm excluding those bits to avoid involving other targets than arm at this point. (It's easy to enable other targets later on.)

looks fine to me (but I cannot approve). I'm using this patch already for package builds without seeing regressions.

Patch submitted:
<http://gcc.gnu.org/ml/gcc-patches/2009-12/msg01192.html>

Subject: Bug 42503

Author: doko
Date: Mon Jan  4 15:13:08 2010
New Revision: 155617

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155617
Log:
2010-01-04  Mikael Pettersson  <mikpe@it.uu.se>

        PR target/42503

        Backport from mainline:

        2009-09-09  Jakub Jelinek  <jakub@redhat.com>

        * config/t-slibgcc-elf-ver (SHLIB_MAKE_SOLINK, SHLIB_INSTALL_SOLINK):
        New variables.
        (SHLIB_LINK, SHLIB_INSTALL): Use them.
        * config/t-slibgcc-libgcc: New file.

        2009-10-19  Matthias Klose  <doko@ubuntu.com>

        PR target/40134
        * config.gcc (arm*-*-linux-*eabi): Use config/t-slibgcc-libgcc.

Added:
    branches/gcc-4_4-branch/gcc/config/t-slibgcc-libgcc
Modified:
    branches/gcc-4_4-branch/gcc/ChangeLog
    branches/gcc-4_4-branch/gcc/config.gcc
    branches/gcc-4_4-branch/gcc/config/t-slibgcc-elf-ver

Is this fixed now?

Fixed now, closing.