Jakub Jelinek <ja...@redhat.com> wrote:
>On Mon, Dec 30, 2013 at 10:14:16PM +0100, Jan Hubicka wrote:
>> this is C version
>> static int (*p) (int a) = (int (*)(int))__builtin_unreachable;
>> main()
>> {
>> return p(1);
>> }
>
>Well, that testcase is invalid, as you are calling the function
>(builtin)
>through incompatible function pointer, so all we care there is not
>ICEing.
>Not to mention that the above testcase will not link with -O0.
>Plus it is not fold_stmt that folds the above.
>
>IMHO when GCC adds the __builtin_unreachable itself, it shouldn't do
>the
>invalid thing.
>
>That said, fold_stmt callers have to be prepared to handle say a normal
>call becoming noreturn call, consider say:
>
>struct A { virtual int foo (); };
>struct B : public A { int foo () __attribute__((noreturn)); };
>int B::foo () { __builtin_exit (0); }
>int bar ()
>{
> B b;
> B *p = &b;
> return p->foo ();
>}
Is that a valid specialization though?
>where fold_stmt changes the OBJ_TYPE_REF based call into B::foo ()
>which
>is noreturn.
I am quite sure callers of fold_stmt do not schedule cleanup_cfg when it
returns true. They mostly do it accidentally.
Richard.
The bad thing on the folding gimple_fold_call did before
>the
>patch I've posted is mainly that it kept the lhs there even when
>__builtin_unreachable has void return type, and very ugly but not fatal
>is the passing of extra arguments to the builtin that doesn't take any.
>
> Jakub
