https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84095
--- Comment #5 from Arnd Bergmann ---
Here are some additional instances in the kernel. I'm currently trying to get a
reliable build first and haven't got a log of all the messages, but there are a
number of changes I did that are related,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83835
--- Comment #3 from Marek Polacek ---
Perhaps we also want to set TARGET_EXPR_DIRECT_INIT_P here:
6785 /* If this is a constructor or a function returning an aggr type,
6786we need to build up a TARGET_EXPR. */
6787
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82461
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83530
Aldy Hernandez changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84111
Michael Matz changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |matz at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83503
--- Comment #11 from Jakub Jelinek ---
There is a valid use case, you have some public interface which you only want
to guarantee to be pure, the result depends on the arguments and e.g. on some
OSes or in some specific cases needs read-only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83758
--- Comment #30 from rsandifo at gcc dot gnu.org
---
(In reply to acsawdey from comment #29)
> The problematic expression was:
>
> (mem/c:QI (plus:DI (plus:DI (reg/f:DI 187) (const_int 32 [0x20])) (const_int
> 72 [0x48]))
>
> and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83503
--- Comment #12 from Martin Sebor ---
AFAIK, specifying attribute const and pure on a function definition has no
effect on the code emitted for the function itself or on its callers in other
translation units, so what you describe doesn't sound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82965
--- Comment #8 from amker at gcc dot gnu.org ---
I think there is inconsistent semantics between call in vect_do_peeling:
scale_loop_profile (prolog, prob_prolog, bound_prolog);
and implementation of scale_loop_profile.
When the loop is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84095
Martin Sebor changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84105
--- Comment #2 from Arnd Bergmann ---
Created attachment 43281
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43281=edit
preprocessed simplified sm_sideeffect.c, compressed
I managed to get a standalone testcase now, manually reduced the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83758
--- Comment #31 from acsawdey at gcc dot gnu.org ---
I'm not sure where the copy happens, I am just surmising that it must have been
added because the code clearly assumes it won't be copied.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84091
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83503
--- Comment #13 from Jakub Jelinek ---
(In reply to Martin Sebor from comment #12)
> AFAIK, specifying attribute const and pure on a function definition has no
> effect on the code emitted for the function itself or on its callers in
> other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81550
--- Comment #11 from Michael Meissner ---
Author: meissner
Date: Mon Jan 29 22:30:34 2018
New Revision: 257166
URL: https://gcc.gnu.org/viewcvs?rev=257166=gcc=rev
Log:
2018-01-29 Michael Meissner
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84042
Michael Meissner changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84087
Berni changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84098
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65871
Yann Collet changed:
What|Removed |Added
CC||yann.collet.73 at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82086
--- Comment #8 from Harald Anlauf ---
(In reply to jsberg from comment #7)
> As to why I think this is a bug (and why I think Intel's compiler is doing
> the right thing), referencing the 2008 standard (N1830):
In the F2018 DIS (N2146) the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84109
Harald Anlauf changed:
What|Removed |Added
CC||anlauf at gmx dot de
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84111
--- Comment #6 from Jakub Jelinek ---
Sure, but some of the mentioned SSA_NAMEs are registered for update and SCEV
code is called before that happens.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84114
Bug ID: 84114
Summary: global reassociation pass prevents fma usage,
generates slower code
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84116
Bug ID: 84116
Summary: [7/8 Regression] ICE in gfc_match_omp_clauses, at
fortran/openmp.c:1354
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84111
--- Comment #4 from Jakub Jelinek ---
Seems this is during
#0 follow_copies_to_constant (var=) at
../../gcc/tree-scalar-evolution.c:1548
#1 0x010ce55e in analyze_scalar_evolution_1 (loop=0x7fffefb99550,
var=)
at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84066
--- Comment #4 from igor.v.tsimbalist at intel dot com ---
Created attachment 43280
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43280=edit
updated patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68810
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80867
--- Comment #11 from kelvin at gcc dot gnu.org ---
Author: kelvin
Date: Mon Jan 29 18:00:49 2018
New Revision: 257158
URL: https://gcc.gnu.org/viewcvs?rev=257158=gcc=rev
Log:
gcc/ChangeLog:
2018-01-29 Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68467
--- Comment #23 from Jeffrey A. Law ---
I've got no objection Joseph. But I think you need to make your case to Richi
and Jakub -- I doubt they're on CC for this BZ :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84095
--- Comment #3 from Arnd Bergmann ---
(In reply to Martin Sebor from comment #2)
> (In reply to Arnd Bergmann from comment #0)
>
> Let me work on this.
>
> I tested the warning with the kernel but don't recall coming across this
> false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4131
Andrew Pinski changed:
What|Removed |Added
CC||antoshkka at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84103
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83503
--- Comment #9 from Jakub Jelinek ---
If you mean it as a coding style warning (at least for const/pure), then it is
at least worded incorrectly, there is no conflict between those and if what you
do is that you ignore const attribute because
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84095
--- Comment #4 from Martin Sebor ---
Thanks.
Just for reference in case more of these should pop up, I see two -Wrestrict
instances in my build (below). The first one looks correct but the second one
could be an instance of the false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68810
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83503
--- Comment #10 from Martin Sebor ---
(In reply to Jakub Jelinek from comment #9)
This is not a style warning. Because there is no valid use case for having
both attribute const and pure on two declarations of the same function, in the
absence
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68467
--- Comment #24 from Joseph S. Myers ---
Author: jsm28
Date: Mon Jan 29 21:00:52 2018
New Revision: 257165
URL: https://gcc.gnu.org/viewcvs?rev=257165=gcc=rev
Log:
Fix m68k-linux-gnu libgcc build for ColdFire (PR target/68467).
PR target/68467
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83966
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84088
--- Comment #6 from Paul Thomas ---
(In reply to Tom de Vries from comment #5)
> Hmm. Probably this failure would have been picked up by
> libgomp-plugin-host_nonshm.
Hi Tom,
Although my patch caused it, I am not in a position to pick this one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68467
--- Comment #22 from joseph at codesourcery dot com ---
What do the m68k maintainers think about the suggestion of backporting to
GCC 7 (and for that matter GCC 6)? This is a regression in the sense of
"libgcc used to build for ColdFire, then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84113
--- Comment #1 from Douglas Mencken ---
ah yep, it’s at first stage
$ cat stage_current
stage1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84077
--- Comment #5 from Flössie ---
Created attachment 43278
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43278=edit
Complete -v output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84108
--- Comment #3 from Arnd Bergmann ---
(In reply to Jakub Jelinek from comment #1)
> I vaguely remember the behavior of packed + aligned(N) kept changing in the
> past, some versions of GCC treated it just like packed, others as aligned.
> Is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83758
--- Comment #29 from acsawdey at gcc dot gnu.org ---
The problematic expression was:
(mem/c:QI (plus:DI (plus:DI (reg/f:DI 187) (const_int 32 [0x20])) (const_int 72
[0x48]))
and internal_arg_pointer was (plus:DI (reg/f:DI 187) (const_int 32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84066
--- Comment #6 from igor.v.tsimbalist at intel dot com ---
(In reply to H.J. Lu from comment #5)
> (In reply to igor.v.tsimbalist from comment #4)
> > Created attachment 43280 [details]
> > updated patch
>
> - mem = gen_rtx_MEM (Pmode,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84066
--- Comment #7 from H.J. Lu ---
(In reply to igor.v.tsimbalist from comment #6)
> >
> > reg_ssp must be in word_mode, not in Pmode.
>
> reg_ssp is word_mode. It's reg_adj that is Pmode (it's increment to shadow
> stack).
OK.
> > Please show
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81122
--- Comment #17 from Jonathan Wakely ---
For the avoidance of doubt:
C++98 did not support reading hex floats from an istream.
Libstdc++ still follows the C++98 spec, so does not read hex floats. "0x1" is
read as "0". "0x1p1" is also read as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68810
--- Comment #19 from Jason Merrill ---
Author: jason
Date: Mon Jan 29 20:56:00 2018
New Revision: 257161
URL: https://gcc.gnu.org/viewcvs?rev=257161=gcc=rev
Log:
PR c++/68810 - wrong location for reinterpret_cast error.
* cvt.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84090
Aldy Hernandez changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83975
--- Comment #7 from G. Steinmetz ---
Some additional testcases :
$ cat z2.f90
subroutine s(x)
character(*) :: x
associate (y => [x])
print *, size(y), len(y), y
end associate
end
$ cat z3.f90
subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24928
Andrew Pinski changed:
What|Removed |Added
CC||antoshkka at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84099
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83996
--- Comment #2 from Marek Polacek ---
Author: mpolacek
Date: Mon Jan 29 20:54:12 2018
New Revision: 257160
URL: https://gcc.gnu.org/viewcvs?rev=257160=gcc=rev
Log:
PR c++/83996
* constexpr.c (cxx_fold_indirect_ref): Compute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84111
--- Comment #3 from Jakub Jelinek ---
Seems during cunroll we end up with:
y_8 = PHI
...
y_29 = PHI
...
y_37 = PHI
where all 3 PHIs are degenerate and thus:
1539static tree
1540
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84113
Bug ID: 84113
Summary: gcc-7.3.0/libgcc/unwind.inc:136:1: internal compiler
error: in extract_insn, at recog.c:2311
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84115
--- Comment #1 from G. Steinmetz ---
A few more testcases :
$ cat z2.f90
subroutine s(x)
character(:), allocatable :: x
associate (y => x)
print *, y
end associate
end
$ cat z3.f90
subroutine s(x)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84115
Bug ID: 84115
Summary: [8 Regression] ICE: tree check: expected tree that
contains 'decl minimal' structure, have 'indirect_ref'
in add_decl_as_local, at fortran/trans-decl.c:256
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84117
Bug ID: 84117
Summary: [8 Regression] ICE in gimplify_modify_expr, at
gimplify.c:5798
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82461
--- Comment #7 from Jason Merrill ---
Author: jason
Date: Mon Jan 29 20:58:36 2018
New Revision: 257164
URL: https://gcc.gnu.org/viewcvs?rev=257164=gcc=rev
Log:
PR c++/82461 - constexpr list-initialized member
* constexpr.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83996
Marek Polacek changed:
What|Removed |Added
Summary|[6/7/8] Regression] ICE |[6/7] Regression] ICE with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70952
Eric Gallager changed:
What|Removed |Added
Keywords||diagnostic
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83966
--- Comment #2 from Marek Polacek ---
Author: mpolacek
Date: Mon Jan 29 18:20:01 2018
New Revision: 257159
URL: https://gcc.gnu.org/viewcvs?rev=257159=gcc=rev
Log:
PR c/83966
* c-format.c (check_function_format): Check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83758
--- Comment #28 from rsandifo at gcc dot gnu.org
---
(In reply to acsawdey from comment #27)
> So, I think the problem is that the rtx given by
> crtl->args.internal_arg_pointer is not canonical as expected. So near the
> beginning of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84066
--- Comment #5 from H.J. Lu ---
(In reply to igor.v.tsimbalist from comment #4)
> Created attachment 43280 [details]
> updated patch
- mem = gen_rtx_MEM (Pmode, plus_constant (Pmode, operands[0],
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68467
Joseph S. Myers changed:
What|Removed |Added
Target Milestone|8.0 |7.4
--- Comment #25 from Joseph S.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83937
--- Comment #7 from Marek Polacek ---
Actually this might be just a missing TARGET_EXPR_DIRECT_INIT_P check in
build_special_member_call:
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -8824,7 +8824,8 @@ build_special_member_call (tree instance,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84105
--- Comment #5 from Aldy Hernandez ---
Created attachment 43282
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43282=edit
untested patch
Proposed patch in testing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83503
--- Comment #7 from Jakub Jelinek ---
First of all, I was talking about a function first declared pure and later made
const, your invalid example has it the other way around, but the invalid thing
on it isn't any kind of attribute conflict, but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83942
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84108
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84111
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83503
--- Comment #8 from Martin Sebor ---
The purpose of the warning is to detect coding mistakes. There is no valid use
case for declaring the same function const and pure so it must be a mistake.
As the test case shows, the mistake can lead to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84112
--- Comment #1 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #0)
> The following testcase ICEs with -mcpu=power8 -O3 -fstack-protector-strong
> -fpic on powerpc64le-linux with:
> rh1539812.i: In function ‘foo’:
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84111
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82819
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83176
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84092
Richard Biener changed:
What|Removed |Added
Keywords||ice-on-valid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84095
Richard Biener changed:
What|Removed |Added
Keywords||diagnostic
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84082
--- Comment #4 from Jakub Jelinek ---
As that PR was a workaround for buggy code and the intent was to not reject
code that has been accepted before, perhaps we could only do the pedwarn rather
than error and clearing of TREE_TYPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84093
Dominique d'Humieres changed:
What|Removed |Added
Priority|P3 |P4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84096
Bug ID: 84096
Summary: Wrong prototype for omp_init_nest_lock_with_hint() in
"omp.h.in"
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83496
Laurent GUERBY changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84057
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84057
--- Comment #4 from Richard Biener ---
Author: rguenth
Date: Mon Jan 29 09:16:09 2018
New Revision: 257139
URL: https://gcc.gnu.org/viewcvs?rev=257139=gcc=rev
Log:
2018-01-29 Richard Biener
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84017
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from Jakub Jelinek ---
> I can't think of how the self-test failure could be related, unless it just
> results in miscompiled stage2 or stage3 compiler.
It seems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84076
--- Comment #2 from Jakub Jelinek ---
The convert_arg_to_ellipsis call that converts in this case the non-POD class
to its address is done very shortly before calling the -Wformat check, but most
of the stuff the function is doing is needed for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84088
--- Comment #2 from Tom de Vries ---
Minimal version:
...
! { dg-do run }
module vars
implicit none
integer z
!$acc declare create (z)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84067
--- Comment #3 from ktkachov at gcc dot gnu.org ---
(In reply to Richard Biener from comment #2)
> So any hint on whether the code after r257077 is better or worse than before?
Looks worse unfortunately:
For aarch64 at -O2 it generates:
foo:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84067
--- Comment #6 from ktkachov at gcc dot gnu.org ---
(In reply to rguent...@suse.de from comment #5)
> On Mon, 29 Jan 2018, ktkachov at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84067
> >
> > --- Comment #3 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84080
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P2
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84082
--- Comment #2 from Jakub Jelinek ---
build_functional_cast here creates CAST_EXPR with NULL TREE_TYPE as well as
TREE_OPERAND (, 0) and cp_parser_constant_expression ->
potential_rvalue_constant_expression -> potential_constant_expression_1 is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84084
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84082
--- Comment #3 from Jakub Jelinek ---
To be precise, the CAST_EXPR doesn't have NULL TREE_TYPE initially, it has A
type, just NULL operand.
But then r245223 comes with:
if (processing_template_decl)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84086
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84067
--- Comment #4 from ktkachov at gcc dot gnu.org ---
(In reply to ktkachov from comment #3)
> (In reply to Richard Biener from comment #2)
> > So any hint on whether the code after r257077 is better or worse than
> > before?
>
> Looks worse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84091
Richard Biener changed:
What|Removed |Added
Keywords||ice-on-valid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84068
Richard Biener changed:
What|Removed |Added
Keywords||ice-checking
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84067
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84071
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84083
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
1 - 100 of 238 matches
Mail list logo