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


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


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