https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55930
--- Comment #3 from Saleem Abdulrasool ---
Still occurs with 4.9.2 (and the same patch still fixes it).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65341
--- Comment #11 from Markus Trippelsdorf ---
So one has to use:
CC="gcc -Wa,-mpower8" CXX="g++ -Wa,-mpower8" ../glibc/configure
to configure glibc on ppc64le? This looks odd to me.
Why not pass -mpower8 to the assembler by default?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65341
--- Comment #10 from Jakub Jelinek ---
Ah, indeed, I've totally missed it is a *.S file rather than *.c. Thus this is
certainly a glibc bug, please file it there instead.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65341
--- Comment #9 from David Edelsohn ---
GCC is working correctly. The file prologue generated by GCC for a C file now
includes
.machine power8
The example is a pre-processed assembly file. Note the file actively pushes
and pops the machine typ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43407
--- Comment #3 from Brian Adams ---
This bug is also in 4.9.0, and applies to /any/ attribute. Assuming a GCC
plugin that defines 'my_attr':
enum class __attribute__((my_attr)) MessageType : uint8_t {}
will generate the warning
Message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64785
--- Comment #6 from Kazumoto Kojima ---
(In reply to Oleg Endo from comment #4)
> I think that an SH specific pre-RA RTL pass could be useful in the future,
> for example to improve R0 utilization, even with LRA.
>
> Kaz, do you have any opinion
/specs
COLLECT_GCC=/build/gcc-trunk-git/gcc/xgcc
Target: powerpc64le-unknown-linux-gnu
Configured with: /src/gcc-trunk-git/configure --disable-bootstrap
--enable-languages=c,c++
Thread model: posix
gcc version 5.0.0 20150307 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-B' '/build/gcc-trunk-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65345
--- Comment #3 from Marek Polacek ---
Seems to be unrelated to _Generic, the following ICEs as well:
_Atomic int i = 5;
int j = i;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65345
--- Comment #2 from Marek Polacek ---
Backtrace:
0xcbc8aa crash_signal
/home/marek/src/gcc/gcc/toplev.c:383
0x978b80 tree_check
/home/marek/src/gcc/gcc/tree.h:2845
0x978b80 gimple_body(tree_node*)
/home/marek/src/gcc/gcc/gimple-expr.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65238
--- Comment #5 from Marek Polacek ---
(In reply to Iain Sandoe from comment #4)
> well, I suppose, before digging deeper into fixing this, the question is
> "should __has_attribute/__has_cpp_attribute be enabled for traditional"?
I believe it sh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65345
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65238
--- Comment #4 from Iain Sandoe ---
well, I suppose, before digging deeper into fixing this, the question is
"should __has_attribute/__has_cpp_attribute be enabled for traditional"?
if not .. (using the 'keep non-traditional cpp builtins at the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65345
Bug ID: 65345
Summary: ICE with _Generic selection on _Atomic int
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65316
--- Comment #11 from Jan Hubicka ---
Author: hubicka
Date: Sat Mar 7 20:33:58 2015
New Revision: 221258
URL: https://gcc.gnu.org/viewcvs?rev=221258&root=gcc&view=rev
Log:
PR ipa/65316
* tree.c (free_lang_data_in_type): Be sure to keep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59832
--- Comment #7 from Paul Pluzhnikov ---
Still broken on trunk @r221169.
Leaving known ICEs for >= 1 year untouched seems... suboptimal.
(Sorry I don't know enough GCC internals to take this on.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65341
--- Comment #7 from David Edelsohn ---
Was this fixed after Mike's patch? The logic in rs6000_override_options was
ignoring TARGET_DEFAULT.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65153
--- Comment #16 from Oleg Endo ---
Author: olegendo
Date: Sat Mar 7 19:35:22 2015
New Revision: 221257
URL: https://gcc.gnu.org/viewcvs?rev=221257&root=gcc&view=rev
Log:
gcc/testsuite/
PR target/65153
* gcc.c-torture/compile/pr65153.c:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65341
--- Comment #6 from Martin Sebor ---
Ah, yes, I missed that the macro was defined by gcc rather than glibc. It does
look like gcc defines the macro and then invokes as without telling it it's in
power6 mode.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61250
howarth at bromo dot med.uc.edu changed:
What|Removed |Added
CC||howarth at bromo dot med
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65341
--- Comment #5 from Jakub Jelinek ---
I think the point is when _ARCH_PWR6 is defined, the assembler should be
already in power6 or later mode (either through .machine directive emitted by
the compiler earlier, or through some command line option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64253
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65341
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65316
--- Comment #10 from Jan Hubicka ---
Unfortunately the patch breaks firefox LTO in an interesting way - I am
investigating if it is a firefox bug or not.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65341
--- Comment #3 from Markus Trippelsdorf ---
(In reply to David Edelsohn from comment #2)
> When did this start? GCC should be passing ".machine power8". Was this
> before or after Mike's change to processor default?
It started with your r21985
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65344
Bug ID: 65344
Summary: Exception is not catched on AIX - class with more
ancestors, virtual method throws
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65342
--- Comment #3 from Iain Sandoe ---
(In reply to Dominique d'Humieres from comment #2)
> > Confirmed. The problem occurs in fwprop1 where instructions corresponding
> > to the
> > following assembly
> > addis r2,r31,ha16(_A.1.1600-L1$pb)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63175
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
Summar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61207
--- Comment #9 from Kai Tietz ---
well, it might be same issue, but on x64 target the testcase of comment #6
works without issues.
As SRA seems to be involved here, the changes on trunk for DOM might be the
solution.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65249
Oleg Endo changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65249
--- Comment #16 from Oleg Endo ---
Author: olegendo
Date: Sat Mar 7 16:12:41 2015
New Revision: 221256
URL: https://gcc.gnu.org/viewcvs?rev=221256&root=gcc&view=rev
Log:
gcc/testsuite/
PR target/65249
* g++.dg/torture/pr65249.C: New.
A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65321
--- Comment #7 from Jeffrey A. Law ---
Richard S. is correct. SHIFT_COUNT_TRUNCATED means that the target internally
truncates the shift count to the number of bits needed to represent the size of
the object being shift (which is actually more c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65341
--- Comment #2 from David Edelsohn ---
When did this start? GCC should be passing ".machine power8". Was this before
or after Mike's change to processor default?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65343
--- Comment #1 from Jonathan Wakely ---
Maybe we want to placement-new the mutexes into a buffer so they are never
destroyed, although on mingw that will show up as leaked resources at program
shutdown (and this is only really a problem on mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65342
--- Comment #2 from Dominique d'Humieres ---
> Confirmed. The problem occurs in fwprop1 where instructions corresponding to
> the
> following assembly
> addis r2,r31,ha16(_A.1.1600-L1$pb)
> la r9,lo16(_A.1.1600-L1$pb)(r2)
> ld
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65343
Bug ID: 65343
Summary: unexpected exception thrown during destruction of
static object in debug mode
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65342
Alan Modra changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65331
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65332
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65333
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65339
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65341
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64785
--- Comment #5 from Oleg Endo ---
(In reply to Oleg Endo from comment #3)
> Created attachment 34982 [details]
> Add sh_pre_ra RTL pass
+
+ flag_live_range_shrinkage = 1;
This hunk was not supposed to be in the patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64785
--- Comment #4 from Oleg Endo ---
(In reply to Oleg Endo from comment #3)
> Created attachment 34982 [details]
> Add sh_pre_ra RTL pass
Right now I can think of two alternatives for this PR:
- convert respective insns into insn_and_split and emi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64785
--- Comment #3 from Oleg Endo ---
Created attachment 34982
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34982&action=edit
Add sh_pre_ra RTL pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61207
Ray Donnelly changed:
What|Removed |Added
CC||mingw.android at gmail dot com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61362
Thibaut LUTZ changed:
What|Removed |Added
CC||thibaut.lutz at googlemail dot
com
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65321
--- Comment #6 from rsandifo at gcc dot gnu.org
---
(In reply to rguent...@suse.de from comment #5)
> On Thu, 5 Mar 2015, rsandifo at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65321
> >
> > --- Comment #4 from r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65342
Bug ID: 65342
Summary: [5 Regression] FAIL:
gfortran.dg/intrinsic_(un)?pack_1.f90 -O1 execution
test on powerpc-apple-darwin9 after r210201
Product: gcc
Versio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65341
Bug ID: 65341
Summary: [5 Regression] glibc build failure on ppc64le:
setcontext.S:367: Error: junk at end of line: `1,0'
Product: gcc
Version: 5.0
Status: UNCONFIRMED
49 matches
Mail list logo
