Re: [PATCH V3] rs6000: cannot_force_const_mem for HIGH code rtx[PR106460]

Hi, "Kewen.Lin" writes: > Hi Jeff, > > on 2022/9/7 15:08, Jiufu Guo via Gcc-patches wrote: >> Hi, >> >> As the issue in PR106460, a rtx 'high:DI (symbol_ref:DI ("var_48")' is tried >> to store into constant pool and ICE occur. But actually, this rtx represents >> partial address and can not

Re: [PATCH] LoongArch: Pass cache information to optimizer

在 2022/9/27 上午11:16, Xi Ruoyao 写道: On Mon, 2022-09-26 at 15:04 +0800, Lulu Cheng wrote: This change may have to wait for the test results to determine whether to merge. With this patch and my other pending patches - https://gcc.gnu.org/pipermail/gcc-patches/2022-September/602172.html -

Re: [PATCH] dwarf2.h (enum dwarf_source_language): Add new DWARF5 language codes.

On 7/12/22 10:43, Meghan Denny wrote: Updated constants from diff --git a/include/dwarf2.h b/include/dwarf2.h index 40aa5a54f01..87bf764a4fb 100644 --- a/include/dwarf2.h +++ b/include/dwarf2.h [ ... ] I fixed the formatting on the patch and pushed it

Re: [PATCH] Libvtv-test: Fix the problem that scansarif.exp cannot be found in libvtv regression test.

Sorry, I will try to avoid this problem in the future. 在 2022/9/27 上午11:30, WANG Xuerui 写道: On 2022/9/27 11:16, Lulu Cheng wrote: r13-967 add ARRIF output format. However libvtv does not add support. "SARIF support was added in r13-967 but libvtv wasn't updated." (Tip: always remember

Re: [PATCH] Libvtv-test: Fix the problem that scansarif.exp cannot be found in libvtv regression test.

On 2022/9/27 11:16, Lulu Cheng wrote: r13-967 add ARRIF output format. However libvtv does not add support. "SARIF support was added in r13-967 but libvtv wasn't updated." (Tip: always remember that English, unlike Chinese, isn't a "topic-prominent" language, meaning you should

[PATCH] Libvtv-test: Fix the problem that scansarif.exp cannot be found in libvtv regression test.

r13-967 add ARRIF output format. However libvtv does not add support. commit 6cf276ddf22066af780335cd0072d2c27aabe468 Author: David Malcolm Date: Thu Jun 2 15:40:22 2022 -0400 diagnostics: add SARIF output format libvtv/ChangeLog: *

Re: [PATCH] LoongArch: Pass cache information to optimizer

On Mon, 2022-09-26 at 15:04 +0800, Lulu Cheng wrote: > This change may have to wait for the test results to determine whether > to merge. With this patch and my other pending patches - https://gcc.gnu.org/pipermail/gcc-patches/2022-September/602172.html -

Re: [PATCH] LoongArch: Libvtv add LoongArch support.

+ Caroline (the author or libvtv, I hope the email address is still active). On Tue, 2022-09-27 at 10:37 +0800, Lulu Cheng wrote: > I asked my colleagues in the kernel group, this page size may change. > > That there is a macro BIG_PAGE_SIZE comment in vtv-change-permission.h > > written like

Re: [PATCH] LoongArch: Libvtv add LoongArch support.

I asked my colleagues in the kernel group, this page size may change. That there is a macro BIG_PAGE_SIZE comment in vtv-change-permission.h written like this:"Replace '4096' below with correct big page size." I understand that this is to get the page size at runtime, but I don't see where

Re: [PATCH] c++, v2: Implement C++23 P1169R4 - static operator() [PR106651]

On 9/19/22 08:25, Jakub Jelinek wrote: Hi! On Sat, Sep 17, 2022 at 01:30:08PM +0200, Jason Merrill wrote: Below is an updated patch on top of the https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601788.html patch. Ah, OK. I don't think you need to check for C++23 or CALL_EXPR at all,

Re: [PATCH] Add libgo dependency on libbacktrace.

On 8/18/22 00:59, Sergei Trofimovich via Gcc-patches wrote: From: Sergei Trofimovich Noticed missing dependency when regenerated Makefile.in for unrelated change with 'autoget Makefile.def'. The change was lost in basepoints/gcc-12-6861-gaeac414923a ("Revert "Fix PR 67102: Add libstdc++

Re: [PATCH] Ignore debug insns with CONCAT and CONCATN for insn scheduling

On 9/26/22 17:43, Jakub Jelinek wrote: On Mon, Sep 26, 2022 at 05:23:45PM -0600, Jeff Law via Gcc-patches wrote: On 9/26/22 13:52, H.J. Lu wrote: On Sat, Sep 24, 2022 at 1:37 PM Jeff Law wrote: On 9/21/22 16:11, H.J. Lu wrote: On Wed, Sep 7, 2022 at 10:03 AM Jeff Law via Gcc-patches

Re: [patch] libgompd: Add thread handles

For some reason my mail client keeps missing things up. Maybe it is my fault. Anyway this is it again with the right format I hope. /This patch is the initial implementation of OpenMP-API specs book section //20.5.5 with title "Thread Handles". //libgomp/ChangeLog ///2022-07-01 Ahmed Sayed

[patch] libgompd: Add thread handles

/This patch is the initial implementation of OpenMP-API specs book section //20.5.5 with title "Thread Handles". //libgomp/ChangeLog ///2022-07-01 Ahmed Sayed ///* Makefile.am (libgompd_la_SOURCES): Add ompd-threads.c.///* Makefile.in: Regenerate. * team.c (gomp_free_thread): Call

Re: [PATCH] c++: Improve diagnostics about conflicting specifiers

On 9/19/22 03:24, Jakub Jelinek wrote: Hi! On Sat, Sep 17, 2022 at 01:23:59AM +0200, Jason Merrill wrote: I wonder why we don't give an error when setting the conflicting_specifiers_p flag in cp_parser_set_storage_class? We should be able to give a better diagnostic at that point. I didn't

[PATCH v5 2/2] IBM zSystems: Define CODE_LABEL_BOUNDARY

Currently s390 emits the following sequence to store a frame_pc: a: .LASANPC0: lg %r1,.L5-.L4(%r13) la %r1,0(%r1,%r12) stg %r1,176(%r11) .L5: .quad .LASANPC0@GOTOFF The reason GOT

[PATCH v5 1/2] asan: specify alignment for LASANPC labels

gcc/ChangeLog: 2020-06-30 Ilya Leoshkevich * asan.cc (asan_emit_stack_protection): Use CODE_LABEL_BOUNDARY. * defaults.h (CODE_LABEL_BOUNDARY): New macro. * doc/tm.texi: Document CODE_LABEL_BOUNDARY. * doc/tm.texi.in: Likewise. --- gcc/asan.cc| 1 +

[PATCH v5 0/2] IBM zSystems: Improve storing asan frame_pc

Hi, This is a resend of v4 with slightly adjusted commit messages: v1: https://gcc.gnu.org/pipermail/gcc-patches/2019-July/525016.html v2: https://gcc.gnu.org/pipermail/gcc-patches/2019-July/525069.html v3: https://gcc.gnu.org/pipermail/gcc-patches/2020-June/548338.html v4:

Re: [PATCH] Avoid depending on destructor order

On 9/23/22 10:12, Thomas Neumann wrote:     +static const bool in_shutdown = false; I'll let Jason or others decide if this is the right solution.  It seems that in_shutdown also could be declared outside the #ifdef and initialized as "false". sure, either is fine. Moving it outside the

Re: [PATCH] Ignore debug insns with CONCAT and CONCATN for insn scheduling

On Mon, Sep 26, 2022 at 05:23:45PM -0600, Jeff Law via Gcc-patches wrote: > > On 9/26/22 13:52, H.J. Lu wrote: > > On Sat, Sep 24, 2022 at 1:37 PM Jeff Law wrote: > > > > > > On 9/21/22 16:11, H.J. Lu wrote: > > > > On Wed, Sep 7, 2022 at 10:03 AM Jeff Law via Gcc-patches > > > > wrote: > > >

Re: [COMMITTED] Optimize [0 = x & MASK] in range-ops.

On 9/26/22 11:24, Aldy Hernandez via Gcc-patches wrote: For [0 = x & MASK], we can determine that x is ~MASK. This is something we're picking up in DOM thanks to maybe_set_nonzero_bits, but is something we should handle natively. This is a good example of how much easier to maintain the

Re: [PATCH] Ignore debug insns with CONCAT and CONCATN for insn scheduling

On 9/26/22 13:52, H.J. Lu wrote: On Sat, Sep 24, 2022 at 1:37 PM Jeff Law wrote: On 9/21/22 16:11, H.J. Lu wrote: On Wed, Sep 7, 2022 at 10:03 AM Jeff Law via Gcc-patches wrote: On 9/2/2022 8:36 AM, H.J. Lu via Gcc-patches wrote: CONCAT and CONCATN never appear in the insn chain. They

Re: [PATCH] c++: Implement P1467R9 - Extended floating-point types and standard names compiler part except for bfloat16 [PR106652]

On Mon, Sep 26, 2022 at 05:15:12PM -0400, Jason Merrill wrote: > > Anyway, here is an updated patch that adds also _Float{32,64,128}x support > > with DF{32,64,128}x mangling and demangling and the conv->bad_p + pedwarn > > change. __float128 is still distinct from _Float128. > > Looks good with

[committed] libstdc++: Use new built-ins for std::is_convertible traits

Tested powerpc64le-linux. Pushed to trunk. -- >8 -- libstdc++-v3/ChangeLog: * include/std/type_traits (is_convertible, is_convertible_v): Define using new built-in. (is_nothrow_convertible is_nothrow_convertible_v): Likewise. --- libstdc++-v3/include/std/type_traits |

[committed] libstdc++: Update std::pointer_traits to match new LWG 3545 wording

Tested powerpc64le-linux. Pushed to trunk. -- >8 -- It was pointed out in recent LWG 3545 discussion that having a constrained partial specialization of std::pointer_traits can cause ambiguities with program-defined specializations. For example, the addition to the testcase has: template

Ping^3: [PATCH] libcpp: Handle extended characters in user-defined literal suffix [PR103902]

On Wed, Jun 15, 2022 at 03:06:16PM -0400, Lewis Hyatt wrote: > On Tue, Jun 14, 2022 at 05:26:49PM -0400, Lewis Hyatt wrote: > > Hello- > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103902 > > > > The attached patch resolves PR preprocessor/103902 as described in the patch > > message

Re: [EXTERNAL] Re: [PING][PATCH] Add instruction level discriminator support.

On 9/8/22 20:45, Eugene Rozenfeld wrote: Jason, Thank for your suggestion. The patch is updated (attached). @@ -467,12 +471,19 @@ lto_location_cache::apply_location_cache () current_loc = set_block (current_loc, loc.block); else current_loc = LOCATION_LOCUS

Re: [PATCH] c++: Implement P1467R9 - Extended floating-point types and standard names compiler part except for bfloat16 [PR106652]

On 9/19/22 12:39, Jakub Jelinek wrote: On Sat, Sep 17, 2022 at 10:58:54AM +0200, Jason Merrill wrote: I thought it is fairly important because __float128 has been around in GCC for 19 years already. To be precise, I think e.g. for x86_64 GCC 3.4 introduced it, but mangling was implemented only

Re: Extend fold_vec_perm to fold VEC_PERM_EXPR in VLA manner

Prathamesh Kulkarni writes: > On Fri, 23 Sept 2022 at 21:33, Richard Sandiford > wrote: >> >> Prathamesh Kulkarni writes: >> > On Tue, 20 Sept 2022 at 18:09, Richard Sandiford >> > wrote: >> >> >> >> Prathamesh Kulkarni writes: >> >> > On Mon, 12 Sept 2022 at 19:57, Richard Sandiford >> >> >

[PATCH v2] c++: Don't quote nothrow in diagnostic

On Mon, Sep 26, 2022 at 12:34:04PM -0400, Jason Merrill wrote: > On 9/26/22 03:50, Richard Biener wrote: > > On Fri, Sep 23, 2022 at 8:41 PM Marek Polacek via Gcc-patches > > wrote: > > > > > > In > > > Jason noticed that we

Re: [PATCH] Ignore debug insns with CONCAT and CONCATN for insn scheduling

On Sat, Sep 24, 2022 at 1:37 PM Jeff Law wrote: > > > On 9/21/22 16:11, H.J. Lu wrote: > > On Wed, Sep 7, 2022 at 10:03 AM Jeff Law via Gcc-patches > > wrote: > >> > >> > >> On 9/2/2022 8:36 AM, H.J. Lu via Gcc-patches wrote: > >>> CONCAT and CONCATN never appear in the insn chain. They are

Re: Extend fold_vec_perm to fold VEC_PERM_EXPR in VLA manner

On Fri, 23 Sept 2022 at 21:33, Richard Sandiford wrote: > > Prathamesh Kulkarni writes: > > On Tue, 20 Sept 2022 at 18:09, Richard Sandiford > > wrote: > >> > >> Prathamesh Kulkarni writes: > >> > On Mon, 12 Sept 2022 at 19:57, Richard Sandiford > >> > wrote: > >> >> > >> >> Prathamesh

[PATCH][pushed] docs: add missing dash in option name

Pushed as obvious. Martin gcc/ChangeLog: * doc/invoke.texi: Add missing dash for Wanalyzer-exposure-through-uninit-copy. --- gcc/doc/invoke.texi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi index

Re: [PATCH] c++ modules: ICE with class NTTP argument [PR100616]

On Mon, 26 Sep 2022, Patrick Palka wrote: > On Mon, 26 Sep 2022, Nathan Sidwell wrote: > > > On 9/26/22 10:08, Nathan Sidwell wrote: > > > On 9/23/22 09:32, Patrick Palka wrote: > > > > > > > Judging by the two commits that introduced/modified this part of > > > > maybe_register_incomplete_var,

Re: [PATCH] c++ modules: ICE with class NTTP argument [PR100616]

On Mon, 26 Sep 2022, Nathan Sidwell wrote: > On 9/26/22 10:08, Nathan Sidwell wrote: > > On 9/23/22 09:32, Patrick Palka wrote: > > > > > Judging by the two commits that introduced/modified this part of > > > maybe_register_incomplete_var, r196852 and r214333, ISTM the code > > > is really only

Re: [Patch] libgomp/nvptx: Prepare for reverse-offload callback handling

Hi. My main concerns remain not addressed: 1) what I said in the opening paragraphs of my previous email; 2) device-issued atomics are not guaranteed to appear atomic to the host unless using atom.sys and translating for CUDA compute capability 6.0+. Item 2 is a correctness issue. Item 1 I

Re: [PATCH v2] c++: Implement C++23 P2266R1, Simpler implicit move [PR101165]

On 9/20/22 14:19, Marek Polacek wrote: On Tue, Sep 06, 2022 at 10:38:12PM -0400, Jason Merrill wrote: On 9/3/22 12:42, Marek Polacek wrote: This patch implements https://wg21.link/p2266, which, once again, changes the implicit move rules. Here's a brief summary of various changes in this

[COMMITTED] Optimize [0 = x & MASK] in range-ops.

For [0 = x & MASK], we can determine that x is ~MASK. This is something we're picking up in DOM thanks to maybe_set_nonzero_bits, but is something we should handle natively. This is a good example of how much easier to maintain the range-ops entries are versus the ad-hoc pattern matching stuff

Re: [PATCH] c++: P2513R4, char8_t Compatibility and Portability Fix [PR106656]

On 9/23/22 21:16, Marek Polacek wrote: P0482R6, which added char8_t, didn't allow const char arr[] = u8"howdy"; because it said "Declarations of arrays of char may currently be initialized with UTF-8 string literals. Under this proposal, such initializations would become ill-formed." This

Re: [PATCH v2] c++: Instantiate less when evaluating __is_convertible

On 9/26/22 12:25, Marek Polacek wrote: On Mon, Sep 26, 2022 at 11:51:30AM -0400, Patrick Palka wrote: On Mon, 26 Sep 2022, Marek Polacek via Gcc-patches wrote: Jon reported that evaluating __is_convertible in this test leads to instantiating char_traits::eq, which is invalid (because we are

[PATCH] openmp: Add OpenMP assume, assumes and begin/end assumes support

Hi! The following patch implements OpenMP 5.1 #pragma omp assume #pragma omp assumes and #pragma omp begin assumes #pragma omp end assumes directive support for C and C++. Currently it doesn't remember anything from the assumption clauses for later, so is mainly to support the directives and

Re: [PATCH] c++: Don't quote nothrow in diagnostic

On 9/26/22 03:50, Richard Biener wrote: On Fri, Sep 23, 2022 at 8:41 PM Marek Polacek via Gcc-patches wrote: In Jason noticed that we quote "nothrow" in diagnostics even though it's not a keyword in C++. Just removing the

Re: [PATCH] c++: Instantiate less when evaluating __is_convertible

On Mon, Sep 26, 2022 at 05:02:36PM +0100, Jonathan Wakely wrote: > On Mon, 26 Sept 2022 at 16:23, Marek Polacek wrote: > > > > Jon reported that evaluating __is_convertible in this test leads to > > instantiating char_traits::eq, which is invalid (because we > > are trying to call a member

[PATCH v2] c++: Instantiate less when evaluating __is_convertible

On Mon, Sep 26, 2022 at 11:51:30AM -0400, Patrick Palka wrote: > On Mon, 26 Sep 2022, Marek Polacek via Gcc-patches wrote: > > > Jon reported that evaluating __is_convertible in this test leads to > > instantiating char_traits::eq, which is invalid (because we > > are trying to call a member

Re: [PATCH] c++: Instantiate less when evaluating __is_convertible

On 9/26/22 11:51, Patrick Palka wrote: On Mon, 26 Sep 2022, Marek Polacek via Gcc-patches wrote: Jon reported that evaluating __is_convertible in this test leads to instantiating char_traits::eq, which is invalid (because we are trying to call a member function on a char) and so we fail to

Re: [PATCH] c++: Instantiate less when evaluating __is_convertible

On Mon, 26 Sept 2022 at 16:23, Marek Polacek wrote: > > Jon reported that evaluating __is_convertible in this test leads to > instantiating char_traits::eq, which is invalid (because we > are trying to call a member function on a char) N.B. in the original code wasn't trying to do something dumb

Re: [PATCH] c++: Instantiate less when evaluating __is_convertible

On Mon, 26 Sep 2022, Marek Polacek via Gcc-patches wrote: > Jon reported that evaluating __is_convertible in this test leads to > instantiating char_traits::eq, which is invalid (because we > are trying to call a member function on a char) and so we fail to > compile the test. __is_convertible

Re: [PATCH 1/2]middle-end Fold BIT_FIELD_REF and Shifts into BIT_FIELD_REFs alone

On Sun, Sep 25, 2022 at 9:56 PM Tamar Christina wrote: > > > -Original Message- > > From: Andrew Pinski > > Sent: Saturday, September 24, 2022 8:57 PM > > To: Tamar Christina > > Cc: gcc-patches@gcc.gnu.org; nd ; rguent...@suse.de > > Subject: Re: [PATCH 1/2]middle-end Fold

Re: [PATCH] Teach vectorizer to deal with bitfield accesses (was: [RFC] Teach vectorizer to deal with bitfield reads)

On 08/09/2022 12:51, Richard Biener wrote: I'm curious, why the push to redundant_ssa_names? That could use a comment ... So I purposefully left a #if 0 #else #endif in there so you can see the two options. But the reason I used redundant_ssa_names is because ifcvt seems to use that as a

[PATCH] c++: Instantiate less when evaluating __is_convertible

Jon reported that evaluating __is_convertible in this test leads to instantiating char_traits::eq, which is invalid (because we are trying to call a member function on a char) and so we fail to compile the test. __is_convertible doesn't and shouldn't need to instantiate so much, so let's limit it

Update for gcc steering committee page

Updates my affiliation on the web pages. Committed to the trunk. Jeff commit 57e71fb18e8fa397336266f105a22f45f0fa7704 Author: Jeff Law Date: Mon Sep 26 09:19:36 2022 -0600 Update my affiliation on the steering committee page. diff --git a/htdocs/steering.html b/htdocs/steering.html

Update my email address and DCO entry in MAINTAINERS file

Committed to the trunk. commit 1b5432b401934962affe32cd7e42e864224e8062 Author: Jeff Law Date: Mon Sep 26 09:14:55 2022 -0600 Update my address and DCO entry in MAINTAINERS file / * MAINTAINERS: Update my email address and DCO entry. diff --git a/MAINTAINERS

Re: [Patch] libgomp/nvptx: Prepare for reverse-offload callback handling

Hi Alexander, On 21.09.22 22:06, Alexander Monakov wrote: It also goes against the good practice of accelerator programming, which requires queueing work on the accelerator and letting it run asynchronously with the CPU with high occupancy. (I know libgomp still waits for the GPU to finish in

Re: [PATCH] c++ modules: variable template partial spec fixes [PR107033]

On 9/26/22 10:36, Patrick Palka wrote: In r13-2775-g32d8123cd6ce87 I overlooked that we need to adjust the call to add_mergeable_specialization in the MK_partial case to correctly handle variable template partial specializations (it currently assumes we're always dealing with one for a class

Re: [PATCH] c++ modules: ICE with class NTTP argument [PR100616]

On 9/26/22 10:08, Nathan Sidwell wrote: On 9/23/22 09:32, Patrick Palka wrote: Judging by the two commits that introduced/modified this part of maybe_register_incomplete_var, r196852 and r214333, ISTM the code is really only concerned with constexpr static data members (whose initializer may

[PATCH] c++ modules: variable template partial spec fixes [PR107033]

In r13-2775-g32d8123cd6ce87 I overlooked that we need to adjust the call to add_mergeable_specialization in the MK_partial case to correctly handle variable template partial specializations (it currently assumes we're always dealing with one for a class template). This fixes an ICE when

VN, len_store and endianness

Hi, I'm locally testing a branch that enables vll/vstl for partial vector usage i.e. len_load and len_store on s390. I see a FAIL in testsuite/gfortran.dg/power_3.f90. Since r13-1777-gbd9837bc3ca134 we also performe VN for masked/len stores and things go wrong there. The problem seems to be

Re: [PATCH] c++ modules: ICE with class NTTP argument [PR100616]

On 9/23/22 09:32, Patrick Palka wrote: Judging by the two commits that introduced/modified this part of maybe_register_incomplete_var, r196852 and r214333, ISTM the code is really only concerned with constexpr static data members (whose initializer may contain a pointer-to-member for a

RE: [PATCH 1/2]middle-end: RFC: On expansion of conditional branches, give hint if argument is a truth type to backend

> -Original Message- > From: Richard Biener > Sent: Monday, September 26, 2022 1:43 PM > To: Tamar Christina > Cc: gcc-patches@gcc.gnu.org; nd ; jeffreya...@gmail.com; > Richard Sandiford > Subject: Re: [PATCH 1/2]middle-end: RFC: On expansion of conditional > branches, give hint if

Re: [PATCH] Avoid depending on destructor order

Hi Iain, You might also want to include Rainer’s patch, AFAIR patches to fix bootstrap are allowed to proceed as an exception to the usual rules, I was not aware of that. I have pushed the patch below now (including Rainer's change), I will update the code if requested. Best Thomas

[committed] libstdc++: Add #if around non-C++03 code in std::bitset [PR107037]

Tested x86_64-linux, pushed to trunk. -- >8 -- libstdc++-v3/ChangeLog: PR libstdc++/107037 * include/std/bitset (_Base_bitset::_M_do_reset): Use preprocessor conditional around non-C++03 code. * testsuite/20_util/bitset/107037.cc: New test. ---

Re: [PATCH] Avoid depending on destructor order

> On 26 Sep 2022, at 12:49, Thomas Neumann via Gcc-patches > wrote: > > Hi Claudiu, > >> This change prohibits compiling of ARC backend: >>> + gcc_assert (in_shutdown || ob); >> in_shutdown is only defined when ATOMIC_FDE_FAST_PATH is defined, >> while gcc_assert is outside of any ifdef.

Re: [PATCH 1/2]middle-end: RFC: On expansion of conditional branches, give hint if argument is a truth type to backend

On Mon, 26 Sep 2022, Richard Biener wrote: > On Mon, 26 Sep 2022, Tamar Christina wrote: > > > > Maybe the target could use (subreg:SI (reg:BI ...)) as argument. Heh. > > > > But then I'd still need to change the expansion code. I suppose this could > > prevent the issue with changes to code

Re: [PATCH 1/2]middle-end: RFC: On expansion of conditional branches, give hint if argument is a truth type to backend

On Mon, 26 Sep 2022, Tamar Christina wrote: > > Maybe the target could use (subreg:SI (reg:BI ...)) as argument. Heh. > > But then I'd still need to change the expansion code. I suppose this could > prevent the issue with changes to code on other targets. > > > > > We have undocumented addcc,

[PATCH] [PR107009] Set ranges from unreachable edges for all known ranges.

In the conversion of DOM+evrp to DOM+ranger, we missed that evrp was exporting ranges for unreachable edges for all SSA names for which we have ranges for. Instead we have only been exporting ranges for the SSA name in the final conditional to the BB involving the unreachable edge. This patch

Re: [PATCH] Avoid depending on destructor order

Thanks, I haven't observed it. Waiting for it, Claudiu On Mon, Sep 26, 2022 at 2:49 PM Thomas Neumann wrote: > > Hi Claudiu, > > > This change prohibits compiling of ARC backend: > > > >> + gcc_assert (in_shutdown || ob); > > > > in_shutdown is only defined when ATOMIC_FDE_FAST_PATH is

Re: [PATCH] Avoid depending on destructor order

Hi Claudiu, This change prohibits compiling of ARC backend: + gcc_assert (in_shutdown || ob); in_shutdown is only defined when ATOMIC_FDE_FAST_PATH is defined, while gcc_assert is outside of any ifdef. Please can you revisit this line and change it accordingly. I have a patch ready, I am

Re: [PATCH 1/2]middle-end: RFC: On expansion of conditional branches, give hint if argument is a truth type to backend

> Maybe the target could use (subreg:SI (reg:BI ...)) as argument. Heh. But then I'd still need to change the expansion code. I suppose this could prevent the issue with changes to code on other targets. > > > We have undocumented addcc, negcc, etc. patterns, should we have aandcc > > >

Re: [PATCH] Avoid depending on destructor order

Hi Thomas, This change prohibits compiling of ARC backend: > + gcc_assert (in_shutdown || ob); in_shutdown is only defined when ATOMIC_FDE_FAST_PATH is defined, while gcc_assert is outside of any ifdef. Please can you revisit this line and change it accordingly. Thanks, Claudiu

Re: [PATCH 1/2]middle-end: RFC: On expansion of conditional branches, give hint if argument is a truth type to backend

On Mon, 26 Sep 2022, Tamar Christina wrote: > > > This pattern occurs more than 120,000 times in SPECCPU 2017 and so is > > > quite common. > > > How does this help a target? > > So the idea is to communicate that only the bottom bit of the value is > relevant and not the entire value itself.

Re: [Patch] OpenACC: Fix reduction tree-sharing issue [PR106982]

Hi! On 2022-09-26T11:34:48+0200, Richard Biener via Gcc-patches wrote: > On Mon, Sep 26, 2022 at 11:27 AM Tobias Burnus > wrote: >> On 26.09.22 10:32, Richard Biener wrote: >>> On Fri, Sep 23, 2022 at 5:25 PM Tobias Burnus >>> wrote: >> >>> This fixes a tree-sharing ICE. Thanks for looking

Re: [PATCH]middle-end fix floating out of constants in conditionals

> Before my change we had always done the folding *only* for TREE_CONSTANT > (arg) and my change allowed it for some cases of !TREE_CONSTANT (arg), but > I did not want to touch the !TREE_CONSTANT (arg) case at all: ...to touch the TREE_CONSTANT (arg) case at all... -- Eric Botcazou

RE: [PATCH]middle-end Add optimized float addsub without needing VEC_PERM_EXPR.

On Fri, 23 Sep 2022, Tamar Christina wrote: > > -Original Message- > > From: Gcc-patches > bounces+tamar.christina=arm@gcc.gnu.org> On Behalf Of Tamar > > Christina via Gcc-patches > > Sent: Friday, September 23, 2022 9:14 AM > > To: Richard Biener > > Cc: Richard Sandiford ; nd ; >

Re: [PATCH]middle-end fix floating out of constants in conditionals

> I think the better fix would be to only consider TREE_CONSTANT (arg) > if it wasn't constant initially. Because clearly "simplify" intends > to be "constant" here. In fact I wonder why we test !TREE_CONSTANT (arg) > at all, we don't simplify 'arg' ... > > Eric added this test (previosuly we'd

Re: [PATCH 1/2]middle-end: RFC: On expansion of conditional branches, give hint if argument is a truth type to backend

> > This pattern occurs more than 120,000 times in SPECCPU 2017 and so is quite > > common. > How does this help a target? So the idea is to communicate that only the bottom bit of the value is relevant and not the entire value itself. > Why does RTL nonzerop bits not recover thisinformation

Re: [PATCH] reassoc: Handle OFFSET_TYPE like POINTER_TYPE in optimize_range_tests_cmp_bitwise [PR107029[

On Mon, 26 Sep 2022, Jakub Jelinek wrote: > Hi! > > As the testcase shows, OFFSET_TYPE needs the same treatment as > POINTER_TYPE/REFERENCE_TYPE, otherwise we fail the same during the > newly added verification. OFFSET_TYPE is signed though, so unlike > POINTER_TYPE/REFERENCE_TYPE it can also

RE: [PATCH]middle-end simplify complex if expressions where comparisons are inverse of one another.

On Fri, 23 Sep 2022, Tamar Christina wrote: > > -Original Message- > > From: Richard Biener > > Sent: Friday, September 23, 2022 9:10 AM > > To: Tamar Christina > > Cc: Andrew Pinski ; nd ; gcc- > > patc...@gcc.gnu.org > > Subject: RE: [PATCH]middle-end simplify complex if expressions

Re: [PATCH 1/4]middle-end Support not decomposing specific divisions during vectorization.

On Fri, 23 Sep 2022, Tamar Christina wrote: > Hi All, > > In plenty of image and video processing code it's common to modify pixel > values > by a widening operation and then scale them back into range by dividing by > 255. > > e.g.: > >x = y / (2 ^ (bitsize (y)/2)-1 > > This patch adds

[PATCH] reassoc: Handle OFFSET_TYPE like POINTER_TYPE in optimize_range_tests_cmp_bitwise [PR107029[

Hi! As the testcase shows, OFFSET_TYPE needs the same treatment as POINTER_TYPE/REFERENCE_TYPE, otherwise we fail the same during the newly added verification. OFFSET_TYPE is signed though, so unlike POINTER_TYPE/REFERENCE_TYPE it can also trigger with the x < 0 && y < 0 && z < 0 to (x | y | z)

Re: [PATCH 1/2]middle-end: RFC: On expansion of conditional branches, give hint if argument is a truth type to backend

On Fri, 23 Sep 2022, Tamar Christina wrote: > Hi All, > > This is an RFC to figure out how to deal with targets that don't have native > comparisons against QImode values. > > Booleans, at least in C99 and higher are 0-1 valued. This means that we only > really need to test a single bit.

Re: [PATCH]middle-end fix floating out of constants in conditionals

On Fri, 23 Sep 2022, Tamar Christina wrote: > Hi All, > > The following testcase: > > int zoo1 (int a, int b, int c, int d) > { >return (a > b ? c : d) & 1; > } > > gets de-optimized by the front-end since somewhere around GCC 4.x due to a fix > that was added to

Re: [PATCH]middle-end Recognize more conditional comparisons idioms.

On Fri, 23 Sep 2022, Tamar Christina wrote: > Hi All, > > GCC currently recognizes some of these for signed but not unsigned types. > It also has trouble dealing with casts in between because these are handled > by the fold machinery. > > This moves the pattern detection to match.pd instead.

[PATCH][pushed] s390: fix wrong refactoring

Pushed as obvious (tested by Robin) Since r13-2251-g1930c5d05ceff2, the refactoring is not 1:1 and we end up with a wrong rtx type. gcc/ChangeLog: * config/s390/s390.cc (s390_rtx_costs): Remove dest variable and use only dst. --- gcc/config/s390/s390.cc | 15 +++ 1

Re: [Patch] OpenACC: Fix reduction tree-sharing issue [PR106982]

On Mon, Sep 26, 2022 at 11:27 AM Tobias Burnus wrote: > > Hi Richard, > > On 26.09.22 10:32, Richard Biener wrote: > > On Fri, Sep 23, 2022 at 5:25 PM Tobias Burnus wrote: > > This fixes a tree-sharing ICE. It seems as if all unshare_expr > I added were required in this case. [...] > > looks

Re: [Patch] OpenACC: Fix reduction tree-sharing issue [PR106982]

Hi Richard, On 26.09.22 10:32, Richard Biener wrote: On Fri, Sep 23, 2022 at 5:25 PM Tobias Burnus wrote: This fixes a tree-sharing ICE. It seems as if all unshare_expr I added were required in this case. [...] looks like v1/v2/v3 are now unshared twice

[COMMITED] ada: Remove GNATmetric's documentation from GNAT's documentation

From: Boris Yakobowski gcc/ada/ * doc/gnat_ugn/gnat_utility_programs.rst: Remove documentation for gnatmetric. --- .../doc/gnat_ugn/gnat_utility_programs.rst| 1120 + 1 file changed, 1 insertion(+), 1119 deletions(-) diff --git

[COMMITED] ada: Fix location of pragmas coming from aspects in top-level instances

From: Piotr Trojanek This patch fixes an AST anomaly where pragmas that correspond to aspects of a generic package declaration appeared as the auxiliary declarations of the compilation unit for the instantiated package body. In particular, this anomaly happened for aspect Annotate and affected

[COMMITED] ada: Doc: rename Valid_Image to Valid_Value

From: Ghjuvan Lacambre This renaming happened some time ago in the code, but the documentation was not updated. gcc/ada/ * doc/gnat_rm/implementation_defined_attributes.rst: Rename Valid_Image. * gnat_rm.texi: Regenerate. * gnat_ugn.texi: Regenerate. ---

[COMMITED] ada: Remove unreferenced C macro from OS constants template

From: Piotr Trojanek The STR/STR1 macros in OS constants template has been unreferenced since 2005, so we can safely remove them. gcc/ada/ * s-oscons-tmplt.c (STR, STR1): Remove. --- gcc/ada/s-oscons-tmplt.c | 3 --- 1 file changed, 3 deletions(-) diff --git

[COMMITED] ada: Remove unreferenced Rtsfind entries

From: Piotr Trojanek Remove unreferenced entries for finding runtime units and runtime entities by the compiler. Code cleanup using basic grep scripting. gcc/ada/ * rtsfind.ads (RTU_Id): Remove unreferenced packages; fix whitespace. (RE_Id): Remove unreferenced

[COMMITED] ada: Make Original_Aspect_Pragma_Name more precise

From: Tucker Taft This commit makes Original_Aspect_Pragma_Name more precise in cases where there is a second level of indirection caused by pragmas being turned into Check pragmas. gcc/ada/ * sem_util.adb (Original_Aspect_Pragma_Name): Check for Check pragmas. ---

[COMMITED] ada: Improve CUDA host-side and device-side binder support

From: Steve Baird Binder-generated code is not allowed to use Ada2012 syntax. In order to specify an aspect, a pragma must be used. gcc/ada/ * bindgen.adb: When the binder is invoked for the device, specify the CUDA_Global aspect for the adainit and adafinal procedures via

[COMMITED] ada: Delay expansion of iterator specification in preanalysis

From: Piotr Trojanek When preanalysing spec expression (e.g. expression of an expression function), the name of iterator specification should not be expanded. This patch simplifies a complicated condition for delaying expansion within quantified expressions and iterated component associations.

[COMMITED] ada: Document Long_Long_Long_Size parameter for -gnateT

From: Eric Botcazou This was overlooked when the new parameter was created. gcc/ada/ * doc/gnat_ugn/building_executable_programs_with_gnat.rst (-gnateT): Document new parameter Long_Long_Long_Size. * gnat_ugn.texi: Regenerate. ---

[COMMITED] ada: Document support for the mold linker

From: Kévin Le Gouguec gcc/ada/ * doc/gnat_ugn/building_executable_programs_with_gnat.rst (Linker Switches): Document support for mold along with gold; add some advice regarding OpenSSL in the Pro version. * gnat_ugn.texi: Regenerate. ---

[COMMITED] ada: Only reject volatile ghost objects when SPARK_Mode is On

From: Piotr Trojanek SPARK rule that forbids ghost volatile objects is only affecting proof and not generation of object code. It is now only applied where SPARK_Mode is On. This flexibility is needed to compile code automatically instrumented by GNATcoverage. gcc/ada/ * contracts.adb

[COMMITED] ada: Delay expansion of iterated component association

From: Piotr Trojanek When preanalysing spec expression (e.g. expression of an expression function), the name of iterator specification within an iterated component association should not be expanded, especially in GNATprove mode. gcc/ada/ * sem_ch5.adb (Analyze_Iterator_Specification):

[COMMITED] ada: Remove socket definitions for ancient MinGW

From: Piotr Trojanek Modern MinGW defines _WIN32_WINNT as 0xa00, so there is no need go guard against it being lower than 0x0600 or setting it to 0x0501. gcc/ada/ * gsocket.h: Remove redefinition of _WIN32_WINNT. * mingw32.h: Remove conditional definition of _WIN32_WINNT.

[COMMITED] ada: Improve accessibility check generation

From: Justin Squirek Improve accessibility check generation by more precisely identifying cases in which an Original_Node call is needed. Instead of grabbing the Original_Node of a prefix in all cases (since this can cause issues where unanalyzed instance names get referenced) we only obtain

[PATCH] aarch64: Add -march support for Armv9.1-A, Armv9.2-A, Armv9.3-A

Hi all, This is a straightforward patch that allows targeting the architecture revisions mentioned in the subject through -march. These are already supported in binutils. Bootstrapped and tested on aarch64-none-linux-gnu. Pushing to trunk. Thanks, Kyrill gcc/ChangeLog: *

  1   2   >