GCC 10.5 Released
When I compile GCC 10.5.0 from /pub/gcc/releases/gcc-10.5.0 and run the resulting executable I get: $ g++ --version g++ (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0 Copyright (C) 2019 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Did I do something wrong? --Sidney Marshall
Re: GCC 10.5 Released
On 7/8/23 14:37, Sidney Marshall wrote: When I compile GCC 10.5.0 from /pub/gcc/releases/gcc-10.5.0 and run the resulting executable I get: $ g++ --version g++ (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0 Copyright (C) 2019 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Did I do something wrong? --Sidney Marshall If you're running g++ from the shell, then unless you have `.` in your PATH and its located before the usual `/bin` directories (very unlikely and an absolutely horrible idea), you're running the g++ binary that's provided by the system. If you want to run a g++ binary located in your current directory, do `./g++`
GCC 10.5 Released
When I compile GCC 10.5.0 from /pub/gcc/releases/gcc-10.5.0 and run the resulting executable I get: $ g++ --version g++ (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0 Copyright (C) 2019 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Did I do something wrong? --Sidney Marshall My mistake. Everything is OK: $ ./g++ --version g++ (GCC) 10.5.0 Copyright (C) 2020 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Using _POSIX_SEM_VALUE_MAX not _SC_SEM_VALUE_MAX?
I have been trying to make clangd work with my GCC-based builds (it's a long story don't ask) and after a ton of effort (and, unfortunately, some hacks due to clangd limitations) there is one thing left that's causing a lot of spurious errors: In gcc/libstdc++-v3/include/bits/semaphore_base.h we find: 56 #ifdef SEM_VALUE_MAX 57 static constexpr ptrdiff_t _S_max = SEM_VALUE_MAX; 58 #else 59 static constexpr ptrdiff_t _S_max = _POSIX_SEM_VALUE_MAX; 60 #endif Unfortunately because I am using limits.h from the clang intrinsics / resource directory (else many other things break), _POSIX_SEM_VALUE_MAX is not defined. I can't quite figure out why, and my attempts to generate preprocessor output to track it down through the #include / #define maze have failed. But the error I get (from clangd) suggests I want to be using _SC_SEM_VALUE_MAX and indeed if I make that change it works. Should GCC be using the _SC version, since that's what's defined in POSIX? Or at least expanding the above to use it as a last resort, as in: #if defined(SEM_VALUE_MAX) static constexpr ptrdiff_t _S_max = SEM_VALUE_MAX; #elif defined(_POSIX_SEM_VALUE_MAX) static constexpr ptrdiff_t _S_max = _POSIX_SEM_VALUE_MAX; #else static constexpr ptrdiff_t _S_max = _SC_SEM_VALUE_MAX; #endif ??
Re: Using _POSIX_SEM_VALUE_MAX not _SC_SEM_VALUE_MAX?
On Jul 08 2023, Paul Smith wrote: > Unfortunately because I am using limits.h from the clang intrinsics / > resource directory (else many other things break), _POSIX_SEM_VALUE_MAX > is not defined. POSIX requires conforming implementations to define _POSIX_SEM_VALUE_MAX. > I can't quite figure out why, and my attempts to generate preprocessor > output to track it down through the #include / #define maze have > failed. But the error I get (from clangd) suggests I want to be using > _SC_SEM_VALUE_MAX and indeed if I make that change it works. _SC_SEM_VALUE_MAX is related, but has a different role. It is the argument to sysconf to retrieve the runtime value of SEM_VALUE_MAX. > Or at least expanding the above to use it as a last resort, as in: > > #if defined(SEM_VALUE_MAX) > static constexpr ptrdiff_t _S_max = SEM_VALUE_MAX; > #elif defined(_POSIX_SEM_VALUE_MAX) > static constexpr ptrdiff_t _S_max = _POSIX_SEM_VALUE_MAX; > #else > static constexpr ptrdiff_t _S_max = _SC_SEM_VALUE_MAX; That needs to be sysconf (_SC_SEM_VALUE_MAX), and thus is not suitable for a constexpr. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: Using _POSIX_SEM_VALUE_MAX not _SC_SEM_VALUE_MAX?
On Sat, 2023-07-08 at 17:30 +0200, Andreas Schwab wrote: > That needs to be sysconf (_SC_SEM_VALUE_MAX), and thus is not > suitable for a constexpr. Oh right, obviously. Well, I guess I'll have to try to figure out why it's not defined. Sigh.
gcc-13-20230708 is now available
Snapshot gcc-13-20230708 is now available on https://gcc.gnu.org/pub/gcc/snapshots/13-20230708/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 13 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-13 revision d00a7d22c68aae583fa37236d894a220028dd0c8 You'll find: gcc-13-20230708.tar.xz Complete GCC SHA256=9d67b1ad45d3b6be81da7c7427ab58b7d107105a8cfd9ba5ff7ca9c323ac06e5 SHA1=d1fb0e80b49d7ff0c417d139e878b06c03060741 Diffs from 13-20230701 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-13 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Using _POSIX_SEM_VALUE_MAX not _SC_SEM_VALUE_MAX?
On Sat, 2023-07-08 at 12:33 -0400, Paul Smith wrote: > On Sat, 2023-07-08 at 17:30 +0200, Andreas Schwab wrote: > > That needs to be sysconf (_SC_SEM_VALUE_MAX), and thus is not > > suitable for a constexpr. > > Oh right, obviously. > > Well, I guess I'll have to try to figure out why it's not defined. > Sigh. I figured it out. I'm sure it's such a weird problem no one else will hit it but just in case: In order to use clangd without errors I need to use the clangd intrinsics: clang can't parse the GCC intrinsics correctly. The clang limits.h uses #include_next which happens to find GCC's include-fixed/limits.h and includes it in such a way that it doesn't try to include the full system limits.h, so I only have the basics and not all the POSIX extensions etc. If I convince clangd to ignore BOTH the GCC intrinsics directory AND the GCC include-fixed directory, then everything works as expected.
