[ANNOUNCEMENT] Test: {mingw64-{i686,x86_64}-,}gcc-11.1.0-0.1

[ANNOUNCEMENT] Test: {mingw64-{i686,x86_64}-,}gcc-11.1.0-0.1

[Achim Gratz]

The native and mingw-w64 cross compilers have been updated for both
architectures to the latest upstream release version:

 gcc-11.1.0-0.1
 mingw64-i686-gcc-11.1.0-0.1
 mingw64-x86_64-gcc-11.1.0-0.1

This test release includes libgccjit as a separate package for the
native toolchain on both architectures.  Since Cygwin can't use ASLR any
nontrivial dynamic objects that get created in this way will likely need
to get rebased before they can be used (especially on 32bit).  It is
unlikely that build systems recognize the need for doing that at the
moment.

Please test these compilers with your packages and applications as
extensively as possible (especially if you are a Cygwin package
maintainer).  Unless problems are found that necessitate another round
of testing, the plan is to bootstrap the support libraries with the new
toolchain and do a non-test update in about two to four weeks.

-- 
              *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there. It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain.com@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.

Re: [ANNOUNCEMENT] Test: {mingw64-{i686,x86_64}-,}gcc-11.1.0-0.1

[Thomas Wolff]

Am 10.05.2021 um 21:13 schrieb Achim Gratz:
> The native and mingw-w64 cross compilers have been updated for both
> architectures to the latest upstream release version:
>
>   gcc-11.1.0-0.1
Are there any known problems with gcc 11? My program crashes if compiled 
with gcc -O2; gcc -O1 works, gcc 10 also works.
Thomas

>   mingw64-i686-gcc-11.1.0-0.1
>   mingw64-x86_64-gcc-11.1.0-0.1
>
> This test release includes libgccjit as a separate package for the
> native toolchain on both architectures.  Since Cygwin can't use ASLR any
> nontrivial dynamic objects that get created in this way will likely need
> to get rebased before they can be used (especially on 32bit).  It is
> unlikely that build systems recognize the need for doing that at the
> moment.
>
> Please test these compilers with your packages and applications as
> extensively as possible (especially if you are a Cygwin package
> maintainer).  Unless problems are found that necessitate another round
> of testing, the plan is to bootstrap the support libraries with the new
> toolchain and do a non-test update in about two to four weeks.
>

Re: [ANNOUNCEMENT] Test: {mingw64-{i686,x86_64}-,}gcc-11.1.0-0.1

[Jonathan Yong]

On 5/12/21 9:14 AM, Thomas Wolff wrote:
> Am 10.05.2021 um 21:13 schrieb Achim Gratz:
>> The native and mingw-w64 cross compilers have been updated for both
>> architectures to the latest upstream release version:
>>
>>   gcc-11.1.0-0.1
> Are there any known problems with gcc 11? My program crashes if compiled 
> with gcc -O2; gcc -O1 works, gcc 10 also works.
> Thomas
> 
>>   mingw64-i686-gcc-11.1.0-0.1
>>   mingw64-x86_64-gcc-11.1.0-0.1
>>
>> This test release includes libgccjit as a separate package for the
>> native toolchain on both architectures.  Since Cygwin can't use ASLR any
>> nontrivial dynamic objects that get created in this way will likely need
>> to get rebased before they can be used (especially on 32bit).  It is
>> unlikely that build systems recognize the need for doing that at the
>> moment.
>>
>> Please test these compilers with your packages and applications as
>> extensively as possible (especially if you are a Cygwin package
>> maintainer).  Unless problems are found that necessitate another round
>> of testing, the plan is to bootstrap the support libraries with the new
>> toolchain and do a non-test update in about two to four weeks.
>>
> 
> 

Does stripping the optimized executable fix things? Are you also able to 
produce a minimal test case?

Re: [ANNOUNCEMENT] Test: {mingw64-{i686,x86_64}-,}gcc-11.1.0-0.1

[Thomas Wolff]

Am 12.05.2021 um 12:42 schrieb Jonathan Yong via Cygwin:
> On 5/12/21 9:14 AM, Thomas Wolff wrote:
>> Am 10.05.2021 um 21:13 schrieb Achim Gratz:
>>> The native and mingw-w64 cross compilers have been updated for both
>>> architectures to the latest upstream release version:
>>>
>>>   gcc-11.1.0-0.1
>> Are there any known problems with gcc 11? My program crashes if 
>> compiled with gcc -O2; gcc -O1 works, gcc 10 also works.
>> Thomas
>>
>>>   mingw64-i686-gcc-11.1.0-0.1
>>>   mingw64-x86_64-gcc-11.1.0-0.1
>>>
>>> This test release includes libgccjit as a separate package for the
>>> native toolchain on both architectures.  Since Cygwin can't use ASLR 
>>> any
>>> nontrivial dynamic objects that get created in this way will likely 
>>> need
>>> to get rebased before they can be used (especially on 32bit). It is
>>> unlikely that build systems recognize the need for doing that at the
>>> moment.
>>>
>>> Please test these compilers with your packages and applications as
>>> extensively as possible (especially if you are a Cygwin package
>>> maintainer).  Unless problems are found that necessitate another round
>>> of testing, the plan is to bootstrap the support libraries with the new
>>> toolchain and do a non-test update in about two to four weeks.
>>>
>>
>>
>
> Does stripping the optimized executable fix things?
No
> Are you also able to produce a minimal test case? 
Hardly. Behaviour is totally erratic. If I let the stacktrace tell me 
where it crashed and make the function empty, it happens somewhere else...

Re: [ANNOUNCEMENT] Test: {mingw64-{i686,x86_64}-,}gcc-11.1.0-0.1

[Achim Gratz]

Thomas Wolff writes:
> Am 10.05.2021 um 21:13 schrieb Achim Gratz:
>> The native and mingw-w64 cross compilers have been updated for both
>> architectures to the latest upstream release version:
>>
>>   gcc-11.1.0-0.1
> Are there any known problems with gcc 11? My program crashes if
> compiled with gcc -O2; gcc -O1 works, gcc 10 also works.

None that I'd know of, especially given that very vague symptoms.  While
I guess it's possible that there's a bug in the optimizer, I'd first
attempt to rule out undefined behaviour in the program being compiled.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: [ANNOUNCEMENT] Test: {mingw64-{i686,x86_64}-,}gcc-11.1.0-0.1

[Brian Inglis]

On 2021-05-12 12:30, Thomas Wolff wrote:
> Am 12.05.2021 um 12:42 schrieb Jonathan Yong via Cygwin:
>> On 5/12/21 9:14 AM, Thomas Wolff wrote:
>>> Am 10.05.2021 um 21:13 schrieb Achim Gratz:
>>>> The native and mingw-w64 cross compilers have been updated for both
>>>> architectures to the latest upstream release version:
>>>>   gcc-11.1.0-0.1

>>> Are there any known problems with gcc 11? My program crashes if 
>>> compiled with gcc -O2; gcc -O1 works, gcc 10 also works.
Do you mean that building mintty with gcc 11 -O2 breaks mintty?

>>>>   mingw64-i686-gcc-11.1.0-0.1
>>>>   mingw64-x86_64-gcc-11.1.0-0.1
>>>>
>>>> This test release includes libgccjit as a separate package for the
>>>> native toolchain on both architectures.  Since Cygwin can't use ASLR any
>>>> nontrivial dynamic objects that get created in this way will likely need
>>>> to get rebased before they can be used (especially on 32bit). It is
>>>> unlikely that build systems recognize the need for doing that at the
>>>> moment.
>>>>
>>>> Please test these compilers with your packages and applications as
>>>> extensively as possible (especially if you are a Cygwin package
>>>> maintainer).  Unless problems are found that necessitate another round
>>>> of testing, the plan is to bootstrap the support libraries with the new
>>>> toolchain and do a non-test update in about two to four weeks.

>> Does stripping the optimized executable fix things?

> No

>> Are you also able to produce a minimal test case? 

> Hardly. Behaviour is totally erratic. If I let the stacktrace tell me where 
> it crashed and make the function empty, it happens somewhere else...
-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

Re: [ANNOUNCEMENT] Test: {mingw64-{i686,x86_64}-,}gcc-11.1.0-0.1

[Thomas Wolff]

Am 13.05.2021 um 03:41 schrieb Brian Inglis:
>
> On 2021-05-12 12:30, Thomas Wolff wrote:
>> Am 12.05.2021 um 12:42 schrieb Jonathan Yong via Cygwin:
>>> On 5/12/21 9:14 AM, Thomas Wolff wrote:
>>>> Am 10.05.2021 um 21:13 schrieb Achim Gratz:
>>>>> The native and mingw-w64 cross compilers have been updated for both
>>>>> architectures to the latest upstream release version:
>>>>>   gcc-11.1.0-0.1
>
>>>> Are there any known problems with gcc 11? My program crashes if 
>>>> compiled with gcc -O2; gcc -O1 works, gcc 10 also works.
> Do you mean that building mintty with gcc 11 -O2 breaks mintty?
No, this is actually about another program, my text editor mined (just 
migrating to github).

>
>>>>>   mingw64-i686-gcc-11.1.0-0.1
>>>>>   mingw64-x86_64-gcc-11.1.0-0.1
>>>>>
>>>>> This test release includes libgccjit as a separate package for the
>>>>> native toolchain on both architectures.  Since Cygwin can't use 
>>>>> ASLR any
>>>>> nontrivial dynamic objects that get created in this way will 
>>>>> likely need
>>>>> to get rebased before they can be used (especially on 32bit). It is
>>>>> unlikely that build systems recognize the need for doing that at the
>>>>> moment.
>>>>>
>>>>> Please test these compilers with your packages and applications as
>>>>> extensively as possible (especially if you are a Cygwin package
>>>>> maintainer).  Unless problems are found that necessitate another 
>>>>> round
>>>>> of testing, the plan is to bootstrap the support libraries with 
>>>>> the new
>>>>> toolchain and do a non-test update in about two to four weeks.
>
>>> Does stripping the optimized executable fix things?
>
>> No
>
>>> Are you also able to produce a minimal test case? 
>
>> Hardly. Behaviour is totally erratic. If I let the stacktrace tell me 
>> where it crashed and make the function empty, it happens somewhere 
>> else...

Re: [ANNOUNCEMENT] Test: {mingw64-{i686,x86_64}-,}gcc-11.1.0-0.1

[Thomas Wolff]

Am 12.05.2021 um 20:53 schrieb Achim Gratz:
> Thomas Wolff writes:
>> Am 10.05.2021 um 21:13 schrieb Achim Gratz:
>>> The native and mingw-w64 cross compilers have been updated for both
>>> architectures to the latest upstream release version:
>>>
>>>    gcc-11.1.0-0.1
>> Are there any known problems with gcc 11? My program crashes if
>> compiled with gcc -O2; gcc -O1 works, gcc 10 also works.
> None that I'd know of, especially given that very vague symptoms.  While
> I guess it's possible that there's a bug in the optimizer, I'd first
> attempt to rule out undefined behaviour in the program being compiled.
The crash vanishes after removing a few lines from a conditional (if 
block) where the condition is false.
This smells like wrong calculation of a relative jump (Intel "short 
jump") by the optimizer.

>
>
> Regards,
> Achim.

Re: [ANNOUNCEMENT] Test: {mingw64-{i686,x86_64}-,}gcc-11.1.0-0.1

[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?

> 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?

Re: [ANNOUNCEMENT] Test: {mingw64-{i686,x86_64}-,}gcc-11.1.0-0.1

[Thomas Wolff]

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...