This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [Patch] Fix libstdc++/9659
On Tue, Feb 11, 2003 at 06:41:05AM -0800, Nathan Myers wrote:
> On Tue, Feb 11, 2003 at 12:10:29PM +0100, Paolo Carlini wrote:
> > Weird that it only shows up at -O3 and could not be noticed
> > running the testsuite.
> >
> > If nobody objects will apply today to both trunk and 3_3.
> > ! // Seek successful.
> > ! __ret = __tmp +
> > ! std::max(this->_M_out_cur, this->_M_in_cur) - _M_filepos;
> > --- 456,467 ----
> > ! {
> > ! // Seek successful.
> > ! __ret = __tmp;
> > ! __ret +=
> > ! std::max(this->_M_out_cur, this->_M_in_cur) - _M_filepos;
> > ! }
>
> This looks to me like a grave compiler bug.
Apologies for panicking on the list. What seems to be going
on here is that at -O2, the compiler treats the expression as
(a + (b - c)), but at -O3, it tries out ((a + b) - c) and finds
an ambiguous overload.
It Seems To Me that finding an ambiguous overload for op+(long,char*),
matching op+(int,char*), member fpos<>::op+(long), and a user global
op+(long, T) (where a T(char*) conversion is defined) indicates a
problem somewhere. Isn't op+(long,char*) an exact match for a built-in?
How can that char* match the fpos<>::op+ argument at all?
Nathan Myers
ncm-nospam@cantrip.org