[PATCH 0/2] Fix two test failures with --enable-default-pie [PR70150]

In GCC 14.1-rc1, there are two new (comparing to GCC 13) failures if the build is configured --enable-default-pie. Let's fix them. Tested on x86_64-linux-gnu. Ok for trunk and releases/gcc-14? Xi Ruoyao (2): i386: testsuite: Add -no-pie for pr113689-1.c [PR70150] i386: testsuite: Adapt

[PATCH 2/2] i386: testsuite: Adapt fentryname3.c for r14-811 change [PR70150]

After r14-811 "call *nop@GOTPCREL(%rip)" is only generated with -mno-direct-extern-access even if --enable-default-pie. So the r13-1614 change to this file is not valid anymore. gcc/testsuite/ChangeLog: PR testsuite/70150 * gcc.target/i386/fentryname3.c (dg-final): Revert

[PATCH 1/2] i386: testsuite: Add -no-pie for pr113689-1.c [PR70150]

For a --enable-default-pie build, using -fno-pic (for compiler) but not -no-pie (for linker) triggers some linker warnings counted as excess errors: /usr/bin/ld: /tmp/cc8MgxiR.o: warning: relocation in read-only section `.text.startup' /usr/bin/ld: warning: creating DT_TEXTREL in a

Re: [PATCH] x86: Fix cmov cost model issue [PR109549]

CC uros. On Mon, May 6, 2024 at 11:03 AM Kong, Lingling wrote: > > Hi, > (if_then_else:SI (eq (reg:CCZ 17 flags) > (const_int 0 [0])) > (reg/v:SI 101 [ e ]) > (reg:SI 102)) > The cost is 8 for the rtx, the cost for > (eq (reg:CCZ 17 flags) (const_int 0 [0])) is 4, but this is

[PATCH] x86: Fix cmov cost model issue [PR109549]

Hi, (if_then_else:SI (eq (reg:CCZ 17 flags) (const_int 0 [0])) (reg/v:SI 101 [ e ]) (reg:SI 102)) The cost is 8 for the rtx, the cost for (eq (reg:CCZ 17 flags) (const_int 0 [0])) is 4, but this is just an operator do not need to compute it's cost in cmov. Bootstrapped and

[NOT CODE REVIEW] [PATCH v3 1/1] [RISC-V] Add support for _Bfloat16

1 At point , BF16 has already been completed "post public review". 2 LLVM has also added support for RISCV BF16 in and . 3 According to the discussion

[NOT CODE REVIEW] [PATCH v3 0/1] [RISC-V] Add support for _Bfloat16

This v3 submission is only for testing whether the code meets the format requirements of CI. The CI testing website is located at: If satisfied, this code will be immediately pushed into

[PATCH v3] aarch64: Fix normal returns inside functions which use eh_returns [PR114843]

The problem here is that on a normal return path, we still restore the eh data return when we should not. Instead of one return path in the case of eh_return, this changes over to use multiple returns pathes just like a normal function. On the normal path (non-eh return), we need to skip restoring

Re: [RFA][RISC-V] Use "uw" forms for constant synthesis

On 5/4/24 6:53 PM, Jeff Law wrote: So another constant synthesis improvement. In this patch we're looking at cases where we'd like to be able to use lui+slli, but can't because of the sign extending nature of lui on TARGET_64BIT.  For example: 0x800110020UL.  The trunk currently

[pushed] wwwdocs: gcc-14/porting_to: Improve markup.

The key change is putting "GCC target" in ... . Pushed. Gerald --- htdocs/gcc-14/porting_to.html | 16 +++- 1 file changed, 7 insertions(+), 9 deletions(-) diff --git a/htdocs/gcc-14/porting_to.html b/htdocs/gcc-14/porting_to.html index 13772080..db27f122 100644 ---

Re: [PATCH] libgfortran: Fix libgfortran.so versioning on Solaris with subdirs

Hi Rainer, > This patch fixes this by allowing for the new structure. > Tested on i386-pc-solaris2.11 and sparc-sun-solaris2.11. > > Ok for trunk? OK to push, given it’s localised inside LIBGFOR_USE_SYMVER_SUN. I find it weird though that .libs is harcoded there. If we look at all the

[PATCH] libgfortran: Fix libgfortran.so versioning on Solaris with subdirs

The move of libgfortran objects to subdirectories completely broke the creation of libgfortran.so on Solaris. Since the gfortran.ver-sun rule doesn't support that structure, no libtool objects are found, thus no symbols exported from libgfortran.so, causing every link to fail. This patch fixes

Re: [PATCH] Fortran: fix issues with class(*) assignment [PR114827]

Hi Paul, Am 05.05.24 um 18:48 schrieb Paul Richard Thomas: Hi Harald, Please do commit, with or without the extra bit for the function result. I've committed the attached variant that excludes the case of a scalar class(*) allocatable function result on the rhs, and added a TODO. As well

[PATCH v5 4/5] Add tests for C/C++ musttail attributes

Mostly adopted from the existing C musttail plugin tests. gcc/testsuite/ChangeLog: * c-c++-common/musttail1.c: New test. * c-c++-common/musttail2.c: New test. * c-c++-common/musttail3.c: New test. * c-c++-common/musttail4.c: New test. *

[PATCH v5 2/5] C++: Support clang compatible [[musttail]] (PR83324)

This patch implements a clang compatible [[musttail]] attribute for returns. musttail is useful as an alternative to computed goto for interpreters. With computed goto the interpreter function usually ends up very big which causes problems with register allocation and other per function

[PATCH v5 5/5] Add documentation for musttail attribute

gcc/ChangeLog: * doc/extend.texi: Document [[musttail]] --- gcc/doc/extend.texi | 22 -- 1 file changed, 20 insertions(+), 2 deletions(-) diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi index e290265d68d3..deb100ad93b6 100644 --- a/gcc/doc/extend.texi +++

[PATCH v5 3/5] C: Implement musttail attribute for returns

Implement a C23 clang compatible musttail attribute similar to the earlier C++ implementation in the C parser. PR83324 gcc/c/ChangeLog: * c-parser.cc (struct attr_state): Define with musttail_p. (c_parser_statement_after_labels): Handle [[musttail]]

[PATCH v5 1/5] Improve must tail in RTL backend

- Give error messages for all causes of non sibling call generation - Don't override choices of other non sibling call checks with must tail. This causes ICEs. The must tail attribute now only overrides flag_optimize_sibling_calls locally. - Error out when tree-tailcall failed to mark a must-tail

[PATCH] testsuite: c++: Skip g++.dg/analyzer on Solaris [PR111475]

Rainer Orth writes: >> On Fri, May 03, 2024 at 09:31:08AM -0400, David Malcolm wrote: >>> Jakub, Richi, Rainer: this is a non-trivial change that cleans up >>> analyzer C++ testsuite results on Solaris, but has a slight risk of >>> affecting analyzer behavior on other targets. As such, I was

Re: [PATCH] Fortran: fix issues with class(*) assignment [PR114827]

Hi Harald, Please do commit, with or without the extra bit for the function result. As well as having to get back to pr113363, I have patches in a complete state for pr84006 and 98534. However they clash with yours. You arrived at the head of the queue first and so after you :-) Regards Paul

Re: [PATCH] Minor range type fixes for IPA in preparation for prange.

PING. I can probably commit this patchlet as a ranger maintainer, but I'd prefer a nod from a global or IPA maintainer. It is the one patch that's needed before I can throw the switch on prange support later this week. Thanks. Aldy On Sun, Apr 28, 2024 at 10:10 PM Aldy Hernandez wrote: > >