Created attachment 33257 [details] delta+hand reduced testcase Found on powerpc64le with 4.9, and then with x86_64 4.10.0 20140727 Due to __warn_memset_zero_len reference in object, we get .../bytearraymodel_p.o: In function `memset': .../bits/string3.h:81: warning: memset used with constant zero length parameter; this could be due to transposed parameters collect2: error: ld returned 1 exit status Compile testcase with -O3 -fvisibility=hidden -Werror=return-type -fvisibility-inlines-hidden
I don't see a bug here as there is one case where addSize can return 0 and with jump threading and basic block copying, we get a zero size passed to memset.
I can see where you're coming from Andrew, but what is disconcerting about this is that the _FORTIFY_SOURCE warning is plainly incorrect here. How is one supposed to write a string.h memset macro using __builtin_constant_p() to provide a useful _FORTIFY_SOURCE warning, in the face of this sort of optimisation? Users are going to see this as "__builtin_constant_p() is broken".
(In reply to Alan Modra from comment #2) > I can see where you're coming from Andrew, but what is disconcerting about > this is that the _FORTIFY_SOURCE warning is plainly incorrect here. How is > one supposed to write a string.h memset macro using __builtin_constant_p() > to provide a useful _FORTIFY_SOURCE warning, in the face of this sort of > optimisation? This is why Jakub moved it to the front-end away from glibc (See PR 61294). > > Users are going to see this as "__builtin_constant_p() is broken". It is not. It is working correctly as on that path, it is constant. This is an exact duplicate of bug 61294 really. *** This bug has been marked as a duplicate of bug 61294 ***