Using __builtin_unwind_init in glibc

I would like to use __builtin_unwind_init in glibc in a few places, to preserve additional evidence for a debugger. It's currently not a documented built-in function. Would that still be okay. (Most architectures will have probably benefit from a custom register-preserving assembler trampoline,

Concerns regarding the -ffp-contract=fast default

While rebuilding CentOS Stream with -march=x86-64-v3, I rediscovered several packages had test suite failures because x86-64 suddenly gained FMA support. I say “rediscovered” because these issues were already visible on other architectures with FMA. So far, our package/architecture maintainers ha

Re: Concerns regarding the -ffp-contract=fast default

* Richard Biener: >> > > GCC contraction behavior is rather inconsistent. It does not contract x >> > > + x - x without -ffast-math, for example, although I believe it would be >> > > permissible under the rules that enable FMA contraction. This whole > > Is that really just x + x - x? We curre

Re: Concerns regarding the -ffp-contract=fast default

* Alexander Monakov: > On Mon, 18 Sep 2023, Florian Weimer via Gcc wrote: > >> x - x is different because replacing it with 0 doesn't seem to be a >> valid contraction because it's incorrect for NaNs. x + x - x seems to >> be different in this regard, but in ou

Re: Concerns regarding the -ffp-contract=fast default

* Richard Biener: >> How much numerical code is compatible with that? For example, David >> Goldberg's What Every Computer Scientist Should Know About >> Floating-Point Arithmetic (revised) contains this sentence: >> >> | A language definition that does not require parentheses to be honored >> |

Re: Concerns regarding the -ffp-contract=fast default

* Alexander Monakov: >> > Contracting 'x + x - x' to fma(x, 2, -x) would be fine. >> >> It still changes the result, doesn't it? > > I don't follow. I doesn't change the result for infinities (produces > a NaN). It changes the result when x is so large that 'x + x' is > not representable (exponen

Report from the additional type errors for GCC 14 BoF at Cauldron

My understanding of the consensus goes as follows: * We want to make some changes in this area for GCC 14. * We should do the same thing that Clang does: default to the relevant -Werror= options. * Unlike regular warnings, these warnings-as-errors should also apply to system headers. * At leas

Re: Report from the additional type errors for GCC 14 BoF at Cauldron

* Jakub Jelinek: > On Tue, Sep 26, 2023 at 10:28:34AM +0200, Florian Weimer via Gcc wrote: >> My understanding of the consensus goes as follows: >> >> * We want to make some changes in this area for GCC 14. >> * We should do the same thing that Clang does: default t

Re: Report from the additional type errors for GCC 14 BoF at Cauldron

* Jeff Law: >> I think the open issues are: >> * Do we want to implement something else beside implicit-int and >>implicit-function-declaration? (Candidates are int-conversion and >>incompatible-pointer-types, and the void vs non-void part of >>return-type, maybe others as previously

Re: Report from the additional type errors for GCC 14 BoF at Cauldron

* Arsen Arsenović via Gcc: > Sam James via Gcc writes: > >> Florian Weimer via Gcc writes: >> >>> My understanding of the consensus goes as follows: >>> >>> * We want to make some changes in this area for GCC 14. >>> * We should do t

Re: Question about merging if-else blocks

* Richard Biener: >> By disassembling the exe file generated by icc, I found that icc will >> merge these two blocks with the example code below. So I think there >> maybe some ways to make it. > > ... glibc for example allows user-provided printf format callbacks so > printf might call back into

-Wint-conversion as errors seems doable for GCC 14

I completed a Fedora rawhide rebuild with an instrumented GCC (~14,500 packages). 156 packages failed to build with a logged -Wint-conversion error. This number is much lower than what I expected, and I think we should include -Wint-conversion in the GCC 14 changes. My instrumentation isn't very

Documenting common C/C++ options

Currently, -fsigned-char and -funsigned-char are only documented as C language options, although they work for C++ as well (and Objective-C and Objective-C++, I assume, but I have not tested this). There does not seem to be a place for this kind of options in the manual. The options -fshort-enums

Re: Documenting common C/C++ options

* Richard Earnshaw: > On 10/10/2023 11:46, Richard Earnshaw (lists) via Gcc wrote: >> On 10/10/2023 10:47, Florian Weimer via Gcc wrote: >>> Currently, -fsigned-char and -funsigned-char are only documented as C >>> language options, although they work for C++ as we

C89 question: Do we need to accept -Wint-conversion warnings

Are these code fragments valid C89 code? int i1 = 1; char *p1 = i; char c; char *p2 = &c; int i2 = p2; Or can we generate errors for them even with -std=gnu89? (It will still be possible to override this with -fpermissive or -Wno-int-conversion.) Thanks, Florian

Re: C89 question: Do we need to accept -Wint-conversion warnings

* Jakub Jelinek: > On Tue, Oct 10, 2023 at 12:30:52PM -0400, Jason Merrill via Gcc wrote: >> On Tue, Oct 10, 2023 at 7:30 AM Florian Weimer via Gcc >> wrote: >> >> > Are these code fragments valid C89 code? >> > >> > int i1 = 1; >> >

Re: C89 question: Do we need to accept -Wint-conversion warnings

* Joseph Myers: > On Tue, 10 Oct 2023, Florian Weimer via Gcc wrote: > >> Are these code fragments valid C89 code? >> >> int i1 = 1; >> char *p1 = i; >> >> char c; >> char *p2 = &c; >> int i2 = p2; > > Implicit conversio

Re: Documenting common C/C++ options

* Jason Merrill: >> But that wasn't really the direction of my question. I was wondering >> where we should document a future C version of -fpermissive. > > My permerror patch proposes moving it to the Warning Options node, > right after -pedantic-errors. Yes, that should work. I'm basing my pa

Re: C89 question: Do we need to accept -Wint-conversion warnings

* David Brown: > So IMHO (and as I am not a code contributor to GCC, my opinion really > is humble) it is better to be stricter than permissive, even in old > standards. It is particularly important for "-std=c89", while > "-std=gnu89" is naturally more permissive. (I have seen more than > enoug

Re: Function multiversioning ABI issues

* Andrew Carlotti via Gcc: > I've also seen the GCC documentation for the ifunc attribute [1]. > This states that "the indirect function needs to be defined in the > same translation unit as the resolver function". This is not how > function multiversioning is currently implemented. Instead, the

Re: C89 question: Do we need to accept -Wint-conversion warnings

* David Brown: > On 11/10/2023 10:10, Florian Weimer wrote: >> * David Brown: >> >>> So IMHO (and as I am not a code contributor to GCC, my opinion really >>> is humble) it is better to be stricter than permissive, even in old >>> standards. It is pa

Re: C89 question: Do we need to accept -Wint-conversion warnings

* David Brown: >> C23 changes meaning of of extern foo(); to match the C++ >> interpretation of extern foo(void);. I don't think we should warn >> about that. If we warn, it would be at the call site. > > I'm not sure I fully agree. "extern foo();" became invalid when > implicit int was removed

Emacs ChangeLog generation and commit messages

Emacs has a very useful facility. You press “C-x 4 a” in a place where you make changes, and the editor automatically opens the right ChangeLog file and adds a draft entry to it, like this: 2023-11-06 Florian Weimer * c-opts.cc (c_common_post_options): █ Is there something like this

Update on GCC 14 C type safety changes/warnings as errors

The patch series is currently under review: [PATCH v3 00/11] : More warnings as errors by default Jeff as a global reviewer has delegated review to Marek. The current series is based on an earlier suggestion

libgcov, fork, and mingw (and other targets without the full POSIX set)

I've received a report of a mingw build failure: ../../../gcc/libgcc/libgcov-interface.c: In function '__gcov_fork': ../../../gcc/libgcc/libgcov-interface.c:185:9: error: implicit declaration of function 'fork' [-Wimplicit-function-declaration] 185 | pid = fork (); | ^~~~ make[2

Re: libgcov, fork, and mingw (and other targets without the full POSIX set)

* Richard Biener: > On Fri, Dec 1, 2023 at 9:04 AM Florian Weimer via Gcc wrote: >> >> I've received a report of a mingw build failure: >> >> ../../../gcc/libgcc/libgcov-interface.c: In function '__gcov_fork': >> ../../../gcc/libgcc/libgcov-inter

Re: libgcov, fork, and mingw (and other targets without the full POSIX set)

* Mark Wielaard: > BTW. The gcc-fedora-mingw buildbot has been broken because of this > issue for the last week: > > https://builder.sourceware.org/buildbot/#/builders/gcc-fedora-mingw > ../../../gcc/libgcc/libgcov-interface.c: In function '__gcov_fork': > ../../../gcc/libgcc/libgcov-interface.c:1

Re: libgcov, fork, and mingw (and other targets without the full POSIX set)

* LIU Hao via Gcc: > 在 2023/12/8 21:59, Florian Weimer via Gcc 写道: >>[PATCH] libgcov: Call __builtin_fork instead of fork >> >> <https://inbox.sourceware.org/gcc-patches/87edg4epw5@oldenburg.str.redhat.com/> > > May I ask why it's not something l

-fcf-protection default on x86-64 (also for -fhardened)

Currently, -fcf-protection defaults to both shadow stack and indirect branch tracking (IBT) on x86_64-linux-gnu, and -fhardened follows that. I think it should only enable shadow stack at this point. I'm not sure if this is a good idea because there will likely be no userspace support for IBT when

Switching x86_64-linux-gnu to GNU2 TLS descriptors by default

I feel like I have asked this before. Currently, GCC uses calls to __tls_get_addr to obtain the address of global-dynamic TLS variables. On other architectures with support for GNU2 TLS descriptors, those are used by default. Should we flip the default to GNU2 descriptors? Support has been avail

Re: Deprecating -fgnu-tm support for GCC 14 and removing it for GCC 15

* Andrew Pinski via Gcc: > -fgnu-tm support has not been improved since GCC 5 or earlier. It is > not even supported with LTO. Does it make sense to deprecate the > support for GCC 14 and remove it in GCC 15? Is this the stuff around libitm and that adds _ITM_registerTMCloneTable and _ITM_deregis

New TLS usage in libgcc_s.so.1, compatibility impact

This commit commit 8abddb187b33480d8827f44ec655f45734a1749d Author: Andrew Burgess Date: Sat Aug 5 14:31:06 2023 +0200 libgcc: support heap-based trampolines Add support for heap-based trampolines on x86_64-linux, aarch64-linux, and x86_64-darwin. Implement the __builtin_neste

Re: New TLS usage in libgcc_s.so.1, compatibility impact

* Carlos O'Donell: > I agree. TLS should be seen more like .bss/.data rather than something > that is allocated with malloc(). There wasn't consensus regarding this in 2014. See below. > If we leak memory via TLS that is a glibc bug that we can deal with, This is something that libgcc_s.so.1 d

Re: New TLS usage in libgcc_s.so.1, compatibility impact

* Iain Sandoe: >> On 15 Jan 2024, at 15:35, Florian Weimer wrote: >> >> * Carlos O'Donell: >> >>> I agree. TLS should be seen more like .bss/.data rather than something >>> that is allocated with malloc(). >> >> There wasn't

Re: [lttng-dev] New TLS usage in libgcc_s.so.1, compatibility impact

* Mathieu Desnoyers: > On 2024-01-13 07:49, Florian Weimer via lttng-dev wrote: >> This commit >> commit 8abddb187b33480d8827f44ec655f45734a1749d >> Author: Andrew Burgess >> Date: Sat Aug 5 14:31:06 2023 +0200 >> libgcc: support heap-based trampolines

Re: Update on GCC 14 C type safety changes/warnings as errors

* Martin Jambor: > Given you probably have the most experience with it, can you please also > suggest an entry to https://gcc.gnu.org/gcc-14/porting_to.html that > would describe this change? (I was thinking of proposing something > myself, but I don't really know just how much verbose such an en

Re: New feature: -fdump-gimple-nodes (once more, with feeling)

* Andi Kleen via Gcc: >> ***This is NodeNumber0 >> (0x7f12e13b0d00) NodeNumber0 >> tree_code: function_decl >> tree_code_class: tcc_declaration > > My suggestion if you go this route would be to generate > some standard format like YAML or JSON that other tools > ca

Re: Builtin for consulting value analysis (better ffs() code gen)

* Andrew Cooper via Gcc: > Anyway - is there a way of doing this that I've managed to overlook? Use __builtin_ffs? I think there's some concern for GCC that some of the alternative x86-64 implementations do not follow the AMD and Intel behavior. Thanks, Florian

Re: Sourceware mitigating and preventing the next xz-backdoor

* Guinevere Larsen via Overseers: > Beyond that, we (GDB) are already experimenting with approved-by, and > I think glibc was doing the same. The glibc project uses Reviewed-by:, but it's completely unrelated to this. Everyone still pushes their own patches, and there are no technical countermea

Re: [RFC] Linux system call builtins

* Matheus Afonso Martins Moreira via Gcc: > + It's stable > > This is one of the things which makes Linux unique > in the operating system landscape: applications > can target the kernel directly. Unlike in virtually > every other operating system out there, the L

Re: [RFC] Linux system call builtins

* Alexander Monakov: > On Mon, 8 Apr 2024, Florian Weimer via Gcc wrote: > >> * Matheus Afonso Martins Moreira via Gcc: >> >> > + It's stable >> > >> > This is one of the things which makes Linux unique >> > in th

Re: Updated Sourceware infrastructure plans

* Jason Merrill: > On Mon, Apr 22, 2024 at 11:42 AM Tom Tromey wrote: > > > "Frank" == Frank Ch Eigler writes: > > >> [...] I suggest that a basic principle for such a system is that it > >> should be *easy* to obtain and maintain a local copy of the history > >> of all pull requests.

Re: configure adds -std=gnu++11 to CXX variable

* Paul Eggert: > diff --git a/NEWS b/NEWS > index 20dbc173..4ba8f3fe 100644 > --- a/NEWS > +++ b/NEWS > @@ -16,6 +16,10 @@ GNU Autoconf NEWS - User visible changes. >C11 and later. Programs can use AC_C_VARARRAYS and __STDC_NO_VLA__ >to use VLAs if available. > > +*** AC_PROG_CXX now pr

Re: configure adds -std=gnu++11 to CXX variable

* Paul Eggert: > On 2024-05-27 03:35, Florian Weimer wrote: >> Does this turn on experimental language modes by default? That's >> probably not what we want. > > What do C++ developers want these days? Autoconf should have a > reasonable default, and C++11 is sure

Re: How to target a processor with very primitive addressing modes?

* Jeff Law via Gcc: > If he's got a CC register exposed prior to LRA and LRA needs to insert > any code, that inserted code may clobber the CC state. This is > discussed in the reload-to-LRA transition wiki page. Do you mean the CC0 conversion page? T

Re: What is the purpose of these two fixincludes?

* Richard Biener via Gcc: > But are they still needed? Often headers already contain > alternatives for standard conforming compilers or GCC can now > deal with the contents. I suspect that io_quotes_def and io_quotes_use in particular often get applied spuriously. Thanks, Florian

Re: RISC-V Pioneer Box for builder.sourceware.org gcc CI

* Jeff Law via Gcc: > On 8/5/24 4:23 PM, Mark Wielaard wrote: > >> It was suggested to just ignore the machine has rvv since it isn't >> 1.0 >> compliant. So it is now configured --with-arch=rv64gc --with-abi=lp64d >> --with-multilib-list=lp64d but that didn't really change any of the >> testresul

Re: stack arenas using alloca

* Michael Clark via Gcc: > On 8/23/24 15:57, Michael Clark wrote: >> On 8/23/24 15:46, Michael Clark wrote: >>> one more thing. it doesn't require PT_GNU_STACK or writable stacks >>> like GCC nested functions. 🙂 so I think it is safer but it does >>> have safety issues, mostly related to stack ove

Re: Fixing dormant bugs in obstack code

* Andrew Pinski via Gcc: > On Wed, Aug 28, 2024 at 2:37 PM David Malcolm via Gcc wrote: >> >> I've been debugging a use-immediately-after-free bug involving obstacks >> (the bug isn't in trunk; I found it whilst testing one of my patches). >> >> It was only visible as a crash when it happened tha

Re: Proposed CHOST change for the 64bit time_t transition

* Arsen Arsenović via Gcc: > Bruno Haible writes: > >> Paul Eggert wrote: >>> I'd rather just switch, as Debian has. >> >> I'd go one step further, and not only >> make the ABI transition without changing the canonical triplet, >> but also >> make gcc and clang define -D_FILE_OFFSET_BITS=64 -

Re: Update bootstrap requirement to C++14?

* Jason Merrill via Gcc: > We moved to a bootstrap requirement of C++11 in GCC 11, 8 years after > support was stable in GCC 4.8. Note that some documentation still says C++03, for example: | The directories gcc, libcpp and fixincludes may use C++03. They may | also use the long long type if the

Re: feature request: a linker option to avoid merging variables from separate object files into shared cache lines

* David Brown via Gcc: > I would have thought it would be better as part of the compiler. For > each compilation unit, you generate one or more data sections > depending on the variable initialisations, compiler options and target > (.bss, .data, .rodata, .sbss, etc.). If the compiler has > "-al

Re: On pull request workflows for the GNU toolchain

* Jonathan Wakely: > The discussion is about how we do patch submission and patch review. > The GitHub pull request workflow is widely seen as simpler than our > current email-based workflow (not everybody agrees, of course). The > idea is to *lower* the barrier of entry for contributors, not rais

Re: [committed] c: Default to -std=gnu23

* Joseph Myers: > Change the default language version for C compilation from -std=gnu17 > to -std=gnu23. A few tests are updated to remove local definitions of > bool, true and false (where making such an unconditional test change > seemed to make more sense than changing the test conditionally e

Re: [committed] c: Default to -std=gnu23

* Sam James: >> Has anyone performed experiments to determine the impact of this change >> on typical free software distributions? > > I filed https://gcc.gnu.org/PR117298 for an issue Joseph noticed in one > of the GCC tests (that is actually an improvement, but a missed opt for > older standards

Re: Alignment of `complex double`

* Jonathan Wakely via Gcc: > On Tue, 7 Jan 2025, 03:09 M Chhapgar via Gcc, wrote: > >> Hello, >> >> I am learning about memory alignment and noticed that on my x86-64 machine >> with GCC 14, a `complex double` has a size of 16 bytes, but an alignment of >> only 8 bytes. I am curious as to why thi

Passing a hidden argument in a dedicated register

I would like to provide a facility to create wrapper functions without lots of argument shuffling. To achieve that, the wrapping function and the wrapped function should have the same prototype. There will be a trampoline that puts additional data somewhere (possibly including the address of the

Re: Passing a hidden argument in a dedicated register

* Alexander Monakov: > On Mon, 16 Dec 2024, Florian Weimer via Gcc wrote: > >> I would like to provide a facility to create wrapper functions without >> lots of argument shuffling. To achieve that, the wrapping function and >> the wrapped function should have the same pro

Re: Question about optimizing dynamic_cast call in C++ at GIMPLE Level

* Hanke Zhang via Gcc: > I have recently been delving into optimizing dynamic_cast calls in C++ > within the context of GIMPLE code. In particular, for scenarios > involving single inheritance, I'm aiming to convert the following > code: > > _1 = __dynamic_cast (obj_1(D), &_ZTI7Base, &_ZTI10Derive

Re: Passing a hidden argument in a dedicated register

* Alexander Monakov: >> > Not in a way that will work with LLVM, I'm afraid, and with GCC >> > you'll have to shield wrappers from LTO: >> > >> > register void *r10 asm("r10"); >> > void f(int, int); >> > void f_wrap(int a, int b) >> > { >> > r10 = f; >> > f(a, b); >> > } >> >> Does this

<    3   4   5   6   7   8