date:20230510

Eli Schwartz  writes:

>> Unfortunately, we do not have the source code for our compiler.  Would
>> you care to ask people here to restore `gcc -traditional'?
>
>
> This would appear to be a self-inflicted wound. If I understand the
> chain of events properly...

The chain of events actually is:

  - The code was originally written for the BSD Unix cc.
  - Eventually, it started to be built with GCC, with -traditional.
  - GCC removes -traditional.
  - We are forced to find another C comppiler.

Note that I wasn't where I am when this started, so everything above is
second hand knowledge.

And finally, this:

>   - to avoid making it produce invalid results, you hack your linker

Which is essentially link-time lint, and not related to the subject at
hand.  I only mentioned it to make a point, which is that people writing
traditional C in this day and age are unlikely to make any mistakes
doing so.

> You'd rather hack your compiler, but you cannot do it because you
> purchased a proprietary compiler and didn't purchase the rights to its
> source code.
>
> (BTW, there's a FOSS compiler that you can hack on if you like.)

Which sadly does not support the code which we need to compile.
Clearly, turning GCC into a K compiler is not a very welcome idea
around here, so why would we hack on it?

> That's all fine and well, you do you. What I do not understand is, two
> things.
>
> First of all, why are you calling this "traditional C"? It is not
> "traditional C". It isn't C. It is not-C.

When the file names for the source files end with `.c' and `.h', and the
compiler is named `cc' and `acomp', it is C.  It just isn't Standard C.

> Second of all, why is this GCC's problem? You are not a user of GCC,
> apparently.

Because decisions arbitrarily made on GCC's part will simply result in
even more people deciding to find some other compiler.

The point being that people sufficiently dedicated to their existing
code to not have changed in over 30 years will not respond to such
changes by changing their code.  They are much more likely to look for
some other compiler instead.

> And implicit-function-declaration does not have the same problem as
> -traditional, because implicit-function-declaration ***WILL*** have a
> flag that permits people who are users of GCC, and just want
> implicit-function-declaration back.

And remember that `-traditional' DID exist for a certain amount of time.
Then it was removed.  So in addition to annoying a lot of people, what
guarantees that -Wno-implicit will not be removed in the future, after
the proposed changes are made?

[committed v2] RISC-V: Support const series vector for RVV auto-vectorization

2023-05-10 Thread pinskia at gcc dot gnu.org via Gcc-bugs

From: Juzhe-Zhong 

Off line discussed with Ju-Zhe, and send and committed by me because he
got some network issue.

V2 Changes:

- Code restructure and rename emit_indexop to emit_index_op.
- Minor comment tweak.


--

This patch is the prerequiste patch for more RVV auto-vectorization
support.

Since when we enable a very simple binary operations, we will end
up with such following ICE:

during RTL pass: expand
add_run-1.c: In function 'main':
add_run-1.c:28:1: internal compiler error: Segmentation fault
0x1618ea3 crash_signal
../../../riscv-gcc/gcc/toplev.cc:314
0xe76cd9 single_set(rtx_insn const*)
../../../riscv-gcc/gcc/rtl.h:3602
0x1080f8a emit_move_insn(rtx_def*, rtx_def*)
../../../riscv-gcc/gcc/expr.cc:4342
0x170c458 insert_value_copy_on_edge
../../../riscv-gcc/gcc/tree-outof-ssa.cc:352
0x170d58e eliminate_phi
../../../riscv-gcc/gcc/tree-outof-ssa.cc:785
0x170df17 expand_phi_nodes(ssaexpand*)
../../../riscv-gcc/gcc/tree-outof-ssa.cc:1024
0xef27e2 execute
../../../riscv-gcc/gcc/cfgexpand.cc:6818

This is because LoopVectorizer assume target is able to handle
series const vector when we enable binary operations.
Then it will be easily causing ICE like that.

gcc/ChangeLog:

* config/riscv/autovec.md (@vec_series): New pattern
* config/riscv/riscv-protos.h (expand_vec_series): New function.
* config/riscv/riscv-v.cc (emit_binop): Ditto.
(emit_index_op): Ditto.
(expand_vec_series): Ditto.
(expand_const_vector): Add series vector handling.
* config/riscv/riscv.cc (riscv_const_insns): Enable series vector for 
testing.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/autovec/series-1.c: New test.
* gcc.target/riscv/rvv/autovec/series_run-1.c: New test.
---
 gcc/config/riscv/autovec.md   |  24 
 gcc/config/riscv/riscv-protos.h   |   1 +
 gcc/config/riscv/riscv-v.cc   | 118 +-
 gcc/config/riscv/riscv.cc |  27 +++-
 .../gcc.target/riscv/rvv/autovec/series-1.c   |  50 
 .../riscv/rvv/autovec/series_run-1.c  |  20 +++
 6 files changed, 236 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/series-1.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/series_run-1.c

diff --git a/gcc/config/riscv/autovec.md b/gcc/config/riscv/autovec.md
index f1c5ff5951bf..99dc4f046b0c 100644
--- a/gcc/config/riscv/autovec.md
+++ b/gcc/config/riscv/autovec.md
@@ -58,3 +58,27 @@
 DONE;
   }
 )
+
+;; =
+;; == Vector creation
+;; =
+
+;; -
+;;  [INT] Linear series
+;; -
+;; Includes:
+;; - vid.v
+;; - vmul.vx
+;; - vadd.vx/vadd.vi
+;; -
+
+(define_expand "@vec_series"
+  [(match_operand:VI 0 "register_operand")
+   (match_operand: 1 "reg_or_int_operand")
+   (match_operand: 2 "reg_or_int_operand")]
+  "TARGET_VECTOR"
+  {
+riscv_vector::expand_vec_series (operands[0], operands[1], operands[2]);
+DONE;
+  }
+)
diff --git a/gcc/config/riscv/riscv-protos.h b/gcc/config/riscv/riscv-protos.h
index c0293a306f92..e8a728ae226f 100644
--- a/gcc/config/riscv/riscv-protos.h
+++ b/gcc/config/riscv/riscv-protos.h
@@ -219,6 +219,7 @@ rtx gen_avl_for_scalar_move (rtx);
 void expand_tuple_move (machine_mode, rtx *);
 machine_mode preferred_simd_mode (scalar_mode);
 opt_machine_mode get_mask_mode (machine_mode);
+void expand_vec_series (rtx, rtx, rtx);
 }
 
 /* We classify builtin types into two classes:
diff --git a/gcc/config/riscv/riscv-v.cc b/gcc/config/riscv/riscv-v.cc
index 7ca49ca67c18..381e6601a174 100644
--- a/gcc/config/riscv/riscv-v.cc
+++ b/gcc/config/riscv/riscv-v.cc
@@ -248,6 +248,111 @@ emit_nonvlmax_op (unsigned icode, rtx dest, rtx src, rtx 
len,
   emit_pred_op (icode, NULL_RTX, dest, src, len, mask_mode, false);
 }
 
+/* Emit binary operations.  */
+
+static void
+emit_binop (unsigned icode, rtx *ops, machine_mode mask_mode,
+   machine_mode scalar_mode)
+{
+  insn_expander<9> e;
+  machine_mode mode = GET_MODE (ops[0]);
+  e.add_output_operand (ops[0], mode);
+  e.add_all_one_mask_operand (mask_mode);
+  e.add_vundef_operand (mode);
+  if (VECTOR_MODE_P (GET_MODE (ops[1])))
+e.add_input_operand (ops[1], GET_MODE (ops[1]));
+  else
+e.add_input_operand (ops[1], scalar_mode);
+  if (VECTOR_MODE_P (GET_MODE (ops[2])))
+e.add_input_operand (ops[2], GET_MODE (ops[2]));
+  else
+e.add_input_operand (ops[2], scalar_mode);
+  rtx vlmax = gen_reg_rtx (Pmode);
+  emit_vlmax_vsetvl (mode, vlmax);
+  e.add_input_operand (vlmax, Pmode);
+  e.add_policy_operand

Re: [PATCH] riscv: Add autovectorization tests for binary integer

2023-05-10 Thread Jeff Law via Gcc-patches





On 5/10/23 20:26, Kito Cheng wrote:

Don't forgot to add Michael to co-author, you can added by following line:

Co-authored-by: Michael Collison 

And GCC's changelog generating script will recognize that and generate
the right thing for that :)
Thanks for pointing that out.  I was looking for something similar to 
--author, but didn't find anything (of course).  I didn't realize it was 
actually handled by looking for tags in the commit message.


Jeff

Re: More C type errors by default for GCC 14

2023-05-10 Thread Eli Schwartz via Gcc

> Unfortunately, we do not have the source code for our compiler.  Would
> you care to ask people here to restore `gcc -traditional'?


This would appear to be a self-inflicted wound. If I understand the
chain of events properly...

- gcc drops support for -traditional

- you wish to use code that does the badness

- you purchase a proprietary compiler that permits it anyway
  - to avoid making it produce invalid results, you hack your linker

You'd rather hack your compiler, but you cannot do it because you
purchased a proprietary compiler and didn't purchase the rights to its
source code.

(BTW, there's a FOSS compiler that you can hack on if you like.)



That's all fine and well, you do you. What I do not understand is, two
things.

First of all, why are you calling this "traditional C"? It is not
"traditional C". It isn't C. It is not-C.

Second of all, why is this GCC's problem? You are not a user of GCC,
apparently.



Moreover, this discussion is not about -traditional! It's about
implicit-function-declaration. And implicit-function-declaration does
not have the same problem as -traditional, because
implicit-function-declaration ***WILL*** have a flag that permits people
who are users of GCC, and just want implicit-function-declaration back.

So you have exactly what you want out of this conversation. We concede.
C type errors by default will come with a flag to disable them.


-- 
Eli Schwartz

[commited] MAINTAINERS: Add myself to write after approval

2023-05-10 Thread juzhe . zhong

From: Ju-Zhe Zhong 

Signed-off-by: Juzhe Zhong 

ChangeLog:

* MAINTAINERS: Add myself.
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 4b846c6b288..1c380bef5c5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -521,6 +521,7 @@ James Lemke 
 Ilya Leoshkevich   
 Kriang Lerdsuwanakij   
 Pan Li 
+Juzhe Zhong
 Renlin Li  
 Xinliang David Li  
 Chen Liqin 
-- 
2.36.1

[PATCH] MAINTAINERS: Add myself to write after approval

2023-05-10 Thread juzhe . zhong

From: Ju-Zhe Zhong 

Signed-off-by: Juzhe Zhong 

ChangeLog:

* MAINTAINERS: Add myself.
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 4b846c6b288..1c380bef5c5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -521,6 +521,7 @@ James Lemke 
 Ilya Leoshkevich   
 Kriang Lerdsuwanakij   
 Pan Li 
+Juzhe Zhong
 Renlin Li  
 Xinliang David Li  
 Chen Liqin 
-- 
2.36.1

[Bug debug/109805] LTO affecting -fdebug-prefix-map

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109805

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|DUPLICATE   |---
 Status|RESOLVED|UNCONFIRMED

--- Comment #3 from Andrew Pinski  ---
Let's reopen this one for a few.

[Bug debug/109805] LTO affecting -fdebug-prefix-map

2023-05-10 Thread pinskia at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109805

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Andrew Pinski  ---
Dup of bug 87726.

*** This bug has been marked as a duplicate of bug 87726 ***

[Bug debug/87726] -fdebug-prefix-map doesn't work with lto

2023-05-10 Thread pinskia at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87726

--- Comment #4 from Andrew Pinski  ---
*** Bug 109805 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/109806] 13.1.0 cc1plus stack smashing crash with C array of complex structs

2023-05-10 Thread pinskia at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109806

--- Comment #1 from Andrew Pinski  ---
>it's 1.6MB, so it was impossible to attach them here uncompressed

Can you try to compress it and attach it?

Re: More C type errors by default for GCC 14

Jonathan Wakely via Gcc  writes:

> On Wed, 10 May 2023, 03:32 Eli Zaretskii,  wrote:
>
>>
>> And then people will start complaining about GCC unnecessarily
>> erroring out, which is a compiler bug, since there's no problem
>> producing correct code in these cases.
>>
>
>
> What is the correct code for this?
>
> void foo(int);
> void bar() { foo("42"); }
>
> Why should this compile?

Because keeping that from compiling will also keep this from compiling:

bar ()
{
  extern foo ();

  return foo ("42");
}

> You keep demanding better rationale for the change, but your argument
> amounts to nothing more than "it compiles today, it should compile
> tomorrow".

And so it should.  Because for every invalid piece of code you can think
of, there are hundereds or thousands of combinations that may as well be
valid.  For example, on the 68020, vax, or similarly reasonable 32-bit
machine:

foo (ptr)
{
  register char *str;

  str = ptr;

  /* do stuff with str */

  puts (str);
}

/* In another translation unit.  */

bar ()
{
  foo ("42");
}

RE: [PATCH] RISC-V: Update RVV integer compare simplification comments

2023-05-10 Thread Li, Pan2 via Gcc-patches

Hi Jeff,

Thanks a lot. If no more comments, I can commit it to trunk later, .

Pan

-Original Message-
From: Jeff Law  
Sent: Tuesday, May 9, 2023 6:06 AM
To: Li, Pan2 ; gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; kito.ch...@sifive.com; Wang, Yanzhang 

Subject: Re: [PATCH] RISC-V: Update RVV integer compare simplification comments



On 5/8/23 02:54, Pan Li via Gcc-patches wrote:
> From: Pan Li 
> 
> The VMSET simplification RVV integer comparision has merged already.
> This patch would like to update the comments for the cases that the 
> define_split will act on.
> 
> Signed-off-by: Pan Li 
> 
> gcc/ChangeLog:
> 
>   * config/riscv/vector.md: Add comments for simplifying to vmset.
OK.  Thanks.
jeff

Re: [PATCH] riscv: Add autovectorization tests for binary integer

2023-05-10 Thread juzhe.zh...@rivai.ai

LGTM. 
The whole implementation is your own work, but tests are mostly base on Michael 
so add Michael as co-author in testcase patch and then commit.



juzhe.zh...@rivai.ai
 
From: Robin Dapp
Date: 2023-05-10 23:24
To: gcc-patches; juzhe.zh...@rivai.ai; Kito Cheng; Michael Collison; palmer; 
jeffreyalaw
CC: rdapp.gcc
Subject: [PATCH] riscv: Add autovectorization tests for binary integer
Hi,
 
this patchs adds scan as well as execution tests for vectorized
binary integer operations.  It is based on Michael Collison's work
and also includes scalar variants.  The tests are not fully comprehensive
as the vector type promotions (vec_unpack, extend etc.) are not
implemented yet.  Also, vmulh, vmulhu, and vmulhsu and others are
still missing.
 
Regards
Robin
 
--
 
gcc/testsuite/ChangeLog:
 
* gcc.target/riscv/rvv/autovec/shift-rv32gcv.c: New test.
* gcc.target/riscv/rvv/autovec/shift-rv64gcv.c: New test.
* gcc.target/riscv/rvv/autovec/shift-scalar-rv32gcv.c: New test.
* gcc.target/riscv/rvv/autovec/shift-scalar-rv64gcv.c: New test.
* gcc.target/riscv/rvv/autovec/shift-scalar-template.h: New test.
* gcc.target/riscv/rvv/autovec/shift-template.h: New test.
* gcc.target/riscv/rvv/autovec/shift-run-template.h: New test.
* gcc.target/riscv/rvv/autovec/vadd-run-template.h: New test.
* gcc.target/riscv/rvv/autovec/vadd-rv32gcv.c: New test.
* gcc.target/riscv/rvv/autovec/vadd-rv64gcv.c: New test.
* gcc.target/riscv/rvv/autovec/vadd-template.h: New test.
* gcc.target/riscv/rvv/autovec/vand-run-template.h: New test.
* gcc.target/riscv/rvv/autovec/vand-rv32gcv.c: New test.
* gcc.target/riscv/rvv/autovec/vand-rv64gcv.c: New test.
* gcc.target/riscv/rvv/autovec/vand-template.h: New test.
* gcc.target/riscv/rvv/autovec/vdiv-run-template.h: New test.
* gcc.target/riscv/rvv/autovec/vdiv-rv32gcv.c: New test.
* gcc.target/riscv/rvv/autovec/vdiv-rv64gcv.c: New test.
* gcc.target/riscv/rvv/autovec/vdiv-template.h: New test.
* gcc.target/riscv/rvv/autovec/vmax-run-template.h: New test.
* gcc.target/riscv/rvv/autovec/vmax-rv32gcv.c: New test.
* gcc.target/riscv/rvv/autovec/vmax-rv64gcv.c: New test.
* gcc.target/riscv/rvv/autovec/vmax-template.h: New test.
* gcc.target/riscv/rvv/autovec/vmin-run-template.h: New test.
* gcc.target/riscv/rvv/autovec/vmin-rv32gcv.c: New test.
* gcc.target/riscv/rvv/autovec/vmin-rv64gcv.c: New test.
* gcc.target/riscv/rvv/autovec/vmin-template.h: New test.
* gcc.target/riscv/rvv/autovec/vmul-run-template.h: New test.
* gcc.target/riscv/rvv/autovec/vmul-rv32gcv.c: New test.
* gcc.target/riscv/rvv/autovec/vmul-rv64gcv.c: New test.
* gcc.target/riscv/rvv/autovec/vmul-template.h: New test.
* gcc.target/riscv/rvv/autovec/vor-run-template.h: New test.
* gcc.target/riscv/rvv/autovec/vor-rv32gcv.c: New test.
* gcc.target/riscv/rvv/autovec/vor-rv64gcv.c: New test.
* gcc.target/riscv/rvv/autovec/vor-template.h: New test.
* gcc.target/riscv/rvv/autovec/vrem-run-template.h: New test.
* gcc.target/riscv/rvv/autovec/vrem-rv32gcv.c: New test.
* gcc.target/riscv/rvv/autovec/vrem-rv64gcv.c: New test.
* gcc.target/riscv/rvv/autovec/vrem-template.h: New test.
* gcc.target/riscv/rvv/autovec/vsub-run-template.h: New test.
* gcc.target/riscv/rvv/autovec/vsub-rv32gcv.c: New test.
* gcc.target/riscv/rvv/autovec/vsub-rv64gcv.c: New test.
* gcc.target/riscv/rvv/autovec/vsub-template.h: New test.
* gcc.target/riscv/rvv/autovec/vxor-run-template.h: New test.
* gcc.target/riscv/rvv/autovec/vxor-rv32gcv.c: New test.
* gcc.target/riscv/rvv/autovec/vxor-rv64gcv.c: New test.
* gcc.target/riscv/rvv/autovec/vxor-template.h: New test.
---
.../riscv/rvv/autovec/shift-run-template.h|  47 +++
.../riscv/rvv/autovec/shift-rv32gcv.c |  12 ++
.../riscv/rvv/autovec/shift-rv64gcv.c |  12 ++
.../riscv/rvv/autovec/shift-scalar-rv32gcv.c  |   7 ++
.../riscv/rvv/autovec/shift-scalar-rv64gcv.c  |   7 ++
.../riscv/rvv/autovec/shift-scalar-template.h | 119 ++
.../riscv/rvv/autovec/shift-template.h|  34 +
.../riscv/rvv/autovec/vadd-run-template.h |  64 ++
.../riscv/rvv/autovec/vadd-rv32gcv.c  |   8 ++
.../riscv/rvv/autovec/vadd-rv64gcv.c  |   8 ++
.../riscv/rvv/autovec/vadd-template.h |  56 +
.../riscv/rvv/autovec/vand-run-template.h |  64 ++
.../riscv/rvv/autovec/vand-rv32gcv.c  |   8 ++
.../riscv/rvv/autovec/vand-rv64gcv.c  |   8 ++
.../riscv/rvv/autovec/vand-template.h |  56 +
.../riscv/rvv/autovec/vdiv-run-template.h |  42 +++
.../riscv/rvv/autovec/vdiv-rv32gcv.c  |  10 ++
.../riscv/rvv/autovec/vdiv-rv64gcv.c  |  10 ++
.../riscv/rvv/autovec/vdiv-template.h |  34 +
.../riscv/rvv/autovec/vmax-run-template.h |  42 +++
.../riscv/rvv/autovec/vmax-rv32gcv.c  |   8 ++
.../riscv/rvv/autovec/vmax-rv64gcv.c  |   8 ++
.../riscv/rvv/autovec/vmax-template.h |  34 +
.../riscv/rvv/autovec/vmin-run-template.h |  42 +++

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

2023-05-10 Thread Li, Pan2 via Gcc-patches

Thanks Richard Sandiford. Update PATCH v4 here -> 
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/618099.html.

> -  if (dv_as_opaque (node->dv) != decl || node->offset != offset)
> +  if (node->dv.first_or_null () != decl || node->offset != 
> + offset)

> Genuine question, but: is the first_or_null really needed?  I would have 
> expected node->dv != decl to work, with an implicit conversion on the 
> argument.

Directly compare node->dv and decl may requires additional overload operator, 
or it may complains similar as below. But I am afraid it is unreasonable to add 
such kind of operator for one specific type RTX in pointer_mux up to a point. 
Thus I think here we may need node->dv == (decl_or_val) decl here.

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

Pan

-Original Message-
From: Richard Sandiford  
Sent: Wednesday, May 10, 2023 11:56 PM
To: Li, Pan2 
Cc: gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai; kito.ch...@sifive.com; Wang, 
Yanzhang ; jeffreya...@gmail.com; ja...@redhat.com; 
rguent...@suse.de
Subject: Re: [PATCH v3] Var-Tracking: Typedef pointer_mux 
as decl_or_value

Thanks, mostly looks good to me.  Some minor comments below.

pan2...@intel.com writes:
> From: Pan Li 
>
> The decl_or_value is defined as void * before this PATCH. It will take 
> care of both the tree_node and rtx_def. Unfortunately, given a void 
> pointer cannot tell the input is tree_node or rtx_def.
>
> Then we have some implicit structure layout requirement similar as 
> below. Or we will touch unreasonable bits when cast void * to 
> tree_node or rtx_def.
>
> ++---+--+
> | offset | tree_node | rtx_def  |
> ++---+--+
> |  0 | code: 16  | code: 16 | <- require the location and bitssize
> ++---+--+
> | 16 | ...   | mode: 8  |
> ++---+--+
> | ...   |
> ++---+--+
> | 24 | ...   | ...  |
> ++---+--+
>
> This behavior blocks the PATCH that extend the rtx_def mode from 8 to
> 16 bits for running out of machine mode. This PATCH introduced the 
> pointer_mux to tell the input is tree_node or rtx_def, and decouple 
> the above implicition dependency.
>
> Signed-off-by: Pan Li 
> Co-Authored-By: Richard Sandiford 
> Co-Authored-By: Richard Biener 
> Co-Authored-By: Jakub Jelinek 
>
> gcc/ChangeLog:
>
>   * mux-utils.h: Add overload operator == and != for pointer_mux.
>   * var-tracking.cc: Included mux-utils.h for pointer_tmux.
>   (decl_or_value): Changed from void * to pointer_mux.
>   (dv_is_decl_p): Reconciled to the new type, aka pointer_mux.
>   (dv_as_decl): Ditto.
>   (dv_as_opaque): Removed due to unnecessary.
>   (struct variable_hasher): Take decl_or_value as compare_type.
>   (variable_hasher::equal): Diito.
>   (dv_from_decl): Reconciled to the new type, aka pointer_mux.
>   (dv_from_value): Ditto.
>   (attrs_list_member): Ditto.
>   (vars_copy): Ditto.
>   (var_reg_decl_set): Ditto.
>   (var_reg_delete_and_set): Ditto.
>   (find_loc_in_1pdv): Ditto.
>   (canonicalize_values_star): Ditto.
>   (variable_post_merge_new_vals): Ditto.
>   (dump_onepart_variable_differences): Ditto.
>   (variable_different_p): Ditto.
>   (variable_was_changed): Ditto.
>   (set_slot_part): Ditto.
>   (clobber_slot_part): Ditto.
>   (clobber_variable_part): Ditto.
>   (remove_value_from_changed_variables): Ditto.
>   (notify_dependents_of_changed_value): Ditto.
> ---
>  gcc/mux-utils.h | 12 ++
>  gcc/var-tracking.cc | 96 
> ++---
>  2 files changed, 51 insertions(+), 57 deletions(-)
>
> diff --git a/gcc/mux-utils.h b/gcc/mux-utils.h index 
> a2b6a316899..adf3d3b722b 100644
> --- a/gcc/mux-utils.h
> +++ b/gcc/mux-utils.h
> @@ -72,6 +72,18 @@ public:
>// Return true unless the pointer is a null A pointer.
>explicit operator bool () const { return m_ptr; }
>  
> +  // Return true if class has the same m_ptr, or false.
> +  bool operator == (const pointer_mux ) const
> +{
> +  return this->m_ptr == other.m_ptr;
> +}
> +
> +  // Return true if class has the different m_ptr, or false.
> +  bool operator != (const pointer_mux ) const
> +{
> +  return this->m_ptr != other.m_ptr;
> +}
> +

The current code tries to follow the coding standard rule that functions should 
be defined outside the class if the whole thing doesn't fit on one line.  
Admittedly that's not widely followed, but we might as well continue to stick 
to it here.

The comment shouldn't talk about m_ptr, since that's an internal implementation 
detail rather than a user-facing thing.  I think it's OK to leave the functions 
uncommented, since it's obvious what == and != do.

>//

Re: [PATCH] riscv: Clarify vlmax and length handling.

2023-05-10 Thread juzhe.zh...@rivai.ai

This part LGTM.



juzhe.zh...@rivai.ai
 
From: Robin Dapp
Date: 2023-05-10 23:24
To: gcc-patches; juzhe.zh...@rivai.ai; Kito Cheng; Michael Collison; palmer; 
jeffreyalaw
CC: rdapp.gcc
Subject: [PATCH] riscv: Clarify vlmax and length handling.
Hi,
 
this patch tries to improve the wrappers that emit either vlmax or
non-vlmax operations.  Now, emit_len_op can be used to
emit a regular operation.  Depending on whether a length != NULL
is passed either no VLMAX flags are set or we emit a vsetvli and
set VLMAX flags.  The patch also adds some comments that describes
some of the rationale of the current handling of vlmax/nonvlmax
operations.
 
Bootstrapped and regtested.
 
Regards
Robin
 
--
 
gcc/ChangeLog:
 
* config/riscv/autovec.md: Use renamed functions.
* config/riscv/riscv-protos.h (emit_vlmax_op): Rename.
(emit_vlmax_reg_op): To this.
(emit_nonvlmax_op): Rename.
(emit_len_op): To this.
(emit_nonvlmax_binop): Rename.
(emit_len_binop): To this.
* config/riscv/riscv-v.cc (emit_pred_op): Add default parameter.
(emit_pred_binop): Remove vlmax_p.
(emit_vlmax_op): Rename.
(emit_vlmax_reg_op): To this.
(emit_nonvlmax_op): Rename.
(emit_len_op): To this.
(emit_nonvlmax_binop): Rename.
(emit_len_binop): To this.
(sew64_scalar_helper): Use renamed functions.
(expand_tuple_move): Use renamed functions.
* config/riscv/riscv.cc (vector_zero_call_used_regs): Use
renamed functions.
* config/riscv/vector.md: Use renamed functions.
---
gcc/config/riscv/autovec.md | 24 +-
gcc/config/riscv/riscv-protos.h |  8 ++--
gcc/config/riscv/riscv-v.cc | 82 -
gcc/config/riscv/riscv.cc   |  4 +-
gcc/config/riscv/vector.md  | 12 +++--
5 files changed, 75 insertions(+), 55 deletions(-)
 
diff --git a/gcc/config/riscv/autovec.md b/gcc/config/riscv/autovec.md
index 15f8d007e07..8347e42bb9c 100644
--- a/gcc/config/riscv/autovec.md
+++ b/gcc/config/riscv/autovec.md
@@ -31,8 +31,8 @@ (define_expand "len_load_"
(match_operand 3 "const_0_operand")]
   "TARGET_VECTOR"
{
-  riscv_vector::emit_nonvlmax_op (code_for_pred_mov (mode), operands[0],
-   operands[1], operands[2], mode);
+  riscv_vector::emit_len_op (code_for_pred_mov (mode), operands[0],
+  operands[1], operands[2], mode);
   DONE;
})
@@ -43,8 +43,8 @@ (define_expand "len_store_"
(match_operand 3 "const_0_operand")]
   "TARGET_VECTOR"
{
-  riscv_vector::emit_nonvlmax_op (code_for_pred_mov (mode), operands[0],
-   operands[1], operands[2], mode);
+  riscv_vector::emit_len_op (code_for_pred_mov (mode), operands[0],
+  operands[1], operands[2], mode);
   DONE;
})
@@ -79,15 +79,15 @@ (define_expand "3"
   if (inner == E_QImode || inner == E_HImode || inner == E_SImode)
op2mode = inner;
-  riscv_vector::emit_nonvlmax_binop (code_for_pred_scalar
- (, mode),
- operands[0], operands[1], cst,
- NULL_RTX, mode, op2mode);
+  riscv_vector::emit_len_binop (code_for_pred_scalar
+ (, mode),
+ operands[0], operands[1], cst,
+ NULL_RTX, mode, op2mode);
 }
   else
-riscv_vector::emit_nonvlmax_binop (code_for_pred
-(, mode),
-operands[0], operands[1], operands[2],
-NULL_RTX, mode);
+riscv_vector::emit_len_binop (code_for_pred
+   (, mode),
+   operands[0], operands[1], operands[2],
+   NULL_RTX, mode);
   DONE;
})
diff --git a/gcc/config/riscv/riscv-protos.h b/gcc/config/riscv/riscv-protos.h
index 75cdb90b9c9..bfdf09b17ee 100644
--- a/gcc/config/riscv/riscv-protos.h
+++ b/gcc/config/riscv/riscv-protos.h
@@ -167,10 +167,10 @@ bool legitimize_move (rtx, rtx, machine_mode);
void emit_vlmax_vsetvl (machine_mode, rtx);
void emit_hard_vlmax_vsetvl (machine_mode, rtx);
void emit_vlmax_op (unsigned, rtx, rtx, machine_mode);
-void emit_vlmax_op (unsigned, rtx, rtx, rtx, machine_mode);
-void emit_nonvlmax_op (unsigned, rtx, rtx, rtx, machine_mode);
-void emit_nonvlmax_binop (unsigned, rtx, rtx, rtx, rtx, machine_mode,
-   machine_mode = VOIDmode);
+void emit_vlmax_reg_op (unsigned, rtx, rtx, rtx, machine_mode);
+void emit_len_op (unsigned, rtx, rtx, rtx, machine_mode);
+void emit_len_binop (unsigned, rtx, rtx, rtx, rtx, machine_mode, machine_mode =
+  VOIDmode);
enum vlmul_type get_vlmul (machine_mode);
unsigned int get_ratio (machine_mode);
unsigned int get_nf (machine_mode);
diff --git a/gcc/config/riscv/riscv-v.cc b/gcc/config/riscv/riscv-v.cc
index 3c43dfc5eea..07b7783282f 100644
--- a/gcc/config/riscv/riscv-v.cc
+++ b/gcc/config/riscv/riscv-v.cc
@@ -99,27 +99,24 @@ public:
 add_vundef_operand (dest_mode);
   }
-  void set_len_and_policy (rtx len, bool vlmax_p)
+  void set_len_and_policy (rtx len, bool force_vlmax = false)
 {
+  bool vlmax_p = force_vlmax;
   gcc_assert (has_dest);
-  gcc_assert (len || vlmax_p);
-  if (len)
- add_input_operand (len, Pmode);
-  else
+  if (!len)
{
-   rtx vlmax = gen_reg_rtx (Pmode);
-   emit_vlmax_vsetvl (dest_mode, vlmax);
-   add_input_operand (vlmax, Pmode);
+   vlmax_p = true;
+   len = gen_reg_rtx

[PATCH v4] Var-Tracking: Typedef pointer_mux as decl_or_value

2023-05-10 Thread Pan Li via Gcc-patches

From: Pan Li 

The decl_or_value is defined as void * before this PATCH. It will take
care of both the tree_node and rtx_def. Unfortunately, given a void
pointer cannot tell the input is tree_node or rtx_def.

Then we have some implicit structure layout requirement similar as
below. Or we will touch unreasonable bits when cast void * to tree_node
or rtx_def.

++---+--+
| offset | tree_node | rtx_def  |
++---+--+
|  0 | code: 16  | code: 16 | <- require the location and bitssize
++---+--+
| 16 | ...   | mode: 8  |
++---+--+
| ...   |
++---+--+
| 24 | ...   | ...  |
++---+--+

This behavior blocks the PATCH that extend the rtx_def mode from 8 to
16 bits for running out of machine mode. This PATCH introduced the
pointer_mux to tell the input is tree_node or rtx_def, and decouple
the above implicit dependency.

Signed-off-by: Pan Li 
Co-Authored-By: Richard Sandiford 
Co-Authored-By: Richard Biener 
Co-Authored-By: Jakub Jelinek 

gcc/ChangeLog:

* mux-utils.h: Add overload operator == and != for pointer_mux.
* var-tracking.cc: Included mux-utils.h for pointer_tmux.
(decl_or_value): Changed from void * to pointer_mux.
(dv_is_decl_p): Reconciled to the new type, aka pointer_mux.
(dv_as_decl): Ditto.
(dv_as_opaque): Removed due to unnecessary.
(struct variable_hasher): Take decl_or_value as compare_type.
(variable_hasher::equal): Diito.
(dv_from_decl): Reconciled to the new type, aka pointer_mux.
(dv_from_value): Ditto.
(attrs_list_member):  Ditto.
(vars_copy): Ditto.
(var_reg_decl_set): Ditto.
(var_reg_delete_and_set): Ditto.
(find_loc_in_1pdv): Ditto.
(canonicalize_values_star): Ditto.
(variable_post_merge_new_vals): Ditto.
(dump_onepart_variable_differences): Ditto.
(variable_different_p): Ditto.
(set_slot_part): Ditto.
(clobber_slot_part): Ditto.
(clobber_variable_part): Ditto.
---
 gcc/mux-utils.h |  4 +++
 gcc/var-tracking.cc | 85 ++---
 2 files changed, 37 insertions(+), 52 deletions(-)

diff --git a/gcc/mux-utils.h b/gcc/mux-utils.h
index a2b6a316899..486d80915b1 100644
--- a/gcc/mux-utils.h
+++ b/gcc/mux-utils.h
@@ -117,6 +117,10 @@ public:
   //  ...use ptr.known_second ()...
   T2 *second_or_null () const;
 
+  bool operator == (const pointer_mux ) const { return m_ptr == pm.m_ptr; }
+
+  bool operator != (const pointer_mux ) const { return m_ptr != pm.m_ptr; }
+
   // Return true if the pointer is a T.
   //
   // This is only valid if T1 and T2 are distinct and if T can be
diff --git a/gcc/var-tracking.cc b/gcc/var-tracking.cc
index fae0c73e02f..1f7ec0e34ca 100644
--- a/gcc/var-tracking.cc
+++ b/gcc/var-tracking.cc
@@ -116,6 +116,7 @@
 #include "fibonacci_heap.h"
 #include "print-rtl.h"
 #include "function-abi.h"
+#include "mux-utils.h"
 
 typedef fibonacci_heap  bb_heap_t;
 
@@ -197,14 +198,14 @@ struct micro_operation
 
 
 /* A declaration of a variable, or an RTL value being handled like a
-   declaration.  */
-typedef void *decl_or_value;
+   declaration by pointer_mux.  */
+typedef pointer_mux decl_or_value;
 
 /* Return true if a decl_or_value DV is a DECL or NULL.  */
 static inline bool
 dv_is_decl_p (decl_or_value dv)
 {
-  return !dv || (int) TREE_CODE ((tree) dv) != (int) VALUE;
+  return dv.is_first ();
 }
 
 /* Return true if a decl_or_value is a VALUE rtl.  */
@@ -219,7 +220,7 @@ static inline tree
 dv_as_decl (decl_or_value dv)
 {
   gcc_checking_assert (dv_is_decl_p (dv));
-  return (tree) dv;
+  return dv.known_first ();
 }
 
 /* Return the value in the decl_or_value.  */
@@ -227,14 +228,7 @@ static inline rtx
 dv_as_value (decl_or_value dv)
 {
   gcc_checking_assert (dv_is_value_p (dv));
-  return (rtx)dv;
-}
-
-/* Return the opaque pointer in the decl_or_value.  */
-static inline void *
-dv_as_opaque (decl_or_value dv)
-{
-  return dv;
+  return dv.known_second ();
 }
 
 
@@ -483,9 +477,9 @@ static void variable_htab_free (void *);
 
 struct variable_hasher : pointer_hash 
 {
-  typedef void *compare_type;
+  typedef decl_or_value compare_type;
   static inline hashval_t hash (const variable *);
-  static inline bool equal (const variable *, const void *);
+  static inline bool equal (const variable *, const decl_or_value);
   static inline void remove (variable *);
 };
 
@@ -501,11 +495,9 @@ variable_hasher::hash (const variable *v)
 /* Compare the declaration of variable X with declaration Y.  */
 
 inline bool
-variable_hasher::equal (const variable *v, const void *y)
+variable_hasher::equal (const variable *v, const decl_or_value y)
 {
-  decl_or_value dv = CONST_CAST2 (decl_or_value, const void *, y);
-
-  return (dv_as_opaque (v->dv) == dv_as_opaque (dv));
+  return

Re: More C type errors by default for GCC 14

jwakely@gmail.com (Jonathan Wakely) writes:

> No, the proposed changes are to give errors (instead of warnings) for
> rules introduced in C99. GCC is just two decades late in enforcing the
> C99 rules properly!

The Standard requires that a diagnostic be issued upon encountering
certain kinds of invalid constructs.  Warnings are diagnostics.

Re: [PATCH] riscv: Clarify vlmax and length handling.

LGTM, and just one nit, use RISC-V in the title would be better since
Palmer's patchwork filter is set to "RISC-V", so using "riscv:" might
be missed during patchwork review meeting :P


On Thu, May 11, 2023 at 2:54 AM Palmer Dabbelt  wrote:
>
> On Wed, 10 May 2023 11:50:32 PDT (-0700), rdapp@gmail.com wrote:
> >> It's somewhat common for mail clients to treat "--" as a signature
> >> deliminator, it's "---" that git uses as a comment deliminator.
> >
> > It's in my muscle memory somehow.  Always did it that way because I
> > didn't want the same delimiter as in the git part of the message.  Time
> > to change that habit I suppose :) (or automate more of the process).
>
> I guess if you're committing your own code it doesn't matter, but mixing
> them will trip up git-am and such.
>
> The patch LGTM, but it's mostly Juzhe's code so it's probably best to at
> least give him a chance to see it when he's awake.

Re: [PATCH] riscv: Add autovectorization tests for binary integer

Don't forgot to add Michael to co-author, you can added by following line:

Co-authored-by: Michael Collison 

And GCC's changelog generating script will recognize that and generate
the right thing for that :)

[Bug c++/109806] New: 13.1.0 cc1plus stack smashing crash with C array of complex structs

2023-05-10 Thread amy at amyspark dot me via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109806

Bug ID: 109806
   Summary: 13.1.0 cc1plus stack smashing crash with C array of
complex structs
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amy at amyspark dot me
  Target Milestone: ---

Hi,

Coming from
https://github.com/msys2/MINGW-packages/pull/16968#issuecomment-1541465457.
I've found a crash in cc1plus 13.1.0 when building an array of ~68 structs in
C++. The crash yields no report or crash handling, it just causes g++  to
return exit code 1.

However, I was able to trap the cc1plus execution line, and then run it
manually under GDB. This yielded a symbolicated stacktrace that I've uploaded
along with the preprocessed file (it's 1.6MB, so it was impossible to attach
them here uncompressed):

https://gist.github.com/amyspark/be93638fc5b5779594dd138aa8995860

GCC version data:

Using built-in specs.
COLLECT_GCC=D:\msys64\ucrt64\bin\gcc.exe
COLLECT_LTO_WRAPPER=D:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-13.1.0/configure --prefix=/ucrt64
--with-local-prefix=/ucrt64/local --build=x86_64-w64-mingw32
--host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32
--with-native-system-header-dir=/ucrt64/include --libexecdir=/ucrt64/lib
--enable-bootstrap --enable-checking=release --with-arch=nocona
--with-tune=generic --enable-languages=c,lto,c++,fortran,ada,objc,obj-c++,jit
--enable-shared --enable-static --enable-libatomic --enable-threads=posix
--enable-graphite --enable-fully-dynamic-string
--enable-libstdcxx-filesystem-ts --enable-libstdcxx-time
--disable-libstdcxx-pch --enable-lto --enable-libgomp --disable-libssp
--disable-multilib --disable-rpath --disable-win32-registry --disable-nls
--disable-werror --disable-symvers --with-libiconv --with-system-zlib
--with-gmp=/ucrt64 --with-mpfr=/ucrt64 --with-mpc=/ucrt64 --with-isl=/ucrt64
--with-pkgversion=Rev4, Built by MSYS2 project
--with-bugurl=https://github.com/msys2/MINGW-packages/issues --with-gnu-as
--with-gnu-ld --enable-libstdcxx-debug --with-boot-ldflags="-static-libstdc++"
--with-stage1-ldflags="-static-libstdc++"
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.1.0 (Rev4, Built by MSYS2 project) 

Prior to https://github.com/msys2/MINGW-packages/pull/17094, the CFLAGS value
was (I added debug !strip to the PKGBUILD options to get debugging symbols):

-g -march=nocona -msahf -mtune=generic -O2 -pipe -Wp,-D_FORTIFY_SOURCE=2
-fstack-protector-strong -ggdb -Og
-ffile-prefix-map=/c/Users/Amalia/Desktop/MINGW-packages/mingw-w64-gcc/src=/usr/src/debug/mingw-w64-gcc

Re: More C type errors by default for GCC 14

Sam James  writes:

> I think the group of people dedicated enough to patch their linker would
> be able to pass a flag to the compiler to allow old constructs.

Unfortunately, we do not have the source code for our compiler.  Would
you care to ask people here to restore `gcc -traditional'?

RE: [EXTERNAL] Re: [PATCH] Fixes and workarounds for warnings during autoprofiledbootstrap build

2023-05-10 Thread Eugene Rozenfeld via Gcc-patches

I'm ok with disabling warnings as errors for autoprofiledbootstrap. What's the 
proper way to do that? Searching for "--disable-werror" I see matches in lib 
configure files but not in gcc files.

Thanks,

Eugene

-Original Message-
From: Richard Biener  
Sent: Tuesday, May 9, 2023 11:40 PM
To: Eugene Rozenfeld 
Cc: gcc-patches@gcc.gnu.org
Subject: [EXTERNAL] Re: [PATCH] Fixes and workarounds for warnings during 
autoprofiledbootstrap build

On Wed, May 10, 2023 at 3:38 AM Eugene Rozenfeld via Gcc-patches 
 wrote:
>
> autoprofiledbootstrap build produces new warnings since inlining 
> decisions are different from other builds. This patch contains fixes 
> and workarounds for those warnings.
>
> Tested on x86_64-pc-linux-gnu.

Rather than this would it make sense to add --disable-werror to 
autoprofiledbootstrap configs like we do for others?  I also wonder how 
"stable" the afdo bootstrap inlining decisions are, so applying these 
workarounds may not be sustainable?

> gcc/ChangeLog:
>
> * config/i386/i386-expand.cc (expand_vec_perm_interleave2): Work 
> around
> -Wstringop-overflow false positive during autoprofiledbootstrap
> * ipa-devirt.cc (debug_tree_odr_name): Fix for -Wformat-overflow
> warning during autoprofiledbootstrap
> * lra-eliminations.cc (setup_can_eliminate): Work around
> -Wmaybe-uninitialized false positive during autoprofiledbootstrap
> * opts-common.cc (candidates_list_and_hint): Work around
> -Wstringop-overflow false positive during autoprofiledbootstrap
> * tree-ssa-ccp.cc (bit_value_unop): Work around -Wmaybe-uninitialized
> false positive during autoprofiledbootstrap
> * wide-int.h (wi::copy): Work around -Wmaybe-uninitialized false
> positive during autoprofiledbootstrap
> ---
>  gcc/config/i386/i386-expand.cc | 11 +++
>  gcc/ipa-devirt.cc  |  3 ++-
>  gcc/lra-eliminations.cc| 11 +++
>  gcc/opts-common.cc |  1 +
>  gcc/tree-ssa-ccp.cc| 11 +++
>  gcc/wide-int.h | 11 +++
>  6 files changed, 47 insertions(+), 1 deletion(-)
>
> diff --git a/gcc/config/i386/i386-expand.cc 
> b/gcc/config/i386/i386-expand.cc index 634fe61ba79..be9f912775b 100644
> --- a/gcc/config/i386/i386-expand.cc
> +++ b/gcc/config/i386/i386-expand.cc
> @@ -20419,6 +20419,13 @@ expand_vec_perm_pblendv (struct 
> expand_vec_perm_d *d)
>
>  static bool expand_vec_perm_interleave3 (struct expand_vec_perm_d 
> *d);
>
> +/* Work around -Wstringop-overflow false positive during 
> +autoprofiledbootstrap.  */
> +
> +# if GCC_VERSION >= 7001
> +#pragma GCC diagnostic push
> +#pragma GCC diagnostic ignored "-Wstringop-overflow"
> +#endif
> +
>  /* A subroutine of ix86_expand_vec_perm_const_1.  Try to simplify
> a two vector permutation into a single vector permutation by using
> an interleave operation to merge the vectors.  */ @@ -20737,6 
> +20744,10 @@ expand_vec_perm_interleave2 (struct expand_vec_perm_d *d)
>return true;
>  }
>
> +# if GCC_VERSION >= 7001
> +#pragma GCC diagnostic pop
> +#endif
> +
>  /* A subroutine of ix86_expand_vec_perm_const_1.  Try to simplify
> a single vector cross-lane permutation into vpermq followed
> by any of the single insn permutations.  */ diff --git 
> a/gcc/ipa-devirt.cc b/gcc/ipa-devirt.cc index 819860258d1..36ea266e834 
> 100644
> --- a/gcc/ipa-devirt.cc
> +++ b/gcc/ipa-devirt.cc
> @@ -4033,7 +4033,8 @@ debug_tree_odr_name (tree type, bool demangle)
>odr = cplus_demangle (odr, opts);
>  }
>
> -  fprintf (stderr, "%s\n", odr);
> +  if (odr != NULL)
> +fprintf (stderr, "%s\n", odr);
>  }
>
>  /* Register ODR enum so we later stream record about its values.  */ 
> diff --git a/gcc/lra-eliminations.cc b/gcc/lra-eliminations.cc index 
> 4220639..05e2a7e0d68 100644
> --- a/gcc/lra-eliminations.cc
> +++ b/gcc/lra-eliminations.cc
> @@ -138,6 +138,13 @@ lra_debug_elim_table (void)
>print_elim_table (stderr);
>  }
>
> +/* Work around -Wmaybe-uninitialized false positive during 
> +autoprofiledbootstrap.  */
> +
> +# if GCC_VERSION >= 4007
> +#pragma GCC diagnostic push
> +#pragma GCC diagnostic ignored "-Wmaybe-uninitialized"
> +#endif
> +
>  /* Setup possibility of elimination in elimination table element EP to
> VALUE.  Setup FRAME_POINTER_NEEDED if elimination from frame
> pointer to stack pointer is not possible anymore.  */ @@ -152,6 
> +159,10 @@ setup_can_eliminate (class lra_elim_table *ep, bool value)
>  REGNO_POINTER_ALIGN (HARD_FRAME_POINTER_REGNUM) = 0;  }
>
> +# if GCC_VERSION >= 4007
> +#pragma GCC diagnostic pop
> +#endif
> +
>  /* Map: eliminable "from" register -> its current elimination,
> or NULL if none.  The elimination table may contain more than
> one elimination for the same hard register, but this map specifies 
> diff --git a/gcc/opts-common.cc b/gcc/opts-common.cc index 
> 23ddcaa3b55..0bb8e34e2b0 100644
> ---

Re: More C type errors by default for GCC 14

Sam James  writes:

> Nobody here is suggesting that the ability to compile this code at
> all would be removed. Throughout this thread, people discuss methods
> like e.g. adding -fpermissive to allow it.

Here, I'm saying that making it annoying to compile such code is not
going to convince people to change the way they write.

Making it impossible to do so will make them look for some other C
compiler.  So you might as well not try.

Re: More C type errors by default for GCC 14

Sam James  writes:

> No, we're talking about "things which ISO C made invalid in 1999, but
> GCC kept supporting for a while". We're discussing terminating that
> support. The "standard" part here is not about deference to the standard
> and claiming extensions can never be made, but rather that we're keeping
> something which was explicitly removed.

Which is still an extension to the Standard, and a perfectly conforming
one at that.

The same could not be said about the lack of trigraphs, and keywords
such as `asm'.

> These aren't things which were in the standard and then got removed
> because of how terrible they are. They're things that are considered
> a part of GNU C as proper GNU extensions.

Once the Standard removed those features, the implementations in GNU C
became GNU extensions.  No amount of wordplay is going to change that.

In C99 and later dialects of C, GCC even issues a diagnostic upon
encountering implicit function declarations or implicit int, thereby
satisfying that requirement of the Standard.

> Note that, per the rest of the thread, the constructs we're discussing
> here to be banned are not considered "proper GNU extensions".

Really?  It is an implementation extension, the implementation being GNU
C.  It also seems rather arrogant to assume that you have the privilege
to ban others from writing code in a certain way.

RE: [EXTERNAL] Re: [PATCH] Fixes and workarounds for warnings during autoprofiledbootstrap build

2023-05-10 Thread Eugene Rozenfeld via Gcc-patches



> I cannot find a call to this debug function on trunk.  How exactly did this 
> trigger a warning?

Here is the command during autoprofiledbootstrap build that resulted in a 
warning:

~/gcc1_objdir/gcc$ /home/erozen/gcc1_objdir/./prev-gcc/xg++ 
-B/home/erozen/gcc1_objdir/./prev-gcc/ 
-B/home/erozen/GCC1/x86_64-pc-linux-gnu/bin/ -nostdinc++ 
-B/home/erozen/gcc1_objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs 
-B/home/erozen/gcc1_objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
  
-I/home/erozen/gcc1_objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu
  -I/home/erozen/gcc1_objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/include  
-I/home/erozen/gcc1/libstdc++-v3/libsupc++ 
-L/home/erozen/gcc1_objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs 
-L/home/erozen/gcc1_objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
  -fno-PIE -c   -g -O2 -fchecking=1 -DIN_GCC -fno-exceptions -fno-rtti 
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings 
-Wcast-qual -Wmissing-format-attribute -Wconditionally-supported 
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros 
-Wno-overlength-strings -Werror -fno-common  -DHAVE_CONFIG_H 
-fauto-profile=cc1plus.fda -I. -I. -I/home/erozen/gcc1_objdir/../gcc1/gcc 
-I/home/erozen/gcc1_objdir/../gcc1/gcc/. 
-I/home/erozen/gcc1_objdir/../gcc1/gcc/../include  
-I/home/erozen/gcc1_objdir/../gcc1/gcc/../libcpp/include 
-I/home/erozen/gcc1_objdir/../gcc1/gcc/../libcody 
-I/home/erozen/gcc1_objdir/./gmp -I/home/erozen/gcc1/gmp 
-I/home/erozen/gcc1_objdir/./mpfr/src -I/home/erozen/gcc1/mpfr/src 
-I/home/erozen/gcc1/mpc/src  
-I/home/erozen/gcc1_objdir/../gcc1/gcc/../libdecnumber 
-I/home/erozen/gcc1_objdir/../gcc1/gcc/../libdecnumber/bid -I../libdecnumber 
-I/home/erozen/gcc1_objdir/../gcc1/gcc/../libbacktrace 
-I/home/erozen/gcc1_objdir/./isl/include -I/home/erozen/gcc1/isl/include  -o 
ipa-devirt.o -MT ipa-devirt.o -MMD -MP -MF ./.deps/ipa-devirt.TPo 
/home/erozen/gcc1_objdir/../gcc1/gcc/ipa-devirt.cc
/home/erozen/gcc1_objdir/../gcc1/gcc/ipa-devirt.cc: In function 'void 
debug_tree_odr_name(tree, bool)':
/home/erozen/gcc1_objdir/../gcc1/gcc/ipa-devirt.cc:4037:23: error: '%s' 
directive argument is null [-Werror=format-overflow=]
 4037 | fprintf (stderr, "%s\n", odr);


> In any case, IMHO the function should rather print something that makes it 
> clear that an odr name could not be obtained rather than printing nothing.

> I also think that if we want to handle the case, we should do it before also 
> possibly passing odr to demangler.

I'll modify the fix unless we end up suppressing warnings as errors for 
autoprofiledbootstrap as Richard suggested.

Thanks,

Martin

[r14-475 Regression] FAIL: libgomp.oacc-fortran/update-dt-array.f90 -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 -foffload=disable -O1 (test for excess errors) on Linux/x86_64

2023-05-10 Thread haochen.jiang via Gcc-patches

On Linux/x86_64,

508f082829af680ec4c1a5bcf55fe464986e3c95 is the first bad commit
commit 508f082829af680ec4c1a5bcf55fe464986e3c95
Author: Uros Bizjak 
Date:   Thu May 4 12:59:24 2023 +0200

i386: Improve index_register_operand predicate

caused

FAIL: gfortran.dg/pr65450.f90   -O3 -fomit-frame-pointer -funroll-loops 
-fpeel-loops -ftracer -finline-functions  (internal compiler error: in 
extract_insn, at recog.cc:2791)
FAIL: gfortran.dg/pr65450.f90   -O3 -fomit-frame-pointer -funroll-loops 
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: gfortran.dg/pr65450.f90   -O3 -g  (internal compiler error: in 
extract_insn, at recog.cc:2791)
FAIL: gfortran.dg/pr65450.f90   -O3 -g  (test for excess errors)
FAIL: gfortran.dg/pr88148.f90   -O  (internal compiler error: in extract_insn, 
at recog.cc:2791)
FAIL: gfortran.dg/pr88148.f90   -O  (test for excess errors)
FAIL: gfortran.dg/pr88932.f90   -O  (internal compiler error: in extract_insn, 
at recog.cc:2791)
FAIL: gfortran.dg/pr88932.f90   -O  (test for excess errors)
FAIL: gfortran.dg/pr92161.f   -O  (internal compiler error: in extract_insn, at 
recog.cc:2791)
FAIL: gfortran.dg/pr92161.f   -O  (test for excess errors)
FAIL: gfortran.dg/realloc_on_assign_10.f90   -O1  (internal compiler error: in 
extract_insn, at recog.cc:2791)
FAIL: gfortran.dg/realloc_on_assign_10.f90   -O1  (test for excess errors)
FAIL: gfortran.dg/realloc_on_assign_12.f90   -O1  (internal compiler error: in 
extract_insn, at recog.cc:2791)
FAIL: gfortran.dg/realloc_on_assign_12.f90   -O1  (test for excess errors)
FAIL: gfortran.dg/zero_sized_1.f90   -O1  (internal compiler error: in 
extract_insn, at recog.cc:2791)
FAIL: gfortran.dg/zero_sized_1.f90   -O1  (test for excess errors)
FAIL: libgomp.fortran/allocatable1.f90   -O1  (internal compiler error: in 
extract_insn, at recog.cc:2791)
FAIL: libgomp.fortran/allocatable1.f90   -O1  (test for excess errors)
FAIL: libgomp.fortran/allocatable4.f90   -O1  (internal compiler error: in 
extract_insn, at recog.cc:2791)
FAIL: libgomp.fortran/allocatable4.f90   -O1  (test for excess errors)
FAIL: libgomp.fortran/use_device_addr-5.f90   -O  (internal compiler error: in 
extract_insn, at recog.cc:2791)
FAIL: libgomp.fortran/use_device_addr-5.f90   -O  (test for excess errors)
FAIL: libgomp.oacc-fortran/gemm-2.f90 -DACC_DEVICE_TYPE_host=1 
-DACC_MEM_SHARED=1 -foffload=disable  -O1  (internal compiler error: in 
extract_insn, at recog.cc:2791)
FAIL: libgomp.oacc-fortran/gemm-2.f90 -DACC_DEVICE_TYPE_host=1 
-DACC_MEM_SHARED=1 -foffload=disable  -O1  (test for excess errors)
FAIL: libgomp.oacc-fortran/gemm.f90 -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 
-foffload=disable  -O1  (internal compiler error: in extract_insn, at 
recog.cc:2791)
FAIL: libgomp.oacc-fortran/gemm.f90 -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 
-foffload=disable  -O1  (test for excess errors)
FAIL: libgomp.oacc-fortran/update-dt-array.f90 -DACC_DEVICE_TYPE_host=1 
-DACC_MEM_SHARED=1 -foffload=disable  -O1  (internal compiler error: in 
extract_insn, at recog.cc:2791)
FAIL: libgomp.oacc-fortran/update-dt-array.f90 -DACC_DEVICE_TYPE_host=1 
-DACC_MEM_SHARED=1 -foffload=disable  -O1  (test for excess errors)

with GCC configured with

../../gcc/configure 
--prefix=/export/users/haochenj/src/gcc-bisect/master/master/r14-475/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/gcc && make check RUNTESTFLAGS="dg.exp=gfortran.dg/pr43866.f90 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check RUNTESTFLAGS="dg.exp=gfortran.dg/pr65450.f90 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check RUNTESTFLAGS="dg.exp=gfortran.dg/pr88148.f90 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check RUNTESTFLAGS="dg.exp=gfortran.dg/pr88932.f90 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check RUNTESTFLAGS="dg.exp=gfortran.dg/pr92161.f 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="dg.exp=gfortran.dg/realloc_on_assign_10.f90 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="dg.exp=gfortran.dg/realloc_on_assign_12.f90 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="dg.exp=gfortran.dg/zero_sized_1.f90 --target_board='unix{-m32\ 
-march=cascadelake}'"
$ cd {build_dir}/x86_64-linux/libgomp/testsuite && make check 
RUNTESTFLAGS="fortran.exp=libgomp.fortran/allocatable1.f90 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/x86_64-linux/libgomp/testsuite && make check 
RUNTESTFLAGS="fortran.exp=libgomp.fortran/allocatable4.f90 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd

Re: More C type errors by default for GCC 14



Po Lu via Gcc  writes:

> jwakely@gmail.com (Jonathan Wakely) writes:
>
>> So let's do it. Let's write a statement saying that the GCC developers
>> consider software security to be of increasing importance, and that we
>> consider it irresponsible to default to accepting invalid constructs in the
>> name of backwards compatibility. State that we will make some changes which
>> were a break from GCC's traditional stance, for the good of the ecosystem.
>
> I'm sorry you think that way.
>
>> Given recent pushes to discourage or outright ban the use of memory-safe
>> languages in some domains, I think it would be good to make a strong
>> statement about taking the topic seriously. And not just make a statement,
>> but take action too.
>>
>> If we don't do this, I believe it will harm GCC in the long run. The vocal
>> minority who want to preserve the C they're used to, like some kind of
>> historical reenactment society, would get their wish: it would become a
>> historical dead end and go nowhere.
>
> Vocal minority? Do you have any evidence to back this claim?
>
> What I see is that some reasonable organizations have already chosen
> other C compilers which are capable of supporting their existing large
> bodies of C code that have seen significant investment over many years,
> while others have chosen to revise their C code with each major change
> to the language.
>
> The organizations which did not wish to change their code did not
> vocally demand changes to GCC after GCC became unsuitable, but quietly
> arranged to license other compilers.
>
> Those that continue write traditional C code know what they are doing,
> and the limitations of traditional C do not affect the quality of their
> code.  For example, on the Unix systems at my organization, the SGS is
> modified so that it will not link functions called through a declaration
> with no parameter specification with a different set of parameters than
> it was defined with.

I think the group of people dedicated enough to patch their linker would
be able to pass a flag to the compiler to allow old constructs.

Re: More C type errors by default for GCC 14

jwakely@gmail.com (Jonathan Wakely) writes:

> So let's do it. Let's write a statement saying that the GCC developers
> consider software security to be of increasing importance, and that we
> consider it irresponsible to default to accepting invalid constructs in the
> name of backwards compatibility. State that we will make some changes which
> were a break from GCC's traditional stance, for the good of the ecosystem.

I'm sorry you think that way.

> Given recent pushes to discourage or outright ban the use of memory-safe
> languages in some domains, I think it would be good to make a strong
> statement about taking the topic seriously. And not just make a statement,
> but take action too.
>
> If we don't do this, I believe it will harm GCC in the long run. The vocal
> minority who want to preserve the C they're used to, like some kind of
> historical reenactment society, would get their wish: it would become a
> historical dead end and go nowhere.

Vocal minority? Do you have any evidence to back this claim?

What I see is that some reasonable organizations have already chosen
other C compilers which are capable of supporting their existing large
bodies of C code that have seen significant investment over many years,
while others have chosen to revise their C code with each major change
to the language.

The organizations which did not wish to change their code did not
vocally demand changes to GCC after GCC became unsuitable, but quietly
arranged to license other compilers.

Those that continue write traditional C code know what they are doing,
and the limitations of traditional C do not affect the quality of their
code.  For example, on the Unix systems at my organization, the SGS is
modified so that it will not link functions called through a declaration
with no parameter specification with a different set of parameters than
it was defined with.

Naturally, the modified linker is not used to run configure scripts.

Re: [PATCH] RISC-V: Support const series vector for RVV auto-vectorization

O
> diff --git a/gcc/config/riscv/riscv-protos.h b/gcc/config/riscv/riscv-protos.h
> index c0293a306f9..e8a728ae226 100644
> --- a/gcc/config/riscv/riscv-protos.h
> +++ b/gcc/config/riscv/riscv-protos.h
> @@ -219,6 +219,7 @@ rtx gen_avl_for_scalar_move (rtx);
>  void expand_tuple_move (machine_mode, rtx *);
>  machine_mode preferred_simd_mode (scalar_mode);
>  opt_machine_mode get_mask_mode (machine_mode);
> +void expand_vec_series (rtx, rtx, rtx);
>  }
>
>  /* We classify builtin types into two classes:
> diff --git a/gcc/config/riscv/riscv-v.cc b/gcc/config/riscv/riscv-v.cc
> index 7ca49ca67c1..0c3b1b4c40b 100644
> --- a/gcc/config/riscv/riscv-v.cc
> +++ b/gcc/config/riscv/riscv-v.cc
> @@ -248,6 +248,111 @@ emit_nonvlmax_op (unsigned icode, rtx dest, rtx src, 
> rtx len,
>emit_pred_op (icode, NULL_RTX, dest, src, len, mask_mode, false);
>  }
>
> +/* Emit binary operations.  */
> +
> +static void
> +emit_binop (unsigned icode, rtx *ops, machine_mode mask_mode,
> +   machine_mode scalar_mode)
> +{
> +  insn_expander<9> e;
> +  machine_mode mode = GET_MODE (ops[0]);
> +  e.add_output_operand (ops[0], mode);
> +  e.add_all_one_mask_operand (mask_mode);
> +  e.add_vundef_operand (mode);
> +  if (VECTOR_MODE_P (GET_MODE (ops[1])))
> +e.add_input_operand (ops[1], GET_MODE (ops[1]));
> +  else
> +e.add_input_operand (ops[1], scalar_mode);
> +  if (VECTOR_MODE_P (GET_MODE (ops[2])))
> +e.add_input_operand (ops[2], GET_MODE (ops[2]));
> +  else
> +e.add_input_operand (ops[2], scalar_mode);
> +  rtx vlmax = gen_reg_rtx (Pmode);
> +  emit_vlmax_vsetvl (mode, vlmax);
> +  e.add_input_operand (vlmax, Pmode);
> +  e.add_policy_operand (get_prefer_tail_policy (), get_prefer_mask_policy 
> ());
> +  e.add_avl_type_operand (avl_type::VLMAX);
> +  e.expand ((enum insn_code) icode, false);
> +}
> +
> +/* Emit vid.v instruction.  */
> +
> +static void
> +emit_indexop (rtx target, machine_mode mask_mode)

nit: rename to emit_index_op


> +void
> +expand_vec_series (rtx dest, rtx base, rtx step)
> +{
> +  machine_mode mode = GET_MODE (dest);
> +  machine_mode inner_mode = GET_MODE_INNER (mode);
> +  machine_mode mask_mode;
> +  gcc_assert (get_mask_mode (mode).exists (_mode));
> +
> +  /* VECT_IV = BASE + I * STEP.  */
> +
> +  /* Step 1: Generate I = { 0, 1, 2, ... } by vid.v.  */
> +  rtx tmp = gen_reg_rtx (mode);
> +  emit_indexop (tmp, mask_mode);
> +  if (rtx_equal_p (step, const1_rtx) && rtx_equal_p (base, const0_rtx))
> +{
> +  emit_move_insn (dest, tmp);
> +  return;
> +}
> +
> +  /* Step 2: Generate I * STEP.
> + - STEP is 1, we don't emit any instructions.
> + - STEP is power of 2, we use vsll.vi/vsll.vx.
> + - STEP is non-power of 2, we use vmul.vx.  */

The comment seems mismatch the structure of the code, I am prefer to
restructure the code to match the comment.

> diff --git a/gcc/testsuite/gcc.target/riscv/rvv/autovec/series-1.c 
> b/gcc/testsuite/gcc.target/riscv/rvv/autovec/series-1.c
> new file mode 100644
> index 000..a01f6ce7411
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/riscv/rvv/autovec/series-1.c
> @@ -0,0 +1,50 @@
> +/* { dg-do compile } */
> +/* { dg-options "-march=rv32gcv -mabi=ilp32d --param 
> riscv-autovec-preference=fixed-vlmax --param riscv-autovec-lmul=m4" } */
> +
> +#include 

Use stdint-gcc.h instead

Re: More C type errors by default for GCC 14


Po Lu via Gcc  writes:

> dje@gmail.com (David Edelsohn) writes:
>
>> This seems to be the core tension.  If developers cared about these issues,
>> they would enable appropriate warnings and -Werror.
>>
>> The code using these idioms is not safe and does create security
>> vulnerabilities.  And software security is increasingly important.
>
> Oh please.  By this definition, every bug is a security issue.
> What bugs have been caused by implicit int?
>
>> The concern is using the good will of the GNU Toolchain brand as the tip of
>> the spear or battering ram to motivate software packages to fix their
>> problems. It's using GCC as leverage in a manner that is difficult for
>> package maintainers to avoid.  Maybe that's a necessary approach, but we
>> should be clear about the reasoning.  Again, I'm not objecting, but let's
>> clarify why we are choosing this approach.
>
> You will simply make life annoying for people who already have working
> code.  People do not like it when others do that!
>
> If you make it too annoying to turn off the new diagnostics, you will
> not convince people who have not stopped writing traditional C code to
> stop doing so.
>
> Instead, they will use an older version of GCC, or license a proprietary
> compiler which allows them to keep writing use language as they always
> did.  My organization eventually chose the latter when GCC removed
> `-traditional', and to this day we continue to write code which relies
> on float arithmetic being promoted to double, unsigned narrow types
> being promoted to unsigned int, and string constants being writable.

Nobody here is suggesting that the ability to compile this code at
all would be removed. Throughout this thread, people discuss methods
like e.g. adding -fpermissive to allow it.


signature.asc
Description: PGP signature

Re: More C type errors by default for GCC 14

dje@gmail.com (David Edelsohn) writes:

> This seems to be the core tension.  If developers cared about these issues,
> they would enable appropriate warnings and -Werror.
>
> The code using these idioms is not safe and does create security
> vulnerabilities.  And software security is increasingly important.

Oh please.  By this definition, every bug is a security issue.
What bugs have been caused by implicit int?

> The concern is using the good will of the GNU Toolchain brand as the tip of
> the spear or battering ram to motivate software packages to fix their
> problems. It's using GCC as leverage in a manner that is difficult for
> package maintainers to avoid.  Maybe that's a necessary approach, but we
> should be clear about the reasoning.  Again, I'm not objecting, but let's
> clarify why we are choosing this approach.

You will simply make life annoying for people who already have working
code.  People do not like it when others do that!

If you make it too annoying to turn off the new diagnostics, you will
not convince people who have not stopped writing traditional C code to
stop doing so.

Instead, they will use an older version of GCC, or license a proprietary
compiler which allows them to keep writing use language as they always
did.  My organization eventually chose the latter when GCC removed
`-traditional', and to this day we continue to write code which relies
on float arithmetic being promoted to double, unsigned narrow types
being promoted to unsigned int, and string constants being writable.

Re: More C type errors by default for GCC 14

Po Lu via Gcc  writes:

> jwakely@gmail.com (Jonathan Wakely) writes:
>
>> This isn't "be like Clang", this is "diagnose things that have been
>> invalid C since 1999".
>
> Only if your definition of valid C is ``strictly conforming to the ISO
> Standard''.  I doubt there are many programs which fit such a
> definition.

No, we're talking about "things which ISO C made invalid in 1999, but
GCC kept supporting for a while". We're discussing terminating that
support. The "standard" part here is not about deference to the standard
and claiming extensions can never be made, but rather that we're keeping
something which was explicitly removed.

>
> And anyway, GCC accepts many other constructs which can not be used in a
> strictly conforming Standard C programs.  For example, the use of dollar
> signs in identifiers.  Should we not also reject those, identifier names
> with external linkage longer than thirty two characters, hex floats,
> arithmetic on void pointers, zero-length arrays, statement expressions,
> and so on?

These aren't things which were in the standard and then got removed
because of how terrible they are. They're things that are considered
a part of GNU C as proper GNU extensions.

Note that, per the rest of the thread, the constructs we're discussing
here to be banned are not considered "proper GNU extensions".

signature.asc
Description: PGP signature

Re: More C type errors by default for GCC 14


Po Lu via Gcc  writes:

> jwakely@gmail.com (Jonathan Wakely) writes:
>
>> This isn't "be like Clang", this is "diagnose things that have been
>> invalid C since 1999".
>
> Only if your definition of valid C is ``strictly conforming to the ISO
> Standard''.  I doubt there are many programs which fit such a
> definition.
>
> And anyway, GCC accepts many other constructs which can not be used in a
> strictly conforming Standard C programs.  For example, the use of dollar
> signs in identifiers.  Should we not also reject those, identifier names
> with external linkage longer than thirty two characters, hex floats,
> arithmetic on void pointers, zero-length arrays, statement expressions,
> and so on?
>
>> Accepting invalid code by default is a disservice to users. Those who
>> need to compile invalid C code can use an extra option to allow it,
>> the default should be to tell users their code is doing something bad.
>
> The code is conforming, it simply relies on extensions to the Standard.
> Implicit int does not break any strictly conforming program, so a C
> implementation implemented it continues to be conforming, along with
> those programs relying on implicit int.  See this wording in the
> Standard:
>
>   A conforming implementation may have extensions (including additional
>   library functions), provided they do not alter the behavior of any
>   strictly conforming program.
>
> You are not trying to reject non-conforming C code.  You are, for better
> or worse, trying to impose your personal preferences on users of GCC.
>
> Let's debate the real problem at hand instead of using the Standard as a
> boogeyman: namely, whether or not disabling implicit-int in GCC 14 is a
> good idea.

Much of the thread (including the original post) does discuss that and
it's not limited to implicit-int.


signature.asc
Description: PGP signature

Re: More C type errors by default for GCC 14

2023-05-10 Thread sergiodj at sergiodj dot net via Gcc-bugs

jwakely@gmail.com (Jonathan Wakely) writes:

> This isn't "be like Clang", this is "diagnose things that have been
> invalid C since 1999".

Only if your definition of valid C is ``strictly conforming to the ISO
Standard''.  I doubt there are many programs which fit such a
definition.

And anyway, GCC accepts many other constructs which can not be used in a
strictly conforming Standard C programs.  For example, the use of dollar
signs in identifiers.  Should we not also reject those, identifier names
with external linkage longer than thirty two characters, hex floats,
arithmetic on void pointers, zero-length arrays, statement expressions,
and so on?

> Accepting invalid code by default is a disservice to users. Those who
> need to compile invalid C code can use an extra option to allow it,
> the default should be to tell users their code is doing something bad.

The code is conforming, it simply relies on extensions to the Standard.
Implicit int does not break any strictly conforming program, so a C
implementation implemented it continues to be conforming, along with
those programs relying on implicit int.  See this wording in the
Standard:

  A conforming implementation may have extensions (including additional
  library functions), provided they do not alter the behavior of any
  strictly conforming program.

You are not trying to reject non-conforming C code.  You are, for better
or worse, trying to impose your personal preferences on users of GCC.

Let's debate the real problem at hand instead of using the Standard as a
boogeyman: namely, whether or not disabling implicit-int in GCC 14 is a
good idea.

Ping^^: [PATCH V2] extract DF/SF/SI/HI/QI subreg from parameter word on stack

2023-05-10 Thread Jiufu Guo via Gcc-patches



Hi,

I would like to ping:
https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609396.html

We know there are a few issues related to aggregate parameter and
returns.  I'm thinking if it is ok for trunk to use this patch to
resolve part of those issues.


BR,
Jeff (Jiufu)


Jiufu Guo via Gcc-patches  writes:

> Hi,
>
> Gentle ping:
> https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609396.html
>
> Thanks for comments and suggestions!
>
> I'm thinking that we may use these patches to fix some of the issues
> on parm and returns.
>
> Sorry for the late ping for this patch to ask if this is acceptable.
>
>
> BR,
> Jeff (Jiufu)
>
> Jiufu Guo  writes:
>
>> Hi,
>>
>> This patch is fixing an issue about parameter accessing if the
>> parameter is struct type and passed through integer registers, and
>> there is floating member is accessed. Like below code:
>>
>> typedef struct DF {double a[4]; long l; } DF;
>> double foo_df (DF arg){return arg.a[3];}
>>
>> On ppc64le, with trunk gcc, "std 6,-24(1) ; lfd 1,-24(1)" is
>> generated.  While instruction "mtvsrd 1, 6" would be enough for
>> this case.
>>
>> This patch updates the behavior when loading floating members of a
>> parameter: if that floating member is stored via integer register,
>> then loading it as integer mode first, and converting it to floating
>> mode.
>>
>> Compare with previous patch:
>> https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608872.html
>> Previous version supports converion from DImode to DF/SF, this
>> version also supports conversion from DImode to SI/HI/QI modes.
>>
>> I also tried to enhance CSE/DSE for this issue.  But because the
>> limitations (e.g. CSE does not like new pseudo, DSE is not good
>> at cross-blocks), some cases (as this patch) can not be handled.
>>
>> Bootstrap and regtest passes on ppc64{,le}.
>> Is this ok for trunk?  Thanks for comments!
>>
>>
>> BR,
>> Jeff (Jiufu)
>>
>>
>>  PR target/108073
>>
>> gcc/ChangeLog:
>>
>>  * expr.cc (extract_subreg_from_loading_word): New function.
>>  (expand_expr_real_1): Call extract_subreg_from_loading_word.
>>
>> gcc/testsuite/ChangeLog:
>>
>>  * g++.target/powerpc/pr102024.C: Updated.
>>  * gcc.target/powerpc/pr108073.c: New test.
>>
>> ---
>>  gcc/expr.cc | 76 +
>>  gcc/testsuite/g++.target/powerpc/pr102024.C |  2 +-
>>  gcc/testsuite/gcc.target/powerpc/pr108073.c | 30 
>>  3 files changed, 107 insertions(+), 1 deletion(-)
>>  create mode 100644 gcc/testsuite/gcc.target/powerpc/pr108073.c
>>
>> diff --git a/gcc/expr.cc b/gcc/expr.cc
>> index d9407432ea5..6de4a985c8b 100644
>> --- a/gcc/expr.cc
>> +++ b/gcc/expr.cc
>> @@ -10631,6 +10631,69 @@ stmt_is_replaceable_p (gimple *stmt)
>>return false;
>>  }
>>  
>> +/* Return the content of the memory slot SOURCE as MODE.
>> +   SOURCE is based on BASE. BASE is a memory block that is stored via words.
>> +
>> +   To get the content from SOURCE:
>> +   first load the word from the memory which covers the SOURCE slot first;
>> +   next return the word's subreg which offsets to SOURCE slot;
>> +   then convert to MODE as necessary.  */
>> +
>> +static rtx
>> +extract_subreg_from_loading_word (machine_mode mode, rtx source, rtx base)
>> +{
>> +  rtx src_base = XEXP (source, 0);
>> +  poly_uint64 offset = MEM_OFFSET (source);
>> +
>> +  if (GET_CODE (src_base) == PLUS && CONSTANT_P (XEXP (src_base, 1)))
>> +{
>> +  offset += INTVAL (XEXP (src_base, 1));
>> +  src_base = XEXP (src_base, 0);
>> +}
>> +
>> +  if (!rtx_equal_p (XEXP (base, 0), src_base))
>> +return NULL_RTX;
>> +
>> +  /* Subreg(DI,n) -> DF/SF/SI/HI/QI */
>> +  poly_uint64 word_size = GET_MODE_SIZE (word_mode);
>> +  poly_uint64 mode_size = GET_MODE_SIZE (mode);
>> +  poly_uint64 byte_off;
>> +  unsigned int start;
>> +  machine_mode int_mode;
>> +  if (known_ge (word_size, mode_size) && multiple_p (word_size, mode_size)
>> +  && int_mode_for_mode (mode).exists (_mode)
>> +  && can_div_trunc_p (offset, word_size, , _off)
>> +  && multiple_p (byte_off, mode_size))
>> +{
>> +  rtx word_mem = copy_rtx (source);
>> +  PUT_MODE (word_mem, word_mode);
>> +  word_mem = adjust_address (word_mem, word_mode, -byte_off);
>> +
>> +  rtx word_reg = gen_reg_rtx (word_mode);
>> +  emit_move_insn (word_reg, word_mem);
>> +
>> +  poly_uint64 low_off = subreg_lowpart_offset (int_mode, word_mode);
>> +  if (!known_eq (byte_off, low_off))
>> +{
>> +  poly_uint64 shift_bytes = known_gt (byte_off, low_off)
>> +  ? byte_off - low_off
>> +  : low_off - byte_off;
>> +  word_reg = expand_shift (RSHIFT_EXPR, word_mode, word_reg,
>> +   shift_bytes * BITS_PER_UNIT, word_reg, 0);
>> +}
>> +
>> +  rtx int_subreg = gen_lowpart (int_mode, word_reg);
>> +  if (mode == int_mode)
>> +return int_subreg;
>> +
>> +  rtx

[Bug debug/109805] LTO affecting -fdebug-prefix-map

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109805

--- Comment #1 from Sergio Durigan Junior  ---
The formatting for the example snippet got messed up.  Here's a fixed version:

$ echo 'int main(){}' > foo.c
$ ~/gcc/install/bin/gcc -c foo.c -O2 -g -flto=auto -ffat-lto-objects
-fdebug-prefix-map=`pwd`=/aaa -o foo
$ ~/gcc/install/bin/gcc foo -flto=auto -ffat-lto-objects -o bar

[Bug debug/109805] New: LTO affecting -fdebug-prefix-map

2023-05-10 Thread sergiodj at sergiodj dot net via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109805

Bug ID: 109805
Summary: LTO affecting -fdebug-prefix-map
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: sergiodj at sergiodj dot net
Target Milestone: ---

Hi,

In Ubuntu we use -fdebug-prefix-map to remap a package's build directory (which
contains random stuff) into a predictable path under /usr/src. This is done in
order to help debuginfod index the source code for our packages.

Things work very well, but I found a weird corner case involving LTO. The
affected package is vim. You can see the build logs for it here:

https://launchpadlibrarian.net/665520301/buildlog_ubuntu-mantic-amd64.vim_2%3A9.0.1378-2ubuntu1_BUILDING.txt.gz

As you can notice, we're using -fdebug-prefix-map and LTO for the build.

The problem is that the resulting debuginfo doesn't have the remaped directory.
I can replicate the issue locally, and at first I thought this was either bug
#108464 or #87726, but after some digging I'm convinced it's something else.
I've compiled gcc (GCC) 14.0.0 20230510 from the master branch
(608e7f3ab47fe746279c552c3574147aa3d8ee76), and I still can reproduce the
problem.

A simple reproducer for the problem follows:

$ echo 'int main(){}' > foo.c $ ~/gcc/install/bin/gcc -c foo.c -O2 -g
-flto=auto -ffat-lto-objects -fdebug-prefix-map=`pwd`=/aaa -o foo $
~/gcc/install/bin/gcc foo -flto=auto -ffat-lto-objects -o bar

A workaround for this bug is to either stop using LTO or explicitly set
-fdebug-prefix-map when linking the object.

Re: [RFC,patch] Linker plugin - extend API for offloading corner case (aka: LDPT_REGISTER_CLAIM_FILE_HOOK_V2 linker plugin hook [GCC PR109128])

2023-05-10 Thread Alan Modra via Gcc-patches

On Thu, May 04, 2023 at 11:02:25AM +, Richard Biener via Binutils wrote:
> So since we expect the linker to use the host side table is there a way
> for the plugin to exactly query that (the set of symbols the linker
> uses from the object passed to the plugin)?

That would be possible and relatively easy to implement, but might be
slow.

>  Because if the linker
> uses something from the file but _not_ the host side offload table
> (-ffunction-sections -fdata-sections) then things would still go
> wrong, right?

> Is there a way to connect both in a way that the linker discards
> either if the other isn't present?

No, or at least I do not want to even think about implementing such a
linker "feature".  The problem is that after you have modified the
global linker symbol table after adding an object's symbols, it is
virtually impossible to restore the state of symbols to what they
would be without that object.  (Yes, we do that sort of thing for
as-needed shared libraries, but the restoration happens immediately
after adding the symbols.  I also regret implementing it the way I
did.)

The patch posted is OK from the linker side of things.

-- 
Alan Modra
Australia Development Lab, IBM

[Bug debug/87726] -fdebug-prefix-map doesn't work with lto

2023-05-10 Thread sergiodj at sergiodj dot net via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87726

Sergio Durigan Junior  changed:

   What|Removed |Added

 CC||sergiodj at sergiodj dot net

--- Comment #3 from Sergio Durigan Junior  ---
FWIW, this is working for me (GCC 12).  I'm investigating another bug with
-fdebug-prefix-map and LTO, and thought this one would be related.

Re: More C type errors by default for GCC 14


"James K. Lowden"  writes:

> On Tue, 9 May 2023 23:45:50 +0100
> Jonathan Wakely via Gcc  wrote:
>
>> On Tue, 9 May 2023 at 23:38, Joel Sherrill wrote:
>> > We are currently using gcc 12 and specifying C11.  To experiment
>> > with these stricter warnings and slowly address them, would we need
>> > to build with a newer C version?
>> 
>> No, the proposed changes are to give errors (instead of warnings) for
>> rules introduced in C99. GCC is just two decades late in enforcing the
>> C99 rules properly!
>
> This, it seems to me, is the crux of the question.  Code that does not
> conform to the standard should produce an error.  Code that can be
> compiled correctly, per the specification, but might not be what the
> user intended, is a candidate for a warning.  
>
> If the proposed changes catch true errors -- not just dubious
> constructs -- that were previously allowed, well, that's the price of
> progress.  That's the compiler getting better at distinguishing between
> code conformant and not.  
>
> Section 2.1 "C Language" of the manual states that, with no option
> specified on the command line, the default standard is -std=gnu17.  
>
> Part of the proposal IIUC is to treat undeclared functions as an error.
> Function prototypes have been required afaik since c99.  If
> that's correct, then letting them pass without error is a mistake for
> -std=c99 and above.  
>
> As to the default, is anyone suggesting that gnu17 -- i.e., c17 with
> GNU extensions -- includes ignoring missing function prototypes?  That
> to me would be an odd definition of "extension".  
>
> The user who has old code that does not meet the c99 standard but Just
> Works nonetheless has a direct route to compiling that code without
> complaint: -std=c90.  It says so right there in the fine manual.  
>
> It's that simple.  The code is either in spec and compiles without
> error, or it is not and does not.  The only debate is over what "the
> spec" is, and what warnings the user might want for conforming code.  

jwakely's already dispatched with these claims, but I'd note that
if this were the case, we'd all be arguing about whether Clang
is currently conformant.

(There is a fair point in all of this about how much we want to
consider some of these constructs extensions. I'm relieved to see
that e.g. implicit func. decls weren't ever considered "real"
GNU extensions, rather something which was added for compat. for
a while, rather than something deliberately and explicitly
supported as a GNU extension forever, even just for certain Cs.)



signature.asc
Description: PGP signature

Re: More C type errors by default for GCC 14

2023-05-10 Thread Jonathan Wakely via Gcc

On Thu, 11 May 2023 at 00:18, James K. Lowden  wrote:
>
> On Tue, 9 May 2023 23:45:50 +0100
> Jonathan Wakely via Gcc  wrote:
>
> > On Tue, 9 May 2023 at 23:38, Joel Sherrill wrote:
> > > We are currently using gcc 12 and specifying C11.  To experiment
> > > with these stricter warnings and slowly address them, would we need
> > > to build with a newer C version?
> >
> > No, the proposed changes are to give errors (instead of warnings) for
> > rules introduced in C99. GCC is just two decades late in enforcing the
> > C99 rules properly!
>
> This, it seems to me, is the crux of the question.  Code that does not
> conform to the standard should produce an error.

That's not what the standard says.

>  Code that can be
> compiled correctly, per the specification, but might not be what the
> user intended, is a candidate for a warning.
>
> If the proposed changes catch true errors -- not just dubious
> constructs -- that were previously allowed, well, that's the price of
> progress.  That's the compiler getting better at distinguishing between
> code conformant and not.
>
> Section 2.1 "C Language" of the manual states that, with no option
> specified on the command line, the default standard is -std=gnu17.
>
> Part of the proposal IIUC is to treat undeclared functions as an error.
> Function prototypes have been required afaik since c99.  If
> that's correct, then letting them pass without error is a mistake for
> -std=c99 and above.

Technically, the standard only requires a diagnostic, and a warning is
a diagnostic. So strictly speaking, it's conforming to let them pass
with a warning. The question is whether that's really the best
behaviour for the majority of current users. At some point in the past
it was decided that warning and continuing by default was the best
choice. That might not still be true today.

> As to the default, is anyone suggesting that gnu17 -- i.e., c17 with
> GNU extensions -- includes ignoring missing function prototypes?  That
> to me would be an odd definition of "extension".

I don't think that actually matters here.

> The user who has old code that does not meet the c99 standard but Just
> Works nonetheless has a direct route to compiling that code without
> complaint: -std=c90.  It says so right there in the fine manual.

Indeed.

> It's that simple.  The code is either in spec and compiles without
> error, or it is not and does not.  The only debate is over what "the
> spec" is, and what warnings the user might want for conforming code.

Well, no, because issuing a warning for violations of the spec
conforms to the standard. So it's not that simple, we really do have
to decide whether to actually cause compilation failure for these
constraint violations, or just issue a diagnostic and continue.

Re: [PATCH] match.pd: Simplify popcount(X)+popcount(X|Y) as popcount(X)+popcount(Y)

2023-05-10 Thread Jeff Law via Gcc-patches





On 5/10/23 15:53, Roger Sayle wrote:


This patch teaches match.pd to simplify popcount(X)+popcount(X|Y) as
popcount(X)+popcount(Y), and the related simplifications that
popcount(X)+popcount(Y)-popcount(X) is popcount(X|Y).  As surprising
as it might seem, this idiom is common in cheminformatics codes
(for Tanimoto coefficient calculations).
I'd read the ChangeLog before reading this paragraph.  My first thought 
was "will these ever be useful".  Thanks for referring back to real code 
as a justification.




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-05-10  Roger Sayle  

gcc/ChangeLog
* match.pd : Simplify popcount(X|Y) +
popcount(X) as popcount(X)+popcount(Y).  Likewise, simplify
popcount(X)+popcount(Y)-popcount(X) as popcount(X|Y), and
vice versa.

gcc/testsuite/ChangeLog
* gcc.dg/fold-popcount-8.c: New test case.
* gcc.dg/fold-popcount-9.c: Likewise.
* gcc.dg/fold-popcount-10.c: Likewise.

OK.
jeff

Re: More C type errors by default for GCC 14

2023-05-10 Thread James K. Lowden

On Tue, 9 May 2023 23:45:50 +0100
Jonathan Wakely via Gcc  wrote:

> On Tue, 9 May 2023 at 23:38, Joel Sherrill wrote:
> > We are currently using gcc 12 and specifying C11.  To experiment
> > with these stricter warnings and slowly address them, would we need
> > to build with a newer C version?
> 
> No, the proposed changes are to give errors (instead of warnings) for
> rules introduced in C99. GCC is just two decades late in enforcing the
> C99 rules properly!

This, it seems to me, is the crux of the question.  Code that does not
conform to the standard should produce an error.  Code that can be
compiled correctly, per the specification, but might not be what the
user intended, is a candidate for a warning.  

If the proposed changes catch true errors -- not just dubious
constructs -- that were previously allowed, well, that's the price of
progress.  That's the compiler getting better at distinguishing between
code conformant and not.  

Section 2.1 "C Language" of the manual states that, with no option
specified on the command line, the default standard is -std=gnu17.  

Part of the proposal IIUC is to treat undeclared functions as an error.
Function prototypes have been required afaik since c99.  If
that's correct, then letting them pass without error is a mistake for
-std=c99 and above.  

As to the default, is anyone suggesting that gnu17 -- i.e., c17 with
GNU extensions -- includes ignoring missing function prototypes?  That
to me would be an odd definition of "extension".  

The user who has old code that does not meet the c99 standard but Just
Works nonetheless has a direct route to compiling that code without
complaint: -std=c90.  It says so right there in the fine manual.  

It's that simple.  The code is either in spec and compiles without
error, or it is not and does not.  The only debate is over what "the
spec" is, and what warnings the user might want for conforming code.  

--jkl

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

2023-05-10 Thread Jeff Law via Gcc-patches





On 5/10/23 09:47, Bernhard Reutner-Fischer via Gcc-patches wrote:

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

Just a nit:

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

Can you please use scan-tree-dump-not instead?
OK with that change.  I considered asking for the patterns to be merged, 
but I think it's easier to read with them separate.


jeff

Re: Re: [PATCH] riscv: Split off shift patterns for autovectorization.

>> I don't think VEL is _wrong_ here, as it's an integer type that's big
>> enough to hold the shift amount, but we might get some odd generated
>> code for the QI and HI flavors as we frequently don't handle the shorter
>> types well.

This implementation has been proved works well in both my downsteam GCC and 
"rvv-next".
 
>> "csr_operand" does seem wrong, though, as that just accepts constants.
>> Maybe "arith_operand" is the way to go?  I haven't looked at the
>> V immediates though.

"arith_operand" is not correct which is SMALL_OPERND - 12bit operand.
For shift V immediates should be 0 ~ 31 which perfectly match csr_operand.



juzhe.zh...@rivai.ai
 
From: Palmer Dabbelt
Date: 2023-05-11 03:19
To: rdapp.gcc
CC: gcc-patches; juzhe.zhong; Kito Cheng; collison; jeffreyalaw; rdapp.gcc
Subject: Re: [PATCH] riscv: Split off shift patterns for autovectorization.
On Wed, 10 May 2023 08:24:50 PDT (-0700), rdapp@gmail.com wrote:
> Hi,
>
> this patch splits off the shift patterns of the binop patterns.
> This is necessary as the scalar shifts require a Pmode operand
> as shift count.  To this end, a new iterator any_int_binop_no_shift
> is introduced.  At a later point when the binops are split up
> further in commutative and non-commutative patterns (which both
> do not include the shift patterns) we might not need this anymore.
>
> Bootstrapped and regtested.
>
> Regards
>  Robin
>
> --
>
> gcc/ChangeLog:
>
> * config/riscv/autovec.md (3): Add scalar shift
> pattern.
> (v3): Add vector shift pattern.
> * config/riscv/vector-iterators.md: New iterator.
> ---
>  gcc/config/riscv/autovec.md  | 40 +++-
>  gcc/config/riscv/vector-iterators.md |  4 +++
>  2 files changed, 43 insertions(+), 1 deletion(-)
>
> diff --git a/gcc/config/riscv/autovec.md b/gcc/config/riscv/autovec.md
> index 8347e42bb9c..2da4fc67d51 100644
> --- a/gcc/config/riscv/autovec.md
> +++ b/gcc/config/riscv/autovec.md
> @@ -65,7 +65,7 @@ (define_expand "movmisalign"
>
>  (define_expand "3"
>[(set (match_operand:VI 0 "register_operand")
> -(any_int_binop:VI
> +(any_int_binop_no_shift:VI
>   (match_operand:VI 1 "")
>   (match_operand:VI 2 "")))]
>"TARGET_VECTOR"
> @@ -91,3 +91,41 @@ (define_expand "3"
>NULL_RTX, mode);
>DONE;
>  })
> +
> +;; =
> +;; == Binary integer shifts by scalar.
> +;; =
> +
> +(define_expand "3"
> +  [(set (match_operand:VI 0 "register_operand")
> +(any_shift:VI
> + (match_operand:VI 1 "register_operand")
> + (match_operand: 2 "csr_operand")))]
 
I don't think VEL is _wrong_ here, as it's an integer type that's big
enough to hold the shift amount, but we might get some odd generated
code for the QI and HI flavors as we frequently don't handle the shorter
types well.
 
"csr_operand" does seem wrong, though, as that just accepts constants.
Maybe "arith_operand" is the way to go?  I haven't looked at the
V immediates though.
 
> +  "TARGET_VECTOR"
> +{
> +  if (!CONST_SCALAR_INT_P (operands[2]))
> +  operands[2] = gen_lowpart (Pmode, operands[2]);
> +  riscv_vector::emit_len_binop (code_for_pred_scalar
> + (, mode),
> + operands[0], operands[1], operands[2],
> + NULL_RTX, mode, Pmode);
> +  DONE;
> +})
> +
> +;; =
> +;; == Binary integer shifts by vector.
> +;; =
> +
> +(define_expand "v3"
> +  [(set (match_operand:VI 0 "register_operand")
> +(any_shift:VI
> + (match_operand:VI 1 "register_operand")
> + (match_operand:VI 2 "vector_shift_operand")))]
> +  "TARGET_VECTOR"
> +{
> +  riscv_vector::emit_len_binop (code_for_pred
> + (, mode),
> + operands[0], operands[1], operands[2],
> + NULL_RTX, mode);
> +  DONE;
> +})
> diff --git a/gcc/config/riscv/vector-iterators.md 
> b/gcc/config/riscv/vector-iterators.md
> index 42848627c8c..fdb0bfbe3b1 100644
> --- a/gcc/config/riscv/vector-iterators.md
> +++ b/gcc/config/riscv/vector-iterators.md
> @@ -1429,6 +1429,10 @@ (define_code_iterator any_commutative_binop [plus and 
> ior xor
>
>  (define_code_iterator any_non_commutative_binop [minus div udiv mod umod])
>
> +(define_code_iterator any_int_binop_no_shift
> + [plus minus and ior xor smax umax smin umin mult div udiv mod umod
> +])
> +
>  (define_code_iterator any_immediate_binop [plus minus and ior xor])
>
>  (define_code_iterator any_sat_int_binop [ss_plus ss_minus us_plus us_minus])
> --
> 2.40.0
 
It'd be great to have test cases for the patterns we're adding, at least
for some of the stickier ones.

Re: Re: [PATCH] riscv: Add vectorized binops and insn_expander helpers.

>> This I added in order to match the scalar variants like
 
 >>  [(set (match_operand:VI_QHS 0 "register_operand"  "=vd,vd, vr, vr")
>> (if_then_else:VI_QHS
>>   (unspec:
>> [(match_operand: 1 "vector_mask_operand" "vm,vm,Wc1,Wc1")
 >> (match_operand 5 "vector_length_operand""rK,rK, rK, rK")
>>  (match_operand 6 "const_int_operand"" i, i,  i,  i")
>>  (match_operand 7 "const_int_operand"" i, i,  i,  i")
 >> (match_operand 8 "const_int_operand"" i, i,  i,  i")
 >> (reg:SI VL_REGNUM)
 >> (reg:SI VTYPE_REGNUM)] UNSPEC_VPREDICATE)
 >>  (any_commutative_binop:VI_QHS
 >>(vec_duplicate:VI_QHS
 >>  (match_operand: 4 "reg_or_0_operand"  "rJ,rJ, rJ, rJ"))
 
>> Any other way to get there?

No, you don't need to care about that. 
Intrinsic patterns are well designed, you just use "GET_MODE_INNER" which can
well handle that.

 >> Hmm I see, the VOIDmode being abused as default might be confusing here.
 >> Would an additional parameter like "bool set_op2_mode" make it clearer?
 >> Another option is to separate this into another function altogether like
 >> emit_len_binop_scalar or so.

No, you just use op2mode which you pass through.




juzhe.zh...@rivai.ai
 
From: Robin Dapp
Date: 2023-05-11 02:02
To: 钟居哲; gcc-patches; kito.cheng; Michael Collison; palmer; Jeff Law
Subject: Re: [PATCH] riscv: Add vectorized binops and insn_expander helpers.
> +  machine_mode op2mode = Pmode;
> +  if (inner == E_QImode || inner == E_HImode || inner == E_SImode)
> + op2mode = inner;
 
This I added in order to match the scalar variants like
 
  [(set (match_operand:VI_QHS 0 "register_operand"  "=vd,vd, vr, vr")
(if_then_else:VI_QHS
  (unspec:
[(match_operand: 1 "vector_mask_operand" "vm,vm,Wc1,Wc1")
 (match_operand 5 "vector_length_operand""rK,rK, rK, rK")
 (match_operand 6 "const_int_operand"" i, i,  i,  i")
 (match_operand 7 "const_int_operand"" i, i,  i,  i")
 (match_operand 8 "const_int_operand"" i, i,  i,  i")
 (reg:SI VL_REGNUM)
 (reg:SI VTYPE_REGNUM)] UNSPEC_VPREDICATE)
  (any_commutative_binop:VI_QHS
(vec_duplicate:VI_QHS
  (match_operand: 4 "reg_or_0_operand"  "rJ,rJ, rJ, rJ"))
 
Any other way to get there?
 
> + e.add_input_operand (src2, op2mode == VOIDmode ? GET_MODE (src2) : op2mode);
> Very confusing here.
 
Hmm I see, the VOIDmode being abused as default might be confusing here.
Would an additional parameter like "bool set_op2_mode" make it clearer?
Another option is to separate this into another function altogether like
emit_len_binop_scalar or so.
 
> +  
> change it into 
 
Done and removed the rest.
 
Thanks.

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

2023-05-10 Thread mpolacek at gcc dot gnu.org via Gcc-bugs

I am sorry that I am still confused about that.

Is this what you want ?

  bool use_minus_p = TREE_CODE (step) == INTEGER_CST && ((TYPE_UNSIGNED 
(TREE_TYPE (step)) && tree_int_cst_lt (step1, step))
 || (!TYPE_UNSIGNED (TREE_TYPE (step)) && 
!tree_expr_nonnegative_warnv_p (step, ) && may_negate_without_overflow_p 
(step)));

  /* For easier readability of the created code, produce MINUS_EXPRs
 when suitable.  */
  if (TREE_CODE (step) == INTEGER_CST)
{
  if (TYPE_UNSIGNED (TREE_TYPE (step)))
{
  step1 = fold_build1 (NEGATE_EXPR, TREE_TYPE (step), step);
  if (tree_int_cst_lt (step1, step))
{
  incr_op = MINUS_EXPR; /* Remove it.  */
  step = step1;
}
}
  else
{
  bool ovf;

  if (!tree_expr_nonnegative_warnv_p (step, )
  && may_negate_without_overflow_p (step))
{
  incr_op = MINUS_EXPR; /* Remove it.  */
  step = fold_build1 (NEGATE_EXPR, TREE_TYPE (step), step);
}
}
}
  if (POINTER_TYPE_P (TREE_TYPE (base)))
{
  if (TREE_CODE (base) == ADDR_EXPR)
mark_addressable (TREE_OPERAND (base, 0));
  step = convert_to_ptrofftype (step);
  if (incr_op == MINUS_EXPR) /* Change it into if (use_minus_p)  */
step = fold_build1 (NEGATE_EXPR, TREE_TYPE (step), step);
  incr_op = POINTER_PLUS_EXPR; /* Remove it.  */
}
  /* Gimplify the step if necessary.  We put the computations in front of the
 loop (i.e. the step should be loop invariant).  */
  step = force_gimple_operand (step, , true, NULL_TREE);
  if (stmts)
gsi_insert_seq_on_edge_immediate (pe, stmts);

  if (POINTER_TYPE_P (TREE_TYPE (base)))
stmt = gimple_build_assign (va, POINTER_PLUS_EXPR, vb, step);
  else if (use_minus_p)
stmt = gimple_build_assign (va, MINUS_EXPR, vb, step);
  else
stmt = gimple_build_assign (va, incr_op, vb, step);
...

Since I have no idea to make stmts flips between PLUS_EXPR and MINUS_EXPR.

Thanks.

juzhe.zh...@rivai.ai

From: Richard Sandiford
Date: 2023-05-11 05:28
To: 钟居哲
CC: gcc-patches; rguenther
Subject: Re: [PATCH V4] VECT: Add decrement IV iteration loop control by 
variable amount support
钟居哲  writes:
> Thanks Richard.
> I am planning to seperate a patch with only creat_iv stuff only.
>
> Are you suggesting that I remove "tree_code incr_op = code;"
> Use the argument directly ?
>
> I saw the codes here:
>
>   /* For easier readability of the created code, produce MINUS_EXPRs
>  when suitable.  */
>   if (TREE_CODE (step) == INTEGER_CST)
> {
>   if (TYPE_UNSIGNED (TREE_TYPE (step)))
> {
>   step1 = fold_build1 (NEGATE_EXPR, TREE_TYPE (step), step);
>   if (tree_int_cst_lt (step1, step))
> {
>   incr_op = MINUS_EXPR;
>   step = step1;
> }
> }
>   else
> {
>   bool ovf;
>
>   if (!tree_expr_nonnegative_warnv_p (step, )
>   && may_negate_without_overflow_p (step))
> {
>   incr_op = MINUS_EXPR;
>   step = fold_build1 (NEGATE_EXPR, TREE_TYPE (step), step);
> }
> }
> }
>   if (POINTER_TYPE_P (TREE_TYPE (base)))
> {
>   if (TREE_CODE (base) == ADDR_EXPR)
> mark_addressable (TREE_OPERAND (base, 0));
>   step = convert_to_ptrofftype (step);
>   if (incr_op == MINUS_EXPR)
> step = fold_build1 (NEGATE_EXPR, TREE_TYPE (step), step);
>   incr_op = POINTER_PLUS_EXPR;
> }
>   /* Gimplify the step if necessary.  We put the computations in front of the
>  loop (i.e. the step should be loop invariant).  */
>   step = force_gimple_operand (step, , true, NULL_TREE);
>   if (stmts)
> gsi_insert_seq_on_edge_immediate (pe, stmts);
>
>   stmt = gimple_build_assign (va, incr_op, vb, step);
> ...
>
> It seems that it has complicated conditions here to change value of variable 
> "incr_op".
> That's why I define a temporary variable "tree_code incr_op = code;" here and
> let the following codes change the value of "incr_op".
>
> Could you give me some hints of dealing with this piece of code to get rid of 
> "tree_code incr_op = code;" ?

Yeah, but like I said in the review, those later:
  incr_op = MINUS_EXPR;
stmts need to be updated to something that flips between PLUS_EXPR
and MINUS_EXPR (with updates to the comments).  Just leaving them
as-is is incorrect (in cases where the caller passed MINUS_EXPR
rather than PLUS_EXPR).

The POINTER_PLUS_EXPR handling is fine due to the conditional
negate beforehand.

Thanks,
Richard

[Bug libstdc++/109772] [13/14 Regression] Memory layout optimization of std::chrono::hh_mm_ss is wrong

2023-05-10 Thread redi at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109772

--- Comment #4 from Jonathan Wakely  ---
There's another problem which is that hh_mm_ss>>
fails to compile:

/home/jwakely/gcc/13/include/c++/13.0.1/chrono: In instantiation of 'class
std::chrono::hh_mm_ss > >':
hms.cc:12:63:   required from here
/home/jwakely/gcc/13/include/c++/13.0.1/chrono:2439:37: error: ambiguous
template instantiation for 'struct
std::chrono::hh_mm_ss >
>::__subseconds > >'
 2439 | __subseconds _M_ss{};
  | ^
/home/jwakely/gcc/13/include/c++/13.0.1/chrono:2412:18: note: candidates are:
'template template  requires
!(treat_as_floating_point_v<_Rep>) && (ratio_less_v<_Period, std::ratio<1, 1>
>) && ((ratio_greater_equal_v<_Period, std::ratio<1, 250> >) ||
(__fits)) struct
std::chrono::hh_mm_ss<_Duration>::__subseconds > [with _Rep = long int; _Period = std::ratio<1, 100>; _Duration =
std::chrono::duration >]'
 2412 |   struct __subseconds>
  |  ^
/home/jwakely/gcc/13/include/c++/13.0.1/chrono:2426:18: note:
'template template  requires
!(treat_as_floating_point_v<_Rep>) && (ratio_less_v<_Period, std::ratio<1, 250>
>) && ((ratio_greater_equal_v<_Period, std::ratio<1, 40> >) ||
(__fits)) struct
std::chrono::__subseconds > [with _Rep =
long int; _Period = std::ratio<1, 100>; _Duration =
std::chrono::duration >]'
 2426 |   struct __subseconds>
  |  ^

gcc-10-20230510 is now available

2023-05-10 Thread GCC Administrator via Gcc

Snapshot gcc-10-20230510 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/10-20230510/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 10 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch 
releases/gcc-10 revision d2ddb2b9ad2b601a0e1929cefcdf21f81f7c99f2

You'll find:

 gcc-10-20230510.tar.xz   Complete GCC

  SHA256=5dff3dfb9833f7c7080f0ded78ef675c3046fcd0456eaf2cc2e34fc6ce75e2b7
  SHA1=556fe66816e3c89bc3caaf7cbef3e0225d4b7ae5

Diffs from 10-20230503 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-10
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

[Bug c++/109680] [13 Regression] is_convertible incorrectly true

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109680

Marek Polacek  changed:

   What|Removed |Added

Summary|[13/14 Regression]  |[13 Regression]
   |is_convertible incorrectly true  |int(*)()> incorrectly true

--- Comment #10 from Marek Polacek  ---
Fixed on trunk so far.

[Bug c++/109680] [13/14 Regression] is_convertible incorrectly true

2023-05-10 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109680

--- Comment #9 from CVS Commits  ---
The trunk branch has been updated by Marek Polacek :

https://gcc.gnu.org/g:4c2ffb02fd4104d77c5d907662f04434dc4c3fe8

commit r14-669-g4c2ffb02fd4104d77c5d907662f04434dc4c3fe8
Author: Marek Polacek 
Date:   Tue May 2 17:36:00 2023 -0400

c++: wrong std::is_convertible with cv-qual fn [PR109680]

This PR points out that std::is_convertible has given the wrong answer
in

  static_assert (!std::is_convertible_v , "");

since r13-2822 implemented __is_{,nothrow_}convertible.

std::is_convertible uses the imaginary

  To test() { return std::declval(); }

to do its job.  Here, From is 'int () const'.  std::declval is defined as:

  template
  typename std::add_rvalue_reference::type declval() noexcept;

std::add_rvalue_reference is defined as "If T is a function type that
has no cv- or ref- qualifier or an object type, provides a member typedef
type which is T&&, otherwise type is T."

In our case, T is cv-qualified, so the result is T, so we end up with

  int () const declval() noexcept;

which is invalid.  In other words, this is pretty much like:

  using T = int () const;
  T fn1(); // bad, fn returning a fn
  T& fn2(); // bad, cannot declare reference to qualified function type
  T* fn3(); // bad, cannot declare pointer to qualified function type

  using U = int ();
  U fn4(); // bad, fn returning a fn
  U& fn5(); // OK
  U* fn6(); // OK

I think is_convertible_helper needs to simulate std::declval better.
To that end, I'm introducing build_trait_object, to be used where
a declval is needed.

PR c++/109680

gcc/cp/ChangeLog:

* method.cc (build_trait_object): New.
(assignable_expr): Use it.
(ref_xes_from_temporary): Likewise.
(is_convertible_helper): Likewise.  Check FUNC_OR_METHOD_TYPE_P.

gcc/testsuite/ChangeLog:

* g++.dg/ext/is_convertible6.C: New test.

Re: [PATCH v2] c++: wrong std::is_convertible with cv-qual fn [PR109680]

2023-05-10 Thread Jason Merrill via Gcc-patches


On 5/10/23 17:28, Marek Polacek wrote:

On Wed, May 03, 2023 at 03:37:03PM -0400, Jason Merrill wrote:

On 5/2/23 19:10, Marek Polacek wrote:

This PR points out that std::is_convertible has given the wrong answer
in

static_assert (!std::is_convertible_v , "");

since r13-2822 implemented __is_{,nothrow_}convertible.

std::is_convertible uses the imaginary

To test() { return std::declval(); }

to do its job.  Here, From is 'int () const'.  std::declval is defined as:

template
typename std::add_rvalue_reference::type declval() noexcept;

std::add_rvalue_reference is defined as "If T is a function type that
has no cv- or ref- qualifier or an object type, provides a member typedef
type which is T&&, otherwise type is T."

In our case, T is cv-qualified, so the result is T, so we end up with

int () const declval() noexcept;

which is invalid.  In other words, this is pretty much like:

using T = int () const;
T fn1(); // bad, fn returning a fn
T& fn2(); // bad, cannot declare reference to qualified function type
T* fn3(); // bad, cannot declare pointer to qualified function type

using U = int ();
U fn4(); // bad, fn returning a fn
U& fn5(); // OK
U* fn6(); // OK

I think is_convertible_helper needs to simulate std::declval better.
I wouldn't be surprised if other type traits needed a similar fix.

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/13?

I've tested the new test with G++12 and clang++ as well (with
std::is_convertible).

PR c++/109680

gcc/cp/ChangeLog:

* method.cc (is_convertible_helper): Correct simulating std::declval.

gcc/testsuite/ChangeLog:

* g++.dg/ext/is_convertible6.C: New test.
---
   gcc/cp/method.cc   | 20 
   gcc/testsuite/g++.dg/ext/is_convertible6.C | 16 
   2 files changed, 36 insertions(+)
   create mode 100644 gcc/testsuite/g++.dg/ext/is_convertible6.C

diff --git a/gcc/cp/method.cc b/gcc/cp/method.cc
index 00eae56eb5b..38eb7520312 100644
--- a/gcc/cp/method.cc
+++ b/gcc/cp/method.cc
@@ -2245,6 +2245,26 @@ is_convertible_helper (tree from, tree to)
   {
 if (VOID_TYPE_P (from) && VOID_TYPE_P (to))
   return integer_one_node;
+  /* std::is_{,nothrow_}convertible test whether the imaginary function
+ definition
+
+   To test() { return std::declval(); }
+
+ is well-formed.  A function can't return a function...  */
+  if (FUNC_OR_METHOD_TYPE_P (to)
+  /* ...neither can From be a function with cv-/ref-qualifiers:
+std::declval is defined as
+
+ template
+ typename std::add_rvalue_reference::type declval() noexcept;
+
+   and std::add_rvalue_reference yields T when T is a function with
+   cv- or ref-qualifiers, making the definition ill-formed.
+   ??? Should we check this in other uses of build_stub_object too?  */


Probably we want a build_trait_object that wraps build_stub_object with
these extra checks, or does something that exercises more of the normal
code, maybe by tsubsting into T (U&&) with { to, from }?


I did the former.  We only have the To type when processing
__is_convertible, so I think that can't be part of the declval
function, which takes another type, From.  IOW, if we want to factor
declval out, build_trait_object will take only one type.  Eh, that
still sounds confusing.  But the patch is simple.

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?


OK.


-- >8 --
This PR points out that std::is_convertible has given the wrong answer
in

   static_assert (!std::is_convertible_v , "");

since r13-2822 implemented __is_{,nothrow_}convertible.

std::is_convertible uses the imaginary

   To test() { return std::declval(); }

to do its job.  Here, From is 'int () const'.  std::declval is defined as:

   template
   typename std::add_rvalue_reference::type declval() noexcept;

std::add_rvalue_reference is defined as "If T is a function type that
has no cv- or ref- qualifier or an object type, provides a member typedef
type which is T&&, otherwise type is T."

In our case, T is cv-qualified, so the result is T, so we end up with

   int () const declval() noexcept;

which is invalid.  In other words, this is pretty much like:

   using T = int () const;
   T fn1(); // bad, fn returning a fn
   T& fn2(); // bad, cannot declare reference to qualified function type
   T* fn3(); // bad, cannot declare pointer to qualified function type

   using U = int ();
   U fn4(); // bad, fn returning a fn
   U& fn5(); // OK
   U* fn6(); // OK

I think is_convertible_helper needs to simulate std::declval better.
To that end, I'm introducing build_trait_object, to be used where
a declval is needed.

PR c++/109680

gcc/cp/ChangeLog:

* method.cc (build_trait_object): New.
(assignable_expr): Use it.
(ref_xes_from_temporary): Likewise.
(is_convertible_helper): Likewise.  Check FUNC_OR_METHOD_TYPE_P.

Re: [PATCH] i386: Honour -mdirect-extern-access when calling fentry

2023-05-10 Thread H.J. Lu via Gcc-patches

On Wed, May 10, 2023 at 2:17 AM Uros Bizjak  wrote:
>
> On Tue, May 9, 2023 at 10:58 AM Ard Biesheuvel  wrote:
> >
> > The small and medium PIC code models generate profiling calls that
> > always load the address of __fentry__() via the GOT, even if
> > -mdirect-extern-access is in effect.
> >
> > This deviates from the behavior with respect to other external
> > references, and results in a longer opcode that relies on linker
> > relaxation to eliminate the GOT load. In this particular case, the
> > transformation replaces an indirect 'CALL *__fentry__@GOTPCREL(%rip)'
> > with either 'CALL __fentry__; NOP' or 'NOP; CALL __fentry__', where the
> > NOP is a 1 byte NOP that preserves the 6 byte length of the sequence.
> >
> > This is problematic for the Linux kernel, which generally relies on
> > -mdirect-extern-access and hidden visibility to eliminate GOT based
> > symbol references in code generated with -fpie/-fpic, without having to
> > depend on linker relaxation.
> >
> > The Linux kernel relies on code patching to replace these opcodes with
> > NOPs at runtime, and this is complicated code that we'd prefer not to
> > complicate even more by adding support for patching both 5 and 6 byte
> > sequences as well as parsing the instruction stream to decide which
> > variant of CALL+NOP we are dealing with.
> >
> > So let's honour -mdirect-extern-access, and only load the address of
> > __fentry__ via the GOT if direct references to external symbols are not
> > permitted.
> >
> > Note that the GOT reference in question is in fact a data reference: we
> > explicitly load the address of __fentry__ from the GOT, which amounts to
> > eager binding, rather than emitting a PLT call that could bind eagerly,
> > lazily or directly at link time.
> >
> > gcc/ChangeLog:
> >
> > * config/i386/i386.cc (x86_function_profiler): Take
> >   ix86_direct_extern_access into account when generating calls
> >   to __fentry__()
>
> HJ, is the patch OK with you?

LGTM.

Thanks.

> Uros.
>
> >
> > Cc: H.J. Lu 
> > Cc: Jakub Jelinek 
> > Cc: Richard Biener 
> > Cc: Uros Bizjak 
> > Cc: Hou Wenlong 
> > ---
> >  gcc/config/i386/i386.cc | 8 ++--
> >  1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
> > index b1d08ecdb3d44729..69b183abb4318b0a 100644
> > --- a/gcc/config/i386/i386.cc
> > +++ b/gcc/config/i386/i386.cc
> > @@ -21836,8 +21836,12 @@ x86_function_profiler (FILE *file, int labelno 
> > ATTRIBUTE_UNUSED)
> >   break;
> > case CM_SMALL_PIC:
> > case CM_MEDIUM_PIC:
> > - fprintf (file, "1:\tcall\t*%s@GOTPCREL(%%rip)\n", 
> > mcount_name);
> > - break;
> > + if (!ix86_direct_extern_access)
> > +   {
> > + fprintf (file, "1:\tcall\t*%s@GOTPCREL(%%rip)\n", 
> > mcount_name);
> > + break;
> > +   }
> > + /* fall through */
> > default:
> >   x86_print_call_or_nop (file, mcount_name);
> >   break;
> > --
> > 2.39.2
> >



-- 
H.J.

[PATCH] match.pd: Simplify popcount(X)+popcount(X|Y) as popcount(X)+popcount(Y)

2023-05-10 Thread Roger Sayle


This patch teaches match.pd to simplify popcount(X)+popcount(X|Y) as
popcount(X)+popcount(Y), and the related simplifications that
popcount(X)+popcount(Y)-popcount(X) is popcount(X|Y).  As surprising
as it might seem, this idiom is common in cheminformatics codes
(for Tanimoto coefficient calculations).

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-05-10  Roger Sayle  

gcc/ChangeLog
* match.pd : Simplify popcount(X|Y) +
popcount(X) as popcount(X)+popcount(Y).  Likewise, simplify
popcount(X)+popcount(Y)-popcount(X) as popcount(X|Y), and
vice versa.

gcc/testsuite/ChangeLog
* gcc.dg/fold-popcount-8.c: New test case.
* gcc.dg/fold-popcount-9.c: Likewise.
* gcc.dg/fold-popcount-10.c: Likewise.


Thanks in advance,
Roger
--

diff --git a/gcc/match.pd b/gcc/match.pd
index ceae1c3..accae2a 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -7771,6 +7771,25 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
   (bit_and (POPCOUNT @0) integer_onep)
   (PARITY @0))
 
+/* popcount(X) + popcount(X|Y) is popcount(x) + popcount(Y).  */
+(simplify
+  (plus:c (POPCOUNT:s (bit_and:s @0 @1)) (POPCOUNT:s (bit_ior:cs @0 @1)))
+  (plus (POPCOUNT @0) (POPCOUNT @1)))
+
+/* popcount(X) + popcount(Y) - popcount(X) is popcount(X|Y).  */
+/* popcount(X) + popcount(Y) - popcount(X|Y) is popcount(X).  */
+(for popcount (POPCOUNT)
+  (for log1 (bit_and bit_ior)
+   log2 (bit_ior bit_and)
+(simplify
+  (minus (plus:s (popcount:s @0) (popcount:s @1))
+(popcount:s (log1:cs @0 @1)))
+  (popcount (log2 @0 @1)))
+(simplify
+  (plus:c (minus:s (popcount:s @0) (popcount:s (log1:cs @0 @1)))
+ (popcount:s @1))
+  (popcount (log2 @0 @1)
+
 /* PARITY simplifications.  */
 /* parity(~X) is parity(X).  */
 (simplify
diff --git a/gcc/testsuite/gcc.dg/fold-popcount-10.c 
b/gcc/testsuite/gcc.dg/fold-popcount-10.c
new file mode 100644
index 000..fa8a52a
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/fold-popcount-10.c
@@ -0,0 +1,28 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-optimized" } */
+
+#define popc __builtin_popcount
+
+int foo1(unsigned int x, unsigned int y)
+{
+  return popc (x) + popc (y) - popc (x|y);
+}
+
+int foo2(unsigned int x, unsigned int y)
+{
+  return popc (y) + popc (x) - popc (x|y);
+}
+
+int foo3(unsigned int x, unsigned int y)
+{
+  return (popc (x) - popc (x|y)) + popc (y);
+}
+
+int foo4(unsigned int x, unsigned int y)
+{
+  return (popc (y) - popc (x|y)) + popc (x);
+}
+
+/* { dg-final { scan-tree-dump-not " \\| " "optimized" } } */
+/* { dg-final { scan-tree-dump-times " & " 4 "optimized" } } */
+/* { dg-final { scan-tree-dump-times "popcount " 4 "optimized" } } */
diff --git a/gcc/testsuite/gcc.dg/fold-popcount-8.c 
b/gcc/testsuite/gcc.dg/fold-popcount-8.c
new file mode 100644
index 000..9599a3c
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/fold-popcount-8.c
@@ -0,0 +1,25 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-optimized" } */
+
+int foo1(unsigned int x, unsigned int y)
+{
+  return __builtin_popcount (x) + __builtin_popcount (x|y);
+}
+
+int foo2(unsigned int x, unsigned int y)
+{
+  return __builtin_popcount (x) + __builtin_popcount (y|x);
+}
+
+int foo3(unsigned int x, unsigned int y)
+{
+  return __builtin_popcount (x|y) + __builtin_popcount (x);
+}
+
+int foo4(unsigned int x, unsigned int y)
+{
+  return __builtin_popcount (x|y) + __builtin_popcount (y);
+}
+
+/* { dg-final { scan-tree-dump-not " & " "optimized" } } */
+/* { dg-final { scan-tree-dump-not " \\| " "optimized" } } */
diff --git a/gcc/testsuite/gcc.dg/fold-popcount-9.c 
b/gcc/testsuite/gcc.dg/fold-popcount-9.c
new file mode 100644
index 000..a9ffa62
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/fold-popcount-9.c
@@ -0,0 +1,28 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-optimized" } */
+
+#define popc __builtin_popcount
+
+int foo1(unsigned int x, unsigned int y)
+{
+  return popc (x) + popc (y) - popc (x);
+}
+
+int foo2(unsigned int x, unsigned int y)
+{
+  return popc (y) + popc (x) - popc (x);
+}
+
+int foo3(unsigned int x, unsigned int y)
+{
+  return (popc (x) - popc (x)) + popc (y);
+}
+
+int foo4(unsigned int x, unsigned int y)
+{
+  return (popc (y) - popc (x)) + popc (x);
+}
+
+/* { dg-final { scan-tree-dump-not " & " "optimized" } } */
+/* { dg-final { scan-tree-dump-times " \\| " 4 "optimized" } } */
+/* { dg-final { scan-tree-dump-times "popcount " 4 "optimized" } } */

[Bug tree-optimization/109804] [11/12/13/14 Regression] internal compiler error in gimple-ssa-warn-access.cc

2023-05-10 Thread mpolacek at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109804

--- Comment #9 from Marek Polacek  ---
Right.  Local unnamed enums are of the DEMANGLE_COMPONENT_UNNAMED_TYPE type,
but those don't have their subtrees filed as per cplus_demangle_fill_component.
 So I think we can't do *newc.u.s_binary.left when the type is
DEMANGLE_COMPONENT_UNNAMED_TYPE.  Maybe they need a new case in
new_delete_mismatch_p.

[Bug fortran/109788] [14 Regression] gcc/hwint.h:293:61: runtime error: shift exponent 64 is too large for 64-bit type 'long unsigned int since r14-377-gc92b8be9b52b7e

2023-05-10 Thread jakub at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109788

--- Comment #11 from Jakub Jelinek  ---
If you e.g. put breakpoint on the spot I changed and stopon the testcase with
-Os when t == global_trees[TI_VOID_LIST_NODE] you can then see in e->callee the
FUNCTION_TYPE with just 5 arguments.

[Bug fortran/109788] [14 Regression] gcc/hwint.h:293:61: runtime error: shift exponent 64 is too large for 64-bit type 'long unsigned int since r14-377-gc92b8be9b52b7e

2023-05-10 Thread anlauf at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109788

--- Comment #10 from anlauf at gcc dot gnu.org ---
Can you tell whether you see other intrinsics with bad FUNCTION_TYPE?
E.g. if we have a similar issue with pack_char or pack_s_char?

In that case I have a vague idea why it happens, but do not yet know how
to solve this.

Regarding the prototype fix: would it be ok if we add an
__attribute__((unused))
to the affected-but-unused arguments, as that is already there for the
actual implementation?  And would that make a difference for the ABI?

[PATCH v2] c++: wrong std::is_convertible with cv-qual fn [PR109680]

2023-05-10 Thread Marek Polacek via Gcc-patches

On Wed, May 03, 2023 at 03:37:03PM -0400, Jason Merrill wrote:
> On 5/2/23 19:10, Marek Polacek wrote:
> > This PR points out that std::is_convertible has given the wrong answer
> > in
> > 
> >static_assert (!std::is_convertible_v , "");
> > 
> > since r13-2822 implemented __is_{,nothrow_}convertible.
> > 
> > std::is_convertible uses the imaginary
> > 
> >To test() { return std::declval(); }
> > 
> > to do its job.  Here, From is 'int () const'.  std::declval is defined as:
> > 
> >template
> >typename std::add_rvalue_reference::type declval() noexcept;
> > 
> > std::add_rvalue_reference is defined as "If T is a function type that
> > has no cv- or ref- qualifier or an object type, provides a member typedef
> > type which is T&&, otherwise type is T."
> > 
> > In our case, T is cv-qualified, so the result is T, so we end up with
> > 
> >int () const declval() noexcept;
> > 
> > which is invalid.  In other words, this is pretty much like:
> > 
> >using T = int () const;
> >T fn1(); // bad, fn returning a fn
> >T& fn2(); // bad, cannot declare reference to qualified function type
> >T* fn3(); // bad, cannot declare pointer to qualified function type
> > 
> >using U = int ();
> >U fn4(); // bad, fn returning a fn
> >U& fn5(); // OK
> >U* fn6(); // OK
> > 
> > I think is_convertible_helper needs to simulate std::declval better.
> > I wouldn't be surprised if other type traits needed a similar fix.
> > 
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/13?
> > 
> > I've tested the new test with G++12 and clang++ as well (with
> > std::is_convertible).
> > 
> > PR c++/109680
> > 
> > gcc/cp/ChangeLog:
> > 
> > * method.cc (is_convertible_helper): Correct simulating std::declval.
> > 
> > gcc/testsuite/ChangeLog:
> > 
> > * g++.dg/ext/is_convertible6.C: New test.
> > ---
> >   gcc/cp/method.cc   | 20 
> >   gcc/testsuite/g++.dg/ext/is_convertible6.C | 16 
> >   2 files changed, 36 insertions(+)
> >   create mode 100644 gcc/testsuite/g++.dg/ext/is_convertible6.C
> > 
> > diff --git a/gcc/cp/method.cc b/gcc/cp/method.cc
> > index 00eae56eb5b..38eb7520312 100644
> > --- a/gcc/cp/method.cc
> > +++ b/gcc/cp/method.cc
> > @@ -2245,6 +2245,26 @@ is_convertible_helper (tree from, tree to)
> >   {
> > if (VOID_TYPE_P (from) && VOID_TYPE_P (to))
> >   return integer_one_node;
> > +  /* std::is_{,nothrow_}convertible test whether the imaginary function
> > + definition
> > +
> > +   To test() { return std::declval(); }
> > +
> > + is well-formed.  A function can't return a function...  */
> > +  if (FUNC_OR_METHOD_TYPE_P (to)
> > +  /* ...neither can From be a function with cv-/ref-qualifiers:
> > +std::declval is defined as
> > +
> > + template
> > + typename std::add_rvalue_reference::type declval() noexcept;
> > +
> > +   and std::add_rvalue_reference yields T when T is a function with
> > +   cv- or ref-qualifiers, making the definition ill-formed.
> > +   ??? Should we check this in other uses of build_stub_object too?  */
> 
> Probably we want a build_trait_object that wraps build_stub_object with
> these extra checks, or does something that exercises more of the normal
> code, maybe by tsubsting into T (U&&) with { to, from }?

I did the former.  We only have the To type when processing
__is_convertible, so I think that can't be part of the declval
function, which takes another type, From.  IOW, if we want to factor
declval out, build_trait_object will take only one type.  Eh, that
still sounds confusing.  But the patch is simple.

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?

-- >8 --
This PR points out that std::is_convertible has given the wrong answer
in

  static_assert (!std::is_convertible_v , "");

since r13-2822 implemented __is_{,nothrow_}convertible.

std::is_convertible uses the imaginary

  To test() { return std::declval(); }

to do its job.  Here, From is 'int () const'.  std::declval is defined as:

  template
  typename std::add_rvalue_reference::type declval() noexcept;

std::add_rvalue_reference is defined as "If T is a function type that
has no cv- or ref- qualifier or an object type, provides a member typedef
type which is T&&, otherwise type is T."

In our case, T is cv-qualified, so the result is T, so we end up with

  int () const declval() noexcept;

which is invalid.  In other words, this is pretty much like:

  using T = int () const;
  T fn1(); // bad, fn returning a fn
  T& fn2(); // bad, cannot declare reference to qualified function type
  T* fn3(); // bad, cannot declare pointer to qualified function type

  using U = int ();
  U fn4(); // bad, fn returning a fn
  U& fn5(); // OK
  U* fn6(); // OK

I think is_convertible_helper needs to simulate std::declval better.
To that end, I'm introducing build_trait_object, to be used where
a declval is needed.

PR c++/109680

gcc/cp/ChangeLog:

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

2023-05-10 Thread Richard Sandiford via Gcc-patches

钟居哲  writes:
> Thanks Richard.
> I am planning to seperate a patch with only creat_iv stuff only.
>
> Are you suggesting that I remove "tree_code incr_op = code;"
> Use the argument directly ?
>
> I saw the codes here:
>
>   /* For easier readability of the created code, produce MINUS_EXPRs
>  when suitable.  */
>   if (TREE_CODE (step) == INTEGER_CST)
> {
>   if (TYPE_UNSIGNED (TREE_TYPE (step)))
> {
>   step1 = fold_build1 (NEGATE_EXPR, TREE_TYPE (step), step);
>   if (tree_int_cst_lt (step1, step))
> {
>   incr_op = MINUS_EXPR;
>   step = step1;
> }
> }
>   else
> {
>   bool ovf;
>
>   if (!tree_expr_nonnegative_warnv_p (step, )
>   && may_negate_without_overflow_p (step))
> {
>   incr_op = MINUS_EXPR;
>   step = fold_build1 (NEGATE_EXPR, TREE_TYPE (step), step);
> }
> }
> }
>   if (POINTER_TYPE_P (TREE_TYPE (base)))
> {
>   if (TREE_CODE (base) == ADDR_EXPR)
> mark_addressable (TREE_OPERAND (base, 0));
>   step = convert_to_ptrofftype (step);
>   if (incr_op == MINUS_EXPR)
> step = fold_build1 (NEGATE_EXPR, TREE_TYPE (step), step);
>   incr_op = POINTER_PLUS_EXPR;
> }
>   /* Gimplify the step if necessary.  We put the computations in front of the
>  loop (i.e. the step should be loop invariant).  */
>   step = force_gimple_operand (step, , true, NULL_TREE);
>   if (stmts)
> gsi_insert_seq_on_edge_immediate (pe, stmts);
>
>   stmt = gimple_build_assign (va, incr_op, vb, step);
> ...
>
> It seems that it has complicated conditions here to change value of variable 
> "incr_op".
> That's why I define a temporary variable "tree_code incr_op = code;" here and
> let the following codes change the value of "incr_op".
>
> Could you give me some hints of dealing with this piece of code to get rid of 
> "tree_code incr_op = code;" ?

Yeah, but like I said in the review, those later:
 
  incr_op = MINUS_EXPR;
 
stmts need to be updated to something that flips between PLUS_EXPR
and MINUS_EXPR (with updates to the comments).  Just leaving them
as-is is incorrect (in cases where the caller passed MINUS_EXPR
rather than PLUS_EXPR).

The POINTER_PLUS_EXPR handling is fine due to the conditional
negate beforehand.

Thanks,
Richard

Re: [PATCH] c++: converted lambda as template argument [PR83258, ...]

2023-05-10 Thread Jason Merrill via Gcc-patches


On 5/10/23 14:11, Patrick Palka wrote:

On Wed, 10 May 2023, Jason Merrill wrote:


On 5/10/23 11:36, Patrick Palka wrote:

r8-1253-g3d2e25a240c711 removed the template argument linkage requirement
in convert_nontype_argument for C++17, but we need to also remove the one
in convert_nontype_argument_function for sake of the first and third test
case which we incorrectly reject (in C++17/20 mode).

And in invalid_tparm_referent_p we're inadvertendly rejecting using the
address of a lambda's static op() due to the DECL_ARTIFICIAL check.
This patch relaxes this check for sake of the second test case which we
incorrectly reject (in C++20 mode).

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk and perhaps 13 (since it's a relatively easy/safe fix for a
popular non-regression bug).

Co-authored-by: Jonathan Wakely 

PR c++/83258
PR c++/80488
PR c++/97700

gcc/cp/ChangeLog:

* pt.cc (convert_nontype_argument_function): Disable linkage
requirement for C++17 and later.
(invalid_tparm_referent_p): Relax DECL_ARTIFICIAL check for
the artificial static op() of a lambda.

gcc/testsuite/ChangeLog:

* g++.dg/ext/visibility/anon8.C: Don't expect a "no linkage"
error for the template argument :fn in C++17 mode.
* g++.dg/cpp0x/lambda/lambda-conv15.C: New test.
* g++.dg/cpp2a/nontype-class56.C: New test.
* g++.dg/template/function2.C: New test.
---
   gcc/cp/pt.cc  |  7 +--
   gcc/testsuite/g++.dg/cpp0x/lambda/lambda-conv15.C | 11 +++
   gcc/testsuite/g++.dg/cpp2a/nontype-class56.C  |  8 
   gcc/testsuite/g++.dg/ext/visibility/anon8.C   |  4 ++--
   gcc/testsuite/g++.dg/template/function2.C |  8 
   5 files changed, 34 insertions(+), 4 deletions(-)
   create mode 100644 gcc/testsuite/g++.dg/cpp0x/lambda/lambda-conv15.C
   create mode 100644 gcc/testsuite/g++.dg/cpp2a/nontype-class56.C
   create mode 100644 gcc/testsuite/g++.dg/template/function2.C

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 696df2bdd9f..c9b089f8fa7 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -6782,7 +6782,8 @@ convert_nontype_argument_function (tree type, tree
expr,
   }
   linkage = decl_linkage (fn_no_ptr);
-  if (cxx_dialect >= cxx11 ? linkage == lk_none : linkage != lk_external)
+  if ((cxx_dialect < cxx11 && linkage != lk_external)
+  || (cxx_dialect < cxx17 && linkage == lk_none))
   {
 if (complain & tf_error)
{
@@ -7180,7 +7181,9 @@ invalid_tparm_referent_p (tree type, tree expr,
tsubst_flags_t complain)
   * a string literal (5.13.5),
   * the result of a typeid expression (8.2.8), or
   * a predefined __func__ variable (11.4.1).  */
-   else if (DECL_ARTIFICIAL (decl))
+   else if (DECL_ARTIFICIAL (decl)
+/* Accept the artificial static op() of a lambda.  */
+&& !LAMBDA_TYPE_P (CP_DECL_CONTEXT (decl)))


Maybe check for FUNCTION_DECL instead?  I think the cases we want to diagnose
are all VAR_DECL.


Makes sense, before r13-6970-gb5e38b1c166357 this code path would only
be reachable for VAR_DECL anyway.  Like so?  Bootstrapped and regtested
on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps 13?


OK for both.


-- >8 --

Subject: [PATCH] c++: converted lambda as template argument [PR83258, ...]

r8-1253-g3d2e25a240c711 removed the template argument linkage requirement
in convert_nontype_argument for C++17, but we need to also remove the one
in convert_nontype_argument_function for sake of the first and third test
case which we incorrectly reject (in C++17/20 mode).

And in invalid_tparm_referent_p we're inadvertendly diagnosing using the
address of a lambda's static op() since it's DECL_ARTIFICIAL, which causes
us to reject the second (C++20) testcase.  But this DECL_ARTIFICIAL check
seems to be relevant only for VAR_DECL, and indeed code path was reached
only for VAR_DECL until r13-6970-gb5e38b1c166357.  So this patch relaxes
the check accordingly.

Co-authored-by: Jonathan Wakely 

PR c++/83258
PR c++/80488
PR c++/97700

gcc/cp/ChangeLog:

* pt.cc (convert_nontype_argument_function): Disable linkage
check for C++17 and later.
(invalid_tparm_referent_p): Accept DECL_ARTIFICIAL FUNCTION_DECL.

gcc/testsuite/ChangeLog:

* g++.dg/ext/visibility/anon8.C: Don't expect a "no linkage"
error for the template argument :fn in C++17 mode.
* g++.dg/cpp0x/lambda/lambda-conv15.C: New test.
* g++.dg/cpp2a/nontype-class56.C: New test.
* g++.dg/template/function2.C: New test.
---
  gcc/cp/pt.cc  |  5 +++--
  gcc/testsuite/g++.dg/cpp0x/lambda/lambda-conv15.C | 11 +++
  gcc/testsuite/g++.dg/cpp2a/nontype-class56.C  |  8 
  gcc/testsuite/g++.dg/ext/visibility/anon8.C   |  4 ++--

[Bug tree-optimization/109804] [11/12/13/14 Regression] internal compiler error in gimple-ssa-warn-access.cc

2023-05-10 Thread pinskia at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109804

--- Comment #8 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #7)
> I am suspecting the `unnamed enum` is causing the ICE.

I mean the local unnamed enums is what is exposing the ICE. Naming either of
them and the ICE goes away.

[Bug tree-optimization/109804] [11/12/13/14 Regression] internal compiler error in gimple-ssa-warn-access.cc

2023-05-10 Thread pinskia at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109804

--- Comment #7 from Andrew Pinski  ---
I am suspecting the `unnamed enum` is causing the ICE.

[Bug tree-optimization/109804] [11/12/13/14 Regression] internal compiler error in gimple-ssa-warn-access.cc

2023-05-10 Thread pinskia at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109804

--- Comment #6 from Andrew Pinski  ---
Note the ICE moved from maybe_emit_free_warning in expand.c in GCC 11 to
new_delete_mismatch_p in gimple-ssa-warn-access.cc in GCC 12+.

[Bug tree-optimization/109804] internal compiler error in gimple-ssa-warn-access.cc

2023-05-10 Thread pinskia at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109804

--- Comment #5 from Andrew Pinski  ---
Created attachment 55044
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55044=edit
reduced as much as I could get it for the trunk (note GCC 11 fails still too)

[Bug tree-optimization/109804] internal compiler error in gimple-ssa-warn-access.cc

2023-05-10 Thread pinskia at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109804

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-05-10
 Status|UNCONFIRMED |NEW

--- Comment #4 from Andrew Pinski  ---
.

[Bug tree-optimization/109804] internal compiler error in gimple-ssa-warn-access.cc

2023-05-10 Thread pinskia at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109804

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed|2023-05-10 00:00:00 |
 Ever confirmed|1   |0
 Status|NEW |UNCONFIRMED
Summary|[11/12/13/14 Regression]|internal compiler error in
   |internal compiler error in  |gimple-ssa-warn-access.cc
   |gimple-ssa-warn-access.cc   |
  Known to fail||11.1.0, 12.1.0, 13.1.0,
   ||14.0

[pushed] c++: adjust conversion diagnostics

2023-05-10 Thread Jason Merrill via Gcc-patches

Tested x86_64-pc-linux-gnu, applying to trunk.

-- 8< --

While looking at PR109247 I made this change to improve diagnostics.  I
don't think I'm going ahead with that patch, but this still seems like a
worthy cleanup.

gcc/cp/ChangeLog:

* call.cc (convert_like_internal): Share ck_ref_bind handling
between all bad conversions.
---
 gcc/cp/call.cc | 20 +---
 1 file changed, 9 insertions(+), 11 deletions(-)

diff --git a/gcc/cp/call.cc b/gcc/cp/call.cc
index 2a06520c0c1..48611bb16a3 100644
--- a/gcc/cp/call.cc
+++ b/gcc/cp/call.cc
@@ -8360,15 +8360,6 @@ convert_like_internal (conversion *convs, tree expr, 
tree fn, int argnum,
   /*issue_conversion_warnings=*/false,
   /*c_cast_p=*/false, /*nested_p=*/true,
   complain);
- if (convs->kind == ck_ref_bind)
-   expr = convert_to_reference (totype, expr, CONV_IMPLICIT,
-LOOKUP_NORMAL, NULL_TREE,
-complain);
- else
-   expr = cp_convert (totype, expr, complain);
- if (complained)
-   maybe_inform_about_fndecl_for_bogus_argument_init (fn, argnum);
- return expr;
}
  else if (t->kind == ck_user || !t->bad_p)
{
@@ -8376,6 +8367,8 @@ convert_like_internal (conversion *convs, tree expr, tree 
fn, int argnum,
   /*issue_conversion_warnings=*/false,
   /*c_cast_p=*/false, /*nested_p=*/true,
   complain);
+ if (t->bad_p)
+   complained = 1;
  break;
}
  else if (t->kind == ck_ambig)
@@ -8394,10 +8387,15 @@ convert_like_internal (conversion *convs, tree expr, 
tree fn, int argnum,
  "invalid conversion from %qH to %qI",
  TREE_TYPE (expr), totype);
}
+  if (convs->kind == ck_ref_bind)
+   expr = convert_to_reference (totype, expr, CONV_IMPLICIT,
+LOOKUP_NORMAL, NULL_TREE,
+complain);
+  else
+   expr = cp_convert (totype, expr, complain);
   if (complained == 1)
maybe_inform_about_fndecl_for_bogus_argument_init (fn, argnum);
-
-  return cp_convert (totype, expr, complain);
+  return expr;
 }
 
   if (issue_conversion_warnings && (complain & tf_warning))

base-commit: 8d46516a61a83d24ba89086071f65a194d82ce4e
-- 
2.31.1

[Bug tree-optimization/109804] [11/12/13/14 Regression] internal compiler error in gimple-ssa-warn-access.cc

2023-05-10 Thread mpolacek at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109804

--- Comment #3 from Marek Polacek  ---
Started with r11-6507

commit fd64f348a6b40621dc2bcc743f5fdfb31ed0894c
Author: Martin Sebor 
Date:   Wed Jan 6 13:36:18 2021 -0700

PR c++/98305 spurious -Wmismatched-new-delete on template instance

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