>> which seems to work, but I'm really concerned about the manuals
>> warning of the input and output operads being in seperate places.
>>
>> Which form is correct?
>
>static __inline__ void atomic_inc(atomic_t *v)
>{
> __asm__ __volatile__("addql #1,%0" : "+m" (*v));
>}
>
>Works just fine,
On 2005-03-02, at 05:20, Ed Smith-Rowland wrote:
In fact, I'm somewhat curious what caused folks to jump into the
breach with parsers. From reading the lists it seems to be
maintainability and stomping out corner case problems for the most
part.
Perhaps a parser toolset is emerging that will d
James A. Morrison wrote:
Ed Smith-Rowland <[EMAIL PROTECTED]> writes:
On 1 Mar 2005 at 8:17, James A. Morrison wrote:
Hi,
I've decided I'm going to try to take the time and cleanup and
update
the
Pascal frontend for gcc and try it get it integrated into the upstream
source. I'm doing this
> From: "Joseph S. Myers" <[EMAIL PROTECTED]>
>> On Tue, 1 Mar 2005, Paul Schlie wrote:
>> Might it be possible to alternatively add an attribute symbol hook so that a
>> target may easily define an arbitrary target specific named attribute which
>> may be utilized without having to patch the parse
James A. Morrison wrote:
> I've decided I'm going to try to take the time and cleanup and update
> the Pascal frontend for gcc and try it get it integrated into the
> upstream source.
Nice to hear that you want to work on Pascal. However did you notice
that gpc _is_ changing. In particular, the l
Ed Smith-Rowland <[EMAIL PROTECTED]> writes:
> On 1 Mar 2005 at 8:17, James A. Morrison wrote:
>
> > Hi,
> > I've decided I'm going to try to take the time and cleanup and
> > update
> > the
> > Pascal frontend for gcc and try it get it integrated into the upstream
> > source. I'm doing this
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2005-03-02 10:52:38 +0800 Mike Stump <[EMAIL PROTECTED]> wrote:
[snipped..]
P.S.: cc'ed to the GNUstep list just for informational purpose
[ assuming that list is still closed, since, you didn't say they
opened it ]
Will you please stop doing that.
On Feb 28, 2005, at 3:41 AM, Lars Sonchocky-Helldorf wrote:
I'd like to know what the 'official' position regarding ObjC++ is now.
Anybody willing to clear up?
Sure, why not... Either, someone will submit a clean, safe patch and
it will be reviewed and OKed and it will be checked in, or that's w
On Mar 1, 2005, at 9:46 PM, Marcin Dalecki wrote:
Hugh? I see the argument that another front-end will exercise more of
the back-end, since
chances are that it will trigger code paths in it which other
languages don't use.
However I can hardly see any Pascal language feature/construct, which
wou
On 2005-03-02, at 03:36, Andrew Pinski wrote:
Actually I disagree with you GPC is much smaller than Java,
If you have only USCDII in mind yes. But not if you look after any of
the usable, aka
Delfi, implementation of it. You always have to have runtime libraries.
and doing full converage
for a la
After trying to build the fortran compiler I'm convinced that at a cut
down version of the multi precision libraries it requires should be
included
in to the compiler tree. The reasons are as follows:
1. They should be there for reference in bug checking.
2. This would make installation on system
On Mar 1, 2005, at 9:29 PM, Marcin Dalecki wrote:
On 2005-03-02, at 03:22, Ed Smith-Rowland wrote:
On 1 Mar 2005 at 8:17, James A. Morrison wrote:
Hi,
I've decided I'm going to try to take the time and cleanup and
update
the
Pascal frontend for gcc and try it get it integrated into the
upstre
On 2005-03-02, at 03:22, Ed Smith-Rowland wrote:
On 1 Mar 2005 at 8:17, James A. Morrison wrote:
Hi,
I've decided I'm going to try to take the time and cleanup and
update
the
Pascal frontend for gcc and try it get it integrated into the upstream
source. I'm doing this because I wouldn't like t
On 1 Mar 2005 at 8:17, James A. Morrison wrote:
Hi,
I've decided I'm going to try to take the time and cleanup and update
the
Pascal frontend for gcc and try it get it integrated into the upstream
source. I'm doing this because I wouldn't like to see GPC work with GCC
4+. I don't care at all at
On Feb 26, 2005, at 8:01 AM, [EMAIL PROTECTED] wrote:
gcc -XLinker -M test.c 2>test.map
would output some usful information about locating
function to lib and ...
The detail analyze of them would be very useful.
Where can I find some introduce document about them?
This list isn't for such questions
On Tue, 1 Mar 2005, Paul Schlie wrote:
> Might it be possible to alternatively add an attribute symbol hook so that a
> target may easily define an arbitrary target specific named attribute which
> may be utilized without having to patch the parser, etc. to do so?
>
> Thereby one could easily def
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2005-03-02 10:07:25 +0800 Mike Stump <[EMAIL PROTECTED]> wrote:
On Feb 25, 2005, at 7:41 PM, Rogelio M.Serrano Jr. wrote:
I have also moved all my changes to gcc.c and c-incpath.c into
config/linux.h and config/frameworks.c. the latter is just darwin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2005-03-02 10:03:56 +0800 Mike Stump <[EMAIL PROTECTED]> wrote:
On Feb 25, 2005, at 9:35 AM, Rogelio M.Serrano Jr. wrote:
what is darwin_register_objc_includes in gcc/config/darwin-c.c for?
is
it needed for linux?
/* Register the GNU objective-C run
On Feb 25, 2005, at 7:41 PM, Rogelio M.Serrano Jr. wrote:
I have also moved all my changes to gcc.c and c-incpath.c into
config/linux.h and config/frameworks.c. the latter is just darwin-c.c
with the pragma stuff removed.
Sounds reasonable.
I also have a problem with -F switch it makes gcc hang.
S
On Feb 25, 2005, at 9:35 AM, Rogelio M.Serrano Jr. wrote:
what is darwin_register_objc_includes in gcc/config/darwin-c.c for? is
it needed for linux?
/* Register the GNU objective-C runtime include path if STDINC. */
/* Register the GNU OBJC runtime include path if we are compiling
OBJC
wi
On Tue, 1 Mar 2005, Peter Barada wrote:
>
> I'm trying to improve atomic operations for ColdFir ein a 2.4 kernel, and
> I tried the following following the current online manual at:
> http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/Extended-Asm.html#Extended-Asm
>
> static __inline__ void atomic_inc(at
> Joseph S. Myers writes:
> How about calling decl_attributes from fname_decl so a target
> insert_attributes hook can add attributes to __func__? Would that suffice
> to solve your problem?
Might it be possible to alternatively add an attribute symbol hook so that a
target may easily define an a
On Mar 1, 2005, at 7:54 PM, Peter Barada wrote:
which seems to work, but I'm really concerned about the manuals
warning of the input and output operads being in seperate places.
Which form is correct?
static __inline__ void atomic_inc(atomic_t *v)
{
__asm__ __volatile__("addql #1,%0" : "+m"
I'm trying to improve atomic operations for ColdFir ein a 2.4 kernel, and
I tried the following following the current online manual at:
http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/Extended-Asm.html#Extended-Asm
static __inline__ void atomic_inc(atomic_t *v)
{
__asm__ __volatile__("addql #
On Wed, 2 Mar 2005, Bernardo Innocenti wrote:
> To move strings into program memory, there's a macro like this:
>
> #define PSTR(s) ({ static const char __c[] PROGMEM = (s); &__c[0]; })
>
>
> But this wouldn't work because __func__ does not work like
> a string literal:
>
> #define TRACEMSG(ms
> Thomas Gill wrote:
> I'm working on a GCC backend for a small embedded processor. We've got a
> Harvard architecture with 16 bit data addresses and 24 bit code
> addresses. How well does GCC support having different sized pointers for
> this sort of thing? The macros POINTER_SIZE and Pmode seem t
Giovanni Bajo wrote:
Mike Hearn <[EMAIL PROTECTED]> wrote:
In your __FUNCTION__ case, we are basically in the latter group. __FUNCTION__
is a well-documented extension in C90 (it's part of C99 in some form now), and
it was never documented to be a macro. The fact that was named like a macro and
wo
Mark Mitchell <[EMAIL PROTECTED]> writes:
> James A. Morrison wrote:
>
> > I made this post, with my changes posted, to see if I would get any
> > support.
>
> I'd also suggesting contacting the GCC SC to see what their reaction
> would be.
That's a good point. However, if I do get far eno
On Tue, 1 Mar 2005, Prof A Olowofoyeku (The African Chief) wrote:
> Instead of starting a totally separate project, wouldn't it be better
> to coordinate your efforts with the GPC development team?
Effective coordination will require, for a start, the GPC mailing list to
accept messages from no
E. Weddington wrote:
Personally, I'm not necessarily convinced that adding Pascal to GCC is
a good idea. I like Pascal just fine, but because every new language
adds to the load on everyone. (In my ideal world, we'd have stable
enough interfaces that it was easy to maintain front ends separate
Mark Mitchell wrote:
James A. Morrison wrote:
I made this post, with my changes posted, to see if I would get any
support.
I'd also suggesting contacting the GCC SC to see what their reaction
would be.
Personally, I'm not necessarily convinced that adding Pascal to GCC is
a good idea. I like
James A. Morrison wrote:
I made this post, with my changes posted, to see if I would get any support.
I'd also suggesting contacting the GCC SC to see what their reaction
would be.
Personally, I'm not necessarily convinced that adding Pascal to GCC is a
good idea. I like Pascal just fine, but
On Tue, 2005-03-01 at 22:21 +, Joseph S. Myers wrote:
> On Tue, 1 Mar 2005, Daniel Berlin wrote:
>
> > > That is, there won't be
> > > any problems like those mentioned in comments in bugzilla-checkout and
> > > htdocs-checkout and cgibin-checkout with the new scripts.
> >
> > I don't unde
Helge Bahmann wrote:
void (A::*function2)(void) throw()=&A::function2;
(a.*function2)();
however for the call through pointer function2 gcc will always generate an
indirect call, i386 assembly for example looks like:
Yes, it should be able to do so, but it's not. This is probably
somethi
On Tue, 1 Mar 2005, Daniel Berlin wrote:
> > That is, there won't be
> > any problems like those mentioned in comments in bugzilla-checkout and
> > htdocs-checkout and cgibin-checkout with the new scripts.
>
> I don't understand what the real problem is, because the comments claim
> something
Hello,
I would be interested in testing patches that you produce. It seems
that inlining heuristics have quite a large effect on my code, compared
to other codes.
As an aside, do you (or anyone) know what kind of compile-time speedup
can be gained by boostrapping with more extreme options?
On Tue, 2005-03-01 at 21:00 +, Joseph S. Myers wrote:
> On Tue, 1 Mar 2005, Daniel Berlin wrote:
>
> > > Date: 2005-03-01 15:26:25 -0500 (Tue, 01 Mar 2005)
>
> I take it the time will be shown in gcc.gnu.org's timezone (fixed at UTC),
> not depending on the timezone of the person making the
On Tue, Mar 01, 2005 at 10:29:45AM -0800, Janis Johnson wrote:
> Is command line processing relevant for embedded targets? (I have no
> idea.) Tests that pass options to the test program could be skipped
> for embedded targets and for other kinds of testing where it isn't
> reliable. The dg-prog
On Tue, 1 Mar 2005, Daniel Berlin wrote:
> > Date: 2005-03-01 15:26:25 -0500 (Tue, 01 Mar 2005)
I take it the time will be shown in gcc.gnu.org's timezone (fixed at UTC),
not depending on the timezone of the person making the commit?
> > WebSVN: http://dberlin.org/cgi-bin/viewcvs.cgi?
> > view=
vivek sukumaran <[EMAIL PROTECTED]> wrote:
Are there any ready to use gcc rpms for,
host:x-86,redhat9.0
target:alpha
The right mailing list to ask is the one at
http://sources.redhat.com/ml/crossgcc/
When you do post there, be sure to mention what OS
the target will be running.
If the target i
The SVN repo has been updated again.
Again, because different tags were included in this dump, you will have
to recheckout a working copy.
The only tags excluded from this run were tags with "merge" in the name,
and tags with ".*-ss-.*" and ".*_ss_.*".
For those who want http access, i can give
On Feb 21, 2005, at 3:45 AM, Mile Davidovic wrote:
Functions are completely the same.
What is the reason for such compilere behaviour?
Just lack of code in the compiler to do better, see
http://gcc.gnu.org/ml/gcc-patches/2002-08/msg00354.html for some of the
details and starting point, should you
Caroline Tice wrote:
There might be some validity in the idea of modifying this optimization,
in the future, to consider
the size of a basic block in addition to it's "hot-ness", when deciding
which partition to put it into.
I expect this would not be that difficult to implement, and would
proba
I apologize for not responding to these messages sooner; I was out of
town for a few days and only
just read them.
In the first place, I am a little confused about exactly what Joern is
objecting to. If I am reading your
emails correctly, you seem to feel that the hot/cold partitioning
optimiz
Janis Johnson wrote:
I also find it annoying that the dump files aren't cleaned up. Should
the dump files for failing tests be left, or would it be OK to remove
all of them?
Much as I don't use the failing executables left behind by the
testsuite, I wouldn't use the dump files. They can be easil
> On Tue, 1 Mar 2005 16:49:04 +0100, Richard Guenther
> <[EMAIL PROTECTED]> wrote:
> > On Tue, 1 Mar 2005 16:14:14 +0100, Jan Hubicka <[EMAIL PROTECTED]> wrote:
> >
> > > Concerning growth limits:
> > >
> > > If you take a look on when -finline-unit-growth limit hits, it is clear
> > > that it hit
On Tue, Mar 01, 2005 at 01:29:48PM -0500, Andrew Pinski wrote:
>
> On Mar 1, 2005, at 1:25 PM, Janis Johnson wrote:
>
> >I also find it annoying that the dump files aren't cleaned up. Should
> >the dump files for failing tests be left, or would it be OK to remove
> >all of them?
>
> I find it e
On Tuesday 01 March 2005 02:30, Steven Bosscher wrote:
> On Tuesday 01 March 2005 02:03, Jan Hubicka wrote:
> > You still didn't get into the fun part of actually inlining all the
> > inlines in in Gerald's testcase ;)
>
> I'll let it run to the end tomorrow, for at most one full day ;-)
It got ki
Richard Guenther <[EMAIL PROTECTED]> writes:
> Hi!
>
> struct cgraph_edge is currently member of two lists, i.e.
> it contains two "next" pointers, but is annotated like
>
> struct cgraph_edge GTY((chain_next ("%h.next_caller")))
> {
> struct cgraph_node *caller;
> struct cgraph_node *callee
On Mar 1, 2005, at 1:25 PM, Janis Johnson wrote:
I also find it annoying that the dump files aren't cleaned up. Should
the dump files for failing tests be left, or would it be OK to remove
all of them?
I find it even more annoying as on targets which uses case insensitive
storing
of files, causes
On Mon, Feb 28, 2005 at 08:45:17PM -0500, Daniel Jacobowitz wrote:
> On Mon, Feb 28, 2005 at 04:14:12PM -0800, Janis Johnson wrote:
> > > DejaGnu's definition of ${tool}_load has an optional argument for flags
> > > to pass to the test program, but none of the procedures in DejaGnu or in
> > > gcc/
On Mon, Feb 28, 2005 at 10:23:56AM -0700, Jeffrey A Law wrote:
> On Mon, 2005-02-28 at 17:08 +0100, Richard Guenther wrote:
> > Hi!
> >
> > It seems the current dg infrastructure does not support scanning
> > tree-dumps dumped via -fdump-ipa-XXX because they are labeled
> > differently. I worked
On Tuesday 01 March 2005 19.02, Soumitra Kumar wrote:
> Henrik,
> So, if I get the following output (rule no after a
> lookahead symbol), finding the ambiguous rules is
> trivial.
well, you can search for all the states that have a goto your state 10.
On Tue, 1 Mar 2005 16:49:04 +0100, Richard Guenther
<[EMAIL PROTECTED]> wrote:
> On Tue, 1 Mar 2005 16:14:14 +0100, Jan Hubicka <[EMAIL PROTECTED]> wrote:
>
> > Concerning growth limits:
> >
> > If you take a look on when -finline-unit-growth limit hits, it is clear
> > that it hits very often on
On Tue, 1 Mar 2005 16:14:14 +0100, Jan Hubicka <[EMAIL PROTECTED]> wrote:
> Concerning growth limits:
>
> If you take a look on when -finline-unit-growth limit hits, it is clear
> that it hits very often on small units (several times in the kernel,
> testsuite and such) just because there is tinn
Steve Snyder wrote:
Specifically, I get many, many occurances of this (on the 3.4.3
system):
/usr/include/c++/3.3.2/bits/stl_alloc.h:232: undefined reference to
`std::__default_alloc_template::allocate(unsigned int)'
Shouldn't there be binary compatibility between these 2 versions of
GCC?
T
On Tue, 2005-03-01 at 15:29, Petko Manolov wrote:
> On Tue, 1 Mar 2005, Paul Brook wrote:
>
> > The "old" arm-none-elf and arm-linux targets still use SJLJ exceptions. They
> > will probably never be "fixed" as this would involve an ABI change.
>
> Didn't understand that. How is all non scratch
On Tuesday 01 March 2005 15:29, Petko Manolov wrote:
> On Tue, 1 Mar 2005, Paul Brook wrote:
> > The "old" arm-none-elf and arm-linux targets still use SJLJ exceptions.
> > They will probably never be "fixed" as this would involve an ABI change.
>
> Didn't understand that. How is all non scratch F
Should there be binary compatibility between GCC versions 3.3.2 and
3.4.2?
I have a large (~40 source files) C++ application that builds and runs
correctly with GCC v3.3.2 (in Fedora Core #1). With GCC v3.4.2 (FC3)
the application builds correctly, yet fails to run correctly.
No errors or war
On Tue, 1 Mar 2005, Paul Brook wrote:
The "old" arm-none-elf and arm-linux targets still use SJLJ exceptions. They
will probably never be "fixed" as this would involve an ABI change.
Didn't understand that. How is all non scratch FP registers save at the
prologue related to the exceptions?
Pet
Hi,
so after reading the whole discussion, here are some of my toughts
for sanity check combined in one to reduce inbox pollution ;)
Concerning Richard's cost tweaks:
There is longer story why I like it ;)
I originally considered further tweaking of cost function as mostly lost
case as the repres
Thomas Gill wrote:
Hi all.
I'm working on a GCC backend for a small embedded processor. We've got a
Harvard architecture with 16 bit data addresses and 24 bit code
addresses. How well does GCC support having different sized pointers for
this sort of thing? The macros POINTER_SIZE and Pmode seem to
Steven Bosscher <[EMAIL PROTECTED]> writes:
> On Mar 01, 2005 02:17 PM, James A. Morrison <[EMAIL PROTECTED]> wrote:
>
> > Hi,
> >
> > I've decided I'm going to try to take the time and cleanup and update the
> > Pascal frontend for gcc and try it get it integrated into the upstream
> > sour
On 1 Mar 2005 at 8:17, James A. Morrison wrote:
> Hi,
>
> I've decided I'm going to try to take the time and cleanup and update
> the
> Pascal frontend for gcc and try it get it integrated into the upstream
> source. I'm doing this because I wouldn't like to see GPC work with GCC
> 4+. I don
On Tue, 1 Mar 2005 13:46:22 +0100, Jan Hubicka <[EMAIL PROTECTED]> wrote:
> Looks nice, you might also consider turing next_clone list into doubly
> linked list to speedup remove_node somewhat. Not sure how much that
> one counts.
I'd like to see profiles after the patch first - changing that on
> [Paul]:
> Is this problem present also in CSL-3.4.x branch?
That depends which target you are using. It Richard's analysis is correct this
is an ABI limitation rather than a compiler problem.
The "old" arm-none-elf and arm-linux targets still use SJLJ exceptions. They
will probably never be
On Mar 01, 2005 02:28 PM, Richard Guenther <[EMAIL PROTECTED]> wrote:
> Is it possible and beneficial to have both next pointers
> annotated with chain_next?
Unfortunately it is not. There are other places where this would
be useful, but gengtype does not support this at the moment.
Gr.
Steven
Oh, and please do not include [EMAIL PROTECTED] in the CC, because that
is not a public list so reply-to-all messages bounce.
Gr.
Steven
Hi!
struct cgraph_edge is currently member of two lists, i.e.
it contains two "next" pointers, but is annotated like
struct cgraph_edge GTY((chain_next ("%h.next_caller")))
{
struct cgraph_node *caller;
struct cgraph_node *callee;
struct cgraph_edge *next_caller;
struct cgraph_edge *next_
On Mar 01, 2005 02:17 PM, James A. Morrison <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I've decided I'm going to try to take the time and cleanup and update the
> Pascal frontend for gcc and try it get it integrated into the upstream source.
Since the GNU Pascal maintainers have publicly stated they
Original Message
>From: Zack Weinberg
>Sent: 28 February 2005 20:48
> I think I've addressed all the points you bring up in responses to
> other people. If I missed something, please let me know?
>
> zw
Nope, everything seems sound to me. This is a worthy bit of tidying up,
good luck
Hi,
I've decided I'm going to try to take the time and cleanup and update the
Pascal frontend for gcc and try it get it integrated into the upstream source.
I'm doing this because I wouldn't like to see GPC work with GCC 4+.
I don't care at all at supporting GPC on anything less than GCC 4.1 so
On Tue, 1 Mar 2005 13:41:27 +0100 (CET), Steven Bosscher
<[EMAIL PROTECTED]> wrote:
> On Mar 01, 2005 01:35 PM, Richard Guenther <[EMAIL PROTECTED]> wrote:
> > Try this,. bootstrapped on i686-pc-linux-gnu in progress.
>
> If this works, maybe we should consider this for 4.0 (as a compiler
> speedu
> On Tue, 1 Mar 2005 13:30:41 +0100, Jan Hubicka <[EMAIL PROTECTED]> wrote:
> > > On Tue, 1 Mar 2005 02:03:57 +0100, Jan Hubicka <[EMAIL PROTECTED]> wrote:
> > >
> > > > OK, I will put this higher in the TODO list (but this is not 4.0
> > > > either). What was those less unrealistic tests? I reme
On Mar 01, 2005 01:35 PM, Richard Guenther <[EMAIL PROTECTED]> wrote:
> Try this,. bootstrapped on i686-pc-linux-gnu in progress.
If this works, maybe we should consider this for 4.0 (as a compiler
speedup), but for 4.1 we should really look into VECs instead of
doubly linked lists.
If your patch
On Tue, 1 Mar 2005 13:30:41 +0100, Jan Hubicka <[EMAIL PROTECTED]> wrote:
> > On Tue, 1 Mar 2005 02:03:57 +0100, Jan Hubicka <[EMAIL PROTECTED]> wrote:
> >
> > > OK, I will put this higher in the TODO list (but this is not 4.0
> > > either). What was those less unrealistic tests? I remember seein
> On Tue, 1 Mar 2005 02:03:57 +0100, Jan Hubicka <[EMAIL PROTECTED]> wrote:
>
> > OK, I will put this higher in the TODO list (but this is not 4.0
> > either). What was those less unrealistic tests? I remember seeing node
> > removal in profiles, but edge removal comes first here. Looks like I
Hi all.
I'm working on a GCC backend for a small embedded processor. We've got a
Harvard architecture with 16 bit data addresses and 24 bit code
addresses. How well does GCC support having different sized pointers for
this sort of thing? The macros POINTER_SIZE and Pmode seem to suggest
that ther
On Tue, 2005-03-01 at 10:54, Vladimir Ivanov wrote:
> Hello,
>
> [Richard]:
> Does this mean that GCC-3.4.x won't be fixed?
>
Most certainly it won't be. 3.4 is in regression-fix only mode and this
is not a regression.
R.
Hello,
[Richard]:
Does this mean that GCC-3.4.x won't be fixed?
[Paul]:
Is this problem present also in CSL-3.4.x branch?
Best regards,
-- Vladimir
On Tue, 1 Mar 2005, Richard Earnshaw wrote:
On Mon, 2005-02-28 at 12:51, Vladimir Ivanov wrote:
Hello all,
While compiling this:
On Mon, 2005-02-28 at 12:51, Vladimir Ivanov wrote:
> Hello all,
>
> While compiling this:
> http://sourceforge.net/projects/raytracer/
>
> I think I've spotted a bug in ARM port of G++.
>
> The problem is that many method functions tend to save all callee-saved FP
> registers, while they
On Mon, 2005-02-28 at 00:05, Zdenek Dvorak wrote:
> at the beginning of the stage 1, there always is lot of major changes
> queued up. It never lead to unmanageable amount of "breakage and
> disruption".
Then you clearly haven't tried to maintain a port other than x86-* or
*-linux.
The fact is
Hi!
It seems, the local on the GCC web page
http://gcc.gnu.org/install/specific.html
does not work due to wrong HTML format.
--
-=AV=-
Hello,
> Giv optimizations are just features which not
> implemented yet in the new loop unroller, so I think
> put it in bugzilla is not appropriate.
it most definitely is appropriate. This is a performance
regression. Even if it would not be, feature requests
can be put to Bugzilla.
The be
On Tue, 1 Mar 2005 02:03:57 +0100, Jan Hubicka <[EMAIL PROTECTED]> wrote:
> OK, I will put this higher in the TODO list (but this is not 4.0
> either). What was those less unrealistic tests? I remember seeing node
> removal in profiles, but edge removal comes first here. Looks like I
> finally
85 matches
Mail list logo
