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
> Hmm, as far as I can tell, stage1 i386.c:ix86_split_ashr has been
> miscompiled by gcc (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-54).
Thanks a bunch for sorting this out!
--
Eric Botcazou
Andrew Haley wrote:
>
> So it seems I have to abandom the system compiler for doing bootstraps.
Can you make a simple testcase for this?
Andrew.
Attached.
This fails at -O0..-O2 for gcc 3.2.2 and gcc 3.2.3 on
i686-pc-linux-gnu. For gcc 3.4.3,
it still fails at -O1.
4.2.0 appears to b
(Resending after update on archive link below.)
A proposal was made to pick one the Decimal Floating-Point encodings from
the IEEE754r draft in the x86-64 psABI a few weeks ago (see thread starting
at http://www.amd64.org/lists/discuss/thrd215.html#08857). Given that any
such decision can have mu
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
David Edelsohn wrote:
> I am pleased to announce that the GCC Steering Committee has
> appointed Ulrich Weigand to the role of reload maintainer.
Thank you!
> Please join me in congratulating Ulrich on his new role. Ulrich,
> please update your entry in the MAINTAINERS file.
I've c
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
Hi,
On Wednesday 05 July 2006 20:26, Dave Korn wrote:
> I believe Lionel's real problem is likely to be that he was hoping that
> turning on the "-mmx -sse -sse2 -3dnow" options would auto-vectorise his code
> for him.
>
> Lionel, (IIUIC) those options just /enable/ the use of the various SI
Mark Mitchell wrote:
I'm not sure the number above is in and of itself terribly meaningful,
in part because Volker has been filing many
ICE-on-invalid-after-error-message PRs against the C++ front end. These
don't really even show up for users in releases, due to the "confused by
earlier errors
On 05 July 2006 19:11, Rene Rebe wrote:
> Hi,
>
> On Wednesday 05 July 2006 19:57, Mike Stump wrote:
>> On Jul 4, 2006, at 7:43 PM, [EMAIL PROTECTED] wrote:
>>> The codec is at http://www.sourceforge.net/projects/openavs/.
>>> Currently, it requires a 3Ghz or better CPU to get a resonable
>>> fra
Hi,
On Wednesday 05 July 2006 19:57, Mike Stump wrote:
> On Jul 4, 2006, at 7:43 PM, [EMAIL PROTECTED] wrote:
> > The codec is at http://www.sourceforge.net/projects/openavs/.
> > Currently, it requires a 3Ghz or better CPU to get a resonable
> > framerate. I would like the codec to be useful ev
On Jul 4, 2006, at 7:43 PM, [EMAIL PROTECTED] wrote:
The codec is at http://www.sourceforge.net/projects/openavs/.
Currently, it requires a 3Ghz or better CPU to get a resonable
framerate. I would like the codec to be useful even on 586
( 1Ghz or
so ). Any ideas?
Recode slower parts in as
Joern RENNECKE writes:
> Joern Rennecke wrote:
>
> > Eric Botcazou wrote:
> >
> >>> make[3]: Leaving directory `/mnt/scratch/nightly/2006-07-04/i686'
> >>> Comparing stages 2 and 3
> >>> warning: ./cc1-checksum.o differs
> >>> warning: ./cc1plus-checksum.o differs
> >>> warning: ./cc1obj-
On Jul 5, 2006, at 2:26 AM, J.J.Garcia wrote:
Can i assume that what im using (2.95.2.1) is the last used
previously to
release 2.95.3 20010315 (release)?
Not really. If you were going to stake your life on it, you'd not
want to do that. I doubt the stakes are that high however. Anyway,
Joern Rennecke wrote:
Eric Botcazou wrote:
make[3]: Leaving directory `/mnt/scratch/nightly/2006-07-04/i686'
Comparing stages 2 and 3
warning: ./cc1-checksum.o differs
warning: ./cc1plus-checksum.o differs
warning: ./cc1obj-checksum.o differs
Bootstrap comparison failure!
Does the attach
> No, I still get the same set of .o files that differ, and the -fdump-noaddr
> (See PR other/28251) peephole2 dump for cfg.c compiled with stage1 /
> stage2 cc1 is still the same.
Then I'm puzzled. The original patch is supposed to be essentially a nop for
languages that do not use ARRAY_RANGE
Eric Botcazou wrote:
make[3]: Leaving directory `/mnt/scratch/nightly/2006-07-04/i686'
Comparing stages 2 and 3
warning: ./cc1-checksum.o differs
warning: ./cc1plus-checksum.o differs
warning: ./cc1obj-checksum.o differs
Bootstrap comparison failure!
Does the attached patch make any diffe
>
> 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
> >
Kazu Hirata wrote:
> Hi Ian,
>
>>> I keep finding places in GCC sources that check whether a member of
>>> TYPE_ARG_TYPES is 0. For example,
>>>
>>> for (link = TYPE_ARG_TYPES (function_or_method_type);
>>> link && TREE_VALUE (link);
>>> link = TREE_CHAIN (link))
>>>gen_type_die
Hi Ian,
I keep finding places in GCC sources that check whether a member of
TYPE_ARG_TYPES is 0. For example,
for (link = TYPE_ARG_TYPES (function_or_method_type);
link && TREE_VALUE (link);
link = TREE_CHAIN (link))
gen_type_die (TREE_VALUE (link), context_die);
Notice that T
On Wed, Jul 05, 2006 at 11:49:58AM -0400, Daniel Berlin wrote:
> I believe it also happens with varargs functions in some cases, if there
> was nothing but a varargs parameter.
I was recently reminded that that's not valid C. Is there any language
which lets you get away with only unnamed argumen
Daniel Berlin wrote:
> I believe it also happens with varargs functions in some cases, if there
> was nothing but a varargs parameter.
This is the one and only case in which it should occur, but, yes, it is
possible.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Ian Lance Taylor wrote:
> Kazu Hirata <[EMAIL PROTECTED]> writes:
>
>> I keep finding places in GCC sources that check whether a member of
>> TYPE_ARG_TYPES is 0. For example,
>>
>> for (link = TYPE_ARG_TYPES (function_or_method_type);
>>link && TREE_VALUE (link);
>>link = TREE_
Kazu Hirata <[EMAIL PROTECTED]> writes:
> I keep finding places in GCC sources that check whether a member of
> TYPE_ARG_TYPES is 0. For example,
>
> for (link = TYPE_ARG_TYPES (function_or_method_type);
>link && TREE_VALUE (link);
>link = TREE_CHAIN (link))
> gen_type_die
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
Hi,
I keep finding places in GCC sources that check whether a member of
TYPE_ARG_TYPES is 0. For example,
for (link = TYPE_ARG_TYPES (function_or_method_type);
link && TREE_VALUE (link);
link = TREE_CHAIN (link))
gen_type_die (TREE_VALUE (link), context_die);
Notice that TRE
This question is not appropriate for the gcc@gcc.gnu.org mailing list.
It would be appropriate on the [EMAIL PROTECTED] mailing list.
Thanks.
[EMAIL PROTECTED] writes:
> I am wondering if i have used -O, -O2 or -O3, do i still benifit from
> flags such as -march -fmpmath -ffast-math -mmx -sse -s
> 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
Mike Stump wrote:
> svn ls -r40553 svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-2_95-branch/
> gcc/testsuite
>
> appears to be fairly close. Don't know why the tag was messed up.
>
> This number comes from the tags/gcc-2_95_3 tag.
>
Thx a lot Mike,
This is what i get from svn repo (after import
50 matches
Mail list logo
