[Bug d/104911] [12 regression] Comparison failure in gcc/d/typesem.o etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104911 --- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #9 from Iain Buclaw --- > This should be fine now. It is indeed: thanks a lot.
[Bug d/104911] [12 regression] Comparison failure in gcc/d/typesem.o etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104911 Iain Buclaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #9 from Iain Buclaw --- This should be fine now.
[Bug d/104911] [12 regression] Comparison failure in gcc/d/typesem.o etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104911 --- Comment #8 from CVS Commits --- The master branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:fbdaa58162ee4189f441b75170af89215465d189 commit r12-7737-gfbdaa58162ee4189f441b75170af89215465d189 Author: Iain Buclaw 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.
[Bug d/104911] [12 regression] Comparison failure in gcc/d/typesem.o etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104911 Iain Buclaw changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=104738 --- Comment #7 from Iain Buclaw --- 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.
[Bug d/104911] [12 regression] Comparison failure in gcc/d/typesem.o etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104911
--- Comment #6 from Iain Buclaw ---
Created attachment 52649
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52649=edit
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 = integerValue (&__frame, 18446744073709551488);
+ return = integerValue (&__frame, 128);
case 14:;
case 16:;
case 18:;
[Bug d/104911] [12 regression] Comparison failure in gcc/d/typesem.o etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104911 --- Comment #5 from Iain Buclaw --- (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.
[Bug d/104911] [12 regression] Comparison failure in gcc/d/typesem.o etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104911 --- Comment #4 from Rainer Orth --- Created attachment 52630 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52630=edit 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.
[Bug d/104911] [12 regression] Comparison failure in gcc/d/typesem.o etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104911 --- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #2 from Iain Buclaw --- > 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 Date: Sun Mar 13 12:28:05 2022 +0100 d: Merge upstream dmd 02a3fafc6, druntime 26b58167, phobos 16cb085b5.
[Bug d/104911] [12 regression] Comparison failure in gcc/d/typesem.o etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104911 --- Comment #2 from Iain Buclaw --- That's interesting. I've just done a build of 54ef95cc4d1f3f2cde7c1f13250f889ffb81ca75 (20220301) and I get the same comparison failure.
[Bug d/104911] [12 regression] Comparison failure in gcc/d/typesem.o etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104911 Rainer Orth changed: What|Removed |Added Target Milestone|--- |12.0
[Bug d/104911] [12 regression] Comparison failure in gcc/d/typesem.o etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104911 --- Comment #1 from Rainer Orth --- Created attachment 52622 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52622=edit stage 2 and 3 objects
