Hi,
among the support facilities required by C++0x there is:
//
20.9.9.1 addressof [specialized.addressof]
template T* addressof(T& r);
1 Returns: the actual address of the object or function referenced by r,
even in the presence of an
overloaded operator&.
Throws: nothing.
Hello,
I wrote following code:
#include
#include
#include
int main()
{
struct dirent **namelist;
int numberOfProcDirs;
numberOfProcDirs=scandir("/proc", &namelist, 0, alphasort);
//std::string temp(std::string(namelist[0]->d_name)+std::string("fdsfds"));
//std::string temp(std::string(namelist[
... 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)));
}
I'm not sure...
Paolo.
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)));
> }
>
By the way
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
Hi,
>>> ... 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>> char&>(__v)));
>>> }
> It's uglier because t
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.
On Mon, May 17, 2010 at 8:44 AM, Maxim Kuvyrkov wrote:
> CodeSourcery is working on improving performance for Intel's Core 2 and Core
> i7 families of processors.
>
> CodeSourcery plans to add support for unaligned vector instructions, to
> provide fine-tuned scheduling support and to update instr
On 5/20/10 4:04 PM, Steven Bosscher wrote:
On Mon, May 17, 2010 at 8:44 AM, Maxim Kuvyrkov wrote:
CodeSourcery is working on improving performance for Intel's Core 2 and Core
i7 families of processors.
CodeSourcery plans to add support for unaligned vector instructions, to
provide fine-tuned s
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 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...
>
> This is probabl
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...
This is p
Sent from my iPhone
On May 20, 2010, at 5:43 AM, "Peter Dimov" wrote:
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 i
I observed the following issue with g++-4.3.4:
I can work around the restriction of initializing a static const integral
class member with a non-constant expression.
This violates the standard and should be rejected by "-pedantic".
Correct me, if I'm wrong.
I cut down my code to the following (c
Hello,
For some time now, I've wanted to see where compile time goes in a
typical GCC build, because nobody really seems to know what the
compiler spends its time on. The impressions that get published about
gcc usually indicate that there is at least a feeling that GCC is not
getting faster, and
Robert Grimm wrote:
> Actually, I saw some old posts that talked about a -fno-implicit-fp option
[I know this is a very old post, but I noticed it in old email and felt
it might still be useful to reply.]
CodeSourcery has a -fno-implicit-fp option that does exactly what you
have requested in so
On 05/20/2010 11:21 AM, Mark Mitchell wrote:
Robert Grimm wrote:
Actually, I saw some old posts that talked about a -fno-implicit-fp option
[I know this is a very old post, but I noticed it in old email and felt
it might still be useful to reply.]
CodeSourcery has a -fno-implicit-
Joel Sherrill wrote:
> I know RTEMS users have asked about this option before.
> We have the same problem since we also support floating
> point as an optional task attribute. On some tasks we implicitly
> make the port force all tasks to have FP contexts.
>
> Why was this rejected and not merge
On Sun, May 02, 2010 at 11:38:39PM +0200, Gerald Pfeifer wrote:
> As http://gcc.gnu.org/ml/gcc-testresults/2010-05/msg00120.html shows,
> *-unknown-freebsd* exhibits tons of failures around LTO.
>
> I dug a bit deeper, and even the most trivial test program
> int main() { }
> fails with
> lto1
Yixuan Huang writes:
> I wrote following code:
> #include
> #include
> #include
> int main()
> {
> struct dirent **namelist;
> int numberOfProcDirs;
> numberOfProcDirs=scandir("/proc", &namelist, 0, alphasort);
> //std::string temp(std::string(namelist[0]->d_name)+std::string("fdsfds"));
> //s
Jan Tusch writes:
> I observed the following issue with g++-4.3.4:
>
> I can work around the restriction of initializing a static const integral
> class member with a non-constant expression.
> This violates the standard and should be rejected by "-pedantic".
> Correct me, if I'm wrong.
>
> I cu
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...
This is probably a g++/gcc exte
On 05/20/2010 08:13 PM, Jason Merrill wrote:
> The standard permits a compiler to accept or reject such a cast.
>
> 5.2.10/8: Converting a pointer to a function into a pointer to an
> object type or vice versa is conditionally-supported. The meaning of
> such a conversion is implementation-defined
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...
This is p
Hello,
The Obj-C++ front end is effectively unmaintained, and has virtually
no serious users. I propose to remove it from GCC.
Perhaps the only user of some significance is GNUstep, but they are
already in an awkward position because they wish to use ObjC 2.0, and
they are looking at clang for th
Steven Bosscher wrote:
Hello,
For some time now, I've wanted to see where compile time goes in a
typical GCC build, because nobody really seems to know what the
compiler spends its time on. The impressions that get published about
gcc usually indicate that there is at least a feeling that GCC is
On Thu, 20 May 2010, Steven Bosscher wrote:
> * The C front end (preprocessing+lexing+parsing) costs ~17%. For an
> optimizing compiler with so many passes, this is quite a lot.
Unlike C++ where a lot of speedups were done around 2004-5, I don't think
much has been done about speeding up the C f
No Asbestos required - but .. I do have some observations..
I write pretty much all my serious (day-job) code in ObjC and..
... I have stated that it's an intention to make *that*, at least
work at V2 on FSF.
Having said that:
a) I have not anything like as much attachment to ObjC++ ...
b
On 05/20/2010 09:17 PM, Vladimir Makarov wrote:
Steven Bosscher wrote:
For some time now, I've wanted to see where compile time goes in a
typical GCC build, because nobody really seems to know what the
compiler spends its time on. The impressions that get published about
gcc usually indicate
On Thu, 2010-05-20 at 21:02 +0200, Steven Bosscher wrote:
> Hello,
>
> The Obj-C++ front end is effectively unmaintained, and has virtually
> no serious users. I propose to remove it from GCC.
Maybe we could consider, for the putative people wanting to maintain
that frontend, to make it a plugin
On Thu, May 20, 2010 at 9:54 PM, IainS wrote:
> No Asbestos required - but .. I do have some observations..
>
> I write pretty much all my serious (day-job) code in ObjC and..
> ... I have stated that it's an intention to make *that*, at least work at
> V2 on FSF.
>
> Having said that:
>
> a) I
On Thu, May 20, 2010 at 10:20 PM, Basile Starynkevitch
wrote:
> On Thu, 2010-05-20 at 21:02 +0200, Steven Bosscher wrote:
>> Hello,
>>
>> The Obj-C++ front end is effectively unmaintained, and has virtually
>> no serious users. I propose to remove it from GCC.
>
> Maybe we could consider, for the
> * Adding and subtracting the above numbers, the rest of the compiler,
> which is mostly the RTL parts, still account for 100-17-16-8=59% of
> the total compile time. This was the most surprising result for me.
That figure is a little skewed though, the rest is not entirely RTL.
Front-end (3):
Hi Vlad,
On Thu, May 20, 2010 at 9:17 PM, Vladimir Makarov wrote:
>> For some time now, I've wanted to see where compile time goes in a
>> typical GCC build, because nobody really seems to know what the
>> compiler spends its time on. The impressions that get published about
>> gcc usually indicat
> That figure is a little skewed though, the rest is not entirely RTL.
Now without some annoying typo in a formula...
Front-end (3):
lexical_analysis 6.65
preprocessing 27.59
parser 31.53
Hi,
I don't know is it big or not to have such time spend in RTL parts. But I
think that this RTL part could be decreased if RTL (magically :) would have
smaller footprint and contain less details.
Bah, no wand... :-)
I noticed while working on the dragonegg plugin that replacing gimple ->
Steven Bosscher writes:
> And finally: expand. This should be just a change of IR format, from
> GIMPLE to RTL. I have no idea why this pass always shows up in the top
> 10 of slowest parts of GCC. Lowering passes on e.g. WHIRL, or GENERIC
> lowering to GIMPLE, never show up in the compile time
On Thu, May 20, 2010 at 2:09 PM, Ian Lance Taylor wrote:
> Steven Bosscher writes:
>
>> And finally: expand. This should be just a change of IR format, from
>> GIMPLE to RTL. I have no idea why this pass always shows up in the top
>> 10 of slowest parts of GCC. Lowering passes on e.g. WHIRL, or
On Thu, May 20, 2010 at 10:54 PM, Duncan Sands wrote:
> I noticed while working on the dragonegg plugin that replacing gimple -> RTL
> with gimple -> LLVM IR significantly reduced the amount of memory used by
> the compiler at -O0. I didn't investigate where the memory was going, but
> it seems l
On Thu, May 20, 2010 at 11:14 PM, Xinliang David Li wrote:
> stack variable overlay and stack slot assignments is here too.
Yes, and for these I would like to add a separate timevar. Agree?
Ciao!
Steven
On Thu, May 20, 2010 at 2:18 PM, Steven Bosscher wrote:
> On Thu, May 20, 2010 at 11:14 PM, Xinliang David Li
> wrote:
>> stack variable overlay and stack slot assignments is here too.
>
> Yes, and for these I would like to add a separate timevar. Agree?
Yes. (By the way, we are rewriting this
On my codes, pre-RA instruction scheduling on X86-64 (a) improves run
times by roughly 10%, and (b) costs a lot of compile time.
The -fscheduling option didn't seem to be on in your time tests (I think
it's not on by default on that architecture at -O2).
Brad
Hello,
I have a FORTRAN code that uses some c routines. I compile it with gcc
and gfortran in RedHat Linux without any problem. Recently I bought a
laptop with Ubuntu. I have gcc and gfortran version 4.4.3 in it. When
I compile the code, I see the following warning:
warning: ignoring return value
Hello,
I have a FORTRAN code that uses some c routines. I compile it with gcc
and gfortran in RedHat Linux without any problem. Recently I bought a
laptop with Ubuntu. I have gcc and gfortran version 4.4.3 in it. When
I compile the code, I see the following warning:
warning: ignoring return value
Snapshot gcc-4.5-20100520 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20100520/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Muhammad Akbar writes:
> I have a FORTRAN code that uses some c routines. I compile it with gcc
> and gfortran in RedHat Linux without any problem. Recently I bought a
> laptop with Ubuntu. I have gcc and gfortran version 4.4.3 in it. When
> I compile the code, I see the following warning:
>
> wa
On May 20, 2010, at 8:04 AM, Steven Bosscher wrote:
> On Mon, May 17, 2010 at 8:44 AM, Maxim Kuvyrkov
> wrote:
>> CodeSourcery is working on improving performance for Intel's Core 2 and Core
>> i7 families of processors.
>>
>> CodeSourcery plans to add support for unaligned vector instructions
On Thu, May 20, 2010 at 09:40:47AM -0700, Mark Mitchell wrote:
> It is of course a feature much
> less valuable on a workstation/server class operating system than on the
> VxWorks/RTEMS class of RTOS systems.
Even on servers this option may be quite valuable. I recall seing
figures that showed u
On Thu, May 20, 2010 at 9:35 PM, Alan Modra wrote:
> On Thu, May 20, 2010 at 09:40:47AM -0700, Mark Mitchell wrote:
>> It is of course a feature much
>> less valuable on a workstation/server class operating system than on the
>> VxWorks/RTEMS class of RTOS systems.
>
> Even on servers this option
David Edelsohn wrote:
>>> It is of course a feature much
>>> less valuable on a workstation/server class operating system than on the
>>> VxWorks/RTEMS class of RTOS systems.
> No one disagrees with the potential benefit of the feature.
OK; I must have misremembered.
I believe our current imple
50 matches
Mail list logo
