https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115621
Bug ID: 115621
Summary: internal compiler error: Segmentation fault with
ambiguous operator
Product: gcc
Version: 14.1.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110437
--- Comment #12 from Jan Žižka ---
(In reply to Xi Ruoyao from comment #11)
> is perfectly legal if the caller doesn't pass anything other than 1 or 42 to
> f. So we cannot just reject it at the compile time, we can only issue a
> warning.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110437
--- Comment #10 from Jan Žižka ---
Ah I didn't really complain, this is fine by me and I'm happy we can catch
these. The code
and build configuration, which hit this, was not touched for 20 years :-) so
any help is welcome for us at least.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110437
--- Comment #8 from Jan Žižka ---
Well then I apologize for stealing your time. I did try to search both BZ and
Internet and didn't hit any hints as what is happening and why exactly with gcc
13 if gcc 12 didn't "catch" these. I need to work on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110437
--- Comment #6 from Jan Žižka ---
Thanks ;-) hope this BZ will at least help others if they hit the same thing to
understand the reasoning.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110437
--- Comment #3 from Jan Žižka ---
Good thanks for pointer and clarification.
Is there some reason this cannot be caught during compile time already? I mean
the warning should be an error maybe? It would be much easier to fix in legacy
code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110437
Bug ID: 110437
Summary: SIGILL when return missing in a C++ function with a
condition
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106922
--- Comment #27 from Jan Žižka ---
(In reply to rguent...@suse.de from comment #26)
>
> They are clearly necessary to fix this bug. What I'm unsure yet about
> is the risk of generally enhancing VN for this diagnostic regression.
> The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106922
--- Comment #25 from Jan Žižka ---
I have backported all three patches but true that I didn't try to test without
VN enhancement. Would it help if I'd try that with our production code and the
reproducers? Or anything else I could try so that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106922
--- Comment #22 from Jan Žižka ---
Great, our production code builds just fine with
af611afe5fcc908a6678b5b205fb5af7d64fbcb2 :-) thanks a lot.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106922
--- Comment #18 from Jan Žižka ---
Created attachment 53617
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53617=edit
Third reproducer failing with 9baee6181b4e427e0b5ba417e51424c15858dce7
I did cherry-pick
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106922
--- Comment #12 from Jan Žižka ---
(In reply to Richard Biener from comment #11)
> So there's a similar missed optimization but it's not caused by the bisected
> revision.
Ah I see. I didn't try to bisect this again. I can do that if that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106922
--- Comment #10 from Jan Žižka ---
Created attachment 53581
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53581=edit
Second reproducer failing with 5edf02ed2b6de024f83a023d046a6a18f645bc83
I have cherry-picked the fix on top of gcc 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106922
--- Comment #7 from Jan Žižka ---
> Thanks a lot for opening this bugreport!
You are welcome! :-) Unfortunately I'm not familiar with gcc internals that
much in order to comment on the analysis :-(. But once there will be patch for
this issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106922
Bug ID: 106922
Summary: [12 Regression] Bogus uninitialized warning on
boost::optional<>>
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
15 matches
Mail list logo
