On 1/30/22 11:58, Jakub Jelinek wrote:
On Sun, Jan 30, 2022 at 10:50:56AM +0000, Jonathan Wakely wrote:
We could put a trap instruction at the end of the function though, which
would make the result a bit less arbitrary.
I've come around to thinking that's preferable for cases like this.
Depends on which exact cases.
Because for
int foo (int s) { if (s == 123) return 1; }
we want to optimize it into
return 1;
rather than if (s == 123) return 1; else __builtin_trap ();
For debugging we have -fsanitize=undefined
Jakub
I understand completely, it is undefined behaviour. What I had not
realized is that undefined behaviour
is not a property of the function itself, but of the function call when
parameters are specified. That seems
more difficult to handle from the compiler perspective, but if that is
the rule, so be it...
It seems to me that this is a case that just makes things more
complicated for programmers (and compiler developers) for the benefit
of only a small community which will know the precise limits of the
undefined behaviour and would like to play at the boundary of the cliff.
Honestly, for the user perspective (or more exactly a majority of
users), it would be nice if there was a way to catch such situations at
compile time (making of course more strict assumptions on the compiler
side). Of course, I can fire gdb or -fsanitize=undefined, but
whatever can be caught earlier is better.... I will turn that specific
warning into a an error with -Werrror=XXX for my own usage.
Thank's for the explanations. At least, I learned something. Hope I did
not waste too much of your time.
Theo.
