On 11 September 2017 at 18:05, Jeff Law <l...@redhat.com> wrote:
> 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.
>
A dynamic array is a struct { size_t length, void* ptr }. So if the
length was set in a place where the compiler can infer the value, then
it will be removed by the usual const propagation / dce passes.
Having a quick look, I am pretty sure that the code generation for D
is as such that, that particular case is handled without the extra
write - the length setting should already be exposed.
>> +
>> +@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?
>
A unittest is a D language feature, D unittests are not compiled in by
default. This turns them on.
Contrived example:
double pow2 (double x)
{
return x ^^ 2;
}
unittest
{
assert (pow2 (2) == 4);
}
>
>> +
>> +@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.
>
OK, thanks, I'll have a look. The idea was to be closely resemble
C/C++, even though there is no preprocessor in D, and it outputs the
dependencies between module files.
>
>> +
>> +@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
For D_IMPORT_PATH, there's -I /somedir, I wouldn't say that it needs
to be there, its just an equivalent of something that gcc exposes.
DDOCFILE I found in the DMD front-end implementation, and so thought
it best to say something about it.
Iain.
