This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch] Fix libstdc++/9659


On Tue, Feb 11, 2003 at 04:35:58PM +0100, Paolo Carlini wrote:
> Nathan Myers wrote:
> 
> >This looks to me like a grave compiler bug.  
> Indeed, naively, seems weird that, being operator+ defined inside fpos 
> besides operator+=, an user of pos_type cannot use that syntax.
> 
> Could you please explain in a little more techincal detail what seems 
> wrong with the compiler?

Looking at the affected code in more detail...

  __ret = __tmp + std::max(this->_M_out_cur, this->_M_in_cur) - _M_filepos;

The type of _M_filepos is _CharT* (b)
The type of __tmp is long or long long (c)
The type of _M_*_cur is _CharT* (d)

  a = b + c - d;
  a = (b + c) - d;
  a = b + (c - d);

Depending on how the compiler chooses to group these, we have an
integral type added to a pointer, and then another pointer subtracted
from it, yielding ptrdiff_t; or an integral type added to a pointer
difference.  Whether the result is defined depends on whether b + c
is within the array pointed to by c.

Splitting the statement in two, as Paolo did, ensures that the
third form above is what is computed.  I believe that adding 
parentheses should suffice, but Paolo's suggestion makes the 
grouping clearest.

I withdraw my objection to Paolo's patch.  

I think it's a compiler bug that it rejects the code at one -O
level and accepts it at another, particular since the difference
is in overload resolution.

Nathan Myers
ncm-nospam@cantrip.org


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]