[Bug 169] New: Can't build druntime on os x (ICE)
http://bugzilla.gdcproject.org/show_bug.cgi?id=169 Bug ID: 169 Summary: Can't build druntime on os x (ICE) Product: GDC Version: development Hardware: All OS: All Status: NEW Severity: normal Priority: Normal Component: gdc Assignee: ibuc...@gdcproject.org Reporter: john.loughran.col...@gmail.com /Users/john/Git/gdc/objdir/./gcc/gdc -B/Users/john/Git/gdc/objdir/./gcc/ -B/opt/gdc/x86_64-apple-darwin14.0.0/bin/ -B/opt/gdc/x86_64-apple-darwin14.0.0/lib/ -isystem /opt/gdc/x86_64-apple-darwin14.0.0/include -isystem /opt/gdc/x86_64-apple-darwin14.0.0/sys-include -o object_.o -Wall -g -frelease -O2 -nostdinc -pipe -Wno-deprecated -I ../../../../gcc-5-20141207/libphobos/libdruntime -I ./x86_64-apple-darwin14.0.0 -I . -c ../../../../gcc-5-20141207/libphobos/libdruntime/object_.d ../../../../gcc-5-20141207/libphobos/libdruntime/object_.d: In member function ‘tsize’: ../../../../gcc-5-20141207/libphobos/libdruntime/object_.d:1: error: LHS in noreturn call # VUSE <.MEM_1(D)> retval.415_3 = talign (this_2(D)); [tail call] ../../../../gcc-5-20141207/libphobos/libdruntime/object_.d:1: internal compiler error: verify_gimple failed ../../../../gcc-5-20141207/libphobos/libdruntime/object_.d:1: internal compiler error: Abort trap: 6 gdc: internal compiler error: Abort trap: 6 (program cc1d) -- You are receiving this mail because: You are watching all bug changes.
[Bug 169] Can't build druntime on os x (ICE)
http://bugzilla.gdcproject.org/show_bug.cgi?id=169 John Colvin changed: What|Removed |Added Hardware|All |x86_64 OS|All |OSX Severity|normal |major --- Comment #1 from John Colvin --- This is with OS X 10.10, same results when compiling gdc with gcc-proper or clang. gcc snapshot gcc-5-20141207 -- You are receiving this mail because: You are watching all bug changes.
[Bug 170] New: Template functions in templates missing member symbols
http://bugzilla.gdcproject.org/show_bug.cgi?id=170
Bug ID: 170
Summary: Template functions in templates missing member symbols
Product: GDC
Version: 4.8.x
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: Normal
Component: gdc
Assignee: ibuc...@gdcproject.org
Reporter: obscur...@gmail.com
Template functions in a template scope aren't inferring instantiations
correctly. This is a bit hard to explain so here's a MWE:
---file1
module foobar;
class bar(T) {
void undefined_reference() {}
}
template foo(T) {
bar!T foo1(T2)() if (true) body { return null; }
bar!T foo2(T2)() { return null; }
bar!T foo3(T2 = void)() if (true) body { return null; }
bar!T foo4(T2 = void)() { return null; }
void foo5(T2)(bar!T x) if (true) body {}
void foo6(T2)(bar!T x) {}
void foo7(T2 = void)(bar!T x) if (true) body {}
void foo8(T2 = void)(bar!T x) {}
}
---end
---file2
import foobar;
void main() {
foo!void.foo1!void();// succeeds
foo!void.foo2!void();// succeeds
foo!void.foo3();// succeeds
foo!void.foo3!void();// succeeds
foo!void.foo4();// succeeds
foo!void.foo4!void();// succeeds
//foo!void.foo5!void(null);// fails!
foo!void.foo6!void(null);// succeeds
foo!void.foo7(null);// succeeds
//foo!void.foo7!void(null);// fails!
foo!void.foo8(null);// succeeds
foo!void.foo8!void(null);// succeeds
}
---end
Uncomment the failing lines, and I get (on 4.8.2) a linker error missing void
foobar.bar!(void).bar.undefined_reference().
If they are in the same file nothing fails. For parameters only, it fails only
if both a template argument was given and a template constraint exists.
--
You are receiving this mail because:
You are watching all bug changes.
[Bug 171] New: >>>= broken with short integers
http://bugzilla.gdcproject.org/show_bug.cgi?id=171
Bug ID: 171
Summary: >>>= broken with short integers
Product: GDC
Version: development
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: Normal
Component: gdc
Assignee: ibuc...@gdcproject.org
Reporter: ibuc...@gdcproject.org
Testcase:
void main()
{
short a = -1;
while (a != 0)
a >>>= 1;
}
This program will loop forever.
--
You are receiving this mail because:
You are watching all bug changes.
[Bug 171] >>>= broken with short integers
http://bugzilla.gdcproject.org/show_bug.cgi?id=171 --- Comment #1 from Iain Buclaw --- Problem is that in the operation: a = a >> 1; 'a' is promoted to an unsigned integer for normal operations before the final result being downcasted back. So we get the following sequence. a => -1 cast(uint) => 4294967295 a >> 1 => 2147483647 cast(short) => -1 -- You are receiving this mail because: You are watching all bug changes.
[Bug 171] >>>= broken with short integers
http://bugzilla.gdcproject.org/show_bug.cgi?id=171 Iain Buclaw changed: What|Removed |Added Status|NEW |ASSIGNED -- You are receiving this mail because: You are watching all bug changes.
[Bug 171] >>>= broken with short integers
http://bugzilla.gdcproject.org/show_bug.cgi?id=171 Iain Buclaw changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Iain Buclaw --- https://github.com/D-Programming-GDC/GDC/commit/2eabee4674c557bcb986837aa851b7c8c2817174 -- You are receiving this mail because: You are watching all bug changes.
[Bug 165] gdc segfault on scope(failure)
http://bugzilla.gdcproject.org/show_bug.cgi?id=165 Ketmar Dark changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |UPSTREAM --- Comment #3 from Ketmar Dark --- i just checked this, and found no segfaults anymore. i think that we can close this bug now, but i don't sure which reason to choose. seems that "resolved/upstream" is the right one. so i'm doing that. -- You are receiving this mail because: You are watching all bug changes.
[Bug 172] New: Add support for GCC's weak attribute
http://bugzilla.gdcproject.org/show_bug.cgi?id=172 Bug ID: 172 Summary: Add support for GCC's weak attribute Product: GDC Version: development Hardware: All OS: All Status: NEW Severity: enhancement Priority: Normal Component: gdc Assignee: ibuc...@gdcproject.org Reporter: slavo5...@yahoo.com see https://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html#index-g_t_0040code_007bweak_007d-attribute-3186 -- You are receiving this mail because: You are watching all bug changes.
[Bug 173] New: internal compiler error typeMerge
http://bugzilla.gdcproject.org/show_bug.cgi?id=173
Bug ID: 173
Summary: internal compiler error typeMerge
Product: GDC
Version: 4.9.x
Hardware: All
OS: All
Status: NEW
Severity: minor
Priority: Normal
Component: gdc
Assignee: ibuc...@gdcproject.org
Reporter: danny.mil...@gmail.com
struct Cell {
dchar code;
alias code this; // FIXME?
}
struct Row {
Cell[] fCells; // actually dchar[][] would be better.
Cell opIndex(int x) {
return (x >= 0) ? fCells[x] : ' ';
}
}
int main() {
return 0;
}
gdc (Debian 4.9.1-19) 4.9.1
Copyright (C) 2014 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.
$ gdc a.d
cc1d: ../../src/gcc/d/dfrontend/cast.c:2691: int typeMerge(Scope*, Expression*,
Type**, Expression**, Expression**): Assertion `t1->ty == t2->ty' failed.
cc1d: internal compiler error: Aborted
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
It's because fCells[x] :: Cell and ' ' :: char. Only happens with the "alias
this".
--
You are receiving this mail because:
You are watching all bug changes.
[Bug 174] New: core.atomic.atomicFence() should be @nogc
http://bugzilla.gdcproject.org/show_bug.cgi?id=174 Bug ID: 174 Summary: core.atomic.atomicFence() should be @nogc Product: GDC Version: 4.9.x Hardware: All OS: Linux Status: NEW Severity: normal Priority: Normal Component: libgdruntime Assignee: ibuc...@gdcproject.org Reporter: ket...@ketmar.no-ip.org Created attachment 80 --> http://bugzilla.gdcproject.org/attachment.cgi?id=80&action=edit add @nogc attribute to core.atomic.atomicFence() subj. other core.atomic operations are templates, so compiler is able to infer @nogc on 'em. -- You are receiving this mail because: You are watching all bug changes.
[Bug 174] core.atomic.atomicFence() should be @nogc
http://bugzilla.gdcproject.org/show_bug.cgi?id=174 Johannes Pfau changed: What|Removed |Added Status|NEW |RESOLVED CC||johannesp...@gmail.com Resolution|--- |FIXED --- Comment #1 from Johannes Pfau --- Thanks. https://github.com/D-Programming-GDC/GDC/commit/0d35abb0223f82f435979d552e9e2d139f9b106a -- You are receiving this mail because: You are watching all bug changes.
[Bug 78] GDC-4.7: Compilation broken
http://bugzilla.gdcproject.org/show_bug.cgi?id=78 Iain Buclaw changed: What|Removed |Added Status|NEW |RESOLVED CC||ibuc...@gdcproject.org Resolution|--- |FIXED --- Comment #1 from Iain Buclaw --- This should be fixed (I can build images for gdc-4.7) You can see the recent history here: https://github.com/D-Programming-GDC/GDC/commits/gdc-4.7 -- You are receiving this mail because: You are watching all bug changes.
[Bug 63] c++ compiler built even when --disable-bootstrap is given
http://bugzilla.gdcproject.org/show_bug.cgi?id=63 --- Comment #4 from Iain Buclaw --- I think it should now be possible to remove this. C++ is now *the* boot language for gcc. So by that measure it *must* be automatically enabled in bootstrapped builds. Let me test... -- You are receiving this mail because: You are watching all bug changes.
[Bug 63] c++ compiler built even when --disable-bootstrap is given
http://bugzilla.gdcproject.org/show_bug.cgi?id=63 Timo Sintonen changed: What|Removed |Added CC||t.sinto...@luukku.com --- Comment #5 from Timo Sintonen --- Not fully releted but... When building a cross compiler, c++ for target is also built. The time is not the issue there but c++ and its runtime library may not build in all systems. If they build properly they may not work anyway. In addition, c++ runtime requires libc for target to be installed before it is possible to start compiling gcc. -- You are receiving this mail because: You are watching all bug changes.
[Bug 63] c++ compiler built even when --disable-bootstrap is given
http://bugzilla.gdcproject.org/show_bug.cgi?id=63 Iain Buclaw changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Iain Buclaw --- It is related. The configure script for GCC seems to have a slightly odd logic for which languages it should enable in the stage1 phase. It seems silly to me that lang_requires_boot_languages should even be considered in --disable-bootstrap builds, but hey ho... The fix Brad has been waiting for - I can give you back that time when we meet at Dconf this year. :) https://github.com/D-Programming-GDC/GDC/commit/10335c0c00b5b2d2a3c31eb7bf6c2ce7b5e7012b -- You are receiving this mail because: You are watching all bug changes.
[Bug 175] New: immutable override - error in error reporting
http://bugzilla.gdcproject.org/show_bug.cgi?id=175 Bug ID: 175 Summary: immutable override - error in error reporting Product: GDC Version: 4.9.x Hardware: All OS: All Status: NEW Severity: normal Priority: Normal Component: gdc Assignee: ibuc...@gdcproject.org Reporter: danny.mil...@gmail.com Created attachment 81 --> http://bugzilla.gdcproject.org/attachment.cgi?id=81&action=edit example See attached example. $ gdc A.d cc1d: ../../src/gcc/d/dfrontend/statement.c:293: ErrorStatement::ErrorStatement(): Assertion `global.gaggedErrors || global.errors' failed. cc1d: internal compiler error: Aborted Please submit a full bug report, with preprocessed source if appropriate. See for instructions. $ gdc --version gdc (Debian 4.9.1-19) 4.9.1 Copyright (C) 2014 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 175] immutable override - error in error reporting
http://bugzilla.gdcproject.org/show_bug.cgi?id=175 --- Comment #1 from Danny Milosavljevic --- According to Ketmar it's both non-DMD bug, and nonexistent-in-new-gdc bug. -- You are receiving this mail because: You are watching all bug changes.
[Bug 176] New: __ctfe variable should not be readable in CTFE
http://bugzilla.gdcproject.org/show_bug.cgi?id=176
Bug ID: 176
Summary: __ctfe variable should not be readable in CTFE
Product: GDC
Version: development
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: Normal
Component: gdc
Assignee: ibuc...@gdcproject.org
Reporter: ket...@ketmar.no-ip.org
Created attachment 82
--> http://bugzilla.gdcproject.org/attachment.cgi?id=82&action=edit
__ctfe ctfe fix
yes, this is a bug (that solved in upcoming 2.067). this code must trigger
compilation error:
static if (__ctfe) {}
i attached a fix, backported from dmd.
--
You are receiving this mail because:
You are watching all bug changes.
[Bug 177] New: core.thread won't compile
http://bugzilla.gdcproject.org/show_bug.cgi?id=177 Bug ID: 177 Summary: core.thread won't compile Product: GDC Version: development Hardware: All OS: OSX Status: NEW Severity: critical Priority: Normal Component: libgdruntime Assignee: ibuc...@gdcproject.org Reporter: john.loughran.col...@gmail.com ../../../../gcc-4.9.2/libphobos/libdruntime/core/thread.d:3551:13: error: static assert "Not implemented" static assert(0, "Not implemented"); To fix this, either core.sys.posix.ucontext needs OS X support or the inline asm in fiber_switchContext needs translating. -- You are receiving this mail because: You are watching all bug changes.
[Bug 168] Missing "section" GCC attribute in GDC
http://bugzilla.gdcproject.org/show_bug.cgi?id=168 Jens Bauer changed: What|Removed |Added CC||jens-bugzi...@gpio.dk --- Comment #1 from Jens Bauer --- Being able to select which section code, variables, arrays and other data will go into is especially important when working with microcontrollers. The following gives some insight of why this feature is useful on microcontrollers: For instance: Often the first N words of data is reserved for exception vectors. On ARM, for instance (any ARM architecture), the first 16 words which are 32-bit wide each, contain first an initial stack pointer value followed by core vectors. After those 16 vectors, the vendor may choose what interrupt vectors to add (normally up to 256 vectors can be supported here). In a linker-script, one would typically make a section called .isr_vectors and then put an array of function-pointers in this section. Note: Such a section may be read-only memory (eg. Flash memory or ROM), but in some cases it can be RAM. Other reasons for being able to specify sections include the ability to choose which data goes into CCMRAM (CCM=Core Coupled Memory) on some devices, NOR-Flash, NAND-Flash, Flash Bank 1, Flash Bank 2, SRAM1, SRAM2, SRAM3, SRAM4, Local SRAM, SDRAM, External SRAM, ROM, and so forth; even SD/MMC card can be written indirectly this way. On some microcontrollers, it's very useful to have code (normally running in the .text section) to be copied to SRAM for fast execution speed, as executing code from the Flash memory might be up to 7 times slower than SRAM. Thus small subroutines can often be placed in SRAM to improve speed greatly. Since the D compiler already know about some sections, it would be convenient having native support for it, which would not depend on the backend. -- You are receiving this mail because: You are watching all bug changes.
[Bug 172] Add support for GCC's weak attribute
http://bugzilla.gdcproject.org/show_bug.cgi?id=172
Jens Bauer changed:
What|Removed |Added
CC||jens-bugzi...@gpio.dk
--- Comment #1 from Jens Bauer ---
Having support for this will be highly appreciated.
Especially weak,alias is important on microcontrollers, which have exception
vectors.
Small C Example (this one is for ARM Cortex-M microcontrollers):
---8<-8<-8<-
#define WA(a) __attribute__((weak, alias(#a)))
#define WE WA(defaultExceptionHandler)
#define WR WA(defaultResetHandler)
typedef void (*const VectorFunc)(void);
static void defaultResetHandler(void) __attribute__((__interrupt__));
/* $ System Exception Vector Handlers: */
void WR Reset_Handler(void);/* 1 $0004 Reset */
void WE NMI_Handler(void); /* 2 $0008 Non Maskable Interrupt */
void WE HardFault_Handler(void);/* 3 $000c Hard Fault */
...
...
/* Vector Table */
__attribute__((section(".isr_vector"))) VectorFunc g_pfnVectors[] =
{
(VectorFunc)STACK_ADDRESS, /* 0 $ Initial Stack Pointer */
Reset_Handler, /* 1 $0004 Reset Vector */
NMI_Handler,/* 2 $0008 Non Maskable Interrupt Vector */
HardFault_Handler, /* 3 $000c Hard Fault Vector */
...
...
};
static void defaultResetHandler(void)
{
while(1){ asm volatile("wfi"); }
}
--->8->8->8-
The above example demonstrates the use of the section attribute and the use of
the weak+alias attribute.
The weak+alias is used for having default implementations of all the exception
handlers (including Reset_Handler).
This means that the user can just start writing code, but allows customization
in case an implementation, which is either simpler or more advanced than the
provided one is required.
--
You are receiving this mail because:
You are watching all bug changes.
[Bug 126] Add support for attribute to mark data as volatile.
http://bugzilla.gdcproject.org/show_bug.cgi?id=126 Johannes Pfau changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |WONTFIX --- Comment #22 from Johannes Pfau --- The volatileLoad/Store intrinsics will have to suffice. -- You are receiving this mail because: You are watching all bug changes.
[Bug 96] phobos build doesn't use CFLAGS_FOR_BUILD in most cases
http://bugzilla.gdcproject.org/show_bug.cgi?id=96 Johannes Pfau changed: What|Removed |Added Status|NEW |RESOLVED CC||johannesp...@gmail.com Resolution|--- |FIXED --- Comment #1 from Johannes Pfau --- The phobos makefile now uses the DFLAGS variable. And BTW: build=machine which builds the compiler host=machine which runs the compiler target=machine which the compiler generates code for flags for build therefore should only be used when building programs that have to run on the machine building the compiler. (E.g. when building idgen) -- You are receiving this mail because: You are watching all bug changes.
[Bug 105] improve documentation about gdc internals
http://bugzilla.gdcproject.org/show_bug.cgi?id=105 Johannes Pfau changed: What|Removed |Added Status|NEW |RESOLVED CC||johannesp...@gmail.com Resolution|--- |INVALID --- Comment #1 from Johannes Pfau --- I'll mark this as resolved. There's some information on the wiki. Of course there could always be more but there's no point in keeping a bug report which only says 'write more documentation'. -- You are receiving this mail because: You are watching all bug changes.
[Bug 160] Support for "Variable Templates" missing/broken
http://bugzilla.gdcproject.org/show_bug.cgi?id=160 Johannes Pfau changed: What|Removed |Added Status|NEW |RESOLVED CC||johannesp...@gmail.com Resolution|--- |FIXED -- You are receiving this mail because: You are watching all bug changes.
[Bug 168] Missing "section" GCC attribute in GDC
http://bugzilla.gdcproject.org/show_bug.cgi?id=168 Johannes Pfau changed: What|Removed |Added Status|NEW |RESOLVED CC||johannesp...@gmail.com Resolution|--- |FIXED --- Comment #2 from Johannes Pfau --- https://github.com/D-Programming-GDC/GDC/commit/b20184d7639a8e5529cd6172e094d5d2affbb496 -- You are receiving this mail because: You are watching all bug changes.
[Bug 137] missing import in std.range
http://bugzilla.gdcproject.org/show_bug.cgi?id=137 Johannes Pfau changed: What|Removed |Added Status|NEW |RESOLVED CC||johannesp...@gmail.com Resolution|--- |FIXED --- Comment #1 from Johannes Pfau --- Sorry, somehow didn't see this bug report. Fixed with last frontend merge. -- You are receiving this mail because: You are watching all bug changes.
[Bug 138] std.enconding: EncodingSchemeUtf16Native and EncodingSchemeUtf32Native invalid splicing
http://bugzilla.gdcproject.org/show_bug.cgi?id=138 Johannes Pfau changed: What|Removed |Added Status|NEW |RESOLVED CC||johannesp...@gmail.com Resolution|--- |UPSTREAM --- Comment #3 from Johannes Pfau --- This should go to upstream phobos first. If it's urgent we can backport this as soon as it's in mainline phobos. -- You are receiving this mail because: You are watching all bug changes.
[Bug 82] Crash when compiled with gdc (not dmd). Related to direntry? or with?
http://bugzilla.gdcproject.org/show_bug.cgi?id=82 Johannes Pfau changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #6 from Johannes Pfau --- Closing as WORKSFORME. If this is still an issue please reopen this bug report. -- You are receiving this mail because: You are watching all bug changes.
[Bug 177] core.thread won't compile
http://bugzilla.gdcproject.org/show_bug.cgi?id=177 Johannes Pfau changed: What|Removed |Added CC||johannesp...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[Bug 95] Definition of _tls_data_array with version( OSX ) in thread.d
http://bugzilla.gdcproject.org/show_bug.cgi?id=95 Johannes Pfau changed: What|Removed |Added CC||johannesp...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[Bug 172] Add support for GCC's weak attribute
http://bugzilla.gdcproject.org/show_bug.cgi?id=172 Johannes Pfau changed: What|Removed |Added CC||johannesp...@gmail.com --- Comment #2 from Johannes Pfau --- https://github.com/D-Programming-GDC/GDC/pull/96 -- You are receiving this mail because: You are watching all bug changes.
[Bug 126] Add support for attribute to mark data as volatile.
http://bugzilla.gdcproject.org/show_bug.cgi?id=126 Jens Bauer changed: What|Removed |Added CC||jens-bugzi...@gpio.dk --- Comment #23 from Jens Bauer --- (In reply to Johannes Pfau from comment #22) > The volatileLoad/Store intrinsics will have to suffice. Are these guaranteed to be in the specified order for volatileLoad/Store, assuming a, b, c and d are different memory locations: read a write b read c read d -Or would the compiler be able to mess up the order ? I believe it's important to be able to keep the order exactly, so that you can transfer data using several ports. Simple (pseudo-code) example: SWD protocol SWDIO_DIR = 0; /* data direction = input */ SWCLK = 0; /* clock pin low */ i = SWDIO; /* read data */ SWCLK = 1; /* clock pin high */ SWDIO_DIR = 1; /* data direction = output */ SWDIO = o; /* write bit 'o' */ SWCLK = 0; /* clock pin low */ cast(void)SWDIO; /* read value but throw it away. (this delay is required) */ SWCLK = 1; /* clock pin high */ ... A much more advanced example would be to have multiple clock pins and multiple ports where we read/write many bits on each port. -- You are receiving this mail because: You are watching all bug changes.
[Bug 91] String literals not always properly zero-terminated
http://bugzilla.gdcproject.org/show_bug.cgi?id=91 Jens Bauer changed: What|Removed |Added CC||jens-bugzi...@gpio.dk --- Comment #11 from Jens Bauer --- (In reply to Peter Remmers from comment #7) > I might add, always adding a zero termination costs nothing apart from a few > bytes in the data segment. > > At the very least this is a performance issue, as GDC's toStringz(string) > would always copy, and DMD's and LDC's would not. Though this might be an old conversation, I'd like to add: If your string resides in read-only memory, and you need to use it as a zero-terminated string, then you will need to copy it to read/write memory, in order to add the zero. After that, you can hand it to whichever function you need to call. Disadvantages: 1: On small microcontrollers - say those that have 1024 bytes of RAM and 8KB Flash memory (eg. read-only memory), you'll very quickly run out of memory. Thus it would be a good idea to have the zero included in the string in such cases. 2: It's fairly easy to implement bugs in your code, if strings are not zero-terminated automatically. Advantages: When you have very little read-only memory, then it may be possible to recycle a strings where occurrences of smaller strings can be found within longer strings. -Unfortunately, many strings start with an uppercase letter. "assignment missing" "missing variable" "variable not found" "found '%s' when expecting '%s'" I do not know, how realstic this compression/compacting is in the real world, though, but it could be significant on small devices. My suggestion would be: By default, a zero-termination should be included. If explicitly specified, the zero-termination should be excluded. Then we'd have the safety from getting loads of bugs when writing 'late-night code' and still be able to benefit from short strings and possibly compacting. -- You are receiving this mail because: You are watching all bug changes.
[Bug 126] Add support for attribute to mark data as volatile.
http://bugzilla.gdcproject.org/show_bug.cgi?id=126 --- Comment #24 from Iain Buclaw --- (In reply to Jens Bauer from comment #23) > (In reply to Johannes Pfau from comment #22) > > The volatileLoad/Store intrinsics will have to suffice. > > Are these guaranteed to be in the specified order for volatileLoad/Store, > assuming a, b, c and d are different memory locations: > > read a > write b > read c > read d > > -Or would the compiler be able to mess up the order ? Compiler reordering should never mess up order of program logic to variables/objects where changes are considered 'observable' (eg, on shared data). Most re-ordering/memoization happens on 'non-observable' data such as local variables, thread-local storage. However, that certainly doesn't stop certain C-like behaviours from occuring in the optimiser. Such include crash-inducing operations like divide by zero may be pushed forward to occur before volatile load/reads or actions with side-effects. -- You are receiving this mail because: You are watching all bug changes.
[Bug 178] New: cc1d locks up when specifying function instead of function pointer in an array
http://bugzilla.gdcproject.org/show_bug.cgi?id=178 Bug ID: 178 Summary: cc1d locks up when specifying function instead of function pointer in an array Product: GDC Version: 4.9.x Hardware: PPC OS: OSX Status: NEW Severity: critical Priority: Normal Component: gdc Assignee: ibuc...@gdcproject.org Reporter: jens-bugzi...@gpio.dk Created attachment 83 --> http://bugzilla.gdcproject.org/attachment.cgi?id=83&action=edit Example file. When compiling this, cc1d locks up. By accident I forgot to add a '&' in front of Reset_Handler in this array: Steps to reproduce: Build the attachd file 'start.d'. Results: cc1d locks up. build: f378f9a, branch=gdc-4.9 Code: VectorFunc [3] g_pfnVectors = [ &Reset_Handler, /* If removing the '&' here, cc1d locks up. */ ]; Speculation: This bug might relate to all platforms or perhaps a Big Endian issue if it's not reproducible on for instance X86. Note: Unfortunately, the tools that Apple provide for debugging locks up, when I'm trying to sample the process, in order to find out where it locks up. -- You are receiving this mail because: You are watching all bug changes.
[Bug 178] cc1d locks up when specifying function instead of function pointer in an array
http://bugzilla.gdcproject.org/show_bug.cgi?id=178 Ketmar Dark changed: What|Removed |Added CC||ket...@ketmar.no-ip.org --- Comment #1 from Ketmar Dark --- it is reproducible on my GNU/Linux x86 box. moreover, it's reproducible with DMD, so it's a general frontend bug. mind filling an issue in DMD bugzilla? -- You are receiving this mail because: You are watching all bug changes.
[Bug 178] cc1d locks up when specifying function instead of function pointer in an array
http://bugzilla.gdcproject.org/show_bug.cgi?id=178 --- Comment #2 from Ketmar Dark --- ah, i looked closer at your sample and found that it's an expected behavior. ;-) what going on here is CTFE. as `ResetHandler` never exits, CTFE interpreter never exits too. it's possible to write a simple enless loop detector in interpreter, but it's impossible to detect all kind of endless loops. so i don't know how to solve this: setting some arbitrary limit on loop iteration will simply hide the problem, but won't solve it. -- You are receiving this mail because: You are watching all bug changes.
[Bug 178] cc1d locks up when specifying function instead of function pointer in an array
http://bugzilla.gdcproject.org/show_bug.cgi?id=178 --- Comment #3 from Ketmar Dark --- p.s. but for this particular case CTFE can fail early, as `Reset_Handler` is `void`, so there is no sense to interpret it. -- You are receiving this mail because: You are watching all bug changes.
[Bug 178] cc1d locks up when specifying function instead of function pointer in an array
http://bugzilla.gdcproject.org/show_bug.cgi?id=178 --- Comment #4 from Jens Bauer --- Being new to D is probably why this confuses me. Eg.. I am expecting the compiler to generate code, not execute it. The GDC I've build is a cross-compiler, thus it generates code for a different architecture than my host architecture. Would GDC really 'run' my code ? -- You are receiving this mail because: You are watching all bug changes.
[Bug 178] cc1d locks up when specifying function instead of function pointer in an array
http://bugzilla.gdcproject.org/show_bug.cgi?id=178
--- Comment #5 from Ketmar Dark ---
see the part about CTFE here: http://dlang.org/function.html#interpretation
one of the features of D is that it can run code in *compile* *time* (hence the
"CTFE" term — it's "Compile Time Function Evaluation"). compiler can run D code
while compiling your source and use the result to initialise variables.
in your case compiler tries to evaluate `Reset_Handler()` and use it's return
value to init array element. it's a very powerful feature, as you can calculate
various tables without resorting to external "generators". i, for example,
using that to generate parity flag table in my Z80 emulator:
auto genParityTable () {
ubyte[256] t;
foreach (immutable f; 0..256) {
int n, p;
for (n = f, p = 0; n != 0; n >>= 1) p ^= n&0x01;
t[f] = (p ? 0 : 1);
}
return t;
}
private immutable ubyte[256] tblParity = genParityTable();
here compiler executes `genParityTable()` when it compiling my code and using
it's result to init `tblParity`.
it's vital to understand that `tblParity` is initialized in COMPILE time, there
is no runtime function calls.
the power of D, yeah.
--
You are receiving this mail because:
You are watching all bug changes.
[Bug 178] cc1d locks up when specifying function instead of function pointer in an array
http://bugzilla.gdcproject.org/show_bug.cgi?id=178 --- Comment #6 from Ketmar Dark --- i.e. D compiler can interpret D code in compile time, it has full-featured D interpreter built in. ;-) -- You are receiving this mail because: You are watching all bug changes.
[Bug 178] cc1d locks up when specifying function instead of function pointer in an array
http://bugzilla.gdcproject.org/show_bug.cgi?id=178
--- Comment #7 from Jens Bauer ---
(In reply to Ketmar Dark from comment #5)
> private immutable ubyte[256] tblParity = genParityTable();
>
> it's vital to understand that `tblParity` is initialized in COMPILE time,
> there is no runtime function calls.
I agree; CTFE is a good feature, indeed.
Does this happen only for immutable assignments ?
If so, then the problem is not so big, but it still is nasty, when the compiler
locks up.
Detection could probably be tricky. I would expect that even if checking the
condition given to while() could fail, so that when there's in fact no lock-up,
it would happen as well.
And a naive 32-bit loop-counter would probably not do well either.
Recognizing a while(constant){ ... } would of course help.
I think that it all boils down to if there's a branch-back without any kind of
conditional exit instruction in the generated code, it would work quite well
(but would probably not be completely foolproof).
--
You are receiving this mail because:
You are watching all bug changes.
[Bug 178] cc1d locks up when specifying function instead of function pointer in an array
http://bugzilla.gdcproject.org/show_bug.cgi?id=178 --- Comment #8 from Ketmar Dark --- (In reply to Jens Bauer from comment #7) > I agree; CTFE is a good feature, indeed. > Does this happen only for immutable assignments ? and for array initialization. you'd better read some D book to get it right, as i really bad at explanations. ;-) i "feel" it, but can't "word" it. > I think that it all boils down to if there's a branch-back without any kind > of conditional exit instruction in the generated code, it would work quite > well (but would probably not be completely foolproof). this will require deeper code analysis in frontend. it's doable, but i don't know if someone will take that task. in your case, however, CTFE engine should abort before even trying to evaluate anything, as `void` is not a value suitable for array element. this check is easier, and it worth filling a bug in DMD bugzilla. -- You are receiving this mail because: You are watching all bug changes.
[Bug 178] cc1d locks up when specifying function instead of function pointer in an array
http://bugzilla.gdcproject.org/show_bug.cgi?id=178 --- Comment #9 from Jens Bauer --- (In reply to Ketmar Dark from comment #8) > in your case, however, CTFE engine should abort before even trying to > evaluate anything, as `void` is not a value suitable for array element. this > check is easier, and it worth filling a bug in DMD bugzilla. Yes, I agree. Evaluating the function is also redundant, as void is specified to return 0. If I had made it return an int, the case would be different. -- You are receiving this mail because: You are watching all bug changes.
[Bug 178] cc1d locks up when specifying function instead of function pointer in an array
http://bugzilla.gdcproject.org/show_bug.cgi?id=178 --- Comment #10 from Iain Buclaw --- I raised this upstream. https://issues.dlang.org/show_bug.cgi?id=14419 -- You are receiving this mail because: You are watching all bug changes.
[Bug 178] cc1d locks up when specifying function instead of function pointer in an array
http://bugzilla.gdcproject.org/show_bug.cgi?id=178 Johannes Pfau changed: What|Removed |Added Status|NEW |RESOLVED CC||johannesp...@gmail.com Resolution|--- |UPSTREAM -- You are receiving this mail because: You are watching all bug changes.
[Bug 104] gcc-4.4.5 / D2.052 / cygwin: configure error for phobos/__libc_stack_end
http://bugzilla.gdcproject.org/show_bug.cgi?id=104 Johannes Pfau changed: What|Removed |Added Status|NEW |RESOLVED CC||johannesp...@gmail.com Resolution|--- |INVALID --- Comment #1 from Johannes Pfau --- Very old report. cygwin probably doesn't work but as nobody even attempted to port gdc for cygwin... -- You are receiving this mail because: You are watching all bug changes.
[Bug 150] compiler spits asm errors
http://bugzilla.gdcproject.org/show_bug.cgi?id=150 Johannes Pfau changed: What|Removed |Added Status|NEW |RESOLVED CC||johannesp...@gmail.com Resolution|--- |WORKSFORME --- Comment #2 from Johannes Pfau --- Please reopen if new information is available. -- You are receiving this mail because: You are watching all bug changes.
[Bug 113] Internal compiler problem on shared argument of final interface method: in toElem, at d/d-elem.cc:2521
http://bugzilla.gdcproject.org/show_bug.cgi?id=113 Johannes Pfau changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||johannesp...@gmail.com Resolution|--- |WORKSFORME -- You are receiving this mail because: You are watching all bug changes.
[Bug 172] Add support for GCC's weak attribute
http://bugzilla.gdcproject.org/show_bug.cgi?id=172 Johannes Pfau changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Johannes Pfau --- https://github.com/D-Programming-GDC/GDC/commit/48384612969fe90bdf88f562d1017bd8c5ec8612 -- You are receiving this mail because: You are watching all bug changes.
[Bug 161] GDC prevents backend from removing dead functions
http://bugzilla.gdcproject.org/show_bug.cgi?id=161 --- Comment #1 from Iain Buclaw --- Isn't this what LTO/strip is used for? Actually, it's mark_needed in d-objfile.cc that forces it's write to objfile. It's needed for sure, otherwise phantom linker errors crop up in larger / heavy templated projects. -- You are receiving this mail because: You are watching all bug changes.
[Bug 81] ICE in gimple_expand_cfg
http://bugzilla.gdcproject.org/show_bug.cgi?id=81 Iain Buclaw changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Iain Buclaw --- https://github.com/D-Programming-GDC/GDC/commit/01f88518c42dc46c22305b3ef15ad26aae30ebad -- You are receiving this mail because: You are watching all bug changes.
[Bug 27] Undefined interface functions when inheriting from two sources.
http://bugzilla.gdcproject.org/show_bug.cgi?id=27 Iain Buclaw changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Iain Buclaw --- Finally fixed proper! https://github.com/D-Programming-GDC/GDC/commit/d41c3b8584262db05cf67151406209a244d0f5c4 https://github.com/D-Programming-GDC/GDC/commit/cbd6d919559697bba6bb210acc2761ae43dbaf8a -- 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
http://bugzilla.gdcproject.org/show_bug.cgi?id=148 --- Comment #2 from Iain Buclaw --- The regression is now fixed: https://github.com/D-Programming-GDC/GDC/commit/c76a734d3bf6db8120d4262fd2bba53c58174e29 I'm not sure about the enhancement, it requires that some semantic analysis that the parser is unable to distinguish. -- You are receiving this mail because: You are watching all bug changes.
[Bug 179] New: invalid code generation with -O2 for method returning ref
http://bugzilla.gdcproject.org/show_bug.cgi?id=179
Bug ID: 179
Summary: invalid code generation with -O2 for method returning
ref
Product: GDC
Version: 4.9.x
Hardware: x86
OS: Linux
Status: NEW
Severity: normal
Priority: Normal
Component: gdc
Assignee: ibuc...@gdcproject.org
Reporter: ket...@ketmar.no-ip.org
the following code works with -O0, but segfaults with -O2.
the expected output (-O0 is ok):
emit: me=B743FFF8
addS: me=B743FFF8
output with -O2:
emit: me=B73ECFF8
addS: me=BFAC86B8
the thing is that both addresses MUST be the same, and they are with -O0. but
with -O2 second address is completely wrong.
this works:
# gdc -o z00_gdc -O0 z00.d && ./z00_gdc
and this segfaults:
# gdc -o z00_gdc -O2 z00.d && ./z00_gdc
the code:
=== z00.d ===
import std.stdio;
struct Signal(Args...) {
private:
RestrictedSignal!(Args) mRestricted;
public:
alias restricted this;
void emit (Args args) @trusted { mRestricted.mImpl.emit(args); }
@property ref RestrictedSignal!(Args) restricted () @trusted { return
mRestricted; }
}
struct RestrictedSignal(Args...) {
private:
SignalImpl mImpl;
public:
void connect(string method, ClassType) (ClassType obj) @trusted
//if (is(ClassType == class) && __traits(compiles, {void delegate (Args) dg =
mixin("&obj."~method);}))
{
mImpl.addSlot(obj, cast(void delegate ())mixin("&obj."~method));
}
}
private struct SignalImpl {
@disable this (this);
@disable void opAssign (SignalImpl other);
void emit(Args...) (Args args) {
writeln("emit: me=", &this);
}
void addSlot (Object obj, void delegate () dg) {
writeln("addS: me=", &this);
}
}
class MyObject {
ref RestrictedSignal!(string, int) valueChanged () { return valueChangedSg; }
private Signal!(string, int) valueChangedSg;
@property void value (int v) {
valueChangedSg.emit("setting new value", v);
}
}
class Observer {
void watch (string msg, int i) {}
}
void main () {
auto a = new MyObject;
auto o = new Observer;
a.value = 3;
a.valueChanged.connect!"watch"(o);
}
--
You are receiving this mail because:
You are watching all bug changes.
[Bug 179] invalid code generation with -O2 for method returning ref
http://bugzilla.gdcproject.org/show_bug.cgi?id=179 Ketmar Dark changed: What|Removed |Added CC||ket...@ketmar.no-ip.org --- Comment #1 from Ketmar Dark --- p.s. changing the line a.valueChanged.connect!"watch"(o); to a.valueChangedSg.connect!"watch"(o); (i.e. bypassing method call) works as expected both with -O0 and -O2. -- You are receiving this mail because: You are watching all bug changes.
[Bug 179] invalid code generation with -O2 for method returning ref
http://bugzilla.gdcproject.org/show_bug.cgi?id=179 --- Comment #2 from Ketmar Dark --- p.p.s. i'm using GCC 4.9.2 and the corresponding HEAD branch of gdc on x86. -- You are receiving this mail because: You are watching all bug changes.
[Bug 179] invalid code generation with -O2 for method returning ref
http://bugzilla.gdcproject.org/show_bug.cgi?id=179 --- Comment #3 from Ketmar Dark --- also, adding 'final' either to `ref RestrictedSignal!(string, int) valueChanged ()` or to `@property void value (int v)` fixes the code too. -- You are receiving this mail because: You are watching all bug changes.
[Bug 52] NRVO not implemented
http://bugzilla.gdcproject.org/show_bug.cgi?id=52 Iain Buclaw changed: What|Removed |Added CC||ket...@ketmar.no-ip.org --- Comment #10 from Iain Buclaw --- *** Bug 179 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[Bug 179] invalid code generation with -O2 for method returning ref
http://bugzilla.gdcproject.org/show_bug.cgi?id=179 Iain Buclaw changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Iain Buclaw --- I think this is just another side of #52 with regards to NRVO. *** This bug has been marked as a duplicate of bug 52 *** -- You are receiving this mail because: You are watching all bug changes.
[Bug 179] invalid code generation with -O2 for method returning ref
http://bugzilla.gdcproject.org/show_bug.cgi?id=179 Iain Buclaw changed: What|Removed |Added Status|RESOLVED|NEW Resolution|DUPLICATE |--- --- Comment #5 from Iain Buclaw --- Actually, no it isn't. -- You are receiving this mail because: You are watching all bug changes.
[Bug 179] invalid code generation with -O2 for method returning ref
http://bugzilla.gdcproject.org/show_bug.cgi?id=179 Iain Buclaw changed: What|Removed |Added Status|NEW |ASSIGNED -- You are receiving this mail because: You are watching all bug changes.
[Bug 52] NRVO not implemented
http://bugzilla.gdcproject.org/show_bug.cgi?id=52 Iain Buclaw changed: What|Removed |Added Status|NEW |ASSIGNED -- You are receiving this mail because: You are watching all bug changes.
[Bug 52] NRVO not implemented
http://bugzilla.gdcproject.org/show_bug.cgi?id=52 --- Comment #11 from Iain Buclaw --- I've got a fix for this in the works. Setting CALL_EXPR_RETURN_SLOT_OPT on the call returning NRVO is all we needed in the end. -- You are receiving this mail because: You are watching all bug changes.
[Bug 52] NRVO not implemented
http://bugzilla.gdcproject.org/show_bug.cgi?id=52 --- Comment #12 from Ketmar Dark --- that's great! -- You are receiving this mail because: You are watching all bug changes.
[Bug 52] NRVO not implemented
http://bugzilla.gdcproject.org/show_bug.cgi?id=52 Iain Buclaw changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #13 from Iain Buclaw --- https://github.com/D-Programming-GDC/GDC/commit/b9bbf568c20d806bc8570c8cefe41bf57c729bb1 -- You are receiving this mail because: You are watching all bug changes.
[Bug 52] NRVO not implemented
http://bugzilla.gdcproject.org/show_bug.cgi?id=52 --- Comment #14 from Iain Buclaw --- Also added testcase. https://github.com/D-Programming-GDC/GDC/commit/1a75aa6e2280272735237bf640931cdc26fe8350 -- You are receiving this mail because: You are watching all bug changes.
[Bug 179] invalid code generation with -O2 for method returning ref
http://bugzilla.gdcproject.org/show_bug.cgi?id=179
--- Comment #6 from Iain Buclaw ---
Reduced:
---
struct SignalImpl
{
@disable this(this);
}
struct RestrictedSignal
{
SignalImpl mImpl;
void connect() { }
}
struct Signal
{
RestrictedSignal mRestricted;
}
class MyObject
{
Signal valueChangedSg;
ref RestrictedSignal valueChanged()
{
return valueChangedSg.mRestricted;
}
}
int main ()
{
MyObject a = new MyObject;
a.valueChanged().connect();
return 0;
}
--
You are receiving this mail because:
You are watching all bug changes.
[Bug 179] invalid code generation with -O2 for method returning ref
http://bugzilla.gdcproject.org/show_bug.cgi?id=179
--- Comment #7 from Iain Buclaw ---
There seems to be a key thing happening here:
---
struct SignalImpl
{
@disable this(this); // SignalImpl is now non-POD
}
---
Because of this, TypeFunction::toCtype sets TREE_ADDRESSABLE on functions
returning SignalImpl (which is correct behaviour, we do *not* want non-POD
types to return in registers).
However...
---
ref RestrictedSignal valueChanged()
{
return valueChangedSg.mRestricted; // returned by ref
}
---
Reference returns should not have TREE_ADDRESSABLE set as they are already
returning in memory.
--
You are receiving this mail because:
You are watching all bug changes.
[Bug 179] invalid code generation with -O2 for method returning ref
http://bugzilla.gdcproject.org/show_bug.cgi?id=179 Iain Buclaw changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Iain Buclaw --- https://github.com/D-Programming-GDC/GDC/commit/10bc8bcddc787d1134fc6da5602d4453f7a9f454 -- You are receiving this mail because: You are watching all bug changes.
[Bug 180] New: DMD -O is faster than GDC -O3 for byte and short math
http://bugzilla.gdcproject.org/show_bug.cgi?id=180 Bug ID: 180 Summary: DMD -O is faster than GDC -O3 for byte and short math Product: GDC Version: development Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: Normal Component: gdc Assignee: ibuc...@gdcproject.org Reporter: ket...@ketmar.no-ip.org Created attachment 84 --> http://bugzilla.gdcproject.org/attachment.cgi?id=84&action=edit test case using the attached test code, i got this results: for: dmd -O -inline -release tByte: 0.004,872 secs tShort: 0.006,896 secs tInt: 0.008,672 secs tLong: 0.036,864 secs for: gdc -march=native -O3 -frelease tByte: 0.008,830 secs tShort: 0.008,858 secs tInt: 0.008,267 secs tLong: 0.014,029 secs seems that DMD does better with bytes and shorts, while gdc has the same speed for bytes, shorts and ints. -- 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
http://bugzilla.gdcproject.org/show_bug.cgi?id=180 Ketmar Dark changed: What|Removed |Added CC||ket...@ketmar.no-ip.org Severity|normal |enhancement -- 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
http://bugzilla.gdcproject.org/show_bug.cgi?id=180 Ketmar Dark changed: What|Removed |Added Attachment #84 is|0 |1 obsolete|| --- Comment #1 from Ketmar Dark --- Created attachment 85 --> http://bugzilla.gdcproject.org/attachment.cgi?id=85&action=edit fixed testcase sorry, previous attachement was uncompilable. added fixed one. -- You are receiving this mail because: You are watching all bug changes.
[Bug 181] New: Missing tags for recent frontend merges
http://bugzilla.gdcproject.org/show_bug.cgi?id=181 Bug ID: 181 Summary: Missing tags for recent frontend merges Product: GDC Version: development Hardware: All OS: All Status: NEW Severity: normal Priority: Normal Component: gdc Assignee: ibuc...@gdcproject.org Reporter: pub...@dicebot.lv I recently got complaints about Arch Linux package providing 2.065 frontend version (for 4.9) while there is 2.066.1 available via website. However I don't see anything recent among https://github.com/D-Programming-GDC/GDC/releases I could use for building new package and using branch heads for that purpose is extremely fragile. -- You are receiving this mail because: You are watching all bug changes.
[Bug 181] Missing tags for recent frontend merges
http://bugzilla.gdcproject.org/show_bug.cgi?id=181 --- Comment #2 from Dicebot --- Thanks! -- You are receiving this mail because: You are watching all bug changes.
[Bug 181] Missing tags for recent frontend merges
http://bugzilla.gdcproject.org/show_bug.cgi?id=181 Iain Buclaw changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Iain Buclaw --- Added some lightweight tags for teh recent GCC-5.1 release. Might be worth periodically (bi-monthly?) checking for bumps to newer revisions. -- You are receiving this mail because: You are watching all bug changes.
[Bug 181] Missing tags for recent frontend merges
http://bugzilla.gdcproject.org/show_bug.cgi?id=181
Johannes Pfau changed:
What|Removed |Added
CC||johannesp...@gmail.com
--- Comment #3 from Johannes Pfau ---
@Iain Until now I always tagged the last commit on a frontend version. I.e.
v2.065_gcc4.9 is the last commit with 2.065, the next commit is on 2.066.
Of course this means the tags are always one release old. This is annoying for
packagers like Dicebot but it is useful if you want a specific frontend
version. This way the tag always gives the most recent ('best') commit for a
frontend version.
What does the git etiquette say about updating tags? Is it OK to update tags? I
think a standard fetch does not update tags so that's a drawback. And there's
probably not much benefit in using tags for packagers if we update them.
It's also hard to say when a commit qualifies for a tag. Except for the
first&last commit with a frontend version there's nothing special about any
commit. Why tag on "Implement Exception/Error chaining in unwind EH routines"
and not on "Bug 179 - Invalid code generation with -O2 for method returning
ref"? And as our tag is now on "Implement Exception/Error chaining in unwind EH
routines" does this mean that further update Archlinux packages do not pickup
updates till we have a 2.067 tag? What if somebody creates 2.065 packages
later. When he uses the tag he might miss further bugfix commits.
We could introduce arbitrary -snapshotN commits every now and then, but then
those are not very useful:
As our development model doesn't converge to a finished, stable
commit(/release) it's really hard to decide when we should tag. We're more or
less using a 'rolling release' development model.
--
You are receiving this mail because:
You are watching all bug changes.
[Bug 181] Missing tags for recent frontend merges
http://bugzilla.gdcproject.org/show_bug.cgi?id=181 --- Comment #4 from Dicebot --- Common approach is to have extra level of minor versions that "extends" the upstream (gcc in this case) and do smaller releases with those version bumps time to time. Changing tags is very bad. The very reason why I am asking for tags (as opposed to using branch heads) is to guarantee that same package script built 1 year later will result in exactly same thing packaged. It is also possible to pin to specific commit hashes of course but that will result in inconsistent functionality among distros as everyone will chose own arbitrary commit to stick to. -- You are receiving this mail because: You are watching all bug changes.
[Bug 181] Missing tags for recent frontend merges
http://bugzilla.gdcproject.org/show_bug.cgi?id=181 --- Comment #5 from Johannes Pfau --- That's more or less what I thought. But there's no guiding principle when to make those minor version bumps. In the end we could bump with every commit, every second commit, every week, It's completely arbitrary. -- You are receiving this mail because: You are watching all bug changes.
[Bug 181] Missing tags for recent frontend merges
http://bugzilla.gdcproject.org/show_bug.cgi?id=181 --- Comment #6 from Dicebot --- It is completely up to you. It is simply way to tell packager "prefer this commit" and "consider upgrading gdc". I think two most important cases are frontend version bumps and branch freezes. -- You are receiving this mail because: You are watching all bug changes.
[Bug 181] Missing tags for recent frontend merges
http://bugzilla.gdcproject.org/show_bug.cgi?id=181 --- Comment #7 from Iain Buclaw --- Perhaps we better make the next commit "upgrade to 2.067.1" then. :) -- You are receiving this mail because: You are watching all bug changes.
[Bug 182] New: Travis CI is brocken
http://bugzilla.gdcproject.org/show_bug.cgi?id=182 Bug ID: 182 Summary: Travis CI is brocken Product: GDC Version: 4.9.x Hardware: All OS: All Status: NEW Severity: normal Priority: Normal Component: gdc Assignee: ibuc...@gdcproject.org Reporter: ilyayaroshe...@gmail.com The problem is with http://gdcproject.org Simple files names like "gdc-4.9.2.tar.xz" are required. See Travis CI log at https://travis-ci.org/9il/atmosphere/jobs/60194069 -- You are receiving this mail because: You are watching all bug changes.
[Bug 183] New: ICE: in complete_ctor_at_level_p, at expr.c:5775 (ctor of struct containing union fails)
http://bugzilla.gdcproject.org/show_bug.cgi?id=183
Bug ID: 183
Summary: ICE: in complete_ctor_at_level_p, at expr.c:5775 (ctor
of struct containing union fails)
Product: GDC
Version: 4.9.x
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: Normal
Component: gdc
Assignee: ibuc...@gdcproject.org
Reporter: drug2...@bk.ru
If struct contains union of structs its ctor fails.
union Coord
{
struct
{
double x, y, z;
}
struct
{
double lon, lat, alt;
}
}
struct Foo
{
Coord coord;
this(double x, double y, double z)
{
this.coord.x = x;
this.coord.y = y;
this.coord.z = z;
}
}
void main()
{
auto foo = Foo(0, 0, 0);
}
if change Coord to
struct Coord
{
double x, y, z;
}
the code compiles.
--
You are receiving this mail because:
You are watching all bug changes.
[Bug 181] Missing tags for recent frontend merges
http://bugzilla.gdcproject.org/show_bug.cgi?id=181 --- Comment #8 from Iain Buclaw --- Kick-started "the big overhaul". https://github.com/D-Programming-GDC/GDC/pull/99 -- You are receiving this mail because: You are watching all bug changes.
[Bug 161] GDC prevents backend from removing dead functions
http://bugzilla.gdcproject.org/show_bug.cgi?id=161
Iain Buclaw changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |WONTFIX
--- Comment #2 from Iain Buclaw ---
This is the crux of the problem why we do what we do (snipped, shortened, and
with added clarity from std.exception).
private void bailOut() { assert(false); }
public T enforce(T value)
{
if (!value)
bailOut();
return value;
}
When compiling the module, 'private bailOut' is would be seen as unused, and so
considered as a candidate for removal. However, external modules that
instantiate 'public enforce' would indirectly need bailOut to exist.
I am aware that the spec says that 'private' in D is equivalent to 'static' in
C, but in practice, that it just doesn't work that way.
--
You are receiving this mail because:
You are watching all bug changes.
[Bug 161] GDC prevents backend from removing dead functions
http://bugzilla.gdcproject.org/show_bug.cgi?id=161 --- Comment #3 from Iain Buclaw --- (In reply to Iain Buclaw from comment #2) > > When compiling the module, 'private bailOut' is would be seen as unused, and > so considered as a candidate for removal. However, external modules that > instantiate 'public enforce' would indirectly need bailOut to exist. > Even if 'private bailOut' is not removed. It still requires that TREE_PUBLIC be set on the symbol so that it is accessible at link-time. -- You are receiving this mail because: You are watching all bug changes.
[Bug 157] using -O{1,2,3} together with -g causes ICE (seg fault)
http://bugzilla.gdcproject.org/show_bug.cgi?id=157 Iain Buclaw changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #1 from Iain Buclaw --- I assume this was a bug in 4.10 backend that's since been fixed in the 5.1 release. -- You are receiving this mail because: You are watching all bug changes.
[Bug 173] internal compiler error typeMerge
http://bugzilla.gdcproject.org/show_bug.cgi?id=173 --- Comment #1 from Iain Buclaw --- This looks like an upstream bug. https://issues.dlang.org/show_bug.cgi?id=14538 -- You are receiving this mail because: You are watching all bug changes.
[Bug 152] ICE, CtorDeclaration::semantic(Scope*): Assertion `tf && tf->ty == Tfunction' failed
http://bugzilla.gdcproject.org/show_bug.cgi?id=152 Iain Buclaw changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |UPSTREAM -- You are receiving this mail because: You are watching all bug changes.
[Bug 175] immutable override - error in error reporting
http://bugzilla.gdcproject.org/show_bug.cgi?id=175 Iain Buclaw changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |UPSTREAM --- Comment #2 from Iain Buclaw --- Yep, looks to be fixed in 2.066 -- You are receiving this mail because: You are watching all bug changes.
[Bug 183] ICE: in complete_ctor_at_level_p, at expr.c:5775 (ctor of struct containing union fails)
http://bugzilla.gdcproject.org/show_bug.cgi?id=183
Iain Buclaw changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #1 from Iain Buclaw ---
It appears that anonymous structs are not emitted at all. Meaning that we have
the following initialiser:
union { NAN, NAN, NAN }
When we are instead expecting:
union { { NAN, NAN, NAN } }
This is because unions can only have one value to initialise them, not three.
--
You are receiving this mail because:
You are watching all bug changes.
[Bug 173] internal compiler error typeMerge
http://bugzilla.gdcproject.org/show_bug.cgi?id=173 Iain Buclaw changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |UPSTREAM --- Comment #2 from Iain Buclaw --- And... it is being merged in: https://github.com/D-Programming-Language/dmd/pull/4636 -- You are receiving this mail because: You are watching all bug changes.
[Bug 184] New: TypeInfo.name strings don't get put into separate sections when compiling with -fdata-sections
http://bugzilla.gdcproject.org/show_bug.cgi?id=184
Bug ID: 184
Summary: TypeInfo.name strings don't get put into separate
sections when compiling with -fdata-sections
Product: GDC
Version: development
Hardware: All
OS: All
Status: NEW
Severity: major
Priority: Normal
Component: gdc
Assignee: ibuc...@gdcproject.org
Reporter: slavo5...@yahoo.com
Consider the following code:
***
module test;
long sys_write(long arg1, in void* arg2, long arg3) nothrow
{
long result;
asm
{
"syscall"
: "=a" result
: "a" 1,
"D" arg1,
"S" arg2,
"m" arg2,
"d" arg3
: "memory", "cc", "rcx", "r11";
}
return result;
}
void write(in string text) nothrow
{
sys_write(2, text.ptr, text.length);
}
void write(A...)(in A a) nothrow
{
foreach(t; a)
{
write(t);
}
}
final abstract class TestClass1 { }
final abstract class TestClass2 { }
final abstract class TestClass3 { }
final abstract class TestClass4 { }
final abstract class TestClass5 { }
final abstract class TestClass6 { }
final abstract class TestClass7 { }
final abstract class TestClass8 { }
final abstract class TestClass9 { }
extern(C) void main()
{
write("x");
}
**
Compile with:
-
gdc -static -frelease -fno-emit-moduleinfo -nophoboslib -nostdlib test.d
--entry=main -ffunction-sections -fdata-sections -Wl,--gc-sections -o test
Examining the .rodata section we see:
-
objdump -s -j .rodata test | grep "TestClass"
42edf0 74657374 2e546573 74436c61 73733100 test.TestClass1.
42ee40 74657374 2e546573 74436c61 73733200 test.TestClass2.
42ee90 74657374 2e546573 74436c61 73733300 test.TestClass3.
42eee0 74657374 2e546573 74436c61 73733400 test.TestClass4.
42ef30 74657374 2e546573 74436c61 73733500 test.TestClass5.
42ef80 74657374 2e546573 74436c61 73733600 test.TestClass6.
42efd0 74657374 2e546573 74436c61 73733700 test.TestClass7.
42f020 74657374 2e546573 74436c61 73733800 test.TestClass8.
42f070 74657374 2e546573 74436c61 73733900 test.TestClass9.
The "test.TestClassX." strings appears to be the TypeInfo.name field. If
compiling with -fdata-sections, these should be put into individual sections so
they can be garbage-collected by --gc-sections
However, although compiled with the -fdata-sections flag, they are always
placed in .rodata. I thought that this was related to GCC bug 192
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=192), but a recent patch to fix
that bug, did not solve this problem, therefore, I'm assuming this is an
artifact of DMD's/GDC's codegen.
Why this is a major problem
---
In my project, I make use of a highly-templated memory-mapped IO library to
describe the memory layout of registers statically. This results in 100s of
small static types. Since the TypeInfo.name strings are not garbage-collected,
the resulting binary results grows to over several 100k, when it should be less
than 10k. This prevents the binary from being small enough to load into flash
memory of some microcontrollers, when the vast majority of the data in the
binary is never used.
This problem was discussed on the GDC forum:
http://forum.dlang.org/post/m98a61$qp$1...@digitalmars.com
It appears we may get an -fno-rtti option soon which will alleviate this
problem temporarily, but when TypeInfo is eventually implemented and used in a
more full-featured runtime, this will become a major problem again.
--
You are receiving this mail because:
You are watching all bug changes.
[Bug 185] New: Wrong codegen is used for = expressions when there is a function as part of the rvalue.
http://bugzilla.gdcproject.org/show_bug.cgi?id=185
Bug ID: 185
Summary: Wrong codegen is used for = expressions when there
is a function as part of the rvalue.
Product: GDC
Version: 4.9.x
Hardware: x86_64
OS: Linux
Status: NEW
Severity: blocker
Priority: Normal
Component: gdc
Assignee: ibuc...@gdcproject.org
Reporter: li...@weka.io
Initially issue was found in a large Fiber based application, and narrowed down
to use the += operation around functions that later call yield.
The code was:
-
import std.stdio;
import core.thread;
enum numAddition = 3;
long globalSum = 0;
class DerivedFiber : Fiber
{
int index;
this(int _index)
{
index = _index;
super( &run );
}
private :
void run()
{
foreach(int k; 0 .. numAddition) {
globalSum += otherFunc();
writefln("DerivedFiber(%d) iteration %d globalSum is %d", index, k,
globalSum);
}
}
long otherFunc() {
yield();
return index;
}
}
int main()
{
Fiber derived1 = new DerivedFiber(1);
Fiber derived2 = new DerivedFiber(2);
foreach(j; 0 .. (numAddition+1)) {
derived1.call();
derived2.call();
}
assert(globalSum == (1+2)*numAddition);
return 0;
}
-
And the problem was that the compiler cached the globalSum value before the
yield, so concurrent changes were not possible.
Later, Johannes Pfau showed that generally = caches the "origin" even if
calling functions from other modules that may change the value without use of
fibers and yield at all.
"""
Iain: I think our codegen might be wrong. -fdump-tree-original:
@61 var_decl name: @76 mngl: @77 type: @60
scpe: @54 srcp: test.d:5
size: @39 algn: 64 used: 1
@62 plus_exprtype: @60 op 0: @61 op 1: @78
@78 call_exprtype: @60 fn : @96 0 : @23
Does GCC guarantee an evaluation order for plus_expr? This is
kinda weird btw. The rewrite might already happen in the frontend. If we
rewrite
globalSum += otherFunc();
to
globalSum = globalSum + otherFunc();
and follow strict LTR evaluation the code we generate is correct and
the code DMD generates is incorrect.
OTOH I don't know the exact rules for += but intuitively it should
first evaluate the RHS, then load the LHS.
"""
Then Iain Buclaw added:
"""
I can confirm that C codegen does infact emit 'foo += bar()' as 'foo
= bar() + foo'
Which only strengthens the reasoning to change it.
.
.
.
For commutative operations we can simply change the operands. For
non-commutative operations we'll have to explicitly evaluate the side
effects of the RHS before assigning. (-=, ...)
"""
--
You are receiving this mail because:
You are watching all bug changes.
[Bug 185] Wrong codegen is used for = expressions when there is a function as part of the rvalue.
http://bugzilla.gdcproject.org/show_bug.cgi?id=185 --- Comment #1 from Iain Buclaw --- FYI, we enforce strict LTR. The rewrite that was observed in C seems to be as a result of one of the passes in const-fold.c executed by the front-end, and not as a result of the front-end explicitly righting it in that way. -- You are receiving this mail because: You are watching all bug changes.
[Bug 186] New: Struct with union of struct and size_t field gets wrong optimization if initialized on same line as declaration
http://bugzilla.gdcproject.org/show_bug.cgi?id=186
Bug ID: 186
Summary: Struct with union of struct and size_t field gets
wrong optimization if initialized on same line as
declaration
Product: GDC
Version: 4.9.x
Hardware: x86_64
OS: Linux
Status: NEW
Severity: major
Priority: Normal
Component: gdc
Assignee: ibuc...@gdcproject.org
Reporter: li...@weka.io
Reproduced on commit b022dd4cac195d85e9c3a6a37f2501a07ade455a from April 7
(4.9.x branch)
The following code:
-
module test;
import std.stdio;
import std.string;
struct StructWithUnion {
union {
struct {
ubyte fieldA;
byte fieldB = -1;
byte fieldC = -1;
}
size_t _complete;
}
this(size_t complete) {
this._complete = complete;
}
}
void printSWUInfo(in StructWithUnion obj, byte fieldB) {
writefln("Struct is %s fieldA %s fieldB %s fieldC %s complete %s, explicit
fieldB %s", obj, obj.fieldA, obj.fieldB, obj.fieldC, obj._complete, fieldB);
}
int myFunction(size_t val)
{
StructWithUnion obj = StructWithUnion(val); // Fails when the
initialization happens on same line of variable declaration
printSWUInfo(obj, obj.fieldB);
writefln("Struct is %s fieldA %s fieldB %s fieldC is %s complete %s", obj,
obj.fieldA, obj.fieldB, obj.fieldC, obj._complete);
obj = StructWithUnion(val); // works ok when initialized without declaring.
printSWUInfo(obj, obj.fieldB);
writefln("Struct is %s fieldA %s fieldB %s fieldC is %s complete %s", obj,
obj.fieldA, obj.fieldB, obj.fieldC, obj._complete);
return 0;
}
int main()
{
return myFunction(2);
}
-
Produces the following output:
bash-4.3# /opt/gdc/bin/gdc -ggdb -O -ogtest test.d && ./gtest
Struct is const(StructWithUnion)(2, 0, 0, 2) fieldA 2 fieldB 0 fieldC 0
complete 2, explicit fieldB -1
Struct is StructWithUnion(2, 0, 0, 2) fieldA 0 fieldB -1 fieldC is -1 complete
2
Struct is const(StructWithUnion)(2, 0, 0, 2) fieldA 2 fieldB 0 fieldC 0
complete 2, explicit fieldB 0
Struct is StructWithUnion(2, 0, 0, 2) fieldA 2 fieldB 0 fieldC is 0 complete 2
You can see that in myFunction, after initializing obj on the same line fieldB
and fieldC should have been 0, but are actually -1.
When comparing the generated assembly of the call to printSWUInfo, the one of
line 25 (same line as declaration):
/mnt/test.d:25
404ca5: be ff ff ff ff mov$0x,%esi // second
argument is always -1
404caa: e8 0d ff ff ff callq 404bbc
<_D4test12printSWUInfoFxS4test15StructWithUniongZv>
No need to set %edi as it is already set from the function call.
Then on line 29 (initialization not on line of declaration):
404ca2: 48 89 fbmov%rdi,%rbx // Saving 'val' to %rbx
on entry
.
.
/mnt/test.d:29
404d3d: 41 89 dcmov%ebx,%r12d // preparing r12d for
fieldB calaulation
404d40: 66 41 c1 fc 08 sar$0x8,%r12w // Yuppie!
"calculating"
404d45: 44 89 e6mov%r12d,%esi
404d48: 48 89 dfmov%rbx,%rdi
404d4b: e8 6c fe ff ff callq 404bbc
<_D4test12printSWUInfoFxS4test15StructWithUniongZv>
---
So for some reason the optimizer ignores the need to calculate fieldB in the
case that the initialization was performed on the line of variable declaration.
--
You are receiving this mail because:
You are watching all bug changes.
[Bug 187] New: Nested struct that has non-padded array does not initialize fields correctly when compiled with optimizations
http://bugzilla.gdcproject.org/show_bug.cgi?id=187
Bug ID: 187
Summary: Nested struct that has non-padded array does not
initialize fields correctly when compiled with
optimizations
Product: GDC
Version: 4.9.x
Hardware: x86_64
OS: Linux
Status: NEW
Severity: normal
Priority: Normal
Component: gdc
Assignee: ibuc...@gdcproject.org
Reporter: li...@weka.io
Reproducible on commit b022dd4cac195d85e9c3a6a37f2501a07ade455a from April 7th
on the 4.9 branch.
Consider the following code:
---
module test;
import std.stdio;
align(1) struct Unpadded {
align(1) {
uint unpaddedA;
ushort unpaddedB;
}
}
struct StructWithUnpaddedArray {
Unpadded[3] unpaddedArray;
// If initializer differs than ubyte.init then it does get inititalized
// Naturally, the "= ubyte.init" part is not required for the bug to
reproduce
ubyte wontInitialize = ubyte.init;
}
struct OuterStruct {
StructWithUnpaddedArray interesting;
}
void prepareStack()
{
byte[255] stackGarbage;
foreach(i, ref b; stackGarbage) {
b = cast(byte)(-i);
}
}
void main()
{
prepareStack();
auto a = OuterStruct(StructWithUnpaddedArray());
writefln("Value is %s . wontInitialize is %s ", a,
a.interesting.wontInitialize);
}
---
When compiled with optimization, the wontInitialize field ends up being 194,
instead of 0 as by the D spec.
This is the minimal code that I was able to get that reproduces.
example output:
bash-4.3# /opt/gdc/bin/gdc -ggdb -O -ogtest test.d && ./gtest
Value is OuterStruct(StructWithUnpaddedArray([Unpadded(0, 0), Unpadded(0, 0),
Unpadded(0, 0)], 194)) . wontInitialize is 194
--
You are receiving this mail because:
You are watching all bug changes.
[Bug 188] New: Optimized GDC with no-bounds-checking skips operations in foreach if given statically
http://bugzilla.gdcproject.org/show_bug.cgi?id=188
Bug ID: 188
Summary: Optimized GDC with no-bounds-checking skips operations
in foreach if given statically
Product: GDC
Version: 4.9.x
Hardware: x86_64
OS: Linux
Status: NEW
Severity: critical
Priority: Normal
Component: gdc
Assignee: ibuc...@gdcproject.org
Reporter: li...@weka.io
Reproducible on commit b022dd4cac195d85e9c3a6a37f2501a07ade455a from April 7th
on the 4.9 branch.
Please consider the following code:
-
module test;
import std.stdio;
enum R = 4;
enum S = 2;
int main() {
uint[R+S] a = 6;
uint[R+S] b = 9;
writeln("a, b : ", a, b);
ushort c = 3;
foreach(i; 0..R) {
b[i .. (i+1)] += a[i .. (i+1)];
a[i .. (i+1)] = b[i .. (i+1)] ^ c;
}
writeln("After operation: a,b: ", a, b);
return 0;
}
-
And the following output, first from dmd, then gdc:
bash-4.3# dmd test.d -ofdtest && ./dtest
a, b : [6, 6, 6, 6, 6, 6][9, 9, 9, 9, 9, 9]
After operation: a,b: [12, 12, 12, 12, 6, 6][15, 15, 15, 15, 9, 9]
bash-4.3# /opt/gdc/bin/gdc -fno-bounds-check -O test.d -ogtest && ./gtest
a, b : [6, 6, 6, 6, 6, 6][9, 9, 9, 9, 9, 9]
After operation: a,b: [12, 6, 6, 6, 6, 6][15, 9, 9, 9, 9, 9] # WRONG!!!
When GDC compiles the code with static range in the foreach, only the first
index is being assigned and only the first calculation is being performed.
In this example there is also S set, but it reproduces perfectly without the S,
or when it's 0. I just added it to show that the code cannot be fixed with
foreach(i; 0 .. b.length).
I put two examples of operations (addition and xor), but it actually does not
matter. Any operation that I tried reproduces the problem (as long as there is
no function call in the foreach() ).
--
You are receiving this mail because:
You are watching all bug changes.
