[Bug 272] New: ICE with -fsanitize=address
https://bugzilla.gdcproject.org/show_bug.cgi?id=272
Bug ID: 272
Summary: ICE with -fsanitize=address
Product: GDC
Version: 4.8.x
Hardware: x86_64
OS: Linux
Status: NEW
Severity: normal
Priority: Normal
Component: gdc
Assignee: ibuc...@gdcproject.org
Reporter: c...@dawg.eu
cat > bug.d << CODE
extern(C) void my_memcmp(const(void) *s1, const(void) *s2);
void bug(const(char)* p)
{
my_memcmp(p, "__FILE__".ptr);
}
CODE
gdc -c -oflexer.o -fsanitize=address ddmd/lexer.d
ddmd/lexer.d:1:0: internal compiler error: in tree_to_uhwi, at tree.h:4044
extern(C) void my_memcmp(const(void) *s1, const(void) *s2);
The specific compiler version for that error output is gdc (gdcproject.org
20161225-v2.068.2_gcc6) 6.3.0, but it happens with 4.8.5 and 4.9.3 as well.
--
You are receiving this mail because:
You are watching all bug changes.
[Bug 272] ICE with -fsanitize=address
https://bugzilla.gdcproject.org/show_bug.cgi?id=272 Iain Buclaw changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #1 from Iain Buclaw --- This is related to void static arrays. -- You are receiving this mail because: You are watching all bug changes.
[Bug 272] ICE with -fsanitize=address
https://bugzilla.gdcproject.org/show_bug.cgi?id=272 --- Comment #2 from Iain Buclaw --- https://github.com/D-Programming-GDC/GDC/pull/552 -- You are receiving this mail because: You are watching all bug changes.
[Bug 272] ICE with -fsanitize=address
https://bugzilla.gdcproject.org/show_bug.cgi?id=272 Iain Buclaw changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED -- You are receiving this mail because: You are watching all bug changes.
[Bug 273] New: Unexplained crash in generated binary
https://bugzilla.gdcproject.org/show_bug.cgi?id=273
Bug ID: 273
Summary: Unexplained crash in generated binary
Product: GDC
Version: development
Hardware: All
OS: Linux
Status: NEW
Severity: normal
Priority: Normal
Component: gdc
Assignee: ibuc...@gdcproject.org
Reporter: sebastien.alai...@gmail.com
// crash.d
int main()
{
auto box = DubiousFunction(0);
auto buf = new ubyte[2048];
search(box);
return 0;
}
void search(Base box)
{
foreach(b; box.children)
search(b); // crash at execution occurs here
}
// any modification to the below code makes the crash disappear
Base DubiousFunction(int)
{
int a, b, c;
auto box = new Derived;
foreach(i; 0 .. 2)
box.children ~= new Derived;
char[1] tab = void;
foreach(cc; tab)
{
}
return box;
}
class Derived : Base { }
class Base
{
Base[] children;
}
I'm running an up-to-date GNU/Debian testing:
$ gdc-6 --version | head -n 1
gdc-6 (Debian 6.4.0-7) 6.4.0 20170920
$ gdc-7 --version | head -n 1
gdc-7 (Debian 7.2.0-7) 7.2.0
$ gdc-6 crash.d -o crash-6 && ./crash-6 && echo OK
OK
$ gdc-7 crash.d -o crash-7 && ./crash-7 && echo OK
[1]20610 segmentation fault ./crash-7
Replacing the first "new Derived" with "new Base" is specially interesting, as
it makes the crash disappear, but the generated code is only slightly modified:
--- crash-7.s 2017-09-29 19:05:51.800263642 +0200
+++ crash-7b.s 2017-09-29 19:06:01.469764349 +0200
@@ -147,7 +147,7 @@
movl$0, -52(%rbp)
movl$0, -56(%rbp)
movl$0, -60(%rbp)
- leaq_D5crash7Derived7__ClassZ(%rip), %rdi
+ leaq_D5crash4Base7__ClassZ(%rip), %rdi
call_d_newclass@PLT
movq%rax, -72(%rbp)
movl$0, -36(%rbp)
@@ -310,7 +310,7 @@
.quad _D6Object7__ClassZ
.quad 0
.quad 0
- .long 52
+ .long 116
.zero 4
.quad 0
.quad 0
The first diff corresponds to the call to new, the second is the "flags" field
for the TypeInfo_Class initializer for "Base" type, which gets its flag
"isAbstract" set ...
This difference is enough to trigger the crash or not.
Here's, for reference, the full (crashing) generated code with gdc-7:
.file "crash.d"
.text
.globl main
.type main, @function
main:
.LFB0:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
subq$16, %rsp
movl%edi, -4(%rbp)
movq%rsi, -16(%rbp)
movq-16(%rbp), %rcx
movl-4(%rbp), %eax
movq_Dmain@GOTPCREL(%rip), %rdx
movq%rcx, %rsi
movl%eax, %edi
call_d_run_main@PLT
leave
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE0:
.size main, .-main
.globl _Dmain
.type _Dmain, @function
_Dmain:
.LFB1:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
subq$32, %rsp
movl$0, %edi
call_D5crash15DubiousFunctionFiZC5crash4Base
movq%rax, -8(%rbp)
movl$2048, %esi
movq_D11TypeInfo_Ah6__initZ@GOTPCREL(%rip), %rax
movq%rax, %rdi
call_d_newarrayT@PLT
movq%rax, -32(%rbp)
movq%rdx, -24(%rbp)
movq-8(%rbp), %rax
movq%rax, %rdi
call_D5crash6searchFC5crash4BaseZv
movl$0, %eax
leave
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE1:
.size _Dmain, .-_Dmain
.section.rodata
.LC0:
.string "crash.d"
.text
.globl _D5crash6searchFC5crash4BaseZv
.type _D5crash6searchFC5crash4BaseZv, @function
_D5crash6searchFC5crash4BaseZv:
.LFB2:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
pushq %r13
pushq %r12
pushq %rbx
subq$56, %rsp
.cfi_offset 13, -24
.cfi_offset 12, -32
.cfi_offset 3, -40
movq%rdi, -72(%rbp)
movq-72(%rbp), %rax
movq24(%rax), %rdx
movq16(%rax), %rax
movq%rax, -64(%rbp)
movq%rdx, -56(%rbp)
movq$0, -40(%rbp)
.L8:
movq-64(%rbp), %rax
cmpq%rax, -40(%rbp)
jnb .L9
movq-56(%rbp), %rdx
movq-64(%rbp), %rax
cmpq%rax, -40(%rbp)
jb .L7
movl$7, %r12d
leaq.LC0(%rip), %r13
movq%r12, %rcx
movq%r13, %rbx
movq%r12, %rax
movq%r13, %rdx
[Bug 273] Unexplained crash in generated binary
https://bugzilla.gdcproject.org/show_bug.cgi?id=273
Iain Buclaw changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #1 from Iain Buclaw ---
Ouch, looks like some horrid stack stomping is going on.
---
(gdb) p box.children
$1 = {0x77ecb020, 0x77ecb040}
(gdb) n
(gdb) p box.children
$2 = {0x77ecb080, 0x557c71a0}
---
--
You are receiving this mail because:
You are watching all bug changes.
[Bug 273] Unexplained crash in generated binary
https://bugzilla.gdcproject.org/show_bug.cgi?id=273 --- Comment #2 from Iain Buclaw --- Oh wait, no. This is a bug in the GC. -- You are receiving this mail because: You are watching all bug changes.
[Bug 273] Unexplained crash in generated binary
https://bugzilla.gdcproject.org/show_bug.cgi?id=273 --- Comment #3 from Sebastien Alaiwan --- Hi Iain, thanks for looking. Were you able to reproduce it with the git master HEAD? -- You are receiving this mail because: You are watching all bug changes.
[Bug 273] Unexplained crash in generated binary
https://bugzilla.gdcproject.org/show_bug.cgi?id=273 --- Comment #4 from Iain Buclaw --- I can't reproduce on master locally, though I'd like to check the gdc-7 branch specifically. As this is a compiler packaged for Ubuntu, cannot rule out that some distribution-specific patches have an effect on the result. If there's a specific configuration that defeats the GC's ability to determine live objects from unreferenced, I'd like to know about it. This reminds me of https://github.com/D-Programming-GDC/GDC/commit/5021b8d031fcacac52ee43d83508a5d2856606cd - that patch is not related, but it could be a similar symptom (scanning for pointers at unaligned offsets). -- You are receiving this mail because: You are watching all bug changes.
[Bug 273] Unexplained crash in generated binary
https://bugzilla.gdcproject.org/show_bug.cgi?id=273 Johannes Pfau changed: What|Removed |Added CC||johannesp...@gmail.com --- Comment #5 from Johannes Pfau --- I can't reproduce this with the latest gdc-7 branch on an Archlinux system. Though if this is GC memory corruption it's likely even small changes in GDC/phobos or the used OS can hide such a problem :-( -- You are receiving this mail because: You are watching all bug changes.
[Bug 273] Unexplained crash in generated binary
https://bugzilla.gdcproject.org/show_bug.cgi?id=273 --- Comment #6 from Iain Buclaw --- According to the timestamp of the gcc sources in Debian/Ubuntu, the date is it was taken was 20170502. So that may narrow it down to a possible regression and fix commit. -- You are receiving this mail because: You are watching all bug changes.
[Bug 273] Unexplained crash in generated binary
https://bugzilla.gdcproject.org/show_bug.cgi?id=273 --- Comment #7 from Johannes Pfau --- OK, can reproduce with revision ac0c40aca0638ba0f22e23dd5c03da35ef4f311a. -- You are receiving this mail because: You are watching all bug changes.
[Bug 273] Unexplained crash in generated binary
https://bugzilla.gdcproject.org/show_bug.cgi?id=273 --- Comment #8 from Iain Buclaw --- (In reply to Johannes Pfau from comment #7) > OK, can reproduce with revision ac0c40aca0638ba0f22e23dd5c03da35ef4f311a. Excellent. I can only so far reproduce using f29d15a1a96856c0880aef832bf1d5859bbb1086 - after applying all debian-specific patches *and* configuring with mostly the same flags as debian's build. If I remove the patches, then it works. -- You are receiving this mail because: You are watching all bug changes.
[Bug 273] Unexplained crash in generated binary
https://bugzilla.gdcproject.org/show_bug.cgi?id=273 --- Comment #9 from Iain Buclaw --- So far I've narrowed it down to the commit *before* updating to 2.072 (bad) and the commit *after* updating to 2.075 (good). Chances am it may just be libphobos 2.071 that is bad, but will continue to dig a bit further. -- You are receiving this mail because: You are watching all bug changes.
[Bug 273] Unexplained crash in generated binary
https://bugzilla.gdcproject.org/show_bug.cgi?id=273 --- Comment #10 from Iain Buclaw --- (In reply to Iain Buclaw from comment #9) > So far I've narrowed it down to the commit *before* updating to 2.072 (bad) > and the commit *after* updating to 2.075 (good). > > Chances am it may just be libphobos 2.071 that is bad, but will continue to > dig a bit further. Yep, the first good commit is the updating phobos/druntime to 2.072. -- You are receiving this mail because: You are watching all bug changes.
[Bug 273] Unexplained crash in generated binary
https://bugzilla.gdcproject.org/show_bug.cgi?id=273 Iain Buclaw changed: What|Removed |Added Priority|Normal |Highest Severity|normal |critical --- Comment #11 from Iain Buclaw --- I think the bug is in our setting of class flags for type Derived. It seems to be setting 'ClassFlags.noPointers', however it does not set this for the class Base. This is most curious, as if Base is determined to have pointers, then Derived should have the same flag setting. Checking the part of the compiler where this logic is maintained. -- You are receiving this mail because: You are watching all bug changes.
[Bug 273] Unexplained crash in generated binary
https://bugzilla.gdcproject.org/show_bug.cgi?id=273
--- Comment #12 from Iain Buclaw ---
---
for (ClassDeclaration *bcd = cd; bcd; bcd = bcd->baseClass)
{
if (!bcd->members)
continue;
──> for (size_t i = 0; i < cd->members->dim; i++)
{
Dsymbol *sm = (*cd->members)[i];
if (sm->hasPointers ())
goto Lhaspointers;
}
}
---
It was at this point when palm said hello to face.
First bad commit was: 8bffa3ab8857398ef800fccde153029d289b68fc
https://github.com/D-Programming-GDC/GDC/pull/371
This is actually a horribly horrific horridness of a regression.
Here's a minimal test case that fails in master:
---
void main()
{
assert((Base.classinfo.m_flags & 2) == 0);// OK
assert((Derived.classinfo.m_flags & 2) == 0); // Fail
}
class Derived : Base { }
class Base
{
Base[] children;
}
---
--
You are receiving this mail because:
You are watching all bug changes.
[Bug 273] Unexplained crash in generated binary
https://bugzilla.gdcproject.org/show_bug.cgi?id=273 --- Comment #13 from Iain Buclaw --- https://github.com/D-Programming-GDC/GDC/pull/554 -- You are receiving this mail because: You are watching all bug changes.
[Bug 273] Unexplained crash in generated binary
https://bugzilla.gdcproject.org/show_bug.cgi?id=273 Iain Buclaw changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are watching all bug changes.
[Bug 116] Build script and infrastructure to produce and release Windows binaries.
https://bugzilla.gdcproject.org/show_bug.cgi?id=116 ml...@mlatu.de changed: What|Removed |Added CC||ml...@mlatu.de --- Comment #7 from ml...@mlatu.de --- Am I correct to assume that: ftp://ftp.gdcproject.org/binaries/x86_64-w64-mingw32/x86_64-w64-mingw32_2.066.1_gcc4.9.2_f378f9ab41_20150413.7z is the most recent version for compiling for mingw? In which case its missing on the download page. On the other hand, it looks like the most recent gcc version is actually 6.3? In which case, why is there no recent build for the mingw target? -- You are receiving this mail because: You are watching all bug changes.
[Bug 274] New: ice-on-valid: member of recursively templated
https://bugzilla.gdcproject.org/show_bug.cgi?id=274
Bug ID: 274
Summary: ice-on-valid: member of recursively templated
Product: GDC
Version: development
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: Normal
Component: gdc
Assignee: ibuc...@gdcproject.org
Reporter: sebastien.alai...@gmail.com
void f()
{
static class MyClass
{
MySmartPointer!MyClass m_member;
}
}
struct MySmartPointer (T)
{
T owner;
}
$ gdc crash.d
cc1d: ../../src/gcc/d/dfrontend/optimize.c:628: virtual void
Expression_optimize(Expression*, int, bool)::OptimizeVisitor::visit(CastExp*):
Assertion `cdfrom->sizeok == SIZEOKdone' failed.
cc1d: internal compiler error: Aborted
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
--
You are receiving this mail because:
You are watching all bug changes.
[Bug 274] ice-on-valid: member of recursively templated
https://bugzilla.gdcproject.org/show_bug.cgi?id=274 --- Comment #1 from Iain Buclaw --- This is reproducible on dmd/stable. -- You are receiving this mail because: You are watching all bug changes.
[Bug 274] ice-on-valid: member of recursively templated
https://bugzilla.gdcproject.org/show_bug.cgi?id=274 --- Comment #2 from Iain Buclaw --- https://issues.dlang.org/show_bug.cgi?id=17915 -- You are receiving this mail because: You are watching all bug changes.
[Bug 275] New: gdc segfaults
https://bugzilla.gdcproject.org/show_bug.cgi?id=275 Bug ID: 275 Summary: gdc segfaults Product: GDC Version: development Hardware: x86_64 OS: Linux Status: NEW Severity: normal Priority: Normal Component: gdc Assignee: ibuc...@gdcproject.org Reporter: dorian.hagl...@gmail.com Created attachment 92 --> https://bugzilla.gdcproject.org/attachment.cgi?id=92&action=edit Source that reproduces the bug GDC segfaults when compiling the attached file. Here is the log plus some infos about my box: @ /tmp 4 % uname -a Linux 4.13.0-1-amd64 #1 SMP Debian 4.13.4-1 (2017-10-01) x86_64 GNU/Linux @ /tmp 0 % gdc --version gdc (Debian 7.2.0-8) 7.2.0 Copyright (C) 2017 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. @ /tmp 0 % gdc gdc_bug.d gdc: internal compiler error: Segmentation fault (program cc1d) Please submit a full bug report, with preprocessed source if appropriate. See for instructions. -- You are receiving this mail because: You are watching all bug changes.
[Bug 275] gdc segfaults
https://bugzilla.gdcproject.org/show_bug.cgi?id=275
Sebastien Alaiwan changed:
What|Removed |Added
CC||sebastien.alai...@gmail.com
--- Comment #1 from Sebastien Alaiwan ---
(inline the attachment for convenience)
int main()
{
auto tab = [1];
assert(tab == tab[] + 1);
return 0;
}
--
You are receiving this mail because:
You are watching all bug changes.
[Bug 275] gdc segfaults
https://bugzilla.gdcproject.org/show_bug.cgi?id=275 Johannes Pfau changed: What|Removed |Added Status|NEW |RESOLVED CC||johannesp...@gmail.com Resolution|--- |UPSTREAM --- Comment #2 from Johannes Pfau --- This example no longer compiles with a recent frontend / GDC git master: test.d:4:17: error: array operation tab[] + 1 without destination memory not allowed assert(tab == tab[] + 1); ^ The frontend probably did not validate this code correctly in earlier releases. I assume this is a reduced test case? It's possible there's a bug in GDC which will be exposed by the original, non-reduced test. If you can still reproduce this bug with recent GDC git versions, please reopen and attach a test case to reproduce the bug with recent GDC versions. -- You are receiving this mail because: You are watching all bug changes.
[Bug 276] New: [ICE] internal compiler error: in extract_insn, at recog.c:2305 (-fPIE)
https://bugzilla.gdcproject.org/show_bug.cgi?id=276
Bug ID: 276
Summary: [ICE] internal compiler error: in extract_insn, at
recog.c:2305 (-fPIE)
Product: GDC
Version: development
Hardware: All
OS: All
Status: NEW
Severity: major
Priority: Normal
Component: gdc
Assignee: ibuc...@gdcproject.org
Reporter: ibuc...@gdcproject.org
---
// Written in the D programming language.
module std.file;
import core.sys.posix.unistd;
class FileException : Exception
{
import std.conv;
uint errno;
this(in char[] name, in char[] ) {
super(text(name));
}
this(in char[] name) {
import std.exception ;
this(name, errnoString(errno));
}
}
T cenforce(T)(T , const(char)[] name)
{
throw new FileException(name);
}
string getcwd()
{
auto p = cenforce(core.sys.posix.unistd.getcwd(null, 0),
"cannot get cwd");
return p[0 .. core.stdc.string.strlen(p)].idup;
}
string tempDir() {
static string cache;
import std.process ;
cache = environment.get("TMPDIR");
if (cache is null) getcwd;
return cache;
}
---
file.d: In function ‘tempDir’:
file.d:40:1: error: unrecognizable insn:
}
^
(insn 58 57 59 2 (set (reg/f:DI 121)
(const:DI (plus:DI (unspec:DI [
(symbol_ref:DI ("_D3std4file7tempDirFZ5cacheAya")
[flags 0x2a] )
] UNSPEC_NTPOFF)
(const_int 8 [0x8] "file.d":37 -1
(nil))
during RTL pass: subreg2
file.d:40:1: internal compiler error: in extract_insn, at recog.c:2305
0x5ea119 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../dev/gcc/rtl-error.c:108
0x5ea13a _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../dev/gcc/rtl-error.c:116
0xb57c6c extract_insn(rtx_insn*)
../../dev/gcc/recog.c:2305
0x12236fc decompose_multiword_subregs
../../dev/gcc/lower-subreg.c:1533
0x12241ad execute
../../dev/gcc/lower-subreg.c:1719
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug 277] [ICE] internal compiler error: in change_address_1, at emit-rtl.c:2162 (-fPIE)
https://bugzilla.gdcproject.org/show_bug.cgi?id=277 Iain Buclaw changed: What|Removed |Added Priority|Normal |High Hardware|All |x86_64 -- You are receiving this mail because: You are watching all bug changes.
[Bug 276] [ICE] internal compiler error: in extract_insn, at recog.c:2305 (-fPIE)
https://bugzilla.gdcproject.org/show_bug.cgi?id=276 Iain Buclaw changed: What|Removed |Added Priority|Normal |High Hardware|All |x86_64 -- You are receiving this mail because: You are watching all bug changes.
[Bug 277] New: [ICE] internal compiler error: in change_address_1, at emit-rtl.c:2162 (-fPIE)
https://bugzilla.gdcproject.org/show_bug.cgi?id=277
Bug ID: 277
Summary: [ICE] internal compiler error: in change_address_1, at
emit-rtl.c:2162 (-fPIE)
Product: GDC
Version: development
Hardware: All
OS: All
Status: NEW
Severity: major
Priority: Normal
Component: gdc
Assignee: ibuc...@gdcproject.org
Reporter: ibuc...@gdcproject.org
Related to bug 276 (or may even be the cause of).
---
string tempDir()
{
static string cache;
return cache;
}
---
during RTL pass: split2
file.d: In function ‘tempDir’:
file.d:5:1: internal compiler error: in change_address_1, at emit-rtl.c:2162
}
^
0x5b7ac9 change_address_1
../../dev/gcc/emit-rtl.c:2162
0x946e4d adjust_address_1(rtx_def*, machine_mode, long, int, int, int, long)
../../dev/gcc/emit-rtl.c:2300
0xe0cb04 split_double_mode(machine_mode, rtx_def**, int, rtx_def**, rtx_def**)
../../dev/gcc/config/i386/i386.c:18116
0xe0e22b ix86_split_to_parts
../../dev/gcc/config/i386/i386.c:24693
0xe16b44 ix86_split_long_move(rtx_def**)
../../dev/gcc/config/i386/i386.c:24782
0xfce625 gen_split_23(rtx_insn*, rtx_def**)
../../dev/gcc/config/i386/i386.md:2363
0x111e554 split_18
../../dev/gcc/config/i386/i386.md:6535
0x115784b split_insns(rtx_def*, rtx_insn*)
../../dev/gcc/config/i386/i386.md:13105
0x949023 try_split(rtx_def*, rtx_insn*, int)
../../dev/gcc/emit-rtl.c:3692
0xb552b1 split_insn
../../dev/gcc/recog.c:2883
0xb59f27 split_all_insns()
../../dev/gcc/recog.c:2972
0xb59fe8 execute
../../dev/gcc/recog.c:3884
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug 277] [ICE] internal compiler error: in change_address_1, at emit-rtl.c:2162 (-fPIE)
https://bugzilla.gdcproject.org/show_bug.cgi?id=277 Iain Buclaw changed: What|Removed |Added URL||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=82725 --- Comment #1 from Iain Buclaw --- Affects other frontends, raised upstream bug. -- You are receiving this mail because: You are watching all bug changes.
[Bug 277] [ICE] internal compiler error: in change_address_1, at emit-rtl.c:2162 (-fPIE)
https://bugzilla.gdcproject.org/show_bug.cgi?id=277 Iain Buclaw changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Iain Buclaw --- This was fixed in GCC -- You are receiving this mail because: You are watching all bug changes.
[Bug 276] [ICE] internal compiler error: in extract_insn, at recog.c:2305 (-fPIE)
https://bugzilla.gdcproject.org/show_bug.cgi?id=276 Iain Buclaw changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Iain Buclaw --- This was indeed related to bug 277. And is also fixed by same patch to gcc. -- You are receiving this mail because: You are watching all bug changes.
[Bug 264] [ICE] (update_equiv_regs) ira.c:3425: Assertion failed gcc_assert (REG_P (dest));
https://bugzilla.gdcproject.org/show_bug.cgi?id=264 Iain Buclaw changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Iain Buclaw --- Upstream bug fixed. -- You are receiving this mail because: You are watching all bug changes.
[Bug 271] [regression] ICE-on-valid when generating debug info
https://bugzilla.gdcproject.org/show_bug.cgi?id=271 Iain Buclaw changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Iain Buclaw --- As above, this was fixed in a commit back in August. -- You are receiving this mail because: You are watching all bug changes.
[Bug 180] DMD -O is faster than GDC -O3 for byte and short math
https://bugzilla.gdcproject.org/show_bug.cgi?id=180 Iain Buclaw changed: What|Removed |Added Resolution|--- |WONTFIX Status|NEW |RESOLVED --- Comment #4 from Iain Buclaw --- And on my test machine, I get faster results if I remove `-march=native` from the commandline. I can only conclude that this test is contrived - and certainly looking at the generated trees, there's nothing we're really doing wrong here. This is testing GCC's ability to produce good code, not GDC's ability. -- You are receiving this mail because: You are watching all bug changes.
[Bug 109] Error compiling 4.8.2 on Cygwin
https://bugzilla.gdcproject.org/show_bug.cgi?id=109 --- Comment #1 from Iain Buclaw --- >From the source: object.h --- #define POSIX (__linux__ || __APPLE__ || __FreeBSD__ || __OpenBSD__ || __sun) filename.c --- #if _WIN32 char sep = '\\'; #elif POSIX char sep = '/'; #endif if (path[strlen(path) - 1] != sep) --- So cygwin is neither _WIN32 or POSIX. http://nadeausoftware.com/articles/2012/01/c_c_tip_how_use_compiler_predefined_macros_detect_operating_system#WindowswithCygwinPOSIX There is a debian patch that supports at hurd and kfreebsd. https://anonscm.debian.org/viewvc/gcccvs/branches/sid/gcc-8/debian/patches/gdc-frontend-posix.diff?revision=9713&view=markup Cygwin should be checked and added as well. -- You are receiving this mail because: You are watching all bug changes.
[Bug 129] Diagnostic bug in casting to array types.
https://bugzilla.gdcproject.org/show_bug.cgi?id=129 Iain Buclaw changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #1 from Iain Buclaw --- Seems like this is now a front-end error. -- You are receiving this mail because: You are watching all bug changes.
[Bug 230] Turn on optimizations when building druntime and phobos unittester
https://bugzilla.gdcproject.org/show_bug.cgi?id=230 Iain Buclaw changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #1 from Iain Buclaw --- *** This bug has been marked as a duplicate of bug 193 *** -- You are receiving this mail because: You are watching all bug changes.
[Bug 193] Druntime and Phobos unittests should be compiled with optimisations
https://bugzilla.gdcproject.org/show_bug.cgi?id=193 --- Comment #1 from Iain Buclaw --- *** Bug 230 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[Bug 265] [rejects-valid] Name resolution clash (vs dmd)
https://bugzilla.gdcproject.org/show_bug.cgi?id=265 Iain Buclaw changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Iain Buclaw --- Closing as per last comments. -- You are receiving this mail because: You are watching all bug changes.
[Bug 200] Excess precision appears to be precisely defined in D
https://bugzilla.gdcproject.org/show_bug.cgi?id=200 Iain Buclaw changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Iain Buclaw --- https://github.com/D-Programming-GDC/GDC/pull/568 -- You are receiving this mail because: You are watching all bug changes.
[Bug 274] ice-on-valid: member of recursively templated
https://bugzilla.gdcproject.org/show_bug.cgi?id=274 Iain Buclaw changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Iain Buclaw --- https://github.com/D-Programming-GDC/GDC/pull/567 -- You are receiving this mail because: You are watching all bug changes.
[Bug 278] New: ICE in -fdump-tree-original-raw
https://bugzilla.gdcproject.org/show_bug.cgi?id=278
Bug ID: 278
Summary: ICE in -fdump-tree-original-raw
Product: GDC
Version: development
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: Normal
Component: gdc
Assignee: ibuc...@gdcproject.org
Reporter: johannesp...@gmail.com
Test case:
--
import core.bitop;
struct S
{
uint field;
uint prop() @property
{
return field;
}
uint prop(uint value) @property
{
return field = value;
}
}
void main()
{
S s;
((auto ref _e1) => _e1.prop(_e1.prop() + 1))(s);
volatileStore(cast(uint*)32, s.field);
}
--
gdc -fdump-tree-original-raw -c test.d
: In function 'main':
:1:0: internal compiler error: tree check: expected tree that contains
'decl with visibility' structure, have 'translation_unit_decl' in
dequeue_and_dump, at tree-dump.c:340
0x5d80d9 tree_contains_struct_check_failed(tree_node const*,
tree_node_structure_enum, char const*, int, char const*)
../../gcc-8-20171029/gcc/tree.c:9268
0xca1fec contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc-8-20171029/gcc/tree.h:3208
0xca1fec dequeue_and_dump
../../gcc-8-20171029/gcc/tree-dump.c:340
0xca1fec dump_node(tree_node const*, unsigned long, _IO_FILE*)
../../gcc-8-20171029/gcc/tree-dump.c:745
0xc83b09 dump_function_to_file(tree_node*, _IO_FILE*, unsigned long)
../../gcc-8-20171029/gcc/tree-cfg.c:7767
0x862397 dump_function(int, tree_node*)
../../gcc-8-20171029/gcc/dumpfile.c:1014
0x75b46e finish_function(tree_node*)
../../gcc-8-20171029/gcc/d/decl.cc:1831
0x760521 DeclVisitor::visit(FuncDeclaration*)
../../gcc-8-20171029/gcc/d/decl.cc:876
0x75f977 DeclVisitor::visit(AttribDeclaration*)
../../gcc-8-20171029/gcc/d/decl.cc:217
0x75b011 build_decl_tree(Dsymbol*)
../../gcc-8-20171029/gcc/d/decl.cc:898
0x76d3f0 build_module_tree(Module*)
../../gcc-8-20171029/gcc/d/modules.cc:716
0x75faab DeclVisitor::visit(Module*)
../../gcc-8-20171029/gcc/d/decl.cc:137
0x75b011 build_decl_tree(Dsymbol*)
../../gcc-8-20171029/gcc/d/decl.cc:898
0x754438 d_parse_file()
../../gcc-8-20171029/gcc/d/d-lang.cc:1219
--
You are receiving this mail because:
You are watching all bug changes.
[Bug 278] ICE in -fdump-tree-original-raw
https://bugzilla.gdcproject.org/show_bug.cgi?id=278 --- Comment #1 from Iain Buclaw --- First check the gcc-8-20171105 tree (can't reproduce here, but will rebuild incase of oddities). -- You are receiving this mail because: You are watching all bug changes.
[Bug 278] ICE in -fdump-tree-original-raw
https://bugzilla.gdcproject.org/show_bug.cgi?id=278 Iain Buclaw changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |UPSTREAM --- Comment #2 from Iain Buclaw --- https://gcc.gnu.org/ml/gcc-patches/2017-11/msg00037.html -- You are receiving this mail because: You are watching all bug changes.
[Bug 279] New: ICE in local class definition.
https://bugzilla.gdcproject.org/show_bug.cgi?id=279
Bug ID: 279
Summary: ICE in local class definition.
Product: GDC
Version: development
Hardware: x86_64
OS: Linux
Status: NEW
Severity: normal
Priority: Normal
Component: gdc
Assignee: ibuc...@gdcproject.org
Reporter: dorian.hagl...@gmail.com
The following code fails to compile with gdc (Debian 7.2.0-12) 7.2.1 20171025.
struct S (T)
{
this(int)
{
}
T t;
}
int main()
{
class C
{
S!C member;
}
return 0;
}
@ /home/dorian/dev/lib_algo 0 % gdc mini.d
cc1d: ../../src/gcc/d/dfrontend/optimize.c:628: virtual void
Expression_optimize(Expression*, int, bool)::OptimizeVisitor::visit(CastExp*):
Assertion `cdfrom->sizeok == SIZEOKdone' failed.
cc1d: internal compiler error: Aborted
Please submit a full bug report,
with preprocessed source if appropriate.
About my box:
@ /home/dorian/dev/lib_algo 1 % uname -a
Linux allegro75 4.13.0-1-amd64 #1 SMP Debian 4.13.4-2 (2017-10-15) x86_64
GNU/Linux
Notes:
The code compiles if the class C definition is moved outside the main's scope.
The code compiles if 'S!C' is replaced by 'S!int'. (A self referencing issue?)
The code compiles if the struct 'S' doesn't have a 'T' member.
The code compiles as is with dmd and ldc.
--
You are receiving this mail because:
You are watching all bug changes.
[Bug 274] ice-on-valid: member of recursively templated
https://bugzilla.gdcproject.org/show_bug.cgi?id=274 Sebastien Alaiwan changed: What|Removed |Added CC||dorian.hagl...@gmail.com --- Comment #4 from Sebastien Alaiwan --- *** Bug 279 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[Bug 279] ICE in local class definition.
https://bugzilla.gdcproject.org/show_bug.cgi?id=279 Sebastien Alaiwan changed: What|Removed |Added Resolution|--- |DUPLICATE CC||sebastien.alai...@gmail.com Status|NEW |RESOLVED --- Comment #1 from Sebastien Alaiwan --- *** This bug has been marked as a duplicate of bug 274 *** -- You are receiving this mail because: You are watching all bug changes.
[Bug 280] New: ICE with static immutable RedBlackTree
https://bugzilla.gdcproject.org/show_bug.cgi?id=280
Bug ID: 280
Summary: ICE with static immutable RedBlackTree
Product: GDC
Version: development
Hardware: All
OS: All
Status: NEW
Severity: major
Priority: Normal
Component: libgphobos
Assignee: ibuc...@gdcproject.org
Reporter: elro...@slashem.me
I get a segfault with this code:
void main() {
import std.container;
static immutable s = new RedBlackTree!int('h');
}
--
You are receiving this mail because:
You are watching all bug changes.
[Bug 280] ICE with static immutable RedBlackTree
https://bugzilla.gdcproject.org/show_bug.cgi?id=280 Iain Buclaw changed: What|Removed |Added CC||ibuc...@gdcproject.org Component|libgphobos |gdc -- You are receiving this mail because: You are watching all bug changes.
[Bug 103] -fdeps Doesn't Handle Multiple Source Files
https://bugzilla.gdcproject.org/show_bug.cgi?id=103 Iain Buclaw changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED -- You are receiving this mail because: You are watching all bug changes.
[Bug 281] New: NRVO tests behave different than in DMD
https://bugzilla.gdcproject.org/show_bug.cgi?id=281
Bug ID: 281
Summary: NRVO tests behave different than in DMD
Product: GDC
Version: development
Hardware: All
OS: All
Status: NEW
Severity: minor
Priority: Normal
Component: gdc
Assignee: ibuc...@gdcproject.org
Reporter: be...@caraus.de
extern (C) int printf(const(char*) fmt, ...);
/**/
// 13089
struct S13089
{
@disable this(this);// non nothrow
}
void* p13089;
S13089[1000] foo13089() nothrow
{
typeof(return) data;
p13089 = &data;
return data;
}
void main()
{
immutable data = foo13089();
assert(p13089 == &data);
}
The assertion holds in DMD but fails in GCC. The question is whether it is
something should be changed.
References:
http://forum.dlang.org/post/gverkczeotvadwmdo...@forum.dlang.org
https://dlang.org/glossary.html#nrvo
https://github.com/D-Programming-GDC/GDC/pull/573
--
You are receiving this mail because:
You are watching all bug changes.
[Bug 270] Weird ctor / dtor function names
https://bugzilla.gdcproject.org/show_bug.cgi?id=270 Iain Buclaw changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Iain Buclaw --- https://github.com/D-Programming-GDC/GDC/pull/575 -- You are receiving this mail because: You are watching all bug changes.
[Bug 280] ICE with static immutable RedBlackTree
https://bugzilla.gdcproject.org/show_bug.cgi?id=280 Iain Buclaw changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Iain Buclaw --- https://github.com/D-Programming-GDC/GDC/pull/574 -- You are receiving this mail because: You are watching all bug changes.
[Bug 240] i++ not working correctly as arg to writeln
https://bugzilla.gdcproject.org/show_bug.cgi?id=240 Iain Buclaw changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Iain Buclaw --- https://github.com/D-Programming-GDC/GDC/pull/576 -- You are receiving this mail because: You are watching all bug changes.
[Bug 282] New: [ICE] internal compiler error: in chainon, at tree.c:2865
https://bugzilla.gdcproject.org/show_bug.cgi?id=282
Bug ID: 282
Summary: [ICE] internal compiler error: in chainon, at
tree.c:2865
Product: GDC
Version: development
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: Normal
Component: gdc
Assignee: ibuc...@gdcproject.org
Reporter: ibuc...@gdcproject.org
// generated by defuzzed, seed 52097
int v0_0=61;
class C0
{
class C0
{
}
class C1
{
}
void f32 ()
{
}
void f32 ()
{
}
}
--
You are receiving this mail because:
You are watching all bug changes.
[Bug 282] [ICE] internal compiler error: in chainon, at tree.c:2865
https://bugzilla.gdcproject.org/show_bug.cgi?id=282 Iain Buclaw changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Iain Buclaw --- https://github.com/D-Programming-GDC/GDC/pull/579 -- You are receiving this mail because: You are watching all bug changes.
[Bug 283] Wrong code with -O, possible cleanup_point_expr bug
https://bugzilla.gdcproject.org/show_bug.cgi?id=283 Iain Buclaw changed: What|Removed |Added Severity|normal |critical Priority|Normal |High --- Comment #1 from Iain Buclaw --- The above example -- You are receiving this mail because: You are watching all bug changes.
[Bug 283] Wrong code with -O, possible cleanup_point_expr bug
https://bugzilla.gdcproject.org/show_bug.cgi?id=283 --- Comment #2 from Iain Buclaw --- The above reduced test fails when compiled with: 'gdc -frelease -O' It runs just fine when compiling with: 'gdc -frelease' An earlier, more complex version of this test passed when built with -O2, but failed with -O3. When compiling the original source module (sdtor.d), it always succeeds regardless of what optimization flags you pass. So, the same program ran in isolation can do something different than when compiled with a larger codebase. Making it a rather peculiar optimization bug. -- You are receiving this mail because: You are watching all bug changes.
[Bug 283] New: Wrong code with -O, possible cleanup_point_expr bug
https://bugzilla.gdcproject.org/show_bug.cgi?id=283
Bug ID: 283
Summary: Wrong code with -O, possible cleanup_point_expr bug
Product: GDC
Version: development
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: Normal
Component: gdc
Assignee: ibuc...@gdcproject.org
Reporter: ibuc...@gdcproject.org
Can't reduce the program down much further. Something in our code-gen is not
quite right, and the optimizer is making false assumptions as a result of it.
During the reduction of it, making a change to `front()` makes the problem go
away. The different between the two is that the "bad" version generates a
CLEANUP_POINT_EXPR for the temporary, making it a possible regression.
See: https://github.com/D-Programming-GDC/GDC/pull/585
---
version = SIGILL; // Comment out to get segfault instead.
//version = SUCCESS;// Uncomment to get a successful program.
struct Impl
{
size_t _count;
}
struct RefCountedStore
{
Impl* _store;
void initialize()
{
import core.stdc.stdlib : malloc;
_store = cast(Impl*) malloc(Impl.sizeof);
_store._count = 1;
}
bool isInitialized()
{
return _store !is null;
}
void ensureInitialized()
{
if (!isInitialized)
initialize();
}
}
struct RefCounted14443
{
RefCountedStore _refCounted;
this(int)
{
_refCounted.initialize();
}
this(this)
{
version (SIGILL)
{
if (!_refCounted.isInitialized)
assert(0);
}
++_refCounted._store._count;
}
~this()
{
version (SIGILL)
{
if (!_refCounted.isInitialized)
assert(0);
if (_refCounted._store._count <= 0)
assert(0);
}
if (--_refCounted._store._count)
return;
import core.stdc.stdlib : free;
free(_refCounted._store);
_refCounted._store = null;
}
int refCountedPayload()
{
_refCounted.ensureInitialized();
return 1;
}
}
struct PathRange14443
{
RefCounted14443 path;
@property PathElement14443 front()
{
version (SUCCESS)
{
auto tmp = path.refCountedPayload();
return PathElement14443(this);
}
else
return PathElement14443(this, path.refCountedPayload());
}
}
struct PathElement14443
{
PathRange14443 range;
version (SUCCESS)
{
this(PathRange14443 range)
{
this.range = range;
}
}
else
{
this(PathRange14443 range, int)
{
this.range = range;
}
}
}
void main()
{
auto path = RefCounted14443(12);
if (path._refCounted._store._count != 1)
assert(0);
{
auto _r = PathRange14443(path);
if (path._refCounted._store._count != 2)
assert(0);
{
auto element = _r.front;
if (path._refCounted._store._count != 3)
assert(0);
}
if (path._refCounted._store._count != 2)
assert(0);
}
if (path._refCounted._store._count != 1)
assert(0);
}
--
You are receiving this mail because:
You are watching all bug changes.
[Bug 283] Wrong code with -O, possible cleanup_point_expr bug
https://bugzilla.gdcproject.org/show_bug.cgi?id=283
--- Comment #3 from Iain Buclaw ---
Yes I think the CLEANUP_POINT_EXPR is the problem.
In briefest way of describing, the following is generated by codegen:
---
<
__gate68 = 1;>>;
__slPathE67 = {};
return = *__ctor (&__slPathE67, &__pfx69, __pfy70);
---
Gimplified into try/finally as:
---
try
{
__gate68 = 0;
__pfx69 = *this;
__fieldPostblit (&__pfx69);
try
{
try
{
__gate68 = 1;
}
finally
{
__gate68.0_1 = __gate68;
_2 = ~__gate68.0_1;
if (_2 != 0) goto ; else goto ;
:
__fieldDtor (&__pfx69);
:
}
}
finally
{
__pfx69 = {CLOBBER};// ***
}
__slPathE67 = {}
_4 = __ctor (&__slPathE67, &__pfx69, __pfy70);// ***
= *_4;
return ;
}
---
Marked with *** are places of interest. First, temporary var __pfx69 is
clobbered (it is invalidated for further reuse). Second, its address is taken
(undefined behaviour at this point).
This is likely a problem with the rewrite done in d_build_call, the
cleanup_point expression should encapsulate both parameter and call.
--
You are receiving this mail because:
You are watching all bug changes.
[Bug 283] Wrong code with -O, possible cleanup_point_expr bug
https://bugzilla.gdcproject.org/show_bug.cgi?id=283 Iain Buclaw changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Iain Buclaw --- https://github.com/D-Programming-GDC/GDC/pull/606 -- You are receiving this mail because: You are watching all bug changes.
[Bug 252] ICE when compiling with -flto
https://bugzilla.gdcproject.org/show_bug.cgi?id=252 Iain Buclaw changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Iain Buclaw --- https://github.com/D-Programming-GDC/GDC/pull/578 -- You are receiving this mail because: You are watching all bug changes.
[Bug 284] internal compiler error: in add_stack_var, at cfgexpand.c:453
https://bugzilla.gdcproject.org/show_bug.cgi?id=284 Iain Buclaw changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Iain Buclaw --- https://github.com/D-Programming-GDC/GDC/pull/620 -- You are receiving this mail because: You are watching all bug changes.
[Bug 285] New: Backend optimizer assumes strings are null terminated.
https://bugzilla.gdcproject.org/show_bug.cgi?id=285
Bug ID: 285
Summary: Backend optimizer assumes strings are null terminated.
Product: GDC
Version: development
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: Normal
Component: gdc
Assignee: ibuc...@gdcproject.org
Reporter: ibuc...@gdcproject.org
>From phobos.
---
inout(char)[] fromStringz(inout(char)* cString) @nogc @system pure nothrow {
import core.stdc.string : strlen;
return cString ? cString[0 .. strlen(cString)] : null;
}
///
void main()
{
assert(fromStringz(null) == null);
assert(fromStringz("foo") == "foo");
}
---
Although gdc calls: build_string(3, "foo"), gcc itself still expects us to
factor in the null terminator into the length.
Because of this, when optimizing an inlined 'fromStringz', the result of
strlen("foo") is folded into the value '2', instead of the expected '3'.
--
You are receiving this mail because:
You are watching all bug changes.
[Bug 286] New: Returning AA value whose key is a RefCounted type gets wrong value.
https://bugzilla.gdcproject.org/show_bug.cgi?id=286
Bug ID: 286
Summary: Returning AA value whose key is a RefCounted type gets
wrong value.
Product: GDC
Version: development
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: Normal
Component: gdc
Assignee: ibuc...@gdcproject.org
Reporter: ibuc...@gdcproject.org
---
import std.uni;
import std.stdio;
//accessor with caching
CharMatcher getMatcher(CodepointSet set)
{
static CharMatcher[CodepointSet] matcherCache;
auto p = set in matcherCache;
if (p)
return *p;
return (matcherCache[set] = CharMatcher(set));
}
struct CharMatcher
{
uint[4] filter;
this(CodepointSet set)
{
auto asciiSet = set & unicode.ASCII;
foreach (iv; asciiSet.byInterval)
{
foreach (v; iv.a .. iv.b)
{
immutable i = ((v >> 7) ^ v) & 0x7F;
filter[i >> 5] |= 1 << (i & 31);
}
}
writeln(this);
}
}
void main()
{
auto t = getMatcher(unicode.Nd);
writeln(t);
if (t.filter == [0,0,0,0])
assert(0);
return;
}
---
Outputs:
CharMatcher([0, 67043328, 0, 0])
CharMatcher([0, 0, 0, 0])
Illegal instruction
Only happens with -frelease.
--
You are receiving this mail because:
You are watching all bug changes.
[Bug 287] New: ice-on-valid: segfault when taking the address of a delegate
https://bugzilla.gdcproject.org/show_bug.cgi?id=287
Bug ID: 287
Summary: ice-on-valid: segfault when taking the address of a
delegate
Product: GDC
Version: development
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: Normal
Component: gdc
Assignee: ibuc...@gdcproject.org
Reporter: sebastien.alai...@gmail.com
$ cat yo.d
class A
{
void f()
{
class B
{
void g()
{
auto crash = &f;
}
}
}
}
$ gdc yo.d
yo.d: In function ‘g’:
yo.d:9:14: internal compiler error: Segmentation fault
auto crash = &f;
^
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
$ gdc --version
gdc (Debian 7.3.0-11) 7.3.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
--
You are receiving this mail because:
You are watching all bug changes.
[Bug 287] ice-on-valid: segfault when taking the address of a delegate
https://bugzilla.gdcproject.org/show_bug.cgi?id=287 Iain Buclaw changed: What|Removed |Added CC||ibuc...@gdcproject.org --- Comment #1 from Iain Buclaw --- Probably a which this? bug. There would possibly be a chain from B->f->A. Has this been tried in master also? -- You are receiving this mail because: You are watching all bug changes.
[Bug 287] ice-on-valid: segfault when taking the address of a delegate
https://bugzilla.gdcproject.org/show_bug.cgi?id=287 --- Comment #2 from Sebastien Alaiwan --- Not tried on master (I gave up compiling from master, this is too much of a hassle - feel free to try to convince me of the contrary :D). -- You are receiving this mail because: You are watching all bug changes.
[Bug 287] ice-on-valid: segfault when taking the address of a delegate
https://bugzilla.gdcproject.org/show_bug.cgi?id=287 --- Comment #3 from Iain Buclaw --- You could probably try on the gdc-7 branch, so you don't have to keep gcc updated. ;-) -- You are receiving this mail because: You are watching all bug changes.
[Bug 287] ice-on-valid: segfault when taking the address of a delegate
https://bugzilla.gdcproject.org/show_bug.cgi?id=287 --- Comment #4 from Iain Buclaw --- OK, got the backtrace, and I think this is a duplicate of bug 261. -- You are receiving this mail because: You are watching all bug changes.
[Bug 286] Returning AA value whose key is a RefCounted type gets wrong value.
https://bugzilla.gdcproject.org/show_bug.cgi?id=286 Iain Buclaw changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Iain Buclaw --- https://github.com/D-Programming-GDC/GDC/pull/640 -- You are receiving this mail because: You are watching all bug changes.
[Bug 285] Backend optimizer assumes strings are null terminated.
https://bugzilla.gdcproject.org/show_bug.cgi?id=285 Iain Buclaw changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Iain Buclaw --- https://github.com/D-Programming-GDC/GDC/pull/638 -- You are receiving this mail because: You are watching all bug changes.
[Bug 288] New: strange nonsensical x86-64 code generation with -O3 - rats' nest of useless conditional jumps
https://bugzilla.gdcproject.org/show_bug.cgi?id=288 Bug ID: 288 Summary: strange nonsensical x86-64 code generation with -O3 - rats' nest of useless conditional jumps Product: GDC Version: 7.x Hardware: x86_64 OS: Linux Status: NEW Severity: minor Priority: Normal Component: gdc Assignee: ibuc...@gdcproject.org Reporter: ce...@cecilward.com Created attachment 93 --> https://bugzilla.gdcproject.org/attachment.cgi?id=93&action=edit D source; debug-only c9de is the weird stuff so compiling with -fdebug is essential because the source code in question is inside a D 'debug' cond so otherwise no relevant code will be generated This seems to be a quirk in the code generated by the GCC x86-64 backend itself in my humble opinion, and very much doubt it has much to do with GDC itself. I am not alleging that the generated code does not perform the correct function, I haven't gone through it carefully enough, but the x64 code generated is just very strange and utterly pointless. I compiled with GDC 7.x for x64 with -O3 -fdebug -march=skylake See the long list of useless conditional jumps towards the end of the first function in the asm output (whose demangled name is test.t1(unit)) -- You are receiving this mail because: You are watching all bug changes.
[Bug 288] strange nonsensical x86-64 code generation with -O3 - rats' nest of useless conditional jumps
https://bugzilla.gdcproject.org/show_bug.cgi?id=288 --- Comment #1 from Iain Buclaw --- > See the long list of useless conditional jumps towards the end of the first > function in the asm output (whose demangled name is test.t1(unit)) Well, you'd never use -O3 if you care about speed anyway. :-) And they are not useless jumps, it's just the foreach loop unrolled in its entirety. You can see that it's a feature of the gcc-7 series and latter, irregardless of the target, they all produce the same unrolled loop. https://explore.dgnu.org/g/vD3N4Y It might be a nice experiment to add pragma(ivdep) and pragma(unroll) support to give you more control. https://gcc.gnu.org/onlinedocs/gcc/Loop-Specific-Pragmas.html I wouldn't hold my breath though (this is not strictly a bug). -- You are receiving this mail because: You are watching all bug changes.
[Bug 289] Static linking has wrong libc/libpthread order
https://bugzilla.gdcproject.org/show_bug.cgi?id=289 Stefan Schuerger changed: What|Removed |Added CC||ste...@schuerger.com --- Comment #1 from Stefan Schuerger --- Is there perhaps a workaround besides the -v order change? -- You are receiving this mail because: You are watching all bug changes.
[Bug 289] New: Static linking has wrong libc/libpthread order
https://bugzilla.gdcproject.org/show_bug.cgi?id=289 Bug ID: 289 Summary: Static linking has wrong libc/libpthread order Product: GDC Version: 7.x Hardware: All OS: All Status: NEW Severity: major Priority: Normal Component: gdc Assignee: ibuc...@gdcproject.org Reporter: ste...@schuerger.com When compiling a little "helloworld" program with an ARM GDC cross-compiler toolchain, I encounter a symbol error: $ arm-linux-gnueabihf-gdc helloworld.o -o helloworld.arm -static /opt/cross/lib/gcc/arm-linux-gnueabihf/7.3.0/../../../../arm-linux-gnueabihf/lib/libgphobos.a(stdio.o): In function `_D3std5stdio11openNetworkFAyatZS3std5stdio4File': /home/stefan/src-gcc/build/build-gcc/arm-linux-gnueabihf/libphobos/src/../../../../gcc-7.3.0/libphobos/src/std/stdio.d:5122: warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /opt/cross/lib/gcc/arm-linux-gnueabihf/7.3.0/../../../../arm-linux-gnueabihf/lib/libpthread.a(lowlevellock.o): In function `__lll_lock_wait_private': /home/stefan/src-gcc/build/glibc-2.27/nptl/lowlevellock.c:28: multiple definition of `__lll_lock_wait_private' /opt/cross/lib/gcc/arm-linux-gnueabihf/7.3.0/../../../../arm-linux-gnueabihf/lib/libc.a(libc-lowlevellock.o):/home/stefan/src-gcc/build/glibc-2.27/nptl/./lowlevellock.c:28: first defined here collect2: error: ld returned 1 exit status -v shows glibc is linked before libpthread, that's wrong: ... /opt/cross/libexec/gcc/arm-linux-gnueabihf/7.3.0/collect2 -plugin /opt/cross/libexec/gcc/arm-linux-gnueabihf/7.3.0/liblto_plugin.so -plugin-opt=/opt/cross/libexec/gcc/arm-linux-gnueabihf/7.3.0/lto-wrapper -plugin-opt=-fresolution=/tmp/ccWgyAkd.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_eh -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lm -plugin-opt=-pass-through=-lpthread -plugin-opt=-pass-through=-ldl -Bstatic -X -m armelf_linux_eabi -o helloworld.arm /opt/cross/lib/gcc/arm-linux-gnueabihf/7.3.0/../../../../arm-linux-gnueabihf/lib/crt1.o /opt/cross/lib/gcc/arm-linux-gnueabihf/7.3.0/../../../../arm-linux-gnueabihf/lib/crti.o /opt/cross/lib/gcc/arm-linux-gnueabihf/7.3.0/crtbeginT.o -L/opt/cross/lib/gcc/arm-linux-gnueabihf/7.3.0 -L/opt/cross/lib/gcc/arm-linux-gnueabihf/7.3.0/../../../../arm-linux-gnueabihf/lib helloworld.o -lgphobos -lgdruntime --start-group -lgcc -lgcc_eh -lc -lm -lpthread -ldl --end-group /opt/cross/lib/gcc/arm-linux-gnueabihf/7.3.0/crtend.o /opt/cross/lib/gcc/arm-linux-gnueabihf/7.3.0/../../../../arm-linux-gnueabihf/lib/crtn.o When changing the link order manually, it works: /opt/cross/libexec/gcc/arm-linux-gnueabihf/7.3.0/collect2 -plugin /opt/cross/libexec/gcc/arm-linux-gnueabihf/7.3.0/liblto_plugin.so -plugin-opt=/opt/cross/libexec/gcc/arm-linux-gnueabihf/7.3.0/lto-wrapper -plugin-opt=-fresolution=/tmp/cc5Y6i7I.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_eh -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lm -plugin-opt=-pass-through=-lpthread -plugin-opt=-pass-through=-ldl -Bstatic -X -m armelf_linux_eabi -o helloworld.arm /opt/cross/lib/gcc/arm-linux-gnueabihf/7.3.0/../../../../arm-linux-gnueabihf/lib/crt1.o /opt/cross/lib/gcc/arm-linux-gnueabihf/7.3.0/../../../../arm-linux-gnueabihf/lib/crti.o /opt/cross/lib/gcc/arm-linux-gnueabihf/7.3.0/crtbeginT.o -L/opt/cross/lib/gcc/arm-linux-gnueabihf/7.3.0 -L/opt/cross/lib/gcc/arm-linux-gnueabihf/7.3.0/../../../../arm-linux-gnueabihf/lib helloworld.o -lgphobos -lgdruntime --start-group -lgcc -lgcc_eh -lpthread -lc -lm -ldl --end-group /opt/cross/lib/gcc/arm-linux-gnueabihf/7.3.0/crtend.o /opt/cross/lib/gcc/arm-linux-gnueabihf/7.3.0/../../../../arm-linux-gnueabihf/lib/crtn.o Please fix. Thanks! -- You are receiving this mail because: You are watching all bug changes.
[Bug 289] Static linking has wrong libc/libpthread order
https://bugzilla.gdcproject.org/show_bug.cgi?id=289 Iain Buclaw changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #2 from Iain Buclaw --- Should be caused by the order here: https://github.com/D-Programming-GDC/GDC/blob/ad6adc7d6da4e9e490ba2e13b0069a72b8cc2f7c/libphobos/configure.ac#L93 You will have a file named libgphobos.spec installed, you can swap the libraries there. -- You are receiving this mail because: You are watching all bug changes.
[Bug 289] Static linking has wrong libc/libpthread order
https://bugzilla.gdcproject.org/show_bug.cgi?id=289 --- Comment #3 from Stefan Schuerger --- Hi Iain, Thanks for the workaround! Changing libgphobos.spec from *lib: %(liborig_gdc_renamed) -lm -lpthread -ldl to *lib: -lpthread %(liborig_gdc_renamed) -lm -ldl works! -- You are receiving this mail because: You are watching all bug changes.
[Bug 289] Static linking has wrong libc/libpthread order
https://bugzilla.gdcproject.org/show_bug.cgi?id=289
--- Comment #4 from Stefan Schuerger ---
Fun fact: When taking the "helloworld" example from the dlang.org page
(https://tour.dlang.org/):
import std.stdio;
import std.algorithm;
import std.range;
void main()
{
// Let's get going!
writeln("Hello World!");
// An example for experienced programmers:
// Take three arrays, and without allocating
// any new memory, sort across all the
// arrays inplace
int[] arr1 = [4, 9, 7];
int[] arr2 = [5, 2, 1, 10];
int[] arr3 = [6, 8, 3];
sort(chain(arr1, arr2, arr3));
writefln("%s\n%s\n%s\n", arr1, arr2, arr3);
// To learn more about this example, see the
// "Range algorithms" page under "Gems"
}
compiled as static and stripped, the ARM binary is 1.1M. When you comment out
all the code but the writeln("Hello World!"), the stripped binary grows to
1.7M...
--
You are receiving this mail because:
You are watching all bug changes.
[Bug 289] Static linking has wrong libc/libpthread order
https://bugzilla.gdcproject.org/show_bug.cgi?id=289 --- Comment #5 from Iain Buclaw --- (In reply to Stefan Schuerger from comment #3) > Hi Iain, > > Thanks for the workaround! Changing libgphobos.spec from > > *lib: %(liborig_gdc_renamed) -lm -lpthread -ldl > > to > > *lib: -lpthread %(liborig_gdc_renamed) -lm -ldl > > works! Can %(liborig_gdc_renamed) appear after the other libraries also? -- You are receiving this mail because: You are watching all bug changes.
[Bug 289] Static linking has wrong libc/libpthread order
https://bugzilla.gdcproject.org/show_bug.cgi?id=289 --- Comment #6 from Iain Buclaw --- https://github.com/D-Programming-GDC/GDC/pull/617 -- You are receiving this mail because: You are watching all bug changes.
[Bug 289] Static linking has wrong libc/libpthread order
https://bugzilla.gdcproject.org/show_bug.cgi?id=289 Iain Buclaw changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are watching all bug changes.
[Bug 290] New: ice-on-valid: Assertion `fd->semanticRun == PASSsemantic3done' failed.
https://bugzilla.gdcproject.org/show_bug.cgi?id=290
Bug ID: 290
Summary: ice-on-valid: Assertion `fd->semanticRun ==
PASSsemantic3done' failed.
Product: GDC
Version: 7.x
Hardware: All
OS: All
Status: NEW
Severity: major
Priority: Normal
Component: gdc
Assignee: ibuc...@gdcproject.org
Reporter: sebastien.alai...@gmail.com
This one spans on two modules. I couldn't reduce it more.
$ cat file_a.d
// file_a.d
import file_b;
void f()
{
import std.stdio;
writefln("Startup");
}
struct Context
{
Dim2f box;
}
$ cat file_b.d
// file_b.d
struct GDim (T)
{
T width, height;
string toString() const
{
import std.string;
return format("%sx%s", width, height);
}
}
alias GDim!float Dim2f;
$ gdc file_a.d
cc1d: ../../src/gcc/d/dfrontend/dinterpret.c:712: void
ctfeCompile(FuncDeclaration*): Assertion `fd->semanticRun == PASSsemantic3done'
failed.
/usr/lib/gcc/x86_64-linux-gnu/7/include/d/std/conv.d:114:13: internal compiler
error: Aborted
return src ? "true" : "false";
^
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
$ gdc --version
gdc (Debian 7.3.0-15) 7.3.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
--
You are receiving this mail because:
You are watching all bug changes.
[Bug 290] ice-on-valid: Assertion `fd->semanticRun == PASSsemantic3done' failed.
https://bugzilla.gdcproject.org/show_bug.cgi?id=290 Iain Buclaw changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #1 from Iain Buclaw --- Not reproducible on master, may have been a frontend bug that was backported from the 2.076-compat patches. -- You are receiving this mail because: You are watching all bug changes.
[Bug 290] ice-on-valid: Assertion `fd->semanticRun == PASSsemantic3done' failed.
https://bugzilla.gdcproject.org/show_bug.cgi?id=290 --- Comment #2 from Sebastien Alaiwan --- (In reply to Iain Buclaw from comment #1) > Not reproducible on master, may have been a frontend bug that was backported > from the 2.076-compat patches. Yeah, maybe ; please keep in mind this one is highly volatile. For example, I can prevent the problem from manifesting itself by simply deleting the declaration of the (unused) structure "Context". The error might still be present on master (but would need a slightly different test case). -- You are receiving this mail because: You are watching all bug changes.
[Bug 290] ice-on-valid: Assertion `fd->semanticRun == PASSsemantic3done' failed.
https://bugzilla.gdcproject.org/show_bug.cgi?id=290 --- Comment #3 from Iain Buclaw --- (In reply to Sebastien Alaiwan from comment #2) > (In reply to Iain Buclaw from comment #1) > > Not reproducible on master, may have been a frontend bug that was backported > > from the 2.076-compat patches. > > Yeah, maybe ; please keep in mind this one is highly volatile. > > For example, I can prevent the problem from manifesting itself by simply > deleting the declaration of the (unused) structure "Context". > > The error might still be present on master (but would need a slightly > different test case). Can this be reproduced in any version of dmd between 2.068 and 2.076? That would be one way to check, but as this is not a context-free test, it could even be that library changes made the bug go away. -- You are receiving this mail because: You are watching all bug changes.
[Bug 291] New: Compile-time AssemblerTemplate is not supported
https://bugzilla.gdcproject.org/show_bug.cgi?id=291
Bug ID: 291
Summary: Compile-time AssemblerTemplate is not supported
Product: GDC
Version: 8,x
Hardware: x86_64
OS: Linux
Status: NEW
Severity: normal
Priority: Normal
Component: gdc
Assignee: ibuc...@gdcproject.org
Reporter: aras...@protonmail.com
According to the wiki (Using_GDC), which is currently down (I am getting
"Sorry! This site is experiencing technical difficulties. ... (cannot access
the database)"), the AssemblerTemplate string for extended inline assembly may
be a compile-time string. That doesn't seem to be maintained, according to the
compilation errors from this small program:
```
module test;
enum assemblerTemplate(string instruction) = instruction;
void main(string[] args) {
asm {
assemblerTemplate!("syscall") :: "a" 1;
}
}
```
Fails with error:
```
test.d: In function 'D main':
test.d:7:43: sorry, unimplemented: D inline assembler statements are not
supported in GDC.
assemblerTemplate!("syscall") :: "a" 1;
^
```
--
You are receiving this mail because:
You are watching all bug changes.
[Bug 291] Compile-time AssemblerTemplate is not supported
https://bugzilla.gdcproject.org/show_bug.cgi?id=291
--- Comment #1 from ARaspiK ---
I opened the wiki on the Internet Archive. According to the wiki at June 29,
2017, "If the template is not a string literal, use parenthesis to indicate
that it is not an opcode."
This doesn't ACTUALLY WORK. Using `(assemblerTemplate!("syscall"))` doesn't
help whatsoever!
GDC version: `gdc (Gentoo 8.1.0 p1.2) 8.1.0`
--
You are receiving this mail because:
You are watching all bug changes.
[Bug 148] gcc inline asm instruction template must be a constant char string regression
https://bugzilla.gdcproject.org/show_bug.cgi?id=148 Iain Buclaw changed: What|Removed |Added Blocks||291 Referenced Bugs: https://bugzilla.gdcproject.org/show_bug.cgi?id=291 [Bug 291] Compile-time AssemblerTemplate is not supported -- You are receiving this mail because: You are watching all bug changes.
[Bug 291] Compile-time AssemblerTemplate is not supported
https://bugzilla.gdcproject.org/show_bug.cgi?id=291 Iain Buclaw changed: What|Removed |Added Depends on||148 Referenced Bugs: https://bugzilla.gdcproject.org/show_bug.cgi?id=148 [Bug 148] gcc inline asm instruction template must be a constant char string regression -- You are receiving this mail because: You are watching all bug changes.
[Bug 291] Compile-time AssemblerTemplate is not supported
https://bugzilla.gdcproject.org/show_bug.cgi?id=291 --- Comment #2 from Iain Buclaw --- Related to #148. I wasn't aware of the wiki documentation saying that, maybe we can add support for that effectively closing both. However at some point I have wanted to redo this so that gdc has exclusive ownership of asm statements - not a could be one syntax or the other depending on the first matched token. -- You are receiving this mail because: You are watching all bug changes.
[Bug 193] Druntime and Phobos unittests should be compiled with optimisations
https://bugzilla.gdcproject.org/show_bug.cgi?id=193 Iain Buclaw changed: What|Removed |Added Component|gdc |libgphobos -- You are receiving this mail because: You are watching all bug changes.
[Bug 292] New: Add configure flag to build minimal druntime only
https://bugzilla.gdcproject.org/show_bug.cgi?id=292 Bug ID: 292 Summary: Add configure flag to build minimal druntime only Product: GDC Version: development Hardware: All OS: All Status: NEW Severity: normal Priority: Normal Component: libgphobos Assignee: ibuc...@gdcproject.org Reporter: ibuc...@gdcproject.org Such a flag should turn off most of these components, unless explicitly requested i.e: using --with-libatomic - Building phobos - Building the garbage collector - Add dependency on libatomic - Add dependency libbacktrace - Add dependency libz -- You are receiving this mail because: You are watching all bug changes.
[Bug 293] New: Utilize assert (ptr == (ptr & -align)) to assume alignment
https://bugzilla.gdcproject.org/show_bug.cgi?id=293
Bug ID: 293
Summary: Utilize assert (ptr == (ptr & -align)) to assume
alignment
Product: GDC
Version: 8,x
Hardware: x86_64
OS: Linux
Status: NEW
Severity: normal
Priority: Normal
Component: gdc
Assignee: ibuc...@gdcproject.org
Reporter: aras...@protonmail.com
This is a feature request.
GCC provides __builtin_assume_aligned to let the programmer inform the compiler
that a pointer is aligned. Some pointer alignment code I am using is not making
sense to the compiler, and so it is not using aligned SSE movement instructions
when possible. Here is my alignment (pseudo)code (note that I have excluded
casting pointers to arithmetic types and back):
len = -dst & 0xf; // Gets amount needed to align to 16 bytes
if (len) {
if (len & 1) {
*cast(ubyte*)dst = *cast(ubyte*)src;
dst++;
src++;
assert ((dst & 1) == 0); // This should work to assume X-byte alignment
}
...
}
// This should work, and the compiler should assume it's true even when asserts
are not being compiled.
assert ((dst & 0xf) == 0); // Now aligned.
assert ((dst & -0x10) == dst); // Same thing.
// I have to do this instead:
dst &= 0xf;
struct void16 {void[16] data;} // Example SSE register optimization
*cast(void16*)dst = *cast(void16*)src; // Should use movdqa and move into dst
aligned
// Does not work via asserts.
This could be used as a global assumption optimization.
GDC arguments (note that no AVX, but SSE 4.2):
gdc -march=native -mtune=native -frelease -Ofast
Additionally, I have excluded Phobos, enabled static compilation, and disabled
PIC and moduleinfo.
--
You are receiving this mail because:
You are watching all bug changes.
[Bug 293] Utilize assert (ptr == (ptr & -align)) to assume alignment
https://bugzilla.gdcproject.org/show_bug.cgi?id=293 --- Comment #1 from ARaspiK --- General pseudocode: void* dst = ...; Possible D code for alignment assumption: assert ((dst & -0x10) == dst); assert ((dst & 0xf) == 0); Possible C code for alignment assumption: dst = __builtin_assume_aligned(dst, 16); Here is a StackOverflow (capitalization?) question on it: https://stackoverflow.com/q/9608171/9781227 -- You are receiving this mail because: You are watching all bug changes.
[Bug 294] New: Debug names of extern(C++) symbols doesn't match C++
https://bugzilla.gdcproject.org/show_bug.cgi?id=294
Bug ID: 294
Summary: Debug names of extern(C++) symbols doesn't match C++
Product: GDC
Version: development
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: Normal
Component: gdc
Assignee: ibuc...@gdcproject.org
Reporter: ibuc...@gdcproject.org
Debug names of extern(C++) - and probably extern(C) also - symbols include
module names that they are declared in, which doesn't match up to the names
generated by g++, so the debugger is not able to match up the type when
debugging from the C++ side.
---
(gdb) p base
$1 = (AggregateDeclaration *) 0x75a4cc00
(gdb) p *base
$2 =
---
Current workaround is to explicitly cast to the gdc generated type name.
---
(gdb) p ('dmd.aggregate.AggregateDeclaration'*)base
$3 = (dmd.aggregate.AggregateDeclaration *) 0x75a4cc00
(gdb) p *('dmd.aggregate.AggregateDeclaration'*)base
warning: can't find linker symbol for virtual table for
`dmd.aggregate.AggregateDeclaration' value
warning: found `initializer for dmd.dstruct.UnionDeclaration' instead
$4 = warning: can't find linker symbol for virtual table for
`dmd.aggregate.AggregateDeclaration' value
warning: found `initializer for dmd.dstruct.UnionDeclaration' instead
{ = { =
{ = {__vptr = 0x2103b38 }, ident = 0x77ea3a00, parent =
0x75a4c800, csym =
0x0, isym = 0x0, comment = 0x0, loc = {filename = 0x23aa8a0
"std/algorithm/setops.d", linnum = 27, charnum = 13}, _scope = 0x0,
prettystring = 0x23a4420
"setops.BinaryHeap!(compFront).BinaryHeap.RefCounted.Impl
", errors = false, semanticRun = dmd.dsymbol.PASS.semantic3done, depdecl = 0x0,
userAttribDecl = 0x0, ddocUnittest = 0x0}, members = 0x75a49240, symtab =
0x77ea4700, endlinnum = 0, importedScopes = 0x0,
prots = 0x0, accessiblePackages = {len = 0, ptr = 0x0},
privateAccessiblePackages = {len = 0, ptr = 0x0}}, type = 0x75a4ab00,
storage_class = 0, protection = {kind = dmd.dsymbol.Prot.Kind.public_, pkg =
0x0}
, structsize = 1, alignsize = 1, fields = {dim = 1, data = 0x75a4ccf8,
allocdim = 1, smallarray = {0x75a4b600}}, sizeok =
dmd.aggregate.Sizeok.done, deferred = 0x0, isdeprecated = false, classKind =
dmd.
aggregate.ClassKind.d, enclosing = 0x0, vthis = 0x0, invs = {dim = 0, data =
0x0, allocdim = 0, smallarray = {0x0}}, inv = 0x0, aggNew = 0x0, aggDelete =
0x0, ctor = 0x0, defaultCtor = 0x0, aliasthis = 0x0, noDe
faultCtor = false, dtors = {dim = 0, data = 0x0, allocdim = 0, smallarray =
{0x0}}, dtor = 0x0, primaryDtor = 0x0, tidtor = 0x0, getRTInfo = 0x249fa90,
stag = 0x0, sinit = 0x75725750}
---
--
You are receiving this mail because:
You are watching all bug changes.
[Bug 293] Utilize assert (ptr == (ptr & -align)) to assume alignment
https://bugzilla.gdcproject.org/show_bug.cgi?id=293 --- Comment #2 from ARaspiK --- Welp, I just discovered gcc.builtins. __builtin_assume_aligned did the trick. For anybody wondering: `import gcc.builtins` will pull in all (most?) GCC builtin functions. __builtin_assume_aligned is among them. -- You are receiving this mail because: You are watching all bug changes.
[Bug 293] Utilize assert (ptr == (ptr & -align)) to assume alignment
https://bugzilla.gdcproject.org/show_bug.cgi?id=293 Iain Buclaw changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #3 from Iain Buclaw --- Asserts that have no side effects are given as hints for the optimizer, otherwise generally having any kind of pattern matching in the that results in emitting details like "assume aligned" is really out of scope for what a front-end should do. -- You are receiving this mail because: You are watching all bug changes.
