On 05/28/2017 03:12 PM, Iain Buclaw wrote:
> This patch adds the D frontend language configure make files, as
> described on the anatomy of a language front-end.
>
> ---
>
>
> 04-d-frontend-misc.patch
>
>
> +
> +You can specify more than one input file on the @command{gdc} command line,
> +in which case they will all be compiled. If you specify a
> +@code{-o @var{file}} option, all the input files will be compiled together,
> +producing a single output file, named @var{file}. This is allowed even
> +when using @code{-S} or @code{-c}.
So out of curiosity, when multiple sources are specified on the command
line, are they subject to IPA as a group or are they handled individually?
> +@item -fno-bounds-check
> +@cindex @option{-fbounds-check}
> +@cindex @option{-fno-bounds-check}
> +Turns off array bounds checking for all functions, which can improve
> +performance for code that uses array extensively. Note that this
> +can result in unpredictable behavior if the code in question actually
> +does violate array bounds constraints. It is safe to use this option
> +if you are sure that your code will never throw a @code{RangeError}.
So I don't know the internals of where you keep the bounds and how you
generate code for checking, but it might be worth looking at what Roger
Sayle did for Java array index checking back in 2016:
https://gcc.gnu.org/ml/java-patches/2016-q1/msg00014.html
I don't know if his trick of exposing an extra write would apply to D,
but it's worth reviewing.
> +
> +@item -funittest
> +@cindex @option{-funittest}
> +@cindex @option{-fno-unittest}
> +Turns on compilation of @code{unittest} code, and turns on the
> +@code{version(unittest)} identifier. This implies @option{-fassert}.
I think we're using -fselftest elsewhere for unit testing bits within
the compiler. Can you look and see if your unit tests are comparable
and perhaps consider using the same option if they are?
> +
> +@node Code Generation
> +@section Code Generation
> +@cindex options, code generation
> +
> +In addition to the many @command{gcc} options controlling code generation,
> +@command{gdc} has several options specific to itself.
> +
> +@table @gcctabopt
> +
> +@item -M
> +@cindex @option{-M}
> +Output the module dependencies of all source files being compiled in a
> +format suitable for @command{make}. The compiler outputs one
> +@command{make} rule containing the object file name for that source file,
> +a colon, and the names of all imported files.
[ ... Many -M options ... ]
Note we recently allowed generation of the dependency files even in the
case some errors. Please consider doing the same if it makes sense.
See the Sept change to c_common_finish.
> +
> +@c man begin ENVIRONMENT
> +
> +In addition to the many @command{gcc} environment variables that control
> +its operation, @command{gdc} has a few environment variables specific to
> +itself.
> +
> +@vtable @env
> +
> +@item D_IMPORT_PATH
> +@findex D_IMPORT_PATH
> +The value of @env{D_IMPORT_PATH} is a list of directories separated by a
> +special character, much like @env{PATH}, in which to look for imports.
> +The special character, @code{PATH_SEPARATOR}, is target-dependent and
> +determined at GCC build time. For Microsoft Windows-based targets it is a
> +semicolon, and for almost all other targets it is a colon.
> +
> +@item DDOCFILE
> +@findex DDOCFILE
> +If @env{DDOCFILE} is set, it specifies a text file of macro definitions
> +to be read and used by the Ddoc generator. This overrides any macros
> +defined in other @file{.ddoc} files.
How important are the environment variables to the existing user base?
We generally try to avoid changing much behavior based on environment
variables. Can these be made command line options?
jeff
