Ping^6: [PATCH 0/2] Fix two test failures with --enable-default-pie [PR70150]

Ping^6 https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650763.html I'm quite frustrated why no response to such simple test case fixes. Are people on vacation or something? On Mon, 2024-05-06 at 12:45 +0800, Xi Ruoyao wrote: > In GCC 14.1-rc1, there are two new (comparing to GCC 13) failures

Re: [PATCH] LoongArch: Implement scalar isinf, isnormal, and isfinite via fclass

On Sun, 2024-07-21 at 22:46 -0700, Andrew Pinski wrote: > On Sun, Jul 21, 2024 at 3:57 AM Xi Ruoyao wrote: > > > > On Mon, 2024-07-15 at 15:53 +0800, Lulu Cheng wrote: > > > Hi, > > > > > > g++.dg/opt/pr107569.C and range-sincos.c vrp-float-abs-1.c is the same > > > issue, right? > > > > > > An

RE: [PATCH] i386: Change prefetchi output template

> -Original Message- > From: Haochen Jiang > Sent: Monday, July 22, 2024 2:41 PM > To: gcc-patches@gcc.gnu.org > Cc: Liu, Hongtao ; ubiz...@gmail.com > Subject: [PATCH] i386: Change prefetchi output template > > Hi all, > > For prefetchi instructions, RIP-relative address is explicitl

RE: [PATCH v3] RISC-V: Implement the .SAT_TRUNC for scalar

Kindly ping. Pan -Original Message- From: Li, Pan2 Sent: Monday, July 15, 2024 6:35 PM To: gcc-patches@gcc.gnu.org Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; jeffreya...@gmail.com; rdapp@gmail.com; Li, Pan2 Subject: [PATCH v3] RISC-V: Implement the .SAT_TRUNC for scalar From

Re: [PATCH V5] report message for operator %a on unaddressible operand

Hi Jeff, on 2024/7/16 13:39, Jiufu Guo wrote: > Hi, > > For PR96866, when printing asm code for modifier "%a", an addressable > operand is required. While the constraint "X" allow any kind of > operand even which is hard to get the address directly. e.g. extern > symbol whose address is in TOC.

Re: [PATCH] rs6000, Remove __builtin_vec_set_v1ti,, __builtin_vec_set_v2df, __builtin_vec_set_v2di

Hi Carl, on 2024/7/18 00:01, Carl Love wrote: > GCC maintainers: > > This patch removes the __builtin_vec_set_v1ti, __builtin_vec_set_v2df and > __builtin_vec_set_v2di built-ins.  The users should just use normal C-code to > update the various vector elements.  This change was originally intend

Re: [PATCH] rs6000, remove __builtin_vsx_xvcmp* built-ins

Hi Carl, on 2024/7/17 23:52, Carl Love wrote: > GCC maintainers: > > The following patch removes the three __builtin_vsx_xvcmp[eq|ge|gt]sp  > builtins as they similar to the overloaded vec_cmp[eq|ge|gt] built-ins.  The > difference is the overloaded built-ins return a vector of boolean or a vec

Re: [PATCH-3v5, rs6000] Implement optab_isnormal for SFDF and IEEE128

Hi Haochen, on 2024/7/18 09:45, HAO CHEN GUI wrote: > Hi, > This patch implemented optab_isnormal for SFDF and IEEE128 by > test data class instructions. > > Compared with previous version, the main change is to merge > the patterns of SFDF and IEEE128 into one. > https://gcc.gnu.org/pipermai

Re: [PATCH-2v5, rs6000] Implement optab_isfinite for SFDF and IEEE128

Hi Haochen, on 2024/7/18 09:45, HAO CHEN GUI wrote: > Hi, > This patch implemented optab_isfinite for SFDF and IEEE128 by > test data class instructions. > > Compared with previous version, the main change is to merge > the patterns of SFDF and IEEE128 into one. > https://gcc.gnu.org/pipermai

PING^3 [PATCH] rs6000: Adjust -fpatchable-function-entry* support for dual entry [PR112980]

Hi, Gentle ping this patch: https://gcc.gnu.org/pipermail/gcc-patches/2024-May/651025.html BR, Kewen on 2024/7/12 00:15, Martin Jambor wrote: > Hi, > > can I add myself to the bunch of people who are pinging this? Having > this in will make our life easier. > > Thanks a lot, > > Martin > >

Re: [PATCH v2 3/8] OpenMP: middle-end support for dispatch + adjust_args

Hi PA, as discussed off list, I was stumbling over the call to GOMP_task. I now understand why: I was looking at a different version of the OpenMP spec. Namely, OpenMP 5.2 contains the changes for spec Issue 2741 "dispatch construct data scoping issues". Namely: Performance issue due to 'task

[PATCH 0/3] aarch64: Add march flags for +fp8 arch extensions

This series introduces initial flags and functionality for the fp8 feature. Specifically, the following are added: - functions that enable constructing valid fpm register values. - support for the '+fp8' -march modifier that defines the __ARM_FEATURE_FP8 macro to 1. - support for reading and wr

[PATCH 1/3] aarch64: Add march flags for +fp8 arch extensions

This introduces the relevant flags to enable access to the fpmr register and fp8 intrinsics, which will be added subsequently. The `+fp8' -march modifier defines the __ARM_FEATURE_FP8 macro to 1. gcc/ChangeLog: * config/aarch64/aarch64-c.cc (__ARM_FEATURE_FP8): New. * config/aa

[PATCH 2/3] aarch64: Add support for moving fpm system register

Unlike most system registers, fpmr can be heavily written to in code that exercises the fp8 functionality. That is because every fp8 instrinsic call can potentially change the value of fpmr. Rather than just use a an unspec, we treat the fpmr system register like all other registers and use a move

[PATCH 3/3] aarch64: add fpm register helper functions.

The ACLE declares several helper types and functions to facilitate construction of `fpm` arguments. gcc/ChangeLog: * config/aarch64/arm_acle.h (fpm_t): New type representing fpmr values. (enum __ARM_FPM_FORMAT): New enum representing valid fp8 formats. (enum __ARM_FPM_OVE

Re: [Ping, Patch, Fortran, PR88624, v1] Fix Rejects allocatable coarray passed as a dummy argument

Hi Paul, thanks for the review. I have added a stripped down version of the initial submission as testcase pr88624.f90 (for compile only) and commited as: gcc-15-2190-g913bab282d9 Thanks for the review and regards, Andre On Fri, 19 Jul 2024 17:16:20 +0100 Paul Richard Thomas wrote: >

Re: [PATCH][PR115565] cse: Don't use a valid regno for non-register in comparison_qty

On Mon, 15 Jul 2024, Maciej W. Rozycki wrote: > > > Is it OK to backport now or shall we skip GCC 11 altogether since it's > > > going to be closed after the upcoming 11.5 release later this week? > > > > Yes, please leave 11.5 alone, it's OK for the rest of branches. > > Ack. I'll wait some

Re: [PATCH 1/3] aarch64: Add march flags for +fp8 arch extensions

Hi Claudio, Thanks for working on this. > On 22 Jul 2024, at 11:30, Claudio Bantaloukas > wrote: > > External email: Use caution opening links or attachments > > > This introduces the relevant flags to enable access to the fpmr register and > fp8 intrinsics, which will be added subsequently.

Re: [PATCH 2/3] aarch64: Add support for moving fpm system register

Hi Claudio, > On 22 Jul 2024, at 11:30, Claudio Bantaloukas > wrote: > > External email: Use caution opening links or attachments > > > Unlike most system registers, fpmr can be heavily written to in code that > exercises the fp8 functionality. That is because every fp8 instrinsic call > can

Re: [PATCH 3/3] aarch64: add fpm register helper functions.

Hi Claudio, > On 22 Jul 2024, at 11:30, Claudio Bantaloukas > wrote: > > External email: Use caution opening links or attachments > > > The ACLE declares several helper types and functions to > facilitate construction of `fpm` arguments. > > gcc/ChangeLog: > >* config/aarch64/arm_ac

Re: [PATCH,c++,wwwdocs] bugs: Remove old "export" non-bug

On Mon, 22 Jul 2024 at 07:51, Gerald Pfeifer wrote: > > We have been carrying this note on the "original" export feature for ages, > and I believe it's not actually a FAQ, if it ever was. > > Jonathan moved this down when adding a note on ADL last fall. > > I now propose to drop it. > > Thoughts?

Re: [PATCH 2/3] aarch64: Add support for moving fpm system register

Hi Claudio, I've left a couple of small comments below. On 22/07/2024 09:30, Claudio Bantaloukas wrote: > > Unlike most system registers, fpmr can be heavily written to in code that > exercises the fp8 functionality. That is because every fp8 instrinsic call > can potentially change the value of

[PATCH] constify inchash

The following constifies parts of inchash. Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed. * inchash.h (inchash::end): Make const. (inchash::merge): Take const reference hash argument. (inchash::add_commutative): Likewise. --- gcc/inchash.h | 6 +++--- 1 file

[PATCH] [v2] rtl-optimization/116002 - cselib hash is bad

The following addresses the bad hash function of cselib which uses integer plus for merging. This causes a huge number of collisions for the testcase in the PR and thus very large compile-time. The following rewrites it to use inchash, eliding duplicate mixing of RTX code and mode in some cases a

[PATCH] nvptx: Specify '-mno-alias' for 'gcc.dg/pr60797.c' [PR60797, PR104957] (was: [PATCH] Fix PR60797)

Hi! On 2014-04-11T12:37:42+0200, Richard Biener wrote: > This fixes the endless error reporting for unhandled aliases [...] > *** gcc/testsuite/gcc.dg/pr60797.c(revision 0) > --- gcc/testsuite/gcc.dg/pr60797.c(working copy) > *** > *** 0 > --- 1,8 > + /* { dg-do com

[PATCH] aarch64: Add ACLE intrinsics for AdvSIMD faminmax

The AArch64 FEAT_FAMINMAX extension is optional in Armv9.2 and mandatory in Armv9.5. It introduces instructions for computing the floating point absolute maximum and minimum of the two vectors element-wise. This patch introduces intrinsics for AdvSIMD faminmax extension in the form of the followi

Re: [PATCH] tree-optimization/58416 - SRA wrt FP type replacements

On Sun, 21 Jul 2024, Richard Biener wrote: > As in other places we have to be careful to use FP modes to represent > the underlying bit representation of an object. With x87 floating-point > types there are no load or store instructions that preserve this and > XFmode can have padding. > > When

[PATCH] Fix hash of WIDEN_*_EXPR

We're hashing operand 2 to the temporary hash. Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed. * fold-const.cc (operand_compare::hash_operand): Fix hash of WIDEN_*_EXPR. --- gcc/fold-const.cc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/fol

Re: [PATCH] aarch64: Add ACLE intrinsics for AdvSIMD faminmax

Hi Saurabh, > On 22 Jul 2024, at 13:39, saurabh@arm.com wrote: > > External email: Use caution opening links or attachments > > > The AArch64 FEAT_FAMINMAX extension is optional in Armv9.2 and mandatory > in Armv9.5. It introduces instructions for computing the floating point > absolute max

[Patch, rs6000] Improve suggested unroll factor in finish_cost

Hello All: This patch improve determine_suggested_unroll_factor in finish_cost with reduction factor of loads/stores/non_load_stores. Return unroll factor calculated as per reduction factor with number of loads/stores/non_load_stores (general_ops). Bootstrapped and regtested on powerpc64-linux-g

Ping: [PATCH v2] Provide more contexts for -Warray-bounds warning messages

Hi, Richard, Could you please take a look at the patch and let me know any comment you have (especially on the middle-end part)? David, let me know if you have further comment and suggestions. Thanks a lot. Qing > On Jul 12, 2024, at 10:03, Qing Zhao wrote: > > due to code duplication from

[PATCH] c++/coroutines: correct passing *this to promise type

Tested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps backports? -- >8 -- When passing *this to the promise type ctor (or operator new) (as per [dcl.fct.def.coroutine]/4), we add an explicit cast to lvalue reference, but that's unnecessary since *this is already an lvalue. And it

Re: [PATCH][contrib]: support json output from check_GNU_style_lib.py

Hi Tamar, I wanted to try reviewing a patch and this seemed simple enough so I gave it a shot. Hopefully this saves some time of the maintainer that eventually approves this :). I don't see any bug in the code. I also tried running it on my own input and the output was correct. So functionally

Re: [PATCH] c++: alias of alias tmpl with dependent attrs [PR115897]

On Fri, 19 Jul 2024, Patrick Palka wrote: > On Thu, 18 Jul 2024, Jason Merrill wrote: > > > On 7/18/24 12:45 PM, Patrick Palka wrote: > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does thi look > > > OK for trunk/14? > > > > > > -- >8 -- > > > > > > As a followup of r15-2047-g7954bb4

[PATCH v3] RISC-V: Implement __init_riscv_feature_bits, __riscv_feature_bits, and __riscv_vendor_feature_bits

This provides a common abstraction layer to probe the available extensions at run-time. These functions can be used to implement function multi-versioning or to detect available extensions. The advantages of providing this abstraction layer are: - Easy to port to other new platforms. - Easier to m

Re: [PATCH v3] RISC-V: Implement __init_riscv_feature_bits, __riscv_feature_bits, and __riscv_vendor_feature_bits

Corresponding implementation in compiler-rt already merged in LLVM side, so I plan to merge this into trunk tomorrow if no strong objections. NOTE: This has been tested with clang/llvm within our internal CI. On Mon, Jul 22, 2024 at 10:16 PM Kito Cheng wrote: > > This provides a common abstracti

Re: [PATCH][contrib]: support json output from check_GNU_style_lib.py

On Mon, 22 Jul 2024 at 14:54, Filip Kastl wrote: > > Hi Tamar, > > I wanted to try reviewing a patch and this seemed simple enough so I gave it a > shot. Hopefully this saves some time of the maintainer that eventually > approves this :). > > I don't see any bug in the code. I also tried running

[Fortran, Patch, PR85510, v1] Fix coarray token in associate not linking

Hi all, hi Paul, you asked me to have a look at PR85510 (which the associate meta bug is blocked by). I have come up with the cause. The symbol of the coarray is deemed to be host_associated and therefore the caf_token is not created in the correct scope. I am not familiar with host-association, s

[committed][NFC][PR rtl-optimization/115877] Avoid setting irrelevant bit groups as live in ext-dce

Another patch to refine liveness computations. This should be NFC and is designed to help debugging. In simplest terms the patch avoids setting bit groups outside the size of a pseudo as live. Consider a HImode pseudo, bits 16..63 for such a pseudo don't really have meaning, yet we often set

[patch, libgfortran] PR105361 Incorrect end-of-file condition for derived-type I/O

Hi all, The attached patch fixes this by avoiding looking for and avoiding the EOF condition in the parent READ after returning from the child IO process. I could not think of a simple test case yet since the problem occurred only when redirecting the input to the test program via a pipe. If

Re: [PATCH 3/3] aarch64: add fpm register helper functions.

Kyrylo Tkachov writes: > Hi Claudio, > >> On 22 Jul 2024, at 11:30, Claudio Bantaloukas >> wrote: >> >> External email: Use caution opening links or attachments >> >> >> The ACLE declares several helper types and functions to >> facilitate construction of `fpm` arguments. >> >> gcc/ChangeLog

Re: [PATCH v3] RISC-V: Implement the .SAT_TRUNC for scalar

LGTM. -- Regards Robin

[PATCH] c++: Some cp-tree.def comment fixes

Hi! While reading the fold expression and concept tree comments, I found various spots referring to non-existent macros etc. The following patch attempts to sync that with what is actually implemented. Ok for trunk? 2024-07-22 Jakub Jelinek * cp-tree.def (UNARY_LEFT_FOLD_EXPR): Use

Re: [PATCH] c++: Some cp-tree.def comment fixes

On Mon, Jul 22, 2024 at 05:32:17PM +0200, Jakub Jelinek wrote: > Hi! > > While reading the fold expression and concept tree comments, I found > various spots referring to non-existent macros etc. > > The following patch attempts to sync that with what is actually implemented. > > Ok for trunk?

[pushed] aarch64: Tighten aarch64_simd_mem_operand_p [PR115969]

aarch64_simd_mem_operand_p checked for a memory with a POST_INC or REG address, but it didn't check what kind of register was being used. This meant that it allowed DImode FPRs as well as GPRs. I wondered about rewriting it to use aarch64_classify_address, but this one-line fix seemed simpler. T

[pushed] rtl-ssa: Add debug routines for def_splay_tree

This patch adds debug routines for def_splay_tree, which I found useful while debugging PR116009. Bootstrapped & regression-tested on aarch64-linux-gnu. Pushed as (hopefully) obvious. Richard gcc/ * rtl-ssa/accesses.h (rtl_ssa::pp_def_splay_tree): Declare. (dump, debug): Add ov

[pushed] rtl-ssa: Avoid using a stale splay tree root [PR116009]

In the fix for PR115928, I'd failed to notice that "root" was used later in the function, so needed to be updated. Boostrapped & regression-tested on aarch64-linux-gnu. Pushed as obvious. Richard gcc/ PR rtl-optimization/116009 * rtl-ssa/accesses.cc (function_info::add_def): Se

Re: [PATCH] c++: Some cp-tree.def comment fixes

On Mon, 22 Jul 2024, Jakub Jelinek wrote: > Hi! > > While reading the fold expression and concept tree comments, I found > various spots referring to non-existent macros etc. > > The following patch attempts to sync that with what is actually implemented. > > Ok for trunk? > > 2024-07-22 Jaku

Re: [PATCH] c++: Some cp-tree.def comment fixes

On Mon, Jul 22, 2024 at 11:48:51AM -0400, Patrick Palka wrote: > On Mon, 22 Jul 2024, Jakub Jelinek wrote: > > > Hi! > > > > While reading the fold expression and concept tree comments, I found > > various spots referring to non-existent macros etc. > > > > The following patch attempts to sync t

Fix accounting of offsets in unadjusted_ptr_and_unit_offset

Hi, unadjusted_ptr_and_unit_offset accidentally throws away the offset computed by get_addr_base_and_unit_offset. Instead of passing extra_offset it passes offset. Bootstrapped/regtested x86_64-linux and comitted. Will backport it to gcc14 PR ipa/114207 gcc/ChangeLog: * ipa-pro

Fix modref_eaf_analysis::analyze_ssa_name handling of values dereferenced to function call parameters

Hi, modref_eaf_analysis::analyze_ssa_name misinterprets EAF flags. If dereferenced parameter is passed (to map_iterator in the testcase) it can be returned indirectly which in turn makes it to escape into the next function call. Bootstrapped/rgtested x86_64-linux, comitted. Will backport it to gc

Compare loop bounds in ipa-icf

Hi, this testcase shows another poblem with missing comparators for metadata in ICF. With value ranges available to loop optimizations during early opts we can estimate number of iterations based on guarding condition that can be split away by the fnsplit pass. This patch disables ICF when number o

[committed][4/n][PR rtl-optimization/115877] Correct SUBREG handling in a destination

If we encounter something during SET handling that we can not handle, the safe thing to do is to ignore the destination and continue the loop. We've actually been trying to do slightly better with SUBREG destinations by iterating into SUBREG_REG. It turns out that wasn't working as expecte

Re: Compare loop bounds in ipa-icf

On Mon, Jul 22, 2024 at 06:12:43PM +0200, Jan Hubicka wrote: > Hi, > this testcase shows another poblem with missing comparators for metadata > in ICF. With value ranges available to loop optimizations during early > opts we can estimate number of iterations based on guarding condition that > can b

[PATCH 3/8] libstdc++: Use dg-additional-files in some I/O tests

Tested x86_64-linux. -- >8 -- Use the dg-additional-files directive to declare files that need to be copied into the test's working directory. This is currently redundant (as all .tst and .txt files are copied for all tests) but is a step towards not copying all files. libstdc++-v3/ChangeLog:

[PATCH 4/8] libstdc++: Add file-io-diff to replace @diff@ markup in I/O tests

Tested x86_64-linux. -- >8 -- This adds a new dg-final action to compare two files after a test has run, so that we can verify that fstream operations produce the expected results. With this change, all uses of @diff@ that seem potentially useful have been converted to actually compare the files

[PATCH 6/8] libstdc++: Use dg-additional-files in some non-I/O tests

Tested x86_64-linux. -- >8 -- libstdc++-v3/ChangeLog: * testsuite/20_util/hash/chi2_q_document_words.cc: Use dg-additional-files for input text. * testsuite/performance/ext/pb_ds/all_text_find.cc: Likewise. * testsuite/performance/ext/pb_ds/multimap_text_find.hpp:

[PATCH 8/8] libstdc++: Rename tests [PR12048]

Tested x86_64-linux. -- >8 -- These have the wrong PR number in the filenames. libstdc++-v3/ChangeLog: PR libstdc++/12048 * testsuite/ext/stdio_sync_filebuf/wchar_t/12948-1.cc: Move to... * testsuite/ext/stdio_sync_filebuf/wchar_t/12048-1.cc: ...here. * testsuite

[PATCH 2/8] libstdc++: Replace @require@ markup in some I/O tests

Tested x86_64-linux. -- >8 -- We can replace the @require@ markup with { dg-additional-files ... } directives, so that the required files are explicitly named and are explicitly copied into place for tests that require it. This will allow a later change to remove the "Copy all required data files

[PATCH 5/8] libstdc++: Use dg-additional-files in some algorithm tests

Tested x86_64-linux. -- >8 -- Use the dg-additional-files directive to declare files that need to be copied into the test's working directory. This is currently redundant (as all .tst and .txt files are copied for all tests) but is a step towards not copying all files. libstdc++-v3/ChangeLog:

[PATCH 1/8] libstdc++: Clean up @diff@ markup in some I/O tests

Tested x86_64-linux. -- >8 -- We have a number of 27_io/* tests with comments like this: // @require@ %-*.tst // @diff@ %-*.tst %-*.txt It seems that these declare required data files used by the test and a post-test action to compare the test output with the expected result. We do have tests t

[PATCH 7/8] libstdc++: Stop copying all data files into test directory

Tested x86_64-linux. -- >8 -- This removes the TODO in libstdc++_init, so that we don't copy all *.tst and *.txt files from testsuite/data into every test's working directory. Instead, only the necessary files declared with dg-additional-files are copied. libstdc++-v3/ChangeLog: * tests

Re: [PATCH] testsuite: Allow vst1 instruction

On 2024-07-19 17:22, Richard Earnshaw (lists) wrote: On 19/07/2024 16:10, Torbjorn SVENSSON wrote: On 2024-07-19 16:36, Richard Earnshaw (lists) wrote: On 19/07/2024 14:07, Torbjörn SVENSSON wrote: Ok for trunk and releases/gcc-14? -- On Cortex-A7 with -mfloat-abi=hard and -mfpu=neon, t

[ARC PATCH] Improve performance of SImode right shifts (take #2)

This significantly reworks my previous patch to improve SImode right shifts on ARC CPUs without a barrel shifter when not optimizing for size. This patch provides several additional implementation strategies further reducing the number of cycles required. One feature of !TARGET_BARREL_SHIFTER on

Fix modref's iteraction with store merging

Hi, this patch fixes wrong code in case store-merging introduces load of function parameter that was previously write-only (which happens for bitfields). Without this, the whole store-merged area is consdered to be killed. Bootstrapped/regtested x86_64-linux, comitted. Will backport it to GCC14

Re: [PATCH] c++: Some cp-tree.def comment fixes

On 7/22/24 11:53 AM, Marek Polacek wrote: On Mon, Jul 22, 2024 at 11:48:51AM -0400, Patrick Palka wrote: On Mon, 22 Jul 2024, Jakub Jelinek wrote: Hi! While reading the fold expression and concept tree comments, I found various spots referring to non-existent macros etc. The following patch

[testsuite PATCH] Robustify lib/g++.exp

I often find it useful to run "make -k check" on a cross-compiler even without a supporting toolchain to perform compile-only testing. This works for the gcc and gfortran testsuites, but I'm currently seeing no results reported for g++ due to: Running /home/roger/GCC/combined/gcc/testsuite/g++.dg

Re: [PATCH] rs6000, Remove __builtin_vec_set_v1ti,, __builtin_vec_set_v2df, __builtin_vec_set_v2di

Kewen: On 7/22/24 2:09 AM, Kewen.Lin wrote: Hi Carl, on 2024/7/18 00:01, Carl Love wrote: GCC maintainers: This patch removes the __builtin_vec_set_v1ti, __builtin_vec_set_v2df and __builtin_vec_set_v2di built-ins.  The users should just use normal C-code to update the various vector elem

RE: [PATCH] i386: Add _MM_FROUND_TIES_TO_EVEN to smmintrin.h

In response to feedback from LLVM/clang, I suggest naming the macro `_MM_FROUND_TO_NEAREST_TIES_EVEN`. The updated patch is attached (and the previous one may be disregarded). The clang PR is here: https://github.com/llvm/llvm-project/pull/99691 Regards, Paul -Original message- From:

Re: [PATCH v3] RISC-V: Implement __init_riscv_feature_bits, __riscv_feature_bits, and __riscv_vendor_feature_bits

Hi Kito, On 7/22/2024 8:19 AM, Kito Cheng wrote: Corresponding implementation in compiler-rt already merged in LLVM side, so I plan to merge this into trunk tomorrow if no strong objections. NOTE: This has been tested with clang/llvm within our internal CI. On Mon, Jul 22, 2024 at 10:16 PM

[PATCH] fortran: Support optional dummy as BACK argument of MINLOC/MAXLOC.

From: Mikael Morin Hello, this fixes a null pointer dereference with absent optional dummy passed as BACK argument of MINLOC/MAXLOC. Tested for regression on x86_64-linux. OK for master? -- >8 -- Protect the evaluation of BACK with a check that the reference is non-null in case the expression

Re: [PATCH] c++/coroutines: correct passing *this to promise type

Hi Patrick thanks for looking at this. > On 22 Jul 2024, at 14:43, Patrick Palka wrote: > > Tested on x86_64-pc-linux-gnu, does this look OK for trunk > and perhaps backports? > > -- >8 -- > > When passing *this to the promise type ctor (or operator new) (as > per [dcl.fct.def.coroutine]/4), w

Re: [PATCH] libstdc++: Remove duplicate include header from ranges_algobase.h

The bits/stl_algobase.h header was added to bits/ranges_algobase.h separately through two related commits: https://github.com/gcc-mirror/gcc/commit/674d213ab91871652e96dc2de06e6f50682eebe0 https://github.com/gcc-mirror/gcc/commit/0bb1db32ccf54a9de59bea718f7575f7ef22abf5 The comment for the firs

Re: [PATCH] c++/coroutines: correct passing *this to promise type

On 7/22/24 9:43 AM, Patrick Palka wrote: Tested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps backports? -- >8 -- When passing *this to the promise type ctor (or operator new) (as per [dcl.fct.def.coroutine]/4), we add an explicit cast to lvalue reference, but that's unnecessa

[PATCH] c++: Remove CHECK_CONSTR

Hi! On Mon, Jul 22, 2024 at 11:48:51AM -0400, Patrick Palka wrote: > FWIW this tree code seems to be a vestige of the initial Concepts TS > implementation and is effectively unused, we can remove it outright. Here is a patch which removes that. Bootstrapped/regtested on x86_64-linux and i686-lin

Fix handling of ICF_NOVOPS in ipa-modref

Hi, As shown in somewhat convoluted testcase, ipa-modref is mistreating ECF_NOVOPS as "having no side effects". This come from time when modref cared only about memory accesses and thus it was possible to shortcut on it. This patch removes (hopefully) all those bad shortcuts. Bootstrapped/regtest

Re: [PATCH] c++: Remove CHECK_CONSTR

On 7/22/24 4:45 PM, Jakub Jelinek wrote: Hi! On Mon, Jul 22, 2024 at 11:48:51AM -0400, Patrick Palka wrote: FWIW this tree code seems to be a vestige of the initial Concepts TS implementation and is effectively unused, we can remove it outright. Here is a patch which removes that. Bootstrapp

Re: [PATCH] c++: alias of alias tmpl with dependent attrs [PR115897]

On 7/19/24 10:30 AM, Patrick Palka wrote: On Thu, 18 Jul 2024, Jason Merrill wrote: On 7/18/24 12:45 PM, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does thi look OK for trunk/14? -- >8 -- As a followup of r15-2047-g7954bb4fcb6fa8, we also need to consider depende

Re: [RFC/PATCH] isel: Fold more in gimple_expand_vec_cond_expr with andc/iorc

On Sun, Jun 30, 2024 at 11:17 PM Kewen.Lin wrote: > > Hi, > > As PR115659 shows, assuming c = x CMP y, there are some > folding chances for patterns r = c ? 0/z : z/-1: > - For r = c ? 0 : z, it can be folded into r = ~c & z. > - For r = c ? z : -1, it can be folded into r = ~c | z. > > But BI

Re: [PATCH] MATCH: add abs support for half float

Revised based on the comment and moved it into existing patterns as. gcc/ChangeLog: * match.pd: Extend A CMP 0 ? A : -A into (type)A CMP 0 ? A : -A. Extend A CMP 0 ? A : -A into (type) A CMP 0 ? A : -A. gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/absfloat16.c: New test. Signed-off-by: Kugan Viv

Re: [PATCH v3] RISC-V: Implement __init_riscv_feature_bits, __riscv_feature_bits, and __riscv_vendor_feature_bits

thanks for catching that, seem like we only check for the linux path :) Edwin Lu 於 2024年7月23日 週二 02:45 寫道： > Hi Kito, > > > On 7/22/2024 8:19 AM, Kito Cheng wrote: > > Corresponding implementation in compiler-rt already merged in LLVM > > side, so I plan to merge this into trunk tomorrow if no s

Re: [PATCH] MATCH: add abs support for half float

On Mon, Jul 22, 2024 at 5:26 PM Kugan Vivekanandarajah wrote: > > Revised based on the comment and moved it into existing patterns as. > > gcc/ChangeLog: > > * match.pd: Extend A CMP 0 ? A : -A into (type)A CMP 0 ? A : -A. > Extend A CMP 0 ? A : -A into (type) A CMP 0 ? A : -A. > > gcc/testsuite/C

[PATCH] Relax ix86_hardreg_mov_ok after split1.

ix86_hardreg_mov_ok is added by r11-5066-gbe39636d9f68c4 >The solution proposed here is to have the x86 backend/recog prevent >early RTL passes composing instructions (that set likely_spilled hard >registers) that they (combine) can't simplify, until after reload. >We allow sets fr

RE: [PATCH v3] RISC-V: Implement the .SAT_TRUNC for scalar

Committed, thanks Robin. Pan -Original Message- From: Robin Dapp Sent: Monday, July 22, 2024 11:27 PM To: Li, Pan2 ; gcc-patches@gcc.gnu.org Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; jeffreya...@gmail.com Subject: Re: [PATCH v3] RISC-V: Implement the .SAT_TRUNC for scalar LGTM.

[PATCH 0/1] LoongArch: Remove gawk extension from a generator script.

Builds for the LoongArch target fail if the system "awk" is not "gawk". This patch removes this unnecessary requirement. Thanks to Jan-Benedict Glaw for finding and reporting this issue. Yang Yujie (1): LoongArch: Remove gawk extension from a generator script. gcc/config/loongarch/genopts/ge

[PATCH 1/1] LoongArch: Remove gawk extension from a generator script.

gcc/ChangeLog: * config/loongarch/genopts/gen-evolution.awk: Do not use "length()" to compute the size of an array. --- gcc/config/loongarch/genopts/gen-evolution.awk | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/gcc/config/loongarch/genopts/gen-evolut

[PATCH FYI] [powerpc] [testsuite] reorder dg directives [PR106069]

The dg-do directive appears after dg-require-effective-target in g++.target/powerpc/pr106069.C. That doesn't work the way that was presumably intended. Both of these directives set dg-do-what, but dg-do does so fully and unconditionally, overriding any decisions recorded there by earlier direct

Re: [RFC/PATCH] isel: Fold more in gimple_expand_vec_cond_expr with andc/iorc

Hi Andrew, on 2024/7/23 08:09, Andrew Pinski wrote: > On Sun, Jun 30, 2024 at 11:17 PM Kewen.Lin wrote: >> >> Hi, >> >> As PR115659 shows, assuming c = x CMP y, there are some >> folding chances for patterns r = c ? 0/z : z/-1: >> - For r = c ? 0 : z, it can be folded into r = ~c & z. >> - Fo

Re: [PATCH] rs6000, Remove __builtin_vec_set_v1ti,, __builtin_vec_set_v2df, __builtin_vec_set_v2di

Hi Carl, on 2024/7/23 01:37, Carl Love wrote: > > Kewen: > > On 7/22/24 2:09 AM, Kewen.Lin wrote: >> Hi Carl, >> >> on 2024/7/18 00:01, Carl Love wrote: >>> GCC maintainers: >>> >>> This patch removes the __builtin_vec_set_v1ti, __builtin_vec_set_v2df and >>> __builtin_vec_set_v2di built-ins. 

Re: [PATCH FYI] [powerpc] [testsuite] reorder dg directives [PR106069]

Hi Alexandre, on 2024/7/23 10:32, Alexandre Oliva wrote: > > The dg-do directive appears after dg-require-effective-target in > g++.target/powerpc/pr106069.C. That doesn't work the way that was > presumably intended. Both of these directives set dg-do-what, but > dg-do does so fully and uncondi

[PATCH v2] i386: Change prefetchi output template

Hi all, I tested with %a and it works. Therefore I suppose it is a better solution. Bootstrapped and regtested on x86-64-pc-linux-gnu. Ok for trunk and backport to GCC 13 and 14? Thx, Haochen --- Changes in v2: Use %a in pattern --- For prefetchi instructions, RIP-relative address is explici

Re: [PATCH] x86: Don't enable APX_F in 32-bit mode.

On Thu, Jul 18, 2024 at 5:29 PM Kong, Lingling wrote: > > I adjusted my patch based on the comments by H.J. > And I will add the testcase like gcc.target/i386/pr101395-1.c when the march > for APX is determined. > > Ok for trunk? Synced with LLVM folks, they agreed to this solution. Ok. > > Than

Re: [PATCH] regrename: Skip renaming register pairs [PR115860]

On Sun, Jul 21, 2024 at 11:47 PM Stefan Schulze Frielinghaus wrote: > > It is not trivial to decide when a write of a register pair terminates > or starts a new chain. For example, prior regrename we have > > (insn 91 38 36 5 (set (reg:FPRX2 16 %f0 [orig:76 x ] [76]) > (const_double:FPRX2

[committed][5/n][PR rtl-optimization/115877] Fix handling of input/output operands

So in this patch we're correcting a failure to mark objects live in scenarios like (set (dest) (plus (dest) (src)) When handling set pseudos, we transfer the liveness information from LIVENOW into LIVE_TMP. LIVE_TMP is subsequently used to narrow what bit groups are live for the inputs. T

Re: Yet another SPEC compare failure on trunk

On 7/22/24 10:58, Jeff Law wrote: > On 7/22/24 11:52 AM, Vineet Gupta wrote: >> On 7/9/24 17:26, Jeff Law wrote: >>> On 7/9/24 6:11 PM, Vineet Gupta wrote: Couple weeks ago, 502.gcc was failing (PR/115669) which got fixed promptly. On today's trunk I'm seeing a runtime compare failure

Re: [PATCH] c++: fix wrong ambiguity resolution [PR29834]

On 7/20/24 2:31 PM, Marek Polacek wrote: [ Entering the contest to fix the oldest PR in this cycle. ] Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- This 18-year-old PR reports that we parse certain comma expressions as a declaration rather than statement when the stateme

[PATCH v1] RISC-V: Implement the quad and oct .SAT_TRUNC for scalar

From: Pan Li This patch would like to implement the quad and oct .SAT_TRUNC pattern in the riscv backend. Aka: Form 1: #define DEF_SAT_U_TRUC_FMT_1(NT, WT) \ NT __attribute__((noinline)) \ sat_u_truc_##WT##_to_##NT##_fmt_1 (WT x) \ {

Re: [PATCH] Relax ix86_hardreg_mov_ok after split1.

On Tue, Jul 23, 2024 at 3:08 AM liuhongt wrote: > > ix86_hardreg_mov_ok is added by r11-5066-gbe39636d9f68c4 > > >The solution proposed here is to have the x86 backend/recog prevent > >early RTL passes composing instructions (that set likely_spilled hard > >registers) that they (combin

Re: [PATCH v2] i386: Change prefetchi output template

On Tue, Jul 23, 2024 at 4:59 AM Haochen Jiang wrote: > > Hi all, > > I tested with %a and it works. Therefore I suppose it is a better solution. > > Bootstrapped and regtested on x86-64-pc-linux-gnu. Ok for trunk and backport > to GCC 13 and 14? OK, also for backports. Thanks, Uros. > > Thx, >

[PATCH] ssa: Fix up maybe_rewrite_mem_ref_base complex type handling [PR116034]

Hi! The folding into REALPART_EXPR is correct, used only when the mem_offset is zero, but for IMAGPART_EXPR it didn't check the exact offset value (just that it is not 0). The following patch fixes that by using IMAGPART_EXPR only if the offset is right and using BITFIELD_REF or whatever else othe

  1   2   >