This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Introduce -fwrapp and make -fno-strict-overflow imply it (PR middle-end/82694)


On Fri, 12 Jan 2018, Marc Glisse wrote:

> On Fri, 12 Jan 2018, Jakub Jelinek wrote:
> 
> > Apparently Linux kernel contains various UB code that has been worked around
> > through -fno-strict-overflow in 7.x and before, but when
> > POINTER_TYPE_OVERFLOW_UNDEFINED has been removed it now fails to boot.
> > 
> > The following patch follows the comments in the PR, essentially reverts
> > Bin's removal of that, except that it is now controlled by a separate option
> > and is included in TYPE_OVERFLOW_{WRAPS,UNDEFINED} macros.
> 
> I am pretty sure there are other patterns in match.pd that need protection
> now, with pointer_diff.
> 
> (for op (simple_comparison)
>  (simplify
>   (op (pointer_diff@3 @0 @2) (pointer_diff @1 @2))
>   (if (!TYPE_OVERFLOW_SANITIZED (TREE_TYPE (@2)))
>    (op @0 @1))))
> 
> This is ready for sanitizers but not for wrapping pointers. And there are a
> few more like it.
> 
> 
> There were discussions at some point of implementing -fwrapp in the front-end,
> generating (unsigned)q-(unsigned)p or (unsigned)p<(unsigned)q for pointer
> operations. It has the advantage that the middle-end doesn't need to know
> about those variants, but it might have some fallout (and I am not sure what
> to do when the middle-end creates new pointer operations), and I can
> understand that in stage 3 you are more interested in an approach that looks
> like a reversal to a former known-ok state.

Yes, I think reversal to previous behavior is the only reasonable
thing at the moment.

Richard.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]