[Patch] Fix libstdc++/9659

Philippe Elie phil.el@wanadoo.fr
Tue Feb 11 22:50:00 GMT 2003


Nathan Myers wrote:
> 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?

But it's reached through conversion operator
fpos<>::operator streamoff() const.

> How can that char* match the fpos<>::op+ argument at all?

I dunno but, weirdly, adding -pedantic remove this match in
error message, that indicates perhaps an inacurracy to
filter properly matching candidates in error message.

regards,
Philippe Elie



More information about the Gcc mailing list