Re: gtyp-input.list should contain absolute paths.
Basile STARYNKEVITCH writes: > In plugin mode (for the few plugins using PLUGIN_REGISTER_GGC_ROOTS), > gengtype needs a file list. So a plugin build (in its own directory) would > want to run (in Makefile syntax) > $(GCCBUILD)/gcc/gengtype -p $(GCCSOURCE)/gcc > $(GCCBUILD)/gcc/gtype-input.list plugin.c > > However, this won't work, because the gtype-input.list contains (even when > GCC was configured with absolute paths) a few relative file paths (notably > auto-host.h). Perhaps gengtype should be modified to always treat the files in gtyp-input.list relative to location of that file. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: -print-* command-line switches misbehave or are misdocumented
Eli Zaretskii writes:
> Granted, I know very well why it doesn't work with cpp and gcc. But I
> was talking about _user_documentation_, and from the user's point of
> view (as opposed to GCC programmer/hacker POV), the distinction is not
> quite obvious. Either the docs should be fixed to make that clear, or
> (better) the code should be modified to support all related programs.
Perhaps the description of the options should be moved to the internals
documentation (since they are somewhat gcc-internal options), and the
user documentation should just refer to it ("for the curious").
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Re: gtyp-input.list should contain absolute paths.
Andreas Schwab wrote:
Basile STARYNKEVITCH writes:
In plugin mode (for the few plugins using PLUGIN_REGISTER_GGC_ROOTS),
gengtype needs a file list. So a plugin build (in its own directory) would
want to run (in Makefile syntax)
$(GCCBUILD)/gcc/gengtype -p $(GCCSOURCE)/gcc
$(GCCBUILD)/gcc/gtype-input.list plugin.c
However, this won't work, because the gtype-input.list contains (even when
GCC was configured with absolute paths) a few relative file paths (notably
auto-host.h).
Perhaps gengtype should be modified to always treat the files in
gtyp-input.list relative to location of that file.
If we did that, we could not run gengtype in plugin mode as easily as
[Makefile syntax inside our plugin tree]
$(GCCBUILD)/gcc/build/gengtype -p $(GCCSOURCE)/gcc
$(GCCBUILD)/gcc/gtype-input.list plugin.c
because then the plugin.c would be expected to be inside the
$(GCCBUILD)/gcc or $(GCCBUILD)/gcc/build/ directory, which it is not.
Also, modifying gengtype that way (which is non trivial: I don't know
how to *portably* and *easily* determine dynamically the location of an
executable: many non-linux systams don't have /proc/self/exe) is much
harder than just generating an extra real-gtype-input.list in
$(GCCBUILD)/gcc/
Regards
--
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: gtyp-input.list should contain absolute paths.
Basile STARYNKEVITCH writes: > Andreas Schwab wrote: >> Perhaps gengtype should be modified to always treat the files in >> gtyp-input.list relative to location of that file. > If we did that, we could not run gengtype in plugin mode as easily as > [Makefile syntax inside our plugin tree] > > $(GCCBUILD)/gcc/build/gengtype -p $(GCCSOURCE)/gcc > $(GCCBUILD)/gcc/gtype-input.list plugin.c > > because then the plugin.c would be expected to be inside the > $(GCCBUILD)/gcc or $(GCCBUILD)/gcc/build/ directory, which it is not. It wouldn't. Any additional file specified on the command line would still be found relative to the current directory. > Also, modifying gengtype that way (which is non trivial: I don't know how > to *portably* and *easily* determine dynamically the location of an > executable: many non-linux systams don't have /proc/self/exe) Why would you need the location of the executable? Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: gtyp-input.list should contain absolute paths.
Andreas Schwab wrote:
Basile STARYNKEVITCH writes:
Andreas Schwab wrote:
Perhaps gengtype should be modified to always treat the files in
gtyp-input.list relative to location of that file.
I probably misunderstood your sentence. I parsed "that file" as
referring to gengtype, but you perhaps meant to refer to gtype-input.list
I still don't understand what patch to gengtype are you precisely
thinking of.
If we did that, we could not run gengtype in plugin mode as easily as
[Makefile syntax inside our plugin tree]
$(GCCBUILD)/gcc/build/gengtype -p $(GCCSOURCE)/gcc
$(GCCBUILD)/gcc/gtype-input.list plugin.c
because then the plugin.c would be expected to be inside the
$(GCCBUILD)/gcc or $(GCCBUILD)/gcc/build/ directory, which it is not.
It wouldn't. Any additional file specified on the command line would
still be found relative to the current directory.
[my misunderstanding about "that file"]
Regards.
PS BTW we also need gengtype to output gtype-desc.h in plugin mode.
--
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: gtyp-input.list should contain absolute paths.
On Sun, Jul 5, 2009 at 8:26 AM, Basile STARYNKEVITCH wrote: > Ian Lance Taylor wrote: >> >> Basile STARYNKEVITCH writes: >> >> >>> >>> @: $(call write_entries_to_file,$(realpath $(GTFILES)),tmp-gi.list) >>> $(SHELL) $(srcdir)/../move-if-change tmp-gi.list gtyp-input.list >>> $(STAMP) s-gtyp-input >>> >> >> In general, one should try to avoid changing a user specified relative >> path to an absolute path. In this case, the user specification comes >> from how they invoked configure. Absolute paths have different >> behaviour in automount environments. It's OK to temporarily change from >> a relative to an absolute path, but changing to an absolute path and >> writing that to a file should be avoided when possible. >> >> It's not clear to me why plugins need to deal with gtyp-input.list. > > In plugin mode (for the few plugins using PLUGIN_REGISTER_GGC_ROOTS), > gengtype needs a file list. So a plugin build (in its own directory) would > want to run (in Makefile syntax) > $(GCCBUILD)/gcc/gengtype -p $(GCCSOURCE)/gcc > $(GCCBUILD)/gcc/gtype-input.list plugin.c > > However, this won't work, because the gtype-input.list contains (even when > GCC was configured with absolute paths) a few relative file paths (notably > auto-host.h). >> >> I >> thought we were trying to make it possible to build plugins with a set >> of installed header files. If plugins need to read gtyp-plugin.list, >> they need access to the complete source code. > > Yes, but a Makefile for a plugin cannot even use the > $(GCCBUILD)/gcc/gtype-input.list it should transform it to transform > relative paths to absolute ones, and that is painful. >> >> In that case, can't they >> just apply the same transformations that gengtype itself applies? >> > > I don't understand what transformations are you referring to. > > However, there might be another solution: have the gcc/Makefile.in generate > both the current gtype-input.list and another gtype-input-absolute.list > which contains only absolute paths, and document that plugins could use > that gtype-input-absolute.list (perhaps adding a caveat about automounters). > > What do you think?? How do you think distributors should package a gcc-devel package containing all necessary files for plugin development? I am really curious, so maybe you can take one of the existing packagings for GCC trunk and modify it accordingly? (Well, I know of one existing obviously - you can get it at http://download.opensuse.org/repositories/home://rguenther/openSUSE_11.1/src/gcc45-4.5.0_20090703-1.1.src.rpm Thanks, Richard.
Re: gtyp-input.list should contain absolute paths.
Basile STARYNKEVITCH writes: > Andreas Schwab wrote: >> Basile STARYNKEVITCH writes: >> >> >>> Andreas Schwab wrote: >>> Perhaps gengtype should be modified to always treat the files in gtyp-input.list relative to location of that file. > I probably misunderstood your sentence. I parsed "that file" as referring > to gengtype, but you perhaps meant to refer to gtype-input.list > > I still don't understand what patch to gengtype are you precisely thinking > of. Just prepend $(GCCBUILD)/gcc/ (the location of gtyp-input.list) to all non-absolute file names from $(GCCBUILD)/gcc/gtyp-input.list. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: -print-* command-line switches misbehave or are misdocumented
Eli Zaretskii wrote: >> Date: Sun, 05 Jul 2009 00:33:44 +0100 >> From: Dave Korn >> CC: Eli Zaretskii , gcc@gcc.gnu.org >> Well, the simple rule is "It can tell you where any program that gcc might >> invoke lives", isn't it? That would explain why it can locate cc1, ld and >> as, >> but not gcc or ls, and why it used to be able to locate cpp when it used to >> invoke cpp, but not since. > > Granted, I know very well why it doesn't work with cpp and gcc. But I > was talking about _user_documentation_, and from the user's point of > view (as opposed to GCC programmer/hacker POV), the distinction is not > quite obvious. Either the docs should be fixed to make that clear, or > (better) the code should be modified to support all related programs. Yes. I was suggesting a new wording there. I just didn't do it in the form of a patch because I'm up to my eyeballs in more serious bugs/patches ATM... cheers, DaveK
Re: -print-* command-line switches misbehave or are misdocumented
> X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,
> FORGED_RCVD_HELO autolearn=ham version=3.1.0
> From: Andreas Schwab
> Cc: Dave Korn , i...@google.com,
> gcc@gcc.gnu.org
> Date: Sun, 05 Jul 2009 10:30:35 +0200
>
> Eli Zaretskii writes:
>
> > Granted, I know very well why it doesn't work with cpp and gcc. But I
> > was talking about _user_documentation_, and from the user's point of
> > view (as opposed to GCC programmer/hacker POV), the distinction is not
> > quite obvious. Either the docs should be fixed to make that clear, or
> > (better) the code should be modified to support all related programs.
>
> Perhaps the description of the options should be moved to the internals
> documentation (since they are somewhat gcc-internal options), and the
> user documentation should just refer to it ("for the curious").
That'd be fine with me, but even internals should be documented
better, IMO.
CONSTANT_POOL_BEFORE_FUNCTION has no effect in tm.h?
Hello, all. I'm attempting to port GCC 4.4.0 to a new m68k target. The target begins execution in the first byte of the first text section. Adding '#define CONSTANT_POOL_BEFORE_FUNCTION 0' in my target's tm.h seems like the simplest way to avoid execution of read-only data; however, defining the constant has no effect on compilation. (Note, custom or missing startup code is common, so I can't work around it there.) The only references to CONSTANT_POOL_BEFORE_FUNCTION are in varasm.c, and the only target current using the definition is pdp11--not exactly current. Is CONSTANT_POOL_BEFORE_FUNCTION still being used, or have I hit upon a section of dead code? Is there a simple way to relocate read-only data to the end of a function without writing a target-specific reorg routine? Jumping over the data in a prologue might be an easy, quick and dirty solution, but the target is a memory-constrained system, and that seems wasteful. Thanks, Trev
Graphite Merge Expected in Mid/Late July
David Edelsohn has informed the release managers that the Graphite branch is nearly ready for merge to mainline. Graphite will provide a bunch of new loop optimization capabilities, and is one of the important infrastructure developments that will help to improve the performance of code generated by GCC. The Graphite developers feel that they will be ready to merge in mid-to-late July. The RMs have approved this plan. As the Graphite developers firm up their plans, they will let us know, and we'll coordinate the exact mechanics for the merge, including any necessary "quiet period" on the trunk to accommodate that. Of course, all the patches will go through technical review/approval as part of the merge, and the remaining questions about exactly what versions of CLooG/PPL should be used will be worked out as well. I encourage the Graphite developers to start discussing those issues on the mailing list as soon as possible so that we have everything ready when the time comes. Thanks, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
gcc-4.3-20090705 is now available
Snapshot gcc-4.3-20090705 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20090705/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch revision 149265 You'll find: gcc-4.3-20090705.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20090705.tar.bz2 C front end and core compiler gcc-ada-4.3-20090705.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20090705.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20090705.tar.bz2 C++ front end and runtime gcc-java-4.3-20090705.tar.bz2 Java front end and runtime gcc-objc-4.3-20090705.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20090705.tar.bz2The GCC testsuite Diffs from 4.3-20090628 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 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: CONSTANT_POOL_BEFORE_FUNCTION has no effect in tm.h?
Trevor Scroggins writes: > Hello, all. I'm attempting to port GCC 4.4.0 to a new m68k target. The > target begins execution in the first byte of the first text section. > Adding '#define CONSTANT_POOL_BEFORE_FUNCTION 0' in my target's tm.h > seems like the simplest way to avoid execution of read-only data; > however, defining the constant has no effect on compilation. (Note, > custom or missing startup code is common, so I can't work around it > there.) > > The only references to CONSTANT_POOL_BEFORE_FUNCTION are in varasm.c, > and the only target current using the definition is pdp11--not exactly > current. Is CONSTANT_POOL_BEFORE_FUNCTION still being used, or have I > hit upon a section of dead code? Is there a simple way to relocate > read-only data to the end of a function without writing a > target-specific reorg routine? Jumping over the data in a prologue > might be an easy, quick and dirty solution, but the target is a > memory-constrained system, and that seems wasteful. Setting CONSTANT_POOL_BEFORE_FUNCTION to 0 ought to work to emit the constant pool after the function. However, to be clear, it only affects the constant pool which holds constants which are not LEGITIMATE_CONSTANT_P. This is normally things like 32-bit constants which RISC architectures can not handle in a single instruction. The m68k is a flexible architecture and can handle 32-bit constants just fine without using a constant pool. You didn't really describe what you are seeing; what makes you think that the constant pool is the problem? Ian
