[Bug tree-optimization/85158] ubsan and -O3 finds a problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85158 --- Comment #7 from rguenther at suse dot de --- On Tue, 3 Apr 2018, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85158 > > --- Comment #6 from Jakub Jelinek --- > As a middle-ground between ints, HOST_WIDE_INTs and unlimited precision we > have > offset_int, widest_int etc. But perhaps using even that would be too costly. Not sure - we seem to get away with gmp in niter analysis just "fine". What the current code misses if we don't go all the way to unlimited precision is a failure mode on overflow given overflow almost certainly results in wrong-code with enough bad luck. Anyway, IIRC we went to HWIs already to handle "most" cases, and yes, the lambda_vector case is still "unfixed" at ints. But what's still missing is the failure mode... (I fear that a hard assert will trigger way too often...)
[Bug tree-optimization/85158] ubsan and -O3 finds a problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85158 --- Comment #6 from Jakub Jelinek --- As a middle-ground between ints, HOST_WIDE_INTs and unlimited precision we have offset_int, widest_int etc. But perhaps using even that would be too costly.
[Bug tree-optimization/85158] ubsan and -O3 finds a problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85158 --- Comment #5 from David Binderman --- (In reply to Richard Biener from comment #4) > There's related PR82494 about the lambda vector operations but yes, this > code hasn't > been fixed to avoid overflows and generally expects to operate with infinite > precision integers ... (you know, 64bits will be enough - really!). This code works 99% of the time. I'd be happy to see it bodged until it works 99.9% of the time. Can I suggest that for those parts of the code where int isn't enough, then long gets used and for those parts where long isn't enough, the 128 bit data type (__int128_t ?) gets used. Going all the way to unlimited ints when plain ints aren't enough seems overkill to me, although I am not familiar with the code.
[Bug tree-optimization/85158] ubsan and -O3 finds a problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85158 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Richard Biener --- There's related PR82494 about the lambda vector operations but yes, this code hasn't been fixed to avoid overflows and generally expects to operate with infinite precision integers ... (you know, 64bits will be enough - really!). Fixing requires overhauling all of the API and data structures in dependence analysis and finding a suitable representation for "infinite precision integers". Note that most of the APIs do not have a well-defined failure mode so bailing out isn't easy either. Using GMP is very likely prohibitly expensive not only due to its lack of optimizing the small-precision case. OTOH we are using it from niter analysis already. Evaluating ISL ints (isl/val.h when configured to not use GMP) might be worth, as well as maybe looking at including (patched?) mini-gmp. Note the HWIs are less likely a problem than the ints currently used for lambda vectors/matrices. Note that simply silencing UBSAN by using unsigned arithmetic will simply silence it, not avoiding wrong-code issues that might be latent there. *** This bug has been marked as a duplicate of bug 82494 ***
[Bug tree-optimization/85158] ubsan and -O3 finds a problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85158 Jakub Jelinek changed: What|Removed |Added Status|WAITING |NEW CC||rguenth at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Oops, sorry, missed the UB is in the compiler, sorry. I believe this and surrounding code has several such known issues, but can't find a PR for that right now.
[Bug tree-optimization/85158] ubsan and -O3 finds a problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85158 --- Comment #2 from David Binderman --- (In reply to Jakub Jelinek from comment #1) > The above snippet isn't a self-contained program and contains UB, so it is > unclear how you can get runtime diagnostics for it. The short snippet of code is stored in file bug424.c gcc trunk revision 259004 has been built with ubsan, as the configure line should make clear. 06:51 is pretty early in the morning, isn't it ? ;->
[Bug tree-optimization/85158] ubsan and -O3 finds a problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85158 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-04-03 CC||jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- The above snippet isn't a self-contained program and contains UB, so it is unclear how you can get runtime diagnostics for it.
