On Thu, May 27, 2010 at 10:14 AM, Paolo Bonzini wrote:
> On 05/27/2010 10:10 AM, Steven Bosscher wrote:
>>
>> -/* FIXME: Still need to include rtl.h here (via expr.h) in a front-end
>> file.
>> - Pretend this is a back-end file. */
>> -#define IN_GCC_BACKEND
>> #include "expr.h" /* For vector_
On 05/27/2010 10:10 AM, Steven Bosscher wrote:
-/* FIXME: Still need to include rtl.h here (via expr.h) in a front-end file.
- Pretend this is a back-end file. */
-#define IN_GCC_BACKEND
#include "expr.h" /* For vector_mode_valid_p */
Is this really the only reason? We don't have any othe
gcc/ChangeLog:
* Makefile.in (ALL_CFLAGS): Add file-specific CFLAGS.
(ALL_HOST_FRONTEND_OBJS): New, for all front-end specific objects.
(ALL_HOST_BACKEND_OBJS): New, for all backend and target objects.
(ALL_HOST_OBJS): Now a union of the above two.
:
On Thu, May 27, 2010 at 9:49 AM, Paolo Bonzini wrote:
> On 05/27/2010 08:25 AM, Steven Bosscher wrote:
>>
>> On Thu, May 27, 2010 at 7:15 AM, Paolo Bonzini wrote:
>> Well, gives me at least one clue so far: the implicit rule .c.o is
>> over-ruled by t-i386, which explains why the extra CFLAGS-$fi
On 05/27/2010 08:25 AM, Steven Bosscher wrote:
On Thu, May 27, 2010 at 7:15 AM, Paolo Bonzini wrote:
Well, gives me at least one clue so far: the implicit rule .c.o is
over-ruled by t-i386, which explains why the extra CFLAGS-$file are
not passed to config/i386/i386-c.c. I'm now restarting the
On Thu, May 27, 2010 at 8:25 AM, Steven Bosscher wrote:
> On Thu, May 27, 2010 at 7:15 AM, Paolo Bonzini wrote:
>> On 05/27/2010 06:58 AM, Steven Bosscher wrote:
>>>
>>> Well, it looks like I do need something like @F because I now only get
>>> the define on files in gcc/. Any file with a / in th
On Thu, May 27, 2010 at 7:15 AM, Paolo Bonzini wrote:
> On 05/27/2010 06:58 AM, Steven Bosscher wrote:
>>
>> Well, it looks like I do need something like @F because I now only get
>> the define on files in gcc/. Any file with a / in the full name $@
>> does not get a file specific CFLAGS.
>
> Inte
On 05/27/2010 06:58 AM, Steven Bosscher wrote:
Well, it looks like I do need something like @F because I now only get
the define on files in gcc/. Any file with a / in the full name $@
does not get a file specific CFLAGS.
Interesting, this simpler testcase worked:
test-a/b = $(warning ok)
all
On Tue, May 25, 2010 at 5:06 PM, Paolo Bonzini wrote:
> 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
Steven Bosscher writes:
> OK, the patch at the end of this mail appears to do what I've been
> trying to achieve.
> Does it look correct, and acceptable for the trunk after proper testing?
I'll approve the patch to system.h if testing succeeds. The patch to
Makefile.in looks fine to me but I'd
On Tue, May 25, 2010 at 5:06 PM, Paolo Bonzini wrote:
> 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
Steven Bosscher writes:
> +ALL_HOST_FRONTEND_OBJS = $(C_OBJS)
> + $(foreach v,$(CONFIG_LANGUAGES),$($(v)_OBJS))
You still need the backslash.
Andreas.
--
Andreas Schwab, sch...@redhat.com
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E
"And now for something complete
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 CFLAG
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
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:
> [...]
>> Th
* 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
>
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
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-specif
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
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 ca
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 variab
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 the
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 s
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
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
25 matches
Mail list logo
