[Bug target/64231] New: SIGSEGV building glibc on aarch64-linux-gnu from r217852

[Bug target/64231] New: SIGSEGV building glibc on aarch64-linux-gnu from r217852

[sandra at codesourcery dot com]

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

            Bug ID: 64231
           Summary: SIGSEGV building glibc on aarch64-linux-gnu from
                    r217852
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: sandra at codesourcery dot com
                CC: belagod at gcc dot gnu.org
              Host: i686-pc-linux-gnu
            Target: aarch64-linux-gnu
             Build: i686-pc-linux-gnu

I have an aarch64-linux-gnu build tree with a glibc checkout from about a month
ago (revision 1400983e04d7b4b5a92db79ab27b0d0ec7d8bdef) that has started giving
a SEGV when building argp/argp-help.c.  I tracked it down to this GCC commit:


r217852 | belagod | 2014-11-20 05:58:23 -0800 (Thu, 20 Nov 2014) | 17 lines
2014-11-20  Tejas Belagod  <tejas.belagod@arm.com>

gcc/
    * config/aarch64/aarch64-protos.h (aarch64_classify_symbol):
    Fixup prototype.
    * config/aarch64/aarch64.c (aarch64_expand_mov_immediate,
    aarch64_cannot_force_const_mem, aarch64_classify_address,
    aarch64_classify_symbolic_expression): Fixup call to
    aarch64_classify_symbol.
    (aarch64_classify_symbol): Add range-checking for
    symbol + offset addressing for tiny and small models.

testsuite/
         * gcc.target/aarch64/symbol-range.c: New.
         * gcc.target/aarch64/symbol-range-tiny.c: New.

Here's the info from running the debugger on cc1.

Program received signal SIGSEGV, Segmentation fault.
plus_constant (mode=DImode, x=0xf78e1f30, c=144, inplace=<optimized out>, 
    inplace@entry=false)
    at /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/explow.c:120
120          if (memory_address_p (GET_MODE (tem), XEXP (tem, 0)))
(gdb) print debug_rtx(x)
(mem/u/c:DI (symbol_ref/u:DI ("*.LC39") [flags 0x2]) [4  S8 A64])
$6 = void
(gdb) print tem
$7 = (rtx) 0x0
(gdb) bt
#0  plus_constant (mode=DImode, x=0xf78e1f30, c=144, inplace=<optimized out>, 
    inplace@entry=false)
    at /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/explow.c:120
#1  0x082e2db3 in init_alias_analysis ()
    at /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/alias.c:2966
#2  0x08b59682 in cse_main (nregs=<optimized out>, f=<optimized out>)
    at /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/cse.c:6597
#3  0x08b5a5ec in rest_of_handle_cse2 ()
    at /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/cse.c:7528
#4  (anonymous namespace)::pass_cse2::execute (this=0x92c99c8)
    at /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/cse.c:7581
#5  0x0868ca49 in execute_one_pass (pass=pass@entry=0x92c99c8)
    at /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/passes.c:2311
#6  0x0868cf16 in execute_pass_list_1 (pass=0x92c99c8)
    at /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/passes.c:2363
#7  0x0868cf26 in execute_pass_list_1 (pass=0x92c93c8, pass@entry=0x92c7288)
    at /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/passes.c:2364
#8  0x0868cf72 in execute_pass_list (fn=0xf7933dac, pass=0x92c7288)
    at /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/passes.c:2374
#9  0x08367a5d in cgraph_node::expand (this=this@entry=0xf794cd20)
    at /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/cgraphunit.c:1773
#10 0x083692ff in expand_all_functions ()
    at /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/cgraphunit.c:1909
#11 symbol_table::compile (this=this@entry=0xf7c3b000)
    at /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/cgraphunit.c:2263
#12 0x0836ae3d in symbol_table::finalize_compilation_unit (this=0xf7c3b000)
    at /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/cgraphunit.c:2340
#13 0x081ec3a4 in c_write_global_declarations ()
    at /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/c/c-decl.c:10777
#14 0x0874fdce in compile_file ()
    at /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/toplev.c:584
#15 0x081d1823 in do_compile ()
    at /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/toplev.c:2041
#16 toplev::main (this=this@entry=0xffffcfff, argc=argc@entry=103, 
    argv=argv@entry=0xffffd0b4)
    at /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/toplev.c:2138
#17 0x081d2175 in main (argc=103, argv=0xffffd0b4)
    at /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/main.c:38

Hopefully this is enough info to track it down?  Seems clear that something in
the bad patch started causing force_const_mem to return NULL in this case and
the call site in plus_mem is not expecting that.

[Bug target/64231] SIGSEGV building glibc on aarch64-linux-gnu from r217852

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I was able to build glibc just with Friday's GCC sources with glibc as of
Friday too.

[Bug target/64231] SIGSEGV building glibc on aarch64-linux-gnu from r217852

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
>Hopefully this is enough info to track it down?

We need the preprocessed source really.

[Bug target/64231] SIGSEGV building glibc on aarch64-linux-gnu from r217852

[sandra at codesourcery dot com]

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

--- Comment #3 from Sandra Loosemore <sandra at codesourcery dot com> ---
Created attachment 34225
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34225&action=edit
preprocessor output (gzipped)

Preprocessor output attached.

[Bug target/64231] SIGSEGV building glibc on aarch64-linux-gnu from r217852

[sandra at codesourcery dot com]

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

--- Comment #4 from Sandra Loosemore <sandra at codesourcery dot com> ---
In case it's also relevant, my GCC was configured with:

Configured with: /scratch/sandra/aarch64-fsf/src/gcc-mainline/configure
--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=aarch64-linux-gnu
--enable-threads --disable-libmudflap --disable-libssp --disable-libstdcxx-pch
--with-march=armv8-a --disable-libsanitizer --with-gnu-as --with-gnu-ld
--enable-languages=c,c++ --enable-shared --enable-lto --enable-symvers=gnu
--enable-__cxa_atexit --with-glibc-version=2.21 --disable-nls
--prefix=/scratch/sandra/aarch64-fsf/install --disable-shared --disable-threads
--disable-libssp --disable-libgomp --without-headers --with-newlib
--disable-decimal-float --disable-libffi --disable-libquadmath --disable-libitm
--disable-libatomic --enable-languages=c
--with-sysroot=/scratch/sandra/aarch64-fsf/install/aarch64-linux-gnu/libc
--with-gmp=/scratch/sandra/aarch64-fsf/obj/pkg-mainline-0-aarch64-linux-gnu/fsf-mainline-0-aarch64-linux-gnu.extras/host-libs-i686-pc-linux-gnu/usr
--with-mpfr=/scratch/sandra/aarch64-fsf/obj/pkg-mainline-0-aarch64-linux-gnu/fsf-mainline-0-aarch64-linux-gnu.extras/host-libs-i686-pc-linux-gnu/usr
--with-mpc=/scratch/sandra/aarch64-fsf/obj/pkg-mainline-0-aarch64-linux-gnu/fsf-mainline-0-aarch64-linux-gnu.extras/host-libs-i686-pc-linux-gnu/usr
--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm'
--with-isl=/scratch/sandra/aarch64-fsf/obj/pkg-mainline-0-aarch64-linux-gnu/fsf-mainline-0-aarch64-linux-gnu.extras/host-libs-i686-pc-linux-gnu/usr
--with-cloog=/scratch/sandra/aarch64-fsf/obj/pkg-mainline-0-aarch64-linux-gnu/fsf-mainline-0-aarch64-linux-gnu.extras/host-libs-i686-pc-linux-gnu/usr
--disable-libgomp --disable-libitm --disable-libatomic --disable-libssp
--enable-poison-system-directories
--with-build-time-tools=/scratch/sandra/aarch64-fsf/install/aarch64-linux-gnu/bin
--with-build-time-tools=/scratch/sandra/aarch64-fsf/install/aarch64-linux-gnu/bin
SED=sed
Thread model: single
gcc version 5.0.0 20141120 (experimental) (GCC)

[Bug target/64231] SIGSEGV building glibc on aarch64-linux-gnu from r217852

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

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

--- Comment #5 from ktkachov at gcc dot gnu.org ---
Works for me with current trunk GCC and recent glibc as well. By the way, what
are the compile options? I tried -O2

[Bug target/64231] [5 Regression] SIGSEGV building glibc on aarch64-linux-gnu from r217852

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |5.0
            Summary|SIGSEGV building glibc on   |[5 Regression] SIGSEGV
                   |aarch64-linux-gnu from      |building glibc on
                   |r217852                     |aarch64-linux-gnu from
                   |                            |r217852

[Bug target/64231] [5 Regression] SIGSEGV building glibc on aarch64-linux-gnu from r217852

[sandra at codesourcery dot com]

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

--- Comment #6 from Sandra Loosemore <sandra at codesourcery dot com> ---
This reproduces it for me; my build is at r217852.

$ aarch64-linux-gnu-gcc  argp-help.i -c -O2 
argp-help.c: In function '_help':
argp-help.c:1684:1: internal compiler error: Segmentation fault
0x874f9b0 crash_signal
    /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/toplev.c:359
0x8406cfb plus_constant(machine_mode, rtx_def*, long long, bool)
    /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/explow.c:120
0x82e2db2 init_alias_analysis()
    /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/alias.c:2966
0x8b59681 cse_main
    /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/cse.c:6597
0x8b5a5eb rest_of_handle_cse2
    /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/cse.c:7528
0x8b5a5eb execute
    /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/cse.c:7581
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

When I have a chance, I'll see if I can dig up some more information out of the
debugger and/or reduce the testcase enough to allow setting some breakpoints.

[Bug target/64231] [5 Regression] SIGSEGV building glibc on aarch64-linux-gnu from r217852

[sandra at codesourcery dot com]

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

--- Comment #7 from Sandra Loosemore <sandra at codesourcery dot com> ---
Hmmmm.  I'm not sure why there's trouble in reproducing the failure, but
looking at this some more, it seems like we have a problem with this code
fragment from force_const_mem in varasm.c:

  /* If we're not allowed to drop X into the constant pool, don't.  */
  if (targetm.cannot_force_const_mem (mode, x))
    return NULL_RTX;

and the code at the call site in plus_constant in explow.c:

      tem = force_const_mem (GET_MODE (x), tem);
      if (memory_address_p (GET_MODE (tem), XEXP (tem, 0)))
        return tem;

which is clearly not expecting force_const_mem to return null.  Guarding the
reference in the conditional like

      if (tem && memory_address_p (GET_MODE (tem), XEXP (tem, 0))) ...

fixes the SEGV, but a quick look shows that there are a lot of other uses of
force_const_mem that expect it to return a non-null value, with no checking.  
So, probably this has nothing to do with the specific change in r217852, but
has been a lurking bug for a long time, and it needs more than a band-aid on
this one particular call site.

[Bug target/64231] [5 Regression] SIGSEGV building glibc on aarch64-linux-gnu from r217852

[belagod at gcc dot gnu.org]

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

--- Comment #8 from Tejas Belagod <belagod at gcc dot gnu.org> ---
Hi Sandra, I'm unable to reproduce this SEGV with a x-build of
aarch64-linux-gcc/native gcc with -O2 on the attached prepocessed test case.
Are there any other options I'm missing?

[Bug target/64231] [5 Regression] SIGSEGV building glibc on aarch64-linux-gnu from r217852

[ramana at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2015-01-13
                 CC|                            |ramana at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #9 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
Waiting on this one - no one seems to be able to reproduce this.

[Bug target/64231] [5 Regression] SIGSEGV building glibc on aarch64-linux-gnu from r217852

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |build, ice-on-valid-code

--- Comment #10 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
What host compiler are you using?  I am running into a similar issue (though I
have not reproduced it myself; only in an automated build) with the host
compiler from RedHat EL5 (after backporting this patch to our GCC 4.7 tree) but
if I use the one from Debian 5, it works.

[Bug target/64231] [5 Regression] SIGSEGV building glibc on aarch64-linux-gnu from r217852

[ramana at gcc dot gnu.org]

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

--- Comment #11 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #10)
> What host compiler are you using?  I am running into a similar issue (though
> I have not reproduced it myself; only in an automated build) with the host
> compiler from RedHat EL5 (after backporting this patch to our GCC 4.7 tree)
> but if I use the one from Debian 5, it works.

gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1)

[Bug target/64231] [5 Regression] SIGSEGV building glibc on aarch64-linux-gnu from r217852

[sandra at codesourcery dot com]

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

--- Comment #12 from Sandra Loosemore <sandra at codesourcery dot com> ---
I'm using a 4.7.3 based gcc as the host compiler (built from one of our own
CodeBench release branches).

Regardless of whether the actual failure is reproducible, if you look at the
code I pointed at in comment 7, there is clearly a bug here:  if
force_const_mem returns NULL, GCC will crash, not just here but in several
other places as well.

[Bug target/64231] [5 Regression] SIGSEGV building glibc on aarch64-linux-gnu from r217852

[belagod at gcc dot gnu.org]

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

--- Comment #13 from Tejas Belagod <belagod at gcc dot gnu.org> ---
(In reply to Sandra Loosemore from comment #12)
> I'm using a 4.7.3 based gcc as the host compiler (built from one of our own
> CodeBench release branches).
> 
> Regardless of whether the actual failure is reproducible, if you look at the
> code I pointed at in comment 7, there is clearly a bug here:  if
> force_const_mem returns NULL, GCC will crash, not just here but in several
> other places as well.

I tried with a build of cross aarch64-linux-gnu with 4.7.4 as the host compiler
and my gcc sources at HEAD and r217852 of trunk, but no luck! :-(

[Bug target/64231] [5 Regression] SIGSEGV building glibc on aarch64-linux-gnu from r217852

[belagod at gcc dot gnu.org]

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

--- Comment #14 from Tejas Belagod <belagod at gcc dot gnu.org> ---
Also, I'm unable to build x-gcc with glibc at
1400983e04d7b4b5a92db79ab27b0d0ec7d8bdef due to an error: 

bin-trunk-linux/obj/glibc/intl/hash-string.os
plural.c:182:5: error: conflicting types for ‘__gettextparse’
 int __gettextparse (void);
     ^
In file included from plural.y:35:0:
plural-exp.h:97:23: note: previous declaration of ‘__gettextparse’ was here
 # define PLURAL_PARSE __gettextparse

so, I tried with an earlier version(c5684fdb2badfda3bd6e973e5f933272e39e9590),
but still no luck.
>From gcc-bugs-return-473373-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jan 15 16:32:29 2015
Return-Path: <gcc-bugs-return-473373-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 20856 invoked by alias); 15 Jan 2015 16:32:29 -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 20827 invoked by uid 48); 15 Jan 2015 16:32:24 -0000
From: "dgilbert at redhat dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/64614] bogus used initialized warning (in gcc 4.9.2 not in 4.8.3); switch statement versus &
Date: Thu, 15 Jan 2015 16:32:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 4.9.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: dgilbert at redhat dot com
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:
Message-ID: <bug-64614-4-abHyLLsOH6@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64614-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64614-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-01/txt/msg01367.txt.bz2
Content-length: 486

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

--- Comment #2 from Dr. David Alan Gilbert <dgilbert at redhat dot com> ---
(In reply to Marek Polacek from comment #1)
> We have tons of these -W*uninitialized bugs, so there's likely a dup.

Yep, it's possible - I couldn't find an obvious match; but two things to note
that might make this case easier to track down:
   a) It seems a regression from 4.8.3 to 4.9.2
   b) To me it seems specific to the  if/switch combination

Dave

[Bug target/64231] [5 Regression] SIGSEGV building glibc on aarch64-linux-gnu from r217852

[pinskia at gcc dot gnu.org]

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

--- Comment #15 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Ok, I was finally able to trace this down,  This is a 32bit vs 64bit host
compiler difference.
The problem is with:
      if (SYMBOL_REF_WEAK (x)
          || INTVAL (offset) < (HOST_WIDE_INT) -4294967263
          || INTVAL (offset) > (HOST_WIDE_INT) 4294967264)


This really should be something like:
      if (SYMBOL_REF_WEAK (x)
          || INTVAL (offset) < (HOST_WIDE_INT) -4294967263LL
          || INTVAL (offset) > (HOST_WIDE_INT) 4294967264LL)

[Bug target/64231] [5 Regression] SIGSEGV building glibc on aarch64-linux-gnu from r217852

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

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

--- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Perhaps better as:
          if (SYMBOL_REF_WEAK (x)
              || !IN_RANGE (INTVAL (x), HOST_WIDE_INT_C (-4294967263),
                            HOST_WIDE_INT_C (4294967264)))
?

[Bug target/64231] [5 Regression] SIGSEGV building glibc on aarch64-linux-gnu from r217852

[jakub at gcc dot gnu.org]

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

--- Comment #17 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Andrew, are you going to post the patch?  I think it is pretty obvious...

[Bug target/64231] [5 Regression] SIGSEGV building glibc on aarch64-linux-gnu from r217852

[ramana at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW

[Bug target/64231] [5 Regression] SIGSEGV building glibc on aarch64-linux-gnu from r217852

[belagod at gcc dot gnu.org]

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

--- Comment #18 from Tejas Belagod <belagod at gcc dot gnu.org> ---
Author: belagod
Date: Mon Feb  2 15:54:59 2015
New Revision: 220348

URL: https://gcc.gnu.org/viewcvs?rev=220348&root=gcc&view=rev
Log:
2015-02-02  Tejas Belagod  <tejas.belagod@arm.com>
        Andrew Pinski  <pinskia@gcc.gnu.org>
        Jakub Jelinek  <jakub@gcc.gnu.org>

    PR target/64231
    * config/aarch64/aarch64.c (aarch64_classify_symbol): Fix large
    integer typing for small model. Use IN_RANGE.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/aarch64/aarch64.c

[Bug target/64231] [5 Regression] SIGSEGV building glibc on aarch64-linux-gnu from r217852

[belagod at gcc dot gnu.org]

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

Tejas Belagod <belagod at gcc dot gnu.org> changed:

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

--- Comment #19 from Tejas Belagod <belagod at gcc dot gnu.org> ---
Fixed as r220348.

[Bug target/64231] [5 Regression] SIGSEGV building glibc on aarch64-linux-gnu from r217852

[clyon at gcc dot gnu.org]

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

--- Comment #20 from clyon at gcc dot gnu.org ---
Author: clyon
Date: Wed Apr 15 08:11:56 2015
New Revision: 222119

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

    Backport from trunk r220348.
    2015-02-02  Tejas Belagod  <tejas.belagod@arm.com>
        Andrew Pinski  <pinskia@gcc.gnu.org>
        Jakub Jelinek  <jakub@gcc.gnu.org>

    PR target/64231
    * config/aarch64/aarch64.c (aarch64_classify_symbol): Fix large
    integer typing for small model. Use IN_RANGE.


Modified:
    branches/linaro/gcc-4_9-branch/gcc/ChangeLog.linaro
    branches/linaro/gcc-4_9-branch/gcc/config/aarch64/aarch64.c