https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118280
--- Comment #7 from Thomas Petazzoni ---
(In reply to Joseph S. Myers from comment #6)
> Are you *actually using the code built by recent GCC versions on Microblaze
> hardware running the Linux kernel* (as opposed to simply building software
> f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118280
--- Comment #5 from Thomas Petazzoni ---
(In reply to Mikael Pettersson from comment #4)
> Note that a microblaze-unknown-linux-gnu toolchain builds just fine with
> gcc-14, glibc, and c++ enabled, so perhaps it's a _bit_ premature to
> deprecat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118280
--- Comment #1 from Thomas Petazzoni ---
Actually the issue is not just libstdc++. libatomic.so also uses
__atomic_test_and_set(), and that causes build failures since GCC 14.x. For
example when building linux-pam on Microblaze:
/home/buildroot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118280
Bug ID: 118280
Summary: undefined symbol __atomic_test_and_set in libstdc++.so
on Microblaze
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116007
--- Comment #22 from Thomas Petazzoni ---
Thanks for the patch, I confirm it fixes the build issue I was seeing!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116007
--- Comment #12 from Thomas Petazzoni ---
Thanks for all the discussion, but I'm confused about what the conclusion
actually is. Could you help me understand what's the plan moving forward?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116007
--- Comment #8 from Thomas Petazzoni ---
(In reply to Jakub Jelinek from comment #7)
> That commit made --without-long-double-128 the default on
> powerpc*-*-linux-musl*.
> ELFv2 is one thing, but whether long double is IEEE double, IBM double
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116007
--- Comment #6 from Thomas Petazzoni ---
Thanks for all the feedback! However, I'm still a bit confused. In one comment
you say:
> From thbis, it seems powerpc musl likely doesn't have neither double double
> nor IEEE quad support and so in tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116007
--- Comment #2 from Thomas Petazzoni ---
(In reply to Andrew Pinski from comment #1)
> This might just be fixed on the trunk.
Thanks for the super fast feedback. Do you have a pointer to the commit fixing
this? I quickly looked at the recent ch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116007
Bug ID: 116007
Summary: libquadmath fails to build with
libgcc/soft-fp/quad.h:69:1: error: unable to emulate
'TF'
Product: gcc
Version: 14.1.0
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107728
--- Comment #3 from Thomas Petazzoni ---
Thanks for the super quick feedback. Could you clarify "Move over, the
functions are not optimized out at -O2 but rather they don't get pulled in
glibc building because another function is referenced." ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107728
Bug ID: 107728
Summary: with -O0, libgcc in the first stage compiler has
reference to libc functions
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107032
--- Comment #4 from Thomas Petazzoni ---
Yes, same triplet. We do not (yet) have FDPIC support for ARM in Buildroot (we
have a patch series pending for that).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107032
--- Comment #2 from Thomas Petazzoni ---
Thanks for the feedback. There must be something special in those
configurations, because I did build a Cortex-M4 configuration with gcc 11.3.0
just a few days ago, and it built fine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106972
Thomas Petazzoni changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107032
Bug ID: 107032
Summary: ARM: libgcc2.c:2174:1: error: r7 cannot be used in
'asm' here
Product: gcc
Version: 11.3.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106972
--- Comment #5 from Thomas Petazzoni ---
ACK, but what we're using in this configuration is --with-cpu=iwmmxt. I'm a bit
confused between it being a CPU type, and it being just a vector extension.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106972
--- Comment #2 from Thomas Petazzoni ---
Thanks for the quick feedback! I am not super familiar with iwmmxt, but as I
understand it is used in Marvell PXA270 and above. While these are fairly old
indeed, their support is still maintained in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106972
Bug ID: 106972
Summary: internal compiler error: in extract_insn, at
recog.c:2770 on ARMeb when building gcc itself
Product: gcc
Version: 11.3.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101916
Thomas Petazzoni changed:
What|Removed |Added
CC||thomas.petazzoni@free-elect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101915
Thomas Petazzoni changed:
What|Removed |Added
CC||thomas.petazzoni@free-elect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101952
Thomas Petazzoni changed:
What|Removed |Added
CC||thomas.petazzoni@free-elect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101737
--- Comment #1 from Thomas Petazzoni ---
This still happens with gcc 11.1.0, with the exact same conditions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101737
Bug ID: 101737
Summary: SH4 -Os causes internal compiler error when building
pixman
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
24 matches
Mail list logo
