Re: toolchain/58411: GCC/x86_64 10.5 and 12.4 miscompile GCC/sh3 12.4

[Rin Okuyama <rokuyama.rk%gmail.com@localhost>]

The following reply was made to PR toolchain/58411; it has been noted by GNATS.

From: Rin Okuyama <rokuyama.rk%gmail.com@localhost>
To: gnats-bugs%netbsd.org@localhost, toolchain-manager%netbsd.org@localhost,
 gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost
Cc: 
Subject: Re: toolchain/58411: GCC/x86_64 10.5 and 12.4 miscompile GCC/sh3 12.4
Date: Thu, 11 Jul 2024 22:36:20 +0900

 This is not a GCC/amd64 bug! I should have read x86_64 ELF ABI.
 It says:
 
  > When a value of type _Bool is returned or passed in a register or
  > on the stack, bit 0 contains the truth value and bits 1 to 7
  > shall be zero ^14.
  > ...
  > ^14 Other bits are left unspecified, hence the consumer side of
  > those values can rely on it being 0 or 1 when truncated to 8 bit.
 
 So, returning bool value in %al is completely legal, and it is
 callers' responsibility to zero-extend to %rax (or %eax or so).
 
 This strongly suggests that there may be bugs in caller side.
 And I've finally found it:
 
 https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=e214cab68cb34e77622b91113f7698cf137bbdd6
 
 Alas! Upstream already has fixed it, but just forgot to pull it
 up to gcc-12 and -11!
 
 With cherry-picking the above commit, landisk kernel and userland
 successfully build. Now, I'm carrying out full ATF run and compiling
 some pkgsrc's on my machines.
 
 If there's no regression, I'll commit it to gcc, as well as
 gcc.old (and send pull up request to netbsd-10).
 
 Thanks, and sorry for frightening you,
 rin