https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107931
--- Comment #7 from rguenther at suse dot de ---
On Thu, 1 Dec 2022, me at xenu dot pl wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107931
>
> --- Comment #5 from Tomasz Konojacki ---
> To sum this thread up, there are undocumented r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107946
--- Comment #3 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:5b50850c3c6f2eceb8012dcc8d3cd5ddd94fac6c
commit r13-4458-g5b50850c3c6f2eceb8012dcc8d3cd5ddd94fac6c
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43301
--- Comment #8 from Eric Gallager ---
(In reply to Eric Gallager from comment #7)
>
> Alexandre Oliva's assessment is that the issue was just one having an old
> build left over, and that all the patch did was to force a rebuild:
> https://gcc.g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59447
Eric Gallager changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59447
--- Comment #11 from CVS Commits ---
The master branch has been updated by Eric Gallager :
https://gcc.gnu.org/g:a710f3ce7474792c098ac6fe4dc6a366cdbb4fb4
commit r13-4457-ga710f3ce7474792c098ac6fe4dc6a366cdbb4fb4
Author: Eric Gallager
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84471
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107504
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
Assi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59447
Eric Gallager changed:
What|Removed |Added
Keywords||patch
URL|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107948
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107948
--- Comment #1 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:0b737090a69624dea5318c380620283f0321a92e
commit r13-4456-g0b737090a69624dea5318c380620283f0321a92e
Author: David Malcolm
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107413
--- Comment #19 from Rama Malladi ---
(In reply to Wilco from comment #17)
> (In reply to Rama Malladi from comment #16)
> > (In reply to Wilco from comment #15)
> > > (In reply to Rama Malladi from comment #14)
> > > > This fix also improved pe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107934
--- Comment #5 from Hongtao.liu ---
Fixed in GCC13.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107934
--- Comment #4 from CVS Commits ---
The master branch has been updated by hongtao Liu :
https://gcc.gnu.org/g:e055e6db974d8b8950b30859a853e0aee74e20c2
commit r13-4454-ge055e6db974d8b8950b30859a853e0aee74e20c2
Author: liuhongt
Date: Thu Dec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146
LIU Hao changed:
What|Removed |Added
CC||lh_mouse at 126 dot com
--- Comment #53 from L
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107539
Patrick Palka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107539
--- Comment #6 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:a4e577b044d69977f93b2cb7769dc991eadf2cf0
commit r13-4453-ga4e577b044d69977f93b2cb7769dc991eadf2cf0
Author: Patrick Palka
Date: T
-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../trunk/configure --prefix=/home/jerry/dev/usr
--enable-languages=c,c++,fortran --enable-libgomp --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20221201 (experimental) (GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107874
--- Comment #13 from Jerry DeLisle ---
A debug session gives:
(gdb) c
Continuing.
^C
Program received signal SIGINT, Interrupt.
futex_wait (private=0, expected=2, futex_word=0x405950) at
../sysdeps/nptl/futex-internal.h:146
146 int err =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107874
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106773
--- Comment #12 from James Hilliard ---
(In reply to James Hilliard from comment #10)
> (In reply to David Faust from comment #9)
> > Created attachment 54002 [details]
> > updated patch
> >
> > Update the 'extern' variable marking, and also ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107874
--- Comment #11 from anlauf at gcc dot gnu.org ---
And this is the output I'm getting on stdout:
tstuff
fstuff
T
tstuff
fstuff
F
tstuff
fstuff
T
tstuff
fstuff
F
tstuff
T
tstuff
F
fstuff
T
fstuff
F
Can you compare your output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106773
--- Comment #11 from James Hilliard ---
Also hitting this one in cgroup_hierarchical_stats.c:
$ /home/buildroot/bpf-next/tools/testing/selftests/bpf/tools/sbin/bpftool
--debug gen skeleton
/home/buildroot/bpf-next/tools/testing/selftests/bpf/bpf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106773
--- Comment #10 from James Hilliard ---
(In reply to David Faust from comment #9)
> Created attachment 54002 [details]
> updated patch
>
> Update the 'extern' variable marking, and also mark 'extern' funcs.
That fixes the issue in kfunc_call_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107874
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106773
David Faust changed:
What|Removed |Added
Attachment #53993|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107874
--- Comment #9 from Jerry DeLisle ---
I am seeing timeout failures with merge_1.f90. Can you look into this?
Thanks,
Jerry
On Thu, Dec 1, 2022, 12:28 PM anlauf at gcc dot gnu.org via Gcc-bugs <
gcc-bugs@gcc.gnu.org> wrote:
> https://gcc.gnu.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107874
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |13.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107922
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104160
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79083
Andrew Pinski changed:
What|Removed |Added
CC||stephan.oostveen@nextlevel-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107945
Andrew Pinski changed:
What|Removed |Added
Summary|static incomplete |static constexpr incomplete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107945
--- Comment #2 from Andrew Pinski ---
ICC has the same behavior as GCC, though I don't know if it was EDG marking
this as an extension or not.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107945
--- Comment #1 from Andrew Pinski ---
Reduced:
```
struct incomplete;
template struct C
{
static constexpr T t{};
};
int main() {
C t;
// t.t;
}
```
If we uncomment t.t, then GCC will reject it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59447
Eric Gallager changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107940
--- Comment #7 from Andrew Pinski ---
(In reply to laurent.alfo...@linaro.org from comment #0)
> sanitizer=address reports an issue while stack unwinding :
>
> ==13419==ERROR: AddressSanitizer: SEGV on unknown address 0x
> (pc 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107833
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107929
--- Comment #5 from cqwrteur ---
1. the real gap is much larger due to larger preprocessor space.
2. that is just an excuse. the mm_ intrinsic is implemented with builtin
functions on gcc and clang. You can always avoid include that header b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107947
--- Comment #5 from eggert at cs dot ucla.edu ---
Thanks for reporting the conformance bug in TZDB. I fixed it in the TZDB
development repository here:
https://github.com/eggert/tz/commit/9cfe9507fcc22cd4a0c4da486ea1c7f0de6b075f
and the fix sho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107515
--- Comment #9 from Stam Markianos-Wright ---
> Clearly Helium+Linux on Godbolt is a bit confused
Yea, I agree -- it still shouldn't be an unintuitive front-end type clash
error, though!
I've posted another patch:
https://gcc.gnu.org/pipermai
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107920
prathamesh3492 at gcc dot gnu.org changed:
What|Removed |Added
Attachment #53992|0 |1
is obsolete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107931
--- Comment #6 from Jakub Jelinek ---
If you use always_inline attribute and therefore want an error if some function
isn't inlined, to be precise. Otherwise it just wouldn't be inlined...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107931
--- Comment #5 from Tomasz Konojacki ---
To sum this thread up, there are undocumented rules that can cause a
semantically identical program to be rejected by the compiler under certain
optimisation levels (with an uninformative error message) a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107833
--- Comment #9 from Jakub Jelinek ---
Wasn't this discussed in the past in other PRs? Whether uninitialized vars
mean anything or anything but same value each time a SSA_NAME initialized to it
is used?
Because as this testcase shows, not all us
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106773
--- Comment #8 from David Faust ---
(In reply to James Hilliard from comment #5)
> (In reply to David Faust from comment #4)
> > Created attachment 53993 [details]
> > proposed patch
> >
> > Should fix the remaining issues with 'extern' linkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107833
--- Comment #8 from Jakub Jelinek ---
I think this is CCP's fault rather than VRP.
Everything I've looked at in the vrp2 dump looks right to me.
In the outer loop, h/i is
# RANGE [irange] int [0, 3] NONZERO 0x3
# h_41 = PHI
# i_44 = PHI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107678
Wilco changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |wilco at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107940
--- Comment #6 from laurent.alfonsi at linaro dot org ---
testing with other versions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107413
--- Comment #18 from Rama Malladi ---
(In reply to Wilco from comment #17)
> (In reply to Rama Malladi from comment #16)
> > (In reply to Wilco from comment #15)
> > > (In reply to Rama Malladi from comment #14)
> > > > This fix also improved pe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107833
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80677
--- Comment #5 from Andrew Pinski ---
https://gcc.gnu.org/pipermail/gcc-patches/2017-April/472727.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80677
--- Comment #4 from Andrew Pinski ---
https://gcc.gnu.org/pipermail/gcc/2014-January/211652.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107941
--- Comment #4 from Andrew Pinski ---
diagnostic_report_current_module in diagnostic.cc is what outputs the include
stack for the text output case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107941
--- Comment #3 from Andrew Pinski ---
(In reply to David Malcolm from comment #2)
> Does the SARIF output format contain the information you need?
No it does not:
{"$schema":
"https://raw.githubusercontent.com/oasis-tcs/sarif-spec/master/Schema
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107946
--- Comment #2 from Richard Biener ---
So with --param max-unswitch-depth=1 and -O2 -flto -march=znver2 + FDO I get
176s which is slower than with unswitching outer loops.
Means I cannot reproduce (at least with this specific feature, aka this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107863
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107941
--- Comment #2 from David Malcolm ---
Does the SARIF output format contain the information you need?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107897
Jakub Jelinek changed:
What|Removed |Added
Summary|[13 Regression] mangling|[13 Regression] mangling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107931
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107947
--- Comment #4 from Andrew Pinski ---
To expand on the invalid placement of the attribute, the C++ front-end also
rejects it and also see PR 101682 which is also asking about it, gnulib was
broken at one point.
I did find that clang accepts the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107300
--- Comment #6 from Jakub Jelinek ---
And yet another option would be to change the IFN_TRAP to a normal builtin with
space in name so users couldn't access it, which would somewhat simplify the
IPA code; for replacing a normal call stmt with in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107946
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |13.0
--- Comment #1 from Richard Biene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107539
Patrick Palka changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107300
--- Comment #5 from Martin Liška ---
@Honza: ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746
--- Comment #15 from Segher Boessenkool ---
Yup. I don't consider DEBUG_INSNs to be scheduled at all, only real things
are, but that is just vague terminology :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107947
--- Comment #3 from Jonathan Wakely ---
(In reply to WANG Xuerui from comment #0)
> I haven't bisected yet but can help doing so if necessary.
Bisection shows that it changed with r13-2976 which is the commit that added
support for the [[noretu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105204
--- Comment #3 from Avi Kivity ---
Does one have to declare all preconditions? I happen to know that shared_ptr
with a reference count of zero is impossible, and I can understand the compiler
not being able to infer it, but just because it's una
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107678
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #5 from Wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746
--- Comment #14 from Jakub Jelinek ---
(In reply to Segher Boessenkool from comment #13)
> DEBUG_INSNs should never influence any scheduling decisions, or any other
> decisions that influence what machine code we generate.
Well, with the except
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746
--- Comment #13 from Segher Boessenkool ---
DEBUG_INSNs should never influence any scheduling decisions, or any other
decisions that influence what machine code we generate.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107941
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2022-12-01
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107940
--- Comment #5 from Jonathan Wakely ---
Something seems very broken, and I don't think it's libstdc++.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107927
--- Comment #4 from Jonathan Wakely ---
It might be fixed by r13-4393-gcca06f0d6d76b0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107943
--- Comment #5 from Martin Liška ---
Created attachment 54000
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54000&action=edit
Partially reduced test-case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107948
Bug ID: 107948
Summary: GCC Static Analyzer doesn't realize `0 - width <= 0`
is always true when `width > 0` and `width is int`
type，
Product: gcc
Version: 13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107937
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107947
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107947
--- Comment #1 from WANG Xuerui ---
The corresponding Gentoo bug is at https://bugs.gentoo.org/883719.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107947
Bug ID: 107947
Summary: __has_c_attribute incorrectly identifies attribute as
supported
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107946
Bug ID: 107946
Summary: [13 Regression] 507.cactuBSSN_r regresses by ~9% on
znver3 with PGO since r13-3875-g9e11ceef165bc0
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107945
Bug ID: 107945
Summary: GCC accepts invalid program involving constexpr static
data member of class template
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Sev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 107413, which changed state.
Bug 107413 Summary: Perf loss ~14% on 519.lbm_r SPEC cpu2017 benchmark with
r8-7132-gb5b33e113434be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107413
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107413
Wilco changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106840
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106933
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107920
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746
--- Comment #12 from Jakub Jelinek ---
Alex, please correct me if I'm wrong, but I think the scheduling DEBUG_INSN
decision was that DEBUG_INSNs are somehow taken into account during scheduling,
not completely ignored, so that they actually move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107943
Martin Liška changed:
What|Removed |Added
Summary|gcc -fanalyzer hangs in |[11/12/13 Regression] gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107943
--- Comment #3 from Bernd Edlinger ---
this is how far I got with bisecting:
$ git bisect log
git bisect start
# good: [885f5c3d5763d46e02bd2f192765cb589b4c4fe4] Daily bump.
git bisect good 885f5c3d5763d46e02bd2f192765cb589b4c4fe4
# bad: [24b8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107943
--- Comment #2 from Bernd Edlinger ---
Created attachment 53998
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53998&action=edit
preprocessed source file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107499
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107943
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107409
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107929
--- Comment #4 from Matthias Kretz (Vir) ---
I agree that compilation speed is a problem. However,
1. GCC's vector extensions are not sufficient (especially for use of AVX-512
masks)
2. I see 0.6s difference between calling `g++ -O2 -march=sky
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84402
--- Comment #57 from Martin Liška ---
Created attachment 53997
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53997&action=edit
Partial linking path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84402
--- Comment #56 from Martin Liška ---
Created attachment 53996
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53996&action=edit
make all-host on Ryzen 9 with LTO partial linking
Using partial linking for the following 4 objects (gimple-mat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84402
--- Comment #55 from Martin Liška ---
Created attachment 53995
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53995&action=edit
make all-host on Ryzen 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107937
--- Comment #9 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:abf05583dbc86a6667b63f5bda6ba57fe55a1b25
commit r13-4437-gabf05583dbc86a6667b63f5bda6ba57fe55a1b25
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107944
Richard Biener changed:
What|Removed |Added
Summary|ICE in |[12/13 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84402
--- Comment #54 from Martin Liška ---
> Try LTOing libbackend.a?
So this option is not feasible as well, we're paying a too high price for
parallel WPA of the LTO and the resulting time on 32 cores is even slower :/
1 - 100 of 112 matches
Mail list logo
