[gentoo-dev] Changing policy about -Werror

[Richard Yao]

> On Sep 13, 2018, at 8:54 PM, Georg Rudoy <0xd34df00d@×××××.com> wrote:
>
>> On 14.09.2018 at 0:44 user Richard Yao <ryao@g.o> wrote:
>> This is a really odd design decision by the GCC developers. With other compilers, the separation between front end and backend is strong enough that you will never have this sort of thing. It does not seem necessary to me either. :/
I didn't want to get into this, but GCC's backend is actually split into
a middle-end, that does architecture independent optimizations and a
backend, that generates assembly code (and likely does architecture
specific optimization):

https://en.wikibooks.org/wiki/GNU_C_Compiler_Internals/GNU_C_Compiler_Architecture

You can get it to dump what appears to be the input to the middle end by
doing -fdump-translation-unit. You can get GCC to dump each stage of the
middle end using -fdump-tree-all. Presumably, any warnings that depend
on optimization won't be generated, although someone would need to study
the code to verify that.

I suspect quite a few people talking about what -Werror -Wall does have
never actually touched the internals of a compiler and perhaps that
should change. I won't claim to be an expert, but I have minor
experience with front-end development, writing code to do error
generation, etcetera. Honestly, when I first looked at GCC's sources, I
decided that I would be happier never looking at them ever again, but I
am starting to reconsider that decision.
>
> You might be able to perform certain additional data/control flow analysis after things like inlining, dead code removal or devirtualization.
Do you have any examples? I am having some trouble making a test case
that shows a different in behavior at different optimization levels
either way.

Here is an example:

__attribute__((always_inline))
static inline int
test(int x) {
        return x;
}

int main() {
        int x;

        return (test(x)*0);
}

GCC 7.3.0 will emit a warning regardless of optimization level provided
that -Wall is passed. However, it will not emit a warning for this at
any optimization level:

int main() {
        int x;

        return (x*0);
}

>
> Moving that logic to the frontend would require essentially duplicating what's the optimizer's gonna do anyway, which might have negative effects on compilation times (both with and without optimizations) and compiler code maintenance.
If it is easier to use the optimizer's infrastructure to figure this
out, then the code could be written to call it to do analysis as a
pseudo-optimization pass, which GCC actually appears to do when it runs
its "Function test" "optimization" pass. There is no code maintenance
burden.

Fabian was right about needing -Wall for -Werror to catch many things
because most warnings are off by default. However, I am extremely
skeptical that the optimization level has significant error. -Wall gives
us whatever we need and so far, I cannot find a code example showing
differences in warning generation at different optimization levels. I'll
accept the idea that the warning quality might change (although I don't
fully understand the reasoning for it) by the GCC documentation.

However, I find the idea that -O3 will make a warning appear that didn't
otherwise appear to be very difficult to accept. The documentation
claims that optimization passes can effect emission of warnings for
uninitialized variables, but the only way that I could imagine that
happening would be if an optimization pass made x*0 into 0 before the
code generating the warning is run. This is the complete opposite of
what is being claimed here. In some actual tests, I am unable to get GCC
to emit a warning for that at any optimization level. I am also unable
to get it to behave differently for uninitialized variables at different
optimization levels no matter what idea I try.
>
>
>
> --
>  Georg Rudoy
>
>