Ian Lance Taylor wrote:
Ryan Hill [EMAIL PROTECTED] writes:
Was there ever any action on this? AFAICS consensus was that the trap
would be removed and this behaviour be documented as an extension.
There was a bit more discussion of how exactly the documentation would
be worded[i] and the
On 3/25/07, Ryan Hill [EMAIL PROTECTED] wrote:
I couldn't find one so I've filed PR #31359. Apologies if it's a duplicate.
I will again say, undocumented extensions don't exist (except for
the case where the documentation is in the source and this was not one
of those cases). This was just
Mark Mitchell wrote:
Ian Lance Taylor wrote:
I realized that I am still not stating my position very clearly. I
don't think we should make any extra effort to make this code work:
after all, the code is undefined. I just think 1) we should not
insert a trap; 2) we should not ICE.
I
Ryan Hill [EMAIL PROTECTED] writes:
Mark Mitchell wrote:
Ian Lance Taylor wrote:
I realized that I am still not stating my position very clearly. I
don't think we should make any extra effort to make this code work:
after all, the code is undefined. I just think 1) we should not
Andrew Haley wrote:
Yuri Pudgorodsky writes:
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
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
Yuri Pudgorodsky writes:
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
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 behaviour.
-- Gaby
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
Yuri Pudgorodsky [EMAIL PROTECTED] writes:
| 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
Mark Mitchell [EMAIL PROTECTED] writes:
| Ian Lance Taylor wrote:
|
| I realized that I am still not stating my position very clearly. I
| don't think we should make any extra effort to make this code work:
| after all, the code is undefined. I just think 1) we should not
| insert a trap;
Mark Mitchell writes:
I also agree with Gaby that we should document this as an extension. If
we go to the work of putting it back in, we should ensure that it
continues to work for the foreseeable future. Part of that is writing
down what we've decided.
We can't make function
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 for
Ian Lance Taylor writes:
Andrew Haley [EMAIL PROTECTED] writes:
Ian Lance Taylor writes:
Yuri Pudgorodsky [EMAIL PROTECTED] writes:
Compiling openssl-0.9.8b with gcc-4.2 snapshots, I found gcc 4.2
fortifies its check for function pointer conversion and generates
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 anyways.
What are you trying
Andrew Haley [EMAIL PROTECTED] writes:
[...]
| If we're going to guarantee this stuff for the future, we'll have to
| fix the bug, make sure it's doesn't destabilize the compiler and write
| some test cases. If we're really serious about it we should make it a
| documented extension to C.
if
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,
Yuri Pudgorodsky [EMAIL PROTECTED] writes:
| 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.
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
Ian Lance Taylor writes:
Andrew Haley [EMAIL PROTECTED] writes:
If we're going to guarantee this stuff for the future, we'll have
to fix the bug, make sure it's doesn't destabilize the compiler
and write some test cases. If we're really serious about it we
should make it a
What do we do if compiler ICE generating code for valid C syntax with
defined behavior? Fix it!
Why should we go another way for valid C syntax with undefined behavior?
The answer is in the question, no?
--
Eric Botcazou
Ian Lance Taylor [EMAIL PROTECTED] writes:
I personally don't agree that this needs to be a documented extension.
I'm simply going on a more general rule which I tried to state above:
I don't think we should insert a trap call for undefined code.
I realized that I am still not stating my
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
Andrew Haley [EMAIL PROTECTED] writes:
If we make a change for openssh to allow this undefined behaviour,
then do we agree to keep it working or not? If we agree that we will,
then we have to at least add some test cases and we have to add some
internal documentation to gcc. If we don't
Ian Lance Taylor writes:
Andrew Haley [EMAIL PROTECTED] writes:
If we make a change for openssh to allow this undefined behaviour,
then do we agree to keep it working or not? If we agree that we will,
then we have to at least add some test cases and we have to add some
internal
On Jul 5, 2006, at 8:38 AM, Ian Lance Taylor wrote:
To me this is related to the point I raised at the steering committee
panel discussion (I know you weren't there): I think we are too casual
about breaking existing working code.
What happens when a target comes along and passes different
On Wed, Jul 05, 2006 at 09:11:32AM -0700, Andrew Pinski wrote:
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
Andrew Pinski [EMAIL PROTECTED] writes:
On Jul 5, 2006, at 8:38 AM, Ian Lance Taylor wrote:
To me this is related to the point I raised at the steering committee
panel discussion (I know you weren't there): I think we are too casual
about breaking existing working code.
What happens
On 05 July 2006 17:12, Andrew Pinski wrote:
On Jul 5, 2006, at 8:38 AM, Ian Lance Taylor wrote:
To me this is related to the point I raised at the steering committee
panel discussion (I know you weren't there): I think we are too casual
about breaking existing working code.
What happens
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
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 excluded been fixed? If so, while
I don't like the semantics in place now, I'd
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 excluded been fixed? If so, while
I
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
Ian Lance Taylor [EMAIL PROTECTED] writes:
[...]
| I personally don't agree that this needs to be a documented extension.
| I'm simply going on a more general rule which I tried to state above:
| I don't think we should insert a trap call for undefined code.
If it should not a documented
Ian Lance Taylor [EMAIL PROTECTED] writes:
| Andrew Haley [EMAIL PROTECTED] writes:
|
| If we make a change for openssh to allow this undefined behaviour,
| then do we agree to keep it working or not? If we agree that we will,
| then we have to at least add some test cases and we have to add
Ian Lance Taylor wrote:
I realized that I am still not stating my position very clearly. I
don't think we should make any extra effort to make this code work:
after all, the code is undefined. I just think 1) we should not
insert a trap; 2) we should not ICE.
I agree. If the inlining
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
Yuri Pudgorodsky [EMAIL PROTECTED] writes:
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.
Personally speaking, I agree with you that the compiler should
Ian Lance Taylor writes:
Yuri Pudgorodsky [EMAIL PROTECTED] writes:
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.
Personally speaking, I agree
Andrew Haley [EMAIL PROTECTED] writes:
Ian Lance Taylor writes:
Yuri Pudgorodsky [EMAIL PROTECTED] writes:
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
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
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
-- Pinski
43 matches
Mail list logo
