[Ada] Fix comment about building names in task arrays

2022-05-10 Thread Pierre-Marie de Rodat via Gcc-patches
Cleanup related to handling of character values in SPARK counterexamples, which just like the code for names in task arrays create N_Character_Literal nodes. Tested on x86_64-pc-linux-gnu, committed on trunk gcc/ada/ * exp_util.adb (Build_Task_Array_Image): Fix style in the

[Ada] Cleanup detection of No_Elist with No and Present

2022-05-10 Thread Pierre-Marie de Rodat via Gcc-patches
Replace equality and inequality operators with calls to No and Present. Offending occurrences found with: $ grep -n " /\?= No_Elist" *.adb Code cleanup only; semantics is unaffected. Tested on x86_64-pc-linux-gnu, committed on trunk gcc/ada/ * exp_ch11.adb, exp_ch5.adb, exp_prag.adb,

[Ada] Simplify call to overloaded Earlier_In_Extended_Unit

2022-05-10 Thread Pierre-Marie de Rodat via Gcc-patches
We have two variants of Earlier_In_Extended_Unit that take either Node_Id or Source_Ptr values. The caller can simply use another variant and not explicitly convert parameters. Code cleanup; semantics is unaffected. Tested on x86_64-pc-linux-gnu, committed on trunk gcc/ada/ *

Re: [PATCH] PR fortran/105501 - check for non-optional spaces between adjacent keywords

2022-05-10 Thread Mikael Morin
Le 09/05/2022 à 21:34, Harald Anlauf a écrit : Hi Mikael, Am 09.05.22 um 20:24 schrieb Mikael Morin: The fix itself looks good.  Regarding the test, I don’t understand the problem.  Can’t there be multiple subroutines, each having one (or more) problematic statement(s)? that's why I tried

Re: [Patch] OpenMP: Fix use_device_{addr, ptr} with in-data-sharing arg

2022-05-10 Thread Thomas Schwinge
Hi! On 2022-04-20T15:19:38+0200, Tobias Burnus wrote: > For >omp parallel shared(array_desc_var) > the shared-variable is passed to the generated function as > argument - and replaced by a DECL_VALUE_EXPR inside the parallel region. > > If inside the parallel region, a > >omp target data

[Ada] Simplify conversion from Character to Char_Code

2022-05-10 Thread Pierre-Marie de Rodat via Gcc-patches
Replace "Char_Code (Character'Pos (...))" with "Get_Char_Code (...)". The Get_Char_Code routine is inlined, so there is no performance penalty when it is called with static actual parameters. The N_Character_Literal has field Char_Literal_Value of type Unat, but we should really only store there

[Ada] Fix hiding of user-defined operator that is not a homograph

2022-05-10 Thread Pierre-Marie de Rodat via Gcc-patches
This adds a missing test for the presence of a homograph when applying the RM 8.4(10) clause about the visibility of operators, and removes resolution code made obsolete by the change. There is also a fixlet for a previously undetected ambiguity in the runtime. Tested on x86_64-pc-linux-gnu,

[Ada] Remove tiny and incomplete optimization for unset references

2022-05-10 Thread Pierre-Marie de Rodat via Gcc-patches
Code cleanup; behaviour is unaffected. Tested on x86_64-pc-linux-gnu, committed on trunk gcc/ada/ * sem_warn.adb (Check_Unset_Reference): The early test was only saving time of calls to Original_Node, Comes_From_Source and Nkind, which are all quick and cheap.diff --git

[Ada] Prevent search for references in postconditions from going too far

2022-05-10 Thread Pierre-Marie de Rodat via Gcc-patches
Add a standard prevention against climbing the entire compilation unit. Cleanup only; behaviour of the compiler is unaffected. Tested on x86_64-pc-linux-gnu, committed on trunk gcc/ada/ * sem_warn.adb (Within_Postcondition): Guard against search going too far.diff --git

[Ada] Optimize nonstandard boolean conversions

2022-05-10 Thread Pierre-Marie de Rodat via Gcc-patches
This patch improves the generated code for nonstandard boolean types. One of the improvements extends the code that avoids converting back to the nonstandard boolean type an expression computed as standard boolean, when it will be converted to a(nother) nonstandard boolean type. The other

Re: [PATCH 02/10] aarch64: Add backend support for DFP

2022-05-10 Thread Richard Sandiford via Gcc-patches
Christophe Lyon via Gcc-patches writes: > @@ -8464,10 +8464,18 @@ aarch64_gen_storewb_pair (machine_mode mode, rtx > base, rtx reg, rtx reg2, >return gen_storewb_pairdf_di (base, base, reg, reg2, > GEN_INT (-adjustment), >

Re: [PATCH 09/10] libgcc: Add support for HF mode (aka __fp16) in libbid

2022-05-10 Thread Joseph Myers
On Tue, 10 May 2022, Christophe Lyon via Gcc-patches wrote: > > Note that for conversion from DFP to HFmode, double rounding (going via > > SFmode) probably produces incorrectly rounded results in some cases > > (though we already have such incorrect results in the other direction for > > DPD;

PING Re: [PATCH RFA] attribs: fix typedefs in generic code [PR105492]

2022-05-10 Thread Jason Merrill via Gcc-patches
Ping? On 5/5/22 14:07, Jason Merrill wrote: In my patch for PR100545 I added an assert to check for broken typedefs in set_underlying_type, and it found one in this case: rs6000_handle_altivec_attribute had the same problem as handle_mode_attribute. So let's move the fixup into

rs6000: Prefer assigning the MMA vector operands to altivec registers [PR105556]

2022-05-10 Thread Peter Bergner via Gcc-patches
This patch addresses an issue when compiling the MMA optimized DGEMM kernel in OpenBLAS. The MMA code uses all 8 accumulators, which overlap all vs0-vs31 vector registers. Current trunk assigns one of the normal vector inputs to one of the MMA instructions, which forces us to spill one of the

Re: [PATCH, rs6000] Implemented f[min/max]_optab by xs[min/max]dp [PR103605]

2022-05-10 Thread Michael Meissner via Gcc-patches
On Tue, May 10, 2022 at 07:27:30AM -0500, Segher Boessenkool wrote: > > IMHO, it's something we want to fix as well, based on the reasons: > > 1) bif names have the corresponding mnemonics, users would expect 1-1 > > mapping here. > > 2) clang emits xs{min,max}dp all the time, with cpu type

Re: [PATCH, rs6000] Implemented f[min/max]_optab by xs[min/max]dp [PR103605]

2022-05-10 Thread Segher Boessenkool
On Tue, May 10, 2022 at 02:56:58PM -0400, Michael Meissner wrote: > On Tue, May 10, 2022 at 07:27:30AM -0500, Segher Boessenkool wrote: > > > IMHO, it's something we want to fix as well, based on the reasons: > > > 1) bif names have the corresponding mnemonics, users would expect 1-1 > > >

[Ada] Fix oversight for case expression in Eval_Integer_Literal

2022-05-10 Thread Pierre-Marie de Rodat via Gcc-patches
The intent of the entry test is to treat conditional expressions, that is to say if-expression and case-expression, alike and to require that a second condition be true for them. But an N_Case_Expression_Alternative is not an N_Subexpr so this second condition was short-circuited for this node.

[Ada] Refine iteration from entities to formals

2022-05-10 Thread Pierre-Marie de Rodat via Gcc-patches
When matching formal parameters from spec and body it is cleaner and more efficient to iterate with First_Formal/Next_Formal and not with First_Entity/Next_Entity. The previous iteration could unintentionally pick entities from within the subprogram body, e.g. objects declared within the

[Ada] Optimize nonstandard boolean validity checking

2022-05-10 Thread Pierre-Marie de Rodat via Gcc-patches
Validity checking of enumerations with nonstandard representation starts by checking the value range, then calling _rep_to_pos to verify that the value itself is valid. The value range check is thus redundant and inefficient: the _rep_to_pos call is normally inlined when optimizing for speed and

[PATCH] Replace PTR with 'void *' in compiler.

2022-05-10 Thread Martin Liška
Similarly in GCC itself. I've built all FEs with the patch. Patch can bootstrap on x86_64-linux-gnu and survives regression tests. Ready to be installed? Thanks, Martin gcc/ada/ChangeLog: * gcc-interface/decl.cc (compare_field_bitpos): Use void * instead PTR. *

[PATCH] Remove non-ANSI C macros in ansidecl.h.

2022-05-10 Thread Martin Liška
Patch can bootstrap on x86_64-linux-gnu and survives regression tests. @Alan: Are you fine with the change from binutils/gdb perspective? Thanks, Martin include/ChangeLog: * ansidecl.h (PTR): Remove. (const): Likewise. (volatile): Likewise. (signed): Likewise.

Re: [PATCH] Remove non-ANSI C macros in ansidecl.h.

2022-05-10 Thread Andreas Schwab
The header line should probably be changed since it's no longer about ANSI or traditional C. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."

Re: [PATCH] Remove non-ANSI C macros in ansidecl.h.

2022-05-10 Thread Martin Liška
On 5/10/22 11:55, Andreas Schwab wrote: > The header line should probably be changed since it's no longer about > ANSI or traditional C. > Sure, updated in v2. MartinFrom 9359921cd29f9ec4f7536f49160ad54b74e0214a Mon Sep 17 00:00:00 2001 From: Martin Liska Date: Tue, 10 May 2022 09:47:08 +0200

[PATCH] middle-end/105537 - debug processing

2022-05-10 Thread Richard Biener via Gcc-patches
The following makes sure to have a consistent state of flag_var_tracking_assignments with the distributed handling in process_options and finish_options by moving everything to finish_options which also restores diagnostics for -g0 -fvar-tracking which was lost with previous changes. Bootstrapped

Re: [PATCH v2] Skip constant folding for fmin/max when either argument is sNaN [PR105414]

2022-05-10 Thread Richard Biener via Gcc-patches
On Tue, May 10, 2022 at 10:10 AM HAO CHEN GUI wrote: > > Hi, >This patch skips constant folding for fmin/max when either argument > is sNaN. According to C standard, >fmin(sNaN, sNaN)= qNaN, fmin(sNaN, NaN) = qNaN >So signaling NaN should be tested and skipped for fmin/max in

Re: [PATCH] Remove size limit of PCH

2022-05-10 Thread LIU Hao via Gcc-patches
在 2022-05-10 20:00, Xi Ruoyao 写道: On Tue, 2022-05-10 at 19:35 +0800, LIU Hao via Gcc-patches wrote: Subject: [PATCH] Remove size limit of PCH Make it "Remove size limit of PCH [PR14940]", so once it's committed a message will show up in bugzilla. Here is the revised patch. -- Best

Re: [PATCH] libiberty: stop using PTR macro.

2022-05-10 Thread Jeff Law via Gcc-patches
On 5/10/2022 2:56 AM, Martin Liška wrote: Hi. As noticed by Alan, we can stop using the non-ANSI C specific macro (PTR). Let's removed its usafe in libiberty. Patch can bootstrap on x86_64-linux-gnu and survives regression tests. Ready to be installed? Thanks, Martin include/ChangeLog:

[PATCH 1/2] c++: Harden *_PACK_EXPANSION and *_ARGUMENT_PACK macros

2022-05-10 Thread Patrick Palka via Gcc-patches
The accessor macros for TYPE_PACK_EXPANSION/EXPR_PACK_EXPANSION and TYPE_ARGUMENT_PACK/NONTYPE_ARGUMENT_PACK should check the tree code of the argument. Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? gcc/cp/ChangeLog: * cp-tree.h (PACK_EXPANSION_CHECK):

[Ada] Reject numeric literals with too big exponents

2022-05-10 Thread Pierre-Marie de Rodat via Gcc-patches
While the compiler can compute numeric literal with arbitrary large exponents, this may take ages and is most likely a typo. Better emit an error when we certainly expect it to take long. The chosen threshold takes about 100s to compute. Tested on x86_64-pc-linux-gnu, committed on trunk gcc/ada/

[Ada] Handle non-standard booleans in if_expression condition

2022-05-10 Thread Pierre-Marie de Rodat via Gcc-patches
We failed to call Adjust_Condition for the condition expression of an if_expression, so non-standard booleans were expanded like standard booleans, disregarding representation clauses. Fixed. Tested on x86_64-pc-linux-gnu, committed on trunk gcc/ada/ * exp_ch4.adb

Re: [PATCH 02/10] aarch64: Add backend support for DFP

2022-05-10 Thread Richard Sandiford via Gcc-patches
Richard Sandiford writes: > The patch changes the scalar handling in aapcs_vfp_sub_candidate, > but not the complex handling. Is that deliberate? TIL: we don't support complex decimal floats. So never mind that :-) Richard

Re: [PATCH] Replace PTR with 'void *' in compiler.

2022-05-10 Thread Richard Biener via Gcc-patches
On Tue, May 10, 2022 at 11:38 AM Martin Liška wrote: > > Similarly in GCC itself. I've built all FEs with the patch. > > Patch can bootstrap on x86_64-linux-gnu and survives regression tests. > > Ready to be installed? OK for the middle-end parts. Richard. > Thanks, > Martin > >

[Ada] Avoid repeated conversions from Int to Char_Code

2022-05-10 Thread Pierre-Marie de Rodat via Gcc-patches
When expanding aggregates like "(others => 'x')" into strings we repeated conversion from Int to Char_Code for every character. Now we convert once and use the Char_Code directly. Cleanup related to handling characters in GNATprove counterexamples; semantics is unaffected. Tested on

[Ada] Remove repeated conversions between Source_Ptr and Int

2022-05-10 Thread Pierre-Marie de Rodat via Gcc-patches
Both Source_Ptr and Int are integer types (and even happen to have equal ranges). Their values can be calculated without converting back-and-forth, e.g.: Int (Loc1) - Int (Loc2) can be written simply as: Int (Loc1 - Loc2) Code cleanup related to handling of references to unset objects.

[Ada] Reuse Is_Rewrite_Substitution where possible

2022-05-10 Thread Pierre-Marie de Rodat via Gcc-patches
Replace comparisons of Original_Node with semantically equivalent but high-level calls to Is_Rewrite_Substitution. Offending occurrences found with: $ grep -n "Original_Node (\([A-Za-z_]\+\)) /\?= \1" *.adb Code cleanup only; semantics is unaffected. Tested on x86_64-pc-linux-gnu, committed

[PATCH] aarch64: Fix pac-ret with unusual dwarf in libgcc unwinder [PR104689]

2022-05-10 Thread Szabolcs Nagy via Gcc-patches
The RA_SIGN_STATE dwarf pseudo-register is normally only set using the DW_CFA_AARCH64_negate_ra_state (== DW_CFA_window_save) operation which toggles the return address signedness state (the default state is 0). (It may be set by remember/restore_state CFI too, those save/restore the state of all

Re: [patch][gcc13][i386][pr101891]Adjust -fzero-call-used-regs to always use XOR

2022-05-10 Thread Qing Zhao via Gcc-patches
> On May 10, 2022, at 1:12 AM, Richard Biener wrote: > > On Mon, 9 May 2022, Uros Bizjak wrote: > >> On Mon, May 9, 2022 at 5:44 PM Qing Zhao wrote: >>> >>> Another question: >>> >>> I think that this patch might need to be back ported to Gcc12 and GCC11. >>> >>> What?s your opinion on

[Ada] Failure compiling "for ... of" loop over a slice

2022-05-10 Thread Pierre-Marie de Rodat via Gcc-patches
In some cases involving a "for ... of" loop (not to be confused with the more common "for ... in" loop) iterating over a slice, compilation would fail with an internal compiler error. Tested on x86_64-pc-linux-gnu, committed on trunk gcc/ada/ * sem_util.adb (Get_Actual_Subtype): If a

[Ada] Fix incorrect range computation

2022-05-10 Thread Pierre-Marie de Rodat via Gcc-patches
When the type range [Lo, Hi] and the computed expression range [Lor, Hir] are disjoint, the range-constraining logic breaks and returns an incorrect range. For example, when Lodiff --git a/gcc/ada/checks.adb b/gcc/ada/checks.adb --- a/gcc/ada/checks.adb +++ b/gcc/ada/checks.adb @@ -5469,22

[Ada] Check if- and case-expressions for unset references

2022-05-10 Thread Pierre-Marie de Rodat via Gcc-patches
Detection of references to unset (uninitialized) objects requires calls to Check_Unset_Reference on every subexpression of a composite statement and expression. This was missing for if-expressions and incomplete for case-expressions. Tested on x86_64-pc-linux-gnu, committed on trunk gcc/ada/

[Ada] Incorrect ineffective use type clause warning

2022-05-10 Thread Pierre-Marie de Rodat via Gcc-patches
This patch fixes an issue in the compiler whereby a use_type_clause incorrectly gets flagged as ineffective when the use of it comes after a generic package instantiation where the installation of private use clauses are required and one such clause references the same type. Tested on

[PATCH] isel: Fix up gimple_expand_vec_set_expr [PR105528]

2022-05-10 Thread Jakub Jelinek via Gcc-patches
Hi! The following testcase ICEs (and only without -g), because we don't replace one VEC_COND_EXPR with .VCOND* call. We don't do that because gimple_expand_vec_set_expr adds some stmts before *gsi and then uses gsi_remove to remove it. gsi_remove moves the iterator to the next stmt and in the

[PATCH] Store complicated const into pool

2022-05-10 Thread Jiufu Guo via Gcc-patches
Hi, To set a constant to a reg, one way is building the constant through instructions, like lis/ori/sldi... Another way is loading it from the constant pool through instruction 'ld'(or 'pld' for P10). Loading a constant may need 2 instructions (or just 'pld' on P10), and according to testing,

Re: [PATCH] Replace PTR with 'void *' in compiler.

2022-05-10 Thread Arnaud Charlet via Gcc-patches
> > Similarly in GCC itself. I've built all FEs with the patch. > > > > Patch can bootstrap on x86_64-linux-gnu and survives regression tests. > > > > Ready to be installed? > > OK for the middle-end parts. and OK for the Ada parts.

[Ada] Accept Structural in aspect Subprogram_Variant and pragma Loop_Variant

2022-05-10 Thread Pierre-Marie de Rodat via Gcc-patches
Add a new form of variants to ensure termination of loops or recursive subprograms. Structural variants correspond to objects which designate a part of the data-structure they used to designate in the previous loop iteration or recursive call. They only imply termination if the data-structure is

[PATCH] libiberty: stop using PTR macro.

2022-05-10 Thread Martin Liška
Hi. As noticed by Alan, we can stop using the non-ANSI C specific macro (PTR). Let's removed its usafe in libiberty. Patch can bootstrap on x86_64-linux-gnu and survives regression tests. Ready to be installed? Thanks, Martin include/ChangeLog: * hashtab.h (HTAB_EMPTY_ENTRY): Use void

[c++] Disambiguate ModuleKind flags

2022-05-10 Thread Nathan Sidwell
In modules, 'attached to global module' nearly always means 'not in module purview'. Also the implementation treats, 'in global module && in module purview' as meaning 'header unit'. The ModuleKind flags reflected that. The 'nearly always' means there are cases that the first condition is not

[PATCH] Remove size limit of PCH

2022-05-10 Thread LIU Hao via Gcc-patches
Remove the limit and solve https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14940. I have tested the patch on `x86_64-w64-mingw32` with MSVCRT, by pre-compiling a header of many standard and boost headers to generate a 313-MiB-large .gch file and using it to compile a simple 'hello world' program,

Re: [PATCH] Remove size limit of PCH

2022-05-10 Thread Xi Ruoyao via Gcc-patches
On Tue, 2022-05-10 at 19:35 +0800, LIU Hao via Gcc-patches wrote: > Subject: [PATCH] Remove size limit of PCH Make it "Remove size limit of PCH [PR14940]", so once it's committed a message will show up in bugzilla. > Reference: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14940 > Signed-off-by:

Re: [PATCH] Remove non-ANSI C macros in ansidecl.h.

2022-05-10 Thread Jeff Law via Gcc-patches
On 5/10/2022 4:51 AM, Martin Liška wrote: On 5/10/22 11:55, Andreas Schwab wrote: The header line should probably be changed since it's no longer about ANSI or traditional C. Sure, updated in v2. OK jeff

[Ada] Cleanup unnecessary declare block in Check_Unreachable_Code

2022-05-10 Thread Pierre-Marie de Rodat via Gcc-patches
Cleanup related to static detection of references to uninitialized variables. Semantics is unaffected. Tested on x86_64-pc-linux-gnu, committed on trunk gcc/ada/ * sem_ch5.adb (Check_Unreachable_Code): Remove inner declare block; refill code and comments.diff --git

[PATCH][pushed] libgcov: use proper type for n_functions

2022-05-10 Thread Martin Liška
gcov_info::n_functions type is initialized by generated code in build_info_type: /* n_functions */ field = build_decl (BUILTINS_LOCATION, FIELD_DECL, NULL_TREE, get_gcov_unsigned_t ()); It uses gcov_unsigned_t, but the struct definition in libgcov.h uses unsigned type. That

[PATCH] Properly use opts in finish_options

2022-05-10 Thread Richard Biener via Gcc-patches
When code was moved from process_options to finish_options it was not properly adjusted to look at and alter the opts set passed to the function but continued to modify the global options set. The following rectifies this and makes sure the same mistake isn't repeated by poisoning

Re: [PATCH 02/10] aarch64: Add backend support for DFP

2022-05-10 Thread Christophe Lyon via Gcc-patches
On 5/10/22 11:30, Richard Sandiford wrote: Richard Sandiford writes: The patch changes the scalar handling in aapcs_vfp_sub_candidate, but not the complex handling. Is that deliberate? TIL: we don't support complex decimal floats. So never mind that :-) Indeed. Sorry, maybe I should

Re: [patch gcc13] middle-end/70090: Dynamic sizes for -fsanitize=object-size

2022-05-10 Thread Martin Liška
On 5/9/22 09:37, Jakub Jelinek via Gcc-patches wrote: > On Mon, May 09, 2022 at 01:02:07PM +0530, Siddhesh Poyarekar wrote: >> On 07/02/2022 17:37, Jakub Jelinek wrote: >>> On Mon, Feb 07, 2022 at 05:31:58PM +0530, Siddhesh Poyarekar wrote: Use __builtin_dynamic_object_size to get object

[PATCH, OpenMP, v2] Implement uses_allocators clause for target regions

2022-05-10 Thread Chung-Lin Tang
On 2022/5/7 12:40 AM, Tobias Burnus wrote: Can please also handle the new clause in Fortran's dump-parse-tree.cc? I did see some split handling in C, but not in Fortran; do you also need to up update gfc_split_omp_clauses in Fortran's trans-openmp.cc? Done. Actually, glancing at the

Re: [PATCH, rs6000] Implemented f[min/max]_optab by xs[min/max]dp [PR103605]

2022-05-10 Thread Segher Boessenkool
Hi guys, On Mon, May 09, 2022 at 12:05:51PM +0800, Kewen.Lin wrote: > on 2022/5/9 09:54, HAO CHEN GUI wrote: > > This patch implements optab f[min/max]_optab by xs[min/max]dp on rs6000. > > Tests show that outputs of xs[min/max]dp are consistent with the standard > > of C99 fmin/max. > > gcc/

Re: [PATCH v2] c, c++: -Wswitch warning on [[maybe_unused]] enumerator [PR105497]

2022-05-10 Thread Jason Merrill via Gcc-patches
On 5/7/22 18:26, Marek Polacek wrote: Corrected version that avoids an uninitialized warning: This PR complains that we emit the "enumeration value not handled in switch" warning even though the enumerator was marked with the [[maybe_unused]] attribute. The first snag was that I couldn't just

[Ada] Replace variables with constants in expanded code for task names

2022-05-10 Thread Pierre-Marie de Rodat via Gcc-patches
Using constants instead of variables is cleaner both in human-written and auto-generated code. Cleanup related to handling of character values in SPARK counterexamples, which just like the code for names of tasks create N_Character_Literal nodes. Tested on x86_64-pc-linux-gnu, committed on trunk

[Ada] Check declare and qualified expressions for unset references

2022-05-10 Thread Pierre-Marie de Rodat via Gcc-patches
Detection of references to unset (uninitialized) objects requires calls to Check_Unset_Reference on every subexpression of a composite statement and expression. For declare and qualified expressions this was done only when they occurred within another composite statement/expression. Tested on

Re: [PATCH] opts: do not allow Separate+Joined ending with =

2022-05-10 Thread Martin Liška
On 5/9/22 14:26, Richard Biener wrote: > On Mon, May 9, 2022 at 2:16 PM Martin Liška wrote: >> >> On 5/9/22 13:58, Richard Biener wrote: >>> The patch would have been a lot smaller if you kept it Joined only? >> >> Yes, but the langspec rules append a space for some reason: >> >> $ ./xgcc -B.

Re: [PATCH 08/10] testsuite: Add C++ unwinding tests with Decimal Floating-Point

2022-05-10 Thread Richard Sandiford via Gcc-patches
Christophe Lyon via Gcc-patches writes: > These tests exercise exception handling with Decimal Floating-Point > type. > > dfp-1.C and dfp-2.C check that thrown objects of such types are > properly caught, whether when using C++ classes (decimalXX) or via GCC > mode attributes. > >

Re: [PATCH 00/10] Enable Decimal Floating Point (DFP) on AArch64

2022-05-10 Thread Richard Sandiford via Gcc-patches
Christophe Lyon via Gcc-patches writes: > This patch series enables support of DFP on AArch64, using the BID > format (Binary Integer Decimal). There is no HW support for DFP on > AArch64, and we made a choice similar to x86: BID format using > libgcc's libbid for software emulation. > > This

Re: [PATCH] isel: Fix up gimple_expand_vec_set_expr [PR105528]

2022-05-10 Thread Richard Biener via Gcc-patches
On Tue, 10 May 2022, Jakub Jelinek wrote: > Hi! > > The following testcase ICEs (and only without -g), because we don't replace > one VEC_COND_EXPR with .VCOND* call. > We don't do that because gimple_expand_vec_set_expr adds some stmts before > *gsi and then uses gsi_remove to remove it.

[PATCH 2/2] c++: Remove SET_PACK_EXPANSION_PATTERN / SET_ARGUMENT_PACK_ARGS

2022-05-10 Thread Patrick Palka via Gcc-patches
Unlike in C, in C++ the conditional operator yields an lvalue if both branches are lvalues, so we can just assign to PACK_EXPANSION_PATTERN and ARGUMENT_PACK_ARGS directly. Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? gcc/cp/ChangeLog: * coroutines.cc

[RESEND][committed v4] RISC-V: Provide `fmin'/`fmax' RTL patterns

2022-05-10 Thread Maciej W. Rozycki
As at r2.2 of the RISC-V ISA specification[1] (equivalent to version 2.0 of the "F" and "D" standard architecture extensions for single-precision and double-precision floating-point respectively) the FMIN and FMAX machine instructions fully match our requirement for the `fminM3' and `fmaxM3'

Re: [PATCH] Remove non-ANSI C macros in ansidecl.h.

2022-05-10 Thread Alan Modra via Gcc-patches
On Tue, May 10, 2022 at 10:57:47AM +0200, Martin Liška wrote: > Patch can bootstrap on x86_64-linux-gnu and survives regression tests. > > @Alan: Are you fine with the change from binutils/gdb perspective? I'm fine if this isn't going into the binutils-gdb repo immediately. There are occurrences

Re: [PATCH 1/2] c++: Harden *_PACK_EXPANSION and *_ARGUMENT_PACK macros

2022-05-10 Thread Jason Merrill via Gcc-patches
On 5/10/22 09:40, Patrick Palka wrote: The accessor macros for TYPE_PACK_EXPANSION/EXPR_PACK_EXPANSION and TYPE_ARGUMENT_PACK/NONTYPE_ARGUMENT_PACK should check the tree code of the argument. Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? OK.

Re: [PATCH] AArch64: Improve address rematerialization costs

2022-05-10 Thread Richard Sandiford via Gcc-patches
Wilco Dijkstra writes: > Hi Richard, > >>> There isn't really a better way of doing this within the existing costing >>> code. >> >> Yeah, I was wondering whether we could change something there. >> ADRP+LDR is logically more expensive than a single LDR, especially >> when optimising for size,

[committed 1/2] libstdc++: Add declarations to [PR105284]

2022-05-10 Thread Jonathan Wakely via Gcc-patches
Tested powerpc64le-linux, pushed to trunk. -- >8 -- libstdc++-v3/ChangeLog: PR libstdc++/105284 * include/std/iosfwd: Add declarations for class templates and typedefs. * include/std/syncstream (basic_syncbuf, basic_osyncstream): Remove default template

Re: [PATCH] Remove non-ANSI C macros in ansidecl.h.

2022-05-10 Thread Martin Liška
On 5/10/22 16:09, Alan Modra wrote: > On Tue, May 10, 2022 at 10:57:47AM +0200, Martin Liška wrote: >> Patch can bootstrap on x86_64-linux-gnu and survives regression tests. >> >> @Alan: Are you fine with the change from binutils/gdb perspective? > > I'm fine if this isn't going into the

Re: [PATCH] AArch64: Improve address rematerialization costs

2022-05-10 Thread Wilco Dijkstra via Gcc-patches
Hi Richard, >> There isn't really a better way of doing this within the existing costing >> code. > > Yeah, I was wondering whether we could change something there. > ADRP+LDR is logically more expensive than a single LDR, especially > when optimising for size, so I think it's reasonable for the

[PATCH] Use gimple-match folding in fold_build_cond_expr

2022-05-10 Thread Richard Biener via Gcc-patches
The following cleans up if-conversions fold_build_cond_expr to use gimple-match folding instead of GENERIC folding. Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed. 2022-05-10 Richard Biener * tree-if-conv.cc (fold_build_cond_expr): Use match-and-simplify to

Re: [PATCH] libiberty: stop using PTR macro.

2022-05-10 Thread Eric Gallager via Gcc-patches
On Tue, May 10, 2022 at 5:37 AM Martin Liška wrote: > > Hi. > > As noticed by Alan, we can stop using the non-ANSI C specific macro (PTR). > Let's removed its usafe in libiberty. > > Patch can bootstrap on x86_64-linux-gnu and survives regression tests. > > Ready to be installed? > Thanks, >

Re: [RESEND][committed v4] RISC-V: Provide `fmin'/`fmax' RTL patterns

2022-05-10 Thread Kito Cheng via Gcc-patches
Thanks Maciej! On Tue, May 10, 2022 at 10:05 PM Maciej W. Rozycki wrote: > > As at r2.2 of the RISC-V ISA specification[1] (equivalent to version 2.0 > of the "F" and "D" standard architecture extensions for single-precision > and double-precision floating-point respectively) the FMIN and FMAX >

[PATCH] x86: Document -mno-cet-switch

2022-05-10 Thread H.J. Lu via Gcc-patches
When -fcf-protection=branch is used, the compiler will generate jump tables where the indirect jump is prefixed with the NOTRACK prefix, so it can jump to non-ENDBR targets. Yet, for NOTRACK prefixes to work, the NOTRACK specific enable bit must be set, what renders the binary broken on any

[PATCH] Add -fcf-check-attribute=[yes|no|none] for Linux kernel

2022-05-10 Thread H.J. Lu via Gcc-patches
When compiling Linux kernel with -fcf-protection=branch to enable x86 Indiret Branch Tracking (IBT), ENDBR is added to all global functions. This creates more "legal" forward edges than necessary. -mmanual-endbr provides a way to insert ENDBR instruction at function entry only via the 'cf_check'

Advise to call 'internal_error' instead of 'abort' or 'fancy_abort'

2022-05-10 Thread Thomas Schwinge
Hi! On 2022-05-03T15:46:43+0200, Richard Biener wrote: > On Tue, May 3, 2022 at 2:29 PM Thomas Schwinge > wrote: >> On 2022-05-03T12:53:50+0200, Richard Biener >> wrote: >> > On Tue, May 3, 2022 at 10:16 AM Thomas Schwinge >> > wrote: >> >> On 2022-05-03T09:17:52+0200, Richard Biener >>

Re: [PATCH] libiberty: stop using PTR macro.

2022-05-10 Thread Martin Liška
On 5/10/22 16:20, Alan Modra wrote: > On Tue, May 10, 2022 at 10:56:22AM +0200, Martin Liška wrote: > >> diff --git a/libiberty/hashtab.c b/libiberty/hashtab.c > >> @@ -457,15 +457,15 @@ htab_empty (htab_t htab) >>else if (htab->free_with_arg_f != NULL) >> (*htab->free_with_arg_f)

Re: [PATCH] x86: Add .note.GNU-stack section only for Linux

2022-05-10 Thread H.J. Lu via Gcc-patches
On Mon, May 9, 2022 at 7:51 AM H.J. Lu wrote: > > Add .note.GNU-stack section only for Linux since it may not be supported > on non-Linux OSes. __ELF__ isn't checked since these tests can only run > on Linux/x86 ELF systems. > > PR target/105472 > *

[PATCH] doc: Fix mode iterator example

2022-05-10 Thread Segher Boessenkool
The example missed the mode condition in the replacement text. Committed as obvious. Segher 2022-05-10 Segher Boessenkool * doc/md.texi (Defining Mode Iterators): Correct example replacement text. --- gcc/doc/md.texi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

Ping: [PATCH, rs6000] Fix passing of Coomplex IEEE 128-bit [PR99685]

2022-05-10 Thread Pat Haugen via Gcc-patches
Ping. On 4/26/22 3:06 PM, Pat Haugen via Gcc-patches wrote: Fix register count when not splitting Complex IEEE 128-bit args. For ABI_V4, we do not split complex args. This created a problem because even though an arg would be passed in two VSX regs, we were only advancing the function arg

Re: [committed] Fix more problems with new linker warnings

2022-05-10 Thread H.J. Lu via Gcc-patches
On Thu, Apr 28, 2022 at 11:52 PM Richard Biener wrote: > > On Thu, Apr 28, 2022 at 7:54 PM H.J. Lu wrote: > > > > On Thu, Apr 28, 2022 at 9:59 AM Jeff Law wrote: > > > > > > > > > > > > On 4/28/2022 10:27 AM, H.J. Lu wrote: > > > > On Thu, Apr 28, 2022 at 9:10 AM Jeff Law via Gcc-patches > > >

Re: [PATCH v2] c, c++: -Wswitch warning on [[maybe_unused]] enumerator [PR105497]

2022-05-10 Thread Marek Polacek via Gcc-patches
On Tue, May 10, 2022 at 08:58:46AM -0400, Jason Merrill wrote: > On 5/7/22 18:26, Marek Polacek wrote: > > Corrected version that avoids an uninitialized warning: > > > > This PR complains that we emit the "enumeration value not handled in > > switch" warning even though the enumerator was marked

Re: [PATCH] libiberty: stop using PTR macro.

2022-05-10 Thread Martin Liška
On 5/10/22 15:50, Eric Gallager wrote: > Hi, please preserve existing style when possible when making this > replacement; ISTR there are some tools (like for generating > libiberty's documentation) that depend on the return type being on a > separate line... If all of the relevant Makefile targets

Re: [PATCH] libiberty: stop using PTR macro.

2022-05-10 Thread Alan Modra via Gcc-patches
On Tue, May 10, 2022 at 10:56:22AM +0200, Martin Liška wrote: > diff --git a/libiberty/hashtab.c b/libiberty/hashtab.c > @@ -457,15 +457,15 @@ htab_empty (htab_t htab) >else if (htab->free_with_arg_f != NULL) > (*htab->free_with_arg_f) (htab->alloc_arg, htab->entries); >if

[PATCH] aarch64: Fix va_arg alignment handling (PR target/105549)

2022-05-10 Thread Christophe Lyon via Gcc-patches
While working on enabling DFP for AArch64, I noticed new failures in gcc.dg/compat/struct-layout-1.exp (t028) which were not actually caused by DFP types handling. These tests are generated during 'make check' and enabling DFP made generation different (not sure if new non-DFP tests are generated,

[committed 2/2] libstdc++: Add declarations to [PR105284]

2022-05-10 Thread Jonathan Wakely via Gcc-patches
Tested powerpc64le-linux, pushed to trunk. -- >8 -- libstdc++-v3/ChangeLog: PR libstdc++/105284 * include/std/iosfwd: Add declarations for class templates and typedefs. * include/std/spanstream (basic_spanbuf, basic_ispanstream) (basic_ospanstream,

[PATCH] x86: Skip ENDBR when emitting direct call/jmp to local function

2022-05-10 Thread H.J. Lu via Gcc-patches
Mark a function with SYMBOL_FLAG_FUNCTION_ENDBR when inserting ENDBR at function entry. Skip the 4-byte ENDBR when emitting a direct call/jmp to a local function with ENDBR at function entry. This has been tested on Linux kernel. gcc/ PR target/102953 *

Re: [patch gcc13] middle-end/70090: Dynamic sizes for -fsanitize=object-size

2022-05-10 Thread Siddhesh Poyarekar
On 10/05/2022 16:16, Martin Liška wrote: The revision caused: $ ./xgcc -B. /home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/ubsan/bind-c-intent-out-2.f90 -fsanitize=undefined -c -O during GIMPLE pass: ubsan

Re: [PATCH 2/2] c++: Remove SET_PACK_EXPANSION_PATTERN / SET_ARGUMENT_PACK_ARGS

2022-05-10 Thread Jason Merrill via Gcc-patches
On 5/10/22 09:40, Patrick Palka wrote: Unlike in C, in C++ the conditional operator yields an lvalue if both branches are lvalues, so we can just assign to PACK_EXPANSION_PATTERN and ARGUMENT_PACK_ARGS directly. Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk?

[PATCH][pushed] libiberty: fix bad replacement.

2022-05-10 Thread Martin Liška
Pushed as obvious. Martin libiberty/ChangeLog: * random.c: Remove 'define PTR'. --- libiberty/random.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/libiberty/random.c b/libiberty/random.c index be8819dd6b8..cd0b7399e73 100644 --- a/libiberty/random.c +++ b/libiberty/random.c @@

Re: [PATCH] OpenMP, C++: Add template support for the has_device_addr clause.

2022-05-10 Thread Marcel Vollweiler
Hi Jakub, diff --git a/gcc/cp/semantics.cc b/gcc/cp/semantics.cc index 0cb17a6..452ecfd 100644 --- a/gcc/cp/semantics.cc +++ b/gcc/cp/semantics.cc @@ -8534,11 +8534,14 @@ finish_omp_clauses (tree clauses, enum c_omp_region_type ort) { if (handle_omp_array_sections (c, ort))

Re: [PATCH] PR fortran/105526 - [Coarray] Add missing checks for arguments of type TEAM_TYPE

2022-05-10 Thread Mikael Morin
Le 09/05/2022 à 22:20, Harald Anlauf via Fortran a écrit : Dear Fortranners, we were lacking checks for arguments of type TEAM_TYPE to some coarray intrinsics (FORM TEAM, CHANGE TEAM, and SYNC TEAM). The attached patch adds these, and as a bonus verifies that TEAM NUMBER is a scalar integer.

Re: [ping2][PATCH 0/8][RFC] Support BTF decl_tag and type_tag annotations

2022-05-10 Thread Yonghong Song via Gcc-patches
On 5/6/22 2:18 PM, David Faust wrote: On 5/5/22 16:00, Yonghong Song wrote: On 5/4/22 10:03 AM, David Faust wrote: On 5/3/22 15:32, Joseph Myers wrote: On Mon, 2 May 2022, David Faust via Gcc-patches wrote: Consider the following example: #define __typetag1

Re: [ping2][PATCH 0/8][RFC] Support BTF decl_tag and type_tag annotations

2022-05-10 Thread Yonghong Song via Gcc-patches
On 5/10/22 8:43 PM, Yonghong Song wrote: On 5/6/22 2:18 PM, David Faust wrote: On 5/5/22 16:00, Yonghong Song wrote: On 5/4/22 10:03 AM, David Faust wrote: On 5/3/22 15:32, Joseph Myers wrote: On Mon, 2 May 2022, David Faust via Gcc-patches wrote: Consider the following example:

[PATCH] PR fortran/105230 - [9/10/11/12/13 Regression] ICE in find_array_section, at fortran/expr.cc:1634

2022-05-10 Thread Harald Anlauf via Gcc-patches
Dear all, I intend to commit the attached patch as obvious within the next 24 hours unless there are objections. It fixes the logic which is intended to prevent a NULL pointer dereference on invalid code, which is related to PR104849. (Both PRs by Gerhard). Co-authored by Steve. Regtested on

Supporting RISC-V Vendor Extensions in the GNU Toolchain

2022-05-10 Thread Palmer Dabbelt
[Sorry for cross-posting to a bunch of lists, I figured it'd be best to have all the discussions in one thread.] We currently only support what is defined by official RISC-V specifications in the various GNU toolchain projects. There's certainly some grey areas there, but in general that

Re: [PATCH] testsuite: btf: Fix btf-datasec-1.c for RISC-V

2022-05-10 Thread Kito Cheng via Gcc-patches
LGTM, that's only added a new option for RISC-V and won't affect all other targets, so I assume I can approve that. On Wed, May 4, 2022 at 8:27 AM Palmer Dabbelt wrote: > > Similar to 37e65643d3e ("testsuite/101269: fix testcase when used with > -m32"), RISC-V needs to be told not to put symbols

Re: [wwwdocs] gcc-12/changes.html: Document the RISC-V libstdc++ -latomic detection

2022-05-10 Thread Kito Cheng via Gcc-patches
LGTM, I think document what we really did in GCC 12 is never too late :P On Fri, Apr 29, 2022 at 2:23 AM Palmer Dabbelt wrote: > > --- > IMO this one is worth documenting too, not sure if it's too late for > gcc-12's docs (due to those branch commits) so I haven't committed it > yet to avoid

  1   2   >