http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57725
--- Comment #5 from jbeulich at novell dot com ---
How that? How is code supposed to find out then?
Perhaps briefly explaining where this is coming from originally might help: The
Xen hypervisor (as much as Linux) has a number of linker script con
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36041
--- Comment #21 from Jakub Jelinek ---
Created attachment 30382
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30382&action=edit
gcc49-pr36041.patch
Untested libgcc2.c implementation (no hw support). HW support is IMHO best
dealt on the com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57724
--- Comment #5 from Jörg Richter ---
BTW: There is currently a discussion [1] on this topic on the
"ISO C++ Standard - Discussion" list.
[1]
https://groups.google.com/a/isocpp.org/d/msg/std-discussion/ehqGBMsswjk/nbsubYASnPgJ
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57723
--- Comment #7 from petschy at gmail dot com ---
Is it a plausible assumption that if a function is not marked as 'noreturn' and
the loop doesn't change the program's state then the loop could be optimized
away?
Cases:
- the loop terminates, but t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53801
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54048
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57717
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #3 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54048
Mikael Morin changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54788
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54679
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57697
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57590
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57611
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57496
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57731
Bug ID: 57731
Summary: [4.9 Regression] ICE in extract_insn, at recog.c:2158
(arm-linux)
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56596
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57279
Matthias Klose changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57279
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|4.8.2 |4.8.1
--- Comment #4 from Jonathan Wake
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57486
Dinar Temirbulatov changed:
What|Removed |Added
CC||dtemirbulatov at gmail dot com
--- C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57623
--- Comment #6 from sgunderson at bigfoot dot com ---
BZHI seems to have the same problem.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57486
--- Comment #3 from Dinar Temirbulatov ---
Hello, Richard. I have got this error with gcc-4.8.x-google branch under the
RedHat based system. Here is command-line to reproduce the error: g++ -c
graphite.i -o graphite.o -fno-exceptions -fno-rtti -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57624
--- Comment #2 from sgunderson at bigfoot dot com ---
Shouldn't really the documentation say so, then? The entire GCC manual seems to
make no note of this header at all, as far as I can see.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57689
--- Comment #2 from Matthias Klose ---
building with BOOT_CFLAGS set to -g -O1 or -g -Og doesn't show the ICE and
builds libgo. Attaching test results later.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57172
Marc Glisse changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57732
Bug ID: 57732
Summary: [4.8 / 4.9 Regression] ICE (segfault in libisl)
building drizzle on 32bit targets (at least arm-linux
and i586-linux)
Product: gcc
Version:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57623
--- Comment #7 from Jakub Jelinek ---
Created attachment 30387
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30387&action=edit
gcc49-pr57623.patch
BZHI has a similar problem, but due to the non-canonical order of AND arguments
in the patter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57623
--- Comment #8 from sgunderson at bigfoot dot com ---
I really did spot the BZHI problem in actual code; that's how I found out :-) I
rewrote it slightly and the problem disappeared, though.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57623
--- Comment #9 from Jakub Jelinek ---
Then please provide preprocessed testcase for it (plus command line options).
Because I'm really curious how it could have been matched.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57733
Bug ID: 57733
Summary: pointer assignment internal compiler error
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57623
--- Comment #10 from sgunderson at bigfoot dot com ---
On Thu, Jun 27, 2013 at 12:27:02PM +, jakub at gcc dot gnu.org wrote:
> Then please provide preprocessed testcase for it (plus command line options).
> Because I'm really curious how it co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57623
--- Comment #11 from sgunderson at bigfoot dot com ---
On Thu, Jun 27, 2013 at 12:32:18PM +, sgunderson at bigfoot dot com wrote:
> Sorry, the code is a) not so easy to make public right now, and b) this
>
> particular edit has been lost in th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57723
--- Comment #8 from Michael Matz ---
(In reply to petschy from comment #7)
> Is it a plausible assumption that if a function is not marked as 'noreturn'
> and the loop doesn't change the program's state then the loop could be
> optimized away?
It
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57623
--- Comment #12 from sgunderson at bigfoot dot com ---
Created attachment 30389
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30389&action=edit
BZHI bug example (compile with g++-4.8 -O2 -mbmi2 -c foo.cc)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57623
--- Comment #13 from sgunderson at bigfoot dot com ---
There. That ought to satisfy your curiosity. :-) I get:
sesse@gruessi:~/addie$ g++-4.8 -O2 -mbmi2 -c foo.cc
/tmp/ccX2oEfE.s: Assembler messages:
/tmp/ccX2oEfE.s:21: Error: operand size mismatc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57623
--- Comment #14 from Jakub Jelinek ---
Ah, right, it isn't the combiner in your case, but register allocator, yes,
that can happen. The patch I've attached should fix that too.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56788
Marc Glisse changed:
What|Removed |Added
CC||dwarak.rajagopal at amd dot
com,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57733
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57670
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57723
--- Comment #9 from Mikael Pettersson ---
(In reply to Michael Matz from comment #8)
> (the
> argument being that an infinite loop is in itself a side-effect observable
> from
> outside).
Exactly.
> A function containing
> an infinite loop could
gold --enable-ld=default
--enable-plugin --with-plugin-ld=ld.gold --with-linker-hash-style=gnu
--disable-install-libiberty --disable-multilib --disable-libssp
--disable-werror --enable-checking=release --program-suffix=-4.9
--enable-version-specific-runtime-libs
Thread model: posix
gcc version 4.9.0 20130
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57734
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57733
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment #2 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57725
--- Comment #6 from joseph at codesourcery dot com ---
On Thu, 27 Jun 2013, jbeulich at novell dot com wrote:
> How that? How is code supposed to find out then?
Why does the code want to find out? If it's using these extensions it's
saying it'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57725
--- Comment #7 from jbeulich at novell dot com ---
That's why I gave the example of where this is coming from - the code obviously
wants to be able to determine whether the data block between the two labels is
empty. And no, using asm()-s for this
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57735
Bug ID: 57735
Summary: ICE with -mtune=xscale (error: could not split insn)
when building webkit
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57689
--- Comment #3 from Ian Lance Taylor ---
That makes it sound like the problem is that stage2 GCC is mis-compiling stage3
GCC, and that it's only a coincidence that the error occurs when building
libgo.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56977
--- Comment #6 from Harald van Dijk ---
FWIW, I've done some more testing with that on top of 4.8.1 and haven't been
able to find anything that breaks that wasn't already broken without it. Nice,
thanks.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57676
--- Comment #2 from Vladimir Makarov ---
That is a pretty interesting test case. Roughly speaking, we have chains of
divmodsi4 insns:
p1 / p2
...
p3 / p1
P1 (and many others) gets AX. But it is necessary for P3 in the second insn.
So on each
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57735
--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed with 4.8.1
Works with 4.7 and current trunk 4.9 though.
Fails for -mcpu=xscale , iwmmxt and iwmmxt2
Trying to reduce...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57623
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57725
--- Comment #8 from joseph at codesourcery dot com ---
On Thu, 27 Jun 2013, jbeulich at novell dot com wrote:
> That's why I gave the example of where this is coming from - the code
> obviously
> wants to be able to determine whether the data bl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57736
Bug ID: 57736
Summary: [4.8/4.9 Regression] ICE in emit_move_insn with
__builtin_ia32_rdtsc
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57736
--- Comment #1 from Alexander Monakov ---
Oops, submitted too soon.
echo 'f(){__builtin_ia32_rdtsc();}' | gcc -xc - -S -o-
: In function ‘f’:
:1:25: internal compiler error: in emit_move_insn, at expr.c:3486
0x6d9c63 emit_move_insn(rtx_def*, rtx_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57737
Bug ID: 57737
Summary: -fopenmp + -femit-struct-debug-reduced/baseonly =
internal compiler error: Segmentation fault
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57737
--- Comment #1 from Evgeny Gavrin ---
Created attachment 30393
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30393&action=edit
preprocessed file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57737
--- Comment #2 from Evgeny Gavrin ---
Created attachment 30394
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30394&action=edit
preprocessed file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57738
Bug ID: 57738
Summary: gcc-4.8.1 bootstrap gets unrecognized symbol type
"gnu_unique_object" (centos6.4)
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57738
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57739
Bug ID: 57739
Summary: Weaker diagnostics of failed overload resolution when
operators are declared as friends instead of
externally
Product: gcc
Version: 4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57739
--- Comment #1 from Phil Miller ---
Created attachment 30396
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30396&action=edit
Example of completely unhelpful overload resolution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57739
--- Comment #2 from Phil Miller ---
I've observed the same behavior as far back as g++ 4.4.3, modulo differences in
column number and caret display.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57736
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Target Milesto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57736
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57224
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57740
Bug ID: 57740
Summary: C++11 std::thread not usable with static linking
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: l
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57740
--- Comment #1 from Andrew Pinski ---
I think it is bad form to use static linking with pthreads.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57740
--- Comment #2 from roland at gnu dot org ---
(In reply to Andrew Pinski from comment #1)
> I think it is bad form to use static linking with pthreads.
Nonsense. There is code specifically to ensure it works.
The additions for C++11 thread interf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57723
--- Comment #10 from petschy at gmail dot com ---
Thanks for the explanation. The multithreaded argument is sound, but then, on
second thought, even in single threaded programs the state might be altered by
a signal handler, or another process if t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57740
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57719
--- Comment #2 from Zhendong Su ---
Hi Jakub, below are three additional (possibly related) testcases that may help
you folks diagnose the issue; they (including the original testcase) all
manifest differently:
-
test #2: wr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57740
--- Comment #4 from roland at gnu dot org ---
weakrefs are right for the conditional cases.
For the functions that underlie std::thread et al, it can never be meaningful
to use those interfaces and fail to link with -lpthread.
The Fedora hack jus
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57740
--- Comment #5 from roland at gnu dot org ---
So my draft fix actually breaks the dynamic case. For the unconditional calls,
weak is right in the shared library but strong is right in the static library.
But unlike normal libraries, libstdc++ goes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57740
--- Comment #6 from Jakub Jelinek ---
Note also that libstdc++.a can be used together with libpthread.so or
libstdc++.so with libpthread.a (g++ -static-libstdc++ etc.).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57741
Bug ID: 57741
Summary: ICE in tree.c:build_int_cst_wide starting in revision
200394
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Pr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57740
--- Comment #7 from roland at gnu dot org ---
(In reply to Jakub Jelinek from comment #6)
> Note also that libstdc++.a can be used together with libpthread.so or
> libstdc++.so with libpthread.a (g++ -static-libstdc++ etc.).
If libstdc++.a had str
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57509
Marc Glisse changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57456
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57456
Tobias Burnus changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #4 from Tobias Burnus --
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56596
--- Comment #3 from Dominique d'Humieres ---
This seems to have been fixed between revision 199435 (2013-05-30) and revision
199885 (2013-06-03): revision 199528?
The error
==15298== 80 bytes in 1 blocks are definitely lost in loss record 1 of 2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57740
--- Comment #8 from Andrew Pinski ---
(In reply to roland from comment #7)
> -static-libstdc++ is important
> to avoid DSO dependencies specific to the GCC version, which varies across
> installations in incompatible ways far more than libc/libpth
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57741
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57740
--- Comment #9 from roland at gnu dot org ---
(In reply to Andrew Pinski from comment #8)
> (In reply to roland from comment #7)
> > -static-libstdc++ is important
> > to avoid DSO dependencies specific to the GCC version, which varies across
> > i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57742
Bug ID: 57742
Summary: memset(malloc(n),0,n) -> calloc(n,1)
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: tree-opt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57743
Bug ID: 57743
Summary: Code accepted by other recent compilers, but not by
g++ - possibly failure to activate ADL
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57741
--- Comment #2 from Pat Haugen ---
Created attachment 30402
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30402&action=edit
full .i file
The proposed patch fixes the error for the reduced testcase and also fixes the
problem for the apsi ben
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57743
--- Comment #1 from Andrew Pinski ---
Note int does not have an associated namespace which is the issue here. There
is a defect report against the C++ standard about that.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57744
Bug ID: 57744
Summary: Power8 support has problems with quad word atomic
instructions
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57745
Bug ID: 57745
Summary: missing recursive lifetime extension within
std::initializer_list
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57744
Michael Meissner changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57744
--- Comment #1 from Michael Meissner ---
Created attachment 30403
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30403&action=edit
Program to show the bug
Compile with -O3 -mcpu=power8 -c -save-temps to make sure the assembler tries
to assem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57744
--- Comment #2 from Michael Meissner ---
Created attachment 30404
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30404&action=edit
Proposed patch to fix problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57740
--- Comment #10 from joseph at codesourcery dot com ---
On Thu, 27 Jun 2013, pinskia at gcc dot gnu.org wrote:
> No it does not. Or rather there have not been an ABI change in libstdc++
> since
> 3.4. If you compile with the oldest distro you
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57745
--- Comment #1 from Paolo Carlini ---
First blush seems related to PR54293, but I didn't study the latter seriously
enough.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57746
Bug ID: 57746
Summary: rejected valid specialization of member function of
class template (I think)
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: nor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57747
Bug ID: 57747
Summary: The progress indicator always shows 38%
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57747
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57717
--- Comment #4 from Khem Raj ---
I have backported this fix to 4.8 branch and tested it and it fixed the issue.
Below is the patch for 4.8
Index: gcc-4.8.1/gcc/config/rs6000/rs6000.c
==
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
Bug ID: 57748
Summary: ICE on ARM with -mfloat-abi=softfp -mfpu=neo
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: targe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
Khem Raj changed:
What|Removed |Added
Target||arm-none-linux-gnueabi
Build|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
Khem Raj changed:
What|Removed |Added
CC||mjambor at suse dot cz
--- Comment #2 from Khe
1 - 100 of 101 matches
Mail list logo
