Second GCC 4.7.0 Release Candidate available from gcc.gnu.org

[Paolo Carlini]

Hi,

On 03/19/2012 01:38 PM, Jonathan Wakely wrote:
> 2012/3/19 Jonathan Wakely<jwakely.gcc@gmail.com>:
>> 2012/3/19 Paweł Sikora:
>>> On Wednesday 14 of March 2012 12:22:41 Richard Guenther wrote:
>>>> GCC 4.7.0 Release Candidate available from gcc.gnu.org
>>>>
>>>> A second release candidate for GCC 4.7.0 is available from
>>>>
>>>>   ftp://gcc.gnu.org/pub/gcc/snapshots/4.7.0-RC-20120314
>>>>
>>>> and shortly its mirrors.  It has been generated from SVN revision 185376.
>>>>
>>>> I have so far bootstrapped and tested the release candidate on
>>>> x86_64-linux.  Please test it and report any issues to bugzilla.
>>> i'd like to ask about simple code snipet rejected by 4.7.0-RC2:
>>>
>>> #include<boost/shared_ptr.hpp>
>>> #include<map>
>>> #include<string>
>>>
>>> typedef boost::shared_ptr<std::string>  HString;
>>> typedef std::map<std::string,HString>  StrAttribsT;
>>> StrAttribsT m_str_attribs;
>>>
>>> void foo(const char* attribName, const char* value)
>>> {
>>>         m_str_attribs.insert(std::make_pair(attribName, new std::string(value)));
>>> }
>>>
>>> it compiles cleanly with 'g++46 -std=gnu++0x' but 4.7 rejects this code.
>>> is it an effect of 'name lookup changes'? (http://gcc.gnu.org/gcc-4.7/porting_to.html)
>> No, the change is in how std::pair is constructed, the code can be reduced to:
>>
>> #include<boost/shared_ptr.hpp>
>> #include<string>
>>
>> typedef boost::shared_ptr<std::string>  HString;
>>
>> void foo(const char* attribName)
>> {
>>     const std::pair<const std::string, HString>  a
>>         = std::make_pair(attribName, new std::string);
>> }
>>
>> Probably caused by http://gcc.gnu.org/viewcvs?view=revision&revision=174464
>>
>> I haven't looked in enough detail to see if the change in behaviour is
>> correct or a regression.
> My guess is that the new behaviour is correct, because the relevant
> constructor of boost::shared_ptr is 'explicit' but you're relying on
> an implicit conversion from pair<const char*, string*>  to
> pair<std::string, shared_ptr<string>>  which implicitly converts a raw
> pointer to a shared_ptr.
Probably, yes. We should double check your analysis (thanks!)

In 4.7 we indeed have much more constraining in std::pair, but first 
blush it's correct, per C++11 I mean (there is also the DR about using 
is_constructible instead of is_convertible in std::map, still 
unimplemented, but I don't think it's related and goes beyond C++11 anyway)

Paolo.