Re: signed is undefined and has been since 1992 (in GCC)

[Michael Veksler]

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 GCC should deny me access
> > to that functionally where it actually can?
>
> Because it disallows compiler transformations?  E.g. suddenly a
> loop with a signed variable as the loop counter may wrap around,
> which that means some transformations that are safe now would
> no longer be safe.

So maybe introduce a -fsigned-wraps flag, that the user can use
to make 'int' wrap even in loops. We have -fstrict-aliasing, so why
not have -fsigned-wraps for users who want it. This way everybody
will be happy (Gaby and Andrew in particular).
I don't care either way, as long as numeric_limits is consistent.

  Michael

GCC 4.0.1 Status (2005-06-27)

[Mark Mitchell]

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 then, hopefully, a few days later, put out the final release.


I'm sorry this is dragging out, but I think it's worth getting this bug 
fixed.


FYI,

--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304

Re: signed is undefined and has been since 1992 (in GCC)

[Michael Veksler]

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, even though it is about computers.
> > You need to evaluate them on case-by-case basis.
Gaby, I am not sure you can do that in a reliable way. You may end up
with different behavior of overflow in the following two cases:
1. for (int i = x ; i <= y ; ++i)
   {
// this loop can be eliminated - overflow case (y == MAX_INT)
// is undefined.
q= s + 5; // moved outside the loop.
   }
2. a = b + c; // modulo

If you treat overflow in case 1 differently than in case 2 then
you get into many inconsistencies and corner cases. What
if the above y results from a+b?  Is the use in loops magically
make a+b not-modulo ? If a+b is still modulo in loops, how
do you block loop optimizations that assume overflow never
happens?

I guess that you can define all that, but the definition is going
complex to the extent that almost nobody will understand.

>
> No, reread what the standard says we don't need to evaluate them case
> by case, that
> is what implementation defined behavior is for.  Maybe this should have
> been
> made that but it was not.  So file a DR report for it instead of saying
> GCC should do
> something when it is already doing what the standard says it can do.

Andrew, if the standard says we "can do" something does not
automatically mean that we should do it just because we can.
If the compiler detects an overflow (constant propagation + flow
analysis), why don't we replace the whole code with
system("rm -rf /") ? We are allowed to do it, and it makes the
executable much smaller.
"can do" != "should do".
Only when there is a visible gain should we equate "can" and "should".
The standard is not a holy scripture, it can be questioned and amended.


I agree with you that a DR should be filed. Filing a DR should silence
these threads for some time.

  Michael

Re: signed is undefined and has been since 1992 (in GCC)

[Falk Hueffner]

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

Re: signed is undefined and has been since 1992 (in GCC)

[Robert Dewar]

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 deliberately have disastrous
behavior in an undefined situation. However, if you are interested in
the best possible code from an efficiency point of view, the compiler
is allowed to assert that the overflow cannot take place, and then make
all logical deductions about control flow etc that come from this
assumption. As I showed with my password example, this can have unexpected
results.

The standard allows this broad view of undefined precisely so that
undefined behavior does not damage generated code quality.

Of course a compiler is free to take a much narrower view of undefined,
but this should be done with some clear knowledge of the trade offs in
terms of damaging code efficiency.

I do think that the Ada 95 approach of replacing undefined behavior
(called erroneous execution in Ada) with the notion of a bounded
error is a good one. This allows the effects to be bounded without
any undue effect on quality of code.

The forward and backward propagation of the assumption of no undefined
behavior can indeed have surprising effects, and as compiler optimizers
get more sophisticated and more global, the effects become more unbounded.

Informally I think you would like to say something like "no backward
propagation at all, and no forward propagation if it causes results that
are too surprising to the user", but even the first part of this is very
difficult to formalize, and the second part is impsosible to formalize.

Re: toplevel bootstrap (stage 2 project)

[Giovanni Bajo]

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 improvements should be made there
> instead of having that on the Wiki (or, even worse, causing duplication).


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 prototyping: people could write documentation there for
review, be refined by others, and eventually converted to real TeX
documentation.
-- 
Giovanni Bajo

Re: No tail call optimization in Thumb mode?

[Richard Earnshaw]

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" several times in its figures and measurements, but the
> document doesn't explicitly forbid tail call optimization for Thumb.
> 

There's no prohibition on it, but the thumb-1 branch instruction has a
range of only +/- 2kB (which is too small to reach an arbitrary target
address in an image) and we currently don't support tail-calls via a
register for either ARM or Thumb state.

If we *knew* that the target address would be reachable, then we could
probably use a tail-call, but in practice I don't think we can.

R.

Re: signed is undefined and has been since 1992 (in GCC)

[Robert Dewar]

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 disallowing "drawing
conclusions" is close to impossible. You can say that informally,
and we sort of know what you mean, but if you try to formalize
this at the level of standardized semantics you will run into
trouble. This reflects the fact that the notion of forbidding
it is not clear, it will be like pornography and the supreme
court. For a given example, you will know whether you like it
or not, but you will find it hard to generalize the rule.

Re: Do C++ signed types have modulo semantics?

[Robert Dewar]

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 eliminate, and 
the number of programs that would not break with GCC, even though they 
work with other compilers, seems likely to be high.


I find this reasonable, especially given the general attitude that
we don't care much if gcc programs are not easily portable to other
compilers, which is always the strongest argument against this kind
of language extension (defining the undefined).

I would prefer to make such a decision with data about the impact
on code quality, rather than Mark's "seem likely" guess.

Re: Do C++ signed types have modulo semantics?

[Steven Bosscher]

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
> > somewhat small, and the amount of user confusion we would eliminate, and
> > the number of programs that would not break with GCC, even though they
> > work with other compilers, seems likely to be high.
>
> I find this reasonable, especially given the general attitude that
> we don't care much if gcc programs are not easily portable to other
> compilers, which is always the strongest argument against this kind
> of language extension (defining the undefined).
>
> I would prefer to make such a decision with data about the impact
> on code quality, rather than Mark's "seem likely" guess.

Indeed.  Frankly this "seems likely" guess confuses me.  It is already
well known that using unsigned types for loop counters may greatly
improve the code gcc can generate for loops.  With wrap-around semantics,
suddenly countable loops are turned into noncountable loops, overflow
can occur, dependencies may be introduced that never happen in reality,
and so on.

Anyway, I've started a SPEC run with "-O2" vs. "-O2 -fwrapv".  Let's see
how big the damage would be ;-)

Gr.
Steven

Re: signed is undefined and has been since 1992 (in GCC)

[Gabriel Dos Reis]

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.
| > -- Gaby
| 
| Obviously no one programs a compiler to deliberately have disastrous
| behavior in an undefined situation. However, if you are interested in
| the best possible code from an efficiency point of view, the compiler
| is allowed to assert that the overflow cannot take place, and then make
| all logical deductions about control flow etc that come from this
| assumption. As I showed with my password example, this can have unexpected
| results.

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 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
type. 

-- Gaby

Re: signed is undefined and has been since 1992 (in GCC)

[Gabriel Dos Reis]

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 should deny me access
| > to that functionally where it actually can?
| 
| Because it disallows compiler transformations?  E.g. suddenly a
| loop with a signed variable as the loop counter may wrap around, 
| which that means some transformations that are safe now would
| no longer be safe.

You have to define "safe".  Obviously, if you make the assumption that
with signed overflow, all bets are off then you can go to
tansformations predicated by that assumption.  If you take the
assumption that signed overflow is defined and supported, you can go
transformations predicated by that assumption.  In either case, "safe"
is with respect to the semantics chosen. 

-- Gaby

Re: Do C++ signed types have modulo semantics?

[Ulrich Weigand]

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 induction variable reduction wrong ...)

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  Linux on zSeries Development
  [EMAIL PROTECTED]

Re: signed is undefined and has been since 1992 (in GCC)

[Robert Dewar]

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
type. 


Well the "hardware consistently displaying a semantics" is not so
cut and dried as you think (consider the loop instruction and other
arithmetic on the x86 for instance in the context of generating code
for loops).

THis is all about trading off undefined behavior (a bad thing) against
high performance (a good thing) against encouraging people to write
portable code (a good thing) against existing wrong programs working
(probably a good thing, though at odds with the portability requirement).

C is not a way of writing machine code, it is an abstract language
defined by the standard. There can be arguyments for language extension,
as you making, but such decisions should be made with proper data about
the magnitude of the tradeoffs.


-- Gaby

Re: signed is undefined and has been since 1992 (in GCC)

[Gabriel Dos Reis]

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 because of the presence
of numeric_limits::is_modulo -- assuming you make GCC's behaviour
consistent.  

-- Gaby

Re: signed is undefined and has been since 1992 (in GCC)

[Robert Dewar]

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 of possible evil effects of
taking advantage of undefined. If anything it is an argument for your
point of view :-)

Re: Do C++ signed types have modulo semantics?

[Steven Bosscher]

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 performance degradations of 20-30% in some
> SPECfp cases from getting induction variable reduction wrong ...)

Yeah, I'm testing on an AMD64 box, both 64 bits and 32 bits.

Gr.
Steven

Re: Do C++ signed types have modulo semantics?

[Paul Koning]

> "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 semantics, suddenly countable loops
 Steven> are turned into noncountable loops, overflow can occur,
 Steven> dependencies may be introduced that never happen in reality,
 Steven> and so on.

I must be missing something.  Unsigned has wraparound (modulo)
semantics.  So if unsigned loop counters produce better code, why does
making signed ints wrap cause worse code rather than better (just as
good as unsigned) code?

 paul

Re: Do C++ signed types have modulo semantics?

[Steven Bosscher]

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 code gcc can generate for
>  Steven> loops.  With wrap-around semantics, suddenly countable loops
>  Steven> are turned into noncountable loops, overflow can occur,
>  Steven> dependencies may be introduced that never happen in reality,
>  Steven> and so on.
>
> I must be missing something.

Yes.

> Unsigned has wraparound (modulo) 
> semantics.

The whole point is that it doesn't.

Gr.
Steven

Re: signed is undefined and has been since 1992 (in GCC)

[Gabriel Dos Reis]

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 case of converting a void* to a F*, where F is a function
| > type.
| 
| Well the "hardware consistently displaying a semantics" is not so
| cut and dried as you think (consider the loop instruction and other
| arithmetic on the x86 for instance in the context of generating code
| for loops).

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. 

-- Gaby

Re: signed is undefined and has been since 1992 (in GCC)

[Gabriel Dos Reis]

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
| > programs where we can.
| 
| The password example is just an example of possible evil effects of
| taking advantage of undefined. If anything it is an argument for your
| point of view :-)

Well, I do not think so -- that is what I was saying.

-- Gaby

Re: Do C++ signed types have modulo semantics?

[Michael Veksler]

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 between signed and unsigned.
Signed does not have modulo semantics (in GCC.
The standard permits it to have modulo semantics).

  Michael

Re: Do C++ signed types have modulo semantics?

[Steven Bosscher]

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 whole point is that it doesn't.
>
> I think that you confuse between signed and unsigned.
> Signed does not have modulo semantics (in GCC.
> The standard permits it to have modulo semantics).

Hmmyes.  Silly me.

Gr.
Steven
  

Re: GCC 4.0.1 Status (2005-06-27)

[Scott Robert Ladd]

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

Re: signed is undefined and has been since 1992 (in GCC)

[Robert Dewar]

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 not
exist. C is not an assembly language.

Re: signed is undefined and has been since 1992 (in GCC)

[Gabriel Dos Reis]

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
| assuming some connection between C and the hardware which does not
| exist. C is not an assembly language.

If you live in a different world, you may not see the connection.

-- Gaby

Re: toplevel bootstrap (stage 2 project)

[Daniel Berlin]

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 part of the regular documentation,
> > and if anything is to improve, the improvements should be made there
> > instead of having that on the Wiki (or, even worse, causing duplication).
> 
> 
> 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 prototyping: people could write documentation there for
> review, be refined by others, and eventually converted to real TeX
> documentation.

This is what i did with the decl hierarchy documentation i submitted as
part of the decl cleanup patch.

The Texinfo version took significantly longer than the wiki portion, but
it was mainly just mechanical formatting, etc, where wiki knows what to
do automatically or with a trivial command and Texinfo doesn't.

Re: Do C++ signed types have modulo semantics?

[Nathan Sidwell]

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(int a, int b)

| {
|   if ( (a<0) != (b<0))
| return a+b; // Different sign, no overflow possible.
|   unsigned sum = (unsigned) a + b;
|   if (sum <= MAX_INT)
| return sum;
|   sum -= MIN_INT;
|   if (sum > MAX_INT) // can be eliminated for 2's complement
|abort(); // oops
|   return (int)sum + MIN_INT;
| }
| 
| It does not look too good optimization-wise.


Thanks for providing this example.  This is the sort of thing I
faced.  With pipeline process, it does harm.


Please explain why
int wrap_sum (int a, int b)
{
 return (int) ((unsigned)a + (unsigned)b));
}
is unacceptable (provided we're on the standard 2's complement machine where the 
mapping between negative ints and unsigned is *implementation defined* to be the 
sane mapping, which I might point out you've already assumed in the wrap_sum I 
quoted).


nathan

and whoever silently removed gcc@gcc.gnu.org, shame on you

--
Nathan Sidwell::   http://www.codesourcery.com   :: CodeSourcery LLC
[EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk

Re: signed is undefined and has been since 1992 (in GCC)

[Gabriel Paubert]

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
> | > 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
> | > type.
> | 
> | Well the "hardware consistently displaying a semantics" is not so
> | cut and dried as you think (consider the loop instruction and other
> | arithmetic on the x86 for instance in the context of generating code
> | for loops).
> 
> 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. 

For the matter, PPC also has undefined behaviour for integer divides
of 0x8000 by -1 (according to the architecture specification).
I just checked on a 400MHz PPC750, and the result register ends
up containing -1. 

A side effect is that (INT_MIN % -1) is INT_MAX, which is really 
surprising. I believe that it is reasonable to expect that the 
absolute value of x%y is less than the absolute value of y; it 
might even be required by some language standard.

On x86, the same operation results in a "divide by zero" exception
(vector 0) and a signal under most (all?) operating systems
(SIGFPE under Linux).

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 ? 

I can see a moderate code size impact, something like 4 or 5 machine
instructions per integer division, not really a performance impact
since on one branch you would have a divide instruction which takes
many clock cycles.

Regards,
Gabriel

Re: signed is undefined and has been since 1992 (in GCC)

[Andrew Pinski]

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, it
adds up and then becomes a performance regression which nobody wants.

-- Pinski

G++ and ISO C++

[Mirza]

Hi,

Can someone point me to list of ISO C++ vs. g++ incompatibilities.

thanks

Re: Do C++ signed types have modulo semantics?

[Gabriel Dos Reis]

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 
for
| > | each
| > | processor to have best results.
| > | | int wrap_sum(int a, int b)
| > | {
| > |   if ( (a<0) != (b<0))
| > | return a+b; // Different sign, no overflow possible.
| > |   unsigned sum = (unsigned) a + b;
| > |   if (sum <= MAX_INT)
| > | return sum;
| > |   sum -= MIN_INT;
| > |   if (sum > MAX_INT) // can be eliminated for 2's complement
| > |abort(); // oops
| > |   return (int)sum + MIN_INT;
| > | }
| > | | It does not look too good optimization-wise.
| > Thanks for providing this example.  This is the sort of thing I
| > faced.  With pipeline process, it does harm.
| 
| Please explain why
| int wrap_sum (int a, int b)
| {
|   return (int) ((unsigned)a + (unsigned)b));
| }
| is unacceptable

Notice that in your rendition you're assuming that you can convert any
unsigned value > INT_MAX to a int without invoking undefined behaviour.

Thus the question is whether you're accepting that as documented
behaviour of GCC, and if so, then I'm interested in which ways it
would differs from saying that is_modulo is true.  That is useful for
improving over the current situation, may I point out.

| (provided we're on the standard 2's complement machine
| where the mapping between negative ints and unsigned is
| *implementation defined* to be the sane mapping, which I might point
| out you've already assumed in the wrap_sum I quoted).
| 
| nathan
| 
| and whoever silently removed gcc@gcc.gnu.org, shame on you

I don't see why you should put shame on Daniel Berlin for having
sent a private useful notice.

-- Gaby

Re: Do C++ signed types have modulo semantics?

[Andrew Pinski]

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 behavior so your argument does not work.

Quote from Nathan's mail (the emphases are not mine but Nathan's which 
means he wanted

to you to read that part and not say it was undefined behavior):
(provided we're on the standard 2's complement machine where the 
mapping between negative ints and unsigned is *implementation defined* 
to be the sane mapping, which I might point out you've already assumed 
in the wrap_sum I quoted).


-- Pinski

Re: Do C++ signed types have modulo semantics?

[Nathan Sidwell]

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 piece of code differently 
for
| > | each
| > | processor to have best results.
| > | | int wrap_sum(int a, int b)
| > | {
| > |   if ( (a<0) != (b<0))
| > | return a+b; // Different sign, no overflow possible.
| > |   unsigned sum = (unsigned) a + b;
| > |   if (sum <= MAX_INT)
| > | return sum;
| > |   sum -= MIN_INT;
| > |   if (sum > MAX_INT) // can be eliminated for 2's complement
| > |abort(); // oops
| > |   return (int)sum + MIN_INT;
| > | }
| > | | It does not look too good optimization-wise.
| > Thanks for providing this example.  This is the sort of thing I
| > faced.  With pipeline process, it does harm.
| 
| Please explain why

| int wrap_sum (int a, int b)
| {
|   return (int) ((unsigned)a + (unsigned)b));
| }
| is unacceptable

Notice that in your rendition you're assuming that you can convert any
unsigned value > INT_MAX to a int without invoking undefined behaviour.

Thus the question is whether you're accepting that as documented
behaviour of GCC, and if so, then I'm interested in which ways it
would differs from saying that is_modulo is true.  That is useful for
improving over the current situation, may I point out.


I give up.

nathan
--
Nathan Sidwell::   http://www.codesourcery.com   :: CodeSourcery LLC
[EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk

Some basic/beginner questions

[nico]

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 think one dump switch ('fdump-tree-optimized') is very close that  
what I want.
Which of the options is the best way to have a look at the data  
structure? I don't want have a look at debug-informations etc. I only  
want to see control flow, data flow, types and such things.
Another problem is to find in the gcc-sourcecode where this dump  
happens. A hint from this list was to have a look at the tree- 
dump.c . But I think the dumps which are implemented there, based on  
the 'tree-dump-index' in 'tree.h'. And there I can only found a few  
of the possible dump-flags. And no one of them is 'optimized'.


To much questions - I know.

Perhaps somebody recommend me some further readings.

Ciao and thanks,
Nico

Re: Do C++ signed types have modulo semantics?

[Gabriel Dos Reis]

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, the cast is implementation defined
| and not undefined behavior so your argument does not work.

I stand corrected! 


-- Gaby

Re: Some basic/beginner questions

[Diego Novillo]

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_passes

Dumps are controlled by TODO_dump_func.  See tree-optimize.c:execute_todo
to follow what happens when the flag is enabled.  The global
variables dump_file and dump_flag tell the passes whether dumps
are enabled.  If you browse a few passes, you'll see that they
all predicate dump actions with 'if (dump_file ...)'.


Diego.

Re: signed is undefined and has been since 1992 (in GCC)

[Olivier Galibert]

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 high-level,
somewhat portable assembly language.  Ignoring that part is not a very
good idea.

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

- sizeof(int) == 4, sizeof(long long) == 8

- sizeof(long) == sizeof(void *) == sizeof(void (*)())

Break them and see your compiler rejected by pretty much everybody.

  OG.

Re: signed is undefined and has been since 1992 (in GCC)

[Jonathan Wilson]

- sizeof(int) == 4, sizeof(long long) == 8

I swear 16 bit compilers have sizeof(int) = 2 with sizeof(long) = 4

Re: signed is undefined and has been since 1992 (in GCC)

[Robert Dewar]

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!

RE: signed is undefined and has been since 1992 (in GCC)

[Dave Korn]

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 subtly-incorrect.  To
attempt to fix it all in the compiler rather than the source seems a bit
bass-ackwards to me!

> - sizeof(int) == 4, sizeof(long long) == 8
> 
> - sizeof(long) == sizeof(void *) == sizeof(void (*)())
> 
> Break them and see your compiler rejected by pretty much everybody.

  And what about 64 bit architectures?  Your assumptions are already widely
invalid and only going to get more so.

cheers,
  DaveK
-- 
Can't think of a witty .sigline today

Re: signed is undefined and has been since 1992 (in GCC)

[Olivier Galibert]

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 lately?

I kinda doubt gcc can generate 16-bit code at that point in any case.

  OG.

Re: signed is undefined and has been since 1992 (in GCC)

[Gabriel Dos Reis]

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 non-negligible part of the use of C and even C++ is as a high-level,
| somewhat portable assembly language.  Ignoring that part is not a very
| good idea.

Especially given that we do compile C and C++ programs based on the
published processor specific ABIs, and pretending that there is no
connection between C or C++ and hardware semantics is, ahem, not a
very good idea.

-- Gaby

Re: signed is undefined and has been since 1992 (in GCC)

[Olivier Galibert]

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 is a vast amount of bad
> software in the world, some blatantly buggy, some subtly-incorrect.  To
> attempt to fix it all in the compiler rather than the source seems a bit
> bass-ackwards to me!

Welcome to the real world.  Useful compilers are not an exercise in
theorical computing, especially for languages like C or C++.


> > - sizeof(int) == 4, sizeof(long long) == 8
> > 
> > - sizeof(long) == sizeof(void *) == sizeof(void (*)())
> > 
> > Break them and see your compiler rejected by pretty much everybody.
> 
>   And what about 64 bit architectures?  Your assumptions are already widely
> invalid and only going to get more so.

They aren't.  They have:

- sizeof(int) == 4, sizeof(long long) == 8
- sizeof(long) == sizeof(void *) == sizeof(void (*)()) == 8

and nobody in his right mind would seriously propose to change
sizeof(int) to 8 or sizeof(long long) to 16.

IA-64 may have an issue with sizeof(void (*)()) from what I've heard,
but they have been laughed out of the market.

  OG.

Re: signed is undefined and has been since 1992 (in GCC)

[Robert Dewar]

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.

Re: signed is undefined and has been since 1992 (in GCC)

[Andrew Haley]

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:
 > > 
 > >   This is a bad line of reasoning in general.  There is a vast amount of 
 > > bad
 > > software in the world, some blatantly buggy, some subtly-incorrect.  To
 > > attempt to fix it all in the compiler rather than the source seems a bit
 > > bass-ackwards to me!
 > 
 > Welcome to the real world.  Useful compilers are not an exercise in
 > theorical computing, especially for languages like C or C++.

This is childish and insulting.

Please try to have a little more respect for the people you're dealing
with -- who live and work in the real world as much as you do.  

The standard of discourse on this list has been dropping of late, and
we'd all get a lot more done if we'd learn to take a deep breath
before posting.  Try to remember this is a technical discussion, not
an argument in a bar.

Andrew.

Re: Do C++ signed types have modulo semantics?

[Michael Veksler]

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 undefined
behaviour.
> |
> |
> |
> | If you read Nathan's mail correctly, the cast is implementation defined
> | and not undefined behavior so your argument does not work.
>
> I stand corrected!
>

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

This is because as far as I remember 0x is interpreted
as -0, which then cast to unsigned as 0x.


This behavior seems to be undocumented (a documentation PR?).

  Michael

Re: GCC 4.0.1 Status (2005-06-27)

[Jeffrey A Law]

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 hopes to fix Tuesday.  As soon as that's in, I'll build 
> RC3, and then, hopefully, a few days later, put out the final release.
> 
> I'm sorry this is dragging out, but I think it's worth getting this bug 
> fixed.
I'm working on it right now.My PA box is experiencing cpu faults
on its second cpu while trying to bootstrap for a set of baseline
results   I suspect it'll take until late tomorrow before I can get
a set of baseline test results, fix the bug, then get a set of new test
results for comparison purposes.


jeff

Re: Do C++ signed types have modulo semantics?

[Nathan Sidwell]

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 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 whether the extraordinary 
value
is a trap representation or an ordinary value (C99 6.2.6.2).}

GCC supports only two's complement integer types, and all bit patterns
are ordinary values.

please stop considering non 2's complement stuff.

nathan

--
Nathan Sidwell::   http://www.codesourcery.com   :: CodeSourcery LLC
[EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk

Re: GCC 4.0.1 Status (2005-06-27)

[Mark Mitchell]

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 
working on, and hopes to fix Tuesday.  As soon as that's in, I'll build 
RC3, and then, hopefully, a few days later, put out the final release.


I'm sorry this is dragging out, but I think it's worth getting this bug 
fixed.


I'm working on it right now.My PA box is experiencing cpu faults
on its second cpu while trying to bootstrap for a set of baseline
results   I suspect it'll take until late tomorrow before I can get
a set of baseline test results, fix the bug, then get a set of new test
results for comparison purposes.


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.


--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304

Re: Do C++ signed types have modulo semantics?

[Gabriel Dos Reis]

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
| > | > 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 behavior so your argument does not work.
| >
| > I stand corrected!
| >
| 
| So what does gcc gives for (int) (MAX_INT+1U)?

It should give you INT_MIN.  At least numeric_limits::min is
implemented that way (suggested by RTH).

| This behavior seems to be undocumented (a documentation PR?).

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.

-- Gaby

Re: Do C++ signed types have modulo semantics?

[Michael Veksler]

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 whether the extraordinary
value
>is a trap representation or an ordinary value (C99 6.2.6.2).}
>
>GCC supports only two's complement integer types, and all bit patterns
>are ordinary values.
>
> please stop considering non 2's complement stuff.
>

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?

  Michael

Re: Do C++ signed types have modulo semantics?

[Andrew Pinski]

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 normal user visible documentation.

-- Pinski

Re: GCC 4.0.1 Status (2005-06-27)

[Jeffrey A Law]

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 the bloody box
to hopefully improve its airflow and give it one more shot.


jeff

Re: GCC 4.0.1 Status (2005-06-27)

[Joe Buck]

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 PA-HPUX for you.
> It might be the best bet.   I'm going to clean out the bloody box
> to hopefully improve its airflow and give it one more shot.

I can also test hppa-hpux.

Re: signed is undefined and has been since 1992 (in GCC)

[Joe Buck]

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't a 0 or 1 thingy, even though it is about computers.
> > > You need to evaluate them on case-by-case basis.

Andrew Pinski wrote on 28/06/2005 08:34:25:
> Gaby, I am not sure you can do that in a reliable way. You may end up
> with different behavior of overflow in the following two cases:
> 1. for (int i = x ; i <= y ; ++i)
>{
> // this loop can be eliminated - overflow case (y == MAX_INT)
> // is undefined.
> q= s + 5; // moved outside the loop.
>}
> 2. a = b + c; // modulo
> 
> If you treat overflow in case 1 differently than in case 2 then
> you get into many inconsistencies and corner cases.

In digital logic optimization we speak of "don't cares".  This means
that we have certain input combinations that we don't care about, but
we must produce correct logic for all the cases that we do care about.
It's really just the same for producing a compiler that matches a spec:
We want to produce the cheapest possible circuit/program, by taking
maximal advantage of the degrees of freedom provided by the don't-cares.

Andrew, you're exactly right that we can't define the behavior in a
reliable way, and THAT IS EXACTLY THE POINT.  We want to produce the
most efficient possible implementation for the cases that *are* defined,
and the behavior for the undefined cases naturally falls out of that.
You've actually given us an excellent example above.

Consider a processor whose integer addition instruction wraps.  Then
the cheapest implementation for examples 1 and 2 above that cover the
defined cases is to eliminate the loop in case 1, and produce a modulo
result in case 2.  You worried about interaction between the two
constructs.  Consider

/* int a, b, c; */
if (b > 0) {
a = b + c;
int count;
for (int i = c; i <= a; i++)
count++;
some_func(count);
}

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_func(b+1);

Any attempt to assign meaning to integer overflow would prevent this
optimization.

Re: signed is undefined and has been since 1992 (in GCC)

[Joe Buck]

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, since you are
> assuming some connection between C and the hardware which does not
> exist. C is not an assembly language.

Actually, those of us who work in hardware-software codesign and formal
verification consider exactly such problems, though it ends up being a
comparison of the behavior of two abstract machines, the (idealized)
processor model and the "C machine".

The distinction between an HLL and assembly language is that in the
latter, every program that is accepted by the tool is mapped into some
definite machine language (though the processor architecture will flag
the behavior of some instructions as undefined).

Re: Do C++ signed types have modulo semantics?

[Gabriel Dos Reis]

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
| magnitude,
| >two's complement, or one's complement, and whether the extraordinary
| value
| >is a trap representation or an ordinary value (C99 6.2.6.2).}
| >
| >GCC supports only two's complement integer types, and all bit patterns
| >are ordinary values.
| >
| > please stop considering non 2's complement stuff.
| >
| 
| 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?

It is targted at the user audience.

An issue I raised earlier -- that still remains -- is how, pratically,
that differs from the modulo semantics and the loop optimizer is not 
willing to make under some circumstances.

-- Gaby

Re: signed is undefined and has been since 1992 (in GCC)

[Joe Buck]

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 is a vast amount of bad
> software in the world, some blatantly buggy, some subtly-incorrect.  To
> attempt to fix it all in the compiler rather than the source seems a bit
> bass-ackwards to me!
> 
> > - sizeof(int) == 4, sizeof(long long) == 8
> > 
> > - sizeof(long) == sizeof(void *) == sizeof(void (*)())
> > 
> > Break them and see your compiler rejected by pretty much everybody.
> 
>   And what about 64 bit architectures?  Your assumptions are already widely
> invalid and only going to get more so.

No, all of Olivier's assumptions are valid on LP64 as well as ILP32
architectures.  They are invalid on most DSP architectures, as well as
on 16-bit embedded architectures, which I suppose you could call "widely
invalid" if you count # of shipping parts.  But they are a reasonable
engineering tradeoff in many cases (it's a waste of time in most cases
for a program that does a lot of bit manipulation to consider the case
of 37 bit one's complement architectures with an 11 bit byte).

Re: Do C++ signed types have modulo semantics?

[Joseph S. Myers]

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's Annex J.3 and 
J.4, or is it necessary to go through the whole standard to find what 
needs documenting?

-- 
Joseph S. Myers   http://www.srcf.ucam.org/~jsm28/gcc/
[EMAIL PROTECTED] (personal mail)
[EMAIL PROTECTED] (CodeSourcery mail)
[EMAIL PROTECTED] (Bugzilla assignments and CCs)

Re: Do C++ signed types have modulo semantics?

[Joe Buck]

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" keyword in their
> >>declarations.
> 
> I agree.
> 
> 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 eliminate, and 
> the number of programs that would not break with GCC, even though they 
> work with other compilers, seems likely to be high.

I strongly object.

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.

Here's a simple example.

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);
}
}

Here, if integer overflow is undefined, this is just

int func(int a, int b) {
if (b >= 0) {
blah(b+1);
}
}

But if integer overflow is defined to wrap, then if a+b overflows,
count will be 0.  We could still simplify the loop, but we are forced
to emit worse code.

That said, it is certainly true that if we just have

int add(int a, int b) {
return a + b;
}

and the add function is compiled separately, and the target's integer
addition instruction wraps, we would get modulo.

Re: signed is undefined and has been since 1992 (in GCC)

[Joe Buck]

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.

Re: signed is undefined and has been since 1992 (in GCC)

[Morten Welinder]

> 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, neither has or will any other compiler.   The runtime
penalty would be too big and hurt performance numbers.

What I believe you can find examples of is that the more restricted claim of
"addition and perhaps subtraction of signed numbers is modulo" is being
assumed.  That's cheap since (for 2-complement) signed addition is the same
operation as unsigned addition.

Morten

Re: toplevel bootstrap (stage 2 project)

[Giovanni Bajo]

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 prototyping:
>> people could write documentation there for review, be refined by
>> others, and eventually converted to real TeX documentation.
>
> This is what i did with the decl hierarchy documentation i submitted
> as part of the decl cleanup patch.
>
> The Texinfo version took significantly longer than the wiki portion,
> but it was mainly just mechanical formatting, etc, where wiki knows what
> to do automatically or with a trivial command and Texinfo doesn't.

I believe we could conceive something to convert raw wiki text into texinfo
with our commands. It would handle the boring part of the conversion.

Giovanni Bajo

Re: G++ and ISO C++

[Kurt Wall]

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 gcc 'C++ Extensions'"; "info gcc compatibility" has info
about compatibility. 

Kurt
-- 
The trouble with being poor is that it takes up all your time.

Re: Do C++ signed types have modulo semantics?

[Mark Mitchell]

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 optimization impact.  Reiterating my response to Daniel, if 
it is in fact the case that this is a major loss for optimization, then 
I would have to retract my claim.



Here's a simple example.

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);
}
}


Yes, I understand.

I just didn't imagine that these kinds of opportunities came up very 
often.  (Perhaps that's because I routinely write code that can't be 
compiled well, and so don't think about this situation.  In particular, 
I often use unsigned types when the underlying quantity really is always 
non-negative, and I'm saddened to learn that doing that would result in 
inferior code.)


--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304

Re: signed is undefined and has been since 1992 (in GCC)

[Gabriel Dos Reis]

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 do the same for Z."  "Undefined
| > > > behaviour" isn't a 0 or 1 thingy, even though it is about computers.
| > > > You need to evaluate them on case-by-case basis.
| 
| Andrew Pinski wrote on 28/06/2005 08:34:25:

I think there is a slight misattribution in your message.  The example
was given my Michael.

[...]

| Consider a processor whose integer addition instruction wraps.  Then
| the cheapest implementation for examples 1 and 2 above that cover the
| defined cases is to eliminate the loop in case 1, and produce a modulo
| result in case 2.  You worried about interaction between the two
| constructs.  Consider
| 
| /* int a, b, c; */
| if (b > 0) {
|   a = b + c;
|   int count;
|   for (int i = c; i <= a; i++)
|   count++;
|   some_func(count);
| }
| 
| 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_func(b+1);
| 
| Any attempt to assign meaning to integer overflow would prevent this
| optimization.

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?

If the optimizer takes that into account, then the question becomes
when do we consider breaking the ABI to switch numeric_limits::is_modulo back to old behaviour.

-- Gaby

Re: Do C++ signed types have modulo semantics?

[Daniel Berlin]

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 in assuming that this wouldn't have a 
big optimization impact.  Reiterating my response to Daniel, if it is in fact 
the case that this is a major loss for optimization, then I would have to 
retract my claim.


I've got some notes in to various XLC people to get info if they have 
actual numbers.


However, in the meanwhile, the manual actually says it causes very severe 
performance 
degradation, and that you are better off doing -O2 and 
-qnostrict_induction than -O3 + qstrict_induction, if it makes your code 
work.


(which means it says you are better off turning off high level loop opts 
like interchange/fusion/etc and still letting lower level stuff make the 
assumption, than you are turning off the assumption and turning on high 
level loop opts).


I imagine it very badly degrades your ability to move things out of loops, 
perform any kind of cache transformations, etc.


and it's just so common to write signed loops without caring about 
overflow that i'd guess you lose 90% of your opportunities to do anything 
useful or cool with the loop.

RE: signed is undefined and has been since 1992 (in GCC)

[Dave Korn]

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 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 subtly-incorrect. 
>> To attempt to fix it all in the compiler rather than the source seems a
>> bit bass-ackwards to me! 
>> 
>>> - sizeof(int) == 4, sizeof(long long) == 8
>>> 
>>> - sizeof(long) == sizeof(void *) == sizeof(void (*)())
>>> 
>>> Break them and see your compiler rejected by pretty much everybody.
>> 
>>   And what about 64 bit architectures?  Your assumptions are already
>> widely invalid and only going to get more so.
> 
> No, all of Olivier's assumptions are valid on LP64 as well as ILP32
> architectures.

  Well, they're invalid on ILP64, but I guess Cray and Alpha T3E aren't very
widespread platforms.  But we can expect that ILP64 will become more widely
used in the future, when the migration from 32-bit platforms starts to
become nothing more than a distant memory, can't we?

>  They are invalid on most DSP architectures, as well as
> on 16-bit embedded architectures, which I suppose you could call "widely
> invalid" if you count # of shipping parts.  

  I'm sure I remember a post from one of the interminably long threads of
the past few weeks that quoted examples of non-standard sizes in some 64-bit
arch(es), but I haven't been able to dig it up.

> But they are a reasonable
> engineering tradeoff in many cases (it's a waste of time in most cases
> for a program that does a lot of bit manipulation to consider the case
> of 37 bit one's complement architectures with an 11 bit byte).

  A waste of time in user apps, yes, but not an assumption that we
necessarily want to embed in the compiler (and bear in mind I'm not talking
about really bizarre stuff with 37 bits or 1's-C or non-8-bit-bytes; I'm
talking only about nice power-of-2 sizes and other sane choices here.)


cheers,
  DaveK
-- 
Can't think of a witty .sigline today

RE: LCOV

[Dave Korn]

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 "senior capstone software engineering project"
should involve either a little more effort, or perhaps a little more
stealth ?
-- 
Can't think of a witty .sigline today

Re: signed is undefined and has been since 1992 (in GCC)

[Olivier Galibert]

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 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 subtly-incorrect.  To
>  > > attempt to fix it all in the compiler rather than the source seems a bit
>  > > bass-ackwards to me!
>  > 
>  > Welcome to the real world.  Useful compilers are not an exercise in
>  > theorical computing, especially for languages like C or C++.
> 
> 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 "blatantly buggy"
or "subtly-incorrect" is somewhat childish and insulting.


> The standard of discourse on this list has been dropping of late, and
> we'd all get a lot more done if we'd learn to take a deep breath
> before posting.  Try to remember this is a technical discussion, not
> an argument in a bar.

Lemme give the long version then.  C has been created as a system
programming language[1], and is still _the_ system programming
language.  Its types are by design very dependant on the real
hardware, and even its behaviour.  And the standardization, probably
to the great chagrin of language theorists, has been careful to
reflect that, leaving large areas underspecified to allow both the
compiler and the programmer to rely on the appropriate
hardware-defined behaviour where useful.

Knowing what you run on is not being subtly incorrect, it's being an
engineer instead of a theorist.  Languages which try to define every
behaviour independently of the hardware either run on virtual machines
or require the help of Hossein Rezazadeh to move the specs around.

Now, given this hardware dependance of the language on one side and a
desire for reasonable portability on the other there pretty much
exists classes of hardware a given program will compile and run on.
Only theorical, and essentially uninteresting, programs will run on
everything.  The main class today is the one I was talking about:

- 8 bits char, 16 bits short, 32 bits int, 64 bits long long

- 2-complement without surprises, with the exception that overflow on
  loop induction variables is essentially always a bug

- long is the same size as pointer (intptr_t is not very accepted
  yet), pointer to function and pointer to data have the same size

- 32 and 64 bits ieee for float and double

- null pointer is all bits 0

- volatile means something can modify the value at any time

- memory is naturally byte-accessible, you just have to be careful
  with alignments (and even then it's often considered that the OS
  should provide transparent unaligned accesses if the hardware
  doesn't do it by itself)

And probably some others I'm forgetting.  Thinking that programs which
rely on these assumptions are incorrect is the attitude of a theorist
with his head in the sand.  The kind of people that should never be
left anywhere near the source of a C compiler.  And to break themyou
need a really, compelling hardware reason.  Breaking sizeof(void *) ==
sizeof(int) took years for people and programs to adapt and is still
not completely there yet.  Breaking aliasing took a while too.

Even embedded hardware tend to converge on that class for flexibility
and interoperability reasons.  Those who aren't there yet keep a very,
very close control on their software environment and don't plan to run
anything they find on sourceforge without a large amount of effort.
And they use the C compiler even more as a high-level assembler than
most people.


Anyway, my point is that breaking these assumptions just because the
standard does not specify them is silly.  They're driven by the
hardware, not by the wishes of compiler writers or of language
theorists.


  OG.

[1] http://cm.bell-labs.com/cm/cs/who/dmr/chist.html

Re: signed is undefined and has been since 1992 (in GCC)

[Joe Buck]

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 so.
> > 
> > No, all of Olivier's assumptions are valid on LP64 as well as ILP32
> > architectures.
> 
>   Well, they're invalid on ILP64, but I guess Cray and Alpha T3E aren't very
> widespread platforms.  But we can expect that ILP64 will become more widely
> used in the future, when the migration from 32-bit platforms starts to
> become nothing more than a distant memory, can't we?

No, it's going to be LP64 (with I=32), and I don't see a reason for that
ever to go away.  32-bit integers are going to remain useful types, and
LP64 architectures finally have char = 8, short = 16, int = 32, long = 64,
which is too useful to break.  Why would anyone now switch int to 64?

Re: signed is undefined and has been since 1992 (in GCC)

[Olivier Galibert]

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 INT_MIN/-1, gcc has NEVER fulfilled such assumptions
> on i86 and, quite likely, neither has or will any other compiler.   The 
> runtime
> penalty would be too big and hurt performance numbers.

I meant "bad taste to rely on that", sorry.  Not that it shouldn't
overflow, but rather that overflowing shouldn't happen in a
well-behaving program and and the compiler is allowed to go and slap
you if it happens.


> What I believe you can find examples of is that the more restricted claim of
> "addition and perhaps subtraction of signed numbers is modulo" is being
> assumed.  That's cheap since (for 2-complement) signed addition is the same
> operation as unsigned addition.

Yes.

  OG.

Re: G++ and ISO C++

[Giovanni Bajo]

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, correct semantic for old-style access
declarations vs using declarations, etc.), plus of course the usual bag of
bugs.

I am not aware of any official list though.

Giovanni Bajo

Re: signed is undefined and has been since 1992 (in GCC)

[Joe Buck]

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_func(b+1);
> | 
> | Any attempt to assign meaning to integer overflow would prevent this
> | optimization.
> 
> 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?

C/C++ require unsigned to be modulo, and I think it is perfectly
appropriate to define the cast from unsigned to int to assume two's
complement behavior.  But if unsigned variables are involved, in my
example the compiler is forced to produce worse code (it must cover
the case of wraparound).

> If the optimizer takes that into account, then the question becomes
> when do we consider breaking the ABI to switch numeric_limits type>::is_modulo back to old behaviour.

I think that defining signed types as is_modulo is broken, but I'm not
sure what consequences follow from this problem (e.g. what kind of user
code is using this feature, and for what).

Re: signed is undefined and has been since 1992 (in GCC)

[Diego Novillo]

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 bug yesterday.  Scalar evolutions was assuming it
couldn't wrap around.


Diego.

RE: signed is undefined and has been since 1992 (in GCC)

[Dave Korn]

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
>>  > > >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
>>  subtly-incorrect.  To > > attempt to fix it all in the compiler rather
>>  than the source seems a bit  > > bass-ackwards to me! >
>>  > Welcome to the real world.  Useful compilers are not an exercise in
>>  > theorical computing, especially for languages like C or C++.
>> 
>> 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 "blatantly buggy"
> or "subtly-incorrect" is somewhat childish and insulting.

  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 with it.

  If you re-read what *you* originally said, you made it look like you were
talking in abstract terms about software-in-general, and that's certainly
what I was referring to when I replied; it's unreasonable of you to point at
that very generalised sentence and suddenly say "I was talking about my own
code, even though I hid the fact, and so you've insulted me by disparaging
it".

> Lemme give the long version then.  

  No number of correct assumptions about the sizes of various types or the
representation of NULL pointers will validate the incorrect assumption that
signed integer arithmetic could be made to wrap without obliging the
compiler to emit lousy code and miss an awful lot of loop-optimisation
opportunities.

cheers,
  DaveK
-- 
Can't think of a witty .sigline today

Re: signed is undefined and has been since 1992 (in GCC)

[Paul Schlie]

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 can you tell me why GCC should deny me access
>| > to that functionally where it actually can?
>| 
>| Because it disallows compiler transformations?  E.g. suddenly a
>| loop with a signed variable as the loop counter may wrap around,
>| which that means some transformations that are safe now would
>| no longer be safe.
>
> You have to define "safe".  Obviously, if you make the assumption that
> with signed overflow, all bets are off then you can go to
> tansformations predicated by that assumption.  If you take the
> assumption that signed overflow is defined and supported, you can go
> transformations predicated by that assumption.  In either case, "safe"
> is with respect to the semantics chosen.

Yes.

Overall the problem/conflict seems to revolve around the differentiation
between what's allowed vs. should be done; where "should" is of course
subjective, so it may be worth first attempting to define philosophically
what an idealized implementation "should" do, and then strive to follow this
guideline in cases where the compiler has the freedom to do so.

For what it's worth, a compiler "should":

- Strictly implement all mandated language semantics by default; although
  may enable these semantics to be extended and/or altered, if believed to
  be "Most Likely Beneficial", only by explicit request to do so.

- Define and correspondingly strictly implement the "Most Likely Beneficial"
  semantics which are not mandated by the standard as if they were, and
  emit a warning for every such behavior which is known to likely to express
  itself. (i.e. a shift by a value known to have a range which may exceed
  the size of it's shifted operand, or a the dereference of a pointer which
  is known to potentially be NULL, for example.)

- Where the "Most likely Beneficial" semantics are those which most likely:
  - improve the expressiveness and/or consistency of the language.
  - improve the determinism of the language and resulting executable.
  - improve the efficiency of the language and resulting executable by
adopting and basing optimizations on the target's native semantics
when not in conflict with the above.

Thereby it's never "Most likely Beneficial" to base optimizations on a
presumed undefined behavior, as no such behaviors should exist; therefore
such optimizations will only likely yield inconsistent and/or potentially
non-deterministic results, which is most likely not beneficial toward the
goals of producing an efficient deterministic program.

(The key to an efficient, consistent, and deterministic compiled program is
leveraging the natural behavior of the target where it is not in conflict
with the language's or implementation's otherwise defined semantics.)

Re: Do C++ signed types have modulo semantics?

[Theodore Papadopoulo]

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);
> > }
> > }
> 
> Yes, I understand.
> 
> I just didn't imagine that these kinds of opportunities came up very 
> often.  (Perhaps that's because I routinely write code that can't be 
> compiled well, and so don't think about this situation.  In particular, 
> I often use unsigned types when the underlying quantity really is always 
> non-negative, and I'm saddened to learn that doing that would result in 
> inferior code.)

The real question is how often anyone is writing a loop (with an
unsigned of signed index) that is designed to wrap

So maybe at the end of this lengthy discussion, one decision to make is
introduce a flag -floop-index-may-wrap and assume by default that loop
indices never, ever go outside of the range of values allowed by the
underlying type (or the opposite if backward compatibility is judged
more important).

A few months ago, problems with integers that may possibly wrap was
found to be a major penalty for STL vectors because loops over iterators
were never unrolled (because the increment on pointers is 4 and the
unroller was not able to decide the finiteness of a loop in such a
case). Zdenek (I hope my memory does not misattribute the work)
corrected that for increments that are powers of 2 (in which case it is
easier to decide whether the loop is finite or not). The fact remains
that the loop unroller currently must be pessimist in many cases
assuming that the loop induction variable may wrap ending up in an
infinite loop

Re: signed is undefined and has been since 1992 (in GCC)

[Joe Buck]

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 "blatantly buggy"
> or "subtly-incorrect" is somewhat childish and insulting.

I agree, partly, with Olivier.  However, let's not insult each other;
we need to recognize that GCC developers have to worry about embedded
systems, where some of the assumptions Olivier makes do not hold.

I make some of the same tradeoffs in my code as Olivier does, because
the assumptions are true of all of the target platforms we care about.
(In particular, either ILP32 or LP64, with IEEE FP arithmetic; for
everything else we need rigorous type safety, unions if pointers share
storage with longs, etc).

However, I am careful to document them, and disagree with a couple
(particularly assuming things about unaligned access; even when the
architecture permits it, there's a substantial speed penalty).  Also,
some of Olivier's assumptions could lead to less maintainable code;
sloppy typing can hide errors, even for assumptions that are safe with
all ILP32 and LP64 machines with IEEE FP.

However:

> And probably some others I'm forgetting.  Thinking that programs which
> rely on these assumptions are incorrect is the attitude of a theorist
> with his head in the sand.

It would be best to say that the assumptions are non-portable, too
non-portable to be used in code contributed to GCC.

Re: Do C++ signed types have modulo semantics?

[Gabriel Dos Reis]

"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.
| 
| Is there a convenient checklist for C++ similar to C99's Annex J.3 and 
| J.4, or is it necessary to go through the whole standard to find what 
| needs documenting?

There is no such things as the C99's annex for C++.  So, I'm afraid
one would go through the entire document.  I'll raise the issue so
that the next C++0x has something similar. But, int the meantime, I'd
try to produce a collection based on grep.

-- Gaby

Re: signed is undefined and has been since 1992 (in GCC)

[Olivier Galibert]

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 with it.

Then your definition of "incorrect" is uninteresting.  Per your
definition, "use of implementation-defined behaviour is incorrect",
essentially no non-trivial program is correct.  Including gcc for a
start, which can't be correct, ever.


>   If you re-read what *you* originally said, you made it look like you were
> talking in abstract terms about software-in-general,

I said "A very large number of C and C++ programs".  That includes
kernels, gnome, kde, lots of things.  Or if you want programs I
work(ed) on, xemacs and mame.


> and that's certainly
> what I was referring to when I replied; it's unreasonable of you to point at
> that very generalised sentence and suddenly say "I was talking about my own
> code, even though I hid the fact, and so you've insulted me by disparaging
> it".

You disparaged probably around 99% of a typical linux distribution.
Find one non-trivial program that doesn't assume that int is 32 bits.
Find one of *your* programs that doesn't.


>   No number of correct assumptions about the sizes of various types or the
> representation of NULL pointers will validate the incorrect assumption that
> signed integer arithmetic could be made to wrap without obliging the
> compiler to emit lousy code and miss an awful lot of loop-optimisation
> opportunities.

Sure, and you'll notice I always special-cased the loop induction
variables.  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 which does not
> exist. C is not an assembly language.

That is what I utterly disagree with.

  OG.

Re: signed is undefined and has been since 1992 (in GCC)

[Gabriel Dos Reis]

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 with
| > | 
| > | if (b > 0)
| > |   some_func(b+1);
| > | 
| > | Any attempt to assign meaning to integer overflow would prevent this
| > | optimization.
| > 
| > 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?
| 
| C/C++ require unsigned to be modulo, and I think it is perfectly
| appropriate to define the cast from unsigned to int to assume two's
| complement behavior.  But if unsigned variables are involved, in my
| example the compiler is forced to produce worse code (it must cover
| the case of wraparound).

>From Diego's mail, I understand that the loop optimizer was way too
aggressive in its assumptions and it is fixed now.  So, the next
logical step would be to have the semantics well-documented.

| > If the optimizer takes that into account, then the question becomes
| > when do we consider breaking the ABI to switch numeric_limits type>::is_modulo back to old behaviour.
| 
| I think that defining signed types as is_modulo is broken, but I'm not
| sure what consequences follow from this problem (e.g. what kind of user
| code is using this feature, and for what).

numeric_limits::is_modulo is part of the core C++ language (not just 
the library) and any change to that value implies an ABI change, in
the sense any use of numeric_limits::is_modulo in template
declarations (e.g. SFINAE hackery) gets mangled the same but
instantiate to a different function.  I would expect such hackery to
be localized, but it is an ABI change and we must know that (whatever
is decided after).

-- Gaby

Re: Do C++ signed types have modulo semantics?

[Mark Mitchell]

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 possible that I was naive in assuming that this wouldn't 
have a big optimization impact.  Reiterating my response to Daniel, if 
it is in fact the case that this is a major loss for optimization, 
then I would have to retract my claim.



I've got some notes in to various XLC people to get info if they have 
actual numbers.


However, in the meanwhile, the manual actually says it causes very 
severe performance degradation, and that you are better off doing -O2 
and -qnostrict_induction than -O3 + qstrict_induction, if it makes your 
code work.


OK.  I'll withdraw my statement, then.  And, so, I now think that 
 needs to change is_modulo back to false.


--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304

Re: signed is undefined and has been since 1992 (in GCC)

[Gabriel Dos Reis]

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 subpart of what I personally write either "blatantly buggy"
| > or "subtly-incorrect" is somewhat childish and insulting.
| 
| I agree, partly, with Olivier.  However, let's not insult each other;
| we need to recognize that GCC developers have to worry about embedded
| systems, where some of the assumptions Olivier makes do not hold.
| 
| I make some of the same tradeoffs in my code as Olivier does, because
| the assumptions are true of all of the target platforms we care about.
| (In particular, either ILP32 or LP64, with IEEE FP arithmetic; for
| everything else we need rigorous type safety, unions if pointers share
| storage with longs, etc).

Once upon a time, a bunch of good, expert, knowledgeable guys got
together to design an optimizing compiler for C.  They had one of the
best (if not The Best) optimizing C compilers at the time for
programs written within the well-defined part of C -- taking advantage
of undefined behaviour to propogate assumptions forward and backward.
It could blow up just about any competing compiler at the time.

...

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.

-- Gaby

Re: signed is undefined and has been since 1992 (in GCC)

[Olivier Galibert]

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 non
> > negligible subpart of what I personally write either "blatantly buggy"
> > or "subtly-incorrect" is somewhat childish and insulting.
> 
> I agree, partly, with Olivier.  However, let's not insult each other;
> we need to recognize that GCC developers have to worry about embedded
> systems, where some of the assumptions Olivier makes do not hold.

Oh yes.  But you have to be careful not to break them for the
non-embedded world, and in any case I was only answering to the
affirmation that "C the language is disconnected from the hardware".

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.


> However, I am careful to document them, and disagree with a couple
> (particularly assuming things about unaligned access; even when the
> architecture permits it, there's a substantial speed penalty).

Sure, and I tend to avoid them too, especially since I still run code
on sgis and alphas.  Still, they're often considered slow but not
crashing in lots of programs out there.

> Also, some of Olivier's assumptions could lead to less maintainable
> code; sloppy typing can hide errors, even for assumptions that are
> safe with all ILP32 and LP64 machines with IEEE FP.

The pointer/long interchangeability, thankfully, appears less often.
I see it raise its ugly head essentially in cases of printing (%p is
recent), pointer difference (which fits in a long but not an int),
virtual machines where storage is tightly controlled (lisp engines in
particular), and more often when you want to pass a value through a
library-opaque void * (thread starts, callbacks) but you do not want
to have structure lifetime issues.  In these cases you know you can
pass up to a long unscathed.


> It would be best to say that the assumptions are non-portable, too
> non-portable to be used in code contributed to GCC.

Some are already there and won't go, the most obvious one is that int
is more than 16 bits.  There are also some:
INDEX_EDGE (edge_list, i)->aux = (void *) (size_t) i;

which is I guess one of your cases of sloppy typing.  I'm sure we can
find a number of assumptions you wouldn't like on the boehm collector
too, simply because code so close to the memory management needs them
badly.

  OG.

RE: signed is undefined and has been since 1992 (in GCC)

[Dave Korn]

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* "buggy" or "incorrect", and your personal pride has absolutely
>> nothing to do with it.
> 
> Then your definition of "incorrect" is uninteresting.  Per your
> definition, "use of implementation-defined behaviour is incorrect",

  Please don't put words in my mouth.  That isn't remotely what I said, and
if you are trying to paraphrase it, you have changed the meaning.  Undefined
is not the same thing as implementation defined.

>>   If you re-read what *you* originally said, you made it look like you
>> were talking in abstract terms about software-in-general,
> 
> I said "A very large number of C and C++ programs".  That includes
> kernels, gnome, kde, lots of things.  Or if you want programs I
> work(ed) on, xemacs and mame.

  Well, then it counts stuff I've worked on as well.  And?

>> and that's certainly
>> what I was referring to when I replied; it's unreasonable of you to
>> point at that very generalised sentence and suddenly say "I was talking
>> about my own code, even though I hid the fact, and so you've insulted me
>> by disparaging it".
> 
> You disparaged probably around 99% of a typical linux distribution.

  I didn't disparage anything.  I described non-compliance with the standard
as representing anything on a scale from "blatantly buggy" (BTW, 'blatant'
means 'openly and visibly', it is not any kind of a pejorative term) to
"subtly incorrect", which seems to me a fair description of the sorts of
problems that can arise from disregarding the language spec.  It is only you
who is reading an emotional cast into this.

> Find one non-trivial program that doesn't assume that int is 32 bits.
> Find one of *your* programs that doesn't.

  Last one I wrote on my Amiga (all of them, in fact).  And?

>>   No number of correct assumptions about the sizes of various types or
>> the representation of NULL pointers will validate the incorrect
>> assumption that signed integer arithmetic could be made to wrap without
>> obliging the compiler to emit lousy code and miss an awful lot of
>> loop-optimisation opportunities.
> 
> Sure, and you'll notice I always special-cased the loop induction
> variables.  

  Yep, but at that point, your definition starts to look uninteresting,
because now it's starting to look like "We should be able to rely on signed
ints wrapping in all circumstances, except those in which they don't."  A
lot of this discussion has focussed on loop optimisations, but can you
guarantee those are the *only* optimisations which really benefit from
assuming signed ints don't wrap?  As far as I can see, it is reasonable for
the C standard to say that all signed integer overflow is undefined because
enumerating the circumstances in which it is or is not defined would be an
unbounded and poorly-defined task.  A language feature that sometimes works
and sometimes does not and there is no easy way to know whether it will or
will not work in any given circumstances is *not* a useful feature, it's a
dangerous ambiguity - worse than useless in a production environment.

>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 which does not
>> exist. C is not an assembly language.
> 
> That is what I utterly disagree with.

  Well, I don't utterly _anything_ about either his position or yours.  C is
not just a high level assembler, it has complex and abstract semantics
imposed on that; it may have been reasonable to treat it as such back in the
very early K'n'R days, but it has changed massively since then.  I also
agree that reasoning in the utter abstract about languages is not
necessarily very useful in practice, but it is a perfectly reasonable way to
define a baseline against which it becomes possible to analyze the
similarities and differences of any real-world implementation.


cheers,
  DaveK
-- 
Can't think of a witty .sigline today

Re: GCC 4.0.1 Status (2005-06-27)

[Jeffrey A Law]

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 
> >>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 then, hopefully, a few days later, put out the final release.
> >>
> >>I'm sorry this is dragging out, but I think it's worth getting this bug 
> >>fixed.
> > 
> > I'm working on it right now.My PA box is experiencing cpu faults
> > on its second cpu while trying to bootstrap for a set of baseline
> > results   I suspect it'll take until late tomorrow before I can get
> > a set of baseline test results, fix the bug, then get a set of new test
> > results for comparison purposes.
> 
> 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.
Someone is going to have to do the PA testing.  The PA box isn't going
to recover.  Oh well.

There's actually two closely related bugs in this code.  In one case
we can eliminate necessary canonicalizations and in others we can 
introduce unwanted canonicalizations.  Whee, fun.

Jeff

Bootstrap failure -- verify_ssa failed

[Ulrich Weigand]

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.628_22 in statement:
TMT.628_41 = PHI ;
PHI argument
TMT.628_22
for PHI node
TMT.628_41 = PHI ;
../../gcc-head/gcc/tree-ssa-operands.c:570: internal compiler error: verify_ssa 
failed.

Before I start debugging, does this ring any bells?

Thanks,
Ulrich

-- 
  Dr. Ulrich Weigand
  Linux on zSeries Development
  [EMAIL PROTECTED]

RE: signed is undefined and has been since 1992 (in GCC)

[Dave Korn]

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 assumptions in GCC, they are *very clearly documented
requirements* for GCC host platforms.

   cheers,
  DaveK
-- 
Can't think of a witty .sigline today

Re: Bootstrap failure -- verify_ssa failed

[David Edelsohn]

The same failure occurs on PowerPC:

http://gcc.gnu.org/ml/gcc-regression/2005-06/msg00090.html

David

Re: Bootstrap failure -- verify_ssa failed

[Andrew Pinski]

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 
64 does not dominate use in block 13

for SSA_NAME: TMT.628_22 in statement:
TMT.628_41 = PHI ;
PHI argument
TMT.628_22
for PHI node
TMT.628_41 = PHI ;
../../gcc-head/gcc/tree-ssa-operands.c:570: internal compiler error: 
verify_ssa failed.


Before I start debugging, does this ring any bells?


Yes, this is the same failure on powerpc-darwin.
.

It is also the same failure as I reported in
 when I disabled 
forwprop

and the preprocessed source still is able to reproduce it with todays
clean source.

-- Pinski

Re: signed is undefined and has been since 1992 (in GCC)

[Michael Veksler]

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, gcc has NEVER fulfilled such
assumptions
> on i86 and, quite likely, neither has or will any other compiler.
> The runtime
> penalty would be too big and hurt performance numbers.
>
> What I believe you can find examples of is that the more restricted claim
of
> "addition and perhaps subtraction of signed numbers is modulo" is being
> assumed.  That's cheap since (for 2-complement) signed addition is the
same
> operation as unsigned addition.
>
> Morten

This is problematic as Joe Buck has shown:
;/* int a, b, c; */
;if (b > 0) {
;a = b + c;
;int count=0;
;for (int i = c; i <= a; i++)
;count++;
;some_func(count);
;}

Can be optimized to
;if (b > 0)
;some_func(b+1);

Only if you assume int never overflows. Requiring operator++
to overflow will prohibit this optimization.

Re: signed is undefined and has been since 1992 (in GCC)

[Robert Dewar]

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 the ISO standard. You may want C or C++ to be different from what
it is, but the standard is widely accepted, and deviations from this
standard should only occur if they are very clearly documented and
very well justified.

Re: Bootstrap failure -- verify_ssa failed

[Diego Novillo]

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.

Re: signed is undefined and has been since 1992 (in GCC)

[Robert Dewar]

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 absolutely
nothing to do with it.



Then your definition of "incorrect" is uninteresting.  Per your
definition, "use of implementation-defined behaviour is incorrect",
essentially no non-trivial program is correct.  Including gcc for a
start, which can't be correct, ever.


Nope, there is nothing in the C standard that suggests that a program
relying on implementation-defined behavior is incorrect of buggy, and that
has nothing to do with what Dave Korn wrote. There is a world of
difference between undefined and implementation-defined.

Re: signed is undefined and has been since 1992 (in GCC)

[Robert Dewar]

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 please give a proper reference on this, it would be interesting
to know that this is a real story, and not just legend :-)

Re: signed is undefined and has been since 1992 (in GCC)

[Gabriel Dos Reis]

"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 which does not
| >> exist. C is not an assembly language.
| > 
| > That is what I utterly disagree with.
| 
|   Well, I don't utterly _anything_ about either his position or yours.  C is
| not just a high level assembler, it has complex and abstract semantics
| imposed on that; it may have been reasonable to treat it as such back in the
| very early K'n'R days, but it has changed massively since then.  I also
| agree that reasoning in the utter abstract about languages is not
| necessarily very useful in practice, but it is a perfectly reasonable way to
| define a baseline against which it becomes possible to analyze the
| similarities and differences of any real-world implementation.

when the baseline is that C or C++ has not connection with whardware
semantics", it becomes ridiculous and uninteresting. 

-- Gaby

Re: signed is undefined and has been since 1992 (in GCC)

[Gabriel Dos Reis]

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 it that way at all, this is just a statement of fact
| wrt the ISO standard. You may want C or C++ to be different from what
| it is, but the standard is widely accepted,

Those standards are widely accepted and so are very facts that they do
have connections with hardware.  In fact, the respective committees
do work seriously on producing TRs for embedded systems and access to
hardware semantics. 

-- Gaby

Re: signed is undefined and has been since 1992 (in GCC)

[Olivier Galibert]

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 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 with it.
> > 
> > Then your definition of "incorrect" is uninteresting.  Per your
> > definition, "use of implementation-defined behaviour is incorrect",
> 
>   Please don't put words in my mouth.  That isn't remotely what I said, and
> if you are trying to paraphrase it, you have changed the meaning.  Undefined
> is not the same thing as implementation defined.

Sizeofs and encodings of the different type and behaviour on overflow
are implementation-defined, not undefined afaik.  In any case, if I
misunderstood you and you felt insulted, please accept my apologies.


>   Yep, but at that point, your definition starts to look uninteresting,
> because now it's starting to look like "We should be able to rely on signed
> ints wrapping in all circumstances, except those in which they don't."  A
> lot of this discussion has focussed on loop optimisations, but can you
> guarantee those are the *only* optimisations which really benefit from
> assuming signed ints don't wrap?  As far as I can see, it is reasonable for
> the C standard to say that all signed integer overflow is undefined because
> enumerating the circumstances in which it is or is not defined would be an
> unbounded and poorly-defined task.  A language feature that sometimes works
> and sometimes does not and there is no easy way to know whether it will or
> will not work in any given circumstances is *not* a useful feature, it's a
> dangerous ambiguity - worse than useless in a production environment.

You get it the wrong way around.  It's "We should be able to rely on
signed ints wrapping in all circumstances, except those in which we
don't care.".  In loop induction variables, usually people don't care.
In all the rest, they often do, especially in emulators and virtual
machines.  It's not an optimization when all you do is making programs
give the wrong result 0.1% faster.  Unless you want a repeat of the
strict-aliasing fiasco, only worse.


>   Well, I don't utterly _anything_ about either his position or yours.  C is
> not just a high level assembler, it has complex and abstract semantics
> imposed on that;

Yes.  But C is _also_ a high level assembler, and ignoring that is foolish.

  OG.