Re: [avr-libc-dev] New release?

[David Brown]

Dmitry K. wrote:
> On Thursday 29 November 2007 02:16, Anatoly Sokolov wrote:
> [...]
> > I suggest to set up the minimal required version of GCC as 4.2.
> > It will allow:
> >
> > 1. To remove check of new devices which are already supported in the GCC
> > 4.2 from 'configure.ac' file.
> >
> > 2. To remove avr25 divices from 'AVR12_DEV_INFO' in 'gen-avr-lib-tree.sh'
> > file, and do not build 'crt*' files for this devices twice.
> >
> > 3. Do not define '__AVR_HAVE_MOVW__', '__AVR_HAVE_LPMX__' and
> > '__AVR_HAVE_MUL__' macros in avr-libc.
>
> I object.
> The listed items have no value for users and are not burdensome
> for developers of Avr-libc.
>
> On the contrary, I would warn against rash transition
> to version 4.2.
>
> GCC 4.2 is too agressive in optimization. For example,
> the next function is translated as infinite loop (-Os):
>    void foo (void)
>    {
>       int i;
>       for (i = 1; i >= 0; i++) bar ();
>    }
> More, common options '-W -Wall' do NOT type any warnings!

Your "foo" function there is broken code, which happens to have 
generated a non-infinite loop in previous versions of the compiler.  You 
are *always* going to get code that gets caught out when compilers 
improve - a very common problem for newbies switching from poor 
compilers to gcc is that their delay loops suddenly don't work because 
they forgot to use "volatile" (or some other mechanism to force the loop 
to generate code).  It's their code that's broken, not the compiler.

When the "-fstrict-overflow" flag is active (under -Os, -O2, -O3), 
-Wstrict-overflow=1 is set automatically, which (should) warn on many 
overflow errors.  If your code relies on overflowing ints, you can 
always use -fwrapv to get the effect you want.

Changing compiler versions (and library versions) is not something you 
do lightly in the middle of a project - users should expect to have to 
do a thorough check of their code, and when archiving old projects, the 
toolchain used is part of that archive (this is yet another reason why 
gcc is far more suitable for professional development work than many 
commercial compilers - precisely because the compiler can be archived).

> Simultaneously quality of a code concedes not only to
> branches 3.3 and 3.4, but even concedes to a branch 4.1.
> For example, Avr-libc's sscanf("1.2345","%e",&x) takes
> 3886 bytes of flash and 140 bytes of stack with 4.2.2.
> Above branch (4.1.2) uses only 3802 bytes of flash and
> 128 bytes of stack.

This is a much more important issue.  I haven't tested 4.2 for the avr, 
or done serious comparisons with older versions.  Is there anything 
specific behind this problem?

> Dmitry.