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
floating point exception (clang6) #2211
Comments
I hit an assertion in sol_cx and other places with deal.II 9.0, might be related, but is slightly different:
I have an idea where it is coming from and will fix, lets see if that solves your issue as well. |
The fix for my problem is in #2214, does your error still occur after that fix? |
I can reproduce exactly your error message on ubuntu 14.04 (clang 6 manually installed) and 18.04 (clang 6 installed from repository). I can not see what is happening though. Is there a tester for deal.II with clang 6 and this particular setup? Then we could at least narrow down if the problem is in aspect or deal.II. |
This is the full callstack:
Does it tell us anything that the exception is raised from libpthread? |
Demangled, this looks as follows:
I don't think that the problem is inside libpthread, but only that the pthread library has installed a signal handler that cleans up the thread before it aborts the program. |
In other words, I assume that the problem happens inside the |
@bangerth: Timo posted the line that gdb shows, but that makes no sense, because there is no floating point operation there. So it must happen at some random point before. Would printf check for FPE's? A few more informations:
So does our test just incorrectly assume that FPEs would work on this system? Then #2225 would be the solution. Should we just go with that and make the release? I do not see a reason why clang6 should suddenly find errors that other compilers did not find before. |
I assume clang is more aggressive in optimizing the code in debug mode. Without FP exceptions, it is of course legal to optimize something like
and always do the divide. I don't think we have a bug in our code.
Hardcoding a check like this for a specific compiler version is not ideal. I would prefer to extend the check. Give me a plane ride to see if I can figure this out. ;-) |
Let's let @tjhei have his plane ride :-) @gassmoeller -- no, |
So, my guess was correct: clang is optimizing around simple bool checks an eagerly evaluates expressions that contain floating point exceptions like the I tried extending our FPE check to contain code similar to this, but I haven't succeeded in making it fail the check. So what do we do? Try to disable these clang optimizations? rewrite the functions to be safe? blacklist all clang 6.0+ for FPEs? |
That's clearly a compiler bug then. I vote to just disable FPEs for clang 6, as already implemented in #2225. This has the advantage that (i) we don't further obfuscate our source code, (ii) don't penalize everyone who is using a different compiler. The number of people who would be impacted by #2225 is likely quite small, and that's useful. |
while not "fixed", let's close this with #2225 as the solution. |
I am getting
when running solcx in the second nonlinear solve. I am not sure what is going on here.
The text was updated successfully, but these errors were encountered: