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

2024-02-02 Thread Bernhard Reutner-Fischer via Gcc
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

2024-01-29 Thread Bernhard Reutner-Fischer via Gcc
[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 8/8] OpenMP: Fortran "!$omp declare mapper" support

2023-09-14 Thread 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

2023-06-23 Thread 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

2023-06-23 Thread 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

2023-06-22 Thread 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

2023-06-21 Thread 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

2023-06-19 Thread 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)

2023-06-15 Thread 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

2023-06-14 Thread 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)

2023-06-12 Thread 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)

2023-06-09 Thread 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

2023-06-03 Thread 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

2023-06-03 Thread 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

2023-06-01 Thread 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

2023-06-01 Thread 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

2023-06-01 Thread 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.

2023-06-01 Thread 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

2023-05-31 Thread 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

2023-05-31 Thread 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

2023-05-31 Thread 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

2023-05-26 Thread 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_swap (, , mem, expect, desired,
    is_weak, success, failure))
@@ -6387,8 +6387,8 @@ expand_ifn_atomic_compare_exchange (gcall *call)
 
   

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

2023-05-25 Thread 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]

2023-05-24 Thread 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]

2023-05-19 Thread 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

2023-05-19 Thread 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]

2023-05-19 Thread 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

2023-05-18 Thread 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

2023-05-18 Thread 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]

2023-05-18 Thread 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

2023-05-18 Thread 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]

2023-05-18 Thread 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]

2023-05-15 Thread 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

2023-05-15 Thread 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]

2023-05-14 Thread 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

2023-05-13 Thread 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->decl))
 return true;
 
-  if (TREE_CODE (e->decl) == VAR_DECL)
+  if 

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

2023-05-13 Thread 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

2023-05-13 Thread 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/pdp11/pdp11.cc 

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

2023-05-13 Thread 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 (tree, Bvariable *var, tree 
init_tree)
   tree 

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

2023-05-13 Thread 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/gcc/ada/gcc-interface/trans.cc
@@ -1241,7 +1241,7 @@ Identifier_to_gnu (Node_Id gnat_node, tree 
*gnu_result_type_p)
   /* Do the 

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

2023-05-13 Thread 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_TYPE (t1);
  if (TREE_CODE (t2) == COMPLEX_TYPE)
t2 = TREE_TYPE (t2);
- 

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

2023-05-13 Thread 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

2023-05-13 Thread 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_trans_assignment_1 (gfc_expr * expr1, gfc_expr * 
expr2, bool init_flag,
   if (expr2->ts.type == BT_CHARACTER && !expr1->ts.deferred
   && !(VAR_P (rse.string_length)
   

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

2023-05-13 Thread 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 (location_t loc, tree type, tree 

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

2023-05-13 Thread 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

2023-05-13 Thread 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

2023-05-13 Thread 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)
  && is_gimple_omp_offloaded (ctx->stmt))

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

2023-05-13 Thread 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_sign)
   else
 {
   /* Warn for real types converted 

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

2023-05-13 Thread 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

2023-05-13 Thread 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)

2023-05-12 Thread 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

2023-05-12 Thread 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

2023-05-11 Thread 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

2023-05-10 Thread 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]

2023-05-10 Thread 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

2023-05-10 Thread 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]

2023-05-10 Thread 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]

2023-05-10 Thread 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.

2023-05-10 Thread 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]

2023-05-09 Thread 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]

2023-05-08 Thread 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

2023-05-08 Thread 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

2023-05-08 Thread 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()

2023-05-08 Thread 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

2023-05-08 Thread 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]

2023-05-06 Thread 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

2023-04-28 Thread 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

2023-04-28 Thread Bernhard Reutner-Fischer via Gcc
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: libsanitizer: sync from master

2023-04-28 Thread 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

2023-04-27 Thread 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

2023-04-26 Thread 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

2023-04-26 Thread 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

2023-04-26 Thread Bernhard Reutner-Fischer via Gcc
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: libsanitizer: sync from master

2023-04-26 Thread 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

2023-04-25 Thread 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

2023-04-25 Thread 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

2023-04-24 Thread 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);
> >> +  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
> 

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

2023-04-24 Thread 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

2023-04-19 Thread 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

2023-04-19 Thread 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]

2023-04-19 Thread 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

2023-04-19 Thread 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)
> >+
>


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

2023-04-19 Thread Bernhard Reutner-Fischer via Gcc-patches
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.

>+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)
>+



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

2023-04-17 Thread Bernhard Reutner-Fischer via Gcc-patches
Ping!

Harald fixed the leak in set_exponent in the meantime.
As stated in the cover-letter, it was bootstrapped and regtested
without regression on x86_64-foo-linux.

I consider it obvious, but never the less, OK for trunk (as in gcc-14)
so far?

thanks,

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.
> 
> thanks,
> >  
> >> diff --git a/gcc/fortran/expr.cc b/gcc/fortran/expr.cc
> >> index 7fb33f81788..b4736804eda 100644
> >> --- a/gcc/fortran/expr.cc
> >> +++ b/gcc/fortran/expr.cc
> >> @@ -1539,6 +1539,7 @@ find_array_section (gfc_expr *expr, gfc_ref *ref)
> >> mpz_init_set_ui (delta_mpz, one);
> >> mpz_init_set_ui (nelts, one);
> >> mpz_init (tmp_mpz);
> >> +  mpz_init (ptr);
> >> 
> >> /* Do the initialization now, so that we can cleanup without
> >>keeping track of where we were.  */
> >> @@ -1682,7 +1683,6 @@ find_array_section (gfc_expr *expr, gfc_ref *ref)
> >> mpz_mul (delta_mpz, delta_mpz, tmp_mpz);
> >>   }
> >> 
> >> -  mpz_init (ptr);
> >> cons = gfc_constructor_first (base);
> >> 
> >> /* Now clock through the array reference, calculating the index in
> >> @@ -1735,7 +1735,8 @@ find_array_section (gfc_expr *expr, gfc_ref *ref)
> >> "at %L requires an increase of the allowed %d "
> >> "upper limit.  See %<-fmax-array-constructor%> "
> >> "option", >where, flag_max_array_constructor);
> >> -return false;
> >> +t = false;
> >> +goto cleanup;
> >>}
> >> 
> >> cons = gfc_constructor_lookup (base, limit);
> >> @@ -1750,8 +1751,6 @@ find_array_section (gfc_expr *expr, gfc_ref *ref)
> >>   gfc_copy_expr (cons->expr), NULL);
> >>   }
> >> 
> >> -  mpz_clear (ptr);
> >> -
> >>   cleanup:
> >> 
> >> mpz_clear (delta_mpz);
> >> @@ -1765,6 +1764,7 @@ cleanup:
> >> mpz_clear (ctr[d]);
> >> mpz_clear (stride[d]);
> >>   }
> >> +  mpz_clear (ptr);
> >> gfc_constructor_free (base);
> >> return t;
> >>   }
> >> diff --git a/gcc/fortran/simplify.cc b/gcc/fortran/simplify.cc
> >> index ecf0e3558df..d1f06335e79 100644
> >> --- a/gcc/fortran/simplify.cc
> >> +++ b/gcc/fortran/simplify.cc
> >> @@ -6866,6 +6866,7 @@ gfc_simplify_reshape (gfc_expr *source, gfc_expr 
> >> *shape_exp,
> >>  gfc_error ("The SHAPE array 

Re: [PATCH,FORTRAN 00/29] Move towards stringpool, part 1

2023-04-13 Thread Bernhard Reutner-Fischer via Gcc-patches
Hi all, Janne!

On Wed, 19 Sep 2018 16:40:01 +0200
Bernhard Reutner-Fischer  wrote:
> On Fri, 7 Sep 2018 at 10:07, Bernhard Reutner-Fischer
>  wrote:
> >
> > On Wed, 5 Sep 2018 at 20:57, Janne Blomqvist  
> > wrote:  
> > >
> > > On Wed, Sep 5, 2018 at 5:58 PM Bernhard Reutner-Fischer 
> > >  wrote:  
> >  
> > >> Bootstrapped and regtested on x86_64-foo-linux.
> > >>
> > >> I'd appreciate if someone could double check for regressions on other
> > >> setups. Git branch:
> > >> https://gcc.gnu.org/git/?p=gcc.git;a=log;h=refs/heads/aldot/fortran-fe-stringpool
> > >>
> > >> Ok for trunk?  
> > >
> > >
> > > Hi,
> > >
> > > this is quite an impressive patch set. I have looked through all the 
> > > patches, and on the surface they all look ok.  
> >
> > Thanks alot for your appreciation!  
> > >
> > > Unfortunately I don't have any exotic target to test on either, so I 
> > > think you just have to commit it and check for regression reports. Though 
> > > I don't see this set doing anything which would work differently on other 
> > > targets, but you never know..
> > >
> > > I'd say wait a few days in case anybody else wants to comment on it, then 
> > > commit it to trunk.  

Unfortunately I never got to commit it.

Are you still OK with this series?

Iff so, i will refresh it for gcc-14 stage1. I would formally resubmit
the series for approval then, of course, for good measure.

It will need some small adjustments since coarrays were added
afterwards and a few other spots were changed since then.

Note that after your OK i fixed the problem described below with this
patch
https://inbox.sourceware.org/gcc-patches/20180919225533.20009-1-rep.dot@gmail.com/
and so i think this "[PATCH,FORTRAN v2] Use stringpool on loading
module symbols" was not formally OKed yet, FWIW. I believe that this v2 worked 
flawlessly.
Note, however, that by adding/changing module names of symbols in the
module files, this will (i think / fear) require a bump of the module
version if we are honest. Ultimately that was the reason why i did not
push the series back then.

Link to the old series:
https://inbox.sourceware.org/gcc-patches/20180905145732.404-1-rep.dot@gmail.com/

thanks and cheers,

> >
> > Upon further testing i encountered a regression in module writing,
> > manifesting itself in a failure to compile ieee_8.f90 (and only this).  
> 
> > Sorry for that, I'll have another look during the weekend.  
> 
> so in free_pi_tree we should not free true_name nor module:
> 
> @@ -239,12 +239,6 @@ free_pi_tree (pointer_info *p)
>free_pi_tree (p->left);
>free_pi_tree (p->right);
> 
> -  if (iomode == IO_INPUT)
> -{
> -  XDELETEVEC (p->u.rsym.true_name);
> -  XDELETEVEC (p->u.rsym.module);
> -}
> -
>free (p);
>  }
> 
> This fixes the module writing but leaks, obviously.
> Now the reason why i initially did not use mio_pool_string for both
> rsym.module and rsym.true_name was that mio_pool_string sets the name
> to NULL if the string is empty.
> Currently these are read by read_string() [which we should get rid of
> entirely, the 2 mentioned fields are the last two who use
> read_string()] which does not nullify the empty string but returns
> just the pointer. For e.g. ieee_8.f90 using mio_pool_string gives us a
> NULL module which leads to gfc_use_module -> load_needed ->
> gfc_find_symbol -> gfc_find_sym_tree -> gfc_find_symtree which tries
> to c = strcmp (name, st->name); where name is NULL.
> 
> The main culprits seem to be class finalization wrapper variables so
> i'm adding modules to those now.
> Which leaves me with regressions like allocate_with_source_14.f03.
> "Fixing" these by falling back to gfc_current_ns->proc_name->name in
> load_needed for !ns->proc_name if the rsym->module is NULL seems to
> work.
> 
> Now there are a number of issues with names of fixups. Like the 9 in e.g.:
> 
> $ zcat /tmp/n/m.mod | egrep -v "^(\(\)|\(\(\)|$)"
> GFORTRAN module version '15' created from generic_27.f90
> (('testif' 'm' 2 3))
> (4 'm' 'm' '' 1 ((MODULE UNKNOWN-INTENT UNKNOWN-PROC UNKNOWN UNKNOWN 0 0)
> 3 'test1' 'm' '' 1 ((PROCEDURE UNKNOWN-INTENT MODULE-PROC DECL UNKNOWN 0
> 0 FUNCTION) () (REAL 4 0 0 0 REAL ()) 5 0 (6) () 3 () () () 0 0)
> 2 'test2' 'm' '' 1 ((PROCEDURE UNKNOWN-INTENT MODULE-PROC DECL UNKNOWN 0
> 0 FUNCTION ARRAY_OUTER_DEPENDENCY) () (REAL 4 0 0 0 REAL ()) 7 0 (8) ()
> 2 () () () 0 0)
> 6 'obj' '' '' 5 ((VARIABLE UNKNOWN-INTENT UNKNOWN-PROC UNKNOWN UNKNOWN 0
> 0 DUMMY) () (REAL 4 0 0 0 REAL ()) 0 0 () () 0 () () () 0 0)
> 8 'pr' '' '' 7 ((PROCEDURE UNKNOWN-INTENT DUMMY-PROC UNKNOWN UNKNOWN 0 0
> EXTERNAL DUMMY FUNCTION PROCEDURE ARRAY_OUTER_DEPENDENCY) () (REAL 4 9 0
> 0 REAL ()) 0 0 () () 8 () () () 0 0)
> 9 '' '' '' 7 ((PROCEDURE UNKNOWN-INTENT UNKNOWN-PROC UNKNOWN UNKNOWN 0 0
> FUNCTION) () (REAL 4 0 0 0 REAL ()) 0 0 () () 0 () () () 0 0)
> )
> ('m' 0 4 'test1' 0 3 'test2' 0 2)
> 
> which is a bit of a complication since we need them to verify proper
> interface types and 

Re: [PATCH v2] ree: Improve ree pass for rs6000 target.

2023-04-12 Thread Bernhard Reutner-Fischer via Gcc-patches
On 6 April 2023 12:49:53 CEST, Ajit Agarwal via Gcc-patches 
 wrote:
>Hello All:
>
>Eliminate unnecessary redundant extension within basic and across basic blocks.

To borrow HP's "arm-chair development mode", unfortunately most of the comments 
i had for the previous version apply to this version too, fwiw.

PS: Pretty please avoid moving functions around, if possible, as it spoils the 
history needlessly, IMHO.

thanks, and looking forward to a stage 1 patch.


Re: [RFC PATCH] range-op-float: Fix up op1_op2_relation of comparisons

2023-04-12 Thread Bernhard Reutner-Fischer via Gcc-patches
On 12 April 2023 16:21:24 CEST, Jakub Jelinek via Gcc-patches 
 wrote:

>--- gcc/range-op-float.cc.jj   2023-04-12 12:17:44.784962757 +0200
>+++ gcc/range-op-float.cc  2023-04-12 16:07:54.948759355 +0200
>@@ -835,10 +835,17 @@ public:
>   bool fold_range (irange , tree type,
>  const frange , const frange ,
>  relation_trio = TRIO_VARYING) const final override;
>-  relation_kind op1_op2_relation (const irange , const frange &,
>-const frange &) const final override
>+  relation_kind op1_op2_relation (const irange , const frange ,
>+const frange ) const final override
>   {
>-return lt_op1_op2_relation (lhs);
>+relation_kind ret = lt_op1_op2_relation (lhs);
>+if (ret == VREL_GE
>+  && (op1.known_isnan ()
>+  || op1.maybe_isnan ()
>+  || op2.known_isnan ()
>+  || op2.maybe_isnan ()))
>+  ret = VREL_VARYING; // Inverse of VREL_LT is VREL_UNGE with NAN ops.
>+return ret;
>   }
>   bool op1_range (frange , tree type,
> const irange , const frange ,
>@@ -952,9 +959,17 @@ public:
>   bool fold_range (irange , tree type,
>  const frange , const frange ,
>  relation_trio rel = TRIO_VARYING) const final override;
>-  relation_kind op1_op2_relation (const irange , const frange &,
>-const frange &) const final override
>+  relation_kind op1_op2_relation (const irange , const frange ,
>+const frange ) const final override
>   {
>+relation_kind ret = le_op1_op2_relation (lhs);
>+if (ret == VREL_GT
>+  && (op1.known_isnan ()
>+  || op1.maybe_isnan ()
>+  || op2.known_isnan ()
>+  || op2.maybe_isnan ()))
>+  ret = VREL_VARYING; // Inverse of VREL_LE is VREL_UNGT with NAN ops.
>+return ret;
> return le_op1_op2_relation (lhs);

I think you forgot to delete the above return.

thanks,


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

2023-04-03 Thread Bernhard Reutner-Fischer via Gcc-patches
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.

thanks,
>
>> diff --git a/gcc/fortran/expr.cc b/gcc/fortran/expr.cc
>> index 7fb33f81788..b4736804eda 100644
>> --- a/gcc/fortran/expr.cc
>> +++ b/gcc/fortran/expr.cc
>> @@ -1539,6 +1539,7 @@ find_array_section (gfc_expr *expr, gfc_ref *ref)
>> mpz_init_set_ui (delta_mpz, one);
>> mpz_init_set_ui (nelts, one);
>> mpz_init (tmp_mpz);
>> +  mpz_init (ptr);
>> 
>> /* Do the initialization now, so that we can cleanup without
>>keeping track of where we were.  */
>> @@ -1682,7 +1683,6 @@ find_array_section (gfc_expr *expr, gfc_ref *ref)
>> mpz_mul (delta_mpz, delta_mpz, tmp_mpz);
>>   }
>> 
>> -  mpz_init (ptr);
>> cons = gfc_constructor_first (base);
>> 
>> /* Now clock through the array reference, calculating the index in
>> @@ -1735,7 +1735,8 @@ find_array_section (gfc_expr *expr, gfc_ref *ref)
>>   "at %L requires an increase of the allowed %d "
>>   "upper limit.  See %<-fmax-array-constructor%> "
>>   "option", >where, flag_max_array_constructor);
>> -  return false;
>> +  t = false;
>> +  goto cleanup;
>>  }
>> 
>> cons = gfc_constructor_lookup (base, limit);
>> @@ -1750,8 +1751,6 @@ find_array_section (gfc_expr *expr, gfc_ref *ref)
>> gfc_copy_expr (cons->expr), NULL);
>>   }
>> 
>> -  mpz_clear (ptr);
>> -
>>   cleanup:
>> 
>> mpz_clear (delta_mpz);
>> @@ -1765,6 +1764,7 @@ cleanup:
>> mpz_clear (ctr[d]);
>> mpz_clear (stride[d]);
>>   }
>> +  mpz_clear (ptr);
>> gfc_constructor_free (base);
>> return t;
>>   }
>> diff --git a/gcc/fortran/simplify.cc b/gcc/fortran/simplify.cc
>> index ecf0e3558df..d1f06335e79 100644
>> --- a/gcc/fortran/simplify.cc
>> +++ b/gcc/fortran/simplify.cc
>> @@ -6866,6 +6866,7 @@ gfc_simplify_reshape (gfc_expr *source, gfc_expr 
>> *shape_exp,
>>gfc_error ("The SHAPE array for the RESHAPE intrinsic at %L has a "
>>   "negative value %d for dimension %d",
>>   _exp->where, shape[rank], rank+1);
>> +  mpz_clear (index);
>>return _bad_expr;
>>  }
>> 
>> @@ -6889,6 +6890,7 @@ gfc_simplify_reshape (gfc_expr *source, gfc_expr 
>> *shape_exp,
>>  {
>>gfc_error ("Shapes of ORDER at %L and SHAPE at %L are different",
>>   _exp->where, _exp->where);
>> +  mpz_clear (index);
>>return _bad_expr;
>>  }
>> 
>> @@ -6902,6 +6904,7 @@ gfc_simplify_reshape (gfc_expr *source, gfc_expr 
>> *shape_exp,
>>  {
>>gfc_error ("Sizes of ORDER at %L and SHAPE at %L are different",
>>

Re: [PATCH 2/2] Fortran: Fix memory leak in gfc_add_include_path [PR68800]

2023-04-02 Thread Bernhard Reutner-Fischer via Gcc-patches
ping?

libcpp maintainers, is the helper in incpath.* ok?

fortraners,
Do you prefer a rogue, local forward declaration, or is the
introduction of that trivial wrapper ok? I don't think pulling in cpp.h
from f95-lang.cc is desirable, but i can do that if you all think
that's preferred.

cover-letter:
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583522.html

gcc/incpath.* bits (i guess that'd be for the libcpp maintainers):
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583520.html

fortran bits:
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583521.html

thanks,

On Sun, 7 Nov 2021 02:38:21 +0100
Bernhard Reutner-Fischer  wrote:

> On Sat, 6 Nov 2021 20:22:53 +0100
> Harald Anlauf  wrote:
> 
> > Hi Bernhard,
> > 
> > I cannot comment on the gcc/ parts, but
> >   
> 
> > > diff --git a/gcc/fortran/cpp.c b/gcc/fortran/cpp.c
> > > index e86386c8b17..04fe8fe460b 100644
> > > --- a/gcc/fortran/cpp.c
> > > +++ b/gcc/fortran/cpp.c
> > > @@ -728,12 +728,20 @@ gfc_cpp_done (void)
> > > cpp_clear_file_cache (cpp_in);
> > >   }
> > 
> > why do you introduce a wrapper for something outside of fortran
> > that is used only once,
> >   
> > > -/* PATH must be malloc-ed and NULL-terminated.  */
> > > +/* Free all cpp include dirs.  */
> > > +void
> > > +gfc_cpp_free_cpp_dirs (void)
> > > +{
> > > +  free_cpp_dirs ();
> > > +}  
> 
> > > diff --git a/gcc/fortran/cpp.h b/gcc/fortran/cpp.h
> > > index 44644a2a333..963b9a9c89e 100644
> > > --- a/gcc/fortran/cpp.h
> > > +++ b/gcc/fortran/cpp.h
> > > @@ -46,6 +46,7 @@ void gfc_cpp_post_options (bool);
> > >   bool gfc_cpp_preprocess (const char *source_file);
> > >
> > >   void gfc_cpp_done (void);
> > > +void gfc_cpp_free_cpp_dirs (void);
> > >
> > >   void gfc_cpp_add_include_path (char *path, bool user_supplied);
> > >   void gfc_cpp_add_include_path_after (char *path, bool user_supplied);
> > > diff --git a/gcc/fortran/f95-lang.c b/gcc/fortran/f95-lang.c
> > > index 58dcaf01d75..ec4c2cf01d9 100644
> > > --- a/gcc/fortran/f95-lang.c
> > > +++ b/gcc/fortran/f95-lang.c
> > > @@ -275,7 +275,7 @@ gfc_finish (void)
> > > gfc_cpp_done ();
> > > gfc_done_1 ();
> > > gfc_release_include_path ();
> > > -  return;
> > 
> > namely here?
> >   
> > > +  gfc_cpp_free_cpp_dirs ();
> > >   }
> > 
> > Why not call free_cpp_dirs () here directly, omit all unnecessary
> > stuff, and maybe only add a brief comment here?  
> 
> cpp.c includes incpath.h, f95-lang.c does not and should not.
> So the cleanest thing is to keep the cpp handling in cpp.[ch] and have
> the language frontend call into it's cpp bits.
> 
> It would be rather rogue to
> extern void free_cpp_dirs (void);
> in f95-lang.c and directly call it in gfc_finish, i'd say?
> 
> thanks,



[PATCH 2/3] rust: Fix memory leak in compile_{integer,float}_literal

2023-04-02 Thread Bernhard Reutner-Fischer via Gcc-patches
From: Bernhard Reutner-Fischer 

Cc: Arthur Cohen 
Cc: Philip Herron 

gcc/rust/ChangeLog:

* backend/rust-compile-expr.cc (CompileExpr::compile_integer_literal):
(CompileExpr::compile_float_literal): Fix memory leak.
---
 gcc/rust/backend/rust-compile-expr.cc | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/gcc/rust/backend/rust-compile-expr.cc 
b/gcc/rust/backend/rust-compile-expr.cc
index 436fc924a13..82078b81953 100644
--- a/gcc/rust/backend/rust-compile-expr.cc
+++ b/gcc/rust/backend/rust-compile-expr.cc
@@ -2119,6 +2119,7 @@ CompileExpr::compile_integer_literal (const 
HIR::LiteralExpr ,
   if (mpz_init_set_str (ival, literal_value.as_string ().c_str (), 10) != 0)
 {
   rust_error_at (expr.get_locus (), "bad number in literal");
+  mpz_clear (ival);
   return error_mark_node;
 }
 
@@ -2133,6 +2134,9 @@ CompileExpr::compile_integer_literal (const 
HIR::LiteralExpr ,
   rust_error_at (expr.get_locus (),
 "integer overflows the respective type %<%s%>",
 tyty->get_name ().c_str ());
+  mpz_clear (type_min);
+  mpz_clear (type_max);
+  mpz_clear (ival);
   return error_mark_node;
 }
 
@@ -2158,6 +2162,7 @@ CompileExpr::compile_float_literal (const 
HIR::LiteralExpr ,
   != 0)
 {
   rust_error_at (expr.get_locus (), "bad number in literal");
+  mpfr_clear (fval);
   return error_mark_node;
 }
 
@@ -2179,9 +2184,11 @@ CompileExpr::compile_float_literal (const 
HIR::LiteralExpr ,
   rust_error_at (expr.get_locus (),
 "decimal overflows the respective type %<%s%>",
 tyty->get_name ().c_str ());
+  mpfr_clear (fval);
   return error_mark_node;
 }
 
+  mpfr_clear (fval);
   return real_value;
 }
 
-- 
2.30.2



[PATCH 1/3] go: Fix memory leak in Integer_expression

2023-04-02 Thread Bernhard Reutner-Fischer via Gcc-patches
From: Bernhard Reutner-Fischer 

Cc: Ian Lance Taylor 

gcc/go/ChangeLog:

* gofrontend/expressions.cc (Integer_expression::do_import): Fix
memory leak.
---
 gcc/go/gofrontend/expressions.cc | 5 +
 1 file changed, 5 insertions(+)

diff --git a/gcc/go/gofrontend/expressions.cc b/gcc/go/gofrontend/expressions.cc
index 4ac55af7433..93f5d5dc52b 100644
--- a/gcc/go/gofrontend/expressions.cc
+++ b/gcc/go/gofrontend/expressions.cc
@@ -2728,6 +2728,7 @@ Integer_expression::do_import(Import_expression* imp, 
Location loc)
{
  go_error_at(imp->location(), "bad number in import data: %qs",
  real_str.c_str());
+ mpfr_clear (real);
  return Expression::make_error(loc);
}
}
@@ -2743,6 +2744,8 @@ Integer_expression::do_import(Import_expression* imp, 
Location loc)
{
  go_error_at(imp->location(), "bad number in import data: %qs",
  imag_str.c_str());
+ mpfr_clear (imag);
+ mpfr_clear (real);
  return Expression::make_error(loc);
}
   mpc_t cval;
@@ -2766,6 +2769,7 @@ Integer_expression::do_import(Import_expression* imp, 
Location loc)
{
  go_error_at(imp->location(), "bad number in import data: %qs",
  num.c_str());
+ mpz_clear (val);
  return Expression::make_error(loc);
}
   Expression* ret;
@@ -2783,6 +2787,7 @@ Integer_expression::do_import(Import_expression* imp, 
Location loc)
{
  go_error_at(imp->location(), "bad number in import data: %qs",
  num.c_str());
+ mpfr_clear (val);
  return Expression::make_error(loc);
}
   Expression* ret = Expression::make_float(, NULL, loc);
-- 
2.30.2



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

2023-04-02 Thread Bernhard Reutner-Fischer via Gcc-patches
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");
 }
 
diff --git a/gcc/fortran/expr.cc b/gcc/fortran/expr.cc
index 7fb33f81788..b4736804eda 100644
--- a/gcc/fortran/expr.cc
+++ b/gcc/fortran/expr.cc
@@ -1539,6 +1539,7 @@ find_array_section (gfc_expr *expr, gfc_ref *ref)
   mpz_init_set_ui (delta_mpz, one);
   mpz_init_set_ui (nelts, one);
   mpz_init (tmp_mpz);
+  mpz_init (ptr);
 
   /* Do the initialization now, so that we can cleanup without
  keeping track of where we were.  */
@@ -1682,7 +1683,6 @@ find_array_section (gfc_expr *expr, gfc_ref *ref)
   mpz_mul (delta_mpz, delta_mpz, tmp_mpz);
 }
 
-  mpz_init (ptr);
   cons = gfc_constructor_first (base);
 
   /* Now clock through the array reference, calculating the index in
@@ -1735,7 +1735,8 @@ find_array_section (gfc_expr *expr, gfc_ref *ref)
 "at %L requires an increase of the allowed %d "
 "upper limit.  See %<-fmax-array-constructor%> "
 "option", >where, flag_max_array_constructor);
- return false;
+ t = false;
+ goto cleanup;
}
 
   cons = gfc_constructor_lookup (base, limit);
@@ -1750,8 +1751,6 @@ find_array_section (gfc_expr *expr, gfc_ref *ref)
   gfc_copy_expr (cons->expr), NULL);
 }
 
-  mpz_clear (ptr);
-
 cleanup:
 
   mpz_clear (delta_mpz);
@@ -1765,6 +1764,7 @@ cleanup:
   mpz_clear (ctr[d]);
   mpz_clear (stride[d]);
 }
+  mpz_clear (ptr);
   gfc_constructor_free (base);
   return t;
 }
diff --git a/gcc/fortran/simplify.cc b/gcc/fortran/simplify.cc
index ecf0e3558df..d1f06335e79 100644
--- a/gcc/fortran/simplify.cc
+++ b/gcc/fortran/simplify.cc
@@ -6866,6 +6866,7 @@ gfc_simplify_reshape (gfc_expr *source, gfc_expr 
*shape_exp,
  gfc_error ("The SHAPE array for the RESHAPE intrinsic at %L has a "
 "negative value %d for dimension %d",
 _exp->where, shape[rank], rank+1);
+ mpz_clear (index);
  return _bad_expr;
}
 
@@ -6889,6 +6890,7 @@ gfc_simplify_reshape (gfc_expr *source, gfc_expr 
*shape_exp,
{
  gfc_error ("Shapes of ORDER at %L and SHAPE at %L are different",
 _exp->where, _exp->where);
+ mpz_clear (index);
  return _bad_expr;
}
 
@@ -6902,6 +6904,7 @@ gfc_simplify_reshape (gfc_expr *source, gfc_expr 
*shape_exp,
{
  gfc_error ("Sizes of ORDER at %L and SHAPE at %L are different",
 _exp->where, _exp->where);
+ mpz_clear (index);
  return _bad_expr;
}
 
@@ -6918,6 +6921,7 @@ gfc_simplify_reshape (gfc_expr *source, gfc_expr 
*shape_exp,
 "in the range [1, ..., %d] for the RESHAPE intrinsic "
 "near %L", order[i], _exp->where, rank,
 _exp->where);
+ mpz_clear (index);
  return _bad_expr;
}
 
@@ -6926,6 +6930,7 @@ gfc_simplify_reshape (gfc_expr *source, gfc_expr 
*shape_exp,
{
  gfc_error ("ORDER at %L is not a permutation of the size of "
 "SHAPE at %L", _exp->where, _exp->where);
+ mpz_clear (index);
  return _bad_expr;
}
  x[order[i]] = 1;
@@ -7408,7 +7413,7 @@ gfc_simplify_set_exponent (gfc_expr *x, gfc_expr *i)
   exp2 = (unsigned long) mpz_get_d (i->value.integer);
   mpfr_mul_2exp (result->value.real, frac, exp2, GFC_RND_MODE);
 
-  mpfr_clears (absv, log2, pow2, frac, NULL);
+  mpfr_clears (exp, absv, log2, pow2, frac, NULL);
 
   return range_check (result, "SET_EXPONENT");
 }
-- 
2.30.2



[PATCH 0/3] Fix mpfr and mpz memory leaks

2023-04-02 Thread Bernhard Reutner-Fischer via Gcc-patches
From: Bernhard Reutner-Fischer 

Hi!

These patches for the go, rust and fortran frontends fix the mpfr and
mpz memory leaks my coccinelle script found.

Bootstrapped and regtested without regressions on x86_64-unknown-linux,
including go,rust,fortran.

Ok for trunk for the fortran bits?

I'd hope that go and rust can apply the respective patches upstream.

Bernhard Reutner-Fischer (3):
  go: Fix memory leak in Integer_expression
  rust: Fix memory leak in compile_{integer,float}_literal
  Fortran: Fix mpz and mpfr memory leaks

 gcc/fortran/array.cc  | 3 +++
 gcc/fortran/expr.cc   | 8 
 gcc/fortran/simplify.cc   | 7 ++-
 gcc/go/gofrontend/expressions.cc  | 5 +
 gcc/rust/backend/rust-compile-expr.cc | 7 +++
 5 files changed, 25 insertions(+), 5 deletions(-)

-- 
2.30.2



Re: [PATCH v2] rtl-optimization: ppc backend generates unnecessary extension.

2023-03-30 Thread Bernhard Reutner-Fischer via Gcc-patches
On Thu, 30 Mar 2023 17:30:43 +0530
Ajit Agarwal via Gcc-patches  wrote:

> Hello All:

Just some nits.

And this seems to be an incremental diff ontop of your v2.
You might want check for coding-style errors by running:
 contrib/check_GNU_style.py /tmp/ree-v2bis.patch

> 
> This patch added enhancement to extimination elimination for rs6000 target.

I think REE means redundant extension elimination.

> gcc/ChangeLog:
> 
>   * ree.cc(is_feasible_elim_across_basic_blocks):

We often use the lispy _p suffix for predicates.
Maybe eliminate_across_bbs_p would be shorter.

>   Add checks to enable extension elimination..
>   * ree.cc(combine_reaching_defs): Add checks to enable
>   extension elimination.
> ---
>  gcc/ree.cc | 121 ++---
>  1 file changed, 116 insertions(+), 5 deletions(-)
> 
> diff --git a/gcc/ree.cc b/gcc/ree.cc
> index d05d37f9a23..7e4cce5cee4 100644
> --- a/gcc/ree.cc
> +++ b/gcc/ree.cc
> @@ -253,6 +253,56 @@ struct ext_cand
>  
>  static int max_insn_uid;
>  
> +/* Get all the reaching definitions of an instruction.  The definitions are
> +   desired for REG used in INSN.  Return the definition list or NULL if a
> +   definition is missing.  If DEST is non-NULL, additionally push the INSN
> +   of the definitions onto DEST.  */
> +
> +static struct df_link *
> +get_defs (rtx_insn *insn, rtx reg, vec *dest)
> +{
> +  df_ref use;
> +  struct df_link *ref_chain, *ref_link;
> +
> +  FOR_EACH_INSN_USE (use, insn)
> +{
> +  if (GET_CODE (DF_REF_REG (use)) == SUBREG)
> + return NULL;
> +  if (REGNO (DF_REF_REG (use)) == REGNO (reg))
> + break;
> +}
> +
> +  if (use == NULL) return NULL;

Missing newline before return.

> +
> +  gcc_assert (use != NULL);

Either the assert or the if but both is a bit much.

> +
> +  ref_chain = DF_REF_CHAIN (use);
> +
> +  for (ref_link = ref_chain; ref_link; ref_link = ref_link->next)
> +{
> +  /* Problem getting some definition for this instruction.  */
> +  if (ref_link->ref == NULL)
> + return NULL;
> +  if (DF_REF_INSN_INFO (ref_link->ref) == NULL)
> + return NULL;
> +  /* As global regs are assumed to be defined at each function call
> +  dataflow can report a call_insn as being a definition of REG.
> +  But we can't do anything with that in this pass so proceed only
> +  if the instruction really sets REG in a way that can be deduced
> +  from the RTL structure.  */
> +  if (global_regs[REGNO (reg)]
> +   && !set_of (reg, DF_REF_INSN (ref_link->ref)))
> + return NULL;
> +}
> +
> +  if (dest)
> +for (ref_link = ref_chain; ref_link; ref_link = ref_link->next)
> +  dest->safe_push (DF_REF_INSN (ref_link->ref));
> +
> +  return ref_chain;
> +}
> +
> +
>  /* Identify instruction AND with identical zero extension.  */
>  
>  static unsigned int
> @@ -393,6 +443,7 @@ combine_set_extension (ext_cand *cand, rtx_insn 
> *curr_insn, rtx *orig_set)
>machine_mode orig_mode = GET_MODE (SET_DEST (*orig_set));
>rtx new_set = NULL_RTX;
>rtx cand_pat = single_set (cand->insn);
> +

superfluous whitespace change.

>if (insn_is_zext_p(cand->insn)
> && CONST_INT_P (orig_src) && INTVAL (orig_src) != 0)
>  return false;
> @@ -401,6 +452,7 @@ combine_set_extension (ext_cand *cand, rtx_insn 
> *curr_insn, rtx *orig_set)
>   then we need to change the original load to reference the destination
>   of the extension.  Then we need to emit a copy from that destination
>   to the original destination of the load.  */
> + // print_rtl_single(stdout, cand_pat);

Please remove that debug comment.

>rtx new_reg;
>bool copy_needed
>  = (REGNO (SET_DEST (cand_pat)) != REGNO (XEXP (SET_SRC (cand_pat), 0)));
> @@ -547,6 +599,7 @@ transform_ifelse (ext_cand *cand, rtx_insn *def_insn)
>return false;
>  }
>  
> +#if 0
>  /* Get all the reaching definitions of an instruction.  The definitions are
> desired for REG used in INSN.  Return the definition list or NULL if a
> definition is missing.  If DEST is non-NULL, additionally push the INSN
> @@ -593,7 +646,7 @@ get_defs (rtx_insn *insn, rtx reg, vec *dest)
>  
>return ref_chain;
>  }
> -
> +#endif

Why did you move get_defs?

>  /* Get all the reaching uses of an instruction.  The uses are desired for REG
> set in INSN.  Return use list or NULL if a use is missing or irregular.  
> */
>  
> @@ -848,6 +901,36 @@ is_feasible_elim_across_basic_blocks (ext_cand *cand,
>   && REGNO (XEXP (PATTERN (BB_END (bb)), 0)) != REGNO (SET_DEST 
> (cand->expr)))
>   return false;
>  
> +   if (cand->code == ZERO_EXTEND
> + && GET_CODE ((PATTERN (def_insn))) == PARALLEL)
> + return false;

Excess braces above.

> +
> +   if (cand->code == ZERO_EXTEND
> + && GET_CODE ((PATTERN (def_insn))) == SET

Excess braces above.

> + && GET_CODE (SET_SRC (PATTERN (def_insn))) != XOR)
> + return false;
> +
> +   if (cand->code 

Re: [PATCH] tree-optimization/109237 - last_stmt is possibly slow

2023-03-22 Thread Bernhard Reutner-Fischer via Gcc-patches
On 22 March 2023 13:29:52 CET, Richard Biener via Gcc-patches 
 wrote:

>The alternative would be to change last_stmt, explicitely introducing
>last_nondebug_stmt.  I remember we chickened out and made last_stmt
>conservative here but not anticipating the compile-time issues this
>creates.  I count 227 last_stmt and 12 last_and_only_stmt uses.

In https://inbox.sourceware.org/gcc-help/20211121010713.1452267f@nbbrfq/ i 
asked if maybe
---8<---
1) last_stmt
wouldn't it be more efficient if tree-cfg.c:: last_stmt() would
gimple_seq_last_nondebug_stmt (bb_seq (bb)) ? That would set stmt=NULL
only after the loop it seems..



Re: [PATCH] docs: Fix double 'See' in zero-length-bounds docs.

2023-03-12 Thread Bernhard Reutner-Fischer via Gcc-patches
On 12 March 2023 03:47:08 CET, Sean Bright via Gcc-patches 
 wrote:
>On 3/11/2023 6:39 PM, Bernhard Reutner-Fischer wrote:
>> On 11 March 2023 18:33:46 CET, Sean Bright via Gcc-patches 
>>  wrote:
>>> Hi,
>>>
>>> This fixes a minor issue where the zero-length-bound docs read "See See
>>> Zero Length."
>>>
>>> gcc/ChangeLog:
>>>     * doc/invoke.texi (Warning Options): Remove errant 'See'
>>>     before @xref.
>>> ---
>>>  gcc/doc/invoke.texi | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
>>> index 3a6a97862b0..174d160dd6c 100644
>>> --- a/gcc/doc/invoke.texi
>>> +++ b/gcc/doc/invoke.texi
>>> @@ -8345,7 +8345,7 @@ conversions the warnings 
>>> @option{-Wno-int-to-pointer-cast} and
>>>  @item -Wzero-length-bounds
>>>  Warn about accesses to elements of zero-length array members that might
>>>  overlap other members of the same object.  Declaring interior zero-length
>>> -arrays is discouraged because accesses to them are undefined.  See
>>> +arrays is discouraged because accesses to them are undefined.
>>>  @xref{Zero Length}.
>>
>> I'm not a native speaker, but wouldn't it be better to talk about singular 
>> access, i.e. s/accesses/access/ in both cases?
>>
>> thanks,
>
>As a native speaker it does not feel ergonomic to use 'accesses' in this
>context but it also does not feel objectively wrong. I'm happy to
>provide a follow-up patch if you feel strongly about it.

I'd prefer the singular but defer to the documentation maintainers.

thanks,


Re: [PATCH] docs: Fix double 'See' in zero-length-bounds docs.

2023-03-11 Thread Bernhard Reutner-Fischer via Gcc-patches
On 11 March 2023 18:33:46 CET, Sean Bright via Gcc-patches 
 wrote:
>Hi,
>
>This fixes a minor issue where the zero-length-bound docs read "See See
>Zero Length."
>
>gcc/ChangeLog:
>    * doc/invoke.texi (Warning Options): Remove errant 'See'
>    before @xref.
>---
> gcc/doc/invoke.texi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
>index 3a6a97862b0..174d160dd6c 100644
>--- a/gcc/doc/invoke.texi
>+++ b/gcc/doc/invoke.texi
>@@ -8345,7 +8345,7 @@ conversions the warnings 
>@option{-Wno-int-to-pointer-cast} and
> @item -Wzero-length-bounds
> Warn about accesses to elements of zero-length array members that might
> overlap other members of the same object.  Declaring interior zero-length
>-arrays is discouraged because accesses to them are undefined.  See
>+arrays is discouraged because accesses to them are undefined.
> @xref{Zero Length}.


I'm not a native speaker, but wouldn't it be better to talk about singular 
access, i.e. s/accesses/access/ in both cases?

thanks,


Re: [PATCH] RISC-V: Add fault first load C/C++ support

2023-03-08 Thread Bernhard Reutner-Fischer via Gcc-patches
On 7 March 2023 07:21:23 CET, juzhe.zh...@rivai.ai wrote:
>From: Ju-Zhe Zhong 
>

>+class vleff : public function_base
>+{
>+public:
>+  unsigned int call_properties (const function_instance &) const override
>+  {
>+return CP_READ_MEMORY | CP_WRITE_CSR;
>+  }
>+
>+  gimple *fold (gimple_folder ) const override
>+  {
>+/* fold vleff (const *base, size_t *new_vl, size_t vl)
>+
>+   > vleff (const *base, size_t vl)
>+   new_vl = MEM_REF[read_vl ()].  */
>+
>+auto_vec vargs;

Where is that magic 8 coming from?

Wouldn't you rather have one temporary to hold this manually CSEd

nargs = gimple_call_num_args (f.call) - 2;

which you would use throughout this function as it does not seem to change?

Would you reserve something based off nargs for the auto_vec above?
If not, please add a comment where the 8 comes from?

thanks,

>+
>+for (unsigned i = 0; i < gimple_call_num_args (f.call); i++)
>+  {
>+  /* Exclude size_t *new_vl argument.  */
>+  if (i == gimple_call_num_args (f.call) - 2)
>+continue;
>+
>+  vargs.quick_push (gimple_call_arg (f.call, i));
>+  }
>+
>+gimple *repl = gimple_build_call_vec (gimple_call_fn (f.call), vargs);
>+gimple_call_set_lhs (repl, f.lhs);
>+
>+/* Handle size_t *new_vl by read_vl.  */
>+tree new_vl = gimple_call_arg (f.call, gimple_call_num_args (f.call) - 2);
>+if (integer_zerop (new_vl))
>+  {
>+  /* This case happens when user passes the nullptr to new_vl argument.
>+ In this case, we just need to ignore the new_vl argument and return
>+ vleff instruction directly. */
>+  return repl;
>+  }
>+
>+tree tmp_var = create_tmp_var (size_type_node, "new_vl");
>+tree decl = get_read_vl_decl ();
>+gimple *g = gimple_build_call (decl, 0);
>+gimple_call_set_lhs (g, tmp_var);
>+tree indirect
>+  = fold_build2 (MEM_REF, size_type_node,
>+   gimple_call_arg (f.call,
>+gimple_call_num_args (f.call) - 2),
>+   build_int_cst (build_pointer_type (size_type_node), 0));
>+gassign *assign = gimple_build_assign (indirect, tmp_var);
>+
>+gsi_insert_after (f.gsi, assign, GSI_SAME_STMT);
>+gsi_insert_after (f.gsi, g, GSI_SAME_STMT);
>+return repl;
>+  }
>+



Re: [PATCH] [RFC] RAII auto_mpfr and autp_mpz

2023-03-07 Thread Bernhard Reutner-Fischer via Gcc-patches
On Mon, 6 Mar 2023 11:29:30 + (UTC)
Richard Biener via Gcc-patches  wrote:

> On Mon, 6 Mar 2023, Jakub Jelinek wrote:
> 
> > On Mon, Mar 06, 2023 at 11:01:18AM +, Richard Biener wrote:  
> > > +  auto_mpfr =(const auto_mpfr &) = delete;
> > > +  auto_mpz =(const auto_mpz &) = delete;  
> > 
> > Just formatting nit, space before (.
> > 
> > Looks like nice improvement and thanks Jonathan for the suggestions ;)  
> 
> Good, I've queued it for stage1 unless fortran folks want to pick it
> up earlier for the purpose of fixing leaks.

You did not Cc the fortran list though, not sure if Tobias is aware of
this possibility.

While it's a nice idea, there have been resentments towards (visible)
C++ in the fortran frontend and especially the library, i think.
I do not know if this has changed in the meantime.

PS: not sure about libgfortran/intrinsics/trigd.inc
FTYPE s
in #ifdef SIND_SMALL_LITERAL
when this is true:
if (mpfr_cmp_ld (ax, SIND_SMALL_LITERAL) < 0)
ISTM we leak s in the return x;

This seems to happen both in SIND and TAND, from the looks.

PPS: without handling (mpfr|mpz)_clears proper, hence missing quite
some potential spots, i guess one could potentially discuss at least
$ git diff | diffstat -ulp1
gcc/builtins.cc
gcc/fold-const-call.cc
gcc/fortran/arith.cc
gcc/fortran/array.cc
gcc/fortran/check.cc
gcc/fortran/data.cc
gcc/fortran/dependency.cc
gcc/fortran/expr.cc
gcc/fortran/resolve.cc
gcc/fortran/simplify.cc
gcc/fortran/target-memory.cc
gcc/fortran/trans-array.cc
gcc/fortran/trans-intrinsic.cc
gcc/real.cc
gcc/rust/backend/rust-compile-expr.cc
gcc/tree-ssa-loop-niter.cc
gcc/ubsan.cc

See the spots highlighted in the attached patch, which i did not try to
compile. I did not filter out the files you patched already, nor
externally maintained files like rust (which seems to leak fval and
ival not only on errors, from a quick look).

That was from
find ./ \( -name "*.c[cp]" -o -name "*.[ch]" -o -name "*.inc" \) -a \( ! -path 
"./gcc/testsuite/*" -a ! -path "./gcc/contrib/*" \) -exec spatch --sp-file 
~/coccinelle/auto_mpfrz.2.cocci --in-place {} \;

thanks,
// mpz and mpfr -> auto_\1
// Remember to s/= [[:space:]]*XXXZXXX//g
// to get rid of the disguise-in-c hack
// TODO: properly handle (mpfr|mpz)_clears
@ mpfr_1 @
typedef mpfr_t;
identifier i;
@@
- mpfr_t i;
+ auto_mpfr i;
...
- mpfr_init (i);
...
(
- mpfr_clear (i);
|
mpfr_clears (
 ...,
- i,
 ...
 );
)

@ mpfr_2 @
typedef mpfr_t;
identifier i;
expression prec;
@@
- mpfr_t i;
+ auto_mpfr i = XXXZXXX(prec);
...
- mpfr_init2 (i, prec);
...
(
- mpfr_clear (i);
|
mpfr_clears (
 ...,
- i,
 ...
 );
)

@ mpfr_3 @
@@
- mpfr_clears(NULL);

/// mpz ///

@ mpz_1 @
typedef mpz_t;
identifier i;
@@
- mpz_t i;
+ auto_mpz i;
...
- mpz_init (i);
...
(
- mpz_clear (i);
|
mpz_clears (
 ...,
- i,
 ...
 );
)

@ mpz_2 @
typedef mpz_t;
identifier i;
expression prec;
@@
- mpz_t i;
+ auto_mpz i = XXXZXXX(prec);
...
- mpz_init2 (i, prec);
...
(
- mpz_clear (i);
|
mpz_clears (
 ...,
- i,
 ...
 );
)

@ mpz_3 @
@@
- mpz_clears(NULL);

diff --git a/gcc/builtins.cc b/gcc/builtins.cc
index 4d467c8c5c1..9be0949aa1d 100644
--- a/gcc/builtins.cc
+++ b/gcc/builtins.cc
@@ -11064,15 +11064,13 @@ do_mpfr_lgamma_r (tree arg, tree arg_sg, tree type)
  const int prec = fmt->p;
  const mpfr_rnd_t rnd = fmt->round_towards_zero? MPFR_RNDZ : MPFR_RNDN;
  int inexact, sg;
- mpfr_t m;
+ auto_mpfr m (prec);
  tree result_lg;
 
- mpfr_init2 (m, prec);
  mpfr_from_real (m, ra, MPFR_RNDN);
  mpfr_clear_flags ();
  inexact = mpfr_lgamma (m, , m, rnd);
  result_lg = do_mpfr_ckconv (m, type, inexact);
- mpfr_clear (m);
  if (result_lg)
{
  tree result_sg;
diff --git a/gcc/fold-const-call.cc b/gcc/fold-const-call.cc
index 43819c1f984..900c4069ddb 100644
--- a/gcc/fold-const-call.cc
+++ b/gcc/fold-const-call.cc
@@ -130,14 +130,13 @@ do_mpfr_arg1 (real_value *result,
 
   int prec = format->p;
   mpfr_rnd_t rnd = format->round_towards_zero ? MPFR_RNDZ : MPFR_RNDN;
-  mpfr_t m;
+  auto_mpfr m (prec);
 
-  mpfr_init2 (m, prec);
+  
   mpfr_from_real (m, arg, MPFR_RNDN);
   mpfr_clear_flags ();
   bool inexact = func (m, m, rnd);
   bool ok = do_mpfr_ckconv (result, m, inexact, format);
-  mpfr_clear (m);
 
   return ok;
 }
@@ -224,14 +223,13 @@ do_mpfr_arg2 (real_value *result,
 
   int prec = format->p;
   mpfr_rnd_t rnd = format->round_towards_zero ? MPFR_RNDZ : MPFR_RNDN;
-  mpfr_t m;
+  auto_mpfr m (prec);
 
-  mpfr_init2 (m, prec);
+  
   mpfr_from_real (m, arg1, MPFR_RNDN);
   mpfr_clear_flags ();
   bool inexact = func (m, arg0.to_shwi (), m, rnd);
   bool ok = do_mpfr_ckconv (result, m, inexact, format);
-  mpfr_clear (m);
 
   return ok;
 }
diff --git a/gcc/fortran/arith.cc b/gcc/fortran/arith.cc
index d0d1c0b03d2..5b14a833d9a 100644
--- a/gcc/fortran/arith.cc
+++ b/gcc/fortran/arith.cc
@@ -329,13 +329,12 @@ static 

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

2023-03-03 Thread Bernhard Reutner-Fischer via Gcc-patches
On 2 March 2023 02:23:10 CET, Jerry D  wrote:
>On 3/1/23 4:07 PM, Steve Kargl via Fortran 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.
>> 
>
>The only question I have: Is free posix compliant on all platforms?
>
>For example ming64 or mac?  It seems sometimes we run into things like this 
>once in a while.

I think we have the -liberty to cater even for non compliant systems either 
way, if you please excuse the pun. That's not an excuse on POSIX systems, imho.

>
>Otherwise I have no issue at all.  It is a lot cleaner.
>
>Jerry



  1   2   3   4   >