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.
_______________________________________________
AVR-libc-dev mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
