* [Bug target/60732] FAIL: g++.dg/ext/altivec-7.C -std=* scan-assembler _Z3fooDv*
2014-04-01 18:41 [Bug target/60732] New: FAIL: g++.dg/ext/altivec-7.C -std=* scan-assembler _Z3fooDv* dominiq at lps dot ens.fr
@ 2014-04-02 0:30 ` mrs at gcc dot gnu.org
2014-04-02 0:37 ` brooks at gcc dot gnu.org
` (7 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: mrs at gcc dot gnu.org @ 2014-04-02 0:30 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60732
mrs at gcc dot gnu.org <mrs at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mrs at gcc dot gnu.org
--- Comment #1 from mrs at gcc dot gnu.org <mrs at gcc dot gnu.org> ---
The flag is documented to default to 2. Darwin does nothing special here (that
I could find or remember). One simply cannot change mangling without checking
this flag. If the flag doesn't change, then how can the mangling change?
If one wants to check a new mangling, then they have to use -fabi-version=n,
where is the the version they want to check. I don't see why that would be
dependent upon darwin; it should be unconditional.
Confused.
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug target/60732] FAIL: g++.dg/ext/altivec-7.C -std=* scan-assembler _Z3fooDv*
2014-04-01 18:41 [Bug target/60732] New: FAIL: g++.dg/ext/altivec-7.C -std=* scan-assembler _Z3fooDv* dominiq at lps dot ens.fr
2014-04-02 0:30 ` [Bug target/60732] " mrs at gcc dot gnu.org
@ 2014-04-02 0:37 ` brooks at gcc dot gnu.org
2014-04-02 7:16 ` dominiq at lps dot ens.fr
` (6 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: brooks at gcc dot gnu.org @ 2014-04-02 0:37 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60732
--- Comment #2 from Brooks Moses <brooks at gcc dot gnu.org> ---
For the record, here's my GCC mailing-list post associated with that commit:
http://gcc.gnu.org/ml/gcc-patches/2013-10/msg00836.html
As I described there,
> The failure is because the test is searching for mangled names of the
> form "_Z3fooU8__vectorh", which are only generated by ABI versions 1,
> 2, and 3. As noted in the documentation, "Version 4, which first
> appeared in G++ 4.5, implements a standard mangling for vector types";
> this standard mangling looks like "_Z3fooDv16_h" instead.
>
> This patch fixes the failure by adjusting the test to look for the
> names using the standard mangling. It passes with all ABI versions;
> the compiler always emits the standard symbols, and with versions 1,
> 2, and 3 it also emits duplicate symbols with the old mangling."
My immediate guess is that my claim that "the compiler always emits the
standard symbols [from version 4 of the ABI]" is not true on Darwin.
Dominique, what does the generated assembly look like in the (failing) Darwin
case?
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug target/60732] FAIL: g++.dg/ext/altivec-7.C -std=* scan-assembler _Z3fooDv*
2014-04-01 18:41 [Bug target/60732] New: FAIL: g++.dg/ext/altivec-7.C -std=* scan-assembler _Z3fooDv* dominiq at lps dot ens.fr
2014-04-02 0:30 ` [Bug target/60732] " mrs at gcc dot gnu.org
2014-04-02 0:37 ` brooks at gcc dot gnu.org
@ 2014-04-02 7:16 ` dominiq at lps dot ens.fr
2014-04-02 17:49 ` brooks at gcc dot gnu.org
` (5 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: dominiq at lps dot ens.fr @ 2014-04-02 7:16 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60732
--- Comment #3 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> Dominique, what does the generated assembly look like in the (failing) Darwin case?
Without -fabi-version=0 (or with -fabi-version=1 to 3), I get the pre r203469
manglings:
.globl __Z3fooU8__vectorh
.globl __Z3fooU8__vectora
.globl __Z3fooU8__vectorU6__boolc
.globl __Z3fooU8__vectort
.globl __Z3fooU8__vectors
.globl __Z3fooU8__vectorU6__bools
.globl __Z3fooU8__vectorj
.globl __Z3fooU8__vectori
.globl __Z3fooU8__vectorU6__booli
.globl __Z3fooU8__vectorf
.globl __Z3fooU8__vectoru7__pixel
.globl __Z3fooi
.globl __Z3fooj
.globl __Z3foof
With -fabi-version=0 or 4, I get the manglings expected by the test
.globl __Z3fooDv16_h
.globl __Z3fooDv16_a
.globl __Z3fooDv16_U6__boolc
.globl __Z3fooDv8_t
.globl __Z3fooDv8_s
.globl __Z3fooDv8_U6__bools
.globl __Z3fooDv4_j
.globl __Z3fooDv4_i
.globl __Z3fooDv4_U6__booli
.globl __Z3fooDv4_f
.globl __Z3fooDv8_u7__pixel
.globl __Z3fooi
.globl __Z3fooj
.globl __Z3foof
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug target/60732] FAIL: g++.dg/ext/altivec-7.C -std=* scan-assembler _Z3fooDv*
2014-04-01 18:41 [Bug target/60732] New: FAIL: g++.dg/ext/altivec-7.C -std=* scan-assembler _Z3fooDv* dominiq at lps dot ens.fr
` (2 preceding siblings ...)
2014-04-02 7:16 ` dominiq at lps dot ens.fr
@ 2014-04-02 17:49 ` brooks at gcc dot gnu.org
2014-04-09 9:10 ` dominiq at lps dot ens.fr
` (4 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: brooks at gcc dot gnu.org @ 2014-04-02 17:49 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60732
--- Comment #4 from Brooks Moses <brooks at gcc dot gnu.org> ---
Interesting. As noted, with -fabi-version=[1 to 3] on Linux, I was getting
both sets.
Mike, what do you think is the best solution here? We could use Dominique's
patch with a comment to the effect that "New-ABI symbols are always emitted on
Linux, but only with -fabi-version=4 or later on Darwin." We could revert my
change and hardcode -fabi-version=2 for all targets. Or we could take the
suggestion from your original review email and duplicate the test into new-ABI
and old-ABI versions, and do both of those.
(If we duplicate the test, is altivec-7a.C a reasonable name for the
duplicate-with-different-ABI, or does it need to be altivec-18.C or whatever
the next available number is?)
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug target/60732] FAIL: g++.dg/ext/altivec-7.C -std=* scan-assembler _Z3fooDv*
2014-04-01 18:41 [Bug target/60732] New: FAIL: g++.dg/ext/altivec-7.C -std=* scan-assembler _Z3fooDv* dominiq at lps dot ens.fr
` (3 preceding siblings ...)
2014-04-02 17:49 ` brooks at gcc dot gnu.org
@ 2014-04-09 9:10 ` dominiq at lps dot ens.fr
2014-05-27 23:30 ` iains at gcc dot gnu.org
` (3 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: dominiq at lps dot ens.fr @ 2014-04-09 9:10 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60732
--- Comment #5 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> Mike, what do you think is the best solution here? We could use Dominique's
> patch with a comment to the effect that "New-ABI symbols are always emitted
> on Linux, but only with -fabi-version=4 or later on Darwin." We could revert
> my change and hardcode -fabi-version=2 for all targets. Or we could take the
> suggestion from your original review email and duplicate the test into new-ABI
> and old-ABI versions, and do both of those.
I am in favor of the duplicated test.
> (If we duplicate the test, is altivec-7a.C a reasonable name for the
> duplicate-with-different-ABI, or does it need to be altivec-18.C or whatever
> the next available number is?)
I prefer altivec-7a.C.
It would be nice to have this done for 4.9.0.
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug target/60732] FAIL: g++.dg/ext/altivec-7.C -std=* scan-assembler _Z3fooDv*
2014-04-01 18:41 [Bug target/60732] New: FAIL: g++.dg/ext/altivec-7.C -std=* scan-assembler _Z3fooDv* dominiq at lps dot ens.fr
` (4 preceding siblings ...)
2014-04-09 9:10 ` dominiq at lps dot ens.fr
@ 2014-05-27 23:30 ` iains at gcc dot gnu.org
2014-06-02 1:03 ` brooks at gcc dot gnu.org
` (2 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: iains at gcc dot gnu.org @ 2014-05-27 23:30 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60732
Iain Sandoe <iains at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2014-05-27
Ever confirmed|0 |1
--- Comment #6 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Dominique d'Humieres from comment #5)
> > Mike, what do you think is the best solution here? We could use Dominique's
> > patch with a comment to the effect that "New-ABI symbols are always emitted
> > on Linux, but only with -fabi-version=4 or later on Darwin." We could revert
> > my change and hardcode -fabi-version=2 for all targets. Or we could take the
> > suggestion from your original review email and duplicate the test into new-ABI
> > and old-ABI versions, and do both of those.
>
> I am in favor of the duplicated test.
It looks to me like the ELF toolchain is emitting a non-weak alias for the
alternate symbol.
We don't (currently) support that in Darwin (and it's pretty unlikely we will
given ld64's atom rules).
Therefore, I concur that the correct action is to have two tests - one for each
ABI and run both tests on all targets.
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug target/60732] FAIL: g++.dg/ext/altivec-7.C -std=* scan-assembler _Z3fooDv*
2014-04-01 18:41 [Bug target/60732] New: FAIL: g++.dg/ext/altivec-7.C -std=* scan-assembler _Z3fooDv* dominiq at lps dot ens.fr
` (5 preceding siblings ...)
2014-05-27 23:30 ` iains at gcc dot gnu.org
@ 2014-06-02 1:03 ` brooks at gcc dot gnu.org
2014-06-02 16:18 ` mikestump at comcast dot net
2014-06-02 17:01 ` iains at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: brooks at gcc dot gnu.org @ 2014-06-02 1:03 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60732
--- Comment #8 from Brooks Moses <brooks at gcc dot gnu.org> ---
Yup, that's essentially exactly what I had in mind, with a couple of minor
adjustments:
* I'd use your original patch of -fabi-version=0 to altivec-7.C, so that we're
continuing to test the latest ABI version even if it gets updated again in the
future.
* I'd make -fabi-version=2 on altivec-7a.C unconditional, rather than
conditional on Darwin. The reason that we got into this in the first place is
that I was building with a default of -fabi-version=4, and that test won't pass
on Linux in that case because at abi=4 only the new symbols are emitted.
* It's probably worth adding some comments to explain why these settings are
here. I'd suggest:
On altivec-7.C: "On Linux, these symbols are emitted on all abi versions.
However, on Darwin, they are only emitted on abi verson 4 and later."
On altivec-7a.C: "These symbols are only emitted for abi version 3 and
earlier."
In any case, thank you very much for following up on this. I had meant to, but
obviously hadn't made the time to get around to it, so I really appreciate you
doing this for me!
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug target/60732] FAIL: g++.dg/ext/altivec-7.C -std=* scan-assembler _Z3fooDv*
2014-04-01 18:41 [Bug target/60732] New: FAIL: g++.dg/ext/altivec-7.C -std=* scan-assembler _Z3fooDv* dominiq at lps dot ens.fr
` (6 preceding siblings ...)
2014-06-02 1:03 ` brooks at gcc dot gnu.org
@ 2014-06-02 16:18 ` mikestump at comcast dot net
2014-06-02 17:01 ` iains at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: mikestump at comcast dot net @ 2014-06-02 16:18 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60732
--- Comment #9 from Mike Stump <mikestump at comcast dot net> ---
So, I’m still left wondering if the difference in behavior between linux and
darwin is a bug in itself or not… Do we know which code or what change gives
rise to that?
>From gcc-bugs-return-453003-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jun 02 16:27:38 2014
Return-Path: <gcc-bugs-return-453003-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 32431 invoked by alias); 2 Jun 2014 16:27: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 32399 invoked by uid 48); 2 Jun 2014 16:27:33 -0000
From: "mpolacek at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/52829] gcc releases up to 4.6.2 triggers ICE when compiling Gambit Scheme at -O2 on ppc64
Date: Mon, 02 Jun 2014 16:27:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: 4.6.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: mpolacek at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
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: bug_status cc resolution
Message-ID: <bug-52829-4-ECw3X8CCqX@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-52829-4@http.gcc.gnu.org/bugzilla/>
References: <bug-52829-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-06/txt/msg00085.txt.bz2
Content-length: 547
https://gcc.gnu.org/bugzilla/show_bug.cgi?idR829
Marek Polacek <mpolacek at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
CC| |mpolacek at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #2 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
If this is fixed in 4.7+, there's nothing to do.
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug target/60732] FAIL: g++.dg/ext/altivec-7.C -std=* scan-assembler _Z3fooDv*
2014-04-01 18:41 [Bug target/60732] New: FAIL: g++.dg/ext/altivec-7.C -std=* scan-assembler _Z3fooDv* dominiq at lps dot ens.fr
` (7 preceding siblings ...)
2014-06-02 16:18 ` mikestump at comcast dot net
@ 2014-06-02 17:01 ` iains at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: iains at gcc dot gnu.org @ 2014-06-02 17:01 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60732
--- Comment #10 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Mike Stump from comment #9)
> So, I’m still left wondering if the difference in behavior between linux and
> darwin is a bug in itself or not… Do we know which code or what change
> gives rise to that?
I don't think it's a bug.
It seems that when the old ABI is specified - ELF toolchains emit both old and
new manglings (using non-weak aliases).
Darwin can't do that (at least, for now) so it only emits the mangling
appropriate to the ABI rev.
SO - we should test that all platforms emit the expected mangling for two
representative ABI versions.
I suppose that the ELF toolchains could also do a third test for the "bonus"
additional mangling emitted.
[[ that is unless it's a bug NOT to emit both - in which case Darwin has more
of a challenge ]]
>From gcc-bugs-return-453007-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jun 02 17:53:34 2014
Return-Path: <gcc-bugs-return-453007-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 14113 invoked by alias); 2 Jun 2014 17:53:33 -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 14064 invoked by uid 48); 2 Jun 2014 17:53:30 -0000
From: "iains at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/61387] [4.10 Regression] ~900 test failures on on x86_64-apple-darwin13 for g++ with -m64 after r211088
Date: Mon, 02 Jun 2014 17:53: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: 4.10.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: iains at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.10.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-61387-4-bYadv7ICtn@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61387-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61387-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-06/txt/msg00089.txt.bz2
Content-length: 1838
https://gcc.gnu.org/bugzilla/show_bug.cgi?ida387
Iain Sandoe <iains at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mrs at gcc dot gnu.org
--- Comment #4 from Iain Sandoe <iains at gcc dot gnu.org> ---
some analysis:
1. The codepath:
predicate that can distinguish between frame and non-frame memory.
For our purposes here, we can get away with (ab)using a jump pattern,
because we're going to do no optimization. */
if (MEM_P (fnaddr))
{
if (sibcall_insn_operand (fnaddr, word_mode))
{
does not appear to be triggered for x86_64-linux (i put an assert in which was
not triggered in either a bootstrap or complete c/c++ testsuite run).
----
2.
taking say pr58585.c as an example.
struct A
{
virtual void foo() {}
void bar();
};
void A::bar() { foo(); }
Linux and Darwin both mark foo() as weak.
However,
Linux says that targetm.binds_local_p (foo) == true.
Darwin says it's false.
So Darwin takes the code-path above and Linux doesn't. Right now, I'm not sure
which is the right claim on the binds_local_p.
3.
Anyway, assuming that the intention is to unwrap the indirection from the call
- something like:
if (MEM_P (fnaddr))
{
if (sibcall_insn_operand (fnaddr, word_mode))
{
fnaddr = XEXP (DECL_RTL (function), 0);
tmp = gen_rtx_MEM (QImode, fnaddr);
tmp = gen_rtx_CALL (VOIDmode, tmp, const0_rtx);
tmp = emit_call_insn (tmp);
SIBLING_CALL_P (tmp) = 1;
}
else
emit_jump_insn (gen_indirect_jump (fnaddr));
}
seems more like what was intended.
However, I really think we need to explain the difference in treatment.
Mike? amy thoughts?
^ permalink raw reply [flat|nested] 10+ messages in thread