[Bug target/106460] internal compiler error: output_operand: invalid expression as operand on -O1

[guojiufu at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Jiu Fu Guo  ---
The ice occur when output rtx "(high:DI (symbol_ref:DI ("var_48")..))) to
constant pool.
This rtx is generated at function "recog_for_combine"(in combine.cc) after
invoking "force_const_mem".

This kind of rtx represents the high part of a symbol_ref/address when passed
as an argument to "cannot_force_const_mem".  Actually, this kind of rtx can not
be put into a constant pool.  
So "cannot_force_const_mem" should return 'true' for them.

[Bug rtl-optimization/106460] New: internal compiler error: output_operand: invalid expression as operand on -O1

[guojiufu at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 106460
   Summary: internal compiler error: output_operand: invalid
expression as operand on -O1
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: guojiufu at gcc dot gnu.org
  Target Milestone: ---

For code:

extern short var_48;
void
foo (double *r)
{
  if (var_48)
*r = 1234.5678;
}

On gcc trunk, using the below command, an ICE is raised:
> gcc -mcpu=power10 -O1 t.c

t.c:22:1: internal compiler error: output_operand: invalid expression as
operand
   22 | }
  | ^
0x10bdb24b output_operand_lossage(char const*, ...)
/home/guojiufu/gcc/gcc-mainline-base/gcc/final.cc:3234
0x10bdd2b7 output_addr_const(_IO_FILE*, rtx_def*)
/home/guojiufu/gcc/gcc-mainline-base/gcc/final.cc:3831
0x11a64e57 assemble_integer_with_op(char const*, rtx_def*)
/home/guojiufu/gcc/gcc-mainline-base/gcc/varasm.cc:2866
0x11a64f67 default_assemble_integer(rtx_def*, unsigned int, int)
/home/guojiufu/gcc/gcc-mainline-base/gcc/varasm.cc:2882
0x11b0343f rs6000_assemble_integer
/home/guojiufu/gcc/gcc-mainline-base/gcc/config/rs6000/rs6000.cc:14420
0x11a65063 assemble_integer(rtx_def*, unsigned int, unsigned int, int)
/home/guojiufu/gcc/gcc-mainline-base/gcc/varasm.cc:2898
0x11a6b727 output_constant_pool_2
/home/guojiufu/gcc/gcc-mainline-base/gcc/varasm.cc:4074
0x11a6c20b output_constant_pool_1
/home/guojiufu/gcc/gcc-mainline-base/gcc/varasm.cc:4191
0x11a6cd87 output_constant_pool_contents
/home/guojiufu/gcc/gcc-mainline-base/gcc/varasm.cc:4348
0x11a6d95b output_shared_constant_pool()
/home/guojiufu/gcc/gcc-mainline-base/gcc/varasm.cc:4546
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[PATCH 5/5] Support IEEE 128-bit overload test data built-in functions.

[Michael Meissner via Gcc-patches]

[PATCH 5/5] Support IEEE 128-bit overload test data built-in functions.

This patch adds support for overloading the IEEE 128-bit test data and
test data negate built-in functions bewteeen KFmode and TFmode arguments.

I have tested these patches on a power10 that is running Fedora 36, which
defaults to using long doubles that are IEEE 128-bit.  I have built two
parallel GCC compilers, one that defaults to using IEEE 128-bit long doubles
and one that defaults to using IBM 128-bit long doubles.

I have compared the test results to the original compiler results, comparing a
modified GCC to the original compiler using an IEEE 128-bit long double
default, and also comparing a modified GCC to the original compiler using an
IBM 128-bit long double default.  In both cases, the results are the same.

I have also compared the compilers with the future patch in progress that does
switch the internal type handling.  Once those patches are installed, the
overload mechanism will insure the correct built-in is used.

Can I install this patch to the trunk, assuming I have installed the first
four patches in the series?

2022-07-27   Michael Meissner  

gcc/

* config/rs6000/rs6000-builtins.def
(__builtin_vsx_scalar_test_data_class_qp_kf): Rename KFmode IEEE
128-bit test data built-in functions to have a KF suffix to allow
overloading.
(__builtin_vsx_scalar_test_neg_qp_kf): Likewise.
(__builtin_vsx_scalar_test_data_class_qp_tf): Add TFmode variants
for IEEE 128-bit insert and extract support.
(__builtin_vsx_scalar_test_neg_qp_tf): Likewise.
* config/rs6000/rs6000-overload.def
(__builtin_vec_scalar_test_data_class): Add TFmode overloads.
(__builtin_vec_scalar_test_neg): Likewise.
(__builtin_vec_scalar_test_neg_qp): Likewise.
(__builtin_vec_scalar_test_data_class_qp): Likewise.

gcc/testsuite/

* gcc.target/powerpc/bfp/scalar-test-data-class-11.c:  Update the
expected error message.
* gcc.target/powerpc/bfp/scalar-test-neg-5.c: Likewise.
---
 gcc/config/rs6000/rs6000-builtins.def  | 17 -
 gcc/config/rs6000/rs6000-overload.def  | 18 +-
 .../powerpc/bfp/scalar-test-data-class-11.c|  2 +-
 .../gcc.target/powerpc/bfp/scalar-test-neg-5.c |  2 +-
 4 files changed, 27 insertions(+), 12 deletions(-)

diff --git a/gcc/config/rs6000/rs6000-builtins.def 
b/gcc/config/rs6000/rs6000-builtins.def
index 2ac66b39975..e12efc95965 100644
--- a/gcc/config/rs6000/rs6000-builtins.def
+++ b/gcc/config/rs6000/rs6000-builtins.def
@@ -2918,12 +2918,12 @@
 unsigned long long);
 VSIEQPF_KF xsiexpqpf_kf {}
 
-  const signed int __builtin_vsx_scalar_test_data_class_qp (_Float128, \
-const int<7>);
-VSTDCQP xststdcqp_kf {}
+  const signed int __builtin_vsx_scalar_test_data_class_qp_kf (_Float128, \
+  const int<7>);
+VSTDCQP_KF xststdcqp_kf {}
 
-  const signed int __builtin_vsx_scalar_test_neg_qp (_Float128);
-VSTDCNQP xststdcnegqp_kf {}
+  const signed int __builtin_vsx_scalar_test_neg_qp_kf (_Float128);
+VSTDCNQP_KF xststdcnegqp_kf {}
 
 
 ; Builtins requiring hardware support for IEEE-128 floating-point.  Long double
@@ -2980,6 +2980,13 @@
   unsigned long long);
 VSIEQPF_TF xsiexpqpf_tf {ieeeld}
 
+  const signed int __builtin_vsx_scalar_test_data_class_qp_tf (_Float128, \
+  const int<7>);
+VSTDCQP_TF xststdcqp_tf {ieeeld}
+
+  const signed int __builtin_vsx_scalar_test_neg_qp_tf (_Float128);
+VSTDCNQP_TF xststdcnegqp_tf {ieeeld}
+
 
 ; Decimal floating-point builtins.
 [dfp]
diff --git a/gcc/config/rs6000/rs6000-overload.def 
b/gcc/config/rs6000/rs6000-overload.def
index 546883ece19..572e3510360 100644
--- a/gcc/config/rs6000/rs6000-overload.def
+++ b/gcc/config/rs6000/rs6000-overload.def
@@ -4536,7 +4536,9 @@
   unsigned int __builtin_vec_scalar_test_data_class (double, const int);
 VSTDCDP
   unsigned int __builtin_vec_scalar_test_data_class (_Float128, const int);
-VSTDCQP
+VSTDCQP_KF
+  unsigned int __builtin_vec_scalar_test_data_class (long double, const int);
+VSTDCQP_TF
 
 [VEC_VSTDCN, scalar_test_neg, __builtin_vec_scalar_test_neg]
   unsigned int __builtin_vec_scalar_test_neg (float);
@@ -4544,7 +4546,9 @@
   unsigned int __builtin_vec_scalar_test_neg (double);
 VSTDCNDP
   unsigned int __builtin_vec_scalar_test_neg (_Float128);
-VSTDCNQP
+VSTDCNQP_KF
+  unsigned int __builtin_vec_scalar_test_neg (long double);
+VSTDCNQP_TF
 
 [VEC_VTDC, vec_test_data_class, __builtin_vec_test_data_class]
   vbi __builtin_vec_test_data_class (vf, const int);
@@ -5928,9 +5932,11 @@
   unsigned int 

[PATCH 4/5] Support IEEE 128-bit overload extract and insert built-in functions.

[Michael Meissner via Gcc-patches]

[PATCH 4/5] Support IEEE 128-bit overload extract and insert built-in functions.

This patch adds support for overloading the IEEE 128-bit extract and
insert built-in functions bewteeen KFmode and TFmode arguments.

I have tested these patches on a power10 that is running Fedora 36, which
defaults to using long doubles that are IEEE 128-bit.  I have built two
parallel GCC compilers, one that defaults to using IEEE 128-bit long doubles
and one that defaults to using IBM 128-bit long doubles.

I have compared the test results to the original compiler results, comparing a
modified GCC to the original compiler using an IEEE 128-bit long double
default, and also comparing a modified GCC to the original compiler using an
IBM 128-bit long double default.  In both cases, the results are the same.

I have also compared the compilers with the future patch in progress that does
switch the internal type handling.  Once those patches are installed, the
overload mechanism will insure the correct built-in is used.

Can I install this patch to the trunk, assuming I have installed the first
three patches in the series?

2022-07-27   Michael Meissner  

gcc/

* config/rs6000/rs6000-builtins.def
(__builtin_vsx_scalar_extract_expq_kf): Rename KFmode IEEE 128-bit
insert and extract built-in functions to have a KF suffix to allow
overloading.
(__builtin_vsx_scalar_extract_sigq_kf): Likewise.
(__builtin_vsx_scalar_insert_exp_qp_kf): Likewise.
(__builtin_vsx_scalar_extract_expq_tf): Add TFmode variants for
IEEE 128-bit insert and extract support.
(__builtin_vsx_scalar_extract_sigq_tf): Likewise.
(__builtin_vsx_scalar_insert_exp_qp_tf): Likewise.
* config/rs6000/rs6000-c.cc (altivec_resolve_overloaded_builtin):
Add support for having KFmode and TFmode variants of VSIEQPF.
* config/rs6000/rs6000-overload.def
(__builtin_vec_scalar_extract_exp): Add TFmode overloads.
(__builtin_vec_scalar_extract_sig): Likewise.
(__builtin_vec_scalar_insert_exp): Likewise.

gcc/testsuite/

* gcc.target/powerpc/bfp/scalar-extract-exp-4.c:  Update the
expected error message.
* gcc.target/powerpc/bfp/scalar-extract-sig-4.c: Likewise.
* gcc.target/powerpc/bfp/scalar-insert-exp-10.c: Likewise.
---
 gcc/config/rs6000/rs6000-builtins.def | 26 ++-
 gcc/config/rs6000/rs6000-c.cc | 10 ---
 gcc/config/rs6000/rs6000-overload.def | 12 ++---
 .../powerpc/bfp/scalar-extract-exp-4.c|  2 +-
 .../powerpc/bfp/scalar-extract-sig-4.c|  2 +-
 .../powerpc/bfp/scalar-insert-exp-10.c|  2 +-
 6 files changed, 37 insertions(+), 17 deletions(-)

diff --git a/gcc/config/rs6000/rs6000-builtins.def 
b/gcc/config/rs6000/rs6000-builtins.def
index 23fc4a5f108..2ac66b39975 100644
--- a/gcc/config/rs6000/rs6000-builtins.def
+++ b/gcc/config/rs6000/rs6000-builtins.def
@@ -2902,19 +2902,21 @@
   fpmath double __builtin_truncf128_round_to_odd_kf (_Float128);
 TRUNCF128_ODD_KF trunckfdf2_odd {}
 
-  const signed long long __builtin_vsx_scalar_extract_expq (_Float128);
-VSEEQP xsxexpqp_kf {}
+  const signed long long __builtin_vsx_scalar_extract_expq_kf (_Float128);
+VSEEQP_KF xsxexpqp_kf {}
 
-  const signed __int128 __builtin_vsx_scalar_extract_sigq (_Float128);
-VSESQP xsxsigqp_kf {}
+  const signed __int128 __builtin_vsx_scalar_extract_sigq_kf (_Float128);
+VSESQP_KF xsxsigqp_kf {}
 
+; Note we cannot overload this function since it does not have KFmode
+; or TFmode arguments.
   const _Float128 __builtin_vsx_scalar_insert_exp_q (unsigned __int128, \
  unsigned long long);
 VSIEQP xsiexpqp_kf {}
 
-  const _Float128 __builtin_vsx_scalar_insert_exp_qp (_Float128, \
-  unsigned long long);
-VSIEQPF xsiexpqpf_kf {}
+  const _Float128 __builtin_vsx_scalar_insert_exp_qp_kf (_Float128, \
+unsigned long long);
+VSIEQPF_KF xsiexpqpf_kf {}
 
   const signed int __builtin_vsx_scalar_test_data_class_qp (_Float128, \
 const int<7>);
@@ -2968,6 +2970,16 @@
   fpmath double __builtin_truncf128_round_to_odd_tf (long double);
 TRUNCF128_ODD_TF trunctfdf2_odd {ieeeld}
 
+  const signed long long __builtin_vsx_scalar_extract_expq_tf (long double);
+VSEEQP_TF xsxexpqp_tf {ieeeld}
+
+  const signed __int128 __builtin_vsx_scalar_extract_sigq_tf (long double);
+VSESQP_TF xsxsigqp_tf {ieeeld}
+
+  const long double __builtin_vsx_scalar_insert_exp_qp_tf (long double,
\
+  unsigned long long);
+VSIEQPF_TF xsiexpqpf_tf {ieeeld}
+
 
 ; Decimal floating-point builtins.
 [dfp]
diff --git a/gcc/config/rs6000/rs6000-c.cc 

[PATCH 3/5] Support IEEE 128-bit overload comparison built-in functions.

[Michael Meissner via Gcc-patches]

PATCH 3/5] Support IEEE 128-bit overload comparison built-in functions.

This patch adds support for overloading the IEEE 128-bit comparison
built-in functions bewteeen KFmode and TFmode arguments.

I have tested these patches on a power10 that is running Fedora 36, which
defaults to using long doubles that are IEEE 128-bit.  I have built two
parallel GCC compilers, one that defaults to using IEEE 128-bit long doubles
and one that defaults to using IBM 128-bit long doubles.

I have compared the test results to the original compiler results, comparing a
modified GCC to the original compiler using an IEEE 128-bit long double
default, and also comparing a modified GCC to the original compiler using an
IBM 128-bit long double default.  In both cases, the results are the same.

I have also compared the compilers with the future patch in progress that does
switch the internal type handling.  Once those patches are installed, the
overload mechanism will insure the correct built-in is used.

Can I install this patch to the trunk, assuming I have installed the first two
patches in the series?

2022-07-27   Michael Meissner  

gcc/

* config/rs6000/rs6000-builtins.def
(__builtin_vsx_scalar_cmp_exp_qp_eq_kf): Rename KFmode comparison
built-in functions to have a KF suffix to allow overloading.
(__builtin_vsx_scalar_cmp_exp_qp_gt_kf): Likewise.
(__builtin_vsx_scalar_cmp_exp_qp_lt_kf): Likewise.
(__builtin_vsx_scalar_cmp_exp_qp_unordered_kf): Likewise.
(__builtin_vsx_scalar_cmp_exp_qp_eq_tf): Add TFmode comparison
built-in functions.
(__builtin_vsx_scalar_cmp_exp_qp_gt_tf): Likewise.
(__builtin_vsx_scalar_cmp_exp_qp_lt_tf): Likewise.
(__builtin_vsx_scalar_cmp_exp_qp_unordered_tf): Likewise.
* config/rs6000/rs6000-overload.def
(__builtin_vec_scalar_cmp_exp_eq): Add TFmode overloaded
functions.
(__builtin_vec_scalar_cmp_exp_gt): Likewise.
(__builtin_vec_scalar_cmp_exp_lt): Likewise.
(__builtin_vec_scalar_cmp_exp_unordered): Likewise.
---
 gcc/config/rs6000/rs6000-builtins.def | 32 ---
 gcc/config/rs6000/rs6000-overload.def | 16 ++
 2 files changed, 36 insertions(+), 12 deletions(-)

diff --git a/gcc/config/rs6000/rs6000-builtins.def 
b/gcc/config/rs6000/rs6000-builtins.def
index d72ff8cb7fe..23fc4a5f108 100644
--- a/gcc/config/rs6000/rs6000-builtins.def
+++ b/gcc/config/rs6000/rs6000-builtins.def
@@ -2880,18 +2880,18 @@
   fpmath _Float128 __builtin_mulf128_round_to_odd_kf (_Float128, _Float128);
 MULF128_ODD_KF mulkf3_odd {}
 
-  const signed int __builtin_vsx_scalar_cmp_exp_qp_eq (_Float128, _Float128);
-VSCEQPEQ xscmpexpqp_eq_kf {}
+  const signed int __builtin_vsx_scalar_cmp_exp_qp_eq_kf (_Float128, 
_Float128);
+VSCEQPEQ_KF xscmpexpqp_eq_kf {}
 
-  const signed int __builtin_vsx_scalar_cmp_exp_qp_gt (_Float128, _Float128);
-VSCEQPGT xscmpexpqp_gt_kf {}
+  const signed int __builtin_vsx_scalar_cmp_exp_qp_gt_kf (_Float128, 
_Float128);
+VSCEQPGT_KF xscmpexpqp_gt_kf {}
 
-  const signed int __builtin_vsx_scalar_cmp_exp_qp_lt (_Float128, _Float128);
-VSCEQPLT xscmpexpqp_lt_kf {}
+  const signed int __builtin_vsx_scalar_cmp_exp_qp_lt_kf (_Float128, 
_Float128);
+VSCEQPLT_KF xscmpexpqp_lt_kf {}
 
   const signed int \
-  __builtin_vsx_scalar_cmp_exp_qp_unordered (_Float128, _Float128);
-VSCEQPUO xscmpexpqp_unordered_kf {}
+  __builtin_vsx_scalar_cmp_exp_qp_unordered_kf (_Float128, _Float128);
+VSCEQPUO_KF xscmpexpqp_unordered_kf {}
 
   fpmath _Float128 __builtin_sqrtf128_round_to_odd_kf (_Float128);
 SQRTF128_ODD_KF sqrtkf2_odd {}
@@ -2942,6 +2942,22 @@
long double);
 MULF128_ODD_TF multf3_odd {ieeeld}
 
+  const signed int __builtin_vsx_scalar_cmp_exp_qp_eq_tf (long double, \
+ long double);
+VSCEQPEQ_TF xscmpexpqp_eq_tf {ieeeld}
+
+  const signed int __builtin_vsx_scalar_cmp_exp_qp_gt_tf (long double, \
+ long double);
+VSCEQPGT_TF xscmpexpqp_gt_kf {ieeeld}
+
+  const signed int __builtin_vsx_scalar_cmp_exp_qp_lt_tf (long double, \
+ long double);
+VSCEQPLT_TF xscmpexpqp_lt_tf {ieeeld}
+
+  const signed int \
+  __builtin_vsx_scalar_cmp_exp_qp_unordered_tf (long double, long double);
+VSCEQPUO_TF xscmpexpqp_unordered_tf {ieeeld}
+
   fpmath long double __builtin_sqrtf128_round_to_odd_tf (long double);
 SQRTF128_ODD_TF sqrttf2_odd {ieeeld}
 
diff --git a/gcc/config/rs6000/rs6000-overload.def 
b/gcc/config/rs6000/rs6000-overload.def
index f406a16a882..511a3821d5b 100644
--- a/gcc/config/rs6000/rs6000-overload.def
+++ b/gcc/config/rs6000/rs6000-overload.def
@@ -4474,25 +4474,33 @@
   signed int __builtin_vec_scalar_cmp_exp_eq (double, double);
 VSCEDPEQ
 

[PATCH 2/5] Support IEEE 128-bit overload round_to_odd built-in functions.

[Michael Meissner via Gcc-patches]

[PATCH 2/5] Support IEEE 128-bit overload round_to_odd built-in functions.

This patch adds support for overloading the IEEE 128-bit round to odd
built-in functions bewteeen KFmode and TFmode arguments.

I have tested these patches on a power10 that is running Fedora 36, which
defaults to using long doubles that are IEEE 128-bit.  I have built two
parallel GCC compilers, one that defaults to using IEEE 128-bit long doubles
and one that defaults to using IBM 128-bit long doubles.

I have compared the test results to the original compiler results, comparing a
modified GCC to the original compiler using an IEEE 128-bit long double
default, and also comparing a modified GCC to the original compiler using an
IBM 128-bit long double default.  In both cases, the results are the same.

I have also compared the compilers with the future patch in progress that does
switch the internal type handling.  Once those patches are installed, the
overload mechanism will insure the correct built-in is used.

Can I install this patch to the trunk, assuming I have installed the first
patch in the series?

2022-07-27   Michael Meissner  

gcc/

* config/rs6000/rs6000-builtins.def
(__builtin_addf128_round_to_odd_kf): Rename KFmode round to odd
built-in functions with a KF suffix to allow overloading.
(__builtin_divf128_round_to_odd_kf): Likewise.
(__builtin_fmaf128_round_to_odd_kf): Likewise.
(__builtin_mulf128_round_to_odd_kf): Likewise.
(__builtin_sqrtf128_round_to_odd_kf): Likewise.
(__builtin_subf128_round_to_odd_kf): Likewise.
(__builtin_truncf128_round_to_odd_kf): Likewise.
(__builtin_addf128_round_to_odd_tf): Add TFmode round to odd
built-in functions.
(__builtin_fmaf128_round_to_odd_tf): Likewise.
(__builtin_mulf128_round_to_odd_tf): Likewise.
(__builtin_sqrtf128_round_to_odd_tf): Likewise.
(__builtin_subf128_round_to_odd_tf): Likewise.
(__builtin_truncf128_round_to_odd_tf): Likewise.
* config/rs6000/rs6000-overload.def
(__builtin_addf128_round_to_odd): Make IEEE 128-bit round to odd
built-in functions overloaded.
(__builtin_divf128_round_to_odd): Likewise.
(__builtin_fmaf128_round_to_odd): Likewise.
(__builtin_mulf128_round_to_odd): Likewise.
(__builtin_sqrtf128_round_to_odd): Likewise.
(__builtin_subf128_round_to_odd): Likewise.
(__builtin_truncf128_round_to_odd): Likewise.
---
 gcc/config/rs6000/rs6000-builtins.def | 58 ---
 gcc/config/rs6000/rs6000-overload.def | 44 
 2 files changed, 87 insertions(+), 15 deletions(-)

diff --git a/gcc/config/rs6000/rs6000-builtins.def 
b/gcc/config/rs6000/rs6000-builtins.def
index defd7e25ffe..d72ff8cb7fe 100644
--- a/gcc/config/rs6000/rs6000-builtins.def
+++ b/gcc/config/rs6000/rs6000-builtins.def
@@ -2867,18 +2867,18 @@
 
 ; Builtins requiring hardware support for IEEE-128 floating-point.
 [ieee128-hw]
-  fpmath _Float128 __builtin_addf128_round_to_odd (_Float128, _Float128);
-ADDF128_ODD addkf3_odd {}
+  fpmath _Float128 __builtin_addf128_round_to_odd_kf (_Float128, _Float128);
+ADDF128_ODD_KF addkf3_odd {}
 
-  fpmath _Float128 __builtin_divf128_round_to_odd (_Float128, _Float128);
-DIVF128_ODD divkf3_odd {}
+  fpmath _Float128 __builtin_divf128_round_to_odd_kf (_Float128, _Float128);
+DIVF128_ODD_KF divkf3_odd {}
 
-  fpmath _Float128 __builtin_fmaf128_round_to_odd (_Float128, _Float128, \
-   _Float128);
-FMAF128_ODD fmakf4_odd {}
+  fpmath _Float128 __builtin_fmaf128_round_to_odd_kf (_Float128, _Float128, \
+ _Float128);
+FMAF128_ODD_KF fmakf4_odd {}
 
-  fpmath _Float128 __builtin_mulf128_round_to_odd (_Float128, _Float128);
-MULF128_ODD mulkf3_odd {}
+  fpmath _Float128 __builtin_mulf128_round_to_odd_kf (_Float128, _Float128);
+MULF128_ODD_KF mulkf3_odd {}
 
   const signed int __builtin_vsx_scalar_cmp_exp_qp_eq (_Float128, _Float128);
 VSCEQPEQ xscmpexpqp_eq_kf {}
@@ -2893,14 +2893,14 @@
   __builtin_vsx_scalar_cmp_exp_qp_unordered (_Float128, _Float128);
 VSCEQPUO xscmpexpqp_unordered_kf {}
 
-  fpmath _Float128 __builtin_sqrtf128_round_to_odd (_Float128);
-SQRTF128_ODD sqrtkf2_odd {}
+  fpmath _Float128 __builtin_sqrtf128_round_to_odd_kf (_Float128);
+SQRTF128_ODD_KF sqrtkf2_odd {}
 
-  fpmath _Float128 __builtin_subf128_round_to_odd (_Float128, _Float128);
-SUBF128_ODD subkf3_odd {}
+  fpmath _Float128 __builtin_subf128_round_to_odd_kf (_Float128, _Float128);
+SUBF128_ODD_KF subkf3_odd {}
 
-  fpmath double __builtin_truncf128_round_to_odd (_Float128);
-TRUNCF128_ODD trunckfdf2_odd {}
+  fpmath double __builtin_truncf128_round_to_odd_kf (_Float128);
+TRUNCF128_ODD_KF trunckfdf2_odd {}
 
   const signed long long __builtin_vsx_scalar_extract_expq (_Float128);
 

[PATCH 1/5] IEEE 128-bit built-in overload support.

[Michael Meissner via Gcc-patches]

[PATCH 1/5] IEEE 128-bit built-in overload support.

This patch lays the ground work that future patches will use to add
builtin support (both normal and overloaded) for the case where long
double uses the IEEE 128-bit encoding.

This adds a new stanza (ieee128-hw-ld) for when we have IEEE 128-bit
hardware support and long double uses the IEEE 128-bit encoding.

A new type attribute (ieeeld) is added for long double if long double uses
the IEEE 128-bit encoding.

I have tested these patches on a power10 that is running Fedora 36, which
defaults to using long doubles that are IEEE 128-bit.  I have built two
parallel GCC compilers, one that defaults to using IEEE 128-bit long doubles
and one that defaults to using IBM 128-bit long doubles.

I have compared the test results to the original compiler results, comparing a
modified GCC to the original compiler using an IEEE 128-bit long double
default, and also comparing a modified GCC to the original compiler using an
IBM 128-bit long double default.  In both cases, the results are the same.

I have also compared the compilers with the future patch in progress that does
switch the internal type handling.  Once those patches are installed, the
overload mechanism will insure the correct built-in is used.

Can I install this patch to the trunk?

2022-07-27   Michael Meissner  

gcc/

* config/rs6000/rs6000-builtin.cc (rs6000_invalid_builtin): Add
support for ibm128-hw-ld stanza.
(rs6000_builtin_is_supported): Likewise.
(rs6000_init_builtins): Likewise.
(rs6000_expand_builtin): Add support for IEEE128_HW_LD.  Add
support for ieeeld.
* config/rs6000/rs6000-builtins.def (toplevel): Add comment about
the new ieeeld attribute.
* config/rs6000/rs6000-gen-builtins.cc (enum bif_stanza): Add
BSTZ_IEEE128_HW_LD.
(stanza_map): Likewise.
(enable_string): Likewise.
(attrinfo): Add isieeeld.
(parse_bif_attrs): Parse ieeeld.  Add printing ieeeld to the debug
print.
(write_decls): Add support for ibm128-hw-ld stanza and ieeeld
attribute.
(write_bif_static_init): Add support for ieeeld attribute.
---
 gcc/config/rs6000/rs6000-builtin.cc  | 18 ++
 gcc/config/rs6000/rs6000-builtins.def|  1 +
 gcc/config/rs6000/rs6000-gen-builtins.cc | 18 --
 3 files changed, 35 insertions(+), 2 deletions(-)

diff --git a/gcc/config/rs6000/rs6000-builtin.cc 
b/gcc/config/rs6000/rs6000-builtin.cc
index 2819773d9f9..67e86bee781 100644
--- a/gcc/config/rs6000/rs6000-builtin.cc
+++ b/gcc/config/rs6000/rs6000-builtin.cc
@@ -123,6 +123,10 @@ rs6000_invalid_builtin (enum rs6000_gen_builtins fncode)
 case ENB_IEEE128_HW:
   error ("%qs requires quad-precision floating-point arithmetic", name);
   break;
+case ENB_IEEE128_HW_LD:
+  error ("%qs requires %qs to use IEEE quad-precision floating-point "
+"arithmetic", name, "long double");
+  break;
 case ENB_DFP:
   error ("%qs requires the %qs option", name, "-mhard-dfp");
   break;
@@ -189,6 +193,8 @@ rs6000_builtin_is_supported (enum rs6000_gen_builtins 
fncode)
   return TARGET_ALTIVEC && rs6000_cpu == PROCESSOR_CELL;
 case ENB_IEEE128_HW:
   return TARGET_FLOAT128_HW;
+case ENB_IEEE128_HW_LD:
+  return TARGET_FLOAT128_HW && FLOAT128_IEEE_P (TFmode);
 case ENB_DFP:
   return TARGET_DFP;
 case ENB_CRYPTO:
@@ -857,6 +863,9 @@ rs6000_init_builtins (void)
continue;
  if (e == ENB_IEEE128_HW && !TARGET_FLOAT128_HW)
continue;
+ if (e == ENB_IEEE128_HW_LD && (!TARGET_FLOAT128_HW
+|| !FLOAT128_IEEE_P (TFmode)))
+   continue;
  if (e == ENB_DFP && !TARGET_DFP)
continue;
  if (e == ENB_CRYPTO && !TARGET_CRYPTO)
@@ -3387,6 +3396,8 @@ rs6000_expand_builtin (tree exp, rtx target, rtx /* 
subtarget */,
|| (e == ENB_P9_64 && TARGET_MODULO && TARGET_POWERPC64)
|| (e == ENB_P9V && TARGET_P9_VECTOR)
|| (e == ENB_IEEE128_HW && TARGET_FLOAT128_HW)
+   || (e == ENB_IEEE128_HW_LD && TARGET_FLOAT128_HW
+   && FLOAT128_IEEE_P (TFmode))
|| (e == ENB_DFP && TARGET_DFP)
|| (e == ENB_CRYPTO && TARGET_CRYPTO)
|| (e == ENB_HTM && TARGET_HTM)
@@ -3426,6 +3437,13 @@ rs6000_expand_builtin (tree exp, rtx target, rtx /* 
subtarget */,
   return const0_rtx;
 }
 
+  if (bif_is_ieeeld (*bifaddr) && !FLOAT128_IEEE_P (TFmode))
+{
+  error ("%qs requires % to be IEEE 128-bit format",
+bifaddr->bifname);
+  return const0_rtx;
+}
+
   if (bif_is_cpu (*bifaddr))
 return cpu_expand_builtin (fcode, exp, target);
 
diff --git a/gcc/config/rs6000/rs6000-builtins.def 
b/gcc/config/rs6000/rs6000-builtins.def
index f76f54793d7..defd7e25ffe 100644
--- a/gcc/config/rs6000/rs6000-builtins.def
+++ b/gcc/config/rs6000/rs6000-builtins.def
@@ 

[PATCH 0/5] IEEE 128-bit built-in overload support.

[Michael Meissner via Gcc-patches]

The following patches add support for doing built-in function overloading
between the two 128-bit IEEE types (i.e. _Float182/__float128 using KFmode and
when long double uses the IEEE 128-bit encoding with TFmode).

These patches lay the foundation for a set of follow-on patches that will
change the internal handling of 128-bit floating point types in GCC.  In the
future patches, I hope to change the compiler to always use KFmode for the
explicit _Float128/__float128 types, to always use TFmode for the long double
type, no matter which 128-bit floating point type is used, and IFmode for the
explicit __ibm128 type.

But before I can submit those patches to change the internal type structure, I
need to make sure that the built-in functions can handle both sets of types,
and the overload mechanism automatically switches between the two.

There are 5 patches in the series.

The first patch adds the infrastructure to the built-in mechanism to deal with
long doubles that use the IEEE 128-bit encoding.

The second patch adds overload support to the IEEE 128-bit round to odd
built-in functions.

The third patch adds overload support to the IEEE 128-bit comparason built-in
functions.

The fourth patch adds overload support to the IEEE 128-bit scalar extract field
and insert field built-in functions.

The fifth patch adds overload support to the IEEE 128-bit test data and test
data negate built-in functions.

I have tested these patches on a power10 that is running Fedora 36, which
defaults to using long doubles that are IEEE 128-bit.  I have built two
parallel GCC compilers, one that defaults to using IEEE 128-bit long doubles
and one that defaults to using IBM 128-bit long doubles.

I have compared the test results to the original compiler results, comparing a
modified GCC to the original compiler using an IEEE 128-bit long double
default, and also comparing a modified GCC to the original compiler using an
IBM 128-bit long double default.  In both cases, the results are the same.

I have also compared the compilers with the future patch in progress that does
switch the internal type handling.  Once those patches are installed, the
overload mechanism will insure the correct built-in is used.

Can I install these patches to the trunk?

-- 
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com

[PATCH] testsuite: Add extra RISC-V options so that -fprefetch-loop-arrays works

[jiawei]

This patch adds the additional options on RISC-V target.
"-fprefetch-loop-arrays" option needs enable prefetch instruction,
for RISC-V that contained in "zicbop" extension.
Use "-march" with "zicbop" will enable this feature.

gcc/testsuite/ChangeLog:

* gcc.dg/pr106397.c: New dg-additional-options for RISC-V.

---
 gcc/testsuite/gcc.dg/pr106397.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/gcc/testsuite/gcc.dg/pr106397.c b/gcc/testsuite/gcc.dg/pr106397.c
index 2bc17f8cf80..19274fa8771 100644
--- a/gcc/testsuite/gcc.dg/pr106397.c
+++ b/gcc/testsuite/gcc.dg/pr106397.c
@@ -1,6 +1,8 @@
 /* { dg-do compile } */
 /* { dg-options "-O3 -fprefetch-loop-arrays --param l2-cache-size=0 --param 
prefetch-latency=3 -fprefetch-loop-arrays" } */
 /* { dg-additional-options "-march=i686 -msse" { target { { i?86-*-* 
x86_64-*-* } && ia32 } } } */
+/* { dg-additional-options "-march=rv64gc_zicbop" { target { riscv64-*-* } } */
+/* { dg-additional-options "-march=rv32gc_zicbop" { target { riscv32-*-* } } */
 
 int
 bar (void)
-- 
2.25.1

Re: [PATCH][wwwdocs] gcc-13: Add loongarch '-mexplicit-relocs' support

[Lulu Cheng]

在 2022/7/26 下午8:01, Xi Ruoyao 写道:

On Tue, 2022-07-26 at 19:42 +0800, Lulu Cheng wrote:


在 2022/7/26 下午5:44, Xi Ruoyao 写道:

Should we indicate that our .eh_frame section format has changed?

I don't really understand C++ exception handling, so: does the change
breaks something?  For example, if foo links to libbar, libbar is built
with GCC 12 (or vice versa), would an exception thrown from libbar
properly caught by foo?

Generally changes.html is for compiler users (instead of developers),
and I believe at least 90% of users (including I) don't know the
potential consequences from a .eh_frame format change.  So it's better
to describe the breakage and possible workaround here.  If nothing will
be broken, we can just skip the change in changes.html.


The ASM_PREFERRED_EH_DATA_FORMAT macro before and after modification is 
as follows:


 #define ASM_PREFERRED_EH_DATA_FORMAT(CODE, GLOBAL) \

-  (((GLOBAL) ? DW_EH_PE_indirect : 0) | DW_EH_PE_absptr)
+  (((GLOBAL) ? DW_EH_PE_indirect : 0) | DW_EH_PE_pcrel | DW_EH_PE_sdata4)

Use the following tests to describe the effect of modifying this macro 
on the generated assembly code： #include  #include  
using namespace std; int main() { 　　try { 　　throw 1; 　　} 　　catch 
(int i) 　　{ cout << i << endl; 　　} } The main comparisons 
related to the eh_frame section are as follows： 　　 OLD NEW 
.LFB1997 = . | .LFB1780 = . .cfi_startproc | .cfi_startproc 
.cfi_personality 0x80,DW.ref.__gxx_personality_v0 | .cfi_personality 
0x9b,DW.ref.__gxx_personality_v0 .cfi_lsda 0,.LLSDA1997 | .cfi_lsda 
0x1b,.LLSDA1780 If the assembly file generated by the new gcc is 
compiled with the binutils of version 2.38, the following error will be 
reported: test.s:74: Error: invalid or unsupported encoding in 
.cfi_personality test.s:75: Error: invalid or unsupported encoding in 
.cfi_lsda


So I think I should judge whether binutils supports this encoding when 
gcc is configured, and then choose how to define macro 
ASM_PREFERRED_EH_DATA_FORMAT.

[PATCH] c++: Extend -Wpessimizing-move for class prvalues [PR106276]

[Marek Polacek via Gcc-patches]

We already have a warning that warns about pessimizing std::move
in a return statement, when it prevents the NRVO:

  T fn()
  {
T t;
return std::move (t); // warning \o/
  }

However, the warning doesn't warn when what we are returning is a class
prvalue, that is, when std::move prevents the RVO:

  T fn()
  {
T t;
return std::move (T{}); // no warning :-(
  }

This came up recently in GCC:
.

This patch fixes that.  I would like to extend the warning further, so
that it warns in more contexts, e.g.:

  T t = std::move(T());

or

  void foo (T);
  foo (std::move(T()));

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

PR c++/106276

gcc/cp/ChangeLog:

* typeck.cc (can_do_rvo_p): New.
(maybe_warn_pessimizing_move): Warn when moving a temporary object
in a return statement prevents copy elision.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/Wpessimizing-move7.C: New test.
---
 gcc/cp/typeck.cc  | 31 -
 .../g++.dg/cpp0x/Wpessimizing-move7.C | 63 +++
 2 files changed, 91 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/Wpessimizing-move7.C

diff --git a/gcc/cp/typeck.cc b/gcc/cp/typeck.cc
index 6e4f23af982..9500c4e2fe8 100644
--- a/gcc/cp/typeck.cc
+++ b/gcc/cp/typeck.cc
@@ -10287,12 +10287,29 @@ can_do_nrvo_p (tree retval, tree functype)
  /* The cv-unqualified type of the returned value must be the
 same as the cv-unqualified return type of the
 function.  */
- && same_type_p ((TYPE_MAIN_VARIANT (TREE_TYPE (retval))),
- (TYPE_MAIN_VARIANT (functype)))
+ && same_type_p (TYPE_MAIN_VARIANT (TREE_TYPE (retval)),
+ TYPE_MAIN_VARIANT (functype))
  /* And the returned value must be non-volatile.  */
  && !TYPE_VOLATILE (TREE_TYPE (retval)));
 }
 
+/* Like can_do_nrvo_p, but we check if we're trying to move a class
+   prvalue.  */
+
+static bool
+can_do_rvo_p (tree retval, tree functype)
+{
+  if (functype == error_mark_node)
+return false;
+  if (retval)
+STRIP_ANY_LOCATION_WRAPPER (retval);
+  return (retval != NULL_TREE
+ && TREE_CODE (retval) == TARGET_EXPR
+ && same_type_p (TYPE_MAIN_VARIANT (TREE_TYPE (retval)),
+ TYPE_MAIN_VARIANT (functype))
+ && !TYPE_VOLATILE (TREE_TYPE (retval)));
+}
+
 /* If we should treat RETVAL, an expression being returned, as if it were
designated by an rvalue, returns it adjusted accordingly; otherwise, returns
NULL_TREE.  See [class.copy.elision].  RETURN_P is true if this is a return
@@ -10401,12 +10418,20 @@ maybe_warn_pessimizing_move (tree retval, tree 
functype)
  "prevents copy elision"))
inform (loc, "remove % call");
}
+ else if (can_do_rvo_p (arg, functype))
+   {
+ auto_diagnostic_group d;
+ if (warning_at (loc, OPT_Wpessimizing_move,
+ "moving a temporary object in a return statement "
+ "prevents copy elision"))
+   inform (loc, "remove % call");
+   }
  /* Warn if the move is redundant.  It is redundant when we would
 do maybe-rvalue overload resolution even without std::move.  */
  else if (warn_redundant_move
   && (moved = treat_lvalue_as_rvalue_p (arg, /*return*/true)))
{
- /* Make sure that the overload resolution would actually succeed
+ /* Make sure that overload resolution would actually succeed
 if we removed the std::move call.  */
  tree t = convert_for_initialization (NULL_TREE, functype,
   moved,
diff --git a/gcc/testsuite/g++.dg/cpp0x/Wpessimizing-move7.C 
b/gcc/testsuite/g++.dg/cpp0x/Wpessimizing-move7.C
new file mode 100644
index 000..cd4eaa09aae
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/Wpessimizing-move7.C
@@ -0,0 +1,63 @@
+// PR c++/106276
+// { dg-do compile { target c++11 } }
+// { dg-options "-Wpessimizing-move" }
+
+// Define std::move.
+namespace std {
+  template
+struct remove_reference
+{ typedef _Tp   type; };
+
+  template
+struct remove_reference<_Tp&>
+{ typedef _Tp   type; };
+
+  template
+struct remove_reference<_Tp&&>
+{ typedef _Tp   type; };
+
+  template
+constexpr typename std::remove_reference<_Tp>::type&&
+move(_Tp&& __t) noexcept
+{ return static_cast::type&&>(__t); }
+}
+
+struct A { A(); A(const A&) = delete; A(A&&); };
+struct B { B(A); };
+
+static A foo ();
+
+A
+fn1 ()
+{
+  return std::move (A{}); // { dg-warning "moving a temporary object in a 
return statement prevents copy elision" }
+  return std::move (A()); // { dg-warning "moving a temporary object in a 

[Bug target/106459] Compiler crashing for loongarch64-linux-gnu on windows

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Andrew Pinski  ---
It might also be:
#define IMM16_OPERAND(VALUE) \
  ((unsigned HOST_WIDE_INT) (VALUE) + 0x8000 < 0x1)

[Bug target/106459] Compiler crashing for loongarch64-linux-gnu on windows

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Andrew Pinski  ---
I suspect it is this macro which is causing the issue:
/* True if VALUE can be loaded into a register using LU12I.  */

#define LU12I_OPERAND(VALUE) \
  (((VALUE) | ((1UL << 31) - IMM_REACH)) == ((1UL << 31) - IMM_REACH) \
   || ((VALUE) | ((1UL << 31) - IMM_REACH)) + IMM_REACH == 0)

It should either use ULL or use HOST_WIDE_INT_1U instead of 1UL.

[Bug target/106459] Compiler crashing for loongarch64-linux-gnu on windows

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c++ |target

--- Comment #3 from Andrew Pinski  ---
This is most likely a loongarch64 backend issue where it uses long instead of
host wide int for testing the value of a const_int.

Re: [PATCH 2/3] testsuite: Add tests for C2X N2653 char8_t and UTF-8 string literal changes

[Joseph Myers]

On Mon, 25 Jul 2022, Tom Honermann via Gcc-patches wrote:

> This change provides new tests for the core language and compiler
> dependent library changes adopted for C2X via WG14 N2653.

I'd expect this patch also to add tests verifying that u8"" strings have 
the old type for C11 (unless there are existing such tests, but I don't 
see them).

> diff --git a/gcc/testsuite/gcc.dg/atomic/c2x-stdatomic-lockfree-char8_t.c 
> b/gcc/testsuite/gcc.dg/atomic/c2x-stdatomic-lockfree-char8_t.c
> new file mode 100644
> index 000..37ea4c8926c
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/atomic/c2x-stdatomic-lockfree-char8_t.c
> @@ -0,0 +1,42 @@
> +/* Test atomic_is_lock_free for char8_t.  */
> +/* { dg-do run } */
> +/* { dg-options "-std=c2x -D_ISOC2X_SOURCE -pedantic-errors" } */

I don't think _ISOC2X_SOURCE belongs in any GCC tests.

> diff --git a/gcc/testsuite/gcc.dg/atomic/gnu2x-stdatomic-lockfree-char8_t.c 
> b/gcc/testsuite/gcc.dg/atomic/gnu2x-stdatomic-lockfree-char8_t.c
> new file mode 100644
> index 000..a017b134817
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/atomic/gnu2x-stdatomic-lockfree-char8_t.c
> @@ -0,0 +1,5 @@
> +/* Test atomic_is_lock_free for char8_t with -std=gnu2x.  */
> +/* { dg-do run } */
> +/* { dg-options "-std=gnu2x -D_GNU_SOURCE -pedantic-errors" } */

Nor does _GNU_SOURCE (unless the test depends on glibc functionality 
that's only available with _GNU_SOURCE, but in that case you also need 
some effective-target conditionals to restrict it to appropriate glibc 
targets).

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

Re: [PATCH 1/3] C: Implement C2X N2653 char8_t and UTF-8 string literal changes

[Joseph Myers]

On Mon, 25 Jul 2022, Tom Honermann via Gcc-patches wrote:

> diff --git a/gcc/ginclude/stdatomic.h b/gcc/ginclude/stdatomic.h
> index bfcfdf664c7..75ed7965689 100644
> --- a/gcc/ginclude/stdatomic.h
> +++ b/gcc/ginclude/stdatomic.h
> @@ -49,6 +49,10 @@ typedef _Atomic long atomic_long;
>  typedef _Atomic unsigned long atomic_ulong;
>  typedef _Atomic long long atomic_llong;
>  typedef _Atomic unsigned long long atomic_ullong;
> +#if (defined(__CHAR8_TYPE__) \
> + && (defined(_GNU_SOURCE) || defined(_ISOC2X_SOURCE)))
> +typedef _Atomic __CHAR8_TYPE__ atomic_char8_t;
> +#endif
>  typedef _Atomic __CHAR16_TYPE__ atomic_char16_t;
>  typedef _Atomic __CHAR32_TYPE__ atomic_char32_t;
>  typedef _Atomic __WCHAR_TYPE__ atomic_wchar_t;

GCC headers don't test glibc feature test macros such as _GNU_SOURCE and 
_ISOC2X_SOURCE; they base things only on the standard version (whether 
directly, or indirectly as via __CHAR8_TYPE__) and standard-defined 
feature test macros.

(There's one exception in glimits.h - testing __USE_GNU, the macro defined 
internally by glibc's headers - but I don't think that's something we want 
to emulate in new code.)

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

[Bug c++/106459] Compiler crashing for loongarch64-linux-gnu on windows

[unlvsur at live dot com via Gcc-bugs]

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

cqwrteur  changed:

   What|Removed |Added

  Component|other   |c++

--- Comment #2 from cqwrteur  ---
I think it is the bug in the front end for windows that fails to create
temporary files.

[Bug other/106459] Compiler crashing for loongarch64-linux-gnu on windows

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #1 from cqwrteur  ---
It does not crash on linux host but crash on windows host.

[Bug other/106459] New: Compiler crashing for loongarch64-linux-gnu on windows

[unlvsur at live dot com via Gcc-bugs]

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

Bug ID: 106459
   Summary: Compiler crashing for loongarch64-linux-gnu on windows
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

Created attachment 53367
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53367=edit
preprocessor file

D:\hg\fast_io\.sha512>loongarch64-linux-gnu-g++ -S sha512.cc -Ofast -std=c++23
-I../include
In file included from ../include/fast_io_crypto/hash/sha512.h:183,
 from ../include/fast_io_crypto/hash/impl.h:6,
 from ../include/fast_io_crypto.h:25,
 from sha512.cc:1:
../include/fast_io_crypto/hash/sha512_scalar.h: In function 'void
fast_io::details::sha512::sha512_runtime_routine(uint_least64_t*, const
std::byte*, const std::byte*)':
../include/fast_io_crypto/hash/sha512_scalar.h:99:1: error: unrecognizable
insn:
   99 | }
  | ^
(insn 30 29 31 4 (set (reg:DI 1071)
(ior:DI (zero_extend:DI (subreg:SI (reg:DI 1071) 0))
(const_int 2867079648641024 [0xa2f98])))
"../include/fast_io_crypto/hash/sha512.h":90:5 -1
 (nil))
during RTL pass: vregs
../include/fast_io_crypto/hash/sha512_scalar.h:99:1: internal compiler error:
in extract_insn, at recog.cc:2791
libbacktrace could not find executable to open
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.

D:\hg\fast_io\.sha512>loongarch64-linux-gnu-g++ -S sha512.cc -Ofast -std=c++23
-I../include -freport-bug
In file included from ../include/fast_io_crypto/hash/sha512.h:183,
 from ../include/fast_io_crypto/hash/impl.h:6,
 from ../include/fast_io_crypto.h:25,
 from sha512.cc:1:
../include/fast_io_crypto/hash/sha512_scalar.h: In function 'void
fast_io::details::sha512::sha512_runtime_routine(uint_least64_t*, const
std::byte*, const std::byte*)':
../include/fast_io_crypto/hash/sha512_scalar.h:99:1: error: unrecognizable
insn:
   99 | }
  | ^
(insn 30 29 31 4 (set (reg:DI 1071)
(ior:DI (zero_extend:DI (subreg:SI (reg:DI 1071) 0))
(const_int 2867079648641024 [0xa2f98])))
"../include/fast_io_crypto/hash/sha512.h":90:5 -1
 (nil))
during RTL pass: vregs
../include/fast_io_crypto/hash/sha512_scalar.h:99:1: internal compiler error:
in extract_insn, at recog.cc:2791
libbacktrace could not find executable to open
Please submit a full bug report, with preprocessed source.
See  for instructions.
loongarch64-linux-gnu-g++: fatal error: cannot execute
'd:/x86_64-windows-gnu/loongarch64-linux-gnu/bin/../libexec/gcc/loongarch64-linux-gnu/13.0.0/cc1plus.exe':
open temporary output file
compilation terminated.

Re: [PATCH 1/1] c++/106423: Fix pragma suppression of -Wc++20-compat diagnostics.

[Joseph Myers]

On Sun, 24 Jul 2022, Tom Honermann via Gcc-patches wrote:

> Gcc's '#pragma GCC diagnostic' directives are processed in "early mode"
> (see handle_pragma_diagnostic_early) for the C++ frontend and, as such,
> require that the target diagnostic option be enabled for the preprocessor
> (see c_option_is_from_cpp_diagnostics).  This change modifies the
> -Wc++20-compat option definition to register it as a preprocessor option
> so that its associated diagnostics can be suppressed.  The changes also

There are lots of C++ warning options, all of which should support pragma 
suppression regardless of whether they are relevant to the preprocessor or 
not.  Do they all need this kind of handling, or is it only -Wc++20-compat 
that has some kind of problem?

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

[Bug lto/106170] [13 Regression] x86_64-w64-mingw32 host GCC with win32 thread model does not provide pthread.h. lto-plugin fails with canadian compilation

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #17 from cqwrteur  ---
(In reply to Martin Liška from comment #15)
> Feel free to provide Windows implementation of the critical section.

case $target in
  riscv*)
# do not use locking as pthread depends on libatomic
;;
  *-linux*)
use_locking=yes
;;
esac


This should be $host, not $target

case $host in
  riscv*)
# do not use locking as pthread depends on libatomic
;;
  *-linux*)
use_locking=yes
;;
esac

[Bug lto/106170] [13 Regression] x86_64-w64-mingw32 host GCC with win32 thread model does not provide pthread.h. lto-plugin fails with canadian compilation

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #16 from cqwrteur  ---
(In reply to Martin Liška from comment #15)
> Feel free to provide Windows implementation of the critical section.

make[4]: Leaving directory
'/home/cqwrteur/toolchains_build/gcc_build/x86_64-w64-mingw32/loongarch64-linux-gnu/gcc/gmp/doc'
/home/cqwrteur/toolchains/native/x86_64-w64-mingw32/lib/gcc/x86_64-w64-mingw32/13.0.0/../../../../x86_64-w64-mingw32/bin/ld:
cannot find -lpthread: No such file or directory
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:472: liblto_plugin.la] Error 1
make[3]: Leaving directory
'/home/cqwrteur/toolchains_build/gcc_build/x86_64-w64-mingw32/loongarch64-linux-gnu/gcc/lto-plugin'
make[2]: *** [Makefile:383: all] Error 2
make[2]: Leaving directory
'/home/cqwrteur/toolchains_build/gcc_build/x86_64-w64-mingw32/loongarch64-linux-gnu/gcc/lto-plugin'
make[1]: *** [Makefile:12790: all-lto-plugin] Error 2
make[1]: *** Waiting for unfinished jobs

It still has not yet fixed

[Bug analyzer/99860] RFE: analyzer does not respect "restrict"

[dmalcolm at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from David Malcolm  ---
Quoting Paul Eggert here:
  https://lists.gnu.org/archive/html/bug-gnulib/2022-07/msg00066.html

> I looked into this a bit more, and it turns out that GCC was wrong
> about 
> what happens when some parameters have 'restrict' and others do not,
> and 
> this was partly because the C Standard itself is so opaque. (The GCC
> bug 
> has been fixed.)
> 
> In 2018 Troy Johnson and Bill Homer of Cray proposed[1] adding
> examples 
> to the C standard to try to make it clearer what happens when some 
> function parameters are 'restrict' and others are not. These examples
> have been added (with some changes) to section 6.7.3.1 of the current
> (June 2022) draft of the next C standard.[2] Perhaps they will help 
> explain things better.
> 
> The confusion in this obscure area for so many years suggests that 
> Gnulib would be better off following the lead of POSIX and the C 
> standard, by using 'restrict' on all relevant parameters rather than 
> trying to be clever and use 'restrict' with only some parameters. 
> Although omitting some 'restrict's shortens the code, it complicates 
> analysis (for both humans and compilers) so much that it's more
> trouble 
> than its worth.
> 
> [1] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2260.pdf
> [2] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2912.pdf
>

Re: [PATCH] doc: Clarify FENV_ACCESS pragma semantics WRT `-ftrapping-math'

[Joseph Myers]

On Tue, 19 Jul 2022, Maciej W. Rozycki wrote:

> Our documentation indicates that it is the `-frounding-math' invocation 
> option that controls whether we respect what the FENV_ACCESS pragma 
> would imply, should we implement it, regarding the floating point 
> environment.  It is only a part of the picture however, because the 
> `-ftrapping-math' invocation option also affects how we handle said 
> environment.  Clarify that in the description of both options then, as 
> well as the FENV_ACCESS pragma itself.
> 
>   gcc/
>   * doc/implement-c.texi (Floating point implementation): Mention
>   `-fno-trapping-math' in the context of FENV_ACCESS pragma.
>   * doc/invoke.texi (Optimize Options): Clarify FENV_ACCESS pragma
>   implication in the descriptions of `-fno-trapping-math' and 
>   `-frounding-math'.

OK.

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

Re: [GCC13][Patch][V2][1/2]Add a new option -fstrict-flex-array[=n] and attribute strict_flex_array(n) and use it in PR101836

[Kees Cook via Gcc-patches]

On Tue, Jul 19, 2022 at 02:09:46PM +, Qing Zhao wrote:
> [...]
> diff --git a/gcc/c-family/c-attribs.cc b/gcc/c-family/c-attribs.cc
> index c8d96723f4c..10d16532f0d 100644
> --- a/gcc/c-family/c-attribs.cc
> +++ b/gcc/c-family/c-attribs.cc
> @@ -101,6 +101,8 @@ static tree handle_special_var_sec_attribute (tree *, 
> tree, tree, int, bool *);
> static tree handle_aligned_attribute (tree *, tree, tree, int, bool *);
> static tree handle_warn_if_not_aligned_attribute (tree *, tree, tree,
> int, bool *);
> +static tree handle_strict_flex_array_attribute (tree *, tree, tree,
> + int, bool *);

Something mangled these patches -- leading blank characters got dropped?

-- 
Kees Cook

[Bug c++/106430] [modules] ICE on function result of imported type with user-declared constexpr SMF

[johelegp at gmail dot com via Gcc-bugs]

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

Johel Ernesto Guerrero Peña  changed:

   What|Removed |Added

Summary|[modules] ICE on function   |[modules] ICE on function
   |result of imported type |result of imported type
   |with user-declared  |with user-declared
   |constexpr destructor|constexpr SMF

--- Comment #1 from Johel Ernesto Guerrero Peña  ---
See https://godbolt.org/z/T8591z1nT with copy constructor:

`mod.cpp`:
```C++
export module mod;

export struct X {
  bool b = true;
  X() = default;
  constexpr X(const X&) { }
};

export constexpr X id(X x) { return x; }
```

`test.cpp`:
```C++
import mod;
static_assert(id(X{}).b);
int main() { }
```

Output:
```
test.cpp:2:25:   in 'constexpr' expansion of 'id@mod(X@mod)()'
test.cpp:2:25: internal compiler error: in cxx_eval_call_expression, at
cp/constexpr.cc:2850
2 | static_assert(id(X{}).b);
  | ^
0x230869e internal_error(char const*, ...)
???:0
0xa90716 fancy_abort(char const*, int, char const*)
???:0
0xaf60ac maybe_constant_value(tree_node*, tree_node*, bool)
???:0
0xce6baf finish_static_assert(tree_node*, tree_node*, unsigned int, bool, bool)
???:0
0xc66a77 c_parse_file()
???:0
0xda0269 c_common_parse_file()
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
```

[Bug analyzer/105285] False positive with -Wanalyzer-null-dereference in git.git's reftable/reader.c

[dmalcolm at gcc dot gnu.org via Gcc-bugs]

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

David Malcolm  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #14 from David Malcolm  ---
(In reply to David Malcolm from comment #11)
> Should be fixed on trunk for GCC 13 by the above commit.
> 
> I hope to backport this to GCC 12; keeping this open until that's done.

Backported to GCC 12 (for 12.2), so marking this as resolved.

[Bug analyzer/106358] [meta-bug] tracker bug for building the Linux kernel with -fanalyzer

[dmalcolm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106358
Bug 106358 depends on bug 106204, which changed state.

Bug 106204 Summary: False positive from -Wanalyzer-use-of-uninitialized-value 
with -ftrivial-auto-var-init=zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106204

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug analyzer/106204] False positive from -Wanalyzer-use-of-uninitialized-value with -ftrivial-auto-var-init=zero

[dmalcolm at gcc dot gnu.org via Gcc-bugs]

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

David Malcolm  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #6 from David Malcolm  ---
Backported to gcc 12, so marking as resolved.

[Bug analyzer/106358] [meta-bug] tracker bug for building the Linux kernel with -fanalyzer

[dmalcolm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106358
Bug 106358 depends on bug 106225, which changed state.

Bug 106225 Summary: False positives from -Wanalyzer-tainted-divisor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106225

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug analyzer/106225] False positives from -Wanalyzer-tainted-divisor

[dmalcolm at gcc dot gnu.org via Gcc-bugs]

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

David Malcolm  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #5 from David Malcolm  ---
Backported to gcc 12, so marking as resolved.

Backports of various patches to gcc 12 branch (mostly analyzer)

[David Malcolm via Gcc-patches]

I've backported the following patches to the releases/gcc-12 branch:

r12-8631-g1321183a13540b:
  "analyzer: add .fpath.txt dumps to -fdump-analyzer-feasibility"
from r13-6-gd8586b00dd00a1783862da5f0c8811a740400074

r12-8632-g05530fcea07a9e:
  "analyzer: handle repeated accesses after init of unknown size [PR105285]"
 from r13-7-g00c4405cd7f6a144d0a439e4d848d246920e6ff3

r12-8633-g1d38fa564edeae:
  "analyzer: fix memory leaks"
 from r13-334-g99988b0e8b57b3

r12-8634-g6fd39b06042012:
  "json: fix escaping of '\'"
 from r13-965-g4f9ad0b4b0a8c7

r12-8635-g4eac9fa087f4ef:
  "analyzer: add more uninit test coverage"
 from r13-1116-g44681d45473883

r12-8636-g9fa11419ef59fd:
  "analyzer: show saved diagnostics as nodes in .eg.dot dumps"
 from r13-1117-gc540077a3bf600

r12-8637-g09cb9c88ef8e2c:
  "analyzer: fix uninit false positive with -ftrivial-auto-var-init= [PR106204]"
 from r13-1517-gb33dd7874523af

r12-8638-g71a4f739c21874:
  "analyzer: fix false positives from -Wanalyzer-tainted-divisor [PR106225]"
 from r13-1562-g897b3b31f0a94b

r12-8639-g7455e982f09832:
  "analyzer: fix stray get_element decls"
 from r13-1847-g0460ba622e833d


Dave

[Bug analyzer/106225] False positives from -Wanalyzer-tainted-divisor

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-12 branch has been updated by David Malcolm
:

https://gcc.gnu.org/g:71a4f739c218746df70612eeb844024d1fe206bb

commit r12-8638-g71a4f739c218746df70612eeb844024d1fe206bb
Author: David Malcolm 
Date:   Wed Jul 27 17:38:55 2022 -0400

analyzer: fix false positives from -Wanalyzer-tainted-divisor [PR106225]

(cherry picked from r13-1562-g897b3b31f0a94b)

gcc/analyzer/ChangeLog:
PR analyzer/106225
* sm-taint.cc (taint_state_machine::on_stmt): Move handling of
assignments from division to...
(taint_state_machine::check_for_tainted_divisor): ...this new
function.  Reject warning when the divisor is known to be non-zero.
* sm.cc: Include "analyzer/program-state.h".
(sm_context::get_old_region_model): New.
* sm.h (sm_context::get_old_region_model): New decl.

gcc/testsuite/ChangeLog:
PR analyzer/106225
* gcc.dg/analyzer/taint-divisor-1.c: Add test coverage for various
correct and incorrect checks against zero.

Signed-off-by: David Malcolm 

[Bug analyzer/106204] False positive from -Wanalyzer-use-of-uninitialized-value with -ftrivial-auto-var-init=zero

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-12 branch has been updated by David Malcolm
:

https://gcc.gnu.org/g:09cb9c88ef8e2c0c89ada9cde2caf1a960db7a77

commit r12-8637-g09cb9c88ef8e2c0c89ada9cde2caf1a960db7a77
Author: David Malcolm 
Date:   Wed Jul 27 17:38:55 2022 -0400

analyzer: fix uninit false positive with -ftrivial-auto-var-init=
[PR106204]

(cherry picked from r13-1517-gb33dd7874523af)

-fanalyzer handles -ftrivial-auto-var-init= by special-casing
IFN_DEFERRED_INIT to be a no-op, so that e.g.:

  len_2 = .DEFERRED_INIT (4, 2, &"len"[0]);

is treated as a no-op, so that len_2 is still uninitialized after the
stmt.

PR analyzer/106204 reports that -fanalyzer gives false positives from
-Wanalyzer-use-of-uninitialized-value on locals that have their address
taken, due to e.g.:

  _1 = .DEFERRED_INIT (4, 2, &"len"[0]);
  len = _1;

where -fanalyzer leaves _1 uninitialized, and then complains about
the assignment to "len".

Fixed thusly by suppressing the warning when assigning from such SSA
names.

gcc/analyzer/ChangeLog:
PR analyzer/106204
* region-model.cc (within_short_circuited_stmt_p): Move extraction
of assign_stmt to caller.
(due_to_ifn_deferred_init_p): New.
(region_model::check_for_poison): Move extraction of assign_stmt
from within_short_circuited_stmt_p to here.  Share logic with
call to due_to_ifn_deferred_init_p.

gcc/testsuite/ChangeLog:
PR analyzer/106204
* gcc.dg/analyzer/torture/uninit-pr106204.c: New test.
* gcc.dg/analyzer/uninit-pr106204.c: New test.

Signed-off-by: David Malcolm 

[Bug analyzer/105285] False positive with -Wanalyzer-null-dereference in git.git's reftable/reader.c

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #13 from CVS Commits  ---
The releases/gcc-12 branch has been updated by David Malcolm
:

https://gcc.gnu.org/g:05530fcea07a9ee5c7501867f3f11f0fbc504a06

commit r12-8632-g05530fcea07a9ee5c7501867f3f11f0fbc504a06
Author: David Malcolm 
Date:   Wed Jul 27 17:38:53 2022 -0400

analyzer: handle repeated accesses after init of unknown size [PR105285]

(cherry-picked from r13-7-g00c4405cd7f6a144d0a439e4d848d246920e6ff3)

PR analyzer/105285 reports a false positive from
-Wanalyzer-null-dereference on git.git's reftable/reader.c.

A reduced version of the problem can be seen in test_1a of
gcc.dg/analyzer/symbolic-12.c in the following:

void test_1a (void *p, unsigned next_off)
{
  struct st_1 *r = p;

  external_fn();

  if (next_off >= r->size)
return;

  if (next_off >= r->size)
/* We should have already returned if this is the case.  */
__analyzer_dump_path (); /* { dg-bogus "path" } */
}

where the analyzer erroneously considers this path, where
(next_off >= r->size) is both false and then true:

symbolic-12.c: In function âtest_1aâ:
symbolic-12.c:22:5: note: path
   22 | __analyzer_dump_path (); /* { dg-bogus "path" } */
  | ^~~
  âtest_1aâ: events 1-5
|
|   17 |   if (next_off >= r->size)
|  |  ^
|  |  |
|  |  (1) following âfalseâ branch...
|..
|   20 |   if (next_off >= r->size)
|  |  ~~~~
|  |  | |
|  |  | (2) ...to here
|  |  (3) following âtrueâ branch...
|   21 | /* We should have already returned if this is the case. 
*/
|   22 | __analyzer_dump_path (); /* { dg-bogus "path" } */
|  | ~~~
|  | |
|  | (4) ...to here
|  | (5) here
|

The root cause is that, at the call to the external function, the
analyzer considers the cluster for *p to have been touched, binding it
to a conjured_svalue, but because p is void * no particular size is
known for the write, and so the cluster is bound using a symbolic key
covering the base region.  Later, the accesses to r->size are handled by
binding_cluster::get_any_binding, but binding_cluster::get_binding fails
to find a match for the concrete field lookup, due to the key for the
binding being symbolic, and reaching this code:

1522  /* If this cluster has been touched by a symbolic write, then the
content
1523 of any subregion not currently specifically bound is "UNKNOWN". 
*/
1524  if (m_touched)
1525{
1526  region_model_manager *rmm_mgr = mgr->get_svalue_manager ();
1527  return rmm_mgr->get_or_create_unknown_svalue (reg->get_type ());
1528}

Hence each access to r->size is an unknown svalue, and thus the
condition (next_off >= r->size) isn't tracked, leading to the path with
contradictory conditions being treated as satisfiable.

In the original reproducer in git's reftable/reader.c, the call to the
external fn is:
  reftable_record_type(rec)
which is considered to possibly write to *rec, which is *tab, where tab
is the void * argument to reftable_reader_seek_void, and thus after the
call to reftable_record_type some arbitrary amount of *rec could have
been written to.

This patch fixes things by detecting the "this cluster has been 'filled'
with a conjured value of unknown size" case, and handling
get_any_binding on it by returning a sub_svalue of the conjured_svalue,
so that repeated accesses to r->size give the same symbolic value, so
that the constraint manager rejects the bogus execution path, fixing the
false positive.

gcc/analyzer/ChangeLog:
PR analyzer/105285
* store.cc (binding_cluster::get_any_binding): Handle accessing
sub_svalues of clusters where the base region has a symbolic
binding.

gcc/testsuite/ChangeLog:
PR analyzer/105285
* gcc.dg/analyzer/symbolic-12.c: New test.

Signed-off-by: David Malcolm 

[Bug analyzer/105285] False positive with -Wanalyzer-null-dereference in git.git's reftable/reader.c

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #12 from CVS Commits  ---
The releases/gcc-12 branch has been updated by David Malcolm
:

https://gcc.gnu.org/g:1321183a13540b5c3503586b94c758198471c7b3

commit r12-8631-g1321183a13540b5c3503586b94c758198471c7b3
Author: David Malcolm 
Date:   Wed Jul 27 17:38:53 2022 -0400

analyzer: add .fpath.txt dumps to -fdump-analyzer-feasibility

(cherry picked from r13-6-gd8586b00dd00a1783862da5f0c8811a740400074)

I found this extension to -fdump-analyzer-feasibility very helpful when
debugging PR analyzer/105285.

gcc/analyzer/ChangeLog:
* diagnostic-manager.cc (epath_finder::process_worklist_item):
Call dump_feasible_path when a path that reaches the the target
enode is found.
(epath_finder::dump_feasible_path): New.
* engine.cc (feasibility_state::dump_to_pp): New.
* exploded-graph.h (feasibility_state::dump_to_pp): New decl.
* feasible-graph.cc (feasible_graph::dump_feasible_path): New.
* feasible-graph.h (feasible_graph::dump_feasible_path): New
decls.
* program-point.cc (function_point::print): Fix missing trailing
newlines.
* program-point.h (program_point::print_source_line): Remove
unimplemented decl.

gcc/ChangeLog:
* doc/invoke.texi (-fdump-analyzer-feasibility): Mention the
fpath.txt output.

Signed-off-by: David Malcolm 

[Bug c++/105842] rejects-valid: static member function overload set constrained by concepts for class template results in ambiguous call

[joeloser at fastmail dot com via Gcc-bugs]

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

--- Comment #6 from Joe Loser  ---
(In reply to Patrick Palka from comment #5)
> Fixed for GCC 12.2/13

Thanks for the fix, Patrick!

Re: [PATCH] Some additional zero-extension related optimizations in simplify-rtx.

[Segher Boessenkool]

Hi!

On Wed, Jul 27, 2022 at 02:42:25PM +0100, Roger Sayle wrote:
> This patch implements some additional zero-extension and sign-extension
> related optimizations in simplify-rtx.cc.  The original motivation comes
> from PR rtl-optimization/71775, where in comment #2 Andrew Pinski sees:
> 
> Failed to match this instruction:
> (set (reg:DI 88 [ _1 ])
> (sign_extend:DI (subreg:SI (ctz:DI (reg/v:DI 86 [ x ])) 0)))
> 
> On many platforms the result of DImode CTZ is constrained to be a
> small unsigned integer (between 0 and 64), hence the truncation to
> 32-bits (using a SUBREG) and the following sign extension back to
> 64-bits are effectively a no-op, so the above should ideally (often)
> be simplified to "(set (reg:DI 88) (ctz:DI (reg/v:DI 86 [ x ]))".

And you can also do that if ctz is undefined for a zero argument!

> To implement this, and some closely related transformations, we build
> upon the existing val_signbit_known_clear_p predicate.  In the first
> chunk, nonzero_bits knows that FFS and ABS can't leave the sign-bit
> bit set,

Is that guaranteed in all cases?  Also at -O0, also for args bigger than
64 bits?

> Unfortunately, for PR rtl-optimization/71775, ctz:DI on x86_64 with
> default architecture options is undefined at zero, so we can't be sure
> the upper bits of reg:DI 88 will be sign extended (all zeros or all ones).
> nonzero_bits knows this, so the above transformations don't trigger,
> but the transformations themselves are perfectly valid for other
> operations such as FFS, POPCOUNT and PARITY, and on other targets/-march
> settings where CTZ is defined at zero.

It is valid to do whatever you want if the result of CTZ or CLZ is
undefined, so the sign_extend of c[lt]z is a nop.

However if C[LT]Z_DEFINED_VALUE_AT_ZERO is non-zero you have to check
if the returned value (the macro's second arg) survives sign-extending.

>/* If operand is something known to be positive, ignore the ABS.  */
> -  if (GET_CODE (op) == FFS || GET_CODE (op) == ABS
> -   || val_signbit_known_clear_p (GET_MODE (op),
> - nonzero_bits (op, GET_MODE (op
> +  if (val_signbit_known_clear_p (GET_MODE (op),
> +  nonzero_bits (op, GET_MODE (op
>   return op;

I don't think val_signbit_known_clear_p is true in all cases, as I said
above, but we do not care about generated code quality for these cases.
OK.

> +  /* We can canonicalize SIGN_EXTEND (op) as ZERO_EXTEND (op) when
> + we know the sign bit of OP must be clear.  */
> +  if (val_signbit_known_clear_p (GET_MODE (op),
> +  nonzero_bits (op, GET_MODE (op
> + return simplify_gen_unary (ZERO_EXTEND, mode, op, GET_MODE (op));

OK.

> +  /* (sign_extend:DI (subreg:SI (ctz:DI ...))) is (ctz:DI ...).  */
> +  if (GET_CODE (op) == SUBREG
> +   && subreg_lowpart_p (op)
> +   && GET_MODE (SUBREG_REG (op)) == mode
> +   && is_a  (mode, _mode)
> +   && is_a  (GET_MODE (op), _mode)
> +   && GET_MODE_PRECISION (int_mode) <= HOST_BITS_PER_WIDE_INT
> +   && GET_MODE_PRECISION (op_mode) < GET_MODE_PRECISION (int_mode)
> +   && (nonzero_bits (SUBREG_REG (op), mode)
> +   & ~(GET_MODE_MASK (op_mode)>>1)) == 0)

(spaces around >> please)

Please use val_signbit_known_{set,clear}_p?

> + return SUBREG_REG (op);

Also, this is not correct for C[LT]Z_DEFINED_VALUE_AT_ZERO non-zero if
the value it returns in its second arg does not survive sign extending
unmodified (if it is 0x for an extend from SI to DI for
exxample).

> +  /* (zero_extend:DI (subreg:SI (ctz:DI ...))) is (ctz:DI ...).  */
> +  if (GET_CODE (op) == SUBREG
> +   && subreg_lowpart_p (op)
> +   && GET_MODE (SUBREG_REG (op)) == mode
> +   && is_a  (mode, _mode)
> +   && is_a  (GET_MODE (op), _mode)
> +   && GET_MODE_PRECISION (int_mode) <= HOST_BITS_PER_WIDE_INT
> +   && GET_MODE_PRECISION (op_mode) < GET_MODE_PRECISION (int_mode)
> +   && (nonzero_bits (SUBREG_REG (op), mode)
> +   & ~GET_MODE_MASK (op_mode)) == 0)
> + return SUBREG_REG (op);

This has that same problem.


Segher

[Bug c/106416] -Wint-conversion should be an error, not a pedwarn

[redi at gcc dot gnu.org via Gcc-bugs]

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

Jonathan Wakely  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=91092

--- Comment #2 from Jonathan Wakely  ---
Yes, definitely in the same category.

Re: [PATCH] match.pd: Add new division pattern [PR104992]

[Sam Feifer via Gcc-patches]

> _Complex int are strange beasts, I'd simply avoid the transform for them.
>
>
I added to the match.pd rule to not simplify if the operands are complex.
There is now a test case for complex types to make sure they do not
simplify. I had to move the "dg-do run" test to g++.dg to accommodate the
complex type function that is included (even though there isn't a runtime
test for complex types).

Can you please move the pattern next to the existing div/mod patterns,
> like after the related
>
>
done :)

/* Simplify (A / B) * B + (A % B) -> A.  */
> (for div (trunc_div ceil_div floor_div round_div)
>  mod (trunc_mod ceil_mod floor_mod round_mod)
>   (simplify
>(plus:c (mult:c (div @0 @1) @1) (mod @0 @1))
>@0))
>
> pattern?
>
> +/* x / y * y == x -> x % y == 0.  */
> +(simplify
> +  (eq (mult (trunc_div @0 @1) @1) @0)
> +  (eq (trunc_mod @0 @1) { build_zero_cst TREE_TYPE(@0); }))
>
> there are parens missing around the TREE_TYPE (@0), how did you test
> the patch?  You probably want :s on the trunc_div and as Andrew said
> :c on the eq and the mult.
>

I made those changes to the rule. The rule worked without the parentheses,
which is probably why I didn't notice they were missing. Attached is an
updated patch file.

Thanks
-Sam


> Richard.
>
> > Thanks
> > -Sam
> >
> >
> > > For vector try (which works for both the C and C++ front-end):
> > > #define vector __attribute__((vector_size(4*sizeof(int)) ))
> > > vector int f(vector int x, vector int y)
> > > {
> > >   return x == x / y * y;
> > > }
> > >
> > > That is for the vector case, == still returns a vector type.
> > >
> > > Thanks,
> > > Andrew Pinski
> > >
> > > >
> > > > Thanks
> > > > -Sam
> > > >
> > > >> Thanks,
> > > >> Andrew Pinski
> > > >>
> > > >> > diff --git a/gcc/testsuite/gcc.dg/pr104992-1.c
> > > b/gcc/testsuite/gcc.dg/pr104992-1.c
> > > >> > new file mode 100644
> > > >> > index 000..a80e5e180ce
> > > >> > --- /dev/null
> > > >> > +++ b/gcc/testsuite/gcc.dg/pr104992-1.c
> > > >> > @@ -0,0 +1,30 @@
> > > >> > +/* PR tree-optimization/104992 */
> > > >> > +/* { dg-do run } */
> > > >> > +/* { dg-options "-O2"} */
> > > >> > +
> > > >> > +#include "pr104992.c"
> > > >> > +
> > > >> > +int main () {
> > > >> > +
> > > >> > +/* Should be true.  */
> > > >> > +if (!foo(6, 3)
> > > >> > +|| !bar(12, 2)
> > > >> > +|| !baz(34, 17)
> > > >> > +|| !qux(50, 10)
> > > >> > +|| !fred(16, 8)
> > > >> > +|| !baz(-9, 3)
> > > >> > +|| !baz(9, -3)
> > > >> > +|| !baz(-9, -3)
> > > >> > +) {
> > > >> > +__builtin_abort();
> > > >> > + }
> > > >> > +
> > > >> > +/* Should be false.  */
> > > >> > +if (foo(5, 30)
> > > >> > +|| bar(72, 27)
> > > >> > +|| baz(42, 15)) {
> > > >> > +__builtin_abort();
> > > >> > +}
> > > >> > +
> > > >> > +return 0;
> > > >> > +}
> > > >> > diff --git a/gcc/testsuite/gcc.dg/pr104992.c
> > > b/gcc/testsuite/gcc.dg/pr104992.c
> > > >> > new file mode 100644
> > > >> > index 000..b4b0ca53118
> > > >> > --- /dev/null
> > > >> > +++ b/gcc/testsuite/gcc.dg/pr104992.c
> > > >> > @@ -0,0 +1,35 @@
> > > >> > +/* PR tree-optimization/104992 */
> > > >> > +/* { dg-do compile } */
> > > >> > +/* { dg-options "-O2 -fdump-tree-optimized" } */
> > > >> > +
> > > >> > +/* Form from PR.  */
> > > >> > +__attribute__((noipa)) unsigned foo(unsigned x, unsigned y)
> > > >> > +{
> > > >> > +return x / y * y == x;
> > > >> > +}
> > > >> > +
> > > >> > +__attribute__((noipa)) unsigned bar(unsigned x, unsigned y) {
> > > >> > +return x == x / y * y;
> > > >> > +}
> > > >> > +
> > > >> > +/* Signed test case.  */
> > > >> > +__attribute__((noipa)) unsigned baz (int x, int y) {
> > > >> > +return x / y * y == x;
> > > >> > +}
> > > >> > +
> > > >> > +/* Changed order.  */
> > > >> > +__attribute__((noipa)) unsigned qux (unsigned x, unsigned y) {
> > > >> > +return y * (x / y) == x;
> > > >> > +}
> > > >> > +
> > > >> > +/* Wrong order.  */
> > > >> > +__attribute__((noipa)) unsigned fred (unsigned x, unsigned y) {
> > > >> > +return y * x / y == x;
> > > >> > +}
> > > >> > +
> > > >> > +/* Wrong pattern.  */
> > > >> > +__attribute__((noipa)) unsigned waldo (unsigned x, unsigned y,
> > > unsigned z) {
> > > >> > +return x / y * z == x;
> > > >> > +}
> > > >> > +
> > > >> > +/* { dg-final {scan-tree-dump-times " % " 4 "optimized" } } */
> > > >> >
> > > >> > base-commit: 633e9920589ddfaf2d6da1c24ce99b18a2638db4
> > > >> > --
> > > >> > 2.31.1
> > > >> >
> > > >>
> > >
> > >
>
>
From bdcfd7b85e95ec9a649c8083c4fbc1bfb88cea88 Mon Sep 17 00:00:00 2001
From: Sam Feifer 
Date: Wed, 27 Jul 2022 15:37:39 -0400
Subject: [PATCH] match.pd: Add new division pattern [PR104992]

This patch fixes a missed optimization in match.pd. It takes the pattern, x / y * y == x, and optimizes it to x % y == 0. This produces fewer instructions. This simplification does not happen for complex 

Re: [PATCH, v2] Fortran: fix invalid rank error in ASSOCIATED when rank is remapped [PR77652]

[Toon Moene]

On 7/27/22 21:45, Harald Anlauf via Fortran wrote:


Hi Mikael,



Am 26.07.22 um 21:25 schrieb Mikael Morin:



Le 25/07/2022 à 22:18, Harald Anlauf a écrit :


I would normally trust NAG more than Intel and Cray. 

… and yourself, it seems.  Too bad.
May I suggest that, if well known Fortran compilers differ in the 
treatment of this case, there might be reason to ask the Fortran 
Standard Committee for an Interpretation of the Standard ?


Kind regards,

--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands

[PATCH, v2] Fortran: fix invalid rank error in ASSOCIATED when rank is remapped [PR77652]

[Harald Anlauf via Gcc-patches]

Hi Mikael,

Am 26.07.22 um 21:25 schrieb Mikael Morin:

Le 25/07/2022 à 22:18, Harald Anlauf a écrit :

I would normally trust NAG more than Intel and Cray.

… and yourself, it seems.  Too bad.


If somebody else convinces me to accept that NAG has it wrong this
time, I would be happy to proceed.

It won’t convince you about NAG, but here are two reasons to proceed:
  - Consensus among the maintainers is sufficient; it’s the case here.
  - If uncertain, let’s be rather too permissive than too strict; it’s
fine as long as the runtime answer is right.


ok, I have thought about your comments in the review process,
and played with the Cray compiler.  Attached is a refined version
of the patch that now rejects in addition these cases for which there
are no possible related pointer assignments with bounds remapping:

  ASSOCIATED (scalar, array) ! impossible, cannot remap bounds
  ASSOCIATED (array, scalar) ! a scalar is not simply contiguous

(Cray would allow those two, but IMHO these should be disallowed).

See attached for version 2 with updated testcase, regtested again.

I think this is what we could both be happy with... ;-)

Thanks,
Harald
From 5432880ff21de862c64d79626aa19c4eda928cd5 Mon Sep 17 00:00:00 2001
From: Harald Anlauf 
Date: Wed, 27 Jul 2022 21:34:22 +0200
Subject: [PATCH] Fortran: fix invalid rank error in ASSOCIATED when rank is
 remapped [PR77652]

gcc/fortran/ChangeLog:

	PR fortran/77652
	* check.cc (gfc_check_associated): Make the rank check of POINTER
	vs. TARGET match the allowed forms of pointer assignment for the
	selected Fortran standard.

gcc/testsuite/ChangeLog:

	PR fortran/77652
	* gfortran.dg/associated_target_9a.f90: New test.
	* gfortran.dg/associated_target_9b.f90: New test.
---
 gcc/fortran/check.cc  | 23 ++--
 .../gfortran.dg/associated_target_9a.f90  | 27 +++
 .../gfortran.dg/associated_target_9b.f90  | 23 
 3 files changed, 71 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/associated_target_9a.f90
 create mode 100644 gcc/testsuite/gfortran.dg/associated_target_9b.f90

diff --git a/gcc/fortran/check.cc b/gcc/fortran/check.cc
index 91d87a1b2c1..1da0b3cbe15 100644
--- a/gcc/fortran/check.cc
+++ b/gcc/fortran/check.cc
@@ -1502,8 +1502,27 @@ gfc_check_associated (gfc_expr *pointer, gfc_expr *target)
 t = false;
   /* F2018 C838 explicitly allows an assumed-rank variable as the first
  argument of intrinsic inquiry functions.  */
-  if (pointer->rank != -1 && !rank_check (target, 0, pointer->rank))
-t = false;
+  if (pointer->rank != -1 && pointer->rank != target->rank)
+{
+  if (pointer->rank == 0 || target->rank == 0)
+	{
+	  /* There exists no valid pointer assignment using bounds
+	 remapping for scalar => array or array => scalar. */
+	  if (!rank_check (target, 0, pointer->rank))
+	t = false;
+	}
+  else if (target->rank != 1)
+	{
+	  if (!gfc_notify_std (GFC_STD_F2008, "Rank remapping target is not "
+			   "rank 1 at %L", >where))
+	t = false;
+	}
+  else if ((gfc_option.allow_std & GFC_STD_F2003) == 0)
+	{
+	  if (!rank_check (target, 0, pointer->rank))
+	t = false;
+	}
+}
   if (target->rank > 0 && target->ref)
 {
   for (i = 0; i < target->rank; i++)
diff --git a/gcc/testsuite/gfortran.dg/associated_target_9a.f90 b/gcc/testsuite/gfortran.dg/associated_target_9a.f90
new file mode 100644
index 000..708645d5bcb
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/associated_target_9a.f90
@@ -0,0 +1,27 @@
+! { dg-do run }
+! { dg-options "-std=f2018" }
+! PR fortran/77652 - Invalid rank error in ASSOCIATED when rank is remapped
+! Contributed by Paul Thomas
+
+program p
+  real, dimension(100),  target  :: array
+  real, dimension(:,:),  pointer :: matrix
+  real, dimension(20,5), target  :: array2
+  real, dimension(:),pointer :: matrix2
+  matrix(1:20,1:5) => array
+  matrix2(1:100)   => array2
+  !
+  ! F2018:16.9.16, ASSOCIATED (POINTER [, TARGET])
+  ! Case(v): If TARGET is present and is an array target, the result is
+  ! true if and only if POINTER is associated with a target that has
+  ! the same shape as TARGET, ...
+  if (associated (matrix, array )) stop 1
+  if (associated (matrix2,array2)) stop 2
+  call check (matrix2, array2)
+contains
+  subroutine check (ptr, tgt)
+real, pointer :: ptr(..)
+real, target  :: tgt(:,:)
+if (associated (ptr, tgt)) stop 3
+  end subroutine check
+end
diff --git a/gcc/testsuite/gfortran.dg/associated_target_9b.f90 b/gcc/testsuite/gfortran.dg/associated_target_9b.f90
new file mode 100644
index 000..1daa0a7dde1
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/associated_target_9b.f90
@@ -0,0 +1,23 @@
+! { dg-do compile }
+! { dg-options "-std=f2003" }
+! PR fortran/77652 - Invalid rank error in ASSOCIATED when rank is remapped
+! Contributed by Paul Thomas
+
+subroutine s
+  real, dimension(100),  target  :: array
+  real, dimension(:,:), 

[Bug target/106458] [12 Regression] glibc's malloc/tst-scratch_buffer.c test is miscompiled with gcc-12

[danglin at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from John David Anglin  ---
Created attachment 53366
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53366=edit
.s file generated with gcc-12

[Bug target/106458] [12 Regression] glibc's malloc/tst-scratch_buffer.c test is miscompiled with gcc-12

[danglin at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from John David Anglin  ---
Created attachment 53365
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53365=edit
.s file generated with gcc-11

[Bug target/106458] [12 Regression] glibc's malloc/tst-scratch_buffer.c test is miscompiled with gcc-12

[danglin at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from John David Anglin  ---
Created attachment 53364
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53364=edit
.i file

[Bug target/106458] New: [12 Regression] glibc's malloc/tst-scratch_buffer.c test is miscompiled with gcc-12

[danglin at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 106458
   Summary: [12 Regression] glibc's malloc/tst-scratch_buffer.c
test is miscompiled with gcc-12
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 53363
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53363=edit
.c file

dave@atlas:~/gnu/glibc/objdir$ make test t=malloc/tst-scratch_buffer
make -r PARALLELMFLAGS="" -C ../glibc objdir=`pwd` test
make[1]: Entering directory '/home/dave/gnu/glibc/glibc'
make subdir=malloc -C malloc/ ..=../
/home/dave/gnu/glibc/objdir/malloc/tst-scratch_buffer.out
make[2]: Entering directory '/home/dave/gnu/glibc/glibc/malloc'
gcc tst-scratch_buffer.c -c -std=gnu11 -fgnu89-inline  -g -O2 -Wall
-Wwrite-strings -Wundef -Werror -fmerge-all-constants -frounding-math
-fno-stack-protector -fno-common -Wstrict-prototypes -Wold-style-definition
-fmath-errno-fno-pie -I../include
-I/home/dave/gnu/glibc/objdir/malloc  -I/home/dave/gnu/glibc/objdir 
-I../sysdeps/unix/sysv/linux/hppa  -I../sysdeps/hppa/nptl 
-I../sysdeps/unix/sysv/linux/include -I../sysdeps/unix/sysv/linux 
-I../sysdeps/nptl  -I../sysdeps/pthread  -I../sysdeps/gnu 
-I../sysdeps/unix/inet  -I../sysdeps/unix/sysv  -I../sysdeps/unix 
-I../sysdeps/posix  -I../sysdeps/hppa/hppa1.1  -I../sysdeps/wordsize-32 
-I../sysdeps/ieee754/flt-32  -I../sysdeps/ieee754/dbl-64  -I../sysdeps/hppa/fpu
 -I../sysdeps/hppa  -I../sysdeps/ieee754  -I../sysdeps/generic  -I.. -I../libio
-I. -nostdinc -isystem /usr/lib/gcc/hppa-linux-gnu/12/include -isystem
/usr/include -D_LIBC_REENTRANT -include
/home/dave/gnu/glibc/objdir/libc-modules.h -DMODULE_NAME=testsuite_internal
-include ../include/libc-symbols.h   -DTOP_NAMESPACE=glibc -o
/home/dave/gnu/glibc/objdir/malloc/tst-scratch_buffer.o -MD -MP -MF
/home/dave/gnu/glibc/objdir/malloc/tst-scratch_buffer.o.dt -MT
/home/dave/gnu/glibc/objdir/malloc/tst-scratch_buffer.o
gcc -o /home/dave/gnu/glibc/objdir/malloc/tst-scratch_buffer -nostdlib
-nostartfiles -Wl,-z,relro  /home/dave/gnu/glibc/objdir/csu/crt1.o
/home/dave/gnu/glibc/objdir/csu/crti.o `gcc  --print-file-name=crtbegin.o`
/home/dave/gnu/glibc/objdir/malloc/tst-scratch_buffer.o
/home/dave/gnu/glibc/objdir/support/libsupport_nonshared.a 
-Wl,-dynamic-linker=/lib/ld.so.1
-Wl,-rpath-link=/home/dave/gnu/glibc/objdir:/home/dave/gnu/glibc/objdir/math:/home/dave/gnu/glibc/objdir/elf:/home/dave/gnu/glibc/objdir/dlfcn:/home/dave/gnu/glibc/objdir/nss:/home/dave/gnu/glibc/objdir/nis:/home/dave/gnu/glibc/objdir/rt:/home/dave/gnu/glibc/objdir/resolv:/home/dave/gnu/glibc/objdir/mathvec:/home/dave/gnu/glibc/objdir/support:/home/dave/gnu/glibc/objdir/crypt:/home/dave/gnu/glibc/objdir/nptl
-lgcc -Wl,--as-needed -lgcc_s  -Wl,--no-as-needed
/home/dave/gnu/glibc/objdir/libc.so.6
/home/dave/gnu/glibc/objdir/libc_nonshared.a -Wl,--as-needed
/home/dave/gnu/glibc/objdir/elf/ld.so -Wl,--no-as-needed -lgcc -Wl,--as-needed
-lgcc_s  -Wl,--no-as-needed `gcc  --print-file-name=crtend.o`
/home/dave/gnu/glibc/objdir/csu/crtn.o
env GCONV_PATH=/home/dave/gnu/glibc/objdir/iconvdata
LOCPATH=/home/dave/gnu/glibc/objdir/localedata LC_ALL=C  
/home/dave/gnu/glibc/objdir/elf/ld.so.1 --library-path
/home/dave/gnu/glibc/objdir:/home/dave/gnu/glibc/objdir/math:/home/dave/gnu/glibc/objdir/elf:/home/dave/gnu/glibc/objdir/dlfcn:/home/dave/gnu/glibc/objdir/nss:/home/dave/gnu/glibc/objdir/nis:/home/dave/gnu/glibc/objdir/rt:/home/dave/gnu/glibc/objdir/resolv:/home/dave/gnu/glibc/objdir/mathvec:/home/dave/gnu/glibc/objdir/support:/home/dave/gnu/glibc/objdir/crypt:/home/dave/gnu/glibc/objdir/nptl
/home/dave/gnu/glibc/objdir/malloc/tst-scratch_buffer  >
/home/dave/gnu/glibc/objdir/malloc/tst-scratch_buffer.out; \
../scripts/evaluate-test.sh malloc/tst-scratch_buffer $? false false >
/home/dave/gnu/glibc/objdir/malloc/tst-scratch_buffer.test-result
make[2]: Leaving directory '/home/dave/gnu/glibc/glibc/malloc'
FAIL: malloc/tst-scratch_buffer
original exit status 1
tst-scratch_buffer.c:167: error: blob comparison failed
  blob length: 1040 bytes
  left (evaluated from r):
 

[Bug tree-optimization/106457] New: array_at_struct_end_p returns TRUE for a two-dimension array which is not inside any structure

[qinzhao at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 106457
   Summary: array_at_struct_end_p returns TRUE for a two-dimension
array which is not inside any structure
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: qinzhao at gcc dot gnu.org
  Target Milestone: ---

During my work on updating array_at_struct_end_p with the new
-fstrict-flex-array control, I noticed the following issue in the routine
"array_at_struct_end_p" for the following small testing case:
gcc/testsuite/g++.dg/debug/debug5.C

// { dg-do compile }
// { dg-require-effective-target alloca }

int foo()
{
  int a = 1;
  int b = 1;
  int e[a][b];
  e[0][0] = 0;
  return e[a-1][b-1];
}


when compiled with -O1 with the latest trunk gcc, when I used the gdb to debug
it as:

(gdb) break array_at_struct_end_p
Breakpoint 1 at 0x1d4cdf8: file ../../latest_gcc/gcc/tree.cc, line 12690.
(gdb) run
Starting program: /home/opc/Work/GCC/build/gcc/cc1plus -quiet -iprefix
/home/opc/Work/GCC/build/gcc/../lib/gcc/aarch64-unknown-linux-gnu/13.0.0/
-isystem /home/opc/Work/GCC/build/gcc/testsuite/g++/../../include -isystem
/home/opc/Work/GCC/build/gcc/testsuite/g++/../../include-fixed -D_GNU_SOURCE
t.C -quiet -dumpbase debug5.C -dumpbase-ext .C -mlittle-endian -mabi=lp64 -O1
-o debug5.s
...

Breakpoint 1, array_at_struct_end_p (ref=0xf57a2b88) at
../../latest_gcc/gcc/tree.cc:12690
12690 if (TREE_CODE (ref) == ARRAY_REF
...
(gdb) break 12784
Breakpoint 2 at 0x1d4d50c: file ../../latest_gcc/gcc/tree.cc, line 12784.
(gdb) c
Continuing.

Breakpoint 2, array_at_struct_end_p (ref=0xf5771a70) at
../../latest_gcc/gcc/tree.cc:12784
12784 if (TREE_CODE (TYPE_SIZE_UNIT (TREE_TYPE (atype))) != INTEGER_CST
(gdb) n
12786 || TREE_CODE (TYPE_MIN_VALUE (TYPE_DOMAIN (atype))) !=
INTEGER_CST)
(gdb) n
12784 if (TREE_CODE (TYPE_SIZE_UNIT (TREE_TYPE (atype))) != INTEGER_CST
(gdb) n
12787   return true;
(gdb) n
12803   }

it's obvious that the array reference " e[0][0]" is NOT an array at the end of
a structure. 

the utility routine "array_at_struct_end_p" should NOT result true for such
array reference.

We should fix this issue in this routine.

RE: [EXTERNAL] Re: State of AutoFDO in GCC

[Eugene Rozenfeld via Gcc]

Hi Xionghu,

Yes, I'm pretty sure both of the fixes you mentioned are applicable to GCC 10. 
I'm not sure what the bar is for backporting fixes.
Jan, can you comment on that?
The fixes that Xionghu mentioned are:

Fix indirect call inlining with AutoFDO

https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=285aa6895d479bed8e72ad363290846645b6faa0
AutoFDO: Don't try to promote indirect calls that result in recursive 
direct calls

https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=ba125745d9e9fe90a18a2af8701b3269c5fdd468

Thanks,

Eugene

-Original Message-
From: Xionghu Luo  
Sent: Tuesday, July 26, 2022 6:41 PM
To: Eugene Rozenfeld ; Andi Kleen 
; Joseph Myers ; Jan Hubicka 
; gcc 
Subject: [EXTERNAL] Re: State of AutoFDO in GCC

[You don't often get email from yinyuefen...@gmail.com. Learn why this is 
important at https://aka.ms/LearnAboutSenderIdentification ]

On 2022/7/27 09:31, Xionghu Luo wrote:
>
>
> On 2022/7/27 04:12, Eugene Rozenfeld via Gcc wrote:
>> Hello GCC community.
>>
>> I started this thread on the state of AutoFDO in GCC more than a year 
>> ago. Here is the first message in the thread:
>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgcc
>> .gnu.org%2Fpipermail%2Fgcc%2F2021-April%2F235860.htmldata=05%7C0
>> 1%7CEugene.Rozenfeld%40microsoft.com%7Ccda1f6374c584732950e08da6f7126
>> 83%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637944829019804556%7C
>> Unknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1
>> haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=t%2B94vOYKb8SDZ9i86Fnin
>> iYXt7LTGXqbrbftH1TVqEs%3Dreserved=0
>>
>> Since then I committed a number of patches to revive AutoFDO in GCC:
>>
>> Fix a typo in an AutoFDO error
>> string> F%2Fgcc.gnu.org%2Fgit%2F%3Fp%3Dgcc.git%3Ba%3Dcommit%3Bh%3D23691ddd3aa
>> 3ffe55892b2bff54f9a15a89de2b4data=05%7C01%7CEugene.Rozenfeld%40m
>> icrosoft.com%7Ccda1f6374c584732950e08da6f712683%7C72f988bf86f141af91a
>> b2d7cd011db47%7C1%7C0%7C637944829019804556%7CUnknown%7CTWFpbGZsb3d8ey
>> JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C30
>> 00%7C%7C%7Csdata=4WD%2FgKxeXEFz7V6pcqDsYxvAbSOP3ldxXHb%2FoMxV5kc
>> %3Dreserved=0>
>>
>> Update gen_autofdo_event.py and
>> gcc-auto-profile.> =https%3A%2F%2Fgcc.gnu.org%2Fgit%2F%3Fp%3Dgcc.git%3Ba%3Dcommit%3Bh%3D
>> 01d402c5e0ac1ddf5618bbe316b50067625fda46data=05%7C01%7CEugene.Ro
>> zenfeld%40microsoft.com%7Ccda1f6374c584732950e08da6f712683%7C72f988bf
>> 86f141af91ab2d7cd011db47%7C1%7C0%7C637944829019804556%7CUnknown%7CTWF
>> pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
>> Mn0%3D%7C3000%7C%7C%7Csdata=TA%2FhV%2FKsRF3MUZmUL%2FpTWbESdx03VK
>> PIudXrrBjAMvQ%3Dreserved=0>
>>
>> Fixes for AutoFDO
>> tests> %2Fgcc.gnu.org%2Fgit%2F%3Fp%3Dgcc.git%3Ba%3Dcommit%3Bh%3Df9ad3d5339fa
>> aaed6e15a7b27d90fbc66eb72f37data=05%7C01%7CEugene.Rozenfeld%40mi
>> crosoft.com%7Ccda1f6374c584732950e08da6f712683%7C72f988bf86f141af91ab
>> 2d7cd011db47%7C1%7C0%7C637944829019804556%7CUnknown%7CTWFpbGZsb3d8eyJ
>> WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C300
>> 0%7C%7C%7Csdata=AvWCTytUxlcXq%2BpjkWJmhkmV0nH%2Fn0CzC4alU9XA9%2F
>> 4%3Dreserved=0>
>>
>> Fix indir-call-prof-2.c with
>> AutoFDO> 2F%2Fgcc.gnu.org%2Fgit%2F%3Fp%3Dgcc.git%3Ba%3Dcommit%3Bh%3D0ed093c7c3
>> f755bc1cd80e5186abeb2f5c50ee0cdata=05%7C01%7CEugene.Rozenfeld%40
>> microsoft.com%7Ccda1f6374c584732950e08da6f712683%7C72f988bf86f141af91
>> ab2d7cd011db47%7C1%7C0%7C637944829019804556%7CUnknown%7CTWFpbGZsb3d8e
>> yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3
>> 000%7C%7C%7Csdata=3dlTtTfe4XOOm6BEy5YLWG0l3WlQdfbCyFiXs3Q7W1I%3D
>> reserved=0>
>>
>> Fixes for AutoFDO
>> testing> 2F%2Fgcc.gnu.org%2Fgit%2F%3Fp%3Dgcc.git%3Ba%3Dcommit%3Bh%3D9265b37853
>> 1391498ec1727f67a45da72a6c07e9data=05%7C01%7CEugene.Rozenfeld%40
>> microsoft.com%7Ccda1f6374c584732950e08da6f712683%7C72f988bf86f141af91
>> ab2d7cd011db47%7C1%7C0%7C637944829019804556%7CUnknown%7CTWFpbGZsb3d8e
>> yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3
>> 000%7C%7C%7Csdata=ZWSIQ0jb6t2DZQpDb%2F7e5FqKM6KKskM%2FAYzLpxbUkp
>> 4%3Dreserved=0>
>>
>> Fix indirect call inlining with
>> AutoFDO> 2F%2Fgcc.gnu.org%2Fgit%2F%3Fp%3Dgcc.git%3Ba%3Dcommit%3Bh%3D285aa6895d
>> 479bed8e72ad363290846645b6faa0data=05%7C01%7CEugene.Rozenfeld%40
>> microsoft.com%7Ccda1f6374c584732950e08da6f712683%7C72f988bf86f141af91
>> ab2d7cd011db47%7C1%7C0%7C637944829019804556%7CUnknown%7CTWFpbGZsb3d8e
>> yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3
>> 000%7C%7C%7Csdata=W8kTuSjC188BYd3fkZvCK5UxWrYutosB%2FeZnWbmAbPI%

Re: [PATCH] Add new target hook: simplify_modecc_const.

[Segher Boessenkool]

On Wed, Jul 27, 2022 at 08:51:58AM +0100, Roger Sayle wrote:
> > They can be, as clearly documented (and obvious from the code), but you
> can
> > not ever have that in the RTL stream, which is needed for your patch to do
> > anything.
> 
> That's the misunderstanding; neither this nor the previous SUBREG patch,
> affect/change what is in the RTL stream, no COMPARE nodes are every
> changed or modified, only eliminated by the propagation/fusion in combine
> (or CSE).

There are no guarantees at all for that though?

> We have --enable-checking=rtl to guarantee that the documented invariants
> always hold in the RTL stream.

That unfortunately only checks a few structural constraints, and not
even all.  For example not that STRICT_LOW_PART has a SUBREG as
argument, which is documented, and the only thing that makes sense
anyway.  This is PR106101.  Unfortunately many targets violate this.


Segher

Re: [PATCH V2] btf: emit linkage information in BTF_KIND_FUNC entries

[David Faust via Gcc-patches]

On 7/12/22 08:13, Jose E. Marchesi via Gcc-patches wrote:
> 
> The kernel bpftool expects BTF_KIND_FUNC entries in BTF to include an
> annotation reflecting the linkage of functions (static, global).  For
> whatever reason they abuse the `vlen' field of the BTF_KIND_FUNC entry
> instead of adding a variable-part to the record like it is done with
> other entry kinds.
> 
> This patch makes GCC to include this linkage info in BTF_KIND_FUNC
> entries.
> 
> Tested in bpf-unknown-none target.

LGTM
Thanks.

> 
> gcc/ChangeLog:
> 
>   PR debug/106263
>   * ctfc.h (struct ctf_dtdef): Add field linkage.
>   * ctfc.cc (ctf_add_function): Set ctti_linkage.
>   * dwarf2ctf.cc (gen_ctf_function_type): Pass a linkage for
>   function types and subprograms.
>   * btfout.cc (btf_asm_func_type): Emit linkage information for the
>   function.
>   (btf_dtd_emit_preprocess_cb): Propagate the linkage information
>   for functions.
> 
> gcc/testsuite/ChangeLog:
> 
>   PR debug/106263
>   * gcc.dg/debug/btf/btf-function-4.c: New test.
>   * gcc.dg/debug/btf/btf-function-5.c: Likewise.
> ---
>  gcc/btfout.cc   |  6 +-
>  gcc/ctfc.cc |  3 ++-
>  gcc/ctfc.h  |  3 ++-
>  gcc/dwarf2ctf.cc|  4 +++-
>  gcc/testsuite/gcc.dg/debug/btf/btf-function-4.c | 14 ++
>  gcc/testsuite/gcc.dg/debug/btf/btf-function-5.c | 14 ++
>  6 files changed, 40 insertions(+), 4 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.dg/debug/btf/btf-function-4.c
>  create mode 100644 gcc/testsuite/gcc.dg/debug/btf/btf-function-5.c
> 
> diff --git a/gcc/btfout.cc b/gcc/btfout.cc
> index 31af50521da..594cba84910 100644
> --- a/gcc/btfout.cc
> +++ b/gcc/btfout.cc
> @@ -463,6 +463,7 @@ btf_dtd_emit_preprocess_cb (ctf_container_ref ctfc, 
> ctf_dtdef_ref dtd)
>ctf_dtdef_ref func_dtd = ggc_cleared_alloc ();
>func_dtd->dtd_data = dtd->dtd_data;
>func_dtd->dtd_data.ctti_type = dtd->dtd_type;
> +  func_dtd->linkage = dtd->linkage;
>  
>vec_safe_push (funcs, func_dtd);
>num_types_created++;
> @@ -740,7 +741,10 @@ static void
>  btf_asm_func_type (ctf_dtdef_ref dtd)
>  {
>dw2_asm_output_data (4, dtd->dtd_data.ctti_name, "btt_name");
> -  dw2_asm_output_data (4, BTF_TYPE_INFO (BTF_KIND_FUNC, 0, 0), "btt_info");
> +  dw2_asm_output_data (4, BTF_TYPE_INFO (BTF_KIND_FUNC, 0,
> + dtd->linkage),
> +   "btt_info: kind=%u, kflag=%u, linkage=%u",
> +   BTF_KIND_FUNC, 0, dtd->linkage);
>dw2_asm_output_data (4, get_btf_id (dtd->dtd_data.ctti_type), "btt_type");
>  }
>  
> diff --git a/gcc/ctfc.cc b/gcc/ctfc.cc
> index f24e7bff948..9773358a475 100644
> --- a/gcc/ctfc.cc
> +++ b/gcc/ctfc.cc
> @@ -777,7 +777,7 @@ ctf_add_function_arg (ctf_container_ref ctfc, dw_die_ref 
> func,
>  ctf_id_t
>  ctf_add_function (ctf_container_ref ctfc, uint32_t flag, const char * name,
> const ctf_funcinfo_t * ctc, dw_die_ref die,
> -   bool from_global_func)
> +   bool from_global_func, int linkage)
>  {
>ctf_dtdef_ref dtd;
>ctf_id_t type;
> @@ -791,6 +791,7 @@ ctf_add_function (ctf_container_ref ctfc, uint32_t flag, 
> const char * name,
>type = ctf_add_generic (ctfc, flag, name, , die);
>  
>dtd->from_global_func = from_global_func;
> +  dtd->linkage = linkage;
>dtd->dtd_data.ctti_info = CTF_TYPE_INFO (CTF_K_FUNCTION, flag, vlen);
>/* Caller must make sure CTF types for ctc->ctc_return are already added.  
> */
>dtd->dtd_data.ctti_type = (uint32_t) ctc->ctc_return;
> diff --git a/gcc/ctfc.h b/gcc/ctfc.h
> index 001e544ef08..bcf3a43ae1b 100644
> --- a/gcc/ctfc.h
> +++ b/gcc/ctfc.h
> @@ -161,6 +161,7 @@ struct GTY ((for_user)) ctf_dtdef
>ctf_itype_t dtd_data;/* Type node.  */
>bool from_global_func; /* Whether this type was added from a global
>   function.  */
> +  uint32_t linkage;   /* Used in function types.  0=local, 1=global. 
>  */
>union GTY ((desc ("ctf_dtu_d_union_selector (&%1)")))
>{
>  /* struct, union, or enum.  */
> @@ -423,7 +424,7 @@ extern ctf_id_t ctf_add_forward (ctf_container_ref, 
> uint32_t, const char *,
>  extern ctf_id_t ctf_add_typedef (ctf_container_ref, uint32_t, const char *,
>ctf_id_t, dw_die_ref);
>  extern ctf_id_t ctf_add_function (ctf_container_ref, uint32_t, const char *,
> -   const ctf_funcinfo_t *, dw_die_ref, bool);
> +   const ctf_funcinfo_t *, dw_die_ref, bool, 
> int);
>  extern ctf_id_t ctf_add_sou (ctf_container_ref, uint32_t, const char *,
>uint32_t, size_t, dw_die_ref);
>  
> diff --git a/gcc/dwarf2ctf.cc b/gcc/dwarf2ctf.cc
> index a6329ab6ee4..39714c2 100644
> --- 

RE: [EXTERNAL] Re: State of AutoFDO in GCC

[Eugene Rozenfeld via Gcc]

Hi Jan,

Thank you for your reply. I did have you on the TO line in my latest patch:
https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596065.html

That's the patch I need a review on.

I'm looking forward to co-maintaining AutoFDO with you.

Thanks,

Eugene

-Original Message-
From: Jan Hubicka  
Sent: Wednesday, July 27, 2022 12:27 AM
To: David Edelsohn 
Cc: Eugene Rozenfeld ; Martin Liska 
; Xinliang David Li ; gcc 
; Andi Kleen ; Joseph Myers 

Subject: [EXTERNAL] Re: State of AutoFDO in GCC

> On Tue, Jul 26, 2022 at 4:13 PM Eugene Rozenfeld via Gcc 
>  wrote:
> >
> > Hello GCC community.
> >
> > I started this thread on the state of AutoFDO in GCC more than a 
> > year ago. Here is the first message in the thread: 
> > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgc
> > c.gnu.org%2Fpipermail%2Fgcc%2F2021-April%2F235860.htmldata=05%7
> > C01%7CEugene.Rozenfeld%40microsoft.com%7Cfe5184091a18487fd92d08da6fa
> > 1619e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63794503618637077
> > 0%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTi
> > I6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=9%2Bnv2ShWxKh88K%
> > 2BsOeqPgQX3lOCJQ0lnF%2F7SUs4K4uI%3Dreserved=0
> >
> > Since then I committed a number of patches to revive AutoFDO in GCC:
> >
> > Fix a typo in an AutoFDO error 
> > string > 2F%2Fgcc.gnu.org%2Fgit%2F%3Fp%3Dgcc.git%3Ba%3Dcommit%3Bh%3D23691ddd3
> > aa3ffe55892b2bff54f9a15a89de2b4data=05%7C01%7CEugene.Rozenfeld%
> > 40microsoft.com%7Cfe5184091a18487fd92d08da6fa1619e%7C72f988bf86f141a
> > f91ab2d7cd011db47%7C1%7C0%7C637945036186370770%7CUnknown%7CTWFpbGZsb
> > 3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
> > D%7C3000%7C%7C%7Csdata=qkecfE9uH5gy91vILQQlCk9RpExqPZxO4q02wiN1
> > EFw%3Dreserved=0> Update gen_autofdo_event.py and 
> > gcc-auto-profile. > l=https%3A%2F%2Fgcc.gnu.org%2Fgit%2F%3Fp%3Dgcc.git%3Ba%3Dcommit%3Bh%
> > 3D01d402c5e0ac1ddf5618bbe316b50067625fda46data=05%7C01%7CEugene
> > .Rozenfeld%40microsoft.com%7Cfe5184091a18487fd92d08da6fa1619e%7C72f9
> > 88bf86f141af91ab2d7cd011db47%7C1%7C0%7C637945036186370770%7CUnknown%
> > 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC
> > JXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=E52qVFlfdfFGnW9yDsBNhh4k2ey8g
> > 3aJEGzH40MuSOc%3Dreserved=0> Fixes for AutoFDO 
> > tests > F%2Fgcc.gnu.org%2Fgit%2F%3Fp%3Dgcc.git%3Ba%3Dcommit%3Bh%3Df9ad3d5339
> > faaaed6e15a7b27d90fbc66eb72f37data=05%7C01%7CEugene.Rozenfeld%4
> > 0microsoft.com%7Cfe5184091a18487fd92d08da6fa1619e%7C72f988bf86f141af
> > 91ab2d7cd011db47%7C1%7C0%7C637945036186370770%7CUnknown%7CTWFpbGZsb3
> > d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
> > %7C3000%7C%7C%7Csdata=XYlFoY3OTTXHp18O1v8BY47A17NyNPXvUWWYsVnbD
> > 0U%3Dreserved=0> Fix indir-call-prof-2.c with 
> > AutoFDO > %2F%2Fgcc.gnu.org%2Fgit%2F%3Fp%3Dgcc.git%3Ba%3Dcommit%3Bh%3D0ed093c7
> > c3f755bc1cd80e5186abeb2f5c50ee0cdata=05%7C01%7CEugene.Rozenfeld
> > %40microsoft.com%7Cfe5184091a18487fd92d08da6fa1619e%7C72f988bf86f141
> > af91ab2d7cd011db47%7C1%7C0%7C637945036186370770%7CUnknown%7CTWFpbGZs
> > b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%
> > 3D%7C3000%7C%7C%7Csdata=sLftY6hjvzSuE9ZgkGmXZLDpRMjlDo%2FEAyDyP
> > CviY5Q%3Dreserved=0> Fixes for AutoFDO 
> > testing > %2F%2Fgcc.gnu.org%2Fgit%2F%3Fp%3Dgcc.git%3Ba%3Dcommit%3Bh%3D9265b378
> > 531391498ec1727f67a45da72a6c07e9data=05%7C01%7CEugene.Rozenfeld
> > %40microsoft.com%7Cfe5184091a18487fd92d08da6fa1619e%7C72f988bf86f141
> > af91ab2d7cd011db47%7C1%7C0%7C637945036186370770%7CUnknown%7CTWFpbGZs
> > b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%
> > 3D%7C3000%7C%7C%7Csdata=lXZ%2F%2FbcfYD%2BQyIiXMAaCxOujEAfDXSY1p
> > 78kUb2md7w%3Dreserved=0> Fix indirect call inlining with 
> > AutoFDO > %2F%2Fgcc.gnu.org%2Fgit%2F%3Fp%3Dgcc.git%3Ba%3Dcommit%3Bh%3D285aa689
> > 5d479bed8e72ad363290846645b6faa0data=05%7C01%7CEugene.Rozenfeld
> > %40microsoft.com%7Cfe5184091a18487fd92d08da6fa1619e%7C72f988bf86f141
> > af91ab2d7cd011db47%7C1%7C0%7C637945036186370770%7CUnknown%7CTWFpbGZs
> > b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%
> > 3D%7C3000%7C%7C%7Csdata=ypoF%2BZnEe3eC3Gat6%2FjUJLV2XiltdjJHe68
> > pue64fSU%3Dreserved=0> Improve AutoFDO count propagation 
> > algorithm > 3A%2F%2Fgcc.gnu.org%2Fgit%2F%3Fp%3Dgcc.git%3Ba%3Dcommit%3Bh%3D3d9e67
> > 67939e9658260e2506e81ec32b37cba041data=05%7C01%7CEugene.Rozenfe
> > ld%40microsoft.com%7Cfe5184091a18487fd92d08da6fa1619e%7C72f988bf86f1
> > 

Merge from trunk to gccgo branch

[Ian Lance Taylor via Gcc-patches]

I merged trunk revision 5eb9f117a361538834b9740d59219911680717d1 to
the gccgo branch.

Ian

[Bug target/106415] loop-ivopts prevents correct usage of dbra with 16-bit loop counters on m68k

[undefinedopcode2 at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Undefined Opcode  ---
(In reply to Kewen Lin from comment #5)
> At the top of tree-ssa-loop-ivopts.cc file, there are some useful comments
> describing the costs for iv candidate itself and group, it may help.
> 
> :
>   cand  cost
>   0 5
>   1 5
>   2 5
>   3 4
>   4 5
>   5 5
>   6 5
>   7 5
>   8 5
> 
> This part is for "variable costs".
> 
> :
> Group 0:
>   candcostcompl.  inv.expr.   inv.vars
>   0   400 0   NIL;NIL;
>   7   0   0   NIL;NIL;
>   8   400 0   NIL;NIL;
> 
> This part is for "group/use costs".
> 
> There would be no dumping for a candidate when it has infinite cost for the
> group, so the above means only candidate 0, 7 and 8 are valid to be used for
> group 0.
> 
> Final cost looks like:
> 
> cost: 7 (complexity 0)
> reg_cost: 2
> cand_cost: 5
> cand_group_cost: 0 (complexity 0)
> candidates: 7
>  group:0 --> iv_cand:7, cost=(0,0)
>  group:1 --> iv_cand:7, cost=(0,0)
> invariant variables:
> invariant expressions:
> 
> 
> 
> By quick checking, it looks the inf cost for the pair (cand 3, group 0) is
> due to:
> 
>   /* Check if we have enough precision to express the values of use.  */
>   if (TYPE_PRECISION (utype) > TYPE_PRECISION (ctype))
> return infinite_cost;

Some debug prints confirm this is indeed what's happening, the pass thinks
candidate 3 is trying to fit a 32-bit value into 16-bits and bails. What's not
clear to me is why. Does it have some notion of -1 requiring 32-bits to store
even though it'll fit just fine in 16 for our purposes?

RE: [EXTERNAL] Re: State of AutoFDO in GCC

[Eugene Rozenfeld via Gcc]

Hi David,

Thank you for your offer to take on the responsibility of maintaining the 
AutoFDO-specific portions of the code. I'll be happy to do that with Jan's and 
other GGC maintainers' help.
I hope more people will start using and contributing to AutoFDO.

Thanks,

Eugene

-Original Message-
From: David Edelsohn  
Sent: Tuesday, July 26, 2022 3:38 PM
To: Eugene Rozenfeld ; Jan Hubicka 
; Martin Liska ; Xinliang David Li 

Cc: Andi Kleen ; Joseph Myers ; 
gcc 
Subject: [EXTERNAL] Re: State of AutoFDO in GCC

[You don't often get email from dje@gmail.com. Learn why this is important 
at https://aka.ms/LearnAboutSenderIdentification ]

On Tue, Jul 26, 2022 at 4:13 PM Eugene Rozenfeld via Gcc  
wrote:
>
> Hello GCC community.
>
> I started this thread on the state of AutoFDO in GCC more than a year 
> ago. Here is the first message in the thread: 
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgcc.
> gnu.org%2Fpipermail%2Fgcc%2F2021-April%2F235860.htmldata=05%7C01%
> 7CEugene.Rozenfeld%40microsoft.com%7Ccabaec504f234632a03a08da6f5780d2%
> 7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637944718882043585%7CUnkn
> own%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi
> LCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=5RoiLypTlkNRIZW8yAufYR4qiO573
> 0PADO%2BFsS6InIU%3Dreserved=0
>
> Since then I committed a number of patches to revive AutoFDO in GCC:
>
> Fix a typo in an AutoFDO error 
> string %2Fgcc.gnu.org%2Fgit%2F%3Fp%3Dgcc.git%3Ba%3Dcommit%3Bh%3D23691ddd3aa3f
> fe55892b2bff54f9a15a89de2b4data=05%7C01%7CEugene.Rozenfeld%40micr
> osoft.com%7Ccabaec504f234632a03a08da6f5780d2%7C72f988bf86f141af91ab2d7
> cd011db47%7C1%7C0%7C637944718882199821%7CUnknown%7CTWFpbGZsb3d8eyJWIjo
> iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%
> 7C%7Csdata=LRgW4qyh%2FAdrlKluUXnaDTFCNW8tnS1WX8bCs1WAT7s%3Dr
> eserved=0> Update gen_autofdo_event.py and 
> gcc-auto-profile. https%3A%2F%2Fgcc.gnu.org%2Fgit%2F%3Fp%3Dgcc.git%3Ba%3Dcommit%3Bh%3D01
> d402c5e0ac1ddf5618bbe316b50067625fda46data=05%7C01%7CEugene.Rozen
> feld%40microsoft.com%7Ccabaec504f234632a03a08da6f5780d2%7C72f988bf86f1
> 41af91ab2d7cd011db47%7C1%7C0%7C637944718882199821%7CUnknown%7CTWFpbGZs
> b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
> %7C3000%7C%7C%7Csdata=oBJvTW6RrkY6uURmr0UK5gaNiVS1b8vFfIyOoqq8AkM
> %3Dreserved=0> Fixes for AutoFDO 
> tests 2Fgcc.gnu.org%2Fgit%2F%3Fp%3Dgcc.git%3Ba%3Dcommit%3Bh%3Df9ad3d5339faaa
> ed6e15a7b27d90fbc66eb72f37data=05%7C01%7CEugene.Rozenfeld%40micro
> soft.com%7Ccabaec504f234632a03a08da6f5780d2%7C72f988bf86f141af91ab2d7c
> d011db47%7C1%7C0%7C637944718882199821%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
> MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7
> C%7Csdata=6evlP10%2BQJyUuVZ3u%2Fv%2FP9nSIsASLjtWETyqeBfnQ2k%3D
> p;reserved=0> Fix indir-call-prof-2.c with 
> AutoFDO F%2Fgcc.gnu.org%2Fgit%2F%3Fp%3Dgcc.git%3Ba%3Dcommit%3Bh%3D0ed093c7c3f7
> 55bc1cd80e5186abeb2f5c50ee0cdata=05%7C01%7CEugene.Rozenfeld%40mic
> rosoft.com%7Ccabaec504f234632a03a08da6f5780d2%7C72f988bf86f141af91ab2d
> 7cd011db47%7C1%7C0%7C637944718882199821%7CUnknown%7CTWFpbGZsb3d8eyJWIj
> oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C
> %7C%7Csdata=mtMd21By6r8DiIIXzk5ePHP0iU%2FHfnDQG8%2FXJbAr5qE%3D
> p;reserved=0> Fixes for AutoFDO 
> testing F%2Fgcc.gnu.org%2Fgit%2F%3Fp%3Dgcc.git%3Ba%3Dcommit%3Bh%3D9265b3785313
> 91498ec1727f67a45da72a6c07e9data=05%7C01%7CEugene.Rozenfeld%40mic
> rosoft.com%7Ccabaec504f234632a03a08da6f5780d2%7C72f988bf86f141af91ab2d
> 7cd011db47%7C1%7C0%7C637944718882199821%7CUnknown%7CTWFpbGZsb3d8eyJWIj
> oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C
> %7C%7Csdata=QnKrxt7W9wfTYY3Drjm%2FSn7D4yHwxjInvI8dj9KEIs4%3D
> reserved=0> Fix indirect call inlining with 
> AutoFDO F%2Fgcc.gnu.org%2Fgit%2F%3Fp%3Dgcc.git%3Ba%3Dcommit%3Bh%3D285aa6895d47
> 9bed8e72ad363290846645b6faa0data=05%7C01%7CEugene.Rozenfeld%40mic
> rosoft.com%7Ccabaec504f234632a03a08da6f5780d2%7C72f988bf86f141af91ab2d
> 7cd011db47%7C1%7C0%7C637944718882199821%7CUnknown%7CTWFpbGZsb3d8eyJWIj
> oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C
> %7C%7Csdata=695ieVftlFRwICzxxMmmIb9%2F%2FDBlYBy9jJn%2ByfzkhP0%3D&
> amp;reserved=0> Improve AutoFDO count propagation 
> algorithm %2F%2Fgcc.gnu.org%2Fgit%2F%3Fp%3Dgcc.git%3Ba%3Dcommit%3Bh%3D3d9e676793
> 9e9658260e2506e81ec32b37cba041data=05%7C01%7CEugene.Rozenfeld%40m
> icrosoft.com%7Ccabaec504f234632a03a08da6f5780d2%7C72f988bf86f141af91ab
> 

[committed] MAINTAINERS: Add myself as CTF and BTF reviewer

[David Faust via Gcc-patches]

ChangeLog:

* MAINTAINERS: Add myself as reviewer for CTF and BTF.
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 7408396471f..1a37f4419b9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -267,6 +267,7 @@ arc portClaudiu Zissulescu  

 callgraph  Martin Liska
 callgraph  Martin Jambor   
 C front endMarek Polacek   
+CTF, BTF   David Faust 
 dataflow   Paolo Bonzini   
 dataflow   Seongbae Park   
 dataflow   Kenneth Zadeck  
@@ -397,7 +398,6 @@ Doug Evans  

 Chris Fairles  
 Alessandro Fanfarillo  
 Changpeng Fang 
-David Faust
 Sam Feifer 
 Li Feng
 Thomas Fitzsimmons 
-- 
2.36.1

[Bug target/100340] Bootstrap fails with Clang 12.0.5 (XCode 12.5)

[iains at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #37 from Iain Sandoe  ---
(In reply to Eric Gallager from comment #36)
> Note that the solution to this has caused downstream MacPorts bug 65236:
> https://trac.macports.org/ticket/65236

the macports ticket does not contain enough information to figure out the
problem ... 

I build and test regularly on Darwin9-21 and have used a range of installed
Xcode CLT:

e.g. here's the latest I have:

gcc/as -arch x86_64 -v -mmacosx-version-min=12.0 -mllvm
-x86-pad-for-align=false -force_cpusubtype_ALL -o /Volumes/ramdisk/ccuqyehz.o
/Volumes/ramdisk/ccN3ilQO.s
Apple clang version 13.1.6 (clang-1316.0.21.2.5)
Target: x86_64-apple-darwin21.6.0
Thread model: posix
InstalledDir: /Users/Shared/XC/13.4/CommandLineTools/usr/bin
 "/Users/Shared/XC/13.4/CommandLineTools/usr/bin/clang" -cc1as -triple
x86_64-apple-macosx12.0.0 -filetype obj -main-file-name ccN3ilQO.s -target-cpu
penryn -fdebug-compilation-dir=/scratch/12-mon/gcc-master -dwarf-debug-producer
"Apple clang version 13.1.6 (clang-1316.0.21.2.5)" -dwarf-version=4
-mrelocation-model pic --mrelax-relocations -mllvm -x86-pad-for-align=false
-mllvm -disable-aligned-alloc-awareness=1 -o /Volumes/ramdisk/ccuqyehz.o
/Volumes/ramdisk/ccN3ilQO.s

works fine (i.e the assembler is accepting the flag) .. so I am not sure where
the problem is arising in the bias stuff.

Perhaps, by some strange mechanism, the cctools assembler is being invoked ?

[Bug analyzer/106298] RFE: analyzer handling of dup, dup2, and dup3

[dmalcolm at gcc dot gnu.org via Gcc-bugs]

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

David Malcolm  changed:

   What|Removed |Added

   Last reconfirmed||2022-07-27
   Assignee|dmalcolm at gcc dot gnu.org|mir at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

--- Comment #2 from David Malcolm  ---
Immad's looking at this one.

Re: [PATCH] preprocessor: Set input_location to the most recently seen token

[Joseph Myers]

On Mon, 11 Jul 2022, Lewis Hyatt via Gcc-patches wrote:

> Hello-
> 
> As discussed here:
> https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598136.html
> 
> Here is another short patch that improves "#pragma GCC diagnostic" handling.
> Longer term, it will be desirable to make the handling of this pragma
> independent of the global input_location. But in the meantime, some glitches
> like this one can be readily addressed by making input_location point to
> something better. In this case, input_location during preprocessing (-E or
> -save-temps) is made to point to the most recently seen token rather than the
> beginning of the file. To the best of my knowledge, nothing else besides
> "#pragma GCC diagnostic" handling can observe input_location during
> token streaming, so this is expected not to have any other
> repercussions. Bootstrap + regtest does look clean on x86-64 Linux.
> 
> By the way, the new testcase fails when compiled with C++, but it's not
> because of pragma handling, it's rather because the C++ frontend changes the
> location on the warning to the wrong place. Once done_lexing has been set to
> true, it changes the location of all warnings to input_location, however
> that's not correct when the location is the cached location of a macro
> definition; the original location is preferable. I will file a separate PR
> about that, and have xfailed that testcase for now, since I am not quite there
> with grokking the reason it behaves this way, and anyway it's not related to
> this 1-line fix for gcc -E.
> 
> Please let me know how it looks? Thanks!

OK.

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

[Bug target/100340] Bootstrap fails with Clang 12.0.5 (XCode 12.5)

[egallager at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #36 from Eric Gallager  ---
Note that the solution to this has caused downstream MacPorts bug 65236:
https://trac.macports.org/ticket/65236

[Bug c++/46476] Missing Warning about unreachable code after return [-Wunreachable-code-return]

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

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

[Bug c/106456] -Wunreachable-code seems very broken

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

-Wunreachable-code was removed a long time ago (over 12 years ago) because of
all of the false positives it was generating.

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

[Bug c/106456] -Wunreachable-code seems very broken

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Andrew Pinski  ---
Wunreachable-code
Common Ignore Warning
Does nothing. Preserved for backward compatibility.

Re: Rust frontend patches v1

[David Malcolm via Gcc-patches]

On Wed, 2022-07-27 at 14:40 +0100, herron.philip--- via Gcc-patches
wrote:
> This is the initial version 1 patch set for the Rust front-end. There
> are more changes that need to be extracted out for all the target
> hooks we have implemented. The goal is to see if we are implementing
> the target hooks information for x86 and arm. We have more patches
> for the other targets I can add in here but they all follow the
> pattern established here.
> 
> Each patch is buildable on its own and rebased ontop of
> 718cf8d0bd32689192200d2156722167fd21a647. As for ensuring we keep
> attribution for all the patches we have received in the front-end
> should we create a CONTRIBUTOR's file inside the front-end folder?
> 
> Note thanks to Thomas Schwinge and Mark Wielaard, we are keeping a
> branch up to date with our code on: 
> https://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/devel/rust/master
>  but this is not rebased ontop of gcc head.
> 
> Let me know if I have sent these patches correctly or not, this is a
> learning experience with git send-email.
> 
> [PATCH Rust front-end v1 1/4] Add skeleton Rust front-end folder
> [PATCH Rust front-end v1 2/4] Add Rust lang TargetHooks for i386 and
> [PATCH Rust front-end v1 3/4] Add Rust target hooks to ARM
> [PATCH Rust front-end v1 4/4] Add Rust front-end and associated

FWIW it looks like patch 4 of the kit didn't make it (I didn't get a
copy and I don't see it in the archives).

Maybe it exceeded a size limit?  If so, maybe try splitting it up into
more patches.

Dave

[Bug c++/106448] [OpenMP] atomic compare – g++ wrongly accepts parenthesized condition

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Jakub Jelinek  ---
(In reply to Jakub Jelinek from comment #1)
> is incorrectly accepted in C and rejected in C++.

I mean is correctly rejected in C++.

[Bug c++/106448] [OpenMP] atomic compare – g++ wrongly accepts parenthesized condition

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Jakub Jelinek  ---
int x;

void
bar (void)
{
  #pragma omp atomic
  x = (x + 6);
  #pragma omp atomic
  x = (x * 6);
}

is incorrectly accepted in C and rejected in C++.

[PING^4] nvptx: Allow '--with-arch' to override the default '-misa' (was: nvptx multilib setup)

[Thomas Schwinge]

Hi Tom!

Ping.


Grüße
 Thomas


On 2022-07-20T14:46:03+0200, I wrote:
> Hi Tom!
>
> Ping.
>
>
> Grüße
>  Thomas
>
>
> On 2022-07-13T10:42:44+0200, I wrote:
>> Hi Tom!
>>
>> Ping.
>>
>>
>> Grüße
>>  Thomas
>>
>>
>> On 2022-07-05T16:59:23+0200, I wrote:
>>> Hi Tom!
>>>
>>> Ping.
>>>
>>>
>>> Grüße
>>>  Thomas
>>>
>>>
>>> On 2022-06-15T23:18:10+0200, I wrote:
 Hi Tom!

 On 2022-05-13T16:20:14+0200, I wrote:
> On 2022-02-04T13:09:29+0100, Tom de Vries via Gcc  
> wrote:
>> On 2/4/22 08:21, Thomas Schwinge wrote:
>>> On 2022-02-03T13:35:55+, "vries at gcc dot gnu.org via Gcc-bugs" 
>>>  wrote:
 I've tested this using (recommended) driver 470.94 on boards:
>
 while iterating over dimensions { -mptx=3.1 , -mptx=6.3 } x { 
 GOMP_NVPTX_JIT=-O0,  }.
>>>
>>> Do you use separate (nvptx-none offload target only?) builds for
>>> different '-mptx' variants (likewise: '-misa'), or have you hacked up 
>>> the
>>> multilib configuration?
>>
>> Neither, I'm using --target_board=unix/foffload= for that.
>
> ACK, I see.  So these flags then only affect GCC/nvptx code generation
> for the actual user code (here: GCC libgomp test cases), but for the
> GCC/nvptx target libraries (such as: libc, libm, libgfortran, libgomp --
> the latter especially relevant for OpenMP), it uses PTX code from one of
> the two "pre-compiled" GCC/nvptx multilibs: default or '-mptx=3.1'.
>
> Meaning, one can't just use such a flag for "completely building code"
> for a specific configuration.  Random example,
> '-foffload-options=nvptx-none=-march=sm_75': as GCC/nvptx target
> libraries aren't being built for '-march=sm_75' multilib,
> '-foffload-options=nvptx-none=-march=sm_75' uses the default multilib,
> which isn't '-march=sm_75'.
>
>
>>   ('gcc/config/nvptx/t-nvptx:MULTILIB_OPTIONS'
>>> etc., I suppose?)  Should we add a few representative configurations to
>>> be built by default?  And/or, should we have a way to 'configure' per
>>> user needs (I suppose: '--with-multilib-list=[...]', as supported for a
>>> few other targets?)?  (I see there's also a new
>>> '--with-multilib-generator=[...]', haven't looked in detail.)  No matter
>>> which way: again, combinatorial explosion is a problem, of course...
>>
>> As far as I know, the gcc build doesn't finish when switching default to
>> higher than sm_35, so there's little point to go to a multilib setup at
>> this point.  But once we fix that, we could reconsider, otherwise,
>> things are likely to regress again.
>
> As far as I remember, several issues have been fixed.  Still waiting for
> Roger's "middle-end: Support ABIs that pass FP values as wider integers"
> or something similar, but that PR104489 issue is being worked around by
> "Limit HFmode support to mexperimental", if I got that right.
>
> Now I'm not suggesting we should now enable all or any random GCC/nvptx
> multilibs, to get all these variants of GCC/nvptx target libraries built;
> especially also given that GCC/nvptx code generation currently doesn't
> make too much use of the new capabilities.
>
> However, we do have a specific request that a customer would like to be
> able to change at GCC 'configure' time the GCC/nvptx default multilib
> (including that being used for building corresponding GCC/nvptx target
> libraries).
>
> Per 'gcc/doc/install.texi', I do see that some GCC targets allow for
> GCC 'configure'-time '--with-multilib-list=[...]', or
> '--with-multilib-generator=[...]', and I suppose we could be doing
> something similar?  But before starting implementing, I'd like your
> input, as you'll be the one to approve in the end.  And/or, maybe you've
> already made up your own ideas about that?

 So, instead of "random GCC/nvptx multilib configuration" (last
 paragraph), I've come up with a way to implement our customer's request
 (second last paragraph): 'configure' GCC/nvptx '--with-arch=sm_70'.

 I think I've implemented this in a way so that "random GCC/nvptx multilib
 configuration" may eventually be implemented on top of that.  For easy
 review/testing I've split my changes into three commits, see attached
 "nvptx: Make default '-misa=sm_30' explicit",
 "nvptx: Introduce dummy multilib option for default '-misa=sm_30'",
 "nvptx: Allow '--with-arch' to override the default '-misa'".

 To the best of my knowledge, the first two patches do not change any
 user-visible behavior (I generally 'diff'ed target libraries, and
 compared a good number of 'gcc -print-multi-directory [flags]'), and
 likewise with the third patch, given implicit (default) or explicit
 '--with-arch=sm_30', and that with '--with-arch=sm_70', for example, the
 '-misa=sm_70' multilib variants 

[PING^5] nvptx: forward '-v' command-line option to assembler, linker

[Thomas Schwinge]

Hi Tom!

Ping.


Grüße
 Thomas


On 2022-07-20T14:44:36+0200, I wrote:
> Hi Tom!
>
> Ping.
>
>
> Grüße
>  Thomas
>
>
> On 2022-07-13T10:41:23+0200, I wrote:
>> Hi Tom!
>>
>> Ping.
>>
>>
>> Grüße
>>  Thomas
>>
>>
>> On 2022-07-05T16:58:54+0200, I wrote:
>>> Hi Tom!
>>>
>>> Ping.
>>>
>>>
>>> Grüße
>>>  Thomas
>>>
>>>
>>> On 2022-06-07T17:41:16+0200, I wrote:
 Hi!

 On 2022-05-30T09:06:21+0200, Tobias Burnus  wrote:
> On 29.05.22 22:49, Thomas Schwinge wrote:
>> Not sure if that's what you had in mind, but what do you think about the
>> attached "nvptx: forward '-v' command-line option to assembler, linker"?
>> OK to push to GCC master branch (after merging
>> 
>> "Put '-v' verbose output onto stderr instead of stdout")?
>
> I was mainly thinking of some way to have it available — which
> '-foffload-options=-Wa,-v' already permits on the GCC side. (Once the
> nvptx-tools patch actually makes use of the '-v'.)

 (Merged a week ago.)

> If I understand your patch correctly, this patch now causes 'gcc -v' to
> imply 'gcc -v -Wa,-v'. I think that's okay, since 'gcc -v' already
> outputs a lot of lines and those lines can be helpful to understand what
> happens and what not.

 ACK.

> Tom, your thoughts on this?

 Ping.


 Grüße
  Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From 17c35607d4927299b0c4bd19dd6fd205c85c4a4b Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Sun, 29 May 2022 22:31:43 +0200
Subject: [PATCH] nvptx: forward '-v' command-line option to assembler, linker

For example, for offloading compilation with '-save-temps -v', before vs. after
word-diff then looks like:

[...]
 [...]/build-gcc-offload-nvptx-none/gcc/as {+-v -v+} -o ./a.xnvptx-none.mkoffload.o ./a.xnvptx-none.mkoffload.s
{+Verifying sm_30 code with sm_35 code generation.+}
{+ ptxas -c -o /dev/null ./a.xnvptx-none.mkoffload.o --gpu-name sm_35 -O0+}
[...]
 [...]/build-gcc-offload-nvptx-none/gcc/collect2 {+-v -v+} -o ./a.xnvptx-none.mkoffload [...] @./a.xnvptx-none.mkoffload.args.1 -lgomp -lgcc -lc -lgcc
{+collect2 version 12.0.1 20220428 (experimental)+}
{+[...]/build-gcc-offload-nvptx-none/gcc/collect-ld -v -v -o ./a.xnvptx-none.mkoffload [...] ./a.xnvptx-none.mkoffload.o -lgomp -lgcc -lc -lgcc+}
{+Linking ./a.xnvptx-none.mkoffload.o as 0+}
{+trying lib libc.a+}
{+trying lib libgcc.a+}
{+trying lib libgomp.a+}
{+Resolving abort+}
{+Resolving acc_on_device+}
{+Linking libgomp.a::oacc-init.o/ as 1+}
{+Linking libc.a::lib_a-abort.o/   as 2+}
[...]

(This depends on 
"Put '-v' verbose output onto stderr instead of stdout".)

	gcc/
	* config/nvptx/nvptx.h (ASM_SPEC, LINK_SPEC): Define.
---
 gcc/config/nvptx/nvptx.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/gcc/config/nvptx/nvptx.h b/gcc/config/nvptx/nvptx.h
index ed72c253191..b184f1d0150 100644
--- a/gcc/config/nvptx/nvptx.h
+++ b/gcc/config/nvptx/nvptx.h
@@ -27,6 +27,13 @@
 
 /* Run-time Target.  */
 
+/* Assembler supports '-v' option; handle similar to
+   '../../gcc.cc:asm_options', 'HAVE_GNU_AS'.  */
+#define ASM_SPEC "%{v}"
+
+/* Linker supports '-v' option.  */
+#define LINK_SPEC "%{v}"
+
 #define STARTFILE_SPEC "%{mmainkernel:crt0.o}"
 
 #define TARGET_CPU_CPP_BUILTINS() nvptx_cpu_cpp_builtins ()
-- 
2.25.1

Cancelled event: GCC Rust hang out @ Wed 27 Jul 2022 7pm - 7:30pm (BST) (gcc-rust@gcc.gnu.org)

[philip . herron]

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:CANCEL
BEGIN:VTIMEZONE
TZID:Europe/London
X-LIC-LOCATION:Europe/London
BEGIN:DAYLIGHT
TZOFFSETFROM:+
TZOFFSETTO:+0100
TZNAME:BST
DTSTART:19700329T01
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0100
TZOFFSETTO:+
TZNAME:GMT
DTSTART:19701025T02
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTART;TZID=Europe/London:20220727T19
DTEND;TZID=Europe/London:20220727T193000
DTSTAMP:20220727T154847Z
ORGANIZER;CN=philip.her...@embecosm.com:mailto:philip.her...@embecosm.com
UID:4tl63v6qndrq0l26aisn0b4...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;CN=philip
 .her...@embecosm.com;X-NUM-GUESTS=0:mailto:philip.her...@embecosm.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=gc
 c-r...@gcc.gnu.org;X-NUM-GUESTS=0:mailto:gcc-rust@gcc.gnu.org
RECURRENCE-ID;TZID=Europe/London:20220727T19
CREATED:20220627T153912Z
DESCRIPTION:Hi everyone\n\nThis is a regular call for anyone to drop in and
  talk about gccrs\, it should suit some people better with this time.\n\nWe
  will reuse our jitsi link: https://meet.jit.si/gccrs-community-call\n \n \
 nThanks\n\n--Phil
LAST-MODIFIED:20220727T154846Z
LOCATION:https://meet.jit.si/gccrs-community-call
SEQUENCE:1
STATUS:CANCELLED
SUMMARY:GCC Rust hang out
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

[Bug c/91093] Error on implicit int by default

[fw at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Florian Weimer  ---
It seems that

auto x = 1.0;

will change meaning in C2X (as implemented by GCC) and use type double instead
of int for x. We are probably way too late to fix this (by rejecting the
construct in earlier language modes) before C2X support arrives in GCC.

This may require the same careful treatment as bug 91092 and bug 106416.

[Bug c/106416] -Wint-conversion should be an error, not a pedwarn

[fw at gcc dot gnu.org via Gcc-bugs]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fw at gcc dot gnu.org

--- Comment #1 from Florian Weimer  ---
This will likely need the same preparatory treatment as rejecting implicit
function declarations (bug 91092), for the same reason: Without some care
upfront, introducing the new compiler error will change configure test results
in fully consistent ways, resulting in silently dropped features.

[Bug middle-end/106449] ICE in #pragma omp parallel for simd since r6-4544-ge01d41e553aae245

[burnus at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from Tobias Burnus  ---
Comment on attachment 53362
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53362
gcc13-pr106449.patch

The code does not seem to work. If I add:

void foobar(int *a, int*b) {
  __builtin_printf("%lu\n", b-a);
}

and use it in place for the ';' in the loops, when then calling
  foo();
  bar(64, 128);

While foo() with and without OpenMP and - with -fno-openmp - also bar(64,128)
give all identical result. But -fopenmp, 'bar' does not call 'foobar' at all
(no printf output).

[Bug c/106455] bad style: comparatives over booleans ?

[schwab--- via Gcc-bugs]

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

--- Comment #4 from Andreas Schwab  ---
bool > bool is evaluated as (int)bool > (int)bool.

[Bug c/106455] bad style: comparatives over booleans ?

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #3 from David Binderman  ---
(In reply to Andrew Pinski from comment #1)
> bool > bool works just fine and is exactly what we want to test here.

Confused. So is false > true or true > false ?

[Bug c/106455] bad style: comparatives over booleans ?

[schwab--- via Gcc-bugs]

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

--- Comment #2 from Andreas Schwab  ---
negative && !other_negative is definitely easier to understand than negative >
other_negative.  In fact, given the condition negative != other_negative,
negative already implies !other_negative, so this can be simplified to just if
(negative != other_negative) return negative.

PING [PATCH] x86: Add ix86_ifunc_ref_local_ok

[H.J. Lu via Gcc-patches]

On Thu, Jul 21, 2022 at 11:53 AM H.J. Lu  wrote:
>
> We can't always use the PLT entry as the function address for local IFUNC
> functions.  When the PIC register is needed for PLT call, indirect call
> via the PLT entry will fail since the PIC register may not be set up
> properly for indirect call.  Add ix86_ifunc_ref_local_ok to return false
> when the PLT entry can't be used as local IFUNC function pointers.
>
> gcc/
>
> PR target/83782
> * config/i386/i386.cc (ix86_ifunc_ref_local_ok): New.
> (TARGET_IFUNC_REF_LOCAL_OK): Use it.
>
> gcc/testsuite/
>
> PR target/83782
> * gcc.target/i386/pr83782-1.c: Require non-ia32.
> * gcc.target/i386/pr83782-2.c: Likewise.
> * gcc.target/i386/pr83782-3.c: New test.
> ---
>  gcc/config/i386/i386.cc   | 15 ++-
>  gcc/testsuite/gcc.target/i386/pr83782-1.c |  8 +++---
>  gcc/testsuite/gcc.target/i386/pr83782-2.c |  4 +--
>  gcc/testsuite/gcc.target/i386/pr83782-3.c | 32 +++
>  4 files changed, 50 insertions(+), 9 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr83782-3.c
>
> diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
> index e03f86d4a23..5e30dc884bf 100644
> --- a/gcc/config/i386/i386.cc
> +++ b/gcc/config/i386/i386.cc
> @@ -16070,6 +16070,19 @@ ix86_call_use_plt_p (rtx call_op)
>return true;
>  }
>
> +/* Implement TARGET_IFUNC_REF_LOCAL_OK.  If this hook returns true,
> +   the PLT entry will be used as the function address for local IFUNC
> +   functions.  When the PIC register is needed for PLT call, indirect
> +   call via the PLT entry will fail since the PIC register may not be
> +   set up properly for indirect call.  In this case, we should return
> +   false.  */
> +
> +static bool
> +ix86_ifunc_ref_local_ok (void)
> +{
> +  return !flag_pic || (TARGET_64BIT && ix86_cmodel != CM_LARGE_PIC);
> +}
> +
>  /* Return true if the function being called was marked with attribute
> "noplt" or using -fno-plt and we are compiling for non-PIC.  We need
> to handle the non-PIC case in the backend because there is no easy
> @@ -24953,7 +24966,7 @@ ix86_libgcc_floating_mode_supported_p
>ix86_get_multilib_abi_name
>
>  #undef TARGET_IFUNC_REF_LOCAL_OK
> -#define TARGET_IFUNC_REF_LOCAL_OK hook_bool_void_true
> +#define TARGET_IFUNC_REF_LOCAL_OK ix86_ifunc_ref_local_ok
>
>  #if !TARGET_MACHO && !TARGET_DLLIMPORT_DECL_ATTRIBUTES
>  # undef TARGET_ASM_RELOC_RW_MASK
> diff --git a/gcc/testsuite/gcc.target/i386/pr83782-1.c 
> b/gcc/testsuite/gcc.target/i386/pr83782-1.c
> index ce97b12e65d..85674346aec 100644
> --- a/gcc/testsuite/gcc.target/i386/pr83782-1.c
> +++ b/gcc/testsuite/gcc.target/i386/pr83782-1.c
> @@ -1,4 +1,4 @@
> -/* { dg-do compile } */
> +/* { dg-do compile { target { ! ia32 } } } */
>  /* { dg-require-ifunc "" } */
>  /* { dg-options "-O2 -fpic" } */
>
> @@ -20,7 +20,5 @@ bar(void)
>return foo;
>  }
>
> -/* { dg-final { scan-assembler {leal[ \t]foo@GOTOFF\(%[^,]*\),[ \t]%eax} { 
> target ia32 } } } */
> -/* { dg-final { scan-assembler {lea(?:l|q)[ \t]foo\(%rip\),[ \t]%(?:e|r)ax} 
> { target { ! ia32 } } } } */
> -/* { dg-final { scan-assembler-not "foo@GOT\\\(" { target ia32 } } } */
> -/* { dg-final { scan-assembler-not "foo@GOTPCREL\\\(" { target { ! ia32 } } 
> } } */
> +/* { dg-final { scan-assembler {lea(?:l|q)[ \t]foo\(%rip\),[ \t]%(?:e|r)ax} 
> } } */
> +/* { dg-final { scan-assembler-not "foo@GOTPCREL\\\(" } } */
> diff --git a/gcc/testsuite/gcc.target/i386/pr83782-2.c 
> b/gcc/testsuite/gcc.target/i386/pr83782-2.c
> index e25d258bbda..a654ded771f 100644
> --- a/gcc/testsuite/gcc.target/i386/pr83782-2.c
> +++ b/gcc/testsuite/gcc.target/i386/pr83782-2.c
> @@ -1,4 +1,4 @@
> -/* { dg-do compile } */
> +/* { dg-do compile { target { ! ia32 } } } */
>  /* { dg-require-ifunc "" } */
>  /* { dg-options "-O2 -fpic" } */
>
> @@ -20,7 +20,5 @@ bar(void)
>return foo;
>  }
>
> -/* { dg-final { scan-assembler {leal[ \t]foo@GOTOFF\(%[^,]*\),[ \t]%eax} { 
> target ia32 } } } */
>  /* { dg-final { scan-assembler {lea(?:l|q)[ \t]foo\(%rip\),[ \t]%(?:e|r)ax} 
> { target { ! ia32 } } } } */
> -/* { dg-final { scan-assembler-not "foo@GOT\\\(" { target ia32 } } } */
>  /* { dg-final { scan-assembler-not "foo@GOTPCREL\\\(" { target { ! ia32 } } 
> } } */
> diff --git a/gcc/testsuite/gcc.target/i386/pr83782-3.c 
> b/gcc/testsuite/gcc.target/i386/pr83782-3.c
> new file mode 100644
> index 000..1536481cb79
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/i386/pr83782-3.c
> @@ -0,0 +1,32 @@
> +/* { dg-do run }  */
> +/* { dg-require-ifunc "" } */
> +/* { dg-require-effective-target pie } */
> +/* { dg-options "-fpie -pie" } */
> +
> +#include 
> +
> +static int __attribute__((noinline))
> +implementation (void)
> +{
> +  printf ("'ere I am JH\n");
> +  return 0;
> +}
> +
> +static __typeof__ (implementation) *resolver (void)
> +{
> +  return (void *)implementation;
> +}
> +
> +extern int magic (void) __attribute__ 

[Bug c/106455] bad style: comparatives over booleans ?

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Andrew Pinski  ---
This is not bad style at all.

bool > bool works just fine and is exactly what we want to test here.
Basically it means

negative && !other_negative

[Bug middle-end/106449] ICE in #pragma omp parallel for simd since r6-4544-ge01d41e553aae245

[burnus at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from Tobias Burnus  ---
Comment on attachment 53362
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53362
gcc13-pr106449.patch

> +   t = fold_convert (sizetype, fd->loops[i + 1].n1);
> +   t = fold_build_pointer_plus (t2, t);

I think the first line is not needed, given that fold_build_pointer_plus_loc
has:

  return fold_build2_loc (loc, POINTER_PLUS_EXPR, TREE_TYPE (ptr),
  ptr, convert_to_ptrofftype_loc (loc, off));

and the convert_to_ptrofftype_loc does:

  if (ptrofftype_p (TREE_TYPE (off)))
return off;
  return fold_convert_loc (loc, sizetype, off);

where the last line matches your first line. Hence, just calling

  t = fold_build_pointer_plus (t2, fd->loops[i + 1].n1);

should gives the same result and is more compact (avoids a line and a
2-character indent).

Re: [PATCH] [PR83782] i386 PIE: avoid @GOTOFF for ifuncs and their aliases

[H.J. Lu via Gcc-patches]

On Tue, Jul 26, 2022 at 10:14 PM Alexandre Oliva  wrote:
>
>
> g++.dg/ext/attr-ifunc-3.C and gcc.target/i386/mvc10.c, not changed,
> have made it clear that there were problems in the optimizations to
> use @GOTOFF to refer to locally-bound ifuncs.  GNU ld as recently as
> May 2018 would reject such constructs, whereas later versions will
> silently accept but generate incorrect PIE with them (attr-ifunc-3.C)
> or still reject them if referenced through aliases (mvc10.c).  The use
> of @GOTOFF for locally-bound but externally-visible symbols
> (e.g. protected visibility) also breaks pointer identity if the
> canonical address ends up preempted by a PLT entry.  This patch
> modifies the local_symbolic_operand predicate to disable @GOTOFF for
> locally-bound symbols that would require @PLT for calls, restoring
> earlier behavior and disabling the optimization that has proven
> problematic even on amd64.  Eventually we may reintroduce the
> optimization, when the linker is fixed and we test for the fix before
> enabling it, and we exclude symbols whose canonical addresses may be
> preempted even when the symbol definition can't.  pr83782 tests have
> been adjusted to expect @GOT instead of @GOTOFF.
>
> Regstrapped on x86_64-linux-gnu; also tested, along with other patches
> I'm posting today with "i386 PIE" in the subject, and compared
> default-PIE and default-nonPIE results on it, and on i686-linux-gnu.  Ok
> to install?

Here is a different fix:

https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598667.html

Use PLT doesn't mean that it can't be treated as local.  The problem
on ia32 is that PIC won't be set up properly for indirect call.There is
no problem on x86-64 and non-PIC on ia32.

>
> for  gcc/ChangeLog
>
> PR target/83782
> * config/i386/predicates.md (local_symbolic_operand): Disable
> GOTOFF even for locally-bound ifuncs.
> * config/i386/i386.cc (ix86_call_use_plt_p): Follow the alias
> chain looking for an ifunc, as in gcc.target/i386/mvc10.c.
>
> for  gcc/testsuite/ChangeLog
>
> PR target/83782
> * gcc.target/i386/pr83782-1.c: Adjust to require GOT rather
> than GOTOFF on ia32.
> * gcc.target/i386/pr83782-2.c: Likewise.
> ---
>  gcc/config/i386/i386.cc   |   16 ++--
>  gcc/config/i386/predicates.md |4 +++-
>  gcc/testsuite/gcc.target/i386/pr83782-1.c |4 ++--
>  gcc/testsuite/gcc.target/i386/pr83782-2.c |4 ++--
>  4 files changed, 17 insertions(+), 11 deletions(-)
>
> diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
> index aab28da4b5d4b..5c5dc8d2373ff 100644
> --- a/gcc/config/i386/i386.cc
> +++ b/gcc/config/i386/i386.cc
> @@ -16058,13 +16058,17 @@ ix86_call_use_plt_p (rtx call_op)
>  {
>if (SYMBOL_REF_DECL (call_op)
>   && TREE_CODE (SYMBOL_REF_DECL (call_op)) == FUNCTION_DECL)
> -   {
> - /* NB: All ifunc functions must be called via PLT.  */
> - cgraph_node *node
> -   = cgraph_node::get (SYMBOL_REF_DECL (call_op));
> - if (node && node->ifunc_resolver)
> +   /* NB: All ifunc functions must be called via PLT, and we have
> +  to explicitly iterate over an alias chain looking for a
> +  node marked as an ifunc(_resolver) to tell.  That node is
> +  itself aliased to the actual resolver function, so
> +  ultimate_alias_target would skip the marker, and the call
> +  may be to another declaration aliased to the ifunc.  */
> +   for (cgraph_node *node
> +  = cgraph_node::get (SYMBOL_REF_DECL (call_op));
> +node && node->alias; node = node->get_alias_target ())
> + if (node->ifunc_resolver)
> return true;
> -   }
>return false;
>  }
>return true;
> diff --git a/gcc/config/i386/predicates.md b/gcc/config/i386/predicates.md
> index 42053ea7209f6..411c06e22e600 100644
> --- a/gcc/config/i386/predicates.md
> +++ b/gcc/config/i386/predicates.md
> @@ -596,7 +596,9 @@ (define_predicate "local_symbolic_operand"
>if (TARGET_DLLIMPORT_DECL_ATTRIBUTES && SYMBOL_REF_DLLIMPORT_P (op))
>  return false;
>if (SYMBOL_REF_LOCAL_P (op))
> -return true;
> +/* ifuncname@GOTOFF was rejected by the x86 linker before May
> +   2018, and silently generated wrong code for PIE afterwards.  */
> +return !ix86_call_use_plt_p (op);
>
>/* There is, however, a not insubstantial body of code in the rest of
>   the compiler that assumes it can just stick the results of
> diff --git a/gcc/testsuite/gcc.target/i386/pr83782-1.c 
> b/gcc/testsuite/gcc.target/i386/pr83782-1.c
> index ce97b12e65d58..af52278ec4df2 100644
> --- a/gcc/testsuite/gcc.target/i386/pr83782-1.c
> +++ b/gcc/testsuite/gcc.target/i386/pr83782-1.c
> @@ -20,7 +20,7 @@ bar(void)
>return foo;
>  }
>
> -/* { dg-final { scan-assembler {leal[ \t]foo@GOTOFF\(%[^,]*\),[ \t]%eax} { 
> target ia32 } } } */
> +/* { dg-final { 

[GCC 12] [PATCH] x86: Support 2/4/8 byte constant vector stores

[H.J. Lu via Gcc-patches]

On Fri, Jul 1, 2022 at 8:31 AM Uros Bizjak  wrote:
>
> On Thu, Jun 30, 2022 at 4:50 PM H.J. Lu  wrote:
> >
> > 1. Add a predicate for constant vectors which can be converted to integer
> > constants suitable for constant integer stores.  For a 8-byte constant
> > vector, the converted 64-bit integer must be valid for store with 64-bit
> > immediate, which is a 64-bit integer sign-extended from a 32-bit integer.
> > 2. Add a new pattern to allow 2-byte, 4-byte and 8-byte constant vector
> > stores, like
> >
> > (set (mem:V2HI (reg:DI 84))
> >  (const_vector:V2HI [(const_int 0 [0]) (const_int 1 [0x1])]))
> >
> > 3. After reload, convert constant vector stores to constant integer
> > stores, like
> >
> > (set (mem:SI (reg:DI 5 di [84]))
> >  (const_int 65536 [0x1]))
> >
> > For
> >
> > void
> > foo (short * c)
> > {
> >   c[0] = 0;
> >   c[1] = 1;
> > }
> >
> > it generates
> >
> > movl$65536, (%rdi)
> >
> > instead of
> >
> > movl.LC0(%rip), %eax
> > movl%eax, (%rdi)
> >
> > gcc/
> >
> > PR target/106022
> > * config/i386/i386-protos.h (ix86_convert_const_vector_to_integer):
> > New.
> > * config/i386/i386.cc (ix86_convert_const_vector_to_integer):
> > New.
> > * config/i386/mmx.md (V_16_32_64): New.
> > (*mov_imm): New patterns for stores with 16-bit, 32-bit
> > and 64-bit constant vector.
> > * config/i386/predicates.md (x86_64_const_vector_operand): New.
> >
> > gcc/testsuite/
> >
> > PR target/106022
> > * gcc.target/i386/pr106022-1.c: New test.
> > * gcc.target/i386/pr106022-2.c: Likewise.
> > * gcc.target/i386/pr106022-3.c: Likewise.
> > * gcc.target/i386/pr106022-4.c: Likewise.
>
> OK.

OK to backport to GCC 12 branch?

> Thanks,
> Uros.
>
> > ---
> >  gcc/config/i386/i386-protos.h  |  2 +
> >  gcc/config/i386/i386.cc| 47 ++
> >  gcc/config/i386/mmx.md | 37 +
> >  gcc/config/i386/predicates.md  | 11 +
> >  gcc/testsuite/gcc.target/i386/pr106022-1.c | 13 ++
> >  gcc/testsuite/gcc.target/i386/pr106022-2.c | 14 +++
> >  gcc/testsuite/gcc.target/i386/pr106022-3.c | 14 +++
> >  gcc/testsuite/gcc.target/i386/pr106022-4.c | 14 +++
> >  8 files changed, 152 insertions(+)
> >  create mode 100644 gcc/testsuite/gcc.target/i386/pr106022-1.c
> >  create mode 100644 gcc/testsuite/gcc.target/i386/pr106022-2.c
> >  create mode 100644 gcc/testsuite/gcc.target/i386/pr106022-3.c
> >  create mode 100644 gcc/testsuite/gcc.target/i386/pr106022-4.c
> >
> > diff --git a/gcc/config/i386/i386-protos.h b/gcc/config/i386/i386-protos.h
> > index 3596ce81ecf..cf847751ac5 100644
> > --- a/gcc/config/i386/i386-protos.h
> > +++ b/gcc/config/i386/i386-protos.h
> > @@ -122,6 +122,8 @@ extern void ix86_expand_unary_operator (enum rtx_code, 
> > machine_mode,
> > rtx[]);
> >  extern rtx ix86_build_const_vector (machine_mode, bool, rtx);
> >  extern rtx ix86_build_signbit_mask (machine_mode, bool, bool);
> > +extern HOST_WIDE_INT ix86_convert_const_vector_to_integer (rtx,
> > +  machine_mode);
> >  extern void ix86_split_convert_uns_si_sse (rtx[]);
> >  extern void ix86_expand_convert_uns_didf_sse (rtx, rtx);
> >  extern void ix86_expand_convert_uns_sixf_sse (rtx, rtx);
> > diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
> > index b15b4893bb9..0cfe9962f75 100644
> > --- a/gcc/config/i386/i386.cc
> > +++ b/gcc/config/i386/i386.cc
> > @@ -15723,6 +15723,53 @@ ix86_build_signbit_mask (machine_mode mode, bool 
> > vect, bool invert)
> >return force_reg (vec_mode, v);
> >  }
> >
> > +/* Return HOST_WIDE_INT for const vector OP in MODE.  */
> > +
> > +HOST_WIDE_INT
> > +ix86_convert_const_vector_to_integer (rtx op, machine_mode mode)
> > +{
> > +  if (GET_MODE_SIZE (mode) > UNITS_PER_WORD)
> > +gcc_unreachable ();
> > +
> > +  int nunits = GET_MODE_NUNITS (mode);
> > +  wide_int val = wi::zero (GET_MODE_BITSIZE (mode));
> > +  machine_mode innermode = GET_MODE_INNER (mode);
> > +  unsigned int innermode_bits = GET_MODE_BITSIZE (innermode);
> > +
> > +  switch (mode)
> > +{
> > +case E_V2QImode:
> > +case E_V4QImode:
> > +case E_V2HImode:
> > +case E_V8QImode:
> > +case E_V4HImode:
> > +case E_V2SImode:
> > +  for (int i = 0; i < nunits; ++i)
> > +   {
> > + int v = INTVAL (XVECEXP (op, 0, i));
> > + wide_int wv = wi::shwi (v, innermode_bits);
> > + val = wi::insert (val, wv, innermode_bits * i, innermode_bits);
> > +   }
> > +  break;
> > +case E_V2HFmode:
> > +case E_V4HFmode:
> > +case E_V2SFmode:
> > +  for (int i = 0; i < nunits; ++i)
> > +   {
> > + rtx x = XVECEXP (op, 0, i);
> > + int v = real_to_target (NULL, CONST_DOUBLE_REAL_VALUE (x),
> > 

[committed] docs: Fix outdated reference to LOOPS_HAVE_MARKED_SINGLE_EXITS

[Andrew Carlotti via Gcc-patches]

This reference has been wrong since 2007; committed as an obvious fix.

gcc/ChangeLog:

 * doc/loop.texi: Refer to LOOPS_HAVE_RECORDED_EXITS instead.

diff --git a/gcc/doc/loop.texi b/gcc/doc/loop.texi
index 
d7b71a24dbfed284b13da702bd5037691a515535..6e8657a074d2447db7ae9b75cbfbb71282b84287
 100644
--- a/gcc/doc/loop.texi
+++ b/gcc/doc/loop.texi
@@ -210,7 +210,7 @@ loop in depth-first search order in reversed CFG, ordered 
by dominance
 relation, and breath-first search order, respectively.
 @item @code{single_exit}: Returns the single exit edge of the loop, or
 @code{NULL} if the loop has more than one exit.  You can only use this
-function if LOOPS_HAVE_MARKED_SINGLE_EXITS property is used.
+function if @code{LOOPS_HAVE_RECORDED_EXITS} is used.
 @item @code{get_loop_exit_edges}: Enumerates the exit edges of a loop.
 @item @code{just_once_each_iteration_p}: Returns true if the basic block
 is executed exactly once during each iteration of a loop (that is, it

☺ Buildbot (GNU Toolchain): gccrust - build successful (master)

[builder--- via Gcc-rust]

A restored build has been detected on builder gccrust-bootstrap-debian-amd64 
while building gccrust.

Full details are available at:
https://builder.sourceware.org/buildbot/#builders/107/builds/48

Build state: build successful
Revision: 961468ed824a7b49f10ed597ba9dcc98177125ca
Worker: bb2
Build Reason: (unknown)
Blamelist: Arthur Cohen , bors[bot] 
<26634292+bors[bot]@users.noreply.github.com>, liushuyu 

Steps:

- 0: worker_preparation ( success )

- 1: git checkout ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/107/builds/48/steps/1/logs/stdio

- 2: rm -rf gccrs-build ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/107/builds/48/steps/2/logs/stdio

- 3: configure ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/107/builds/48/steps/3/logs/stdio

- 4: make ( warnings )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/107/builds/48/steps/4/logs/stdio
- warnings (42): 
https://builder.sourceware.org/buildbot/#builders/107/builds/48/steps/4/logs/warnings__42_

- 5: make check ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/107/builds/48/steps/5/logs/stdio
- rust.sum: 
https://builder.sourceware.org/buildbot/#builders/107/builds/48/steps/5/logs/rust_sum
- rust.log: 
https://builder.sourceware.org/buildbot/#builders/107/builds/48/steps/5/logs/rust_log

- 6: grep unexpected rust.sum ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/107/builds/48/steps/6/logs/stdio

- 7: prep ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/107/builds/48/steps/7/logs/stdio

- 8: build bunsen.cpio ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/107/builds/48/steps/8/logs/stdio

- 9: fetch bunsen.cpio ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/107/builds/48/steps/9/logs/stdio

- 10: unpack bunsen.cpio ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/107/builds/48/steps/10/logs/stdio

- 11: pass .bunsen.source.gitname ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/107/builds/48/steps/11/logs/stdio

- 12: pass .bunsen.source.gitbranch ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/107/builds/48/steps/12/logs/stdio

- 13: pass .bunsen.source.gitrepo ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/107/builds/48/steps/13/logs/stdio

- 14: upload to bunsen ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/107/builds/48/steps/14/logs/stdio

- 15: clean up ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/107/builds/48/steps/15/logs/stdio

- 16: rm -rf gccrs-build_1 ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/107/builds/48/steps/16/logs/stdio

-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

[Bug c/106456] New: -Wunreachable-code seems very broken

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 106456
   Summary: -Wunreachable-code seems very broken
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

I tried out this simple example:

extern void g( int);

int f( int a)
{
return 2 * a;
g( a);
}

gcc doesn't seem able to find the problem:

$ /home/dcb/gcc/results/bin/g++ -c -g -O2 -Wall -Wextra -Wunreachable-code
jul27d.cc
$

clang++ can:

$ clang++ -c -g -O2 -Wall -Wextra -Wunreachable-code jul27d.cc
jul27d.cc:7:2: warning: code will never be executed [-Wunreachable-code]
g( a);
^
1 warning generated.
$

Following on from this, there are a couple of examples in the gcc source code:

trunk.git/gcc/value-range-storage.h:149:3: style: Statements following return,
break, continue, goto or throw will never be executed. [unreachableCode]
trunk.git/gcc/value-range-storage.h:210:3: style: Statements following return,
break, continue, goto or throw will never be executed. [unreachableCode]

Re: [PATCH Rust front-end v1 3/4] Add Rust target hooks to ARM

[Richard Earnshaw via Gcc-patches]

On 27/07/2022 14:40, herron.philip--- via Gcc-patches wrote:

From: Philip Herron 

This adds the nessecary target hooks for the arm target.

gcc/ChangeLog:

 * config.gcc: add rust_target_objs for arm

gcc/config/arm/ChangeLog:

* arm-protos.h: define arm_rust_target_cpu_info
 * arm-rust.cc: new file to generate info
* arm.h: define TARGET_RUST_CPU_INFO
* bpabi.h: define TARGET_RUST_OS_INFO
* freebsd.h: likewise
* linux-eabi.h: likewise
* linux-elf.h: likewise
* netbsd-eabi.h: likewise
* netbsd-elf.h: likewise
* rtems.h: likewise
* symbian.h: likewise
* t-arm: compile arm-rust.cc
* uclinux-eabi.h: define TARGET_RUST_OS_INFO
* uclinux-elf.h: likewise
* vxworks.h: likewise

Co-authored-by: SimplyTheOther 
---
  gcc/config.gcc|   1 +
  gcc/config/arm/arm-protos.h   |   3 +
  gcc/config/arm/arm-rust.cc| 304 ++
  gcc/config/arm/arm.h  |   3 +
  gcc/config/arm/bpabi.h|  11 ++
  gcc/config/arm/freebsd.h  |   9 +
  gcc/config/arm/linux-eabi.h   |   8 +
  gcc/config/arm/linux-elf.h|   5 +
  gcc/config/arm/netbsd-eabi.h  |  10 ++
  gcc/config/arm/netbsd-elf.h   |   8 +
  gcc/config/arm/rtems.h|  14 ++
  gcc/config/arm/symbian.h  |  15 ++
  gcc/config/arm/t-arm  |   4 +
  gcc/config/arm/uclinux-eabi.h |  13 ++
  gcc/config/arm/uclinux-elf.h  |  12 ++
  gcc/config/arm/vxworks.h  |  14 ++
  16 files changed, 434 insertions(+)
  create mode 100644 gcc/config/arm/arm-rust.cc

diff --git a/gcc/config.gcc b/gcc/config.gcc
index cdd4fb4392a..9d686019b28 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -368,6 +368,7 @@ arm*-*-*)
c_target_objs="arm-c.o"
cxx_target_objs="arm-c.o"
d_target_objs="arm-d.o"
+rust_target_objs="arm-rust.o"
extra_options="${extra_options} arm/arm-tables.opt"
target_gtfiles="\$(srcdir)/config/arm/arm-builtins.cc 
\$(srcdir)/config/arm/arm-mve-builtins.h \$(srcdir)/config/arm/arm-mve-builtins.cc"
;;
diff --git a/gcc/config/arm/arm-protos.h b/gcc/config/arm/arm-protos.h
index f8aabbdae37..9513f96fdbc 100644
--- a/gcc/config/arm/arm-protos.h
+++ b/gcc/config/arm/arm-protos.h
@@ -406,6 +406,9 @@ extern void arm_cpu_cpp_builtins (struct cpp_reader *);
  extern void arm_d_target_versions (void);
  extern void arm_d_register_target_info (void);
  
+/* Defined in arm-rust.c  */

+extern void arm_rust_target_cpu_info (void);
+
  extern bool arm_is_constant_pool_ref (rtx);
  
  /* The bits in this mask specify which instruction scheduling options should

diff --git a/gcc/config/arm/arm-rust.cc b/gcc/config/arm/arm-rust.cc
new file mode 100644
index 000..7c83e3fa3a6
--- /dev/null
+++ b/gcc/config/arm/arm-rust.cc
@@ -0,0 +1,304 @@
+/* Subroutines for the Rust front end on the ARM architecture.
+   Copyright (C) 2020 Free Software Foundation, Inc.
+
+GCC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 3, or (at your option)
+any later version.
+
+GCC is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3.  If not see
+.  */
+
+#include "config.h"
+#include "system.h"
+#include "coretypes.h"
+#include "tm.h"
+#include "tm_p.h"
+#include "rust/rust-target.h"
+#include "rust/rust-target-def.h"
+
+/* Implement TARGET_RUST_CPU_INFO for ARM targets.  */
+
+void arm_rust_target_cpu_info(void) {
+rust_add_target_info("target_arch", "arm");
+
+/* TODO: further research support for CLREX, acquire-release (lda/ldaex), 
slow-fp-brcc (slow FP
+ * compare and branch), perfmon, trustzone, fpao, fuse-aes, fuse-literals, 
read-tp-hard, zcz,
+ * prof-unpr, slow-vgetlni32, slow-vdup32, prefer-vmovsr, prefer-ishst, 
muxed-units, slow-odd-reg,
+ * slow-load-D-subreg, wide-stride-vfp, dont-widen-vmovs, splat-vfp-neon, 
expand-fp-mlx,
+ * vmlx-hazards, neon-fpmovs, neonfp (as in using neon for scalar fp), 
vldn-align,
+ * nonpipelined-vfp, slowfpvmlx, slowfpvfmx, vmlx-forwarding, 32bit 
(prefer 32-bit Thumb),
+ * loop-align, mve1beat, mve2beat, mve4beat, avoid-partial-cpsr, 
cheap-predictable-cpsr,
+ * avoid-movs-shop, ret-addr-stack, no-branch-predictor, virtualization, 
nacl-trap, execute-only,
+ * reserve-r9, no-movt, no-neg-immediates, use-misched, 
disable-postra-scheduler, lob (Low
+ * Overhead Branch), noarm, cde - can't find them. */
+/* TODO: figure out if gcc has an equivalent to "fpregs" (floating-point 
registers even if only
+ * used for integer - shared 

[Bug c/106455] New: bad style: comparatives over booleans ?

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 106455
   Summary: bad style: comparatives over booleans ?
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Static analyser cppcheck says for recent gcc trunk:

trunk.git/gcc/sreal.h:72:25: style: Comparison of a variable having boolean
value using relational (<, >, <= or >=) operator.
[comparisonOfBoolWithBoolError]

Source code is

  bool negative = m_sig < 0;
  bool other_negative = other.m_sig < 0;

  if (negative != other_negative)
return negative > other_negative;

I agree - this looks bad style to me. I don't think > should work on booleans.

Re: [RFC] Analysis of PR105586 and possible approaches to fix issue

[Surya Kumari Jangala via Gcc]

Hi Richard,

On 27/07/22 12:28 pm, Richard Biener wrote:
> On Tue, Jul 26, 2022 at 8:55 PM Surya Kumari Jangala via Gcc
>  wrote:

>> To fix the issue of insns being assigned different cycles, there are two 
>> possible solutions:
>>
>> 1. Modify no_real_insns_p() to treat a DEBUG insn as a non-real insn 
>> (similar to NOTE and LABEL). With this change, bb 3 will not be scheduled in 
>> the debug mode (as it contains only NOTE and DEBUG insns). If scheduling is 
>> skipped, then bb 3’s state is not copied to bb 4 and the initial dfa state 
>> of bb 4 will be same in both debug and non-debug modes
>> 2. Copy dfa state of a basic block to it’s fall-thru block only if the basic 
>> block contains ‘real’ insns (ie, it should contain at least one insn which 
>> is not a LABEL, NOTE or DEBUG). This will prevent copying of dfa state from 
>> bb 3 to bb 4 in debug mode.
> 
> Do you know why the DFA state is not always copied to the fallthru
> destination and then copied further even if the block does not contain

I am not sure why the DFA state is not always copied to the fallthru 
destination. It is not very apparent from the code.

> any (real) insns?  It somewhat sounds like premature optimization
> breaking things here...
> 

Now that you mention it, yes it does seem suboptimal that the DFA state is not 
always copied. I don’t see any reason why the DFA state shouldn’t be always 
copied. And I think this is the fix for this bug. '-g' mode is behaving 
correctly, it is the non-debug mode which is incorrect.

Thanks,
Surya

[Bug middle-end/106449] ICE in #pragma omp parallel for simd since r6-4544-ge01d41e553aae245

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Jakub Jelinek  ---
Created attachment 53362
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53362=edit
gcc13-pr106449.patch

Untested fix.

[Bug analyzer/106003] RFE: -fanalyzer could complain about misuse of file-descriptors

[mir at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106003
Bug 106003 depends on bug 106286, which changed state.

Bug 106286 Summary: fd_diagnostic should implement get_meaning_for_state_change 
vfunc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106286

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

[Bug analyzer/106286] fd_diagnostic should implement get_meaning_for_state_change vfunc

[mir at gcc dot gnu.org via Gcc-bugs]

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

Immad Mir  changed:

   What|Removed |Added

 CC||mir at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Immad Mir  ---
Issue resolved.

[RISCV] RISC-V GNU Toolchain Meeting Cancell (July, 28, 2022)

[jiawei]

Hi all,



Tomorrow meeting will cancel since there are few new topics to discuss.  

   


The next meeting will be two weeks later, and we are collecting the themes.




If you have any questions want to discuss please mail me and I will add it 
into 

the agenda for next meeting.





Best wishes,

Jiawei

[Bug analyzer/106286] fd_diagnostic should implement get_meaning_for_state_change vfunc

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Immad Mir :

https://gcc.gnu.org/g:0f82c0ea8d86ee3bb404c460a04ff2ccfb56d2a0

commit r13-1860-g0f82c0ea8d86ee3bb404c460a04ff2ccfb56d2a0
Author: Immad Mir 
Date:   Wed Jul 27 19:16:36 2022 +0530

analyzer: add get_meaning_for_state_change vfunc to fd_diagnostic in
sm-fd.cc [PR106286]

This patch adds get_meaning_for_state_change vfunc to
fd_diagnostic in sm-fd.cc which could be used by SARIF output.

Lightly tested on x86_64 Linux.

gcc/analyzer/ChangeLog:
PR analyzer/106286
* sm-fd.cc:
(fd_diagnostic::get_meaning_for_state_change): New.

gcc/testsuite/ChangeLog:
PR analyzer/106286
* gcc.dg/analyzer/fd-meaning.c: New test.

Signed-off-by: Immad Mir 

[Bug rtl-optimization/106419] ICE in lra_assign, at lra-assigns.cc:1649

[segher at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #10 from Segher Boessenkool  ---
(In reply to Kewen Lin from comment #9)
> (In reply to Segher Boessenkool from comment #8)
> > So for which pseudo and which hard register did this ICE, and what did the
> > code look like at that point?
> 
> The culprit pseudo is r133, the values of those related expressions in the
> check:
> 
> lra_reg_info[i].nrefs  -> 4
> 
> reg_renumber[i] -> 97
> 
> overlaps_hard_reg_set_p(lra_reg_info[i].conflict_hard_regs, E_SImode, 97) ->
> true
> 
> Before IRA, the code looks like:

> (insn 34 33 35 4 (set (reg:SI 97 ctr)
> (reg/v/f:SI 133 [ foo ])) "test.f":17:72 562 {*movsi_internal1}
>  (nil))  

> in IRA, the hard reg assignment is:

> choosing r3 for r133.

Doing ctr (reg 97) instead (as LRA seems to change it to?) is
counterproductive.

We have that

> (insn 33 32 34 4 (set (reg:SI 3 3)
> (reg/v/f:SI 137 [ g ])) "test.f":17:72 562 {*movsi_internal1}
>  (nil))

right before 34, so if we want to use hard reg 3 for pseudo 97 we could
swap insns 33 and 34 (both of which are trivial assignments), much nicer
than the current dance via memory.

But all of this is a distraction from the actual bug here, sorry.

[PATCH] Some additional zero-extension related optimizations in simplify-rtx.

[Roger Sayle]

This patch implements some additional zero-extension and sign-extension
related optimizations in simplify-rtx.cc.  The original motivation comes
from PR rtl-optimization/71775, where in comment #2 Andrew Pinski sees:

Failed to match this instruction:
(set (reg:DI 88 [ _1 ])
(sign_extend:DI (subreg:SI (ctz:DI (reg/v:DI 86 [ x ])) 0)))

On many platforms the result of DImode CTZ is constrained to be a
small unsigned integer (between 0 and 64), hence the truncation to
32-bits (using a SUBREG) and the following sign extension back to
64-bits are effectively a no-op, so the above should ideally (often)
be simplified to "(set (reg:DI 88) (ctz:DI (reg/v:DI 86 [ x ]))".

To implement this, and some closely related transformations, we build
upon the existing val_signbit_known_clear_p predicate.  In the first
chunk, nonzero_bits knows that FFS and ABS can't leave the sign-bit
bit set, so the simplification of of ABS (ABS (x)) and ABS (FFS (x))
can itself be simplified.  The second transformation is that we can
canonicalized SIGN_EXTEND to ZERO_EXTEND (as in the PR 71775 case above)
when the operand's sign-bit is known to be clear.  The final two chunks
are for SIGN_EXTEND of a truncating SUBREG, and ZERO_EXTEND of a
truncating SUBREG respectively.  The nonzero_bits of a truncating
SUBREG pessimistically thinks that the upper bits may have an
arbitrary value (by taking the SUBREG), so we need look deeper at the
SUBREG's operand to confirm that the high bits are known to be zero.

Unfortunately, for PR rtl-optimization/71775, ctz:DI on x86_64 with
default architecture options is undefined at zero, so we can't be sure
the upper bits of reg:DI 88 will be sign extended (all zeros or all ones).
nonzero_bits knows this, so the above transformations don't trigger,
but the transformations themselves are perfectly valid for other
operations such as FFS, POPCOUNT and PARITY, and on other targets/-march
settings where CTZ is defined at zero.

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.  Testing with CSiBE shows these transformations
trigger on several source files (and with -Os reduces the size of the
code).  Ok for mainline?


2022-07-27  Roger Sayle  

gcc/ChangeLog
* simplify_rtx.cc (simplify_unary_operation_1) : Simplify
test as both FFS and ABS result in nonzero_bits returning a
mask that satisfies val_signbit_known_clear_p.
: Canonicalize SIGN_EXTEND to ZERO_EXTEND when
val_signbit_known_clear_p is true of the operand.
Simplify sign extensions of SUBREG truncations of operands
that are already suitably (zero) extended.
: Simplify zero extensions of SUBREG truncations
of operands that are already suitably zero extended.


Thanks in advance,
Roger
--

diff --git a/gcc/simplify-rtx.cc b/gcc/simplify-rtx.cc
index fa20665..e62bf56 100644
--- a/gcc/simplify-rtx.cc
+++ b/gcc/simplify-rtx.cc
@@ -1366,9 +1366,8 @@ simplify_context::simplify_unary_operation_1 (rtx_code 
code, machine_mode mode,
break;
 
   /* If operand is something known to be positive, ignore the ABS.  */
-  if (GET_CODE (op) == FFS || GET_CODE (op) == ABS
- || val_signbit_known_clear_p (GET_MODE (op),
-   nonzero_bits (op, GET_MODE (op
+  if (val_signbit_known_clear_p (GET_MODE (op),
+nonzero_bits (op, GET_MODE (op
return op;
 
   /* If operand is known to be only -1 or 0, convert ABS to NEG.  */
@@ -1615,6 +1614,24 @@ simplify_context::simplify_unary_operation_1 (rtx_code 
code, machine_mode mode,
}
}
 
+  /* We can canonicalize SIGN_EXTEND (op) as ZERO_EXTEND (op) when
+ we know the sign bit of OP must be clear.  */
+  if (val_signbit_known_clear_p (GET_MODE (op),
+nonzero_bits (op, GET_MODE (op
+   return simplify_gen_unary (ZERO_EXTEND, mode, op, GET_MODE (op));
+
+  /* (sign_extend:DI (subreg:SI (ctz:DI ...))) is (ctz:DI ...).  */
+  if (GET_CODE (op) == SUBREG
+ && subreg_lowpart_p (op)
+ && GET_MODE (SUBREG_REG (op)) == mode
+ && is_a  (mode, _mode)
+ && is_a  (GET_MODE (op), _mode)
+ && GET_MODE_PRECISION (int_mode) <= HOST_BITS_PER_WIDE_INT
+ && GET_MODE_PRECISION (op_mode) < GET_MODE_PRECISION (int_mode)
+ && (nonzero_bits (SUBREG_REG (op), mode)
+ & ~(GET_MODE_MASK (op_mode)>>1)) == 0)
+   return SUBREG_REG (op);
+
 #if defined(POINTERS_EXTEND_UNSIGNED)
   /* As we do not know which address space the pointer is referring to,
 we can do this only if the target does not support different pointer
@@ -1765,6 +1782,18 @@ simplify_context::simplify_unary_operation_1 (rtx_code 
code, machine_mode mode,
 op0_mode);
}
 
+  /* 

[PATCH Rust front-end v1 2/4] Add Rust lang TargetHooks for i386 and x86_64

[herron.philip--- via Gcc-patches]

From: Philip Herron 

This patch introduces a new set of interfaces to define the target info as
expected by the rust front-end. It takes advantage of the information
within gcc/config/target directories which gets called by the front-end
to populate rust front-end datastructures by calling into:
builtin_rust_info. This patch has been isolated to find if we are
approaching this in an idiomatic way and is compilable without the
rust-front-end code.

We have received many patches here which gives us the target hook info for
most platforms but getting the normal x86 done correctly will define if
the other patches are done correctly.

gcc/doc/ChangeLog:

* tm.texi.in: specifiy hooks for rust target info
* tm.texi: commit the generated documentation

gcc/ChangeLog:

* Makefile.in: add target to generate rust hooks
* config.gcc: add rust target interface to be compiled for i386
* genhooks.cc: generate rust target hooks
* configure: autoconf update
* configure.ac: add tm_rust_file_list and tm_rust_include_list

gcc/config/ChangeLog:

* default-rust.cc: new target hooks initializer for rust
* gnu.h: add new macro GNU_USER_TARGET_RUST_OS_INFO
* dragonfly.h: define TARGET_RUST_OS_INFO
* freebsd-spec.h: define FBSD_TARGET_RUST_OS_INFO
* freebsd.h: define guard for TARGET_RUST_OS_INFO
* fuchsia.h: define TARGET_RUST_OS_INFO
* kfreebsd-gnu.h: define GNU_USER_TARGET_RUST_OS_INFO
* kopensolaris-gnu.h: define GNU_USER_TARGET_RUST_OS_INFO
* linux-android.h: define ANDROID_TARGET_RUST_OS_INFO
* linux.h: define GNU_USER_TARGET_RUST_OS_INFO
* netbsd.h: define NETBSD_TARGET_RUST_OS_INFO
* openbsd.h: define OPENBSD_TARGET_RUST_OS_INFO
* phoenix.h: define TARGET_RUST_OS_INFO
* sol2.h: define TARGET_RUST_OS_INFO
* vxworks.h: define VXWORKS_TARGET_RUST_OS_INFO
* vxworksae.h: define VXWORKS_TARGET_RUST_OS_INFO

gcc/config/i386/ChangeLog:

* crtdll.h: define EXTRA_TARGET_RUST_OS_INFO
* cygming.h: define TARGET_RUST_OS_INFO
* cygwin.h: define EXTRA_TARGET_RUST_OS_INFO
* darwin.h: define TARGET_RUST_OS_INFO
* djgpp.h: likewise
* gnu-user-common.h: define TARGET_RUST_OS_INFO
* i386-protos.h: prototype for ix86_rust_target_cpu_info
* i386-rust.cc: new file to generate the rust target host info
* i386.h: define TARGET_RUST_CPU_INFO hook
* linux-common.h: define hooks for target info
* lynx.h: likewise
* mingw32.h: likewise
* netbsd-elf.h: likewise
* netbsd64.h: likewise
* nto.h: likewise
* openbsdelf.h: likewise
* rdos.h: likewise
* rtemself.h: likewise
* t-i386: add makefilke rule for i386-rust.cc
* vxworks.h: define TARGET_RUST_OS_INFO

gcc/rust/ChangeLog:

* rust-target-def.h: define the headers to access the hooks
* rust-target.def: define the hooks nessecary based on C90
* rust-target.h: define extern gcc_targetrustm

Co-authored-by: SimplyTheOther 
---
 gcc/Makefile.in   |  35 ++-
 gcc/config.gcc|  17 +
 gcc/config/default-rust.cc|  26 ++
 gcc/config/dragonfly.h|  12 +
 gcc/config/freebsd-spec.h |   9 +
 gcc/config/freebsd.h  |   5 +
 gcc/config/fuchsia.h  |  16 +
 gcc/config/gnu.h  |  12 +
 gcc/config/i386/crtdll.h  |  12 +
 gcc/config/i386/cygming.h |   5 +
 gcc/config/i386/cygwin.h  |  10 +
 gcc/config/i386/darwin.h  |  10 +
 gcc/config/i386/djgpp.h   |   9 +
 gcc/config/i386/gnu-user-common.h |   5 +
 gcc/config/i386/i386-protos.h |   3 +
 gcc/config/i386/i386-rust.cc  | 501 ++
 gcc/config/i386/i386.h|   3 +
 gcc/config/i386/linux-common.h|  17 +
 gcc/config/i386/lynx.h|   9 +
 gcc/config/i386/mingw32.h |   8 +
 gcc/config/i386/netbsd-elf.h  |   5 +
 gcc/config/i386/netbsd64.h|   5 +
 gcc/config/i386/nto.h |  12 +
 gcc/config/i386/openbsdelf.h  |   5 +
 gcc/config/i386/rdos.h|  11 +
 gcc/config/i386/rtemself.h|  10 +
 gcc/config/i386/t-i386|   4 +
 gcc/config/i386/vxworks.h |   5 +
 gcc/config/kfreebsd-gnu.h |   8 +
 gcc/config/kopensolaris-gnu.h |  12 +
 gcc/config/linux-android.h|  12 +
 gcc/config/linux.h|  14 +
 gcc/config/netbsd.h   |   9 +
 gcc/config/openbsd.h  |   8 +
 gcc/config/phoenix.h  |  12 +
 gcc/config/sol2.h |  10 +
 gcc/config/vxworks.h  |   8 +
 gcc/config/vxworksae.h|   9 +
 gcc/configure |  19 ++
 gcc/configure.ac  |  19 ++
 gcc/doc/tm.texi   |  17 +
 gcc/doc/tm.texi.in|   9 +
 

[PATCH Rust front-end v1 3/4] Add Rust target hooks to ARM

[herron.philip--- via Gcc-patches]

From: Philip Herron 

This adds the nessecary target hooks for the arm target.

gcc/ChangeLog:

* config.gcc: add rust_target_objs for arm

gcc/config/arm/ChangeLog:

* arm-protos.h: define arm_rust_target_cpu_info
* arm-rust.cc: new file to generate info
* arm.h: define TARGET_RUST_CPU_INFO
* bpabi.h: define TARGET_RUST_OS_INFO
* freebsd.h: likewise
* linux-eabi.h: likewise
* linux-elf.h: likewise
* netbsd-eabi.h: likewise
* netbsd-elf.h: likewise
* rtems.h: likewise
* symbian.h: likewise
* t-arm: compile arm-rust.cc
* uclinux-eabi.h: define TARGET_RUST_OS_INFO
* uclinux-elf.h: likewise
* vxworks.h: likewise

Co-authored-by: SimplyTheOther 
---
 gcc/config.gcc|   1 +
 gcc/config/arm/arm-protos.h   |   3 +
 gcc/config/arm/arm-rust.cc| 304 ++
 gcc/config/arm/arm.h  |   3 +
 gcc/config/arm/bpabi.h|  11 ++
 gcc/config/arm/freebsd.h  |   9 +
 gcc/config/arm/linux-eabi.h   |   8 +
 gcc/config/arm/linux-elf.h|   5 +
 gcc/config/arm/netbsd-eabi.h  |  10 ++
 gcc/config/arm/netbsd-elf.h   |   8 +
 gcc/config/arm/rtems.h|  14 ++
 gcc/config/arm/symbian.h  |  15 ++
 gcc/config/arm/t-arm  |   4 +
 gcc/config/arm/uclinux-eabi.h |  13 ++
 gcc/config/arm/uclinux-elf.h  |  12 ++
 gcc/config/arm/vxworks.h  |  14 ++
 16 files changed, 434 insertions(+)
 create mode 100644 gcc/config/arm/arm-rust.cc

diff --git a/gcc/config.gcc b/gcc/config.gcc
index cdd4fb4392a..9d686019b28 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -368,6 +368,7 @@ arm*-*-*)
c_target_objs="arm-c.o"
cxx_target_objs="arm-c.o"
d_target_objs="arm-d.o"
+rust_target_objs="arm-rust.o"
extra_options="${extra_options} arm/arm-tables.opt"
target_gtfiles="\$(srcdir)/config/arm/arm-builtins.cc 
\$(srcdir)/config/arm/arm-mve-builtins.h 
\$(srcdir)/config/arm/arm-mve-builtins.cc"
;;
diff --git a/gcc/config/arm/arm-protos.h b/gcc/config/arm/arm-protos.h
index f8aabbdae37..9513f96fdbc 100644
--- a/gcc/config/arm/arm-protos.h
+++ b/gcc/config/arm/arm-protos.h
@@ -406,6 +406,9 @@ extern void arm_cpu_cpp_builtins (struct cpp_reader *);
 extern void arm_d_target_versions (void);
 extern void arm_d_register_target_info (void);
 
+/* Defined in arm-rust.c  */
+extern void arm_rust_target_cpu_info (void);
+
 extern bool arm_is_constant_pool_ref (rtx);
 
 /* The bits in this mask specify which instruction scheduling options should
diff --git a/gcc/config/arm/arm-rust.cc b/gcc/config/arm/arm-rust.cc
new file mode 100644
index 000..7c83e3fa3a6
--- /dev/null
+++ b/gcc/config/arm/arm-rust.cc
@@ -0,0 +1,304 @@
+/* Subroutines for the Rust front end on the ARM architecture.
+   Copyright (C) 2020 Free Software Foundation, Inc.
+
+GCC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 3, or (at your option)
+any later version.
+
+GCC is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3.  If not see
+.  */
+
+#include "config.h"
+#include "system.h"
+#include "coretypes.h"
+#include "tm.h"
+#include "tm_p.h"
+#include "rust/rust-target.h"
+#include "rust/rust-target-def.h"
+
+/* Implement TARGET_RUST_CPU_INFO for ARM targets.  */
+
+void arm_rust_target_cpu_info(void) {
+rust_add_target_info("target_arch", "arm");
+
+/* TODO: further research support for CLREX, acquire-release (lda/ldaex), 
slow-fp-brcc (slow FP
+ * compare and branch), perfmon, trustzone, fpao, fuse-aes, fuse-literals, 
read-tp-hard, zcz,
+ * prof-unpr, slow-vgetlni32, slow-vdup32, prefer-vmovsr, prefer-ishst, 
muxed-units, slow-odd-reg,
+ * slow-load-D-subreg, wide-stride-vfp, dont-widen-vmovs, splat-vfp-neon, 
expand-fp-mlx,
+ * vmlx-hazards, neon-fpmovs, neonfp (as in using neon for scalar fp), 
vldn-align,
+ * nonpipelined-vfp, slowfpvmlx, slowfpvfmx, vmlx-forwarding, 32bit 
(prefer 32-bit Thumb),
+ * loop-align, mve1beat, mve2beat, mve4beat, avoid-partial-cpsr, 
cheap-predictable-cpsr,
+ * avoid-movs-shop, ret-addr-stack, no-branch-predictor, virtualization, 
nacl-trap, execute-only,
+ * reserve-r9, no-movt, no-neg-immediates, use-misched, 
disable-postra-scheduler, lob (Low
+ * Overhead Branch), noarm, cde - can't find them. */
+/* TODO: figure out if gcc has an equivalent to "fpregs" (floating-point 
registers even if only
+ * used for integer - shared between VFP and MVE).  */
+if (TARGET_VFPD32)
+

[PATCH Rust front-end v1 1/4] Add skeleton Rust front-end folder

[herron.philip--- via Gcc-patches]

From: Philip Herron 

This is a skeleton front-end which is used so we can ensure each patch is
buildable:

gcc/rust/ChangeLog:

* Make-lang.in
* config-lang.in
* lang-specs.h
* lang.opt
* rust-lang.cc
* rustspec.cc
---
 gcc/rust/Make-lang.in   | 308 +
 gcc/rust/config-lang.in |  30 
 gcc/rust/lang-specs.h   |  26 
 gcc/rust/lang.opt   |  45 ++
 gcc/rust/rust-lang.cc   | 332 
 gcc/rust/rustspec.cc| 285 ++
 6 files changed, 1026 insertions(+)
 create mode 100644 gcc/rust/Make-lang.in
 create mode 100644 gcc/rust/config-lang.in
 create mode 100644 gcc/rust/lang-specs.h
 create mode 100644 gcc/rust/lang.opt
 create mode 100644 gcc/rust/rust-lang.cc
 create mode 100644 gcc/rust/rustspec.cc

diff --git a/gcc/rust/Make-lang.in b/gcc/rust/Make-lang.in
new file mode 100644
index 000..759960544c8
--- /dev/null
+++ b/gcc/rust/Make-lang.in
@@ -0,0 +1,308 @@
+# Make-lang.in -- Top level -*- makefile -*- fragment for GCC Rust frontend.
+
+# Copyright (C) 2009-2022 Free Software Foundation, Inc.
+
+# This file is part of GCC.
+
+# GCC is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3, or (at your option)
+# any later version.
+
+# GCC is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+
+# You should have received a copy of the GNU General Public License
+# along with GCC; see the file COPYING3.  If not see
+# .
+
+# This file provides the language dependent support in the main Makefile.
+
+#RUST_EXES = rust
+
+# Use strict warnings for this front end.
+rust-warn = $(STRICT_WARN)
+
+# Installation name. Useful for cross compilers and used during install.
+GCCRS_INSTALL_NAME := $(shell echo gccrs|sed '$(program_transform_name)')
+GCCRS_TARGET_INSTALL_NAME := $(target_noncanonical)-$(shell echo gccrs|sed 
'$(program_transform_name)')
+
+# Define the names for selecting rust in LANGUAGES.
+rust: rust1$(exeext)
+
+# Tell GNU make to ignore files by these names if they exist.
+.PHONY: rust
+
+# removed GRS_CFLAGS from here
+
+CFLAGS-rust/rustspec.o += $(DRIVER_DEFINES)
+
+# Create the compiler driver gccrs.
+# A compiler driver is the program that interprets command argument and can be 
called from the command
+# line - e.g. gcc or g++, and not cc1, which is the actual compiler
+
+# Create driver objects
+GCCRS_D_OBJS = \
+   $(GCC_OBJS) \
+   rust/rustspec.o \
+   $(END)
+
+gccrs$(exeext): $(GCCRS_D_OBJS) $(EXTRA_GCC_OBJS) libcommon-target.a $(LIBDEPS)
+   +$(LINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) -o $@ \
+ $(GCCRS_D_OBJS) $(EXTRA_GCC_OBJS) libcommon-target.a \
+ $(EXTRA_GCC_LIBS) $(LIBS)
+
+# List of host object files used by the rust language - files for translation 
from the parse tree
+# to GENERIC
+# The compiler proper, not driver
+GRS_OBJS = \
+rust/rust-lang.o \
+$(END)
+# removed object files from here
+
+# All language-specific object files for Rust.
+RUST_ALL_OBJS = $(GRS_OBJS) $(RUST_TARGET_OBJS)
+
+rust_OBJS = $(RUST_ALL_OBJS) rust/rustspec.o
+
+# The compiler itself is called rust1 (formerly grs1)
+rust1$(exeext): $(RUST_ALL_OBJS) attribs.o $(BACKEND) $(LIBDEPS)
+   +$(LLINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) -o $@ \
+ $(RUST_ALL_OBJS) attribs.o $(BACKEND) $(LIBS) $(BACKENDLIBS)
+
+# Build hooks.
+
+lang_checks += check-rust
+lang_checks_parallelized += check-rust
+check_rust_parallelize = 10
+
+# Copies its dependencies into the source directory. This generally should be 
used for generated files
+# such as Bison output files which are not version-controlled, but should be 
included in any release
+# tarballs. This target will be executed during a bootstrap if 
‘--enable-generated-files-in-srcdir’
+# was specified as a configure option.
+rust.srcextra:
+
+rust.all.cross: gccrs$(exeext)
+
+# idk what this does but someone used it
+rust.start.encap: gccrs$(exeext)
+rust.rest.encap:
+
+# Build generated man pages for the front end from Texinfo manuals (see Man 
Page Generation), in the
+# build directory. This target is only called if the necessary tools are 
available, but should ignore
+# errors so as not to stop the build if errors occur; man pages are optional 
and the tools involved
+# may be installed in a broken way.
+rust.man:
+
+# Copies its dependencies into the source directory. These targets will be 
executed during a bootstrap
+# if ‘--enable-generated-files-in-srcdir’ was specified as a configure option.
+rust.srcman:
+
+# Clean hooks.
+
+rust.mostlyclean:
+#  cd $(srcdir)/rust; rm -f *.o y.tab.h y.tab.c lex.yy.c
+
+rust.clean: 

Rust frontend patches v1

[herron.philip--- via Gcc-patches]

This is the initial version 1 patch set for the Rust front-end. There are more 
changes that need to be extracted out for all the target hooks we have 
implemented. The goal is to see if we are implementing the target hooks 
information for x86 and arm. We have more patches for the other targets I can 
add in here but they all follow the pattern established here.

Each patch is buildable on its own and rebased ontop of 
718cf8d0bd32689192200d2156722167fd21a647. As for ensuring we keep attribution 
for all the patches we have received in the front-end should we create a 
CONTRIBUTOR's file inside the front-end folder?

Note thanks to Thomas Schwinge and Mark Wielaard, we are keeping a branch up to 
date with our code on: 
https://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/devel/rust/master 
but this is not rebased ontop of gcc head.

Let me know if I have sent these patches correctly or not, this is a learning 
experience with git send-email.

[PATCH Rust front-end v1 1/4] Add skeleton Rust front-end folder
[PATCH Rust front-end v1 2/4] Add Rust lang TargetHooks for i386 and
[PATCH Rust front-end v1 3/4] Add Rust target hooks to ARM
[PATCH Rust front-end v1 4/4] Add Rust front-end and associated

[Bug rtl-optimization/106187] armhf: Miscompilation at O2 level (O0 / O1 are working)

[rearnsha at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #47 from Richard Earnshaw  ---
Created attachment 53361
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53361=edit
Possible patch

A slightly more thorough attempt to avoid the problem by detecting when the
alias sets are known to conflict.  We track through the list of same values
that CSELIB has recorded to find one that writes the same location (because the
addresses are considered equal).

Re: Re: [PATCH 1/1] Fix bit-position comparison

[钟居哲]

Thank you for your reply. I am gonna try another to implement the fractional 
vector spilling of RVV in RISC-V backend. 
If this patch is really having a bad impact on other targets. I think this 
patch may needs to be abandon.




juzhe.zh...@rivai.ai
 
From: Richard Sandiford
Date: 2022-07-27 20:47
To: Richard Biener
CC: zhongjuzhe; gcc-patches; richard.earnshaw; jakub; kenner; jlaw; gnu; jason; 
davem; joseph; bernds_cb1; ian; wilson
Subject: Re: [PATCH 1/1] Fix bit-position comparison
Richard Biener  writes:
> On Wed, 27 Jul 2022, juzhe.zh...@rivai.ai wrote:
>
>> From: zhongjuzhe 
>> 
>> gcc/ChangeLog:
>> 
>> * expr.cc (expand_assignment): Change GET_MODE_PRECISION to 
>> GET_MODE_BITSIZE
>> 
>> ---
>>  gcc/expr.cc | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/gcc/expr.cc b/gcc/expr.cc
>> index 80bb1b8a4c5..ac2b3c07df6 100644
>> --- a/gcc/expr.cc
>> +++ b/gcc/expr.cc
>> @@ -5574,7 +5574,7 @@ expand_assignment (tree to, tree from, bool 
>> nontemporal)
>>  code contains an out-of-bounds access to a small array.  */
>>if (!MEM_P (to_rtx)
>>&& GET_MODE (to_rtx) != BLKmode
>> -   && known_ge (bitpos, GET_MODE_PRECISION (GET_MODE (to_rtx
>> +   && known_ge (bitpos, GET_MODE_BITSIZE (GET_MODE (to_rtx
>
> I think this has the chance to go wrong with regard to endianess.
> Consider to_rtx with 32bit mode size but 12bit mode precision.  bitpos
> is relative to the start of to_rtx as if it were in memory and bitsize
> determines the contiguous region affected.  But since we are actually
> storing into a non-memory endianess comes into play.
 
Not sure I follow the code well enough to comment, but: this condition
is saying when we can drop the assignment on the floor and just expand
the rhs (for side effects).  From that point of view, using bitsize
should be more conservative than using precision, since bitsize is
always >= precision.
 
Thanks,
Richard
 
>
> So no, I don't think the patch is correct, it would be way more
> complicated to get the desired improvement.
>
> Richard.
>
>>  {
>>expand_normal (from);
>>result = NULL;
>> 
 

Re: [PATCH] LoongArch: document -m[no-]explicit-relocs

[Xi Ruoyao via Gcc-patches]

On Wed, 2022-07-27 at 17:57 +0800, WANG Xuerui wrote:
> On 2022/7/27 17:28, Lulu Cheng wrote:
> > 
> > 
> > 在 2022/7/27 下午5:15, Xi Ruoyao 写道:
> > > On Wed, 2022-07-27 at 16:47 +0800, Lulu Cheng wrote:
> > > 
> > > > >   "Use or do not use assembler relocation operators when dealing with
> > > > > symbolic addresses. The alternative is to use assembler macros
> > > > > instead, which may limit optimization.
> > > > >   
> > > > >   The default value for the option is determined during GCC build-
> > > > > time by detecting corresponding assembler support: @code{-mexplicit-
> > > > > relocs} if said support is present, @code{-mno-explicit-relocs}
> > > > > otherwise. This option is mostly useful for debugging, or
> > > > > interoperation with assemblers different from the build-time one."
> > > > >   
> > > > I agree with wangxuerui's idea.
> > > > The same parameter and the same description information can reduce the
> > > > user's time to learn how to use this parameter.
> > > I agree it's better than my origin paragraph.
> > > 
> > > If you agree I'll commit it with Xuerui as the commit author.
> > > 
> > 
> > I have no opinion if wangxuerui agrees.
> Either is OK (if you really think the commit is effectively rewritten by 
> me), thanks.

Pushed r13-1859.

-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

Re: Re: [PATCH 1/1] Fix bit-position comparison

[钟居哲]

After consideration. Maybe I can try another solution. I aggree with you that 
it is not good idea that fake the BYTESIZE of vint8mf2_t and let GCC think it 
is a full vector.  I think the best way is let GCC understand the real size of 
'vint8mf2_t' as a half of a vector and then RISC-V backend insert vsetvli after 
RA (register allocation) so that it will not enlarge the spill size. Thank you 
so much.



juzhe.zh...@rivai.ai
 
From: Richard Biener
Date: 2022-07-27 20:56
To: juzhe.zh...@rivai.ai
CC: gcc-patches; vmakarov
Subject: Re: Re: [PATCH 1/1] Fix bit-position comparison
On Wed, 27 Jul 2022, juzhe.zh...@rivai.ai wrote:
 
> For vint8m1_t: 
>VECTOR_MODES_WITH_PREFIX (VNx, INT, 16, 0)
> ADJUST_NUNITS (VNx16QI, riscv_vector_chunks * 8);
> ADJUST_BYTES (VNx16QI, riscv_vector_chunks * 8);
> For vint8mf2_t: 
>VECTOR_MODES_WITH_PREFIX (VNx, INT, 8, 0)
> ADJUST_NUNITS (VNx8QI, riscv_vector_chunks * 4);
> ADJUST_BYTES (VNx16QI, riscv_vector_chunks * 8);
 
^^^
 
ADJUST_BYTES (VNx8QI, riscv_vector_chunks * 8);
 
probably.  As said, I'm not sure this is a good idea just for the sake
of spill slots.  Maybe there's a mode_for_spill one could use and
spill a paradoxical subreg of that mode ... (don't search for
mode_for_spill, I just made that up).
 
Maybe you can somehow forbit spilling of vint8mf2_t and instead
define spill_class for those so they spill first to vint8m1_t
and then those get spilled to the stack?
 
> riscv_vector_chunks is a compile-time unknown poly value, I use ADJUST_BYTES 
> to specify these 2 machine_modes 
> with same bytesize but different element number.
> This way can tell GCC that vint8mf2_t has half element nunber of vint8m1_t 
> but occupy the same size during the register spilling.
> 
> May be we can add a new function that call ADJUST_PRECISION that I can 
> adjust these two precision?
> I am not sure. I am look forward another solution to deal with this issuse. 
> Thank you so much.
> 
> 
> 
> juzhe.zh...@rivai.ai
>  
> From: Richard Biener
> Date: 2022-07-27 16:12
> To: juzhe.zh...@rivai.ai
> CC: gcc-patches
> Subject: Re: Re: [PATCH 1/1] Fix bit-position comparison
> On Wed, 27 Jul 2022, juzhe.zh...@rivai.ai wrote:
>  
> > Let's take look at these 2 cases: https://godbolt.org/z/zP16frPnb. In 
> > RVV, we have vle8 and vsetvli to specify loading vint8mf2 (vsetvli a1, 
> > zero + vle8.v). You can see it in foo function.  In this case we don't 
> > need to confuse compiler the size of vint8mf2. However, The second case 
> > is I write assembly to occupy the vector register to generate register 
> > spilling cases. You can see LLVM implementation:  First use vsetvli + 
> > vle8.v load (vint8mf2_t) data from the base pointer, then spill the 
> > vector to memory using vs1r (this is the whole register store which 
> > store the whole vector to the memory and then use vl1r load the whole 
> > register and finally return it.  In LLVM implementation, it insert 
> > vsetvli instructions for RVV instruction using LLVM PASS before RA 
> > (register allocation).  So after RA, compiler generate the spilling 
> > loads/stores. We can either choose to use vsetvli + vle/vse (load/store 
> > fractional vector) or vl1r/vs1r (load/store whole vector which enlarge 
> > the spill size).
> > 
> > Because implementing insert vsetvli PASS after RA (register allocation) 
> > is so complicated, LLVM choose to use vl1r/vs1r. Frankly, I implement 
> > RVV GCC reference to LLVM. So that why I want to define the machine_mode 
> > for `vint8mf2` with smaller element-size but same byte-size from 
> > `vint8m1'.
>  
> The LLVM strathegy might not be the best one for GCC.  I still don't
> quite understand what issue you face with the code you try to patch.
> How does the machmode.def portion of the port look like for
> vint8m1 and vint8mf2?  What are the corresponding modes?
>  
> > Thank you for your reply.  
> > 
> > 
> > 
> > juzhe.zh...@rivai.ai
> >  
> > From: Richard Biener
> > Date: 2022-07-27 15:35
> > To: juzhe.zh...@rivai.ai
> > CC: gcc-patches
> > Subject: Re: Re: [PATCH 1/1] Fix bit-position comparison
> > On Wed, 27 Jul 2022, juzhe.zh...@rivai.ai wrote:
> >  
> > > Thank you so much for the fast reply. Ok, it is true that I didn't think 
> > > about it carefully. Can you help me with the following the issue?
> > > 
> > > For RVV (RISC-V 'V' Extension), we have full vector type 'vint8m1_t' 
> > > (LMUL = 1) and fractional vector type 'vint8mf2_t' (LMUL = 1/2).
> >  
> > Can you explain in terms of GCCs generic vectors what vint8m1_t and
> > vint8mf2_t are?
> >  
> > > Because in the ISA, we don't have whole register load/store for 
> > > fractional vector. I reference the LLVM implementation and I adjust 
> > > BITSIZE of 
> > > fractional vector same as full vector (It will confuse GCC the bytesize 
> > > of fractional vector and consider the spill size of a fractional vector 
> > > is same as LMUL = 1) 
> > > so that I can use whole register load/store directly during the register 
> > >