public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Andrew MacLeod <amacleod@redhat.com>
To: Richard Biener <richard.guenther@gmail.com>
Cc: gcc-patches <gcc-patches@gcc.gnu.org>
Subject: Re: [patch] consolidate some includes into coretypes.h
Date: Tue, 02 Jun 2015 12:47:00 -0000	[thread overview]
Message-ID: <556DA2C2.4010704@redhat.com> (raw)
In-Reply-To: <CAFiYyc0Pu0x7WxjxeXPeZkxMeSm8n_Q_bM6My02DFHoA3ocf5g@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1810 bytes --]

On 06/02/2015 04:26 AM, Richard Biener wrote:
> On Mon, Jun 1, 2015 at 11:02 PM, Andrew MacLeod <amacleod@redhat.com> wrote:
>>
>> Bootstraps from scratch on x86_64-unknown-linux-gnu with no new test
>> regressions.  I also built it on all the config-list.mk targets with no
>> additional compilation errors.
>>
>> OK for trunk?
> Generally the idea is sound (amend coretypes.h), but I don't like the
> GCC_CONFIG_H guard, why does !GENERATOR_FILE not work?
Target files also use coretypes.h. In particular, libgcc includes it and 
does not have GENERATOR_FILE set.  Rather than checking for GCC_CONFIG_H 
we could check

#if !defined (GENERATOR_FILE) && !defined (USED_FOR_TARGET)

I think that should work OK.
> Furthermore I don't like the special-casing in rtl.h, instead have
> coretypes.h contain sth like
>
> #ifdef GENERATOR_FILE
> ... rtl.h special-case
> #else
> ... GCC_CONFIG_H stuff
> #endif
>
> Thanks,
> Richard.

This one is harder. I don't like the special case either, but you cant 
really figure it out in coretypes.h.  The problem comes from some 
generator files which compile rtl.c and and a couple of other files, and 
thus have GENERATOR_FILE set... These run after the initial set of 
generators so insn-modes.h and friends have been created, and these 
includes are now required.   the presence of rtl.h seems to be the the 
litmus test and if it occurs in the include chain after coretypes.h, 
then we'll need these files.

I suppose you could just include those files in rtl.h directly without 
the guard...  it is probably the cleanest solution. Otherwise we'd 
either have to add a new identifying macro to a dozen generator files, 
or include these headers there, or some other such thing.

The following tweak to the 2 files address both issues.  how does that seem?

  Andrew


[-- Attachment #2: num3.diff --]
[-- Type: text/x-patch, Size: 1306 bytes --]

Index: coretypes.h
===================================================================
--- coretypes.h	(revision 223875)
+++ coretypes.h	(working copy)
@@ -299,4 +299,14 @@
 typedef unsigned char uchar;
 #endif
 
+/* Most host source files will require the following headers.  */
+#if !defined (GENERATOR_FILE) && !defined (USED_FOR_TARGET)
+#include "machmode.h"
+#include "signop.h"
+#include "wide-int.h" 
+#include "double-int.h"
+#include "real.h"
+#include "fixed-value.h"
+#endif
+
 #endif /* coretypes.h */
Index: rtl.h
===================================================================
--- rtl.h	(revision 223875)
+++ rtl.h	(working copy)
@@ -20,15 +20,21 @@
 #ifndef GCC_RTL_H
 #define GCC_RTL_H
 
+/* coretypes.h normally includes these header files, but does not for generator
+   files.  This file is included by some late running generator files which 
+   also requires them, so always include them here.  */
+#include "machmode.h"     
+#include "signop.h"
+#include "wide-int.h"
+#include "double-int.h"
+#include "real.h"
+#include "fixed-value.h"
+
 #include "statistics.h"
-#include "machmode.h"
 #include "input.h"
-#include "real.h"
 #include "vec.h"
-#include "fixed-value.h"
 #include "alias.h"
 #include "hashtab.h"
-#include "wide-int.h"
 #include "flags.h"
 #include "is-a.h"
 

  reply	other threads:[~2015-06-02 12:34 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-01 21:09 Andrew MacLeod
2015-06-02  8:28 ` Richard Biener
2015-06-02 12:47   ` Andrew MacLeod [this message]
2015-06-02 13:49     ` Richard Biener
2015-06-02 14:19       ` Andrew MacLeod
2015-06-03 11:53         ` Richard Biener
2015-06-03 13:40           ` Andrew MacLeod
2015-06-04 12:29             ` Andrew MacLeod

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=556DA2C2.4010704@redhat.com \
    --to=amacleod@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=richard.guenther@gmail.com \
    /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).