Steven Bosscher wrote on 28/06/2005 09:55:03:
> On Tuesday 28 June 2005 07:12, Gabriel Dos Reis wrote:
> > For the concrete case at issue, if the hardware I'm writing the C/C++
> > programs for consistently displays modulo arithmetics for signed
> > integer type, Andrew can you tell me why G
As stated earlier, the only patches I'm considering for 4.0.1 at present
are wrong-code cases on primary platforms. There are several open, but
the only one I consider a show-stopper is PR 22051, which Jeff Law is
working on, and hopes to fix Tuesday. As soon as that's in, I'll build
RC3, and
Andrew Pinski wrote on 28/06/2005 08:34:25:
> On Jun 28, 2005, at 1:12 AM, Gabriel Dos Reis wrote:
>
> > So,
> > please, do refrain from reasoning like "since we did X for Y and Y was
> > undefined behaviour, we should do the same for Z." "Undefined
> > behaviour" isn't a 0 or 1 thingy, ev
Michael Veksler <[EMAIL PROTECTED]> writes:
> So maybe introduce a -fsigned-wraps flag, that the user can use
> to make 'int' wrap even in loops.
We have that already, it's called "-fwrapv".
--
Falk
Gabriel Dos Reis wrote:
and it should also be able to take your life. Do you want it to actually
do it? If yes, I suggest you create your own compiler that does that
and leave us work on a compiler that does something more positive.
-- Gaby
Obviously no one programs a compiler to deliberate
Gerald Pfeifer <[EMAIL PROTECTED]> wrote:
>> It would help also if you add to the wiki explanation of what exactly all
>> these options do. Especially bubblestrap vs quickstrap vs restrap.
>
> Why to the WIki?? This should be part of the regular documentation,
> and if anything is to improve, the
On Fri, 2005-06-24 at 07:15, Kazu Hirata wrote:
> Hi,
>
> Why is tail call optimization for Thumb disabled on GCC? I am
> wondering if this is a TODO item or something that we cannot do
> intrinsically.
>
> "The ARM-THUMB Procedure Call Standard" says "No tail continuation in
> Thumb-state" seve
Michael Veksler wrote:
I don't mind MAX_INT+1 being undefined by gcc. I object to drawing from
"undefined" to conclude that is_modulo should be true. This does not
make a practical sense. Drawing conclusions from "undefined" can yield
absurd results.
Yes, but trying to define what you mean by
Mark Mitchell wrote:
Although the standard clearly makes signed overflow undefined, I think
it would be better if GCC defined it to be modulo arithmetic. The
degree to which that would result in inferior code seems likely to be
somewhat small, and the amount of user confusion we would elimina
On Tuesday 28 June 2005 12:07, Robert Dewar wrote:
> Mark Mitchell wrote:
> > Although the standard clearly makes signed overflow undefined, I think
> > it would be better if GCC defined it to be modulo arithmetic. The
> > degree to which that would result in inferior code seems likely to be
> > s
Robert Dewar <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
|
| > and it should also be able to take your life. Do you want it to actually
| > do it? If yes, I suggest you create your own compiler that does that
| > and leave us work on a compiler that does something more positive.
| > -
Steven Bosscher <[EMAIL PROTECTED]> writes:
| On Tuesday 28 June 2005 07:12, Gabriel Dos Reis wrote:
| > For the concrete case at issue, if the hardware I'm writing the C/C++
| > programs for consistently displays modulo arithmetics for signed
| > integer type, Andrew can you tell me why GCC shoul
Steven Bosscher wrote:
> Anyway, I've started a SPEC run with "-O2" vs. "-O2 -fwrapv". Let's see
> how big the damage would be ;-)
Please make sure to include a 64-bit target, where it actually makes any
difference. (I recall performance degradations of 20-30% in some
SPECfp cases from getting
Gabriel Dos Reis wrote:
The issue here is whether if the hardware consistently display a
semantics, GCC should not allow access to that consistent semantics
under the name that "the standard says it is undefined behaviour".
Consider the case of converting a void* to a F*, where F is a function
t
Falk Hueffner <[EMAIL PROTECTED]> writes:
| Michael Veksler <[EMAIL PROTECTED]> writes:
|
| > So maybe introduce a -fsigned-wraps flag, that the user can use
| > to make 'int' wrap even in loops.
|
| We have that already, it's called "-fwrapv".
In the case of C++, it leads to ODR violation beca
Gabriel Dos Reis wrote:
I saw your passsword example but I think it is largely beside the point.
I'm not interested in programming "undefined behaviour". I'm looking
for way to take advantage of that liberty we accept more useful
programs where we can.
The password example is just an example
On Tuesday 28 June 2005 14:02, Ulrich Weigand wrote:
> Steven Bosscher wrote:
> > Anyway, I've started a SPEC run with "-O2" vs. "-O2 -fwrapv". Let's see
> > how big the damage would be ;-)
>
> Please make sure to include a 64-bit target, where it actually makes any
> difference. (I recall perfor
> "Steven" == Steven Bosscher <[EMAIL PROTECTED]> writes:
Steven> Indeed. Frankly this "seems likely" guess confuses me. It
Steven> is already well known that using unsigned types for loop
Steven> counters may greatly improve the code gcc can generate for
Steven> loops. With wrap-around
On Tuesday 28 June 2005 14:16, Paul Koning wrote:
> > "Steven" == Steven Bosscher <[EMAIL PROTECTED]> writes:
>
> Steven> Indeed. Frankly this "seems likely" guess confuses me. It
> Steven> is already well known that using unsigned types for loop
> Steven> counters may greatly improve the
Robert Dewar <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
|
| > The issue here is whether if the hardware consistently display a
| > semantics, GCC should not allow access to that consistent semantics
| > under the name that "the standard says it is undefined behaviour".
| > Consider the
Robert Dewar <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
|
| > I saw your passsword example but I think it is largely beside the point.
| > I'm not interested in programming "undefined behaviour". I'm looking
| > for way to take advantage of that liberty we accept more useful
| > progr
Steven Bosscher <[EMAIL PROTECTED]> wrote on 28/06/2005 15:30:27:
> On Tuesday 28 June 2005 14:16, Paul Koning wrote:
> >
> > I must be missing something.
>
> Yes.
>
> > Unsigned has wraparound (modulo)
> > semantics.
>
> The whole point is that it doesn't.
>
I think that you confuse betwee
On Tuesday 28 June 2005 14:34, Michael Veksler wrote:
> Steven Bosscher <[EMAIL PROTECTED]> wrote on 28/06/2005 15:30:27:
> > On Tuesday 28 June 2005 14:16, Paul Koning wrote:
> > > I must be missing something.
> >
> > Yes.
> >
> > > Unsigned has wraparound (modulo)
> > > semantics.
> >
> > The who
Mark Mitchell wrote:
> I'm sorry this is dragging out, but I think it's worth getting this bug
> fixed.
No need for apologies; you're doing the "right thing".
..Scott
Gabriel Dos Reis wrote:
=
Please do remember that this is hardware dependent. If you have
problems with x86, it does not mean you have the same witha PPC or a
Sparc.
But the whole idea of hardware semantics is bogus, since you are
assuming some connection between C and the hardware which does
Robert Dewar <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
| =
| > Please do remember that this is hardware dependent. If you have
| > problems with x86, it does not mean you have the same witha PPC or a
| > Sparc.
|
| But the whole idea of hardware semantics is bogus, since you are
| as
On Tue, 2005-06-28 at 11:43 +0200, Giovanni Bajo wrote:
> Gerald Pfeifer <[EMAIL PROTECTED]> wrote:
>
> >> It would help also if you add to the wiki explanation of what exactly all
> >> these options do. Especially bubblestrap vs quickstrap vs restrap.
> >
> > Why to the WIki?? This should be par
Gabriel Dos Reis wrote:
Michael Veksler <[EMAIL PROTECTED]> writes:
[...]
| The code is not very simple, and different codes will get optimized
| differently.
| The user will have to learn how to write this piece of code differently for
| each
| processor to have best results.
|
| int wrap_sum
On Tue, Jun 28, 2005 at 02:32:04PM +0200, Gabriel Dos Reis wrote:
> Robert Dewar <[EMAIL PROTECTED]> writes:
>
> | Gabriel Dos Reis wrote:
> |
> | > The issue here is whether if the hardware consistently display a
> | > semantics, GCC should not allow access to that consistent semantics
> | > und
On Jun 28, 2005, at 9:46 AM, Gabriel Paubert wrote:
Now in practice what would be the cost of checking that the divisor
is -1 and take an alternate path that computes the correct
results (in modulo arithmetic) for this case ?
Small compared the division it self but if it is in an inner loop,
Hi,
Can someone point me to list of ISO C++ vs. g++ incompatibilities.
thanks
Nathan Sidwell <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
| > Michael Veksler <[EMAIL PROTECTED]> writes:
| > [...]
| > | The code is not very simple, and different codes will get optimized
| > | differently.
| > | The user will have to learn how to write this piece of code differently
On Jun 28, 2005, at 9:58 AM, Gabriel Dos Reis wrote:
Notice that in your rendition you're assuming that you can convert any
unsigned value > INT_MAX to a int without invoking undefined behaviour.
If you read Nathan's mail correctly, the cast is implementation defined
and not undefined behav
Gabriel Dos Reis wrote:
Nathan Sidwell <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
| > Michael Veksler <[EMAIL PROTECTED]> writes:
| > [...]
| > | The code is not very simple, and different codes will get optimized
| > | differently.
| > | The user will have to learn how to write this
Hi,
I want to get a dump of the whole data structure of my sourcecode
after (all) target independent optimization.
I think the best point to do this is after 'pass_del_ssa'. But I'm
not sure.
At this point the internal representation of the data structure is
'generic' - is this right?
I thi
Andrew Pinski <[EMAIL PROTECTED]> writes:
| On Jun 28, 2005, at 9:58 AM, Gabriel Dos Reis wrote:
|
| > Notice that in your rendition you're assuming that you can convert any
| > unsigned value > INT_MAX to a int without invoking undefined behaviour.
|
|
|
| If you read Nathan's mail correctly,
On Tue, Jun 28, 2005 at 04:11:24PM +0200, nico wrote:
> I want to get a dump of the whole data structure of my sourcecode
> after (all) target independent optimization.
>
Dump flags and switches are dynamically enabled by the pass
manager. Take a look at tree-optimize.c:init_tree_optimization_
On Tue, Jun 28, 2005 at 08:57:20AM -0400, Robert Dewar wrote:
> But the whole idea of hardware semantics is bogus, since you are
> assuming some connection between C and the hardware which does not
> exist. C is not an assembly language.
A non-negligible part of the use of C and even C++ is as a h
- sizeof(int) == 4, sizeof(long long) == 8
I swear 16 bit compilers have sizeof(int) = 2 with sizeof(long) = 4
Gabriel Paubert wrote:
Now in practice what would be the cost of checking that the divisor
is -1 and take an alternate path that computes the correct
results (in modulo arithmetic) for this case ?
We actually had to do this on the x86 early on for GNAT, UGH!
Original Message
>From: Olivier Galibert
>Sent: 28 June 2005 15:25
> In particular, a very large number of C and C++ programs are written
> with the assumptions:
This is a bad line of reasoning in general. There is a vast amount of bad
software in the world, some blatantly buggy, some
On Tue, Jun 28, 2005 at 10:30:39PM +0800, Jonathan Wilson wrote:
> >- sizeof(int) == 4, sizeof(long long) == 8
> I swear 16 bit compilers have sizeof(int) = 2 with sizeof(long) = 4
Yes, and some computers have 9-bit bytes too. Tried running linux,
gnome, kde, gimp, cdrecord, mame, qemu... on them
Olivier Galibert <[EMAIL PROTECTED]> writes:
| On Tue, Jun 28, 2005 at 08:57:20AM -0400, Robert Dewar wrote:
| > But the whole idea of hardware semantics is bogus, since you are
| > assuming some connection between C and the hardware which does not
| > exist. C is not an assembly language.
|
| A
On Tue, Jun 28, 2005 at 03:39:38PM +0100, Dave Korn wrote:
> Original Message
> >From: Olivier Galibert
> >Sent: 28 June 2005 15:25
>
> > In particular, a very large number of C and C++ programs are written
> > with the assumptions:
>
> This is a bad line of reasoning in general. There
Olivier Galibert wrote:
IA-64 may have an issue with sizeof(void (*)()) from what I've heard,
but they have been laughed out of the market.
And this comment is supposed to be from the "real world"? I think not.
Olivier Galibert writes:
> On Tue, Jun 28, 2005 at 03:39:38PM +0100, Dave Korn wrote:
> > Original Message
> > >From: Olivier Galibert
> > >Sent: 28 June 2005 15:25
> >
> > > In particular, a very large number of C and C++ programs are written
> > > with the assumptions:
> >
> >
Gabriel Dos Reis wrote on 28/06/2005 17:12:43:
> Andrew Pinski <[EMAIL PROTECTED]> writes:
>
> | On Jun 28, 2005, at 9:58 AM, Gabriel Dos Reis wrote:
> |
> | > Notice that in your rendition you're assuming that you can convert
any
> | > unsigned value > INT_MAX to a int without invoking undefi
On Tue, 2005-06-28 at 00:20 -0700, Mark Mitchell wrote:
> As stated earlier, the only patches I'm considering for 4.0.1 at present
> are wrong-code cases on primary platforms. There are several open, but
> the only one I consider a show-stopper is PR 22051, which Jeff Law is
> working on, and h
Michael Veksler wrote:
So what does gcc gives for (int) (MAX_INT+1U)?
Maybe it is constrained such that
(int)(unsigned)a == a
For 1's complement the reverse seems to be incorrect:
unsigned a= 0x; // or was it 0x8000?
assert((unsigned)(int)a == a); // may fail
why are you ta
Jeffrey A Law wrote:
On Tue, 2005-06-28 at 00:20 -0700, Mark Mitchell wrote:
As stated earlier, the only patches I'm considering for 4.0.1 at present
are wrong-code cases on primary platforms. There are several open, but
the only one I consider a show-stopper is PR 22051, which Jeff Law is
w
Michael Veksler <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote on 28/06/2005 17:12:43:
|
| > Andrew Pinski <[EMAIL PROTECTED]> writes:
| >
| > | On Jun 28, 2005, at 9:58 AM, Gabriel Dos Reis wrote:
| > |
| > | > Notice that in your rendition you're assuming that you can convert
| any
| > |
Nathan Sidwell <[EMAIL PROTECTED]> wrote on 28/06/2005 18:48:26:
>
> why are you talking about one's complement in the context of gcc. From
> implement-c.texi
>
>@cite{Whether signed integer types are represented using sign and
magnitude,
>two's complement, or one's complement, and
On Jun 28, 2005, at 11:58 AM, Michael Veksler wrote:
Sorry, did not realize this was documented this way.
Is "implement-c.texi" part of the user visible documentation, or is it
targeted for gcc developers?
http://gcc.gnu.org/onlinedocs/gcc/C-Implementation.html#C-Implementation
in the norma
On Tue, 2005-06-28 at 08:50 -0700, Mark Mitchell wrote:
> Perhaps you could get a patch put together, test it by staring
> atassembly output, and then ask for a volunteer to test it? I expect
> that Joseph could do a test run on PA-HPUX for you.
It might be the best bet. I'm going to clean out
On Tue, Jun 28, 2005 at 10:06:35AM -0600, Jeffrey A Law wrote:
> On Tue, 2005-06-28 at 08:50 -0700, Mark Mitchell wrote:
> > Perhaps you could get a patch put together, test it by staring
> > atassembly output, and then ask for a volunteer to test it? I expect
> > that Joseph could do a test run
On Tue, Jun 28, 2005 at 10:23:51AM +0300, Michael Veksler wrote:
On Jun 28, 2005, at 1:12 AM, Gabriel Dos Reis wrote:
> > > So,
> > > please, do refrain from reasoning like "since we did X for Y and Y was
> > > undefined behaviour, we should do the same for Z." "Undefined
> > > behaviour" isn
On Tue, Jun 28, 2005 at 08:57:20AM -0400, Robert Dewar wrote:
> Gabriel Dos Reis wrote:
> =
> >Please do remember that this is hardware dependent. If you have
> >problems with x86, it does not mean you have the same witha PPC or a
> >Sparc.
>
> But the whole idea of hardware semantics is bogus,
Michael Veksler <[EMAIL PROTECTED]> writes:
| Nathan Sidwell <[EMAIL PROTECTED]> wrote on 28/06/2005 18:48:26:
|
| >
| > why are you talking about one's complement in the context of gcc. From
| > implement-c.texi
| >
| >@cite{Whether signed integer types are represented using sign and
| magn
On Tue, Jun 28, 2005 at 03:39:38PM +0100, Dave Korn wrote:
> Original Message
> >From: Olivier Galibert
> >Sent: 28 June 2005 15:25
>
> > In particular, a very large number of C and C++ programs are written
> > with the assumptions:
>
> This is a bad line of reasoning in general. There
On Tue, 28 Jun 2005, Gabriel Dos Reis wrote:
> Yes, we should document this. In general, implementation defined
> aspects (and some of the undefined behaviour aspects) are missing
> documentation for C++ -- JSM did some work for that for C.
Is there a convenient checklist for C++ similar to C99'
On Mon, Jun 27, 2005 at 08:05:48PM -0700, Mark Mitchell wrote:
> Michael Veksler wrote:
>
> >>Most programmers "know" that arithmetic is modulo wordsize. And those few
> >>who know the right answer (only unsigned arithmetic is modulo) will
> >>from time to time slip up and omit the "unsigned" key
On Tue, Jun 28, 2005 at 09:32:49AM -0700, Joe Buck wrote:
> /* int a, b, c; */
> if (b > 0) {
> a = b + c;
> int count;
> for (int i = c; i <= a; i++)
> count++;
> some_func(count);
> }
I forgot to initialize count to 0, of course.
> In particular, a very large number of C and C++ programs are written
> with the assumptions:
>- signed and unsigned types are modulo, except in loop induction
> variables where it's bad taste
Well, as demonstrated by INT_MIN/-1, gcc has NEVER fulfilled such assumptions
on i86 and, quite likely,
Daniel Berlin <[EMAIL PROTECTED]> wrote:
>> Well, because Wiki is more attractive to people writing
>> documentation for several reasons (faster than writing a HTML/TeX
>> patch and submitting it for review, etc.). Maybe we should think if
>> we want to use the Wiki as our rapid documentation prot
On Tue, Jun 28, 2005 at 03:57:31PM +0200, Mirza took 0 lines to write:
> Hi,
>
> Can someone point me to list of ISO C++ vs. g++ incompatibilities.
>
See http://gcc.gnu.org/bugs.html#cxx. There is a second C++ section
near the bottom of the same page; there's a list of C++ extensions
in "info gc
Joe Buck wrote:
I don't think we should give the user any such promise, and if we do
give such a promise, we will never catch icc. The main problem is that
we will no longer be able to optimize many loops.
It's entirely possible that I was naive in assuming that this wouldn't
have a big opti
Joe Buck <[EMAIL PROTECTED]> writes:
| On Tue, Jun 28, 2005 at 10:23:51AM +0300, Michael Veksler wrote:
|
|
| On Jun 28, 2005, at 1:12 AM, Gabriel Dos Reis wrote:
| > > > So,
| > > > please, do refrain from reasoning like "since we did X for Y and Y was
| > > > undefined behaviour, we should
On Tue, 28 Jun 2005, Mark Mitchell wrote:
Joe Buck wrote:
I don't think we should give the user any such promise, and if we do
give such a promise, we will never catch icc. The main problem is that
we will no longer be able to optimize many loops.
It's entirely possible that I was naive i
Original Message
>From: Joe Buck
>Sent: 28 June 2005 17:42
> On Tue, Jun 28, 2005 at 03:39:38PM +0100, Dave Korn wrote:
>> Original Message
>>> From: Olivier Galibert
>>> Sent: 28 June 2005 15:25
>>
>>> In particular, a very large number of C and C++ programs are written
>>> with
Original Message
>From: Dickson Patton
>Sent: 27 June 2005 18:41
> All,
>
> LCOV looks like what we were planning. Let's steal it.
>
> See you at 7:00.
>
>
> Dickson
Sorry, I couldn't make it. Did you save any beer for me?
cheers,
DaveK
P.S. Don't you think a "sen
On Tue, Jun 28, 2005 at 04:03:49PM +0100, Andrew Haley wrote:
> Olivier Galibert writes:
> > On Tue, Jun 28, 2005 at 03:39:38PM +0100, Dave Korn wrote:
> > > Original Message
> > > >From: Olivier Galibert
> > > >Sent: 28 June 2005 15:25
> > >
> > > > In particular, a very large numbe
On Tue, Jun 28, 2005 at 06:10:26PM +0100, Dave Korn wrote:
> >>> - sizeof(int) == 4, sizeof(long long) == 8
> >>>
> >>> - sizeof(long) == sizeof(void *) == sizeof(void (*)())
> >> And what about 64 bit architectures? Your assumptions are already
> >> widely invalid and only going to get more s
On Tue, Jun 28, 2005 at 12:59:10PM -0400, Morten Welinder wrote:
> > In particular, a very large number of C and C++ programs are written
> > with the assumptions:
>
> >- signed and unsigned types are modulo, except in loop induction
> > variables where it's bad taste
>
> Well, as demonstrated by
Mirza <[EMAIL PROTECTED]> wrote:
> Can someone point me to list of ISO C++ vs. g++ incompatibilities.
There are very few large issues at this point. The only big feature missing is
"export", then it's a bunch of relatively minor nits (access checking in friend
declarations within templates, corre
On Tue, Jun 28, 2005 at 07:02:49PM +0200, Gabriel Dos Reis wrote:
> | Since behavior on integer overflow is undefined, we can optimize assuming
> | that overflow has not occurred. Then a > c, so the for loop always
> | executes b+1 times, and we end up with
> |
> | if (b > 0)
> | some_fun
On Tue, Jun 28, 2005 at 07:02:49PM +0200, Gabriel Dos Reis wrote:
> We document that
>
> a = (int) ((unsigned) b + c)
>
> is well-defined and given by the wrapping semantics. Does the current
> optimizer takes that into account or will it assume b+1 execution times?
>
I fixed this bu
Original Message
>From: Olivier Galibert
>Sent: 28 June 2005 18:18
> On Tue, Jun 28, 2005 at 04:03:49PM +0100, Andrew Haley wrote:
>> Olivier Galibert writes:
>> > On Tue, Jun 28, 2005 at 03:39:38PM +0100, Dave Korn wrote: > >
>> Original Message > > >From: Olivier Galibert
>>
Gabriel Dos Reis writes:
> Steven Bosscher <[EMAIL PROTECTED]> writes:
>| On Tuesday 28 June 2005 07:12, Gabriel Dos Reis wrote:
>| > For the concrete case at issue, if the hardware I'm writing the C/C++
>| > programs for consistently displays modulo arithmetics for signed
>| > integer type, Andrew
On Tue, 2005-06-28 at 10:02 -0700, Mark Mitchell wrote:
> Joe Buck wrote:
> >
> > int blah(int);
> >
> > int func(int a, int b) {
> > if (b >= 0) {
> > int c = a + b;
> > int count = 0;
> > for (int i = a; i <= c; i++)
> > count++;
> > blah(count);
> > }
> > }
>
On Tue, Jun 28, 2005 at 07:17:52PM +0200, Olivier Galibert wrote:
> On Tue, Jun 28, 2005 at 04:03:49PM +0100, Andrew Haley wrote:
> > This is childish and insulting.
>
> Calling a large part of the programs out there, including a non
> negligible subpart of what I personally write either "blatantl
"Joseph S. Myers" <[EMAIL PROTECTED]> writes:
| On Tue, 28 Jun 2005, Gabriel Dos Reis wrote:
|
| > Yes, we should document this. In general, implementation defined
| > aspects (and some of the undefined behaviour aspects) are missing
| > documentation for C++ -- JSM did some work for that for C.
On Tue, Jun 28, 2005 at 06:36:26PM +0100, Dave Korn wrote:
> It certainly wasn't meant to be. It was meant to be a dispassionate
> description of the state of facts. Software that violates the C standard
> just *is* "buggy" or "incorrect", and your personal pride has absolutely
> nothing to do
Joe Buck <[EMAIL PROTECTED]> writes:
| On Tue, Jun 28, 2005 at 07:02:49PM +0200, Gabriel Dos Reis wrote:
| > | Since behavior on integer overflow is undefined, we can optimize assuming
| > | that overflow has not occurred. Then a > c, so the for loop always
| > | executes b+1 times, and we end up
Daniel Berlin wrote:
On Tue, 28 Jun 2005, Mark Mitchell wrote:
Joe Buck wrote:
I don't think we should give the user any such promise, and if we do
give such a promise, we will never catch icc. The main problem is that
we will no longer be able to optimize many loops.
It's entirely poss
Joe Buck <[EMAIL PROTECTED]> writes:
| On Tue, Jun 28, 2005 at 07:17:52PM +0200, Olivier Galibert wrote:
| > On Tue, Jun 28, 2005 at 04:03:49PM +0100, Andrew Haley wrote:
| > > This is childish and insulting.
| >
| > Calling a large part of the programs out there, including a non
| > negligible s
On Tue, Jun 28, 2005 at 10:50:39AM -0700, Joe Buck wrote:
> On Tue, Jun 28, 2005 at 07:17:52PM +0200, Olivier Galibert wrote:
> > On Tue, Jun 28, 2005 at 04:03:49PM +0100, Andrew Haley wrote:
> > > This is childish and insulting.
> >
> > Calling a large part of the programs out there, including a
Original Message
>From: Olivier Galibert
>Sent: 28 June 2005 19:02
> On Tue, Jun 28, 2005 at 06:36:26PM +0100, Dave Korn wrote:
>> It certainly wasn't meant to be. It was meant to be a dispassionate
>> description of the state of facts. Software that violates the C standard
>> just *is
On Tue, 2005-06-28 at 08:50 -0700, Mark Mitchell wrote:
> Jeffrey A Law wrote:
> > On Tue, 2005-06-28 at 00:20 -0700, Mark Mitchell wrote:
> >
> >>As stated earlier, the only patches I'm considering for 4.0.1 at present
> >>are wrong-code cases on primary platforms. There are several open, but
Hello,
with current GCC mainline bootstrap fails on s390(x)-ibm-linux
during stage2 build with:
../../gcc-head/gcc/tree-ssa-operands.c: In function 'finalize_ssa_uses':
../../gcc-head/gcc/tree-ssa-operands.c:570: error: Definition in block 64 does
not dominate use in block 13
for SSA_NAME: TMT.6
Original Message
>From: Olivier Galibert
>Sent: 28 June 2005 19:29
> Incidentally, gcc itself makes most of these assumptions in its own
> code. I kinda doubt you can run it on a dsp or a machine with 16-bits
> ints. Which is different than generating code for them.
They aren't assump
The same failure occurs on PowerPC:
http://gcc.gnu.org/ml/gcc-regression/2005-06/msg00090.html
David
On Jun 28, 2005, at 2:38 PM, Ulrich Weigand wrote:
Hello,
with current GCC mainline bootstrap fails on s390(x)-ibm-linux
during stage2 build with:
../../gcc-head/gcc/tree-ssa-operands.c: In function
'finalize_ssa_uses':
../../gcc-head/gcc/tree-ssa-operands.c:570: error: Definition in block
Morten Welinder wrote on 28/06/2005 19:59:10:
> > In particular, a very large number of C and C++ programs are written
> > with the assumptions:
>
> >- signed and unsigned types are modulo, except in loop induction
> > variables where it's bad taste
>
> Well, as demonstrated by INT_MIN/-1, g
Olivier Galibert wrote:
Calling a large part of the programs out there, including a non
negligible subpart of what I personally write either "blatantly buggy"
or "subtly-incorrect" is somewhat childish and insulting.
nope, I don't see it that way at all, this is just a statement of fact
wrt th
On Tue, Jun 28, 2005 at 08:38:13PM +0200, Ulrich Weigand wrote:
> Hello,
>
> with current GCC mainline bootstrap fails on s390(x)-ibm-linux
> during stage2 build with:
>
I'm on it.
Diego.
Olivier Galibert wrote:
On Tue, Jun 28, 2005 at 06:36:26PM +0100, Dave Korn wrote:
It certainly wasn't meant to be. It was meant to be a dispassionate
description of the state of facts. Software that violates the C standard
just *is* "buggy" or "incorrect", and your personal pride has absolu
Gabriel Dos Reis wrote:
But the compiler miscompiled the Unix kernel -- which, apart from has
history intermixed with the C language design, was relying on
"undocumented" aspect of "undefined behaviour". Nobdoy was willing to
buy the compiler. The company ran out of business.
Could you pleas
"Dave Korn" <[EMAIL PROTECTED]> writes:
[...]
| >Maybe you should reread what I was replying to:
| >
| > On Tue, Jun 28, 2005 at 08:57:20AM -0400, Robert Dewar wrote:
| >> But the whole idea of hardware semantics is bogus, since you are
| >> assuming some connection between C and the hardware wh
Robert Dewar <[EMAIL PROTECTED]> writes:
| Olivier Galibert wrote:
|
| > Calling a large part of the programs out there, including a non
| > negligible subpart of what I personally write either "blatantly buggy"
| > or "subtly-incorrect" is somewhat childish and insulting.
|
| nope, I don't see
On Tue, Jun 28, 2005 at 07:36:00PM +0100, Dave Korn wrote:
> Original Message
> >From: Olivier Galibert
> >Sent: 28 June 2005 19:02
>
> > On Tue, Jun 28, 2005 at 06:36:26PM +0100, Dave Korn wrote:
> >> It certainly wasn't meant to be. It was meant to be a dispassionate
> >> description
1 - 100 of 154 matches
Mail list logo
