Re: [PATCH] Improve location for new statements in match-and-simplify phiopt

2021-12-18 Thread Richard Biener via Gcc-patches
On December 18, 2021 11:56:48 PM GMT+01:00, apinski--- via Gcc-patches wrote: >From: Andrew Pinski > >Before match-and-simplify was used in phiot, the location of the >new stamtents were all of that of the conditional, this adds that >back as I did not realize gimple_simplify didn't do that for

Re: [PATCH v3 06/12] LoongArch Port: Builtin macros.

2021-12-18 Thread Paul Hua via Gcc-patches
Hi Ruoyao, Thank you for your attention. > GCC 12 development cycle is at stage 3 (general bugfixing) now. So a > new port have to wait until stage 1 of GCC 13 begins (in mid 2022, I > guess). I know it is stage3, but we are a new target, it's ok for GCC 12.

Re: [PATCH] c++: Avoid narrowing in make_char_string_pack

2021-12-18 Thread Eric Gallager via Gcc-patches
On Fri, Dec 17, 2021 at 5:59 PM Marek Polacek via Gcc-patches wrote: > > This fixes > > gcc/cp/parser.c:4618:41: warning: narrowing conversion of '(char)(*(str + > ((sizetype)i)))' from 'char' to 'unsigned char' [-Wnarrowing] > 4618 | unsigned char s[3] = { '\'', str[i], '\'' }; > |

[PATCH] Improve location for new statements in match-and-simplify phiopt

2021-12-18 Thread apinski--- via Gcc-patches
From: Andrew Pinski Before match-and-simplify was used in phiot, the location of the new stamtents were all of that of the conditional, this adds that back as I did not realize gimple_simplify didn't do that for you. OK? Bootstrapped and tested on x86_64 with no regressions. gcc/ChangeLog:

[PATCH, committed] PR fortran/103412 - [10/11/12 Regression] ICE: Invalid expression in gfc_element_size since r10-2083-g8dc63166e0b85954

2021-12-18 Thread Harald Anlauf via Gcc-patches
Dear all, committed as obvious after discussion with Steve: SIZEOF() cannot accept a BOZ argument which has no defined type. Regtested on x86_64-pc-linux-gnu. Thanks, Harald From fd74a2ee40456a1d1621e88738f8e57536194080 Mon Sep 17 00:00:00 2001 From: Harald Anlauf Date: Sat, 18 Dec 2021

Re: [PATCH] config: Add check whether D compiler works (PR103528)

2021-12-18 Thread Segher Boessenkool
On Fri, Dec 17, 2021 at 12:12:28AM +0100, Iain Buclaw wrote: > Hi, > > This patch extends AC_PROG_GDC so that as well as checking for the > existence of a GDC compiler, also validate that it has also been built > with libphobos, otherwise warn or fail with the message that GDC is > required to

Re: [PATCH, rs6000] Implement mffscrni pattern

2021-12-18 Thread Segher Boessenkool
On Fri, Dec 17, 2021 at 10:33:12PM -0500, David Edelsohn wrote: > On Thu, Dec 16, 2021 at 9:43 PM HAO CHEN GUI wrote: > > +(define_insn "rs6000_mffscrni" > > + [(set (match_operand:DF 0 "gpc_reg_operand" "=d") > > + (unspec_volatile:DF [(match_operand:DF 1 "u2bit_cint_operand" "n")] > >

Re: [PATCH] config.gcc: Obsolete m32c-rtems target

2021-12-18 Thread Joel Sherrill
On Sat, Dec 18, 2021 at 10:13 AM Joel Sherrill wrote: > > > > On Fri, Dec 17, 2021, 9:57 PM Jeff Law wrote: >> >> >> >> On 12/17/2021 9:10 AM, Joel Sherrill wrote: >> > --- >> > gcc/config.gcc | 1 + >> > 1 file changed, 1 insertion(+) >> > >> > diff --git a/gcc/config.gcc b/gcc/config.gcc >>

Re: [PATCH v3 04/12] LoongArch Port: Machine description C files and .h files.

2021-12-18 Thread Xi Ruoyao via Gcc-patches
On Fri, 2021-12-10 at 15:43 +0800, Chenghua Xu wrote: > +#undef TARGET_ASM_CODE_END > +#define TARGET_ASM_CODE_END loongarch_code_end /* snip */ > +static void > +loongarch_code_end (void) > +{ > + if (NEED_INDICATE_EXEC_STACK) > +/* Add .note.GNU-stack. */ > +

Re: [PATCH] config.gcc: Obsolete m32c-rtems target

2021-12-18 Thread Joel Sherrill
On Fri, Dec 17, 2021, 9:57 PM Jeff Law wrote: > > > On 12/17/2021 9:10 AM, Joel Sherrill wrote: > > --- > > gcc/config.gcc | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/gcc/config.gcc b/gcc/config.gcc > > index c8824367b13..fe93a72a16c 100644 > > --- a/gcc/config.gcc > > +++

[PATCH v5 4/4] tree-object-size: Dynamic sizes for ADDR_EXPR

2021-12-18 Thread Siddhesh Poyarekar
Allow returning dynamic expressions from ADDR_EXPR for __builtin_dynamic_object_size and also allow offsets to be dynamic. gcc/ChangeLog: * tree-object-size.c (size_valid_p): New function. (size_for_offset): Remove OFFSET constness assertion. (addr_object_size): Build

[PATCH v5 3/4] tree-object-size: Handle GIMPLE_CALL

2021-12-18 Thread Siddhesh Poyarekar
Handle non-constant expressions in GIMPLE_CALL arguments. Also handle alloca. gcc/ChangeLog: * tree-object-size.c (alloc_object_size): Make and return non-constant size expression. (call_object_size): Return expression or unknown based on whether dynamic object

[PATCH v5 1/4] tree-object-size: Support dynamic sizes in conditions

2021-12-18 Thread Siddhesh Poyarekar
Handle GIMPLE_PHI and conditionals specially for dynamic objects, returning PHI/conditional expressions instead of just a MIN/MAX estimate. This makes the returned object size variable for loops and conditionals, so tests need to be adjusted to look for precise size in some cases.

[PATCH v5 2/4] tree-object-size: Handle function parameters

2021-12-18 Thread Siddhesh Poyarekar
Handle hints provided by __attribute__ ((access (...))) to compute dynamic sizes for objects. gcc/ChangeLog: * tree-object-size.c: Include tree-dfa.h. (parm_object_size): New function. (collect_object_sizes_for): Call it. gcc/testsuite/ChangeLog: *

[PATCH v5 0/4] __builtin_dynamic_object_size

2021-12-18 Thread Siddhesh Poyarekar
This patchset enhances the __builtin_dynamic_object_size builtin to produce dynamic expressions for object sizes to improve coverage of _FORTIFY_SOURCE. Testing: This series has been tested with build and test for i686, bootstrap with ubsan and full bootstrap and test with x86_64. I

Re: [patch] Future-proof and homogenise handling of darwin versions

2021-12-18 Thread FX via Gcc-patches
> Yes, but please put this ^^ explanation into the git commit log, and prepend > the title line with Darwin: Thanks, committed. FX

[PATCH v2] Disable -fsplit-stack support on non-glibc targets

2021-12-18 Thread soeren--- via Gcc-patches
From: Sören Tempel The -fsplit-stack option requires the pthread_t TCB definition in the libc to provide certain struct fields at specific hardcoded offsets. As far as I know, only glibc provides these fields at the required offsets. Most notably, musl libc does not have these fields. However,

Re: [PATCH] Disable -fsplit-stack support on non-glibc targets

2021-12-18 Thread Andrew Pinski via Gcc-patches
On Sat, Dec 18, 2021 at 3:13 AM Sören Tempel wrote: > > Andrew Pinski wrote: > > I think it should check OPTION_MUSL at runtime instead of > > TARGET_GLIBC_MAJOR at compile time. > > or rather opts->x_linux_libc == LIBC_MUSL > > The others should be done similarly too. > > Thanks for pointing

Re: [PATCH] Disable -fsplit-stack support on non-glibc targets

2021-12-18 Thread Sören Tempel via Gcc-patches
Andrew Pinski wrote: > I think it should check OPTION_MUSL at runtime instead of > TARGET_GLIBC_MAJOR at compile time. > or rather opts->x_linux_libc == LIBC_MUSL > The others should be done similarly too. Thanks for pointing this out, I wasn't aware of OPTION_MUSL and OPTION_GLIBC. However, I

Re: [PATCH] Disable -fsplit-stack support on non-glibc targets

2021-12-18 Thread Andrew Pinski via Gcc-patches
On Sat, Dec 18, 2021 at 2:44 AM soeren--- via Gcc-patches wrote: > > From: Sören Tempel > > The -fsplit-stack option requires the pthread_t TCB definition in the > libc to provide certain struct fields at specific hardcoded offsets. As > far as I know, only glibc provides these fields at the

[PATCH] Disable -fsplit-stack support on non-glibc targets

2021-12-18 Thread soeren--- via Gcc-patches
From: Sören Tempel The -fsplit-stack option requires the pthread_t TCB definition in the libc to provide certain struct fields at specific hardcoded offsets. As far as I know, only glibc provides these fields at the required offsets. Most notably, musl libc does not have these fields. However,

Re: [PATCH v3 06/12] LoongArch Port: Builtin macros.

2021-12-18 Thread Xi Ruoyao via Gcc-patches
On Fri, 2021-12-17 at 15:45 +0800, Paul Hua via Gcc-patches wrote: > Hi Joseph, > > Thanks for your suggestion, Those macros can be removed, we will send > the v4 version soon. > > Are there any problems in this series of patches? I'm not a compiler expert, but I'll bootstrap it once my 5th

Re: [PATCH v3] tree-optimization/103759: Use sizetype everywhere for object sizes

2021-12-18 Thread Jakub Jelinek via Gcc-patches
On Sat, Dec 18, 2021 at 12:24:48PM +0530, Siddhesh Poyarekar wrote: > Since all computations in tree-object-size are now done in sizetype and > not HOST_WIDE_INT, comparisons with HOST_WIDE_INT based unknown and > initval would be incorrect. Instead, use the sizetype trees directly to > generate

New Spanish PO file for 'cpplib' (version 11.1-b20210207)

2021-12-18 Thread Translation Project Robot
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'cpplib' has been submitted by the Spanish team of translators. The file is available at: https://translationproject.org/latest/cpplib/es.po (This file,

Contents of PO file 'cpplib-11.1-b20210207.es.po'

2021-12-18 Thread Translation Project Robot
cpplib-11.1-b20210207.es.po.gz Description: Binary data The Translation Project robot, in the name of your translation coordinator.