* [Bug c/115345] [12/13/14 REGRESSION] / Different outputs compared to GCC 11- and MSVC/Clang
2024-06-04 14:32 [Bug c/115345] New: [12/13/14 REGRESSION] / Different outputs compared to GCC 11- and MSVC/Clang djordje.baljozovic at ac dot rwth-aachen.de
@ 2024-06-04 14:39 ` djordje.baljozovic at ac dot rwth-aachen.de
2024-06-04 14:44 ` djordje.baljozovic at ac dot rwth-aachen.de
` (14 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: djordje.baljozovic at ac dot rwth-aachen.de @ 2024-06-04 14:39 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115345
Djordje Baljozovic <djordje.baljozovic at ac dot rwth-aachen.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
URL| |https://github.com/IUPAC-In
| |ChI/InChI
--- Comment #1 from Djordje Baljozovic <djordje.baljozovic at ac dot rwth-aachen.de> ---
I am attaching an example of the differences in gcc_crash_report.txt for the
input file sid_453841144.sdf in a separate attachment.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug c/115345] [12/13/14 REGRESSION] / Different outputs compared to GCC 11- and MSVC/Clang
2024-06-04 14:32 [Bug c/115345] New: [12/13/14 REGRESSION] / Different outputs compared to GCC 11- and MSVC/Clang djordje.baljozovic at ac dot rwth-aachen.de
2024-06-04 14:39 ` [Bug c/115345] " djordje.baljozovic at ac dot rwth-aachen.de
@ 2024-06-04 14:44 ` djordje.baljozovic at ac dot rwth-aachen.de
2024-06-04 14:49 ` djordje.baljozovic at ac dot rwth-aachen.de
` (13 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: djordje.baljozovic at ac dot rwth-aachen.de @ 2024-06-04 14:44 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115345
--- Comment #2 from Djordje Baljozovic <djordje.baljozovic at ac dot rwth-aachen.de> ---
Created attachment 58345
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58345&action=edit
Example of differences in output
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug c/115345] [12/13/14 REGRESSION] / Different outputs compared to GCC 11- and MSVC/Clang
2024-06-04 14:32 [Bug c/115345] New: [12/13/14 REGRESSION] / Different outputs compared to GCC 11- and MSVC/Clang djordje.baljozovic at ac dot rwth-aachen.de
2024-06-04 14:39 ` [Bug c/115345] " djordje.baljozovic at ac dot rwth-aachen.de
2024-06-04 14:44 ` djordje.baljozovic at ac dot rwth-aachen.de
@ 2024-06-04 14:49 ` djordje.baljozovic at ac dot rwth-aachen.de
2024-06-04 14:51 ` djordje.baljozovic at ac dot rwth-aachen.de
` (12 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: djordje.baljozovic at ac dot rwth-aachen.de @ 2024-06-04 14:49 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115345
--- Comment #3 from Djordje Baljozovic <djordje.baljozovic at ac dot rwth-aachen.de> ---
(In reply to Djordje Baljozovic from comment #1)
> I am attaching an example of the differences in gcc_crash_report.txt for the
> input file sid_453841144.sdf in a separate attachment.
See attachment below.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug c/115345] [12/13/14 REGRESSION] / Different outputs compared to GCC 11- and MSVC/Clang
2024-06-04 14:32 [Bug c/115345] New: [12/13/14 REGRESSION] / Different outputs compared to GCC 11- and MSVC/Clang djordje.baljozovic at ac dot rwth-aachen.de
` (2 preceding siblings ...)
2024-06-04 14:49 ` djordje.baljozovic at ac dot rwth-aachen.de
@ 2024-06-04 14:51 ` djordje.baljozovic at ac dot rwth-aachen.de
2024-06-04 15:10 ` [Bug c/115345] [12/13/14/15 Regression] " jakub at gcc dot gnu.org
` (11 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: djordje.baljozovic at ac dot rwth-aachen.de @ 2024-06-04 14:51 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115345
--- Comment #4 from Djordje Baljozovic <djordje.baljozovic at ac dot rwth-aachen.de> ---
(In reply to Djordje Baljozovic from comment #3)
> (In reply to Djordje Baljozovic from comment #1)
> > I am attaching an example of the differences in gcc_crash_report.txt for the
> > input file sid_453841144.sdf in a separate attachment.
>
> See attachment below.
Now it's above :) .
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug c/115345] [12/13/14/15 Regression] Different outputs compared to GCC 11- and MSVC/Clang
2024-06-04 14:32 [Bug c/115345] New: [12/13/14 REGRESSION] / Different outputs compared to GCC 11- and MSVC/Clang djordje.baljozovic at ac dot rwth-aachen.de
` (3 preceding siblings ...)
2024-06-04 14:51 ` djordje.baljozovic at ac dot rwth-aachen.de
@ 2024-06-04 15:10 ` jakub at gcc dot gnu.org
2024-06-04 16:33 ` [Bug middle-end/115345] " djordje.baljozovic at ac dot rwth-aachen.de
` (10 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: jakub at gcc dot gnu.org @ 2024-06-04 15:10 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115345
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Last reconfirmed| |2024-06-04
Summary|[12/13/14 REGRESSION] / |[12/13/14/15 Regression]
|Different outputs compared |Different outputs compared
|to GCC 11- and MSVC/Clang |to GCC 11- and MSVC/Clang
Status|UNCONFIRMED |WAITING
CC| |jakub at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Please see https://gcc.gnu.org/bugs/ for what we need, we need a self-contained
preprocessed testcase, which you haven't provided.
You should start by compiling the code with -fsanitize=undefined and/or
-fsanitize=address, see if it reports anything, if not, create a minimal
self-contained reproducer.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug middle-end/115345] [12/13/14/15 Regression] Different outputs compared to GCC 11- and MSVC/Clang
2024-06-04 14:32 [Bug c/115345] New: [12/13/14 REGRESSION] / Different outputs compared to GCC 11- and MSVC/Clang djordje.baljozovic at ac dot rwth-aachen.de
` (4 preceding siblings ...)
2024-06-04 15:10 ` [Bug c/115345] [12/13/14/15 Regression] " jakub at gcc dot gnu.org
@ 2024-06-04 16:33 ` djordje.baljozovic at ac dot rwth-aachen.de
2024-06-04 16:48 ` pinskia at gcc dot gnu.org
` (9 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: djordje.baljozovic at ac dot rwth-aachen.de @ 2024-06-04 16:33 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115345
--- Comment #6 from Djordje Baljozovic <djordje.baljozovic at ac dot rwth-aachen.de> ---
(In reply to Jakub Jelinek from comment #5)
> Please see https://gcc.gnu.org/bugs/ for what we need, we need a
> self-contained preprocessed testcase, which you haven't provided.
> You should start by compiling the code with -fsanitize=undefined and/or
> -fsanitize=address, see if it reports anything, if not, create a minimal
> self-contained reproducer.
Hi,
You are pointing me to use fuzzer for our code, which is already done by
Google's oss-fuzz project.
No issue in the code has been detected in the part of the code I sent.
Also, the code itself is not an issue -- it is the GCC executables generated
from the very same code that make all the differences, i.e. if the project/code
is compiled with GCC 12-14 on one side and GCC 0-11, MSVC (all versions) and
Clang (all versions) on the other.
Since the code base is rather big, and all functions are intertwined, the only
thing I can do is:
1. attach EXE/ELF files and one of the input files which causes the problem
2. create two Docker containers -- one with GCC 11 and one with GCC 12/13/14.
3. I can send you instructions how to compile one part of the project from our
GitHub repo.
As mentioned in my initial post, gdb crash report is given in the attachment
https://gcc.gnu.org/bugzilla/attachment.cgi?id=58344 .
Hope this helps.
Sincerely,
George
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug middle-end/115345] [12/13/14/15 Regression] Different outputs compared to GCC 11- and MSVC/Clang
2024-06-04 14:32 [Bug c/115345] New: [12/13/14 REGRESSION] / Different outputs compared to GCC 11- and MSVC/Clang djordje.baljozovic at ac dot rwth-aachen.de
` (5 preceding siblings ...)
2024-06-04 16:33 ` [Bug middle-end/115345] " djordje.baljozovic at ac dot rwth-aachen.de
@ 2024-06-04 16:48 ` pinskia at gcc dot gnu.org
2024-06-04 16:58 ` jakub at gcc dot gnu.org
` (8 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: pinskia at gcc dot gnu.org @ 2024-06-04 16:48 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115345
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |wrong-code
--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
A few questions, does `-fsanitize=undefined -fsanitize=address` report
anything? Does it work at -O0 and not just -O3? Does adding
-fno-strict-aliasing to the command line "fix" the crash? Are there any
warnings with `-Wextra -Wall` that might be causing an issue?
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug middle-end/115345] [12/13/14/15 Regression] Different outputs compared to GCC 11- and MSVC/Clang
2024-06-04 14:32 [Bug c/115345] New: [12/13/14 REGRESSION] / Different outputs compared to GCC 11- and MSVC/Clang djordje.baljozovic at ac dot rwth-aachen.de
` (6 preceding siblings ...)
2024-06-04 16:48 ` pinskia at gcc dot gnu.org
@ 2024-06-04 16:58 ` jakub at gcc dot gnu.org
2024-06-04 17:03 ` djordje.baljozovic at ac dot rwth-aachen.de
` (7 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: jakub at gcc dot gnu.org @ 2024-06-04 16:58 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115345
--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Also, if building with GCC 11 works and with GCC 12 doesn't, can you build two
trees, one with either compiler and then bisect first among the shared
libraries or binaries (find out which shared library or binary is affected),
among the static libraries (GCC 11 and 12 ought to be ABI compatible, so try
linking some *.a libraries from one build and other from another build, among
the object files (start with linking half of the objects built by one compiler
and another half by another compiler and depending on if it works as expected
or not change the set of objects to link).
If you get to one object file which when compiled with GCC 11 works even when
everything else has been compiled with GCC 12 or vice versa, you can then try
different options on that one (e.g. the -fno-strict-aliasing Andrew mentioned,
-O0 etc.), and/or
bisect inside of the source using #pragma GCC optimize(0) etc.
Anyway, if there is a single translation unit like that and ideally if you find
out which function is problematic, trying to stub functions it calls and add a
caller which calls that single function with the right arguments turns it into
a self-contained reproducer.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug middle-end/115345] [12/13/14/15 Regression] Different outputs compared to GCC 11- and MSVC/Clang
2024-06-04 14:32 [Bug c/115345] New: [12/13/14 REGRESSION] / Different outputs compared to GCC 11- and MSVC/Clang djordje.baljozovic at ac dot rwth-aachen.de
` (7 preceding siblings ...)
2024-06-04 16:58 ` jakub at gcc dot gnu.org
@ 2024-06-04 17:03 ` djordje.baljozovic at ac dot rwth-aachen.de
2024-06-04 17:11 ` djordje.baljozovic at ac dot rwth-aachen.de
` (6 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: djordje.baljozovic at ac dot rwth-aachen.de @ 2024-06-04 17:03 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115345
--- Comment #9 from Djordje Baljozovic <djordje.baljozovic at ac dot rwth-aachen.de> ---
(In reply to Andrew Pinski from comment #7)
> A few questions, does `-fsanitize=undefined -fsanitize=address` report
> anything? Does it work at -O0 and not just -O3? Does adding
> -fno-strict-aliasing to the command line "fix" the crash? Are there any
> warnings with `-Wextra -Wall` that might be causing an issue?
Have not tested -O0 and -fno-strict-aliasing; will let you know if this fixed
the problem.
No warnings with -Wextra -Wall to my knowledge.
Sincerely,
George
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug middle-end/115345] [12/13/14/15 Regression] Different outputs compared to GCC 11- and MSVC/Clang
2024-06-04 14:32 [Bug c/115345] New: [12/13/14 REGRESSION] / Different outputs compared to GCC 11- and MSVC/Clang djordje.baljozovic at ac dot rwth-aachen.de
` (8 preceding siblings ...)
2024-06-04 17:03 ` djordje.baljozovic at ac dot rwth-aachen.de
@ 2024-06-04 17:11 ` djordje.baljozovic at ac dot rwth-aachen.de
2024-06-04 18:43 ` djordje.baljozovic at ac dot rwth-aachen.de
` (5 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: djordje.baljozovic at ac dot rwth-aachen.de @ 2024-06-04 17:11 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115345
--- Comment #10 from Djordje Baljozovic <djordje.baljozovic at ac dot rwth-aachen.de> ---
(In reply to Jakub Jelinek from comment #8)
> Also, if building with GCC 11 works and with GCC 12 doesn't, can you build
> two trees, one with either compiler and then bisect first among the shared
> libraries or binaries (find out which shared library or binary is affected),
> among the static libraries (GCC 11 and 12 ought to be ABI compatible, so try
> linking some *.a libraries from one build and other from another build,
> among the object files (start with linking half of the objects built by one
> compiler and another half by another compiler and depending on if it works
> as expected or not change the set of objects to link).
> If you get to one object file which when compiled with GCC 11 works even
> when everything else has been compiled with GCC 12 or vice versa, you can
> then try different options on that one (e.g. the -fno-strict-aliasing Andrew
> mentioned, -O0 etc.), and/or
> bisect inside of the source using #pragma GCC optimize(0) etc.
> Anyway, if there is a single translation unit like that and ideally if you
> find out which function is problematic, trying to stub functions it calls
> and add a caller which calls that single function with the right arguments
> turns it into a self-contained reproducer.
Good idea(s). Let me try all Andrew's options firstly, and get back to you.
Thanks,
George
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug middle-end/115345] [12/13/14/15 Regression] Different outputs compared to GCC 11- and MSVC/Clang
2024-06-04 14:32 [Bug c/115345] New: [12/13/14 REGRESSION] / Different outputs compared to GCC 11- and MSVC/Clang djordje.baljozovic at ac dot rwth-aachen.de
` (9 preceding siblings ...)
2024-06-04 17:11 ` djordje.baljozovic at ac dot rwth-aachen.de
@ 2024-06-04 18:43 ` djordje.baljozovic at ac dot rwth-aachen.de
2024-06-05 6:59 ` rguenth at gcc dot gnu.org
` (4 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: djordje.baljozovic at ac dot rwth-aachen.de @ 2024-06-04 18:43 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115345
--- Comment #11 from Djordje Baljozovic <djordje.baljozovic at ac dot rwth-aachen.de> ---
(In reply to Djordje Baljozovic from comment #9)
> (In reply to Andrew Pinski from comment #7)
> > A few questions, does `-fsanitize=undefined -fsanitize=address` report
> > anything? Does it work at -O0 and not just -O3? Does adding
> > -fno-strict-aliasing to the command line "fix" the crash? Are there any
> > warnings with `-Wextra -Wall` that might be causing an issue?
>
> Have not tested -O0 and -fno-strict-aliasing; will let you know if this
> fixed the problem.
> No warnings with -Wextra -Wall to my knowledge.
>
> Sincerely,
> George
Hi Andrew and Jakub,
The results are more than interesting:
1. -fno-strict-aliasing: none of the inputs processed (with O3)
2. O0: all but one input processed
3. O3: none of the inputs processed
4. O1 and O2: all inputs processed without any issues -- this did it.
Now the question is: how on Earth did O1/O2 do the trick, and not O0?!
Once again, thanks a lot for your detailed and quick responses.
George
P.S. I will keep @Jakub's bisect idea in mind if something like this happens in
the future.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug middle-end/115345] [12/13/14/15 Regression] Different outputs compared to GCC 11- and MSVC/Clang
2024-06-04 14:32 [Bug c/115345] New: [12/13/14 REGRESSION] / Different outputs compared to GCC 11- and MSVC/Clang djordje.baljozovic at ac dot rwth-aachen.de
` (10 preceding siblings ...)
2024-06-04 18:43 ` djordje.baljozovic at ac dot rwth-aachen.de
@ 2024-06-05 6:59 ` rguenth at gcc dot gnu.org
2024-06-06 10:57 ` djordje.baljozovic at ac dot rwth-aachen.de
` (3 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: rguenth at gcc dot gnu.org @ 2024-06-05 6:59 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115345
--- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Djordje Baljozovic from comment #11)
> (In reply to Djordje Baljozovic from comment #9)
> > (In reply to Andrew Pinski from comment #7)
> > > A few questions, does `-fsanitize=undefined -fsanitize=address` report
> > > anything? Does it work at -O0 and not just -O3? Does adding
> > > -fno-strict-aliasing to the command line "fix" the crash? Are there any
> > > warnings with `-Wextra -Wall` that might be causing an issue?
> >
> > Have not tested -O0 and -fno-strict-aliasing; will let you know if this
> > fixed the problem.
> > No warnings with -Wextra -Wall to my knowledge.
> >
> > Sincerely,
> > George
>
> Hi Andrew and Jakub,
> The results are more than interesting:
>
> 1. -fno-strict-aliasing: none of the inputs processed (with O3)
> 2. O0: all but one input processed
> 3. O3: none of the inputs processed
> 4. O1 and O2: all inputs processed without any issues -- this did it.
>
> Now the question is: how on Earth did O1/O2 do the trick, and not O0?!
Can you check whether -O0 works with the other compilers? It feels like
you might be triggering some undefined behavior in your code.
If you have a short running example that breaks with -O0 it might be
also interesting to run it through valgrind to spot use-after-free
or uninitialized use issues.
> Once again, thanks a lot for your detailed and quick responses.
> George
> P.S. I will keep @Jakub's bisect idea in mind if something like this happens
> in the future.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug middle-end/115345] [12/13/14/15 Regression] Different outputs compared to GCC 11- and MSVC/Clang
2024-06-04 14:32 [Bug c/115345] New: [12/13/14 REGRESSION] / Different outputs compared to GCC 11- and MSVC/Clang djordje.baljozovic at ac dot rwth-aachen.de
` (11 preceding siblings ...)
2024-06-05 6:59 ` rguenth at gcc dot gnu.org
@ 2024-06-06 10:57 ` djordje.baljozovic at ac dot rwth-aachen.de
2024-06-06 17:08 ` sjames at gcc dot gnu.org
` (2 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: djordje.baljozovic at ac dot rwth-aachen.de @ 2024-06-06 10:57 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115345
--- Comment #13 from Djordje Baljozovic <djordje.baljozovic at ac dot rwth-aachen.de> ---
(In reply to Richard Biener from comment #12)
> (In reply to Djordje Baljozovic from comment #11)
> > (In reply to Djordje Baljozovic from comment #9)
> > > (In reply to Andrew Pinski from comment #7)
> > > > A few questions, does `-fsanitize=undefined -fsanitize=address` report
> > > > anything? Does it work at -O0 and not just -O3? Does adding
> > > > -fno-strict-aliasing to the command line "fix" the crash? Are there any
> > > > warnings with `-Wextra -Wall` that might be causing an issue?
> > >
> > > Have not tested -O0 and -fno-strict-aliasing; will let you know if this
> > > fixed the problem.
> > > No warnings with -Wextra -Wall to my knowledge.
> > >
> > > Sincerely,
> > > George
> >
> > Hi Andrew and Jakub,
> > The results are more than interesting:
> >
> > 1. -fno-strict-aliasing: none of the inputs processed (with O3)
> > 2. O0: all but one input processed
> > 3. O3: none of the inputs processed
> > 4. O1 and O2: all inputs processed without any issues -- this did it.
> >
> > Now the question is: how on Earth did O1/O2 do the trick, and not O0?!
>
> Can you check whether -O0 works with the other compilers? It feels like
> you might be triggering some undefined behavior in your code.
>
> If you have a short running example that breaks with -O0 it might be
> also interesting to run it through valgrind to spot use-after-free
> or uninitialized use issues.
>
> > Once again, thanks a lot for your detailed and quick responses.
> > George
> > P.S. I will keep @Jakub's bisect idea in mind if something like this happens
> > in the future.
Hi Richard,
Yes, I think that testing O0 with other compilers makes sense.
BTW, do you think that running the code through valgrind can identify some
issues which are not detected by fuzzers?
Thanks,
George
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug middle-end/115345] [12/13/14/15 Regression] Different outputs compared to GCC 11- and MSVC/Clang
2024-06-04 14:32 [Bug c/115345] New: [12/13/14 REGRESSION] / Different outputs compared to GCC 11- and MSVC/Clang djordje.baljozovic at ac dot rwth-aachen.de
` (12 preceding siblings ...)
2024-06-06 10:57 ` djordje.baljozovic at ac dot rwth-aachen.de
@ 2024-06-06 17:08 ` sjames at gcc dot gnu.org
2024-06-06 19:18 ` djordje.baljozovic at ac dot rwth-aachen.de
2024-06-27 13:42 ` djordje.baljozovic at ac dot rwth-aachen.de
15 siblings, 0 replies; 17+ messages in thread
From: sjames at gcc dot gnu.org @ 2024-06-06 17:08 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115345
Sam James <sjames at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |sjames at gcc dot gnu.org
--- Comment #14 from Sam James <sjames at gcc dot gnu.org> ---
It's worth keeping in mind:
* Fuzzers are distinct from sanitizers (fuzzers run with random or ~random
input and often use sanitizers to help find issues)
* Fuzzers might not be hitting the code you're having trouble with
* The implementations of sanitizers in gcc vs clang are different (and AFAIK
oss-fuzz uses clang). They share libsanitizer but when to add instrumentation
varies.
* Valgrind can find things that some sanitizers can't.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug middle-end/115345] [12/13/14/15 Regression] Different outputs compared to GCC 11- and MSVC/Clang
2024-06-04 14:32 [Bug c/115345] New: [12/13/14 REGRESSION] / Different outputs compared to GCC 11- and MSVC/Clang djordje.baljozovic at ac dot rwth-aachen.de
` (13 preceding siblings ...)
2024-06-06 17:08 ` sjames at gcc dot gnu.org
@ 2024-06-06 19:18 ` djordje.baljozovic at ac dot rwth-aachen.de
2024-06-27 13:42 ` djordje.baljozovic at ac dot rwth-aachen.de
15 siblings, 0 replies; 17+ messages in thread
From: djordje.baljozovic at ac dot rwth-aachen.de @ 2024-06-06 19:18 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115345
--- Comment #15 from Djordje Baljozovic <djordje.baljozovic at ac dot rwth-aachen.de> ---
(In reply to Sam James from comment #14)
> It's worth keeping in mind:
> * Fuzzers are distinct from sanitizers (fuzzers run with random or ~random
> input and often use sanitizers to help find issues)
> * Fuzzers might not be hitting the code you're having trouble with
> * The implementations of sanitizers in gcc vs clang are different (and AFAIK
> oss-fuzz uses clang). They share libsanitizer but when to add
> instrumentation varies.
> * Valgrind can find things that some sanitizers can't.
Hi Sam,
Thanks for this useful information.
To be perfectly honest, I did not even run address/unknown GCC sanitisers as I
thought that Clang and GCC sanitizers are identical (I can confirm that
oss-fuzz uses Clang sanitisers).
Will try Valgrind as I have already detected a share of issues with this
inherited code just by reading it, which did not show up in any
fuzzers'/sanitisers' reports.
Thanks,
George
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug middle-end/115345] [12/13/14/15 Regression] Different outputs compared to GCC 11- and MSVC/Clang
2024-06-04 14:32 [Bug c/115345] New: [12/13/14 REGRESSION] / Different outputs compared to GCC 11- and MSVC/Clang djordje.baljozovic at ac dot rwth-aachen.de
` (14 preceding siblings ...)
2024-06-06 19:18 ` djordje.baljozovic at ac dot rwth-aachen.de
@ 2024-06-27 13:42 ` djordje.baljozovic at ac dot rwth-aachen.de
15 siblings, 0 replies; 17+ messages in thread
From: djordje.baljozovic at ac dot rwth-aachen.de @ 2024-06-27 13:42 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115345
Djordje Baljozovic <djordje.baljozovic at ac dot rwth-aachen.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |RESOLVED
Resolution|--- |FIXED
^ permalink raw reply [flat|nested] 17+ messages in thread