https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950
--- Comment #38 from John Kanapes ---
(In reply to Jakub Jelinek from comment #37)
> User error.
True. But gcc should complain and handle user errors, not crash with SIGILL:(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950
--- Comment #36 from John Kanapes ---
That's great news. Thank you so much:)
I have to ask: How did you come up with avx? You couldn't even reproduce the
problem in your new gccs on newer cpus...
I could live with a little better gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950
--- Comment #35 from John Kanapes ---
Changed all my Makefiles to use -mavx acceleration...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950
--- Comment #34 from John Kanapes ---
You must be right. I checked in the web and found one more reference that says
it has only avx acceleration...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950
--- Comment #32 from John Kanapes ---
AMD FX(tm)-8320 Eight-Core Processor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950
--- Comment #30 from John Kanapes ---
I checked without the -mavx2 option, and it worked with -O3 optimization, even
with gcc 9.4.0:)
It seems that whatever problem is related to that option.
Have you tried it with -mavx2 option in 9.5 and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950
--- Comment #29 from John Kanapes ---
Thx for trying it so fast.
I assume you have downloaded it, and no longer need the link:)
I have no problem with the -mavx2 option.
I have gcc 9.4.0, though. Have you tried it with it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950
--- Comment #27 from John Kanapes ---
Hi,
I have uploaded my sources to
https://www.dropbox.com/s/ao4l5h62h3paujq/test.tgz?dl=0
It is a tar.gzip archive. Expands to a test directory with flat files (10) and
1 Makefile. Main executable is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950
--- Comment #26 from John Kanapes ---
On Tuesday, June 14, 2022 at 06:37:17 PM GMT+3, redi at gcc dot gnu.org
wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950
--- Comment #25 from Jonathan Wakely ---
(In reply to John
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950
--- Comment #23 from John Kanapes ---
Hi,
I have not been able to recreate the issue with simpler programs that use the
same resources. I will need to upload my sources. Is it OK to upload a tar.gz
archive with a test directory with the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950
--- Comment #22 from John Kanapes ---
OK. Removed -lubsan. Added -fsanitize=undefined to linking
Same result as all the other flags.
It took you 4 posts to explain me what to do.
It took me 4 posts to understand what you were talking about.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950
--- Comment #20 from John Kanapes ---
(In reply to Jonathan Wakely from comment #18)
> Two of us have already explained that (comment 3 and comment 6, and now
> comment 17).
I couldn't understand what you were talking about. It is listed with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950
--- Comment #19 from John Kanapes ---
Aaaah. So it's different than the other gcc flags...
I just linked libubsan...
No compilation errors. At runtime it SIGILLS at the same gdb point as before...
Same as the rest of the recommended flags.
BTW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950
--- Comment #16 from John Kanapes ---
Good to know (O3).
I have posted my -fsanitize=undefined.
Doesn't compile with it, but I need help to fix that,because I don't know what
it means:(
On Tuesday, June 14, 2022 at 02:35:05 PM GMT+3, redi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950
--- Comment #14 from John Kanapes ---
(In reply to Jakub Jelinek from comment #12)
> (In reply to John Kanapes from comment #11)
> > (In reply to Richard Biener from comment #9)
> > > Note that GCC 9 is no longer supported. Note one common
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950
--- Comment #13 from John Kanapes ---
(In reply to Jakub Jelinek from comment #12)
> (In reply to John Kanapes from comment #11)
> > (In reply to Richard Biener from comment #9)
>
> > I am trying to recreate this bug in a smaller, more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950
--- Comment #11 from John Kanapes ---
(In reply to Richard Biener from comment #9)
> Note that GCC 9 is no longer supported. Note one common error resulting in
> SIGILL is when you fall through to an unreachable place which could be
> padding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950
--- Comment #8 from John Kanapes ---
True. I was confused that sources were needed only by the GNAT subsystem.
I am working to recreate the issue in a smaller, more portable, easier to
understand code. I hope, I have a couple of days before
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950
--- Comment #5 from John Kanapes ---
Thank you for taking the time to look at it, and responding so fast:)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950
--- Comment #4 from John Kanapes ---
I don't know UBSan. What's more these are not user-friendly, compiler errors.
It reminds me of assemblers:( I need readable errors with line numbers,
otherwise I don't know what to change:(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950
--- Comment #2 from John Kanapes ---
Hi,
The missing info, gcc -v -save-temps is provided as an attachment.
Of the flags, Wextra, -fno-strict-aliasing -fwrapv
-fno-aggressive-loop-optimizations did nothing.
-fsanitize=undefined creates the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950
Bug ID: 105950
Summary: > O2 optimization causes runtime (SIGILL) during main
initialization
Product: gcc
Version: 9.4.0
Status: UNCONFIRMED
Severity: normal
22 matches
Mail list logo
