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

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

GCC accepts various conversions between pointers and ints and different types of pointers by default, issuing a warning. I've been reading the (hopefully) relevant partso f the C99 standard, and it seems to me that C implementations are actually required to diagnose errors in these cases because t

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

* Zack Weinberg via Gcc: > I’m the closest thing Autoconf has to a lead maintainer at present. > > It’s come to my attention (via https://lwn.net/Articles/913505/ and > https://fedoraproject.org/wiki/Changes/PortingToModernC) that GCC and > Clang both plan to disable several “legacy” C language fe

msp430-elf cross-compiler: libstdc++ supported?

I'm trying to validate a change to gcc/config/msp430/msp430.cc. The cross-compiler builds as far as I can tell, but I hit a snag while configuring libstdc++: checking for shl_load... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES. make[1]: *** [Makefile:12334: configure-tar

Re: Local type inference with auto is in C2X

* Joseph Myers: > On Thu, 3 Nov 2022, Florian Weimer via Gcc wrote: > >> My main worry is that both Clang and GCC still enable implicit ints by >> default. This means that auto variables have type int always, and that >> can subtly alter the meaning of programs. The o

Local type inference with auto is in C2X

So apparently auto was voted in to the committee draft of C2X at the last minute. I wonder how this aligns with the WG14 charter, given the lack of implementation experience with this feature, but it looks like we are now stuck with it. My main worry is that both Clang and GCC still enable implic

Re: C89isms in the test suite

* Joseph Myers: >> Other tests look like they might be intended to be built in C89 mode, >> e.g. gcc/testsuite/gcc.c-torture/compile/386.c, although it's not >> immediately obvious to me what they test. > > For tests that might be deliberately testing implicit function > declarations or unprotot

Re: C2x features status

* Joseph Myers: > On Fri, 21 Oct 2022, Florian Weimer via Gcc wrote: > >> Do you have a list of C2X features that are likely to impact autoconf >> tests? Or planned changes in the GCC 13 and 14 default language modes >> that reject constructs previous accepted as an exten

  1   2   3   >