gcc-15-20250621 is now available
Snapshot gcc-15-20250621 is now available on https://gcc.gnu.org/pub/gcc/snapshots/15-20250621/ and on various mirrors, see https://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 15 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-15 revision 2c24509f90a0c1c12ba21ecbcd5636e81283d56f You'll find: gcc-15-20250621.tar.xz Complete GCC SHA256=8daf3f4b943b34db7cee04bb36aafb5a75a1b531f00748699255e2f234f3116c SHA1=9a7a8e65c9c908513e64aba29bb5f87e2458b2ee Diffs from 15-20250614 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-15 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: fixincludes comes up empty
> Am 21.06.2025 um 08:45 schrieb James K. Lowden :
>
> I guess I'm doing something wrong, or not enough. "make install" is
> failing after a bootstrap build because the build/fixincludes directory
> is empty. Edited for brevity:
>
> $ make -C build-boot/ V=1 install
> make: Entering directory '.../build-boot'
> make[1]: Entering directory '.../build-boot'
> /bin/bash ../mkinstalldirs /usr/local/gcc-cobol /usr/local/gcc-cobol
> make[2]: Entering directory '.../build-boot/fixincludes'
> make[2]: *** No rule to make target 'install'. Stop.
> make[2]: Leaving directory '.../build-boot/fixincludes'
> make[1]: *** [Makefile:4193: install-fixincludes] Error 2
> make[1]: Leaving directory '.../build-boot'
> make: *** [Makefile:2710: install] Error 2
> make: Leaving directory '.../build-boot'
>
> $ for D in build*/fixincludes
> do
>printf "$D: %d files\n" $(ls $D | wc -l)
> done
> build-02/fixincludes: 18 files
> build-boot/fixincludes: 0 files
> build/fixincludes: 18 files
>
> Until recently I always used --disable-bootstrap because faster.
> Lately because of the discomfort of my own petard I have added
> --enable-bootstrap to my repertoire. The build succeeds, but leaves
> the fixincludes directory empty, which means "make install" fails. I
> thought the issue was confined to building on macOS, but today discover
> it's true (as above) on Ubuntu x86_64.
>
> The configure invocation is nothing special:
>
> $ head build-boot/config.log | grep /configure
> $ ../configure --prefix=/usr/local/gcc-cobol
> --disable-generated-files-in-srcdir --disable-multilib
> --enable-checking --enable-languages=c,cobol
>
> These are branches based on master, updated as of yesterday. (I have
> other examples without --disable-generated-files-in-srcdir.)
>
> A comparison of the mentions of "fixinclude" in config.{status,log} of
> two directories, bootstrap and non-bootstrap, shows no difference.
>
> What should I be looking for?
For why fixinclude isn’t built - the config.log therein might show something.
Alternatively you can configure with —disable-fixincludes IiRC
Richard
>
> --jkl
>
Re: RFD: switch/case statement dispatch using hash
Hi Joern, I've also been thinking about implementing something like that. First I would experiment with implementing switches using perfect hashing functions to see if this really speeds up execution on current CPUs. Then I would try to come up with some heuristic that tells GCC when it is advantageous to do this. Cost modeling sounds good but maybe one could start with a prototype that uses simpler heuristics. I'm still relatively a newcomer though, so this would take me some non-trivial amount of time and I sadly already have a rather big project on my plate. But I'm certainly up to try this in the future! I'm planning to attend the upcoming Cauldron so maybe we'll chat about this there. Cheers, Filip Kastl On Sun 2025-05-25 04:57:15, Joern Wolfgang Rennecke wrote: > This has come up several time over the years: > https://gcc.gnu.org/legacy-ml/gcc/2006-07/msg00158.html > https://gcc.gnu.org/legacy-ml/gcc/2006-07/msg00155.html > https://gcc.gnu.org/pipermail/gcc/2010-March/190234.html > > , but maybe now (or maybe a while ago) is the right time to do this, > considering the changes in relative costs of basic operations? > Multiply and barrel shift are cheap on many modern microarchitectures. > Control flow and non-linear memory access is expensive. > > FWIW, [Dietz92] > https://docs.lib.purdue.edu/cgi/viewcontent.cgi?article=1312&context=ecetr > mentions multiply in passing as unpractical for SPARC because of cost, but > modern CPUs can often do a multiply in a single cycle. > > Approximating division and scaling, for a case value x, we can calculate an > index or offset into a table as > f(x) = x*C1 >> C2 & M > > For an index, M masks off the upper bits so that the index fits into > a table that has a number of elements that is a power of two. > For architectures where a non-scaled index in cheaper to use than > a scaled one, we compute an offset by having M also mask off the lower > bits. > > Each table entry contains a jump address (or offset) and a key - at least if > both are the same size; for different sizes, it might be cheaper to have two > tables. > If we have found values for C1 and C2 that give a perfect hash, we can > immediately dispatch to the default case for a non-match; otherwise, we can > have decision trees at the jump destinations, each using the comparison with > the key from the table for the first decision. > No separate range check is necessary, so if the multiply is fast enough, > this should be close in performance to an ordinary tablejump. > > This dispatch method can be used for tables that are too sparse for a > tablejump,but have enough cases to justify the overhead (depending on > multiple conditional vs single indirect branch costs, the latter might be a > low bar). > > I suppose we could make tree-switch-conversion.cc use rtx costs to compare > the hash implementation to a decision tree, or have a hook make the decision > - and the default for the hook might use rtx costs...
Re: fixincludes comes up empty
> On 21 Jun 2025, at 12:03, Richard Biener via Gcc wrote:
>
>
>
>> Am 21.06.2025 um 08:45 schrieb James K. Lowden :
>>
>> I guess I'm doing something wrong, or not enough. "make install" is
>> failing after a bootstrap build because the build/fixincludes directory
>> is empty. Edited for brevity:
>>
>> $ make -C build-boot/ V=1 install
>> make: Entering directory '.../build-boot'
>> make[1]: Entering directory '.../build-boot'
>> /bin/bash ../mkinstalldirs /usr/local/gcc-cobol /usr/local/gcc-cobol
>> make[2]: Entering directory '.../build-boot/fixincludes'
>> make[2]: *** No rule to make target 'install'. Stop.
>> make[2]: Leaving directory '.../build-boot/fixincludes'
>> make[1]: *** [Makefile:4193: install-fixincludes] Error 2
>> make[1]: Leaving directory '.../build-boot'
>> make: *** [Makefile:2710: install] Error 2
>> make: Leaving directory '.../build-boot'
>>
>> $ for D in build*/fixincludes
>> do
>> printf "$D: %d files\n" $(ls $D | wc -l)
>> done
>> build-02/fixincludes: 18 files
>> build-boot/fixincludes: 0 files
>> build/fixincludes: 18 files
>>
>> Until recently I always used --disable-bootstrap because faster.
>> Lately because of the discomfort of my own petard I have added
>> --enable-bootstrap to my repertoire. The build succeeds, but leaves
>> the fixincludes directory empty, which means "make install" fails. I
>> thought the issue was confined to building on macOS, but today discover
>> it's true (as above) on Ubuntu x86_64.
>>
>> The configure invocation is nothing special:
>>
>> $ head build-boot/config.log | grep /configure
>> $ ../configure --prefix=/usr/local/gcc-cobol
>> --disable-generated-files-in-srcdir --disable-multilib
>> --enable-checking --enable-languages=c,cobol
>>
>> These are branches based on master, updated as of yesterday. (I have
>> other examples without --disable-generated-files-in-srcdir.)
>>
>> A comparison of the mentions of "fixinclude" in config.{status,log} of
>> two directories, bootstrap and non-bootstrap, shows no difference.
>>
>> What should I be looking for?
>
> For why fixinclude isn’t built - the config.log therein might show something.
> Alternatively you can configure with —disable-fixincludes IiRC
However, although disabling fixincludes would perhaps allow install to
complere, and might work, for some platforms, for some range of source code, it
will amost certainly not work for Darwin - where we need to intercept some
quite common includes.
Finding the problem would be a good plan - this generally works - and so there
should be an adequate explanation.
Iain
>
> Richard
>
>>
>> --jkl
