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.

Sign up for GitHub

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

Jump to bottom

LLVM 3.6/3.7: d_do_test fails with "Enforcement failed" #855

Closed
redstar opened this issue Feb 28, 2015 · 7 comments
Closed

LLVM 3.6/3.7: d_do_test fails with "Enforcement failed" #855

redstar opened this issue Feb 28, 2015 · 7 comments
Assignees
@redstar
Labels
A-blocker
Milestone
0.15.2

Comments

@redstar
Copy link
Member

redstar commented Feb 28, 2015

The d_do_test test runner fails with

object.Exception@/home/travis/build/ldc-developers/ldc/runtime/phobos/std/stdio.d(2180): Enforcement failed

if compiled with LLVM 3.6 and LLVM 3.7. The dmd test suite is not run in Travis because of this.
@redstar redstar added this to the 0.15.2 milestone Feb 28, 2015
@redstar
Copy link
Member Author

redstar commented Mar 30, 2015

The exception is caused by the first call to writef, independent of the parameters. If you put a writef("Hello\n"); in the first line of main() then the unittest run fails, too.

@redstar
Copy link
Member Author

redstar commented Mar 31, 2015

Finally found the culprit: if you use the -singleobj command line switch then even a simple hello world type application dies with the exception. This does not happen if you do not use the switch.

@dnadlinger
Copy link
Member

This suggests that the behavior of the LLVM IR module linker changed somehow. It is probably somehow related to static constructors or TLS initialization.

@MartinNowak
Copy link
Contributor

FYI, I also get this for any other program I tested with 0.15.2-beta1.

redstar added a commit to redstar/ldc that referenced this issue Apr 3, 2015
@redstar
Fix for issue ldc-developers#855.
d3f6e4a 
If several modules are linked together, an empty module is used as
target. Starting with LLVM 3.6, there seems to be a slight difference
between an empty module and a module with IR.
The PR uses always the first module as the target. This has the nice
side effect that we are no longer affected by LLVM bug 11479.
redstar added a commit to redstar/ldc that referenced this issue Apr 4, 2015
@redstar
Fix for issue ldc-developers#855.
ff5b75b 
If several modules are linked together, an empty module is used as
target. Starting with LLVM 3.6, there seems to be a slight difference
between an empty module and a module with IR.
The PR uses always the first module as the target. This has the nice
side effect that we are no longer affected by LLVM bug 11479.
redstar added a commit to redstar/ldc that referenced this issue Apr 4, 2015
@redstar
Fix for issue ldc-developers#855.
5be8ba8 
If several modules are linked together, an empty module is used as
target. Starting with LLVM 3.6, there seems to be a slight difference
between an empty module and a module with IR.
The PR uses always the first module as the target. This has the nice
side effect that we are no longer affected by LLVM bug 11479.
@redstar redstar mentioned this issue Apr 4, 2015
Closed
@redstar redstar self-assigned this Apr 4, 2015
redstar added a commit to redstar/ldc that referenced this issue Apr 4, 2015
@redstar
Fix for issue ldc-developers#855.
78343c0 
If several modules are linked together, an empty module is used as
target. Starting with LLVM 3.6, there seems to be a slight difference
between an empty module and a module with IR.
The PR uses always the first module as the target. This has the nice
side effect that we are no longer affected by LLVM bug 11479.
redstar added a commit to redstar/ldc that referenced this issue Apr 4, 2015
@redstar
Fix for issue ldc-developers#855.
2661a40 
If several modules are linked together, an empty module is used as
target. Starting with LLVM 3.6, there seems to be a slight difference
between an empty module and a module with IR.
The PR uses always the first module as the target. This has the nice
side effect that we are no longer affected by LLVM bug 11479.
redstar added a commit to redstar/ldc that referenced this issue Apr 4, 2015
@redstar
Fix for issue ldc-developers#855.
1ac7988 
If several modules are linked together, an empty module is used as
target. Starting with LLVM 3.6, there seems to be a slight difference
between an empty module and a module with IR.
The PR uses always the first module as the target. This has the nice
side effect that we are no longer affected by LLVM bug 11479.
redstar added a commit to redstar/ldc that referenced this issue Apr 4, 2015
@redstar
Fix for issue ldc-developers#855.
aa28964 
If several modules are linked together, an empty module is used as
target. Starting with LLVM 3.6, there seems to be a slight difference
between an empty module and a module with IR.
The PR uses always the first module as the target. This has the nice
side effect that we are no longer affected by LLVM bug 11479.
redstar added a commit to redstar/ldc that referenced this issue Apr 5, 2015
@redstar
Fix for issue ldc-developers#855.
d5d6e89 
If several modules are linked together, an empty module is used as
target. Starting with LLVM 3.6, there seems to be a slight difference
between an empty module and a module with IR.
The PR uses always the first module as the target. This has the nice
side effect that we are no longer affected by LLVM bug 11479.
redstar added a commit to redstar/ldc that referenced this issue Apr 5, 2015
@redstar
Fix for issue ldc-developers#855.
c26e469 
If several modules are linked together, an empty module is used as
target. Starting with LLVM 3.6, there seems to be a slight difference
between an empty module and a module with IR.
The PR uses always the first module as the target. This has the nice
side effect that we are no longer affected by LLVM bug 11479.
redstar added a commit to redstar/ldc that referenced this issue Apr 5, 2015
@redstar
Fix for issue ldc-developers#855.
13fb3f2 
Linking several modules together seems to trigger assertions with
identified structs. In debug builds, the assertion
!(Pair.first != Ty && Pair.second == Ty) && "mapping to a source type"
is raised. In non-debug builds, you often get a D exception saying
"Enforcement failed".

Reason seems to be the use of the some type object in different
modules. E.g. module A imports from module B the struct S. Then both
modules refer to the same identifed llvm::StructType object. This
causes the errors.

The behaviour may be an LLVM bug. There is no test case for this
situation. This affects all supported LLVM versions. If the target
module is changed (e.g. use of llvmModule[0] instead of an empty
module) then the error occurs in other LLVM versions, too.

This commit uses the following workaround:
- target module is llvmModule[0] (instead of an empty module)
- each other module is first linked into an empty module and then
  into the target module.

This is really ugly but avoids the error.

There is no new test case required because runnable/A16.d already
checks it.
@redstar
Copy link
Member Author

redstar commented Apr 5, 2015

Commit 13fb3f2 hopefully fixes this error.

@redstar
Copy link
Member Author

redstar commented Apr 5, 2015

Test compilable/test4003.d still fails because of linking.

redstar added a commit to redstar/ldc that referenced this issue Apr 19, 2015
@redstar
2nd try at issue ldc-developers#855.
1a8ea4f 
I cannot reproduce this issue on my Gentoo Linux. :-(
The fix adds another empty module. It does not crash on Windows.
redstar added a commit to redstar/ldc that referenced this issue Apr 19, 2015
@redstar
2nd try at issue ldc-developers#855.
e6a36bc 
I cannot reproduce this issue on my Gentoo Linux. :-(
The fix adds another empty module. It does not crash on Windows.
This was referenced May 31, 2015
Closed
Closed
Closed
Closed
@dnadlinger
Copy link
Member

We are not using llvm::Linker anymore.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@redstar redstar

Labels
A-blocker
Projects
None yet
Milestone
0.15.2
Development

No branches or pull requests
3 participants
@dnadlinger @MartinNowak @redstar