Re: Bootstrap failure on Linux/x86-64 in Ada

[Bonzini]

Hi Andreas, this should be related to the fixes to AIX toplevel
bootstrap.  My apologies if it is the cause.

Can you try adding these lines to the toplevel Makefile.tpl?

ADAFLAGS = -W -Wall -gnatpg -gnata
ADAFLAGS_FOR_TARGET = -W -Wall -gnatpg -gnata

and changing = to += in config/mt-ppc-aix?

Arnaud, it seems strange that "required" flags like -gnatpg are on
ADAFLAGS rather than the makefile rules.  -c is not in CFLAGS, for
example.  Is it possible that you don't want -gnatpg in some cases?

Paolo

Re: building gcc

[Paolo Bonzini]

In particular, I was just wondering how do compile GCC with debug. Not
how to debug it. I tried CFLAGS="-g" ./configure ..., but it still
compiled with gcc -O2 -g. Anyways, if anyone knows a helpful configure
trick that will help get me ready to debug gcc, please let me know.


By default, GCC bootstraps itself, and after the first stage it always 
compiles itself with optimization enabled.  So what you need is


./configure --enable-languages=c,c++ --disable-bootstrap
make CFLAGS=-g

(or equivalently, with CFLAGS=-g passed to configure).

Paolo

Re: Implicit conversions between vectors

[Paolo Bonzini]

This lack of type safety is unsettling, and I wonder if it should be fixed
with a patch along the lines of the (not yet fully tested) one below.  Does
that sound reasonable?  It seems right to try to fix the generic code here,
even though the testcase in hand is target-specific.  If this approach
is unreasonable, I guess some target-specific hooks will be needed.


I'm almost sure this is a regression, and older versions of GCC 
implemented exactly what you propose.


Paolo

Re: Abt SIMD Emulation

[Paolo Bonzini]

For targets which doesn't have simd hardware support like fr30 ,  simd stuff is 
emulated?
Is there some flags/macros in gcc to indicate that?


To indicate what?


I guess to indicate that the vector is emulated.  The TYPE_MODE of the 
vector type, in that case, is BLKmode or an integer mode.



How is it done in other targets which deosnt have the hardware support?


In the obvious tedious way: as a loop over the elements.


With the additional optimization that & | ^ ~ can be done word-by-word, 
+ - can use bit-twiddling if there are at least 4 elements by word 
(otherwise it is not profitable), and that smaller SIMD instructions 
(e.g. 2 8-byte SIMD instructions to emulate a 16-byte vector) may be 
used if supported.


See tree-ssa-vect-generic.c for the gory details.

Paolo

GMP test

[Paolo Bonzini]

It seems that the GMP test is always run, even when installing binutils 
or gdb.


You probably need something like

if test -d ${srcdir}/gcc && test x$have_gmp != xyes; then
   ...
fi

but I think that the whole test now belongs in the GCC subdirectory, not 
in the toplevel (it was anyway a hack for the sake of disabling Fortran).


Sorry for not speaking up earlier,

Paolo

Re: GMP test

[Paolo Bonzini]

if test -d ${srcdir}/gcc && test x$have_gmp != xyes; then
...
fi

but I think that the whole test now belongs in the GCC subdirectory, not 
in the toplevel (it was anyway a hack for the sake of disabling Fortran).


Moving it is not really a good thing anyways as you are able to configure
and then do a "make -j3" and it is hard to figure out why the build fail
because you don't have the correct version of GMP/MPRF.


Maintainability first.  If something fails with parallel make, and is 
reproducible with plain "make" (i.e. doesn't screw up the build 
directory), I don't see a reason not to move it.  You'd do "make" anyway 
to check if a dependency is missing, wouldn't you?


Paolo

Re: GMP test

[Paolo Bonzini]

But this is a different case as this error is for users rather than developers.
So instead of getting an error early before compiling, we get an error 10 to 20
minutes later and users get upset that they get an error this late for something
which could have been found early on.


That is a problem with running configure at make time in general.  If we 
add some kind of plugin system for configure fragments, it might fly. 
As the thing stands now, it is not a good-enough reason to pollute the 
toplevel code.


We are not maintainers anyway, so we cannot ask anybody to do anything. 
 Kaveh might or might not prepare a patch to move the test, and if he 
does, it will be up to the maintainers to decide who they agree with.


Paolo

Re: GMP test

[Paolo Bonzini]

I'm more content with the gmp check at the top level and don't plan to
submit a change to that.  Although I agree if this configure is shared
between binutils, gdb and gcc, and you're not compiling gcc, then it
shouldn't require gmp.  So maybe something like your "test -d" fragment
would be appropriate.  Would you please submit that one line change for a
configury maintainer to review?

If I have to do it, I'll prepare the patch to move the test instead.

Paolo

Re: GMP test

[Paolo Bonzini]

Andrew Pinski wrote:

On Wed, 2006-10-25 at 13:32 +0900, Paolo Bonzini wrote:
  

I'm more content with the gmp check at the top level and don't plan to
submit a change to that.  Although I agree if this configure is shared
between binutils, gdb and gcc, and you're not compiling gcc, then it
shouldn't require gmp.  So maybe something like your "test -d" fragment
would be appropriate.  Would you please submit that one line change for a
configury maintainer to review?
  

If I have to do it, I'll prepare the patch to move the test instead.



Again this is not user friendly to move this test


Not as bad as you put it, if installing and typing "make" solves the 
issue (either for zip/unzip or gmp/mpfr, it is the same).  I'll let the 
maintainers decide.


Paolo

[PING] fwprop in 4.3 stage 1?

[Paolo Bonzini]

Given that Roger started the ball rolling, by approving Steven's 
-fcse-skip-blocks patch, I'll ping the discussion...


http://gcc.gnu.org/ml/gcc-patches/2006-10/msg01066.html

Paolo

Re: build failure, GMP not available

[Paolo Bonzini]

There is also "fink" (fink.sf.net), which i believe would provide a
new enough gmp, but i am not positive.


Yes, fink packages "gmp gmp-shlibs libmpfr1-dev libmpfr1-shlibs" provide 
all that is needed.


Paolo

Re: build failure, GMP not available

[Paolo Bonzini]

I wouldn't object to that.  It's a bit more build-system complexity, but 
if it makes it easier for people, then it's worth it.


Actually, since we are at it, I would like to have toplevel configure 
automatically symlink "foo-1.2.3" to "foo".  This way, untarring 
gmp/mpfr (and maybe also bison/texinfo/whatever) would magically work.


I have not done this until now because binutils, gdb and other things 
using the gcc/src build system would not work in this scheme. :-(


Paolo

Re: [PING] fwprop in 4.3 stage 1?

[Paolo Bonzini]

I believe the appropriate next step is to freshen these patches against
mainline, and re-bootstrap and regression test them.


Sure, I just wanted to make sure that it was worth the cycles.  I'll do 
so as soon as possible.


Thanks,

Paolo

Re: Handling of extern inline in c99 mode

[Paolo Bonzini]

According to the proposal, we will restore the GNU handling for
"extern inline" even when using -std=c99, which will fix the problem
when using glibc.


I am probably overlooking something, but if the only problematic system 
is glibc, maybe this can be fixed with a fixincludes hack?


Paolo

Re: Even stricter implicit conversions between vectors

[Paolo Bonzini]

Ian Ollmann wrote:


Assuming I understand the proposal properly, this sounds to me like it 
amounts reversing the change  we experienced in the Apple GCC from 3.3 
-> 4.0.  Type checking became a lot more lax for us in 4.0.


This was a bug and has been fixed recently.  I cannot recall if the fix 
has been backported all the way up to 4.0.


Paolo

Re: Even stricter implicit conversions between vectors

[Paolo Bonzini]

Assuming I understand the proposal properly, this sounds to me like 
it amounts reversing the change  we experienced in the Apple GCC 
from 3.3 -> 4.0.  Type checking became a lot more lax for us in 4.0.


This was a bug and has been fixed recently.  I cannot recall if the 
fix has been backported all the way up to 4.0.


Which fix are you thinking of here?  My previous one for rejecting
implicit conversions between vector types between differing numbers
of subparts hasn't been submitted as a patch yet, but has pretty much
been approved in principle.

Oops, yes, that was it.  Does it have a PR number?

Paolo

Re: compiling very large functions.

[Paolo Bonzini]

Kenneth Zadeck wrote:

I think that it is time that we in the GCC community took some time to
address the problem of compiling very large functions in a somewhat
systematic manner.


While I agree with you, I think that there are so many things we are 
already trying to address, that this one can wait.  I think we've been 
doing a very good job on large functions too, and I believe that authors 
of very large functions are just getting not only what they deserve, but 
actually what the expect: large compile times (superlinear).


I think that the most obvious O(n^2) time spots have been cleared 
(dataflow is practically never O(n^2) with a good equation solver), and 
we can live with the remaining O(n^2) space spots since we have a bit, 
or half a bit in front of the n^2.  Actually I just mentioned that 
PR28701 is worth a check on dataflow-branch, but I don't think it will 
be worse than what we have now on mainline (because df is also used in 
liveness, and the memory that fwprop eats might be reused), and it 
should be possible to fix outstanding problems easily (e.g. with bitmap 
obstacks).


Paolo

Re: compiling very large functions.

[Paolo Bonzini]

While I agree with you, I think that there are so many things we are 
already trying to address, that this one can wait.  I think we've been 
doing a very good job on large functions too, and I believe that authors 
of very large functions are just getting not only what they deserve, but 
actually what the expect: large compile times (superlinear).


Not too mention, that these huge functions are usually central to the 
program.  If GCC decided that it is not worth optimizing the 
machine-generated bytecode interpreter of GNU Smalltalk, for example, I 
might as well rewrite it in assembly (or as a JIT compiler).  Same for 
interpret.cc in libjava, though it is a tad smaller than GNU Smalltalk's 
interpreter.


Unlike the authors of other VM's, I have no problem writing code so that 
the *latest* version of GCC will do its best, instead of complaining 
that GCC compiles my code worse on every release.  So, I am ok with GCC 
doing stupid things because of bugs that I/we can fix, but not with GCC 
just giving up optimization on code that has always been compiled 
perfectly (in one/two minutes for about 30,000 lines of 
machine-generated code, despite being chock-full of computed gotos), 
that *can* be optimized very well, and that is central to the 
performance of a program.


Paolo

Re: Problem with listing i686-apple-darwin as a Primary Platform

[Paolo Bonzini]

Jack Howarth wrote:

I would more worried about the second issue if gcc 4.2 was
remotely close to release. However at the rate regressions are
being fixed (or not) in gcc 4.2 branch, I wouldn't hold my
breath as to which is released first (gcc 4.2 or Leopard).
Once Leopard is released, Darwin8 will become the 'previous'
release and the problem on Darwin PPC will go away.


All this would be fine, if it was not that (correct me if I'm wrong, I'd 
love to be corrected) you have to pay to get the latest Mac OS.  That 
may be a very good reason why some people are stuck with 10.3.9 for 
example.  If I had to do it with my own money, I would not have spent 
120 euros for Tiger.


Paolo

Re: Volatile operations and PRE

[Paolo Bonzini]

At a wild guess, maybe strip_useless_type_conversions() is doing
something Bad.


Almost there.  It looks like strip_useless_type_conversions is not used, 
and then something Bad happens.


The following patch fixes it, but it's completely untested.

2006-11-07  Paolo Bonzini  <[EMAIL PROTECTED]>

* gimplify.c (fold_indirect_ref_rhs): Use
STRIP_USELESS_TYPE_CONVERSION rather than STRIP_NOPS.

Index: ../../gcc/gimplify.c
===
--- ../../gcc/gimplify.c(revision 118481)
+++ ../../gcc/gimplify.c(working copy)
@@ -3207,7 +3207,7 @@ fold_indirect_ref_rhs (tree t)
   tree sub = t;
   tree subtype;

-  STRIP_NOPS (sub);
+  STRIP_USELESS_TYPE_CONVERSION (sub);
   subtype = TREE_TYPE (sub);
   if (!POINTER_TYPE_P (subtype))
 return NULL_TREE;

If anybody could regtest it, this is a regression from 3.3, likely to be 
present in all 4.x branches.


Paolo

Re: bootstrap on powerpc fails

[Paolo Bonzini]

Maybe in another six years cpu improvements will outpace gcc bootstrap
times enough to reconsider.


We'll have 60 cores per CPU, and 1 minute after invoking "make" we'll be 
cursing how much it takes for insn-attrtab.c to finish compiling.  :-)


Paolo

Re: make clean no longer works properly?

[Paolo Bonzini]

Now I get:

make[1]: *** No rule to make target `clean'.  Stop.
make: *** [clean-stage4-gcc] Error 2


It turns out I had a fix already approved, but never checked in.  Fixed 
(and my apologies).


Paolo

Re: how to load a cfg from a file by tree-ssa

[Paolo Bonzini]

Rob Quill wrote:

I haven't looked into this yet, but as I think I may need to be able
to do something similar, is it possible to parse the cfg file that is
given out, and build a C structure like that?


It seems to me that the answer had been already given in the message you 
fully quoted: we cannot help you.


And, by the way, I suggest not to top post: see 
http://en.wikipedia.org/wiki/TOFU for more info.


Paolo


> but i don't know how to load that file in a structure.
> I.e. i have the file .cfg builded by gcc with the option
> -fdump-tree-cfg and i want to load this file in a C structure so i can
> manipulate it.

There is no such functionality in GCC.  GCC can only build the CFG from
source code, and can only do so to produce assembly language output.

Re: how to load a cfg from a file by tree-ssa

[Paolo Bonzini]

Rob Quill wrote:

On 24/11/06, Paolo Bonzini <[EMAIL PROTECTED]> wrote:

Rob Quill wrote:
> I haven't looked into this yet, but as I think I may need to be able
> to do something similar, is it possible to parse the cfg file that is
> given out, and build a C structure like that?

It seems to me that the answer had been already given in the message you
fully quoted: we cannot help you.


I don't wish to labour the point, but what I am trying to understand
is whether it is impossible or just impractical. 


It is neither impossible, nor impractical.  Rather, it is irrelevant as 
for as GCC is concerned: it is not within the scope of a compiler to 
read back the CFG that (it prints them out to aid debugging), and this 
is why GCC does not provide APIs to do so.


All you have to do, is understand the output format (either by looking 
at tree-cfg.c or by "reverse engineering" it yourself), and write a 
corresponding parser.  The C structs you will use may be based on those 
in GCC (see basic-block.h) but probably will not because these will 
bring many other details on the GCC intermediate representation.


Paolo

Re: machine-dependent Passes on GIMPLE/SSA Tree's?

[Paolo Bonzini]

Note that in general we're trying to avoid introducing target dependent
stuff into the gimple/SSA optimizers.  We should consider the
vectorization code as the exception rather than the rule for this
kind of thing.


Well, these exceptions are starting to pile up however.  Besides ivopts, 
which is the very last pass in the tree optimization pipeline, the 
tree-ssa-math-opts.c pass to optimize reciprocals is already using 
optabs to guide its optimizations.  Every now and then, also, I'm 
working on moving switch statement expansion to the tree level (which is 
also target dependent).  This will allow VRP to cut dead parts of a 
switch statement's decision tree, for example, which would be close to 
impossible on RTL, unless you want to rewrite VRP there.


Paolo

Re: Objects in c++ and objc

[Paolo Bonzini]

Come Lonfils wrote:

Hi,

I need precise information about how GCC store the objects for c++
and objective-C


For C++, the source of information is the C++ ABI.  See 
http://www.codesourcery.com/cxx-abi/


For Objective-C, I don't know and I suspect the answer is that the 
information is only in the source code to libobjc, which however is 
pretty manageable.


paolo

Re: strict aliasing benefit examples

[Paolo Bonzini]

int f(int *a, float *b)
{
  *a = 1;
  *b = 2.0;
  return *a == 2;
}



Problem: people don't write code that way. (well I hope not)
People declare a few local variables, load them with data via
the pointers, do stuff with the local variables, then save back
the results via the pointers.

So that won't convince many Visual Studio 2005 fans. :-(


Then, the answer is that GCC's stronger aliasing allows you to use one 
line of code instead of three.


Consider that most people can only write at most ~50 SLOC/day (including 
debugging and documentation), with a stunning independence from the 
programming language and programming style.  If you take it with the 
necessary grain of salt, this is quite an argument.


Paolo

Re: strict aliasing benefit examples

[Paolo Bonzini]

for(i = 0;i<*t;i++)
  *f += 1.0;


This one is pretty realistic, especially if you consider C++ and inlining:

struct s {
  int size;
  float *data;
};

void f(struct s *d, struct s *s)
{
  int i;
  for (i = 0; i < s->size; i++)
d->data[i] += s->data[i];
}

can be optimized by GCC to this:

lwz r0,0(r4)
cmpwi cr7,r0,0
blelr- cr7
lwz r3,4(r3)
mtctr r0
lwz r4,4(r4)
li r9,0
L4:
slwi r2,r9,2
addi r9,r9,1
lfsx f0,r3,r2
lfsx f13,r4,r2
fadds f0,f0,f13
stfsx f0,r3,r2
bdnz L4
blr

Note that the only load in the loop is for vec->data[i]. vec->size is 
known not to change during the loop.


With an "int *data" it is impossible to disambiguate.  However, 
base+offset alias analysis can disambiguate the accesses to s->size and 
d->data[i] if struct s is defined as follows:


struct s {
  int size;
  int data[1];
};

Paolo

Re: strict aliasing benefit examples

[Paolo Bonzini]

I guess I can imagine that macro expansion might result in some
cases where strict-aliasing is of benefit. Most people fail to use a
temporary in a macro, probably because __typeof__ is gcc-only.
I can probably fit 20 lines of code on a readable slide. Ideas?


In C++, this:

f (vector  &vec)
{
  vector ::iterator it;
  for (it = vec.begin (); it != vec.end (); it++)
...
}

will expand exactly to

f (vector  *vec)
{
  float *it;
  for (it = vec->data; it != vec->data + vec->size; it++)
...
}

There are no macros involved.  You just need to find whether vec->size 
is invariant.  GCC is nowhere near performing whole program 
optimization, so it has to punt quite often (plus there is the issue 
with "char" aliasing everything, which however can be worked around by 
field-sensitive alias analysis), but you have to start from something.



BTW, there are more normal programming habits that defeat
type-based alias analysis. People pick data types by habit.
Mostly, people will use the same type for nearly everything.


That's a problem with C, not with GCC.  Plus, in the nastiest 
template-metaprogramming-heavy math code this is not necessarily an 
obstacle.  Everything is inlined in the main loop, so there is no need 
for whole program optimization.  You use int or long for counters, float 
or double for data: that's enough for type-based alias analysis to work 
egregiously, coupled with some base/offset alias analysis to 
disambiguate between different data structures used at the same time.


Richard Guenther can provide data for his favorite application (a 
physics simulation) without and with -fstrict-aliasing.  I bet it makes 
a difference (and if not, it's a bug in GCC).


Paolo

libffi compilation failure on Solaris 10?

[Paolo Bonzini]

This bug, documented in the installation instructions:

"GCC 3.3 triggers a bug in version 5.0 Alpha 03/27/98 of the Sun 
assembler, which causes a bootstrap failure when linking the 64-bit 
shared version of libgcc. A typical error message is:


 ld: fatal: relocation error: R_SPARC_32: file 
libgcc/sparcv9/_muldi3.o:

   symbol :  offset 0x7ec133e7 is non-aligned.

This bug has been fixed in the final 5.0 version of the assembler.

A similar problem was reported for version Sun WorkShop 6 99/08/18 of 
the Sun assembler, which causes a bootstrap failure with GCC 4.0.0:


 ld: fatal: relocation error: R_SPARC_DISP32:
   file .libs/libstdc++.lax/libsupc++convenience.a/vterminate.o:
 symbol : offset 0xfccd33ad is non-aligned

This bug has been fixed in more recent revisions of the assembler."

apparently can also be triggered by libffi on Solaris 10.  See 
http://www.mail-archive.com/g-wrap-dev@nongnu.org/msg00045.html and 
http://mail.python.org/pipermail/python-bugs-list/2006-July/034400.html 
for build logs.


Anybody knows what are the affected releases in this case, whether it is 
an assembler or linker bug, and whether there is a workaround?  I wonder 
if this is caused by a newer version that those in the installation 
instruction.


Ciao,

Paolo

Re: block reordering at GIMPLE level?

[Paolo Bonzini]

Looking at the backend optimizations, it is clear that some modify the 
CFG. But my understanding is that loop optimizations and unrolling are 
also being moved to GIMPLE. I do not know about others.


Loop optimizations are performed on GIMPLE only because they are really 
hard to perform on RTL (in the case of ivopts) or because they are 
high-level optimizations (such as loop interchange).


There are indeed some parts of the back-end that could be done on GIMPLE 
too (for example load PRE).


Could it be that sometime all the optimizations that modify the CFG are 
run on GIMPLE?


Some more, for sure.  For example, I'm working in my spare time on 
moving switch statement expansion to trees so that the tree passes can 
see the decision trees.  But not all of them; GCSE for example can 
modify the CFG (it will be preceded by a critical edge split pass on RTL 
in the future).


Is there any plan/interest in having a block layout pass running at 
GIMPLE level?


I don't think so, especially considering that tree->RTL expansion itself 
modifies the CFG.  But basic block reordering should be pretty easy to 
port from RTL to trees for your own treee.


Paolo

Re: CEA (France) has signed assignment of copyright to FSF on GCC

[Paolo Bonzini]

Personally, I think the list should be somewhere that *all* gcc
maintainers have access to (not all of us have gnu.org accounts).


I agree that in principle, GCC "code maintainers" would need to check it 
after approving a patch of somebody who has no CVS access.  But the FSF 
does not care about who can commit what and under what conditions, and 
in fact several maintainers (not random people who have access to the 
subversion repo!) are complete unknowns to the FSF because it's their 
employer who signed the copyright assignment.


The GCC "FSF-appointed maintainer" is the SC, and in fact several people 
on the SC have access to the list.


There could be privacy problems too. I don't know the relevant 
legislation, but the list includes personal data (year of birth, 
citizenship, employer) and, in Italy, I would have to sign a form if I 
had access to such data.  The legislation in the US, however, is 
probably very different: for example, the copyright assignment form 
would have a separate signature, or a click-through if done via web, 
where you accept that the FSF keeps the data on a computer in order to 
process the assignment.


Paolo

Re: CEA (France) has signed assignment of copyright to FSF on GCC

[Paolo Bonzini]

Paolo Bonzini wrote:

The legislation in the US, however, is
probably very different: for example, the copyright assignment form 
would have a separate signature, or a click-through if done via web, 
where you accept that the FSF keeps the data on a computer in order to 
process the assignment.


Just to be clear, this example refers to Italy too.

Paolo

Re: Announce: MPFR 2.2.1 is released

[Paolo Bonzini]

That idea got nixed, but I think it's time to revisit it.  Paolo has
worked out the kinks in the configury and we should apply his patch and
import the gmp/mpfr sources, IMHO.


Note that these two issues (my patch, which by the way was started and 
tested by Nick Clifton, and whether to import the sources), are 
completely separate.


Paolo

Re: g++ doesn't unroll a loop it should unroll

[Paolo Bonzini]

loop anyway... you C++ people tend to overtax compiler with
optimizations. Is it really necessary to do (i == j) * factor
when (i == j) ? factor : 0 is easier for compiler to grok?


Of course I tried it. It's even slower. Doesn't help the compiler unroll the 
loop, and now there's a branch at each iteration.


This is another compiler bug.  Note however, that if I want to use 
oldskool tricks to remove ?:, I would instead do -(i == j) & factor.


The compiler should be able to transform the ?: expression to the faster 
form (and to transform the latter into ?: on architectures where it's 
better) but it does this quite late in the compilation.  It can happen 
that things are screwed up by the time we reach that part of the 
optimization pipeline, and the ?: idiom is not recognized anymore.


We are currently discussing including ?: in the compiler's intermediate 
representation, instead of representing it as an "if" statement; this 
might be a case where it helps.


Paolo

Re: configuration options policy (at toplevel or only inside gcc/)?

[Paolo Bonzini]

Note that configure options beginning with --with and --enable are
passed from the top level configure script to the subdirectory
configure scripts.  So the user just uses all the options at the top
level, and the subdirectories will see them.


I did notice this, but it seems to me (maybe I am wrong) that there is
no generic machinery which passes the --with & --enable of the
top-level configure to the configure in gcc subdirectory. There is
some code in Makefile.tpl for this, but each such option has to be
explicitly & individually processed. 


No, see how host_configure_args is set in Makefile.in.


In other words for adding new configure options to gcc/ subdirectory,
we have to hack the gcc/configure.ac file, the toplevel configure.in
and the toplevel Makefile.tpl and this should be done for every
user-visible options. Otherwise, it is an option which is not visible
to the user. If I hack only gcc/configure.ac, I am adding an option
which the user do not see. Is this correct?


No, you are adding an option that will not be listed in ./configure 
--help.  So you document that option in install.texi.



I agree that new options should only be added at the appropriate
level, but there is one disadvantage: top level configure --help will
not display them.  But then configure --help is kind of useless anyhow
since it has so much boilerplate, so this is not a significant
problem.


Still, what is the build procedure then? Do we expect users to type
two configure commands?


No.  Options are passed down automatically from the toplevel configure 
to the ones below.  This is true of any configure script, even though 
the gcc/binutils/gdb/cygwin/newlib/... toplevel configure script has 
some extra involutions.



At last I do not understand why the MPFR & GMP stuff which has been
discussed a lot is not already under the above scheme? Why is it cheched at
toplevel and not only in gcc/ ? AFAIK the #include  appears only in
gcc/real.h

It's at the top level because the original implementation envisioned
support for putting MPFR and GMP in the tree, alongside of the
directories gcc, libcpp, etc.  That may still happen.


Thanks for the explanation. But I thought it has been firmly decided
to keep GMP & MPFR outside!


We might still allow other people to put gmp and mpfr in the same source 
tree as gcc, even though it was decided to keep them out of the gcc tarball.

Re: Question on BOOT_CFLAGS vs. CFLAGS

[Paolo Bonzini]

http://gcc.gnu.org/onlinedocs/gccint/Makefile.html
http://gcc.gnu.org/install/build.html


I read that, could you please quote the part that documents the current 
behavior.


If you wish to use non-default GCC flags when compiling the stage2 and 
stage3 compilers, set BOOT_CFLAGS on the command line when doing `make'. 
Non-default optimization flags are less well tested here than the 
default of `-g -O2', but should still work.



Let me offer a counter quote:


The counter quote is obviously wrong, thanks for the report.

Paolo

Re: Question on BOOT_CFLAGS vs. CFLAGS

[Paolo Bonzini]

The counter quote is obviously wrong, thanks for the report.


Why it is important to not have CFLAGS influence the build product?  The 
standard, is for it to so influence the build product.  Why is it 
important for gcc to not follow the standard?


Because when I happened to change well-established operation modes, in 
the past, I encountered a lot of resistance, and I don't have the time 
resources to start this one more now.


Paolo

Re: Paolo Bonzini appointed build system maintainer

[Paolo Bonzini]

Mark Mitchell wrote:

Paolo --

The GCC SC has appointed you as a co-maintainer of the build machinery.

Please add an appropriate MAINTAINERS entry.

Congratulations, and thank you for accepting this position!


Thanks very much, I committed the following.

2006-12-19  Paolo Bonzini  <[EMAIL PROTECTED]>

* MAINTAINERS: Add myself as build system maintainer.

Index: MAINTAINERS
===
--- MAINTAINERS (revision 120045)
+++ MAINTAINERS (working copy)
@@ -186,6 +186,7 @@ basic block reordering  Jason Eckhardt  j
 i18n   Philipp Thomas  [EMAIL PROTECTED]
 i18n   Joseph Myers[EMAIL PROTECTED]
 diagnostic messagesGabriel Dos Reis 
[EMAIL PROTECTED]

+build machinery (*.in) Paolo Bonzini   [EMAIL PROTECTED]
 build machinery (*.in) DJ Delorie  [EMAIL PROTECTED]
 build machinery (*.in) Nathanael Nerode[EMAIL PROTECTED]
 build machinery (*.in) Alexandre Oliva [EMAIL PROTECTED]

Paolo

Re: GCC optimizes integer overflow: bug or feature?

[Paolo Bonzini]

By the way, as I've tried to describe here:

variable range tracking can result in reintroduction of
supposedly-fixed security vulnerabilities. 8-(


Interesting read.  I agree with the proposed fix; however, note that GCC 
does not make the result of overflowing signed left-shifts undefined, 
exactly because in this case the overflow is relied upon by too many 
existing programs (and also because left shifts are inherently a bitwise 
operation, with well defined overflowing behavior on the most 
significant bits).


Paolo

Re: GCC optimizes integer overflow: bug or feature?

[Paolo Bonzini]

We've optimized expressions such as (a*2)/2 on the basis of overflow 
being undefined for a very long time, not just loops.


What is (a*2)/2 optimized to? certainly it has the value a if you wrap, 
so you are not necessarily depending on undefined here.


No, it has not.  For example, if a is 0x4000 in a 32 bit type and 
arithmetic wraps, a*2 = -0x8000 (overflow), and hence (a*2)/2 = 
-0x4000 = -1073741824.


Paolo

Re: -fwrapv enables some optimizations

[Paolo Bonzini]

On Wed, Dec 20, 2006 at 03:50:23PM +, Joseph S. Myers wrote:
Indeed.  Fixing this may require it to be possible to mark individual 
operations with their overflow semantics (which will also be needed for 
LTO to handling inlining between translation units compiled with different 
options).  The problem is that some optimizations involve transforming an 
"overflow undefined" operation into an "overflow wraps" one, which is a 
valid transformation, but can't be represented in trees at present -


Doesn't it suffice just to change the type of the operation to unsigned?
For signed integers, overflow is undefined, but for unsigned integers,
overflow wraps.


You mean writing the hypothetical PLUS_WRAP_EXPR  (where a and b 
are ints) as (int) ((unsigned)a + (unsigned)b)?


That might work actually.  However, I don't know if the optimizers will 
be able to see through the casts and perform all the subsequent 
optimizations appropriately.


Paolo

Re: GCC optimizes integer overflow: bug or feature?

[Paolo Bonzini]

Some time ago (a year?) I was told on this mailing-list that code 
breakage due to undefinedness of signed overflow is not too common (I at 
least claimed with no evidence that it was more than one bug per 1,000 
lines). My claim was counterclaimed by something like "most of the time 
people work with small enough values, so overflows don't happen too many 
times in practice".


This claim is a non sequitur.

What I would say is, people *don't understand why a compiler needs to 
assume undefined overflow semantics*, because people work with small 
values and don't care about the boundary conditions.


For example, most programmers that know assembly language will 
appreciate if the compiler can use the processor's support for loop with 
a known number of iterations (mtctr on PPC, for example).  However, I'm 
pretty sure that, if you present these two pieces of code to some good 
programmers,


  unsigned int i;
  for (i = 0; i <= n; i++)
...

  unsigned int i;
  for (i = 0; i < n; i++)
...

where the compiler uses mtctr only in the second case, most of them will 
think that the compiler has bug.  Almost nobody will realize that the 
first can loop infinitely, and the second cannot (which is the reason 
why the compiler cannot optimize them in the same way).


Well, these programmers *are* assuming undefined overflow semantics even 
on unsigned types.  Maybe they would like overflow semantics should be 
defined in some cases and undefined in others?  Fine by me, that would 
be -fwrapv -funsafe-loop-optimizations in GCC; but a language standard 
cannot go to such detail!


On the autoconf mailing list, Paul Eggert mentioned as a good compromise 
that GCC could treat signed overflow as undefined only for loops and not 
in general.  Except that the original gnulib bug report was in a loop, 
so this compromise would leave that case undefined.


You may think that the analogy is far fetched? In that case, I'll pick 
some gcc source file, at random and look for signed operations in it:

categorize_ctor_elements_1(..) in gcc/expr.c:
_elts += mult * nz;
elt_count += mult * ic;
Both assume that neither the multiplication, nor the addition overflow. 


I see this as a *counterexample*: it shows that programmers don't care 
about having wrapping overflow, in fact they don't care about overflow 
at all.  This code is incorrect not only if overflow is undefined, but 
also if overflow wraps (-fwrapv); it is correct if overflow aborts 
(-ftrapv).


Paolo

Re: GCC optimizes integer overflow: bug or feature?

[Paolo Bonzini]

foo->bar = make_a_bar();
foo->bar->none = value;

being rendered as:

call make_a_bar
foo->bar->none = value
foo->bar = 


You are not describing a C compiler.


Um, I'm describing what gcc did?


I think he meant

x = make_a_bar ();
x->none = value;
foo->bar = x;

I don't know if this is a valid optimization, but I wouldn't be 
surprised if it is.


Palo

Re: GCC optimizes integer overflow: bug or feature?

[Paolo Bonzini]

Maybe he forgot the delicate details? The issue may happen if this 
example was incomplete (my "completion" may need some tweaking to make 
it more realistic):


   #define make_a_bar(ppInstance) 
*(unsigned**)(&ppInstance)=make_a_uint(sizeof(struct bar))

   make_a_bar(foo->bar);
   foo->bar->none = value;


Then, the author of make_a_bar() is getting what he deserved.


I am not sure if the following would break as well:

   #define make_a_bar()   (struct bar*)make_a_uint(sizeof(struct bar))
   foo->bar=make_a_bar();
   foo->bar->none = value;

Since gcc should know that foo->bar of type "struct bar" has been 
updated before "value" gets written to "none" which is a field on object 
of type "struct bar".


Of course it wouldn't break.

But the reason I say that this is what you deserved, is that the cast is 
completely unnecessary.  You should write this:


#define make_a_bar (ppInstance) \
 ((ppInstance)=(void *)make_a_uint(sizeof(struct bar)))

that is, you put the cast on the other side and don't play with the 
types of the lvalues.  This is what happens all the time with malloc.


Paolo

Re: GCC optimizes integer overflow: bug or feature?

[Paolo Bonzini]

  int j;
  for (j = 1; 0 < j; j *= 2)
if (! bigtime_test (j))
  return 1;

Here it is obvious to a programmer that the comparison is
intended to do overflow checking, even though the test
controls the loop.


Well, it's not to me. :-)


Another question for the GCC experts: would it fix the bug
if we replaced "j *= 2" with "j <<= 1" in this sample code?


Yes, it will actually compile the code as this:

  int i, j;
  for (i = 0, j = 1; i < 31; i++)
j <<= 1;

Or you can do, since elsewhere in the code you compute time_t_max:

  for (j = 1; j <= time_t_max / 2 + 1; j *= 2)

Which is IMO more intention revealing.

Paolo

Re: GCC optimizes integer overflow: bug or feature?

[Paolo Bonzini]

Or you can do, since elsewhere in the code you compute time_t_max:

  for (j = 1; j <= time_t_max / 2 + 1; j *= 2)


No, this does not work.  It would work to have:

  for (j = 1;;)
{
  if (j > time_t_max / 2)
break;
  j *= 2;
}

Oops.

Paolo

Re: does zlib really need to build multilib?

[Paolo Bonzini]

Jack Howarth wrote:

   I noticed that in gcc trunk and gcc 4.2 branch
that multilib builds of zlib occur. Does gcc
actually use the multlib zlib?


Not for the host zlib.


For instance on
x86_64 linux does the 32-bit zlib get used or on
Darwin does the 64-bit zlib get used? We are
considering using the --with-system-zlib option
when building gcc 4.2 but MacOS X 10.4 and earlier
lacks a 64-bit zlib support library. Thanks in
advance for any clarifications.


If you want to prepare a patch to pass --disable-multilib in the host 
configure arguments, and test it adequately, I'll be happy to review it.


Paolo

[heads-up] disabling "../configure --disable-bootstrap && make bootstrap"

[Paolo Bonzini]

As per the subject.  The upcoming merge of toplevel libgcc will only 
work either for disabled bootstrap, or with the toplevel bootstrap 
mechanism.  For this reason, we are now disabling "../configure 
--disable-bootstrap && make bootstrap".  The correct way to bootstrap is 
to just use "./configure" (followed by "make", "make bootstrap" or similar).


Next week, after the merge, the bootstrap rules in the gcc directory 
will go away.


Ciao,

Paolo

Re: [heads-up] disabling "../configure --disable-bootstrap && make bootstrap"

[Paolo Bonzini]

The problem is that last step: it takes a LONG time to build libjava,
for example.  If I make a change that I need to give a sanity check to,
I want to compile GCC with it, but not all the other additional code: that's
for a later state in the development/testing cycle.  Since building a stage
of GCC is about three times faster than "other target libraries", if there's
no way to suppress that, the time to do this test goes up by a factor of four.


Would you feel OK if there were a make target to do a bootstrap
without building the other target libraries?  The change from today's
bootstrap with --disable-bootstrap would be that it would build
libiberty, libcpp, and friends at each stage, rather than only once.


There's one "make stage3-bubble".

Paolo

Re: configuration options policy (at toplevel or only inside gcc/)?

[Paolo Bonzini]

In particular, IMHO the commands to re-generate the configure scripts 
should be documented if the documentation also targets potential GCC 
contributors.


I agree, that sounds useful.  DJ, Alexandre, Paolo, what's your take
on this.  Any recommendations?


Patches are always welcome. :-)

Basile's proposal seems worthwhile.

Paolo

Re: Top level libgcc checked in

[Paolo Bonzini]

Andrew Pinski wrote:

We should also be very careful not to introduce differences between
native and cross compilers.  So, we should have no run-time tests, no
tests that look at /proc, headers in /usr/include, etc.

Right--I was really only suggesting tests that can be done at
compile-time.  Perhaps there isn't a lot of room for improvement after
all.


The only test I can think of that could be improved if it is not already
done, is the check for visibility support.


In fact that's already done. :-)

I'm sure that a few other changes can be made, such as sizeof tests. 
These however are less interesting than untangling the config files.


Paolo

Re: Do we want non-bootstrapping "make" back?

[Paolo Bonzini]

Richard Kenner wrote:

Not much.  I'm convinced it would be feasible, but definitely not easy,
so I wanted to see how much interest there was - seems like some, but
not a lot.

Would this comprise retrofitting the support into the 4.2 branch?


I don't think it's needed in the 4.2 branch since you can get the functionality
with --disable-bootstrap (or whatever it's called).  It's only in 4.3 that
that option will be removed and hence the functionality otherwise lost.


No, --disable-bootstrap *will* remain forever.  What will be lost is the 
possibility to do


  ../configure --disable-bootstrap
  make bootstrap

Paolo

Re: C++ overflow testcases failing on mainline

[Paolo Bonzini]

It seems I managed to mess up the patch applied to revision 120558.
The problem is that somehow all testcases have been added three times.
I cannot imagine how such thing happenned.


You probably used "patch" which, instead of warning if a patch creates a 
file that is already there, happily puts the content of the file again 
at the beginning of it.


Paolo

Re: RFC: Speeding up libstdc++.so with --dynamic-list-data

[Paolo Bonzini]

I am testing this patch now. It should fix the regresions when
libstdc++ is built with

-Bsymbolic-functions --dynamic-list-cpp-new


What about just --dynamic-list-cpp that enables the new behavior and 
implies --dynamic-list-cpp-typeinfo (I know that it is useless in this 
particular case, since C++ typeinfo is data, but in general such an 
option sounds more useful than only --dynamic-list-cpp-new).


Paolo

Re: PATCH: Build shared libraries with -Bsymbolic-functions

[Paolo Bonzini]

H. J. Lu wrote:

On Wed, Jan 10, 2007 at 06:26:09AM -0700, Tom Tromey wrote:

"H.J." == H J Lu <[EMAIL PROTECTED]> writes:

H.J.> With the new linker switches, -Bsymbolic-functions and
H.J.> --dynamic-list-cpp-new, we can improve shared library
H.J.> performance in gcc. This change will build libstdc++.so with
H.J.> -Bsymbolic-functions and --dynamic-list-cpp-new. I can expand it
H.J.> to other libraries.

I prefer to see semi-generic helper code like this in a new .m4 file
in config.  That makes it somewhat simpler for other target libraries
to reuse it.



Here it is. If it is OK, I will extend it to Java and Fortran.


If the libstdc++ bits are ok, the config bits are ok but please put them 
in a new file.  lib-ld.m4 is imported from gettext.  (And commit the 
config part to both gcc and src).


Paolo

Re: Making gcc read from the standard input

[Paolo Bonzini]

Tathagato Rai Dastidar wrote:

Hello,

Is there a way I can make GCC read a C or C++ code from the standard 
input instead of from a file?


In my application software, I am generating some C code on the fly, 
writing it to a file, then using GCC to compile it. Instead of that, I 
want to invoke GCC through a pipe, and write the C code directly into 
GCC, instead of writing it into a file and then calling GCC.


Is this possible?


This is a question only for gcc-help.  Cross-posting gcc and gcc-help is 
almost always wrong.  :-) But yes, it is possible by adding "-x c" to 
the command line, so that the gcc driver knows which front-end to 
invoke.  In the case of "-E", in fact, GCC implicitly considers the 
language to be C (and invokes the C front-end) because the preprocessor 
is the same for all input languages; but for real compilation, you need 
to specify the language manually.


HTH,

Paolo

Re: PATCH: Build shared libraries with -Bsymbolic-functions

[Paolo Bonzini]

config/

2007-01-10  H.J. Lu  <[EMAIL PROTECTED]>

* ld-symbolic.m4: New.


Please name the macro AC_LIB_PROG_LD_GNU_SYMBOLIC, or 
ACX_PROG_LD_GNU_SYMBOLIC.



libgfortran/

2007-01-10  H.J. Lu  <[EMAIL PROTECTED]>

* aclocal.m4: Include ../config/lib-ld.m4 and
../config/ld-symbolic.m4.


Also, aclocal.m4 is automatically generated with "aclocal -I ../config" 
except in libjava.



* configure.ac: Use PROG_LD_GNU_SYMBOLIC.  Set
libgcj_ld_symbolic to $SYMBOLIC_LDFLAGS if it isn't set.


Please check if libgcj_ld_symbolic is now obsolete in 
libjava/configure.host.

Re: PATCH: Build shared libraries with -Bsymbolic-functions

[Paolo Bonzini]

libjava will use -Bsymbolic on Linux, which is more aggresive than
-Bsymbol-functions. It will bind global data references locally in
additon to global function references. My patch will keep -Bsymbolic
for libjava if it is set by libjava/configure.host.

Here is an updated patch.


The configury logic is fine by me, but please wait for approval at least 
from the libjava and libstdc++ maintainers since I don't understand 
fully the consequences of the -Bsymbolic stuff.  Could it be considered 
an ABI change, in that programs previously overriding some symbols will 
break?  (Sorry if the question is dumb).


Paolo

Re: Invariant division

[Paolo Bonzini]

drizzle drizzle wrote:

Hi
Does gcc do an divison by constant optimization for any 16 bit
architecture. Can anyone point me to where  it does that ?


Yes, in expmed.c (expand_divmod).

Paolo

Re: Cheatsheet for building gcc

[Paolo Bonzini]

Q1) How to bootstrap the compiler, including all libraries?
A1) "make" from the top directory

Could some of the build system experts please provide the answers
for the following questions?

Q2) How to bootstrap the compiler, but not build any time consuming
libraries (libjava, libstdc++)?


A2) "make stage{2,3,feedback}-bubble"


Q3) How to compile just the stage1 compiler + the basic runtime
(libgcc, libmudflap, libgomp)?


A3) make stage1-bubble all-target-libmudflap all-target-libgomp


Q4) How to compile all the libraries (libjava, ...) using the stage1
compiler?


A4) Configure with --enable-stage1-languages=all


Q5) How to clean up everything (including the stage1 compiler, but
excluding makefiles, so that I can build everything from scratch,
but configure does not have to be run)?


make clean (or make cleanstrap to also start a bootstrap)


Q6) How to clean up everything except for the stage1 compiler and
its runtime (libgcc, libmudflap, libgomp)?


make restrap (which will also start a bootstrap)


And of course, how to do any other useful things that I have forgotten
about...


I would like to ask if, in your opinion, libssp, libmudflap and libgomp 
should be bootstrapped like libgcc is.  I would think that, for 
automatic parallelization, you'd need at least libgomp.


In this case, the answer to Q3 would be simply "make stage1-bubble".

Paolo

Re: Cheatsheet for building gcc

[Paolo Bonzini]

Is there a way how to do it without reconfiguring gcc?


No.  Do you think it would be best to have --enable-stage1-languages=all 
in non-release branches?  The time taken to compile the stage1 
(nonoptimized) non-C front-ends is small, and the advantage seems 
significant.



Q6) How to clean up everything except for the stage1 compiler and
   its runtime (libgcc, libmudflap, libgomp)?

make restrap (which will also start a bootstrap)


Would it be possible to add a possibility to just clean up the things,
without restarting the bootstrap (i.e., to move everything to the
state I would have after "make stage1-bubble" if I started from the scratch)?


Actually, I was wrong as "make restrap" will also delete the runtime. 
The closest things to what you want are:
- "make distclean-stage2"; however it will leave there all the target 
libraries if they have already been compiled, not only the runtime.

- "make distclean-stage2 clean-target"; which will remove also the runtime.

Paolo

Re: Miscompilation of remainder expressions

[Paolo Bonzini]

Compared to the slow idivl, abs could be negligible, right. However, abs
does introduce new data dependence which might add a noticeable cost.

   Is there an abs instruction in the i386 instruction set?


No, the closest thing (input in eax, output in edx) is

cltq
addl %edx, %eax
xorl %eax, %edx

But the register allocations constraints are pretty heavy considering 
that idivl already puts strain on the RA.


Paolo

Re: Cheatsheet for building gcc

[Paolo Bonzini]

if you configure with  --enable-stage1-languages=all,

1) will all the libraries be built three times during bootstrap, or just
   once?


Just once.  Things that are built three times are only those that have 
"bootstrap=true" in the Makefile.def file.


Paolo

Re: Miscompilation of remainder expressions

[Paolo Bonzini]

cltq
addl %edx, %eax
xorl %eax, %edx

But the register allocations constraints are pretty heavy considering 
that idivl already puts strain on the RA.


Paolo, what does the cltq instruction do?  I cannot find it in my x86 
reference manuals...


Uhm, I meant cltd and it is the same as "cdq" in the intel syntax.

cltq is an x86-64 instruction and it is the same as "cdqe" in the intel 
syntax.


Paolo

Re: Cheatsheet for building gcc

[Paolo Bonzini]

Richard Kenner wrote:

Q2) How to bootstrap the compiler, but not build any time consuming
libraries (libjava, libstdc++)?

A2) "make stage{2,3,feedback}-bubble"


Can you say what the differences between these three are?  Which is the
equivalent of the old "cd gcc; make bootstrap"?


They will stop respectively at stage2 (equivalent of old "cd gcc; make 
bootstrap2"), stage3 (old "cd gcc; make bootstrap"), stagefeedback 
(equivalent of old "cd gcc; make profiledbootstrap).



Q4) How to compile all the libraries (libjava, ...) using the stage1
compiler?

A4) Configure with --enable-stage1-languages=all


... and then do what, "make bootstrap"?


"make stage1-bubble all-target".

I think I have now enough info to make The Page That Should Have Been 
Created A Year Ago.


Paolo

Re: Cheatsheet for building gcc

[Paolo Bonzini]

with the changes to the build system in the last few months, I am having
problems to do some things I am used to do during development.  I found
more or less satisfactory procedures for most them, however, I would
like to know the "official" way how to achieve those effects (and to put
the created "cheatsheet" to wiki, so that people do not have to reinvent
the wheel).


Now at http://gcc.gnu.org/wiki/Top-Level_Bootstrap.

Paolo

Re: lib{gomp,decnumber}/autom4te.cache

[Paolo Bonzini]

FX Coudert wrote:
Is there any reason why libgomp and libdecnumber don't have a svn:ignore 
property containing autom4te.cache? I noticed the following always 
showing up in my "svn status" after a maintainer-mode build:

?  libdecnumber/autom4te.cache
?  libgomp/autom4te.cache


Go ahead and set it.

Paolo

Re: Preventing warnings

[Paolo Bonzini]

Andrew Pinski wrote:

On Sun, 2007-01-21 at 01:49 -0500, Richard Stallman wrote:

It would be nice to have such a construct in GNU C, something that
could be used in a macro expansion, and would turn off _all_ warnings
for the code within the construct.


http://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html

But it says:
Also, while it is syntactically valid to put these pragmas anywhere in
your sources, the only supported location for them is before any data or
functions are defined. Doing otherwise may result in unpredictable
results depending on how the optimizer manages your sources.

Maybe this will be better if all warnings only come from the front-end.


Or, for the time being, if you apply the options to warnings that only 
come from the front end.  For the one originally mentioned in the 
discussion, this is the case.


If in 4.3 Manuel will have associated this warning to a command-line 
option, the "GCC diagnostic" pragma could be used to turn the warning off.


Paolo

Re: raising minimum version of Flex

[Paolo Bonzini]

I'm not at all impressed with the recent series of flex releases, since it 
started using m4 internally and passing user code through m4.  
(cf. bison, which unlike 
flex pays proper attention to assuring that arbitrary valid parsers are 
not mangled by m4).


Fully agreed.  The recent releases of flex are a mess (a pity, because 
they also have interesting features such as yylineno support without 
performance hits).


Paolo

Re: char should be signed by default

[Paolo Bonzini]

A given program is written in one or the other of these two dialects.
The program stands a chance to work on most any machine if it is
compiled with the proper dialect. It is unlikely to work at all if
compiled with the wrong dialect.


It depends on the program, and whether or not chars in the user's
character set is sign extended (ie, in the USA, you likely won't notice
a difference between the two if chars just hold character values).


You might notice if a -1 (EOF) becomes a 255 and you get an infinite 
loop in return (it did bite me).  Of course, this is a bug in that 
outside the US a 255 character might become an EOF.


Paolo

Re: G++ OpenMP implementation uses TREE_COMPLEXITY?!?!

[Paolo Bonzini]

You know (or so I assume) this was a very Very VERY BAD thing to do


are not helpful.  Of course, if RTH had thought it was a bad thing, he
wouldn't have done it.


Well, I must agree that there is probably no justification other than 
the quote that Richard posted. :-P  Still, I agree with you on the tone 
of Steven's email, and I don't see the need to Cc Jakub and Diego too, 
either.


I hope Steven accepts a little deal: he exits angry-stevenb-mode, and I 
donate him this untested patch to remove TREE_COMPLEXITY from C++.


Paolo
Index: cp-tree.h
===
--- cp-tree.h   (revision 120669)
+++ cp-tree.h   (working copy)
@@ -3040,13 +3040,9 @@ extern void decl_shadowed_for_var_insert
   (TREE_LANG_FLAG_0 (SCOPE_REF_CHECK (NODE)))
 
 /* True for an OMP_ATOMIC that has dependent parameters.  These are stored
-   as bare LHS/RHS, and not as ADDR/RHS, as in the generic statement.  */
+   as an expr in operand 1.  */
 #define OMP_ATOMIC_DEPENDENT_P(NODE) \
-  (TREE_LANG_FLAG_0 (OMP_ATOMIC_CHECK (NODE)))
-
-/* Used to store the operation code when OMP_ATOMIC_DEPENDENT_P is set.  */
-#define OMP_ATOMIC_CODE(NODE) \
-  (OMP_ATOMIC_CHECK (NODE)->exp.complexity)
+  (TREE_CODE (TREE_OPERAND (OMP_ATOMIC_CHECK (NODE), 0)) == INTEGER_CST)
 
 /* Used while gimplifying continue statements bound to OMP_FOR nodes.  */
 #define OMP_FOR_GIMPLIFYING_P(NODE) \
Index: pt.c
===
--- pt.c(revision 120669)
+++ pt.c(working copy)
@@ -8917,12 +8917,13 @@ tsubst_expr (tree t, tree args, tsubst_f
   break;
 
 case OMP_ATOMIC:
-  {
-   tree op0, op1;
-   op0 = RECUR (TREE_OPERAND (t, 0));
-   op1 = RECUR (TREE_OPERAND (t, 1));
-   finish_omp_atomic (OMP_ATOMIC_CODE (t), op0, op1);
-  }
+  if (OMP_ATOMIC_DEPENDENT_P (t))
+{
+ tree op1 = RECUR (TREE_OPERAND (t, 1));
+ tree lhs = RECUR (TREE_OPERAND (op1, 0));
+ tree rhs = RECUR (TREE_OPERAND (op1, 1));
+ finish_omp_atomic (TREE_CODE (op1), lhs, rhs);
+}
   break;
 
 default:
Index: semantics.c
===
--- semantics.c (revision 120669)
+++ semantics.c (working copy)
@@ -3890,9 +3890,8 @@ finish_omp_atomic (enum tree_code code, 
 }
   if (processing_template_decl)
 {
-  stmt = build2 (OMP_ATOMIC, void_type_node, orig_lhs, orig_rhs);
-  OMP_ATOMIC_DEPENDENT_P (stmt) = 1;
-  OMP_ATOMIC_CODE (stmt) = code;
+  stmt = build2 (OMP_ATOMIC, void_type_node, integer_zero_node,
+build2 (code, void_type_node, orig_lhs, orig_rhs));
 }
   add_stmt (stmt);
 }

Re: G++ OpenMP implementation uses TREE_COMPLEXITY?!?!

[Paolo Bonzini]

I rather create a new tree for template usage really, so you don't create
an extra tree and save a little amount of memory.


This, however, would consume another scarce resource, i.e. tree codes. 
The attached patch, in the meanwhile, has been bootstrapped and 
regtested i686-pc-linux-gnu, C/C++ only, with no regression.  Note that 
this is *not* the patch I sent yesterday, which did not work.


Ok for mainline?

Paolo
2007-01-30  Paolo Bonzini  <[EMAIL PROTECTED]>

* cp/cp-tree.h (OMP_ATOMIC_CODE): Delete.
(OMP_ATOMIC_DEPENDENT_P): Rewrite.
* cp/pt.c (tsubst_expr): Adjust for new format of dependent OMP_ATOMIC
expressions.
* cp/semantics.c (finish_omp_atomic): Store a whole expression node
in operand 1, and integer_zero_node in operand 0, for dependent
OMP_ATOMIC.  Rewrite to make flow easier to understand.

Index: cp-tree.h
===
*** cp-tree.h   (revision 121287)
--- cp-tree.h   (working copy)
*** extern void decl_shadowed_for_var_insert
*** 3040,3052 
(TREE_LANG_FLAG_0 (SCOPE_REF_CHECK (NODE)))
  
  /* True for an OMP_ATOMIC that has dependent parameters.  These are stored
!as bare LHS/RHS, and not as ADDR/RHS, as in the generic statement.  */
  #define OMP_ATOMIC_DEPENDENT_P(NODE) \
!   (TREE_LANG_FLAG_0 (OMP_ATOMIC_CHECK (NODE)))
! 
! /* Used to store the operation code when OMP_ATOMIC_DEPENDENT_P is set.  */
! #define OMP_ATOMIC_CODE(NODE) \
!   (OMP_ATOMIC_CHECK (NODE)->exp.complexity)
  
  /* Used while gimplifying continue statements bound to OMP_FOR nodes.  */
  #define OMP_FOR_GIMPLIFYING_P(NODE) \
--- 3040,3048 
(TREE_LANG_FLAG_0 (SCOPE_REF_CHECK (NODE)))
  
  /* True for an OMP_ATOMIC that has dependent parameters.  These are stored
!as an expr in operand 1, and integer_zero_node in operand 0.  */
  #define OMP_ATOMIC_DEPENDENT_P(NODE) \
!   (TREE_CODE (TREE_OPERAND (OMP_ATOMIC_CHECK (NODE), 0)) == INTEGER_CST)
  
  /* Used while gimplifying continue statements bound to OMP_FOR nodes.  */
  #define OMP_FOR_GIMPLIFYING_P(NODE) \
Index: pt.c
===
*** pt.c(revision 121287)
--- pt.c(working copy)
*** tsubst_expr (tree t, tree args, tsubst_f
*** 8917,8928 
break;
  
  case OMP_ATOMIC:
!   {
!   tree op0, op1;
!   op0 = RECUR (TREE_OPERAND (t, 0));
!   op1 = RECUR (TREE_OPERAND (t, 1));
!   finish_omp_atomic (OMP_ATOMIC_CODE (t), op0, op1);
!   }
break;
  
  default:
--- 8917,8929 
break;
  
  case OMP_ATOMIC:
!   if (OMP_ATOMIC_DEPENDENT_P (t))
! {
! tree op1 = TREE_OPERAND (t, 1);
! tree lhs = RECUR (TREE_OPERAND (op1, 0));
! tree rhs = RECUR (TREE_OPERAND (op1, 1));
! finish_omp_atomic (TREE_CODE (op1), lhs, rhs);
! }
break;
  
  default:
Index: semantics.c
===
*** semantics.c (revision 121287)
--- semantics.c (working copy)
*** finish_omp_for (location_t locus, tree d
*** 3867,3907 
  void
  finish_omp_atomic (enum tree_code code, tree lhs, tree rhs)
  {
-   tree orig_lhs;
-   tree orig_rhs;
-   bool dependent_p;
tree stmt;
  
!   orig_lhs = lhs;
!   orig_rhs = rhs;
!   dependent_p = false;
!   stmt = NULL_TREE;
! 
!   /* Even in a template, we can detect invalid uses of the atomic
!  pragma if neither LHS nor RHS is type-dependent.  */
!   if (processing_template_decl)
! {
!   dependent_p = (type_dependent_expression_p (lhs) 
!|| type_dependent_expression_p (rhs));
!   if (!dependent_p)
{
  lhs = build_non_dependent_expr (lhs);
  rhs = build_non_dependent_expr (rhs);
}
! }
!   if (!dependent_p)
! {
stmt = c_finish_omp_atomic (code, lhs, rhs);
-   if (stmt == error_mark_node)
-   return;
- }
-   if (processing_template_decl)
- {
-   stmt = build2 (OMP_ATOMIC, void_type_node, orig_lhs, orig_rhs);
-   OMP_ATOMIC_DEPENDENT_P (stmt) = 1;
-   OMP_ATOMIC_CODE (stmt) = code;
  }
!   add_stmt (stmt);
  }
  
  void
--- 3867,3894 
  void
  finish_omp_atomic (enum tree_code code, tree lhs, tree rhs)
  {
tree stmt;
  
!   if (processing_template_decl
!   && (type_dependent_expression_p (lhs) 
! || type_dependent_expression_p (rhs)))
! stmt = build2 (OMP_ATOMIC, void_type_node, integer_zero_node,
!  build2 (code, void_type_node, lhs, rhs));
!   else
! {
!   /* Even in a template, we can detect invalid uses of the atomic
!  pragma if neither LHS nor RHS is type-dependent.  */
!   if (processing_template_decl)
{
  lhs = build_non_dependent_expr (lhs);
  rhs = build_non_dependent_expr (rhs);
}
! 
stmt = c_finish_omp_

Re: Failure to build libjava on 512MB machine

[Paolo Bonzini]

Anyway, I tried again, this time with the right file, and it took

78.67user 1.29system 1:20.01elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k

and indeed, it does want a lot of memory - at peak some 550m.  It'll
be smaller on a 32-bit box, but not much smaller.


I want to get rid of TREE_COMPLEXITY!

Paolo

Re: Failure to build libjava on 512MB machine

[Paolo Bonzini]

Still, this shows that we did have an increase in memory use recently,
which may be worth looking into.  (And, of course, I'm happily testing
Tom's patch as we speak.)


I'd be curious to know the effect of removing the "complexity" field of 
struct tree_exp.  It should be possible to bootstrap C/C++/Java/Fortran 
with a two line patch removing the field from tree.h, and the only 
reference to it in tree.c (via the macro TREE_COMPLEXITY).


Paolo

Re: gcc-4.1.2 RC1 build problem

[Paolo Bonzini]

The macro $(SYSTEM_HEADER_DIR) is used in a double-quoted context,
leading to nonportable "...`..."..."...`...",  see
.

Proposed untested patch.  (I also haven't checked whether there are
other instances of this issue in 'make install' code.)


If you or anybody can test this (better on an affected system, but even 
i686-pc-linux-gnu would be ok), ok for mainline and all affected release 
branches.


Paolo

Re: Scheduling an early complete loop unrolling pass?

[Paolo Bonzini]

As we also only vectorize innermost loops I believe doing a
complete unrolling pass early will help in general (I pushed
for this some time ago).

Thoughts?


It might also hurt, though, since we don't have a basic block 
vectorizer.  IIUC the vectorizer is able to turn


  for (i = 0; i < 4; i++)
v[i] = 0.0;

into

  *(vector double *)v = (vector double){0.0, 0.0, 0.0, 0.0};

Paolo

Re: problem building gcc4-4.3.0-20070209

[Paolo Bonzini]

if test ${build} != ${host}; then
  some defaults
else
  AC_PROG_CC
fi

AC_TRY_COMPILE

ac_objext is set at the expansion of AC_PROG_CC and if you take the if
branch, it never gets set.

Does anyone reading this know what the right thing to do is?  Is there
anything in the autoconf documentation about not using some macros
inside conditional statements?


Yes, but the idea is that, if we are in a Canadian setting, we can set 
all the variables that Autoconf sets, in the `then' branch.  So we'd set 
ac_objext=.o in the `then' branch.


Paolo

Re: Division by zero

[Paolo Bonzini]

I'm going to use an asm ().


Yeah, an asm volatile ("" : : "r" (x) : ) should please GCC and still be 
portable to different platforms.


Paolo

Re: problem building gcc4-4.3.0-20070209

[Paolo Bonzini]

This seems horribly wrong somehow.  Aren't we intested in the ${build}
-> ${host} compiler at this point anyway?  So shouldn't we be testing
it?  I think the whole block can go.


Hmm, it says indeed "this is going to change when we autoconfiscate". 
Something like this?


Index: configure.ac
===
*** configure.ac(revision 121762)
--- configure.ac(working copy)
*** if test -z "${CC}" && test "${build}" =
*** 1030,1055 
  fi

  if test "${build}" != "${host}" ; then
-   # If we are doing a Canadian Cross, in which the host and build systems
-   # are not the same, we set reasonable default values for the tools.
-
-   CC=${CC-${host_noncanonical}-gcc}
-   CFLAGS=${CFLAGS-"-g -O2"}
-   CXX=${CXX-${host_noncanonical}-c++}
-   CXXFLAGS=${CXXFLAGS-"-g -O2"}
CC_FOR_BUILD=${CC_FOR_BUILD-gcc}
-
  else
!   # Set reasonable default values for some tools even if not Canadian.
!   # Of course, these are different reasonable default values, originally
!   # specified directly in the Makefile.
!   # We don't export, so that autoconf can do its job.
!   # Note that all these settings are above the fragment inclusion point
!   # in Makefile.in, so can still be overridden by fragments.
!   # This is all going to change when we autoconfiscate...
!
CC_FOR_BUILD="\$(CC)"
!   AC_PROG_CC

# We must set the default linker to the linker used by gcc for the 
correct
# operation of libtool.  If LD is not defined and we are using gcc, 
try to

--- 1030,1042 
  fi

  if test "${build}" != "${host}" ; then
CC_FOR_BUILD=${CC_FOR_BUILD-gcc}
  else
!   CFLAGS=${CFLAGS-"-g"}
CC_FOR_BUILD="\$(CC)"
! fi
!
! AC_PROG_CC

# We must set the default linker to the linker used by gcc for the 
correct
# operation of libtool.  If LD is not defined and we are using gcc, 
try to

*** else
*** 1070,1079 
  fi
fi

!   CXX=${CXX-"c++"}
!   CFLAGS=${CFLAGS-"-g"}
!   CXXFLAGS=${CXXFLAGS-"-g -O2"}
! fi

  ACX_PROG_GNAT
  ACX_PROG_CMP_IGNORE_INITIAL
--- 1057,1063 
  fi
fi

! AC_PROG_CXX

  ACX_PROG_GNAT
  ACX_PROG_CMP_IGNORE_INITIAL

Re: Pre Compiled Headers

[Paolo Bonzini]

what happens with the data previously loaded by a previous pch include file?
I can't figure out why every GTY()-ed global data (extern or static) should
be overwritten at each PCH inclusion, but then maybe I am wrong.


There can be only one PCH inclusion in every compilation.

Paolo

Re: Some thoughts and quetsions about the data flow infrastracture

[Paolo Bonzini]

 I even have own tool for 
this NONA http://cocom.sf.net .  Although it might be a good research to 
make it work on insns from diffrent BBs.


Of course instruction selection is usually done intra-BB.  However, some 
analyses that combine performs, such as nonzero_bits and 
num_sign_bit_copies, maybe could be extended to use the new framework.


The problem is that to use the modern approach you need another 
description of insns (with one pattern - one machine insn relation) in 
tree representation with given cost for the tree.  And it is a huge work 
to rewrite current machine descriptions even only for this.


This is not really necessary.  I have a stripped down version of NONA 
working on RTL.  It is possible to build the tree using a mechanism 
similar to subst in combine, simplify the resulting expression, and use 
NONA (which is actually the same algorithms as iburg) to split it.


Paolo

Re: Some thoughts and quetsions about the data flow infrastracture

[Paolo Bonzini]

The problem is that to use the modern approach you need another 
description of insns (with one pattern - one machine insn relation) 
in tree representation with given cost for the tree.  And it is a 
huge work to rewrite current machine descriptions even only for this.


This is not really necessary.  I have a stripped down version of NONA 
working on RTL.  It is possible to build the tree using a mechanism 
similar to subst in combine, simplify the resulting expression, and 
use NONA (which is actually the same algorithms as iburg) to split it.


I tried to do this 7 years ago without a success.  I am glad that you 
are sucessfull.  Thank you for doing this, Paolo.  I never thought that 
this code created 15 year ago can be used somewhere else besides one 
internal production compiler.


I never said I finished. :-)  In particular, my code does not do 
combine-style simplifications.


Most current machine description only have a one pattern - one machine 
insn relation post reload, which can be a problem.  However, current 
RTX_COSTS are much more precise than 7 years ago to the point that 
combine actually uses them, and this somewhat offsets the problem.


Paolo

Re: Some thoughts and quetsions about the data flow infrastracture

[Paolo Bonzini]

Well before GCC 4.x there was an attempt that a few of us worked on to try to
move the algebraic simplifications from combine to simplify-rtx.c, just like
we put tree folding in fold-const.c.  At that point, combine just becomes
"bookkeeping".  The problem with that approach was what to do with such
things as nonzero_bits and num sign bit copies.


Actually, simplify-rtx.c now uses nonzero_bits and num_sign_bit_copies: 
these ask combine for the value in the case of pseudos, via the "RTL 
hooks" mechanism.  The same RTL hooks mechanism allow combine to try 
using its (clobber (const_int 0)) idiom in gen_lowpart, for example.  It 
was done in 4.1 or 4.2, I don't remember, and it allowed quite a few 
simplifications to be moved from combine_simplify_rtx to simplify-rtx.c.


It is possible to move a lot more indeed.  The problems are mainly these 
two:


1) what to do with (clobber (const_int 0)).  This should be not so much 
of a problem thanks to validate_change, but I'd be weary of having such 
CLOBBER rtx-en in REG_EQUAL notes!


2) a lot of this is hard to be done incrementally.  For example, it is 
hard to move any one of simplify_and_const_int, make_compound_operation, 
expand_compound_operation, force_to_mode, simplify_shift_const without 
moving the others.  This means that the patches would be huge.  Or it 
could be possible to move simplify_comparison, but it is a 1200-line 
function so the almost-mechanic changes needed to move it would be also 
very hard to review.


The problem with fold_rtx is the other way round; it's hard to move the 
lookup logic into simplify-rtx.c even using RTL hooks.



That means we could merge CSE and combine and do a *lot* more than we ever
were able to do before while having the code for both passes be much simpler.


Unfortunately, we should not forget CSE's secondary functionality, which 
is to act as garbageman for the GCSE pass.


Paolo

Re: Some thoughts and quetsions about the data flow infrastracture

[Paolo Bonzini]

[trimming down the Cc list]

1) what to do with (clobber (const_int 0)).  This should be not so much 
of a problem thanks to validate_change, but I'd be weary of having such 
CLOBBER rtx-en in REG_EQUAL notes!


Just return NULL.  The philosophy of simplify_rtx is different from combine.
In the former, you're being asked "can you simplify this?" while in the
latter, there's a lot of intertwining between simplification and
substitution.  So you can just return "no, I can't simplify it" and combine
would then do what it wants do with that result.


Yes, one possibility is to use a RTX hook for this too.  By default you 
would return NULL (and this would propagate up); in combine you could 
override it to return the CLOBBER.


To some extent, simplify-rtx.c could *know* about CLOBBER.  It would 
just not return it unless in combine.


Paolo

Re: Some thoughts and quetsions about the data flow infrastracture

[Paolo Bonzini]

Richard Kenner wrote:
Yes, one possibility is to use a RTX hook for this too.  By default you 
would return NULL (and this would propagate up); in combine you could 
override it to return the CLOBBER.


I really don't see why.  Look at when combine calls the simplify routines now.
If they return zero, it uses the original value.


Some of the combine simplifications (you obviously know that) work by 
"hoping" that the CLOBBER is simplified away.  I don't think you can 
preserve all their power if you propagate NULL.  In most cases you can 
replace CLOBBER with NULL, but I don't think that's possible everywhere.


Paolo

Re: Makefile.def and fixincludes/Makefile.in inconsistency?

[Paolo Bonzini]

Am I correct in guessing that the "missing" lines in Makefile.def are 
not currently needed?  Or are they merely present in the GCC fixincludes 
but missing in the fixincludes directories in some other trees that 
share the top-level build files?


Yes, a patch that removes the "missing" lines for "info", "dvi", "pdf", 
"installcheck" (not "install-info" and "TAGS" is preapproved).  Please 
test it with a "make info", "make dvi", "make pdf" and "make 
installcheck" from the toplevel.


Thanks!

Paolo

Re: Fw: Strange paths for gcc for x86_64-pc-mingw32

[Paolo Bonzini]

But then I noticed, that the pathes to the tool-chain - which is

installed

under /usr/local/x86_64-pc-mingw32 - is used while compile, is somehow
broken for the gcc tool. I assume, that the gcc toolchain is to be found
under /usr/local/libexec/gcc/x86_64-pc-mingw32/4.3.0, but it is search in
/usr/local/x86_64-pc-mingw32/libexec/x86_64-pc-mingw32/4.3.0.
The make command "make install-gcc" installs the toolchain as expected
under /usr/local/libexec/gcc/x86_64-pc-mingw32/4.3.0.


The toolchain is install to /usr/local/x86_64-pc-mingw32, but some parts 
of the compiler (for example cc1) are installed to 
/usr/local/libexec/gcc/x86_64-pc-mingw32/4.3.0; install-gcc should 
install some parts there too, but not all of gcc.


This question, by the way, is more suitable to the [EMAIL PROTECTED] 
mailing list.



You're writing that the toolchain is installed under
/usr/local/x86_64-pc-mingw32,
but you assume it should be under
/usr/local/libexec/gcc/x86_64-pc-mingw32/. Why?
If you want it to be under /usr/local/libexec/gcc/x86_64-pc-mingw32/, you
should configure with --prefix=/usr/local/libexec/gcc.

In case you just need it to find it in the correct place (i.e.,
/usr/local/libexec/gcc/x86_64-pc-mingw32/4.3.0),


This is wrong.

Paolo

Re: GCC 4.2.0 Status Report (2007-02-19)

[Paolo Bonzini]

In term of ports, yes I am agree.  As the preformance even with last 
Paolo's patches (some changes could be applied to the mainline too, so 
it is not only about df), the branch compiler is still 8.7% slower for 
SPECint2000 compilation on 2.66Ghz Core2 with --enable-check=release.


Just to straighten things, only one patch (the one approved by Roger for 
mainline) has been applied to dataflow branch.


Of the four patches I posted, the CSE patch could also go into mainline.

The combine patches (not yet applied to dataflow-branch even) give ~1% 
in addition to that and Kenny has a patch to provide LUIDs for free to 
all passes; that will probably give another 0.5-1%.


That said, I think it would not be bad to put 4.3 in stage3 mode until 
dataflow branch is ready and, at that point, rebranch 4.2 and soon after 
that merge dataflow branch.


Paolo

Re: GCC 4.2.0 Status Report (2007-02-19)

[Paolo Bonzini]

I am agree, benchmarking is evil.  My favorite benchmark is gcc because 
it is my tool and I work on it.  Compilation of gcc from Spec2000 is 
 >12% slower with df including last Paolo's patches (which are a really 
big improvement).


Interesting enough, 176.gcc has a pretty bad result for runtime too in 
SPEC2000:


176.gcc  1100  67.8  1622  1100  72.9  1509*
176.gcc  1100  68.1  1614* 1100  72.9  1509
176.gcc  1100  68.8  1600  1100  72.6  1515


By your reasoning, there is some probability that fixing this one 
performance regression brings dataflow branch into shape for merging 
into mainline... (even though so much has changed since 2.7.2 which is 
used in SPEC2000).


Paolo

Re: A combiner type optimization is causing a failure

[Paolo Bonzini]

My question is that, IMO the test is checking overflow behaviour. Is
it right to have such a test ?


Would you care to prepare a patch that moved it under gcc.dg, adding a { 
dg-options "-O2 -fno-strict-overflow" } marker (or maybe "-O2 
-fno-wrapv")?  But your optimization should also be conditional on 
whether strict overflow behavior is requested.


Paolo

Re: Why use pentium4 for Pentium M?

[Paolo Bonzini]

Zuxy Meng wrote:

Hi,

-march=native choose pentium4 instead of pentium-m for Pentium M processors 
(see config/i386/driver-i386.c)? Is this intentional or a typo?


I think the reason is that Intel changed completely the 
microarchitecture (going back to something that actually is more similar 
to Pentium III's) without bumping the number returned by CPUID (or 
without going back to the P3's number, 6).


Paolo

Re: Mainline bug in RTL fwprop.

[Paolo Bonzini]

> 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

Re: Referenced Vars in IPA pass

[Paolo Bonzini]

> int x;
>  {
>  int y;
>  {
>  int z;
>  ...
>  }
>  ...
> }
> 
> just happens to have three statements, all VAR_DECL,x, y, z, without
> any reference to the starting and ending blocks. As a side question,
> how can I get hand of where the blocks start and finish? Don't really
> know if it's useful but If I need it later, better I know how.

This is not available anymore after lowering to GIMPLE.  BIND_EXPRs
(representing lexical scope) are removed in gimple-low.c.

Paolo

Re: core changes for mep port

[Paolo Bonzini]

>>> Look at the calls to cgraph_mark_edge in ipa-inline.c
>> There is no such function.  I couldn't find anything in ipa-inline
>> that (1) had access to both ends of the call edge, (2) was actually
>> called, and (3) was called before the inlining happened.
> 
> Sorry, I meant cgraph_mark_inline.  It looks like what you want to
> me.  But maybe I'm misreading it.

And cgraph_check_inline_limits (could rename it to cgraph_should_inline_p
or something like that, or just call the target hook wherever that
function is called now; the target hook should also have a parameter for
the reason why inlining is forbidden).

Paolo

Re: GCC 4.2 branch comparision failure building Java

[Paolo Bonzini]

> This didn't apply with 4.1 because then, without toplevel bootstrap, all 
> files to be copied to the source directory were generated and copied in 
> stage 1, so stage 2 and stage 3 both built them from the source directory.  
> Now, stage 1 is not only built as C only but the whole stage 1 build 
> directory is configured as C only, and so Java generated files don't get 
> copied until stage 2.

IIUC, the problem only manifests while *building* the release candidates,
not for users of the release candidate.

For 4.2, my suggestion is to just use a bootstrap4 while building the RC.

For 4.3, we can use --enable-stage1-languages=all when building the RCs.
I can prepare a patch to do that automatically when 
--enable-generated-files-in-srcdir
is passed.

Paolo

Re: GCC 4.2 branch comparision failure building Java

[Paolo Bonzini]

Mark Mitchell wrote:
> Paolo Bonzini wrote:
> 
>> IIUC, the problem only manifests while *building* the release candidates,
>> not for users of the release candidate.
>>
>> For 4.2, my suggestion is to just use a bootstrap4 while building the RC.
> 
> That's an attractive idea.  But, I'd rather fix it correctly, because
> distributors may run into the same problem.

Sorry, I meant 4.2.0 -- for 4.2.1, we can backport whatever fix is needed
for 4.3.

>> For 4.3, we can use --enable-stage1-languages=all when building the RCs.
>> I can prepare a patch to do that automatically when 
>> --enable-generated-files-in-srcdir
>> is passed.
> 
> That might work, but it seems like overkill; that just makes the
> bootstrap process longer.

It makes it longer by one-two minutes: the time to build the three
front-ends without optimization.

Paolo

Re: RFC: obsolete __builtin_apply?

[Paolo Bonzini]

Andrew Pinski wrote:
> On 3/16/07, Steven Bosscher <[EMAIL PROTECTED]> wrote:
>> Do you mean this patch:
>> http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00841.html
> 
> Yes, thanks for finding the patch.
> 
> I will look over it this weekend and apply it if it is good.

Build parts are ok, except that in...

@@ -287,7 +288,7 @@
 noconfigdirs="$noconfigdirs tcl expect dejagnu make texinfo bison patch 
flex byacc send-pr gprof uudecode dejagnu diff guile perl itcl gnuserv gettext"
 ;;
   i[[3456789]]86-*-go32* | i[[3456789]]86-*-msdosdjgpp*)
-noconfigdirs="$noconfigdirs tcl tk expect dejagnu send-pr uudecode guile 
itcl gnuserv libffi"
+noconfigdirs="$noconfigdirs tcl tk expect dejagnu send-pr uudecode guile 
itcl gnuserv target-libffi target-libobjc"

... this hunk, you should also add ${libgcj} before target-libffi.

Paolo

Re: Using SSA

[Paolo Bonzini]

> The tree_opt_pass for my pass has PROP_ssa set in the properties_required
> field.  Is this all I need to do?

You need to put your pass after pass_build_ssa.  Setting PROP_ssa does
not build SSA itself, but it will cause an assertion failure if the
pass is run while SSA is (not yet) available.

Paolo

Re: Using SSA

[Paolo Bonzini]

> I think (if I'm correctly interpreting the list in passes.c) it is.  It's
> right after pass_warn_function_noreturn, just before pass_mudflap_2.  Is
> this right?  I don't get any assertion about SSA not being available.

In this case, it is also after pass_del_ssa, which means SSA has already
been destroyed.

Paolo