http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60478
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60479
--- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org ---
*** Bug 60478 has been marked as a duplicate of this bug. ***
gcc 4.8.2 fails to do optimization on global register variables when
compiling on x86_64 Linux.
Consider the following code:
-
include stdint.h
register uint64_t i0_BP __asm__ (r14);
register uint64_t i0_SP __asm__ (r15);
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60480
Bug ID: 60480
Summary: gcc 4.8.2 fails to do optimization on global register
variables when compiling on x86_64 Linux.
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60480
--- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org ---
This is due to x86 being a small register class target.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60480
--- Comment #2 from ganboing at gmail dot com ---
(In reply to Andrew Pinski from comment #1)
This is due to x86 being a small register class target.
The thing is that x86_64 has 16 GPRs, and register r12-r15 are preserved across
function calls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59726
Ramana Radhakrishnan ramana at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60459
Ramana Radhakrishnan ramana at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60298
Ramana Radhakrishnan ramana at gcc dot gnu.org changed:
What|Removed |Added
Keywords|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60109
Ramana Radhakrishnan ramana at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60106
Ramana Radhakrishnan ramana at gcc dot gnu.org changed:
What|Removed |Added
CC||ramana at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60106
--- Comment #2 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
(In reply to Ramana Radhakrishnan from comment #1)
Can you please add your configure flags here ?
Sure,
../gcc-4.9-20140202/configure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60474
Kai Tietz ktietz at gcc dot gnu.org changed:
What|Removed |Added
CC||ktietz at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60473
--- Comment #1 from Martin marmoo1024 at gmail dot com ---
After some checking I've found that the problem is with the binary OR operator.
Addition doesn't have a problem but or does. Here are my results.
unsigned long long **_rdtsc_64 () {
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60474
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60419
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60429
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60461
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Keywords||lto,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60457
--- Comment #3 from Richard Biener rguenth at gcc dot gnu.org ---
Looks obvious to me.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60478
--- Comment #2 from linzj manjian2006 at gmail dot com ---
(In reply to Marek Polacek from comment #1)
You've filed the same bug twice.
*** This bug has been marked as a duplicate of bug 60479 ***
小手一抖，jj没有
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60474
--- Comment #5 from Richard Biener rguenth at gcc dot gnu.org ---
type = signed_type_for (TREE_TYPE (e1));
tree_to_aff_combination (e1, type, aff_e1);
tree_to_aff_combination (e2, type, aff_e2);
signed_type_for (offset_type 0x76d9cc78)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60481
Bug ID: 60481
Summary: [4.9 Regression] Missing diagnostic ISO C++ forbids
declaration of 'foo' with no type
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60438
--- Comment #25 from Jakub Jelinek jakub at gcc dot gnu.org ---
(In reply to linzj from comment #23)
(In reply to Richard Henderson from comment #19)
Created attachment 32311 [details]
proposed patch
Running full tests on this overnight,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60481
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org ---
I think you need -fno-ms-extensions, which may be on by default for mingw
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60418
--- Comment #18 from Jakub Jelinek jakub at gcc dot gnu.org ---
Shouldn't we just prefer the original IL if possible? That is not
SSA_NAME_VERSION, but not gimple_uid of the stmt definition either.
If you have:
_4 = something;
_5 =
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60429
--- Comment #18 from Richard Biener rguenth at gcc dot gnu.org ---
Seems to be a PTA issue:
InsertionSort_pETEchase.29_82, points-to vars: { }
InsertionSort_pETEchase.29_86, points-to non-local, points-to escaped,
points-to vars: { }
p1_155,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55383
Magnus Reftel magnus.reftel at gmail dot com changed:
What|Removed |Added
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55383
--- Comment #5 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to Magnus Reftel from comment #4)
Also affects 4.6, 4.8 and trunk as of version
96c7d4b1727c5f9ddcbb02fb69f727a0f2f3572e. 4.4 correctly prints just error:
cast
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55383
--- Comment #6 from Magnus Reftel magnus.reftel at gmail dot com ---
Sorry, I'm not a GCC developer - just another user aflicted by the bug.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55874
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
Keywords|patch |
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60458
--- Comment #2 from Antony Lewis antony at cosmologist dot info ---
Here's a related example:
module A
implicit none
Type T
integer :: val = 2
contains
final :: testfree
end type
contains
subroutine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60438
--- Comment #26 from linzj manjian2006 at gmail dot com ---
(In reply to Jakub Jelinek from comment #25)
Perhaps we can handle some most common cases of frame related insns (e.g. if
both have REG_CFA_ADJUST_CFA notes, etc.), perhaps it would be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55383
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
Keywords||patch
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60429
--- Comment #19 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
Yes, looks like the reduced testcase is invalid and contains a few
buffer overflows.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60429
--- Comment #20 from Richard Biener rguenth at gcc dot gnu.org ---
As for what Andrew said, yes, the reinterpret_casts look bogus, you should
really change
typedef struct _POINTBLOCK {
int data[200 * sizeof(QPoint)];
QPoint *pts;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60438
--- Comment #27 from Jakub Jelinek jakub at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #25)
Perhaps we can handle some most common cases of frame related insns (e.g. if
both have REG_CFA_ADJUST_CFA notes, etc.), perhaps it would
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60452
--- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org ---
(In reply to Eric Botcazou from comment #6)
But even if I try:
int a;
__attribute__((noinline, noclone)) void
foo (int *e)
{
asm volatile ( : : r (e) : memory);
}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60458
--- Comment #3 from janus at gcc dot gnu.org ---
(In reply to Antony Lewis from comment #2)
Here's a related example:
Though the test case may be loosely related to comment 0, the error is probably
not so much related.
Reduced version of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60482
Bug ID: 60482
Summary: Loop optimization regression
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60458
--- Comment #4 from Antony Lewis antony at cosmologist dot info ---
OK, will do. (thought the underlying cause might be same issue with associate
variables)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60483
Bug ID: 60483
Summary: associate error on valid code: no IMPLICIT type
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60452
--- Comment #8 from Eric Botcazou ebotcazou at gcc dot gnu.org ---
But what would be safe positive/negative offsets from frame_pointer?
I mean, e.g. size of arguments is not included in the frame size, so size of
arguments would need to be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60411
Bernd Edlinger bernd.edlinger at hotmail dot de changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60484
Bug ID: 60484
Summary: -fdump-rtl-expand and attribute optimize gives
incorrect dump file path
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60482
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60438
--- Comment #28 from linzj manjian2006 at gmail dot com ---
(In reply to Jakub Jelinek from comment #27)
Wonder if we just shouldn't pass the other insn (the one we'd like to
delete) to
try_apply_stack_adjustment and if either of them is frame
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60429
--- Comment #21 from Richard Biener rguenth at gcc dot gnu.org ---
AFAIK I can understand the reduced testcase AET is never written to anything
but the initial NULL pointers. Neither CerateETandAET nor loadAET do anything
to the PolygonRegion
the cross build for arm-linux-gnueabihf succeeds again.
Great.
So they use the same system.ads, which now links with a-exexpr-gcc.adb;
Should'nt this target now also use EH_MECHANISM=-gcc or -arm?
Yes, android should also use
EH_MECHANISM=-arm
I'll make that change.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60411
--- Comment #7 from charlet at adacore dot com charlet at adacore dot com ---
the cross build for arm-linux-gnueabihf succeeds again.
Great.
So they use the same system.ads, which now links with a-exexpr-gcc.adb;
Should'nt this target now
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60418
--- Comment #19 from rguenther at suse dot de rguenther at suse dot de ---
On Mon, 10 Mar 2014, jakub at gcc dot gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60418
--- Comment #18 from Jakub Jelinek jakub at gcc dot gnu.org ---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60474
--- Comment #6 from Richard Biener rguenth at gcc dot gnu.org ---
Author: rguenth
Date: Mon Mar 10 13:27:16 2014
New Revision: 208451
URL: http://gcc.gnu.org/viewcvs?rev=208451root=gccview=rev
Log:
2014-03-10 Richard Biener rguent...@suse.de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60474
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60481
--- Comment #2 from Dmitry Gorbachev d.g.gorbachev at gmail dot com ---
Yes, it seems that it is on (there is an error with -fno-ms-extensions), but:
$ i686-w64-mingw32-g++-4.9.0 -Q --help=c++ | grep ms-ext
-fms-extensions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60485
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60485
Bug ID: 60485
Summary: field-sensitive points-to confused by pointer
offsetting
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60482
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60457
--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org ---
Author: jakub
Date: Mon Mar 10 14:55:20 2014
New Revision: 208454
URL: http://gcc.gnu.org/viewcvs?rev=208454root=gccview=rev
Log:
PR ipa/60457
* ipa.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60464
--- Comment #8 from Richard Earnshaw rearnsha at gcc dot gnu.org ---
(In reply to Jeremy Cooper from comment #7)
Is there a reason these were commented out? Is the armv7 multilib unstable?
Volume of variants that have to be compiled at build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60457
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60486
Bug ID: 60486
Summary: [avr] missed optimization on detecting zero flag set
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55383
Gerald Pfeifer gerald at pfeifer dot com changed:
What|Removed |Added
Status|NEW |ASSIGNED
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60452
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Component|tree-optimization |rtl-optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53492
--- Comment #5 from Jason Merrill jason at gcc dot gnu.org ---
Author: jason
Date: Mon Mar 10 15:44:50 2014
New Revision: 208455
URL: http://gcc.gnu.org/viewcvs?rev=208455root=gccview=rev
Log:
PR c++/53492
* parser.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60418
--- Comment #20 from H.J. Lu hjl.tools at gmail dot com ---
(In reply to Richard Biener from comment #13)
Huh, adding a pre-header should _never_ do sth like that. Can you produce
a small testcase that exhibits these kind of changes with
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60487
Bug ID: 60487
Summary: FAIL: gcc.dg/tree-prof/crossmodule-indircall-1a.c
compilation, -fprofile-generate -D_PROFILE_GENERATE
Product: gcc
Version: 4.9.0
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60488
Bug ID: 60488
Summary: missing -Wmaybe-uninitialized on a conditional with
goto
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58678
Jason Merrill jason at gcc dot gnu.org changed:
What|Removed |Added
Assignee|jason at gcc dot gnu.org |hubicka at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59121
--- Comment #14 from Mircea Namolaru mircea.namolaru at inria dot fr ---
Confirmed.
Start looking at it. This test also enters in an endless loop with the
options -fgraphite-identiy -floop-nest-optimize -O2 -c.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60418
--- Comment #21 from Jakub Jelinek jakub at gcc dot gnu.org ---
Can you try if sorting on gimple_uid would help this or not? I think it would
be something like:
--- gcc/tree-ssa-reassoc.c.jj2014-02-19 06:59:35.0 +0100
+++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59121
--- Comment #15 from Jeffrey A. Law law at redhat dot com ---
Mircea, thanks. I'm definitely looking forward to seeing Graphite in a better
state! With you on board at INRIA and working on Graphite, I will not be
calling for Graphite's removal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60489
Bug ID: 60489
Summary: Document which functions can be recursively reentered
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: documentation
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60418
--- Comment #22 from H.J. Lu hjl.tools at gmail dot com ---
(In reply to Jakub Jelinek from comment #21)
Can you try if sorting on gimple_uid would help this or not? I think it
would be something like:
Yes, it works.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59025
--- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org ---
Can you please try the http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60418#c21
patch?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60486
Georg-Johann Lay gjl at gcc dot gnu.org changed:
What|Removed |Added
CC||gjl at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60486
Georg-Johann Lay gjl at gcc dot gnu.org changed:
What|Removed |Added
Target||avr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60486
--- Comment #3 from Georg-Johann Lay gjl at gcc dot gnu.org ---
Here is a smaller test case with similar artifact (insn #7):
extern void foo (unsigned);
char v;
void pr_60486 (unsigned z)
{
if (--z == 0)
v = 0;
foo (z);
}
pr_60486:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60490
Bug ID: 60490
Summary: please define __LITTLE_ENDIAN__/__BIG_ENDIAN__ for
every target where it makes sense
Product: gcc
Version: unknown
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60482
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||pinskia at gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60490
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60490
--- Comment #2 from Eric Christopher echristo at gmail dot com ---
Why does it seem like a bad decision? Endianness can be separate from OS (or
bare metal) so I don't see how outputting the macro as a per-cpu define is a
bad thing.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60490
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60490
--- Comment #4 from Eric Christopher echristo at gmail dot com ---
I disagree for bare metal that including endian is the right way, but agree
that __BYTE_ORDER__ is the right way to do this in general.
Thanks Jakub.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60490
--- Comment #5 from Chandler Carruth chandlerc at gmail dot com ---
(In reply to Eric Christopher from comment #4)
I disagree for bare metal that including endian is the right way, but agree
that __BYTE_ORDER__ is the right way to do this in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60490
--- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org ---
Just look what GCC does?
Say on x86_64 it does:
gcc -E -dD -xc /dev/null | grep ENDIAN
#define __ORDER_LITTLE_ENDIAN__ 1234
#define __ORDER_BIG_ENDIAN__ 4321
#define
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60458
--- Comment #5 from janus at gcc dot gnu.org ---
(In reply to janus from comment #3)
I think this should go into a separate PR.
The problem of comment 2/3 is now tracked as PR60483.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60490
--- Comment #7 from Chandler Carruth chandlerc at gmail dot com ---
(In reply to Jakub Jelinek from comment #6)
Just look what GCC does?
Say on x86_64 it does:
gcc -E -dD -xc /dev/null | grep ENDIAN
#define __ORDER_LITTLE_ENDIAN__ 1234
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60472
Uroš Bizjak ubizjak at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60483
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60472
--- Comment #2 from uros at gcc dot gnu.org ---
Author: uros
Date: Mon Mar 10 18:31:20 2014
New Revision: 208457
URL: http://gcc.gnu.org/viewcvs?rev=208457root=gccview=rev
Log:
PR libgcc/60472
* crtstuff.c (frame_dummy): Use void
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60458
Dominique d'Humieres dominiq at lps dot ens.fr changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60472
Uroš Bizjak ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60367
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
CC||jason at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60483
--- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr ---
The change in behavior occurred after r181425 (r181424 is OK).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60410
--- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr ---
See also http://gcc.gnu.org/ml/gcc-testresults/2014-03/msg00661.html
(x86_64-unknown-linux-gnu).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60491
Bug ID: 60491
Summary: Macros defined in sys/sysmacros.h pulled in by
iterator even in -std=c++11
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51749
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
CC||will at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60491
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60492
Bug ID: 60492
Summary: Using the L#param in a macro fails
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60492
--- Comment #1 from J.R. Heisey jr at heisey dot org ---
Created attachment 32327
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32327action=edit
preprocessor results for GCC 4.5.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60438
--- Comment #29 from Richard Henderson rth at gcc dot gnu.org ---
linj, that hunk is required. It's easy to produce a difference ICE
without it. I believe that even this pr's test case with -fno-crossjumping
is enough to trigger the different
1 - 100 of 135 matches
Mail list logo
