Re: Backend for a stack-oriented architecture

* Michael Matz: > Hello, > > On Mon, 24 Feb 2025, Florian Weimer wrote: > >> .proc fib (_long) (_long) >> # Argument/result register: %3 >> # return address register: %2 >> # local register: %1 >> # outgoing argument/return register: %0 >> .frames

Re: GCC used to store pointers in FP registers on aarch64

* Attila Szegedi: >> That seems … quite unlikely. GCC 8 has seen extensive use on >> AArch64, on a variety of implementations, and I don't recall >> problems in this area. I don't follow AArch64 *that* closely, >> admittedly, but I expect it would have caused quite a ruckus. >> > > Yeah. The lac

Backend for a stack-oriented architecture

As a hobby project, I'm working on a mostly memory-safe architecture that is targeted at direct software emulation. The majority of its instructions have memory operands that are relative to the stack pointer. Calls and returns adjust the stack pointer, so I suppose one could say that the archite

Re: GCC used to store pointers in FP registers on aarch64

* Attila Szegedi via Gcc: > We noticed that this version of GCC compiling on aarch64 will happily use > FP registers to temporarily store/load pointers, so there'd be "fmov d9, > x1" to store a pointer, and then later when it's used as a parameter to a > function call we'll see "fmov x1, d9" etc.

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: Using gcc as a sort of scripting language.

* Jonathan Wakely via Gcc: > Here's a complete example: > > #!/bin/sh > set -e > out=$(mktemp /tmp/a.out.XX) > sed 1,5d "$0" | gcc -x c - -o "$out" > exec "$out" > > #include > int main() > { > puts("Hello, world"); > return 0; > } Or this, with accurate locations for diagnostics and arg

Re: Passing a hidden argument in a dedicated register

* Alexander Monakov: > Well, the first paragraph in your initial mail was talking very explicitly > about making a tailcall from the wrapper, so I guess the goalpost has moved. Uhm, I meant a tailcall from the trampoline, not the wrapper. >> LD_AUDIT offers outright replacement of the address fo

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: C23 status on cppreference

* Joseph Myers: > On Wed, 16 Oct 2024, Florian Weimer wrote: > >> * Jakub Jelinek via Gcc: >> >> > Are some of the papers/features known to be fully implemented (since which >> > version)? E.g. for __VA_OPT__ I remember doing (and Jason too) various >>

Re: C23 status on cppreference

* Jakub Jelinek via Gcc: > Are some of the papers/features known to be fully implemented (since which > version)? E.g. for __VA_OPT__ I remember doing (and Jason too) various fixes > in the past few years, like PR89971, PR103415, PR101488. Not really sure > what exactly C23 requires. Can we add

Re: Educational question on compiling (analyzing) the C programming language

* Laurent Cimon via Gcc: > I realize that compilers have evolved with time, and that many > things required the use of function prototypes, but my question is, > what is the historical reason that a function defined further down > in a C file cannot be used without a function prototype? The most

Re: Handling C2Y zero-length operations on null pointers

* Jakub Jelinek: > How do you express that with access attribute, which can only have 1 > size argument? Don't we sometimes use inline functions to handle such special cases? > For the rest, perhaps we need some nonnull_if_nonzero argument > which requires that the parameter identified by the fi

Re: Handling C2Y zero-length operations on null pointers

* Joseph Myers: > The real question is how to achieve optimal warnings in the absence of the > attribute. Should we have a variant of the nonnull attribute that warns > for NULL arguments but without optimizing based on them? I think attribute access already covers part of it: #include void

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: Bad interaction between gcc and glibc's handling of GNU extension [GCC PR 115724]

* Jakub Jelinek: > On Tue, Jul 02, 2024 at 12:54:09PM -0400, David Malcolm via Gcc wrote: >> Back in 2007 glibc gained some logic to implement "error" and >> "error_at_line" by splitting into zero and non-zero cases, with the >> nonzero case calling a "noreturn" function [1]. >> >> This doesn't s

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 sure

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

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

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. >> >> >> &g

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

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; >> > >> &

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

* Sam James: > Florian Weimer writes: > >> * Sam James: >> >>> Florian Weimer writes: >>> >>>> [...] >>>> In summary, all these seems to be good candidates for errors by default: >>>> >>>> * int-conversion

Re: More C type errors by default for GCC 14

* Sam James: > Florian Weimer writes: > >> [...] >> In summary, all these seems to be good candidates for errors by default: >> >> * int-conversion as errors (already raised separately >> * -Wint-conversion for ?: >> * parameter names in non-prototype

Re: More C type errors by default for GCC 14

* Jason Merrill: > On Fri, May 12, 2023 at 11:03 AM Florian Weimer wrote: >> >> * Joseph Myers: >> >> > On Wed, 10 May 2023, Eli Zaretskii via Gcc wrote: >> > >> >> That is not the case we are discussing, AFAIU. Or at least no one has >&

Re: More C type errors by default for GCC 14

* Joseph Myers: > On Fri, 12 May 2023, Florian Weimer wrote: > >> This sone seems to be a good candidate for additional errors, though: >> >> warned_here = pedwarn >> (loc, warn_return_type >= 0 ? OPT_Wreturn_type : 0, >> "% with no value, i

Re: More C type errors by default for GCC 14

* 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/show_bug.cgi?id=25892 Thanks for the reference. I filed: -Wpointer-sign must be enabled by default

Re: More C type errors by default for GCC 14

* Gabriel Ravier: > On 5/12/23 19:52, Florian Weimer wrote: >> * Florian Weimer: >> >>> In summary, all these seems to be good candidates for errors by default: >>> >>> * int-conversion as errors (already raised separately >>> * -Wint-conve

Re: More C type errors by default for GCC 14

* Florian Weimer: > In summary, all these seems to be good candidates for errors by default: > > * int-conversion as errors (already raised separately > * -Wint-conversion for ?: > * parameter names in non-prototype function declarations > * the union wait function pointer co

Re: More C type errors by default for GCC 14

* Joseph Myers: > On Wed, 10 May 2023, Eli Zaretskii via Gcc wrote: > >> That is not the case we are discussing, AFAIU. Or at least no one has >> yet explained why accepting those old K&R programs will adversely >> affect the ability of GCC to compile C2x programs. > > At block scope, > > auto

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 >

  1   2   3   4   5   6   7   8   >