https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82648
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89259
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89435
Eric Botcazou changed:
What|Removed |Added
Priority|P1 |P3
--- Comment #8 from Eric Botcazou --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89862
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89788
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83822
--- Comment #7 from Eric Gallager ---
(In reply to Eric Gallager from comment #6)
> (In reply to David Binderman from comment #2)
> > (In reply to Eric Gallager from comment #1)
> > > Is this from cppcheck again?
> >
> > Yes. Anything from me t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89853
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89788
--- Comment #3 from David Binderman ---
No. Additional bug in -Wnull-dereference ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89259
--- Comment #3 from David Binderman ---
It does. -Wtype-limits is in -Wextra, but not in -Wall.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82648
--- Comment #2 from David Binderman ---
I agree, but -Wtype-limits is in -Wextra, not commonly used -Wall.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85608
--- Comment #3 from David Binderman ---
No idea, and currently no resource to find out. Sorry.
There are plenty of ubsan bugs in gcc hanging around for
months, if not years. This is merely another one.
Wide int seems to be the favoured solution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89788
Eric Gallager changed:
What|Removed |Added
Keywords||diagnostic
Blocks|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77875
--- Comment #3 from Lénárd Szolnoki ---
A more worrisome example presumably for this same bug, it's a miscompilation:
template
decltype(auto) as_const(T& t) {
using const_ref = const T&;
return const_ref{t};
}
int main() {
int i =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86525
--- Comment #3 from Martin Liška ---
Thanks for report, I know that clang is using an intermediate instead of a
constant array.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89848
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
Bug ID: 89864
Summary: [9.0 regression] gcc fails to build/bootstrap with
XCode 10.2
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89832
--- Comment #4 from Martin Liška ---
(In reply to Diane Meirowitz from comment #3)
> Thank you for fixing this so quickly! This is a huge improvement.
Be my guest!
>
> Here are some suggestions to make it even better for those without a lot of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89829
--- Comment #5 from Martin Liška ---
Author: marxin
Date: Thu Mar 28 08:44:44 2019
New Revision: 269985
URL: https://gcc.gnu.org/viewcvs?rev=269985&root=gcc&view=rev
Log:
Revert r254150 (PR bootstrap/89829).
2019-03-28 Martin Liska
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89829
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87829
--- Comment #6 from Martin Liška ---
Author: marxin
Date: Thu Mar 28 08:51:46 2019
New Revision: 269986
URL: https://gcc.gnu.org/viewcvs?rev=269986&root=gcc&view=rev
Log:
Backport r265786
2019-03-28 Martin Liska
Backport from mainli
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87829
--- Comment #7 from Martin Liška ---
Author: marxin
Date: Thu Mar 28 08:53:49 2019
New Revision: 269987
URL: https://gcc.gnu.org/viewcvs?rev=269987&root=gcc&view=rev
Log:
Backport r265786
2019-03-28 Martin Liska
Backport from mainli
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87829
Martin Liška changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89865
Bug ID: 89865
Summary: [9 Regression] FAIL: gcc.target/i386/pr49095.c
scan-assembler-times ), % 45
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89862
--- Comment #2 from kugan at gcc dot gnu.org ---
(In reply to Eric Botcazou from comment #1)
> Can you try this instead?
>
> Index: rtl.h
> ===
> --- rtl.h (revision 269886)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89866
Bug ID: 89866
Summary: POINTER
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89865
Uroš Bizjak changed:
What|Removed |Added
CC||bernds at gcc dot gnu.org
--- Comment #1 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89866
--- Comment #1 from Laurent Pointal ---
Note: compiled with -std=f2008 option.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89851
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89858
--- Comment #3 from Richard Biener ---
It looks like GMP selects a CPU path that is not supported. Can you run
the compile within gdb to get at the faultin assembly instruction?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89860
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
Richard Biener changed:
What|Removed |Added
Keywords||build
Host|Darwin Kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
Richard Biener changed:
What|Removed |Added
CC||iains at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89837
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64242
Eric Botcazou changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89865
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89867
Bug ID: 89867
Summary: internal compiler error: in layout_type, at
stor-layout.c:2578
Product: gcc
Version: 8.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89867
Richard Biener changed:
What|Removed |Added
Keywords||needs-reduction
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
Iain Sandoe changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #3 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #2)
> This has already been reported to Apple by Daniel Vollmer [noted in PR68771]
(of course, it will do no harm to have multiple radars filed, so go at it!)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89868
Bug ID: 89868
Summary: -fsanitize=address inhibits C++ unhandled exception
core dump
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88834
--- Comment #10 from rsandifo at gcc dot gnu.org
---
(In reply to kugan from comment #9)
> Created attachment 46040 [details]
> patch
Wasn't sure whether this patch was WIP or the final version
for review, but we need to do something more gener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85968
--- Comment #4 from Claudiu Zissulescu ---
Yes we can close it, no need for backporting.
//Claudiu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #4 from Jürgen Reuter ---
Created attachment 46043
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46043&action=edit
Darwin header file ucred.h
As this seems to be of interest, I posted the Darwin XCode 10.2 header file
ucred.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #5 from Jürgen Reuter ---
My hunch is that it takes Apple too long to fix that issue, so a fix inside gcc
would be very much appreciated.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89866
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84101
--- Comment #23 from Richard Biener ---
Fallout is:
FAIL: gcc.dg/pr85195.c (internal compiler error)
where we handle V1TI = {_2} with _2 = (__int128) int_1; this way and
end up calling convert_move from SImode to V1TImode (instead of TImode).
L
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89435
Eric Botcazou changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89795
--- Comment #5 from Eric Botcazou ---
So the combiner first eliminates a ZERO_EXTEND between 2 instructions as
redundant, which is OK in isolation, but IRA (combine_and_move_insns) later
combines again the same 2 instructions without using the
WO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89795
--- Comment #6 from Eric Botcazou ---
*** Bug 89435 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89795
--- Comment #7 from Eric Botcazou ---
It's also related to PR rtl-opt/89862 because it's ultimately the synthesis of
an integer constant in a register, which is not a word_register_operation_p,
but here it's indirectly done by the mini-combiner
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89868
--- Comment #1 from Jonathan Wakely ---
I suspect the problem is that Asan makes the address space much much larger,
and so the core file is larger than the max core file size allowed on your
system.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68771
--- Comment #24 from Daniel Vollmer ---
(In reply to Iain Sandoe from comment #23)
> My freshly-built 7.4 (bootstrapped with 10.1 xc effectively) doesn't
> reproduce it, neither do any other branches I have lying around - so we're
> not there ye
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68771
--- Comment #25 from Iain Sandoe ---
(In reply to Daniel Vollmer from comment #24)
> (In reply to Iain Sandoe from comment #23)
>
> > My freshly-built 7.4 (bootstrapped with 10.1 xc effectively) doesn't
> > reproduce it, neither do any other bra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84101
Richard Biener changed:
What|Removed |Added
Attachment #43287|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89341
--- Comment #11 from Jan Hubicka ---
Removing the alias check seems correct to me. The same body alias patch was
long and needed special casing those aliases on quite few places. I am not at
all sure why I added this one, but it definitly silenc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89865
--- Comment #2 from Bernd Schmidt ---
Jakub seems to be the author of gcc.target/i386/pr49095.c.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33715
--- Comment #6 from Jonathan Wakely ---
But a warning that says "this resource might be leaked, you should add
try-catch to clean it up" would be suggesting awful code that goes against all
good design guidance.
A more useful warning would be to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89868
--- Comment #2 from Jonny Grant ---
Ah that sounds possible. I imagine it is not GCC that would be the one that
controls the core dumping? Perhaps where ever that code is, it could just say
"Core too large (xyz MB) unable to dump".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89858
--- Comment #4 from Hans Buchmann ---
Created attachment 46045
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46045&action=edit
The gbd output
With the help of our sysadmin Peter Schlachter we managed the following output,
hopefully helpfu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89858
--- Comment #5 from Richard Biener ---
Not very helpful - you need follow the fork to the actual compiler binary.
The easiest way to do this is to run the compiler with -v appended
and the cut&paste the line where it executes the cc1plus binary a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89865
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89621
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89861
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89832
--- Comment #5 from Diane Meirowitz ---
Yes, much better!
Again, thank you for fixing this so quickly and completely!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79022
--- Comment #3 from Jonathan Wakely ---
Adding a warning about this case seems genuinely useful, i.e. when the names
match but in a different order.
I'm less convinced that warning about mismatches like void f(int number) and
void f(int num) is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89869
Bug ID: 89869
Summary: -fsanitize=undefined miscompilation
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79022
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79022
--- Comment #5 from Jonathan Wakely ---
Author: redi
Date: Thu Mar 28 13:42:48 2019
New Revision: 269990
URL: https://gcc.gnu.org/viewcvs?rev=269990&root=gcc&view=rev
Log:
PR c/79022 fix mismatch parameter order in declaratio
The declaration of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89725
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89858
--- Comment #6 from Hans Buchmann ---
Created attachment 46048
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46048&action=edit
Disassemly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89725
--- Comment #3 from David Malcolm ---
Candidate patch for the first part:
https://gcc.gnu.org/ml/gcc-patches/2019-03/msg01362.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89725
Richard Biener changed:
What|Removed |Added
CC||amker at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89870
Bug ID: 89870
Summary: C++ suggest header for abort()
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52994
janus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||rejects-valid
--- Comment #14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88066
Matthias Kretz changed:
What|Removed |Added
CC||kretz at kde dot org
--- Comment #9 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89725
--- Comment #5 from David Malcolm ---
Author: dmalcolm
Date: Thu Mar 28 14:40:56 2019
New Revision: 269994
URL: https://gcc.gnu.org/viewcvs?rev=269994&root=gcc&view=rev
Log:
optinfo-emit-json.cc: don't call get_fnname_from_decl (PR middle-end/89
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88066
--- Comment #10 from Jonathan Wakely ---
(In reply to Matthias Kretz from comment #9)
> Created attachment 46049 [details]
> test case
>
> Let me present the counterargument. I.e. if I use -I. and have a file named
> as used internally by libstd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89870
Jonathan Wakely changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89785
--- Comment #10 from Jakub Jelinek ---
Author: jakub
Date: Thu Mar 28 14:47:47 2019
New Revision: 269995
URL: https://gcc.gnu.org/viewcvs?rev=269995&root=gcc&view=rev
Log:
PR c++/89785
* constexpr.c (struct check_for_return_conti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89870
--- Comment #2 from Jonny Grant ---
Good point!
Any header would be a good start... but as it is a CPP file being compiled by
g++ perhaps g++ should even suggest std::abort() and ?
eg suggestion:
test.cpp: In function 'int main()':
test.cpp:3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89870
--- Comment #3 from Jonathan Wakely ---
(In reply to Jonny Grant from comment #2)
> Good point!
>
> Any header would be a good start... but as it is a CPP file being compiled
> by g++ perhaps g++ should even suggest std::abort() and ?
That's a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85968
Eric Gallager changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68771
--- Comment #26 from Daniel Vollmer ---
(In reply to Iain Sandoe from comment #25)
> (In reply to Daniel Vollmer from comment #24)
> > (In reply to Iain Sandoe from comment #23)
> >
> > > My freshly-built 7.4 (bootstrapped with 10.1 xc effective
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79022
Eric Gallager changed:
What|Removed |Added
Keywords||diagnostic
Blocks|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89785
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
Bug 55004 depends on bug 89785, which changed state.
Bug 89785 Summary: Incorrect "not a constant expression" error with switch
statement that returns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89785
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89865
--- Comment #4 from Jakub Jelinek ---
I don't see the testcase FAILing on i?86 though, just on x86_64, and there
starting with Oct 2x (20th is still ok, 23rd fails, so likely r265398).
Let me have a look.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68771
--- Comment #27 from Iain Sandoe ---
(In reply to Daniel Vollmer from comment #26)
> (In reply to Iain Sandoe from comment #25)
> > (In reply to Daniel Vollmer from comment #24)
> > > (In reply to Iain Sandoe from comment #23)
> > Sadly, without
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89865
--- Comment #5 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #4)
> I don't see the testcase FAILing on i?86 though, just on x86_64, and there
> starting with Oct 2x (20th is still ok, 23rd fails, so likely r265398).
The testcase i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77875
--- Comment #4 from Marek Polacek ---
Doesn't this depend on the resolution of Core 1521 (still "drafting"), dealing
with T{expr} where T is a reference type? Which is what this PR is about:
void
f ()
{
int i = 42;
using T = int&;
T t = T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89865
--- Comment #6 from Jakub Jelinek ---
Ah, but that is only because r264897 adjusted the expected counts from 8 to
47/57 :(.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77875
--- Comment #5 from Jonathan Wakely ---
Yes, probably, but it doesn't seem useful for T{i} to do anything except bind a
reference of type T to i. Issue 1521 seems to be a problem with the wording,
such that it doesn't apply to references, but I d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89865
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89853
--- Comment #5 from Peter Bergner ---
(In reply to Martin Liška from comment #4)
> Just for the record, my Ryzen machine periodic tester probably improved due
> to the revision:
> https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=158.377.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89868
--- Comment #3 from Andrew Pinski ---
(In reply to Jonny Grant from comment #2)
> Ah that sounds possible. I imagine it is not GCC that would be the one that
> controls the core dumping? Perhaps where ever that code is, it could just
> say "Core
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89865
Jakub Jelinek changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89812
--- Comment #7 from Jakub Jelinek ---
Author: jakub
Date: Thu Mar 28 17:14:05 2019
New Revision: 270001
URL: https://gcc.gnu.org/viewcvs?rev=270001&root=gcc&view=rev
Log:
PR c/89812
* gcc.dg/attr-aligned-3.c: Limit the test to kn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89853
Martin Jambor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 89853, which changed state.
Bug 89853 Summary: Regression of 525.x264_r at -O2 (and generic tuning) on AMD
EPYC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89853
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89865
--- Comment #9 from Jakub Jelinek ---
Note, the r264897 change to the testcase was clearly bogus, because then the
testcase is really useless, the intent of the testcase was to check that all
(but the 8) peepholes did the right thing and there ar
1 - 100 of 169 matches
Mail list logo
