https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80173
Jakub Jelinek changed:
What|Removed |Added
Summary|[5/6/7 Regression] ICE in |[5/6 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80025
Jakub Jelinek changed:
What|Removed |Added
Summary|[5/6/7 Regression] ICE w/ |[5/6 Regression] ICE w/ -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26461
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80251
--- Comment #4 from Jakub Jelinek ---
Author: jakub
Date: Fri Mar 31 06:40:39 2017
New Revision: 246609
URL: https://gcc.gnu.org/viewcvs?rev=246609&root=gcc&view=rev
Log:
PR libstdc++/80251
c-family/
* c-common.h (enum rid): Add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80173
--- Comment #4 from Jakub Jelinek ---
Author: jakub
Date: Fri Mar 31 06:38:35 2017
New Revision: 246608
URL: https://gcc.gnu.org/viewcvs?rev=246608&root=gcc&view=rev
Log:
PR middle-end/80173
* expmed.c (store_bit_field_1): Don't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80163
--- Comment #5 from Jakub Jelinek ---
Author: jakub
Date: Fri Mar 31 06:32:46 2017
New Revision: 246607
URL: https://gcc.gnu.org/viewcvs?rev=246607&root=gcc&view=rev
Log:
PR middle-end/80163
* varasm.c (initializer_constant_valid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49498
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80025
--- Comment #14 from Jakub Jelinek ---
Author: jakub
Date: Fri Mar 31 06:05:47 2017
New Revision: 246606
URL: https://gcc.gnu.org/viewcvs?rev=246606&root=gcc&view=rev
Log:
PR debug/80025
* cselib.h (rtx_equal_for_cselib_1): Add d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80258
John Ousterhout changed:
What|Removed |Added
CC||ouster at cs dot stanford.edu
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60818
--- Comment #19 from Alan Modra ---
Yes, r246294 powerpc64le-linux-gcc -O1 -misel ICEs on the last testcase. An
earlier compiler I had laying around, 7.0.0 20160616, does not.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80257
--- Comment #3 from nightstrike ---
$ ./test.exe
Program received signal SIGSEGV: Segmentation fault - invalid memory reference.
Backtrace for this error:
#0 0x in ???
#1 0x in ???
#2 0x in ???
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80267
Jonathan Wakely changed:
What|Removed |Added
Keywords||ice-on-valid-code
Status|U
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26461
John Ousterhout changed:
What|Removed |Added
CC||ouster at cs dot stanford.edu
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80268
Bug ID: 80268
Summary: [concepts] list of candidates for ambiguous call
includes unconstrained function
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Keywords
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43496
Segher Boessenkool changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80134
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67288
--- Comment #7 from Segher Boessenkool ---
*** Bug 80134 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80132
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80056
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17593
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80267
Bug ID: 80267
Summary: Compiling aborts when template/auto/lambda occur in
some way
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27212
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80258
--- Comment #9 from Tor Myklebust ---
OK, I gather that the gcc developers, as a group, are against changing this
behaviour. (I can speculate why; almost all code that uses TLS will see a
slowdown.)
In order to work around this behaviour, one n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20614
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80189
--- Comment #5 from Jakub Jelinek ---
Author: jakub
Date: Thu Mar 30 20:31:40 2017
New Revision: 246599
URL: https://gcc.gnu.org/viewcvs?rev=246599&root=gcc&view=rev
Log:
PR translation/80189
* gimplify.c (omp_default_clause): Us
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80246
Peter Bergner changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #7 from Peter Bergner
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80246
Peter Bergner changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80246
--- Comment #5 from Peter Bergner ---
Author: bergner
Date: Thu Mar 30 20:09:32 2017
New Revision: 246596
URL: https://gcc.gnu.org/viewcvs?rev=246596&root=gcc&view=rev
Log:
gcc/
Backport from mainline
2017-03-30 Peter Bergner
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80246
--- Comment #4 from Peter Bergner ---
Author: bergner
Date: Thu Mar 30 20:06:06 2017
New Revision: 246595
URL: https://gcc.gnu.org/viewcvs?rev=246595&root=gcc&view=rev
Log:
gcc/
Backport from mainline
2017-03-30 Peter Bergner
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80246
--- Comment #3 from Peter Bergner ---
Author: bergner
Date: Thu Mar 30 19:57:20 2017
New Revision: 246594
URL: https://gcc.gnu.org/viewcvs?rev=246594&root=gcc&view=rev
Log:
gcc/
PR target/80246
* config/rs6000/dfp.md (dfp_dxex_):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49498
--- Comment #26 from Jeffrey A. Law ---
So I had hoped this old BZ would be fixed by the changes for 71437. Sadly,
that is not the case.
*But* the WIP for for 78496 does happen to fix this BZ. In fact, we only need
the hunks from 78496 which a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79929
--- Comment #3 from Harald Anlauf ---
I've slightly reduced the example to the following:
% cat gfcbug138c.f90
subroutine gfcbug138 (yerrmsg)
character(kind=1,len=*) :: yerrmsg
yerrmsg = 1_"bug: " // yerrmsg
end subroutine gfcbug138
The du
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80046
--- Comment #5 from janus at gcc dot gnu.org ---
(In reply to janus from comment #4)
> I'm currently regtesting a draft patch ...
After regtesting completed successfully, it was posted for review here:
https://gcc.gnu.org/ml/fortran/2017-03/msg0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79534
--- Comment #7 from James Greenhalgh ---
I'm not sure there are any bugs here to fix, though I can still reproduce the
performance differences.
First up, basic block reordering causes an issue across all microarchitectures
on which I've looked a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80241
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80233
--- Comment #9 from Segher Boessenkool ---
Yeah exactly... so I'm conflicted whether we need to backport this or not.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64883
--- Comment #44 from Jonathan Wakely ---
Or my view on what our tests should do have "evolved" (i.e. completely
contradicted my old view!)
If mingw says that isn't a valid program or simply can't support it for valid
reasons, then the right thin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64883
--- Comment #43 from nightstrike ---
Jon,
I was referring to your Comment 9:
The failing test is only intended to check that libstdc++ is consistent about
using the uglified attributes. Anything outside libstdc++ can do whatever it
wants.
App
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64883
--- Comment #42 from Jonathan Wakely ---
(In reply to nightstrike from comment #41)
> It seems to me that the test itself is a bit overzealous. If the intent is
> to ensure just that libstdc++ sources don't use certain words, well that's
> not e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64883
nightstrike changed:
What|Removed |Added
CC||jon_y at users dot
sourceforge.net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80257
--- Comment #2 from Dominique d'Humieres ---
What is the output of
subroutine ppTest(f)
implicit none
external f
call f()
end subroutine ppTest
Program RunTimeCheck
implicit none
external :: ppTest
procedure(), pointer :: pptr
pp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80263
--- Comment #7 from Pedro Alves ---
I filed a corresponding GDB bug here:
Support DW_TAG_base_type with no name
https://sourceware.org/bugzilla/show_bug.cgi?id=21335
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80263
--- Comment #6 from Pedro Alves ---
Yes, agreed.
I haven't investigated yet why it ends up with that "",
but it's likely that the hack was incomplete and that's a red herring.
Hopefully GDB won't have some hard-to-eliminate dependency on a look
ux/ilp32/libada"
"-mabi=ilp32" -fno-diagnostics-show-caret -gnatez -mlittle-endian
../../gcc/gcc/testsuite/gnat.dg/lto21_pkg2.adb
+===GNAT BUG DETECTED==+
| 7.0.1 20170330 (experimental) (aarch64-suse-linux) GCC error:|
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80266
Andreas Schwab changed:
What|Removed |Added
Target Milestone|--- |7.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265
Bug ID: 80265
Summary: __builtin_{memcmp,memchr,strlen} are not usable in
constexpr functions
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80263
--- Comment #5 from Jakub Jelinek ---
For GDB, guess you should not warn for DWARF >= 5.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33661
Andrew Pinski changed:
What|Removed |Added
CC||gdelugre.gcc at subvert dot
techno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64951
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64951
Andrew Pinski changed:
What|Removed |Added
CC||blubban at gmail dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80264
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
tual output:
First one: Compiler silently emits a blank function (other than an unused
variable warning)
Second: movl $42, %ebx (%eax on -O1 or higher)
Third: As expected
Tested versions:
g++ 7.0.1 20170330 x86_64-linux-gnu (Godbolt)
g++ 6.2.0-5ubuntu12 x86_64-linux-gnu (Lubuntu 16.10)
g++ 4.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80263
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60818
--- Comment #18 from Segher Boessenkool ---
Okay, this I can reproduce (no -fPIC needed, not even -m32). Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79876
--- Comment #13 from Jakub Jelinek ---
Seems libgomp has a bug that without {,G}OMP_STACKSIZE and with OMP_DISPLAY_ENV
it displays random (uninitialized) value for the stack size, so I need to test
something like:
2017-03-30 Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79876
--- Comment #12 from Jakub Jelinek ---
Of course, the testcase was not using libgomp at all and OMP_STACKSIZE is an
env var used by libgomp only.
So, this means whatever darwin libpthread are using is using extremely small
default for the pthread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80263
--- Comment #3 from Pedro Alves ---
Possible solutions could be:
#1 - emit the underlying type instead.
#2 - emit no name.
#2 seems to be valid DWARF5, which says (page 103):
"A base type entry may have a DW_AT_name attribute whose value is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77333
--- Comment #23 from Martin Jambor ---
Fixed on trunk so far. I will prepare & test backports.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80263
Richard Biener changed:
What|Removed |Added
Keywords||wrong-debug
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77333
--- Comment #22 from Martin Jambor ---
Author: jamborm
Date: Thu Mar 30 13:51:02 2017
New Revision: 246589
URL: https://gcc.gnu.org/viewcvs?rev=246589&root=gcc&view=rev
Log:
[PR 77333] Fixup fntypes of gimple calls of clones
2017-03-30 Martin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80263
--- Comment #1 from Pedro Alves ---
The consequence is that that internal type's name can mask out a user-defined
type with the same name. For example:
$ cat sizetype2.c
char array[1];
typedef struct sizetype { char c; } sizetype;
sizetype sz;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80263
Bug ID: 80263
Summary: gcc's internal type "sizetype" leaks out as base type
name in the DWARF info
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80206
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79876
--- Comment #11 from Dominique d'Humieres ---
> and see what it prints?
RLIMIT_STACK cur 67104768 max 67104768
PTHREAD_STACK_MIN 8192
main thread pthread_get_stacksize_np 67104768
other thread pthread_get_stacksize_np 524288
other thread pthread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80206
--- Comment #5 from Jakub Jelinek ---
Author: jakub
Date: Thu Mar 30 13:29:28 2017
New Revision: 246588
URL: https://gcc.gnu.org/viewcvs?rev=246588&root=gcc&view=rev
Log:
PR target/80206
* config/i386/sse.md
(_vextract_ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80173
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80233
--- Comment #8 from Jakub Jelinek ---
It is probably latent there, there were major changes in the trap and
conditional trap handling in GCC 7, so we likely don't have a testcase right
now that would ICE in 6.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80233
--- Comment #7 from Segher Boessenkool ---
Is it fixed? Can this not happen on GCC 6?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80232
--- Comment #5 from vincenzo Innocente ---
I confirm that gather is almost twice as fast on
Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz
w/r/t
Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz
(used a benchmark version of PR80248 example)
so on skylake, knl,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80262
--- Comment #5 from rguenther at suse dot de ---
On Thu, 30 Mar 2017, stefan at reservoir dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80262
>
> --- Comment #4 from Stefan M Freudenberger ---
> My original example involved a M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80262
--- Comment #4 from Stefan M Freudenberger ---
My original example involved a MEM with a constant offset, and yielded an ICE:
internal compiler error: tree check: expected integer_cst, have
addr_space_convert_expr in decompose, at tree.h
Maybe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80251
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80173
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80135
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35878
Ville Voutilainen changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ville.voutilainen at
gmail do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69853
Ville Voutilainen changed:
What|Removed |Added
Status|SUSPENDED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80238
--- Comment #5 from Jonathan Wakely ---
(In reply to Mike from comment #4)
> (In reply to Richard Biener from comment #3)
> > Can you try to build in a separate object directory instead?
> And where to put the folder
https://gcc.gnu.org/wiki/FAQ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80238
--- Comment #4 from Mike ---
(In reply to Richard Biener from comment #3)
> So if comment #5 is correct then it seems we are building stage1 genmatch
> against the (not yet built) libstdc++ headers but linking
> (-static-libstdc++) against the ho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80189
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80262
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80262
--- Comment #2 from Stefan M Freudenberger ---
Created attachment 41088
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41088&action=edit
Output from -fdump-tree-esra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80262
--- Comment #1 from Stefan M Freudenberger ---
Created attachment 41087
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41087&action=edit
Output from -fdump-tree-forwprop1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80262
Bug ID: 80262
Summary: address space gets lost in memory access
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80238
Richard Biener changed:
What|Removed |Added
CC||doko at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80260
Richard Biener changed:
What|Removed |Added
Priority|P3 |P4
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80258
Richard Biener changed:
What|Removed |Added
Target||x86_64-*-*
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80259
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79876
--- Comment #10 from Jakub Jelinek ---
(In reply to Dominique d'Humieres from comment #9)
> > I have read people complaining about very low OMP stack sizes
> > on OSX.
>
> What is setting the limit?
Probably OSX thread library?
Can you try som
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70478
Andreas Krebbel changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80251
--- Comment #2 from Jonathan Wakely ---
It's only existed for less than a month,. and it requires a new intrinsic from
the compiler which doesn't exist yet.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80260
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80261
Bug ID: 80261
Summary: Worse code generated compared to clang with modulo
operation
Product: gcc
Version: 6.3.1
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80258
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80259
--- Comment #3 from Jakub Jelinek ---
With untested:
--- gcc/decl2.c.jj 2017-02-21 18:59:36.0 +0100
+++ gcc/decl2.c 2017-03-30 10:16:03.972113673 +0200
@@ -888,9 +888,18 @@ grokfield (const cp_declarator *declarat
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80259
--- Comment #2 from Jakub Jelinek ---
duplicate_decls is called with the DECL_INITIAL is still being NULL on the
newdecl (and olddecl has it a BLOCK).
#0 duplicate_decls (newdecl=,
olddecl=, newdecl_is_friend=true)
at ../../gcc/cp/decl.c:140
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80259
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80197
--- Comment #8 from rguenther at suse dot de ---
On Wed, 29 Mar 2017, amonakov at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80197
>
> --- Comment #7 from Alexander Monakov ---
> No, with fixed-up inlining -ftracer s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80260
Bug ID: 80260
Summary: [7 Regression] ICE with polymorphic array section
actual argument
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80256
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
1 - 100 of 104 matches
Mail list logo
