[PATCH v4] LoongArch: Add support code model extreme.
v1 -> v2:
- Modify some description information.
- Add options -W[no]extreme-plt, warn about code model extreme not support plt
mode,
and then disable plt.
v2 -> v3:
- When -mcmodel=extreme, default set to -fno-plt mode, if the user forces to use
'-mcmodel=extreme -fplt', an error will be reported.
- Delete -Wextreme-plt.
- Fix bug when compiling with '-mcmodel=normal -fno-plt -mno-explicit-relocs'.
v3 -> v4:
- Fix the bug of loongarch_tls_symbol function loading in function
loongarch_call_tls_get_addr.
Use five instructions to calculate a signed 64-bit offset relative to the pc.
gcc/ChangeLog:
* config/loongarch/loongarch-opts.cc: Allow cmodel to be extreme.
* config/loongarch/loongarch.cc (loongarch_call_tls_get_addr):
Add extreme support for TLS GD and LD types.
(loongarch_legitimize_tls_address): Add extreme support for TLS LE
and IE.
(loongarch_split_symbol): When compiling with -mcmodel=extreme,
the symbol address will be obtained through five instructions.
(loongarch_print_operand_reloc): Add support.
(loongarch_print_operand): Add support.
(loongarch_print_operand_address): Add support.
(loongarch_option_override_internal): Set '-mcmodel=extreme' option
incompatible with '-mno-explicit-relocs'.
* config/loongarch/loongarch.md (@lui_l_hi20):
Loads bits 12-31 of data into registers.
(lui_h_lo20): Load bits 32-51 of the data and spell bits 0-31 of
the source register.
(lui_h_hi12): Load bits 52-63 of the data and spell bits 0-51 of
the source register.
* config/loongarch/predicates.md: Symbols need to be decomposed
when defining the macro TARGET_CMODEL_EXTREME
* doc/invoke.texi: Modify the description information of cmodel in the
document.
Document -W[no-]extreme-plt.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/func-call-1.c: Add option '-mcmodel=normal'.
* gcc.target/loongarch/func-call-2.c: Likewise.
* gcc.target/loongarch/func-call-3.c: Likewise.
* gcc.target/loongarch/func-call-4.c: Likewise.
* gcc.target/loongarch/func-call-5.c: Likewise.
* gcc.target/loongarch/func-call-6.c: Likewise.
* gcc.target/loongarch/func-call-7.c: Likewise.
* gcc.target/loongarch/func-call-8.c: Likewise.
* gcc.target/loongarch/relocs-symbol-noaddend.c: Likewise.
* gcc.target/loongarch/func-call-extreme-1.c: New test.
* gcc.target/loongarch/func-call-extreme-2.c: New test.
---
gcc/config/loongarch/loongarch-opts.cc| 3 +-
gcc/config/loongarch/loongarch.cc | 222 +++---
gcc/config/loongarch/loongarch.md | 34 ++-
gcc/config/loongarch/predicates.md| 9 +-
gcc/doc/invoke.texi | 50 +---
.../gcc.target/loongarch/func-call-1.c| 2 +-
.../gcc.target/loongarch/func-call-2.c| 2 +-
.../gcc.target/loongarch/func-call-3.c| 2 +-
.../gcc.target/loongarch/func-call-4.c| 2 +-
.../gcc.target/loongarch/func-call-5.c| 2 +-
.../gcc.target/loongarch/func-call-6.c| 2 +-
.../gcc.target/loongarch/func-call-7.c| 2 +-
.../gcc.target/loongarch/func-call-8.c| 2 +-
.../loongarch/func-call-extreme-1.c | 32 +++
.../loongarch/func-call-extreme-2.c | 32 +++
.../loongarch/relocs-symbol-noaddend.c| 2 +-
16 files changed, 318 insertions(+), 82 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/loongarch/func-call-extreme-1.c
create mode 100644 gcc/testsuite/gcc.target/loongarch/func-call-extreme-2.c
diff --git a/gcc/config/loongarch/loongarch-opts.cc
b/gcc/config/loongarch/loongarch-opts.cc
index 3f70943ded6..2ae89f23443 100644
--- a/gcc/config/loongarch/loongarch-opts.cc
+++ b/gcc/config/loongarch/loongarch-opts.cc
@@ -376,14 +376,13 @@ fallback:
/* 5. Target code model */
t.cmodel = constrained.cmodel ? opt_cmodel : CMODEL_NORMAL;
- if (t.cmodel != CMODEL_NORMAL)
+ if (t.cmodel != CMODEL_NORMAL && t.cmodel != CMODEL_EXTREME)
{
warning (0, "%qs is not supported, now cmodel is set to %qs",
loongarch_cmodel_strings[t.cmodel], "normal");
t.cmodel = CMODEL_NORMAL;
}
-
/* Cleanup and return. */
obstack_free (&msg_obstack, NULL);
*target = t;
diff --git a/gcc/config/loongarch/loongarch.cc
b/gcc/config/loongarch/loongarch.cc
index 24378143641..207ac2762c6 100644
--- a/gcc/config/loongarch/loongarch.cc
+++ b/gcc/config/loongarch/loongarch.cc
@@ -2436,7 +2436,19 @@ loongarch_call_tls_get_addr (rtx sym, enum
loongarch_symbol_type type, rtx v0)
/* Split tls symbol to high and low. */
rtx high = gen_rtx_HIGH (Pmode, copy_rtx (loc));
high = loongarch_force_temporary (tmp, high);
- emit_insn (gen_tls_low (Pmode, a0
[PATCH] fortran: Drop -static-lib{gfortran,quadmath} from f951 [PR46539]
Hi!
As discussed earlier, all other -static-lib* options are Driver only,
these 2 are Driver in common.opt and Fortran in lang.opt.
The spec files never pass the -static-lib* options down to any compiler
(f951 etc.), so the 2 errors below are reported only when one
runs ./f951 -static-libgfortran by hand.
The following patch just removes f951 support of these options, the
gfortran driver behavior remains as before. For other -static-lib*
option (and even these because it is never passed to f951) we never
error if we can't support those options, and e.g. Darwin is actually
able to handle those options through other means.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2022-08-20 Jakub Jelinek
PR fortran/46539
* lang.opt (static-libgfortran, static-libquadmath): Change Fortran
to Driver.
* options.cc (gfc_handle_option): Don't handle OPT_static_libgfortran
nor OPT_static_libquadmath here.
--- gcc/fortran/lang.opt.jj 2022-08-17 17:00:28.558530108 +0200
+++ gcc/fortran/lang.opt2022-08-19 18:09:23.505859992 +0200
@@ -860,11 +860,11 @@ Fortran Joined Separate
; Documented in common.opt
static-libgfortran
-Fortran
+Driver
Statically link the GNU Fortran helper library (libgfortran).
static-libquadmath
-Fortran
+Driver
Statically link the GCC Quad-Precision Math Library (libquadmath).
std=f2003
--- gcc/fortran/options.cc.jj 2022-08-17 17:00:28.559530096 +0200
+++ gcc/fortran/options.cc 2022-08-19 18:05:32.153797148 +0200
@@ -685,20 +685,6 @@ gfc_handle_option (size_t scode, const c
gfc_option.source_form = FORM_FREE;
break;
-case OPT_static_libgfortran:
-#ifndef HAVE_LD_STATIC_DYNAMIC
- gfc_fatal_error ("%<-static-libgfortran%> is not supported in this "
- "configuration");
-#endif
- break;
-
-case OPT_static_libquadmath:
-#ifndef HAVE_LD_STATIC_DYNAMIC
- gfc_fatal_error ("%<-static-libquadmath%> is not supported in this "
- "configuration");
-#endif
- break;
-
case OPT_fintrinsic_modules_path:
case OPT_fintrinsic_modules_path_:
Jakub
Re: [commited PATCH v4] LoongArch: Add support code model extreme.
Pushd to r13-2128.
在 2022/8/20 下午4:39, Lulu Cheng 写道:
v1 -> v2:
- Modify some description information.
- Add options -W[no]extreme-plt, warn about code model extreme not support plt
mode,
and then disable plt.
v2 -> v3:
- When -mcmodel=extreme, default set to -fno-plt mode, if the user forces to use
'-mcmodel=extreme -fplt', an error will be reported.
- Delete -Wextreme-plt.
- Fix bug when compiling with '-mcmodel=normal -fno-plt -mno-explicit-relocs'.
v3 -> v4:
- Fix the bug of loongarch_tls_symbol function loading in function
loongarch_call_tls_get_addr.
Use five instructions to calculate a signed 64-bit offset relative to the pc.
gcc/ChangeLog:
* config/loongarch/loongarch-opts.cc: Allow cmodel to be extreme.
* config/loongarch/loongarch.cc (loongarch_call_tls_get_addr):
Add extreme support for TLS GD and LD types.
(loongarch_legitimize_tls_address): Add extreme support for TLS LE
and IE.
(loongarch_split_symbol): When compiling with -mcmodel=extreme,
the symbol address will be obtained through five instructions.
(loongarch_print_operand_reloc): Add support.
(loongarch_print_operand): Add support.
(loongarch_print_operand_address): Add support.
(loongarch_option_override_internal): Set '-mcmodel=extreme' option
incompatible with '-mno-explicit-relocs'.
* config/loongarch/loongarch.md (@lui_l_hi20):
Loads bits 12-31 of data into registers.
(lui_h_lo20): Load bits 32-51 of the data and spell bits 0-31 of
the source register.
(lui_h_hi12): Load bits 52-63 of the data and spell bits 0-51 of
the source register.
* config/loongarch/predicates.md: Symbols need to be decomposed
when defining the macro TARGET_CMODEL_EXTREME
* doc/invoke.texi: Modify the description information of cmodel in the
document.
Document -W[no-]extreme-plt.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/func-call-1.c: Add option '-mcmodel=normal'.
* gcc.target/loongarch/func-call-2.c: Likewise.
* gcc.target/loongarch/func-call-3.c: Likewise.
* gcc.target/loongarch/func-call-4.c: Likewise.
* gcc.target/loongarch/func-call-5.c: Likewise.
* gcc.target/loongarch/func-call-6.c: Likewise.
* gcc.target/loongarch/func-call-7.c: Likewise.
* gcc.target/loongarch/func-call-8.c: Likewise.
* gcc.target/loongarch/relocs-symbol-noaddend.c: Likewise.
* gcc.target/loongarch/func-call-extreme-1.c: New test.
* gcc.target/loongarch/func-call-extreme-2.c: New test.
---
gcc/config/loongarch/loongarch-opts.cc| 3 +-
gcc/config/loongarch/loongarch.cc | 222 +++---
gcc/config/loongarch/loongarch.md | 34 ++-
gcc/config/loongarch/predicates.md| 9 +-
gcc/doc/invoke.texi | 50 +---
.../gcc.target/loongarch/func-call-1.c| 2 +-
.../gcc.target/loongarch/func-call-2.c| 2 +-
.../gcc.target/loongarch/func-call-3.c| 2 +-
.../gcc.target/loongarch/func-call-4.c| 2 +-
.../gcc.target/loongarch/func-call-5.c| 2 +-
.../gcc.target/loongarch/func-call-6.c| 2 +-
.../gcc.target/loongarch/func-call-7.c| 2 +-
.../gcc.target/loongarch/func-call-8.c| 2 +-
.../loongarch/func-call-extreme-1.c | 32 +++
.../loongarch/func-call-extreme-2.c | 32 +++
.../loongarch/relocs-symbol-noaddend.c| 2 +-
16 files changed, 318 insertions(+), 82 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/loongarch/func-call-extreme-1.c
create mode 100644 gcc/testsuite/gcc.target/loongarch/func-call-extreme-2.c
diff --git a/gcc/config/loongarch/loongarch-opts.cc
b/gcc/config/loongarch/loongarch-opts.cc
index 3f70943ded6..2ae89f23443 100644
--- a/gcc/config/loongarch/loongarch-opts.cc
+++ b/gcc/config/loongarch/loongarch-opts.cc
@@ -376,14 +376,13 @@ fallback:
/* 5. Target code model */
t.cmodel = constrained.cmodel ? opt_cmodel : CMODEL_NORMAL;
- if (t.cmodel != CMODEL_NORMAL)
+ if (t.cmodel != CMODEL_NORMAL && t.cmodel != CMODEL_EXTREME)
{
warning (0, "%qs is not supported, now cmodel is set to %qs",
loongarch_cmodel_strings[t.cmodel], "normal");
t.cmodel = CMODEL_NORMAL;
}
-
/* Cleanup and return. */
obstack_free (&msg_obstack, NULL);
*target = t;
diff --git a/gcc/config/loongarch/loongarch.cc
b/gcc/config/loongarch/loongarch.cc
index 24378143641..207ac2762c6 100644
--- a/gcc/config/loongarch/loongarch.cc
+++ b/gcc/config/loongarch/loongarch.cc
@@ -2436,7 +2436,19 @@ loongarch_call_tls_get_addr (rtx sym, enum
loongarch_symbol_type type, rtx v0)
/* Split tls symbol to high and low. */
rtx high = gen_rtx_HIGH (Pmode, copy_rtx (loc));
[PATCH v1] LoongArch: Add new code model 'emdium'.
The function jump instruction in normal mode is 'bl', so the scope of the function jump is +-128MB. Now we've added support for 'medium' mode, this mode is to complete the function jump through two instructions: pcalau12i + jirl So in this mode the function jump range is increased to +-2GB. Compared with 'normal' mode, 'medium' mode only affects the jump range of functions. gcc/ChangeLog: * config/loongarch/genopts/loongarch-strings: Support code model medium. * config/loongarch/genopts/loongarch.opt.in: Likewise. * config/loongarch/loongarch-def.c: Likewise. * config/loongarch/loongarch-def.h (CMODEL_LARGE): Likewise. (CMODEL_EXTREME): Likewise. (N_CMODEL_TYPES): Likewise. (CMODEL_MEDIUM): Likewise. * config/loongarch/loongarch-opts.cc: Likewise. * config/loongarch/loongarch-opts.h (TARGET_CMODEL_MEDIUM): Likewise. * config/loongarch/loongarch-str.h (STR_CMODEL_MEDIUM): Likewise. * config/loongarch/loongarch.cc (loongarch_call_tls_get_addr): Tls symbol Loading support medium mode. (loongarch_legitimize_call_address): When medium mode, make a symbolic jump with two instructions. (loongarch_option_override_internal): Support medium. * config/loongarch/loongarch.md (@pcalau12i): New template. (@sibcall_internal_1): New function call templates added to support medium mode. (@sibcall_value_internal_1): Likewise. (@sibcall_value_multiple_internal_1): Likewise. (@call_internal_1): Likewise. (@call_value_internal_1): Likewise. (@call_value_multiple_internal_1): Likewise. * config/loongarch/loongarch.opt: Support medium. * config/loongarch/predicates.md: Add processing about medium mode. * doc/invoke.texi: Document for '-mcmodel=medium'. gcc/testsuite/ChangeLog: * gcc.target/loongarch/func-call-medium-1.c: New test. * gcc.target/loongarch/func-call-medium-2.c: New test. * gcc.target/loongarch/func-call-medium-3.c: New test. * gcc.target/loongarch/func-call-medium-4.c: New test. * gcc.target/loongarch/func-call-medium-5.c: New test. * gcc.target/loongarch/func-call-medium-6.c: New test. * gcc.target/loongarch/func-call-medium-7.c: New test. * gcc.target/loongarch/func-call-medium-8.c: New test. * gcc.target/loongarch/tls-gd-noplt.c: Add compile parameter '-mexplicit-relocs'. --- .../loongarch/genopts/loongarch-strings | 1 + gcc/config/loongarch/genopts/loongarch.opt.in | 3 + gcc/config/loongarch/loongarch-def.c | 1 + gcc/config/loongarch/loongarch-def.h | 7 +- gcc/config/loongarch/loongarch-opts.cc| 15 ++- gcc/config/loongarch/loongarch-opts.h | 1 + gcc/config/loongarch/loongarch-str.h | 1 + gcc/config/loongarch/loongarch.cc | 123 + gcc/config/loongarch/loongarch.md | 125 +- gcc/config/loongarch/loongarch.opt| 3 + gcc/config/loongarch/predicates.md| 15 ++- gcc/doc/invoke.texi | 3 + .../gcc.target/loongarch/func-call-medium-1.c | 41 ++ .../gcc.target/loongarch/func-call-medium-2.c | 41 ++ .../gcc.target/loongarch/func-call-medium-3.c | 41 ++ .../gcc.target/loongarch/func-call-medium-4.c | 41 ++ .../gcc.target/loongarch/func-call-medium-5.c | 42 ++ .../gcc.target/loongarch/func-call-medium-6.c | 42 ++ .../gcc.target/loongarch/func-call-medium-7.c | 43 ++ .../gcc.target/loongarch/func-call-medium-8.c | 42 ++ .../gcc.target/loongarch/tls-gd-noplt.c | 4 +- 21 files changed, 595 insertions(+), 40 deletions(-) create mode 100644 gcc/testsuite/gcc.target/loongarch/func-call-medium-1.c create mode 100644 gcc/testsuite/gcc.target/loongarch/func-call-medium-2.c create mode 100644 gcc/testsuite/gcc.target/loongarch/func-call-medium-3.c create mode 100644 gcc/testsuite/gcc.target/loongarch/func-call-medium-4.c create mode 100644 gcc/testsuite/gcc.target/loongarch/func-call-medium-5.c create mode 100644 gcc/testsuite/gcc.target/loongarch/func-call-medium-6.c create mode 100644 gcc/testsuite/gcc.target/loongarch/func-call-medium-7.c create mode 100644 gcc/testsuite/gcc.target/loongarch/func-call-medium-8.c diff --git a/gcc/config/loongarch/genopts/loongarch-strings b/gcc/config/loongarch/genopts/loongarch-strings index cb88ed56b68..44ebb7ab10b 100644 --- a/gcc/config/loongarch/genopts/loongarch-strings +++ b/gcc/config/loongarch/genopts/loongarch-strings @@ -54,5 +54,6 @@ OPTSTR_CMODEL cmodel STR_CMODEL_NORMAL normal STR_CMODEL_TINY tiny STR_CMODEL_TStiny-static +STR_CMODEL_MEDIUM medium STR_CMODEL_LARGE large STR_CMODEL_EXTREMEextreme diff --git a/gcc/config/loongarch/genopts/loongarch.opt.in b/gcc/config/loongarch/genopts/loongarch.opt.in i
Re: [PATCH v1] LoongArch: Add new code model 'emdium'.
Hi, Lulu, I think there is a typo in your subject line. Huacai On Sat, Aug 20, 2022 at 5:05 PM Lulu Cheng wrote: > > The function jump instruction in normal mode is 'bl', > so the scope of the function jump is +-128MB. > > Now we've added support for 'medium' mode, this mode is > to complete the function jump through two instructions: > pcalau12i + jirl > So in this mode the function jump range is increased to +-2GB. > > Compared with 'normal' mode, 'medium' mode only affects the > jump range of functions. > > gcc/ChangeLog: > > * config/loongarch/genopts/loongarch-strings: Support code model > medium. > * config/loongarch/genopts/loongarch.opt.in: Likewise. > * config/loongarch/loongarch-def.c: Likewise. > * config/loongarch/loongarch-def.h (CMODEL_LARGE): Likewise. > (CMODEL_EXTREME): Likewise. > (N_CMODEL_TYPES): Likewise. > (CMODEL_MEDIUM): Likewise. > * config/loongarch/loongarch-opts.cc: Likewise. > * config/loongarch/loongarch-opts.h (TARGET_CMODEL_MEDIUM): Likewise. > * config/loongarch/loongarch-str.h (STR_CMODEL_MEDIUM): Likewise. > * config/loongarch/loongarch.cc (loongarch_call_tls_get_addr): > Tls symbol Loading support medium mode. > (loongarch_legitimize_call_address): When medium mode, make a symbolic > jump with two instructions. > (loongarch_option_override_internal): Support medium. > * config/loongarch/loongarch.md (@pcalau12i): New template. > (@sibcall_internal_1): New function call templates added to > support > medium mode. > (@sibcall_value_internal_1): Likewise. > (@sibcall_value_multiple_internal_1): Likewise. > (@call_internal_1): Likewise. > (@call_value_internal_1): Likewise. > (@call_value_multiple_internal_1): Likewise. > * config/loongarch/loongarch.opt: Support medium. > * config/loongarch/predicates.md: Add processing about medium mode. > * doc/invoke.texi: Document for '-mcmodel=medium'. > > gcc/testsuite/ChangeLog: > > * gcc.target/loongarch/func-call-medium-1.c: New test. > * gcc.target/loongarch/func-call-medium-2.c: New test. > * gcc.target/loongarch/func-call-medium-3.c: New test. > * gcc.target/loongarch/func-call-medium-4.c: New test. > * gcc.target/loongarch/func-call-medium-5.c: New test. > * gcc.target/loongarch/func-call-medium-6.c: New test. > * gcc.target/loongarch/func-call-medium-7.c: New test. > * gcc.target/loongarch/func-call-medium-8.c: New test. > * gcc.target/loongarch/tls-gd-noplt.c: Add compile parameter > '-mexplicit-relocs'. > --- > .../loongarch/genopts/loongarch-strings | 1 + > gcc/config/loongarch/genopts/loongarch.opt.in | 3 + > gcc/config/loongarch/loongarch-def.c | 1 + > gcc/config/loongarch/loongarch-def.h | 7 +- > gcc/config/loongarch/loongarch-opts.cc| 15 ++- > gcc/config/loongarch/loongarch-opts.h | 1 + > gcc/config/loongarch/loongarch-str.h | 1 + > gcc/config/loongarch/loongarch.cc | 123 + > gcc/config/loongarch/loongarch.md | 125 +- > gcc/config/loongarch/loongarch.opt| 3 + > gcc/config/loongarch/predicates.md| 15 ++- > gcc/doc/invoke.texi | 3 + > .../gcc.target/loongarch/func-call-medium-1.c | 41 ++ > .../gcc.target/loongarch/func-call-medium-2.c | 41 ++ > .../gcc.target/loongarch/func-call-medium-3.c | 41 ++ > .../gcc.target/loongarch/func-call-medium-4.c | 41 ++ > .../gcc.target/loongarch/func-call-medium-5.c | 42 ++ > .../gcc.target/loongarch/func-call-medium-6.c | 42 ++ > .../gcc.target/loongarch/func-call-medium-7.c | 43 ++ > .../gcc.target/loongarch/func-call-medium-8.c | 42 ++ > .../gcc.target/loongarch/tls-gd-noplt.c | 4 +- > 21 files changed, 595 insertions(+), 40 deletions(-) > create mode 100644 gcc/testsuite/gcc.target/loongarch/func-call-medium-1.c > create mode 100644 gcc/testsuite/gcc.target/loongarch/func-call-medium-2.c > create mode 100644 gcc/testsuite/gcc.target/loongarch/func-call-medium-3.c > create mode 100644 gcc/testsuite/gcc.target/loongarch/func-call-medium-4.c > create mode 100644 gcc/testsuite/gcc.target/loongarch/func-call-medium-5.c > create mode 100644 gcc/testsuite/gcc.target/loongarch/func-call-medium-6.c > create mode 100644 gcc/testsuite/gcc.target/loongarch/func-call-medium-7.c > create mode 100644 gcc/testsuite/gcc.target/loongarch/func-call-medium-8.c > > diff --git a/gcc/config/loongarch/genopts/loongarch-strings > b/gcc/config/loongarch/genopts/loongarch-strings > index cb88ed56b68..44ebb7ab10b 100644 > --- a/gcc/config/loongarch/genopts/loongarch-strings > +++ b/gcc/config/loongarch/genopts/loongarch-strings > @@ -54,5 +54,6 @@ OPTSTR_CMODEL cmodel >
Re: [PATCH] fortran: Drop -static-lib{gfortran,quadmath} from f951 [PR46539]
Le 20/08/2022 à 10:41, Jakub Jelinek via Fortran a écrit : Hi! As discussed earlier, all other -static-lib* options are Driver only, these 2 are Driver in common.opt and Fortran in lang.opt. The spec files never pass the -static-lib* options down to any compiler (f951 etc.), so the 2 errors below are reported only when one runs ./f951 -static-libgfortran by hand. The following patch just removes f951 support of these options, the gfortran driver behavior remains as before. For other -static-lib* option (and even these because it is never passed to f951) we never error if we can't support those options, and e.g. Darwin is actually able to handle those options through other means. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? OK, thanks.
[PATCH] libgo: Access to glibc-specific field in struct sigevent
Hi Ian,
Thanks for your input!
I am not familiar with Go runtime internals at all, but the patch below
at least compiles for me. Let me know if this works for you too / if
there is a better way to do this. The untyped uintptr_t seems to be
necessary as otherwise I encountered errors about &sevp escaping to the
heap.
Sincerely,
Sören
diff --git a/libgo/go/runtime/os_linux.go b/libgo/go/runtime/os_linux.go
index 96fb1788..6653d85e 100644
--- a/libgo/go/runtime/os_linux.go
+++ b/libgo/go/runtime/os_linux.go
@@ -22,6 +22,8 @@ type mOS struct {
profileTimerValid uint32
}
+func setProcID(uintptr, int32)
+
func getProcID() uint64 {
return uint64(gettid())
}
@@ -365,7 +367,7 @@ func setThreadCPUProfiler(hz int32) {
var sevp _sigevent
sevp.sigev_notify = _SIGEV_THREAD_ID
sevp.sigev_signo = _SIGPROF
- *((*int32)(unsafe.Pointer(&sevp._sigev_un))) = int32(mp.procid)
+ setProcID(uintptr(unsafe.Pointer(&sevp)), int32(mp.procid))
ret := timer_create(_CLOCK_THREAD_CPUTIME_ID, &sevp, &timerid)
if ret != 0 {
// If we cannot create a timer for this M, leave
profileTimerValid false
diff --git a/libgo/runtime/go-signal.c b/libgo/runtime/go-signal.c
index 528d9b6d..347b24e2 100644
--- a/libgo/runtime/go-signal.c
+++ b/libgo/runtime/go-signal.c
@@ -183,6 +183,16 @@ setSigactionHandler(struct sigaction* sa, uintptr handler)
sa->sa_sigaction = (void*)(handler);
}
+void setProcID(uintptr_t, int32_t)
+ __asm__ (GOSYM_PREFIX "runtime.setProcID");
+
+void
+setProcID(uintptr_t ptr, int32_t v)
+{
+ struct sigevent *s = (void *)ptr;
+ s->sigev_notify_thread_id = v;
+}
+
// C code to fetch values from the siginfo_t and ucontext_t pointers
// passed to a signal handler.
Ian Lance Taylor wrote:
> On Fri, Aug 12, 2022 at 10:21 AM Sören Tempel
> wrote:
> >
> > This is one of the few remaining issues regarding musl compatibility for
> > gofrontend. Unfortunately, I am not sure how to best fix this one. Hence
> > reporting it here.
> >
> > The setThreadCPUProfiler implementation in libgo/go/runtime/os_linux.go
> > contains the following code:
> >
> > var sevp _sigevent
> > sevp.sigev_notify = _SIGEV_THREAD_ID
> > sevp.sigev_signo = _SIGPROF
> > *((*int32)(unsafe.Pointer(&sevp._sigev_un))) = int32(mp.procid)
> >
> > I am not entirely sure, but I assume the last line is supposed to access
> > the thread ID in struct sigevent. Unfortunately, it does so via the
> > glibc-specific _sigev_un member which doesn't work on musl libc (the
> > union is named __sev_fields on musl and hence causes a build failure).
> >
> > A portable way to access the thread ID in struct sigevent is via
> > sigev_notify_thread_id which is documented in timer_create(2). This is a
> > macro provided in siginfo.h from linux-headers for glibc [1] and in
> > signal.h for musl [2]. However, since it is macro it probably requires a
> > C wrapper function in order to be usable in libgo. Would be possible to
> > add that somehow to libgo or is there an alternative feasible solution
> > for this issue?
>
> I think you're right that a tiny C function is the way to go here.
>
> Ian
[PATCH 2/3] Fix PR 106601: __builtin_bswap16 code gen could be improved with ZBB enabled
From: Andrew Pinski
The default expansion for bswap16 is two extractions (shift/and)
followed by an insertation (ior) and then a zero extend. This can be improved
with ZBB enabled to just full byteswap followed by a (logical) shift right.
This patch adds a new pattern for this which does that.
OK? Built and tested on riscv32-linux-gnu and riscv64-linux-gnu.
gcc/ChangeLog:
PR target/106601
* config/riscv/bitmanip.md (bswaphi2): New pattern.
gcc/testsuite/ChangeLog:
PR target/106601
* gcc.target/riscv/zbb_32_bswap-2.c: New test.
* gcc.target/riscv/zbb_bswap-2.c: New test.
Change-Id: If61362c14664cf8685da17779217033689878f86
---
gcc/config/riscv/bitmanip.md | 24 +++
.../gcc.target/riscv/zbb_32_bswap-2.c | 12 ++
gcc/testsuite/gcc.target/riscv/zbb_bswap-2.c | 12 ++
3 files changed, 48 insertions(+)
create mode 100644 gcc/testsuite/gcc.target/riscv/zbb_32_bswap-2.c
create mode 100644 gcc/testsuite/gcc.target/riscv/zbb_bswap-2.c
diff --git a/gcc/config/riscv/bitmanip.md b/gcc/config/riscv/bitmanip.md
index c7ba667f87a..c4383285d81 100644
--- a/gcc/config/riscv/bitmanip.md
+++ b/gcc/config/riscv/bitmanip.md
@@ -276,6 +276,30 @@ (define_insn "bswap2"
"rev8\t%0,%1"
[(set_attr "type" "bitmanip")])
+;; HI bswap can be emulated using SI/DI bswap followed
+;; by a logical shift right
+;; SI bswap for TARGET_64BIT is already similarly in
+;; the common code.
+(define_expand "bswaphi2"
+ [(set (match_operand:HI 0 "register_operand" "=r")
+(bswap:HI (match_operand:HI 1 "register_operand" "r")))]
+ "TARGET_ZBB"
+{
+ rtx tmp = gen_reg_rtx (word_mode);
+ rtx newop1 = gen_lowpart (word_mode, operands[1]);
+ if (TARGET_64BIT)
+emit_insn (gen_bswapdi2 (tmp, newop1));
+ else
+emit_insn (gen_bswapsi2 (tmp, newop1));
+ rtx tmp1 = gen_reg_rtx (word_mode);
+ if (TARGET_64BIT)
+emit_insn (gen_lshrdi3 (tmp1, tmp, GEN_INT (64 - 16)));
+ else
+emit_insn (gen_lshrsi3 (tmp1, tmp, GEN_INT (32 - 16)));
+ emit_move_insn (operands[0], gen_lowpart (HImode, tmp1));
+ DONE;
+})
+
(define_insn "3"
[(set (match_operand:X 0 "register_operand" "=r")
(bitmanip_minmax:X (match_operand:X 1 "register_operand" "r")
diff --git a/gcc/testsuite/gcc.target/riscv/zbb_32_bswap-2.c
b/gcc/testsuite/gcc.target/riscv/zbb_32_bswap-2.c
new file mode 100644
index 000..679b34c4e41
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/zbb_32_bswap-2.c
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options "-march=rv32gc_zbb -mabi=ilp32" } */
+/* { dg-skip-if "" { *-*-* } { "-O0" } } */
+
+int foo(int n)
+{
+ return __builtin_bswap16(n);
+}
+
+/* { dg-final { scan-assembler "rev8" } } */
+/* { dg-final { scan-assembler "srli" } } */
+
diff --git a/gcc/testsuite/gcc.target/riscv/zbb_bswap-2.c
b/gcc/testsuite/gcc.target/riscv/zbb_bswap-2.c
new file mode 100644
index 000..c358f6683f3
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/zbb_bswap-2.c
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options "-march=rv64gc_zbb -mabi=lp64" } */
+/* { dg-skip-if "" { *-*-* } { "-O0" } } */
+
+int foo(int n)
+{
+ return __builtin_bswap16(n);
+}
+
+/* { dg-final { scan-assembler "rev8" } } */
+/* { dg-final { scan-assembler "srli" } } */
+
--
2.17.1
[PATCH 0/3] [RISCV] Improve bswap for ZBB
From: Andrew Pinski Just some improvements for bswap and ZBB including a testsuite change that will allow more testing to happen. Thanks, Andrew Pinski Andrew Pinski (3): Fix PR 106600: __builtin_bswap32 is not hooked up for ZBB for 32bit Fix PR 106601: __builtin_bswap16 code gen could be improved with ZBB enabled Fix PR 106690: enable effective_target_bswap for RISCV targets with ZBB enabled by default gcc/config/riscv/bitmanip.md | 26 ++- .../gcc.target/riscv/zbb_32_bswap-1.c | 11 .../gcc.target/riscv/zbb_32_bswap-2.c | 12 + gcc/testsuite/gcc.target/riscv/zbb_bswap-1.c | 11 gcc/testsuite/gcc.target/riscv/zbb_bswap-2.c | 12 + gcc/testsuite/lib/target-supports.exp | 7 + 6 files changed, 78 insertions(+), 1 deletion(-) create mode 100644 gcc/testsuite/gcc.target/riscv/zbb_32_bswap-1.c create mode 100644 gcc/testsuite/gcc.target/riscv/zbb_32_bswap-2.c create mode 100644 gcc/testsuite/gcc.target/riscv/zbb_bswap-1.c create mode 100644 gcc/testsuite/gcc.target/riscv/zbb_bswap-2.c -- 2.17.1
[PATCH 1/3] Fix PR 106600: __builtin_bswap32 is not hooked up for ZBB for 32bit
From: Andrew Pinski
The problem here is the bswap2 pattern had a check for TARGET_64BIT
but then used the X iterator. Since the X iterator is either SI or DI depending
on the setting TARGET_64BIT, there is no reason for the TARGET_64BIT.
OK? Built and tested on both riscv32-linux-gnu and riscv64-linux-gnu.
Thanks,
Andrew Pinski
gcc/ChangeLog:
PR target/106600
* config/riscv/bitmanip.md (bswap2): Remove
condition on TARGET_64BIT as X is already conditional there.
gcc/testsuite/ChangeLog:
PR target/106600
* gcc.target/riscv/zbb_32_bswap-1.c: New test.
* gcc.target/riscv/zbb_bswap-1.c: New test.
Change-Id: Iba3187e5620b0f291f7c38aab597f367b47a22c5
---
gcc/config/riscv/bitmanip.md| 2 +-
gcc/testsuite/gcc.target/riscv/zbb_32_bswap-1.c | 11 +++
gcc/testsuite/gcc.target/riscv/zbb_bswap-1.c| 11 +++
3 files changed, 23 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/gcc.target/riscv/zbb_32_bswap-1.c
create mode 100644 gcc/testsuite/gcc.target/riscv/zbb_bswap-1.c
diff --git a/gcc/config/riscv/bitmanip.md b/gcc/config/riscv/bitmanip.md
index d1570ce8508..c7ba667f87a 100644
--- a/gcc/config/riscv/bitmanip.md
+++ b/gcc/config/riscv/bitmanip.md
@@ -272,7 +272,7 @@ (define_insn "rotlsi3_sext"
(define_insn "bswap2"
[(set (match_operand:X 0 "register_operand" "=r")
(bswap:X (match_operand:X 1 "register_operand" "r")))]
- "TARGET_64BIT && TARGET_ZBB"
+ "TARGET_ZBB"
"rev8\t%0,%1"
[(set_attr "type" "bitmanip")])
diff --git a/gcc/testsuite/gcc.target/riscv/zbb_32_bswap-1.c
b/gcc/testsuite/gcc.target/riscv/zbb_32_bswap-1.c
new file mode 100644
index 000..3ff7d9de409
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/zbb_32_bswap-1.c
@@ -0,0 +1,11 @@
+/* { dg-do compile } */
+/* { dg-options "-march=rv32gc_zbb -mabi=ilp32" } */
+/* { dg-skip-if "" { *-*-* } { "-O0" } } */
+
+int foo(int n)
+{
+ return __builtin_bswap32(n);
+}
+
+/* { dg-final { scan-assembler "rev8" } } */
+
diff --git a/gcc/testsuite/gcc.target/riscv/zbb_bswap-1.c
b/gcc/testsuite/gcc.target/riscv/zbb_bswap-1.c
new file mode 100644
index 000..20feded0df2
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/zbb_bswap-1.c
@@ -0,0 +1,11 @@
+/* { dg-do compile } */
+/* { dg-options "-march=rv64gc_zbb -mabi=lp64" } */
+/* { dg-skip-if "" { *-*-* } { "-O0" } } */
+
+int foo(int n)
+{
+ return __builtin_bswap32(n);
+}
+
+/* { dg-final { scan-assembler "rev8" } } */
+
--
2.17.1
[PATCH 3/3] Fix PR 106690: enable effective_target_bswap for RISCV targets with ZBB enabled by default
From: Andrew Pinski
While looking for testcases to quickly test, I Noticed that
check_effective_target_bswap was not enabled for riscv when
ZBB is enabled. This patch checks if ZBB is enabled when
targeting RISCV* for bswap.
OK? Ran the testsuite for riscv32-linux-gnu both with and without ZBB enabled.
PR testsuite/106690
gcc/testsuite/ChangeLog:
* lib/target-supports.exp (check_effective_target_bswap):
Return true if riscv and ZBB ISA extension is enabled.
Change-Id: I521c91e7fc1a54faa0c8399b685248690022278b
---
gcc/testsuite/lib/target-supports.exp | 7 +++
1 file changed, 7 insertions(+)
diff --git a/gcc/testsuite/lib/target-supports.exp
b/gcc/testsuite/lib/target-supports.exp
index 04a2a8e8659..0f1e1af31e9 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -8646,6 +8646,13 @@ proc check_effective_target_bswap { } {
|| [istarget powerpc*-*-*]
|| [istarget rs6000-*-*]
|| [istarget s390*-*-*]
+|| ([istarget riscv*-*-*]
+&& [check_no_compiler_messages_nocache riscv_zbb object {
+#if __riscv_zbb <= 0
+#error ZBB is not enabled
+#endif
+int i;
+} ""])
|| ([istarget arm*-*-*]
&& [check_no_compiler_messages_nocache arm_v6_or_later object {
#if __ARM_ARCH < 6
--
2.17.1
[PATCH] Fortran: fix simplification of intrinsics IBCLR and IBSET [PR106557]
Dear all,
the simplification of the TRANSFER intrinsic produces a
redundant representation of the result, one in expr->value
and another in expr->representation.string. This is done
to ensure a safe "round-trip" for nested TRANSFER.
In a subsequent use of this result we either need to make
sure that both parts stay consistent, or drop the latter
part.
The simplifications of IBCLR and IBSET do a gfc_copy_expr
of their argument x and modify only the former part.
Depending on context, either value.integer or
representation.string (if non-NULL) are used later,
leading to surprising results.
A conservative approach to fix this PR is to simply
drop the unneeded representation.string in the
simplification of the intrinsics IBCLR and IBSET,
see attached patch. (A quick glance did not turn up
other intrinsics affected the same way.)
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From a540a806cf02d739a408f129738252e73f03e60c Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Sat, 20 Aug 2022 20:36:28 +0200
Subject: [PATCH] Fortran: fix simplification of intrinsics IBCLR and IBSET
[PR106557]
gcc/fortran/ChangeLog:
PR fortran/106557
* simplify.cc (gfc_simplify_ibclr): Ensure consistent results of
the simplification by dropping a redundant memory representation
of argument x.
(gfc_simplify_ibset): Likewise.
gcc/testsuite/ChangeLog:
PR fortran/106557
* gfortran.dg/pr106557.f90: New test.
---
gcc/fortran/simplify.cc| 14 ++
gcc/testsuite/gfortran.dg/pr106557.f90 | 19 +++
2 files changed, 33 insertions(+)
create mode 100644 gcc/testsuite/gfortran.dg/pr106557.f90
diff --git a/gcc/fortran/simplify.cc b/gcc/fortran/simplify.cc
index fb725994653..f992c31e5d7 100644
--- a/gcc/fortran/simplify.cc
+++ b/gcc/fortran/simplify.cc
@@ -3380,6 +3380,13 @@ gfc_simplify_ibclr (gfc_expr *x, gfc_expr *y)
k = gfc_validate_kind (x->ts.type, x->ts.kind, false);
result = gfc_copy_expr (x);
+ /* Drop any separate memory representation of x to avoid potential
+ inconsistencies in result. */
+ if (result->representation.string)
+{
+ free (result->representation.string);
+ result->representation.string = NULL;
+}
convert_mpz_to_unsigned (result->value.integer,
gfc_integer_kinds[k].bit_size);
@@ -3471,6 +3478,13 @@ gfc_simplify_ibset (gfc_expr *x, gfc_expr *y)
k = gfc_validate_kind (x->ts.type, x->ts.kind, false);
result = gfc_copy_expr (x);
+ /* Drop any separate memory representation of x to avoid potential
+ inconsistencies in result. */
+ if (result->representation.string)
+{
+ free (result->representation.string);
+ result->representation.string = NULL;
+}
convert_mpz_to_unsigned (result->value.integer,
gfc_integer_kinds[k].bit_size);
diff --git a/gcc/testsuite/gfortran.dg/pr106557.f90 b/gcc/testsuite/gfortran.dg/pr106557.f90
new file mode 100644
index 000..d073f3e7186
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr106557.f90
@@ -0,0 +1,19 @@
+! { dg-do run }
+! { dg-additional-options "-fdump-tree-original" }
+! PR fortran/106557 - nesting intrinsics ibset and transfer gives wrong result
+
+program p
+ implicit none
+ character(1) :: s
+
+ write(s,'(i1)') ibset (transfer (0, 0), 0)
+ if (s /= '1') stop 1
+ write(s,'(i1)') ibclr (transfer (1, 0), 0)
+ if (s /= '0') stop 2
+
+ ! These shall be fully resolved at compile time:
+ if (transfer (ibset (transfer (0, 0), 0), 0) /= 1) stop 3
+ if (transfer (ibclr (transfer (1, 0), 0), 0) /= 0) stop 4
+end
+
+! { dg-final { scan-tree-dump-times "_gfortran_stop_numeric" 2 "original" } }
--
2.35.3
Re: [PATCH v3] c++: Implement -Wself-move warning [PR81159]
On 8/19/22 15:34, Marek Polacek wrote:
On Thu, Aug 18, 2022 at 08:33:47PM -0400, Jason Merrill wrote:
On 8/18/22 13:19, Marek Polacek wrote:
On Mon, Aug 15, 2022 at 03:54:05PM -0400, Jason Merrill wrote:
On 8/9/22 09:37, Marek Polacek wrote:
+ /* We're looking for *std::move ((T &) &arg), or
+ *std::move ((T &) (T *) r) if the argument it a reference. */
+ if (!REFERENCE_REF_P (rhs)
+ || TREE_CODE (TREE_OPERAND (rhs, 0)) != CALL_EXPR)
+return;
+ tree fn = TREE_OPERAND (rhs, 0);
+ if (!is_std_move_p (fn))
+return;
+ tree arg = CALL_EXPR_ARG (fn, 0);
+ if (TREE_CODE (arg) != NOP_EXPR)
+return;
+ /* Strip the (T &). */
+ arg = TREE_OPERAND (arg, 0);
+ /* Strip the (T *) or &. */
+ arg = TREE_OPERAND (arg, 0);
Are you sure these are the only two expressions that can make it here? What
if the argument to move is *Tptr?
Not 100% sure but I couldn't find any other form. For *Tptr we get
*std::move ((int * &) &Tptr)
That likes like what you'd get when the argument is Tptr, not when it's
*Tptr. And indeed that's what I see in the testcase:
+ Tptr = std::move (Tptr); // { dg-warning "moving a variable to itself" }
is missing the *
Duh, sorry. The previous patch didn't handle the *Tptr case. Further poking
revealed that we need special care to handle (*(Tptr)) and **Tptr etc. So in
this patch I'm stripping all *s and V_C_Es. Sigh.
Ah, I was just thinking that the old patch needed more checking of
TREE_CODEs. But I suppose it's also good to diagnose these cases as well.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
About 5 years ago we got a request to implement -Wself-move, which
warns about useless moves like this:
int x;
x = std::move (x);
This patch implements that warning.
PR c++/81159
gcc/c-family/ChangeLog:
* c.opt (Wself-move): New option.
gcc/cp/ChangeLog:
* typeck.cc (maybe_warn_self_move): New.
(cp_build_modify_expr): Call maybe_warn_self_move.
gcc/ChangeLog:
* doc/invoke.texi: Document -Wself-move.
gcc/testsuite/ChangeLog:
* g++.dg/warn/Wself-move1.C: New test.
---
gcc/c-family/c.opt | 4 +
gcc/cp/typeck.cc| 51 +-
gcc/doc/invoke.texi | 23 -
gcc/testsuite/g++.dg/warn/Wself-move1.C | 122
4 files changed, 198 insertions(+), 2 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/warn/Wself-move1.C
diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index dfdebd596ef..f776efd39d8 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -1229,6 +1229,10 @@ Wselector
ObjC ObjC++ Var(warn_selector) Warning
Warn if a selector has multiple methods.
+Wself-move
+C++ ObjC++ Var(warn_self_move) Warning LangEnabledBy(C++ ObjC++, Wall)
+Warn when a value is moved to itself with std::move.
+
Wsequence-point
C ObjC C++ ObjC++ Var(warn_sequence_point) Warning LangEnabledBy(C ObjC C++
ObjC++,Wall)
Warn about possible violations of sequence point rules.
diff --git a/gcc/cp/typeck.cc b/gcc/cp/typeck.cc
index 992ebfd99fb..b2bd13db1b6 100644
--- a/gcc/cp/typeck.cc
+++ b/gcc/cp/typeck.cc
@@ -8897,7 +8897,54 @@ cp_build_c_cast (location_t loc, tree type, tree expr,
return error_mark_node;
}
-
+
+/* Warn when a value is moved to itself with std::move. LHS is the target,
+ RHS may be the std::move call, and LOC is the location of the whole
+ assignment. */
+
+static void
+maybe_warn_self_move (location_t loc, tree lhs, tree rhs)
+{
+ if (!warn_self_move)
+return;
+
+ /* C++98 doesn't know move. */
+ if (cxx_dialect < cxx11)
+return;
+
+ if (processing_template_decl)
+return;
+
+ if (!REFERENCE_REF_P (rhs)
+ || TREE_CODE (TREE_OPERAND (rhs, 0)) != CALL_EXPR)
+return;
+ tree fn = TREE_OPERAND (rhs, 0);
+ if (!is_std_move_p (fn))
+return;
+
+ /* Just a little helper to strip * and various NOPs. */
+ auto extract_op = [] (tree &op) {
+STRIP_NOPS (op);
+while (INDIRECT_REF_P (op))
+ op = TREE_OPERAND (op, 0);
+op = maybe_undo_parenthesized_ref (op);
+STRIP_ANY_LOCATION_WRAPPER (op);
+ };
+
+ tree arg = CALL_EXPR_ARG (fn, 0);
+ extract_op (arg);
+ if (TREE_CODE (arg) == ADDR_EXPR)
+arg = TREE_OPERAND (arg, 0);
+ extract_op (lhs);
+
+ if (cp_tree_equal (lhs, arg))
+{
+ auto_diagnostic_group d;
+ if (warning_at (loc, OPT_Wself_move, "moving a variable to itself"))
Maybe only say "variable" when the original operand is in fact a variable?
+ inform (loc, "remove % call");
+}
+}
+
/* For use from the C common bits. */
tree
build_modify_expr (location_t location,
@@ -9101,6 +9148,8 @@ cp_build_modify_expr (location_t loc, tree lhs, enum
tree_code modifycode,
if (modifycode == NOP_EXPR)
{
+ maybe_warn_self_move (loc, lhs, rhs);
+
if (c_dialect_objc ())
{
result = objc_maybe_bui
Re: [PATCH] RISC-V: Add runtime invariant support
This breaks bootstrap: ../../gcc/tree-vect-loop-manip.cc: In function 'void vect_gen_vector_loop_niters(loop_vec_info, tree, tree_node**, tree_node**, bool)': ../../gcc/tree-vect-loop-manip.cc:1981:26: error: 'const_vf' may be used uninitialized [-Werror=maybe-uninitialized] 1981 | unsigned HOST_WIDE_INT const_vf; | ^~~~ cc1plus: all warnings being treated as errors make[3]: *** [Makefile:1146: tree-vect-loop-manip.o] Error 1 make[2]: *** [Makefile:4977: all-stage2-gcc] Error 2 make[1]: *** [Makefile:30363: stage2-bubble] Error 2 make: *** [Makefile:1065: all] Error 2 -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: [PATCH] RISC-V: Add runtime invariant support
On Sat, Aug 20, 2022 at 3:34 PM Andreas Schwab wrote: > > This breaks bootstrap: > > ../../gcc/tree-vect-loop-manip.cc: In function 'void > vect_gen_vector_loop_niters(loop_vec_info, tree, tree_node**, tree_node**, > bool)': > ../../gcc/tree-vect-loop-manip.cc:1981:26: error: 'const_vf' may be used > uninitialized [-Werror=maybe-uninitialized] > 1981 | unsigned HOST_WIDE_INT const_vf; > | ^~~~ > cc1plus: all warnings being treated as errors > make[3]: *** [Makefile:1146: tree-vect-loop-manip.o] Error 1 > make[2]: *** [Makefile:4977: all-stage2-gcc] Error 2 > make[1]: *** [Makefile:30363: stage2-bubble] Error 2 > make: *** [Makefile:1065: all] Error 2 This looks like a real uninitialized variable issue. I even can't tell if the paths that lead to using const_vf will be always set so how we expect GCC to do the same. The code that uses const_vf was added with r11-5820-cdcbef3c3310, CCing the author there. Thanks, Andrew > > -- > Andreas Schwab, sch...@linux-m68k.org > GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 > "And now for something completely different."
Re: Re: [PATCH] RISC-V: Add runtime invariant support
Hi, it seems that this warning still report if I revert my patch. Am I right? Feel free to correct me. Maybe I need to try it again? juzhe.zh...@rivai.ai From: Andrew Pinski Date: 2022-08-21 07:53 To: Andreas Schwab CC: juzhe.zhong; gcc-patches; kito.cheng; andrew; Richard Guenther Subject: Re: [PATCH] RISC-V: Add runtime invariant support On Sat, Aug 20, 2022 at 3:34 PM Andreas Schwab wrote: > > This breaks bootstrap: > > ../../gcc/tree-vect-loop-manip.cc: In function 'void > vect_gen_vector_loop_niters(loop_vec_info, tree, tree_node**, tree_node**, > bool)': > ../../gcc/tree-vect-loop-manip.cc:1981:26: error: 'const_vf' may be used > uninitialized [-Werror=maybe-uninitialized] > 1981 | unsigned HOST_WIDE_INT const_vf; > | ^~~~ > cc1plus: all warnings being treated as errors > make[3]: *** [Makefile:1146: tree-vect-loop-manip.o] Error 1 > make[2]: *** [Makefile:4977: all-stage2-gcc] Error 2 > make[1]: *** [Makefile:30363: stage2-bubble] Error 2 > make: *** [Makefile:1065: all] Error 2 This looks like a real uninitialized variable issue. I even can't tell if the paths that lead to using const_vf will be always set so how we expect GCC to do the same. The code that uses const_vf was added with r11-5820-cdcbef3c3310, CCing the author there. Thanks, Andrew > > -- > Andreas Schwab, sch...@linux-m68k.org > GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 > "And now for something completely different."
Re: Re: [PATCH] RISC-V: Add runtime invariant support
On Sat, Aug 20, 2022 at 5:06 PM 钟居哲 wrote: > > Hi, it seems that this warning still report if I revert my patch. Am I right? > Feel free to correct me. Maybe I need to try it again? The warning will not be still there. The reason is NUM_POLY_INT_COEFFS defaults to 1 which means vf.is_constant (&const_vf) will always return true and will always set const_vf. I don't know why the warning does not happen on aarch64-linux-gnu (the other target where NUM_POLY_INT_COEFFS is set to 2) though; it just might be slightly different IR which causes the warning mechanism not to warn. Thanks, Andrew Pinski > > > juzhe.zh...@rivai.ai > > > From: Andrew Pinski > Date: 2022-08-21 07:53 > To: Andreas Schwab > CC: juzhe.zhong; gcc-patches; kito.cheng; andrew; Richard Guenther > Subject: Re: [PATCH] RISC-V: Add runtime invariant support > On Sat, Aug 20, 2022 at 3:34 PM Andreas Schwab wrote: > > > > This breaks bootstrap: > > > > ../../gcc/tree-vect-loop-manip.cc: In function 'void > > vect_gen_vector_loop_niters(loop_vec_info, tree, tree_node**, tree_node**, > > bool)': > > ../../gcc/tree-vect-loop-manip.cc:1981:26: error: 'const_vf' may be used > > uninitialized [-Werror=maybe-uninitialized] > > 1981 | unsigned HOST_WIDE_INT const_vf; > > | ^~~~ > > cc1plus: all warnings being treated as errors > > make[3]: *** [Makefile:1146: tree-vect-loop-manip.o] Error 1 > > make[2]: *** [Makefile:4977: all-stage2-gcc] Error 2 > > make[1]: *** [Makefile:30363: stage2-bubble] Error 2 > > make: *** [Makefile:1065: all] Error 2 > > > This looks like a real uninitialized variable issue. > I even can't tell if the paths that lead to using const_vf will be > always set so how we expect GCC to do the same. > The code that uses const_vf was added with r11-5820-cdcbef3c3310, > CCing the author there. > > Thanks, > Andrew > > > > > -- > > Andreas Schwab, sch...@linux-m68k.org > > GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 > > "And now for something completely different." >
Re: Re: [PATCH] RISC-V: Add runtime invariant support
OK. Thank you. I am gonna try it again and fix this in RISC-V port. juzhe.zh...@rivai.ai From: Andrew Pinski Date: 2022-08-21 08:18 To: 钟居哲 CC: Andreas Schwab; gcc-patches; kito.cheng; andrew; rguenther Subject: Re: Re: [PATCH] RISC-V: Add runtime invariant support On Sat, Aug 20, 2022 at 5:06 PM 钟居哲 wrote: > > Hi, it seems that this warning still report if I revert my patch. Am I right? > Feel free to correct me. Maybe I need to try it again? The warning will not be still there. The reason is NUM_POLY_INT_COEFFS defaults to 1 which means vf.is_constant (&const_vf) will always return true and will always set const_vf. I don't know why the warning does not happen on aarch64-linux-gnu (the other target where NUM_POLY_INT_COEFFS is set to 2) though; it just might be slightly different IR which causes the warning mechanism not to warn. Thanks, Andrew Pinski > > > juzhe.zh...@rivai.ai > > > From: Andrew Pinski > Date: 2022-08-21 07:53 > To: Andreas Schwab > CC: juzhe.zhong; gcc-patches; kito.cheng; andrew; Richard Guenther > Subject: Re: [PATCH] RISC-V: Add runtime invariant support > On Sat, Aug 20, 2022 at 3:34 PM Andreas Schwab wrote: > > > > This breaks bootstrap: > > > > ../../gcc/tree-vect-loop-manip.cc: In function 'void > > vect_gen_vector_loop_niters(loop_vec_info, tree, tree_node**, tree_node**, > > bool)': > > ../../gcc/tree-vect-loop-manip.cc:1981:26: error: 'const_vf' may be used > > uninitialized [-Werror=maybe-uninitialized] > > 1981 | unsigned HOST_WIDE_INT const_vf; > > | ^~~~ > > cc1plus: all warnings being treated as errors > > make[3]: *** [Makefile:1146: tree-vect-loop-manip.o] Error 1 > > make[2]: *** [Makefile:4977: all-stage2-gcc] Error 2 > > make[1]: *** [Makefile:30363: stage2-bubble] Error 2 > > make: *** [Makefile:1065: all] Error 2 > > > This looks like a real uninitialized variable issue. > I even can't tell if the paths that lead to using const_vf will be > always set so how we expect GCC to do the same. > The code that uses const_vf was added with r11-5820-cdcbef3c3310, > CCing the author there. > > Thanks, > Andrew > > > > > -- > > Andreas Schwab, sch...@linux-m68k.org > > GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 > > "And now for something completely different." >
Re: Re: [PATCH] RISC-V: Add runtime invariant support
On Sat, Aug 20, 2022 at 5:29 PM 钟居哲 wrote: > > OK. Thank you. I am gonna try it again and fix this in RISC-V port. The fix is not in the RISC-V port, the fix needs to happen in vect_gen_vector_loop_niters (tree-vect-loop-manip.cc). I described why the code is broken, the second use of const_vf is not connected at all to vf.is_constant (&const_vf) so it will be uninitilized there. Thanks, Andrew > > > juzhe.zh...@rivai.ai > > > From: Andrew Pinski > Date: 2022-08-21 08:18 > To: 钟居哲 > CC: Andreas Schwab; gcc-patches; kito.cheng; andrew; rguenther > Subject: Re: Re: [PATCH] RISC-V: Add runtime invariant support > On Sat, Aug 20, 2022 at 5:06 PM 钟居哲 wrote: > > > > Hi, it seems that this warning still report if I revert my patch. Am I > > right? Feel free to correct me. Maybe I need to try it again? > > The warning will not be still there. The reason is NUM_POLY_INT_COEFFS > defaults to 1 which means vf.is_constant (&const_vf) will always > return true and will always set const_vf. > I don't know why the warning does not happen on aarch64-linux-gnu (the > other target where NUM_POLY_INT_COEFFS is set to 2) though; it just > might be slightly different IR which causes the warning mechanism not > to warn. > > Thanks, > Andrew Pinski > > > > > > > > juzhe.zh...@rivai.ai > > > > > > From: Andrew Pinski > > Date: 2022-08-21 07:53 > > To: Andreas Schwab > > CC: juzhe.zhong; gcc-patches; kito.cheng; andrew; Richard Guenther > > Subject: Re: [PATCH] RISC-V: Add runtime invariant support > > On Sat, Aug 20, 2022 at 3:34 PM Andreas Schwab > > wrote: > > > > > > This breaks bootstrap: > > > > > > ../../gcc/tree-vect-loop-manip.cc: In function 'void > > > vect_gen_vector_loop_niters(loop_vec_info, tree, tree_node**, > > > tree_node**, bool)': > > > ../../gcc/tree-vect-loop-manip.cc:1981:26: error: 'const_vf' may be used > > > uninitialized [-Werror=maybe-uninitialized] > > > 1981 | unsigned HOST_WIDE_INT const_vf; > > > | ^~~~ > > > cc1plus: all warnings being treated as errors > > > make[3]: *** [Makefile:1146: tree-vect-loop-manip.o] Error 1 > > > make[2]: *** [Makefile:4977: all-stage2-gcc] Error 2 > > > make[1]: *** [Makefile:30363: stage2-bubble] Error 2 > > > make: *** [Makefile:1065: all] Error 2 > > > > > > This looks like a real uninitialized variable issue. > > I even can't tell if the paths that lead to using const_vf will be > > always set so how we expect GCC to do the same. > > The code that uses const_vf was added with r11-5820-cdcbef3c3310, > > CCing the author there. > > > > Thanks, > > Andrew > > > > > > > > -- > > > Andreas Schwab, sch...@linux-m68k.org > > > GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 > > > "And now for something completely different." > > >
