Re: [RFC] docs: remove documentation for unsupported releases

On Wed, 9 Nov 2022, Alexander Monakov wrote: > For this I would suggest using the tag to neatly fold links > for old releases. Please see the attached patch. Loving it, Alexander! What do you guys think about unfolding all releases we, the GCC project, currently support (per https://gcc.gnu.org

Re: [RFC PATCH] c++: Minimal handling of carries_dependency attribute

On 11/9/22 02:18, Jakub Jelinek wrote: On Tue, Nov 08, 2022 at 01:40:03PM -1000, Jason Merrill wrote: A comment in D2552R1: "The only questionable (but still conforming) case we found was [[carries_dependency(some_argument)]] on GCC, where the emitted diagnostic said that the carries_dependency

Re: [PATCH] ifcombine: fold two bit tests with different polarity

On Thu, 10 Nov 2022, Philipp Tomsich wrote: > Our ifcombine pass combines 2 single-bit tests into a single test of > the form "(a & T) == T", requiring the same polarity (i.e., tests for > bit set/cleared) for both bit-tests. However some applications test > against two bits expecting one set and

Re: [PATCH] ifcombine: recognize single bit test of sign-bit

On Thu, 10 Nov 2022, Philipp Tomsich wrote: > Our ifcombine pass combines 2 single-bit tests into a single test of > the form "(a & T) == T". > > However, detection of the bit-tests does not work for sign-bits (of > any mode) as the RTL presented to the pass uses a cast to a > signed-type and an

Re: [PATCH v2 2/4] LoongArch: Add ftint{,rm,rp}.{w,l}.{s,d} instructions

在 2022/11/9 下午9:53, Xi Ruoyao 写道: +;; Convert floating-point numbers to integers +(define_insn "2" + [(set (match_operand:ANYFI 0 "register_operand" "=f") + (unspec:ANYFI [(match_operand:ANYF 1 "register_operand" "f")] + LRINT))] + "TARGET_HARD_FLOAT && + ( +||

[wwwdocs] gcc-13: Mention Intel new ISA and march support.

Hi all, This patch aims to mention newly added Intel ISA and march support. Ok for trunk? BRs, Haochen --- htdocs/gcc-13/changes.html | 50 ++ 1 file changed, 50 insertions(+) diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html index bd11cb

[PATCH (pushed)] maintainer-scripts: fix superfluous 'sh' for Python script

Hi. I noticed: https://gcc.gnu.org/pipermail/gccadmin/2022q4/019260.html /home/gccadmin/venv/bin/python3: /home/gccadmin/venv/bin/python3: cannot execute binary file It will be fixed with the following patch. @Jakub: Please update the cron. Thanks, Martin maintainer-scripts/ChangeLog:

[PATCH (pushed)] doc: Modernize baseconf.py.

Pushed. ChangeLog: * doc/baseconf.py: Modernize by using pathlib. --- doc/baseconf.py | 34 ++ 1 file changed, 18 insertions(+), 16 deletions(-) diff --git a/doc/baseconf.py b/doc/baseconf.py index d85659e4540..8021a101e77 100644 --- a/doc/baseconf.py +++

Re: [PATCH] doc: Use a separate directory for new modules we add to PATH

On 11/9/22 22:31, Arsen Arsenović wrote: > ChangeLog: > > * doc/baseconf.py: Inject dirname(__file__)/'modules' to path > instead of just ``.''. > * doc/gcc_sphinx.py: Moved to... > * doc/modules/gcc_sphinx.py: ...here. > --- > Evening, > > This patch addresses a path mixu

Re: [PATCH] rtl: Try to remove EH edges after {pro,epi}logue generation [PR90259]

on 2022/11/9 15:56, Eric Botcazou wrote: >> The previous testings on powerpc64{,le}-linux-gnu covered language Go, but >> not Ada. I re-tested it with languages c,c++,fortran,objc,obj-c++,go,ada >> on powerpc64le-linux-gnu, the result looked good. Both x86 and aarch64 >> cfarm machines which I us

[PATCH] c-family: Support #pragma region/endregion [PR85487]

Something similar has been proposed before, but didn't get approval. Jeff wanted a more general framework for ignoring pragmas. It might make sense to do that, and reuse it for the Darwin-specific 'mark' pragmas. But as I said in the PR, I looked at the darwin ones and they are unique among all pra

Re: [PATCH, GCC/testsuite] Fix dump-noaddr dumpbase

On Tue, Dec 5, 2017 at 9:50 AM Thomas Preudhomme wrote: > > Hi, > > dump-noaddr test FAILS when $tmpdir is not the same as the directory > where runtest is called from. Note that this does not happen when > running make check because tmpdir is set to srcdir. > > In that case, file mkdir will creat

[PATCH 6/6] PowerPC: Add support for 1,024 bit DMR registers.

This patch is a prelimianry patch to add the full 1,024 bit dense math register (DMRs) for -mcpu=future. The MMA 512-bit accumulators map onto the top of the DMR register. This patch only adds the new 1,024 bit register support. It does not add support for any instructions that need 1,024 bit re

[PATCH 5/6] PowerPC: Switch to dense math names for all MMA operations.

This patch changes the assembler instruction names for MMA instructions from the original name used in power10 to the new name when used with the dense math system. I.e. xvf64gerpp becomes dmxvf64gerpp. The assembler will emit the same bits for either spelling. The patches have been tested on th

[PATCH 4/6] PowerPC: Make MMA insns support DMR registers

This patch changes the MMA instructions to use either FPR registers (-mcpu=power10) or DMRs (-mcpu=future). In this patch, the existing MMA instruction names are used. A macro (__PPC_DMR__) is defined if the MMA instructions use the DMRs. The patches have been tested on the following platforms.

[PATCH 3/6] PowerPC: Add support for accumulators in DMR registers.

The MMA system added the notion of accumulator registers. In power10, these accumulators overlapped with the FPR registers, but logically the accumulators were separate from the FPR registers. It is anticipated that in future systems, we may have a separate dense math unit and the accumulators wi

[PATCH 2/6] PowerPC: Make -mcpu=future enable -mblock-ops-vector-pair.

This patch enables generating load and store vector pair instructions when doing certain memory copy operations when -mcpu=future is used. In doing tests on power10, it was determined that using these instructions were problematical in a few cases, so we disabled generating them by default. This

[PATCH 1/6] PowerPC: Add -mcpu=future

This patch adds support for the -mcpu=future and -mtune=future options. Besides defining __ARCH_PWR_FUTURE__ this particular patch does not enable any new features. These patches implement support for potential future PowerPC cpus. At this time, features enabled with -mcpu=future may or may not b

[PATCH 0/6] PowerPC Dense Math prelimary support (-mcpu=future)

This patch is very preliminary support for a potential new feature to the PowerPC that extends the current power10 MMA architecture. This feature may or may not be present in any specific future PowerPC processor. In the current MMA subsystem for Power10, there are 8 512-bit accumulator registers

Re: [PATCH] Optimize VEC_PERM_EXPR with same permutation index and operation [PR98167]

Hi Prathamesh and Richard, Thanks for the review and nice suggestions! > > I guess the transform should work as long as mask is same for both > > vectors even if it's > > not constant ? > > Yes, please change accordingly (and maybe push separately). > Removed VECTOR_CST for integer ops. > > If

[committed] libstdc++: Optimize std::destructible concept

Tested x86_64-linux. Pushed to trunk. -- >8 -- This uses variable templates and constraints to define a much simpler std::destructible concept. This avoids instantiating the trait std::is_nothrow_destructible and all its implementation in terms of __is_destructible_safe and __is_destructible_impl

[PATCH] c++: Extend -Wdangling-reference for std::minmax

This patch extends -Wdangling-reference to also warn for auto v = std::minmax(1, 2); which dangles because this overload of std::minmax returns a std::pair where the two references are bound to the temporaries created for the arguments of std::minmax. This is a common footgun, also described at

Re: [PATCH] RISC-V: costs: support shift-and-add in strength-reduction

On Tue, 08 Nov 2022 11:54:34 PST (-0800), philipp.toms...@vrull.eu wrote: The strength-reduction implementation in expmed.c will assess the profitability of using shift-and-add using a RTL expression that wraps a MULT (with a power-of-2) in a PLUS. Unless the RISC-V rtx_costs function recognizes

Re: [PATCH] RISC-V: Implement movmisalign to enable SLP

I am not sure if I am missing something, your testcase should rely on movmisalignhi pattern, but you defined movmisalign with ANYF mode iterator rather than movmisalign with HI, SI, DI? And seems the testcase compile with `-march=rv64gc -mabi=lp64 -mtune=size -O2` w/o this patch already generated

Re: [PATCH] Remove SLOW_SHORT_ACCESS from target headers

On Wed, Nov 9, 2022 at 5:16 PM apinski--- via Gcc-patches wrote: > > From: Andrew Pinski > > SLOW_SHORT_ACCESS is defined in bfin and i386 target > headers but the target macro is not used elsewhere. > So let's remove it from those two headers and poison it. Just to add, this target macro was de

[PATCH] Remove SLOW_SHORT_ACCESS from target headers

From: Andrew Pinski SLOW_SHORT_ACCESS is defined in bfin and i386 target headers but the target macro is not used elsewhere. So let's remove it from those two headers and posion it. OK? Built x86_64-linux-gnu and bfin-elf. gcc/ChangeLog: * config/bfin/bfin.h (SLOW_SHORT_ACCESS): Delete

Re: [PATCH] RISC-V: Fix selection of pipeline model for sifive-7-series

LGTM, thank you for catching that!! On Wed, Nov 9, 2022 at 3:50 PM Philipp Tomsich wrote: > > A few of the gcc.target/riscv/mcpu-*.c tests have been failing for a > while now, due to the pipeline model for sifive-7-series not being > selected despite -mtune=sifive-7-series. The root cause is tha

Re: [RFC][PATCH] Remove SLOW_BYTE_ACCESS

On Fri, Nov 17, 2017 at 11:08 AM Wilco Dijkstra wrote: > > Remove SLOW_BYTE_ACCESS given it's confusing, badly named, > badly documented and used incorrectly. Although most targets > define it as 1, there are several targets which confuse it > (based on comments next to it) and set it to 0 since

Go patch committed: Define __atomic_fetch_add functions

This patch to the GCC-specific part of the Go frontend defines the __atomic_fetch_add functions. The frontend only generates calls to the __atomic_add_fetch functions, but in some cases the middle-end can transform the latter into the former. This patch is originally by Marc Poulhiès. This fixes

[PATCH] RISC-V: Fix selection of pipeline model for sifive-7-series

A few of the gcc.target/riscv/mcpu-*.c tests have been failing for a while now, due to the pipeline model for sifive-7-series not being selected despite -mtune=sifive-7-series. The root cause is that the respective RISCV_TUNE entry points to generic instead. Fix this. Fixes 97d1ed67fc6 ("RISC-V:

[PATCH v3] RISC-V: Replace zero_extendsidi2_shifted with generalized split

The current method of treating shifts of extended values on RISC-V frequently causes sequences of 3 shifts, despite the presence of the 'zero_extendsidi2_shifted' pattern. Consider: unsigned long f(unsigned int a, unsigned long b) { a = a << 1; unsigned long c = (un

[PATCH v2] [WIP] RISC-V: Replace zero_extendsidi2_shifted with generalized split

The current method of treating shifts of extended values on RISC-V frequently causes sequences of 3 shifts, despite the presence of the 'zero_extendsidi2_shifted' pattern. Consider: unsigned long f(unsigned int a, unsigned long b) { a = a << 1; unsigned long c = (un

[PATCH] ifcombine: fold two bit tests with different polarity

Our ifcombine pass combines 2 single-bit tests into a single test of the form "(a & T) == T", requiring the same polarity (i.e., tests for bit set/cleared) for both bit-tests. However some applications test against two bits expecting one set and the other cleared. This adds support for the case "

[PATCH] ifcombine: recognize single bit test of sign-bit

Our ifcombine pass combines 2 single-bit tests into a single test of the form "(a & T) == T". However, detection of the bit-tests does not work for sign-bits (of any mode) as the RTL presented to the pass uses a cast to a signed-type and an order-operator. E.g., the test for 'a & 0x80' presents a

[PATCH] RISC-V: Implement movmisalign to enable SLP

The default implementation of support_vector_misalignment() checks whether movmisalign is present for the requested mode. This will be used by vect_supportable_dr_alignment() to determine whether a misaligned access of vectorized data is permissible. For RISC-V this is required to convert multipl

[PATCH] RISC-V: Optimise adding a (larger than simm12) constant

Handling the register-const_int addition has very quickly escalated to creating a full sign-extended 32bit constant and performing a register-register for RISC-V in GCC so far, resulting in sequences like (for the case of "a + 2048"): li a5,4096 addia5,a5,-2048 add

[committed] analyzer: better logging of event creation

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. Pushed to trunk as r13-3867-g965ce1ba392ca0. gcc/analyzer/ChangeLog: * checker-path.cc (checker_event::debug): New. (checker_path::add_event): Move here from checker-path.h. Add logging. * checker-path.

Re: [PATCH] doc: Use a separate directory for new modules we add to PATH

On Wed, 2022-11-09 at 22:31 +0100, Arsen Arsenović via Gcc-patches wrote: > ChangeLog: > > * doc/baseconf.py: Inject dirname(__file__)/'modules' to path > instead of just ``.''. > * doc/gcc_sphinx.py: Moved to... > * doc/modules/gcc_sphinx.py: ...here. > --- > Eveni

Re: [DOCS] sphinx: use new Sphinx links

On Wed, 9 Nov 2022, Martin Liška wrote: > Gerald, can you please propagate changes I made to: > htdocs/style.mhtml file? Done. All pages live on gcc.gnu.org should be udpated now. (I'm at a conference and have been offline during daytime this week so far. If you want to run further changes, Frid

[PATCH v2] doc: Remove outdated reference to "core" and front-end downloads

Patch rebased on the new doc format. I haven't tested building the docs this way, but this is just plain text here. OK for trunk? -- >8 -- gcc/ChangeLog: * doc/install/testing.rst: Remove anachronism about separate source tarballs. --- gcc/doc/install/testing.rst | 4 +--- 1 fi

[PATCH] doc: Use a separate directory for new modules we add to PATH

ChangeLog: * doc/baseconf.py: Inject dirname(__file__)/'modules' to path instead of just ``.''. * doc/gcc_sphinx.py: Moved to... * doc/modules/gcc_sphinx.py: ...here. --- Evening, This patch addresses a path mixup and provides a nice compromise between convenience

Re: [PATCH] match.pd: rewrite select to branchless expression

Richard, Thanks for your feedback. I want to make sure I am following what you are recommending. Are you suggesting changing: (for op (bit_xor bit_ior) (simplify (cond (eq (bit_and @0 integer_onep@1) integer_zerop) @2 (op:c @3 @2)) (if (INTEGRAL_TYPE_P (type) && (INTEGRAL_TYPE_P (TREE_TYPE (@0

Re: [PATCH] Fix doc typo

On 11/9/22 08:51, Richard Biener via Gcc-patches wrote: > On Wed, Nov 9, 2022 at 4:29 AM Sinan via Gcc-patches > wrote: >> >> add a missing variable name. > > OK. I've just pushed the change. Martin

Re: [committed] wwwdocs: codingconventions: Properly link to flake8

On 11/1/22 13:01, Gerald Pfeifer wrote: > Nearly all hrefs= on our site are https:// or http://, and that's the case > pretty much across the web. Still the protocol needs to be provided for > links to work. Makes sense, thanks! Martin > > Pushed. > > Gerald > > > Web links need to be pref

[PATCH] c++: P2448 - Relaxing some constexpr restrictions [PR106649]

This patch implements C++23 P2448, which lifts more restrictions on the constexpr keyword. It's effectively going the way of being just a hint (hello, inline!). This gist is relatively simple: in C++23, a constexpr function's return type/parameter type doesn't have to be a literal type; and you c

Proxy ping [PATCH] Fortran: diagnostics for actual arguments to pointer dummy arguments [PR94104]

Dear all, Jose posted a patch here that was never reviewed: https://gcc.gnu.org/pipermail/fortran/2021-June/056162.html I think the diagnostics improvement is helpful, as it adjusts to the changes from F2003 to F2008. The patch suffered a little from bitrot, but was otherwise straightforward

[PATCH, committed] Fortran: avoid NULL pointer dereference on bad EQUIVALENCEs [PR107559]

Dear all, I've committed an obvious patch for NULL pointer dereferences that could occur when checking EQUIVALENCEs. See also attached. Testcase by Gerhard. Regtested on x86_64-pc-linux-gnu. Pushed: https://gcc.gnu.org/g:e505f7493bed1395d121d2f53137ec11706fa42e Thanks, Harald From e505f7493b

[Ping 2][PATCH] Add condition coverage profiling

On 02/11/2022 07:16, Jørgen Kvalsvik wrote: > On 25/10/2022 08:33, Jørgen Kvalsvik wrote: >> On 12/10/2022 12:16, Jørgen Kvalsvik wrote: >>> 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

[PATCH (pushed)] docs: Fix expected diagnostics URL [PR107599]

PR c++/107599 gcc/testsuite/ChangeLog: * c-c++-common/diagnostic-format-json-2.c: Fix expected URL. * c-c++-common/diagnostic-format-json-3.c: Likewise. * c-c++-common/diagnostic-format-json-4.c: Likewise. * gfortran.dg/diagnostic-format-json-2.F90: Likewis

Re: [RFC] docs: remove documentation for unsupported releases

On 11/9/22 20:32, Alexander Monakov wrote: > > On Wed, 9 Nov 2022, Martin Liška wrote: > >> Hi. >> >> I think we should remove documentation for unsupported GCC releases >> as it's indexed by Google engine. > > I'd agree with previous responses that outright removing the links is > undesirable,

[PATCH (pushed)] sphinx: add missing HAS_SPHINX_BUILD

libgomp/ChangeLog: * Makefile.in: Add missing HAS_SPHINX_BUILD. libitm/ChangeLog: * Makefile.in: Add missing HAS_SPHINX_BUILD. libquadmath/ChangeLog: * Makefile.in: Add missing HAS_SPHINX_BUILD. --- libgomp/Makefile.in | 1 + libitm/Makefile.in | 1 + libquadm

Re: [RFC] docs: remove documentation for unsupported releases

On Wed, 9 Nov 2022, Martin Liška wrote: > Hi. > > I think we should remove documentation for unsupported GCC releases > as it's indexed by Google engine. I'd agree with previous responses that outright removing the links is undesirable, and pointing Google to recent documentation should be done

[PATCH 0/2] Fortran: add attribute target_clones

Hi! These two patches add support for attribute target_clones to the fortran frontend. 1) The symtab hunk is identical to the one sent in https://gcc.gnu.org/pipermail/gcc-patches/2022-November/605081.html which had some additional information. I only tested it on x86_64-unknown-linux and for lan

[PATCH 2/2] Fortran: add attribute target_clones

Hi! Add support for attribute target_clones: !GCC$ ATTRIBUTES target_clones("arch1", "arch3","default") :: mysubroutine Bootstrapped and regtested on x86_64-unknown-linux with --target_board=unix'{-m32,-m64}'. OK for trunk? gcc/fortran/ChangeLog: * decl.cc: Include fold-const.h for size

[PATCH 1/2] symtab: also change RTL decl name

We were changing the ASSEMBLER_NAME of the function decl but not the name in DECL_RTL which is used as the function name fnname in rest_of_handle_final(). This led to using the old, wrong name for the attribute target default function when using target_clones. Bootstrapped and regtested cleanly on

Re: [RFC] docs: remove documentation for unsupported releases

On Wed, 9 Nov 2022, Michael Matz via Gcc-patches wrote: > I think everything that's on the web server (even the 2.95 docu) has to be > reachable via a (reasonable) set of clicks from the main index.html. It > doesn't need to be _directly_ from the main index.html, though. > > Also, you simply

Re: [Patch Arm] Fix PR 92999

Hi Ramana, On 08/11/2022 18:20, Ramana Radhakrishnan via Gcc-patches wrote: > PR92999 is a case where the VFP calling convention does not allocate > enough FP registers for a homogenous aggregate containing FP16 values. > I believe this is the complete fix but would appreciate another set of > eye

[PATCH (pushed)] Include docs-sources in onlinedocs.

--- htdocs/onlinedocs/index.html | 1 + 1 file changed, 1 insertion(+) diff --git a/htdocs/onlinedocs/index.html b/htdocs/onlinedocs/index.html index cfa8bf5a..3410f731 100644 --- a/htdocs/onlinedocs/index.html +++ b/htdocs/onlinedocs/index.html @@ -1610,6 +1610,7 @@ existing release. (htt

[PATCH (pushed)] docs: create sources tarball

maintainer-scripts/ChangeLog: * update_web_docs_git.py: Create sources tarball. --- maintainer-scripts/update_web_docs_git.py | 29 +++ 1 file changed, 29 insertions(+) diff --git a/maintainer-scripts/update_web_docs_git.py b/maintainer-scripts/update_web_docs_git.py

Re: [PATCH V2] Enable small loop unrolling for O2

> This patch does not change rs6000/s390 since I don't have machines to > test them, but I suppose the default behavior is the same since they > enable flag_unroll_loops at O2. There are Power (rs6000) systems in the Compile Farm. Trial Linux on Z (s390x) VMs are available through the Linux Commu

[COMMITTED] Clear NAN when reading back a global range if necessary.

When reading back from the global store, we must clear the NAN bit if necessary. The reason it's not happening is because the constructor sets a NAN by default (when HONOR_NANS). We must be careful to clear the NAN bit if the original range didn't have a NAN. I have commented the reason we use t

Re: [PATCH] riscv: implement TARGET_MODE_REP_EXTENDED

On Wed, 9 Nov 2022, Philipp Tomsich wrote: > > To give a specific example that will be problematic if you go far enough > > down > > the road of matching MIPS64 behavior: > > > > long f(void) > > { > > int x; > > asm("" : "=r"(x)); > > return x; > > } > > > > here GCC (unlike LLVM) om

Re: Announcement: Porting the Docs to Sphinx - tomorrow

On Wed, Nov 9, 2022 at 6:11 PM Joseph Myers wrote: > > On Wed, 9 Nov 2022, Richard Biener via Gcc wrote: > > > I'd say that doing a trunk snapshot build every day as CI would be nice, we > > can then publish one once a week, skipping days where the build failed. > > Note that each snapshot should

Re: Announcement: Porting the Docs to Sphinx - 9. November 2022

On Wed, 9 Nov 2022, Martin Liška wrote: > 1) not synchronized content among lib*/Makefile.in and lib*/Makefile.am. > Apparently, I modified the generated Makefile.in file with the rules like: > > doc/info/texinfo/libitm.info: $(SPHINX_FILES) > + if [ x$(HAS_SPHINX_BUILD) = xhas-sphinx-build

Re: Announcement: Porting the Docs to Sphinx - tomorrow

On Wed, 9 Nov 2022, Richard Biener via Gcc wrote: > I'd say that doing a trunk snapshot build every day as CI would be nice, we > can then publish one once a week, skipping days where the build failed. Note that each snapshot should have diffs relative to the previous published snapshot. Not re

Re: [PATCH 1/2] Change the name of array_at_struct_end_p to array_ref_flexible_size_p

Thanks. Committed as: https://gcc.gnu.org/pipermail/gcc-cvs/2022-November/373830.html Qing > On Nov 9, 2022, at 2:57 AM, Richard Biener wrote: > > On Tue, 8 Nov 2022, Qing Zhao wrote: > >> The name of the utility routine "array_at_struct_end_p" is misleading >> and should be changed to a new

RE: [PATCH 2/4]AArch64 Add implementation for pow2 bitmask division.

Hi Tamar, > -Original Message- > From: Tamar Christina > Sent: Monday, October 31, 2022 11:35 AM > To: Tamar Christina ; gcc-patches@gcc.gnu.org > Cc: nd ; Richard Earnshaw ; > Marcus Shawcroft ; Kyrylo Tkachov > ; Richard Sandiford > > Subject: RE: [PATCH 2/4]AArch64 Add implementation

Re: [COMMITTED] Implement op[12]_range operators for PLUS_EXPR and MINUS_EXPR.

On Wed, Nov 09, 2022 at 04:43:56PM +0100, Aldy Hernandez wrote: > Heh. I just ran into this while debugging the problem reported by Xi. > > We are solving NAN = op1 - VARYING, and trying to do it with op1 = NAN > + VARYING, which returns op1 = NAN (incorrectly). > > I suppose in the above case o

Re: [COMMITTED] [range-op-float] Implement MINUS_EXPR.

I have reverted the patch while I sort this out. Thanks for the report and especially for the distilled test. It's very useful. Aldy On Wed, Nov 9, 2022 at 2:58 PM Xi Ruoyao wrote: > > On Wed, 2022-11-09 at 21:49 +0800, Xi Ruoyao wrote: > > Hi Aldy, > > > > This commit breaks the attached test

Re: [COMMITTED] Implement op[12]_range operators for PLUS_EXPR and MINUS_EXPR.

On Wed, Nov 9, 2022 at 3:58 PM Jakub Jelinek wrote: > > On Wed, Nov 09, 2022 at 10:02:46AM +0100, Aldy Hernandez wrote: > > We can implement the op[12]_range entries for plus and minus in terms > > of each other. These are adapted from the integer versions. > > I think for NANs the op[12]_range s

[wwwdocs] Add httpd redirects for texinfo trunk docs and for each release series

I've tested that the redirects work on my own httpd server, and have verified that no new sphinx-generated docs match these patterns, and no old texinfo docs fail to match them (except for cases like index.html where a new file exists with the same name anyway so we don't need a redirect). For exa

Re: [COMMITTED] Implement op[12]_range operators for PLUS_EXPR and MINUS_EXPR.

On Wed, Nov 09, 2022 at 10:02:46AM +0100, Aldy Hernandez wrote: > We can implement the op[12]_range entries for plus and minus in terms > of each other. These are adapted from the integer versions. I think for NANs the op[12]_range shouldn't act this way. For the forward binary operations, we hav

Re: Announcement: Porting the Docs to Sphinx - 9. November 2022

On 10/20/22 18:43, Joseph Myers wrote: > On Thu, 20 Oct 2022, Martin Liška wrote: > >>> Also, but not strictly part of the release issue: >>> >>> (d) Builds with missing or old Sphinx should work regardless of whether >>> such files are in the source directory - but if they aren't in the source

[PATCH (pushed)] docs: fix links pointing to gcc.gnu.org/install

Use https://gcc.gnu.org/onlinedocs/install/ instead. ChangeLog: * configure.ac: Use new install URL. * configure: Regenerate. gcc/ChangeLog: * Makefile.in: Use new install URL. * doc/gcc/gcc-command-options/machine-dependent-options/avr-options.rst: Use i

[GCC][PATCH 13/15, v4] arm: Add support for dwarf debug directives and pseudo hard-register for PAC feature.

Hello, This patch teaches the DWARF support in gcc about RA_AUTH_CODE pseudo hard-register and also updates the ".save", ".cfi_register", ".cfi_offset", ".cfi_restore" directives accordingly. This patch also adds support to emit ".pacspval" directive when "pac ip, lr, sp" instruction in genera

Re: [COMMITTED] [range-op-float] Abstract out binary operator code out of PLUS_EXPR entry.

On Wed, Nov 09, 2022 at 02:32:55PM +0100, Jakub Jelinek wrote: > On Wed, Nov 09, 2022 at 02:14:19PM +0100, Aldy Hernandez wrote: > > On Wed, Nov 9, 2022 at 1:48 PM Jakub Jelinek wrote: > > > > > > On Wed, Nov 09, 2022 at 08:07:57AM +0100, Aldy Hernandez wrote: > > > > The PLUS_EXPR was always mean

Re: [RFC] docs: remove documentation for unsupported releases

Hello, On Wed, 9 Nov 2022, Martin Liška wrote: > I think we should remove documentation for unsupported GCC releases > as it's indexed by Google engine. Second reason is that the page is long > one one can't easily jump to Current development documentation. > > Thoughts? I think everything that

Re: [RFC] docs: remove documentation for unsupported releases

On Wed, Nov 09, 2022 at 02:54:48PM +0100, Martin Liška wrote: > I think we should remove documentation for unsupported GCC releases > as it's indexed by Google engine. Second reason is that the page is long > one one can't easily jump to Current development documentation. > > Thoughts? I'd prefer

Re: [COMMITTED] [range-op-float] Implement MINUS_EXPR.

On Wed, 2022-11-09 at 21:49 +0800, Xi Ruoyao wrote: > Hi Aldy, > > This commit breaks the attached test case at -O2 on x86_64-linux-gnu and ^^^ Ah, not this one. I meant r13-3842 "Implement op[12]_range operators for PLUS_EXPR and MINUS_EXPR." > loongarch64-linux-gnu :(. > > The code

[RFC] docs: remove documentation for unsupported releases

Hi. I think we should remove documentation for unsupported GCC releases as it's indexed by Google engine. Second reason is that the page is long one one can't easily jump to Current development documentation. Thoughts? Martin --- htdocs/onlinedocs/index.html | 1294 -

[PATCH v2 4/4] LoongArch: Add flogb.{s, d} instructions and expand logb{sf, df}2

On LoongArch, flogb instructions extract the exponent of a non-negative floating point value, but produces NaN for negative values. So we need to add a fabs instruction when we expand logb. gcc/ChangeLog: * config/loongarch/loongarch.md (UNSPEC_FLOGB): New unspec. (type): Add flo

Re: [PATCH Rust front-end v3 38/46] gccrs: Add HIR to GCC GENERIC lowering entry point

On Wed, Oct 26, 2022 at 10:37 AM wrote: > > From: Philip Herron > > This patch contains the entry point and utilities used for the lowering > of HIR nodes to `tree`s. It also contains a constant evaluator, ported > over from the C++ frontend. > > Co-authored-by: David Faust > Co-authored-by: Fai

[PATCH v2 2/4] LoongArch: Add ftint{,rm,rp}.{w,l}.{s,d} instructions

This allows to optimize the following builtins if -fno-math-errno: - __builtin_lrint{,f} - __builtin_lfloor{,f} - __builtin_lceil{,f} Inspired by https://gcc.gnu.org/pipermail/gcc-patches/2022-November/605287.html. ANYFI is added so the compiler won't try ftint.l.s if -mfpu=32. If we simply use

[PATCH v2 3/4] LoongArch: Add fscaleb.{s, d} instructions as ldexp{sf, df}3

This allows optimizing __builtin_ldexp{,f} and __builtin_scalbn{,f} with -fno-math-errno. IMODE is added because we can't hard code SI for operand 2: fscaleb.d instruction always take the high half of both source registers into account. See my_ldexp_long in the test case. gcc/ChangeLog:

[PATCH v2 1/4] LoongArch: Rename frint_ to rint2

Use standard name so __builtin_rint{,f} can be expanded to one instruction. gcc/ChangeLog: * config/loongarch/loongarch.md (frint_): Rename to .. (rint2): .. this. gcc/testsuite/ChangeLog: * gcc.target/loongarch/frint.c: New test. --- gcc/config/loongarch/loongarch.md

[PATCH v2 0/4] LoongArch: Add some floating-point operations

These patches allow to expand the following builtins to floating point instructions for LoongArch: - __builtin_rint{,f} - __builtin_{l,ll}rint{,f} - __builtin_{l,ll}floor{,f} - __builtin_{l,ll}ceil{,f} - __builtin_scalb{n,ln}{,f} - __builtin_logb{,f} Bootstrapped and regtested on loongarch64-linu

[PATCH] tree-optimization/84646 - remove premature thread path rejection

This removes a premature rejection that's done later in a different way. Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed. PR tree-optimization/84646 * tree-ssa-threadbackward.cc (back_threader::maybe_register_path): Remove premature cycle rejection. --- gcc/tr

Re: [COMMITTED] [range-op-float] Implement MINUS_EXPR.

Hi Aldy, This commit breaks the attached test case at -O2 on x86_64-linux-gnu and loongarch64-linux-gnu :(. The code is simplified from Glibc: the breakage causes two Glibc test failures on loongarch64-linux-gnu. Reverting the commit can fix the breakage. On Wed, 2022-11-09 at 08:07 +0100, Aldy

Re: [DOCS] sphinx: use new Sphinx links

On 11/9/22 12:22, Martin Liška wrote: > Gerald, can you please propagate changes I made to: > htdocs/style.mhtml file? Gerald I would like to ask you for further server actions related to the Sphinx documentation: 1) https://gcc.gnu.org/install/ - for the future we will use https://gcc.gnu.org/on

[PATCH] changelog: check for space after tab

Will install if there are not comments. Martin contrib/ChangeLog: * gcc-changelog/git_commit.py: Check for a space after leading tab. * gcc-changelog/test_email.py: Likewise. * gcc-changelog/test_patches.txt: Likewise. --- contrib/gcc-changelog/git_commit.py|

Re: [COMMITTED] [range-op-float] Abstract out binary operator code out of PLUS_EXPR entry.

On Wed, Nov 09, 2022 at 02:14:19PM +0100, Aldy Hernandez wrote: > On Wed, Nov 9, 2022 at 1:48 PM Jakub Jelinek wrote: > > > > On Wed, Nov 09, 2022 at 08:07:57AM +0100, Aldy Hernandez wrote: > > > The PLUS_EXPR was always meant to be a template for further > > > development, since most of the binar

Re: [PATCH (pushed)] sphinx: update diagnostics URLs

On Wed, Nov 9, 2022 at 2:07 PM Martin Liška wrote: > > On 11/9/22 14:00, Richard Biener wrote: > > Do we need a redirect at the old location? > > Well, what's not working are older gcc releases that still point to "master" > branch > documentation: > > gcc --version > gcc (SUSE Linux) 12.2.1 2022

Re: [COMMITTED] [range-op-float] Abstract out binary operator code out of PLUS_EXPR entry.

On Wed, Nov 9, 2022 at 1:48 PM Jakub Jelinek wrote: > > On Wed, Nov 09, 2022 at 08:07:57AM +0100, Aldy Hernandez wrote: > > The PLUS_EXPR was always meant to be a template for further > > development, since most of the binary operators will share a similar > > structure. This patch abstracts out

Re: [PATCH (pushed)] sphinx: update diagnostics URLs

On 11/9/22 14:00, Richard Biener wrote: > Do we need a redirect at the old location? Well, what's not working are older gcc releases that still point to "master" branch documentation: gcc --version gcc (SUSE Linux) 12.2.1 20221020 [revision 0aaef83351473e8f4eb774f8f999bbe87a4866d7] ... https://

RE: [PATCH] RISC-V: cost model for loading 64bit constant in rv32

>> comparison with clang: >> https://godbolt.org/z/v5nxTbKe9 > > IIUC the rules are generally no compiler explorer links (so we can > preserve history) and no attachment patches (ie, inline them like > git-send-email does). There's some documenation on sending pat

Re: [PATCH (pushed)] sphinx: update diagnostics URLs

On Wed, Nov 9, 2022 at 1:12 PM Martin Liška wrote: > > For the future, we'll use https://pypi.org/project/sphinx-redirect-by-id/ > which will allow links like > > https://gcc.gnu.org/onlinedocs/gcc/redirect.html?q=cmdoption-Wfoo > > but for now, let's use the proper landing pages. Do we need a re

Re: [RFC] propgation leap over memory copy for struct

On Wed, 9 Nov 2022, Jiufu Guo wrote: > Hi, > > Richard Biener writes: > > > On Mon, Oct 31, 2022 at 11:14 PM Jeff Law via Gcc-patches > > wrote: > >> > >> > >> On 10/30/22 20:42, Jiufu Guo via Gcc-patches wrote: > >> > Hi, > >> > > >> > We know that for struct variable assignment, memory copy

Re: [COMMITTED] [range-op-float] Abstract out binary operator code out of PLUS_EXPR entry.

On Wed, Nov 09, 2022 at 08:07:57AM +0100, Aldy Hernandez wrote: > The PLUS_EXPR was always meant to be a template for further > development, since most of the binary operators will share a similar > structure. This patch abstracts out the common bits into the default > definition for range_operato

[PATCH (pushed)] docs: fix: WARNING: Parsing of expression failed. Using fallback parser.

For the future, we can use https://sphinx-fortran.readthedocs.io/ for Fortran functions which can have optional arguments. However, it's an additional dependency. Simplify the function declration. gcc/fortran/ChangeLog: * doc/gfortran/intrinsic-procedures/aint.rst: Simplify function

[PATCH] AArch64: Add fma_reassoc_width [PR107413]

Add a reassocation width for FMAs in per-CPU tuning structures. Keep the existing setting for cores with 2 FMA pipes, and use 4 for cores with 4 FMA pipes. This improves SPECFP2017 on Neoverse V1 by ~1.5%. Passes regress/bootstrap, OK for commit? gcc/ PR 107413 * config/aarch64/a

  1   2   >