> It's in now, BTW. Nothing broke. :-) (As I notified when I submitted the
> patch as an FYI prior to stage 1 opening, this was checked with a native
> bootstrap *and* a cross build.)
The GNAT tools don't build automatically for me anymore, I need to explicitly
'make -C gcc gnattools'.
[EMAIL
Are there any ready to use gcc rpms for,
host:x-86,redhat9.0
target:alpha
thanking you
vivek
__
Do you Yahoo!?
Yahoo! Mail - 250MB free storage. Do more. Manage less.
http://info.mail.yahoo.com/mail_250
Hi,
IMHO "gnattools" should be added to "ADA_DIRS" in "gcc_release"
to generate snapshots properly. Otherwise, people who do not
download and install "gcc-ada" tarballs will get a bootstrap
error.
I no longer use official GCC source snapshots, but I still
ran into this issue as I make a copy of
On Feb 28, 2005, at 10:18 PM, Canqun Yang wrote:
Giv optimizations are just features which not
implemented yet in the new loop unroller, so I think
put it in bugzilla is not appropriate.
Bugzilla should be used more than just normal bugs but
also enhancements.
I test 171.swim on IA64 system with 1
Hi, Gr.Steven
Very thanks for your replyment.
Induction variables are variables whose successive
values form an arithmetic progression over a loop.
Induction variables are often divided into bivs (basic
induction variables), which are explicitly modified by
the same constant amount during eac
Hi,
Here is a unified diff for the proposed change (I think).
BR,
Johan
-Original Message-
From: Giovanni Bajo [mailto:[EMAIL PROTECTED]
Sent: den 1 mars 2005 02:03
To: Johan Bergman (KI/EAB)
Cc: gcc@gcc.gnu.org
Subject: Re: http://gcc.gnu.org/gcc-3.4/changes.html
Johan Bergman (KI/EA
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/testsuite/* are set up to pass such flags. It would be fairly
> > straight
Gabriel Dos Reis wrote:
And, yes, I appreciate your work a lot. That does not rule out
occasional disagreements.
I agree.
And, I think Nathanael and I have resolved the situation very
satisfactorily, so, as far as I'm concerned, everything worked as well
as could be hoped.
--
Mark Mitchell
Cod
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 ;-)
Gr.
Steven
Mark Mitchell <[EMAIL PROTECTED]> writes:
| Nathanael Nerode wrote:
| >>> Nathanael Nerode wrote:
| > It's in now, BTW. Nothing broke. :-)
|
| We need to talk about that.
|
| Independently of whether or not I made the right decision, your
| decision to check in the patch undermined the process
> On Tuesday 01 March 2005 01:33, Jan Hubicka wrote:
> > > On Monday 28 February 2005 10:25, Richard Guenther wrote:
> > > > > I can only wonder why we are having this discussion just after GCC
> > > > > 4.0 was branched, while it was obvious already two years ago that
> > > > > inlining heuristics
Johan Bergman (KI/EAB) <[EMAIL PROTECTED]> wrote:
> I propose the following change to
> http://gcc.gnu.org/gcc-3.4/changes.html. (The "alternative solution"
> was proposed by myself a while ago,
> but now I have realized that it is not backwards compatible.)
Please post the patch as an unified di
On Tuesday 01 March 2005 01:33, Jan Hubicka wrote:
> > On Monday 28 February 2005 10:25, Richard Guenther wrote:
> > > > I can only wonder why we are having this discussion just after GCC
> > > > 4.0 was branched, while it was obvious already two years ago that
> > > > inlining heuristics were goin
> On Monday 28 February 2005 10:25, Richard Guenther wrote:
> > > I can only wonder why we are having this discussion just after GCC 4.0
> > > was branched, while it was obvious already two years ago that inlining
> > > heuristics were going to be a difficult item with tree-ssa.
> >
> > There were
Nathanael Nerode wrote:
Apologies for committing.
Thanks.
And I don't mean to make a mountain out of a molehill. It certainly
looks like I made a wrong call about the patch, and I'm very psyched
that you're cleaning up this stuff. I'm taking everyone's feedback to
heart, and I certainly don't
> Surely it would be possible to use -ffixed-* options to reserve all the
> altivec registers and get precisely that effect?
Nah, I don't need to be that drastic. The RAID6 code is already in a
separate file that can have a specific additional set of compile flags,
so I can just enable altivec
On Mon, Feb 28, 2005 at 03:59:52PM -0800, Janis Johnson wrote:
> On Fri, Feb 25, 2005 at 08:14:04PM -0800, Steve Kargl wrote:
> >
> > at the top of the program to have dejagnu execute the
> > the a.out file. But, I want to execute "a.out 1 2 3".
> > Is this possible? I tried looking through gcc.
Apologies for committing. I committed before I heard from you saying
"No, don't", but apparently well after you had sent the message. My mail
receiving must have been a bit off. :-/
Indeed, as I see from another message, you considered putting "part 1" as
an early project and "part 2" as a stag
On Mon, Feb 28, 2005 at 03:59:52PM -0800, Janis Johnson wrote:
> On Fri, Feb 25, 2005 at 08:14:04PM -0800, Steve Kargl wrote:
> > I would like to write a short program to test the
> > command line parsing of gfortran. I know I can add
> >
> > ! {dg-do run}
> >
> > at the top of the program to ha
On Tuesday 01 March 2005 00:49, Mark Mitchell wrote:
> Nathanael Nerode wrote:
> >>>Nathanael Nerode wrote:
> >
> > It's in now, BTW. Nothing broke. :-)
>
> We need to talk about that.
>
> Independently of whether or not I made the right decision, your decision
> to check in the patch undermined
On Fri, Feb 25, 2005 at 08:14:04PM -0800, Steve Kargl wrote:
> I would like to write a short program to test the
> command line parsing of gfortran. I know I can add
>
> ! {dg-do run}
>
> at the top of the program to have dejagnu execute the
> the a.out file. But, I want to execute "a.out 1 2 3
Steven Bosscher wrote:
It's not about how long the branch may live, but the most time it
may have to be maintained before being merged.
We're splitting semantic hairs now, but you need to maintain the branch
during its lifetime, not just the 4 months prior to its merge. Anyway,
this is about all
Andrew Pinski wrote:
But it is documented on our own web site:
http://gcc.gnu.org/develop.html
Yes, I know. I still disagree with it. But don't care enough to keep
arguing about it.
Diego.
Nathanael Nerode wrote:
Nathanael Nerode wrote:
It's in now, BTW. Nothing broke. :-)
We need to talk about that.
Independently of whether or not I made the right decision, your decision
to check in the patch undermined the process. Rather than convincing me
I was in error, or developing a
On Feb 28, 2005, at 6:40 PM, Diego Novillo wrote:
Nathanael Nerode wrote:
"Although maintaining a development branch, including merging new
changes from
the mainline, is somewhat burdensome, the absolute worst case is that
such a
branch will have to be maintained for four months."
This is wrong.
Just to be clear, I do not want to criticize Mark or the Project system in
general. I quite *like* the project sequencing idea. I submitted the
libada-gnattools-branch project as two phases, and I think any major changes
from the second phase are perfectly suited to wait for stage 2. Furthermore
On Tuesday 01 March 2005 00:40, Diego Novillo wrote:
> Nathanael Nerode wrote:
> > "Although maintaining a development branch, including merging new changes
> > from the mainline, is somewhat burdensome, the absolute worst case is
> > that such a branch will have to be maintained for four months."
Nathanael Nerode wrote:
"Although maintaining a development branch, including merging new changes from
the mainline, is somewhat burdensome, the absolute worst case is that such a
branch will have to be maintained for four months."
This is wrong. There is no limit on how long a development branch
>>Nathanael Nerode wrote:
It's in now, BTW. Nothing broke. :-) (As I notified when I submitted the
patch as an FYI prior to stage 1 opening, this was checked with a native
bootstrap *and* a cross build.)
>>The libada-gnattools-branch suffers severely from having to be maintained
>>in parallel
On Mon, 2005-02-28 at 13:25 +0100, Marc Espie wrote:
> In article <[EMAIL PROTECTED]> you write:
>
> >People do break Ada bootstrap because they don't configure and test Ada,
> >they don't configure Ada because they complained about Ada build
> >machinery being non standard, delaying Ada build mac
Hi,
I propose the following change to http://gcc.gnu.org/gcc-3.4/changes.html.
(The "alternative solution" was proposed by myself a while ago,
but now I have realized that it is not backwards compatible.)
--
449c449,450
< As an
On Monday 28 February 2005 10:25, Richard Guenther wrote:
> > I can only wonder why we are having this discussion just after GCC 4.0
> > was branched, while it was obvious already two years ago that inlining
> > heuristics were going to be a difficult item with tree-ssa.
>
> There were of course co
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
Richard Sandiford <[EMAIL PROTECTED]> writes:
> Zack Weinberg <[EMAIL PROTECTED]> writes:
>> I have worked out a tentative plan for replacing most of these macros
>> with ordinary target hooks, and eliminating REG_OK_STRICT. I propose
>> to change GO_IF_LEGITIMATE_ADDRESS, GO_IF_MODE_DEPENDENT_AD
"Dave Korn" <[EMAIL PROTECTED]> writes:
> I'm basically in agreement with you here, and just want to suggest you can
> avoid an awful lot of code duplication by doing something like
>
> #ifdef REG_OK_STRICT
> #define ${CPU}_IS_STRICT 1
> #else
> #define ${CPU}_IS_STRICT 0
> #endif
This idiom i
Kazu Hirata <[EMAIL PROTECTED]> writes:
> Hi Zack,
>
>> So, the plan: Step 1 introduces - one at a time - target hooks
>> corresponding to each of the above macros. All callers are changed to
>> use the hooks.
...
>> Step 2 is to convert each architecture, one at a time, to make
>> target-hook d
Bernd Schmidt <[EMAIL PROTECTED]> writes:
> Zack Weinberg wrote:
>> I have worked out a tentative plan for replacing most of these
>> macros with ordinary target hooks, and eliminating REG_OK_STRICT.
>
> Are you planning to keep the observed behaviour, or do you want to
> make any enhancements that
Dale Johannesen wrote:
No, you should not turn on partitioning in situations where code
size is important to you.
You are missing the point. In my example, with perfect profiling
data, you still end up with
more code in the hot section,
Yes.
i.e. more pages are actually swapped in.
Unles
Hi Dave,
> I'm basically in agreement with you here, and just want to suggest you can
> avoid an awful lot of code duplication by doing something like
>
> #ifdef REG_OK_STRICT
> #define ${CPU}_IS_STRICT 1
> #else
> #define ${CPU}_IS_STRICT 0
> #endif
Sure. In fact, the FRV port and possible
Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:
> Unless -mcpu=POWER8 -mno-altivec -maltivec is legal ...
Yes, a later -msomething will override a previous -mno-something.
Presently, under OS X, GCC requires explicit definitions for static
template data members. That is,
template
struct foo
{
static int x;
};
template
int foo::x;
causes problems at link time. An explicit definition of the x member
m
An explicit Addressing Mode or mechanism to enable the identification
of "read-only" rtl static data references, there by enabling uC, and/or
DSP's with Harvard memory architectures, which typically require the use
of specialized load instructions to access it's ROM based program memory
space, to e
On Feb 28, 2005, at 10:19 AM, Joern RENNECKE wrote:
Dale Johannesen wrote:
Certainly. In general it will make the total size bigger, as does
inlining. If you have good
information about what's hot and cold, it should reduce the number of
pages that actually
get swapped in. The information h
> (insn 28 26 29 1 /mnt/disk2/src/gcc/gcc/libgcc2.c:464 (set (mem/i:HI
> (reg/f:HI 8 si [orig:30 D.1371 ] [30]) [5 +0 S2 A16])
> (subreg:HI (reg/v:DI 31 [ u ]) 0)) 1 {*movhi} (nil)
> (nil))
This is a tricky one. You need to split up the moves early enough to
let reload be flexible,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, Feb 28, 2005 at 10:13:00AM +0100, Josef Angermeier wrote:
> Rehi
> > It's been done a couple of times already, first by me, and later my
> > code was extended by a couple of other people. Don't know if you
> > want to start from scratch "on pr
Dale Johannesen wrote:
Certainly. In general it will make the total size bigger, as does
inlining. If you have good
information about what's hot and cold, it should reduce the number of
pages that actually
get swapped in. The information has to be good, though, as a branch from
hot<->cold
On Mon, 2005-02-28 at 10:01 -0800, Dale Johannesen wrote:
> On Feb 28, 2005, at 4:43 AM, Joern RENNECKE wrote:
>
> > Dale Johannesen wrote:
> >
> >>Well, no, what is supposed to happen (I haven't tried it for a
> >> while, so I don't promise
> >> this still works) is code like this:
> >>
> >>
On Feb 28, 2005, at 4:43 AM, Joern RENNECKE wrote:
Dale Johannesen wrote:
Well, no, what is supposed to happen (I haven't tried it for a
while, so I don't promise
this still works) is code like this:
.hotsection:
loop:
conditional branch (i?==1000) to L2
L1:
/* do stuff */
end loop:
/* sti
Original Message
>From: Hans-Peter Nilsson
>Sent: 28 February 2005 14:30
> On Mon, 28 Feb 2005, Dave Korn wrote:
>> Hmmm, actually, I would say that moving these macro definitions into
>> the cpu.c files is a fairly mechanical and trivial transformation.
>> Given:
>
> WRONG!
>
>> ${
Original Message
>From: gcc-owner On Behalf Of Kazu Hirata
>Sent: 28 February 2005 14:41
> So I would change each macro to an
> architecture-specific function in each architecture first. For
> example, GO_IF_LEGITIMATE_ADDRESS should look like this (taken from
> i386.h):
>
> #ifdef REG_
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 around this by replacing
>
> set output_file "[glob [file tail $testca
On Wed, Feb 23, 2005 at 12:56:20PM -0500, Patrick McFarland wrote:
> On Wednesday 23 February 2005 11:03 am, Florian Weimer wrote:
> >
> > I though that #gcc on oftc.net was more active, anyway, or has this
> > changed?
>
> This was more of a request for the #gcc on freenode to catch up with the r
> Zack Weinberg
> The target macros described in the "Addressing Modes" section of the
> internals manual are rather badly in need of cleaning up. I see three
> primary reasons why this is so:
- Very Nice; and wonder, although somewhat orthogonal, if it would be
similarly desirable to clean up
On Sun, 2005-02-27 at 18:16 -0500, Kazu Hirata wrote:
> Hi,
>
> Consider the following code from
> tree-ssa-dom.c:tree_ssa_dominator_optimize.
>
> /* Thread jumps, creating duplicate blocks as needed. */
> cfg_altered = thread_through_all_blocks ();
>
> /* Removal of statement
> Question: If we assume that a TImode would've been a more efficient mode
> to represent the record type above, would it not have been acceptable for
> the compiler to promote the alignment of this type to 128, given there
> are no apparent restrictions otherwise, or are there other C conventions
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 around this by replacing
set output_file "[glob [file tail $testcase].t??.[lindex $args 1]]"
with
set output_file "[glob [file tail $
Hello,
if I compile the following little code snippet:
#include
class A {
public:
virtual ~A(void) {}
static void function1(void) throw() {puts("Hello world\n");}
void function2(void) throw() {puts("Hello world!\n");}
};
int main()
{
A a;
void (*function1)(void)
Hello Swami,
You can either assign the work through the process of each indivudal who
worked on the code with a disclaimer from the company, or you could use
a corporate assignment which would cover all the employees at the firm.
All the best,
Ted TEah
Assignment Administrator
Zack Weinberg <[EMAIL PROTECTED]> writes:
> I have worked out a tentative plan for replacing most of these macros
> with ordinary target hooks, and eliminating REG_OK_STRICT. I propose
> to change GO_IF_LEGITIMATE_ADDRESS, GO_IF_MODE_DEPENDENT_ADDRESS,
> LEGITIMIZE_ADDRESS, LEGITIMIZE_RELOAD_ADDRE
On Mon, Feb 28, 2005 at 09:24:20AM -0500, Robert Dewar wrote:
> Not quite, Marc is suggesting that -pedantic be the default if I read
> the above statement correctly.
Yep.
Except it's probably too late for that, and there is stuff in -pedantic
that is downright obnoxious (because every C compiler
I usually just lurk.
In other contexts, I've sometimes done informally ombudsish stuff.
This seems to me that it is important enough and intractable enough to
deserve a switch. This would be information to the compiler that this
code either does or does not have a lot of templating and such. High
Hi Zack,
> So, the plan: Step 1 introduces - one at a time - target hooks
> corresponding to each of the above macros. All callers are changed to
> use the hooks. The default definitions of the hooks invoke the
> existing macros. The hardest part of this is working out exactly what
> their sole
On Mon, 28 Feb 2005, Dave Korn wrote:
> Hmmm, actually, I would say that moving these macro definitions into the
> cpu.c files is a fairly mechanical and trivial transformation. Given:
WRONG!
> ${CPU}.h:
> #define GO_IF_LEGITIMATE_ADDRESS(MODE,X,ADDR) \
> if ( some very hairy conditiona
Giovanni Bajo wrote:
Marc Espie <[EMAIL PROTECTED]> wrote:
Personally, I would even say that it would be *great* if gcc would
start warning if you use any extension, unless you explicitly disable
those warnings... (except for __extension__ in header files, and then
I've stumbled upon situations wh
Original Message
>From: gcc-owner On Behalf Of Zack Weinberg
>Sent: 28 February 2005 02:57
> 1) These are the macros subject to REG_OK_STRICT.
[ ... snip! ... ]
>Also, any macro which uses any of the above macros is perforce
>affected.
>
> 2) Several of these macr
Original Message
>From: gcc-owner On Behalf Of David Edelsohn
>Sent: 27 February 2005 23:35
>> So what is the proper way or set of options for me to:
>
>> 1) optionally have POWER4 optimisations (that must be independant on the
>> rest below) 2) be able to use altivec instructions in ass
On Feb 28, 2005 02:35 PM, Canqun Yang <[EMAIL PROTECTED]> wrote:
> Hi, all
>
> The new loop unroller causes performance degradation
> due to the unimplemented giv (general induction
> variable) optimizations.
>
> When will it be implemented?
Will you be more specific so we can have a clue w
Hi, all
The new loop unroller causes performance degradation
due to the unimplemented giv (general induction
variable) optimizations.
When will it be implemented?
Canqun Yang
Creative Compiler Research Group.
National University of Defense Technology, China.
On Mon, Feb 28, 2005 at 12:43:35PM +, Joern RENNECKE wrote:
> Well, even then, using of the cold section can increase the hot section
> size, depending on target, and for some
> targets the maximum supported distance of the cold section.
>
> For SH, using the cold section, you get (for non-PI
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 use few or none of them.
Here's a small snippet from "base3d.cpp" fil
Dale Johannesen wrote:
Well, no, what is supposed to happen (I haven't tried it for a while,
so I don't promise
this still works) is code like this:
.hotsection:
loop:
conditional branch (i?==1000) to L2
L1:
/* do stuff */
end loop:
/* still in hot section */
L2: jmp L3
.coldsection:
L3
In article <[EMAIL PROTECTED]> you write:
>People do break Ada bootstrap because they don't configure and test Ada,
>they don't configure Ada because they complained about Ada build
>machinery being non standard, delaying Ada build machinery changes will
>only make things worse for Ada bootstrap s
On Sun, 2005-02-27 at 14:57 -0800, Mark Mitchell wrote:
> Nathanael Nerode wrote:
> > Although you have listed it as "stage 2", I wish to commit the finished
> > portion as soon as possible during stage 1. I have maintainership authority
> > to do so. This will not interfere in any way with *any*
Zack Weinberg wrote:
I have worked out a tentative plan for replacing most of these macros
with ordinary target hooks, and eliminating REG_OK_STRICT. I propose
to change GO_IF_LEGITIMATE_ADDRESS, GO_IF_MODE_DEPENDENT_ADDRESS,
LEGITIMIZE_ADDRESS, LEGITIMIZE_RELOAD_ADDRESS, REG_OK_FOR_BASE_P,
REG_MO
Now that the 4.0 Branch has been created and ObjC++ is still not in GCC
(since Zem Laski seems to be to busy with other things currently and
obviously nobody else is able to pick up the loose ends and do the merge)
I'd like to know what the 'official' position regarding ObjC++ is now.
I did not
Mike Hearn <[EMAIL PROTECTED]> wrote:
> As recent releases have broken more and more code, I would like to
> understand what GCCs policy on source compatibility is. Sometimes the
> code was buggy, in this particular case GCC simply decided to pull an
> extension it has offered for years. Is it doc
Marc Espie <[EMAIL PROTECTED]> wrote:
> Personally, I would even say that it would be *great* if gcc would
> start warning if you use any extension, unless you explicitly disable
> those warnings... (except for __extension__ in header files, and then
> I've stumbled upon situations where it hurts
> I can only wonder why we are having this discussion just after GCC 4.0
> was branched, while it was obvious already two years ago that inlining
> heuristics were going to be a difficult item with tree-ssa.
There were of course complaints and discussions about this, and I even
tried to tweak inli
Rehi
> It's been done a couple of times already, first by me, and later my
> code was extended by a couple of other people. Don't know if you want
> to start from scratch "on principle" though, otherwise search the mail
> archives.
Just forget about the thesis. Tell me where to get that patch/co
On 27 Feb 2005, Gabriel Dos Reis wrote:
> Mark Mitchell <[EMAIL PROTECTED]> writes:
>
> | 5. However, it really might be sensible to have the C++ front end
> | treat "inline" as a command, rather than a hint, by default. It might
>
> For "simple enough" functions. Here, by "simple enough" functi
Daniel Jacobowitz wrote:
On Sun, Feb 27, 2005 at 03:56:26PM -0800, Mark Mitchell wrote:
Daniel Jacobowitz wrote:
On Sun, Feb 27, 2005 at 02:57:05PM -0800, Mark Mitchell wrote:
Nathanael said it did not interfere with any of the other _projects_,
not that it would be disjoint from all Stage 1 _patc
Daniel Jacobowitz wrote:
On Sun, Feb 27, 2005 at 03:56:26PM -0800, Mark Mitchell wrote:
Daniel Jacobowitz wrote:
On Sun, Feb 27, 2005 at 02:57:05PM -0800, Mark Mitchell wrote:
Nathanael said it did not interfere with any of the other _projects_,
not that it would be disjoint from all Stage 1 _patc
82 matches
Mail list logo
