[Bug middle-end/62018] New: FAIL: gcc.dg/torture/ftrapv-1.c * execution test on x86_64-apple-darwin13

[Bug middle-end/62018] New: FAIL: gcc.dg/torture/ftrapv-1.c * execution test on x86_64-apple-darwin13

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62018

            Bug ID: 62018
           Summary: FAIL: gcc.dg/torture/ftrapv-1.c * execution test on
                    x86_64-apple-darwin13
           Product: gcc
           Version: 4.10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: dominiq at lps dot ens.fr
                CC: iains at gcc dot gnu.org, rguenther at suse dot de
              Host: x86_64-apple-darwin13
            Target: x86_64-apple-darwin13
             Build: x86_64-apple-darwin13

On x86_64-apple-darwin13 I get the following failures

FAIL: gcc.dg/torture/ftrapv-1.c   -O0  execution test
FAIL: gcc.dg/torture/ftrapv-1.c   -O1  execution test
FAIL: gcc.dg/torture/ftrapv-1.c   -O2  execution test
FAIL: gcc.dg/torture/ftrapv-1.c   -O3 -fomit-frame-pointer  execution test
FAIL: gcc.dg/torture/ftrapv-1.c   -O3 -fomit-frame-pointer -funroll-loops 
execution test
FAIL: gcc.dg/torture/ftrapv-1.c   -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  execution test
FAIL: gcc.dg/torture/ftrapv-1.c   -O3 -g  execution test
FAIL: gcc.dg/torture/ftrapv-1.c   -Os  execution test
FAIL: gcc.dg/torture/ftrapv-1.c   -O2 -flto -flto-partition=none  execution
test
FAIL: gcc.dg/torture/ftrapv-1.c   -O2 -flto  execution test

According Iain Sandoe the tests pass on x86_64-apple-darwin12.

[Bug middle-end/62018] FAIL: gcc.dg/torture/ftrapv-1.c * execution test on x86_64-apple-darwin13

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62018

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2014-08-05
     Ever confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Can you please investigate a bit yourself?  The test relies on fork()/wait()
to work and properly return the exit status of the forked process.

[Bug middle-end/62018] FAIL: gcc.dg/torture/ftrapv-1.c * execution test on x86_64-apple-darwin13

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62018

--- Comment #2 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> Can you please investigate a bit yourself?  The test relies on fork()/wait()
> to work and properly return the exit status of the forked process.

Where should I start?

[Bug middle-end/62018] FAIL: gcc.dg/torture/ftrapv-1.c * execution test on x86_64-apple-darwin13

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62018

--- Comment #4 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> With a debugger?

Yerk!-(

[Bug middle-end/62018] FAIL: gcc.dg/torture/ftrapv-1.c * execution test on x86_64-apple-darwin13

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62018

--- Comment #5 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
If I remove the attribute 'no clone', the test succeeds with clang, but fails
with at least gcc 4.8.3, 4.9.1, and trunk.

[Bug middle-end/62018] FAIL: gcc.dg/torture/ftrapv-1.c * execution test on x86_64-apple-darwin13

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62018

--- Comment #6 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Created attachment 33367
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33367&action=edit
Preprocessed and assembly files for gcc and clang

Preprocessed and assembly files for gcc (ftrapv-1_gcc.(i|s)) and clang
(ftrapv-1_clang.(i|s)).

[Bug middle-end/62018] FAIL: gcc.dg/torture/ftrapv-1.c * execution test on x86_64-apple-darwin13

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62018

Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW
                 CC|                            |fxcoudert at gcc dot gnu.org

--- Comment #7 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
Here's a minimal reproducer:

int iaddv (int a, int b) { return a + b; }
int main (void)
{ volatile int x = iaddv (__INT_MAX__, 1); }


Compiled with gcc trunk (or 4.8 or 4.9) with option -ftrapv, it executes
without fault. If I do the same on a linux box, it traps (as it should).

However, on both the tree dumps are the same: i.e. I cannot see, from the dump
tree, where the trap checks and instructions should be. Richard, I am willing
to debug this, but don't know where to go after the above analysis.

[Bug middle-end/62018] FAIL: gcc.dg/torture/ftrapv-1.c * execution test on x86_64-apple-darwin13

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62018

--- Comment #8 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
(In reply to Francois-Xavier Coudert from comment #7)
> Richard, I am willing to debug this, but don't know where to go after the above analysis.


I think it's a libgcc miscompilation somehow. Directly calling __addvsi3 as
follows:

int __addvsi3 (int, int);
int main (void)
{ volatile int x = __addvsi3 (__INT_MAX__, 1); }

does not abort, even though (in my understanding) it should.

[Bug target/62018] FAIL: gcc.dg/torture/ftrapv-1.c * execution test on x86_64-apple-darwin13

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62018

Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
             Target|x86_64-apple-darwin13       |x86_64-apple-darwin1[34]
   Last reconfirmed|2014-08-05 00:00:00         |2014-11-9
          Component|middle-end                  |target
               Host|x86_64-apple-darwin13       |x86_64-apple-darwin1[34]
              Build|x86_64-apple-darwin13       |x86_64-apple-darwin1[34]

--- Comment #9 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
Some more debugging, and finally a victory: I understand what happens. But I
don't know how to fix it.

0. With my testcase from comment #8, compiling with -static-libgcc makes the
executable have the desired behavior (abort), but compiling without it (or with
-shared-libgcc) makes it not abort.

1. Yet forcing to compile with the "shared" object file (_addvsi3_s.o) leads to
correct result (abort). So, it's not a miscomputation.

2. Running the -shared-libgcc executable with DYLD_PRINT_LIBRARIES=y shows that
it's loading the correct libgcc_s:

  dyld: loaded: /Users/fx/devel/gcc/irun2/./a.out
  dyld: loaded: /usr/lib/libSystem.B.dylib
  dyld: loaded: /usr/local/gfortran/lib/libgcc_s.1.dylib


3. But running it with DYLD_PRINT_BINDINGS=y shows that our ___addvsi3 does not
get pulled from libgcc_s.1.dylib, as we'd like, but from the system's
libcompiler_rt.dylib (which has, apparently, a faulty version of this symbol
for backward compatibility reasons):

  dyld: lazy bind: a.out:0x10D212010 = libcompiler_rt.dylib:___addvsi3,
*0x10D212010 = 0x7FFF9158BF67




4. And confirmation: forcing it to resolve symbols from libgcc_s.1.dylib, by
saying "DYLD_FORCE_FLAT_NAMESPACE=y
DYLD_INSERT_LIBRARIES=/usr/local/gfortran/lib/libgcc_s.1.dylib", makes the
executable have the expected behavior (aborts).

-----------------------------------

Conclusion: it's really a darwin bug. We need to have symbols taken from our
own libgcc override those from the system's libcompiler_rt (which is itself
pulled from libSystem, if I understand correctly). Any idea how we achieve
that?

[Bug target/62018] FAIL: gcc.dg/torture/ftrapv-1.c * execution test on x86_64-apple-darwin13

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62018

--- Comment #10 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Francois-Xavier Coudert from comment #9)
> Some more debugging, and finally a victory: I understand what happens. But I
> don't know how to fix it.
> 
> 0. With my testcase from comment #8, compiling with -static-libgcc makes the
> executable have the desired behavior (abort), but compiling without it (or
> with -shared-libgcc) makes it not abort.
> 
> 1. Yet forcing to compile with the "shared" object file (_addvsi3_s.o) leads
> to correct result (abort). So, it's not a miscomputation.

Great!

> 2. Running the -shared-libgcc executable with DYLD_PRINT_LIBRARIES=y shows
> that it's loading the correct libgcc_s:
> 
>   dyld: loaded: /Users/fx/devel/gcc/irun2/./a.out
>   dyld: loaded: /usr/lib/libSystem.B.dylib
>   dyld: loaded: /usr/local/gfortran/lib/libgcc_s.1.dylib
> 
> 
> 3. But running it with DYLD_PRINT_BINDINGS=y shows that our ___addvsi3 does
> not get pulled from libgcc_s.1.dylib, as we'd like, but from the system's
> libcompiler_rt.dylib (which has, apparently, a faulty version of this symbol
> for backward compatibility reasons):
> 
>   dyld: lazy bind: a.out:0x10D212010 = libcompiler_rt.dylib:___addvsi3,
> *0x10D212010 = 0x7FFF9158BF67
> 
> 
> 
> 
> 4. And confirmation: forcing it to resolve symbols from libgcc_s.1.dylib, by
> saying "DYLD_FORCE_FLAT_NAMESPACE=y
> DYLD_INSERT_LIBRARIES=/usr/local/gfortran/lib/libgcc_s.1.dylib", makes the
> executable have the expected behavior (aborts).
> 
> -----------------------------------
> 
> Conclusion: it's really a darwin bug. We need to have symbols taken from our
> own libgcc override those from the system's libcompiler_rt (which is itself
> pulled from libSystem, if I understand correctly). Any idea how we achieve
> that?

ld64 should pull the symbol from the first place that mentions it on the link
line.  It should place the two-level namespace information in the exe so that
the symbol is resolved from the correct place at runtime.

Can you confirm this?

if that's the case potential solutions:
(a) more fiddling with library ordering in the specs
(b) we could punt on the hope of ever getting the "extension" shared library to
play nicely with the already installed stuff and revert to putting these items
in a "crt". This would be a static lib and mentioned on the link-line would
take precedence over the system ones.

*sigh* also on my TODO is tidying up the maze of twisty passages that
constitutes the crt/libgcc_s/libcc_ext support across the darwin patch.  This
is where we have a huge challenge c.f. other systems since it's not acceptable
for end Users to "just install some new libs into some part of /usr/xxxx as
root".  Thus we have to make whatever we do interact well with what's already
there.

[Bug target/62018] FAIL: gcc.dg/torture/ftrapv-1.c * execution test on x86_64-apple-darwin13

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62018

--- Comment #11 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
(In reply to Iain Sandoe from comment #10)
> ld64 should pull the symbol from the first place that mentions it on the
> link line.  It should place the two-level namespace information in the exe
> so that the symbol is resolved from the correct place at runtime.
> 
> Can you confirm this?

Linking simply with "gcc a.c -ftrapv" calls collect2 with (removed the -L
options for clarity):

  collect2 -dynamic -arch x86_64 -macosx_version_min 10.10.0
-weak_reference_mismatches non-weak -o a.out a.o -no_compact_unwind -lSystem
-lgcc_ext.10.5 -lgcc -lSystem -v

and in turn ld with:

  ld -dynamic -arch x86_64 -macosx_version_min 10.10.0
-weak_reference_mismatches non-weak -o a.out a.o -no_compact_unwind -lSystem
-lgcc_ext.10.5 -lgcc -lSystem -v

If I manually call collect2 with "-lgcc_ext.10.5 -lgcc -lSystem" instead of
"-lSystem -lgcc_ext.10.5 -lgcc -lSystem" (removing the first "-lSystem"), then
the executable aborts it should.


So:

> (a) more fiddling with library ordering in the specs

It so happens that gcc/config/darwin10.h says: "Fix PR47558 by linking against
libSystem ahead of libgcc_ext."
So it looks like this is going to be fun!

[Bug target/62018] FAIL: gcc.dg/torture/ftrapv-1.c * execution test on x86_64-apple-darwin13

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62018

--- Comment #12 from rguenther at suse dot de <rguenther at suse dot de> ---
On Sun, 9 Nov 2014, fxcoudert at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62018
> 
> --- Comment #8 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
> (In reply to Francois-Xavier Coudert from comment #7)
> > Richard, I am willing to debug this, but don't know where to go after the above analysis.
> 
> 
> I think it's a libgcc miscompilation somehow. Directly calling __addvsi3 as
> follows:
> 
> int __addvsi3 (int, int);
> int main (void)
> { volatile int x = __addvsi3 (__INT_MAX__, 1); }
> 
> does not abort, even though (in my understanding) it should.

It definitely does on x86_64-linux.  Are you using libgcc_s from
the system (thus darwin)?  ISTR old libgcc did the arithmetic
in a bogus way (using undefined behavior).  Quoting from GCC 4.3
sources:

Wtype
__addvSI3 (Wtype a, Wtype b)
{
  const Wtype w = a + b;
^^^

  if (b >= 0 ? w < a : w > a)
    abort ();

the addition is done in signed thus invoking undefined behavior.
A fixed variant (trunk) looks like

Wtype
__addvSI3 (Wtype a, Wtype b)
{
  const Wtype w = (UWtype) a + (UWtype) b;

  if (b >= 0 ? w < a : w > a)
    abort ();

doing the addition in unsigned arithmetic.

So I bet apple GCC 4.2 is affected as well - not sure if LLVM
provides libgcc_s on newer systems.

[Bug target/62018] FAIL: gcc.dg/torture/ftrapv-1.c * execution test on x86_64-apple-darwin13

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62018

--- Comment #13 from rguenther at suse dot de <rguenther at suse dot de> ---
On Sun, 9 Nov 2014, fxcoudert at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62018
> 
> Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>            Keywords|                            |wrong-code
>              Target|x86_64-apple-darwin13       |x86_64-apple-darwin1[34]
>    Last reconfirmed|2014-08-05 00:00:00         |2014-11-9
>           Component|middle-end                  |target
>                Host|x86_64-apple-darwin13       |x86_64-apple-darwin1[34]
>               Build|x86_64-apple-darwin13       |x86_64-apple-darwin1[34]
> 
> --- Comment #9 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
> Some more debugging, and finally a victory: I understand what happens. But I
> don't know how to fix it.
> 
> 0. With my testcase from comment #8, compiling with -static-libgcc makes the
> executable have the desired behavior (abort), but compiling without it (or with
> -shared-libgcc) makes it not abort.
> 
> 1. Yet forcing to compile with the "shared" object file (_addvsi3_s.o) leads to
> correct result (abort). So, it's not a miscomputation.
> 
> 2. Running the -shared-libgcc executable with DYLD_PRINT_LIBRARIES=y shows that
> it's loading the correct libgcc_s:
> 
>   dyld: loaded: /Users/fx/devel/gcc/irun2/./a.out
>   dyld: loaded: /usr/lib/libSystem.B.dylib
>   dyld: loaded: /usr/local/gfortran/lib/libgcc_s.1.dylib
> 
> 
> 3. But running it with DYLD_PRINT_BINDINGS=y shows that our ___addvsi3 does not
> get pulled from libgcc_s.1.dylib, as we'd like, but from the system's
> libcompiler_rt.dylib (which has, apparently, a faulty version of this symbol
> for backward compatibility reasons):
> 
>   dyld: lazy bind: a.out:0x10D212010 = libcompiler_rt.dylib:___addvsi3,
> *0x10D212010 = 0x7FFF9158BF67
> 
> 
> 
> 
> 4. And confirmation: forcing it to resolve symbols from libgcc_s.1.dylib, by
> saying "DYLD_FORCE_FLAT_NAMESPACE=y
> DYLD_INSERT_LIBRARIES=/usr/local/gfortran/lib/libgcc_s.1.dylib", makes the
> executable have the expected behavior (aborts).
> 
> -----------------------------------
> 
> Conclusion: it's really a darwin bug. We need to have symbols taken from our
> own libgcc override those from the system's libcompiler_rt (which is itself
> pulled from libSystem, if I understand correctly). Any idea how we achieve
> that?

Simply get libcompiler_rt folks to fix their code?  You should be
able to file a bug somewhere.

[Bug target/62018] FAIL: gcc.dg/torture/ftrapv-1.c * execution test on x86_64-apple-darwin13

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62018

--- Comment #14 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
(In reply to rguenther@suse.de from comment #12)
> So I bet apple GCC 4.2 is affected as well - not sure if LLVM
> provides libgcc_s on newer systems.

Apple does not provide GCC 4.2 anymore, but its LLVM compiler provides a
__addvsi3 as part of its libSystem. Probably for backward compatibility,
because…


(In reply to rguenther@suse.de from comment #13)
> Simply get libcompiler_rt folks to fix their code?  You should be
> able to file a bug somewhere.

… the current clang-based Apple compilers do not emit any call to __addvsi3,
but directly emit the overflow checking code. So, I cannot get a simple
reproducer to report to them.
>From gcc-bugs-return-466196-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Nov 10 08:54:58 2014
Return-Path: <gcc-bugs-return-466196-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 770 invoked by alias); 10 Nov 2014 08:54:58 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 717 invoked by uid 55); 10 Nov 2014 08:54:54 -0000
From: "rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/62018] FAIL: gcc.dg/torture/ftrapv-1.c * execution test on x86_64-apple-darwin13
Date: Mon, 10 Nov 2014 08:54:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenther at suse dot de
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-62018-4-O7CI2lEQ6Q@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-62018-4@http.gcc.gnu.org/bugzilla/>
References: <bug-62018-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-11/txt/msg00668.txt.bz2
Content-length: 1105

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62018

--- Comment #15 from rguenther at suse dot de <rguenther at suse dot de> ---
On Mon, 10 Nov 2014, fxcoudert at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62018
> 
> --- Comment #14 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
> (In reply to rguenther@suse.de from comment #12)
> > So I bet apple GCC 4.2 is affected as well - not sure if LLVM
> > provides libgcc_s on newer systems.
> 
> Apple does not provide GCC 4.2 anymore, but its LLVM compiler provides a
> __addvsi3 as part of its libSystem. Probably for backward compatibility,
> because…
> 
> 
> (In reply to rguenther@suse.de from comment #13)
> > Simply get libcompiler_rt folks to fix their code?  You should be
> > able to file a bug somewhere.
> 
> … the current clang-based Apple compilers do not emit any call to __addvsi3,
> but directly emit the overflow checking code. So, I cannot get a simple
> reproducer to report to them.

Your example directly calling __addvsi3 should suffice for that.

Richard.
>From gcc-bugs-return-466198-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Nov 10 08:58:38 2014
Return-Path: <gcc-bugs-return-466198-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 4094 invoked by alias); 10 Nov 2014 08:58:38 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 4063 invoked by uid 48); 10 Nov 2014 08:58:35 -0000
From: "ramana at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/53579] libstdc++ configure atomicity tests use CXXFLAGS instead of CXXFLAGS_FOR_TARGET
Date: Mon, 10 Nov 2014 08:58:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 4.8.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ramana at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-53579-4-aLtduvEont@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-53579-4@http.gcc.gnu.org/bugzilla/>
References: <bug-53579-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-11/txt/msg00670.txt.bz2
Content-length: 971

https://gcc.gnu.org/bugzilla/show_bug.cgi?idS579

Ramana Radhakrishnan <ramana at gcc dot gnu.org> changed:

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

--- Comment #2 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
This is not just the atomicity tests that are affected.

 Now that we've switched to C++ in the main compiler, folks (especially in the
business of building cross-compilers) just set CXXFLAGS in the environment and
assume that this implies that the compiler built is built with the appropriate
CXXFLAGS. So, it's very easy to build a libstdc++ with the value of CXXFLAGS
set to something that wasn't expected. The build system appears to honour the
difference between CFLAGS and CFLAGS_FOR_TARGET, so it is natural that folks
expect that CXXFLAGS to behave in the same fashion.

[Bug target/62018] FAIL: gcc.dg/torture/ftrapv-1.c * execution test on x86_64-apple-darwin13

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62018

--- Comment #16 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
(In reply to rguenther@suse.de from comment #15)
> Your example directly calling __addvsi3 should suffice for that.

I've filed it (radar #18924081), but I don't expect them to fix anything,
because it is an undocumented internal function, supported for backward
compatibility.

[Bug target/62018] FAIL: gcc.dg/torture/ftrapv-1.c * execution test on x86_64-apple-darwin13

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62018

--- Comment #17 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Francois-Xavier Coudert from comment #16)
> (In reply to rguenther@suse.de from comment #15)
> > Your example directly calling __addvsi3 should suffice for that.
> 
> I've filed it (radar #18924081), but I don't expect them to fix anything,
> because it is an undocumented internal function, supported for backward
> compatibility.

if it's part of compiler-rt we can just post a patch on llvm-commits and that
will eventually percolate through to the system.  If it's part of libSystem,
then I agree .. they might elect to preserve the status quo.

We can still find a way to fix this for GCC tho.

[Bug target/62018] FAIL: gcc.dg/torture/ftrapv-1.c * execution test on x86_64-apple-darwin13

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62018

--- Comment #18 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
(In reply to Iain Sandoe from comment #17)
> if it's part of compiler-rt we can just post a patch on llvm-commits and
> that will eventually percolate through to the system.

It is part of compiler-rt (I mentioned libSystem because libSystem is the one
pulling libcompiler-rt.dylib into action). I'll prepare a patch for it, but now
the LLVM website is down.

[Bug target/62018] FAIL: gcc.dg/torture/ftrapv-1.c * execution test on x86_64-apple-darwin13

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62018

--- Comment #19 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
(In reply to Iain Sandoe from comment #17)
> if it's part of compiler-rt we can just post a patch on llvm-commits and
> that will eventually percolate through to the system.

I've opened an LLVM PR and attached a patch here:
http://llvm.org/bugs/show_bug.cgi?id=21518

[Bug target/62018] FAIL: gcc.dg/torture/ftrapv-1.c * execution test on x86_64-apple-darwin13

[howarth at bromo dot med.uc.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62018

howarth at bromo dot med.uc.edu changed:

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

--- Comment #20 from howarth at bromo dot med.uc.edu ---
Don't forget, for the historical record, that the original attempt to work
around such broken compiler-rt calls was discussed in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333.

[Bug target/62018] FAIL: gcc.dg/torture/ftrapv-1.c * execution test on x86_64-apple-darwin13

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62018

--- Comment #21 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
True, we could also follow this approach again
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333#c55), but it's more of a
hack really.

[Bug target/62018] FAIL: gcc.dg/torture/ftrapv-1.c * execution test on x86_64-apple-darwin13

[howarth at bromo dot med.uc.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62018

--- Comment #22 from howarth at bromo dot med.uc.edu ---
(In reply to Francois-Xavier Coudert from comment #21)
> True, we could also follow this approach again
> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333#c55), but it's more of a
> hack really.

There isn't any notations upstream that indicate that original problem with
inaccurate results from ___divdc3 was fixed in compiler-rt...

http://llvm.org/bugs/show_bug.cgi?id=9150

[Bug target/62018] FAIL: gcc.dg/torture/ftrapv-1.c * execution test on x86_64-apple-darwin13

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62018

--- Comment #23 from Iain Sandoe <iains at gcc dot gnu.org> ---
My take is:

1. It's good we have an upstream patch - if it percolates through that's one
less thing to worry about - although (of course) that will never realistically
be available historically.

2. we have so many versions, different layouts and version-specific issues,
that I think it's time to reorganise our GCC extensions library to meet these
different requirements than to limp along with kludge after kludge.

(temporary fixes might be needed, of course, while we figure out a better
layout for the general case).

[Bug target/62018] FAIL: gcc.dg/torture/ftrapv-1.c * execution test on x86_64-apple-darwin13

[howarth at bromo dot med.uc.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62018

--- Comment #24 from howarth at bromo dot med.uc.edu ---
I always thought the major reorganization would be forced whenever Apple
finally fully deprecated the libgcc_s.10.5.dylib stub, the associated
libgcc_s.10.4.dylib symlink pointing at libgcc_s.10.5.dylib and the
libgcc_s.1.dylib symlink pointing at libSystem.B.dylib. I would imagine that
will happen whenever Apple decides to completely remove the legacy libstdc++
support from OS X (which I would imagine is still a few OS releases away).

[Bug target/62018] FAIL: gcc.dg/torture/ftrapv-1.c * execution test on x86_64-apple-darwin13

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62018

--- Comment #25 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
(In reply to Iain Sandoe from comment #23)
> 2. we have so many versions, different layouts and version-specific issues,
> that I think it's time to reorganise our GCC extensions library to meet
> these different requirements than to limp along with kludge after kludge.

As a first step to achieving this, we should decide what targets we support
(building on, and compiling for via -mmacosx-version-min). Given the current
state of OS X versions, I see two options:

 a) We keep PowerPC, and thus drop support for 10.4 and earlier (since 10.5 is
the last OS X version to support ppc). This helps remove some old stuff (I'll
attach a work-in-progress patch).

 b) We drop PowerPC, then it makes sense to drop support for 10.5 too. This
would really simplify things in term of specs and those various support/ext
libraries.

Given that 10.5 and PowerPC have been vendor-unsupported for more than 3 years
at this point, that we don't have regular testing (and bootstrap on those
machines is quite slow), I'd say we should focus our energy on providing newer
compilers for the newer machines/OSes. So I would suggest we mark
powerpc-darwin as obsolete in GCC 5, and remove it for GCC 6. (Or maybe, we
even skip the obsolete part and simply drop it?)

What do you guys think?

[Bug target/62018] FAIL: gcc.dg/torture/ftrapv-1.c * execution test on x86_64-apple-darwin13

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62018

--- Comment #26 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
Created attachment 34077
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34077&action=edit
Patch removing 10.4 and earlier support from our specs/driver

[Bug target/62018] FAIL: gcc.dg/torture/ftrapv-1.c * execution test on x86_64-apple-darwin13

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62018

--- Comment #27 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Francois-Xavier Coudert from comment #25)
> (In reply to Iain Sandoe from comment #23)
> > 2. we have so many versions, different layouts and version-specific issues,
> > that I think it's time to reorganise our GCC extensions library to meet
> > these different requirements than to limp along with kludge after kludge.
> 
> As a first step to achieving this, we should decide what targets we support
> (building on, and compiling for via -mmacosx-version-min). Given the current
> state of OS X versions, I see two options:
> 
>  a) We keep PowerPC, and thus drop support for 10.4 and earlier (since 10.5
> is the last OS X version to support ppc). This helps remove some old stuff
> (I'll attach a work-in-progress patch).

I have a patch in my Q that moves the only ppc-specific 10.4 stuff to a
separate target fragment in libgcc/config/rs6000 - at that point, it becomes
academic to the discussion on supporting old versions since it has 0 impact on
work going forward.

>  b) We drop PowerPC, then it makes sense to drop support for 10.5 too. This
> would really simplify things in term of specs and those various support/ext
> libraries.
> 
> Given that 10.5 and PowerPC have been vendor-unsupported for more than 3
> years at this point, that we don't have regular testing (and bootstrap on
> those machines is quite slow), I'd say we should focus our energy on
> providing newer compilers for the newer machines/OSes.

I think we are (realistically) focussed on the newer versions - since we all
have limited hardware resources.  However, there's a bunch of perfectly
function hardware out there that is more usable with older system installs.

 So I would suggest we
> mark powerpc-darwin as obsolete in GCC 5, and remove it for GCC 6. (Or
> maybe, we even skip the obsolete part and simply drop it?)

The general approach here (as recommended by Mike) has been that we don't kill
versions intentionally;  having said that when stuff stops getting tested one
can assume it's quite quickly broken.  There's no work involved in "supporting"
10.2..10.4 since none of us making any attempt to keep them going (David Fang
does still test releases on 10.4, for fink, but that's the only thing I know
of).

As for 10.5 - I have personally both ppc and x86 10.5 hardware in daily use (
and not just for compiler building ;) ) - these are machines which just don't
have enough resources (or are ppc) to update further.  I will continue to test
(at a lower level) and fix stuff on ppc-darwin9 so long as the QuadG5 is still
in use.

Going forward - there are kind of three groupings:

 <= 10.4 [this possibly requires support for stubs etc.]  It's highly debatable
whether 10.4 is supportable without using odcctools (i.e. 10.5's assembler and
linker) - so, again, I'm not going to worry about it.  Someone sufficiently
interested in making it work can put the effort in.

 10.5/10.6 - These are the remaining two "gcc-based" systems and we can deal
with them with existing procedures.  Likely we should emulate the way that the
system libgcc_s does the forwarding of EH stuff to libSystem as well (10.6). 
10.5 has EH hassles that can only realistically be solved by replacing the
/usr/lib/libgcc_s.dylib (but I think anyone sufficiently enthusiastic to work
there, will be willing to do that).  I intend to post onto github a suitable
replacement lib - it seems that they will allow binaries there.

 10.7+ - (albeit 10.7 is somewhat transitionary) 
 here we need to stop building the eh stuff into libgcc, we probably need to
split the emultls stuff into a crt.  We might want to consider not having a
shared lib for the gcc crt at all here (i.e. do much like clang does with the
compiler-rt and just append a libgcc.a).  The only reason we *need* a dylib at
present is the EH (which is unused for these systems) and emults bits (which
could be dealt with differently).  I don't think that the argument that the
exes might grow by a few kb is terribly significant on modern systems. 

It's not been the case so far in gcc-5 that the old systems have been the
painful ones to keep flying ;)

I'm not a fan of "supporting only N and N-1" that's one of the suckiest things
about the vendor's tools.

Maybe we should open an enhancement PR for "rationalising libgcc and crts
across the darwin editions".

[Bug target/62018] FAIL: gcc.dg/torture/ftrapv-1.c * execution test on x86_64-apple-darwin13

[howarth at bromo dot med.uc.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62018

--- Comment #28 from howarth at bromo dot med.uc.edu ---
(In reply to Iain Sandoe from comment #27)
>  10.7+ - (albeit 10.7 is somewhat transitionary) 
>  here we need to stop building the eh stuff into libgcc, we probably need to
> split the emultls stuff into a crt.  We might want to consider not having a
> shared lib for the gcc crt at all here (i.e. do much like clang does with
> the compiler-rt and just append a libgcc.a).  The only reason we *need* a
> dylib at present is the EH (which is unused for these systems) and emults
> bits (which could be dealt with differently).  I don't think that the
> argument that the exes might grow by a few kb is terribly significant on
> modern systems. 
> 

We should also consider what to do about the compact unwinder (which we
currently disable by passing -no_compact_unwind to the LINK_GCC_C_SEQUENCE_SPEC
in gcc/config/darwin10.h). I assume at some point, perhaps when the legacy
libstdc++ support is removed from OS X, that the compatibility unwinder, which
we currently use, will be fully deprecated.

[Bug target/62018] FAIL: gcc.dg/torture/ftrapv-1.c * execution test on x86_64-apple-darwin1[34]

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62018

--- Comment #29 from Richard Biener <rguenth at gcc dot gnu.org> ---
*** Bug 68137 has been marked as a duplicate of this bug. ***

[Bug target/62018] FAIL: gcc.dg/torture/ftrapv-(1|2).c * execution test on x86_64-apple-darwin1[34]

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62018

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|FAIL:                       |FAIL:
                   |gcc.dg/torture/ftrapv-1.c * |gcc.dg/torture/ftrapv-(1|2)
                   |execution test on           |.c * execution test on
                   |x86_64-apple-darwin1[34]    |x86_64-apple-darwin1[34]

--- Comment #30 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> *** Bug 68137 has been marked as a duplicate of this bug. ***

Adjusting summary.