-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/07/11 15:25, Richard Guenther wrote: > > Indeed. We'd have to tell people that they cannot catch *(void *)0 > = 0 with a SIGSEGV signal handler unless they compile with some > magic flag. Thus, the question is whether we want to optimize > things in a way that are non-obvious to people viewing things from > a POSIX point of view rather than a C standard conforming issue. Agreed. The path I'd started going down was a flag like "-fassume-null-dereference-faults-and-is-uncatchable" or something like that. -fdelete-null-pointer-checks would be subsumed by the new flag.
> > > But what we could do by default is transform such stores to a trap > representation, or at least making the feeding stmts dead by > changing the stored value and the address to a constant (thus, even > preserve the trap kind). fold_stmt could change the stored value > if the address is literal zero, and all passes that know it is zero > should propagate it anyway. That wouldn't remove the outgoing edge > from the store of course, cfgcleanup could be teached to do that > though (and we could invent a trap kind argument to > __builtin_trap). More correctly, we'd wipe the path from the control edge to the *0 statement and remove the out edges from the block with the *0. Then just leave the *0 or a __builtin_trap. We'd leave the control edge itself leading to the *0/trap. That allows us to get most of the space savings optimization as well as most of the secondary benefits. The programmer could still catch the trapping signal. That doesn't work in the case of the implied dereference via NULL PHI arg. For that case we'd have to copy the block with the PHI, the incoming edges would be partitioned into those implying a null dereference vs those not implying a null dereference. Effectively this isolates the path with the implied NULL dereference and turns it into an explicit NULL dereference and we could optimize as noted above. So the question is do we want to proceed with any of this work? If so I can update the patch, if not I'll go back to my warning work :-) jeff -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOuYdZAAoJEBRtltQi2kC7z8oH/RVnZ03u2E20D2IbH++f0tiD 0StUVXlgtGGZHtY3jUupFzsQSSoyYtZhbgsVCCIm2Vu56t8jnb1YeWh8U4LVzsnA SifQo9txI5rp9NECahsqHUMxYFOlFDXVfIzc2c0Fq/RTZ5dRCVCYgHTRODHB1qcJ tXw4ckT0YOTEatGJsGt7QJtmEcjao71QV6UENbnzK6OIr7pD+hvFD0zUk7cZCyjW eIH3uy075qt06o3tCyDq0KU6sz8HqHZu9r9WFKx7pi2Tyqxysxps4KiH/X9ruz74 w+0fVIHnqUbszMjqsOSls+Qu/DvhKVACIwGyStcgMyHyTcgrnyy7WkGzkWgcOQk= =mSLN -----END PGP SIGNATURE-----
