https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118506
Andrew Pinski changed:
What|Removed |Added
Depends on||56547
--- Comment #1 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118483
--- Comment #10 from rguenther at suse dot de ---
On Wed, 15 Jan 2025, pinskia at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118483
>
> --- Comment #6 from Andrew Pinski ---
> I am not sure we need the :S in the end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 115895, which changed state.
Bug 115895 Summary: [15 Regression] FAIL: gcc.dg/vect/pr115385.c execution test
with -march=znver4 --param partial-vector-usage=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115895
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115895
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115895
--- Comment #4 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:1b5d2ccd060ce983c7459ee165275e0205271396
commit r15-6939-g1b5d2ccd060ce983c7459ee165275e0205271396
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118505
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118506
Bug ID: 118506
Summary: Missing FMA for `(a + 1.0) * b`
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118505
--- Comment #3 from Andrew Pinski ---
Note there is also a fma forming missing:
_69 = s_64 + 1.0e+0;
...
_71 = _69 * _70;
which is:
`(s_64 + 1.0) * _70` which can be rewritten as `s_64 * _70 + _70`
That might alone get the performance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118505
Andrew Pinski changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118505
--- Comment #1 from Dhruv Chawla ---
I'm not sure if this is an aarch64-specific issue or a middle-end issue, so
I've filed it under aarch64 for now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118505
Bug ID: 118505
Summary: [15 regression] aarch64: 25% regression in TSVC s258
since r15-3436-gb2b20b277988ab
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Seve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118504
Bug ID: 118504
Summary: Bogus -Wstringop-overflow warning on simple memcpy
type loop
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118503
--- Comment #6 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #5)
> Created attachment 60169 [details]
> Slightly reduced from the reduced testcase
Any more manual inlining causes the ICE to go away. Because of the
uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118503
--- Comment #5 from Andrew Pinski ---
Created attachment 60169
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60169&action=edit
Slightly reduced from the reduced testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118503
--- Comment #4 from Andrew Pinski ---
Note this creduced testcase is full of uninitialized variables.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118503
--- Comment #3 from Ted Rodgers ---
Comment on attachment 60168
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60168
reduced UnifiedSource-f2e18ffc-19.cpp.ii
builds with:
g++ -pipe -std=c++23 -fPIC -fmax-errors=20 -fasynchronous-unwind-t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118464
--- Comment #11 from Andrew Pinski ---
*** Bug 118503 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118503
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118503
--- Comment #1 from Ted Rodgers ---
Created attachment 60168
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60168&action=edit
reduced UnifiedSource-f2e18ffc-19.cpp.ii
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118503
Bug ID: 118503
Summary: [15 Regression] gcc-15.0.0_pre20250112 ICE with
webkit-gtk-2.46.5-r600: JSBigInt.cpp:1424:6: internal
compiler error: in exact_div, at poly-int.h:2160 1424
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118483
--- Comment #9 from Andrew Pinski ---
Created attachment 60167
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60167&action=edit
patch which I am testing for this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443
Bug 88443 depends on bug 113026, which changed state.
Bug 113026 Summary: Bogus -Wstringop-overflow warning on simple memcpy type loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113026
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113026
Andrew Pinski changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118492
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67886
--- Comment #4 from Andrew Pinski ---
Note in this example the reason why GCC able to optimize this way (even without
something like -fstrict-vtable-pointers) is because GCC is able to
speculatively devirtualize the inner function call (that mean
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113026
Alexandre Oliva changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443
Bug 88443 depends on bug 113026, which changed state.
Bug 113026 Summary: Bogus -Wstringop-overflow warning on simple memcpy type loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113026
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118492
Andrew Pinski changed:
What|Removed |Added
Keywords||alias
--- Comment #1 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118489
Hongtao Liu changed:
What|Removed |Added
Last reconfirmed||2025-01-16
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114277
--- Comment #9 from Andrew Pinski ---
> But reviewing that hunk made me realize that we did have the right bits in
> place to test for 0/1 values during expansion. So instead of recognizing the
> multiplication as a conditional move, we could
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114277
--- Comment #8 from Jeffrey A. Law ---
So I was playing with the patch Raphael and I put together a bit more. A few
things to note.
First, if we're going to use the match.pd bits in some way, they need to be
conditional on GIMPLE. If used on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118489
Hongtao Liu changed:
What|Removed |Added
Last reconfirmed|2025-01-16 00:00:00 |
Target Milestone|15.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118502
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2025-01-16
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115673
--- Comment #11 from Peter Bergner ---
(In reply to Sam James from comment #8)
> I'm still seeing this, but I think it's an actual bug, not a testism.
I will restate that Surya's IRA commit is a correct fix, so the
missed-optimization bug lies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19501
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118502
Bug ID: 118502
Summary: Add shrink wrapping testcase for
vector::push_back
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: missed-optimization, needs-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116743
--- Comment #25 from GCC Commits ---
The master branch has been updated by Eugene Rozenfeld :
https://gcc.gnu.org/g:e683c6b029f809c7a1981b4341c95d9652c22e18
commit r15-6933-ge683c6b029f809c7a1981b4341c95d9652c22e18
Author: Eugene Rozenfeld
Da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118019
--- Comment #14 from Vineet Gupta ---
(In reply to Robin Dapp from comment #7)
> > The problem is GCC-15 has performance regression compare to GCC-14 on both
> > strict align and we should fix it, we can't specify use no strict align in
> > GCC-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105220
--- Comment #4 from Jason Merrill ---
Further discussion raised that the parameter mapping lives somewhere on the
border. Consider https://godbolt.org/z/TEsWhd5oG
template concept C = B;
struct A {
template void f() requires C;
};
struct B
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118499
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118489
Hongtao Liu changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118396
--- Comment #10 from Marek Polacek ---
We have:
TARGET_EXPR
so object=D.2996 whose type is Data, so we do not go down the VOID_TYPE_P path
in cxx_eval_outermost_constant_expr, and evaluate the whole init to VOID_CST.
Obviously, that should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48
Andrew Pinski changed:
What|Removed |Added
Depends on||118483
--- Comment #3 from Andrew Pinsk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118499
--- Comment #6 from kargls at comcast dot net ---
(In reply to kargls from comment #5)
> (In reply to Thomas Koenig from comment #3)
> Yes, please lift the restriction. I ran into this issue while
> writing a testcase as well. As J3 is not con
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118499
--- Comment #5 from kargls at comcast dot net ---
(In reply to Thomas Koenig from comment #3)
> (In reply to kargls from comment #2)
> > Not Thomas, but ...
> >
> > https://j3-fortran.org/doc/year/24/24-116.txt
> >
> > The exponentiation operat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118483
Andrew Pinski changed:
What|Removed |Added
Known to fail||5.1.0
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102705
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|12.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102705
--- Comment #12 from GCC Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:903ab914dd48c3131ded0cf427da50c23168024c
commit r15-6929-g903ab914dd48c3131ded0cf427da50c23168024c
Author: Andrew Pinski
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118501
--- Comment #5 from Andrew Pinski ---
>Note: the code originates from thrust, not from libstdc++!
And the reason why it works with libstdc++s' complex definition is because
libstdc++ uses _Complex for double types and not arrays or fields.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118501
--- Comment #4 from Andrew Pinski ---
xorsign didn't change But what did change was `struct s1` changed into a
V2DF mode. and now a subreg of that causes issues. Maybe this needs to be
force_subreg now ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118501
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118501
--- Comment #2 from Andrew Pinski ---
Created attachment 60166
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60166&action=edit
Reduced further
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118396
--- Comment #9 from Marek Polacek ---
This difference seems to be the problem:
-vector::vector (&items_, (const struct Data &) &TARGET_EXPR >>>) >;
+vector::vector (&items_, (const struct Data &) &TARGET_EXPR ) >;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118501
--- Comment #1 from Sam James ---
The testcase looks really familiar..
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118396
--- Comment #8 from Andrew Pinski ---
Created attachment 60165
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60165&action=edit
Fixed up removing hard coded size_t, use __SIZE_TYPE__ instead and removed
__assert_failure
Just some small ch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118501
Sam James changed:
What|Removed |Added
Keywords||ice-on-valid-code
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118495
Iain Buclaw changed:
What|Removed |Added
CC||ibuclaw at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118501
Bug ID: 118501
Summary: aarch64: ICE in simplify_context::simplify_subreg
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118396
--- Comment #7 from Marek Polacek ---
// PR c++/118396
extern "C" void __assert_fail(const char *, const char *);
void *operator new(unsigned long, void *__p) { return __p; }
struct Foo {
virtual ~Foo() = default;
};
struct Data {
int sta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118499
--- Comment #4 from anlauf at gcc dot gnu.org ---
(In reply to Thomas Koenig from comment #3)
> (In reply to kargls from comment #2)
> > Not Thomas, but ...
> >
> > https://j3-fortran.org/doc/year/24/24-116.txt
> >
> > The exponentiation operat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118499
--- Comment #3 from Thomas Koenig ---
(In reply to kargls from comment #2)
> Not Thomas, but ...
>
> https://j3-fortran.org/doc/year/24/24-116.txt
>
> The exponentiation operator ** shall not be applied to UNSIGNED values.
That was something
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102705
Andrew Pinski changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118500
--- Comment #4 from Alejandro Colomar ---
(In reply to Andrew Pinski from comment #1)
> I think this need analyzer to handle really.
We get a -Wfree-nonheap-object if I change the strsep(3) call by s++.
I think we should treat any call that ge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118499
kargls at comcast dot net changed:
What|Removed |Added
CC||kargls at comcast dot net
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118500
--- Comment #3 from Alejandro Colomar ---
(In reply to Sam James from comment #2)
> With -O0/-O1, we do get -Wanalyzer-malloc-leak. It gets lost with >= -O2
> unless we use noinine on my_strdup. Not sure if that's another case of
> PR100717 and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118500
--- Comment #2 from Sam James ---
With -O0/-O1, we do get -Wanalyzer-malloc-leak. It gets lost with >= -O2 unless
we use noinine on my_strdup. Not sure if that's another case of PR100717 and so
on (we have a bunch of bugs for attributes being lo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118441
Tobias Burnus changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118500
Andrew Pinski changed:
What|Removed |Added
Component|c |analyzer
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118500
Bug ID: 118500
Summary: no diagnostics with strsep(3) and
[[gnu::malloc(free)]] attribute
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118499
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118499
Bug ID: 118499
Summary: Exponentiation of UNSIGNED is rejected
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118498
--- Comment #5 from Andrew Pinski ---
(In reply to Alejandro Colomar from comment #4)
>
> What about the leak? Is it not reported because main() is special? Or is
> it a bug?
Most likely a bug, I have not looked into how the leak detection s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118498
--- Comment #2 from Andrew Pinski ---
(In reply to Sam James from comment #1)
> Where's the deallocation?
I think he is saying there is a missing leak detection here.
-Wmismatched-dealloc does not come into play if there is no de-allocation (a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118498
--- Comment #4 from Alejandro Colomar ---
(In reply to Sam James from comment #1)
> Where's the deallocation?
There's not. I expected that(In reply to Andrew Pinski from comment #2)
> (In reply to Sam James from comment #1)
> > Where's the dea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118498
Andrew Pinski changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118498
--- Comment #3 from Sam James ---
Ah, that makes more sense.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118498
--- Comment #1 from Sam James ---
Where's the deallocation?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118498
Bug ID: 118498
Summary: -Wmismatched-dealloc false negative
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
--- Comment #42 from GCC Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:6f85a97248fdff15aadc9514c1118eee0293d256
commit r15-6926-g6f85a97248fdff15aadc9514c1118eee0293d256
Author: Jonathan Wakely
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118497
--- Comment #2 from Andrew Pinski ---
I wonder if the patch in r15-2810-g3c67a0fa1dd39a3378deb854a7fef0ff7fe38004
(which was reverted due to a bootstrap failure on aarch64) fixes this one too
..
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118493
Jonathan Wakely changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118441
--- Comment #5 from Tobias Burnus ---
>if (sym->formal_ns
> + && sym->attr.proc != PROC_INTRINSIC // temporary hack
I am afraid that this might break
/usr/include/finclude/math-vector-fortran.h
which contains lines like:
!GCC$
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118406
--- Comment #4 from anlauf at gcc dot gnu.org ---
Created attachment 60164
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60164&action=edit
Draft patch
This fixes the crash by switching over to another round in the conversion.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118495
--- Comment #3 from Brecht Sanders
---
I was just trying to build GCC 12,13,14 with D+libphobos using GCC11.
No success.
GCC12:
libtool: compile: /R/winlibs_gcc1564/gcc-12.4.0/build_mingw/./gcc/gdc
-B/R/winlibs_gcc1564/gcc-12.4.0/build_min
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118010
--- Comment #12 from Sam James ---
Huh, I'm actually still seeing this:
```
m2/gm2-libs-boot/Glibc.h:207:14: warning: type of ‘libc_lseek’ does not match
original declaration [-Wlto-type-mismatch]
207 | EXTERN off_t libc_lseek (int fd, ssize_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115673
--- Comment #10 from Sam James ---
ping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118497
--- Comment #1 from Jakub Jelinek ---
The reason this has been reported is that golang cgo has some weird code to
rewrite @GOT references which can deal with R_386_GOT32{,X} relocations only in
very limited subset of instructions, just movl symb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118497
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |15.0
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118497
Bug ID: 118497
Summary: [15 Regression] Worse code generated on i686-linux
since r15-1619
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118471
--- Comment #4 from anlauf at gcc dot gnu.org ---
(In reply to Tobias Burnus from comment #2)
> Seems as if a special case for Fortran pointers is needed, where the a->span
> has to be replaced by the byte size of the base type.
>
> (Needs some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118441
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71884
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |15.0
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118495
--- Comment #2 from Mikael Pettersson ---
(In reply to Sam James from comment #1)
> You're saying 12..14 all failed too, or you didn't try those?
I suspect it's related to gcc-11 being the last release where D could be
bootstrapped with only a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118496
--- Comment #2 from Jakub Jelinek ---
Unrolling is intentionally implemented using ANNOTATE_EXPR
annot_expr_unroll_kind.
So you need at least -O1 to see it in action.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118485
--- Comment #2 from Sam James ---
I saw something similar on arm but not investigated at all yet.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118496
--- Comment #1 from Tobias Burnus ---
Variant — for GCC, you need to switch to 'gcc (trunk)':
https://godbolt.org/z/Yce7rqdrW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118496
Bug ID: 118496
Summary: [OpenMP] "omp unroll" parsed — but not active
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: openmp
Severity: normal
Priority
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118396
--- Comment #6 from Marek Polacek ---
Somewhat reduced but it's still ugly:
```
extern "C" void __assert_fail(const char *, const char *);
struct Data;
void *operator new(unsigned long, void *__p) { return __p; }
template struct __new_allocato
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118396
--- Comment #5 from Sam James ---
*** Bug 118475 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118487
--- Comment #3 from Christoph Müllner ---
My initial comment about the need to sanitize the mask elements of
VEC_PERM_EXPR was correct, but there is nothing to be done for that, because
this is handled by ccp1.
The ICE reported here comes from
1 - 100 of 192 matches
Mail list logo
