gcc(-14) snapshot releases?

[oscarbg]

Hi, gcc-14 is around the corner.. may release some snapshot release like Winlibs does: https://github.com/brechtsanders/winlibs_mingw/releases/tag/14.0.0-snapshot20240107posix-11.0.1-msvcrt-r1 mainly for making some testing before general release..

[skeeto]

I'm not interested in providing GCC snapshot builds, but as a branch for testers to self-build, it could be useful for discovering upcoming issues sooner. After all, it's trivial to build w64devkit from source, so willing testers do not need me to do it! As far as I can tell, WinLibs does not publish build scripts, and the only person who can build test releases is Brecht Sanders. So that project must be tested through snapshot builds.

For my own philosophy: There's no urgency. So what if it takes an extra couple weeks to make a w64devkit after a GCC release? Developers are, in general, too enamored with shiny novelties — exciting new language and compiler features — when they should instead focus on making things work well using the tools they've already got. New toys are fun, but rarely affect the stuff that matters.

[Peter0x44]

I tried to build gcc 14 myself but couldn't, I was faced with errors like the following:

In file included from ../../../../gcc/libgcc/config/i386/cpuinfo.c:30:
../../../../gcc/libgcc/../gcc/common/config/i386/cpuinfo.h: In function 
'get_available_features':
../../../../gcc/libgcc/../gcc/common/config/i386/cpuinfo.h:938:21: error: 
'bit_USER_MSR' undeclared (first use in this function)
  938 | if (edx & bit_USER_MSR)
      | ^~~~~~~~~~~~
../../../../gcc/libgcc/../gcc/common/config/i386/cpuinfo.h:938:21: note: 
each undeclared identifier is reported only once for each function it 
appears in
../../../../gcc/libgcc/../gcc/common/config/i386/cpuinfo.h:950:25: error: 
'bit_AVXVNNIINT16' undeclared (first use in this function); did you mean 
'bit_AVXVNNIINT8'?
  950 | if (edx & bit_AVXVNNIINT16)
      | ^~~~~~~~~~~~~~~~
      | bit_AVXVNNIINT8

This is not in the context of w64devkit, but I assume it would be affectted too. I'm guessing it's a bug of some sort, because gcc 13.2 built fine with an identical configure command...

[Peter0x44]

In case anyone was wondering, I sorted this out. It's probably NOT a gcc bug, it was because I was trying to cross-compile gcc 14 with gcc 13.2, which doesn't have those constants for the new intel instructions. I got past that specific error by pointing to the headers manually and invoking the command the makefile would, but I was met later with an error when libstdc++ used -std=gnu++26 which gcc 13.2 doesn't recognize.

So, lesson learned. If you are cross compiling gcc, do it with a gcc version >= the version you want to run on the target. Anything else is probably not supported.

[skeeto]

If you are cross compiling gcc, do it with a gcc version >= the version you want to run on the target.

That's basically my experience, too. My initial attempt at w64devkit (not in the commit history), adapting it from my old, ad-hoc scripts, I tried to use Debian's Mingw-w64 cross-compiler rather than bootstrap one from the native compiler, but I couldn't get it working reliably.

[skeeto]

If anyone's interested in trying it out, I just pushed gcc-14-snapshot. Unfortunately it fails on a missing gengtype-lex.cc, which I guess was supposed to have been generated from gengtype-lex.l.

[oscarbg]

@skeeto thanks! waiting for binaries in case you sort the lex issue..

[skeeto]

@oscarbg, I merely needed to install flex, which I've pushed in another commit. I suspect it's only necessary for these snapshot builds. It seems to be working fine so far.

I'm still not planning to supply snapshot binaries, but if you have Docker then you can build your own from that branch.

[skeeto]

@N-R-K, something you might find interesting: GCC 14 adds a new warning to the alloc_size attribute, -Wcalloc-transposed-args, which is now assumed to have calloc semantics, i.e. (nmemb, size). So we get a warning passing a sizeof as the argument indicated by the first alloc_size parameter. In other words, GCC 14 thinks we should write it alloc_size(3, 2) instead of alloc_size(2, 3) despite the attribute documentation suggesting it's commutative.

(I'm rather annoyed by this.)

[N-R-K]

despite the attribute documentation suggesting it's commutative

I was sort of aware of this because I saw people sending completely useless patches swapping calloc arguments around because gcc was causing warnings. There was a gcc bug reported about this but I wasn't able to find it now.

[N-R-K]

There was a gcc bug reported about this

Found it https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112364. Disappointingly, they chose to "fix" the issue by swapping calloc args in gcc's source instead of fixing the bogus warning.

[Peter0x44]

@skeeto flex is documented to be required for development/snapshot builds here: https://gcc.gnu.org/install/prerequisites.html

Necessary to build GCC during development because the generated output files are not included in the version-controlled source repository. They are included in releases.

So, your idea was correct.

[Peter0x44]

Now that gcc 14 is released, I guess this can be closed. Shouldn't be any need to use snapshots.

[skeeto]

Thanks to dogfooding the snapshot over the last few weeks, I was confident in pushing out a new w64devkit release (1.23.0) just a day after GCC 14.1, so this experiment has worked out quite well.