From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <xry111@mengyan1223.wang>
Received: from mengyan1223.wang (mengyan1223.wang [89.208.246.23])
 by sourceware.org (Postfix) with ESMTPS id 57951385842D
 for <gcc-help@gcc.gnu.org>; Wed, 22 Dec 2021 10:36:47 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 57951385842D
Received: from [IPv6:240e:358:11f8:5b00:dc73:854d:832e:3] (unknown
 [IPv6:240e:358:11f8:5b00:dc73:854d:832e:3])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange ECDHE (P-256) server-signature ECDSA (P-384) server-digest
 SHA384) (Client did not present a certificate)
 (Authenticated sender: xry111@mengyan1223.wang)
 by mengyan1223.wang (Postfix) with ESMTPSA id A8391660F4;
 Wed, 22 Dec 2021 05:36:43 -0500 (EST)
Message-ID: <9eb235680e05e02f8ac6589a52d1996b3cfc0bb5.camel@mengyan1223.wang>
Subject: Re: broken code only when optimized "-O2"
From: Xi Ruoyao <xry111@mengyan1223.wang>
To: Adrian Moreno <amorenoz@redhat.com>, Florian Weimer
 <fweimer@redhat.com>,  Adrian Moreno via Gcc-help <gcc-help@gcc.gnu.org>
Cc: David Brown <david.brown@hesbynett.no>
Date: Wed, 22 Dec 2021 18:36:37 +0800
In-Reply-To: <c4813434-f4ba-bbf8-7d1e-71b9a5215315@redhat.com>
References: <cc01d4b4-ab21-febe-2ae4-197cfdca1816@redhat.com>
 <CAAxjCEwaUQ8bGd7NYqTjVL=VN4PbRsXx7PvJJWLwd9SL9oZ1RQ@mail.gmail.com>
 <f9e0c1c0-7a8b-2b63-eab4-ec0c7eb1b56c@hesbynett.no>
 <9b28799e-71f8-2ef9-1cc9-01345993cc11@redhat.com>
 <877dbx7x47.fsf@oldenburg.str.redhat.com>
 <c4813434-f4ba-bbf8-7d1e-71b9a5215315@redhat.com>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.42.2 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-3031.6 required=5.0 tests=BAYES_00, DKIM_SIGNED,
 DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, JMQ_SPF_NEUTRAL, SPF_HELO_PASS,
 SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.4
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on
 server2.sourceware.org
X-BeenThere: gcc-help@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-help mailing list <gcc-help.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-help>,
 <mailto:gcc-help-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-help/>
List-Post: <mailto:gcc-help@gcc.gnu.org>
List-Help: <mailto:gcc-help-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-help>,
 <mailto:gcc-help-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Dec 2021 10:36:49 -0000

On Wed, 2021-12-22 at 11:34 +0100, Adrian Moreno via Gcc-help wrote:
> 
> 
> On 12/22/21 11:27, Florian Weimer wrote:
> > * Adrian Moreno via Gcc-help:
> > 
> > > So here I do not know what the compiler would think about "pos" if
> > > it
> > > happens to point to some invalid stack address.
> > 
> > In such cases, the compiler typically assumes that the code in
> > question
> > is never executed.  This means that the comparison does not need to
> > be
> > performed, among other things.
> > 
> 
> So it wouldn't cause undefined behavior?

It *is* undefined behavior, and the compiler can remove any execution
paths which will eventually hit an undefined behavior.
-- 
Xi Ruoyao <xry111@mengyan1223.wang>
School of Aerospace Science and Technology, Xidian University