* GCC 11.1 Release Candidate available from gcc.gnu.org
@ 2021-04-20 15:24 Jakub Jelinek
2021-04-20 20:27 ` William Seurer
2021-04-20 22:25 ` GCC 11.1 Release Candidate available from gcc.gnu.org David Edelsohn
0 siblings, 2 replies; 17+ messages in thread
From: Jakub Jelinek @ 2021-04-20 15:24 UTC (permalink / raw)
To: gcc
The first release candidate for GCC 11.1 is available from
https://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420/
ftp://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420
and shortly its mirrors. It has been generated from git revision
r11-8265-g246abba01f302eb453475b650ba839ec905be76d.
I have so far bootstrapped and tested the release candidate on
x86_64-linux and i686-linux. Please test it and report any issues to
bugzilla.
If all goes well, I'd like to release 11.1 on Tuesday, April 27th.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: GCC 11.1 Release Candidate available from gcc.gnu.org
2021-04-20 15:24 GCC 11.1 Release Candidate available from gcc.gnu.org Jakub Jelinek
@ 2021-04-20 20:27 ` William Seurer
2021-04-20 21:05 ` Andreas Schwab
2021-04-20 21:20 ` D build on powerpc broken (was Re: GCC 11.1 Release Candidate available from gcc.gnu.org) Jakub Jelinek
2021-04-20 22:25 ` GCC 11.1 Release Candidate available from gcc.gnu.org David Edelsohn
1 sibling, 2 replies; 17+ messages in thread
From: William Seurer @ 2021-04-20 20:27 UTC (permalink / raw)
To: gcc
On 4/20/21 10:24 AM, Jakub Jelinek via Gcc wrote:
> The first release candidate for GCC 11.1 is available from
>
> https://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420/
> ftp://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420
>
> and shortly its mirrors. It has been generated from git revision
> r11-8265-g246abba01f302eb453475b650ba839ec905be76d.
>
> I have so far bootstrapped and tested the release candidate on
> x86_64-linux and i686-linux. Please test it and report any issues to
> bugzilla.
>
> If all goes well, I'd like to release 11.1 on Tuesday, April 27th.
>
I am seeing at least one compilation failure when building the RC. Note
that trunk built fine for me yesterday morning.
libtool: compile: /home/seurer/gcc/git/build/gcc-11.1.0-RC-20210420/./gcc/gdc -B/home/seurer/gcc/git/build/gcc-11.1.0-RC-20210420/./gcc/ -B/home/seurer/gcc/git/install/gcc-11.1.0-RC-20210420/powerpc64-unknown-linux-gnu/bin/ -B/home/seurer/gcc/git/install/gcc-11.1.0-RC-20210420/powerpc64-unknown-linux-gnu/lib/ -isystem /home/seurer/gcc/git/install/gcc-11.1.0-RC-20210420/powerpc64-unknown-linux-gnu/include -isystem /home/seurer/gcc/git/install/gcc-11.1.0-RC-20210420/powerpc64-unknown-linux-gnu/sys-include -fchecking=1 -fversion=Shared -Wall -frelease -ffunction-sections -fdata-sections -O2 -g -nostdinc -I /home/seurer/gcc/git/gcc-11.1.0-RC-20210420/libphobos/libdruntime -I . -c /home/seurer/gcc/git/gcc-11.1.0-RC-20210420/libphobos/libdruntime/core/thread/osthread.d -fPIC -fversion=Shared -o core/thread/.libs/osthread.o
/tmp/cc8zG8DV.s: Assembler messages:
/tmp/cc8zG8DV.s:2566: Error: unsupported relocation against r13
/tmp/cc8zG8DV.s:2570: Error: unsupported relocation against r14
/tmp/cc8zG8DV.s:2574: Error: unsupported relocation against r15
/tmp/cc8zG8DV.s:2578: Error: unsupported relocation against r16
/tmp/cc8zG8DV.s:2582: Error: unsupported relocation against r17
/tmp/cc8zG8DV.s:2586: Error: unsupported relocation against r18
/tmp/cc8zG8DV.s:2590: Error: unsupported relocation against r19
/tmp/cc8zG8DV.s:2594: Error: unsupported relocation against r20
/tmp/cc8zG8DV.s:2598: Error: unsupported relocation against r21
/tmp/cc8zG8DV.s:2602: Error: unsupported relocation against r22
/tmp/cc8zG8DV.s:2606: Error: unsupported relocation against r23
/tmp/cc8zG8DV.s:2610: Error: unsupported relocation against r24
/tmp/cc8zG8DV.s:2614: Error: unsupported relocation against r25
/tmp/cc8zG8DV.s:2618: Error: unsupported relocation against r26
/tmp/cc8zG8DV.s:2622: Error: unsupported relocation against r27
/tmp/cc8zG8DV.s:2626: Error: unsupported relocation against r28
/tmp/cc8zG8DV.s:2630: Error: unsupported relocation against r29
/tmp/cc8zG8DV.s:2634: Error: unsupported relocation against r30
/tmp/cc8zG8DV.s:2638: Error: unsupported relocation against r31
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: GCC 11.1 Release Candidate available from gcc.gnu.org
2021-04-20 20:27 ` William Seurer
@ 2021-04-20 21:05 ` Andreas Schwab
2021-04-20 21:20 ` D build on powerpc broken (was Re: GCC 11.1 Release Candidate available from gcc.gnu.org) Jakub Jelinek
1 sibling, 0 replies; 17+ messages in thread
From: Andreas Schwab @ 2021-04-20 21:05 UTC (permalink / raw)
To: William Seurer via Gcc; +Cc: William Seurer, Iain Buclaw
On Apr 20 2021, William Seurer via Gcc wrote:
> On 4/20/21 10:24 AM, Jakub Jelinek via Gcc wrote:
>> The first release candidate for GCC 11.1 is available from
>>
>> https://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420/
>> ftp://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420
>>
>> and shortly its mirrors. It has been generated from git revision
>> r11-8265-g246abba01f302eb453475b650ba839ec905be76d.
>>
>> I have so far bootstrapped and tested the release candidate on
>> x86_64-linux and i686-linux. Please test it and report any issues to
>> bugzilla.
>>
>> If all goes well, I'd like to release 11.1 on Tuesday, April 27th.
>>
> I am seeing at least one compilation failure when building the RC. Note
> that trunk built fine for me yesterday morning.
>
> libtool: compile: /home/seurer/gcc/git/build/gcc-11.1.0-RC-20210420/./gcc/gdc -B/home/seurer/gcc/git/build/gcc-11.1.0-RC-20210420/./gcc/ -B/home/seurer/gcc/git/install/gcc-11.1.0-RC-20210420/powerpc64-unknown-linux-gnu/bin/ -B/home/seurer/gcc/git/install/gcc-11.1.0-RC-20210420/powerpc64-unknown-linux-gnu/lib/ -isystem /home/seurer/gcc/git/install/gcc-11.1.0-RC-20210420/powerpc64-unknown-linux-gnu/include -isystem /home/seurer/gcc/git/install/gcc-11.1.0-RC-20210420/powerpc64-unknown-linux-gnu/sys-include -fchecking=1 -fversion=Shared -Wall -frelease -ffunction-sections -fdata-sections -O2 -g -nostdinc -I /home/seurer/gcc/git/gcc-11.1.0-RC-20210420/libphobos/libdruntime -I . -c /home/seurer/gcc/git/gcc-11.1.0-RC-20210420/libphobos/libdruntime/core/thread/osthread.d -fPIC -fversion=Shared -
> o core/thread/.libs/osthread.o
> /tmp/cc8zG8DV.s: Assembler messages:
> /tmp/cc8zG8DV.s:2566: Error: unsupported relocation against r13
> /tmp/cc8zG8DV.s:2570: Error: unsupported relocation against r14
> /tmp/cc8zG8DV.s:2574: Error: unsupported relocation against r15
> /tmp/cc8zG8DV.s:2578: Error: unsupported relocation against r16
> /tmp/cc8zG8DV.s:2582: Error: unsupported relocation against r17
> /tmp/cc8zG8DV.s:2586: Error: unsupported relocation against r18
> /tmp/cc8zG8DV.s:2590: Error: unsupported relocation against r19
> /tmp/cc8zG8DV.s:2594: Error: unsupported relocation against r20
> /tmp/cc8zG8DV.s:2598: Error: unsupported relocation against r21
> /tmp/cc8zG8DV.s:2602: Error: unsupported relocation against r22
> /tmp/cc8zG8DV.s:2606: Error: unsupported relocation against r23
> /tmp/cc8zG8DV.s:2610: Error: unsupported relocation against r24
> /tmp/cc8zG8DV.s:2614: Error: unsupported relocation against r25
> /tmp/cc8zG8DV.s:2618: Error: unsupported relocation against r26
> /tmp/cc8zG8DV.s:2622: Error: unsupported relocation against r27
> /tmp/cc8zG8DV.s:2626: Error: unsupported relocation against r28
> /tmp/cc8zG8DV.s:2630: Error: unsupported relocation against r29
> /tmp/cc8zG8DV.s:2634: Error: unsupported relocation against r30
> /tmp/cc8zG8DV.s:2638: Error: unsupported relocation against r31
That comes from commit 6eae7549b8a.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
^ permalink raw reply [flat|nested] 17+ messages in thread
* D build on powerpc broken (was Re: GCC 11.1 Release Candidate available from gcc.gnu.org)
2021-04-20 20:27 ` William Seurer
2021-04-20 21:05 ` Andreas Schwab
@ 2021-04-20 21:20 ` Jakub Jelinek
2021-04-20 22:02 ` Peter Bergner
2021-04-20 23:38 ` William Seurer
1 sibling, 2 replies; 17+ messages in thread
From: Jakub Jelinek @ 2021-04-20 21:20 UTC (permalink / raw)
To: William Seurer, Iain Buclaw; +Cc: gcc
On Tue, Apr 20, 2021 at 03:27:08PM -0500, William Seurer via Gcc wrote:
>
> On 4/20/21 10:24 AM, Jakub Jelinek via Gcc wrote:
> > The first release candidate for GCC 11.1 is available from
> >
> > https://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420/
> > ftp://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420
> >
> > and shortly its mirrors. It has been generated from git revision
> > r11-8265-g246abba01f302eb453475b650ba839ec905be76d.
> >
> > I have so far bootstrapped and tested the release candidate on
> > x86_64-linux and i686-linux. Please test it and report any issues to
> > bugzilla.
> >
> > If all goes well, I'd like to release 11.1 on Tuesday, April 27th.
> >
> I am seeing at least one compilation failure when building the RC. Note
> that trunk built fine for me yesterday morning.
>
> libtool: compile: /home/seurer/gcc/git/build/gcc-11.1.0-RC-20210420/./gcc/gdc -B/home/seurer/gcc/git/build/gcc-11.1.0-RC-20210420/./gcc/ -B/home/seurer/gcc/git/install/gcc-11.1.0-RC-20210420/powerpc64-unknown-linux-gnu/bin/ -B/home/seurer/gcc/git/install/gcc-11.1.0-RC-20210420/powerpc64-unknown-linux-gnu/lib/ -isystem /home/seurer/gcc/git/install/gcc-11.1.0-RC-20210420/powerpc64-unknown-linux-gnu/include -isystem /home/seurer/gcc/git/install/gcc-11.1.0-RC-20210420/powerpc64-unknown-linux-gnu/sys-include -fchecking=1 -fversion=Shared -Wall -frelease -ffunction-sections -fdata-sections -O2 -g -nostdinc -I /home/seurer/gcc/git/gcc-11.1.0-RC-20210420/libphobos/libdruntime -I . -c /home/seurer/gcc/git/gcc-11.1.0-RC-20210420/libphobos/libdruntime/core/thread/osthread.d -fPIC -fversion=Shared -o core/thread/.libs/osthread.o
> /tmp/cc8zG8DV.s: Assembler messages:
> /tmp/cc8zG8DV.s:2566: Error: unsupported relocation against r13
> /tmp/cc8zG8DV.s:2570: Error: unsupported relocation against r14
> /tmp/cc8zG8DV.s:2574: Error: unsupported relocation against r15
> /tmp/cc8zG8DV.s:2578: Error: unsupported relocation against r16
> /tmp/cc8zG8DV.s:2582: Error: unsupported relocation against r17
> /tmp/cc8zG8DV.s:2586: Error: unsupported relocation against r18
> /tmp/cc8zG8DV.s:2590: Error: unsupported relocation against r19
> /tmp/cc8zG8DV.s:2594: Error: unsupported relocation against r20
> /tmp/cc8zG8DV.s:2598: Error: unsupported relocation against r21
> /tmp/cc8zG8DV.s:2602: Error: unsupported relocation against r22
> /tmp/cc8zG8DV.s:2606: Error: unsupported relocation against r23
> /tmp/cc8zG8DV.s:2610: Error: unsupported relocation against r24
> /tmp/cc8zG8DV.s:2614: Error: unsupported relocation against r25
> /tmp/cc8zG8DV.s:2618: Error: unsupported relocation against r26
> /tmp/cc8zG8DV.s:2622: Error: unsupported relocation against r27
> /tmp/cc8zG8DV.s:2626: Error: unsupported relocation against r28
> /tmp/cc8zG8DV.s:2630: Error: unsupported relocation against r29
> /tmp/cc8zG8DV.s:2634: Error: unsupported relocation against r30
> /tmp/cc8zG8DV.s:2638: Error: unsupported relocation against r31
So do we need to change
+ else version (PPC)
+ {
+ void*[19] regs = void;
+ asm pure nothrow @nogc
+ {
+ "stw r13, %0" : "=m" (regs[ 0]);
+ "stw r14, %0" : "=m" (regs[ 1]);
...
+ else version (PPC64)
+ {
+ void*[19] regs = void;
+ asm pure nothrow @nogc
+ {
+ "std r13, %0" : "=m" (regs[ 0]);
+ "std r14, %0" : "=m" (regs[ 1]);
...
to "stw 13, %0" and "std 13, %0" etc. unconditionally, or
to "stw %%r13, %0" etc. under some conditions?
Jakub
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: D build on powerpc broken (was Re: GCC 11.1 Release Candidate available from gcc.gnu.org)
2021-04-20 21:20 ` D build on powerpc broken (was Re: GCC 11.1 Release Candidate available from gcc.gnu.org) Jakub Jelinek
@ 2021-04-20 22:02 ` Peter Bergner
2021-04-20 22:47 ` ibuclaw
2021-04-20 22:49 ` Iain Sandoe
2021-04-20 23:38 ` William Seurer
1 sibling, 2 replies; 17+ messages in thread
From: Peter Bergner @ 2021-04-20 22:02 UTC (permalink / raw)
To: Jakub Jelinek, William Seurer, Iain Buclaw; +Cc: gcc
On 4/20/21 4:20 PM, Jakub Jelinek via Gcc wrote:
> On Tue, Apr 20, 2021 at 03:27:08PM -0500, William Seurer via Gcc wrote:
>> /tmp/cc8zG8DV.s: Assembler messages:
>> /tmp/cc8zG8DV.s:2566: Error: unsupported relocation against r13
>> /tmp/cc8zG8DV.s:2570: Error: unsupported relocation against r14
[snip]
> So do we need to change
> + else version (PPC)
> + {
> + void*[19] regs = void;
> + asm pure nothrow @nogc
> + {
> + "stw r13, %0" : "=m" (regs[ 0]);
> + "stw r14, %0" : "=m" (regs[ 1]);
> ...
> + else version (PPC64)
> + {
> + void*[19] regs = void;
> + asm pure nothrow @nogc
> + {
> + "std r13, %0" : "=m" (regs[ 0]);
> + "std r14, %0" : "=m" (regs[ 1]);
> ...
> to "stw 13, %0" and "std 13, %0" etc. unconditionally, or
> to "stw %%r13, %0" etc. under some conditions?
Yes, I think so. The "r13", etc. names are not accepted by gas unless you
use the -mregnames option. It's easier to just remove the 'r'.
Peter
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: GCC 11.1 Release Candidate available from gcc.gnu.org
2021-04-20 15:24 GCC 11.1 Release Candidate available from gcc.gnu.org Jakub Jelinek
2021-04-20 20:27 ` William Seurer
@ 2021-04-20 22:25 ` David Edelsohn
2021-04-20 23:52 ` Thomas Rodgers
1 sibling, 1 reply; 17+ messages in thread
From: David Edelsohn @ 2021-04-20 22:25 UTC (permalink / raw)
To: Jakub Jelinek; +Cc: GCC Development
On Tue, Apr 20, 2021 at 12:43 PM Jakub Jelinek via Gcc <gcc@gcc.gnu.org> wrote:
>
> The first release candidate for GCC 11.1 is available from
>
> https://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420/
> ftp://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420
>
> and shortly its mirrors. It has been generated from git revision
> r11-8265-g246abba01f302eb453475b650ba839ec905be76d.
>
> I have so far bootstrapped and tested the release candidate on
> x86_64-linux and i686-linux. Please test it and report any issues to
> bugzilla.
>
> If all goes well, I'd like to release 11.1 on Tuesday, April 27th.
As I have reported in Bugzilla, the last minute
libstdc++: Refactor/cleanup of C++20 atomic wait implementation
has severely regressed libstdc++ on AIX due to changes to
bits/semaphore_base.h header.
- David
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: D build on powerpc broken (was Re: GCC 11.1 Release Candidate available from gcc.gnu.org)
2021-04-20 22:02 ` Peter Bergner
@ 2021-04-20 22:47 ` ibuclaw
2021-04-20 22:49 ` Iain Sandoe
1 sibling, 0 replies; 17+ messages in thread
From: ibuclaw @ 2021-04-20 22:47 UTC (permalink / raw)
To: Peter Bergner, Jakub Jelinek, William Seurer; +Cc: gcc
> On 21/04/2021 00:02 Peter Bergner <bergner@linux.ibm.com> wrote:
>
>
> On 4/20/21 4:20 PM, Jakub Jelinek via Gcc wrote:
> > On Tue, Apr 20, 2021 at 03:27:08PM -0500, William Seurer via Gcc wrote:
> >> /tmp/cc8zG8DV.s: Assembler messages:
> >> /tmp/cc8zG8DV.s:2566: Error: unsupported relocation against r13
> >> /tmp/cc8zG8DV.s:2570: Error: unsupported relocation against r14
> [snip]
> > So do we need to change
> > + else version (PPC)
> > + {
> > + void*[19] regs = void;
> > + asm pure nothrow @nogc
> > + {
> > + "stw r13, %0" : "=m" (regs[ 0]);
> > + "stw r14, %0" : "=m" (regs[ 1]);
> > ...
> > + else version (PPC64)
> > + {
> > + void*[19] regs = void;
> > + asm pure nothrow @nogc
> > + {
> > + "std r13, %0" : "=m" (regs[ 0]);
> > + "std r14, %0" : "=m" (regs[ 1]);
> > ...
> > to "stw 13, %0" and "std 13, %0" etc. unconditionally, or
> > to "stw %%r13, %0" etc. under some conditions?
>
> Yes, I think so. The "r13", etc. names are not accepted by gas unless you
> use the -mregnames option. It's easier to just remove the 'r'.
>
OK, unless told otherwise, I'll keep them in for darwin though.
--- a/libphobos/libdruntime/core/thread/osthread.d
+++ b/libphobos/libdruntime/core/thread/osthread.d
@@ -1444,55 +1444,35 @@ in (fn)
else version (PPC)
{
void*[19] regs = void;
- asm pure nothrow @nogc
- {
- "stw r13, %0" : "=m" (regs[ 0]);
- "stw r14, %0" : "=m" (regs[ 1]);
- "stw r15, %0" : "=m" (regs[ 2]);
- "stw r16, %0" : "=m" (regs[ 3]);
- "stw r17, %0" : "=m" (regs[ 4]);
- "stw r18, %0" : "=m" (regs[ 5]);
- "stw r19, %0" : "=m" (regs[ 6]);
- "stw r20, %0" : "=m" (regs[ 7]);
- "stw r21, %0" : "=m" (regs[ 9]);
- "stw r22, %0" : "=m" (regs[ 9]);
- "stw r23, %0" : "=m" (regs[10]);
- "stw r24, %0" : "=m" (regs[11]);
- "stw r25, %0" : "=m" (regs[12]);
- "stw r26, %0" : "=m" (regs[13]);
- "stw r27, %0" : "=m" (regs[14]);
- "stw r28, %0" : "=m" (regs[15]);
- "stw r29, %0" : "=m" (regs[16]);
- "stw r30, %0" : "=m" (regs[17]);
- "stw r31, %0" : "=m" (regs[18]);
- }
+ version (Darwin)
+ enum regname = "r";
+ else
+ enum regname = "";
+ static foreach (i; 0 .. regs.length)
+ {{
+ enum int j = 13 + i; // source register
+ asm pure nothrow @nogc
+ {
+ "stw "~regname~j.stringof~", %0" : "=m" (regs[i]);
+ }
+ }}
sp = cast(void*)®s[0];
}
else version (PPC64)
{
void*[19] regs = void;
- asm pure nothrow @nogc
- {
- "std r13, %0" : "=m" (regs[ 0]);
- "std r14, %0" : "=m" (regs[ 1]);
- "std r15, %0" : "=m" (regs[ 2]);
- "std r16, %0" : "=m" (regs[ 3]);
- "std r17, %0" : "=m" (regs[ 4]);
- "std r18, %0" : "=m" (regs[ 5]);
- "std r19, %0" : "=m" (regs[ 6]);
- "std r20, %0" : "=m" (regs[ 7]);
- "std r21, %0" : "=m" (regs[ 8]);
- "std r22, %0" : "=m" (regs[ 9]);
- "std r23, %0" : "=m" (regs[10]);
- "std r24, %0" : "=m" (regs[11]);
- "std r25, %0" : "=m" (regs[12]);
- "std r26, %0" : "=m" (regs[13]);
- "std r27, %0" : "=m" (regs[14]);
- "std r28, %0" : "=m" (regs[15]);
- "std r29, %0" : "=m" (regs[16]);
- "std r30, %0" : "=m" (regs[17]);
- "std r31, %0" : "=m" (regs[18]);
- }
+ version (Darwin)
+ enum regname = "r";
+ else
+ enum regname = "";
+ static foreach (i; 0 .. regs.length)
+ {{
+ enum int j = 13 + i; // source register
+ asm pure nothrow @nogc
+ {
+ "std "~regname~j.stringof~", %0" : "=m" (regs[i]);
+ }
+ }}
sp = cast(void*)®s[0];
}
else
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: D build on powerpc broken (was Re: GCC 11.1 Release Candidate available from gcc.gnu.org)
2021-04-20 22:02 ` Peter Bergner
2021-04-20 22:47 ` ibuclaw
@ 2021-04-20 22:49 ` Iain Sandoe
1 sibling, 0 replies; 17+ messages in thread
From: Iain Sandoe @ 2021-04-20 22:49 UTC (permalink / raw)
To: Peter Bergner; +Cc: Jakub Jelinek, William Seurer, Iain Buclaw, gcc
Peter Bergner via Gcc <gcc@gcc.gnu.org> wrote:
> On 4/20/21 4:20 PM, Jakub Jelinek via Gcc wrote:
>> On Tue, Apr 20, 2021 at 03:27:08PM -0500, William Seurer via Gcc wrote:
>>> /tmp/cc8zG8DV.s: Assembler messages:
>>> /tmp/cc8zG8DV.s:2566: Error: unsupported relocation against r13
>>> /tmp/cc8zG8DV.s:2570: Error: unsupported relocation against r14
> [snip]
>> So do we need to change
>> + else version (PPC)
>> + {
>> + void*[19] regs = void;
>> + asm pure nothrow @nogc
>> + {
>> + "stw r13, %0" : "=m" (regs[ 0]);
>> + "stw r14, %0" : "=m" (regs[ 1]);
>> ...
>> + else version (PPC64)
>> + {
>> + void*[19] regs = void;
>> + asm pure nothrow @nogc
>> + {
>> + "std r13, %0" : "=m" (regs[ 0]);
>> + "std r14, %0" : "=m" (regs[ 1]);
>> ...
>> to "stw 13, %0" and "std 13, %0" etc. unconditionally, or
>> to "stw %%r13, %0" etc. under some conditions?
>
> Yes, I think so. The "r13", etc. names are not accepted by gas unless you
> use the -mregnames option. It's easier to just remove the 'r’.
which would break it on Darwin.
Either that section needs to be conditional on “version Darwin” and a
second one
general - or the existing fall-back can be used for Linux (but the comments
still stand
that there are disadvantages on PPC from using the fallback).
Iain (S)
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: D build on powerpc broken (was Re: GCC 11.1 Release Candidate available from gcc.gnu.org)
2021-04-20 21:20 ` D build on powerpc broken (was Re: GCC 11.1 Release Candidate available from gcc.gnu.org) Jakub Jelinek
2021-04-20 22:02 ` Peter Bergner
@ 2021-04-20 23:38 ` William Seurer
1 sibling, 0 replies; 17+ messages in thread
From: William Seurer @ 2021-04-20 23:38 UTC (permalink / raw)
To: Jakub Jelinek, Iain Buclaw; +Cc: gcc
On 4/20/21 4:20 PM, Jakub Jelinek wrote:
> On Tue, Apr 20, 2021 at 03:27:08PM -0500, William Seurer via Gcc wrote:
>> On 4/20/21 10:24 AM, Jakub Jelinek via Gcc wrote:
>>> The first release candidate for GCC 11.1 is available from
>>>
>>> https://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420/
>>> ftp://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420
>>>
>>> and shortly its mirrors. It has been generated from git revision
>>> r11-8265-g246abba01f302eb453475b650ba839ec905be76d.
>>>
>>> I have so far bootstrapped and tested the release candidate on
>>> x86_64-linux and i686-linux. Please test it and report any issues to
>>> bugzilla.
>>>
>>> If all goes well, I'd like to release 11.1 on Tuesday, April 27th.
>>>
>> I am seeing at least one compilation failure when building the RC. Note
>> that trunk built fine for me yesterday morning.
>>
>> libtool: compile: /home/seurer/gcc/git/build/gcc-11.1.0-RC-20210420/./gcc/gdc -B/home/seurer/gcc/git/build/gcc-11.1.0-RC-20210420/./gcc/ -B/home/seurer/gcc/git/install/gcc-11.1.0-RC-20210420/powerpc64-unknown-linux-gnu/bin/ -B/home/seurer/gcc/git/install/gcc-11.1.0-RC-20210420/powerpc64-unknown-linux-gnu/lib/ -isystem /home/seurer/gcc/git/install/gcc-11.1.0-RC-20210420/powerpc64-unknown-linux-gnu/include -isystem /home/seurer/gcc/git/install/gcc-11.1.0-RC-20210420/powerpc64-unknown-linux-gnu/sys-include -fchecking=1 -fversion=Shared -Wall -frelease -ffunction-sections -fdata-sections -O2 -g -nostdinc -I /home/seurer/gcc/git/gcc-11.1.0-RC-20210420/libphobos/libdruntime -I . -c /home/seurer/gcc/git/gcc-11.1.0-RC-20210420/libphobos/libdruntime/core/thread/osthread.d -fPIC -fversion=Shared -o core/thread/.libs/osthread.o
>> /tmp/cc8zG8DV.s: Assembler messages:
>> /tmp/cc8zG8DV.s:2566: Error: unsupported relocation against r13
>> /tmp/cc8zG8DV.s:2570: Error: unsupported relocation against r14
>> /tmp/cc8zG8DV.s:2574: Error: unsupported relocation against r15
>> /tmp/cc8zG8DV.s:2578: Error: unsupported relocation against r16
>> /tmp/cc8zG8DV.s:2582: Error: unsupported relocation against r17
>> /tmp/cc8zG8DV.s:2586: Error: unsupported relocation against r18
>> /tmp/cc8zG8DV.s:2590: Error: unsupported relocation against r19
>> /tmp/cc8zG8DV.s:2594: Error: unsupported relocation against r20
>> /tmp/cc8zG8DV.s:2598: Error: unsupported relocation against r21
>> /tmp/cc8zG8DV.s:2602: Error: unsupported relocation against r22
>> /tmp/cc8zG8DV.s:2606: Error: unsupported relocation against r23
>> /tmp/cc8zG8DV.s:2610: Error: unsupported relocation against r24
>> /tmp/cc8zG8DV.s:2614: Error: unsupported relocation against r25
>> /tmp/cc8zG8DV.s:2618: Error: unsupported relocation against r26
>> /tmp/cc8zG8DV.s:2622: Error: unsupported relocation against r27
>> /tmp/cc8zG8DV.s:2626: Error: unsupported relocation against r28
>> /tmp/cc8zG8DV.s:2630: Error: unsupported relocation against r29
>> /tmp/cc8zG8DV.s:2634: Error: unsupported relocation against r30
>> /tmp/cc8zG8DV.s:2638: Error: unsupported relocation against r31
> So do we need to change
> + else version (PPC)
> + {
> + void*[19] regs = void;
> + asm pure nothrow @nogc
> + {
> + "stw r13, %0" : "=m" (regs[ 0]);
> + "stw r14, %0" : "=m" (regs[ 1]);
> ...
> + else version (PPC64)
> + {
> + void*[19] regs = void;
> + asm pure nothrow @nogc
> + {
> + "std r13, %0" : "=m" (regs[ 0]);
> + "std r14, %0" : "=m" (regs[ 1]);
> ...
> to "stw 13, %0" and "std 13, %0" etc. unconditionally, or
> to "stw %%r13, %0" etc. under some conditions?
>
> Jakub
>
I tried that and I did get a clean build. The only additional errors
seen when test were run (compared to a build yesterday) were:
FAIL: g++.dg/cpp0x/constexpr-52830.C -std=c++14 (test for excess errors)
FAIL: g++.dg/cpp0x/constexpr-52830.C -std=c++14 (test for excess errors)
FAIL: g++.dg/cpp0x/constexpr-52830.C -std=c++17 (test for excess errors)
FAIL: g++.dg/cpp0x/constexpr-52830.C -std=c++17 (test for excess errors)
FAIL: g++.dg/cpp0x/constexpr-52830.C -std=c++2a (test for excess errors)
FAIL: g++.dg/cpp0x/constexpr-52830.C -std=c++2a (test for excess errors)
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: GCC 11.1 Release Candidate available from gcc.gnu.org
2021-04-20 22:25 ` GCC 11.1 Release Candidate available from gcc.gnu.org David Edelsohn
@ 2021-04-20 23:52 ` Thomas Rodgers
2021-04-21 0:09 ` David Edelsohn
0 siblings, 1 reply; 17+ messages in thread
From: Thomas Rodgers @ 2021-04-20 23:52 UTC (permalink / raw)
To: David Edelsohn; +Cc: Jakub Jelinek, GCC Development
On 2021-04-20 15:25, David Edelsohn via Gcc wrote:
> On Tue, Apr 20, 2021 at 12:43 PM Jakub Jelinek via Gcc
> <gcc@gcc.gnu.org> wrote:
>
>> The first release candidate for GCC 11.1 is available from
>>
>> https://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420/
>> ftp://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420
>>
>> and shortly its mirrors. It has been generated from git revision
>> r11-8265-g246abba01f302eb453475b650ba839ec905be76d.
>>
>> I have so far bootstrapped and tested the release candidate on
>> x86_64-linux and i686-linux. Please test it and report any issues to
>> bugzilla.
>>
>> If all goes well, I'd like to release 11.1 on Tuesday, April 27th.
>
> As I have reported in Bugzilla, the last minute
>
> libstdc++: Refactor/cleanup of C++20 atomic wait implementation
>
> has severely regressed libstdc++ on AIX due to changes to
> bits/semaphore_base.h header.
>
> - David
I posted a patch to BZ that should disable <semaphore> entirely for AIX
(and other targets where there's not a supported implementation
strategy).
This patch isn't the best way of addressing this for a variety of
reasons, but this support is intended as experimental for GCC11 anyway.
Unfortunately I can't test it on AIX because it would seem that my ssh
keys never landed on the AIX cfarm machines.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: GCC 11.1 Release Candidate available from gcc.gnu.org
2021-04-20 23:52 ` Thomas Rodgers
@ 2021-04-21 0:09 ` David Edelsohn
2021-04-21 0:23 ` Thomas Rodgers
0 siblings, 1 reply; 17+ messages in thread
From: David Edelsohn @ 2021-04-21 0:09 UTC (permalink / raw)
To: Thomas Rodgers; +Cc: Jakub Jelinek, GCC Development
On Tue, Apr 20, 2021 at 7:52 PM Thomas Rodgers
<rodgert@appliantology.com> wrote:
>
> On 2021-04-20 15:25, David Edelsohn via Gcc wrote:
>
> On Tue, Apr 20, 2021 at 12:43 PM Jakub Jelinek via Gcc <gcc@gcc.gnu.org> wrote:
>
>
> The first release candidate for GCC 11.1 is available from
>
> https://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420/
> ftp://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420
>
> and shortly its mirrors. It has been generated from git revision
> r11-8265-g246abba01f302eb453475b650ba839ec905be76d.
>
> I have so far bootstrapped and tested the release candidate on
> x86_64-linux and i686-linux. Please test it and report any issues to
> bugzilla.
>
> If all goes well, I'd like to release 11.1 on Tuesday, April 27th.
>
>
> As I have reported in Bugzilla, the last minute
>
> libstdc++: Refactor/cleanup of C++20 atomic wait implementation
>
> has severely regressed libstdc++ on AIX due to changes to
> bits/semaphore_base.h header.
>
> - David
>
>
> I posted a patch to BZ that should disable <semaphore> entirely for AIX (and other targets where there's not a supported implementation strategy).
>
> This patch isn't the best way of addressing this for a variety of reasons, but this support is intended as experimental for GCC11 anyway. Unfortunately I can't test it on AIX because it would seem that my ssh keys never landed on the AIX cfarm machines.
I am testing the patch on an AIX system inside IBM.
But it seems that you are disabling semaphore entirely on AIX, which
is an unnecessary regression. AIX has POSIX semaphores. libstdc++
configure defines
_GLIBCXX_HAVE_POSIX_SEMAPHORE
I don't understand your comments about disabling semaphore on AIX
while the comment about experimental for GCC11 implies that this is
some new, experimental feature. I could understand disabling the
experimental feature, but not disabling all semaphore support.
Thanks, David
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: GCC 11.1 Release Candidate available from gcc.gnu.org
2021-04-21 0:09 ` David Edelsohn
@ 2021-04-21 0:23 ` Thomas Rodgers
2021-04-21 0:37 ` Thomas Rodgers
2021-04-21 0:43 ` David Edelsohn
0 siblings, 2 replies; 17+ messages in thread
From: Thomas Rodgers @ 2021-04-21 0:23 UTC (permalink / raw)
To: David Edelsohn; +Cc: Jakub Jelinek, GCC Development
On 2021-04-20 17:09, David Edelsohn wrote:
> On Tue, Apr 20, 2021 at 7:52 PM Thomas Rodgers
> <rodgert@appliantology.com> wrote:
>
>> On 2021-04-20 15:25, David Edelsohn via Gcc wrote:
>>
>> On Tue, Apr 20, 2021 at 12:43 PM Jakub Jelinek via Gcc
>> <gcc@gcc.gnu.org> wrote:
>>
>> The first release candidate for GCC 11.1 is available from
>>
>> https://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420/
>> ftp://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420
>>
>> and shortly its mirrors. It has been generated from git revision
>> r11-8265-g246abba01f302eb453475b650ba839ec905be76d.
>>
>> I have so far bootstrapped and tested the release candidate on
>> x86_64-linux and i686-linux. Please test it and report any issues to
>> bugzilla.
>>
>> If all goes well, I'd like to release 11.1 on Tuesday, April 27th.
>>
>> As I have reported in Bugzilla, the last minute
>>
>> libstdc++: Refactor/cleanup of C++20 atomic wait implementation
>>
>> has severely regressed libstdc++ on AIX due to changes to
>> bits/semaphore_base.h header.
>>
>> - David
>>
>> I posted a patch to BZ that should disable <semaphore> entirely for
>> AIX (and other targets where there's not a supported implementation
>> strategy).
>>
>> This patch isn't the best way of addressing this for a variety of
>> reasons, but this support is intended as experimental for GCC11
>> anyway. Unfortunately I can't test it on AIX because it would seem
>> that my ssh keys never landed on the AIX cfarm machines.
>
> I am testing the patch on an AIX system inside IBM.
>
> But it seems that you are disabling semaphore entirely on AIX, which
> is an unnecessary regression. AIX has POSIX semaphores. libstdc++
> configure defines
>
> _GLIBCXX_HAVE_POSIX_SEMAPHORE
>
> I don't understand your comments about disabling semaphore on AIX
> while the comment about experimental for GCC11 implies that this is
> some new, experimental feature. I could understand disabling the
> experimental feature, but not disabling all semaphore support.
>
> Thanks, David
The #error would not be hit if _GLIBCXX_HAVE_POSIX_SEMAPHORE were
defined, but it shows up in your error report.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: GCC 11.1 Release Candidate available from gcc.gnu.org
2021-04-21 0:23 ` Thomas Rodgers
@ 2021-04-21 0:37 ` Thomas Rodgers
2021-04-21 0:43 ` David Edelsohn
1 sibling, 0 replies; 17+ messages in thread
From: Thomas Rodgers @ 2021-04-21 0:37 UTC (permalink / raw)
To: David Edelsohn; +Cc: Jakub Jelinek, GCC Development
On 2021-04-20 17:23, Thomas Rodgers wrote:
> On 2021-04-20 17:09, David Edelsohn wrote:
>
> On Tue, Apr 20, 2021 at 7:52 PM Thomas Rodgers
> <rodgert@appliantology.com> wrote:
>
> On 2021-04-20 15:25, David Edelsohn via Gcc wrote:
>
> On Tue, Apr 20, 2021 at 12:43 PM Jakub Jelinek via Gcc
> <gcc@gcc.gnu.org> wrote:
>
> The first release candidate for GCC 11.1 is available from
>
> https://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420/
> ftp://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420
>
> and shortly its mirrors. It has been generated from git revision
> r11-8265-g246abba01f302eb453475b650ba839ec905be76d.
>
> I have so far bootstrapped and tested the release candidate on
> x86_64-linux and i686-linux. Please test it and report any issues to
> bugzilla.
>
> If all goes well, I'd like to release 11.1 on Tuesday, April 27th.
>
> As I have reported in Bugzilla, the last minute
>
> libstdc++: Refactor/cleanup of C++20 atomic wait implementation
>
> has severely regressed libstdc++ on AIX due to changes to
> bits/semaphore_base.h header.
>
> - David
>
> I posted a patch to BZ that should disable <semaphore> entirely for AIX
> (and other targets where there's not a supported implementation
> strategy).
>
> This patch isn't the best way of addressing this for a variety of
> reasons, but this support is intended as experimental for GCC11 anyway.
> Unfortunately I can't test it on AIX because it would seem that my ssh
> keys never landed on the AIX cfarm machines.
> I am testing the patch on an AIX system inside IBM.
>
> But it seems that you are disabling semaphore entirely on AIX, which
> is an unnecessary regression. AIX has POSIX semaphores. libstdc++
> configure defines
>
> _GLIBCXX_HAVE_POSIX_SEMAPHORE
>
> I don't understand your comments about disabling semaphore on AIX
> while the comment about experimental for GCC11 implies that this is
> some new, experimental feature. I could understand disabling the
> experimental feature, but not disabling all semaphore support.
>
> Thanks, David
The #error would not be hit if _GLIBCXX_HAVE_POSIX_SEMAPHORE were
defined, but it shows up in your error report.
Specifically -
/tmp/GCC/powerpc-ibm-aix7.2.3.0/libstdc++-v3/include/bits/semaphore_base.h:259:
error: #error "No suitable semaphore implementation available"
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: GCC 11.1 Release Candidate available from gcc.gnu.org
2021-04-21 0:23 ` Thomas Rodgers
2021-04-21 0:37 ` Thomas Rodgers
@ 2021-04-21 0:43 ` David Edelsohn
2021-04-21 1:08 ` David Edelsohn
1 sibling, 1 reply; 17+ messages in thread
From: David Edelsohn @ 2021-04-21 0:43 UTC (permalink / raw)
To: Thomas Rodgers; +Cc: Jakub Jelinek, GCC Development
On Tue, Apr 20, 2021 at 8:23 PM Thomas Rodgers
<rodgert@appliantology.com> wrote:
>
> On 2021-04-20 17:09, David Edelsohn wrote:
>
> On Tue, Apr 20, 2021 at 7:52 PM Thomas Rodgers
> <rodgert@appliantology.com> wrote:
>
>
> On 2021-04-20 15:25, David Edelsohn via Gcc wrote:
>
> On Tue, Apr 20, 2021 at 12:43 PM Jakub Jelinek via Gcc <gcc@gcc.gnu.org> wrote:
>
>
> The first release candidate for GCC 11.1 is available from
>
> https://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420/
> ftp://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420
>
> and shortly its mirrors. It has been generated from git revision
> r11-8265-g246abba01f302eb453475b650ba839ec905be76d.
>
> I have so far bootstrapped and tested the release candidate on
> x86_64-linux and i686-linux. Please test it and report any issues to
> bugzilla.
>
> If all goes well, I'd like to release 11.1 on Tuesday, April 27th.
>
>
> As I have reported in Bugzilla, the last minute
>
> libstdc++: Refactor/cleanup of C++20 atomic wait implementation
>
> has severely regressed libstdc++ on AIX due to changes to
> bits/semaphore_base.h header.
>
> - David
>
>
> I posted a patch to BZ that should disable <semaphore> entirely for AIX (and other targets where there's not a supported implementation strategy).
>
> This patch isn't the best way of addressing this for a variety of reasons, but this support is intended as experimental for GCC11 anyway. Unfortunately I can't test it on AIX because it would seem that my ssh keys never landed on the AIX cfarm machines.
>
>
> I am testing the patch on an AIX system inside IBM.
>
> But it seems that you are disabling semaphore entirely on AIX, which
> is an unnecessary regression. AIX has POSIX semaphores. libstdc++
> configure defines
>
> _GLIBCXX_HAVE_POSIX_SEMAPHORE
>
> I don't understand your comments about disabling semaphore on AIX
> while the comment about experimental for GCC11 implies that this is
> some new, experimental feature. I could understand disabling the
> experimental feature, but not disabling all semaphore support.
>
> Thanks, David
>
>
> The #error would not be hit if _GLIBCXX_HAVE_POSIX_SEMAPHORE were defined, but it shows up in your error report.
You now have pinpointed the problem.
It's not that AIX doesn't have semaphore, but that the code previously
had a fallback that hid a bug in the macros:
#if defined _GLIBCXX_HAVE_LINUX_FUTEX && !_GLIBCXX_REQUIRE_POSIX_SEMAPHORE
// Use futex if available and didn't force use of POSIX
using __fast_semaphore = __atomic_semaphore<__detail::__platform_wait_t>;
#elif _GLIBCXX_HAVE_POSIX_SEMAPHORE
using __fast_semaphore = __platform_semaphore;
#else
using __fast_semaphore = __atomic_semaphore<ptrdiff_t>;
#endif
The problem is that libstdc++ configure defines
_GLIBCXX_HAVE_POSIX_SEMAPHORE in config.h. libstdc++ uses sed to
rewrite config.h to c++config.h and prepends _GLIBCXX_, so c++config.h
contains
#define _GLIBCXX__GLIBCXX_HAVE_POSIX_SEMAPHORE 1
And bits/semaphore_base.h is not testing that corrupted macro. Either
semaphore_base.h needs to test for the corrupted macro, or libtsdc++
configure needs to define HAVE_POSIX_SEMAPHORE without itself
prepending _GLIBCXX_ so that the c++config.h rewriting works
correctly and defines the correct macro for semaphore_base.h.
Thanks, David
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: GCC 11.1 Release Candidate available from gcc.gnu.org
2021-04-21 0:43 ` David Edelsohn
@ 2021-04-21 1:08 ` David Edelsohn
2021-04-21 2:43 ` Thomas Rodgers
2021-04-21 5:12 ` Thomas Rodgers
0 siblings, 2 replies; 17+ messages in thread
From: David Edelsohn @ 2021-04-21 1:08 UTC (permalink / raw)
To: Thomas Rodgers; +Cc: Jakub Jelinek, GCC Development
On Tue, Apr 20, 2021 at 8:43 PM David Edelsohn <dje.gcc@gmail.com> wrote:
>
> On Tue, Apr 20, 2021 at 8:23 PM Thomas Rodgers
> <rodgert@appliantology.com> wrote:
> >
> > On 2021-04-20 17:09, David Edelsohn wrote:
> >
> > On Tue, Apr 20, 2021 at 7:52 PM Thomas Rodgers
> > <rodgert@appliantology.com> wrote:
> >
> >
> > On 2021-04-20 15:25, David Edelsohn via Gcc wrote:
> >
> > On Tue, Apr 20, 2021 at 12:43 PM Jakub Jelinek via Gcc <gcc@gcc.gnu.org> wrote:
> >
> >
> > The first release candidate for GCC 11.1 is available from
> >
> > https://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420/
> > ftp://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420
> >
> > and shortly its mirrors. It has been generated from git revision
> > r11-8265-g246abba01f302eb453475b650ba839ec905be76d.
> >
> > I have so far bootstrapped and tested the release candidate on
> > x86_64-linux and i686-linux. Please test it and report any issues to
> > bugzilla.
> >
> > If all goes well, I'd like to release 11.1 on Tuesday, April 27th.
> >
> >
> > As I have reported in Bugzilla, the last minute
> >
> > libstdc++: Refactor/cleanup of C++20 atomic wait implementation
> >
> > has severely regressed libstdc++ on AIX due to changes to
> > bits/semaphore_base.h header.
> >
> > - David
> >
> >
> > I posted a patch to BZ that should disable <semaphore> entirely for AIX (and other targets where there's not a supported implementation strategy).
> >
> > This patch isn't the best way of addressing this for a variety of reasons, but this support is intended as experimental for GCC11 anyway. Unfortunately I can't test it on AIX because it would seem that my ssh keys never landed on the AIX cfarm machines.
> >
> >
> > I am testing the patch on an AIX system inside IBM.
> >
> > But it seems that you are disabling semaphore entirely on AIX, which
> > is an unnecessary regression. AIX has POSIX semaphores. libstdc++
> > configure defines
> >
> > _GLIBCXX_HAVE_POSIX_SEMAPHORE
> >
> > I don't understand your comments about disabling semaphore on AIX
> > while the comment about experimental for GCC11 implies that this is
> > some new, experimental feature. I could understand disabling the
> > experimental feature, but not disabling all semaphore support.
> >
> > Thanks, David
> >
> >
> > The #error would not be hit if _GLIBCXX_HAVE_POSIX_SEMAPHORE were defined, but it shows up in your error report.
>
> You now have pinpointed the problem.
>
> It's not that AIX doesn't have semaphore, but that the code previously
> had a fallback that hid a bug in the macros:
>
> #if defined _GLIBCXX_HAVE_LINUX_FUTEX && !_GLIBCXX_REQUIRE_POSIX_SEMAPHORE
> // Use futex if available and didn't force use of POSIX
> using __fast_semaphore = __atomic_semaphore<__detail::__platform_wait_t>;
> #elif _GLIBCXX_HAVE_POSIX_SEMAPHORE
> using __fast_semaphore = __platform_semaphore;
> #else
> using __fast_semaphore = __atomic_semaphore<ptrdiff_t>;
> #endif
>
> The problem is that libstdc++ configure defines
> _GLIBCXX_HAVE_POSIX_SEMAPHORE in config.h. libstdc++ uses sed to
> rewrite config.h to c++config.h and prepends _GLIBCXX_, so c++config.h
> contains
>
> #define _GLIBCXX__GLIBCXX_HAVE_POSIX_SEMAPHORE 1
>
> And bits/semaphore_base.h is not testing that corrupted macro. Either
> semaphore_base.h needs to test for the corrupted macro, or libtsdc++
> configure needs to define HAVE_POSIX_SEMAPHORE without itself
> prepending _GLIBCXX_ so that the c++config.h rewriting works
> correctly and defines the correct macro for semaphore_base.h.
>
> Thanks, David
By the way, you can see the bug in the macro name on any Linux system
and reproduce the failure on any Linux system if you force it to
fallback to POSIX semaphores instead of Linux Futex or atomic wait.
Thanks, David
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: GCC 11.1 Release Candidate available from gcc.gnu.org
2021-04-21 1:08 ` David Edelsohn
@ 2021-04-21 2:43 ` Thomas Rodgers
2021-04-21 5:12 ` Thomas Rodgers
1 sibling, 0 replies; 17+ messages in thread
From: Thomas Rodgers @ 2021-04-21 2:43 UTC (permalink / raw)
To: David Edelsohn; +Cc: Jakub Jelinek, GCC Development
On 2021-04-20 18:08, David Edelsohn wrote:
> On Tue, Apr 20, 2021 at 8:43 PM David Edelsohn <dje.gcc@gmail.com>
> wrote:
> On Tue, Apr 20, 2021 at 8:23 PM Thomas Rodgers
> <rodgert@appliantology.com> wrote:
> On 2021-04-20 17:09, David Edelsohn wrote:
>
> On Tue, Apr 20, 2021 at 7:52 PM Thomas Rodgers
> <rodgert@appliantology.com> wrote:
>
> On 2021-04-20 15:25, David Edelsohn via Gcc wrote:
>
> On Tue, Apr 20, 2021 at 12:43 PM Jakub Jelinek via Gcc
> <gcc@gcc.gnu.org> wrote:
>
> The first release candidate for GCC 11.1 is available from
>
> https://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420/
> ftp://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420
>
> and shortly its mirrors. It has been generated from git revision
> r11-8265-g246abba01f302eb453475b650ba839ec905be76d.
>
> I have so far bootstrapped and tested the release candidate on
> x86_64-linux and i686-linux. Please test it and report any issues to
> bugzilla.
>
> If all goes well, I'd like to release 11.1 on Tuesday, April 27th.
>
> As I have reported in Bugzilla, the last minute
>
> libstdc++: Refactor/cleanup of C++20 atomic wait implementation
>
> has severely regressed libstdc++ on AIX due to changes to
> bits/semaphore_base.h header.
>
> - David
>
> I posted a patch to BZ that should disable <semaphore> entirely for AIX
> (and other targets where there's not a supported implementation
> strategy).
>
> This patch isn't the best way of addressing this for a variety of
> reasons, but this support is intended as experimental for GCC11 anyway.
> Unfortunately I can't test it on AIX because it would seem that my ssh
> keys never landed on the AIX cfarm machines.
>
> I am testing the patch on an AIX system inside IBM.
>
> But it seems that you are disabling semaphore entirely on AIX, which
> is an unnecessary regression. AIX has POSIX semaphores. libstdc++
> configure defines
>
> _GLIBCXX_HAVE_POSIX_SEMAPHORE
>
> I don't understand your comments about disabling semaphore on AIX
> while the comment about experimental for GCC11 implies that this is
> some new, experimental feature. I could understand disabling the
> experimental feature, but not disabling all semaphore support.
>
> Thanks, David
>
> The #error would not be hit if _GLIBCXX_HAVE_POSIX_SEMAPHORE were
> defined, but it shows up in your error report.
> You now have pinpointed the problem.
>
> It's not that AIX doesn't have semaphore, but that the code previously
> had a fallback that hid a bug in the macros:
>
> #if defined _GLIBCXX_HAVE_LINUX_FUTEX &&
> !_GLIBCXX_REQUIRE_POSIX_SEMAPHORE
> // Use futex if available and didn't force use of POSIX
> using __fast_semaphore =
> __atomic_semaphore<__detail::__platform_wait_t>;
> #elif _GLIBCXX_HAVE_POSIX_SEMAPHORE
> using __fast_semaphore = __platform_semaphore;
> #else
> using __fast_semaphore = __atomic_semaphore<ptrdiff_t>;
> #endif
>
> The problem is that libstdc++ configure defines
> _GLIBCXX_HAVE_POSIX_SEMAPHORE in config.h. libstdc++ uses sed to
> rewrite config.h to c++config.h and prepends _GLIBCXX_, so c++config.h
> contains
>
> #define _GLIBCXX__GLIBCXX_HAVE_POSIX_SEMAPHORE 1
>
> And bits/semaphore_base.h is not testing that corrupted macro. Either
> semaphore_base.h needs to test for the corrupted macro, or libtsdc++
> configure needs to define HAVE_POSIX_SEMAPHORE without itself
> prepending _GLIBCXX_ so that the c++config.h rewriting works
> correctly and defines the correct macro for semaphore_base.h.
>
> Thanks, David
By the way, you can see the bug in the macro name on any Linux system
and reproduce the failure on any Linux system if you force it to
fallback to POSIX semaphores instead of Linux Futex or atomic wait.
Thanks, David
Ok, I'll see if I can get a patch out before calling it a night.
Thanks!
Tom.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: GCC 11.1 Release Candidate available from gcc.gnu.org
2021-04-21 1:08 ` David Edelsohn
2021-04-21 2:43 ` Thomas Rodgers
@ 2021-04-21 5:12 ` Thomas Rodgers
1 sibling, 0 replies; 17+ messages in thread
From: Thomas Rodgers @ 2021-04-21 5:12 UTC (permalink / raw)
To: David Edelsohn; +Cc: Jakub Jelinek, GCC Development, jwakely
[-- Attachment #1: Type: text/plain, Size: 3924 bytes --]
On 2021-04-20 18:08, David Edelsohn wrote:
> On Tue, Apr 20, 2021 at 8:43 PM David Edelsohn <dje.gcc@gmail.com>
> wrote:
> On Tue, Apr 20, 2021 at 8:23 PM Thomas Rodgers
> <rodgert@appliantology.com> wrote:
> On 2021-04-20 17:09, David Edelsohn wrote:
>
> On Tue, Apr 20, 2021 at 7:52 PM Thomas Rodgers
> <rodgert@appliantology.com> wrote:
>
> On 2021-04-20 15:25, David Edelsohn via Gcc wrote:
>
> On Tue, Apr 20, 2021 at 12:43 PM Jakub Jelinek via Gcc
> <gcc@gcc.gnu.org> wrote:
>
> The first release candidate for GCC 11.1 is available from
>
> https://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420/
> ftp://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420
>
> and shortly its mirrors. It has been generated from git revision
> r11-8265-g246abba01f302eb453475b650ba839ec905be76d.
>
> I have so far bootstrapped and tested the release candidate on
> x86_64-linux and i686-linux. Please test it and report any issues to
> bugzilla.
>
> If all goes well, I'd like to release 11.1 on Tuesday, April 27th.
>
> As I have reported in Bugzilla, the last minute
>
> libstdc++: Refactor/cleanup of C++20 atomic wait implementation
>
> has severely regressed libstdc++ on AIX due to changes to
> bits/semaphore_base.h header.
>
> - David
>
> I posted a patch to BZ that should disable <semaphore> entirely for AIX
> (and other targets where there's not a supported implementation
> strategy).
>
> This patch isn't the best way of addressing this for a variety of
> reasons, but this support is intended as experimental for GCC11 anyway.
> Unfortunately I can't test it on AIX because it would seem that my ssh
> keys never landed on the AIX cfarm machines.
>
> I am testing the patch on an AIX system inside IBM.
>
> But it seems that you are disabling semaphore entirely on AIX, which
> is an unnecessary regression. AIX has POSIX semaphores. libstdc++
> configure defines
>
> _GLIBCXX_HAVE_POSIX_SEMAPHORE
>
> I don't understand your comments about disabling semaphore on AIX
> while the comment about experimental for GCC11 implies that this is
> some new, experimental feature. I could understand disabling the
> experimental feature, but not disabling all semaphore support.
>
> Thanks, David
>
> The #error would not be hit if _GLIBCXX_HAVE_POSIX_SEMAPHORE were
> defined, but it shows up in your error report.
> You now have pinpointed the problem.
>
> It's not that AIX doesn't have semaphore, but that the code previously
> had a fallback that hid a bug in the macros:
>
> #if defined _GLIBCXX_HAVE_LINUX_FUTEX &&
> !_GLIBCXX_REQUIRE_POSIX_SEMAPHORE
> // Use futex if available and didn't force use of POSIX
> using __fast_semaphore =
> __atomic_semaphore<__detail::__platform_wait_t>;
> #elif _GLIBCXX_HAVE_POSIX_SEMAPHORE
> using __fast_semaphore = __platform_semaphore;
> #else
> using __fast_semaphore = __atomic_semaphore<ptrdiff_t>;
> #endif
>
> The problem is that libstdc++ configure defines
> _GLIBCXX_HAVE_POSIX_SEMAPHORE in config.h. libstdc++ uses sed to
> rewrite config.h to c++config.h and prepends _GLIBCXX_, so c++config.h
> contains
>
> #define _GLIBCXX__GLIBCXX_HAVE_POSIX_SEMAPHORE 1
>
> And bits/semaphore_base.h is not testing that corrupted macro. Either
> semaphore_base.h needs to test for the corrupted macro, or libtsdc++
> configure needs to define HAVE_POSIX_SEMAPHORE without itself
> prepending _GLIBCXX_ so that the c++config.h rewriting works
> correctly and defines the correct macro for semaphore_base.h.
>
> Thanks, David
By the way, you can see the bug in the macro name on any Linux system
and reproduce the failure on any Linux system if you force it to
fallback to POSIX semaphores instead of Linux Futex or atomic wait.
Thanks, David
I think the attached patch (also in BZ) addresses the issue in
bits/semaphore_base.h, but I'm going to defer to Jonathan on why the
macro name is being transformed incorrectly in the first place.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-libstdc-Work-around-for-PR100164.patch --]
[-- Type: text/x-diff; name=0001-libstdc-Work-around-for-PR100164.patch, Size: 4037 bytes --]
From b1892fe84fb702ff3085eee8a062bc8606e5566a Mon Sep 17 00:00:00 2001
From: Thomas Rodgers <rodgert@twrodgers.com>
Date: Tue, 20 Apr 2021 21:56:21 -0700
Subject: [PATCH] [libstdc++] Work around for PR100164
As dje.gcc@gmail.com pointed out, the _GLIBCXX_HAVE_POSIX_SEMAPHORE
macro is being munged into _GLIBCXX__GLIBCXX_HAVE_POSIX_SEMAPHORE. This
caused the detection logic in bits/semaphore_base.h to not define
__platform_semaphore. Fixing this uncovered the issue that
__platform_semaphore::_M_try_wait() was missing. This patch works around
the former issue and addresses the latter issue.
libstdc++-v3/ChangeLog:
* include/bits/semaphore_base.h: Define
__platform_semaphore::_M_try_wait(), temporarily adjust
detection macro to reflect the actual name being generated
during configuration.
* testsuite/30_threads/semaphore/try_acquire_posix.cc: Force
use of Posix semaphores if available and always run the test.
---
libstdc++-v3/include/bits/semaphore_base.h | 27 ++++++++++++++++---
.../30_threads/semaphore/try_acquire_posix.cc | 15 ++++++++---
2 files changed, 36 insertions(+), 6 deletions(-)
diff --git a/libstdc++-v3/include/bits/semaphore_base.h b/libstdc++-v3/include/bits/semaphore_base.h
index 7e3235d182e..5c687bfae6f 100644
--- a/libstdc++-v3/include/bits/semaphore_base.h
+++ b/libstdc++-v3/include/bits/semaphore_base.h
@@ -38,7 +38,8 @@
#include <ext/numeric_traits.h>
#endif // __cpp_lib_atomic_wait
-#ifdef _GLIBCXX_HAVE_POSIX_SEMAPHORE
+#ifdef _GLIBCXX__GLIBCXX_HAVE_POSIX_SEMAPHORE
+// #ifdef _GLIBCXX_HAVE_POSIX_SEMAPHORE
# include <limits.h>
# include <semaphore.h>
#endif
@@ -50,7 +51,8 @@ namespace std _GLIBCXX_VISIBILITY(default)
{
_GLIBCXX_BEGIN_NAMESPACE_VERSION
-#ifdef _GLIBCXX_HAVE_POSIX_SEMAPHORE
+#ifdef _GLIBCXX__GLIBCXX_HAVE_POSIX_SEMAPHORE
+// #ifdef _GLIBCXX_HAVE_POSIX_SEMAPHORE
struct __platform_semaphore
{
using __clock_t = chrono::system_clock;
@@ -86,6 +88,24 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
}
}
+ _GLIBCXX_ALWAYS_INLINE bool
+ _M_try_acquire() noexcept
+ {
+ for (;;)
+ {
+ auto __err = sem_trywait(&_M_semaphore);
+ if (__err && (errno == EINTR))
+ continue;
+ else if (__err && (errno == EAGAIN))
+ return false;
+ else if (__err)
+ std::terminate();
+ else
+ break;
+ }
+ return true;
+ }
+
_GLIBCXX_ALWAYS_INLINE void
_M_release(std::ptrdiff_t __update) noexcept
{
@@ -253,7 +273,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
// use of Posix semaphores (sem_t). Doing so however, alters the ABI.
#if defined __cpp_lib_atomic_wait && !_GLIBCXX_REQUIRE_POSIX_SEMAPHORE
using __semaphore_impl = __atomic_semaphore;
-#elif _GLIBCXX_HAVE_POSIX_SEMAPHORE
+#elif _GLIBCXX__GLIBCXX_HAVE_POSIX_SEMAPHORE
+// #elif _GLIBCXX_HAVE_POSIX_SEMAPHORE
using __semaphore_impl = __platform_semaphore;
#else
# error "No suitable semaphore implementation available"
diff --git a/libstdc++-v3/testsuite/30_threads/semaphore/try_acquire_posix.cc b/libstdc++-v3/testsuite/30_threads/semaphore/try_acquire_posix.cc
index 97e386f7b76..54d67652950 100644
--- a/libstdc++-v3/testsuite/30_threads/semaphore/try_acquire_posix.cc
+++ b/libstdc++-v3/testsuite/30_threads/semaphore/try_acquire_posix.cc
@@ -20,8 +20,16 @@
// { dg-require-effective-target pthread }
// { dg-require-gthreads "" }
+#include <atomic>
+#ifdef _GLIBCXX__GLIBCXX_HAVE_POSIX_SEMAPHORE
+// #ifdef _GLIBCXX_HAVE_POSIX_SEMAPHORE
+#define _GLIBCXX_REQUIRE_POSIX_SEMAPHORE 1
+#endif
+
#include <semaphore>
-#ifdef _GLIBCXX_HAVE_POSIX_SEMAPHORE
+
+#ifdef _GLIBCXX__GLIBCXX_HAVE_POSIX_SEMAPHORE
+// #ifdef _GLIBCXX_HAVE_POSIX_SEMAPHORE
#include <chrono>
#include <thread>
#include <atomic>
@@ -139,11 +147,12 @@ void test04()
b.wait(1);
}
-#endif
+#endif // _GLIBCXX_HAVE_POSIX_SEMAPHORE
int main()
{
-#ifdef _GLIBCXX_HAVE_POSIX_SEMAPHORE
+#ifdef _GLIBCXX__GLIBCXX_HAVE_POSIX_SEMAPHORE
+// #ifdef _GLIBCXX_HAVE_POSIX_SEMAPHORE
test01();
test02();
test03();
--
2.30.2
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2021-04-21 5:12 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-04-20 15:24 GCC 11.1 Release Candidate available from gcc.gnu.org Jakub Jelinek
2021-04-20 20:27 ` William Seurer
2021-04-20 21:05 ` Andreas Schwab
2021-04-20 21:20 ` D build on powerpc broken (was Re: GCC 11.1 Release Candidate available from gcc.gnu.org) Jakub Jelinek
2021-04-20 22:02 ` Peter Bergner
2021-04-20 22:47 ` ibuclaw
2021-04-20 22:49 ` Iain Sandoe
2021-04-20 23:38 ` William Seurer
2021-04-20 22:25 ` GCC 11.1 Release Candidate available from gcc.gnu.org David Edelsohn
2021-04-20 23:52 ` Thomas Rodgers
2021-04-21 0:09 ` David Edelsohn
2021-04-21 0:23 ` Thomas Rodgers
2021-04-21 0:37 ` Thomas Rodgers
2021-04-21 0:43 ` David Edelsohn
2021-04-21 1:08 ` David Edelsohn
2021-04-21 2:43 ` Thomas Rodgers
2021-04-21 5:12 ` Thomas Rodgers
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).