gcc 4.2 more strict check for "function called through a non-compatible type"

[Yuri Pudgorodsky]

So that ICE still exist for objective-c and is just hidden with 
warn/trap workaround
for c/c++:

double foo(double arg)
{
  return arg;
}

int bar(int d)
{
  d = ((int (*) (int)) foo)(d);
  return d *d;
}

If you compile the above example in objective-c mode (gcc -O3 -x 
objective-c),
current mainline as well as all 3.4.2 ... 4.1 versions hits an ICE:

yur@cloud ~/tmp $ gcc-4.2 -O3 -x objective-c bbb1.c -S
bbb1.c: In function 'bar':
bbb1.c:8: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://bugs.gentoo.org/> for instructions.
Preprocessed source stored into /tmp/ccO8k5QS.out file, please attach 
this to your bugreport.
yur@cloud ~/tmp $ gcc-3.4.5 -O3 -x objective-c bbb1.c -S
bbb1.c: In function `bar':
bbb1.c:3: internal compiler error: in convert_move, at expr.c:564
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://bugs.gentoo.org/> for instructions.
Preprocessed source stored into /tmp/ccj3pUVx.out file, please attach 
this to your bugreport.


Original PR/12085 fix was proposed to simply not inline function call:
http://gcc.gnu.org/ml/gcc-patches/2003-12/msg00683.html.

2003-12-07  Eric Botcazou  <ebotcazou@libertysurf.fr>

        PR optimization/12085
        * tree-inline.c (expand_call_inline): Do not inline functions at
    calling points where they are viewed with too different a prototype
    than the actual one.

But later it has been changed to warn/trap for c/c++ mode, leaving ICE 
for objc intact:
http://gcc.gnu.org/ml/gcc-patches/2003-12/msg01767.html

2003-12-19  Eric Botcazou  <ebotcazou@libertysurf.fr>

        PR c/12085
        * c-typeck.c (build_function_call): Issue a warning if a
        function is called through an incompatible prototype and
    replace the call by a trap in this case.

May be it's time to implement better fix for that ICE than generating 
trap instead of actual call
for all (even valid on a particular platform) function pointer conversions?

Can someone make the decision to reopen PR optimization/12085?