DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 8F5C5385800A
Subject: Re: [ANNOUNCEMENT] Test: {mingw64-{i686,x86_64}-,}gcc-11.1.0-0.1
To: cygwin@cygwin.com
References: <announce.871raewgfm.fsf@Rainer.invalid>
 <f3f9f296-cde2-1549-e7e9-38c1c855d5df@towo.net>
 <87mtszzsvd.fsf@Rainer.invalid>
 <29a53ee2-cac3-6815-792d-36f96be47bd1@towo.net>
 <5d911b7f-70c6-01f5-a353-d8735be46ecd@t-online.de>
From: Thomas Wolff <towo@towo.net>
Message-ID: <04176b59-1b36-c139-76b7-046e3823caa1@towo.net>
Date: Thu, 13 May 2021 23:57:40 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.10.1
MIME-Version: 1.0
In-Reply-To: <5d911b7f-70c6-01f5-a353-d8735be46ecd@t-online.de>
Precedence: list
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Errors-To: cygwin-bounces@cygwin.com
Sender: "Cygwin" <cygwin-bounces@cygwin.com>
Content-Transfer-Encoding: 8bit


Am 13.05.2021 um 21:33 schrieb Hans-Bernhard Bröker:
> Am 13.05.2021 um 10:57 schrieb Thomas Wolff:
>
>> The crash vanishes after removing a few lines from a conditional (if 
>> block) where the condition is false.
>
> A conditions that's always false, or one that's false during the 
> execution of a particular test case?
False during execution.
>
>> This smells like wrong calculation of a relative jump (Intel "short 
>> jump") by the optimizer.
>
> If it were that simple, the problematic change should stand out like 
> the proverbial sore thumb when comparing assembly listings of the two 
> cases.  Does it? 
Not really. As the problem only occurs with -O2, I'd need to check the 
result of gcc -S -O2, but with -O2, code is stirred so much it's hardly 
recognizable. The conditional jump to skip the (dynamically false) 
conditional is even a jump backwards in this case...

-- 
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple