[Bug target/60732] New: FAIL: g++.dg/ext/altivec-7.C -std=* scan-assembler _Z3fooDv*

[Bug target/60732] New: FAIL: g++.dg/ext/altivec-7.C -std=* scan-assembler _Z3fooDv*

[dominiq at lps dot ens.fr]

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

            Bug ID: 60732
           Summary: FAIL: g++.dg/ext/altivec-7.C -std=*  scan-assembler
                    _Z3fooDv*
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: dominiq at lps dot ens.fr
                CC: brooks at gcc dot gnu.org, iains at gcc dot gnu.org,
                    mikestump at comcast dot net
              Host: powerpc*-*-darwin*
            Target: powerpc*-*-darwin*
             Build: powerpc*-*-darwin*

The test g++.dg/ext/altivec-7.C has started to fail on powerpc-apple-darwin9
after r203469. The failures are silenced with the following patch

--- ../_gcc_clean/gcc/testsuite/g++.dg/ext/altivec-7.C    2013-10-13
00:58:24.000000000 +0200
+++ gcc/testsuite/g++.dg/ext/altivec-7.C    2014-02-20 13:57:47.000000000 +0100
@@ -2,6 +2,7 @@
 /* { dg-do compile { target powerpc*-*-* } } */
 /* { dg-require-effective-target powerpc_altivec_ok } */
 /* { dg-options "-maltivec" } */
+/* { dg-additional-options "-fabi-version=0" { target powerpc*-*-darwin* } }
*/

 #include <altivec.h>

Is there any reason why -fabi-version=0 is not the default on
powerpc*-*-darwin*?

[Bug target/60732] FAIL: g++.dg/ext/altivec-7.C -std=* scan-assembler _Z3fooDv*

[mrs at gcc dot gnu.org]

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.

[Bug target/60732] FAIL: g++.dg/ext/altivec-7.C -std=* scan-assembler _Z3fooDv*

[brooks at gcc dot gnu.org]

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?

[Bug target/60732] FAIL: g++.dg/ext/altivec-7.C -std=* scan-assembler _Z3fooDv*

[dominiq at lps dot ens.fr]

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

[Bug target/60732] FAIL: g++.dg/ext/altivec-7.C -std=* scan-assembler _Z3fooDv*

[brooks at gcc dot gnu.org]

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?)

[Bug target/60732] FAIL: g++.dg/ext/altivec-7.C -std=* scan-assembler _Z3fooDv*

[dominiq at lps dot ens.fr]

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.

[Bug target/60732] FAIL: g++.dg/ext/altivec-7.C -std=* scan-assembler _Z3fooDv*

[iains at gcc dot gnu.org]

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.

[Bug target/60732] FAIL: g++.dg/ext/altivec-7.C -std=* scan-assembler _Z3fooDv*

[brooks at gcc dot gnu.org]

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!

[Bug target/60732] FAIL: g++.dg/ext/altivec-7.C -std=* scan-assembler _Z3fooDv*

[mikestump at comcast dot net]

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.

[Bug target/60732] FAIL: g++.dg/ext/altivec-7.C -std=* scan-assembler _Z3fooDv*

[iains at gcc dot gnu.org]

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?