On 4/3/19 1:27 PM, Martin Sebor wrote: > PR 89934 reports yet another ICE due to a call to a library > built-in function with invalid arguments. The attached patch > does the bare minimum to avoid it. I will commit it to trunk > and to GCC 8 later this week if there are no objections. > > Martin > > PS There have been many of these reports (at least three in > the wrestrict pass alone, and quite a few elsewhere). Simply > avoiding the ICEs as this patch does and as all the others > before it have done as well does nothing to help solve > the underlying problem in user code: the invalid calls will > end up with undefined behavior if they are ever made at runtime. > For example, the one in this bug report will most likely cause > data corruption or buffer overflow without ever being detected > by _FORTIFY_SOURCE. That seems far worse than failing to compile > the code (either with an ICE or with some > other hard error). > > For GCC 10 I think a more robust solution should be put in place > not just to prevent these invalid built-in calls from tripping > up the middle-end, but also to avoid the undefined behavior at > runtime. The calls could either be rejected with an error as > Clang does, or they could be replaced them with __builtin_trap > or perhaps __builtin_unreachable, depending on some command > line option. > > > gcc-89934.diff > > PR middle-end/89934 - ICE on a call with fewer arguments to strncpy declared > without prototype > > gcc/ChangeLog: > > PR middle-end/89934 > * gimple-ssa-warn-restrict.c (builtin_access::builtin_access): Bail > out if the number of arguments is less than expected. > > gcc/testsuite/ChangeLog: > > PR middle-end/89934 > * gcc.dg/Wrestrict-19.c: New test. > * gcc.dg/Wrestrict-5.c: Add comment. Remove unused code. OK.
WRT the larger issue. Assume we have the infrastructure bits to transform the bogus calls into a __builtin_trap or __builtin_unreachable (which I think we can easily lift from elsewhere) and a flag to allow us to determine which style we want. (we can build and prototype that and use the result in the erroneous-path-isolation pass). The question is when do we want to detect the bogus calls. There are some that we'd likely want to catch early, such as the wrong number of arguments like we see in this case. That feels like a pass over the IL right after gimplification. Other cases are more interesting. Do we try to detect when a propagation makes the call invalid as soon as it happens, or do we defer to the erroneous path isolation pass? Or do we end up doing both as there may be cases where analysis is nontrivial. Anyway, I think we can start working down this path for gcc-10. jeff
