Right, it's not a question of our code hitting the check, it's the
compiler crashing on us. We can't have errors in the compiler we use.
Looks good to me. Don't forget to regenerate configure and also push the
closed version.
/Erik
On 2014-11-24 15:07, Erik Helin wrote:
Hi Erik,
thanks for having a look! I realized that I had forgot to remove one usage
of $HAS_CFLAG_DETECT_UNDEFINED_BEHAVIOR, please see new webrev at:
http://cr.openjdk.java.net/~ehelin/8065648/webrev.01/
On 2014-11-24, Erik Joelsson wrote:
I think it's a reasonable change to remove the flag as it has most
likely not seen much use (if any) yet. I'm not sure what it does,
but I assume it's something to improve exploit protection the source
code. But if it doesn't work, we can't use it.
I should have mentioned what the flag does. From the official
documentation [2]:
Enable UndefinedBehaviorSanitizer, a fast undefined behavior detector.
Various computations will be instrumented to detect undefined behavior
at runtime.
GCC will instrument (add) code to detect if we are using any undefined
behavior at runtime, for example if the code divides an integer by zero.
The flag was only enabled for slowdebug builds due to the overhead of this
instrumentation.
On 2014-11-24, Erik Joelsson wrote:
We could also consider disabling the flag for the specific file
where we have the problem, if we think it's useful to keep the flag.
Given that the internal compiler error in GCC happens for such a small
program as
void fun() {
double f = 0.0;
(int)(1.0 < f ? 1.0 : 0.0);
}
I think it is better to not enable the flag for now and then re-enable it
when the implementation in GCC is more stable (hopefully in some future
GCC 4.9.x release).
Thanks,
Erik
[2]:
https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/Debugging-Options.html#Debugging-Options
/Erik
On 2014-11-21 15:57, Erik Helin wrote:
Hi all,
this patch removes the usage of the flag -fsanitize=undefined introduced
in GCC 4.9. The reason for not using this flag is that the implementation
in GCC still seem to have some bugs [0] (which I have encountered). The
flag is currently only enabled for slowdebug builds.
My suggestion is that we remove the flag for now, since the only supported
GCC version is 4.8.2 [1]. Then we can revisit this decisision when we upgrade
the supported compiler to GCC 4.9.x, since hopefully the bugs in GCC have
been fixed by then.
What do you think?
Webrev:
http://cr.openjdk.java.net/~ehelin/8065648/webrev.00/
Bug:
https://bugs.openjdk.java.net/browse/JDK-8065648
Testing:
- Verified that generated-configure.sh no longer tries to enable the flag.
Thanks,
Erik
[0]: https://bugzilla.redhat.com/show_bug.cgi?id=1166173
[1]: http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-October/001489.html
