On Sat, 12 Oct 2024, Martin Uecker wrote: > Am Samstag, dem 12.10.2024 um 18:44 +0200 schrieb Richard Biener: > > > > > Am 12.10.2024 um 16:43 schrieb Martin Uecker <uec...@tugraz.at>: > > > > > > > > > There is code which should not fail at run-time. For this, > > > it is helpful to get a warning when a compiler inserts traps > > > (e.g. sanitizers, hardbools, __builtin_trap(), etc.). > > > > > > Having a warning for this also has many other use cases, e.g. > > > one can use it with some sanitizer to rule out that some > > > piece of code has certain undefined behavior such as > > > signed overflow or undefined behavior in left-shifts > > > (one gets a warning if the optimizer does not prove the > > > trap is dead and it is emitted). > > > > > > Another potential use case could be writing tests. > > > > > > > > > Bootstrapped and regression tested on x64_84. > > > > > > > > > Add warning option that warns when a trap is generated. > > > > > > This adds a warning option -Wtrap that is emitted in > > > expand_builtin_trap. It can be used to verify that traps > > > are generated or - more importantly - are not generated > > > under various conditions, e.g. for UBSan with -fsanitize-trap, > > > hardbools, etc. > > > > Isn’t it better to diagnose with more context from the callers that insert > > the trap? > > More context would be better. Should there be additional > arguments when creating the call to the builtin?
Why not diagnose when we create the call? But sure, adding a diagnostic argument would work, it might also work to distinguish calls we want to diagnose from those we don't. Richard.
