https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97827
--- Comment #1 from Matthias Klose ---
my bad, this is not a regression. Seen when building the offload compiler with
LLVM 11 instead of LLVM 10 or 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 97830, which changed state.
Bug 97830 Summary: [11 Regression] ICE in expressions_equal_p at
gcc/tree-ssa-sccvn.c:5631 since r11-4982-g4d6b8d4213376e8a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97830
What
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97835
--- Comment #3 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:d12603b746986554981f5ee220926a36a6cb6baf
commit r11-5048-gd12603b746986554981f5ee220926a36a6cb6baf
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97830
--- Comment #6 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:aaccdb9cec423ef4de9d541dbe0a95fa3346f430
commit r11-5047-gaaccdb9cec423ef4de9d541dbe0a95fa3346f430
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97835
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97830
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97744
--- Comment #4 from Kewen Lin ---
The additional pass fre4 run triggers this, to disable fre4 can make it pass
(but to disable dse3 can't separately, so it's unrelated), further narrowing
down shows fre4 on the function MG3XDEMO is responsible. B
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97744
--- Comment #5 from Kewen Lin ---
btw, this is power7 specific, I found it can pass with -mcpu=power8.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88101
Jakub Jelinek changed:
What|Removed |Added
Attachment #49563|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97736
--- Comment #7 from CVS Commits ---
The master branch has been updated by Martin Liska :
https://gcc.gnu.org/g:5e303cdee1ff01e4b302ef2f913c0bdd84ab967e
commit r11-5049-g5e303cdee1ff01e4b302ef2f913c0bdd84ab967e
Author: Martin Liska
Date: Mon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97736
--- Comment #8 from Martin Liška ---
(In reply to ncm from comment #6)
> The referenced patch seems to have also deleted a fair bit of explanatory
> comment text, including a list of possible refinements for selected targets.
Sorry for that, I m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97736
Martin Liška changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97844
Roman Lebedev changed:
What|Removed |Added
CC||lebedev.ri at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97821
--- Comment #2 from Richard Biener ---
Created attachment 49568
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49568&action=edit
for the testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96734
--- Comment #8 from Martin Liška ---
All right, there's a compile farm mips64 machine gcc24 so I'll try it there..
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97844
--- Comment #3 from Jonathan Wakely ---
(In reply to Roman Lebedev from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > unsigned integer overflow DOES NOT EXIST. It is called wrapping only.
>
> > This is NOT undefined at all.
> I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97803
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|marxin at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97821
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97848
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88101
Jakub Jelinek changed:
What|Removed |Added
Attachment #49567|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97838
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97838
--- Comment #3 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:d0a206abc6cbf0e992bf82bbb3584686eae05d34
commit r11-5050-gd0a206abc6cbf0e992bf82bbb3584686eae05d34
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97832
--- Comment #2 from Richard Biener ---
It's again reassociation making a mess out of the natural SLP opportunity (and
thus SLP discovery fails miserably).
One idea worth playing with would be to change reassociation to rank references
from the s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97828
--- Comment #1 from ensadc at mailnesia dot com ---
Compilation failure with `std::list`: https://godbolt.org/z/vbqhax
Wrong result with `std::vector`: https://godbolt.org/z/axYbYr (expected output:
"42 42 42"; actual: "42 0 42")
It appears that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97843
--- Comment #1 from Iain Buclaw ---
(In reply to Alex from comment #0)
> This code:
>
> import std.stdio;
>
> ubyte sum(ubyte[] bytes)
> {
> ubyte result;
> foreach(x;bytes)
> result += x;
> return result;
> }
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97828
--- Comment #2 from ensadc at mailnesia dot com ---
This seems to fix the bug (note: not thoroughly tested)
diff --git a/libstdc++-v3/include/bits/ranges_algo.h
b/libstdc++-v3/include/bits/ranges_algo.h
index f1a4cc24c0d..414ce0b1baa 100644
--- a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97842
--- Comment #1 from Iain Buclaw ---
It would be great if you can use dustmite to make a reduced test case,
preferably by reducing phobos as well so it's just a standalone test.
https://github.com/CyberShadow/DustMite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97803
--- Comment #6 from CVS Commits ---
The master branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:9dbf8dc7a96a8020e0ee05926ef7a3f976e9c318
commit r11-5054-g9dbf8dc7a96a8020e0ee05926ef7a3f976e9c318
Author: H.J. Lu
Date: Wed Nov 11 15:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97843
--- Comment #2 from Alex ---
I agree that the order of evaluation of operands is undefined and writing code
that depends on that order would not be reliable. In this case it's the
execution of the assign expression happening before all the operan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787
--- Comment #8 from rguenther at suse dot de ---
On Fri, 13 Nov 2020, bunk at stusta dot de wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787
>
> --- Comment #7 from Adrian Bunk ---
> (In reply to Richard Biener from comment #6)
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97834
--- Comment #3 from Nathan Sidwell ---
gcov has its own buffer. Hm, perhaps its not (no longer?) matching typical
disc block sizes. Back then they were 512bytes, now they're usually 4K, right?
Is gcov's buffer 1K?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96734
--- Comment #9 from Martin Liška ---
g++ -std=c++11 -fno-PIE -c -g -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97849
Bug ID: 97849
Summary: aarch64: ICE (segfault) during GIMPLE pass: ifcvt
since r10-3543-gf30b3d28
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97849
Alex Coplan changed:
What|Removed |Added
Known to fail||11.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91486
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |11.0
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97803
H.J. Lu changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97850
Bug ID: 97850
Summary: [11 Regression] aarch64: ICE in expand_insn, at
optabs.c:7467 since r11-1143-gb05d5563f
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97850
Alex Coplan changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
Tar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97850
Richard Biener changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97842
--- Comment #2 from Iain Buclaw ---
I think it is this issue that is being hit:
https://issues.dlang.org/show_bug.cgi?id=18970
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91486
--- Comment #14 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #13)
> Those are doing exactly what the Networking TS requires.
For that matter, so was our implementation of condition_variable::wait_for that
was changed for bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97834
--- Comment #4 from Roland Illig ---
(In reply to Nathan Sidwell from comment #3)
> gcov has its own buffer.
I wish the above were true. Using gcov from GCC 5.5.0, ktrace shows that the
actual buffer size is 0. That's consistent with the setbu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97842
--- Comment #3 from Iain Buclaw ---
Upstream PR raised with related backports.
https://github.com/dlang/dmd/pull/11971
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97851
Bug ID: 97851
Summary: aarch64: Wrong code with -Os -fmodulo-sched since
r7-879-g43c0068e60
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97834
--- Comment #5 from Nathan Sidwell ---
you're looking in the wrong place. see gcov_var and GCOV_BLOCK_SIZE. it is
indeed 1k, but there;s some buffer doubling code in gcov_allocate that I don't
recall and am not sure why it's needed/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97757
--- Comment #3 from Jan Hubicka ---
This is problem with propagate_in_scc sometimes freeing the summary and losing
track of it. It is fixed in
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559116.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97852
Bug ID: 97852
Summary: Parameter pack not found
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97851
Richard Biener changed:
What|Removed |Added
CC||zhroma at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97853
Bug ID: 97853
Summary: [11 regression] go front end fails to bootstrap
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97834
--- Comment #6 from Martin Liška ---
(In reply to Roland Illig from comment #0)
> Since 2003-05-14, gcov_open calls setbuf (gcov_var.file, (char *)0), thereby
> slowing down the instrumentation a lot.
>
Can you please explain what's slow? Is it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97840
--- Comment #7 from CVS Commits ---
The master branch has been updated by Jan Hubicka :
https://gcc.gnu.org/g:0c9687d0daa08c33456210b87e4060d6397ff4d8
commit r11-5060-g0c9687d0daa08c33456210b87e4060d6397ff4d8
Author: Jan Hubicka
Date: Mon No
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97843
--- Comment #3 from Iain Buclaw ---
(In reply to Alex from comment #2)
> I agree that the order of evaluation of operands is undefined and writing
> code that depends on that order would not be reliable. In this case it's the
> execution of the a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97843
--- Comment #4 from Iain Buclaw ---
Might be a regression caused by the fix for PR96924
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97828
Alexey Mission changed:
What|Removed |Added
CC||space.mission at yandex dot ru
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92407
Moritz Sichert changed:
What|Removed |Added
CC||sichert at in dot tum.de
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97843
--- Comment #5 from Iain Buclaw ---
(In reply to Alex from comment #2)
> The arithmetic equivalent would be for:
> X += 4/2
> To be produce:
> Immediate load Register with 4
> Add register with 4 in it to x
> Divide register with 4 in it by 2
> R
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97828
--- Comment #4 from Jonathan Wakely ---
(In reply to Alexey Mission from comment #3)
> Please see also cppreference.com where this bug is also spotted:
> https://en.cppreference.com/w/Talk:cpp/algorithm/ranges/search_n
Reporting bugs in a talk p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97828
--- Comment #5 from Jonathan Wakely ---
Also, don't paste copyrighted code into talk pages on cppreference.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9
--- Comment #4 from qinzhao at gcc dot gnu.org ---
this should be a bug in the pass "stack".
if I modify the file "reg-stack.c" as following:
qinzhao@gcc10:~/Work/write_gcc/gcc$ git diff reg-stack.c
diff --git a/gcc/reg-stack.c b/gcc/reg-stack.c
i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97853
Andreas Schwab changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97840
Andreas Schwab changed:
What|Removed |Added
CC||seurer at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97854
Bug ID: 97854
Summary: [11 regression] ODR violation in stub-objc.c
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ob
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97693
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2020-11-16
Ever confir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97693
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97855
Bug ID: 97855
Summary: [11 regression] Bogus warning locations during
lto-bootstrap
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97595
--- Comment #5 from Jason Merrill ---
(In reply to Martin Sebor from comment #3)
> I can confirm the warning but I'm not sure the bug is in the middle end
> code. Let me CC Jason for his comments.
>
> The warning triggers for the MEM_REF below:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97828
Patrick Palka changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97856
Bug ID: 97856
Summary: Missed optimization: repeated call
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimiz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97840
--- Comment #9 from Jan Hubicka ---
Created attachment 49571
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49571&action=edit
Warnings building cc1plus with LTO
This is current set of wranings building cc1plus with LTO. there are 66
maybe-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97857
Bug ID: 97857
Summary: profiledbootstrap broken freeing speculative call
summary
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97858
Bug ID: 97858
Summary: [11 regression] Bogus warnings about va_list during
profiledbootstrap
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97859
Bug ID: 97859
Summary: [11 Regression] bootstrap error building a gnat cross
compiler targeting ppc64le on x86_64-linux-gnu
Product: gcc
Version: 11.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589
Thomas Koenig changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #12 from Thomas Koenig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97736
--- Comment #10 from ncm at cantrip dot org ---
Don't understand, the compiler we are using (9) has the
regression. It looks like a trivial backport.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97860
Bug ID: 97860
Summary: [11 Regression] ICE in handle_argspec_attribute, at
c-family/c-attribs.c:3244
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97861
Bug ID: 97861
Summary: [11 Regression] ICE in warn_parm_array_mismatch, at
c-family/c-warn.c:3378
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97862
Bug ID: 97862
Summary: [11 Regression] ICE in expand_omp_for_init_vars, at
omp-expand.c:2524
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97863
Bug ID: 97863
Summary: ICE in ix86_expand_split_stack_prologue, at
config/i386/i386.c:9796
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97859
--- Comment #1 from Matthias Klose ---
targeting aarch64-linux-gnu with the same version works
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97854
Martin Liška changed:
What|Removed |Added
Target Milestone|--- |11.0
Version|unknown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97854
Martin Liška changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97862
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97857
Martin Liška changed:
What|Removed |Added
Ever confirmed|0 |1
Summary|profiledbootstrap br
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97736
--- Comment #11 from Jakub Jelinek ---
We usually don't backport optimization improvements, even if they fix
regressions, to release branches. There are quite high risks involved.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97860
Martin Liška changed:
What|Removed |Added
Known to work||10.2.0
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97861
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97862
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97857
--- Comment #2 from Jan Hubicka ---
> I see a similar bootstrap failure that's with:
>
> ../configure --enable-languages=c,c++,lto --prefix=/home/marxin/bin/gcc
> --disable-multilib --without-isl --disable-libsanitizer
> --with-build-config=boot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97863
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
> I see a similar bootstrap failure that's with:
>
> ../configure --enable-languages=c,c++,lto --prefix=/home/marxin/bin/gcc
> --disable-multilib --without-isl --disable-libsanitizer
> --with-build-config=bootstrap-lto-lean && make profiledbootstrap
> 'STAGE1_CFLAGS=-g -O2'
>
> started with r11-4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97857
--- Comment #3 from Martin Liška ---
(In reply to Jan Hubicka from comment #2)
> > I see a similar bootstrap failure that's with:
> >
> > ../configure --enable-languages=c,c++,lto --prefix=/home/marxin/bin/gcc
> > --disable-multilib --without-is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97857
--- Comment #4 from Jan Hubicka ---
> > Yep, I already worked out it is ipa-icf...
> > Do you have easy way to bisect what merge is causing the failure?
>
> Working on that will send details soon.
Great, thanks. In meantime I will check if I ca
> > Yep, I already worked out it is ipa-icf...
> > Do you have easy way to bisect what merge is causing the failure?
>
> Working on that will send details soon.
Great, thanks. In meantime I will check if I can isolate one of the paths
(constant access merging, variable access merging on the two o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97857
--- Comment #5 from Martin Liška ---
I'm planning to use merged_ipa_icf debug counter to isolate that..
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97862
--- Comment #2 from Jakub Jelinek ---
With r11-1967-g5acef69f9d3d9f3c537b5e5157519edf02f86c4d actually.
The version you've mentioned started (properly) rejecting it, this wasn't valid
in OpenMP 4.5, but is valid in 5.0 and for GCC11 the support h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97857
--- Comment #6 from Martin Liška ---
It crashes here:
echo timestamp > stmp-int-hdrs
/home/mliska/Programming/gcc/objdir/./gcc/xgcc
-B/home/mliska/Programming/gcc/objdir/./gcc/ -xc -nostdinc /dev/null -S -o
/dev/null -fself-test=../../gcc/testsu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97857
--- Comment #7 from Jan Hubicka ---
It seems to crash on quite few locaitons but always related to indirect
calls. So perhaps there is some sort of weird relation to indirect call
profiling or devirutalization...
I am going to move my build to
It seems to crash on quite few locaitons but always related to indirect
calls. So perhaps there is some sort of weird relation to indirect call
profiling or devirutalization...
I am going to move my build to faster machine.
Honza
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97832
--- Comment #3 from Michael_S ---
(In reply to Richard Biener from comment #2)
> It's again reassociation making a mess out of the natural SLP opportunity
> (and thus SLP discovery fails miserably).
>
> One idea worth playing with would be to ch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97840
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #10
1 - 100 of 188 matches
Mail list logo
