We can say something like:
In GNU C, you may cast a function pointer of one type to a function
pointer of another type. If you use a function pointer to call a
function, and the dynamic type of the function pointed to by the
function pointer is not the same as indicated by the static type
Gabriel Dos Reis wrote:
Yuri Pudgorodsky [EMAIL PROTECTED] writes:
[...]
| The result of calling function pointer casted to sufficiently different
| type is
| a real example an undefined behavior.
As I said earlier, it is fruitless to try to impose an ordering on
the space of undefined
Andrew Pinski wrote:
On Jul 4, 2006, at 5:07 PM, Yuri Pudgorodsky wrote:
Can someone make the decision to reopen PR optimization/12085?
And I posted a patch to do the same in Objective-C mode as C mode :).
http://gcc.gnu.org/ml/gcc-patches/2004-08/msg01013.html
That indeed will fix PR
Andrew Pinski wrote:
On Jul 5, 2006, at 2:36 AM, Yuri Pudgorodsky wrote:
1) with direct cast: (int (*)(int)) foo
- warn/trap since 3.x
2) with cast through void fptr: (int (*)(int)) (int(*)()) foo
- warn/trap since 4.2 current
I don't see why you are invoking this undefined behavior
Gabriel Dos Reis wrote:
Furthermore, I've read people suggesting that we are gratuitously
broking code. That is misleading. The code was invoking undefined
behaviour and, before, we did not make any explicit guarantee about
the semantics.
It is one thing to argue for changing gear; but,
I apologize for presenting something which appears to be a strawman
argument. That would never be my intent. Let me restate: I don't
think gcc should ever insert a trap call for undefined code. We
should only insert a trap call for code which will provably trap.
We're currently breaking
For what it's worth, I tried to recreate the ICE after removing the
trap insertion, but failed. So I'm not even sure the trap insertion
is fixing a real problem any more. It works at the moment simply
because it treats the call through a cast as a call through a function
pointer, and
What happens when a target comes along and passes different pointers
types
differently. Like say a floating point pointer in the FP register and an
pointer to an integer in the general purpose register, wouldn't that also
break the code in question? Yes this is in theory but still saying
Ian Lance Taylor wrote:
Mike Stump [EMAIL PROTECTED] writes:
On Jul 4, 2006, at 5:18 PM, Andrew Pinski wrote:
And I posted a patch to do the same in Objective-C mode as C mode :).
http://gcc.gnu.org/ml/gcc-patches/2004-08/msg01013.html
Is the reason that Objective-C was
Compiling openssl-0.9.8b with gcc-4.2 snapshots, I found gcc 4.2
fortifies its check for function pointer conversion and generates
abort for PEM_read_X509_AUX() and similar wrappers.
There was an old discussion about casting pointer to function
issue - Why does casting a function generate a
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
11 matches
Mail list logo
