On 16.11.2024 13:19, Gerald Pfeifer wrote:
[...]
How should that be changed? (Simply drop the Atmel line?)
I am not sure what you mean, but I think "Atmel" should be replaced with
"Microchip" because other devices have manufacturers listed.
https://www.microchip.com/pdf/mchp_to_acquire_atmel.p
On 23.02.2025 04:59, Jeff Law wrote:
[...]
it'll have to wait for the next development window. Meaning it
probably won't get any attention for a couple months.Not a big deal. H8 has
never been a popular target.
/J.D.
lesser
than Wtype_MAXp1_F to an UWtype int which of course does not have enough
capacity.
2025-02-22 Jan Dubiec
PR target/116363
libgcc/ChangeLog:
* libgcc2.c (__fixunssfDI): Fix SFtype to UDWtype conversion for targets
without LIBGCC2_HAS_DF_MODE defined libgcc/libgcc2.
On 23.02.2025 04:59, Jeff Law wrote:
[...]
Thanks! Just a note we're in stage4 of our development cycle
(regression bugfixes) as we prepare for gcc-15. This doesn't look like
something we would typically make an exception for, it'll have to wait
for the next development window. Meaning it pr
infoapi/nf-sysinfoapi-globalmemorystatusex
2025-06-23 Jan Dubiec
PR other/108662
libiberty/ChangeLog:
* physmem.c: Replace explicit linking to GlobalMemoryStatusEx()
with implicit linking and get rid of annoying "cast between
incompatible function types"
BUMP
On 10.07.2025 15:42, Jeff Law wrote:
[...]
Anyway, this has been repeatedly bootstrapped & regression tested on
aarch64, ppc64le and other targets. It's also been many dozens of
regression testing cycles on the various embedded targets.
This part of code does not seem to be used on many targe
