Re: "extern inline" inlining heuristics in unlikely branches
On Wed, Jul 31, 2024 at 8:12 PM Ilija Tovilo via Gcc wrote: > > Hi everyone > > I'm new here. I read the mailing list policy, but please correct me if > I'm doing anything wrong. > > In our C codebase, we're using a fair amount of static inline > __attribute__((always_inline)). This is arguably not a great decision, > because it forces inlining under questionable conditions, i.e. in cold > functions and unlikely branches. We're looking into switching some > non-trivial functions to extern inline instead. > > When testing I noticed that GCC avoids inlining in > __attribute__((cold)) functions, but not in unlikely branches, as > signaled by __builtin_expect(cond, 0), even if the caller is hot. See > https://godbolt.org/z/sxnYh5PsE. The unlikely branch is moved to the > bottom, but it still seems beneficial to avoid inlining to reduce > instruction cache pressure for the rest of the hot functions. I wasn't > able to achieve this behavior with __builtin_expect or > __builtin_expect_with_probability with a very high probability. > > Coincidentally, Clang does the exact opposite, inlining in cold > functions, but not in unlikely branches. > > This is just one example, and I don't know anything about the > heuristics GCC uses to determine if some function is inlined. I wanted > to bring this up nonetheless to see if this situation may be improved. > > I wasn't sure if this belongs in the bug tracker, let me know if I > should move it there instead. Please file a bugreport with a testcase, the outcome and your expectation. Thanks, Richard. > Thank you. > > Ilija
GCC 14.2 Released
The GNU Compiler Collection version 14.2 has been released. GCC 14.2 is a bug-fix release from the GCC 14 branch containing important fixes for regressions and serious bugs in GCC 14.1 with more than 102 bugs fixed since the previous release. This release is available from the FTP servers listed here: https://sourceware.org/pub/gcc/releases/gcc-14.2.0/ https://gcc.gnu.org/mirrors.html Please do not contact me directly regarding questions or comments about this release. Instead, use the resources available from http://gcc.gnu.org. As always, a vast number of people contributed to this GCC release -- far too many to thank them individually!
Re: How to add an additional option to dg-compile and dg-run
Am 29.07.24 um 22:14 schrieb Thomas Schwinge: By the way: I did see your recent announcement; wow -- Fortran finally getting an UNSIGNED type! 🙂 Yep, at lest J3 accepted a propoasl. I would like to be able to run all existing Fortran tests also with -funsigned, to make sure the option does not break anything on existing code. Question is: How? I came as far as $ make check-fortran RUNTESTFLAGS="--target_board=unix/-funsigned" but that causes testsuite failures because C does not recognize the option. Any other possibilites? Hard-code it to enabled in 'gcc/fortran/lang.opt'... 😉 For later, I think. Or: '-Wno-complain-wrong-lang' ought to help your case: That works (and has already turned up some issues). Thanks! Thomas
RISC-V Pioneer Box for builder.sourceware.org gcc CI
Hi, Thanks to RISC-V International and SOPHGO we got a Milk-V Pioneer Box [*] for builder.sourceware.org that we can use for gcc CI. It is running Fedora 38 with gdb 15.1, binutils 2.42 and gcc 14.1 installed on top. We could create containers with other setups if useful. https://builder.sourceware.org/buildbot/#/builders/gcc-full-fedora-riscv Even though it has 64 cores, single core performance isn't very fast, so a gcc build and check takes ~10 hours. This is mostly because the gcc build has a lot of parallelism bottlenecks so those 64 cores are mostly idle during the build. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84402 Specifically one file takes ~6 hours to build, most of which isn't done in parallel with anything else. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116166 make check -j64 is very parallel though. It takes only 1.5 hours with all cores being busy most of the time. Test results are recorded in bunsen: https://builder.sourceware.org/testruns/?has_keyvalue_k=testrun.git_describe&has_keyvalue_op=glob&has_keyvalue_v=*gcc-full-fedora-riscv* PASS=572148 UNSUPPORTED=19063 XFAIL=4528 FAIL=584 XPASS=28 UNRESOLVED=15 WARNING=1 As can be seen in the attached test summary report most failures are in gcc.target/riscv/rvv/rvv.exp I assume that is because the SG2042 implements rvv 0.7.1 and not rvv 1.0. Is there a better way to configure gcc for that? Or maybe configure without rvv support at all? Configuration in in the builder repo, patches welcome: https://sourceware.org/cgit/builder/tree/builder/master.cfg#n4070 Cheers, Mark [*] https://riscv.org/blog/2023/06/sophgo-donates-50-risc-v-motherboards-learn-more-about-the-pioneer-box/Native configuration is riscv64-unknown-linux-gnu === gcc tests === Running target unix FAIL: c-c++-common/spec-barrier-1.c -Wc++-compat (test for excess errors) FAIL: gcc.dg/Wstringop-overflow-47.c pr97027 (test for warnings, line 72) FAIL: gcc.dg/Wstringop-overflow-47.c pr97027 (test for warnings, line 77) FAIL: gcc.dg/Wstringop-overflow-47.c pr97027 note (test for warnings, line 68) XPASS: gcc.dg/attr-alloc_size-11.c missing range info for short (test for warnings, line 51) XPASS: gcc.dg/attr-alloc_size-11.c missing range info for signed char (test for warnings, line 50) FAIL: gcc.dg/pr100927.c scan-rtl-dump-times final "(?n)^[ t]*(fix:SI" 3 XPASS: gcc.dg/guality/example.c -O0 execution test XPASS: gcc.dg/guality/example.c -O1 -DPREVENT_OPTIMIZATION execution test XPASS: gcc.dg/guality/example.c -Og -DPREVENT_OPTIMIZATION execution test XPASS: gcc.dg/guality/guality.c -O0 execution test XPASS: gcc.dg/guality/guality.c -O1 -DPREVENT_OPTIMIZATION execution test XPASS: gcc.dg/guality/guality.c -O2 -DPREVENT_OPTIMIZATION execution test XPASS: gcc.dg/guality/guality.c -O2 -flto -fno-use-linker-plugin -flto-partition=none -DPREVENT_OPTIMIZATION execution test XPASS: gcc.dg/guality/guality.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects -DPREVENT_OPTIMIZATION execution test XPASS: gcc.dg/guality/guality.c -O3 -g -DPREVENT_OPTIMIZATION execution test XPASS: gcc.dg/guality/guality.c -Os -DPREVENT_OPTIMIZATION execution test XPASS: gcc.dg/guality/guality.c -Og -DPREVENT_OPTIMIZATION execution test XPASS: gcc.dg/guality/inline-params.c -O2 -DPREVENT_OPTIMIZATION execution test XPASS: gcc.dg/guality/inline-params.c -O2 -flto -fno-use-linker-plugin -flto-partition=none -DPREVENT_OPTIMIZATION execution test XPASS: gcc.dg/guality/inline-params.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects -DPREVENT_OPTIMIZATION execution test XPASS: gcc.dg/guality/inline-params.c -O3 -g -DPREVENT_OPTIMIZATION execution test XPASS: gcc.dg/guality/inline-params.c -Os -DPREVENT_OPTIMIZATION execution test FAIL: gcc.dg/guality/loop-1.c -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions -DPREVENT_OPTIMIZATION line 20 i == 1 XPASS: gcc.dg/guality/pr41353-1.c -O1 -DPREVENT_OPTIMIZATION line 28 j == 28 + 37 XPASS: gcc.dg/guality/pr41353-1.c -O2 -DPREVENT_OPTIMIZATION line 28 j == 28 + 37 XPASS: gcc.dg/guality/pr41353-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none -DPREVENT_OPTIMIZATION line 28 j == 28 + 37 XPASS: gcc.dg/guality/pr41353-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects -DPREVENT_OPTIMIZATION line 28 j == 28 + 37 XPASS: gcc.dg/guality/pr41353-1.c -O3 -g -DPREVENT_OPTIMIZATION line 28 j == 28 + 37 XPASS: gcc.dg/guality/pr41353-1.c -Os -DPREVENT_OPTIMIZATION line 28 j == 28 + 37 FAIL: gcc.dg/guality/pr41353-1.c -Og -DPREVENT_OPTIMIZATION line 28 i1 == 2 * 37 FAIL: gcc.dg/guality/pr41353-1.c -Og -DPREVENT_OPTIMIZATION line 28 i2 == 3 * 37 XPASS: gcc.dg/guality/pr41353-1.c -Og -DPREVENT_OPTIMIZATION line 28 j == 28 + 37 FAIL: gcc.dg/guality/pr41616-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects -DPREVENT_OPTIMIZATION execution test FAIL: gcc.dg/guality/pr54200.c -O1 -DPREVENT_
gcc-12-20240801 is now available
Snapshot gcc-12-20240801 is now available on https://gcc.gnu.org/pub/gcc/snapshots/12-20240801/ 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 b0137fe4af2f997d1567c5131c597fa13a2625f5 You'll find: gcc-12-20240801.tar.xz Complete GCC SHA256=f272b525ea14d9791f0d356ce1955f72e2e10d33cbb1753b02812498f570e565 SHA1=8c5ffe3cfa91f17410f6744184c64fa08d63feff Diffs from 12-20240725 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.
RFC: Changing Bugzilla updates at release time
Hi! This came out of some discussion with Arsen and prompted by some other comments on IRC. At the moment, during release time, maintainer-scripts/branch_changer.py is run by release managers and causes a large amount of bugmail to be sent both to CCs/assignees but also to the gcc-bugs ML. The activity comes from the RM's personal account. In the past, I've missed real activity on bugs (including a question to me) as well as some other email drowned out in the notification emails. What do people think about possibly having a special 'GCC releases' account which only the RMs have an API key to, possibly suppresses sending email to begin with, and is ignored by gcc-bugs? It would allow easier filtering out of the mail. (I'm familiar enough with BZ to say it should be trivially doable, with the exception of suppressing *sending* the mail to begin with, which I'd have to investigate.) thanks, sam signature.asc Description: PGP signature
Remove my email from your email list
Hello, Can you remove my email(jojomanz...@gmail.com) from your mailing list? I no longer need the announcement emails when a new GCC comes out -- *Faiz*
