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
Merge 2.074 front-end + libs #2076
Conversation
@@ -179,6 +190,13 @@ struct Target | |||
realalignsize = 2; | |||
reverseCppOverloads = true; | |||
c_longsize = 4; | |||
if (ptrsize == 4) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's version this out.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This code is only used by DMD, we have our own Target struct at the top of the file.
return 0; | ||
} | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will need to be checked, i.e., whether a proper fix preventing the same field from being added multiple times to the fields list has made it into upstream 2.074.
First upstream PR: dlang/druntime#1815 |
Fixes compilable/b17111.d, see dlang/dmd@84fcc60.
Linux: 4 distinct failing unittest modules left, the rest (dmd-testsuite, lit-tests, LDC unittests) passes. |
// skip over casts | ||
auto ce = cs->exp; | ||
while (ce->op == TOKcast) | ||
ce = static_cast<CastExp *>(ce)->e1; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any chance that this drops a narrowing conversion? (Sorry if this is totally off, haven't studied the code closely.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nope. It's only used to check for a nested VarExp
; cs->exp
, the original expression, is evaluated in all cases (variable/constant).
2nd upstream PR: dlang/druntime#1816 |
Next one: dlang/phobos#5345 |
Required for OSX, where version `CheckFiberMigration` is set.
Another one: dlang/phobos#5346 |
Update:
|
Conflicts: runtime/druntime runtime/phobos
With ldc-developers/phobos@2220a3a, all |
Alright, first green runs - all but the 2 Travis |
Conflicts: runtime/druntime runtime/phobos
Upgraded to 2.074.1 and synced with master. |
In case the host real_t is double (e.g., for MSVC hosts).
Conflicts: runtime/druntime
Conflicts: tests/d2/dmd-testsuite
As to the final issue: not even a Phobos hello-world program can be linked when using the shared runtime libs due to undefined members of this nested struct:
Any ideas why only the shared libs are affected? No public visibility or something like that? I know nothing about shared libs on Linux, but the template seems to be instantiated in Phobos (=> #2168). |
Conflicts: runtime/druntime
Conflicts: runtime/druntime tests/d2/dmd-testsuite
Static:
vs. shared:
Edit: |
Oh and btw, both shared and static Phobos libs consist of the same D object files. |
So the function is not codegenned, I've run into similar issues with Weka's codebase where some templates are culled too aggressively. But also because of failing to deduce attributes in certain cases but not in others: https://issues.dlang.org/show_bug.cgi?id=17541. |
But then why is the linker not complaining when feeding it the static lib with exactly the same D objects? |
Conjecture: in the static case, the linker sees all symbols and knows it can strip the symbol in which the undef thing is referenced. In the sharedlib case, perhaps the linker cannot make as many assumptions, because the shared lib could be replaced with another and then behavior could be different when certain symbols are available or not? Really, I don't know. |
This is the first time I see that happening in Phobos stuff. That's very good news: see if it happens with dmd too, dustmite and submit bugreport. The bug with Weka source has been a bit elusive so far. (or I've lost track in the confusion of the weird complex bugs I submitted...) |
DMD 2.074.0 has no problems with linking the above hello-world with its combined (druntime + Phobos) |
lol heh true. (thought they are doing static linking) Very strange that our front-end culls, and theirs doesn't though.... |
I have a strong assumption - they seem to build druntime & Phobos in a single command line, all D files at once: https://github.com/dlang/phobos/blob/master/posix.mak#L321 |
So this should basically be due to (supposedly fixed) https://issues.dlang.org/show_bug.cgi?id=2500 or some more sophisticated variant of it. |
They do by default but ship with static and shared libs, so I caught the linker line via |
All green now after the template culling hack. |
CMakeLists.txt
Outdated
@@ -817,6 +819,9 @@ add_subdirectory(tests) | |||
|
|||
install(PROGRAMS ${LDC_EXE_FULL} DESTINATION ${CMAKE_INSTALL_PREFIX}/bin) | |||
install(PROGRAMS ${LDMD_EXE_FULL} DESTINATION ${CMAKE_INSTALL_PREFIX}/bin) | |||
if(NOT CMAKE_INSTALL_PREFIX STREQUAL "/usr") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Huh? This smells massively.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't want to install the bash script system-wide. It's more of an internal script by itself, useful for local builds and release packages, but not system-wide availability IMO.
Correct context: #2198
I created a test branch I'd prefer using #2231 (maybe merged as part of 2.074 if the Semaphore issue reproducibly vanishes) and expose the weakened template culling hack as command-line option. Thoughts? |
Well, no Phobos compilation failures after 10 jobs, so I think it's safe to assume 2.074 gets rid of that last issue of #2231. |
Conflicts: runtime/druntime runtime/phobos
No description provided.