Re: Massive SPEC failures on trunk
FYI Bug has been already reported http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31037 -Vladimir
Re: new auto-inc-dec pass
In http://gcc.gnu.org/ml/gcc/2007-03/msg00128.html, you wrote: > One case is about multiple increments, the tree optimizer merges them and > increments the register only once, so if one only looks at the size of the > pointer value one misses them, e.g. something like this: > > (set (mem (reg)) (x)) > (set (mem (plus (reg) (const_int 4))) (x)) > (set (reg) (plus (reg) (const_int 8)) The patches attached to PR20211 handle this case.
Re: Is "FTZ/DAZ for SSE via fast math" available for x86 arch other than Linux?
Hello, "Zuxy Meng" <[EMAIL PROTECTED]> дÈëÏûÏ¢ÐÂÎÅ:[EMAIL PROTECTED] >I saw the patch in http://gcc.gnu.org/ml/gcc/2005-08/msg00281.html but is >it > available for other hosts, like mingw32? I've uploaded a proposed patch for this bug (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13151&action=diff). Putting crtfastmath.o in the endfile section of specs causes undefined reference to memset, so I moved it to the startfile section. Anyone to review this? Quite trivial anyway. -- Zuxy
Re: subreg pass
Hi,
On Mon, 5 Mar 2007, Roman Zippel wrote:
> > Yes, it is in general better now to split double-word length
> > operations before reload. It's not necessarily better to split as
> > early as possible, as that will essentially disable the RTL level loop
> > optimizations.
>
> I was worried about that too, since some patterns would be more
> complicated, which may make some optimizations more difficult, e.g. where
> I noticed it first was mulsidi3, which currently looks like this:
Ok, I played a little more with umulsidi3 (see attached patch, only the
umulsidi3 pattern are relevant for this) and I think found a bug somwhere,
although I'm not sure whether the subreg pass causes it or only trigggers
it (it goes away with -fno-split-wide-types).
I removed the '%' from the constraint to test proper reloads (which may
not be here, but probably in other cases) and used the following testcase:
unsigned long long f(void)
{
register unsigned int a asm ("%d0");
register unsigned int b asm ("%d1");
asm ("# %0 %1" : "=d" (a), "=d" (b));
return ((unsigned long long)b * (unsigned long long)a);
}
This is the situation prior to subreg2:
(insn 32 10 30 2 (parallel [
(set (strict_low_part (subreg:SI (reg:DI 33) 4))
(mult:SI (reg/v:SI 0 %d0 [ a ])
(reg/v:SI 1 %d1 [ b ])))
(set (strict_low_part (subreg:SI (reg:DI 33) 0))
(truncate:SI (lshiftrt:DI (mult:DI (zero_extend:DI (reg/v:SI 0
%d0 [ a ]))
(zero_extend:DI (reg/v:SI 1 %d1 [ b ])))
(const_int 32 [0x20]
]) -1 (nil)
(expr_list:REG_DEAD (reg/v:SI 0 %d0 [ a ])
(expr_list:REG_DEAD (reg/v:SI 1 %d1 [ b ])
(nil
(insn 30 32 31 2 (set (reg:SI 0 %d0 [ ])
(subreg:SI (reg:DI 33) 0)) 31 {*m68k.md:673} (insn_list:REG_DEP_TRUE 11
(nil))
(nil))
(insn 31 30 23 2 (set (reg:SI 1 %d1 [orig:0 +4 ] [0])
(subreg:SI (reg:DI 33) 4)) 31 {*m68k.md:673} (nil)
(expr_list:REG_DEAD (reg:DI 33)
(nil)))
(insn 23 31 0 2 (use (reg/i:DI 0 %d0 [ ])) -1 (insn_list:REG_DEP_TRUE
30 (nil))
(nil))
subreg2 produces this (which looks correct):
(insn 32 10 30 2 (parallel [
(set (strict_low_part (reg:SI 38 [+4 ]))
(mult:SI (reg/v:SI 0 %d0 [ a ])
(reg/v:SI 1 %d1 [ b ])))
(set (strict_low_part (reg:SI 37))
(truncate:SI (lshiftrt:DI (mult:DI (zero_extend:DI (reg/v:SI 0
%d0 [ a ]))
(zero_extend:DI (reg/v:SI 1 %d1 [ b ])))
(const_int 32 [0x20]
]) 181 {*umulsidi3_subreg} (nil)
(expr_list:REG_DEAD (reg/v:SI 0 %d0 [ a ])
(expr_list:REG_DEAD (reg/v:SI 1 %d1 [ b ])
(nil
(insn 30 32 31 2 (set (reg:SI 0 %d0 [ ])
(reg:SI 37)) 31 {*m68k.md:673} (insn_list:REG_DEP_TRUE 11 (nil))
(expr_list:REG_DEAD (reg:SI 37)
(nil)))
(insn 31 30 23 2 (set (reg:SI 1 %d1 [orig:0 +4 ] [0])
(reg:SI 38 [+4 ])) 31 {*m68k.md:673} (nil)
(expr_list:REG_DEAD (reg:SI 38 [+4 ])
(nil)))
(insn 23 31 0 2 (use (reg/i:DI 0 %d0 [ ])) -1 (insn_list:REG_DEP_TRUE
30 (nil))
(nil))
Reload has now to match (reg %d0) and (reg 38) above in insn 32 and after
pseudo register replacement it looks like this:
(insn 32 10 30 2 (parallel [
(set (strict_low_part (reg:SI 1 %d1 [orig:38+4 ] [38]))
(mult:SI (reg/v:SI 0 %d0 [ a ])
(reg/v:SI 1 %d1 [ b ])))
(set (strict_low_part (reg:SI 0 %d0 [37]))
(truncate:SI (lshiftrt:DI (mult:DI (zero_extend:DI (reg/v:SI 0
%d0 [ a ]))
(zero_extend:DI (reg/v:SI 1 %d1 [ b ])))
(const_int 32 [0x20]
]) 181 {*umulsidi3_subreg} (nil)
(expr_list:REG_DEAD (reg/v:SI 0 %d0 [ a ])
(expr_list:REG_DEAD (reg/v:SI 1 %d1 [ b ])
(nil
Notice that the REG_DEAD notes are not correct anymore, reload produces
now the following reload:
Reloads for insn # 32
Reload 0: reload_in (SI) = (reg/v:SI 0 %d0 [ a ])
reload_out (SI) = (reg:SI 1 %d1 [orig:38+4 ] [38])
DATA_REGS, RELOAD_OTHER (opnum = 0)
reload_in_reg: (reg/v:SI 0 %d0 [ a ])
reload_out_reg: (reg:SI 1 %d1 [orig:38+4 ] [38])
reload_reg_rtx: (reg/v:SI 0 %d0 [ a ])
The problem here is it can't use %d0 as reload register (but it does it
anyway, because it thinks it's dead), as it's used for (reg 37) and reload
produces this:
(insn 32 10 34 2 (parallel [
(set (strict_low_part (reg/v:SI 0 %d0 [ a ]))
(mult:SI (reg/v:SI 0 %d0 [ a ])
(reg/v:SI 1 %d1 [ b ])))
(set (strict_low_part (reg:SI 0 %d0 [37]))
(truncate:SI (lshiftrt:DI (mult:DI (zero_extend:DI (reg/v:SI 0
%d0 [ a ]))
(zero_extend:DI (reg/v:SI 1 %d1 [ b ])))
Re: new auto-inc-dec pass
Hi, On Tue, 6 Mar 2007, Joern Rennecke wrote: > In http://gcc.gnu.org/ml/gcc/2007-03/msg00128.html, you wrote: > > One case is about multiple increments, the tree optimizer merges them and > > increments the register only once, so if one only looks at the size of the > > pointer value one misses them, e.g. something like this: > > > > (set (mem (reg)) (x)) > > (set (mem (plus (reg) (const_int 4))) (x)) > > (set (reg) (plus (reg) (const_int 8)) > > The patches attached to PR20211 handle this case. Hmm, it seems to do a bit more. I have to agree with the last comment insofar, that regmove.c is probably not the best place for this. Most of the auto-inc-dec business should be done before combine. bye, Roman
Re: subreg pass
On Tue, 6 Mar 2007, Roman Zippel wrote:
> Reload has now to match (reg %d0) and (reg 38) above in insn 32 and after
> pseudo register replacement it looks like this:
>
> (insn 32 10 30 2 (parallel [
> (set (strict_low_part (reg:SI 1 %d1 [orig:38+4 ] [38]))
> (mult:SI (reg/v:SI 0 %d0 [ a ])
> (reg/v:SI 1 %d1 [ b ])))
> (set (strict_low_part (reg:SI 0 %d0 [37]))
> (truncate:SI (lshiftrt:DI (mult:DI (zero_extend:DI (reg/v:SI
> 0 %d0 [ a ]))
> (zero_extend:DI (reg/v:SI 1 %d1 [ b ])))
> (const_int 32 [0x20]
> ]) 181 {*umulsidi3_subreg} (nil)
> (expr_list:REG_DEAD (reg/v:SI 0 %d0 [ a ])
> (expr_list:REG_DEAD (reg/v:SI 1 %d1 [ b ])
> (nil
>
> Notice that the REG_DEAD notes are not correct anymore,
>
[..]
>
> %d0 is used in both set destinations and postreload dies because of it.
> The question is now, who is responsible for telling reload that %d0/%d1
> are not really dead anymore after register allocation?
Below is possible approach, I hijacked mark_not_eliminable to scan all
register stores and remove the obsolete REG_DEAD notes. With this reload
produces the correct reload.
bye, Roman
Index: gcc/reload1.c
===
--- gcc/reload1.c (revision 122519)
+++ gcc/reload1.c (working copy)
@@ -842,7 +842,7 @@
cannot be done. */
for (insn = first; insn && num_eliminable; insn = NEXT_INSN (insn))
if (INSN_P (insn))
- note_stores (PATTERN (insn), mark_not_eliminable, NULL);
+ note_stores (PATTERN (insn), mark_not_eliminable, insn);
maybe_fix_stack_asms ();
@@ -3398,8 +3398,9 @@
the insns of the function. */
static void
-mark_not_eliminable (rtx dest, rtx x, void *data ATTRIBUTE_UNUSED)
+mark_not_eliminable (rtx dest, rtx x, void *data)
{
+ rtx note, insn = data;
unsigned int i;
/* A SUBREG of a hard register here is just changing its mode. We should
@@ -3408,6 +3409,9 @@
if (GET_CODE (dest) == SUBREG)
dest = SUBREG_REG (dest);
+ if (REG_P (dest) && (note = find_regno_note (insn, REG_DEAD, REGNO (dest
+remove_note (insn, note);
+
if (dest == hard_frame_pointer_rtx)
return;
Re: subreg pass
Roman Zippel <[EMAIL PROTECTED]> writes: > The new subreg lowering pass seems to generate a bit worse code on m68k > than before, let's take simple example: FWIW I see the opposite on i386: I have a function that strangely ran slower with -fomit-frame-pointer than without on 4.1. With a 4.3 snapshot -fomit-frame-pointer is faster as expected. -Andi
Mainline bug in RTL fwprop.
I was working on a a patch for PR 21596, and it seems to have triggered
a bug in fwprop on x86 in mainline.
The testcase is simple:
register int *reg __asm__("%edi");
int test () { return *--reg <= 0; }
I've attached the patch for TER which changes the tree produced in
mainline from:
reg.0 = reg;
reg.27 = reg.0 - 4B;
reg = reg.27;
return *reg.27 <= 0;
to
reg.27 = reg - 4B;
reg = reg.27;
return *reg.27 <= 0;
which eliminates one extraneous copy.
Going into fwprop1, the rtl looks like:
(insn 7 5 8 2 (parallel [
(set (reg:SI 58 [ reg.27 ])
(plus:SI (reg/v:SI 5 di [ reg ])
(const_int -4 [0xfffc])))
(clobber (reg:CC 17 flags))
]) 148 {*addsi_1} (nil)
(nil))
(insn 8 7 9 2 (set (reg/v:SI 5 di [ reg ])
(reg:SI 58 [ reg.27 ])) 34 {*movsi_1} (nil)
(nil))
(insn 9 8 10 2 (set (reg:CCNO 17 flags)
(compare:CCNO (mem:SI (reg:SI 58 [ reg.27 ]) [3 S4 A32])
(const_int 0 [0x0]))) 0 {*cmpsi_ccno_1} (nil)
(nil))
and fwprop decides to propagate:
(compare:CCNO (mem:SI (reg:SI 58 [ reg.27 ]) [3 S4 A32])
(const_int 0 [0x0]))
with (compare:CCNO (mem:SI (plus:SI (reg/v:SI 5 di [ reg ])
(const_int -4 [0xfffc])) [3 S4 A32])
(const_int 0 [0x0]))
resulting in:
(insn 7 5 8 2 (parallel [
(set (reg:SI 58 [ reg.27 ])
(plus:SI (reg/v:SI 5 di [ reg ])
(const_int -4 [0xfffc])))
(clobber (reg:CC 17 flags))
]) 148 {*addsi_1} (nil)
(nil))
(insn 8 7 9 2 (set (reg/v:SI 5 di [ reg ])
(reg:SI 58 [ reg.27 ])) 34 {*movsi_1} (nil)
(nil))
(insn 9 8 10 2 (set (reg:CCNO 17 flags)
(compare:CCNO (mem:SI (plus:SI (reg/v:SI 5 di [ reg ])
(const_int -4 [0xfffc])) [3 S4 A32])
(const_int 0 [0x0]))) 0 {*cmpsi_ccno_1} (nil)
(nil))
note that it has propagated 'di - 4' past insn 8 which sets di to di
-4.
The compare in insn 9 is now comparing an additional -4 offset to di,
which is wrong.
It would be really sweet if we propagated the 'di - 4' into insn 8, then
recognized that di is now the value of SI 58, and propagated di into the
compare. insn 7 would be dead and we'd get the code the PR is looking
for :-)
Andrew
2007-03-05 Andrew MacLeod <[EMAIL PROTECTED]>
* tree-ssa-ter.c (find_replaceable_in_bb): Allow expression replacement
of same basename variables for stmts with a single ssa_name use.
Index: tree-ssa-ter.c
===
*** tree-ssa-ter.c (revision 122131)
--- tree-ssa-ter.c (working copy)
*** find_replaceable_in_bb (temp_expr_table_
*** 555,565
--- 555,567
var_map map = tab->map;
ssa_op_iter iter;
bool stmt_replaceable;
+ bool single_use_stmt;
for (bsi = bsi_start (bb); !bsi_end_p (bsi); bsi_next (&bsi))
{
stmt = bsi_stmt (bsi);
ann = stmt_ann (stmt);
+ single_use_stmt = SINGLE_SSA_TREE_OPERAND (stmt, SSA_OP_USE) != NULL_TREE;
stmt_replaceable = is_replaceable_p (stmt);
/* Determine if this stmt finishes an existing expression. */
*** find_replaceable_in_bb (temp_expr_table_
*** 577,583
/* See if the root variables are the same. If they are, we
do not want to do the replacement to avoid problems with
code size, see PR tree-optimization/17549. */
! if (!bitmap_empty_p (vars))
FOR_EACH_SSA_TREE_OPERAND (def, stmt, iter2, SSA_OP_DEF)
{
if (bitmap_bit_p (vars, DECL_UID (SSA_NAME_VAR (def
--- 579,590
/* See if the root variables are the same. If they are, we
do not want to do the replacement to avoid problems with
code size, see PR tree-optimization/17549. */
!
! /* If this stmt is not accumulating more than one variable (ie,
! it has a single use), then an exponential growth rate is not
! possible. This makes it safe to allow TER to proceed. See
! PR tree-optimization/21596. */
! if (!bitmap_empty_p (vars) && !single_use_stmt)
FOR_EACH_SSA_TREE_OPERAND (def, stmt, iter2, SSA_OP_DEF)
{
if (bitmap_bit_p (vars, DECL_UID (SSA_NAME_VAR (def
Adding a new gcc dir
Hi all, I've just added a new gcc subdir : head/gcc/myproj with structures and utilities for my ipa pass which lives in head/gcc. Now I have to tell gcc to compile the files inside myproj. Is there a standard way to do this? I've looked into head/gcc/Makefile.in but it seem quite cluttered and I don't really know where to begin since the gcc build is quite complex. Any suggestions? (Probably I can have my Makefile.in in myproj dir) but then where should I tell gcc to compile them) Regards, -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK
Re: Massive SPEC failures on trunk
"Vladimir Sysoev" <[EMAIL PROTECTED]> writes: > Bug has been already reported > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31037 I don't think this one could have anything to do with my VRP changes, but I'll try to take a look later today. Ian
Re: Massive SPEC failures on trunk
Ian Lance Taylor wrote on 03/06/07 09:49: > "Vladimir Sysoev" <[EMAIL PROTECTED]> writes: > >> Bug has been already reported >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31037 > > I don't think this one could have anything to do with my VRP changes, > but I'll try to take a look later today. > Actually, this looks more related to my aliasing patch. I'll be dealing with this one soon.
BUG: wrong function call
Hi, I use multiple inheritance in my project. In the child class i have functions GetParam() and SetParam(). In the cpp-file I call GetParam() function, but I fell to SetParam() function. Can You help me?
Re: BUG: wrong function call
On 3/6/07, W. Ivanov <[EMAIL PROTECTED]> wrote: Hi, I use multiple inheritance in my project. In the child class i have functions GetParam() and SetParam(). In the cpp-file I call GetParam() function, but I fell to SetParam() function. Can You help me? Don't take me wrong but it is most likely a bug in your code. Still, you might want to inform the developers (not me) through this mailing list which code you're compiling and which version of gcc you're using. Cheers, -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK
Re: Adding a new gcc dir
On 3/6/07, Paulo J. Matos <[EMAIL PROTECTED]> wrote: Hi all, I've just added a new gcc subdir : head/gcc/myproj with structures and utilities for my ipa pass which lives in head/gcc. Now I have to tell gcc to compile the files inside myproj. Is there a standard way to do this? I've looked into head/gcc/Makefile.in but it seem quite cluttered and I don't really know where to begin since the gcc build is quite complex. Any suggestions? (Probably I can have my Makefile.in in myproj dir) but then where should I tell gcc to compile them) Well, added a couple of lines to gcc/Makefile.in referring to files in myproj. Still, although it is partly working one thing is annoying me. It's using these flags by default: -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -Wmissing-format-attribute Which means using C90, which means no mixed declarations and code, no C++ comments, etc. Is there any way to compile at least, my files with c99 constructs? Or all gcc code should be built like this?? Regards, Paulo Matos Regards, -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK
Doxygen documentation nearly unreadable
Hi, I try from time to time to find some information related GNU's C++ STL implemention e.g. in http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/classstd_1_1basic__string.html But this page (and others) are nearly unreadable because there is no way to recognise member function declarations such as template basic_string< _CharT, _Traits, _Alloc > & std::basic_string< _CharT, _Traits, _Alloc >::assign because of missing contrast. The default doxygen styles use a color box around such declarations but this is not true for your documentation! This makes this pages really unreadable. Please fix it. (I first thought it's a browser problem with CSS or something similar but it looks equally ugly in konqueror and firefox). Jens
Re: BUG: wrong function call
Paulo J. Matos wrote: On 3/6/07, W. Ivanov <[EMAIL PROTECTED]> wrote: Hi, I use multiple inheritance in my project. In the child class i have functions GetParam() and SetParam(). In the cpp-file I call GetParam() function, but I fell to SetParam() function. Can You help me? Don't take me wrong but it is most likely a bug in your code. Still, you might want to inform the developers (not me) through this mailing list which code you're compiling and which version of gcc you're using. Cheers, Please, give me a mail address of developers.
RE: Adding a new gcc dir
On 06 March 2007 16:07, Paulo J. Matos wrote: > Well, added a couple of lines to gcc/Makefile.in referring to files in > myproj. Still, although it is partly working one thing is annoying me. > It's using these flags by default: > -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes > -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition > -Wmissing-format-attribute > > Which means using C90, which means no mixed declarations and code, no > C++ comments, etc. Is there any way to compile at least, my files with > c99 constructs? Take a look at the section of gcc/Makefile.in beginning "# Various ways of specifying flags for compilations:" and go from there. > Or all gcc code should be built like this?? Well, for your own personal purposes, you can do whatever you like, but it is part of the coding standard that all gcc code should be bog-standard C90, so that it is possible for end-users to build gcc on any machine, even a very old one with a very old compiler. cheers, DaveK -- Can't think of a witty .sigline today
Re: Adding a new gcc dir
> Which means using C90, which means no mixed declarations and code, no > C++ comments, etc. Is there any way to compile at least, my files with > c99 constructs? > Or all gcc code should be built like this?? This is a feature. gcc can be bootstrapped using an arbitrary c90 compiler. The warning options you mentioned help to enforce this. Paul
Re: BUG: wrong function call
On 3/6/07, W. Ivanov <[EMAIL PROTECTED]> wrote: Paulo J. Matos wrote: > On 3/6/07, W. Ivanov <[EMAIL PROTECTED]> wrote: >> Hi, I use multiple inheritance in my project. In the child class i have >> functions GetParam() and SetParam(). >> In the cpp-file I call GetParam() function, but I fell to SetParam() >> function. >> Can You help me? >> > > Don't take me wrong but it is most likely a bug in your code. Still, > you might want to inform the developers (not me) through this mailing > list which code you're compiling and which version of gcc you're > using. > > Cheers, > Please, give me a mail address of developers. You're already reaching pretty much all of them through this mailing list. Gr. Steven
Re: BUG: wrong function call
On 06/03/07, W. Ivanov <[EMAIL PROTECTED]> wrote: Paulo J. Matos wrote: > On 3/6/07, W. Ivanov <[EMAIL PROTECTED]> wrote: >> Hi, I use multiple inheritance in my project. In the child class i have >> functions GetParam() and SetParam(). >> In the cpp-file I call GetParam() function, but I fell to SetParam() >> function. >> Can You help me? >> > > Don't take me wrong but it is most likely a bug in your code. Still, > you might want to inform the developers (not me) through this mailing > list which code you're compiling and which version of gcc you're > using. > > Cheers, > Please, give me a mail address of developers. What Paulo surely means is that when reporting a bug you should provide a testcase, the current output, the desired output, the command you used to obtain the output and the result of running gcc --version. That is the minimum for reporting a bug. In this case, since you are not sure whether this is a bug, you should first ask in [EMAIL PROTECTED] since that list is for user issues and this list is for developing GCC. Cheers, Manuel.
Re: Mainline bug in RTL fwprop.
> It would be really sweet if we propagated the 'di - 4' into insn 8, then > recognized that di is now the value of SI 58, and propagated di into the > compare. insn 7 would be dead and we'd get the code the PR is looking > for :-) Unfortunately there's no hope of that because fwprop doesn't do value numbering, but I'll try to look at it because it's a wrong code bug. (It would be great if you had a testcase for mainline...). Paolo
build broken
It appears that one of these: r122580 | doko | 2007-03-05 15:23:18 -0800 (Mon, 05 Mar 2007) | 6 lines 2007-03-02 Mario Torre <[EMAIL PROTECTED]> PR classpath/31017: committed for Petteri R<83>ty <[EMAIL PROTECTED]> * configure.ac: fix broken build for gcj browser plugin r122573 | doko | 2007-03-05 12:24:50 -0800 (Mon, 05 Mar 2007) | 5 lines 2007-03-05 Matthias Klose <[EMAIL PROTECTED]> * doc/Makefile.am(man_MANS): Add $(TOOLS_MANFILES). * doc/Makefile.in: Regenerate. Did this: 2007-03-04T22:54:20Z 2007-03-05T05:50:09Z regress-3 native 122532 2007-03-05T05:53:26Z 2007-03-05T12:49:35Z regress-3 native 122539 2007-03-05T12:52:59Z 2007-03-05T19:53:13Z regress-3 native 122546 2007-03-05T19:56:35Z 2007-03-06T02:53:47Z regress-3 native 122566 2007-03-06T02:57:13Z 2007-03-06T05:18:43Z build native 122594 2007-03-06T07:48:12Z 2007-03-06T10:11:04Z build native 122597 2007-03-06T10:14:03Z 2007-03-06T12:32:47Z build native 122618 2007-03-06T14:18:12Z 2007-03-06T16:37:20Z build native 122619 to the darwin nightly tester. From the log file: perl /Users/regress/tbox/svn-gcc/libjava/classpath/../../contrib/ texi2pod.pl -D gkeytool < /Users/regress/tbox/svn-gcc/libjava/ classpath/doc/cp-tools.texinfo > gkeytool.pod perl /Users/regress/tbox/svn-gcc/libjava/classpath/../../contrib/ texi2pod.pl -D gnative2ascii < /Users/regress/tbox/svn-gcc/libjava/ classpath/doc/cp-tools.texinfo > gnative2ascii.pod perl /Users/regress/tbox/svn-gcc/libjava/classpath/../../contrib/ texi2pod.pl -D gorbd < /Users/regress/tbox/svn-gcc/libjava/classpath/ doc/cp-tools.texinfo > gorbd.pod sed -i -e 's/^For more details.*/See I for more details./' \ -e 's/1\.<\([^>]*\)>/- \1/' \ gkeytool.pod sed: lstat: No such file or directory make[7]: *** [gkeytool.pod] Error 1 make[7]: *** Waiting for unfinished jobs rm gnative2ascii.pod gorbd.pod gjar.pod gappletviewer.pod gkeytool.pod gjavah.pod gjarsigner.pod make[6]: *** [all-recursive] Error 1 make[5]: *** [all-recursive] Error 1 make[4]: *** [all-recursive] Error 1 make[3]: *** [multi-do] Error 1 make[2]: *** [all-multi] Error 2 make[1]: *** [all-target-libjava] Error 2 make: *** [bootstrap] Error 2 + '[' -s .bad_compare ']' + exit 1 I have a feeling sed -i isn't our friend.
Re: Improvements of the haifa scheduler
On 3/5/07, Maxim Kuvyrkov <[EMAIL PROTECTED]> wrote:
Diego Novillo wrote:
> Maxim Kuvyrkov wrote on 03/05/07 02:14:
>
>>o Fix passes that invalidate tree-ssa alias export.
>
> Yes, this should be good and shouldn't need a lot of work.
>
>>o { Fast but unsafe Gupta's aliasing patch, Unsafe tree-ssa alias
>> export } in scheduler's data speculation.
>
> "unsafe" alias export? I would definitely like to see the tree->rtl
> alias information transfer fixed once and for all. Finishing RAS's
> tree->rtl work would probably make a good SoC project.
"Unsafe" doesn't mean not fixed. My thought is that it would be nice to
have a switch in aliasing that will turn such operations as
join (pt_anything, points_to) -> pt_anything
into
join (pt_anything, points_to) -> points_to
This transformation will sacrifice correctness for sake of additional
information.
In 4.3, doesn't exist outside of the confines of tree-ssa-structalias.c
We transform it into a conservatively correct set of variables, rather
than giving up like we used to.
This alone should significantly improve your export results.
Re: Improvements of the haifa scheduler
On 3/6/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
On 3/5/07, Maxim Kuvyrkov <[EMAIL PROTECTED]> wrote:
> Diego Novillo wrote:
> > Maxim Kuvyrkov wrote on 03/05/07 02:14:
> >
> >>o Fix passes that invalidate tree-ssa alias export.
> >
> > Yes, this should be good and shouldn't need a lot of work.
> >
> >>o { Fast but unsafe Gupta's aliasing patch, Unsafe tree-ssa alias
> >> export } in scheduler's data speculation.
> >
> > "unsafe" alias export? I would definitely like to see the tree->rtl
> > alias information transfer fixed once and for all. Finishing RAS's
> > tree->rtl work would probably make a good SoC project.
>
> "Unsafe" doesn't mean not fixed. My thought is that it would be nice to
> have a switch in aliasing that will turn such operations as
>
> join (pt_anything, points_to) -> pt_anything
>
> into
>
> join (pt_anything, points_to) -> points_to
>
> This transformation will sacrifice correctness for sake of additional
> information.
In 4.3, doesn't exist outside of the confines of tree-ssa-structalias.c
^
pt_anything doesn't exist
We transform it into a conservatively correct set of variables, rather
than giving up like we used to.
This alone should significantly improve your export results.
Re: Mainline bug in RTL fwprop.
On Tue, 2007-03-06 at 18:18 +0100, Paolo Bonzini wrote: > > It would be really sweet if we propagated the 'di - 4' into insn 8, then > > recognized that di is now the value of SI 58, and propagated di into the > > compare. insn 7 would be dead and we'd get the code the PR is looking > > for :-) > > Unfortunately there's no hope of that because fwprop doesn't do value > numbering, but I'll try to look at it because it's a wrong code bug. > (It would be great if you had a testcase for mainline...). Apply the small patch to mainline which I attached to the note (it only causes tree-ssa-ter.c to be recompiled), and the provided 2 line testcase causes this situation. I plan to check the patch in, but not until this wrong code bug is resolved. Andrew
Re: reload.c as a bugzilla quip
On 3/5/07, Joe Buck <[EMAIL PROTECTED]> wrote: On Sun, Mar 04, 2007 at 09:45:13AM +0100, FX Coudert wrote: > One of the bugzilla quips (the headlines appearing at random for each > bug list) is actually the head of gcc/reload.c (full text below). That is really obnoxious and should be removed. Gone. Along with the 10 huge quotes of somebody quoting themselves.
Re: reload.c as a bugzilla quip
On Tue, Mar 06, 2007 at 12:50:47PM -0500, Daniel Berlin wrote: > On 3/5/07, Joe Buck <[EMAIL PROTECTED]> wrote: > >On Sun, Mar 04, 2007 at 09:45:13AM +0100, FX Coudert wrote: > >> One of the bugzilla quips (the headlines appearing at random for each > >> bug list) is actually the head of gcc/reload.c (full text below). > > > >That is really obnoxious and should be removed. > > > > Gone. > Along with the 10 huge quotes of somebody quoting themselves. Could you add a length limit? The idea was to have a cute little quip at the top; if it's more than about four lines of text it's a PITA.
Re: Adding a new gcc dir
On 3/6/07, Dave Korn <[EMAIL PROTECTED]> wrote: On 06 March 2007 16:07, Paulo J. Matos wrote: > Well, added a couple of lines to gcc/Makefile.in referring to files in > myproj. Still, although it is partly working one thing is annoying me. > It's using these flags by default: > -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes > -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition > -Wmissing-format-attribute > > Which means using C90, which means no mixed declarations and code, no > C++ comments, etc. Is there any way to compile at least, my files with > c99 constructs? Take a look at the section of gcc/Makefile.in beginning "# Various ways of specifying flags for compilations:" and go from there. > Or all gcc code should be built like this?? Well, for your own personal purposes, you can do whatever you like, but it is part of the coding standard that all gcc code should be bog-standard C90, so that it is possible for end-users to build gcc on any machine, even a very old one with a very old compiler. OK, thank you. I'll adhere to this standard them. :-) cheers, DaveK -- Can't think of a witty .sigline today -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK
Re: Adding a new gcc dir
On 3/6/07, Paulo J. Matos <[EMAIL PROTECTED]> wrote: Hi all, I've just added a new gcc subdir : head/gcc/myproj with structures and utilities for my ipa pass which lives in head/gcc. Now I have to tell gcc to compile the files inside myproj. Is there a standard way to do this? I've looked into head/gcc/Makefile.in but it seem quite cluttered and I don't really know where to begin since the gcc build is quite complex. Any suggestions? (Probably I can have my Makefile.in in myproj dir) but then where should I tell gcc to compile them) Thank you for the issue on C90, which I will adhere to. Still, I cannot compile my files living on a new dir. So, exactly what I did. Under gcc I created a subdir gsvt with files symbol-tables.c, symbol-tables.h and symbol-tables-priv.h. My pass which requires these files to build is with all other passes inside gcc and it is called ipa-gsvt-pass.c. So, I have this in gcc/Makefile.in In OBJS-common I added: ipa-gsvt-pass.o symbol-tables.o Then I created a target for my pass and symbol-tables: ipa-gsvt-pass.o : ipa-gsvt-pass.c ... symbol-tables.o : gsvt/symbol-tables.c gsvt/symbol-tables.h gsvt/symbol-tables-priv.h ../../../acocc/data_structures/trie/trie.o Everything seems to compile perfectly but when linking I get: i686-pc-linux-gnu-ar rc libbackend.a tree-chrec.o tree-scalar-evolution.o tree-data-ref.o tree-cfg.o tree-dfa.o tree-eh.o tree-ssa.o tree-optimize.o tree-gimple.o gimplify.o tree-pretty-print.o tree-into-ssa.o ipa-gsvt-pass.o symbol-tables.o tree-outof-ssa.o tree-ssa-ccp.o tree-vn.o tree-ssa-uncprop.o tree-ssa-dce.o tree-ssa-copy.o tree-nrv.o tree-ssa-copyrename.o tree-ssa-pre.o tree-ssa-live.o tree-ssa-operands.o tree-ssa-alias.o tree-ssa-phiopt.o tree-ssa-forwprop.o tree-nested.o tree-ssa-dse.o tree-ssa-dom.o domwalk.o tree-tailcall.o gimple-low.o tree-iterator.o tree-phinodes.o tree-ssanames.o tree-sra.o tree-complex.o tree-vect-generic.o tree-ssa-loop.o tree-ssa-loop-niter.o tree-ssa-loop-manip.o tree-ssa-threadupdate.o tree-vectorizer.o tree-vect-analyze.o tree-vect-transform.o tree-ssa-loop-ivcanon.o tree-ssa-propagate.o tree-ssa-address.o tree-ssa-math-opts.o tree-ssa-loop-ivopts.o tree-if-conv.o tree-ssa-loop-unswitch.o alias.o bb-reorder.o bitmap.o builtins.o caller-save.o calls.o cfg.o cfganal.o cfgbuild.o cfgcleanup.o cfglayout.o cfgloop.o cfgloopanal.o cfgloopmanip.o loop-init.o loop-unswitch.o loop-unroll.o cfgrtl.o combine.o conflict.o convert.o coverage.o cse.o cselib.o dbxout.o ddg.o tree-ssa-loop-ch.o loop-invariant.o tree-ssa-loop-im.o debug.o df.o diagnostic.o dojump.o dominance.o loop-doloop.o dwarf2asm.o dwarf2out.o emit-rtl.o except.o explow.o loop-iv.o expmed.o expr.o final.o flow.o fold-const.o function.o gcse.o genrtl.o ggc-common.o global.o graph.o gtype-desc.o haifa-sched.o hooks.o ifcvt.o insn-attrtab.o insn-emit.o insn-modes.o insn-extract.o insn-opinit.o insn-output.o insn-peep.o insn-recog.o integrate.o intl.o jump.o langhooks.o lcm.o lists.o local-alloc.o loop.o mode-switching.o modulo-sched.o optabs.o options.o opts.o params.o postreload.o postreload-gcse.o predict.o insn-preds.o pointer-set.o print-rtl.o print-tree.o profile.o value-prof.o var-tracking.o real.o recog.o reg-stack.o regclass.o regmove.o regrename.o reload.o reload1.o reorg.o resource.o rtl.o rtlanal.o rtl-error.o sbitmap.o sched-deps.o sched-ebb.o sched-rgn.o sched-vis.o sdbout.o simplify-rtx.o sreal.o stmt.o stor-layout.o stringpool.o targhooks.o timevar.o toplev.o tracer.o tree.o tree-dump.o varasm.o varray.o vec.o version.o vmsdbgout.o xcoffout.o alloc-pool.o et-forest.o cfghooks.o bt-load.o pretty-print.o ggc-page.o web.o passes.o tree-profile.o rtlhooks.o cfgexpand.o lambda-mat.o lambda-trans.o lambda-code.o tree-loop-linear.o tree-ssa-sink.o tree-vrp.o tree-stdarg.o tree-cfgcleanup.o tree-ssa-reassoc.o tree-ssa-structalias.o tree-object-size.o i386.o host-linux.o tree-inline.o cgraph.o cgraphunit.o tree-nomudflap.o ipa.o ipa-inline.o ipa-utils.o ipa-reference.o ipa-pure-const.o ipa-type-escape.o ipa-prop.o ipa-cp.o i686-pc-linux-gnu-ar: symbol-tables.o: No such file or directory And in fact there is no symbol-tables.o but I saw it being compiled so I wonder where it has gone to. Any suggestions ?? Regards, Paulo Matos Regards, -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK
RE: Adding a new gcc dir
On 06 March 2007 18:22, Paulo J. Matos wrote: > i686-pc-linux-gnu-ar: symbol-tables.o: No such file or directory > > And in fact there is no symbol-tables.o but I saw it being compiled so > I wonder where it has gone to. > > > Any suggestions ?? 1. Always pipe the build output to a file so you can review it after the build and see what went wrong. 2. Learn about the unix 'find' command. 3. Don't use a subdirectory, none of the other passes do that, subdirectories are for separate languages. Think of it like this: a compile taking place in a subdirectory of the gcc build dir can reference the core gcc .o files built in the parent dir, but the core gcc build in the parent dir can't reference files in a sub-dir. (This isn't strictly true, I'm sure there's a way to make it work, but all the existing build machinery works this way round and it's probably easiest to keep to the same scheme). cheers, DaveK -- Can't think of a witty .sigline today
Re: build broken
Mike Stump schrieb: It appears that one of these: + '[' -s .bad_compare ']' + exit 1 I have a feeling sed -i isn't our friend. fixed. Matthias 2007-03-06 Matthias Klose <[EMAIL PROTECTED]> * doc/Makefile.am(gkeytool.pod): Don't use sed -i. * doc/Makefile.in: Regenerate. Index: doc/Makefile.am === --- doc/Makefile.am (Revision 122631) +++ doc/Makefile.am (Arbeitskopie) @@ -67,10 +67,10 @@ # hack around the cross references and the enumeration gkeytool.pod: $(srcdir)/cp-tools.texinfo - -$(TEXI2POD) -D gkeytool < $< > $@ - sed -i -e 's/^For more details.*/See I for more details./' \ + -$(TEXI2POD) -D gkeytool < $< \ + | sed -e 's/^For more details.*/See I for more details./' \ -e 's/1\.<\([^>]*\)>/- \1/' \ - $@ + > $@ gnative2ascii.pod: $(srcdir)/cp-tools.texinfo -$(TEXI2POD) -D gnative2ascii < $< > $@
Re: Adding a new gcc dir
On 3/6/07, Dave Korn <[EMAIL PROTECTED]> wrote: On 06 March 2007 18:22, Paulo J. Matos wrote: > i686-pc-linux-gnu-ar: symbol-tables.o: No such file or directory > > And in fact there is no symbol-tables.o but I saw it being compiled so > I wonder where it has gone to. > > > Any suggestions ?? 1. Always pipe the build output to a file so you can review it after the build and see what went wrong. Yes, so? What help would that be right now? 2. Learn about the unix 'find' command. I know about the find command! Why should I need it here? To do "find . -name symbol-tables.o" ? I told you, there's no such file. 3. Don't use a subdirectory, none of the other passes do that, subdirectories are for separate languages. Think of it like this: a compile taking place in a subdirectory of the gcc build dir can reference the core gcc .o files built in the parent dir, but the core gcc build in the parent dir can't reference files in a sub-dir. (This isn't strictly true, I'm sure there's a way to make it work, but all the existing build machinery works this way round and it's probably easiest to keep to the same scheme). So, any auxiliar files to the pass should be in the same directory as the pass itself. Or do you advise me to have _all_ the code in the pass file? Cheers, Paulo Matos cheers, DaveK -- Can't think of a witty .sigline today -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK
RE: Adding a new gcc dir
On 06 March 2007 20:12, Paulo J. Matos wrote: > On 3/6/07, Dave Korn <[EMAIL PROTECTED]> wrote: >> On 06 March 2007 18:22, Paulo J. Matos wrote: >> >> >>> i686-pc-linux-gnu-ar: symbol-tables.o: No such file or directory >>> >>> And in fact there is no symbol-tables.o but I saw it being compiled so >>> I wonder where it has gone to. >>> >>> >>> Any suggestions ?? >> >> 1. Always pipe the build output to a file so you can review it after the >> build and see what went wrong. >> > > Yes, so? What help would that be right now? You would be able to look again at the command-line that was invoked when you "saw it being compiled" and see what the -o option said. You could also see if there were any errors when it was compiled. >> 2. Learn about the unix 'find' command. >> > > I know about the find command! Why should I need it here? To do "find > . -name symbol-tables.o" ? I told you, there's no such file. You also told me you "saw it being compiled", from which I inferred that it /was/ compiled, from which I inferred that there had to be an output file somewhere. The only way I could reconcile those two seemingly-contradictory statements was to assume that you must not have looked for it in the place where it actually ended up. Of course, it's possible that it was compiled one minute and automagically deleted the next. If you had had that log file, you'd be able to see *that* too. >> 3. Don't use a subdirectory, none of the other passes do that, >> subdirectories are for separate languages. Think of it like this: a >> compile taking place in a subdirectory of the gcc build dir can reference >> the core gcc .o files built in the parent dir, but the core gcc build in >> the parent dir can't reference files in a sub-dir. (This isn't strictly >> true, I'm sure there's a way to make it work, but all the existing build >> machinery works this way round and it's probably easiest to keep to the >> same scheme). >> > > So, any auxiliar files to the pass should be in the same directory as > the pass itself. Well, that is how every other pass has been implemented. > Or do you advise me to have _all_ the code in the > pass file? No, I advise that when adding a pass, regardless of whether the code can fit in a single file or is large enough to need to use several separate files, it's consistent to put all the files that implement the pass in the main 'gcc' source directory. cheers, DaveK -- Can't think of a witty .sigline today
Re: GCC 4.2.0 Status Report (2007-03-04)
On 05/03/07, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote: On 05/03/07, Mark Mitchell <[EMAIL PROTECTED]> wrote: > After reviewing all of the traffic[1] that stemmed from my previous > status report, I've decided that, indeed, it makes sense to steam ahead > with GCC 4.2.0 based on current GCC 4.2.0 release branch. > I ask special permission to apply this patch: http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01461.html to GCC 4.2.0. This patch is trivial and it has been in GCC 4.3 for a few weeks already. It replaces two options that are introduced in GCC 4.2 with a single switch -Waddress. I think we should replace them before releasing, to minimise the effect of the change in users. Mark, Do you have an opinion about this? Whatever decision is made, I would like to delete it from my TODO list. Cheers, Manuel.
Re: Adding a new gcc dir
On 3/6/07, Dave Korn <[EMAIL PROTECTED]> wrote: No, I advise that when adding a pass, regardless of whether the code can fit in a single file or is large enough to need to use several separate files, it's consistent to put all the files that implement the pass in the main 'gcc' source directory. OK, thank you. cheers, DaveK -- Can't think of a witty .sigline today -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK
Re: GCC 4.2.0 Status Report (2007-03-04)
Manuel López-Ibáñez wrote: > On 05/03/07, Mark Mitchell <[EMAIL PROTECTED]> wrote: >> After reviewing all of the traffic[1] that stemmed from my previous >> status report, I've decided that, indeed, it makes sense to steam ahead >> with GCC 4.2.0 based on current GCC 4.2.0 release branch. >> > > I ask special permission to apply this patch: > > http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01461.html > > to GCC 4.2.0. This patch is trivial and it has been in GCC 4.3 for a > few weeks already. This patch is OK for 4.2.0, on the grounds that the -Walways-true option has not yet appeared in any FSF release, and we don't want to release the option with semantics different than what are eventually intended. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: which opt. flags go where? - references
Hi Kenneth, Just found your post in the gcc archive ;) - wanted to say that there have been many projects on the topic of optimal compiler flag selections. Actually, there are several free and commercial tools available for several years already: PathOpt from PathScale and ESTO from IBM, for example. We switched to PathOpt in 2003 and currently use it for our research since it is easily configurable, works with any languages, does not require project modifications and has many extendable basic search strategies (random, one by one, all but one). We easily coupled it with the PAPI library to obtain hardware counters, retargeted it to work with GCC and Intel Compilers, and added different machine learning algorithms. If you are interested, you can find more information about these tools and search techniques on global and fine-grain level, including publications and links to groups working on iterative optimizations at my webpage here: http://fursin.net/research_iter.html Also, if you are interested, we will present our new paper "Rapidly Selecting Good Compiler Optimizations using Performance Counters" at the CGO in a few days where we use hardware counters and machine learning to select best optimization flags for the PathScale compiler (Open64/ORC compiler). Unfortunately, I will not be able to come to CGO and present it due to some passport problems, but there will be my colleagues whom you can chat with about iterative optimizations ... By the way, we now move most of our tools and techniques to the GCC within MilePost project and HiPEAC network, and would be happy for any comments and suggestions. Our development website is here: http://gcc-ici.sourceforge.net Cheers, Grigori = Grigori Fursin, PhD Research Fellow, INRIA Futurs, France http://fursin.net * From: Kenneth Hoste * To: Diego Novillo * Cc: gcc at gcc dot gnu dot org, Ben Elliston * Date: Wed, 7 Feb 2007 15:35:15 +0100 * Subject: Re: which opt. flags go where? - references * References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Hi, On 07 Feb 2007, at 15:22, Diego Novillo wrote: Kenneth Hoste wrote on 02/07/07 08:56: [1] Almagor et al., Finding effective compilation sequences (LCES'04) [2] Cooper et al., Optimizing for Reduced Code Space using Genetic Algorithms (LCTES'99) [3] Almagor et al., Compilation Order Matters: Exploring the Structure of the Space of Compilation Sequences Using Randomized Search Algorithms (Tech.Report) [3] Acovea: Using Natural Selection to Investigate Software Complexities (http://www.coyotegulch.com/products/acovea/) You should also contact Ben Elliston (CC'd) and Grigori Fursin (sorry, no email). Ben worked on dynamic reordering of passes, his thesis will have more information about it. Grigori is working on an API for iterative an adaptive optimization, implemented in GCC. He presented at the last HiPEAC 2007 GCC workshop. Their presentation should be available at http://www.hipeac.net/node/746 I actually talked to Grigori about the -Ox flags, I was at the HiPEAC conference too ;-) I didn't include references to his work, because my aim wouldn't be at reordering of passes, but just selecting them. I understand that reordering is of great importance while optimizing, but I think this project is big enough as is. Some other questions: * I'm planning to do this work on an x86 platform (i.e. Pentium4), but richi told me that's probably not a good idea, because of the low number of registers available on x86. Comments? When deriving ideal flag combinations for -Ox, we will probably want common sets for the more popular architectures, so I would definitely include x86. OK. I think richi's comment on x86 was the fact that evaluating the technique we are thinking about might produce results which are hard to 'port' to a different architecture. But then again, we won't be stating we have found _the_ best set of flags for a given goal... Thank you for your comment. * Since we have done quite some analysis on the SPEC2k benchmarks, we'll also be using them for this work. Other suggestions are highly appreciated. We have a collection of tests from several user communities that we use as performance benchmarks (DLV, TRAMP3D, MICO). There should be links to the testers somewhere in http://gcc.gnu.org/ OK, sounds interesting, I'll look into it. In which way are these benchmarks used? Just to test the general performance of GCC? Have they been compared to say, SPEC CPU, or other 'research/industrial' benchmark suites (such as MiBench, MediaBench, EEMBC, ...) ? * Since there has been some previous work on this, I wonder why none of it has made it into GCC development. Were the methods proposed unfeasible for some reason? What would be needed to make an approach to automatically find suitable flags for -
GCC Interactive Compilation Interface development
Dear all, Just wanted to announce that we are working on the GCC Interactive Compilation Interface to enable automatic tuning of optimization heuristic. This interface is used in HiPEAC, MilePost, SARC and GCCC projects. A website with latest patches, software, forums, mailing lists, publications is available here: http://gcc-ici.sourceforge.net Current prototype of GCC-ICI has an ability to reorder compiler optimization phases and fine-tune several transformations. We are currently working on the following issues: * incrementally modifying Tree-SSA to support dynamic pass reordering * splitting analysis and optimization code * extracting program features * adding support for fine-grain tuning of most of the GCC optimizations * developing a component model for passes to enable dynamic linking of external optimization plugins * developing a scripting language inside GCC to simplify and automatize transformations & optimization process We presented our preliminary work at the SMART'07 workshop and GCC HiPEAC Tutorial where I had a chat with Diego Novillo et al about further GCC-ICI developments. We now plan to have an open discussion at the GCC-ICI forum about further developments and will be happy for any comments and suggestions. Here is the formal motivation for our research and developments: Current innovations in science and industry demand ever-increasing computing resources while placing strict requirements on system performance, power consumption, code size, response, reliability, portability and design time. However compilers often fail to deliver satisfactory levels of performance on modern processors, due to rapidly evolving hardware, lack/cost of expert resources, fixed and black-box optimization heuristics, simplistic hardware models, inability to fine-tune the application of transformations, and highly dynamic behavior of the system. Recently, we started developing an Interactive Compilation Interface (ICI) to connect external optimization drivers to the GCC. This interface is meant to facilitate the prototyping and evaluation of iterative optimization, fine-grain customization and design-space exploration strategies. The early design to enable non-intrusive feature extraction and meddling with heuristic's decisions was presented at the SMART'07 workshop. Currently, we are working on a more advanced design, incrementally modifying Tree-SSA to support dynamic pass reordering, structured split of analysis and optimization code, and a component model for passes to enable dynamic linking of external optimization plugins. We believe these modification will simplify the tuning process of new optimization heuristics and will eventually simplify the whole compiler design where compiler heuristics will be learned automatically, continuously and transparently for a user using statistical and machine learning techniques. Looking forward to your input, Grigori Fursin = Grigori Fursin, PhD Research Fellow, INRIA Futurs, France http://fursin.net/research_desc.html
Re: GCC 4.2.0 Status Report (2007-03-04)
On 06/03/07, Mark Mitchell <[EMAIL PROTECTED]> wrote: Manuel López-Ibáñez wrote: > On 05/03/07, Mark Mitchell <[EMAIL PROTECTED]> wrote: >> After reviewing all of the traffic[1] that stemmed from my previous >> status report, I've decided that, indeed, it makes sense to steam ahead >> with GCC 4.2.0 based on current GCC 4.2.0 release branch. >> > > I ask special permission to apply this patch: > > http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01461.html > > to GCC 4.2.0. This patch is trivial and it has been in GCC 4.3 for a > few weeks already. This patch is OK for 4.2.0, on the grounds that the -Walways-true option has not yet appeared in any FSF release, and we don't want to release the option with semantics different than what are eventually intended. Thanks, As far as I know, it was introduced in GCC 4.2 revision 108489. Also: $ svn log svn://gcc.gnu.org/svn/gcc/branches/gcc-4_2-branch | grep -n -e "Walways.true" 63424: * gcc.dg/20031012-1.c: Add -Walways-true option. 63978: * doc/invoke.texi (Warning Options): Document -Walways-true being 64532: * common.opt (Walways-true): New option. while $ svn log svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch | grep -n -e "Walways.true" shows nothing. Cheers, Manuel.
Re: build broken
On Mar 6, 2007, at 11:14 AM, Matthias Klose wrote: Mike Stump schrieb: I have a feeling sed -i isn't our friend. fixed. I can confirm that this fixed my build. I'm expected the regression tester to follow shortly. Thanks.
Re: GCC 4.2.0 Status Report (2007-03-04)
"Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes: | On 06/03/07, Mark Mitchell <[EMAIL PROTECTED]> wrote: | > Manuel López-Ibáñez wrote: | > > On 05/03/07, Mark Mitchell <[EMAIL PROTECTED]> wrote: | > >> After reviewing all of the traffic[1] that stemmed from my previous | > >> status report, I've decided that, indeed, it makes sense to steam ahead | > >> with GCC 4.2.0 based on current GCC 4.2.0 release branch. | > >> | > > | > > I ask special permission to apply this patch: | > > | > > http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01461.html | > > | > > to GCC 4.2.0. This patch is trivial and it has been in GCC 4.3 for a | > > few weeks already. | > | > This patch is OK for 4.2.0, on the grounds that the -Walways-true option | > has not yet appeared in any FSF release, and we don't want to release | > the option with semantics different than what are eventually intended. | > | > Thanks, | > | | As far as I know, it was introduced in GCC 4.2 revision 108489. | | Also: | | $ svn log svn://gcc.gnu.org/svn/gcc/branches/gcc-4_2-branch | grep -n | -e "Walways.true" | 63424: * gcc.dg/20031012-1.c: Add -Walways-true option. | 63978: * doc/invoke.texi (Warning Options): Document -Walways-true being | 64532: * common.opt (Walways-true): New option. | | while | | $ svn log svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch | grep -n | -e "Walways.true" | | shows nothing. I strongly encourage the removal brefore 4.2 gets out. -- Gaby
