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 p
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
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
$(GCCBU
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]
>
>
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, b
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-
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 yo
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
> 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
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 co
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
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
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-
13 matches
Mail list logo
