Re: LIBGCC14 fails to build on MacOS Sequoia x64

Hi Samuele, The gcc-patches list is for submission and review of patches to GCC. For general help, please use the generic gcc mailing-list (gcc@gcc.gnu.org ), and/or file a bug directly at https://gcc.gnu.org/bugzilla/ The issue you’re referring to, a failure to build l

Re: GCC Quad-Precision Math Library Manual: Errors

Hi Peter, You are right, thanks for reporting these issues in the libquadmath documentation. I am CC’ing the GCC mailing-list. Does the following patch seem right? diff --git a/libquadmath/libquadmath.texi b/libquadmath/libquadmath.texi index dc2a9ff374b..ce4accf6421 100644 --- a/libquadmath/li

Re: Nonbootstrap build with Apple clang broken in gm2

> Ah yes indeed it is systematic. Many thanks for spotting this - git > pushed GNU flex required > https://gcc.gnu.org/pipermail/gcc-cvs/2024-July/406305.html Couldn’t the generated files be committed to the tree, so that flex is not needed (unless one modifies the source). This is what is done

Re: Nonbootstrap build with Apple clang broken in gm2

Another quick m2-related question: I am seeing, in a build of GCC 14.1.0 on Linux, that flex is called when building with the modula-2 front-end. It was not the case in previous builds, and the only difference is that I added m2 to the languages. Is that systematic? If so, the prerequisites page

Nonbootstrap build with Apple clang broken in gm2

Hi, I am unable to perform a nonbootstrap build when gm2 is included, with Apple clang 15 as compiler. The error is due to incorrect inclusion of headers ( and ) which are included after GCC’s system.h has been included, and macros like abort() are redefined or poisoned. I think the correct id

Re: What is the purpose of these two fixincludes?

> Laugh or cry. Wow. But how does any other compiler deal with them? I’ve pushed the change as https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=66d6b1861ec57ba29540a5fa7854df3978ba5409 Please let me know if you see any issue in the next tests. FX

Re: What is the purpose of these two fixincludes?

Hi, > I usually just install with install-no-fixedincludes, but really this > should probably be a configure option and default to on. It would be great if we could measure what fixincludes are still needed, on which targets. Could we possibly modify contrib/test_summary to list the fixincluded

What is the purpose of these two fixincludes?

Hi, I am trying to reduce the number of unneeded fixincludes that are used on darwin (because fixincluded headers make it impossible to change SDK once the compiler is built, which is common practice in the macOS world, and quite useful). There are currently two generic (not darwin-specific) f

Re: Updated Sourceware infrastructure plans

> I regenerate auto* files from time to time for libgfortran. Regenerating > them has always been very fragile (using --enable-maintainer-mode), > and difficult to get right. I have never found them difficult to regenerate, but if you have only a non maintainer build, it is a pain to have to make

Analyzer test failures

Hi, I’m seeing the following analyzer test failures on darwin. They were introduced in December, when the tests were moved around: FAIL: c-c++-common/analyzer/fd-glibc-byte-stream-socket.c FAIL: c-c++-common/analyzer/fd-manpage-getaddrinfo-client.c FAIL: c-c++-common/analyzer/fd-mappage-getaddri

Re: Analyzer failure due to missing header

> std::max and std::min, introduced by d99d73c77d1e and 2bad0eeb5573, are not > available because is not included. I originally thought this was only seen in cross-compilers, but it actually broke bootstrap on darwin. Attached patch restores it, OK to commit? FX 0001-Analyzer-include-algori

Analyzer failure due to missing header

Hi David, I’m seeing the following failures on building GCC with Apple’s clang: > /Users/fx/devel/gcc/gcc-repo-write/gcc/analyzer/region-model.cc:3426:16: > error: unexpected type name 'byte_size_t': expected expression >std::max (bytes.m_size_in_bytes, >

Re: Testsuite issue and warning about floating-point conversion

Hi, > That seems like a bug in the aarch64-darwin port. > 1.0q should definitely be __float128 rather than _Float128. Is there a simple way to test what type 1.0q is, in C? I tried using _Generic, but it says > a.c:7:52: error: ‘_Generic’ specifies two compatible types > 7 | int i = _Gene

Re: Testsuite issue and warning about floating-point conversion

Hi, > I don't know why 1.0q is _Float128 on aarch64 instead of __float128. That’s weird. I create it in this way: + /* Populate the float128 node if it is not already done so that the FEs + know it is available. */ + if (float128_type_node == NULL_TREE) +{ + float128_type_node =

Re: Testsuite issue and warning about floating-point conversion

Hi Jakub, I should have pinged you, I see you recently touched that code. FX > Le 18 août 2023 à 21:07, FX Coudert a écrit : > > Hello, > > On the WIP aarch64-darwin port of GCC > (https://github.com/iains/gcc-darwin-arm64), there are some C++ testsuite > failures which are due to the foll

Testsuite issue and warning about floating-point conversion

Hello, On the WIP aarch64-darwin port of GCC (https://github.com/iains/gcc-darwin-arm64), there are some C++ testsuite failures which are due to the following: 1. The testsuite check_effective_target_has_q_floating_suffix check tries to compile the code "float dummy = 1.0q;” to determine if th

Re: Hundreds of gcc.dg/guality failures on both 14 and 13.1 branches

Hi, > Which is why people should just compare testsuite results from earlier run > on the same configuration to watch for regressions, especially in the > guality testsuite. All this gives the idea of a test framework that is too rigid, or tests that are too fragile. I mean, The accumulation of

Hundreds of gcc.dg/guality failures on both 14 and 13.1 branches

Hi, I am finding it very hard to reliably compare test results and regressions with the very large number of gcc.dg/guality test failures that are apparently the new norm on x86_64-linux: more than one hundred on 13.1, and several hundreds on 14. Is there any on-going discussion about this? I

gcc/config.in was not regenerated

Hi, Building GCC in maintainer mode leads to changes in gcc/config.in : > diff --git a/gcc/config.in b/gcc/config.in > index 4cad077bfbe..25442c59aec 100644 > --- a/gcc/config.in > +++ b/gcc/config.in > @@ -67,6 +67,12 @@ > #endif > +/* Define to larger than one set the n