Re: Switching x86-64 to GNU2 TLS descriptors

* H. J. Lu: > On Tue, Jul 15, 2025 at 8:47 AM 'Florian Weimer' via X86-64 System V > Application Binary Interface wrote: >> >> * H. J. Lu: >> >> > Compilers will never know since the build-time glibc is independent of >> > the run-time glibc. If compilers want to be 100% sure that the run-time

Re: Switching x86-64 to GNU2 TLS descriptors

* H. J. Lu: > Compilers will never know since the build-time glibc is independent of > the run-time glibc. If compilers want to be 100% sure that the run-time > is GNU2 TLS bug-free, they can require linkers which generate the > GLIBC_ABI_GNU2_TLS dependency. (Such a linker requirement could be

Re: Switching x86-64 to GNU2 TLS descriptors

* Adhemerval Zanella Netto: >> (b) Introduce binary markup to indicate that binaries may need the glibc >> fix, and that glibc has the fix. >> >> [PATCH] x86-64: Add GLIBC_ABI_GNU2_TLS [BZ #33129] >> >> >>

Re: Switching x86-64 to GNU2 TLS descriptors

* Richard Biener: > I think both (a) or (d) are reasonable, though I am missing a > configure time flag to override the changed default. Even with > glibc fixed we likely do not want to have this change in older > enterprise code streams given there might be unknown external > tooling that might

Switching x86-64 to GNU2 TLS descriptors

H.J. proposed to switch the default for GCC 16 (turning on -mtls-dialect=gnu2 by default). This is a bit tricky because when we tried to make the switch in Fedora (for eventual implementation), we hit an ABI compatibility problem: _dl_tlsdesc_dynamic doesn't preserve all caller-saved registers

Re: RFD: switch/case statement dispatch using hash

* Andi Kleen via Gcc: > Joern Wolfgang Rennecke writes: > >> 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

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: 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

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

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

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: [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: 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: 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: 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: 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: 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: 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: 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: 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: 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 surely not a good default anymore. I

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: 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: [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: [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: 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: 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: 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: 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: [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 >> Add support for heap-bas

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 consensus regarding this in 2014. See below. >> >>> If we leak memo

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

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: 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

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

-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

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

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)

* 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

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

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

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

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

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 particularly important for "-std=c89", while >>>

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: > 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: 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

* 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: 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; >> >

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: 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

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

-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

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

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: 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

* 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

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: 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

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: > 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: >> > > 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

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

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,

Re: Calling convention for Intel APX extension

* Thomas Koenig via Gcc: > Intel recommends to have the new registers as caller-saved for > compatibility with current calling conventions. If I understand this > correctly, this is required for exception unwinding, but not if the > function called is __attribute__((nothrow)). Nothrow functions

Re: m68k Coldfire and PC-relative addressing distances

* Richard Biener: > On Tue, Jul 11, 2023 at 11:36 AM Florian Weimer via Gcc > wrote: >> >> How does the Coldfire m68k subtarget and sure that displacements in PIC >> code are within the addressable range? > > There is usually a branch shortening pass relying on

m68k Coldfire and PC-relative addressing distances

How does the Coldfire m68k subtarget and sure that displacements in PIC code are within the addressable range? We have a source file in glibc that fails at assembly because it contains a branch that is out of range with -fpic. The GAS error is: …/iso-2022-jp.s: Fatal error: Tried to convert PC r

Re: End of subscription

* Iain Sandoe: >> On 24 May 2023, at 14:09, Paul Koning via Gcc wrote: >> Curious, because Mac OS mail does show it as a mailing list message, >> offering up an "unsubscribe" button. So it looks like an iOS mail bug. > > for me, in macOS mail “it depends” - sometimes the posts are marked as > f

Re: Differences between clang and gcc handling of int[static n] function arguments

* Jonathan Wakely: > On Wed, 24 May 2023 at 10:06, Florian Weimer wrote: >> >> * Jonathan Wakely via Gcc: >> >> >> It seems it might even be trivial enough for me to investigate and >> >> tackle myself, in some spare time. >> >> >> >> I see very little code using either of these features, so it's

Re: Differences between clang and gcc handling of int[static n] function arguments

* Jonathan Wakely via Gcc: >> It seems it might even be trivial enough for me to investigate and >> tackle myself, in some spare time. >> >> I see very little code using either of these features, so it's >> definitely not a high priority task regardless. >> > > Glibc uses the nonnull attribute in

Re: End of subscription

* Jonathan Wakely via Gcc: > Unfortunately even the Gmail web UI doesn't offer an unsubscribe > option, despite knowing the mails come from a list and showing: > > mailing list: gcc@gcc.gnu.org Filter messages from this mailing list It does for me, under the ⏷ menu at the end of the recipient lis

Re: More C type errors by default for GCC 14

* Jason Merrill: > As a compromise, it should be possible to error by default only in > cases where the implicit int (including as a return value) is either > the source or target of a non-value-preserving conversion, as those > are very likely to be bugs. That seems desirable for both camps. No

Re: More C type errors by default for GCC 14

* Jakub Jelinek: > On Tue, May 16, 2023 at 01:39:26PM +0300, Alexander Monakov wrote: >> >> On Tue, 16 May 2023, Florian Weimer wrote: >> >> > > (FWIW: no, this should not be an error, a warning is fine, and I >> > > actually >> > > think the current state of it not being in Wall is the right

Re: More C type errors by default for GCC 14

* Michael Matz: > Hello, > > On Fri, 12 May 2023, Florian Weimer wrote: > >> * Alexander Monakov: >> >> > This is not valid (constraint violation): >> > >> > unsigned x; >> > >> > int *p = &x; >> > >> > In GCC this is diagnosed under -Wpointer-sign: >> > >> > https://gcc.gnu.org/bugzilla/sh

Re: More C type errors by default for GCC 14

* Eric Gallager via Gcc: > I support this plan for using -Werror= and having it be split based on > whether -std= is set to a strict ANSI option or a GNU option; is there > a way to do that in the optfiles, or would it have to be handled at > the specs level instead? This isn't going to work well

Re: More C type errors by default for GCC 14

* Thomas Koenig via Gcc: > So... using an error message as a crowbar to change people's behavior > failed, at least partially. And you only hear from the people who > complain, not from those who are glad that they found errors that they > would otherwise have missed. Thank you for sharing the F

Re: More C type errors by default for GCC 14

* Richard Biener: > On Wed, May 10, 2023 at 10:05 AM Jonathan Wakely via Gcc > wrote: >> >> On Wed, 10 May 2023, 03:32 Eli Zaretskii, wrote: >> >> > >> > And then people will start complaining about GCC unnecessarily >> > erroring out, which is a compiler bug, since there's no problem >> > produ

Re: More C type errors by default for GCC 14

* Eli Zaretskii via Gcc: >> Date: Tue, 9 May 2023 21:07:07 +0200 >> From: Jakub Jelinek >> Cc: Jonathan Wakely , ar...@aarsen.me, gcc@gcc.gnu.org >> >> On Tue, May 09, 2023 at 10:04:06PM +0300, Eli Zaretskii via Gcc wrote: >> > People who ignore warnings will use options that disable these new >

Re: More C type errors by default for GCC 14

* David Edelsohn: > Yes, GCC has two, distinct user groups / use cases, but GCC also has a > very unique and crucial role, as the foundation for a large portion of > the GNU/Linux and FOSS software ecosystem. This proposal is missing a > motivation for this change, especially making new errors th

Re: More C type errors by default for GCC 14

* Sam James: > Florian Weimer writes: > >> * Richard Biener: >> >>>> Am 09.05.2023 um 14:16 schrieb Florian Weimer via Gcc : >>>> >>>> TL;DR: This message is about turning implicit-int, >>>> implicit-function-declaration,

Re: More C type errors by default for GCC 14

* Richard Biener: >> Am 09.05.2023 um 14:16 schrieb Florian Weimer via Gcc : >> >> TL;DR: This message is about turning implicit-int, >> implicit-function-declaration, and possibly int-conversion into errors >> for GCC 14. > > I suppose the goal is to not

Re: More C type errors by default for GCC 14

* Richard Biener: > > Am 09.05.2023 um 18:13 schrieb David Edelsohn : > > > > On Tue, May 9, 2023 at 12:07 PM Jakub Jelinek via Gcc > > wrote: > > > > On Tue, May 09, 2023 at 05:16:19PM +0200, Richard Biener via Gcc wrote: > > > > > > >

More C type errors by default for GCC 14

TL;DR: This message is about turning implicit-int, implicit-function-declaration, and possibly int-conversion into errors for GCC 14. A few of you might remember that I've been looking into turning some type errors from warnings into errors by default. Mainly I've been looking at implicit functio

Re: Probe emission in fstack-clash-protection

* Varun Kumar E. via Gcc: > Hello, > > https://godbolt.org/z/P3M8s8jqh > The above case shows that gcc first decreases the stack pointer and then > probes. > > As mentioned by Jeff Law (reference >

Re: GCC/Clang attributes guiding warnings about unused entities

* Stephan Bergmann via Gcc: > [cross-posting this to both the GCC and Clang communities] I don't see your post here: I don't think this is expected to work from a Discourse point of view. > * __attribute__((unus

Re: libsanitizer: sync from master

* Martin Liška: > On 4/26/23 20:31, Florian Weimer wrote: >> * Martin Liška: >> >>> On 11/15/22 16:47, Martin Liška wrote: Hi. I've just pushed libsanitizer update that was tested on x86_64-linux and ppc64le-linux systems. Moreover, I run bootstrap on x86_64-linux and ch

Re: libsanitizer: sync from master

* Martin Liška: > On 11/15/22 16:47, Martin Liška wrote: >> Hi. >> >> I've just pushed libsanitizer update that was tested on x86_64-linux and >> ppc64le-linux systems. >> Moreover, I run bootstrap on x86_64-linux and checked ABI difference with >> abidiff. > > Hello. > > And I've done the same

Re: Using __gnu_lto_slim to detect -fno-fat-lto-objects

* Richard Biener: > On Wed, Feb 22, 2023 at 9:19 AM Florian Weimer via Gcc > wrote: >> >> Can we use the COMMON symbol __gnu_lto_slim to detect >> -fno-fat-lto-objects on contemporary GNU/Linux (with the LTO linker >> plugin)? > > Yes. Great, thanks. &g

Using __gnu_lto_slim to detect -fno-fat-lto-objects

Can we use the COMMON symbol __gnu_lto_slim to detect -fno-fat-lto-objects on contemporary GNU/Linux (with the LTO linker plugin)? We currently build the distribution with -ffat-lto-objects, and I want to switch away from that. Packages will need to opt in to -ffat-lto-objects if static objects t

Re: libquadmath, glibc, and the Q format flag

* Jakub Jelinek: > On Wed, Feb 01, 2023 at 11:56:42AM +0100, Florian Weimer via Gcc wrote: >> I recently discovered that libquadmath registers custom printf callbacks >> on load. As far as I can tell, this is done so that the Q format flag >> can be used to print floating

libquadmath, glibc, and the Q format flag

I recently discovered that libquadmath registers custom printf callbacks on load. As far as I can tell, this is done so that the Q format flag can be used to print floating point numbers, using format strings such as "%Qf". To enable Q flag processing, libquadmath has to register replacements for

Default initialization of poly-ints

It seems that the default constructor of the non-POD poly-ints does nothing. Is this intentional? I expected zero initialization, to match regular ints. Thanks, Florian

Re: Triggering -save-temps from the front-end code

* Arsen Arsenović: > Hi, > > Florian Weimer via Gcc writes: > >> Unfortunately, some build systems immediately delete the input source >> files. Is there some easy way I can dump the pre-processed and >> non-preprocessed sources to my log file? I tried to und

Triggering -save-temps from the front-end code

I've got some instrumentation for logging errors to a magic directory, so that I can see if a build triggered them even when it did not fail—and hid all compiler errors and warnings. Unfortunately, some build systems immediately delete the input source files. Is there some easy way I can dump the

Re: How can Autoconf help with the transition to stricter compilation defaults?

* Paul Eggert: > On 2022-11-14 04:41, Aaron Ballman wrote: >> it's generally a problem when autoconf relies on invalid >> language constructs > > Autoconf *must* rely on invalid language constructs, if only to test > whether the language constructs work. And Clang therefore must be > careful abou

Re: C89isms in the test suite

* Sam James: > Would you be able to backport 6be2672e4ee41c566a9e072088a263bab5f7 > and 885b6660c17fb91980b5682514ef54668e544b02 to the active <13 > branches? Jakub, okay to backport these two (to 12, 11, 10 I presume)? commit 6be2672e4ee41c566a9e072088a263bab5f7 Author: Florian Weimer

Re: How can Autoconf help with the transition to stricter compilation defaults?

* Rich Felker: > I've been writing/complaining about autoconf doing this wrong for > decades, with the best writeup around 9 years ago at > https://ewontfix.com/13/. Part of the reason is that this has bitten > musl libc users over and over again due to configure finding symbols > that were intend

Re: -Wint-conversion, -Wincompatible-pointer-types, -Wpointer-sign: Are they hiding constraint C violations?

* Marek Polacek: > On Thu, Nov 10, 2022 at 07:25:21PM +0100, Florian Weimer via Gcc wrote: >> GCC accepts various conversions between pointers and ints and different >> types of pointers by default, issuing a warning. >> >> I've been reading the (hopefully) re

  1   2   3   >