https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99029
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98950
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99003
--- Comment #2 from CVS Commits ---
The master branch has been updated by Martin Liska :
https://gcc.gnu.org/g:d44f56f2b2d4f0a827ba6f08aebc715786225c6f
commit r11-7163-gd44f56f2b2d4f0a827ba6f08aebc715786225c6f
Author: Martin Liska
Date: Tue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99002
--- Comment #3 from CVS Commits ---
The master branch has been updated by Martin Liska :
https://gcc.gnu.org/g:5da5d8a02c6799e60970fef72ee8c1c3d033a5e5
commit r11-7164-g5da5d8a02c6799e60970fef72ee8c1c3d033a5e5
Author: Martin Liska
Date: Tue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99003
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99002
Martin Liška changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78251
Eric Gallager changed:
What|Removed |Added
CC||casner at acm dot org
--- Comment #13 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99002
Martin Liška changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98950
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|rguenth at gcc d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99042
--- Comment #2 from Antonio Chirizzi ---
Hi David,
just curious of what you mean with "unknown function". Is it something that has
not been declared or is not known to the compiler up to that point?
Thanks,
-Antonio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99025
--- Comment #2 from Uroš Bizjak ---
Comment on attachment 50154
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50154
gcc11-pr99025.patch
>2021-02-09 Jakub Jelinek
>+ if (SUBREG_P (operands[1]))
>+operands[1] = force_reg (V2SFmode,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99026
Martin Liška changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99036
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99024
--- Comment #2 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:d997565c41a8a5783bf076437208f38d8ea39ced
commit r11-7165-gd997565c41a8a5783bf076437208f38d8ea39ced
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99024
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99029
--- Comment #2 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:9eb7669cc040882992dee3621ebacf4f0311e8a0
commit r11-7166-g9eb7669cc040882992dee3621ebacf4f0311e8a0
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99029
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99054
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99037
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692
--- Comment #17 from Mark Wielaard ---
Thanks for the step-by-step explanation of the assembly instructions and
calling conventions.
(In reply to Segher Boessenkool from comment #16)
> (In reply to Mark Wielaard from comment #13)
> > ==25741== U
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99007
--- Comment #5 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:bd0e37f68a3aed944df4eb739a0734bb87153749
commit r11-7167-gbd0e37f68a3aed944df4eb739a0734bb87153749
Author: Jakub Jelinek
Date: We
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99055
Bug ID: 99055
Summary: memory leak in warn_parm_array_mismatch
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99025
--- Comment #3 from Jakub Jelinek ---
(In reply to Uroš Bizjak from comment #2)
> Comment on attachment 50154 [details]
> gcc11-pr99025.patch
>
> >2021-02-09 Jakub Jelinek
>
> >+ if (SUBREG_P (operands[1]))
> >+operands[1] = force_reg (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99043
Tobias Burnus changed:
What|Removed |Added
Last reconfirmed||2021-02-10
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99054
--- Comment #2 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:72932511053596091ad291539022b51d9f2ba418
commit r11-7168-g72932511053596091ad291539022b51d9f2ba418
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99034
Martin Liška changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97346
--- Comment #4 from Richard Biener ---
So like the following? Note the leak is the allcoation from ipa_init
being not released when we do the vec_alloc in
ipa_reference_write_optimization_summary (maybe this function wants to
use its own private
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97346
--- Comment #5 from Richard Biener ---
(In reply to Richard Biener from comment #4)
> So like the following? Note the leak is the allcoation from ipa_init
> being not released when we do the vec_alloc in
> ipa_reference_write_optimization_summar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98985
--- Comment #2 from m.heinzler at heinzler dot de ---
(In reply to Jonathan Wakely from comment #1)
> I'll fix it by using MoveFileExW in posix::rename instead.
>
> MoveFileExW seems to have some weird differences from POSIX rename when the
> so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97346
--- Comment #6 from Richard Biener ---
I'm testing the following which fixes the leak(s)
diff --git a/gcc/ipa-reference.c b/gcc/ipa-reference.c
index 2ea2a6d5327..a6b79fb9381 100644
--- a/gcc/ipa-reference.c
+++ b/gcc/ipa-reference.c
@@ -966,8 +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99054
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99042
--- Comment #3 from David Malcolm ---
(In reply to Antonio Chirizzi from comment #2)
> just curious of what you mean with "unknown function". Is it something that
> has not been declared or is not known to the compiler up to that point?
A functi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391
--- Comment #13 from David Malcolm ---
(In reply to Michael Cronenworth from comment #12)
> That's the Linux GCC. You will want to see the version for MinGW:
> mingw-gcc-9.2.1-6.fc32 - which does not crash so I'm not surprised you
> didn't crash.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391
--- Comment #14 from David Malcolm ---
(In reply to David Malcolm from comment #13)
> $ rpm -q mock
> mock-2.3-1.fc32.noarch
Sorry, my bad; I had quite an old mock. I've upgraded, and the build is now
progressing beyond that point.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99002
--- Comment #6 from CVS Commits ---
The master branch has been updated by Martin Liska :
https://gcc.gnu.org/g:57d1b68d6582efec5a7ca63ea56a1cedbfe6e874
commit r11-7169-g57d1b68d6582efec5a7ca63ea56a1cedbfe6e874
Author: Martin Liska
Date: Wed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99026
--- Comment #2 from CVS Commits ---
The master branch has been updated by Martin Liska :
https://gcc.gnu.org/g:57d1b68d6582efec5a7ca63ea56a1cedbfe6e874
commit r11-7169-g57d1b68d6582efec5a7ca63ea56a1cedbfe6e874
Author: Martin Liska
Date: Wed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98986
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99056
Bug ID: 99056
Summary: NIOS GCC optimizaton issue with memset
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: objc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98986
--- Comment #4 from rguenther at suse dot de ---
On Wed, 10 Feb 2021, rsandifo at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98986
>
> rsandifo at gcc dot gnu.org changed:
>
>What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99026
Martin Liška changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99002
Martin Liška changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99035
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99057
Bug ID: 99057
Summary: Memory leak in cp_parser_selection_statement
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99056
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99057
Martin Liška changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95265
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95958
Bug 95958 depends on bug 95265, which changed state.
Bug 95265 Summary: aarch64: suboptimal code generation for common neon
intrinsic sequence involving shrn and mull
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95265
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99056
--- Comment #2 from Leonardo Pacheco ---
Yes, your result shows that the issue is already fixed.
Thanks, will try to open bug report to Altera.
Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82074
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95958
Bug 95958 depends on bug 82074, which changed state.
Bug 82074 Summary: [aarch64] vmlsq_f32 compiled into 2 instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82074
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97346
--- Comment #7 from Jan Hubicka ---
I tested yesterday this one (which makes the lifetime bit more explicit
- during propagation it is for dumps only). Sorry for not posting it
earlier. I just wanted to double check tha tleak is gone.
diff --git
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97346
--- Comment #8 from Richard Biener ---
(In reply to Jan Hubicka from comment #7)
> I tested yesterday this one (which makes the lifetime bit more explicit
> - during propagation it is for dumps only). Sorry for not posting it
> earlier. I just wa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95964
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2021-02-10
Ever confirm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99057
--- Comment #1 from Martin Liška ---
And this one please for C FE:
$ cat wslay.i
typedef long unsigned int size_t;
typedef struct {
}
__sigset_t;
typedef int (*__compar_fn_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99058
Bug ID: 99058
Summary: Consider adding a note about std::optional ABI break
to the C++17 status table
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99030
--- Comment #2 from CVS Commits ---
The master branch has been updated by Nathan Sidwell :
https://gcc.gnu.org/g:f8fac476b5ce4b9a37ea2b257d9da810f8c507be
commit r11-7170-gf8fac476b5ce4b9a37ea2b257d9da810f8c507be
Author: Nathan Sidwell
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99030
Nathan Sidwell changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99049
--- Comment #2 from Julian Orth ---
MSVC returns 128 for both: https://godbolt.org/z/16Tzh7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98863
--- Comment #46 from Richard Biener ---
Created attachment 50162
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50162&action=edit
df-live on demand
So I did the experiment to turn off DF_LIVE as permanent like we do for -O1.
w/o permanent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692
--- Comment #18 from Mark Wielaard ---
The current thinking (Julian did the thinking, I am just repeating) is that
this is caused by the way the _savegpr and/or restgpr functions return using
blr.
PPC has two special "lets zap the red zone" (the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99059
Bug ID: 99059
Summary: Static inline variable can't refer to itself
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99057
Marek Polacek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99033
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692
jseward at acm dot org changed:
What|Removed |Added
CC||jseward at acm dot org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99007
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|11.0|8.5
Summary|[11 Regression] I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99007
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692
--- Comment #21 from jseward at acm dot org ---
(In reply to Jakub Jelinek from comment #20)
> Can you disable it just for these magic entrypoints (either by name or by
> content)?
In principle yes. I prefer by-content rather than by-name, in th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
Richard Biener changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692
--- Comment #22 from jseward at acm dot org ---
Looking back at the above, it's now clearer what the problem is:
# Park potentially live data in the red zone
_savegpr0_14: std r14,-144(r1)
_savegpr0_15: std r15,-136(r1)
_savegpr0_16:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95675
Patrick Palka changed:
What|Removed |Added
CC||david at doublewise dot net
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99016
Patrick Palka changed:
What|Removed |Added
Resolution|--- |DUPLICATE
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #84 from Richard Biener ---
So it's the usual (quadratic) culprit:
Samples: 1M of event 'cycles:u', Event count (approx.): 1675893461671
Overhead Samples Command Shared Object Symbol
20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391
--- Comment #15 from David Malcolm ---
#0 fancy_abort (file=0x95b0ab6 "../../libcpp/line-map.c", line=1359,
function=0x95b0ace "linemap_compare_locations")
at ../../gcc/diagnostic.c:1778
#1 0x08fcbecf in linemap_compare_locations (set=0xf7f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #85 from Richard Biener ---
Starting new chain with statement:
D.31414 ={v} {CLOBBER};
The base object is:
&D.31414
Starting new chain with statement:
D.31415 ={v} {CLOBBER};
The base object is:
&D.31415
...
but those are all the las
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #86 from Richard Biener ---
OK, so clobber handling was added as a fix for PR92038
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #87 from Jakub Jelinek ---
At least for PR92038 it is important to see CLOBBERs in the chain, including
the first position in there.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #88 from rguenther at suse dot de ---
On Wed, 10 Feb 2021, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
>
> --- Comment #87 from Jakub Jelinek ---
> At least for PR92038 it is important to se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391
--- Comment #16 from rguenther at suse dot de ---
On Wed, 10 Feb 2021, dmalcolm at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391
>
> --- Comment #15 from David Malcolm ---
> #0 fancy_abort (file=0x95b0ab6 "../../
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99055
Martin Sebor changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot
gnu.org
Eve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #89 from Richard Biener ---
Fallout includes
FAIL: g++.dg/opt/store-merging-1.C scan-tree-dump store-merging "New sequence
of [12] stores to replace old one of 2 stores"
which shows
Starting new chain with statement:
s ={v} {CLOBB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #90 from Jakub Jelinek ---
Because it says that the whole range is uninitialized, so the store merging
code doesn't need to care about pre-existing content in any gaps between the
stored values. So say when the whole var is clobbered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #91 from Richard Biener ---
So the other simple idea I have is to limit the number of active store groups
and force-terminate in either a LRU or FIFO manner.
For the testcase at hand the decls we start the chain for are all only
used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391
--- Comment #17 from qinzhao at gcc dot gnu.org ---
(In reply to David Malcolm from comment #15)
> where:
>
> (gdb) call inform (loc_a, "loc_a")
> In file included from
> /usr/i686-w64-mingw32/sys-root/mingw/include/minwindef.h:163,
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #92 from Richard Biener ---
Simple and stupid like the below works and does
store merging : 0.42 ( 1%) 0.00 ( 0%) 0.43 ( 1%)
3858k ( 1%)
TOTAL : 56.86 0.56
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692
--- Comment #23 from Segher Boessenkool ---
savegpr/restgpr are special ABI-defined functions that do not have all the same
ABI
calling conventions as normal functions. They indeed write into the parent's
frame
(red zone, in this case).
Maybe y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692
--- Comment #24 from Segher Boessenkool ---
I do see the problems for savegpr/restgpr with that suggestion, but maybe
something
in that vein can be done.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #93 from Jakub Jelinek ---
I think I'd go for more chains by default, at least 64 or even 256, with a
param and tracking on how many we have in a counter. The class has a
ctor/dtor, so the increment/decrement of the counter can be do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98986
--- Comment #5 from Segher Boessenkool ---
(In reply to rsand...@gcc.gnu.org from comment #3)
> FWIW, another similar thing I've wanted in the past is to try
> recognising multiple possible constants in an (and X (const_int N))
> when X is known
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391
David Malcolm changed:
What|Removed |Added
Last reconfirmed||2021-02-10
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=1
--- Comment #15 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:3df5b249b3c81e95cdcb293a388155ae5b168f9e
commit r11-7174-g3df5b249b3c81e95cdcb293a388155ae5b168f9e
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391
--- Comment #19 from David Malcolm ---
(In reply to David Malcolm from comment #18)
> Converting one of both of those "const" and "void" to non-macros ought to
"one or both", I meant to say
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99060
Bug ID: 99060
Summary: [9/10/11 Regression] ICE in gfc_match_varspec, at
fortran/primary.c:2411
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98986
--- Comment #6 from Segher Boessenkool ---
(In reply to rguent...@suse.de from comment #4)
> So this is where the "autogenerated" part comes in. We should have
> an idea what might be useful and what isn't even worth trying by
> looking at the m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99061
Bug ID: 99061
Summary: [10/11 Regression] ICE in gfc_conv_intrinsic_atan2d,
at fortran/trans-intrinsic.c:4728
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Sev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99062
Bug ID: 99062
Summary: [10/11 Regression] ICE in tree_to_uhwi, at tree.h:4579
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99063
Bug ID: 99063
Summary: [9/10/11 Regression] ICE in prep_operand, at
cp/call.c:5842
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99055
Martin Sebor changed:
What|Removed |Added
Keywords||patch
--- Comment #1 from Martin Sebor -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87758
npl at chello dot at changed:
What|Removed |Added
CC||npl at chello dot at
--- Comment #
(experimental) [master revision
bdcde150450:e18dcf9fcae:b407f233d7c18534fbfe8f74af7f0232498fb0c4] (GCC)
r11-6550 FAIL
gcc version 11.0.0 20210210 (experimental) [master revision
bd0e37f68a3:deed5164277:72932511053596091ad291539022b51d9f2ba418] (GCC)
r11-7168 FAIL
$ cat x.ii
template struct
1 - 100 of 168 matches
Mail list logo
