[Bug rtl-optimization/62308] New: A bug with aarch64 big-endian

[Bug rtl-optimization/62308] New: A bug with aarch64 big-endian

[yml6087582 at 163 dot com]

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

            Bug ID: 62308
           Summary: A bug with aarch64 big-endian
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: rtl-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: yml6087582 at 163 dot com

Hi, when I compiled test.c with aarch64-none-elf-gcc -mbig-endian -S ,it
reported the following error:
   test.c:In function 'checkx2823':
   test.c:3:25:internal compiler error:Segmentation fault 
   void checkx2823(struct S2823 args){};

test.c:
   typedef int __attribute__((vector_size(16))) v4si;
   struct S2823 {v4si a;int b[0];};
   void checkx2823 (struct S2823 args){};

With the option of -mlittle-endian ,it would not have this error.And the error
would interrupt cc1 in the rtl-optimization reload,can someone help me find the
reason ?

  Thankyou!
by yimingliang

[Bug target/62308] A bug with aarch64 big-endian

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ABI
             Target|                            |aarch64
          Component|rtl-optimization            |target

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
The backend probably doesn't handle zero-length arrays passed by value.  And
the ABI probably doesn't specify what to do.

[Bug target/62308] A bug with aarch64 big-endian

[yml6087582 at 163 dot com]

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

--- Comment #2 from yml <yml6087582 at 163 dot com> ---
   But with the option of -mlittle-endian ,it would not have this error. Do it
prove that the backend support zero-length arrays passed by value ?

[Bug target/62308] A bug with aarch64 big-endian

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-09-02
                 CC|                            |ktkachov at gcc dot gnu.org
     Ever confirmed|0                           |1
      Known to fail|                            |4.9.1, 5.0

--- Comment #3 from ktkachov at gcc dot gnu.org ---
Confirmed, however I get an LRA ICE instead:

be.c: In function 'checkx2823':
be.c:3:28: internal compiler error: in check_rtl, at lra.c:1925
    void checkx2823 (struct S2823 args){};
                            ^
0x8f616f check_rtl
        $TOP/gcc/lra.c:1925
0x8f95f9 lra(_IO_FILE*)
        $TOP/gcc/lra.c:2315
0x8ba1fd do_reload
        $TOP/gcc/ira.c:5311
0x8ba1fd execute
        $TOP/gcc/ira.c:5470

[Bug target/62308] A bug with aarch64 big-endian

[yroux at gcc dot gnu.org]

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

Yvan Roux <yroux at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vmakarov at gcc dot gnu.org,
                   |                            |yroux at gcc dot gnu.org

--- Comment #4 from Yvan Roux <yroux at gcc dot gnu.org> ---
yes, and there is no issue when we use reload instead of LRA (flag -mno-lra).

[Bug target/62308] A bug with aarch64 big-endian

[venkataramanan.kumar at amd dot com]

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

--- Comment #5 from Venkataramanan <venkataramanan.kumar at amd dot com> ---
Not able to reproduce with latest trunk r215964. Bisecting to find a revision
from which bug disappears.

[Bug target/62308] A bug with aarch64 big-endian

[venkataramanan.kumar at amd dot com]

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

--- Comment #6 from Venkataramanan <venkataramanan.kumar at amd dot com> ---
git bisect experiment showed this revision after which bug disappears.

https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=215707

[Bug target/62308] A bug with aarch64 big-endian

[vmakarov at gcc dot gnu.org]

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

--- Comment #8 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
(In reply to Venkataramanan from comment #7)

> Where reload gets 
> 
> (set (reg:DI 0 x0 [76]) (reg:DI 1 x1 [ args+8 ]))
> (set (reg:TI 0 x0 [74]) (reg:TI -1 [+-8 ])
> 
> Looks same issue to me. 
> 
> Vladimir can you please confirm.

Now as I am less busy with the rematerialization pass, I'll look at this
problem on this week.  Thanks.

[Bug target/62308] A bug with aarch64 big-endian

[fei.yang0953 at gmail dot com]

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

Fei Yang <fei.yang0953 at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fei.yang0953 at gmail dot com

--- Comment #9 from Fei Yang <fei.yang0953 at gmail dot com> ---
(In reply to Vladimir Makarov from comment #8)
> (In reply to Venkataramanan from comment #7)

> Where reload gets 
> 
> (set
> (reg:DI 0 x0 [76]) (reg:DI 1 x1 [ args+8 ]))
> (set (reg:TI 0 x0 [74])
> (reg:TI -1 [+-8 ])
> 
> Looks same issue to me. 
> 
> Vladimir can you
> please confirm.

Now as I am less busy with the rematerialization pass, I'll
> look at this problem on this week.  Thanks.

Hello Vladimir,
  Any progress on this issue? This bug bothers me too. Thanks

[Bug target/62308] A bug with aarch64 big-endian

[clyon at gcc dot gnu.org]

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

--- Comment #10 from Christophe Lyon <clyon at gcc dot gnu.org> ---
Hello Vladimir,
Have you been able to make progress on this bug?

[Bug target/62308] A bug with aarch64 big-endian

[vmakarov at gcc dot gnu.org]

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

--- Comment #11 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
(In reply to Christophe Lyon from comment #10)
> Hello Vladimir,
> Have you been able to make progress on this bug?

Thanks for the remainder, Cristophe.  Sometimes I am loosing track of bugs I
should work on as I have to many of them.

I checked gcc-4.9-branch and the test.  I believe the patch mentioned for rev.
215707 is the right solution.  It could be a bit different but it has no sense
to try something else as the patch had already good testing and proved by time.

So you can submit the patch into gcc-4.9-branch after standard procedure
(bootstrap at least on x86-64 and aarch64 and testing on the both platform).  I
approve it.

[Bug target/62308] A bug with aarch64 big-endian

[clyon at gcc dot gnu.org]

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

--- Comment #12 from Christophe Lyon <clyon at gcc dot gnu.org> ---
(In reply to Vladimir Makarov from comment #11)
> (In reply to Christophe Lyon from comment #10)
> > Hello Vladimir,
> > Have you been able to make progress on this bug?
> 
> Thanks for the remainder, Cristophe.  Sometimes I am loosing track of bugs I
> should work on as I have to many of them.
> 
> I checked gcc-4.9-branch and the test.  I believe the patch mentioned for
> rev. 215707 is the right solution.  It could be a bit different but it has
> no sense to try something else as the patch had already good testing and
> proved by time.
> 
> So you can submit the patch into gcc-4.9-branch after standard procedure
> (bootstrap at least on x86-64 and aarch64 and testing on the both platform).
> I approve it.

The patch applies cleanly to the 4.9-branch.

However, I am probably missing something since with an updated 4.9-branch and
without this patch, I couldn't make the compiler crash:
$ aarch64-unknown-linux-gnu-gcc -S test.c -mbig-endian
test.c:2:15: error: expected specifier-qualifier-list before ‘v4si’
 struct S2823 {v4si a;int b[0];};
>From gcc-bugs-return-487758-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jun 01 22:27:32 2015
Return-Path: <gcc-bugs-return-487758-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 17627 invoked by alias); 1 Jun 2015 22:27:32 -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 17573 invoked by uid 48); 1 Jun 2015 22:27:28 -0000
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/66354] [UBSAN] stl_algobase.h:708:7: runtime error: null pointer passed as argument
Date: Mon, 01 Jun 2015 22:27: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: 6.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: redi at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: redi at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status resolution
Message-ID: <bug-66354-4-TbXsUsrYd3@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66354-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66354-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: 2015-06/txt/msg00090.txt.bz2
Content-length: 470

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |ASSIGNED
         Resolution|FIXED                       |---

--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Reopening as I plan to fix this on other branches too.

[Bug target/62308] A bug with aarch64 big-endian

[clyon at gcc dot gnu.org]

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

--- Comment #13 from Christophe Lyon <clyon at gcc dot gnu.org> ---
(In reply to Christophe Lyon from comment #12)

> However, I am probably missing something since with an updated 4.9-branch
> and without this patch, I couldn't make the compiler crash:
> $ aarch64-unknown-linux-gnu-gcc -S test.c -mbig-endian
> test.c:2:15: error: expected specifier-qualifier-list before ‘v4si’
>  struct S2823 {v4si a;int b[0];};

Not sure what was wrong with my previous build....

I now managed to reproduce it on the 4.9-branch (r224544).
With the patch applied, the ICE disappears as expected.

Bootstrapped on x86_64 and aarch64, make check shows no regression.
>From gcc-bugs-return-489343-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jun 18 17:45:18 2015
Return-Path: <gcc-bugs-return-489343-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 8649 invoked by alias); 18 Jun 2015 17:45:18 -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 8349 invoked by uid 48); 18 Jun 2015 17:45:13 -0000
From: "ebotcazou at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/66584] gcc differs in static, branch-prediction cost from icc in switch.
Date: Thu, 18 Jun 2015 17:45: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: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ebotcazou at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: WONTFIX
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 resolution
Message-ID: <bug-66584-4-cJ7c9p5Vc0@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66584-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66584-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: 2015-06/txt/msg01675.txt.bz2
Content-length: 1249

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

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #9 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> Perhaps I was unclear. I am asking that you point out to me in the gcc
> documentation where it comments regarding code generation for
> switch-statements, and that it might make clear that the lexographic
> "top-down" approach nor the default label are preferred but other, more
> complex heuristics are used that defeat static branch-prediction analysis. I
> do not think this is unreasonable.

I see, but documenting the code generation strategy in the user documentation
is not really appropriate, it is subject to change without notice and the doc
could be quickly out of sync.  Moreover, it would be a slippery slope: if we
start to document this case and not the dozens of others, users would either
ask for the others or draw false conclusions from their absence.

So WONTFIX seems to be the best resolution here.

[Bug target/62308] A bug with aarch64 big-endian

[clyon at gcc dot gnu.org]

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

--- Comment #14 from Christophe Lyon <clyon at gcc dot gnu.org> ---
Author: clyon
Date: Fri Jun 19 14:41:32 2015
New Revision: 224671

URL: https://gcc.gnu.org/viewcvs?rev=224671&root=gcc&view=rev
Log:
2015-06-19  Christophe Lyon  <christophe.lyon@linaro.org>

        PR target/62308
        Backport from mainline r215707.
        2014-09-30  David Sherwood  <david.sherwood@arm.com>

        * ira-int.h (ira_allocno): Add "wmode" field.
        * ira-build.c (create_insn_allocnos): Add new "parent" function
        parameter.
        * ira-conflicts.c (ira_build_conflicts): Add conflicts for registers
        that cannot be accessed in wmode.

        Backport from mainline r224649.
        2015-06-19  Christophe Lyon  <christophe.lyon@linaro.org>

        * gcc.target/aarch64/pr62308.c: New test.



Added:
    branches/gcc-4_9-branch/gcc/testsuite/gcc.target/aarch64/pr62308.c
Modified:
    branches/gcc-4_9-branch/gcc/ChangeLog
    branches/gcc-4_9-branch/gcc/ira-build.c
    branches/gcc-4_9-branch/gcc/ira-conflicts.c
    branches/gcc-4_9-branch/gcc/ira-int.h
    branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug target/62308] A bug with aarch64 big-endian

[clyon at gcc dot gnu.org]

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

--- Comment #15 from Christophe Lyon <clyon at gcc dot gnu.org> ---
Testcase committed to trunk as r224649, to gcc-5-branch as r224670.

[Bug target/62308] A bug with aarch64 big-endian

[clyon at gcc dot gnu.org]

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

Christophe Lyon <clyon at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #16 from Christophe Lyon <clyon at gcc dot gnu.org> ---
Now fixed in trunk, gcc-5-branch and gcc-4_9-branch.