[Issue 6670] Compiler seg fault using std.concurrency.atomicOp
http://d.puremagic.com/issues/show_bug.cgi?id=6670
Brad Roberts bra...@puremagic.com changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC||bra...@puremagic.com
AssignedTo|nob...@puremagic.com|bra...@puremagic.com
--- Comment #2 from Brad Roberts bra...@puremagic.com 2011-09-17 20:09:02 PDT
---
I'm not seeing a dmd crash with this bug (much like not seeing the crash in bug
6669), but I am seeing something odd:
import std.concurrency;
void main()
{
int a;
atomicOp!+=(a, 1);
}
yields:
./../../druntime/import/core/atomic.di(108): Error: cast(shared(const(int)))val
is not an lvalue
s/std.concurrency/core.atomic/
And it builds.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6670] Compiler seg fault using std.concurrency.atomicOp
http://d.puremagic.com/issues/show_bug.cgi?id=6670
--- Comment #3 from Brad Roberts bra...@puremagic.com 2011-09-17 21:01:43 PDT
---
My current reduction:
template isMutable(T)
{
enum isMutable = !is(T == const) !is(T == immutable);
}
unittest
{
static assert(isMutable!(shared const(int)[]));
}
int atomicLoad( ref const shared int val )
{
return 0;
}
void main()
{
int a;
atomicLoad(a);
}
$ dmd bug6670.d
bug6670.d(20): Error: cast(shared(const(int)))a is not an lvalue
Not sure why the unused isMutable template is required, nor why the unittest
block is required when -unittest isn't part of the dmd arguments, but they are
and without them the code compiles.
Don or Daniel, either of you want to take this? I took it because I originally
thought it was a iasm or backend bug, which are areas I'm more familiar with.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6670] Compiler seg fault using std.concurrency.atomicOp
http://d.puremagic.com/issues/show_bug.cgi?id=6670
yebblies yebbl...@gmail.com changed:
What|Removed |Added
CC||yebbl...@gmail.com
--- Comment #4 from yebblies yebbl...@gmail.com 2011-09-18 15:26:19 EST ---
Urrgh.
Reduced test case:
shared(const(int)[]) g;
int atomicLoad( ref const shared int val )
{
return 0;
}
void main()
{
int a;
atomicLoad(a);
}
Due to issue 5493, ref is completely ignored when looking at parameter type
matching. Therefore int matches const(shared(int)), when it really shouldn't.
This gets turned into cast(const(shared(int)))a
The compiler then optimizes cast(const(shared(int)))a, which it shouldn't do
when an lvalue is required. (like bug 2521)
Finally, a bug in CastExp::optimize uses constOf rather than
addMod(MODconst)/implicitConvTo=MATCHconst to see if the cast can be ignored,
and constOf's wacky behaviour interacts with the previous usage of
shared(const(int)) in the declaration of g.
So yeah, no segfault, and nothing to do with inline asm.
This bug is probably a dupe of bug 6669 and you've had the pleasure of
discovering a new one!
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6670] Compiler seg fault using std.concurrency.atomicOp
http://d.puremagic.com/issues/show_bug.cgi?id=6670 --- Comment #1 from Peter Alexander peter.alexander...@gmail.com 2011-09-14 13:49:26 PDT --- Actually, this is probably related to http://d.puremagic.com/issues/show_bug.cgi?id=6669 core.atomic uses a lot of inline asm, and atomicOp just causes those functions to be instantiated, triggering the other seg fault. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
