Re: current 4.0 branch doesn't compile
On Sunday 14 August 2005 01:39, Tommy Vercetti wrote: > /home/gj/Projects/gcc/build/gcc/xgcc -B/home/gj/Projects/gcc/build/gcc/ > -B/usr/local/gcc4.0/i686-pc-linux-gnu/bin/ > -B/usr/local/gcc4.0/i686-pc-linux-gnu/lib/ > -isystem /usr/local/gcc4.0/i686-pc-linux-gnu/include > -isystem /usr/local/gcc4.0/i686-pc-linux-gnu/sys-include -O2 -DIN_GCC-W > -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes > -Wold-style-definition -isystem ./include -I. -I. -I../../gcc/gcc > -I../../gcc/gcc/. -I../../gcc/gcc/../include > -I../../gcc/gcc/../libcpp/include -g0 -finhibit-size-directive > -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss > -fno-unit-at-a-time -fno-omit-frame-pointer \ >-c ../../gcc/gcc/crtstuff.c -DCRT_BEGIN \ > -o crtbegin.o > In file included from ../../gcc/gcc/tsystem.h:104, > from ../../gcc/gcc/crtstuff.c:64: > /usr/include/stdlib.h:395: internal compiler error: in > cgraph_mark_inline_edge, at cgraphunit.c:1129 > Please submit a full bug report, > with preprocessed source if appropriate. > > Any one interested in more details, or is it enough information ? removal of build dir, and redoing everything from scratch, helped. -- Vercetti
Re: [GCC 4.2 Project] Omega data dependence test
Daniel Berlin wrote: > > Sebastian, I really think you are worrying too much. right. > It's pretty rare that it will take going all the way to omega to be able > to disambiguate two dependences. > for dependence tests we exercise only a limited part of omega, but now suppose that we'll use omega for other purposes, for example cache miss equations, scheduling, regalloc, etc. One of these users will sooner or later end by triggering the exponential bullet.
Re: Question on updating ssa for virtual operands (PR tree-optimization/22543)
Daniel Berlin <[EMAIL PROTECTED]> wrote on 12/08/2005 17:56:11: > > comments/ideas? > > I would start by figuring out why update_ssa + rewrite_into_loop_closed > isn't putting SFT.3 into loop closed ssa form. > > Even if we do put virtual vars back into loop closed, that's still a > bug. > I found the problem - apparently there's a call to delete_update_ssa() between the point where I mark the vars for renaming and the point where update_ssa() is called... I'm now just recording the vars I want to rename in a bitmap and mark them for renaming later on, just before the call to update_ssa(), and indeed update_ssa() does the job and the failure is resolved. thanks, dorit > > > > thanks, > > dorit > > >
Re: [SUMMARY] Old machine cluster for GCC compile/testing
Here is the initial wiki page for the CompileFarm project: http://gcc.gnu.org/wiki/CompileFarm Feel free to add detailed proposals there. Laurent On Fri, 2005-08-12 at 13:01 +0200, Laurent GUERBY wrote: > Thanks to all who proposed projects and volunteered, I've informed FSF > France that the project has enough volunteers to move ahead. > > I'll write a summary in the GCC wiki this week-end, feel free > to add more projects then. [...]
What systems (if any) have fprintf_unlocked?
Hmm I'm curious, what systems (if any) have fprintf_unlocked? The first mention of it that I see is where Zack added the machinery to detect it here: http://gcc.gnu.org/ml/gcc-patches/2001-09/msg01174.html >From the way he writes it was an afterthought, and not the main purpose of his patch. But I don't see fprintf_unlocked on my linux-gnu box nor does it appear in e.g. glibc-2.3.4. Any ideas? Thanks, --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
Re: [GCC 4.2 Project] Omega data dependence test
On Sun, 2005-08-14 at 13:14 +0200, Sebastian Pop wrote: > Daniel Berlin wrote: > > > > Sebastian, I really think you are worrying too much. > > right. > > > It's pretty rare that it will take going all the way to omega to be able > > to disambiguate two dependences. > > > > for dependence tests we exercise only a limited part of omega, but now > suppose that we'll use omega for other purposes, for example cache > miss equations, Most cache miss equations are using distance numbers, which we don't always need to go all the way to omega to get. > scheduling, Dependence again :) > regalloc, Dependence again :) > etc. One of these users will > sooner or later end by triggering the exponential bullet. Only if you use such a big hammer for every small nail :)
Re: Question of the suitable time to call `free_bb_for_insn()'
I'm sorry that I didn't trace the cfgrtl.c before I posting the question. Now I see that I can get the info again by calling compute_bb_for_insn(). On Sun, 14 Aug 2005 09:15:49 +0800, Ling-hua Tseng wrote > I'm porting the GCC 4.0.2 (2005-08-11 snapshot) to a new VLIW architecture. > > I figured out the `free_bb_for_insn()' is called before the reorg > pass, and I would like to use the CFG in the reorg pass for a reason. > > The reason is: > I would like to change flag_schedule_insns_after_reload to 0 by > the macro OVERRIDE_OPTIONS if it was set,and then I would like > to call the sched2 pass in some location of the hook TARGET_MACHINE_DEPENDENT_REORG. > Perhaps I will manually do some instruction scheduling in the > reorg pass in the future. > > So I have two questions: > > 1. Is it safe to move the line `free_bb_for_insn ();' to the > next line of `rest_of_handle_machine_reorg ();' ? > 2. If it is safe, would the GCC team like to move it to there > for allowing other ones can use CFG infoin the reorg pass? > > By the way, I noticed that the ia64 port did something which is > similar to mine. But it do some effort for recoding something before > the reorg pass. Moreover, it's forced to call the `schedule_ebbs()' > however(I'd like to call `schedule_insns()'). > > Thanks a lot.
Re: Inlining vs the stack
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, Aug 12, 2005 at 02:16:39PM -0700, Ian Lance Taylor wrote:
> Mike Stump <[EMAIL PROTECTED]> writes:
> > X can be run time selectable, OMF selectable, OS defined...
>
> No.
>
> Making the stack bigger by inlining is no different from making it
> bigger by declaring and using more local variables or calls to alloca.
void killme(void)
{
int x[100]; /* Let's kill 64-bitters too. */
int i;
for (i = 0; i < sizeof (x) / sizeof (x[0]); i++) {
printf("%d\n", x[i]);
}
}
volatile int keep_going = 1;
void forever(void)
{
while (keep_going) {
/* Pretend this is a loop in FreeCiv. */
ai_move_units();
next_turn();
}
killme();
}
You'd expect the attempt to grow the stack to be made only *after*
keep_going hits zero. I'd rather not have the compiler presume
certainty of a 10GB stack allocation, especially not if it's actually
pretty unlikely.
- --
"If you lie to the compiler, it will get its revenge." - Henry Spencer
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFC/2rj/FmLrNfLpjMRAioFAJ9M/i9LXiofpXBi0pPV1SU8yk6eJgCeL/Uo
noiQWoWPZXHHHQBrriG6kd4=
=Bmte
-END PGP SIGNATURE-
Re: Inlining vs the stack
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Fri, Aug 12, 2005 at 02:16:39PM -0700, Ian Lance Taylor wrote:
> > Mike Stump <[EMAIL PROTECTED]> writes:
> > > X can be run time selectable, OMF selectable, OS defined...
> >
> > No.
> >
> > Making the stack bigger by inlining is no different from making it
> > bigger by declaring and using more local variables or calls to alloca.
>
> void killme(void)
> {
> int x[100]; /* Let's kill 64-bitters too. */
> int i;
> for (i = 0; i < sizeof (x) / sizeof (x[0]); i++) {
> printf("%d\n", x[i]);
> }
> }
It would be better if you used abort instead which will kill the problem
in easier/better way.
-- Pinski
Re: Inlining vs the stack
> You'd expect the attempt to grow the stack to be made only *after* > keep_going hits zero. Only if you thought you knew better than the compiler :) > I'd rather not have the compiler presume > certainty of a 10GB stack allocation, especially not if it's actually > pretty unlikely. It could still be done, even if we inline. There is nothing that prevents us from adding space to the stack allocation only at that point, it's just not coded in gcc to do that.
Re: Problems with bootstrapping 4.0.1
It appears that the gcc included with Fedora Core 4 (or some other program that may be used during gcc bootstrap) does not produce identical output on stages 2 and 3. I ran "make bootstrap4", and the comparison check passed after building stage 4. Any one with Fedora Core 4 will have to run "make bootstrap4" to successfully bootstrap gcc-4.0.x - that's what I noticed. - KJM On Sat, 2005-08-13 at 17:11 -0700, James E Wilson wrote: > Kevin McBride wrote: > > I have been having comparison errors while building a native 4.0.1 > > compiler for my Fedora Core 4 system. > > Running >cmp c-pragma.o stage2/c-pragma.o > on your provided files says that they identical. If you are getting > comparison failures on these files, then perhaps your "cmp" program is > broken. Or perhaps you included the wrong files to look at. > > Your makefile output is a little odd, as you give the compile line for > c-pragma.o first, and then the compile lines for c-parse.o. Probably a > simple cut and paste error. This is probably not relevant anyways. It > is highly unlikely that there is a problem with the gcc command line > args during stage2 or stage3.
Re: What systems (if any) have fprintf_unlocked?
Kaveh R. Ghazi said: > Hmm I'm curious, what systems (if any) have fprintf_unlocked? At the time I thought glibc had it, but I don't see it on my (2.3.5) system now. baffled, zw
