[Issue 5314] Wrong error message: struct within immutable member and postblit function
http://d.puremagic.com/issues/show_bug.cgi?id=5314
--- Comment #6 from Jonathan M Davis jmdavisp...@gmx.com 2010-12-06 00:21:15
PST ---
@nfxjfg
This program shows when init, a constructor, the postblit constructor, and
opAssign are used:
import std.stdio;
struct Foo
{
int a = 7;
this(int a)
{
this.a = a;
writefln(constructor: %s, this.a);
}
this(this)
{
writefln(postblit: %s, this.a);
}
/+
Foo opAssign(const ref Foo other)
{
this.a = other.a;
writefln(opAssign: %s, this.a);
return this;
}
+/
}
void main()
{
writefln(%s(%s): ---, __FILE__, __LINE__);
Foo a;
writefln(%s(%s): ---, __FILE__, __LINE__);
auto b = Foo(6);
writefln(%s(%s): ---, __FILE__, __LINE__);
auto c = a;
writefln(%s(%s): ---, __FILE__, __LINE__);
b = c;
writefln(%s(%s): ---, __FILE__, __LINE__);
}
The output is:
test.d(29): ---
test.d(31): ---
constructor: 6
test.d(33): ---
postblit: 7
test.d(35): ---
postblit: 7
test.d(37): ---
Notice that assignment uses the postblit constructor. If you uncomment
opAssign(), then you get this instead:
test.d(29): ---
test.d(31): ---
constructor: 6
test.d(33): ---
postblit: 7
test.d(35): ---
opAssign: 7
test.d(37): ---
Now, assignment uses opAssign(). The problem with having an immutable member
variable and a postblit constructor is that you cannot reassign that member
variable. That portion of the struct cannot be altered.
If I changed the code to
import std.stdio;
struct Foo
{
immutable int a;
this(int a) immutable
{
this.a = a;
writefln(constructor: %s, this.a);
}
}
void main()
{
writefln(%s(%s): ---, __FILE__, __LINE__);
Foo a;
writefln(%s(%s): ---, __FILE__, __LINE__);
auto b = Foo(6);
writefln(%s(%s): ---, __FILE__, __LINE__);
auto c = a;
writefln(%s(%s): ---, __FILE__, __LINE__);
b = c;
writefln(%s(%s): ---, __FILE__, __LINE__);
}
then it fails to compile, giving the message
test.d(24): Error: variable test.main.b cannot modify immutable
The line b = c is illegal. Now, the line auto c = a is still legal, and you
could arguably allow a postblit constructor which didn't alter the immutable
member variables, but it does get a bit odd. You could arguably even allow for
assignment via opAssign() as long as the immutable member variable isn't
altered, but then it's probably not really copying, which would not be good.
So, I suppose that a postblit could be allowed in a struct with an immutable
member variable, but you couldn't assign to it or do a deep copy or do anything
with it that you'd normally do in a postblit constructor (though whether or not
that's a problem is debatable). But the compiler would have to be smart enough
to realize that having a postblit constructor didn't allow for assignment for
structs with immutable member variables, which may or may not be
straightforward, depending on how the compiler decides that it cannot do an
assignment to a struct with an immutable member variable.
All in all, copying structs with immutable member variables does tend to get a
bit funny. I suppose that a postblit constructor _could_ be allowed, but it is
a bit odd. Assignment certainly can't be allowed, and the postblit constructor
is assignment of a sort, but it could still work as long as it's only used when
constructing a variable. So, I don't know what the correct behavior is.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5094] No implicit conversion with alias property this
http://d.puremagic.com/issues/show_bug.cgi?id=5094 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #2 from Walter Bright bugzi...@digitalmars.com 2010-12-06 00:20:04 PST --- http://www.dsource.org/projects/dmd/changeset/786 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3659] Too much exegesis on opEquals
http://d.puremagic.com/issues/show_bug.cgi?id=3659 Don clugd...@yahoo.com.au changed: What|Removed |Added Keywords||rejects-valid, spec CC||clugd...@yahoo.com.au Version|unspecified |D2 Severity|normal |blocker --- Comment #6 from Don clugd...@yahoo.com.au 2010-12-06 00:38:51 PST --- Raising severity, as I think this is one of the crucial unresolved issues in the const system. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5100] -O Degrades performance of loop statements
http://d.puremagic.com/issues/show_bug.cgi?id=5100 Don clugd...@yahoo.com.au changed: What|Removed |Added CC||clugd...@yahoo.com.au --- Comment #3 from Don clugd...@yahoo.com.au 2010-12-06 01:20:51 PST --- Cannot reproduce. On Windows, for both test cases, without -O it's about 5 seconds (does an INC and CMP of a stack variable). With -O it is about 1 second (just does INC and CMP of EAX). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3971] Syntax semantics for array assigns
http://d.puremagic.com/issues/show_bug.cgi?id=3971 Denis Derman denis.s...@gmail.com changed: What|Removed |Added CC||denis.s...@gmail.com --- Comment #15 from Denis Derman denis.s...@gmail.com 2010-12-06 01:26:24 PST --- (In reply to comment #7) You are right, the c=a; case can be allowed, it can just copy the ptr and length of the static array inside the struct of the dynamic array (this is how D currently works). Thank you for spotting it. Is it really the way D currently works? Doesn't it dup the static array instead? I thought static ones were on the stack while dynamic ones were on the heap. Denis -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5326] GC -- 99% CPU in gc@gcx@Gcx@mark()
http://d.puremagic.com/issues/show_bug.cgi?id=5326 nfx...@gmail.com changed: What|Removed |Added CC||nfx...@gmail.com --- Comment #1 from nfx...@gmail.com 2010-12-06 02:05:55 PST --- That's somewhat excpected. The mark() function is the core of the garbage collector, where it basically follows all references in the program's heap. void[] arrays can potentially contain references, so the GC has to mark() these as well. (Why are you using void[]? 10 dollars on you have no real reason.) What makes things worse: each time there's a pointer into a large memory block, the GC has to do a linear scan to find the beginning of the memory block. And you are alocating LARGE blocks (32k pages!), so that might become significant. I think what's happening is that your heap is exploding due to false pointers. The memory allocations are so large that there's always something that looks like a pointer pointing into it, so it never gets free'd. A larger heap means higher collection times. So, this is probably not a bug. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5326] GC -- 99% CPU in gc@gcx@Gcx@mark()
http://d.puremagic.com/issues/show_bug.cgi?id=5326 --- Comment #2 from nfx...@gmail.com 2010-12-06 02:15:59 PST --- PS: scope doesn't work on arrays. Your example code never explicitly free's the memory. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5294] -O optimization breaks for loop
http://d.puremagic.com/issues/show_bug.cgi?id=5294 --- Comment #5 from bearophile_h...@eml.cc 2010-12-06 03:15:42 PST --- Automatic fuzzy testing like this one allows to discover compiler bugs like that: http://gcc.gnu.org/wiki/summit2010?action=AttachFiledo=viewtarget=regehr_gcc_summit_2010.pdf -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3971] Syntax semantics for array assigns
http://d.puremagic.com/issues/show_bug.cgi?id=3971 Stewart Gordon s...@iname.com changed: What|Removed |Added CC||s...@iname.com --- Comment #16 from Stewart Gordon s...@iname.com 2010-12-06 03:22:53 PST --- (In reply to comment #0) a[] = b[]; static dynamic static OK1 OK1 dynamic OK1 OK1 a = b[];static dynamic static Err Err dynamic Err Err a[] = b;static dynamic static Err Err dynamic Err Err a = b; static dynamic static Err2Err dynamic Err OK2 I'm not sure I like this. What, exactly, would be the semantic difference between the rvalue b and the rvalue b[]? Currently, they are the same, and changing this might be confusing. int i; a=i; static dynamic Err Err int i; a[] = i;static dynamic OK3 OK3 This is how D behaves currently. Key: Err = Syntax error OK1 = Copies all items from an array to the oter. OK2 = Copies just the stuct of the dynamic array, array body not copied. OK3 = Copies the value to all the items of the array. Err2 = Syntax error, becase there is no reference to copy, better to keep tidy the language. Making it a _syntax_ error cannot be done, because D's grammar is context-free by design. You can see that this too is disallowed: int a, b; a = b; ??? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5294] -O optimization breaks for loop
http://d.puremagic.com/issues/show_bug.cgi?id=5294 --- Comment #6 from Stephan Dilly s...@extrawurst.org 2010-12-06 03:32:26 PST --- (In reply to comment #5) Automatic fuzzy testing like this kidding me ? I wish it would have been found by any test, it appeared in an actual project. while i converted some C code to D i wondered a lot until i finally reduced it to this testcase. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5327] New: Immutable correctness is broken
http://d.puremagic.com/issues/show_bug.cgi?id=5327
Summary: Immutable correctness is broken
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: zan77...@nifty.com
--- Comment #0 from SHOO zan77...@nifty.com 2010-12-06 03:53:59 PST ---
This code shouldn't work:
--
import std.stdio;
struct ID
{
immutable int value;
}
struct Data
{
ID id;
}
void main()
{
Data data = Data(ID(1));
immutable int* val = data.id.value;
writeln(*val); // 1
data = Data(ID(2)); // - This line shouldn't be allowed.
writeln(*val); // 2
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5328] New: The addressof-expression that should be rejected is accepted
http://d.puremagic.com/issues/show_bug.cgi?id=5328
Summary: The addressof-expression that should be rejected is
accepted
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Keywords: accepts-invalid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: rayerd@gmail.com
--- Comment #0 from Haruki Shigemori rayerd@gmail.com 2010-12-06 08:56:21
PST ---
// a.d
void f(void function() m) { m(); }
class A
{
this()
{
f(A.m); // rejects-invalid = OK
}
/+static+/ void m() {}
}
void main()
{
f(A.m); // accepts-invalid = BAD!!
}
$ dmd a.d
a.d(7): Error: function a.f (void function() m) is not callable using argument
types (void delegate())
a.d(7): Error: cannot implicitly convert expression (this.A.m) of type void
delegate() to void function()
You will get the following result if you remove A.this constructor.
$ dmd a.d
object.Error: Access Violation
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5328] The addressof-expression that should be rejected is accepted
http://d.puremagic.com/issues/show_bug.cgi?id=5328 nfx...@gmail.com changed: What|Removed |Added CC||nfx...@gmail.com Version|D2 |D1 D2 OS/Version|Windows |All --- Comment #1 from nfx...@gmail.com 2010-12-06 09:21:27 PST --- It's a feature, not a bug. You can take the address of methods without providing an object reference (i.e. no this pointer, or what would be the context member of method delegates). The returned function pointer is simply what the class' vtable contains. The function signature is the same as the signature of a proper delegate to the method. It doesn't make sense to call the function pointer by itself (wrong calling convention, this pointer is missing), but it's useful for other things. E.g. you can use the type of the function pointer value in meta programming to get the method's signature. That's very important for meta programming. You could just instantiate a new object, and then analyze the delegate, but why should you need to construct a dummy object? For the actual value of the function pointer there are also valid uses. Think about serialization of delegates, for example. Note that the delegate property .funcptr return a similarly non-sensical function pointer. The context is missing and the calling convention is incompatible. If you call it, you get an access violation as well. What is happening here is that the language designers just didn't feel like introducing a dedicated separate function type for this purpose. Instead, they reused the normal function pointer type, even if calling it makes no sense. Basically it's a quick language hack that endangers type-safety and confuses users. Btw. the code inside A.this is not accepted, because the A. from A.m just qualifies the member m. Inside the ctor it's exactly the same as writing m. And m is a delegate, not a function. So everything is alright. Though this slight syntactic ambiguity is another hint that D as a language is actually quite unorthogonal and full of special cases. Maybe typeof(this).m in the ctor would do the same as the A.m in main()? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3554] Ddoc generates invalid output for documentation comments with non paired parantheses
http://d.puremagic.com/issues/show_bug.cgi?id=3554 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED Summary|Ddoc generats invalid |Ddoc generates invalid |output for documentation|output for documentation |comments with non paired|comments with non paired |paranthasis |parantheses --- Comment #16 from Walter Bright bugzi...@digitalmars.com 2010-12-06 11:29:44 PST --- http://www.dsource.org/projects/dmd/changeset/788 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5294] -O optimization breaks for loop
http://d.puremagic.com/issues/show_bug.cgi?id=5294
--- Comment #7 from Don clugd...@yahoo.com.au 2010-12-06 11:53:27 PST ---
Bearophile -- That's an interesting link. Currently, DMD back-end bugs are
being found at the rate of about 3 per year. So yes, fuzzy testing of DMC could
probably flush out some backend bugs a bit faster.
---
Here's what's happening. First, in this code:
for (int i = 0; i 10; i++) {
foo(i * 5 - 6);
}
it sees that i and 10 are always =0, so the signed comparison i 10 is
replaced with an unsigned one. (This happens in the backend in constprop() ).
Then, while dealing with loop invariants, it rewrites the loop into:
for (int _i2 = -6; _i2 10*5 - 6; _i2 += 5)
{
foo(_i2);
}
Fine. Except that it had changed the comparison into an unsigned one!
Particularly interesting is the case where the call is foo(i*5-50);
Then, the loop becomes:
for (int _i2 = -50; _i2 0; _i2 += 5)
Since an unsigned value is NEVER less than zero, it just drops the loop
completely!
Nasty.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 1382] memory allocated for arrays in CTFE functions during compilation is not released
http://d.puremagic.com/issues/show_bug.cgi?id=1382
Rob Jacques sandf...@jhu.edu changed:
What|Removed |Added
CC||sandf...@jhu.edu
--- Comment #7 from Rob Jacques sandf...@jhu.edu 2010-12-06 12:09:04 PST ---
I just came across this bug while working on improving std.variant: the
combination of templates + ctfe + unittests resulted in out of memory errors.
I've also traced down another issue (I don't know if it should be filed
separately or not):
It appears that _any_ access of an array variable allocates ram, resulting in
drastically slower compile times (+55 seconds) and excess memory usage (30+ mb
in this case using DMD 2.050)
string ctfeTest() {
char[] result;
result.length = ushort.max;
char c;
for(size_t i = 0; i result.length; i++) {} // Allocates
for(size_t i = 0; i ushort.max; i++) {}// Doesn't allocate
for(size_t i = 0; i ushort.max; i++) { // Allocates
c = result[i];
}
for(size_t i = 0; i ushort.max; i++) { // Doesn't allocate
c = cast(ubyte)('A' + i%26);
}
return cast(string)result;
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 2954] [tdpl] Appalling bug in associative arrays (D2 only)
http://d.puremagic.com/issues/show_bug.cgi?id=2954 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #7 from Walter Bright bugzi...@digitalmars.com 2010-12-06 12:21:48 PST --- http://www.dsource.org/projects/dmd/changeset/789 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5100] -O Degrades performance of loop statements
http://d.puremagic.com/issues/show_bug.cgi?id=5100 --- Comment #4 from Iain Buclaw ibuc...@ubuntu.com 2010-12-06 14:51:32 PST --- objdump without -O on Linux: push %ebp mov%esp,%ebp sub$0x4,%esp movl $0x0,-0x4(%ebp) cmpl $0x7fff,-0x4(%ebp) jge1c _Dmain+0x1c addl $0x1,-0x4(%ebp) jmpd _Dmain+0xd xor%eax,%eax leave ret objdump with -O on Linux push %ebp mov%esp,%ebp xor%eax,%eax add$0x1,%eax cmp$0x7fff,%eax jb 5 _Dmain+0x5 pop%ebp xor%eax,%eax ret Looks to be same as what Don said that was on his Windows box. Wonder why Linux is slower... (must be a quirk, that or my Intel Atom CPU is to blame). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5278] DMD generates programs that immediately segfault.
http://d.puremagic.com/issues/show_bug.cgi?id=5278
--- Comment #3 from Chad Joan chadj...@gmail.com 2010-12-06 18:12:22 PST ---
(In reply to comment #2)
Something looks wrong with your 32 bit gcc installation. Notice that gcc is
invoking the 64 bit linker. Can you successfully build any 32 bit C apps with
gcc? I'm going to guess no.
Good thought. I still seem to be able to build 32 bit C apps though:
c...@hugin ~/cprojects/ctesting $ gcc trivial.c -o trivial
c...@hugin ~/cprojects/ctesting $ file trivial
trivial: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically
linked (uses shared libs), for GNU/Linux 2.6.9, not stripped
c...@hugin ~/cprojects/ctesting $ ./trivial
c...@hugin ~/cprojects/ctesting $ gcc trivial.c -m32 -o trivial
c...@hugin ~/cprojects/ctesting $ file trivial
trivial: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped
c...@hugin ~/cprojects/ctesting $ ./trivial
c...@hugin ~/cprojects/ctesting $ cat trivial.c
int main(int argc, char *argv[])
{
return 0;
}
I checked dmd 2.050 at the same time just to make sure this isn't because I
changed my system config. It still produces segfaulting executables. I have
encountered another program that I didn't expect to segfault but did: the Gish
demo (http://www.chroniclogic.com/gish_download.htm). I don't know if it's
related because the segfault is such a terribly vague error and I don't feel
like learning how to disassemble executables again right now :/ If someone
wants to point me in the right directions to do that though, I wouldn't mind.
So hey, maybe there is something special about my system that makes things
crashy, but it'd be nice if the D executables could run on my system without
crashing like all of the other executables on my system that don't crash.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5278] DMD generates programs that immediately segfault.
http://d.puremagic.com/issues/show_bug.cgi?id=5278 --- Comment #4 from Brad Roberts bra...@puremagic.com 2010-12-06 18:38:25 PST --- Try gcc -v trivial.c -m32 -o trivial to see which linker is being invoked in the working 32 bit case. Also try gcc -v trivial.c -o trivial -m32 to closer match the way dmd is invoking gcc. Which linker is being invoked now? I just tried those experiments on my box, and both forms correctly built 32 bit binaries. Another thing to do to try to gather more information, on the dmd command line, add: -L-v. That should be enough to show that collect2 is being invoked with -m elf_i386. For even more details, try running dmd with: -L-v -L-Wl,-v. That will add another -v down at the ld command which will give even more output, showing that ld is being invoked with -m elf_i386 as well. I assure you that dmd produces proper 32 bit executables on my linux x86_64 box. So, the exercise here is to figure out what's different, why, and how to resolve it. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5278] DMD generates programs that immediately segfault.
http://d.puremagic.com/issues/show_bug.cgi?id=5278 --- Comment #5 from Chad Joan chadj...@gmail.com 2010-12-06 19:35:47 PST --- Alright, here goes: c...@hugin ~/cprojects/ctesting $ gcc -v trivial.c -m32 -o trivial Reading specs from /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/specs Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.3.2-r3/work/gcc-4.3.2/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.2 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.2 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.2/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.2/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --enable-nls --without-included-gettext --with-system-zlib --disable-werror --enable-secureplt --enable-multilib --enable-libmudflap --disable-libssp --disable-libgomp --enable-checking=release --disable-libgcj --enable-languages=c,c++,treelang --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo Hardened 4.3.2-r3 p1.6, pie-10.1.5' Thread model: posix gcc version 4.3.2 (Gentoo Hardened 4.3.2-r3 p1.6, pie-10.1.5) COLLECT_GCC_OPTIONS='-v' '-m32' '-o' 'trivial' '-mtune=generic' /usr/libexec/gcc/x86_64-pc-linux-gnu/4.3.2/cc1 -quiet -v -imultilib 32 trivial.c -fPIE -fno-strict-overflow -quiet -dumpbase trivial.c -m32 -mtune=generic -auxbase trivial -version -o /tmp/cc4qEg6K.s ignoring nonexistent directory /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../x86_64-pc-linux-gnu/include #include ... search starts here: #include ... search starts here: /usr/local/include /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/include /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/include-fixed /usr/include End of search list. GNU C (Gentoo Hardened 4.3.2-r3 p1.6, pie-10.1.5) version 4.3.2 (x86_64-pc-linux-gnu) compiled by GNU C version 4.3.2, GMP version 4.3.2, MPFR version 2.4.2-p3. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: e8faf928abdbcb1acb2166e18d14ae3d COLLECT_GCC_OPTIONS='-v' '-m32' '-o' 'trivial' '-mtune=generic' /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../x86_64-pc-linux-gnu/bin/as -V -Qy --32 -o /tmp/ccEd2Qcf.o /tmp/cc4qEg6K.s GNU assembler version 2.20.1 (x86_64-pc-linux-gnu) using BFD version (GNU Binutils) 2.20.1.20100303 COMPILER_PATH=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.3.2/:/usr/libexec/gcc/x86_64-pc-linux-gnu/4.3.2/:/usr/libexec/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/:/usr/lib/gcc/x86_64-pc-linux-gnu/:/usr/libexec/gcc/x86_64-pc-linux-gnu/4.3.2/:/usr/libexec/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/:/usr/lib/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../x86_64-pc-linux-gnu/bin/ LIBRARY_PATH=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/32/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/32/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../lib32/:/lib/../lib32/:/usr/lib/../lib32/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../x86_64-pc-linux-gnu/lib/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-m32' '-o' 'trivial' '-mtune=generic' /usr/libexec/gcc/x86_64-pc-linux-gnu/4.3.2/collect2 --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -pie -z now -o trivial /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../lib32/Scrt1.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../lib32/crti.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/32/crtbeginS.o -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/32 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/32 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../lib32 -L/lib/../lib32 -L/usr/lib/../lib32 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../x86_64-pc-linux-gnu/lib -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../.. /tmp/ccEd2Qcf.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/32/crtendS.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/../../../../lib32/crtn.o c...@hugin ~/cprojects/ctesting $ ./trivial c...@hugin ~/cprojects/ctesting $ c...@hugin ~/cprojects/ctesting $ gcc -v trivial.c -o trivial -m32 Reading specs from /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/specs Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.3.2-r3/work/gcc-4.3.2/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.2 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.2 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.2/man
[Issue 5278] DMD generates programs that immediately segfault.
http://d.puremagic.com/issues/show_bug.cgi?id=5278 --- Comment #6 from Brad Roberts bra...@puremagic.com 2010-12-06 20:05:09 PST --- Does this bug report shed any light, specifically the part about changing the CHOST towards the bottom of the report? (I'm not a gentoo user, just using google to investigate similar issues). http://bugs.gentoo.org/show_bug.cgi?id=332663 If that's not it, then I'm running out of obvious things to check. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5294] -O optimization breaks for loop
http://d.puremagic.com/issues/show_bug.cgi?id=5294 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #8 from Walter Bright bugzi...@digitalmars.com 2010-12-06 22:41:10 PST --- For optimizer spelunkers, if you compile dmd with debug on, and compile with: -O --c you'll get reports of the various optimizations done. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5328] The addressof-expression that should be rejected is accepted
http://d.puremagic.com/issues/show_bug.cgi?id=5328 Don clugd...@yahoo.com.au changed: What|Removed |Added CC||clugd...@yahoo.com.au --- Comment #2 from Don clugd...@yahoo.com.au 2010-12-06 23:35:07 PST --- (In reply to comment #1) It's a feature, not a bug. You can take the address of methods without providing an object reference (i.e. no this pointer, or what would be the context member of method delegates). What is happening here is that the language designers just didn't feel like introducing a dedicated separate function type for this purpose. Instead, they reused the normal function pointer type, even if calling it makes no sense. Basically it's a quick language hack that endangers type-safety and confuses users. Are you sure this is an intentional design decision, and not just an oversight? Was it discussed by Walter and Andrei in the newsgroup? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5278] DMD generates programs that immediately segfault.
http://d.puremagic.com/issues/show_bug.cgi?id=5278 --- Comment #7 from Chad Joan chadj...@gmail.com 2010-12-06 23:44:30 PST --- (In reply to comment #6) Does this bug report shed any light, specifically the part about changing the CHOST towards the bottom of the report? (I'm not a gentoo user, just using google to investigate similar issues). http://bugs.gentoo.org/show_bug.cgi?id=332663 If that's not it, then I'm running out of obvious things to check. I'm afraid not. I haven't changed my CHOST; it's x86_64-pc-linux-gnu like always. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
