Help needed: banishing RTL from the front ends
Hi, I would like to banish bits and pieces of the compiler from ever appearing again in places where they do not belong. That would be step one towards modularization: impose boundaries of some kind. As it is, we can't really make separate modules of parts of gcc yet, but at least I would like to impose some kind of rules to avoid re-introducing the dependencies that I'm trying to break. The first thing I'd like to do now, is banish RTL from the front end. The plan I had for this was: 1) Group front end objects in Makefile.in under e.g. ALL_HOST_FRONTEND_OBJS 2) Add a new build rule that adds an extra define -DIN_GCC_FRONTEND 3) Conditionally poison symbols in system.h For the last step, that would be e.g.: #ifdef IN_GCC_FRONTEND #pragma GCC poison GCC_RTL_H GCC_REGS_H ... #endif Unfortunately, my Makefile-fu is insufficient to do step 2. There is an implicit rule ".c.o:" that triggers no matter what I try, and I don't want to add explicit $(COMPILER) rules for all the front end objects. So this is a call for help. First, is the plan I had a good plan? If so, can someone give me a little hint/help implementing that? And if the plan isn't good, what would be other ways to achieve the same effect? Thanks, Ciao! Steven
Re: Help needed: banishing RTL from the front ends
On 05/25/2010 09:55 AM, Steven Bosscher wrote: 1) Group front end objects in Makefile.in under e.g. ALL_HOST_FRONTEND_OBJS 2) Add a new build rule that adds an extra define -DIN_GCC_FRONTEND 3) Conditionally poison symbols in system.h For the last step, that would be e.g.: #ifdef IN_GCC_FRONTEND #pragma GCC poison GCC_RTL_H GCC_REGS_H ... #endif Unfortunately, my Makefile-fu is insufficient to do step 2. There is an implicit rule ".c.o:" that triggers no matter what I try, and I don't want to add explicit $(COMPILER) rules for all the front end objects. $(ALL_HOST_FRONTEND_OBJS): ALL_CFLAGS += -DIN_GCC_FRONTEND ? Paolo
GCC4.3.4 downside against GCC3.4.4 on mips?
Hi all, I compared assembly files of a function compiled by GCC4.3.4 and GCC3.4.4. The function focuses on array computation and has no branch, or any loop structure, The command line is like "-march=mips32r2 -O3", and here is the instruction statics: total: 1879 : 1534 addiu :6 :6 addu : 216 : 129 jr :1 :1 lui :5:5 lw : 396 : 353 madd : 41 :0 mfhi: 80 : 80 mflo: 121 : 86 move :0: 21 mtlo : 39 :0 mul : 85 :0 mult : 18 : 80 multu : 64 :0 or: 80 : 80 sll : 80 : 80 sra : 79 : 47 srl: 80 : 80 subu : 80 : 80 sw : 408 : 406 Considering there is no any branch or loop structure ,It seems result of GCC3.4.4 is much better, since generating much less instructions. secondly, GCC4.3.4 does consume less stack slots(1224 bytes against 1408). So, any comments? Thanks in advance. -- Best Regards.
Re: Help needed: banishing RTL from the front ends
On Tue, May 25, 2010 at 9:56 AM, Paolo Bonzini wrote: > On 05/25/2010 09:55 AM, Steven Bosscher wrote: >> >> 1) Group front end objects in Makefile.in under e.g. >> ALL_HOST_FRONTEND_OBJS >> 2) Add a new build rule that adds an extra define -DIN_GCC_FRONTEND >> 3) Conditionally poison symbols in system.h >> >> For the last step, that would be e.g.: >> #ifdef IN_GCC_FRONTEND >> #pragma GCC poison GCC_RTL_H GCC_REGS_H ... >> #endif >> >> Unfortunately, my Makefile-fu is insufficient to do step 2. There is >> an implicit rule ".c.o:" that triggers no matter what I try, and I >> don't want to add explicit $(COMPILER) rules for all the front end >> objects. > > $(ALL_HOST_FRONTEND_OBJS): ALL_CFLAGS += -DIN_GCC_FRONTEND > > ? Hmm, the following *almost* works... - 8< Index: Makefile.in === --- Makefile.in (revision 159808) +++ Makefile.in (working copy) @@ -1445,12 +1445,18 @@ OBJS = $(OBJS-common) $(OBJS-md) $(OBJS- OBJS-onestep = libbackend.o $(OBJS-archive) +# This lists all host objects for the front ends. Extra defines are passed +# to the compiler for these objects. +ALL_HOST_FRONTEND_OBJS = $(C_OBJS) + $(foreach v,$(CONFIG_LANGUAGES),$($(v)_OBJS)) + +$(ALL_HOST_FRONTEND_OBJS): ALL_CFLAGS += -DIN_GCC_FRONTEND + # This lists all host object files, whether they are included in this # compilation or not. -ALL_HOST_OBJS = $(GCC_OBJS) $(C_OBJS) $(OBJS) libbackend.o \ +ALL_HOST_OBJS = $(GCC_OBJS) $(OBJS) libbackend.o \ @TREEBROWSER@ main.o gccspec.o version.o intl.o prefix.o cppspec.o \ - $(foreach v,$(CONFIG_LANGUAGES),$($(v)_OBJS)) \ - $(COLLECT2_OBJS) $(EXTRA_GCC_OBJS) \ + $(ALL_HOST_FRONTEND_OBJS) $(COLLECT2_OBJS) $(EXTRA_GCC_OBJS) \ mips-tfile.o mips-tdump.o \ $(GCOV_OBJS) $(GCOV_DUMP_OBJS) - 8< But for some reason I get -DIN_GCC_FRONTEND also on some of the gen* files, libiberty, and gcov-io.o, like so: gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -Wold-style-definition -Wc++-compat -DHAVE_CONFIG_H -DIN_GCC_FRONTEND -DGENERATOR_FILE -I. -Ibuild -I../../trunk/gcc -I../../trunk/gcc/build -I../../trunk/gcc/../include -I../../trunk/gcc/../libcpp/include -I/opt/cfarm/gmp-4.2.4/include -I/opt/cfarm/mpfr-2.4.1/include -I/opt/cfarm/mpc-0.8/include -I../../trunk/gcc/../libdecnumber -I../../trunk/gcc/../libdecnumber/bid -I../libdecnumber -I/opt/cfarm/libelf-0.8.12//include -I/opt/cfarm/libelf-0.8.12//include/libelf \ -o build/genmodes.o ../../trunk/gcc/genmodes.c The -DIN_GCC_FRONTEND is not passed to middle-end objects, so there must somehow be a dependency on the generator files from the front ends, that I don't see here. I configured with "--enable-languages=c,objc,fortran". I don't see any dependencies in the front end files: # Target specific, C specific object file c_target_ob...@c_target_objs@ # Language-specific object files for C and Objective C. C_AND_OBJC_OBJS = attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o \ c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o c-semantics.o \ c-ppoutput.o c-cppbuiltin.o \ c-objc-common.o c-dump.o c-pch.o c-parser.o $(C_TARGET_OBJS) \ c-gimplify.o tree-mudflap.o c-pretty-print.o c-omp.o # Language-specific object files for C. C_OBJS = c-lang.o stub-objc.o $(C_AND_OBJC_OBJS) # Language-specific object files for Objective C. OBJC_OBJS = objc/objc-lang.o objc/objc-act.o # These are the groups of object files we have. The F95_PARSER_OBJS are # all the front end files, the F95_OBJS are the files for the translation # from the parse tree to GENERIC F95_PARSER_OBJS = fortran/arith.o fortran/array.o fortran/bbt.o \ fortran/check.o fortran/class.o fortran/constructor.o fortran/cpp.o \ fortran/data.o fortran/decl.o fortran/dump-parse-tree.o fortran/error.o \ fortran/expr.o fortran/interface.o fortran/intrinsic.o fortran/io.o \ fortran/iresolve.o fortran/match.o fortran/matchexp.o fortran/misc.o \ fortran/module.o fortran/openmp.o fortran/options.o fortran/parse.o \ fortran/primary.o fortran/resolve.o fortran/scanner.o fortran/simplify.o \ fortran/st.o fortran/symbol.o fortran/target-memory.o F95_OBJS = $(F95_PARSER_OBJS) $(FORTRAN_TARGET_OBJS) \ fortran/convert.o fortran/dependency.o fortran/f95-lang.o \ fortran/trans.o fortran/trans-array.o fortran/trans-common.o \ fortran/trans-const.o fortran/trans-decl.o fortran/trans-expr.o \ fortran/trans-intrinsic.o fortran/trans-io.o fortran/trans-openmp.o \ fortran/trans-stmt.o fortran/trans-types.o I am guessing this comes in from the $C_TARGET_OBJS and other language target objects. In the Makefile in the build directory I have this dependency: Target specific, C specific object file C_TARGET_OBJS=i386-c.o But unfortunately I cannot find the rule for this obje
Re: Help needed: banishing RTL from the front ends
On 25/05/2010 09:44, Steven Bosscher wrote: > +# This lists all host objects for the front ends. Extra defines are passed > +# to the compiler for these objects. > +ALL_HOST_FRONTEND_OBJS = $(C_OBJS) > + $(foreach v,$(CONFIG_LANGUAGES),$($(v)_OBJS)) > + Missing line-continuation backslash there, surely? > Any suggestions how to debug this? "remake -x" is pretty much the only tool I've ever needed even for debugging the most complex makefile problems. http://bashdb.sourceforge.net/remake/ cheers, DaveK
[wwwdocs] PATCH for Re: FAQ conflict
On Thu, 13 May 2010, Todd Rinaldo wrote: > Your FAQ at the below URLS conflicts as to which autoconf should be > used. one says 2.13 th other says 2.64. 2.65 is currently available. > > http://gcc.gnu.org/faq.html#generated_files > > http://gcc.gnu.org/install/prerequisites.html Thanks for your report, Todd. You are right, and the FAQ is out of date whereas the installation documentation is correct. I am updating FAQ per the patch below, and if you got to http://gcc.gnu.org/faq.html#generated_files you will see the new (and shorter) version already which now directly refers to the installation documentation. I hope this addresses the issue you have been seeing? Gerald Index: faq.html === RCS file: /cvs/gcc/wwwdocs/htdocs/faq.html,v retrieving revision 1.209 diff -u -3 -p -r1.209 faq.html --- faq.html3 May 2010 13:47:48 - 1.209 +++ faq.html25 May 2010 08:54:05 - @@ -475,19 +475,9 @@ those generated files are out of date an script in the contrib subdirectory of GCC, which handles this transparently without requiring installation of any additional tools. - -When building from diffs or SVN or if you modified some sources, -you may also need to obtain development versions of some GNU tools, as -the production versions do not necessarily handle all features needed -to rebuild GCC. - -In general, the current versions of these tools from ftp://ftp.gnu.org/gnu/";>ftp://ftp.gnu.org/gnu/ will work. -At present, Autoconf 2.50 is not supported, and you will need to use -Autoconf 2.13; work is in progress to fix this problem. Also look at -ftp://gcc.gnu.org/pub/gcc/infrastructure/";> -ftp://gcc.gnu.org/pub/gcc/infrastructure/ for any special versions -of packages. +If you modified some sources or when building from SVN you may also +need http://gcc.gnu.org/install/prerequisites.html#TOC1";>some +additional tools.
Re: Help needed: banishing RTL from the front ends
Steven Bosscher writes: > But for some reason I get -DIN_GCC_FRONTEND also on some of the gen* > files, libiberty, and gcov-io.o, like so: Target-specific variable values are applied to all dependencies, see (make) Target-specific: There is one more special feature of target-specific variables: when you define a target-specific variable that variable value is also in effect for all prerequisites of this target, and all their prerequisites, etc. (unless those prerequisites override that variable with their own target-specific variable value). Andreas. -- Andreas Schwab, sch...@redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E "And now for something completely different."
Melt-building problem
Hello, I tried to compile the gcc-melt branch from svn, but i get the following error: make warmelt1 make[4]: Entering directory `/home/wolfgang/gcc-melt/objects/gcc' date +"/* empty-file-for-melt.c %c */" > empty-file-for-melt.c-tmp /bin/bash ../../melt-branch/gcc/../move-if-change empty-file-for-melt.c-tmp empty-file-for-melt.c make -f ../../melt-branch/gcc/melt-module.mk VPATH=../../melt-branch/gcc:. meltmodule \ GCCMELT_CFLAGS="-g -O2 -fomit-frame-pointer -g -g -O2 -fomit-frame-pointer -gtoggle -DIN_GCC -DHAVE_CONFIG_H -I melt-private-build-include -I." \ GCCMELT_MODULE_SOURCE=../../melt-branch/gcc/melt/generated/warmelt-first.0.c GCCMELT_MODULE_BINARY=warmelt-first.0.so make[5]: Entering directory `/home/wolfgang/gcc-melt/objects/gcc' gcc -g -O2 -fomit-frame-pointer -g -g -O2 -fomit-frame-pointer -gtoggle -DIN_GCC -DHAVE_CONFIG_H -I melt-private-build-include -I. -fPIC -c -o warmelt-first.0.pic.o ../../melt-branch/gcc/melt/generated//warmelt-first.0.c cc1: error: unrecognised debug output level "toggle" make[5]: *** [warmelt-first.0.pic.o] Fehler 1 make[5]: Leaving directory `/home/wolfgang/gcc-melt/objects/gcc' make[4]: *** [warmelt-first.0.so] Fehler 2 make[4]: Leaving directory `/home/wolfgang/gcc-melt/objects/gcc' make[3]: *** [melt.encap] Fehler 2 make[3]: Leaving directory `/home/wolfgang/gcc-melt/objects/gcc' make[2]: *** [all-stage2-gcc] Fehler 2 make[2]: Leaving directory `/home/wolfgang/gcc-melt/objects' make[1]: *** [stage2-bubble] Fehler 2 make[1]: Leaving directory `/home/wolfgang/gcc-melt/objects' make: *** [all] Fehler 2 wolfg...@debian:~/gcc-melt/objects$ any advice? Thanks Wolfgang -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
Help with expanding compare
Hello, I am using current mainline to compile a testcase which contains a loop. The target I'm working on supports cmpsi pattern. While expanding the loop condition I get that do_compare_rtx_and_jump () and do_jump_by_parts_greater_rtx () call each other repeatedly. The test I'm compiling passes OK when using GCC 4.4. Looking into the difference between the two versions that might caused this problem; I see that in GCC4.4 can_compare_p () asks if the target supports cmp_optab. while GCC4.6 does not ask for this opcode and thus IIUC causes the later call to do_jump_by_parts_greater_rtx (). I appreciate any help with this problem. Thanks, Revital
Re: Help needed: banishing RTL from the front ends
On Tue, 25 May 2010, Steven Bosscher wrote: > I am guessing this comes in from the $C_TARGET_OBJS and other language > target objects. In the Makefile in the build directory I have this > dependency: > > Target specific, C specific object file > C_TARGET_OBJS=i386-c.o > > But unfortunately I cannot find the rule for this object. It's in config/i386/t-i386. And such files shouldn't really be using RTL themselves. They are for pragmas, assertions, aspects of built-in functions that need handing at front-end time, controlling extensions for the C language, ... - all things that should be completed before the conversion to RTL. (It's possible that some of them may store information for use by later stages of the compiler, but the code processing that information should be language-independent.) -- Joseph S. Myers jos...@codesourcery.com
Re: Help needed: banishing RTL from the front ends
On Tue, May 25, 2010 at 2:25 PM, Joseph S. Myers wrote: > On Tue, 25 May 2010, Steven Bosscher wrote: > >> I am guessing this comes in from the $C_TARGET_OBJS and other language >> target objects. In the Makefile in the build directory I have this >> dependency: >> >> Target specific, C specific object file >> C_TARGET_OBJS=i386-c.o >> >> But unfortunately I cannot find the rule for this object. > > It's in config/i386/t-i386. Right. I found that out in the mean time with good-old grep. There are many targets with C_TARGET_OBJS and CXX_TARGET_OBJS, and one target with FORTRAN_TARGET_OBJS (which should be turned into targetcm hooks, I think). > And such files shouldn't really be using RTL > themselves. They are for pragmas, assertions, aspects of built-in > functions that need handing at front-end time, controlling extensions for > the C language, ... - all things that should be completed before the > conversion to RTL. (It's possible that some of them may store information > for use by later stages of the compiler, but the code processing that > information should be language-independent.) Yes, and it looks like for the most part the dependencies on back-end code are false (just like for the front ends) but some appear to be real. I will first do this for the primary targets and then look at the rest. I could use some help with that... Just means the banishing of RTL from the front ends will have to wait a little bit longer. Ciao! Steven
Re: GCC4.3.4 downside against GCC3.4.4 on mips?
On Tue, 25 May 2010 16:28:37 +0800, "Amker.Cheng" wrote: > Hi all, > I compared assembly files of a function compiled by GCC4.3.4 and > GCC3.4.4. > The function focuses on array computation and has no branch, or any > loop structure, > The command line is like "-march=mips32r2 -O3", and here is the > instruction statics: > > total: 1879 : 1534 > addiu :6 :6 > addu : 216 : 129 > jr :1 :1 > lui :5:5 > lw : 396 : 353 > madd : 41 :0 > mfhi: 80 : 80 > mflo: 121 : 86 > move :0: 21 > mtlo : 39 :0 > mul : 85 :0 > mult : 18 : 80 >multu : 64 :0 > or: 80 : 80 > sll : 80 : 80 > sra : 79 : 47 > srl: 80 : 80 > subu : 80 : 80 > sw : 408 : 406 > > Considering there is no any branch or loop structure ,It seems result > of GCC3.4.4 > is much better, since generating much less instructions. > > secondly, GCC4.3.4 does consume less stack slots(1224 bytes against 1408). > > So, any comments? Thanks in advance. Posting some random numbers without a test-case and precise command line parameters for both compilers makes the numbers useless, IMHO. You also only mention instruction counts. Have you actually benchmarked the resulting code? CPUs are complicated and what you might perceive as worse code might actually be superior thanks to scheduling and internal CPU parallelism etc. -- VH
Re: Help with expanding compare
On 05/25/2010 12:13 PM, Revital1 Eres wrote: Hello, I am using current mainline to compile a testcase which contains a loop. The target I'm working on supports cmpsi pattern. While expanding the loop condition I get that do_compare_rtx_and_jump () and do_jump_by_parts_greater_rtx () call each other repeatedly. The test I'm compiling passes OK when using GCC 4.4. Looking into the difference between the two versions that might caused this problem; I see that in GCC4.4 can_compare_p () asks if the target supports cmp_optab. while GCC4.6 does not ask for this opcode and thus IIUC causes the later call to do_jump_by_parts_greater_rtx (). Have you converted cmpsi to cbranchsi4? Paolo
Re: Help with expanding compare
Hello, Just did so... :-) and it indeed solves this. Thanks, Revital From: Paolo Bonzini To: Revital1 Eres/Haifa/i...@ibmil Cc: gcc@gcc.gnu.org Date: 25/05/2010 03:57 PM Subject:Re: Help with expanding compare Sent by:Paolo Bonzini On 05/25/2010 12:13 PM, Revital1 Eres wrote: > > Hello, > > I am using current mainline to compile a testcase which contains a loop. > The target I'm working on supports cmpsi pattern. > > While expanding the loop condition I get that do_compare_rtx_and_jump () > and > do_jump_by_parts_greater_rtx () call each other repeatedly. > > The test I'm compiling passes OK when using GCC 4.4. Looking into the > difference between the two versions that might caused this problem; > I see that in GCC4.4 can_compare_p () asks if the target supports > cmp_optab. while GCC4.6 does not ask for this opcode and thus IIUC causes > the later call to do_jump_by_parts_greater_rtx (). Have you converted cmpsi to cbranchsi4? Paolo
Re: Help with expanding compare
On 05/25/2010 03:01 PM, Revital1 Eres wrote: Hello, Just did so... :-) and it indeed solves this. Remember to do the same for cstore. Most of the time it will remove more code from your target than it adds. I think that it did so for basically all targets in GCC 4.5, sometimes cutting up to 1000 lines for no change in generated code. The only exception was spu IIRC, which gained maybe 30 lines. Paolo
Re: Melt-building problem
On Tue, 2010-05-25 at 12:03 +0200, Wolfgang wrote:
> Hello,
>
> I tried to compile the gcc-melt branch from svn,
A big thanks for testing GCC MELT! What svn revision of the MELT branch
are you testing? Did you configure gcc-melt with --enable-bootstrap?
Can you reproduce the bug inside a clean build tree? (I mean, removing
all your build tree, and start again the configure & the build)
> but i get the following error:
>
>
> make warmelt1
> make[4]: Entering directory `/home/wolfgang/gcc-melt/objects/gcc'
> date +"/* empty-file-for-melt.c %c */" > empty-file-for-melt.c-tmp
> /bin/bash ../../melt-branch/gcc/../move-if-change empty-file-for-melt.c-tmp
> empty-file-for-melt.c
> make -f ../../melt-branch/gcc/melt-module.mk VPATH=../../melt-branch/gcc:.
> meltmodule \
> GCCMELT_CFLAGS="-g -O2 -fomit-frame-pointer -g -g -O2
> -fomit-frame-pointer -gtoggle -DIN_GCC -DHAVE_CONFIG_H -I
> melt-private-build-include -I." \
>
> GCCMELT_MODULE_SOURCE=../../melt-branch/gcc/melt/generated/warmelt-first.0.c
> GCCMELT_MODULE_BINARY=warmelt-first.0.so
> make[5]: Entering directory `/home/wolfgang/gcc-melt/objects/gcc'
> gcc -g -O2 -fomit-frame-pointer -g -g -O2 -fomit-frame-pointer -gtoggle
> -DIN_GCC -DHAVE_CONFIG_H -I melt-private-build-include -I. -fPIC -c -o
> warmelt-first.0.pic.o ../../melt-branch/gcc/melt/generated//warmelt-first.0.c
> cc1: error: unrecognised debug output level "toggle"
Which gcc is this one? (What does gcc -v tells you?).
I hoped to have corrected this bug by adding the MELTHERE_CFLAGS in GCC
MELT's gcc/Makefile.in near line 5076. I am not a guru in autoconf + GNU
make tricks. Apparently, something is still wrong.
A dirty workaround might be to replace every -gtoggle occurrence in the
build tree gcc/Makefile with -g.
I will try to reproduce that bug!
Thanks for reporting it.
BTW, I am surprised that GCC (even a plain 4.4 or 4.5) issues an error
for an unrecognised debug output level. I would imagine it would in that
case issue a warning, and try to do what -g does...
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: Help needed: banishing RTL from the front ends
On Tue, May 25, 2010 at 11:13 AM, Andreas Schwab wrote: > Steven Bosscher writes: > >> But for some reason I get -DIN_GCC_FRONTEND also on some of the gen* >> files, libiberty, and gcov-io.o, like so: > > Target-specific variable values are applied to all dependencies, see > (make) Target-specific: > > There is one more special feature of target-specific variables: when > you define a target-specific variable that variable value is also in > effect for all prerequisites of this target, and all their > prerequisites, etc. (unless those prerequisites override that variable > with their own target-specific variable value). That is the problem here. TM_H depends on insn-constants.h, which depends on genconstants: TM_H = $(GTM_H) insn-constants.h insn-flags.h options.h No need to remake target `../../trunk/gcc/coretypes.h'. Considering target file `tm.h'. ... Considering target file `options.h'. ... Considering target file `insn-constants.h'. File `insn-constants.h' does not exist. Considering target file `s-constants'. File `s-constants' does not exist. Considering target file `build/genconstants'. File `build/genconstants' does not exist. Looking for an implicit rule for `build/genconstants'. Trying pattern rule with stem `constants'. Trying implicit prerequisite `build/genconstants.o'. Trying rule prerequisite `../build-x86_64-unknown-linux-gnu/libiberty/libiberty.a'. Found an implicit rule for `build/genconstants'. Considering target file `build/genconstants.o'. ... Lots of files validly depend on TM_H (directly, or via target.h). So I guess this plan of mine is not going to work... Other ideas? Ciao! Steven
Re: Help needed: banishing RTL from the front ends
Steven Bosscher wrote: > The first thing I'd like to do now, is banish RTL from the front end. Certainly a desirable goal! (I did a bit of this in the C++ front-end a while back, though nothing as formal or complete as what you are suggesting. There used to be various places where the front end would peek at the RTL generated for global variables and such.) > 1) Group front end objects in Makefile.in under e.g. ALL_HOST_FRONTEND_OBJS > 2) Add a new build rule that adds an extra define -DIN_GCC_FRONTEND > 3) Conditionally poison symbols in system.h This seems like a reasonable plan to me. It will, of course, take some work to achieve, but in concept I completely agree that the front ends should have no knowledge whatsoever of RTL. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: Help needed: banishing RTL from the front ends
* Steven Bosscher wrote on Tue, May 25, 2010 at 04:23:35PM CEST: > On Tue, May 25, 2010 at 11:13 AM, Andreas Schwab wrote: > > Target-specific variable values are applied to all dependencies, see > > (make) Target-specific: [...] > That is the problem here. TM_H depends on insn-constants.h, which > depends on genconstants: [...] > > Lots of files validly depend on TM_H (directly, or via target.h). What's more, the order-only prerequisite $(ALL_HOST_OBJS) : | $(generated_files) may (eventually) bite you, too. This GNU make semantic does not seem very intuitive. > So I guess this plan of mine is not going to work... > Other ideas? Well, you could override the overridden variable for the dependencies yet again. Cheers, Ralf
Re: Help needed: banishing RTL from the front ends
On Tue, May 25, 2010 at 4:28 PM, Ralf Wildenhues wrote: > * Steven Bosscher wrote on Tue, May 25, 2010 at 04:23:35PM CEST: >> On Tue, May 25, 2010 at 11:13 AM, Andreas Schwab wrote: >> > Target-specific variable values are applied to all dependencies, see >> > (make) Target-specific: > [...] >> That is the problem here. TM_H depends on insn-constants.h, which >> depends on genconstants: > [...] >> >> Lots of files validly depend on TM_H (directly, or via target.h). > > What's more, the order-only prerequisite > > $(ALL_HOST_OBJS) : | $(generated_files) I can use that to my advantage if I turn the logic around, as in the attached patch. With this, I get all gen* files and libiberty built without trouble, and the build stops on the first front-end file that includes rtl.h (attribs.h, which btw doesn't have to include it). Ciao! Steven Index: Makefile.in === --- Makefile.in (revision 159808) +++ Makefile.in (working copy) @@ -1445,15 +1445,22 @@ OBJS = $(OBJS-common) $(OBJS-md) $(OBJS- OBJS-onestep = libbackend.o $(OBJS-archive) -# This lists all host object files, whether they are included in this -# compilation or not. -ALL_HOST_OBJS = $(GCC_OBJS) $(C_OBJS) $(OBJS) libbackend.o \ +# This lists all host objects for the front ends. Extra defines are passed +# to the compiler for these objects. +ALL_HOST_FRONTEND_OBJS = $(C_OBJS) + $(foreach v,$(CONFIG_LANGUAGES),$($(v)_OBJS)) + +ALL_HOST_BACKEND_OBJS = $(GCC_OBJS) $(OBJS) libbackend.o \ @TREEBROWSER@ main.o gccspec.o version.o intl.o prefix.o cppspec.o \ - $(foreach v,$(CONFIG_LANGUAGES),$($(v)_OBJS)) \ - $(COLLECT2_OBJS) $(EXTRA_GCC_OBJS) \ - mips-tfile.o mips-tdump.o \ + $(COLLECT2_OBJS) $(EXTRA_GCC_OBJS) mips-tfile.o mips-tdump.o \ $(GCOV_OBJS) $(GCOV_DUMP_OBJS) +$(ALL_HOST_BACKEND_OBJS): ALL_CFLAGS += -DIN_GCC_BACKEND + +# This lists all host object files, whether they are included in this +# compilation or not. +ALL_HOST_OBJS = $(ALL_HOST_FRONTEND_OBJS) $(ALL_HOST_BACKEND_OBJS) + BACKEND = main.o @TREEBROWSER@ libbackend.a $(CPPLIB) $(LIBDECNUMBER) MOSTLYCLEANFILES = insn-flags.h insn-config.h insn-codes.h \ @@ -2075,7 +2082,7 @@ c-cppbuiltin.o : c-cppbuiltin.c $(CONFIG # A file used by all variants of C and some other languages. attribs.o : attribs.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) $(TREE_H) \ - $(FLAGS_H) $(TOPLEV_H) output.h $(RTL_H) $(GGC_H) $(TM_P_H) \ + $(FLAGS_H) $(TOPLEV_H) output.h $(GGC_H) $(TM_P_H) \ $(TARGET_H) langhooks.h $(CPPLIB_H) $(PLUGIN_H) c-format.o : c-format.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) $(TREE_H) langhooks.h \ Index: system.h === --- system.h(revision 159808) +++ system.h(working copy) @@ -789,6 +789,10 @@ extern void fancy_abort (const char *, i VA_FIXEDARG VA_CLOSE VA_START #endif /* IN_GCC */ +#if !defined(IN_GCC_BACKEND) && !defined(GENERATOR_FILE) +#pragma GCC poison GCC_RTL_H +#endif + /* Note: not all uses of the `index' token (e.g. variable names and structure members) have been eliminated. */ #undef bcopy
Re: Melt-building problem
On Tue, 2010-05-25 at 16:20 +0200, Basile Starynkevitch wrote:
>
> A dirty workaround might be to replace every -gtoggle occurrence in the
> build tree gcc/Makefile with -g.
Another slightly less dirty workaround, assuming that gcc-4.5 is
available on your machine, is to set the GCCMELT_CC environment variable
to gcc-4.5 (this environment variable may set the compiler used to
compile MELT generated C code).
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: Help needed: banishing RTL from the front ends
Steven Bosscher writes: > So I guess this plan of mine is not going to work... > Other ideas? Add $(CFLAGS-$(@F)) to the .c.o rule and define CFLAGS-foo for each foo in $(ALL_HOST_FRONTEND_OBJS). Though the latter is a bit tricky if you want to do it automatically. Andreas. -- Andreas Schwab, sch...@redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E "And now for something completely different."
Re: Help needed: banishing RTL from the front ends
On Tue, May 25, 2010 at 16:59, Andreas Schwab wrote: > Steven Bosscher writes: > >> So I guess this plan of mine is not going to work... >> Other ideas? > > Add $(CFLAGS-$(@F)) to the .c.o rule Actually $@ is fine, since you want cp/tree.o to have different flags from tree.o. > and define CFLAGS-foo for each foo > in $(ALL_HOST_FRONTEND_OBJS). Though the latter is a bit tricky if you > want to do it automatically. That would be something like $(foreach file,$(ALL_HOST_FRONTEND_OBJS),$(eval CFLAGS-$(file) += ...)) (All on one line, no spaces after commas!) Paolo
Re: Melt-building problem
Original-Nachricht
> Datum: Tue, 25 May 2010 16:20:14 +0200
> Von: Basile Starynkevitch
> An: Wolfgang
> CC: gcc@gcc.gnu.org
> Betreff: Re: Melt-building problem
> On Tue, 2010-05-25 at 12:03 +0200, Wolfgang wrote:
> > Hello,
> >
> > I tried to compile the gcc-melt branch from svn,
>
> A big thanks for testing GCC MELT! What svn revision of the MELT branch
> are you testing? Did you configure gcc-melt with --enable-bootstrap?
>
> Can you reproduce the bug inside a clean build tree? (I mean, removing
> all your build tree, and start again the configure & the build)
yes, it is reproduceable...i cleaned all and tried to build that new
>
> > but i get the following error:
> >
> >
> > make warmelt1
> > make[4]: Entering directory `/home/wolfgang/gcc-melt/objects/gcc'
> > date +"/* empty-file-for-melt.c %c */" > empty-file-for-melt.c-tmp
> > /bin/bash ../../melt-branch/gcc/../move-if-change
> empty-file-for-melt.c-tmp empty-file-for-melt.c
> > make -f ../../melt-branch/gcc/melt-module.mk
> VPATH=../../melt-branch/gcc:. meltmodule \
> > GCCMELT_CFLAGS="-g -O2 -fomit-frame-pointer -g -g -O2
> -fomit-frame-pointer -gtoggle -DIN_GCC -DHAVE_CONFIG_H -I
> melt-private-build-include
> -I." \
> >
> GCCMELT_MODULE_SOURCE=../../melt-branch/gcc/melt/generated/warmelt-first.0.c
> GCCMELT_MODULE_BINARY=warmelt-first.0.so
> > make[5]: Entering directory `/home/wolfgang/gcc-melt/objects/gcc'
> > gcc -g -O2 -fomit-frame-pointer -g -g -O2 -fomit-frame-pointer -gtoggle
> -DIN_GCC -DHAVE_CONFIG_H -I melt-private-build-include -I. -fPIC -c -o
> warmelt-first.0.pic.o ../../melt-branch/gcc/melt/generated//warmelt-first.0.c
> > cc1: error: unrecognised debug output level "toggle"
>
> Which gcc is this one? (What does gcc -v tells you?).
At the moment, i have the gcc 4.4 installed:
wolfg...@debian:~/gcc-melt/objects$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.4-1'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--enable-multiarch --enable-linker-build-id --with-system-zlib
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
--enable-targets=all --with-arch-32=i486 --with-tune=generic
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--target=i486-linux-gnu
Thread model: posix
gcc version 4.4.4 (Debian 4.4.4-1)
The Melt-Branch was configuired with:
../melt-branch/configure --enable-languages=c,c++ --enable-shared
--enable-threads=posix --enable-nls --enable-objc-gc --enable-mpfr
--prefix=/usr/lib/test2 --enable-plugin --enable-lto --with-ppl
--enable-bootstrap
I now tried to compile it with the new gcc-4.5
Thanks
Wolfgang
>
> I hoped to have corrected this bug by adding the MELTHERE_CFLAGS in GCC
> MELT's gcc/Makefile.in near line 5076. I am not a guru in autoconf + GNU
> make tricks. Apparently, something is still wrong.
>
> A dirty workaround might be to replace every -gtoggle occurrence in the
> build tree gcc/Makefile with -g.
>
> I will try to reproduce that bug!
>
> Thanks for reporting it.
>
>
> BTW, I am surprised that GCC (even a plain 4.4 or 4.5) issues an error
> for an unrecognised debug output level. I would imagine it would in that
> case issue a warning, and try to do what -g does...
>
> Cheers.
>
>
> --
> Basile STARYNKEVITCH http://starynkevitch.net/Basile/
> email: basilestarynkevitchnet mobile: +33 6 8501 2359
> 8, rue de la Faiencerie, 92340 Bourg La Reine, France
> *** opinions {are only mines, sont seulement les miennes} ***
>
--
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
Re: Melt-building problem
On Tue, 2010-05-25 at 17:09 +0200, Wolfgang wrote:
> Original-Nachricht
> > Datum: Tue, 25 May 2010 16:20:14 +0200
> > Von: Basile Starynkevitch
> > An: Wolfgang
> > CC: gcc@gcc.gnu.org
> > Betreff: Re: Melt-building problem
>
> > On Tue, 2010-05-25 at 12:03 +0200, Wolfgang wrote:
> > > Hello,
> > >
> > > I tried to compile the gcc-melt branch from svn,
> >
> > A big thanks for testing GCC MELT! What svn revision of the MELT branch
> > are you testing? Did you configure gcc-melt with --enable-bootstrap?
> >
> > Can you reproduce the bug inside a clean build tree? (I mean, removing
> > all your build tree, and start again the configure & the build)
> yes, it is reproduceable...i cleaned all and tried to build that new
>
> >
> > > but i get the following error:
> > >
> > >
> > > make warmelt1
> > > make[4]: Entering directory `/home/wolfgang/gcc-melt/objects/gcc'
> > > date +"/* empty-file-for-melt.c %c */" > empty-file-for-melt.c-tmp
> > > /bin/bash ../../melt-branch/gcc/../move-if-change
> > empty-file-for-melt.c-tmp empty-file-for-melt.c
> > > make -f ../../melt-branch/gcc/melt-module.mk
> > VPATH=../../melt-branch/gcc:. meltmodule \
> > > GCCMELT_CFLAGS="-g -O2 -fomit-frame-pointer -g -g -O2
> > -fomit-frame-pointer -gtoggle -DIN_GCC -DHAVE_CONFIG_H -I
> > melt-private-build-include
> > -I." \
> > >
> > GCCMELT_MODULE_SOURCE=../../melt-branch/gcc/melt/generated/warmelt-first.0.c
> > GCCMELT_MODULE_BINARY=warmelt-first.0.so
> > > make[5]: Entering directory `/home/wolfgang/gcc-melt/objects/gcc'
> > > gcc -g -O2 -fomit-frame-pointer -g -g -O2 -fomit-frame-pointer -gtoggle
> > -DIN_GCC -DHAVE_CONFIG_H -I melt-private-build-include -I. -fPIC -c -o
> > warmelt-first.0.pic.o
> > ../../melt-branch/gcc/melt/generated//warmelt-first.0.c
> > > cc1: error: unrecognised debug output level "toggle"
> >
> > Which gcc is this one? (What does gcc -v tells you?).
> At the moment, i have the gcc 4.4 installed:
> wolfg...@debian:~/gcc-melt/objects$ gcc -v
> Using built-in specs.
> Target: i486-linux-gnu
> Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.4-1'
> --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
> --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
> --enable-multiarch --enable-linker-build-id --with-system-zlib
> --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
> --with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4
> --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
> --enable-targets=all --with-arch-32=i486 --with-tune=generic
> --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
> --target=i486-linux-gnu
> Thread model: posix
> gcc version 4.4.4 (Debian 4.4.4-1)
>
> The Melt-Branch was configuired with:
> ../melt-branch/configure --enable-languages=c,c++ --enable-shared
> --enable-threads=posix --enable-nls --enable-objc-gc --enable-mpfr
> --prefix=/usr/lib/test2 --enable-plugin --enable-lto --with-ppl
> --enable-bootstrap
>
> I now tried to compile it with the new gcc-4.5
I am trying right now to build it from scratch, using my
Ubuntu/Lucid/amd64 default compiler (a 4.4.3).
Maybe --disable-bootstrap at the configure might help to.
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: Melt-building problem
On Tue, 2010-05-25 at 17:09 +0200, Wolfgang wrote: > Original-Nachricht > > Datum: Tue, 25 May 2010 16:20:14 +0200 > > Von: Basile Starynkevitch > > An: Wolfgang > > CC: gcc@gcc.gnu.org > > Betreff: Re: Melt-building problem > > > On Tue, 2010-05-25 at 12:03 +0200, Wolfgang wrote: > > > Hello, > > > > > > I tried to compile the gcc-melt branch from svn, It could happen that Wolfgang is hacking inside the MELT runtime to add support for loop-s. > > > > > but i get the following error: > > > > > > > > > make warmelt1 > > > make[4]: Entering directory `/home/wolfgang/gcc-melt/objects/gcc' > > > date +"/* empty-file-for-melt.c %c */" > empty-file-for-melt.c-tmp > > > /bin/bash ../../melt-branch/gcc/../move-if-change > > empty-file-for-melt.c-tmp empty-file-for-melt.c > > > make -f ../../melt-branch/gcc/melt-module.mk > > VPATH=../../melt-branch/gcc:. meltmodule \ > > > GCCMELT_CFLAGS="-g -O2 -fomit-frame-pointer -g -g -O2 > > -fomit-frame-pointer -gtoggle -DIN_GCC -DHAVE_CONFIG_H -I > > melt-private-build-include > > -I." \ > > > > > GCCMELT_MODULE_SOURCE=../../melt-branch/gcc/melt/generated/warmelt-first.0.c > > GCCMELT_MODULE_BINARY=warmelt-first.0.so > > > make[5]: Entering directory `/home/wolfgang/gcc-melt/objects/gcc' > > > gcc -g -O2 -fomit-frame-pointer -g -g -O2 -fomit-frame-pointer -gtoggle > > -DIN_GCC -DHAVE_CONFIG_H -I melt-private-build-include -I. -fPIC -c -o > > warmelt-first.0.pic.o > > ../../melt-branch/gcc/melt/generated//warmelt-first.0.c > > > cc1: error: unrecognised debug output level "toggle" Perhaps re-merging the current MELT branch into your private branch (assuming you have a private MELT variant) might help, because on my side with GCCMELT_CC set to gcc-4.5 the make log contains make warmelt1 make[4]: Entering directory `/usr/src/Lang/_MeltBoot/Obj/gcc' date +"/* empty-file-for-melt.c %c */" > empty-file-for-melt.c-tmp /bin/bash ../../melt-branch/gcc/../move-if-change empty-file-for-melt.c-tmp empty-file-for-melt.c make -f ../../melt-branch/gcc/melt-module.mk VPATH=../../melt-branch/gcc:. meltmodule \ GCCMELT_CFLAGS="-g -fkeep-inline-functions -g -fkeep-inline-functions -DIN_GCC -DHAVE_CONFIG_H -I melt-private-build-include -I." \ GCCMELT_MODULE_SOURCE=../../melt-branch/gcc/melt/generated/warmelt-first.0.c GCCMELT_MODULE_BINARY=warmelt-first.0.so make[5]: Entering directory `/usr/src/Lang/_MeltBoot/Obj/gcc' gcc-4.5 -g -fkeep-inline-functions -g -fkeep-inline-functions -DIN_GCC -DHAVE_CONFIG_H -I melt-private-build-include -I. -fPIC -c -o warmelt-first.0.pic.o ../../melt-branch/gcc/melt/generated//warmelt-first.0.c gcc-4.5 -g -fkeep-inline-functions -g -fkeep-inline-functions -DIN_GCC -DHAVE_CONFIG_H -I melt-private-build-include -I. -fPIC -c -o warmelt-first.0 +01.pic.o ../../melt-branch/gcc/melt/generated//warmelt-first.0+01.c echo '/*' generated file ./warmelt-first.0-stamp.c '*/' > warmelt-first.0-stamp.c-tmp date "+const char melt_compiled_timestamp[]=\"%c \";" >> warmelt-first.0-stamp.c-tmp echo "const char melt_md5[]=\"\\" >> warmelt-first.0-stamp.c-tmp for f in ../../melt-branch/gcc/melt/generated/warmelt-first.0.c ../../melt-branch/gcc/melt/generated/warmelt-first.0+01.c; do \ md5line=`md5sum $f` ; \ printf "%s\\\n" $md5line >> warmelt-first.0-stamp.c-tmp; \ done echo "\";" >> warmelt-first.0-stamp.c-tmp echo "const char melt_csource[]= \"../../melt-branch/gcc/melt/generated/warmelt-first.0.c ../../melt-branch/gcc/melt/generated/warmelt-first.0+01.c\";" >> warmelt-first.0-stamp.c-tmp mv warmelt-first.0-stamp.c-tmp warmelt-first.0-stamp.c gcc-4.5 -g -fkeep-inline-functions -g -fkeep-inline-functions -DIN_GCC -DHAVE_CONFIG_H -I melt-private-build-include -I. -fPIC -shared \ ./warmelt-first.0.pic.o ./warmelt-first.0 +01.pic.o ./warmelt-first.0-stamp.c -o warmelt-first.0.so rm -f ./warmelt-first.0-stamp.c As you can see, the inner make -f ../../melt-branch/gcc/melt-module.mk has no -gtoggle inside the GCCMELT_CFLAGS. I see no reason it won't work with gcc-4.4 as GCCMELT_CC The GCC MELT was svn checkout cleanly, the svn info is Tue May 25 17:06:44 MEST 2010 Path: melt-branch URL: svn://gcc.gnu.org/svn/gcc/branches/melt-branch Repository Root: svn://gcc.gnu.org/svn/gcc Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4 Revision: 159821 Node Kind: directory Last Changed Author: bstarynk Last Changed Rev: 159667 Last Changed Date: 2010-05-21 16:44:05 +0200 (Fri, 21 May 2010) So I tend to still believe that I did fix that bug, but I am not sure of that. And I am not able to reproduce that bug on the latest MELT branch rev 159821 Perhaps you might try to merge again the latest MELT branch into your private one; the changes are mostly in gcc/Makefile.in or some gcc/*.mk I believe. Tell us if that helps! Cheers.
Trouble with MDs: "const" RTL object stops recognition of RTL expressions by insn patterns
Dear All,
I am porting GCC to a 16 bit micro (with 16 bit bytes, thus
BITS_PER_UNIT=16, 16 bit ints become "QI"s etc).
The port compiles is nearly done and simple C programs, but now chokes
on a trivial line such as:
yyy(&array[4], &e, &p);
with this error:
xxx.c: In function ‘yyy’:
xxx.c:193: error: unrecognizable insn:
(insn 183 181 184 4 (set (reg/f:QI 37 [ D.1127 ])
(const:QI (plus:QI (symbol_ref:QI ("digest") [flags 0x2]
)
(const_int 8 [0x8] -1 (nil)
(nil))
sha1_16_struct2.c:193: internal compiler error: in extract_insn, at
recog.c:2020
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
I determined that the problem is triggered by the computation of array
address+const (4/8 in this case).
My MD contains:
(define_insn "addqi3"
[(set (match_operand:QI 0 "register_operand" "=r,r")
(plus:QI (match_operand:QI 1 "register_operand" "0,0")
(match_operand:QI 2 "nonmemory_operand" "r,K"))
)]
""
"@
ADD \\t%2 %0
ADDI \\t%h2 %0"
)
which correctly compiles ordinary arithmetic expressions: x = 5+y etc.
However, when a symbol is involved, the addqi3 isns pattern cannot
recognise the RTL: Symbol+Int.
Is maybe the surrounding (const:QI...) the reason why addqi3 does not
match?! Grepping the GCC source I found in rtl.h that CONST is defined as:
/* This is used to encapsulate an expression whose value is constant
(such as the sum of a SYMBOL_REF and a CONST_INT) so that it will be
recognized as a constant operand rather than by arithmetic instructions. */
DEF_RTL_EXPR(CONST, "const", "e", RTX_CONST_OBJ)
So, what is my port missing to make it compile such RTL expressions?
I feel that it must be something really trivial which I am overlooking..
Thanks for your help,
Sergio
toplevel out of sync
All, the toplevel configury of gcc/gdb/binutils is very much out of sync. If people agree, I would like to freeze commits to the toplevel configury until they are not diverging anymore. Also, I would like to make a new policy that from now on patches to the toplevel cannot be committed by anyone who doesn't have write access to both gcc and src. Is there any agreement on this? Unfortunately I don't have much time to devote to bringing the trees back in shape, and not even to chase down committers of patches placed only on one side. Can anybody help with this? In particular, if DJ could provide with the last date when the tree was synchronized that would help. Paolo
Re: toplevel out of sync
* Paolo Bonzini wrote on Tue, May 25, 2010 at 06:06:16PM CEST: > the toplevel configury of gcc/gdb/binutils is very much out of sync. > Unfortunately I don't have much time to devote to bringing the trees > back in shape, and not even to chase down committers of patches > placed only on one side. Can anybody help with this? I can take a look. > ... the last date when the tree was synchronized ... It looked fairly good 3 months ago[1]. Do you prefer tracking down committers and letting them finish their work, or should I just go ahead and sync sets of commits as I did last time? Thanks, Ralf [1] $ L="git log --until=3.months.ago --pretty=format:%H" $ diff <( cd gcc && git show $($L origin/trunk | head -n 1):configure.ac ) \ <( cd src && git show $($L origin/master | head -n 1):configure.ac )
Re: toplevel out of sync
On 05/25/2010 07:09 PM, Ralf Wildenhues wrote: * Paolo Bonzini wrote on Tue, May 25, 2010 at 06:06:16PM CEST: the toplevel configury of gcc/gdb/binutils is very much out of sync. Unfortunately I don't have much time to devote to bringing the trees back in shape, and not even to chase down committers of patches placed only on one side. Can anybody help with this? I can take a look. ... the last date when the tree was synchronized ... It looked fairly good 3 months ago[1]. Do you prefer tracking down committers and letting them finish their work, or should I just go ahead and sync sets of commits as I did last time? As you prefer. I'd rather see a list of commits before giving you green light though. :-) Paolo
Re: toplevel out of sync
* Paolo Bonzini wrote on Tue, May 25, 2010 at 07:10:33PM CEST: > On 05/25/2010 07:09 PM, Ralf Wildenhues wrote: > >>... the last date when the tree was synchronized ... > > > >It looked fairly good 3 months ago[1]. Toplevel and config/ went out of sync with commit 6c8aa2aa884d of the GCC infradead git mirror, aka. r157945, on April 2. Since then, there have been no commits on src that were not synced to GCC. > >Do you prefer tracking down committers and letting them finish their > >work, or should I just go ahead and sync sets of commits as I did last > >time? > > As you prefer. I'd rather see a list of commits before giving you > green light though. :-) commit id of infradead mirror, GCC SVN revision number: 17281d1ee17f204064cfcbcc82089aefa19e3779 159527 401f30d69e280e18a9581b819376d18786595d3b 159173 decab1d0d6db331f662d42679eb1a8d473f72920 159134 bcd70fb06d56d9316d49019f5c0a3109def08d39 158763 a9ed67d000f285282e61aa9b87cc8d992a8731df 158762 22c56f6f70e07d6d9991a294439613dbf8eb60e0 158550 8b6a3525690f368dc965cd1457dc128d1925c995 158459 7da77e3b5958bf72909a3d238b2be0aa0820cb41 158423 82cf45c792250d333911ae6d2719fea77b520f0d 158285 d1d17d418a5c66a792e9988a945ca25e89692632 157946 6c8aa2aa884de79314b9b16a374518f4fd6624aa 157945 There are no changes in intl, libiberty. The sourceware git mirror doesn't seem to carry libdecnumber. Which files in include/ were part of libiberty again? Thanks, Ralf
Re: toplevel out of sync
* Ralf Wildenhues wrote on Tue, May 25, 2010 at 07:33:53PM CEST: > * Paolo Bonzini wrote on Tue, May 25, 2010 at 07:10:33PM CEST: > > As you prefer. I'd rather see a list of commits before giving you > > green light though. :-) > > commit id of infradead mirror, GCC SVN revision number: One more missing in config/: f299d473920cb31abfc07842575b43bbf08383d6 155648
Re: stack slot reuse
On Fri, May 21, 2010 at 10:30 AM, Xinliang David Li wrote:
>
> On Fri, May 21, 2010 at 2:24 AM, Richard Guenther
> wrote:
> > On Thu, May 20, 2010 at 11:21 PM, Xinliang David Li
> > wrote:
> >> On Thu, May 20, 2010 at 2:18 PM, Steven Bosscher
> >> wrote:
> >>> On Thu, May 20, 2010 at 11:14 PM, Xinliang David Li
> >>> wrote:
> stack variable overlay and stack slot assignments is here too.
> >>>
> >>> Yes, and for these I would like to add a separate timevar. Agree?
> >>
> >> Yes. (By the way, we are rewriting this pass to eliminate the code
> >> motion/aliasing problem -- but that is a different topic).
> >
> > Btw, we want to address the same problem by representing the
> > points where (big) variables go out-of scope in the IL, also to
> > help DSE. The original idea was to simply drop in an aggregate
> > assignment from an undefined value at the end of the scope
> > during lowering, like
> >
> > var = {undefined};
> >
>
Is there something that prevents store sinking (or similar passes)
from moving this 'var = {undefined};' statement outside the scope? Or
should store sinking be taught to treat this as a barrier?
>
> This looks like a very interesting approach. Do you see any downside
> of this approach? What is the problem of handling (nullifying) the
> dummy statement in expansion pass?
>
> The approach we took is different --- we move this overlay/packing
> earlier (after ipa-inlining).
To elaborate further, we use the current stack-slot sharing heuristics
in cfgexpand.c to decide what variables can share stack slots,
synthesize union variables with those variables as fields and replace
references to those variables with field references. We have an
initial implementation and are evaluating the performance impact of
making the sharing decisions early.
Thanks,
Easwaran
>
> One of the other motivation for doing
> this is due to the limitation in current implementation that leaves
> out many overlaying opportunities (e.g. structs with union members can
> not share slots etc), but this is a probably independent issue.
>
>
> Thanks,
>
> David
>
> > which we'd expand to nothing. Of course shifting the problem to
> > the RTL optimizers, so better expand to a similar RTL construct.
> > But then are you addressing the similar problem on the RTL side?
> >
> > Richard.
> >
Re: toplevel out of sync
> Also, I would like to make a new policy that from now on patches to > the toplevel cannot be committed by anyone who doesn't have write > access to both gcc and src. Is there any agreement on this? Our current policy certainly doesn't work, either we come up with something that will, or abandon the whole idea and let chaos reign. > In particular, if DJ could provide with the last date when the tree > was synchronized that would help. I don't recall. It's stricly a manual process.
Re: toplevel out of sync
> There are no changes in intl, libiberty. The sourceware git mirror > doesn't seem to carry libdecnumber. Which files in include/ were > part of libiberty again? Libiberty is kept in sync because gcc is the master and src is the copy, so it can be mostly automated. The libiberty sync includes libiberty/, intl/, libdecnumber/, and those files in include/ that exist in both repositories (src has more files therein which are src-specific).
Re: unrecognizable insn ICE in latticemico32 (lm32-elf) when building Linux kernel
On 25/05/10 06:06, Ian Lance Taylor wrote: The official list of maintainers is stored in the gcc source code in the file MAINTAINERS. Having said that, there is no maintainer listed for lm32. I assume that it must be, as you suggest, Jon Beniston. Yeah, I spotted that in SVN about five minutes after I posted ;) Funny how you spot things in websvn that get missed when you're just 'ls'-ing the source tree... That ICE is telling you that an RTL insn was generated for some reason but there is no matching define_insn in the CPU MD file. In this case it is an SImode move using a SUBREG. The address is unusual: (subreg:SI (mem/s:DI (plus:SI (reg/v/f:SI 39 [ ctx ]) (const_int 64 [0x40])) [0 S8 A64]) 4) Why isn't that simply (mem/s:SI (plus:SI (reg/v/f:SI 39 [ ctx ]) (const_int 68 [0x40])) [0 S8 A64]) Let me see if I understand this right... It's using an SImode (machine-native size, 32 bit) subreg over a DImode (DWORD, 64bit) address of a 32-bit addition operation? That can't be right... What's interesting is that this happens on a variable initialisation statement... although maybe I shouldn't be assuming the SLoC-number part of the ICE error is accurate... That makes it look like something is creating a subreg without going through simplify_gen_subreg. It's also possible that the problem is simply that lm32_legitimate_address_p needs to handle a SUBREG memory address. The questions raised by that would be: 1) Where is the subreg being created? (or: "how can a subreg be created?" -- then grep the lm32 source for the answer(s) to that question) 2) (assuming [1] isn't the problem) How do you handle a SUBREG in *_legitimate_address_p? Thanks, Phil.
gcc-4.4-20100525 is now available
Snapshot gcc-4.4-20100525 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20100525/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch revision 159845 You'll find: gcc-4.4-20100525.tar.bz2 Complete GCC (includes all of below) gcc-core-4.4-20100525.tar.bz2 C front end and core compiler gcc-ada-4.4-20100525.tar.bz2 Ada front end and runtime gcc-fortran-4.4-20100525.tar.bz2 Fortran front end and runtime gcc-g++-4.4-20100525.tar.bz2 C++ front end and runtime gcc-java-4.4-20100525.tar.bz2 Java front end and runtime gcc-objc-4.4-20100525.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.4-20100525.tar.bz2The GCC testsuite Diffs from 4.4-20100518 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 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: unrecognizable insn ICE in latticemico32 (lm32-elf) when building Linux kernel
Philip Pemberton writes: >> The address is unusual: >> >> (subreg:SI (mem/s:DI (plus:SI (reg/v/f:SI 39 [ ctx ]) >> (const_int 64 [0x40])) [0 S8 A64]) 4) >> >> Why isn't that simply >> >> (mem/s:SI (plus:SI (reg/v/f:SI 39 [ ctx ]) >> (const_int 68 [0x40])) [0 S8 A64]) > > Let me see if I understand this right... > > It's using an SImode (machine-native size, 32 bit) subreg over a > DImode (DWORD, 64bit) address of a 32-bit addition operation? That > can't be right... This means that it is taking an SImode slice out of a DImode value. >> That makes it look like something is creating a subreg without going >> through simplify_gen_subreg. >> >> It's also possible that the problem is simply that >> lm32_legitimate_address_p needs to handle a SUBREG memory address. > > The questions raised by that would be: > 1) Where is the subreg being created? (or: "how can a subreg be > created?" -- then grep the lm32 source for the answer(s) to that > question) I don't know where the subreg is being created. There are several different ways to create one. > 2) (assuming [1] isn't the problem) How do you handle a SUBREG in > *_legitimate_address_p? In *_legitimate_address_p you can usually do something along the lines of if (GET_CODE (x) == SUBREG) x = SUBREG_REG (x); However, as I mentioned, this whole SUBREG is odd, so it's first necessary to find out whether it should have been created at all. Ian
GFDL/GPL issues
In a biweekly call with the other GCC Release Managers, I was asked today on the status of the SC/FSF discussions re. GFDL/GPL issues. In particular, the question of whether or not we can use "literate programming" techniques to extract documentation from code and take bits of what is currently in GCC manuals and put that into comments in code and so forth and so on. I have raised this issue directly with RMS, with a copy to the GCC SC. I will report any significant changes in status here. If I don't report anything, then it's probably because there's nothing to report. It's typical for these kinds of license issues to take a long time (months, or even years) to be resolved -- unless the FSF decides very quickly that it will not grant whatever request it is that we are making. Therefore, if I don't have an update "soon" (within a week or two), I'd suggest that we operate under the assumption that it will not be possible to combine GFDL manuals and GPL code in the near future. Thanks, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
RM Q&A Session on irc.oftc.net
In: http://gcc.gnu.org/ml/gcc/2010-05/msg00347.html I indicated that I, and the other GCC RMs as available, would participate in an interactive IRC discussion on May 27th at 9:00 AM Pacific. As nobody has volunteered to moderate the IRC session, we'll use the general-purpose GCC developer IRC channel irc://irc.oftc.net/#gcc. At the start of the session, I'll ask that routine GCC development traffic cease for an hour so that we can do the interactive discussion. This Wiki page: http://gcc.gnu.org/wiki/Release%20Manager%20Q%26A already contains quite a few good questions being asked by people who will apparently be unable to participate. We'll try to answer those as breaks in the conversation occur. Thanks, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: toplevel out of sync
On Tue, May 25, 2010 at 4:38 PM, DJ Delorie wrote: > >> Also, I would like to make a new policy that from now on patches to >> the toplevel cannot be committed by anyone who doesn't have write >> access to both gcc and src. Is there any agreement on this? > > Our current policy certainly doesn't work, either we come up with > something that will, or abandon the whole idea and let chaos reign. Ideas: Switch to svn and use svn:externals to link the two repos Make binutils be part of the gcc repository to begin with Lock the files on the binutils side and only allow a specific user to commit; Make that user a bot that's hooked onto the gcc commit
Re: toplevel out of sync
On 25/05/2010 17:06, Paolo Bonzini wrote: > Unfortunately I don't have much time to devote to bringing the trees > back in shape, and not even to chase down committers of patches placed > only on one side. Can anybody help with this? Augh. I forgot to copy over this one: > PR lto/42776 > * configure.ac (--enable-lto): Refactor handling so libelf tests > are only performed inside then-clause of ACX_ELF_TARGET_IFELSE, > and allow LTO to be explicitly enabled on non-ELF platforms that > are known to support it inside else-clause. > * configure: Regenerate. I'll do that right away. cheers, DaveK
Re: toplevel out of sync
On 25/05/2010 18:33, Ralf Wildenhues wrote: > bcd70fb06d56d9316d49019f5c0a3109def08d39 158763 > a9ed67d000f285282e61aa9b87cc8d992a8731df 158762 I'm responsible for those two, and I'm copying them across right now; sorry for forgetting. cheers, DaveK
Re: toplevel out of sync
On 26/05/2010 05:58, Dave Korn wrote: > On 25/05/2010 18:33, Ralf Wildenhues wrote: > >> bcd70fb06d56d9316d49019f5c0a3109def08d39 158763 >> a9ed67d000f285282e61aa9b87cc8d992a8731df 158762 > > I'm responsible for those two, and I'm copying them across right now; sorry > for forgetting. And while I'm at it, I'll take care of these two as well: > 17281d1ee17f204064cfcbcc82089aefa19e3779 159527 > 401f30d69e280e18a9581b819376d18786595d3b 159173 ... since they're one-liner additions to the section I'm synching. cheers, DaveK
[PATCH, committed] Re: toplevel out of sync
On 26/05/2010 06:09, Dave Korn wrote: > On 26/05/2010 05:58, Dave Korn wrote: >> On 25/05/2010 18:33, Ralf Wildenhues wrote: >> >>> bcd70fb06d56d9316d49019f5c0a3109def08d39 158763 >>> a9ed67d000f285282e61aa9b87cc8d992a8731df 158762 >> I'm responsible for those two, and I'm copying them across right now; sorry >> for forgetting. > > And while I'm at it, I'll take care of these two as well: > >> 17281d1ee17f204064cfcbcc82089aefa19e3779 159527 >> 401f30d69e280e18a9581b819376d18786595d3b 159173 > > ... since they're one-liner additions to the section I'm synching. I've synched across the above-mentioned GCC revisions to the top-level configure.ac script in /src, with the following ChangeLog: 2010-05-26 Dave Korn Merge from gcc: 2010-05-18 Steven Bosscher * configure.ac (--enable-lto): All *-apple-darwin* now support LTO. * configure: Regenerate. 2010-05-07 Steven Bosscher * configure.ac (--enable-lto): Add x86_64-apple-darwin* as a platform that supports LTO. * configure: Regenerate. 2010-04-27 Dave Korn PR lto/42776 * configure.ac (--enable-lto): Refactor handling so libelf tests are only performed inside then-clause of ACX_ELF_TARGET_IFELSE, and allow LTO to be explicitly enabled on non-ELF platforms that are known to support it inside else-clause. * configure: Regenerate. Committed after building and testing binutils on i686-pc-cygwin just to make sure nothing went wrong in the merge. cheers, DaveK Index: configure.ac === RCS file: /cvs/src/src/configure.ac,v retrieving revision 1.102 diff -p -u -r1.102 configure.ac --- configure.ac 27 Apr 2010 14:24:37 - 1.102 +++ configure.ac 26 May 2010 04:54:16 - @@ -1651,17 +1651,8 @@ AC_ARG_ENABLE(lto, enable_lto=$enableval, enable_lto=yes; default_enable_lto=yes) -ACX_ELF_TARGET_IFELSE([], -if test x"$default_enable_lto" = x"yes" ; then - enable_lto=no -else - if test x"$enable_lto" = x"yes"; then -AC_MSG_ERROR([LTO support requires an ELF target.]) - fi -fi -default_enable_lto=no) -if test x"$enable_lto" = x"yes" ; then +ACX_ELF_TARGET_IFELSE([if test x"$enable_lto" = x"yes" ; then # Make sure that libelf.h and gelf.h are available. AC_ARG_WITH(libelf, [ --with-libelf=PATH Specify prefix directory for the installed libelf package Equivalent to --with-libelf-include=PATH/include @@ -1777,7 +1768,25 @@ to specify its location.]) # Flags needed for libelf. AC_SUBST(libelflibs) AC_SUBST(libelfinc) -fi +fi],[if test x"$default_enable_lto" = x"yes" ; then +# On non-ELF platforms, LTO must be explicitly enabled. +enable_lto=no + else + # Apart from ELF platforms, only Windows supports LTO so far. It + # would also be nice to check the binutils support, but we don't + # have gcc_GAS_CHECK_FEATURE available here. For now, we'll just + # warn during gcc/ subconfigure; unless you're bootstrapping with + # -flto it won't be needed until after installation anyway. +case $target in + *-cygwin*|*-mingw*) ;; + *-apple-darwin*) ;; + *) if test x"$enable_lto" = x"yes"; then + AC_MSG_ERROR([LTO support is not enabled for this target.]) +fi + ;; +esac + fi + default_enable_lto=no]) # By default, C is the only stage 1 language.
Re: GFDL/GPL issues
On Tue, 2010-05-25 at 17:44 -0700, Mark Mitchell wrote:
> In a biweekly call with the other GCC Release Managers, I was asked
> today on the status of the SC/FSF discussions re. GFDL/GPL issues. In
> particular, the question of whether or not we can use "literate
> programming" techniques to extract documentation from code and take bits
> of what is currently in GCC manuals and put that into comments in code
> and so forth and so on.
[...]
>
> Therefore, if I don't have an update "soon" (within a week or two), I'd
> suggest that we operate under the assumption that it will not be
> possible to combine GFDL manuals and GPL code in the near future.
I am already doing that within the GCC MELT branch. Detailed
explanations have been given in my email of May 7th
http://gcc.gnu.org/ml/gcc/2010-05/msg00125.html
To be more precise
* all the MELT documentation have been written only by me (Basile).
* There is a chapter melt.texi devoted to MELT. It is hand written.
* The MELT infrastructure provides a syntax (:doc annotation) to add
documentation into definitions (of MELT functions, classes, primitives,
matchers, ...). The MELT infrastructure also provides a mode (a way of
running GCC MELT) to generate this documentation (from gcc/melt/*melt
source files) as a meltgendoc.texi in the build dir. So this generated
doc is another chapter of the documentation: gccint.texi has both
@include melt.texi & @include meltgendoc.texi
Actually, I believe that for MELT as a gcc-4.5 plugin, the two files
melt.texi (handwritten) & meltgendoc.texi (generated from *.melt source
files) constitute the documentation.
So what should I do?
a. ignore Mark Mitchell suggestion since GCC MELT is a branch, not the
official trunk.
b. scrap all the documentation & the documentation generator. This is
not good news - even if the documentation is incomplete, I did put a lot
of efforts inside... And MELT cannot be used without any documentation
(and this documentation, even imperfect & incomplete, is the best I have
today)
c. change the licenses of the melt*texi files [I certainly won't do that
without explicit approval] to something compatible. Perhaps the fact
that I am the only contributor to these files might help.
BTW, I intend to make a first release of MELT as a plugin in a few
weeks, not in a few years. This mostly means for me publishing the .tgz
file of all the MELT files as collected by the existing
contrib/make-melt-source-tar.sh script.
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: [PATCH, committed] Re: toplevel out of sync
* Dave Korn wrote on Wed, May 26, 2010 at 07:36:26AM CEST: > >>> bcd70fb06d56d9316d49019f5c0a3109def08d39 158763 > >>> a9ed67d000f285282e61aa9b87cc8d992a8731df 158762 > >> 17281d1ee17f204064cfcbcc82089aefa19e3779 159527 > >> 401f30d69e280e18a9581b819376d18786595d3b 159173 > I've synched across the above-mentioned GCC revisions to the top-level > configure.ac script in /src, with the following ChangeLog: Remainders, in reverse chronological order: 2010-05-05 Sebastian Pop * configure.ac: Allow all the versions greater than 0.10 of PPL. * configure: Regenerated. 2010-04-16 Rainer Orth * configure.ac: Check for elf_getshdrstrndx or elf_getshstrndx separately. * configure: Regenerate. 2010-04-13 Steve Ellcey * configure: Regenerate after change to elf.m4. config/ 2010-04-13 Steve Ellcey * elf.m4: Add hppa[12]*-*-hpux* to list of non-elf platforms. 2010-04-02 Sebastian Pop * configure.ac: Add brackets around AC_TRY_COMPILE alternative. * configure: Regenerated. 2010-04-02 Sebastian Pop * configure.ac: Print "buggy but acceptable" when CLooG revision is less than 9. * configure: Regenerated. config/ 2010-01-05 Rainer Orth * stdint.m4 (GCC_HEADER_STDINT): Don't typedef uint8_t etc. if corresponding macros already exist.
