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

Re: Mathematical Statistics Functions for libgo

* Arjunlal M. A.: > I was wondering if libgo contained any modules for high precision > statistics functions. If it doesn't, would implementing something like that > really necessary? I think these functions would have to go into the mainline Go codebase first before they appear in libgo.

Re: bit field alignment

* Doug McIlroy via Gcc: > What was the rationale for the gcc ABI convention that int > bit fields force the containing struct to be int-aligned? > > For example, the size of struct{int x:2;} is 4 in Linux > gcc, completely wasting 3 out of every 4 bytes of memory. I'm pretty sure that this

Re: Should ARMv8-A generic tuning default to -moutline-atomics

* Kyrylo Tkachov: > Hi Florian, > >> -Original Message- >> From: Gcc On Behalf Of Florian Weimer via Gcc >> Sent: 29 April 2020 13:33 >> To: gcc@gcc.gnu.org >> Cc: nmeye...@amzn.com >> Subject: Should ARMv8-A generic tuning default to -moutline-

Should ARMv8-A generic tuning default to -moutline-atomics

Distributions are receiving requests to build things with -moutline-atomics: Should this be reflected in the GCC upstream defaults for ARMv8-A generic tuning? It does not make much sense to me if every distribution has to overide

Re: size of exception handling

* Moritz Strübe: > Hey. > > Am 11.05.2020 um 15:59 schrieb Thomas Neumann via Gcc: >> In a way I am disagreeing with the paper, of course, in that I propose >> to make the existing exception mechanism faster instead of inventing a >> new exception mechanism. But what I agree on with P0709 is that

Re: size of exception handling

* Freddie Chopin: > Very nice that Moritz finally mentioned it (; The world of deep > embedded is usually forgotten by all the language committees and people > who are in charge. That can only happen if the embedded people do not bother to show up in numbers. Of course the tools will move in

Re: size of exception handling

* Moritz Strübe: >> Would you use it if switching from -fno-exceptions to this new >> approach resulted in an immediate 20% code size increase, without >> actually using the new error handling feature at all? What about >> 10%? > > I don't think that it will be that much. Why? Have you

Re: [RFC] Closing of all remaining Bugzilla PRs against powerpcspe

* Segher Boessenkool: > I can't speak for Arseny of course, but the reason *I* want this is to > no longer see all those powerpcspe BZs in my powerpc queries -- nothing > ever changes to them, so it's just pointless distraction. Keeping them open might also lead to some users believing that

Re: performance of exception handling

* Thomas Neumann via Gcc: > Currently, exception handling scales poorly due to global mutexes when > throwing. This can be seen with a small demo script here: > https://repl.it/repls/DeliriousPrivateProfiler > Using a thread count >1 is much slower than running single threaded. > This global

Re: performance of exception handling

* Thomas Neumann: >> Link: >> >> I'm not sure if your summary is correct. > > I was referring to Section 3.2, where Herb says: > > "We must remove all technical reasons for a C++ project to disable > exception handling (e.g., by compiler switch) or ban use of

Re: performance of exception handling

* David Edelsohn: > On Mon, May 11, 2020 at 10:52 AM Florian Weimer wrote: >> >> * David Edelsohn: >> >> > On Mon, May 11, 2020 at 6:47 AM Florian Weimer via Gcc >> > wrote: >> > >> >> My current preferred solution is something th

Re: performance of exception handling

* David Edelsohn: > On Mon, May 11, 2020 at 6:47 AM Florian Weimer via Gcc > wrote: > >> My current preferred solution is something that moves the entire code >> that locates the relevant FDE table into glibc. This is all the code in >> _Unwind_IterateP

AArch64 and -moutline-atomics

FYI: I've verified that when building with GCC 10, outline atomics are correctly initialized on LSE machines. The ld.so ELF constructors eventually get run and initialize __aarch64_have_lse_atomics. One minor improvement would be to document __aarch64_have_lse_atomics as interposable on the GCC

Re: Function signatures in extern "C".

* Jakub Jelinek via Gcc: > On Mon, Sep 07, 2020 at 10:27:13AM +0100, Jonathan Wakely via Gcc wrote: >> On Mon, 7 Sep 2020 at 09:18, Iain Sandoe wrote: >> > >> > Perhaps the PR should be reopened with “accepts invalid”? >> >> My impression from the PR is that the reporter was using a different >>

Re: Does -fstack-protector really need to clear registers?

* Jeff Law via Gcc: >> (1) We don't make any effort to hide the address of the canary value >> (typically &__stack_chk_guard, although some targets support >> alternatives). It's not obvious what “hiding” this address >> would actually mean in practice, since it would often be easily

Re: Expose 'array_length()' macro in

* Jonathan Wakely: > I don't see much point in using std::size here. If you're going to > provide the alternative implementation for when std::size isn't > defined, why not just use it always? > > template > #if __cplusplus >= 201103L > constexpr > #endif > inline std::size_t >

Re: [libc-coord] Re: Expose 'array_length()' macro in

* Jonathan Wakely: >># define array_length(arr) (std:size(arr)) > > C++ programmers will not accept a macro for this. I think we need a macro for C++98 support because there is no other way to produce constant expression. Note that this intended for C programs compiled in C++ mode. As

Re: Expose 'array_length()' macro in

* Ville Voutilainen: > Why should this be array_length and not __array_length? This is a > vendor extension, so it should use > a name that is reserved for such? In general, we use __ for glibc internals that are not intended for direct access by users. In some cases, we have non-__ identifiers

Re: Question about -moutline-atomic under -mcmodel-large

* Bin Cheng via Gcc: > Last question is why do we have __aarch64_have_lse_atomics(and some > other symbols) in both libgcc and glibc? > > #objdump -t /usr/lib64/libc.so.6 | grep "__aarch64_ldadd" > > 00111460 l F .text 0030 > __aarch64_ldadd8_acq > > 00111370 l

Re: Question about -moutline-atomic under -mcmodel-large

* Florian Weimer: > * Bin Cheng via Gcc: > >> Last question is why do we have __aarch64_have_lse_atomics(and some >> other symbols) in both libgcc and glibc? >> >> #objdump -t /usr/lib64/libc.so.6 | grep "__aarch64_ldadd" >> >> 00111460 l F .text 0030 >>

Re: Two new proposals to the upcoming C2X standard

* Andreas Schwab: > On Mai 29 2020, David Brown wrote: > >> So my counter-proposal for you would be to recommend gcc's "typeof" as a >> new keyword (spelt "_Typeof", with "typeof" as a macro in , >> in solid C tradition). > > Or call it _Decltype/decltype, following C++. But please only if it

Re: Two new proposals to the upcoming C2X standard

* Xavier Del Campo Romero via Gcc: > I have sent the following proposals to the committee, but they require > them to be implemented at least into two major compilers, That seems to be an odd requirement. Once implement in GCC and Clang, there is every incentive not submit it for

Re: AArch64 and -moutline-atomics

* Richard Henderson: > On 5/19/20 3:38 AM, Florian Weimer via Gcc wrote: >> One minor improvement would be to document __aarch64_have_lse_atomics as >> interposable on the GCC side and define that directly in glibc, so that >> lse-init.o is not linked in anymore and __aarch64

Re: AArch64 and -moutline-atomics

* Szabolcs Nagy: > The 05/20/2020 09:02, Florian Weimer via Gcc wrote: >> * Richard Henderson: >> > On 5/19/20 3:38 AM, Florian Weimer via Gcc wrote: >> >> One minor improvement would be to document __aarch64_have_lse_atomics as >> >> interposable on the

Re: Expose 'array_length()' macro in or

* Alejandro Colomar: > [[ > CC += libc-co...@sourceware.org > CC += gcc@gcc.gnu.org > CC += libstd...@gcc.gnu.org > ]] > > Hi Florian, > > On 2020-09-21 10:38, Florian Weimer wrote: >> * Alejandro Colomar via Libc-alpha: >> >>> I'd like to propose exposing the macro 'array_length()' as defined in

Re: desired behavior or missing warning?

* Ulrich Drepper via Gcc: > I found myself with code similar to this: > > struct base { > virtual void cb() = 0; > }; > > struct deriv final : public base { > void cb() final override { } > }; > > > The question is about the second use of 'final'. Because the entire > class is declared

Re: New x86-64 micro-architecture levels

* Premachandra Mallappa: > [AMD Public Use] > > Hi Floarian, > >> I'm including a proposal for the levels below. I use single letters for >> them, but I expect that the concrete implementation of this proposal will >> use >> names like “x86-100”, “x86-101”, like in the glibc patch referenced

Re: New x86-64 micro-architecture levels

* Jan Beulich: > On 21.07.2020 20:04, Florian Weimer wrote: >> * Premachandra Mallappa: >> >>> [AMD Public Use] >>> >>> Hi Floarian, >>> I'm including a proposal for the levels below. I use single letters for them, but I expect that the concrete implementation of this proposal will

Re: New x86-64 micro-architecture levels

* Richard Biener: > On Wed, Jul 22, 2020 at 10:58 AM Florian Weimer via Gcc > wrote: >> >> * Dongsheng Song: >> >> > I fully agree these names (100/101, A/B/C/D) are not very intuitive, I >> > recommend using isa tags by year (e.g. x64_2010, x64_2014)

Re: New x86-64 micro-architecture levels

* Dongsheng Song: > I fully agree these names (100/101, A/B/C/D) are not very intuitive, I > recommend using isa tags by year (e.g. x64_2010, x64_2014) like the > python's platform tags (e.g. manylinux2010, manylinux2014). I started out with a year number, but that was before the was Level A.

Re: Ellipsis in varadic macro definitions

* Jonathan Wakely via Gcc: > On Sun, 2 Aug 2020 at 15:49, Philip R Brenan via Gcc wrote: >> >> Hi *GCC*: >> >> On page: >> >> https://gcc.gnu.org/onlinedocs/cpp/Variadic-Macros.html#Variadic-Macros >> >> you say: >> >> #define eprintf(args…) fprintf (stderr, args) >> >> but do you in fact mean:

Re: Non-inlined functions and mixed architectures

* Allan Sandfeld Jensen: > On Montag, 27. Juli 2020 10:54:02 CEST Florian Weimer wrote: >> * Allan Sandfeld Jensen: >> > On Montag, 27. Juli 2020 10:33:35 CEST Florian Weimer wrote: >> >> * Allan Sandfeld Jensen: >> >> > A problem that I keep running into is functions defined headers, but >> >> >

Re: documentation of powerpc64{,le}-linux-gnu as primary platform

* David Edelsohn via Gcc: > No, it's not dropped. Some people are being pedantic about the name, > which is why Bill added {,le}. powerpc64-unknown-linux-gnu means > everything. If you want to add {,le} back, that's fine. But there > always is some variant omitted, and that doesn't mean it is

Re: New x86-64 micro-architecture levels

* Joseph Myers: > On Fri, 10 Jul 2020, Florian Weimer via Gcc wrote: > >> * Level A >> >> CMPXCHG16B, LAHF/SAHF, POPCNT, SSE3, SSE4.1, SSE4.2, SSSE3 >> >> This is one step above the K8 baseline and corresponds to a mainline CPU >> model ca. 2008 to 2

Re: New x86-64 micro-architecture levels

* H. J. Lu: > Looks good. I like it. Thanks. What do you think about Level B? Should we keep it? > My only concerns are > > 1. Names like “x86-100”, “x86-101”, what features do they support? I think we can add more diagnostic output to ld.so --help. My patch does not show individual CPU

Re: New x86-64 micro-architecture levels

* Allan Sandfeld Jensen: > On Freitag, 10. Juli 2020 19:30:09 CEST Florian Weimer via Gcc wrote: >> glibc (or an alternative loader implementation) would search for >> libraries starting at level D, going back to level A, and finally the >> baseline implementation in the def

Re: New x86-64 micro-architecture levels

* Richard Biener: >> Looks good. I like it. > > Likewise. Btw, did you check that VIA family chips slot into Level A > at least? Those seem to lack SSE4.2, so they land in the baseline. > Where do AMD bdverN slot in? bdver1 to bdver3 (as defined by GCC) should land in Level B (so Level A if

Re: documentation of powerpc64{,le}-linux-gnu as primary platform

* Bill Schmidt via Gcc: > Matthias, if you want to post a patch for GCC 9 and GCC 10, I'm sure > that would be accepted (though I do not have the power to pre-approve > it).  Or I can put it on my list for later in the summer when my life > settles down.  Your choice. I posted a patch:

Re: New x86-64 micro-architecture levels

* Mark Wielaard: > One thing that wasn't clear to me from this proposal is how the glibc > dynamic loader checks for the CPU feature flags. This is important for > valgrind since it can communicate those through different means. cpuid > interception, auxv AT_HWCAP/AT_HWCAP2 interception (but not

New x86-64 micro-architecture levels

Most Linux distributions still compile against the original x86-64 baseline that was based on the AMD K8 (minus the 3DNow! parts, for Intel EM64T compatibility). There has been an attempt to use the existing AT_PLATFORM-based loading mechanism in the glibc dynamic linker to enable a selection of

Re: install location of math-vector-fortran.h

* Matthias Klose: > [not subscribed to the libc-alpha list] > > GCC and glibc need to agree on the install location for math-vector-fortran.h. > Currently it is installed into > > /usr/include/finclude/math-vector-fortran.h > > However the file is architecture specific, currently only having >

Re: install location of math-vector-fortran.h

* Matthias Klose: > this file currently only has lines like: > > !GCC$ builtin (cos) attributes simd (notinbranch) if('x86_64') > > so it shouldn't have any effect to other architectures? Or are the > conditionals explicitly done to exclude the 32bit x86 configuration? Ah. It's the latter.

Re: New x86-64 micro-architecture levels

* Premachandra Mallappa: > [AMD Public Use] >>> Also we would also like to have dynamic loader support for "zen" / >>> "zen2" as a version of "Level D" and takes preference over Level D, >>> which may have super-optimized libraries from AMD or other vendors. > >> *That* shouldn't be too hard

Re: Non-inlined functions and mixed architectures

* Allan Sandfeld Jensen: > A problem that I keep running into is functions defined headers, but used in > sources files that are compiled with different CPU feature flags (for runtime > CPU feature selection). > > We know to make sure the functions are inlinable and their address never >

Re: Non-inlined functions and mixed architectures

* Allan Sandfeld Jensen: > On Montag, 27. Juli 2020 10:33:35 CEST Florian Weimer wrote: >> * Allan Sandfeld Jensen: >> > A problem that I keep running into is functions defined headers, but used >> > in sources files that are compiled with different CPU feature flags (for >> > runtime CPU feature

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

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 > application and not in glibc

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

Re: Using IFUNC with template functions.

* Amrita H. S. via Gcc: > I am interested to know if there any other better way to use ifuncs with > template functions. If there is none, is it worth suggesting to the C++ > standards? IFUNC is GNU-specific. It's not supported by all ELF platforms, and not even by all non-glibc Linux targets.

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

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

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

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

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

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

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 >> configure scripts w

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

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

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

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: >> >> >> >> > In terms of relying on the feature: If __memcmpeq

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,

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”); > #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

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

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

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

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,

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

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 is a false-positive data race report if an

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

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 >> > glibc binaries. >> > 2. Somes binaries

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;

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

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

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

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

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 >

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

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

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

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

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

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

-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

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

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

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

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

  1   2   3   4   >