[PATCH] arm: Fix parsecpu.awk for aliases [PR113030]

2024-01-20 Thread Andrew Pinski
So the problem here is the 2 functions check_cpu and check_arch use the wrong variable to check if an alias is valid for that cpu/arch. check_cpu uses cpu_optaliases instead of cpu_opt_alias. cpu_optaliases is an array of index'ed by the cpuname that contains all of the valid aliases for that cpu

[COMMITTED] Clean up examples for -Wdangling-pointer [PR109708]

2024-01-20 Thread Sandra Loosemore
gcc/ChangeLog PR c/109708 * doc/invoke.texi (Warning Options): Fix broken example and clean up/reorganize the others. Also describe what the short-form options mean. --- gcc/doc/invoke.texi | 56 +++-- 1 file changed, 34

Re: [C PATCH] Fix ICE for composite type for structs with unsigned bitfields [PR113492]

2024-01-20 Thread Joseph Myers
On Sat, 20 Jan 2024, Martin Uecker wrote: > C23: Fix ICE for composite type for structs with unsigned bitfields [PR113492] > > This patch fixes a bug when forming a composite type from structs that > contain an unsigned bitfield declared with int while using > -funsigned-bitfields. > In

[PATCH] c++: Fix importing nested namespace declarations [PR100707]

2024-01-20 Thread Nathaniel Shead
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? -- >8 -- Currently, importing a namespace declarations marks it as imported, and so marks it as originating from the module that it was imported from. This is usually harmless, but causes problems with nested namespaces. In the

Re: PR82943 - Suggested patch to fix

2024-01-20 Thread Alexander Westbrooks
Based on what I am reading here, I can either do the DCO path or the copy right form path? Or is it both, where I send in the copy right forms and then on every commit I put the DCO? On Sat, Jan 20, 2024 at 3:40 PM Harald Anlauf wrote: > Am 20.01.24 um 21:37 schrieb Jerry D: > > On 1/20/24

[committed] Remove several xfails for 32-bit hppa*-*-*

2024-01-20 Thread John David Anglin
Tested on hppa-unknown-linux-gnu. Committed to trunk. Dave --- Remove several xfails for 32-bit hppa*-*-* These arise because 32-bit ELF targets were changed from callee copies to caller copies. 2024-01-20 John David Anglin gcc/testsuite/ChangeLog: * gcc.dg/ipa/iinline-4.c:

[PATCH] Fortran: passing of optional scalar arguments with VALUE attribute [PR113377]

2024-01-20 Thread Harald Anlauf
Dear all, here's the first part of an attempt to fix issues with optional dummy arguments as actual arguments to optional dummies. This patch rectifies the case of scalar dummies with the VALUE attribute, which in gfortran's argument passing convention are passed on the stack when they are of

[committed] Increase timeout by 2 in libgomp.fortran/alloc-comp-3.f90 on hppa*-*-*

2024-01-20 Thread John David Anglin
Tested on hppa64-hp-hpux11.11. Committed to trunk. Dave --- Increase timeout by 2 in libgomp.fortran/alloc-comp-3.f90 on hppa*-*-* 2024-01-20 John David Anglin libgomp/ChangeLog: * testsuite/libgomp.fortran/alloc-comp-3.f90: Increase timeout by 2 on hppa*-*-*. diff --git

Re: PR82943 - Suggested patch to fix

2024-01-20 Thread Harald Anlauf
Am 20.01.24 um 21:37 schrieb Jerry D: On 1/20/24 12:08 PM, Harald Anlauf wrote: Am 20.01.24 um 20:08 schrieb Jerry D: On 1/20/24 10:46 AM, Alexander Westbrooks wrote: Hello and Happy New Year! I wanted to follow up on this patch I made to address PR82943 for GFortran. Has anyone had a chance

[committed] Don't run libgomp.c/simd-math-1.c on hppa*-*-hpux*

2024-01-20 Thread John David Anglin
Tested on hppa64-hp-hpux11.11. Committed to trunk. Dave --- Don't run libgomp.c/simd-math-1.c on hppa*-*-hpux* hppa*-*-hpux* lacks necessary math functions. 2024-01-20 John David Anglin libgomp/ChangeLog: * testsuite/libgomp.c/simd-math-1.c: Don't run on hppa*-*-hpux*.

[committed] xfail scan-tree-dump-times checks on hppa*64*-*-* in gcc.dg/tree-ssa/slsr-13.c

2024-01-20 Thread John David Anglin
Tested on hppa64-hp-hpux11.11. Committed to trunk. Dave --- xfail scan-tree-dump-times checks on hppa*64*-*-* in gcc.dg/tree-ssa/slsr-13.c 2024-01-20 John David Anglin gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/slsr-13.c: xfail scan-tree-dump-times checks on hppa*64*-*-*.

[committed] Require target lra in gcc.dg/torture/pr110422.c

2024-01-20 Thread John David Anglin
Tested on hppa64-hp-hpux11.11. Committed to trunk. Dave --- Require target lra in gcc.dg/torture/pr110422.c LRA is required for asm goto. 2024-01-20 John David Anglin gcc/testsuite/ChangeLog: * gcc.dg/torture/pr110422.c: Require target lra. diff --git

[PATCH] ipa-cp: Fix check for exceeding param_ipa_cp_value_list_size (PR 113490)

2024-01-20 Thread Martin Jambor
Hi, When the check for exceeding param_ipa_cp_value_list_size limit was modified to be ignored for generating values from self-recursive calls, it should have been changed from equal to, to equals toor is greater than. This omission manifests itself as PR 113490. When I examined the condition I

Re: PR82943 - Suggested patch to fix

2024-01-20 Thread Jerry D
On 1/20/24 12:08 PM, Harald Anlauf wrote: Am 20.01.24 um 20:08 schrieb Jerry D: On 1/20/24 10:46 AM, Alexander Westbrooks wrote: Hello and Happy New Year! I wanted to follow up on this patch I made to address PR82943 for GFortran. Has anyone had a chance to review it? Thanks, Alexander

[Fortran] half-cycle trig functions and atan[d] fixes

2024-01-20 Thread Steve Kargl
All, I have attached a new patch to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113152 which addresses the following issues. PR113152 -- implement half-cycle trigonometric functions PR113412 -- better error message for atan(y,x) PR113413 -- implement atand(y,x) The patch clocks in at 3488

Re: PR82943 - Suggested patch to fix

2024-01-20 Thread Harald Anlauf
Am 20.01.24 um 20:08 schrieb Jerry D: On 1/20/24 10:46 AM, Alexander Westbrooks wrote: Hello and Happy New Year! I wanted to follow up on this patch I made to address PR82943 for GFortran. Has anyone had a chance to review it? Thanks, Alexander Westbrooks Inserting myself in here just a

Re: PR82943 - Suggested patch to fix

2024-01-20 Thread Jerry D
On 1/20/24 11:08 AM, Jerry D wrote: On 1/20/24 10:46 AM, Alexander Westbrooks wrote: Hello and Happy New Year! I wanted to follow up on this patch I made to address PR82943 for GFortran. Has anyone had a chance to review it? Thanks, Alexander Westbrooks Inserting myself in here just a

[COMMITTED] ipa: Add testcase for already fixed case [PR110705]

2024-01-20 Thread Andrew Pinski
This testcase was fixed with r13-1695-gb0f02eeb906b63 which added an Ada testcase for the issue but adding a C testcase is a good idea and that is what this does. Committed after making sure it passes on x86_64-linux-gnu. PR ipa/110705 gcc/testsuite/ChangeLog: *

Re: PR82943 - Suggested patch to fix

2024-01-20 Thread Jerry D
On 1/20/24 10:46 AM, Alexander Westbrooks wrote: Hello and Happy New Year! I wanted to follow up on this patch I made to address PR82943 for GFortran. Has anyone had a chance to review it? Thanks, Alexander Westbrooks Inserting myself in here just a little bit. I will apply and test

Re: PR82943 - Suggested patch to fix

2024-01-20 Thread Alexander Westbrooks
Hello and Happy New Year! I wanted to follow up on this patch I made to address PR82943 for GFortran. Has anyone had a chance to review it? Thanks, Alexander Westbrooks On Thu, Jun 29, 2023 at 10:38 PM Alexander Westbrooks wrote: > Hello, > > I have finished my testing, and updated my patch

[C PATCH] Fix ICE for composite type for structs with unsigned bitfields [PR113492]

2024-01-20 Thread Martin Uecker
C23: Fix ICE for composite type for structs with unsigned bitfields [PR113492] This patch fixes a bug when forming a composite type from structs that contain an unsigned bitfield declared with int while using -funsigned-bitfields. In such structs the unsigned integer type was not compatible

Re: [PATCH] libgccjit: Add ability to get CPU features

2024-01-20 Thread Antoni Boucher
CC-ing Iain in case they can do the review since it is based on how they did it in the D frontend. Could you please do the review? Thanks! On Thu, 2023-11-09 at 18:04 -0500, David Malcolm wrote: > On Thu, 2023-11-09 at 17:27 -0500, Antoni Boucher wrote: > > Hi. > > This patch adds support for

[COMMITTED] Correct documentation for -Warray-parameter [PR102998]

2024-01-20 Thread Sandra Loosemore
gcc/ChangeLog PR c/102998 * doc/invoke.texi (Option Summary): Add -Warray-parameter. (Warning Options): Correct/edit discussion of -Warray-parameter to make the first example less confusing, and fill in missing info. --- gcc/doc/invoke.texi | 24

[PATCH 1/2] x86: Add no_callee_saved_registers function attribute

2024-01-20 Thread H.J. Lu
When an interrupt handler is implemented by an assembly stub which does: 1. Save all registers. 2. Call a C function. 3. Restore all registers. 4. Return from interrupt. it is completely unnecessary to save and restore any registers in the C function called by the assembly stub, even if they

[PATCH 2/2] x86: Don't save callee-saved registers in noreturn functions

2024-01-20 Thread H.J. Lu
There is no need to save callee-saved registers in noreturn functions if they don't throw nor support exceptions. We can treat them the same as functions with no_callee_saved_registers attribute. Adjust stack-check-17.c for noreturn function which no longer saves any registers. With this

[PATCH 0/2] x86: Don't save callee-saved registers if not needed

2024-01-20 Thread H.J. Lu
In some cases, there are no need to save callee-saved registers: 1. If a noreturn function doesn't throw nor support exceptions, it can skip saving callee-saved registers. 2. When an interrupt handler is implemented by an assembly stub which does: 1. Save all registers. 2. Call a C

Re: [PATCH] lower-bitint: Handle INTEGER_CST rhs1 in handle_cast [PR113462]

2024-01-20 Thread Jakub Jelinek
On Sat, Jan 20, 2024 at 12:11:10PM +0100, Richard Biener wrote: > > The following patch ICEs because fre3 leaves around unfolded > > _1 = VIEW_CONVERT_EXPR<_BitInt(129)>(0); > > Hmm, const_unop should handle this, I suppose either we fail to convert this > to a NOP_EXPR or native

Re: [PATCH] lower-bitint: Handle INTEGER_CST rhs1 in handle_cast [PR113462]

2024-01-20 Thread Richard Biener
> Am 20.01.2024 um 10:39 schrieb Jakub Jelinek : > > Hi! > > The following patch ICEs because fre3 leaves around unfolded > _1 = VIEW_CONVERT_EXPR<_BitInt(129)>(0); Hmm, const_unop should handle this, I suppose either we fail to convert this to a NOP_EXPR or native encode/interpret do not

Re: [PATCH] tree-switch-conversion: Bugfixes for _BitInt [PR113491]

2024-01-20 Thread Richard Biener
> Am 20.01.2024 um 10:36 schrieb Jakub Jelinek : > > Hi! > > The following patch fixes various issues with large/huge _BitInt used as > switch > expressions. > In particular: > 1) the indexes in CONSTRUCTORs shouldn't be types with precision larger than > sizetype precision, varasm uses

[PATCH v3] c++/modules: Emit definitions of ODR-used static members imported from modules [PR112899]

2024-01-20 Thread Nathaniel Shead
On Fri, Jan 19, 2024 at 01:57:18PM -0500, Patrick Palka wrote: > On Wed, 3 Jan 2024, Nathaniel Shead wrote: > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? > > > > -- >8 -- > > > > Static data members marked 'inline' should be emitted in TUs where they > > are ODR-used.

[patch] nvptx.opt: Add sm_89 and sm_90a to -march-map=

2024-01-20 Thread Tobias Burnus
Stumbled over this as we recently got a sm_89 card. -march-map= is mostly a future proof method for user to ensure to use always the best code gen for a specific card - without needing to know which GCC version added support for what --march=sm_... (or -misa=sm_... - those are aliases).

[PATCH] lower-bitint: Handle INTEGER_CST rhs1 in handle_cast [PR113462]

2024-01-20 Thread Jakub Jelinek
Hi! The following patch ICEs because fre3 leaves around unfolded _1 = VIEW_CONVERT_EXPR<_BitInt(129)>(0); statement and in handle_cast I was expecting just SSA_NAMEs for the large/huge _BitInt to large/huge _BitInt casts; INTEGER_CST is something we can handle in that case exactly the same, as

[PATCH] tree-switch-conversion: Bugfixes for _BitInt [PR113491]

2024-01-20 Thread Jakub Jelinek
Hi! The following patch fixes various issues with large/huge _BitInt used as switch expressions. In particular: 1) the indexes in CONSTRUCTORs shouldn't be types with precision larger than sizetype precision, varasm uses wi::to_offset on those and too large indexes ICE; we've already

Re: [middle-end PATCH] Prefer PLUS over IOR in RTL expansion of multi-word shifts/rotates.

2024-01-20 Thread Uros Bizjak
On Fri, Jan 19, 2024 at 5:50 PM Jeff Law wrote: > > > > On 1/19/24 09:05, Georg-Johann Lay wrote: > > > > > > Am 18.01.24 um 20:54 schrieb Roger Sayle: > >> > >> This patch tweaks RTL expansion of multi-word shifts and rotates to use > >> PLUS rather than IOR for disjunctive operations. During

Re: [PING][PATCH] Include safe-ctype.h after C++ standard headers, to avoid over-poisoning

2024-01-20 Thread Sam James
Sam James writes: > Dimitry Andric writes: > >> Ping. It would be nice to get this QoL fix in. >> > > Yes please - we've been using this in Gentoo since around when it was > first posted. No complaints. > > I cannot approve but it looks good to me. Ping. > >> -Dimitry >> >>> On 28 Sep 2023,