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


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