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 jus
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]
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
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.
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 po
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 earlie
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
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
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 poin
> 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
Andrew Haley wrote:
> 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 dec
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 po
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 t
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
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
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 exten
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
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
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 rat
>
> 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
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
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.
>
> Wha
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
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 po
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
> >
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'
> 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
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
> 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 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
> 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
Andrew Haley <[EMAIL PROTECTED]> writes:
> > > keating> Because if you *do* try to inline the call, you will get an ICE.
> >
> > Yes, I agree that the ICE, if it still exists, would have to be fixed,
> > but to me that seems like a separate issue.
>
> No, it isn't a separate issue. We gener
>
> 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
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 seman
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
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 be
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
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 t
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 conversi
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 fi
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
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 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_X50
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 speaki
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
45 matches
Mail list logo
