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.

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

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 the ope

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

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

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 >

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

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

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

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

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

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

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

-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

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 lik

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

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-interface.c:1

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 (); | ^~~~

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

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

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,

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 >

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

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 = >> int i2 = p2; > > Implicit conversions b

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

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

-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

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

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

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 our imp

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

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

Re: [gcc r13-7720] x86: Update model values for Raptorlake.

* Lili Cui via Gcc-cvs: > https://gcc.gnu.org/g:0fa76e35a5f9e141c08fdf151380f2f9689101c7 > > commit r13-7720-g0fa76e35a5f9e141c08fdf151380f2f9689101c7 > Author: Cui, Lili > Date: Mon Aug 14 02:06:00 2023 + > > x86: Update model values for Raptorlake. > > Update model values

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: Intel AVX10.1 Compiler Design and Support

* Hongtao Liu: > On Wed, Aug 9, 2023 at 3:17 PM Jan Beulich wrote: >> Aiui these ABI levels were intended to be incremental, i.e. higher versions >> would include everything earlier ones cover. Without such a guarantee, how >> would you propose compatibility checks to be implemented in a way

Re: Intel AVX10.1 Compiler Design and Support

* Richard Biener via Gcc-patches: > I don’t think we can realistically change the ABI. If we could > passing them in two 256bit registers would be possible as well. > > Note I fully expect intel to turn around and implement 512 bits on a > 256 but data path on the E cores in 5 years. And it

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

[PATCH releases/gcc-13 1/2] libgcc: Fix eh_frame fast path in find_fde_tail

The eh_frame value is only used by linear_search_fdes, not the binary search directly in find_fde_tail, so the bug is not immediately apparent with most programs. Fixes commit e724b0480bfa5ec04f39be8c7290330b495c59de ("libgcc: Special-case BFD ld unwind table encodings in find_fde_tail").

[PATCH releases/gcc-13 2/2] libgcc: Fix -Wint-conversion warning in find_fde_tail

Fixes commit r14-1614-g49310a99330849 ("libgcc: Fix eh_frame fast path in find_fde_tail"). libgcc/ PR libgcc/110179 * unwind-dw2-fde-dip.c (find_fde_tail): Add cast to avoid implicit conversion of pointer value to integer. (cherry picked from commit

Re: [PATCH] aarch64: Fix warnings during libgcc build

* Richard Earnshaw: > On 11/07/2023 10:37, Florian Weimer via Gcc-patches wrote: >> libgcc/ >> * config/aarch64/aarch64-unwind.h >> (aarch64_cie_signed_with_b_key): >> Add missing const qualifier. Cast from const unsigned char * >> to const char

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

[PATCH] riscv: Fix -Wincompatible-pointer-types warning during libgcc build

libgcc/ * config/riscv/linux-unwind.h (riscv_fallback_frame_state): Add missing cast. --- libgcc/config/riscv/linux-unwind.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libgcc/config/riscv/linux-unwind.h b/libgcc/config/riscv/linux-unwind.h index

[PATCH] or1k: Fix -Wincompatible-pointer-types warning during libgcc build

libgcc/ * config/or1k/linux-unwind.h (or1k_fallback_frame_state): Add missing cast. --- libgcc/config/or1k/linux-unwind.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libgcc/config/or1k/linux-unwind.h b/libgcc/config/or1k/linux-unwind.h index

[PATCH] arc: Fix -Wincompatible-pointer-types warning during libgcc build

libgcc/ * config/arc/linux-unwind.h (arc_fallback_frame_state): Add missing cast. --- libgcc/config/arc/linux-unwind.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libgcc/config/arc/linux-unwind.h b/libgcc/config/arc/linux-unwind.h index

[PATCH] csky: Fix -Wincompatible-pointer-types warning during libgcc build

libgcc/ * config/csky/linux-unwind.h (csky_fallback_frame_state): Add missing cast. --- libgcc/config/csky/linux-unwind.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libgcc/config/csky/linux-unwind.h b/libgcc/config/csky/linux-unwind.h index

[PATCH] m68k: Avoid implicit function declaration in libgcc

libgcc/ * config/m68k/fpgnulib.c (__cmpdf2): Declare. --- libgcc/config/m68k/fpgnulib.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libgcc/config/m68k/fpgnulib.c b/libgcc/config/m68k/fpgnulib.c index fe41edf26aa..d5c3411e947 100644 --- a/libgcc/config/m68k/fpgnulib.c +++

[PATCH] aarch64: Fix warnings during libgcc build

libgcc/ * config/aarch64/aarch64-unwind.h (aarch64_cie_signed_with_b_key): Add missing const qualifier. Cast from const unsigned char * to const char *. Use __builtin_strchr to avoid an implicit function declaration. * config/aarch64/linux-unwind.h

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

[PATCH] libgcc: Fix -Wint-conversion warning in find_fde_tail

Fixes commit r14-1614-g49310a99330849 ("libgcc: Fix eh_frame fast path in find_fde_tail"). libgcc/ PR libgcc/110179 * unwind-dw2-fde-dip.c (find_fde_tail): Add cast to avoid implicit conversion of pointer value to integer. --- libgcc/unwind-dw2-fde-dip.c | 2 +- 1 file

Re: [RFC] Add stdckdint.h header for C23

* Paul Eggert: > I don't see how you could implement __has_include_next() > for arbitrary non-GCC compilers, which is what we'd need for glibc > users. This is not a requirement for glibc in general. For example, only works with compilers to which it has been ported. Thanks, Florian

[PATCH] libgcc: Fix eh_frame fast path in find_fde_tail

The eh_frame value is only used by linear_search_fdes, not the binary search directly in find_fde_tail, so the bug is not immediately apparent with most programs. Fixes commit e724b0480bfa5ec04f39be8c7290330b495c59de ("libgcc: Special-case BFD ld unwind table encodings in find_fde_tail"). [I'd

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 >

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

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.

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 = >> > >> > In GCC this is diagnosed under -Wpointer-sign: >> > >> >

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

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

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

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

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

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

Re: Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values

* Puneet Kumar Yatnal via Gcc-bugs: > What is next step here? How do I post this in Bugzilla and get > support. This issue has already been fixed with this commit: commit 80fe172ba9820199c2bbce5d0611ffca27823049 Author: Jonathan Wakely Date: Tue Nov 9 23:45:36 2021 + libstdc++:

Re: [libstdc++] use strtold for from_chars even without locale

* Jonathan Wakely via Libstdc: > We could use strtod for a single-threaded target (i.e. > !defined(_GLIBCXX_HAS_GTHREADS) by changing the global locale using > setlocale, instead of changing the per-thread locale using uselocale. This is not generally safe because the call to setlocale is still

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 >

[PATCH] libstdc++: Mention recent libgcc_s symbol versions in manual

GCC_11.0 is an aarch64-specific outlier. * doc/xml/manual/abi.xml (abi.versioning.history): Add GCC_7.0.0, GCC_9.0.0, GCC_11.0, GCC_12.0.0, GCC_13.0.0 for libgcc_s. --- libstdc++-v3/doc/xml/manual/abi.xml | 5 + 1 file changed, 5 insertions(+) diff --git

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. > *

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

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

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

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

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

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

Re: [PATCH] Various fixes for DWARF register size computation

* Jakub Jelinek: > On Tue, Jan 03, 2023 at 12:15:23PM +0100, Florian Weimer wrote: >> --- a/gcc/debug.h >> +++ b/gcc/debug.h >> @@ -245,7 +245,18 @@ extern const struct gcc_debug_hooks vmsdbg_debug_hooks; >> >> /* Dwarf2 frame information. */ >> >> -extern int dwarf_reg_sizes_constant ();

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

[PATCH] Various fixes for DWARF register size computation

The previous code had several issues. 1. XALLOCAVEC does not create any objects, so invocating the non-POD poly_uint16 assignment operator is undefined. 2. The default constructor of poly-ints does not create a zero poly-int object (unlike what happens with regular ints). 3. The register

Re: [PATCH 1/3] Compute a table of DWARF register sizes at compile

* Jeff Law: > On 11/8/22 11:05, Florian Weimer via Gcc-patches wrote: >> The sizes are compile-time constants. Create a vector with them, >> so that they can be inspected at compile time. >> >> * gcc/dwarf2cfi.cc (init_return_column_size): Remove. >>

Re: [PATCH] docs: Suggest options to improve ASAN stack traces

* Marek Polacek via Gcc-patches: > diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi > index 726392409b6..2de14466dd3 100644 > --- a/gcc/doc/invoke.texi > +++ b/gcc/doc/invoke.texi > @@ -16510,6 +16510,14 @@ The option cannot be combined with > @option{-fsanitize=thread} or >

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

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

Re: [PATCH] c: Propagate erroneous types to declaration specifiers [PR107805]

* Jakub Jelinek: > On Thu, Nov 24, 2022 at 11:01:40AM +0100, Florian Weimer via Gcc-patches > wrote: >> * Joseph Myers: >> >> > On Tue, 22 Nov 2022, Florian Weimer via Gcc-patches wrote: >> > >> >> Without this change, finish_declspecs cannot tel

Re: [PATCH] c: Propagate erroneous types to declaration specifiers [PR107805]

* Joseph Myers: > On Tue, 22 Nov 2022, Florian Weimer via Gcc-patches wrote: > >> Without this change, finish_declspecs cannot tell that whether there >> was an erroneous type specified, or no type at all. This may result >> in additional diagnostics for implicit ints

  1   2   3   4   >