User account creation filtered due to spam.
The following target macros are present in 3.0 but not in 2.95.3, and
are undocumented, which is a regression.
System: Linux digraph 2.4.5 #1 Sat May 26 09:50:17 UTC 2001 i686 unknown
configured with: ../gcc-3.0/configure --prefix=/usr --with-slibdir=/lib --enable-shared --enable-threads=posix --with-system-zlib
Document these macros.
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):
The ones fixed are by:
2002-09-12 Stan Shebs <firstname.lastname@example.org>
* doc/tm.texi (TARGET_TERMINATE_DW2_EH_FRAME_INFO): Document.
2001-06-26 Jim Wilson <email@example.com> (even though
NTEL_EXTENDED_IEEE_FORMAT is now undocumented)
* doc/tm.texi (MAX_LONG_DOUBLE_TYPE_SIZE,
2001-07-08 Richard Henderson <firstname.lastname@example.org>
* doc/tm.texi (Exception Handling): New subnode of Stack and Calling.
2001-06-27 Neil Booth <email@example.com>
* doc/tm.texi: Document TARGET_ESC.
Adding the people who introduced these undocumented target marcos:
firstname.lastname@example.org: ASM_SIMPLIFY_DWARF_ADDR, BUILD_VA_LIST_TYPE,
CRT_GET_RFIB_DATA, EXPAND_BUILTIN_VA_ARG, EXPAND_BUILTIN_VA_START
email@example.com: TDESC_SECTION_ASM_OP (even though he said in the ChangeLog for
which added this one, it was documented).
unknown new email (Stan Cox <firstname.lastname@example.org>): HARD_REGNO_RENAME_OK
Andrew MacLeod <email@example.com>, Jim Wilson <firstname.lastname@example.org>,
Andrew Haley <email@example.com>: IA64_UNWIND_EMIT, IA64_UNWIND_INFO
Mark Elbrecht <firstname.lastname@example.org>: IDENT_ASM_OP
Zack Weinberg <email@example.com>: STABS_GCC_MARKER
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: "firstname.lastname@example.org" <email@example.com>
> Adding the people who introduced these undocumented target marcos:
> firstname.lastname@example.org: 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?
I removed email@example.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
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 firstname.lastname@example.org ONLY, *NOT* email@example.com.
> 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
Subject: Re: [3.3/3.4 Regression] Undocumented target macros
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
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
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:
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
Subject: Re: [3.3/3.4/4.0 Regression] Undocumented target
macros in 3.0
steven at gcc dot gnu dot org wrote:
> Just to get it over with, I'll see what I can do to document these.