Re: [PATCH] libgfortran: Disable gthreads weak symbols for glibc 2.34

On Tue, Apr 9, 2024 at 10:25 AM Andrew Pinski wrote: > > > > On Tue, Apr 9, 2024, 10:07 H.J. Lu wrote: >> >> Since Glibc 2.34 all pthreads symbols are defined directly in libc not >> libpthread, and since Glibc 2.32 we have used __libc_single_threaded to >>

Re: [PATCH v7] libgfortran: Replace mutex with rwlock

On Sat, Dec 9, 2023 at 7:25 PM Zhu, Lipeng wrote: > > On 2023/12/9 23:23, Jakub Jelinek wrote: > > On Sat, Dec 09, 2023 at 10:39:45AM -0500, Lipeng Zhu wrote: > > > This patch try to introduce the rwlock and split the read/write to > > > unit_root tree and unit_cache with rwlock instead of the

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

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'

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

Re: [PATCH] libgfortran: Replace mutex with rwlock

On Sun, Dec 25, 2022 at 4:58 PM Steve Kargl via Gcc-patches wrote: > > On Wed, Dec 21, 2022 at 07:27:11PM -0500, Lipeng Zhu via Fortran wrote: > > This patch try to introduce the rwlock and split the read/write to > > unit_root tree and unit_cache with rwlock instead of the mutex to > > increase

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

Re: [PATCH, Fortran] Skip gfortran.dg/PR100914.f90 on targets that don't provide quadmath.h

On Sun, Sep 5, 2021 at 11:02 AM Sandra Loosemore wrote: > > On 9/5/21 7:31 AM, H.J. Lu wrote: > > On Sat, Sep 4, 2021 at 7:31 PM Sandra Loosemore > > wrote: > >> > >> The testcase gfortran.dg/PR100914.f90 that I recently checked in > >> (originally w

Re: [PATCH, Fortran] Skip gfortran.dg/PR100914.f90 on targets that don't provide quadmath.h

On Sat, Sep 4, 2021 at 7:31 PM Sandra Loosemore wrote: > > The testcase gfortran.dg/PR100914.f90 that I recently checked in > (originally written by José Rui Faustino de Sousa) depends on the > header file to obtain a typedef for __complex128. It > appears not to be possible to define an

Re: [r12-3321 Regression] FAIL: gfortran.dg/PR100914.f90 -Os (test for excess errors) on Linux/x86_64

On Fri, Sep 3, 2021 at 10:25 AM Sandra Loosemore wrote: > > On 9/2/21 11:37 PM, Sandra Loosemore wrote: > > On 9/2/21 10:18 PM, sunil.k.pandey wrote: > >> On Linux/x86_64, > >> > >> 93b6b2f614eb692d1d8126ec6cb946984a9d01d7 is the first bad commit > >> commit

Re: [PATCH] PR fortran/100950 - ICE in output_constructor_regular_field, at varasm.c:5514

On Thu, Aug 19, 2021 at 12:12 PM Harald Anlauf via Gcc-patches wrote: > > Hi Tobias, > > > I am inclined to say that the Intel compiler has a bug by not > > accepting it – but as written before, I regard sub-string length > > (esp. with const expr) inquiries as an odd corner case which > > is