[m-dev.] promoted ROTDs

[Zoltan Somogyi]

On Tue, 24 Jul 2018 15:07:38 +1000, Peter Wang <novalazy at gmail.com> wrote:
> clang understands -Werror as well.
> 
> I think you can turn it on for bootchecks by default, with an option to
> disable it. Different compiler versions will often warn about different
> things, sometimes important but sometimes relatively harmless things.
> It should be possible to continue testing while (knowingly) ignoring
> warnings.

I added -Werror to the .mgnuc_copts file in all the directories
(runtime, library, compiler etc) and got a clean bootcheck in hlc.gc.
However, the bootcheck in asm_fast.gc was anything but clean.
First, you get errors (originally warnings) in mercury_context.c
for its use of the system-provided FD_SET macro. After several layers,
it expands to a conditional expression that contains a call to a function
with a __warnattr. The call should never be made (the condition *should*
prevent it), but gcc either doesn't know this or doesn't care. I have found
no way to shut this off. The second is that in asm_fast.gc, the way we
get around the non-officially-approved nature of our global use of local labels
leaves us using functions that we define using asm code, but not C code,
so gcc thinks that a module uses a function without defining it. We normally
filter out messages about this using mfiltercc, so when I enabled -Werror,
I got output that said that gcc failed, without saying *why*, the why being
eaten by mfiltercc.

I don't think either problem is simple to fix, and I don't think the benefit
is enough to warrant much effort, so I think the best remaining approach
is a new mgnuc option that turns on -Werror only in MLDS grades.
We could then specify the option for hlc bootchecks in tools/bootcheck,
and/or in Mmake.params files for earlier feedback. Any opinions?
 
> Actually, the warning I have in mind is not only harmless but spurious:
> for a while, gcc used to complain about local variables shadowing
> globals.

I seem to remember a similar problem that occurred because the MLDS
code generator used to use a very cavalier method of deciding where
to declare the C variables corresponding to Mercury variables, and could
sometimes decide to declare such C variables more than once,
sometimes in nested scopes. None of those scopes was the global
scope though, and I fixed that problem years ago. While it *was*
spurious in our case, I think sometimes such shadowing *is* a symptom
of a real problem, so I think the warning is justified.

Zoltan.