On Mon, Jun 22, 2015 at 07:59:20PM -0600, Martin Sebor wrote:
> >It seems like this patch regresess pr59630.c testcase; I don't see
> >the testcase being addressed in this patch.
>
> Thanks for the review and for pointing out this regression!
> I missed it among all the C test suite failures (I see 157
> of them in 24 distinct tests on x86_64.)
You might want to use contrib/test_summary and then compare its
outputs.
> pr59630 is marked ice-on-valid-code even though the call via
> the converted pointer is clearly invalid (UB). What's more
> relevant, though, is that the test case is one of those that
> (while they both compile and link with the unpatched GCC) are
> not intended to compile with the patch (and don't compile with
> Clang).
Right, just turn dg-warning into dg-error.
> In this simple case, the call to __builtin_abs(0) is folded
> into the constant 0, but in more involved cases GCC emits
> a call to abs. It's not clear to me from the manual or from
> the builtin tests I've seen whether this is by design or
> an accident of the implementation
>
> Is it intended that programs be able to take the address of
> the builtins that correspond to libc functions and make calls
> to the underlying libc functions via such pointers? (If so,
> the patch will need some tweaking.)
I don't think so, at least clang doesn't allow e.g.
size_t (*fp) (const char *) = __builtin_strlen;
Marek
