http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60498
Bug ID: 60498
Summary: error: 'snprintf' was not declared in this scope
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55383
--- Comment #9 from Magnus Reftel ---
Created attachment 32331
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32331&action=edit
Patch from comment #1, updated to apply on trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60495
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199
--- Comment #39 from Jerry DeLisle ---
OK, I can reproduce this here. The problem is the read is trying to go past
where we adjusted the string length due to things like 1X and / in the format.
Good catch, thanks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60497
Bug ID: 60497
Summary: unique_ptr tries to complete its type T even though
it's not required to be a complete type
Product: gcc
Version: unknown
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199
--- Comment #38 from Dominique d'Humieres ---
> Dominiq, can you try FM908 with something like Valgrind and also try
> different
> optimization levels and see if anything odd pops up.
I don't have access to valgrind on this machine, but if I co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60496
mikulas at artax dot karlin.mff.cuni.cz changed:
What|Removed |Added
Host|x86_64-linux-gnu|x86_64-linux-gnux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60492
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60492
--- Comment #4 from duncan_roe at acslink dot net.au ---
This works:
#define DEFINE_XML_TOKEN_STRING(n, s) const char n##a[] = #s; const wchar_t
n##w[] = L###s;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60496
Bug ID: 60496
Summary: ffreep instruction shouldn't be generated when using
i386 instruction set
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: minor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199
--- Comment #37 from Jerry DeLisle ---
Here on NIST I do not get any failures. FM908 passes FM905 and FM907 require
inspection to confirm and they look good. I only need to adjust the reference
output file that is used by the script to do the in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60495
Bug ID: 60495
Summary: ICE: in fold_convert_loc, at fold-const.c:1994
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60492
--- Comment #3 from Jonathan Wakely ---
I'm pretty sure GCC is correct, you cannot construct a wide-character string
literal like that using the preprocessor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52593
David Heidelberger (okias) changed:
What|Removed |Added
CC||david.heidelberger at ixit do
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56906
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58321
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59121
Tobias Grosser changed:
What|Removed |Added
CC||grosser at gcc dot gnu.org
--- Comment #
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59025
--- Comment #10 from Pat Haugen ---
(In reply to Jakub Jelinek from comment #9)
> Can you please try the http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60418#c21
> patch?
Trunk no longer fails with the options stated in comment #1, but I tried the
p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60494
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60494
Bug ID: 60494
Summary: A better strtol
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: libgcc
Assignee:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60483
--- Comment #3 from janus at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #2)
> The change in behavior occurred after r181425
the infamous constructor patch strikes again ...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60492
--- Comment #2 from J.R. Heisey ---
Created attachment 32330
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32330&action=edit
Source file
gcc -save-temps Bug_L_in_macro.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60367
--- Comment #8 from Jason Merrill ---
Author: jason
Date: Mon Mar 10 21:06:59 2014
New Revision: 208465
URL: http://gcc.gnu.org/viewcvs?rev=208465&root=gcc&view=rev
Log:
PR c++/60367
* call.c (convert_default_arg): Remove special handling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60493
Bug ID: 60493
Summary: g++ throws segmentation fault on simple code
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60206
--- Comment #7 from wmi at google dot com ---
After looking into the problem more, I found IVOPT may not be the root cause.
Even if IVOPT create a memory operand using two registers, if only the
following optimizations doesn't propagate the memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60206
--- Comment #6 from wmi at google dot com ---
Created attachment 32328
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32328&action=edit
2.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60438
--- Comment #31 from Richard Henderson ---
FWIW, I finished bootstrap and test with -m32 -Os -fomit-frame-pointer.
Jakub, let me know the results of your frequency testing. I'll delay
committing the patch until I return home on Wednesday.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60457
--- Comment #6 from Jan Hubicka ---
Yes, it is obvious. We will however need to get better origin representation
(supporting early inlined functions and probably also the variable origins as
they apparently can exist) later on if we ever want sav
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199
--- Comment #36 from Dominique d'Humieres ---
When running the NIST tests from a script, I see the following failure with the
patch:
FM908 fails to run
At line 727 of file /Users/dominiq/Documents/Fortran/NISTtest/NIST/FM908.f
Fortran runtime err
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51483
--- Comment #20 from bosch at adacore dot com ---
On Mar 10, 2014, at 16:11, ebotcazou at gcc dot gnu.org
wrote:
> --- Comment #19 from Eric Botcazou ---
> Taking care of it.
>
Thank you!
-Geert
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60452
Eric Botcazou changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51483
Eric Botcazou changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51483
Eric Botcazou changed:
What|Removed |Added
CC|ebotcazou at gcc dot gnu.org |
Assignee|unassigned at
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
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=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=60367
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
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=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=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=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=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=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=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=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=60472
Uroš Bizjak changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
URL|
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
--- 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=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
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
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=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 #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=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 #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
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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
CC||jakub at gcc dot gnu.org
--- Comment #1 f
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
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=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=60486
Georg-Johann Lay changed:
What|Removed |Added
Target||avr
Status|UNCONFIRMED
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=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=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=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=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=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 #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=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=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=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=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=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=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=55383
Gerald Pfeifer changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #8 from Gerald Pfei
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=60457
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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
--- 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=60482
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
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=60485
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Status|UNCONFIRME
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=60474
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
CC|
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=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=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
> 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=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,
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=60482
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
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=60411
Bernd Edlinger changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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=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=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=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 #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
1 - 100 of 133 matches
Mail list logo
