https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53234
--- Comment #2 from Andy Lutomirski ---
*** Bug 57998 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57998
Andy Lutomirski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94186
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94175
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94175
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:94e2418780f1d13235f3e2e6e5c09dbe821c1ce3
commit r10-7284-g94e2418780f1d13235f3e2e6e5c09dbe821c1ce3
Author: Jason Merrill
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94043
--- Comment #4 from Kewen Lin ---
This was just exposed from my commit, it can also be reproduced without my
commit but with -fno-vect-cost-model.
Some loops we have for this case:
;; Loop 1
;; header 3, latch 10
;; depth 1, outer 0
;;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93328
Paco Arjonilla changed:
What|Removed |Added
CC||pacoarjonilla at yahoo dot es
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94228
--- Comment #5 from Steve Kargl ---
On Thu, Mar 19, 2020 at 10:24:10PM +, markwayne1969 at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94228
>
> --- Comment #4 from Mark Paris ---
> (In reply to kargl from comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94231
Bug ID: 94231
Summary: Invalid move constructor defaulted outside of class as
deleted is accepted
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57998
S. Davis Herring changed:
What|Removed |Added
CC||herring at lanl dot gov
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81349
S. Davis Herring changed:
What|Removed |Added
CC||herring at lanl dot gov
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94202
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94202
--- Comment #2 from CVS Commits ---
The master branch has been updated by Jan Hubicka :
https://gcc.gnu.org/g:f7dceb4e658399edfbf8dd0e08ce0c686bfa2c9d
commit r10-7282-gf7dceb4e658399edfbf8dd0e08ce0c686bfa2c9d
Author: Jan Hubicka
Date: Fri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94228
--- Comment #4 from Mark Paris ---
(In reply to kargl from comment #3)
> No. Newer C, as opposed to older C, uses // for a comment.
> Fortran uses // as the concatenation operator. Run this
> through a cpp pre-processor.
>
> character(len=80)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94230
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94029
Jakub Jelinek changed:
What|Removed |Added
Summary|[9/10 Regression] gcc crash |[9 Regression] gcc crash in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94230
Bug ID: 94230
Summary: provide an option to change the size limitation for
-Wmisleading-indent
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94029
--- Comment #13 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:9def91e9f2a7051c9c146f16c1a10d1b25d33b47
commit r10-7281-g9def91e9f2a7051c9c146f16c1a10d1b25d33b47
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93751
Jason Merrill changed:
What|Removed |Added
Status|NEW |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94229
Bug ID: 94229
Summary: more clarification on the warning message from
-Wmisleading-indent
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94228
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93369
--- Comment #15 from Jan Hubicka ---
The testcase has an ODR violation that makes comdat groups go out of sync. So I
guess it is just about finding way to not make verifier to ICE.
With release settings the testcase will however quietly compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94228
--- Comment #2 from Mark Paris ---
(In reply to Andrew Pinski from comment #1)
> gfortran defaults to -traditional-cpp preprocessor mode.
Thank you for your reply. If I may, I'd like to pose a question that I cannot
find the answer to from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63944
Joseph S. Myers changed:
What|Removed |Added
CC||dje at gcc dot gnu.org
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94225
Joseph S. Myers changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94078
Martin Sebor changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94228
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94228
Bug ID: 94228
Summary: Preprocessor inconsistency for macros when invoked
from gfortran
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94227
Marek Polacek changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94227
Bug ID: 94227
Summary: ambiguous lookup for nested-name-specifier in
using-declaration is not diagnosed
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92372
--- Comment #10 from Jan Hubicka ---
*** Bug 93351 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93351
Jan Hubicka changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94226
Martin Sebor changed:
What|Removed |Added
Blocks||84774
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94226
Bug ID: 94226
Summary: [10 regression] r10-7272 eliminated some warning
messages
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94222
--- Comment #3 from Andrew Pinski ---
(In reply to Jaroslav Fojtík from comment #2)
> Sorry, it worked for many years without any problems. I has been fixed a
> problem in my WP2LaTeX now.
Well it depends on the ABI for va_list . On the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94224
--- Comment #2 from Jakub Jelinek ---
Created attachment 48066
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48066=edit
gcc10-pr94224.patch
Untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94224
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92372
Jan Hubicka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92372
--- Comment #8 from CVS Commits ---
The master branch has been updated by Jan Hubicka :
https://gcc.gnu.org/g:f22712bd8a2ed57d3cc7e6fa92730bd5852e27b3
commit r10-7279-gf22712bd8a2ed57d3cc7e6fa92730bd5852e27b3
Author: Jan Hubicka
Date: Thu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92757
--- Comment #14 from CVS Commits ---
The releases/gcc-9 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:337111a23499e597707f220662b2567e3f3bd6ea
commit r9-8402-g337111a23499e597707f220662b2567e3f3bd6ea
Author: Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92757
--- Comment #15 from CVS Commits ---
The releases/gcc-8 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:c8f84830a1bd275a62e226584b8ede40f0ce6760
commit r8-10133-gc8f84830a1bd275a62e226584b8ede40f0ce6760
Author: Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94225
David Edelsohn changed:
What|Removed |Added
CC||jsm28 at gcc dot gnu.org
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94225
Bug ID: 94225
Summary: C18 conformance for structure implicit initialization
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94224
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |10.0
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94175
--- Comment #2 from Jakub Jelinek ---
But for #c1 it is just a missed-optimization, while if the passing of a
constexpr var to a function isn't an ODR use, isn't it then a standard
violation that we aren't optimizing the variable read into its
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #30 from Jakub Jelinek ---
Or perhaps just do:
--- gcc/var-tracking.c.jj 2020-01-12 11:54:38.532381439 +0100
+++ gcc/var-tracking.c 2020-03-19 15:49:19.457340470 +0100
@@ -6112,7 +6112,8 @@ add_stores (rtx loc, const_rtx expr,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94216
--- Comment #10 from rguenther at suse dot de ---
On Thu, 19 Mar 2020, Richard Biener wrote:
> On Thu, 19 Mar 2020, jakub at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94216
> >
> > --- Comment #8 from Jakub
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92757
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94175
--- Comment #1 from Jason Merrill ---
Testcase using fewer C++ features:
struct A {};
extern A a;
int i;
[[gnu::noinline, gnu::noclone]]
void f(A) { ++i; }
int main()
{
f(a);
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #29 from Jakub Jelinek ---
So, the reason why the values aren't being marked as sp based is given in
PR54796 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54796#c2
In these functions, there is no fp_setter insn, so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94175
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
runk-r10-7276-20200319122247-g02f7334ac93-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.0.1 20200319 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94062
--- Comment #10 from Jonathan Wakely ---
No.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90834
Iain Sandoe changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #28 from Martin Liška ---
(In reply to Richard Biener from comment #25)
> Created attachment 48064 [details]
> more localized caching
>
> Updated and simplified patch. Maybe it does help depending on how we have
> shared locs for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93709
Jiu Fu Guo changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93435
--- Comment #8 from Martin Jambor ---
The issue actually started with my r8-344-2bba75411e1 and it is
basically a perfect SRA bomb, it makes SRA sub-access propagation
accross assignments create gazillions of accesses and then
replacements,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #27 from Jakub Jelinek ---
So, I've looked at two cases from those where visited_vals.length () > 100
returned non-NULL, in particular Wsizeof-pointer-memaccess1.c and
diagnostic-show-locus.c. In both all the cases where it returned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94062
--- Comment #9 from m.cencora at gmail dot com ---
(In reply to Jonathan Wakely from comment #8)
> No, we can switch to using a data member with the [[no_unique_address]]
> attribute, which is on my TODO list for gcc-11. See PR 55713 and PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55713
Jonathan Wakely changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94062
--- Comment #8 from Jonathan Wakely ---
(In reply to m.cencora from comment #7)
> But I guess to fix this you would have to break ABI (or change C++ standard).
No, we can switch to using a data member with the [[no_unique_address]]
attribute,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93147
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94223
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94062
--- Comment #7 from m.cencora at gmail dot com ---
(In reply to Jonathan Wakely from comment #6)
> Further reduced:
>
> struct Bar1
> {
> Bar1(Bar1&&) = delete;
> };
>
> struct Foo1
> {
> operator Bar1() const;
> };
>
> struct tuple : Bar1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93931
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=94062
--- Comment #6 from Jonathan Wakely ---
Further reduced:
struct Bar1
{
Bar1(Bar1&&) = delete;
};
struct Foo1
{
operator Bar1() const;
};
struct tuple : Bar1
{
tuple() : Bar1(Foo1{}) { }
};
tuple t;
elide.cc: In constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82113
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94216
--- Comment #9 from rguenther at suse dot de ---
On Thu, 19 Mar 2020, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94216
>
> --- Comment #8 from Jakub Jelinek ---
> (In reply to Richard Biener from comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94223
Bug ID: 94223
Summary: [10 Regression] -fcompare-debug -O0 failure on
cpp1z/init-statement6.C
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94221
Richard Biener changed:
What|Removed |Added
Known to fail||10.0
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94216
--- Comment #8 from Jakub Jelinek ---
(In reply to Richard Biener from comment #5)
> (In reply to Jakub Jelinek from comment #1)
> > I wonder if we shouldn't do:
> > --- gcc/fold-const.c.jj 2020-03-18 12:47:36.0 +0100
> > +++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94062
Jonathan Wakely changed:
What|Removed |Added
Component|libstdc++ |c++
--- Comment #5 from Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93931
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:02f7334ac93f53ed06d881beb611e88be36dc56a
commit r10-7276-g02f7334ac93f53ed06d881beb611e88be36dc56a
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94062
--- Comment #4 from m.cencora at gmail dot com ---
Ping(In reply to Jonathan Wakely from comment #2)
> I guess you're compiling in C++17 mode, but I shouldn't have to guess the
> options you're passing to the compiler. Please provide them (as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #26 from Richard Biener ---
(In reply to Martin Liška from comment #24)
> (In reply to Richard Biener from comment #23)
> > (In reply to Richard Biener from comment #22)
> > > Created attachment 48063 [details]
> > > more localized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
Richard Biener changed:
What|Removed |Added
Attachment #48063|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #24 from Martin Liška ---
(In reply to Richard Biener from comment #23)
> (In reply to Richard Biener from comment #22)
> > Created attachment 48063 [details]
> > more localized caching
> >
> > Like this. Martin, can you also check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #23 from Richard Biener ---
(In reply to Richard Biener from comment #22)
> Created attachment 48063 [details]
> more localized caching
>
> Like this. Martin, can you also check the effect on this one?
We can actually simplify
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94062
Jonathan Wakely changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #3 from Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94062
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #22 from Richard Biener ---
Created attachment 48063
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48063=edit
more localized caching
Like this. Martin, can you also check the effect on this one?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #21 from Richard Biener ---
(In reply to Jakub Jelinek from comment #19)
> I think caching is problematic, for a couple of reasons:
> 1) for non-cselib_preserved_value_p, the loc list is dynamic and keeps
> changing, locs are added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94222
--- Comment #2 from Jaroslav Fojtík ---
Sorry, it worked for many years without any problems. I has been fixed a
problem in my WP2LaTeX now.
https://bitbucket.org/JaFojtik/wp2latex/commits/b337710165faa629cbae4f81f6ed4d79dde5aa3e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94222
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94062
--- Comment #1 from m.cencora at gmail dot com ---
Ping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94222
Bug ID: 94222
Summary: Architecture dependent problem with vsnprintf
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94211
Jakub Jelinek changed:
What|Removed |Added
Summary|[8/9/10 Regression] |[8/9 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94211
--- Comment #4 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:c7e9019681857b329bbe4c1e7ec8dec8c736c0fe
commit r10-7274-gc7e9019681857b329bbe4c1e7ec8dec8c736c0fe
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94217
--- Comment #8 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:f3280e4c0c98e103603bafc466ea49651fe0b7f2
commit r10-7273-gf3280e4c0c98e103603bafc466ea49651fe0b7f2
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94217
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94216
--- Comment #6 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:73bc09fa8c6b973a928a599498caa66a25c8bc8d
commit r10-7272-g73bc09fa8c6b973a928a599498caa66a25c8bc8d
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94216
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #20 from Martin Liška ---
(In reply to Richard Biener from comment #17)
> Created attachment 48061 [details]
> cache base term
>
> I wonder if we could simply cache the base terms in elt_loc_list? Does that
> make a difference?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #19 from Jakub Jelinek ---
I think caching is problematic, for a couple of reasons:
1) for non-cselib_preserved_value_p, the loc list is dynamic and keeps
changing, locs are added and removed as we go through the basic blocks
2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94221
Bug ID: 94221
Summary: Explicit assignment in type is ignored in some cases
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94219
Martin Liška changed:
What|Removed |Added
CC||jason at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #18 from Richard Biener ---
Note also that param_max_find_base_term_values limits recursion depth but not
width (the loc list traversals). The original visited_vals thing was to
prevent infinite recursion only. If the global
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #17 from Richard Biener ---
Created attachment 48061
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48061=edit
cache base term
I wonder if we could simply cache the base terms in elt_loc_list? Does that
make a difference?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #16 from Martin Liška ---
PR88440 is also slightly related where enablement of
-ftree-loop-distribute-patterns caused longer compilation:
521.wrf_r: 310 -> 346s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264
--- Comment #15 from Richard Biener ---
WRF initial_config has very very very many (nested) loops to initialize
globals.
IIRC there's a related bug running into the very same issue when prefetching
is enabled.
1 - 100 of 105 matches
Mail list logo
