[Issue 1] Hello World
http://gdcproject.org/bugzilla/show_bug.cgi?id=1 Iain Buclaw changed: What|Removed |Added Status|IN_PROGRESS |CONFIRMED Platform|x86 |All OS/Version|Other |All --- Comment #4 from Iain Buclaw 2012-07-10 17:02:26 UTC --- Testing sending bug emails to D.gnu mailing list. -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 2] New: Structs with toString() method not formatted properly
http://gdcproject.org/bugzilla/show_bug.cgi?id=2
Bug #: 2
Summary: Structs with toString() method not formatted properly
Classification: Unclassified
Product: GDC
Version: development
Platform: All
OS/Version: All
Status: NEW
Severity: major
Priority: Normal
Component: libgphobos
AssignedTo: ibuc...@gdcproject.org
ReportedBy: a...@lycus.org
$ cat test.d
import std.string;
struct S
{
string toString() { return "foo"; }
}
void main()
{
format("%s", S());
}
$ gdc test.d
$ ./a.out
std.format.FormatException@../../../gcc-4.8-20120701/libphobos/std/format.d(4748):
cannot portably format a struct on this target
./a.out() [0x43aa10]
./a.out() [0x4238c3]
./a.out() [0x4239b1]
./a.out() [0x402502]
./a.out() [0x405be1]
./a.out() [0x40608d]
./a.out() [0x406140]
./a.out() [0x40608d]
./a.out() [0x40666c]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed) [0x7f29b9bb430d]
./a.out() [0x402385]
This program should print "foo".
--
Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching all issue changes.
[Issue 3] New: GDC prints some diagnostic information to stderr instead of stdout
http://gdcproject.org/bugzilla/show_bug.cgi?id=3 Bug #: 3 Summary: GDC prints some diagnostic information to stderr instead of stdout Classification: Unclassified Product: GDC Version: development Platform: All OS/Version: All Status: NEW Severity: normal Priority: Normal Component: gdc AssignedTo: ibuc...@gdcproject.org ReportedBy: a...@lycus.org GDC prints diagnostic messages like importall to stderr instead of stdout (DMD behavior). This isn't normally a problem, but since rdmd invokes " -v -o- -Ipath path/script.d" and uses an stdout redirect to capture compiler output, it means that these diagnostics are shown in the user's terminal unnecessarily. The solution would probably be to just print all of these to stdout, but I don't know if this goes against some GCC convention. -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 3] GDC prints some diagnostic information to stderr instead of stdout
http://gdcproject.org/bugzilla/show_bug.cgi?id=3 Iain Buclaw changed: What|Removed |Added CC||ibuc...@gdcproject.org --- Comment #1 from Iain Buclaw 2012-07-15 10:13:00 UTC --- We could do, but it does not work with -pipe, which feeds everything sent to stdout straight to the assembler - think: `gcc -o - | as -o foo.o` For convenience, could simply error that options like -fd-verbose and -fvtls cannot work with -pipe. -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 2] Structs with toString() method not formatted properly
http://gdcproject.org/bugzilla/show_bug.cgi?id=2 --- Comment #1 from Iain Buclaw 2012-07-16 10:14:08 UTC --- Documentation on known differences should be updated. DMD on 64bit has a runtime library implementation that retrieves the next variadic argument based on it's TypeInfo and it's tsize(). eg: auto va = va_arg(ap, ti); GDC uses it's GCC's built-in VA_ARG_EXPR, which depends on the type being known at compile time in order to work. eg: auto va = va_arg!(Foo)(ap); There is no way around this other than implementing a new runtime function which does a similar job that DMD's implementation does, but have it specific for the way GDC passes variadic arguments to the callee. -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 4] New: reverse allowed on string (gdc 4.6.3 !)
http://gdcproject.org/bugzilla/show_bug.cgi?id=4
Bug #: 4
Summary: reverse allowed on string (gdc 4.6.3 !)
Classification: Unclassified
Product: GDC
Version: development
Platform: x86
OS/Version: Linux
Status: NEW
Severity: normal
Priority: Normal
Component: gdc
AssignedTo: ibuc...@gdcproject.org
ReportedBy: kwez...@hotmail.com
(Note that I don't have access to 4.7.x or 4.8.x on Ubuntu, this might not
apply anymore ! sorry if it is the case)
gdc (Ubuntu/Linaro 4.6.3-1ubuntu1) 4.6.3
DMD32 D Compiler v2.059
GDC allows this:
(it will crash on execution)
void main() {
string str = "allo";
str.reverse;
str.sort;
}
But dmd will catch the error at compile time:
dmd testStringReverse.d
testStringReverse.d(4): Error: can only reverse a mutable array
testStringReverse.d(5): Error: can only sort a mutable array
--
Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching all issue changes.
[Issue 1] Hello World
http://gdcproject.org/bugzilla/show_bug.cgi?id=1 Alex Rønne Petersen changed: What|Removed |Added Status|NEW |RESOLVED CC||a...@lycus.org Resolution||WORKSFORME --- Comment #5 from Alex Rønne Petersen 2012-08-13 10:25:32 UTC --- Works for me. ;) -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 5] New: std.file: struct_stat64 wrong for ARM
http://gdcproject.org/bugzilla/show_bug.cgi?id=5 Bug #: 5 Summary: std.file: struct_stat64 wrong for ARM Classification: Unclassified Product: GDC Version: development Platform: ARM OS/Version: Linux Status: NEW Severity: trivial Priority: Normal Component: libgphobos AssignedTo: ibuc...@gdcproject.org ReportedBy: johannesp...@gmail.com The struct_stat64 declaration forces align(4) on st_size. This is wrong for ARM, I wonder if it's actually correct for x86? Should be trivial to fix, but std.file probably should define this struct at all. It should use core.sys.posix.sys.stat instead, which currently does not have a struct_stat64 definition. Filed here, so it won't be forgotten. -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 5] std.file: struct_stat64 wrong for ARM
http://gdcproject.org/bugzilla/show_bug.cgi?id=5 Johannes Pfau changed: What|Removed |Added Status|NEW |ASSIGNED CC||johannesp...@gmail.com AssignedTo|ibuc...@gdcproject.org |johannesp...@gmail.com -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 5] std.file: struct_stat64 wrong for ARM
http://gdcproject.org/bugzilla/show_bug.cgi?id=5 Iain Buclaw changed: What|Removed |Added CC||ibuc...@gdcproject.org --- Comment #1 from Iain Buclaw 2012-09-24 15:51:38 UTC --- This should first be fixed in phobos - which should not be defining it's own version of struct statfs at all. It should instead use the druntime version. There is an open ticket somewhere in D.bugs - flag it again and raise a pull request to remove it entirely, and update any parts that may break as a result. -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 6] New: ARM: Illegal instruction in runnable/aliasthis.d and with -O2
http://gdcproject.org/bugzilla/show_bug.cgi?id=6 Bug #: 6 Summary: ARM: Illegal instruction in runnable/aliasthis.d and with -O2 Classification: Unclassified Product: GDC Version: development Platform: ARM OS/Version: Linux Status: NEW Severity: normal Priority: Normal Component: gdc AssignedTo: ibuc...@gdcproject.org ReportedBy: johannesp...@gmail.com Created attachment 1 --> http://gdcproject.org/bugzilla/attachment.cgi?id=1 Reduced test case The test suite fails on runnable/aliasthis.d on ARM with an "Illegal instruction" message. This does not happen on x86/x86-64. Probably triggered by libgcc (unwinder) and a cross platform bug? A reduced test case, the gdb backtrace and gdc -v is attached. -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 6] ARM: Illegal instruction in runnable/aliasthis.d and with -O2
http://gdcproject.org/bugzilla/show_bug.cgi?id=6 --- Comment #1 from Johannes Pfau 2012-09-24 16:24:50 UTC --- Created attachment 2 --> http://gdcproject.org/bugzilla/attachment.cgi?id=2 gdb backtrace -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 6] ARM: Illegal instruction in runnable/aliasthis.d and with -O2
http://gdcproject.org/bugzilla/show_bug.cgi?id=6 --- Comment #2 from Johannes Pfau 2012-09-24 16:25:18 UTC --- Created attachment 3 --> http://gdcproject.org/bugzilla/attachment.cgi?id=3 gdc -v ouput / system info -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 6] ARM: Illegal instruction in runnable/aliasthis.d and with -O2
http://gdcproject.org/bugzilla/show_bug.cgi?id=6 Johannes Pfau changed: What|Removed |Added Attachment #3 mime|application/octet-stream|text/plain type|| -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 6] ARM: Illegal instruction in runnable/aliasthis.d and with -O2
http://gdcproject.org/bugzilla/show_bug.cgi?id=6 --- Comment #3 from Johannes Pfau 2012-09-24 16:36:47 UTC --- Actually seems to happen for any assert or thrown Exception. I remember Exceptions where working some time ago, so this is probably an error in my gdc / gcc configuration. -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 6] ARM: Illegal instruction in runnable/aliasthis.d and with -O2
http://gdcproject.org/bugzilla/show_bug.cgi?id=6 --- Comment #4 from Iain Buclaw 2012-09-24 18:22:52 UTC --- As this occurs in a libgcc .S file, yes it does seem like a configuration problem let's have a look and see what causes that illegal instruction to be ran... -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 6] ARM: Illegal instruction in runnable/aliasthis.d and with -O2
http://gdcproject.org/bugzilla/show_bug.cgi?id=6 --- Comment #5 from Iain Buclaw 2012-09-24 18:28:50 UTC --- That particular assembly code is intended for !__ARM_ARCH_6M__ systems. -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 6] ARM: Illegal instruction in runnable/aliasthis.d and with -O2
http://gdcproject.org/bugzilla/show_bug.cgi?id=6 --- Comment #6 from Iain Buclaw 2012-09-24 18:34:46 UTC --- Having a look at gcc-4.8/gcc/config/arm/arm-arches.def Perhaps you need to reconfigure with --with-arch=armv6-m or armv6s-m for soft float. Regards Iain. -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 6] ARM: Illegal instruction in runnable/aliasthis.d and with -O2
http://gdcproject.org/bugzilla/show_bug.cgi?id=6 --- Comment #7 from Iain Buclaw 2012-09-24 18:36:22 UTC --- (In reply to comment #6) > Having a look at gcc-4.8/gcc/config/arm/arm-arches.def > > Perhaps you need to reconfigure with --with-arch=armv6-m or armv6s-m for soft > float. > At least, I assume the 's' bit means soft. ;) -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 6] ARM: Illegal instruction in runnable/aliasthis.d and with -O2
http://gdcproject.org/bugzilla/show_bug.cgi?id=6 --- Comment #8 from Johannes Pfau 2012-09-24 18:55:19 UTC --- No, I think it's a gdc bug. I think something recently broke the ARM EABI unwinder. The gcc executable from the same build as the gdc executable works. And the version (GNU_ARM_EABI_Unwinder) is not set, although it is detected by configure and DCFG_ARM_EABI_UNWINDER is set to "GNU_ARM_EABI_Unwinder". Seems the reason is this commit: https://github.com/D-Programming-GDC/gdc/commit/ffed7d684e94d2b933a7d2f27403d8fb7de65314 DCFG_ARM_EABI_UNWINDER=GNU_ARM_EABI_Unwinder ends up in the toplevel phobos-ver-syms file, but not in libdruntime/phobos-ver-syms. Seems the libdruntime/phobos-ver-syms.in file wasn't updated in https://github.com/D-Programming-GDC/gdc/commit/ffed7d684e94d2b933a7d2f27403d8fb7de65314 I'm not sure if using the wrong unwinder can have such an effect. But I looked at the exception handling code in libgcc and there's no reason why it would work for c++ but not form gdc, unless we corrupt the context in the personality routine. -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 6] ARM: Illegal instruction in runnable/aliasthis.d and with -O2
http://gdcproject.org/bugzilla/show_bug.cgi?id=6 Johannes Pfau changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #9 from Johannes Pfau 2012-09-24 19:43:17 UTC --- yep, that was the problem. Fix: https://github.com/D-Programming-GDC/gdc/pull/31 -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 7] New: ARM: runnable/aliasthis.d fails with -O2
http://gdcproject.org/bugzilla/show_bug.cgi?id=7 Bug #: 7 Summary: ARM: runnable/aliasthis.d fails with -O2 Classification: Unclassified Product: GDC Version: development Platform: ARM OS/Version: Linux Status: NEW Severity: normal Priority: Normal Component: gdc AssignedTo: ibuc...@gdcproject.org ReportedBy: johannesp...@gmail.com Created attachment 4 --> http://gdcproject.org/bugzilla/attachment.cgi?id=4 reduced test case There's a failing assert in the testsuite in runnable/aliasthis.d if compiling with -O2. This does not happen when compiling with -O1. It also does't happen on x86/x86-64. Output: core.exception.AssertError@aliasthis.d(25): Assertion failure _Dmain at crtstuff.c:0 _D2rt6dmain24mainUiPPaZi7runMainMFZv at /home/pi/objdir/arm-linux-gnueabihf/libphobos/libdruntime/../../../../gcc-4.8-20120826/libphobos/libdruntime/rt/dmain2.d:569 _D2rt6dmain24mainUiPPaZi7tryExecMFMDFZvZv at /home/pi/objdir/arm-linux-gnueabihf/libphobos/libdruntime/../../../../gcc-4.8-20120826/libphobos/libdruntime/rt/dmain2.d:556 _D2rt6dmain24mainUiPPaZi6runAllMFZv at /home/pi/objdir/arm-linux-gnueabihf/libphobos/libdruntime/../../../../gcc-4.8-20120826/libphobos/libdruntime/rt/dmain2.d:579 _D2rt6dmain24mainUiPPaZi7tryExecMFMDFZvZv at /home/pi/objdir/arm-linux-gnueabihf/libphobos/libdruntime/../../../../gcc-4.8-20120826/libphobos/libdruntime/rt/dmain2.d:556 main at /home/pi/objdir/arm-linux-gnueabihf/libphobos/libdruntime/../../../../gcc-4.8-20120826/libphobos/libdruntime/rt/dmain2.d:592 onAssertError at /home/pi/objdir/arm-linux-gnueabihf/libphobos/libdruntime/../../../../gcc-4.8-20120826/libphobos/libdruntime/core/exception.d:404 -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 7] ARM: runnable/aliasthis.d fails with -O2
http://gdcproject.org/bugzilla/show_bug.cgi?id=7 --- Comment #1 from Johannes Pfau 2012-09-25 09:07:37 UTC --- Created attachment 5 --> http://gdcproject.org/bugzilla/attachment.cgi?id=5 system / compier information -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 8] New: ARM: runnable/arrayop.d fails: Wrong execution order
http://gdcproject.org/bugzilla/show_bug.cgi?id=8 Bug #: 8 Summary: ARM: runnable/arrayop.d fails: Wrong execution order Classification: Unclassified Product: GDC Version: development Platform: ARM OS/Version: Linux Status: NEW Severity: normal Priority: Normal Component: gdc AssignedTo: ibuc...@gdcproject.org ReportedBy: johannesp...@gmail.com Created attachment 6 --> http://gdcproject.org/bugzilla/attachment.cgi?id=6 reduced test case Test case attached. Reduced from runnable/arrayop.d Compile & run: gdc arrayop.d -o arrayop.exe ./arrayop.exe -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 8] ARM: runnable/arrayop.d fails: Wrong execution order
http://gdcproject.org/bugzilla/show_bug.cgi?id=8 --- Comment #1 from Johannes Pfau 2012-09-25 09:24:52 UTC --- Created attachment 7 --> http://gdcproject.org/bugzilla/attachment.cgi?id=7 system / compier information -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 9] New: ARM: runnable/builtin.d floating point equality fails
http://gdcproject.org/bugzilla/show_bug.cgi?id=9 Bug #: 9 Summary: ARM: runnable/builtin.d floating point equality fails Classification: Unclassified Product: GDC Version: development Platform: ARM OS/Version: Linux Status: NEW Severity: trivial Priority: Normal Component: gdc AssignedTo: ibuc...@gdcproject.org ReportedBy: johannesp...@gmail.com I guess the exact value doesn't matter here, so we could just compare the result and allow a certain delta? What would be a useful delta here? static assert(sin(6.8) == 0x1.f9f8d9aea10fdf1cp-2); runnable/builtin.d:15: Error: static assert (4.94113351138608159e-1L == 4.94113351138608325e-1L) is false -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 10] New: ARM: runnable/opover2.d fails: xopEquals fallback aborts instead of throwing Exception
http://gdcproject.org/bugzilla/show_bug.cgi?id=10
Bug #: 10
Summary: ARM: runnable/opover2.d fails: xopEquals fallback
aborts instead of throwing Exception
Classification: Unclassified
Product: GDC
Version: development
Platform: ARM
OS/Version: Linux
Status: NEW
Severity: normal
Priority: Normal
Component: gdc
AssignedTo: ibuc...@gdcproject.org
ReportedBy: johannesp...@gmail.com
Reduced example:
--
void main()
{
// xopEquals NG
struct S2a
{
bool opEquals(S2a rhs) //Add const here and everything OK
{return false; }
}
S2a s;
//Should throw exception, instead aborts
typeid(S2a).equals(&s, &s);
}
---
Compile:
gdc opover2.d -o opover2.exe
./opover2.exe
Aborted
Incomplete gdb backtrace:
---
Program received signal SIGABRT, Aborted.
0x40106bfc in raise () from /lib/arm-linux-gnueabihf/libc.so.6
(gdb) bt
#0 0x40106bfc in raise () from /lib/arm-linux-gnueabihf/libc.so.6
#1 0x4010a97c in abort () from /lib/arm-linux-gnueabihf/libc.so.6
#2 0x8bd8 in ?? ()
#3 0x8bd8 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
---
I started looking into this issue, this is what I found:
The TypeInfoStruct.equals function is set in TypeInfoStructDeclaration::toDt
(typinf.c):
---
if (sd->xeq)
dtxoff(pdt, sd->xeq->toSymbol(), 0, TYnptr);
else
dtsize_t(pdt, 0);
---
xeq is built in clone.c, StructDeclaration::buildXopEquals.
* If no opEquals function is defined, it return NULL. This is working.
* If an opEquals function was found, it tries to produce code to call this
function. If this succeeds, everything is working. If this fails, for example
because opEquals isn't const, it returns the object._xopEquals function. This
is what happens in this test case and isn't working.
object._xopEquals is defined in druntime:
bool _xopEquals(in void*, in void*)
{
throw new Error("TypeInfo.equals is not implemented");
}
calling it directly is working:
object._xopEquals(null, null); //Throws as expected.
I'm not sure if this is the root cause, but this is fishy: (TypeInfo_Struct)
override equals_t equals(in void* p1, in void* p2) @trusted pure nothrow const
but:
bool _xopEquals(in void*, in void*)
Could be another issue of the recent commit, fixing pure/nothrow attributes on
functions with asserts:
d-decls.cc(FuncDeclaration::toSymbol): Don't set any pure/nothrow attributes if
asserts are generated in code.
This can't detect the thrown Error in this case, as it's thown via a function
pointer.
--
Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching all issue changes.
[Issue 10] ARM: runnable/opover2.d fails: xopEquals fallback aborts instead of throwing Exception
http://gdcproject.org/bugzilla/show_bug.cgi?id=10 --- Comment #1 from Johannes Pfau 2012-09-25 10:47:18 UTC --- OK, this was indeed the cause. Removing pure nothrow from "equals_t equals" and "equals_t function(in void*, in void*) xopEquals;" fixes this issue. We could hack this in druntime, but I think we need a more general solution. Imho we shouldn't mark functions as nothrow in the backend if the complete source code is not available: So: invoking a function via pointer / delegate => not nothrow. Invoking a nothrow function where we only have a definition in a .di header => not nothrow. And if a function invokes other nothrow functions these have to be checked for assertion / throw Error as well. The same may apply to pure. Maybe there's a better solution, but it seems that the dmd schizophrenia "throwing Errors in nothrow functions is OK" get's us into trouble here, as GCC probably doesn't set up exception handling for NOTHROW functions at all. -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 11] New: ARM: runnable/test11.d Unsupported platform
http://gdcproject.org/bugzilla/show_bug.cgi?id=11 Bug #: 11 Summary: ARM: runnable/test11.d Unsupported platform Classification: Unclassified Product: GDC Version: development Platform: ARM OS/Version: Linux Status: NEW Severity: trivial Priority: Normal Component: gdc AssignedTo: ibuc...@gdcproject.org ReportedBy: johannesp...@gmail.com This test is currently failing: byte* p; version(X86) assert(p.sizeof == 4); else version(X86_64) assert(p.sizeof == 8); else assert(false, "unknown platform"); we could of course just add a else version(ARM) assert(p.sizeof == 4); but I wonder whether this should use D_LP64 instead? With armv8/AArch64 arm will support 64bit pointers. The question then is whether we introduce a new version for 64 bit version(ARM64), or whether version(ARM) could be 32 or 64 bit and we should additionally use version(D_LP64)? -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 11] ARM: runnable/test11.d Unsupported platform
http://gdcproject.org/bugzilla/show_bug.cgi?id=11 Johannes Pfau changed: What|Removed |Added CC||johannesp...@gmail.com AssignedTo|ibuc...@gdcproject.org |johannesp...@gmail.com -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 12] New: ARM: runnable/test12.d Unsupported platform
http://gdcproject.org/bugzilla/show_bug.cgi?id=12
Bug #: 12
Summary: ARM: runnable/test12.d Unsupported platform
Classification: Unclassified
Product: GDC
Version: development
Platform: ARM
OS/Version: Linux
Status: NEW
Severity: trivial
Priority: Normal
Component: gdc
AssignedTo: ibuc...@gdcproject.org
ReportedBy: johannesp...@gmail.com
These tests are currently failing:
version(X86)
assert(a.classinfo.init.length == 28);
else version(X86_64)
assert(a.classinfo.init.length == 36);
else
assert(0);
version(X86)
{
assert(Qwert32.yuiop.offsetof == 8);
assert(Qwert32.asdfg.offsetof == 12);
}
else version (X86_64)
{
assert(Qwert32.yuiop.offsetof == 16);
assert(Qwert32.asdfg.offsetof == 20);
}
else
assert(0);
we could of course just add
else version(ARM)
assert(a.classinfo.init.length == 28);
and
else version (ARM)
{
assert(Qwert32.yuiop.offsetof == 8);
assert(Qwert32.asdfg.offsetof == 12);
}
but I wonder whether this should use D_LP64 instead?
--
Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching all issue changes.
[Issue 12] ARM: runnable/test12.d Unsupported platform
http://gdcproject.org/bugzilla/show_bug.cgi?id=12 Johannes Pfau changed: What|Removed |Added AssignedTo|ibuc...@gdcproject.org |johannesp...@gmail.com -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 13] New: ARM: can't cast _argptr / va_list to pointer
http://gdcproject.org/bugzilla/show_bug.cgi?id=13
Bug #: 13
Summary: ARM: can't cast _argptr / va_list to pointer
Classification: Unclassified
Product: GDC
Version: development
Platform: ARM
OS/Version: Linux
Status: NEW
Severity: normal
Priority: Normal
Component: gdc
AssignedTo: ibuc...@gdcproject.org
ReportedBy: johannesp...@gmail.com
import core.vararg;
void foo31(...)
{
byte b = *cast(byte*)_argptr;
assert(b == 8);
}
void main()
{
byte b = 8;
foo31(b);
}
test20.d: In function ‘foo31’:
test20.d:5: error: cannot convert to a pointer type
The test suite test cases runnable/test20.d and runnable/testdstress.d fail
because of this. Should I document this as a difference between x86 and ARM and
fix that test suite code to only run on x86? I guess this isn't portable code
anyway?
Or should we somehow fix that in the compiler / druntime? AFAIK va_list is a
structure on ARM, but it contains a void* which would probably work just like
the va_list on x86?
--
Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching all issue changes.
[Issue 14] New: ARM: runnable/testmath.d Arm not precise enough?
http://gdcproject.org/bugzilla/show_bug.cgi?id=14 Bug #: 14 Summary: ARM: runnable/testmath.d Arm not precise enough? Classification: Unclassified Product: GDC Version: development Platform: ARM OS/Version: Linux Status: NEW Severity: trivial Priority: Normal Component: gdc AssignedTo: ibuc...@gdcproject.org ReportedBy: johannesp...@gmail.com equals: x = 0.523599 equals: y = 0.523599 equals: ndigits = 16 bufx = '0.5235987755982989' bufy = '0.5235987755982988' core.exception.AssertError@runnable/testmath.d(134): Assertion failure Seems the floating point calculations (or fp to string conversion) on ARM (or at least on the Raspberry Pi) are not precise enough to pass the tests in testmath.d. What should be done about this? 1. Lower required precision for all platforms 2. Special case ARM to lower precision 3. ? -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 14] ARM: runnable/testmath.d Arm not precise enough?
http://gdcproject.org/bugzilla/show_bug.cgi?id=14 --- Comment #1 from Johannes Pfau 2012-09-25 12:13:08 UTC --- What is this test supposed to do? int exp; real mantissa = frexp(123.456, exp); assert(equals(mantissa * pow(2.0L, cast(real)exp), 123.456, 19)); equals: x = 67.456 equals: y = 123.456 equals: ndigits = 19 bufx = '67.456000307' bufy = '123.45600031' core.exception.AssertError@testmath.d(170): Assertion failure -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 11] ARM: runnable/test11.d Unsupported platform
http://gdcproject.org/bugzilla/show_bug.cgi?id=11 Iain Buclaw changed: What|Removed |Added CC||ibuc...@gdcproject.org --- Comment #1 from Iain Buclaw 2012-09-25 16:35:55 UTC --- Yep, it should be D_LP64. Raise it upstream. Alexrp should agree with me. :^) -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 12] ARM: runnable/test12.d Unsupported platform
http://gdcproject.org/bugzilla/show_bug.cgi?id=12 Iain Buclaw changed: What|Removed |Added CC||ibuc...@gdcproject.org --- Comment #1 from Iain Buclaw 2012-09-25 16:38:19 UTC --- This is again a problem solved by using D_LP64. :^) -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 14] ARM: runnable/testmath.d Arm not precise enough?
http://gdcproject.org/bugzilla/show_bug.cgi?id=14 --- Comment #2 from Iain Buclaw 2012-09-25 16:53:49 UTC --- An alternate option could be to rethink the codegen for floating comparisons in GDC overall, as certain floating point comparisons fail in GDC x86/x86_64 too. Problem: Simply doing (A == B) is not correct. Possible solution: The comparison with an epsilon value is what most tends to be done in game programming. However the following: (diff = A - B, (diff < EPSILON) && (-diff > EPSILON))) Is a bit of wasted processing for something that should be fast, yet effective. Here's an interesting read-up: http://realtimecollisiondetection.net/blog/?p=89 Regards Iain -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 12] ARM: runnable/test12.d Unsupported platform
http://gdcproject.org/bugzilla/show_bug.cgi?id=12 --- Comment #2 from Iain Buclaw 2012-09-25 19:49:32 UTC --- https://github.com/D-Programming-Language/dmd/pull/1143/files -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 11] ARM: runnable/test11.d Unsupported platform
http://gdcproject.org/bugzilla/show_bug.cgi?id=11 --- Comment #2 from Iain Buclaw 2012-09-25 19:49:49 UTC --- https://github.com/D-Programming-Language/dmd/pull/1143/files -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 10] ARM: runnable/opover2.d fails: xopEquals fallback aborts instead of throwing Exception
http://gdcproject.org/bugzilla/show_bug.cgi?id=10 --- Comment #2 from Iain Buclaw 2012-09-25 20:22:03 UTC --- Although I would have thought it to have the same behaviour, I can't seem to reproduce it on x86/x86_64. -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 13] ARM: can't cast _argptr / va_list to pointer
http://gdcproject.org/bugzilla/show_bug.cgi?id=13
--- Comment #1 from Iain Buclaw 2012-09-25 20:31:59
UTC ---
ARM va_list type is void*
ARM EABI va_list type is {void*}
As such, you need to be a little more creative about getting it's value the
x86-way.
byte *p = *cast(byte**)&argptr;
byte b = *p;
Works for both the old and embedded ABI's.
--
Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching all issue changes.
[Issue 10] ARM: runnable/opover2.d fails: xopEquals fallback aborts instead of throwing Exception
http://gdcproject.org/bugzilla/show_bug.cgi?id=10 Andrej changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #3 from Andrej 2012-09-25 20:47:25 UTC --- Can someone please explain to me why the gdc bugzilla keeps emailing me all of a sudden? I have all email notifications disabled and I'm not on any CC list. -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 8] ARM: runnable/arrayop.d fails: Wrong execution order
http://gdcproject.org/bugzilla/show_bug.cgi?id=8 --- Comment #2 from Iain Buclaw 2012-09-25 20:48:27 UTC --- You may think so, but this is actually not a bug, just a little known example of an x86-specific quirk. In D functions (thus, extern D) - everything should be evaluated left to right (LTR). And I am pretty confident for most cases, GDC gets this correct in the codegen despite pulling an arm or two in the process to get it done. For extern C functions you are left up to the order of which the underlying architecture pushes arguments on the stack. As it just so happens, x86/x86_64 is right to left (RTL), aka PUSH_ARGS_REVERSED. So expecting BCA makes sense as: A()[] = B()[] + C()[]; Gets turned into: _arraySliceSliceAddSliceAssign_f(A[], C[], B[]); Hence why it asserts that the result is "BCA". However, ARM pushes arguments on the stack LTR, so we should instead expect the result of the array operation to be "ACB" -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 10] ARM: runnable/opover2.d fails: xopEquals fallback aborts instead of throwing Exception
http://gdcproject.org/bugzilla/show_bug.cgi?id=10 --- Comment #4 from Iain Buclaw 2012-09-25 21:06:03 UTC --- I guess it's because it's attached to the D.gnu ML, has always been that way... D's bugzilla is attached to D.gnu too (for those few bugs still assigned to GDC). -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 10] ARM: runnable/opover2.d fails: xopEquals fallback aborts instead of throwing Exception
http://gdcproject.org/bugzilla/show_bug.cgi?id=10 --- Comment #5 from Andrej 2012-09-25 21:14:59 UTC --- (In reply to comment #4) > I guess it's because it's attached to the D.gnu ML, has always been that > way... > D's bugzilla is attached to D.gnu too (for those few bugs still assigned to > GDC). Oh wait, I'm sorry, I thought it was mailing me directly. Sorry for the noise. :) -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 8] ARM: runnable/arrayop.d fails: Wrong execution order
http://gdcproject.org/bugzilla/show_bug.cgi?id=8 Alex Rønne Petersen changed: What|Removed |Added CC||a...@lycus.org --- Comment #3 from Alex Rønne Petersen 2012-09-26 08:03:04 UTC --- Just leaving some IRC logs here to record my opinion on the matter: 20:52:37 < Zor> ibuclaw: in my opinion, the language should make strong guarantees about this stuff that compilers must follow, regardless of arch quirks 20:53:05 < ibuclaw> extern(D) makes strong guarantees. 20:53:28 < ibuclaw> extern(C) doesn't, which is why the testcase is fairly bogus. 20:55:44 < Zor> ibuclaw: I don't see why the compiler can't make the same guarantees about extern (C) functions too 20:56:48 < Zor> ibuclaw: the compiler would have to do some extra work to ensure LTR evaluation order, but that shouldn't be impossible 20:58:08 < Zor> ibuclaw: I especially think it's worth looking into because there's nothing even mentioning C linkage/ABI in this piece of D code, which makes the gotcha even more ridiculous 20:58:57 < ibuclaw> Zor, the problem is there would be code out there that relies on the already existing behaviour, sadly enough. 20:59:28 < Zor> yes, but there's no point in caring about that 20:59:41 < Zor> TDPL says left-to-right, always 20:59:53 < Zor> it'll break code, but we need to clean up the mess sooner rather than later 21:00:51 < ibuclaw> Zor, does it explicitly say 'all functions, even extern(C)' ? :^) 21:01:34 < Zor> All arguments are evaluated left to right 21:01:34 < Zor> before fun gets invoked. 21:01:50 < Zor> that's in the description of the function call operator 21:01:59 < Zor> so it's regardless of linkage, I'd say 21:02:28 < Zor> besides, I think code relying on RTL evaluation will be very rare 21:02:34 < Zor> LTR is what people intuitively expect -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 11] ARM: runnable/test11.d Unsupported platform
http://gdcproject.org/bugzilla/show_bug.cgi?id=11 Johannes Pfau changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Johannes Pfau 2012-09-26 08:32:30 UTC --- Fixed upstream in dmd 2.061 https://github.com/D-Programming-Language/dmd/commit/375855698cd4de3c74f9840941daf37b9ae36dcf -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 12] ARM: runnable/test12.d Unsupported platform
http://gdcproject.org/bugzilla/show_bug.cgi?id=12 Johannes Pfau changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Johannes Pfau 2012-09-26 08:32:34 UTC --- Fixed upstream in dmd 2.061 https://github.com/D-Programming-Language/dmd/commit/375855698cd4de3c74f9840941daf37b9ae36dcf -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 2] Structs with toString() method not formatted properly
http://gdcproject.org/bugzilla/show_bug.cgi?id=2 Johannes Pfau changed: What|Removed |Added CC||johannesp...@gmail.com --- Comment #3 from Johannes Pfau 2012-09-26 09:01:43 UTC --- Can we close this bug report? -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 10] ARM: runnable/opover2.d fails: xopEquals fallback aborts instead of throwing Exception
http://gdcproject.org/bugzilla/show_bug.cgi?id=10 --- Comment #6 from Johannes Pfau 2012-09-26 09:20:06 UTC --- @Iain: I forgot to explicitly state that, but the test case does indeed not fail on x86/x86-64, it only fails on ARM. It probably depends on the unwinder and/or exception ABI. -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 13] ARM: can't cast _argptr / va_list to pointer
http://gdcproject.org/bugzilla/show_bug.cgi?id=13 --- Comment #2 from Johannes Pfau 2012-09-26 09:26:55 UTC --- So D doesn't make any guarantees that casting va_list to a pointer is portable, right? But what does that mean for the test suite? Change it to use the portable va_arg or is that test meant to be platform specific and we should add a version(ARM) block to test the ARM behaviour? https://github.com/D-Programming-GDC/GDC/blob/master/gcc/testsuite/gdc.test/runnable/test20.d#L595 https://github.com/D-Programming-GDC/GDC/blob/master/gcc/testsuite/gdc.test/runnable/testdstress.d#L209 -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 2] Structs with toString() method not formatted properly
http://gdcproject.org/bugzilla/show_bug.cgi?id=2 Iain Buclaw changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Iain Buclaw 2012-09-26 11:26:25 UTC --- If your happy. Closed. -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 13] ARM: can't cast _argptr / va_list to pointer
http://gdcproject.org/bugzilla/show_bug.cgi?id=13 --- Comment #3 from Iain Buclaw 2012-09-26 13:34:12 UTC --- (In reply to comment #2) > So D doesn't make any guarantees that casting va_list to a pointer is > portable, > right? > > But what does that mean for the test suite? Change it to use the portable > va_arg or is that test meant to be platform specific and we should add a > version(ARM) block to test the ARM behaviour? > > https://github.com/D-Programming-GDC/GDC/blob/master/gcc/testsuite/gdc.test/runnable/test20.d#L595 > https://github.com/D-Programming-GDC/GDC/blob/master/gcc/testsuite/gdc.test/runnable/testdstress.d#L209 Both look fishy... how it is passing for 64bit, I do not know. -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 14] ARM: runnable/testmath.d Arm not precise enough?
http://gdcproject.org/bugzilla/show_bug.cgi?id=14 Johannes Pfau changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|ibuc...@gdcproject.org |johannesp...@gmail.com --- Comment #3 from Johannes Pfau 2012-09-27 17:35:31 UTC --- Not sure if we should do anything about this in the compiler. I wonder what dmd does? Anyway: https://github.com/D-Programming-Language/dmd/pull/1146 http://forum.dlang.org/thread/k3v614$2882$1...@digitalmars.com hopefully fixed soon in upstream -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 8] ARM: runnable/arrayop.d fails: Wrong execution order
http://gdcproject.org/bugzilla/show_bug.cgi?id=8 --- Comment #4 from Johannes Pfau 2012-09-27 17:36:57 UTC --- For reference: Related discussion in D newsgroup: http://forum.dlang.org/thread/bniaxycuguviwfdto...@forum.dlang.org -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 14] ARM: runnable/testmath.d Arm not precise enough?
http://gdcproject.org/bugzilla/show_bug.cgi?id=14 Iain Buclaw changed: What|Removed |Added CC||ibuc...@gdcproject.org --- Comment #4 from Iain Buclaw 2012-09-27 17:38:07 UTC --- Cool beans. By the way, if there's anything you need downstreaming to gdc, just send it my way. Thanks. -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 9] ARM: runnable/builtin.d floating point equality fails
http://gdcproject.org/bugzilla/show_bug.cgi?id=9 Johannes Pfau changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|ibuc...@gdcproject.org |johannesp...@gmail.com --- Comment #1 from Johannes Pfau 2012-09-27 17:50:39 UTC --- https://github.com/D-Programming-Language/dmd/pull/1148 -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 13] ARM: can't cast _argptr / va_list to pointer
http://gdcproject.org/bugzilla/show_bug.cgi?id=13 Johannes Pfau changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|ibuc...@gdcproject.org |johannesp...@gmail.com --- Comment #4 from Johannes Pfau 2012-09-27 18:02:33 UTC --- https://github.com/D-Programming-Language/dmd/pull/1149 -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 5] std.file: struct_stat64 wrong for ARM
http://gdcproject.org/bugzilla/show_bug.cgi?id=5 --- Comment #2 from Johannes Pfau 2012-09-28 18:04:47 UTC --- https://github.com/D-Programming-Language/phobos/pull/819 Got rid off all the old *64 functions. (struct_stat64 is actually deprecated). I still have to check whether druntime's stat_t is correct though. -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 14] ARM: runnable/testmath.d Arm not precise enough?
http://gdcproject.org/bugzilla/show_bug.cgi?id=14 Johannes Pfau changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Johannes Pfau 2012-10-01 15:12:20 UTC --- @Iain sure, I'll do that. But most of those fixes are just errors in the test suite, not really errors in the library/compiler, so that stuff can wait till the 2.061 merge. testmath.d has been removed from the test suite in upstream dmd (2.061), so I'm closing this. I hope Don won't forget the fix for frexp though. https://github.com/D-Programming-Language/dmd/commit/77ad29c6b38897881e849d6f80165921febe1293 -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 1] Hello World
http://gdcproject.org/bugzilla/show_bug.cgi?id=1 --- Comment #7 from Iain Buclaw 2012-10-17 21:34:14 UTC --- Test -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 15] internal compiler error: in expand_expr_real_1, at expr.c:9266
http://gdcproject.org/bugzilla/show_bug.cgi?id=15 --- Comment #2 from Iain Buclaw 2012-10-17 15:31:50 UTC --- . -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 1] Hello World
http://gdcproject.org/bugzilla/show_bug.cgi?id=1 Iain Buclaw changed: What|Removed |Added CC|a...@lycus.org | --- Comment #6 from Iain Buclaw 2012-10-17 15:36:02 UTC --- Test -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 15] New: internal compiler error: in expand_expr_real_1, at expr.c:9266
http://gdcproject.org/bugzilla/show_bug.cgi?id=15
Bug #: 15
Summary: internal compiler error: in expand_expr_real_1, at
expr.c:9266
Classification: Unclassified
Product: GDC
Version: 4.8.x
Platform: x86_64
OS/Version: Linux
Status: NEW
Severity: normal
Priority: Normal
Component: gdc
AssignedTo: ibuc...@gdcproject.org
ReportedBy: deadal...@gmail.com
Code below trigger an ICE.
It is likely that dmd suffer from the same bug but don't detect it in the
backend.
import std.algorithm;
class A {
}
class B {
A a;
}
class C {
void visit(B b) {
auto as = [b.a];
as.map!(d => d);
}
}
gdc output :
/opt/gdc/include/d/4.8.0/std/algorithm.d: In member function
'bug.C.visit.map!(__lambda2).map!(A[]).map':
/opt/gdc/include/d/4.8.0/std/algorithm.d:380: internal compiler error: in
expand_expr_real_1, at expr.c:9266
0x71c376 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**)
../../gcc-4.8-20121007/gcc/expr.c:9261
0x723471 store_expr(tree_node*, rtx_def*, int, bool)
../../gcc-4.8-20121007/gcc/expr.c:5180
0x72807e expand_assignment(tree_node*, tree_node*, bool)
../../gcc-4.8-20121007/gcc/expr.c:4826
0x67d76f expand_gimple_stmt_1
../../gcc-4.8-20121007/gcc/cfgexpand.c:2106
0x67d76f expand_gimple_stmt
../../gcc-4.8-20121007/gcc/cfgexpand.c:2202
0x67eb84 expand_gimple_basic_block
../../gcc-4.8-20121007/gcc/cfgexpand.c:3965
0x6807a3 gimple_expand_cfg
../../gcc-4.8-20121007/gcc/cfgexpand.c:4484
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
--
Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching all issue changes.
[Issue 15] internal compiler error: in expand_expr_real_1, at expr.c:9266
http://gdcproject.org/bugzilla/show_bug.cgi?id=15 --- Comment #1 from Iain Buclaw 2012-10-17 15:19:37 UTC --- It's entirely possible that it's a problem in the gcc backend. I've tested on a copy from 08/07/2012 and can't reproduce. Regards Iain -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 1] Hello World
http://gdcproject.org/bugzilla/show_bug.cgi?id=1 --- Comment #8 from Iain Buclaw 2012-10-17 21:59:28 UTC --- 42 -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 16] New: Programs that use std.parallelism.taskPool hang
http://gdcproject.org/bugzilla/show_bug.cgi?id=16
Bug #: 16
Summary: Programs that use std.parallelism.taskPool hang
Classification: Unclassified
Product: GDC
Version: development
Platform: x86_64
OS/Version: Linux
Status: NEW
Severity: normal
Priority: Normal
Component: gdc
AssignedTo: ibuc...@gdcproject.org
ReportedBy: lomerei...@gmail.com
I've compiled GDC trunk with latest GCC.
Then I compiled the following code with GDC:
import std.parallelism;
void main() { taskPool; }
Most times, the produced executable just hangs. However, on every 5th run or
so, it finishes execution immediately, as expected.
Output of gdc -v:
Using built-in specs.
COLLECT_GCC=gdc
COLLECT_LTO_WRAPPER=/export/local/users/artem/opt/gdc48/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.8-20121014/configure --enable-languages=d
--enable-checking=release --prefix=/home/artem/opt/gdc48 --enable-multilib
Thread model: posix
gcc version 4.8.0 20121014 (experimental) (GCC)
Glibc version: 2.11.3-3
--
Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching all issue changes.
[Issue 17] New: Nasty interface contract bug
http://gdcproject.org/bugzilla/show_bug.cgi?id=17 Bug #: 17 Summary: Nasty interface contract bug Classification: Unclassified Product: GDC Version: development Platform: All OS/Version: All Status: NEW Severity: critical Priority: Normal Component: gdc AssignedTo: ibuc...@gdcproject.org ReportedBy: a...@lycus.org I could not reproduce this bug outside of MCI, but here are the instructions to do so in MCI for what it's worth: $ git clone git://github.com/lycus/mci.git $ ./bootstrap.py $ ./waf configure --check-d-compiler=gdc $ ./waf build $ ./waf test This last step is going to fail. Fire up GDB: $ gdb --args ./build/mci asm tests/assembler/pass/test0.ial -o tests/assembler/pass/test0.mci -d tests/assembler/pass/test0.ast (gdb) run Starting program: /home/alexrp/Projects/mci/build/mci asm tests/assembler/pass/test0.ial -o tests/assembler/pass/test0.mci -d tests/assembler/pass/test0.ast [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. 0x00436917 in std.path.__T15extSeparatorPosTaZ.extSeparatorPos() (path=...) at /opt/gdc/include/d/4.8.0/std/path.d:629 629while (i >= 0 && !isSeparator(path[i])) One thing is very clearly wrong here: (gdb) print path.length $1 = 140737488345808 (gdb) print path.ptr $2 = 0x7fffe82b "test0.mci" The length is completely wrong, but the pointer is OK. Let's go up a few frames: (gdb) bt #0 0x00436917 in std.path.__T15extSeparatorPosTaZ.extSeparatorPos() (path=...) at /opt/gdc/include/d/4.8.0/std/path.d:629 #1 0x0043678b in std.path.__T9extensionTaZ.extension() (path=...) at /opt/gdc/include/d/4.8.0/std/path.d:656 #2 0x005bc828 in mci.core.code.modules.ModuleSaver.save() (this=0x7fffda90) at ../src/mci/core/code/modules.d:410 #3 0x004bd83d in mci.vm.io.writer.ModuleWriter.save() (this=..., module_=..., path=...) at ../src/mci/vm/io/writer.d:37 #4 0x00432f0e in mci.cli.tools.assembler.AssemblerTool.run() (this=..., args=...) at ../src/mci/cli/tools/assembler.d:195 #5 0x0040622f in mci.cli.main.run() (args=...) at ../src/mci/cli/main.d:159 #6 0x00406527 in D main (args=...) at ../src/mci/cli/main.d:202 #7 0x006206a1 in rt.dmain2.main.runMain (this=0x7fffe360) at ../../../../gcc-4.8-20121014/libphobos/libdruntime/rt/dmain2.d:569 #8 0x00620dff in rt.dmain2.main() (this=this@entry=0x7fffe360, dg=...) at ../../../../gcc-4.8-20121014/libphobos/libdruntime/rt/dmain2.d:544 #9 0x00620fb0 in rt.dmain2.main.runAll (this=0x7fffe360) at ../../../../gcc-4.8-20121014/libphobos/libdruntime/rt/dmain2.d:579 #10 0x00620dff in rt.dmain2.main() (this=this@entry=0x7fffe360, dg=...) at ../../../../gcc-4.8-20121014/libphobos/libdruntime/rt/dmain2.d:544 #11 0x00620f15 in main (argc=7, argv=0x7fffe498) at ../../../../gcc-4.8-20121014/libphobos/libdruntime/rt/dmain2.d:588 (gdb) frame 3 #3 0x004bd83d in mci.vm.io.writer.ModuleWriter.save() (this=..., module_=..., path=...) at ../src/mci/vm/io/writer.d:37 37public void save(Module module_, string path) (gdb) print path.length $3 = 30 (gdb) print path.ptr $4 = 0x7fffe816 "tests/assembler/pass/test0.mci" Looks OK. Then: (gdb) print path.length $5 = 140737488345680 (gdb) print path.ptr $6 = 0x5bc828 "H\211\301H\211\323H\211\316H\211\320A\270" (gdb) print path.length $5 = 140737488345680 (gdb) print path.ptr $6 = 0x5bc828 "H\211\301H\211\323H\211\316H\211\320A\270" I'm pretty sure GDC is generating bad code here... -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 17] Nasty interface contract bug
http://gdcproject.org/bugzilla/show_bug.cgi?id=17 Alex Rønne Petersen changed: What|Removed |Added CC||a...@lycus.org --- Comment #1 from Alex Rønne Petersen 2012-10-21 15:39:44 UTC --- Sorry, the last steps should have been: (gdb) frame 2 (gdb) print path.length $5 = 140737488345680 (gdb) print path.ptr $6 = 0x5bc828 "H\211\301H\211\323H\211\316H\211\320A\270" -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 15] internal compiler error: in expand_expr_real_1, at expr.c:9266
http://gdcproject.org/bugzilla/show_bug.cgi?id=15
--- Comment #3 from Iain Buclaw 2012-10-22 19:20:00
UTC ---
On further analysis looks to be a custom static chain bug...
In the map!() template, we emit this code:
{
struct MapResult __ctmp997 = {};
__ctmp.this = this; // 'this' is in another context that we can't access
for here.
return = *__ctor (&__ctmp997, r);
}
Maybe will see if DMD does the same...
--
Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching all issue changes.
[Issue 18] New: callgraph error (?) when using -fdebug and sort!del(some_array)
http://gdcproject.org/bugzilla/show_bug.cgi?id=18 Bug #: 18 Summary: callgraph error (?) when using -fdebug and sort!del(some_array) Classification: Unclassified Product: GDC Version: 4.7.x Platform: x86_64 OS/Version: Linux Status: NEW Severity: blocker Priority: Normal Component: gdc AssignedTo: ibuc...@gdcproject.org ReportedBy: lt.infiltra...@gmail.com Created attachment 8 --> http://gdcproject.org/bugzilla/attachment.cgi?id=8 Code that fails Using gdc compiled from branch gdc-4.7 (at commit 972eb3d) -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 18] callgraph error (?) when using -fdebug and sort!del(some_array)
http://gdcproject.org/bugzilla/show_bug.cgi?id=18 lt.infiltra...@gmail.com changed: What|Removed |Added Severity|blocker |major -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 18] callgraph error (?) when using -fdebug and sort!del(some_array)
http://gdcproject.org/bugzilla/show_bug.cgi?id=18 --- Comment #1 from lt.infiltra...@gmail.com 2012-10-23 21:49:48 UTC --- Created attachment 9 --> http://gdcproject.org/bugzilla/attachment.cgi?id=9 gdc command and error -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 18] callgraph error (?) when using -fdebug and sort!del(some_array)
http://gdcproject.org/bugzilla/show_bug.cgi?id=18 --- Comment #2 from lt.infiltra...@gmail.com 2012-10-23 21:51:53 UTC --- Created attachment 10 --> http://gdcproject.org/bugzilla/attachment.cgi?id=10 gdc command and error for gdc from Debian's repo -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 18] callgraph error (?) when using -fdebug and sort!del(some_array)
http://gdcproject.org/bugzilla/show_bug.cgi?id=18 lt.infiltra...@gmail.com changed: What|Removed |Added CC||lt.infiltra...@gmail.com -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 18] callgraph error (?) when using -fdebug and sort!del(some_array)
http://gdcproject.org/bugzilla/show_bug.cgi?id=18 Roy Crihfield changed: What|Removed |Added CC||rscr...@gmail.com --- Comment #3 from Roy Crihfield 2012-10-24 01:49:59 UTC --- I can confirm this on 4.8.0 20120902, Arch linux x86_64. -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 19] New: byte b; --b = b; // error: non-trivial conversion (int/byte) /w wrong line number
http://gdcproject.org/bugzilla/show_bug.cgi?id=19 Bug #: 19 Summary: byte b; --b = b; // error: non-trivial conversion (int/byte) /w wrong line number Classification: Unclassified Product: GDC Version: 4.7.x Platform: x86_64 OS/Version: Linux Status: NEW Severity: trivial Priority: Normal Component: gdc AssignedTo: ibuc...@gdcproject.org ReportedBy: marco.le...@gmx.de While I was experimenting with some bit twiddling hacks, I noticed that DMD 2.060 compiles this, while GDC doesn't. It is not a normal error message though (translation to English by me): sudoku.d: In function »sudoku.solve«: sudoku.d:225:0: Error: non-trivial conversion on assignment int byte *__assignop1747 = D.9717; sudoku.d:225: confused by previous errors, abort It prints the line number of the function, not that of the assignment in question. Should this problem have been detected in an earlier compilation stage ? Is there some disagreement on the return type of the prefix (de/in)crement operator between DMD and GDC ? -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 18] callgraph error (?) when using -fdebug and sort!del(some_array)
http://gdcproject.org/bugzilla/show_bug.cgi?id=18 Iain Buclaw changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #4 from Iain Buclaw 2012-10-25 21:52:16 UTC --- CNR - I do believe this commit squashed it: https://github.com/D-Programming-GDC/GDC/commit/6df38fbc95aa193a7223c07ee30afe3452a30130 -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 15] internal compiler error: in expand_expr_real_1, at expr.c:9266
http://gdcproject.org/bugzilla/show_bug.cgi?id=15 Iain Buclaw changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Iain Buclaw 2012-10-25 22:52:00 UTC --- https://github.com/D-Programming-GDC/GDC/commit/20c0b776702947a338afc953ba35234425994c65 -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 20] New: internal compiler error: in expand_expr_real_1, at expr.c:9301
http://gdcproject.org/bugzilla/show_bug.cgi?id=20 Bug #: 20 Summary: internal compiler error: in expand_expr_real_1, at expr.c:9301 Classification: Unclassified Product: GDC Version: development Platform: x86_64 OS/Version: Linux Status: NEW Severity: major Priority: Normal Component: gdc AssignedTo: ibuc...@gdcproject.org ReportedBy: lt.infiltra...@gmail.com Created attachment 11 --> http://gdcproject.org/bugzilla/attachment.cgi?id=11 Code that fails gdc from master branch (at commit 3292afb) and gcc snapshot gcc-4.8-20121021. -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 20] internal compiler error: in expand_expr_real_1, at expr.c:9301
http://gdcproject.org/bugzilla/show_bug.cgi?id=20 --- Comment #1 from lt.infiltra...@gmail.com 2012-10-26 01:41:55 UTC --- Created attachment 12 --> http://gdcproject.org/bugzilla/attachment.cgi?id=12 gdc command and failure -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 20] internal compiler error: in expand_expr_real_1, at expr.c:9301
http://gdcproject.org/bugzilla/show_bug.cgi?id=20 Alex Rønne Petersen changed: What|Removed |Added CC||a...@lycus.org --- Comment #2 from Alex Rønne Petersen 2012-10-26 03:38:21 UTC --- (Builds with DMD and LDC.) -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 15] internal compiler error: in expand_expr_real_1, at expr.c:9266
http://gdcproject.org/bugzilla/show_bug.cgi?id=15 Iain Buclaw changed: What|Removed |Added CC||lt.infiltra...@gmail.com --- Comment #5 from Iain Buclaw 2012-10-26 12:20:35 UTC --- *** Issue 20 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 20] internal compiler error: in expand_expr_real_1, at expr.c:9301
http://gdcproject.org/bugzilla/show_bug.cgi?id=20 Iain Buclaw changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #3 from Iain Buclaw 2012-10-26 12:20:35 UTC --- You just missed the fix: https://github.com/D-Programming-GDC/GDC/commit/20c0b776702947a338afc953ba35234425994c65 *** This issue has been marked as a duplicate of issue 15 *** -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 15] internal compiler error: in expand_expr_real_1, at expr.c:9266
http://gdcproject.org/bugzilla/show_bug.cgi?id=15 --- Comment #6 from deadalnix 2012-10-26 18:23:52 UTC --- (In reply to comment #4) > https://github.com/D-Programming-GDC/GDC/commit/20c0b776702947a338afc953ba35234425994c65 So this is finally not related to dmd ? -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 21] New: ICE on calling function with delegate literal containing 'new'
http://gdcproject.org/bugzilla/show_bug.cgi?id=21
Bug #: 21
Summary: ICE on calling function with delegate literal
containing 'new'
Classification: Unclassified
Product: GDC
Version: 4.7.x
Platform: x86_64
OS/Version: Linux
Status: NEW
Severity: major
Priority: Normal
Component: gdc
AssignedTo: ibuc...@gdcproject.org
ReportedBy: hst...@quickfur.ath.cx
void addOp(void* delegate() impl) { }
static this() {
addOp({ return new B(); });
}
$ gdc -I. -O3 -g3 -frelease -c -o veclist.o veclist.d
veclist.d:5: Error: undefined identifier B
cc1d: /usr/src/gcc-4.7/gcc-4.7-4.7.2/src/gcc/d/dfrontend/cast.c:1727: virtual
Expression* FuncExp::inferType(Type*, int, TemplateParameters*): Assertion
`typen->deco' failed.
cc1d: internal compiler error: Aborted
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
This error seems very dependent on the exact compilation flags; replacing
-frelease with -funittest, for example, *seems* to make it go away. But I
suspect the problem is still there; it just doesn't show up. This is the same
bug that I posted about on the forum; I was unable to reduce it last time
because I was running with -funittest, and past a certain code size the problem
becomes hidden. Furthermore, I found that separate compilation vs. bulk
compilation isn't the real issue; separate compilation with -frelease also
triggers this bug.
Also, the undefined identifier B in the original code is actually defined
(under a different name, the exact name doesn't appear to matter -- the void*
was originally a base class of B). But the problem seems to disappear upon
reduction unless I keep an undefined identifier there. So this bug is NOT
merely a problem with undefined identifiers, in the original code it's defined
but still ICE's.
During the early stages of code reduction, the above ICE was randomly
alternating with a memory corruption error. I couldn't isolate the memory
corruption, but I did manage to isolate the typen->deco ICE.
--
Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching all issue changes.
[Issue 21] ICE on calling function with delegate literal containing 'new'
http://gdcproject.org/bugzilla/show_bug.cgi?id=21 --- Comment #1 from hst...@quickfur.ath.cx 2012-10-26 19:47:15 UTC --- Hmm. I managed to reproduce the bug with minimal command-line arguments: gdc -c veclist.d also produces the ICE. -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 22] New: Build fails with macro expansion failures for TARGET_ANDROID
http://gdcproject.org/bugzilla/show_bug.cgi?id=22 Bug #: 22 Summary: Build fails with macro expansion failures for TARGET_ANDROID Classification: Unclassified Product: GDC Version: development Platform: x86_64 OS/Version: Linux Status: NEW Severity: major Priority: Normal Component: gdc AssignedTo: ibuc...@gdcproject.org ReportedBy: lt.infiltra...@gmail.com Error: In file included from ./tm.h:19:0, from ../../gcc-4.8-20121021/gcc/d/d-spec.c:22: ./options.h:3299:36: error: token "." is not valid in preprocessor expressions #define flag_android global_options.x_flag_android ^ ./options.h:4012:26: note: in expansion of macro 'flag_android' #define TARGET_ANDROID ((flag_android & OPTION_MASK_ANDROID) != 0) ^ ../../gcc-4.8-20121021/gcc/d/d-spec.c:59:36: note: in expansion of macro 'TARGET_ANDROID' #if TARGET_WINDOS || TARGET_OSX || TARGET_ANDROID ^ ./options.h:3299:36: error: token "." is not valid in preprocessor expressions #define flag_android global_options.x_flag_android ^ ./options.h:4012:26: note: in expansion of macro 'flag_android' #define TARGET_ANDROID ((flag_android & OPTION_MASK_ANDROID) != 0) ^ ../../gcc-4.8-20121021/gcc/d/d-spec.c:488:22: note: in expansion of macro 'TARGET_ANDROID' #if TARGET_LINUX && !TARGET_ANDROID ^ Workaround for me is to just hack d-spec.c and remove those two macros; but that obviously wouldn't work if you're actually targetting android. -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 15] internal compiler error: in expand_expr_real_1, at expr.c:9266
http://gdcproject.org/bugzilla/show_bug.cgi?id=15 --- Comment #7 from Iain Buclaw 2012-10-27 00:55:49 UTC --- (In reply to comment #6) > (In reply to comment #4) > > https://github.com/D-Programming-GDC/GDC/commit/20c0b776702947a338afc953ba35234425994c65 > > So this is finally not related to dmd ? Never said it was related to dfe. :) -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 21] ICE on calling function with delegate literal containing 'new'
http://gdcproject.org/bugzilla/show_bug.cgi?id=21 --- Comment #2 from Iain Buclaw 2012-10-27 00:57:35 UTC --- looks like an FE bug. Did you try DMD 2.060 first? -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 21] ICE on calling function with delegate literal containing 'new'
http://gdcproject.org/bugzilla/show_bug.cgi?id=21 --- Comment #3 from hst...@quickfur.ath.cx 2012-10-27 01:44:12 UTC --- This problem doesn't happen on DMD (or at least, it doesn't manifest itself), that's why I reported it against GDC instead of DMD. I just tried dmd 2.060 and it seems fine. -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 23] New: undefined reference to `_d_arrayappendcTX'
http://gdcproject.org/bugzilla/show_bug.cgi?id=23 Bug #: 23 Summary: undefined reference to `_d_arrayappendcTX' Classification: Unclassified Product: GDC Version: development Platform: x86_64 OS/Version: Linux Status: NEW Severity: blocker Priority: Normal Component: gdc AssignedTo: ibuc...@gdcproject.org ReportedBy: lt.infiltra...@gmail.com Created attachment 13 --> http://gdcproject.org/bugzilla/attachment.cgi?id=13 code that fails I'm guessing that I messed something up when I built/installed it; or perhaps path/permissions issues. -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 23] undefined reference to `_d_arrayappendcTX'
http://gdcproject.org/bugzilla/show_bug.cgi?id=23 --- Comment #1 from lt.infiltra...@gmail.com 2012-10-27 02:18:31 UTC --- Created attachment 14 --> http://gdcproject.org/bugzilla/attachment.cgi?id=14 gdc command and error message -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 21] ICE on calling function with delegate literal containing 'new'
http://gdcproject.org/bugzilla/show_bug.cgi?id=21 --- Comment #4 from Iain Buclaw 2012-10-27 09:53:19 UTC --- (In reply to comment #3) > This problem doesn't happen on DMD (or at least, it doesn't manifest itself), > that's why I reported it against GDC instead of DMD. I just tried dmd 2.060 > and > it seems fine. Right, now try it with 2.059. :-) -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 19] byte b; --b = b; // error: non-trivial conversion (int/byte) /w wrong line number
http://gdcproject.org/bugzilla/show_bug.cgi?id=19 Iain Buclaw changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Iain Buclaw 2012-10-27 14:08:05 UTC --- Fixed in trunk. https://github.com/D-Programming-GDC/GDC/commit/bab24a82d7079686375a74b017752cfdfc082ffc -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 21] ICE on calling function with delegate literal containing 'new'
http://gdcproject.org/bugzilla/show_bug.cgi?id=21 hst...@quickfur.ath.cx changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Comment #5 from hst...@quickfur.ath.cx 2012-10-27 15:55:36 UTC --- You're right, this bug is in dmd 2.059. -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 13] ARM: can't cast _argptr / va_list to pointer
http://gdcproject.org/bugzilla/show_bug.cgi?id=13 Johannes Pfau changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Johannes Pfau 2012-10-27 17:53:41 UTC --- Fixed in upstream dmd: https://github.com/D-Programming-Language/dmd/commit/f804036586e3c5a363c29f47f1e9407304c75f9e -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 22] Build fails with macro expansion failures for TARGET_ANDROID
http://gdcproject.org/bugzilla/show_bug.cgi?id=22 Johannes Pfau changed: What|Removed |Added Status|NEW |ASSIGNED CC||johannesp...@gmail.com AssignedTo|ibuc...@gdcproject.org |johannesp...@gmail.com --- Comment #1 from Johannes Pfau 2012-10-27 18:16:33 UTC --- A recent change in gcc broke this. Workaround: Use an older gcc snapshot. The problem: GCC now defines a TARGET_ANDROID itself which clashes with our TARGET_ANDROID: - * opth-gen.awk (TARGET_* generation): Always generate TARGET_ for Mask options, whether they use Var(...) or not. - We can probably use that TARGET_ANDROID macro and throw away our implementation. Can you test if whether it works if you put the calls to TARGET_ANDROID in parens? So in d-spec.c:59: #if TARGET_WINDOS || TARGET_OSX || (TARGET_ANDROID) and d-spec.c:488:22: #if TARGET_LINUX && !(TARGET_ANDROID) If this does not fix it, it's probably a bug in upstream gcc as the error is in the TARGET_ANDROID macro definition which is part of gcc. -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
[Issue 22] Build fails with macro expansion failures for TARGET_ANDROID
http://gdcproject.org/bugzilla/show_bug.cgi?id=22 --- Comment #2 from Johannes Pfau 2012-10-27 18:21:03 UTC --- Ermm, maybe the gcc TARGET_ANDROID macro expands to a runtime expression. This needs some more work then. -- Configure issuemail: http://gdcproject.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all issue changes.
