Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixes for two important CTFE regressions #37

Merged
merged 5 commits into from Apr 30, 2011

Conversation

donc
Copy link
Collaborator

@donc donc commented Apr 20, 2011

The first patch entirely removes the hackish, limited constant folding for $ from the initial semantic pass, into the constant folding pass where it belongs. (Incidentally, the comments for __dollar in the code were completely wrong -- it isn't always a constant!)

The second patch allows array reference assignment to members of structs, which in 2.052 would always compile, and occasionally generate correct code . Now it should actually work.

Don Clugston added 3 commits April 20, 2011 16:13
Now that $ is constant-folded correctly during the optimize step, the limited
constant-folding in dsymbol can be removed. It had the effect of creating
__dollar=0 in zombie cases where constant folding wasn't quite possible.
A big mess.

Here's a very simple new scheme: __dollar is still initialized for tuples, but
for arrays, it is ALWAYS void-initialized. Later, it might be turned into an
integer in the optimize step; otherwise, it becomes a runtime value.
The implementation now shares most of the same code as array variable
assignment.
@jmdavis
Copy link
Member

jmdavis commented Apr 23, 2011

Maybe it's something with the setup on my machine, but when I dmd with this patch on Linux, I get this error:

g++ -m32 -c -Wno-deprecated -Wstrict-aliasing -D__near= -D__pascal= -fno-exceptions -O2 -Iroot -D__I86__=1 -DMARS=1 -DTARGET_LINUX=1 -D_DH interpret.c
interpret.c: In member function ‘Expression* BinExp::interpretAssignCommon(InterState_, CtfeGoal, Expression_ ()(Type, Expression_, Expression_), int)’:
interpret.c:2681:58: error: lvalue required as left operand of assignment
make: *** [interpret.o] Error 1

@donc
Copy link
Collaborator Author

donc commented Apr 23, 2011

That's weird. So g++ thinks this isn't an lvalue (line 2681) ?
(Expression *)se3->elements->data[se_indx] = newval;
Does it compile if you change it to:
(Expression *)(se3->elements->data[se_indx]) = newval;

@WalterBright
Copy link
Member

Some compilers don't like a cast on the lvalue.

@WalterBright
Copy link
Member

Also, what happened to the "merge help" button?

@WalterBright
Copy link
Member

what's the git pull command for this? Damn merge help button is gone.

This caused a foreach CTFE regression, and also refused code like
int[]a=null; int [] b = a[0..$];
@donc
Copy link
Collaborator Author

donc commented Apr 23, 2011

I've found that this doesn't fix all cases. For example, this fails with another "__dollar cannot be read at compile time" message.
int[] a = null;
int [] b = a[0..$];
This is the same bug that causes the foreach() regression which David found.
I'll add an extra commit to this once it finishes running through the test suite.

@jmdavis
Copy link
Member

jmdavis commented Apr 23, 2011

No, additional parens don't fix the problem on line 2687 of interpret.c, whether I put them around the lvalue or around both the lvalue and the cast. I'm guessing that you're going to have to cast the value on the right rather than the left. Also, that last check in seems to make the compilation of interpret.c fail even more on my machine:

g++ -m32 -c -Wno-deprecated -Wstrict-aliasing -D__near= -D__pascal= -fno-exceptions -O2 -Iroot -D__I86__=1 -DMARS=1 -DTARGET_LINUX=1 -D_DH interpret.c
interpret.c: In member function ‘Expression* BinExp::interpretAssignCommon(InterState_, CtfeGoal, Expression_ ()(Type, Expression_, Expression_), int)’:
interpret.c:2687:58: error: lvalue required as left operand of assignment
interpret.c: In member function ‘virtual Expression* SliceExp::interpret(InterState_, CtfeGoal)’:
interpret.c:3649:1: error: jump to label ‘Lcant’
interpret.c:3625:14: error: from here
interpret.c:3636:16: error: crosses initialization of ‘uinteger_t iupr’
interpret.c:3635:16: error: crosses initialization of ‘uinteger_t ilwr’
interpret.c:3649:1: error: jump to label ‘Lcant’
interpret.c:3622:14: error: from here
interpret.c:3636:16: error: crosses initialization of ‘uinteger_t iupr’
interpret.c:3635:16: error: crosses initialization of ‘uinteger_t ilwr’
interpret.c:3649:1: error: jump to label ‘Lcant’
interpret.c:3613:14: error: from here
interpret.c:3636:16: error: crosses initialization of ‘uinteger_t iupr’
interpret.c:3635:16: error: crosses initialization of ‘uinteger_t ilwr’
interpret.c:3649:1: error: jump to label ‘Lcant’
interpret.c:3594:14: error: from here
interpret.c:3636:16: error: crosses initialization of ‘uinteger_t iupr’
interpret.c:3635:16: error: crosses initialization of ‘uinteger_t ilwr’
make: *_* [interpret.o] Error 1

I don't know what version of gcc/g++ that you're using, but it may be that mine is more recent and pickier. It claims to be

g++ (GCC) 4.5.2 20110127 (prerelease)

Or perhaps you just built it on Windows with dmc and dmc isn't as picky about this particular case. In either case, it's failing to build on my machine.

@braddr
Copy link
Member

braddr commented Apr 24, 2011

The pull help is linked just above the text entry box for comments:

Comment on this pull request (Help) <-- it's not help for text entry, it's help for the whole pull process.

@donc
Copy link
Collaborator Author

donc commented Apr 25, 2011

Jim, Walter already answered it. Bizarrely, g++ can't handle casts on lvalues, even when it's a no-op. You can remove the cast entirely.
se3->elements->data[se_indx] = newval;

WalterBright added a commit that referenced this pull request Apr 30, 2011
Fixes for two important CTFE regressions
@WalterBright WalterBright merged commit 0c9c52c into dlang:master Apr 30, 2011
@jmdavis
Copy link
Member

jmdavis commented Apr 30, 2011

I would point out that the error that I listed before with the gotos is still there, and not only is it failing on my box, it's now failing on most of the autotesters. So, this merge broke the dmd build.

@WalterBright
Copy link
Member

Things definitely are a mess right now. FreeBSD's unit tests don't pass datetime, and as far as I know never passed. Druntime won't build on Linux due to core.atomic changes. Unit tests on the latest Phobos hang on Windows. Now this (though this should be easily fixable, as g++ cries wolf a lot about branching past initializations).

@jmdavis
Copy link
Member

jmdavis commented Apr 30, 2011

Hmm. I thought that std.datetime had been passing on FreeBSD. If not, it would be good to know what's broken about it so that I can fix it (assuming that it's not a compiler error). In either case, there are definitely several issues which need to be ironed out before we can really think about doing another release.

@WalterBright
Copy link
Member

Pushed a fix for the goto problem.

@braddr
Copy link
Member

braddr commented Apr 30, 2011

@jmdavis
Copy link
Member

jmdavis commented Apr 30, 2011

@WalterBright dmd does now build on my box thanks to your goto fix.

@braddr Oh yes. I'd forgotten about that. I never saw it in any of my searches because it doesn't mention std.datetime. The code's fine, but the test needs to be fixed. So, it's a problem but far from critical. And it's going to be entertaining to find the appropriate test there, given the variations in behaviour. Bleh. Well, at least it's on my radar again.

@WalterBright
Copy link
Member

It is a problem for me because I cannot run my build/test scripts on FreeBSD.

@jmdavis
Copy link
Member

jmdavis commented Apr 30, 2011

Why? I wouldn't have thought that whether core.time's unit tests ran would affect anything else. Regardless, I can just disable the test for now if it's causing problems for you and then re-enable it once I've got it figured out.

@braddr
Copy link
Member

braddr commented Apr 30, 2011

Can we move this off github onto the mailing list? It has nothing to do with this pull request and is just cluttering things up.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
4 participants