Re: Failure in bootstrapping gfortran-4.4.0-20080425 on Cygwin
"H.J. Lu" <[EMAIL PROTECTED]> wrote on 27.04.2008 21:31:14:
> Is this related to
>
> http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01951.html
>
>
> H.J.
> On Sun, Apr 27, 2008 at 11:47 AM, FX <[EMAIL PROTECTED]> wrote:
> >
> > > Cygwin native built gfortran 4.4 was already broken, even when it
was
> > making it through bootstrap and testsuite. All comments I've received
told
> > me I was wasting my time with it.
> > >
> >
> > Where is that bug reported? cygwin is secondary target, I think it
should
> > really be unbroken, with the help of its maintainers (and possibly by
> > identifying the patch that broke bootstrap).
> >
> >
> >
> > FX
> >
> > --
> > François-Xavier Coudert
> > http://www.homepages.ucl.ac.uk/~uccafco/
> >
> >
>
I reverted the patch to keep fortran compilable on Saturday and
bootstrapped it. This patch was just affecting mingw target by changes in
mingw32.h and can't affect cygwin target, so it is unlikely to be the
reason.
The problem was for this patch, that the fortran frontend does not provide
the function disable_builtin_function. Fortran uses implicit the builtins
by the middle, but does not support the api defined in c-common.c.
By this reason a subtarget is unable to disable builtins for C/C++ targets
via the provide api, so I removed this patch.
Kai
| (\_/) This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| (")_(") world domination.
Re: IRA for GCC 4.4
On 2008/4/28 Ben Elliston <[EMAIL PROTECTED]> wrote: > On Sun, 2008-04-27 at 21:45 +0200, J.C. Pizarro wrote: > > > Don't be stupid! > > Could you be a bit more civil, please? It's fairly unusual for people > on this list to talk to each other in this way. > > Thanks, > Ben Excuse me, i'm not the unique and first person that says you stupid, GCC did it too. The "stupid" word can be a help, not only an offense. gcc/cp/decl.c: and in case doing stupid register allocation. gcc/c-aux-info.c: user may do something really stupid, like creating a brand new gcc/reload.c: we are called from global_alloc but false when stupid register gcc/dwarf2out.c: Now onto stupid register sets in non contiguous locations. gcc/protoize.c: A table of conversions that may need to be made for some (stupid) older /gcc/protoize.c: Don't act too stupid here. Somebody may try to convert an entire system gcc/protoize.c: case it would be stupid for us to fail to realize that this one definition gcc/protoize.c: this is stupid practice and should be discouraged. gcc/tree-ssa-phiopt.c: anything stupid here. gcc/c-common.c: Warn for unlikely, improbable, or stupid DECL declarations gcc/function.c: ??? This should no longer be necessary since stupid is no longer with gcc/gimple-low.c: don't know. This is used only to avoid stupidly generating extra code. gcc/genrecog.c: ??? is_unconditional is a stupid name for a tri-state function. gcc/global.c: and it is run even when stupid register allocation is in use. gcc/config/arm/arm.c: Prevent the user from choosing an obviously stupid PIC register. gcc/config/ia64/ia64-modes.def: so that flow doesn't do something stupid. gcc/config/ia64/ia64.c: stop the paradoxical subreg stupidity in the *_operand functions gcc/config/ia64/predicates.md: Deny the stupid user trick of addressing outside the object. gcc/config/mmix/predicates.md: FIXME: This may be a stupid trick. What happens when GCC wants to gcc/config/v850/v850.c: Function prototypes for stupid compilers gcc/config/sparc/sparc.c: avoid emitting truly stupid code. gcc/config/rs6000/darwin-fpsave.asm: be a stupid thing to do, anyway gcc/Makefile.in: Really, really stupid make features, such as SUN's KEEP_STATE, may force gcc/alias.c: but stupid user tricks can produce them, so don't die. gcc/c-decl.c: and in case doing stupid register allocation. gcc/c-decl.c: Warn for unlikely, improbable, or stupid declarations of `main'. gcc/optabs.c: but it's nice to not be stupid about initial code gen either. gcc/regrename.c: of a call insn, which is stupid, since these are certainly configure: This seems to be due to autoconf 2.5x stupidity. libstdc++-v3/doc/xml/manual/using.xml: However, you still need to not do stupid things like calling libstdc++-v3/scripts/run_doxygen: work around a stupid doxygen bug libstdc++-v3/scripts/run_doxygen: here's the other end of the "stupid doxygen bug" mentioned above libstdc++-v3/testsuite/data/thirty_years_among_the_dead_preproc.txt: stupidity configure.ac: This seems to be due to autoconf 2.5x stupidity. ChangeLog: Makefile.tpl: Fix stupid pasto. ChangeLog: configure: Fix stupid bug where RANLIB was mistakenly included. ChangeLog: configure.in: Fix deeply stupid bug. J.C.Pizarro
[switch conv] Bootsrap error because of the (CERT) pointer wraparound warning
Hi,
I've been rebootstrapping my switch conversion patch (which is still
waiting for review) to make sure it still works. Unfortunately, it
did not. The error given was the following and I believe this is the
warning introduced by Ian as a response to the infamous CERT advisory.
(Furthermore, I am getting this warning at revision 134664 but I was
not getting it at 134135.)
--- Compiler output ---
/cswtch/gcc/. -I/abuild/mjambor/cswtch/gcc/../include
-I/abuild/mjambor/cswtch/gcc/../libcpp/include
-I/abuild/mjambor/cswtch/gcc/../libdecnumber
-I/abuild/mjambor/cswtch/gcc/../libdecnumber/bid -I../libdecnumber
/abuild/mjambor/cswtch/gcc/tree-switch-conversion.c -o tree-switch-conversion.o
cc1: warnings being treated as errors
/abuild/mjambor/cswtch/gcc/tree-switch-conversion.c: In function
'process_switch':
/abuild/mjambor/cswtch/gcc/tree-switch-conversion.c:182: error: assuming signed
overflow does not occur when assuming that (X - c) > X is always false
make[3]: *** [tree-switch-conversion.o] Error 1
- End -
The whole switch conversion patch can be found at:
http://gcc.gnu.org/ml/gcc-patches/2008-04/msg00863.html. The code
that triggers the warning is the following, line 182 is the last one
in this snippet:
static bool
check_range (tree swtch) /* swtch is a SWITCH_EXPR */
{
tree min_case, max_case;
tree cases = SWITCH_LABELS (swtch);
int branch_num = TREE_VEC_LENGTH (cases);
min_case = TREE_VEC_ELT (cases, 0);
info.range_min = CASE_LOW (min_case);
gcc_assert (branch_num > 1);
gcc_assert (CASE_LOW (TREE_VEC_ELT (cases, branch_num - 1)) == NULL_TREE);
max_case = TREE_VEC_ELT (cases, branch_num - 2);
Now the fundamental question is, am I doing something wrong? My best
guess is that this is only a very unfortunate bogus instance of the
warning. When checking is not enabled, TREE_VEC_ELT(T, I) is expanded
to ((T)->vec.a[I]) and given that branch_num holds the number of
vector elements, I am certainly accessing an item inside the array.
On the contrary, bootstrapping is done with checking on and so
TREE_VEC_ELT expands to much more complex thing:
#define TREE_VEC_ELT_CHECK(T, I) __extension__ \
(*({__typeof (T) const __t = (T); \
const int __i = (I);\
if (TREE_CODE (__t) != TREE_VEC)\
tree_check_failed (__t, __FILE__, __LINE__, __FUNCTION__, \
TREE_VEC, 0); \
if (__i < 0 || __i >= __t->vec.length) \
tree_vec_elt_check_failed (__i, __t->vec.length, \
__FILE__, __LINE__, __FUNCTION__); \
&__t->vec.a[__i]; }))
And I guess that the second condition triggers the warning which is
then treated like an error.
Having said the above, I do not know why the TREE_VEC_ELT on the
previous line does not trigger the warning.
In the end, I basically have these questions:
1. Am I doing something wrong?
2. How can I get rid of the error and bootstrap my code?
3. If the warning is really bogus, should we perhaps turn it off for
bootstrap, (or turn it off by default in general and leave it
there for people who want to check their code after reading CERT
advisories)?
Thank you,
Martin
Redundant malloc in structure optimization? (testsuite/gcc.dg/struct/wo_prof_global_var.c)
Hello,
I am looking at a testsuite failure (wo_prof_global_var.c) in my
porting. Somehow, I found GCC 4.3.0 seems to generate unnecessary malloc
during structure optimization. In the code, the structure is split into
two individual fields (D.2240 and D.2242) and they are allocated
separately. But the original structure (D.2215) is still allocated, and
not used afterward. The following RTL-level optimization cannot
eliminate it.
Cheers,
Bingfeng Mei
Broadcom UK
Original C code:
/* { dg-do compile } */
/* { dg-do run } */
#include
typedef struct
{
int a;
float b;
}str_t;
#define N 1000
str_t *p;
int
main ()
{
int i, sum;
p = malloc (N * sizeof (str_t));
for (i = 0; i < N; i++)
p[i].a = p[i].b + 1;
for (i = 0; i < N; i++)
if (p[i].a != p[i].b + 1)
abort ();
return 0;
}
.final_cleanup
/*--
*/
/* { dg-final { scan-ipa-dump "Number of structures to transform is 1"
"ipa_struct_reorg" } } */
/* { dg-final { cleanup-ipa-dump "*" } } */
;; Function main (main)
main ()
{
int i.43;
unsigned int D.2245;
unsigned int D.2243;
void * D.2242;
void * D.2240;
struct struct.0_sub.1 * p.0.4;
struct struct.0_sub.0 * p.0.3;
int i;
void * D.2215;
:
D.2215 = malloc (8000);
D.2240 = malloc (4000);
p.0.3 = (struct struct.0_sub.0 *) D.2240;
D.2242 = malloc (4000);
p.0.4 = (struct struct.0_sub.1 *) D.2242;
p = (struct str_t *) D.2215;
p.1 = p.0.4;
p.0 = p.0.3;
i = 0;
:
D.2243 = (unsigned int) i << 2;
(p.0.4 + D.2243)->a = (int) ((p.0.3 + D.2243)->b + 1.0e+0);
i = i + 1;
if (i != 1000)
goto ;
else
goto ;
:
i.43 = 0;
:
D.2245 = (unsigned int) i.43 << 2;
if ((float) (p.0.4 + D.2245)->a != (p.0.3 + D.2245)->b + 1.0e+0)
goto ;
else
goto ;
:
abort ();
:
i.43 = i.43 + 1;
if (i.43 != 1000)
goto ;
else
goto ;
:
return 0;
}
Code representations
I am trying to look at assembler code, and representing it as C code. For ia32, x86 platforms, assembler like the following ADD eax,ebx; JO integer_overflow_detected; How would I represent this in C? Kind Regards James
Re: Code representations
[EMAIL PROTECTED] wrote on 28.04.2008 13:11:39:
> I am trying to look at assembler code, and representing it as C code.
>
> For ia32, x86 platforms,
> assembler like the following
>
> ADD eax,ebx;
> JO integer_overflow_detected;
>
> How would I represent this in C?
>
> Kind Regards
>
> James
It would be something like this:
#define MSB (type) ((1<<((sizeof(type)*8)-1))
typedef unsigned int myscalar;
...
{
myscalar a,b,savea;
...
savea = a;
a+=b;
if ( ((savea & MSB(myscalar)) & ((b & MSB(myscalar)) & ~(a &
MSB(myscalar ||
( ~(savea & MSB(myscalar)) & ~(b&MSB(myscalar)) & (a&MSB(myscalar
/* overflow */
...
}
For signed integers you can ease this as follow
savea = a;
a+=b;
if ( (savea<0 && b<0 && a>=0)) ||
(savea>=0 && b>=0 && a<0))
/* overflow */
Regards,
i.A. Kai Tietz
| (\_/) This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| (")_(") world domination.
Metrication tool
Dear Reader, A few years ago I had already posted a question about implementing a metrication tool in GCC, i.e. a tool that can measure several metrics from the source code. Examples could be, the number of variables, number of multiplications, number of loops, number of functions, etc. At that time I needed that information for a Hardware Estimation Model I was building for my MSc. Thesis (http://ce.et.tudelft.nl/~rmeeuws/thesis.pdf). I was pointed to the ELSA compiler frontend which suited my purposes just fine... However, currently in my PhD work I have to take the model several steps further... First, I need to increase the models accuracy. One source of inaccuracy is that the metrics I use are determined at a very high level, i.e. I am counting operations that are removed by optimizations, like constant propagation, common subexpression elimination, dead code removal, etc. Therefore I need to measure some of the metrics at a lower level, which I aim to do using GCC, because in time the hardware generator (from c code) we use at our department will probably be moved to GCC at some point as well. So here is what I would like to know: what kind of metrics could I measure at e.g. GIMPLE level, and what steps do I need to take to implement a pass for GIMPLE to measure the needed values? Many thanks in advance for any help you can provide, with Kind Regards, Roel -- Roel Meeuws PhD. Student Delft University of Technology Faculty of Electrical Engineering Mathematics and Computer Science Computer Engineering Laboratory Mekelweg 4, 2628 CD Delft, The Netherlands Email:[EMAIL PROTECTED] Office: HB 16.290 Office phone: +31 (0)15 27 82 165 Mob. phone: +31 (0)6 10 82 44 01
Re: IRA for GCC 4.4
On Mon, Apr 28, 2008 at 09:07:51AM +0200, J.C. Pizarro wrote: > Excuse me, i'm not the unique and first person that says you stupid, > GCC did it too. GCC is not posting on the mailing list. Please be polite to other contributors; that includes not insulting their intelligence. -- Daniel Jacobowitz CodeSourcery
Re: Code representations
2008/4/28 Kai Tietz <[EMAIL PROTECTED]>:
> [EMAIL PROTECTED] wrote on 28.04.2008 13:11:39:
>
>
>
> > I am trying to look at assembler code, and representing it as C code.
> >
> > For ia32, x86 platforms,
> > assembler like the following
> >
> > ADD eax,ebx;
> > JO integer_overflow_detected;
> >
> > How would I represent this in C?
> >
> > Kind Regards
> >
> > James
>
> It would be something like this:
>
> #define MSB (type) ((1<<((sizeof(type)*8)-1))
> typedef unsigned int myscalar;
> ...
> {
> myscalar a,b,savea;
> ...
> savea = a;
> a+=b;
> if ( ((savea & MSB(myscalar)) & ((b & MSB(myscalar)) & ~(a &
> MSB(myscalar ||
> ( ~(savea & MSB(myscalar)) & ~(b&MSB(myscalar)) & (a&MSB(myscalar
> /* overflow */
> ...
> }
>
> For signed integers you can ease this as follow
>
> savea = a;
> a+=b;
> if ( (savea<0 && b<0 && a>=0)) ||
> (savea>=0 && b>=0 && a<0))
> /* overflow */
>
I am taking a wild guess here, but can I assume that the above will
not compile back to something like:
ADD eax,ebx;
JO integer_overflow_detected;
I think I will have to have some macro/function in C that does the following:
add(int a,int b, int (&integer_overflow_detected));
This will add a and b, and jump to the overflow handler if there is an overflow.
I can then implement CPU specific implementations for each target
platform, and that would at least return to the same ASM code
generated at compile.
James
Re: Code representations
"James Courtier-Dutton" <[EMAIL PROTECTED]> wrote on 28.04.2008
15:28:56:
> 2008/4/28 Kai Tietz <[EMAIL PROTECTED]>:
> > [EMAIL PROTECTED] wrote on 28.04.2008 13:11:39:
> >
> >
> >
> > > I am trying to look at assembler code, and representing it as C
code.
> > >
> > > For ia32, x86 platforms,
> > > assembler like the following
> > >
> > > ADD eax,ebx;
> > > JO integer_overflow_detected;
> > >
> > > How would I represent this in C?
> > >
> > > Kind Regards
> > >
> > > James
> >
> > It would be something like this:
> >
> > #define MSB (type) ((1<<((sizeof(type)*8)-1))
> > typedef unsigned int myscalar;
> > ...
> > {
> > myscalar a,b,savea;
> > ...
> > savea = a;
> > a+=b;
> > if ( ((savea & MSB(myscalar)) & ((b & MSB(myscalar)) & ~(a &
> > MSB(myscalar ||
> > ( ~(savea & MSB(myscalar)) & ~(b&MSB(myscalar)) &
(a&MSB(myscalar
> > /* overflow */
> > ...
> > }
> >
> > For signed integers you can ease this as follow
> >
> > savea = a;
> > a+=b;
> > if ( (savea<0 && b<0 && a>=0)) ||
> > (savea>=0 && b>=0 && a<0))
> > /* overflow */
> >
>
> I am taking a wild guess here, but can I assume that the above will
> not compile back to something like:
> ADD eax,ebx;
> JO integer_overflow_detected;
This is a matter of the optimization. But I guess that gcc won't optimize
this to the same instruction you wrote, too.
But you queried 'How would I represent this in C?' and the above code is
the c representation of your assembler, sure.
> I think I will have to have some macro/function in C that does the
following:
> add(int a,int b, int (&integer_overflow_detected));
> This will add a and b, and jump to the overflow handler if there is
> an overflow.
> I can then implement CPU specific implementations for each target
> platform, and that would at least return to the same ASM code
> generated at compile.
May the better choice for your purpose.
Kai
| (\_/) This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| (")_(") world domination.
Re: dg-skip-if on powerpc when multiple cpu cflags specified
Mark Mitchell wrote: Janis Johnson wrote: This will involve editing every test that using dg-options to add a -mcpu/-march flag. Would it make sense to let dg-options check for the conflict as it adds an option? Yes, it would meaning adding the new option to hundreds of tests, but that's better than the earlier suggestion of adding a very ugly dg-skip-if to every one of those tests. I think it's even more complicated. The testsuite should not assume that options explicitly provided (a combination of the options explicitly in the test, those implicitly for the DejaGNU harness, those for the multilib being tested, and those provided in the board file) are those that govern completely. In particular, the --with-cpu configuration option, or other bits of configury, or -t options that serve as abbreviations for other options can all affect what CPU is actually being targeted. Trying to scan the list of options to see which ones are provided is too error-prone. Therefore I think there are two plausible approaches: 1. Make these tests say something about what capability they require, with a dg-require directive, and then write autoconf-style tests run by the testsuite to determine whether the current compiler has that capability. For example, add a "dg-require-hard-float" directive, and probe the compiler to see whether it can generate hard float, given all the options in play. That will not work on at least the *-rtems* configurations. We use one multilib'ed toolset configuration to support all variants within a family. So for the PowerPC, we actually do have support for [4567]xx, [58]xxx, etc. m68k includes coldfire, etc. 2. Write the tests with #ifdef's that test compiler predefines that indicate the CPU model, architecture, or available feature. For example, it would be a nice thing if something like __GNU_CPU_y__ and __GNU_TUNE_z__ were defined on all machines, corresponding to -march= and -mtune=. For example __GNU_CPU_603__ for a Power 603, or __GNU_FEATURE_ALTIVEC__ for a CPU with AltiVec support, or something. I think this would work. If you ended up with compiler settings that didn't match what the test required, then it could exit. How should it exit in this case? For the case we have been looking at, -mcpu=405 results in __PPC405__ being defined. If you are writing a CPU model specific test, you should know what the macro generated is. #if !defined(__PPC405__) XXX -- ?? what to do? #endif Would this work on the scan tests which look for particular assembly instructions? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713 -- Joel Sherrill, Ph.D. Director of Research & Development [EMAIL PROTECTED]On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Re: Metrication tool
On 4/28/08 7:46 AM, Roel Meeuws wrote: So here is what I would like to know: what kind of metrics could I measure at e.g. GIMPLE level, and what steps do I need to take to implement a pass for GIMPLE to measure the needed values? You can measure anything that is language-independent (though you could try to discern some FE attributes from the types you get). You can also do some limited measurements on target properties using target hooks. Writing a GIMPLE pass should not be too hard. There are some articles and online tutorials that may help. See http://gcc.gnu.org/wiki/GettingStarted Diego.
RE: IRA for GCC 4.4
J.C. Pizarro wrote on : > On 2008/4/28 Ben Elliston wrote: >> On Sun, 2008-04-27 at 21:45 +0200, J.C. Pizarro wrote: >> >> > Don't be stupid! >> >> Could you be a bit more civil, please? It's fairly unusual for people >> on this list to talk to each other in this way. >> >> Thanks, >> Ben > > Excuse me, i'm not the unique and first person that says you stupid, GCC > did it too. Even if that were so, two wrongs do not make a right. > The "stupid" word can be a help, not only an offense. > > gcc/cp/decl.c: and in case doing stupid register allocation. > gcc/c-aux-info.c: user may do something really stupid, like > creating a brand new The crucial difference you've overlooked is that all these comments are describing some /thing/ as stupid, not some /person/. When you want to offer what you hope will be /constructive/ criticism, try to de-personalise the issues; it makes for more productive social interactions. cheers, DaveK -- Can't think of a witty .sigline today
Re: IRA for GCC 4.4
On 2008/4/28 Dave Korn <[EMAIL PROTECTED]> wrote: > J.C. Pizarro wrote on : > > > > On 2008/4/28 Ben Elliston wrote: > >> On Sun, 2008-04-27 at 21:45 +0200, J.C. Pizarro wrote: > >> > >> > Don't be stupid! > >> > >> Could you be a bit more civil, please? It's fairly unusual for people > >> on this list to talk to each other in this way. > >> > >> Thanks, > >> Ben > > > > Excuse me, i'm not the unique and first person that says you stupid, GCC > > did it too. > > Even if that were so, two wrongs do not make a right. It's your personal comment. For me, they do not make a right when they are 7 wrongs. > > > The "stupid" word can be a help, not only an offense. > > > > gcc/cp/decl.c: and in case doing stupid register allocation. > > gcc/c-aux-info.c: user may do something really stupid, like > > creating a brand new > > The crucial difference you've overlooked is that all these comments are > describing some /thing/ as stupid, not some /person/. When you want to offer > what you hope will be /constructive/ criticism, try to de-personalise the > issues; it makes for more productive social interactions. What about the stupid user in gcc/alias.c: but stupid user tricks can produce them, so don't die ? But the stupid things are made by humans, never by things. You can't de-personalise the stupid things made by humans, so it's better to say them stupid to persons who did stupid things better than to unfear things. > > cheers, > DaveK > -- > Can't think of a witty .sigline today
Re: dg-skip-if on powerpc when multiple cpu cflags specified
Joel Sherrill wrote:
1. Make these tests say something about what capability they require,
with a dg-require directive, and then write autoconf-style tests run by
the testsuite to determine whether the current compiler has that
capability. For example, add a "dg-require-hard-float" directive, and
probe the compiler to see whether it can generate hard float, given all
the options in play.
That will not work on at least the *-rtems* configurations.
We use one multilib'ed toolset configuration to support
all variants within a family. So for the PowerPC, we actually
do have support for [4567]xx, [58]xxx, etc. m68k includes
coldfire, etc.
There's no reason that we can't probe once per multilib. There are
already probes like that in the testsuite. The autoconfy-ness just
needs to be per-multilib.
I think this would work. If you ended up with compiler
settings that didn't match what the test required, then
it could exit. How should it exit in this case?
Just by doing "return 0;" from "main".
For the case we have been looking at, -mcpu=405 results
in __PPC405__ being defined. If you are writing a CPU model
specific test, you should know what the macro generated is.
#if !defined(__PPC405__)
XXX -- ?? what to do?
#endif
Here:
#if !defined(__PPC405__)
int main() { return 0; }
#else
/* The real test goes here. */
#endif
Would this work on the scan tests which look for particular
assembly instructions?
Probably not. Though, I suppose:
#if !defined(__PPC405__)
asm("haha here is a 405 insn");
#else
/* The real test goes here. */
#endif
might...
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
GCC performance with CP2K
I've just tested gcc/gfortran with CP2K, which some of you might know from PR29975 and other messages to the list, and observed some very pleasing evolution in the runtime of the code. In each case the set of compilation options is '-O2 -ffast-math -funroll-loops -ftree-vectorize -march=native' (-march=k8-sse3), the intel reference '-O2 -xW -heap-arrays 64' version subroutine time[s] out.intel: CP2K 504.52 out.gfortran.4.2.3: CP2K 601.35 out.gfortran.4.3.0: CP2K 569.42 out.gfortran.4.4.0: CP2K 508.12 I hope that this rate of improvement sets a standard up to gcc 4.95.3 ;-) Thanks for your efforts... Cheers, Joost
Re: IRA for GCC 4.4
On 2008/4/27 J.C. Pizarro <[EMAIL PROTECTED]> wrote: > On Fri 25 Apr 2008 22:22:55 -0500, Peter Bergner <[EMAIL PROTECTED]> wrote: > > The difference between a compressed upper triangular bit matrix from a > standard > > upper triangular bit matrix like the one above, is we eliminate space from > the > > bit matrix for conflicts we _know_ can never exist. The easiest case to > catch, > > and the only one we catch at the moment, is that allocnos that are "local" > to a > > basic block B1 cannot conflict with allocnos that are local to basic block > B2, > > where B1 != B2. To take advantage of this fact, I updated the code in > global.c > > to sort the allocnos such that all "global" allocnos (allocnos that are > live in > > more than one basic block) are given smaller allocno numbers than the > "local" > > allocnos, and all allocnos for a given basic block are grouped together in > a > > contiguous range to allocno numbers. The sorting is accomplished by: > > > > /* ...so we can sort them in the order we want them to receive > > their allocnos. */ > > qsort (reg_allocno, max_allocno, sizeof (int), regno_compare); > > > > ... > It's useful when there are increases or decreases in the number of BBs. Topicing off about the recent stupidity's discussion, the chained upper triangulars and rectangulars are more flexible than a bigger compressed upper triangular because how expensive is modifying the compressed upper triangular when 1) add o remove basic blocks? 2) add o remove allocnos? In the chained case, you can call to subroutine to make it consistent after of adding or removing basic blocks or allocnos, it's traversing the chains and remallocing the many local memoryspaces of BBs. In the compressed case, you have to realize complex and expensive routines for remallocing the big compressed upper triangular. J.C.Pizarro
Re: dg-skip-if on powerpc when multiple cpu cflags specified
On Mon, 2008-04-28 at 07:47 -0700, Mark Mitchell wrote:
> Joel Sherrill wrote:
>
> >> 1. Make these tests say something about what capability they require,
> >> with a dg-require directive, and then write autoconf-style tests run by
> >> the testsuite to determine whether the current compiler has that
> >> capability. For example, add a "dg-require-hard-float" directive, and
> >> probe the compiler to see whether it can generate hard float, given all
> >> the options in play.
Defining proc check_effective_target_whatever makes it possible
to use "dg-require-effective-target whatever", or combinations
of whatever with other effective targets. The proc can compile,
and optionally run, a configuration test with the current set of
options. I suppose it could even be used before and after
dg-options to make sure that the test files compiled with those
options will be compatible with support files compiled without
those options, as in
/* { dg-require-effective-target hard_float } */
/* { dg-options "-O2 -mcpu=405" } */
/* { dg-require-effective-target hard_float && ppc405 } */
> > That will not work on at least the *-rtems* configurations.
> > We use one multilib'ed toolset configuration to support
> > all variants within a family. So for the PowerPC, we actually
> > do have support for [4567]xx, [58]xxx, etc. m68k includes
> > coldfire, etc.
>
> There's no reason that we can't probe once per multilib. There are
> already probes like that in the testsuite. The autoconfy-ness just
> needs to be per-multilib.
Right, the effective-target tests are usually run per-multilib.
> > I think this would work. If you ended up with compiler
> > settings that didn't match what the test required, then
> > it could exit. How should it exit in this case?
>
> Just by doing "return 0;" from "main".
>
> > For the case we have been looking at, -mcpu=405 results
> > in __PPC405__ being defined. If you are writing a CPU model
> > specific test, you should know what the macro generated is.
> >
> > #if !defined(__PPC405__)
> > XXX -- ?? what to do?
> > #endif
>
> Here:
>
> #if !defined(__PPC405__)
> int main() { return 0; }
> #else
> /* The real test goes here. */
> #endif
>
> > Would this work on the scan tests which look for particular
> > assembly instructions?
>
> Probably not. Though, I suppose:
>
> #if !defined(__PPC405__)
> asm("haha here is a 405 insn");
> #else
> /* The real test goes here. */
> #endif
>
> might...
It's easier, though, to just skip the test.
Janis
[RFC] Modeling the behavior of function calls
[ Apologies if this comes out twice. I posted this message last week, but I think it was rejected because of a .pdf attachment. ] We have been bouncing ideas for a new mechanism to describe the behavior of function calls so that optimizers can be more aggressive at call sites. Currently, GCC supports the notion of pure/impure, const/non-const, but that is not enough for various cases. The main application for this would be stable library code like libc, that the compiler generally doesn't get to process. David sketched up the initial idea and we have been adding to it for the last few weeks. At this point, we have the initial design ideas and some thoughts on how we would implement it, but we have not started any actual implementation work. The main idea is to add a variety of attributes to describe contracts for function calls. When the optimizers read in the function declaration, they can take advantage of the attributes and adjust the clobbering effects of call sites. We are interested in feedback on the main idea and possible implementation effort. We would like to discuss this further at the Summit, perhaps we can organize a BoF or just get folks together for a chat (this came up after the Summit deadline). The design document is available at the new wiki page I set up for this project: http://gcc.gnu.org/wiki/FunctionBehavior Thanks. Diego.
Re: [RFC] Modeling the behavior of function calls
On Mon, Apr 28, 2008 at 3:04 PM, Diego Novillo <[EMAIL PROTECTED]> wrote: > [ Apologies if this comes out twice. I posted this message last week, >but I think it was rejected because of a .pdf attachment. ] > > We have been bouncing ideas for a new mechanism to describe the behavior > of function calls so that optimizers can be more aggressive at call > sites. Currently, GCC supports the notion of pure/impure, > const/non-const, but that is not enough for various cases. > > The main application for this would be stable library code like libc, > that the compiler generally doesn't get to process. > > David sketched up the initial idea and we have been adding to it for the > last few weeks. At this point, we have the initial design ideas and > some thoughts on how we would implement it, but we have not started any > actual implementation work. > > The main idea is to add a variety of attributes to describe contracts > for function calls. When the optimizers read in the function > declaration, they can take advantage of the attributes and adjust the > clobbering effects of call sites. > > We are interested in feedback on the main idea and possible > implementation effort. Roughly all of these attributes and ideas have been proposed before (by me, by zdenek, etc). Implementing the code to do stuff with the attributes is the easy part, and we've done some of it before (with a no_pointer_capture attribute, etc). The problem is three fold: 1. They all rely on slave labor for attributing headers for all the interesting platforms You can ameliorate some of this by having auto-annotations for the standard C library (ala builtins.def). 2. The number of interesting attributes is tremendous because of the amount of info you are trying to capture, and it is going to be very hard to get anyone to attribute an entire application, or even interesting functions, with all the right ones. 3. Most if not all of these attributes can be discovered by the compiler while we are compiling the libraries in question (or when your distro, etc does it), we just don't save it anywhere. It would be a huge boon if you included provisions for storing this info on the side somewhere, much like most linux distros these days keep debug info separate in /usr/lib/debug (and darwin allows you to put debug info in a differently named dir, etc). This would make most of the attributes not really necessary except for special cases, for the majority of our users. The last problem was easy, which is that nobody stepped up to solve all these problems :)
Are x86 builtin load functions "const"?
Hi, I noticed that x86 builtin load functions aren't defined with def_builtin_const. Is this an oversight or intentional? Thanks. H.J.
Re: Are x86 builtin load functions "const"?
On Mon, Apr 28, 2008 at 12:47 PM, H.J. Lu <[EMAIL PROTECTED]> wrote: > I noticed that x86 builtin load functions aren't defined > with def_builtin_const. Is this an oversight or intentional? I don't see why they can't be defined as const, the only time I can think of is when you have -fnon-call-exceptions turned on as they can trap. Why do you think this is wrong? Thanks, Andrew Pinski
Re: [RFC] Modeling the behavior of function calls
Diego Novillo wrote: [ Apologies if this comes out twice. I posted this message last week, but I think it was rejected because of a .pdf attachment. ] We have been bouncing ideas for a new mechanism to describe the behavior of function calls so that optimizers can be more aggressive at call sites. Currently, GCC supports the notion of pure/impure, const/non-const, but that is not enough for various cases. The main application for this would be stable library code like libc, that the compiler generally doesn't get to process. David sketched up the initial idea and we have been adding to it for the last few weeks. At this point, we have the initial design ideas and some thoughts on how we would implement it, but we have not started any actual implementation work. The main idea is to add a variety of attributes to describe contracts for function calls. When the optimizers read in the function declaration, they can take advantage of the attributes and adjust the clobbering effects of call sites. We are interested in feedback on the main idea and possible implementation effort. We would like to discuss this further at the Summit, perhaps we can organize a BoF or just get folks together for a chat (this came up after the Summit deadline). Diego, For the (all important :-)) java front end, it could be useful to have an attribute indicating that a function returns a non-null value. This is the case for the new operator which throws on allocation failures. Having this would allow VRP to eliminate a good bit of dead code for common java constructs. See also: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24825 Thanks, David Daney
Re: IRA for GCC 4.4
Peter Bergner wrote:
On Thu, 2008-04-24 at 20:23 -0400, Vladimir Makarov wrote:
Hi, Peter. The last time I looked at the conflict builder
(ra-conflict.c), I did not see the compressed matrix. Is it in the
trunk? What should I look at?
Yes, the compressed bit matrix was committed as revision 129037 on
October 5th, so it's been there a while. Note that the old square
bit matrix was used not only for testing for conflicts, but also for
visiting an allocno's neighbors. The new code (and all compilers I've
worked on/with), use a {,compressed} upper triangular bit matrix for
testing for conflicts and an adjacency list for visiting neighbors.
IRA also uses an adjacency lists for visiting conflict graph neighbors
(they contain conflict allocnos only of the same cover classes).
The code that allocates and initializes the compressed bit matrix is in
global.c. If you remember how a upper triangular bit matrix works, it's
just one big bit vector, where the bit number that represents the conflict
between allocnos LOW and HIGH is given by either of these two functions:
...
Thanks, Peter. That was clever and email is very enlightening. I have
analogous idea for more compact conflict matrix representation. IRA
builds allocno live ranges first (they are ranges of program points
where the allocno lives). I can use this information for fast searching
potential conflicts to sort the allocnos. Probably the matrix will be
even more compact because live ranges contain more detail info than
basic blocks where the local allocnos live. For example, the ranges
even can show that allocnos local in the same block will never
conflicts. It means that matrix even for fppp can be compressed.
I have also another question. I saw that sparset was used for the
conflict builder. I tried that too when I worked on YARA project. I
even wanted to contribute a generic sparset implementation. But I found
that in general case bitmaps are not worse the sparse sets and much
better if we take a needed space into account. May be you have another
impression? It would be very interesting for me to hear it. I found
that bitmaps have more advanced design than sparsets. I always wanted
to find inventors the bitmaps but never tracked them down.
The sparseset representation is only used for the allocnos_live set.
The old version was a bit vector to match up with the square bit matrix.
Since I changed that to save space, I had to reimplement allocnos_live.
Danny suggested I use a bitmap for that set and I tried it, but I found
for the particular usage of allocnos_live, a sparseset was noticeably
faster than bitmaps. I'll note that the main operations on allocnos_live
are to add allocnos to the set, remove allonos to the set and iterate over
the members of the set and occasionally clear the entire set. These are
all O(1) operations for the sparseset with fairly low constant factors
too. I didn't look too closely, but I'm guessing that the main problem
with bitmaps for this type of usage was the slower iterating over all
of the members of the set versus the sparseset.
Obviously, bitmaps are much better than sparsesets wrt space usage, so
you have to use them sparingly. You wouldn't want an array of these
things! :) But there are use cases where they work very very well.
The currently "live" set is one such use. Another use I have found
where they work well is in the needLoad set used by Briggs' allocator.
Whether you want/should use a sparseset really depends on the number
and type of set operations your particular usage will see. I'm sure
there are many usage cases where bitmaps are superior to sparsesets,
just like there are usage cases where sparsesets are superior. I know
that sounds like a cop-out, but it really does depend on how you're
going to use it.
I tried to use sparsets for the same purposes (only for maintaining and
processing allocnos currently living). But usage of sparsets for this
purposes gave practically nothing (I had to use valgrind lackey to see
the difference). Therefore I decided not to introduce the additional
data and use just bitmaps for this.
Sparsets already exists in a compiler. I am thinking about their usage
too. May be you have a benchmark where the sparsets give a visible
compiler speed improvement (my favorite was combine.i). I'd appreciate
if you point me such benchmark. It could help me to make a decision to
use sparsets.
Re: Are x86 builtin load functions "const"?
I am combining most x86 SIMD builtins into bdesc_sse_args. I only define store builtins with def_builtin. The rest will be defined with def_builtin_const., including load builtins. I want to make sure that it is OK to do so. Thanks. H.J. On Mon, Apr 28, 2008 at 12:50 PM, Andrew Pinski <[EMAIL PROTECTED]> wrote: > On Mon, Apr 28, 2008 at 12:47 PM, H.J. Lu <[EMAIL PROTECTED]> wrote: > > I noticed that x86 builtin load functions aren't defined > > with def_builtin_const. Is this an oversight or intentional? > > I don't see why they can't be defined as const, the only time I can > think of is when you have -fnon-call-exceptions turned on as they can > trap. > Why do you think this is wrong? > > Thanks, > Andrew Pinski >
Re: IRA for GCC 4.4
On Mon, 2008-04-28 at 16:01 -0400, Vladimir Makarov wrote: > Thanks, Peter. That was clever and email is very enlightening. I have > analogous idea for more compact conflict matrix representation. IRA > builds allocno live ranges first (they are ranges of program points > where the allocno lives). I can use this information for fast searching > potential conflicts to sort the allocnos. Probably the matrix will be > even more compact because live ranges contain more detail info than > basic blocks where the local allocnos live. For example, the ranges > even can show that allocnos local in the same block will never > conflicts. It means that matrix even for fppp can be compressed. You say you use your analogous idea now? Can you point me to the code? I thought I heard you (maybe someone else?) that your conflict information was much bigger than old mainline. If this is true and you are compacting the bit matrix like I am, why is it so big? > I tried to use sparsets for the same purposes (only for maintaining and > processing allocnos currently living). But usage of sparsets for this > purposes gave practically nothing (I had to use valgrind lackey to see > the difference). Therefore I decided not to introduce the additional > data and use just bitmaps for this. > > Sparsets already exists in a compiler. I am thinking about their usage > too. May be you have a benchmark where the sparsets give a visible > compiler speed improvement (my favorite was combine.i). I'd appreciate > if you point me such benchmark. It could help me to make a decision to > use sparsets. Yes, I added the sparseset implementation that has been in since gcc 4.3. Did you use my sparseset implementation or did you write your own for your tests? I don't recall which file(s) I saw the difference on. All I recall is I tried it both ways, saw a difference somewhere and promptly threw the slower code away along with which file(s) I saw the difference on. Sorry I can't be of more help. Given how sparsesets are implemented, I cannot see how they could ever be slower than bitmaps for the use of "live", but I can see how they might be faster. That said, if your allocator is spending enough time elsewhere, then I can easily imagine the difference being swamped such that you don't see any difference at all. Peter
Re: [RFC] Modeling the behavior of function calls
On Apr 28, 2008, at 12:04 PM, Diego Novillo wrote: [ Apologies if this comes out twice. I posted this message last week, but I think it was rejected because of a .pdf attachment. ] We have been bouncing ideas for a new mechanism to describe the behavior of function calls so that optimizers can be more aggressive at call sites. Currently, GCC supports the notion of pure/impure, const/non-const, but that is not enough for various cases. The main application for this would be stable library code like libc, that the compiler generally doesn't get to process. This is very interesting. One issue to consider: how do you plan to handle errno? There are a variety of compiler transformations that can be done on libm functions, even in the presence of errno. For an example (which occurs in spec2k), it is safe to transform: for (i = 0 .. 100) Val += i*sqrt(loopinvariant) into: tmp = sqrt(loopinvariant) for (i = 0 .. 100) Val += i*tmp This is safe because errno will still be set and the value that errno is set to is a function of the input value. Also, the value of errno is not otherwise changed in the body of the loop. Note that sqrt is not pure or const here because it sets errno. The wrinkle is "detecting that the loop body doesn't set errno". On many platforms, errno is a #define for something like "*__errno_func()". How do you plan to model this? -Chris
mapping liveness to variables
Hi guys, I am trying to get as close mapping from liveness information ( in bb->il.rtl->global_live_at_start ) to global and local variables as possible. Mapping to stack slots would be a good first step. What data structures should I look at use? What would be the best way to do it? Any suggestions appreciated, Gregory -- What would you attempt to do if you knew you could not fail?
Re: IRA for GCC 4.4
Peter Bergner wrote: On Mon, 2008-04-28 at 16:01 -0400, Vladimir Makarov wrote: Thanks, Peter. That was clever and email is very enlightening. I have analogous idea for more compact conflict matrix representation. IRA builds allocno live ranges first (they are ranges of program points where the allocno lives). I can use this information for fast searching potential conflicts to sort the allocnos. Probably the matrix will be even more compact because live ranges contain more detail info than basic blocks where the local allocnos live. For example, the ranges even can show that allocnos local in the same block will never conflicts. It means that matrix even for fppp can be compressed. You say you use your analogous idea now? Can you point me to the code? I thought I heard you (maybe someone else?) that your conflict information was much bigger than old mainline. If this is true and you are compacting the bit matrix like I am, why is it so big? I am currently working on bit matrix compression. It is not implemented yet. I hope it will be ready in a week. Live ranges were implemented long ago. They are quit important for fast transformation of regional IR into one region IR (before this I just rebuilt IR which was simple code but very time consuming). IRA can create additional allocnos because of live range splitting on the region borders and remove some of them during the transformation. The transformation is complicated because allocnos on upper levels of the region tree accumulate a lot of info (including conflicts) from allocnos on lower levels. I tried to use sparsets for the same purposes (only for maintaining and processing allocnos currently living). But usage of sparsets for this purposes gave practically nothing (I had to use valgrind lackey to see the difference). Therefore I decided not to introduce the additional data and use just bitmaps for this. Sparsets already exists in a compiler. I am thinking about their usage too. May be you have a benchmark where the sparsets give a visible compiler speed improvement (my favorite was combine.i). I'd appreciate if you point me such benchmark. It could help me to make a decision to use sparsets. Yes, I added the sparseset implementation that has been in since gcc 4.3. Did you use my sparseset implementation or did you write your own for your tests? I don't recall which file(s) I saw the difference on. All I recall is I tried it both ways, saw a difference somewhere and promptly threw the slower code away along with which file(s) I saw the difference on. Sorry I can't be of more help. I had own implementation which I used for YARA project. Given how sparsesets are implemented, I cannot see how they could ever be slower than bitmaps for the use of "live", but I can see how they might be faster. That said, if your allocator is spending enough time elsewhere, then I can easily imagine the difference being swamped such that you don't see any difference at all. Yes, that is true. I found that the code using sparsets (or bitmaps) are far away to be a bottleneck.
gcc-4.1-20080428 is now available
Snapshot gcc-4.1-20080428 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20080428/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.1 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch revision 134768 You'll find: gcc-4.1-20080428.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20080428.tar.bz2 C front end and core compiler gcc-ada-4.1-20080428.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20080428.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20080428.tar.bz2 C++ front end and runtime gcc-java-4.1-20080428.tar.bz2 Java front end and runtime gcc-objc-4.1-20080428.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20080428.tar.bz2The GCC testsuite Diffs from 4.1-20080421 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.1 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Are x86 builtin load functions "const"?
Load builtins can't be const since they may return different values on the same pointer value. H.J. On Mon, Apr 28, 2008 at 1:19 PM, H.J. Lu <[EMAIL PROTECTED]> wrote: > I am combining most x86 SIMD builtins into bdesc_sse_args. > I only define store builtins with def_builtin. The rest will be > defined with def_builtin_const., including load builtins. I want > to make sure that it is OK to do so. > > Thanks. > > H.J. > > > On Mon, Apr 28, 2008 at 12:50 PM, Andrew Pinski <[EMAIL PROTECTED]> wrote: > > On Mon, Apr 28, 2008 at 12:47 PM, H.J. Lu <[EMAIL PROTECTED]> wrote: > > > I noticed that x86 builtin load functions aren't defined > > > with def_builtin_const. Is this an oversight or intentional? > > > > I don't see why they can't be defined as const, the only time I can > > think of is when you have -fnon-call-exceptions turned on as they can > > trap. > > Why do you think this is wrong? > > > > Thanks, > > Andrew Pinski > > >
Re: Are x86 builtin load functions "const"?
On Mon, Apr 28, 2008 at 5:16 PM, H.J. Lu <[EMAIL PROTECTED]> wrote: > Load builtins can't be const since they may return different values on > the same pointer value. They should be pure though. -- Pinski
Re: [switch conv] Bootsrap error because of the (CERT) pointer wraparound warning
Martin Jambor <[EMAIL PROTECTED]> writes: > I've been rebootstrapping my switch conversion patch (which is still > waiting for review) to make sure it still works. Unfortunately, it > did not. The error given was the following and I believe this is the > warning introduced by Ian as a response to the infamous CERT advisory. > (Furthermore, I am getting this warning at revision 134664 but I was > not getting it at 134135.) > > --- Compiler output --- > /cswtch/gcc/. -I/abuild/mjambor/cswtch/gcc/../include > -I/abuild/mjambor/cswtch/gcc/../libcpp/include > -I/abuild/mjambor/cswtch/gcc/../libdecnumber > -I/abuild/mjambor/cswtch/gcc/../libdecnumber/bid -I../libdecnumber > /abuild/mjambor/cswtch/gcc/tree-switch-conversion.c -o > tree-switch-conversion.o > cc1: warnings being treated as errors > /abuild/mjambor/cswtch/gcc/tree-switch-conversion.c: In function > 'process_switch': > /abuild/mjambor/cswtch/gcc/tree-switch-conversion.c:182: error: assuming > signed overflow does not occur when assuming that (X - c) > X is always false > make[3]: *** [tree-switch-conversion.o] Error 1 > - End - The warnings I added for the CERT advisory say "assuming pointer wraparound does not occur" You are running into one of the older signed overflow warnings. > 1. Am I doing something wrong? No. > 2. How can I get rid of the error and bootstrap my code? Make branch_num an unsigned int. > 3. If the warning is really bogus, should we perhaps turn it off for > bootstrap, (or turn it off by default in general and leave it > there for people who want to check their code after reading CERT > advisories)? The basic criteria for -Wall is: could indicate a problem, easy to rewrite code to avoid. You've encountered a false positive, but it's easy to avoid. Ian
Re: IRA for GCC 4.4
On Mon, 2008-04-28 at 18:07 -0400, Vladimir Makarov wrote: > I am currently working on bit matrix compression. It is not implemented > yet. I hope it will be ready in a week. Ahh, ok. Well, hopefully the code I wrote on the trunk is useful for IRA. If you have questions about it, let me know, or if you want me to look into it on IRA, just point me to your current code that does this and I'll try and take a look when I have some free cycles. I'll note that the real key to eliminating the space from the bit matrix isn't that we know two allocnos do not interfere, but rather that we know we'll never test for whether they conflict or not. Since our definition of conflict is "live at the definition of another", that simply translates into, if they're never simultaneously live, then we'll never call any bit matrix routines asking whether they conflict or not, so we don't need to reserve space for any conflict info. The fact that local allonocs from different blocks are never simultaneously live was just a very easy and inexpensive property to measure. If your live range info can easily and cheaply partition the allocnos into sets that are and are not live simultaneously, then you should be able to see some further reductions over what I'm seeing...which I think I've shown, can be considerable. Peter
Re: IRA for GCC 4.4
Vladimir Makarov wrote: Peter Bergner wrote: On Mon, 2008-04-28 at 16:01 -0400, Vladimir Makarov wrote: Thanks, Peter. That was clever and email is very enlightening. I have analogous idea for more compact conflict matrix representation. IRA builds allocno live ranges first (they are ranges of program points where the allocno lives). I can use this information for fast searching potential conflicts to sort the allocnos. Probably the matrix will be even more compact because live ranges contain more detail info than basic blocks where the local allocnos live. For example, the ranges even can show that allocnos local in the same block will never conflicts. It means that matrix even for fppp can be compressed. You say you use your analogous idea now? Can you point me to the code? I thought I heard you (maybe someone else?) that your conflict information was much bigger than old mainline. If this is true and you are compacting the bit matrix like I am, why is it so big? I am currently working on bit matrix compression. It is not implemented yet. I hope it will be ready in a week. vlad, this seems like the wrong way to go. i understand that you feel that it is a sign of weakness to use someone else's fully debugged and functional code rather than writing it from scratch, but every one else feels that (a) you could better spend your time working on the other issues that will be relevant to getting this thing in and (b) none of the other reviewers looks forward to just seeing a lot of the same code only different. Kenny
Fwd: gcc cross compiler problem
-- Forwarded message -- From: NoFirst NoLast <[EMAIL PROTECTED]> Date: Mon, Apr 28, 2008 at 6:46 PM Subject: gcc cross compiler problem To: gcc@gcc.gnu.org Hello gcc, I am running into a problem when I am trying to compile GCC to run on a i686-pc-linux-gnu (host) but to build source code for target, x86_64-pc-linux-gnu. I have build binutils first with the following configure parameters: configure --target=x86_64-pc-linux-gnu --prefix==mydirectoryforinstall. After I make and install binutils into my own directory, I build gcc using the following configure parameter: configure --prefix=mygccdirectoryfor install --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,fortran,ada --disable-dssi --enable-plugin --with-cpu=generic --host=x86_64-pc-linux-gnu Once I did that, I perform a make all. Eventually, gcc starts to build genmodes.c at which point I get the following errors: /tmp/ccwdhaLJ.s: 2073: Error: Suffix or operands invalid for 'pop' /tmp/ccwdhaLJ.s: 2075: Error: Suffix or operands invalid for 'pop' /tmp/ccwdhaLJ.s: 2077: Error: Suffix or operands invalid for 'pop' /tmp/ccwdhaLJ.s: 2094: Error: Suffix or operands invalid for 'push' There are a lot of the these error messages. I only pasted a few lines. I am using GCC version 4.3.0 and binutils 2.18. If you could giving a helping hand, I would appreciate it very much. Thanks, Scott
Re: [RFC] Modeling the behavior of function calls
Diego Novillo wrote: We have been bouncing ideas for a new mechanism to describe the behavior of function calls so that optimizers can be more aggressive at call sites. Currently, GCC supports the notion of pure/impure, const/non-const, but that is not enough for various cases. Fortran supports to mark function arguments as INTENT(IN), i.e. they are not modified by the function, or INTENT(OUT), i.e. the variable is set in the function - thus an assignment of a variable just before the function call can be optimized away. (Especially, supporting INTENT(IN) would be useful as by default all variables get passed by reference in Fortran. See PR 23169. Tobias PS: Fortran has also the notion of PURE functions. And all objects which are passed by reference or are ALLOCATABLE match C's restricted pointer, unless they have the (pointer) TARGET or the POINTER attribute - only then the same memory can be reached via more than one variable name.
