[Bug other/46489] tree optimizer and frontend files use target macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46489 Nicholas Krause changed: What|Removed |Added CC||xerofoify at gmail dot com --- Comment #11 from Nicholas Krause --- (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.
[Bug other/46489] tree optimizer and frontend files use target macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46489 --- Comment #10 from Eric Gallager --- (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 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 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.
[Bug other/46489] tree optimizer and frontend files use target macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46489 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #9 from Eric Gallager --- (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.
[Bug other/46489] tree optimizer and frontend files use target macros
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
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
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
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
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
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
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
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.
