Re: [Patch] OpenMP/Fortran: Permit assumed-size arrays in uniform clause

On Fri, Jul 29, 2022 at 11:47:54AM +0200, Tobias Burnus wrote: > Testcase wise, the run-time testcase libgomp.fortran/examples-4/simd-2.f90 > checks essentially the same, except that it uses an array-descriptor array > (assumed shape) while this testcase uses an assumed-size array. > > I decided f

Re: [Patch] Add libgomp.c-c++-common/pr106449-2.c (was: [committed] openmp: Fix up handling of non-rectangular simd loops with pointer type iterators [PR106449])

On Fri, Jul 29, 2022 at 11:48:08AM +0200, Tobias Burnus wrote: > On 29.07.22 10:03, Jakub Jelinek wrote: > > There were 2 issues visible on this new testcase, one that we didn't have > > special POINTER_TYPE_P handling in a few spots of expand_omp_simd ... > > The other issue was that we put n2 exp

Re: [patch] libgompd: Add thread handles

On Mon, Jul 04, 2022 at 10:34:03PM +0200, Ahmed Sayed Mousse wrote: > *This patch is the initial implementation of OpenMP-API specs book section > **20.5.5 with title "Thread Handles".* Sorry for the delay, have been on vacation. > *I have fixed the first version after revising the notes on it.*

Re: [PATCH] openmp-simd-clone: Match shift type

On Fri, Jul 29, 2022 at 04:53:51PM +0100, Andrew Stubbs wrote: > This patch adjusts the generation of SIMD "inbranch" clones that use integer > masks to ensure that it vectorizes on amdgcn. > > The problem was only that an amdgcn mask is DImode and the shift amount was > SImode, and the difference

Re: [PATCH] openmp-simd-clone: Match shift type

On Fri, Jul 29, 2022 at 06:03:18PM +0100, Andrew Stubbs wrote: > On 29/07/2022 16:59, Jakub Jelinek wrote: > > Doing the fold_convert seems to be a wasted effort to me. > > Can't this be done conditional on whether some change is needed at all > > and just using gimple_build_assign with NOP_EXPR, s

[PATCH] libfortran: Fix up boz_15.f90 on powerpc64le with -mabi=ieeelongdouble [PR106079]

Hi! The boz_15.f90 test FAILs on powerpc64le-linux when -mabi=ieeelongdouble is used (either default through --with-long-double-format=ieee or when used explicitly). The problem is that the read/write transfer routines are called with BT_REAL (or BT_COMPLEX) type and kind 17 which is magic we use

Re: [PATCH] libstdc++: Outline the overlapping case of string _M_replace into a separate function [PR105329]

On Wed, Jul 27, 2022 at 11:33:29AM +0200, Jakub Jelinek via Gcc-patches wrote: > The following patch is partially a workaround for bogus warnings > when the compiler isn't able to fold _M_disjunct call into constant > false, but also an optimization attempt - assuming _M_disjunct (

Re: [PATCH] tree-optimization/106513 - fix mistake in bswap symbolic number shifts

On Wed, Aug 10, 2022 at 03:47:10PM +0200, Richard Biener via Gcc-patches wrote: > This fixes a mistake in typing a local variable in the symbolic > shift routine. > > Bootstrap & regtest pending on x86_64-unknown-linux-gnu. > > PR tree-optimization/106513 > * gimple-ssa-store-merging.

[PATCH] _BitInt bit-field support [PR102989]

Hi! On Fri, Jul 28, 2023 at 06:37:23PM +, Joseph Myers wrote: > Yes, the type used in _Generic isn't fully specified, just the type after > integer promotions in contexts where those occur. Ok. I've removed those static_asserts from the test then, no need to test what isn't fully specified.

[PATCH] c-family: Add _BitInt support for __atomic_*fetch* [PR102989]

Hi! The following patch implements the lowering of __atomic_*fetch* functions where first argument is a pointer to (optionally _Atomic) _BitInt which either doesn't have size 1, 2, 4, 8 or 16 bytes or has 16 byte size but target doesn't support TImode. Patch on top of the _BitInt patch series. Te

Re: [PATCH] match.pd: Canonicalize (signed x << c) >> c [PR101955]

> Canonicalizes (signed x << c) >> c into the lowest > precision(type) - c bits of x IF those bits have a mode precision or a > precision of 1. Also combines this rule with (unsigned x << c) >> c -> x & > ((unsigned)-1 >> c) to prevent duplicate pattern. Tested successfully on > x86_64 and x86 targ

Re: [PATCH 1/5] Middle-end _BitInt support [PR102989]

On Fri, Aug 04, 2023 at 01:25:07PM +, Richard Biener wrote: > > @@ -144,6 +144,9 @@ DEFTREECODE (BOOLEAN_TYPE, "boolean_type > > and TYPE_PRECISION (number of bits used by this type). */ > > DEFTREECODE (INTEGER_TYPE, "integer_type", tcc_type, 0) Thanks. > > +/* Bit-precise integer type

[PATCH] _Decimal* to _BitInt conversion support [PR102989]

Hi! Repost because the patch was too large. On Fri, Jul 28, 2023 at 06:03:33PM +, Joseph Myers wrote: > Note that representations with too-large significand are defined to be > noncanonical representations of zero, so you need to take care of that in > decoding BID. Done. > You could e.g. h

Re: [PATCH] libsanitizer: Fix SPARC stacktraces

On Mon, Aug 07, 2023 at 11:13:10AM +0200, Rainer Orth wrote: > As detailed in LLVM Issue #57624 > (https://github.com/llvm/llvm-project/issues/57624), a patch to > sanitizer_internal_defs.h broke SPARC stacktraces in the sanitizers. > The issue has now been fixed upstream (https://reviews.llvm.org/

[PATCH] _BitInt to _Decimal* conversion support [PR102989]

Hi! The following patch on top of the _Decimal* to _BitInt conversion support patch (and obviously the _BitInt patch series) implements the _BitInt to _Decimal{32,64,128} conversions. These functions do at most two divisions, one possibly by very large power of 10 for which the code just checks i

Re: Intel AVX10.1 Compiler Design and Support

On Tue, Aug 08, 2023 at 03:13:09PM +0800, Haochen Jiang via Gcc-patches wrote: > We will send out our initial support of AVX10 and some sample patches in this > mailing thread. And there will be more coming up afterwards. Therefore, we > would > like to share our proposed AVX10 design in GCC. > >

Re: [PATCH] [X86] Workaround possible CPUID bug in Sandy Bridge.

On Tue, Aug 08, 2023 at 03:56:00PM +0800, liuhongt via Gcc-patches wrote: > + /* According to document, when subleaf is invliad, EAX,EBX,ECX,EDX > should s/invliad/invalid/ Jakub

Re: [RFC] GCC Security policy

On Tue, Aug 08, 2023 at 02:52:57PM +0200, Richard Biener via Gcc-patches wrote: > There's probably external tools to do this, not sure if we should replicate > things in the driver for this. > > But sure, I think the driver is the proper point to address any of such > issues - iff we want to addre

[PATCH] testsuite: Add runtime _BitInt stdatomic.h tests [PR102989]

Hi! On Thu, Aug 03, 2023 at 05:19:54PM +, Joseph Myers wrote: > It would be good to have execution tests for these operations (so probably > in gcc.dg/atomic so that libatomic is linked in automatically as needed). Ok, following patch does that, tested on x86_64-linux. 2023-08-08 Jakub Jel

Re: [RFC] GCC Security policy

On Tue, Aug 08, 2023 at 10:30:10AM -0400, Siddhesh Poyarekar wrote: > > Do you have a suggestion for the language to address libgcc, libstdc++, > > etc. and libiberty, libbacktrace, etc.? > > I'll work on this a bit and share a draft. BTW, I think we should perhaps differentiate between productio

Re: [PATCH] aarch64: enable mixed-types for aarch64 simdclones

On Wed, Aug 09, 2023 at 05:55:28PM +0100, Richard Sandiford wrote: > Jakub: do you remember what the reason was? I don't mind dropping > "function", but it feels weird to drop the quotes around "simd". > Seems like, if we do that, there'll one day be a patch to add > them back. :) Because in Open

Re: [PATCH] aarch64: enable mixed-types for aarch64 simdclones

On Wed, Aug 09, 2023 at 06:27:20PM +0100, Richard Sandiford wrote: > Jakub Jelinek writes: > > On Wed, Aug 09, 2023 at 05:55:28PM +0100, Richard Sandiford wrote: > >> Jakub: do you remember what the reason was? I don't mind dropping > >> "function", but it feels weird to drop the quotes around "s

[PATCH 0/12] GCC _BitInt support [PR102989]

Hi! The following patch series introduces support for C23 bit-precise integer types. In short, they are similar to other integral types in many ways, just aren't subject for integral promotions if smaller than int and they can have even much wider precisions than ordinary integer types. This ser

[PATCH 1/12] expr: Small optimization [PR102989]

Hi! Small optimization to avoid testing modifier multiple times. 2023-08-09 Jakub Jelinek PR c/102989 * expr.cc (expand_expr_real_1) : Add an early return for EXPAND_WRITE or EXPAND_MEMORY modifiers to avoid testing it multiple times. --- gcc/expr.cc.jj 2

[PATCH 2/12] lto-streamer-in: Adjust assert [PR102989]

Hi! With _BitInt(575) or any other _BitInt(513) or larger constants we can run into this assertion. MAX_BITSIZE_MODE_ANY_INT is just a value from which WIDE_INT_MAX_PRECISION is derived. 2023-08-09 Jakub Jelinek PR c/102989 * lto-streamer-in.cc (lto_input_tree_1): Assert TYPE

[PATCH 3/12] phiopt: Fix phiopt ICE on vops [PR102989]

Hi! I've ran into ICE on gcc.dg/torture/bitint-42.c with -O1 or -Os when enabling expensive tests, and unfortunately I can't reproduce without _BitInt. The IL before phiopt3 has: [local count: 203190070]: # .MEM_428 = VDEF <.MEM_367> bitint.159 = VIEW_CONVERT_EXPR(*.LC3); goto ; [100.00%

[PATCH 4/12] Middle-end _BitInt support [PR102989]

Hi! The following patch introduces the middle-end part of the _BitInt support, a new BITINT_TYPE, handling it where needed, except the lowering pass and sanitizer support. 2023-08-09 Jakub Jelinek PR c/102989 * tree.def (BITINT_TYPE): New type. * tree.h (TREE_CHECK6, T

[PATCH 6/12] i386: Enable _BitInt on x86-64 [PR102989]

Hi! The following patch enables _BitInt support on x86-64, the only target which has _BitInt specified in psABI. 2023-08-09 Jakub Jelinek PR c/102989 * config/i386/i386.cc (classify_argument): Handle BITINT_TYPE. (ix86_bitint_type_info): New function. (TARGET_C

[PATCH 7/12] ubsan: _BitInt -fsanitize=undefined support [PR102989]

Hi! The following patch introduces some -fsanitize=undefined support for _BitInt, but some of the diagnostics is limited by lack of proper support in the library. I've filed https://github.com/llvm/llvm-project/issues/64100 to request proper support, for now some of the diagnostics might have less

[PATCH 9/12] libgcc _BitInt support [PR102989]

Hi! This patch adds the library helpers for multiplication, division + modulo and casts from and to floating point (both binary and decimal). As described in the intro, the first step is try to reduce further the passed in precision by skipping over most significant limbs with just zeros or sign b

[PATCH 10/12] C _BitInt support [PR102989]

Hi! This patch adds the C FE support, c-family support, small libcpp change so that 123wb and 42uwb suffixes are handled plus glimits.h change to define BITINT_MAXWIDTH macro. The previous patches really do nothing without this, which enables all the support. 2023-08-09 Jakub Jelinek

Re: [PATCH 3/12] phiopt: Fix phiopt ICE on vops [PR102989]

On Wed, Aug 09, 2023 at 11:27:48AM -0700, Andrew Pinski wrote: > Maybe it is better to punt for VOPS after the call to > single_non_singleton_phi_for_edges since none of functions called > afterwards support VOPs. > That is something like: > diff --git a/gcc/tree-ssa-phiopt.cc b/gcc/tree-ssa-phiopt

Re: [PATCH 3/12] phiopt: Fix phiopt ICE on vops [PR102989]

On Wed, Aug 09, 2023 at 01:06:22PM -0700, Andrew Pinski wrote: > That was my next thought, returning NULL from > single_non_singleton_phi_for_edges if it would return a virtual OP > might be better even. > Either version of these patches are ok with me (though I am not the > maintainer here). In p

Re: Intel AVX10.1 Compiler Design and Support

On Wed, Aug 09, 2023 at 08:43:00PM +, Joseph Myers wrote: > At this point it seems appropriate to remind people of another ABI > consideration for vector extensions. glibc's libmvec defines vector > versions of various functions, including AVX512 ones (of course those > function versions on

Re: [PATCH 0/12] GCC _BitInt support [PR102989]

On Thu, Aug 10, 2023 at 06:55:05AM +, Richard Biener wrote: > On Wed, 9 Aug 2023, Joseph Myers wrote: > > > On Wed, 9 Aug 2023, Jakub Jelinek via Gcc-patches wrote: > > > > > - _Complex _BitInt(N) isn't supported; again mainly because none of the > &

[PATCH 13/12] C _BitInt incremental fixes [PR102989]

On Wed, Aug 09, 2023 at 09:17:57PM +, Joseph Myers wrote: > > - _Complex _BitInt(N) isn't supported; again mainly because none of the > > psABIs > > mention how those should be passed/returned; in a limited way they are > > supported internally because the internal functions into which > >

Re: [PATCH] match.pd: Implement missed optimization ((x ^ y) & z) | x -> (z & y) | x [PR109938]

On Tue, Aug 08, 2023 at 03:18:51PM +0200, Richard Biener via Gcc-patches wrote: > On Fri, Aug 4, 2023 at 11:49 PM Drew Ross via Gcc-patches > wrote: > > > > Adds a simplification for ((x ^ y) & z) | x to be folded into > > (z & y) | x. Merges this simplification with ((x | y) & z) | x -> (z & y) |

Re: [V2][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

On Thu, Aug 10, 2023 at 04:38:21PM +0200, Martin Uecker wrote: > Am Donnerstag, dem 10.08.2023 um 13:59 + schrieb Qing Zhao: > > > > > On Aug 10, 2023, at 2:58 AM, Martin Uecker wrote: > > > > > > Am Mittwoch, dem 09.08.2023 um 20:10 + schrieb Qing Zhao: > > > > > > > > > On Aug 9, 2023

Re: Intel AVX10.1 Compiler Design and Support

On Thu, Aug 10, 2023 at 03:08:11PM +, Zhang, Annita via Gcc-patches wrote: > > IMO it is not acceptable for AVX10-256 to generate zmm registers. > > > > If I have to choose among the three proposal, the second is better. > > > > But the best choice I suppose is to keep what we are doing curre

[PATCH 13/12 v2] C _BitInt incremental fixes [PR102989]

On Thu, Aug 10, 2023 at 12:10:07PM +0200, Jakub Jelinek via Gcc-patches wrote: > Here is an incremental patch which does that: Bootstrap/regtest on i686-linux (next to x86_64-linux where it went fine) revealed I forgot to add { target bitint } to dg-do compile lines. Here is an updated pa

[PATCH] c, v2: Add __typeof_unqual__ and __typeof_unqual support

Hi! I'd like to ping this patch. Reposting it as the extend.texi hunk didn't apply cleanly anymore. Bootstrapped/regtested again on x86_64-linux and i686-linux, ok for trunk? On Mon, Jun 12, 2023 at 09:51:22PM +0200, Jakub Jelinek via Gcc-patches wrote: > As I mentioned in my std

[PATCH] c, c++, v2: Accept __builtin_classify_type (typename)

Hi! I'd like to ping this patch. Reposting it as I found a typo in the documentation - s/builtin-in/built-in/. Bootstrapped/regtested again on x86_64-linux and i686-linux, ok for trunk? On Mon, Jun 12, 2023 at 09:57:17PM +0200, Jakub Jelinek via Gcc-patches wrote: > As mention

[PATCH] c, v2: Add stdckdint.h header for C23

n the compiler and C library. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? On Mon, Jun 12, 2023 at 09:59:34PM +0200, Jakub Jelinek via Gcc-patches wrote: > The following patch is an updated version of the patch I've posted > on Saturday, on top of the 2 patches I

[PATCH] stdckdint.h _BitInt test

Hi! The following patch (on top of the stdckdint.h patch and _BitInt patch series) adds a test for _BitInt diagnostics of ckd_{add,sub,mul} macros. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2023-08-10 Jakub Jelinek * gcc.dg/stdckdint-3.c: New test. --- gcc

[PATCH] match.pd, v2: Implement missed optimization ((x ^ y) & z) | x -> (z & y) | x [PR109938]

Hi! On Thu, Aug 10, 2023 at 12:28:24PM +0200, Jakub Jelinek via Gcc-patches wrote: > On Tue, Aug 08, 2023 at 03:18:51PM +0200, Richard Biener via Gcc-patches > wrote: > > On Fri, Aug 4, 2023 at 11:49 PM Drew Ross via Gcc-patches > > wrote: > > > > > > Adds a

Re: Intel AVX10.1 Compiler Design and Support

On Thu, Aug 10, 2023 at 03:08:31PM +, Jiang, Haochen via Gcc-patches wrote: > There are lots of discussions on arch level and ABIs and I really appreciate > that. > > For the arch level issue, it might be a little early to discuss and should > not block > these patches. > > For ABI issue, t

Re: [V2][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

On Thu, Aug 10, 2023 at 12:30:06PM -0400, Siddhesh Poyarekar wrote: > The definition of __bos/__bdos allows us the freedom to *estimate* rather > than be precise, so I'd go for sizeof(x) + N * sizeof(*x.a) since it's bound > to give the more conservative answer of the two. To be precise, we have t

Re: [PATCH] c, c++, v2: Accept __builtin_classify_type (typename)

On Thu, Aug 10, 2023 at 05:44:20PM -0400, Jason Merrill wrote: > Hmm, you really think there's any code at all in the wild relying on > __builtin_classify_type + array/function decay? It's a (previously) Looking at the first uses of the builtin back in 90s in va*.h, it certainly relied on array/f

[PATCH] c, v3: Add stdckdint.h header for C23

On Thu, Aug 10, 2023 at 10:31:12PM +, Joseph Myers wrote: > > The following patch (on top of the stdckdint.h patch and _BitInt patch > > series) adds a test for _BitInt diagnostics of ckd_{add,sub,mul} macros. > > I remain unconvinced that diagnosing use with types where it's clear what > the

Re: [PATCH] c, c++, v2: Accept __builtin_classify_type (typename)

On Fri, Aug 11, 2023 at 01:13:32AM +0200, Jakub Jelinek wrote: > Looking at the first uses of the builtin back in 90s in va*.h, it certainly > relied on array/function decay there (the macros would abort e.g. on > array_type_class, function_type_class and various other return values). > Looking at

[PATCH] c, v4: Add stdckdint.h header for C23

On Fri, Aug 11, 2023 at 01:25:38PM +, Joseph Myers wrote: > On Fri, 11 Aug 2023, Jakub Jelinek wrote: > > > All that is diagnosed is when result is bool or enum (any kind). Even for > > I'd suggest tests that other nonsense cases are diagnosed, such as > floating-point or pointer arguments

Re: [PATCH] Emit funcall external declarations only if actually used.

On Fri, Aug 18, 2023 at 03:53:51PM +0200, Jose E. Marchesi via Gcc-patches wrote: > --- a/gcc/final.cc > +++ b/gcc/final.cc > @@ -815,6 +815,8 @@ make_pass_compute_alignments (gcc::context *ctxt) > reorg.cc, since the branch splitting exposes new instructions with delay > slots. */ > >

Re: [PATCH] Emit funcall external declarations only if actually used.

On Fri, Aug 18, 2023 at 06:31:10PM +0200, Jose E. Marchesi wrote: > > This won't work if target can't use a direct call instruction. > > Consider > > __int128 a, b; void foo () { a = a / b; } > > on x86_64-linux. With just -O2, the above works fine, with > > -O2 -mcmodel=large it will not, the cal

Re: [Patch] omp-expand.cc: Fix wrong code with non-rectangular loop nest [PR111017]

On Fri, Aug 18, 2023 at 07:15:16PM +0200, Tobias Burnus wrote: > Comments, questions, concerns? > > If not, I intent to commit the attached patch to mainline on Monday > and after the usual grace time to GCC 13 and then to GCC 12. > > PR middle-end/111017 > gcc/ > * omp-expand.cc (exp

Re: Intel AVX10.1 Compiler Design and Support

On Mon, Aug 21, 2023 at 09:36:16AM +0200, Richard Biener via Gcc-patches wrote: > > On Sun, Aug 20, 2023 at 6:44 AM ZiNgA BuRgA via Gcc-patches > > wrote: > > > > > > Hi, > > > > > > With the proposed design of these switches, how would I restrict AVX10.1 > > > to particular AVX-512 subsets? > > W

Re: Intel AVX10.1 Compiler Design and Support

On Mon, Aug 21, 2023 at 04:28:20PM +0800, Hongtao Liu wrote: > We have an undocumented option mavx10-max-512bit. How it is called internally is one thing, but it is weird to use avx10 in an option name which would be meant for finding common subset of -mavx512xxx and -mavx10.1-256. Jakub

Patch ping Re: [PATCH 0/12] GCC _BitInt support [PR102989]

Hi! On Wed, Aug 09, 2023 at 08:14:14PM +0200, Jakub Jelinek via Gcc-patches wrote: > Jakub Jelinek (12): > expr: Small optimization [PR102989] > lto-streamer-in: Adjust assert [PR102989] > phiopt: Fix phiopt ICE on vops [PR102989] > Middle-end _BitInt support [PR1029

Re: [PATCH] libgomp, testsuite: Do not call nonstandard functions on darwin

On Mon, Aug 21, 2023 at 09:12:09PM +0200, Tobias Burnus wrote: > OK. — I'd prefer if you also changed + tested a fix for my (a) + (b) > remarks, but as those are unrelated, I understand if you don't and just > commit your Darwin patch. I don't like the #if !defined(__APPLE__) conditionals everywhe

Re: [PATCH] libgomp, testsuite: Do not call nonstandard functions on darwin

On Mon, Aug 21, 2023 at 09:50:37PM +0200, FX Coudert wrote: > > I don't like the #if !defined(__APPLE__) conditionals everywhere in the > > test, I think much cleaner would be to add an effective target to test > > for those functions > > I understand, I wanted to not just report the issue but pro

Re: [PATCH] libgomp, testsuite: Do not call nonstandard functions on darwin

On Mon, Aug 21, 2023 at 10:00:30PM +0200, FX Coudert wrote: > >> I understand, I wanted to not just report the issue but propose an option. > >> It seems a bit heavy to design an effective target just for one test, > >> though, no? > > > > It has the advantage of getting it right on all current

[PATCH] c++: Implement C++26 P2169R4 - Placeholder variables with no name [PR110349]

Hi! The following patch implements the C++26 P2169R4 paper. As written in the PR, the patch expects that: 1) https://eel.is/c++draft/expr.prim.lambda.capture#2 "Ignoring appearances in initializers of init-captures, an identifier or this shall not appear more than once in a lambda-capture."

[PATCH] c++: Fix up mangling of function/block scope static structured bindings [PR111069]

Hi! As can be seen on the testcase, we weren't correctly mangling static/thread_local structured bindings (C++20 feature) at function/block scope. The following patch fixes that by using what write_local_name does for those cases (note, structured binding mandling doesn't use the standard path be

[PATCH] doc: Remove obsolete sentence about _Float* not being supported in C++ [PR106652]

Hi! As mentioned in the PR, these types are supported in C++ since GCC 13, so we shouldn't confuse users. Ok for trunk? 2023-08-22 Jakub Jelinek PR c++/106652 * doc/extend.texi (_Float): Drop obsolete sentence that the types aren't supported in C++. --- gcc/doc/exten

Re: [PATCH] libgomp, testsuite: Do not call nonstandard functions on darwin

On Tue, Aug 22, 2023 at 10:16:37AM +0200, FX Coudert wrote: > Revised patch. I does the job on darwin, can you check that it still tests > the functions on Linux? Seems the attached patch doesn't match what was discussed in this thread. And for that DWARF patch, I'd like to see what different out

Re: Intel AVX10.1 Compiler Design and Support

On Tue, Aug 22, 2023 at 09:36:15AM +0200, Richard Biener via Gcc-patches wrote: > I think internally we should have conditional 512bit support work across > AVX512 and AVX10. > > I also think it makes sense to _internally_ have AVX10.1 (10.1!) just > enable the respective AVX512 features. AVX10.2

[PATCH] tree-ssa-math-opts: Fix up uaddc/usubc pattern matching [PR110271]

Hi! The following testcase ICEs, because I misremembered what the return value from match_arith_overflow is. It isn't true if __builtin_*_overflow was matched, but it is true only in the BIT_NOT_EXPR case if stmt was removed. So, if match_arith_overflow matches something, gsi_stmt (gsi) will not

[PATCH] builtins: Add support for clang compatible __builtin_{add,sub}c{,l,ll} [PR79173]

Hi! While the design of these builtins in clang is questionable, rather than being say unsigned __builtin_addc (unsigned, unsigned, bool, bool *) so that it is clear they add two [0, 0x] range numbers plus one [0, 1] range carry in and give [0, 0x] range return plus [0, 1] range ca

Re: [PATCH v1] RISC-V: Fix out of range memory access when lto mode init

On Mon, Jun 19, 2023 at 08:40:58AM +, Richard Biener wrote: > You also have to fix bp_pack_machine_mode/bp_unpack_machine_mode which > streams exactly values in [0, 1<<8 - 1]. > > CCing Jakub who invented this code. For stream-out, all it stores is a bool flag whether the mode is streamed out

Re: [PATCH] RISC-V: Fix out of range memory access of machine mode table

On Mon, Jun 19, 2023 at 05:05:48PM +0800, pan2...@intel.com wrote: > --- a/gcc/lto-streamer-in.cc > +++ b/gcc/lto-streamer-in.cc > @@ -1985,7 +1985,8 @@ lto_input_mode_table (struct lto_file_decl_data > *file_data) > internal_error ("cannot read LTO mode table from %s", > fi

Re: [libstdc++] Improve M_check_len

On Mon, Jun 19, 2023 at 01:05:36PM +0200, Jan Hubicka via Gcc-patches wrote: > - if (max_size() - size() < __n) > - __throw_length_error(__N(__s)); > + const size_type __max_size = max_size(); > + // On 64bit systems vectors can not reach overflow by growing > + // by small si

Re: [PATCH] RISC-V: Fix out of range memory access of machine mode table

On Tue, Jun 20, 2023 at 07:50:00AM +, Li, Pan2 wrote: > Hi Jakub, > > Thanks for reviewing but I am not quite sure if I fully understand how to fix > this issue. Could you please help to enlighten me more about this ? > > Currently for RISC-V, the memset has touched out of range memory alrea

Re: [libstdc++] Improve M_check_len

On Tue, Jun 20, 2023 at 09:50:25AM +0200, Jan Hubicka wrote: > > > > > > size_type > > > _M_check_len(size_type __n, const char* __s) const > > > { > > > const size_type __size = size(); > > > const size_type __max_size = max_size(); > > > > > > if (__is_sa

Re: [PATCH] RISC-V: Fix out of range memory access of machine mode table

On Tue, Jun 20, 2023 at 02:08:07PM +, Li, Pan2 via Gcc-patches wrote: > Thanks Jakub for the explanation, I have a try like below patch but I am not > quite sure it is expected, and where should I put the assertion. > > > If yes, it needs to > > be unsigned short, if not, we should add an ass

[PATCH] tree-ssa-math-opts: Small uaddc/usubc pattern matching improvement [PR79173]

Hi! In the following testcase we fail to pattern recognize the least significant .UADDC call. The reason is that arg3 in that case is _3 = .ADD_OVERFLOW (...); _2 = __imag__ _3; _1 = _2 != 0; arg3 = (unsigned long) _1; and while before the changes arg3 has a single use in some .ADD_OVERFL

Re: [PATCH] RISC-V: Fix out of range memory access of machine mode table

On Wed, Jun 21, 2023 at 06:59:08AM +, Li, Pan2 wrote: > inline machine_mode > bp_unpack_machine_mode (struct bitpack_d *bp) > { > - return (machine_mode) > -((class lto_input_block *) > - bp->stream)->mode_table[bp_unpack_enum (bp, machine_mode, 1 << 8)]; > + int last = 1 <

Re: [PATCH] Prevent TYPE_PRECISION on VECTOR_TYPEs

On Tue, Jun 27, 2023 at 11:45:33AM +0200, Richard Biener wrote: > The following makes sure that using TYPE_PRECISION on VECTOR_TYPE > ICEs when tree checking is enabled. This should avoid wrong-code > in cases like PR110182 and instead ICE. > > It also introduces a TYPE_PRECISION_RAW accessor and

Re: [PATCH] tree-optimization/110434 - avoid ={v} {CLOBBER} from NRV

On Wed, Jun 28, 2023 at 10:21:45AM +, Richard Biener via Gcc-patches wrote: > When NRV replaces a local variable with it also replaces > occurences in clobbers. This leads to being clobbered > before the return of it which is strictly invalid but harmless in > practice since there's no pass

Re: [PATCH] tree-optimization/110434 - avoid ={v} {CLOBBER} from NRV

On Wed, Jun 28, 2023 at 12:32:51PM +, Richard Biener wrote: > As said there's nothing run after NRV. There is expansion but in the case I strongly doubt we are trying to stack reuse it for other vars, so maybe it is ok. > > On the other side, could there be partial clobbers for the var -> ,

Re: [PATCH] i386: add -fno-stack-protector to two tests

On Thu, Jun 29, 2023 at 04:01:20PM -0400, Marek Polacek via Gcc-patches wrote: > These tests fail when the testsuite is executed with -fstack-protector-strong. > To avoid this, this patch adds -fno-stack-protector to dg-options. > > Tested on x86_64-pc-linux-gnu, ok for trunk? > > gcc/testsuite/C

Re: [PATCH] i386: add -fno-stack-protector to two tests

On Fri, Jun 30, 2023 at 04:11:44AM +0800, Xi Ruoyao via Gcc-patches wrote: > On Fri, 2023-06-30 at 04:08 +0800, Xi Ruoyao wrote: > > On Thu, 2023-06-29 at 16:01 -0400, Marek Polacek via Gcc-patches wrote: > > > These tests fail when the testsuite is executed with -fstack- > > > protector-strong. >

Re: Adjust LTO mode tables for "Machine_Mode: Extend machine_mode from 8 to 16 bits" (was: [PATCH] Machine_Mode: Extend machine_mode from 8 to 16 bits)

On Fri, Jun 30, 2023 at 08:45:38PM +0800, Kito Cheng wrote: > Hmmm, I think maybe what we need is to leverage C++ language features > to declare enum with underlying types like that: > > enum machine_mode : uint16_t What would be the advantage of doing that? I mean, on most hosts using unsigned r

[PATCH] tree-ssa-math-opts: Fix up ICE in match_uaddc_usubc [PR110508]

Hi! The match_uaddc_usubc matching doesn't require that the second .{ADD,SUB}_OVERFLOW has REALPART_EXPR of its lhs used, only that there is at most one. So, in the weird case where the REALPART_EXPR of it isn't present, we shouldn't ICE trying to replace that REALPART_EXPR with REALPART_EXPR of

Re: [PATCH] match.pd: Implement missed optimization (~X | Y) ^ X -> ~(X & Y) [PR109986]

On Thu, Jul 06, 2023 at 03:00:28PM +0200, Richard Biener via Gcc-patches wrote: > > + (if (types_match (type, @1)) > > + (bit_not (bit_and @1 (convert @0))) > > + (if (types_match (type, @0)) > > +(bit_not (bit_and (convert @1) @0)) > > +(convert (bit_not (bit_and @0 (convert @1)))

Re: [PATCH] libgcc: Fix -Wint-conversion warning in find_fde_tail

On Mon, Jul 10, 2023 at 08:54:54PM +0200, Florian Weimer via Gcc-patches wrote: > Fixes commit r14-1614-g49310a99330849 ("libgcc: Fix eh_frame fast path > in find_fde_tail"). > > libgcc/ > > PR libgcc/110179 > * unwind-dw2-fde-dip.c (find_fde_tail): Add cast to avoid > implicit

Re: [PATCH] x86: improve fast bfloat->float conversion

On Tue, Jul 11, 2023 at 09:50:23AM +0200, Jan Beulich via Gcc-patches wrote: > > Quote from what Jakub said in [1]. > > --- > > This is not correct. > > While using such code for _mm_cvtsbh_ss is fine if it is documented not to > > raise exceptions and turn a sNaN into a qNaN, it is not fine fo

Re: [PATCH] match.pd: Implement missed optimization (~X | Y) ^ X -> ~(X & Y) [PR109986]

On Thu, Jul 06, 2023 at 03:00:28PM +0200, Richard Biener via Gcc-patches wrote: > On Wed, Jul 5, 2023 at 3:42 PM Drew Ross via Gcc-patches > wrote: > > > > Adds a simplification for (~X | Y) ^ X to be folded into ~(X & Y). > > Tested successfully on x86_64 and x86 targets. > > > >

Patch ping

I'd like to ping a few pending patches: https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607534.html - PR107846 - P1 - c-family: Account for integral promotions of left shifts for -Wshift-overflow warning https://gcc.gnu.org/pipermail/gcc-patches/2023-January/610285.html - PR108464 -

Re: [PATCH] tree-optimization/108691 - indirect calls to setjmp

On Mon, Feb 13, 2023 at 12:00:56PM +0100, Richard Biener wrote: > DCE now chokes on indirect setjmp calls becoming direct because > that exposes them too late to be subject to abnormal edge creation. > The following patch honors gimple_call_ctrl_altering for those and > _not_ treat formerly indirec

Re: [Ping^3] gomp: Various fixes for SVE types [PR101018]

On Mon, Feb 13, 2023 at 10:45:05AM +, Richard Sandiford wrote: > Ping^3 [https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606741.html] > > > > Various parts of the omp code checked whether the size of a decl > was an INTEGER_CST in order to determine whether the decl was > variabl

Re: [PATCH] tree-optimization/108691 - indirect calls to setjmp

On Mon, Feb 13, 2023 at 12:41:48PM +, Richard Biener wrote: > > Could we e.g. prevent turning such indirect calls into direct calls? > > We do exactly have gimple_call_fntype and gimple_call_ctrl_altering_p > to not require special-casing indirect to direct call promotion here. Ah, so if we m

[PATCH] asan: Add --param=asan-kernel-mem-intrinsic-prefix= [PR108777]

Hi! While in the -fsanitize=address case libasan overloads memcpy, memset, memmove and many other builtins, such that they are always instrumented, Linux kernel for -fsanitize=kernel-address recently changed or is changing, such that memcpy, memset and memmove actually aren't instrumented because

[PATCH] c++: Add testcases from some Issaquah DRs

Hi! The following patch adds testcases for 5 DRs. In the DR2475, DR2530 and DR2691 my understanding is we already implement the desired behavior, in DR2478 partially (I've added 2 dg-bogus there, I think we inherit rather than overwrite DECL_DECLARED_CONSTINIT_P for explicit specialization somewh

Re: [PATCH] c++: Add testcases from some Issaquah DRs

On Tue, Feb 14, 2023 at 12:22:33PM +0100, Jakub Jelinek via Gcc-patches wrote: > 2023-02-14 Jakub Jelinek > > * g++.dg/DRs/dr2691.C: New test. Actually, this one isn't a DR, so maybe it should go into: * gcc/testsuite/c-c++-common/cpp/delimited-escape-seq-8.c: New

Re: [PATCH] Fix possible sanopt compile-time hog

On Tue, Feb 14, 2023 at 04:20:24PM +0100, Richard Biener wrote: > While working on bitmap operations I figured sanopt.cc uses > a sbitmap worklist, iterating using bitmap_first_set_bit on it. > That's quadratic since bitmap_first_set_bit for sbitmap is O(n). > > The fix is to use regular bitmaps f

Re: [PATCH (pushed)] docs: document new --param=asan-kernel-mem-intrinsic-prefix

On Wed, Feb 15, 2023 at 09:39:11AM +0100, Martin Liška wrote: > gcc/ChangeLog: > > * doc/invoke.texi: Document --param=asan-kernel-mem-intrinsic-prefix. Ok, thanks. Jakub

[committed] powerpc: Fix up expansion for WIDEN_MULT_PLUS_EXPR [PR108787]

Hi! WIDEN_MULT_PLUS_EXPR as documented has the factor operands with the same precision and the addend and result another one at least twice as wide. Similarly, {,u}maddMN4 is documented as 'maddMN4' Multiply operands 1 and 2, sign-extend them to mode N, add operand 3, and store the resul

Re: [PATCH] warn-access: wrong -Wdangling-pointer with labels [PR106080]

On Tue, Feb 14, 2023 at 10:48:15PM -0500, Marek Polacek via Gcc-patches wrote: > -Wdangling-pointer warns when the address of a label escapes. This > causes grief in OCaml () as > well as in the kernel: >

Re: [Patch][v2] OpenMP/Fortran: Fix loop-iter var privatization with !$OMP LOOP [PR108512]

On Fri, Feb 10, 2023 at 12:52:47PM +0100, Tobias Burnus wrote: > > I'm afraid this is needed but insufficient. > > I think > > case EXEC_OMP_MASKED_TASKLOOP: > > case EXEC_OMP_MASKED_TASKLOOP_SIMD: > > case EXEC_OMP_MASTER_TASKLOOP: > > case EXEC_

Re: [Patch] libgomp: Fix 'target enter data' with always pointer

On Mon, Feb 13, 2023 at 09:28:15PM +0100, Tobias Burnus wrote: > libgomp: Fix 'target enter data' with always pointer > > As GOMP_MAP_ALWAYS_POINTER operates on the previous map item, ensure that > with 'target enter data' both are passed together to gomp_map_vars_internal. > > libgomp/ChangeLog:

Re: [Patch] libgomp: Fix reverse-offload for GOMP_MAP_TO_PSET

On Thu, Feb 09, 2023 at 10:23:53AM +0100, Tobias Burnus wrote: > libgomp: Fix reverse-offload for GOMP_MAP_TO_PSET > > libgomp/ > * target.c (gomp_target_rev): Dereference ptr > to get device address. > * libgomp.fortran/reverse-offload-5.f90: Add test > for unallocated all

<    1   2   3   4   5   6   7   8   9   10   >