Re: Updated Sourceware infrastructure plans
On Thu, 18 Apr 2024 at 07:06, Thomas Koenig via Gcc wrote: > > Am 18.04.24 um 01:27 schrieb Mark Wielaard: > > We also should make sure that all generated files (either in git or in > > the release/snapshot tar balls) can be reliably and reproducibly > > regenerated. This also helps the (pre-commit) CI buildbots. We already > > have the autoregen bots for gcc and binutils-gdb. And Christoph has > > been working on extending the scripts to regenerate more kinds of > > files. > > 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've been curious for ages why gfortran requires using maintainer mode for that. Nobody else uses maintainer mode for GCC development, so it causes friction when somebody has to do changes across the whole of gcc including gfortran parts. If it doesn't work with a simple autoreconf then that should be fixed.
Re: Deprecation/removal of nios2 target support
On 4/18/24 13:41, Arnd Bergmann wrote: On Thu, Apr 18, 2024, at 17:44, Joseph Myers wrote: On Wed, 17 Apr 2024, Sandra Loosemore wrote: Therefore I'd like to mark Nios II as obsolete in GCC 14 now, and remove support from all toolchain components after the release is made. I'm not sure there is an established process for obsoleting/removing support in other components; besides binutils, GDB, and GLIBC, there's QEMU, newlib/libgloss, and the Linux kernel. But, we need to get the ball rolling somewhere. CC:ing Arnd Bergmann regarding the obsolescence in the Linux kernel. We have not yet marked nios2 as deprecated in the kernel, but that is mostly because the implementation does not get in the way too much and Dinh Nguyen is still around as a maintainer and merging bugfixes. Almost all nios2 kernel changes I see in the past decade have been done blindly without testing on hardware, either for treewide changes, or by code inspection. The only notable exceptions I could find are from Andreas Oetken and Bernd Weiberg at Siemens and from Marek Vasut (all added to Cc in case they have something to add). We should probably remove nios2 from the kernel in the near future, but even if we decide not to, I think deprecating it from gcc is the right idea: If there are a few remaining users that still plan to update their kernels, gcc-14 will still be able to build new kernels for several years. I'm planning to do this soon. Dinh
Re: adacore git-hooks - daemon-mode email vs. systemd-logind linger
Hi Frank, > - just send the emails immediately, without the daemon stuff; if the > delays are there to try to sequentialize them, consider instead > getting the hooks to emit Message-Id:/In-Reply-To:/Date: headers to > let MUA's sort properly at reception We can certainly add a non-daemon mode to the hooks. I don't know when I'd have time to work on this enhancement, unfortunately. > - invoke the email sending wrapped in a "systemd-run --user" > deferred execution gadget, including a "sleep XXX" if you must > keep time-hope-based sequencing > > - move email stuff entirely out of the hooks; these repos are "public > property" anyhow, and we can put cron jobs in place elsewhere to > trigger email notifications about commits; heck, they could run the > hook code itself later, just feed it retrospective git-hook lines You can configure the hooks to turn emailing off completely. From memory, this triggers a warning message on the user end when they do the push, just to let them know to not expect emails. The downside of going this way, other than the minor annoyance above, is that you lose track of who did the push. Right now, the emails allows you to derive the information from the emails' from field. Thinking more long term, I think there are talks about using a more comprehensive system for source and contribution management, similar to products such as GitLab or GitHub. Those will likely come with they own set of tooling for things such as alerting, pre-commit checks, keeping track of who submitted, who reviewed and approved, and who pushed. That's why I tend to think that, for the moment, I'd go the simplest route overall: In this case, I think the simplest is to just have a way to disable the daemon mode, and just have the users wait. In the vast majority of cases, the wait will be a few seconds. Even with a patch-series of a 100 patches, it would mean a 1min40s wait. Very bearable. If you agree, we can create an issue for it on the git-hooks repoisitory on GitHub. -- Joel
Re: adacore git-hooks - daemon-mode email vs. systemd-logind linger
Hi, Joel - > [...] Thinking more long term, I think there are talks about using > a more comprehensive system for source and contribution management, > similar to products such as GitLab or GitHub. [...] (Yeah, but I wouldn't count on any of that in the medium term.) > [...] That's why I tend to think that, for the moment, > I'd go the simplest route overall: In this case, I think the simplest > is to just have a way to disable the daemon mode, and just have > the users wait. In the vast majority of cases, the wait will be > a few seconds. Even with a patch-series of a 100 patches, it would > mean a 1min40s wait. Very bearable. Right. the EMAIL_DELAY_IN_SECONDS time of 5s could be reduced to 1s, or even 0. - FChE
Why one form have no warning the other forms have warning when using -Wformat=2
Hi,
While testing with -Wformat=2, I encountered the following behaviour:
Please see the attached simple C file (tested on gcc 11.2.0/gcc
13.2.1), both give the same warning (clang (17.0.6/gives no warning,
although I am not really sure they have the same effect with the
flags).
It gives the following error when compiling with "gcc -c -Wformat=2 fmt-test.c"
fmt-test.c:9:9: warning: format not a string literal, argument types
not checked [-Wformat-nonliteral]
The strange thing is that, when the fmt_str is defined as "const char
fmt_str[]", no warning is given, while defined it as "const char
*fmt_str" or "const char *const fmt_str", warning is given.
Most of the time, I would prefer fmt_str to be "const char *" or
"const char *const" to ensure it is not mutable. From my view, the
compiler should either give no warning (I would prefer this) or give
warning for all cases.
--
Qun-Ying
#include
int main(int argc, char *argv[])
{
// const char str_fmt[] = "hello world: %d\n"; /* OK */
// const char *str_fmt = "hello world: %d\n"; /* Warning */
const char * const str_fmt = "hello world: %d\n"; /* Warning */
printf(str_fmt, 1);
return 0;
}
gcc-12-20240419 is now available
Snapshot gcc-12-20240419 is now available on https://gcc.gnu.org/pub/gcc/snapshots/12-20240419/ and on various mirrors, see https://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 12 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-12 revision f04f8734f792159d8bc001946fe4ca6f3503034f You'll find: gcc-12-20240419.tar.xz Complete GCC SHA256=6d9c2cfb0f6b4e9b5ba97115d7951d387e32f508e4de8ee1c9fffb4a7f3d718a SHA1=072c9cc4cd581da12b913499e970f93936437e2e Diffs from 12-20240412 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-12 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.
