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 locki

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 there

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

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

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

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 simulate

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 s

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

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 standardization

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

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

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

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 o

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 fla

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 t

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

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 a

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

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

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

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

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

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

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

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 > __array_length(cons

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

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

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

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

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 analyze. >> > the use-after-unchecked-open maybe usef

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 >> pthread_create). > > Makes sense. Though that actually

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. > > Why? Isn't int main () {} in C2X the same

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

  1   2   >