Jason Merrill wrote:
On 05/20/2010 08:18 AM, Peter Dimov wrote:
On 05/20/2010 01:55 PM, Paolo Carlini wrote:
It's uglier because the code above doesn't work for functions,
By the way, do you have a specific testcase in mind?
Because addressof_fn_test.cpp, part of Boost, passes...
Paolo Carlini wrote:
On 05/20/2010 02:18 PM, Peter Dimov wrote:
On 05/20/2010 01:55 PM, Paolo Carlini wrote:
It's uglier because the code above doesn't work for functions,
By the way, do you have a specific testcase in mind?
Because addressof_fn_test.cpp, part of Boost, passes...
On 05/20/2010 01:55 PM, Paolo Carlini wrote:
It's uglier because the code above doesn't work for functions,
By the way, do you have a specific testcase in mind?
Because addressof_fn_test.cpp, part of Boost, passes...
This is probably a g++/gcc extension... some compilers do not allow
refere
On 05/20/2010 01:10 PM, Paolo Carlini wrote:
... for reference, it would be something like this (in my recollections,
it was even uglier ;)
template
_Tp*
addressof(_Tp& __v)
{
return reinterpret_cast<_Tp*>
(&const_cast(reinterpret_cast(__v)));
}
It's uglier because the code a
Jonathan Wakely:
2009/5/4 Joseph S. Myers:
> On Mon, 4 May 2009, Jan Hubicka wrote:
>
>> On mainline I enabled infinite loop removal at
>> -funsafe-loop-optimizations. I would suggest adding
>> -fempty-loops-terminate and make it default for C++? It does not apply
>> for C, right?
>
> You mean fo
Paolo Carlini:
Peter Dimov wrote:
The problem, from the point of view of a library such as
boost::shared_ptr, is that there is no way to distinguish between user A,
who just types g++ foo.cpp and expects to get a program that works well
on a typical machine, and user B, who types g++ -march
Mark Mitchell:
Richard Henderson wrote:
H.J. Lu wrote:
Can we declare that Linux/ia32 generates i486 insn by default?
We the gcc team? I'm not sure. For now I'll say no.
We an individual linux distributor? Certainly.
In fact I would be surprised if i586 wasn't a
decent minimum these days.
Richard Henderson wrote:
To keep all this in perspective, folks should remember that atomic
operations are *slow*. Very very slow. Orders of magnitude slower
than function calls. Seriously. Taking p4 as the extreme example,
one can expect a null function call in around 10 cycles, but a locke
