Re: Proposing switch -fsmart-pointers

++. Rust is a new language, with no concern for backwards compatibility, but if it turns out that this is impossible to solve there, it won't work for C/C++, either. In the meantime, there is the cleanup attribute, and C++ already has several kinds of smart pointers. -- Florian Weimer

Re: Broken Math Resource Link on Your Site - Follow-up

* Jonathan Wakely: > The link you referred to is in an archived email sent to a GCC mailing > list. The contents of mails sent to the list are not really the > responsibility of the GCC project and editing archived posts to fix > broken links is not an option. Alexandra (probably not her real nam

Re: Passing 64-bit function arguments to assembler

On 10/12/2012 10:55 AM, Mischa Baars wrote: As can be seen from the objdump output, 64-bit arguments are passed in 32-bit registers x86_64 clears the upper 32 bit of a 64 bit register if the lower 32 bit are written to, so this isn't a bug. -- Florian Weimer / Red Hat Product Security Team

Re: bounds checking in STL containers

-D_FORTIFY_SOURCE, but GCC isn't able to hoist the bounds check out of inner loops, so the impact is pretty significant: <http://gcc.gnu.org/ml/libstdc++/2012-06/msg2.html> -- Florian Weimer / Red Hat Product Security Team

Re: Time for GCC 5.0? (TIC)

modularity allowing for easier plugin development, major improvements in static & dynamic analysis capabilities, etc. Or a new ABI for libstdc++, I guess. -- Florian Weimer / Red Hat Product Security Team

Re: RFC - Alternatives to gengtype

you were asking about std::shared_ptr.) -- Florian Weimer / Red Hat Product Security Team

Re: RFC - Alternatives to gengtype

memory overhead was done (at much, much smaller heap sizes for sure). -- Florian Weimer / Red Hat Product Security Team

Re: RFC - Alternatives to gengtype

well. The beauty of Cheney's scheme is that it uses the from space as a work queue, and I don't see how we can do something similar in mostly portable C++. (That being said, we could probably use Boehm GC for the bootstrap compiler and a different collector after bootstrapping.) --

Re: BUG: assuming signed overflow does not occur when simplifying conditional to constant

* Bruce Korb: > I wrote a loop that figures out how many items are in a list, > counts down from that count to -1, changes direction and counts > up from 0 to the limit, a la: > > > inc = -1; > int idx = 0; > while (opts->papzHomeList[idx+1] != NULL) > idx++; > for (;;) {

Re: BUG: assuming signed overflow does not occur when simplifying conditional to constant

* Bruce Korb: > Hi Florian, > > On Sat, Dec 29, 2012 at 2:38 AM, Florian Weimer wrote: >>> ../../autoopts/configfile.c: In function 'intern_file_load': >>> ../../autoopts/configfile.c:1025:12: error: assuming signed overflow does >>> not occur \ &g

Re: Integer Overflow/Wrap and GCC Optimizations

instruction in the *same* asm statement. You cannot use asm statements to access such flags set by other asm statements, or by code emitted by GCC. -- Florian Weimer / Red Hat Product Security Team

Re: gcc : c++11 : full support : eta?

temporaries etc., things which are just not visible in an AST. You have to reimplement many program analysis algorithms typically part of compiler optimizers, after lowering the AST to a less elaborate intermediate representation (a step which requires a fair amount of knowledge about the langu

Re: SPEC2006 436.cactusADM performance depends on the length of $LD_LIBRARY_PATH

On 02/19/2013 12:14 PM, Ilya Verbin wrote: Is this a known issue? I think this might be the phenomenon described in Mytkowicz et al., "Producing Wrong Data Without Doing Anything Obviously Wrong!". -- Florian Weimer / Red Hat Product Security Team

Re: How does _ZNSs4_Rep20_S_empty_rep_storageE (not) become a unique global symbol?

..") or not: We tracked this down to a bug in ld: <http://sourceware.org/bugzilla/show_bug.cgi?id=15107> -- Florian Weimer / Red Hat Product Security Team

Re: [PATCH][4.3] Deprecate -ftrapv

* Robert Dewar: > So here's exactly what happens now in Ada > > 1. If -gnato is not set (no overflow checking) > > In this case, the situation is exactly the same as C, and the front end > ignores the possibility of overflow. It's C in -fwrapv mode, isn't it? (Otherwise, you can't really get the

Re: [PATCH][4.3] Deprecate -ftrapv

* Richard Kenner: >> int f(int a, int b) { return 0 * (a + b); } >> >> get the potentially trapping arithmetic folded away. If -ftrapv is to >> have properly defined semantics, those must include trapping if (a + b) >> overflows in the above code. > > Why? Is there any language that requires

Re: [PATCH][4.3] Deprecate -ftrapv

* Florian Weimer: > * Richard Kenner: > >>> int f(int a, int b) { return 0 * (a + b); } >>> >>> get the potentially trapping arithmetic folded away. If -ftrapv is to >>> have properly defined semantics, those must include trapping if (a + b) >&

Re: [PATCH][4.3] Deprecate -ftrapv

* Robert Dewar: > Florian Weimer wrote: >> * Robert Dewar: >> >>> So here's exactly what happens now in Ada >>> >>> 1. If -gnato is not set (no overflow checking) >>> >>> In this case, the situation is exactly the same as C, and th

Re: [PATCH][4.3] Deprecate -ftrapv

* Robert Dewar: >> Standard ML. I don't think there is a GCC front end (and it's not >> likely that one will be feasible, at least until GCC supports a fitting >> garbage collector). > > Why is it a GCC issue to support a GC for ML, I don't get it ... ML programs are mostly functional and alloca

Re: [PATCH][4.3] Deprecate -ftrapv

* Ross Ridge: > At the risk of my curiousity getting me into more trouble, could any > one explain to me how to access these "eip" and "trapno" members from > a signal handler on Linux? I can't find any relevent documention with > man nor Google. I think you need sigaction with a SA_SIGINFO, and

Re: atomic accesses

* Segher Boessenkool: > Good point. Suggestions for better wording? How does > > "any access to a naturally aligned scalar object in memory > that is not a bit-field and fits in a general purpose integer > machine register, will be performed by a single machine > instruct

Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag

* Robert Dewar: > again, in the real world, there are MANY projects that are nothing > like this interactive when it comes to moving to new versions of > operating systems. Sure, but how many of those get to see software compiled with GCC 4.3? If this has any real impact, it's more likely to sho

Re: Official GCC git repository

* Daniel Berlin: > They could have made massive strides since then (this was a little > over a year ago), but I wouldn't trust anything with that large of a > scaling issue to have solved it in such a short time. They still compute revision numbers on the fly in many commands, which means that th

Re: Copyright assignment wiki page

* Richard Kenner: >> This is probably true for a country like the USA, but like FX >> the FSF didn't ask a disclaimer from my employer: in France >> as long as you don't use your employer ressources to contribute >> your employer has absolutely no say on what you do outside your work. > > That's t

Re: US-CERT Vulnerability Note VU#162289

* Robert C. Seacord: > I agree with you that the behavior that gcc exhibits in this case is > permitted by the ISO/IEC 9899:1999 C specification > > (§6.5.6p8). I believe the vulnerability is that gcc may *silently* > discard the overfl

Re: US-CERT Vulnerability Note VU#162289

* Robert C. Seacord: > i agree that the optimization is allowed by C99. i think this is a > quality of implementation issue, and that it would be preferable for > gcc to emphasize security over performance, as might be expected. I don't think this is reasonable. If you use GCC and its C fronte

Re: US-CERT Vulnerability Note VU#162289

* Robert Dewar: > Florian Weimer wrote: >> * Robert C. Seacord: >> >>> i agree that the optimization is allowed by C99. i think this is a >>> quality of implementation issue, and that it would be preferable for >>> gcc to emphasize security over perfor

Re: US-CERT Vulnerability Note VU#162289

* Brad Roberts: > Additionally, the linked to notes for GCC are reflective of the original > innaccuracies: > > http://www.kb.cert.org/vuls/id/CRDY-7DWKWM > > Vendor Statement > No statement is currently available from the vendor regarding this > vulnerability. Chad, it would be helpful if you

Re: US-CERT Vulnerability Note VU#162289

* Robert Dewar: > To me, the whole notion of this vulnerability node > is flawed in that respect. You can write a lengthy > and useful book on pitfalls in C that must be > avoided, but I see no reason to turn such a book > into a cert advisory, I think it's useful to point out in security advisor

Re: bit_size_type - a data type?

* Richard Kenner: >> bitsizetype is a type that can hold any values of sizetype * >> BITS_PER_UNIT so we can safely do bit-size calculations without overflow. >> This type shouldn't end up used in code though. > > Unfortunately, it does, though not in C. Ada's 'Size attribute returns > the size i

Re: bit_size_type - a data type?

* Richard Kenner: >> Ada used a 32-bit signed integer type in this case, limiting object size >> to 2**31 bits. Is this no longer the case? > > It was never the case. You're confusing sizetype with bitsizetype. The limit was definitely there. Maybe it had a different root cause, though.

Re: Should we remove java from the default bootstrap languages?

* Tom Tromey: > We could look into this. The minimum subset is probably several > hundred classes. For instance, Class refers to URL, which will > probably pull in most of java.net. Can't you fallback to the interpreter for the URL class?

Re: use of %n in genmodes.c causes trouble on Vista

* Ian Lance Taylor: > What is the security issue here? The issue arrases in programs that pass attacker-controlled data as the format string. They use printf(some_string); syslog(LOG_INFO, some_string); instead of printf("%s", some_string); syslog(LOG_INFO, "%s", some_string); The ma

Re: RFH: GPLv3

* Robert Dewar: > One could of course just take a blanket view that everything > on the site is, as of a certain moment, licensed under GPLv3 > (note you don't have to change file headers to achieve this, > the file headers have no particular legal significance in > any case). In Germany, they ar

Re: Ada standard elaboration order

* Christophe Meudec: > So how can the body of system.soft_links be elaborated prior to the > body of ada.exceptions since it is dependent on it? The standard library is not subject to the elaboration rules of the language. It's not written in standard Ada, either.

Re: -fno-tree-cselim not working?

* Andrew Pinski: > Yes it is duplicated. And it is not a new problem, if conversion has > been with GCC since the 2.95 days so I don't understand why it is only > being brought up now (except threading programming is becoming more > popular). The cmov instruction is post-Pentium material, so it'

Re: Optimization of conditional access to globals: thread-unsafe?

* Andrew Haley: > The core problem here seems to be that the "C with threads" memory > model isn't sufficiently well-defined to make a determination > possible. You're assuming that you have no resposibility to mark > shared memory protected by a mutex as volatile, but I know of nothing > in the

Re: Optimization of conditional access to globals: thread-unsafe?

* Bart Van Assche: > As known the compiler may not reorder any access to any static > variable, global variable or dynamically allocated data with a call to > a function that is not declared inline. I assume you mean "defined in another translation unit" instead of "not declared inline". Still,

Re: Optimization of conditional access to globals: thread-unsafe?

* Bart Van Assche: > On 10/27/07, Florian Weimer <[EMAIL PROTECTED]> wrote: > >> And this isn't really specific to threads. > > Hello Florian, > > What I was trying to explain is that it is not necessary to declare > shared variables volatile, not for any C

Re: Optimization of conditional access to globals: thread-unsafe?

* Robert Dewar: >> In the following example, is the access to "Shared" considered >> unsynchronized even though what looks like a proper lock is used >> around it? > > Yes, it is unsynchronized. Why would you think otherwise? The signaling rules are dynamic, not static. Only the code path that i

Re: Optimization of conditional access to globals: thread-unsafe?

* Samuel Tardieu: > On 27/10, Florian Weimer wrote: > > | (I can't reproduce the conditional store with my GCC 4.2 installation, > | though.) > > You need "-O -fno-inline" to trigger it on this particular example > (you don't need "-fno-inline&

Re: Optimization of conditional access to globals: thread-unsafe? II

* Andi Kleen: > Ian Lance Taylor <[EMAIL PROTECTED]> writes: > > Never mind your latest patch with Jakub's feedback seems to handle > that correctly. Looks good to me. It fixes the (very simple) Java test case, too.

Re: Progress on GCC plugins ?

* Robert Dewar: > Tom Tromey wrote: > >> First, aren't we already in this situation? There are at least 2 >> compilers out there that re-use parts of GCC by serializing trees and >> then reading them into a different back end. > > It's not obvious to me that this is consistent with the GPL .. It

Re: Handling C2Y zero-length operations on null pointers

* Jakub Jelinek: > How do you express that with access attribute, which can only have 1 > size argument? Don't we sometimes use inline functions to handle such special cases? > For the rest, perhaps we need some nonnull_if_nonzero argument > which requires that the parameter identified by the fi

Re: C23 status on cppreference

* Joseph Myers: > On Wed, 16 Oct 2024, Florian Weimer wrote: > >> * Jakub Jelinek via Gcc: >> >> > Are some of the papers/features known to be fully implemented (since which >> > version)? E.g. for __VA_OPT__ I remember doing (and Jason too) various >>

Re: C23 status on cppreference

* Jakub Jelinek via Gcc: > Are some of the papers/features known to be fully implemented (since which > version)? E.g. for __VA_OPT__ I remember doing (and Jason too) various fixes > in the past few years, like PR89971, PR103415, PR101488. Not really sure > what exactly C23 requires. Can we add

Re: Educational question on compiling (analyzing) the C programming language

* Laurent Cimon via Gcc: > I realize that compilers have evolved with time, and that many > things required the use of function prototypes, but my question is, > what is the historical reason that a function defined further down > in a C file cannot be used without a function prototype? The most

Re: Handling C2Y zero-length operations on null pointers

* Joseph Myers: > The real question is how to achieve optimal warnings in the absence of the > attribute. Should we have a variant of the nonnull attribute that warns > for NULL arguments but without optimizing based on them? I think attribute access already covers part of it: #include void

Re: Passing a hidden argument in a dedicated register

* Alexander Monakov: > Well, the first paragraph in your initial mail was talking very explicitly > about making a tailcall from the wrapper, so I guess the goalpost has moved. Uhm, I meant a tailcall from the trampoline, not the wrapper. >> LD_AUDIT offers outright replacement of the address fo

Re: Using gcc as a sort of scripting language.

* Jonathan Wakely via Gcc: > Here's a complete example: > > #!/bin/sh > set -e > out=$(mktemp /tmp/a.out.XX) > sed 1,5d "$0" | gcc -x c - -o "$out" > exec "$out" > > #include > int main() > { > puts("Hello, world"); > return 0; > } Or this, with accurate locations for diagnostics and arg

Re: Backend for a stack-oriented architecture

* Michael Matz: > Hello, > > On Mon, 24 Feb 2025, Florian Weimer wrote: > >> .proc fib (_long) (_long) >> # Argument/result register: %3 >> # return address register: %2 >> # local register: %1 >> # outgoing argument/return register: %0 >> .frames

Re: GCC used to store pointers in FP registers on aarch64

* Attila Szegedi via Gcc: > We noticed that this version of GCC compiling on aarch64 will happily use > FP registers to temporarily store/load pointers, so there'd be "fmov d9, > x1" to store a pointer, and then later when it's used as a parameter to a > function call we'll see "fmov x1, d9" etc.

Backend for a stack-oriented architecture

As a hobby project, I'm working on a mostly memory-safe architecture that is targeted at direct software emulation. The majority of its instructions have memory operands that are relative to the stack pointer. Calls and returns adjust the stack pointer, so I suppose one could say that the archite

Re: GCC used to store pointers in FP registers on aarch64

* Attila Szegedi: >> That seems … quite unlikely. GCC 8 has seen extensive use on >> AArch64, on a variety of implementations, and I don't recall >> problems in this area. I don't follow AArch64 *that* closely, >> admittedly, but I expect it would have caused quite a ruckus. >> > > Yeah. The lac

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

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 follow

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 these

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-

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

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

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 r

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

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 prop

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.

<    1   2   3   4   5   6   7   8   >