Between 20220311 (1375e2b62332351a8f9c928421cd1ea8b53c5127) and 20220313 (7e28750395889d16a9cba49cd5935ced7dc00ce8), Solaris bootstrap failed with Bootstrap comparison failure! gcc/d/typesem.o differs gcc/d/semantic3.o differs This happens on both SPARC and x86, as and gas, 32 and 64-bit. I'm attaching the stage2 and stage3 objects, both original and stripped as per contrib/compare-debug.
Created attachment 52622 [details] stage 2 and 3 objects
That's interesting. I've just done a build of 54ef95cc4d1f3f2cde7c1f13250f889ffb81ca75 (20220301) and I get the same comparison failure.
> --- Comment #2 from Iain Buclaw <ibuclaw at gdcproject dot org> --- > That's interesting. I've just done a build of > 54ef95cc4d1f3f2cde7c1f13250f889ffb81ca75 (20220301) and I get the same > comparison failure. Weird: I've just run a reghunt to identify the culprit patch and it converged on commit 7e28750395889d16a9cba49cd5935ced7dc00ce8 Author: Iain Buclaw <ibuclaw@gdcproject.org> Date: Sun Mar 13 12:28:05 2022 +0100 d: Merge upstream dmd 02a3fafc6, druntime 26b58167, phobos 16cb085b5.
Created attachment 52630 [details] stage 2 and 3 objects and assembler output I've now compiled typesem.d and semantic3.d using the stage 1 and 2 gdc respectively with -save-temps added (with a source tree as of 1b85638affe6c987a33427c54e0369b819cd7915, i.e. before the problematic commit, so I could repeat the procedure before and after with the same sources). typesem.s indeed shows small codegen differences, while for semantic3.s there are both codegen differences per se as well as label renamings that may not effect the object files.
(In reply to Rainer Orth from comment #4) > typesem.s indeed shows small codegen differences, while for semantic3.s > there are > both codegen differences per se as well as label renamings that may not > effect the > object files. With typesem.s, it looks like `byte.min' (-128) is being turned into 128 somewhere. Though I can't see how any change in the front-end would have caused that. With semantic3.s, it looks like the middle-end optimizer is removing some branches as dead code, when there should be no way it would possibly be able to infer that.
Created attachment 52649 [details] fdump-tree-original The corrupt is indeed coming from the front-end. Attached tree dumps. --- stage2/typesem.d.005t.original 2022-03-18 10:40:44.087366215 +0100 +++ stage3/typesem.d.005t.original 2022-03-18 10:41:11.776070215 +0100 @@ -2994,7 +2994,7 @@ struct Expression * visitBasic (const st switch ((int) __frame.mt->ty) { case 13:; - return <retval> = integerValue (&__frame, 18446744073709551488); + return <retval> = integerValue (&__frame, 128); case 14:; case 16:; case 18:;
Ah, yes, of course. libdruntime/core/stdc/stdint.d: --- alias int8_t = char; alias uint8_t = ubyte; dmd/globals.d: --- alias d_int8 = int8_t; alias d_uns8 = uint8_t; dmd/expression.d: --- case Tint8: result = cast(d_int8)value; break; case Tchar: case Tuns8: result = cast(d_uns8)value; break; --- D sees both char and ubyte as having the same signed-ness.
The master branch has been updated by Iain Buclaw <ibuclaw@gcc.gnu.org>: https://gcc.gnu.org/g:fbdaa58162ee4189f441b75170af89215465d189 commit r12-7737-gfbdaa58162ee4189f441b75170af89215465d189 Author: Iain Buclaw <ibuclaw@gdcproject.org> Date: Mon Mar 21 16:52:40 2022 +0100 d: Merge upstream dmd 2503f17e5, phobos a74fa63e6. D front-end changes: - Import dmd mainline development. - Removed internal d_intN and d_unsN aliases to stdint types, which caused a regression on Solaris where int8_t is a char (PR104911). Phobos changes: - Import phobos mainline development. PR d/104911 gcc/d/ChangeLog: * dmd/MERGE: Merge upstream dmd 2503f17e5. * d-convert.cc (convert_expr): Replace d_uns64 with dinteger_t. * d-lang.cc: Remove dmd/root/file.h include. (d_handle_option): Update for new front-end interface. (d_parse_file): Likewise. libphobos/ChangeLog: * src/MERGE: Merge upstream phobos a74fa63e6.
This should be fine now.
> --- Comment #9 from Iain Buclaw <ibuclaw at gdcproject dot org> --- > This should be fine now. It is indeed: thanks a lot.