date:20230226

RE: [PATCH] Fix RTL simplifications of FFS, POPCOUNT and PARITY.

2023-02-26 Thread Roger Sayle

To assist Jakub's request for progress on this, I've re-tested this patch
(which
still applies cleanly) on x86_64-pc-linux-gnu, again without any
regressions.
This is a middle-end piece of my preferred solution to PR106594, which is a
P1 regression affecting aarch64.

This patch  teaches simplify-rtx.cc to err on the side of caution, by never
creating (new) FFS, POPCOUNT or PARITY rtx with mismatched modes,
matching the documentation.

I've a related (optional) backend patch for nvptx that was posted here:
https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609571.html
but this isn't strictly required, and is effectively a clean-up.

The RISC-V vector popcount instructions mentioned by Jakub are a similar
representation problem.   I'd suggest that the preferred way to represent
these in RTL is as a vector-to-vector popcount, followed by a sum reduction
[RISC-V already has a vector sum reduction insn/UNSPEC].  This would, in
theory, allow constant folding of this instruction for known operands, but
unfortunately, (I believe) GCC doesn't (yet) have an RTX for representing
(sum) reductions (from vectors to scalars)?.

This patch has been retested 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?

2023-02-26  Roger Sayle  

gcc/ChangeLog
* simplify-rtx.cc (simplify_unary_operation_1) :
Avoid generating FFS with mismatched operand and result modes,
by using an explicit SIGN_EXTEND/ZERO_EXTEND.
: Likewise, for POPCOUNT of ZERO_EXTEND.
: Likewise, for PARITY of {ZERO,SIGN}_EXTEND.

Thanks in advance,
Roger

> -Original Message-
> From: Jakub Jelinek 
> Sent: 21 February 2023 15:39
> To: Jeff Law ; 'Segher Boessenkool'
> ; Roger Sayle 
> Cc: 'GCC Patches' 
> Subject: Re: [PATCH] Fix RTL simplifications of FFS, POPCOUNT and PARITY.
> 
> On Sun, Jan 01, 2023 at 03:55:26PM -, Roger Sayle wrote:
> > In 2011, the rtl.texi documentation was updated to reflect that the
> > modes of the RTX unary operations FFS, POPCOUNT and PARITY must match
> > those of their operands.  Unfortunately, some of the transformations
> > in simplify-rtx.cc predate this tightening of RTL semantics, and have
> > not (until now) been updated/fixed.  i.e. The POPCOUNT and PARITY
> > optimizations were "correct" when I originally added them back in 2007.
> >
> > Segher requested that I split this piece out from a fix for PR 106594
> > in
> > https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601501.html
> >
> > 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?
> >
> >
> > 2023-01-01  Roger Sayle  
> >
> > gcc/ChangeLog
> > * gcc/simplify-rtx.cc (simplify_unary_operation_1) :
> 
> BTW, gcc/ prefix shouldn't be in the ChangeLog entry.
> 
> > Avoid generating FFS with mismatched operand and result modes, by
> > using an explicit SIGN_EXTEND/ZERO_EXTEND instead.
> > : Likewise, for POPCOUNT of ZERO_EXTEND.
> > : Likewise, for PARITY of {ZERO,SIGN}_EXTEND.
> 
> Can we make progress on this?
> I've looked with
> make mddump
> grep '(\(ffs\|popcount\|parity\):' tmp-mddump.md | grep -v
> '(\(ffs\|popcount\|parity\):\([A-Z0-9x]*\) (match_operand:\2'
> at various targets.  This prints nothing at all on aarch64, arm, gcn,
powerpc,
> rl78, visium, on x86 it prints
> (popcount:SI (zero_extend:SI (match_operand:HI 1
> ("nonimmediate_operand") ("")
> (popcount:SI (match_dup 1)))
> (popcount:DI (match_dup 1)))
> (and:DI (subreg:DI (popcount:SI (match_dup 1)) 0)
> (zero_extend:DI (popcount:SI (match_dup 1
> (popcount:SI (zero_extend:SI (match_operand:HI 1
> ("nonimmediate_operand") ("")
> (popcount:SI (match_dup 0))) where the (popcount:SI
(zero_extend:SI
> cases are *popcounthi2_1 define_insn_and_split but we have *popcounthi2_2
> which has (zero_extend:SI (popcount:HI and so is ok, and I've manually
checked
> the match_dup cases and the match_operand corresponding to match_dup has
> the right mode, on mips it prints
> (popcount:SI (truncate:SI (match_operand:DI 1
("register_operand")
> ("d") which is also ok, on sparc
> (truncate:SI (popcount:DI (match_dup 2 in popcountsi2 also
looks ok,
> on s390x
> (popcount:DI (match_dup 2)))
> (popcount:DI (match_dup 2))) where I've also manually
verified
> popcountsi2 and popcounthi2 to be ok.
> And then riscv, see below.
> Now, for the above arches, everything thus matches the rtl.texi
documentation
> and popcount/parity/ffs match or create only matching modes between the
RTL
> and its operand and Roger's patch seems to be IMHO the way to go, because
> what simplify-rtx.cc does now for those cases the pa

Re: [PATCH v2 0/5] A small Texinfo refinement

2023-02-26 Thread Arsen Arsenović via Gcc-patches

Hi Thomas,

Thomas Schwinge  writes:

> Hi Arsen!
>
> Thanks for caring about the documentation infrastructure!
>
> On 2023-02-23T11:27:09+0100, Arsen Arsenović via Gcc-patches 
>  wrote:
>> The commit "docs: Reorder @opindex to be before corresponding options"
>
>> https://gcc.gnu.org/pipermail/gcc-patches/2023-February/612616.html
>> His idea of automatically checking for this error pattern will be
>> implemented separately, after I figure out how best to do that.  The
>> code that was involved in making this patchset is too primitive to
>> apply globally.
>
> But please don't spend too much time on that idea, if that turns out to
> require non-trivial Texinfo parsing.

My intention was to do it in texi2any, since there's already a nice and
convenient parse tree that can be used there.  Alternatively, texi2any
can export the parse tree for external tools consumption, if some
heuristic ends up not being general enough for all Texinfo manuals.  I'd
like to figure out something general, though, as time permits.

> Given that you've now fixed up the existing disordered instances, I
> suppose not many new ones are going be introduced, assuming that people
> extend the documentation by looking at the existing, now-good context.

Yes, I think so too.  In either case, I'll try to catch errors before
they get merged, at least for now.

>
> Grüße
>  Thomas
> -
> Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
> München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
> Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
> München, HRB 106955

Have a lovely day.
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Contents of PO file 'cpplib-13.1-b20230212.sv.po'

2023-02-26 Thread Translation Project Robot



cpplib-13.1-b20230212.sv.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.

New Swedish PO file for 'cpplib' (version 13.1-b20230212)

2023-02-26 Thread Translation Project Robot

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'cpplib' has been submitted
by the Swedish team of translators.  The file is available at:

https://translationproject.org/latest/cpplib/sv.po

(This file, 'cpplib-13.1-b20230212.sv.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

https://translationproject.org/latest/cpplib/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

https://translationproject.org/domain/cpplib.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

[PATCH] xtensa: Make use of CLAMPS instruction if configured

2023-02-26 Thread Takayuki 'January June' Suwa via Gcc-patches

This patch introduces the use of CLAMPS instruction when the instruction
is configured.

/* example */
int test(int a) {
  if (a < -512)
return -512;
  if (a > 511)
return 511;
  return a;
}

;; prereq: TARGET_CLAMPS
test:
clamps  a2, a2, 9
ret.n

gcc/ChangeLog:

* config/xtensa/xtensa-protos.h (xtensa_match_CLAMPS_imms_p):
New prototype.
* config/xtensa/xtensa.cc (xtensa_match_CLAMPS_imms_p):
New function.
* config/xtensa/xtensa.h (TARGET_CLAMPS): New macro definition.
* config/xtensa/xtensa.md (*xtensa_clamps): New insn pattern.
---
 gcc/config/xtensa/xtensa-protos.h |  1 +
 gcc/config/xtensa/xtensa.cc   | 13 +++
 gcc/config/xtensa/xtensa.h|  1 +
 gcc/config/xtensa/xtensa.md   | 37 +++
 4 files changed, 52 insertions(+)

diff --git a/gcc/config/xtensa/xtensa-protos.h 
b/gcc/config/xtensa/xtensa-protos.h
index c81cf94323a..64cbf27c248 100644
--- a/gcc/config/xtensa/xtensa-protos.h
+++ b/gcc/config/xtensa/xtensa-protos.h
@@ -60,6 +60,7 @@ extern bool xtensa_tls_referenced_p (rtx);
 extern enum rtx_code xtensa_shlrd_which_direction (rtx, rtx);
 extern bool xtensa_split1_finished_p (void);
 extern void xtensa_split_DI_reg_imm (rtx *);
+extern bool xtensa_match_CLAMPS_imms_p (rtx, rtx);
 
 #ifdef TREE_CODE
 extern void init_cumulative_args (CUMULATIVE_ARGS *, int);
diff --git a/gcc/config/xtensa/xtensa.cc b/gcc/config/xtensa/xtensa.cc
index 5044bc25c2f..7287aa7a258 100644
--- a/gcc/config/xtensa/xtensa.cc
+++ b/gcc/config/xtensa/xtensa.cc
@@ -2611,6 +2611,19 @@ xtensa_emit_add_imm (rtx dst, rtx src, HOST_WIDE_INT 
imm, rtx scratch,
 }
 
 
+/* Return true if the constants used in the application of smin() following
+   smax() meet the specifications of the CLAMPS machine instruction.  */
+bool
+xtensa_match_CLAMPS_imms_p (rtx cst_max, rtx cst_min)
+{
+  int max, min;
+
+  return IN_RANGE (max = exact_log2 (-INTVAL (cst_max)), 7, 22)
+&& IN_RANGE (min = exact_log2 (INTVAL (cst_min) + 1), 7, 22)
+&& max == min;
+}
+
+
 /* Implement TARGET_CANNOT_FORCE_CONST_MEM.  */
 
 static bool
diff --git a/gcc/config/xtensa/xtensa.h b/gcc/config/xtensa/xtensa.h
index d4cd5def7b5..058602e44ee 100644
--- a/gcc/config/xtensa/xtensa.h
+++ b/gcc/config/xtensa/xtensa.h
@@ -35,6 +35,7 @@ along with GCC; see the file COPYING3.  If not see
 #define TARGET_NSA XCHAL_HAVE_NSA
 #define TARGET_MINMAX  XCHAL_HAVE_MINMAX
 #define TARGET_SEXTXCHAL_HAVE_SEXT
+#define TARGET_CLAMPS  XCHAL_HAVE_CLAMPS
 #define TARGET_BOOLEANSXCHAL_HAVE_BOOLEANS
 #define TARGET_HARD_FLOAT  XCHAL_HAVE_FP
 #define TARGET_HARD_FLOAT_DIV  XCHAL_HAVE_FP_DIV
diff --git a/gcc/config/xtensa/xtensa.md b/gcc/config/xtensa/xtensa.md
index b60dec2447f..3521fa33b47 100644
--- a/gcc/config/xtensa/xtensa.md
+++ b/gcc/config/xtensa/xtensa.md
@@ -446,6 +446,43 @@
(set_attr "mode""SI")
(set_attr "length"  "3")])
 
+
+;; Signed clamp.
+
+(define_insn_and_split "*xtensa_clamps"
+  [(set (match_operand:SI 0 "register_operand" "=a")
+   (smax:SI (smin:SI (match_operand:SI 1 "register_operand" "r")
+ (match_operand:SI 2 "const_int_operand" "i"))
+(match_operand:SI 3 "const_int_operand" "i")))]
+  "TARGET_CLAMPS
+   && xtensa_match_CLAMPS_imms_p (operands[3], operands[2])"
+  "#"
+  "&& 1"
+  [(set (match_dup 0)
+   (smin:SI (smax:SI (match_dup 1)
+ (match_dup 3))
+(match_dup 2)))]
+  ""
+  [(set_attr "type""arith")
+   (set_attr "mode""SI")
+   (set_attr "length"  "3")])
+
+(define_insn "*xtensa_clamps"
+  [(set (match_operand:SI 0 "register_operand" "=a")
+   (smin:SI (smax:SI (match_operand:SI 1 "register_operand" "r")
+ (match_operand:SI 2 "const_int_operand" "i"))
+(match_operand:SI 3 "const_int_operand" "i")))]
+  "TARGET_CLAMPS
+   && xtensa_match_CLAMPS_imms_p (operands[2], operands[3])"
+{
+  static char result[64];
+  sprintf (result, "clamps\t%%0, %%1, %d", floor_log2 (-INTVAL (operands[2])));
+  return result;
+}
+  [(set_attr "type""arith")
+   (set_attr "mode""SI")
+   (set_attr "length"  "3")])
+
 
 ;; Count redundant leading sign bits and leading/trailing zeros,
 ;; and find first bit.
-- 
2.30.2

(Totally off-topic, but do you know anything about the SALT/SALTU instructions?
I see them in the "Core Architecture Instructions" in a recent Cadence document
but not in slightly older Tensilica one...)

Ping^5: [PATCH] jit: Install jit headers in $(libsubincludedir) [PR 101491]

2023-02-26 Thread Lorenzo Salvadore via Gcc-patches

Hello,

Ping https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606450.html

Thanks,

Lorenzo Salvadore

> From f8e2c2ee89a7d8741bb65163d1f1c20edcd546ac Mon Sep 17 00:00:00 2001
> From: Lorenzo Salvadore develo...@lorenzosalvadore.it
> 
> Date: Wed, 16 Nov 2022 11:27:38 +0100
> Subject: [PATCH] jit: Install jit headers in $(libsubincludedir) [PR 101491]
> 
> Installing jit/libgccjit.h and jit/libgccjit++.h headers in
> $(includedir) can be a problem for machines where multiple versions of
> GCC are required simultaneously, see for example this bug report on
> FreeBSD:
> 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257060
> 
> Hence,
> 
> - define $(libsubincludedir) the same way it is defined in libgomp;
> - install jit/libgccjit.h and jit/libgccjit++.h in $(libsubincludedir).
> 
> The patch has already been applied successfully in the official FreeBSD
> ports tree for the ports lang/gcc11 and lang/gcc12. Please see the
> following commits:
> 
> https://cgit.freebsd.org/ports/commit/?id=0338e04504ee269b7a95e6707f1314bc1c4239fe
> https://cgit.freebsd.org/ports/commit/?id=f1957296ed2dce8a09bb9582e9a5a715bf8b3d4d
> 
> gcc/ChangeLog:
> 
> 2022-11-16 Lorenzo Salvadore develo...@lorenzosalvadore.it
> 
> PR jit/101491
> * Makefile.in: Define and create $(libsubincludedir)
> 
> gcc/jit/ChangeLog:
> 
> 2022-11-16 Lorenzo Salvadore develo...@lorenzosalvadore.it
> 
> PR jit/101491
> * Make-lang.in: Install headers in $(libsubincludedir)
> ---
> gcc/Makefile.in | 3 +++
> gcc/jit/Make-lang.in | 4 ++--
> 2 files changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/gcc/Makefile.in b/gcc/Makefile.in
> index f672e6ea549..3bcf1c491ab 100644
> --- a/gcc/Makefile.in
> +++ b/gcc/Makefile.in
> @@ -635,6 +635,8 @@ libexecdir = @libexecdir@
> 
> # Directory in which the compiler finds libraries etc.
> libsubdir = 
> $(libdir)/gcc/$(real_target_noncanonical)/$(version)$(accel_dir_suffix)
> +# Directory in which the compiler finds headers.
> +libsubincludedir = $(libdir)/gcc/$(target_alias)/$(version)/include
> # Directory in which the compiler finds executables
> libexecsubdir = 
> $(libexecdir)/gcc/$(real_target_noncanonical)/$(version)$(accel_dir_suffix)
> # Directory in which all plugin resources are installed
> @@ -3642,6 +3644,7 @@ install-cpp: installdirs cpp$(exeext)
> # $(libdir)/gcc/include isn't currently searched by cpp.
> installdirs:
> $(mkinstalldirs) $(DESTDIR)$(libsubdir)
> + $(mkinstalldirs) $(DESTDIR)$(libsubincludedir)
> $(mkinstalldirs) $(DESTDIR)$(libexecsubdir)
> $(mkinstalldirs) $(DESTDIR)$(bindir)
> $(mkinstalldirs) $(DESTDIR)$(includedir)
> diff --git a/gcc/jit/Make-lang.in b/gcc/jit/Make-lang.in
> index 248ec45b729..ba1b3e95da5 100644
> --- a/gcc/jit/Make-lang.in
> +++ b/gcc/jit/Make-lang.in
> @@ -360,9 +360,9 @@ selftest-jit:
> # Install hooks:
> jit.install-headers: installdirs
> $(INSTALL_DATA) $(srcdir)/jit/libgccjit.h \
> - $(DESTDIR)$(includedir)/libgccjit.h
> + $(DESTDIR)$(libsubincludedir)/libgccjit.h
> $(INSTALL_DATA) $(srcdir)/jit/libgccjit++.h \
> - $(DESTDIR)$(includedir)/libgccjit++.h
> + $(DESTDIR)$(libsubincludedir)/libgccjit++.h
> 
> ifneq (,$(findstring mingw,$(target)))
> jit.install-common: installdirs jit.install-headers
> --
> 2.38.0

[patch, libgfortran] Initailize some variable to get rid of nuisance warnings.

2023-02-26 Thread Jerry D via Gcc-patches

The attached patch is minor and self explanatory.  I assume this should 
wait for gfortran 14 since no regression involved.  Please advise otherwise.


Regression tested on x86-64.

OK for trunk when the time is right?

Regards,

Jerry

Author: Jerry DeLisle 
Date:   Sat Feb 25 20:30:35 2023 -0800

Fortran: Eliminate nuisance warnings by initializing.

Set sstride[0] and mstide[0] to zero, eliminating some warnings.

libgfortran/ChangeLog:

* generated/pack_c10.c (pack_c10): Regenerated.
* generated/pack_c16.c (pack_c16): Regenerated.
* generated/pack_c17.c (pack_c17): Regenerated.
* generated/pack_c4.c (pack_c4): Regenerated.
* generated/pack_c8.c (pack_c8): Regenerated.
* generated/pack_i1.c (pack_i1): Regenerated.
* generated/pack_i16.c (pack_i16): Regenerated.
* generated/pack_i2.c (pack_i2): Regenerated.
* generated/pack_i4.c (pack_i4): Regenerated.
* generated/pack_i8.c (pack_i8): Regenerated.
* generated/pack_r10.c (pack_r10): Regenerated.
* generated/pack_r16.c (pack_r16): Regenerated.
* generated/pack_r17.c (pack_r17): Regenerated.
* generated/pack_r4.c (pack_r4): Regenerated.
* generated/pack_r8.c (pack_r8): Regenerated.
* generated/spread_c10.c (spread_c10): Regenerated.
* generated/spread_c16.c (spread_c16): Regenerated.
* generated/spread_c17.c (spread_c17): Regenerated.
* generated/spread_c4.c (spread_c4): Regenerated.
* generated/spread_c8.c (spread_c8): Regenerated.
* generated/spread_i1.c (spread_i1): Regenerated.
* generated/spread_i16.c (spread_i16): Regenerated.
* generated/spread_i2.c (spread_i2): Regenerated.
* generated/spread_i4.c (spread_i4): Regenerated.
* generated/spread_i8.c (spread_i8): Regenerated.
* generated/spread_r10.c (spread_r10): Regenerated.
* generated/spread_r16.c (spread_r16): Regenerated.
* generated/spread_r17.c (spread_r17): Regenerated.
* generated/spread_r4.c (spread_r4): Regenerated.
* generated/spread_r8.c (spread_r8): Regenerated.
* intrinsics/execute_command_line.c (execute_command_line_i4),
(execute_command_line_i8): Set estat_initial to zero.
* intrinsics/pack_generic.c (pack_internal): Set sstride[0] and
mstride[0] to zero.
* intrinsics/spread_generic.c (spread_internal): Set 
sstride[0].

* m4/pack.m4: Set sstride[0] and mstride[0].
* m4/spread.m4: Set sstride[0].
diff --git a/libgfortran/generated/pack_c10.c b/libgfortran/generated/pack_c10.c
index a961057a8a6..c01efd11cf8 100644
--- a/libgfortran/generated/pack_c10.c
+++ b/libgfortran/generated/pack_c10.c
@@ -96,6 +96,9 @@ pack_c10 (gfc_array_c10 *ret, const gfc_array_c10 *array,
 
   dim = GFC_DESCRIPTOR_RANK (array);
 
+  sstride[0] = 0; /* Avoid warnings if not initialized.  */
+  mstride[0] = 0;
+
   mptr = mask->base_addr;
 
   /* Use the same loop for all logical types, by using GFC_LOGICAL_1
diff --git a/libgfortran/generated/pack_c16.c b/libgfortran/generated/pack_c16.c
index 37c062798bb..8ee6b25cbe6 100644
--- a/libgfortran/generated/pack_c16.c
+++ b/libgfortran/generated/pack_c16.c
@@ -96,6 +96,9 @@ pack_c16 (gfc_array_c16 *ret, const gfc_array_c16 *array,
 
   dim = GFC_DESCRIPTOR_RANK (array);
 
+  sstride[0] = 0; /* Avoid warnings if not initialized.  */
+  mstride[0] = 0;
+
   mptr = mask->base_addr;
 
   /* Use the same loop for all logical types, by using GFC_LOGICAL_1
diff --git a/libgfortran/generated/pack_c17.c b/libgfortran/generated/pack_c17.c
index f9638d640ad..7a1cf5e17e8 100644
--- a/libgfortran/generated/pack_c17.c
+++ b/libgfortran/generated/pack_c17.c
@@ -96,6 +96,9 @@ pack_c17 (gfc_array_c17 *ret, const gfc_array_c17 *array,
 
   dim = GFC_DESCRIPTOR_RANK (array);
 
+  sstride[0] = 0; /* Avoid warnings if not initialized.  */
+  mstride[0] = 0;
+
   mptr = mask->base_addr;
 
   /* Use the same loop for all logical types, by using GFC_LOGICAL_1
diff --git a/libgfortran/generated/pack_c4.c b/libgfortran/generated/pack_c4.c
index d72717041a1..76c8a853fac 100644
--- a/libgfortran/generated/pack_c4.c
+++ b/libgfortran/generated/pack_c4.c
@@ -96,6 +96,9 @@ pack_c4 (gfc_array_c4 *ret, const gfc_array_c4 *array,
 
   dim = GFC_DESCRIPTOR_RANK (array);
 
+  sstride[0] = 0; /* Avoid warnings if not initialized.  */
+  mstride[0] = 0;
+
   mptr = mask->base_addr;
 
   /* Use the same loop for all logical types, by using GFC_LOGICAL_1
diff --git a/libgfortran/generated/pack_c8.c b/libgfortran/generated/pack_c8.c
index 9f8e97e4bc8..365c26ed0e8 100644
--- a/libgfortran/generated/pack_c8.c
+++ b/libgfortran/generated/pack_c8.c
@@ -96,6 +96,9 @@ pack_c8 (gfc_array_c8 *ret, const gfc_array_c8 *array,
 
   dim = GFC_DESCRIPTOR_RANK (array);

Re: [patch, libgfortran] Initailize some variable to get rid of nuisance warnings.

2023-02-26 Thread Harald Anlauf via Gcc-patches


Hi Jerry,

regarding PACK: since this is a bogus warning as the compiler does
not realize that dim >= 1, wouldn't a

gcc_assert (dim >= 1);

in the right place achieve the same effect, since the first argument
must be an array?

(It's different for SPREAD, though, where SOURCE may be scalar).

Cheers,
Harald

Am 26.02.23 um 20:52 schrieb Jerry D via Gcc-patches:
The attached patch is minor and self explanatory.  I assume this should 
wait for gfortran 14 since no regression involved.  Please advise 
otherwise.


Regression tested on x86-64.

OK for trunk when the time is right?

Regards,

Jerry

Author: Jerry DeLisle 
Date:   Sat Feb 25 20:30:35 2023 -0800

     Fortran: Eliminate nuisance warnings by initializing.

     Set sstride[0] and mstide[0] to zero, eliminating some warnings.

     libgfortran/ChangeLog:

     * generated/pack_c10.c (pack_c10): Regenerated.
     * generated/pack_c16.c (pack_c16): Regenerated.
     * generated/pack_c17.c (pack_c17): Regenerated.
     * generated/pack_c4.c (pack_c4): Regenerated.
     * generated/pack_c8.c (pack_c8): Regenerated.
     * generated/pack_i1.c (pack_i1): Regenerated.
     * generated/pack_i16.c (pack_i16): Regenerated.
     * generated/pack_i2.c (pack_i2): Regenerated.
     * generated/pack_i4.c (pack_i4): Regenerated.
     * generated/pack_i8.c (pack_i8): Regenerated.
     * generated/pack_r10.c (pack_r10): Regenerated.
     * generated/pack_r16.c (pack_r16): Regenerated.
     * generated/pack_r17.c (pack_r17): Regenerated.
     * generated/pack_r4.c (pack_r4): Regenerated.
     * generated/pack_r8.c (pack_r8): Regenerated.
     * generated/spread_c10.c (spread_c10): Regenerated.
     * generated/spread_c16.c (spread_c16): Regenerated.
     * generated/spread_c17.c (spread_c17): Regenerated.
     * generated/spread_c4.c (spread_c4): Regenerated.
     * generated/spread_c8.c (spread_c8): Regenerated.
     * generated/spread_i1.c (spread_i1): Regenerated.
     * generated/spread_i16.c (spread_i16): Regenerated.
     * generated/spread_i2.c (spread_i2): Regenerated.
     * generated/spread_i4.c (spread_i4): Regenerated.
     * generated/spread_i8.c (spread_i8): Regenerated.
     * generated/spread_r10.c (spread_r10): Regenerated.
     * generated/spread_r16.c (spread_r16): Regenerated.
     * generated/spread_r17.c (spread_r17): Regenerated.
     * generated/spread_r4.c (spread_r4): Regenerated.
     * generated/spread_r8.c (spread_r8): Regenerated.
     * intrinsics/execute_command_line.c (execute_command_line_i4),
     (execute_command_line_i8): Set estat_initial to zero.
     * intrinsics/pack_generic.c (pack_internal): Set sstride[0] 
and

     mstride[0] to zero.
     * intrinsics/spread_generic.c (spread_internal): Set 
sstride[0].

     * m4/pack.m4: Set sstride[0] and mstride[0].
     * m4/spread.m4: Set sstride[0].

Re: [PATCH] xtensa: Make use of CLAMPS instruction if configured

2023-02-26 Thread Max Filippov via Gcc-patches

On Sun, Feb 26, 2023 at 9:27 AM Takayuki 'January June' Suwa
 wrote:
> This patch introduces the use of CLAMPS instruction when the instruction
> is configured.

Testing.

> (Totally off-topic, but do you know anything about the SALT/SALTU 
> instructions?
> I see them in the "Core Architecture Instructions" in a recent Cadence 
> document
> but not in slightly older Tensilica one...)

Yes, they are a part of the core xtensa instruction set since the
release RG-2015.0.
I believe this translates to the test (XTENSA_MARCH_EARLIEST >= 26).
There's a chapter "Added instructions" at the end of the xtensa ISA book with
the list of such opcodes.

-- 
Thanks.
-- Max

Re: [pushed][PATCH v2] LoongArch: Change the value of macro TRY_EMPTY_VM_SPACE from 0x8000000000 to 0x1000000000.

2023-02-26 Thread Lulu Cheng


Pushed to r13-6353.

在 2023/2/23 下午5:29, Lulu Cheng 写道:

The PCH mechanism first tries to map the .gch file to the virtual memory
space pointed to by TRY_EMPTY_VM_SPACE during the compilation process.

The original value of TRY_EMPTY_VM_SPACE macro is 0x80,
but like la464 only has 40 bits of virtual address space, this value
just exceeds the address range.

If we want to support chips with less than 40 bits virtual addresses,
then the value of this macro needs to be set small. I think setting
this value small will increase the probability of virtual address
mapping failure. And the purpose of pch is to make compilation faster,
but I think we rarely compile on embedded systems. So this situation
may not be within our consideration.

So change the value of this macro to 0x10.

gcc/ChangeLog:

* config/host-linux.cc (TRY_EMPTY_VM_SPACE): Modify the value of
the macro to 0x10.
---
  gcc/config/host-linux.cc | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/config/host-linux.cc b/gcc/config/host-linux.cc
index a891651a7b6..d1aa7ab28ca 100644
--- a/gcc/config/host-linux.cc
+++ b/gcc/config/host-linux.cc
@@ -99,7 +99,7 @@
  #elif defined(__riscv) && defined (__LP64__)
  # define TRY_EMPTY_VM_SPACE   0x10
  #elif defined(__loongarch__) && defined(__LP64__)
-# define TRY_EMPTY_VM_SPACE0x80
+# define TRY_EMPTY_VM_SPACE0x10
  #else
  # define TRY_EMPTY_VM_SPACE   0
  #endif

Re: [patch, libgfortran] Initailize some variable to get rid of nuisance warnings.

2023-02-26 Thread Jerry D via Gcc-patches


On 2/26/23 12:59 PM, Harald Anlauf wrote:

Hi Jerry,

regarding PACK: since this is a bogus warning as the compiler does
not realize that dim >= 1, wouldn't a

gcc_assert (dim >= 1);

in the right place achieve the same effect, since the first argument
must be an array?

(It's different for SPREAD, though, where SOURCE may be scalar).



I should have clarified in my posts that the warnings are on the use of 
sstride[0], mstride[0] or both. For example.


../../../trunk/libgfortran/generated/pack_i2.c: In function ‘pack_i2’:
../../../trunk/libgfortran/generated/pack_i2.c:129:14: warning: 
‘sstride’ may be used uninitialized [-Wmaybe-uninitialized]

  129 |   if (sstride[0] == 0)
  |   ~~~^~~
../../../trunk/libgfortran/generated/pack_i2.c:80:14: note: ‘sstride’ 
declared here

   80 |   index_type sstride[GFC_MAX_DIMENSIONS];
  |  ^~~
../../../trunk/libgfortran/generated/pack_i2.c:131:14: warning: 
‘mstride’ may be used uninitialized [-Wmaybe-uninitialized]

  131 |   if (mstride[0] == 0)
  |   ~~~^~~
../../../trunk/libgfortran/generated/pack_i2.c:84:14: note: ‘mstride’ 
declared here

   84 |   index_type mstride[GFC_MAX_DIMENSIONS];
  |  ^~~
../../../trunk/libgfortran/generated/pack_i2.c:131:14: warning: 
‘mstride’ may be used uninitialized [-Wmaybe-uninitialized]

  131 |   if (mstride[0] == 0)
  |   ~~~^~~
../../../trunk/libgfortran/generated/pack_i2.c:84:14: note: ‘mstride’ 
declared here

   84 |   index_type mstride[GFC_MAX_DIMENSIONS];
  |  ^~~

In a sense it is a regression. It showed up when builds started to use 
-Wmaybe-unitialized.



Cheers,
Harald

Am 26.02.23 um 20:52 schrieb Jerry D via Gcc-patches:
The attached patch is minor and self explanatory.  I assume this 
should wait for gfortran 14 since no regression involved.  Please 
advise otherwise.


Regression tested on x86-64.

OK for trunk when the time is right?

Regards,

Jerry

Author: Jerry DeLisle 
Date:   Sat Feb 25 20:30:35 2023 -0800

 Fortran: Eliminate nuisance warnings by initializing.

 Set sstride[0] and mstide[0] to zero, eliminating some warnings.

 libgfortran/ChangeLog:

 * generated/pack_c10.c (pack_c10): Regenerated.
 * generated/pack_c16.c (pack_c16): Regenerated.
 * generated/pack_c17.c (pack_c17): Regenerated.
 * generated/pack_c4.c (pack_c4): Regenerated.
 * generated/pack_c8.c (pack_c8): Regenerated.
 * generated/pack_i1.c (pack_i1): Regenerated.
 * generated/pack_i16.c (pack_i16): Regenerated.
 * generated/pack_i2.c (pack_i2): Regenerated.
 * generated/pack_i4.c (pack_i4): Regenerated.
 * generated/pack_i8.c (pack_i8): Regenerated.
 * generated/pack_r10.c (pack_r10): Regenerated.
 * generated/pack_r16.c (pack_r16): Regenerated.
 * generated/pack_r17.c (pack_r17): Regenerated.
 * generated/pack_r4.c (pack_r4): Regenerated.
 * generated/pack_r8.c (pack_r8): Regenerated.
 * generated/spread_c10.c (spread_c10): Regenerated.
 * generated/spread_c16.c (spread_c16): Regenerated.
 * generated/spread_c17.c (spread_c17): Regenerated.
 * generated/spread_c4.c (spread_c4): Regenerated.
 * generated/spread_c8.c (spread_c8): Regenerated.
 * generated/spread_i1.c (spread_i1): Regenerated.
 * generated/spread_i16.c (spread_i16): Regenerated.
 * generated/spread_i2.c (spread_i2): Regenerated.
 * generated/spread_i4.c (spread_i4): Regenerated.
 * generated/spread_i8.c (spread_i8): Regenerated.
 * generated/spread_r10.c (spread_r10): Regenerated.
 * generated/spread_r16.c (spread_r16): Regenerated.
 * generated/spread_r17.c (spread_r17): Regenerated.
 * generated/spread_r4.c (spread_r4): Regenerated.
 * generated/spread_r8.c (spread_r8): Regenerated.
 * intrinsics/execute_command_line.c 
(execute_command_line_i4),

 (execute_command_line_i8): Set estat_initial to zero.
 * intrinsics/pack_generic.c (pack_internal): Set 
sstride[0] and

 mstride[0] to zero.
 * intrinsics/spread_generic.c (spread_internal): Set 
sstride[0].

 * m4/pack.m4: Set sstride[0] and mstride[0].
 * m4/spread.m4: Set sstride[0].

[PATCH] MIPS: Add buildtime option to set msa default

2023-02-26 Thread Junxian Zhu

From: Junxian Zhu 

Add buildtime option to decide whether will compiler build with `-mmsa` option 
default.

gcc/ChangeLog:
* config.gcc: add -with-{no-}msa build option.
* config/mips/mips.h: Likewise.
* doc/install.texi: Likewise.

Signed-off-by: Junxian Zhu 
---
 gcc/config.gcc | 19 +--
 gcc/config/mips/mips.h |  3 ++-
 gcc/doc/install.texi   |  8 
 3 files changed, 27 insertions(+), 3 deletions(-)

diff --git a/gcc/config.gcc b/gcc/config.gcc
index c070e6ecd2e..da3a6d3ba1f 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -4709,7 +4709,7 @@ case "${target}" in
;;
 
mips*-*-*)
-   supported_defaults="abi arch arch_32 arch_64 float fpu nan 
fp_32 odd_spreg_32 tune tune_32 tune_64 divide llsc mips-plt synci lxc1-sxc1 
madd4 compact-branches"
+   supported_defaults="abi arch arch_32 arch_64 float fpu nan 
fp_32 odd_spreg_32 tune tune_32 tune_64 divide llsc mips-plt synci lxc1-sxc1 
madd4 compact-branches msa"
 
case ${with_float} in
"" | soft | hard)
@@ -4871,6 +4871,21 @@ case "${target}" in
exit 1
;;
esac
+
+   case ${with_msa} in
+   yes)
+   with_msa=msa
+   ;;
+   no)
+   with_msa=no-msa
+   ;;
+   "")
+   ;;
+   *)
+   echo "Unknown msa type used in --with-msa" 1>&2
+   exit 1
+   ;;
+   esac
;;
 
loongarch*-*-*)
@@ -5815,7 +5830,7 @@ case ${target} in
 esac
 
 t=
-all_defaults="abi cpu cpu_32 cpu_64 arch arch_32 arch_64 tune tune_32 tune_64 
schedule float mode fpu nan fp_32 odd_spreg_32 divide llsc mips-plt synci tls 
lxc1-sxc1 madd4 isa_spec compact-branches"
+all_defaults="abi cpu cpu_32 cpu_64 arch arch_32 arch_64 tune tune_32 tune_64 
schedule float mode fpu nan fp_32 odd_spreg_32 divide llsc mips-plt synci tls 
lxc1-sxc1 madd4 isa_spec compact-branches msa"
 for option in $all_defaults
 do
eval "val=\$with_"`echo $option | sed s/-/_/g`
diff --git a/gcc/config/mips/mips.h b/gcc/config/mips/mips.h
index fbb4372864f..13bc193b752 100644
--- a/gcc/config/mips/mips.h
+++ b/gcc/config/mips/mips.h
@@ -916,7 +916,8 @@ struct mips_cpu_info {
   {"synci", "%{!msynci:%{!mno-synci:-m%(VALUE)}}" },   \
   {"lxc1-sxc1", "%{!mlxc1-sxc1:%{!mno-lxc1-sxc1:-m%(VALUE)}}" }, \
   {"madd4", "%{!mmadd4:%{!mno-madd4:-m%(VALUE)}}" }, \
-  {"compact-branches", "%{!mcompact-branches=*:-mcompact-branches=%(VALUE)}" } 
\
+  {"compact-branches", "%{!mcompact-branches=*:-mcompact-branches=%(VALUE)}" 
}, \
+  {"msa", "%{!mmsa:%{!mno-msa:-m%(VALUE)}}" } \
 
 /* A spec that infers the:
-mnan=2008 setting from a -mips argument,
diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index 8ef5c1414da..e3fcb63de0c 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -1653,6 +1653,14 @@ unfused is normally expected).  Disabling these 
instructions is the
 only way to ensure compatible code is generated; this will incur
 a performance penalty.
 
+@item --with-msa
+On MIPS targets, make @option{-mmsa} the default when no
+@option{-mno-mmsa} option is passed.
+
+@item --without-msa
+On MIPS targets, make @option{-mno-msa} the default when no
+@option{-mmsa} option is passed. This is the default.
+
 @item --with-mips-plt
 On MIPS targets, make use of copy relocations and PLTs.
 These features are extensions to the traditional
-- 
2.39.2

RE: Re: [PATCH] RISC-V: Bugfix for rvv bool mode precision adjustment

2023-02-26 Thread Li, Pan2 via Gcc-patches

Hi there,

Just FYI that there is no obvious errors of this patch by running the GCC 
bootstrap making.

Pan

From: Li, Pan2
Sent: Friday, February 24, 2023 3:21 PM
To: juzhe.zh...@rivai.ai; kito.cheng ; richard.sandiford 

Cc: incarnation.p.lee ; gcc-patches 
; Kito.cheng ; rguenther 
; jeffreyalaw 
Subject: RE: Re: [PATCH] RISC-V: Bugfix for rvv bool mode precision adjustment

Hi Richard Sandiford,

Looks like you are busy and stuck in some important work right now, could you 
please help to share something like ETA if possible? Then we may have a better 
plan for the RVV intrinsic support in the GCC 13.

Thanks a lot and feel free to ping us if any question or concern.

Pan

From: juzhe.zh...@rivai.ai 
mailto:juzhe.zh...@rivai.ai>>
Sent: Friday, February 24, 2023 1:08 PM
To: kito.cheng mailto:kito.ch...@gmail.com>>; Li, Pan2 
mailto:pan2...@intel.com>>
Cc: richard.sandiford 
mailto:richard.sandif...@arm.com>>; 
incarnation.p.lee 
mailto:incarnation.p@outlook.com>>; 
gcc-patches mailto:gcc-patches@gcc.gnu.org>>; 
Kito.cheng mailto:kito.ch...@sifive.com>>; rguenther 
mailto:rguent...@suse.de>>; jeffreyalaw 
mailto:jeffreya...@gmail.com>>
Subject: Re: Re: [PATCH] RISC-V: Bugfix for rvv bool mode precision adjustment

Hi,

It's been a while since this patch is sent.
This patch is very important for us since we are going to release RVV intrinsic 
support in GCC 13.
And this is the patch to fix bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108654

Can any one verifies this patch for us?

Thanks.

juzhe.zh...@rivai.ai

From: Kito Cheng
Date: 2023-02-21 16:28
To: Li, Pan2
CC: richard.sandif...@arm.com; 
juzhe.zhong; 
incarnation.p@outlook.com; 
gcc-patches@gcc.gnu.org; 
kito.ch...@sifive.com; Richard 
Biener
Subject: Re: [PATCH] RISC-V: Bugfix for rvv bool mode precision adjustment
Hi Richard Sandiford:

RISC-V part is OK to me, could you review the ADJUST_PRECISION part to
make sure this change is reasonable?

Thanks :)

On Tue, Feb 21, 2023 at 2:37 PM Li, Pan2 via Gcc-patches
mailto:gcc-patches@gcc.gnu.org>> wrote:
>
> Hi,
>
> Kindly reminder for this PR.
>
> Pan
>
> -Original Message-
> From: Li, Pan2
> Sent: Friday, February 17, 2023 4:39 PM
> To: richard.sandif...@arm.com; juzhe.zhong 
> mailto:juzhe.zh...@rivai.ai>>
> Cc: incarnation.p@outlook.com; 
> gcc-patches@gcc.gnu.org; 
> kito.ch...@sifive.com; Richard Biener 
> mailto:rguent...@suse.de>>
> Subject: RE: [PATCH] RISC-V: Bugfix for rvv bool mode precision adjustment
>
> Cool, thank you!
>
> Hi Richard S,
>
> Could you please help to do me a fever for this change when you free? Thank 
> you!
>
> Pan
>
> -Original Message-
> From: Richard Biener mailto:rguent...@suse.de>>
> Sent: Friday, February 17, 2023 3:36 PM
> To: juzhe.zhong mailto:juzhe.zh...@rivai.ai>>
> Cc: incarnation.p@outlook.com; 
> gcc-patches@gcc.gnu.org; 
> kito.ch...@sifive.com; Li, Pan2 
> mailto:pan2...@intel.com>>; 
> richard.sandif...@arm.com
> Subject: Re: [PATCH] RISC-V: Bugfix for rvv bool mode precision adjustment
>
> On Thu, 16 Feb 2023, juzhe.zhong wrote:
>
> > Thanks for the great work to fix this issue for rvv.Hi，richard. This
> > is the patch to differentiate mask mode of same bytesize. Adjust the
> > precision correctly according to rvv isa. Would you mind helping us
> > with this patch ？
> > Since it‘s very important for rvv support in gcc
>
> If adjusting the precision works fine then I suppose the patch looks 
> reasonable.  I'll defer to Richard S. though since he's the one knowing the 
> mode stuff better.  I'd have integrated the precision adjustment with the 
> ADJUST_NITER hook since that is also documented to adjust the precision btw.
>
> Richard.
>
> > Thanks.
> >  Replied Message 
> > From
> > incarnation.p@outlook.commailto:incarnation.p@outlook.com%3cincarnation.p@outlook.com>>
> > Date
> > 02/16/2023 23:12
> > To
> > gcc-patches@gcc.gnu.orgmailto:gcc-patches@gcc.gnu.org%3cgcc-patc...@gcc.gnu.org>>
> > Cc
> > juzhe.zh...@rivai.aimailto:juzhe.zh...@rivai.ai%3cjuzhe.zh...@rivai.ai>>,
> > kito.ch...@sifive.commailto:kito.ch...@sifive.com%3ckito.ch...@sifive.com>>,
> > rguent...@suse.demailto:rguent...@suse.de%3crguent...@suse.de>>,
> > pan2...@intel.commailto:pan2...@intel.com%3cpan2...@intel.com>>
> > Subject
> > [PATCH] RISC-V: Bugfix for rvv bool mode precision adjustment
> > From: Pan Li mailto:pan2...@intel.com>

Re: [PATCH] Fix std::unordered_map key range insertion

2023-02-26 Thread François Dumont via Gcc-patches


Replying to my own questions.

This use case is not valid from a Standard point of view. So not a bug 
and no need to deal with that before next stage 1.


The question left is either we want to support it ?

François

On 23/02/23 22:14, François Dumont wrote:

Hi

Based on my work on PR 96088 for std::map I imagine this use case of 
inserting a range of keys into an associative container. It behaves as 
operator[] by inserting a default value for each key.


I wonder if the Standard says that it should work. Or maybe we want to 
support it ?


I haven't checked if it used to work before we introduced the 
_ConvertToValueType type. I have no old enough gcc to do so.


It is not supported by std::map neither, even without 
_ConvertToValueType so I guess it was not working for 
std::unordered_map prior to it.


If it can be considered as a bug I'll create a PR.

François

Re: [patch, libgfortran] Initailize some variable to get rid of nuisance warnings.

2023-02-26 Thread Thomas Koenig via Gcc-patches


Hi Jerry,


I should have clarified in my posts that the warnings are on the use of 
sstride[0], mstride[0] or both.



In a sense it is a 
regression. It showed up when builds started to use -Wmaybe-unitialized.


I think this is OK for trunk now, and backport for up to whenever
-Wmaybe-uninitialized was introduced into the build.

The "regression-only" rule is mostly motivated by not introducing
new bugs (and for Fortran, we have a bit of leeway), and I would
be hard to pressed to think of a patch less likely to introduce
regressions.

Thanks for the patch!

Best regards

Thomas

Re: [PATCH] testsuite: Add -fno-ivopts to gcc.dg/Wuse-after-free-2.c, PR108828

2023-02-26 Thread Richard Biener via Gcc-patches

On Fri, Feb 24, 2023 at 5:38 PM Hans-Peter Nilsson via Gcc-patches
 wrote:
>
> Ok to commit?
>
> I suggest that when committed I'll also set the bugzilla
> entry in SUSPENDED mode, as opposed to RESOLVED.  I mean,
> the issue isn't really solved; that'd be a patch improving
> pointer tracking across ivopts.

OK.

Thanks,
Richard.

> -- >8 --
> For cris-elf before this patch, ever since it was added,
> this test gets:
>
> Running /x/gcc/testsuite/gcc.dg/dg.exp ...
> FAIL: gcc.dg/Wuse-after-free-2.c  (test for warnings, line 115)
> FAIL: gcc.dg/Wuse-after-free-2.c  (test for warnings, line 116)
>
> and comparing tree dumps with a native x86_64-pc-linux-gnu
> run shows a suspicious difference in the "180t.ivopts" dump.
> Indeed -fno-ivopts makes the warning appear for cris-elf
> too.  It was suggested to simply add -fno-ivopts to the
> test-flags, like before -fno-tree-loop-distribute-patterns
> was added; thus.
>
> PR tree-optimization/108828
> * gcc.dg/Wuse-after-free-2.c: Add -fno-ivopts.
> ---
>  gcc/testsuite/gcc.dg/Wuse-after-free-2.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/gcc/testsuite/gcc.dg/Wuse-after-free-2.c 
> b/gcc/testsuite/gcc.dg/Wuse-after-free-2.c
> index 68ec75845cec..ebc051690db5 100644
> --- a/gcc/testsuite/gcc.dg/Wuse-after-free-2.c
> +++ b/gcc/testsuite/gcc.dg/Wuse-after-free-2.c
> @@ -1,6 +1,6 @@
>  /* PR middle-end/104232 - spurious -Wuse-after-free after conditional free
> { dg-do compile }
> -   { dg-options "-O2 -Wall -fno-tree-loop-distribute-patterns" }  */
> +   { dg-options "-O2 -Wall -fno-tree-loop-distribute-patterns -fno-ivopts" } 
>  */
>
>  void free (void*);
>
> @@ -108,7 +108,8 @@ int warn_cond_loop (char *p)
>char *q = p;
>
>/*  -fno-tree-loop-distribute-patterns ensures this does not get converted
> -  into rawmemchr (making q and p unrelated).  */
> +  into rawmemchr (making q and p unrelated).  Also, -fno-ivopts is 
> required
> +  for some targets, to not lose track of the pointer.  */
>while (*q)
>  ++q;
>
> --
> 2.30.2
>

Re: [patch, libgfortran] Initailize some variable to get rid of nuisance warnings.

2023-02-26 Thread Tobias Burnus


Just side remarks, the 0 init in the patch is fine.

On 27.02.23 03:53, Jerry D via Gcc-patches wrote:


regarding PACK: since this is a bogus warning as the compiler does
not realize that dim >= 1, wouldn't a

gcc_assert (dim >= 1);


Note: gcc_assert only exists in the compiler itself; in libgfortran, we
use GFC_ASSERT or directly 'assert'.

You could also use 'if (dim < 1) __builtin_unreachable();' – or since
GCC 13:

__attribute__((assume (dim >= 1)));

Tobias

PS: In Fortran, '-fopenmp-simd' plus '!$omp assume holds(dim>=0) ...
!$omp end assume' (or !$omp ... + block/end block) can be used to denote
such assumptions. '-fopenmp-simd' enables only those bits of OpenMP that
do not require any library support (no libgomp, no pthreads), contrary
to '-fopenmp'.

-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955

RE: [PATCH] Fix RTL simplifications of FFS, POPCOUNT and PARITY.

Re: [PATCH v2 0/5] A small Texinfo refinement

Contents of PO file 'cpplib-13.1-b20230212.sv.po'

New Swedish PO file for 'cpplib' (version 13.1-b20230212)

[PATCH] xtensa: Make use of CLAMPS instruction if configured

Ping^5: [PATCH] jit: Install jit headers in $(libsubincludedir) [PR 101491]

[patch, libgfortran] Initailize some variable to get rid of nuisance warnings.

Re: [patch, libgfortran] Initailize some variable to get rid of nuisance warnings.

Re: [PATCH] xtensa: Make use of CLAMPS instruction if configured

Re: [pushed][PATCH v2] LoongArch: Change the value of macro TRY_EMPTY_VM_SPACE from 0x8000000000 to 0x1000000000.

Re: [patch, libgfortran] Initailize some variable to get rid of nuisance warnings.

[PATCH] MIPS: Add buildtime option to set msa default

RE: Re: [PATCH] RISC-V: Bugfix for rvv bool mode precision adjustment

Re: [PATCH] Fix std::unordered_map key range insertion

Re: [patch, libgfortran] Initailize some variable to get rid of nuisance warnings.

Re: [PATCH] testsuite: Add -fno-ivopts to gcc.dg/Wuse-after-free-2.c, PR108828

Re: [patch, libgfortran] Initailize some variable to get rid of nuisance warnings.

17 matches

Site Navigation

Mail list logo

Footer information