The following target macros are present in 3.0 but not in 2.95.3, and are undocumented, which is a regression. ASM_OUTPUT_DWARF_PCREL ASM_SIMPLIFY_DWARF_ADDR BUILD_VA_LIST_TYPE CONST_SECTION_ASM_OP CONVERT_HARD_REGISTER_TO_SSA_P CRT_END_INIT_DUMMY CRT_GET_RFIB_DATA DWARF_FRAME_REGISTERS EXPAND_BUILTIN_VA_ARG EXPAND_BUILTIN_VA_START HARD_REGNO_RENAME_OK IA64_UNWIND_EMIT IA64_UNWIND_INFO IDENT_ASM_OP INTEL_EXTENDED_IEEE_FORMAT MAX_LONG_DOUBLE_TYPE_SIZE MD_FALLBACK_FRAME_STATE_FOR STABS_GCC_MARKER TARGET_EBCDIC TARGET_ESC TDESC_SECTION_ASM_OP Release: 3.0 Environment: System: Linux digraph 2.4.5 #1 Sat May 26 09:50:17 UTC 2001 i686 unknown Architecture: i686 host: i686-pc-linux-gnu build: i686-pc-linux-gnu target: i686-pc-linux-gnu configured with: ../gcc-3.0/configure --prefix=/usr --with-slibdir=/lib --enable-shared --enable-threads=posix --with-system-zlib
Fix: Document these macros.
State-Changed-From-To: open->analyzed State-Changed-Why: Confirming my PR, and marking as "high" since it is a regression from 2.95.
The following where fixed in at least mainline (20030524): ASM_OUTPUT_DWARF_PCREL MAX_LONG_DOUBLE_TYPE_SIZE MD_FALLBACK_FRAME_STATE_FOR TARGET_ESC The ones fixed are by: 2002-09-12 Stan Shebs <shebs@apple.com> * doc/tm.texi (TARGET_TERMINATE_DW2_EH_FRAME_INFO): Document. (ASM_OUTPUT_DWARF_DELTA): Ditto. (ASM_OUTPUT_DWARF_OFFSET): Ditto. (ASM_OUTPUT_DWARF_PCREL): Ditto. 2001-06-26 Jim Wilson <wilson@redhat.com> (even though NTEL_EXTENDED_IEEE_FORMAT is now undocumented) * doc/tm.texi (MAX_LONG_DOUBLE_TYPE_SIZE, INTEL_EXTENDED_IEEE_FORMAT): Document. 2001-07-08 Richard Henderson <rth@redhat.com> * doc/tm.texi (Exception Handling): New subnode of Stack and Calling. Document MD_FALLBACK_FRAME_STATE_FOR. 2001-06-27 Neil Booth <neil@cat.daikokuya.demon.co.uk> * doc/tm.texi: Document TARGET_ESC.
Adding the people who introduced these undocumented target marcos: rth@redhat.com: ASM_SIMPLIFY_DWARF_ADDR, BUILD_VA_LIST_TYPE, CRT_GET_RFIB_DATA, EXPAND_BUILTIN_VA_ARG, EXPAND_BUILTIN_VA_START oldham@codesourcery.com: CONVERT_HARD_REGISTER_TO_SSA_P jakub@redhat.com: CRT_END_INIT_DUMMY martin@loewis.home.cs.tu-berlin.de: DWARF_FRAME_REGISTERS wilson@redhat.com: INTEL_EXTENDED_IEEE_FORMAT hp@axis.com: TDESC_SECTION_ASM_OP (even though he said in the ChangeLog for which added this one, it was documented). Not added: unknown new email (Stan Cox <scox@cygnus.com>): HARD_REGNO_RENAME_OK Andrew MacLeod <amacleod@cygnus.com>, Jim Wilson <wilson@cygnus.com>, Andrew Haley <aph@cygnus.com>: IA64_UNWIND_EMIT, IA64_UNWIND_INFO Mark Elbrecht <snowball3@bigfoot.com>: IDENT_ASM_OP Zack Weinberg <zackw@stanford.edu>: STABS_GCC_MARKER linas@linas.org: TARGET_EBCDIC CONST_SECTION_ASM_OPL unknown, it was there before 2.95.3.
Subject: Re: Undocumented target macros in 3.0 > Date: 28 May 2003 00:17:21 -0000 > From: "pinskia@physics.uc.edu" <gcc-bugzilla@gcc.gnu.org> > Adding the people who introduced these undocumented target marcos: > hp@axis.com: TDESC_SECTION_ASM_OP (even though he said in the ChangeLog for > which added this one, it was documented). I'm an innocent bystander: I did not introduce TDESC_SECTION_ASM_OP. I see a ChangeLog(.4) entry of mine vaguely related to TDESC_SECTION_ASM_OP, dated 2000-09-25: a large patch where I added leading and trailing TAB characters to most *ASM_OP macros. Perhaps you meant some other macro? brgds, H-P
I removed hp@axis.com from the CC as he really is an innocent bystander, I should have read the changelog more closely.
TDESC_SECTION_ASM_OP is gone cross that one off the list.
Chaning this to a regression because these should fixed soon.
This PR is targeted for 3.3.1, but I believe it is not reasonable to expect this to be fixed before then; this PR is important for 3.4 and it really, _really_, __REALLY__ should be fixed for 3.4. But certainly not for 3.3.1. So I moved the target milestone. Is the list of undocumented macros still up to date? Is there a way to check this quickly?
There really is no easy way to find out what are the new ones that got not documented, I tried to update the list that was there and add people who added some of the patches which added the target macros.
Subject: Re: [3.3/3.4 Regression] Undocumented target macros in 3.0 On Fri, 2003-07-11 at 16:33, steven at gcc dot gnu dot org wrote: > PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org. > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3386 > > > steven at gcc dot gnu dot org changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |mark at codesourcery dot com > Target Milestone|3.3.1 |3.4 I'd prefer we leave this for 3.3.2, rather than 3.4, so that it shows up on everyone's radar when they search for bugs to kill for the next release. Thanks,
Subject: Re: [3.3/3.4 Regression] Undocumented target macros in 3.0 On Sat, 11 Jul 2003, steven at gcc dot gnu dot org wrote: > Is the list of undocumented macros still up to date? Is there a way to check > this quickly? The list in the bug report is a subset of my longer list (of the same vintage) <http://gcc.gnu.org/ml/gcc/2001-06/msg00507.html> (linked to from projects/beginner.html), from which I extracted those that weren't in 2.95 so that the bug was a regression. That message describes the methodology - that the macro is defined in a target header, used somewhere else in the compiler, and not mentioned in the manual - the implementation was probably a perl+shell one-liner on the command line with some subsequent manual editing. Other similar checks that can be done: * Macros that are documented but not defined by any targets, or defined only with one default value (in which case the default should at least go to defaults.h if there is thought to be value in retaining the macro). * Macros that are documented but not used in the compiler (whether or not defined by targets). * Macros that are defined in a target header but not used in the compiler (including in that config directory), whether or not documented. * Macros that are tested in the compiler but not defined anywhere and not documented. I.e., if DOC is the set of all documented target macros (extracted from the manual), DEF is the set of those that are defined (or defined with nondefault values, ideally), extracted from target headers and USE is the set of all identifiers used in the compiler that might possibly be macros (this generates much too big a set and in some cases should include those used in target headers, in some cases shouldn't; it also needs to cover #ifdef / #ifndef), then: * Anything in DOC should be in DEF intersect USE. * Anything in DEF intersect USE should be in DOC. * Anything in DEF should be in the bigger version of USE (including uses within that target directory). * Anything in USE that is used _as a macro_ (meaning in preprocessor conditional tests) should be in a bigger version of DEF that includes defines outside target headers and autoconf-generated defines. A lot of such checks may generate false positives in practice. But perhaps robust scripts to generate DOC, the two versions of DEF and the three versions of USE would help people do these tests.
I've decided to clear the target milestone for this PR. Realistically, this bug just isn't ever going to hold up any release, ever.
Subject: Re: Hookize BUILD_VA_LIST_TYPE On Wed, 29 Oct 2003, Richard Henderson wrote: > Part 1 of 3 to hookize the stdarg target macros. Applied to mainline > to minimize tree-ssa divergence. So an undocumented macro has become an undocumented target hook; PR 3386 (still a regression) still applies.
Even though Mark cleared it but it would be nice to have it on People's radars for 3.5.
I've downgraded the priority and severity of this PR. This PR is certainly not "critical" severity; it doesn't stop people from using the compiler. It is also not high-priority; there will never be end-user complains about this. I've also once-again removed the target milestone, as we'll never hold up the release for this problem.
A little update on the original list of undocumented macros: ASM_OUTPUT_DWARF_PCREL - documented ASM_SIMPLIFY_DWARF_ADDR - removed and poisoned BUILD_VA_LIST_TYPE - removed and poisoned CONST_SECTION_ASM_OP - removed and poisoned CONVERT_HARD_REGISTER_TO_SSA_P - removed and poisoned CRT_END_INIT_DUMMY - removed and *not* poisoned CRT_GET_RFIB_DATA - *not* documented DWARF_FRAME_REGISTERS - documented EXPAND_BUILTIN_VA_ARG - removed and poisoned EXPAND_BUILTIN_VA_START - *not* documented HARD_REGNO_RENAME_OK - documented IA64_UNWIND_EMIT - removed and *not* poisoned IA64_UNWIND_INFO - removed and *not* poisoned IDENT_ASM_OP - *not* documented INTEL_EXTENDED_IEEE_FORMAT - removed and *not* poisoned MAX_LONG_DOUBLE_TYPE_SIZE - removed and poisoned MD_FALLBACK_FRAME_STATE_FOR - documented STABS_GCC_MARKER - removed and poisoned TARGET_EBCDIC - removed and *not* poisoned TARGET_ESC - documented TDESC_SECTION_ASM_OP - Only used in config/i860/sysv4.h (not a target macro?) Perhaps there are new undocumented hooks/macros, but I doubt it - our docs maintainers are like watchdogs that never sleep ;-) So ignoring the non-poisoning for which the obvious patch can be crafted in minutes, the following three are the only remaining problems: CRT_GET_RFIB_DATA EXPAND_BUILTIN_VA_START IDENT_ASM_OP Just to get it over with, I'll see what I can do to document these.
Subject: Re: [3.3/3.4/4.0 Regression] Undocumented target macros in 3.0 On Fri, 3 Dec 2004, steven at gcc dot gnu dot org wrote: > BUILD_VA_LIST_TYPE - removed and poisoned I noted in comment #14 that this was a case of an undocumented macro changing to an undocumented hook. I.e., there's still the regression "current varargs interface undocumented". Finding undocumented hooks is easier than finding undocumented macros, and all such hooks are inevitably regressions from before there were target hooks: TARGET_VECTORIZE_MISALIGNED_MEM_OK TARGET_VECTORIZE_BUILTIN_MASK_FOR_LOAD TARGET_VECTORIZE_BUILTIN_MASK_FOR_STORE TARGET_EH_RETURN_FILTER_MODE TARGET_FOLD_BUILTIN TARGET_VALID_POINTER_MODE TARGET_CANNOT_FORCE_CONST_MEM TARGET_CANNOT_COPY_INSN_P TARGET_DELEGITIMIZE_ADDRESS TARGET_BUILD_BUILTIN_VA_LIST TARGET_HANDLE_PRAGMA_REDEFINE_EXTNAME TARGET_HANDLE_PRAGMA_EXTERN_PREFIX
Subject: Re: [3.3/3.4/4.0 Regression] Undocumented target macros in 3.0 steven at gcc dot gnu dot org wrote: > CRT_GET_RFIB_DATA > EXPAND_BUILTIN_VA_START > IDENT_ASM_OP > > Just to get it over with, I'll see what I can do to document these. That's great!