[m-dev.] promoted ROTDs

Peter Wang novalazy at gmail.com
Wed Jul 25 11:08:27 AEST 2018


On Wed, 25 Jul 2018 02:47:22 +0200 (CEST), "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> 
> 
> 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.

What is the warning?

> 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.

Forgot about that.

> 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?

bootcheck

> > 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.

It was very annoying in graphics code in which y0, y1 are very common
variable names, which also happen to be the name of Bessel functions.

Peter


More information about the developers mailing list