[PATCH htdocs] bugs: mention ASAN too

Request that reporters try `-fsanitize=address,undefined` rather than just `-fsanitize=undefined` when reporting bugs. We get invalid bug reports which ASAN would've caught sometimes, even if it's less often than where UBSAN would help. --- OK? htdocs/bugs/index.html | 2 +- 1 file changed, 1 ins

[PATCH] doc: mention STAGE1_CFLAGS

STAGE1_CFLAGS can be used to accelerate the just-built stage1 compiler which especially improves its performance on some of the large generated files during bootstrap. It defaults to nothing (i.e. -O0). The downside is that if the native compiler is buggy, there's a greater risk of a failed bootst

Re: [PATCH 1/2] c++: add -Wdeprecated-literal-operator [CWG2521]

On Thu, Oct 3, 2024 at 9:42 AM Jason Merrill wrote: > > Tested x86_64-pc-linux-gnu, applying to trunk. > > -- 8< -- > > C++23 CWG issue 2521 (https://wg21.link/cwg2521) deprecates user-defined > literal operators declared with the optional space between "" and the > suffix. > > Many testcases used

[WIP][PATCH] c++: Fix ABI for lambdas declared in alias templates [PR116568]

FWIW, here's my WIP patch to fix the lambda in type alias case "properly". I've gotten stuck with trying to work out how to set LAMBDA_EXPR_EXTRA_CONTEXT on the uninstantiated declaration; any thoughts or suggestions here? I also found that the hunk - /* Substituting the type might ha

[gcc-wwwdocs PATCH] gcc-15: Mention new ISA and Diamond Rapids support for x86_64 backend

Hi all, This patch will add recent new ISA and arch support for x86_64 backend into gcc-wwwdocs. Ok for gcc-wwwdocs? Thx, Haochen --- htdocs/gcc-15/changes.html | 37 + 1 file changed, 37 insertions(+) diff --git a/htdocs/gcc-15/changes.html b/htdocs/gcc-15

Re: [PATCH v2] xtensa: Fix the issue in "*extzvsi-1bit_addsubx"

On Sat, Nov 9, 2024 at 10:39 PM Takayuki 'January June' Suwa wrote: > > The second source register of insn "*extzvsi-1bit_addsubx" cannot be the > same as the destination register, because that register will be overwritten > with an intermediate value after insn splitting. > > /* example #1 *

Re: [PATCH] Guard truncate from vector float to vector __bf16 with !flag_rounding_math && HONOR_NANS (BFmode).

On Fri, Nov 8, 2024 at 10:33 AM liuhongt wrote: > > hw instruction doesn't raise exceptions, turns sNAN into qNAN quietly, > and always round to nearest (even). Output denormals are always > flushed to zero and input denormals are always treated as zero. MXCSR > is not consulted nor updated. > W/o

[PATCH v3] i386: Zero extend 32-bit address to 64-bit with option -mx32 -maddress-mode=long. [PR 117418]

OK, added check for target. Bootstrapped and Regtested on x86-64-linux-pc-gnu, OK for trunk? BRs, Lin -maddress-mode=long let Pmode = DI_mode, so zero extend 32-bit address to 64-bit and uses a 64-bit register as a pointer for avoid raise an ICE. gcc/ChangeLog: PR target/117418

[PATCH v3] [GCCJIT] support dynamic alloca stub

This patch adds dynamic alloca stubs support to GCCJIT. DEF_BUILTIN_STUB only defines the enum for builtins instead of providing the type. Therefore, builtins with stub will lead to ICE before this patch. This applies to `alloca_with_align`, `stack_save` and `stack_restore`. This patch adds speci

Re: [patch, Fortran] Reject UNSIGNED for COMPLEX

Hi Thomas, the patch is basically fine. I am wondering if we should create a new helper function that is the opposite of type_check ("type_cannot_be"), so that we avoid redundant code at the source level. It may not be worth it yet, so your choice. Furthermore, if you planned to list intrinsic

Re: [Patch, fortran] PR109345 - [12/13/14/15 Regression] class(*) variable that is a string array is not handled correctly

Hi Paul, this looks good to me for mainline as well as backports ... ... except that the PR number should be corrected (109345 instead of 109435) in the testcase and the commit message (Change.logs). Thanks for the patch! Harald Am 10.11.24 um 14:52 schrieb Paul Richard Thomas: Hi All, The

[PATCH] testsuite: arm: Mark pr81812.C as xfail for thumb1

Ok for trunk and releases/gcc-14? -- Test fails for Cortex-M0 with: .../pr81812.C:6:8: error: generic thunk code fails for method 'virtual void ChildNode::_ZTv0_n12_NK9ChildNode5errorEz(...) const' which uses '...' According to PR108277, it's expected that thumb1 targets does not support empty

Re: [patch,avr] Fix PR117500: Don't ICE on invalid asm operands.

сб, 9 нояб. 2024 г. в 15:51, Georg-Johann Lay : > > This patch avoids an internal compiler error when a %i gets an operand > that's not valid for %i. It uses output_operand_lossage that outputs > an ordinary error. > > Ok to apply? Ok, please apply. Denis. > > Johann > > -- > > AVR: target/11750

Re: [PATCH v2] gccjit: support dynamic alloca stub

sorry, just noticed that the check_value was wrongly written on the last line of this patch. Other parts should be good. Should I correct it now in a new revision? Or is it okay to wait for further reviews for now? On Sun, Nov 10, 2024 at 13:17, Schrodinger ZHU Yifan wrote: Thi

[PATCH v2] gccjit: support dynamic alloca stub

This patch adds dynamic alloca stubs support to GCCJIT. DEF_BUILTIN_STUB only defines the enum for builtins instead of providing the type. Therefore, builtins with stub will lead to ICE before this patch. This applies to `alloca_with_align`, `stack_save` and `stack_restore`. This patch adds speci

[PATCH] testsuite: arm: Prune incremental link warning

Ok for trunk and releases/gcc-14? -- When the feature "needs_status_wrapper" in dejagnu is used, the resulting gcc_tg.o file is a regular object file and thus the following warning will be emitted if doing an incremental link: .../ld: warning: incremental linking of LTO and non-LTO objects; usin

Re: [committed] contrib: Add 2 further ignored commits

On Sun, Nov 10, 2024 at 01:30:06PM -0300, Alexandre Oliva wrote: > On Nov 9, 2024, Jakub Jelinek wrote: > > > r15-4998 and r15-5004 had wrong commit message, add those to > > ignored commits. > > Ugh, sorry and thanks. > Was that .c vs .cc only, or was there anything else? I think so. > I'm s

Re: [committed] contrib: Add 2 further ignored commits

On Nov 9, 2024, Jakub Jelinek wrote: > r15-4998 and r15-5004 had wrong commit message, add those to > ignored commits. Ugh, sorry and thanks. Was that .c vs .cc only, or was there anything else? I'm surprised the commit-time checker didn't catch them. It used to, and that was very helpful to a

[PATCH] [v2] Add missing SLP discovery for CFN[_MASK][_LEN]_SCATTER_STORE

This was responsible for a bunch of SVE FAILs with --param vect-force-slp=1 Bootstrap and regtest running on x86_64-unknown-linux-gnu. * tree-vect-slp.cc (arg1_arg3_map): New. (arg1_arg3_arg4_map): Likewise. (vect_get_operand_map): Handle IFN_SCATTER_STORE, IFN_MAS

[PATCH] testsuite: arm: fast-math-complex-add-half-float.c test should not xfail

Ok for trunk? -- With the change in 15-3128-gde1923f9f4d, this test case no longer xfail. gcc/testsuite/ChangeLog: * gcc.dg/vect/complex/fast-math-complex-add-half-float.c: Remove xfail from test. Signed-off-by: Torbjörn SVENSSON --- .../gcc.dg/vect/complex/fast-math-complex-

[Patch, fortran] PR109345 - [12/13/14/15 Regression] class(*) variable that is a string array is not handled correctly

Hi All, The failing testcase came about because the array reference in the TYPE IS block required the correct value of the span. The fix separates out unlimited polymorphic expressions in gfc_get_array_span and ensures that the value returned is the originating array span, rather than the element

Re: [PATCH v18 0/2] c: Add __countof__ operator

Am Sonntag, dem 10.11.2024 um 11:32 +0100 schrieb Alejandro Colomar: > Hi! > > Your favourite operator with the most controversial name comes back with > support for [0], thanks to Martin Uecker. In movie theaters, and > probably in GCC 16. > > For those who fight in a side in the name wars, her

[PATCH] testsuite: arm: Update expected RTL for reg_equal_test.c test

Hi Richard, I'm not sure if I'm doing something wrong here, or if it was an oversight when doing the update in r12-8108-g62082d278d1. Anyway, the commit message suggest that it's only the constant that is of interrest, so I updated the test to only check the constant. Do you think this is enough,

[PATCH v3 1/7] Improve outgoing integer argument promotion

For targets, like x86, which define TARGET_PROMOTE_PROTOTYPES to return true, all integer arguments smaller than int are passed as int: [hjl@gnu-tgl-3 pr14907]$ cat x.c extern int baz (char c1); int foo (char c1) { return baz (c1); } [hjl@gnu-tgl-3 pr14907]$ gcc -S -O2 -m32 x.c [hjl@gnu-tgl-3 p

[PATCH v3 7/7] ssa-fre-4.c: Skip for all targets

Since the C frontend no longer promotes char argument, ssa-fre-4.c will fail for all targets. Skip it for all targets. PR middle-end/14907 * gcc.dg/tree-ssa/ssa-fre-4.c: Skip for all targets. Signed-off-by: H.J. Lu --- gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-4.c | 6 +++--- 1 fil

[PATCH v3 5/7] vect-simd-clone-1[6-8][cd].c: Expect in-branch clones for x86

Since the C frontend no longer promotes char and short arguments, expect in-branch clones for x86. PR middle-end/14907 * gcc.dg/vect/vect-simd-clone-16c.c: Expect in-branch clones for x86. * gcc.dg/vect/vect-simd-clone-16d.c: Likewise. * gcc.dg/vect/vect-sim

[PATCH v3 3/7] i386: Use GET_MODE with lowpart_subreg

With expand_promote_outgoing_argument, op3 in op3 = lowpart_subreg (QImode, op3, HImode); may not be in HImode. Call lowpart_subreg on op3 only if it isn't integer constant and pass GET_MODE (op3) to lowpart_subreg instead of HImode. PR middle-end/14907 * config/i386/i386-expa

[PATCH v3 6/7] scev-cast.c: Adjusted

Since the C frontend no longer promotes char argument, adjust scev-cast.c. PR middle-end/14907 * gcc.dg/tree-ssa/scev-cast.c: Adjusted. Signed-off-by: H.J. Lu --- gcc/testsuite/gcc.dg/tree-ssa/scev-cast.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/gc

[PATCH v3 0/7] Improve outgoing integer argument promotion

For targets, like x86, which define TARGET_PROMOTE_PROTOTYPES to return true, all integer arguments smaller than int are passed as int: [hjl@gnu-tgl-3 pr14907]$ cat x.c extern int baz (char c1); int foo (char c1) { return baz (c1); } [hjl@gnu-tgl-3 pr14907]$ gcc -S -O2 -m32 x.c [hjl@gnu-tgl-3 p

[PATCH v3 2/7] Add expand_promote_outgoing_argument

Since the C/C++/Ada frontends no longer promote integer argument smaller than int, add expand_promote_outgoing_argument to promote it when expanding builtin functions. PR middle-end/14907 * expr.cc (expand_promote_outgoing_argument): New function. * expr.h (expand_promote_o

[PATCH v3 4/7] i386: Adjust apx-ndd.c for frontend promotion removal

Since the C frontend no longer promotes integer argument smaller than int, the apx-ndd.c codgen is slightly different: --- apx-ndd.s (original)2024-11-10 06:07:09.894876973 +0800 +++ apx-ndd.s (updated) 2024-11-10 06:06:59.371860565 +0800 @@ -17,7 +17,7 @@ foo_add_char: foo1_add_c

[PING^1][PATCH v3] rs6000: Fix issue in specifying PTImode as an attribute [PR106895]

Ping! please review. Thanks & Regards Jeevitha On 14/10/24 5:16 pm, jeevitha wrote: > Hi All, > > The following patch has been bootstrapped and regtested on powerpc64le-linux. > > PTImode assists in generating even/odd register pairs on 128 bits. When the > user > specifies PTImode as an attr

[PING^1][PATCH] testsuite: Simplify target test and dg-options for AMO tests

Ping! please review. Thanks & Regards Jeevitha On 15/10/24 12:49 pm, jeevitha wrote: > Hi All, > > Removed powerpc*-*-* from the target test as it is always true. Simplified > options by removing -mpower9-misc and -mvsx, which are enabled by default with > -mdejagnu-cpu=power9. The has_arch_pwr

Re: [PATCH v18 0/2] c: Add __countof__ operator

On Sun, Nov 10, 2024 at 11:32:54AM GMT, Alejandro Colomar wrote: > Hi! > > Your favourite operator with the most controversial name comes back with > support for [0], thanks to Martin Uecker. In movie theaters, and > probably in GCC 16. > > For those who fight in a side in the name wars, here's

[PATCH v18 2/2] c: Add __countof__ operator

This operator is similar to sizeof but can only be applied to an array, and returns its number of elements. FUTURE DIRECTIONS: - We should make it work with array parameters to functions, and somehow magically return the number of elements of the array, regardless of it being really a poin

[PATCH v18 0/2] c: Add __countof__ operator

Hi! Your favourite operator with the most controversial name comes back with support for [0], thanks to Martin Uecker. In movie theaters, and probably in GCC 16. For those who fight in a side in the name wars, here's a reminder of a fair survey (by JeanHeyd) which might end the war with a peace

[PATCH v18 1/2] contrib/: Add support for Cc: and Link: tags

contrib/ChangeLog: * gcc-changelog/git_commit.py (GitCommit): Add support for 'Cc: ' and 'Link: ' tags. Cc: Jason Merrill Signed-off-by: Alejandro Colomar --- contrib/gcc-changelog/git_commit.py | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/contrib/gcc

Adjust 'libgomp.c/max_vf-*.c' (was: [PATCH 4/4] openmp: Add testcases for omp_max_vf)

Hi! On 2024-11-06T16:18:50+, Andrew Stubbs wrote: > On 06/11/2024 15:41, Jakub Jelinek wrote: >> On Wed, Nov 06, 2024 at 03:27:22PM +, Andrew Stubbs wrote: >>> [...] requires enabling the offload-dump scanning features previously only >>> used >>> in the libgomp testsuite. The automake

[PATCH] testsuite: arm: Update expected assembler for pr43920-2.c test

Ok for trunk, releases/gcc-12, releases/gcc-13 and releases/gcc-14? -- In version 6-2017-q1-update of the "GNU Arm Embedded Toolchain" build, there are 2 pop instructions. In version 7-2018-q2-update, the next version that still have a binary build available on launchpad, there is only a single p

[PATCH v3] testsuite: arm: Use effective-target for attr-neon* tests

Changes since v1: - Changed from arm_neon to arm_arch_v7a for the required effective target. Changes since v2: - Added arm_libc_fp_abi as an required effective taret. - Removed to arm_neon and arm_vfp from effective target. With v3, the tests are now tested in armv7-a context in either hard or