public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jerry DeLisle <jvdelisle@frontier.com>
To: FX <fxcoudert@gmail.com>
Cc: gcc-patches@gcc.gnu.org, gfortran List <fortran@gcc.gnu.org>,
	 Michael Meissner <meissner@linux.vnet.ibm.com>,
	Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>,
	chertykov@gmail.com,  aesok@post.ru, eric.weddington@atmel.com
Subject: Re: [patch] Separate {OS,CPU}_CPP_BUILTINS macros into C-family and language-independent macros
Date: Sat, 06 Nov 2010 00:06:00 -0000	[thread overview]
Message-ID: <4CD49B1A.20603@frontier.com> (raw)
In-Reply-To: <1D974441-C894-4F24-A0D1-7B693044B2BF@gmail.com>

On 11/03/2010 02:26 PM, FX wrote:
> See below for the description of the patch; this take n+1 incorporates suggestions by Michael Meissner and Rainer Orth, with the following exceptions:
>
>    -- As avr.c includes new headers (cpplib.h and cppbuiltin.h), I wanted to update its dependencies in the target configuration file (t-avr), but to my surprise, this file doesn't contain any mention of avr.o. In fact, I failed to find any by grepping the whole tree, so I'm a little unsure how this can work (and apparently it does). Could the maintainers help me here?
>
>    -- Michael is worried about splitting all this stuff:
>
>>> Unless I don't see what you're talking about, this is not possible: the Fortran front-end is not linked with the *-c.c files, only with *.c, so the language-independent functions need to be moved there.
>>
>> Yes, but if fortran is going to use the preprocessor, maybe they should be
>> linked in.  I'm just worried about the possibility of a macro getting lost in
>> the movement.
>
>
> Well, we do need some separation between CPP built-in macros that are only relevant for C-family languages (for example, because they depend on flag variables that are only declared for C) and the others. Now that the job is done, was discussed beforehand, and it fixes the regression experienced by Fortran, I'd be glad to just have it work.
>
>
> Tested as indicated below, OK to commit? (needs a global reviewer; pretty pretty please, don't let it bitrot again)  I'd like to highlight that it's nothing conceptualy major, and it'll be easy to fix any eventual fallout.
>
> FX

I have reviewed this patch and I have to agree with FX.  There is nothing here 
that makes these workings more obfuscated then they already are and I think the 
splitting actually makes it easier to understand, ie less obfuscated. 
Considering the lessor evil and that it passes testing, and I would like to 
encourage this patch be approved.

I would like to see specific comments as to why not if not, so we can close on this.

Regards,

Jerry

  parent reply	other threads:[~2010-11-06  0:03 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-03 21:29 FX
2010-11-03 22:34 ` Weddington, Eric
2010-11-03 22:35   ` FX
2010-11-04 17:05 ` Rainer Orth
2010-11-06  0:06 ` Jerry DeLisle [this message]
  -- strict thread matches above, loose matches on Subject: below --
2010-10-07 10:49 FX
2010-10-07 11:14 ` Rainer Orth
2010-10-07 12:31   ` FX
2010-10-07 12:46     ` FX
2010-10-08  8:56 ` Tobias Burnus
2010-10-08 20:29 ` Rainer Orth
2010-10-16 19:44 ` Tobias Burnus
2010-10-20 22:34   ` FX

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4CD49B1A.20603@frontier.com \
    --to=jvdelisle@frontier.com \
    --cc=aesok@post.ru \
    --cc=chertykov@gmail.com \
    --cc=eric.weddington@atmel.com \
    --cc=fortran@gcc.gnu.org \
    --cc=fxcoudert@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=meissner@linux.vnet.ibm.com \
    --cc=ro@CeBiTec.Uni-Bielefeld.DE \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).