On Mon, Dec 18, 2017 at 10:37:19AM -0700, Martin Sebor wrote: > On 12/18/2017 10:07 AM, Jakub Jelinek wrote: > > On Mon, Dec 18, 2017 at 10:00:36AM -0700, Martin Sebor wrote: > > > On 12/18/2017 08:10 AM, Marek Polacek wrote: > > > > I'm not entirely up to speed with this code, but this one seemed > > > > sufficiently > > > > obvious: check INTEGRAL_TYPE_P before looking at a tree's min/max value. > > > > Otherwise, go with maxobjsize. > > > > > > > > Bootstrapped/regtested on x86_64-linux, ok for trunk? > > > > > > Thanks for the fix. I noticed the problem only comes up when > > > memcpy is declared without a prototype. Otherwise, the memcpy > > > call is eliminated early on (during gimplification?) So while > > > avoiding the ICE is obviously a necessary change, I wonder if > > > this bug also suggests a missing optimization that might still > > > be relevant (i.e., eliminating memcpy() with a zero size for > > > a memcpy without a prototype): > > > > No, we shouldn't try to optimize if people mess up stuff. > > Declaring memcpy() without a prototype isn't messing up. It may > be poor practice but there's nothing inherently wrong with it.
There is. Because the last argument is size_t, so calling it with 0 is UB (on LP64, on ILP32 I think it will be optimized normally). Jakub