Re: ☠ Buildbot (Sourceware): gcc - failed configure (failure) (master)
On Sun, Jan 29, 2023 at 07:49:35PM +, Sam James via Fortran wrote: > > > > On 29 Jan 2023, at 19:36, Jerry D via Gcc wrote: > > > > I had this show up today. I have no idea what this is about. > > > > Please advise. > > > > Sorry Jerry, false positive -- something went wrong with > the builder. Disregard. > > We're still setting things up there. > Please remove the skull and cross bones in the subject line. -- Steve
gcc-13-20230129 is now available
Snapshot gcc-13-20230129 is now available on https://gcc.gnu.org/pub/gcc/snapshots/13-20230129/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 13 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch master revision 2e32a12c04c72f692a7bd119fd3e4e5b74392c9d You'll find: gcc-13-20230129.tar.xz Complete GCC SHA256=f1fc3f6beccf233d15d91d02ab9fc01efe4c3a83fffd01a9d39bd273f146eaa1 SHA1=25f8a46bdc5db160a7d6a167ceb349f60565e72b Diffs from 13-20230122 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-13 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.
Re: ☠ Buildbot (Sourceware): gcc - failed configure (failure) (master)
> On 29 Jan 2023, at 19:36, Jerry D via Gcc wrote: > > I had this show up today. I have no idea what this is about. > > Please advise. > Sorry Jerry, false positive -- something went wrong with the builder. Disregard. We're still setting things up there. > Jerry Best, sam signature.asc Description: Message signed with OpenPGP
Re: ☠ Buildbot (Sourceware): gcc - failed configure (failure) (master)
On Sun, Jan 29, 2023 at 2:37 PM Jerry D via Fortran wrote: > > I had this show up today. I have no idea what this is about. > > Please advise. I assume the buildbot thinks that https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=8011fbba7baa46947341ca8069b5a327163a68d5 broke the build, but I fail to see how that commit results in the error reported in the log.
Fwd: ☠ Buildbot (Sourceware): gcc - failed configure (failure) (master)
I had this show up today. I have no idea what this is about. Please advise. Jerry Forwarded Message Subject: ☠ Buildbot (Sourceware): gcc - failed configure (failure) (master) Date: Sun, 29 Jan 2023 19:31:23 + From: buil...@sourceware.org To: Jerry DeLisle A new failure has been detected on builder gcc-gentoo-sparc while building gcc. Full details are available at: https://builder.sourceware.org/buildbot/#builders/231/builds/210 Build state: failed configure (failure) Revision: 8011fbba7baa46947341ca8069b5a327163a68d5 Worker: gentoo-sparc-big Build Reason: (unknown) Blamelist: Jerry DeLisle Steps: - 0: worker_preparation ( success ) - 1: git checkout ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/231/builds/210/steps/1/logs/stdio - 2: rm -rf gcc-build ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/231/builds/210/steps/2/logs/stdio - 3: configure ( failure ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/231/builds/210/steps/3/logs/stdio
Re: s390 port
Hi Joe. They aren't 24 or 31 bit addresses. All that code I showed was running in AM64. The very first thing that z/PDOS does when it IPLs is activate z/Arch mode and enable AM64. That's about 10 assembler instructions and then it's pure 64-bit for eternity. Only the lower 32 bits of the 64-bit registers are actually populated though, because at least at the application level I am using pure S/370 instructions (from a machine definition in 1989). Even in the OS (z/PDOS) it's almost all GCC-generated code, ie S/370 instructions also. All 32-bit registers. All 32-bit clean. That is why the code ... WORKS. As opposed to your irrelevant quoting from the POP, which is ... irrelevant. BFN. Paul. On Sun, 29 Jan 2023 at 21:08, Joe Monk wrote: > "A 24-bit or 31-bit virtual address is expanded to 64 bits by appending > 40 or 33 zeros, respectively, on the left before it is translated by means > of the DAT process, and a 24-bit or 31-bit real address is similarly > expanded to 64 bits before it is transformed by prefixing. A 24-bit or > 31-bit absolute address is expanded to 64 bits before main storage is > accessed." IBM z/Arch POO page 3-6. > > I dont see 32 bits anywhere in that process. Unless and until IBM changes > the architecture definition to include 32 bits in address sizes, there is > no need for a -m32 switch. > > Joe > > On Sat, Jan 28, 2023 at 12:51 PM Paul Edwards wrote: > >> Hi Joe. >> >> Sorry for the delay (1 year and 4 months) in responding >> to this. There's a long and sad story as to what caused >> the delay, but we're here now. >> >> First of all, Hercules is a very important target. Even >> if gcc -m31 only allowed writing above 2 GiB on Hercules, >> that would still be an extremely important result, and >> justify changing the option to -m32, which is what it >> inherently is. Just because some arbitrary hardware >> masks bits at 24, or 31, or 32, or fails to even do a >> wrap at 64, doesn't alter the inherent fact that GCC >> is using 32-bit registers. Not 64. Not 31. Not 24. >> >> They are general purpose registers being used, so both >> address and data registers are 32 bits. >> >> If you have poorly-written assembler that only works if >> addresses are being masked to 24 bits, then there would >> be some justification in referring to that as a 24-bit >> program. >> >> If you have poorly-written assembler that only works if >> addresses are being masked to 31 bits, then there would >> be some justification in referring to that as a 31-bit >> program. >> >> But if you have a program that works in both of those >> AMODEs, ie what IBM calls "AMODE ANY", it would be a >> bit odd to call it an ANY-bit program, but that would >> be the exact name you need if you want to continue >> along that path. And an ANY-including-32-bit program >> if it also capable of running as AM32 on any real, >> emulated, or theoretical environment. >> >> If you have a poorly-written operating system (like z/OS), >> that doesn't provide address masking (via DAT) to 32 bits >> for 32-bit programs, so your only option is to run them >> as AM31, where negative indexes work, or only run programs >> that don't use negative indexes (and ensure that the >> high 32 bits of 64 bit registers are 0), then there would >> be justification in calling this an AM64-intolerant >> program or AM64-tolerant program, respectively. >> >> z/OS has an additional problem that even in AM64, and >> even with an AM64-tolerant 32-bit program, there is no >> way to request memory in the 2 GiB - 4 GiB region other >> than via crapshoot (use_2g_to_32g or whatever), and >> even if you win the crapshoot, you can't have a nice >> display of the 2 GiB boundary being crossed in a single >> instruction. You could if you switched to supervisor >> mode/key zero and didn't mind clobbering what was already >> there, but you would probably still need to switch DAT off. >> And then because you don't know what damage you have >> done, you would need to freeze the system and re-IPL. >> >> Instead of attempting that, what I did was use a >> properly-written OS, z/PDOS, that uses DAT (virtual >> memory) to map the 4 GiB to 8 GiB region to 0 to 4 GiB, >> so that even in AM64, you effectively get AM32. This is >> the proper way to handle memory when you run 32-bit >> programs on a 64-bit system. 32 and 64-bit programs >> can run transparently with no mode switching required. >> The 4 GiB to 8 GiB virtual storage region is effectively >> dead. >> >> It is only used for negative indexes, which are a >> fundmanental part of indexed addressing. Even positive >> indexes need wrapping. E.g. if you have an address at >> the 3.5 GiB mark and you wish to access memory at the >> 0.5 GiB mark, you would use a positive index of 1 GiB >> to get there. On an AM64 system, without a 32-bit mode >> in effect, this would index to location 4.5 GiB without >> an appropriate DAT mapping. >> >> Note that the index that would do such a thing may be >> in a variable (register) t
Re: s390 port
"A 24-bit or 31-bit virtual address is expanded to 64 bits by appending 40 or 33 zeros, respectively, on the left before it is translated by means of the DAT process, and a 24-bit or 31-bit real address is similarly expanded to 64 bits before it is transformed by prefixing. A 24-bit or 31-bit absolute address is expanded to 64 bits before main storage is accessed." IBM z/Arch POO page 3-6. I dont see 32 bits anywhere in that process. Unless and until IBM changes the architecture definition to include 32 bits in address sizes, there is no need for a -m32 switch. Joe On Sat, Jan 28, 2023 at 12:51 PM Paul Edwards wrote: > Hi Joe. > > Sorry for the delay (1 year and 4 months) in responding > to this. There's a long and sad story as to what caused > the delay, but we're here now. > > First of all, Hercules is a very important target. Even > if gcc -m31 only allowed writing above 2 GiB on Hercules, > that would still be an extremely important result, and > justify changing the option to -m32, which is what it > inherently is. Just because some arbitrary hardware > masks bits at 24, or 31, or 32, or fails to even do a > wrap at 64, doesn't alter the inherent fact that GCC > is using 32-bit registers. Not 64. Not 31. Not 24. > > They are general purpose registers being used, so both > address and data registers are 32 bits. > > If you have poorly-written assembler that only works if > addresses are being masked to 24 bits, then there would > be some justification in referring to that as a 24-bit > program. > > If you have poorly-written assembler that only works if > addresses are being masked to 31 bits, then there would > be some justification in referring to that as a 31-bit > program. > > But if you have a program that works in both of those > AMODEs, ie what IBM calls "AMODE ANY", it would be a > bit odd to call it an ANY-bit program, but that would > be the exact name you need if you want to continue > along that path. And an ANY-including-32-bit program > if it also capable of running as AM32 on any real, > emulated, or theoretical environment. > > If you have a poorly-written operating system (like z/OS), > that doesn't provide address masking (via DAT) to 32 bits > for 32-bit programs, so your only option is to run them > as AM31, where negative indexes work, or only run programs > that don't use negative indexes (and ensure that the > high 32 bits of 64 bit registers are 0), then there would > be justification in calling this an AM64-intolerant > program or AM64-tolerant program, respectively. > > z/OS has an additional problem that even in AM64, and > even with an AM64-tolerant 32-bit program, there is no > way to request memory in the 2 GiB - 4 GiB region other > than via crapshoot (use_2g_to_32g or whatever), and > even if you win the crapshoot, you can't have a nice > display of the 2 GiB boundary being crossed in a single > instruction. You could if you switched to supervisor > mode/key zero and didn't mind clobbering what was already > there, but you would probably still need to switch DAT off. > And then because you don't know what damage you have > done, you would need to freeze the system and re-IPL. > > Instead of attempting that, what I did was use a > properly-written OS, z/PDOS, that uses DAT (virtual > memory) to map the 4 GiB to 8 GiB region to 0 to 4 GiB, > so that even in AM64, you effectively get AM32. This is > the proper way to handle memory when you run 32-bit > programs on a 64-bit system. 32 and 64-bit programs > can run transparently with no mode switching required. > The 4 GiB to 8 GiB virtual storage region is effectively > dead. > > It is only used for negative indexes, which are a > fundmanental part of indexed addressing. Even positive > indexes need wrapping. E.g. if you have an address at > the 3.5 GiB mark and you wish to access memory at the > 0.5 GiB mark, you would use a positive index of 1 GiB > to get there. On an AM64 system, without a 32-bit mode > in effect, this would index to location 4.5 GiB without > an appropriate DAT mapping. > > Note that the index that would do such a thing may be > in a variable (register) that is only known at runtime, > so it is not something that you can change GCC to stop > generating, and I was wrong to ask for that (for years). > > So, with that said, I have been able to satisfy your > challenge, using real hardware. A real z114 using a > real 3270 terminal. You can see that beautiful terminal here: > https://groups.io/g/hercules-380/message/2391https://groups.io/g/hercules-380/message/2392 > > The second photo of the first link shows the CPU (2818) > > z114 = 2818-M05/M10 > > I can obtain a picture of the sticker if needed. > > No Hercules in sight. > > You could move the goal posts and say that running under > z/VM doesn't count either. > > If you do that, I can run z/PDOS directly on an LPAR > and run the memory test (in fact, this has already > been done), but we don't know the procedure (and may > not have permission) to us
