Re: [PATCH v3 11/11] riscv: thead: Add support for the XTheadFMemIdx ISA extension

> + > +(define_memory_constraint "Qmx" > + "@internal > + An address valid for GPR." > + (and (match_code "mem") > + (match_test "!riscv_legitimize_address_index_p ( > + XEXP (op, 0), GET_MODE (op), false)"))) Check TARGET_XTHEADFMEMIDX, and I don't quite understand

Re: [PATCH v3 04/11] riscv: thead: Add support for the XTheadBs ISA extension

> diff --git a/gcc/config/riscv/thead.md b/gcc/config/riscv/thead.md > index 158e9124c3a..2c684885850 100644 > --- a/gcc/config/riscv/thead.md > +++ b/gcc/config/riscv/thead.md > @@ -29,3 +29,14 @@ (define_insn "*th_addsl" >"th.addsl\t%0,%3,%1,%2" >[(set_attr "type" "bitmanip") >

Re: [wwwdocs, patch] OpenMP update for gcc-13/changes.html + projects/gomp/

On 2/24/23 04:02, Gerald Pfeifer wrote: > On Thu, 23 Feb 2023, Tobias Burnus wrote: >> PS: I also removed a stray , but admittedly only after the >> commit. I found it by manually running those through the w3 validator >> site. However, I did not see an automatic email, either it takes longer >>

[PATCH v2] Print padding size when aligning struct member

Hello, I changed the tested pattern to match even on targets with different alignment. BR, VK -- >8 -- Announce the size of introduced padding when compiling with -Wpadded. gcc/ChangeLog: * stor-layout.cc (place_field): Change warning message format gcc/testsuite/ChangeLog:

RE: Re: [PATCH] RISC-V: Bugfix for rvv bool mode precision adjustment

Hi Richard Sandiford, Looks like you are busy and stuck in some important work right now, could you please help to share something like ETA if possible? Then we may have a better plan for the RVV intrinsic support in the GCC 13. Thanks a lot and feel free to ping us if any question or concern.

Re: [PATCH v3 03/11] riscv: thead: Add support for the XTheadBa ISA extension

On Thu, Feb 23, 2023 at 9:55 PM Christoph Muellner wrote: > > From: Christoph Müllner > > This patch adds support for the XTheadBa ISA extension. > The new INSN pattern is defined in a new file to separate > this vendor extension from the standard extensions. How does this interact with doing

Re: [wwwdocs] Add revised Texinfo manual CSS

Morning, Gerald Pfeifer writes: > On Fri, 27 Jan 2023, Arsen Arsenović via Gcc-patches wrote: >> htdocs/texinfo-manuals.css | 129 + > > Thank you - I pushed this. > > +/* Texinfo documentation stylesheet. > + Inspired by the Gnulib manual, 2023-01-26. > +

Re: [gcc] RTEMS: Tune multilib selection

On 23.02.23 19:38, Palmer Dabbelt wrote: On Thu, 23 Feb 2023 03:48:26 PST (-0800), sebastian.hu...@embedded-brains.de wrote: gcc/ChangeLog: * config/riscv/t-rtems: Keep only -mcmodel=medany 64-bit multilibs. Add non-compact 32-bit multilibs. ---  gcc/config/riscv/t-rtems | 17

[PATCH v3 10/11] riscv: thead: Add support for the XTheadMemIdx ISA extension

From: "moiz.hussain" The XTheadMemIdx ISA extension provides a additional addressing modes to load and store instructions: * increment after * increment before * register indexed gcc/ChangeLog: * config/riscv/constraints.md (Qmb): New constraint. (Qma): Likewise. (Qmr):

[PATCH v3 09/11] riscv: thead: Add support for the XTheadMemPair ISA extension

From: Christoph Müllner The XTheadMemPair ISA extension allows to pair two loads or stores: * th.ldd (2x LD) * th.lwd (2x LW) * th.lwud (2x LWU) * th.sdd (2x SD) * th.swd (2x SW) The displacement of these instructions is quite limited: * Displacement := imm2 << shamt * imm2 is a 2-bit unsigned

[PATCH v3 08/11] riscv: thead: Add support for the XTheadFmv ISA extension

From: Christoph Müllner The XTheadFmv ISA extension provides instructions to move data between 32-bit GP registers and 64-bit FP registers. gcc/ChangeLog: * config/riscv/constraints.md (TARGET_XTHEADFMV ? FP_REGS : NO_REGS) New constraint "th_f_fmv". (TARGET_XTHEADFMV ?

[PATCH v3 11/11] riscv: thead: Add support for the XTheadFMemIdx ISA extension

From: "moiz.hussain" The XTheadFMemIdx ISA extension provides register-indexed addressing modes to floating-point load and store instructions. gcc/ChangeLog: * config/riscv/constraints.md (Qmx): New constraint. * config/riscv/riscv-protos.h (riscv_output_move_index_float):

[PATCH v3 03/11] riscv: thead: Add support for the XTheadBa ISA extension

From: Christoph Müllner This patch adds support for the XTheadBa ISA extension. The new INSN pattern is defined in a new file to separate this vendor extension from the standard extensions. gcc/ChangeLog: * config/riscv/riscv.md: Include thead.md * config/riscv/thead.md: New

[PATCH v3 06/11] riscv: thead: Add support for the XTheadCondMov ISA extensions

From: Christoph Müllner This patch adds support for XTheadCondMov ISA extension. The extension brings a one-sided conditional move (no else-assignment). Given that GCC has a great if-conversion pass, we don't need to do much, besides properly expanding movcc accordingly and adjust the cost

[PATCH v3 05/11] riscv: thead: Add support for the XTheadBb ISA extension

From: Christoph Müllner This patch adds support for the XTheadBb ISA extension. Thus, there is a functional overlap of the new instructions with existing Bitmanip instruction, which allows a good amount of code sharing. However, the vendor extensions are cleanly separated from the standard

[PATCH v3 07/11] riscv: thead: Add support for the XTheadMac ISA extension

From: Christoph Müllner The XTheadMac ISA extension provides multiply-accumulate/subtract instructions: * mula/mulaw/mulah * muls/mulsw/mulsh To benefit from middle-end passes, we expand the following named patterns in riscv.md (as they are not T-Head-specific): * maddhisi4 * msubhisi4

[PATCH v3 00/11] RISC-V: Add XThead* extension support

From: Christoph Müllner This series introduces support for the T-Head specific RISC-V ISA extensions which are available e.g. on the T-Head XuanTie C906. The ISA spec can be found here: https://github.com/T-head-Semi/thead-extension-spec This series adds support for the following XThead*

[PATCH v3 02/11] riscv: riscv-cores.def: Add T-Head XuanTie C906

From: Christoph Müllner This adds T-Head's XuanTie C906 to the list of known cores as "thead-c906". The C906 is shipped for quite some time (it is the core of the Allwinner D1). Note, that the tuning struct for the C906 is already part of GCC (it is also name "thead-c906"). gcc/ChangeLog:

[PATCH v3 04/11] riscv: thead: Add support for the XTheadBs ISA extension

From: Christoph Müllner This patch adds support for the XTheadBs ISA extension. The new INSN pattern is defined in a new file to separate this vendor extension from the standard extensions. The cost model adjustment reuses the xbs:bext cost. gcc/ChangeLog: * config/riscv/riscv.cc

[PATCH v3 01/11] riscv: Add basic XThead* vendor extension support

From: Christoph Müllner This patch add basic support for the following XThead* ISA extensions: * XTheadBa * XTheadBb * XTheadBs * XTheadCmo * XTheadCondMov * XTheadFMemIdx * XTheadFmv * XTheadInt * XTheadMac * XTheadMemIdx * XTheadMemPair * XTheadSync The extensions are just recognized by the

Re: Support for WEAK attribute, part 2

On Thu, Feb 23, 2023 at 10:53 PM Harald Anlauf wrote: > the patch is mostly fine, but there is a minor style issue: > > + if (sym->attr.ext_attr & (1 << EXT_ATTR_WEAK)) > + gfc_error ("Symbol %qs at %L has the WEAK attribute but is a %s", > + sym->name, >declared_at,

Re: Re: [PATCH] RISC-V: Bugfix for rvv bool mode precision adjustment

Hi, It's been a while since this patch is sent. This patch is very important for us since we are going to release RVV intrinsic support in GCC 13. And this is the patch to fix bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108654 Can any one verifies this patch for us? Thanks.

Re: [PATCH] vect: Check that vector factor is a compile-time constant

Hi Jeff: > What I'd been planning to do internally at Ventana was to update our > codebase to gcc-13 once it's released. Then I'd backport RVV autovec > work from the gcc-14 dev tree into that Ventana branch. > > Instead, but along the same lines, we could have a public gcc-13 based > branch

Re: [PATCH] vect: Check that vector factor is a compile-time constant

On 2/22/23 21:50, Michael Collison wrote: Hi Jeff, We do not have two independent implementations: my work is 100% based on the vector intrinsic foundation in upstream GCC. Phew! That's good news. I totally misunderstood. In fact I have only added two core patterns, vector add and

[PATCH] RISC-V: Disable attribute generation by default

We generate a handful of attributes by default, but they don't really encode any useful information. We've broadly stopped ascribing any meaning to them in binutils; but they trip up LLVM, older toolchains, and users. So let's just turn them off by default. The old binaries will still be

Re: [wwwdocs, patch] OpenMP update for gcc-13/changes.html + projects/gomp/

On Thu, 23 Feb 2023, Tobias Burnus wrote: > PS: I also removed a stray , but admittedly only after the > commit. I found it by manually running those through the w3 validator > site. However, I did not see an automatic email, either it takes longer > or does it no longer run? It did in the past!

Re: [v3][PATCH 2/2] Update documentation to clarify a GCC extension (PR77650)

On Thu, 23 Feb 2023, Qing Zhao via Gcc-patches wrote: > But the following: > > struct flex1 { int length1; char data1[]; }; > struct flex2 { int length2; char data2[]; }; > union union_flex { struct flex1 f1; struct flex2 f2; }; /* this is C > standard. */ > > struct out_flex { int n;

Re: [wwwdocs] Add revised Texinfo manual CSS

On Fri, 27 Jan 2023, Arsen Arsenović via Gcc-patches wrote: > htdocs/texinfo-manuals.css | 129 + Thank you - I pushed this. +/* Texinfo documentation stylesheet. + Inspired by the Gnulib manual, 2023-01-26. + + Arsen Arsenović Can we rephrase this a

[COMMITTED 1/2] gcc: xtensa: rename xtensa-dynconfig.c and update its build rule

gcc/ * config/xtensa/t-xtensa (xtensa-dynconfig.o): Use $(COMPILE) and $(POSTCOMPILE) instead of manual dependency listing. * config/xtensa/xtensa-dynconfig.c: Rename to ... * config/xtensa/xtensa-dynconfig.cc: ... this. --- gcc/config/xtensa/t-xtensa

[COMMITTED 2/2] gcc: xtensa: update include style in xtensa-dynconfig.cc

gcc/ * config/xtensa/xtensa-dynconfig.cc (config.h, system.h) (coretypes.h, diagnostic.h, intl.h): Use "..." instead of <...> for the gcc-internal headers. --- gcc/config/xtensa/xtensa-dynconfig.cc | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff

[PATCH] c++: ICE with constexpr variable template [PR107938]

Since r11-557, cp_finish_decl can call check_initializer even in a template for a constexpr initializer. That ultimately leads to convert_for_assignment and check_address_or_pointer_of_packed_member, where we crash, because it doesn't expect that the CALL_EXPR is a function object. Q has a

Re: [PATCH v2 2/5] **/*.texi: Reorder index entries

On Thu, 23 Feb 2023, Arsen Arsenović wrote: > This change is a generalization of r13-6292-gddf6fe375d9110. : > gcc/d/ChangeLog: > > * implement-d.texi: Reorder index entries around @items. > > gcc/ChangeLog: > > * doc/cfg.texi: Reorder index entries around @items. > *

Re: [PATCH 1/2] xtensa: Fix non-fatal regression introduced by b2ef02e8cbbaf95fee98be255f697f47193960ec

On Thu, Feb 23, 2023 at 1:35 AM Max Filippov wrote: > > On Wed, Feb 22, 2023 at 7:42 PM Takayuki 'January June' Suwa > wrote: > > > > In commit b2ef02e8cbbaf95fee98be255f697f47193960ec, the sibling call > > insn included (use (reg:SI A0_REG)) to fix the problem, which added > > a USE chain

Re: [PATCH v7] xtensa: Eliminate the use of callee-saved register that saves and restores only once

On Thu, Feb 16, 2023 at 11:54 PM Takayuki 'January June' Suwa wrote: > > In the case of the CALL0 ABI, values that must be retained before and > after function calls are placed in the callee-saved registers (A12 > through A15) and referenced later. However, it is often the case that > the save

Re: [PATCH v5] xtensa: Eliminate unnecessary general-purpose reg-reg moves

On Fri, Feb 17, 2023 at 8:43 PM Takayuki 'January June' Suwa wrote: > > Register-register move instructions that can be easily seen as > unnecessary by the human eye may remain in the compiled result. > For example: > > /* example */ > double test(double a, double b) { > return

Re: [v3][PATCH 2/2] Update documentation to clarify a GCC extension (PR77650)

> On Feb 23, 2023, at 5:04 PM, Qing Zhao via Gcc-patches > wrote: > > > >> On Feb 23, 2023, at 4:24 PM, Joseph Myers wrote: >> >> On Thu, 23 Feb 2023, Qing Zhao via Gcc-patches wrote: >> >>> +@item >>> +The structure with a C99 flexible array member is the field of >>> +another union,

Re: [PATCH] xtensa: Fix up fatal_error message strings in xtensa-dynconfig.c [PR108890]

Hi Jakub, On Thu, Feb 23, 2023 at 2:34 AM Jakub Jelinek wrote: > The translation PR complains that these 4 messages from xtensa-dynconfig.c > are marked in po/gcc.pot as c-format (which doesn't allow %qs) while they > should be gcc-internal-format. > > The problem is in the manual translation of

Re: [v3][PATCH 2/2] Update documentation to clarify a GCC extension (PR77650)

> On Feb 23, 2023, at 4:24 PM, Joseph Myers wrote: > > On Thu, 23 Feb 2023, Qing Zhao via Gcc-patches wrote: > >> +@item >> +The structure with a C99 flexible array member is the field of >> +another union, for example: >> + >> +@smallexample >> +struct flex1 @{ int length1; char data1[]; @}

[PATCH] c++: non-dependent variable template-id [PR108848]

Here we're incorrectly treating the non-dependent variable template-id tag as dependent ever since r226642 gave variable TEMPLATE_ID_EXPR an empty type which causes the call to finish_template_variable from finish_id_expression_1 to be dead code at template parse time. Thus we're led into

Re: Fwd: [v3][PATCH 2/2] Update documentation to clarify a GCC extension (PR77650)

On Thu, 23 Feb 2023, Qing Zhao via Gcc-patches wrote: > +@item > +The structure with a C99 flexible array member is the field of > +another union, for example: > + > +@smallexample > +struct flex1 @{ int length1; char data1[]; @} > +struct flex2 @{ int length2; char data2[]; @} > + > +union

Re: [PATCH v2] RISC-V: Produce better code with complex constants [PR95632] [PR106602]

On Fri, Dec 9, 2022 at 10:25 AM Raphael Moreira Zinsly wrote: > > Changes since v1: > - Fixed formatting issues. > - Added a name to the define_insn_and_split pattern. > - Set the target on the 'dg-do compile' in pr106602.c. > - Removed the rv32 restriction in

Re: C++ modules and AAPCS/ARM EABI clash on inline key methods

On Feb 23, 2023, Alexandre Oliva wrote: > On Feb 23, 2023, Richard Earnshaw wrote: >> On 22/02/2023 19:57, Alexandre Oliva wrote: >>> On Feb 21, 2023, Richard Earnshaw wrote: >>> Rather than scanning for the triplet, a better test would be >>> { xfail { arm_eabi } } >>> >>>

[PATCH] Fix std::unordered_map key range insertion

Hi Based on my work on PR 96088 for std::map I imagine this use case of inserting a range of keys into an associative container. It behaves as operator[] by inserting a default value for each key. I wonder if the Standard says that it should work. Or maybe we want to support it ? I

Re: [gcc] RTEMS: Tune multilib selection

On Thu, 23 Feb 2023 03:48:26 PST (-0800), sebastian.hu...@embedded-brains.de wrote: gcc/ChangeLog: * config/riscv/t-rtems: Keep only -mcmodel=medany 64-bit multilibs. Add non-compact 32-bit multilibs. --- gcc/config/riscv/t-rtems | 17 + 1 file changed, 9

Re: [PATCH] [PR77760] [libstdc++] encode __time_get_state in tm

On Thu, 23 Feb 2023 at 17:55, Alexandre Oliva wrote: > > On Feb 22, 2023, Alexandre Oliva wrote: > > >> Just curious, why doesn't the pmf hack work on arm-vxworks7? > > > At first, I thought we were running into this just because we have to > > define __clang__ because of some vxworks system

Re: Ping^2: [PATCH+wwwdocs 0/8] A small Texinfo refinement

On 2/22/23 18:26, Gerald Pfeifer wrote: On Tue, 21 Feb 2023, Arsen Arsenović wrote: Ping. Like last time, I rebased the series. Thank you! The first two times around, I did not notice there's dedicated maintainers for the documentation component, and so, I am adding Gerald, Joseph and

Re: [PATCH] [PR77760] [libstdc++] encode __time_get_state in tm

On Feb 22, 2023, Alexandre Oliva wrote: >> Just curious, why doesn't the pmf hack work on arm-vxworks7? > At first, I thought we were running into this just because we have to > define __clang__ because of some vxworks system headers aimed at clang. > But even as I tried to drop the #ifndef,

Re: [PATCH] libstdc++: Add Doxygen comment for string::resize_and_overwite

On Thu, 23 Feb 2023 at 17:42, Daniel Krügler wrote: > > Am Do., 23. Feb. 2023 um 18:38 Uhr schrieb Jonathan Wakely via > Libstdc++ : > > > > Reviews of the resize_and_overwite description welcome. I've tried to > > strike a balance between pedantic precision and user-friendliness. > > > > -- >8

Re: [PATCH] libstdc++: Add Doxygen comment for string::resize_and_overwite

Am Do., 23. Feb. 2023 um 18:38 Uhr schrieb Jonathan Wakely via Libstdc++ : > > Reviews of the resize_and_overwite description welcome. I've tried to > strike a balance between pedantic precision and user-friendliness. > > -- >8 -- > > This is a complicated API that should be clearly documented. >

[PATCH] libstdc++: Add Doxygen comment for string::resize_and_overwite

Reviews of the resize_and_overwite description welcome. I've tried to strike a balance between pedantic precision and user-friendliness. -- >8 -- This is a complicated API that should be clearly documented. Also improve the comment on basic_ios::_M_setstate. libstdc++-v3/ChangeLog: *

Re: C++ modules and AAPCS/ARM EABI clash on inline key methods

On Feb 23, 2023, Richard Earnshaw wrote: > On 22/02/2023 19:57, Alexandre Oliva wrote: >> On Feb 21, 2023, Richard Earnshaw wrote: >> >>> Rather than scanning for the triplet, a better test would be >> >>> { xfail { arm_eabi } } >> >> Indeed, thanks. Here's the updated patch, retested. Ok

RE: [PATCH 1/2]middle-end: Fix wrong overmatching of div-bitmask by using new optabs [PR108583]

> -Original Message- > From: Andrew MacLeod > Sent: Thursday, February 23, 2023 4:40 PM > To: Tamar Christina ; Richard Biener > ; Richard Sandiford > Cc: Tamar Christina via Gcc-patches ; nd > ; j...@ventanamicro.com > Subject: Re: [PATCH 1/2]middle-end: Fix wrong overmatching of

Re: [Patch] Fortran/OpenMP: Fix mapping of array descriptors and deferred-length strings

Minor change to previous patch – it did not affect the mainline build but it makes more sense this way and on OG12, i.e. with mapping allocatable components (patch posted last year in Q1 during Stage 4), it gave an ICE without this change as one '*' wasn't stripped. ---

Re: [PATCH 1/2]middle-end: Fix wrong overmatching of div-bitmask by using new optabs [PR108583]

On 2/23/23 03:36, Tamar Christina wrote: Hi Andrew, Oh yeah, and in case you haven't figured it out on your own, you'll have to remove WIDEN_MULT_EXPR from the range-ops init table.   This non-standard mechanism only gets checked if there is no standard range-op table entry for the tree code

Re: Willing to contribute to the project Idea "Fortran – DO CONCURRENT"

On Thu, Feb 23, 2023 at 07:24:26AM -0800, Damian Rouson wrote: > I wonder if a relatively easy starting point would be enabling the > declaration of do concurrent construct variables: > > do concurrent (integer :: i = 1:n) > > It’s a minor convenience and less exciting than adding locality

Re: [PATCH] c++: variable template and targ deduction [PR108550]

On Thu, Feb 23, 2023 at 10:17:22AM -0500, Patrick Palka wrote: > On Wed, 22 Feb 2023, Marek Polacek wrote: > > > In this test, we get a bogus error because we failed to deduce the auto in > > constexpr auto is_pointer_v = is_pointer::value; > > to bool. Then

Re: Willing to contribute to the project Idea "Fortran – DO CONCURRENT"

I wonder if a relatively easy starting point would be enabling the declaration of do concurrent construct variables: do concurrent (integer :: i = 1:n) It’s a minor convenience and less exciting than adding locality specifiers but possibly a good first exercise. Damian On Thu, Feb 23, 2023 at

Re: [PATCH] Avoid default-initializing auto_vec storage

On Thu, Feb 23, 2023 at 03:02:01PM +, Richard Biener wrote: > > > * vec.h (auto_vec): Turn m_data storage into > > > uninitialized unsigned char. > > > > Given that we actually never reference the m_data array anywhere, > > it is just to reserve space, I think even the alignas(T) there is

Re: [PATCH] c++: variable template and targ deduction [PR108550]

On Wed, 22 Feb 2023, Marek Polacek wrote: > In this test, we get a bogus error because we failed to deduce the auto in > constexpr auto is_pointer_v = is_pointer::value; > to bool. Then ensure_literal_type_for_constexpr_object thinks the object > isn't literal and an error is reported. > > This

[PATCH] libatomic: Fix SEQ_CST 128-bit atomic load [PR108891]

The LSE2 ifunc for 16-byte atomic load requires a barrier before the LDP - without it, it effectively has Load-AcquirePC semantics similar to LDAPR, which is less restrictive than what __ATOMIC_SEQ_CST requires. This patch fixes this and adds comments to make it easier to see which sequence is

Re: Willing to contribute to the project Idea "Fortran – DO CONCURRENT"

Hi, and welcome to the GCC / gfortran community. On 23.02.23 14:15, varma datla via Fortran wrote: I am willing to contribute to the project idea "Fortran – DO CONCURRENT". I hope the following helps a bit – it is admittedly a bit chaotic, but I try to write something cleaner later. But to

Re: [PATCH] testsuite: Fix up modules.exp [PR108899]

On Thu, 23 Feb 2023, Jakub Jelinek wrote: > Hi! > > On Wed, Feb 22, 2023 at 02:33:42PM -0300, Alexandre Oliva via Gcc-patches > wrote: > > When a multi-source module is found to be unsupported, we fail > > module_cmi_p and subsequent sources. Override proc unsupported to > > mark the result in

Re: [PATCH] Avoid default-initializing auto_vec storage

On Thu, 23 Feb 2023, Jakub Jelinek wrote: > On Thu, Feb 23, 2023 at 01:54:27PM +0100, Richard Biener wrote: > > The following avoids default-initializing auto_vec storage for > > non-POD T since that's not what the allocated storage fallback > > will do and it's also not expected for existing

Re: [wwwdocs, patch] OpenMP update for gcc-13/changes.html + projects/gomp/

On 23.02.23 00:29, Gerald Pfeifer wrote: On Wed, 22 Feb 2023, Tobias Burnus wrote: Comments? Suggestions? Would it make sense to sort AMD GCN and nvptx alphabetically (and in turn switch the order)? From a wwwdocs perspective the changes look fine. Thanks for having a look. I swapped them

[PATCH] testsuite: Fix up modules.exp [PR108899]

Hi! On Wed, Feb 22, 2023 at 02:33:42PM -0300, Alexandre Oliva via Gcc-patches wrote: > When a multi-source module is found to be unsupported, we fail > module_cmi_p and subsequent sources. Override proc unsupported to > mark the result in module_do, and test it to skip module_cmp_p and >

Re: [PATCH] c++: Fix up -fcontracts option description [PR108890]

On Thu, Feb 23, 2023 at 11:26:27AM +0100, Jakub Jelinek via Gcc-patches wrote: > Hi! > > This translation PR mentioned the description is a little bit weird. > > Ok for trunk? I think this is OK... > 2023-02-23 Jakub Jelinek > > PR translation/108890 > * c.opt (fcontracts):

Fwd: [v3][PATCH 2/2] Update documentation to clarify a GCC extension (PR77650)

Ping * 2. Hi, Joseph and Richard, Could you please review this patch and let me know whether it’s ready for committing into GCC13? thanks. Qing Begin forwarded message: From: Qing Zhao mailto:qing.z...@oracle.com>> Subject: [v3][PATCH 2/2] Update documentation to clarify a GCC extension

Fwd: [v3][PATCH 1/2] Handle component_ref to a structre/union field including C99 FAM [PR101832]

Ping * 2. Hi, Joseph and Richard, Could you please review this patch and let me know whether it’s ready for committing into GCC13? This is an important bug that need to be fixed for kernel security purpose. thanks. Qing Begin forwarded message: From: Qing Zhao mailto:qing.z...@oracle.com>>

Re: [PATCH] Avoid default-initializing auto_vec storage

On Thu, Feb 23, 2023 at 01:54:27PM +0100, Richard Biener wrote: > The following avoids default-initializing auto_vec storage for > non-POD T since that's not what the allocated storage fallback > will do and it's also not expected for existing cases like > > auto_vec, 64> elts; > > which exist

[PATCH] Fix memory leak in PTA

When handle_lhs_call calls .create on the passed in vector it leaks any previous allocated storage. Avoid doing that and instead rely on the caller for memory management, just truncate the vector. Bootstrap and regtest running on x86_64-unknown-linux-gnu. * tree-ssa-structalias.cc

[PATCH] Avoid default-initializing auto_vec storage

The following avoids default-initializing auto_vec storage for non-POD T since that's not what the allocated storage fallback will do and it's also not expected for existing cases like auto_vec, 64> elts; which exist to optimize the allocation. Bootstrapped and tested on

[committed][OG12] libgomp: no need to attach USM pointers

This patch fixes a bug in which libgomp doesn't know what to do with attached pointers in fortran derived types when using Unified Shared Memory instead of explicit mappings. I've committed it to the devel/omp/gcc-12 branch (OG12) and will fold it into the next rebase/repost of the USM

[PATCH][wwwdocs][committed] Extend changes.html entries for arm and aarch64

Hi all, Here's a patch that fleshes out the changes.html entries for arm and aarch64. I did a quick scan through appropriately filtered git logs and wrote up stuff that I think is user-visible, but please shout if you know of things that should be highlighted as there's been much great work

[gcc] RTEMS: Tune multilib selection

gcc/ChangeLog: * config/riscv/t-rtems: Keep only -mcmodel=medany 64-bit multilibs. Add non-compact 32-bit multilibs. --- gcc/config/riscv/t-rtems | 17 + 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/gcc/config/riscv/t-rtems

Re: [PATCH 4/8] libstdc++: Add missing constexpr on simd shift implementation

On Thursday, 23 February 2023 12:07:11 CET Jonathan Wakely wrote: > On Thu, 23 Feb 2023 at 08:55, Matthias Kretz via Libstdc++ > > wrote: > > Resolves -Wtautological-compare warnings about `if > > (__builtin_is_constant_evaluated())` in the implementations of these > > functions. > > The

Re: [PATCH 8/8] libstdc++: Test that integral simd reductions are precise

On Thu, 23 Feb 2023 at 08:51, Matthias Kretz via Libstdc++ wrote: > OK for all branches. > > Signed-off-by: Matthias Kretz > > libstdc++-v3/ChangeLog: > > * testsuite/experimental/simd/tests/reductions.cc: Introduce > max_distance as the type-dependent max error. > --- >

Re: [PATCH 7/8] libstdc++: Fix -Wsign-compare issue

On Thu, 23 Feb 2023 at 08:51, Matthias Kretz via Libstdc++ wrote: > > OK for all branches. > Signed-off-by: Matthias Kretz > > libstdc++-v3/ChangeLog: > > * include/experimental/bits/simd_builtin.h (_S_set): Compare as > int. The actual range of these indexes is very small. >

Re: [PATCH 4/8] libstdc++: Add missing constexpr on simd shift implementation

On Thu, 23 Feb 2023 at 08:55, Matthias Kretz via Libstdc++ wrote: > > > > Resolves -Wtautological-compare warnings about `if > (__builtin_is_constant_evaluated())` in the implementations of these > functions. The 'inline' is redundant now, because these are unconditionally constexpr which

Re: [PATCH 2/8] libstdc++: Fix simd build failure on clang

On Thu, 23 Feb 2023 at 08:54, Matthias Kretz via Libstdc++ wrote: > > > > Clang does not support __attribute__ on lambdas. Therefore, only set > _GLIBCXX_SIMD_ALWAYS_INLINE_LAMBDA if __clang__ is not defined. OK for all branches. > Signed-off-by: Matthias Kretz > > libstdc++-v3/ChangeLog: > >

Re: [PATCH 1/8] libstdc++: Simplify three helper functions into one

On Thu, 23 Feb 2023 at 08:53, Matthias Kretz via Libstdc++ wrote: > > > > Broadcast is a very common function. This should reduce compile-time > effort. OK for all branches. > Signed-off-by: Matthias Kretz > > libstdc++-v3/ChangeLog: > > PR libstdc++/108030 > *

[PATCH] Fix memory leak in if-conversion

The following fixes if-conversion failing to release data-references and the data-reference vector. Bootstrapped on x86_64-unknown-linux-gnu, testing in progress. * tree-if-conv.cc (tree_if_conversion): Properly manage memory of refs and the contained data references. ---

Re: [committed 034/103] gccrs: dump: Emit visibility when dumping items

On 2/23/23 02:01, Gerald Pfeifer wrote: Just noticed this by chance: How does this patch constitute a functional change (that matches the ChangeLog)? It looks it only adds an empty line to the source code? Huh. That is weird. Sorry about that! This range of commits on our AST dump contained

Re: [PATCH] libgcc_s: Use alias for __cpu_indicator_init instead of symver

On Wed, Feb 22, 2023 at 04:23:33AM -0800, Yash Shinde wrote: > From: Khem Raj > > Adapter from > > https://gcc.gnu.org/ml/gcc-patches/2015-05/msg00899.html > > This fix was debated but hasnt been applied gcc upstream since > they expect musl to support '@' in symbol versioning which is > a

[PATCH] xtensa: Fix up fatal_error message strings in xtensa-dynconfig.c [PR108890]

Hi! The translation PR complains that these 4 messages from xtensa-dynconfig.c are marked in po/gcc.pot as c-format (which doesn't allow %qs) while they should be gcc-internal-format. The problem is in the manual translation of the strings with _(), that should be both unnecessary because

Re: [PATCH] ipa-prop: Fix another case of missing BUILT_IN_UNREACHABLE_TRAP handling [PR106258]

On Thu, Feb 23, 2023 at 7:56 AM Jakub Jelinek wrote: > > On Wed, Feb 22, 2023 at 07:46:46PM +0100, Richard Biener wrote: > > Ok for stage1 > > Thanks. In that case, can we get at least following into GCC 13, > another spot that handles in IPA just BUILT_IN_UNREACHABLE and > not

[PATCH v2 3/5] doc: Add @defbuiltin family of helpers, set documentlanguage

The @defbuiltin{,x} macros are convenience macros for the often-repeated task of defining a built-in function in extend.texi. Usage of this macro should lead to a higher degree of consistency across pieces of text written by different people, and provide a better reading experience, as they

[PATCH v2 5/5] update_web_docs_git: Update CSS reference to new manual CSS

maintainer-scripts/ChangeLog: * update_web_docs_git (CSS): Update CSS reference to point to /texinfo-manuals.css. --- maintainer-scripts/update_web_docs_git | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/maintainer-scripts/update_web_docs_git

[PATCH v2 1/5] docs: Create Indices appendix

The GCC manual has multiple indices. By creating an appendix which lists them, we help makeinfo present a more accessible way for the reader to see all the indices. gcc/ChangeLog: * doc/gcc.texi: Add the Indices appendix, to make texinfo generate nice indices overview page.

[PATCH v2 0/5] A small Texinfo refinement

Morning, (as said in ) This is a rebase + slight amendment of the previous patch series visible at: https://inbox.sourceware.org/gcc-patches/cover.1674777149.git.ar...@aarsen.me/ The commit "docs: Reorder @opindex to be before

[PATCH] c++: Fix up -fcontracts option description [PR108890]

Hi! This translation PR mentioned the description is a little bit weird. Ok for trunk? 2023-02-23 Jakub Jelinek PR translation/108890 * c.opt (fcontracts): Fix description. --- gcc/c-family/c.opt.jj 2023-02-01 10:19:42.637146215 +0100 +++ gcc/c-family/c.opt

[PATCH] c++: Add target hook for emit_support_tinfos [PR108883]

Hi! _Float16 and decltype(0.0bf16) types are on x86 supported only with -msse2. On x86_64 that is the default, but on ia32 it is not. We should still emit fundamental type tinfo for those types in libsupc++.a/libstdc++.*, regardless of whether libsupc++/libstdc++ is compiled with -msse2 or not,

Re: C++ modules and AAPCS/ARM EABI clash on inline key methods

On 22/02/2023 19:57, Alexandre Oliva wrote: On Feb 21, 2023, Richard Earnshaw wrote: Rather than scanning for the triplet, a better test would be { xfail { arm_eabi } } Indeed, thanks. Here's the updated patch, retested. Ok to install? Based on Nathan's comments, we should just

[PATCH] tree-optimization/108888 - call if-conversion

The following makes sure to only predicate calls necessary. Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed. PR tree-optimization/10 * tree-if-conv.cc (if_convertible_stmt_p): Set PLF_2 on calls to predicate. (predicate_statements): Only predicate

Re: [PATCH 3/3] vect: inbranch SIMD clones

On 10/02/2023 09:11, Jakub Jelinek wrote: I've tried to fix the -flto thing and I can't figure out how. The problem seems to be that there are two dump files from the two compiler invocations and it scans the wrong one. Aarch64 has the same problem. Two dumps are because it is in a dg-do run

Re: (rebased patchset) [PATCH 3/7] **/*.texi: Reorder index entries

Hi Gerald, Thanks for the review. Gerald Pfeifer writes: > I was going to push this, alas there are now rejects for > fortran/invoke.texi, gcc/doc/invoke.texi and gcc/doc/cppopts.texi. > > If you can get me a rebased version I'll give it a try again. (Or > are there some earlier dependencies?

[COMMITTED 2/2] xtensa: fix PR target/108876

In commit b2ef02e8cbbaf95fee98be255f697f47193960ec, the sibling call insn included (use (reg:SI A0_REG)) to fix the problem, which added a USE chain unconditionally to the data flow of register A0 during the sibling call. As a result, df_regs_ever_live_p (A0_REG) returns true, so even if register

[COMMITTED 1/2] Revert "gcc: xtensa: fix PR target/108876"

This reverts commit b2ef02e8cbbaf95fee98be255f697f47193960ec. --- gcc/config/xtensa/xtensa.cc | 2 ++ gcc/config/xtensa/xtensa.md | 20 +++- 2 files changed, 9 insertions(+), 13 deletions(-) diff --git a/gcc/config/xtensa/xtensa.cc b/gcc/config/xtensa/xtensa.cc index

Re: [PATCH 1/2] xtensa: Fix non-fatal regression introduced by b2ef02e8cbbaf95fee98be255f697f47193960ec

On Wed, Feb 22, 2023 at 7:42 PM Takayuki 'January June' Suwa wrote: > > In commit b2ef02e8cbbaf95fee98be255f697f47193960ec, the sibling call > insn included (use (reg:SI A0_REG)) to fix the problem, which added > a USE chain unconditionally to the data flow of register A0 during > the sibling

Re: [PATCH 2/2] xtensa: Fix missing mode warnings in machine description

On Wed, Feb 22, 2023 at 7:42 PM Takayuki 'January June' Suwa wrote: > > gcc/ChangeLog: > > * config/xtensa/xtensa.md > (zero_cost_loop_start, zero_cost_loop_end, loop_end): > Add missing "SI:" to PLUS RTXes. > --- > gcc/config/xtensa/xtensa.md | 12 ++-- > 1 file

[PATCH v2] LoongArch: Change the value of macro TRY_EMPTY_VM_SPACE from 0x8000000000 to 0x1000000000.

The PCH mechanism first tries to map the .gch file to the virtual memory space pointed to by TRY_EMPTY_VM_SPACE during the compilation process. The original value of TRY_EMPTY_VM_SPACE macro is 0x80, but like la464 only has 40 bits of virtual address space, this value just exceeds the

  1   2   >