Re: [PATCH v2] c++: parser - Support for target address spaces in C++

On Thu, Oct 13, 2022 at 02:52:59AM +0200, Paul Iannetta via Gcc-patches wrote: > + if (type != error_mark_node > + && !ADDR_SPACE_GENERIC_P (TYPE_ADDR_SPACE (type)) > + && current_function_decl) > + { > + error > +

[PATCH] Optimize identical permutation in my last r13-3212-gb88adba751da63

Add extra index check when merging VEC_CST, this handles the case when exactly op1 needs to be return. This fixes: FAIL: gcc.dg/tree-ssa/forwprop-19.c scan-tree-dump-not forwprop1 "VEC_PERM_EXPR" gcc/ChangeLog: PR target/107220 * match.pd: Check the index of VEC_CST

[PATCH] Optimize indentical permuation in my last r13-3212-gb88adba751da63

Add extra index check when merging VEC_CST, this handles the case when exactly op1 needs to be return. This fixes: FAIL: gcc.dg/tree-ssa/forwprop-19.c scan-tree-dump-not forwprop1 "VEC_PERM_EXPR" gcc/ChangeLog: PR target/107220 * match.pd: Check the index of VEC_CST

[committed] c: Do not use *_IS_IEC_60559 == 2

A late change for C2x (addressing comments from the second round of editorial review before the CD ballot, postdating the most recent public working draft) removed the value 2 for *_IS_IEC_60559 (a new macro added in C2x). Adjust the implementation accordingly not to use this value.

Re: [PATCH v2] c++: parser - Support for target address spaces in C++

On Tue, Oct 11, 2022 at 09:49:43PM -0400, Jason Merrill wrote: > > It surprises that this is the only place we complain about an object with an > address-space qualifier. Shouldn't we also complain about e.g. automatic > variables/parameters or non-static data members with address-space

Re: [wwwdocs] porting_to: Two-stage overload resolution for implicit move removed

On Wed, Oct 12, 2022 at 11:38:01PM +0100, Jonathan Wakely wrote: > On Wed, 12 Oct 2022 at 23:24, Marek Polacek wrote: > > > > On Wed, Oct 12, 2022 at 09:50:36PM +0100, Jonathan Wakely wrote: > > > On Wed, 12 Oct 2022 at 20:39, Marek Polacek wrote: > > > > > > > > As I promised in > > > >

Re: [wwwdocs] porting_to: Two-stage overload resolution for implicit move removed

On Wed, 12 Oct 2022 at 23:24, Marek Polacek wrote: > > On Wed, Oct 12, 2022 at 09:50:36PM +0100, Jonathan Wakely wrote: > > On Wed, 12 Oct 2022 at 20:39, Marek Polacek wrote: > > > > > > As I promised in > > > , > > > I'd like

Ping^2: [PATCH] libcpp: Improve location for macro names [PR66290]

Hello- https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599397.html Since Jeff was kind enough to ack one of my other preprocessor patches today, I have become emboldened to ping this one again too :). Would anyone have some time to take a look at it please? Thanks! -Lewis On Thu, Sep 15,

Re: [wwwdocs] porting_to: Two-stage overload resolution for implicit move removed

On Wed, Oct 12, 2022 at 09:50:36PM +0100, Jonathan Wakely wrote: > On Wed, 12 Oct 2022 at 20:39, Marek Polacek wrote: > > > > As I promised in > > , > > I'd like to update our GCC 13 porting_to.html with the following note. > > >

Re: [PATCH] libstdc++: async: tolerate slightly shorter sleep

On Oct 12, 2022, Jonathan Wakely wrote: > On Wed, 12 Oct 2022 at 12:41, Jonathan Wakely wrote: >> >> On Thu, 23 Jun 2022 at 12:38, Alexandre Oliva via Libstdc++ >> wrote: >> > >> > On Jun 22, 2022, Alexandre Oliva wrote: >> > >> > > Regstrapped on x86_64-linux-gnu, also tested with a cross to

Re: [wwwdocs] porting_to: Two-stage overload resolution for implicit move removed

On Wed, 12 Oct 2022 at 20:39, Marek Polacek wrote: > > As I promised in > , > I'd like to update our GCC 13 porting_to.html with the following note. > > Does this look OK to commit? Thanks, > > diff --git

[PATCH] PR 107189 Remove useless _Alloc_node

    libstdc++: Remove _Alloc_node instance in _Rb_tree [PR107189]     libstdc++-v3/ChangeLog:     PR libstdc++/107189     * include/bits/stl_tree.h (_Rb_tree<>::_M_insert_range_equal): Remove     unused _Alloc_node instance. Ok to commit ? François diff --git

[PATCH] libstdc++: respect with-{headers, newlib} for default hosted value

This saves us a build flag when building for freestanding targets. libstdc++-v3/ChangeLog: * acinclude.m4: Default hosted to off if building without headers and without newlib. --- Tested for x86_64-elf. libstdc++-v3/acinclude.m4 | 5 - 1 file changed, 4 insertions(+), 1

[PATCH] Fortran: simplify array constructors with typespec [PR93483, PR107216, PR107219]

Dear Fortranners, this one was really bugging me for quite some time. We failed to properly handle (= simplify) expressions using array constructors with typespec, and with parentheses and unary '+' and '-' sprinkled here and there. When there was no typespec, there was no related problem. The

[wwwdocs] porting_to: Two-stage overload resolution for implicit move removed

As I promised in , I'd like to update our GCC 13 porting_to.html with the following note. Does this look OK to commit? Thanks, diff --git a/htdocs/gcc-13/porting_to.html b/htdocs/gcc-13/porting_to.html index 84a00f21..243ed29d

[PATCH] xtensa: Add workaround for pSRAM cache issue in ESP32

From a2b425031f5b06dd51cd3ca34fe4f3620b93a944 Mon Sep 17 00:00:00 2001 From: Jeroen Domburg Date: Sat, 12 Aug 2017 23:10:12 +0800 Subject: [PATCH] xtensa: Add workaround for pSRAM cache issue in ESP32 Xtensa does a load/store inversion when a load and a store to the same address is found in the

[COMMITTED] Add range-op entry for floating point NEGATE_EXPR.

Handling negate is pretty easy, as all you have to do is flip the sign bit, even for NANs. gcc/ChangeLog: * range-op-float.cc (class foperator_negate): New. (floating_op_table::floating_op_table): Add NEGATE_EXPR (range_op_float_tests): Add negate tests. ---

Re: [PATCH v2] c++: ICE with VEC_INIT_EXPR and defarg [PR106925]

On Wed, Oct 12, 2022 at 01:12:57PM -0400, Marek Polacek wrote: > On Wed, Oct 12, 2022 at 12:47:21PM -0400, Jason Merrill wrote: > > On 10/12/22 12:27, Marek Polacek wrote: > > > On Tue, Oct 11, 2022 at 04:28:11PM -0400, Jason Merrill wrote: > > > > On 10/11/22 16:00, Marek Polacek wrote: > > > > >

Re: [PATCH] c++: Implement excess precision support for C++ [PR107097, PR323]

On Tue, Oct 11, 2022 at 03:33:23PM +0200, Jakub Jelinek via Gcc-patches wrote: > Hi! > > The following patch implements excess precision support for C++. > Like for C, it uses EXCESS_PRECISION_EXPR tree to say that its operand > is evaluated in excess precision and what the semantic type of the >

Re: [PATCH] mips: Add appropriate linker flags when compiling with -static-pie

On 9/25/22 09:49, linted via Gcc-patches wrote: Hello, I'm just checking to see if anyone has had a chance to look at this. Thank you On Wed, Sep 14, 2022 at 2:09 PM linted wrote: Hello, This patch fixes missing flags when compiling with -static-pie on mips. I made these modifications

Re: [PATCH] c++: Implement excess precision support for C++ [PR107097, PR323]

On 10/11/22 09:33, Jakub Jelinek wrote: Hi! The following patch implements excess precision support for C++. Great! Like for C, it uses EXCESS_PRECISION_EXPR tree to say that its operand is evaluated in excess precision and what the semantic type of the expression is. In most places I've

Re: [PATCH] improved const shifts for AVR targets

On 10/4/22 11:06, Alexander Binzberger via Gcc-patches wrote: Hi, recently I used some arduino uno for a project and realized some areas which do not output optimal asm code. Especially around shifts and function calls. With this as motivation and hacktoberfest I started patching things. Since

vect: Don't pattern match BITFIELD_REF's of non-integrals [PR107226]

Hi, The original patch supported matching the vect_recog_bitfield_ref_pattern for BITFIELD_REF's where the first operand didn't have a INTEGRAL_TYPE_P type. That means it would also match vectors, leading to regressions in targets that supported vectorization of those. Bootstrappend and

ifcvt: Fix bitpos calculation in bitfield lowering [PR107229]

Hi, The bitposition calculation for the bitfield lowering in loop if conversion was not taking DECL_FIELD_OFFSET into account, which meant that it would result in wrong bitpositions for bitfields that did not end up having representations starting at the beginning of the struct. Bootstrappend

Re: [Patch] libgomp/gcn: Prepare for reverse-offload callback handling

On 12.10.22 19:09, Andrew Stubbs wrote: On 12/10/2022 15:29, Tobias Burnus wrote: Right, sorry, the buffer is circular, but the counter is linear. It simplified reservation that way, but it does mean that there's a limit to the number of times the buffer can cycle before the counter saturates.

Re: [PATCH v2 00/10] [RISC-V] Atomics improvements [PR100265/PR100266]

> > > +Andrea, in case he has time to look at the memory model / ABI > > > issues. > +Jeff, who was offering to help when the threads got crossed. I'd punted on > a lot of this in the hope Andrea could help out, as I'm not really a memory > model guy and this is pretty far down the

Re: [PATCH v2] c++: ICE with VEC_INIT_EXPR and defarg [PR106925]

On Wed, Oct 12, 2022 at 12:47:21PM -0400, Jason Merrill wrote: > On 10/12/22 12:27, Marek Polacek wrote: > > On Tue, Oct 11, 2022 at 04:28:11PM -0400, Jason Merrill wrote: > > > On 10/11/22 16:00, Marek Polacek wrote: > > > > Since r12-8066, in cxx_eval_vec_init we perform expand_vec_init_expr > >

Re: [Patch] libgomp/gcn: Prepare for reverse-offload callback handling

On 12/10/2022 15:29, Tobias Burnus wrote: On 29.09.22 18:24, Andrew Stubbs wrote: On 27/09/2022 14:16, Tobias Burnus wrote: Andrew did suggest a while back to piggyback on the console_output handling, avoiding another atomic access. - If this is still wanted, I like to have some guidance

Re: [PATCH] preprocessor: Fix tracking of system header state [PR60014, PR60723]

On 10/8/22 15:18, Lewis Hyatt via Gcc-patches wrote: The token_streamer class (which implements gcc mode -E and -save-temps/-no-integrated-cpp) needs to keep track whether the last tokens output were in a system header, so that it can generate line marker annotations as necessary for a

Re: [PATCH] testsuite: Only run -fcf-protection test on i?86/x86_64 [PR107213]

On 10/11/22 10:57, Marek Polacek via Gcc-patches wrote: This test fails on non-i?86/x86_64 targets because on those targets we get error: '-fcf-protection=full' is not supported for this target so this patch limits where the test is run. Tested on x86_64-pc-linux-gnu, ok for trunk?

[committed] libgomp: Fix up OpenMP 5.2 feature bullet

Hi! The previous bullet correctly mentions 5.2 added for Fortran allocators directive which is a replacement of allocate directive associated with ALLOCATE statement to differentiate it at parse time from allocate directive as declarative one not associated with ALLOCATE statement, but the

[committed] libgomp: Add omp_in_explicit_task support

Hi! This is pretty straightforward, if gomp_thread ()->task is NULL, it can't be explicit task, otherwise if gomp_thread ()->task->kind == GOMP_TASK_IMPLICIT, it is an implicit task, otherwise explicit task. Regtested on x86_64-linux and i686-linux, committed to trunk. 2022-10-12 Jakub Jelinek

[committed] libgomp: Fix up creation of artificial teams

Hi! When not in explicit parallel/target/teams construct, we in some cases create an artificial parallel with a single thread (either to handle target nowait or for task reduction purposes). In those cases, it handled again artificially created implicit task (created by gomp_new_icv for cases

Re: [PATCH v2] c++: ICE with VEC_INIT_EXPR and defarg [PR106925]

On 10/12/22 12:27, Marek Polacek wrote: On Tue, Oct 11, 2022 at 04:28:11PM -0400, Jason Merrill wrote: On 10/11/22 16:00, Marek Polacek wrote: Since r12-8066, in cxx_eval_vec_init we perform expand_vec_init_expr while processing the default argument in this test. Hmm, why are we calling

Re: [PATCH] libgcc: Quote variable in Makefile.in

On 10/12/22 05:52, Jonathan Wakely via Gcc-patches wrote: This isn't very important as the error is harmless, but it's easy to fix and so is one less thing that might confuse people when looking at build logs. OK for trunk? -- >8 -- If the xgcc executable has not been built (or has been

[PATCH v2] c++: ICE with VEC_INIT_EXPR and defarg [PR106925]

On Tue, Oct 11, 2022 at 04:28:11PM -0400, Jason Merrill wrote: > On 10/11/22 16:00, Marek Polacek wrote: > > Since r12-8066, in cxx_eval_vec_init we perform expand_vec_init_expr > > while processing the default argument in this test. > > Hmm, why are we calling cxx_eval_vec_init during parsing of

Re: [PATCH] middle-end IFN_ASSUME support [PR106654]

On 10/12/22 10:39, Jakub Jelinek wrote: On Wed, Oct 12, 2022 at 10:31:00AM -0400, Andrew MacLeod wrote: I presume you are looking to get this working for this release, making the priority high? :-) Yes. So that we can claim we actually support C++23 Portable Assumptions and OpenMP assume

Re: [PATCH][AArch64] Improve bit tests [PR105773]

Wilco Dijkstra writes: > Hi Richard, > >> Realise this is awkward, but: CC_NZmode is for operations that set only >> the N and Z flags to useful values. If we want to take advantage of V >> being zero then I think we need a different mode. >> >> We can't go all the way to CCmode because the

Re: [PATCH] middle-end, v2: IFN_ASSUME support [PR106654]

On 10/11/22 09:36, Jakub Jelinek wrote: On Mon, Oct 10, 2022 at 11:19:24PM +0200, Jakub Jelinek via Gcc-patches wrote: On Mon, Oct 10, 2022 at 05:09:29PM -0400, Jason Merrill wrote: On 10/10/22 04:54, Jakub Jelinek via Gcc-patches wrote: My earlier patches gimplify the simplest

[pushed] c++: defer all consteval in default args [DR2631]

Tested x86_64-pc-linux-gnu, applying to trunk. -- >8 -- The proposed resolution of CWG2631 extends our current handling of source_location::current to all consteval functions: default arguments are not evaluated until they're used in a call, the same should apply to evaluation of immediate

Re: [PATCH][AArch64] Improve immediate expansion [PR106583]

Hi Richard, >>> Sounds good, but could you put it before the mode version, >>> to avoid the forward declaration? >> >> I can swap them around but the forward declaration is still required as >> aarch64_check_bitmask is 5000 lines before aarch64_bitmask_imm. > > OK, how about moving them both

Re: [PATCH] middle-end IFN_ASSUME support [PR106654]

On Wed, Oct 12, 2022 at 10:31:00AM -0400, Andrew MacLeod wrote: > I presume you are looking to get this working for this release, making the > priority high? :-) Yes. So that we can claim we actually support C++23 Portable Assumptions and OpenMP assume directive's hold clauses for something

Re: [PATCH][AArch64] Improve bit tests [PR105773]

Hi Richard, > Realise this is awkward, but: CC_NZmode is for operations that set only > the N and Z flags to useful values.  If we want to take advantage of V > being zero then I think we need a different mode. > > We can't go all the way to CCmode because the carry flag has the opposite > value

Re: [PATCH] middle-end IFN_ASSUME support [PR106654]

On 10/12/22 06:15, Jakub Jelinek wrote: the ranges we calculated above for the function. Or some special pass that reads assumes, does the processing you mention above and applies it?  Is that what you are thinking? The options would be to evaluate it each time ranger processes .ASSUME, or

Re: [Patch] libgomp/gcn: Prepare for reverse-offload callback handling

On 29.09.22 18:24, Andrew Stubbs wrote: On 27/09/2022 14:16, Tobias Burnus wrote: Andrew did suggest a while back to piggyback on the console_output handling, avoiding another atomic access. - If this is still wanted, I like to have some guidance regarding how to actually implement it. [...]

[PATCH] LoongArch: implement count_{leading,trailing}_zeros

LoongArch always support clz and ctz instructions, so we can always use __builtin_{clz,ctz} for count_{leading,trailing}_zeros. This improves the code of libgcc, and also benefits Glibc once we merge longlong.h there. Bootstrapped and regtested on loongarch64-linux-gnu. include/ChangeLog:

[Patch] libgomp: Add offload_device_gcn check, add requires-4a.c test

This came up because the USM implementation with -foffload-memory={unified,pinned} as posted at https://gcc.gnu.org/pipermail/gcc-patches/2022-July/597976.html does not handle USM with static variables. This shows up for the OG12 alias devel/omp/gcc-12 branch as FAIL for requires-4.c. The

Re: [PATCH] Optimize nested permutation to single VEC_PERM_EXPR [PR54346]

On Mon, 2022-09-26 at 14:56 +0800, Liwei Xu via Gcc-patches wrote: >     This patch implemented the optimization in PR 54346, which Merges > > c = VEC_PERM_EXPR ; >     d = VEC_PERM_EXPR ; >     to >     d = VEC_PERM_EXPR ; > > Bootstrapped and regtested

Re: [PATCH] 0/19 modula-2 front end patches overview

Rainer Orth writes: > Hi Gaius, > >> Testing >> === > [...] >> The devel/modula-2 branch has been bootstrapped on: >> > [...] >>sparc64 solaris >>sparc32 solaris > > which versions exactly did you run those bootstraps on? I'm asking > because for Solaris 11.4/SPARCV9

Re: [PATCH] RISC-V: Refine register_builtin_types function.

Committed with a few minor ChangeLog fixes. On Tue, Oct 11, 2022 at 2:15 PM wrote: > > From: Ju-Zhe Zhong > > gcc/ChangeLog: > > * config/riscv/riscv-vector-builtins.cc (GTY): Redefine vector types. > (build_const_pointer): New function. > (register_builtin_type): Ditto.

Re: [PATCH] RISC-V: Remove TUPLE size macro define.

Committed, thanks! On Tue, Oct 11, 2022 at 2:23 PM wrote: > > From: Ju-Zhe Zhong > > gcc/ChangeLog: > > * config/riscv/riscv-vector-builtins.h: Remove redundant macro. > > --- > gcc/config/riscv/riscv-vector-builtins.h | 3 --- > 1 file changed, 3 deletions(-) > > diff --git

Re: [PATCH] RISC-V: Clang-format add_vector_attribute function.

Committed, thanks! On Tue, Oct 11, 2022 at 2:22 PM wrote: > > From: Ju-Zhe Zhong > > gcc/ChangeLog: > > * config/riscv/riscv-vector-builtins.cc (add_vector_type_attribute): > Clang-format function. > > --- > gcc/config/riscv/riscv-vector-builtins.cc | 4 ++-- > 1 file changed, 2

Re: [PATCH] RISC-V: Clang-format vector_type_index.

Committed but combined with another one clang-format fixing :) On Tue, Oct 11, 2022 at 2:36 PM wrote: > > From: Ju-Zhe Zhong > > gcc/ChangeLog: > > * config/riscv/riscv-vector-builtins.h (DEF_RVV_TYPE): Clang-format > it. > > --- > gcc/config/riscv/riscv-vector-builtins.h | 3 +-- > 1

Re: [PATCH] RISC-V: Move function place to make it looks better.

Moving class declaration to theriscv-vector-builtins.cc file is not bad idea since the only user is riscv-vector-builtins.cc, but I don't think moving other code for consistent with ARM's code is reasonable, anyway committed with only class declaration movement, NOTE: I've off-list conversion

Re: [PATCH] RISC-V: Add new line at end of file.

Most changes has included in this commit: https://github.com/gcc-mirror/gcc/commit/684d238b8cd7e8222d9e66457815f2a63178730b On Wed, Oct 12, 2022 at 9:43 AM wrote: > > From: Ju-Zhe Zhong > > gcc/ChangeLog: > > * config/riscv/riscv-c.cc: Add new line. > *

Re: [PATCH] 0/19 modula-2 front end patches overview

Hi Gaius, > Testing > === [...] > The devel/modula-2 branch has been bootstrapped on: > [...] >sparc64 solaris >sparc32 solaris which versions exactly did you run those bootstraps on? I'm asking because for Solaris 11.4/SPARCV9 (sparcv9-sun-solaris2.11) was fine, while Solaris

[PATCH] libgcc: Quote variable in Makefile.in

This isn't very important as the error is harmless, but it's easy to fix and so is one less thing that might confuse people when looking at build logs. OK for trunk? -- >8 -- If the xgcc executable has not been built (or has been removed by 'make clean') then the command to print the multilib

Re: [PATCH] machmode, v2: Introduce GET_MODE_NEXT_MODE with previous GET_MODE_WIDER_MODE meaning, add new GET_MODE_WIDER_MODE

Jakub Jelinek writes: > On Wed, Oct 12, 2022 at 11:15:40AM +0100, Richard Sandiford wrote: >> Looks good to me, just some minor comments below. > > Here is an updated patch. > >> How robust is the mechanism that guarantees HF comes before BF, >> and so is the mode that appears in the (new) wider

Re: [PATCH] libstdc++: async: tolerate slightly shorter sleep

On Wed, 12 Oct 2022 at 12:41, Jonathan Wakely wrote: > > On Thu, 23 Jun 2022 at 12:38, Alexandre Oliva via Libstdc++ > wrote: > > > > On Jun 22, 2022, Alexandre Oliva wrote: > > > > > Regstrapped on x86_64-linux-gnu, also tested with a cross to > > > aarch64-rtems6. Ok to install? > > > > The

Re: [PATCH] libstdc++: async: tolerate slightly shorter sleep

On Thu, 23 Jun 2022 at 12:38, Alexandre Oliva via Libstdc++ wrote: > > On Jun 22, 2022, Alexandre Oliva wrote: > > > Regstrapped on x86_64-linux-gnu, also tested with a cross to > > aarch64-rtems6. Ok to install? > > The early wakeups are fixed for rtems6.1, so the same question raised at >

Re: [PATCH] libstdc++: Fixing Error: invalid type argument of unary '*' (have 'int')

On 04/08/22 12:54 -0400, Seija Kijin wrote: Had an error compiling tiny-cuda-nn using gcc 12.1. With this minor patch, I recompiled and the build succeeded. This looks like a bug in the cuda compiler then. The libstdc++ code is correct. N.B. libstdc++ patches need to be CC'd to the libstdc++

Re: [PATCH] Complete __gnu_test::basic_string<>::compare support

On Wed, 10 Aug 2022 at 19:31, François Dumont via Libstdc++ wrote: > > Here is another patch to complete __gnu_debug::basic_string<> Standard > conformity. This one is adding the missing compare overloads. > > I also would like to propose to change how __gnu_debug::basic_string<> > is tested. I

[PATCH] machmode, v2: Introduce GET_MODE_NEXT_MODE with previous GET_MODE_WIDER_MODE meaning, add new GET_MODE_WIDER_MODE

On Wed, Oct 12, 2022 at 11:15:40AM +0100, Richard Sandiford wrote: > Looks good to me, just some minor comments below. Here is an updated patch. > How robust is the mechanism that guarantees HF comes before BF, > and so is the mode that appears in the (new) wider list? genmodes.cc seems to have

Re: [PATCH] Fortran: check types of operands of arithmetic binary operations [PR107217]

Le 11/10/2022 à 22:23, Harald Anlauf via Fortran a écrit : Dear all, we need to check that the operands of arithmetic binary operations are consistent and of numeric type. The PR reported an issue for multiplication ("*"), but we better extend this to the other binary operations. I chose the

Re: [PATCH] machmode: Introduce GET_MODE_NEXT_MODE with previous GET_MODE_WIDER_MODE meaning, add new GET_MODE_WIDER_MODE

On Wed, Oct 12, 2022 at 12:37:39PM +0200, Eric Botcazou wrote: > > Though I admit I didn't go carefully through all 24 GET_MODE_WIDER_MODE > > uses, 54 FOR_EACH_MODE_IN_CLASS uses, 3 FOR_EACH_MODE uses, 24 > > FOR_EACH_MODE_FROM, 6 FOR_EACH_MODE_UNTIL and 15 FOR_EACH_WIDER_MODE uses. > > It is

Re: [PATCH] machmode: Introduce GET_MODE_NEXT_MODE with previous GET_MODE_WIDER_MODE meaning, add new GET_MODE_WIDER_MODE

> Though I admit I didn't go carefully through all 24 GET_MODE_WIDER_MODE > uses, 54 FOR_EACH_MODE_IN_CLASS uses, 3 FOR_EACH_MODE uses, 24 > FOR_EACH_MODE_FROM, 6 FOR_EACH_MODE_UNTIL and 15 FOR_EACH_WIDER_MODE uses. > It is more important to go through the GET_MODE_WIDER_MODE and >

[PATCH] Add condition coverage profiling

This patch adds support in gcc+gcov for modified condition/decision coverage (MC/DC) with the -fprofile-conditions flag. MC/DC is a type of test/code coverage and it is particularly important in the avation and automotive industries for safety-critical applications. MC/DC it is required for or

Re: [PATCH] machmode: Introduce GET_MODE_NEXT_MODE with previous GET_MODE_WIDER_MODE meaning, add new GET_MODE_WIDER_MODE

Jakub Jelinek writes: > On Wed, Oct 05, 2022 at 04:02:25PM -0400, Jason Merrill wrote: >> > > > @@ -5716,7 +5716,13 @@ emit_store_flag_1 (rtx target, enum rtx_ >> > > >{ >> > > > machine_mode optab_mode = mclass == MODE_CC ? CCmode : >> > > > compare_mode; >> > > > icode

Re: [PATCH] middle-end IFN_ASSUME support [PR106654]

On Tue, Oct 11, 2022 at 02:05:52PM -0400, Andrew MacLeod wrote: > > Aldy, could ranger handle this? If it sees .ASSUME call, > > walk the body of such function from the edge(s) to exit with the > > assumption that the function returns true, so above set _2 [true, true] > > and from there derive

Re: [PATCH][RFT] Vectorization of first-order recurrences

Richard Biener writes: > + /* First-order recurrence autovectorization needs to handle permutation > + with indices = [nunits-1, nunits, nunits+1, ...]. */ > + vec_perm_builder sel (nunits, 1, 3); > + for (int i = 0; i < 3; ++i) > +sel.quick_push (nunits - dist + i); > +

Re: Restore default 'sorry' 'TARGET_ASM_CONSTRUCTOR', 'TARGET_ASM_DESTRUCTOR' (was: [PATCH 1/3] STABS: remove -gstabs and -gxcoff functionality)

On 10/10/22 16:19, Thomas Schwinge wrote: > Hi! > > On 2022-09-01T12:05:23+0200, Martin Liška wrote: >> Patch can bootstrap on x86_64-linux-gnu and survives regression tests. >> >> I've also built all cross compilers. > > First: thanks for that: clean up plus "built all cross compilers"! > >

Re: [RFC] Teach vectorizer to deal with bitfield reads

e> gcc/gnat1 -quiet loop_optimization23_pkg.adb -O2 -Igcc/ada/rts during GIMPLE pass: vect +===GNAT BUG DETECTED==+ | 13.0.0 20221012 (experimental) [master ca7f7c3f140] (x86_64-suse-linux) GCC error:| | in exact_div, at poly-i

Re: [PATCH v2] rs6000: Rework option -mpowerpc64 handling [PR106680]

Hi Kewen, > On 12 Oct 2022, at 09:12, Kewen.Lin wrote: > PR106680 shows that -m32 -mpowerpc64 is different from > -mpowerpc64 -m32, this is determined by the way how we > handle option powerpc64 in rs6000_handle_option. > > Segher pointed out this difference should be taken as > a bug and we

Re: [Patch][v5] libgomp/nvptx: Prepare for reverse-offload callback handling

On 11.10.22 13:12, Alexander Monakov wrote: My understanding is such trickery should not be necessary with the barrier-based approach, i.e. the sequence of PTX instructions st % plain store membar.sys st.volatile should be enough to guarantee that the former store is visible on the

[COMMITTED] gcov: rename gcov_write_summary

Patch can bootstrap on x86_64-linux-gnu and survives regression tests. I'm going to install it. Martin gcc/ChangeLog: * gcov-io.cc (gcov_write_summary): Rename to ... (gcov_write_object_summary): ... this. * gcov-io.h (GCOV_TAG_OBJECT_SUMMARY_LENGTH): Rename from ...

Re: [PATCH] rs6000: Rework option -mpowerpc64 handling [PR106680]

Hi Segher! on 2022/10/10 21:58, Segher Boessenkool wrote: > On Mon, Oct 10, 2022 at 10:15:58AM +0800, Kewen.Lin wrote: >> on 2022/10/4 05:15, Segher Boessenkool wrote: >>> Right. If If mpowerpc64 is enabled while OS_MISSING_POWERPC64, warn for >>> that; >> >> Currently if option powerpc64 is

[PATCH] machmode: Introduce GET_MODE_NEXT_MODE with previous GET_MODE_WIDER_MODE meaning, add new GET_MODE_WIDER_MODE

On Wed, Oct 05, 2022 at 04:02:25PM -0400, Jason Merrill wrote: > > > > @@ -5716,7 +5716,13 @@ emit_store_flag_1 (rtx target, enum rtx_ > > > >{ > > > > machine_mode optab_mode = mclass == MODE_CC ? CCmode : > > > > compare_mode; > > > > icode = optab_handler (cstore_optab,

[PATCH v2] rs6000: Rework option -mpowerpc64 handling [PR106680]

Hi, PR106680 shows that -m32 -mpowerpc64 is different from -mpowerpc64 -m32, this is determined by the way how we handle option powerpc64 in rs6000_handle_option. Segher pointed out this difference should be taken as a bug and we should ensure that option powerpc64 is independent of -m32/-m64.

Re: [PATCH v2 00/10] [RISC-V] Atomics improvements [PR100265/PR100266]

On Wed, Oct 12, 2022 at 2:15 AM Palmer Dabbelt wrote: > On Tue, 11 Oct 2022 16:31:25 PDT (-0700), Vineet Gupta wrote: > > > > > > On 10/11/22 13:46, Christoph Müllner wrote: > >> On Tue, Oct 11, 2022 at 9:31 PM Palmer Dabbelt > wrote: > >> > >> On Tue, 11 Oct 2022 12:06:27 PDT (-0700),

RE: [PATCH] MAINTAINERS: Add myself for write after approval

> -Original Message- > From: Cui, Lili > Sent: Wednesday, October 12, 2022 3:50 PM > To: gcc-patches@gcc.gnu.org > Cc: Liu, Hongtao > Subject: [PATCH] MAINTAINERS: Add myself for write after approval > > Hi, > > I want to add myself in MAINTANINER for write after approval. > > OK

[PATCH] MAINTAINERS: Add myself for write after approval

Hi, I want to add myself in MAINTANINER for write after approval. OK for master? ChangeLog: * MAINTAINERS (Write After Approval): Add myself. --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 11fa8bc6dbd..e4e7349a6d9 100644 ---

[PATCH (pushed)] regenerate configure files

Needed after a recent change. gcc/ChangeLog: * configure: Regenerate. libatomic/ChangeLog: * configure: Regenerate. libbacktrace/ChangeLog: * configure: Regenerate. libcc1/ChangeLog: * configure: Regenerate. libffi/ChangeLog: * configure:

Re: [PATCH v2 2/3] doc: -falign-functions is ignored under -Os

> This is implicitly mentioned in the docs, but there were some questions > in a recent patch. This makes it more exlicit that -falign-functions is > meant to be ignored under -Os. > > gcc/doc/ChangeLog > > * invoke.texi (-falign-functions): Mention -Os > --- > gcc/doc/invoke.texi | 3

[COMMITTED] Add an frange(type) constructor analogous to the irange version.

gcc/ChangeLog: * value-range.h (frange::frange): Add constructor taking type. --- gcc/value-range.h | 8 1 file changed, 8 insertions(+) diff --git a/gcc/value-range.h b/gcc/value-range.h index 07a2067898c..9d630e40f78 100644 --- a/gcc/value-range.h +++ b/gcc/value-range.h @@

[COMMITTED] Disable tree to bool conversion in frange::update_nan.

We have a set_nan(type) method which can be confused with update_nan(bool) because of the silent conversion of pointers to bool. Currently, if you call update_nan(tree), you'll set the possibility of NAN with a sign of true if tree is non-null. This is prone to error and this patch disallows this

[COMMITTED] Add default relation_kind to floating point range-op entries.

The methods from which these derive all have a default relation_kind. This patch just adds the default, to make it easier to write unit tests later. gcc/ChangeLog: * range-op-float.cc: Add relation_kind = VREL_VARYING to all methods. --- gcc/range-op-float.cc | 80

[COMMITTED] Add stubs for floating point range-op tests.

gcc/ChangeLog: * range-op-float.cc (frange_float): New. (range_op_float_tests): New. * range-op.cc (range_op_tests): Call range_op_float_tests. --- gcc/range-op-float.cc | 26 ++ gcc/range-op.cc | 3 +++ 2 files changed, 29 insertions(+)

[COMMITTED] Add method to query the sign of a NAN.

In writing some range-op entries I noticed we don't have a way to query the sign of the NAN in a range, unless the range only contains NAN, in which case you can just use frange::signbit_p. This patch adds a method that returns TRUE if there exists the possiblity of a NAN and we know its sign.

[PATCH V4] rs6000: cannot_force_const_mem for HIGH code rtx[PR106460]

Hi, As the issue in PR106460, a rtx 'high:DI (symbol_ref:DI ("var_48")' is tried to store into constant pool and ICE occur. But actually, this rtx represents partial incomplete address and can not be put into a .rodata section. This patch updates rs6000_cannot_force_const_mem to return true for

Ping^2: [PATCH V6] rs6000: Optimize cmp on rotated 16bits constant

Gentle ping: https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600475.html BR, Jeff (Jiufu) Jiufu Guo via Gcc-patches writes: > Ping: https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600475.html > > BR, > Jeff(Jiufu) > > > Jiufu Guo writes: > >> Hi, >> >> When checking eq/ne with a

Re: [PATCH] coroutines: Use cp_build_init_expr consistently.

> On 12 Oct 2022, at 00:19, Jason Merrill wrote: > > On 10/11/22 18:17, Iain Sandoe wrote: >> Hi Jason >>> On 11 Oct 2022, at 23:06, Jason Merrill wrote: >>> >>> On 10/11/22 17:58, Iain Sandoe wrote: Now we have the TARGET_EXPR_ELIDING_P flag, it is important to ensure it is set