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
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,
> >
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.
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
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'
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
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
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: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
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.
> >
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
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 gene
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
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
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
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
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
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.
> >
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.
&g
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
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 P
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 P
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 1
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:
> > > &g
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.
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_AN
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
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
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:
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
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
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
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
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
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
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
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
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 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.
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
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
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
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
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.
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
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
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
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
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 w
3061010906291cd2722dc9a407dd8afe454459a5 Mon Sep 17 00:00:00 2001
From: "H.J. Lu"
Date: Wed, 6 May 2020 17:25:38 -0700
Subject: [PATCH] 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) re
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
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
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
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
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
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
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
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.
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 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 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:
> >>>
> >>> $ g
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
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
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
>
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
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
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 Coo
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
&g
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
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
X86 GCC automated testers are back online. They bootstrap and run
testsuite for master
branch and the current 2 release branches on Linux/x86-64 and Linux/i686:
https://gcc.gnu.org/pipermail/gcc-testresults/2020-March/555912.html
https://gcc.gnu.org/pipermail/gcc-testresults/2020-March/555909.ht
On Wed, Mar 4, 2020 at 5:01 AM Jakub Jelinek wrote:
>
> On Wed, Mar 04, 2020 at 04:52:20AM -0800, H.J. Lu wrote:
> > I saw these new failures on Fedora 31:
> >
> > FAIL: 22_locale/numpunct/members/char/3.cc execution test
> > FAIL: 22_locale/time_get/get_time/cha
On Wed, Mar 4, 2020 at 2:30 AM Jakub Jelinek wrote:
>
> Status
> ==
>
> GCC 8.4 has been released and the branch is again open for regression
> and documentation fixes. History makes us expect a GCC 8.5 release
> in fall of this year and it will be the last release from the GCC 8
> series.
>
On Mon, Mar 2, 2020 at 3:46 AM Jakub Jelinek wrote:
>
> On Mon, Mar 02, 2020 at 03:41:06AM -0800, H.J. Lu wrote:
> > On Mon, Mar 2, 2020 at 2:46 AM Jakub Jelinek wrote:
> > >
> > > The second release candidate for GCC 8.4 is available from
> > >
> > &
elease 8.4 on Wednesday, March 4th.
>
I'd like to backport:
commit r10-6965-g577350603a657590c4b54a4a966cb49497e2514c
Author: H.J. Lu
Date: Mon Mar 2 03:08:57 2020 -0800
lto: Also copy .note.gnu.property section
When generating the separate file with LTO debug sections, we s
On Fri, Feb 28, 2020 at 5:42 AM Jakub Jelinek wrote:
>
> Status
> ==
>
> GCC 9.2 has been released more than half a year ago and it is time
> for another release from the latest stable branch. Many people have
> backported their fixes to 9 branch recently already, often together
> with backpo
On Tue, Feb 4, 2020 at 2:03 PM Bill Schmidt wrote:
>
> I'm having a little difficulty with my workflow, and I'm hoping someone
> can spot the problem.
>
> I have a user branch set up with the contrib/git-add-user-branch.sh
> script. Here are the relevant portions of my .git/config:
>
> [remote "u
On Fri, Jan 24, 2020 at 2:39 PM Paul Smith wrote:
>
> On Fri, 2020-01-24 at 22:45 +0100, Jakub Jelinek wrote:
> > > > In my experience the output of git log is a total mess so cannot
> > > > replace ChangeLogs. But we can well decide to drop ChangeLog for
> > > > the testsuite.
> > >
> > > Well,
On Fri, Apr 5, 2019 at 12:55 PM Martin Sebor wrote:
>
> Is it safe to rerun make bootstrap after changing GCC source?
>
> Say if the first bootstrap succeeds and I then change a single
> GCC .c file and rerun make bootstrap, am I guaranteed to see
> the same fallout of the change as I would if I d
On Sat, Feb 9, 2019 at 1:12 AM Jakub Jelinek wrote:
>
> Status
> ==
>
> Both GCC 8.3 P1s we had yesterday were fixed, so let's aim for the first
> release candidate of 8.3 on February, 15th and, if all goes well, for
> 8.3 release on February, 22nd.
>
This is a new C++ regression on GCC 8 bra
On Sat, Jan 19, 2019 at 11:23 AM Wojciech Muła
wrote:
>
> Hi all!
>
> One thing I miss in GCC is lack of support for the AVX512 ternary logic
> instruction VPTERNLOG. This instruction evaluates any three-argument logic
> function; this means that an expression like "a | b & ~c" can be folded into
In Tue, Oct 30, 2018 at 4:28 AM Iain Sandoe wrote:
>
> Hi,
>
> For a processor that supports SSE, but not AVX.
>
> the following code:
>
> typedef int __attribute__((mode(QI))) qi;
> typedef qi __attribute__((vector_size (32))) v32qi;
>
> v32qi foo (int x)
> {
> v32qi y = {'0','1','2','3','4','5
On Thu, Sep 13, 2018 at 6:27 AM, Wilco Dijkstra wrote:
> Hi,
>
> The existing sincos functions use 2 pointers to return the sine and cosine
> result. In
> most cases 4 memory accesses are necessary per call. This is inefficient and
> often
> significantly slower than returning values in register
On Wed, Apr 18, 2018 at 3:34 AM, Jakub Jelinek wrote:
> On Wed, Apr 18, 2018 at 12:30:03PM +0200, Richard Biener wrote:
>> On Wed, 18 Apr 2018, Uros Bizjak wrote:
>>
>> > Hello!
>> >
>> > Currently, CET is enabled by default for linux if target supports
>> > multi-byte NOPs and if assembler suppor
On Tue, Mar 27, 2018 at 8:55 AM, H.J. Lu wrote:
> On Tue, Mar 27, 2018 at 8:43 AM, Florian Weimer wrote:
>> On 03/27/2018 01:26 PM, H.J. Lu wrote:
>>
>>> 2. Since shadow stack is never saved and restored by compiler, unwinder
>>> in libgcc counts how many stac
On Tue, Mar 27, 2018 at 8:43 AM, Florian Weimer wrote:
> On 03/27/2018 01:26 PM, H.J. Lu wrote:
>
>> 2. Since shadow stack is never saved and restored by compiler, unwinder
>> in libgcc counts how many stack frame it has to unwind and uses INCSSP
>> to pop shadow stack
On Tue, Mar 27, 2018 at 6:32 AM, Richard Biener wrote:
>
> Status
> ==
>
> The GCC 8 trunk is open for regression and documentation fixes. Following
> past releases we are aiming at a first release candidate mid April though
> if you look at the quality data below that looks ambitious.
>
> So
On Mon, Mar 26, 2018 at 11:31 PM, Florian Weimer wrote:
> On 03/27/2018 12:43 AM, H.J. Lu wrote:
>>
>> On Linux, when alternate signal stack is used with thread cancellation,
>> _Unwind_Resume fails when it tries to unwind shadow stack from signal
>> handler on alterna
On Linux, when alternate signal stack is used with thread cancellation,
_Unwind_Resume fails when it tries to unwind shadow stack from signal
handler on alternate signal stack. The issue is that signal handler on
alternate signal stack uses a separate shadow stack and we must switch
to the origina
On Thu, Mar 22, 2018 at 11:08 AM, Steve Ellcey wrote:
> I have a question about the math vector library routines in libmvec.
> If I compile a program on x86 with -Ofast, something like:
>
> void foo(double * __restrict x, double * __restrict y, double * __restrict z)
> {
> for (int i = 0;
On Wed, Jan 31, 2018 at 7:56 AM, H.J. Lu wrote:
> On Wed, Jan 31, 2018 at 7:44 AM, Cory Fields wrote:
>> After looking at this for quite a while, I'm afraid I'm unsure how to
>> proceed.
>>
>> As of now, static and static-pie
On Wed, Jan 31, 2018 at 7:44 AM, Cory Fields wrote:
> After looking at this for quite a while, I'm afraid I'm unsure how to proceed.
>
> As of now, static and static-pie are mutually exclusive. So given the
> GNU_USER_TARGET_STARTFILE_SPEC you pasted
> earlier, "static" matches before "static-pie"
On Tue, Jan 30, 2018 at 11:18 AM, Cory Fields wrote:
> On Tue, Jan 30, 2018 at 2:14 PM, H.J. Lu wrote:
>> On Tue, Jan 30, 2018 at 11:07 AM, Cory Fields wrote:
>>> On Tue, Jan 30, 2018 at 1:35 PM, H.J. Lu wrote:
>>>> On Tue, Jan 30, 2018 at 10:26 AM, Cor
On Tue, Jan 30, 2018 at 11:07 AM, Cory Fields wrote:
> On Tue, Jan 30, 2018 at 1:35 PM, H.J. Lu wrote:
>> On Tue, Jan 30, 2018 at 10:26 AM, Cory Fields wrote:
>>> Hi list
>>>
>>> I'm playing with -static-pie and musl, which seems to be in good shape
&g
On Tue, Jan 30, 2018 at 10:26 AM, Cory Fields wrote:
> Hi list
>
> I'm playing with -static-pie and musl, which seems to be in good shape
> for 8.0.0. Nice work :)
>
> However, the fact that "gcc -static -pie" and "gcc -static-pie"
> produce different results is very unexpected. I understand the c
On Fri, Jan 26, 2018 at 1:52 PM, Martin Sebor wrote:
> On 01/22/2018 11:08 AM, Frank Ch. Eigler wrote:
>>
>> Hi -
>>
>>> Problems are still occurring for me; Bugzilla gives me 504 Gateway
>>> Time-outs when I try to access it tonight...
>>
>>
>> OK, we reworked some of the database routine mainten
n symbol,
There is no need for PLT since hidden symbol is defined locally. But
GCC ignores hidden visibility for libcalls, like memcpy. If GCC treats
them like normal calls, your scheme and my testcase should work.
> But anyway, doesn't matter terribly much if I understand :p
>
>
On Fri, Jan 26, 2018 at 12:29 PM, Tom Mason wrote:
> Hi,
> I've got a project here: https://github.com/wheybags/glibc_version_header
> which uses .symver directives to link to a specified version of glibc, so
> long as it's older than the version on your system.
> This works, but a problem I'm hav
On Thu, Jan 25, 2018 at 12:32 AM, Florian Weimer wrote:
> On 01/22/2018 01:21 PM, Florian Weimer wrote:
>
>> There is a different issue with the think itself.
>>
>> __x86_indirect_thunk_rax:
>> .LFB2:
>> .cfi_startproc
>> call.LIND5
>> .LIND4:
>> pause
>> lf
On Mon, Jan 22, 2018 at 4:21 AM, Florian Weimer wrote:
> I tried this:
>
> struct C {
> virtual ~C();
> virtual void f();
> };
>
> void
> f (C *p)
> {
> p->f();
> p->f();
> }
>
> with r256939 and -mindirect-branch=thunk -O2 on x86-64 GNU/Linux, and got
> this:
>
> _Z1fP1C:
> .LFB0:
>
1 - 100 of 1202 matches
Mail list logo
