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-
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
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
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
> 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
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
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
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-
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
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:
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
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
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
13 matches
Mail list logo
