http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60480
--- Comment #1 from Andrew Pinski ---
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 changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60459
Ramana Radhakrishnan changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60298
Ramana Radhakrishnan changed:
What|Removed |Added
Keywords||ice-on-valid-code
Stat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60109
Ramana Radhakrishnan changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60106
Ramana Radhakrishnan changed:
What|Removed |Added
CC||ramana at gcc dot gnu.org
--- Comm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60106
--- Comment #2 from Bernd Edlinger ---
(In reply to Ramana Radhakrishnan from comment #1)
> Can you please add your configure flags here ?
Sure,
../gcc-4.9-20140202/configure --prefix=/home/ed/gnu/arm-linux-gnueabihf
--enable-languages=c,c++,obj
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60474
Kai Tietz changed:
What|Removed |Added
CC||ktietz at gcc dot gnu.org
--- Comment #3 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60473
--- Comment #1 from Martin ---
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 () {
unsigned long long h,l;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60474
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60419
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60429
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60461
Richard Biener changed:
What|Removed |Added
Keywords||lto, wrong-code
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60457
--- Comment #3 from Richard Biener ---
Looks obvious to me.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60478
--- Comment #2 from linzj ---
(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 ---
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)
returns NULL_TREE. OFFS
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
Se
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60438
--- Comment #25 from Jakub Jelinek ---
(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, but it fixes th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60481
--- Comment #1 from Jonathan Wakely ---
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 ---
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 = somethingelse;
_6 = somethingdiff
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60429
--- Comment #18 from Richard Biener ---
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, points-to NULL, points-to vars:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55383
Magnus Reftel changed:
What|Removed |Added
CC||magnus.reftel at gmail dot com
--- Commen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55383
--- Comment #5 from Manuel López-Ibáñez ---
(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 discards qualifiers from p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55383
--- Comment #6 from Magnus Reftel ---
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 changed:
What|Removed |Added
Keywords|patch |
--- Comment #3 from Manuel López-I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60458
--- Comment #2 from Antony Lewis ---
Here's a related example:
module A
implicit none
Type T
integer :: val = 2
contains
final :: testfree
end type
contains
subroutine testfree(this)
Type(T) this
pri
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60438
--- Comment #26 from linzj ---
(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 worth it to
> run a bootstr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55383
Manuel López-Ibáñez changed:
What|Removed |Added
Keywords||patch
--- Comment #7 from Manuel Ló
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60429
--- Comment #19 from Markus Trippelsdorf ---
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 ---
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;
struct _POINTBLOCK *next;
} P
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60438
--- Comment #27 from Jakub Jelinek ---
(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 worth it to
> run a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60452
--- Comment #7 from Jakub Jelinek ---
(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");
> > }
> >
> > i
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 commen
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 ---
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: fo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60452
--- Comment #8 from Eric Botcazou ---
> 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 taken into account too, plus d
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60411
Bernd Edlinger changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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 changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60438
--- Comment #28 from linzj ---
(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 related insn,
> check hard
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60429
--- Comment #21 from Richard Biener ---
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 local AET.
I have a fix (bah,
> 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 ---
> 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60418
--- Comment #19 from 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 ---
> Shouldn't we just prefer the original IL if
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60474
--- Comment #6 from Richard Biener ---
Author: rguenth
Date: Mon Mar 10 13:27:16 2014
New Revision: 208451
URL: http://gcc.gnu.org/viewcvs?rev=208451&root=gcc&view=rev
Log:
2014-03-10 Richard Biener
PR middle-end/60474
* tree.c (signe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60474
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60481
--- Comment #2 from Dmitry Gorbachev ---
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 [disabled]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60485
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Status|UNCONFIRME
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
Priori
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60482
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60457
--- Comment #4 from Jakub Jelinek ---
Author: jakub
Date: Mon Mar 10 14:55:20 2014
New Revision: 208454
URL: http://gcc.gnu.org/viewcvs?rev=208454&root=gcc&view=rev
Log:
PR ipa/60457
* ipa.c (symtab_remove_unreachable_nodes): Don't call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60464
--- Comment #8 from Richard Earnshaw ---
(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 time. Each enabled entry
pra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60457
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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
Componen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55383
Gerald Pfeifer changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #8 from Gerald Pfei
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60452
Jakub Jelinek changed:
What|Removed |Added
Component|tree-optimization |rtl-optimization
--- Comment #9 from Jaku
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53492
--- Comment #5 from Jason Merrill ---
Author: jason
Date: Mon Mar 10 15:44:50 2014
New Revision: 208455
URL: http://gcc.gnu.org/viewcvs?rev=208455&root=gcc&view=rev
Log:
PR c++/53492
* parser.c (cp_parser_class_head): Also check PRIMARY_T
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60418
--- Comment #20 from H.J. Lu ---
(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 adding/removing
> a preheader?
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: UNCONFIRM
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
Priori
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58678
Jason Merrill changed:
What|Removed |Added
Assignee|jason at gcc dot gnu.org |hubicka at gcc dot
gnu.org
--- Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59121
--- Comment #14 from Mircea Namolaru ---
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 ---
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
+++ gcc/tree-ssa-reassoc.c2014-03-10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59121
--- Comment #15 from Jeffrey A. Law ---
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 after the 4.9 release.
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 ---
(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 ---
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 changed:
What|Removed |Added
CC||gjl at gcc dot gnu.org
--- Comment #1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60486
Georg-Johann Lay changed:
What|Removed |Added
Target||avr
Status|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60486
--- Comment #3 from Georg-Johann Lay ---
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:
sbiw r24,1 ; 6
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
Sev
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60482
Jakub Jelinek changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org
--- Comment #3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60490
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60490
--- Comment #2 from Eric Christopher ---
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 changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60490
--- Comment #4 from Eric Christopher ---
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 ---
(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 general.
>
> Thanks Jakub.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60490
--- Comment #6 from Jakub Jelinek ---
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 __ORDER_PDP_ENDIAN__ 3412
#define __BYTE_OR
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 ---
(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
> #define __ORDER_BIG_ENDIAN__
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60472
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
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=208457&root=gcc&view=rev
Log:
PR libgcc/60472
* crtstuff.c (frame_dummy): Use void **jcr_l
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60458
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60472
Uroš Bizjak changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
URL|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60367
Jonathan Wakely changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60483
--- Comment #2 from Dominique d'Humieres ---
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 ---
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
even in -std=c++11
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51749
Jonathan Wakely changed:
What|Removed |Added
CC||will at wmitchell dot net
--- Comment #
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60491
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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 ---
Created attachment 32327
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32327&action=edit
preprocessor results for GCC 4.5.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60438
--- Comment #29 from Richard Henderson ---
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 ICE.
Jakub, it's way mor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60367
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60438
--- Comment #30 from Jakub Jelinek ---
(In reply to Richard Henderson from comment #29)
> 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60339
--- Comment #2 from Jan Kratochvil ---
(In reply to Eric Botcazou from comment #1)
> This is a non-inlined subroutine nested in an inlined subroutine, see
> 3.3.8.4.
OK, thanks for the pointer.
> > BTW master (4.9 - r208124) failed on GNAT inte
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199
--- Comment #35 from Dominique d'Humieres ---
> http://gcc.gnu.org/ml/fortran/2014-03/msg00079.html
The test
character buffer*10
integer i,j
DO j=1,
write(buffer,'(i4)') j
read(buffer,'(i10)') i
1 - 100 of 133 matches
Mail list logo
