[Bug other/46489] New: tree optimizer and frontend files use target macros

[Bug other/46489] New: tree optimizer and frontend files use target macros

[amylaar at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46489

           Summary: tree optimizer and frontend files use target macros
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: other
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: amylaar@gcc.gnu.org
            Blocks: 44566


As mentioned in comment #2 of PR44566, there are many target macros used
outside
of the RTL passes.  In order to build a multi-target core compiler, we want
to convert all macro uses in non-rtl centric source files to hooks.

See also the discussion starting with the message
http://gcc.gnu.org/ml/gcc/2010-11/msg00311.html
and the previous postings to which Joseph S. Myers refers to in his replies.

[Bug other/46489] tree optimizer and frontend files use target macros

[amylaar at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46489

--- Comment #1 from Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> 2010-11-16 04:59:35 UTC ---
Created attachment 22418
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22418
This is a list of the files that use tm.h, broken up into different categories.

[Bug other/46489] tree optimizer and frontend files use target macros

[amylaar at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46489

--- Comment #2 from Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> 2010-12-18 20:56:15 UTC ---
trunk is currently closed for macro->hook conversions:
http://gcc.gnu.org/ml/gcc-patches/2010-12/msg01291.html

I have now created a branch to work on this PR:
svn://gcc.gnu.org/svn/gcc/branches/pr46489-20101217-branch

[Bug other/46489] tree optimizer and frontend files use target macros

[amylaar at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46489

--- Comment #3 from Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> 2010-12-20 13:59:41 UTC ---
When using gcc, using -dD, I can auto-generate a headerfile tm-poison.h which
poisons all macros that including tm.h defines, which are not defined
by frontend-premissible headers like coretypes.h / tree.h .
The fallback would  be to have tm-poison.h be empty.
This file can be included instead of tm.h in files that are hoped / believed
to been freed of target macros uses .
This can safe a lot of manual checking.

[Bug other/46489] tree optimizer and frontend files use target macros

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46489

--- Comment #4 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2010-12-20 15:43:37 UTC ---
On Mon, 20 Dec 2010, amylaar at gcc dot gnu.org wrote:

> When using gcc, using -dD, I can auto-generate a headerfile tm-poison.h which
> poisons all macros that including tm.h defines, which are not defined
> by frontend-premissible headers like coretypes.h / tree.h .
> The fallback would  be to have tm-poison.h be empty.
> This file can be included instead of tm.h in files that are hoped / believed
> to been freed of target macros uses .
> This can safe a lot of manual checking.

This sounds like a nice approach for making sure it is safe to remove a 
tm.h include from a particular source file - if combined with generating a 
list of every target (every triplet with significant differences in how 
config.gcc / libgcc/config.host configure it, whether in the set of 
headers or the set of tm_defines) so you can run tests automatically for 
all targets - it may avoid the need to check for every macro with one of 
the properties I identified as meaning a target macro, that is used 
anywhere in that source file or any header it includes.  I'd be more 
doubtful about actually checking in a #include of tm-poison.h on trunk 
(the code to generate it, however, might be useful to check in).

Your approach also catches target macros such as TARGET_64BIT that are 
meant to be purely internal to a port but may nevertheless be used, 
incorrectly, in target-independent code, by treating such macros 
identically to those that are expected to be used in target-independent 
code but only in those source files allowed to include tm.h.  (Which 
anything based on looking at documented macros in tm.texi.in, for example, 
would not catch.)

[Bug other/46489] tree optimizer and frontend files use target macros

[amylaar at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46489

--- Comment #5 from Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> 2010-12-20 17:04:39 UTC ---
(In reply to comment #4)

> This sounds like a nice approach for making sure it is safe to remove a 
> tm.h include from a particular source file - if combined with generating a 
> list of every target (every triplet with significant differences in how 
> config.gcc / libgcc/config.host configure it, whether in the set of 
> headers or the set of tm_defines) so you can run tests automatically for 
> all targets -

I fear our configure system is turing complete, and thus such a list is
not computable.
But by testing at least one configuration per target architecture, we
already get a useful test coverage.
I can also make a script to search for every macro that is documented with
@defmac, so the remaining uncertainty would be for undocumented macros
that only appear in specific configuration variants.
I think a slight risk to break something where undocumented macros are
involved is acceptable in phase 1/2, as long as the breakage is obvious
during the gcc build - without the target macro poisoning, we could have
obscure changes in behaviour that could be very hard to debug.

> it may avoid the need to check for every macro with one of 
> the properties I identified as meaning a target macro, that is used 
> anywhere in that source file or any header it includes.  I'd be more 
> doubtful about actually checking in a #include of tm-poison.h on trunk 
> (the code to generate it, however, might be useful to check in).

Yes, the idea is to auto-generate the file.

[Bug other/46489] tree optimizer and frontend files use target macros

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46489

--- Comment #6 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2010-12-20 17:42:46 UTC ---
On Mon, 20 Dec 2010, amylaar at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46489
> 
> --- Comment #5 from Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> 2010-12-20 17:04:39 UTC ---
> (In reply to comment #4)
> 
> > This sounds like a nice approach for making sure it is safe to remove a 
> > tm.h include from a particular source file - if combined with generating a 
> > list of every target (every triplet with significant differences in how 
> > config.gcc / libgcc/config.host configure it, whether in the set of 
> > headers or the set of tm_defines) so you can run tests automatically for 
> > all targets -
> 
> I fear our configure system is turing complete, and thus such a list is
> not computable.

One configuration for each case in config.gcc, at least, so that you cover 
every header that might go in tm_file (and every object in c_target_objs 
etc.).  The effects of different macro values (such as the computation of 
FBSD_MAJOR from the target triplet for *-*-freebsd*) are less important.

> But by testing at least one configuration per target architecture, we
> already get a useful test coverage.
> I can also make a script to search for every macro that is documented with
> @defmac, so the remaining uncertainty would be for undocumented macros
> that only appear in specific configuration variants.

You could also check for every #define (note that some may have whitespace 
after the #) in config/*.h config/*/*.h.

[Bug other/46489] tree optimizer and frontend files use target macros

[jsm28 at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46489

--- Comment #7 from Joseph S. Myers <jsm28 at gcc dot gnu.org> 2011-04-05 15:43:46 UTC ---
FWIW, the following files include tm.h and appear not to have any direct uses
of target macros, or uses of the most common headers (such as rtl.h or
cp-tree.h) that depend on tm.h.  They require more careful checks of what
headers they are using for any hidden tm.h dependencies, but may be good
candidates for the removal of tm.h includes.

gcc/ada/gcc-interface/cuintp.c
gcc/attribs.c
gcc/c-aux-info.c
gcc/c-convert.c
gcc/c-errors.c
gcc/c-family/c-ada-spec.c
gcc/c-family/c-dump.c
gcc/c-family/c-gimplify.c
gcc/c-family/c-pretty-print.c
gcc/c-family/c-semantics.c
gcc/c-lang.c
gcc/c-parser.c
gcc/cgraphbuild.c
gcc/cppspec.c
gcc/debug.c
gcc/domwalk.c
gcc/fixed-value.c
gcc/gencheck.c
gcc/gimple-iterator.c
gcc/gimple-low.c
gcc/gimple-pretty-print.c
gcc/hooks.c
gcc/ipa-pure-const.c
gcc/ipa-reference.c
gcc/ipa-utils.c
gcc/java/except.c
gcc/java/jvgenmain.c
gcc/java/jvspec.c
gcc/java/mangle.c
gcc/java/zextract.c
gcc/lto-section-in.c
gcc/lto-section-out.c
gcc/lto-streamer-out.c
gcc/lto-streamer.c
gcc/lto/lto.c
gcc/main.c
gcc/objc/objc-lang.c
gcc/params.c
gcc/print-tree.c
gcc/tree-call-cdce.c
gcc/tree-cfg.c
gcc/tree-cfgcleanup.c
gcc/tree-complex.c
gcc/tree-dump.c
gcc/tree-eh.c
gcc/tree-if-conv.c
gcc/tree-into-ssa.c
gcc/tree-nomudflap.c
gcc/tree-nrv.c
gcc/tree-optimize.c
gcc/tree-outof-ssa.c
gcc/tree-predcom.c
gcc/tree-pretty-print.c
gcc/tree-profile.c
gcc/tree-ssa-coalesce.c
gcc/tree-ssa-copy.c
gcc/tree-ssa-copyrename.c
gcc/tree-ssa-dce.c
gcc/tree-ssa-dom.c
gcc/tree-ssa-dse.c
gcc/tree-ssa-ifcombine.c
gcc/tree-ssa-live.c
gcc/tree-ssa-loop-ch.c
gcc/tree-ssa-loop-im.c
gcc/tree-ssa-loop-ivcanon.c
gcc/tree-ssa-loop-manip.c
gcc/tree-ssa-loop-niter.c
gcc/tree-ssa-loop-unswitch.c
gcc/tree-ssa-loop.c
gcc/tree-ssa-operands.c
gcc/tree-ssa-phiopt.c
gcc/tree-ssa-phiprop.c
gcc/tree-ssa-pre.c
gcc/tree-ssa-propagate.c
gcc/tree-ssa-reassoc.c
gcc/tree-ssa-sink.c
gcc/tree-ssa-ter.c
gcc/tree-ssa-threadedge.c
gcc/tree-ssa-threadupdate.c
gcc/tree-ssa-uncprop.c
gcc/tree-ssa-uninit.c
gcc/tree-ssanames.c
gcc/tree-stdarg.c
gcc/tree-switch-conversion.c
gcc/tree-tailcall.c
gcc/tree-vect-patterns.c
gcc/tree-vect-slp.c
gcc/tree-vectorizer.c
gcc/tree-vrp.c
libdecnumber/dconfig.h
libgcc/generic-morestack-thread.c

[Bug other/46489] tree optimizer and frontend files use target macros

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46489

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-01-24
     Ever Confirmed|0                           |1

--- Comment #8 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-01-24 00:01:55 UTC ---
Confirmed.

[Bug other/46489] tree optimizer and frontend files use target macros

[xerofoify at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46489

Nicholas Krause <xerofoify at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |xerofoify at gmail dot com

--- Comment #11 from Nicholas Krause <xerofoify at gmail dot com> ---
(In reply to Eric Gallager from comment #10)
> (In reply to Eric Gallager from comment #9)
> > (In reply to Joseph S. Myers from comment #7)
> > > FWIW, the following files include tm.h and appear not to have any direct
> > > uses of target macros, or uses of the most common headers (such as rtl.h or
> > > cp-tree.h) that depend on tm.h.  They require more careful checks of what
> > > headers they are using for any hidden tm.h dependencies, but may be good
> > > candidates for the removal of tm.h includes.
> > > 
> > > gcc/java/except.c
> > > gcc/java/jvgenmain.c
> > > gcc/java/jvspec.c
> > > gcc/java/mangle.c
> > > gcc/java/zextract.c
> > 
> > I don't know about the rest of them, but these at least are gone.
I looked through the code and most of the original files either no longer
exist or are removed.  A lot of the remaining ones seem to be in the c,
C++ and other frontends.
> 
> I checked for other removals:
> 
> (In reply to Joseph S. Myers from comment #7)
> > gcc/c-aux-info.c
> > gcc/c-convert.c
> > gcc/c-errors.c
> > gcc/c-lang.c
> > gcc/c-parser.c
> 
The only files mentioned are that require tm.h still are
gcc/c/c-errors.
gcc/c/c-aux-info.c
> These have all been moved to gcc/c/
> 
> > gcc/cppspec.c
> 
> This has been moved to gcc/c-family/
> 
> > gcc/tree-nomudflap.c
> > gcc/tree-optimize.c
> > gcc/tree-ssa-copyrename.c
> 
> These 3 appear to have been removed.