Re: [avr-gcc-list] Link Time Optimization vs __builtin_unreachable() and .signature?

[Georg-Johann Lay]

Bob Paddock schrieb:

> > Compiler bugs can always be seen in the generated assembly text.
> > GCC is a text->text transformer that maps high level language
> > source code to low level language source code.
> >
> > If you observe a defect, that effect can be reproduced by anyone
> > if he has the sources and knows what options you use on what
> > compiler version.
>
> cloc says the project is 64118 lines of source code, 8000 of them are
> comments.  I have no idea how to turn that into a simple test case.

There are basically two approaches to get a small test case:

- Write a test case from scratch:  To do this you must have an idea
how the bug works or how it is triggered.  If your guess is wrong,
then it's unlikely you find a test case that way.  We already saw that
the assumption "builtin unreachable is culprit" is wrong...

- Reduce/obfuscate an existing test case as much as possible:
As you are sure that is is a bug, you have revealed a connexion
between a specific source construct and a specific part in the
generated assembler that exhibits the compiler bug, i.e.
missing or wrong instructions, etc.

Now start reducing the test case. For example, throw away a complex
function and replace it with a dummy.  Or omit module foo.c and the
function foo therein altogether and just -Wl,--defsym=foo=0.

With almost 100% certainty your test case is /not/ minimal (or close to)
and thus can be gross simplified.

A test case just has to produce the issue.  The test case don't have to
to anything sensible (with respect to what the code does, it should
still be valid source code with defined behavior, of course).


> > Because I am not a gcc developer familiar with LTO, a knowledgeable
> > gcc developer would have to have a look at the issue.
>
> This is a production project.  I'm not going to give the code out for
> the world to see.

> I'm going to consider LTO to buggy to use, hopefully 
> it will work in some future version, and move on.

In LTO there is nothing AVR-specific.  And LTO is not an optimization
algorithm or strategy:  With LTO, the object file contains information
on the program like call graph and intermediate representation of the
code. At link time, the linker calls the compiler by means of a plugin
so that the compiler gets more (global) information on the program.
It is very much as if you compiled all files at once.

The optimizations GCC uses with LTO are exactly the same as without LTO.
The only difference is that GCC has more information, e.g. on external
functions.

When users report "bugs in the compiler" it's often a bug in their
program.  For example, a missing volatile does not hurt with -O0, but
it's likely the flaw will lead to non-functional code with higher
optimizations.  Notice that "non-functional" is not the same as "bogus",
i.e. the generated code still complies to the language standard and is
a correct transformation of the source code.  It's just that the source
does not express the programmer's intention in a robust, optimization
invariant way...

Because software as complex as GCC or Mozilla FireFox can be built with
LTO successfully, and LTO is not AVR-specific at all, there is some
indication that you hit a flaw in your code, not a flaw in the compiler.


> > Because I am not a gcc developer familiar with LTO, a knowledgeable
> > gcc developer would have to have a look at the issue.
>
> This is a production project.  I'm not going to give the code out for
> the world to see.

Under the assumption that it's actually an LTO issue (or an issue in
some other optimization pass just triggered by the additional
information supplied by LTO) and not a flaw in your code, and
under the really unlikely assumption that your test case cannot be
minimized to a code that is useless for Taiwanese, you have several
option beside a proper bug report:

1) Track the issue yourself. You have the compiler sources and
everything needed to do it.  Your tools are generated with
optimization and symbols stripped off. Thus, if you want to track
it yourself, you want to rebuild the compiler with, say, -g3 -O0.

2) Review the compiler sources and show the source bit that causes
the bug.  Then you can explain to the developers why the source is
wrong and likely the knowledge enables you to write an easy and
non-compromising test case.

3) Hire a third-party company to get avr-gcc support and negotiate
a non-disclosure agreement with respect to your bug reports and
test cases.

4) Don't do any thing about it, don't use the feature and hope it's
actually /that/ feature that triggered the bug.  Just sit and wait
and hope it won't bit you again in a completely different context.

Johann