On Thu, Oct 04, 2018 at 11:52:29AM -0600, Jeff Law wrote: > On 10/4/18 11:01 AM, Josef Wolf wrote: > > On Thu, Oct 04, 2018 at 06:33:57AM -0600, Jeff Law wrote: > >> On 10/4/18 6:19 AM, Josef Wolf wrote: > >>> Why does gcc use those instructions? There is nothing special in the code > >>> which is now translated into those trap instructions. I don't use floating > >>> point at all, so I don't see any reason to use those instructions (and crash > >>> on them). > >>> > >> GCC will replace a NULL pointer dereference or division by zero with a > >> trap instruction. > > > > Is this described somewhere? I am pretty much sure that there is no NULL > > pointer dereference and no division in this code. There must be something else. > You can use -fdump-tree-all-blocks-details and look at the > isolate-erroneous-paths dump file. Those are the cases I'm aware of > where GCC will insert traps. Thanks, I'll check that out. When gcc inserts trap instructions, it assumes that there is some sort of hanlder installed for this? How should such a handler look like? I'd rather have the handler output some useful diagnostics instead of just crashing. > > In addition, the crash disappears, when I insert some no-op function call at > > the beginning of one of those functions. This causes GCC to use other > > registers for local variables. > register allocation shouldn't have anything to do with whether or not > something gets translated into a trap. The traps are there in both cases. But with this no-op function call, everything works as expected and the trap path is not taken. Without this no-op function call, the trap path will be taken. The only difference in the generated code is register allocation, caused by the additional function call. The input data is identical in both cases. I discovered this because I was inserting printf statements to track down the problem. -- Josef Wolf jw@xxxxxxxxxxxxx
