-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
Validate more on assertion builds, and abort on errors #52830
Conversation
There is also julia/base/compiler/optimize.jl Lines 1059 to 1063 in 31a9f13
|
@nanosoldier |
The package evaluation job you requested has completed - possible new issues were detected. |
Looking at that report, running with additional verification/validation makes PkgEval on an assertions build 2.3% slower. That seems worth it, given the 12 IR corruptions uncovered here. I'll work on (filing issues to) fix those, and hopefully we can merge this afterwards. |
This found a lot more than I had expected, so I guess it's worthwhile. It's interesting that LLVM doesn't complain about these, because a lot of them seem to be malformed Phi nodes |
0819ad9
to
011becb
Compare
Keno fixed all of the issues I filed, so let's test again: @nanosoldier |
The package evaluation job you requested has completed - possible new issues were detected. |
CI failures unrelated (this only affects asserts builds), and PkgEval shows that this doesn't introduce additional failures. |
This PR add a
jl_is_assertsbuild
function (cfr.jl_is_debugbuild
) for checking if this is an assertions build.It's used in two places:
-g2
Both these changes are intended to help PkgEval in detecting more issues (invalid Julia IR) and make for more robust detection (a fatal signal instead of having to grep logs for
Internal error
, which leads to false positives).RFC because people actually working on the compiler might have opinions about the process not aborting if invalid IR is encountered.
cc @gbaraldi