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 run-t
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 mainl
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.
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&#x
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 believe I understand your general objection. I don't feel strongly
> about the current behaviour, except that if it has to change then it
> must be a documented extension.
>
> I don't think we can meaningfully order the space of "undefined
> behaviour" and single out some as are "more un
> 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 brea
> 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 t
>
> 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 sa
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 excl
> 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
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 imp
12 matches
Mail list logo
