s390 port

[Paul Edwards via Gcc]

Hi Ulrich.

Sorry for the necro - things happen slowly Down Under. :-)

Anyway, I am helping someone with their public domain
project, UDOS - https://github.com/udos-project/udos

(just a hobby, won't be big and professional like Linux)

We got the IPL process in place on ESA/390, and then
I decided that the next thing to do would be to switch
to z/Arch so that we could get rid of the AMODE 31
architectural limit on 32-bit programs.

It all worked fine, and we were able to use GCC 11 to
target S/390 and use the -m31 to generate 32-bit code,
run it under z/Arch as AM64, sort of making it the
equivalent of AM32. Really it is the equivalent of
AM-infinity, and there's the rub - GCC 11 is generating
negative indexes, which cause memory above 4 GiB
to be accessed (instead of wrapping at 2/4 GiB), which
of course fails.

Do you have any idea how to stop the S/390 target
from generating negative indexes? I thought the
solution might be to change the Pmode to DImode
even for non-TARGET64, but as you can see here:

http://www.pdos.org/gccfail.png

we got an internal compile error - maximum number
of generated reload insns per insn achieved (90).

I then tried changing the other SImode reference
(CASE_VECTOR_MODE) to DImode too, but that gave
the same internal error.

Here is what the failure looks like (see the large R4):

01:28:27 PSW=00042001 8000 5870 INST=A73A0001 AHI   3,1 
add_halfword_immediate
01:28:27 R0=01FD R1=00E2 R2=0009E579 
R3=80B2
01:28:27 R4=F000 R5=0001E5C8 R6=7FFF 
R7=2000
01:28:27 R8=201F R9= RA=80B0 
RB=80B2
01:28:27 RC=0009E580 RD=8138 RE=7B4C 
RF=0001E4E4
01:28:27 PSW=00042001 8000 5874 INST=42142FFF STC 
1,4095(4,2)store_character

01:28:27 R:00010009E578: Translation exception 0005
01:28:27 R0=01FD R1=00E2 R2=0009E579 
R3=80B3
01:28:27 R4=F000 R5=0001E5C8 R6=7FFF 
R7=2000
01:28:27 R8=201F R9= RA=80B0 
RB=80B2
01:28:27 RC=0009E580 RD=8138 RE=7B4C 
RF=0001E4E4

01:28:27 HHCCP014I CPU: Addressing exception CODE=0005 ILC=4
01:28:27 PSW=00042001 8000 5878 INST=42142FFF STC 
1,4095(4,2)store_character

01:28:27 R:00010009E578: Translation exception 0005
01:28:27 R0=01FD R1=00E2 R2=0009E579 
R3=80B3
01:28:27 R4=F000 R5=0001E5C8 R6=7FFF 
R7=2000
01:28:27 R8=201F R9= RA=80B0 
RB=80B2
01:28:27 RC=0009E580 RD=8138 RE=7B4C 
RF=0001E4E4
01:28:27 HHCCP043I Wait state PSW loaded: PSW=00060001 8000 
0444

01:28:40 quit
01:28:40 HHCIN900I Begin Hercules shutdown

Any idea what we can do?

Thanks. Paul.




-Original Message- 
From: Ulrich Weigand

Sent: Saturday, June 6, 2009 1:20 AM
To: Paul Edwards
Cc: gcc@gcc.gnu.org
Subject: Re: i370 port

Paul Edwards wrote:


In addition, that code has been ported to GCC 3.4.6, which is now
working as a cross-compiler at least.  It's still some months away
from working natively though.  It takes a lot of effort to convert
the Posix-expecting GCC compiler into C90 compliance.  This has
been done though, in a way that has minimal code changes to the
GCC mainline.


You're referring to building GCC for a non-Posix *host*, right?
I assume those changes are not (primarily) in the back-end, but
throughout GCC common code?


Yes, I'm aware that there is an S/390 port, but it isn't EBCDIC, isn't
HLASM, isn't 370, isn't C90, isn't MVS.  It may well be possible to
change all those things, and I suspect that in a few years from now
I may be sending another message asking what I need to do to get
all my changes to the s390 target into the s390 target.  At that time,
I suspect there will be a lot of objection to "polluting" the s390 target
with all those "unnecessary" things.


Actually, I would really like to see the s390 target optionally support
the MVS ABI and HLASM assembler format, so I wouldn't have any objection
to patches that add these features ...

I understand current GCC supports various source and target character
sets a lot better out of the box, so it may be EBCDIC isn't even an
issue any more.   If there are other problems related to MVS host
support, I suppose those would need to be fixed in common code anyway,
no matter whether the s390 or i370 back-ends are used.

The only point in your list I'm sceptical about is 370 architecture
support -- I don't quite see why this is still useful today (the s390
port does require at a minimum a S/390 G2 with the branch relative
instructions ... but those have been around for 

Re: s390 port

[Paul Edwards via Gcc]

Hi Ulrich.

Below is the output as text.

Thanks. Paul.



make  all-recursive
make[1]: Entering directory '/home/robertapengelly/Desktop/UDOS'
Making all in kernel
make[2]: Entering directory '/home/robertapengelly/Desktop/UDOS/kernel'
depbase=`echo irq.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
s390-linux-gcc -DHAVE_CONFIG_H -I. -I.. -ffreestanding -fno-stack-protector 
-pipe -Wall -Wextra -pedantic -Wshadow -Wpointer-arith -Wcast-align -Wwrite-strings 
-Wstrict-prototypes -Wmissing-declarations -Wdouble-promotion -Wredundant-decls 
-Wnested-externs -Winline -Wconversion -fexec-charset=IBM-1047 -O2 -m31 -g  
-MT irq.o -MD -MP -MF $depbase.Tpo -c -o irq.o irq.c &&\

mv -f $depbase.Tpo $depbase.Po
during RTL pass: reload
In file included from irq.c:3:
./panic.h: In function ‘kpanic’:
./panic.h:21:1: internal compiler error: maximum number of generated reload 
insns per insn achieved (90)

  21 | }
 | ^
0xce67fc lra_constraints(bool)
   ../../gcc/gcc/lra-constraints.c:5091
0xcd2fa2 lra(_IO_FILE*)
   ../../gcc/gcc/lra.c:2336
0xc8a2f9 do_reload
   ../../gcc/gcc/ira.c:5932
0xc8a2f9 execute
   ../../gcc/gcc/ira.c:6118
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[2]: *** [Makefile:418: irq.o] Error 1
make[2]: Leaving directory '/home/robertapengelly/Desktop/UDOS/kernel'
make[1]: *** [Makefile:406: all-recursive] Error 1
make[1]: Leaving directory '/home/robertapengelly/Desktop/UDOS'
make: *** [Makefile:326: all] Error 2




-Original Message- 
From: Paul Edwards

Sent: Thursday, September 2, 2021 6:15 PM
To: Ulrich Weigand
Cc: gcc@gcc.gnu.org
Subject: s390 port

Hi Ulrich.

Sorry for the necro - things happen slowly Down Under. :-)

Anyway, I am helping someone with their public domain
project, UDOS - https://github.com/udos-project/udos

(just a hobby, won't be big and professional like Linux)

We got the IPL process in place on ESA/390, and then
I decided that the next thing to do would be to switch
to z/Arch so that we could get rid of the AMODE 31
architectural limit on 32-bit programs.

It all worked fine, and we were able to use GCC 11 to
target S/390 and use the -m31 to generate 32-bit code,
run it under z/Arch as AM64, sort of making it the
equivalent of AM32. Really it is the equivalent of
AM-infinity, and there's the rub - GCC 11 is generating
negative indexes, which cause memory above 4 GiB
to be accessed (instead of wrapping at 2/4 GiB), which
of course fails.

Do you have any idea how to stop the S/390 target
from generating negative indexes? I thought the
solution might be to change the Pmode to DImode
even for non-TARGET64, but as you can see here:

http://www.pdos.org/gccfail.png

we got an internal compile error - maximum number
of generated reload insns per insn achieved (90).

I then tried changing the other SImode reference
(CASE_VECTOR_MODE) to DImode too, but that gave
the same internal error.

Here is what the failure looks like (see the large R4):

01:28:27 PSW=00042001 8000 5870 INST=A73A0001 AHI   3,1
add_halfword_immediate
01:28:27 R0=01FD R1=00E2 R2=0009E579
R3=80B2
01:28:27 R4=F000 R5=0001E5C8 R6=7FFF
R7=2000
01:28:27 R8=201F R9= RA=80B0
RB=80B2
01:28:27 RC=0009E580 RD=8138 RE=7B4C
RF=0001E4E4
01:28:27 PSW=00042001 8000 5874 INST=42142FFF STC
1,4095(4,2)store_character
01:28:27 R:00010009E578: Translation exception 0005
01:28:27 R0=01FD R1=00E2 R2=0009E579
R3=80B3
01:28:27 R4=F000 R5=0001E5C8 R6=7FFF
R7=2000
01:28:27 R8=201F R9= RA=80B0
RB=80B2
01:28:27 RC=0009E580 RD=8138 RE=7B4C
RF=0001E4E4
01:28:27 HHCCP014I CPU: Addressing exception CODE=0005 ILC=4
01:28:27 PSW=00042001 8000 5878 INST=42142FFF STC
1,4095(4,2)store_character
01:28:27 R:00010009E578: Translation exception 0005
01:28:27 R0=01FD R1=00E2 R2=0009E579
R3=80B3
01:28:27 R4=F000 R5=0001E5C8 R6=7FFF
R7=2000
01:28:27 R8=201F R9= RA=80B0
RB=80B2
01:28:27 RC=0009E580 RD=8138 RE=7B4C
RF=0001E4E4
01:28:27 HHCCP043I Wait state PSW loaded: PSW=00060001 8000
0444
01:28:40 quit
01:28:40 HHCIN900I Begin Hercules shutdown

Any idea what we can do?

Thanks. Paul.




-Original Message- 
From: Ulrich Weigand

Sent: Saturday, June 6, 2009 1:20 AM
To: Paul Edwards
Cc: gcc@gcc.gnu.org
Subject: Re: i370 port

Paul Edwards wrote:


In addit

Re: s390 port

[Paul Edwards via Gcc]

Hi Ulrich.

I just checked my copy of s390.md and I don’t see
LA being used for arithmetic.

If your copy of s390.md is using LA for arithmetic
then would it be possible to have an option to
use a normal mathematics instruction instead of
LA?

Do you have any more examples besides LA being
used for maths instead of a proper maths instruction?

Also, I just realized – if GCC is using LA for maths
for 32-bit registers, then values will be limited to
2 GiB instead of 4 GiB for unsigned, but that is not
the case.

BFN. Paul.




From: Ulrich Weigand 
Sent: Friday, September 3, 2021 12:53 AM
To: Paul Edwards 
Cc: gcc@gcc.gnu.org ; Ulrich Weigand 
Subject: Re: s390 port

"Paul Edwards"  wrote on 02.09.2021 16:50:35:

> Could you give me an example of an instruction
> generated by –m31 that is not expected to work
> on an AM64 system?

Well, everything related to address computation, of course.

For example, GCC may use LA on -m31 to implement a
31-bit addition, while it may use LA on -m64 to
implement a 64-bit addition.

Bye,
Ulrich

Re: s390 port

[Ulrich Weigand via Gcc]

Hi Paul,

"Paul Edwards"  wrote on 02.09.2021 10:15:44:

> We got the IPL process in place on ESA/390, and then
> I decided that the next thing to do would be to switch
> to z/Arch so that we could get rid of the AMODE 31
> architectural limit on 32-bit programs.
>
> It all worked fine, and we were able to use GCC 11 to
> target S/390 and use the -m31 to generate 32-bit code,
> run it under z/Arch as AM64, sort of making it the
> equivalent of AM32. Really it is the equivalent of
> AM-infinity, and there's the rub - GCC 11 is generating
> negative indexes, which cause memory above 4 GiB
> to be accessed (instead of wrapping at 2/4 GiB), which
> of course fails.

Can you elaborate what exactly your goals are?  The point
of the -m31 vs. -m64 option is exactly to match the
AMODE 31 vs. AMODE 64 hardware distinction, so trying to
run -m31 code in AMODE 64 is not supposed to work.

Bye,
Ulrich

Re: s390 port

[Ulrich Weigand via Gcc]

Hi Paul,

> I just checked my copy of s390.md and I don’t see
> LA being used for arithmetic.

This would be the "*la_31" and "*la_31_and" patterns.
(Note that the addition is implicit in the use of
the "address_operand" constraint.)

> If your copy of s390.md is using LA for arithmetic
> then would it be possible to have an option to
> use a normal mathematics instruction instead of
> LA?

LA was just an example.  It doesn't usually make sense
to reason on an "use instruction X" basis, that's not
how compiler optimizations work.  You rather start with
a set of semantic invariants and then make sure those
are preserved through all transformations.

Therefore again my question, what is the actual goal
you want to achieve?   I'm still not sure I understand
that ...

> Also, I just realized – if GCC is using LA for maths
> for 32-bit registers, then values will be limited to
> 2 GiB instead of 4 GiB for unsigned, but that is not
> the case.

That's why GCC makes sure to only use the instruction
when a 31-bit addition is wanted.  This can be the
case either when GCC can prove that the involved
operands are pointer values (which are by definition
restricted to 31-bit values in -m31 mode), or when
there is an explict 31-bit addition (using e.g. an
& 0x7fff) in the source code.

Bye,
Ulrich

Re: s390 port

[Ulrich Weigand via Gcc]

"Paul Edwards"  wrote on 02.09.2021 16:50:35:

> Could you give me an example of an instruction
> generated by –m31 that is not expected to work
> on an AM64 system?

Well, everything related to address computation, of course.

For example, GCC may use LA on -m31 to implement a
31-bit addition, while it may use LA on -m64 to
implement a 64-bit addition.

Bye,
Ulrich

Re: s390 port

[Paul Edwards via Gcc]

>> I just checked my copy of s390.md and I don’t see
>> LA being used for arithmetic.

> This would be the "*la_31" and "*la_31_and" patterns.
Sorry, I did a grep for “LA”, forgetting that
s390.md doesn’t use uppercase instructions.

> (Note that the addition is implicit in the use of
> the "address_operand" constraint.)

If it is an address we are talking about, then that LA
instruction is going to work perfectly fine in AM24,
AM31 and AM64, and in the AM64 case it is going
to be the equivalent of AM32, so maybe the s390
port could have a “-m32” option for use when
running 32-bit applications as AM64?

>> If your copy of s390.md is using LA for arithmetic
>> then would it be possible to have an option to
>> use a normal mathematics instruction instead of
>> LA?

> LA was just an example.  It doesn't usually make sense
> to reason on an "use instruction X" basis, that's not
> how compiler optimizations work.  You rather start with
> a set of semantic invariants and then make sure those
> are preserved through all transformations.

Ok, that’s above my head.

> Therefore again my question, what is the actual goal
> you want to achieve?   I'm still not sure I understand
> that ...

I would like to know what is required to implement
“-m32” in the S/390 target. I realize that z/Arch
doesn’t have a specific AM32, but I don’t need a
specific AM32. What would actually happen if you
coded a “-m32” and then ran it in an AM64
environment?

My experiments show “with one single problem
discovered so far, actually –m31 and –m32 are
identical and work fine under AM64”.

>> Also, I just realized – if GCC is using LA for maths
>> for 32-bit registers, then values will be limited to
>> 2 GiB instead of 4 GiB for unsigned, but that is not
>> the case.

> That's why GCC makes sure to only use the instruction
> when a 31-bit addition is wanted.  This can be the
> case either when GCC can prove that the involved
> operands are pointer values (which are by definition
> restricted to 31-bit values in -m31 mode)

The compiler doesn’t create a restriction there.
It just generates a simple LA and it works
differently depending on whether it is AM24/31/64.

> or when
> there is an explict 31-bit addition (using e.g. an
> & 0x7fff) in the source code.

Ok, thankyou, this is what I needed to know.
I believe I would like to have a –m32 that
drops this test. I don’t want GCC to assume
that such an AND instruction can be implemented
with the use of the “LA” instruction. I want
to see an explicit “N” instruction used. Can
I have this as part of “-m32”?

Thanks. Paul.

Re: s390 port

[Paul Edwards via Gcc]

Hi Ulrich.

Thanks a lot for your reply.

Could you give me an example of an instruction
generated by –m31 that is not expected to work
on an AM64 system?

E.g. the 32-bit

LR R2,R3

will definitely work on AM64.

So what specifically won’t work? How many different
things won’t work?

Thanks. Paul.




From: Ulrich Weigand 
Sent: Friday, September 3, 2021 12:34 AM
To: Paul Edwards 
Cc: gcc@gcc.gnu.org ; Ulrich Weigand 
Subject: Re: s390 port

Hi Paul,

"Paul Edwards"  wrote on 02.09.2021 10:15:44:

> We got the IPL process in place on ESA/390, and then
> I decided that the next thing to do would be to switch
> to z/Arch so that we could get rid of the AMODE 31
> architectural limit on 32-bit programs.
> 
> It all worked fine, and we were able to use GCC 11 to
> target S/390 and use the -m31 to generate 32-bit code,
> run it under z/Arch as AM64, sort of making it the
> equivalent of AM32. Really it is the equivalent of
> AM-infinity, and there's the rub - GCC 11 is generating
> negative indexes, which cause memory above 4 GiB
> to be accessed (instead of wrapping at 2/4 GiB), which
> of course fails.

Can you elaborate what exactly your goals are?  The point
of the -m31 vs. -m64 option is exactly to match the
AMODE 31 vs. AMODE 64 hardware distinction, so trying to
run -m31 code in AMODE 64 is not supposed to work.

Bye,
Ulrich

Re: s390 port

[Ulrich Weigand via Gcc]

"Paul Edwards"  wrote on 02.09.2021 17:26:25:

> > Therefore again my question, what is the actual goal
> > you want to achieve?   I'm still not sure I understand
> > that ...
> I would like to know what is required to implement
> “-m32” in the S/390 target. I realize that z/Arch
> doesn’t have a specific AM32, but I don’t need a
> specific AM32. What would actually happen if you
> coded a “-m32” and then ran it in an AM64
> environment?

That depends on what that would actually do.  I'm still not
quite sure what the actual requirements are.

Is this about supporting a 4GB address space instead
of a 2GB space?  (I'm not aware of that being used
anywhere currently.)

Is it about supporting a 32-bit pointer type in an
otherwise AM64 environment?  (This is already used
by the TPF target, but the 32-bit pointer will still
refer to a 2GB address space.)

Is it something else?

In either case, what is the actual benefit of that mode?
(I.e. what benefit would justify the effort to implement it?)


> >> Also, I just realized – if GCC is using LA for maths
> >> for 32-bit registers, then values will be limited to
> >> 2 GiB instead of 4 GiB for unsigned, but that is not
> >> the case.
>
> > That's why GCC makes sure to only use the instruction
> > when a 31-bit addition is wanted.  This can be the
> > case either when GCC can prove that the involved
> > operands are pointer values (which are by definition
> > restricted to 31-bit values in -m31 mode)
>
> The compiler doesn’t create a restriction there.
> It just generates a simple LA and it works
> differently depending on whether it is AM24/31/64.

It is the other way around.  The compiler knows
exactly how the LA instruction behaves in hardware,
and will use the instruction whenever that behavior
matches the semantics of (a part of) the program.
Since the behavior of the instruction differs based
on the addressing mode, the compiler will have to
know which mode the executable will be running in.


Currently, the -m31/-m64 switch basically changes several
things (at the same time):
- the assumption on which AM the executable will run in
- the (used) size of a general-purpose register
- the (default) size of a pointer type
- ABI (function calling convention) details

In theory, it would be possible to split this apart
into distinct features, so that it would be possible
to implement a mode where you can have code that uses
32-bit pointers but is running in AM64 (which would
then support a 4 GB address space).

Is this what you mean by an "-m32" mode?


Basically, this would involve looking at all uses of
the TARGET_64BIT macro in the back-end and determine
which of them actually depend on which of the above
features, and disentangle it accordingly.

I guess that would be possible, but it requires a
nontrivial effort.


Bye,
Ulrich

Re: s390 port

[Paul Edwards via Gcc]

Hi Ulrich. Thanks for your detailed reply.
>> > Therefore again my question, what is the actual goal
>> > you want to achieve?   I'm still not sure I understand
>> > that ...

>> I would like to know what is required to implement
>> “-m32” in the S/390 target. I realize that z/Arch
>> doesn’t have a specific AM32, but I don’t need a
>> specific AM32. What would actually happen if you
>> coded a “-m32” and then ran it in an AM64
>> environment?

> That depends on what that would actually do.  I'm still not
> quite sure what the actual requirements are.

> Is this about supporting a 4GB address space instead
> of a 2GB space?
Yes, correct.
> (I'm not aware of that being used anywhere currently.)
I’m about to use it. I just need to get past
the problem with negative indexes being used,
and I need your help.

> Is it about supporting a 32-bit pointer type in an
> otherwise AM64 environment?  (This is already used
> by the TPF target, but the 32-bit pointer will still
> refer to a 2GB address space.)

Yes, all pointers will be 32-bit – a normal 32-bit system.

> Is it something else?

Nope, you got it.

> In either case, what is the actual benefit of that mode?
> (I.e. what benefit would justify the effort to implement it?)

The “legacy” environment of z/Linux etc would be 32-bit
instead of 31-bit. IBM’s reputation will be restored. IBM
will have the best architecture on the planet. Better than
x64 because no mode switch is required shifting between
32-bit and 64-bit applications. All run as AM64 = AM-infinity.

>> >> Also, I just realized – if GCC is using LA for maths
>> >> for 32-bit registers, then values will be limited to
>> >> 2 GiB instead of 4 GiB for unsigned, but that is not
>> >> the case.
> 
>> > That's why GCC makes sure to only use the instruction
>> > when a 31-bit addition is wanted.  This can be the
>> > case either when GCC can prove that the involved
>> > operands are pointer values (which are by definition
>> > restricted to 31-bit values in -m31 mode)
>  
>> The compiler doesn’t create a restriction there.
>> It just generates a simple LA and it works
>> differently depending on whether it is AM24/31/64.

> It is the other way around.  The compiler knows
> exactly how the LA instruction behaves in hardware,
> and will use the instruction whenever that behavior
> matches the semantics of (a part of) the program.
> Since the behavior of the instruction differs based
> on the addressing mode, the compiler will have to
> know which mode the executable will be running in.

The i370 port produces code that works in AM24, AM31,
AM32 and AM64 (except for negative indexes). I’m surprised
the s390 port doesn’t too. As far as I can remember from
using IBM C, it supports execution in any AMODE too.

> Currently, the -m31/-m64 switch basically changes several
> things (at the same time)
> - the assumption on which AM the executable will run in 
> - the (used) size of a general-purpose register
> - the (default) size of a pointer type
> - ABI (function calling convention) details

> In theory, it would be possible to split this apart
> into distinct features, so that it would be possible
> to implement a mode where you can have code that uses
> 32-bit pointers but is running in AM64 (which would
> then support a 4 GB address space).

> Is this what you mean by an "-m32" mode?

Yes, correct.

> Basically, this would involve looking at all uses of
> the TARGET_64BIT macro in the back-end and determine
> which of them actually depend on which of the above
> features, and disentangle it accordingly.

> I guess that would be possible, but it requires a
> nontrivial effort.

I’d like to approach the problem from the other
direction – what modifications are required to
be made to “-m31” so that it does “-m32” instead?
I’m happy to simply retire “-m31”, but I don’t care
if both exist.

If “-m31” is retired, and made an alias for “-m32”,
my guess is that 20 lines of code need to be changed.

The most important thing is to stop generating
negative indexes.

ie if you have “char *p” and you go p[-1] I don’t
want 0x generated as an index. I instead
want a subtraction done.

I was under the impression that this was governed
by the Pmode – whether it was set to DImode or
SImode. But I tried forcing Pmode to DImode, even
for “–m31”, but it gave an internal error, which I
showed you already.

What am I missing?

Thanks. Paul.

Re: s390 port

[Andreas Schwab]

On Sep 03 2021, Paul Edwards via Gcc wrote:

> The “legacy” environment of z/Linux etc would be 32-bit
> instead of 31-bit. IBM’s reputation will be restored. IBM
> will have the best architecture on the planet. Better than
> x64 because no mode switch is required shifting between
> 32-bit and 64-bit applications. All run as AM64 = AM-infinity.

That looks like -mabi=ilp32 on aarch64, or -mx32 on x86_64.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

gcc-9-20210902 is now available

[GCC Administrator via Gcc]

Snapshot gcc-9-20210902 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/9-20210902/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 9 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-9 
revision 12b86d68065cf4d6e990ce92482f79b51d1e4899

You'll find:

 gcc-9-20210902.tar.xzComplete GCC

  SHA256=2488e6d85e7b62f71cdf15ba68fe33a0d78cd7178bfaffb34c1d02e89605c937
  SHA1=a78646f7e39b469a44b69fd5b79a75bc76058c0c

Diffs from 9-20210826 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-9
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.