cross/avr-gcc: Update to 15.2.0 Remove pkgsrc patches that were merged upstream. Full changelog can be found here: Changes for AVR architecture in GCC 15 ====================================== - Support has been added for the signal(num) and interrupt(num) function attributes that allow to specify the interrupt vector number num as an argument. It allows to use static functions as interrupt handlers, and also functions defined in a C++ namespace. - Support has been added for the noblock function attribute. It can be specified together with the signal attribute to indicate that the interrupt service routine should start with a SEI instruction to globally re-enable interrupts. The difference to the interrupt attribute is that the noblock attribute just acts like a flag and does not impose a specific function name. - Support has been added for the __builtin_avr_mask1 built-in function. It can be used to compute some bit masks when code like 1 << offset is not fast enough. - Support has been added for a new 24-bit named address space __flashx. It is similar to the __memx address space introduced in GCC 4.7, but reading is more efficient since it only supports reading from program memory. Objects in the __flashx address space are located in the .progmemx.data section. The address space is available when the feature-test macro __FLASHX is defined. - Apart from the built-in types __int24 and __uint24 supported since GCC 4.7, support has been added for the signed __int24 and unsigned __int24 types. - Code generation for the 32-bit integer shifts with constant offset has been improved. The code size may slightly increase even when optimizing for code size with -Os. - Support has been added for a compact vector table as supported by some AVR devices. It can be activated by the new command-line option -mcvt. It links crtmcu-cvt.o as startup code which is supported since AVR-LibC v2.3. - Support has been added for the new option -mno-call-main. Instead of calling main, it will be located in section .init9. - New AVR specific optimizations have been added. They can be controlled by the new command-line options -mfuse-move, -msplit-ldst, -msplit-bit-shift and -muse-nonzero-bits. - Support for the following devices has been added: AVR32DA28S, AVR32DA32S, AVR32DA48S, AVR64DA28S, AVR64DA32S, AVR64DA48S, AVR64DA64S, AVR128DA28S, AVR128DA32S, AVR128DA48S, AVR128DA64S. Full changelog can be found here: Changes for AVR architecture in GCC 14 ====================================== - On AVR64* and AVR128* devices, read-only data is now located in program memory per default and no longer in RAM. - Only a 32 KiB block of program memory can be used to store and access .rodata in that way. Which block is used can be selected by defining the symbol __flmap. As an alternative, the byte address of the block can be specified by the symbol __RODATA_FLASH_START__ which takes precedence over __flmap. For example, linking with -Wl,--defsym,__RODATA_FLASH_START__=32k chooses the second 32 KiB block. - The default uses the last 32 KiB block, which is also the hardware default for bit-field NVMCTRL_CTRLB.FLMAP. - When a non-default block is used, then NVMCTRL_CTRLB.FLMAP must be initialized accordingly by hand, or AVR-LibC v2.2 that implements #931 can be used. The latter initializes NVMCTRL_CTRLB.FLMAP in the startup code and according to the value of __flmap or __RODATA_FLASH_START__. - When AVR-LibC with #931 is used, then defining the symbol __flmap_lock to a non-zero value will set bit NVMCTRL_CTRLB.FLMAPLOCK. This will protect NVMCTRL_CTRLB.FLMAP from any further changes which would be Undefined Behaviour in C/C++. If you prefer to define the symbol in a C/C++ file, an asm statement can be used: __asm (".global __flmap_lock" "\n\t" "__flmap_lock = 1"); - When you do not want the code from #931, then define a global symbol __do_flmap_init and the linker will not pull in that code from libmcu.a any more. - In order to return to the old placement of read-only data in RAM, the new compiler option -mrodata-in-ram can be used. This is required on devices where the hardware revision is affected by a silicon bug concerning the FLMAP functionality. - Read-only data is located in output section .rodata, whereas it is part of .text when located in RAM. - The feature is only available when the compiler is configured with a version of Binutils that implements PR31124, which is the case for Binutils v2.42 and up. - The implementation consists of two parts: 1. Binutils support new emulations avrxmega2_flmap and avrxmega4_flmap. The sole purpose of these emulations is to provide adjusted default linker description files. Apart from that, these emulations behave exactly the same like avrxmega2 resp. avrxmega4. 2. The compiler uses a device-specs file which links the program with -mavrxmega2_flmap or -mavrxmega2 depending on -m[no-]rodata-in-ram; and similar for -mavrxmega4[_flmap]. This means the feature can be used with older compiler or Binutils versions; all what's needed is an adjusted linker script and a custom device-specs file. - A new compiler option -m[no-]rodata-in-ram has been added. The default is to locate read-only data in program memory for devices that support it, e.g. for AVR64* and AVR128* devices as explained above, and for devices from the avrxmega3 and avrtiny families. - The new built-in macro __AVR_RODATA_IN_RAM__ is supported on all devices. It's defined to 0 or 1. - A new optimization tries to improve code generation for indirect memory accesses on Reduced Tiny devices. It can be controlled by the new compiler option -mfuse-add=level where level may be 0, 1 or 2. - On the Reduced Tiny devices, the meaning of register constraint "w" has been changed. It now constrains the registers R24...R31 as is the case for all the other devices.