From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id AA18338E6BC4; Thu,  6 Jun 2024 10:57:30 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org AA18338E6BC4
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1717671450;
	bh=Py+7gSiyPlm2rMnUWt50fcaZQ72VyxA7Sqdp25MuokY=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=kG6rsFpXYu5Y5JqkY75ef0F2SEOlQoVWePx8uditz8Ib4sNKqBgM5rPH4sOEkNqBf
	 Qck6s4LaAS5uNpu0hUNcsoMeNvbPGtKpKX/AXCC1vj8uOjIkKuxVLvgQRfYYk4z2xV
	 8Bs1wfs4iIKupVh+K0mHI4ZSSRGlRNOS2iMRRDlI=
From: "djordje.baljozovic at ac dot rwth-aachen.de"
 <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/115345] [12/13/14/15 Regression] Different outputs
 compared to GCC 11- and MSVC/Clang
Date: Thu, 06 Jun 2024 10:57:29 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 12.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: djordje.baljozovic at ac dot rwth-aachen.de
X-Bugzilla-Status: WAITING
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-115345-4-ARTjKRsAfh@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-115345-4@http.gcc.gnu.org/bugzilla/>
References: <bug-115345-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

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

--- 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=3Dundefined -fsanitize=3Daddress`=
 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?
> > >=20
> > > Have not tested -O0 and -fno-strict-aliasing; will let you know if th=
is
> > > fixed the problem.
> > > No warnings with -Wextra -Wall to my knowledge.
> > >=20
> > > Sincerely,
> > > George
> >=20
> > Hi Andrew and Jakub,
> > The results are more than interesting:
> >=20
> > 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.
> >=20
> > Now the question is: how on Earth did O1/O2 do the trick, and not O0?!
>=20
> Can you check whether -O0 works with the other compilers?  It feels like
> you might be triggering some undefined behavior in your code.
>=20
> 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.
>=20
> > 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 ha=
ppens
> > 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=