RE: [PATCH v2] Draft|Internal-fn: Introduce internal fn saturation US_PLUS

Hi Richard and Tamar, I have a try with DEF_INTERNAL_SIGNED_OPTAB_FN for SAT_ADD/SUB/MUL but meet some problem when match.pd. For unsigned SAT_ADD = (x + y) | - ((x + y) < x), the match.pd can be (bit_ior:c (plus:c@2 @0 @1) (negate (convert (lt @2 @0. For unsigned SAT_SUB = x >= y ? x - y :

[PATCH] c++: Don't set DECL_CONTEXT to nested template-template parameters [PR98881]

Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? -- >8 -- When streaming in a nested template-template parameter as in the attached testcase, we end up reaching the containing template-template parameter in 'tpl_parms_fini'. We should not set the DECL_CONTEXT to this (nested) temp

[PATCH] gcc, libcpp: Add warning switch for "#pragma once in main file" [PR89808]

This patch adds a warning switch for "#pragma once in main file". The warning option name is Wpragma-once-outside-header, which is the same as Clang. PR preprocessor/89808 gcc/c-family/ChangeLog: * c-opts.cc (c_common_handle_option): Handle OPT_Wpragma_once_outside_heade

Re: libbacktrace patch committed: Read symbol table of debuginfo file

On Thu, Feb 29, 2024 at 7:47 PM Ian Lance Taylor wrote: > > This patch to libbacktrace reads symbol tables from debuginfo files. > These become another symbol table to search. This is needed if people > use --strip-all rather than --strip-debug when adding a debuglink > section. This fixes > htt

RE: [PATCH v2] DSE: Bugfix ICE after allow vector type in get_stored_val

Yeah, talking about this with robin offline for this fix. > Yes, but what we set tieable is e.g. V4QI and V2SF. That comes from different code lines. Jeff would like to learn more about extract_low_bits, it will first convert to int_mode and then call the tieable_p. And I bet the V4QI and V2SF c

[PATCH] c++: DECL_DECOMPOSITION_P cleanup

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for 15? -- >8 -- DECL_DECOMPOSITION_P already checks VAR_P but we repeat the check in a lot of places. gcc/cp/ChangeLog: * decl.cc (duplicate_decls): Don't check VAR_P before DECL_DECOMPOSITION_P. * init.cc (build_aggr_ini

[PATCH] c++: direct-init of an array of class type [PR59465]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? I don't claim that this has to go to 14 though. -- >8 -- ...from another array in a mem-initializer should not be accepted. We already reject struct string {} a[1]; string x[1](a); but struct pair { string s[1]; pair()

[PATCH] c++: lambda capturing structured bindings [PR85889]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for 15? (Or even trunk?) -- >8 -- clarifies that it's OK to capture structured bindings. [expr.prim.lambda.capture]/4 says "The identifier in a simple-capture shall denote a local entity" and [basic.pre]/3: "An entity

RE: [PATCH v3] RISC-V: Introduce gcc option mrvv-vector-bits for RVV

Sure thing. Pan -Original Message- From: Vineet Gupta Sent: Saturday, March 2, 2024 3:00 AM To: Li, Pan2 ; Kito Cheng ; 钟居哲 Cc: gcc-patches ; Wang, Yanzhang ; rdapp.gcc ; Jeff Law Subject: Re: [PATCH v3] RISC-V: Introduce gcc option mrvv-vector-bits for RVV Hi Pan, On 2/28/24 17:

Re: [Patch] invoke.texi: Add note that -foffload= does not affect device detection

On 3/1/24 08:23, Tobias Burnus wrote: Not very often, but do I keep running into issues (fails, segfaults) related to testing programs compiled with a GCC without offload configured and then using the system libraries. - That's equivalent to having the system compiler (or any offload compiler) an

[PATCH 10/11] gcc/doc/extend.texi: Add documentation for __is_scoped_enum

gcc/ChangeLog: * doc/extend.texi (__is_scoped_enum): New documentation. Signed-off-by: Ken Matsui --- gcc/doc/extend.texi | 5 + 1 file changed, 5 insertions(+) diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi index d36707fcdf3..fb2614176e5 100644 --- a/gcc/doc/extend.texi ++

[PATCH 02/11] gcc/doc/extend.texi: Add documentation for __is_array

gcc/ChangeLog: * doc/extend.texi (__is_array): New documentation. Signed-off-by: Ken Matsui --- gcc/doc/extend.texi | 5 + 1 file changed, 5 insertions(+) diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi index b13f9d6f934..5aeb9bdd47a 100644 --- a/gcc/doc/extend.texi +++ b/gc

[PATCH 08/11] gcc/doc/extend.texi: Add documentation for __is_object

gcc/ChangeLog: * doc/extend.texi (__is_object): New documentation. Signed-off-by: Ken Matsui --- gcc/doc/extend.texi | 5 + 1 file changed, 5 insertions(+) diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi index 08276f734f2..05f864e3dd5 100644 --- a/gcc/doc/extend.texi +++ b/g

[PATCH 11/11] gcc/doc/extend.texi: Add documentation for __remove_pointer

gcc/ChangeLog: * doc/extend.texi (__remove_pointer): New documentation. Signed-off-by: Ken Matsui --- gcc/doc/extend.texi | 5 + 1 file changed, 5 insertions(+) diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi index fb2614176e5..1705ed93934 100644 --- a/gcc/doc/extend.texi ++

[PATCH 05/11] gcc/doc/extend.texi: Add documentation for __is_member_function_pointer

gcc/ChangeLog: * doc/extend.texi (__is_member_function_pointer): New documentation. Signed-off-by: Ken Matsui --- gcc/doc/extend.texi | 5 + 1 file changed, 5 insertions(+) diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi index 8ad88516c04..9361b425ba1 100644 --- a/gc

[PATCH 04/11] gcc/doc/extend.texi: Add documentation for __is_function

gcc/ChangeLog: * doc/extend.texi (__is_function): New documentation. Signed-off-by: Ken Matsui --- gcc/doc/extend.texi | 5 + 1 file changed, 5 insertions(+) diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi index 4c8c0631ca7..8ad88516c04 100644 --- a/gcc/doc/extend.texi +++ b

Re: [PATCH 5/5] RISC-V: Support vmsxx.vx for autovec comparison of vec and imm

On Fri, Mar 1, 2024 at 4:07 AM Robin Dapp wrote: > > Hi Han, > > in addition to what Juzhe mentioned (and that late-combine is going > to handle such cases) it should be noted that register pressure > should not be the only consideration here. Many uarchs have a higher > latency for register-file

[PATCH 01/11] gcc/doc/extend.texi: Sort built-in traits alphabetically

This patch sorts built-in traits alphabetically for better codebase consistency and easier future integration of changes. gcc/ChangeLog: * doc/extend.texi (Type Traits): Sort built-in traits alphabetically. Signed-off-by: Ken Matsui --- gcc/doc/extend.texi | 62

[PATCH 06/11] gcc/doc/extend.texi: Add documentation for __is_member_object_pointer

gcc/ChangeLog: * doc/extend.texi (__is_member_object_pointer): New documentation. Signed-off-by: Ken Matsui --- gcc/doc/extend.texi | 5 + 1 file changed, 5 insertions(+) diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi index 9361b425ba1..df2df98567a 100644 --- a/gcc/

[PATCH 03/11] gcc/doc/extend.texi: Add documentation for __is_bounded_array

gcc/ChangeLog: * doc/extend.texi (__is_bounded_array): New documentation. Signed-off-by: Ken Matsui --- gcc/doc/extend.texi | 5 + 1 file changed, 5 insertions(+) diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi index 5aeb9bdd47a..4c8c0631ca7 100644 --- a/gcc/doc/extend.texi

[PATCH 09/11] gcc/doc/extend.texi: Add documentation for __is_reference

gcc/ChangeLog: * doc/extend.texi (__is_reference): New documentation. Signed-off-by: Ken Matsui --- gcc/doc/extend.texi | 5 + 1 file changed, 5 insertions(+) diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi index 05f864e3dd5..d36707fcdf3 100644 --- a/gcc/doc/extend.texi +++

[PATCH 07/11] gcc/doc/extend.texi: Add documentation for __is_member_pointer

gcc/ChangeLog: * doc/extend.texi (__is_member_pointer): New documentation. Signed-off-by: Ken Matsui --- gcc/doc/extend.texi | 5 + 1 file changed, 5 insertions(+) diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi index df2df98567a..08276f734f2 100644 --- a/gcc/doc/extend.texi

Re: [committed] Set num_threads to 50 on 32-bit hppa in two libgomp loop tests

On 2024-03-01 3:44 a.m., Jakub Jelinek wrote: Isn't this just that you have 50 in there? No.  It's okay. The problem is we run out of memory caused by a "ulimit -s 81920" statement that I had in .bashrc.  The test pass with default stack allocation. clone(child_stack=0x3191040, flags=CLONE_V

[PATCH] middle-end: Fix dominator information with loop duplication PR114197

When adding the new_preheader to the cfg, only the new_preheader's dominator information is updated. If one of the new basic block's children was part of the original cfg and adding new_preheader to the cfg introduces another path to that child, the child's dominator information will not be updated

[14 regression] Fix insn types in risc-v port

So one of the broad goals we've had over the last few months has been to ensure that every insn has a scheduling type and that every insn is associated with an insn reservation in the scheduler. This avoids some amazingly bad behavior in the scheduler. I won't go through the gory details. I

Re: [PATCH v5] c++: implement [[gnu::non_owning]] [PR110358]

On 3/1/24 16:23, Patrick Palka wrote: Sorry for not asking this sooner, but does it matter whether we attach the attribute to the function type rather than the function declaration? I noticed e.g. nodiscard gets attached to the decl. And we document it as a function attribute despite attaching

Re: [PATCH v5] c++: implement [[gnu::non_owning]] [PR110358]

On Fri, 1 Mar 2024, Jason Merrill wrote: > On 3/1/24 14:24, Marek Polacek wrote: > > On Fri, Mar 01, 2024 at 01:19:40PM -0500, Jason Merrill wrote: > > > On 3/1/24 12:39, Marek Polacek wrote: > > > >@option{-Wdangling-reference} also warns about code like > > > >@smallexample > > > > @@ -3

[PATCH] gcc_update: Add missing generated files

Is this OK for trunk? -- >8 -- I'm seeing errors for --enable-maintainer-mode builds due to incorrectly regenerating these files. They should be touched by gcc_update so they aren't regenerated unnecessarily. contrib/ChangeLog: * gcc_update: Add more generated files in libcc1, lto-plugi

Re: [PATCH v5] c++: implement [[gnu::non_owning]] [PR110358]

On 3/1/24 14:24, Marek Polacek wrote: On Fri, Mar 01, 2024 at 01:19:40PM -0500, Jason Merrill wrote: On 3/1/24 12:39, Marek Polacek wrote: @option{-Wdangling-reference} also warns about code like @smallexample @@ -3932,6 +3935,10 @@ struct Span @{ as @code{std::span}-like; that is, the

Re: [PATCH] c++/modules: depending local enums [PR104919, PR106009]

On 3/1/24 14:34, Patrick Palka wrote: On Fri, 1 Mar 2024, Jason Merrill wrote: On 3/1/24 13:28, Patrick Palka wrote: On Fri, 1 Mar 2024, Jason Merrill wrote: On 3/1/24 12:08, Patrick Palka wrote: On Fri, 1 Mar 2024, Patrick Palka wrote: On Fri, 1 Mar 2024, Jason Merrill wrote: On 3/1/24

Re: [PATCH] c++/modules: depending local enums [PR104919, PR106009]

On Fri, 1 Mar 2024, Jason Merrill wrote: > On 3/1/24 13:28, Patrick Palka wrote: > > On Fri, 1 Mar 2024, Jason Merrill wrote: > > > > > On 3/1/24 12:08, Patrick Palka wrote: > > > > On Fri, 1 Mar 2024, Patrick Palka wrote: > > > > > > > > > On Fri, 1 Mar 2024, Jason Merrill wrote: > > > > > > >

[PATCH v5] c++: implement [[gnu::non_owning]] [PR110358]

On Fri, Mar 01, 2024 at 01:19:40PM -0500, Jason Merrill wrote: > On 3/1/24 12:39, Marek Polacek wrote: > > @option{-Wdangling-reference} also warns about code like > > @smallexample > > @@ -3932,6 +3935,10 @@ struct Span @{ > > as @code{std::span}-like; that is, the class is a non-union class

Re: [PATCH] c++/modules: complete_vars ICE with non-exported constexpr var

On 2/26/24 15:52, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- Here during stream-in of the non-exported constexpr var 'a' we call maybe_register_incomplete_var, which ends up taking the second branch and pushing {a, NULL_TREE} on

Re: [PATCH] c++/modules: relax diagnostic about GMF contents

On 2/15/24 16:51, Patrick Palka wrote: On Thu, 15 Feb 2024, Jason Merrill wrote: Relaxing to pedwarn is fine, but I think it should be on by default, not just with -pedantic. So it should get a new option. Ah, like so? I'm not sure about naming the option Wmodules-gmf-contents vs just Wgmf-

Re: [PATCH] c++/modules: depending local enums [PR104919, PR106009]

On 3/1/24 13:28, Patrick Palka wrote: On Fri, 1 Mar 2024, Jason Merrill wrote: On 3/1/24 12:08, Patrick Palka wrote: On Fri, 1 Mar 2024, Patrick Palka wrote: On Fri, 1 Mar 2024, Jason Merrill wrote: On 3/1/24 10:00, Patrick Palka wrote: On Fri, 1 Mar 2024, Jason Merrill wrote: On 2/29/2

Re: [PATCH] testsuite: ctf: make array in ctf-file-scope-1 fixed length

On 3/1/24 11:01, David Faust wrote: The array member of struct SFOO in the ctf-file-scope-1 caused the test to fail for the BPF target, since BPF does not support dynamic stack allocation. The array does not need to variable length for the sake of the test, so make it fixed length instead to allo

[PATCH] testsuite: ctf: make array in ctf-file-scope-1 fixed length

The array member of struct SFOO in the ctf-file-scope-1 caused the test to fail for the BPF target, since BPF does not support dynamic stack allocation. The array does not need to variable length for the sake of the test, so make it fixed length instead to allow the test to run successfully for the

Re: [PATCH v3] RISC-V: Introduce gcc option mrvv-vector-bits for RVV

Hi Pan, On 2/28/24 17:23, Li, Pan2 wrote: > > Personally I prefer to remove --param=riscv-autovec-preference=none > and only allow > > mrvv-vector-bits, to avoid tricky(maybe) sematic of none preference. > However, let’s > > wait for a while in case there are some comments from others. > We are v

Re: [PATCH] c++/modules: depending local enums [PR104919, PR106009]

On Fri, 1 Mar 2024, Jason Merrill wrote: > On 3/1/24 12:08, Patrick Palka wrote: > > On Fri, 1 Mar 2024, Patrick Palka wrote: > > > > > On Fri, 1 Mar 2024, Jason Merrill wrote: > > > > > > > On 3/1/24 10:00, Patrick Palka wrote: > > > > > On Fri, 1 Mar 2024, Jason Merrill wrote: > > > > > > > >

Re: [PATCH v4] c++: implement [[gnu::non_owning]] [PR110358]

On 3/1/24 12:39, Marek Polacek wrote: On Thu, Feb 29, 2024 at 07:30:02PM -0500, Jason Merrill wrote: On 2/29/24 19:12, Marek Polacek wrote: On Wed, Feb 28, 2024 at 06:03:54PM -0500, Jason Merrill wrote: Hmm, if we're also going to allow the attribute to be applied to a function, the name does

Re: [PATCH] c++/modules: depending local enums [PR104919, PR106009]

On 3/1/24 12:08, Patrick Palka wrote: On Fri, 1 Mar 2024, Patrick Palka wrote: On Fri, 1 Mar 2024, Jason Merrill wrote: On 3/1/24 10:00, Patrick Palka wrote: On Fri, 1 Mar 2024, Jason Merrill wrote: On 2/29/24 15:56, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu,

Re: [PATCH] c++/modules: depending local enums [PR104919, PR106009]

On 3/1/24 11:45, Patrick Palka wrote: On Fri, 1 Mar 2024, Jason Merrill wrote: This was nearly enough to make things work, except we now ran into issues with the local TYPE/CONST_DECL copies when streaming the constexpr version of a function body. It occurred to me that we don't need to make c

[PATCH v4] c++: implement [[gnu::non_owning]] [PR110358]

On Thu, Feb 29, 2024 at 07:30:02PM -0500, Jason Merrill wrote: > On 2/29/24 19:12, Marek Polacek wrote: > > On Wed, Feb 28, 2024 at 06:03:54PM -0500, Jason Merrill wrote: > > > > > Hmm, if we're also going to allow the attribute to be applied to a > > > function, > > > the name doesn't make so mu

Re: [PATCH] c++/modules: depending local enums [PR104919, PR106009]

On Fri, 1 Mar 2024, Patrick Palka wrote: > On Fri, 1 Mar 2024, Jason Merrill wrote: > > > On 3/1/24 10:00, Patrick Palka wrote: > > > On Fri, 1 Mar 2024, Jason Merrill wrote: > > > > > > > On 2/29/24 15:56, Patrick Palka wrote: > > > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does th

[patch,avr,applied] Adjust help messages.

This patch unifies help screen messages. Johann -- AVR: Overhaul help screen gcc/ * config/avr/avr.opt: Overhaul help screen.diff --git a/gcc/config/avr/avr.opt b/gcc/config/avr/avr.opt index ea35b7d5b4e..c3ca8379ee3 100644 --- a/gcc/config/avr/avr.opt +++ b/gcc/config/avr/avr.opt @@ -

Re: [PATCH] c++/modules: depending local enums [PR104919, PR106009]

On Fri, 1 Mar 2024, Jason Merrill wrote: > On 3/1/24 10:32, Jason Merrill wrote: > > On 3/1/24 10:00, Patrick Palka wrote: > > > On Fri, 1 Mar 2024, Jason Merrill wrote: > > > > > > > On 2/29/24 15:56, Patrick Palka wrote: > > > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this loo

Re: [PATCH] c++/modules: depending local enums [PR104919, PR106009]

On Fri, 1 Mar 2024, Jason Merrill wrote: > On 3/1/24 10:00, Patrick Palka wrote: > > On Fri, 1 Mar 2024, Jason Merrill wrote: > > > > > On 2/29/24 15:56, Patrick Palka wrote: > > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look > > > > OK for trunk? > > > > > > > > -- >8 --

Re: [Patch] OpenMP/C++: Fix (first)private clause with member variables [PR110347]

On Fri, Mar 01, 2024 at 05:19:29PM +0100, Tobias Burnus wrote: > Jakub Jelinek wrote: > > As discussed on IRC, I believe not disregarding the capture proxies in > > target regions if they shouldn't be shared is always wrong, but also the > > gimplify.cc suggestion was incorrect. > > > > The thing

Re: [Patch] OpenMP/C++: Fix (first)private clause with member variables [PR110347]

Jakub Jelinek wrote: As discussed on IRC, I believe not disregarding the capture proxies in target regions if they shouldn't be shared is always wrong, but also the gimplify.cc suggestion was incorrect. The thing is that at the place where the omp_disregard_value_expr call is done currently for

Re: [PATCH] c++/modules: depending local enums [PR104919, PR106009]

On 3/1/24 10:32, Jason Merrill wrote: On 3/1/24 10:00, Patrick Palka wrote: On Fri, 1 Mar 2024, Jason Merrill wrote: On 2/29/24 15:56, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- For local enums defined in a non-template func

[PATCH] s390: Deprecate some vector builtins

According to IBM Open XL C/C++ for z/OS version 1.1 builtins - vec_permi - vec_ctd - vec_ctsl - vec_ctul - vec_ld2f - vec_st2f are deprecated. Also deprecate helper builtins vec_ctd_s64 and vec_ctd_u64. Furthermore, the overloads of vec_insert which make use of a bool vector are deprecated, too

Re: [PATCH v4] aarch64,arm: Move branch-protection data to targets

On 11/01/2024 14:35, Szabolcs Nagy wrote: > The branch-protection types are target specific, not the same on arm > and aarch64. This currently affects pac-ret+b-key, but there will be > a new type on aarch64 that is not relevant for arm. > > After the move, change aarch_ identifiers to aarch64_ o

Re: [PATCH v6 5/5] arm: Add support for MVE Tail-Predicated Low Overhead Loops

On 27/02/2024 13:56, Andre Vieira wrote: > > This patch adds support for MVE Tail-Predicated Low Overhead Loops by using > the > doloop funcitonality added to support predicated vectorized hardware loops. > > gcc/ChangeLog: > > * config/arm/arm-protos.h (arm_target_bb_ok_for_lob): Change

Re: [PATCH v6 4/5] doloop: Add support for predicated vectorized loops

On 27/02/2024 13:56, Andre Vieira wrote: > > This patch adds support in the target agnostic doloop pass for the detection > of > predicated vectorized hardware loops. Arm is currently the only target that > will make use of this feature. > > gcc/ChangeLog: > > * df-core.cc (df_bb_regno_o

Re: [PATCH] c++, v2: Fix up decltype of non-dependent structured binding decl in template [PR92687]

On 3/1/24 02:55, Jakub Jelinek wrote: On Thu, Feb 29, 2024 at 12:50:47PM +0100, Jakub Jelinek wrote: finish_decltype_type uses DECL_HAS_VALUE_EXPR_P (expr) check for DECL_DECOMPOSITION_P (expr) to determine if it is array/struct/vector/complex etc. subobject proxy case vs. structured binding usi

Re: [PATCH v6 3/5] arm: Fix a wrong attribute use and remove unused unspecs and iterators

On 27/02/2024 13:56, Andre Vieira wrote: > > This patch fixes the erroneous use of a mode attribute without a mode iterator > in the pattern and removes unused unspecs and iterators. > > gcc/ChangeLog: > > * config/arm/iterators.md (supf): Remove VMLALDAVXQ_U, VMLALDAVXQ_P_U, > VMLAL

Re: [PATCH v6 2/5] arm: Annotate instructions with mve_safe_imp_xlane_pred

On 27/02/2024 13:56, Andre Vieira wrote: > > This patch annotates some MVE across lane instructions with a new attribute. > We use this attribute to let the compiler know that these instructions can be > safely implicitly predicated when tail predicating if their operands are > guaranteed to have

Re: [PATCH v6 1/5] arm: Add define_attr to to create a mapping between MVE predicated and unpredicated insns

On 27/02/2024 13:56, Andre Vieira wrote: > > This patch adds an attribute to the mve md patterns to be able to identify > predicable MVE instructions and what their predicated and unpredicated > variants > are. This attribute is used to encode the icode of the unpredicated variant > of > an ins

Re: [PATCH] c++/modules: depending local enums [PR104919, PR106009]

On 3/1/24 10:00, Patrick Palka wrote: On Fri, 1 Mar 2024, Jason Merrill wrote: On 2/29/24 15:56, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- For local enums defined in a non-template function or a function template instantiati

Re: [COMMITTED htdocs] robots.txt: Disallow various wiki actions

On Fri, 1 Mar 2024, Mark Wielaard wrote: > It is fine for robots to crawl the wiki pages, but they should perform > actions, generate huge diffs, search/highlight pages or generate > calendars. s/should/should not/ :-) I see your patch does exactly that - thank you! Gerald

[COMITTED] contrib: mklog: Use present tense in ChangeLog

Hi! installed as r14-9256 > diff --git a/contrib/mklog.py b/contrib/mklog.py > index d764fb41f99..7d8d554b15e 100755 > --- a/contrib/mklog.py > +++ b/contrib/mklog.py > @@ -277,7 +277,7 @@ def generate_changelog(data, no_functions=False, > fill_pr_titles=False, > # it used to be

Re: [PATCH] c++: auto(x) partial substitution [PR110025, PR114138]

On 3/1/24 10:17, Patrick Palka wrote: On Fri, 1 Mar 2024, Jason Merrill wrote: On 2/29/24 14:17, Patrick Palka wrote: On Wed, 28 Feb 2024, Jason Merrill wrote: I wonder about, rather than returning it directly, setting its level to 1 for the substitution? Done, that works nicely. Then I w

[Patch] invoke.texi: Add note that -foffload= does not affect device detection

Not very often, but do I keep running into issues (fails, segfaults) related to testing programs compiled with a GCC without offload configured and then using the system libraries. - That's equivalent to having the system compiler (or any offload compiler) and compiling with -foffload=disable. Th

[PATCH] s390: Streamline NNPA builtins with POP mnemonics

At the moment there are no extended mnemonics for vclfn(h,l) and vcrnf defined in the Principles of Operation. Thus, remove the suffix "s" from the builtins and expanders and introduce a further operand for the data type. gcc/ChangeLog: * config/s390/s390-builtin-types.def: Update to ref

Re: [PATCH] c++: auto(x) partial substitution [PR110025, PR114138]

On Fri, 1 Mar 2024, Jason Merrill wrote: > On 2/29/24 14:17, Patrick Palka wrote: > > On Wed, 28 Feb 2024, Jason Merrill wrote: > > > I wonder about, rather than returning it directly, setting its level to 1 > > > for > > > the substitution? > > > > Done, that works nicely. > > > > > Then I wond

[PATCH] libstdc++: Add missing std::tuple constructor [PR114147]

This fixes a regression on all active branches. Tested aarch64-linux. -- >8 -- I caused a regression with commit r10-908 by adding a constraint to the non-explicit allocator-extended default constructor, but seemingly forgot to add an explicit overload with the corresponding constraint. libst

[PATCH] libstdc++: Better diagnostics for std::format errors

Does the text of these new diagnostics look good? There are of course other ways for a type to be not-formattable (e.g. the formatter::format member doesn't return the right type or has some other kind of incorrect signature, or the formatter::parse member isn't constexpr) but we can't predict/det

Re: [PATCH] RISC-V: Add initial cost handling for segment loads/stores.

> +  /* Segment load/store permute cost.  */ > +  const int segment_permute_2; > +  const int segment_permute_4; > +  const int segment_permute_8; > > Why do we only have 2/4/8, I think we should have 2/3/4/5/6/7/8 No idea why I posted that (wrong) version, I used it for some testing locally. At

Re: [PATCH] c++/modules: depending local enums [PR104919, PR106009]

On Fri, 1 Mar 2024, Jason Merrill wrote: > On 2/29/24 15:56, Patrick Palka wrote: > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look > > OK for trunk? > > > > -- >8 -- > > > > For local enums defined in a non-template function or a function template > > instantiation it seems

Re: [PATCH] arm: Fixed C23 call compatibility with arm-none-eabi

On 19/02/2024 09:13, Torbjörn SVENSSON wrote: > Ok for trunk and releases/gcc-13? > Regtested on top of 945cb8490cb for arm-none-eabi, without any regression. > > Backporting to releases/gcc-13 will change -std=c23 to -std=c2x. Jakub has just pushed a different fix for this, so I don't think we n

Re: [PATCH] arm: fix c23 0-named-args caller-side stdarg

On 01/03/2024 04:38, Alexandre Oliva wrote: > Hello, Matthew, > > Thanks for the review. For closure, Jakub has just pushed a patch to the generic code, so I don't think we need this now. R. > > On Feb 26, 2024, Matthew Malcomson wrote: > >> I think you're right that the AAPCS32 requires al

Re: [PATCH 1/5] RISC-V: Remove float vector eqne pattern

> 2. When I write if (a == 2) and if (2 == a), the results are > same > > 3. The vec_duplicate operand is the 5th operand in both cmp and > eqne patterns. I think they are equal. A comparison with a constant is always canonicalized to have the constant second, that's why you won't see

[PATCH] libstdc++: Use [] for empty argument to automake macro

Does this look reasonable to push? There are lots of other uses of AM_ENABLE_MULTILIB(, ..) in the tree, but I'll leave others to "fix" those if needed. -- >8 -- This seems to be needed to build with --enable-maintainer-mode but I don't understand why it doesn't fail in the normal build. libstdc

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

Ping on this patch set. Thanks a lot! Qing > On Feb 16, 2024, at 14:47, Qing Zhao wrote: > > Hi, > > This is the 6th version of the patch. > > compare with the 5th version, the only difference is: > > 1. Add the 6th argument to .ACCESS_WITH_SIZE > to carry the TYPE of the flexible array.

Re: [PATCH] testsuite: Turn errors back into warnings in arm/acle/cde-mve-error-2.c

On 13/01/2024 20:46, Thiago Jung Bauermann wrote: > Since commit 2c3db94d9fd ("c: Turn int-conversion warnings into > permerrors") the test fails with errors such as: > > FAIL: gcc.target/arm/acle/cde-mve-error-2.c -O0 (test for errors, line > 32) > FAIL: gcc.target/arm/acle/cde-mve-error

Re: [PATCH] testsuite: Fix fallout of turning warnings into errors on 32-bit Arm

On 01/03/2024 14:23, Andre Vieira (lists) wrote: > Hi Thiago, > > Thanks for this, LGTM but I can't approve this, CC'ing Richard. > > Do have a nitpick, in the gcc/testsuite/ChangeLog: remove 'gcc/testsuite' > from bullet points 2-4. > Yes, this is OK with the change Andre mentioned (your push

Re: [PATCH] testsuite: Fix fallout of turning warnings into errors on 32-bit Arm

Hi Thiago, Thanks for this, LGTM but I can't approve this, CC'ing Richard. Do have a nitpick, in the gcc/testsuite/ChangeLog: remove 'gcc/testsuite' from bullet points 2-4. Kind regards, Andre On 13/01/2024 00:55, Thiago Jung Bauermann wrote: Since commits 2c3db94d9fd ("c: Turn int-conversi

Re: [PATCH] calls: Further fixes for TYPE_NO_NAMED_ARGS_STDARG_P handling [PR107453]

On 29/02/2024 15:55, Jakub Jelinek wrote: > On Thu, Feb 29, 2024 at 02:14:05PM +, Richard Earnshaw wrote: >>> I tried the above on arm, aarch64 and x86_64 and that seems fine, >>> including the new testcase you added. >>> >> >> I should mention though, that INIT_CUMULATIVE_ARGS on arm ignores >

Re: Re: [PATCH] RISC-V: Add initial cost handling for segment loads/stores.

+ /* Segment load/store permute cost. */ + const int segment_permute_2; + const int segment_permute_4; + const int segment_permute_8; Why do we only have 2/4/8, I think we should have 2/3/4/5/6/7/8 juzhe.zh...@rivai.ai From: Robin Dapp Date: 2024-02-28 05:27 To: juzhe.zh...@rivai.ai; gcc-

Re: [Patch] OpenACC: Update libgomp.texi + openacc{.f90,_lib.h} for 3.1 arg-name changes

Hi Thomas, Thomas Schwinge wrote: On 2024-02-27T20:11:30+0100, Tobias Burnus wrote: The attached patch updates the manual to match OpenACC 3.3 specification for the implemented routines. But not update references to OpenACC 3.3, too? As the change is not really visible (except when using F

Update GCC 14 OpenACC changes some more (was: [wwwdocs] gcc-14/changes.html + projects/gomp/: OpenMP + OpenACC update)

Hi! On 2024-02-27T20:16:52+0100, Tobias Burnus wrote: > Minor update for older and more recent changes. > > Comments? > gcc-14/changes.html + projects/gomp/: OpenMP + OpenACC update > Update OpenACC for one new feature (Fortran interface to exisiting > C/C++ routines). > --- a/htdocs/gcc-14/ch

Re: [PATCH] calls: Further fixes for TYPE_NO_NAMED_ARGS_STDARG_P handling [PR107453]

On Fri, Mar 01, 2024 at 01:53:08PM +, Richard Earnshaw (lists) wrote: > On 29/02/2024 17:56, Jakub Jelinek wrote: > > On Thu, Feb 29, 2024 at 05:51:03PM +, Richard Earnshaw (lists) wrote: > >> Oh, but wait! Perhaps that now falls into the initial 'if' clause and we > >> never reach the po

Re: [PATCH] c++/modules: Stream definitions for implicit instantiations [PR114170]

On 3/1/24 08:41, Nathaniel Shead wrote: On Fri, Mar 01, 2024 at 08:18:09AM -0500, Jason Merrill wrote: On 2/29/24 20:08, Nathaniel Shead wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? -- >8 -- An implicit instantiation has an initializer depending on whether DECL_INIT

Re: [PATCH] calls: Further fixes for TYPE_NO_NAMED_ARGS_STDARG_P handling [PR107453]

On 29/02/2024 17:56, Jakub Jelinek wrote: > On Thu, Feb 29, 2024 at 05:51:03PM +, Richard Earnshaw (lists) wrote: >> Oh, but wait! Perhaps that now falls into the initial 'if' clause and we >> never reach the point where you pick zero. So perhaps I'm worrying about >> nothing. > > If you a

Re: [PATCH] c++/modules: Stream definitions for implicit instantiations [PR114170]

On Fri, Mar 01, 2024 at 08:18:09AM -0500, Jason Merrill wrote: > On 2/29/24 20:08, Nathaniel Shead wrote: > > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? > > > > -- >8 -- > > > > An implicit instantiation has an initializer depending on whether > > DECL_INITIALIZED_P is set (

Re: [PATCH] dwarf2out: Don't move variable sized aggregates to comdat [PR114015]

On 2/29/24 07:10, Jakub Jelinek wrote: Hi! The following testcase ICEs, because we decide to move that struct { char a[n]; } DW_TAG_structure_type into .debug_types section / DW_UT_type DWARF5 unit, but refer from there to a DW_TAG_variable (created artificially for the array bounds). Even with

Re: [PATCH] c++: auto(x) partial substitution [PR110025, PR114138]

On 2/29/24 14:17, Patrick Palka wrote: On Wed, 28 Feb 2024, Jason Merrill wrote: I wonder about, rather than returning it directly, setting its level to 1 for the substitution? Done, that works nicely. Then I wonder if it would be feasible to give all autos level 0 and adjust it here? That'

[COMMITTED htdocs] robots.txt: Disallow various wiki actions

It is fine for robots to crawl the wiki pages, but they should perform actions, generate huge diffs, search/highlight pages or generate calendars. --- htdocs/robots.txt | 4 1 file changed, 4 insertions(+) diff --git a/htdocs/robots.txt b/htdocs/robots.txt index 057c5899..36be4d13 100644 ---

Re: [PATCH] c++/modules: depending local enums [PR104919, PR106009]

On 2/29/24 15:56, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? -- >8 -- For local enums defined in a non-template function or a function template instantiation it seems we neglect to make the function depend on the enum definition, which u

Re: [PATCH] c++/modules: Stream definitions for implicit instantiations [PR114170]

On 2/29/24 20:08, Nathaniel Shead wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? -- >8 -- An implicit instantiation has an initializer depending on whether DECL_INITIALIZED_P is set (like normal VAR_DECLs) which needs to be written to ensure that consumers of header mod

Re: [PATCH] c++: Ensure DECL_CONTEXT is set for temporary vars [PR114005]

On 2/29/24 16:28, Nathaniel Shead wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? Alternatively we could update 'DECL_CONTEXT' only for 'make_temporary_var_for_ref_to_temp' in call.cc, as a more targetted fix, but I felt that this way it'd also fix any other similar issue

Re: [PATCH v1 08/13] aarch64: Add Cygwin and MinGW environments for AArch64

> On Feb 29, 2024, at 21:59, Richard Earnshaw (lists) > wrote: > > On 29/02/2024 17:55, Andrew Pinski (QUIC) wrote: >>> -Original Message- >>> From: Maxim Kuvyrkov >>> Sent: Thursday, February 29, 2024 9:46 AM >>> To: Andrew Pinski (QUIC) >>> Cc: Evgeny Karpov ; Andrew Pinski >>> ; Ric

Re: [PATCH] middle-end/114070 - VEC_COND_EXPR folding

On Thu, 29 Feb 2024, Jakub Jelinek wrote: > On Thu, Feb 29, 2024 at 11:16:54AM +0100, Richard Biener wrote: > > That said, the quick experiment shows this isn't anything for stage4. > > The earlier the vector lowering is moved in the pass list, the higher > are the possibilities that match.pd or

Re: [PATCH 5/5] RISC-V: Support vmsxx.vx for autovec comparison of vec and imm

Hi Han, in addition to what Juzhe mentioned (and that late-combine is going to handle such cases) it should be noted that register pressure should not be the only consideration here. Many uarchs have a higher latency for register-file-crossing moves. At least without spilling the vv variant is p

[PATCH] tree-optimization/114164 - unsupported SIMD clone call, unsupported VEC_COND

The following avoids creating unsupported VEC_COND_EXPRs as part of SIMD clone call mask argument setup during vectorization which results in inefficient decomposing of the operation during vector lowering. Bootstrapped and tested on x86_64-unknown-linux-gnu. Will push on Monday when arm CI is ha

Re: [PATCH] tree-optimization/110221 - SLP and loop mask/len

On Fri, 1 Mar 2024, Andre Vieira (lists) wrote: > Hi, > > Bootstrapped and tested the gcc-13 backport of this on gcc-12 for > aarch64-unknown-linux-gnu and x86_64-pc-linux-gnu and no regressions. > > OK to push to gcc-12 branch? OK. Thanks, Richard. > Kind regards, > Andre Vieira > > On 10/1

Re: [PATCH] function: Fix another TYPE_NO_NAMED_ARGS_STDARG_P spot

On Fri, 1 Mar 2024, Jakub Jelinek wrote: > Hi! > > When looking at PR114175 (although that bug seems to be now a riscv backend > bug), I've noticed that for the TYPE_NO_NAMED_ARGS_STDARG_P functions which > return value through hidden reference, like > #include > > struct S { char a[64]; }; > i

Re: [PATCH] bitint: Handle VCE from large/huge _BitInt SSA_NAME from load [PR114156]

On Fri, 1 Mar 2024, Jakub Jelinek wrote: > Hi! > > When adding checks in which case not to merge a VIEW_CONVERT_EXPR from > large/huge _BitInt to vector/complex etc., I missed the case of loads. > Those are handled differently later. > Anyway, I think the load case is something we can handle just

Re: [PATCH v2] LoongArch: Add support for TLS descriptors

Thanks, I try to send a new version patch next week. 在 2024/2/29 下午2:08, Xi Ruoyao 写道: On Thu, 2024-02-29 at 09:42 +0800, mengqinggang wrote: Generate la.tls.desc macro instruction for TLS descriptors model. la.tls.desc expand to   pcalau12i $a0, %desc_pc_hi20(a)   ld.d  $a1, $a0, %desc

[PATCH] s390: Streamline vector builtins with LLVM

Similar as to s390_lcbb, s390_vll, s390_vstl, et al. make use of a signed vector type for vlbb. Furthermore, a const void pointer seems more common and an integer for the mask. For s390_vfi(s,d)b make use of integers for masks, too. Use unsigned integers for all s390_vlbr/vstbr variants. Make u

  1   2   >