On Fri, 7 Feb 2020, Richard Biener wrote: > To me it's a QOI question that depends on the actual case. > Turning memcpy (p, p, N) into a no-op is the correct thing, > even though with (too) large N it might trap. Folding > a read from outside of an object to zero might be OK > (it's undefined), but the choice of zero is arbitrary and it's > clearly not what the writer of the code intended. Folding > it do a NaT and do further optimizations based on that > would be even worse. Currently we leave the undefined > code in place but IMHO another sensible choice would > be to replace it with an explicit trap or unreachable > (and the choice between those could be dependent on > a command-line option).
Calling va_arg with a type changed by the default argument promotions (float, char, etc.) is another case where there would be a reasonably safe fallback (making gimplify_va_arg_expr adjust the type itself to the one it mentions in the warning message) as an alternative to generating a trap, possibly depending on command-line options to say how the user wishes to handle such cases. -- Joseph S. Myers jos...@codesourcery.com
