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
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
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 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
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
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
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
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
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 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 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 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
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
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 ->
> 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 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
> * 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):
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
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, 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 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
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 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
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
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
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
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
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
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
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
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
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 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-
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
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
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
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
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
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
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 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 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 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.
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: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
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
... 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.
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[
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.
50 matches
Mail list logo
