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

On Wed, Aug 14, 2024 at 4:23 PM Kong, Lingling wrote: > > > > -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

Re: [PATCH v2] aarch64: Improve popcount for bytes [PR113042]

On Wed, Aug 14, 2024 at 2:21 PM Richard Sandiford wrote: > > Andrew Pinski writes: > > For popcount for bytes, we don't need the reduction addition > > after the vector cnt instruction as we are only counting one > > byte's popcount. > > This changes the popcount extend to cover all ALLI rather t

[PATCH v3] aarch64: Improve popcount for bytes [PR113042]

For popcount for bytes, we don't need the reduction addition after the vector cnt instruction as we are only counting one byte's popcount. This changes the popcount extend to cover all ALLI rather than GPI. Changes since v1: * v2 - Use ALLI iterator and combine all into one pattern. Add new

[PATCH] Optimize initialization of small padded objects

When small objects containing padding bits (or bytes) are fully initialized, we will often store them in registers, and setting bitfields and other small fields will attempt to preserve the uninitialized padding bits, which tends to be expensive. Zero-initializing registers, OTOH, tends to be che

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

Hi All, These three value range patches were committed as r15-2922, r15-2923 and r15-2924. Thanks Gui Haochen 在 2024/8/15 5:46, Jeff Law 写道: > > > On 8/14/24 12:38 PM, Sam James wrote: >> Vineet Gupta writes: >> >>> Ping - looks like this is blocking the patches for builtin_isnormal and >>

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

Hans-Peter Nilsson wrote: Date: Wed, 14 Aug 2024 20:58:04 -0500 From: Jacob Bachmeyer Reply-To: jcb62...@gmail.com [...] If this is correct, I will fix it in Git master. (The fix is trivial: change the "I" to "[Ii]" to accept both forms.) Yes, thanks; just don't forget to escape t

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

> Date: Wed, 14 Aug 2024 20:58:04 -0500 > From: Jacob Bachmeyer > Reply-To: jcb62...@gmail.com > Hans-Peter Nilsson wrote: > > (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 newl

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

Hans-Peter Nilsson wrote: (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 (

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

> -Original Message- > From: Haochen Jiang > Sent: Wednesday, August 14, 2024 5:02 PM > To: gcc-patches@gcc.gnu.org > Cc: Liu, Hongtao ; ubiz...@gmail.com > Subject: [PATCH 00/22] Support AVX10.2 ymm rounding > > Hi all, > > The initial patch for AVX10.2 has been merged this week. > > F

Re: [PATCH] gm2: fix bad programming practice identifier warning

Wilken Gottwalt writes: > On Tue, 23 Jul 2024 09:58:56 +0200 > Wilken Gottwalt wrote: > >> Fix using keywords as identifiers to prevent warnings coming from >> Modula-2's own libraries. >> >> m2pim/DynamicStrings.mod:1358:27: note: In procedure ‘Slice’: the symbol >> name ‘end’ is legal as an i

Re: [PATCH] gm2: fix bad programming practice warning

Wilken Gottwalt writes: > On Wed, 24 Jul 2024 12:09:46 +0200 > Wilken Gottwalt wrote: > >> Fix identifier names to be too similar to Modula-2 keywords and causing >> warnings coming from Modula-2's own libraries. >> >> m2/m2iso/StdChans.mod:54:20: note: In implementation module ‘StdChans’: >> e

Re: [PATCH 1/2] Makefile.tpl: drop leftover intermodule cruft

Sam James writes: > intermodule supported was dropped in r0-103106-gde6ba7aee152a0 with some > remaining bits for Fortran removed in r14-1696-gecc96eb5d2a0e5. > > Remove some small leftovers. > > * Makefile.in: Regenerate. > * Makefile.tpl (STAGE1_CONFIGURE_FLAGS: Remove --disable-int

Re: [PATCH v4] diagnostics: Follow DECL_ORIGIN in lhd_print_error_function [PR102061]

On 2024-08-11 04:42, Peter Damianov wrote: Currently, if a warning references a cloned function, the name of the cloned function will be emitted in the "In function 'xyz'" part of the diagnostic, which users aren't supposed to see. This patch follows the DECL_ORIGIN link to get the name of the

Re: [RFC] libstdc++: Replace Ryu with Teju Jagua for float.

On Mon, 5 Aug 2024, Cassio Neri wrote: > Implement the template function teju_jagua which finds the shortest > representation of a floating-point number. The floating-point type is a > template parameter and the implementation is generic enough to handle all > floating-point types of interest, nam

[PATCH 2/2] Makefile.tpl: fix whitespace in licence header

* Makefile.tpl: Fix whitespace. --- Makefile.tpl | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Makefile.tpl b/Makefile.tpl index cbb3c6789dcf..da38dca697ad 100644 --- a/Makefile.tpl +++ b/Makefile.tpl @@ -13,12 +13,12 @@ in # it under the terms of the GNU General

[PATCH 1/2] Makefile.tpl: drop leftover intermodule cruft

intermodule supported was dropped in r0-103106-gde6ba7aee152a0 with some remaining bits for Fortran removed in r14-1696-gecc96eb5d2a0e5. Remove some small leftovers. * Makefile.in: Regenerate. * Makefile.tpl (STAGE1_CONFIGURE_FLAGS: Remove --disable-intermodule. --- Makefile.in

[to-be-committed][RISC-V][PR target/116282] Stabilize pattern conditions

So as expected the core problem with target/116282 is that the cost of certain constant synthesis cases varied depending on whether or not we're allowed to generate new pseudos or not. That in turn meant that in obscure cases an insn might change from recognizable to unrecognizable and trigger

Re: [PATCH] libcpp, c-family, v2: Add (dumb) C23 N3017 #embed support [PR105863]

On Tue, 18 Jun 2024, Jakub Jelinek wrote: > The following patch implements the C23 N3017 "#embed - a scannable, > tooling-friendly binary resource inclusion mechanism" paper. Some initial comments, not yet reviewed the whole patch. > The patch uses --embed-dir= option that clang plans to add abo

Re: [PATCH v4] Target-independent store forwarding avoidance.

On 7/8/24 6:46 AM, Manolis Tsamis wrote: This pass detects cases of expensive store forwarding and tries to avoid them by reordering the stores and using suitable bit insertion sequences. For example it can transform this: [ ... ] So FYI. Clean bootstrap and regression test on m68k, sh4, sh

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

On 8/14/24 3:53 PM, Richard Sandiford wrote: FWIW, I think the work to add a df subreg liveness tracking problem and use it in LRA/IRA would solve the live range problem without needing a clobber. I wonder how that's going? In my last review I suggested a change in representation (a single

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

Jeff Law writes: > On 8/12/24 10:12 AM, Xianmiao Qu wrote: >> The previous patch: >> https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=d8a6945c6ea22efa4d5e42fe1922d2b27953c8cd >> aimed to eliminate redundant MOV instructions by removing calling >> emit_clobber in lower-subreg.cc's resolve_simple_move.

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

On 8/14/24 12:38 PM, Sam James wrote: 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

Re: [PATCH v2] aarch64: Improve popcount for bytes [PR113042]

Andrew Pinski writes: > For popcount for bytes, we don't need the reduction addition > after the vector cnt instruction as we are only counting one > byte's popcount. > This changes the popcount extend to cover all ALLI rather than GPI. > > Changes since v1: > * v2 - Use ALLI iterator and combine

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

This operator is similar to sizeof but can only be applied to an array, and returns its number of elements. FUTURE DIRECTIONS: - We should make it work with array parameters to functions, and somehow magically return the number of elements of the array, regardless of it being really a poin

[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:

[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 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

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] 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] 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

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

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: [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] 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: [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-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

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] 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] 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] 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] 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

[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] 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

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

[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: 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

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: [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

[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: 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

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

[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

> 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] 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

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

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: [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

[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: 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

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

[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: [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

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 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

> 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: 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

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

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

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: [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: [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: 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: 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: [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

[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: 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

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, 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

[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

> 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

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

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, 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

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 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: [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 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

[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

[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 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 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 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 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 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 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 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 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 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 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 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):

  1   2   >