[Bug libstdc++/22200] New: numeric_limits<signed>::is_modulo is inconsistend with gcc

[Bug libstdc++/22200] New: numeric_limits<signed>::is_modulo is inconsistend with gcc

[veksler at il dot ibm dot com]

GCC does not have a proper modulo overflow semantics for signed
integral types.
1. The loop optimizer seems to assume that signed overflow does
   not happen (or is undefined). 
2. On x86 INT_MAX/-1 seems to trap (instead of implementing
   modulo semantics).

In that case numeric_limits<signed>:is_modulo should be synchronized
with gcc and be set to false instead of true.

Another option, is to change gcc to fully support the modulo
arithmetics of signed integer.

-- 
           Summary: numeric_limits<signed>::is_modulo is inconsistend with
                    gcc
           Product: gcc
           Version: 4.0.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: libstdc++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: veksler at il dot ibm dot com
                CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200

[Bug libstdc++/22200] numeric_limits<signed>::is_modulo is inconsistend with gcc

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-27 15:21 -------
INT_MAX/-1 is undefined.
and signed overflow is undefined.

Why file this bug when the comments on the list say this is not a bug?

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200

[Bug libstdc++/22200] numeric_limits<signed>::is_modulo is inconsistend with gcc

[veksler at il dot ibm dot com]

------- Additional Comments From veksler at il dot ibm dot com  2005-06-27 15:33 -------
This is a bug because std::numeric_limits<signed>::is_modulo
should be true only if singed overflow is defined.
This is not the case with gcc, because gcc does not have the
extension "signed oveflow == module" then is_modulo should
not lie.
The undefinedness referse to MAX_INT+1 not to is_modulo.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200

[Bug libstdc++/22200] numeric_limits<signed>::is_modulo is inconsistend with gcc

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-27 15:40 -------
I think we need to read:
"ISO/IEC 10967-1 Language Independent Arithmetic, part 1" since that is what the standard references 
for is_modulo.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200

[Bug libstdc++/22200] numeric_limits<signed>::is_modulo is inconsistend with gcc

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2005-06-27 16:06 -------
Subject: Re:  numeric_limits<signed>::is_modulo is inconsistend with gcc

"pinskia at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:

| INT_MAX/-1 is undefined.
| and signed overflow is undefined.
| 
| Why file this bug when the comments on the list say this is not a bug?

Maybe the real question is why you feel you must send your message.

Please do consider the issue as raised on the main list and the
discussion there. 

The point is we must say something about numerci_limits<>, and this
consistently with the behaviour of GCC.  This probably is not an issue
for C, but it is for C++.

For all useful purposes, do remember that GCC used to define is_modulo
as false for signed integer types.  It was consciously changed to true
by RTH.  See the reference I gave.

Now, if you do not understand the issue, please refrain from sending
unhelpful messages.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200

[Bug libstdc++/22200] numeric_limits<signed>::is_modulo is inconsistend with gcc

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-27 16:07 -------
Actually it is modulo for all operations.  
and INT_MAX/-1 does not raise a trap.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200

Re: [Bug libstdc++/22200] numeric_limits<signed>::is_modulo is inconsistend with gcc

[Gabriel Dos Reis]

"pinskia at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:

| Actually it is modulo for all operations.  

But then do read the comment as far as the loop optimizer is
concerned. It does not seem like it understands that it is modulo
arithmetic. 

| and INT_MAX/-1 does not raise a trap.

It that is the case, then it is one issue less.  But that wasn't the
purpose of this PR.  The issue is far from resolved just because
you assert that INT_MAX/-1 does not trap.

-- Gaby

[Bug libstdc++/22200] numeric_limits<signed>::is_modulo is inconsistend with gcc

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2005-06-27 16:09 -------
Subject: Re:  numeric_limits<signed>::is_modulo is inconsistend with gcc

"pinskia at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:

| I think we need to read:
| "ISO/IEC 10967-1 Language Independent Arithmetic, part 1" since that
| is what the standard references for is_modulo.

yes, as pointed out in the message I sent.

It was pointed out that the loop optimizers was making some
assumtpions.  If the only is only for the loop optimizers, then we
can also consider the option of explicitly allowing specific behaviour
for induction variables.  At any rate, a proper resolution for this
PR is hardly "the standard says it is undefined behaviour".

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200

[Bug libstdc++/22200] numeric_limits<signed>::is_modulo is inconsistend with gcc

[gdr at gcc dot gnu dot org]

------- Additional Comments From gdr at gcc dot gnu dot org  2005-06-27 16:21 -------
(In reply to comment #1)
> INT_MAX/-1 is undefined.
> and signed overflow is undefined.
> 
> Why file this bug when the comments on the list say this is not a bug?

(In reply to comment #5)
> Actually it is modulo for all operations.  
> and INT_MAX/-1 does not raise a trap.

Andrew --

You do not seem to understand this PR.  Please DO NOT close it.
Your eagerness to close PRs is doing harms -- that was already debated
last couple o weeks and I do not want to repeat that again.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200

[Bug libstdc++/22200] numeric_limits<signed>::is_modulo is inconsistend with gcc

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2005-06-27 16:25 -------
Subject: Re:  numeric_limits<signed>::is_modulo is inconsistend with gcc

"pinskia at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:

| Actually it is modulo for all operations.  

But then do read the comment as far as the loop optimizer is
concerned. It does not seem like it understands that it is modulo
arithmetic. 

| and INT_MAX/-1 does not raise a trap.

It that is the case, then it is one issue less.  But that wasn't the
purpose of this PR.  The issue is far from resolved just because
you assert that INT_MAX/-1 does not trap.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200

Re: [Bug libstdc++/22200] numeric_limits<signed>::is_modulo is inconsistend with gcc

[Andrew Pinski]

On Jun 27, 2005, at 12:25 PM, gdr at integrable-solutions dot net wrote:

> | Actually it is modulo for all operations.
>
> But then do read the comment as far as the loop optimizer is
> concerned. It does not seem like it understands that it is modulo
> arithmetic.

But that is because overflow is undefined, read what other people
have written.  It is modulo for all normal operations but it is still
undefined at what the output will be.

-- Pinski

[Bug libstdc++/22200] numeric_limits<signed>::is_modulo is inconsistend with gcc

[themis_hv at yahoo dot co dot uk]

------- Additional Comments From themis_hv at yahoo dot co dot uk  2005-06-27 16:32 -------
(In reply to comment #1)
> Why file this bug when the comments on the list say this is not a bug?
It's for the potentially long debate.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200

[Bug libstdc++/22200] numeric_limits<signed>::is_modulo is inconsistend with gcc

[veksler at il dot ibm dot com]

------- Additional Comments From veksler at il dot ibm dot com  2005-06-27 16:35 -------
In Comment #5 Andrew Pinski writes:
> Actually it is modulo for all operations.  
> and INT_MAX/-1 does not raise a trap.

That was a typo on my part.

It was supposed to be INT_MIN/-1

INT_MAX/-1 does not require modulo because in 2's complement
INT_MIN==-INT_MAX-1


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200

[Bug libstdc++/22200] numeric_limits<signed>::is_modulo is inconsistend with gcc

[pinskia at physics dot uc dot edu]

------- Additional Comments From pinskia at physics dot uc dot edu  2005-06-27 16:53 -------
Subject: Re:  numeric_limits<signed>::is_modulo is inconsistend with gcc


On Jun 27, 2005, at 12:25 PM, gdr at integrable-solutions dot net wrote:

> | Actually it is modulo for all operations.
>
> But then do read the comment as far as the loop optimizer is
> concerned. It does not seem like it understands that it is modulo
> arithmetic.

But that is because overflow is undefined, read what other people
have written.  It is modulo for all normal operations but it is still
undefined at what the output will be.

-- Pinski



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200

[Bug libstdc++/22200] numeric_limits<signed>::is_modulo is inconsistend with gcc

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-27 17:29 -------
(In reply to comment #7)
> Andrew --
> 
> You do not seem to understand this PR.  Please DO NOT close it.
> Your eagerness to close PRs is doing harms -- that was already debated
> last couple o weeks and I do not want to repeat that again.

yes it will be debated until the end of time.  INT_MIN/-1 is undefined as declared by the C/C++ 
standards so this is invalid.  we get modulo results most of the time, but again since this is undefined, 
we may as well say it is modulo because it is.  I think the standard say that if two postive values are 
added to and you __may__ get a value that is less than both of them, then is_modulo should be set to 
true.  (I don't have the copy right in front of me right now but IIRC that is what it says)


In fact from the comment in std_limits.h says "if possible" meaning "may":
    /** True if the type is @e modulo, that is, if it is possible to add two
        positive numbers and have a result that wraps around to a third number
        that is less.  Typically false for floating types, true for unsigned
        integers, and true for signed integers.  */

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200

[Bug libstdc++/22200] numeric_limits<signed>::is_modulo is inconsistend with gcc

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-27 17:34 -------
Invalid as the C++ standard says:
" True if the type is modulo.203) A type is modulo if it is possible to add two positive numbers and 
have a result that wraps around to a third number that is less. Generally, this is false for floating types, 
true for unsigned integers, and true for signed integers on"

it says "if possible" which means not always but some of the time.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200

[Bug libstdc++/22200] numeric_limits<signed>::is_modulo is inconsistend with gcc

[schlie at comcast dot net]

------- Additional Comments From schlie at comcast dot net  2005-06-27 18:00 -------
(In reply to comment #13)
> Invalid as the C++ standard says:
> " True if the type is modulo.203) A type is modulo if it is possible to add two positive numbers and 
> have a result that wraps around to a third number that is less. Generally, this is false for floating 
types, 
> true for unsigned integers, and true for signed integers on"
> 
> it says "if possible" which means not always but some of the time.

It's only "possible" because the sum of two positive numbers may not exceed that
type's MAX value; not because if a type is modulo it may not produce a modulo result.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200

[Bug libstdc++/22200] numeric_limits<signed>::is_modulo is inconsistend with gcc

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2005-06-27 18:19 -------
Subject: Re:  numeric_limits<signed>::is_modulo is inconsistend with gcc

"pinskia at physics dot uc dot edu" <gcc-bugzilla@gcc.gnu.org> writes:

| Subject: Re:  numeric_limits<signed>::is_modulo is inconsistend with gcc
| 
| 
| On Jun 27, 2005, at 12:25 PM, gdr at integrable-solutions dot net wrote:
| 
| > | Actually it is modulo for all operations.
| >
| > But then do read the comment as far as the loop optimizer is
| > concerned. It does not seem like it understands that it is modulo
| > arithmetic.
| 
| But that is because overflow is undefined, read what other people
| have written.

I read what other people say.  But you do not seem to understand what
is_modulo means, even when you point to the LIA-1 part.  Please, do 
consider the semantics described there and the quote I provided.
Basically, you can decide that it overflows and send a notification of
overlfow but "wrap" with defined meaning. 

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200

[Bug libstdc++/22200] numeric_limits<signed>::is_modulo is inconsistend with gcc

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2005-06-27 18:23 -------
Subject: Re:  numeric_limits<signed>::is_modulo is inconsistend with gcc

"pinskia at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:

| ------- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-27 17:29 -------
| (In reply to comment #7)
| > Andrew --
| > 
| > You do not seem to understand this PR.  Please DO NOT close it.
| > Your eagerness to close PRs is doing harms -- that was already debated
| > last couple o weeks and I do not want to repeat that again.
| 
| yes it will be debated until the end of time.  INT_MIN/-1 is undefined as declared by the C/C++ 
| standards so this is invalid.  we get modulo results most of the time, but again since this is undefined, 

The issue is whether that modulo result is taken to be the definition that
GCC gives to the operation.  At this point, saying "the standard 
says it is undefined behaviour" is pointless and unhelpful.

| we may as well say it is modulo because it is.

Yes, that is part of the issue.

|  I think the standard say that if two postive values are  
| added to and you __may__ get a value that is less than both of them,

yes, but at this point we're more interesting in what GCC decides that
behaviour should be.  It is irrelevant to say "the standard says it is
undefined behaviour".

| then is_modulo should be set to  true.  (I don't have the copy right in front of me right now but IIRC that is what it says)
| 
| 
| In fact from the comment in std_limits.h says "if possible" meaning "may":
|     /** True if the type is @e modulo, that is, if it is possible to add two
|         positive numbers and have a result that wraps around to a third number
|         that is less.  Typically false for floating types, true for unsigned
|         integers, and true for signed integers.  */

Thanks, I'm the author of <limits>.  For all useful purposes, please
Andrew go back and read the link I gave to RTH's message.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200

[Bug libstdc++/22200] numeric_limits<signed>::is_modulo is inconsistend with gcc

[gdr at gcc dot gnu dot org]

------- Additional Comments From gdr at gcc dot gnu dot org  2005-06-27 18:25 -------
Andrew is being silly.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200

[Bug libstdc++/22200] numeric_limits<signed>::is_modulo is inconsistend with gcc

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2005-06-27 18:27 -------
Subject: Re:  numeric_limits<signed>::is_modulo is inconsistend with gcc

"pinskia at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:

| ------- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-27 17:34 -------
| Invalid as the C++ standard says:

Andrew --
Stop this unhelpful behaviour.  

If you don't understand the issue, refrain from closing it.   There is
a consistency problem between numeric_limimts<>::is_modulo and GCC's
optimizations assumptions. 

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200

[Bug libstdc++/22200] numeric_limits<signed>::is_modulo is inconsistend with gcc

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-27 18:34 -------
(In reply to comment #16)
> Thanks, I'm the author of <limits>.  For all useful purposes, please
> Andrew go back and read the link I gave to RTH's message.

Yes and RTH's comment about trapping is wrong, because PPC does not trap at all.  See PR 22203 for 
that bug.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200

[Bug libstdc++/22200] numeric_limits<signed>::is_modulo is inconsistend with gcc

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2005-06-27 18:46 -------
Subject: Re:  numeric_limits<signed>::is_modulo is inconsistend with gcc

"pinskia at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:

| ------- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-27 18:34 -------
| (In reply to comment #16)
| > Thanks, I'm the author of <limits>.  For all useful purposes, please
| > Andrew go back and read the link I gave to RTH's message.
| 
| Yes and RTH's comment about trapping is wrong, because PPC does not trap at all.  See PR 22203 for 
| that bug.

You seem to confuse all issues.  Please be careful in trying issues.
The fact that you assert that integers don't trap does not make RTH's
comment wrong.  Furtheremore, are you claiming that

    1 / 0 

does not trap on PPC? (I do not have a PPC to check).  If that is
true, you're welcoome to submit a patch to rectify the value for PPC.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200

[Bug libstdc++/22200] numeric_limits<signed>::is_modulo is inconsistend with gcc

[veksler at il dot ibm dot com]

------- Additional Comments From veksler at il dot ibm dot com  2005-06-27 20:28 -------
(In reply to comment #13)
> Invalid as the C++ standard says:
> " True if the type is modulo.203) A type is modulo if it is possible to add
> two positive numbers and 
> have a result that wraps around to a third number that is less. Generally,
> this is false for floating types, 
> true for unsigned integers, and true for signed integers on"
> 
> it says "if possible" which means not always but some of the time.

It seems to me you are being subtly inconsistent.
Correct me if I misread your comments:
1. signed overflow is undefined
   [letting the compiler do whatever it likes.
    In that case the compiler may decide, among other things, to trap,
    saturate or modulo].
2. It is OK for a compiler to set is_modulo because as it is undefined,
   modulo result may be recieved from the random junk that "undefined"
   produces. And to prove your point you refer to "...it is possible to
   add two positive numbers and have a result that wraps around.."

The logic of 2. works both ways. Any logical conclusion will be
valid in the presense of "undefined". I can say that since <limits>
does not know exactly what gcc does or does not do, it wll *may*
be possible that the undefined behavior always leads to MAX_INT.

So, if we want to have a reasonable meaning for the sentance 
"...it is possible to add ...", it should be read as 
"...it is possible to choose such values that when added...".
Reading any other way does not make sense, especially if you put
the nondeterministic "undefined" into the mix. 

This requires a DR to get a formal clarification, for people with 
Andrew's point of view, and avoid future confusion.

Andrew: Don't you think that all this noise indicates that this is
not a clear cut case? When there is a dispute, aren't we choose
the most pragmatic and useful point of view (until a formal clarification
is given)? Don't you agree that:
1. Sometimes using "undefined" simplifies the compiler and improves
   generated code.
2. (OTOH) Undefind situations are unhelpful the the users, they complicate
   debugging, and make programming harder. Reducing rules that imply
   undefined behavior semantics is good for the users.
3. Each language strikes a different balance between 1 and 2.
4. Claiming that numeric_limits<signed>::is_modulo based on "undefined"
   does not help the user, because as a result you lose all the benefits of
   is_modulo to begin with. Consider the example:
   template <class T> T foo(T a, T b)
   {
    // For example simplicity, this "if" is not generic.
    if (numeric_limits<T>::is_modulo)
      return trivial_code (a+b); // undefined for signed
    else
      return contorted_slow_code(a, b);
   }

   is_modulo = true is unhelpful, it will trigger the undefined case,
   a case that the code tries to avoid. It makes it more difficult to 
   write generic code that avoids the trouble.
   It is much more helpful to go for is_modulo = false.
5. There is no performance penatly for is_modulo = false, so item 1 does
   not come into play.
6. According to 3, the language should strike a balance between 1 and 2.
   Since 1 is not playing any role here, then 2 wins and the language
   should go for the semantics that does not depend on "undefined".
7. The text of the standard may be interpreded both ways (a fact: several
   people draw contradictory conclusions from the document). In that
   case we should choose what makes more sense if we would write the
   document.
8. When interpreting an ambiguous document (7), we should take the motives
   of the writers and the whole document objectives into account.
   According to 6, is_modulo = false strikes the best balance, as a result
   it would have been preferred by any reasonable committy.

  Michael   

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200

[Bug libstdc++/22200] numeric_limits<signed>::is_modulo is inconsistend with gcc

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-27 21:02 -------
(In reply to comment #21)
> 1. Sometimes using "undefined" simplifies the compiler and improves
>    generated code.
> 2. (OTOH) Undefind situations are unhelpful the the users, they complicate
>    debugging, and make programming harder. Reducing rules that imply
>    undefined behavior semantics is good for the users.

No I disagree with that, most undefined behaviors are very easy to debug,
the most obvious one and most invoked undefined behavior in terms of bug
reports is violating C/C++ aliasing rules (see PR  21920 which has 69 duplicates).
In fact if you look at GCC, it is the only compiler were people run into violating C/C++
aliasing rules beause we use them to check if two addresses can alias.  This is unlike almost all other 
compilers which represent their aliasing info as base+address and they only invoke the C/C++ aliasing 
rules when they cannot figure out if they point to the same address.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200

[Bug libstdc++/22200] numeric_limits<signed>::is_modulo is inconsistend with gcc

[veksler at il dot ibm dot com]

------- Additional Comments From veksler at il dot ibm dot com  2005-06-27 22:00 -------
(In reply to comment #22)
> (In reply to comment #21)
> > 2. (OTOH) Undefind situations are unhelpful the the users, they complicate
> >    debugging, and make programming harder. Reducing rules that imply
>  >   undefined behavior semantics is good for the users.

> No I disagree with that, most undefined behaviors are very easy to debug,
> the most obvious one and most invoked undefined behavior in terms of bug
> reports is violating C/C++ aliasing rules (see PR  21920 which has 69
> duplicates).

What you disagree with? You're claiming that undefined behavior does
not complicate debugging? Isn't it true that with undefined behavior
you're most likely to bump into behavioral differences between -O2 and -O0?
Isn't it true that debugging an -O2 code is more complicated than -O0 ?
Q.E.D.

Also, how did you come to the conclusion that "most undefined behaviors
are very easy to debug"? You don't know how much time it took the user
to reduce 100 KLOC to simple test cases of these 69 dups of PR  21920.
Once the test case is reduced, it is pretty trival to understand it.

> In fact if you look at GCC, it is the only compiler were people run into
> violating C/C++
> aliasing rules beause we use them to check if two addresses can alias.
> This is unlike almost all other 
> compilers which represent their aliasing info as base+address and they only
> invoke the C/C++ aliasing 
> rules when they cannot figure out if they point to the same address.

The first time I got into trouble with aliasing rules was with xlC, not
with gcc. It was in template inline code (STL allocators).

Trivial base+address would have detected that 
free_list_element* and T* alias (they were copies of one another!).
Because I used a temporary copy of u.next_free_element, instead of
accessing u.next_free_element directly, xlC would think that the
pointers do not alias.

Now since most normal people don't write STL allocators at their leisure,
they have less chance to bump into such a complex scenario as I did.

The aliasing rules were violated only due to inlining, a very difficult
thing for a user to spot. I had to debug PPC assembly code to figure out
what went wrong (remember that debugging with -O2 has a very limited
utility). And yes, I was aware of the aliasing rules, just make a subtle
mistake. Would I not have been aware of the aliasing rules, then it would
take me 3 days instead of 1 to analyze it. I could I reduce my 100 KLOC
(no valgrind for AIX to find this memory corruption) to 15 trival lines,
which any competent C/C++ programmer would find to be invalid.

Please, pretty please, take into account that the distance between the C++
text, and assembly (and probably GIMPLE) is significantly greater
than that of C, due to generic programming. It is much harder to analyze
the subtalties of undefined behavior in C++.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200