[Bug d/115295] [15 regression] Various gdc testsuite regressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115295 --- Comment #3 from Iain Buclaw --- (In reply to Alexandre Oliva from comment #2) > Ugh, it looks like D deviates from one of the fundamental assumptions behind > the change, namely, that for each named source file, the compiler would > attempt to generate one (set of) output files, so when not linking, an > explicitly named output file would be rejected by the compiler. > > I suppose we could make the new behavior of omitting additional sources in > compile tests dependent on the input language. This is because D (and at a glance Go and Rust too) sets this setting in lang-specs.h ``` int combinable; /* If nonzero, compiler can deal with multiple source files at once (IMA). */ ```
[Bug d/114434] gdc.test/runnable/test23514.d FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114434 Iain Buclaw changed: What|Removed |Added CC||ibuclaw at gcc dot gnu.org --- Comment #3 from Iain Buclaw --- I see the test is pointer + 64-bit int. Is this UB on 32bit pointer platforms?
[Bug tree-optimization/115138] [15 Regression] Bootstrap compare-debug fail after r15-580-gf3e5f4c58591f5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115138 --- Comment #21 from Iain Buclaw --- Now doing a fair comparison: Command: g++-11 -std=c++11 \ -fno-PIE -c -O3 -g -fno-checking -DIN_GCC -fno-exceptions \ -fno-rtti -fasynchronous-unwind-tables \ -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format \ -Wmissing-format-attribute -Wconditionally-supported \ -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros \ -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -fno-PIE \ -I../stage1-gcc -I../../gcc -I../../gcc/. -I../../gcc/../include \ -I../../gcc/../libcpp/include -I../../gcc/../libcody \ -I../../gcc/../libdecnumber -I../../gcc/../libdecnumber/bid \ -I../libdecnumber -I../../gcc/../libbacktrace \ -o gimplify.o ../../gcc/gimplify.cc Optimized-tree dump around line 6529. ``` [local count: 302659225]: # _272 = PHI # DEBUG lhs => NULL # DEBUG final_pred => _272 # DEBUG BEGIN_STMT if (_272 != _547) goto ; [53.47%] else goto ; [46.53%] [local count: 301785332]: # DEBUG BEGIN_STMT _66 = MEM[(union tree_node * *)_1 + 32B]; _67 = _66->base.code; if (_67 == 163) goto ; [34.00%] else goto ; [66.00%] [local count: 161831887]: # DEBUG BEGIN_STMT ret_268 = gimplify_expr (_796, pre_p_252(D), post_p_253(D), _272, 1); # DEBUG ret => ret_268 # DEBUG BEGIN_STMT if (ret_268 == -2) goto ; [0.54%] else goto ; [99.46%] ``` Command #2: ../stage1-gcc/xg++ -B../stage1-gcc/ -B/usr/x86_64-pc-linux-gnu/bin/ \ -nostdinc++ -B../stage1-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs \ -B../stage1-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs \ -I../stage1-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu \ -I../stage1-x86_64-pc-linux-gnu/libstdc++-v3/include \ -I../../libstdc++-v3/libsupc++ \ -L../stage1-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs \ -L../stage1-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs \ -fno-PIE -c -O3 -g -fno-checking -DIN_GCC -fno-exceptions \ -fno-rtti -fasynchronous-unwind-tables \ -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual \ -Wmissing-format-attribute -Wconditionally-supported \ -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros \ -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -fno-PIE \ -I../stage2-gcc -I../../gcc -I../../gcc/. -I../../gcc/../include \ -I../../gcc/../libcpp/include -I../../gcc/../libcody \ -I../../gcc/../libdecnumber -I../../gcc/../libdecnumber/bid \ -I../libdecnumber -I../../gcc/../libbacktrace \ -o gimplify.o ../../gcc/gimplify.cc Output. ``` [local count: 302659226]: # _274 = PHI # DEBUG lhs => NULL # DEBUG final_pred => _274 # DEBUG BEGIN_STMT # DEBUG BEGIN_STMT ret_270 = gimplify_expr (_723, pre_p_253(D), post_p_254(D), _274, 1); # DEBUG ret => ret_270 # DEBUG BEGIN_STMT if (ret_270 == -2) goto ; [0.54%] else goto ; [99.46%] [local count: 301785333]: # DEBUG BEGIN_STMT _66 = MEM[(union tree_node * *)_1 + 32B]; _67 = _66->base.code; if (_67 == 163) goto ; [34.00%] else goto ; [66.00%] ``` Is this helpful enough to narrow it down?
[Bug tree-optimization/115138] [15 Regression] Bootstrap compare-debug fail after r15-580-gf3e5f4c58591f5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115138 --- Comment #20 from Iain Buclaw --- Stepping through both the stage1-gcc/gdc and stage2-gcc/gdc compilers, there is an apparent divergence in behaviour at this point in gimplify.cc 6527│ /* Now that the LHS is gimplified, re-gimplify the RHS if our initial 6528│ guess for the predicate was wrong. */ 6529│ gimple_predicate final_pred = rhs_predicate_for (*to_p); 6530│ if (final_pred != initial_pred) 6531│ { 6532│ ret = gimplify_expr (from_p, pre_p, post_p, final_pred, fb_rvalue); 6533│ if (ret == GS_ERROR) 6534│ return ret; 6535│ } It looks like the stage2 compiler treats the if condition as being always true - though I could be looking at apples and oranges here as one is -O0 whilst the other is -O2. stage1: ``` 0x01421561 <+2288>: call 0x141dc8e <_Z17rhs_predicate_forP9tree_node> 0x01421566 <+2293>: mov%rax,-0x90(%rbp) 0x0142156d <+2300>: mov-0x90(%rbp),%rax 0x01421574 <+2307>: cmp-0x98(%rbp),%rax 0x0142157b <+2314>: je 0x14215c1 0x0142157d <+2316>: mov-0x90(%rbp),%rcx 0x01421584 <+2323>: mov-0xf8(%rbp),%rdx 0x0142158b <+2330>: mov-0xf0(%rbp),%rsi 0x01421592 <+2337>: mov-0xb0(%rbp),%rax 0x01421599 <+2344>: mov$0x1,%r8d 0x0142159f <+2350>: mov%rax,%rdi 0x014215a2 <+2353>: call 0x1456eac <_Z13gimplify_exprPP9tree_nodePP6gimpleS4_PFbS0_Ei> 0x014215a7 <+2358>: mov%eax,-0xd4(%rbp) 0x014215ad <+2364>: cmpl $0xfffe,-0xd4(%rbp) 0x014215b4 <+2371>: jne0x14215c1 0x014215b6 <+2373>: mov-0xd4(%rbp),%eax 0x014215bc <+2379>: jmp0x1422709 0x014215c1 <+2384>: mov-0xb0(%rbp),%rax ``` stage2 ``` 0x010d637c <+668>: call 0x105d030 <_Z13is_gimple_regP9tree_node> 0x010d6381 <+673>: mov$0x10a2ad0,%ecx 0x010d6386 <+678>: mov%r12,%rdx 0x010d6389 <+681>: mov%rbx,%rsi 0x010d638c <+684>: test %al,%al 0x010d638e <+686>: mov$0x10a21d0,%eax 0x010d6393 <+691>: mov$0x1,%r8d 0x010d6399 <+697>: mov%r14,%rdi 0x010d639c <+700>: cmovne %rax,%rcx 0x010d63a0 <+704>: call 0x10b3700 <_Z13gimplify_exprPP9tree_nodePP6gimpleS4_PFbS0_Ei> 0x010d63a5 <+709>: cmp$0xfffe,%eax 0x010d63a8 <+712>: je 0x10d6538 ```
[Bug tree-optimization/115138] [15 Regression] Bootstrap compare-debug fail after r15-580-gf3e5f4c58591f5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115138 --- Comment #19 from Iain Buclaw --- (In reply to Iain Buclaw from comment #18) > Reduction of opover.d > ``` > bool __setArrayAllocLength(size_t newLength) > { > import core.checkedint; > bool overflow; > addu(newLength, > addu(0, 0, overflow), > overflow); > This is likely not translatable into C/C++. The D FE emits ADD_OVERFLOW() directly, and swapping this with __builtin_uaddll_overflow is not equivalent - pulling out the second `addu` to its own local variable means the comparison failure is not triggered.
[Bug tree-optimization/115138] [15 Regression] Bootstrap compare-debug fail after r15-580-gf3e5f4c58591f5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115138 --- Comment #18 from Iain Buclaw --- Reduction of opover.d ``` bool __setArrayAllocLength(size_t newLength) { import core.checkedint; bool overflow; addu(newLength, addu(0, 0, overflow), overflow); return true; } enum EXP { greaterOrEqual, greaterThan, lessOrEqual, lessThan, } EXP reverseRelation(EXP op) { switch (op) { case EXP.greaterOrEqual: op = EXP.lessOrEqual;break; case EXP.greaterThan: op = EXP.lessThan; break; case EXP.lessOrEqual: op = EXP.greaterOrEqual; break; default: break; } return op; } ``` Running (from the build directory) ``` ./stage1-gcc/gdc -B ./stage1-gcc/ -c -O2 -g -fversion=IN_GCC \ -I ./stage1-x86_64-pc-linux-gnu/libphobos/libdruntime \ -I ../../libphobos/libdruntime -I ../../gcc/d/ \ -J ../../gcc/d/dmd -J ../../gcc/d/dmd/res opover.d -o opover-1.o ../stage2-gcc/gdc -B ../stage2-gcc/ -c -O2 -g -fversion=IN_GCC \ -I ../stage2-x86_64-pc-linux-gnu/libphobos/libdruntime \ -I ../../libphobos/libdruntime -I ../../gcc/d/ \ -J ../../gcc/d/dmd -J ../../gcc/d/dmd/res opover.d -o opover-2.o cmp --ignore-initial=16 opover-1.o opover-2.o ``` Also observed from assembly output ``` --- opover-1.s 2024-05-22 19:10:36.315939819 +0200 +++ opover-2.s 2024-05-22 19:10:28.763819758 +0200 @@ -29,7 +29,7 @@ _D6opover15reverseRelationFEQBa3EXPZQj: movl%edi, %eax cmpl$2, %eax ja .L5 - leaqCSWTCH.8(%rip), %rdx + leaqCSWTCH.9(%rip), %rdx movl(%rdx,%rax,4), %eax .L5: .LVL2: @@ -123,9 +123,9 @@ gdc.dso_dtor: .quad gdc.dso_dtor .section.rodata .align 8 - .type CSWTCH.8, @object - .size CSWTCH.8, 12 -CSWTCH.8: + .type CSWTCH.9, @object + .size CSWTCH.9, 12 +CSWTCH.9: .long 2 .long 3 .long 0 ```
[Bug tree-optimization/115138] [15 Regression] Bootstrap compare-debug fail after r15-580-gf3e5f4c58591f5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115138 --- Comment #16 from Iain Buclaw --- (In reply to Richard Biener from comment #15) > Note the opover.d compile doesn't even use -O3, so this is all extremely > odd. It would somehow point at a miscompile of the stage2 compiler by > the stage1 compiler manifesting itself only in this change ... > > So the logical next step would be to bisect stage1/stage2 object files > of d21 and see which stage2 object is miscompiled. After removing `--enable-multilib` I've managed to replicate this too. Confirmed that GDCFLAGS ignores whatever's in `--with-build-config=bootstrap-O3` when compared next to Stage1 (`-g -O2` vs `-g`) ``` gdc -c -g -O2 -fversion=IN_GCC -fno-PIE -fno-exceptions -fasynchronous-unwind-tables -Wall -Wdeprecated -fno-common -o d/opover.o -MT d/opover.o -MMD -MP -MF d/.deps/opover.TPo -I../../gcc/d -J../../gcc/d/dmd -J../../gcc/d/dmd/res ../../gcc/d/dmd/opover.d g++ -std=c++11 -fno-PIE -c -DIN_GCC_FRONTEND -g -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Wconditionally-supported -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -fno-PIE -I. -Id -I../../gcc -I../../gcc/d -I../../gcc/../include -I../../gcc/../libcpp/include -I../../gcc/../libcody -I../../gcc/../libdecnumber -I../../gcc/../libdecnumber/bid -I../libdecnumber -I../../gcc/../libbacktrace -o d/d-attribs.o -MT d/d-attribs.o -MMD -MP -MF d/.deps/d-attribs.TPo ../../gcc/d/d-attribs.cc ``` Stage2 (`-O2 -g` vs `-O3 -g -fno-checking`) ``` /repos/gcc/build.O3/./prev-gcc/gdc -B/repos/gcc/build.O3/./prev-gcc/ -B/usr/x86_64-pc-linux-gnu/bin/ -O2 -g -B/repos/gcc/build.O3/prev-x86_64-pc-linux-gnu/libphobos/libdruntime/gcc -B/repos/gcc/build.O3/prev-x86_64-pc-linux-gnu/libphobos/src -B/repos/gcc/build.O3/prev-x86_64-pc-linux-gnu/libphobos/src/.libs -I/repos/gcc/build.O3/prev-x86_64-pc-linux-gnu/libphobos/libdruntime -I/repos/gcc/libphobos/libdruntime -L/repos/gcc/build.O3/prev-x86_64-pc-linux-gnu/libphobos/src/.libs -B/repos/gcc/build.O3/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/repos/gcc/build.O3/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -c -g -O2 -fversion=IN_GCC -fno-PIE -fno-exceptions -fasynchronous-unwind-tables -Wall -Wdeprecated -fno-common -o d/opover.o -MT d/opover.o -MMD -MP -MF d/.deps/opover.TPo -I../../gcc/d -J../../gcc/d/dmd -J../../gcc/d/dmd/res ../../gcc/d/dmd/opover.d /repos/gcc/build.O3/./prev-gcc/xg++ -B/repos/gcc/build.O3/./prev-gcc/ -B/usr/x86_64-pc-linux-gnu/bin/ -nostdinc++ -B/repos/gcc/build.O3/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -B/repos/gcc/build.O3/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -I/repos/gcc/build.O3/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I/repos/gcc/build.O3/prev-x86_64-pc-linux-gnu/libstdc++-v3/include -I/repos/gcc/libstdc++-v3/libsupc++ -L/repos/gcc/build.O3/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/repos/gcc/build.O3/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -fno-PIE -c -DIN_GCC_FRONTEND -O3 -g -fno-checking -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Wconditionally-supported -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -fno-PIE -I. -Id -I../../gcc -I../../gcc/d -I../../gcc/../include -I../../gcc/../libcpp/include -I../../gcc/../libcody -I../../gcc/../libdecnumber -I../../gcc/../libdecnumber/bid -I../libdecnumber -I../../gcc/../libbacktrace -o d/d-attribs.o -MT d/d-attribs.o -MMD -MP -MF d/.deps/d-attribs.TPo ../../gcc/d/d-attribs.cc ``` Stage3: (`-O2 -g` vs `-O3 -g -fchecking=1`) ``` /repos/gcc/build.O3/./prev-gcc/gdc -B/repos/gcc/build.O3/./prev-gcc/ -B/usr/x86_64-pc-linux-gnu/bin/ -O2 -g -B/repos/gcc/build.O3/prev-x86_64-pc-linux-gnu/libphobos/libdruntime/gcc -B/repos/gcc/build.O3/prev-x86_64-pc-linux-gnu/libphobos/src -B/repos/gcc/build.O3/prev-x86_64-pc-linux-gnu/libphobos/src/.libs -I/repos/gcc/build.O3/prev-x86_64-pc-linux-gnu/libphobos/libdruntime -I/repos/gcc/libphobos/libdruntime -L/repos/gcc/build.O3/prev-x86_64-pc-linux-gnu/libphobos/src/.libs -B/repos/gcc/build.O3/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/repos/gcc/build.O3/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -c -g -O2 -fversion=IN_GCC -fno-PIE -fno-exceptions -fasynchronous-unwind-tables -Wall -Wdeprecated -fno-common -o d/opover.o -MT d/opover.o -MMD -MP -MF d/.deps/opover.TPo -I../../gcc/d -J../../gcc/d/dmd -J../../gcc/d/dmd/res ../../gcc/d/dmd/opover.d /repos/gcc/build.O3/./prev-gcc/xg++ -B/repos/gcc/build.O3/./prev-gcc/ -B/usr/x86_64-pc-linux-gnu/bin/ -nostdinc++ -B/repos/gcc/build.O3/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -B/repos/gcc/build.O3/prev-x86_64-pc-linux-gnu/libstdc++-v3
[Bug tree-optimization/115138] [15 Regression] Bootstrap compare-debug fail after r15-580-gf3e5f4c58591f5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115138 --- Comment #11 from ibuclaw at gcc dot gnu.org --- (In reply to Iain Sandoe from comment #0) > At present, still trying to figure out how to debug this further .. it's D > so no preprocessed output - I guess will have to try tree dumps. Dustmite would help reduce it if you have a reliable automated test.
[Bug d/112408] [12/13/14 regression] d21 loops in getCpuInfo0B in Solaris/x86 kernel zone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112408 --- Comment #7 from ibuclaw at gcc dot gnu.org --- Patch ready to apply to releases/gcc-13, and backports to gcc-12 and gcc-11. Mainline will get this in the next upstream merge.
[Bug d/112408] [12/13/14 regression] d21 loops in getCpuInfo0B in Solaris/x86 kernel zone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112408 --- Comment #5 from ibuclaw at gcc dot gnu.org --- Upstream PR https://github.com/dlang/dmd/pull/15778
[Bug d/112408] [12/13/14 regression] d21 loops in getCpuInfo0B in Solaris/x86 kernel zone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112408 --- Comment #3 from ibuclaw at gcc dot gnu.org --- Based on what I see here, this patch to core.cpuid should be sufficient to fix loop and not introduce any change in existing behaviour. --- --- a/druntime/src/core/cpuid.d +++ b/druntime/src/core/cpuid.d @@ -666,10 +666,12 @@ void getAMDcacheinfo() // to determine number of processors. void getCpuInfo0B() { -int level=0; int threadsPerCore; uint a, b, c, d; -do { +// I'm not sure about this. The docs state that there +// are 2 hyperthreads per core if HT is factory enabled. +for (int level = 0; level < 2; level++) +{ version (GNU_OR_LDC) asm pure nothrow @nogc { "cpuid" : "=a" (a), "=b" (b), "=c" (c), "=d" (d) : "a" (0x0B), "c" (level); } else asm pure nothrow @nogc { @@ -681,19 +683,20 @@ void getCpuInfo0B() mov c, ECX; mov d, EDX; } -if (b!=0) { - // I'm not sure about this. The docs state that there - // are 2 hyperthreads per core if HT is factory enabled. -if (level==0) +if (b != 0) +{ +if (level == 0) threadsPerCore = b & 0x; -else if (level==1) { +else if (level == 1) +{ cpuFeatures.maxThreads = b & 0x; cpuFeatures.maxCores = cpuFeatures.maxThreads / threadsPerCore; } - } -++level; -} while (a!=0 || b!=0); +// Got "invalid domain" returned from cpuid +if (a == 0 && b == 0) +break; +} } void cpuidX86()
[Bug d/112408] [12/13/14 regression] d21 loops in getCpuInfo0B in Solaris/x86 kernel zone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112408 ibuclaw at gcc dot gnu.org changed: What|Removed |Added CC||ibuclaw at gcc dot gnu.org --- Comment #1 from ibuclaw at gcc dot gnu.org --- (In reply to Rainer Orth from comment #0) > This affects all DMD-based versions of GDC, while the previous C++-based > versions > are fine. The compiler is fine, but if I understand right, all programs built by the C++-based version would still observe the same infinite loop.
[Bug d/110712] d: ICE: verify_gimple_failed (conversion of register to a different size in 'view_convert_expr')
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110712 ibuclaw at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED CC||ibuclaw at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #7 from ibuclaw at gcc dot gnu.org --- Fix committed and backported.
[Bug d/112270] ICE: in verify_gimple_in_seq on powerpc-darwin9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112270 ibuclaw at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #4 from ibuclaw at gcc dot gnu.org --- Fix committed, and backported to GCC 13 and GCC 12 release branches.
[Bug d/112270] New: ICE: in verify_gimple_in_seq on powerpc-darwin9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112270 Bug ID: 112270 Summary: ICE: in verify_gimple_in_seq on powerpc-darwin9 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: ibuclaw at gcc dot gnu.org Target Milestone: --- Mismatching D and C boolean types causes ICE on powerpc-darwin. ---../../gcc/d/dmd/cppmangle.d: In function ‘isNamespaceEqual’: ../../gcc/d/dmd/cppmangle.d:2354:14: error: non-trivial conversion in ‘integer_cst’ 2354 | private bool isNamespaceEqual (CPPNamespaceDeclaration a, CPPNamespaceDeclaration b) @safe | ^ bool iftmp.120 = 1; ../../gcc/d/dmd/cppmangle.d:2354:14: internal compiler error: ‘verify_gimple’ failed 0x118c5a5 verify_gimple_in_seq(gimple*, bool) ../../gcc/tree-cfg.cc:5297 0xe4192b gimplify_body(tree_node*, bool) ../../gcc/gimplify.cc:18046 0xe41a9f gimplify_function_tree(tree_node*) ../../gcc/gimplify.cc:18162 0xc571f7 cgraph_node::analyze() ../../gcc/cgraphunit.cc:684 0xc598d7 analyze_functions ../../gcc/cgraphunit.cc:1247 0xc5a621 symbol_table::finalize_compilation_unit() ../../gcc/cgraphunit.cc:2554 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. ../../gcc/d/dmd/cppmangle.d failed --- Minimal reproducer: --- class CPPNamespaceDeclaration { } bool isNamespaceEqual (CPPNamespaceDeclaration a) { return a ? true : isNamespaceEqual(a); }
[Bug d/103578] d21 doesn't link on Darwin/i386
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103578 ibuclaw at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED CC||ibuclaw at gcc dot gnu.org --- Comment #1 from ibuclaw at gcc dot gnu.org --- This was fixed in r12-8302.
[Bug d/111537] ICE: in set_cell_span, at text-art/table.cc:148 with D front-end and -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111537 ibuclaw at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #12 from ibuclaw at gcc dot gnu.org --- Fixes committed. Thanks!
[Bug d/111537] ICE: in set_cell_span, at text-art/table.cc:148 with D front-end and -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111537 ibuclaw at gcc dot gnu.org changed: What|Removed |Added CC||ibuclaw at gcc dot gnu.org Assignee|dmalcolm at gcc dot gnu.org|ibuclaw at gcc dot gnu.org Component|analyzer|d --- Comment #10 from ibuclaw at gcc dot gnu.org --- Nice, thanks for pointing me to specifically where analyzer was tripping over David. I think I can take over this PR from here. --- oob.d: In function ‘D main’: oob.d:5:11: warning: stack-based buffer overflow [CWE-121] [-Wanalyzer-out-of-bounds] 5 | strcpy(arr.ptr, "hello world"); | ^ ‘D main’: events 1-4 | |4 | char[5] arr; | | ^ | | | | | (1) capacity: 5 bytes | | (2) following ‘false’ branch... | | (3) ...to here |5 | strcpy(arr.ptr, "hello world"); | | ~ | | | | | (4) out-of-bounds write from byte 5 till byte 11 but ‘arr’ ends at byte 5 | oob.d:5:11: note: write of 7 bytes to beyond the end of ‘arr’ 5 | strcpy(arr.ptr, "hello world"); | ^ oob.d:5:11: note: valid subscripts for ‘arr’ are ‘[0]’ to ‘[4]’ ┌─┬─┬─┬─┬───┐┌─┬─┬─┬┬┬┬┐ │ [0] │ [1] │ [2] │ [3] │ [4] ││ [5] │ [6] │ [7] │[8] │[9] │[10]│[11]│ ├─┼─┼─┼─┼───┤├─┼─┼─┼┼┼┼┤ │ ‘h’ │ ‘e’ │ ‘l’ │ ‘l’ │ ‘o’ ││ ‘ ’ │ ‘w’ │ ‘o’ │‘r’ │‘l’ │‘d’ │NUL │ ├─┴─┴─┴─┴───┴┴─┴─┴─┴┴┴┴┤ │ string literal (type: ‘const char[12]’)│ └──┘ │ │ │ │ │ │ │ │││││ │ │ │ │ │ │ │ │││││ v v v v v v v vvvvv ┌─┬─┬───┐┌─┐ │ [0] │ ... │ [4] ││ │ ├─┴─┴───┤│ after valid range │ │‘arr’ (type: ‘char[5]’)││ │ └───┘└─┘ ├───┬───┤├──┬──┤ │ │ ╭┴╮ ╭───┴──╮ │capacity: 5 bytes│ │⚠️ overflow of 7 bytes│ ╰─╯ ╰──╯
[Bug d/110959] gdc: internal compiler error: in layout_aggregate_type in recursive templated class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110959 ibuclaw at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED CC||ibuclaw at gcc dot gnu.org --- Comment #3 from ibuclaw at gcc dot gnu.org --- Fix committed to releases/gcc-12, and test case added to mainline.
[Bug d/108842] Cannot use enum array with -fno-druntime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108842 ibuclaw at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED CC||ibuclaw at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #5 from ibuclaw at gcc dot gnu.org --- Fix committed and backported.
[Bug d/108962] d: Don't generate code that throws exceptions when compiling with `-fno-exceptions'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108962 ibuclaw at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from ibuclaw at gcc dot gnu.org --- Fixed by PR d/110471
[Bug d/110516] core.volatile.volatileLoad discarded if result is unused
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110516 ibuclaw at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #7 from ibuclaw at gcc dot gnu.org --- Fix committed and backported.
[Bug d/110516] core.volatile.volatileLoad is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110516 --- Comment #2 from ibuclaw at gcc dot gnu.org --- (In reply to Witold Baryluk from comment #0) > I did not test volatileStore, but I would not be surprised it is also broken. volatileStore is fine, because that expands to an assignment, which is assumed to have a side effect.
[Bug d/110514] d: accesses of immutable arrays using constant index still bounds checked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110514 ibuclaw at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from ibuclaw at gcc dot gnu.org --- Fix committed and backported.
[Bug d/110516] core.volatile.volatileLoad is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110516 ibuclaw at gcc dot gnu.org changed: What|Removed |Added CC||ibuclaw at gcc dot gnu.org --- Comment #1 from ibuclaw at gcc dot gnu.org --- (In reply to Witold Baryluk from comment #0) > gcc 12.2.0 (from Debian stable) and gcc trunk 14.0.0 (in godbolt) tested. > > core.volatile.volatileLoad simply does not work. > > 1) It merges loads. > 2) It removes unused loads at -O1 and higher. > > Example: > > void actualRun(ubyte* ptr1) { > import core.volatile : volatileLoad; > volatileLoad(ptr1); > volatileLoad(ptr1); > volatileLoad(ptr1); > volatileLoad(ptr1); > } Actually, doesn't seem to be doing either 1 or 2, it looks like the statement is just dropped altogether as no obvious side-effect was picked up from the expression to which the intrinsic was expanded into. https://d.godbolt.org/z/361x4vKfn
[Bug d/110514] New: d: accesses immutable arrays using constant index still bounds checked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110514 Bug ID: 110514 Summary: d: accesses immutable arrays using constant index still bounds checked Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: ibuclaw at gcc dot gnu.org Target Milestone: --- For example: --- immutable uint[] arr = [1,2,3]; void test() { immutable uint* p = arr.ptr; if (arr[0]== p[0] && arr[1] == p[1] && arr[2] == p[2]) return; assert(0); } --- Although the size and value of `arr` is known at compile-time, and is guaranteed to never change at run-time, there are still three calls to `_d_arrayboundsp` inserted into the program.
[Bug d/110471] d: Don't generate code that throws exceptions when compiling with `-fno-exceptions'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110471 ibuclaw at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from ibuclaw at gcc dot gnu.org --- Fix committed and backported to gcc-13.
[Bug d/110511] d: internal compiler error: in setValue, at d/dmd/dinterpret.c:7013
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110511 ibuclaw at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from ibuclaw at gcc dot gnu.org --- Upstream PR backported.
[Bug d/110511] d: internal compiler error: in setValue, at d/dmd/dinterpret.c:7013
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110511 ibuclaw at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-07-01 Ever confirmed|0 |1 --- Comment #1 from ibuclaw at gcc dot gnu.org --- Fixed by https://github.com/dlang/dmd/pull/13172 Will only backport that commit to gcc-10 and gcc-11 then.
[Bug d/110511] New: d: internal compiler error: in setValue, at d/dmd/dinterpret.c:7013
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110511 Bug ID: 110511 Summary: d: internal compiler error: in setValue, at d/dmd/dinterpret.c:7013 Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: ibuclaw at gcc dot gnu.org Target Milestone: --- Only affects gdc-11 and earlier. --- void formattedRead() { cast(void)checkFormatException!(); } const checkFormatException() = { const pnum = { ubyte* p; return cast(ulong) p; }(); return null; }(); ---
[Bug d/110471] New: d: Don't generate code that throws exceptions when compiling with `-fno-exceptions'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110471 Bug ID: 110471 Summary: d: Don't generate code that throws exceptions when compiling with `-fno-exceptions' Product: gcc Version: 9.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: ibuclaw at gcc dot gnu.org Target Milestone: --- The predefined version conditions D_ModuleInfo, D_Exceptions, and D_TypeInfo were added in r9-7112. However individual feature flags do not turn off these versions. For example. this should succeed compilation. // { dg-options "-fno-exceptions" } version (D_Exceptions) static assert(false); // expected to never trigger.
[Bug d/106977] [13/14 regression] d21 dies with SIGBUS on 32-bit Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977 --- Comment #34 from ibuclaw at gcc dot gnu.org --- I think this should be fixed now. I'll let @Iain Sandoe confirm, as there are likely other fixes he has relating to the testsuite.
[Bug target/110406] d: Wrong code-gen returning POD structs by value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110406 ibuclaw at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #16 from ibuclaw at gcc dot gnu.org --- Fixed and backported problem specific to the D front-end. There's another part to this in pr102027, but I don't think this should be kept open waiting for it.
[Bug target/110406] d: Wrong code-gen returning POD structs by value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110406 ibuclaw at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2023-06-28 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ibuclaw at gcc dot gnu.org --- Comment #13 from ibuclaw at gcc dot gnu.org --- Created attachment 55413 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55413&action=edit delay calling compute_record_mode until all fields complete Attaching the full patch that was being tested, related to the above snippet.
[Bug d/110193] d_signed_or_unsigned_type is invoked for vector types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110193 ibuclaw at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from ibuclaw at gcc dot gnu.org --- Fix committed.
[Bug target/110406] d: Wrong code-gen returning POD structs by value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110406 --- Comment #10 from ibuclaw at gcc dot gnu.org --- Looking at an ICE in stage2 D compiler for i686-darwin17, I realized that it's another facet of this issue. // aggregate.d import dsymbol; extern (C++) class AggregateDeclaration : ScopeDsymbol { Visibility visibility; override Visibility visible() { return visibility; } } // dsymbol.d struct Visibility { enum Kind { undefined } Kind kind; } extern(C++) class ScopeDsymbol { Visibility visible(); Visibility.Kind* visibilities; } When compiling dsymbol.d, `struct Visibility` is set SImode. However when compiling aggregate.d it's instead given BLKmode. This causes all the difference in how it is returned. Any C++ code interfacing with this will crash due to the mismatch too.
[Bug target/110406] d: Wrong code-gen returning POD structs by value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110406 --- Comment #9 from ibuclaw at gcc dot gnu.org --- (In reply to ibuclaw from comment #8) > So long as C and D agree with each other when it comes to POD types, it > almost doesn't matter to me weather the back-end is following the wrong ABI. Or whether.
[Bug target/110406] d: Wrong code-gen returning POD structs by value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110406 --- Comment #8 from ibuclaw at gcc dot gnu.org --- (In reply to Andrew Pinski from comment #7) > (In reply to Andrew Pinski from comment #6) > > Which itself is GCC 12+ regression too ... > > I filed that as PR 110407, let's see what the x86 backend folks say ... OK, in the meantime I will proceed with seeing what I did to change the return behaviour on my end. So long as C and D agree with each other when it comes to POD types, it almost doesn't matter to me weather the back-end is following the wrong ABI.
[Bug target/110406] d: Wrong code-gen returning POD structs by value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110406 --- Comment #4 from ibuclaw at gcc dot gnu.org --- It would be good if TYPE_MODE no longer had such a strong influence though. In the meantime, I ought to restore behaviour to how it was in 12.x
[Bug target/110406] d: Wrong code-gen returning POD structs by value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110406 --- Comment #3 from ibuclaw at gcc dot gnu.org --- (In reply to Andrew Pinski from comment #2) > >structs have been set the wrong mode > > No, they don't have wrong mode, just the x86_64 backend is broken, see bug > 102027 comment #7 specifically. I think they do. On 64-bit, I expect the mode set by compute_record_mode to be TImode. However what I'm instead seeing is BLKmode. This tells me I might be calling it too early, and some fields yet to have their DECL_SIZE set.
[Bug d/110406] New: d: Wrong code-gen returning POD structs by value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110406 Bug ID: 110406 Summary: d: Wrong code-gen returning POD structs by value Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: ibuclaw at gcc dot gnu.org Target Milestone: --- Since 13.1 (r13-1104?), structs have been set the wrong mode, causing them to return differently to equivalent static arrays. --- struct cpuid_abcd_t { uint eax; uint ebx; uint ecx; uint edx; }; cpuid_abcd_t cpuid_insn(const uint in_eax) { cpuid_abcd_t ret = void; asm { "cpuid" : "=a" ( ret.eax ), "=b" ( ret.ebx ), "=c" ( ret.ecx ), "=d" ( ret.edx ) : "a" ( in_eax ) : ;} return ret; } uint[4] cpuid_insn2(const uint in_eax) { uint[4] ret = void; asm { "cpuid" : "=a" ( ret[0] ), "=b" ( ret[1] ), "=c" ( ret[2] ), "=d" ( ret[3] ) : "a" ( in_eax ) : ;} return ret; } --- The first function erroneously being returned in vector registers. _15 = {ret$eax_3, ret$ebx_4, ret$ecx_5, ret$edx_6}; MEM [(void *)&D.1894] = _15; return D.1894;
[Bug d/110359] d: Suboptimal codegen for __builtin_expect(cond, false) since PR96435
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110359 ibuclaw at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #6 from ibuclaw at gcc dot gnu.org --- Fix committed.
[Bug d/110113] gdc -fpreview=dip1021 crash in d/dmd/root/aav.d:127 dmd_aaGetRvalue from DsymbolTable::lookup(Identifier const*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110113 ibuclaw at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #13 from ibuclaw at gcc dot gnu.org --- Fix committed to releases/gcc-13, and backported to gcc-12. It will hit mainline on the next merge with upstream dmd.
[Bug d/110359] New: d: Suboptimal codegen for __builtin_expect(cond, false) since PR96435
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110359 Bug ID: 110359 Summary: d: Suboptimal codegen for __builtin_expect(cond, false) since PR96435 Product: gcc Version: 11.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: ibuclaw at gcc dot gnu.org Target Milestone: --- Since pr96435, both boolean objects *and* expressions have been evaluated in the following way. (*(ubyte*)&obj_or_expr) & 1 It has been noted that sometimes this can cause the back-end to optimize in non-obvious ways - in particular with `__builtin_expect`. --- double pow(in double x, in ulong p) { import gcc.builtins : __builtin_expect; if (__builtin_expect(p == 0, false)) // 1,2 return 1; if (__builtin_expect(p == 1, false)) // 3,4 return x; double s = x; double v = 1; for (ulong i = p; i > 1; i >>= 1) // 5 { v = (i & 0x1) ? s * v : v; s = s * s; } return v * s; } --- The first 5 lines of assembly for the above function (corresponding souce line marked in comments) --- double example.pow(in double, in ulong): testrdi, rdi je .L6 cmp rdi, 1 je .L1 jbe .L1 --- The jbe condition looks like it is either redundant, or suboptimal. This @safe feature could be restricted to just when reading the value of a bool field that comes from a union.
[Bug d/110193] d_signed_or_unsigned_type is invoked for vector types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110193 --- Comment #4 from ibuclaw at gcc dot gnu.org --- A shortcut to signed_or_unsigned_type_for for vector types seems reasonable nonetheless.
[Bug d/110193] d_signed_or_unsigned_type is invoked for vector types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110193 --- Comment #3 from ibuclaw at gcc dot gnu.org --- (In reply to ibuclaw from comment #2) > Gimple dump: > --- > __vector(int[4]) rshift (__vector(int[4]) v) > { > __vector(int[4]) D.1795; > > _1 = VIEW_CONVERT_EXPR(v); > _2 = _1 >> 2; > D.1795 = VIEW_CONVERT_EXPR<__vector(int[4])>(_2); > return D.1795; > } I've just realized that I wasn't reading this code dump properly. Everything looks correct here. I've a look again and picked at random vector E_V8HImode, that has a precision of 3. Whereas a cent has a precision of 128.
[Bug d/110193] d_signed_or_unsigned_type is invoked for vector types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110193 ibuclaw at gcc dot gnu.org changed: What|Removed |Added CC||ibuclaw at gcc dot gnu.org --- Comment #2 from ibuclaw at gcc dot gnu.org --- Just having a cursory look, the only references to d_signed_or_unsigned_type is via d_unsigned_type and d_signed_type. The former is only called by d_gimplify_unsigned_rshift_expr. So I guess you must mean you've noticed this with something like. __vector(int[4]) unsigned_rshift(__vector(int[4]) v) { return v >>> 2; } It turns out that this accident doesn't affect the intent on x86. https://d.godbolt.org/z/99fK7fWaW Gimple dump: --- __vector(int[4]) rshift (__vector(int[4]) v) { __vector(int[4]) D.1795; _1 = VIEW_CONVERT_EXPR(v); _2 = _1 >> 2; D.1795 = VIEW_CONVERT_EXPR<__vector(int[4])>(_2); return D.1795; }
[Bug d/110113] gdc -fpreview=dip1021 crash in d/dmd/root/aav.d:127 dmd_aaGetRvalue from DsymbolTable::lookup(Identifier const*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110113 ibuclaw at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |ASSIGNED --- Comment #9 from ibuclaw at gcc dot gnu.org --- (In reply to ibuclaw from comment #8) > Regression caused by upstream. > > https://github.com/dlang/dmd/pull/14837 Tracked it down to a memory corruption bug in the D front-end. There is a call to Mem.xrealloc(ptr) inside the escape analysis code, which allocates a new GC pointer, marking the old pointer as "free" to reuse by the next GC.malloc request. However, said pointer is to a data structure with Array(T) fields, each to which contain a pointer that references itself (a smallarray optimization). The corruption arises as eventually there are two references to the same address one that is reading/writing to it as an `VarDeclaration**`, the other as an `aaA**`. Segfault occurs as a result of aaGetRvalue interpreting a `VarDeclaration*` as an `aaA*`. Fix is in review, and will backport to both GCC-13 and GCC-12.
[Bug d/110113] gdc -fpreview=dip1021 crash in d/dmd/root/aav.d:127 dmd_aaGetRvalue from DsymbolTable::lookup(Identifier const*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110113 ibuclaw at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 URL||https://github.com/dlang/dm ||d/pull/14837 Last reconfirmed||2023-06-07 --- Comment #8 from ibuclaw at gcc dot gnu.org --- Regression caused by upstream. https://github.com/dlang/dmd/pull/14837
[Bug d/110113] gdc -fpreview=dip1021 crash in d/dmd/root/aav.d:127 dmd_aaGetRvalue from DsymbolTable::lookup(Identifier const*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110113 --- Comment #7 from ibuclaw at gcc dot gnu.org --- Same, but without any compiler errors. This is reproducible in upstream dmd too. dmd -lowmem -preview=dip1021 pr110113.d -o- --- class LUBench { } void lup(ulong , ulong , int , int = 1) { new LUBench; } void lup_3200(ulong iters, ulong flops) { lup(iters, flops, 3200); } void raytrace() { struct V { float x, y, z; auto normalize() { } struct Tid { } auto spawnLinked() { } string[] namesByTid; class MessageBox { } auto cross() { } } }
[Bug d/110113] gdc -fpreview=dip1021 crash in d/dmd/root/aav.d:127 dmd_aaGetRvalue from DsymbolTable::lookup(Identifier const*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110113 --- Comment #6 from ibuclaw at gcc dot gnu.org --- Full reduction without any imports. --- class LUBench { } void lup(ulong , ulong , int , int = 1) { new LUBench; } void lup_3200(ulong iters, ulong flops) { lup(iters, flops, 3200); } float raytrace() { struct V { float x, y, z; auto normalize() { } struct Tid { } Tid spawnLinked() { } string[] namesByTid; class MessageBox { } auto cross() { } } }
[Bug d/110113] gdc -fpreview=dip1021 crash in d/dmd/root/aav.d:127 dmd_aaGetRvalue from DsymbolTable::lookup(Identifier const*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110113 --- Comment #5 from ibuclaw at gcc dot gnu.org --- Reducing the std module down to the following always produces a crash in dmd_aaGetRvalue when running debian/ubuntu pre-compiled gdc-13 under gdb. --- struct Tid { MessageBox mbox; } struct ThreadInfo { bool[Tid] links; } class MessageBox { } --- Reproducing with own built gdc is proving to be elusive.
[Bug d/110113] gdc -fpreview=dip1021 crash in d/dmd/root/aav.d:127 dmd_aaGetRvalue from DsymbolTable::lookup(Identifier const*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110113 --- Comment #4 from ibuclaw at gcc dot gnu.org --- Test case should deterministically crash when kernel.randomize_va_space=0.
[Bug d/110113] gdc -fpreview=dip1021 crash in d/dmd/root/aav.d:127 dmd_aaGetRvalue from DsymbolTable::lookup(Identifier const*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110113 ibuclaw at gcc dot gnu.org changed: What|Removed |Added CC||ibuclaw at gcc dot gnu.org --- Comment #3 from ibuclaw at gcc dot gnu.org --- It would be handy if there was a test that didn't import all of Phobos.
[Bug d/109144] d: Closure fields don't get same alignment as local variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109144 ibuclaw at gcc dot gnu.org changed: What|Removed |Added Version|11.0|12.0 Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from ibuclaw at gcc dot gnu.org --- Fix committed, and only backporting as far as gcc-12.
[Bug d/109144] New: d: Closure fields don't get same alignment as local variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109144 Bug ID: 109144 Summary: d: Closure fields don't get same alignment as local variable Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: ibuclaw at gcc dot gnu.org Target Milestone: --- Between the variable declaration, and building its associated field in a closure, the decl alignment gets lost, so this fails. --- void main() { align(128) byte var; assert((cast(size_t) &var) % 128 == 0); var = 73; assert((() => var)() == 73); }
[Bug d/109108] d: Undefined reference to lambda in private enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109108 ibuclaw at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #4 from ibuclaw at gcc dot gnu.org --- Fix committed and backported.
[Bug d/109108] New: d: Undefined reference to lambda in private enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109108 Bug ID: 109108 Summary: d: Undefined reference to lambda in private enum Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: ibuclaw at gcc dot gnu.org Target Milestone: --- Similar to pr108055. Lambdas should be emitted in every module they are referenced from. ``` import other; void main() { auto a = callFun(1); } ``` ``` private enum int function(ref int)[] funs = [ 0: (ref idx) => 0, 1: (ref idx) => 1, ]; int callFun(I)(I idx) { return funs[idx](idx); } ``` Only compiling the "main" module results in linker errors. --- $ gdc test.d -Wl,--demangle=dlang /usr/x86_64-pc-linux-gnu/bin/ld: /tmp/ccDW8iNw.o: in function `other.callFun!(int).callFun(int)': test.d:(.text+0x4b): undefined reference to `other.__lambda4!(int).__lambda4(ref int)' test.d:(.text+0x56): undefined reference to `other.__lambda5!(int).__lambda5(ref int)' collect2: error: ld returned 1 exit status
[Bug d/109023] New: d: Add option to include imported modules in the compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109023 Bug ID: 109023 Summary: d: Add option to include imported modules in the compilation Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: ibuclaw at gcc dot gnu.org Target Milestone: --- The reference D compiler has an option `-i` that enables "include imports" mode, where the compiler will include imported modules in the compilation, as if they were given on the command line. Possibly some considerations: - This option might need to implicitly mean `-fwhole-program', as we don't want link-time errors to occur as a result of library symbols being in multiple DSOs (or do we?). - Would it complicate matters if the same DRT constructor/destructors end up in multiple DSOs? - Excluding libphobos and libdruntime modules from being compiled imports would avoid the main pitfalls I can think of occurring.
[Bug d/108763] va_arg usage in D doesn't compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108763 ibuclaw at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #8 from ibuclaw at gcc dot gnu.org --- Added note on the missing features page.
[Bug d/108877] Explicit immutable struct import internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108877 ibuclaw at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #7 from ibuclaw at gcc dot gnu.org --- Fix committed and backported.
[Bug d/108167] d: internal compiler error: in binary_op, at d/expr.cc:117
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108167 ibuclaw at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from ibuclaw at gcc dot gnu.org --- Fix has already been committed as part of a previous upstream/dmd merge. Added test.
[Bug d/108945] [13.0] d: vector float comparison doesn't result in 0 or -1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108945 ibuclaw at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from ibuclaw at gcc dot gnu.org --- Fix committed.
[Bug d/108946] [13.0] d: Identity comparison of vectors not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108946 ibuclaw at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from ibuclaw at gcc dot gnu.org --- Fix committed.
[Bug d/108962] New: d: Don't generate code that throws exceptions when compiling with `-fno-exceptions'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108962 Bug ID: 108962 Summary: d: Don't generate code that throws exceptions when compiling with `-fno-exceptions' Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: ibuclaw at gcc dot gnu.org Target Milestone: --- There are a few constructs that implicitly raise an Error exception, for example, `final switch`. ``` void main() { final switch (0) { case 1: return; } } ``` It might be more desirable to instead abort the runtime, optionally creating a trace before exiting.
[Bug d/108946] New: [13.0] d: Identity comparison of vectors not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108946 Bug ID: 108946 Summary: [13.0] d: Identity comparison of vectors not supported Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: ibuclaw at gcc dot gnu.org Target Milestone: --- The operation `bool r = vector1 is vector2;` should be allowed by the D front-end codegen, and have a boolean result.
[Bug d/108945] New: [13.0] d: vector float comparison doesn't result in 0 or -1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108945 Bug ID: 108945 Summary: [13.0] d: vector float comparison doesn't result in 0 or -1 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: ibuclaw at gcc dot gnu.org Target Milestone: --- This is because we're using VEC_COND_EXPR using a float vector in both the true and false branches, this then reinterprets `-1.0f' as an integer. Only affects mainline, as vector comparison is a new addition to the D implementation.
[Bug d/108877] Explicit immutable struct import internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108877 ibuclaw at gcc dot gnu.org changed: What|Removed |Added CC||ibuclaw at gcc dot gnu.org --- Comment #1 from ibuclaw at gcc dot gnu.org --- Immutable is the keyword here. Stub debug symbols are only attached to the main variant of a type. I think this would also be reproducible with `immutable class` and `immutable enum` as well. Have fix really to commit and backport once I test it. --- diff --git a/gcc/d/imports.cc b/gcc/d/imports.cc index 3b46d1b7560..2efef4ed54f 100644 --- a/gcc/d/imports.cc +++ b/gcc/d/imports.cc @@ -106,12 +106,16 @@ public: tree type = build_ctype (d->type); /* Not all kinds of D enums create a TYPE_DECL. */ if (TREE_CODE (type) == ENUMERAL_TYPE) - this->result_ = this->make_import (TYPE_STUB_DECL (type)); + { + type = TYPE_MAIN_VARIANT (type); + this->result_ = this->make_import (TYPE_STUB_DECL (type)); + } } void visit (AggregateDeclaration *d) final override { tree type = build_ctype (d->type); +type = TYPE_MAIN_VARIANT (type); this->result_ = this->make_import (TYPE_STUB_DECL (type)); } @@ -119,6 +123,7 @@ public: { /* Want the RECORD_TYPE, not POINTER_TYPE. */ tree type = TREE_TYPE (build_ctype (d->type)); +type = TYPE_MAIN_VARIANT (type); this->result_ = this->make_import (TYPE_STUB_DECL (type)); }
[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977 --- Comment #29 from ibuclaw at gcc dot gnu.org --- (In reply to Iain Sandoe from comment #27) > great! > > we make more progress now - at least past libphobos configure: > > we now fail building druntime/core/atomic.d and I am not quite sure how to > interpret the backtrace (from b internal_error). > > d21`_D3dmd6access17checkSymbolAccessFPSQBh6dscope5ScopeCQBy7dsymbol7DsymbolZb > (sc=, s=) at access.d:296 > My fear is that now it's corrupting the return in other ways now, this time within D itself. access.d:296: final switch (s.visible().kind)
[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977 --- Comment #26 from ibuclaw at gcc dot gnu.org --- Comparing the D and C++ trees side by side. At the point of `finish_function` for the ::vis() method, I see the following: D: type
[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977 --- Comment #24 from ibuclaw at gcc dot gnu.org --- (In reply to Iain Sandoe from comment #23) > So the ABIs differ in this (as noted on IRC, the Darwin 32b ABIs are not the > same as Linux). I'm still yet to work out why D on 32-bit Darwin behaves the same as 32-bit Linux though. I would have assumed the decision to generate an sret would occur long after the front-end has freed itself from the compilation process. Regardless, the ABI issue can be raised in a separate PR. Because of it though, that means for this bootstrap PR we just have to avoid calling any extern(C++) method implemented in D that returns a struct by value.
[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977 --- Comment #22 from ibuclaw at gcc dot gnu.org --- (In reply to ibuclaw from comment #21) > There is something about the Darwin ABI I'm just not getting from looking at > the front-end alone though: Taken from a test Iain had sent me, and I've subsequently modified. ``` struct Visibility { enum Kind { undefined, none, private_, package_, protected_, public_, export_ }; Kind kind; void *pkg; }; class Bar { public: int x; virtual Visibility vis (); }; Visibility Bar::vis () { return Visibility (); } class Foo : public Bar { public: Visibility v; int y; Visibility vis () override final; }; Visibility Foo::vis () { return v; } int test (Bar *foo) { Visibility vis; vis = foo->vis (); return vis.kind; } ```
[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977 --- Comment #21 from ibuclaw at gcc dot gnu.org --- There is something about the Darwin ABI I'm just not getting from looking at the front-end alone though: C++ Darwin 32-bit calling a method that returns an 8 byte struct: ``` __Z4testP3Bar: subl$24, %esp movl28(%esp), %eax movl(%eax), %edx pushl %eax// <-- call*(%edx) ``` C++ Linux 32-bit calling a method that returns an 8 byte struct: ``` _Z4testP3Bar: subl$44, %esp movl%gs:20, %edx movl%edx, 28(%esp) xorl%edx, %edx movl48(%esp), %eax leal8(%esp), %ecx subl$8, %esp movl(%eax), %edx pushl %eax// <-- pushl %ecx// <-- call*(%edx) ```
[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977 --- Comment #20 from ibuclaw at gcc dot gnu.org --- (In reply to Andrew Pinski from comment #19) > (In reply to Andrew Pinski from comment #18) > > > I think the visibility type is POD (assuming D has that concept) > > At least the front-end does. > See dmd/dstruct.d:443 > > if isPOD return false, TREE_ADDRESSABLE is set on the struct. > I have not gone through the code otherwise. See d/decl.cc:950 It's not TREE_ADDRESSABLE, but on 32-bit the struct is considered to be 'aggregate_value_p', which in turn sets up return by hidden reference. This effects how the return is handled later (around toir.cc:1044), which splits up the init and return expression. Returning this way I guess is fine for extern(D) functions, however we should not be so eager to do rvo/sret for other extern language functions. Having a quick look at C++ front-end, they require both `aggregate_value_p` and for a named variable to be in the return expression. ``` if (current_function_return_value) { tree r = current_function_return_value; tree outer; if (r != error_mark_node /* This is only worth doing for fns that return in memory--and simpler, since we don't have to worry about promoted modes. */ && aggregate_value_p (TREE_TYPE (TREE_TYPE (fndecl)), fndecl) ``` So for the current gate in D: ``` if (TREE_ADDRESSABLE (TREE_TYPE (resdecl)) || aggregate_value_p (TREE_TYPE (resdecl), fndecl)) ``` I think tightening that to (its late, and my parentheses may be wrong). ``` if (TREE_ADDRESSABLE (TREE_TYPE (resdecl)) || ((d->resolvedLinkage () == LINK::d || (d->resolvedLinkage () == LINK::cpp && d->nrvo_var)) && aggregate_value_p (TREE_TYPE (resdecl), fndecl))) ``` Which is: 1. TREE_ADDRESSABLE 2. extern(D) and aggregate_value_p 3. extern(C++) and have NVRO variable and aggregate_value_p I guess for extern(C) functions we should just forget even attempting to do any (N)RVO/SRET returns and let tree-nrv.cc decide whether to optimize or not.
[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977 --- Comment #13 from ibuclaw at gcc dot gnu.org --- Confirmed, D is doing NRVO return whereas C++ isn't. gdc-11 codegen of the `visible` method: --- struct Visibility visible (struct AggregateDeclaration * const this) { return = this->visibility; } --- vs. gdc-mainline --- struct Visibility visible (struct AggregateDeclaration * const this) { = this->visibility; return ; } ---
[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977 --- Comment #12 from ibuclaw at gcc dot gnu.org --- Looks like a bad mismatch between C++ and D. When C++ calls the method, it pushes one register. When D calls it, pushes two. Looks like the method itself returns the result in 2 registers as well - or maybe uses return slot optimization. --- // C++ Caller code #include "tree.h" #include "dmd/dsymbol.h" #include "dmd/aggregate.h" void set_visibility_for_decl (tree node, Dsymbol *sym) { Visibility visibility = sym->visible (); // C++ Caller asm pushl %ebx subl$20, %esp .loc 1 2561 1 movl32(%esp), %eax movl28(%esp), %ebx .loc 1 2562 40 movl(%eax), %edx pushl %eax call*104(%edx) // D Caller code import dmd.dsymbol; import dmd.aggregate; import dmd.gluelayer; extern(C++) void set_visibility_for_decl (tree_node* node, Dsymbol sym) { Visibility visibility = sym.visible(); } // D Caller asm subl$28, %esp .loc 1 5 1 movl36(%esp), %eax .loc 1 8 27 leal8(%esp), %ecx subl$8, %esp movl(%eax), %edx pushl %eax pushl %ecx call*104(%edx) // D Callee code override final Visibility visible() pure nothrow @nogc @safe { return visibility; } // D Callee asm movl8(%esp), %edx movl4(%esp), %eax .loc 1 789 9 movl208(%edx), %ecx movl212(%edx), %edx movl%ecx, (%eax) movl%edx, 4(%eax) .loc 1 790 5 ret $4
[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977 --- Comment #10 from ibuclaw at gcc dot gnu.org --- Without using `->visible()` would be something like: --- a/gcc/d/decl.cc +++ b/gcc/d/decl.cc @@ -2559,10 +2561,17 @@ set_linkage_for_decl (tree decl) void set_visibility_for_decl (tree node, Dsymbol *sym) { - Visibility visibility = sym->visible (); - if (visibility.kind == Visibility::private_) + Visibility::Kind kind; + if (AggregateDeclaration *ad = sym->isAggregateDeclaration ()) +kind = ad->visibility.kind; + else if (Declaration *d = sym->isDeclaration ()) +kind = d->visibility.kind; + else +gcc_unreachable (); + + if (kind == Visibility::private_) TREE_PRIVATE (node) = 1; - else if (visibility.kind == Visibility::protected_) + else if (kind == Visibility::protected_) TREE_PROTECTED (node) = 1; /* If the declaration was declared `export', append either the dllimport
[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977 --- Comment #9 from ibuclaw at gcc dot gnu.org --- (In reply to Iain Sandoe from comment #8) > + > +/* NODE is a FUNCTION_DECL, VAR_DECL or RECORD_TYPE for the declaration SYM. > + Set flags to reflect visibility that NODE will get in the object file. > */ > + > +void > +set_visibility_for_decl (tree node, Dsymbol *sym) > > hmmm.. should the call be "set_visibility_for_decl (decl, decl->csym); ? > > or should the signature of set_visibility_for_decl() be > set_visibility_for_decl (Dsymbol *sym, tree node)? > > or maybe I misread the comment I might be unclear, first parameter (NODE) is a tree *_DECL representation for the second parameters (SYM) that is the associated front-end symbol.
[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977 ibuclaw at gcc dot gnu.org changed: What|Removed |Added CC||ibuclaw at gcc dot gnu.org --- Comment #6 from ibuclaw at gcc dot gnu.org --- There's r13-1113 with introduced the use of visible(). Can't see anything odd about the virtual function declaration that would suggest there's a mismatch between C++/D. It does return a struct though. Is there maybe something special done in the way structs are returned on 32-bit OSX that doesn't occur on 32-bit Linux? I could also just revert to accessing the underlying `->visibility` field directly, if it really is just that function call that's problematic.
[Bug d/108763] va_arg usage in D doesn't compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108763 --- Comment #6 from ibuclaw at gcc dot gnu.org --- I'll add it as a note to the deviations page. https://gcc.gnu.org/onlinedocs/gdc/Missing-Features.html#Missing-Features I'd actually forgotten about this.
[Bug d/108763] va_arg usage in D doesn't compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108763 ibuclaw at gcc dot gnu.org changed: What|Removed |Added CC||ibuclaw at gcc dot gnu.org --- Comment #5 from ibuclaw at gcc dot gnu.org --- I abandoned the idea of supporting RTTI-based variadics years ago. Even the current reference implementation only supports a subset of the x86_64 ABI in its current incarnation as far as I recall. I had considered maybe libffi might allow us to do this, but I didn't see anything that would allow me to say "retrieve the next variadic argument of size SIZE and mode MODE". But I could not see anything that looked exactly as that, even though as I understand there is limited support for constructing a variadic call to a C function.
[Bug d/108408] libphobos: Support building on *-*-cygwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108408 --- Comment #5 from ibuclaw at gcc dot gnu.org --- (In reply to Corinna from comment #4) > I'm not sure what you mean with "hybrid". Probably the wrong word to use, based on what I was told via gcc irc. """ the relationship of cygwin1.dll and newlib seems a lil strange afaict cygwin1.dll is a superset of newlib functionality """ > Having said that, there's no "one size fits all" for all supported > targets in newlib, so to support newlib targets in general, a preprocessor > based solution would be extremly helpful. In D, there's `static if` for that. Features can either be hard tuned in a config.d module (core/sys/cygwin/config.d?) or detected at configure-time and put into gcc/config.d.in.
[Bug d/108408] libphobos: Support building on *-*-cygwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108408 --- Comment #3 from ibuclaw at gcc dot gnu.org --- So a big part of what's missing in druntime bindings is *any* declarations for version(CRuntime_Newlib) targets. Though as I understand it, Cygwin is a bit of a hybrid in that matter.
[Bug d/108408] libphobos: Support building on *-*-cygwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108408 ibuclaw at gcc dot gnu.org changed: What|Removed |Added CC||ibuclaw at gcc dot gnu.org --- Comment #2 from ibuclaw at gcc dot gnu.org --- (In reply to nightstrike from comment #0) > +struct _Bigint { > +_Bigint* _next; > +int _k; > +int _maxwds; > +int _sign; > +int _wds; > +ulong[1] _x; > +} --snip-- > +_Bigint* _p5s; > +int _result_k; > +_Bigint* _result; > +_Bigint** _freelist; If some of these definitions are just going to be pointer fields in other structs, can definitely loose the definition, and just declare an opaque struct instead (struct _Bigint;)
[Bug d/108167] New: d: internal compiler error: in binary_op, at d/expr.cc:117
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108167 Bug ID: 108167 Summary: d: internal compiler error: in binary_op, at d/expr.cc:117 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: ibuclaw at gcc dot gnu.org Target Milestone: --- auto gdcTrunkICE(const(ubyte[32])[] a) { return cast(const(ubyte)*)&a[1][0]; } Caused by a front-end change that changed `&a[1][0]` into `&a[1] + null`.
[Bug d/106832] Missing powerpc64le-linux support for D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106832 ibuclaw at gcc dot gnu.org changed: What|Removed |Added CC||ibuclaw at gcc dot gnu.org --- Comment #15 from ibuclaw at gcc dot gnu.org --- (In reply to Peter Bergner from comment #14) > Similar error on a long double == IEEE128 system: > > /home/bergner/gcc/gcc-fsf-mainline-lang-D/libphobos/src/std/math.d:281:5: > error: static assert "Only 64-bit, 80-bit, and 128-bit reals are supported > for LittleEndian CPUs" > 281 | static assert(real.mant_dig == 53 || real.mant_dig == 64 > | ^ Looks like you configured for IBM128 to me.
[Bug d/105544] gdc fails to compile d source from stdin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105544 --- Comment #10 from ibuclaw at gcc dot gnu.org --- (In reply to Fabian Vogt from comment #9) > (In reply to ibuclaw from comment #8) > > (In reply to Fabian Vogt from comment #6) > > > I had a quick debugging session: The DMD lexer code doesn't really care > > > about the size of the buffer and instead runs until it encounters either > > > a 0 > > > or 0x1A byte. The stdin read loop in d_parse_file doesn't explicitly > > > 0-terminate the buffer, which means that it works randomly... > > > > > > > OK, so the suggestion would be to zero the padding at the end of the input > > buffer then. > > > > --- a/gcc/d/d-lang.cc > > +++ b/gcc/d/d-lang.cc > > @@ -1072,6 +1072,10 @@ d_parse_file (void) > > global.params.doHdrGeneration); > > modules.push (m); > > > > + /* Zero the padding past the end of the buffer so the D lexer has a > > +sentinel. The lexer only reads up to 4 bytes at a time. */ > > + memset (buffer + len, '\0', 16); > > + > > /* Overwrite the source file for the module, the one created by > > Module::create would have a forced a `.d' suffix. */ > > m->src.length = len; > > Yep, that should work. Though I wonder why 16B of padding and not just a > single byte for the 0. FWICT the lexer reads a single byte at a time only > (utf8_t is an unsigned char), so it should stop at the first 0. > > The comment above explaining the padding mentions a "final '\n'" which > should probably be adjusted with the change to \0. The lexer scans spaces 4 bytes at a time (*cast(uint*)p == 0x20202020). So should zero at least 4 bytes to avoid asan complaining about reading uninitialized memory.
[Bug d/105544] gdc fails to compile d source from stdin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105544 --- Comment #8 from ibuclaw at gcc dot gnu.org --- (In reply to Fabian Vogt from comment #6) > I had a quick debugging session: The DMD lexer code doesn't really care > about the size of the buffer and instead runs until it encounters either a 0 > or 0x1A byte. The stdin read loop in d_parse_file doesn't explicitly > 0-terminate the buffer, which means that it works randomly... > OK, so the suggestion would be to zero the padding at the end of the input buffer then. --- a/gcc/d/d-lang.cc +++ b/gcc/d/d-lang.cc @@ -1072,6 +1072,10 @@ d_parse_file (void) global.params.doHdrGeneration); modules.push (m); + /* Zero the padding past the end of the buffer so the D lexer has a +sentinel. The lexer only reads up to 4 bytes at a time. */ + memset (buffer + len, '\0', 16); + /* Overwrite the source file for the module, the one created by Module::create would have a forced a `.d' suffix. */ m->src.length = len;
[Bug d/105544] gdc fails to compile d source from stdin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105544 --- Comment #4 from ibuclaw at gcc dot gnu.org --- Ah, it's likely something even more fiendish than that. What encodings are you using? (i.e: locale -a)
[Bug d/105544] gdc fails to compile d source from stdin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105544 --- Comment #2 from ibuclaw at gcc dot gnu.org --- What version of glibc are you using? Not encountered this myself from debian's gcc packages. $ echo "pragma(msg, int(__VERSION__));" | /usr/bin/gdc-9 -c -x d - 2076 $ echo "pragma(msg, int(__VERSION__));" | /usr/bin/gdc-10 -c -x d - 2076 $ echo "pragma(msg, int(__VERSION__));" | /usr/bin/gdc-11 -c -x d - 2076 $ echo "pragma(msg, int(__VERSION__));" | /usr/bin/gdc-12 -c -x d - 2099
[Bug d/103604] [12 Regression] trunk 20210506 fails to build in libphobos on mips64el-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103604 ibuclaw at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |ASSIGNED --- Comment #8 from ibuclaw at gcc dot gnu.org --- (In reply to YunQiang Su from comment #7) > Where should we fallback this patch to? I can submit it to upstream dlang/druntime (on github) and merged it in when I next do the sync later this week.
[Bug d/103604] [12 Regression] trunk 20210506 fails to build in libphobos on mips64el-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103604 ibuclaw at gcc dot gnu.org changed: What|Removed |Added CC||ibuclaw at gcc dot gnu.org --- Comment #5 from ibuclaw at gcc dot gnu.org --- (In reply to YunQiang Su from comment #4) > but where is the stat_t of D is defined? In libphobos/libdruntime/core/sys/posix/sys/stat.d
[Bug d/102837] [12 regression] Many 32-bit gdc tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102837 ibuclaw at gcc dot gnu.org changed: What|Removed |Added CC||ibuclaw at gcc dot gnu.org --- Comment #4 from ibuclaw at gcc dot gnu.org --- (In reply to r...@cebitec.uni-bielefeld.de from comment #3) > Actually, it's > > commit efa5449a094d3887e124d400ff0410af2c745b2d > Author: Iain Buclaw > Date: Sat Sep 25 19:50:52 2021 +0200 > > libphobos: Give _Unwind_Exception an alignment that best resembles > __attribute__((aligned)) > > in particular > > +else version (X86) private enum __aligned__ = 16; > > I don't yet see where/how struct _Unwind_Execption is allocated to > guarantee that alignment. Depending on the answer PR libstdc++/77691 > (32-bit Solaris/x86 malloc only returns 8-byte aligned memory) or the > fact that the stack is only 4-byte aligned following the i386 psABI) may > be relevant. i386 psABI would likely be the most relevant detail here. I'll see if exposing the value of __attribute__((aligned)) to D CTFE is possible.
[Bug tree-optimization/102673] [9 Regression] Wrong code with -O due to adjust_cond_for_loop_until_wrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102673 ibuclaw at gcc dot gnu.org changed: What|Removed |Added Resolution|DUPLICATE |FIXED --- Comment #4 from ibuclaw at gcc dot gnu.org --- (In reply to Andrew Pinski from comment #3) > exact dup of bug 102666 :). > > *** This bug has been marked as a duplicate of bug 102666 *** Excellent, I just saw it hit my queue for the D front-end, with no context of where they got it from. :-)
[Bug tree-optimization/102673] [9 Regression] Wrong code with -O due to adjust_cond_for_loop_until_wrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102673 --- Comment #2 from ibuclaw at gcc dot gnu.org --- (In reply to ibuclaw from comment #0) > Bisected, and the commit that changed behaviour was the fix for pr84648. Commit was r9-4145.
[Bug tree-optimization/102673] [9 Regression] Wrong code with -O due to adjust_cond_for_loop_until_wrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102673 --- Comment #1 from ibuclaw at gcc dot gnu.org --- Since pr101145, the function this now happens in is number_of_iterations_until_wrap.
[Bug tree-optimization/102673] New: [9 Regression] Wrong code with -O due to adjust_cond_for_loop_until_wrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102673 Bug ID: 102673 Summary: [9 Regression] Wrong code with -O due to adjust_cond_for_loop_until_wrap Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: ibuclaw at gcc dot gnu.org Target Milestone: --- Reduced test, when compiled with -O, optimizes the loop into `return 1;`. --- int main() { for (unsigned a = 0, b = 0; a < 6; a += 1, b += 2) { if (b < a) return 1; } return 0; } --- https://godbolt.org/z/YM7aYrY8v Bisected, and the commit that changed behaviour was the fix for pr84648.
[Bug d/102618] d-demangle: anonymous symbols are not being properly skipped
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102618 ibuclaw at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ibuclaw at gcc dot gnu.org Component|demangler |d CC||ibuclaw at gcc dot gnu.org --- Comment #1 from ibuclaw at gcc dot gnu.org --- How did you check this? The given example passes the testsuite. # --format=dlang _D8demangle9anonymous03fooZ demangle.anonymous.foo
[Bug d/102094] New: d: ICE in gimple_register_canonical_type_1, at lto/lto-common.c:430
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102094 Bug ID: 102094 Summary: d: ICE in gimple_register_canonical_type_1, at lto/lto-common.c:430 Product: gcc Version: 11.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: ibuclaw at gcc dot gnu.org Target Milestone: --- Looks like there's a TYPE_CXX_ODR_P mismatch between D closure frames and user defined types. --- extern(C) int printf(char* s, ...); struct Wow { int a; } void formatValue() { Wow x; void nested() { printf(cast(char*)0, x); } }
[Bug d/102093] New: d: Add --enable-d-flags= configure option to libphobos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102093 Bug ID: 102093 Summary: d: Add --enable-d-flags= configure option to libphobos Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: ibuclaw at gcc dot gnu.org Target Milestone: --- To do the same action as --enable-cxx-flags=