Re: [PATCH-1v4] Value Range: Add range op for builtin isinf

Hi Jeff, May I know your final decision on this patch? https://gcc.gnu.org/pipermail/gcc-patches/2024-July/656937.html Thanks Gui Haochen 在 2024/8/5 22:51, Jeff Law 写道: > > > On 7/23/24 4:39 PM, Andrew MacLeod wrote: >> the range is in r, and is set to [0,0].  this is the false part of what

Re: [PATCH, gfortran] libgfortran: implement fpu-macppc for Darwin, support IEEE arithmetic

Thank you for responding. I have added a changelog (is this a correct way?). Sergey On Wed, Aug 14, 2024 at 12:58 AM FX Coudert wrote: > Hi, > > > I dropped a change to the test file, since you have fixed it > appropriately, and switched to Apple libm convention for flags, as you have > suggest

Re: [Fortran, Patch, PR116292, v1] Fix 15-regression in move_alloc

Hi Thomas, thanks for the review. Committed as gcc-15-2910-gbb2324769c5 Thanks again, Andre On Tue, 13 Aug 2024 13:34:44 +0200 Thomas Koenig wrote: > Hi Andre, > > > attached patch fixes a regression introduced by my previous patch on > > handling _vptr's more consistently. The patch g

Re: Ping^4 [PATCH-2v4] Value Range: Add range op for builtin isfinite

Hi Vinnet, This patch (test cases) relies on former patch (range op for isinf) which hasn't been approval yet. I will commit them as soon as the former patch get approval. Thanks Gui Haochen 在 2024/8/14 1:24, Vineet Gupta 写道: > Hi Hao Gui, > > Can you commit this soon - some of the arch patch

[PATCH] c++: Partially implement CWG 2867 - Order of initialization for structured bindings [PR115769]

Hi! The following patch partially implements CWG 2867 - Order of initialization for structured bindings. The DR requires that initialization of e is sequenced before r_i and that r_i initialization is sequenced before r_j for j > i, we already do it that way, the former ordering is a necessity so

[RFC PATCH] c++: Partially implement for static locals CWG 2867 - Order of initialization for structured bindings [PR115769]

Hi! The following patch extends the CWG 2867 support to function scope static structured bindings. The reason why I'm sending this separately is that I'm afraid it is an ABI change (admittedly for a C++20 P1091R3 feature, but we accept it with warning already in C++11). The current state in both G

Re: [Fortran, Patch, PR102973, v1] Reset flag for parsing proc_ptrs in associate in error case

Hi Harald, thanks for the review. Comitted as gcc-15-2911-g54be14bfd6e. Do you have time for reviewing the pr110033 fix? See here: https://gcc.gnu.org/pipermail/fortran/2024-August/060814.html Yes, it looks lengthy, but it is always the same propagation of the corank and bit of meat in the secon

Re: [patch, fortran] First part of Fortran's unsigned implementation

Hi Thomas, > > may I ask you to run contrib/check_GNU_style.py on your patch? At least on > > my system more than lines 50 are reported. I am drawn to this style issues > > and find it hard to digest the beef of the patch. That's my personal OCD > > unfortunately. > > I did so, and fixed most of w

Re: [RFC][PATCH, aarch64] Implement 16-byte vector mode const0 store by TImode

HAO CHEN GUI writes: > Hi, > I submitted a patch to change the mode checking for > CLEAR_BY_PIECES. > https://gcc.gnu.org/pipermail/gcc-patches/2024-August/660344.html > > It causes some regressions on aarch64. With the patch, > V2x8QImode is used to do clear by pieces instead of TImode as > v

[PATCH v2] i386: Fix some vex insns that prohibit egpr

-Original Message- From: Kong, Lingling Sent: Wednesday, August 14, 2024 4:20 PM To: Kong, Lingling Subject: [PATCH v2] i386: Fix some vex insns that prohibit egpr Although these vex insn have evex counterpart, but when it uses the displayed vex prefix should not support APX EGPR. L

[PATCH V4] fsra: gimple final sra pass for paramters and returns

There are a few PRs (meta-bug PR101926) about accessing aggregate parameters/returns which are passed through registers. A major reason of those issues is when access the aggregate, the temporary stack slots are used without leverage the information about the incoming/outgoing registers. We could

Re: [PATCH V7 1/3] split complicate 64bit constant to memory

Hi, I would like to have a ping for these patches. BR, Jeff(Jiufu Guo) Jiufu Guo writes: > Hi, > > Sometimes, a complicated constant is built via 3(or more) > instructions. Generally speaking, it would not be as fast > as loading it from the constant pool (as the discussions in > PR63281):

Re: v2.1 Draft for a lengthof paper

Hi Jens, Martin, On Wed, Aug 14, 2024 at 08:11:20AM GMT, Jens Gustedt wrote: > > Checking , I see that while several > > projects have a lengthof() macro, all of them use it with semantics > > compatible with this keyword, so it shouldn't break too much. Maybe > > t

[PATCH 06/22] AVX10.2 ymm rounding: Support vcvtps2{, u}{dq, qq} intrins

From: "Hu, Lin1" gcc/ChangeLog: * config/i386/avx10_2roundingintrin.h: New intrins. * config/i386/i386-builtin-types.def: Add new DEF_FUNCTION_TYPE. * config/i386/i386-builtin.def (BDESC): Add new builtins. * config/i386/i386-expand.cc (ix86_expand_round_builtin):

[PATCH 12/22] AVX10.2 ymm rounding: Support vfmadd{132, 231, 213}p{s, d, h} intrins

From: "Hu, Lin1" gcc/ChangeLog: * config/i386/avx10_2roundingintrin.h: New intrins. * config/i386/i386-builtin.def (BDESC): Add new builtins. * config/i386/sse.md: (_fmadd__mask3): Add condition check. gcc/testsuite/ChangeLog: * gcc.target/i386/avx-1.c:

[PATCH 02/22] AVX10.2 ymm rounding: Support vcvtdq2p{s, h} and vcvtpd2p{s, h} intrins

From: "Hu, Lin1" gcc/ChangeLog: * config/i386/avx10_2roundingintrin.h: Add new intrins. * config/i386/i386-builtin-types.def: Add new DEF_FUNCTION_TYPE. * config/i386/i386-builtin.def (BDESC): Add new builtins. * config/i386/i386-expand.cc (ix86_expand_round_built

[PATCH 10/22] AVX10.2 ymm rounding: Support vcvt{, u}w2ph and vdivp{s, d, h} intrins

From: "Hu, Lin1" gcc/ChangeLog: * config/i386/avx10_2roundingintrin.h: New intrins. * config/i386/i386-builtin-types.def: Add new DEF_FUNCTION_TYPE. * config/i386/i386-builtin.def (BDESC): Add new builtins. * config/i386/i386-expand.cc (ix86_expand_round_builtin):

[PATCH 08/22] AVX10.2 ymm rounding: Support vcvttph2{, u}{dq, qq, w} intrins

From: "Hu, Lin1" gcc/ChangeLog: * config/i386/avx10_2roundingintrin.h: New intrins. * config/i386/i386-builtin-types.def: Add new DEF_FUNCTION_TYPE. * config/i386/i386-builtin.def (BDESC): Add new builtins. * config/i386/sse.md (avx512fp16_fix_trunc2): Ex

[PATCH 05/22] AVX10.2 ymm rounding: Support vcvtph2{, u}w and vcvtps2p{d, hx} intrins

From: "Hu, Lin1" gcc/ChangeLog: * config/i386/avx10_2roundingintrin.h: New intrins. * config/i386/i386-builtin-types.def: Add new DEF_FUNCTION_TYPE. * config/i386/i386-builtin.def (BDESC): Add new builtins. * config/i386/i386-expand.cc (ix86_expand_round_builtin):

Re: [PATCH] c++/coroutines: fix passing *this to promise type, again [PR116327]

> On 14 Aug 2024, at 05:46, Jason Merrill wrote: > > On 8/13/24 7:52 PM, Patrick Palka wrote: >> On Tue, 13 Aug 2024, Jason Merrill wrote: >>> On 8/12/24 10:01 PM, Patrick Palka wrote: Tested on x86_64-pc-linux-gnu, does this look OK for trunk/14? -- >8 -- In r15-221

[PATCH 13/22] AVX10.2 ymm rounding: Support vfmaddcph and vfmaddsub{132, 231, 213}p{s, d, h} intrins

From: "Hu, Lin1" gcc/ChangeLog: * config/i386/avx10_2roundingintrin.h: New intrins. * config/i386/i386-builtin-types.def: Add new DEF_FUNCTION_TYPE. * config/i386/i386-builtin.def (BDESC): Add new builtins. * config/i386/sse.md: (_fmaddsub__mask): Add cond

[PATCH 00/22] Support AVX10.2 ymm rounding

Hi all, The initial patch for AVX10.2 has been merged this week. For the upcoming patches, we will first upstream ymm rounding control part. In ymm rounding part, ALL the instructions in AVX512 with 512-bit rounding control will also have 256-bit rounding control in AVX10.2. For clearness, the

[PATCH 03/22] AVX10.2 ymm rounding: Support vcvtpd2{, u}{dq, qq} intrins

From: "Hu, Lin1" gcc/ChangeLog: * config/i386/avx10_2roundingintrin.h: Add new intrins. * config/i386/i386-builtin-types.def: Add new DEF_FUNCTION_TYPE. * config/i386/i386-builtin.def (BDESC): Add new builtins. * config/i386/i386-expand.cc (ix86_expand_round_built

[PATCH 07/22] AVX10.2 ymm rounding: Support vcvtqq2p{s, d, h} and vcvttpd2{, u}{dq, qq} intrins

From: "Hu, Lin1" gcc/ChangeLog: * config/i386/avx10_2roundingintrin.h: New intrins. * config/i386/i386-builtin-types.def: Add new DEF_FUNCTION_TYPE. * config/i386/i386-builtin.def (BDESC): Add new builtins. * config/i386/i386-expand.cc (ix86_expand_round_builtin):

[PATCH 09/22] AVX10.2 ymm rounding: Support vcvttps2{, u}{dq, qq} and vcvtu{dq, qq}2p{s, d, h} intrins

From: "Hu, Lin1" gcc/ChangeLog: * config/i386/avx10_2roundingintrin.h: New intrins. * config/i386/i386-builtin-types.def: Add new DEF_FUNCTION_TYPE. * config/i386/i386-builtin.def (BDESC): Add new builtins. * config/i386/sse.md (unspec_fix_truncv8sfv8si2):

[PATCH 16/22] AVX10.2 ymm rounding: Support vfnmsub{132, 231, 213}p{s, d, h} intrins

From: "Hu, Lin1" gcc/ChangeLog: * config/i386/avx10_2roundingintrin.h: New intrins. * config/i386/i386-builtin.def (BDESC): Add new builtins. * config/i386/sse.md: (_fnmsub__mask3): Add condition check. gcc/testsuite/ChangeLog: * gcc.target/i386/avx-1.c:

[PATCH 11/22] AVX10.2 ymm rounding: Support vfc{madd, mul}cph, vfixupimmp{s, d} intrins

From: "Hu, Lin1" gcc/ChangeLog: * config/i386/avx10_2roundingintrin.h: New intrins. * config/i386/i386-builtin-types.def: Add new DEF_FUNCTION_TYPE. * config/i386/i386-builtin.def (BDESC): Add new builtins. * config/i386/i386-expand.cc (ix86_expand_round_builtin):

[PATCH 15/22] AVX10.2 ymm rounding: Support vfmulcph and vfnmadd{132, 231, 213}p{s, d, h} intrins

From: "Hu, Lin1" gcc/ChangeLog: * config/i386/avx10_2roundingintrin.h: New intrins. * config/i386/i386-builtin.def (BDESC): Add new builtins. gcc/testsuite/ChangeLog: * gcc.target/i386/avx-1.c: Add new builtin test. * gcc.target/i386/sse-13.c: Ditto. * g

[PATCH 19/22] AVX10.2 ymm rounding: Support vmulp{s, d, h} and vrangep{s, d} intrins

From: "Hu, Lin1" gcc/ChangeLog: * config/i386/avx10_2roundingintrin.h: New intrins. * config/i386/i386-builtin-types.def: Add new DEF_FUNCTION_TYPE. * config/i386/i386-builtin.def (BDESC): Add new builtins. * config/i386/i386-expand.cc (ix86_expand_round_builtin):

[PATCH 04/22] AVX10.2 ymm rounding: Support vcvtph2p{s, d, sx} and vcvtph2{, u}{dq, qq} intrins

From: "Hu, Lin1" gcc/ChangeLog: * config/i386/avx10_2roundingintrin.h: New intrins. * config/i386/i386-builtin-types.def: Add new DEF_FUNCTION_TYPE. * config/i386/i386-builtin.def (BDESC): Add new builtins. * config/i386/i386-expand.cc (ix86_expand_round_builtin):

[PATCH 18/22] AVX10.2 ymm rounding: Support v{max, min}p{s, d, h} intrins

From: "Hu, Lin1" gcc/ChangeLog: * config/i386/avx10_2roundingintrin.h: New intrins. * config/i386/i386-builtin.def (BDESC): Add new builtins. gcc/testsuite/ChangeLog: * gcc.target/i386/avx-1.c: Add new builtin test. * gcc.target/i386/sse-13.c: Ditto. * g

[PATCH 01/22] AVX10.2 ymm rounding: Support vadd{s, d, h} and vcmp{s, d, h} intrins

From: "Hu, Lin1" gcc/ChangeLog: * config.gcc: Add avx10_2roundingintrin.h. * config/i386/i386-builtin-types.def: Add new DEF_FUNCTION_TYPE. * config/i386/i386-builtin.def (BDESC): Add new builtins. * config/i386/i386-expand.cc (ix86_expand_round_builtin): Handle

[PATCH 14/22] AVX10.2 ymm rounding: Support vfm{sub, subadd}{132, 231, 213}p{s, d, h} intrins

From: "Hu, Lin1" gcc/ChangeLog: * config/i386/avx10_2roundingintrin.h: New intrins. * config/i386/i386-builtin-types.def: Add new DEF_FUNCTION_TYPE. * config/i386/i386-builtin.def (BDESC): Add new builtins. * config/i386/sse.md: (_fmsub__mask): Add conditi

[PATCH 21/22] AVX10.2 ymm rounding: Support vscalefp{s,d,h} intrins

From: "Hu, Lin1" gcc/ChangeLog: * config/i386/avx10_2roundingintrin.h: New intrins. * config/i386/i386-builtin-types.def: Add new DEF_FUNCTION_TYPE. * config/i386/sse.md: (_scalef): Add condition check. gcc/testsuite/ChangeLog: * gcc.target/i386/avx-1.c:

[PATCH 20/22] AVX10.2 ymm rounding: Support vreducep{s, d, h} and vrndscalep{s, d, h} intrins

From: "Hu, Lin1" gcc/ChangeLog: * config/i386/avx10_2roundingintrin.h: New intrins. * config/i386/i386-builtin.def (BDESC): Add new builtins. * config/i386/sse.md: (reducep): Add condition check. (_rndscale): Ditto. gcc/testsuite/ChangeLog:

[PATCH 17/22] AVX10.2 ymm rounding: Support vgetexpp{s, d, h} and vgetmantp{s, d, h} intrins

From: "Hu, Lin1" gcc/ChangeLog: * config/i386/avx10_2roundingintrin.h: New intrins. * config/i386/i386-builtin-types.def: Add new DEF_FUNCTION_TYPE. * config/i386/i386-builtin.def (BDESC): Add new builtins. * config/i386/i386-expand.cc (ix86_expand_round_builtin):

[PATCH 22/22] AVX10.2 ymm rounding: Support vsqrtp{s, d, h} and vsubp{s, d, h} intrins

From: "Hu, Lin1" gcc/ChangeLog: * config/i386/avx10_2roundingintrin.h: New intrins. * config/i386/i386-builtin.def (BDESC): Add new builtins. gcc/testsuite/ChangeLog: * gcc.target/i386/avx-1.c: Add new builtin test. * gcc.target/i386/sse-13.c: Ditto. * g

Re: [PATCH v3 03/12] libgomp: runtime support for target_device selector

On Sat, Jul 20, 2024 at 02:42:22PM -0600, Sandra Loosemore wrote: > This patch implements the libgomp runtime support for the dynamic > target_device selector via the GOMP_evaluate_target_device function. For kind, isa and arch traits in the device sets we decide based on compiler flags and overri

Re: [Fortran, Patch, PR110033, v1] Fix associate for coarrays

Hi Andre, >From a very rapid scan(in the style of somebody on vacation :-) ) of the two patches, it all looks good to me. Adding the corank structure to gfc_expr is long overdue. Thanks also for rolling select type into the second patch. It would be good if you would check if PRs 46371 and 56496 a

Re: [PATCH v3 03/12] libgomp: runtime support for target_device selector

On Wed, Aug 14, 2024 at 12:25:23PM +0200, Jakub Jelinek wrote: > Now, at least in 5.2 I don't see a restriction that target_device trait > can't be used inside of selectors in a target region. > IMHO that is a bug in the standard. E.g. it says that > "The expression of a device_num trait must eval

RE: v2.1 Draft for a lengthof paper

Sorry for top-posting, my work account is stuck on Outlook. :-/ > For a WG14 paper you should add these findings to support that choice. > Another option would be for WG14 to standardize the then existing > implementation with the double underscores. +1, it's always good to explain prior art and

Re: [PATCH, gfortran] libgfortran: implement fpu-macppc for Darwin, support IEEE arithmetic

> Thank you for responding. > I have added a changelog (is this a correct way?). Content seems ok, lines are maybe too long. Check with contrib/gcc-changelog/git_check_commit.py before pushing. Once that is fine, OK to push. FX

RE: v2.1 Draft for a lengthof paper

Hi Aaron, Am 14. August 2024 13:31:19 MESZ schrieb "Ballman, Aaron" : > Sorry for top-posting, my work account is stuck on Outlook. :-/ > > > For a WG14 paper you should add these findings to support that choice. > > Another option would be for WG14 to standardize the then existing > > implemen

RE: [PATCH V2 02/10] autovectorizer: Add basic support for convert optabs

Hi Victor, > -Original Message- > From: Victor Do Nascimento > Sent: Tuesday, August 13, 2024 1:42 PM > To: gcc-patches@gcc.gnu.org > Cc: Tamar Christina ; claz...@gmail.com; > hongtao@intel.com; s...@gcc.gnu.org; bernds_...@t-online.de; > al...@redhat.com; Victor Do Nascimento > Sub

RE: v2.1 Draft for a lengthof paper

> I think that this argument goes too short. E. g. implementation that already > have compound expressions (or lambdas ;-) may provide a > quality > implementation using `static_assert` and `typeof` alone, and don't have to > touch their compiler at all. > > We should not impose an implementatio

[PATCH] ltmain.sh: allow more flags at link-time

libtool defaults to filtering flags passed at link-time. This brings the filtering in GCC's 'fork' of libtool into sync with upstream libtool commit 22a7e547e9857fc94fe5bc7c921d9a4b49c09f8e. In particular, this now allows some harmless diagnostic flags (especially useful for things like -Werror=o

Re: v2.1 Draft for a lengthof paper

Hi Aaron, Jens, On Wed, Aug 14, 2024 at 02:17:52PM GMT, Jens Gustedt wrote: > Am 14. August 2024 13:31:19 MESZ schrieb "Ballman, Aaron" > : > > Sorry for top-posting, my work account is stuck on Outlook. :-/ > > > > > For a WG14 paper you should add these findings to support that choice. > > > A

Re: [PATCH V2 02/10] autovectorizer: Add basic support for convert optabs

On 8/14/24 13:24, Tamar Christina wrote: Hi Victor, -Original Message- From: Victor Do Nascimento Sent: Tuesday, August 13, 2024 1:42 PM To: gcc-patches@gcc.gnu.org Cc: Tamar Christina ; claz...@gmail.com; hongtao@intel.com; s...@gcc.gnu.org; bernds_...@t-online.de; al...@redhat.co

Re: v2.1 Draft for a lengthof paper

Hi Aaron, On Wed, Aug 14, 2024 at 12:40:41PM GMT, Ballman, Aaron wrote: > > We should not impose an implementation in the language where doing > > it in a header can be completely sufficient. > > But can doing this in a header be completely sufficient in practice? > e.g., the user who passes a po

[PATCH] Update LDPT_REGISTER_CLAIM_FILE_HOOK_V2 linker plugin hook

The new hook allows the linker plugin to distinguish calls to claim_file_handler that know the object is being used by the linker (from ldmain.c:add_archive_element), from calls that don't know it's being used by the linker (from elf_link_is_defined_archive_symbol); in the latter case, the plugin s

Re: [PATCH-1v4] Value Range: Add range op for builtin isinf

On 8/14/24 1:04 AM, HAO CHEN GUI wrote: Hi Jeff, May I know your final decision on this patch? https://gcc.gnu.org/pipermail/gcc-patches/2024-July/656937.html I thought I acked the whole set. Jeff

RE: v2.1 Draft for a lengthof paper

> What regex did you use for searching? I went cheap and easy rather than trying to narrow down: https://sourcegraph.com/search?q=context:global+lang:C+lengthof&patternType=regexp&sm=0 > I was thinking of renaming the proposal to elementsof(), to avoid confusion > between length of an array and

RE: v2.1 Draft for a lengthof paper

Am 14. August 2024 14:40:41 MESZ schrieb "Ballman, Aaron" : > > I think that this argument goes too short. E. g. implementation that > > already have compound expressions (or lambdas ;-) may provide a > quality > > implementation using `static_assert` and `typeof` alone, and don't have to > > t

Re: [PATCH, gfortran] libgfortran: implement fpu-macppc for Darwin, support IEEE arithmetic

Thank you, Iain. I have adjusted a longer line and added an intro sentence before changelog record. On Wed, Aug 14, 2024 at 8:24 PM Iain Sandoe wrote: > > > > On 14 Aug 2024, at 13:17, Sergey Fedorov wrote: > > > > > > > > On Wed, Aug 14, 2024 at 8:03 PM FX Coudert wrote: > > > Thank you for

Re: [PATCH] c++/coroutines: fix passing *this to promise type, again [PR116327]

On Tue, 13 Aug 2024, Jason Merrill wrote: > On 8/13/24 7:52 PM, Patrick Palka wrote: > > On Tue, 13 Aug 2024, Jason Merrill wrote: > > > > > On 8/12/24 10:01 PM, Patrick Palka wrote: > > > > Tested on x86_64-pc-linux-gnu, does this look OK for trunk/14? > > > > > > > > -- >8 -- > > > > > > > >

Re: v2.1 Draft for a lengthof paper

Am Mittwoch, dem 14.08.2024 um 12:40 + schrieb Ballman, Aaron: > > I think that this argument goes too short. E. g. implementation that > > already have compound expressions (or lambdas > > ;-) may provide a > quality implementation using `static_assert` and > > `typeof` alone, and don't have

Re: v2.1 Draft for a lengthof paper

Am 14. August 2024 14:58:16 MESZ schrieb Alejandro Colomar : > Hi Aaron, Jens, > > On Wed, Aug 14, 2024 at 02:17:52PM GMT, Jens Gustedt wrote: > > Am 14. August 2024 13:31:19 MESZ schrieb "Ballman, Aaron" > > : > > > Sorry for top-posting, my work account is stuck on Outlook. :-/ > > > > > > > F

Re: v2.1 Draft for a lengthof paper

Hi Aaron, On Wed, Aug 14, 2024 at 01:21:18PM GMT, Ballman, Aaron wrote: > > What regex did you use for searching? > > I went cheap and easy rather than trying to narrow down: > https://sourcegraph.com/search?q=context:global+lang:C+lengthof&patternType=regexp&sm=0 Ahh, context:global seems to be

RE: v2.1 Draft for a lengthof paper

> I am currently on a summer bike trip, so not able to provide a full reference > implantation. But could do so, once I am back. No need (after thinking on this a bit more, I believe you're right that this can be done in a macro-only implementation; we might not go that route in Clang because o

RE: v2.1 Draft for a lengthof paper

> Ahh, context:global seems to be what I wanted. Where is that documented? For me it is the default when I go to https://sourcegraph.com/search but there's documentation at https://sourcegraph.com/docs/code-search/working/search_contexts > Thanks! I'll rename it to elementsof(). Rather than

Re: [PATCH V2 02/10] autovectorizer: Add basic support for convert optabs

On 8/14/24 13:24, Tamar Christina wrote: It seems to me that this should take a code_helper, create the vector modes and call directly_supported_p, or am I missing something? Ok. Having done some digging around in the git history, I see that `vect_supportable_direct_optab_p', upon which I ba

Re: v2.1 Draft for a lengthof paper

Hi Martin, On Wed, Aug 14, 2024 at 03:50:00PM GMT, Martin Uecker wrote: > An operator that returns an array with all dimensions of a multi-dimensional > array would make a a lot of sense to me. > > > double array[4][3][2]; > > // array_dims(array) = (constexpr size_t[3]){ 4, 3, 2 } And what i

Re: [PATCH] PR tree-optimization/101390: Vectorize modulo operator

Jennifer Schmitz writes: > This patch adds a new vectorization pattern that detects the modulo > operation where the second operand is a variable. > It replaces the statement by division, multiplication, and subtraction. > > The patch was bootstrapped and regtested on aarch64-linux-gnu, no regress

[PATCH] c: Enable -f{,no-}char8_t option for C/ObjC

Hi! The N2653 paper contains: "The proposed change to the type of UTF-8 string literals impacts backward compatibility as described in the following sections. Implementors are encouraged to offer options to disable char8_t support when necessary to preserve compatibility with C17." While we do hav

Re: v2.1 Draft for a lengthof paper

Hi Aaron, On Wed, Aug 14, 2024 at 01:59:58PM GMT, Ballman, Aaron wrote: > > Why would you be looping? lengthof only addresses the outer dimension > > sizeof would need a loop, no ? > > Due to poor reading comprehension, I missed in the paper that lengthof > works on the outer dimension. 😉 I thin

Re: v2.1 Draft for a lengthof paper

Am Mittwoch, dem 14.08.2024 um 16:12 +0200 schrieb Alejandro Colomar: > Hi Martin, > > On Wed, Aug 14, 2024 at 03:50:00PM GMT, Martin Uecker wrote: > > An operator that returns an array with all dimensions of a multi-dimensional > > array would make a a lot of sense to me. > > > > > > double ar

[Patch, rs6000, middle-end] v8: Add implementation for different targets for pair mem fusion

Hello Richard: This patch addresses all the review comments. Common infrastructure using generic code for pair mem fusion of different targets. rs6000 target specific code implement virtual functions defined by generic code. Target specific code are added in rs6000-mem-fusion.cc. Bootstrapped

Re: [Patch, rs6000, middle-end] v7: Add implementation for different targets for pair mem fusion

Hello Richard: On 12/08/24 5:30 pm, Richard Sandiford wrote: > Ajit Agarwal writes: >> [...] >> +static void >> +update_change (set_info *set) >> +{ >> + if (!set->has_any_uses ()) >> +return; >> + >> + auto *use = *set->all_uses ().begin (); >> + do >> +{ >> + auto *next_use = us

Re: [PATCH] (Re: Splitting up 27_io/basic_istream/ignore/wchar_t/94749.cc (takes too long))

> From: Vaseeharan Vinayagamoorthy > Date: Sat, 22 Jun 2024 01:38:09 + Sorry for the late reply. I sort of hoped somebody else would chime in. Maybe the issue has resolved itself in the meantime? > Hi, > > I have noticed that in gcc-13, test05 (in the 94749.cc > testcase) is still enabled

Re: v2.1 Draft for a lengthof paper

On Wed, Aug 14, 2024 at 03:50:21PM GMT, Jens Gustedt wrote: > > > > > > > > That said, I suspect WG14 would not be keen on standardizing > > > > `lengthof` without an ugly keyword given that there are plenty of other > > > > uses of it that would break: > > > > > > > > https://sourcegraph.com/g

[PATCH] c++: c->B::m access resolved through current inst [PR116320]

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk and later backports? -- >8 -- Here when checking the access of (the injected-class-name) B in c->B::m at parse time, we notice its scope B (now the type) is a base of the object type C, so we proceed to use C as qualif

RE: v2.1 Draft for a lengthof paper

> I would love to see a proposal for adding this GNU extension to ISO C. > Did nobody do it yet? I could try to, if I find some time. (But I'll take a > longish time for that; if anyone else does it, it would be great.) It's been discussed but hasn't moved forward because there are design issue

[PATCH] libstdc++-v3: Handle iconv as optional for newlib builds [PR116362]

Regtested cris-elf, both an older newlib (FWIW: before the getentropy issue that I hoped to investigate before summer...maybe next summer) and a fresh checkout, both with/without --enable-newlib-iconv. I'm pleasantly surprised that it works (there are no regressions) with newlib iconv enabled comp

Re: v2.1 Draft for a lengthof paper

Hi Aaron, On Wed, Aug 14, 2024 at 02:07:16PM GMT, Ballman, Aaron wrote: > > Ahh, context:global seems to be what I wanted. Where is that documented? > > For me it is the default when I go to https://sourcegraph.com/search but > there's documentation at > https://sourcegraph.com/docs/code-searc

Re: v2.1 Draft for a lengthof paper

Am Mittwoch, dem 14.08.2024 um 14:52 + schrieb Ballman, Aaron: > > I would love to see a proposal for adding this GNU extension to ISO C. > > Did nobody do it yet? I could try to, if I find some time. (But I'll take > > a longish time for that; if anyone else > > does it, it would be > great

[PATCH] match: Fix A || B not optimized to true when !B implies A [PR114326]

From: kelefth In expressions like (a != b || ((a ^ b) & CST0) == CST1) and (a != b || (a ^ b) == CST), (a ^ b) is folded to false. In the equivalent expressions (((a ^ b) & CST0) == CST1 || a != b) and ((a ^ b) == CST, (a ^ b) || a != b) this is not happening. This patch adds the following simpl

Re: [PATCH] c: Enable -f{,no-}char8_t option for C/ObjC

On Wed, 14 Aug 2024, Jakub Jelinek wrote: > The following patch enables the option also for C/ObjC. I still disapprove of creating the combinatorial complexity of language variants with individual small features like this enabled / disabled, as I said in

Re: [PATCH] c: Enable -f{,no-}char8_t option for C/ObjC

On Wed, Aug 14, 2024 at 03:29:24PM +, Joseph Myers wrote: > On Wed, 14 Aug 2024, Jakub Jelinek wrote: > > > The following patch enables the option also for C/ObjC. > > I still disapprove of creating the combinatorial complexity of language > variants with individual small features like this

Re: v2.1 Draft for a lengthof paper

Am 14. August 2024 16:47:32 MESZ schrieb Alejandro Colomar : > On Wed, Aug 14, 2024 at 03:50:21PM GMT, Jens Gustedt wrote: > > > > > > > > > > That said, I suspect WG14 would not be keen on standardizing > > > > > `lengthof` without an ugly keyword given that there are plenty of > > > > > other u

[PATCH] c++: Implement for static locals CWG 2867 - Order of initialization for structured bindings [PR115769]

On Wed, Aug 14, 2024 at 10:06:24AM +0200, Jakub Jelinek wrote: > Though, now that I think about it again, perhaps what we could do instead > is just make sure the _ZGVZ3barvEDC1x1y1z1wE initialization doesn't have > a CLEANUP_POINT_EXPR in it and wrap both the _ZGVZ3barvEDC1x1y1z1wE > and cp_finish

Re: [PATCH] aarch64: Improve vector constant generation using SVE INDEX instruction [PR113328]

Pengxuan Zheng writes: > SVE's INDEX instruction can be used to populate vectors by values starting > from > "base" and incremented by "step" for each subsequent value. We can take > advantage of it to generate vector constants if TARGET_SVE is available and > the > base and step values are with

Re: [PATCH] Re-add calling emit_clobber in lower-subreg.cc's resolve_simple_move.

On Tue, Aug 13, 2024 at 09:13:37AM +0100, Roger Sayle wrote: > > Hi Xianmiao, > I have no objection to reverting that original patch, if it was indeed made > obsolete by > later changes to the i386 backend. > > The theory at the time was that it was possible for backends to define mov > instructi

[PATCH] libstdc++-v3: testsuite: Prune uncapitalized "in function" linker warning

(CC to the dejagnu project as a heads-up) Regtested cris-elf with a fresh newlib checkout where 2640 libstdc++-v3 tests otherwise fail due to the stubbed newlib _getentropy. Ok to commit? -- >8 -- Newer newlib trigger warnings about certain functions not implemented (_getentropy) when testing li

Re: [PATCH] c++/coroutines: fix passing *this to promise type, again [PR116327]

On 8/14/24 9:47 AM, Patrick Palka wrote: On Tue, 13 Aug 2024, Jason Merrill wrote: On 8/13/24 7:52 PM, Patrick Palka wrote: On Tue, 13 Aug 2024, Jason Merrill wrote: On 8/12/24 10:01 PM, Patrick Palka wrote: Tested on x86_64-pc-linux-gnu, does this look OK for trunk/14? -- >8 -- In r15-22

Re: [PATCH] c++: c->B::m access resolved through current inst [PR116320]

On 8/14/24 10:50 AM, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk and later backports? Yes. -- >8 -- Here when checking the access of (the injected-class-name) B in c->B::m at parse time, we notice its scope B (now the type) is a base of

Re: [PATCH] s390: Fix high-level builtins vec_gfmsum{,_accum}_128

On 8/8/24 20:28, Stefan Schulze Frielinghaus wrote: Starting with r14-9449-g9f2b16ce1efef0 builtins were streamlined with those in LLVM. In particular s390_vgfm{,a}g have been changed from UV16QI to UINT128 in order to match those in LLVM. However, these low-level builtins are directly used by

Re: [PATCH] s390: Remove vector intrinsics

On 8/8/24 20:29, Stefan Schulze Frielinghaus wrote: The following intrinsics are not implemented. Thus, remove them. Ok for mainline? gcc/ChangeLog: * config/s390/vecintrin.h (vec_vstbrh): Remove. (vec_vstbrf): Remove. (vec_vstbrg): Remove. (vec_vstbrq): Remove

Re: [PATCH-1v4] Value Range: Add range op for builtin isinf

Ping - looks like this is blocking the patches for builtin_isnormal and builtin_isfinite ! Thx, -Vineet On 8/5/24 07:51, Jeff Law wrote: > > On 7/23/24 4:39 PM, Andrew MacLeod wrote: >> the range is in r, and is set to [0,0].  this is the false part of what >> is being returned for the range. >

Re: [PATCH-1v4] Value Range: Add range op for builtin isinf

Vineet Gupta writes: > Ping - looks like this is blocking the patches for builtin_isnormal and > builtin_isfinite ! > See https://inbox.sourceware.org/gcc-patches/d9459db0-7301-40f6-a3cf-077017b8c...@gmail.com/. It appears to be approved. (Please also avoid topposting.) > Thx, > -Vineet > >

Re: [PATCH-1v4] Value Range: Add range op for builtin isinf

On 8/14/24 11:38, Sam James wrote: >> Ping - looks like this is blocking the patches for builtin_isnormal and >> builtin_isfinite ! >> > See > https://inbox.sourceware.org/gcc-patches/d9459db0-7301-40f6-a3cf-077017b8c...@gmail.com/. > > It appears to be approved. Sorry, should have refreshed

Re: [PATCH] Fortran: fix minor frontend GMP leaks

Hi Andre, Am 14.08.24 um 07:53 schrieb Andre Vehreschild: Hi Harald, I had a hard time to figure why this is correct, when gfc_array_size() returned false, but now I get it. Ok to commit. I know that reading code is always twice as hard as writing it... ;-) Thanks for checking. Pushed as r1

Re: [Fortran, Patch, PR110033, v1] Fix associate for coarrays

Hi Andre, Am 12.08.24 um 14:11 schrieb Andre Vehreschild: Hi all, the attached two patches fix ASSOCIATE for coarrays, i.e. that a coarray associated to a variable is also a coarray in the block of the ASSOCIATE command. The patch has two parts: 1. pr110033p1_1.patch: Adds a corank member to t

Re: [PATCH] ltmain.sh: allow more flags at link-time

On Wed, Aug 14, 2024 at 8:50 AM Sam James wrote: > > libtool defaults to filtering flags passed at link-time. > > This brings the filtering in GCC's 'fork' of libtool into sync with > upstream libtool commit 22a7e547e9857fc94fe5bc7c921d9a4b49c09f8e. I think it'd be worthwhile to link to the upstr

Re: [PATCH v2] c++: ICE with NSDMIs and fn arguments [PR116015]

On Tue, Aug 13, 2024 at 03:12:01PM -0700, Jason Merrill wrote: > On 8/12/24 7:21 PM, Marek Polacek wrote: > > On Fri, Aug 09, 2024 at 05:15:05PM -0400, Jason Merrill wrote: > > > On 8/9/24 4:21 PM, Marek Polacek wrote: > > > > On Fri, Aug 09, 2024 at 12:58:34PM -0400, Jason Merrill wrote: > > > > >

Re: [PATCH] ltmain.sh: allow more flags at link-time

Eric Gallager writes: > On Wed, Aug 14, 2024 at 8:50 AM Sam James wrote: >> >> libtool defaults to filtering flags passed at link-time. >> >> This brings the filtering in GCC's 'fork' of libtool into sync with >> upstream libtool commit 22a7e547e9857fc94fe5bc7c921d9a4b49c09f8e. > > I think it'd

[PATCH] testuite: Accept vmov.f64

Ok for trunk and releases/gcc-14? -- On Cortex-M55 with fpv5-d16, the vmov.f64 instruction is used. gcc/testsuite/ChangeLog: * armv8_1m-fp64-move-1.c: Accept vmov.f64 instruction. Signed-off-by: Torbjörn SVENSSON --- gcc/testsuite/gcc.target/arm/armv8_1m-fp64-move-1.c | 4 +++- 1 fil

Re: [PATCH] Use add_name_and_src_coords_attributes in modified_type_die

> "Tom" == Tom Tromey writes: Tom> While working on a patch to the Ada compiler, I found a spot in Tom> dwarf2out.cc that calls add_name_attribute where a call to Tom> add_name_and_src_coords_attributes would be better, because the latter Tom> respects DECL_NAMELESS. Tom> gcc Tom>* dwar

[PATCH v9 0/3] c: Add __elementsof__ operator

Hi! v9: - Rename s/lengthof/elementsof/ There are existing lengthof() functions in the wild, which are incompatible with (completely unrelated to) this operator. In the case of elementsof(), we only found macros that expand to the usual sizeof division (plus safety checks in some c

[PATCH v9 1/3] gcc/: Rename array_type_nelts() => array_type_nelts_minus_one()

The old name was misleading. While at it, also rename some temporary variables that are used with this function, for consistency. Link: https://inbox.sourceware.org/gcc-patches/9fffd80-dca-2c7e-14b-6c9b509a7...@redhat.com/T/#m2f661c67c8f7b2c405c8c7fc3152dd85dc729120 Cc: Gabriel Ravier Cc: Marti

[PATCH v9 2/3] Merge definitions of array_type_nelts_top()

There were two identical definitions, and none of them are available where they are needed for implementing __elementsof__. Merge them, and provide the single definition in gcc/tree.{h,cc}, where it's available for __elementsof__, which will be added in the following commit. gcc/ChangeLog:

  1   2   >