https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68292
Eric Botcazou changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68292
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68162
--- Comment #10 from Joseph S. Myers ---
I have verified that the patch in comment#7, (a) on its own and (b) together
with my patch, does not cause any regressions on x86_64-pc-linux-gnu. My
inclination would be that this patch should go in,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68117
--- Comment #18 from Gary Funck ---
(In reply to Gary Funck from comment #17)
> We're seeing this ICE on x86-64, while building the 32-bit libgfortran.
> We're building the target libraries with -O3 with GCC compiler checks
> enabled.
Taking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67220
H.J. Lu changed:
What|Removed |Added
Attachment #36697|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67784
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67784
--- Comment #7 from Marek Polacek ---
Author: mpolacek
Date: Thu Nov 12 21:07:04 2015
New Revision: 230273
URL: https://gcc.gnu.org/viewcvs?rev=230273=gcc=rev
Log:
PR c/67784
* c-parser.c (c_parser_for_statement): Reclassify the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68318
kargl at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68294
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68293
Zdenek Sojka changed:
What|Removed |Added
CC||ienkovich at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68305
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68304
Richard Biener changed:
What|Removed |Added
Component|middle-end |rtl-optimization
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68306
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68268
--- Comment #6 from isearcher at 126 dot com ---
I "make distclean",and make again. Everything goes well. And gfortran is made.
The problem is solved. thanks for the advice.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68268
--- Comment #7 from Dominique d'Humieres ---
> I "make distclean",and make again. Everything goes well. And gfortran is made.
> The problem is solved. thanks for the advice.
You're welcome!
Further advice, 4.8.0 is quite old and unsupported:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68293
James Greenhalgh changed:
What|Removed |Added
Target|aarch64-unknown-linux-gnu |aarch64-unknown-linux-gnu,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68308
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68296
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |6.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58497
--- Comment #11 from Richard Biener ---
Author: rguenth
Date: Thu Nov 12 09:00:37 2015
New Revision: 230216
URL: https://gcc.gnu.org/viewcvs?rev=230216=gcc=rev
Log:
2015-11-12 Richard Biener
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68288
TC changed:
What|Removed |Added
CC||rs2740 at gmail dot com
--- Comment #1 from TC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68303
Jan Kratochvil changed:
What|Removed |Added
CC||jan.kratochvil at redhat dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68062
Richard Biener changed:
What|Removed |Added
CC||uweigand at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67239
--- Comment #7 from Richard Biener ---
(In reply to H.J. Lu from comment #6)
> Does this patch
>
> diff --git a/gcc/tree-ssa-sccvn.c b/gcc/tree-ssa-sccvn.c
> index 2ac3828..8b57875 100644
> --- a/gcc/tree-ssa-sccvn.c
> +++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68298
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68305
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68296
James Greenhalgh changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68293
James Greenhalgh changed:
What|Removed |Added
CC||sch...@linux-m68k.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68300
--- Comment #1 from Markus Trippelsdorf ---
From class.c:
1629 /* Return true, iff class T has a non-virtual destructor that is
1630accessible from outside the class heirarchy (i.e. is public, or
1631there's a suitable friend. */
1632
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68308
Bug ID: 68308
Summary: [6 Regression] ICE: tree check: expected integer_cst,
have var_decl in decompose, at tree.h:5105
Product: gcc
Version: 6.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68307
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68302
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |5.3
--- Comment #1 from Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68309
Bug ID: 68309
Summary: [C++14] Expanding a captured parameter pack with
std::forward(args) fails.
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68290
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68269
Gary Funck changed:
What|Removed |Added
CC||gary at intrepid dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68318
kargl at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68117
--- Comment #19 from Gary Funck ---
We see similar failure an x86-64 opensuse VM in the 32-bit libgfortran build
but on a different file: eoshift.c. After removing the .lo and .o files and
re-running make, the build completed without error. As
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68115
John David Anglin changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #3 from John David
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68323
Bug ID: 68323
Summary: chrono reference to ‘literals’ namespace is ambiguous
when using gnu-versioned-namespace
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68117
--- Comment #17 from Gary Funck ---
We're seeing this ICE on x86-64, while building the 32-bit libgfortran.
We're building the target libraries with -O3 with GCC compiler checks enabled.
libtool: compile:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67239
--- Comment #9 from H.J. Lu ---
Created attachment 36699
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36699=edit
tree dump
It is compiled with -O2 -mx32.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68319
kargl at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68290
Eric Botcazou changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67872
Martin Sebor changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68318
--- Comment #4 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Fri Nov 13 00:14:32 2015
New Revision: 230278
URL: https://gcc.gnu.org/viewcvs?rev=230278=gcc=rev
Log:
2015-11-12 Steven G. Kargl
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68322
Bug ID: 68322
Summary: -Wodr warning on templates should list the
instantiation
Product: gcc
Version: 5.2.1
Status: UNCONFIRMED
Severity: minor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67239
--- Comment #10 from H.J. Lu ---
(In reply to Richard Biener from comment #7)
> No, even for the false edge we can record proper expressions, see
> record_conds and how it handles the cases if the condition was true or false.
>
record_conds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68318
--- Comment #5 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Fri Nov 13 01:11:10 2015
New Revision: 230282
URL: https://gcc.gnu.org/viewcvs?rev=230282=gcc=rev
Log:
2015-11-12 Steven G. Kargl
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68277
--- Comment #7 from Kazumoto Kojima ---
(In reply to Kazumoto Kojima from comment #6)
I've changed the predicate of the 2nd operand to arith_operand instead
of const_int_operand in your patch and run testsuite. There is one new
failure:
FAIL:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67613
--- Comment #2 from David Malcolm ---
Author: dmalcolm
Date: Fri Nov 13 01:59:03 2015
New Revision: 230285
URL: https://gcc.gnu.org/viewcvs?rev=230285=gcc=rev
Log:
PR driver/67613 - spell suggestions for misspelled command line options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68310
Bug ID: 68310
Summary: [6 Regression] Invalid read of size 1 in
options-save.c:3521
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68309
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67265
--- Comment #15 from Eric Botcazou ---
Author: ebotcazou
Date: Thu Nov 12 12:01:40 2015
New Revision: 230249
URL: https://gcc.gnu.org/viewcvs?rev=230249=gcc=rev
Log:
PR target/67265
* config/i386/i386.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68271
--- Comment #17 from Dominique d'Humieres ---
Ny need to keep this PR opened?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68271
--- Comment #18 from Jakub Jelinek ---
Yes, so that we don't forget to apply a real fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50221
Paul Thomas changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68291
--- Comment #2 from Ilya Enkovich ---
Should be fixed by r230238.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68293
--- Comment #6 from Ilya Enkovich ---
Should be fixed by r230238.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68062
--- Comment #9 from rguenther at suse dot de ---
On Thu, 12 Nov 2015, uweigand at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68062
>
> --- Comment #8 from Ulrich Weigand ---
> (In reply to Richard Biener from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68288
--- Comment #2 from lucdanton at free dot fr ---
(In reply to TC from comment #1)
> This behavior looks correct to me. (Clang behaves identically.)
>
> 0e1_e+0 is a valid pp-number, so per max munch it must be parsed that way,
> as a single
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68271
Dominique d'Humieres changed:
What|Removed |Added
Severity|blocker |normal
--- Comment #19 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68305
--- Comment #4 from Ilya Enkovich ---
Author: ienkovich
Date: Thu Nov 12 12:59:05 2015
New Revision: 230252
URL: https://gcc.gnu.org/viewcvs?rev=230252=gcc=rev
Log:
gcc/
PR tree-optimization/68305
* tree-vect-slp.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68310
Richard Biener changed:
What|Removed |Added
Component|c |middle-end
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68134
Ramana Radhakrishnan changed:
What|Removed |Added
CC||ienkovich at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68312
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63932
Paul Thomas changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66408
Paul Thomas changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68312
Bug ID: 68312
Summary: [6 Regression] Memory leaks in cilkplus
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67265
--- Comment #14 from Eric Botcazou ---
Author: ebotcazou
Date: Thu Nov 12 11:59:23 2015
New Revision: 230247
URL: https://gcc.gnu.org/viewcvs?rev=230247=gcc=rev
Log:
PR target/67265
* config/i386/i386.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68286
Markus Trippelsdorf changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68062
--- Comment #8 from Ulrich Weigand ---
(In reply to Richard Biener from comment #7)
> I think there was some inconsistencies in C vs. C++ FEs in this area (but as
> usual I don't remember exactly but I remember Uli complaining about it again
>
: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
clang compiling gcc trunk dated 20151112 says
../../src/trunk/gcc/ipa-icf.c:3041:73: warning: multiple unsequenced
modifications to 'class_id' [-Wunsequenced]
Source code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68305
Ilya Enkovich changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68309
--- Comment #2 from Markus Trippelsdorf ---
Without headers:
namespace std {
template _Tp forward(int);
template class initializer_list {
int *_M_array;
unsigned long _M_len;
};
}
using namespace std;
template void print(Ts... args) {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68283
Dominique d'Humieres changed:
What|Removed |Added
CC||pault at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68312
--- Comment #1 from Martin Liška ---
Created attachment 36696
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36696=edit
valgrind2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68310
--- Comment #1 from Uroš Bizjak ---
PR 67484 ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68286
--- Comment #4 from Ilya Enkovich ---
Should be fixed by r230238.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67265
--- Comment #13 from Eric Botcazou ---
Author: ebotcazou
Date: Thu Nov 12 11:55:11 2015
New Revision: 230245
URL: https://gcc.gnu.org/viewcvs?rev=230245=gcc=rev
Log:
PR target/67265
* config/i386/i386.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68306
Ulrich Weigand changed:
What|Removed |Added
CC||uweigand at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68325
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68317
Markus Trippelsdorf changed:
What|Removed |Added
CC||su at cs dot ucdavis.edu
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68326
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68197
--- Comment #2 from Mickael Guene ---
Anyway it's a bad usage since index must come from xalloc.
I was unable to find what the specifications say in case of using a negative
index (or invalid index), do you have some inputs in this case ?
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20151112 (experimental) [trunk revision 230270] (GCC)
$
$ gcc-trunk -O2 -c small.c
small.c: In function ‘fn2’:
small.c:12:27: warning: iteration 2147483638 invokes undefined behavior
[-Waggressive-loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68117
--- Comment #20 from Markus Trippelsdorf ---
I haven't seen this issue since Jason's GC related C++ patches went in:
r230201 and r230202.
But of course this may well be another statistical fluke.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68311
--- Comment #1 from Andrew Pinski ---
Hmm, I though common inside {} are sequenced points.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68293
--- Comment #7 from Zdenek Sojka ---
At least for aarch64, this is fixed.
/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20151112 (experimental) [trunk revision 230270] (GCC)
$
$ gcc-trunk -O2 -c small.c
$ gcc-5.2 -O3 -c small.c
$
$ gcc-trunk -O3 -c small.c
small.c: In function ‘fn1’:
small.c:5:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68311
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68198
--- Comment #6 from Jeffrey A. Law ---
I see what's happening here (and boy it's much better to be debugging with real
screens and a good night's sleep).
So imagine what happens when you build a thread path and on that path you've
got a block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68313
Bug ID: 68313
Summary: "using" shadows declaration
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68306
--- Comment #5 from Richard Biener ---
Author: rguenth
Date: Thu Nov 12 14:02:44 2015
New Revision: 230260
URL: https://gcc.gnu.org/viewcvs?rev=230260=gcc=rev
Log:
2015-11-12 Richard Biener
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68247
--- Comment #1 from vries at gcc dot gnu.org ---
RFC: https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01492.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68247
vries at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68306
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68192
Torbjörn Gard changed:
What|Removed |Added
CC||tgard at opentext dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67478
David Edelsohn changed:
What|Removed |Added
Target||powerpc-ibm-aix*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68314
Bug ID: 68314
Summary: [6 Regression] Invalid read in
build_pbb_minimal_scattering_polyhedrons
(graphite-sese-to-poly.c:148)
Product: gcc
Version: 6.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67239
--- Comment #8 from H.J. Lu ---
(In reply to Richard Biener from comment #7)
> Can you please attach -details dumps of the pass instance that does this?
It is done in fre pass.
> Note that the large number '5368709811' (0x1fff) might point
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67784
--- Comment #3 from joseph at codesourcery dot com ---
The reason is as stated in comment#1: it's necessary to examine the token
after "if ( 1 ) ;" to see if it's the "else" keyword; if it were "else",
that token would be within the C99/C11
1 - 100 of 137 matches
Mail list logo