Gerald Pfeifer wrote:
> On Fri, 20 Jan 2012, Georg-Johann Lay wrote:
>> Adding AVR-specific release notes to wwwdocs/htdocs/gcc-4.7/changes.html
>
> Index: changes.html
> ===================================================================
> +
The AVR port's libgcc has been improved and its multilib structure
> + has been enhanced. As a result, all objects contributing to an
> + application must either be compiled with GCC versions up to 4.6.x or
> + with GCC versions ≥ 4.7.
>
> How about "...compiled with older versions of GCC, up to GCC 4.6.x,
> or GCC 4.7.0 and later" ?
The "compiled with" might be confusing, for example if someone uses a library
generated with 4.6 and compiles his application with 4.7. He does not compile
the library, but yet he might run into problems because the code assumes a
specific layout of libgcc. Therefore I used the "all objects" wording. It's bit
more technical, but I hoped the reduce misunderstandings.
> And I'd omit the just ≥4.7.0 should work?
>
> + Support has beed added for instrinsic named address spaces
>
> "Support for...has been added" (also typo: beed -> been)
>
> + __pgm
, __pgm1
, …, __pgm5
>
> How about omitting here?
>
> + and __pgmx
. These address spaces locate read-only data in
> + flash memory and allow reading from flash memory by means of vanilla
> + C instructions, i.e. without the need of (inline) assembler code.
>
> What's a C instruction? C builtins?
Is "C code" better? Or C-code? Without the extension, inline assembler must be
used to get correct code, using C like a = b or pstruct->component will yield
wrong code without the extensions if b or *pstruct is located in flash.
> + Support for AVR-specific built-in functions has beed added.
>
> Which ones?
Must they all be named explicitly? Or is it ok to link to onlinedocs?
I'd prefer a link to the explanation in onlinedocs but I am unsure how stable
the links are as docs evolve over time/versions.
> + New command-line options -maccumulate-args
,
> + -mbranch-cost=cost
and -mstrict-X
> + were added to allow better fine-tuning of code optimization.
>
> Should X be put under ... here, to?
No, the X refers to X-register and must be literally, nothing else than
uppercase X is permitted.
> + Many optimizations to:
> +
> + - 64-bit integer arithmetic
> + - Widening multiplication
> + - Integer divide-by-constant
>
> "division by a constant"
>
> + - Generic built-in functions + like
__builtin_ffs*
,
> __builtin_clz*
, etc.
>
> I don't think we need here. Breaking the lines here is something
> a web browser should avoid, but it is not verboten, technically.
Tried to get typesetting all right and avoid Hurenkinder, and I really don't
know if browsers add penalties like TeX does. I frequently see browsers offend
typesetting rules if there is no nanny.
What does "need no " mean? Nothing at ",etc." all or blank ", etc."?
>
> + - Merging of data in
.progmem
>
> What is ".progmen"? Perhaps paraphrase this briefly?
Not easy without getting into too much technical details...
Maybe Eric can help. He is definitely better in English than I am.
> The update is fine assuming you look into my suggestions.
Attached an updated patch as there were many changes and so that Eric and Denis
can easier catch up.
Johann