Re: Switching x86-64 to GNU2 TLS descriptors

On Tue, Jul 15, 2025 at 8:47 AM 'Florian Weimer' via X86-64 System V Application Binary Interface wrote: > > * H. J. Lu: > > > Compilers will never know since the build-time glibc is independent of > > the run-time glibc. If compilers want to be 100% sure that the run-time > > is GNU2 TLS bug-fr

Re: Switching x86-64 to GNU2 TLS descriptors

On Tue, Jul 15, 2025 at 7:55 AM Florian Weimer wrote: > > * Adhemerval Zanella Netto: > > >> (b) Introduce binary markup to indicate that binaries may need the glibc > >> fix, and that glibc has the fix. > >> > >> [PATCH] x86-64: Add GLIBC_ABI_GNU2_TLS [BZ #33129] > >> > >>

Re: Switching x86-64 to GNU2 TLS descriptors

On Mon, Jul 7, 2025 at 4:37 PM Florian Weimer wrote: > > H.J. proposed to switch the default for GCC 16 (turning on > -mtls-dialect=gnu2 by default). This is a bit tricky because when we > tried to make the switch in Fedora (for eventual implementation), we hit > an ABI compatibility problem: > >

Re: gcc.gnu.org performance issues?

On Thu, Aug 15, 2024 at 10:17 AM Harald Anlauf via Gcc wrote: > > Hi all, > > is it only me who is recently experiencing intermittent > but extreme slowness of "git pull"? > > I did an ssh -v and saw the following: > > debug1: pledge: filesystem full > > Is that real or a bogus message? > > (My lo

Re: Build errors for older versions

On Thu, Apr 25, 2024 at 8:55 AM Andrew Pinski wrote: > > On Thu, Apr 25, 2024 at 4:21 AM Stefan Schulze Frielinghaus via Gcc > wrote: > > > > Hi all, > > > > while bisecting I recently ran into build errors like > > > > In file included from /devel/gcc/libgcc/../gcc/tsystem.h:101, > >

Re: Switching x86_64-linux-gnu to GNU2 TLS descriptors by default

On Wed, Dec 13, 2023 at 6:19 AM Florian Weimer via Gcc wrote: > > I feel like I have asked this before. Currently, GCC uses calls to > __tls_get_addr to obtain the address of global-dynamic TLS variables. > On other architectures with support for GNU2 TLS descriptors, those are > used by default.

Re: libsanitizer: sync from master

On Wed, Apr 26, 2023 at 4:37 PM H.J. Lu wrote: > > On Wed, Apr 26, 2023 at 1:24 PM Martin Liška wrote: > > > > On 4/26/23 21:23, H.J. Lu wrote: > > > On Wed, Apr 26, 2023 at 6:52 AM Martin Liška wrote: > > >> > > >> On 11/15/22 16:47, Martin Liška wrote: > > >>> Hi. > > >>> > > >>> I've just pus

Re: libsanitizer: sync from master

On Wed, Apr 26, 2023 at 1:24 PM Martin Liška wrote: > > On 4/26/23 21:23, H.J. Lu wrote: > > On Wed, Apr 26, 2023 at 6:52 AM Martin Liška wrote: > >> > >> On 11/15/22 16:47, Martin Liška wrote: > >>> Hi. > >>> > >>> I've just pushed libsanitizer update that was tested on x86_64-linux and > >>> p

Re: libsanitizer: sync from master

On Wed, Apr 26, 2023 at 6:52 AM Martin Liška wrote: > > On 11/15/22 16:47, Martin Liška wrote: > > Hi. > > > > I've just pushed libsanitizer update that was tested on x86_64-linux and > > ppc64le-linux systems. > > Moreover, I run bootstrap on x86_64-linux and checked ABI difference with > > abi

Re: [Exception Handling] Why does frame unwind label have static alignment 4?

On Mon, Jan 17, 2022 at 9:24 AM Joseph Faulls wrote: > > Hello all, > > Small disclaimer of being new to EH, but I have come across a problem that > seems quite fundamental to EH frame registry. I am targeting riscv64, but I > believe the problem to be entirely platform agnostic. > > When using

Re: [PATCH] x86-64: Optimize memset for zeroing

On Fri, Dec 31, 2021 at 2:19 PM Noah Goldstein wrote: > > On Fri, Dec 31, 2021 at 4:14 PM Noah Goldstein > wrote: > > > > On Fri, Dec 31, 2021 at 2:36 PM H.J. Lu wrote: > > > > > > On Fri, Dec 31, 2021 at 12:21 PM Noah Goldstein > > > wrote: > > > > > > > > On Fri, Dec 31, 2021 at 12:20 PM H.

Re: [PATCH] x86-64: Optimize memset for zeroing

On Fri, Dec 31, 2021 at 12:43 PM Florian Weimer wrote: > > * H. J. Lu via Libc-alpha: > > > bzero is an alias of SSE2 memset in glibc. Should we add __memsetzero > > like __memcmpeq? It should be almost free in glibc. GCC can use > > __memsetzero if it is available. > > bzero does not have the

Re: [PATCH] x86-64: Optimize memset for zeroing

On Fri, Dec 31, 2021 at 12:21 PM Noah Goldstein wrote: > > On Fri, Dec 31, 2021 at 12:20 PM H.J. Lu wrote: > > > > Update MEMSET_VDUP_TO_VEC0_AND_SET_RETURN to use PXOR, which has lower > > lantency and higher throughput than VPBROADCAST, for zero constant. > > Since the most common usage of mems

Re: GCC 12.0.0 Status Report (2021-11-15), Stage 3 in effect NOW

On Mon, Nov 15, 2021 at 4:05 AM Richard Biener via Gcc-patches wrote: > > > Status > == > > The GCC development branch now is open for general bugfixing (Stage 3). > > Take the quality data below with a big grain of salt - most of the > new P3 classified bugs will become P1 or P2 (generally ev

Re: [PATCH] Add GNU_PROPERTY_1_GLIBC_2_NEEDED

On Thu, Oct 28, 2021 at 10:43 AM Joseph Myers wrote: > > On Wed, 27 Oct 2021, H.J. Lu via Libc-alpha wrote: > > > Linker adds glibc versions in GNU_PROPERTY_1_GLIBC_2_NEEDED to the > > .gnu.version_r section and removes GNU_PROPERTY_1_GLIBC_2_NEEDED note > > when generating shared libraries and ex

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

On Thu, Oct 28, 2021 at 6:43 AM Florian Weimer wrote: > > * 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

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

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 compiled with the new l

[PATCH] Add GNU_PROPERTY_1_GLIBC_2_NEEDED

Motivations: 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 results with the new

Re: GCC 11.1.1 Status Report (2021-07-06)

On Tue, Jul 6, 2021 at 12:00 AM Richard Biener wrote: > > > Status > == > > The GCC 11 branch is open for regression and documentation fixes. > It's time for a GCC 11.2 release and we are aiming for a release > candidate in about two weeks which would result in the GCC 11.2 > release about thr

Re: GCC 11.1.1 Status Report (2021-07-06)

On Tue, Jul 6, 2021 at 12:00 AM Richard Biener wrote: > > > Status > == > > The GCC 11 branch is open for regression and documentation fixes. > It's time for a GCC 11.2 release and we are aiming for a release > candidate in about two weeks which would result in the GCC 11.2 > release about thr

Re: [llvm-dev] RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX

On Mon, Jun 21, 2021 at 7:36 AM Michael Matz wrote: > > Hello, > > On Thu, 17 Jun 2021, H.J. Lu via Gcc wrote: > > > > > • Disallow copy relocation against definition with the STV_PROTECTED > > > > visibility in the shared library with the marker. > >

Re: [llvm-dev] RFC: Add GNU_PROPERTY_1_NEEDED

On Fri, Jun 18, 2021 at 2:34 PM Fangrui Song wrote: > > On 2021-06-18, H.J. Lu via llvm-dev wrote: > >Add GNU_PROPERTY_1_NEEDED: > > > > #define GNU_PROPERTY_1_NEEDED GNU_PROPERTY_UINT32_OR_LO > > > >to indicate the needed properties by the object file. > > > > I am fine with this logical OR

RFC: Add GNU_PROPERTY_1_NEEDED

Add GNU_PROPERTY_1_NEEDED: #define GNU_PROPERTY_1_NEEDED GNU_PROPERTY_UINT32_OR_LO to indicate the needed properties by the object file. Add GNU_PROPERTY_1_NEEDED_SINGLE_GLOBAL_DEFINITION: #define GNU_PROPERTY_1_NEEDED_SINGLE_GLOBAL_DEFINITION (1U << 0) to indicate that the object file

Re: [llvm-dev] RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX

On Thu, Jun 17, 2021 at 5:49 PM Fāng-ruì Sòng wrote: > > On Thu, Jun 17, 2021 at 5:24 PM H.J. Lu wrote: > > > > On Thu, Jun 17, 2021 at 5:06 PM Fāng-ruì Sòng wrote: > > > > > > On 2021-06-17, H.J. Lu wrote: > > > >On Thu, Jun 17, 2021 at 1:25 PM Fāng-ruì Sòng wrote: > > > >> > > > >> On Thu, Ju

Re: [llvm-dev] RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX

On Thu, Jun 17, 2021 at 5:49 PM Fāng-ruì Sòng wrote: > > On Thu, Jun 17, 2021 at 5:24 PM H.J. Lu wrote: > > > > On Thu, Jun 17, 2021 at 5:06 PM Fāng-ruì Sòng wrote: > > > > > > On 2021-06-17, H.J. Lu wrote: > > > >On Thu, Jun 17, 2021 at 1:25 PM Fāng-ruì Sòng wrote: > > > >> > > > >> On Thu, Ju

Re: [llvm-dev] RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX

On Thu, Jun 17, 2021 at 5:06 PM Fāng-ruì Sòng wrote: > > On 2021-06-17, H.J. Lu wrote: > >On Thu, Jun 17, 2021 at 1:25 PM Fāng-ruì Sòng wrote: > >> > >> On Thu, Jun 17, 2021 at 12:46 PM H.J. Lu wrote: > >> > > >> > On Thu, Jun 17, 2021 at 12:38 PM Fangrui Song wrote: > >> > > > >> > > On 2021-0

Re: [llvm-dev] RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX

On Thu, Jun 17, 2021 at 1:25 PM Fāng-ruì Sòng wrote: > > On Thu, Jun 17, 2021 at 12:46 PM H.J. Lu wrote: > > > > On Thu, Jun 17, 2021 at 12:38 PM Fangrui Song wrote: > > > > > > On 2021-06-17, H.J. Lu via llvm-dev wrote: > > > >On Thu, Jan 21, 2021 at 7:02 AM H.J. Lu wrote: > > > >> > > > >> On

Re: [llvm-dev] RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX

On Thu, Jun 17, 2021 at 12:38 PM Fangrui Song wrote: > > On 2021-06-17, H.J. Lu via llvm-dev wrote: > >On Thu, Jan 21, 2021 at 7:02 AM H.J. Lu wrote: > >> > >> On Wed, Jan 13, 2021 at 9:06 AM H.J. Lu wrote: > >> > > >> > 1. GNU_PROPERTY_UINT32_AND_LO..GNU_PROPERTY_UINT32_AND_HI > >> > > >> > #d

Re: RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX

On Thu, Jan 21, 2021 at 7:02 AM H.J. Lu wrote: > > On Wed, Jan 13, 2021 at 9:06 AM H.J. Lu wrote: > > > > 1. GNU_PROPERTY_UINT32_AND_LO..GNU_PROPERTY_UINT32_AND_HI > > > > #define GNU_PROPERTY_UINT32_AND_LO 0xb000 > > #define GNU_PROPERTY_UINT32_AND_HI 0xb0007fff > > > > A bit in the output

Re: [EXTERNAL] Re: 64-bit integer typedef's and -fpic lead to infinite loop and growing memory use in port to x86-32

On Fri, May 28, 2021 at 12:42 PM Barnes, Richard wrote: > > Unfortunately, our OS is only a 32-bit OS. It's ABI is only a 32-bit ABI. As > you imply, if we had a 64-bit OS, we would have more registers and more > memory and would probably avoid this problem. Also, libgcc2.c is supposed to > be

Re: 64-bit integer typedef's and -fpic lead to infinite loop and growing memory use in port to x86-32

On Fri, May 28, 2021 at 12:10 PM Barnes, Richard wrote: > > We are porting gcc-10.2.0 to a proprietary OS called VOS with a POSIX API > that runs on x86-32. We are using a prior port of gcc-3.4.6 to build the port > natively. When the build gets to the point where it compiles libgcc2.c with > t

Re: RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX

On Sat, Apr 17, 2021 at 11:25 AM Fangrui Song wrote: > > > On 2021-04-17, H.J. Lu wrote: > >On Thu, Jan 21, 2021 at 1:42 PM Fangrui Song wrote: > >> > >> On 2021-01-21, H.J. Lu via Gnu-gabi wrote: > >> >On Wed, Jan 13, 2021 at 9:06 AM H.J. Lu wrote: > >> >> > >> >> 1. GNU_PROPERTY_UINT32_AND_LO.

Re: RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX

On Thu, Jan 21, 2021 at 1:42 PM Fangrui Song wrote: > > On 2021-01-21, H.J. Lu via Gnu-gabi wrote: > >On Wed, Jan 13, 2021 at 9:06 AM H.J. Lu wrote: > >> > >> 1. GNU_PROPERTY_UINT32_AND_LO..GNU_PROPERTY_UINT32_AND_HI > >> > >> #define GNU_PROPERTY_UINT32_AND_LO 0xb000 > >> #define GNU_PROPE

Re: Has FSF stopped processing copyright paperwork?

On Fri, Aug 14, 2020 at 8:25 AM Kaylee Blake wrote: > > On 7/8/20 10:41 pm, H.J. Lu wrote: > > On Tue, May 5, 2020 at 6:42 PM Kaylee Blake wrote: > >> > >> On 2/5/20 11:49 pm, H.J. Lu wrote: > >>> On Wed, Mar 18, 2020 at 6:46 PM Kaylee Blake via Binutils > >>> wrote: > > On 19/3/20 12:

Re: A weird bug

On Thu, Mar 4, 2021 at 3:18 PM Gary Oblock via Gcc wrote: > > Guys, > > I've been trying to debug a linker error (which I thought was a bug in > my optimization.) Well it turns out it occurs in a brand new virgin > version of the compiler running with binutils 2.36 which is the latest > version. I

Re: [RFC 9/9] x86/mm: Implement PR_SET/GET_TAGGED_ADDR_CTRL with LAM

On Fri, Feb 5, 2021 at 7:16 AM Kirill A. Shutemov wrote: > > Provide prctl() interface to enabled LAM for user addresses. Depending > how many tag bits requested it may result in enabling LAM_U57 or > LAM_U48. I prefer the alternate kernel interface based on CET arch_prctl interface which is impl

Re: RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX

On Wed, Jan 13, 2021 at 9:06 AM H.J. Lu wrote: > > 1. GNU_PROPERTY_UINT32_AND_LO..GNU_PROPERTY_UINT32_AND_HI > > #define GNU_PROPERTY_UINT32_AND_LO 0xb000 > #define GNU_PROPERTY_UINT32_AND_HI 0xb0007fff > > A bit in the output pr_data field is set only if it is set in all > relocatable input

Re: Should GCC provide __builtin_memcpy_inline like clang does?

On Tue, Jan 19, 2021 at 6:44 PM Gabriel Ravier via Gcc wrote: > > On 1/19/21 12:33 PM, unlvsur unlvsur via Gcc wrote: > > I think __builtin_memmove_inline, __builtin_memset_inline can also get > > provided. > > > > That allows better performance for small size copies > > Manual tweaking like that

Re: Building gcc for C and C++ with a custom glibc

On Sun, Jan 17, 2021 at 1:06 PM Tom Honermann via Gcc wrote: > > Hi all. I've been trying to build a custom gcc (trunk) with a custom > glibc (trunk) with support for C and C++ on x86_64 Linux and have so far > been unsuccessful at identifying a sequence of configure/make > invocations that compl

RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX

1. GNU_PROPERTY_UINT32_AND_LO..GNU_PROPERTY_UINT32_AND_HI #define GNU_PROPERTY_UINT32_AND_LO 0xb000 #define GNU_PROPERTY_UINT32_AND_HI 0xb0007fff A bit in the output pr_data field is set only if it is set in all relocatable input pr_data fields. If all bits in the the output pr_data field

Re: Add -fdirect-access-external-data

On Thu, Jan 7, 2021 at 7:45 PM Fangrui Song wrote: > > On Thu, Jan 7, 2021 at 6:07 PM H.J. Lu wrote: > > > > On Wed, Jan 6, 2021 at 10:32 PM Fangrui Song wrote: > > > > > > On Sat, Dec 26, 2020 at 7:39 AM H.J. Lu wrote: > > > > > > > > On Sat, Dec 26, 2020 at 7:32 AM Florian Weimer > > > > wr

Re: Add -fdirect-access-external-data

On Wed, Jan 6, 2021 at 10:32 PM Fangrui Song wrote: > > On Sat, Dec 26, 2020 at 7:39 AM H.J. Lu wrote: > > > > On Sat, Dec 26, 2020 at 7:32 AM Florian Weimer wrote: > > > > > > * Fangrui Song: > > > > > > > Hi, I filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98112 which > > > > proposes -fd

Re: More consistency for Git log messages?

On Wed, Dec 30, 2020 at 6:21 AM Segher Boessenkool wrote: > > On Tue, Dec 29, 2020 at 12:54:53AM +0100, Gerald Pfeifer wrote: > > Having spent a bit more time with GCC sources (as opposed to wwwdocs) > > recently and looking for prior art to guide me, I noticed there's a > > lot of options to spec

Re: Add -fdirect-access-external-data

On Sat, Dec 26, 2020 at 7:32 AM Florian Weimer wrote: > > * Fangrui Song: > > > Hi, I filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98112 which > > proposes -fdirect-access-external-data to address some x86-64 > > GCC/binutils pain[1] and also benefit non-x86 architectures (also see [1] > > i

Re: [EXTERNAL] Re: DWARF Debug Info Relocations (.debug_str STRP references)

On Mon, Nov 30, 2020 at 6:41 PM Mark Wielaard wrote: > > Hi Bill, > > On Mon, Nov 30, 2020 at 10:22:34PM +, Bill Messmer wrote: > > > I'm still a bit confused here. And the reason I ask this is because > > I open this particular vmlinux image with an OSS ELF/DWARF > > library... which gives

Re: Cron sh /home/gccadmin/scripts/update_version_git

On Tue, Nov 24, 2020 at 5:19 PM Joseph Myers wrote: > > On Wed, 25 Nov 2020, (Cron Daemon) via Gccadmin wrote: > > > === Working on: master === > > branch pulled and checked out > > 61 revisions since last Daily bump > > Traceback (most recent call last): > > File "../gcc-changelog/git_update_ve

Re: broken check: You should edit tm.texi.in rather than tm.texi

On Fri, Nov 20, 2020 at 7:26 AM Martin Liška wrote: > > On 11/20/20 2:42 PM, H.J. Lu wrote: > > Should contrib/gcc_update handle it? > > I don't know how publicly known is the script? > I personally do not used it. > I always run $ ./contrib/gcc_update --touch after rebase. -- H.J.

Re: broken check: You should edit tm.texi.in rather than tm.texi

On Fri, Nov 20, 2020 at 5:24 AM Martin Liška wrote: > > Hello. > > I hit the following issue: > /bin/sh /home/marxin/Programming/gcc/gcc/../move-if-change tmp-tm.texi tm.texi > You should edit /home/marxin/Programming/gcc/gcc/doc/tm.texi.in rather than > /home/marxin/Programming/gcc/gcc/doc/tm.te

Re: Detect EAF flags in ipa-modref

On Fri, Nov 13, 2020 at 12:07 AM Richard Biener wrote: > > On Tue, 10 Nov 2020, Jan Hubicka wrote: > > > Hi, > > here is updaed patch. > > > > Honza > > > > Bootstrapped/regtested x86_64-linux, OK (after the fnspec fixes)? > > OK. > > Thanks, > Richard. > This caused: https://gcc.gnu.org/bugzill

Re: Clobber REG_CC only for some constraint alternatives?

On Thu, Aug 20, 2020 at 1:53 AM Andrew Stubbs wrote: > > On 20/08/2020 06:40, Senthil Kumar Selvaraj via Gcc wrote: > > What I didn't understand was the (set-attr "cc") > > part - as far I can tell, this results in (set_attr "cc_enabled" ...) in > > all of the three substituted patterns, so I wond

Re: Changes to allow PowerPC to change the long double type to use the IEEE 128-bit floating point format

On Fri, Aug 7, 2020 at 1:57 PM Michael Meissner via Gcc wrote: > > I want to discuss changes that I think we need to make across the open source > toochain to allow us to change the long double type on PowerPC hardware from > using the IBM extended double (i.e. a pair of doubles) to the IEEE 128-b

Has FSF stopped processing copyright paperwork?

On Tue, May 5, 2020 at 6:42 PM Kaylee Blake wrote: > > On 2/5/20 11:49 pm, H.J. Lu wrote: > > On Wed, Mar 18, 2020 at 6:46 PM Kaylee Blake via Binutils > > wrote: > >> > >> On 19/3/20 12:02 pm, H.J. Lu wrote: > >>> Kaylee, is your paper work with FSF in order? I will submit the updated > >>> patc

[x86-64 psABI] RFC: Document Intel AMX

Intel Advanced Matrix Extensions (Intel AMX) is a new programming paradigm consisting of two components: a set of 2-dimensional registers (tiles) representing sub-arrays from a larger 2-dimensional memory image, and accelerators able to operate on tiles. Capability of Intel AMX implementation is en

Re: New x86-64 micro-architecture levels

On Thu, Jul 23, 2020 at 5:44 AM Michael Matz wrote: > > Hello, > > On Wed, 22 Jul 2020, Mallappa, Premachandra wrote: > > > > That's deliberate, so that we can use the same x86-* names for 32-bit > > > library selection (once we define matching micro-architecture levels > > > there). > > > > Und

Re: New x86-64 micro-architecture levels

On Wed, Jul 22, 2020 at 6:50 AM Richard Biener via Libc-alpha wrote: > > On Wed, Jul 22, 2020 at 12:16 PM Florian Weimer wrote: > > > > * Richard Biener: > > > > > On Wed, Jul 22, 2020 at 10:58 AM Florian Weimer via Gcc > > > wrote: > > >> > > >> * Dongsheng Song: > > >> > > >> > I fully agree

Re: New x86-64 micro-architecture levels

On Wed, Jul 15, 2020 at 7:38 AM Mark Wielaard wrote: > > Hi Florian, > > I understand you want to discuss the x86_64 micro-architecture levels > only in this thread, but it would be nice to have a similar discussion > for other architectures. > > One thing that wasn't clear to me from this proposa

Re: New x86-64 micro-architecture levels

On Mon, Jul 13, 2020 at 12:48 AM Jan Beulich wrote: > > On 13.07.2020 09:40, Florian Weimer wrote: > > * Richard Biener: > >>> 2. I have a library with AVX2 and FMA, which directory should it go? > >> > >> Eventually GCC/gas can annotate objects with the lowest architecture > >> level that is appl

Re: New x86-64 micro-architecture levels

On Sun, Jul 12, 2020 at 11:49 PM Florian Weimer wrote: > > * H. J. Lu: > > > Looks good. I like it. > > Thanks. What do you think about Level B? Should we keep it? Please drop Level B. > > My only concerns are > > > > 1. Names like “x86-100”, “x86-101”, what features do they support? > > I th

Re: New x86-64 micro-architecture levels

On Fri, Jul 10, 2020 at 10:30 AM Florian Weimer wrote: > > 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 loadi

Re: Push to my private branches is disallowed

On Mon, Jun 15, 2020 at 10:43 AM Segher Boessenkool wrote: > > Hi Joseph, > > Thanks, good to hear things will get better. > > On Mon, Jun 15, 2020 at 05:19:13PM +, Joseph Myers wrote: > > > It should never send email for user branches *at all*. > > > > I think sending email for all branches s

Re: Stepping down as x86 vector ISA maintainer

On Wed, Jun 3, 2020 at 12:25 AM Uros Bizjak wrote: > > I would like to inform GCC community, that I decided to step down from > maintaining x86 vector ISA part. x86 vector ISA has its own > non-responsive maintainer, but I have filled the maintainers role > nevertheless, until gcc-10 was released.

Is commit hook broken?

On Wed, May 20, 2020 at 7:23 AM Martin Liška wrote: > > On 5/20/20 3:57 PM, H.J. Lu wrote: > > On Wed, May 20, 2020 at 6:55 AM Martin Liška wrote: > >> > >> On 5/20/20 3:48 PM, H.J. Lu wrote: > >>> On Wed, May 20, 2020 at 6:47 AM Martin Liška wrote: > > On 5/20/20 1:31 PM, H.J. Lu wrot

Re: Commit hook for cherry-pick commit

On Wed, May 20, 2020 at 6:55 AM Martin Liška wrote: > > On 5/20/20 3:48 PM, H.J. Lu wrote: > > On Wed, May 20, 2020 at 6:47 AM Martin Liška wrote: > >> > >> On 5/20/20 1:31 PM, H.J. Lu wrote: > >>> On Wed, May 20, 2020 at 1:40 AM Martin Liška wrote: > > On 5/20/20 12:59 AM, H.J. Lu wro

Re: Commit hook for cherry-pick commit

On Wed, May 20, 2020 at 6:47 AM Martin Liška wrote: > > On 5/20/20 1:31 PM, H.J. Lu wrote: > > On Wed, May 20, 2020 at 1:40 AM Martin Liška wrote: > >> > >> On 5/20/20 12:59 AM, H.J. Lu wrote: > >>> I got: > >>> > >>> $ git push origin releases/gcc-10 > >>> Enumerating objects: 15, done. > >>> Co

Re: Commit hook for cherry-pick commit

On Wed, May 20, 2020 at 1:40 AM Martin Liška wrote: > > On 5/20/20 12:59 AM, H.J. Lu wrote: > > I got: > > > > $ git push origin releases/gcc-10 > > Enumerating objects: 15, done. > > Counting objects: 100% (15/15), done. > > Delta compression using up to 8 threads > > Compressing objects: 100% (6

Commit hook for cherry-pick commit

I got: $ git push origin releases/gcc-10 Enumerating objects: 15, done. Counting objects: 100% (15/15), done. Delta compression using up to 8 threads Compressing objects: 100% (6/6), done. Writing objects: 100% (8/8), 1.15 KiB | 1.15 MiB/s, done. Total 8 (delta 7), reused 2 (delta 2), pack-reused

Re: Automatically generated ChangeLog files - script

On Mon, May 4, 2020 at 12:24 PM Tobias Burnus wrote: > > On 5/4/20 9:05 PM, Jakub Jelinek via Gcc wrote: > > On Mon, May 04, 2020 at 08:56:16PM +0200, Martin Liška wrote: > >> What's missing right now is how will we declare a Backport format. > >> Can we just use something like: 'Backport from >

Re: Broken check rejecting -fcf-protection and -mindirect-branch=thunk-extern

On Tue, Apr 28, 2020 at 10:24 AM David Woodhouse wrote: > > > > On 28 April 2020 17:14:49 BST, Peter Zijlstra wrote: > >On Tue, Apr 28, 2020 at 02:41:33PM +0100, Andrew Cooper wrote: > >> Its fine to focus on userspace first, but the kernel is far more > >simple. > >> > >> Looking at that present

Re: Broken check rejecting -fcf-protection and -mindirect-branch=thunk-extern

On Tue, Apr 28, 2020 at 9:33 AM Andy Lutomirski wrote: > > > > > > On Apr 28, 2020, at 9:14 AM, Peter Zijlstra wrote: > > > > On Tue, Apr 28, 2020 at 02:41:33PM +0100, Andrew Cooper wrote: > >> Its fine to focus on userspace first, but the kernel is far more simple. > >> > >> Looking at that pre

Re: Broken check rejecting -fcf-protection and -mindirect-branch=thunk-extern

On Tue, Apr 28, 2020 at 8:06 AM Jan Beulich wrote: > > On 28.04.2020 17:00, H.J. Lu wrote: > > On Tue, Apr 28, 2020 at 6:41 AM Andrew Cooper > > wrote: > >> > >> On 28/04/2020 14:00, H.J. Lu wrote: > >>> On Tue, Apr 28, 2020 at 5:43 AM Andrew Cooper > >>> wrote: > Hello, > > I r

Re: Broken check rejecting -fcf-protection and -mindirect-branch=thunk-extern

On Tue, Apr 28, 2020 at 6:41 AM Andrew Cooper wrote: > > On 28/04/2020 14:00, H.J. Lu wrote: > > On Tue, Apr 28, 2020 at 5:43 AM Andrew Cooper > > wrote: > >> Hello, > >> > >> I raised https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93654 but it has > >> had nothing but tumbleweeds in months, and i

Re: Changes dueto server migration

On Tue, Mar 24, 2020 at 11:02 AM Gunther Nikl wrote: > > Dear GCC developers! > > I just noticed that the server migration for GCC and sourceware.org > brought a surprising change: The list archives are now provided with > mailman. Maybe its only me, but IMO with this change the list archives Sam

Re: Spam, bounces and gcc list removal

On Sat, Mar 21, 2020 at 12:40 PM Thomas Koenig via Gcc wrote: > > Hi, > > > since the change to the new list management, there has been > > an uptick of spam getting through. Spam is bounced by my ISP, > > and this just resulted in a warning that there were too many > > bounces and that I would ge