[Bug d/117115] [14/15 regression] ICE in expand_d_format when diagnosing an empty enum declaration since r14-4663-g964fd402c9b48e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117115 --- Comment #4 from Iain Buclaw --- Upstream fix. https://github.com/dlang/dmd/pull/17004
[Bug d/117115] [14/15 regression] ICE in expand_d_format when diagnosing an empty enum declaration since r14-4663-g964fd402c9b48e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117115 --- Comment #3 from Iain Buclaw --- Introduced upstream by: https://github.com/dlang/dmd/pull/15664 Before: --- enum `object.Foo` enum `Foo` must have at least one member --- After: --- enum `object.Foo enum `Foo` must have at least one member --- There's no coverage from the upstream D2 testsuite either it seems. https://github.com/dlang/dmd/pull/15664/files#diff-862192b33df815981dcb4a8a49bc7dc572506b444a7dc034fde3643f887e2982L2220-R2221
[Bug d/117115] [14/15 regression] ICE in expand_d_format when diagnosing an empty enum declaration since r14-4663-g964fd402c9b48e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117115 --- Comment #2 from Iain Buclaw --- The assert hit is: gcc_assert (!inbacktick); One of the DMD front-end errors likely has an odd number of backticks in the format string.
[Bug middle-end/117002] [13/14/15 Regression] lifetime.d: In function ‘_d_newclassT’: error: size of array element is not a multiple of its alignment with -Warray-bounds and -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117002
Iain Buclaw changed:
What|Removed |Added
CC||ibuclaw at gdcproject dot org
--- Comment #2 from Iain Buclaw ---
Initial reduction, though @Andrew may have given the needed hint to remove the
class declaration (all D classes have a void** vptr pointing at a vtable array)
---
module object;
extern(C++) class Foo {
ubyte[4] not_multiple_of_8;
}
int pr117002(void *p)
{
auto init = __traits(initSymbol, Foo);
if (init.ptr + init.length <= p)
return 1;
return 0;
}
[Bug d/116373] [14/15 regression] ICE in dmd.expressionsem.resolveLoc since r14-8766-gf204359931866b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116373 Iain Buclaw changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=24519 --- Comment #1 from Iain Buclaw --- Upstream fix. https://github.com/dlang/dmd/pull/16408
[Bug d/115295] [15 regression] Various gdc testsuite regressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115295 Iain Buclaw changed: What|Removed |Added CC||ibuclaw at gdcproject dot org --- Comment #6 from Iain Buclaw --- Was a fix ever committed? I've been on a 2-month vacation, and when coming back and recompiling/running the D testsuite, I get a fair number of UNSUPPORTED failures for all tests that make use of dg-additional-sources. This'll make it difficult to update the language implementation with the latest version and be sure there're no new regressions.
[Bug d/114155] gdc.test/runnable/literal.d FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114155 Iain Buclaw changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #4 from Iain Buclaw --- Resolved.
[Bug d/109681] suggested preview switches use DMD preview flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109681 Iain Buclaw changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #1 from Iain Buclaw --- For now, upstream has version condition around the error messages to give the gdc-style option names if version(IN_GCC). https://github.com/dlang/dmd/pull/15747 Downstreamed into mainline since r14-5083.
[Bug d/114155] gdc.test/runnable/literal.d FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114155 --- Comment #2 from Iain Buclaw --- Fix to format hexstrings as big endian has been committed from upstream merge. r14-9505 This should be resolved now.
[Bug d/113081] static linking does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113081
--- Comment #3 from Iain Buclaw ---
(In reply to Iain Buclaw from comment #2)
> If I recall correctly, this trick is not guaranteed to work (for a
> drtbegin.o and drtend.o object), as there really no control over where in
> the TLS section these variables will land.
>
> ```
> #ifdef DRT_BEGIN
> _Thread_local __SIZE_TYPE__ __tls_start = 3;
> #endif
>
> #ifdef DRT_END
> _Thread_local __SIZE_TYPE__ __tls_end;
> #endif
> ```
Both of these rely on the default linker script of:
.tdata : { *(.tdata .tdata.* .gnu.linkonce.td.*) }
.tbss : { *(.tbss .tbss.* .gnu.linkonce.tb.*) *(.tcommon) }
to group the sections in that order.
According to some old commit notes of mine for gdc in 2013, ld can reorder
.tdata after .tdata.*, despite what the linker script says.
[Bug d/113081] static linking does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113081 --- Comment #2 from Iain Buclaw --- It could be moved to drtstuff.o to avoid it being in the library, but unless there's an equivalent function available there'll be crashes caused by the GC free'ing live objects as it did not scan all TLS variables for the executing thread. If I recall correctly, this trick is not guaranteed to work (for a drtbegin.o and drtend.o object), as there really no control over where in the TLS section these variables will land. ``` #ifdef DRT_BEGIN _Thread_local __SIZE_TYPE__ __tls_start = 3; #endif #ifdef DRT_END _Thread_local __SIZE_TYPE__ __tls_end; #endif ```
[Bug d/112290] self-referencing `in` parameter with `-fpreview=in` causes ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112290 Iain Buclaw changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #4 from Iain Buclaw --- Fix committed and backported.
[Bug d/112285] `in` class parameter with `gdc -fpreview=in` causes ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112285 Iain Buclaw changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #4 from Iain Buclaw --- Fix committed and backported.
[Bug d/114171] [13/14 Regression] gdc -O2 -mavx generates misaligned vmovdqa instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114171 Iain Buclaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #11 from Iain Buclaw --- Fix committed and backported.
[Bug d/113125] [D] internal compiler error: in make_import, at d/imports.cc:48
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113125 Iain Buclaw changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #5 from Iain Buclaw --- Fixed and backported.
[Bug d/113758] d: Callee destructor call invalidates the live object, not the temporary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113758 Iain Buclaw changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #5 from Iain Buclaw --- Fixed and backported.
[Bug d/114171] [13/14 Regression] gdc -O2 -mavx generates misaligned vmovdqa instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114171 --- Comment #6 from Iain Buclaw --- (In reply to Richard Biener from comment #5) > Unless gdc somehow guarantees bn->label and init are 128bit aligned > then "casting" this way is broken. You can of course use > build_aligned_type to build a properly (mis-)aligned type to use > to dereference to. Right, it looks like the lowering for struct comparisons wasn't taking the original alignment into account when doing identity comparisons of struct-like fields. --- --- a/gcc/d/d-codegen.cc +++ b/gcc/d/d-codegen.cc @@ -1006,6 +1006,7 @@ lower_struct_comparison (tree_code code, StructDeclaration *sd, if (tmode == NULL_TREE) tmode = make_unsigned_type (GET_MODE_BITSIZE (mode.require ())); + tmode = build_aligned_type (tmode, TYPE_ALIGN (stype)); t1ref = build_vconvert (tmode, t1ref); t2ref = build_vconvert (tmode, t2ref); --- The above change gets reflected in the generated assembly. --- @@ -326,7 +326,7 @@ _Dmain: subq$8, %rsp .cfi_def_cfa_offset 16 call_D8pr1141718newclassFNbNiZPSQBa14BreakStatement - vmovdqa 8(%rax), %xmm0 + vmovdqu 8(%rax), %xmm0 xorl%eax, %eax vptest %xmm0, %xmm0 sete%al ---
[Bug d/114171] [13/14 Regression] gdc -O2 -mavx generates misaligned vmovdqa instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114171
--- Comment #4 from Iain Buclaw ---
Removed druntime dependency.
---
import gcc.builtins;
struct Token {
string label;
}
struct BreakStatement {
ulong pad;
Token label;
}
pragma(inline, false)
auto newclass()
{
void *p = __builtin_malloc(BreakStatement.sizeof);
__builtin_memset(p, 0, BreakStatement.sizeof);
return cast(BreakStatement*) p;
}
int main ()
{
auto bn = newclass();
return bn.label is Token.init;
}
---
Roughly the equivalent C++
---
struct Token {
struct {
__SIZE_TYPE__ length;
const char *ptr;
} label;
};
struct BreakStatement {
__UINT64_TYPE__ pad;
Token label;
};
__attribute__((noinline))
BreakStatement *newclass()
{
void *p = __builtin_malloc(sizeof(BreakStatement));
__builtin_memset(p, 0, sizeof(BreakStatement));
return (BreakStatement*) p;
}
int main ()
{
auto bn = newclass();
auto init = Token();
return *(__uint128_t*)&bn->label == *(__uint128_t*)&init;
}
---
[Bug d/114155] gdc.test/runnable/literal.d FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114155 --- Comment #1 from Iain Buclaw --- Upstream is notified, https://github.com/dlang/dmd/pull/16263#issuecomment-1969502776
[Bug d/113772] [14 Regression] atomic.d compile error since recent upstream imports.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772 Iain Buclaw changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #16 from Iain Buclaw --- Fix downstreamed.
[Bug d/113667] [14 Regression] libgphobos symbols missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113667 Iain Buclaw changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Iain Buclaw --- Bumped.
[Bug d/113772] [14 Regression] atomic.d compile error since recent upstream imports.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772 --- Comment #11 from Iain Buclaw --- (In reply to Iain Sandoe from comment #10) > (In reply to Iain Buclaw from comment #8) > > Created attachment 57329 [details] > > The quick fix to the lock-free test > > > > The immediate thing that can be changed is turning the test into a > > `__traits(compiles)` one, which would turn the error into a `false` value. > > This works for me on both powerpc64-linux and a powerpc-darwin9 cross. > > NOTE: I expect a reduced testsuite on powerpc-darwin since we build > "--with-libphobos-druntime-only" however, I am a bit surprised that > powerpc64-linux has roughly half the number of tests (590 c.f. 1100) of > x86_64-linux; is this expected? (independent of this fix, this was the case > before too). Yes, powerpc64-linux has phobos disabled by default in libphobos/configure.tgt.
[Bug d/113772] [14 Regression] atomic.d compile error since recent upstream imports.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772 --- Comment #9 from Iain Buclaw --- (In reply to Iain Buclaw from comment #8) > Created attachment 57329 [details] > The quick fix to the lock-free test > > The immediate thing that can be changed is turning the test into a > `__traits(compiles)` one, which would turn the error into a `false` value. I wonder though whether maybe the D compiler could push out some manifest constants into the gcc.builtins module similar to the __GCC_ATOMIC_LLONG_LOCK_FREE macros.
[Bug d/113772] [14 Regression] atomic.d compile error since recent upstream imports.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772 --- Comment #8 from Iain Buclaw --- Created attachment 57329 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57329&action=edit The quick fix to the lock-free test The immediate thing that can be changed is turning the test into a `__traits(compiles)` one, which would turn the error into a `false` value.
[Bug d/113772] [14 Regression] atomic.d compile error since recent upstream imports.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772 --- Comment #7 from Iain Buclaw --- (In reply to Iain Sandoe from comment #6) > (In reply to Iain Buclaw from comment #4) > > Looking at gcc/builtins.cc, I have a bad feeling that the only compile-time > > > > /* If it isn't always lock free, don't generate a result. */ > > if (fold_builtin_atomic_always_lock_free (arg0, arg1) == > > boolean_true_node) > > return boolean_true_node; > > > ^ but this does fall back to a libcall to the relevant libatomic function, > (you can verify that with a simple C routine).. and given that both darwin > and linux powerpc have libatomic impls. this still should not give an > "unimplemented" response. The diagnostic is misleading. I gather it assumes "unimplemented" because there is no function body for CTFE to evaluate after the attempt to expand via gcc builtins.cc failed.
[Bug d/113772] [14 Regression] atomic.d compile error since recent upstream imports.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772
--- Comment #4 from Iain Buclaw ---
Looking at gcc/builtins.cc, I have a bad feeling that the only compile-time
values one can get out of this built-in are "true" and "defer to run-time"
---
/* Return a one or zero if it can be determined that object ARG1 of size ARG
is lock free on this architecture. */
static tree
fold_builtin_atomic_is_lock_free (tree arg0, tree arg1)
{
if (!flag_inline_atomics)
return NULL_TREE;
/* If it isn't always lock free, don't generate a result. */
if (fold_builtin_atomic_always_lock_free (arg0, arg1) == boolean_true_node)
return boolean_true_node;
return NULL_TREE;
}
---
The upstream contributor who tested this on x86 likely didn't get this because
it's all lock-free.
[Bug d/113772] [14 Regression] atomic.d compile error since recent upstream imports.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772 --- Comment #2 from Iain Buclaw --- (In reply to Iain Sandoe from comment #0) > I am now seeing this on both Darwin and Linux BE powerpc. > > The message is somewhat odd, since AFAICS from the core druntime code that > pulls in builtins.def which pulls in sync-builtins.def - which defines this > builtin. > > If I check the C compiler manually, then the builtin works as expected - > inline for 1,2,4 bytes and out-of-line call to the atomic library for 8+ > (32b PPC). Yes, that's correct. The contents of the builtins module can be dumped with: ``` // builtins.d module gcc.builtins; ``` gdc -H builtins.d && cat builtins.di I can check this shortly.
[Bug d/113772] [14 Regression] atomic.d compile error since recent upstream imports.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772 --- Comment #1 from Iain Buclaw --- Isn't __atomic_is_lock_free tied to the __GCC_ATOMIC_XXX_T_LOCK_FREE macros?
[Bug d/113758] New: d: Callee destructor call invalidates the live object, not the temporary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113758
Bug ID: 113758
Summary: d: Callee destructor call invalidates the live object,
not the temporary
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: ibuclaw at gdcproject dot org
Target Milestone: ---
D ABI does callee destruction of arguments, which depends on the argument
already being copied to a temporary before passing by ref.
At some point, the front-end stopped explicitly generating this temporary, so
now the code generator must take care of it.
---
struct Sdtor
{
int field;
~this() { field = 0; }
}
void main()
{
auto var = Sdtor(1);
callee(var);
assert(var.field == 1); // fails.
}
void callee(Sdtor param) { }
[Bug d/104739] gdc.test/runnable/mangle.d etc. FAIL with Solaris as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104739
--- Comment #6 from Iain Buclaw ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #5)
> > --- Comment #4 from Rainer Orth ---
> > I wonder how to handle this: while DejaGnu has an ucn effective-target
> > keyword,
> > the gdc.test testsuite doesn't use those at all.
>
> What I think could be done is
>
> * Add "//UTF-8 chars" comments to testmodule.d and ufcs.d; mangle.d
> already has one.
>
> * Make gdc-utils.exp (gdc-convert-test) check for those annotations,
> adding
>
> // { dg-require-effective-target ucn}
>
> if found.
>
> The new annotations would have to go upstream, I believe. WDYT?
Can give it a go.
https://github.com/dlang/dmd/pull/16136
[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 Iain Buclaw changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #11 from Iain Buclaw --- Mainline got this in r14-5678.
[Bug target/96347] note: non-delegitimized UNSPEC UNSPEC_TP (19) found in variable location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96347 Iain Buclaw changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #6 from Iain Buclaw --- (releases/gcc-9) $ ./gcc/xg++ -B ./gcc/ pr.cc -O2 -g -fchecking pr.cc: In function ‘int main()’: pr.cc:45:5: note: non-delegitimized UNSPEC UNSPEC_TP (19) found in variable location 45 | int main (void) | ^~~~ pr.cc:45:5: note: non-delegitimized UNSPEC UNSPEC_TP (19) found in variable location (releases/gcc-10) $ ./gcc/xg++ -B ./gcc/ pr.cc -O2 -g -fchecking pr.cc: In function ‘int main()’: pr.cc:45:5: note: non-delegitimized UNSPEC UNSPEC_TP (19) found in variable location 45 | int main (void) | ^~~~ pr.cc:45:5: note: non-delegitimized UNSPEC UNSPEC_TP (19) found in variable location pr.cc:45:5: note: non-delegitimized UNSPEC UNSPEC_TP (19) found in variable location (releases/gcc-11) $ ./gcc/xg++ -B ./gcc/ pr.cc -O2 -g -fchecking (releases/gcc-12) $ ./gcc/xg++ -B ./gcc/ pr.cc -O2 -g -fchecking (releases/gcc-13) $ ./gcc/xg++ -B ./gcc/ pr.cc -O2 -g -fchecking (trunk) $ ./gcc/xg++ -B ./gcc/ pr.cc -O2 -g -fchecking Minimal test is only reproducible on the 9.x and 10.x compilers, and I've not seen it crop up again in any D testsuite runs. I'll just close this then.
[Bug analyzer/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 --- Comment #9 from Iain Buclaw --- (In reply to Iain Buclaw from comment #8) > I see in the olden days when D sat outside of GCC, this is what was done too. > > https://github.com/D-Programming-GDC/gdc/commit/ > b9d36fc9d71ec4122d1c986599d87c6cb91ca55c Although thinking it over, that did not take into consideration wide character literals. The number of 0's at the end of the raw string in STRING_CST nodes would need to be the same as the width of the type it's representing - one, two, or four 0's for char, wchar and dchar respectively.
[Bug analyzer/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 --- Comment #8 from Iain Buclaw --- Looking at C++ FE, I see they construct the string literal using build_string (4, "foo") because I can see the terminating 0 in the pretty-printed string. --- unit-size align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7743b5e8 precision:8 min max pointer_to_this > type_6 BLK size unit-size align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7717d0a8 domain type_6 DI size unit-size align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7717de70 precision:64 min max > pointer_to_this > readonly constant static "hello world\000"> --- I see in the olden days when D sat outside of GCC, this is what was done too. https://github.com/D-Programming-GDC/gdc/commit/b9d36fc9d71ec4122d1c986599d87c6cb91ca55c This might have been accidentally removed by another contributor in an apparent drive-by search and replace of a specific pattern. https://github.com/D-Programming-GDC/gdc/commit/f8a05f41cb756ef7ed2b1d8b1d33eb8f815421a5
[Bug analyzer/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
--- Comment #7 from Iain Buclaw ---
(In reply to David Malcolm from comment #5)
> Is D correctly building that string_cst? Are D strings 0-terminated?
Yes, D strings are 0-terminated.
The way I've done it is, the string is constructed using
build_string(3, "foo")
but the TREE_TYPE is set to `char[4]` so that the terminating 0 is considered.
I'm sure it's like this because either GCC has a tendency to emit strings
side-by-side without the 0 so strlen("foo") could return 20, or there's an
optimization pass for strlen() that would otherwise evaluate strlen("foo") into
2 if I set the type of the literal as `char[3]`.
[Bug analyzer/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
--- Comment #2 from Iain Buclaw ---
(In reply to David Malcolm from comment #1)
> Am trying to reproduce locally, but when I run this in my BUILDDIR/gcc:
> ./gdc -B. -S -fanalyzer oob.d
> I get:
> d21: error: cannot find source code for runtime library file 'object.d'
>
> Possibly a silly question, but what am I doing wrong?
The library sources aren't in any paths that the compiler looks for. It should
work without any explicit `-I` if the target libraries were installed.
This alternative reproducer should get you off the ground though.
---
mkdir gcc;
echo "module gcc.builtins;" > gcc/builtins.d
cat > oob.d << EOF
module object;
import gcc.builtins;
void main()
{
char[5] arr;
__builtin_strcpy(arr.ptr, "hello world");
}
EOF
./gdc -B. -S -fanalyzer oob.d
[Bug d/111650] ICE in build_deref, at d/d-codegen.cc:1650
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111650
--- Comment #1 from Iain Buclaw ---
Reduced a bit more.
---
module object;
ref V require(K, V)(ref V[K] aa, K key, lazy V value);
struct Root
{
ulong[3] f;
}
Root[ulong] roots;
Root getRoot(int fd, ulong rootID)
{
return roots.require(rootID,
{
Root result;
inoLookup(fd, () => result);
return result;
}());
}
void inoLookup(int, scope Root delegate()) { }
[Bug analyzer/111537] New: 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
Bug ID: 111537
Summary: ICE: in set_cell_span, at text-art/table.cc:148 with D
front-end and -fanalyzer
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: ibuclaw at gdcproject dot org
Target Milestone: ---
Roughly copied an example from the static analyzer talk and wrote it in D.
---
import core.stdc.string;
void main()
{
char[5] arr;
strcpy(arr.ptr, "hello world");
}
---
The C++ equivalent compiled with g++ prints pretty tables and emojis in the
expected warning, whereas with gdc compiler issues an ICE within the text-art
code.
---
oob.d: In function ‘D main’:
oob.d:5:11: warning: buffer over-read [CWE-126] [-Wanalyzer-out-of-bounds]
5 | strcpy(arr.ptr, "hello world");
| ^
‘D main’: events 1-3
|
|4 | char[5] arr;
| | ^
| | |
| | (1) following ‘false’ branch...
| | (2) ...to here
|5 | strcpy(arr.ptr, "hello world");
| | ~
| | |
| | (3) out-of-bounds read at byte 11 but ‘"hello world"’
ends at byte 11
|
oob.d:5:11: note: read of 1 byte from after the end of ‘"hello world"’
5 | strcpy(arr.ptr, "hello world");
| ^
oob.d:5:11: note: valid subscripts for ‘"hello world"’ are ‘[0]’ to ‘[11]’
during IPA pass: analyzer
oob.d:4:13: internal compiler error: in set_cell_span, at text-art/table.cc:148
4 | char[5] arr;
| ^
0xa837bf text_art::table::set_cell_span(text_art::rect,
text_art::table_cell_content&&, text_art::x_align, text_art::y_align)
../../gcc/text-art/table.cc:148
0x2404913
ana::access_diagram_impl::add_invalid_accesses_to_region_table(text_art::table&)
../../gcc/analyzer/access-diagram.cc:2025
0x240b826 ana::access_diagram_impl::access_diagram_impl(ana::access_operation
const&, diagnostic_event_id_t, text_art::style_manager&, text_art::theme
const&, ana::logger*)
../../gcc/analyzer/access-diagram.cc:1874
0x23ffccb std::enable_if::value,
std::unique_ptr > >::type
make_unique(ana::access_operation const&, diagnostic_event_id_t&,
text_art::style_manager&, text_art::theme const&, ana::logger*&)
../../gcc/make-unique.h:41
0x23ffccb ana::access_diagram::access_diagram(ana::access_operation const&,
diagnostic_event_id_t, text_art::style_manager&, text_art::theme const&,
ana::logger*)
../../gcc/analyzer/access-diagram.cc:2416
0x21db92a ana::out_of_bounds::make_access_diagram(ana::access_operation const&,
text_art::style_manager&, text_art::theme const&, ana::logger*) const
../../gcc/analyzer/bounds-checking.cc:190
0x21db92a ana::out_of_bounds::maybe_show_diagram(ana::logger*) const
../../gcc/analyzer/bounds-checking.cc:169
0x21dbf7f ana::out_of_bounds::maybe_show_notes(unsigned int, ana::logger*)
const
../../gcc/analyzer/bounds-checking.cc:125
0x21dbf7f ana::concrete_buffer_over_read::emit(rich_location*, ana::logger*)
../../gcc/analyzer/bounds-checking.cc:437
0x220168c ana::diagnostic_manager::emit_saved_diagnostic(ana::exploded_graph
const&, ana::saved_diagnostic&)
../../gcc/analyzer/diagnostic-manager.cc:1566
0x220544d ana::dedupe_winners::emit_best(ana::diagnostic_manager*,
ana::exploded_graph const&)
../../gcc/analyzer/diagnostic-manager.cc:1446
0x2201c2e ana::diagnostic_manager::emit_saved_diagnostics(ana::exploded_graph
const&)
../../gcc/analyzer/diagnostic-manager.cc:1498
0x16771e5 ana::impl_run_checkers(ana::logger*)
../../gcc/analyzer/engine.cc:6168
0x16780ee ana::run_checkers()
../../gcc/analyzer/engine.cc:6242
0x166738c execute
../../gcc/analyzer/analyzer-pass.cc:87
[Bug analyzer/111536] New: -fanalyzer false positive with NRVO return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111536
Bug ID: 111536
Summary: -fanalyzer false positive with NRVO return
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: ibuclaw at gdcproject dot org
Target Milestone: ---
This code (translated from D to C++):
---
struct Guard {
int i;
~Guard() {}
};
Guard lock() {
return Guard();
}
void bar() {
auto foo = lock();
}
---
Produces this warning with -fanalyzer.
---
nrvo.cc: In function ‘Guard lock()’:
nrvo.cc:6:18: warning: use of uninitialized value ‘’ [CWE-457]
[-Wanalyzer-use-of-uninitialized-value]
6 | return Guard();
| ^
‘Guard lock()’: events 1-3
|
|5 | Guard lock() {
| | ^
| | |
| | (1) region created on stack here
| | (2) capacity: 8 bytes
|6 | return Guard();
| | ~
| | |
| | (3) use of uninitialized value ‘’ here
|
nrvo.cc:6:18: warning: use of uninitialized value ‘’ [CWE-457]
[-Wanalyzer-use-of-uninitialized-value]
6 | return Guard();
| ^
‘void bar()’: events 1-2
|
|8 | void bar() {
| | ^~~
| | |
| | (1) entry to ‘bar’
|9 | auto foo = lock();
| | ~
| | |
| | (2) calling ‘lock’ from ‘bar’
|
+--> ‘Guard lock()’: events 3-6
|
|5 | Guard lock() {
| | ~ ^~~~
| | | |
| | | (3) entry to ‘lock’
| | (4) region created on stack here
| | (5) capacity: 8 bytes
|6 | return Guard();
| | ~
| | |
| | (6) use of uninitialized value ‘’
here
|
---
This is the GIMPLE representation.
---
struct Guard lock ()
{
->a = 0;
return ;
}
void bar ()
{
struct Guard foo;
try
{
foo = lock (); [return slot optimization]
try
{
}
finally
{
Guard::~Guard (&foo);
}
}
finally
{
foo = {CLOBBER(eol)};
}
}
---
[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 --- Comment #3 from Iain Buclaw --- (In reply to Iain Buclaw from comment #2) > I think some extra errors during the D front-end codegen pass are likely the > most appropriate thing to do here, as you say, such things are rejected by > C/C++, so GDC ought to reject them too. This might be reviewed in future, so maybe D does define va_list as a pointer type on targets where it's a static array. But IIRC, this requires some care to ensure that it doesn't start generating code inconsistently with what the middle-end/back-end expect.
[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
--- Comment #2 from Iain Buclaw ---
(In reply to Richard Biener from comment #1)
> this_2(D)->ap = VIEW_CONVERT_EXPR(ap_3(D));
>
> it looks odd since ap_3(D) is a is_gimple_reg but a struct[1] definitely
> would not. Maybe you are missing a dereference here? In C
> struct[1] would decay to a pointer so
>
> this.ap = ap;
>
> wouldn't work (besides that va_list copying requires va_copy).
Static arrays in D are passed around by value, rather than decaying to a
pointer. However va_list is an inconsistent type on this front.
In some D compilers, it's always a pointer type to get around the
incompatibility with C/C++ - though this requires locals and fields to be
specially initialized before being passed to va_start() or va_copy().
i.e, underneath the hood it does:
---
void va_start(T)(out va_list ap, ref T parmn,
va_list storage = alloca(__va_list_tag.sizeof))
{
ap = storage;
// initialize *ap
}
void va_copy(out va_list ap, va_list src,
va_list storage = alloca(__va_list_tag.sizeof))
{
ap = storage;
// copy *src.
}
---
GDC doesn't do this, rather - in a way that mimics C/C++ - va_list static
arrays are decayed to a pointer type when used as a parameter, but semantically
it's still treated as a static array.
I think some extra errors during the D front-end codegen pass are likely the
most appropriate thing to do here, as you say, such things are rejected by
C/C++, so GDC ought to reject them too.
[Bug d/110712] New: 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
Bug ID: 110712
Summary: d: ICE: verify_gimple_failed (conversion of register
to a different size in 'view_convert_expr')
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: ibuclaw at gdcproject dot org
Target Milestone: ---
Seen with gdc-12 with --enable-checking turned on, assume that it's going to
still be the case with mainline.
d21: error: conversion of register to a different size in ‘view_convert_expr’
VIEW_CONVERT_EXPR(ap_3(D));
# .MEM_4 = VDEF <.MEM_1(D)>
this_2(D)->ap = VIEW_CONVERT_EXPR(ap_3(D));
during GIMPLE pass: ssa
d21: internal compiler error: verify_gimple failed
0x11aad62 verify_gimple_in_cfg(function*, bool)
../../gcc/tree-cfg.cc:5561
0x1073dae execute_function_todo
../../gcc/passes.cc:2085
0x107431a execute_todo
../../gcc/passes.cc:2139
---
import gcc.builtins : va_list = __builtin_va_list;
struct S
{
this(va_list ap)
{
this.ap = ap;
}
va_list ap;
}
---
Assigning a va_list parameter (static array saturated to a pointer on x86_64)
to a field (static array on x86_64) fails miserably to pass tree checks.
[Bug d/108055] d: Undefined reference to nested lambda in template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108055 Iain Buclaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Iain Buclaw --- Fix committed and backported.
[Bug d/108050] d: internal compiler error: in visit, at d/imports.cc:72
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108050 Iain Buclaw changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #6 from Iain Buclaw --- Fix committed and backported.
[Bug d/108055] New: d: Undefined reference to nested lambda in template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108055
Bug ID: 108055
Summary: d: Undefined reference to nested lambda in template
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: ibuclaw at gdcproject dot org
Target Milestone: ---
issue.d:
---
import std.conv;
void main()
{
float* zis ;
static if (is(typeof(to!string(*zis
to!string(*zis);
}
---
std/conv.d:
---
T toStr(T, S)(S src)
{
static if (is(typeof(T.init[0]) E))
{
struct Appender
{
inout(E)[] data;
}
import std.format.spec;
import std.format.write;
auto w = Appender();
FormatSpec!E f;
formatValue(w, src, f);
return w.data;
}
}
T to(T, A)(A args)
{
return toStr!T(args);
}
---
std/format/spec.d:
---
module std.format.spec;
template Unqual(T : const U, U)
{
alias Unqual = U;
}
template FormatSpec(Char)
if (!is(Unqual!Char == Char))
{
alias FormatSpec = FormatSpec!(Unqual!Char);
}
struct FormatSpec(Char)
if (is(Unqual!Char == Char))
{
const(Char)[] nested;
}
---
std/format/write.d:
---
module std.format.write;
import std.format.spec;
void formatValueImpl(Writer, T, Char)(ref Writer , const(T) ,
scope const ref FormatSpec!Char )
{
T val;
char spec;
(ref val) @trusted {
return (cast(const char*) &val)[0 .. val.sizeof];
}(val);
}
void formatValue(Writer, T, Char)(Writer w, T val, Char f)
{
formatValueImpl(w, val, f);
}
---
[Bug d/108050] d: internal compiler error: in visit, at d/imports.cc:72
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108050 --- Comment #1 from Iain Buclaw --- Doesn't even need to be a template that's imported. Two or more overloadable functions will trigger the ICE as well.
[Bug d/108050] New: d: internal compiler error: in visit, at d/imports.cc:72
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108050
Bug ID: 108050
Summary: d: internal compiler error: in visit, at
d/imports.cc:72
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: ibuclaw at gdcproject dot org
Target Milestone: ---
ice.d:
---
import std : split;
---
std/package.d
---
module std;
public import std.array;
public import std.regex;
---
std/array.d
---
module std.array;
S[] split()() { }
---
std/regex.d
---
module std.regex;
S[] split()() { }
---
[Bug web/107749] onlinedocs: gdc docs got removed during sphinx revert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107749 Iain Buclaw changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Iain Buclaw --- They've been re-added.
[Bug d/105659] error: #error You must define PREFERRED_DEBUGGING_TYPE if DWARF is not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105659 Iain Buclaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Iain Buclaw --- Fix now backported to gcc-12.
[Bug d/107592] ICE: gdc segfault on label continue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107592 Iain Buclaw changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #6 from Iain Buclaw --- Fix committed and backported to release branches.
[Bug web/107749] New: onlinedocs: gdc docs got removed during sphinx revert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107749 Bug ID: 107749 Summary: onlinedocs: gdc docs got removed during sphinx revert Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: ibuclaw at gdcproject dot org Target Milestone: --- This got added during the conversion to Sphinx. https://gcc.gnu.org/onlinedocs/gdc/ Now that experiment has been reverted, the link to from the main page to gdc docs has been removed https://gcc.gnu.org/onlinedocs/#current along with whatever scripts were being used to build it, as the /gdc/ page is still present, but in the Sphinx-style docs format.
[Bug target/107671] i386: Missed optimization: use of bt in bit test pattern (using -O2 -mtune=core2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107671
--- Comment #5 from Iain Buclaw ---
(In reply to Uroš Bizjak from comment #4)
> from:
> movl%esi, %ecx
> movl$1, %eax
> sall%cl, %eax
> testl %edi, %eax
> setne %al
> movzbl %al, %eax
>
> to:
> xorl%eax, %eax
> btl %esi, %edi
> setc%al
>
> The patch adapts *jcc_bt patterns to similar *scc_bt patterns.
Thanks, have been tinkering with the pointer index version, and found that I
can coax scc_bt_mask to match if I cast the lhs to a signed type. It's not
obvious to me why there would be a difference.
return ((__INT32_TYPE__)p[bitnum >> 5] & (1 << (bitnum & 31))) != 0;
movl%esi, %eax
shrl$5, %eax
movl(%rdi,%rax,4), %eax
btl %esi, %eax
setc%al
Things get even stranger once I expand to "bit test and op" variants though
(better to put in another PR though)
__INT32_TYPE__ btc32(__UINT32_TYPE__ *p, __UINT32_TYPE__ bitnum)
{
__INT32_TYPE__ result = ((__INT32_TYPE__)p[bitnum >> 5]
& (1 << (bitnum & 31))) != 0;
p[bitnum >> 5] ^= 1 << (bitnum & 31);
return result;
}
Patch changes code-gen in the following way.
from:
movl%esi, %eax
movl%esi, %ecx
shrl$5, %eax
leaq(%rdi,%rax,4), %rdx
movl(%rdx), %eax
movl%eax, %esi
sarl%cl, %eax
btcl%ecx, %esi
andl$1, %eax
movl%esi, (%rdx)
to:
movl%esi, %eax
shrl$5, %eax
leaq(%rdi,%rax,4), %rdx
movl(%rdx), %eax
movl%eax, %ecx
btcl%esi, %ecx
btl %esi, %eax
setc%al
movl%ecx, (%rdx)
movzbl %al, %eax
[Bug target/107671] i386: Missed optimization: use of bt in bit test pattern (using -O2 -mtune=core2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107671 --- Comment #2 from Iain Buclaw --- Expected generated code would be: --- bt32_setb*: ... shrl$5, %edx movl(%eax,%edx,4), %edx xorl%eax, %eax btl %ecx, %edx setb%al ... --- bt32_setae*: ... shrl$5, %edx movl(%eax,%edx,4), %edx xorl%eax, %eax btl %ecx, %edx setae %al ... --- bt32v_setb*: ... xorl%eax, %eax btl %esi, %edi setb%al ... --- bt32v_setae*: ... xorl%eax, %eax btl %esi, %edi setae %al ... --- bt64_setb*: ... shrq$6, %rax movq(%rdi,%rax,8), %rcx xorl%eax, %eax btq %rsi, %rcx setb%al ... --- bt64_setae*: ... shrq$6, %rax movq(%rdi,%rax,8), %rcx xorl%eax, %eax btq %rsi, %rcx setae %al ... --- bt64v_setb*: ... xorl%eax, %eax btq %rsi, %rdi setb%al ... --- bt64v_setae*: ... xorl%eax, %eax btq %rsi, %rdi setae %al ...
[Bug target/107671] i386: Missed optimization: use of bt in bit test pattern (using -O2 -mtune=core2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107671
--- Comment #1 from Iain Buclaw ---
Non-pointer variants also not detected.
---
int bt32v_setb(const __UINT32_TYPE__ v, __UINT32_TYPE__ bitnum)
{
return ((v & (1 << (bitnum & 31 != 0;
}
int bt64v_setb(const __UINT64_TYPE__ v, __UINT64_TYPE__ bitnum)
{
return ((v & (1L << (bitnum & 63 != 0;
}
int bt32v_setb2(const __UINT32_TYPE__ v, __UINT32_TYPE__ bitnum)
{
return (v >> (bitnum & 31)) & 1;
}
int bt64v_setb2(const __UINT64_TYPE__ v, __UINT64_TYPE__ bitnum)
{
return (v >> (bitnum & 63)) & 1;
}
int bt32v_setae(const __UINT32_TYPE__ v, __UINT32_TYPE__ bitnum)
{
return ((v & (1 << (bitnum & 31 == 0;
}
int bt64v_setae(const __UINT64_TYPE__ v, __UINT64_TYPE__ bitnum)
{
return ((v & (1L << (bitnum & 63 == 0;
}
int bt32v_setae2(const __UINT32_TYPE__ v, __UINT32_TYPE__ bitnum)
{
return !((v >> (bitnum & 31)) & 1);
}
int bt64v_setae2(const __UINT64_TYPE__ v, __UINT64_TYPE__ bitnum)
{
return !((v >> (bitnum & 63)) & 1);
}
[Bug target/107671] New: i386: Missed optimization: use of bt in bit test pattern when LHS is an array index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107671
Bug ID: 107671
Summary: i386: Missed optimization: use of bt in bit test
pattern when LHS is an array index
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: ibuclaw at gdcproject dot org
Target Milestone: ---
int bt32_setb(const __UINT32_TYPE__ *p, __UINT32_TYPE__ bitnum)
{
return ((p[bitnum >> 5] & (1 << (bitnum & 31 != 0;
}
int bt64_setb(const __UINT64_TYPE__ *p, __UINT64_TYPE__ bitnum)
{
return ((p[bitnum >> 6] & (1L << (bitnum & 63 != 0;
}
int bt32_setb2(const __UINT32_TYPE__ *p, __UINT32_TYPE__ bitnum)
{
return (p[bitnum >> 5] >> (bitnum & 31)) & 1;
}
int bt64_setb2(const __UINT64_TYPE__ *p, __UINT64_TYPE__ bitnum)
{
return (p[bitnum >> 6] >> (bitnum & 63)) & 1;
}
int bt32_setae(const __UINT32_TYPE__ *p, __UINT32_TYPE__ bitnum)
{
return ((p[bitnum >> 5] & (1 << (bitnum & 31 == 0;
}
int bt64_setae(const __UINT64_TYPE__ *p, __UINT64_TYPE__ bitnum)
{
return ((p[bitnum >> 6] & (1L << (bitnum & 63 == 0;
}
int bt32_setae2(const __UINT32_TYPE__ *p, __UINT32_TYPE__ bitnum)
{
return !((p[bitnum >> 5] >> (bitnum & 31)) & 1);
}
int bt64_setae2(const __UINT64_TYPE__ *p, __UINT64_TYPE__ bitnum)
{
return !((p[bitnum >> 6] >> (bitnum & 63)) & 1);
}
[Bug d/107592] ICE: gdc segfault on label continue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107592
--- Comment #1 from Iain Buclaw ---
Generated function:
---
void foo (struct _param_0)
{
void label = <<< error >>>;
label:;
while (1)
{
{
struct thing;
thing = _param_0;
goto ;
}
goto ;
}
:;
}
[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977 --- Comment #3 from Iain Buclaw --- (In reply to r...@cebitec.uni-bielefeld.de from comment #2) > My builds are on Mac OS X 10.7/Darwin 11 still. What macOS version are > you trying this on? FWIW, I gave up on 32-bit builds with macOS > 10.14/Darwin 18 when Apple made it close to impossible to build 32-bit > software. I've got stage1 link failures on 10.10/Darwin 14, using gcc-11.3 built with CC='gcc -m32' CXX='g++ -m32' as the bootstrap compiler. I'll have to check where the failures are, as I don't recall from memory. I've also got a box with a clean 10.8/Darwin 12 install on it, hence the question.
[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977 --- Comment #1 from Iain Buclaw --- Is there a (sort of simple) bootstrap process one can follow for 32-bit OSX? I have the means to test locally, but I can't get much further than building gdc-11 -m32 - using said compiler to bootstrap mainline fails for non-D related reasons when building stage1.
[Bug d/107552] [13 regression] stage 1 d21 fails to link on Linux/x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107552 --- Comment #1 from Iain Buclaw --- Isn't this a duplicate of pr104749, which got fixed in 9.4.0?
[Bug target/107265] New: error: TARGET_VXWORKS7 was not declared in this scope; did you mean TARGET_VXWORKS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107265 Bug ID: 107265 Summary: error: TARGET_VXWORKS7 was not declared in this scope; did you mean TARGET_VXWORKS Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: ibuclaw at gdcproject dot org Target Milestone: --- Seen when configuring with --target=aarch64-wrs-vxworks Looking at config.gcc, aarch64*-*-* is not included in the condition to add the vxworks-dummy.h header.
[Bug d/107241] std.bitmanip.bigEndianToNative et al not inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107241 Iain Buclaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Iain Buclaw --- Looks like pr102765 to me. *** This bug has been marked as a duplicate of bug 102765 ***
[Bug d/102765] [11 Regression] GDC11 stopped inlining library functions and lambdas used by a binary search one-liner code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102765 Iain Buclaw changed: What|Removed |Added CC||witold.baryluk+gcc at gmail dot co ||m --- Comment #7 from Iain Buclaw --- *** Bug 107241 has been marked as a duplicate of this bug. ***
[Bug d/107101] d: Add stub for object module when libphobos is not compiled, or supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107101 --- Comment #1 from Iain Buclaw --- This also affects when compiling with `-nostdinc`.
[Bug d/107101] New: d: Add stub for object module when libphobos is not compiled, or supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107101 Bug ID: 107101 Summary: d: Add stub for object module when libphobos is not compiled, or supported Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: ibuclaw at gdcproject dot org Target Milestone: --- Currently behaviour is that object.d is searched for anyway, resulting in an error that it cannot be found. --- /opt/compiler-explorer/sh/gcc-12.2.0/sh-multilib-linux-gnu/bin/sh-multilib-linux-gnu-gdc -c /tmp/test.d d21: error: cannot find source code for runtime library file 'object.d' d21: note: dmd might not be correctly installed. Run 'dmd -man' for installation instructions. d21: note: config file: not found --- Just declaring a stub module means that although the language at compile-time would be crippled, at least you'll be able to build *something*.
[Bug d/106832] Missing powerpc64le-linux support for D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106832 --- Comment #25 from Iain Buclaw --- (In reply to Iain Buclaw from comment #24) > I'd imagine all static asserts would be hit, so a lot more than that - > floor, tan, sin, cos, pow, etc... - some of which are not exactly trivial to > implement for the IBM format (I've looked at it on a couple occasions over > the last decade). Some could be helped along by just returning the result of libm functions instead of implementing them inline, but then the C function declarations would need the same attributes as std.math - notably many libm bindings in the core.stdc.math module are not annotated with `pure`.
[Bug d/106832] Missing powerpc64le-linux support for D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106832 --- Comment #24 from Iain Buclaw --- (In reply to Peter Bergner from comment #22) > (In reply to Peter Bergner from comment #21) > > For the record, this is what I'm testing with: > > So we get farther, but ICE again at: > /home/bergner/gcc/gcc-fsf-mainline-lang-D/libphobos/src/std/math/exponential. > d:1104:9: error: static assert: "Not implemented for this architecture" > 1104 | static assert(0, "Not implemented for this architecture"); > | ^ > /home/bergner/gcc/gcc-fsf-mainline-lang-D/libphobos/src/std/math/exponential. > d:981:19: note: instantiated from here: ‘expImpl!real’ > 981 | return expImpl(x); > | ^ > > Looking at expImpl(), it has implementations for all of the float types > except for IBM128. Maybe just need to add support for that??? I'd imagine all static asserts would be hit, so a lot more than that - floor, tan, sin, cos, pow, etc... - some of which are not exactly trivial to implement for the IBM format (I've looked at it on a couple occasions over the last decade). std/math/algebraic.d:696:static assert(0); std/math/exponential.d:1104:static assert(0, "Not implemented for this architecture"); std/math/exponential.d:1241:static assert(0, "No exp() tests for real type!"); std/math/exponential.d:1514:static assert(0); std/math/exponential.d:1590:static assert(0, "no coefficients for expm1()"); std/math/exponential.d:1906:static assert(0); std/math/exponential.d:1976:static assert(0, "no coefficients for exp2()"); std/math/exponential.d:2804:else static assert(false, "Floating point type real not supported"); std/math/hardware.d:764:static assert(false, "Not implemented for this architecture"); std/math/hardware.d:879:static assert(false, "Not implemented for this architecture"); std/math/hardware.d:896:static assert(false, "Not implemented for this architecture"); std/math/operations.d:925:static assert(false, "Not implemented for this architecture"); std/math/operations.d:1792:static assert(false, "Floating point type `" ~ F.realFormat ~ "` not supported."); std/math/package.d:418:static assert(false, "No traits support for " ~ T.stringof); std/math/package.d:482:static assert(false, "No traits support for " ~ T.stringof); std/math/rounding.d:698:static assert(false, "real type not supported by lrint()"); std/math/rounding.d:953:static assert(false, "Not implemented for this architecture"); std/math/traits.d:305:static assert(false, "Not implemented for this architecture"); std/math/trigonometry.d:305:static assert(0); std/math/trigonometry.d:381:static assert(0, "no coefficients for tan()"); std/math/trigonometry.d:758:static assert(0, "no coefficients for atan()");
[Bug d/106832] Missing powerpc64le-linux support for D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106832 --- Comment #12 from Iain Buclaw --- (In reply to Jakub Jelinek from comment #11) > Doesn't powerpc*-*-freebsd* use IEEE double long double? > grep LONG_DOUBLE_SIZE * > darwin.h:#define RS6000_DEFAULT_LONG_DOUBLE_SIZE 128 > linux64.h:#define RS6000_DEFAULT_LONG_DOUBLE_SIZE 128 > linux.h:#define RS6000_DEFAULT_LONG_DOUBLE_SIZE 128 > rs6000.cc:#ifndef RS6000_DEFAULT_LONG_DOUBLE_SIZE > rs6000.cc:#define RS6000_DEFAULT_LONG_DOUBLE_SIZE 64 Could be that instead, yeah. > And, sure, it would be ok to support only IEEE quad as D real for > powerpc*-linux*, but then D can be only supported with -mvsx. Furthermore, > dunno if D has its own math library or uses libm or both, if it doesn't have > everything on its own, then it would need at least glibc 2.27 or later (the > one with *f128 support) or perhaps 2.32 or which has __*ieee128 support. Its sort of both. The core D runtime has libm C bindings (core/stdc/math.d), whereas the standard runtime implements its own (pure) math library (std/math/*.d).
[Bug d/106832] Missing powerpc64le-linux support for D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106832 --- Comment #10 from Iain Buclaw --- (In reply to Peter Bergner from comment #9) > (In reply to Jakub Jelinek from comment #2) > > Well, I certainly see libphobos/configure.tgt having powerpc*-linux* as the > > only target that does: > > power*-*-linux*) > > LIBPHOBOS_SUPPORTED=yes > > LIBDRUNTIME_ONLY=yes > > ;; > > It's interesting that the power*-*-freebsd*) target stanza doesn't have > "LIBDRUNTIME_ONLY=yes". Someone else tested that port. From what I recall, I did a spot check and saw that IBM128 is only supported on AIX, Darwin, and Linux-with-long-double-format=ibm. For all other Power ports, it's IEEE128 by default.
[Bug middle-end/106819] New: [13 Regression] NaN != NaN comparisons return false at -O2 since r13-2338
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106819
Bug ID: 106819
Summary: [13 Regression] NaN != NaN comparisons return false at
-O2 since r13-2338
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: ibuclaw at gdcproject dot org
Target Milestone: ---
Isolated, and translated to C from the D testsuite, likely can be reduced
further, as I don't think opCmpProper() affects the outcome.
---
static int isNaN(double x)
{
return x != x;
}
static double opCmpProper(int lhs, double rhs)
{
return lhs < rhs ? -1.0
: lhs > rhs ? 1.0
: lhs == rhs ? 0.0
: __builtin_nan("");
}
int main()
{
if (!isNaN(opCmpProper(41, __builtin_nan(""
__builtin_abort();
return 0;
}
[Bug d/106638] docs: bad links to DIPs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106638 Iain Buclaw changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #7 from Iain Buclaw --- Went through all open release branches and updated all wiki links to point at the github repository.
[Bug d/106638] docs: bad links to DIPs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106638 --- Comment #2 from Iain Buclaw --- (In reply to Martin Liška from comment #1) > Should likely lead to something like: > https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1021.md Indeed, I'm sure the wiki links were working at one point in time, but the github repository is the official place where they are kept now.
[Bug d/106623] internal compiler error: Segmentation fault at gimple-expr.cc:88
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106623 Iain Buclaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Iain Buclaw --- Fix committed.
[Bug d/106623] New: internal compiler error: Segmentation fault at gimple-expr.cc:88
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106623
Bug ID: 106623
Summary: internal compiler error: Segmentation fault at
gimple-expr.cc:88
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: ibuclaw at gdcproject dot org
Target Milestone: ---
When compiling with -O1 and above.
---
private struct _Complex(T) { T re; T im; }
enum __c_complex_double : _Complex!double;
pragma(inline, true)
size_t hashOf()(scope const double val)
{
return *cast(size_t*)&val;
}
pragma(inline, true)
size_t hashOf()(scope const _Complex!double val, size_t seed = 0)
{
return hashOf(val.re) + hashOf(val.im);
}
pragma(inline, true)
size_t hashOf()(__c_complex_double val, size_t seed = 0)
{
return hashOf(cast(_Complex!double) val, seed);
}
int main()
{
__c_complex_double val;
return cast(int)hashOf(val);
}
---
The conflating between native complex and struct representation in the code
generation bites us in the optimization pass.
[Bug d/102765] [11 Regression] GDC11 stopped inlining library functions and lambdas used by a binary search one-liner code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102765 --- Comment #6 from Iain Buclaw --- r13-2002 (and r12-8673) is a start that sows the seeds to make the codegen option -fno-weak-templates the default. Should just be a case of extending the forced emission to all instantiations too.
[Bug d/104317] D language: rt.config module doesn't work as expected in GDC 9/10 (multiple definition linker error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104317 --- Comment #3 from Iain Buclaw --- (In reply to Siarhei Siamashka from comment #2) > I first tried to toggle "flag_weak_templates" in "gcc/d/lang.opt" from 1 to > 0 in GDC11 instead of reverting PR99914, but the resulting toolchain was > unable to compile and link even the most simple applications due to missing > symbols from Phobos. > r13-2002 (and r12-8673) is a start that sows the seeds to make the codegen option -fno-weak-templates the default. Should just be a case of extending the forced emission to all instantiations too.
[Bug d/105360] Inlined lazy parameters / delegate literals, still emitted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105360 Iain Buclaw changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=80680, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=99373 --- Comment #3 from Iain Buclaw --- Possibly a duplicate of pr80680 or pr99373.
[Bug d/105360] Inlined lazy parameters / delegate literals, still emitted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105360 --- Comment #2 from Iain Buclaw --- Looks like it's a middle-end missed-optimization, not a D front-end one. https://godbolt.org/z/5WWYEG4jW Perhaps we need an extra DCE pass?
[Bug d/106563] [12/13 Regression] d: undefined reference to pragma(inline) symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106563 Iain Buclaw changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #4 from Iain Buclaw --- Fix committed.
[Bug d/106563] [12/13 Regression] d: undefined reference to pragma(inline) symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106563 Iain Buclaw changed: What|Removed |Added Known to fail||12.1.0 Known to work||11.1.0 --- Comment #1 from Iain Buclaw --- Well, not really a regression, but it rears its ugly head in gdc-12 because nextPow2() now gets instantiated in the `test' module, whereas previously it didn't.
[Bug d/106563] New: [12/13 Regression] d: undefined reference to pragma(inline) symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106563
Bug ID: 106563
Summary: [12/13 Regression] d: undefined reference to
pragma(inline) symbol
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: ibuclaw at gdcproject dot org
Target Milestone: ---
Compiled with `gdc test.d` results in:
/usr/bin/ld: /tmp/ccxf3O8c.o: in function
`stdx.math.nextPow2!(ulong).nextPow2(const(ulong))':
test.d:(.text+0x6d): undefined reference to
`stdx.math.powIntegralImpl!(const(ulong)).powIntegralImpl(const(ulong))'
collect2: error: ld returned 1 exit status
Because the function is pragma(inline), it should receive automatic codegen
during the front-end -> GCC tree lowering pass.
---
module stdx.math;
T nextPow2(T)(const T val)
{
return powIntegralImpl(val);
}
pragma(inline, true)
T powIntegralImpl(T)(T)
{
return 1;
}
---
module stdx.regex;
import stdx.uni;
struct CharMatcher
{
typeof(MultiArray!().length) trie;
}
---
module stdx.uni;
struct MultiArray()
{
@property length()
{
return spaceFor!0();
}
}
size_t spaceFor(size_t bits)()
{
import stdx.math;
return nextPow2(bits);
}
---
module test;
import stdx.math;
import stdx.regex;
void requireSize()(size_t size)
{
nextPow2(size);
}
void main()
{
requireSize(0);
}
[Bug d/106555] [12/13 Regression] d: internal compiler error: in add_stack_var, at cfgexpand.cc:476
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106555 Iain Buclaw changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from Iain Buclaw --- Fix committed.
[Bug d/106555] New: [12/13 Regression] d: internal compiler error: in add_stack_var, at cfgexpand.cc:476
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106555
Bug ID: 106555
Summary: [12/13 Regression] d: internal compiler error: in
add_stack_var, at cfgexpand.cc:476
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: ibuclaw at gdcproject dot org
Target Milestone: ---
When compiled with: gdc -O2 empty.d ice.d
empty.d:
---
---
ice.d:
---
struct EnemyPool
{
int[] enemy;
int maxEnemy;
this(int) {
enemy.length = maxEnemy;
}
}
---
Results in ICE:
---
during GIMPLE pass: local-fnsummary
In function ‘_d_HookTraceImpl’:
d21: internal compiler error: in add_stack_var, at cfgexpand.cc:476
0x7fa9f3 add_stack_var
../../gcc/cfgexpand.cc:476
0xc9e9cb expand_one_var
../../gcc/cfgexpand.cc:1824
0xc9eae0 estimated_stack_frame_size(cgraph_node*)
../../gcc/cfgexpand.cc:2103
0xf1b37f compute_fn_summary(cgraph_node*, bool)
../../gcc/ipa-fnsummary.cc:3108
0xf1b630 compute_fn_summary_for_current
../../gcc/ipa-fnsummary.cc:3237
0xf1b630 execute
../../gcc/ipa-fnsummary.cc:4855
---
Reduced from debian bug
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1016701
[Bug d/105942] [12/13 Regression] d: internal compiler error: in visit, at d/expr.cc:945
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105942 Iain Buclaw changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Iain Buclaw --- Downstreamed in r13-1949 and r12-8621.
[Bug d/101691] d: Use of LOOP_EXPR prevents removing no-op loops.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101691 Iain Buclaw changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from Iain Buclaw --- Confirmed it is finite loops that makes the difference, nothing to do here.
[Bug d/106139] d: aggregate value used where floating point was expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106139 Iain Buclaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Iain Buclaw --- Fix committed, and backported.
[Bug d/106139] d: aggregate value used where floating point was expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106139 --- Comment #1 from Iain Buclaw --- Note, gdc-11 and gdc-10 error as a result to a different issue. --- cannot resolve type for cast(__vector(int[8]))arr --- Fix was made in a newer version of upstream dmd, so that'll be handled in the backport. https://github.com/dlang/dmd/pull/10532
[Bug d/106139] New: d: aggregate value used where floating point was expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106139 Bug ID: 106139 Summary: d: aggregate value used where floating point was expected Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: ibuclaw at gdcproject dot org Target Milestone: --- Casting from vector to static array is permitted, and the frontend generates a reinterpret cast, but casting back the other way results in an error. --- __vector(int[4]) vec = [1,2,3,4]; int[4] arr; arr = cast(int[4])vec;// OK vec = cast(__vector(int[4]))arr; // Error
[Bug d/105413] gdc extended assembler cannot constraints r8 - r15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105413
Iain Buclaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED |RESOLVED
--- Comment #2 from Iain Buclaw ---
@register attribute has been added, meaning that you can now have the following
as an alternative to your example.
---
import gcc.attributes : register;
@register("rax") SYSCALL rax = ident; // rax - syscall number
@register("rdi") size_t rdi = arg1; // rdi - arg1
@register("rsi") size_t rsi = arg2; // rsi - arg2
@register("rdx") size_t rdx = arg3; // rdx - arg3
@register("r10") size_t r10 = arg4; // r10 - arg4
asm @nogc nothrow {
"syscall"
: "=r" (rax)
// inputs:
: "r" (rax),
"r" (rdi),
"r" (rsi),
"r" (rdx),
"r" (r10),
"m"( *cast(ubyte*)arg1) // "dummy" input instead of full memory clobber
// clobers
: "rcx", "r11"; // Clobers rax, and rcx and r11.
}
return rax;
---
https://godbolt.org/z/PvnTsea9T
[Bug d/105942] [12/13 Regression] d: internal compiler error: in visit, at d/expr.cc:945
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105942 Iain Buclaw changed: What|Removed |Added URL||https://github.com/dlang/dm ||d/pull/14210 --- Comment #1 from Iain Buclaw --- Fix landed in upstream.
[Bug d/105942] New: [12 Regression] d: internal compiler error: in visit, at d/expr.cc:945
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105942
Bug ID: 105942
Summary: [12 Regression] d: internal compiler error: in visit,
at d/expr.cc:945
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: ibuclaw at gdcproject dot org
Target Milestone: ---
---
void ice()
{
struct hasDtor
{
int i;
~this() { }
}
hasDtor[4] arr = hasDtor(4);
}
---
0x9baaa0 ExprVisitor::visit(AssignExp*)
../../src/gcc/d/expr.cc:945
0x9b6a23 build_expr(Expression*, bool, bool)
../../src/gcc/d/expr.cc:3040
0x9b65e8 DeclVisitor::visit(VarDeclaration*)
../../src/gcc/d/decl.cc:735
0x9b06ba DeclVisitor::build_dsymbol(Dsymbol*)
../../src/gcc/d/decl.cc:146
0x9b06ba build_decl_tree(Dsymbol*)
../../src/gcc/d/decl.cc:1010
0x9b6ddd ExprVisitor::visit(DeclarationExp*)
../../src/gcc/d/expr.cc:2008
0x9b6a23 build_expr(Expression*, bool, bool)
../../src/gcc/d/expr.cc:3040
0x9b6abf build_expr_dtor(Expression*)
../../src/gcc/d/expr.cc:3063
0x9c31e5 IRVisitor::visit(ExpStatement*)
../../src/gcc/d/toir.cc:1052
0x9c3157 IRVisitor::build_stmt(Statement*)
../../src/gcc/d/toir.cc:274
0x9c3157 IRVisitor::visit(CompoundStatement*)
../../src/gcc/d/toir.cc:1069
0x9c3157 IRVisitor::visit(CompoundStatement*)
../../src/gcc/d/toir.cc:1059
0x9c3157 IRVisitor::build_stmt(Statement*)
../../src/gcc/d/toir.cc:274
0x9c3157 IRVisitor::visit(CompoundStatement*)
../../src/gcc/d/toir.cc:1069
0x9c3157 IRVisitor::visit(CompoundStatement*)
../../src/gcc/d/toir.cc:1059
0x9c2842 IRVisitor::build_stmt(Statement*)
../../src/gcc/d/toir.cc:274
0x9c2842 build_function_body(FuncDeclaration*)
../../src/gcc/d/toir.cc:1481
0x9b5b72 DeclVisitor::visit(FuncDeclaration*)
../../src/gcc/d/decl.cc:969
0x9b06ba DeclVisitor::build_dsymbol(Dsymbol*)
../../src/gcc/d/decl.cc:146
0x9b06ba build_decl_tree(Dsymbol*)
../../src/gcc/d/decl.cc:1010
[Bug d/105544] gdc fails to compile d source from stdin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105544 Iain Buclaw changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #14 from Iain Buclaw --- Committed patch posted here to mainline and backported to gcc-12.
[Bug d/105659] error: #error You must define PREFERRED_DEBUGGING_TYPE if DWARF is not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105659 --- Comment #2 from Iain Buclaw --- (In reply to Iain Buclaw from comment #1) > If I recall the conversation correctly, either the CPU-specific D language > hooks should be moved to macros - equivalent to TARGET_CPU_CPP_BUILTINS and > others. Or the tm_d file should be packed with a lot more headers within - > possibly tricky as it would mean handling it in every possible path in > config.gcc. Or I do away with tm_d.h and just include tm.h and tm_p.h in all D-specific target files, so that the CPU version macros will always be picked up by default-d.cc and others. I note that there's also a similar hack done for darwin-d.cc, where tm-dwarf2.h is explicitly added to the tm_d.h file in order to get around this.
[Bug d/105659] error: #error You must define PREFERRED_DEBUGGING_TYPE if DWARF is not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105659 --- Comment #1 from Iain Buclaw --- If I recall the conversation correctly, either the CPU-specific D language hooks should be moved to macros - equivalent to TARGET_CPU_CPP_BUILTINS and others. Or the tm_d file should be packed with a lot more headers within - possibly tricky as it would mean handling it in every possible path in config.gcc.
[Bug d/105659] New: error: #error You must define PREFERRED_DEBUGGING_TYPE if DWARF is not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105659 Bug ID: 105659 Summary: error: #error You must define PREFERRED_DEBUGGING_TYPE if DWARF is not supported Product: gcc Version: 12.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: ibuclaw at gdcproject dot org Target Milestone: --- This was discussed in gcc-patches a while back, creating an issue for tracking/fixing it. --- g++ -fno-PIE -c -DIN_GCC_FRONTEND -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. -I/home/ibuclaw/src/gcc/crossbuilds/../gcc/gcc -I/home/ibuclaw/src/gcc/crossbuilds/../gcc/gcc/. -I/home/ibuclaw/src/gcc/crossbuilds/../gcc/gcc/../include -I/home/ibuclaw/src/gcc/crossbuilds/../gcc/gcc/../libcpp/include -I/home/ibuclaw/src/gcc/crossbuilds/../gcc/gcc/../libcody -I/home/ibuclaw/src/gcc/crossbuilds/../gcc/gcc/../libdecnumber -I/home/ibuclaw/src/gcc/crossbuilds/../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I/home/ibuclaw/src/gcc/crossbuilds/../gcc/gcc/../libbacktrace -o default-d.o -MT default-d.o -MMD -MP -MF ./.deps/default-d.TPo /home/ibuclaw/src/gcc/crossbuilds/../gcc/gcc/config/default-d.cc In file included from ./tm_d.h:9, from /home/ibuclaw/src/gcc/crossbuilds/../gcc/gcc/config/default-d.cc:22: /home/ibuclaw/src/gcc/crossbuilds/../gcc/gcc/defaults.h:908:2: error: #error You must define PREFERRED_DEBUGGING_TYPE if DWARF is not supported 908 | #error You must define PREFERRED_DEBUGGING_TYPE if DWARF is not supported | ^ make[1]: *** [Makefile:2329: default-d.o] Error 1 make[1]: *** Waiting for unfinished jobs make[1]: Leaving directory '/home/ibuclaw/src/gcc/crossbuilds/aarch64-rtems/gcc' make: *** [Makefile:4594: all-gcc] Error 2
[Bug d/104740] gdc.dg/simd_ctfe.d etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104740 Iain Buclaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Iain Buclaw --- I think all are covered now.
[Bug d/104878] untranslated string in diagnostic "%s %qs instantiated"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104878 Iain Buclaw changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #1 from Iain Buclaw --- This warning is detritus, as the dmd front-end now tracks and reports on instantiations internally, exposed by the `-ftransition=templates' option. Removed in r12-7972.
[Bug d/105004] d: internal compiler error: in build_complex, at tree.c:2358
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105004 Iain Buclaw changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from Iain Buclaw --- Fix committed.
[Bug d/104911] [12 regression] Comparison failure in gcc/d/typesem.o etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104911 Iain Buclaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #9 from Iain Buclaw --- This should be fine now.
[Bug d/105004] New: d: internal compiler error: in build_complex, at tree.c:2358
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105004
Bug ID: 105004
Summary: d: internal compiler error: in build_complex, at
tree.c:2358
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: ibuclaw at gdcproject dot org
Target Milestone: ---
---
import core.stdc.config;
c_complex_float toNative(float re, float im)
{
return c_complex_float(re, im);
}
[Bug d/104911] [12 regression] Comparison failure in gcc/d/typesem.o etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104911 Iain Buclaw changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=104738 --- Comment #7 from Iain Buclaw --- Ah, yes, of course. libdruntime/core/stdc/stdint.d: --- alias int8_t = char; alias uint8_t = ubyte; dmd/globals.d: --- alias d_int8 = int8_t; alias d_uns8 = uint8_t; dmd/expression.d: --- case Tint8: result = cast(d_int8)value; break; case Tchar: case Tuns8: result = cast(d_uns8)value; break; --- D sees both char and ubyte as having the same signed-ness.
