On 10/4/18 1:39 PM, Josef Wolf wrote: > 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. It's up to the application to figure out how to handle this situation. The compiler only inserts the traps when it can prove conclusively that the program will trigger undefined behavior at a particular execution point. Stopping the program immediately is far better than the compiler trying to issue diagnostics or anything like that. You're in the world of undefined behavior, the safe thing to do is halt immediately. > >>> 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. That indicates a deeper problem (the existence of the call changing the paths through the program. ANyway, I've done about as much as I can here. I'll repeat, if the compiler is inserting traps, the program is horribly buggy at those points. You should dig into why. jeff
