sprintersb

> The bz2 tarball includes `config.guess` So then it depends on which autotools Jörg (@dl8dtl) is using to roll the release.

`ftoa_engine.S` has a lookup table located in `.progmem.data`. The assumption is that `.progmem.data` fits in the lower 64 KiB of program memory; if not, then too much progmem is used....

Fixed by 32a152e8878f9643f7d1696d27b616ed1b3b1dca. Though there are more places that use LPM on ELPM devices, see issue #962. To date that issue is only partially fixed by upgrading some libc functions....

Supporting "unsupported" devices is usually done by means of `.atpack` files provided by Atmel / Microchip. Maybe have a look at [Supporting "unsupported" Devices](https://gcc.gnu.org/wiki/avr-gcc#Supporting_.22unsupported.22_Devices) in the avr-gcc wiki, and come...

FYI, support for these devices has been added to avr-gcc v13.3+, see https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=85414e25ade3db84baeba4acef296e4f34f4184b The bulk of work for full support of the devices (without using ATPACK) is on the side...

The answer to the top question is: yes. All these devices are supported now, see current NEWS for example.

Fixed by https://github.com/avrdudes/avr-libc/commit/5023931a1e9fe8d3d14d4c018446ac059e9e715c. Notice that this is only the AVR-LibC part. The feature relies on avr-gcc [PR116056](https://gcc.gnu.org/PR116056) added in v15.

Question has been answered.

> Compiler cannot prove by himself that _SFR_IO_ADDR(_WD_CONTROL_REG) fits into an immediate, so emits an error Do you have a test case (source, compiler version and options)?

alpine issue as explained above