I'm still waiting for the testsuite to complete (it's been running
just for about 24 hours so far). In the meanwhile I'd like to discuss
the first performance results, which I've put on the Wiki:
First number is GCC with Boehm's GC and the number in parentheses is
GCC with page collector.
combin
On 6/23/06, Laurynas Biveinis <[EMAIL PROTECTED]> wrote:
All in all, IMHO this data favours against Boehm's GC in GCC. But
before deciding I would like to enable generational GC features, if
that will help with run time. On the other hand, I don't see how peak
memory usage could be reduced.
What
On Jun 23, 2006, at 8:51 AM, Laurynas Biveinis wrote:
First number is GCC with Boehm's GC and the number in parentheses is
GCC with page collector.
combine.c: top mem usage: 52180k (13915k). GC execution time 0.66
(0.61) 4% (4%). User running time: 0m16 (0m14).
Are these with checking on or of
>
> On Jun 23, 2006, at 8:51 AM, Laurynas Biveinis wrote:
> > First number is GCC with Boehm's GC and the number in parentheses is
> > GCC with page collector.
> >
> > combine.c: top mem usage: 52180k (13915k). GC execution time 0.66
> > (0.61) 4% (4%). User running time: 0m16 (0m14).
>
> Are the
Thanks! I put an updated page up at
http://kegel.com/gcc/summit2006.html
I won't be attending myself this year (I needed a break from travel),
but if anyone's blogging the event, please let me know and I'll
link to their blog from my page.
- Dan
On 6/23/06, Andrey Belevantsev <[EMAIL PROTECTE
Bugger, this went to testresults insetad of here... sorry for that...
-- Forwarded message --
From: Christian Joensson <[EMAIL PROTECTED]>
Date: Jun 23, 2006 8:09 PM
Subject: Lots of gfortrans testsuite failuers on sparc64-linux:
undefined reference to `_gfortran_reshape_r8
To: [E
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of
> Ron McCall
> Sent: Thursday, June 01, 2006 2:33 PM
> To: gcc@gcc.gnu.org
> Subject: Intermixing powerpc-eabi and powerpc-linux C code
>
> Hi!
>
> Does anyone happen to know if it is possible to link
>
Last fall I produced the RABLE document which described the approach I
thought should be taken to write a new register allocator for GCC.
A new register allocator written from scratch is a very long term
project (measured in years), and there is no guarantee after all that
work that we'd end up w
On 6/23/06, Laurynas Biveinis <[EMAIL PROTECTED]> wrote:
What do you think?
Is it possible to turn garbage collection totally off for a null-case
run-time comparison or would that cause thrashing except for very
small jobs?
--
David L Nicol
"if life were like Opera, this would probably
have po
Andrew MacLeod wrote:
A new register allocator written from scratch is a very long term
project (measured in years), and there is no guarantee after all that
work that we'd end up with something which is remarkably better. One
would hope that it is a lot more maintainable, but the generated code
I'm currently working on a massive overhaul of the visibility code to
make it play nice with C++. One of the issues I've run into is the
question of priority of #pragma visibility versus other sources of
visibility information.
Consider:
#pragma GCC visibility push(hidden)
class __attrib
On Fri, 2006-06-23 at 15:29 -0400, Robert Dewar wrote:
> Andrew MacLeod wrote:
>
> > A new register allocator written from scratch is a very long term
> > project (measured in years), and there is no guarantee after all that
> > work that we'd end up with something which is remarkably better. One
Andrew MacLeod wrote:
I am personally not a believer in combining register allocation and
scheduling. They are two different problems, and although there is some
interaction, I am still in the "keep them seperate" camp.
I disagree, there is in fact much more than "some interaction", there
is
On Fri, Jun 23, 2006 at 04:30:01PM -0400, Robert Dewar wrote:
> >However, RABLET is not writing a register allocator so its moot
> >anyway :-).
>
> indeed, moot = disussable, undecided, so here we are discussing
> (or if you like to use the verb, mooting) the issue.
Please try the other definitio
Daniel Jacobowitz wrote:
Please try the other definition, which he clearly meant:
2. Of purely theoretical or academic interest; having no
practical consequence; as, the team won in spite of the
bad call, and whether the ruling was correct is a moot
question.
Well
On 6/23/06, Robert Dewar <[EMAIL PROTECTED]> wrote:
Well I am not sure what he meant, but for sure it is not the
case that optimal register allocation and scheduling is of only
theoretical or academic interest with no practical consequences!
Thanks for making that point.
Now, what do you think
Steven Bosscher wrote:
Now, what do you think about this RABLET idea, which has nothing to do
with either register allocation or scheduling? ;-)
Well I would not say that it has nothing to do with register allocation!
But indeed this seems a promising approach. The real question in my mind
is
Hello, I would like to know if there is a fortran compiler that runs
on AMD 64 bits. I have installed suse 10.1 linux on my computer, I
would really apreciated all your help. I heard yours also have C and
C++.
Thank you very much, I write you from Argentina,
héctor Riojas Roldan
Hello,
One of things mingw32 C runtime lacks is an implementation of
__cxa_atexit.
However, as explained in the comment below, some of the behaviour of
__cxa_atexit is already in the C runtime atexit implementation.
Adding the object below to libstdc++ or libgcc.a and configuring with
__cxa_ate
Andrew MacLeod <[EMAIL PROTECTED]> writes:
> This describes my current work-in-progress, RABLET, which stands for
> RABLE-Themes, and conveniently implies something smaller.
Thanks for this proposal.
> ssa-to-rtl
> spill cost analysis
> global allocation
> spiller
> spill location optimizer
> i
Jason Merrill wrote:
Nice to see this stuff getting improved!
> #pragma GCC visibility push(hidden)
> class __attribute((visibility("default"))) A
> {
> void f ();
> };
>
> void A::f() { }
>
> Here I think we'd all agree that f should get default visibility.
Agreed.
> class A
Mark Mitchell <[EMAIL PROTECTED]> writes:
> Jason Merrill wrote:
> > Now, templates:
> >
> > template __attribute((visibility ("hidden")) T f(T);
> > #pragma GCC visibility push(default)
> > extern template int f(int);
> > #pragma GCC visibility pop
> >
> > This could really go either wa
Snapshot gcc-4.1-20060623 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20060623/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On 6/23/06, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
...
1 - One of the core themes in RABLE was very early selection of
instructions from patterns. RTL patterns are initially chosen by the
EXPAND pass. EXPAND tends to generates better rtl patterns by being
handed complex trees which it can pro
It looks like crt1.asm unconditionally includes an sh3e opcode (stc
spc,r1) which causes problems trying to build an sh2a-single-only
executable, which falls back to sh2e but doesn't have this sh3e
opcode. Comments?
1091 ! Here handler available, call it.
1092
I have run into a build problem with tonights gcc trunk on MacOS X which
didn't exist in yesterdays
svn pull. The gcc trunk build on MacOS X 10.4.6 crashes with...
checking how to run the C++ preprocessor...
/sw/src/fink.build/gcc4-4.1.999-20060623/darwin_objdir/./gcc/xgcc
-shared-l
Ian Lance Taylor wrote:
> Andrew MacLeod <[EMAIL PROTECTED]> writes:
>
>> This describes my current work-in-progress, RABLET, which stands for
>> RABLE-Themes, and conveniently implies something smaller.
>
> Thanks for this proposal.
>
>
>> ssa-to-rtl
>> spill cost analysis
>> global allocation
> It looks like crt1.asm unconditionally includes an sh3e opcode (stc
> spc,r1) which causes problems trying to build an sh2a-single-only
> executable, which falls back to sh2e but doesn't have this sh3e
> opcode. Comments?
It's not actually unconditional, but the condition it depends on is set
c
> It's not actually unconditional, but the condition it depends on is set
> conditionally with a flawed condition. Please try the attached patch.
That seems to fix it, although I only tested a simple hello.c program.
Thanks!
On Fri, 2006-06-23 at 23:08 -0400, Daniel Berlin wrote:
> Ian Lance Taylor wrote:
> >
> > Here I think you are waving your hands a little too hard. RTL level
> > CSE is significant for handling common expressions exposed by address
> > calculations and by DImode (and larger) computations. On so
Ian Lance Taylor wrote:
> Don't you still have to deal with this case?
>
> #pragma GCC visibility push(hidden)
> template T f(T);
> #pragma GCC visibility pop
> ...
> #pragma GCC visibility push(default)
> extern template int f(int);
> #pragma GCC visibility pop
>
> Personally I wouldn't mind sa
On Fri, 2006-06-23 at 15:07 -0700, Ian Lance Taylor wrote:
> You omitted the RTL loop optimizer passes, which still do quite a bit
> of work despite the tree-ssa loop passes. Also if-conversion and some
> minor passes, though they are less relevant.
Which brings up a good discussion. I presume t
On Jun 23, 2006, at 9:39 PM, Andrew MacLeod wrote:
On Fri, 2006-06-23 at 15:07 -0700, Ian Lance Taylor wrote:
You omitted the RTL loop optimizer passes, which still do quite a bit
of work despite the tree-ssa loop passes. Also if-conversion and
some
minor passes, though they are less rele
Andrew MacLeod <[EMAIL PROTECTED]> writes:
> On Fri, 2006-06-23 at 15:07 -0700, Ian Lance Taylor wrote:
>
> > You omitted the RTL loop optimizer passes, which still do quite a bit
> > of work despite the tree-ssa loop passes. Also if-conversion and some
> > minor passes, though they are less rel
34 matches
Mail list logo
