[Bug c/105950] New: > O2 optimization causes runtime (SIGILL) during main initialization

[Bug c/105950] New: > O2 optimization causes runtime (SIGILL) during main initialization

[jkanapes at yahoo dot com]

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
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jkanapes at yahoo dot com
  Target Milestone: ---

Created attachment 53128
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53128&action=edit
gcc -v -save -temps

Recently upgraded to Ubuntu 20.04, and a program that compiled & ran fine in
Ubuntu 14.04, now coredumps in execution when optimization greater than -O2 is
used during compilation. No warnings in compilation.
When compiled with -O3 -g flags I get gdb output to the offending code
(SIGILL):
size_t channel = 0;
uhd_stream_args_t stream_args =
                      {
                         .cpu_format = "fc32",
                         .otw_format = "sc16",
                         .args = "",
                         .channel_list = &channel,
                         .n_channels = 1
                      };
uhd_stream_atgs_t is defined in the included header:
typedef struct {
    //! Format of host memory
    char* cpu_format;
    //! Over-the-wire format
    char* otw_format;
    //! Other stream args
    char* args;
    //! Array that lists channels
    size_t* channel_list;
    //! Number of channels
    int n_channels;
} uhd_stream_args_t;

The offending code is the next block. This initialization code used to work
fine. It bow works fine with -O2 or less optimization. It compiles fine. Why
does gcc create the wrong executable?

Attaching the gcc -v -save-temps output

[Bug c/105950] > O2 optimization causes runtime (SIGILL) during main initialization

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2022-06-13

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Please provide the missing info requested by https://gcc.gnu.org/bugs and also
try using -fsanitize=undefined and the other flags suggested there.

[Bug c/105950] > O2 optimization causes runtime (SIGILL) during main initialization

[jkanapes at yahoo dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950

--- Comment #2 from John Kanapes <jkanapes at yahoo dot com> ---
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 following output for main:

usr/bin/ld: capture.o: in function `main.cold':
capture.c:(.text.unlikely+0x112): undefined reference to
`__ubsan_handle_load_invalid_value'
/usr/bin/ld: capture.c:(.text.unlikely+0x13a): undefined reference to
`__ubsan_handle_nonnull_arg'
/usr/bin/ld: capture.c:(.text.unlikely+0x16b): undefined reference to
`__ubsan_handle_nonnull_arg'
/usr/bin/ld: capture.c:(.text.unlikely+0x19c): undefined reference to
`__ubsan_handle_nonnull_arg'
/usr/bin/ld: capture.c:(.text.unlikely+0x1cd): undefined reference to
`__ubsan_handle_nonnull_arg'
/usr/bin/ld: capture.c:(.text.unlikely+0x1f6): undefined reference to
`__ubsan_handle_nonnull_arg'
/usr/bin/ld: capture.o:capture.c:(.text.unlikely+0x21f): more undefined
references to `__ubsan_handle_nonnull_arg' follow
/usr/bin/ld: capture.o: in function `main.cold':
capture.c:(.text.unlikely+0x35e): undefined reference to
`__ubsan_handle_load_invalid_value'
/usr/bin/ld: capture.c:(.text.unlikely+0x381): undefined reference to
`__ubsan_handle_load_invalid_value'
/usr/bin/ld: capture.c:(.text.unlikely+0x3a1): undefined reference to
`__ubsan_handle_nonnull_arg'
/usr/bin/ld: capture.c:(.text.unlikely+0x3c1): undefined reference to
`__ubsan_handle_nonnull_arg'
/usr/bin/ld: capture.c:(.text.unlikely+0x3e1): undefined reference to
`__ubsan_handle_nonnull_arg'
/usr/bin/ld: capture.c:(.text.unlikely+0x409): undefined reference to
`__ubsan_handle_load_invalid_value'
/usr/bin/ld: capture.c:(.text.unlikely+0x42a): undefined reference to
`__ubsan_handle_load_invalid_value'
/usr/bin/ld: capture.o: in function `main':
capture.c:(.text.startup+0xa2d): undefined reference to
`__ubsan_handle_pointer_overflow'
/usr/bin/ld: capture.c:(.text.startup+0x1042): undefined reference to
`__ubsan_handle_sub_overflow'
/usr/bin/ld: capture.c:(.text.startup+0x1053): undefined reference to
`__ubsan_handle_out_of_bounds'
/usr/bin/ld: capture.c:(.text.startup+0x1067): undefined reference to
`__ubsan_handle_pointer_overflow'
/usr/bin/ld: capture.c:(.text.startup+0x107e): undefined reference to
`__ubsan_handle_pointer_overflow'
/usr/bin/ld: capture.c:(.text.startup+0x1092): undefined reference to
`__ubsan_handle_type_mismatch_v1'
collect2: error: ld returned 1 exit status

[Bug c/105950] > O2 optimization causes runtime (SIGILL) during main initialization

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
For UBSan, you can't just compile with -fsanitize=undefined, you need to link
with that flag as well.

[Bug c/105950] > O2 optimization causes runtime (SIGILL) during main initialization

[jkanapes at yahoo dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950

--- Comment #4 from John Kanapes <jkanapes at yahoo dot com> ---
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:(

[Bug c/105950] > O2 optimization causes runtime (SIGILL) during main initialization

[jkanapes at yahoo dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950

--- Comment #5 from John Kanapes <jkanapes at yahoo dot com> ---
Thank you for taking the time to look at it, and responding so fast:)

[Bug c/105950] > O2 optimization causes runtime (SIGILL) during main initialization

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950

--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Line numbers in the source code aren't relevant here, you need to add the
-fsanitize=undefined flag to your link command to solve those undefined
references.

[Bug c/105950] > O2 optimization causes runtime (SIGILL) during main initialization

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950

--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to John Kanapes from comment #2)
> The missing info, gcc -v -save-temps is provided as an attachment.

But we're still missing the code that triggers the bug.

A bug report that just says something goes wrong will be closed. We need the
code to figure out what goes wrong and fix it.

[Bug c/105950] > O2 optimization causes runtime (SIGILL) during main initialization

[jkanapes at yahoo dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950

--- Comment #8 from John Kanapes <jkanapes at yahoo dot com> ---
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 closing this ticket:)

[Bug c/105950] > O2 optimization causes runtime (SIGILL) during main initialization

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
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
(like when there's a missing return in a function).

[Bug c/105950] > O2 optimization causes runtime (SIGILL) during main initialization

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950

--- Comment #10 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to John Kanapes from comment #8)
> I hope, I have a couple of days before closing this ticket:)

Yes, we usually let a bug sit in WAITING status for a couple of months before
closing it, so you have plenty of time.

[Bug c/105950] > O2 optimization causes runtime (SIGILL) during main initialization

[jkanapes at yahoo dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950

--- Comment #11 from John Kanapes <jkanapes at yahoo dot com> ---
(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
> (like when there's a missing return in a function).

Hmmm.
gcc 9.40 is the distro gcc for Ubuntu 20.04, which is LTS and still supported.
Does this mean that no action will be taken upon resolving this ticket?
I am trying to recreate this bug in a smaller, more concise context.
It is not an obvious bug. This is valid code, and it takes a large chain of
previous steps to get it wrong at runtime. It used to work with previous gccs,
but it now seems broken:(
It will remain broken in future releases unless we stop it here:(
I hope you reconsider:)
If that was a problem of a missing return in a function, it would have to be an
internal function. The spot it happens is in main initialization, before it had
a chance to call any of my functions.

[Bug c/105950] > O2 optimization causes runtime (SIGILL) during main initialization

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(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 error resulting in
> > SIGILL is when you fall through to an unreachable place which could be
> > padding
> > (like when there's a missing return in a function).
> 
> Hmmm.
> gcc 9.40 is the distro gcc for Ubuntu 20.04, which is LTS and still
> supported.

In this case it is Ubuntu that supports it, so you'd need to ask Ubuntu to fix
it
(if it is a compiler bug of course), because upstream GCC 9.5 was the last
release and there won't be any changes for the GCC 9 series.  If it reproduces
with a newer compiler, it can be fixed upstream in the still supported releases
and perhaps Ubuntu could backport it if you ask them to.

> Does this mean that no action will be taken upon resolving this ticket?

Depends on if it is reproducible with a supported compiler.

> I am trying to recreate this bug in a smaller, more concise context.
> It is not an obvious bug. This is valid code, and it takes a large chain of
> previous steps to get it wrong at runtime. It used to work with previous
> gccs, but it now seems broken:(

Claiming it is valid code until it is analyzed is premature.  It can very well
be undefined behavior in the code.

[Bug c/105950] > O2 optimization causes runtime (SIGILL) during main initialization

[jkanapes at yahoo dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950

--- Comment #13 from John Kanapes <jkanapes at yahoo dot com> ---
(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 concise context.
> > It is not an obvious bug. This is valid code, and it takes a large chain of
> > previous steps to get it wrong at runtime. It used to work with previous
> > gccs, but it now seems broken:(
> 
> Claiming it is valid code until it is analyzed is premature.  It can very
> well be undefined behavior in the code.

True. Except that I have already analyzed it with my own tools. That means that
the offending code, as reported by gdb, compiles and runs fine with -O6
optimization with a simpler code. I am not claiming anything, just stressing
that this is not an obvious issue as reported by gdb, and requires a lot of
previous steps to reproduce:(

[Bug c/105950] > O2 optimization causes runtime (SIGILL) during main initialization

[jkanapes at yahoo dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950

--- Comment #14 from John Kanapes <jkanapes at yahoo dot com> ---
(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 error resulting in
> > > SIGILL is when you fall through to an unreachable place which could be
> > > padding
> > > (like when there's a missing return in a function).
> > 
> > Hmmm.
> > gcc 9.40 is the distro gcc for Ubuntu 20.04, which is LTS and still
> > supported.
> 
> In this case it is Ubuntu that supports it, so you'd need to ask Ubuntu to
> fix it
> (if it is a compiler bug of course), because upstream GCC 9.5 was the last
> release and there won't be any changes for the GCC 9 series.  If it
> reproduces with a newer compiler, it can be fixed upstream in the still
> supported releases and perhaps Ubuntu could backport it if you ask them to.
> 
> > Does this mean that no action will be taken upon resolving this ticket?
> 
> Depends on if it is reproducible with a supported compiler.

That works for me. Both places could use my sources. My work won't be in vain:)

[Bug c/105950] > O2 optimization causes runtime (SIGILL) during main initialization

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950

--- Comment #15 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Just running in GDB doesn't find bugs (and there is no -O6 level, -O3 is the
highest).

Did you try it with -fsanitize=undefined yet?

[Bug c/105950] > O2 optimization causes runtime (SIGILL) during main initialization

[jkanapes at yahoo dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950

--- Comment #16 from John Kanapes <jkanapes at yahoo dot com> ---
 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 at gcc dot gnu.org
<gcc-bugzilla@gcc.gnu.org> wrote:  

 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950

--- Comment #15 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Just running in GDB doesn't find bugs (and there is no -O6 level, -O3 is the
highest).

Did you try it with -fsanitize=undefined yet?

[Bug c/105950] > O2 optimization causes runtime (SIGILL) during main initialization

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950

--- Comment #17 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
If you mean https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950#c2 , no, you
have just posted what is a user error in using the sanitizers and we've told
you how to fix that.  The -fsanitize=undefined option can't be just added to
gcc command line where you compile object files (e.g. if you add it to CFLAGS
or CXXFLAGS vars), but also when you link the program (or shared library), so
e.g. in LDFLAGS, because when linking it takes care of adding -lubsan to the
linker command line.

[Bug c/105950] > O2 optimization causes runtime (SIGILL) during main initialization

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950

--- Comment #18 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Two of us have already explained that (comment 3 and comment 6, and now comment
17).

[Bug c/105950] > O2 optimization causes runtime (SIGILL) during main initialization

[jkanapes at yahoo dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950

--- Comment #19 from John Kanapes <jkanapes at yahoo dot com> ---
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 since -O3 is the highest gcc optimization, gcc could print a warning:
Warning -Ox is deprecated. Downgrading to -O3;-)
Otherwise in a few years you will find code compiled with -O20 and then it is
the sky. It just takes 1 coder to use it in open source, and since gcc seems to
take it, all the other coders will copy it:(

[Bug c/105950] > O2 optimization causes runtime (SIGILL) during main initialization

[jkanapes at yahoo dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950

--- Comment #20 from John Kanapes <jkanapes at yahoo dot com> ---
(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 the other
-f gcc flags:( To avoid confusion, you could update your in your description
that this flag is special and needs to be linked with -lubsan and does that...

[Bug c/105950] > O2 optimization causes runtime (SIGILL) during main initialization

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950

--- Comment #21 from Jonathan Wakely <redi at gcc dot gnu.org> ---
What we said is to use -fsanitize=undefined when linking, not add -lubsan
manually. I don't know how I could have said that more clearly than comment 6.

This is not different to other flags, there are plenty of other flags that are
needed both when compiling and linking.

[Bug c/105950] > O2 optimization causes runtime (SIGILL) during main initialization

[jkanapes at yahoo dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950

--- Comment #22 from John Kanapes <jkanapes at yahoo dot com> ---
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.
You should explain better.

[Bug c/105950] > O2 optimization causes runtime (SIGILL) during main initialization

[jkanapes at yahoo dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950

--- Comment #23 from John Kanapes <jkanapes at yahoo dot com> ---
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 sources and a makefile? What do you do
with the sources after the ticket?

TIA

[Bug c/105950] > O2 optimization causes runtime (SIGILL) during main initialization

[sam at gentoo dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950

Sam James <sam at gentoo dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sam at gentoo dot org

--- Comment #24 from Sam James <sam at gentoo dot org> ---
Please be polite on these bugs. There's a lot of documentation online about how
to use UBsan.

It's not ideal to upload a tarball with all of the bits, but if it's what's
needed, then I guess so be it. Some build systems make it easier to enable
sanitizers like Meson.

GCC's bug tracker isn't for general support on how to use build systems and
flags. 

The bug tracker is public and I don't think one can delete their own
attachments.

Are you saying that when you use -fsanitize=undefined and run your program, it
gets SIGILL'd?

[Bug c/105950] > O2 optimization causes runtime (SIGILL) during main initialization

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950

--- Comment #25 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to John Kanapes from comment #22)
> It took you 4 posts to explain me what to do.
> It took me 4 posts to understand what you were talking about.
> You should explain better.

You should read better. Comment 3 is perfectly clear.

"For UBSan, you can't just compile with -fsanitize=undefined, you need to link
with that flag as well."


(In reply to John Kanapes from comment #23)
> What do you do with the sources after the ticket?

They will stay attached here. If you don't want them to be public, you need to
reduce it to something smaller that still shows the bug (which you've said you
can't) or put them somewhere online and persuade somebody here to download them
and try to reproduce and reduce it for you.

[Bug c/105950] > O2 optimization causes runtime (SIGILL) during main initialization

[jkanapes at yahoo dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950

--- Comment #26 from John Kanapes <jkanapes at yahoo dot com> ---
    On Tuesday, June 14, 2022 at 06:37:17 PM GMT+3, redi at gcc dot gnu.org
<gcc-bugzilla@gcc.gnu.org> wrote:  

 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950

--- Comment #25 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to John Kanapes from comment #22)
>> It took you 4 posts to explain me what to do.
>> It took me 4 posts to understand what you were talking about.
>> You should explain better.

>You should read better. Comment 3 is perfectly clear.

>"For UBSan, you can't just compile with -fsanitize=undefined, you need to link
> with that flag as well."

> That 

I am sorry, that's not at all clear to me. It tells me that I first need to
compile with fsanitized and then link with it.Since i couldn't even compile
with it, due to the undefined references to ubsan_handles, how could I link?
I tried to link against the -lubsan library, just to get past compilation, and
you told me that this was wrong.Finally I ended up just linking with that flag.
You have to bear in mind, that us programmers do not uselinker flags and do not
know about them:(

How could I explain it bettter?
"fsanitized=undefined is a linker flag. Example: gcc test.o example.o ${LIBS}
fsanitized=undefined -o test"

(In reply to John Kanapes from comment #23)
>> What do you do with the sources after the ticket?

>They will stay attached here. If you don't want them to be public, you need to
>reduce it to something smaller that still shows the bug (which you've said you
>can't) or put them somewhere online and persuade somebody here to download them
>and try to reproduce and reduce it for you.
That is extra work for you. I wasn;t able to do it, and I know the code. 
But if you can do smt about it when you find the bug, I would be grateful.I
will upload it to my dropbox account and then send you the link.
TIAJohn

[Bug c/105950] > O2 optimization causes runtime (SIGILL) during main initialization

[jkanapes at yahoo dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950

--- Comment #27 from John Kanapes <jkanapes at yahoo dot com> ---
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 capture.

In Ubuntu 20.04 you will also need to install:
sudo apt-get install flex
sudo apt-get install libuhd3.15
sudo apt-get install libuhd-dev

uhd is the ettus driver for their usrp radio. You don't need the radio for the
test.

Makefile provides 3 targets: (exec), db, clean
exec: make without arguments will build capture with -O3 to test bug
db: builds capture with gdb flags and without any optimizations
clean: cleans all intermediate files and executables

Problem reproduction: capture -h
Expected response: SIGILL core if built with (exec)
                   Syntax and arguments if built with debug

Plz let me  know when you have downloaded it, so that I can block the shared
link. I can help with all installation and problem reproduction.
I will appreciate it, if you can reduce the code before publishing it to a
smaller part that can trigger the problem.

Gl
John

[Bug c/105950] > O2 optimization causes runtime (SIGILL) during main initialization

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950

--- Comment #28 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Can't reproduce, neither with gcc 9.5 nor gcc 12.1.  You are using -mavx2, are
you sure you have AVX2 ISA on the box you're running it?

[Bug c/105950] > O2 optimization causes runtime (SIGILL) during main initialization

[jkanapes at yahoo dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950

--- Comment #29 from John Kanapes <jkanapes at yahoo dot com> ---
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?

[Bug c/105950] > O2 optimization causes runtime (SIGILL) during main initialization

[jkanapes at yahoo dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950

--- Comment #30 from John Kanapes <jkanapes at yahoo dot com> ---
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 12.1?

[Bug c/105950] > O2 optimization causes runtime (SIGILL) during main initialization

[sam at gentoo dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950

--- Comment #31 from Sam James <sam at gentoo dot org> ---
What CPU do you have?

[Bug c/105950] > O2 optimization causes runtime (SIGILL) during main initialization

[jkanapes at yahoo dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950

--- Comment #32 from John Kanapes <jkanapes at yahoo dot com> ---
 AMD FX(tm)-8320 Eight-Core Processor

[Bug c/105950] > O2 optimization causes runtime (SIGILL) during main initialization

[sam at gentoo dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950

--- Comment #33 from Sam James <sam at gentoo dot org> ---
As far as I can tell, that CPU might have AVX, but not AVX2.

[Bug c/105950] > O2 optimization causes runtime (SIGILL) during main initialization

[jkanapes at yahoo dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950

--- Comment #34 from John Kanapes <jkanapes at yahoo dot com> ---
You must be right. I checked in the web and found one more reference that says
it has only avx acceleration...

[Bug c/105950] > O2 optimization causes runtime (SIGILL) during main initialization

[jkanapes at yahoo dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950

--- Comment #35 from John Kanapes <jkanapes at yahoo dot com> ---
Changed all my Makefiles to use -mavx acceleration...

[Bug c/105950] > O2 optimization causes runtime (SIGILL) during main initialization

[jkanapes at yahoo dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950

--- Comment #36 from John Kanapes <jkanapes at yahoo dot com> ---
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 reporting (no SIGILL), but I am very
happy with this. Do you need anything more from me?

[Bug c/105950] > O2 optimization causes runtime (SIGILL) during main initialization

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|---                         |INVALID

--- Comment #37 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
User error.

[Bug c/105950] > O2 optimization causes runtime (SIGILL) during main initialization

[jkanapes at yahoo dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950

--- Comment #38 from John Kanapes <jkanapes at yahoo dot com> ---
(In reply to Jakub Jelinek from comment #37)
> User error.

True. But gcc should complain and handle user errors, not crash with SIGILL:(

[Bug c/105950] > O2 optimization causes runtime (SIGILL) during main initialization

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950

--- Comment #39 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC didn't crash with SIGILL.  GCC was asked to compile a program with AVX2
instruction set, it has done that.  When such a program is run on a hardware
that doesn't support some of its instructions, it is termined by the SIGILL
signal by the kernel, as hardware raises an exception that there is unknown
instruction.  What do you expect could GCC done about that?