[COMITTED] contrib: mklog: Use present tense in ChangeLog

[Bernhard Reutner-Fischer]

Hi!

installed as r14-9256

> diff --git a/contrib/mklog.py b/contrib/mklog.py
> index d764fb41f99..7d8d554b15e 100755
> --- a/contrib/mklog.py
> +++ b/contrib/mklog.py
> @@ -277,7 +277,7 @@ def generate_changelog(data, no_functions=False, 
> fill_pr_titles=False,
>  # it used to be path.source_file[2:]
>  relative_path = 
> get_rel_path_if_prefixed(file.source_file[2:],
>   changelog)
> -out = append_changelog_line(out, relative_path, 'Moved 
> to...')
> +out = append_changelog_line(out, relative_path, 'Move to...')
>  new_path = get_rel_path_if_prefixed(file.target_file[2:],
>  changelog)
>  out += f'\t* {new_path}: ...here.\n'
> 
> 
> cheers

Re: [patch, libgfortran] Part 2: PR105456 Child I/O does not propage iostat

[Bernhard Reutner-Fischer]

On Wed, 28 Feb 2024 21:29:06 -0800
Jerry D  wrote:

> The attached patch adds the error checks similar to the first patch 
> previously committed.
> 
> I noticed a redundancy in some defines MSGLEN and IOMSG_LEN so I 
> consolidated this to one define in io.h. This is just cleanup stuff.
> 
> I have added test cases for each of the places where UDTIO is done in 
> the library.
> 
> Regressions tested on x86_64.
> 
> OK for trunk?

I think the commit hooks will complain about several missing spaces
before open brace; See contrib/check_GNU_style.py /tmp/pr105456-3.diff

Would it make sense to introduce and use an internal helper like trim()?
Or would it be possible to trim the message in generate_error_common()?

And, just for my own education, the length limitation of iomsg to 255
chars is not backed by the standard AFAICS, right? It's just our
STRERR_MAXSZ?

thanks!

> 
> Regards,
> 
> Jerry
> 
> commit 640991bd6b83df4197b2eaec63d1e0e695e48b75
> Author: Jerry DeLisle 
> Date:   Wed Feb 28 20:51:06 2024 -0800
> 
>  Fortran: Add user defined error messages for UDTIO.
> 
>  The defines IOMSG_LEN and MSGLEN were redundant so these are combined
>  into IOMSG_LEN as defined in io.h.
> 
>  The remainder of the patch adds checks for when a user defined
>  derived type IO procedure sets the IOSTAT or IOMSG variables
>  independent of the librrary defined I/O messages.
> 
>  PR libfortran/105456
> 
>  libgfortran/ChangeLog:
> 
>  * io/io.h (IOMSG_LEN): Moved to here.
>  * io/list_read.c (MSGLEN): Removed MSGLEN.
>  (convert_integer): Changed MSGLEN to IOMSG_LEN.
>  (parse_repeat): Likewise.
>  (read_logical): Likewise.
>  (read_integer): Likewise.
>  (read_character): Likewise.
>  (parse_real): Likewise.
>  (read_complex): Likewise.
>  (read_real): Likewise.
>  (check_type): Likewise.
>  (list_formatted_read_scalar): Adjust to IOMSG_LEN.
>  (nml_read_obj): Add user defined error message.
>  * io/transfer.c (unformatted_read): Add user defined error
>  message.
>  (unformatted_write): Add user defined error message.
>  (formatted_transfer_scalar_read): Add user defined error 
> message.
>  (formatted_transfer_scalar_write): Add user defined error 
> message.
>  * io/write.c (list_formatted_write_scalar): Add user 
> defined error message.
>  (nml_write_obj): Add user defined error message.
> 
>  gcc/testsuite/ChangeLog:
> 
>  * gfortran.dg/pr105456-nmlr.f90: New test.
>  * gfortran.dg/pr105456-nmlw.f90: New test.
>  * gfortran.dg/pr105456-ruf.f90: New test.
>  * gfortran.dg/pr105456-wf.f90: New test.
>  * gfortran.dg/pr105456-wuf.f90: New test.

Re: [wwwdocs] gcc-14/changes.html + projects/gomp/: OpenMP + OpenACC update

[Bernhard Reutner-Fischer]

On Tue, 27 Feb 2024 at 20:17, Tobias Burnus  wrote:
>
> Minor update for older and more recent changes.
>
> Comments?

Nit:

+OpenACC 3.2: The following API routines are now available in
+  Fortran using the openacc module or the
+  open_lib.h header file: acc_alloc,

s/open_lib.h/openacc_lib.h/

thanks

Re: [PATCH v1 05/13] Reuse MinGW from i386 for AArch64

[Bernhard Reutner-Fischer]

On Sun, 25 Feb 2024 at 22:12, Mark Harmstone  wrote:
> Also, there are relocation types needed for Windows programs that are 
> supported in COFF but not in ELF object files.
>

Right, it's been a long time since i last dealt with PECOFF and i had
assumed that things might have changed in the meantime.

PS: Please don't forget to add an entry to contrib/config-list.mk
thanks

Re: [PATCH v1 05/13] Reuse MinGW from i386 for AArch64

[Bernhard Reutner-Fischer]

On Thu, 22 Feb 2024 15:56:46 +
Evgeny Karpov  wrote:

> A ChangeLog template using "Moved... ...here" has been generated by 
> contrib/mklog.py.
> It seems that it needs modification.
> 
> Regards,
> Evgeny
> 
> -Original Message-
> Thursday, February 22, 2024 12:11 PM
> Richard Earnshaw (lists) wrote:
> 
> > The ChangeLog has to be expressed in present tense, as mandated by the 
> > standard; s/Moved/Move/g etc.  
> 
> Agreed, but that's a detail that we can get to once the patch has been 
> properly reviewed.
> 

Excellent, two patches for the price of one :)

diff --git a/contrib/mklog.py b/contrib/mklog.py
index d764fb41f99..7d8d554b15e 100755
--- a/contrib/mklog.py
+++ b/contrib/mklog.py
@@ -277,7 +277,7 @@ def generate_changelog(data, no_functions=False, 
fill_pr_titles=False,
 # it used to be path.source_file[2:]
 relative_path = get_rel_path_if_prefixed(file.source_file[2:],
  changelog)
-out = append_changelog_line(out, relative_path, 'Moved to...')
+out = append_changelog_line(out, relative_path, 'Move to...')
 new_path = get_rel_path_if_prefixed(file.target_file[2:],
 changelog)
 out += f'\t* {new_path}: ...here.\n'


cheers

Re: [COMMITTED 07/25] gccrs: TyTy: Store region constraints

[Bernhard Reutner-Fischer]

On Wed,  7 Feb 2024 12:43:53 +0100
arthur.co...@embecosm.com wrote:

> diff --git a/gcc/rust/typecheck/rust-hir-type-check-implitem.h 
> b/gcc/rust/typecheck/rust-hir-type-check-implitem.h
> index 067465ec77a..4d178440775 100644
> --- a/gcc/rust/typecheck/rust-hir-type-check-implitem.h
> +++ b/gcc/rust/typecheck/rust-hir-type-check-implitem.h
> @@ -97,6 +97,7 @@ private:
>HIR::ImplBlock *parent;
>TyTy::BaseType *self;
>std::vector substitutions;
> +  TyTy::RegionConstraints region_costraints;
>  };

/region_costraint/s/cos/cons/;# or delete since it seems unused ATM?

thanks

Re: [Patch, stage-1, RFC]: i386: attribute regparm/stdcall and vaargs

[Bernhard Reutner-Fischer]

Hi Joseph!

On Tue, 30 Jan 2024 14:54:49 + (UTC)
Joseph Myers  wrote:

> On Tue, 30 Jan 2024, Bernhard Reutner-Fischer via Gcc wrote:
> 
> > * builtin-attrs.def (ATTR_TM_NOTHROW_RT_LIST): Use ATTR_NOTHROW_LIST
> > instead of ATTR_TM_NOTHROW_LIST, thus removing ATTR_TM_REGPARM.  
> 
> That doesn't make sense.  ATTR_TM_NOTHROW_RT_LIST is specifically a 
> transactional memory attribute list, but you're removing all transactional 
> memory attributes from it.  A list without the "*tm regparm" internal 
> attribute would have a different name.
> 

AFAICS there is no pre-existing attr list with just returns_twice and
nothrow. Would ATTR_NOTHROW_RT_LIST be more appropriate as name, and
should i move this up to before the format attribute lists, before
DEF_FORMAT_ATTRIBUTE?

Alternatively, there is an existing ATTR_RT_NOTHROW_LEAF_LIST
used by setjmp. But that would add leaf to _ITM_beginTransaction where
it was not marked leaf before. Would it be appropriate to use this for
_ITM_beginTransaction too, which behaves setjmp()ish AFAICS?

thanks

[Patch, stage-1, RFC]: i386: attribute regparm/stdcall and vaargs

[Bernhard Reutner-Fischer]

[I was torn towards asking gcc@ only, individual i386 maintainers in
private or bluntly asking for help on gcc-patches or re-iterate through
ABI, so in an attempt to cut off years of latency i hereby ask all and
everybody for assistance. Stage4 means any chances are low, i know..
hence stage 1 material since it's not pressing in any foreseeable way]
Hello i386 maintainers

Recently, elsewhere, there was discussion about attribute regparm (and
stdcall) on functions with variable number of arguments in C.
Allegedly clang warns about these but GCC does not. I did not look at
clang.

gcc/doc/extend.texi currently states that:

---8<---
@cindex @code{regparm} function attribute, x86
[]
Functions that
take a variable number of arguments continue to be passed all of their
arguments on the stack.
[]
@cindex @code{sseregparm} function attribute, x86
[]
Functions that take a
variable number of arguments continue to pass all of their
floating-point arguments on the stack.
[]
@cindex @code{stdcall} function attribute, x86-32
[]
On x86-32 targets, the @code{stdcall} attribute causes the compiler to
assume that the called function pops off the stack space used to
pass arguments, unless it takes a variable number of arguments.
---8<---

which seems to suggest that all of attribute regparm/sseregparm/stdcall
are ignored on functions with variable number of arguments. I.e. the
ABI mandates that everything is passed on the stack.
[Right? ISTM that this is correct; Didn't follow ABI (tweaks) too
closely in the last decade, admittedly.. But i think this still holds.
Please correct me if i missed something?]

If this is correct, then ISTM that attributes
regparm/sseregparm/stdcall should be rejected on functions with
variable number of arguments also in GCC.

There seems to be (exact) struct function cfun->va_list_[fg]pr_size
for the real fpr and gpr save area sizes. But (unfortunately / of
course) they are layed out way later than parsing the attributes in
both the C++ and C FEs, so using those in ix86_handle_cconv_attribute
is not possible as there is no cfun readily available there yet. ²).

Hence i would propose to ¹):

gcc/ChangeLog:

* builtin-attrs.def (ATTR_TM_NOTHROW_RT_LIST): Use ATTR_NOTHROW_LIST
instead of ATTR_TM_NOTHROW_LIST, thus removing ATTR_TM_REGPARM.
* config/i386/i386-options.cc (ix86_handle_cconv_attribute): Decline
regparm, stdcall and regparm attribute on functions with variable number
of arguments.

libitm/ChangeLog:

* libitm.h (_ITM_beginTransaction): Remove ITM_REGPARM.

gcc/testsuite/ChangeLog:

* gcc.dg/lto/trans-mem.h: Remove ITM_REGPARM.
* gcc.target/i386/attributes-error.c: Extend to cover
(regparm(3),stdcall) on vaargs functions.
* gcc.target/i386/attributes-error-sse.c: New test.

¹) as per attached
²) Unfortunately, the C FE does not readily provide a sensible locus
for the attributes in question but points input_location at that spot
of the beginning of the declaration of such a function. The C++ FE is
a little bit better in this regard:
[here i meant to verbatim emphasis discrepancy of the C++ and C FE
diagnostics for the abovementioned target tests, striking, isn't it, But
see yourselves.]
³) unreferenced, hence implied, where would on do this instead, more
helpful?
diff --git a/gcc/builtin-attrs.def b/gcc/builtin-attrs.def
index 71f4db1f3da..4813509b9c3 100644
--- a/gcc/builtin-attrs.def
+++ b/gcc/builtin-attrs.def
@@ -400,7 +400,7 @@ DEF_ATTR_TREE_LIST (ATTR_TM_NORETURN_NOTHROW_LIST,
 DEF_ATTR_TREE_LIST (ATTR_TM_CONST_NOTHROW_LIST,
 		ATTR_TM_REGPARM, ATTR_NULL, ATTR_CONST_NOTHROW_LIST)
 DEF_ATTR_TREE_LIST (ATTR_TM_NOTHROW_RT_LIST,
-		ATTR_RETURNS_TWICE, ATTR_NULL, ATTR_TM_NOTHROW_LIST)
+		ATTR_RETURNS_TWICE, ATTR_NULL, ATTR_NOTHROW_LIST)
 
 /* Same attributes used for BUILT_IN_MALLOC except with TM_PURE thrown in.  */
 DEF_ATTR_TREE_LIST (ATTR_TMPURE_MALLOC_NOTHROW_LIST,
diff --git a/gcc/config/i386/i386-options.cc b/gcc/config/i386/i386-options.cc
index 3605c2c53fb..daea2394e1a 100644
--- a/gcc/config/i386/i386-options.cc
+++ b/gcc/config/i386/i386-options.cc
@@ -3679,6 +3679,12 @@ ix86_handle_cconv_attribute (tree *node, tree name, tree args, int,
 		   name, REGPARM_MAX);
 	  *no_add_attrs = true;
 	}
+  else if (FUNC_OR_METHOD_TYPE_P (*node) && stdarg_p (*node))
+	{
+	  warning (OPT_Wattributes, "%qE attribute ignored "
+		   "on function with variable number of arguments", name);
+	  *no_add_attrs = true;
+	}
 
   return NULL_TREE;
 }
@@ -3732,6 +3738,12 @@ ix86_handle_cconv_attribute (tree *node, tree name, tree args, int,
 	{
 	  error ("stdcall and thiscall attributes are not compatible");
 	}
+  if (FUNC_OR_METHOD_TYPE_P (*node) && stdarg_p (*node))
+	{
+	  warning (OPT_Wattributes, "%qE attribute ignored "
+		   "on function with variable number of arguments", name);
+	  *no_add_attrs = true;
+	}
 }
 
   /* Can combine cdecl with regparm and sseregparm.  */
@@ 

Re: [PATCH] Fortran: Mark internal symbols as artificial [PR88009,PR68800]

[Bernhard Reutner-Fischer]

On Wed, 17 Nov 2021 21:32:14 +0100
Harald Anlauf  wrote:

> Do you have testcases/reproducers demonstrating that the patch actually
> fixes the issues you're describing?

I believe that marking artificial symbols as such is obvious and i did
use the existing tests to verify that the changes do not regress but
behave as intended. I did check that the memory leak in
gfc_find_derived_vtab is fixed with the patch.

Ok for stage 1 if the rebased regression test passes?

thanks

> 
> Am 17.11.21 um 09:12 schrieb Bernhard Reutner-Fischer via Gcc-patches:
> > On Tue, 16 Nov 2021 21:46:32 +0100
> > Harald Anlauf via Fortran  wrote:
> >  
> >> Hi Bernhard,
> >>
> >> I'm trying to understand your patch.  What does it really try to solve?  
> >
> > Compiler generated symbols should be marked artificial.
> > The fix for PR88009 ( f8add009ce300f24b75e9c2e2cc5dd944a020c28 ,
> > r9-5194 ) added artificial just to the _final component and left out all 
> > the rest.
> > Note that the majority of compiler generated symbols in class.c
> > already had artificial set properly.
> > The proposed patch amends the other generated symbols to be marked
> > artificial, too.
> >
> > The other parts fix memory leaks.
> >  
> >>
> >> PR88009 is closed and seems to have nothing to do with this.  
> >
> > Well it marked only _final as artificial and forgot to adjust the
> > others as well.
> > We can remove the reference to PR88009 if you prefer?
> >
> > thanks!  
> >>
> >> Harald
> >>
> >> Am 14.11.21 um 23:17 schrieb Bernhard Reutner-Fischer via Fortran:  
> >>> Hi!
> >>>
> >>> Amend fix for PR88009 to mark all these class components as artificial.
> >>>
> >>> gcc/fortran/ChangeLog:
> >>>
> >>>   * class.c (gfc_build_class_symbol, 
> >>> generate_finalization_wrapper,
> >>>   (gfc_find_derived_vtab, find_intrinsic_vtab): Use stringpool for
> >>>   names. Mark internal symbols as artificial.
> >>>   * decl.c (gfc_match_decl_type_spec, gfc_match_end): Fix
> >>>   indentation.
> >>>   (gfc_match_derived_decl): Fix indentation. Check extension level
> >>>   before incrementing refs counter.
> >>>   * parse.c (parse_derived): Fix style.
> >>>   * resolve.c (resolve_global_procedure): Likewise.
> >>>   * symbol.c (gfc_check_conflict): Do not ignore artificial 
> >>> symbols.
> >>>   (gfc_add_flavor): Reorder condition, cheapest first.
> >>>   (gfc_new_symbol, gfc_get_sym_tree,
> >>>   generate_isocbinding_symbol): Fix style.
> >>>   * trans-expr.c (gfc_trans_subcomponent_assign): Remove
> >>>   restriction on !artificial.
> >>>   * match.c (gfc_match_equivalence): Special-case CLASS_DATA for
> >>>   warnings.
> >>>
> >>> ---
> >>> gfc_match_equivalence(), too, should not bail-out early on the first
> >>> error but should diagnose all errors. I.e. not goto cleanup but set
> >>> err=true and continue in order to diagnose all constraints of a
> >>> statement. Maybe Sandra or somebody else will eventually find time to
> >>> tweak that.
> >>>
> >>> I think it also plugs a very minor leak of name in gfc_find_derived_vtab
> >>> so i also tagged it [PR68800]. At least that was the initial
> >>> motiviation to look at that spot.
> >>> We were doing
> >>> -  name = xasprintf ("__vtab_%s", tname);
> >>> ...
> >>> gfc_set_sym_referenced (vtab);
> >>> - name = xasprintf ("__vtype_%s", tname);
> >>>
> >>> Bootstrapped and regtested without regressions on x86_64-unknown-linux.
> >>> Ok for trunk?
> >>>  
> >>
> >>  
> >
> >  
> 

Re: [PATCH] RISC-V: Documnet the list of supported extensions

[Bernhard Reutner-Fischer]

Hi Kito!

On Thu, 11 Jan 2024 17:06:09 +0800
Kito Cheng  wrote:

> Try to list all supported extensions: name, version and few description
> for each extension.
> 
> gcc/ChangeLog:
> 
>   * doc/invoke.texi (RISC-V Options): Add list of supported
>   extensions.
> ---
>  gcc/doc/invoke.texi | 463 
>  1 file changed, 463 insertions(+)
> 
> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> index 68d1f364ac0..58271f2f28e 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -30037,6 +30037,469 @@ Generate code for given RISC-V ISA (e.g.@: 
> @samp{rv64im}).  ISA strings must be
>  lower-case.  Examples include @samp{rv64i}, @samp{rv32g}, @samp{rv32e}, and
>  @samp{rv32imaf}.
>  
> +Supported extension are list below:

are listed

> +@multitable @columnfractions .10 .10 .80
> +@headitem Extension Name @tab Supported Version @tab Description
> +@item i
> +@tab 2.0, 2.1
> +@tab Base integer extension.
> +
> +@item e
> +@tab 2.0
> +@tab Reduced base integer extension.
> +
> +@item g
> +@tab -
> +@tab General-purpose computing base extension, @samp{g} will expand to
> +@samp{i}, @samp{m}, @samp{a}, @samp{f}, @samp{d}, @samp{zicsr} and
> +@samp{zifencei}.
> +
> +@item m
> +@tab 2.0
> +@tab Integer multiplication and division extension.
> +
> +@item a
> +@tab 2.0, 2.1
> +@tab Atomic extension.
> +
> +@item f
> +@tab 2.0, 2.2
> +@tab Single-precision floating-point extension.
> +
> +@item d
> +@tab 2.0, 2.2
> +@tab Double-precision floating-point extension.
> +
> +@item c
> +@tab 2.0
> +@tab Compressed extension.
> +
> +@item h
> +@tab 1.0
> +@tab Hypervisor extension.
> +
> +@item v
> +@tab 1.0
> +@tab Vector extension.
> +
> +@item zicsr
> +@tab 2.0
> +@tab Control and status register access extension.
> +
> +@item zifencei
> +@tab 2.0
> +@tab Instruction-fetch fence extension.
> +
> +@item zicond
> +@tab 1.0
> +@tab Integer conditional operations extension.
> +
> +@item zawrs
> +@tab 1.0
> +@tab Wait-on-reservation-set extension.
> +
> +@item zba
> +@tab 1.0
> +@tab Address calculation extension.
> +
> +@item zbb
> +@tab 1.0
> +@tab Basic bit manipulation extension.
> +
> +@item zbc
> +@tab 1.0
> +@tab Carry-less multiplication extension.
> +
> +@item zbs
> +@tab 1.0
> +@tab Single-bit operation extension.
> +
> +@item zfinx
> +@tab 1.0
> +@tab Single-precision floating-ioint in integer registers extension.

s/ioint/point/g
above and below.

> +
> +@item zdinx
> +@tab 1.0
> +@tab Double-precision floating-ioint in integer registers extension.
> +
> +@item zhinx
> +@tab 1.0
> +@tab Half-precision floating-ioint in integer registers extension.
> +
> +@item zhinxmin
> +@tab 1.0
> +@tab Minimal half-precision floating-ioint in integer registers extension.
> +
> +@item zbkb
> +@tab 1.0
> +@tab Cryptography bit-manipulation extension.
> +
> +@item zbkc
> +@tab 1.0
> +@tab Cryptography carry-less multiply extension.
> +
> +@item zbkx
> +@tab 1.0
> +@tab Cryptography crossbar permutation extension.
> +
> +@item zkne
> +@tab 1.0
> +@tab AES Encryption extension.
> +
> +@item zknd
> +@tab 1.0
> +@tab AES Decryption extension.
> +
> +@item zknh
> +@tab 1.0
> +@tab Hash function extension.
> +
> +@item zkr
> +@tab 1.0
> +@tab Entropy source extension.
> +
> +@item zksed
> +@tab 1.0
> +@tab SM4 block cipher extension.
> +
> +@item zksh
> +@tab 1.0
> +@tab SM3 hash function extension.
> +
> +@item zkt
> +@tab 1.0
> +@tab Data independent execution latency extension.
> +
> +@item zk
> +@tab 1.0
> +@tab Standard scalar cryptography extension.
> +
> +@item zkn
> +@tab 1.0
> +@tab NIST algorithm suite extension.

For @item g you document which extensions this will expand to, do you
want to list the expansions here, too?

ISTM that
https://riscv.org/blog/2021/09/risc-v-cryptography-extensions-task-group-announces-public-review-of-the-scalar-cryptography-extensions/
lists
Zkn – NIST Algorithm Suite (shorthand for Zknd_Zkne_Zknh_Zbkb_Zbkc_Zbkx)
Zks – ShangMi Algorithm Suite  (shorthand for Zksed_Zksh_Zbkb_Zbkc_Zbkx)
Zk – Standard scalar cryptography extension (shorthand for Zkn_Zkt_Zkr)

> +
> +@item zks
> +@tab 1.0
> +@tab ShangMi algorithm suite extension.
> +
> +@item zihintntl
> +@tab 1.0
> +@tab Non-temporal locality hints extension.
> +
> +@item zihintpause
> +@tab 1.0
> +@tab Pause hint extension.
> +
> +@item zicboz
> +@tab 1.0
> +@tab Cache-block zero extension.
> +
> +@item zicbom
> +@tab 1.0
> +@tab Cache-block management extension.
> +
> +@item zicbop
> +@tab 1.0
> +@tab Cache-block prefetch extension.
> +
> +@item ztso
> +@tab 1.0
> +@tab Total store ordering extension.
> +
> +@item zve32x
> +@tab 1.0
> +@tab Vector extensions for embedded processors.
> +
> +@item zve32f
> +@tab 1.0
> +@tab Vector extensions for embedded processors.
> +
> +@item zve64x
> +@tab 1.0
> +@tab Vector extensions for embedded processors.
> +
> +@item zve64f
> +@tab 1.0
> +@tab Vector extensions for embedded processors.
> +
> +@item zve64d
> +@tab 1.0
> +@tab Vector 

Re: [PATCH] Fortran: annotations for DO CONCURRENT loops [PR113305]

[Bernhard Reutner-Fischer]

On Wed, 10 Jan 2024 23:24:22 +0100
Harald Anlauf  wrote:

> diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
> index 82f388c05f8..88502c1e3f0 100644
> --- a/gcc/fortran/gfortran.h
> +++ b/gcc/fortran/gfortran.h
> @@ -2926,6 +2926,10 @@ gfc_dt;
>  typedef struct gfc_forall_iterator
>  {
>gfc_expr *var, *start, *end, *stride;
> +  unsigned short unroll;
> +  bool ivdep;
> +  bool vector;
> +  bool novector;
>struct gfc_forall_iterator *next;
>  }
[]
> diff --git a/gcc/fortran/trans-stmt.cc b/gcc/fortran/trans-stmt.cc
> index a718dce237f..59a9cf99f9b 100644
> --- a/gcc/fortran/trans-stmt.cc
> +++ b/gcc/fortran/trans-stmt.cc
> @@ -41,6 +41,10 @@ typedef struct iter_info
>tree start;
>tree end;
>tree step;
> +  unsigned short unroll;
> +  bool ivdep;
> +  bool vector;
> +  bool novector;
>struct iter_info *next;
>  }

Given that we already have in gfortran.h

> typedef struct
> {
>   gfc_expr *var, *start, *end, *step;
>   unsigned short unroll;
>   bool ivdep;
>   bool vector;
>   bool novector;
> }
> gfc_iterator;

would it make sense to break out these loop annotation flags into its
own let's say struct gfc_iterator_flags and use pointers to that flags
instead?

LGTM otherwise.
Thanks for the patch!

PING^3 Re: [i386 PATCH] A minor code clean-up: Use NULL_RTX instead of nullptr

[Bernhard Reutner-Fischer]

On Wed, 14 Jun 2023 21:14:02 +0200
Bernhard Reutner-Fischer  wrote:

> plonk.

ping^3

patch at
https://inbox.sourceware.org/gcc-patches/20230526103151.3a7f6...@nbbrfq.loc/

I would regenerate it for rtx and/or tree, though, whatever you deem
desirable?

thanks

> 
> On 26 May 2023 10:31:51 CEST, Bernhard Reutner-Fischer 
>  wrote:
> >On Thu, 25 May 2023 18:58:04 +0200
> >Bernhard Reutner-Fischer  wrote:
> >  
> >> On Wed, 24 May 2023 18:54:06 +0100
> >> "Roger Sayle"  wrote:
> >>   
> >> > My understanding is that GCC's preferred null value for rtx is NULL_RTX
> >> > (and for tree is NULL_TREE), and by being typed allows strict type 
> >> > checking,
> >> > and use with function polymorphism and template instantiation.
> >> > C++'s nullptr is preferred over NULL and 0 for pointer types that don't
> >> > have a defined null of the correct type.
> >> > 
> >> > This minor clean-up uses NULL_RTX consistently in i386-expand.cc.
> >> 
> >> Oh. Well, i can't resist cleanups :)  
> >  
> >> (and handle nullptr too, and the same game for tree)  
> >
> > so like the attached. And
> > sed -e 's/RTX/TREE/g' -e 's/rtx/tree/g' \
> >  < ~/coccinelle/gcc-rtx-null.0.cocci \  
> >  > ~/coccinelle/gcc-tree-null.0.cocci  
> >
> > I do not know if we want to shorten explicit NULL comparisons.
> > foo == NULL => !foo and foo != NULL => foo
> > Left them alone in the form they were written.
> >
> > See the attached result of the rtx hunks, someone would have to build  
> 
> I've bootstrapped and regtested the hunks for rtx as cited up-thread without 
> regressions (as expected).
> 
> I know everybody is busy, but I'd like to know if I should swap these out 
> completely,
> or postpone this until start of stage3 or next stage 1 or something.
> I can easily keep these local to my personal pre-configure stage for my own 
> amusement.
> 
> thanks,
> 
> >it and hack git-commit-mklog.py --changelog 'Use NULL_RTX.'
> >to print("{}.".format(random.choice(['Ditto', 'Same', 'Likewise']))) ;)
> >  
> >> 
> >> Just a thought..  
> >
> >cheers,  
> 

Re: [PATCH 04/14] c++: use _P() defines from tree.h

[Bernhard Reutner-Fischer]

On Tue, 8 Aug 2023 16:31:39 -0400
Jason Merrill  wrote:

> On 8/2/23 12:51, Patrick Palka via Gcc-patches wrote:
> > On Thu, Jun 1, 2023 at 2:11 PM Bernhard Reutner-Fischer
> >  wrote:  
> >>
> >> Hi David, Patrick,
> >>
> >> On Thu, 1 Jun 2023 18:33:46 +0200
> >> Bernhard Reutner-Fischer  wrote:
> >>  
> >>> On Thu, 1 Jun 2023 11:24:06 -0400
> >>> Patrick Palka  wrote:
> >>>  
> >>>> On Sat, May 13, 2023 at 7:26 PM Bernhard Reutner-Fischer via
> >>>> Gcc-patches  wrote:  
> >>>  
> >>>>> diff --git a/gcc/cp/tree.cc b/gcc/cp/tree.cc
> >>>>> index 131b212ff73..19dfb3ed782 100644
> >>>>> --- a/gcc/cp/tree.cc
> >>>>> +++ b/gcc/cp/tree.cc
> >>>>> @@ -1173,7 +1173,7 @@ build_cplus_array_type (tree elt_type, tree 
> >>>>> index_type, int dependent)
> >>>>>   }
> >>>>>
> >>>>> /* Avoid spurious warnings with VLAs (c++/54583).  */
> >>>>> -  if (TYPE_SIZE (t) && EXPR_P (TYPE_SIZE (t)))
> >>>>> +  if (CAN_HAVE_LOCATION_P (TYPE_SIZE (t)))  
> >>>>
> >>>> Hmm, this change seems undesirable...  
> >>>
> >>> mhm, yes that is misleading. I'll prepare a patch to revert this.
> >>> Let me have a look if there were other such CAN_HAVE_LOCATION_P changes
> >>> that we'd want to revert.  
> >>
> >> Sorry for that!
> >> I'd revert the hunk above and the one in gcc-rich-location.cc
> >> (maybe_range_label_for_tree_type_mismatch::get_text), please see
> >> attached. Bootstrap running, ok for trunk if it passes?  
> > 
> > LGTM!  
> 
> Yes, OK.

Now applied as r14-5508 (186331063dfbcf1eacb445c473d92634c9baa90f)

thanks

Re: [PATCH v4] libgfortran: Replace mutex with rwlock

[Bernhard Reutner-Fischer]

[CCing Ian as libgcc maintainer]

On Wed, 1 Nov 2023 10:14:37 +
"Zhu, Lipeng"  wrote:

> > >
> > > Hi Lipeng,
> > >  
> > > >>> Sure, as your comments, in the patch V6, I added 3 test cases with
> > > >>> OpenMP to test different cases in concurrency respectively:
> > > >>> 1. find and create unit very frequently to stress read lock and write 
> > > >>> lock.
> > > >>> 2. only access the unit which exist in cache to stress read lock.
> > > >>> 3. access the same unit in concurrency.
> > > >>> For the third test case, it also help to find a bug:  When unit
> > > >>> can't be found in cache nor unit list in read phase, then threads
> > > >>> will try to acquire write lock to insert the same unit, this will
> > > >>> cause duplicate key  
> > > >> error.  
> > > >>> To fix this bug, I get the unit from unit list once again before
> > > >>> insert in write  
> > > >> lock.  
> > > >>> More details you can refer the patch v6.
> > > >>>  
> > > >>
> > > >> Could you help to review this update? I really appreciate your 
> > > >> assistance.
> > > >>  
> > >  
> > > > Could you help to review this update?  Any concern will be appreciated. 
> > > >  
> > >
> > > Fortran parts are OK (I think I wrote that already), we need somebody
> > > for the non-Fortran parts.
> > >  
> > Hi Thomas,
> > 
> > Thanks for your response. Very appreciate for your patience and help.
> >   
> > > Jakub, could you maybe take a look?
> > >
> > > Best regards
> > >
> > >   Thomas  
> > 
> > Hi Jakub,
> > 
> > Can you help to take a look at the change for libgcc part that added several
> > rwlock macros in libgcc/gthr-posix.h?
> >   
> 
> Hi Jakub,
> 
> Could you help to review this, any comment will be greatly appreciated.

Latest version is at
https://inbox.sourceware.org/gcc-patches/20230818031818.2161842-1-lipeng@intel.com/

> 
> > Best Regards,
> > Lipeng Zhu  
> 

Re: [PATCH v9 4/4] ree: Improve ree pass for rs6000 target using defined ABI interfaces

[Bernhard Reutner-Fischer]

On Wed, 25 Oct 2023 16:41:07 +0530
Ajit Agarwal  wrote:

> On 25/10/23 2:19 am, Vineet Gupta wrote:
> > On 10/24/23 13:36, rep.dot@gmail.com wrote:  
> >> As said, I don't see why the below was not cleaned up before the V1 
> >> submission.
> >> Iff it breaks when manually CSEing, I'm curious why?  
>  The function below looks identical in v12 of the patch.
>  Why didn't you use common subexpressions?
>  ba  
> >>> Using CSE here breaks aarch64 regressions hence I have reverted it back
> >>> not to use CSE,  
> >> Just for my own education, can you please paste your patch perusing common 
> >> subexpressions and an assembly diff of the failing versus working aarch64 
> >> testcase, along how you configured that failing (cross-?)compiler and the 
> >> command-line of a typical testcase that broke when manually CSEing the 
> >> function below?  
> > 
> > I was meaning to ask this before, but what exactly is the CSE issue, 
> > manually or whatever.

If nothing else it would hopefully improve the readability.

> >   
> Here is the abi interface where I CSE'D and got a mail from automated 
> regressions run that aarch64
> test fails.

We already concluded that this failure was obviously a hiccup on the
testers, no problem.

> +static inline bool
> +abi_extension_candidate_return_reg_p (int regno)
> +{
> +  return targetm.calls.function_value_regno_p (regno);
> +}

But i was referring to abi_extension_candidate_p :)

your v13 looks like this:

+static bool
+abi_extension_candidate_p (rtx_insn *insn)
+{
+  rtx set = single_set (insn);
+  machine_mode dst_mode = GET_MODE (SET_DEST (set));
+  rtx orig_src = XEXP (SET_SRC (set), 0);
+
+  if (!FUNCTION_ARG_REGNO_P (REGNO (orig_src))
+  || abi_extension_candidate_return_reg_p (REGNO (orig_src)))
+return false;
+
+  /* Return FALSE if mode of destination and source is same.  */
+  if (dst_mode == GET_MODE (orig_src))
+return false;
+
+  machine_mode mode = GET_MODE (XEXP (SET_SRC (set), 0));
+  bool promote_p = abi_target_promote_function_mode (mode);
+
+  /* Return FALSE if promote is false and REGNO of source and destination
+ is different.  */
+  if (!promote_p && REGNO (SET_DEST (set)) != REGNO (orig_src))
+return false;
+
+  return true;
+}

and i suppose it would be easier to read if phrased something like

static bool
abi_extension_candidate_p (rtx_insn *insn)
{
  rtx set = single_set (insn);
  rtx orig_src = XEXP (SET_SRC (set), 0);
  unsigned int src_regno = REGNO (orig_src);

  /* Not a function argument reg or is a function values return reg.  */
  if (!FUNCTION_ARG_REGNO_P (src_regno)
  || abi_extension_candidate_return_reg_p (src_regno))
return false;

  rtx dst = SET_DST (set);
  machine_mode src_mode = GET_MODE (orig_src);

  /* Return FALSE if mode of destination and source is the same.  */
  if (GET_MODE (dst) == src_mode)
return false;

  /* Return FALSE if the FIX THE COMMENT and REGNO of source and destination
 is different.  */
  if (!abi_target_promote_function_mode_p (src_mode)
  && REGNO (dst) != src_regno)
return false;

  return true;
}

so no, that's not exactly better.

Maybe just do what the function comment says (i did not check the "not
promoted" part, but you get the idea):

^L

/* Return TRUE if
   reg source operand is argument register and not return register,
   mode of source and destination operand are different,
   if not promoted REGNO of source and destination operand are the same.  */
static bool
abi_extension_candidate_p (rtx_insn *insn)
{
  rtx set = single_set (insn);
  rtx orig_src = XEXP (SET_SRC (set), 0);

  if (FUNCTION_ARG_REGNO_P (REGNO (orig_src))
  && !abi_extension_candidate_return_reg_p (REGNO (orig_src))
  && GET_MODE (SET_DST (set)) != GET_MODE (orig_src)
  && abi_target_promote_function_mode_p (GET_MODE (orig_src))
  && REGNO (SET_DST (set)) == REGNO (orig_src))
return true;

  return false;
}

I think this is much easier to actually read (and that's why good
function comments are important). In the end it's not important and
just personal preference.
Either way, I did not check the plausibility of the logic therein.

> 
> 
> I have not done any assembly diff as myself have not cross compiled with 
> aarch64.

fair enough.

Re: [PATCH v9 4/4] ree: Improve ree pass for rs6000 target using defined ABI interfaces

[Bernhard Reutner-Fischer]

On Mon, 23 Oct 2023 12:16:18 +0530
Ajit Agarwal  wrote:

> Hello All:
> 
> Addressed below review comments in the version 11 of the patch.
> Please review and please let me know if its ok for trunk.

s/satisified/satisfied/

> > As said, I don't see why the below was not cleaned up before the V1 
> > submission.
> > Iff it breaks when manually CSEing, I'm curious why?

The function below looks identical in v12 of the patch.
Why didn't you use common subexpressions?

> >   
> >>> +/* Return TRUE if reg source operand of zero_extend is argument registers
> >>> +   and not return registers and source and destination operand are same
> >>> +   and mode of source and destination operand are not same.  */
> >>> +
> >>> +static bool
> >>> +abi_extension_candidate_p (rtx_insn *insn)
> >>> +{
> >>> +  rtx set = single_set (insn);
> >>> +  machine_mode dst_mode = GET_MODE (SET_DEST (set));
> >>> +  rtx orig_src = XEXP (SET_SRC (set), 0);
> >>> +
> >>> +  if (!FUNCTION_ARG_REGNO_P (REGNO (orig_src))
> >>> +  || abi_extension_candidate_return_reg_p (/*insn,*/ REGNO 
> >>> (orig_src)))  
> >>> +return false;
> >>> +
> >>> +  /* Mode of destination and source should be different.  */
> >>> +  if (dst_mode == GET_MODE (orig_src))
> >>> +return false;
> >>> +
> >>> +  machine_mode mode = GET_MODE (XEXP (SET_SRC (set), 0));
> >>> +  bool promote_p = abi_target_promote_function_mode (mode);
> >>> +
> >>> +  /* REGNO of source and destination should be same if not
> >>> +  promoted.  */
> >>> +  if (!promote_p && REGNO (SET_DEST (set)) != REGNO (orig_src))
> >>> +return false;
> >>> +
> >>> +  return true;
> >>> +}
> >>> +  


> > 
> > As said, please also rephrase the above (and everything else if it 
> > obviously looks akin the above).

thanks

Re: [PATCH] remove workaround for GCC 4.1-4.3

[Bernhard Reutner-Fischer]

On 27 September 2023 06:46:29 CEST, Bernhard Reutner-Fischer 
 wrote:
>On 27 September 2023 06:43:24 CEST, Jakub Jelinek  wrote:
>>Hi!
>>
>>While looking into vec.h, I've noticed we still have a workaround for
>>GCC 4.1-4.3 bugs.
>
>
>This is https://gcc.gnu.org/PR105656
>thanks,

Mere cosmetics, but just for consistency:
I think you fat-fingered the number.
Since I would not suggest to backport this, should I close this reminder PR 
with a manually crafted commit link, or is there a preferred, other way to 
adjust the commited PR reference (also for the typoed PR which got the 
unrelated commit associated) and close the PR?

thanks,

>
>>As we now use C++11 and thus need to be built by GCC 4.8 or later,
>>I think this is now never used.
>>
>>Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>>
>>2023-09-27  Jakub Jelinek  
>>
>>  * system.h (BROKEN_VALUE_INITIALIZATION): Don't define.
>>  * vec.h (vec_default_construct): Remove BROKEN_VALUE_INITIALIZATION
>>  workaround.
>>  * function.cc (assign_parm_find_data_types): Likewise.
>>
>>--- gcc/system.h.jj   2023-04-22 20:14:03.502203388 +0200
>>+++ gcc/system.h  2023-09-26 16:41:44.384204843 +0200
>>@@ -905,12 +905,6 @@ extern void fancy_abort (const char *, i
>> /* Some compilers do not allow the use of unsigned char in bitfields.  */
>> #define BOOL_BITFIELD unsigned int
>> 
>>-/* GCC older than 4.4 have broken C++ value initialization handling, see
>>-   PR11309, PR30111, PR33916, PR82939 and PR84405 for more details.  */
>>-#if GCC_VERSION > 0 && GCC_VERSION < 4004 && !defined(__clang__)
>>-# define BROKEN_VALUE_INITIALIZATION
>>-#endif
>>-
>> /* As the last action in this file, we poison the identifiers that
>>shouldn't be used.  Note, luckily gcc-3.0's token-based integrated
>>preprocessor won't trip on poisoned identifiers that arrive from
>>--- gcc/vec.h.jj  2023-07-11 13:40:40.392430080 +0200
>>+++ gcc/vec.h 2023-09-26 16:44:30.637902359 +0200
>>@@ -512,21 +512,6 @@ template 
>> inline void
>> vec_default_construct (T *dst, unsigned n)
>> {
>>-#ifdef BROKEN_VALUE_INITIALIZATION
>>-  /* Versions of GCC before 4.4 sometimes leave certain objects
>>- uninitialized when value initialized, though if the type has
>>- user defined default ctor, that ctor is invoked.  As a workaround
>>- perform clearing first and then the value initialization, which
>>- fixes the case when value initialization doesn't initialize due to
>>- the bugs and should initialize to all zeros, but still allows
>>- vectors for types with user defined default ctor that initializes
>>- some or all elements to non-zero.  If T has no user defined
>>- default ctor and some non-static data members have user defined
>>- default ctors that initialize to non-zero the workaround will
>>- still not work properly; in that case we just need to provide
>>- user defined default ctor.  */
>>-  memset (dst, '\0', sizeof (T) * n);
>>-#endif
>>   for ( ; n; ++dst, --n)
>> ::new (static_cast(dst)) T ();
>> }
>>--- gcc/function.cc.jj2023-07-11 13:40:38.992448821 +0200
>>+++ gcc/function.cc   2023-09-26 16:44:54.865567722 +0200
>>@@ -2429,15 +2429,7 @@ assign_parm_find_data_types (struct assi
>> {
>>   int unsignedp;
>> 
>>-#ifndef BROKEN_VALUE_INITIALIZATION
>>   *data = assign_parm_data_one ();
>>-#else
>>-  /* Old versions of GCC used to miscompile the above by only initializing
>>- the members with explicit constructors and copying garbage
>>- to the other members.  */
>>-  assign_parm_data_one zero_data = {};
>>-  *data = zero_data;
>>-#endif
>> 
>>   /* NAMED_ARG is a misnomer.  We really mean 'non-variadic'. */
>>   if (!cfun->stdarg)
>>
>>  Jakub
>>
>

Re: [PATCH] remove workaround for GCC 4.1-4.3

[Bernhard Reutner-Fischer]

On 27 September 2023 06:43:24 CEST, Jakub Jelinek  wrote:
>Hi!
>
>While looking into vec.h, I've noticed we still have a workaround for
>GCC 4.1-4.3 bugs.


This is https://gcc.gnu.org/PR105656
thanks,

>As we now use C++11 and thus need to be built by GCC 4.8 or later,
>I think this is now never used.
>
>Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
>2023-09-27  Jakub Jelinek  
>
>   * system.h (BROKEN_VALUE_INITIALIZATION): Don't define.
>   * vec.h (vec_default_construct): Remove BROKEN_VALUE_INITIALIZATION
>   workaround.
>   * function.cc (assign_parm_find_data_types): Likewise.
>
>--- gcc/system.h.jj2023-04-22 20:14:03.502203388 +0200
>+++ gcc/system.h   2023-09-26 16:41:44.384204843 +0200
>@@ -905,12 +905,6 @@ extern void fancy_abort (const char *, i
> /* Some compilers do not allow the use of unsigned char in bitfields.  */
> #define BOOL_BITFIELD unsigned int
> 
>-/* GCC older than 4.4 have broken C++ value initialization handling, see
>-   PR11309, PR30111, PR33916, PR82939 and PR84405 for more details.  */
>-#if GCC_VERSION > 0 && GCC_VERSION < 4004 && !defined(__clang__)
>-# define BROKEN_VALUE_INITIALIZATION
>-#endif
>-
> /* As the last action in this file, we poison the identifiers that
>shouldn't be used.  Note, luckily gcc-3.0's token-based integrated
>preprocessor won't trip on poisoned identifiers that arrive from
>--- gcc/vec.h.jj   2023-07-11 13:40:40.392430080 +0200
>+++ gcc/vec.h  2023-09-26 16:44:30.637902359 +0200
>@@ -512,21 +512,6 @@ template 
> inline void
> vec_default_construct (T *dst, unsigned n)
> {
>-#ifdef BROKEN_VALUE_INITIALIZATION
>-  /* Versions of GCC before 4.4 sometimes leave certain objects
>- uninitialized when value initialized, though if the type has
>- user defined default ctor, that ctor is invoked.  As a workaround
>- perform clearing first and then the value initialization, which
>- fixes the case when value initialization doesn't initialize due to
>- the bugs and should initialize to all zeros, but still allows
>- vectors for types with user defined default ctor that initializes
>- some or all elements to non-zero.  If T has no user defined
>- default ctor and some non-static data members have user defined
>- default ctors that initialize to non-zero the workaround will
>- still not work properly; in that case we just need to provide
>- user defined default ctor.  */
>-  memset (dst, '\0', sizeof (T) * n);
>-#endif
>   for ( ; n; ++dst, --n)
> ::new (static_cast(dst)) T ();
> }
>--- gcc/function.cc.jj 2023-07-11 13:40:38.992448821 +0200
>+++ gcc/function.cc2023-09-26 16:44:54.865567722 +0200
>@@ -2429,15 +2429,7 @@ assign_parm_find_data_types (struct assi
> {
>   int unsignedp;
> 
>-#ifndef BROKEN_VALUE_INITIALIZATION
>   *data = assign_parm_data_one ();
>-#else
>-  /* Old versions of GCC used to miscompile the above by only initializing
>- the members with explicit constructors and copying garbage
>- to the other members.  */
>-  assign_parm_data_one zero_data = {};
>-  *data = zero_data;
>-#endif
> 
>   /* NAMED_ARG is a misnomer.  We really mean 'non-variadic'. */
>   if (!cfun->stdarg)
>
>   Jakub
>

Re: [PATCH] vect, omp: inbranch simdclone dropping const

[Bernhard Reutner-Fischer]

On 26 September 2023 23:02:10 CEST, "Andre Vieira (lists)" 
 wrote:
>
>
>On 26/09/2023 21:26, Bernhard Reutner-Fischer wrote:
>> On 26 September 2023 18:46:11 CEST, Tobias Burnus  
>> wrote:
>>> On 26.09.23 18:37, Andrew Stubbs wrote:
>>>> If the fall-through is deliberate please add a /* FALLTHROUGH */
>>>> comment (or whatever spelling disables the warning).
>>> 

>
>I was surprised my bootstrap didn't catch this, I thought we generated 
>warnings in such cases and bootstrap builds with -Werror does it not?

Well, I wouldn't see much benefit to warn in this case, no?
You're falling through to a break, not other "active" code AFAICS?

You had:

references->safe_push (ref);
return false;
+ case IFN_MASK_CALL:
+   i = 1;
  default:
break;
  }

I would not have expected a warning here, TBH :-)
thanks,

Re: [PATCH] vect, omp: inbranch simdclone dropping const

[Bernhard Reutner-Fischer]

On 26 September 2023 18:46:11 CEST, Tobias Burnus  
wrote:
>On 26.09.23 18:37, Andrew Stubbs wrote:
>> If the fall-through is deliberate please add a /* FALLTHROUGH */
>> comment (or whatever spelling disables the warning).
>
>It's: gcc_fallthrough ();
>
>Which gets converted to "__attribute__((fallthrough))"; it could also
>expand to "[[fallthrough]]" but that's C++17 (and, also, an C23 feature
>- albeit so far unimplemented in gcc).

OT
IIRC we do parse comments for a number of spellings of the hint by the user 
that the fallthrough is deliberate:

https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html

See the numerous levels of -Wimplicit-fallthrough=n, the default being 3.

---8<---
-Wimplicit-fallthrough=3 case sensitively matches one of the following regular 
expressions:
-fallthrough
@fallthrough@
lint -fallthrough[ \t]*
[ \t.!]*(ELSE,? |INTENTIONAL(LY)? )?
FALL(S | |-)?THR(OUGH|U)[ \t.!]*(-[^\n\r]*)?
[ \t.!]*(Else,? |Intentional(ly)? )?
Fall((s | |-)[Tt]|t)hr(ough|u)[ \t.!]*(-[^\n\r]*)?
[ \t.!]*([Ee]lse,? |[Ii]ntentional(ly)? )?
fall(s | |-)?thr(ough|u)[ \t.!]*(-[^\n\r]*)?
---8<---

Just FWIW.
thanks,

Re: [PATCH 01/12] [contrib] validate_failures.py: Avoid testsuite aliasing

[Bernhard Reutner-Fischer]

Hi Maxim!

On Mon, 5 Jun 2023 18:06:25 +0400
Maxim Kuvyrkov via Gcc-patches  wrote:

> > On Jun 3, 2023, at 19:17, Jeff Law  wrote:
> > 
> > On 6/2/23 09:20, Maxim Kuvyrkov via Gcc-patches wrote:  
> >> This patch adds tracking of current testsuite "tool" and "exp"
> >> to the processing of .sum files.  This avoids aliasing between
> >> tests from different testsuites with same name+description.
> >> E.g., this is necessary for testsuite/c-c++-common, which is ran
> >> for both gcc and g++ "tools".
> >> This patch changes manifest format from ...
> >> 
> >> FAIL: gcc_test
> >> FAIL: g++_test
> >> 
> >> ... to ...
> >> 
> >> === gcc tests ===
> >> Running gcc/foo.exp ...
> >> FAIL: gcc_test
> >> === gcc Summary ==
> >> === g++ tests ===
> >> Running g++/bar.exp ...
> >> FAIL: g++_test
> >> === g++ Summary ==
> >> .
> >> The new format uses same formatting as DejaGnu's .sum files
> >> to specify which "tool" and "exp" the test belongs to.  
> > I think the series is fine.  You're not likely to hear from Diego or Doug I 
> > suspect, I don't think either are involved in GNU stuff anymore.
> >   
> 
> Thanks, Jeff.  I'll wait for a couple of days and will merge if there are no 
> new comments.

Maxim, may i ask you to have a look at the following problem, please?

ISTM that your exp code does not work as expected for go, maybe you
forgot to test the changes with go enabled?

Ever since your changes in summer i see the following:

gcc-14.mine$ 
/scratch/src/gcc-14.mine/contrib/testsuite-management/validate_failures.py 
--clean_build ../gcc-14.orig/
Getting actual results from build directory .
./gcc/testsuite/go/go.sum
./gcc/testsuite/gcc/gcc.sum
./gcc/testsuite/objc/objc.sum
./gcc/testsuite/jit/jit.sum
./gcc/testsuite/gdc/gdc.sum
./gcc/testsuite/gnat/gnat.sum
./gcc/testsuite/ada/acats/acats.sum
./gcc/testsuite/g++/g++.sum
./gcc/testsuite/obj-c++/obj-c++.sum
./gcc/testsuite/rust/rust.sum
./gcc/testsuite/gfortran/gfortran.sum
./x86_64-pc-linux-gnu/libgomp/testsuite/libgomp.sum
./x86_64-pc-linux-gnu/libphobos/testsuite/libphobos.sum
./x86_64-pc-linux-gnu/libstdc++-v3/testsuite/libstdc++.sum
./x86_64-pc-linux-gnu/libffi/testsuite/libffi.sum
./x86_64-pc-linux-gnu/libitm/testsuite/libitm.sum
./x86_64-pc-linux-gnu/libgo/libgo.sum
./x86_64-pc-linux-gnu/libatomic/testsuite/libatomic.sum
./gotools/gotools.sum
.sum file seems to be broken: tool="gotools", exp="None", summary_line="FAIL: 
TestScript"
Traceback (most recent call last):
  File 
"/scratch/src/gcc-14.mine/contrib/testsuite-management/validate_failures.py", 
line 732, in 
retval = Main(sys.argv)
  File 
"/scratch/src/gcc-14.mine/contrib/testsuite-management/validate_failures.py", 
line 721, in Main
retval = CompareBuilds()
  File 
"/scratch/src/gcc-14.mine/contrib/testsuite-management/validate_failures.py", 
line 622, in CompareBuilds
actual = GetResults(sum_files)
  File 
"/scratch/src/gcc-14.mine/contrib/testsuite-management/validate_failures.py", 
line 466, in GetResults
build_results.update(ParseSummary(sum_fname))
  File 
"/scratch/src/gcc-14.mine/contrib/testsuite-management/validate_failures.py", 
line 405, in ParseSummary
result = result_set.MakeTestResult(line, ordinal)
  File 
"/scratch/src/gcc-14.mine/contrib/testsuite-management/validate_failures.py", 
line 239, in MakeTestResult
return TestResult(summary_line, ordinal,
  File 
"/scratch/src/gcc-14.mine/contrib/testsuite-management/validate_failures.py", 
line 151, in __init__
raise
RuntimeError: No active exception to reraise


The problem seems to be that gotools.sum does not mention any ".exp"
files.

$ grep "Running " gotools/gotools.sum 
Running cmd/go
Running runtime
Running cgo
Running carchive
Running cmd/vet
Running embed
$ grep -c "\.exp" gotools/gotools.sum 
0

The .sum files looks like this:
---8<---
Test Run By foo on Tue Sep 26 14:46:48 CEST 2023
Native configuration is x86_64-foo-linux-gnu

=== gotools tests ===

Running cmd/go
UNTESTED: TestAccidentalGitCheckout
PASS: TestAlwaysLinkSysoFiles
...
UNTESTED: TestParallelTest
FAIL: TestScript
...
---8<---

May i ask you to have a look, please?

TIA,

Re: [PATCH 8/8] OpenMP: Fortran "!$omp declare mapper" support

[Bernhard Reutner-Fischer]

On 18 September 2023 12:19:17 CEST, Julian Brown  
wrote:
>On Thu, 14 Sep 2023 17:13:02 +0200
>Bernhard Reutner-Fischer via Gcc-patches 
>wrote:
>
>> On Tue, 5 Sep 2023 12:28:28 -0700
>> Julian Brown  wrote:
>> 
>> > +  static bool
>> > +  equal (const omp_name_type ,
>> > +   const omp_name_type )
>> > +  {
>> > +if (a.name == NULL_TREE && b.name == NULL_TREE)
>> > +  return a.type == b.type;  
>> 
>> I'm curious if (and why) the type comparison above is safe and does
>> not use gfc_compare_types () ?
>> 
>> thanks,
>
>Probably ignorance on my part! It works for (derived, class) types which
>are canonicalized to exactly the same gfc_typespec, but you're likely
>right that a more Fortran-ish notion of type equality should be used
>here instead when comparing "declare mapper"s.

Sounds like a word2vec question.

>
>Or maybe using gfc_compare_types would smush too many types together
>into one? E.g. if b.type is an extension of a.type, do we want those
>types to be able to have separate mappers?

I fear this really depends.

>
>I'll have a look at addressing this when it's time to reroll these
>patches.
>
>Thanks,

TIA,

PS: I'm not thrilled about those recent get_identifier("") as temporary 
additions fed into the hasher. I know it's not funny, but please let's avoid 
that. Said the cat.

>
>Julian

Re: [PATCH 8/8] OpenMP: Fortran "!$omp declare mapper" support

[Bernhard Reutner-Fischer via Gcc-patches]

On Tue, 5 Sep 2023 12:28:28 -0700
Julian Brown  wrote:

> +  static bool
> +  equal (const omp_name_type ,
> +  const omp_name_type )
> +  {
> +if (a.name == NULL_TREE && b.name == NULL_TREE)
> +  return a.type == b.type;

I'm curious if (and why) the type comparison above is safe and does not
use gfc_compare_types () ?

thanks,

> +else if (a.name == NULL_TREE || b.name == NULL_TREE)
> +  return false;
> +else
> +  return a.name == b.name && gfc_compare_types (a.type, b.type);
> +  }

Re: [PATCH V6] VECT: Apply LEN_MASK_{LOAD,STORE} into vectorizer

[Bernhard Reutner-Fischer via Gcc-patches]

On 23 June 2023 10:03:45 CEST, Richard Sandiford  
wrote:

>> Fuse the block below into the one above as the condition seems to be 
>> identical?
>
>Yeah, true, but I think the idea is that the code above “Arguments are
>ready” is calculating argument values, and the code after it is creating
>code.  These are two separate steps, and the fact that the two final_len
>blocks end up being consecutive is something of a coincidence.
>
>So personally I think we should keep the structure in the patch.

Sure, works for me.
thanks,

Re: [PATCH V6] VECT: Apply LEN_MASK_{LOAD,STORE} into vectorizer

[Bernhard Reutner-Fischer via Gcc-patches]

On 23 June 2023 01:51:12 CEST, juzhe.zh...@rivai.ai wrote:
>From: Ju-Zhe Zhong 

I am sorry but I somehow overlooked a trivial spot in V5.
Nit which does not warrant an immediate next version, but please consider it 
before pushing iff approved:

>+if (final_len)
>+  {
>+signed char biasval
>+  = LOOP_VINFO_PARTIAL_LOAD_STORE_BIAS (loop_vinfo);
>+
>+bias = build_int_cst (intQI_type_node, biasval);
>+  }
>+
>+/* Arguments are ready.  Create the new vector stmt.  */
>+if (final_len)
>+  {

Fuse the block below into the one above as the condition seems to be identical?
thanks,

>+gcall *call;
> tree ptr = build_int_cst (ref_type, align * BITS_PER_UNIT);
> /* Need conversion if it's wrapped with VnQI.  */
> if (vmode != new_vmode)

Re: [PATCH] Introduce hardbool attribute for C

[Bernhard Reutner-Fischer via Gcc-patches]

On Wed, 21 Jun 2023 22:08:55 -0300
Alexandre Oliva  wrote:

> Thanks for the test.
> 
> Did you mean for me to incorporate it into the patch, or do you mean to
> contribute it separately, if the feature happens to be accepted?

These were your tests that i quoted but i or my MUA botched to add one
level of quotes -- sorry for that.

> 
> On Jun 19, 2023, Bernhard Reutner-Fischer  wrote:
> 
> > I don't see explicit tests with _Complex nor __complex__. Would we
> > want to check these here, or are they handled thought the "underlying"
> > tests above?  
> 
> Good question.  The notion of using complex types to hold booleans
> hadn't even crossed my mind.

Maybe it is not real, it just sparkled through somehow.

> On the one hand, there doesn't seem to be reason to rule them out, and
> that could go for literally any other type.
> 
> On the other, there doesn't seem to be any useful case for them.  Can
> anyone think of one?

We could either not reject other such uses and wait or we could reject
them and equally wait for complaints. I would not dare to bet who pops
up first, fuzzers or users, though arguments of the latter would
probably be interesting.. I don't have an opinion (nor a use-case),
really, it was just a thought (i mentioned tinfoil hat, did i ;).

> 
> > I'd welcome a fortran interop note in the docs  
> 
> Is there any good place for such interop notes?  I'm not sure I'm
> best-suited to write them up, since Fortran is not a language I'm
> very familiar with, but I suppose I could give it a try.
> 

I'd append to your extend.texi hunk below the para about uninitialized a
note to the effect of:
Note: Types annotated with this attribute may not be Fortran
interoperable.

I would not go into too much detail about C_BOOL nor LOGICAL for i
reckon anybody sensibilised to either two of that attribute, C and
Fortran will draw her conclusions.
Didn't really think how easy it would be to handle this on the user
side, but i fear the modern iso_c_binding way would need help from the
compiler for the lazy. I'd expect a user to be able to trivially
translate this in wrappers done the old way though, which is a pity
from an educational and modernisation POV. Didn't look closely, so this
guesstimate might be all wrong, of course.

thanks,

Re: [Patch, fortran] PR107900 Select type with intrinsic type inside associate causes ICE / Segmenation fault

[Bernhard Reutner-Fischer via Gcc-patches]

Hi!

First of all, many thanks for the patch!
If i may, i have a question concerning the chosen style in the error
message and one nitpick concerning a return type though, the latter
primarily prompting this reply.

On Tue, 20 Jun 2023 11:54:25 +0100
Paul Richard Thomas via Fortran  wrote:

> diff --git a/gcc/fortran/expr.cc b/gcc/fortran/expr.cc
> index d5cfbe0cc55..c960dfeabd9 100644
> --- a/gcc/fortran/expr.cc
> +++ b/gcc/fortran/expr.cc

> @@ -6470,6 +6480,22 @@ gfc_check_vardef_context (gfc_expr* e, bool pointer, 
> bool alloc_obj,
>   }
> return false;
>   }
> +  else if (context && gfc_is_ptr_fcn (assoc->target))
> + {
> +   if (!gfc_notify_std (GFC_STD_F2018, "%qs at %L associated to "
> +"pointer function target being used in a "
> +"variable definition context (%s)", name,
> +>where, context))

I'm curious why you decided to put context in braces and not simply use
quotes as per %qs?

> + return false;
> +   else if (gfc_has_vector_index (e))
> + {
> +   gfc_error ("%qs at %L associated to vector-indexed target"
> +  " cannot be used in a variable definition"
> +  " context (%s)",
> +  name, >where, context);

Ditto.

> diff --git a/gcc/fortran/match.cc b/gcc/fortran/match.cc
> index e7be7fddc64..0e4b5440393 100644
> --- a/gcc/fortran/match.cc
> +++ b/gcc/fortran/match.cc
> @@ -6377,6 +6377,39 @@ build_class_sym:
>  }
> 
> 
> +/* Build the associate name  */
> +static int
> +build_associate_name (const char *name, gfc_expr **e1, gfc_expr **e2)
> +{

> +return 1;

> +  return 0;
> +}

I've gone through the frontend recently and changed several such
boolean functions to use bool where appropriate. May i ask folks to use
narrower types in new code, please?
Iff later in the pipeline it is considered appropriate or benefical to
promote types, these will eventually be promoted.

> diff --git a/gcc/fortran/trans-decl.cc b/gcc/fortran/trans-decl.cc
> index e6a4337c0d2..18589e17843 100644
> --- a/gcc/fortran/trans-decl.cc
> +++ b/gcc/fortran/trans-decl.cc

> @@ -1906,6 +1915,7 @@ gfc_get_symbol_decl (gfc_symbol * sym)
>   gcc_assert (!sym->value || sym->value->expr_type == EXPR_NULL);
>  }
> 
> +

ISTM that the addition of vertical whitespace like here is in
contradiction with the coding style.

Please kindly excuse my comment and, again, thanks!

>gfc_finish_var_decl (decl, sym);
> 
>if (sym->ts.type == BT_CHARACTER)

Re: [PATCH] Introduce hardbool attribute for C

[Bernhard Reutner-Fischer via Gcc-patches]

On 16 June 2023 07:35:27 CEST, Alexandre Oliva via Gcc-patches 
 wrote:

index 0..634feaed4deef
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/hardbool-err.c
@@ -0,0 +1,28 @@
+/* { dg-do compile } */
+/* { dg-options "" } */
+
+typedef _Bool __attribute__ ((__hardbool__))
+hbbl; /* { dg-error "integral types" } */
+
+typedef double __attribute__ ((__hardbool__))
+hbdbl; /* { dg-error "integral types" } */
+
+enum x;
+typedef enum x __attribute__ ((__hardbool__))
+hbenum; /* { dg-error "integral types" } */
+
+struct s;
+typedef struct s __attribute__ ((__hardbool__))
+hbstruct; /* { dg-error "integral types" } */
+
+typedef int __attribute__ ((__hardbool__ (0, 0)))
+hb00; /* { dg-error "different values" } */
+
+typedef int __attribute__ ((__hardbool__ (4, 16))) hb4x;
+struct s {
+ hb4x m:2;
+}; /* { dg-error "is a GCC extension|different values" } */
+/* { dg-warning "changes value" "warning" { target *-*-* } .-1 } */
+
+hb4x __attribute__ ((vector_size (4 * sizeof (hb4x
+vvar; /* { dg-error "invalid vector type" } */

Arm-chair, tinfoil hat still on, didn't look closely, hence:

I don't see explicit tests with _Complex nor __complex__. Would we want to 
check these here, or are they handled thought the "underlying" tests above?

I'd welcome a fortran interop note in the docs as hinted previously to cover 
out of the box behavior. It's probably reasonably unlikely but better be safe 
than sorry?
cheers,

Re: [PATCH] ipa: Self-DCE of uses of removed call LHSs (PR 108007)

[Bernhard Reutner-Fischer via Gcc-patches]

On 13 June 2023 17:11:13 CEST, Martin Jambor  wrote:
>Ping.

s/funtction/function/
s/runing/running/
>
>Thanks,

Re: [i386 PATCH] A minor code clean-up: Use NULL_RTX instead of nullptr

[Bernhard Reutner-Fischer via Gcc-patches]

plonk.

On 26 May 2023 10:31:51 CEST, Bernhard Reutner-Fischer  
wrote:
>On Thu, 25 May 2023 18:58:04 +0200
>Bernhard Reutner-Fischer  wrote:
>
>> On Wed, 24 May 2023 18:54:06 +0100
>> "Roger Sayle"  wrote:
>> 
>> > My understanding is that GCC's preferred null value for rtx is NULL_RTX
>> > (and for tree is NULL_TREE), and by being typed allows strict type 
>> > checking,
>> > and use with function polymorphism and template instantiation.
>> > C++'s nullptr is preferred over NULL and 0 for pointer types that don't
>> > have a defined null of the correct type.
>> > 
>> > This minor clean-up uses NULL_RTX consistently in i386-expand.cc.  
>> 
>> Oh. Well, i can't resist cleanups :)
>
>> (and handle nullptr too, and the same game for tree)
>
>so like the attached. And
>sed -e 's/RTX/TREE/g' -e 's/rtx/tree/g' \
>  < ~/coccinelle/gcc-rtx-null.0.cocci \
>  > ~/coccinelle/gcc-tree-null.0.cocci
>
>I do not know if we want to shorten explicit NULL comparisons.
> foo == NULL => !foo and foo != NULL => foo
>Left them alone in the form they were written.
>
>See the attached result of the rtx hunks, someone would have to build

I've bootstrapped and regtested the hunks for rtx as cited up-thread without 
regressions (as expected).

I know everybody is busy, but I'd like to know if I should swap these out 
completely,   or postpone this until start of stage3 or next stage 1 or 
something.
I can easily keep these local to my personal pre-configure stage for my own 
amusement.

thanks,

>it and hack git-commit-mklog.py --changelog 'Use NULL_RTX.'
>to print("{}.".format(random.choice(['Ditto', 'Same', 'Likewise']))) ;)
>
>> 
>> Just a thought..
>
>cheers,

Re: Splitting up 27_io/basic_istream/ignore/wchar_t/94749.cc (takes too long)

[Bernhard Reutner-Fischer via Gcc-patches]

On Sat, 10 Jun 2023 11:29:36 -0700
Mike Stump  wrote:

> On Jun 9, 2023, at 2:47 PM, Bernhard Reutner-Fischer
>  wrote:

> > But well. Either way, what
> > should we do about remote env, if there is one? If the target
> > supports it, send it and skip otherwise?  

> So, to focus a
> conversation, which target, which host, canadian? Which part of the
> environment? What part is missing you want to fix? Want to unify
> between targets... and so on.
> 

The most recent target where this came up again was GCN i think.
See the last block in
https://inbox.sourceware.org/gcc-patches/20230508195217.4897009f@nbbrfq/
and Thomas' reference therein to Tobias'
https://inbox.sourceware.org/gcc-patches/018bcdeb-b3bb-1859-cd0b-a8a92e26d...@codesourcery.com/

thoughts?

thanks,

Re: Splitting up 27_io/basic_istream/ignore/wchar_t/94749.cc (takes too long)

[Bernhard Reutner-Fischer via Gcc-patches]

On 9 June 2023 19:18:45 CEST, Mike Stump via Gcc-patches 
 wrote:
> simulation ports.  Maybe a 20-100x speedup? If you want to go this way I'd 
> say do it in python at the bottom as it would be nice to switch over to 
> python in the next 5-20 years and away from tcl.

Yes, i guess we have all pondered this for way long enough, but it is a lot of 
work still.

The nice side effect would be that we see such hogs easier and earlier, at 
least more comfortable. But well. Either way, what should we do about remote 
env, if there is one? If the target supports it, send it and skip otherwise?

thanks,

Re: [PATCH] libatomic: x86_64: Always try ifunc

[Bernhard Reutner-Fischer via Gcc-patches]

On 3 June 2023 15:46:02 CEST, Xi Ruoyao  wrote:

>Unfortunately __builtin_cpu_is performs CPU detection on runtime, not
>compile time.

Right, you were talking about configure, sorry.

Re: [PATCH] libatomic: x86_64: Always try ifunc

[Bernhard Reutner-Fischer via Gcc-patches]

On 3 June 2023 13:25:32 CEST, Xi Ruoyao via Gcc-patches 
 wrote:

>There seems no good way to check if the CPU is Intel or AMD from
>the built-in macros (maybe we can check every known model like __skylake,
>__bdver2, ..., but it will be very error-prune and require an update
>whenever we add the support for a new x86 model).  The best thing we can
>do seems "always try ifunc" here.

IIRC there is __builtin_cpu_is (after initialisation) -- A couple of days ago, 
we wondered if it would be handy to lower that even in fortran without going 
through C, so i am pretty sure I don't make that up.. ;-)

Just a thought,

Re: [PATCH 04/14] c++: use _P() defines from tree.h

[Bernhard Reutner-Fischer via Gcc-patches]

Hi David, Patrick,

On Thu, 1 Jun 2023 18:33:46 +0200
Bernhard Reutner-Fischer  wrote:

> On Thu, 1 Jun 2023 11:24:06 -0400
> Patrick Palka  wrote:
> 
> > On Sat, May 13, 2023 at 7:26 PM Bernhard Reutner-Fischer via
> > Gcc-patches  wrote:  
> 
> > > diff --git a/gcc/cp/tree.cc b/gcc/cp/tree.cc
> > > index 131b212ff73..19dfb3ed782 100644
> > > --- a/gcc/cp/tree.cc
> > > +++ b/gcc/cp/tree.cc
> > > @@ -1173,7 +1173,7 @@ build_cplus_array_type (tree elt_type, tree 
> > > index_type, int dependent)
> > >  }
> > >
> > >/* Avoid spurious warnings with VLAs (c++/54583).  */
> > > -  if (TYPE_SIZE (t) && EXPR_P (TYPE_SIZE (t)))
> > > +  if (CAN_HAVE_LOCATION_P (TYPE_SIZE (t)))
> > 
> > Hmm, this change seems undesirable...  
> 
> mhm, yes that is misleading. I'll prepare a patch to revert this.
> Let me have a look if there were other such CAN_HAVE_LOCATION_P changes
> that we'd want to revert.

Sorry for that!
I'd revert the hunk above and the one in gcc-rich-location.cc
(maybe_range_label_for_tree_type_mismatch::get_text), please see
attached. Bootstrap running, ok for trunk if it passes?

thanks,
>From 322bce380144b5199cca5775f7a3f0fb30a219ae Mon Sep 17 00:00:00 2001
From: Bernhard Reutner-Fischer 
Date: Thu, 1 Jun 2023 19:44:19 +0200
Subject: [PATCH] c++, analyzer: Expand CAN_HAVE_LOCATION_P macro.

r14-985-gca2007a9bb3074 used the collapsed macro definition
CAN_HAVE_LOCATION_P in gcc-rich-location.cc and r14-977-g8861c80733da5c
in c++'s build_cplus_array_type ().
However, although otherwise correct, the usage of CAN_HAVE_LOCATION_P
in these two spots is misleading, so this patch reverts aforementioned
two hunks.

gcc/cp/ChangeLog:

* tree.cc (build_cplus_array_type): Revert using the macro
CAN_HAVE_LOCATION_P.

gcc/ChangeLog:

* gcc-rich-location.cc 
(maybe_range_label_for_tree_type_mismatch::get_text):
Revert using the macro CAN_HAVE_LOCATION_P.
---
 gcc/cp/tree.cc   | 2 +-
 gcc/gcc-rich-location.cc | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/cp/tree.cc b/gcc/cp/tree.cc
index 19dfb3ed782..9363166152a 100644
--- a/gcc/cp/tree.cc
+++ b/gcc/cp/tree.cc
@@ -1173,7 +1173,7 @@ build_cplus_array_type (tree elt_type, tree index_type, 
int dependent)
 }
 
   /* Avoid spurious warnings with VLAs (c++/54583).  */
-  if (CAN_HAVE_LOCATION_P (TYPE_SIZE (t)))
+  if (TYPE_SIZE (t) && EXPR_P (TYPE_SIZE (t)))
 suppress_warning (TYPE_SIZE (t), OPT_Wunused);
 
   /* Push these needs up to the ARRAY_TYPE so that initialization takes
diff --git a/gcc/gcc-rich-location.cc b/gcc/gcc-rich-location.cc
index edecf07f81e..d02a5144cc6 100644
--- a/gcc/gcc-rich-location.cc
+++ b/gcc/gcc-rich-location.cc
@@ -200,7 +200,7 @@ maybe_range_label_for_tree_type_mismatch::get_text 
(unsigned range_idx) const
   tree expr_type = TREE_TYPE (m_expr);
 
   tree other_type = NULL_TREE;
-  if (CAN_HAVE_LOCATION_P (m_other_expr))
+  if (m_other_expr && EXPR_P (m_other_expr))
 other_type = TREE_TYPE (m_other_expr);
 
   range_label_for_type_mismatch inner (expr_type, other_type);
-- 
2.30.2

Re: [PATCH 04/14] c++: use _P() defines from tree.h

[Bernhard Reutner-Fischer via Gcc-patches]

On Thu, 1 Jun 2023 11:24:06 -0400
Patrick Palka  wrote:

> On Sat, May 13, 2023 at 7:26 PM Bernhard Reutner-Fischer via
> Gcc-patches  wrote:

> > diff --git a/gcc/cp/tree.cc b/gcc/cp/tree.cc
> > index 131b212ff73..19dfb3ed782 100644
> > --- a/gcc/cp/tree.cc
> > +++ b/gcc/cp/tree.cc
> > @@ -1173,7 +1173,7 @@ build_cplus_array_type (tree elt_type, tree 
> > index_type, int dependent)
> >  }
> >
> >/* Avoid spurious warnings with VLAs (c++/54583).  */
> > -  if (TYPE_SIZE (t) && EXPR_P (TYPE_SIZE (t)))
> > +  if (CAN_HAVE_LOCATION_P (TYPE_SIZE (t)))  
> 
> Hmm, this change seems undesirable...

mhm, yes that is misleading. I'll prepare a patch to revert this.
Let me have a look if there were other such CAN_HAVE_LOCATION_P changes
that we'd want to revert.

thanks,

Re: [PATCH v5] tree-ssa-sink: Improve code sinking pass

[Bernhard Reutner-Fischer via Gcc-patches]

On 1 June 2023 09:20:08 CEST, Ajit Agarwal  wrote:
>Hello All:
>
>This patch improves code sinking pass to sink statements before call to reduce
>register pressure.
>Review comments are incorporated.

Hi Ajit!

I had two comments for v4 that you did not address in v5 or followed up.
thanks,

Re: PATCH v5 4/4] ree: Improve ree pass for rs6000 target using defined ABI interfaces.

[Bernhard Reutner-Fischer via Gcc-patches]

On Thu, 1 Jun 2023 10:53:02 +0530
Ajit Agarwal via Gcc-patches  wrote:

> Hello All:
> 
> This new version of patch 4 use improve ree pass for rs6000 target using 
> defined ABI interfaces.
> Bootstrapped and regtested on power64-linux-gnu.
> 
> Review comments incorporated.

Not a review:

/scratch/src/gcc-14.mine$ ./contrib/check_GNU_style.py /tmp/rs6k-ree-v5.patch 
=== ERROR type #1: there should be exactly one space between function name and 
parenthesis (2 error(s)) ===
gcc/ree.cc:1461:33:   if (state.defs_list.length() != 0)
gcc/ree.cc:1487:42:   if ((i+1) < reinsn_copy_list.length())

=== ERROR type #2: trailing operator (1 error(s)) ===
gcc/ree.cc:761:24:  machine_mode tgt_mode =

$ grep -E "^[-+].*[^[:space:]\.][[:space:]][[:space:]]" /tmp/rs6k-ree-v5.patch 
+   an return  registers.  */
+  if (GET_CODE (SET_SRC (set)) !=  ZERO_EXTEND)
+  if (GET_CODE (SET_SRC (set)) !=  ZERO_EXTEND)
+  if (code !=  ZERO_EXTEND)

And maybe you could add fewer empty lines in combine_reaching_defs()

thanks,

Re: [PATCH] jump: Change return type of predicate functions from int to bool

[Bernhard Reutner-Fischer via Gcc-patches]

On Wed, 31 May 2023 09:40:24 +0200
Uros Bizjak via Gcc-patches  wrote:

> On Wed, May 31, 2023 at 9:17 AM Richard Biener
>  wrote:

> > Do we have a diagnostic that would point out places we
> > assign the bool result to an integer variable?  Do we want
> > to change those places as well (did you intend to or restrict
> > the changes to functions only used in conditional context?)  
> 
> FWIW, I'm going through candidate files by hand, looking for predicate
> functions that return 0/1. The candidate files are the ones mentioned
> in rtl.h. In addition, I am doing some drive-by cleanups in candidate
> files.

I've scratched
https://inbox.sourceware.org/gcc-patches/20221112234543.95441-5-al...@gcc.gnu.org/
https://inbox.sourceware.org/gcc-patches/20221112234543.95441-6-al...@gcc.gnu.org/

to generate patches.
You had to manually adjust the declarations to match the patched
definitions, and i did not change the type of local variables feeding
into the return automatically.

But it helped find some low hanging fruit quickly.

HTH and cheers,

Re: [PATCH v4] tree-ssa-sink: Improve code sinking pass

[Bernhard Reutner-Fischer via Gcc-patches]

Hi!

On Wed, 31 May 2023 12:31:35 +0530
Ajit Agarwal via Gcc-patches  wrote:

> Hello All:
> 
> This patch improves code sinking pass to sink statements before call to reduce
> register pressure.
> Review comments are incorporated.
> 
> For example :
> 
> void bar();
> int j;
> void foo(int a, int b, int c, int d, int e, int f)
> {
>   int l;
>   l = a + b + c + d +e + f;
>   if (a != 5)
> {
>   bar();
>   j = l;
> }
> }
> 
> Code Sinking does the following:
> 
> void bar();
> int j;
> void foo(int a, int b, int c, int d, int e, int f)
> {
>   int l;
>   
>   if (a != 5)
> {
>   l = a + b + c + d +e + f; 
>   bar();
>   j = l;
> }
> }
> 
> Bootstrapped regtested on powerpc64-linux-gnu.
> 
> Thanks & Regards
> Ajit
> 
> tree-ssa-sink: Improve code sinking pass
> 
> Code Sinking sinks the blocks after call.This increases register pressure
> for callee-saved registers. Improves code sinking before call in the use
> blocks or immediate dominator of use blocks.
> 
> 2023-05-24  Ajit Kumar Agarwal  
> 
> gcc/ChangeLog:
> 
>   * tree-ssa-sink.cc (statement_sink_location): Move statements before
>   calls.
>   (def_use_same_block): New function.
>   (select_best_block): Add heuristics to select the best blocks in the
>   immediate post dominator.
> 
> gcc/testsuite/ChangeLog:
> 
>   * gcc.dg/tree-ssa/ssa-sink-20.c: New testcase.
>   * gcc.dg/tree-ssa/ssa-sink-21.c: New testcase.
> ---
>  gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-20.c | 15 +
>  gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-21.c | 19 ++
>  gcc/tree-ssa-sink.cc| 74 +
>  3 files changed, 96 insertions(+), 12 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-20.c
>  create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-21.c
> 
> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-20.c 
> b/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-20.c
> new file mode 100644
> index 000..49d5019ab93
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-20.c
> @@ -0,0 +1,15 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -fdump-tree-optimized -fdump-tree-sink-stats" } */

You don't test the optimized dump, do you?

> +void bar();
> +int j;
> +void foo(int a, int b, int c, int d, int e, int f)
> +{
> +  int l;
> +  l = a + b + c + d +e + f;
> +  if (a != 5)
> +{
> +  bar();
> +  j = l;
> +}
> +}
> +/* { dg-final { scan-tree-dump 
> {l_12\s+=\s+_4\s+\+\s+f_11\(D\);\n\s+bar\s+\(\)} sink1 } } */
> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-21.c 
> b/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-21.c
> new file mode 100644
> index 000..84e7938c54f
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-21.c
> @@ -0,0 +1,19 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -fdump-tree-sink-stats" } */
> +void bar();
> +int j, x;
> +void foo(int a, int b, int c, int d, int e, int f)
> +{
> +  int l;
> +  l = a + b + c + d +e + f;
> +  if (a != 5)
> +{
> +  bar();
> +  if (b != 3)
> +x = 3;
> +  else
> +x = 5;
> +  j = l;
> +}
> +}
> +/* { dg-final { scan-tree-dump 
> {l_13\s+=\s+_4\s+\+\s+f_12\(D\);\n\s+bar\s+\(\)} sink1 } } */
> diff --git a/gcc/tree-ssa-sink.cc b/gcc/tree-ssa-sink.cc
> index b1ba7a2ad6c..ee8988bbb2c 100644
> --- a/gcc/tree-ssa-sink.cc
> +++ b/gcc/tree-ssa-sink.cc
> @@ -171,9 +171,28 @@ nearest_common_dominator_of_uses (def_operand_p def_p, 
> bool *debug_stmts)
>return commondom;
>  }
>  
> +/* Return TRUE if immediate uses of the defs in
> +   STMT occur in the same block as STMT, FALSE otherwise.  */
> +
> +bool
> +def_use_same_block (gimple *stmt)

Looks like this function should be static.

> +{
> +  def_operand_p def;
> +  ssa_op_iter iter;
> +
> +  FOR_EACH_SSA_DEF_OPERAND (def, stmt, iter, SSA_OP_DEF)
> +{
> +  gimple *def_stmt = SSA_NAME_DEF_STMT (DEF_FROM_PTR (def));
> +  if ((gimple_bb (def_stmt) == gimple_bb (stmt)))
> + return true;
> + }
> +  return false;
> +}
> +
>  /* Given EARLY_BB and LATE_BB, two blocks in a path through the dominator
> tree, return the best basic block between them (inclusive) to place
> -   statements.
> +   statements. The best basic block should be in immediate dominator of
> +   best basic block if the use stmt is after the call.

s/in/an/ ?

>  
> We want the most control dependent block in the shallowest loop nest.
>  
> @@ -190,7 +209,8 @@ nearest_common_dominator_of_uses (def_operand_p def_p, 
> bool *debug_stmts)
>  static basic_block
>  select_best_block (basic_block early_bb,
>  basic_block late_bb,
> -gimple *stmt)
> +gimple *stmt,
> +gimple *use)
>  {
>basic_block best_bb = late_bb;
>basic_block temp_bb = late_bb;
> @@ -230,14 +250,46 @@ select_best_block (basic_block early_bb,
>if (threshold > 100)
>   threshold = 100;
>  }
> -

superfluous whitespace change?

Re: [PATCH] PR52665 do not let .ident confuse assembler scan tests

[Bernhard Reutner-Fischer via Gcc-patches]

On Wed, 5 Sep 2018 17:32:04 +0200
Bernhard Reutner-Fischer  wrote:

> On Tue, 21 Jun 2016 at 00:19, Jeff Law  wrote:
> >
> > On 06/18/2016 01:31 PM, Bernhard Reutner-Fischer wrote:  

> > > gcc/testsuite/ChangeLog
> > >
> > > 2016-06-18  Bernhard Reutner-Fischer  
> > >
> > >   PR testsuite/52665
> > >   * lib/gcc-dg.exp (gcc-dg-test-1): Iterate over _required_options.
> > >   * lib/target-supports.exp (scan-assembler_required_options,
> > >   scan-assembler-not_required_options,
> > >   scan-assembler-times_required_options): Add -fno-ident.
> > >   * lib/scanasm.exp (scan-assembler-times): Fix error message.
> > >   * c-c++-common/ident-0a.c: New test.
> > >   * c-c++-common/ident-0b.c: New test.
> > >   * c-c++-common/ident-1a.c: New test.
> > >   * c-c++-common/ident-1b.c: New test.
> > >   * c-c++-common/ident-2a.c: New test.
> > >   * c-c++-common/ident-2b.c: New test.
> > >
> > > Ok for trunk?
> > >
> > > PS: proc force_conventional_output_for would be a bit misnomed by this,
> > > not sure if it should be renamed to maybe set_required_options_for or
> > > the like?  
> > OK.  
> 
> Now applied without the rename to trunk as r264128.
> 
> thanks,
> 
> >
> > Changing force_conventional_output to set_required_options_for is
> > pre-approved as well.

I've now applied the renaming as r14-1449-g994195b597ff20
thanks,

> >
> > jeff
> >  

Re: [i386 PATCH] A minor code clean-up: Use NULL_RTX instead of nullptr

[Bernhard Reutner-Fischer via Gcc-patches]

On Thu, 25 May 2023 18:58:04 +0200
Bernhard Reutner-Fischer  wrote:

> On Wed, 24 May 2023 18:54:06 +0100
> "Roger Sayle"  wrote:
> 
> > My understanding is that GCC's preferred null value for rtx is NULL_RTX
> > (and for tree is NULL_TREE), and by being typed allows strict type checking,
> > and use with function polymorphism and template instantiation.
> > C++'s nullptr is preferred over NULL and 0 for pointer types that don't
> > have a defined null of the correct type.
> > 
> > This minor clean-up uses NULL_RTX consistently in i386-expand.cc.  
> 
> Oh. Well, i can't resist cleanups :)

> (and handle nullptr too, and the same game for tree)

so like the attached. And
sed -e 's/RTX/TREE/g' -e 's/rtx/tree/g' \
  < ~/coccinelle/gcc-rtx-null.0.cocci \
  > ~/coccinelle/gcc-tree-null.0.cocci

I do not know if we want to shorten explicit NULL comparisons.
 foo == NULL => !foo and foo != NULL => foo
Left them alone in the form they were written.

See the attached result of the rtx hunks, someone would have to build
it and hack git-commit-mklog.py --changelog 'Use NULL_RTX.'
to print("{}.".format(random.choice(['Ditto', 'Same', 'Likewise']))) ;)

> 
> Just a thought..

cheers,


gcc-rtx-null.0.cocci
Description: Binary data
diff --git a/gcc/alias.cc b/gcc/alias.cc
index 7dc7e06de07..f1925ab3de2 100644
--- a/gcc/alias.cc
+++ b/gcc/alias.cc
@@ -1725,7 +1725,7 @@ get_reg_known_value (unsigned int regno)
   if (regno < vec_safe_length (reg_known_value))
 	return (*reg_known_value)[regno];
 }
-  return NULL;
+  return NULL_RTX;
 }
 
 /* Set it.  */
diff --git a/gcc/auto-inc-dec.cc b/gcc/auto-inc-dec.cc
index 1486e8c679a..568fae7b906 100644
--- a/gcc/auto-inc-dec.cc
+++ b/gcc/auto-inc-dec.cc
@@ -428,7 +428,7 @@ move_dead_notes (rtx_insn *to_insn, rtx_insn *from_insn, rtx pattern)
 {
   rtx note;
   rtx next_note;
-  rtx prev_note = NULL;
+  rtx prev_note = NULL_RTX;
 
   for (note = REG_NOTES (from_insn); note; note = next_note)
 {
diff --git a/gcc/bb-reorder.cc b/gcc/bb-reorder.cc
index 615d5426a34..e42e4593a6a 100644
--- a/gcc/bb-reorder.cc
+++ b/gcc/bb-reorder.cc
@@ -1477,7 +1477,7 @@ sjlj_fix_up_crossing_landing_pad (basic_block old_bb)
 	rtx_insn *insn = BB_END (e->src);
 	rtx note = find_reg_note (insn, REG_EH_REGION, NULL_RTX);
 
-	gcc_assert (note != NULL);
+	gcc_assert (note != NULL_RTX);
 	const unsigned old_index = INTVAL (XEXP (note, 0));
 
 	/* Generate the new landing-pad structure.  */
@@ -1525,7 +1525,7 @@ dw2_fix_up_crossing_landing_pad (eh_landing_pad old_lp, basic_block old_bb)
 	rtx_insn *insn = BB_END (e->src);
 	rtx note = find_reg_note (insn, REG_EH_REGION, NULL_RTX);
 
-	gcc_assert (note != NULL);
+	gcc_assert (note != NULL_RTX);
 	gcc_checking_assert (INTVAL (XEXP (note, 0)) == old_lp->index);
 	XEXP (note, 0) = GEN_INT (new_lp->index);
 
diff --git a/gcc/builtins.cc b/gcc/builtins.cc
index 8400adaf5b4..48df3d4d193 100644
--- a/gcc/builtins.cc
+++ b/gcc/builtins.cc
@@ -985,7 +985,7 @@ expand_builtin_setjmp_receiver (rtx receiver_label)
 	}
 }
 
-  if (receiver_label != NULL && targetm.have_builtin_setjmp_receiver ())
+  if (receiver_label != NULL_RTX && targetm.have_builtin_setjmp_receiver ())
 emit_insn (targetm.gen_builtin_setjmp_receiver (receiver_label));
   else if (targetm.have_nonlocal_goto_receiver ())
 emit_insn (targetm.gen_nonlocal_goto_receiver ());
@@ -4118,7 +4118,7 @@ expand_builtin_strncpy (tree exp, rtx target)
 static rtx
 gen_memset_value_from_prev (by_pieces_prev *prev, fixed_size_mode mode)
 {
-  rtx target = nullptr;
+  rtx target = NULL_RTX;
   if (prev != nullptr && prev->data != nullptr)
 {
   /* Use the previous data in the same mode.  */
@@ -4179,7 +4179,7 @@ gen_memset_value_from_prev (by_pieces_prev *prev, fixed_size_mode mode)
 		break;
 		  }
 	  }
-	  if (target == nullptr)
+	  if (target == NULL_RTX)
 	prev_rtx = copy_to_reg (prev_rtx);
 	}
 
@@ -4203,7 +4203,7 @@ builtin_memset_read_str (void *data, void *prev,
 
   rtx target = gen_memset_value_from_prev ((by_pieces_prev *) prev,
 	   mode);
-  if (target != nullptr)
+  if (target != NULL_RTX)
 return target;
   rtx src = gen_int_mode (*c, QImode);
 
@@ -4250,7 +4250,7 @@ builtin_memset_gen_str (void *data, void *prev,
 return (rtx) data;
 
   target = gen_memset_value_from_prev ((by_pieces_prev *) prev, mode);
-  if (target != nullptr)
+  if (target != NULL_RTX)
 return target;
 
   if (VECTOR_MODE_P (mode))
@@ -6278,11 +6278,11 @@ expand_builtin_atomic_compare_exchange (machine_mode mode, tree exp,
 is_weak = true;
 
   if (target == const0_rtx)
-target = NULL;
+target = NULL_RTX;
 
   /* Lest the rtl backend create a race condition with an imporoper store
  to memory, always create a new pseudo for OLDVAL.  */
-  oldval = NULL;
+  oldval = NULL_RTX;
 
   if (!expand_atomic_compare_and_s

Re: [i386 PATCH] A minor code clean-up: Use NULL_RTX instead of nullptr

[Bernhard Reutner-Fischer via Gcc-patches]

On Wed, 24 May 2023 18:54:06 +0100
"Roger Sayle"  wrote:

> My understanding is that GCC's preferred null value for rtx is NULL_RTX
> (and for tree is NULL_TREE), and by being typed allows strict type checking,
> and use with function polymorphism and template instantiation.
> C++'s nullptr is preferred over NULL and 0 for pointer types that don't
> have a defined null of the correct type.
> 
> This minor clean-up uses NULL_RTX consistently in i386-expand.cc.

Oh. Well, i can't resist cleanups :)

Given
$ cat /tmp/inp0.c ; echo EOF
rtx myfunc (int i, int j)
{
  rtx ret;
  if (i)
return NULL;
  if (j)
   ret = NULL;
  if (ret == NULL) {
ret = NULL_RTX;
  }
  if (!ret)
return (rtx)2;
  return NULL_RTX;
}
EOF
$ spatch --c++=11 --smpl-spacing --in-place --sp-file 
~/coccinelle/rtx-null.0.cocci /tmp/inp0.c
init_defs_builtins: /usr/bin/../lib/coccinelle/standard.h
--- /tmp/inp0.c
+++ /tmp/cocci-output-76891-58af4a-inp0.c
@@ -2,10 +2,10 @@ rtx myfunc (int i, int j)
 {
   rtx ret;
   if (i)
-return NULL;
+return NULL_RTX;
   if (j)
-   ret = NULL;
-  if (ret == NULL) {
+   ret = NULL_RTX;
+  if (ret == NULL_RTX) {
 ret = NULL_RTX;
   }
   if (!ret)
HANDLING: /tmp/inp0.c
diff = 

So you if you would feel like, someone could
find ./ \( -name "testsuite" -o -name "contrib" -o -name "examples" -o -name 
".git" -o -name "zlib" -o -name "intl" \) -prune -o \( -name "*.[chpx]*" -a 
-type f \) -exec spatch --c++=11 --smpl-spacing --in-place $opts --sp-file 
~/coccinelle/rtx-null.0.cocci {} \;
with the attached rtx-null coccinelle script.
(and handle nullptr too, and the same game for tree)

Just a thought..


rtx-null.0.cocci
Description: Binary data

Re: [V7][PATCH 1/2] Handle component_ref to a structre/union field including flexible array member [PR101832]

[Bernhard Reutner-Fischer via Gcc-patches]

On 24 May 2023 16:09:21 CEST, Qing Zhao  wrote:
>Bernhard,
>
>Thanks a lot for your comments.
>
>> On May 19, 2023, at 7:11 PM, Bernhard Reutner-Fischer 
>>  wrote:
>> 
>> On Fri, 19 May 2023 20:49:47 +
>> Qing Zhao via Gcc-patches  wrote:
>> 
>>> GCC extension accepts the case when a struct with a flexible array member
>>> is embedded into another struct or union (possibly recursively).
>> 
>> Do you mean TYPE_TRAILING_FLEXARRAY()?
>
>The following might be more accurate description:
>
>GCC extension accepts the case when a struct with a flexible array member
> is embedded into another struct or union (possibly recursively) as the last 
> field.
>
>
>
>> 
>>> diff --git a/gcc/tree.h b/gcc/tree.h
>>> index 0b72663e6a1..237644e788e 100644
>>> --- a/gcc/tree.h
>>> +++ b/gcc/tree.h
>>> @@ -786,7 +786,12 @@ extern void omp_clause_range_check_failed (const_tree, 
>>> const char *, int,
>>>(...) prototype, where arguments can be accessed with va_start and
>>>va_arg), as opposed to an unprototyped function.  */
>>> #define TYPE_NO_NAMED_ARGS_STDARG_P(NODE) \
>>> -  (TYPE_CHECK (NODE)->type_common.no_named_args_stdarg_p)
>>> +  (FUNC_OR_METHOD_CHECK (NODE)->type_common.no_named_args_stdarg_p)
>>> +
>>> +/* True if this RECORD_TYPE or UNION_TYPE includes a flexible array member
>>> +   at the last field recursively.  */
>>> +#define TYPE_INCLUDE_FLEXARRAY(NODE) \
>>> +  (RECORD_OR_UNION_CHECK (NODE)->type_common.no_named_args_stdarg_p)
>> 
>> Until i read the description above i read TYPE_INCLUDE_FLEXARRAY as an
>> option to include or not include something. The description hints more
>> at TYPE_INCLUDES_FLEXARRAY (with an S) to be a type which has at least
>> one member which has a trailing flexible array or which itself has a
>> trailing flexible array.
>
>Yes, TYPE_INCLUDES_FLEXARRAY (maybe with a S is a better name) means the 
>structure/union TYPE includes a flexible array member or includes a struct 
>with a flexible array member as the last field.
>

So ANY_TRAILING_FLEXARRAY or TYPE_CONTAINS_FLEXARRAY, TYPE_INCLUDES_FLEXARRAY 
or something like that would be more clear, i don't know.
I'd probably use the first, but that's enough bike shedding for me now. Let's 
see what others think.

thanks,

>Hope this is clear.
>thanks.
>
>Qing
>> 
>>> 
>>> /* In an IDENTIFIER_NODE, this means that assemble_name was called with
>>>this string as an argument.  */
>> 
>

Re: [V7][PATCH 1/2] Handle component_ref to a structre/union field including flexible array member [PR101832]

[Bernhard Reutner-Fischer via Gcc-patches]

On Fri, 19 May 2023 20:49:47 +
Qing Zhao via Gcc-patches  wrote:

> GCC extension accepts the case when a struct with a flexible array member
> is embedded into another struct or union (possibly recursively).

Do you mean TYPE_TRAILING_FLEXARRAY()?

> diff --git a/gcc/tree.h b/gcc/tree.h
> index 0b72663e6a1..237644e788e 100644
> --- a/gcc/tree.h
> +++ b/gcc/tree.h
> @@ -786,7 +786,12 @@ extern void omp_clause_range_check_failed (const_tree, 
> const char *, int,
> (...) prototype, where arguments can be accessed with va_start and
> va_arg), as opposed to an unprototyped function.  */
>  #define TYPE_NO_NAMED_ARGS_STDARG_P(NODE) \
> -  (TYPE_CHECK (NODE)->type_common.no_named_args_stdarg_p)
> +  (FUNC_OR_METHOD_CHECK (NODE)->type_common.no_named_args_stdarg_p)
> +
> +/* True if this RECORD_TYPE or UNION_TYPE includes a flexible array member
> +   at the last field recursively.  */
> +#define TYPE_INCLUDE_FLEXARRAY(NODE) \
> +  (RECORD_OR_UNION_CHECK (NODE)->type_common.no_named_args_stdarg_p)

Until i read the description above i read TYPE_INCLUDE_FLEXARRAY as an
option to include or not include something. The description hints more
at TYPE_INCLUDES_FLEXARRAY (with an S) to be a type which has at least
one member which has a trailing flexible array or which itself has a
trailing flexible array.

>  
>  /* In an IDENTIFIER_NODE, this means that assemble_name was called with
> this string as an argument.  */

Re: [PATCH 08/14] fortran: use _P() defines from tree.h

[Bernhard Reutner-Fischer via Gcc-patches]

On Thu, 18 May 2023 21:20:41 +0200
Mikael Morin  wrote:

> Le 18/05/2023 à 17:18, Bernhard Reutner-Fischer a écrit :

> > I've fed gfortran.h into the script and found some CLASS_DATA spots,
> > see attached bootstrapped and tested patch.
> > Do we want to have that?  
> Some of it makes sense, but not all of it.
> 
> It is a macro to access the _data component of a class container.
> So for class-related stuff it makes sense to use CLASS_DATA, and 
> typically there will be a check that the type is BT_CLASS before.
> But for cases where we loop over all of the components of a type that is 
> not necessarily a class container, it doesn't make sense to use CLASS_DATA.
> 
> So I suggest to only keep the following hunks.
[]
> OK for those hunks.

Pushed those as r14-1001-g05b7cc7daac8b3
Many thanks!

PS: I'm attaching the fugly script i used to do these macro
replacements FYA.


use-defines.1.awk
Description: application/awk

Re: [PATCH] avr: Set param_min_pagesize to 0 [PR105523]

[Bernhard Reutner-Fischer via Gcc-patches]

On 19 May 2023 07:58:48 CEST, "SenthilKumar.Selvaraj--- via Gcc-patches" 
 wrote:

Just a nit:

>+static bool
>+avr_addr_space_zero_address_valid (addr_space_t as ATTRIBUTE_UNUSED)
>+{
>+  return flag_delete_null_pointer_checks == 0;
>+}

Since we are c++ nowadays, you can omit the parameter name for unused 
arguments. I.e.:

static bool
avr_addr_space_zero_address_valid (addr_space_t)
{
  ...

Re: [PATCH 01/14] ada: use _P() defines from tree.h

[Bernhard Reutner-Fischer via Gcc-patches]

On Sun, 14 May 2023 17:03:55 -0600
Jeff Law  wrote:

> On 5/13/23 17:23, Bernhard Reutner-Fischer via Gcc-patches wrote:
> > From: Bernhard Reutner-Fischer 
> > 
> > gcc/ada/ChangeLog:
> > 
> > * gcc-interface/decl.cc (gnat_to_gnu_entity): Use _P defines

> The series as a whole is OK.

Thanks.
I've dropped the go and rust hunks and installed the rest (with tweaks
as requested) as r14-974-g04682fe764004b .. r14-985-gca2007a9bb3074

Re: [PATCH 01/14] ada: use _P() defines from tree.h

[Bernhard Reutner-Fischer via Gcc-patches]

On Mon, 15 May 2023 12:05:10 +0200
Eric Botcazou  wrote:

> > && DECL_RETURN_VALUE_P (inner))
> > diff --git a/gcc/ada/gcc-interface/utils.cc b/gcc/ada/gcc-interface/utils.cc
> > index 0c4f8b90c8e..460ef6f1f01 100644
> > --- a/gcc/ada/gcc-interface/utils.cc
> > +++ b/gcc/ada/gcc-interface/utils.cc
> > @@ -1966,7 +1966,7 @@ finish_record_type (tree record_type, tree field_list,
> > int rep_level, bool debug_info_p)
> >  {
> >const enum tree_code orig_code = TREE_CODE (record_type);
> > -  const bool had_size = TYPE_SIZE (record_type) != NULL_TREE;
> > +  const bool had_size = COMPLETE_TYPE_P (record_type);
> >const bool had_align = TYPE_ALIGN (record_type) > 0;
> >/* For all-repped records with a size specified, lay the QUAL_UNION_TYPE
> >   out just like a UNION_TYPE, since the size will be fixed.  */  
> 
> This one is not an improvement but more of a coincidence; the rest is OK.
> 

I've dropped this hunk and installed the rest as
r14-974-g04682fe764004b.
Thanks!

Re: [PATCH v2] Fortran: Narrow return types [PR78798]

[Bernhard Reutner-Fischer via Gcc-patches]

On Sun, 14 May 2023 14:27:42 +0200
Mikael Morin  wrote:

> Le 10/05/2023 à 18:47, Bernhard Reutner-Fischer via Fortran a écrit :
> > From: Bernhard Reutner-Fischer 
> > 
> > gcc/fortran/ChangeLog:
> > 
> > PR fortran/78798
> > * array.cc (compare_bounds): Use narrower return type.
> > (gfc_compare_array_spec): Likewise.
> > (is_constant_element): Likewise.
> > (gfc_constant_ac): Likewise.  
> (...)
> > ---
> > Bootstrapped without new warnings and regression tested on
> > x86_64-linux with no regressions, OK for trunk?
> >   
> (...)
> > diff --git a/gcc/fortran/check.cc b/gcc/fortran/check.cc
> > index b348bda6e6c..4e3aed84b9d 100644
> > --- a/gcc/fortran/check.cc
> > +++ b/gcc/fortran/check.cc
> > @@ -1156,7 +1156,7 @@ dim_rank_check (gfc_expr *dim, gfc_expr *array, int 
> > allow_assumed)
> >  dimension bi, returning 0 if they are known not to be identical,
> >  and 1 if they are identical, or if this cannot be determined.  */
> >   
> > -static int
> > +static bool
> >   identical_dimen_shape (gfc_expr *a, int ai, gfc_expr *b, int bi)
> >   {
> > mpz_t a_size, b_size;  
> 
> To be consistent, please change as well the local variable "ret" used as 
> return value from int to bool.
> 
> > diff --git a/gcc/fortran/cpp.cc b/gcc/fortran/cpp.cc
> > index c3b7c7f7bd9..d7890a97287 100644
> > --- a/gcc/fortran/cpp.cc
> > +++ b/gcc/fortran/cpp.cc
> > @@ -297,7 +297,7 @@ gfc_cpp_init_options (unsigned int 
> > decoded_options_count,
> > gfc_cpp_option.deferred_opt_count = 0;
> >   }
> >   
> > -int
> > +bool
> >   gfc_cpp_handle_option (size_t scode, const char *arg, int value 
> > ATTRIBUTE_UNUSED)
> >   {
> > int result = 1;  
> 
> Same here, change the type of variable "result".
> 
> (...)
> > diff --git a/gcc/fortran/dependency.cc b/gcc/fortran/dependency.cc
> > index a648d5c7903..b398b29a642 100644
> > --- a/gcc/fortran/dependency.cc
> > +++ b/gcc/fortran/dependency.cc  
> (...)
> 
> > @@ -1091,7 +1091,7 @@ gfc_check_argument_dependency (gfc_expr *other, 
> > sym_intent intent,
> >   /* Like gfc_check_argument_dependency, but check all the arguments in 
> > ACTUAL.
> >  FNSYM is the function being called, or NULL if not known.  */
> >   
> > -int
> > +bool
> >   gfc_check_fncall_dependency (gfc_expr *other, sym_intent intent,
> >  gfc_symbol *fnsym, gfc_actual_arglist *actual,
> >  gfc_dep_check elemental)  
> 
> Why not change the associated subfunctions 
> (gfc_check_argument_dependency, gfc_check_argument_var_dependency) as well ?

I have left these subfunctions alone for now to get the other hunks out
of the way. I have adjusted the patch according to your other comments
and pushed it as r14-973-gc072df1ab14450.

Thanks!

> 
> (...)
> > @@ -2098,7 +2098,7 @@ ref_same_as_full_array (gfc_ref *full_ref, gfc_ref 
> > *ref)
> > there is some kind of overlap.
> > 0 : array references are identical or not overlapping.  */
> >   
> > -int
> > +bool
> >   gfc_dep_resolver (gfc_ref *lref, gfc_ref *rref, gfc_reverse *reverse,
> >   bool identical)
> >   {  
> 
> The function comment states that the function may return 2, which 
> doesn't seem to be the case any more.  So please update the comment.
> 
> (...)> diff --git a/gcc/fortran/symbol.cc b/gcc/fortran/symbol.cc
> > index 221165d6dac..b4b36e27d75 100644
> > --- a/gcc/fortran/symbol.cc
> > +++ b/gcc/fortran/symbol.cc
> > @@ -3216,7 +3216,7 @@ gfc_find_symtree_in_proc (const char* name, 
> > gfc_namespace* ns)
> >  any parent namespaces if requested by a nonzero parent_flag.
> >  Returns nonzero if the name is ambiguous.  */
> >   
> > -int
> > +bool
> >   gfc_find_sym_tree (const char *name, gfc_namespace *ns, int parent_flag,
> >gfc_symtree **result)
> >   {  
> 
> Maybe change nonzero to true in the comment?
> 
> (...)
> 
> OK with all the above fixed.
> 
> Thanks.
> 

Re: [PATCH 08/14] fortran: use _P() defines from tree.h

[Bernhard Reutner-Fischer via Gcc-patches]

On Sun, 14 May 2023 15:10:12 +0200
Mikael Morin  wrote:

> Le 14/05/2023 à 01:23, Bernhard Reutner-Fischer via Gcc-patches a écrit :
> > From: Bernhard Reutner-Fischer 
> > 
> > gcc/fortran/ChangeLog:
> > 
> > * trans-array.cc (is_pointer_array): Use _P() defines from tree.h.
> > (gfc_conv_scalarized_array_ref): Ditto.
> > (gfc_conv_array_ref): Ditto.
> > * trans-decl.cc (gfc_finish_decl): Ditto.
> > (gfc_get_symbol_decl): Ditto.
> > * trans-expr.cc (gfc_trans_pointer_assignment): Ditto.
> > (gfc_trans_arrayfunc_assign): Ditto.
> > (gfc_trans_assignment_1): Ditto.
> > * trans-intrinsic.cc (gfc_conv_intrinsic_minmax): Ditto.
> > (conv_intrinsic_ieee_value): Ditto.
> > * trans-io.cc (gfc_convert_array_to_string): Ditto.
> > * trans-openmp.cc (gfc_omp_is_optional_argument): Ditto.
> > (gfc_trans_omp_clauses): Ditto.
> > * trans-stmt.cc (gfc_conv_label_variable): Ditto.
> > * trans.cc (gfc_build_addr_expr): Ditto.
> > (get_array_span): Ditto.  
> 
> OK from the fortran side.
> 
> Thanks

Thanks, i'll push it during the weekend.

I've fed gfortran.h into the script and found some CLASS_DATA spots,
see attached bootstrapped and tested patch.
Do we want to have that?
If so, i'd write a proper ChangeLog, of course.

Thanks!
diff --git a/gcc/fortran/class.cc b/gcc/fortran/class.cc
index 9d0c802b867..1466b07e260 100644
--- a/gcc/fortran/class.cc
+++ b/gcc/fortran/class.cc
@@ -889,7 +889,7 @@ copy_vtab_proc_comps (gfc_symbol *declared, gfc_symbol *vtype)
 
   vtab = gfc_find_derived_vtab (declared);
 
-  for (cmp = vtab->ts.u.derived->components; cmp; cmp = cmp->next)
+  for (cmp = CLASS_DATA (vtab); cmp; cmp = cmp->next)
 {
   if (gfc_find_component (vtype, cmp->name, true, true, NULL))
 	continue;
@@ -1078,7 +1078,7 @@ finalize_component (gfc_expr *expr, gfc_symbol *derived, gfc_component *comp,
   gfc_component *c;
 
   vtab = gfc_find_derived_vtab (comp->ts.u.derived);
-  for (c = vtab->ts.u.derived->components; c; c = c->next)
+  for (c = CLASS_DATA (vtab); c; c = c->next)
 	if (strcmp (c->name, "_final") == 0)
 	  break;
 
@@ -1143,7 +1143,7 @@ finalize_component (gfc_expr *expr, gfc_symbol *derived, gfc_component *comp,
 {
   gfc_component *c;
 
-  for (c = comp->ts.u.derived->components; c; c = c->next)
+  for (c = CLASS_DATA (comp); c; c = c->next)
 	finalize_component (e, comp->ts.u.derived, c, stat, fini_coarray, code,
 			sub_ns);
   gfc_free_expr (e);
@@ -1675,7 +1675,7 @@ generate_finalization_wrapper (gfc_symbol *derived, gfc_namespace *ns,
   gfc_component *comp;
 
   vtab = gfc_find_derived_vtab (derived->components->ts.u.derived);
-  for (comp = vtab->ts.u.derived->components; comp; comp = comp->next)
+  for (comp = CLASS_DATA (vtab); comp; comp = comp->next)
 	if (comp->name[0] == '_' && comp->name[1] == 'f')
 	  {
 	ancestor_wrapper = comp->initializer;
@@ -2752,7 +2752,7 @@ yes:
 {
   /* Return finalizer expression.  */
   gfc_component *final;
-  final = vtab->ts.u.derived->components->next->next->next->next->next;
+  final = CLASS_DATA (vtab)->next->next->next->next->next;
   gcc_assert (strcmp (final->name, "_final") == 0);
   gcc_assert (final->initializer
 		  && final->initializer->expr_type != EXPR_NULL);
diff --git a/gcc/fortran/data.cc b/gcc/fortran/data.cc
index d29eb12c1b1..f907bb35eb1 100644
--- a/gcc/fortran/data.cc
+++ b/gcc/fortran/data.cc
@@ -730,7 +730,7 @@ formalize_structure_cons (gfc_expr *expr)
   if (!cur || cur->n.component == NULL)
 return;
 
-  for (order = expr->ts.u.derived->components; order; order = order->next)
+  for (order = CLASS_DATA (expr); order; order = order->next)
 {
   cur = find_con_by_component (order, expr->value.constructor);
   if (cur)
diff --git a/gcc/fortran/dependency.cc b/gcc/fortran/dependency.cc
index b398b29a642..864470afdec 100644
--- a/gcc/fortran/dependency.cc
+++ b/gcc/fortran/dependency.cc
@@ -1253,7 +1253,7 @@ check_data_pointer_types (gfc_expr *expr1, gfc_expr *expr2)
 
   if (sym1->ts.type == BT_DERIVED && !seen_component_ref)
 {
-  for (cm1 = sym1->ts.u.derived->components; cm1; cm1 = cm1->next)
+  for (cm1 = CLASS_DATA (sym1); cm1; cm1 = cm1->next)
 	{
 	  if (cm1->ts.type == BT_DERIVED)
 	return false;
diff --git a/gcc/fortran/expr.cc b/gcc/fortran/expr.cc
index aa01a4d3d22..a6b4ef0a0bf 100644
--- a/gcc/fortran/expr.cc
+++ b/gcc/fortran/expr.cc
@@ -2671,7 +2671,7 @@ check_alloc_comp_init (gfc_expr *e)
   gcc_assert (e->expr_type == EXPR_STRUCTURE);
   gcc_assert (e->ts.type == BT_DERIVED || e->ts.type 

Re: [PATCH 1/3] gcc: Fix nonportable shell syntax in "test" and "[" commands [PR105831]

[Bernhard Reutner-Fischer via Gcc-patches]

On 18 May 2023 14:56:45 CEST, Jonathan Wakely via Gcc-patches 
 wrote:
>From: Michael B��uerle 
>
>POSIX sh does not support the == for string comparisons, use = instead.
>
>gcc/ChangeLog:
>
>   PR bootstrap/105831

> 
>diff --git a/gcc/configure.ac b/gcc/configure.ac
>index 075424669c9..cc8dd9e20bf 100644
>--- a/gcc/configure.ac
>+++ b/gcc/configure.ac
>@@ -473,7 +473,7 @@ AC_CHECK_SIZEOF(dev_t)
> if test "$enable_largefile" != no; then
>   case "$host, $build" in
> *-*-aix*,*|*,*-*-aix*)
>-  if test "$ac_cv_sizeof_ino_t" == "4" -a "$ac_cv_sizeof_dev_t" == 4; then
>+  if test "$ac_cv_sizeof_ino_t" = "4" -a "$ac_cv_sizeof_dev_t" = 4; then

test(1) -a and -o are marked obsolescent in SUS and should be spelled out as && 
or ||, respectively: 
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/test.html

thanks,

Re: [PATCH] Add auto-resizing capability to irange's [PR109695]

[Bernhard Reutner-Fischer via Gcc-patches]

On Mon, 15 May 2023 12:35:23 +0200
Aldy Hernandez via Gcc-patches  wrote:

> +// For resizable ranges, resize the range up to HARD_MAX_RANGES if the
> +// NEEDED pairs is greater than the current capacity of the range.
> +
> +inline void
> +irange::maybe_resize (int needed)
> +{
> +  if (!m_resizable || m_max_ranges == HARD_MAX_RANGES)
> +return;
> +
> +  if (needed > m_max_ranges)
> +{
> +  m_max_ranges = HARD_MAX_RANGES;
> +  wide_int *newmem = new wide_int[m_max_ranges * 2];
> +  memcpy (newmem, m_base, sizeof (wide_int) * num_pairs () * 2);
> +  m_base = newmem;

Please excuse my ignorance, but where's the old m_base freed? I think
the assignment above does not call the destructor, or does it?

thanks,

> +}
> +}
> +
> +template
> +inline
> +int_range::~int_range ()
> +{
> +  if (RESIZABLE && m_base != m_ranges)
> +delete m_base;
> +}

Re: Re: [PATCH] RISC-V: Add rounding mode operand for fixed-point patterns

[Bernhard Reutner-Fischer via Gcc-patches]

On 15 May 2023 10:25:30 CEST, "juzhe.zh...@rivai.ai"  
wrote:
>Address comments.

s/VXRM_RENUM/VXRM_REGNUM/g

thanks,

Re: [PATCH v2] Fortran: Narrow return types [PR78798]

[Bernhard Reutner-Fischer via Gcc-patches]

On Sun, 14 May 2023 15:04:15 +0200
Thomas Koenig  wrote:

> On 14.05.23 14:27, Mikael Morin wrote:
> > 
> > (...)  
> >> @@ -2098,7 +2098,7 @@ ref_same_as_full_array (gfc_ref *full_ref, 
> >> gfc_ref *ref)
> >>   there is some kind of overlap.
> >>   0 : array references are identical or not overlapping.  */
> >> -int
> >> +bool
> >>   gfc_dep_resolver (gfc_ref *lref, gfc_ref *rref, gfc_reverse *reverse,
> >>     bool identical)
> >>   {  
> > 
> > The function comment states that the function may return 2, which 
> > doesn't seem to be the case any more.  
> 
> Hm, this makes me a litte suspicious.  Was functionality for reversing
> loops lost,  maybe unintentionally?  I assume that, at some time, we did
> use the '2' as return value (or did we?)

There was 7c428aa29d75ef163c334cf3974f87b3630d8b8b (a revert because it
miscompiled spec2k) which might have associated the comment of the
former static gfc_dependency dep_ref (gfc_ref *lref, gfc_ref *rref,
gfc_reverse *reverse) to the current gfc_dep_resolver.

The commit which introduced the return value 2 documentation was
3d03ead0b8273efde57f6194617b35111a84b05d 
"re PR fortran/24524 (Fortran dependency checking should reverse loops)"

but TBH i don't see how it returned 2 in that revision?
Looks like when writing that patch it deemed useful to return 2 for
this specific situation but in the end it was dropped but the comment
survived.

I will update the comment to document the true / false return values.

And Mikael, do you want me to cleanup 1/0 to true/false assignments for
the boolean variables, or can we do that in a separate patch (or not at
all right now)?

many thanks for the reviews!

[PATCH 06/14] lto: use _P() defines from tree.h

[Bernhard Reutner-Fischer via Gcc-patches]

From: Bernhard Reutner-Fischer 

gcc/ChangeLog:

* lto-streamer-in.cc (lto_input_var_decl_ref): Use _P defines from
tree.h.
(lto_read_body_or_constructor): Ditto.
* lto-streamer-out.cc (tree_is_indexable): Ditto.
(lto_output_var_decl_ref): Ditto.
(DFS::DFS_write_tree_body): Ditto.
(wrap_refs): Ditto.
(write_symbol_extension_info): Ditto.

gcc/lto/ChangeLog:

* lto-common.cc (lto_maybe_register_decl):
* lto-symtab.cc (warn_type_compatibility_p):
(lto_symtab_resolve_replaceable_p):
(lto_symtab_merge_decls_1):
* lto-symtab.h (lto_symtab_prevailing_decl):
---
 gcc/lto-streamer-in.cc  |  4 ++--
 gcc/lto-streamer-out.cc | 11 +--
 gcc/lto/lto-common.cc   |  2 +-
 gcc/lto/lto-symtab.cc   |  8 
 gcc/lto/lto-symtab.h|  2 +-
 5 files changed, 13 insertions(+), 14 deletions(-)

diff --git a/gcc/lto-streamer-in.cc b/gcc/lto-streamer-in.cc
index 03cb41cfa16..2cb83406db5 100644
--- a/gcc/lto-streamer-in.cc
+++ b/gcc/lto-streamer-in.cc
@@ -671,7 +671,7 @@ lto_input_var_decl_ref (lto_input_block *ib, 
lto_file_decl_data *file_data)
   unsigned int ix_u = streamer_read_uhwi (ib);
   tree result = (*file_data->current_decl_state
 ->streams[LTO_DECL_STREAM])[ix_u];
-  gcc_assert (TREE_CODE (result) == VAR_DECL);
+  gcc_assert (VAR_P (result));
   return result;
 }
 
@@ -1653,7 +1653,7 @@ lto_read_body_or_constructor (struct lto_file_decl_data 
*file_data, struct symta
 
  if (TYPE_P (t))
{
- gcc_assert (TYPE_CANONICAL (t) == NULL_TREE);
+ gcc_assert (TYPE_STRUCTURAL_EQUALITY_P (t));
  if (type_with_alias_set_p (t)
  && canonical_type_used_p (t))
TYPE_CANONICAL (t) = TYPE_MAIN_VARIANT (t);
diff --git a/gcc/lto-streamer-out.cc b/gcc/lto-streamer-out.cc
index 0bca530313c..5ab2eb4301e 100644
--- a/gcc/lto-streamer-out.cc
+++ b/gcc/lto-streamer-out.cc
@@ -178,7 +178,7 @@ tree_is_indexable (tree t)
   && lto_variably_modified_type_p (DECL_CONTEXT (t)))
 return false;
   else
-return (TYPE_P (t) || DECL_P (t) || TREE_CODE (t) == SSA_NAME);
+return (IS_TYPE_OR_DECL_P (t) || TREE_CODE (t) == SSA_NAME);
 }
 
 
@@ -346,7 +346,7 @@ void
 lto_output_var_decl_ref (struct lto_out_decl_state *decl_state,
 struct lto_output_stream * obs, tree decl)
 {
-  gcc_checking_assert (TREE_CODE (decl) == VAR_DECL);
+  gcc_checking_assert (VAR_P (decl));
   streamer_write_uhwi_stream
  (obs, lto_get_index (_state->streams[LTO_DECL_STREAM],
  decl));
@@ -1078,8 +1078,7 @@ DFS::DFS_write_tree_body (struct output_block *ob,
   else if (RECORD_OR_UNION_TYPE_P (expr))
for (tree t = TYPE_FIELDS (expr); t; t = TREE_CHAIN (t))
  DFS_follow_tree_edge (t);
-  else if (TREE_CODE (expr) == FUNCTION_TYPE
-  || TREE_CODE (expr) == METHOD_TYPE)
+  else if (FUNC_OR_METHOD_TYPE_P (expr))
DFS_follow_tree_edge (TYPE_ARG_TYPES (expr));
 
   if (!POINTER_TYPE_P (expr))
@@ -2626,7 +2625,7 @@ wrap_refs (tree *tp, int *ws, void *)
 {
   tree t = *tp;
   if (handled_component_p (t)
-  && TREE_CODE (TREE_OPERAND (t, 0)) == VAR_DECL
+  && VAR_P (TREE_OPERAND (t, 0))
   && TREE_PUBLIC (TREE_OPERAND (t, 0)))
 {
   tree decl = TREE_OPERAND (t, 0);
@@ -3064,7 +3063,7 @@ write_symbol_extension_info (tree t)
? GCCST_VARIABLE : GCCST_FUNCTION);
   lto_write_data (, 1);
   unsigned char section_kind = 0;
-  if (TREE_CODE (t) == VAR_DECL)
+  if (VAR_P (t))
 {
   section *s = get_variable_section (t, false);
   if (s->common.flags & SECTION_BSS)
diff --git a/gcc/lto/lto-common.cc b/gcc/lto/lto-common.cc
index 882dd8971a4..537570204b3 100644
--- a/gcc/lto/lto-common.cc
+++ b/gcc/lto/lto-common.cc
@@ -958,7 +958,7 @@ lto_register_function_decl_in_symtab (class data_in 
*data_in, tree decl,
 static void
 lto_maybe_register_decl (class data_in *data_in, tree t, unsigned ix)
 {
-  if (TREE_CODE (t) == VAR_DECL)
+  if (VAR_P (t))
 lto_register_var_decl_in_symtab (data_in, t, ix);
   else if (TREE_CODE (t) == FUNCTION_DECL
   && !fndecl_built_in_p (t))
diff --git a/gcc/lto/lto-symtab.cc b/gcc/lto/lto-symtab.cc
index 2b57d0d5371..79ba8ddde20 100644
--- a/gcc/lto/lto-symtab.cc
+++ b/gcc/lto/lto-symtab.cc
@@ -214,7 +214,7 @@ warn_type_compatibility_p (tree prevailing_type, tree type,
 
   /* Function types needs special care, because types_compatible_p never
  thinks prototype is compatible to non-prototype.  */
-  if (TREE_CODE (type) == FUNCTION_TYPE || TREE_CODE (type) == METHOD_TYPE)
+  if (FUNC_OR_METHOD_TYPE_P (type))
 {
   if (TREE_CODE (type) != TREE_CODE (prevailing_type))
lev |= 1;
@@ -401,7 +401,7 @@ lto_symtab_resolve_replaceable_p (symtab_node *e)
   || DECL_WEAK (e-&g

[PATCH 14/14] gcc: use _P() defines from tree.h

[Bernhard Reutner-Fischer via Gcc-patches]

From: Bernhard Reutner-Fischer 

gcc/ChangeLog:

* alias.cc (ref_all_alias_ptr_type_p): Use _P() defines from tree.h.
* attribs.cc (diag_attr_exclusions): Ditto.
(decl_attributes): Ditto.
(build_type_attribute_qual_variant): Ditto.
* builtins.cc (fold_builtin_carg): Ditto.
(fold_builtin_next_arg): Ditto.
(do_mpc_arg2): Ditto.
* cfgexpand.cc (expand_return): Ditto.
* cgraph.h (decl_in_symtab_p): Ditto.
(symtab_node::get_create): Ditto.
* dwarf2out.cc (base_type_die): Ditto.
(implicit_ptr_descriptor): Ditto.
(gen_array_type_die): Ditto.
(gen_type_die_with_usage): Ditto.
(optimize_location_into_implicit_ptr): Ditto.
* expr.cc (do_store_flag): Ditto.
* fold-const.cc (negate_expr_p): Ditto.
(fold_negate_expr_1): Ditto.
(fold_convert_const): Ditto.
(fold_convert_loc): Ditto.
(constant_boolean_node): Ditto.
(fold_binary_op_with_conditional_arg): Ditto.
(build_fold_addr_expr_with_type_loc): Ditto.
(fold_comparison): Ditto.
(fold_checksum_tree): Ditto.
(tree_unary_nonnegative_warnv_p): Ditto.
(integer_valued_real_unary_p): Ditto.
(fold_read_from_constant_string): Ditto.
* gcc-rich-location.cc 
(maybe_range_label_for_tree_type_mismatch::get_text): Ditto.
* gimple-expr.cc (useless_type_conversion_p): Ditto.
(is_gimple_reg): Ditto.
(is_gimple_asm_val): Ditto.
(mark_addressable): Ditto.
* gimple-expr.h (is_gimple_variable): Ditto.
(virtual_operand_p): Ditto.
* gimple-ssa-warn-access.cc (pass_waccess::check_dangling_stores): 
Ditto.
* gimplify.cc (gimplify_bind_expr): Ditto.
(gimplify_return_expr): Ditto.
(gimple_add_padding_init_for_auto_var): Ditto.
(gimplify_addr_expr): Ditto.
(omp_add_variable): Ditto.
(omp_notice_variable): Ditto.
(omp_get_base_pointer): Ditto.
(omp_strip_components_and_deref): Ditto.
(omp_strip_indirections): Ditto.
(omp_accumulate_sibling_list): Ditto.
(omp_build_struct_sibling_lists): Ditto.
(gimplify_adjust_omp_clauses_1): Ditto.
(gimplify_adjust_omp_clauses): Ditto.
(gimplify_omp_for): Ditto.
(goa_lhs_expr_p): Ditto.
(gimplify_one_sizepos): Ditto.
* graphite-scop-detection.cc 
(scop_detection::graphite_can_represent_scev): Ditto.
* ipa-devirt.cc (odr_types_equivalent_p): Ditto.
* ipa-prop.cc (ipa_set_jf_constant): Ditto.
(propagate_controlled_uses): Ditto.
* ipa-sra.cc (type_prevails_p): Ditto.
(scan_expr_access): Ditto.
* optabs-tree.cc (optab_for_tree_code): Ditto.
* toplev.cc (wrapup_global_declaration_1): Ditto.
* trans-mem.cc (transaction_invariant_address_p): Ditto.
* tree-cfg.cc (verify_types_in_gimple_reference): Ditto.
(verify_gimple_comparison): Ditto.
(verify_gimple_assign_binary): Ditto.
(verify_gimple_assign_single): Ditto.
* tree-complex.cc (get_component_ssa_name): Ditto.
* tree-emutls.cc (lower_emutls_2): Ditto.
* tree-inline.cc (copy_tree_body_r): Ditto.
(estimate_move_cost): Ditto.
(copy_decl_for_dup_finish): Ditto.
* tree-nested.cc (convert_nonlocal_omp_clauses): Ditto.
(note_nonlocal_vla_type): Ditto.
(convert_local_omp_clauses): Ditto.
(remap_vla_decls): Ditto.
(fixup_vla_decls): Ditto.
* tree-parloops.cc (loop_has_vector_phi_nodes): Ditto.
* tree-pretty-print.cc (print_declaration): Ditto.
(print_call_name): Ditto.
* tree-sra.cc (compare_access_positions): Ditto.
* tree-ssa-alias.cc (compare_type_sizes): Ditto.
* tree-ssa-ccp.cc (get_default_value): Ditto.
* tree-ssa-coalesce.cc (populate_coalesce_list_for_outofssa): Ditto.
* tree-ssa-dom.cc (reduce_vector_comparison_to_scalar_comparison): 
Ditto.
* tree-ssa-forwprop.cc (can_propagate_from): Ditto.
* tree-ssa-propagate.cc (may_propagate_copy): Ditto.
* tree-ssa-sccvn.cc (fully_constant_vn_reference_p): Ditto.
* tree-ssa-sink.cc (statement_sink_location): Ditto.
* tree-ssa-structalias.cc (type_must_have_pointers): Ditto.
* tree-ssa-ter.cc (find_replaceable_in_bb): Ditto.
* tree-ssa-uninit.cc (warn_uninit): Ditto.
* tree-ssa.cc (maybe_rewrite_mem_ref_base): Ditto.
(non_rewritable_mem_ref_base): Ditto.
* tree-streamer-in.cc (lto_input_ts_type_non_common_tree_pointers): 
Ditto.
* tree-streamer-out.cc (write_ts_type_non_common_tree_pointers): Ditto.
* tree-vect-generic.cc (do_binop): Ditto.
(do_cond): Ditto.
* tree-vect-stmts.cc (vect_init_vector): Ditto.
* tree-vector-builder.h (tree_vector_builder::note_representative): 
Ditto.
* tree.cc

[PATCH 00/14] use _P() defines from tree.h

[Bernhard Reutner-Fischer via Gcc-patches]

From: Bernhard Reutner-Fischer 

Dear maintainers

I propose the following mechanical change to use the defines in tree.h.
(Common convention is to use the defines as per tree.h, which is what we
keep telling people.)

Exceptions applied to the generator here:
 NULL_TREE # we want to retain "NULL"
 CAN_HAVE_RANGE_P # keep CAN_HAVE_LOCATION_P; Looks confused otherwise.
 No fallback declarations considered. I.e. picks TREE_CODE_CLASS true
 branch (to pick the checking variants of tree access) and skips the
 whole true arm when seeing an extension (like DECL_RTL_KNOWN_SET).
 Case enumerations ignored (CASE_FLT_FN CASE_FLT_FN_FLOATN_NX
 CASE_BUILT_IN_TM_STORE).
 Only _P() named macros without loops are considered for starters.

Bootstrapped on x86_64-unknown-linux with
 --enable-languages=c,fortran,c++,ada,d,go,lto,jit,objc,obj-c++,rust
 (hence not m2) --enable-checking=yes --enable-multilib --disable-libstdcxx-pch
 and regtested without regressions against r14-619-g2499540e9abb55 on
 --target_board=unix'{-m32,-m64}'

Ok for trunk?
PS: I refrain from Ccing about all frontend maintainers in the hopes to
apply this squashed.

Bernhard Reutner-Fischer (14):
  ada: use _P() defines from tree.h
  analyzer: use _P() defines from tree.h
  gcc/config/*: use _P() defines from tree.h
  c++: use _P() defines from tree.h
  m2: use _P() defines from tree.h
  lto: use _P() defines from tree.h
  d: use _P() defines from tree.h
  fortran: use _P() defines from tree.h
  rust: use _P() defines from tree.h
  c: use _P() defines from tree.h
  objc: use _P() defines from tree.h
  go: use _P() defines from tree.h
  omp: use _P() defines from tree.h
  gcc: use _P() defines from tree.h

 gcc/ada/gcc-interface/decl.cc | 17 +++---
 gcc/ada/gcc-interface/trans.cc| 20 +++
 gcc/ada/gcc-interface/utils.cc| 10 ++--
 gcc/ada/gcc-interface/utils2.cc   | 16 +++---
 gcc/alias.cc  |  2 +-
 gcc/analyzer/region-model-manager.cc  |  8 +--
 gcc/analyzer/region-model.cc  |  2 +-
 gcc/analyzer/region.cc|  2 +-
 gcc/attribs.cc| 11 ++--
 gcc/builtins.cc   |  8 +--
 gcc/c-family/c-ada-spec.cc|  6 +--
 gcc/c-family/c-common.cc  | 32 ++--
 gcc/c-family/c-common.h   |  2 +-
 gcc/c-family/c-omp.cc |  5 +-
 gcc/c-family/c-ubsan.cc   |  2 +-
 gcc/c-family/c-warn.cc|  6 +--
 gcc/c/c-convert.cc|  4 +-
 gcc/c/c-decl.cc   |  6 +--
 gcc/c/c-parser.cc |  4 +-
 gcc/c/c-typeck.cc | 52 +--
 gcc/c/gimple-parser.cc|  2 +-
 gcc/cfgexpand.cc  |  2 +-
 gcc/cgraph.h  |  4 +-
 gcc/config/aarch64/aarch64.cc |  4 +-
 gcc/config/alpha/alpha.cc |  6 +--
 gcc/config/arc/arc.cc |  8 +--
 gcc/config/arm/arm.cc | 16 +++---
 gcc/config/arm/unknown-elf.h  |  2 +-
 gcc/config/avr/avr.cc | 11 ++--
 gcc/config/bfin/bfin.cc   |  2 +-
 gcc/config/bpf/bpf.cc |  2 +-
 gcc/config/c6x/c6x.cc |  4 +-
 gcc/config/csky/csky.cc   |  8 ++-
 gcc/config/darwin-c.cc|  2 +-
 gcc/config/darwin.cc  |  2 +-
 gcc/config/epiphany/epiphany.cc   |  3 +-
 gcc/config/epiphany/epiphany.h|  6 +--
 gcc/config/frv/frv.cc |  4 +-
 gcc/config/gcn/gcn-tree.cc|  2 +-
 gcc/config/gcn/gcn.cc |  4 +-
 gcc/config/h8300/h8300.cc |  2 +-
 gcc/config/i386/i386-expand.cc|  2 +-
 gcc/config/i386/i386.cc   | 20 +++
 gcc/config/i386/winnt-cxx.cc  | 12 ++---
 gcc/config/i386/winnt.cc  |  6 +--
 gcc/config/ia64/ia64.cc   |  6 +--
 gcc/config/iq2000/iq2000.cc   |  8 ++-
 gcc/config/lm32/lm32.cc   |  2 +-
 gcc/config/loongarch/loongarch.cc |  2 +-
 gcc/config/m32c/m32c.cc   |  2 +-
 gcc/config/mcore/mcore.cc |  6 +--
 gcc/config/microblaze/microblaze.cc   |  2 +-
 gcc/config/mips/mips.cc   |  2 +-
 gcc/config/mmix/mmix.cc   |  4 +-
 gcc/config/nvptx/nvptx.cc |  8 +--
 gcc/config/pa/pa.cc   | 10 ++--
 gcc/config/pa/pa.h|  4 +-
 gcc/config/pa/som.h   |  2 +-
 gcc/config/pdp1

[PATCH 09/14] rust: use _P() defines from tree.h

[Bernhard Reutner-Fischer via Gcc-patches]

From: Bernhard Reutner-Fischer 

gcc/rust/ChangeLog:

* backend/rust-compile-expr.cc (CompileExpr::type_cast_expression): Use
_P() defines from tree.h
* backend/rust-tree.cc (build_cplus_array_type): Ditto.
* backend/rust-tree.h (ARITHMETIC_TYPE_P): Ditto.
(gnu_vector_type_p): Ditto.
* checks/lints/rust-lint-unused-var.cc (check_decl): Ditto.
* rust-gcc.cc (Gcc_backend::fill_in_array): Ditto.
(Gcc_backend::named_type): Ditto.
(Gcc_backend::convert_expression): Ditto.
(Gcc_backend::init_statement): Ditto.
---
 gcc/rust/backend/rust-compile-expr.cc | 2 +-
 gcc/rust/backend/rust-tree.cc | 2 +-
 gcc/rust/backend/rust-tree.h  | 4 ++--
 gcc/rust/checks/lints/rust-lint-unused-var.cc | 2 +-
 gcc/rust/rust-gcc.cc  | 8 
 5 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/gcc/rust/backend/rust-compile-expr.cc 
b/gcc/rust/backend/rust-compile-expr.cc
index d7945dbf26b..3dc34828e32 100644
--- a/gcc/rust/backend/rust-compile-expr.cc
+++ b/gcc/rust/backend/rust-compile-expr.cc
@@ -2267,7 +2267,7 @@ CompileExpr::type_cast_expression (tree type_to_cast_to, 
tree expr_tree,
   // FIXME check for TREE_OVERFLOW?
   return cast;
 }
-  else if (TREE_CODE (type_to_cast_to) == REAL_TYPE)
+  else if (SCALAR_FLOAT_TYPE_P (type_to_cast_to))
 {
   tree cast = convert_to_real (type_to_cast_to, expr_tree);
   // FIXME
diff --git a/gcc/rust/backend/rust-tree.cc b/gcc/rust/backend/rust-tree.cc
index 8243d4cf5c6..7e11e6584ae 100644
--- a/gcc/rust/backend/rust-tree.cc
+++ b/gcc/rust/backend/rust-tree.cc
@@ -2404,7 +2404,7 @@ build_cplus_array_type (tree elt_type, tree index_type, 
int dependent)
 }
 
   /* Avoid spurious warnings with VLAs (c++/54583).  */
-  if (TYPE_SIZE (t) && EXPR_P (TYPE_SIZE (t)))
+  if (CAN_HAVE_LOCATION_P (TYPE_SIZE (t)))
 suppress_warning (TYPE_SIZE (t), OPT_Wunused);
 
   /* Push these needs up to the ARRAY_TYPE so that initialization takes
diff --git a/gcc/rust/backend/rust-tree.h b/gcc/rust/backend/rust-tree.h
index 284fd873c1c..6d243b7f86e 100644
--- a/gcc/rust/backend/rust-tree.h
+++ b/gcc/rust/backend/rust-tree.h
@@ -54,7 +54,7 @@
 
Keep these checks in ascending code order.  */
 #define ARITHMETIC_TYPE_P(TYPE)
\
-  (RS_INTEGRAL_TYPE_P (TYPE) || TREE_CODE (TYPE) == REAL_TYPE  
\
+  (RS_INTEGRAL_TYPE_P (TYPE) || SCALAR_FLOAT_TYPE_P (TYPE)   \
|| TREE_CODE (TYPE) == COMPLEX_TYPE)
 
 /* True iff TYPE is cv decltype(nullptr).  */
@@ -3250,7 +3250,7 @@ identifier_p (tree t)
 inline bool
 gnu_vector_type_p (const_tree type)
 {
-  return TREE_CODE (type) == VECTOR_TYPE && !TYPE_INDIVISIBLE_P (type);
+  return VECTOR_TYPE_P (type) && !TYPE_INDIVISIBLE_P (type);
 }
 
 extern vec *
diff --git a/gcc/rust/checks/lints/rust-lint-unused-var.cc 
b/gcc/rust/checks/lints/rust-lint-unused-var.cc
index ba5ffb9372b..2cf5cd60f15 100644
--- a/gcc/rust/checks/lints/rust-lint-unused-var.cc
+++ b/gcc/rust/checks/lints/rust-lint-unused-var.cc
@@ -25,7 +25,7 @@ namespace Analysis {
 static void
 check_decl (tree *t)
 {
-  rust_assert (TREE_CODE (*t) == VAR_DECL || TREE_CODE (*t) == PARM_DECL
+  rust_assert (VAR_P (*t) || TREE_CODE (*t) == PARM_DECL
   || TREE_CODE (*t) == CONST_DECL);
 
   tree var_name = DECL_NAME (*t);
diff --git a/gcc/rust/rust-gcc.cc b/gcc/rust/rust-gcc.cc
index cf20b5b98e0..b1995bdb56a 100644
--- a/gcc/rust/rust-gcc.cc
+++ b/gcc/rust/rust-gcc.cc
@@ -886,7 +886,7 @@ Gcc_backend::fill_in_array (tree fill, tree element_type, 
tree length_tree)
   if (element_type == error_mark_node || length_tree == error_mark_node)
 return error_mark_node;
 
-  gcc_assert (TYPE_SIZE (element_type) != NULL_TREE);
+  gcc_assert (COMPLETE_TYPE_P (element_type));
 
   length_tree = fold_convert (sizetype, length_tree);
 
@@ -923,7 +923,7 @@ Gcc_backend::named_type (const std::string , tree 
type, Location location)
   // give it whatever Rust name we have at this point.
   if (TYPE_NAME (type) == NULL_TREE
   && location.gcc_location () == BUILTINS_LOCATION
-  && (TREE_CODE (type) == INTEGER_TYPE || TREE_CODE (type) == REAL_TYPE
+  && (TREE_CODE (type) == INTEGER_TYPE || SCALAR_FLOAT_TYPE_P (type)
  || TREE_CODE (type) == COMPLEX_TYPE
  || TREE_CODE (type) == BOOLEAN_TYPE))
 {
@@ -1173,7 +1173,7 @@ Gcc_backend::convert_expression (tree type_tree, tree 
expr_tree,
 }
   else if (TREE_CODE (type_tree) == INTEGER_TYPE)
 ret = convert_to_integer (type_tree, expr_tree);
-  else if (TREE_CODE (type_tree) == REAL_TYPE)
+  else if (SCALAR_FLOAT_TYPE_P (type_tree))
 ret = convert_to_real (type_tree, expr_tree);
   else if (TREE_CODE (type_tree) == COMPLEX_TYPE)
 ret = convert_to_complex (type_tree, expr_tree);
@@ -1935,7 +1935,7 @@ Gcc_backend::init_statement

[PATCH 01/14] ada: use _P() defines from tree.h

[Bernhard Reutner-Fischer via Gcc-patches]

From: Bernhard Reutner-Fischer 

gcc/ada/ChangeLog:

* gcc-interface/decl.cc (gnat_to_gnu_entity): Use _P defines
from tree.h.
(constructor_address_p): Ditto.
(elaborate_expression_1): Ditto.
* gcc-interface/trans.cc (Identifier_to_gnu): Ditto.
(is_nrv_p): Ditto.
(Subprogram_Body_to_gnu): Ditto.
(gnat_to_gnu): Ditto.
(gnat_to_gnu_external): Ditto.
(add_decl_expr): Ditto.
(gnat_gimplify_expr): Ditto.
* gcc-interface/utils.cc (finish_record_type): Ditto.
(create_var_decl): Ditto.
* gcc-interface/utils2.cc (get_base_type): Ditto.
(build_binary_op): Ditto.
(build_unary_op): Ditto.
(gnat_protect_expr): Ditto.
(gnat_invariant_expr): Ditto.
---
 gcc/ada/gcc-interface/decl.cc   | 17 -
 gcc/ada/gcc-interface/trans.cc  | 20 ++--
 gcc/ada/gcc-interface/utils.cc  | 10 +-
 gcc/ada/gcc-interface/utils2.cc | 16 
 4 files changed, 31 insertions(+), 32 deletions(-)

diff --git a/gcc/ada/gcc-interface/decl.cc b/gcc/ada/gcc-interface/decl.cc
index 20f43de9ea9..ec61593a65b 100644
--- a/gcc/ada/gcc-interface/decl.cc
+++ b/gcc/ada/gcc-interface/decl.cc
@@ -785,7 +785,7 @@ gnat_to_gnu_entity (Entity_Id gnat_entity, tree gnu_expr, 
bool definition)
if ((TREE_CODE (gnu_type) == UNCONSTRAINED_ARRAY_TYPE
 && No (gnat_renamed_obj))
|| TYPE_IS_DUMMY_P (gnu_type)
-   || TREE_CODE (gnu_type) == VOID_TYPE)
+   || VOID_TYPE_P (gnu_type))
  {
gcc_assert (type_annotate_only);
if (this_global)
@@ -840,7 +840,7 @@ gnat_to_gnu_entity (Entity_Id gnat_entity, tree gnu_expr, 
bool definition)
if (TREE_CODE (gnu_expr) == COMPONENT_REF
&& TYPE_IS_PADDING_P
   (TREE_TYPE (TREE_OPERAND (gnu_expr, 0)))
-   && TREE_CODE (TREE_OPERAND (gnu_expr, 0)) == VAR_DECL
+   && VAR_P (TREE_OPERAND (gnu_expr, 0))
&& (TREE_READONLY (TREE_OPERAND (gnu_expr, 0))
|| DECL_READONLY_ONCE_ELAB
   (TREE_OPERAND (gnu_expr, 0
@@ -1077,7 +1077,7 @@ gnat_to_gnu_entity (Entity_Id gnat_entity, tree gnu_expr, 
bool definition)
/* We need to detect the case where a temporary is created to
   hold the return value, since we cannot safely rename it at
   top level as it lives only in the elaboration routine.  */
-   || (TREE_CODE (inner) == VAR_DECL
+   || (VAR_P (inner)
&& DECL_RETURN_VALUE_P (inner))
/* We also need to detect the case where the front-end creates
   a dangling 'reference to a function call at top level and
@@ -1093,10 +1093,10 @@ gnat_to_gnu_entity (Entity_Id gnat_entity, tree 
gnu_expr, bool definition)
 
   We cannot safely rename the rewritten expression since the
   underlying object lives only in the elaboration routine.  */
-   || (TREE_CODE (inner) == INDIRECT_REF
+   || (INDIRECT_REF_P (inner)
&& (inner
= remove_conversions (TREE_OPERAND (inner, 0), true))
-   && TREE_CODE (inner) == VAR_DECL
+   && VAR_P (inner)
&& DECL_RETURN_VALUE_P (inner)))
  ;
 
@@ -1611,7 +1611,7 @@ gnat_to_gnu_entity (Entity_Id gnat_entity, tree gnu_expr, 
bool definition)
   and optimization isn't enabled, then force it in memory so that
   a register won't be allocated to it with possible subparts left
   uninitialized and reaching the register allocator.  */
-   else if (TREE_CODE (gnu_decl) == VAR_DECL
+   else if (VAR_P (gnu_decl)
 && !DECL_EXTERNAL (gnu_decl)
 && !TREE_STATIC (gnu_decl)
 && DECL_MODE (gnu_decl) != BLKmode
@@ -6717,8 +6717,7 @@ range_cannot_be_superflat (Node_Id gnat_range)
 static bool
 constructor_address_p (tree gnu_expr)
 {
-  while (TREE_CODE (gnu_expr) == NOP_EXPR
-|| TREE_CODE (gnu_expr) == CONVERT_EXPR
+  while (CONVERT_EXPR_P (gnu_expr)
 || TREE_CODE (gnu_expr) == NON_LVALUE_EXPR)
 gnu_expr = TREE_OPERAND (gnu_expr, 0);
 
@@ -7061,7 +7060,7 @@ elaborate_expression_1 (tree gnu_expr, Entity_Id 
gnat_entity, const char *s,
 
   expr_variable_p
= !(inner
-   && TREE_CODE (inner) == VAR_DECL
+   && VAR_P (inner)
&& (TREE_READONLY (inner) || DECL_READONLY_ONCE_ELAB (inner)));
 }
 
diff --git a/gcc/ada/gcc-interface/trans.cc b/gcc/ada/gcc-interface/trans.cc
index 5fc1a26fede..c26f1b6e1ac 100644
--- a/gcc/ada/gcc-interface/trans.cc
+++ b/g

[PATCH 04/14] c++: use _P() defines from tree.h

[Bernhard Reutner-Fischer via Gcc-patches]

From: Bernhard Reutner-Fischer 

gcc/cp/ChangeLog:

* call.cc (promoted_arithmetic_type_p): Use _P defines from tree.h.
(build_conditional_expr): Ditto.
(convert_like_internal): Ditto.
(convert_arg_to_ellipsis): Ditto.
(build_over_call): Ditto.
(compare_ics): Ditto.
* class.cc (is_empty_base_ref): Ditto.
* coroutines.cc (rewrite_param_uses): Ditto.
* cp-tree.h (DECL_DISCRIMINATOR_P): Ditto.
(ARITHMETIC_TYPE_P): Ditto.
* cvt.cc (ocp_convert): Ditto.
* cxx-pretty-print.cc (pp_cxx_template_argument_list): Ditto.
* decl.cc (layout_var_decl): Ditto.
(get_tuple_size): Ditto.
* error.cc (dump_simple_decl): Ditto.
* lambda.cc (start_lambda_scope): Ditto.
* mangle.cc (write_template_arg): Ditto.
* method.cc (spaceship_comp_cat): Ditto.
* module.cc (node_template_info): Ditto.
(trees_out::start): Ditto.
(trees_out::decl_node): Ditto.
(trees_in::read_var_def): Ditto.
(set_instantiating_module): Ditto.
* name-lookup.cc (maybe_record_mergeable_decl): Ditto.
(consider_decl): Ditto.
(maybe_add_fuzzy_decl): Ditto.
* pt.cc (convert_nontype_argument): Ditto.
* semantics.cc (handle_omp_array_sections_1): Ditto.
(finish_omp_clauses): Ditto.
(finish_omp_target_clauses_r): Ditto.
(is_this_parameter): Ditto.
* tree.cc (build_cplus_array_type): Ditto.
(is_this_expression): Ditto.
* typeck.cc (do_warn_enum_conversions): Ditto.
* typeck2.cc (store_init_value): Ditto.
(check_narrowing): Ditto.
---
 gcc/cp/call.cc | 42 +++---
 gcc/cp/class.cc|  2 +-
 gcc/cp/coroutines.cc   |  2 +-
 gcc/cp/cp-tree.h   |  4 ++--
 gcc/cp/cvt.cc  |  2 +-
 gcc/cp/cxx-pretty-print.cc |  2 +-
 gcc/cp/decl.cc |  4 ++--
 gcc/cp/error.cc|  2 +-
 gcc/cp/lambda.cc   |  2 +-
 gcc/cp/mangle.cc   |  2 +-
 gcc/cp/method.cc   |  2 +-
 gcc/cp/module.cc   | 12 +--
 gcc/cp/name-lookup.cc  |  6 +++---
 gcc/cp/pt.cc   |  2 +-
 gcc/cp/semantics.cc| 24 +++---
 gcc/cp/tree.cc |  4 ++--
 gcc/cp/typeck.cc   |  4 ++--
 gcc/cp/typeck2.cc  | 10 -
 18 files changed, 64 insertions(+), 64 deletions(-)

diff --git a/gcc/cp/call.cc b/gcc/cp/call.cc
index 2a06520c0c1..6e13d17f6b8 100644
--- a/gcc/cp/call.cc
+++ b/gcc/cp/call.cc
@@ -2746,7 +2746,7 @@ promoted_arithmetic_type_p (tree type)
  integral types plus floating types.  */
   return ((CP_INTEGRAL_TYPE_P (type)
   && same_type_p (type_promotes_to (type), type))
- || TREE_CODE (type) == REAL_TYPE);
+ || SCALAR_FLOAT_TYPE_P (type));
 }
 
 /* Create any builtin operator overload candidates for the operator in
@@ -5759,10 +5759,10 @@ build_conditional_expr (const op_location_t ,
   if ((TREE_CODE (arg2) == EXCESS_PRECISION_EXPR
|| TREE_CODE (arg3) == EXCESS_PRECISION_EXPR)
   && (TREE_CODE (arg2_type) == INTEGER_TYPE
- || TREE_CODE (arg2_type) == REAL_TYPE
+ || SCALAR_FLOAT_TYPE_P (arg2_type)
  || TREE_CODE (arg2_type) == COMPLEX_TYPE)
   && (TREE_CODE (arg3_type) == INTEGER_TYPE
- || TREE_CODE (arg3_type) == REAL_TYPE
+ || SCALAR_FLOAT_TYPE_P (arg3_type)
  || TREE_CODE (arg3_type) == COMPLEX_TYPE))
 {
   semantic_result_type
@@ -5775,8 +5775,8 @@ build_conditional_expr (const op_location_t ,
t1 = TREE_TYPE (t1);
  if (TREE_CODE (t2) == COMPLEX_TYPE)
t2 = TREE_TYPE (t2);
- gcc_checking_assert (TREE_CODE (t1) == REAL_TYPE
-  && TREE_CODE (t2) == REAL_TYPE
+ gcc_checking_assert (SCALAR_FLOAT_TYPE_P (t1)
+  && SCALAR_FLOAT_TYPE_P (t2)
   && (extended_float_type_p (t1)
   || extended_float_type_p (t2))
   && cp_compare_floating_point_conversion_ranks
@@ -6127,8 +6127,8 @@ build_conditional_expr (const op_location_t ,
t1 = TREE_TYPE (t1);
  if (TREE_CODE (t2) == COMPLEX_TYPE)
t2 = TREE_TYPE (t2);
- gcc_checking_assert (TREE_CODE (t1) == REAL_TYPE
-  && TREE_CODE (t2) == REAL_TYPE
+ gcc_checking_assert (SCALAR_FLOAT_TYPE_P (t1)
+  && SCALAR_FLOAT_TYPE_P (t2)
   && (extended_float_type_p (t1)
   || extended_float_type_p (t2))
   && cp_compare_floating_point_conversion_ranks
@@ -6147,8 +6147,8 @@ build_conditional_expr (const op_location_t ,
t1 = TREE

[PATCH 03/14] gcc/config/*: use _P() defines from tree.h

[Bernhard Reutner-Fischer via Gcc-patches]

From: Bernhard Reutner-Fischer 

gcc/ChangeLog:

* config/aarch64/aarch64.cc (aarch64_short_vector_p): Use _P
defines from tree.h.
(aarch64_mangle_type): Ditto.
* config/alpha/alpha.cc (alpha_in_small_data_p): Ditto.
(alpha_gimplify_va_arg_1): Ditto.
* config/arc/arc.cc (arc_encode_section_info): Ditto.
(arc_is_aux_reg_p): Ditto.
(arc_is_uncached_mem_p): Ditto.
(arc_handle_aux_attribute): Ditto.
* config/arm/arm.cc (arm_handle_isr_attribute): Ditto.
(arm_handle_cmse_nonsecure_call): Ditto.
(arm_set_default_type_attributes): Ditto.
(arm_is_segment_info_known): Ditto.
(arm_mangle_type): Ditto.
* config/arm/unknown-elf.h (IN_NAMED_SECTION_P): Ditto.
* config/avr/avr.cc (avr_lookup_function_attribute1): Ditto.
(avr_decl_absdata_p): Ditto.
(avr_insert_attributes): Ditto.
(avr_section_type_flags): Ditto.
(avr_encode_section_info): Ditto.
* config/bfin/bfin.cc (bfin_handle_l2_attribute): Ditto.
* config/bpf/bpf.cc (bpf_core_compute): Ditto.
* config/c6x/c6x.cc (c6x_in_small_data_p): Ditto.
* config/csky/csky.cc (csky_handle_isr_attribute): Ditto.
(csky_mangle_type): Ditto.
* config/darwin-c.cc (darwin_pragma_unused): Ditto.
* config/darwin.cc (is_objc_metadata): Ditto.
* config/epiphany/epiphany.cc (epiphany_function_ok_for_sibcall): Ditto.
* config/epiphany/epiphany.h (ROUND_TYPE_ALIGN): Ditto.
* config/frv/frv.cc (frv_emit_movsi): Ditto.
* config/gcn/gcn-tree.cc (gcn_lockless_update): Ditto.
* config/gcn/gcn.cc (gcn_asm_output_symbol_ref): Ditto.
* config/h8300/h8300.cc (h8300_encode_section_info): Ditto.
* config/i386/i386-expand.cc: Ditto.
* config/i386/i386.cc (type_natural_mode): Ditto.
(ix86_function_arg): Ditto.
(ix86_data_alignment): Ditto.
(ix86_local_alignment): Ditto.
(ix86_simd_clone_compute_vecsize_and_simdlen): Ditto.
* config/i386/winnt-cxx.cc (i386_pe_type_dllimport_p): Ditto.
(i386_pe_type_dllexport_p): Ditto.
(i386_pe_adjust_class_at_definition): Ditto.
* config/i386/winnt.cc (i386_pe_determine_dllimport_p): Ditto.
(i386_pe_binds_local_p): Ditto.
(i386_pe_section_type_flags): Ditto.
* config/ia64/ia64.cc (ia64_encode_section_info): Ditto.
(ia64_gimplify_va_arg): Ditto.
(ia64_in_small_data_p): Ditto.
* config/iq2000/iq2000.cc (iq2000_function_arg): Ditto.
* config/lm32/lm32.cc (lm32_in_small_data_p): Ditto.
* config/loongarch/loongarch.cc (loongarch_handle_model_attribute): 
Ditto.
* config/m32c/m32c.cc (m32c_insert_attributes): Ditto.
* config/mcore/mcore.cc (mcore_mark_dllimport): Ditto.
(mcore_encode_section_info): Ditto.
* config/microblaze/microblaze.cc (microblaze_elf_in_small_data_p): 
Ditto.
* config/mips/mips.cc (mips_output_aligned_decl_common): Ditto.
* config/mmix/mmix.cc (mmix_encode_section_info): Ditto.
* config/nvptx/nvptx.cc (nvptx_encode_section_info): Ditto.
(pass_in_memory): Ditto.
(nvptx_generate_vector_shuffle): Ditto.
(nvptx_lockless_update): Ditto.
* config/pa/pa.cc (pa_function_arg_padding): Ditto.
(pa_function_value): Ditto.
(pa_function_arg): Ditto.
* config/pa/pa.h (IN_NAMED_SECTION_P): Ditto.
(TEXT_SPACE_P): Ditto.
* config/pa/som.h (MAKE_DECL_ONE_ONLY): Ditto.
* config/pdp11/pdp11.cc (pdp11_return_in_memory): Ditto.
* config/riscv/riscv.cc (riscv_in_small_data_p): Ditto.
(riscv_mangle_type): Ditto.
* config/rl78/rl78.cc (rl78_insert_attributes): Ditto.
(rl78_addsi3_internal): Ditto.
* config/rs6000/aix.h (ROUND_TYPE_ALIGN): Ditto.
* config/rs6000/darwin.h (ROUND_TYPE_ALIGN): Ditto.
* config/rs6000/freebsd64.h (ROUND_TYPE_ALIGN): Ditto.
* config/rs6000/linux64.h (ROUND_TYPE_ALIGN): Ditto.
* config/rs6000/rs6000-call.cc (rs6000_function_arg_boundary): Ditto.
(rs6000_function_arg_advance_1): Ditto.
(rs6000_function_arg): Ditto.
(rs6000_pass_by_reference): Ditto.
* config/rs6000/rs6000-logue.cc (rs6000_function_ok_for_sibcall): Ditto.
* config/rs6000/rs6000.cc (rs6000_data_alignment): Ditto.
(rs6000_set_default_type_attributes): Ditto.
(rs6000_elf_in_small_data_p): Ditto.
(IN_NAMED_SECTION): Ditto.
(rs6000_xcoff_encode_section_info): Ditto.
(rs6000_function_value): Ditto.
(invalid_arg_for_unprototyped_fn): Ditto.
* config/s390/s390-c.cc (s390_fn_types_compatible): Ditto.
(s390_vec_n_elem): Ditto.
* config/s390/s390.cc (s390_check_type_for_vector_abi): Ditto.
(s390_function_arg_integer): Ditto.
(s390_return_in_memory): Ditto

[PATCH 08/14] fortran: use _P() defines from tree.h

[Bernhard Reutner-Fischer via Gcc-patches]

From: Bernhard Reutner-Fischer 

gcc/fortran/ChangeLog:

* trans-array.cc (is_pointer_array): Use _P() defines from tree.h.
(gfc_conv_scalarized_array_ref): Ditto.
(gfc_conv_array_ref): Ditto.
* trans-decl.cc (gfc_finish_decl): Ditto.
(gfc_get_symbol_decl): Ditto.
* trans-expr.cc (gfc_trans_pointer_assignment): Ditto.
(gfc_trans_arrayfunc_assign): Ditto.
(gfc_trans_assignment_1): Ditto.
* trans-intrinsic.cc (gfc_conv_intrinsic_minmax): Ditto.
(conv_intrinsic_ieee_value): Ditto.
* trans-io.cc (gfc_convert_array_to_string): Ditto.
* trans-openmp.cc (gfc_omp_is_optional_argument): Ditto.
(gfc_trans_omp_clauses): Ditto.
* trans-stmt.cc (gfc_conv_label_variable): Ditto.
* trans.cc (gfc_build_addr_expr): Ditto.
(get_array_span): Ditto.
---
 gcc/fortran/trans-array.cc | 10 +-
 gcc/fortran/trans-decl.cc  |  4 ++--
 gcc/fortran/trans-expr.cc  |  6 +++---
 gcc/fortran/trans-intrinsic.cc |  4 ++--
 gcc/fortran/trans-io.cc|  2 +-
 gcc/fortran/trans-openmp.cc|  7 +++
 gcc/fortran/trans-stmt.cc  |  2 +-
 gcc/fortran/trans.cc   |  4 ++--
 8 files changed, 19 insertions(+), 20 deletions(-)

diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc
index 9f8aa09673a..15719845ca8 100644
--- a/gcc/fortran/trans-array.cc
+++ b/gcc/fortran/trans-array.cc
@@ -880,7 +880,7 @@ is_pointer_array (tree expr)
   || GFC_CLASS_TYPE_P (TREE_TYPE (expr)))
 return false;
 
-  if (TREE_CODE (expr) == VAR_DECL
+  if (VAR_P (expr)
   && GFC_DECL_PTR_ARRAY_P (expr))
 return true;
 
@@ -888,7 +888,7 @@ is_pointer_array (tree expr)
   && GFC_DECL_PTR_ARRAY_P (expr))
 return true;
 
-  if (TREE_CODE (expr) == INDIRECT_REF
+  if (INDIRECT_REF_P (expr)
   && GFC_DECL_PTR_ARRAY_P (TREE_OPERAND (expr, 0)))
 return true;
 
@@ -3803,7 +3803,7 @@ gfc_conv_scalarized_array_ref (gfc_se * se, gfc_array_ref 
* ar,
 {
   if (TREE_CODE (info->descriptor) == COMPONENT_REF)
decl = info->descriptor;
-  else if (TREE_CODE (info->descriptor) == INDIRECT_REF)
+  else if (INDIRECT_REF_P (info->descriptor))
decl = TREE_OPERAND (info->descriptor, 0);
 
   if (decl == NULL_TREE)
@@ -4057,7 +4057,7 @@ gfc_conv_array_ref (gfc_se * se, gfc_array_ref * ar, 
gfc_expr *expr,
 {
   if (TREE_CODE (se->expr) == COMPONENT_REF)
decl = se->expr;
-  else if (TREE_CODE (se->expr) == INDIRECT_REF)
+  else if (INDIRECT_REF_P (se->expr))
decl = TREE_OPERAND (se->expr, 0);
   else
decl = se->expr;
@@ -4069,7 +4069,7 @@ gfc_conv_array_ref (gfc_se * se, gfc_array_ref * ar, 
gfc_expr *expr,
   if (GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (se->expr)))
{
  decl = se->expr;
- if (TREE_CODE (decl) == INDIRECT_REF)
+ if (INDIRECT_REF_P (decl))
decl = TREE_OPERAND (decl, 0);
}
   else
diff --git a/gcc/fortran/trans-decl.cc b/gcc/fortran/trans-decl.cc
index cd32542eb86..7f21dc2b09f 100644
--- a/gcc/fortran/trans-decl.cc
+++ b/gcc/fortran/trans-decl.cc
@@ -558,7 +558,7 @@ gfc_finish_decl (tree decl)
 return;
 
   if (DECL_SIZE (decl) == NULL_TREE
-  && TYPE_SIZE (TREE_TYPE (decl)) != NULL_TREE)
+  && COMPLETE_TYPE_P (TREE_TYPE (decl)))
 layout_decl (decl, 0);
 
   /* A few consistency checks.  */
@@ -1889,7 +1889,7 @@ gfc_get_symbol_decl (gfc_symbol * sym)
   length = fold_convert (gfc_charlen_type_node, length);
   gfc_finish_var_decl (length, sym);
   if (!sym->attr.associate_var
- && TREE_CODE (length) == VAR_DECL
+ && VAR_P (length)
  && sym->value && sym->value->expr_type != EXPR_NULL
  && sym->value->ts.u.cl->length)
{
diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index d902e8f3281..292aba76aaa 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -10246,7 +10246,7 @@ gfc_trans_pointer_assignment (gfc_expr * expr1, 
gfc_expr * expr2)
  gfc_conv_descriptor_data_set (, desc, data);
 
  /* Copy the span.  */
- if (TREE_CODE (rse.expr) == VAR_DECL
+ if (VAR_P (rse.expr)
  && GFC_DECL_PTR_ARRAY_P (rse.expr))
span = gfc_conv_descriptor_span_get (rse.expr);
  else
@@ -10933,7 +10933,7 @@ gfc_trans_arrayfunc_assign (gfc_expr * expr1, gfc_expr 
* expr2)
 {
   tmp = sym->backend_decl;
   lhs = sym->backend_decl;
-  if (TREE_CODE (tmp) == INDIRECT_REF)
+  if (INDIRECT_REF_P (tmp))
tmp = TREE_OPERAND (tmp, 0);
   sym->backend_decl = gfc_create_var (TREE_TYPE (tmp), "lhs");
   gfc_add_modify (, sym->backend_decl, tmp);
@@ -11883,7 +11883,7 @@ gfc_

[PATCH 05/14] m2: use _P() defines from tree.h

[Bernhard Reutner-Fischer via Gcc-patches]

From: Bernhard Reutner-Fischer 

gcc/m2/ChangeLog:

* gm2-gcc/m2builtins.cc (doradix): Use _P defines from tree.h.
(doplaces): Ditto.
(doexponentmin): Ditto.
(doexponentmax): Ditto.
(dolarge): Ditto.
(dosmall): Ditto.
(dogUnderflow): Ditto.
* gm2-gcc/m2convert.cc (unsafe_conversion_p): Ditto.
* gm2-gcc/m2expr.cc (m2expr_build_unary_op_check): Ditto.
(m2expr_build_binary_op_check): Ditto.
* gm2-gcc/m2tree.cc (m2tree_is_var): Ditto.
* gm2-gcc/m2treelib.cc (build_modify_expr): Ditto.
* gm2-gcc/m2type.cc (gm2_finish_decl): Ditto.
* m2pp.cc (hextree): Ditto.
(m2pp_call_expr): Ditto.
---
 gcc/m2/gm2-gcc/m2builtins.cc | 14 +++---
 gcc/m2/gm2-gcc/m2convert.cc  |  8 
 gcc/m2/gm2-gcc/m2expr.cc |  4 ++--
 gcc/m2/gm2-gcc/m2tree.cc |  2 +-
 gcc/m2/gm2-gcc/m2treelib.cc  |  2 +-
 gcc/m2/gm2-gcc/m2type.cc |  4 ++--
 gcc/m2/m2pp.cc   |  4 ++--
 7 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/gcc/m2/gm2-gcc/m2builtins.cc b/gcc/m2/gm2-gcc/m2builtins.cc
index 8d104c41a1e..3d13e2018d7 100644
--- a/gcc/m2/gm2-gcc/m2builtins.cc
+++ b/gcc/m2/gm2-gcc/m2builtins.cc
@@ -552,7 +552,7 @@ m2builtins_GetBuiltinTypeInfo (location_t location, tree 
type,
 static tree
 doradix (location_t location ATTRIBUTE_UNUSED, tree type)
 {
-  if (TREE_CODE (type) == REAL_TYPE)
+  if (SCALAR_FLOAT_TYPE_P (type))
 {
   enum machine_mode mode = TYPE_MODE (type);
   int radix = REAL_MODE_FORMAT (mode)->b;
@@ -568,7 +568,7 @@ doradix (location_t location ATTRIBUTE_UNUSED, tree type)
 static tree
 doplaces (location_t location ATTRIBUTE_UNUSED, tree type)
 {
-  if (TREE_CODE (type) == REAL_TYPE)
+  if (SCALAR_FLOAT_TYPE_P (type))
 {
   /* Taken from c-family/c-cppbuiltin.cc.  */
   /* The number of decimal digits, q, such that any floating-point
@@ -592,7 +592,7 @@ doplaces (location_t location ATTRIBUTE_UNUSED, tree type)
 static tree
 doexponentmin (location_t location ATTRIBUTE_UNUSED, tree type)
 {
-  if (TREE_CODE (type) == REAL_TYPE)
+  if (SCALAR_FLOAT_TYPE_P (type))
 {
   enum machine_mode mode = TYPE_MODE (type);
   int emin = REAL_MODE_FORMAT (mode)->emin;
@@ -607,7 +607,7 @@ doexponentmin (location_t location ATTRIBUTE_UNUSED, tree 
type)
 static tree
 doexponentmax (location_t location ATTRIBUTE_UNUSED, tree type)
 {
-  if (TREE_CODE (type) == REAL_TYPE)
+  if (SCALAR_FLOAT_TYPE_P (type))
 {
   enum machine_mode mode = TYPE_MODE (type);
   int emax = REAL_MODE_FORMAT (mode)->emax;
@@ -640,7 +640,7 @@ computeLarge (tree type)
 static tree
 dolarge (location_t location ATTRIBUTE_UNUSED, tree type)
 {
-  if (TREE_CODE (type) == REAL_TYPE)
+  if (SCALAR_FLOAT_TYPE_P (type))
 return computeLarge (type);
   return NULL_TREE;
 }
@@ -667,7 +667,7 @@ computeSmall (tree type)
 static tree
 dosmall (location_t location ATTRIBUTE_UNUSED, tree type)
 {
-  if (TREE_CODE (type) == REAL_TYPE)
+  if (SCALAR_FLOAT_TYPE_P (type))
 return computeSmall (type);
   return NULL_TREE;
 }
@@ -735,7 +735,7 @@ dorounds (location_t location ATTRIBUTE_UNUSED, tree type 
ATTRIBUTE_UNUSED)
 static tree
 dogUnderflow (location_t location ATTRIBUTE_UNUSED, tree type)
 {
-  if (TREE_CODE (type) == REAL_TYPE)
+  if (SCALAR_FLOAT_TYPE_P (type))
 {
   enum machine_mode mode = TYPE_MODE (type);
   const struct real_format *fmt = REAL_MODE_FORMAT (mode);
diff --git a/gcc/m2/gm2-gcc/m2convert.cc b/gcc/m2/gm2-gcc/m2convert.cc
index f806669dc39..5d35bcee239 100644
--- a/gcc/m2/gm2-gcc/m2convert.cc
+++ b/gcc/m2/gm2-gcc/m2convert.cc
@@ -91,7 +91,7 @@ unsafe_conversion_p (location_t loc, tree type, tree expr, 
bool produce_warns)
 
   /* Warn for real constant that is not an exact integer converted to
  integer type.  */
-  if (TREE_CODE (expr_type) == REAL_TYPE
+  if (SCALAR_FLOAT_TYPE_P (expr_type)
   && TREE_CODE (type) == INTEGER_TYPE)
 {
   if (!real_isinteger (TREE_REAL_CST_PTR (expr),
@@ -121,7 +121,7 @@ unsafe_conversion_p (location_t loc, tree type, tree expr, 
bool produce_warns)
   else
 give_warning = UNSAFE_OTHER;
 }
-  else if (TREE_CODE (type) == REAL_TYPE)
+  else if (SCALAR_FLOAT_TYPE_P (type))
 {
   /* Warn for an integer constant that does not fit into real type.  */
   if (TREE_CODE (expr_type) == INTEGER_TYPE)
@@ -133,7 +133,7 @@ unsafe_conversion_p (location_t loc, tree type, tree expr, 
bool produce_warns)
 
   /* Warn for a real constant that does not fit into a smaller real
   type.  */
-  else if (TREE_CODE (expr_type) == REAL_TYPE
+ else if (SCALAR_FLOAT_TYPE_P (expr_type)
&& TYPE_PRECISION (type) < TYPE_PRECISION (expr_type))
 {
   REAL_VALUE_TYPE a = TREE_REAL_CST (expr);
@@ -145,7 +145,7 @@ unsafe_conversion_p (loc

[PATCH 11/14] objc: use _P() defines from tree.h

[Bernhard Reutner-Fischer via Gcc-patches]

From: Bernhard Reutner-Fischer 

gcc/objc/ChangeLog:

* objc-act.cc (objc_volatilize_decl): Use _P() defines from tree.h.
(objc_is_global_reference_p): Ditto.
(objc_generate_write_barrier): Ditto.
(objc_gimplify_property_ref): Ditto.
* objc-next-runtime-abi-01.cc 
(next_runtime_abi_01_receiver_is_class_object): Ditto.
* objc-next-runtime-abi-02.cc 
(next_runtime_abi_02_receiver_is_class_object): Ditto.
(next_runtime_abi_02_build_objc_method_call): Ditto.
---
 gcc/objc/objc-act.cc | 10 +-
 gcc/objc/objc-next-runtime-abi-01.cc |  2 +-
 gcc/objc/objc-next-runtime-abi-02.cc |  4 ++--
 3 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/gcc/objc/objc-act.cc b/gcc/objc/objc-act.cc
index 08201749207..e4c49e664e1 100644
--- a/gcc/objc/objc-act.cc
+++ b/gcc/objc/objc-act.cc
@@ -2338,7 +2338,7 @@ objc_volatilize_decl (tree decl)
   /* Do not mess with variables that are 'static' or (already)
  'volatile'.  */
   if (!TREE_THIS_VOLATILE (decl) && !TREE_STATIC (decl)
-  && (TREE_CODE (decl) == VAR_DECL
+  && (VAR_P (decl)
  || TREE_CODE (decl) == PARM_DECL))
 {
   if (local_variables_to_volatilize == NULL)
@@ -3793,7 +3793,7 @@ objc_is_ivar_reference_p (tree expr)
 static int
 objc_is_global_reference_p (tree expr)
 {
-  return (TREE_CODE (expr) == INDIRECT_REF || TREE_CODE (expr) == PLUS_EXPR
+  return (INDIRECT_REF_P (expr) || TREE_CODE (expr) == PLUS_EXPR
  ? objc_is_global_reference_p (TREE_OPERAND (expr, 0))
  : DECL_P (expr)
  ? (DECL_FILE_SCOPE_P (expr) || TREE_STATIC (expr))
@@ -3812,7 +3812,7 @@ objc_generate_write_barrier (tree lhs, enum tree_code 
modifycode, tree rhs)
 
   /* See if we have any lhs casts, and strip them out.  NB: The lvalue casts
  will have been transformed to the form '*(type *)'.  */
-  if (TREE_CODE (lhs) == INDIRECT_REF)
+  if (INDIRECT_REF_P (lhs))
 {
   outer = TREE_OPERAND (lhs, 0);
 
@@ -3864,7 +3864,7 @@ objc_generate_write_barrier (tree lhs, enum tree_code 
modifycode, tree rhs)
 || TREE_CODE (outer) == ARRAY_REF))
 outer = TREE_OPERAND (outer, 0);
 
-  if (TREE_CODE (outer) == INDIRECT_REF)
+  if (INDIRECT_REF_P (outer))
 {
   outer = TREE_OPERAND (outer, 0);
   indirect_p = 1;
@@ -9694,7 +9694,7 @@ objc_gimplify_property_ref (tree *expr_p)
   if (TREE_CODE (getter) == TARGET_EXPR)
 {
   gcc_assert (MAYBE_CLASS_TYPE_P (TREE_TYPE (getter)));
-  gcc_assert (TREE_CODE (TREE_OPERAND (getter, 0)) == VAR_DECL);
+  gcc_assert (VAR_P (TREE_OPERAND (getter, 0)));
   call_exp = TREE_OPERAND (getter, 1);
 }
 #endif
diff --git a/gcc/objc/objc-next-runtime-abi-01.cc 
b/gcc/objc/objc-next-runtime-abi-01.cc
index 8f68f784efe..70ab5262e17 100644
--- a/gcc/objc/objc-next-runtime-abi-01.cc
+++ b/gcc/objc/objc-next-runtime-abi-01.cc
@@ -754,7 +754,7 @@ next_runtime_abi_01_get_arg_type_list_base (vec **argtypes,
 static tree
 next_runtime_abi_01_receiver_is_class_object (tree receiver)
 {
-  if (TREE_CODE (receiver) == VAR_DECL
+  if (VAR_P (receiver)
   && IS_CLASS (TREE_TYPE (receiver)))
 {
   /* The receiver is a variable created by build_class_reference_decl.  */
diff --git a/gcc/objc/objc-next-runtime-abi-02.cc 
b/gcc/objc/objc-next-runtime-abi-02.cc
index bcfc0ce8e19..6548c0078e0 100644
--- a/gcc/objc/objc-next-runtime-abi-02.cc
+++ b/gcc/objc/objc-next-runtime-abi-02.cc
@@ -1571,7 +1571,7 @@ next_runtime_abi_02_get_category_super_ref (location_t 
loc ATTRIBUTE_UNUSED,
 static tree
 next_runtime_abi_02_receiver_is_class_object (tree receiver)
 {
-  if (TREE_CODE (receiver) == VAR_DECL
+  if (VAR_P (receiver)
   && IS_CLASS (TREE_TYPE (receiver))
   && vec_safe_length (classrefs))
 {
@@ -1824,7 +1824,7 @@ next_runtime_abi_02_build_objc_method_call (location_t 
loc,
   checked.  */
   bool check_for_nil = flag_objc_nilcheck;
   if (super
-  || (TREE_CODE (receiver) == VAR_DECL
+  || (VAR_P (receiver)
  && TREE_TYPE (receiver) == objc_class_type))
 check_for_nil = false;
 
-- 
2.30.2

[PATCH 12/14] go: use _P() defines from tree.h

[Bernhard Reutner-Fischer via Gcc-patches]

From: Bernhard Reutner-Fischer 

gcc/go/ChangeLog:

* go-gcc.cc (Gcc_backend::fill_in_array): Use _P() defines from tree.h.
(Gcc_backend::named_type): Ditto.
(Gcc_backend::convert_expression): Ditto.
(operator_to_tree_code): Ditto.
(Gcc_backend::init_statement): Ditto.

gcc/ChangeLog:

* godump.cc (go_format_type): Ditto.
(go_output_typedef): Ditto.
---
 gcc/go/go-gcc.cc | 10 +-
 gcc/godump.cc|  4 ++--
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/gcc/go/go-gcc.cc b/gcc/go/go-gcc.cc
index 41ae9f83731..ad001a9044a 100644
--- a/gcc/go/go-gcc.cc
+++ b/gcc/go/go-gcc.cc
@@ -1168,7 +1168,7 @@ Gcc_backend::fill_in_array(Btype* fill, Btype* 
element_type,
   if (element_type_tree == error_mark_node || length_tree == error_mark_node)
 return this->error_type();
 
-  gcc_assert(TYPE_SIZE(element_type_tree) != NULL_TREE);
+  gcc_assert (COMPLETE_TYPE_P (element_type_tree));
 
   length_tree = fold_convert(sizetype, length_tree);
 
@@ -1347,7 +1347,7 @@ Gcc_backend::named_type(const std::string& name, Btype* 
btype,
   if (TYPE_NAME(type) == NULL_TREE
   && location.gcc_location() == BUILTINS_LOCATION
   && (TREE_CODE(type) == INTEGER_TYPE
- || TREE_CODE(type) == REAL_TYPE
+ || SCALAR_FLOAT_TYPE_P (type)
  || TREE_CODE(type) == COMPLEX_TYPE
  || TREE_CODE(type) == BOOLEAN_TYPE))
 {
@@ -1670,7 +1670,7 @@ Gcc_backend::convert_expression(Btype* type, Bexpression* 
expr,
 }
   else if (TREE_CODE(type_tree) == INTEGER_TYPE)
 ret = fold(convert_to_integer(type_tree, expr_tree));
-  else if (TREE_CODE(type_tree) == REAL_TYPE)
+  else if (SCALAR_FLOAT_TYPE_P (type_tree))
 ret = fold(convert_to_real(type_tree, expr_tree));
   else if (TREE_CODE(type_tree) == COMPLEX_TYPE)
 ret = fold(convert_to_complex(type_tree, expr_tree));
@@ -1880,7 +1880,7 @@ operator_to_tree_code(Operator op, tree type)
   code = MULT_EXPR;
   break;
 case OPERATOR_DIV:
-  if (TREE_CODE(type) == REAL_TYPE || TREE_CODE(type) == COMPLEX_TYPE)
+  if (SCALAR_FLOAT_TYPE_P (type) || TREE_CODE (type) == COMPLEX_TYPE)
code = RDIV_EXPR;
   else
code = TRUNC_DIV_EXPR;
@@ -2223,7 +2223,7 @@ Gcc_backend::init_statement(Bfunction*, Bvariable* var, 
Bexpression* init)
   tree init_tree = init->get_tree();
   if (var_tree == error_mark_node || init_tree == error_mark_node)
 return this->error_statement();
-  gcc_assert(TREE_CODE(var_tree) == VAR_DECL);
+  gcc_assert (VAR_P (var_tree));
 
   // To avoid problems with GNU ld, we don't make zero-sized
   // externally visible variables.  That might lead us to doing an
diff --git a/gcc/godump.cc b/gcc/godump.cc
index 0893d5fbc97..1a62753af12 100644
--- a/gcc/godump.cc
+++ b/gcc/godump.cc
@@ -791,7 +791,7 @@ go_format_type (class godump_container *container, tree 
type,
tree real_type;
 
real_type = TREE_TYPE (type);
-   if (TREE_CODE (real_type) == REAL_TYPE)
+   if (SCALAR_FLOAT_TYPE_P (real_type))
  {
switch (TYPE_PRECISION (real_type))
  {
@@ -1100,7 +1100,7 @@ go_output_typedef (class godump_container *container, 
tree decl)
   if (TREE_CODE (TREE_TYPE (decl)) == ENUMERAL_TYPE
   && TYPE_SIZE (TREE_TYPE (decl)) != 0
   && !container->decls_seen.contains (TREE_TYPE (decl))
-  && (TYPE_CANONICAL (TREE_TYPE (decl)) == NULL_TREE
+  && (TYPE_STRUCTURAL_EQUALITY_P (TREE_TYPE (decl))
  || !container->decls_seen.contains
(TYPE_CANONICAL (TREE_TYPE (decl)
 {
-- 
2.30.2

[PATCH 13/14] omp: use _P() defines from tree.h

[Bernhard Reutner-Fischer via Gcc-patches]

From: Bernhard Reutner-Fischer 

gcc/ChangeLog:

* omp-low.cc (scan_sharing_clauses): Use _P() defines from tree.h.
(lower_reduction_clauses): Ditto.
(lower_send_clauses): Ditto.
(lower_omp_task_reductions): Ditto.
* omp-oacc-neuter-broadcast.cc (install_var_field): Ditto.
(worker_single_copy): Ditto.
* omp-offload.cc (oacc_rewrite_var_decl): Ditto.
* omp-simd-clone.cc (plausible_type_for_simd_clone): Ditto.
---
 gcc/omp-low.cc   | 36 
 gcc/omp-oacc-neuter-broadcast.cc | 10 -
 gcc/omp-offload.cc   |  2 +-
 gcc/omp-simd-clone.cc|  2 +-
 4 files changed, 25 insertions(+), 25 deletions(-)

diff --git a/gcc/omp-low.cc b/gcc/omp-low.cc
index dddf5b59d8f..9db33d2a48b 100644
--- a/gcc/omp-low.cc
+++ b/gcc/omp-low.cc
@@ -1267,7 +1267,7 @@ scan_sharing_clauses (tree clauses, omp_context *ctx)
  tree t = TREE_OPERAND (decl, 0);
  if (TREE_CODE (t) == POINTER_PLUS_EXPR)
t = TREE_OPERAND (t, 0);
- if (TREE_CODE (t) == INDIRECT_REF
+ if (INDIRECT_REF_P (t)
  || TREE_CODE (t) == ADDR_EXPR)
t = TREE_OPERAND (t, 0);
  if (is_omp_target (ctx->stmt))
@@ -1276,7 +1276,7 @@ scan_sharing_clauses (tree clauses, omp_context *ctx)
{
  gcc_assert (DECL_HAS_VALUE_EXPR_P (t));
  t = DECL_VALUE_EXPR (t);
- gcc_assert (TREE_CODE (t) == INDIRECT_REF);
+ gcc_assert (INDIRECT_REF_P (t));
  t = TREE_OPERAND (t, 0);
  gcc_assert (DECL_P (t));
}
@@ -1383,7 +1383,7 @@ scan_sharing_clauses (tree clauses, omp_context *ctx)
}
  else if (OMP_CLAUSE_CODE (c) == OMP_CLAUSE_HAS_DEVICE_ADDR)
{
- if (TREE_CODE (decl) == INDIRECT_REF)
+ if (INDIRECT_REF_P (decl))
decl = TREE_OPERAND (decl, 0);
  install_var_field (decl, true, 3, ctx);
}
@@ -1457,7 +1457,7 @@ scan_sharing_clauses (tree clauses, omp_context *ctx)
  && TREE_CODE (DECL_SIZE (decl)) != INTEGER_CST)
{
  tree decl2 = DECL_VALUE_EXPR (decl);
- gcc_assert (TREE_CODE (decl2) == INDIRECT_REF);
+ gcc_assert (INDIRECT_REF_P (decl2));
  decl2 = TREE_OPERAND (decl2, 0);
  gcc_assert (DECL_P (decl2));
  install_var_local (decl2, ctx);
@@ -1467,7 +1467,7 @@ scan_sharing_clauses (tree clauses, omp_context *ctx)
 
case OMP_CLAUSE_HAS_DEVICE_ADDR:
  decl = OMP_CLAUSE_DECL (c);
- while (TREE_CODE (decl) == INDIRECT_REF
+ while (INDIRECT_REF_P (decl)
 || TREE_CODE (decl) == ARRAY_REF)
decl = TREE_OPERAND (decl, 0);
  goto do_private;
@@ -1635,7 +1635,7 @@ scan_sharing_clauses (tree clauses, omp_context *ctx)
  == GOMP_MAP_FIRSTPRIVATE_REFERENCE)))
{
  if (TREE_CODE (decl) == COMPONENT_REF
- || (TREE_CODE (decl) == INDIRECT_REF
+ || (INDIRECT_REF_P (decl)
  && TREE_CODE (TREE_OPERAND (decl, 0)) == COMPONENT_REF
  && (((TREE_CODE (TREE_TYPE (TREE_OPERAND (decl, 0)))
== REFERENCE_TYPE)
@@ -1646,7 +1646,7 @@ scan_sharing_clauses (tree clauses, omp_context *ctx)
  && TREE_CODE (DECL_SIZE (decl)) != INTEGER_CST)
{
  tree decl2 = DECL_VALUE_EXPR (decl);
- gcc_assert (TREE_CODE (decl2) == INDIRECT_REF);
+ gcc_assert (INDIRECT_REF_P (decl2));
  decl2 = TREE_OPERAND (decl2, 0);
  gcc_assert (DECL_P (decl2));
  install_var_local (decl2, ctx);
@@ -1660,7 +1660,7 @@ scan_sharing_clauses (tree clauses, omp_context *ctx)
  && TREE_CODE (DECL_SIZE (decl)) != INTEGER_CST)
{
  tree decl2 = DECL_VALUE_EXPR (decl);
- gcc_assert (TREE_CODE (decl2) == INDIRECT_REF);
+ gcc_assert (INDIRECT_REF_P (decl2));
  decl2 = TREE_OPERAND (decl2, 0);
  gcc_assert (DECL_P (decl2));
  install_var_field (decl2, true, 3, ctx);
@@ -1802,7 +1802,7 @@ scan_sharing_clauses (tree clauses, omp_context *ctx)
  decl = OMP_CLAUSE_DECL (c);
  if (OMP_CLAUSE_CODE (c) == OMP_CLAUSE_HAS_DEVICE_ADDR)
{
- while (TREE_CODE (decl) == INDIRECT_REF
+ while (INDIRECT_REF_P (decl)
 || TREE_CODE (decl) == ARRAY_REF)
decl = TREE_OPERAND (decl, 0);
}
@@ -1815,7 +1815,7 @@ scan_sharing_clauses (tree clauses, omp_context *ctx)

[PATCH 10/14] c: use _P() defines from tree.h

[Bernhard Reutner-Fischer via Gcc-patches]

From: Bernhard Reutner-Fischer 

gcc/c-family/ChangeLog:

* c-ada-spec.cc (has_static_fields): Use _P() defines from tree.h.
(dump_ada_declaration): Ditto.
(dump_ada_structure): Ditto.
* c-common.cc (unsafe_conversion_p): Ditto.
(shorten_compare): Ditto.
(pointer_int_sum): Ditto.
(c_common_truthvalue_conversion): Ditto.
(scalar_to_vector): Ditto.
* c-common.h (gnu_vector_type_p): Ditto.
* c-omp.cc (c_omp_depend_t_p): Ditto.
(c_omp_split_clauses): Ditto.
* c-ubsan.cc (ubsan_instrument_division): Ditto.
* c-warn.cc (conversion_warning): Ditto.
(warnings_for_convert_and_check): Ditto.

gcc/c/ChangeLog:

* c-convert.cc (c_convert): Ditto.
* c-decl.cc (merge_decls): Ditto.
* c-parser.cc (c_parser_omp_clause_reduction): Ditto.
(c_parser_omp_declare_reduction): Ditto.
* c-typeck.cc (build_component_ref): Ditto.
(convert_argument): Ditto.
(pointer_diff): Ditto.
(build_unary_op): Ditto.
(build_c_cast): Ditto.
(build_modify_expr): Ditto.
(store_init_value): Ditto.
(constexpr_init_fits_real_type): Ditto.
(check_constexpr_init): Ditto.
(c_finish_return): Ditto.
(handle_omp_array_sections_1): Ditto.
(c_finish_omp_clauses): Ditto.
* gimple-parser.cc (c_finish_gimple_return): Ditto.

libcc1/ChangeLog:

* libcc1plugin.cc (plugin_float_type): Ditto.
* libcp1plugin.cc (plugin_reactivate_decl): Ditto.
(plugin_get_float_type): Ditto.
---
 gcc/c-family/c-ada-spec.cc |  6 ++---
 gcc/c-family/c-common.cc   | 32 +++
 gcc/c-family/c-common.h|  2 +-
 gcc/c-family/c-omp.cc  |  5 ++--
 gcc/c-family/c-ubsan.cc|  2 +-
 gcc/c-family/c-warn.cc |  6 ++---
 gcc/c/c-convert.cc |  4 +--
 gcc/c/c-decl.cc|  6 ++---
 gcc/c/c-parser.cc  |  4 +--
 gcc/c/c-typeck.cc  | 52 +++---
 gcc/c/gimple-parser.cc |  2 +-
 libcc1/libcc1plugin.cc |  2 +-
 libcc1/libcp1plugin.cc |  4 +--
 13 files changed, 63 insertions(+), 64 deletions(-)

diff --git a/gcc/c-family/c-ada-spec.cc b/gcc/c-family/c-ada-spec.cc
index b50b3877564..050994d8416 100644
--- a/gcc/c-family/c-ada-spec.cc
+++ b/gcc/c-family/c-ada-spec.cc
@@ -1051,7 +1051,7 @@ has_static_fields (const_tree type)
 return false;
 
   for (tree fld = TYPE_FIELDS (type); fld; fld = TREE_CHAIN (fld))
-if (TREE_CODE (fld) == VAR_DECL && DECL_NAME (fld))
+if (VAR_P (fld) && DECL_NAME (fld))
   return true;
 
   return false;
@@ -3244,7 +3244,7 @@ dump_ada_declaration (pretty_printer *buffer, tree t, 
tree type, int spc)
   if (need_indent)
INDENT (spc);
 
-  if ((TREE_CODE (t) == FIELD_DECL || TREE_CODE (t) == VAR_DECL)
+  if ((TREE_CODE (t) == FIELD_DECL || VAR_P (t))
  && DECL_NAME (t))
check_type_name_conflict (buffer, t);
 
@@ -3462,7 +3462,7 @@ dump_ada_structure (pretty_printer *buffer, tree node, 
tree type, bool nested,
   /* Print the static fields of the structure, if any.  */
   for (tree tmp = TYPE_FIELDS (node); tmp; tmp = TREE_CHAIN (tmp))
 {
-  if (TREE_CODE (tmp) == VAR_DECL && DECL_NAME (tmp))
+  if (VAR_P (tmp) && DECL_NAME (tmp))
{
  if (need_semicolon)
{
diff --git a/gcc/c-family/c-common.cc b/gcc/c-family/c-common.cc
index 2b4c82facf7..9c8eed5442a 100644
--- a/gcc/c-family/c-common.cc
+++ b/gcc/c-family/c-common.cc
@@ -1483,7 +1483,7 @@ unsafe_conversion_p (tree type, tree expr, tree result, 
bool check_sign)
 
   /* Warn for real constant that is not an exact integer converted
 to integer type.  */
-  if (TREE_CODE (expr_type) == REAL_TYPE
+  if (SCALAR_FLOAT_TYPE_P (expr_type)
  && TREE_CODE (type) == INTEGER_TYPE)
{
  if (!real_isinteger (TREE_REAL_CST_PTR (expr), TYPE_MODE (expr_type)))
@@ -1508,7 +1508,7 @@ unsafe_conversion_p (tree type, tree expr, tree result, 
bool check_sign)
  else
give_warning = UNSAFE_OTHER;
}
-  else if (TREE_CODE (type) == REAL_TYPE)
+  else if (SCALAR_FLOAT_TYPE_P (type))
{
  /* Warn for an integer constant that does not fit into real type.  */
  if (TREE_CODE (expr_type) == INTEGER_TYPE)
@@ -1519,7 +1519,7 @@ unsafe_conversion_p (tree type, tree expr, tree result, 
bool check_sign)
}
  /* Warn for a real constant that does not fit into a smaller
 real type.  */
- else if (TREE_CODE (expr_type) == REAL_TYPE
+ else if (SCALAR_FLOAT_TYPE_P (expr_type)
   && TYPE_PRECISION (type) < TYPE_PRECISION (expr_type))
{
  REAL_VALUE_TYPE a = TREE_REAL_CST (expr);
@@ -1579,7 +1579,7 @@ unsafe_conversion_p (tree type, tree expr, tree result, 
bool check_s

[PATCH 07/14] d: use _P() defines from tree.h

[Bernhard Reutner-Fischer via Gcc-patches]

From: Bernhard Reutner-Fischer 

gcc/d/ChangeLog:

* d-codegen.cc (underlying_complex_expr): Use _P defines from tree.h.
* d-convert.cc (convert): Ditto.
(convert_for_rvalue): Ditto.
---
 gcc/d/d-codegen.cc | 2 +-
 gcc/d/d-convert.cc | 9 -
 2 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/gcc/d/d-codegen.cc b/gcc/d/d-codegen.cc
index 5c6c300ecec..9bae06077b5 100644
--- a/gcc/d/d-codegen.cc
+++ b/gcc/d/d-codegen.cc
@@ -1599,7 +1599,7 @@ underlying_complex_expr (tree type, tree expr)
   /* Build a constructor from the real and imaginary parts.  */
   if (COMPLEX_FLOAT_TYPE_P (TREE_TYPE (expr)) &&
   (!INDIRECT_REF_P (expr)
-   || !CONVERT_EXPR_CODE_P (TREE_CODE (TREE_OPERAND (expr, 0)
+   || !CONVERT_EXPR_P (TREE_OPERAND (expr, 0
 {
   vec  *ve = NULL;
   CONSTRUCTOR_APPEND_ELT (ve, TYPE_FIELDS (type),
diff --git a/gcc/d/d-convert.cc b/gcc/d/d-convert.cc
index 9e7fcd506f8..cdbd69cf012 100644
--- a/gcc/d/d-convert.cc
+++ b/gcc/d/d-convert.cc
@@ -257,7 +257,7 @@ convert (tree type, tree expr)
 return fold_convert (type, expr);
   if (TREE_CODE (TREE_TYPE (expr)) == ERROR_MARK)
 return error_mark_node;
-  if (TREE_CODE (TREE_TYPE (expr)) == VOID_TYPE)
+  if (VOID_TYPE_P (TREE_TYPE (expr)))
 {
   error ("void value not ignored as it ought to be");
   return error_mark_node;
@@ -270,8 +270,7 @@ convert (tree type, tree expr)
 
 case INTEGER_TYPE:
 case ENUMERAL_TYPE:
-  if (TREE_CODE (etype) == POINTER_TYPE
- || TREE_CODE (etype) == REFERENCE_TYPE)
+  if (POINTER_TYPE_P (etype))
{
  if (integer_zerop (e))
return build_int_cst (type, 0);
@@ -300,7 +299,7 @@ convert (tree type, tree expr)
   return fold (convert_to_real (type, e));
 
 case COMPLEX_TYPE:
-  if (TREE_CODE (etype) == REAL_TYPE && TYPE_IMAGINARY_FLOAT (etype))
+  if (SCALAR_FLOAT_TYPE_P (etype) && TYPE_IMAGINARY_FLOAT (etype))
return fold_build2 (COMPLEX_EXPR, type,
build_zero_cst (TREE_TYPE (type)),
convert (TREE_TYPE (type), expr));
@@ -656,7 +655,7 @@ convert_for_rvalue (tree expr, Type *etype, Type *totype)
   && ebtype->ty == TY::Tsarray
   && tbtype->nextOf ()->ty == ebtype->nextOf ()->ty
   && INDIRECT_REF_P (expr)
-  && CONVERT_EXPR_CODE_P (TREE_CODE (TREE_OPERAND (expr, 0)))
+  && CONVERT_EXPR_P (TREE_OPERAND (expr, 0))
   && TREE_CODE (TREE_OPERAND (TREE_OPERAND (expr, 0), 0)) == ADDR_EXPR)
 {
   /* If expression is a vector that was casted to an array either by
-- 
2.30.2

[PATCH 02/14] analyzer: use _P() defines from tree.h

[Bernhard Reutner-Fischer via Gcc-patches]

From: Bernhard Reutner-Fischer 

gcc/analyzer/ChangeLog:

* region-model-manager.cc (get_code_for_cast): Use _P defines from
tree.h.
(region_model_manager::get_or_create_cast): Ditto.
(region_model_manager::get_region_for_global): Ditto.
* region-model.cc (region_model::get_lvalue_1): Ditto.
* region.cc (decl_region::maybe_get_constant_value): Ditto.
---
 gcc/analyzer/region-model-manager.cc | 8 
 gcc/analyzer/region-model.cc | 2 +-
 gcc/analyzer/region.cc   | 2 +-
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/gcc/analyzer/region-model-manager.cc 
b/gcc/analyzer/region-model-manager.cc
index fab5bba15d5..3b95e432aba 100644
--- a/gcc/analyzer/region-model-manager.cc
+++ b/gcc/analyzer/region-model-manager.cc
@@ -507,7 +507,7 @@ get_code_for_cast (tree dst_type, tree src_type)
   if (!src_type)
 return NOP_EXPR;
 
-  if (TREE_CODE (src_type) == REAL_TYPE)
+  if (SCALAR_FLOAT_TYPE_P (src_type))
 {
   if (TREE_CODE (dst_type) == INTEGER_TYPE)
return FIX_TRUNC_EXPR;
@@ -531,9 +531,9 @@ region_model_manager::get_or_create_cast (tree type, const 
svalue *arg)
 return arg;
 
   /* Don't attempt to handle casts involving vector types for now.  */
-  if (TREE_CODE (type) == VECTOR_TYPE
+  if (VECTOR_TYPE_P (type)
   || (arg->get_type ()
- && TREE_CODE (arg->get_type ()) == VECTOR_TYPE))
+ && VECTOR_TYPE_P (arg->get_type (
 return get_or_create_unknown_svalue (type);
 
   enum tree_code op = get_code_for_cast (type, arg->get_type ());
@@ -1410,7 +1410,7 @@ region_model_manager::get_region_for_label (tree label)
 const decl_region *
 region_model_manager::get_region_for_global (tree expr)
 {
-  gcc_assert (TREE_CODE (expr) == VAR_DECL);
+  gcc_assert (VAR_P (expr));
 
   decl_region **slot = m_globals_map.get (expr);
   if (slot)
diff --git a/gcc/analyzer/region-model.cc b/gcc/analyzer/region-model.cc
index fb81d43f91b..3bb3df2f063 100644
--- a/gcc/analyzer/region-model.cc
+++ b/gcc/analyzer/region-model.cc
@@ -2092,7 +2092,7 @@ region_model::get_lvalue_1 (path_var pv, 
region_model_context *ctxt) const
   {
gcc_assert (TREE_CODE (expr) == SSA_NAME
|| TREE_CODE (expr) == PARM_DECL
-   || TREE_CODE (expr) == VAR_DECL
+   || VAR_P (expr)
|| TREE_CODE (expr) == RESULT_DECL);
 
int stack_index = pv.m_stack_depth;
diff --git a/gcc/analyzer/region.cc b/gcc/analyzer/region.cc
index a18bfa50d09..8f0eb569b33 100644
--- a/gcc/analyzer/region.cc
+++ b/gcc/analyzer/region.cc
@@ -1162,7 +1162,7 @@ decl_region::get_stack_depth () const
 const svalue *
 decl_region::maybe_get_constant_value (region_model_manager *mgr) const
 {
-  if (TREE_CODE (m_decl) == VAR_DECL
+  if (VAR_P (m_decl)
   && DECL_IN_CONSTANT_POOL (m_decl)
   && DECL_INITIAL (m_decl)
   && TREE_CODE (DECL_INITIAL (m_decl)) == CONSTRUCTOR)
-- 
2.30.2

Re: [PATCH] ipa: Self-DCE of uses of removed call LHSs (PR 108007)

[Bernhard Reutner-Fischer via Gcc-patches]

On 12 May 2023 14:45:14 CEST, Martin Jambor  wrote:

>gcc/ChangeLog:
>
>2023-05-11  Martin Jambor  
>
>   PR ipa/108007
>   * cgraph.h (cgraph_edge): Add a parameter to
>   redirect_call_stmt_to_callee.
>   * ipa-param-manipulation.h (ipa_param_adjustments): Added a
>   parameter to modify_call.
>   * cgraph.cc (cgraph_edge::redirect_call_stmt_to_callee): New
>   parameter killed_ssas, pass it to padjs->modify_call.
>   * ipa-param-manipulation.cc (purge_transitive_uses): New function.
>   (ipa_param_adjustments::modify_call): New parameter killed_ssas.
>   Instead of substitutin uses, invoke purge_transitive_uses.  If
>   hash of killed SSAs has not been provided, create a temporary one
>   and release SSAs that have been added to it.
>   * tree-inline.cc (redirect_all_calls): Create
>   id->killed_new_ssa_names earlier, pass it to edge redirection,
>   adjust a comment.
>   (copy_body): Release SSAs in id->killed_new_ssa_names.

Nit: Please use present tense in the ChangeLog.
s/Added/Add/
And there is a trailing 'g' missing in substitutin
thanks,

Re: [PATCH] Machine_Mode: Extend machine_mode from 8 to 16 bits

[Bernhard Reutner-Fischer via Gcc-patches]

On 12 May 2023 08:49:53 CEST, Richard Biener via Gcc-patches 
 wrote:

>> gcc/ChangeLog:
>> 
>>  * combine.cc (struct reg_stat_type): Extended machine mode to 16 bits.
>>  * cse.cc (struct qty_table_elem): Ditto.
>>  (struct table_elt): Ditto.
>>  (struct set): Ditto.
>>  * genopinit.cc (main): Reconciled the machine mode limit.
>>  * ira-int.h (struct ira_allocno): Extended machine mode to 16 bits.
>>  * ree.cc (struct ATTRIBUTE_PACKED): Ditto.
>
>please go over the ChangeLog and properly specify the structure types
>altered.  The script generating the changelog isn't perfect.

And a nitpick, please use present tense in the ChangeLog: Extend, etc
And I wouldn't have said reconcile.

thanks,

RE: [PATCH v3] Var-Tracking: Typedef pointer_mux as decl_or_value

[Bernhard Reutner-Fischer via Gcc-patches]

On 11 May 2023 04:30:16 CEST, "Li, Pan2 via Gcc-patches" 
 wrote:

>../../gcc/var-tracking.cc:3233:28: error: no match for 'operator!=' (operand 
>types are 'rtx' {aka 'rtx_def*'} and 'decl_or_value' {aka 
>'pointer_mux'}).

Wouldn't you usually declare operator!= by !(left == right) ?
thanks,

Re: [PATCH v2 4/7] fortran: use grep instead of fgrep

[Bernhard Reutner-Fischer via Gcc-patches]

On Mon, 27 Jun 2022 14:10:36 +0800
Xi Ruoyao  wrote:

> fgrep has been deprecated in favor of grep -F for a long time, and the
> next grep release (3.8 or 4.0) will print a warning of fgrep is used.
> Stop using fgrep so we won't see the warning.
> 
> We can't hard code grep -F here or it may break build on hosts w/o GNU
> grep.  autoconf documentation contains a warning about this issue and
> suggest to use AC_PROG_FGREP and $FGREP, but these are too overkill in
> the specific case: there is no way "debian" could be interpreted as an
> non-trivial regex, so we can use a plain grep here.

LGTM but i cannot approve it. I'd say this one is trivial and obvious
so you could sneak it in under the "obvious" rule..
Thanks for the patch!

> 
> gcc/fortran/ChangeLog:
> 
>   * Make-lang.in: Use grep instead of fgrep.
> ---
>  gcc/fortran/Make-lang.in | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/gcc/fortran/Make-lang.in b/gcc/fortran/Make-lang.in
> index 1cb47cb1a52..6eb597d0ca0 100644
> --- a/gcc/fortran/Make-lang.in
> +++ b/gcc/fortran/Make-lang.in
> @@ -278,7 +278,7 @@ $(DESTDIR)$(man1dir)/$(GFORTRAN_INSTALL_NAME)$(man1ext): 
> doc/gfortran.1 \
>   -chmod a-x $@
>  
>  fortran.uninstall:
> - if $(SHELL) -c 'install-info --version | sed 1q | fgrep -s -v -i 
> debian' >/dev/null 2>&1; then \
> + if $(SHELL) -c 'install-info --version | sed 1q | grep -s -v -i debian' 
> >/dev/null 2>&1; then \
> echo " install-info --delete --info-dir=$(DESTDIR)$(infodir) 
> $(DESTDIR)$(infodir)/gfortran.info"; \
> install-info --delete --info-dir=$(DESTDIR)$(infodir) 
> $(DESTDIR)$(infodir)/gfortran.info || : ; \
>   else : ; fi; \

Re: [PATCH 1/2] Fortran: dump-parse-tree attribs: fix unbalanced braces [PR109624]

[Bernhard Reutner-Fischer via Gcc-patches]

[re-adding the lists, i hope you don't mind]

On Wed, 10 May 2023 18:52:54 +0200
Thomas Koenig  wrote:

> Hi Bernhard,
> 
> both patches look good to me.

Pushed as r14-664-g39f7c0963a9c00 and r14-665-gbdc10c2bfaceb3
Thanks!

> 
> No user impact, so they should have the lowest possible impact :-)
> 
> (And I didn't know about DEBUG_FUNCTION, that could come in handy
> later).
> 
> Thanks for the patch!
> 
> Best regards
> 
>      Thomas

[PATCH 2/2] Fortran: dump-parse-tree: Mark debug functions with DEBUG_FUNCTION

[Bernhard Reutner-Fischer via Gcc-patches]

From: Bernhard Reutner-Fischer 

gcc/fortran/ChangeLog:

* dump-parse-tree.cc (gfc_debug_expr): Remove forward declaration.
(debug): Add DEBUG_FUNCTION.
(show_code_node): Remove erroneous whitespace.

---
Regression tested on x86_64-linux, OK for trunk?
---
 gcc/fortran/dump-parse-tree.cc | 38 --
 1 file changed, 22 insertions(+), 16 deletions(-)

diff --git a/gcc/fortran/dump-parse-tree.cc b/gcc/fortran/dump-parse-tree.cc
index 2380fa04796..644f8f37d63 100644
--- a/gcc/fortran/dump-parse-tree.cc
+++ b/gcc/fortran/dump-parse-tree.cc
@@ -55,10 +55,8 @@ static void show_typespec (gfc_typespec *);
 static void show_ref (gfc_ref *);
 static void show_attr (symbol_attribute *, const char *);
 
-/* Allow dumping of an expression in the debugger.  */
-void gfc_debug_expr (gfc_expr *);
-
-void debug (symbol_attribute *attr)
+DEBUG_FUNCTION void
+debug (symbol_attribute *attr)
 {
   FILE *tmp = dumpfile;
   dumpfile = stderr;
@@ -67,7 +65,8 @@ void debug (symbol_attribute *attr)
   dumpfile = tmp;
 }
 
-void debug (gfc_formal_arglist *formal)
+DEBUG_FUNCTION void
+debug (gfc_formal_arglist *formal)
 {
   FILE *tmp = dumpfile;
   dumpfile = stderr;
@@ -80,12 +79,14 @@ void debug (gfc_formal_arglist *formal)
   dumpfile = tmp;
 }
 
-void debug (symbol_attribute attr)
+DEBUG_FUNCTION void
+debug (symbol_attribute attr)
 {
   debug ();
 }
 
-void debug (gfc_expr *e)
+DEBUG_FUNCTION void
+debug (gfc_expr *e)
 {
   FILE *tmp = dumpfile;
   dumpfile = stderr;
@@ -102,7 +103,8 @@ void debug (gfc_expr *e)
   dumpfile = tmp;
 }
 
-void debug (gfc_typespec *ts)
+DEBUG_FUNCTION void
+debug (gfc_typespec *ts)
 {
   FILE *tmp = dumpfile;
   dumpfile = stderr;
@@ -111,12 +113,14 @@ void debug (gfc_typespec *ts)
   dumpfile = tmp;
 }
 
-void debug (gfc_typespec ts)
+DEBUG_FUNCTION void
+debug (gfc_typespec ts)
 {
   debug ();
 }
 
-void debug (gfc_ref *p)
+DEBUG_FUNCTION void
+debug (gfc_ref *p)
 {
   FILE *tmp = dumpfile;
   dumpfile = stderr;
@@ -125,7 +129,7 @@ void debug (gfc_ref *p)
   dumpfile = tmp;
 }
 
-void
+DEBUG_FUNCTION void
 debug (gfc_namespace *ns)
 {
   FILE *tmp = dumpfile;
@@ -135,7 +139,7 @@ debug (gfc_namespace *ns)
   dumpfile = tmp;
 }
 
-void
+DEBUG_FUNCTION void
 gfc_debug_expr (gfc_expr *e)
 {
   FILE *tmp = dumpfile;
@@ -147,7 +151,7 @@ gfc_debug_expr (gfc_expr *e)
 
 /* Allow for dumping of a piece of code in the debugger.  */
 
-void
+DEBUG_FUNCTION void
 gfc_debug_code (gfc_code *c)
 {
   FILE *tmp = dumpfile;
@@ -157,7 +161,8 @@ gfc_debug_code (gfc_code *c)
   dumpfile = tmp;
 }
 
-void debug (gfc_symbol *sym)
+DEBUG_FUNCTION void
+debug (gfc_symbol *sym)
 {
   FILE *tmp = dumpfile;
   dumpfile = stderr;
@@ -2513,7 +2518,7 @@ show_code_node (int level, gfc_code *c)
 case EXEC_SYNC_MEMORY:
   fputs ("SYNC MEMORY ", dumpfile);
   if (c->expr2 != NULL)
-   {
+   {
  fputs (" stat=", dumpfile);
  show_expr (c->expr2);
}
@@ -4031,7 +4036,8 @@ gfc_dump_global_symbols (FILE *f)
 
 /* Show an array ref.  */
 
-void debug (gfc_array_ref *ar)
+DEBUG_FUNCTION void
+debug (gfc_array_ref *ar)
 {
   FILE *tmp = dumpfile;
   dumpfile = stderr;
-- 
2.30.2

[PATCH 1/2] Fortran: dump-parse-tree attribs: fix unbalanced braces [PR109624]

[Bernhard Reutner-Fischer via Gcc-patches]

From: Bernhard Reutner-Fischer 

gcc/fortran/ChangeLog:

PR fortran/109624
* dump-parse-tree.cc (debug): New function for gfc_namespace.
(gfc_debug_code): Delete forward declaration.
(show_attr): Make sure to print balanced braces.

---
(gdb) call debug(gfc_current_ns)

Namespace: A-H: (REAL 4) I-N: (INTEGER 4) O-Z: (REAL 4)
procedure name = fmodule
  symtree: 'C_ptr'   || symbol: 'c_ptr'
type spec : (UNKNOWN 0)
attributes: )

There is an open brace missing after "attributes: "

Regression tested on x86_64-linux, OK for trunk?
---
 gcc/fortran/dump-parse-tree.cc | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/gcc/fortran/dump-parse-tree.cc b/gcc/fortran/dump-parse-tree.cc
index 1fc1f311e84..2380fa04796 100644
--- a/gcc/fortran/dump-parse-tree.cc
+++ b/gcc/fortran/dump-parse-tree.cc
@@ -125,6 +125,16 @@ void debug (gfc_ref *p)
   dumpfile = tmp;
 }
 
+void
+debug (gfc_namespace *ns)
+{
+  FILE *tmp = dumpfile;
+  dumpfile = stderr;
+  show_namespace (ns);
+  fputc ('\n', dumpfile);
+  dumpfile = tmp;
+}
+
 void
 gfc_debug_expr (gfc_expr *e)
 {
@@ -136,7 +146,6 @@ gfc_debug_expr (gfc_expr *e)
 }
 
 /* Allow for dumping of a piece of code in the debugger.  */
-void gfc_debug_code (gfc_code *c);
 
 void
 gfc_debug_code (gfc_code *c)
@@ -758,12 +767,13 @@ show_expr (gfc_expr *p)
 static void
 show_attr (symbol_attribute *attr, const char * module)
 {
+  fputc ('(', dumpfile);
   if (attr->flavor != FL_UNKNOWN)
 {
   if (attr->flavor == FL_DERIVED && attr->pdt_template)
-   fputs (" (PDT-TEMPLATE", dumpfile);
+   fputs ("PDT-TEMPLATE ", dumpfile);
   else
-fprintf (dumpfile, "(%s ", gfc_code2string (flavors, attr->flavor));
+   fprintf (dumpfile, "%s ", gfc_code2string (flavors, attr->flavor));
 }
   if (attr->access != ACCESS_UNKNOWN)
 fprintf (dumpfile, "%s ", gfc_code2string (access_types, attr->access));
-- 
2.30.2

[PATCH v2] Fortran: Narrow return types [PR78798]

[Bernhard Reutner-Fischer via Gcc-patches]

From: Bernhard Reutner-Fischer 

gcc/fortran/ChangeLog:

PR fortran/78798
* array.cc (compare_bounds): Use narrower return type.
(gfc_compare_array_spec): Likewise.
(is_constant_element): Likewise.
(gfc_constant_ac): Likewise.
* check.cc (dim_rank_check): Likewise.
* cpp.cc (gfc_cpp_init_options): Likewise.
(dump_macro): Likewise.
* cpp.h (gfc_cpp_handle_option): Likewise.
* dependency.cc (gfc_ref_needs_temporary_p): Likewise.
(gfc_check_argument_dependency): Likewise.
(gfc_check_fncall_dependency): Likewise.
(ref_same_as_full_array): Likewise.
* dependency.h (gfc_check_fncall_dependency): Likewise.
(gfc_dep_resolver): Likewise.
(gfc_are_equivalenced_arrays): Likewise.
* expr.cc (gfc_copy_ref): Likewise.
(gfc_kind_max): Likewise.
(numeric_type): Likewise.
* gfortran.h (gfc_at_end): Likewise.
(gfc_at_eof): Likewise.
(gfc_at_bol): Likewise.
(gfc_at_eol): Likewise.
(gfc_define_undef_line): Likewise.
(gfc_wide_is_printable): Likewise.
(gfc_wide_is_digit): Likewise.
(gfc_wide_fits_in_byte): Likewise.
(gfc_find_sym_tree): Likewise.
(gfc_generic_intrinsic): Likewise.
(gfc_specific_intrinsic): Likewise.
(gfc_intrinsic_actual_ok): Likewise.
(gfc_has_vector_index): Likewise.
(gfc_numeric_ts): Likewise.
(gfc_impure_variable): Likewise.
(gfc_pure): Likewise.
(gfc_implicit_pure): Likewise.
(gfc_elemental): Likewise.
(gfc_pure_function): Likewise.
(gfc_implicit_pure_function): Likewise.
(gfc_compare_array_spec): Likewise.
(gfc_constant_ac): Likewise.
(gfc_expanded_ac): Likewise.
(gfc_check_digit): Likewise.
* intrinsic.cc (gfc_find_subroutine): Likewise.
(gfc_generic_intrinsic): Likewise.
(gfc_specific_intrinsic): Likewise.
* io.cc (compare_to_allowed_values): Likewise. And remove
unneeded forward declaration.
* misc.cc (gfc_done_2): Likewise.
* parse.cc: Likewise.
* parse.h (gfc_check_do_variable): Likewise.
* primary.cc (gfc_check_digit): Likewise.
* resolve.cc (resolve_structure_cons): Likewise.
(pure_stmt_function): Likewise.
(gfc_pure_function): Likewise.
(impure_stmt_fcn): Likewise.
(resolve_forall_iterators): Likewise.
(resolve_data): Likewise.
(gfc_impure_variable): Likewise.
(gfc_pure): Likewise.
(gfc_unset_implicit_pure): Likewise.
* scanner.cc (wide_is_ascii): Likewise.
(gfc_wide_toupper): Likewise.
(gfc_open_included_file): Likewise.
(gfc_at_end): Likewise.
(gfc_at_eof): Likewise.
(gfc_at_bol): Likewise.
(skip_comment_line): Likewise.
(gfc_gobble_whitespace): Likewise.
* symbol.cc (gfc_find_symtree_in_proc): Likewise.
* trans-array.cc: Likewise.
* trans-decl.cc (gfc_set_decl_assembler_name): Likewise.
* trans-types.cc (gfc_get_element_type): Likewise.
(gfc_add_field_to_struct): Likewise.
* trans-types.h (gfc_copy_dt_decls_ifequal): Likewise.
(gfc_return_by_reference): Likewise.
(gfc_is_nodesc_array): Likewise.
* trans.h (gfc_can_put_var_on_stack): Likewise.
---
Bootstrapped without new warnings and regression tested on
x86_64-linux with no regressions, OK for trunk?

 gcc/fortran/array.cc   |  8 +++
 gcc/fortran/check.cc   |  2 +-
 gcc/fortran/cpp.cc |  3 +--
 gcc/fortran/cpp.h  |  2 +-
 gcc/fortran/dependency.cc  |  8 +++
 gcc/fortran/dependency.h   |  6 ++---
 gcc/fortran/expr.cc|  6 ++---
 gcc/fortran/gfortran.h | 48 +++---
 gcc/fortran/intrinsic.cc   |  6 ++---
 gcc/fortran/io.cc  | 13 ++-
 gcc/fortran/parse.cc   |  2 +-
 gcc/fortran/parse.h|  2 +-
 gcc/fortran/primary.cc |  4 ++--
 gcc/fortran/resolve.cc | 22 -
 gcc/fortran/scanner.cc | 20 
 gcc/fortran/symbol.cc  |  2 +-
 gcc/fortran/trans-array.cc |  2 +-
 gcc/fortran/trans-decl.cc  |  2 +-
 gcc/fortran/trans-types.cc |  6 ++---
 gcc/fortran/trans-types.h  |  6 ++---
 gcc/fortran/trans.h|  2 +-
 21 files changed, 81 insertions(+), 91 deletions(-)

diff --git a/gcc/fortran/array.cc b/gcc/fortran/array.cc
index be5eb8b6a0f..4b7c1e715bf 100644
--- a/gcc/fortran/array.cc
+++ b/gcc/fortran/array.cc
@@ -994,7 +994,7 @@ compare_bounds (gfc_expr *bound1, gfc_expr *bound2)
 /* Compares two array specifications.  They must be constant or deferred
shape.  */
 
-int
+bool
 gfc_compare_array_spec (gfc_array_spec *as1, gfc_array_spec *as2)
 {
   int i;
@@ -1039,7 +1039,7 @@ gfc_compare_array_spec (gfc_array_spec *as1, 
gfc_array_spec *as2)
use the symbol as an implied-DO iterator

Re: [PATCH take #3] match.pd: Simplify popcount/parity of bswap/rotate.

[Bernhard Reutner-Fischer via Gcc-patches]

Hi Roger!
On 10 May 2023 16:46:10 CEST, Roger Sayle  wrote:

Just a nit:

+/* { dg-final { scan-tree-dump-times "bswap" 0 "optimized" } } */

Can you please use scan-tree-dump-not instead?
thanks,

Re: Support parallel testing in libgomp, part II [PR66005]

[Bernhard Reutner-Fischer via Gcc-patches]

Thomas,

On Fri, 5 May 2023 10:59:31 +0200
Thomas Schwinge  wrote:

> Worth noting is that with nvptx offloading, there is one execution test case
> that times out ('libgomp.fortran/reverse-offload-5.f90').  This effectively
> stalls progress for almost 5 min:

Short of fixing it for real you could shorten the timeout for this
single test to a handful of seconds: dg-timeout 3
or set it to a 1/50 fraction or the like: dg-timeout-factor 0.02

If it's unbroken then it should run to completion in far less than 10
or 30 seconds, from the looks?

just a thought..

Re: Support parallel testing in libgomp, part I [PR66005]

[Bernhard Reutner-Fischer via Gcc-patches]

On Mon, 8 May 2023 12:42:33 +0200
Thomas Schwinge  wrote:

> >> +if [info exists ::env(GCC_RUNTEST_PARALLELIZE_DIR)] {
> >> +load_file ../libgomp-test-support.exp
> >> +} else {
> >> +load_file libgomp-test-support.exp
> >> +}  
> >
> > Do we have to re-read those? Otherwise this would be load_lib:  
> 
> Indeed there is some confusion there; conceptually the content of that
> file has to be expected to vary per libgomp (multilib) build variant.
> On the other hand, given the GCC target libraries testing setup, we're
> running testing always via the default variant's build, so always read
> the default variant's file.  I agree that should get un-confused, however
> it's a pre-existing issue that I suggest we tackle independently of this
> mechanical change.

Sure. One thing at a time.

> > Some cosmetic nits.
> > See Jakubs one_to_.  
> 
> Thanks.  That got installed while I'd already finished my patch.  ;-)
> Note that the new 'one_to_' etc. is just the existing
> 'check_p_numbers' etc. renamed and moved, as it now has a second use.
> I'm happy to incorporate that into my changes -- if we agree that it
> should also go into other GCC target libraries' parallel testing code:
> libphobos, libstdc++-v3.

Yes. Streamlining these can be done in follow-ups if the respective
maintainers agree.

> >> >> It is far from trivial though.
> >> >> The point is that most of the OpenMP tests are parallelized with the
> >> >> default OMP_NUM_THREADS, so running the tests in parallel 
> >> >> oversubscribes the
> >> >> machine a lot, the higher number of hw threads the more.  
[]
> >> > the same time?  For example, a new dg-* directive to run them wrapped
> >> > through »flock [libgomp/testsuite/serial.lock] [a.out]« or some such?  
> >
> > I think we all agree one that, yes.  
> 
> Conceptually, yes.  However, given that my
> "Support parallel testing in libgomp, part II [PR66005]" changes already
> seem to enable a great amount of parallelism, occupying CPUs almost
> fully,  I'm not actually sure now if adding more parallelism via
> tedious-to-maintain new dg-* directives is actually necessary/useful.  As
> long as libgomp testing now no longer is at the long tail end of overall
> testing time, I'd rather keep it simple?

If the testsuite runtime is fine with your part II as is then we
should keep it as simple as possible.

> >> > (Will again have the problem that DejaGnu doesn't provide infrastructure
> >> > to communicate environment variables to boards in remote testing.)  
> >
> > Are you sure? I'm pretty confident that this worked fine at least at
> > one point in the past for certain targets.  
> 
> For example, see the comments/references in recent
> .

oh, i think i had an rsh2 remote that uploaded $program.env and the rsh
itself was something like
 $RSH $rsh_useropts $hostname sh -c 'test -r $program.env && .
 $program.env \\; $program $pargs \\; echo ...

but that was ages ago and was properly implemented in the meantime, one
would hope? Well, apparently not.

PS: Back then I usually needed very different per-program env and not a
single, static env. So for me it made no sense to have a set of default
env and have tests add their own variables on-demand on top of the
default. The situation in gcc might be the exact opposite?

thanks,

Re: [PATCH v4] libgfortran: Replace mutex with rwlock

[Bernhard Reutner-Fischer via Gcc-patches]

On Mon,  8 May 2023 17:44:43 +0800
Lipeng Zhu  wrote:

> This patch try to introduce the rwlock and split the read/write to
> unit_root tree and unit_cache with rwlock instead of the mutex to
> increase CPU efficiency. In the get_gfc_unit function, the percentage
> to step into the insert_unit function is around 30%, in most instances,
> we can get the unit in the phase of reading the unit_cache or unit_root
> tree. So split the read/write phase by rwlock would be an approach to
> make it more parallel.
> 
> BTW, the IPC metrics can gain around 9x in our test
> server with 220 cores. The benchmark we used is
> https://github.com/rwesson/NEAT

See commentary typos below.
You did not state if you regression tested the patch?
Other than that it LGTM but i cannot approve it.

> diff --git a/libgfortran/io/async.h b/libgfortran/io/async.h
> index ad226c8e856..0033cc74252 100644
> --- a/libgfortran/io/async.h
> +++ b/libgfortran/io/async.h
> @@ -210,6 +210,128 @@
>  DEBUG_PRINTF ("%s" DEBUG_RED "ACQ:" DEBUG_NORM " %-30s %78p\n", 
> aio_prefix, #mutex, mutex); \
>} while (0)
>  
> +#ifdef __GTHREAD_RWLOCK_INIT
> +#define RWLOCK_DEBUG_ADD(rwlock) do {\
> +aio_rwlock_debug *n; \
> +n = xmalloc (sizeof(aio_rwlock_debug));  \

Missing space before the open brace: sizeof (

> diff --git a/libgfortran/io/unit.c b/libgfortran/io/unit.c
> index 82664dc5f98..62f1db21d34 100644
> --- a/libgfortran/io/unit.c
> +++ b/libgfortran/io/unit.c
> @@ -33,34 +33,36 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  
> If not, see
>  
>  
>  /* IO locking rules:
> -   UNIT_LOCK is a master lock, protecting UNIT_ROOT tree and UNIT_CACHE.
> +   UNIT_RWLOCK is a master lock, protecting UNIT_ROOT tree and UNIT_CACHE.
> +   And use the rwlock to spilt read and write phase to UNIT_ROOT tree
> +   and UNIT_CACHE to increase CPU efficiency.

s/spilt/split. Maybe:

Using an rwlock improves efficiency by allowing us to separate readers
and writers of both UNIT_ROOT and UNIT_CACHE.

> @@ -350,6 +356,17 @@ retry:
>if (c == 0)
>   break;
>  }
> +  /* We did not find a unit in the cache nor in the unit list, create a new
> +(locked) unit and insert into the unit list and cache.
> +Manipulating either or both the unit list and the unit cache requires to
> +hold a write-lock [for obvious reasons]:
> +1. By separating the read/write lock, it will greatly reduce the 
> contention
> +   at the read part, while write part is not always necessary or most
> +   unlikely once the unit hit in cache.

+By separating the read/write lock, we will greatly reduce the contention
+on the read part, while the write part is unlikely once the unit hits
+the cache.

> +2. We try to balance the implementation complexity and the performance
> +   gains that fit into current cases we observed by just using a
> +   pthread_rwlock. */

Let's drop 2.
thanks,

Re: [PATCH v3] libgfortran: Replace mutex with rwlock

[Bernhard Reutner-Fischer via Gcc-patches]

On Mon, 8 May 2023 17:31:27 +0800
"Zhu, Lipeng"  wrote:

> > BTW, did you look at the RELEASE semantics, respectively the note that one 
> > day (and now is that very
> > day), we might improve on the release semantics? Can of course be 
> > incremental AFAIC
> >   
> Not quite understand your question about looking at the RELEASE 
> semantics. Can you be more specific?

libgfortran/io/io.h: could be further optimized by making this be an 
__ATOMIC_RELEASE,

But let's defer that to a follow-up improvement independently of the
rwlock.
thanks,

Re: [PATCH][stage1] Remove conditionals around free()

[Bernhard Reutner-Fischer via Gcc-patches]

On Wed, 1 Mar 2023 16:07:14 -0800
Steve Kargl  wrote:

> On Wed, Mar 01, 2023 at 10:28:56PM +0100, Bernhard Reutner-Fischer via 
> Fortran wrote:
> >  libgfortran/caf/single.c |6 ++
> >  libgfortran/io/async.c   |6 ++
> >  libgfortran/io/format.c  |3 +--
> >  libgfortran/io/transfer.c|6 ++
> >  libgfortran/io/unix.c|3 +--  
> 
> The Fortran ones are OK.
> 

I've pushed the fortran and libgfortran bits as r14-568-gca2f64d5d08c16
thanks,

Re: ping Re: [PATCH 3/3] Fortran: Fix mpz and mpfr memory leaks

[Bernhard Reutner-Fischer via Gcc-patches]

On Mon, 17 Apr 2023 15:18:27 -0700
Steve Kargl  wrote:
> On Mon, Apr 17, 2023 at 09:47:50PM +0200, Bernhard Reutner-Fischer via 
> Fortran wrote:
> > On Mon, 03 Apr 2023 23:42:06 +0200
> > Bernhard Reutner-Fischer  wrote:
> >   
> > > On 3 April 2023 21:50:49 CEST, Harald Anlauf  wrote:  
> > > >Hi Bernhard,
> > > >
> > > >there is neither context nor a related PR with a testcase showing
> > > >that this patch fixes issues seen there.
> > > 
> > > Yes, i forgot to mention the PR:
> > > 
> > > PR fortran/68800
> > > 
> > > I did not construct individual test cases but it should be obvious that 
> > > we should not leak these.
> > >   
> > > >
> > > >On 4/2/23 17:05, Bernhard Reutner-Fischer via Gcc-patches wrote:
> > > >> From: Bernhard Reutner-Fischer 
> > > >> 
> > > >> Cc: fort...@gcc.gnu.org
> > > >> 
> > > >> gcc/fortran/ChangeLog:
> > > >> 
> > > >>* array.cc (gfc_ref_dimen_size): Free mpz memory before ICEing.
> > > >>* expr.cc (find_array_section): Fix mpz memory leak.
> > > >>* simplify.cc (gfc_simplify_reshape): Fix mpz memory leaks in
> > > >>error paths.
> > > >>(gfc_simplify_set_exponent): Fix mpfr memory leak.
> > > >> ---
> > > >>   gcc/fortran/array.cc| 3 +++
> > > >>   gcc/fortran/expr.cc | 8 
> > > >>   gcc/fortran/simplify.cc | 7 ++-
> > > >>   3 files changed, 13 insertions(+), 5 deletions(-)
> > > >> 
> > > >> diff --git a/gcc/fortran/array.cc b/gcc/fortran/array.cc
> > > >> index be5eb8b6a0f..8b1e816a859 100644
> > > >> --- a/gcc/fortran/array.cc
> > > >> +++ b/gcc/fortran/array.cc
> > > >> @@ -2541,6 +2541,9 @@ gfc_ref_dimen_size (gfc_array_ref *ar, int 
> > > >> dimen, mpz_t *result, mpz_t *end)
> > > >> return t;
> > > >> 
> > > >>   default:
> > > >> +  mpz_clear (lower);
> > > >> +  mpz_clear (stride);
> > > >> +  mpz_clear (upper);
> > > >> gfc_internal_error ("gfc_ref_dimen_size(): Bad dimen_type");
> > > >>   }
> > > >
> > > >  What is the point of clearing variables before issuing
> > > >  a gfc_internal_error?
> > > 
> > > To make it obvious that we are aware that we allocated these.  
> 
> I must admit I agree with Harald on this portion
> of the diff.  What's the point?  There is alot more
> allocated than just those 3 mzp_t variables when the
> internal error occurs.  For example, gfortran does not
> walk the namespaces and free those before the ICE.
> I suppose silencing valgrind might be sufficient 
> reason for the clutter.  So, ok.

I've dropped this hunk and pushed the rest as r14-567-g2521390dd2f8e5
Harald fixed the leak of expr in gfc_simplify_set_exponent in the
meantime.
thanks,

Re: Support parallel testing in libgomp, part I [PR66005]

[Bernhard Reutner-Fischer via Gcc-patches]

On Fri, 5 May 2023 10:55:41 +0200
Thomas Schwinge  wrote:

> So I recently had re-created this patch independently, before remembering
> that Rainer had -- just eight years ago... ;-) -- already submitted this.

thanks to you both :)

> etc. (where "normal" is a libstdc++ detail), and regarding:
> 
> >> > with a minimal change
> >> > to libgomp.exp so the generated libgomp-test-support.exp file is found
> >> > in both the sequential and parallel cases.  This isn't an issue in
> >> > libstdc++ since all necessary variables are stored in a single
> >> > site.exp.  
> 
> ... in 'libgomp/testsuite/lib/libgomp.exp', I've changed:
> 
> -load_file libgomp-test-support.exp
> +# Search in both .. and . to support parallel and sequential testing.
> +load_file -1 ../libgomp-test-support.exp libgomp-test-support.exp
> 
> ... into the more explicit:
> 
> -load_file libgomp-test-support.exp
> +# Search in '..' vs. '.' to support parallel vs. sequential testing.
> +if [info exists ::env(GCC_RUNTEST_PARALLELIZE_DIR)] {
> +load_file ../libgomp-test-support.exp
> +} else {
> +load_file libgomp-test-support.exp
> +}

Do we have to re-read those? Otherwise this would be load_lib:

We have libdirs in the minimum deja we require.

Speaking of which. IIRC i additionally deleted all load_gcc_lib:
https://gcc.gnu.org/legacy-ml/fortran/2012-03/msg00094.html
in lib{atomic,ffi,go,gomp,itm,phobos,stdc++-v3,vtv}

> And, for now, I hard-code the number of parallel slots to one.  This
> means that libgomp for 'make -j' now does use the parallel testing code
> paths, but is restricted to just one slot.  That is, no actual change in
> behavior, other than that 'libgomp.sum' then is filtered through
> 'contrib/dg-extract-results.sh'.
> 
> OK to push the attached
> "Support parallel testing in libgomp, part I [PR66005]"?

Some cosmetic nits.
See Jakubs one_to_.

+   @test ! -f $*/site.exp || mv $*/site.exp $*/site.bak
that's twisted

+ rm -rf libgomp-parallel || true; \

just || :; \
I count 4 times.

There seems to be a mixture of ${PWD_COMMAND} and am__cd && pwd:
+   @objdir=`${PWD_COMMAND}`/$*; \
+   srcdir=`$(am__cd) $(srcdir) && pwd`; export srcdir; \

+   runtest=$(_RUNTEST); \
+   if [ -z "$$runtest" ]; then runtest=runtest; fi; \
I think I have plain $${RUNTEST-runtest}
off the default wildcard $(top_srcdir)/../dejagnu/runtest

> >> It is far from trivial though.
> >> The point is that most of the OpenMP tests are parallelized with the
> >> default OMP_NUM_THREADS, so running the tests in parallel oversubscribes 
> >> the
> >> machine a lot, the higher number of hw threads the more.  
> >
> > Do you agree that we have two classes of test cases in libgomp: 1) test
> > cases that don't place a considerably higher load on the machine compared
> > to "normal" (single-threaded) execution tests, because they're just
> > testing some functionality that is not expected to actively depend
> > on/interfere with parallelism.  If needed, and/or if not already done,
> > such test cases can be parameterized (OMP_NUM_THREADS, OpenACC num_gangs,
> > num_workers, vector_length clauses, and so on) for low parallelism
> > levels.  And, 2) test cases that place a considerably higher load on the
> > machine compared to "normal" (single-threaded) execution tests, because
> > they're testing some functionality that actively depends on/interferes
> > with some kind of parallelism.  What about marking such tests specially,
> > such that DejaGnu will only ever schedule one of them for execution at
> > the same time?  For example, a new dg-* directive to run them wrapped
> > through »flock [libgomp/testsuite/serial.lock] [a.out]« or some such?

I think we all agree one that, yes.

> >  
> >> If we go forward with some parallelization of the tests, we at least should
> >> try to export something like OMP_WAIT_POLICY=passive so that the
> >> oversubscribed machine would at least not spend too much time in spinning. 
> >>  
> >
> > (Will again have the problem that DejaGnu doesn't provide infrastructure
> > to communicate environment variables to boards in remote testing.)

Are you sure? I'm pretty confident that this worked fine at least at
one point in the past for certain targets.

The rest of these 2 patches LGTM. Let's see what others have to say.
thanks,

Re: [committed] Fortran: Fix (mostly) comment typos

[Bernhard Reutner-Fischer via Gcc-patches]

On 28 April 2023 09:26:06 CEST, Tobias Burnus  wrote:
>Committed as r14-319-g7ebd4a1d61993c0a75e9ff3098aded21ef04a4da

 >  Only other changes are fixing the variable name a(b)breviated_modproc_decl

I think this is not good, I've mentioned it somewhere, i think, but I'll rename 
it.
thanks!

Re: libsanitizer: sync from master

[Bernhard Reutner-Fischer via Gcc-patches]

On 28 April 2023 11:23:55 CEST, Florian Weimer via Fortran 
 wrote:
>* Martin Liška:

>But that's okay for me as well.

Even better.

Re: [PATCH v2] RISC-V: Fix sync.md and riscv.cc whitespace errors

[Bernhard Reutner-Fischer via Gcc-patches]

On 26 April 2023 23:59:37 CEST, Patrick O'Neill  wrote:

>>> gcc/ChangeLog:
>>> 
>>> * config/riscv/riscv.cc: Fix whitespace.
>>> * config/riscv/sync.md: Fix whitespace.
>> The .md change above is gone by now.
>
>There are still some sync.md changes (comment whitespace/function whitespace 
>changes).

Right, i managed to somehow miss those. Sorry for the noise.
cheers,

Re: [PATCH v2] RISC-V: Fix sync.md and riscv.cc whitespace errors

[Bernhard Reutner-Fischer via Gcc-patches]

On 26 April 2023 23:21:06 CEST, Patrick O'Neill  wrote:
>This patch fixes whitespace errors introduced with
>https://gcc.gnu.org/pipermail/gcc-patches/2023-April/616807.html
>
>2023-04-26 Patrick O'Neill 
>
>gcc/ChangeLog:
>
>   * config/riscv/riscv.cc: Fix whitespace.
>   * config/riscv/sync.md: Fix whitespace.

The .md change above is gone by now.
No reason to resend the patch, just fixing it before you push it is fine, once 
ACKed (although such patches usually counts as obvious).

Many thanks for the quick tweak!
cheers,

>
>Signed-off-by: Patrick O'Neill 
>---
>Patch was checked with contrib/check_GNU_style.py
>
>Whitespace changes in this patch are 2 flavors:
> * Add space between function name and ()
> * 2 spaces between end of comment and  */
>---
>v2 Changelog:
> * Ignored checker warning for space before [] in rtl
>---
> gcc/config/riscv/riscv.cc |  6 +++---
> gcc/config/riscv/sync.md  | 16 
> 2 files changed, 11 insertions(+), 11 deletions(-)
>
>diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
>index 0f890469d7a..1529855a2b4 100644
>--- a/gcc/config/riscv/riscv.cc
>+++ b/gcc/config/riscv/riscv.cc
>@@ -7193,7 +7193,7 @@ riscv_subword_address (rtx mem, rtx *aligned_mem, rtx 
>*shift, rtx *mask,
>   emit_move_insn (*mask, gen_rtx_ASHIFT (SImode, *mask,
>gen_lowpart (QImode, *shift)));
>
>-  emit_move_insn (*not_mask, gen_rtx_NOT(SImode, *mask));
>+  emit_move_insn (*not_mask, gen_rtx_NOT (SImode, *mask));
> }
>
> /* Leftshift a subword within an SImode register.  */
>@@ -7206,8 +7206,8 @@ riscv_lshift_subword (machine_mode mode, rtx value, rtx 
>shift,
>   emit_move_insn (value_reg, simplify_gen_subreg (SImode, value,
> mode, 0));
>
>-  emit_move_insn(*shifted_value, gen_rtx_ASHIFT (SImode, value_reg,
>-   gen_lowpart (QImode, shift)));
>+  emit_move_insn (*shifted_value, gen_rtx_ASHIFT (SImode, value_reg,
>+gen_lowpart (QImode, shift)));
> }
>
> /* Initialize the GCC target structure.  */
>diff --git a/gcc/config/riscv/sync.md b/gcc/config/riscv/sync.md
>index 83be6431cb6..19274528262 100644
>--- a/gcc/config/riscv/sync.md
>+++ b/gcc/config/riscv/sync.md
>@@ -128,10 +128,10 @@
> {
>   /* We have no QImode/HImode atomics, so form a mask, then use
>  subword_atomic_fetch_strong_nand to implement a LR/SC version of the
>- operation. */
>+ operation.  */
>
>   /* Logic duplicated in gcc/libgcc/config/riscv/atomic.c for use when 
> inlining
>- is disabled */
>+ is disabled.  */
>
>   rtx old = gen_reg_rtx (SImode);
>   rtx mem = operands[1];
>@@ -193,10 +193,10 @@
> {
>   /* We have no QImode/HImode atomics, so form a mask, then use
>  subword_atomic_fetch_strong_ to implement a LR/SC version of the
>- operation. */
>+ operation.  */
>
>   /* Logic duplicated in gcc/libgcc/config/riscv/atomic.c for use when 
> inlining
>- is disabled */
>+ is disabled.  */
>
>   rtx old = gen_reg_rtx (SImode);
>   rtx mem = operands[1];
>@@ -367,7 +367,7 @@
> {
>   rtx difference = gen_rtx_MINUS (SImode, val, exp);
>   compare = gen_reg_rtx (SImode);
>-  emit_move_insn  (compare, difference);
>+  emit_move_insn (compare, difference);
> }
>
>   if (word_mode != SImode)
>@@ -393,10 +393,10 @@
> {
>   /* We have no QImode/HImode atomics, so form a mask, then use
>  subword_atomic_cas_strong to implement a LR/SC version of the
>- operation. */
>+ operation.  */
>
>   /* Logic duplicated in gcc/libgcc/config/riscv/atomic.c for use when 
> inlining
>- is disabled */
>+ is disabled.  */
>
>   rtx old = gen_reg_rtx (SImode);
>   rtx mem = operands[1];
>@@ -461,7 +461,7 @@
>   "TARGET_ATOMIC"
> {
>   /* We have no QImode atomics, so use the address LSBs to form a mask,
>- then use an aligned SImode atomic. */
>+ then use an aligned SImode atomic.  */
>   rtx result = operands[0];
>   rtx mem = operands[1];
>   rtx model = operands[2];
>--
>2.34.1
>

Re: [PATCH] RISC-V: Fix sync.md and riscv.cc whitespace errors

[Bernhard Reutner-Fischer via Gcc-patches]

On 26 April 2023 23:10:01 CEST, Andreas Schwab  wrote:
>On Apr 26 2023, Patrick O'Neill wrote:
>
>> @@ -290,10 +290,10 @@
>>[(set (match_operand:GPR 0 "register_operand" "=")
>>  (match_operand:GPR 1 "memory_operand" "+A"))
>> (set (match_dup 1)
>> -(unspec_volatile:GPR [(match_operand:GPR 2 "reg_or_0_operand" "rJ")
>> -  (match_operand:GPR 3 "reg_or_0_operand" "rJ")
>> -  (match_operand:SI 4 "const_int_operand")  ;; mod_s
>> -  (match_operand:SI 5 "const_int_operand")] ;; mod_f
>> +(unspec_volatile:GPR[(match_operand:GPR 2 "reg_or_0_operand" "rJ")
>> + (match_operand:GPR 3 "reg_or_0_operand" "rJ")
>> + (match_operand:SI 4 "const_int_operand")  ;; mod_s
>> + (match_operand:SI 5 "const_int_operand")] ;; mod_f
>
>That appears to be a bug in the checker.  This isn't a C array
>expression, but an argument in lispy vector notation, so it should be
>separated by a space.

Yeah, the checker fails on machine descriptions currently, i should have 
mentioned that, sorry!

Re: libsanitizer: sync from master

[Bernhard Reutner-Fischer via Gcc-patches]

On 26 April 2023 20:31:10 CEST, Florian Weimer via Fortran 
 wrote:
>* Martin Liška:
>
>> On 11/15/22 16:47, Martin Liška wrote:
>>> Hi.
>>> 
>>> I've just pushed libsanitizer update that was tested on x86_64-linux and 
>>> ppc64le-linux systems.
>>> Moreover, I run bootstrap on x86_64-linux and checked ABI difference with 
>>> abidiff.
>>
>> Hello.
>>
>> And I've done the same now and merged upstream version 3185e47b5a8444e9fd.
>
>So … we have the issue that involves interceptors outside of libc.so.6,
>namely crypt, crypt_r, and I posted an upstream patch for this:
>
>  sanitizers: Disable crypt, crypt_r interceptors for glibc
>  
>
>Can we just apply this downstream for now?  It blocks various folks from
>using the sanitizers in their projects.

+1

Re: [PATCH] VECT: Add decrement IV iteration loop control by variable amount support

[Bernhard Reutner-Fischer via Gcc-patches]

On 25 April 2023 18:58:10 CEST, Richard Sandiford via Gcc-patches 
 wrote:
>juzhe.zh...@rivai.ai writes:
>> diff --git a/gcc/internal-fn.cc b/gcc/internal-fn.cc
>> index 6e81dc05e0e..5f44def90d3 100644

>> diff --git a/gcc/tree-ssa-loop-manip.cc b/gcc/tree-ssa-loop-manip.cc
>> index a52277abdbf..54845a62298 100644
>> --- a/gcc/tree-ssa-loop-manip.cc
>> +++ b/gcc/tree-ssa-loop-manip.cc
>> @@ -59,14 +59,14 @@ static bitmap_obstack loop_renamer_obstack;
>>  void
>>  create_iv (tree base, tree step, tree var, class loop *loop,
>> gimple_stmt_iterator *incr_pos, bool after,
>> -   tree *var_before, tree *var_after)
>> +   tree *var_before, tree *var_after, enum tree_code code)
>
>The comment needs to be updated to describe the new interface.

Just cosmetics, but please omit the redundant "enum".

>
>This is personal preference, but: I think the interface would be
>clearer if the code argument came between the base and step,
>so that the order matches a SCEV.  The code could no longer be
>a default argument, and so all callers would need to be updated,
>but IMO that's OK.  Not sure what others think though.
>
>>  {
>>gassign *stmt;
>>gphi *phi;
>>tree initial, step1;
>>gimple_seq stmts;
>>tree vb, va;
>> -  enum tree_code incr_op = PLUS_EXPR;
>> +  enum tree_code incr_op = code;

Likewise here. If you touch such lines, please omit the redundant "enum".

I don't have an opinion on the patch itself.
thanks,

Re: Unloop no longer looping loops in loop-ch

[Bernhard Reutner-Fischer via Gcc-patches]

On 25 April 2023 17:12:50 CEST, Jan Hubicka via Gcc-patches 
 wrote:

+  fprintf (stderr, "Bingo\n");

You forgot to remove that..
Do we prune Bingo in the testsuite? ;-)

Re: [PATCH v3] libgfortran: Replace mutex with rwlock

[Bernhard Reutner-Fischer via Gcc-patches]

Hi!

[please do not top-post]

On Thu, 20 Apr 2023 21:13:08 +0800
"Zhu, Lipeng"  wrote:

> Hi Bernhard,
> 
> Thanks for your questions and suggestions.
> The rwlock could allow multiple threads to have concurrent read-only 
> access to the cache/unit list, only a single writer is allowed.

right.

> Write lock will not be acquired until all read lock are released.

So i must have confused rwlock with something else, something that
allows self to hold a read-lock and upgrade that to a write-lock,
purposely starving all successive incoming readers. I.e. just toggle
your RD_TO_WRLOCK impl, here, atomically. This proved to be benefical in
some situations in the past. Doesn't seem to work with your rwlock,
does it

> And I didn't change the mutex scope when refactor the code, only make a 
> more fine-grained distinction for the read/write cache/unit list.

Yes of course, i can see you did that.

> I complete the comment according to your template, I will insert the 
> comment in the source code in next version patch with other refinement 
> by your suggestions.
> "
> Now we did not get a unit in cache and unit list, so we need to create a
> new unit, and update it to cache and unit list.

s/Now/By now/ or s/Now w/W/ and s/get/find/
"
We did not find a unit in the cache nor in the unit list, create a new
(locked) unit and insert into the unit list and cache.
Manipulating either or both the unit list and the unit cache requires to
hold a write-lock [for obvious reasons]"

Superfluous when talking about pthread_rwlock_wrlock since that
implies that even the process acquiring the wrlock has to first
release it's very own rdlock.

> Prior to update the cache and list, we need to release all read locks,
> and then immediately to acquire write lock, thus ensure the exclusive
> update to the cache and unit list.
> Either way, we will manipulate the cache and/or the unit list so we must
> take a write lock now.
> We don't take the write bit in *addition* to the read lock because:
> 1. It will needlessly complicate releasing the respective lock;

Under pthread_rwlock_wrlock it will deadlock, so that's wrong?
Drop that point then? If not, what's your reasoning / observation?

Under my lock, you hold the R, additionally take the W and then
immediately release the R because you yourself won't read, just write.
But mine's not the pthread_rwlock you talk about, admittedly.

> 2. By separate the read/write lock, it will greatly reduce the
> contention at the read part, while write part is not always necessary or
> most unlikely once the unit hit in cache;

We know that.

> 3. We try to balance the implementation complexity and the performance
> gains that fit into current cases we observed.

.. by just using a pthread_rwlock. And that's the top point iff you
keep it at that. That's a fair step, sure. BTW, did you look at the
RELEASE semantics, respectively the note that one day (and now is that
very day), we might improve on the release semantics? Can of course be
incremental AFAIC

> "

If folks agree on this first step then you have my OK with a catchy
malloc and the discussion recorded here on the list. A second step would
be RELEASE.
And, depending on the underlying capabilities of available locks,
further tweaks, obviously.

PS: and, please, don't top-post

thanks,

> 
> Best Regards,
> Zhu, Lipeng
> 
> On 1/1/1970 8:00 AM, Bernhard Reutner-Fischer wrote:
> > On 19 April 2023 09:06:28 CEST, Lipeng Zhu via Fortran 
> >  wrote:  
> >> This patch try to introduce the rwlock and split the read/write to
> >> unit_root tree and unit_cache with rwlock instead of the mutex to
> >> increase CPU efficiency. In the get_gfc_unit function, the percentage
> >> to step into the insert_unit function is around 30%, in most instances,
> >> we can get the unit in the phase of reading the unit_cache or unit_root
> >> tree. So split the read/write phase by rwlock would be an approach to
> >> make it more parallel.
> >>
> >> BTW, the IPC metrics can gain around 9x in our test server with 220
> >> cores. The benchmark we used is https://github.com/rwesson/NEAT
> >>  
> >   
> >> +#define RD_TO_WRLOCK(rwlock) \
> >> +  RWUNLOCK (rwlock);\
> >> +  WRLOCK (rwlock);
> >> +#endif
> >> +  
> > 
> >   
> >> diff --git a/libgfortran/io/unit.c b/libgfortran/io/unit.c index
> >> 82664dc5f98..4312c5f36de 100644
> >> --- a/libgfortran/io/unit.c
> >> +++ b/libgfortran/io/unit.c  
> >   
> >> @@ -329,7 +335,7 @@ get_gfc_unit (int n, int do_create)
> >>int c, created = 0;
> >>
> >>NOTE ("Unit n=%d, do_create = %d", n, do_create);
> >> -  LOCK (_lock);
> &

Re: [Patch, fortran] PRs 105152, 100193, 87946, 103389, 104429 and 82774

[Bernhard Reutner-Fischer via Gcc-patches]

On Sun, 23 Apr 2023 23:48:03 +0200
Harald Anlauf via Fortran  wrote:

> Am 22.04.23 um 10:32 schrieb Paul Richard Thomas via Gcc-patches:

> > PR103931 - I couldn't reproduce the bug, which involves 'ambiguous c_ptr'.
> > To judge by the comments, it seems that this bug is a bit elusive.

See Haralds comment 12, you need to remove the use cmodule:
module DModule
   use AModule
   !comment 12, 'use CModule' should not be needed: use CModule
   !use CModule

   implicit none
   private

   public :: DType

   type, abstract :: DType
   end type
end module

> PR103931: it is indeed a bit elusive, but very sensitive to code
> changes.  Also Bernhard had a look at it.  Given that there are
> a couple of bugs related to module reading, and rename-on-use,
> I'd recommend to leave that open for further analysis.

I would mark the dt sym that is used *as* the generic interface with
attr.generic.

Like: https://gcc.gnu.org/PR103931#c18

This seems to work and sounds somewhat plausible (to me).
If that is not correct, then i'm running out of ideas and will stop
looking at that PR.

cheers,

Re: [PATCH v3] libgfortran: Replace mutex with rwlock

[Bernhard Reutner-Fischer via Gcc-patches]

On 19 April 2023 09:06:28 CEST, Lipeng Zhu via Fortran  
wrote:
>This patch try to introduce the rwlock and split the read/write to
>unit_root tree and unit_cache with rwlock instead of the mutex to
>increase CPU efficiency. In the get_gfc_unit function, the percentage
>to step into the insert_unit function is around 30%, in most instances,
>we can get the unit in the phase of reading the unit_cache or unit_root
>tree. So split the read/write phase by rwlock would be an approach to
>make it more parallel.
>
>BTW, the IPC metrics can gain around 9x in our test
>server with 220 cores. The benchmark we used is
>https://github.com/rwesson/NEAT
>

>+#define RD_TO_WRLOCK(rwlock) \
>+  RWUNLOCK (rwlock);\
>+  WRLOCK (rwlock);
>+#endif
>+


>diff --git a/libgfortran/io/unit.c b/libgfortran/io/unit.c
>index 82664dc5f98..4312c5f36de 100644
>--- a/libgfortran/io/unit.c
>+++ b/libgfortran/io/unit.c

>@@ -329,7 +335,7 @@ get_gfc_unit (int n, int do_create)
>   int c, created = 0;
> 
>   NOTE ("Unit n=%d, do_create = %d", n, do_create);
>-  LOCK (_lock);
>+  RDLOCK (_rwlock);
> 
> retry:
>   for (c = 0; c < CACHE_SIZE; c++)
>@@ -350,6 +356,7 @@ retry:
>   if (c == 0)
>   break;
> }
>+  RD_TO_WRLOCK (_rwlock);

So I'm trying to convince myself why it's safe to unlock and only then take the 
write lock.

Can you please elaborate/confirm why that's ok?

I wouldn't mind a comment like
We can release the unit and cache read lock now. We might have to allocate a 
(locked) unit, below in do_create.
Either way, we will manipulate the cache and/or the unit list so we have to 
take a write lock now.

We don't take the write bit in *addition* to the read lock because..

(that needlessly complicates releasing the respective locks / it triggers too 
much contention when we.. / ...?)

thanks,

> 
>   if (p == NULL && do_create)
> {
>@@ -368,8 +375,8 @@ retry:
>   if (created)
> {
>   /* Newly created units have their lock held already
>-   from insert_unit.  Just unlock UNIT_LOCK and return.  */
>-  UNLOCK (_lock);
>+   from insert_unit.  Just unlock UNIT_RWLOCK and return.  */
>+  RWUNLOCK (_rwlock);
>   return p;
> }
> 
>@@ -380,7 +387,7 @@ found:
>   if (! TRYLOCK (>lock))
>   {
> /* assert (p->closed == 0); */
>-UNLOCK (_lock);
>+RWUNLOCK (_rwlock);
> return p;
>   }
> 
>@@ -388,14 +395,14 @@ found:
> }
> 
> 
>-  UNLOCK (_lock);
>+  RWUNLOCK (_rwlock);
> 
>   if (p != NULL && (p->child_dtio == 0))
> {
>   LOCK (>lock);
>   if (p->closed)
>   {
>-LOCK (_lock);
>+WRLOCK (_rwlock);
> UNLOCK (>lock);
> if (predec_waiting_locked (p) == 0)
>   destroy_unit_mutex (p);
>@@ -593,8 +600,8 @@ init_units (void)
> #endif
> #endif
> 
>-#ifndef __GTHREAD_MUTEX_INIT
>-  __GTHREAD_MUTEX_INIT_FUNCTION (_lock);
>+#if (!defined(__GTHREAD_RWLOCK_INIT) && !defined(__GTHREAD_MUTEX_INIT))
>+  __GTHREAD_MUTEX_INIT_FUNCTION (_rwlock);
> #endif
> 
>   if (sizeof (max_offset) == 8)

Re: [PATCH v3] doc: Document order of define_peephole2 scanning

[Bernhard Reutner-Fischer via Gcc-patches]

[+list]
On 19 April 2023 21:21:18 CEST, Bernhard Reutner-Fischer 
 wrote:
>Hi H-P!
>
>This begs the question iff now (i fear it's not), upon successful match(es), 
>the whole peepholes get re-run again per BB (ATM?), exposing more 
>opportunities?
>If not, would we want to retry, at least for -fexpensive-optimisations (sp?) 
>or would all hell break loose?
>
>Please also see below.
>
>On 19 April 2023 18:59:14 CEST, Hans-Peter Nilsson via Gcc-patches 
> wrote:
>>> From: Hans-Peter Nilsson 
>>> Date: Wed, 19 Apr 2023 06:06:27 +0200
>>> 
>>> Patch retracted, at least temporarily.  My "understanding"
>>> may be clouded by looking at an actual bug.  Sigh.
>>
>>Mea culpa.  I was looking at the result of one
>>define_peephole2 and thinking it was due to another, and
>>also tricked by incorrect code comments (patch posted, will
>>commit).
>>
>>TL;DR: Matching indeed does resume with attempting to match
>>the *first* define_peephole2 replacement insn.  But the
>>match-and-replacement order is largely undocumented.
>>
>>Anyway, the missing-context problem I ran into remains: if
>>you have an insn sequence {foo bar} and a define_peephole2
>>matching and replacing {bar} into {baz}, the resulting {foo
>>baz} *will not be matched* against a define_peephole2
>>looking for {foo baz}.  But, I'm not trying to document this
>>caveat specifically, though at least it'll now be implied by
>>the documentation.
>>
>>This could be fixed by always backing up MAX_INSNS_PER_PEEP2
>>- 1 insns after a successful replacement.  I'm somewhat
>>worries that this would also mean lots of futile re-match
>>attempts.  Thoughts?
>
>Good point. Probably. Do you have stats?
>
>If there is even a slight benefit, then some certainly would be willing to 
>take that penalty for sure. I.e. iff it helps -Os or locality then such 
>expensive optimisations certainly provide benefit for at least a few if not 
>some, IMO.
>
>Just curious && cheers,
>
>>
>>(I could also just restart at the BB start, but I see all
>>this support for backing-up live info by single insns being
>>used.  Taking notes about a partial match for the first insn
>>of a failed attempt, as the maximum need to back-up to,
>>doesn't look like it'd fly, judging from the nonspecific
>>looking (set dest src) patterns being the first in i386
>>define_peephole2's match sequences.)
>

Re: [PATCH] testsuite: fix scan-tree-dump patterns [PR83904, PR100297]

[Bernhard Reutner-Fischer via Gcc-patches]

On Wed, 19 Apr 2023 at 03:03, Jerry D via Fortran  wrote:
>
> On 4/18/23 12:39 PM, Harald Anlauf via Fortran wrote:
> > Dear all,
> >
> > the attached patch adjusts the scan-tree-dump patterns of the
> > reported testcases which likely were run in a location such
> > that a path in an error message showing in the tree-dump might
> > have accidentally matched "free" or "data", respectively.
> >
> > For the testcase gfortran.dg/reshape_8.f90 I checked with a
> > failing gfortran-11 that the pattern is appropriate.
> >
> > OK for mainline?
> >
> > Thanks,
> > Harald
> >
> Yes, OK

I'm certainly not opposed to this specific incarnation of such a fix.
These failures are really unpleasant :)
As proposed in 
https://inbox.sourceware.org/gcc-patches/20220426010029.2b476337@nbbrfq/
we could add a -fno-file to suppress the assembler .file output
(whatever the prefix looks like depends on the assembler dialect). Or
we could nuke the .file directives by a sed(1), but that would
probably be cumbersome for remote targets. I don't have a better idea
than -fno-file or -ffile=foo.c .
Fixing them case-by-case does not scale all that well IMHO.

Thoughts?

Re: [PATCH v3] libgfortran: Replace mutex with rwlock

[Bernhard Reutner-Fischer via Gcc-patches]

On Wed, 19 Apr 2023 at 14:51, Bernhard Reutner-Fischer
 wrote:
>
> On 19 April 2023 09:06:28 CEST, Lipeng Zhu via Fortran  
> wrote:
>
> >+#ifdef __GTHREAD_RWLOCK_INIT
> >+#define RWLOCK_DEBUG_ADD(rwlock) do { \
> >+aio_rwlock_debug *n;  \
> >+n = malloc (sizeof(aio_rwlock_debug));\
>
> My malloc can fail.

Sorry, i hit send too early.
Please use xmalloc as defined in libgfortran/runtime/memory.c

PS: IIRC we have likely() / unlikely() macros in libgfortran, so you
may want to check if you want to annotate some conditions accordingly
if predict gets it wrong.
thanks,
>
> >+n->prev = TAIL_RWLOCK_DEBUG_QUEUE;\
> >+if (n->prev)  \
> >+  n->prev->next = n;  \
> >+n->next = NULL;   \
> >+n->line = __LINE__;   \
> >+n->func = __FUNCTION__;   \
> >+n->rw = rwlock;   \
> >+if (!aio_rwlock_debug_head) { \
> >+  aio_rwlock_debug_head = n;  \
> >+} \
> >+  } while (0)
> >+
>