Merge with 2.065 Release #76
Conversation
|
:) |
|
Simply converting toIR into a visitor is taking a long time alone because:
|
|
IIRC the rest of 2.065 should be easy... in the sense that the next 1K lines of code changes will be done by someone else and not me. Hurrah! |
|
Well, at least it reduces the frontend diff. |
|
It also reduces complexity of glue. Wasn't too nice handling things in 3 different places (1 in front end, 2 in glue) |
|
Hmm... it would be nice if the ARM/Float unittests were clearly marked. ie: at the top of modified files, there is the following stock message: Which is a good visual indicator to tell me whether or not this file can be copied across without any manual intervention / hand merging. Rather than me hand merging everything just incase there's a commented out / tweaked unittest. |
|
I'll make sure to include such messages in the future. I think I have upstreamed most of these changes, but probably not in time for 2.065. |
|
OK, with 9a809df everything builds. Now time to merge in the testsuite + run unittests / fix regressions. |
ibuclaw
changed the title
|
@yebblies I apologise in advance for any PRs and re-opening bugs that I may do. I've just looked at the test suite results and it's not pretty. :o) The worst part is tracking down what bug is tied to which change. |
|
PRs against dmd? I'll be watching. |
|
OK, x86_64 unittests now pass, and so does the testsuite with the exception to 2 unresolved tests regarding what may appear to be C++ linking problems. |
|
OK - almost done. Just need some platform testing now. @jpf91 - could you try this on ARM? I'm currently getting X32 sorted out. |
|
Awesome! I'll run the tests on ARM but it'll take some time (i.e. days) ;-) |
|
The version in |
|
OK - can you make sure that you've got 821b671 applied too, one NRVO bug slipped through the cracks. Dynamic array comparison should be better optimized too. |
|
Thanks. I get this error when compiling: |
|
Probably serves me right for using gcc.git on an "inbetween snapshot" revision - I'll update and fix master accordingly. |
|
Actually, wait, I've just looked again at your error:
I'm yet to switch to that snapshot date. I'd imagine there's been updates I'm not aware of yet. |
|
Just checked, it also happens with |
|
druntime is missing an declaration for ARM, I'll file an upstream pull request: diff --git a/libphobos/libdruntime/core/stdc/fenv.d b/libphobos/libdruntime/core/stdc/fenv.d
index 52c4f70..ad87e1c 100644
--- a/libphobos/libdruntime/core/stdc/fenv.d
+++ b/libphobos/libdruntime/core/stdc/fenv.d
@@ -75,6 +75,16 @@ else version( linux )
alias fexcept_t = ushort;
}
+ // https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/arm/bits/fenv.h;hb=HEAD
+ else version (ARM)
+ {
+ struct fenv_t
+ {
+ uint __cw;
+ }
+
+ alias fexcept_t = uint;
+ }
else
{
static assert(0, "Unimplemented architecture"); |
All UNRESOLVED and most FAIL tests seem to have one common cause, gdc always segfaults: I'll try to get a better backtrace tomorrow. There's also one evaluation order thing but it doesn't look ARM specific at a first glance? unittest results are mixed. There's only one new 'failing' test, but it's a segmentation fault. This patch needs to be applied anyway: diff --git a/libphobos/src/std/conv.d b/libphobos/src/std/conv.d
index a3c6d96..708a14a 100644
--- a/libphobos/src/std/conv.d
+++ b/libphobos/src/std/conv.d
@@ -2715,7 +2715,7 @@ unittest
//Tests for the double implementation
unittest
{
- import core.stdc.stdlib;
+ import core.stdc.stdlib, std.math;
static if(real.mant_dig == 53)
{
//Should be parsed exactly: 53 bit mantissa
diff --git a/libphobos/src/std/variant.d b/libphobos/src/std/variant.d
index e17757d..2970bc5 100644
--- a/libphobos/src/std/variant.d
+++ b/libphobos/src/std/variant.d
@@ -1438,9 +1438,9 @@ unittest
assert( v.get!(string) == "Hello, World!" );
// Literal arrays are dynamically-typed
- v = cast(int[5]) [1,2,3,4,5];
- assert( v.peek!(int[5]) );
- assert( v.get!(int[5]) == [1,2,3,4,5] );
+ v = cast(int[4]) [1,2,3,4];
+ assert( v.peek!(int[4]) );
+ assert( v.get!(int[4]) == [1,2,3,4] );
{
// @@@BUG@@@: array literals should have type T[], not T[5] (I guess) |
|
@jpf91 your right, something has happened on gcc side between 28/05 and the 08/06 that is causing these tests to ICE.
sigh - too many things are volatile. |
|
As for the ICE's they were caused by the fix for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53927 tree-nested.c has always been a pain. From the time we had (broken) STATIC_CHAIN_EXPR and STATIC_CHAIN_DECL. To the time when I (eventually) fixed the nuance of it in 02f086f to the time I removed setting DECL_STATIC_CHAIN to prevent tree-nested.c from doing precisely what this ICE is doing 2d6aa22. To now when tree-nested.c is now setting DECL_STATIC_CHAIN on it's own accord then dying. Actually, the fact that the middle-end is setting DECL_STATIC_CHAIN more an optimisation bug than anything else (bad codegen creating two chains - one by the frontend, the other by the backend). The actual ICE itself is because of nested 'in' contracts. In this example GCC has no idea how to call the 'in' contract for interface I from class C. (Because the decl->parent hierarchy provided by the D front-end is a bit convoluted when it comes to contracts). As all what the pass for tree-nested.c is doing is simply creating a static_chain_decl and reconstructing all nesting functions to use that decl as passed by a hidden parameter (this is already done by the front-end) then unnesting the function. Perhaps we can skip over this entire riff-raff of constant breakages from tree-nested.c by simply unnesting functions ourselves - and in the worst case, remove the whole notion of DECL_CONTEXT from the frontend codegen, so effectively all functions are public. |
|
@jpf91 I now get passes across the board now: Only to fail compilation on unittests for libphobos: Oh wait.... that is a typo! |
|
Also, strange error message for the operation given! |
|
Rebased, confirmed passing unittests and testsuite here. |
|
I looks like it should work fine on ARM now. (I guess you intentionally didn't include the The tests which failed before ran fine, the segfault in the phobos unittest is gone and phobos tests pass [1]. Unfortunately I don't have the full results yet cause my PandaBoard locked up after [1] except for math.internal.gammafunction, but that's nothing new |
Do you intend to release an RPM for the RapberryPi? |
Oops, I must have missed that. Was originally waiting for you to raise a PR upstream. Then I fell asleep and forgot about it. |
|
OK - everything that I'm aware of needing merging in is merged in. @jpf91 - Should I give you more time and let this sit tight till the weekend? I might be able to crack out my trimslice and get testing on this. |
|
@ibuclaw no need to wait, I restarted the tests and they just finished. @etcimon I'm not sure what you mean. We don't release distribution packages, that's a task for distribution packagers. I know debian/ubuntu will ship GDC on ARM and ArchlinuxARM also already ships GDC. But if you want to know whether we support the RaspberryPi: Yes, GDC should work just fine on the RPI. You can either build GDC from source or use our precompiled binaries. |
|
@ibuclaw seems I found a bug/regression in gdc when building the mingw code: struct IMAGEHLP_SYMBOL64
{
char[1] Name;
}
class StackTrace
{
char[][] resolveNoSync()
{
IMAGEHLP_SYMBOL64* symbol ;
char[][] trace;
if (*symbol.Name.ptr)
uint disp;
return trace;
}
}LANG=C /opt/gdc/bin/gdc test.d :(
test.d: In member function 'resolveNoSync':
test.d:8: error: mismatching comparison operand types
char[1]
int
if (D.2571 != 0) goto <D.2572>; else goto <D.2573>;
test.d:8: internal compiler error: verify_gimple failed
0xa8e21f verify_gimple_in_seq(gimple_statement_base*)
../../gcc-4.9.0/gcc/tree-cfg.c:4609
0x8b85c1 gimplify_body(tree_node*, bool)
../../gcc-4.9.0/gcc/gimplify.c:8654
0x8b8956 gimplify_function_tree(tree_node*)
../../gcc-4.9.0/gcc/gimplify.c:8739
0x746707 analyze_function
../../gcc-4.9.0/gcc/cgraphunit.c:649
0x7479bb analyze_functions
../../gcc-4.9.0/gcc/cgraphunit.c:1017
0x7490b5 finalize_compilation_unit()
../../gcc-4.9.0/gcc/cgraphunit.c:2320
0x697567 d_finish_compilation(tree_node**, int)
../../gcc-4.9.0/gcc/d/d-objfile.cc:1941
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://bugzilla.gdcproject.org> for instructions.I only tested this with gcc-4.9 (the backport is finished :-) but I'm currently building 4.10 to verify if the error happens there as well. |
|
I confirm this is a bug in 4.10 too. So must be codegen related. This is the gcc codegen emitted (spot what is wrong :) I smell a front-end bug. |
|
@yebblies don't know if you can have a quick look into the above? The front-end appears to be doing some AST optimisation and passing us a type-punned |
|
@jpf91 by the way, I swear I've seen something like this before, its some dejavu feeling from when venix1 did mingw maintenance a while back... |
|
Arghhhhh!!!! |
|
Yes, seemed familiar to me as well ;-) |
|
I blame @yebblies for this |
|
Raised a new bug https://issues.dlang.org/show_bug.cgi?id=12900 |
It's a round-about time we start to get this done.
This PR does the following:
Also renames the last of the .c files over to .cc - however we can't drop the separation between
.glue.oand.cglue.ojust yet. There's still one big conflict between GCC and the D front-end that isoptimizebeing a macro in GCC, and a common method in D frontend.Subsequently I'll praise the day when
optimizeeither becomes a visitor or we switch the front-end over to D.From here on afterwards (this includes 2.066) @yebblies gets quite prolific in his changes, and it's hard to keep a track of anything that is going on.
Things on the TODO list before
2.0652.066 merge is complete:RewriteDone in 2.065d-toir.ccas a visitor.RemoveDone in 2.065dfrontend/builtins.cand re-implement in the glue.Migrate D intrinsic routines to aDone in 2.065.deffile..deffile.dfrontend/cppmangle.cand integrate in the glue layer.So, only a couple hundred thousand LOC to write. ;o)