Re: unnormal Intel 80-bit long doubles and isnanl

* Szabolcs Nagy: > ideally fpclassify (and other classification macros) would > handle all representations. > > architecturally invalid or trap representations can be a > non-standard class but i think classifying them as FP_NAN > would break the least amount of code. I think the fpclassify macro

Re: unnormal Intel 80-bit long doubles and isnanl

* Joseph Myers: > glibc effectively treats them as unspecified behavior - we don't expect > them to produce any particular meaningful function return value (this > includes the possibility that such an invalid encoding might be returned > by a function given such an encoding as input), but if t

Re: unnormal Intel 80-bit long doubles and isnanl

* Siddhesh Poyarekar: > On 11/27/20 5:01 PM, Florian Weimer wrote: >> I think the last part (the “bug”) is new. I welcome a consensus along >> those lines. I just want to highlight this aspect. > > Should we consider fixing behaviour if the bug manifests in a user > appl

Re: PR numbers from Changelogs do not arrive in bugzilla

* Thomas Koenig via Gcc: > I had this problem previously, then it was thought that the > messed-up spellling of my name caused this. That has been > fixed by now. > > Any ideas what could be going wrong? On the glibc side, only bug references in the commit body, not the commit subject are picked

Re: using undeclared function returning bool results in wrong return value

* Jonathan Wakely via Gcc: > Declare your functions. Don't ignore warnings. It's actually a GCC bug that this isn't an error. However, too many configure scripts would still break if we changed the default. So either use -Werror=implicit-function-declaration or C++ for the time being. Thanks,

Re: using undeclared function returning bool results in wrong return value

* David Brown: > On 18/02/2021 13:31, Florian Weimer via Gcc wrote: >> * Jonathan Wakely via Gcc: >> >>> Declare your functions. Don't ignore warnings. >> >> It's actually a GCC bug that this isn't an error. However, too many >> conf

Re: Feature Request for C

On 05/06/2017 07:09 PM, Taylor Holberton wrote: Except instead of using c++ style mangling, it would simply just prepend the name of the namespace to the symbols in the file. Would this also apply to type names and struct tags? How does it interfere with the name resolution in the body of inl

Re: [RFC] A memory gathering optimization for loop

* Feng Xue: > To simplify explanation of this memory gathering optimization, pseudo > code on original nested loops is given as: > > outer-loop ( ) { /* data in inner loop are also invariant in outer loop. */ > ... > inner-loop (iter, iter_count) { /* inner loop to apply MGO */ > >

Re: [RFC] A memory gathering optimization for loop

* Richard Biener: >> Can you change this optimization so that it can use a fixed-size buffer? >> This would avoid all issues around calling calloc. If iter_count can be >> very large, allocating that much extra memory might not be beneficial >> anyway. > > It would need to be TLS storage though o

Re: C language extension - Automatically cast

* Sławomir Lach: > One of items is automatically cast. For example I declared variable called > Button of GtkButton and pass it to function requires GtkWidget. Why do not > automatically cast to GtkWidget (like in class hierarchy or conversion > operator in C++ or some extra constructors)? But

Re: Update to GCC copyright assignment policy

* David Edelsohn via Gcc: > GCC was created as part of the GNU Project but has grown to operate as > an autonomous project. > > The GCC Steering Committee has decided to relax the requirement to > assign copyright for all changes to the Free Software Foundation. GCC > will continue to be develope

Re: [Patch] contrig/gcc-changelog: Check that PR in subject in in changelog

* Tobias Burnus: > On 10.06.21 10:07, Martin Liška wrote: >> On 6/10/21 8:35 AM, Tobias Burnus wrote: >>> One options would be to require a 'PR /' line if there is >>> 'PRn+' in the commit title, rejecting the commit otherwise. >> >> Quite interesting idea! Are you willing to prepare a patch f

GCC arc port defaults to -fcommon

It seems to me that the arc port still defaults to -fcommon, presumably due to this in gcc/common/config/arc/arc-common.c: static void arc_option_init_struct (struct gcc_options *opts) { opts->x_flag_no_common = 255; /* Mark as not user-initialized. */ /* Which cpu we're compiling for (ARC60

Re: GCC arc port defaults to -fcommon

* Richard Biener: > On Wed, Jul 7, 2021 at 11:56 AM Richard Biener > wrote: >> >> On Wed, Jul 7, 2021 at 11:00 AM Florian Weimer via Gcc >> wrote: >> > >> > It seems to me that the arc port still defaults to -fcommon, presumably >> >

Disabling TLS address caching to help QEMU on GNU/Linux

Currently, the GNU/Linux ABI does not really specify whether the thread pointer (the address of the TCB) may change at a function boundary. Traditionally, GCC assumes that the ABI allows caching addresses of thread-local variables across function calls. Such caching varies in aggressiveness betwe

Re: How to detect user uses -masm=intel?

* unlvsur unlvsur via Gcc: > What I mean is that what macro GCC sets when it compiles -masm=intel > > > Int main() > { > #ifdef /*__INTEL_ASM*/ > printf(“intel”); > #else > printf(“at&t”); > #endif > } There doesn't seem to be such a macro: $ diff -u <(gcc -dM

Named address spaces on x86 GNU/Linux

The x86-64 architecture supports two instruction prefixes, SEGFS and SEGGS that apply an additional offset to memory operands. The offset lives in a special register that is accessible to the kernel only (historically). On GNU/Linux, SEGFS is used to implement the thread pointer, to avoid dedicat

Re: [RFC] Adding a new attribute to function param to mark it as constant

* Segher Boessenkool: > On Wed, Aug 04, 2021 at 03:27:00PM +0100, Richard Earnshaw wrote: >> On 04/08/2021 14:40, Segher Boessenkool wrote: >> >On Wed, Aug 04, 2021 at 02:00:42PM +0100, Richard Earnshaw wrote: >> >>We don't want to have to resort to macros. Not least because at some >> >>point we

Enable the vectorizer at -O2 for GCC 12

There has been a discussion, both off-list and on the gcc-help mailing list (“Why vectorization didn't turn on by -O2”, spread across several months), about enabling the auto-vectorizer at -O2, similar to what Clang does. I think the review concluded that the very cheap cost model should be used f

Re: [libc-coord] Add new ABI '__memcmpeq()' to libc

* Richard Biener via Gcc: > On Thu, Sep 16, 2021 at 10:36 PM Joseph Myers wrote: >> >> On Thu, 16 Sep 2021, Chris Kennelly wrote: >> >> > In terms of relying on the feature: If __memcmpeq is ever exposed as an a >> > simple alias for memcmp (since the notes mention that it's a valid >> > impleme

Re: [libc-coord] Add new ABI '__memcmpeq()' to libc

* Richard Biener: > On Fri, Sep 17, 2021 at 10:08 AM Florian Weimer wrote: >> >> * Richard Biener via Gcc: >> >> > On Thu, Sep 16, 2021 at 10:36 PM Joseph Myers >> > wrote: >> >> >> >> On Thu, 16 Sep 2021, Chris Kennelly wrote: &

Re: ARM32 configury changes, with no FPU as a default

* Matthias Klose: > Starting with GCC 8, the configury allows to encode extra features into the > architecture string. Debian and Ubuntu's armhf (hard float) architecture is > configured with > > --with-arch=armv7-a --with-fpu=vfpv3-d16 > > and now should be configured with > > --with-arch=arm

Re: [libc-coord] Add new ABI '__memcmpeq()' to libc

* Joseph Myers: > I was supposing a build-time decision (using GCC_GLIBC_VERSION_GTE_IFELSE > to know if the glibc version on the target definitely has this function). > But if we add a header declaration, you could check for __memcmpeq being > declared (and so cover arbitrary C libraries, not

Re: TYPE_NEEDS_CONSTRUCTING zero for std::string?

* Martin Sebor via Gcc: > I'd expect TYPE_NEEDS_CONSTRUCTING to be non-zero in the middle end > for any C++ type with a user-defined ctor, but in some of my testing > I see it's actually zero for std::string, at least in some instances > (but nonzero for other types with ctors). Is there somethin

Are _Unwind_Find_FDE et al. part of the public ABI?

_Unwind_Find_FDE is exported as a public symbol on GNU/Linux, with a default symbol version. But it's not part of the install header, and its struct types are not namespace-clean for C++, potentially leading to ODR violations. What should we do with _Unwind_Find_FDE and similar exported function

Re: Are _Unwind_Find_FDE et al. part of the public ABI?

* Andreas Schwab: > On Okt 25 2021, Florian Weimer via Gcc wrote: > >> What should we do with _Unwind_Find_FDE and similar exported functions >> that require types which are not currently defined in ? > > Aren't they legacy only? Sorry, I don't understand. _Un

Re: [llvm-dev] [PATCH] Add GNU_PROPERTY_1_GLIBC_2_NEEDED

* H. J. Lu via llvm-dev: > 1. Some binaries which require new ELF features, like DT_RELR, only > work with the new glibc binary. They crash at run-time with the older > glibc binaries. > 2. Somes binaries compiled with the new language features, like C2X > printf specifiers, only generate correct

Re: [llvm-dev] [PATCH] Add GNU_PROPERTY_1_GLIBC_2_NEEDED

* H. J. Lu: > On Wed, Oct 27, 2021 at 11:52 PM Florian Weimer wrote: >> >> * H. J. Lu via llvm-dev: >> >> > 1. Some binaries which require new ELF features, like DT_RELR, only >> > work with the new glibc binary. They crash at run-time with the older >

GCC DWARF unwinder _Unwind_Find_FDE acceleration

I've got a mostly-complete implementation of a faster _Unwind_Find_FDE implementation which lock-free and async-signal-safe. The core idea is to turn into effectively this. const fde * _Unwind_Find_FDE (void *pc, struct dwarf_eh_bases *bases) { struct unw_eh_callback_data data; cons

Re: atomic_load

* Martin Uecker via Gcc: > It would be great if somebody could take a look at > PR96159. > > It seems we do not do atomic accesses correctly > when the alignment is insufficient for a lockfree > access, but I think we should fall back to a > library call in this case (as clang does). > > This is

Re: New ThreadSanitizer runtime (v3)

* Dmitry Vyukov via Gcc: > I wanted to give heads up regarding a significant re-design of the > ThreadSanitizer runtime: > https://reviews.llvm.org/D112603 > Currently it's submitted: > https://github.com/llvm/llvm-project/commit/1784fe0532a69ead17793bced060a9bf9d232027 > but can well be rolled ba

Re: New ThreadSanitizer runtime (v3)

* Dmitry Vyukov: > Or what kind of integration do you mean? Tsan did not have any direct > integration and worked with unmodified glibc. I thought there is a false-positive data race report if an initial-exec or local-exec TLS variable is reused (whose memory is not managed by malloc). Thanks, F

Re: New ThreadSanitizer runtime (v3)

* Dmitry Vyukov: > On Tue, 23 Nov 2021 at 14:59, Florian Weimer wrote: >> >> * Dmitry Vyukov: >> >> > Or what kind of integration do you mean? Tsan did not have any direct >> > integration and worked with unmodified glibc. >> >> I thought there

Re: Work on the power-ieee128 branch has hit a snag...

* Thomas Koenig via Gcc: > ... in > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103476, a very > strange error where an invalid Makefile is generated with > --enable-maintainer-mode on POWER. > > I'm not sure how to proceed from here. Maybe somebody > with more make debug fu could take a look?

Re: Help with an ABI peculiarity

* Jeff Law via Gcc: > Most targets these days use registers for parameter passing and > obviously we can run out of registers on all of them.  The key > property is the size/alignment of the argument differs depending on if > it's pass in a register (get promoted) or passed in memory (not > promot

Re: Help with an ABI peculiarity

* Iain Sandoe: > In the case that a call is built and no prototype is available, the > assumption is that all parms are named. The promotion is then done > according to the C promotion rules. > > [for the number of args that can be passed in int regs] the callee > will happen to observe the same

Minor C2X-induced ABI issue on powerpc64le

I've been following [RFC] Enabling -Wstrict-prototypes by default in C and I've just realized that treating extern int foo(); as a prototype declaration (with the same ABI as extern "C" int foo(); in

Re: No type checking in ctype builtins

* Andreas Schwab: > On Apr 27 2022, Andrea Monaco via Gcc wrote: > >> This program >> >> #include >> >> int main () >> { >> char *s; >> isspace (s); >> } >> >> compiles with no warning in gcc 8.3.0, even though there's a type >> mistake; the correct call would be isspace (*s). > >

Re: -Wformat and u8""

* Ulrich Drepper via Gcc: > t.cc: In function ‘int main()’: > t.cc:5:24: warning: format string is not an array of type ‘char’ [-Wformat=] > 5 | printf((const char*) u8"test %d\n", 1); > |^ This is not an aliasing violation because of the exception

Re: CFI for saved argument registers

* Andreas Krebbel via Gcc: > For that purpose I save the argument registers to the stack as we > would do for a variable argument lists. But this time I also provide > the CFI to allow the unwinder to locate the save slots. Since I never > actually intend to restore the content there is no matchi

Re: [PATCH Linux] powerpc: add documentation for HWCAPs

* Nicholas Piggin: > +2. Facilities > +- > +The Power ISA uses the term "facility" to describe a class of instructions, > +registers, interrupts, etc. The presence or absence of a facility indicates > +whether this class is available to be used, but the specifics depend on the > +ISA v

Re: Gcc Digest, Vol 29, Issue 7

* Yair Lenga via Gcc: > My question: does anyone know how much effort it will be to add a new GCC > built-in (or extension), that will automatically generate a descriptive > format string, consistent with scanf formatting, avoiding the need to > manually enter the formatting string. It's already

Re: Safer vararg calls

* Yair Lenga: > I prefer not to go into “flame wars” on the merits of C vs C++. My > projects are (mostly) in “C” and I am happy with this setup. In > addition, given technical / organizational / business issues, > switching to C++ not an option. Sure, but you could at least use C++ to prototype

Re: [RFC] Using std::unique_ptr and std::make_unique in our code

* Pedro Alves: > For example, for the type above, we'd have: > > typedef std::unique_ptr pending_diagnostic_up; > > and then: > > -pending_diagnostic *d, > +pending_diagnostic_up d, > > I would suggest GCC have a similar guideline

Re: Adding file descriptor attribute(s) to gcc and glibc

* Szabolcs Nagy via Gcc: > to be honest, i'd expect interesting fd bugs to be > dynamic and not easy to statically analyze. > the use-after-unchecked-open maybe useful. i would > not expect the access direction to catch many bugs. You might be right. But I think the annotations could help to cat

Re: Adding file descriptor attribute(s) to gcc and glibc

* David Malcolm: > On Wed, 2022-07-13 at 14:05 +0200, Florian Weimer wrote: >> * Szabolcs Nagy via Gcc: > > [adding Immad back to the CC list] > >> >> > to be honest, i'd expect interesting fd bugs to be >> > dynamic and not easy to statically a

Re: rust non-free-compatible trademark

* lkcl via Gcc: > if the Rust Foundation were to add an extremely simple phrase > >"to be able to use the word rust in a distributed compiler your > modifications must 100% pass the test suite without modifying > the test suite" > > then all the problems and pain goes away. No. It wo

Re: rust non-free-compatible trademark

* Arthur Cohen: > Hi Florian, > > On Mon, Jul 18, 2022, 20:33 Florian Weimer via Gcc wrote: > No. It would actually make matters worse for GCC in this case because > the stated intent is to ship without a borrow checker (“There are no > immediate plans for a borrow chec

Counting static __cxa_atexit calls

We currently have a latent bug in glibc where C++ constructor calls can fail if they have static or thread storage duration and a non-trivial destructor. The reason is that __cxa_atexit (and __cxa_thread_atexit_impl) may have to allocate memory. We can avoid that if we know how many such static c

Re: Counting static __cxa_atexit calls

* Michael Matz: > Hello, > > On Tue, 23 Aug 2022, Florian Weimer via Gcc wrote: > >> We currently have a latent bug in glibc where C++ constructor calls can >> fail if they have static or thread storage duration and a non-trivial >> destructor. The re

Re: Counting static __cxa_atexit calls

* Michael Matz: > Hello, > > On Wed, 24 Aug 2022, Florian Weimer wrote: > >> > Isn't this merely moving the failure point from exception-at-ctor to >> > dlopen-fails? >> >> Yes, and that is a soft error that can be handled (likewise for >> pt

Re: The GNU Toolchain Infrastructure Project

* Mark Wielaard via Overseers: > Hi David, > > On Tue, Oct 11, 2022 at 01:14:50PM -0400, David Edelsohn wrote: >> an alternative proposal? When were they allowed to participate in the >> preparation of the "Sourceware" proposal, supposedly for their benefit? > > It wasn't really meant as an altern

C89isms in the test suite

What should we do about these when they are not relevant to what's being tested? For example, gcc/testsuite/gcc.c-torture/execute/ieee/mzero6.c has this: int main () { if (__builtin_copysign (1.0, func (0.0 / -5.0, 10)) != -1.0) abort (); exit (0); } but no include files, so

Re: C89isms in the test suite

* Jakub Jelinek: > On Fri, Oct 21, 2022 at 10:40:16AM +0200, Florian Weimer via Gcc wrote: >> What should we do about these when they are not relevant to what's being >> tested? For example, gcc/testsuite/gcc.c-torture/execute/ieee/mzero6.c >> has this: >> &

Re: C89isms in the test suite

* Jakub Jelinek: > On Fri, Oct 21, 2022 at 11:17:40AM +0200, Florian Weimer wrote: >> So we would patch the tests? > > Depends on how large the patch is, but I'd say so. > >> I guess we can make sure we use “int main >> (void)” etc. at the same time. > &

Re: C89isms in the test suite

* Florian Weimer via Gcc: > * Jakub Jelinek: > >> On Fri, Oct 21, 2022 at 11:17:40AM +0200, Florian Weimer wrote: >>> So we would patch the tests? >> >> Depends on how large the patch is, but I'd say so. >> >>> I guess we can make su

Re: C2x features status

* Joseph Myers: > I'm working on adding various C2x features to the C front end (and > elsewhere in GCC as applicable). > > I suspect I won't get all the C2x features done for GCC 13. If anyone > else is interested in adding C2x features, I'd encourage looking at some > of the following, which

Re: C2x features status

* Arsen Arsenović: > On Friday, 21 October 2022 21:14:54 CEST Marek Polacek via Gcc wrote: >> commit 0a91bdaf177409a2a5e7895bce4f0e7091b4b3ca >> Author: Joseph Myers >> Date: Wed Sep 7 13:56:25 2022 + >> >> c: New C2x keywords >> >> which says: >> >> As with the removal of unprot

Re: C89isms in the test suite

* Joseph Myers: > On Fri, 21 Oct 2022, Florian Weimer via Gcc wrote: > >> Is this really possible? For function pointers, it's an ABI change. >> int (*) () and int (*) (void) have different calling conventions on some >> ABIs (e.g., powerpc64le-linux-gnu). The

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

* 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

* 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

* 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

* 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

* 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

* 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

* 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

* 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

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

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

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

<    2   3   4   5   6   7   8   >