https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114605
Bug ID: 114605
Summary: [14 Regression] wrong code with -march=z13 -O0 since
r14-5831
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114566
Jakub Jelinek changed:
What|Removed |Added
Summary|[11/12/13/14 Regression]|[11/12/13 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114566
--- Comment #16 from Jakub Jelinek ---
(In reply to Andrew Pinski from comment #15)
> (In reply to Jakub Jelinek from comment #14)
> > Marking for 14 as well because I believe the trunk commit just made it
> > latent there rather than fixed.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
--- Comment #22 from Jakub Jelinek ---
BTW, wonder if it wouldn't be desirable to revert the PR114361 patch until this
is sorted out, or at least limit the effects of that patch to flag_isoc23 and
using multiple types with the same tag and same
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
--- Comment #21 from Jakub Jelinek ---
Why? That is already set by
TYPE_CANONICAL (t) = *e;
else
{
TYPE_CANONICAL (t) = t;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
--- Comment #19 from Jakub Jelinek ---
(In reply to Martin Uecker from comment #18)
> I am just looking at a version that would have changed the condition to:
>
> if (TYPE_MODE (t) == mode && TYPE_REF_CAN_ALIAS_ALL (t) == can_alias_all
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
--- Comment #17 from Jakub Jelinek ---
Some comments:
+ else
+{
+ TYPE_CANONICAL (t) = t;
+}
The formatting here is wrong, TYPE_CANONICAL is indented too much, but we also
don't put a single statement between {}s, so just
else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114566
Jakub Jelinek changed:
What|Removed |Added
CC||avieira at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114566
--- Comment #13 from Jakub Jelinek ---
Ah, vect_analyze_data_refs_alignment -> vect_compute_data_ref_alignment
actually checks for this case
1136 if (max_alignment < vect_align_c
1137 || !vect_can_force_dr_alignment_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114566
--- Comment #12 from Jakub Jelinek ---
The user align:32 MEM_REF comes from
(gdb) p debug (dr_info->dr)
#(Data Ref:
# bb: 21
# stmt: a[j_38][k_41] = _48;
# ref: a[j_38][k_41];
# base_object: a;
# Access function 0: {0, +, 1}_3
# Access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114566
--- Comment #11 from Jakub Jelinek ---
Seems like vectorizer bug to me. The _42 + 128 store is to
MEM [(float *)_42 + 128B];
aka:
unit-size
align:32 warn_if_not_align:0 symtab:0 alias-set 1 canonical-type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114566
--- Comment #10 from Jakub Jelinek ---
Note, the a array which is the object into which the misaligned store happens
has
align:128 so assuming 256-bit alignment into it seems wrong:
(insn 57 56 58 4 (set (reg:V8SF 135 [ vect__33.37 ])
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114566
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P2
Summary|Misaligned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114566
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114572
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=114580
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2024-04-04
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114580
Bug ID: 114580
Summary: Bogus warning on if constexpr
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
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,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114537
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
Summary|[14 regression]
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114533
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114561
Jakub Jelinek changed:
What|Removed |Added
Summary|Comma operator with |[11/12/13/14 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114562
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |11.5
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114552
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
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,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114552
Jakub Jelinek changed:
What|Removed |Added
Summary|[13/14 Regression] wrong|[13/14 Regression] wrong
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114462
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51
Jakub Jelinek changed:
What|Removed |Added
Summary|[12/13/14 Regression] Wrong |[12/13 Regression] Wrong
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,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114415
Jakub Jelinek changed:
What|Removed |Added
Summary|wrong code with -Oz |[13/14 Regression] wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114469
Bug ID: 114469
Summary: gcc.dg/torture/bitint-64.c failure with -O2 -flto
-std=c23 -fwrapv
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114462
Bug ID: 114462
Summary: [C++26] P2809R3 - Trivial infinite loops are not
undefined behavior
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114461
Bug ID: 114461
Summary: [C++26] P3034R1 - Disallow module declarations to be
macros
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114460
Bug ID: 114460
Summary: [C++26] P3106R1 - Clarifying rules for brace elision
in aggregate initialization
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114459
Bug ID: 114459
Summary: [C++26] P2893R3 - Variadic friends
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114458
Bug ID: 114458
Summary: [C++26] P2573R2 - = delete("reason");
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114457
Bug ID: 114457
Summary: [C++26] P2795R5 - Erroneous behavior for uninitialized
reads
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114456
Bug ID: 114456
Summary: [C++26] P0609R3 - Attributes for structured bindings
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114455
Bug ID: 114455
Summary: [C++26] P2748R5 - Disallow binding a returned
reference to a temporary
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114433
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2024-03-22
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114426
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
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;
#
301 - 400 of 10546 matches
Mail list logo
