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

[Georg-Johann Lay]

Bob Paddock schrieb:
> > > If main(), and many other used functions, are being removed little
> > > wonder the program doesn't work with LTO.
> >
> > By no means main should be optimized away, so there is evidence that
> > something fundamental is breaking.
> >
> > Is main decorated with attributes?
>
> #define MAIN_OS __attribute__(( OS_main ))
>
> MAIN_OS int main( void )
> {
>   hardware_setup();
>     for(;;)
>       {
>         stuff
>       }
>   return( 0 );
> }
>
> I'm hoping LTO will get rid of things like _exit that can never be reached.
>
> Taking the OS_Main off leaving just 'int main()' made no difference.
>
> > > If you have any interest in looking at this code, let me know and I'll
> > > put it on a web site for you to download.
> >
> > Yes, if the project is ready to be easily rebuilt (no missing
> > headers/directories, etc)
>
> All of the source/headers is self-contained.
>
> I'm using the Utils from WinAVR20100101 to get the POSIX shell environment:
>
> http://sourceforge.net/projects/winavr/files/latest/download
>
> Utils from 
> http://sourceforge.net/projects/getgnuwin32/files/latest/download?source=files
> to get a few more utilities.
>
> Lastly the latest version of SRec, which is 1.59 from the link below
> SourceForge shows it incorrectly as 1.47 in several places:
>
> http://sourceforge.net/projects/srecord/files/srecord-win32/1.59/srecord-1.59-win32.zip/download
>
> The bottom line is a *completely* self-contained project of all
> sources and tools is a .zip file of 250 Megs.

No, no, no. To reproduce an issue all that's needed is

- The sources
- The compiler/tool version and how it is configured
- The command options passed to the tools

The latter two can be seen when gcc is called together with -v

What's definitely not required or wanted are binary files like
tools' binaries or intel hex files or whatever.

> Tell me what you don't need, to make a more manageable download.
> For example you probably don't really need me to send you back the
> 4.7.1-rc1 compiler.

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.

Because I am not a gcc developer familiar with LTO, a knowledgeable
gcc developer would have to have a look at the issue.

We can maximize the chance that someone knowledgeable actually starts
looking into it by exactly describing the issue any by not flooding
him with hundreds of source files, i.e. work out a test case that
is as minimal/easy as you can get it.

The resulting test case need not to be runnable on a hardware or to
perform any meaningful actions, but is must still reproduce the wrong
mapping from C to assembler.

Johann