On Tue, 16 Oct 2018 at 17:28, Richard Sandiford
<richard.sandif...@arm.com> wrote:
>
> Iain Buclaw <ibuc...@gdcproject.org> writes:
> > diff --git a/gcc/Makefile.in b/gcc/Makefile.in
> > index 4b7cec82382..0b2daa320c3 100644
> > --- a/gcc/Makefile.in
> > +++ b/gcc/Makefile.in
> > @@ -2496,6 +2525,7 @@ s-tm-texi: build/genhooks$(build_exeext)
> > $(srcdir)/doc/tm.texi.in
> > && ( test $(srcdir)/doc/tm.texi -nt $(srcdir)/target.def \
> > || test $(srcdir)/doc/tm.texi -nt $(srcdir)/c-family/c-target.def
> > \
> > || test $(srcdir)/doc/tm.texi -nt
> > $(srcdir)/common/common-target.def \
> > + || test $(srcdir)/doc/tm.texi -nt $(srcdir)/d/d-target.def \
> > ); then \
> > echo >&2 ; \
> > echo You should edit $(srcdir)/doc/tm.texi.in rather than
> > $(srcdir)/doc/tm.texi . >&2 ; \
> > [...]
> > @@ -2784,7 +2815,7 @@ build/genrecog.o : genrecog.c $(RTL_BASE_H)
> > $(BCONFIG_H) $(SYSTEM_H) \
> > $(CORETYPES_H) $(GTM_H) errors.h $(READ_MD_H) $(GENSUPPORT_H)
> > \
> > $(HASH_TABLE_H) inchash.h
> > build/genhooks.o : genhooks.c $(TARGET_DEF) $(C_TARGET_DEF) \
> > - $(COMMON_TARGET_DEF) $(BCONFIG_H) $(SYSTEM_H) errors.h
> > + $(COMMON_TARGET_DEF) $(D_TARGET_DEF) $(BCONFIG_H) $(SYSTEM_H) errors.h
> > build/genmddump.o : genmddump.c $(RTL_BASE_H) $(BCONFIG_H) $(SYSTEM_H)
> > \
> > $(CORETYPES_H) $(GTM_H) errors.h $(READ_MD_H) $(GENSUPPORT_H)
> > build/genmatch.o : genmatch.c $(BCONFIG_H) $(SYSTEM_H) \
>
> I was initially a bit worried about this because it makes the build
> depend on the existence of the d/ directory. But it doesn't look
> like we try to ship separate tarballs for specific source languages
> any more, so that's probably not a problem.
>
> > @@ -10659,6 +10668,22 @@ unloaded. The default is to return false.
> > Return target-specific mangling context of @var{decl} or @code{NULL_TREE}.
> > @end deftypefn
> >
> > +@node D Language and ABI
> > +@section D ABI parameters
> > +@cindex parameters, d abi
> > +
> > +@deftypefn {D Target Hook} void TARGET_D_CPU_VERSIONS (void)
> > +Declare all environmental version identifiers relating to the target CPU
> > using the function @code{builtin_version}, which takes a string
> > representing the name of the version. Version identifiers predefined by
> > this hook apply to all modules and being compiled and imported.
> > +@end deftypefn
>
> "and being"? Does this mean "that are being"?
>
> > +@deftypefn {D Target Hook} void TARGET_D_OS_VERSIONS (void)
> > +Similarly to @code{TARGET_D_CPU_VERSIONS}, but is used for versions
> > relating to the target operating system.
> > +@end deftypefn
> > +
> > +@deftypefn {D Target Hook} unsigned TARGET_D_CRITSEC_SIZE (void)
> > +Returns the size of the data structure used by the targeted operating
> > system for critical sections and monitors. For example, on Microsoft
> > Windows this would return the @code{sizeof(CRITICAL_SECTION)}, while other
> > platforms that implement pthreads would return
> > @code{sizeof(pthread_mutex_t)}.
> > +@end deftypefn
>
> Please reflow the .def so that these fit within 80 chars.
>
This file is auto-generated, but looking at other entries, some remain
within 80 chars, others are one line such as this. I'll see if I can
spot the difference in the tm.texi.in file.
> OK otherwise if no target maintainer objects to the changes to their port
> (I think they've had plenty of time already :-))
>
I can cc them just to make sure there's no doubt about that.
--
Iain
