[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
[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=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 *)] = _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*)_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) ) % 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)*)[1][0];
}
Caused by a front-end change that changed `[1][0]` into `[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=
[Bug d/90719] libphobos.phobos_shared/std/file.d FAILs on 32-bit Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90719 ibuclaw at gcc dot gnu.org changed: What|Removed |Added CC||ibuclaw at gcc dot gnu.org --- Comment #9 from ibuclaw at gcc dot gnu.org --- (In reply to Rainer Orth from comment #8) > Unfortunately, something went wrong here: while my original patch removed > st_pad3 > from the non-D_LP64 struct stat64_t, yours changed stat32_t instead, which > leaves > the affected test broken: > > FAIL: libphobos.phobos_shared/std/file.d execution test Oops, I must have both misunderstood your original bug report (you mentioned stat32_t) *and* the patch applied against the wrong struct. Fix sent here: https://github.com/dlang/druntime/pull/3078 I'll downstream it (again) as soon as it's in. For GCC-11, I should really finish off some automated C header -> D conversion tool, as you know all too well the pains of maintaining the current stdc and sys packages in D runtime.
