Re: [PATCH] fortran, libgfortran, v3: Avoid using libquadmath for glibc 2.26+

2022-06-28 Thread Jakub Jelinek via Gcc-patches
On Mon, Jun 27, 2022 at 03:30:49PM +0200, Jakub Jelinek via Gcc-patches wrote:
> Ok, here is an updated patch that uses _Float128/_Complex _Float128 for all
> of GFC_REAL_{16,17}_IS_FLOAT128, but still uses q/Q suffixes on literal
> constants etc. when using libquadmath and f128/F128 otherwise.
> This patch also includes the incremental powerpc64le fixes.
> 
> Ok if it passes testing?

Bootstrapped/regtested successfully on x86_64-linux and i686-linux with
glibc 2.35 (libquadmath not used), powerpc64le-linux with glibc 2.17
(libquadmath used for -mabi=ieeelongdouble support), powerpc64le-linux
with 2.28 (libquadmath not used), powerpc64-linux with glibc 2.17
(libquadmath not used, real(kind=16) only long double IBM double double).

Jakub



Re: [PATCH] jit: avoid calloc() poisoning on musl [PR106102]

2022-06-28 Thread Richard Biener via Gcc-patches
On Mon, 27 Jun 2022, Sergei Trofimovich wrote:

> From: Sergei Trofimovich 
> 
> On musl  uses calloc() (via ). jit/ includes
> it directly and exposes use of poisoned calloc():
> 
> /build/build/./prev-gcc/xg++ ... 
> ../../gcc-13-20220626/gcc/jit/jit-playback.cc
> make[3]: *** [Makefile:1143: jit/libgccjit.o] Error 1
> make[3]: *** Waiting for unfinished jobs
> In file included from /<>/musl-1.2.3-dev/include/pthread.h:30,
>  from ../../gcc-13-20220626/gcc/jit/jit-playback.cc:44:
> /<>/musl-1.2.3-dev/include/sched.h:84:7: error: attempt to use 
> poisoned "calloc"
>84 | void *calloc(size_t, size_t);
>   |   ^
> /<>/musl-1.2.3-dev/include/sched.h:124:36: error: attempt to use 
> poisoned "calloc"
>   124 | #define CPU_ALLOC(n) ((cpu_set_t *)calloc(1,CPU_ALLOC_SIZE(n)))
>   |^
> 
> The change moves sys-specific header before "system.h" inclusion
> to evade poisoning.
> 
> gcc/jit/
> 
>   PR c++/106102
>   * jit-playback.cc: Include  before "system.h" to avoid 
> calloc()
>   poisoning.
>   * jit-recording.cc: Ditto.
>   * libgccjit.cc: Ditto.
> ---
>  gcc/jit/jit-playback.cc  | 5 +++--
>  gcc/jit/jit-recording.cc | 4 +++-
>  gcc/jit/libgccjit.cc | 4 +++-
>  3 files changed, 9 insertions(+), 4 deletions(-)
> 
> diff --git a/gcc/jit/jit-playback.cc b/gcc/jit/jit-playback.cc
> index 6be6bdf8dea..4ab7b59cab9 100644
> --- a/gcc/jit/jit-playback.cc
> +++ b/gcc/jit/jit-playback.cc
> @@ -19,6 +19,9 @@ along with GCC; see the file COPYING3.  If not see
>  .  */
>  
>  #include "config.h"
> +/*  has to go before "system.h" as it pull in to-be-poisoned
> +   symbols on musl like calloc().  */
> +#include 

there are probably targets where there need to be some #includes before
including pthread.h which means it would be best to include pthread.h
from within system.h (conditional, of course, just add a
INCLUDE_PTHREAD_H preprocessor guard).

Richard.

>  #include "system.h"
>  #include "coretypes.h"
>  #include "target.h"
> @@ -41,8 +44,6 @@ along with GCC; see the file COPYING3.  If not see
>  #include "diagnostic.h"
>  #include "stmt.h"
>  
> -#include 
> -
>  #include "jit-playback.h"
>  #include "jit-result.h"
>  #include "jit-builtins.h"
> diff --git a/gcc/jit/jit-recording.cc b/gcc/jit/jit-recording.cc
> index 697dee66e73..9505ed3b279 100644
> --- a/gcc/jit/jit-recording.cc
> +++ b/gcc/jit/jit-recording.cc
> @@ -19,13 +19,15 @@ along with GCC; see the file COPYING3.  If not see
>  .  */
>  
>  #include "config.h"
> +/*  has to go before "system.h" as it pull in to-be-poisoned
> +   symbols on musl like calloc().  */
> +#include 
>  #include "system.h"
>  #include "coretypes.h"
>  #include "tm.h"
>  #include "pretty-print.h"
>  #include "toplev.h"
>  
> -#include 
>  
>  #include "jit-builtins.h"
>  #include "jit-recording.h"
> diff --git a/gcc/jit/libgccjit.cc b/gcc/jit/libgccjit.cc
> index 0e76097b4ba..6a0ac8aaba2 100644
> --- a/gcc/jit/libgccjit.cc
> +++ b/gcc/jit/libgccjit.cc
> @@ -19,12 +19,14 @@ along with GCC; see the file COPYING3.  If not see
>  .  */
>  
>  #include "config.h"
> +/*  has to go before "system.h" as it pull in to-be-poisoned
> +   symbols on musl like calloc().  */
> +#include 
>  #include "system.h"
>  #include "coretypes.h"
>  #include "timevar.h"
>  #include "typed-splay-tree.h"
>  #include "cppbuiltin.h"
> -#include 
>  
>  #include "libgccjit.h"
>  #include "jit-recording.h"
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH, Frankenstra


Re: [Ada] Remove useless pragma Warnings Off from runtime units

2022-06-28 Thread Arnaud Charlet via Gcc-patches
> IIRC, this latter requirement is particularly important for canadian
> crosses, but it applies as a general recommendation, and GNAT often
> takes advantage of that to use features that will be disregarded by
> stage1 (no optimization, no fatal warnings, limited runtime, etc), but
> that must be available in later stages and in cross builds, which is
> easy to satisfy by using the same compiler version, and which is a given
> when bootstrapping.
> 
> Of course it isn't always the case that you will run into problems when
> deviating from these recommendations, so it's perfectly possible that
> you get lucky building it all using compilers that don't meet the
> recommendations to get started, but that's counting on luck, not on a
> reliable procedure.
> 
> See note Prerequisites in the GCC Installation manual for more details.

Right, see https://gcc.gnu.org/install/prerequisites.html (GNAT section).
The only combination that is guaranteed to work is to use the same
version for the native compiler to build the cross.

The error reported here is one example showing why using another version
will not work in general.

Arno


Re: [PATCH] testsuite/ix86: prune MMX ABI warning

2022-06-28 Thread Uros Bizjak via Gcc-patches
On Tue, Jun 28, 2022 at 8:48 AM Jan Beulich  wrote:
>
> So far on 32-bit hosts this test failed (for both C and C++) because of
> the ABI change warning occurring without (explictly) enabling MMX.
>
> gcc/testsuite/
>
> * c-c++-common/torture/builtin-shufflevector-2.c: Prune ix86 MMX
> ABI warning.

OK, but please add a comment that this applies to some x86 configurations.

Thanks,
Uros.


> --- a/gcc/testsuite/c-c++-common/torture/builtin-shufflevector-2.c
> +++ b/gcc/testsuite/c-c++-common/torture/builtin-shufflevector-2.c
> @@ -24,3 +24,5 @@ main (void)
>__builtin_abort ();
>return 0;
>  }
> +
> +// { dg-prune-output "MMX vector (argument|return) without MMX enabled 
> changes the ABI" }


Re: [GCC 13][PATCH] PR101836: Add a new option -fstrict-flex-array[=n] and use it in __builtin_object_size

2022-06-28 Thread Richard Biener via Gcc-patches
On Mon, Jun 27, 2022 at 4:20 PM Qing Zhao via Gcc-patches
 wrote:
>
> Hi,
>
> Per our discussion in the bug report, I came up with the following patch:
>
> ===
>
> PR101836: Add a new option -fstrict-flex-array[=n]
>
> Add the new option and use it in __builtin_object_size.
>
> Treat the trailing array of a structure as a flexible array member in a
> stricter way.  The value of 'n' controls the level of strictness.
> 'n'=0 is the least strict, all trailing arrays of structures are treated
> as flexible array members; This is the default behavior of GCC without specify
> this option.
> 'n'=3 is the strictest, only when the trailing array is declared as a
> flexible array member per C99 standard onwards ([]), it is treated as a
> flexible array member;
> There are two more levels in between 0 and 3, which are provided to support
> older codes that use GCC zero-length array extension ([0]), or one-size array 
> as
> flexible array member ([1]):
> When 'n' is 1, the trailing array is treated as a flexible array member
> when it is declared as either [], [0], or [1];
> When 'n' is 2, the trailing array is treated as a flexible array member
> when it is declared as either [], or [0].
>
> There are other places in GCC that conservatively treat flexible array 
> members.
> A follow-up patch will make -ftrict-flex-array option to control all these
> places consistently.
>
> Bootstrapped and regression tested on both X86 and aarch64, no issues.
>
> Any comment and suggestion?

Since this aims at the C or C++ frontends but the middle-end eventually consumes
this it would be much nicer to encode this in the types themselves.
Since the least
strict reading is the default right now it would be a flag (on the
FIELD_DECL I suppose)
like DECL_NOT_FLEXARRAY or DECL_FIXED_SIZE?  Alternatively the flag could
also be on the record type enclosing the trailing array member (but
type sharing might
make this more difficult in the end).

There's also array_at_struct_end_p which is supposed to be the main
query interface
for this (but it seems people sneaked in more variants with eventually
different semantics ... :/)

Richard.



> Okay for commit to Gcc13?
>
> thanks.
>
> Qing
>
> ===
>
> gcc/
>
>PR tree-optimization/101836
>* common.opt (fstrict-flex-array, fstrict-flex-array=): New options.
>* doc/invoke.texi (-fstrict-flex-array, -fstrict-flex-array=): 
> Document.
>* tree-object-size.cc (addr_object_size): Call is_flexible_array_p to
>check whether an array is a flexible array.
>* tree.cc (special_array_member_type): New routine.
>(is_flexible_array_p): New routine.
>(component_ref_size): Call special_array_member_type to decide the
>type of special array member.
>* tree.h (enum struct special_array_member): Add is_vla, trail_flex.
>(special_array_member_type): New prototype.
>(is_flexible_array_p): New prototype.
>
> gcc/testsuite/
>
>PR tree-optimization/101836
>* gcc.dg/pr101836.c: New test.
>* gcc.dg/pr101836_1.c: New test.
>* gcc.dg/pr101836_2.c: New test.
>* gcc.dg/pr101836_3.c: New test.
>* gcc.dg/pr101836_4.c: New test.
>* gcc.dg/pr101836_5.c: New test.
>
>
> The complete patch is:
>


Re: [PATCH v2] testsuite: Add new target check for no_alignment_constraints

2022-06-28 Thread Richard Biener via Gcc-patches
On Mon, Jun 27, 2022 at 8:09 PM Dimitar Dimitrov  wrote:
>
> A few testcases were marked for avr target, which has no alignment
> requirements.  But those tests in fact should filter for any
> target having __BIGGEST_ALIGNMENT__=1.
>
> A new effective target check is introduced: no_alignment_constraints.
> It checks whether __BIGGEST_ALIGNMENT__ is declared as 1.
>
> This change fixes the testsuite cases for PRU target.  I don't have
> environment to test mm32c and cris targets, which also declare
> __BIGGEST_ALIGNMENT__=1.
>
> It was regression-tested on x86_64-pc-linux-gnu.
>
> The following two existing macros were considered, but they check for
> subtly different target behaviour:
>  1. non_strict_align
> If true, non-aligned access is permitted. But it also allows
> variables to be naturally aligned, which is not true for
> no_alignment_constraints.
>
>  2. default_packed
> Whether structures are packed by default is not necessarily
> the same as lacking constraints for non-aggregate types.
> For example, BIGGEST_FIELD_ALIGNMENT or ADJUST_FIELD_ALIGN
> could be defined for a target as something other than
> BIGGEST_ALIGNMENT.

OK.

Thanks,
Richard.

> gcc/ChangeLog:
>
> * doc/sourcebuild.texi: Document new no_alignment_constraints
> effective target check.
>
> gcc/testsuite/ChangeLog:
>
> * c-c++-common/Wcast-align.c: Silence warnings for targets with
> no_alignment_constraints.
> * gcc.dg/c11-align-4.c: Skip for no_alignment_constraints.
> * gcc.dg/strlenopt-10.c: Replace checks for avr with checks for
> any target with no_alignment_constraints.
> * gcc.dg/strlenopt-11.c: Ditto.
> * gcc.dg/strlenopt-13.c: Ditto.
> * lib/target-supports.exp
> (check_effective_target_no_alignment_constraints): New.
>
>
> Signed-off-by: Dimitar Dimitrov 
> ---
> Changes since patch V1:
>   - Documented the new check in gcc/doc/sourcebuild.texi.
>
>  gcc/doc/sourcebuild.texi |  9 +
>  gcc/testsuite/c-c++-common/Wcast-align.c |  4 ++--
>  gcc/testsuite/gcc.dg/c11-align-4.c   |  2 +-
>  gcc/testsuite/gcc.dg/strlenopt-10.c  |  6 +++---
>  gcc/testsuite/gcc.dg/strlenopt-11.c  | 14 +++---
>  gcc/testsuite/gcc.dg/strlenopt-13.c  | 16 
>  gcc/testsuite/lib/target-supports.exp| 13 +
>  7 files changed, 43 insertions(+), 21 deletions(-)
>
> diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
> index 3696a58fbf2..760ff9559a6 100644
> --- a/gcc/doc/sourcebuild.texi
> +++ b/gcc/doc/sourcebuild.texi
> @@ -2716,6 +2716,7 @@ Target supports @option{-branch-cost=N}.
>  Target uses @code{__cxa_atexit}.
>
>  @item default_packed
> +@anchor{default_packed}
>  Target has packed layout of structure members by default.
>
>  @item exceptions
> @@ -2786,6 +2787,14 @@ Target uses natural alignment (aligned to type size) 
> for types of
>  Target uses natural alignment (aligned to type size) for types of
>  64 bits or less.
>
> +@item no_alignment_constraints
> +Target defines __BIGGEST_ALIGNMENT__=1.  Hence target imposes
> +no alignment constraints.  This is similar, but not necessarily
> +the same as @ref{default_packed}.  Although @code{BIGGEST_FIELD_ALIGNMENT}
> +defaults to @code{BIGGEST_ALIGNMENT} for most targets, it is possible
> +for a target to set those two with different values and have different
> +alignment constraints for aggregate and non-aggregate types.
> +
>  @item noinit
>  Target supports the @code{noinit} variable attribute.
>
> diff --git a/gcc/testsuite/c-c++-common/Wcast-align.c 
> b/gcc/testsuite/c-c++-common/Wcast-align.c
> index c296c7fd249..1087b10fd99 100644
> --- a/gcc/testsuite/c-c++-common/Wcast-align.c
> +++ b/gcc/testsuite/c-c++-common/Wcast-align.c
> @@ -16,8 +16,8 @@ struct t { double x; } *q;
>  void
>  foo (void)
>  {
> -  y = (c *) x;  /* { dg-warning "7:cast \[^\n\r]* required alignment of 
> target type" } */
> -  z = (d *) x;  /* { dg-warning "7:cast \[^\n\r]* required alignment of 
> target type" } */
> +  y = (c *) x;  /* { dg-warning "7:cast \[^\n\r]* required alignment of 
> target type" "" { target { ! no_alignment_constraints } } } */
> +  z = (d *) x;  /* { dg-warning "7:cast \[^\n\r]* required alignment of 
> target type" "" { target { ! no_alignment_constraints } } } */
>(long long *) p;  /* { dg-bogus "alignment" } */
>(double *) q; /* { dg-bogus "alignment" } */
>  }
> diff --git a/gcc/testsuite/gcc.dg/c11-align-4.c 
> b/gcc/testsuite/gcc.dg/c11-align-4.c
> index 57f93ff05fc..eb9071b9149 100644
> --- a/gcc/testsuite/gcc.dg/c11-align-4.c
> +++ b/gcc/testsuite/gcc.dg/c11-align-4.c
> @@ -2,7 +2,7 @@
> are at least some alignment constraints).  */
>  /* { dg-do compile } */
>  /* { dg-options "-std=c11 -pedantic-errors" } */
> -/* { dg-skip-if "no alignment constraints" { "avr-*-*" } } */
> +/* { dg-skip-if "no alignment constraints" { no_alignment_constraints } } */
>
> 

Re: [COMMITTED] Implement vrange::supports_type_p.

2022-06-28 Thread Richard Biener via Gcc-patches
On Mon, Jun 27, 2022 at 9:00 PM Aldy Hernandez  wrote:
>
> The conversion for loop-ch is trivial, since the range of a
> GIMPLE_COND is always an integer.

Yes - but doesn't this hint at the fact that the irange::supports_p is
useless because it checks on the type of the comparison operand
rather than the type of the comparison (boolean_type_node)?

So .. instead of replacing it, remove it?

Richard.

> OK for trunk?
>
> p.s. The loop unswitch code requires a bit more thought, since there
> are numerous range temporaries in the code that are not necessarily
> integers.
>
> On Mon, Jun 13, 2022 at 11:44 AM Richard Biener
>  wrote:
> >
> > On Fri, Jun 3, 2022 at 9:31 AM Aldy Hernandez  wrote:
> > >
> > > [I have conservatively assumed that both the loop-ch and loop-unswitch
> > > passes, which also use the ranger, only support integers and pointers.
> > > If the goal is to handle other types as well, irange::supports_p()
> > > should be Value_Range::supports_type_p(), and any uses of
> > > int_range_max should be converted to Value_Range.  I can help in the
> > > conversion if you'd like.]
> >
> > Both should also support float ranges, so yes - if you can send simple
> > patches I'll review them.
> >
> > > As discussed, this patch disambiguates the use of supports_type_p
> > > throughout, as what ranger supports is a totally different question
> > > than what a given range variant (irange, frange, etc) supports.
> > >
> > > Unfortunately we need both a static method and a virtual method, and
> > > they can't be named the same.  The uses are documented in the vrange
> > > class:
> > >
> > > +// To query what types ranger and the entire ecosystem can support,
> > > +// use Value_Range::supports_type_p(tree type).  This is a static
> > > +// method available independently of any vrange object.
> > > +//
> > > +// To query what a given vrange variant can support, use:
> > > +//irange::supports_p ()
> > > +//frange::supports_p ()
> > > +//etc
> > > +//
> > > +// To query what a range object can support, use:
> > > +//void foo (vrange &v, irange &i, frange &f)
> > > +//{
> > > +// if (v.supports_type_p (type)) ...
> > > +// if (i.supports_type_p (type)) ...
> > > +// if (f.supports_type_p (type)) ...
> > > +//}
> > >
> > > The value_range_equiv::supports_p() method can be use to determine
> > > what legacy VRP supports, as irange::supports_p() will no longer be
> > > applicable in the evrp analyzer code base once irange and prange are
> > > split.
> > >
> > > Tested on x86-64 Linux.
> > >
> > > gcc/ChangeLog:
> > >
> > > * gimple-range-edge.cc (gimple_outgoing_range_stmt_p): Adjust for
> > > an object level supports_type_p for irange and a static
> > > Value_Range::supports_type_p.
> > > * gimple-range-fold.cc (fold_using_range::range_of_range_op): 
> > > Same.
> > > (fold_using_range::range_of_address): Same.
> > > (fold_using_range::range_of_builtin_call): Same.
> > > * gimple-range-fold.h (gimple_range_type): Same.
> > > (gimple_range_ssa_p): Same.
> > > * gimple-range-path.cc (path_range_query::internal_range_of_expr):
> > > Same.
> > > (path_range_query::range_of_stmt): Same.
> > > (path_range_query::add_to_imports): Same.
> > > * gimple-range.cc (gimple_ranger::range_on_edge): Same.
> > > (gimple_ranger::export_global_ranges): Same.
> > > * gimple-ssa-evrp-analyze.cc
> > > (evrp_range_analyzer::record_ranges_from_phis):  Same.
> > > * range-op.cc (range_operator::wi_fold): Same.
> > > (range_operator::fold_range): Same.
> > > * tree-ssa-loop-ch.cc (entry_loop_condition_is_static): Same.
> > > * tree-ssa-loop-unswitch.cc (struct unswitch_predicate): Same.
> > > (evaluate_control_stmt_using_entry_checks): Same.
> > > * tree-ssa-threadedge.cc
> > > (hybrid_jt_simplifier::compute_ranges_from_state): Same.
> > > * tree-vrp.cc (supported_types_p): Same.
> > > * value-query.cc (range_query::value_of_expr): Same.
> > > (range_query::value_on_edge): Same.
> > > (range_query::value_of_stmt): Same.
> > > (range_query::get_tree_range): Same.
> > > (get_range_global): Same.
> > > (global_range_query::range_of_expr): Same.
> > > * value-range-equiv.h (class value_range_equiv): Same.
> > > * value-range.cc (irange::supports_type_p): Same.
> > > (unsupported_range::supports_type_p): Same.
> > > * value-range.h (enum value_range_discriminator): Same.
> > > (Value_Range::init): Same.
> > > (Value_Range::supports_type_p): Same.
> > > (irange::supports_type_p): Same.
> > > (irange::supports_p): Same.
> > > (vrange::supports_type_p): Same.
> > > (vrange_allocator::alloc_vrange): Same.
> > > ---
> > >  gcc/gimple-range-edge.cc   |  3 +--
> > >  gcc/gimple-range-fold.cc   |

Re: [PATCH] Remove legacy EVRP code.

2022-06-28 Thread Richard Biener via Gcc-patches
On Mon, Jun 27, 2022 at 9:04 PM Aldy Hernandez  wrote:
>
> With DOM converted to ranger, there are no longer any uses of the EVRP
> engine.  For that matter, we haven't used the legacy mode in quite a
> while, so I think it's safe to remove any associated code.
>
> There are some methods in vr_values which should now be private, but I
> didn't bother changing them, as most of the vr_values class will be
> removed when VRP1 is converted to ranger.
>
> Does anyone have any issues with me pushing this?

Fine with me.

> gcc/ChangeLog:
>
> * Makefile.in: Remove gimple-ssa-evrp.o and gimple-ssa-evrp-analyze.o.
> * flag-types.h (enum evrp_mode): Remove.
> * params.opt: Remove --param=evrp-mode.
> * tree-vrp.cc (make_pass_early_vrp): New.
> (pass_vrp::execute): Call early VRP instance.
> * gimple-ssa-evrp-analyze.cc: Removed.
> * gimple-ssa-evrp-analyze.h: Removed.
> * gimple-ssa-evrp.cc: Removed.
> ---
>  gcc/Makefile.in |   2 -
>  gcc/flag-types.h|   9 -
>  gcc/gimple-ssa-evrp-analyze.cc  | 456 
>  gcc/gimple-ssa-evrp-analyze.h   |  58 
>  gcc/gimple-ssa-evrp.cc  | 395 ---
>  gcc/params.opt  |  19 --
>  gcc/testsuite/g++.dg/pr100774.C |   2 +-
>  gcc/testsuite/gcc.dg/pr100781.c |   2 +-
>  gcc/tree-vrp.cc |  34 ++-
>  9 files changed, 31 insertions(+), 946 deletions(-)
>  delete mode 100644 gcc/gimple-ssa-evrp-analyze.cc
>  delete mode 100644 gcc/gimple-ssa-evrp-analyze.h
>  delete mode 100644 gcc/gimple-ssa-evrp.cc
>
> diff --git a/gcc/Makefile.in b/gcc/Makefile.in
> index b6dcc45a58a..86257a8b84f 100644
> --- a/gcc/Makefile.in
> +++ b/gcc/Makefile.in
> @@ -1413,8 +1413,6 @@ OBJS = \
> gimple-range-infer.o \
> gimple-range-trace.o \
> gimple-ssa-backprop.o \
> -   gimple-ssa-evrp.o \
> -   gimple-ssa-evrp-analyze.o \
> gimple-ssa-isolate-paths.o \
> gimple-ssa-nonnull-compare.o \
> gimple-ssa-split-paths.o \
> diff --git a/gcc/flag-types.h b/gcc/flag-types.h
> index 2c8498169e0..a11f99af887 100644
> --- a/gcc/flag-types.h
> +++ b/gcc/flag-types.h
> @@ -479,15 +479,6 @@ enum threader_debug
>THREADER_DEBUG_ALL = 1
>  };
>
> -/* EVRP mode.  */
> -enum evrp_mode
> -{
> -  EVRP_MODE_RVRP_ONLY,
> -  EVRP_MODE_EVRP_ONLY,
> -  EVRP_MODE_EVRP_FIRST,
> -  EVRP_MODE_RVRP_FIRST
> -};
> -
>  /* VRP modes.  */
>  enum vrp_mode
>  {
> diff --git a/gcc/gimple-ssa-evrp-analyze.cc b/gcc/gimple-ssa-evrp-analyze.cc
> deleted file mode 100644
> index 82142db7976..000
> --- a/gcc/gimple-ssa-evrp-analyze.cc
> +++ /dev/null
> @@ -1,456 +0,0 @@
> -/* Support routines for Value Range Propagation (VRP).
> -   Copyright (C) 2005-2022 Free Software Foundation, Inc.
> -
> -This file is part of GCC.
> -
> -GCC is free software; you can redistribute it and/or modify
> -it under the terms of the GNU General Public License as published by
> -the Free Software Foundation; either version 3, or (at your option)
> -any later version.
> -
> -GCC is distributed in the hope that it will be useful,
> -but WITHOUT ANY WARRANTY; without even the implied warranty of
> -MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> -GNU General Public License for more details.
> -
> -You should have received a copy of the GNU General Public License
> -along with GCC; see the file COPYING3.  If not see
> -.  */
> -
> -#include "config.h"
> -#include "system.h"
> -#include "coretypes.h"
> -#include "backend.h"
> -#include "tree.h"
> -#include "gimple.h"
> -#include "tree-pass.h"
> -#include "ssa.h"
> -#include "gimple-pretty-print.h"
> -#include "cfganal.h"
> -#include "gimple-iterator.h"
> -#include "gimple-fold.h"
> -#include "tree-eh.h"
> -#include "tree-cfg.h"
> -#include "tree-ssa-loop-manip.h"
> -#include "tree-ssa-loop.h"
> -#include "cfgloop.h"
> -#include "tree-scalar-evolution.h"
> -#include "tree-ssa-propagate.h"
> -#include "alloc-pool.h"
> -#include "domwalk.h"
> -#include "tree-cfgcleanup.h"
> -#include "vr-values.h"
> -#include "gimple-ssa-evrp-analyze.h"
> -
> -evrp_range_analyzer::evrp_range_analyzer (bool update_global_ranges)
> -  : stack (10), m_update_global_ranges (update_global_ranges)
> -{
> -  edge e;
> -  edge_iterator ei;
> -  basic_block bb;
> -  FOR_EACH_BB_FN (bb, cfun)
> -{
> -  bb->flags &= ~BB_VISITED;
> -  FOR_EACH_EDGE (e, ei, bb->preds)
> -e->flags |= EDGE_EXECUTABLE;
> -}
> -}
> -
> -/* Push an unwinding marker onto the unwinding stack.  */
> -
> -void
> -evrp_range_analyzer::push_marker ()
> -{
> -  stack.safe_push (std::make_pair (NULL_TREE, (value_range_equiv *)NULL));
> -}
> -
> -/* Analyze ranges as we enter basic block BB.  */
> -
> -void
> -evrp_range_analyzer::enter (basic_block bb)
> -{
> -  if (!optimize)
> -return;
> -  push_marker ();
> -  record_ranges_from_incoming_edge (bb);
> -  record_ra

Re: [PATCH] libgompd: Fixed Access bug

2022-06-28 Thread Jakub Jelinek via Gcc-patches
On Sun, Jun 26, 2022 at 02:26:27AM +0200, Mohamed Atef wrote:
> Hello,
>   I referenced kind, nthread, and implicit as pointers in my last patch.
> This patch fixes this bug. We review patches and even the committed ones.
> Another thing, I didn't add gompd_thread_handle_access entries in the
> ChangeLog.
> 
> libgomp/ChangeLog
> 
> 2022-06-26  MohamedAtef  

Missing space between your name and surname.
> 
> * ompd-helper.c (gompd_is_final): Change is_ptr from 1 to 0 in
> ACCESS_VALUE.
> (gompd_is_implicit, and gompd_get_team_size): Likewise.

Please take the " and" part out of it.
You could also write
* ompd-helper.c (gompd_is_final, gompd_is_implicit,
gompd_get_team_size): Change is_ptr from 1 to 0 in ACCESS_VALUE.

> 
>  Signed-off-by: Mohamed Atef 

Otherwise LGTM.

> diff --git a/libgomp/ompd-helper.c b/libgomp/ompd-helper.c
> index 9762b48dff8..ca05ed50c18 100644
> --- a/libgomp/ompd-helper.c
> +++ b/libgomp/ompd-helper.c
> @@ -540,7 +540,7 @@ gompd_is_final (ompd_task_handle_t *task_handle, 
> ompd_word_t *final_task)
>ompd_rc_t ret;
>/* gomp_task->final_task.  */
>ACCESS_VALUE (context, NULL, "gompd_access_gomp_task_final_task", 
> temp_offset,
> - 1, ret, symbol_addr, temp_sym_addr, temp_addr);
> + 0, ret, symbol_addr, temp_sym_addr, temp_addr);
>DEREFERENCE (context, NULL, symbol_addr, target_sizes.sizeof_char, 1,
>  res, ret, 0);
>*final_task = res;
> @@ -565,7 +565,7 @@ gompd_is_implicit (ompd_task_handle_t *task_handle, 
> ompd_word_t *task_kind)
>ompd_address_space_context_t *context = task_handle->ah->context;
>ompd_rc_t ret;
>/* gomp_task->kind.  */
> -  ACCESS_VALUE (context, NULL, "gompd_access_gomp_task_kind", temp_offset, 1,
> +  ACCESS_VALUE (context, NULL, "gompd_access_gomp_task_kind", temp_offset, 0,
>   ret, symbol_addr, temp_sym_addr, temp_addr);
>DEREFERENCE (context, NULL, symbol_addr, target_sizes.sizeof_int, 1, res,
>  ret, 0);
> @@ -597,7 +597,7 @@ gompd_get_team_size (ompd_parallel_handle_t 
> *parallel_handle,
>ompd_rc_t ret;
>/* gomp_team->nthreads.  */
>ACCESS_VALUE (context, NULL, "gompd_access_gomp_team_nthreads", 
> temp_offset,
> - 1, ret, symbol_addr, temp_sym_addr, temp_addr);
> + 0, ret, symbol_addr, temp_sym_addr, temp_addr);
>DEREFERENCE (context, NULL, symbol_addr, target_sizes.sizeof_int, 1,
>  res, ret, 0);
>*nthreads = res;


Jakub



[committed] libstdc++: testsuite: Guard use of C99 std::log2

2022-06-28 Thread Jonathan Wakely via Gcc-patches
Tested x86_64-linux, poushed to trunk.

-- >8 --

This prevents the test from failing if the only thing not supported is
the text printed to the log about the size of the floating-point type.

libstdc++-v3/ChangeLog:

* testsuite/20_util/from_chars/4.cc: Only use log2 if C99 math
functions are available.
---
 libstdc++-v3/testsuite/20_util/from_chars/4.cc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libstdc++-v3/testsuite/20_util/from_chars/4.cc 
b/libstdc++-v3/testsuite/20_util/from_chars/4.cc
index dcd9f97c946..c27df4ffa5e 100644
--- a/libstdc++-v3/testsuite/20_util/from_chars/4.cc
+++ b/libstdc++-v3/testsuite/20_util/from_chars/4.cc
@@ -300,9 +300,11 @@ test_max_mantissa()
 
   if (Float_limits::is_iec559 && Float_limits::digits < UInt_limits::digits)
   {
+#ifdef _GLIBCXX_USE_C99_MATH_TR1
 std::printf("Testing %d-bit float, using %zu-bit integer\n",
Float_limits::digits + (int)std::log2(Float_limits::max_exponent) + 1,
sizeof(UIntT) * __CHAR_BIT__);
+#endif
 
 std::from_chars_result res;
 FloatT flt;
-- 
2.36.1



Re: [PATCH] fortran, libgfortran, v3: Avoid using libquadmath for glibc 2.26+

2022-06-28 Thread Tobias Burnus

On 27.06.22 15:30, Jakub Jelinek via Gcc-patches wrote:


Ok, here is an updated patch that uses _Float128/_Complex _Float128 for all
of GFC_REAL_{16,17}_IS_FLOAT128, but still uses q/Q suffixes on literal
constants etc. when using libquadmath and f128/F128 otherwise.
This patch also includes the incremental powerpc64le fixes.

Ok if it passes testing?


LGTM – I am not completely happy of having a TARGET_GLIBC_M{AJ,IN}OR check
in the FE (vs. a symbol-is-available check in libgfortran), but that
should be fine as it is unlikely to cause any issue in practice.

Thanks for the patch.

Tobias


2022-06-27  Jakub Jelinek  

gcc/fortran/
  * gfortran.h (gfc_real_info): Add use_iec_60559 bitfield.
  * trans-types.h (gfc_real16_use_iec_60559): Declare.
  * trans-types.cc (gfc_real16_use_iec_60559): Define.
  (gfc_init_kinds): When building powerpc64le-linux libgfortran
  on glibc 2.26 to 2.31, set gfc_real16_use_iec_60559 and
  use_iec_60559.
  (gfc_build_real_type): Set gfc_real16_use_iec_60559 and use_iec_60559
  on glibc 2.26 or later.
  * trans-intrinsic.cc (gfc_build_intrinsic_lib_fndecls): Adjust
  comment.  Handle gfc_real16_use_iec_60559.
  (gfc_get_intrinsic_lib_fndecl): Handle use_iec_60559.
libgfortran/
  * configure.ac: Check for strtof128 and strfromf128.
  Check for math and complex *f128 functions.  Set
  have_iec_60559_libc_support to yes if *f128 support is around, for
  --enable-libquadmath-support default to "default" rather than yes if
  have_iec_60559_libc_support is yes.
  * acinclude.m4 (LIBGFOR_CHECK_FLOAT128): Test
  _Float128/_Complex _Float128 rather than __float128 and
  _Complex float __attribute__((mode(TC))).  If libquadmath support
  is defaulted and have_iec_60559_libc_support is yes, define and subst
  USE_IEC_60559.  Remove unused LIBGFOR_BUILD_QUAD conditional.
  * Makefile.am (kinds.h): Pass @USE_IEC_60559@ as an extra
  mk-kinds-h.sh argument.
  * mk-kinds-h.sh: Accept 4th use_iec_60559 argument.  Use
  _Float128/_Complex _Float128 types instead of __float128 and
 _Complex float __attribute__((mode(TC))), and if use_iec_60559 is yes,
  use f128 suffix instead of q and define GFC_REAL_16_USE_IEC_60559.
  * kinds-override.h: Use _Float128/_Complex _Float128 types instead of
  __float128 and _Complex float __attribute__((mode(TC))), if
  USE_IEC_60559 is defined, use f128 suffixes instead of q and
  define GFC_REAL_17_USE_IEC_60559.
  * libgfortran.h: Don't include quadmath_weak.h if USE_IEC_60559 is
  defined.
  (GFC_REAL_16_INFINITY, GFC_REAL_16_QUIET_NAN): Define
  for GFC_REAL_16_USE_IEC_60559 differently.
  * caf/single.c (convert_type): Use _Float128/_Complex _Float128
  instead of __float128 and _Complex float __attribute__((mode(TC))).
  For HAVE_GFC_REAL_10 when HAVE_GFC_REAL_16 isn't defined use
  _Complex long double instead of long double.
  * ieee/issignaling_fallback.h (ieee854_float128_shape_type): Use
  _Float128 instead of __float128.
  (__issignalingf128): Change argument type to _Float128.
  (issignaling): Use _Float128 instead of __float128 in _Generic.
  * intrinsics/cshift0.c (cshift0): Use _Float128 instead of __float128
  in a comment.  Fix a comment typo, logn double -> long double.
  * intrinsics/erfc_scaled.c (_THRESH, _M_2_SQRTPI, _INF, _ERFC, _EXP):
  Use different definitions if GFC_REAL_16_USE_IEC_60559.
  (_THRESH, _M_2_SQRTPI): Use GFC_REAL_17_LITERAL macro.
  (_ERFC, _EXP): Use different definitions if GFC_REAL_17_USE_IEC_60559.
  * intrinsics/spread_generic.c (spread, spread_scalar): Use _Float128
  instead of __float128 in a comment.  Fix a comment typo,
  logn double -> long double.
  * intrinsics/trigd.c (ENABLE_SIND, ENABLE_COSD, ENABLE_TAND): Handle
  GFC_REAL_16_USE_IEC_60559.
  * intrinsics/pack_generic.c (pack): Use _Float128 instead of
  __float128 in a comment.  Fix a comment typo, logn double ->
  long double.
  * intrinsics/unpack_generic.c (unpack1, unpack0): Likewise.
  * runtime/in_pack_generic.c (internal_pack): Likewise.
  * runtime/in_unpack_generic.c (internal_unpack): Likewise.
  * io/read.c (convert_real, convert_infnan): Handle
  GFC_REAL_16_USE_IEC_60559 and GFC_REAL_17_USE_IEC_60559.
  * io/transfer128.c (tmp1, tmp2): Don't define if libquadmath
  isn't needed.
  * io/write_float.def (gfor_strfromf128): New function.
  (DTOA2Q, FDTOA2Q): Define differently if
  GFC_REAL_16_USE_IEC_60559 or GFC_REAL_17_USE_IEC_60559.
  * m4/mtype.m4: Use different suffix if GFC_REAL_16_USE_IEC_60559
  or GFC_REAL_17_USE_IEC_60559.
  * config.h.in: Regenerated.
  * configure: Regenerated.
  * Makefile.in: Regenerated.
  * generated/bessel_r16.c: Regenerated.
  * generated/bessel_r17.c: Regenerated.
  * generated/norm2_r16.c: Regenerated.
  

Re: [PATCH] libstdc++-v3: check for openat

2022-06-28 Thread Jonathan Wakely via Gcc-patches
On Mon, 27 Jun 2022 at 23:04, Alexandre Oliva via Libstdc++
 wrote:
>
> On Jun 27, 2022, Jonathan Wakely  wrote:
>
> > -#if _GLIBCXX_HAVE_DIRFD
> > +#if _GLIBCXX_HAVE_DIRFD && _GLIBCXX_HAVE_OPENAT && _GLIBCXX_HAVE_UNLINKAT

I'll push this today.

> Thanks, I had this bit in the WIP _At_path patch, as well as my updated
> remove_all patch, in the latest round of tests.
>
> I confirm that I don't get any errors with it on an x86_64-linux-gnu
> native built with openat and unlinkat forced disabled in libstdc++, but
> on aarch64-rtems6, there are some fails that are not making much sense
> to me.  I haven't looked into any but 27_io/.../copy.cc, so I can't tell
> whether they've regressed, but copy.cc's test01 did when I put this (or
> variants thereof) in.
>
> Tomorrow I'll look into building libstdc++ with -Og or something else
> with less optimization than the default, to help me make sense of what's

You can just use --enable-libstdcxx-debug and then link to the libs in
$libdir/debug instead of $libdir (e.g. with LD_LIBRARY_PATH).

> going on that causes copy() to return without as much as creating the
> destination.

Again, that test is *supposed* to return without creating the
destination. It's testing the failure case.

>
>
> FAILED: default@libstdc++,27_io,filesystem,operations,copy_cc
> FAILED: default@libstdc++,experimental,filesystem,operations,copy_cc
>
> .../27_io/filesystem/operations/copy.cc:5[67]: void test01(): Assertion 
> '!exists(to)' failed.

I don't know what 5[67] means, so I don't know if that's the first or
second !exists(to) assertion, but this is not failing because copy
returned without creating something. copy is not supposed to create
anything here, and it didn't, because the previous assertion (ec ==
std::make_error_code(std::errc::is_a_directory)) didn't fail. So the
copy function behaves correctly, but the 'to' file exists anyway.
Which suggests to me another problem with mkstemp / nonexistent_path.
Before rebuilding the library I'd just add an extra assertion into the
test.

--- a/libstdc++-v3/testsuite/27_io/filesystem/operations/copy.cc
+++ b/libstdc++-v3/testsuite/27_io/filesystem/operations/copy.cc
@@ -49,6 +49,7 @@ test01()
  VERIFY( ec );

  auto to = __gnu_test::nonexistent_path();
+  VERIFY( !exists(to) );
  ec.clear();
  auto opts = fs::copy_options::create_symlinks;
  fs::copy("/", to, opts, ec);

I suspect this is going to fail, because 'to' already exists before
you ever call copy("/", to, opts, ec).

And that would happen is nonexistent_path is still broken. Do you have
the commit r13-1289-g30a8f67295f412 in your tree?

> FAILED: default@libstdc++,27_io,filesystem,operations,copy_file_cc
> FAILED: default@libstdc++,experimental,filesystem,operations,copy_file_cc
>
> terminate called after throwing an instance of 
> 'std::filesystem::__cxx11::filesystem_error'
>   what():  filesystem error: cannot copy file: File exists 
> [filesystem-test.01-copy_file] [filesystem-test.01-copy_file]

Again, this looks like a problem with nonexistent_path, the 'from' and
'to' paths are the same:

  auto from = __gnu_test::nonexistent_path();
  auto to = __gnu_test::nonexistent_path();


> FAILED: default@libstdc++,27_io,filesystem,operations,equivalent_cc
> FAILED: default@libstdc++,experimental,filesystem,operations,equivalent_cc
>
> .../27_io/filesystem/operations/equivalent.cc:4[45]: void test01(): Assertion 
> '!result' failed.

This would also happen if nonexistent_path still returns the same value twice.

>
> FAILED: default@libstdc++,27_io,filesystem,operations,relative_cc
>
> .../27_io/filesystem/operations/relative.cc:32: void test01(): Assertion 'r 
> == ".."/p' failed.

Ditto.

>
> Also still present:
>
> .../20_util/from_chars/4.cc:304: error: 'log2' is not a member of 'std'; did 
> you mean 'log'?
>
> (IIRC we used to have two of these, we're now down to one)

That should be fixed at r13-1315-g30aea28bd30027 now.



[PATCH][pushed] libgomp: fix typo in mold linker detection

2022-06-28 Thread Martin Liška
Pushed as obvious to master and gcc-12 branch.

Thanks,
Martin

libgomp/ChangeLog:

* acinclude.m4: Fix typo in mold linker detection.
* Makefile.in: Regenerate.
* configure: Regenerate.
---
 libgomp/Makefile.in  | 2 +-
 libgomp/acinclude.m4 | 2 +-
 libgomp/configure| 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/libgomp/Makefile.in b/libgomp/Makefile.in
index 8f6255f2d70..8ffd45c9c41 100644
--- a/libgomp/Makefile.in
+++ b/libgomp/Makefile.in
@@ -16,7 +16,7 @@
 
 # Plugins for offload execution, Makefile.am fragment.
 #
-# Copyright (C) 2014-2021 Free Software Foundation, Inc.
+# Copyright (C) 2014-2022 Free Software Foundation, Inc.
 #
 # Contributed by Mentor Embedded.
 #
diff --git a/libgomp/acinclude.m4 b/libgomp/acinclude.m4
index b8154eba99c..12fbb20066c 100644
--- a/libgomp/acinclude.m4
+++ b/libgomp/acinclude.m4
@@ -154,7 +154,7 @@ AC_DEFUN([LIBGOMP_CHECK_LINKER_FEATURES], [
   if $LD --version 2>/dev/null | grep 'GNU gold'> /dev/null 2>&1; then
 libgomp_ld_is_gold=yes
   elif $LD --version 2>/dev/null | grep 'mold'> /dev/null 2>&1; then
-libat_ld_is_mold=yes
+libgomp_ld_is_mold=yes
   fi
   changequote(,)
   ldver=`$LD --version 2>/dev/null |
diff --git a/libgomp/configure b/libgomp/configure
index 89f14e441f2..b11170e6a7c 100755
--- a/libgomp/configure
+++ b/libgomp/configure
@@ -16027,7 +16027,7 @@ with_gnu_ld=$lt_cv_prog_gnu_ld
   if $LD --version 2>/dev/null | grep 'GNU gold'> /dev/null 2>&1; then
 libgomp_ld_is_gold=yes
   elif $LD --version 2>/dev/null | grep 'mold'> /dev/null 2>&1; then
-libat_ld_is_mold=yes
+libgomp_ld_is_mold=yes
   fi
 
   ldver=`$LD --version 2>/dev/null |
-- 
2.36.1



[PATCH 10/12 V2] arm: Implement cortex-M return signing address codegen

2022-06-28 Thread Andrea Corallo via Gcc-patches
Hi all,

second version of this patch enabling address return signature and
verification based on Armv8.1-M Pointer Authentication [1].

To sign the return address, we use the PAC R12, LR, SP instruction
upon function entry.  This is signing LR using SP and storing the
result in R12.  R12 will be pushed into the stack.

During function epilogue R12 will be popped and AUT R12, LR, SP will
be used to verify that the content of LR is still valid before return.

Here an example of PAC instrumented function prologue and epilogue:

void foo (void);

int main()
{
  foo ();
  return 0;
}

Compiled with '-march=armv8.1-m.main -mbranch-protection=pac-ret
-mthumb' translates into:

main:
pac ip, lr, sp
push{r3, r7, ip, lr}
add r7, sp, #0
bl  foo
movsr3, #0
mov r0, r3
pop {r3, r7, ip, lr}
aut ip, lr, sp
bx  lr

The patch also takes care of generating a PACBTI instruction in place
of the sequence BTI+PAC when Branch Target Identification is enabled
contextually.

Ex. the previous example compiled with '-march=armv8.1-m.main
-mbranch-protection=pac-ret+bti -mthumb' translates into:

main:
pacbti  ip, lr, sp
push{r3, r7, ip, lr}
add r7, sp, #0
bl  foo
movsr3, #0
mov r0, r3
pop {r3, r7, ip, lr}
aut ip, lr, sp
bx  lr

As part of previous upstream suggestions a test for varargs has been
added and '-mtpcs-frame' is deemed being incompatible with this return
signing address feature being introduced.

[1] 


gcc/Changelog

* config/arm/arm.c: (arm_compute_frame_layout)
(arm_expand_prologue, thumb2_expand_return, arm_expand_epilogue)
(arm_conditional_register_usage): Update for pac codegen.
(arm_current_function_pac_enabled_p): New function.
* config/arm/arm.md (pac_ip_lr_sp, pacbti_ip_lr_sp, aut_ip_lr_sp):
Add new patterns.
* config/arm/unspecs.md (UNSPEC_PAC_IP_LR_SP)
(UNSPEC_PACBTI_IP_LR_SP, UNSPEC_AUT_IP_LR_SP): Add unspecs.

gcc/testsuite/Changelog

* gcc.target/arm/pac.h : New file.
* gcc.target/arm/pac-1.c : New test case.
* gcc.target/arm/pac-2.c : Likewise.
* gcc.target/arm/pac-3.c : Likewise.
* gcc.target/arm/pac-4.c : Likewise.
* gcc.target/arm/pac-5.c : Likewise.
* gcc.target/arm/pac-6.c : Likewise.
* gcc.target/arm/pac-7.c : Likewise.
* gcc.target/arm/pac-8.c : Likewise.

diff --git a/gcc/config/arm/arm-protos.h b/gcc/config/arm/arm-protos.h
index cff7ff1da2a..84764bf27ce 100644
--- a/gcc/config/arm/arm-protos.h
+++ b/gcc/config/arm/arm-protos.h
@@ -379,6 +379,7 @@ extern int vfp3_const_double_for_bits (rtx);
 extern void arm_emit_coreregs_64bit_shift (enum rtx_code, rtx, rtx, rtx, rtx,
   rtx);
 extern bool arm_fusion_enabled_p (tune_params::fuse_ops);
+extern bool arm_current_function_pac_enabled_p (void);
 extern bool arm_valid_symbolic_address_p (rtx);
 extern bool arm_validize_comparison (rtx *, rtx *, rtx *);
 extern bool arm_expand_vector_compare (rtx, rtx_code, rtx, rtx, bool);
diff --git a/gcc/config/arm/arm.cc b/gcc/config/arm/arm.cc
index ceec14f84b6..6760a01d68a 100644
--- a/gcc/config/arm/arm.cc
+++ b/gcc/config/arm/arm.cc
@@ -21139,6 +21139,14 @@ arm_compute_save_core_reg_mask (void)
 
   save_reg_mask |= arm_compute_save_reg0_reg12_mask ();
 
+  if (arm_current_function_pac_enabled_p ())
+{
+  if (TARGET_TPCS_FRAME
+ || (TARGET_TPCS_LEAF_FRAME && crtl->is_leaf))
+   error ("TPCS incompatible with return address signing.");
+  save_reg_mask |= 1 << IP_REGNUM;
+}
+
   /* Decide if we need to save the link register.
  Interrupt routines have their own banked link register,
  so they never need to save it.
@@ -22302,7 +22310,7 @@ arm_emit_multi_reg_pop (unsigned long saved_regs_mask)
 par = emit_insn (par);
 
   REG_NOTES (par) = dwarf;
-  if (!return_in_pc)
+  if (!return_in_pc && !frame_pointer_needed)
 arm_add_cfa_adjust_cfa_note (par, UNITS_PER_WORD * num_regs,
 stack_pointer_rtx, stack_pointer_rtx);
 }
@@ -23352,6 +23360,11 @@ output_probe_stack_range (rtx reg1, rtx reg2)
   return "";
 }
 
+static bool  aarch_bti_enabled ()
+{
+  return false;
+}
+
 /* Generate the prologue instructions for entry into an ARM or Thumb-2
function.  */
 void
@@ -23431,11 +23444,12 @@ arm_expand_prologue (void)
   /* The static chain register is the same as the IP register.  If it is
  clobbered when creating the frame, we need to save and restore it.  */
   clobber_ip = IS_NESTED (func_type)
-  && ((TARGET_APCS_FRAME && frame_pointer_needed && TARGET_ARM)
-  || ((flag

[PATCH 12/12 V2] arm: implement bti injection

2022-06-28 Thread Andrea Corallo via Gcc-patches
Hi all,

second iteration of this patch enabling Branch Target Identification
Armv8.1-M Mechanism [1].

This is achieved by using the bti pass made common with Aarch64.

The pass iterates through the instructions and adds the necessary BTI
instructions at the beginning of every function and at every landing
pads targeted by indirect jumps.

Best Regards

  Andrea

[1]


gcc/ChangeLog

2022-04-07  Andrea Corallo  

* config.gcc (arm*-*-*): Add 'aarch-bti-insert.o' object.
* config/arm/arm-protos.h: Update.
* config/arm/arm.cc (aarch_bti_enabled, aarch_bti_j_insn_p)
(aarch_pac_insn_p, aarch_gen_bti_c, aarch_gen_bti_j): New
functions.
* config/arm/arm.md (bti_nop): New insn.
* config/arm/t-arm (PASSES_EXTRA): Add 'arm-passes.def'.
(aarch-bti-insert.o): New target.
* config/arm/unspecs.md (UNSPEC_BTI_NOP): New unspec.
* config/arm/aarch-bti-insert.cc (rest_of_insert_bti): Update
to verify arch compatibility.

gcc/testsuite/ChangeLog

2022-04-07  Andrea Corallo  

* gcc.target/arm/bti-1.c: New testcase.
* gcc.target/arm/bti-2.c: Likewise.

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 2021bdf9d2f..004e1dfa8d8 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -353,7 +353,7 @@ arc*-*-*)
;;
 arm*-*-*)
cpu_type=arm
-   extra_objs="arm-builtins.o arm-mve-builtins.o aarch-common.o"
+   extra_objs="arm-builtins.o arm-mve-builtins.o aarch-common.o 
aarch-bti-insert.o"
extra_headers="mmintrin.h arm_neon.h arm_acle.h arm_fp16.h arm_cmse.h 
arm_bf16.h arm_mve_types.h arm_mve.h arm_cde.h"
target_type_format_char='%'
c_target_objs="arm-c.o"
diff --git a/gcc/config/arm/aarch-bti-insert.cc 
b/gcc/config/arm/aarch-bti-insert.cc
index 2d1d2e334a9..38f5a58ef2f 100644
--- a/gcc/config/arm/aarch-bti-insert.cc
+++ b/gcc/config/arm/aarch-bti-insert.cc
@@ -41,6 +41,7 @@
 #include "cfgrtl.h"
 #include "tree-pass.h"
 #include "cgraph.h"
+#include "diagnostic-core.h"
 
 /* This pass enables the support for Branch Target Identification Mechanism for
Arm/AArch64.  This is a security feature introduced in ARMv8.5-A
@@ -104,6 +105,14 @@ rest_of_insert_bti (void)
   rtx_insn *insn;
   basic_block bb;
 
+#if defined (TARGET_32BIT) || defined (TARGET_THUMB1)
+  if (!arm_arch8)
+{
+  error ("This architecture does not support branch protection 
instructions");
+  goto exit;
+}
+#endif
+
   bb = 0;
   FOR_EACH_BB_FN (bb, cfun)
 {
@@ -175,6 +184,7 @@ rest_of_insert_bti (void)
}
 }
 
+ exit:
   timevar_pop (TV_MACH_DEP);
   return 0;
 }
diff --git a/gcc/config/arm/arm-protos.h b/gcc/config/arm/arm-protos.h
index 84764bf27ce..6befb6c4445 100644
--- a/gcc/config/arm/arm-protos.h
+++ b/gcc/config/arm/arm-protos.h
@@ -24,6 +24,8 @@
 
 #include "sbitmap.h"
 
+rtl_opt_pass *make_pass_insert_bti (gcc::context *ctxt);
+
 extern enum unwind_info_type arm_except_unwind_info (struct gcc_options *);
 extern int use_return_insn (int, rtx);
 extern bool use_simple_return_p (void);
diff --git a/gcc/config/arm/arm.cc b/gcc/config/arm/arm.cc
index 6760a01d68a..059075e2c95 100644
--- a/gcc/config/arm/arm.cc
+++ b/gcc/config/arm/arm.cc
@@ -23360,11 +23360,6 @@ output_probe_stack_range (rtx reg1, rtx reg2)
   return "";
 }
 
-static bool  aarch_bti_enabled ()
-{
-  return false;
-}
-
 /* Generate the prologue instructions for entry into an ARM or Thumb-2
function.  */
 void
@@ -32980,6 +32975,56 @@ arm_current_function_pac_enabled_p (void)
&& !crtl->is_leaf);
 }
 
+/* Return TRUE if Branch Target Identification Mechanism is enabled.  */
+bool
+aarch_bti_enabled (void)
+{
+  return aarch_enable_bti == 1;
+}
+
+/* Check if INSN is a BTI J insn.  */
+bool
+aarch_bti_j_insn_p (rtx_insn *insn)
+{
+  if (!insn || !INSN_P (insn))
+return false;
+
+  rtx pat = PATTERN (insn);
+  return GET_CODE (pat) == UNSPEC_VOLATILE && XINT (pat, 1) == UNSPEC_BTI_NOP;
+}
+
+/* Check if X (or any sub-rtx of X) is a PACIASP/PACIBSP instruction.  */
+bool
+aarch_pac_insn_p (rtx x)
+{
+  if (!x || !INSN_P (x))
+return false;
+
+  rtx pat = PATTERN (x);
+
+  if (GET_CODE (pat) == SET)
+{
+  rtx tmp = XEXP (pat, 1);
+  if (tmp
+ && GET_CODE (tmp) == UNSPEC
+ && (XINT (tmp, 1) == UNSPEC_PAC_NOP
+ || XINT (tmp, 1) == UNSPEC_PACBTI_NOP))
+   return true;
+}
+
+  return false;
+}
+
+rtx aarch_gen_bti_c (void)
+{
+  return gen_bti_nop ();
+}
+
+rtx aarch_gen_bti_j (void)
+{
+  return gen_bti_nop ();
+}
+
 /* Implement TARGET_SCHED_CAN_SPECULATE_INSN.  Return true if INSN can be
scheduled for speculative execution.  Reject the long-running division
and square-root instructions.  */
diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md
index ae032e70a7d..b14c45638a8 1006

Re: [COMMITTED] Implement vrange::supports_type_p.

2022-06-28 Thread Aldy Hernandez via Gcc-patches
On Tue, Jun 28, 2022 at 9:36 AM Richard Biener
 wrote:
>
> On Mon, Jun 27, 2022 at 9:00 PM Aldy Hernandez  wrote:
> >
> > The conversion for loop-ch is trivial, since the range of a
> > GIMPLE_COND is always an integer.
>
> Yes - but doesn't this hint at the fact that the irange::supports_p is
> useless because it checks on the type of the comparison operand
> rather than the type of the comparison (boolean_type_node)?
>
> So .. instead of replacing it, remove it?

You're absolutely right.

OK pending tests?

Aldy
From 6a37eec1ccc4f9d648156bc1eaf99ba73a6ccce2 Mon Sep 17 00:00:00 2001
From: Aldy Hernandez 
Date: Mon, 27 Jun 2022 20:50:03 +0200
Subject: [PATCH] Allow all types supported by ranger in loop-ch.

This converts the ranger use in loop-ch to allow any types allowed by
the ranger infrastructure.  Since the range of a GIMPLE_COND is always an
integer we can remove the check because the only temporary is already
an int_range.

gcc/ChangeLog:

	* tree-ssa-loop-ch.cc (entry_loop_condition_is_static): Remove
	irange::supports_p.
---
 gcc/tree-ssa-loop-ch.cc | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/gcc/tree-ssa-loop-ch.cc b/gcc/tree-ssa-loop-ch.cc
index 26d96c0c21a..b74f1d7b612 100644
--- a/gcc/tree-ssa-loop-ch.cc
+++ b/gcc/tree-ssa-loop-ch.cc
@@ -54,8 +54,7 @@ entry_loop_condition_is_static (class loop *l, path_range_query *query)
   edge e = loop_preheader_edge (l);
   gcond *last = safe_dyn_cast  (last_stmt (e->dest));
 
-  if (!last
-  || !irange::supports_p (TREE_TYPE (gimple_cond_lhs (last
+  if (!last)
 return false;
 
   edge true_e, false_e;
-- 
2.36.1



[PATCH] middle-end/106053 - fold_sign_changed_comparison and large bools

2022-06-28 Thread Richard Biener via Gcc-patches
The following fixes a latent issue in the match.pd variant of
fold_sign_changed_comparison which replaces an unsigned integer
comparison with a signed boolean comparison of the same precision
despite the fact that we treat BOOLEAN_TYPEs as only having two
valid values.

Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed to trunk
sofar.

2022-06-28  Richard Biener  

PR middle-end/106053
* match.pd ((T)a == (T)b): Avoid folding away sign
changes in a comparison if we'd truncate to a boolean.

* gcc.target/i386/pr106053.c: New testcase.
---
 gcc/match.pd |  7 -
 gcc/testsuite/gcc.target/i386/pr106053.c | 37 
 2 files changed, 43 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.target/i386/pr106053.c

diff --git a/gcc/match.pd b/gcc/match.pd
index 24c5bc1..c43c528424e 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -5542,7 +5542,12 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
&& (TYPE_UNSIGNED (TREE_TYPE (@00)) == TYPE_UNSIGNED (TREE_TYPE (@0))
|| cmp == NE_EXPR
|| cmp == EQ_EXPR)
-   && !POINTER_TYPE_P (TREE_TYPE (@00)))
+   && !POINTER_TYPE_P (TREE_TYPE (@00))
+   /* (int)bool:32 != (int)uint is not the same as
+  bool:32 != (bool:32)uint since boolean types only have two valid
+  values independent of their precision.  */
+   && (TREE_CODE (TREE_TYPE (@00)) != BOOLEAN_TYPE
+   || TREE_CODE (TREE_TYPE (@10)) == BOOLEAN_TYPE))
 /* ???  The special-casing of INTEGER_CST conversion was in the original
code and here to avoid a spurious overflow flag on the resulting
constant which fold_convert produces.  */
diff --git a/gcc/testsuite/gcc.target/i386/pr106053.c 
b/gcc/testsuite/gcc.target/i386/pr106053.c
new file mode 100644
index 000..69baa3e5fd1
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr106053.c
@@ -0,0 +1,37 @@
+/* { dg-do run { target lp64 } } */
+/* { dg-options "-O -fno-tree-fre -w -mno-avx" } */
+
+typedef unsigned __attribute__((__vector_size__ (32))) v256u8;
+typedef unsigned __attribute__((__vector_size__ (64))) v512u8;
+typedef unsigned short u16;
+typedef unsigned int u32;
+typedef unsigned long long u64;
+typedef unsigned long __attribute__((__vector_size__ (64))) v512u64;
+typedef unsigned __int128 __attribute__((__vector_size__ (32))) v256u128;
+unsigned u;
+v512u64 foo0_v512u64_0;
+
+static inline v256u8
+foo (u32 u32_0, u64 u64_0, v256u128 v256u128_0)
+{
+  int o = __builtin_add_overflow_p (u64_0, 0, 0);
+  v512u64 v512u64_1 =
+foo0_v512u64_0 & (u32) __builtin_sub_overflow_p (0, o, 0);
+  u64_0 |= u;
+  v256u128 v256u128_2 = u64_0 < v256u128_0;
+  v256u128 v256u128_3 = -v256u128_2 == u64_0 * u32_0;
+  v256u8 v256u8_r = ((union {
+  v512u8 a; v256u8 b[2];
+  }) (v512u8) v512u64_1).b[0] + (v256u8) v256u128_3;
+  return v256u8_r;
+}
+
+int
+main (void)
+{
+  v256u8 x = foo (3095179400, 23725760132, (v256u128) { 2, 2 });
+  for (unsigned i = 0; i < sizeof (x) / sizeof (x[0]); i++)
+if (x[i])
+  __builtin_abort ();
+  return 0;
+}
-- 
2.35.3


Re: [COMMITTED] Implement vrange::supports_type_p.

2022-06-28 Thread Richard Biener via Gcc-patches
On Tue, Jun 28, 2022 at 11:33 AM Aldy Hernandez  wrote:
>
> On Tue, Jun 28, 2022 at 9:36 AM Richard Biener
>  wrote:
> >
> > On Mon, Jun 27, 2022 at 9:00 PM Aldy Hernandez  wrote:
> > >
> > > The conversion for loop-ch is trivial, since the range of a
> > > GIMPLE_COND is always an integer.
> >
> > Yes - but doesn't this hint at the fact that the irange::supports_p is
> > useless because it checks on the type of the comparison operand
> > rather than the type of the comparison (boolean_type_node)?
> >
> > So .. instead of replacing it, remove it?
>
> You're absolutely right.
>
> OK pending tests?

Yes.

> Aldy


[PATCH] rtl-optimization/106082 - preserve EH note for no non-local goto

2022-06-28 Thread Richard Biener via Gcc-patches
The following makes sure we preserve EH notes on call insns that
indicate the call doesn't perform a non-local goto when distributing
notes after combining insns.

Bootstrap & regtest pending on x86_64-unknown-linux-gnu, tested on
the m68k testcase in the PR.

OK for trunk if testing passes?

Thanks,
Richard.

2022-06-28  Richard Biener  

PR rtl-optimization/106082
* combine.cc (distribute_notes): Preserve notes when
they indicate a call doesn't perform a non-local goto.
---
 gcc/combine.cc | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/gcc/combine.cc b/gcc/combine.cc
index a8305273e44..3d34e860cf9 100644
--- a/gcc/combine.cc
+++ b/gcc/combine.cc
@@ -14218,8 +14218,10 @@ distribute_notes (rtx notes, rtx_insn *from_insn, 
rtx_insn *i3, rtx_insn *i2,
  gcc_assert (from_insn == i3);
/* We are making sure there is a single effective REG_EH_REGION
   note and it's valid to put it on i3.  */
-   if (!insn_could_throw_p (from_insn))
- /* Throw away stra notes on insns that can never throw.  */
+   if (!insn_could_throw_p (from_insn)
+   && (lp_nr != INT_MIN || !can_nonlocal_goto (from_insn)))
+ /* Throw away stray notes on insns that can never throw or
+make a nonlocal goto.  */
  ;
else
  {
-- 
2.35.3


Re: [PATCH] fortran, libgfortran, v3: Avoid using libquadmath for glibc 2.26+

2022-06-28 Thread Jakub Jelinek via Gcc-patches
On Tue, Jun 28, 2022 at 10:35:03AM +0200, Tobias Burnus wrote:
> On 27.06.22 15:30, Jakub Jelinek via Gcc-patches wrote:
> 
> > Ok, here is an updated patch that uses _Float128/_Complex _Float128 for all
> > of GFC_REAL_{16,17}_IS_FLOAT128, but still uses q/Q suffixes on literal
> > constants etc. when using libquadmath and f128/F128 otherwise.
> > This patch also includes the incremental powerpc64le fixes.
> > 
> > Ok if it passes testing?
> 
> LGTM – I am not completely happy of having a TARGET_GLIBC_M{AJ,IN}OR check
> in the FE

I've used it because it is already (though my fault too) used for the
powerpc64le stuff in the FE too.
The alternative would be grepping of target glibc headers in
gcc/configure.ac, because I think we can't during gcc configure time
preprocess the target glibc header (at least not reliably) because
at that point we just have host compiler which might be a different
architecture.  So, we could e.g. grep for
grep '^[[:blank:]]*#[[:blank:]]*define[[:blank:]]*__HAVE_FLOAT128[[:blank:]]*1' 
$target_header_dir/bits/floatn.h
or so.
Currently all arches that do have the IEC 60559 _Float128 *f128 APIs
in glibc were added in glibc 2.26, if some extra are added later
or some other libraries add those, we can always improve the checks.

Jakub



[committed] libstdc++: Improve directory iterator abstractions for openat

2022-06-28 Thread Jonathan Wakely via Gcc-patches
Tested powerpc64le-linux, pushed to trunk.

-- >8 --

Currently the _Dir::open_subdir function decides whether to construct a
_Dir_base with just a pathname, or a file descriptor and pathname. But
that means it is tiughtly coupled to the implementation of
_Dir_base::openat, which is what actually decides whether to use a file
descriptor or not. If the derived class passes a file descriptor and
filename, but the base class expects a full path and ignores the file
descriptor, then recursive_directory_iterator cannot recurse.

This change introduces a new type that provides the union of all the
information available to the derived class (the full pathname, as well
as a file descriptor for a directory and another pathname relative to
that directory). This allows the derived class to be agnostic to how the
base class will use that information.

libstdc++-v3/ChangeLog:

* src/c++17/fs_dir.cc (_Dir::dir_and_pathname):: Replace with
current() returning _At_path.
(_Dir::_Dir, _Dir::open_subdir, _Dir::do_unlink): Adjust.
* src/filesystem/dir-common.h (_Dir_base::_At_path): New class.
(_Dir_base::_Dir_Base, _Dir_base::openat): Use _At_path.
* src/filesystem/dir.cc (_Dir::dir_and_pathname): Replace with
current() returning _At_path.
(_Dir::_Dir, _Dir::open_subdir): Adjust.
---
 libstdc++-v3/src/c++17/fs_dir.cc | 29 ++-
 libstdc++-v3/src/filesystem/dir-common.h | 66 +---
 libstdc++-v3/src/filesystem/dir.cc   | 21 
 3 files changed, 73 insertions(+), 43 deletions(-)

diff --git a/libstdc++-v3/src/c++17/fs_dir.cc b/libstdc++-v3/src/c++17/fs_dir.cc
index 025317b0a08..2258399da25 100644
--- a/libstdc++-v3/src/c++17/fs_dir.cc
+++ b/libstdc++-v3/src/c++17/fs_dir.cc
@@ -46,7 +46,7 @@ struct fs::_Dir : _Dir_base
 {
   _Dir(const fs::path& p, bool skip_permission_denied, bool nofollow,
[[maybe_unused]] bool filename_only, error_code& ec)
-  : _Dir_base(fdcwd(), p.c_str(), skip_permission_denied, nofollow, ec)
+  : _Dir_base(p.c_str(), skip_permission_denied, nofollow, ec)
   {
 #if _GLIBCXX_HAVE_DIRFD && _GLIBCXX_HAVE_OPENAT && _GLIBCXX_HAVE_UNLINKAT
 if (filename_only)
@@ -117,18 +117,19 @@ struct fs::_Dir : _Dir_base
 return false;
   }
 
-  // Return a file descriptor for the directory and current entry's path.
-  // If dirfd is available, use it and return only the filename.
-  // Otherwise, return AT_FDCWD and return the full path.
-  pair
-  dir_and_pathname() const noexcept
+  // Return a pathname for the current directory entry, as an _At_path.
+  _Dir_base::_At_path
+  current() const noexcept
   {
 const fs::path& p = entry.path();
-#if _GLIBCXX_HAVE_DIRFD && _GLIBCXX_HAVE_OPENAT
-if (!p.empty())
-  return {::dirfd(this->dirp), std::prev(p.end())->c_str()};
+#if _GLIBCXX_HAVE_DIRFD
+if (!p.empty()) [[__likely__]]
+  {
+   auto len = std::prev(p.end())->native().size();
+   return {::dirfd(this->dirp), p.c_str(), p.native().size() - len};
+  }
 #endif
-return {this->fdcwd(), p.c_str()};
+return p.c_str();
   }
 
   // Create a new _Dir for the directory this->entry.path().
@@ -136,8 +137,7 @@ struct fs::_Dir : _Dir_base
   open_subdir(bool skip_permission_denied, bool nofollow,
  error_code& ec) const noexcept
   {
-auto [dirfd, pathname] = dir_and_pathname();
-_Dir_base d(dirfd, pathname, skip_permission_denied, nofollow, ec);
+_Dir_base d(current(), skip_permission_denied, nofollow, ec);
 // If this->path is empty, the new _Dir should have an empty path too.
 const fs::path& p = this->path.empty() ? this->path : this->entry.path();
 return _Dir(std::move(d), p);
@@ -147,8 +147,9 @@ struct fs::_Dir : _Dir_base
   do_unlink(bool is_directory, error_code& ec) const noexcept
   {
 #if _GLIBCXX_HAVE_UNLINKAT
-auto [dirfd, pathname] = dir_and_pathname();
-if (::unlinkat(dirfd, pathname, is_directory ? AT_REMOVEDIR : 0) == -1)
+const auto atp = current();
+if (::unlinkat(atp.dir(), atp.path_at_dir(),
+  is_directory ? AT_REMOVEDIR : 0) == -1)
   {
ec.assign(errno, std::generic_category());
return false;
diff --git a/libstdc++-v3/src/filesystem/dir-common.h 
b/libstdc++-v3/src/filesystem/dir-common.h
index 669780ea23f..4844b1ac453 100644
--- a/libstdc++-v3/src/filesystem/dir-common.h
+++ b/libstdc++-v3/src/filesystem/dir-common.h
@@ -25,6 +25,7 @@
 #ifndef _GLIBCXX_DIR_COMMON_H
 #define _GLIBCXX_DIR_COMMON_H 1
 
+#include   // uint32_t
 #include   // strcmp
 #include 
 #if _GLIBCXX_FILESYSTEM_IS_WINDOWS
@@ -91,12 +92,50 @@ is_permission_denied_error(int e)
 
 struct _Dir_base
 {
+  // As well as the full pathname (including the directory iterator's path)
+  // this type contains a file descriptor for a directory and a second pathname
+  // relative to that directory. The file descriptor and relative pathname
+  // can be used with POSIX openat and unlinkat.
+  struct _At_pa

[pushed][PATCH] loongarch: exclude LARCH_PROLOGUE_TEMP from SIBCALL_REGS [PR 106096]

2022-06-28 Thread Xi Ruoyao via Gcc-patches
Pushed as r13-1319 and r12-8520.  Already approved by port maintainer at
bugzilla.

-- >8 --

The epilogue may clobber LARCH_PROLOGUE_TEMP ($r13/$t1), so it cannot be
used for sibcalls.

gcc/ChangeLog:

PR target/106096
* config/loongarch/loongarch.h (REG_CLASS_CONTENTS): Exclude
$r13 from SIBCALL_REGS.
* config/loongarch/loongarch.cc (loongarch_regno_to_class):
Change $r13 to JIRL_REGS.

gcc/testsuite/ChangeLog:

PR target/106096
* g++.target/loongarch/loongarch.exp: New test support file.
* g++.target/loongarch/pr106096.C: New test.
---
 gcc/config/loongarch/loongarch.cc |  2 +-
 gcc/config/loongarch/loongarch.h  |  2 +-
 .../g++.target/loongarch/loongarch.exp| 34 +
 gcc/testsuite/g++.target/loongarch/pr106096.C | 75 +++
 4 files changed, 111 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/g++.target/loongarch/loongarch.exp
 create mode 100644 gcc/testsuite/g++.target/loongarch/pr106096.C

diff --git a/gcc/config/loongarch/loongarch.cc 
b/gcc/config/loongarch/loongarch.cc
index 80046b64006..c8502b0b0f3 100644
--- a/gcc/config/loongarch/loongarch.cc
+++ b/gcc/config/loongarch/loongarch.cc
@@ -189,7 +189,7 @@ const enum reg_class 
loongarch_regno_to_class[FIRST_PSEUDO_REGISTER] = {
 GR_REGS,GR_REGS, GR_REGS, GR_REGS,
 JIRL_REGS,   JIRL_REGS,   JIRL_REGS,   JIRL_REGS,
 JIRL_REGS,   JIRL_REGS,   JIRL_REGS,   JIRL_REGS,
-SIBCALL_REGS,SIBCALL_REGS,SIBCALL_REGS,SIBCALL_REGS,
+SIBCALL_REGS,JIRL_REGS,   SIBCALL_REGS,SIBCALL_REGS,
 SIBCALL_REGS,SIBCALL_REGS,SIBCALL_REGS,SIBCALL_REGS,
 SIBCALL_REGS,GR_REGS,GR_REGS, JIRL_REGS,
 JIRL_REGS,   JIRL_REGS,   JIRL_REGS,   JIRL_REGS,
diff --git a/gcc/config/loongarch/loongarch.h b/gcc/config/loongarch/loongarch.h
index 4d107a42209..f9de9a6e4fb 100644
--- a/gcc/config/loongarch/loongarch.h
+++ b/gcc/config/loongarch/loongarch.h
@@ -511,7 +511,7 @@ enum reg_class
 #define REG_CLASS_CONTENTS \
 {  \
   { 0x, 0x, 0x },  /* NO_REGS  */  \
-  { 0x001ff000, 0x, 0x },  /* SIBCALL_REGS  */ \
+  { 0x001fd000, 0x, 0x },  /* SIBCALL_REGS  */ \
   { 0xff90, 0x, 0x },  /* JIRL_REGS  */\
   { 0xfffc, 0x, 0x },  /* CSR_REGS  */ \
   { 0x, 0x, 0x },  /* GR_REGS  */  \
diff --git a/gcc/testsuite/g++.target/loongarch/loongarch.exp 
b/gcc/testsuite/g++.target/loongarch/loongarch.exp
new file mode 100644
index 000..4fd1194a552
--- /dev/null
+++ b/gcc/testsuite/g++.target/loongarch/loongarch.exp
@@ -0,0 +1,34 @@
+# Copyright (C) 2019-2022 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GCC; see the file COPYING3.  If not see
+# .
+
+# GCC testsuite that uses the `dg.exp' driver.
+
+# Exit immediately if this isn't a LoongArch target.
+if ![istarget loongarch*-*-*] then {
+  return
+}
+
+# Load support procs.
+load_lib g++-dg.exp
+
+# Initialize `dg'.
+dg-init
+
+# Main loop.
+dg-runtest [lsort [glob -nocomplain $srcdir/$subdir/*.C]] "" ""
+
+# All done.
+dg-finish
diff --git a/gcc/testsuite/g++.target/loongarch/pr106096.C 
b/gcc/testsuite/g++.target/loongarch/pr106096.C
new file mode 100644
index 000..5edbda220f7
--- /dev/null
+++ b/gcc/testsuite/g++.target/loongarch/pr106096.C
@@ -0,0 +1,75 @@
+/* PR target/106096
+   Reduced from gimple-range-path.cc.  It was miscompiled with -O2 and
+   caused ICE (segfault) building stage 2 libgcc.  */
+
+/* { dg-do run } */
+/* { dg-options "-O2" } */
+enum E
+{
+  TS_TYPED
+} a;
+int b, c;
+char d, e;
+
+__attribute__ ((cold, noipa, noinline)) void
+cold (int *, E, char *, int, char *)
+{
+  __builtin_trap ();
+}
+
+int *
+contains_struct_check (E x)
+{
+  if (a)
+cold (&b, x, &d, c, &e);
+  return &b;
+}
+
+struct vrange
+{
+  virtual void set_varying (int *);
+};
+
+struct int_range : vrange
+{
+  int *m_ranges[510];
+};
+
+__attribute__ ((noipa, noinline)) void
+vrange::set_varying (int *)
+{
+}
+
+struct Value_Range
+{
+  Value_Range (int *);
+  int_range m_irange;
+};
+
+

[PATCH] Use mark_block_for_update properly in insert_updated_phi_nodes_for

2022-06-28 Thread Richard Biener via Gcc-patches
This makes sure to use mark_block_for_update when adding a block for
rewriting in insert_updated_phi_nodes_for as otherwise stmt flags are not
initialized.

Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.

2022-06-28  Richard Biener  

* tree-into-ssa.cc (insert_updated_phi_nodes_for): Use
mark_block_for_update.
(update_ssa): Adjust.
---
 gcc/tree-into-ssa.cc | 16 +++-
 1 file changed, 7 insertions(+), 9 deletions(-)

diff --git a/gcc/tree-into-ssa.cc b/gcc/tree-into-ssa.cc
index 9631d8c6556..f9655ce1a28 100644
--- a/gcc/tree-into-ssa.cc
+++ b/gcc/tree-into-ssa.cc
@@ -3109,7 +3109,7 @@ release_ssa_name_after_update_ssa (tree name)
 
 
 /* Insert new PHI nodes to replace VAR.  DFS contains dominance
-   frontier information.  BLOCKS is the set of blocks to be updated.
+   frontier information.
 
This is slightly different than the regular PHI insertion
algorithm.  The value of UPDATE_FLAGS controls how PHI nodes for
@@ -3132,8 +3132,8 @@ release_ssa_name_after_update_ssa (tree name)
  names is not pruned.  PHI nodes are inserted at every IDF block.  */
 
 static void
-insert_updated_phi_nodes_for (tree var, bitmap_head *dfs, bitmap blocks,
-  unsigned update_flags)
+insert_updated_phi_nodes_for (tree var, bitmap_head *dfs,
+ unsigned update_flags)
 {
   basic_block entry;
   def_blocks *db;
@@ -3197,16 +3197,16 @@ insert_updated_phi_nodes_for (tree var, bitmap_head 
*dfs, bitmap blocks,
 
   /* FIXME, this is not needed if we are updating symbols.  We are
 already starting at the ENTRY block anyway.  */
-  bitmap_ior_into (blocks, pruned_idf);
   EXECUTE_IF_SET_IN_BITMAP (pruned_idf, 0, i, bi)
{
  edge e;
  edge_iterator ei;
  basic_block bb = BASIC_BLOCK_FOR_FN (cfun, i);
 
+ mark_block_for_update (bb);
  FOR_EACH_EDGE (e, ei, bb->preds)
if (e->src->index >= 0)
- bitmap_set_bit (blocks, e->src->index);
+ mark_block_for_update (e->src);
}
 
   insert_phi_nodes_for (var, pruned_idf, true);
@@ -3475,14 +3475,12 @@ update_ssa (unsigned update_flags)
  auto_sbitmap tmp (SBITMAP_SIZE (old_ssa_names));
  bitmap_copy (tmp, old_ssa_names);
  EXECUTE_IF_SET_IN_BITMAP (tmp, 0, i, sbi)
-   insert_updated_phi_nodes_for (ssa_name (i), dfs, blocks_to_update,
- update_flags);
+   insert_updated_phi_nodes_for (ssa_name (i), dfs, update_flags);
}
 
   symbols_to_rename.qsort (insert_updated_phi_nodes_compare_uids);
   FOR_EACH_VEC_ELT (symbols_to_rename, i, sym)
-   insert_updated_phi_nodes_for (sym, dfs, blocks_to_update,
- update_flags);
+   insert_updated_phi_nodes_for (sym, dfs, update_flags);
 
   FOR_EACH_BB_FN (bb, cfun)
bitmap_clear (&dfs[bb->index]);
-- 
2.35.3


Re: [PATCH] libstdc++-v3: check for openat

2022-06-28 Thread Alexandre Oliva via Gcc-patches
On Jun 28, 2022, Jonathan Wakely  wrote:

> I'll push this today.

Thanks!

> You can just use --enable-libstdcxx-debug

Thanks again ;-)

> Again, that test is *supposed* to return without creating the
> destination. It's testing the failure case.

Aha, and that's why one shouldn't debug something without looking at the
code to see what it's *supposed* to do ;-)

>> FAILED: default@libstdc++,27_io,filesystem,operations,copy_cc
>> FAILED: default@libstdc++,experimental,filesystem,operations,copy_cc
>> 
>> .../27_io/filesystem/operations/copy.cc:5[67]: void test01():
>> Assertion '!exists(to)' failed.

> I don't know what 5[67] means

Sorry for being unclear, it's just that the corresponding failing
asserts are at different lines in the two mentioned testcases, and I
tried to convey that fact with regexp notation.

> Which suggests to me another problem with mkstemp / nonexistent_path.

*lightbulb powers up*

Now it all makes sense.

It isn't *another* problem, that probably regressed when the mkstemp
patch went in and so it got out of my radar and thus out of the patchset
I used in subsequent test runs, but because of the way I use the testing
system, the baseline on top of which the patchset was installed was
still was still that of the previous nightly build, so I effectively
dropped the mkstemp fix.  And since when I joined this project this bug
had already been fixed, I didn't associate the regressions with the
patch.

Apologies for the noise.  Today's baseline, plus your _At_path patch and
my remove_all patch, is all clear.  Yay!

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 


[committed] libstdc++: Do not optimize away storing pathname if it's needed

2022-06-28 Thread Jonathan Wakely via Gcc-patches
Tested powerpc64le-linux, pushed to trunk.

-- >8 --

libstdc++-v3/ChangeLog:

* src/c++17/fs_dir.cc (_Dir::_Dir) [!_GLIBCXX_HAVE_OPENAT]:
Always store pathname if we don't have openat or unlinkat,
because the full path is needed to open sub-directories and
remove entries.
---
 libstdc++-v3/src/c++17/fs_dir.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libstdc++-v3/src/c++17/fs_dir.cc b/libstdc++-v3/src/c++17/fs_dir.cc
index 25b33baa875..025317b0a08 100644
--- a/libstdc++-v3/src/c++17/fs_dir.cc
+++ b/libstdc++-v3/src/c++17/fs_dir.cc
@@ -48,7 +48,7 @@ struct fs::_Dir : _Dir_base
[[maybe_unused]] bool filename_only, error_code& ec)
   : _Dir_base(fdcwd(), p.c_str(), skip_permission_denied, nofollow, ec)
   {
-#if _GLIBCXX_HAVE_DIRFD
+#if _GLIBCXX_HAVE_DIRFD && _GLIBCXX_HAVE_OPENAT && _GLIBCXX_HAVE_UNLINKAT
 if (filename_only)
   return; // Do not store path p when we aren't going to use it.
 #endif
-- 
2.36.1



Re: [PATCH][AArch64] Implement ACLE Data Intrinsics

2022-06-28 Thread Andre Vieira (lists) via Gcc-patches


On 17/06/2022 11:54, Richard Sandiford wrote:

"Andre Vieira (lists)"  writes:

Hi,

This patch adds support for the ACLE Data Intrinsics to the AArch64 port.

Bootstrapped and regression tested on aarch64-none-linux.

OK for trunk?

Sorry for the slow review.

No worries :)



+{\
+  size_t size = sizeof (TYPE) * __CHAR_BIT__;\
+  rotate = rotate % size;\
+  return value >> rotate | value << (size - rotate); \

This runs into UB for rotate == 0.
I assume it's because of the value << size no? I added a modulo, I 
assume it's legal to shift by 0?


This OK?
diff --git a/gcc/config/aarch64/aarch64-builtins.cc 
b/gcc/config/aarch64/aarch64-builtins.cc
index 
e0a741ac663188713e21f457affa57217d074783..69f1fb3604a481fa378d105cf3ee98edec1ba619
 100644
--- a/gcc/config/aarch64/aarch64-builtins.cc
+++ b/gcc/config/aarch64/aarch64-builtins.cc
@@ -613,6 +613,12 @@ enum aarch64_builtins
   AARCH64_LS64_BUILTIN_ST64B,
   AARCH64_LS64_BUILTIN_ST64BV,
   AARCH64_LS64_BUILTIN_ST64BV0,
+  AARCH64_REV16,
+  AARCH64_REV16L,
+  AARCH64_REV16LL,
+  AARCH64_RBIT,
+  AARCH64_RBITL,
+  AARCH64_RBITLL,
   AARCH64_BUILTIN_MAX
 };
 
@@ -1664,10 +1670,41 @@ aarch64_init_ls64_builtins (void)
   = aarch64_general_add_builtin (data[i].name, data[i].type, data[i].code);
 }
 
+static void
+aarch64_init_data_intrinsics (void)
+{
+  tree uint32_fntype = build_function_type_list (uint32_type_node,
+uint32_type_node, NULL_TREE);
+  tree ulong_fntype = build_function_type_list (long_unsigned_type_node,
+   long_unsigned_type_node,
+   NULL_TREE);
+  tree uint64_fntype = build_function_type_list (uint64_type_node,
+uint64_type_node, NULL_TREE);
+  aarch64_builtin_decls[AARCH64_REV16]
+= aarch64_general_add_builtin ("__builtin_aarch64_rev16", uint32_fntype,
+  AARCH64_REV16);
+  aarch64_builtin_decls[AARCH64_REV16L]
+= aarch64_general_add_builtin ("__builtin_aarch64_rev16l", ulong_fntype,
+  AARCH64_REV16L);
+  aarch64_builtin_decls[AARCH64_REV16LL]
+= aarch64_general_add_builtin ("__builtin_aarch64_rev16ll", uint64_fntype,
+  AARCH64_REV16LL);
+  aarch64_builtin_decls[AARCH64_RBIT]
+= aarch64_general_add_builtin ("__builtin_aarch64_rbit", uint32_fntype,
+  AARCH64_RBIT);
+  aarch64_builtin_decls[AARCH64_RBITL]
+= aarch64_general_add_builtin ("__builtin_aarch64_rbitl", ulong_fntype,
+  AARCH64_RBITL);
+  aarch64_builtin_decls[AARCH64_RBITLL]
+= aarch64_general_add_builtin ("__builtin_aarch64_rbitll", uint64_fntype,
+  AARCH64_RBITLL);
+}
+
 /* Implement #pragma GCC aarch64 "arm_acle.h".  */
 void
 handle_arm_acle_h (void)
 {
+  aarch64_init_data_intrinsics ();
   if (TARGET_LS64)
 aarch64_init_ls64_builtins ();
 }
@@ -2393,6 +2430,40 @@ aarch64_expand_builtin_memtag (int fcode, tree exp, rtx 
target)
   emit_insn (pat);
   return target;
 }
+/* Function to expand an expression EXP which calls one of the ACLE Data
+   Intrinsic builtins FCODE with the result going to TARGET.  */
+static rtx
+aarch64_expand_builtin_data_intrinsic (unsigned int fcode, tree exp, rtx 
target)
+{
+  expand_operand ops[2];
+  machine_mode mode = GET_MODE (target);
+  create_output_operand (&ops[0], target, mode);
+  create_input_operand (&ops[1], expand_normal (CALL_EXPR_ARG (exp, 0)), mode);
+  enum insn_code icode;
+  switch (fcode)
+{
+case AARCH64_REV16:
+case AARCH64_REV16L:
+case AARCH64_REV16LL:
+  if (mode == SImode)
+   icode = CODE_FOR_aarch64_rev16si;
+  else
+   icode = CODE_FOR_aarch64_rev16di;
+  break;
+case AARCH64_RBIT:
+case AARCH64_RBITL:
+case AARCH64_RBITLL:
+  if (mode == SImode)
+   icode = CODE_FOR_aarch64_rbitsi;
+  else
+   icode = CODE_FOR_aarch64_rbitdi;
+  break;
+default:
+  gcc_unreachable ();
+}
+  expand_insn (icode, 2, ops);
+  return target;
+}
 
 /* Expand an expression EXP as fpsr or fpcr setter (depending on
UNSPEC) using MODE.  */
@@ -2551,6 +2622,9 @@ aarch64_general_expand_builtin (unsigned int fcode, tree 
exp, rtx target,
   if (fcode >= AARCH64_MEMTAG_BUILTIN_START
   && fcode <= AARCH64_MEMTAG_BUILTIN_END)
 return aarch64_expand_builtin_memtag (fcode, exp, target);
+  if (fcode >= AARCH64_REV16
+  && fcode <= AARCH64_RBITLL)
+return aarch64_expand_builtin_data_intrinsic (fcode, exp, target);
 
   gcc_unreachable ();
 }
diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index 
acec8c1146765c0fac73c15351853324b8f03209..ef0aed25c6b26eff61f9f6030dc5921

[FYI, PATCH] Add TFLAGS to gcc's GCC_FOR_TARGET

2022-06-28 Thread Alexandre Oliva via Gcc-patches


When the GCC build runs GCC_FOR_TARGET, e.g. for selftests or for
dumping specs, it doesn't use TFLAGS in non-bootstrap scenarios.  This
patch arranges for TFLAGS to be passed from the top level down to gcc
in GCC_FOR_TARGET in this case.

Another issue related with TFLAGS fixed herein is that there's no easy
way to add a TFLAGS to GCC_FOR_TARGET when running "make gnatlib"
within the gcc directory.  Overriding all of GCC_FOR_TARGET is
somewhat cumbersome, so I'm adding TFLAGS support to gcc/Makefile.in,
getting it added to GCC_FOR_TARGET, as it would when passed down from
the top level.

Regstrapped on x86_64-linux-gnu.  I'm checking this in.


for  ChangeLog

* Makefile.tpl (HOST_EXPORTS): Add TFLAGS to GCC_FOR_TARGET.
(EXTRA_GCC_FLAGS): Likewise.
* Makefile.in: Rebuilt.

for  gcc/ChangeLog

* Makefile.in (TFLAGS): New.
(GCC_FOR_TARGET): Add TFLAGS.
(FLAGS_TO_PASS): Pass TFLAGS down.
---
 Makefile.in |4 ++--
 Makefile.tpl|4 ++--
 gcc/Makefile.in |6 +-
 3 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/Makefile.in b/Makefile.in
index 593495e16503a..13ee95a2602ab 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -222,7 +222,7 @@ HOST_EXPORTS = \
AR_FOR_TARGET="$(AR_FOR_TARGET)"; export AR_FOR_TARGET; \
AS_FOR_TARGET="$(AS_FOR_TARGET)"; export AS_FOR_TARGET; \
DSYMUTIL_FOR_TARGET="$(DSYMUTIL_FOR_TARGET)"; export 
DSYMUTIL_FOR_TARGET; \
-   GCC_FOR_TARGET="$(GCC_FOR_TARGET)"; export GCC_FOR_TARGET; \
+   GCC_FOR_TARGET="$(GCC_FOR_TARGET) $$TFLAGS"; export GCC_FOR_TARGET; \
LD_FOR_TARGET="$(LD_FOR_TARGET)"; export LD_FOR_TARGET; \
NM_FOR_TARGET="$(NM_FOR_TARGET)"; export NM_FOR_TARGET; \
OBJDUMP_FOR_TARGET="$(OBJDUMP_FOR_TARGET)"; export OBJDUMP_FOR_TARGET; \
@@ -1047,7 +1047,7 @@ TARGET_FLAGS_TO_PASS = $(BASE_FLAGS_TO_PASS) 
$(EXTRA_TARGET_FLAGS)
 # The BUILD_* variables are a special case, which are used for the gcc
 # cross-building scheme.
 EXTRA_GCC_FLAGS = \
-   "GCC_FOR_TARGET=$(GCC_FOR_TARGET)" \
+   "GCC_FOR_TARGET=$(GCC_FOR_TARGET) $$TFLAGS" \
"`echo 'STMP_FIXPROTO=$(STMP_FIXPROTO)' | sed -e 
s'/[^=][^=]*=$$/XFOO=/'`" \
"`echo 'LIMITS_H_TEST=$(LIMITS_H_TEST)' | sed -e 
s'/[^=][^=]*=$$/XFOO=/'`"
 
diff --git a/Makefile.tpl b/Makefile.tpl
index ef58fac2b9a8b..ba0727153a9b8 100644
--- a/Makefile.tpl
+++ b/Makefile.tpl
@@ -225,7 +225,7 @@ HOST_EXPORTS = \
AR_FOR_TARGET="$(AR_FOR_TARGET)"; export AR_FOR_TARGET; \
AS_FOR_TARGET="$(AS_FOR_TARGET)"; export AS_FOR_TARGET; \
DSYMUTIL_FOR_TARGET="$(DSYMUTIL_FOR_TARGET)"; export 
DSYMUTIL_FOR_TARGET; \
-   GCC_FOR_TARGET="$(GCC_FOR_TARGET)"; export GCC_FOR_TARGET; \
+   GCC_FOR_TARGET="$(GCC_FOR_TARGET) $$TFLAGS"; export GCC_FOR_TARGET; \
LD_FOR_TARGET="$(LD_FOR_TARGET)"; export LD_FOR_TARGET; \
NM_FOR_TARGET="$(NM_FOR_TARGET)"; export NM_FOR_TARGET; \
OBJDUMP_FOR_TARGET="$(OBJDUMP_FOR_TARGET)"; export OBJDUMP_FOR_TARGET; \
@@ -801,7 +801,7 @@ TARGET_FLAGS_TO_PASS = $(BASE_FLAGS_TO_PASS) 
$(EXTRA_TARGET_FLAGS)
 # The BUILD_* variables are a special case, which are used for the gcc
 # cross-building scheme.
 EXTRA_GCC_FLAGS = \
-   "GCC_FOR_TARGET=$(GCC_FOR_TARGET)" \
+   "GCC_FOR_TARGET=$(GCC_FOR_TARGET) $$TFLAGS" \
"`echo 'STMP_FIXPROTO=$(STMP_FIXPROTO)' | sed -e 
s'/[^=][^=]*=$$/XFOO=/'`" \
"`echo 'LIMITS_H_TEST=$(LIMITS_H_TEST)' | sed -e 
s'/[^=][^=]*=$$/XFOO=/'`"
 
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 97e5450ecb593..27ac641270f99 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -146,8 +146,11 @@ endif
 # CFLAGS is for the user to override to, e.g., do a cross build with -O2.
 # TCFLAGS is used for compilations with the GCC just built.
 # T_CFLAGS is used for all compilations and is overridden by t-* files.
+# TFLAGS is also for the user to override, passed down from the top-level
+# Makefile.  It is used for all compilations,
 T_CFLAGS =
 TCFLAGS =
+TFLAGS =
 CFLAGS = @CFLAGS@
 CXXFLAGS = @CXXFLAGS@
 LDFLAGS = @LDFLAGS@
@@ -457,7 +460,7 @@ T_STDINT_GCC_H = $(srcdir)/ginclude/stdint-gcc.h
 # The GCC to use for compiling crt*.o.
 # Usually the one we just built.
 # Don't use this as a dependency--use $(GCC_PASSES).
-GCC_FOR_TARGET = $(STAGE_CC_WRAPPER) ./xgcc -B./ -B$(build_tooldir)/bin/ 
-isystem $(build_tooldir)/include -isystem $(build_tooldir)/sys-include 
-L$(objdir)/../ld
+GCC_FOR_TARGET = $(STAGE_CC_WRAPPER) ./xgcc -B./ -B$(build_tooldir)/bin/ 
-isystem $(build_tooldir)/include -isystem $(build_tooldir)/sys-include 
-L$(objdir)/../ld $(TFLAGS)
 
 # Set if the compiler was configured with --with-build-sysroot.
 SYSROOT_CFLAGS_FOR_TARGET = @SYSROOT_CFLAGS_FOR_TARGET@
@@ -1193,6 +1196,7 @@ FLAGS_TO_PASS = \
"MAKEINFOFLAGS=$(MAKEINFOFLAGS)" \
"MAKEOVERRIDES=" \
"SHELL=$(SHELL)" \
+   "TFLAGS=$(TFLAGS)" \
"exeext=$(exeext)" \
"build_exeext=$(build_exeext)

Re: [PATCH] Remove legacy EVRP code.

2022-06-28 Thread Aldy Hernandez via Gcc-patches
Since Andrew, Jeff, and Richi have all agreed, I have pushed the patch.

Thanks.
Aldy

On Tue, Jun 28, 2022 at 9:37 AM Richard Biener
 wrote:
>
> On Mon, Jun 27, 2022 at 9:04 PM Aldy Hernandez  wrote:
> >
> > With DOM converted to ranger, there are no longer any uses of the EVRP
> > engine.  For that matter, we haven't used the legacy mode in quite a
> > while, so I think it's safe to remove any associated code.
> >
> > There are some methods in vr_values which should now be private, but I
> > didn't bother changing them, as most of the vr_values class will be
> > removed when VRP1 is converted to ranger.
> >
> > Does anyone have any issues with me pushing this?
>
> Fine with me.
>
> > gcc/ChangeLog:
> >
> > * Makefile.in: Remove gimple-ssa-evrp.o and 
> > gimple-ssa-evrp-analyze.o.
> > * flag-types.h (enum evrp_mode): Remove.
> > * params.opt: Remove --param=evrp-mode.
> > * tree-vrp.cc (make_pass_early_vrp): New.
> > (pass_vrp::execute): Call early VRP instance.
> > * gimple-ssa-evrp-analyze.cc: Removed.
> > * gimple-ssa-evrp-analyze.h: Removed.
> > * gimple-ssa-evrp.cc: Removed.
> > ---
> >  gcc/Makefile.in |   2 -
> >  gcc/flag-types.h|   9 -
> >  gcc/gimple-ssa-evrp-analyze.cc  | 456 
> >  gcc/gimple-ssa-evrp-analyze.h   |  58 
> >  gcc/gimple-ssa-evrp.cc  | 395 ---
> >  gcc/params.opt  |  19 --
> >  gcc/testsuite/g++.dg/pr100774.C |   2 +-
> >  gcc/testsuite/gcc.dg/pr100781.c |   2 +-
> >  gcc/tree-vrp.cc |  34 ++-
> >  9 files changed, 31 insertions(+), 946 deletions(-)
> >  delete mode 100644 gcc/gimple-ssa-evrp-analyze.cc
> >  delete mode 100644 gcc/gimple-ssa-evrp-analyze.h
> >  delete mode 100644 gcc/gimple-ssa-evrp.cc
> >
> > diff --git a/gcc/Makefile.in b/gcc/Makefile.in
> > index b6dcc45a58a..86257a8b84f 100644
> > --- a/gcc/Makefile.in
> > +++ b/gcc/Makefile.in
> > @@ -1413,8 +1413,6 @@ OBJS = \
> > gimple-range-infer.o \
> > gimple-range-trace.o \
> > gimple-ssa-backprop.o \
> > -   gimple-ssa-evrp.o \
> > -   gimple-ssa-evrp-analyze.o \
> > gimple-ssa-isolate-paths.o \
> > gimple-ssa-nonnull-compare.o \
> > gimple-ssa-split-paths.o \
> > diff --git a/gcc/flag-types.h b/gcc/flag-types.h
> > index 2c8498169e0..a11f99af887 100644
> > --- a/gcc/flag-types.h
> > +++ b/gcc/flag-types.h
> > @@ -479,15 +479,6 @@ enum threader_debug
> >THREADER_DEBUG_ALL = 1
> >  };
> >
> > -/* EVRP mode.  */
> > -enum evrp_mode
> > -{
> > -  EVRP_MODE_RVRP_ONLY,
> > -  EVRP_MODE_EVRP_ONLY,
> > -  EVRP_MODE_EVRP_FIRST,
> > -  EVRP_MODE_RVRP_FIRST
> > -};
> > -
> >  /* VRP modes.  */
> >  enum vrp_mode
> >  {
> > diff --git a/gcc/gimple-ssa-evrp-analyze.cc b/gcc/gimple-ssa-evrp-analyze.cc
> > deleted file mode 100644
> > index 82142db7976..000
> > --- a/gcc/gimple-ssa-evrp-analyze.cc
> > +++ /dev/null
> > @@ -1,456 +0,0 @@
> > -/* Support routines for Value Range Propagation (VRP).
> > -   Copyright (C) 2005-2022 Free Software Foundation, Inc.
> > -
> > -This file is part of GCC.
> > -
> > -GCC is free software; you can redistribute it and/or modify
> > -it under the terms of the GNU General Public License as published by
> > -the Free Software Foundation; either version 3, or (at your option)
> > -any later version.
> > -
> > -GCC is distributed in the hope that it will be useful,
> > -but WITHOUT ANY WARRANTY; without even the implied warranty of
> > -MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > -GNU General Public License for more details.
> > -
> > -You should have received a copy of the GNU General Public License
> > -along with GCC; see the file COPYING3.  If not see
> > -.  */
> > -
> > -#include "config.h"
> > -#include "system.h"
> > -#include "coretypes.h"
> > -#include "backend.h"
> > -#include "tree.h"
> > -#include "gimple.h"
> > -#include "tree-pass.h"
> > -#include "ssa.h"
> > -#include "gimple-pretty-print.h"
> > -#include "cfganal.h"
> > -#include "gimple-iterator.h"
> > -#include "gimple-fold.h"
> > -#include "tree-eh.h"
> > -#include "tree-cfg.h"
> > -#include "tree-ssa-loop-manip.h"
> > -#include "tree-ssa-loop.h"
> > -#include "cfgloop.h"
> > -#include "tree-scalar-evolution.h"
> > -#include "tree-ssa-propagate.h"
> > -#include "alloc-pool.h"
> > -#include "domwalk.h"
> > -#include "tree-cfgcleanup.h"
> > -#include "vr-values.h"
> > -#include "gimple-ssa-evrp-analyze.h"
> > -
> > -evrp_range_analyzer::evrp_range_analyzer (bool update_global_ranges)
> > -  : stack (10), m_update_global_ranges (update_global_ranges)
> > -{
> > -  edge e;
> > -  edge_iterator ei;
> > -  basic_block bb;
> > -  FOR_EACH_BB_FN (bb, cfun)
> > -{
> > -  bb->flags &= ~BB_VISITED;
> > -  FOR_EACH_EDGE (e, ei, bb->preds)
> > -e->flags |= EDGE_EXECUTABLE;
> > -}
> > -}
> > -
> > -/* Push an 

[PATCH] Speedup loop splitting SSA update

2022-06-28 Thread Richard Biener via Gcc-patches
Since we never process loops with inner loops that have been split
we can delay SSA update until after the pass is done with the whole
loop, avoiding the O(function-size) work associated with it.

Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.

2022-06-28  Richard Biener  

* tree-ssa-loop-split.cc (fix_loop_bb_probability): Do not
call update_ssa.
---
 gcc/tree-ssa-loop-split.cc | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/gcc/tree-ssa-loop-split.cc b/gcc/tree-ssa-loop-split.cc
index d61bad5ba47..bccf621493b 100644
--- a/gcc/tree-ssa-loop-split.cc
+++ b/gcc/tree-ssa-loop-split.cc
@@ -491,8 +491,6 @@ static void
 fix_loop_bb_probability (class loop *loop1, class loop *loop2, edge true_edge,
 edge false_edge)
 {
-  update_ssa (TODO_update_ssa);
-
   /* Proportion first loop's bb counts except those dominated by true
  branch to avoid drop 1s down.  */
   basic_block *bbs1, *bbs2;
@@ -1668,7 +1666,8 @@ tree_ssa_split_loops (void)
   if (loop->aux)
{
  /* If any of our inner loops was split, don't split us,
-and mark our containing loop as having had splits as well.  */
+and mark our containing loop as having had splits as well.
+This allows for delaying SSA update.  */
  loop_outer (loop)->aux = loop;
  continue;
}
-- 
2.35.3


[PATCH] testsuite/C++: suppress filename canonicalization in module tests

2022-06-28 Thread Jan Beulich via Gcc-patches
The pathname underneath gcm.cache/ is determined from the effective name
used for the main input file of a particular module. When modules are
built, no canonicalization occurs for the main input file. Hence the
module file wouldn't be found if a different (the canonicalized) file
name was used when importing that same module. (This is an effect of
importing happening in the preprocessor, just like #include handling.)

Since it doesn't look easy to make module generation use libcpp's
maybe_shorter_path() (in fact I'd consider this a layering violation,
while cloning the logic would - at least in principle - be prone to both
going out of sync), simply suppress system header path canonicalization
for the respective tests.

gcc/testsuite/

* g++.dg/modules/alias-1_b.C: Add -fno-canonical-system-headers.
* g++.dg/modules/alias-1_d.C: Likewise.
* g++.dg/modules/alias-1_e.C: Likewise.
* g++.dg/modules/alias-1_f.C: Likewise.
* g++.dg/modules/cpp-6_c.C: Likewise.
* g++.dg/modules/dir-only-2_b.C: Likewise.
---
Strictly speaking it could be necessary to also suppress
canonicalization when generating the modules, but for now they're self-
contained, i.e. don't include any "real" system headers. IOW at the
moment the tests aren't susceptible to the issue at generation time.

--- a/gcc/testsuite/g++.dg/modules/alias-1_b.C
+++ b/gcc/testsuite/g++.dg/modules/alias-1_b.C
@@ -1,4 +1,4 @@
-// { dg-additional-options "-fmodules-ts -fdump-lang-module -isystem [srcdir]" 
}
+// { dg-additional-options "-fmodules-ts -fdump-lang-module -isystem [srcdir] 
-fno-canonical-system-headers" }
 
 // Alias at the header file.  We have one CMI file
 import "alias-1_a.H";
--- a/gcc/testsuite/g++.dg/modules/alias-1_d.C
+++ b/gcc/testsuite/g++.dg/modules/alias-1_d.C
@@ -1,4 +1,4 @@
-// { dg-additional-options "-fmodules-ts -isystem [srcdir]" }
+// { dg-additional-options "-fmodules-ts -isystem [srcdir] 
-fno-canonical-system-headers" }
 // { dg-module-cmi kevin }
 
 export module kevin;
--- a/gcc/testsuite/g++.dg/modules/alias-1_e.C
+++ b/gcc/testsuite/g++.dg/modules/alias-1_e.C
@@ -1,4 +1,4 @@
-// { dg-additional-options "-fmodules-ts -isystem [srcdir]" }
+// { dg-additional-options "-fmodules-ts -isystem [srcdir] 
-fno-canonical-system-headers" }
 
 import bob;
 import kevin;
--- a/gcc/testsuite/g++.dg/modules/alias-1_f.C
+++ b/gcc/testsuite/g++.dg/modules/alias-1_f.C
@@ -1,4 +1,4 @@
-// { dg-additional-options "-fmodules-ts -fdump-lang-module -isystem [srcdir]" 
}
+// { dg-additional-options "-fmodules-ts -fdump-lang-module -isystem [srcdir] 
-fno-canonical-system-headers" }
 
 import kevin;
 import bob;
--- a/gcc/testsuite/g++.dg/modules/cpp-6_c.C
+++ b/gcc/testsuite/g++.dg/modules/cpp-6_c.C
@@ -1,5 +1,5 @@
 // { dg-do preprocess }
-// { dg-additional-options "-fmodules-ts -isystem [srcdir]" }
+// { dg-additional-options "-fmodules-ts -isystem [srcdir] 
-fno-canonical-system-headers" }
 
 #define empty
 #define nop(X) X
--- a/gcc/testsuite/g++.dg/modules/dir-only-2_b.C
+++ b/gcc/testsuite/g++.dg/modules/dir-only-2_b.C
@@ -1,5 +1,5 @@
 // { dg-do preprocess }
-// { dg-additional-options "-fmodules-ts -fdirectives-only -isystem [srcdir]" }
+// { dg-additional-options "-fmodules-ts -fdirectives-only -isystem [srcdir] 
-fno-canonical-system-headers" }
 // a comment
 module; // line
 frob


[PATCH] testsuite/C++: cope with IPv6 being unavailable

2022-06-28 Thread Jan Beulich via Gcc-patches
When IPv6 is disabled in the kernel, the error message coming back from
Cody::OpenInet6() is different from the sole so far expected one.

gcc/testsuite/

* g++.dg/modules/bad-mapper-3.C: Relax failure pattern.

--- a/gcc/testsuite/g++.dg/modules/bad-mapper-3.C
+++ b/gcc/testsuite/g++.dg/modules/bad-mapper-3.C
@@ -1,6 +1,6 @@
 //  { dg-additional-options "-fmodules-ts -fmodule-mapper=localhost:172477262" 
}
 import unique3.bob;
-// { dg-error {failed connecting mapper 'localhost:172477262'} "" { target 
*-*-* } 0 }
+// { dg-error {failed (socket|connecting) mapper 'localhost:172477262'} "" { 
target *-*-* } 0 }
 // { dg-prune-output "fatal error:" }
 // { dg-prune-output "failed to read" }
 // { dg-prune-output "compilation terminated" }


Re: [PATCH] Support multilib-aware target lib flags self-specs overriding

2022-06-28 Thread Alexandre Oliva via Gcc-patches
On Jun  3, 2022, Alexandre Oliva  wrote:

> On Jun  1, 2022, Hans-Peter Nilsson  wrote:

>> -fmultiflags?

> That works for me.  I favored -multiflags slightly, because the intended
> use is for it to stand for other -m flags, but --multiflags AKA
> -fmultiflags will do as well.


> Now, is there interest in this feature?  (As in, does it any make sense
> for me to post a revised patch, or should I keep it downstream?)

FTR, here's the patch I ended up with, adjusted to use -fmultiflags.


Support multilib-aware target lib flags self-specs overriding

This patch introduces -fmultiflags, short for multilib TFLAGS, as an
option that does nothing by default, but that can be added to TFLAGS
and mapped to useful options by driver self-specs.

Regstrapped on x86_64-linux-gnu.  Posted mainly FTR, but...  I wouldn't
mind putting it in, so...  Ok to install?  ;-)


for  gcc/ChangeLog

* common.opt (fmultiflags): New.
* doc/invoke.texi: Document it.
* gcc.cc (driver_self_specs): Discard it.
* opts.cc (common_handle_option): Ignore it in the driver.
---
 gcc/common.opt  |4 
 gcc/doc/invoke.texi |   30 +-
 gcc/gcc.cc  |6 +-
 gcc/opts.cc |4 
 4 files changed, 42 insertions(+), 2 deletions(-)

diff --git a/gcc/common.opt b/gcc/common.opt
index e7a51e882bade..814966c4562fe 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -2177,6 +2177,10 @@ fmove-loop-stores
 Common Var(flag_move_loop_stores) Optimization
 Move stores out of loops.
 
+fmultiflags
+Common Driver
+Building block for specs-based multilib-aware TFLAGS.
+
 fdce
 Common Var(flag_dce) Init(1) Optimization
 Use the RTL dead code elimination pass.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index bde59ff047249..f9c53df37b28b 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -725,7 +725,7 @@ Objective-C and Objective-C++ Dialects}.
 -flto-report  -flto-report-wpa  -fmem-report-wpa @gol
 -fmem-report  -fpre-ipa-mem-report  -fpost-ipa-mem-report @gol
 -fopt-info  -fopt-info-@var{options}@r{[}=@var{file}@r{]} @gol
--fprofile-report @gol
+-fmultiflags  -fprofile-report @gol
 -frandom-seed=@var{string}  -fsched-verbose=@var{n} @gol
 -fsel-sched-verbose  -fsel-sched-dump-cfg  -fsel-sched-pipelining-verbose @gol
 -fstats  -fstack-usage  -ftime-report  -ftime-report-details @gol
@@ -18927,6 +18927,34 @@ allocation for the WPA phase only.
 Makes the compiler print some statistics about permanent memory
 allocation before or after interprocedural optimization.
 
+@item -fmultiflags
+@opindex fmultiflags
+This option enables multilib-aware @code{TFLAGS} to be used to build
+target libraries with options different from those the compiler is
+configured to use by default, through the use of specs (@xref{Spec
+Files}) set up by compiler internals, by the target, or by builders at
+configure time.
+
+Like @code{TFLAGS}, this allows the target libraries to be built for
+portable baseline environments, while the compiler defaults to more
+demanding ones.  That's useful because users can easily override the
+defaults the compiler is configured to use to build their own programs,
+if the defaults are not ideal for their target environment, whereas
+rebuilding the runtime libraries is usually not as easy or desirable.
+
+Unlike @code{TFLAGS}, the use of specs enables different flags to be
+selected for different multilibs.  The way to accomplish that is to
+build with @samp{make TFLAGS=-fmultiflags}, after configuring
+@samp{--with-specs=%@{fmultiflags:...@}}.
+
+This option is discarded by the driver once it's done processing driver
+self spec.
+
+It is also useful to check that @code{TFLAGS} are being used to build
+all target libraries, by configuring a non-bootstrap compiler
+@samp{--with-specs='%@{!fmultiflags:%emissing TFLAGS@}'} and building
+the compiler and target libraries.
+
 @item -fprofile-report
 @opindex fprofile-report
 Makes the compiler print some statistics about consistency of the
diff --git a/gcc/gcc.cc b/gcc/gcc.cc
index 5cbb38560b266..24d3544e68140 100644
--- a/gcc/gcc.cc
+++ b/gcc/gcc.cc
@@ -1347,7 +1347,11 @@ static const char *const multilib_defaults_raw[] = 
MULTILIB_DEFAULTS;
 
 static const char *const driver_self_specs[] = {
   "%{fdump-final-insns:-fdump-final-insns=.} %report_bug = value;
   break;
 
+case OPT_fmultiflags:
+  gcc_checking_assert (lang_mask == CL_DRIVER);
+  break;
+
 default:
   /* If the flag was handled in a standard way, assume the lack of
 processing here is intentional.  */


-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 


[x86 PATCH] Double word logical operation clean-ups in i386.md.

2022-06-28 Thread Roger Sayle

Hi Uros,
As you've requested/suggested, here's a patch that tidies up and
unifies doubleword handling in i386.md; converting all doubleword
splitters for logic operations to post-reload form, generalizing
their define_insn_and_split templates to  form (supporting
TARGET_64BIT ? TImode : DImode), and where required tweaking the
corresponding expanders to use SDWIM to support TImode doubleword
operations.  These changes incorporate your feedback from
https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596205.html
where I included many/several of these clean-ups, in a patch to
add a new optimization.  I agree, it's better to split these out
(this patch), and I'll resubmit the (smaller) optimization patch
as a follow-up.

This patch has been tested on x86_64-pc-linux-gnu with make bootstrap
and make -k check, both with and without --target_board=unix{-m32},
with no new failures.  Ok for mainline?


2022-06-28  Roger Sayle  

gcc/ChangeLog
* config/i386/i386.md (general_szext_operand): Add TImode
support using x86_64_hilo_general_operand predicate.
(*cmp_doubleword): Use x86_64_hilo_general_operand predicate.
(*add3_doubleword): Improved optimization of zero addition.
(and3): Use SDWIM mode iterator to add support for double
word bit-wise AND in TImode.  Use force_reg when double word
immediate operand isn't x86_64_hilo_general_operand.
(and3_doubleword): Generalized from anddi3_doubleword and
converted into a post-reload splitter.
(*andn3_doubleword): Generalized from *andndi3_doubleword.
(define_split): Generalize DImode splitters for andn to .
One splitter for TARGET_BMI, the other for !TARGET_BMI.
(3): Use SDWIM mode iterator to add suppport for
double word bit-wise XOR and bit-wise IOR in TImode.  Use
force_reg when double word immediate operand isn't
x86_64_hilo_general_operand.
(*di3_doubleword): Generalized from di3_doubleword.
(one_cmpl2): Use SDWIM mode iterator to add support for
double word bit-wise NOT in TImode.
(one_cmpl2_doubleword): Generalize from one_cmpldi2_doubleword
and converted into a post-reload splitter.


Thanks again,
Roger
--

diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index dd173f7..11d3756 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -1192,7 +1192,8 @@
[(QI "general_operand")
 (HI "general_operand")
 (SI "x86_64_szext_general_operand")
-(DI "x86_64_szext_general_operand")])
+(DI "x86_64_szext_general_operand")
+(TI "x86_64_hilo_general_operand")])
 
 (define_mode_attr nonmemory_szext_operand
[(QI "nonmemory_operand")
@@ -1509,7 +1510,7 @@
 (define_insn_and_split "*cmp_doubleword"
   [(set (reg:CCZ FLAGS_REG)
(compare:CCZ (match_operand: 0 "nonimmediate_operand")
-(match_operand: 1 "x86_64_general_operand")))]
+(match_operand: 1 "x86_64_hilo_general_operand")))]
   "ix86_pre_reload_split ()"
   "#"
   "&& 1"
@@ -5802,7 +5803,12 @@
   split_double_mode (mode, &operands[0], 3, &operands[0], &operands[3]);
   if (operands[2] == const0_rtx)
 {
-  ix86_expand_binary_operator (PLUS, mode, &operands[3]);
+  if (operands[5] != const0_rtx)
+   ix86_expand_binary_operator (PLUS, mode, &operands[3]);
+  else if (!rtx_equal_p (operands[3], operands[4]))
+   emit_move_insn (operands[3], operands[4]);
+  else
+   emit_note (NOTE_INSN_DELETED);
   DONE;
 }
 })
@@ -9846,19 +9852,22 @@
 ;; it should be done with splitters.
 
 (define_expand "and3"
-  [(set (match_operand:SWIM1248x 0 "nonimmediate_operand")
-   (and:SWIM1248x (match_operand:SWIM1248x 1 "nonimmediate_operand")
-  (match_operand:SWIM1248x 2 "")))]
+  [(set (match_operand:SDWIM 0 "nonimmediate_operand")
+   (and:SDWIM (match_operand:SDWIM 1 "nonimmediate_operand")
+  (match_operand:SDWIM 2 "")))]
   ""
 {
   machine_mode mode = mode;
 
-  if (mode == DImode && !TARGET_64BIT)
-;
-  else if (const_int_operand (operands[2], mode)
-  && register_operand (operands[0], mode)
-  && !(TARGET_ZERO_EXTEND_WITH_AND
-   && optimize_function_for_speed_p (cfun)))
+  if (GET_MODE_SIZE (mode) > UNITS_PER_WORD
+  && !x86_64_hilo_general_operand (operands[2], mode))
+operands[2] = force_reg (mode, operands[2]);
+
+  if (GET_MODE_SIZE (mode) <= UNITS_PER_WORD
+  && const_int_operand (operands[2], mode)
+  && register_operand (operands[0], mode)
+  && !(TARGET_ZERO_EXTEND_WITH_AND
+  && optimize_function_for_speed_p (cfun)))
 {
   unsigned HOST_WIDE_INT ival = UINTVAL (operands[2]);
 
@@ -9880,34 +9889,44 @@
   DONE;
 })
 
-(define_insn_and_split "*anddi3_doubleword"
-  [(set (match_operand:DI 0 "nonimmediate_operand")
-   (and:DI
-(match_operand:DI 1 "nonimmediate_operand")
-  

Re: [PATCH, libgomp] Fix chunk_size<1 for dynamic schedule

2022-06-28 Thread Jakub Jelinek via Gcc-patches
On Thu, Jun 23, 2022 at 11:47:59PM +0800, Chung-Lin Tang wrote:
> with the way that chunk_size < 1 is handled for gomp_iter_dynamic_next:
> 
> (1) chunk_size <= -1: wraps into large unsigned value, seems to work though.
> (2) chunk_size == 0:  infinite loop
> 
> The (2) behavior is obviously not desired. This patch fixes this by changing

Why?  It is a user error, undefined behavior, we shouldn't slow down valid
code for users who don't bother reading the standard.

E.g. OpenMP 5.1 [132:14] says clearly:
"chunk_size must be a loop invariant integer expression with a positive
value."
and omp_set_schedule for chunk_size < 1 should use a default value (which it
does).

For OMP_SCHEDULE the standard says it is implementation-defined what happens
if the format isn't the specified one, so I guess the env.c change
could be acceptable (though without it it is fine too), but the
loop.c change is wrong.  Note, if the loop.c change would be ok, you'd
need to also change loop_ull.c too.

Jakub



[PATCH] lto: pass -pthread to AM_LDFLAGS [PR 106118]

2022-06-28 Thread Pekka Seppänen
Move -pthread from configure.ac to Makefile.in so that it is passed to 
AM_LDFLAGS.


lto-plugin/ChangeLog:

* configure.ac: Move -pthread from here...
* Makefile.am: ...to here.
* configure: Regenerate.
* Makefile.in: Likewise.
---
 lto-plugin/Makefile.am  | 3 ++-
 lto-plugin/configure.ac | 3 ---
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/lto-plugin/Makefile.am b/lto-plugin/Makefile.am
index a96acc87ee2..81362eafc36 100644
--- a/lto-plugin/Makefile.am
+++ b/lto-plugin/Makefile.am
@@ -9,7 +9,8 @@ libexecsubdir := 
$(libexecdir)/gcc/$(real_target_noncanonical)/$(gcc_version)$(a


 AM_CPPFLAGS = -I$(top_srcdir)/../include $(DEFS)
 AM_CFLAGS = @ac_lto_plugin_warn_cflags@ $(CET_HOST_FLAGS)
-AM_LDFLAGS = @ac_lto_plugin_ldflags@
+# The plug-in depends on pthreads.
+AM_LDFLAGS = -pthread @ac_lto_plugin_ldflags@
 AM_LIBTOOLFLAGS = --tag=disable-static
 override CFLAGS := $(filter-out -fsanitize=address 
-fsanitize=hwaddress,$(CFLAGS))
 override LDFLAGS := $(filter-out -fsanitize=address 
-fsanitize=hwaddress,$(LDFLAGS))

diff --git a/lto-plugin/configure.ac b/lto-plugin/configure.ac
index 75cf46ac5c7..c2ec512880f 100644
--- a/lto-plugin/configure.ac
+++ b/lto-plugin/configure.ac
@@ -13,9 +13,6 @@ AC_PROG_CC
 AC_SYS_LARGEFILE
 ACX_PROG_CC_WARNING_OPTS([-Wall], [ac_lto_plugin_warn_cflags])

-# The plug-in depends on pthreads
-LDFLAGS="-pthread"
-
 # Check whether -static-libgcc is supported.
 saved_LDFLAGS="$LDFLAGS"
 LDFLAGS="$LDFLAGS -static-libgcc"
--
2.34.1


Re: [PATCH] libstdc++-v3: check for openat

2022-06-28 Thread Jonathan Wakely via Gcc-patches
On Tue, 28 Jun 2022 at 13:04, Alexandre Oliva  wrote:
>
> On Jun 28, 2022, Jonathan Wakely  wrote:
>
> > I'll push this today.
>
> Thanks!
>
> > You can just use --enable-libstdcxx-debug
>
> Thanks again ;-)
>
> > Again, that test is *supposed* to return without creating the
> > destination. It's testing the failure case.
>
> Aha, and that's why one shouldn't debug something without looking at the
> code to see what it's *supposed* to do ;-)
>
> >> FAILED: default@libstdc++,27_io,filesystem,operations,copy_cc
> >> FAILED: default@libstdc++,experimental,filesystem,operations,copy_cc
> >>
> >> .../27_io/filesystem/operations/copy.cc:5[67]: void test01():
> >> Assertion '!exists(to)' failed.
>
> > I don't know what 5[67] means
>
> Sorry for being unclear, it's just that the corresponding failing
> asserts are at different lines in the two mentioned testcases, and I
> tried to convey that fact with regexp notation.

Doh! Of course. I thought it was some rtems thing. /facepalm


>
> > Which suggests to me another problem with mkstemp / nonexistent_path.
>
> *lightbulb powers up*
>
> Now it all makes sense.
>
> It isn't *another* problem, that probably regressed when the mkstemp
> patch went in and so it got out of my radar and thus out of the patchset
> I used in subsequent test runs, but because of the way I use the testing
> system, the baseline on top of which the patchset was installed was
> still was still that of the previous nightly build, so I effectively
> dropped the mkstemp fix.  And since when I joined this project this bug
> had already been fixed, I didn't associate the regressions with the
> patch.

Makes sense.

> Apologies for the noise.  Today's baseline, plus your _At_path patch and
> my remove_all patch, is all clear.  Yay!

Great!



Re: [PATCH] Remove legacy EVRP code.

2022-06-28 Thread Jeff Law via Gcc-patches




On 6/28/2022 1:37 AM, Richard Biener via Gcc-patches wrote:

On Mon, Jun 27, 2022 at 9:04 PM Aldy Hernandez  wrote:

With DOM converted to ranger, there are no longer any uses of the EVRP
engine.  For that matter, we haven't used the legacy mode in quite a
while, so I think it's safe to remove any associated code.

There are some methods in vr_values which should now be private, but I
didn't bother changing them, as most of the vr_values class will be
removed when VRP1 is converted to ranger.

Does anyone have any issues with me pushing this?

Fine with me.

Likewise.
jeff



[PATCH] testsuite/102690: Only check warning for lp64 in Warray-bounds-16.C

2022-06-28 Thread Kito Cheng
That warning won't happen on ilp32 targets, seems like Andrew Pinski
already mention that[1] before.

Verified on riscv32-unknown-elf and riscv64-unknown-elf.

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92879#c1

gcc/testsuite/ChangeLog:

PR testsuite/102690
* g++.dg/warn/Warray-bounds-16.C: XFAIL only on lp64 for the
warning.
---
 gcc/testsuite/g++.dg/warn/Warray-bounds-16.C | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/g++.dg/warn/Warray-bounds-16.C 
b/gcc/testsuite/g++.dg/warn/Warray-bounds-16.C
index 89cbadb91c7..45a14b19ea3 100644
--- a/gcc/testsuite/g++.dg/warn/Warray-bounds-16.C
+++ b/gcc/testsuite/g++.dg/warn/Warray-bounds-16.C
@@ -19,7 +19,7 @@ struct S
 p = (int*) new unsigned char [sizeof (int) * m];
 
 for (int i = 0; i < m; i++)
-  new (p + i) int (); /* { dg-bogus "bounds" "pr102690" { xfail *-*-* } } 
*/
+  new (p + i) int (); /* { dg-bogus "bounds" "pr102690" { xfail lp64 } } */
   }
 };
 
-- 
2.34.0



Re: [PATCH] mksysinfo: add support for musl libc

2022-06-28 Thread Sören Tempel via Gcc-patches
Ian Lance Taylor  wrote:
> Given that pretty much every one of these musl patches has led to
> problems on some glibc systems, it would be very nice if you could do
> some testing with glibc.  Thanks.

Sorry, my bad.

I just tested this on Arch Linux and it compiles fine with the patch.

> Can you expand on the st_atim issue?

The st_atim issue is simply that struct stat contains additional struct
fields on 32-bit musl architectures (__st_{a,m,c}tim32) in addition to
st_{a,m,c}tim [1]. The sed expression currently only replaces the first
occurrence (i.e. __st_{a,m,c}tim32) from gen-sysinfo.go:

$ grep 'st_[acm]tim' sysinfo.go
type _stat struct { st_dev uint64; __st_dev_padding int32; 
__st_ino_truncated int32; st_mode uint32; st_nlink uint32; st_uid uint32; 
st_gid uint32; st_rdev uint64; __st_rdev_padding int32; st_size int64; 
st_blksize int32; st_blocks int64; __st_atim32 struct { tv_sec int32; tv_nsec 
int32; }; __st_mtim32 struct { tv_sec int32; tv_nsec int32; }; __st_ctim32 
struct { tv_sec int32; tv_nsec int32; }; st_ino uint64; st_atim Timespec; 
st_mtim Timespec; st_ctim Timespec; }
type Stat_t struct { Dev uint64; __st_dev_padding int32; 
__Ino_truncated int32; Mode uint32; Nlink uint32; Uid uint32; Gid uint32; Rdev 
uint64; __st_rdev_padding int32; Size int64; Blksize int32; Blocks int64; 
__Atim32 struct { tv_sec int32; tv_nsec int32; }; __Mtim32 struct { tv_sec 
int32; tv_nsec int32; }; __Ctim32 struct { tv_sec int32; tv_nsec int32; }; Ino 
uint64; st_atim Timespec; st_mtim Timespec; st_ctim Timespec; }

This causes the following build error on 32-bit musl architectures:

stat_atim.go: error: reference to undefined field or method 'Mtim'
   17 | fs.modTime = timespecToTime(fs.sys.Mtim)
  |   ^
stat_atim.go: error: reference to undefined field or method 'Atim'
   52 | return timespecToTime(fi.Sys().(*syscall.Stat_t).Atim)
  | ^

This is fixed by the proposed patch by replacing both members in struct stat.

> What does the musl type look like in gen-sysinfo.go?

$ grep 'st_[acm]tim' gen-sysinfo.go
// unknowndefine st_atime st_atim.tv_sec
// unknowndefine st_mtime st_mtim.tv_sec
// unknowndefine st_ctime st_ctim.tv_sec
type _stat struct { st_dev uint64; __st_dev_padding int32; 
__st_ino_truncated int32; st_mode uint32; st_nlink uint32; st_uid uint32; 
st_gid uint32; st_rdev uint64; __st_rdev_padding int32; st_size int64; 
st_blksize int32; st_blocks int64; __st_atim32 struct { tv_sec int32; tv_nsec 
int32; }; __st_mtim32 struct { tv_sec int32; tv_nsec int32; }; __st_ctim32 
struct { tv_sec int32; tv_nsec int32; }; st_ino uint64; st_atim _timespec; 
st_mtim _timespec; st_ctim _timespec; }

> What is the value of SYS_SECCOMP in musl?  Is it a system call number?

SYS_SECCOMP is a macro defined in signal.h which can be used to check
the si_code member of siginfo_t for SIGSYS, see the SECCOMP_RET_TRAP
description in seccomp(2). As such, it is not a system call number.
The value of SYS_SECCOMP is simply 1 [2].

> What does it look like in gen-sysinfo.go?

Defined in gen-sysinfo.go as follows:

4688:const _SYS_seccomp = 317
4775:const _SYS_SECCOMP = 1

where the former is the syscall and the latter is the expanded
SYS_SECCOMP macro constant. When generating sysinfo.go the name seems to
be uppercased, thus resulting in a compilation failure. The generated
sysinfo.go contains the following lines:

3067:const _SYS_seccomp = 317
3154:const _SYS_SECCOMP = 1
6600:const SYS_SECCOMP = _SYS_seccomp
6606:const SYS_SECCOMP = _SYS_SECCOMP

Build error:

sysinfo.go:6606:7: error: redefinition of 'SYS_SECCOMP'
 6606 | const SYS_SECCOMP = _SYS_SECCOMP
  |   ^
sysinfo.go:6600:7: note: previous definition of 'SYS_SECCOMP' was here
 6600 | const SYS_SECCOMP = _SYS_seccomp
  |   ^

This is fixed by the patch by only extracting _SYS_seccomp, not _SYS_SECCOMP.

If you need more information, just let me know :)

Greetings,
Sören

[1]: https://git.musl-libc.org/cgit/musl/tree/arch/i386/bits/stat.h
[2]: 
https://git.musl-libc.org/cgit/musl/commit/?id=3dcbd896907d9d474da811b7c6b769342abaf651


Re: [committed] libstdc++: Improve directory iterator abstractions for openat

2022-06-28 Thread Jonathan Wakely via Gcc-patches
On Tue, 28 Jun 2022 at 15:24, Jonathan Wakely via Libstdc++
 wrote:
> --- a/libstdc++-v3/src/filesystem/dir-common.h
> +++ b/libstdc++-v3/src/filesystem/dir-common.h
> @@ -25,6 +25,7 @@
>  #ifndef _GLIBCXX_DIR_COMMON_H
>  #define _GLIBCXX_DIR_COMMON_H 1
>
> +#include   // uint32_t
>  #include   // strcmp
>  #include 
>  #if _GLIBCXX_FILESYSTEM_IS_WINDOWS
> @@ -91,12 +92,50 @@ is_permission_denied_error(int e)
>
>  struct _Dir_base
>  {
> +  // As well as the full pathname (including the directory iterator's path)
> +  // this type contains a file descriptor for a directory and a second 
> pathname
> +  // relative to that directory. The file descriptor and relative pathname
> +  // can be used with POSIX openat and unlinkat.
> +  struct _At_path
> +  {
> +// No file descriptor given, so interpret the pathname relative to the 
> CWD.
> +_At_path(const char* p) noexcept

I forgot to consistently use the char_type alias to support wchar_t
paths on Windows. Fixed by the attached patch.

Tested x86_64-linux and x86_64-mingw32, pushed to trunk.
commit bb1f266a7d602ffee4a070f586351bdfafcb6150
Author: Jonathan Wakely 
Date:   Tue Jun 28 12:56:19 2022

libstdc++: Fix filesystem build for Windows

I only half remembered to use char_type instead of char for filesystem
paths, so that it works with wchar_t on Windows. This fixes the
bootstrap failure.

libstdc++-v3/ChangeLog:

* src/filesystem/dir-common.h (_Dir_base::_At_path):
Use char_type consistently for paths.

diff --git a/libstdc++-v3/src/filesystem/dir-common.h 
b/libstdc++-v3/src/filesystem/dir-common.h
index 4844b1ac453..228fab55afb 100644
--- a/libstdc++-v3/src/filesystem/dir-common.h
+++ b/libstdc++-v3/src/filesystem/dir-common.h
@@ -99,18 +99,22 @@ struct _Dir_base
   struct _At_path
   {
 // No file descriptor given, so interpret the pathname relative to the CWD.
-_At_path(const char* p) noexcept
+_At_path(const posix::char_type* p) noexcept
 : pathname(p), dir_fd(fdcwd()), offset(0)
 { }
 
-_At_path(int fd, const char* p, size_t offset) noexcept
+_At_path(int fd, const posix::char_type* p, size_t offset) noexcept
 : pathname(p), dir_fd(fd), offset(offset)
 { }
 
-const char* path() const noexcept { return pathname; }
+const posix::char_type*
+path() const noexcept { return pathname; }
 
-int dir() const noexcept { return dir_fd; }
-const char* path_at_dir() const noexcept { return pathname + offset; }
+int
+dir() const noexcept { return dir_fd; }
+
+const posix::char_type*
+path_at_dir() const noexcept { return pathname + offset; }
 
   private:
 const posix::char_type* pathname; // Full path relative to CWD.


Re: [PATCH, libgomp] Fix chunk_size<1 for dynamic schedule

2022-06-28 Thread Jakub Jelinek via Gcc-patches
On Tue, Jun 28, 2022 at 04:06:14PM +0200, Jakub Jelinek via Gcc-patches wrote:
> On Thu, Jun 23, 2022 at 11:47:59PM +0800, Chung-Lin Tang wrote:
> > with the way that chunk_size < 1 is handled for gomp_iter_dynamic_next:
> > 
> > (1) chunk_size <= -1: wraps into large unsigned value, seems to work though.
> > (2) chunk_size == 0:  infinite loop
> > 
> > The (2) behavior is obviously not desired. This patch fixes this by changing
> 
> Why?  It is a user error, undefined behavior, we shouldn't slow down valid
> code for users who don't bother reading the standard.
> 
> E.g. OpenMP 5.1 [132:14] says clearly:
> "chunk_size must be a loop invariant integer expression with a positive
> value."
> and omp_set_schedule for chunk_size < 1 should use a default value (which it
> does).
> 
> For OMP_SCHEDULE the standard says it is implementation-defined what happens
> if the format isn't the specified one, so I guess the env.c change
> could be acceptable (though without it it is fine too), but the

Though, seems we quietly transform the only problematic value (0) in there
to 1 for selected schedules which don't accept 0 as "unspecified" and for
the negative values, we'll have large ulong chunk sizes which is fine.

If we really want help people debugging their programs, we could introduce
something like -fsanitize=openmp that would add runtime instrumentation of a
lot of OpenMP restrictions and could diagnose it with nice diagnostics,
perhaps using some extra library and with runtime checks in generated code.

Jakub



Re: [GCC 13][PATCH] PR101836: Add a new option -fstrict-flex-array[=n] and use it in __builtin_object_size

2022-06-28 Thread Qing Zhao via Gcc-patches
Hi, Richard,


> On Jun 28, 2022, at 3:16 AM, Richard Biener  
> wrote:
> 
> On Mon, Jun 27, 2022 at 4:20 PM Qing Zhao via Gcc-patches
>  wrote:
>> 
>> Hi,
>> 
>> Per our discussion in the bug report, I came up with the following patch:
>> 
>> ===
>> 
>> PR101836: Add a new option -fstrict-flex-array[=n]
>> 
>> Add the new option and use it in __builtin_object_size.
>> 
>> Treat the trailing array of a structure as a flexible array member in a
>> stricter way.  The value of 'n' controls the level of strictness.
>> 'n'=0 is the least strict, all trailing arrays of structures are treated
>> as flexible array members; This is the default behavior of GCC without 
>> specify
>> this option.
>> 'n'=3 is the strictest, only when the trailing array is declared as a
>> flexible array member per C99 standard onwards ([]), it is treated as a
>> flexible array member;
>> There are two more levels in between 0 and 3, which are provided to support
>> older codes that use GCC zero-length array extension ([0]), or one-size 
>> array as
>> flexible array member ([1]):
>> When 'n' is 1, the trailing array is treated as a flexible array member
>> when it is declared as either [], [0], or [1];
>> When 'n' is 2, the trailing array is treated as a flexible array member
>> when it is declared as either [], or [0].
>> 
>> There are other places in GCC that conservatively treat flexible array 
>> members.
>> A follow-up patch will make -ftrict-flex-array option to control all these
>> places consistently.
>> 
>> Bootstrapped and regression tested on both X86 and aarch64, no issues.
>> 
>> Any comment and suggestion?
> 
> Since this aims at the C or C++ frontends but the middle-end eventually 
> consumes
> this it would be much nicer to encode this in the types themselves.

Yes, I agree. 

Let the C/C++ FE to decide whether the [0], [1], or [] trailing array field of 
a structure is a flex array member or not based on the option 
-fstrict-flex-array and
then encode such info in the FIELD_DECL as flag DECL_NOT_FLEXARRAY. 

Later, the middle end just check the flag DECL_NOT_FLEXARRAY of the FIELD_DECL
to decide whether the trailing array is flexible array or not. 

This will eliminate all the hacks in the middle-end (as you mentioned, 
array_at_struct_end_p, 
and “trailing_array”, etc, and there are quite some phases use this routine to 
query, and in
an in-consistent way)

> Since the least
> strict reading is the default right now it would be a flag (on the
> FIELD_DECL I suppose)
> like DECL_NOT_FLEXARRAY or DECL_FIXED_SIZE?  Alternatively the flag could
> also be on the record type enclosing the trailing array member (but
> type sharing might
> make this more difficult in the end).
> 
> There's also array_at_struct_end_p which is supposed to be the main
> query interface
> for this (but it seems people sneaked in more variants with eventually
> different semantics ... :/)

Yes, there are many places right now that query “array_at_struct_end_p”, I was 
planning a follow-up
patchs to replace all “array_at_struct_end_p” with is_flexible_array_p. I guess 
that this follow-up patch 
will take quite some time to finish. 

So, my next step:

1. Update this current patch per your suggestion above, i.e, 

A. Add a new flag (DECL_NOT_FLEXARRAY)  in FIELD_DECL, default is FALSE;
B. In C/C++ FE,  for a trailing array field of a structure,  decide 
DECL_NOT_FLEXARRAY flag as following:
Level 1:  any trailing array that is NOT [0], [1], [], 
DECL_NOT_FLEXARRAY is TRUE;
Level 2:  any trailing array that is NOT [0], [], DECL_NOT_FLEXARRAY is 
TRUE; 
Level 3:  any trailing array that is not [], DECL_NOT_FLEXARRAY is TRUE
C. Use DECL_NOT_FLEXARRAY in tree-object-size.c  for __builtin_object_size 
to resolve bug PR101836.

2. Then replace all “array_at_struct_end_p” with using DECL_NOT_FLEXARRAY in 
GCC, adding new testing cases
For different phases with different level, resolving all regressions. 


I plan separate patches for 1 and 2.  Commit 1 first to enable kernel work as 
soon as possible. Then continue working
on 2 to make GCC consistent in gcc13. 

Let me know if you have any suggestion or comment.

Thanks

Qing
 


> 
> Richard.
> 
> 
> 
>> Okay for commit to Gcc13?
>> 
>> thanks.
>> 
>> Qing
>> 
>> ===
>> 
>> gcc/
>> 
>>   PR tree-optimization/101836
>>   * common.opt (fstrict-flex-array, fstrict-flex-array=): New options.
>>   * doc/invoke.texi (-fstrict-flex-array, -fstrict-flex-array=): 
>> Document.
>>   * tree-object-size.cc (addr_object_size): Call is_flexible_array_p to
>>   check whether an array is a flexible array.
>>   * tree.cc (special_array_member_type): New routine.
>>   (is_flexible_array_p): New routine.
>>   (component_ref_size): Call special_array_member_type to decide the
>>   type of special array member.
>>   * tree.h (enum struct special_array_member): Add is_vla, trail_flex.
>>   (special_array_member_typ

Re: [GCC 13][PATCH] PR101836: Add a new option -fstrict-flex-array[=n] and use it in __builtin_object_size

2022-06-28 Thread Jakub Jelinek via Gcc-patches
On Tue, Jun 28, 2022 at 03:03:12PM +, Qing Zhao wrote:
> 2. Then replace all “array_at_struct_end_p” with using DECL_NOT_FLEXARRAY in 
> GCC, adding new testing cases

No, IMHO array_at_struct_end_p should stay as is, just test this extra flag
too.

Jakub



Re: [PATCH gcc 0/1] [PATCH] target: Fix asm generation for AVX builtins when using -masm=intel [PR106095]

2022-06-28 Thread Antoni Boucher via Gcc-patches
Thanks for the review.
Does this mean I can commit it, assuming the output of compare_tests is
good?

By the way, I wanted to mention that it was my first time playing with
the assembly generation, so I was not sure about my changes (even
though it makes the test case compile, I'm not sure it doesn't have any
unintended side effects):
It looked to me that the register qualifiers should be the same for
both AT&T and Intel syntaxes, but I'm might be wrong about this.

On Tue, 2022-06-28 at 14:22 +0800, Hongtao Liu wrote:
> On Tue, Jun 28, 2022 at 9:26 AM ~antoyo via Gcc-patches
>  wrote:
> > 
> > Hi.
> > 
> > This fixes the following bug:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106095
> The patch LGTM, thanks for handling this.
> > 
> > It's the first time I work outside of the jit component, so please
> > tell
> > me if I forgot anything.
> > 
> > Here are the results of running the test:
> > 
> >     === gcc Summary ===
> > 
> > # of expected passes    182481
> > # of unexpected failures    91
> > # of unexpected successes   20
> > # of expected failures  1475
> > # of unsupported tests  2535
> > 
> >     === g++ Summary ===
> > 
> > # of expected passes    231596
> > # of unexpected failures    1
> > # of expected failures  2083
> > # of unsupported tests  9948
> > 
> >     === jit Summary ===
> > 
> > # of expected passes    14542
> > # of unexpected failures    1
> > 
> >     === libstdc++ Summary ===
> > 
> > # of expected passes    15538
> > # of expected failures  95
> > # of unsupported tests  653
> > 
> >     === libgomp Summary ===
> > 
> > # of expected passes    5012
> > # of expected failures  33
> > # of unsupported tests  323
> > 
> >     === libitm Summary ===
> > 
> > # of expected passes    44
> > # of expected failures  3
> > # of unsupported tests  1
> > 
> >     === libatomic Summary ===
> > 
> > # of expected passes    54
> > 
> > It's the first time I run the whole testsuite, so I'm not sure if
> > those
> > failures are normal. I got more unexpected failures for the gcc
> > tests
> > than what is shown in https://gcc.gnu.org/pipermail/gcc-
> > testresults/2022-June/764154.html. In any case, I get the same
> > failures
> > when running the testsuite on master. Perhaps my configure command
> > is
> > wrong? I used the following:
> You can use ./contrib/compare_tests to see if there's no failure or
> new pass.
> ./contrib/compara_tests is under gcc top directory.
> > 
> > ../../gcc/configure --enable-host-shared --enable-
> > languages=c,jit,c++,lto --enable-checking=release
> > --prefix=(pwd)/../install
> > 
> --enable-checking=release will give up some internal checks to
> increase the compilation speed, for the development trunk, it is
> better not to use release.
> > Thanks for the review.
> > 
> > Antoni Boucher (1):
> >   target: Fix asm generation for AVX builtins when using -
> > masm=intel
> >     [PR106095]
> > 
> >  gcc/config/i386/sse.md   | 10 ++---
> >  gcc/testsuite/gcc.target/i386/pr106095.c | 47
> > 
> >  2 files changed, 52 insertions(+), 5 deletions(-)
> >  create mode 100644 gcc/testsuite/gcc.target/i386/pr106095.c
> > 
> > --
> > 2.34.2
> 
> 
> 



Re: [x86 PATCH] Double word logical operation clean-ups in i386.md.

2022-06-28 Thread Uros Bizjak via Gcc-patches
On Tue, Jun 28, 2022 at 1:34 PM Roger Sayle  wrote:
>
>
> Hi Uros,
> As you've requested/suggested, here's a patch that tidies up and
> unifies doubleword handling in i386.md; converting all doubleword
> splitters for logic operations to post-reload form, generalizing
> their define_insn_and_split templates to  form (supporting
> TARGET_64BIT ? TImode : DImode), and where required tweaking the
> corresponding expanders to use SDWIM to support TImode doubleword
> operations.  These changes incorporate your feedback from
> https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596205.html
> where I included many/several of these clean-ups, in a patch to
> add a new optimization.  I agree, it's better to split these out
> (this patch), and I'll resubmit the (smaller) optimization patch
> as a follow-up.
>
> This patch has been tested on x86_64-pc-linux-gnu with make bootstrap
> and make -k check, both with and without --target_board=unix{-m32},
> with no new failures.  Ok for mainline?
>
>
> 2022-06-28  Roger Sayle  
>
> gcc/ChangeLog
> * config/i386/i386.md (general_szext_operand): Add TImode
> support using x86_64_hilo_general_operand predicate.
> (*cmp_doubleword): Use x86_64_hilo_general_operand predicate.
> (*add3_doubleword): Improved optimization of zero addition.
> (and3): Use SDWIM mode iterator to add support for double
> word bit-wise AND in TImode.  Use force_reg when double word
> immediate operand isn't x86_64_hilo_general_operand.
> (and3_doubleword): Generalized from anddi3_doubleword and
> converted into a post-reload splitter.
> (*andn3_doubleword): Generalized from *andndi3_doubleword.
> (define_split): Generalize DImode splitters for andn to .
> One splitter for TARGET_BMI, the other for !TARGET_BMI.
> (3): Use SDWIM mode iterator to add suppport for
> double word bit-wise XOR and bit-wise IOR in TImode.  Use
> force_reg when double word immediate operand isn't
> x86_64_hilo_general_operand.
> (*di3_doubleword): Generalized from di3_doubleword.
> (one_cmpl2): Use SDWIM mode iterator to add support for
> double word bit-wise NOT in TImode.
> (one_cmpl2_doubleword): Generalize from one_cmpldi2_doubleword
> and converted into a post-reload splitter.


 (define_expand "and3"
-  [(set (match_operand:SWIM1248x 0 "nonimmediate_operand")
-(and:SWIM1248x (match_operand:SWIM1248x 1 "nonimmediate_operand")
-   (match_operand:SWIM1248x 2 "")))]
+  [(set (match_operand:SDWIM 0 "nonimmediate_operand")
+(and:SDWIM (match_operand:SDWIM 1 "nonimmediate_operand")
+   (match_operand:SDWIM 2 "")))]
   ""
 {
   machine_mode mode = mode;

-  if (mode == DImode && !TARGET_64BIT)
-;
-  else if (const_int_operand (operands[2], mode)
-   && register_operand (operands[0], mode)
-   && !(TARGET_ZERO_EXTEND_WITH_AND
-&& optimize_function_for_speed_p (cfun)))
+  if (GET_MODE_SIZE (mode) > UNITS_PER_WORD
+  && !x86_64_hilo_general_operand (operands[2], mode))
+operands[2] = force_reg (mode, operands[2]);

You don't have to do that - when the predicate can't be satisfied, the
middle-end pushes the value to a register as a last resort by default.

+  bool emit_insn_deleted_note_p = false;
+
+  split_double_mode (mode, &operands[0], 3, &operands[0], &operands[3]);

   if (operands[2] == const0_rtx)
 emit_move_insn (operands[0], const0_rtx);
   else if (operands[2] == constm1_rtx)
-emit_move_insn (operands[0], operands[1]);
+{
+  if (!rtx_equal_p (operands[0], operands[1]))
+emit_move_insn (operands[0], operands[1]);
+  else
+emit_insn_deleted_note_p = true;
+}

Please note that when operands[2] is an immediate, constraints after
reload *guarantee* that operands[1] match operands[0]. So, the insn
should always be deleted (I think that this functionality was in your
 patch - it is unneeded there, too).

+(define_insn "*andn3_doubleword"
+  [(set (match_operand:DWI 0 "register_operand")
+(and:DWI
+  (not:DWI (match_operand:DWI 1 "register_operand"))
+  (match_operand:DWI 2 "nonimmediate_operand")))
(clobber (reg:CC FLAGS_REG))]
-  "!TARGET_64BIT && TARGET_STV && TARGET_SSE2
-   && ix86_pre_reload_split ()"
+  "ix86_pre_reload_split ()"
   "#")

Please introduce two ANDN double-word insn-and-split patterns, one for
BMI and one for !BMI. The one for BMI should be moved to a post-reload
splitter, too. As we figured out, *all* double-word patterns should
either be of pre-reload or of post-reload type.

 (define_split
-  [(set (match_operand:DI 0 "register_operand")
-(and:DI
-  (not:DI (match_operand:DI 1 "register_operand"))
-  (match_operand:DI 2 "nonimmediate_operand")))
+  [(set (match_operand:DWI 0 "register_operand")
+(and:DWI
+  (not:DWI (match_operand:DWI 1 "register_operand"))
+  (match_operand:DWI 2 "nonimmediate_operand")))
(clo

RE: [PATCH 1/2]AArch64 Add fallback case using sdot for usdot

2022-06-28 Thread Tamar Christina via Gcc-patches
> -Original Message-
> From: Richard Biener 
> Sent: Monday, June 27, 2022 7:10 AM
> To: Tamar Christina 
> Cc: Richard Sandiford ; Richard Earnshaw
> ; nd ; gcc-
> patc...@gcc.gnu.org; Marcus Shawcroft 
> Subject: Re: [PATCH 1/2]AArch64 Add fallback case using sdot for usdot
> 
> On Mon, Jun 27, 2022 at 7:25 AM Tamar Christina via Gcc-patches  patc...@gcc.gnu.org> wrote:
> >
> > > -Original Message-
> > > From: Richard Sandiford 
> > > Sent: Thursday, June 16, 2022 7:54 PM
> > > To: Tamar Christina 
> > > Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
> > > ; Marcus Shawcroft
> > > ; Kyrylo Tkachov
> 
> > > Subject: Re: [PATCH 1/2]AArch64 Add fallback case using sdot for
> > > usdot
> > >
> > > Richard Sandiford via Gcc-patches  writes:
> > > > Tamar Christina  writes:
> > > >> Hi All,
> > > >>
> > > >> The usdot operation is common in video encoder and decoders
> > > >> including some of the most widely used ones.
> > > >>
> > > >> This patch adds a +dotprod version of the optab as a fallback for
> > > >> when you do have sdot but not usdot available.
> > > >>
> > > >> The fallback works by adding a bias to the unsigned argument to
> > > >> convert it to a signed value and then correcting for the bias later on.
> > > >>
> > > >> Essentially it relies on (x - 128)y + 128y == xy where x is
> > > >> unsigned and y is signed (assuming both are 8-bit values).
> > > >> Because the range of a signed byte is only to 127 we split the bias
> correction into:
> > > >>
> > > >>(x - 128)y + 127y + y
> > > >
> > > > I bet you knew this question was coming, but: this technique isn't
> > > > target-specific, so wouldn't it be better to handle it in
> > > > tree-vect-patterns.cc instead?
> >
> > Ok, so after many hours of trying I don't know how to make this work.
> > DOT_PROD_EXPR is a reduction, but emitting them as additional pattern
> > statement doesn't work because they'll be marked as internal_def
> > rather than reduction_def.  I tried marking the new vec_stmt_info that
> > I create explicitly as reduction_def but this gets overwritten during 
> > analysis.
> >
> > I then looked into getting it as a vectorizable_operation but has this
> > obvious problems In that it no longer treats it as a reduction and so tries 
> > to
> decompose into hi/lo.
> >
> > I then looked into treating additional patterns from  a reduction as
> > reductions themselves but this is obviously wrong as non-reduction
> statements also get marked as reductions.
> >
> > The conclusion is that I don't think the vectorizer allows additional
> > reductions to be emitted from patterns.
> 
> Indeed.  DOT_PROD is a weird beast and it doesn't define which lanes are
> reduced to which so it's only usable when the result is reduced to a single
> lane.
> 
> An SLP pattern might work if you use reduc-plus for the reduced lanes and
> keep the multiply separate?

Unfortunately I can't seem to get it to handle the reduction in SLP.  It seems 
to always
use the non-SLP aware loop vectorizer here.  The suggested unroll factor is 
always 1 and
even trying to force it gets it to bail out later, presumable because it's 
reducing into a
scalar that's used outside the loop?

Thanks,
Tamar

> 
> Richard.
> 
> > > Also, how about doing (x - 128)y + 64y + 64y instead, to reduce the
> > > number of hoisted constants?
> > >
> > > Thanks,
> > > Richard
> > >
> > > > Thanks,
> > > > Richard
> > > >
> > > >> Concretely for:
> > > >>
> > > >> #define N 480
> > > >> #define SIGNEDNESS_1 unsigned
> > > >> #define SIGNEDNESS_2 signed
> > > >> #define SIGNEDNESS_3 signed
> > > >> #define SIGNEDNESS_4 unsigned
> > > >>
> > > >> SIGNEDNESS_1 int __attribute__ ((noipa)) f (SIGNEDNESS_1 int res,
> > > >> SIGNEDNESS_3 char *restrict a,
> > > >>SIGNEDNESS_4 char *restrict b) {
> > > >>   for (__INTPTR_TYPE__ i = 0; i < N; ++i)
> > > >> {
> > > >>   int av = a[i];
> > > >>   int bv = b[i];
> > > >>   SIGNEDNESS_2 short mult = av * bv;
> > > >>   res += mult;
> > > >> }
> > > >>   return res;
> > > >> }
> > > >>
> > > >> we generate:
> > > >>
> > > >> moviv5.16b, 0x7f
> > > >> mov x3, 0
> > > >> moviv4.16b, 0x1
> > > >> moviv3.16b, 0xff80
> > > >> moviv0.4s, 0
> > > >> .L2:
> > > >> ldr q2, [x2, x3]
> > > >> ldr q1, [x1, x3]
> > > >> add x3, x3, 16
> > > >> sub v2.16b, v2.16b, v3.16b
> > > >> sdotv0.4s, v2.16b, v1.16b
> > > >> sdotv0.4s, v5.16b, v1.16b
> > > >> sdotv0.4s, v4.16b, v1.16b
> > > >> cmp x3, 480
> > > >> bne .L2
> > > >>
> > > >> instead of:
> > > >>
> > > >> moviv0.4s, 0
> > > >> mov x3, 0
> > > >> .L2:
> > > >> ldr q2, [x1, x3]
> > > >> ldr q1, [x2, x3]
> > > >> add x3, x3, 16
> > > >> sxtlv4.8h, v2.8b
> > > >> sxtl2   v3.8h, v2.16b
> > > >> uxtlv2.8h,

Re: [GCC 13][PATCH] PR101836: Add a new option -fstrict-flex-array[=n] and use it in __builtin_object_size

2022-06-28 Thread Qing Zhao via Gcc-patches


> On Jun 28, 2022, at 11:08 AM, Jakub Jelinek  wrote:
> 
> On Tue, Jun 28, 2022 at 03:03:12PM +, Qing Zhao wrote:
>> 2. Then replace all “array_at_struct_end_p” with using DECL_NOT_FLEXARRAY in 
>> GCC, adding new testing cases
> 
> No, IMHO array_at_struct_end_p should stay as is, just test this extra flag
> too.

Could you please explain why we still need “array_at_struct_end_p” after we 
have the DECL_NOT_FLEXARRAY flag in FIELD_DECL?
In addition to serve the purpose to check whether an array might be a flexible 
array, what else this function “array_at_struct_end_p” will do?

Thanks.

Qing
> 
>   Jakub
> 



Re: Ping: [PATCH] libatomic: drop redundant all-multi command

2022-06-28 Thread Jeff Law via Gcc-patches




On 6/28/2022 12:52 AM, Jan Beulich via Gcc-patches wrote:

On 27.05.2022 10:01, Jan Beulich wrote:

./multilib.am already specifies this same command, and make warns about
the earlier one being ignored when seeing the later one. All that needs
retaining to still satisfy the preceding comment is the extra
dependency.

libatomic/

* Makefile.am (all-multi): Drop commands.
* Makefile.in: Update accordingly.

Ping?

Weird, I thought I'd acked this already, but I can't find it in my outbox.

OK for the trunk.

jeff





Re: [PATCH] rtl-optimization/106082 - preserve EH note for no non-local goto

2022-06-28 Thread Jeff Law via Gcc-patches




On 6/28/2022 5:11 AM, Richard Biener wrote:

The following makes sure we preserve EH notes on call insns that
indicate the call doesn't perform a non-local goto when distributing
notes after combining insns.

Bootstrap & regtest pending on x86_64-unknown-linux-gnu, tested on
the m68k testcase in the PR.

OK for trunk if testing passes?

Thanks,
Richard.

2022-06-28  Richard Biener  

PR rtl-optimization/106082
* combine.cc (distribute_notes): Preserve notes when
they indicate a call doesn't perform a non-local goto.
I've thrown this into the tester and fired up a m68k run.  Results in 
~30hrs or so.


jeff



Re: [GCC 13][PATCH] PR101836: Add a new option -fstrict-flex-array[=n] and use it in __builtin_object_size

2022-06-28 Thread Martin Sebor via Gcc-patches

On 6/28/22 01:16, Richard Biener wrote:

On Mon, Jun 27, 2022 at 4:20 PM Qing Zhao via Gcc-patches
 wrote:


Hi,

Per our discussion in the bug report, I came up with the following patch:

===

PR101836: Add a new option -fstrict-flex-array[=n]

Add the new option and use it in __builtin_object_size.

Treat the trailing array of a structure as a flexible array member in a
stricter way.  The value of 'n' controls the level of strictness.
'n'=0 is the least strict, all trailing arrays of structures are treated
as flexible array members; This is the default behavior of GCC without specify
this option.
'n'=3 is the strictest, only when the trailing array is declared as a
flexible array member per C99 standard onwards ([]), it is treated as a
flexible array member;
There are two more levels in between 0 and 3, which are provided to support
older codes that use GCC zero-length array extension ([0]), or one-size array as
flexible array member ([1]):
When 'n' is 1, the trailing array is treated as a flexible array member
when it is declared as either [], [0], or [1];
When 'n' is 2, the trailing array is treated as a flexible array member
when it is declared as either [], or [0].

There are other places in GCC that conservatively treat flexible array members.
A follow-up patch will make -ftrict-flex-array option to control all these
places consistently.

Bootstrapped and regression tested on both X86 and aarch64, no issues.

Any comment and suggestion?


Since this aims at the C or C++ frontends but the middle-end eventually consumes
this it would be much nicer to encode this in the types themselves.
Since the least
strict reading is the default right now it would be a flag (on the
FIELD_DECL I suppose)
like DECL_NOT_FLEXARRAY or DECL_FIXED_SIZE?  Alternatively the flag could
also be on the record type enclosing the trailing array member (but
type sharing might
make this more difficult in the end).

There's also array_at_struct_end_p which is supposed to be the main
query interface
for this (but it seems people sneaked in more variants with eventually
different semantics ... :/)


The conservative array_at_struct_end_p has historically been used
for codegen.  component_ref_size was added as a separate function
with more flexible (including stricter) semantics to implement
warnings without running the risk of interfering with codegen.

Martin



Richard.




Okay for commit to Gcc13?

thanks.

Qing

===

gcc/

PR tree-optimization/101836
* common.opt (fstrict-flex-array, fstrict-flex-array=): New options.
* doc/invoke.texi (-fstrict-flex-array, -fstrict-flex-array=): Document.
* tree-object-size.cc (addr_object_size): Call is_flexible_array_p to
check whether an array is a flexible array.
* tree.cc (special_array_member_type): New routine.
(is_flexible_array_p): New routine.
(component_ref_size): Call special_array_member_type to decide the
type of special array member.
* tree.h (enum struct special_array_member): Add is_vla, trail_flex.
(special_array_member_type): New prototype.
(is_flexible_array_p): New prototype.

gcc/testsuite/

PR tree-optimization/101836
* gcc.dg/pr101836.c: New test.
* gcc.dg/pr101836_1.c: New test.
* gcc.dg/pr101836_2.c: New test.
* gcc.dg/pr101836_3.c: New test.
* gcc.dg/pr101836_4.c: New test.
* gcc.dg/pr101836_5.c: New test.


The complete patch is:





Re: [GCC 13][PATCH] PR101836: Add a new option -fstrict-flex-array[=n] and use it in __builtin_object_size

2022-06-28 Thread Jakub Jelinek via Gcc-patches
On Tue, Jun 28, 2022 at 03:59:22PM +, Qing Zhao via Gcc-patches wrote:
> > On Jun 28, 2022, at 11:08 AM, Jakub Jelinek  wrote:
> > 
> > On Tue, Jun 28, 2022 at 03:03:12PM +, Qing Zhao wrote:
> >> 2. Then replace all “array_at_struct_end_p” with using DECL_NOT_FLEXARRAY 
> >> in GCC, adding new testing cases
> > 
> > No, IMHO array_at_struct_end_p should stay as is, just test this extra flag
> > too.
> 
> Could you please explain why we still need “array_at_struct_end_p” after we 
> have the DECL_NOT_FLEXARRAY flag in FIELD_DECL?

Because the flag just tells whether some array shouldn't be treated as (poor 
man's)
flexible array member.  We still need to find out if some FIELD_DECL is to
be treated like a flexible array member, which is a minority of
COMPONENT_REFs.
struct S { int a; char b[0]; int c; } s;
struct T { int d; char e[]; };
struct U { int f; struct T g; int h; } u;
Neither s.b nor u.g.e is to be treated like flexible array member,
no matter what -fstrict-flex-array= option is used.

Jakub



Go patch committed: Permit abstract bool expressions to remain abstract

2022-06-28 Thread Ian Lance Taylor via Gcc-patches
This patch to the Go frontend permits expressions of abstract bool to
remain abstract, rather than forcing them into the named type bool.
The test case for this is https://go.dev/cl/414755.  This fixes
https://go.dev/issue/51475.  Bootstrarpped and ran Go testsuite on
x86_64-pc-linux-gnu.  Committed to mainline.

Ian
eebc9c8f0b23acddea253eb5a44f59f44f3f466b
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index 16d274ce99d..a0e386ab4f6 100644
--- a/gcc/go/gofrontend/MERGE
+++ b/gcc/go/gofrontend/MERGE
@@ -1,4 +1,4 @@
-927528cdc112fc51e0d07ee79e7a1254b586eabe
+28fe9fad4acb4e02083faf5503b06e3e6e8eecaf
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
diff --git a/gcc/go/gofrontend/expressions.cc b/gcc/go/gofrontend/expressions.cc
index f59f61d19ad..aadca9710e6 100644
--- a/gcc/go/gofrontend/expressions.cc
+++ b/gcc/go/gofrontend/expressions.cc
@@ -6829,11 +6829,12 @@ Binary_expression::do_determine_type(const 
Type_context* context)
 {
   if ((tleft->integer_type() != NULL && tright->integer_type() != NULL)
  || (tleft->float_type() != NULL && tright->float_type() != NULL)
- || (tleft->complex_type() != NULL && tright->complex_type() != NULL))
+ || (tleft->complex_type() != NULL && tright->complex_type() != NULL)
+ || (tleft->is_boolean_type() && tright->is_boolean_type()))
{
- // Both sides have an abstract integer, abstract float, or
- // abstract complex type.  Just let CONTEXT determine
- // whether they may remain abstract or not.
+ // Both sides have an abstract integer, abstract float,
+ // abstract complex, or abstract boolean type.  Just let
+ // CONTEXT determine whether they may remain abstract or not.
}
   else if (tleft->complex_type() != NULL)
subcontext.type = tleft;


Order Status #AMZN28-8823133

2022-06-28 Thread Order Status
amazon

INVOICE #AMZN28-8823133


Hi gcc-patches@gcc.gnu.org,

Confirmation for your recent purchase with us. Your package has been confirmed 
and ready to dispatch. You will receive your package by 4th July 2022

You can check your order details below.

Help-Desk : +1 (833) 210-2074

Order summary
2022 Apple iPad Air (10.9-inch, Wi-Fi, 64GB)

$ 569.00

Apple Pencil (2nd Generation)

$ 99.00


Discount

$ 60.00

Subtotal

$ 668.00

Shipping

Rs. 0.00

Total

$ 668.00

Shipping address

David H
68 W Palm Ave,

Lake Worth,
FL 33467, USA



Payment method

Online/Direct Debit $ 668.00


If you have any questions regarding this email, reach us on our Help-Desk 
within 24Hrs


Re: [PATCH] rtl-optimization/106082 - preserve EH note for no non-local goto

2022-06-28 Thread Segher Boessenkool
On Tue, Jun 28, 2022 at 11:11:55AM +, Richard Biener wrote:
> The following makes sure we preserve EH notes on call insns that
> indicate the call doesn't perform a non-local goto when distributing
> notes after combining insns.

> - if (!insn_could_throw_p (from_insn))
> -   /* Throw away stra notes on insns that can never throw.  */
> + if (!insn_could_throw_p (from_insn)
> + && (lp_nr != INT_MIN || !can_nonlocal_goto (from_insn)))
> +   /* Throw away stray notes on insns that can never throw or
> +  make a nonlocal goto.  */
> ;

Where is the meaning of INT_MIN here documented?

... Ah, in except.cc .

Can you write this as

if (!insn_could_throw_p (from_insn)
&& !(lp_nr == INT_MIN && can_nonlocal_goto (from_insn)))

please?  It is easier to understand that way.

With or without that, okay for trunk.  Thanks!


Segher


[committed] d: Add @simd and @simd_clones attributes to compiler and library

2022-06-28 Thread Iain Buclaw via Gcc-patches
Hi,

This patch adds a `@simd' attribute to the D front-end, which is
equivalent to `__attribute__((simd))', and `@simd_clones' is a
convenience alias to allow specifying whether the compiler should
generated masked or non-masked simd clones.

Bootstrapped and regression tested on x86_64-linux-gnu/-m32/-mx32, and
committed to mainline.

Regards,
Iain.

---
gcc/d/ChangeLog:

* d-attribs.cc (handle_omp_declare_simd_attribute): New function.
(d_handle_simd_attribute): New function.
(d_langhook_common_attribute_table): Add 'omp declare simd' attribute.
(d_langhook_attribute_table): Add simd attribute.

libphobos/ChangeLog:

* libdruntime/gcc/attributes.d (simd): Define.

gcc/testsuite/ChangeLog:

* gdc.dg/attr_simd1.d: New test.
* gdc.dg/attr_simd2.d: New test.
---
 gcc/d/d-attribs.cc | 65 ++
 gcc/testsuite/gdc.dg/attr_simd1.d  | 40 
 gcc/testsuite/gdc.dg/attr_simd2.d  | 16 +++
 libphobos/libdruntime/gcc/attributes.d | 40 
 4 files changed, 161 insertions(+)
 create mode 100644 gcc/testsuite/gdc.dg/attr_simd1.d
 create mode 100644 gcc/testsuite/gdc.dg/attr_simd2.d

diff --git a/gcc/d/d-attribs.cc b/gcc/d/d-attribs.cc
index 1dd806f7144..04f7f1686a2 100644
--- a/gcc/d/d-attribs.cc
+++ b/gcc/d/d-attribs.cc
@@ -58,6 +58,7 @@ static tree handle_type_generic_attribute (tree *, tree, 
tree, int, bool *);
 static tree handle_transaction_pure_attribute (tree *, tree, tree, int, bool 
*);
 static tree handle_returns_twice_attribute (tree *, tree, tree, int, bool *);
 static tree handle_fnspec_attribute (tree *, tree, tree, int, bool *);
+static tree handle_omp_declare_simd_attribute (tree *, tree, tree, int, bool 
*);
 
 /* D attribute handlers for user defined attributes.  */
 static tree d_handle_noinline_attribute (tree *, tree, tree, int, bool *);
@@ -80,6 +81,7 @@ static tree d_handle_restrict_attribute (tree *, tree, tree, 
int, bool *);
 static tree d_handle_used_attribute (tree *, tree, tree, int, bool *);
 static tree d_handle_visibility_attribute (tree *, tree, tree, int, bool *);
 static tree d_handle_no_sanitize_attribute (tree *, tree, tree, int, bool *);
+static tree d_handle_simd_attribute (tree *, tree, tree, int, bool *);
 
 /* Helper to define attribute exclusions.  */
 #define ATTR_EXCL(name, function, type, variable)  \
@@ -186,6 +188,8 @@ const attribute_spec d_langhook_common_attribute_table[] =
 handle_type_generic_attribute, NULL),
   ATTR_SPEC ("fn spec", 1, 1, false, true, true, false,
 handle_fnspec_attribute, NULL),
+  ATTR_SPEC ("omp declare simd", 0, -1, true,  false, false, false,
+handle_omp_declare_simd_attribute, NULL),
   ATTR_SPEC (NULL, 0, 0, false, false, false, false, NULL, NULL),
 };
 
@@ -228,6 +232,8 @@ const attribute_spec d_langhook_attribute_table[] =
 d_handle_register_attribute, NULL),
   ATTR_SPEC ("restrict", 0, 0, true, false, false, false,
 d_handle_restrict_attribute, NULL),
+  ATTR_SPEC ("simd", 0, 1, true,  false, false, false,
+d_handle_simd_attribute, NULL),
   ATTR_SPEC ("used", 0, 0, true, false, false, false,
 d_handle_used_attribute, NULL),
   ATTR_SPEC ("visibility", 1, 1, false, false, false, false,
@@ -664,6 +670,16 @@ handle_fnspec_attribute (tree *, tree, tree args, int, 
bool *)
   return NULL_TREE;
 }
 
+/* Handle an "omp declare simd" attribute; arguments as in
+   struct attribute_spec.handler.  */
+
+tree
+handle_omp_declare_simd_attribute (tree *node, tree, tree, int, bool *)
+{
+  gcc_assert (TREE_CODE (*node) == FUNCTION_DECL);
+  return NULL_TREE;
+}
+
 /* Language specific attribute handlers.
These functions take the arguments:
(tree *node, tree name, tree args, int flags, bool *no_add_attrs)  */
@@ -1474,6 +1490,55 @@ d_handle_restrict_attribute (tree *node, tree name, 
tree, int,
   return NULL_TREE;
 }
 
+/* Handle a "simd" attribute; arguments as in
+   struct attribute_spec.handler.  */
+
+static tree
+d_handle_simd_attribute (tree *node, tree name, tree args, int,
+bool *no_add_attrs)
+{
+  if (TREE_CODE (*node) != FUNCTION_DECL)
+{
+  warning (OPT_Wattributes, "%qE attribute ignored", name);
+  *no_add_attrs = true;
+  return NULL_TREE;
+}
+
+  tree omp_attr = get_identifier ("omp declare simd");
+  tree omp_flags = NULL_TREE;
+  if (args)
+{
+  tree id = TREE_VALUE (args);
+
+  if (TREE_CODE (id) != STRING_CST)
+   {
+ error ("%qE attribute argument not a string constant", name);
+ *no_add_attrs = true;
+ return NULL_TREE;
+   }
+
+  if (strcmp (TREE_STRING_POINTER (id), "notinbranch") == 0)
+   omp_flags = build_omp_clause (DECL_SOURCE_LOCATION (*node),
+ OMP_CLAUSE_NOTINBRANCH);
+  else if (strcmp (TREE_STRING_POINTER (id), "inbranch") == 0)
+   omp_flags = build_

[committed] d: Use create_tmp_var_raw and get_callee_fndecl

2022-06-28 Thread Iain Buclaw via Gcc-patches
Hi,

A couple of small patterns that repeat are generating a temporary, and
getting a function out of a CALL_EXPR (there are other changes that are
in the works where I ended up adding more repeats of these patterns).
There are convenience functions for these in the common parts of gcc,
use them instead.

Regstrapped on x86_64-linux-gnu, and committed to mainline.

Regards,
Iain.

---
gcc/d/ChangeLog:

* d-codegen.cc: Include gimple-expr.h.
(force_target_expr): Use create_tmp_var_raw.
* decl.cc: Inlucde gimple-expr.h.
(build_local_temp): Use create_tmp_var_raw.
* intrinsics.cc (expand_intrinsic_rotate): Use get_callee_fndecl.
(maybe_expand_intrinsic): Likewise.
---
 gcc/d/d-codegen.cc  |  6 ++
 gcc/d/decl.cc   |  7 ++-
 gcc/d/intrinsics.cc | 13 +++--
 3 files changed, 7 insertions(+), 19 deletions(-)

diff --git a/gcc/d/d-codegen.cc b/gcc/d/d-codegen.cc
index 8a8bf12e7fc..2d90899b37f 100644
--- a/gcc/d/d-codegen.cc
+++ b/gcc/d/d-codegen.cc
@@ -38,6 +38,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "stor-layout.h"
 #include "attribs.h"
 #include "function.h"
+#include "gimple-expr.h"
 
 #include "d-tree.h"
 
@@ -623,11 +624,8 @@ build_target_expr (tree decl, tree exp)
 tree
 force_target_expr (tree exp)
 {
-  tree decl = build_decl (input_location, VAR_DECL, NULL_TREE,
- TREE_TYPE (exp));
+  tree decl = create_tmp_var_raw (TREE_TYPE (exp));
   DECL_CONTEXT (decl) = current_function_decl;
-  DECL_ARTIFICIAL (decl) = 1;
-  DECL_IGNORED_P (decl) = 1;
   layout_decl (decl, 0);
 
   return build_target_expr (decl, exp);
diff --git a/gcc/d/decl.cc b/gcc/d/decl.cc
index 5032ae02d6b..3caa465dd1e 100644
--- a/gcc/d/decl.cc
+++ b/gcc/d/decl.cc
@@ -57,6 +57,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "alloc-pool.h"
 #include "symbol-summary.h"
 #include "symtab-thunks.h"
+#include "gimple-expr.h"
 
 #include "d-tree.h"
 #include "d-target.h"
@@ -1465,11 +1466,7 @@ declare_local_var (VarDeclaration *var)
 tree
 build_local_temp (tree type)
 {
-  tree decl = build_decl (input_location, VAR_DECL, NULL_TREE, type);
-
-  DECL_CONTEXT (decl) = current_function_decl;
-  DECL_ARTIFICIAL (decl) = 1;
-  DECL_IGNORED_P (decl) = 1;
+  tree decl = create_tmp_var_raw (type);
   d_pushdecl (decl);
 
   return decl;
diff --git a/gcc/d/intrinsics.cc b/gcc/d/intrinsics.cc
index 0f96284473f..0dd5543fdd1 100644
--- a/gcc/d/intrinsics.cc
+++ b/gcc/d/intrinsics.cc
@@ -421,12 +421,8 @@ expand_intrinsic_rotate (intrinsic_code intrinsic, tree 
callexp)
 count = CALL_EXPR_ARG (callexp, 1);
   else
 {
-  tree callee = CALL_EXPR_FN (callexp);
-
-  if (TREE_CODE (callee) == ADDR_EXPR)
-   callee = TREE_OPERAND (callee, 0);
-
   /* Retrieve from the encoded template instantation.  */
+  tree callee = get_callee_fndecl (callexp);
   TemplateInstance *ti = DECL_LANG_FRONTEND (callee)->isInstantiated ();
   gcc_assert (ti && ti->tiargs && ti->tiargs->length == 2);
 
@@ -761,12 +757,9 @@ expand_volatile_store (tree callexp)
 tree
 maybe_expand_intrinsic (tree callexp)
 {
-  tree callee = CALL_EXPR_FN (callexp);
-
-  if (TREE_CODE (callee) == ADDR_EXPR)
-callee = TREE_OPERAND (callee, 0);
+  tree callee = get_callee_fndecl (callexp);
 
-  if (TREE_CODE (callee) != FUNCTION_DECL)
+  if (callee == NULL_TREE || TREE_CODE (callee) != FUNCTION_DECL)
 return callexp;
 
   /* Don't expand CTFE-only intrinsics outside of semantic processing.  */
-- 
2.34.1



libgo patch committed: Make runtime.Version return a useful value

2022-06-28 Thread Ian Lance Taylor via Gcc-patches
This libgo patch makes runtime.Version return a meaningful string.
This also means that "go version" will print something useful, e.g.,

go version go1.18 gccgo (GCC) 12.0.1 20220216 (experimental) linux/amd64

This fixes https://go.dev/issue/51850.

Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.  Committed
to mainline.

Ian
0d8541c7c906c92c750c779958beafb0e0dbfe47
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index a0e386ab4f6..551ea650acf 100644
--- a/gcc/go/gofrontend/MERGE
+++ b/gcc/go/gofrontend/MERGE
@@ -1,4 +1,4 @@
-28fe9fad4acb4e02083faf5503b06e3e6e8eecaf
+d5b4abed2f206e492890acc20738e89617ea542c
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
diff --git a/libgo/Makefile.am b/libgo/Makefile.am
index a5d4b6a3525..b03e6553e90 100644
--- a/libgo/Makefile.am
+++ b/libgo/Makefile.am
@@ -568,6 +568,7 @@ s-goroot: Makefile
rm -f goroot.go.tmp
echo "package runtime" > goroot.go.tmp
echo 'var defaultGOROOT = `$(prefix)`' >> goroot.go.tmp
+   echo 'var buildVersion = `'`cat $(srcdir)/VERSION | sed 1q`' '`$(GOC) 
--version | sed 1q`'`' >> goroot.go.tmp
$(SHELL) $(srcdir)/mvifdiff.sh goroot.go.tmp goroot.go
$(STAMP) $@
 
diff --git a/libgo/Makefile.in b/libgo/Makefile.in
index 22f48a52938..16ed62a82ed 100644
--- a/libgo/Makefile.in
+++ b/libgo/Makefile.in
@@ -2780,6 +2780,7 @@ s-goroot: Makefile
rm -f goroot.go.tmp
echo "package runtime" > goroot.go.tmp
echo 'var defaultGOROOT = `$(prefix)`' >> goroot.go.tmp
+   echo 'var buildVersion = `'`cat $(srcdir)/VERSION | sed 1q`' '`$(GOC) 
--version | sed 1q`'`' >> goroot.go.tmp
$(SHELL) $(srcdir)/mvifdiff.sh goroot.go.tmp goroot.go
$(STAMP) $@
 
diff --git a/libgo/go/runtime/extern.go b/libgo/go/runtime/extern.go
index a371d9c0ee0..8e226147965 100644
--- a/libgo/go/runtime/extern.go
+++ b/libgo/go/runtime/extern.go
@@ -231,16 +231,6 @@ func GOROOT() string {
return defaultGOROOT
 }
 
-// buildVersion is the Go tree's version string at build time.
-//
-// If any GOEXPERIMENTs are set to non-default values, it will include
-// "X:".
-//
-// This is set by the linker.
-//
-// This is accessed by "go version ".
-var buildVersion string
-
 // Version returns the Go tree's version string.
 // It is either the commit hash and date at the time of the build or,
 // when possible, a release tag like "go1.3".


Go patch committed: Use package path with embedded builtin

2022-06-28 Thread Ian Lance Taylor via Gcc-patches
This patch to the Go frontend changes the mangled name of a struct to
use the package path with an embedded builtin type.  The test case is
https://go.dev/cl/414235.  This fixes https://go.dev/issue/52856.
Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.  Committed
to mainline.

Ian
74956337e8276e5bc9524104b01c147374dd94e7
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index 551ea650acf..13cb6ea4046 100644
--- a/gcc/go/gofrontend/MERGE
+++ b/gcc/go/gofrontend/MERGE
@@ -1,4 +1,4 @@
-d5b4abed2f206e492890acc20738e89617ea542c
+c7238f58a26131b7611eff6f555cab02af8a623c
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
diff --git a/gcc/go/gofrontend/names.cc b/gcc/go/gofrontend/names.cc
index f85d84ceadf..dac7f20f5c1 100644
--- a/gcc/go/gofrontend/names.cc
+++ b/gcc/go/gofrontend/names.cc
@@ -831,15 +831,28 @@ Struct_type::do_mangled_name(Gogo* gogo, std::string* ret,
  ret->push_back(' ');
}
 
- // For an anonymous field with an alias type, the field name
- // is the alias name.
- if (p->is_anonymous()
- && p->type()->named_type() != NULL
- && p->type()->named_type()->is_alias())
-   p->type()->named_type()->append_symbol_type_name(gogo, true, ret,
-is_non_identifier);
+ const Type* ft = p->type();
+ const Named_type* nt = ft->named_type();
+
+ if (p->is_anonymous() && nt != NULL && nt->is_builtin())
+   {
+ // For an embedded field with a builtin type, we must
+ // include a package path.  Otherwise embedding builtin
+ // types in different packages will produce identical
+ // types, which shouldn't happen because the builtin
+ // types are not exported.
+ ret->append(gogo->pkgpath());
+ ret->push_back('.');
+ nt->append_symbol_type_name(gogo, true, ret, is_non_identifier);
+   }
+ else if (p->is_anonymous() && nt != NULL && nt->is_alias())
+   {
+ // For an anonymous field with an alias type, the field name
+ // is the alias name.
+ nt->append_symbol_type_name(gogo, true, ret, is_non_identifier);
+   }
  else
-   this->append_mangled_name(p->type(), gogo, ret, is_non_identifier);
+   this->append_mangled_name(ft, gogo, ret, is_non_identifier);
 
  if (p->has_tag())
{


Re: [GCC 13][PATCH] PR101836: Add a new option -fstrict-flex-array[=n] and use it in __builtin_object_size

2022-06-28 Thread Qing Zhao via Gcc-patches


> On Jun 28, 2022, at 12:43 PM, Jakub Jelinek  wrote:
> 
> On Tue, Jun 28, 2022 at 03:59:22PM +, Qing Zhao via Gcc-patches wrote:
>>> On Jun 28, 2022, at 11:08 AM, Jakub Jelinek  wrote:
>>> 
>>> On Tue, Jun 28, 2022 at 03:03:12PM +, Qing Zhao wrote:
 2. Then replace all “array_at_struct_end_p” with using DECL_NOT_FLEXARRAY 
 in GCC, adding new testing cases
>>> 
>>> No, IMHO array_at_struct_end_p should stay as is, just test this extra flag
>>> too.
>> 
>> Could you please explain why we still need “array_at_struct_end_p” after we 
>> have the DECL_NOT_FLEXARRAY flag in FIELD_DECL?
> 
> Because the flag just tells whether some array shouldn't be treated as (poor 
> man's)
> flexible array member.  We still need to find out if some FIELD_DECL is to
> be treated like a flexible array member, which is a minority of
> COMPONENT_REFs.
> struct S { int a; char b[0]; int c; } s;
> struct T { int d; char e[]; };
> struct U { int f; struct T g; int h; } u;
> Neither s.b nor u.g.e is to be treated like flexible array member,
> no matter what -fstrict-flex-array= option is used.

Then, to resolve this issue, we might need a opposite  flag DECL_IS_FLEXARRAY 
in FIELD_DECL?

The default is FALSE for all FIELD_DECL.

Only when the FIELD_DECL is a flexible array member, FE will set it to TRUE. 

i.e, FE needs to check

1. The FIELD_DECL is the last field of the enclosing structure;
+  2. This FIELD_DECL is a flexible array per -fstrict-flex-array=n;

Then whenever the DECL_IS_FLEXARRAY is set to TRUE by FEs, that means the 
FIELD_DECL is an flexible array member.  
Middle-end then just use this flag to decide whether an array reference is a 
flexible array  or not.

Any comments?

Qing

> 
>   Jakub
> 



Re: [GCC 13][PATCH] PR101836: Add a new option -fstrict-flex-array[=n] and use it in __builtin_object_size

2022-06-28 Thread Jakub Jelinek via Gcc-patches
On Tue, Jun 28, 2022 at 06:15:58PM +, Qing Zhao wrote:
> > Because the flag just tells whether some array shouldn't be treated as 
> > (poor man's)
> > flexible array member.  We still need to find out if some FIELD_DECL is to
> > be treated like a flexible array member, which is a minority of
> > COMPONENT_REFs.
> > struct S { int a; char b[0]; int c; } s;
> > struct T { int d; char e[]; };
> > struct U { int f; struct T g; int h; } u;
> > Neither s.b nor u.g.e is to be treated like flexible array member,
> > no matter what -fstrict-flex-array= option is used.
> 
> Then, to resolve this issue, we might need a opposite  flag DECL_IS_FLEXARRAY 
> in FIELD_DECL?
> 
> The default is FALSE for all FIELD_DECL.

Doesn't matter whether it is positive or negative, you still need to analyze
it.  See the above example.  If you have struct T t; and test t.e, then it
is flexarray.  But u.g.e is not, even when the COMPONENT_REF refers to the
same FIELD_DECL.  In the t.e case e is the very last field, in the latter
case u.g.e is the last field in struct T, but struct U has the h field after
it.

Jakub



Re: [GCC 13][PATCH] PR101836: Add a new option -fstrict-flex-array[=n] and use it in __builtin_object_size

2022-06-28 Thread Qing Zhao via Gcc-patches



> On Jun 28, 2022, at 2:22 PM, Jakub Jelinek  wrote:
> 
> On Tue, Jun 28, 2022 at 06:15:58PM +, Qing Zhao wrote:
>>> Because the flag just tells whether some array shouldn't be treated as 
>>> (poor man's)
>>> flexible array member.  We still need to find out if some FIELD_DECL is to
>>> be treated like a flexible array member, which is a minority of
>>> COMPONENT_REFs.
>>> struct S { int a; char b[0]; int c; } s;
>>> struct T { int d; char e[]; };
>>> struct U { int f; struct T g; int h; } u;
>>> Neither s.b nor u.g.e is to be treated like flexible array member,
>>> no matter what -fstrict-flex-array= option is used.
>> 
>> Then, to resolve this issue, we might need a opposite  flag 
>> DECL_IS_FLEXARRAY in FIELD_DECL?
>> 
>> The default is FALSE for all FIELD_DECL.
> 
> Doesn't matter whether it is positive or negative, you still need to analyze
> it.  See the above example.  If you have struct T t; and test t.e, then it
> is flexarray.  But u.g.e is not, even when the COMPONENT_REF refers to the
> same FIELD_DECL.  In the t.e case e is the very last field, in the latter
> case u.g.e is the last field in struct T, but struct U has the h field after

So, do you mean that the current FE analysis will not be able to decide whether 
a specific array field is at the end of the enclosing structure? 
Only the middle end can decide this ?

Qing
> it.
> 
>   Jakub
> 



Re: [GCC 13][PATCH] PR101836: Add a new option -fstrict-flex-array[=n] and use it in __builtin_object_size

2022-06-28 Thread Jakub Jelinek via Gcc-patches
On Tue, Jun 28, 2022 at 06:29:01PM +, Qing Zhao wrote:
> 
> 
> > On Jun 28, 2022, at 2:22 PM, Jakub Jelinek  wrote:
> > 
> > On Tue, Jun 28, 2022 at 06:15:58PM +, Qing Zhao wrote:
> >>> Because the flag just tells whether some array shouldn't be treated as 
> >>> (poor man's)
> >>> flexible array member.  We still need to find out if some FIELD_DECL is to
> >>> be treated like a flexible array member, which is a minority of
> >>> COMPONENT_REFs.
> >>> struct S { int a; char b[0]; int c; } s;
> >>> struct T { int d; char e[]; };
> >>> struct U { int f; struct T g; int h; } u;
> >>> Neither s.b nor u.g.e is to be treated like flexible array member,
> >>> no matter what -fstrict-flex-array= option is used.
> >> 
> >> Then, to resolve this issue, we might need a opposite  flag 
> >> DECL_IS_FLEXARRAY in FIELD_DECL?
> >> 
> >> The default is FALSE for all FIELD_DECL.
> > 
> > Doesn't matter whether it is positive or negative, you still need to analyze
> > it.  See the above example.  If you have struct T t; and test t.e, then it
> > is flexarray.  But u.g.e is not, even when the COMPONENT_REF refers to the
> > same FIELD_DECL.  In the t.e case e is the very last field, in the latter
> > case u.g.e is the last field in struct T, but struct U has the h field after
> 
> So, do you mean that the current FE analysis will not be able to decide 
> whether a specific array field is at the end of the enclosing structure? 
> Only the middle end can decide this ?

Well, anything that analyzes it, can be in the FE or middle-end, but there
is no place to store it for later.

Jakub



Re: [GCC 13][PATCH] PR101836: Add a new option -fstrict-flex-array[=n] and use it in __builtin_object_size

2022-06-28 Thread Qing Zhao via Gcc-patches


> On Jun 28, 2022, at 2:49 PM, Jakub Jelinek  wrote:
> 
> On Tue, Jun 28, 2022 at 06:29:01PM +, Qing Zhao wrote:
>> 
>> 
>>> On Jun 28, 2022, at 2:22 PM, Jakub Jelinek  wrote:
>>> 
>>> On Tue, Jun 28, 2022 at 06:15:58PM +, Qing Zhao wrote:
> Because the flag just tells whether some array shouldn't be treated as 
> (poor man's)
> flexible array member.  We still need to find out if some FIELD_DECL is to
> be treated like a flexible array member, which is a minority of
> COMPONENT_REFs.
> struct S { int a; char b[0]; int c; } s;
> struct T { int d; char e[]; };
> struct U { int f; struct T g; int h; } u;
> Neither s.b nor u.g.e is to be treated like flexible array member,
> no matter what -fstrict-flex-array= option is used.
 
 Then, to resolve this issue, we might need a opposite  flag 
 DECL_IS_FLEXARRAY in FIELD_DECL?
 
 The default is FALSE for all FIELD_DECL.
>>> 
>>> Doesn't matter whether it is positive or negative, you still need to analyze
>>> it.  See the above example.  If you have struct T t; and test t.e, then it
>>> is flexarray.  But u.g.e is not, even when the COMPONENT_REF refers to the
>>> same FIELD_DECL.  In the t.e case e is the very last field, in the latter
>>> case u.g.e is the last field in struct T, but struct U has the h field after
>> 
>> So, do you mean that the current FE analysis will not be able to decide 
>> whether a specific array field is at the end of the enclosing structure? 
>> Only the middle end can decide this ?
> 
> Well, anything that analyzes it, can be in the FE or middle-end, but there
> is no place to store it for later.

Then I am a little confused: 

If the FE can decide wether an array field is at the end of the enclosing 
structure,  then combined with whether it’s a [0], [1] or [], and which level 
of -fstrict-flex-array, 

The FE should be able to decide whether this array field is a flexible array 
member or not, then set the flag DECL_IS_FLEXARRAY (or DECL_NOT_FLEXARRAY). 

The new flag is the place to store such info, right?
Do I miss anything here?

Qing
> 
>   Jakub



[PATCH] Fortran: improve error recovery for EXTENDS_TYPE_OF() [PR106121]

2022-06-28 Thread Harald Anlauf via Gcc-patches
Dear all,

the simplification of EXTENDS_TYPE_OF() did not handle the
situation that one of its arguments were a CLASS variable
that was improperly declared.  NULL pointer dereference.

The fix is obvious.  Steve found a similar solution, which
is why I added him as co-author.

Regtested on x86_64-pc-linux-gnu.

Will commit to mainline as obvious within 24 hours unless
there are loud objections.

Thanks,
Harald

From 55aacfd22d73edfb38871e211f85b2ae69fd0072 Mon Sep 17 00:00:00 2001
From: Harald Anlauf 
Date: Tue, 28 Jun 2022 22:29:28 +0200
Subject: [PATCH] Fortran: improve error recovery for EXTENDS_TYPE_OF()
 [PR106121]

gcc/fortran/ChangeLog:

	PR fortran/106121
	* simplify.cc (gfc_simplify_extends_type_of): Do not attempt to
	simplify when one of the arguments is a CLASS variable that was
	not properly declared.

gcc/testsuite/ChangeLog:

	PR fortran/106121
	* gfortran.dg/extends_type_of_4.f90: New test.

Co-authored-by: Steven G. Kargl 
---
 gcc/fortran/simplify.cc   |  4 
 .../gfortran.dg/extends_type_of_4.f90 | 20 +++
 2 files changed, 24 insertions(+)
 create mode 100644 gcc/testsuite/gfortran.dg/extends_type_of_4.f90

diff --git a/gcc/fortran/simplify.cc b/gcc/fortran/simplify.cc
index e8e3ec63669..ab59fbca622 100644
--- a/gcc/fortran/simplify.cc
+++ b/gcc/fortran/simplify.cc
@@ -3096,6 +3096,10 @@ gfc_simplify_extends_type_of (gfc_expr *a, gfc_expr *mold)
   if (UNLIMITED_POLY (a) || UNLIMITED_POLY (mold))
 return NULL;

+  if ((a->ts.type == BT_CLASS && !gfc_expr_attr (a).class_ok)
+  || (mold->ts.type == BT_CLASS && !gfc_expr_attr (mold).class_ok))
+return NULL;
+
   /* Return .false. if the dynamic type can never be an extension.  */
   if ((a->ts.type == BT_CLASS && mold->ts.type == BT_CLASS
&& !gfc_type_is_extension_of
diff --git a/gcc/testsuite/gfortran.dg/extends_type_of_4.f90 b/gcc/testsuite/gfortran.dg/extends_type_of_4.f90
new file mode 100644
index 000..64373322387
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/extends_type_of_4.f90
@@ -0,0 +1,20 @@
+! { dg-do compile }
+! PR fortran/106121 - ICE in gfc_simplify_extends_type_of
+! Contributed by G.Steinmetz
+
+program p
+   type t
+   end type
+   type(t)  :: x
+   class(t) :: y   ! { dg-error "dummy, allocatable or pointer" }
+   print *, extends_type_of (x, y)
+end
+
+subroutine s
+   type t
+  integer :: i
+   end type
+   type(t)  :: x
+   class(t) :: y   ! { dg-error "dummy, allocatable or pointer" }
+   stop extends_type_of (x, y) ! { dg-error "STOP code" }
+end
--
2.35.3



Re: [PATCH] libcpp: Update ucnid.h to Unicode 14

2022-06-28 Thread Joseph Myers
This patch is OK.

-- 
Joseph S. Myers
jos...@codesourcery.com


[PATCH v2] jit: avoid calloc() poisoning on musl [PR106102]

2022-06-28 Thread Sergei Trofimovich via Gcc-patches
From: Sergei Trofimovich 

On musl  uses calloc() (via ). jit/ includes
it directly and exposes use of poisoned calloc():

/build/build/./prev-gcc/xg++ ... 
../../gcc-13-20220626/gcc/jit/jit-playback.cc
make[3]: *** [Makefile:1143: jit/libgccjit.o] Error 1
make[3]: *** Waiting for unfinished jobs
In file included from /<>/musl-1.2.3-dev/include/pthread.h:30,
 from ../../gcc-13-20220626/gcc/jit/jit-playback.cc:44:
/<>/musl-1.2.3-dev/include/sched.h:84:7: error: attempt to use 
poisoned "calloc"
   84 | void *calloc(size_t, size_t);
  |   ^
/<>/musl-1.2.3-dev/include/sched.h:124:36: error: attempt to use 
poisoned "calloc"
  124 | #define CPU_ALLOC(n) ((cpu_set_t *)calloc(1,CPU_ALLOC_SIZE(n)))
  |^

The change moves  inclusion to "system.h" under new
INCLUDE_PTHREAD_H guard and uses this mechanism in libgccjit.

gcc/

PR c++/106102
* system.h: Introduce INCLUDE_PTHREAD_H macros to include .

gcc/jit/

PR c++/106102
* jit-playback.cc: Include  via "system.h" to avoid calloc()
poisoning.
* jit-recording.cc: Ditto.
* libgccjit.cc: Ditto.
---
 gcc/jit/jit-playback.cc  | 3 +--
 gcc/jit/jit-recording.cc | 2 +-
 gcc/jit/libgccjit.cc | 2 +-
 gcc/system.h | 4 
 4 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/gcc/jit/jit-playback.cc b/gcc/jit/jit-playback.cc
index 6be6bdf8dea..79714132b91 100644
--- a/gcc/jit/jit-playback.cc
+++ b/gcc/jit/jit-playback.cc
@@ -19,6 +19,7 @@ along with GCC; see the file COPYING3.  If not see
 .  */
 
 #include "config.h"
+#define INCLUDE_PTHREAD_H
 #include "system.h"
 #include "coretypes.h"
 #include "target.h"
@@ -41,8 +42,6 @@ along with GCC; see the file COPYING3.  If not see
 #include "diagnostic.h"
 #include "stmt.h"
 
-#include 
-
 #include "jit-playback.h"
 #include "jit-result.h"
 #include "jit-builtins.h"
diff --git a/gcc/jit/jit-recording.cc b/gcc/jit/jit-recording.cc
index 697dee66e73..f78daed2d71 100644
--- a/gcc/jit/jit-recording.cc
+++ b/gcc/jit/jit-recording.cc
@@ -19,13 +19,13 @@ along with GCC; see the file COPYING3.  If not see
 .  */
 
 #include "config.h"
+#define INCLUDE_PTHREAD_H
 #include "system.h"
 #include "coretypes.h"
 #include "tm.h"
 #include "pretty-print.h"
 #include "toplev.h"
 
-#include 
 
 #include "jit-builtins.h"
 #include "jit-recording.h"
diff --git a/gcc/jit/libgccjit.cc b/gcc/jit/libgccjit.cc
index 0e76097b4ba..ca862662777 100644
--- a/gcc/jit/libgccjit.cc
+++ b/gcc/jit/libgccjit.cc
@@ -19,12 +19,12 @@ along with GCC; see the file COPYING3.  If not see
 .  */
 
 #include "config.h"
+#define INCLUDE_PTHREAD_H
 #include "system.h"
 #include "coretypes.h"
 #include "timevar.h"
 #include "typed-splay-tree.h"
 #include "cppbuiltin.h"
-#include 
 
 #include "libgccjit.h"
 #include "jit-recording.h"
diff --git a/gcc/system.h b/gcc/system.h
index 67158b70c78..f8d42ff6815 100644
--- a/gcc/system.h
+++ b/gcc/system.h
@@ -753,6 +753,10 @@ extern int vsnprintf (char *, size_t, const char *, 
va_list);
 #endif
 #endif
 
+#ifdef INCLUDE_PTHREAD_H
+#include 
+#endif
+
 #ifdef INCLUDE_ISL
 #ifdef HAVE_isl
 #include 
-- 
2.36.1



Re: [committed] openmp: Add support for HBW or large capacity or interleaved memory through the libmemkind.so library

2022-06-28 Thread Andrew Stubbs

On 09/06/2022 09:19, Jakub Jelinek via Gcc-patches wrote:

+  switch (memspace)
+{
+case omp_high_bw_mem_space:
+#ifdef LIBGOMP_USE_MEMKIND
+  struct gomp_memkind_data *memkind_data;
+  memkind_data = gomp_get_memkind ();
+  if (data.partition == omp_atv_interleaved
+ && memkind_data->kinds[GOMP_MEMKIND_HBW_INTERLEAVE])
+   {
+ data.memkind = GOMP_MEMKIND_HBW_INTERLEAVE;
+ break;
+   }
+  else if (memkind_data->kinds[GOMP_MEMKIND_HBW_PREFERRED])
+   {
+ data.memkind = GOMP_MEMKIND_HBW_PREFERRED;
+ break;
+   }
+#endif
+  return omp_null_allocator;
+case omp_large_cap_mem_space:
+#ifdef LIBGOMP_USE_MEMKIND
+  memkind_data = gomp_get_memkind ();
+  if (memkind_data->kinds[GOMP_MEMKIND_DAX_KMEM_ALL])
+   data.memkind = GOMP_MEMKIND_DAX_KMEM_ALL;
+  else if (memkind_data->kinds[GOMP_MEMKIND_DAX_KMEM])
+   data.memkind = GOMP_MEMKIND_DAX_KMEM;
+#endif
+  break;
+default:
+#ifdef LIBGOMP_USE_MEMKIND
+  if (data.partition == omp_atv_interleaved)
+   {
+ memkind_data = gomp_get_memkind ();
+ if (memkind_data->kinds[GOMP_MEMKIND_INTERLEAVE])
+   data.memkind = GOMP_MEMKIND_INTERLEAVE;
+   }
+#endif
+  break;
+}
+


This conflicts with mine and Abid's patches to implement the device 
allocators and host unified shared memory via the overridable 
"MEMSPACE_ALLOC" hooks. I can still use those for the "else" case, but 
they'll be inactive on any configuration where libmemkind exists. That's 
fine for the device code, and may be OK for USM (given that libmemkind 
won't have an option for that). There's a problem for the 
NVidia-specific host-memory pinning I have planned though.


How do you propose we resolve this conflict, please?

Ideally it will be in such a way that the conditional is resolved at 
compile time and the routine can be inlined (so no fake-OO function 
pointers in structs, I think).


Thanks

Andrew


Re: [PATCH] libgccjit: Fix bug where unary_op will return an integer type instead of the correct type

2022-06-28 Thread David Malcolm via Gcc-patches
On Wed, 2022-06-01 at 22:13 -0400, Antoni Boucher via Gcc-patches
wrote:
> Hi.
> The attached patch fix bug 105812:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105812

Thanks; the patch looks good to me, assuming it's been tested in the
usual way, with one nit: the "PR target/105812" in the ChangeLog should
presuambly be "PR jit/105812".

> 
> I'm having an issue where contrib/check_GNU_style.sh doesn't seem to
> work, i.e. it doesn't seem to do any checking.
> Is there a new way to do that or am I missing something?

I confess I've never actually used that script.

Dave




Re: [PATCH] libgccjit: Fix bug where unary_op will return an integer type instead of the correct type

2022-06-28 Thread David Malcolm via Gcc-patches
On Wed, 2022-06-01 at 22:45 -0400, Antoni Boucher via Gcc-patches
wrote:
> Also, the test gcc/testsuite/jit.dg/test-asm.cc fails and would need
> this line:
> 
> #include 

I'm curious; how is it failing?

> 
> Is this okay if I add it in this patch?
> 
> On Wed, 2022-06-01 at 22:13 -0400, Antoni Boucher wrote:
> > Hi.
> > The attached patch fix bug 105812:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105812
> > 
> > I'm having an issue where contrib/check_GNU_style.sh doesn't seem
> > to
> > work, i.e. it doesn't seem to do any checking.
> > Is there a new way to do that or am I missing something?
> > 
> > Thanks for the review.
> 




[committed] d: Add SIMD intrinsics module and compiler built-ins.

2022-06-28 Thread Iain Buclaw via Gcc-patches
Hi,

This patch adds a SIMD intrinsics module, and compiler intrinsics.

Vectors in D are exposed by the use of the `__vector(T[N])' type, and
whilst most unary and binary operations work as you'd expect, there are
some operations that are not possible without doing the operation
unrolled, or calling some target-specific built-in, or with inline asm.

This introduces a new `gcc.simd' module that introduces the following.

 - Prefetching has been exposed by a convenient `prefetch' function in
   the library.

 - Loading and storing from an unaligned address have been exposed by
   `loadUnaligned' and `storeUnaligned' intrinsics.

 - Vector permutations have been exposed by `shuffle`, and
   `shufflevector' intrinsics.

 - Converting between two vectors with a different element type has been
   exposed by a `convertvector' intrinsic.

 - The ternary operator has been exposed with a `blendvector' intrinsic.

 - Comparison operators have been exposed by `equalMask',
   `notEqualMask', `greaterMask', and `greaterEqualMask' intrinsics.

 - Logic operators have been exposed by convenient `notMask',
   `andAndMask', and `orOrMask' functions in the library.

To be compatible with the LLVM D compiler's own SIMD intrinsic module,
there is also the addition of an `extractelement' and `insertelement'
convenience functions, and an alternative interface for calling the
`shufflevector' function.

The addition of these intrinsics lowers the boundary for users working
in SIMD to get the desired codegen they want out of the compiler.

Most of what is present here - apart from tests - is the adding of
machinery in the intrinsics suite of functions to do validation on
templated intrinsics.  Whilst these are still matched from the library
by their generic (untyped) signature, there is a still an assumption
that what has been instantiated and handed down to the code generator is
valid, because why would these definitions be found outside of the
in-tree D runtime library?  The majority of intrinsics are not
templates, so the test on the mangled signature string still guarantees
all types are as we expect them to be.  However there are still a small
handful of other templated intrinsics (core.bitop.{rol,ror},
core.math.toPrec, std.math.traits.isNaN, ...) that are currently
unchecked, so would benefit from being included into this built-in
checking function at some point in the future.

Regression tested and bootstrapped on x86_64-linux-gnu/-m32/-mx32, and
committed to mainline.

Regards,
Iain

---
gcc/d/ChangeLog:

* intrinsics.cc: Include diagnostic.h, langhooks.h,
vec-perm-indices.h.
(maybe_set_intrinsic): Add cases for new simd intrinsics.
(warn_mismatched_return_type): New function.
(warn_mismatched_argument): New function.
(build_shuffle_mask_type): New function.
(maybe_warn_intrinsic_mismatch): New function.
(expand_intrinsic_vec_cond): New function.
(expand_intrinsic_vec_convert): New function.
(expand_intrinsic_vec_blend): New function.
(expand_intrinsic_vec_shuffle): New function.
(expand_intrinsic_vec_shufflevector): New function.
(expand_intrinsic_vec_load_unaligned): New function.
(expand_intrinsic_vec_store_unaligned): New function.
(maybe_expand_intrinsic): Check signature of intrinsic before handing
off to front-end lowering.  Add cases for new simd intrinsics.
* intrinsics.def (INTRINSIC_LOADUNALIGNED): Define intrinsic.
(INTRINSIC_STOREUNALIGNED): Define intrinsic.
(INTRINSIC_SHUFFLE): Define intrinsic.
(INTRINSIC_SHUFFLEVECTOR): Define intrinsic.
(INTRINSIC_CONVERTVECTOR): Define intrinsic.
(INTRINSIC_BLENDVECTOR): Define intrinsic.
(INTRINSIC_EQUALMASK): Define intrinsic.
(INTRINSIC_NOTEQUALMASK): Define intrinsic.
(INTRINSIC_GREATERMASK): Define intrinsic.
(INTRINSIC_GREATEREQUALMASK): Define intrinsic.

libphobos/ChangeLog:

* libdruntime/Makefile.am (DRUNTIME_DSOURCES): Add gcc/simd.d.
* libdruntime/Makefile.in: Regenerate.
* libdruntime/gcc/simd.d: New file.

gcc/testsuite/ChangeLog:

* gdc.dg/Wbuiltin_declaration_mismatch.d: Rename to...
* gdc.dg/Wbuiltin_declaration_mismatch1.d: ...this.
* gdc.dg/Wbuiltin_declaration_mismatch2.d: New test.
* gdc.dg/torture/simd_blendvector.d: New test.
* gdc.dg/torture/simd_cond.d: New test.
* gdc.dg/torture/simd_convertvector.d: New test.
* gdc.dg/torture/simd_load.d: New test.
* gdc.dg/torture/simd_logical.d: New test.
* gdc.dg/torture/simd_shuffle.d: New test.
* gdc.dg/torture/simd_shufflevector.d: New test.
* gdc.dg/torture/simd_store.d: New test.
---
 gcc/d/intrinsics.cc   | 587 ++
 gcc/d/intrinsics.def  |  23 +
 ...tch.d => Wbuiltin_declaration_mismatch1.d} |   0
 .../gdc.dg/Wbuiltin_declar

Re: [PATCH gcc 0/1] [PATCH] target: Fix asm generation for AVX builtins when using -masm=intel [PR106095]

2022-06-28 Thread Hongtao Liu via Gcc-patches
On Tue, Jun 28, 2022 at 11:16 PM Antoni Boucher  wrote:
>
> Thanks for the review.
> Does this mean I can commit it, assuming the output of compare_tests is
> good?
Yes.
>
> By the way, I wanted to mention that it was my first time playing with
> the assembly generation, so I was not sure about my changes (even
> though it makes the test case compile, I'm not sure it doesn't have any
> unintended side effects):
> It looked to me that the register qualifiers should be the same for
> both AT&T and Intel syntaxes, but I'm might be wrong about this.
Yes for the case in your patch, I think it's a typo.
But there could be some difference for operand modifiers between AT&T
and Intel syntaxes in some patterns.
.i.e the use of mode attr .

>
> On Tue, 2022-06-28 at 14:22 +0800, Hongtao Liu wrote:
> > On Tue, Jun 28, 2022 at 9:26 AM ~antoyo via Gcc-patches
> >  wrote:
> > >
> > > Hi.
> > >
> > > This fixes the following bug:
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106095
> > The patch LGTM, thanks for handling this.
> > >
> > > It's the first time I work outside of the jit component, so please
> > > tell
> > > me if I forgot anything.
> > >
> > > Here are the results of running the test:
> > >
> > > === gcc Summary ===
> > >
> > > # of expected passes182481
> > > # of unexpected failures91
> > > # of unexpected successes   20
> > > # of expected failures  1475
> > > # of unsupported tests  2535
> > >
> > > === g++ Summary ===
> > >
> > > # of expected passes231596
> > > # of unexpected failures1
> > > # of expected failures  2083
> > > # of unsupported tests  9948
> > >
> > > === jit Summary ===
> > >
> > > # of expected passes14542
> > > # of unexpected failures1
> > >
> > > === libstdc++ Summary ===
> > >
> > > # of expected passes15538
> > > # of expected failures  95
> > > # of unsupported tests  653
> > >
> > > === libgomp Summary ===
> > >
> > > # of expected passes5012
> > > # of expected failures  33
> > > # of unsupported tests  323
> > >
> > > === libitm Summary ===
> > >
> > > # of expected passes44
> > > # of expected failures  3
> > > # of unsupported tests  1
> > >
> > > === libatomic Summary ===
> > >
> > > # of expected passes54
> > >
> > > It's the first time I run the whole testsuite, so I'm not sure if
> > > those
> > > failures are normal. I got more unexpected failures for the gcc
> > > tests
> > > than what is shown in https://gcc.gnu.org/pipermail/gcc-
> > > testresults/2022-June/764154.html. In any case, I get the same
> > > failures
> > > when running the testsuite on master. Perhaps my configure command
> > > is
> > > wrong? I used the following:
> > You can use ./contrib/compare_tests to see if there's no failure or
> > new pass.
> > ./contrib/compara_tests is under gcc top directory.
> > >
> > > ../../gcc/configure --enable-host-shared --enable-
> > > languages=c,jit,c++,lto --enable-checking=release
> > > --prefix=(pwd)/../install
> > >
> > --enable-checking=release will give up some internal checks to
> > increase the compilation speed, for the development trunk, it is
> > better not to use release.
> > > Thanks for the review.
> > >
> > > Antoni Boucher (1):
> > >   target: Fix asm generation for AVX builtins when using -
> > > masm=intel
> > > [PR106095]
> > >
> > >  gcc/config/i386/sse.md   | 10 ++---
> > >  gcc/testsuite/gcc.target/i386/pr106095.c | 47
> > > 
> > >  2 files changed, 52 insertions(+), 5 deletions(-)
> > >  create mode 100644 gcc/testsuite/gcc.target/i386/pr106095.c
> > >
> > > --
> > > 2.34.2
> >
> >
> >
>


--
BR,
Hongtao


Re: [PATCH] libstdc++: retry removal of dir entries if dir removal fails

2022-06-28 Thread Alexandre Oliva via Gcc-patches
On Jun 27, 2022, Alexandre Oliva  wrote:

> (ii) arrange for recursive_directory_iterator to rewind a dir from
> which entries have been _erase()d before returning to the parent dir

Here's an implementation of the above.  I kind of like it; it's far more
elegant than the earlier patch, and if it starts removing stuff from one
subdir, it won't remove stuff from other sibling subdirs before removing
that one subdir, and it won't visit any directory more than once.  I
don't think POSIX imposes any such restriction (AFAICT one could launch
parallel removes for each subdir and still be compliant), but it's less
surprising this way.


libstdc++: auto-rewind dirs for remove_all

On some target systems (e.g. rtems6.0), removing directory components
while iterating over directory entries may cause some of the directory
entries to be skipped, which prevents the removal of the parent
directory from succeeding.

Advancing the iterator before removing a member proved not to be
enough, so I've arranged the directory reading implementation to
implicitly rewind a directory when reaching the end, as long as there
were any entries and they have all been removed.  Rewinding will only
ever take place for users of recursive_directory_iterator::__erase,
and thus of _Dir::do_unlink, and since __erase is a private member
function, it can only be used by the remove_all functions because
they're granted friendship.

Regstrapped on x86_64-linux-gnu, also tested with a cross to
aarch64-rtems6.  Ok to install?


for  libstdc++-v3/ChangeLog

* src/filesystem/dir-common.h (__gnu_posix::rewinddir):
Define.
* src/c++17/fs_dir.cc (fs::_Dir::auto_rewind): New enum.
(fs::_Dir::rewind): New data member.
(fs::_Dir::advance): Update rewind, rewinddir if found entries
have all been removed.
(fs::_Dir::do_unlink): Drop const.  Update rewind.
(fs::_Dir::unlink, fs::_Dir::rmdir): Drop const.
---
 libstdc++-v3/src/c++17/fs_dir.cc |   75 +-
 libstdc++-v3/src/filesystem/dir-common.h |3 +
 2 files changed, 75 insertions(+), 3 deletions(-)

diff --git a/libstdc++-v3/src/c++17/fs_dir.cc b/libstdc++-v3/src/c++17/fs_dir.cc
index 2258399da2587..6f535c95a32fb 100644
--- a/libstdc++-v3/src/c++17/fs_dir.cc
+++ b/libstdc++-v3/src/c++17/fs_dir.cc
@@ -44,6 +44,30 @@ template class 
std::__shared_ptr;
 
 struct fs::_Dir : _Dir_base
 {
+  // On some systems, removing a directory entry causes readdir to
+  // skip the subsequent entry.  This state machine enables remove_all
+  // to not miss entries, by arranging for directories to
+  // automatically rewind iff every visited entry got removed, hitting
+  // the end only when no entries are found.  We start with
+  // no_entries, and advance moves from that to found_entry, that
+  // do_unlink changes to removed_entry.  If advance is called again
+  // without unlink, it moves to remaining_entry instead, so that we
+  // will know not to rewind (otherwise we'd visit the same entry
+  // again).  OTOH, if advance doesn't find any entry and the state is
+  // removed_entry, it resets to no_entries and rewinds; at other
+  // states, no rewind takes place.  Skipped entries (dot and dotdot
+  // and permission-denied) do not affect the state machine: they're
+  // skipped every time anyway.  It is envisioned that, with a
+  // reliable detection mechanism for systems that don't need
+  // rewinding, rewind could be initialized to remaining_entry, that
+  // is a final state that prevents rewinding.
+  enum auto_rewind {
+no_entries,
+found_entry,
+removed_entry,
+remaining_entry
+  };
+
   _Dir(const fs::path& p, bool skip_permission_denied, bool nofollow,
[[maybe_unused]] bool filename_only, error_code& ec)
   : _Dir_base(p.c_str(), skip_permission_denied, nofollow, ec)
@@ -67,6 +91,21 @@ struct fs::_Dir : _Dir_base
   {
 if (const auto entp = _Dir_base::advance(skip_permission_denied, ec))
   {
+   switch (rewind)
+ {
+ case no_entries:
+ case removed_entry:
+   rewind = found_entry;
+   break;
+ case found_entry:
+   rewind = remaining_entry;
+   break;
+ case remaining_entry:
+   break;
+ default:
+   __builtin_unreachable ();
+   break;
+ }
auto name = path;
name /= entp->d_name;
file_type type = file_type::none;
@@ -80,6 +119,22 @@ struct fs::_Dir : _Dir_base
   }
 else if (!ec)
   {
+   switch (rewind)
+ {
+ case removed_entry:
+   rewind = no_entries;
+   posix::rewinddir(this->dirp);
+   return advance (skip_permission_denied, ec);
+ case found_entry:
+   rewind = remaining_entry;
+   break;
+ case no_entries:
+ case remaining_entry:
+   break;
+ default:
+   __builtin_unreachable ();
+   break;
+ }
  

Re: [PATCH v2] jit: avoid calloc() poisoning on musl [PR106102]

2022-06-28 Thread Richard Biener via Gcc-patches



> Am 28.06.2022 um 23:06 schrieb Sergei Trofimovich :
> 
> From: Sergei Trofimovich 
> 
> On musl  uses calloc() (via ). jit/ includes
> it directly and exposes use of poisoned calloc():
> 
>/build/build/./prev-gcc/xg++ ... 
> ../../gcc-13-20220626/gcc/jit/jit-playback.cc
>make[3]: *** [Makefile:1143: jit/libgccjit.o] Error 1
>make[3]: *** Waiting for unfinished jobs
>In file included from /<>/musl-1.2.3-dev/include/pthread.h:30,
> from ../../gcc-13-20220626/gcc/jit/jit-playback.cc:44:
>/<>/musl-1.2.3-dev/include/sched.h:84:7: error: attempt to use 
> poisoned "calloc"
>   84 | void *calloc(size_t, size_t);
>  |   ^
>/<>/musl-1.2.3-dev/include/sched.h:124:36: error: attempt to use 
> poisoned "calloc"
>  124 | #define CPU_ALLOC(n) ((cpu_set_t *)calloc(1,CPU_ALLOC_SIZE(n)))
>  |^
> 
> The change moves  inclusion to "system.h" under new
> INCLUDE_PTHREAD_H guard and uses this mechanism in libgccjit.

Ok,

Thanks,
Richard 

> gcc/
> 
>PR c++/106102
>* system.h: Introduce INCLUDE_PTHREAD_H macros to include .
> 
> gcc/jit/
> 
>PR c++/106102
>* jit-playback.cc: Include  via "system.h" to avoid calloc()
>poisoning.
>* jit-recording.cc: Ditto.
>* libgccjit.cc: Ditto.
> ---
> gcc/jit/jit-playback.cc  | 3 +--
> gcc/jit/jit-recording.cc | 2 +-
> gcc/jit/libgccjit.cc | 2 +-
> gcc/system.h | 4 
> 4 files changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/gcc/jit/jit-playback.cc b/gcc/jit/jit-playback.cc
> index 6be6bdf8dea..79714132b91 100644
> --- a/gcc/jit/jit-playback.cc
> +++ b/gcc/jit/jit-playback.cc
> @@ -19,6 +19,7 @@ along with GCC; see the file COPYING3.  If not see
> .  */
> 
> #include "config.h"
> +#define INCLUDE_PTHREAD_H
> #include "system.h"
> #include "coretypes.h"
> #include "target.h"
> @@ -41,8 +42,6 @@ along with GCC; see the file COPYING3.  If not see
> #include "diagnostic.h"
> #include "stmt.h"
> 
> -#include 
> -
> #include "jit-playback.h"
> #include "jit-result.h"
> #include "jit-builtins.h"
> diff --git a/gcc/jit/jit-recording.cc b/gcc/jit/jit-recording.cc
> index 697dee66e73..f78daed2d71 100644
> --- a/gcc/jit/jit-recording.cc
> +++ b/gcc/jit/jit-recording.cc
> @@ -19,13 +19,13 @@ along with GCC; see the file COPYING3.  If not see
> .  */
> 
> #include "config.h"
> +#define INCLUDE_PTHREAD_H
> #include "system.h"
> #include "coretypes.h"
> #include "tm.h"
> #include "pretty-print.h"
> #include "toplev.h"
> 
> -#include 
> 
> #include "jit-builtins.h"
> #include "jit-recording.h"
> diff --git a/gcc/jit/libgccjit.cc b/gcc/jit/libgccjit.cc
> index 0e76097b4ba..ca862662777 100644
> --- a/gcc/jit/libgccjit.cc
> +++ b/gcc/jit/libgccjit.cc
> @@ -19,12 +19,12 @@ along with GCC; see the file COPYING3.  If not see
> .  */
> 
> #include "config.h"
> +#define INCLUDE_PTHREAD_H
> #include "system.h"
> #include "coretypes.h"
> #include "timevar.h"
> #include "typed-splay-tree.h"
> #include "cppbuiltin.h"
> -#include 
> 
> #include "libgccjit.h"
> #include "jit-recording.h"
> diff --git a/gcc/system.h b/gcc/system.h
> index 67158b70c78..f8d42ff6815 100644
> --- a/gcc/system.h
> +++ b/gcc/system.h
> @@ -753,6 +753,10 @@ extern int vsnprintf (char *, size_t, const char *, 
> va_list);
> #endif
> #endif
> 
> +#ifdef INCLUDE_PTHREAD_H
> +#include 
> +#endif
> +
> #ifdef INCLUDE_ISL
> #ifdef HAVE_isl
> #include 
> -- 
> 2.36.1
>