https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568
Andrew Pinski changed:
What|Removed |Added
See Also|https://gcc.gnu.org/bugzill |https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568
--- Comment #23 from Andrew Pinski ---
This might be a divirtualization issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568
--- Comment #22 from Jonathan Wakely ---
Created attachment 57344
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57344=edit
Gzipped preprocessed source
With -O2 -fsantiize=unreachable this prints an error:
pubkey.h:2209:32: runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568
--- Comment #21 from Richard Biener ---
Try -fsanitize=unreachable - when reordering BBs makes crashes appear/disappear
the most likely culprit is we run into a path deemed unreachable which means we
fall through to random code.
You can also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568
--- Comment #20 from Jeffrey Walton ---
Hi Andrew.
I went through the list of options that are enabled at -O2 from [1]. I built
the library with each option separately at "-DNDEBUG -g2 -O2 -fno-xxx".
Here is the list of suspects. I seem to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568
--- Comment #19 from Jeffrey Walton ---
Created attachment 53427
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53427=edit
Test script to build library at -O2 with -fno-xxx
Test script to build library at -O2 with -fno-xxx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568
--- Comment #18 from Jeffrey Walton ---
(In reply to Andrew Pinski from comment #17)
> The other thing to try is -fstack-reuse=none.
No joy with -fstack-reuse=none. The crash is still present.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568
--- Comment #17 from Andrew Pinski ---
The other thing to try is -fstack-reuse=none.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568
--- Comment #16 from Andrew Pinski ---
(In reply to Jeffrey Walton from comment #15)
> It looks like -fno-strict-aliasing cleared the crash. This is bad because I
> thought we did not violate aliasing rules.
>
> Let me try to find it.
Well
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568
--- Comment #15 from Jeffrey Walton ---
It looks like -fno-strict-aliasing cleared the crash. This is bad because I
thought we did not violate aliasing rules.
Let me try to find it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568
--- Comment #14 from Jeffrey Walton ---
(In reply to Jeffrey Walton from comment #13)
> (In reply to Andrew Pinski from comment #12)
> > Can you try -fno-reorder-blocks-and-partition adding to the options?
> > This would not be the first time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568
--- Comment #13 from Jeffrey Walton ---
(In reply to Andrew Pinski from comment #12)
> Can you try -fno-reorder-blocks-and-partition adding to the options?
> This would not be the first time this option caused issues with EH.
No joy with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568
--- Comment #12 from Andrew Pinski ---
Can you try -fno-reorder-blocks-and-partition adding to the options?
This would not be the first time this option caused issues with EH.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568
--- Comment #11 from Andrew Pinski ---
(In reply to Jeffrey Walton from comment #9)
> (In reply to Andrew Pinski from comment #8)
> > (In reply to Jeffrey Walton from comment #7)
> >
> > Try putting a breakpoint on the following functions:
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568
--- Comment #10 from Jeffrey Walton ---
I'm not sure if this is helpful, but Valgrind is showing invalid reads in the
unwind gear:
$ valgrind ./cryptest.exe vv 51
==27339== Memcheck, a memory error detector
==27339== Copyright (C) 2002-2022,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568
--- Comment #9 from Jeffrey Walton ---
(In reply to Andrew Pinski from comment #8)
> (In reply to Jeffrey Walton from comment #7)
>
> Try putting a breakpoint on the following functions:
> _Unwind_RaiseException
> _Unwind_ForcedUnwind
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568
--- Comment #8 from Andrew Pinski ---
(In reply to Jeffrey Walton from comment #7)
>
> Thanks again Andrew.
>
> We have exception handlers for both CryptoPP::Exception& and std::exception&
> starting for main() around
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568
--- Comment #7 from Jeffrey Walton ---
(In reply to Andrew Pinski from comment #6)
> >And the program does not take the exception path. Instead it segfaults.
>
> If I read the backtrace correctly, it is trying to resume an unwind because
> it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568
--- Comment #6 from Andrew Pinski ---
>And the program does not take the exception path. Instead it segfaults.
If I read the backtrace correctly, it is trying to resume an unwind because it
didn't find a catch that would hit in main but the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568
--- Comment #5 from Jeffrey Walton ---
(In reply to Andrew Pinski from comment #3)
> Though there might be an EH issue but there has not been an EH issue for a
> long time .
This is an interesting observation.
The stack trace shows frame #0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568
--- Comment #4 from Andrew Pinski ---
If there is a throw which is not being caught (correctly).
In gdb you can do:
catch throw
And then find where the throw was that is causing the issue (as this is an
_Unwind_Resume case).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568
Andrew Pinski changed:
What|Removed |Added
Component|middle-end |rtl-optimization
Keywords|
22 matches
Mail list logo
