++
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
#include
template
void foo ()
{
if constexpr ((T) std::is_constant_evaluated ())
;
}
void
bar ()
{
foo ();
}
emits bogus warning with -std=c++17 -Wall.
Once it (incorrectly) warns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114555
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
--- Comment #12 from Jakub Jelinek ---
Not an expert on TYPE_CANONICAL, but my understanding is that non-NULL
TYPE_CANONICAL is just an optimization to speed up type comparisons (but it
seems c-typeck.cc doesn't actually use that, so it is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
Jakub Jelinek changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114576
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
--- Comment #5 from Jakub Jelinek ---
Oops, return stmt missing:
struct S foo (const struct S *);
struct S {};
struct S bar (const struct S **) { return (struct S) {}; }
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
--- Comment #4 from Jakub Jelinek ---
Slightly cleaned up testcase:
struct S foo (const struct S *);
struct S {};
struct S bar (const struct S **) {}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114536
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
||2024-04-03
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
Created attachment 57863
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57863=edit
gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114552
Jakub Jelinek changed:
What|Removed |Added
Summary|[13/14 Regression] wrong|[13 Regression] wrong code
)
||since r14-9763
Last reconfirmed||2024-04-03
Status|UNCONFIRMED |NEW
Target Milestone|--- |14.0
CC||jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114555
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112303
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114572
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
|ASSIGNED
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
--- Comment #10 from Jakub Jelinek ---
Created attachment 57853
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57853=edit
gcc14-pr114533.patch
Untested fix. Unfortunately, we don't h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114533
--- Comment #8 from Jakub Jelinek ---
I guess we should go with the above patch after fixing formatting, but it isn't
enough,
printf_fphex.c has similar code.
Even in glibc which doesn't support printing _Float128 nor any other type which
would
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114560
--- Comment #3 from Jakub Jelinek ---
(In reply to Meirav Grimberg from comment #2)
> (In reply to Jakub Jelinek from comment #1)
> > AVX512BW is needed to be able to use __mmask32/__mmask64, those aren't
> > supported in AVX512F, which only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114560
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114561
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |11.5
Priority|P3
||r10-7410
CC||jakub at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek ---
Started with r10-7410-g72809d6fe8e085440403ce125c51d01d6e7512b0 too.
operator and
|pointer |forwarding reference to
||pointer since r10-7410
Ever confirmed|0 |1
CC||jakub at gcc dot gnu.org
Last
at gcc dot gnu.org |jakub at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek ---
Created attachment 57850
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57850=edit
gcc14-pr114552.patch
Untested fix.
Note, perhaps for GCC 15 we could support even non-matching sizes, as long as
w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114552
--- Comment #4 from Jakub Jelinek ---
The r13-989 to r13-990 difference is
- movlk(%rip), %eax
- movl%eax, (%rsp)
- movzwl k+4(%rip), %eax
- movw%ax, 4(%rsp)
+ movw$1, (%rsp)
+ movl$0,
|code at -O1 and above on|code at -O1 and above on
|x86_64-linux-gnu|x86_64-linux-gnu since
||r13-990
CC||jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114551
--- Comment #2 from Jakub Jelinek ---
Started with r14-2944-g3d48c11ad082def8ee237e5778d8a5d569bff96d
a is -1, so the testcase shouldn't do much except almost empty loops with a few
iterations.
The continue in there seems to be important, but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114533
--- Comment #2 from Jakub Jelinek ---
>From what I can see, glibc uses there the same thing as libquadmath does, so
why is it ok on the glibc side and not on the libquadmath side?
I mean
at gcc dot gnu.org |jakub at gcc dot gnu.org
--- Comment #7 from Jakub Jelinek ---
Created attachment 57847
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57847=edit
gcc14-pr114462.patch
Untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114558
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106472
--- Comment #37 from Jakub Jelinek ---
Created attachment 57836
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57836=edit
gcc14-pr106472.patch
So what about the following (so far untested) patch instead?
For ../configure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113372
Jakub Jelinek changed:
What|Removed |Added
CC||shaohua.li at inf dot ethz.ch
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109925
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111075
--- Comment #5 from Jakub Jelinek ---
Started with r13-6145-gb2287a4d9a640fdc2caef6a067830ea65044deb7
I must say I have no idea what is different from this POV on Darwin vs. Linux.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109925
--- Comment #4 from Jakub Jelinek ---
Doesn't reproduce on the trunk since
r14-4089-gd45ddc2c04e471d0dcee016b6edacc00b8341b16
Doesn't reproduce on 13 branch either, the PR113372 fixed it there.
So, I think we should just add the testcase to the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111075
Jakub Jelinek changed:
What|Removed |Added
Summary|[14 Regression] ICE on |[13/14 Regression] ICE on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111075
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111426
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112303
--- Comment #13 from Jakub Jelinek ---
Created attachment 57821
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57821=edit
gcc14-pr112303.patch
This patch fixes the ICE for me.
Seems we already did something like that in other spots (e.g.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53192
--- Comment #9 from Jakub Jelinek ---
(In reply to Andrew Pinski from comment #7)
> The other option is to change how intrinsics work on x86 and use resolve
> overloads inside the backend like how aarch64, arm and rs6000 backends all
> handle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53192
--- Comment #8 from Jakub Jelinek ---
Looking at other intrinsics with {,unsigned }__int64{, const} * arguments, I
see
void _mm_maskstore_epi64 (__int64* mem_addr, __m128i mask, __m128i a)
void _mm256_maskstore_epi64 (__int64* mem_addr, __m256i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114486
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112303
--- Comment #12 from Jakub Jelinek ---
(In reply to Jakub Jelinek from comment #11)
> (In reply to Richard Biener from comment #10)
> > Looks like so, can you test that? I think !(bb->count >= new_count) is
> > good,
> > we're using this kind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112303
--- Comment #11 from Jakub Jelinek ---
(In reply to Richard Biener from comment #10)
> Looks like so, can you test that? I think !(bb->count >= new_count) is good,
> we're using this kind of compare regularly.
Sure, I'll test that.
|code at -O0 on |code at -O0 on
|x86_64-pc-linux-gnu |x86_64-pc-linux-gnu
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
--- Comment #16 from Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112724
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114462
--- Comment #5 from Jakub Jelinek ---
constexpr bool foo () { return true; }
volatile int v;
void
bar (int x)
{
switch (x)
{
case 0:
while (foo ()) ;
break;
case 1:
while (foo ()) {}
break;
case 2:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114462
--- Comment #4 from Jakub Jelinek ---
Ah, if there is a declaration in the condition, then it is not a valid trivial
empty iteration statement.
Anyway, I'd say cp_fold should for WHILE_STMT, DO_STMT and FOR_STMT if the body
is
a STATEMENT_LIST
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114458
--- Comment #1 from Jakub Jelinek ---
Considering taking this for stage1 as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114456
--- Comment #1 from Jakub Jelinek ---
I'll probably take this for stage1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114415
--- Comment #3 from Jakub Jelinek ---
BTW, with additional -mno-red-zone there is still movement of these insns,
though they
leaq128(%rbx), %rsp ! level 0
movq%r13, %rsi
movl%r10d, %edx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114415
Jakub Jelinek changed:
What|Removed |Added
CC||sayle at gcc dot gnu.org,
at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
Started with r13-1826-g16aafa3194d4851a07cc204f56a5f0618f77e5d7
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
This test fails with
make check-gcc GCC_TEST_RUN_EXPENSIVE=1
RUNTESTFLAGS="dg-torture.exp=bitint-64.c"
FA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114462
--- Comment #3 from Jakub Jelinek ---
And another case to watch for is:
void
qux ()
{
while (const bool b = bar ())
;
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114462
Jakub Jelinek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
See <https://wg21.link/P2809R3>.
DR.
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
See <https://wg21.link/P3034R1>.
DR for C++20 and up.
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
See <https://wg21.link/P3106R1>.
DR for C++98 and up.
++
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
See <https://wg21.link/P2893R3>.
mponent: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
See <https://wg21.link/P2573R2>.
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
See <https://wg21.link/P2795R5>.
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
See <https://wg21.link/P0609R3>.
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
See <https://wg21.link/P2748R5>.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51
--- Comment #14 from Jakub Jelinek ---
(In reply to Jakub Jelinek from comment #12)
> The following testcase at least reproduces the unsigned multiplication
> issue, but doesn't reproduce the signed multiplication nor division by -1.
> int
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736
--- Comment #28 from Jakub Jelinek ---
Created attachment 57807
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57807=edit
gcc14-pr111736-tsan.patch
Untested patch for tsan.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736
--- Comment #27 from Jakub Jelinek ---
I think it should.
E.g. for
int __seg_fs a;
void
foo (int __seg_fs *p)
{
a = *p;
}
the instrumentation is
_5 = __builtin_return_address (0);
__builtin___tsan_func_entry (_5);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114433
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |14.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114425
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114426
--- Comment #9 from Jakub Jelinek ---
Unfortunately the above patch regressed g++.dg/opt/is_constant_evaluated3.C
test.
For constructors, even when they have VOID_TYPE_P, initialized_type actually
returns non-VOID type, so constructors are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51
--- Comment #12 from Jakub Jelinek ---
The following testcase at least reproduces the unsigned multiplication issue,
but doesn't reproduce the signed multiplication nor division by -1.
int
main ()
{
unsigned a = (1U + __INT_MAX__) / 2U;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51
--- Comment #11 from Jakub Jelinek ---
Perhaps
--- fold-const.cc.jj8 2024-03-11 22:37:29.0 +0100
+++ fold-const.cc 2024-03-22 19:31:44.189686120 +0100
@@ -7104,6 +7104,27 @@ extract_muldiv_1 (tree t, tree c, enum t
if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51
--- Comment #10 from Jakub Jelinek ---
It isn't just those 2 values though.
MAX (INT_MIN / 2, 0) * -2 etc. would be a problem too.
So maybe play safe and only do it for MULT_EXPR when TYPE_OVERFLOW_UNDEFINED
and c is non-negative? Maybe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51
--- Comment #9 from Jakub Jelinek ---
(In reply to Jakub Jelinek from comment #8)
> (In reply to Richard Biener from comment #5)
> > but even when overflow is undefined we don't know whether we introduce
> > additional overflow then. Consider
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51
--- Comment #8 from Jakub Jelinek ---
(In reply to Richard Biener from comment #5)
> but even when overflow is undefined we don't know whether we introduce
> additional overflow then. Consider MAX (INT_MIN, 0) * -1 where we compute
> 0 * -1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111655
Jakub Jelinek changed:
What|Removed |Added
Priority|P1 |P2
--- Comment #15 from Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114408
--- Comment #4 from Jakub Jelinek ---
Or the option option would be try if it also ICEs without your patch with
-fsanitize=undefined -fsanitize-trap=undefined -O1 -fanalyzer -flto , then you
could put it into gcc.dg/analyzer/ and just use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114408
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Jakub Jelinek ---
Created attachment 57782
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57782=edit
gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114426
--- Comment #8 from Jakub Jelinek ---
2024-03-22 Jakub Jelinek
PR c++/114426
* cp-gimplify.cc (cp_fold): Don't call maybe_const_value on
CALL_EXPRs to cdtors.
* g++.dg/cpp2a/pr114426.C: New test.
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114426
--- Comment #7 from Jakub Jelinek ---
It is indeed the assert added in that patch.
When cp_fold_function is called on the _ZN12ConfiguratorD0Ev body which
contains
Configurator::~Configurator(this); call
Now, maybe_constant_value is called on
,
|at cp/constexpr.cc:3242)|at cp/constexpr.cc:3242)
||since r14-6507
CC||jakub at gcc dot gnu.org
--- Comment #6 from Jakub Jelinek ---
Started with r14-6507
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114425
--- Comment #6 from Jakub Jelinek ---
Though, guess it would help if evrp avoided undesirable propagation here:
It is changing:
:
# DEBUG BEGIN_STMT
_8 = .ADD_OVERFLOW (d_7(D), 0);
_1 = IMAGPART_EXPR <_8>;
_2 = (_Bool) _1;
#
||2024-03-22
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Status|UNCONFIRMED |ASSIGNED
--- Comment #5 from Jakub Jelinek ---
Created attachment 57779
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57779=edit
gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114425
--- Comment #2 from Jakub Jelinek ---
Strangely it is dependent on the printf loop, without that it works fine.
Slightly adjusted testcase:
#if __BITINT_MAXWIDTH__ >= 2000
_BitInt(8) a;
_BitInt(300) b;
_BitInt(2000) c;
unsigned
foo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683
--- Comment #24 from Jakub Jelinek ---
(In reply to Richard Biener from comment #23)
> It looks like this could go to suitable_reference_p instead?
You mean return false for those making them not suitable at all?
I thought without a write such
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683
Jakub Jelinek changed:
What|Removed |Added
Attachment #57768|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683
--- Comment #21 from Jakub Jelinek ---
Created attachment 57768
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57768=edit
gcc14-pr111683.patch
Updated patch which uses wi::multiple_of_p but doesn't regress pr71083.c.
To be precise, it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114405
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683
--- Comment #20 from Jakub Jelinek ---
That is true. I've been also wondering whether e.g. for the pr71083.c case we
couldn't just look through all COMPONENT_REFs of the DR_REF (and maybe
ARRAY_REFs with constant indexes) and check type size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683
--- Comment #18 from Jakub Jelinek ---
Using wi::multiple_of_p is what I've tried first but that regressed the
generated code for pr71083.c (the test still PASSed, but predcom no longer
triggered on it).
I think it has access size 3 and step 4,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683
--- Comment #17 from Jakub Jelinek ---
Created attachment 57767
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57767=edit
gcc14-pr111683.patch
Patch I've tested overnight for this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93041
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683
Jakub Jelinek changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #68 from Jakub Jelinek ---
(In reply to Jakub Jelinek from comment #67)
> (In reply to Martin Jambor from comment #66)
> > Created attachment 57750 [details]
> > Patch comparing jump functions
> >
> > I'm testing this patch. (Not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114409
--- Comment #11 from Jakub Jelinek ---
Created attachment 57758
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57758=edit
gcc14-pr114409.patch
Ah, I have a fix for the bogus warning, ANNOTATE_EXPR really needs to wrap the
whole condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114409
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114409
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |14.0
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114409
--- Comment #8 from Jakub Jelinek ---
Perhaps better testcase:
template
T
foo (T)
{
static T t;
return 42 - ++t;
}
template
void
bar (T x)
{
#pragma GCC novector
while (T y = foo (x))
;
}
void
baz ()
{
bar (0);
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114409
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
201 - 300 of 42543 matches
Mail list logo
