On Tue, Nov 12, 2013 at 8:42 AM, Jeff Law <l...@redhat.com> wrote: > On 11/10/13 20:11, Jeff Law wrote: >> >> OK. It sounds like there's a pretty general consensus that we ought ot >> go ahead and leave in a load/store of a NULL pointer. I'll go ahead and >> run with that. I'll probably just emit SSA_NAME = *0, unless someone >> thinks we ought ot distinguish between loads and stores, emitting >> SSA_NAME = *0 and *0 = 0 for the two cases respectively. > > [ ... ] > Here's a patch which arranges to leave a null pointer dereferece in the IL. > For a memory load through a null pointer, we just leave the statement as-is > since the LHS is going to be a throw-away SSA_NAME. For a store through a > null pointer, we try to simplify the RHS when it's trivially easy to do so > (when the RHS is an integral type). This allows DCE to sometimes do a > better job if the RHS is something that was computed on the isolated path. > This could be easily extended to floating types, vectors and structures if > someone is interested. We issue the builtin_trap after the null > dereference. > > For other cases (invalid NULL argument, invalid NULL return), we continue to > issue the builtin trap in the same manner we did before. > > I've adjusted the existing tests and added a new one which verifies the RHS > of a store through a null pointer is simplified. > > Bootstrapped and regression tested on x86_64-unknown-linux-gnu. Installed on > the trunk. > > > > * gimple-ssa-isolate-paths.c (check_loadstore): New function. > (insert_trap_and_remove_trailing_statements): New argument OP which > is the NULL pointer. Emit the trap after the load/store through > the NULL pointer. Simplify the RHS of a store through a NULL > pointer > when trivial to do so. > (isolate_path): Corresponding changes. > (gimple_ssa_isolate_erroneous_path): Likewise. >
This caused: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59127 -- H.J.
