Re: [PATCH 0/2] LoongArch: respect --with-* and drop loongarch-driver

On Fri, 2022-12-09 at 10:43 +0800, Icenowy Zheng wrote: > This patchset tries to fix the object duplication between the driver and > the real compiler, which makes libgccjit building fail because of > linking this two parts together. Hmm, I think the issue is already fixed by

Re: [PATCH 3/3] btf: correct generation for extern funcs [PR106773]

On 12/7/22 12:57, David Faust wrote: The eBPF loader expects to find entries for functions declared as extern in the corresponding BTF_KIND_DATASEC record, but we were not generating these entries. This patch adds support for the 'extern' linkage of function types in BTF, and creates entries

Re: [PATCH 2/3] btf: fix 'extern const void' variables [PR106773]

Looks OK to me overall. Minor comments below. Thanks On 12/7/22 12:57, David Faust wrote: The eBPF loader expects to find BTF_KIND_VAR records for references to extern const void symbols. We were mistakenly identifing these as unsupported types, and as a result skipping emitting VAR records

Re: [PATCH]AArch64 div-by-255, ensure that arguments are registers. [PR107988]

Richard Earnshaw writes: > On 08/12/2022 16:39, Tamar Christina via Gcc-patches wrote: >> Hi All, >> >> At -O0 (as opposed to e.g. volatile) we can get into the situation where the >> in0 and result RTL arguments passed to the division function are memory >> locations instead of registers. I

Re: [PATCH v2 1/2] Allow subtarget customization of CC1_SPEC

On 07/12/2022 10:50, Richard Sandiford wrote: How about going back to Jose's suggestion from the original thread of using OS_CC1_SPEC? The patch is OK with that change if no-one objects in 24 hours. I checked in this change:

Re: [PATCH 1/3] btf: add 'extern' linkage for variables [PR106773]

Hi David, On 12/7/22 12:57, David Faust wrote: Add support for the 'extern' linkage value for BTF_KIND_VAR records, which is used for variables declared as extern in the source file. PR target/106773 gcc/ * btfout.cc (BTF_LINKAGE_STATIC): New define.

Re: [PATCH V3] Use reg mode to move sub blocks for parameters and returns

Hi Segher, Thanks a lot for your helpful comments! Segher Boessenkool writes: > On Thu, Dec 08, 2022 at 09:17:38PM +0800, Jiufu Guo wrote: >> Segher Boessenkool writes: >> > On Wed, Dec 07, 2022 at 08:00:08PM +0800, Jiufu Guo wrote: >> >> typedef struct SA {double a[3];} A; >> >> A ret_arg_pt

[PATCH 2/2] LoongArch: drop loongarch-driver

Currently the loongarch-driver code tries to parse the values of some -m flags to numeric representation, and then output the strings corresponding to the numeric representations. This is mostly an no-op, and it leads to duplication of these flags' parse code, which makes building libgccjit fail

[PATCH 1/2] LoongArch: respect the with values in config.gcc

In config.gcc, there's a long code snippet that handles --with-{arch,tune,abi,fpu} and give them default values; however these "with" values are not used at all. Use these "with" values to initialize these variables in specs. gcc/ChangeLog: * config/loongarch/loongarch.h

[committed] analyzer: rename region-model-impl-calls.cc to kf.cc

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. Pushed to trunk as r13-4579-g63a42ffc083355. gcc/ChangeLog: * Makefile.in (ANALYZER_OBJS): Update for renaming of analyzer/region-model-impl-calls.cc to analyzer/kf.cc. gcc/analyzer/ChangeLog: * analyzer.h

[committed] analyzer: fix ICE on region creation during get_referenced_base_regions [PR108003]

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. Pushed to trunk as r13-4578-g7dc0ecafe60b22. gcc/analyzer/ChangeLog: PR analyzer/108003 * call-summary.cc (call_summary_replay::convert_region_from_summary_1): Convert heap_regs_in_use from auto_sbitmap

[committed] analyzer: handle memmove like memcpy

On Thu, 2022-12-08 at 07:36 -0300, Alexandre Oliva wrote: > Hello again, David, > > On Dec 2, 2022, David Malcolm wrote: > > > I had a go at porting your patch to trunk; here's the result. > > Oh, wow, nice! Thank you so much. > > I confirm it works on riscv64-elf too. Thanks. When I ran

Re: [PATCH 0/2] Support HWASAN with Intel LAM

On Wed, Nov 30, 2022 at 10:07 PM Martin Liška wrote: > > On 11/29/22 03:37, Hongtao Liu wrote: > > On Mon, Nov 28, 2022 at 10:40 PM Martin Liška wrote: > >> > >> On 11/11/22 02:26, liuhongt via Gcc-patches wrote: > >>>2 years ago, ARM folks support HWASAN[1] in GCC[2], and introduced > >>>

Re: [PATCH 2/3]rs6000: NFC use sext_hwi to replace ((v&0xf..f)^0x80..0) - 0x80..0

Hi, Jiufu Guo via Gcc-patches writes: > Hi Kewen, > > "Kewen.Lin" writes: >> on 2022/12/1 20:16, guojiufu wrote: >>> On 2022-12-01 15:10, Jiufu Guo via Gcc-patches wrote: Hi Kewen, cut... >>> From 8aa8e1234b6ec34473434951a3a6177253aac770 Mon Sep 17 00:00:00 2001 >>> From: Jiufu Guo >>>

[committed] libstdc++: Fix some -Wunused warnings in tests

Tested x86_64-linux. Pushed to trunk. -- >8 -- libstdc++-v3/ChangeLog: * include/ext/pb_ds/detail/type_utils.hpp (PB_DS_STATIC_ASSERT): Add unused attribute to avoid -Wunused-local-typedef warnings. * testsuite/17_intro/tag_type_explicit_ctor.cc: Add pragma to

[committed] libstdc++: Remove digit separators [PR108015]

Tested x86_64-linux. Pushed to trunk. -- >8 -- These are not valid in C++11 and cause a warning when preprocessing, even though they're inside a skipped group. chrono:2436: warning: missing terminating ' character libstdc++-v3/ChangeLog: PR libstdc++/108015 *

[committed] libstdc++: Add [[nodiscard]] to chrono conversion functions

Tested x86_64-linux. Pushed to trunk. -- >8 -- Also add doxygen comments. libstdc++-v3/ChangeLog: * include/bits/chrono.h (duration_cast, floor, round, abs, ceil) (time_point_cast): Add [[nodiscard]] attribute and doxygen comments. (treat_as_floating_point): Add

[committed] libstdc++: Change class-key for duration and time_point to class

Tested x86_64-linux. Pushed to trunk. -- >8 -- We define these with the 'struct' keyword, but the standard uses 'class'. This results in warnings if users try to refer to them using elaborated type specifiers. libstdc++-v3/ChangeLog: * include/bits/chrono.h (duration, time_point):

Re: [PATCH v3] docs: Suggest options to improve ASAN stack traces

On Thu, Dec 08, 2022 at 05:56:41PM -0500, Marek Polacek wrote: > Can't hurt. Here's an updated patch. > > -- >8 -- > I got a complaint that while Clang docs suggest options that improve > the quality of the backtraces ASAN prints (cf. >

[PATCH v3] docs: Suggest options to improve ASAN stack traces

On Thu, Dec 08, 2022 at 04:00:15PM +0100, Jakub Jelinek wrote: > On Thu, Dec 08, 2022 at 09:34:34AM -0500, Marek Polacek wrote: > > I got a complaint that while Clang docs suggest options that improve > > the quality of the backtraces ASAN prints (cf. > >

Re: [PATCH] expr.cc: avoid unexpected side effects in expand_expr_divmod optimization

Hi Jakub. > On Thu, Dec 08, 2022 at 02:02:36PM +0100, Jose E. Marchesi wrote: >> So, I guess the right fix would be to call assemble_external_libcall >> during final? The `.global FOO' directive would be generated >> immediately before the call sequence, but I guess that would be ok. > >

Re: [PATCH] Fortran: diagnose and reject duplicate CONTIGUOUS attribute [PR108025]

On Thu, Dec 08, 2022 at 10:59:42PM +0100, Harald Anlauf via Fortran wrote: > Dear all, > > a fairly obvious, or rather trivial fix that appeared while > analyzing another pr and that can be treated independently: > reject duplicate CONTIGUOUS attributes. > > (Intel and NAG reject this, Cray

Re: [PATCH 1/3] Rework 128-bit complex multiply and divide, PR target/107299

On Wed, Dec 07, 2022 at 03:55:41PM +0800, Kewen.Lin wrote: > Hi Mike, > > on 2022/12/7 14:44, Michael Meissner wrote: > > On Tue, Dec 06, 2022 at 05:36:54PM +0800, Kewen.Lin wrote: > >> Hi Mike, > >> > >> Thanks for fixing this! > >> > >> Could you help to elaborate why we need to disable it

[PATCH RFA] gimplify: avoid unnecessary copy of init array [PR105838]

After the previous patches, I noticed that we were putting the array of strings into .rodata, but then memcpying it into an automatic array, which is pointless; we should be able to use it directly. C++ doesn't allow us to do this for the backing array of an initializer_list, but should be able

[PATCH] Fortran: diagnose and reject duplicate CONTIGUOUS attribute [PR108025]

Dear all, a fairly obvious, or rather trivial fix that appeared while analyzing another pr and that can be treated independently: reject duplicate CONTIGUOUS attributes. (Intel and NAG reject this, Cray warns that this is non-standard.) Regtested on x86_64-pc-linux-gnu. OK for mainline?

Re: [PATCH] RISC-V: Produce better code with complex constants [PR95632] [PR106602]

On Thu, 08 Dec 2022 10:15:47 PST (-0800), gcc-patches@gcc.gnu.org wrote: On 12/8/22 10:53, Palmer Dabbelt wrote: On Wed, 07 Dec 2022 12:55:17 PST (-0800), rzin...@ventanamicro.com wrote: Due to RISC-V limitations on operations with big constants combine is failing to match such operations

Re: [PATCH] bpf: add define_insn for bswap

Hi David. > The eBPF architecture provides 'end[be,le]' instructions for endianness > swapping. Add a define_insn for bswap2 to use them instaed of > falling back on a libcall. > > Tested on bpf-unknown-none, no known regressions. > > OK to commit? > Thanks OK for master. Thanks! > gcc/ > >

[pushed] c++: build initializer_list in a loop [PR105838]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- The previous patch avoided building an initializer_list at all when building a vector, but in situations where that isn't possible, we could still build the initializer_list with a loop over a constant array. This is represented using a

[pushed] c++: avoid initializer_list [PR105838]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- When constructing a vector from { "strings" }, first is built an initializer_list, which is then copied into the strings in the vector. But this is inefficient: better would be treat the { "strings" } as a range and construct the strings

[PATCH] bpf: add define_insn for bswap

The eBPF architecture provides 'end[be,le]' instructions for endianness swapping. Add a define_insn for bswap2 to use them instaed of falling back on a libcall. Tested on bpf-unknown-none, no known regressions. OK to commit? Thanks gcc/ * config/bpf/bpf.md (bswap2): New define_insn.

[pushed] c++: fewer allocator temps [PR105838]

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- In this PR, initializing the array of std::string to pass to the vector initializer_list constructor gets very confusing to the optimizers as the number of elements increases, primarily because of all the std::allocator temporaries passed

Re: [PATCH RFA(tree)] c++: source position of lambda captures [PR84471]

Ping. On 12/2/22 10:45, Jason Merrill wrote: Tested x86_64-pc-linux-gnu, OK for trunk? -- 8< -- If the DECL_VALUE_EXPR of a VAR_DECL has EXPR_LOCATION set, then any use of that variable looks like it has that location, which leads to the debugger jumping back and forth for both lambdas and

Re: [PATCH] RISC-V: Produce better code with complex constants [PR95632] [PR106602]

On 12/8/22 10:53, Palmer Dabbelt wrote: On Wed, 07 Dec 2022 12:55:17 PST (-0800), rzin...@ventanamicro.com wrote: Due to RISC-V limitations on operations with big constants combine is failing to match such operations and is not being able to produce optimal code as it keeps splitting them.

Re: [PATCH] RISC-V: Produce better code with complex constants [PR95632] [PR106602]

On Wed, 07 Dec 2022 12:55:17 PST (-0800), rzin...@ventanamicro.com wrote: Due to RISC-V limitations on operations with big constants combine is failing to match such operations and is not being able to produce optimal code as it keeps splitting them. By pretending we can do those operations we

Re: [PATCH] RISC-V: Produce better code with complex constants [PR95632] [PR106602]

On Wed, 07 Dec 2022 13:30:32 PST (-0800), gcc-patches@gcc.gnu.org wrote: On Wed, Dec 07, 2022 at 05:55:17PM -0300, Raphael Moreira Zinsly wrote: Due to RISC-V limitations on operations with big constants combine is failing to match such operations and is not being able to produce optimal code

Re: [PATCH]AArch64 div-by-255, ensure that arguments are registers. [PR107988]

On 08/12/2022 16:39, Tamar Christina via Gcc-patches wrote: Hi All, At -O0 (as opposed to e.g. volatile) we can get into the situation where the in0 and result RTL arguments passed to the division function are memory locations instead of registers. I think we could reject these early on by

[PATCH] c++: class-scope qualified constrained auto [PR107188]

Here when parsing the class-scope auto constrained by a qualified concept-id, we first tentatively parse the overall member-declaration as a deprecated access-declaration, during which we parse C as a standalone TEMPLATE_ID_EXPR (not part of the auto) and end up emitting the bogus error

[PATCH]AArch64 div-by-255, ensure that arguments are registers. [PR107988]

Hi All, At -O0 (as opposed to e.g. volatile) we can get into the situation where the in0 and result RTL arguments passed to the division function are memory locations instead of registers. I think we could reject these early on by checking that the gimple values are GIMPLE registers, but I think

Re: [PATCH] expr.cc: avoid unexpected side effects in expand_expr_divmod optimization

>> Am 08.12.2022 um 11:56 schrieb Jose E. Marchesi via Gcc-patches >> : >> >> The expand_expr_divmod function in expr.cc attempts to optimize cases >> where both arguments of a division/modulus are known to be positive >> when interpreted as signed. In these cases, both signed division and

Re: [PATCH 02/17] libgomp: pinned memory

On 08.12.22 15:35, Andrew Stubbs wrote: On 08/12/2022 14:02, Tobias Burnus wrote: With available, I assume that nvptx is an 'available device' (per OpenMP definition, finally added in TR11), i.e. there is an image for nvptx and - after omp_requires filtering - there remains at least one nvptx

Re: [PATCH v2] docs: Suggest options to improve ASAN stack traces

On Thu, Dec 08, 2022 at 09:34:34AM -0500, Marek Polacek wrote: > I got a complaint that while Clang docs suggest options that improve > the quality of the backtraces ASAN prints (cf. > ), our docs > don't say anything to that effect. This

Re: [PATCH V3] Use reg mode to move sub blocks for parameters and returns

On Thu, Dec 08, 2022 at 09:17:38PM +0800, Jiufu Guo wrote: > Segher Boessenkool writes: > > On Wed, Dec 07, 2022 at 08:00:08PM +0800, Jiufu Guo wrote: > >> typedef struct SA {double a[3];} A; > >> A ret_arg_pt (A *a) {return *a;} // on ppc64le, expect only 3 lfd(s) > >> A ret_arg (A a) {return

Re: [GCC][PATCH 13/15, v4] arm: Add support for dwarf debug directives and pseudo hard-register for PAC feature.

On 09/11/2022 14:32, Srinath Parvathaneni via Gcc-patches wrote: Hello, This patch teaches the DWARF support in gcc about RA_AUTH_CODE pseudo hard-register and also updates the ".save", ".cfi_register", ".cfi_offset", ".cfi_restore" directives accordingly. This patch also adds support to

Re: [PATCH 02/17] libgomp: pinned memory

On 08/12/2022 14:02, Tobias Burnus wrote: On 08.12.22 13:51, Andrew Stubbs wrote: On 08/12/2022 12:11, Jakub Jelinek wrote: On Thu, Jul 07, 2022 at 11:34:33AM +0100, Andrew Stubbs wrote: Implement the OpenMP pinned memory trait on Linux hosts using the mlock syscall.  Pinned allocations are

[PATCH v2] docs: Suggest options to improve ASAN stack traces

On Thu, Dec 08, 2022 at 03:28:13PM +0100, Jakub Jelinek wrote: > On Thu, Dec 08, 2022 at 09:11:54AM -0500, Marek Polacek via Gcc-patches wrote: > > On Thu, Dec 08, 2022 at 08:25:26AM +0100, Florian Weimer wrote: > > > * Marek Polacek via Gcc-patches: > > > > > > > diff --git a/gcc/doc/invoke.texi

Re: [PATCH] docs: Suggest options to improve ASAN stack traces

On Thu, Dec 08, 2022 at 09:11:54AM -0500, Marek Polacek via Gcc-patches wrote: > On Thu, Dec 08, 2022 at 08:25:26AM +0100, Florian Weimer wrote: > > * Marek Polacek via Gcc-patches: > > > > > diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi > > > index 726392409b6..2de14466dd3 100644 > > >

Re: [PATCH] docs: Suggest options to improve ASAN stack traces

On Thu, Dec 08, 2022 at 08:25:26AM +0100, Florian Weimer wrote: > * Marek Polacek via Gcc-patches: > > > diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi > > index 726392409b6..2de14466dd3 100644 > > --- a/gcc/doc/invoke.texi > > +++ b/gcc/doc/invoke.texi > > @@ -16510,6 +16510,14 @@ The

Re: [PATCH 02/17] libgomp: pinned memory

On 08.12.22 13:51, Andrew Stubbs wrote: On 08/12/2022 12:11, Jakub Jelinek wrote: On Thu, Jul 07, 2022 at 11:34:33AM +0100, Andrew Stubbs wrote: Implement the OpenMP pinned memory trait on Linux hosts using the mlock syscall. Pinned allocations are performed using mmap, not malloc, to ensure

Re: [PATCH] PR tree-optimization/107985 - Ensure arguments to range-op handler are supported.

On 12/7/22 12:26, Richard Biener wrote: On Wed, Dec 7, 2022 at 5:45 PM Andrew MacLeod via Gcc-patches wrote: THis patch invalidates a range-op handler object if an operand type in the statement is not supported. This also triggered a check in stmt dependency resolution which assumed there

Re: [PATCH] expr.cc: avoid unexpected side effects in expand_expr_divmod optimization

> Am 08.12.2022 um 11:56 schrieb Jose E. Marchesi via Gcc-patches > : > > The expand_expr_divmod function in expr.cc attempts to optimize cases > where both arguments of a division/modulus are known to be positive > when interpreted as signed. In these cases, both signed division and >

Re: [PATCH] expr.cc: avoid unexpected side effects in expand_expr_divmod optimization

On Thu, Dec 08, 2022 at 02:02:36PM +0100, Jose E. Marchesi wrote: > So, I guess the right fix would be to call assemble_external_libcall > during final? The `.global FOO' directive would be generated > immediately before the call sequence, but I guess that would be ok. During final only if all

Re: [PATCH V3] Use reg mode to move sub blocks for parameters and returns

Hi Segher, Thanks a lot for your review! Segher Boessenkool writes: > Hi! > > On Wed, Dec 07, 2022 at 08:00:08PM +0800, Jiufu Guo wrote: >> When assigning a parameter to a variable, or assigning a variable to >> return value with struct type, "block move" are used to expand >> the assignment.

Re: [PATCH] expr.cc: avoid unexpected side effects in expand_expr_divmod optimization

Hi Jakub. > On Thu, Dec 08, 2022 at 11:59:44AM +0100, Jose E. Marchesi via Gcc-patches > wrote: >> gcc/ChangeLog >> >> * expr.cc (expand_expr_divmod): Avoid side-effects of trying >> sequences involving funcalls in optimization. > > That looks wrong. > The globals for mentioned

Re: [PATCH 02/17] libgomp: pinned memory

On 08/12/2022 12:11, Jakub Jelinek wrote: On Thu, Jul 07, 2022 at 11:34:33AM +0100, Andrew Stubbs wrote: Implement the OpenMP pinned memory trait on Linux hosts using the mlock syscall. Pinned allocations are performed using mmap, not malloc, to ensure that they can be unpinned safely when

Re: [PATCH] c++: modules and std::source_location::current() def arg [PR100881]

On 12/7/22 16:50, Patrick Palka wrote: We currently declare __builtin_source_location with a const void* return type instead of the true type (const std::source_location::__impl*), and later when folding this builtin we just obtain the true type via name lookup. But the below testcase

Re: [PATCH] expr.cc: avoid unexpected side effects in expand_expr_divmod optimization

On Thu, Dec 08, 2022 at 11:59:44AM +0100, Jose E. Marchesi via Gcc-patches wrote: > gcc/ChangeLog > > * expr.cc (expand_expr_divmod): Avoid side-effects of trying > sequences involving funcalls in optimization. That looks wrong. The globals for mentioned calls just shouldn't be

Re: [PATCH 02/17] libgomp: pinned memory

On Thu, Jul 07, 2022 at 11:34:33AM +0100, Andrew Stubbs wrote: > > Implement the OpenMP pinned memory trait on Linux hosts using the mlock > syscall. Pinned allocations are performed using mmap, not malloc, to ensure > that they can be unpinned safely when freed. As I said before, I think the

Re: [PATCH 2/2] OpenMP: Duplicate checking for map clauses in Fortran (PR107214)

Hi Julian: On 07.12.22 20:13, Julian Brown wrote: I know that this was the case before, but can you move the mark:1 etc. after 'tlink'? In that case all bitfields are grouped together. Thanks for doing so. I wonder whether that also rejects the following – which seems to be valid. The 'map'

Re: [PATCH 01/17] libgomp, nvptx: low-latency memory allocator

On Thu, Jul 07, 2022 at 11:34:32AM +0100, Andrew Stubbs wrote: > libgomp/ChangeLog: > > * allocator.c (MEMSPACE_ALLOC): New macro. > (MEMSPACE_CALLOC): New macro. > (MEMSPACE_REALLOC): New macro. > (MEMSPACE_FREE): New macro. > (dynamic_smem_size): New constants. >

[PATCH] tree-optimization/99919 - bogus uninit diagnostic with bitfield guards

For the testcase in this PR what fold-const.cc optimize_bit_field_compare does to bitfield against constant compares is confusing the uninit predicate analysis and it also makes SRA obfuscate instead of optimize the code. We've long had the opinion that those optimizations are premature but we do

[PATCH] expr.cc: avoid unexpected side effects in expand_expr_divmod optimization

The expand_expr_divmod function in expr.cc attempts to optimize cases where both arguments of a division/modulus are known to be positive when interpreted as signed. In these cases, both signed division and unsigned division will raise the same value, and therefore the cheapest option can be

[PATCH] tree-optimization/107699 - missed _M_elems + _1 != _M_elems folding

The following addresses a missed folding noticed in PR107699 that can be fixed amending the existing + a != + b pattern to also handle the case of only one side having a pointer plus. I'm moving the patterns next to related simpifications showing there'd be an existing pattern matching this if

Re: [PATCH] i386: Add *concat3_{5, 6, 7} patterns [PR107627]

On Thu, Dec 8, 2022 at 10:49 AM Jakub Jelinek wrote: > > Hi! > > On Thu, Dec 01, 2022 at 09:09:51AM +0100, Jakub Jelinek via Gcc-patches wrote: > > BTW, I wonder if we couldn't add additional patterns which would catch > > the case where one of the operands is constant. > > The following patch

Re: [PATCH] [PR102706] [testsuite] -Wno-stringop-overflow vs Warray-bounds

On Dec 3, 2022, Richard Biener wrote: >> On riscv64-elf and arm-eabi/-mcpu=cortex-r5, for example, though the >> Warray-bounds-48.c condition passes, we don't issue warnings because >> we decide not to vectorize the assignments. > If it’s cost can you try-fno-vect-cost-model? If that works it

Re: [PATCH trunk] [PR104308] [analyzer] handle memmove like memcpy

Hello again, David, On Dec 2, 2022, David Malcolm wrote: > I had a go at porting your patch to trunk; here's the result. Oh, wow, nice! Thank you so much. I confirm it works on riscv64-elf too. -- Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/ Free Software

Re: [PATCH] cfgbuild: Fix DEBUG_INSN handling in find_bb_boundaries [PR106719]

On Thu, Dec 8, 2022 at 11:12 AM Jakub Jelinek via Gcc-patches wrote: > > Hi! > > The following testcase FAILs on aarch64-linux. We have some atomic > instruction followed by 2 DEBUG_INSNs (if -g only of course) followed > by NOTE_INSN_EPILOGUE_BEG followed by some USE insn. > Now, split3 pass

Re: [PATCH 1/2] OpenMP/Fortran: Combined directives with map/firstprivate of same symbol

On 07.12.22 20:09, Julian Brown wrote: On Wed, 26 Oct 2022 12:39:39 +0200 Tobias Burnus wrote: The ICE seems to be because gcc/fortran/trans-openmp.cc's gfc_split_omp_clauses mishandles this as the dump shows the following: #pragma omp target firstprivate(a) map(tofrom:a)

[PATCH] cfgbuild: Fix DEBUG_INSN handling in find_bb_boundaries [PR106719]

Hi! The following testcase FAILs on aarch64-linux. We have some atomic instruction followed by 2 DEBUG_INSNs (if -g only of course) followed by NOTE_INSN_EPILOGUE_BEG followed by some USE insn. Now, split3 pass replaces the atomic instruction with a code sequence which ends with a conditional

[PATCH] i386: Add *concat3_{5,6,7} patterns [PR107627]

Hi! On Thu, Dec 01, 2022 at 09:09:51AM +0100, Jakub Jelinek via Gcc-patches wrote: > BTW, I wonder if we couldn't add additional patterns which would catch > the case where one of the operands is constant. The following patch does add those. The difference with the patch on the 2 testcases is:

RE: Zen4 tuning part 1 - cost tables

[AMD Official Use Only - General] Hi Honza, Thank you for posting the tuning patch. > -Original Message- > From: Jan Hubicka > Sent: Tuesday, December 6, 2022 3:31 PM > To: gcc-patches@gcc.gnu.org; mjam...@suse.cz; Alexander Monakov > ; Kumar, Venkataramanan > ; Joshi, Tejas Sanjay >

Re: [PATCH] arm: fix mve intrinsics scan body tests for C++

Kyrylo Tkachov writes: > Hi Andrea, > >> -Original Message- >> From: Andrea Corallo >> Sent: Wednesday, December 7, 2022 3:03 PM >> To: gcc-patches@gcc.gnu.org >> Cc: Kyrylo Tkachov ; Richard Earnshaw >> ; Andrea Corallo >> Subject: [PATCH] arm: fix mve intrinsics scan body tests for

Re: [PATCH] arm: fix mve intrinsics scan body tests for C++

Kyrylo Tkachov writes: > Hi Andrea, > >> -Original Message- >> From: Andrea Corallo >> Sent: Wednesday, December 7, 2022 3:03 PM >> To: gcc-patches@gcc.gnu.org >> Cc: Kyrylo Tkachov ; Richard Earnshaw >> ; Andrea Corallo >> Subject: [PATCH] arm: fix mve intrinsics scan body tests for

[COMMITTED] libgcc: xtensa: remove stray symbols from X*HAL macro definitions

libgcc/ * config/xtensa/xtensa-config-builtin.h (XCHAL_NUM_AREGS) (XCHAL_ICACHE_SIZE, XCHAL_DCACHE_SIZE, XCHAL_ICACHE_LINESIZE) (XCHAL_DCACHE_LINESIZE, XCHAL_MMU_MIN_PTE_PAGE_SIZE) (XSHAL_ABI): Remove stray symbols from macro definitions. ---

Re: [PATCH] Fix aarch64 PR 99657: ICE with SVE types used without an error

on 2022/12/8 15:43, Richard Sandiford wrote: > "Kewen.Lin" writes: >> on 2022/12/7 20:55, Richard Sandiford wrote: >>> "Kewen.Lin" writes: Hi Richard, on 2022/12/7 17:16, Richard Sandiford wrote: > "Kewen.Lin" writes: >> Hi, >> >> In the recent discussion on how

Re: [PATCH v4, rs6000] Enable have_cbranchcc4 on rs6000

Hi Haochen, on 2022/12/8 11:08, HAO CHEN GUI wrote: > Hi, > This patch enables "have_cbranchcc4" on rs6000 by defining > a "cbranchcc4" expander. "have_cbrnachcc4" is a flag in ifcvt.cc > to indicate if branch by CC bits is invalid or not. With this > flag enabled, some branches can be

Re: [PATCH v5, rs6000] Change mode and insn condition for VSX scalar extract/insert instructions

Hi Haochen, Thanks for the update, some comments are inlined as below. on 2022/12/2 15:03, HAO CHEN GUI wrote: > Hi, > For scalar extract/insert instructions, exponent field can be stored in a > 32-bit register. So this patch changes the mode of exponent field from DI to > SI so that these