[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