https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119102
Bug ID: 119102
Summary: GCC 15.0 'import std;' fails with Ofast (not with O3)
due to some openmp internal error
Product: gcc
Version: 15.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119102
--- Comment #1 from Igor Machado Coelho ---
Note that if first building the std module with O3 and then linking with Ofast,
it works fine:
g++-15 -std=c++23 -O3 -fmodules -fsearch-include-path bits/std.cc main.cpp -o
example
# this generates g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118874
--- Comment #6 from Iain Sandoe ---
is this related to or maybe a dup of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117364 ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119073
Jason Merrill changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118874
--- Comment #7 from Jakub Jelinek ---
Most likely yes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103391
--- Comment #9 from paul.richard.thomas at gmail dot com ---
That was a question at the end, not a statement :-) I cannot see anything
wrong with the test case but wondered if one of the more eagle-eyed of us
could see a standardese problem wit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77872
Andre Vehreschild changed:
What|Removed |Added
Status|ASSIGNED|WAITING
--- Comment #15 from Andre V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119071
--- Comment #10 from Jakub Jelinek ---
cse1 optimizes insn optimizes insn 15 away in:
(insn 10 9 11 2 (parallel [
(set (reg:SI 84 [ _3 ])
(plus:SI (reg:SI 96)
(reg:SI 92 [ _18 ])))
(clo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119099
Jeffrey A. Law changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119071
Jakub Jelinek changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118739
--- Comment #18 from GCC Commits ---
The master branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:a92dc3fe31c95d56019b2fb95a58414bca06241f
commit r15-7793-ga92dc3fe31c95d56019b2fb95a58414bca06241f
Author: Uros Bizjak
Date: Wed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118874
--- Comment #5 from Jakub Jelinek ---
I'm unsure if this should be a P1, the P1-ish part on this is solely that a
test was added that ICEs, but the test ICEd before for several years as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117919
--- Comment #7 from GCC Commits ---
The releases/gcc-14 branch has been updated by Filip Kastl
:
https://gcc.gnu.org/g:6ffbc711afbda9446df51fd2b542ecd61853283d
commit r14-11373-g6ffbc711afbda9446df51fd2b542ecd61853283d
Author: Filip Kastl
Dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118874
--- Comment #8 from Iain Sandoe ---
the comments in PR117364, lead me to believe that this is a problem down-stream
of the FE that happens to be exposed frequently by coroutines (since we need to
populate because of the phasing required of that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118874
--- Comment #9 from Jakub Jelinek ---
Looking at the simpler
struct C { void *p; explicit C (void *p) : p(p) {} };
C foo (int i, void *p) { C c (p); return c; }
test, -O2 -m32 vs. -O2 -m64 -mptr64 the reason why is used in the
first case and n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119093
Richard Biener changed:
What|Removed |Added
Keywords||ice-on-valid-code
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118747
--- Comment #6 from GCC Commits ---
The master branch has been updated by Andre Vehreschild :
https://gcc.gnu.org/g:43c11931acc50f3a44efb485b03e6a8d44df97e0
commit r15-7789-g43c11931acc50f3a44efb485b03e6a8d44df97e0
Author: Andre Vehreschild
D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119098
--- Comment #2 from Richard Biener ---
In the Makefile I see
version.go: s-version; @true
s-version: Makefile
rm -f version.go.tmp
echo "package sys" > version.go.tmp
echo 'const GccgoToolDir = "$(libexecsubdir)"' >> ver
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119098
--- Comment #3 from Richard Biener ---
So for GCC 15 I suggest to bump the SONAME. But this behavior really looks odd
with bad separation of compiler driver and runtime?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119076
--- Comment #10 from Jakub Jelinek ---
Created attachment 60643
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60643&action=edit
gcc15-pr119076.patch
Untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119083
--- Comment #7 from Hongtao Liu ---
(In reply to Hongtao Liu from comment #5)
> (In reply to H.J. Lu from comment #3)
> > Created attachment 60640 [details]
> > A patch to remove SSE_FIRST_REG from ix86_class_likely_spilled_p
> >
> > Hongtao, c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118983
--- Comment #3 from Andrew Pinski ---
*** Bug 119095 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119095
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119090
--- Comment #3 from Manuel Alfayate ---
WHAT "-march=native -mtune=native" ENABLES ON MY SYSTEM
gcc -march=native -mtune=native -Q --help=target
The following options are target specific:
-m128bit-long-double [enab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99538
Simon Martin changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119067
--- Comment #12 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:f22e89167b3abfbf6d67f42fc4d689d8ffdc1810
commit r15-7790-gf22e89167b3abfbf6d67f42fc4d689d8ffdc1810
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119067
Richard Biener changed:
What|Removed |Added
Known to work||15.0
Summary|[14/15 Regress
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119067
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
--- Comment #11 from Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119092
Richard Biener changed:
What|Removed |Added
Component|middle-end |c
--- Comment #3 from Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119095
Bug ID: 119095
Summary: GCC in Ubuntu 20.04, 22.04 and 24.04 all have this
problem.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119096
Bug ID: 119096
Summary: Loop with conditional, cast and reduction vectorized
incorrectly with AVX-512
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
Severity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119097
Bug ID: 119097
Summary: Modules references internal linkage entity
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119096
--- Comment #2 from Andrew Pinski ---
The vectorizer looks ok though:
mask_patt_37.15_52 = [vec_unpack_lo_expr] mask__9.14_51;
mask_patt_37.15_53 = [vec_unpack_hi_expr] mask__9.14_51;
vect_patt_36.18_57 = .COND_ADD (mask_patt_37.15_52, vec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119096
--- Comment #1 from Andrew Pinski ---
Gimple level:
vect__4.8_45 = MEM [(int *)A_15(D)];
vect__10.16_54 = [vec_unpack_lo_expr] vect__4.8_45;
vect__10.16_55 = [vec_unpack_hi_expr] vect__4.8_45;
mask__5.9_46 = vect__4.8_45 > { 0, 0, 0, 0,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119096
Sam James changed:
What|Removed |Added
Target Milestone|--- |14.3
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119096
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119098
Bug ID: 119098
Summary: GO built from GCC 14 sources no longer works when
installing libgo23 build from GCC 15
Product: gcc
Version: 15.0
Status: UNCONFIRMED
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119098
Richard Biener changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119096
--- Comment #3 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #2)
> The vectorizer looks ok though:
> mask_patt_37.15_52 = [vec_unpack_lo_expr] mask__9.14_51;
> mask_patt_37.15_53 = [vec_unpack_hi_expr] mask__9.14_51;
> vec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119090
--- Comment #2 from Richard Biener ---
Also can you specify what 'native' maps to for you? What processor do you
have?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119099
Sam James changed:
What|Removed |Added
CC||law at gcc dot gnu.org,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119096
--- Comment #5 from Richard Biener ---
I'm testing
diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
index dc15b955aad..52533623cab 100644
--- a/gcc/tree-vect-loop.cc
+++ b/gcc/tree-vect-loop.cc
@@ -9064,7 +9064,7 @@ vect_transform_red
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68241
Bug 68241 depends on bug 118747, which changed state.
Bug 118747 Summary: [15 Regression]: seg fault on accessing an elemental
procedure dummy argument's deferred-length component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118747
Wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119057
--- Comment #4 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:758de6263dfc7ba8701965fa468691ac23cb7eb5
commit r15-7791-g758de6263dfc7ba8701965fa468691ac23cb7eb5
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119057
Richard Biener changed:
What|Removed |Added
Known to work||15.0
Summary|[15 regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119099
Bug ID: 119099
Summary: Compile-time hang in DCE
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118747
Andre Vehreschild changed:
What|Removed |Added
Resolution|--- |FIXED
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116125
Richard Sandiford changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118318
--- Comment #18 from Martin Jambor ---
I have proposed the patch on the mailing list:
https://inbox.sourceware.org/gcc-patches/ri6bjui45il@virgil.suse.cz/T/#u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119082
--- Comment #3 from Jonathan Wakely ---
(In reply to qurong from comment #0)
> GCC 12.4/13.3/11.4 erroneously compiles code
So you already figured out that this bug was fixed in GCC 14?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118976
Richard Sandiford changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119057
--- Comment #3 from Richard Biener ---
So there's code in check_reduction_path that checks for additional uses of the
path defs that explicitly allows out-of-loop uses for the "tail":
/* Check there's only a single stmt the op is used on.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119099
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
--- Comment #2 from Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119096
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118785
--- Comment #13 from GCC Commits ---
The master branch has been updated by Martin Jambor :
https://gcc.gnu.org/g:d05b64bdd048ffb7f72d97553888934a9bcd13fa
commit r15-7792-gd05b64bdd048ffb7f72d97553888934a9bcd13fa
Author: Martin Jambor
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118756
--- Comment #6 from GCC Commits ---
The master branch has been updated by Martin Jambor :
https://gcc.gnu.org/g:d05b64bdd048ffb7f72d97553888934a9bcd13fa
commit r15-7792-gd05b64bdd048ffb7f72d97553888934a9bcd13fa
Author: Martin Jambor
Date: M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118785
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118318
--- Comment #19 from Sam James ---
Thank you both. I wanted to have a go but was a bit lost.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103379
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed|2021-11-23 00:00:00 |2025-3-3
--- Comment #4 from Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119100
Bug ID: 119100
Summary: RISC-V: missed opportunities for vector-scalar
instructions
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103391
Andre Vehreschild changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |vehre at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119101
Bug ID: 119101
Summary: Function compiled with Gflortran appears to produce a
pointer that points at itself.
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119100
--- Comment #1 from Richard Biener ---
doesn't late-combine and/or forwprop not have the single-BB restriction? Also
when the vec-duplicate is hoisted out of a loop this then becomes a
register pressure in vector vs. scalar regset issue only?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119070
--- Comment #7 from Taylor Hutt ---
(In reply to Andrew Pinski from comment #6)
> You could do:
>
>struct_1 *v1 = &global_0.f_2_0;
>asm("":"+r"(v1));
>unsigned char *v2 = (unsigned char *)v1;
>
> to hide from GCC that the addr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119089
John David Anglin changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118874
--- Comment #12 from Jakub Jelinek ---
(In reply to Iain Sandoe from comment #10)
> In the coroutine handling to deal with
> https://eel.is/c++draft/dcl.fct.def.coroutine#7
>
> we unconditionally create the return object in the slot - if we
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118874
--- Comment #13 from Jakub Jelinek ---
That check_return_expr call in
/* Without a relevant location, bad conversions in check_return_expr
result in unusable diagnostics, since there is not even a mention
of the relevant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119071
--- Comment #13 from Uroš Bizjak ---
(In reply to Sam James from comment #12)
> This works for me on trunk. Did Uros' r15-7793-ga92dc3fe31c95d fix it?
Yes, this is the same issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119071
Sam James changed:
What|Removed |Added
CC||uros at gcc dot gnu.org
--- Comment #12 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119101
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Known to fail||13.3.0, 14.2.0
Key
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101507
--- Comment #2 from Vladimir Makarov ---
Sorry, I've tried gcc-12, gcc-13, gcc-14, trunk dated by Aug 1, and today trunk
but I did not managed to reproduce the error.
Probably, it was fixed by some LRA patch (there were a lot of them since 2021
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118874
--- Comment #11 from Jakub Jelinek ---
In the
#include
struct B {
bool await_ready () const noexcept;
void await_suspend (std::coroutine_handle<> h) const noexcept;
void await_resume () const noexcept;
};
struct C {
struct promise_typ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119071
--- Comment #14 from Jakub Jelinek ---
Indeed, r15-7793-ga92dc3fe31c95d56019b2fb95a58414bca06241f fixed this.
I'll prepare a patch with the testcases.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119104
--- Comment #1 from Andrew Pinski ---
Non zero and zero are runtime values of here. Rather than compile
characteristics of that argument.
Maybe just:
If the runtume value of the integral argument is zero, the pointer argument can
be null; or if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119083
--- Comment #8 from H.J. Lu ---
Created attachment 60647
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60647&action=edit
A patch to remove CREG and BREG from ix86_class_likely_spilled_p
Hongtao, can you measure its impact on SPEC CPU 201
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118924
Martin Jambor changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118924
--- Comment #14 from Martin Jambor ---
So something like the following - which is completely untested, the
type test may be a wrong one, I'd like to think this through a little
more before actually proposing this, but any comments still welcome:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119104
Bug ID: 119104
Summary: Unclear documentation for [[gnu::nonnull_if_nonzero]]
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117061
--- Comment #4 from eczbek.void at gmail dot com ---
Constructors too :(
```
template
struct S {
S(int x) requires(requires { [x] { x; }; }) {}
};
```
```
: In lambda function:
:3:41: error: use of parameter outside function body before ';
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118996
--- Comment #16 from Hongtao Liu ---
(In reply to Hongtao Liu from comment #14)
> (In reply to H.J. Lu from comment #13)
> > (In reply to H.J. Lu from comment #11)
> > > Created attachment 60609 [details]
> > > An untested patch
> >
> > Hongtao
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119083
--- Comment #9 from Hongtao Liu ---
(In reply to H.J. Lu from comment #8)
> Created attachment 60647 [details]
> A patch to remove CREG and BREG from ix86_class_likely_spilled_p
>
> Hongtao, can you measure its impact on SPEC CPU 2017?
Ok.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119009
--- Comment #3 from Michal Jireš ---
Thanks a lot for the script.
I have reproduced it:
# bad3714b - before my patch
BM_UIOVecSink/0 33.8 us 33.8 us 20659 bytes_per_second=2.82508G/s html
# 0895aef0 - my patch
BM_UIOVe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103391
--- Comment #11 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #10)
> ChatGPT seems to be no real help. I just tried it on comment#7, and it said:
>
> "Conclusion
>
> The original code is not standard-conforming because it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119102
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119102
--- Comment #3 from Jonathan Wakely ---
Comparing the preprocessed source for the std.cc module definition file, I see
lots of lines with a simd attribute added when compiled with -Ofast:
--- std-O3.ii 2025-03-03 17:20:32.885607902 +
+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119103
Bug ID: 119103
Summary: Very suboptimal AVX2 code generation of simple shift
loop
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101577
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |15.0
Status|ASSI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32630
Bug 32630 depends on bug 101577, which changed state.
Bug 101577 Summary: [Interop] TYPE with BIND(C): Reject empty TYPE with zero
components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101577
What|Removed |Ad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119100
--- Comment #2 from Jeffrey A. Law ---
It's even more complicated than that. You have to consider that there can be a
cost to move data across the units. ie, it may actually be cheaper to use the
variant that broadcasts the value across a vect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119104
--- Comment #2 from Alejandro Colomar ---
(In reply to Andrew Pinski from comment #1)
> Non zero and zero are runtime values of here. Rather than compile
> characteristics of that argument.
>
> Maybe just:
> If the runtume value of the integral
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103391
--- Comment #12 from Andre Vehreschild ---
Mhhh, when one needs to know the "correct answer" to get it from an AI, what
help is the AI then?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119089
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #12 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119103
Hongtao Liu changed:
What|Removed |Added
CC||liuhongt at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119103
--- Comment #5 from Hongtao Liu ---
(In reply to Hongtao Liu from comment #4)
> vect_recog_over_widening_pattern could be extended with range info for this?
Looks like vectorizer already have range_info from
vect_determine_precisions_from_range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119095
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #2 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118874
--- Comment #10 from Iain Sandoe ---
In the coroutine handling to deal with
https://eel.is/c++draft/dcl.fct.def.coroutine#7
we unconditionally create the return object in the slot - if we create
it somewhere else, that causes us to produce a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119102
--- Comment #4 from Jonathan Wakely ---
We're taking the non-OpenMP branch there, but the error from GCC seems to be
incorrectly referring to OpenMP.
The docs for attribute simd say:
If the attribute is specified and #pragma omp declare simd i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119103
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Severity|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119103
Andrew Pinski changed:
What|Removed |Added
Summary|Very suboptimal AVX2 code |shift not demotated when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101577
--- Comment #2 from GCC Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:f9f16b9f74b767ca799a82f25be66a5fed25756d
commit r15-7798-gf9f16b9f74b767ca799a82f25be66a5fed25756d
Author: Harald Anlauf
Date: S
1 - 100 of 104 matches
Mail list logo
