Re: [PATCH 1/2] Check negative combined step

On Tue, 25 Jan 2022, Jiufu Guo wrote: > Jiufu Guo writes: > > > Richard Biener writes: > > > >> On Thu, 13 Jan 2022, Jiufu Guo wrote: > > ... > >> > >>> - /* No need to check sign of the new step since below code takes > >>> care > >>> - of this well. */ > >>> + /* Like cases

Re: [PATCH 1/2] Check negative combined step

Jiufu Guo writes: > Richard Biener writes: > >> On Thu, 13 Jan 2022, Jiufu Guo wrote: > ... >> >>> - /* No need to check sign of the new step since below code takes care >>> -of this well. */ >>> + /* Like cases shown in PR100740/102131, negtive step is not safe. */ >>> +

Re: [PATCH 1/2] Check negative combined step

Richard Biener writes: > On Thu, 13 Jan 2022, Jiufu Guo wrote: ... > >> - /* No need to check sign of the new step since below code takes care >> - of this well. */ >> + /* Like cases shown in PR100740/102131, negtive step is not safe. */ >> + if (tree_int_cst_sign_bit

[PATCH] [rtl/cprop_hardreg] Don't propagate for a more expensive reg-reg move.

For i386, it enables optimization like: vmovd %xmm0, %edx - vmovd %xmm0, %eax + movl%edx, %eax Bootstrapped and regtested on CLX for both x86_64-pc-linux-gnu{-m32,} and x86_64-pc-linux-gnu{-m32\ -march=native,\ -march=native} Ok for trunk? gcc/ChangeLog: PR

[r12-6849 Regression] FAIL: gfortran.dg/ieee/signaling_3.f90 -Os execution test on Linux/x86_64

On Linux/x86_64, e89d0befe3ec3238fca6de2cb078eb403b8c7e99 is the first bad commit commit e89d0befe3ec3238fca6de2cb078eb403b8c7e99 Author: Francois-Xavier Coudert Date: Mon Jan 17 12:46:48 2022 +0100 Fortran: provide a fallback implementation of issignaling caused FAIL:

Re: [PATCH][RFC] Factor out to config/ld.m4.

Hi Joseph, >> I noticed we have duplicate .m4 code that detects information about linker >> in lib* folders: >> >> libffi/acinclude.m4 - this one is merge from the upstream project >> >> libatomic/acinclude.m4 >> libgomp/acinclude.m4 >> libitm/acinclude.m4 >> libstdc++-v3/acinclude.m4 >> >> I

Re: [PATCH] libgccjit: Add support for register variables [PR104072]

Indeed, I forgot to attach the patch. Le lundi 24 janvier 2022 à 18:20 -0500, David Malcolm a écrit : > On Sat, 2022-01-22 at 19:29 -0500, Antoni Boucher wrote: > > Hi. > > > > Le mardi 18 janvier 2022 à 18:49 -0500, David Malcolm a écrit : > > > On Mon, 2022-01-17 at 19:46 -0500, Antoni Boucher

Re: [PATCH] libgccjit: Add support for register variables [PR104072]

On Sat, 2022-01-22 at 19:29 -0500, Antoni Boucher wrote: > Hi. > > Le mardi 18 janvier 2022 à 18:49 -0500, David Malcolm a écrit : > > On Mon, 2022-01-17 at 19:46 -0500, Antoni Boucher via Gcc-patches > > wrote: > > > I missed the comment about the new define, so here's the updated > > > patch. >

[committed] remove duplicate block from pointer_query::dump

The pointer_query::dump() function contains a duplicate block of code that does the same thing as a prior block, just a little differently. I removed the code after testing it on x86_linux. The committed change is below for reference:

Re: [PATCH][RFC] Factor out to config/ld.m4.

On Mon, 24 Jan 2022, Martin Liška wrote: > Hi. > > I noticed we have duplicate .m4 code that detects information about linker > in lib* folders: > > libffi/acinclude.m4 - this one is merge from the upstream project > > libatomic/acinclude.m4 > libgomp/acinclude.m4 > libitm/acinclude.m4 >

Re: [PATCH][GCC13?] RISC-V: Replace `smin'/`smax' RTL patterns with `fmin'/`fmax'

On Sat, 22 Jan 2022, Maciej W. Rozycki wrote: > I think we have consensus that we can ignore pre-r2.2 hardware. What we > actually support is `-misa-spec=<2.2|20190608|20191213>', so we can assume > r2.2 semantics as the absolute minimum, matching the description in my > submission. Where,

Re: [PATCH] Reset relations when crossing backedges.

On 1/21/2022 3:29 AM, Aldy Hernandez wrote: On Fri, Jan 21, 2022 at 10:43 AM Richard Biener wrote: On Fri, Jan 21, 2022 at 9:30 AM Aldy Hernandez via Gcc-patches wrote: As discussed in PR103721, the problem here is that we are crossing a backedge and causing us to use relations from a

Re: [PATCH] libgccjit: Add option to hide stderr logs [PR104073]

On Sun, 2022-01-23 at 12:34 -0500, Antoni Boucher wrote: > Thanks for the review. > Here's the updated patch. Tnanks. The updated patch looks good to me, but we need to get release manager approval for adding stuff in stage 4; I'll email them when I've looked at the other pending patches. Dave

[PATCH] avoid recomputing PHI results after failure (PR 104203)

The pointer_query algorithm fails when it's unable to determine the provenance of an pointer SSA variable. A failure prevents it from making a record of the variable in the cache. Although this doesn't happen often, one common cause of failures is PHI nodes: e.g., because one of its arguments

Re: [committed] libstdc++: Use fast_float for long double if it uses binary64 format

On Mon, 24 Jan 2022 at 17:42, Patrick Palka via Libstdc++ wrote: > > On Sun, Jan 23, 2022 at 5:53 PM Jonathan Wakely via Gcc-patches > wrote: > > > > Tested powerpc64le-linux, pushed to trunk. > > > > > > We can use the new from_chars implementation when long double and double > > have the same

Re: [PATCH v2] preprocessor: -Wbidi-chars and UCNs [PR104030]

On Mon, Jan 24, 2022 at 05:36:58PM -0500, Marek Polacek wrote: > The implementation is done by using the new EnumSet feature. > > PR preprocessor/104030 > > gcc/c-family/ChangeLog: > > * c.opt (Wbidi-chars): Mark as EnumSet. Also accept =ucn. > > gcc/ChangeLog: > > *

[PATCH v2] preprocessor: -Wbidi-chars and UCNs [PR104030]

Here's an updated version of the patch which uses EnumSet (great to have it, thanks Jakub!) rather than hardcoding strings. With this patch we accept -Wbidi-chars=none,ucn as well as -Wbidi-chars=ucn. I think that's OK. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 --

Re: [PATCH v9] rtl: builtins: (not just) rs6000: Add builtins for fegetround, feclearexcept and feraiseexcept [PR94193]

On Mon, Jan 24, 2022 at 06:24:11PM -0300, Raoni Fassina Firmino wrote: > On Mon, Jan 24, 2022 at 02:29:39PM -0600, Bill Schmidt wrote: > > Adding the patch author for his information. > > Thanks Bill. > > > On 1/24/22 2:26 PM, Jakub Jelinek via Gcc-patches wrote: > > >

Re: [PATCH] dwarf2out: For ppc64le IEEE quad long double, use DW_ATE_GNU_*float128 [PR104194]

On Mon, Jan 24, 2022 at 11:14:41PM +0100, Mark Wielaard wrote: > On Mon, Jan 24, 2022 at 08:34:39PM +0100, Jakub Jelinek wrote: > > The following patch uses DW_ATE_GNU_{,complex_}float128 (new extensions > > equal to corresponding HP extensions) instead of DW_ATE_float, > > another possibility

Re: [PATCH] Fortran: detect signaling NaNs on targets without issignaling macro in libc

> Yes, it does. > > (There is also some leeway granted to non-release-critical languages > like Fortran. RM approval is only needed once a branch has been > frozen). Thanks Thomas. Pushed: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=e89d0befe3ec3238fca6de2cb078eb403b8c7e99 I’m hoping my use

Re: [PATCH] dwarf2out: For ppc64le IEEE quad long double, use DW_ATE_GNU_*float128 [PR104194]

Hi, On Mon, Jan 24, 2022 at 08:34:39PM +0100, Jakub Jelinek wrote: > The following patch uses DW_ATE_GNU_{,complex_}float128 (new extensions > equal to corresponding HP extensions) instead of DW_ATE_float, > another possibility would be DW_ATE_GNU_precision attribute on the > DW_TAG_base_type

[PATCH] openmp: Add support for target_device selector set in metadirectives

Hello This patch builds on top of the previous patches for metadirective support to add support for the target_device selector set introduced in OpenMP 5.1. This selector set is similar to the existing device selector set, but can take an additional device_num selector, specifying the

[PATCH] openmp: Metadirective patch fixes

Hello This patch fixes a couple of issues with the latest patch series for metadirectives. Firstly, the changes to c_parser_skip_to_end_of_block_or_statement and its C++ equivalent cause a couple of tests (e.g. gcc.dg/attr-malloc.c) to regress. This is because these tests cause the parser

Re: [PATCH v9] rtl: builtins: (not just) rs6000: Add builtins for fegetround, feclearexcept and feraiseexcept [PR94193]

On Mon, Jan 24, 2022 at 02:29:39PM -0600, Bill Schmidt wrote: > Adding the patch author for his information. Thanks Bill. > On 1/24/22 2:26 PM, Jakub Jelinek via Gcc-patches wrote: > > expand_builtin_feclear_feraise_except doesn't check if op0 matches > > the predicate of operands[1], the

[PATCH] PR fortran/104212 - ICE in transformational_result, at fortran/simplify.cc:466

Dear Fortranners, we lacked a check on the optional DIM argument of the intrinsics PARITY (see pr) and NORM2 (found by scanning check.cc) to verify that it is scalar. I intend to commit the attached fix within 48 hours as obvious unless there are comments. Regtested on x86_64-pc-linux-gnu.

Re: [PATCH v9] rtl: builtins: (not just) rs6000: Add builtins for fegetround, feclearexcept and feraiseexcept [PR94193]

Adding the patch author for his information. Thanks, Bill On 1/24/22 2:26 PM, Jakub Jelinek via Gcc-patches wrote: > On Mon, Jan 24, 2022 at 08:55:37AM -0600, Segher Boessenkool wrote: >> Hi! >> >> On Thu, Jan 13, 2022 at 02:08:53PM -0300, Raoni Fassina Firmino wrote: >>> Changes since v8[8]:

Re: [PATCH v9] rtl: builtins: (not just) rs6000: Add builtins for fegetround, feclearexcept and feraiseexcept [PR94193]

On Mon, Jan 24, 2022 at 08:55:37AM -0600, Segher Boessenkool wrote: > Hi! > > On Thu, Jan 13, 2022 at 02:08:53PM -0300, Raoni Fassina Firmino wrote: > > Changes since v8[8]: > > - Refactored and expanded builtin-feclearexcept-feraiseexcept-2.c > > testcase: > > + Use a macro to avoid

Re: [PATCH] rs6000: Remove GCC 8.1 U10__float128 mangling compatibility [PR104172]

Hi! On Mon, Jan 24, 2022 at 08:22:59PM +0100, Jakub Jelinek wrote: > In GCC 7.x and earlier, while it had -mabi=ieeelongdouble option, that option > was undocumented and unsupported. > In GCC 8.1 that option got documented and -mabi=ieeelongdouble long double > started > to be mangled as

[PATCH] dwarf2out: For ppc64le IEEE quad long double, use DW_ATE_GNU_*float128 [PR104194]

Hi! As mentioned in the PR, we emit the same .uleb128 0x3 # (DIE (0x42) DW_TAG_base_type) .byte 0x10 # DW_AT_byte_size .byte 0x4 # DW_AT_encoding .4byte .LASF2 # DW_AT_name: "long double" (0x4 is DW_ATE_float) whether we on powerpc64le-linux use

[PATCH] rs6000: Remove GCC 8.1 U10__float128 mangling compatibility [PR104172]

Hi! In GCC 7.x and earlier, while it had -mabi=ieeelongdouble option, that option was undocumented and unsupported. In GCC 8.1 that option got documented and -mabi=ieeelongdouble long double started to be mangled as U10__float128. In GCC 9 and backported to before 8.2 release, that mangling

Re: [PATCH] Reset relations when crossing backedges.

On Mon, Jan 24, 2022 at 9:51 AM Richard Biener wrote: > > On Fri, Jan 21, 2022 at 1:12 PM Aldy Hernandez wrote: > > > > On Fri, Jan 21, 2022 at 11:56 AM Richard Biener > > wrote: > > > > > > On Fri, Jan 21, 2022 at 11:30 AM Aldy Hernandez wrote: > > > > > > > > On Fri, Jan 21, 2022 at 10:43 AM

[r12-6844 Regression] FAIL: gcc.dg/vect/pr81196.c scan-tree-dump-times vect "vectorized 1 loops" 1 on Linux/x86_64

On Linux/x86_64, f1af8528d34418bc874ae9d993ee0dc3559972d2 is the first bad commit commit f1af8528d34418bc874ae9d993ee0dc3559972d2 Author: Richard Biener Date: Mon Jan 24 11:50:06 2022 +0100 tree-optimization/102131 - fix niter analysis wrt overflow caused FAIL: gcc.dg/vect/pr81196.c

Re: Difference between 32-bit SPARCv9 and SPARCv8+?

Hi Eric! On 1/23/22 10:18, Eric Botcazou wrote: >> Is this intentional? If yes, what is the exact difference between V8+ and >> 32-bit V9? > > V8+ requires the full 64-bit registers to be preserved by the kernel, whereas > 32-bit V9 does not. OK, thanks for the clarification. Asking on top of

Re: [committed] libstdc++: Use fast_float for long double if it uses binary64 format

On Sun, Jan 23, 2022 at 5:53 PM Jonathan Wakely via Gcc-patches wrote: > > Tested powerpc64le-linux, pushed to trunk. > > > We can use the new from_chars implementation when long double and double > have the same representation. I suppose we should also update to sync the conditions that define

Re: [PATCH] Fortran: detect signaling NaNs on targets without issignaling macro in libc

On 24.01.22 15:23, FX via Fortran wrote: Then it’s OK to commit for me, but you will need approval from release managers at this stage. Hum… I submitted it before stage 4 started, does that count? Yes, it does. (There is also some leeway granted to non-release-critical languages like

[PATCH] libgcc: Fix _Unwind_Find_FDE for missing unwind data with glibc 2.35

_dl_find_object returns success even if no unwind information has been found, and dlfo_eh_frame is NULL. libgcc/ChangeLog: PR libgcc/104207 * unwind-dw2-fde-dip.c (_Unwind_Find_FDE): Add NULL check. --- libgcc/unwind-dw2-fde-dip.c | 2 +- 1 file changed, 1 insertion(+), 1

Re: [PATCH] c++: Fix non-portable default argument of make_auto_1 [PR104197]

On 1/24/22 10:27, Patrick Palka wrote: Avoid using the macro current_template_depth, which expands to an expression in terms of __FUNCTION__, within the signature of a function. Clang warns about this and MSVC rejects it. Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for

Re: [PATCH] c++: Fix non-portable default argument of make_auto_1 [PR104197]

On Mon, Jan 24, 2022 at 10:27:40AM -0500, Patrick Palka via Gcc-patches wrote: > Avoid using the macro current_template_depth, which expands to an > expression in terms of __FUNCTION__, within the signature of a function. > Clang warns about this and MSVC rejects it. > > Bootstrapped and

[PATCH] c++: Fix non-portable default argument of make_auto_1 [PR104197]

Avoid using the macro current_template_depth, which expands to an expression in terms of __FUNCTION__, within the signature of a function. Clang warns about this and MSVC rejects it. Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? PR c++/104197

Re: [PATCH v9] rtl: builtins: (not just) rs6000: Add builtins for fegetround, feclearexcept and feraiseexcept [PR94193]

Hi! On Thu, Jan 13, 2022 at 02:08:53PM -0300, Raoni Fassina Firmino wrote: > Changes since v8[8]: > - Refactored and expanded builtin-feclearexcept-feraiseexcept-2.c > testcase: > + Use a macro to avoid extended repetition of the core test code. > + Expanded the test code to check

[PATCH] Adjust LSHIFT_EXPR handling of multiple_of_p

This removes the odd check of size_type_node when handling left-shifts as multiplications of 1 << N and instead uses the type as specified. It also moves left-shift handling next to multiplications where it semantically belongs. Boostrap and regtest pending on x86_64-unknown-linux-gnu. OK? (I

[PATCH] Fix multiple_of_p behavior with NOP_EXPR

We were passing down the original type to recursive invocations of multiple_of_p for say (int)(unsigned * unsigned). Bootstrap and regtest pending on x86_64-unknown-linux-gnu. 2022-01-24 Richard Biener * fold-const.cc (multiple_of_p): Pass the correct type of the expression

[PATCH] Reduce multiple_of_p uses

There are a few cases where we know we're dealing with (poly-)integer constants, so remove the use of multiple_of_p in those cases to make the PR100499 fix less impactful. Bootstrapped and tested on x86_64-unknown-linux-gnu. OK? Thanks, Richard. 2022-01-24 Richard Biener PR

Re: [PATCH] Fortran: detect signaling NaNs on targets without issignaling macro in libc

> Then it’s OK to commit for me, but you will need approval from release > managers at this stage. Hum… I submitted it before stage 4 started, does that count? FX

[PATCH] [vect] Add vect_recog_cond_expr_convert_pattern.

The pattern converts (cond (cmp a b) (convert c) (convert d)) to (convert (cond (cmp a b) c d)) when 1) types_match (c, d) 2) single_use for (convert c) and (convert d) 3) TYPE_PRECISION (TREE_TYPE (c)) == TYPE_PRECISION (TREE_TYPE (a)) 4) INTEGERAL_TYPE_P (TREE_TYPE (c)) The pattern can save

Re: [PATCH] [gfortran] Add support for allocate clause (OpenMP 5.0).

On 24/01/2022 08:45, Tobias Burnus wrote: > On 21.01.22 18:43, Tobias Burnus wrote: >> On 21.01.22 18:15, Thomas Schwinge wrote: >>>     11 | integer(c_int) function is_64bit_aligned (a) bind(C) >>> Warning: Variable ‘a’ at (1) is a dummy argument of the BIND(C) >>> procedure

Re: [PATCH] gcc-changelog: Catch forbidden files.

On Mon, Jan 24, 2022 at 01:06:25PM +0100, Martin Liška wrote: > Makes sense, implemented in the attached patch. > > Ready to be installed? LGTM. > From 55e9774ba91e0acf12102d7c595482c29d5397cb Mon Sep 17 00:00:00 2001 > From: Martin Liska > Date: Mon, 24 Jan 2022 13:03:01 +0100 > Subject:

[PATCH] tree-optimization/102131 - fix niter analysis wrt overflow

This fixes the overflow issues seen with analyzing BASE0 + STEP0 cmp BASE1 + STEP1 as BASE0 + STEP0 - STEP1 cmp BASE1 by following the logic we have when simplifying comparisons. Bootstrapped and tested on x86_64-unknown-linux-gnu. I've built SPEC 2017 with extra statistics and in all of it

Re: [PATCH] gcc-changelog: Catch forbidden files.

On 1/24/22 12:40, Jakub Jelinek wrote: On Mon, Jan 24, 2022 at 12:28:53PM +0100, Martin Liška wrote: The patch is about FORBIDDEN_FILES that we don't want to be commited. So far we have $root/Makefile.am and $root/build.log. Do you have any other candidates? I think it shouldn't be about

Re: [PATCH] gcc-changelog: Catch forbidden files.

On Mon, Jan 24, 2022 at 12:28:53PM +0100, Martin Liška wrote: > The patch is about FORBIDDEN_FILES that we don't want to be commited. > So far we have $root/Makefile.am and $root/build.log. > > Do you have any other candidates? I think it shouldn't be about blacklisting all the mistakes from the

[PATCH] gcc-changelog: Catch forbidden files.

Hi. The patch is about FORBIDDEN_FILES that we don't want to be commited. So far we have $root/Makefile.am and $root/build.log. Do you have any other candidates? Cheers, Martin contrib/ChangeLog: * gcc-changelog/git_commit.py: Add FORBIDDEN_FILES. *

[PATCH][V2] Add mold detection for libs.

On 1/21/22 17:54, Jonathan Wakely wrote: Yes, OK (but please CC the libstdc++ list, not just me). Hello. Sorry for that. Anyway, I would like to install the extended version of the patch that touches all libraries. Ready to be installed? Thanks, MartinFrom

Re: [PATCH] acinclude.m4: Remove duplicite AC_DEFUN.

On Mon, Jan 24, 2022 at 11:47 AM Martin Liška wrote: > > The function LIBAT_CHECK_LINKER_FEATURES is defined twice in the file. > > Ready to be installed? OK. > Thanks, > Martin > > libatomic/ChangeLog: > > * acinclude.m4: Remove duplicate > LIBAT_CHECK_LINKER_FEATURES. >

Re: [PATCH] options: Add EnumSet and Set property support [PR104158]

On Mon, Jan 24, 2022 at 11:41 AM Jakub Jelinek wrote: > > On Mon, Jan 24, 2022 at 11:17:00AM +0100, Richard Biener wrote: > > > I think with the 2) patch I achieve what we want for Fortran, for 1) > > > the only behavior from gcc 11 is that > > > -fsanitize-coverage=trace-cmp,trace-cmp is now

[PATCH] acinclude.m4: Remove duplicite AC_DEFUN.

The function LIBAT_CHECK_LINKER_FEATURES is defined twice in the file. Ready to be installed? Thanks, Martin libatomic/ChangeLog: * acinclude.m4: Remove duplicate LIBAT_CHECK_LINKER_FEATURES. * configure: Regenerate. --- libatomic/acinclude.m4 | 102

Re: [PATCH] options: Add EnumSet and Set property support [PR104158]

On Mon, Jan 24, 2022 at 11:17:00AM +0100, Richard Biener wrote: > > I think with the 2) patch I achieve what we want for Fortran, for 1) > > the only behavior from gcc 11 is that > > -fsanitize-coverage=trace-cmp,trace-cmp is now rejected. > > But -fsanitize-coverage=trace-cmp

Re: [PATCH 1/2] Check negative combined step

On Thu, 13 Jan 2022, Jiufu Guo wrote: > Hi, > > Previously, there is discussion in: > https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586460.html > I seperate it as two patches. > > This first patch is to avoid negative step when combining two ivs. > The second patch is adding more

[PATCH][RFC] Factor out to config/ld.m4.

Hi. I noticed we have duplicate .m4 code that detects information about linker in lib* folders: libffi/acinclude.m4 - this one is merge from the upstream project libatomic/acinclude.m4 libgomp/acinclude.m4 libitm/acinclude.m4 libstdc++-v3/acinclude.m4 I prepared a proof-of-concept patch that

Re: [PATCH] options: Add EnumBitSet property support [PR104158]

On Mon, Jan 24, 2022 at 10:01 AM Jakub Jelinek via Gcc-patches wrote: > > On Sat, Jan 22, 2022 at 01:47:08AM +0100, Jakub Jelinek via Gcc-patches wrote: > > I think with the 2) patch I achieve what we want for Fortran, for 1) > > the only behavior from gcc 11 is that > >

Re: [PATCH] options: Fix up -fsanitize-coverage= [PR104158]

On Sat, Jan 22, 2022 at 1:50 AM Jakub Jelinek via Gcc-patches wrote: > > Hi! > > This is incremental patch to fix up -fsanitize-coverage= option > handling, allow -fno-sanitize-coverage= again, allow both > options together in one option or make > -fsanitize-coverage=trace-pc

Re: [PATCH] options: Add EnumSet and Set property support [PR104158]

On Sat, Jan 22, 2022 at 1:48 AM Jakub Jelinek via Gcc-patches wrote: > > Hi! > > The following patch is infrastructure support for at least 3 different > options that need changes: > 1) PR104158 talks about a regression with the -fsanitizer-coverage= >option; in GCC 11 and older and on trunk

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

On Mon, 24 Jan 2022, Jakub Jelinek wrote: > On Sat, Jan 22, 2022 at 07:03:48PM +0100, Jakub Jelinek via Gcc-patches wrote: > > On Sat, Jan 22, 2022 at 01:16:38PM +0100, Jakub Jelinek via Gcc-patches > > wrote: > > > Actually, I suspect we either need something like following patch, > > > or need

[committed] RISC-V: Do not emit zcisr and zifencei if i-ext is 2.0

I-ext 2.0 already included zicsr and zifencei, skip that prevent confusing binutils. gcc/ChangeLog * common/config/riscv/riscv-common.cc (riscv_subset_list::to_string): Skip zicsr and zifencei if I-ext is 2.0. --- gcc/common/config/riscv/riscv-common.cc | 14 -- 1

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

On Sat, Jan 22, 2022 at 07:03:48PM +0100, Jakub Jelinek via Gcc-patches wrote: > On Sat, Jan 22, 2022 at 01:16:38PM +0100, Jakub Jelinek via Gcc-patches wrote: > > Actually, I suspect we either need something like following patch, > > or need to change

Re: [PATCH] Update the type of control.base after changed

Richard Biener writes: > On Fri, 21 Jan 2022, Jiufu Guo wrote: > >> Hi, >> >> This patch correct the type of niter->control.base, when it is updated >> as a PLUS expr. >> During build PLUS expr, the result type should align with the type of >> the operands. >> >> Bootstrap and regtest pass on

[PATCH] options: Add EnumBitSet property support [PR104158]

On Sat, Jan 22, 2022 at 01:47:08AM +0100, Jakub Jelinek via Gcc-patches wrote: > I think with the 2) patch I achieve what we want for Fortran, for 1) > the only behavior from gcc 11 is that > -fsanitize-coverage=trace-cmp,trace-cmp is now rejected. > This is mainly from the desire to disallow >

Re: [PATCH] [gfortran] Add support for allocate clause (OpenMP 5.0).

On 21.01.22 18:43, Tobias Burnus wrote: On 21.01.22 18:15, Thomas Schwinge wrote: 11 | integer(c_int) function is_64bit_aligned (a) bind(C) Warning: Variable ‘a’ at (1) is a dummy argument of the BIND(C) procedure ‘is_64bit_aligned’ but may not be C interoperable