Initial GCC 14.1.0 support #2146
Conversation
nikkon-dev
commented
May 8, 2024
nikkon-dev
commented
- gcc 14 package version
- tar.gz and tar.xz checksums
- patches from gcc13 that can still be applied to gcc14
|
let's see how the builds go |
I don't think that macOS build failure due to lacking the makeinfo tool is anyhow connected to the changes. |
|
Yeah not related to your stuff but maybe there has been a change to the macos runners. Are you based off the latest master? |
Yes, It was based on the latest master branch. |
nikkon-dev
force-pushed
the
nikkon-dev/gcc14
branch
from
58172f7
to
58792a3
Compare
|
I updated the macOS CI workflows to install missing tools via Homebrew. The build passed in my branch.. |
|
I've kicked off the CI run again to see what happens. For the final version please submit this as a series of 2 patches. One for the CI changes. One for the new GCC version |
MacOs CI PR: 2147 I'll resubmit this one on top of the master once the 2147 is merged. |
|
Now we're on to actual failures. From arc-multilib-linux-uclibc: |
Those errors are not related to MacOS but rather actual incompatibilities with gcc14. I created #2148 to backport recent gcc14 changes from the uClibc-ng. The gcc14 integration is proving to be a complex task. There are numerous issues with missing headers (some are not included transiently anymore) and variations in the warnings/errors that gcc14 reports. It's a daunting task to build every combination of targets/libraries versions. How should this effort progress further? |
|
I think just keep doing what you're doing. Build one or two configurations
locally and keep updating the PR with fixes and to identify new failures.
Rinse and repeat.
…On Sat, 11 May 2024, 6:05 pm Nik Konyuchenko, ***@***.***> wrote:
Now we're on to actual failures. From arc-multilib-linux-uclibc:
Error: libc/sysdeps/linux/common/futimesat.c:36:16: error: implicit declaration of function 'utimensat'; did you mean 'futimesat'? [-Wimplicit-function-declaration]
Those errors are not related to MacOS but rather actual incompatibilities
with gcc14. I created #2148
<#2148> to backport
recent gcc14 changes from the uClibc-ng.
The gcc14 integration is proving to be a complex task. There are numerous
issues with missing headers (some are not included transiently anymore) and
variations in the warnings/errors that gcc14 reports. It's a daunting task
to build every combination of targets/libraries versions.
How should this effort progress further?
—
Reply to this email directly, view it on GitHub
<#2146 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABGAE4N5ID3HKF32O6PERLZBWYI5AVCNFSM6AAAAABHMPWAVCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBVGU4DGNZUHA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
nikkon-dev
force-pushed
the
nikkon-dev/gcc14
branch
from
58792a3
to
b246b80
Compare
cpackham
force-pushed
the
nikkon-dev/gcc14
branch
from
b246b80
to
e877ff9
Compare
nikkon-dev
force-pushed
the
nikkon-dev/gcc14
branch
from
e877ff9
to
210ea7c
Compare
cpackham
force-pushed
the
nikkon-dev/gcc14
branch
2 times, most recently
from
5d39934
to
dfbd38d
Compare
|
Some helpful work was done in the compiler explorer: compiler-explorer/compiler-explorer#6406 |
|
8c371dc commit fixed the sh-unknown-elf build |
Resolve the following build error for arc-multilib-linux-uclibc.
libc/sysdeps/linux/common/fstat64.c: In function 'fstat64':
libc/sysdeps/linux/common/fstat64.c:33:38: error: passing argument 2 of '__syscall_fstat64' from incompatible pointer type [-Wincompatible-pointer-types]
33 | return __syscall_fstat64(fd, buf);
| ^~~
| |
| struct stat64 *
While we're at it bring in one more bug fix patch from upstream.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
+ gcc 14 package version + tar.gz and tar.xz checksums + patches from gcc13 that can still be applied to gcc14 Signed-off-by: Nik Konyuchenko <spaun2002mobile@gmail.com>
Current glibc versions don't compile without warnings with GCC14. Disable -Werror for glibc when using GCC14. Signed-off-by: Chris Packham <judge.packham@gmail.com>
GCC14 has started to complain about sloppily written configure tests. Update them so the code snippet is valid according to GCC14. Signed-off-by: Chris Packham <judge.packham@gmail.com>
GCC14 will treat implicit-function-declaration as an error by default. See https://gcc.gnu.org/gcc-14/porting_to.html for details. Some libc function like __trap34 are defined in assembly and break this GCC diagnostic. Signed-off-by: Nik Konyuchenko <spaun2002mobile@gmail.com>
cpackham
force-pushed
the
nikkon-dev/gcc14
branch
from
b394f26
to
3cb85fb
Compare
