public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Andrew MacLeod <amacleod@redhat.com>
To: nick <xerofoify@gmail.com>, "Martin Liška" <mliska@suse.cz>
Cc: GCC Development <gcc@gcc.gnu.org>
Subject: Re: FIXME in gcc/gimplify.c
Date: Tue, 02 Apr 2019 13:33:00 -0000	[thread overview]
Message-ID: <e744c033-a3f0-1b58-73df-bb01f27bfad6@redhat.com> (raw)
In-Reply-To: <04d3e57d-4ffc-1081-6f03-5272e5a4afcf@gmail.com>

On 4/1/19 5:17 PM, nick wrote:
>
> On 2019-04-01 1:54 p.m., Andrew MacLeod wrote:
>>
>> #include "tree-flow.h"
>> #include "cgraph.h"
>> #include "timevar.h"
>> #include "hashtab.h"
>> #include "flags.h"
>> #include "function.h"
>> #include "ggc.h"
>> #include "diagnostic-core.h"
>> #include "target.h"
>> #include "pointer-set.h"
>> #include "splay-tree.h"
>> #include "vec.h"
>> #include "gimple.h"
>>
>> #include "langhooks-def.h"      /* FIXME: for lhd_set_decl_assembler_name */
>> #include "tree-pass.h"          /* FIXME: only for PROP_gimple_any */
>>
>>
>> so that comment predates anything I did to it.   I specifically left any comments that existed as I refactored the core bits.
>>
>> Andrew
>>
> Andrew,
>
> I assumed so but it was the last commit and have your names. I will leave this thread open for discussion if anyone knows what
> the outstanding issues with header refactoring as required for fixing those comments. If someone comments and is able to give
> me a heads up about what needs refactoring I will be glad to do it in a patch or probably patch series.
>
> Nick
Once upon a  time someone went thru the compiler and added comments to a 
few of thesecomments to  #include's when there were only one or two 
dependencies.

I'm not sure what the original intention was, or why it was tagged as 
"FIXME".    The problem with this approach is it can rapidly get out of 
date.. as can be seen by the other undefined messages that caused the 
compilation issue when the #Include is removed.  There is actually half 
a dozen things required from this include file.

We almost removed all those comments when the re-factoring was being 
performed, but it was automated and there were other comments that were 
relevant, so we elected to just preserve all comments.

I don't see any particular reason or need to fix these includes. I think 
the comments are out of date and unnecessary, but won't lose any sleep 
over them.

tree-pass.h is required to compile this file. It is not included by any 
other include file, so there is no ordering issue I can see, nor any 
need to remove the #include.

Andrew

      reply	other threads:[~2019-04-02 13:33 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-29 22:29 nick
2019-04-01  8:21 ` Martin Liška
2019-04-01 16:50   ` nick
2019-04-01 17:54     ` Andrew MacLeod
2019-04-01 21:17       ` nick
2019-04-02 13:33         ` Andrew MacLeod [this message]

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=e744c033-a3f0-1b58-73df-bb01f27bfad6@redhat.com \
    --to=amacleod@redhat.com \
    --cc=gcc@gcc.gnu.org \
    --cc=mliska@suse.cz \
    --cc=xerofoify@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).