[pushed] Darwin, libffi, testsuite: Ensure we pick up the convenience lib.
Tested on i686, powerpc, x86_64, Arm64 Darwin, x86_64-linux-gnu,
pushed to trunk, thanks,
Iain
--- 8< ---
For several Darwin linker versions, the link paths are first traversed
looking for shared libraries, and then again looking for archives.
We want the paths to be searched for both shared and archives in order
so that we will find the non-shared libffi in the testsuite (otherwise
the installed version in the system will be found instead).
Signed-off-by: Iain Sandoe
libffi/ChangeLog:
* testsuite/lib/libffi.exp: Search for both shared and archive
in each path in turn.
---
libffi/testsuite/lib/libffi.exp | 1 +
1 file changed, 1 insertion(+)
diff --git a/libffi/testsuite/lib/libffi.exp b/libffi/testsuite/lib/libffi.exp
index 7dc7b5d19a3..15d3d5ebd73 100644
--- a/libffi/testsuite/lib/libffi.exp
+++ b/libffi/testsuite/lib/libffi.exp
@@ -384,6 +384,7 @@ proc libffi_target_compile { source dest type options } {
if { [istarget "*-*-darwin9*"] || [istarget "*-*-darwin1*"]
|| [istarget "*-*-darwin2*"] } {
lappend options "additional_flags=-Wl,-allow_stack_execute"
+ lappend options "additional_flags=-Wl,-search_paths_first"
}
# If you're building the compiler with --prefix set to a place
--
2.37.1 (Apple Git-137.1)
Re: [pushed] Darwin, libffi, testsuite: Ensure we pick up the convenience lib.
Hi Iain, > Tested on i686, powerpc, x86_64, Arm64 Darwin, x86_64-linux-gnu, > pushed to trunk, thanks, > Iain > > --- 8< --- > > For several Darwin linker versions, the link paths are first traversed > looking for shared libraries, and then again looking for archives. > > We want the paths to be searched for both shared and archives in order > so that we will find the non-shared libffi in the testsuite (otherwise > the installed version in the system will be found instead). > > Signed-off-by: Iain Sandoe > > libffi/ChangeLog: > > * testsuite/lib/libffi.exp: Search for both shared and archive > in each path in turn. shouldn't this go upstream first? Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [pushed] Darwin, libffi, testsuite: Ensure we pick up the convenience lib.
Hi Rainer, > On 22 Jan 2023, at 09:44, Rainer Orth wrote: > >> Tested on i686, powerpc, x86_64, Arm64 Darwin, x86_64-linux-gnu, >> pushed to trunk, thanks, >> Iain >> >> --- 8< --- >> >> For several Darwin linker versions, the link paths are first traversed >> looking for shared libraries, and then again looking for archives. >> >> We want the paths to be searched for both shared and archives in order >> so that we will find the non-shared libffi in the testsuite (otherwise >> the installed version in the system will be found instead). >> >> Signed-off-by: Iain Sandoe >> >> libffi/ChangeLog: >> >> * testsuite/lib/libffi.exp: Search for both shared and archive >> in each path in turn. > > shouldn't this go upstream first? I was regarding this as specific to GCC since we build without the shared library now (but I guess upstream could also be configured with —disable-shared). so I will make a pull request, thanks for the note. Iain
[pushed] wwwdocs: gcc-10: Grammar fixes in the amdgcn section
I missed this originally and noticed looking for something else. Pushed. Gerald --- htdocs/gcc-10/changes.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html index 2bad8ea3..4acc8d12 100644 --- a/htdocs/gcc-10/changes.html +++ b/htdocs/gcc-10/changes.html @@ -873,7 +873,7 @@ typedef svbool_t pred512 __attribute__((arm_sve_vector_bits(512))); AMD Radeon (GCN) - The code generation and in particular the vectorization support has been + Code generation and in particular vectorization support have been much improved. -- 2.39.0
Re: [patch, gfortran.dg] Adjust numerous tests so that they pass on line endings
Hello, Le 22/01/2023 à 00:59, Jerry D via Fortran a écrit : (...) Proposed ChangeLog entry using git gcc-commit-mklog: Author: Jerry DeLisle Date: Sat Jan 21 15:47:19 2023 -0800 Revise the line end tests to pass on certain windows test environments which inject spurious /r characters. Adjust (\n|\r\n|\r) to (\r*\n+). gcc/testsuite/ChangeLog: * gfortran.dg/ISO_Fortran_binding_17.f90: As noted above. (...)This part will be integrated in the ChangeLog file, without the preceding text. Don't start with "As noted above", as there will be no "above" to refer to. Cheers
Re: [PATCH v4] xtensa: Eliminate the use of callee-saved register that saves and restores only once
On Fri, Jan 20, 2023 at 8:39 PM Takayuki 'January June' Suwa wrote: > On 2023/01/21 0:14, Max Filippov wrote: > > After having this many attempts and getting to the issues that are > > really hard to detect I wonder if the target backend is the right place > > for this optimization? > > > I guess they are not hard to detect I mean, on the testing side. check-gcc testsuite passed without new regressions with this change, linux kernel smoke test passed, I was almost convinced that it's ok to commit. > but just issues I didn't anticipate (and I just need a little more work). Looking at other peephole2 patterns I see that their code transformations are much more compact and they don't need to track additional properties of unrelated instructions. > And where else should it be done? What about implementing a > target-specific pass just for one-point optimization? I don't even understand what's target-specific in this optimization? It looks very generic to me. -- Thanks. -- Max
Re: [patch, gfortran.dg] Adjust numerous tests so that they pass on line endings
On 1/22/23 5:38 AM, Mikael Morin wrote: Hello, Le 22/01/2023 à 00:59, Jerry D via Fortran a écrit : (...) Proposed ChangeLog entry using git gcc-commit-mklog: Author: Jerry DeLisle Date: Sat Jan 21 15:47:19 2023 -0800 Revise the line end tests to pass on certain windows test environments which inject spurious /r characters. Adjust (\n|\r\n|\r) to (\r*\n+). gcc/testsuite/ChangeLog: * gfortran.dg/ISO_Fortran_binding_17.f90: As noted above. (...)This part will be integrated in the ChangeLog file, without the preceding text. Don't start with "As noted above", as there will be no "above" to refer to. Thank you, relearning how these things work with the automation scripts. Jerry
[PATCH] Modula-2, testsuite: Remove use of concatenated paths.
tested on x86_64-darwin21 with an updated compiler that does not support
the path concatentation and on an unpatched trunk.
OK for trunk?
thanks
Iain
--- 8< ---
The original implementation for Modula-2 search paths allows things like
'-I/path/a:/path/b'. Such paths are not compatible with the rest of the
compiler (in particular, the preprocessor, which Modula-2 uses). In
preparation for removing that idiom, this patch rewrites the cases in the
testsuite and removes string processing where possible from lists of paths.
TODO: There are some apparent discrepancies and/or extraneous insertions
of partial include paths (especially in gm2_init_log, gm2_init_iso and
gm2_init_pim) - to be handled in some future patch.
Signed-off-by: Iain Sandoe
gcc/testsuite/ChangeLog:
* gm2/case/pass/case-pass.exp: Update for removal of concatenated
paths.
* gm2/complex/pass/complex-pass.exp: Likewise.
* gm2/coroutines/pim/run/pass/coroutines-pim-run-pass.exp: Likewise.
* gm2/iso/analysis/fail/iso-analysis-fail.xp: Likewise.
* gm2/iso/check/fail/iso-check-fail.exp: Likewise.
* gm2/iso/fail/iso-fail.exp: Likewise.
* gm2/iso/pass/iso-pass.exp: Likewise.
* gm2/isolib/run/pass/isolib-run-pass.exp: Likewise.
* gm2/pim/fail/pim-fail.exp: Likewise.
* gm2/pim/pass/pim-pass.exp: Likewise.
* gm2/pimlib/logitech/run/pass/pimlib-logitech-run-pass.exp: Likewise.
* gm2/pimlib/pass/pimlib-pass.exp: Likewise.
* gm2/pimlib/run/pass/pimlib-run-pass.exp: Likewise.
* gm2/projects/iso/run/pass/halma/projects-iso-run-pass-halma.exp:
Likewise.
* gm2/projects/iso/run/pass/hello/projects-iso-run-pass-hello.exp:
Likewise.
* gm2/projects/log/run/pass/hello/projects-log-run-pass-hello.exp:
Likewise.
* gm2/projects/pim/run/pass/hello/projects-pim-run-pass-hello.exp:
Likewise.
* gm2/recover/pass/recover-pass.exp: Likewise.
* gm2/switches/makeall/fail/switches-makeall-fail.exp: Likewise.
* gm2/switches/makeall/pass/switches-makeall-pass.exp: Likewise.
* gm2/switches/none/run/pass/gm2-none.exp: Likewise.
* gm2/switches/pim2/run/pass/switches-pim2-run-pass.exp: Likewise.
* gm2/ulmlib/pass/ulmlib-pass.exp: Likewise.
* gm2/ulmlib/std/pass/ulmlib-std-pass.exp: Likewise.
* gm2/ulmlib/sys/pass/ulmlib-sys-pass.exp: Likewise.
* lib/gm2.exp: Make the paths list a mandatory entry for each
gm2_init_xxx
function. Remove the use of concatenated include and library paths.
Remove string processing where possible.
---
gcc/testsuite/gm2/case/pass/case-pass.exp | 2 +-
.../gm2/complex/pass/complex-pass.exp | 2 +-
.../pim/run/pass/coroutines-pim-run-pass.exp | 2 +-
.../iso/analysis/fail/iso-analysis-fail.exp | 2 +-
.../gm2/iso/check/fail/iso-check-fail.exp | 2 +-
gcc/testsuite/gm2/iso/fail/iso-fail.exp | 2 +-
gcc/testsuite/gm2/iso/pass/iso-pass.exp | 2 +-
.../gm2/isolib/run/pass/isolib-run-pass.exp | 2 +-
gcc/testsuite/gm2/pim/fail/pim-fail.exp | 2 +-
gcc/testsuite/gm2/pim/pass/pim-pass.exp | 2 +-
.../run/pass/pimlib-logitech-run-pass.exp | 2 +-
gcc/testsuite/gm2/pimlib/pass/pimlib-pass.exp | 2 +-
.../gm2/pimlib/run/pass/pimlib-run-pass.exp | 2 +-
.../halma/projects-iso-run-pass-halma.exp | 2 +-
.../hello/projects-iso-run-pass-hello.exp | 2 +-
.../hello/projects-log-run-pass-hello.exp | 3 +-
.../hello/projects-pim-run-pass-hello.exp | 2 +-
.../gm2/recover/pass/recover-pass.exp | 2 +-
.../makeall/fail/switches-makeall-fail.exp| 2 +-
.../makeall/pass/switches-makeall-pass.exp| 2 +-
.../gm2/switches/none/run/pass/gm2-none.exp | 2 +-
.../pim2/run/pass/switches-pim2-run-pass.exp | 2 +-
gcc/testsuite/gm2/ulmlib/pass/ulmlib-pass.exp | 2 +-
.../gm2/ulmlib/std/pass/ulmlib-std-pass.exp | 2 +-
.../gm2/ulmlib/sys/pass/ulmlib-sys-pass.exp | 2 +-
gcc/testsuite/lib/gm2.exp | 325 ++
26 files changed, 200 insertions(+), 176 deletions(-)
diff --git a/gcc/testsuite/gm2/case/pass/case-pass.exp
b/gcc/testsuite/gm2/case/pass/case-pass.exp
index 9c7211b2b5a..e73e4b4e073 100644
--- a/gcc/testsuite/gm2/case/pass/case-pass.exp
+++ b/gcc/testsuite/gm2/case/pass/case-pass.exp
@@ -25,7 +25,7 @@ if $tracelevel then {
# load support procs
load_lib gm2-torture.exp
-gm2_init_pim ${srcdir}/gm2/case/pass;
+gm2_init_pim "${srcdir}/gm2/case/pass"
foreach testcase [lsort [glob -nocomplain $srcdir/$subdir/*.mod]] {
# If we're only testing specific files and this isn't one of them, skip it.
diff --git a/gcc/testsuite/gm2/complex/pass/complex-pass.exp
b/gcc/testsuite/gm2/complex/pass/complex-pass.exp
index 91d8323ba80..a661be1be56 100644
--- a/gcc/testsuite/gm2/complex/pass/complex-pass.exp
+++ b/gcc/testsuite/gm2/complex/pass/complex-pass.exp
@@ -25,7 +25,7 @@ if $
Re: [PATCH] Modula-2, testsuite: Remove use of concatenated paths.
Iain Sandoe writes: > tested on x86_64-darwin21 with an updated compiler that does not support > the path concatentation and on an unpatched trunk. > OK for trunk? > thanks > Iain > > --- 8< --- > > The original implementation for Modula-2 search paths allows things like > '-I/path/a:/path/b'. Such paths are not compatible with the rest of the > compiler (in particular, the preprocessor, which Modula-2 uses). In > preparation for removing that idiom, this patch rewrites the cases in the > testsuite and removes string processing where possible from lists of paths. > > TODO: There are some apparent discrepancies and/or extraneous insertions > of partial include paths (especially in gm2_init_log, gm2_init_iso and > gm2_init_pim) - to be handled in some future patch. > > Signed-off-by: Iain Sandoe > > gcc/testsuite/ChangeLog: > > * gm2/case/pass/case-pass.exp: Update for removal of concatenated > paths. > * gm2/complex/pass/complex-pass.exp: Likewise. > * gm2/coroutines/pim/run/pass/coroutines-pim-run-pass.exp: Likewise. > * gm2/iso/analysis/fail/iso-analysis-fail.xp: Likewise. > * gm2/iso/check/fail/iso-check-fail.exp: Likewise. > * gm2/iso/fail/iso-fail.exp: Likewise. > * gm2/iso/pass/iso-pass.exp: Likewise. > * gm2/isolib/run/pass/isolib-run-pass.exp: Likewise. > * gm2/pim/fail/pim-fail.exp: Likewise. > * gm2/pim/pass/pim-pass.exp: Likewise. > * gm2/pimlib/logitech/run/pass/pimlib-logitech-run-pass.exp: Likewise. > * gm2/pimlib/pass/pimlib-pass.exp: Likewise. > * gm2/pimlib/run/pass/pimlib-run-pass.exp: Likewise. > * gm2/projects/iso/run/pass/halma/projects-iso-run-pass-halma.exp: > Likewise. > * gm2/projects/iso/run/pass/hello/projects-iso-run-pass-hello.exp: > Likewise. > * gm2/projects/log/run/pass/hello/projects-log-run-pass-hello.exp: > Likewise. > * gm2/projects/pim/run/pass/hello/projects-pim-run-pass-hello.exp: > Likewise. > * gm2/recover/pass/recover-pass.exp: Likewise. > * gm2/switches/makeall/fail/switches-makeall-fail.exp: Likewise. > * gm2/switches/makeall/pass/switches-makeall-pass.exp: Likewise. > * gm2/switches/none/run/pass/gm2-none.exp: Likewise. > * gm2/switches/pim2/run/pass/switches-pim2-run-pass.exp: Likewise. > * gm2/ulmlib/pass/ulmlib-pass.exp: Likewise. > * gm2/ulmlib/std/pass/ulmlib-std-pass.exp: Likewise. > * gm2/ulmlib/sys/pass/ulmlib-sys-pass.exp: Likewise. > * lib/gm2.exp: Make the paths list a mandatory entry for each > gm2_init_xxx > function. Remove the use of concatenated include and library paths. > Remove string processing where possible. LGTM - many thanks, regards, Gaius
Re: [PATCH 1/2] select .rodata for const volatile variables.
On 1/19/23 02:59, Cupertino Miranda wrote: Hi Jeff, Kindly calling your attention to this thread. Sorry, just crazy busy around here. Jeff
Re: [PATCH 1/2] select .rodata for const volatile variables.
On 1/9/23 00:57, Richard Biener wrote: On Mon, Dec 5, 2022 at 7:07 PM Jeff Law via Gcc-patches wrote: On 12/2/22 10:52, Cupertino Miranda via Gcc-patches wrote: Changed target code to select .rodata section for 'const volatile' defined variables. This change is in the context of the bugzilla #170181. gcc/ChangeLog: v850.c(v850_select_section): Changed function. I'm not sure this is safe/correct. ISTM that you need to look at the underlying TREE_TYPE to check for const-volatile rather than TREE_SIDE_EFFECTS. Just to quote tree.h: /* In any expression, decl, or constant, nonzero means it has side effects or reevaluation of the whole expression could produce a different value. This is set if any subexpression is a function call, a side effect or a reference to a volatile variable. In a ..._DECL, this is set only if the declaration said `volatile'. This will never be set for a constant. */ #define TREE_SIDE_EFFECTS(NODE) \ (NON_TYPE_CHECK (NODE)->base.side_effects_flag) so if exp is a decl then that's the volatile check. Ah, then we can just use TREE_SIDE_EFFECTS for testing if a _DECL node is volatile. So that concern is a non-issue. I think that was the only concern with patch #1. I'll install it momentarily. Jeff
Re: [PATCH 2/2] Corrected pr25521.c target matching.
On 12/7/22 08:45, Cupertino Miranda wrote: On 12/2/22 10:52, Cupertino Miranda via Gcc-patches wrote: This commit is a follow up of bugzilla #107181. The commit /a0aafbc/ changed the default implementation of the SELECT_SECTION hook in order to match clang/llvm behaviour w.r.t the placement of `const volatile' objects. However, the following targets use target-specific selection functions and they choke on the testcase pr25521.c: *rx - target sets its const variables as '.section C,"a",@progbits'. That's presumably a constant section. We should instead twiddle the test to recognize that section. Although @progbits is indeed a constant section, I believe it is more interesting to detect if the `rx' starts selecting more standard sections instead of the current @progbits. That was the reason why I opted to XFAIL instead of PASSing it. Can I keep it as such ? I'm not aware of any ongoing development for that port, so I would not let concerns about the rx port changing behavior dominate how we approach this problem. The rx port is using a different name for the section. That's valid thing to do and to the extent we can, we should support that in the test rather than (incorrectly IMHO) xfailing the test just becuase the name isn't what we expected. To avoid over-eagerly matching, I would probably search for "C," I wouldn't do that for the const or rodata sections as they often have a suffix like 1, 2, 4, 8 for different sized rodata sections. PPC32 is explicitly doing something different and placing those objects into an RW section. So for PPC32 it makes more sense to skip the test rather than xfail it. Jeff
Re: [PATCH] RISC-V: Add TARGET_MIN_VLEN > 32 into iterators of EEW = 64 vector modes
On 1/20/23 02:33, juzhe.zh...@rivai.ai wrote: From: Ju-Zhe Zhong According to RVV ISA, RVV doesn't support EEW == 64 vector type for zve32x and zve32f. So it makes sense add predicate in the iterators of EEW = 64 vector modes. gcc/ChangeLog: * config/riscv/vector-iterators.md: Add TARGET_MIN_VLEN > 32 predicates. OK. Jeff
Re: [PATCH] RISC-V: Add :: for static function calling to avoid confusing
On 1/17/23 20:16, juzhe.zh...@rivai.ai wrote: From: Ju-Zhe Zhong Since we have same function in class and static function calling get_avl. Adding :: to avoid codes confusing. gcc/ChangeLog: * config/riscv/riscv-vsetvl.cc (pass_vsetvl::get_backward_fusion_type): Add ::. Is there any reasonable way to avoid having the same name? ISTM that's the root of the problem and adding "::" is just papering over the real issue. Jeff
Re: [PATCH] RISC-V: Change parse_insn into public for future use.
On 1/17/23 20:06, juzhe.zh...@rivai.ai wrote: From: Ju-Zhe Zhong gcc/ChangeLog: * config/riscv/riscv-vsetvl.h: Change it into public. OK. jeff
Re: [PATCH] RISC-V: Reorder VSETVL PASS location
On 1/17/23 20:03, juzhe.zh...@rivai.ai wrote: From: Ju-Zhe Zhong gcc/ChangeLog: * config/riscv/riscv-passes.def (INSERT_PASS_BEFORE): Reorder VSETVL PASS. It'd be useful to know the motivation here, I could easily see someone in the future finding a case where the location of the vsetvl gets influenced by some dead code that would have been removed by the DCE pass. Then they're going to want to know the motivation behind the current pass placement. So, OK after adding a comment describing why the pass is placed where it is. Jeff
Re: [PATCH] RISC-V: Clang-format some annotations[NFC]
On 1/17/23 19:58, juzhe.zh...@rivai.ai wrote: From: Ju-Zhe Zhong gcc/ChangeLog: * config/riscv/riscv-vsetvl.cc: Clang-format. OK. jeff
Re: [PATCH] RISC-V: Remove DCE in VSETVL PASS
On 1/17/23 19:53, juzhe.zh...@rivai.ai wrote: From: Ju-Zhe Zhong gcc/ChangeLog: * config/riscv/riscv-vsetvl.cc (pass_vsetvl::done): Remove DCE. * config/riscv/t-riscv: Ditto. OK. Presumably this is because the pass is now placed before DCE. Jeff
Re: [PATCH] RISC-V: Change VSETVL PASS always call split_all_insns
On 1/17/23 19:50, juzhe.zh...@rivai.ai wrote: From: Ju-Zhe Zhong Since LCM will destroy CFG, we are going to reorder the location of VSETVL PASS at least before bbro (block-reorder PASS) which is before split3 PASS. We need to call it in VSETVL PASS to get final RVV instructions patterns. Just for the record. LCM does not destroy the CFG, it just splits critical edges. gcc/ChangeLog: * config/riscv/riscv-vsetvl.cc (pass_vsetvl::execute): Always call split_all_insns. OK. jeff
*PING* [PATCH] Fortran: fix ICE in check_charlen_present [PR108420]
Ping! Am 16.01.23 um 22:11 schrieb Harald Anlauf via Gcc-patches: Dear all, it appears that the fix for pr107874 uncovered a latent bug for the case of arrays of type character and size zero when passed to the intrinsics MERGE and SPREAD as SOURCE. In that case, there is no constructor from which we could obtain another character length. A reasonable solution seems to retain the array's character length. Since I could not find a simple case where this fails, I've added an assertion that we actually have a meaningful length. Regtested on x86_64-pc-linux-gnu. OK for mainline? Thanks, Harald
[committed] pru: Fix CLZ expansion for QI and HI modes
The recent gcc.dg/tree-ssa/clz-char.c test case failed for PRU target,
exposing a wrong code generation bug in the PRU backend. The "clz"
pattern did not produce correct output for QI and HI input operand
modes. SI mode is ok.
The "clz" pattern is expanded to an LMBD instruction to get the
left-most bit position having value "1". In turn, to get the correct
"clz" value, that bit position must be subtracted from the MSB bit
position of the input operand. The old behaviour of hard-coding 31
for MSB bit position is wrong.
The LMBD instruction returns 32 if input operand is zero, irrespective
of its register mode. This maps nicely for SI mode, where the "clz"
pattern outputs -1. It also leads to peculiar (but valid!) output
values from the "clz" pattern for QI and HI zero-valued inputs.
Pushed to trunk. This patch is confined to the PRU backend only,
and is fixing a wrong code generation. Hence I deem it suitable
for stage 4.
Is it ok to push a backport to gcc-11 and gcc-12 branches?
gcc/ChangeLog:
* config/pru/pru.h (CLZ_DEFINED_VALUE_AT_ZERO): Fix value for QI
and HI input modes.
* config/pru/pru.md (clz): Fix generated code for QI and HI
input modes.
gcc/testsuite/ChangeLog:
* gcc.target/pru/clz-hi-2.c: New test.
* gcc.target/pru/clz-hi.c: New test.
Signed-off-by: Dimitar Dimitrov
---
gcc/config/pru/pru.h| 5 ++--
gcc/config/pru/pru.md | 15 ---
gcc/testsuite/gcc.target/pru/clz-hi-2.c | 24 +
gcc/testsuite/gcc.target/pru/clz-hi.c | 35 +
4 files changed, 74 insertions(+), 5 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/pru/clz-hi-2.c
create mode 100644 gcc/testsuite/gcc.target/pru/clz-hi.c
diff --git a/gcc/config/pru/pru.h b/gcc/config/pru/pru.h
index 3658036cccb..1b5e874bc06 100644
--- a/gcc/config/pru/pru.h
+++ b/gcc/config/pru/pru.h
@@ -566,8 +566,9 @@ do {
\
#define CASE_VECTOR_MODE Pmode
-/* See definition of clz pattern for rationale of value -1. */
-#define CLZ_DEFINED_VALUE_AT_ZERO(MODE, VALUE) ((VALUE) = -1, 2)
+/* See definition of clz pattern for rationale of the value. */
+#define CLZ_DEFINED_VALUE_AT_ZERO(MODE, VALUE) \
+ ((VALUE) = GET_MODE_BITSIZE (MODE) - 1 - 32, 2)
/* Jumps are cheap on PRU. */
#define LOGICAL_OP_NON_SHORT_CIRCUIT 0
diff --git a/gcc/config/pru/pru.md b/gcc/config/pru/pru.md
index dfe08071e04..aa8e42a3587 100644
--- a/gcc/config/pru/pru.md
+++ b/gcc/config/pru/pru.md
@@ -1723,8 +1723,16 @@ (define_insn "pru_halt"
[(set_attr "type" "control")])
;; Count Leading Zeros implemented using LMBD.
-;; LMBD returns 32 if bit value is not present, and we subtract 31 to get CLZ.
-;; Hence we get a defined value -1 for CLZ_DEFINED_VALUE_AT_ZERO.
+;;
+;; LMBD returns 32 if bit value is not present, for any kind of input MODE.
+;; The LMBD's search result for a "1" bit is subtracted from the
+;; mode bit size minus one, in order to get CLZ.
+;;
+;; Hence for SImode we get a defined value -1 for CLZ_DEFINED_VALUE_AT_ZERO.
+;;
+;; The QImode and HImode defined values for zero inputs end up to be
+;; non-standard (-25 and -17). But this is considered acceptable in
+;; order to keep the CLZ expansion to only two instructions.
(define_expand "clz2"
[(set (match_operand:QISI 0 "register_operand")
(clz:QISI (match_operand:QISI 1 "register_operand")))]
@@ -1735,7 +1743,8 @@ (define_expand "clz2"
rtx tmpval = gen_reg_rtx (mode);
emit_insn (gen_pru_lmbd (mode, tmpval, src, const1_rtx));
- emit_insn (gen_sub3_insn (dst, GEN_INT (31), tmpval));
+ int msb_bitn = GET_MODE_BITSIZE (mode) - 1;
+ emit_insn (gen_sub3_insn (dst, GEN_INT (msb_bitn), tmpval));
DONE;
})
diff --git a/gcc/testsuite/gcc.target/pru/clz-hi-2.c
b/gcc/testsuite/gcc.target/pru/clz-hi-2.c
new file mode 100644
index 000..af877c7021e
--- /dev/null
+++ b/gcc/testsuite/gcc.target/pru/clz-hi-2.c
@@ -0,0 +1,24 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fno-tree-ch" } */
+
+/* This test case is based on gcc.dg/tree-ssa/clz-char.c. */
+
+#define PREC (sizeof(short) * 8)
+
+int
+__attribute__ ((noinline, noclone))
+foo (unsigned short b) {
+int c = 0;
+
+if (b == 0)
+ return PREC;
+
+while (!(b & (1 << (PREC - 1 {
+ b <<= 1;
+ c++;
+}
+
+return c;
+}
+
+/* { dg-final { scan-assembler "lmbd\\tr\[012\]\[0-9\]?.w\[0-2\],
r\[012\]\[0-9\]?.w\[0-2\], 1" } } */
diff --git a/gcc/testsuite/gcc.target/pru/clz-hi.c
b/gcc/testsuite/gcc.target/pru/clz-hi.c
new file mode 100644
index 000..9350913b6d5
--- /dev/null
+++ b/gcc/testsuite/gcc.target/pru/clz-hi.c
@@ -0,0 +1,35 @@
+/* { dg-do run } */
+/* { dg-options "-O2 -fno-tree-ch -fdump-tree-optimized" } */
+
+/* This test case is based on gcc.dg/tree-ssa/clz-char.c. */
+
+#define PREC (sizeof(short) * 8)
+
+int
+__attribute__ ((noinline, nocl
Re: [PATCH] c++: Handle structured bindings like anon unions in initializers [PR108474]
On 1/21/23 04:59, Jakub Jelinek wrote:
Hi!
As reported by Andrew Pinski, structured bindings (with the exception
of the ones using std::tuple_{size,element} and get which are really
standalone variables in addition to the binding one) also use
DECL_VALUE_EXPR and needs the same treatment in static initializers.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok
for trunk?
2023-01-21 Jakub Jelinek
PR c++/108474
* cp-gimplify.cc (cp_fold_r): Handle structured bindings
vars like anon union artificial vars.
* g++.dg/cpp1z/decomp57.C: New test.
* g++.dg/cpp1z/decomp58.C: New test.
--- gcc/cp/cp-gimplify.cc.jj2023-01-19 23:27:27.998400866 +0100
+++ gcc/cp/cp-gimplify.cc 2023-01-20 11:00:06.093446737 +0100
@@ -1012,8 +1012,12 @@ cp_fold_r (tree *stmt_p, int *walk_subtr
case VAR_DECL:
/* In initializers replace anon union artificial VAR_DECLs
-with their DECL_VALUE_EXPRs, as nothing will do it later. */
- if (DECL_ANON_UNION_VAR_P (stmt) && !data->genericize)
+with their DECL_VALUE_EXPRs, as nothing will do it later.
+Ditto for structured bindings. */
+ if (!data->genericize
+ && DECL_HAS_VALUE_EXPR_P (stmt)
+ && (DECL_ANON_UNION_VAR_P (stmt)
+ || (DECL_DECOMPOSITION_P (stmt) && DECL_DECOMP_BASE (stmt
Is there a reason not to do this for all cases of DECL_HAS_VALUE_EXPR_P,
without the extra checks?
{
*stmt_p = stmt = unshare_expr (DECL_VALUE_EXPR (stmt));
break;
--- gcc/testsuite/g++.dg/cpp1z/decomp57.C.jj2023-01-20 11:02:08.547656638
+0100
+++ gcc/testsuite/g++.dg/cpp1z/decomp57.C 2023-01-20 10:53:01.781649565
+0100
@@ -0,0 +1,27 @@
+// PR c++/108474
+// { dg-do link { target c++17 } }
+
+struct T { int i, j; };
+T h;
+auto [i, j] = h;
+int &r = i;
+int s = i;
+int *t = &i;
+
+void
+foo (int **p, int *q)
+{
+ static int &u = i;
+ static int v = i;
+ static int *w = &i;
+ int &x = i;
+ int y = i;
+ int *z = &i;
+ *p = &i;
+ *q = i;
+}
+
+int
+main ()
+{
+}
--- gcc/testsuite/g++.dg/cpp1z/decomp58.C.jj2023-01-20 11:02:12.314601575
+0100
+++ gcc/testsuite/g++.dg/cpp1z/decomp58.C 2023-01-20 10:54:02.117767542
+0100
@@ -0,0 +1,39 @@
+// PR c++/108474
+// { dg-do link { target c++17 } }
+
+namespace std {
+ template struct tuple_size;
+ template struct tuple_element;
+}
+
+struct A {
+ int i;
+ template int& get() { return i; }
+};
+
+template <> struct std::tuple_size { static const int value = 2; };
+template struct std::tuple_element { using type = int; };
+
+struct A a;
+auto [i, j] = a;
+int &r = i;
+int s = i;
+int *t = &i;
+
+void
+foo (int **p, int *q)
+{
+ static int &u = i;
+ static int v = i;
+ static int *w = &i;
+ int &x = i;
+ int y = i;
+ int *z = &i;
+ *p = &i;
+ *q = i;
+}
+
+int
+main ()
+{
+}
Jakub
Re: [PATCH] c++: Handle structured bindings like anon unions in initializers [PR108474]
On Sun, Jan 22, 2023 at 03:40:26PM -0500, Jason Merrill wrote: > > 2023-01-21 Jakub Jelinek > > > > PR c++/108474 > > * cp-gimplify.cc (cp_fold_r): Handle structured bindings > > vars like anon union artificial vars. > > > > * g++.dg/cpp1z/decomp57.C: New test. > > * g++.dg/cpp1z/decomp58.C: New test. > > > > --- gcc/cp/cp-gimplify.cc.jj2023-01-19 23:27:27.998400866 +0100 > > +++ gcc/cp/cp-gimplify.cc 2023-01-20 11:00:06.093446737 +0100 > > @@ -1012,8 +1012,12 @@ cp_fold_r (tree *stmt_p, int *walk_subtr > > case VAR_DECL: > > /* In initializers replace anon union artificial VAR_DECLs > > -with their DECL_VALUE_EXPRs, as nothing will do it later. */ > > - if (DECL_ANON_UNION_VAR_P (stmt) && !data->genericize) > > +with their DECL_VALUE_EXPRs, as nothing will do it later. > > +Ditto for structured bindings. */ > > + if (!data->genericize > > + && DECL_HAS_VALUE_EXPR_P (stmt) > > + && (DECL_ANON_UNION_VAR_P (stmt) > > + || (DECL_DECOMPOSITION_P (stmt) && DECL_DECOMP_BASE (stmt > > Is there a reason not to do this for all cases of DECL_HAS_VALUE_EXPR_P, > without the extra checks? I was just trying to be careful, because unfortunately this spot doesn't mean it really is only expanded in static var DECL_INITIAL, it can make it into dynamic initializers, and most of DECL_VALUE_EXPRs appear only in runtime code, otherwise we'd have much more of these issues. But if you think it is ok, I'll test tonight a version just with if (!data->genericize && DECL_HAS_VALUE_EXPR_P (stmt) Jakub
Re: [PATCH] c++: Handle structured bindings like anon unions in initializers [PR108474]
On 1/22/23 15:50, Jakub Jelinek wrote: On Sun, Jan 22, 2023 at 03:40:26PM -0500, Jason Merrill wrote: 2023-01-21 Jakub Jelinek PR c++/108474 * cp-gimplify.cc (cp_fold_r): Handle structured bindings vars like anon union artificial vars. * g++.dg/cpp1z/decomp57.C: New test. * g++.dg/cpp1z/decomp58.C: New test. --- gcc/cp/cp-gimplify.cc.jj2023-01-19 23:27:27.998400866 +0100 +++ gcc/cp/cp-gimplify.cc 2023-01-20 11:00:06.093446737 +0100 @@ -1012,8 +1012,12 @@ cp_fold_r (tree *stmt_p, int *walk_subtr case VAR_DECL: /* In initializers replace anon union artificial VAR_DECLs -with their DECL_VALUE_EXPRs, as nothing will do it later. */ - if (DECL_ANON_UNION_VAR_P (stmt) && !data->genericize) +with their DECL_VALUE_EXPRs, as nothing will do it later. +Ditto for structured bindings. */ + if (!data->genericize + && DECL_HAS_VALUE_EXPR_P (stmt) + && (DECL_ANON_UNION_VAR_P (stmt) + || (DECL_DECOMPOSITION_P (stmt) && DECL_DECOMP_BASE (stmt Is there a reason not to do this for all cases of DECL_HAS_VALUE_EXPR_P, without the extra checks? I was just trying to be careful, because unfortunately this spot doesn't mean it really is only expanded in static var DECL_INITIAL, it can make it into dynamic initializers, and most of DECL_VALUE_EXPRs appear only in runtime code, otherwise we'd have much more of these issues. But it shouldn't be harmful anywhere, right? But if you think it is ok, I'll test tonight a version just with if (!data->genericize && DECL_HAS_VALUE_EXPR_P (stmt) OK with that change. Though, actually, why not instead fix expand_expr_real_1 (and staticp) to look through DECL_VALUE_EXPR? Jason
[pushed] c++: lifetime extension with .* expression [PR53288]
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
This PR points out a case where we are not extending the lifetime of a
temporary when the subobject is denoted by a pointer-to-member operation.
These rules were clarified in C++20 by CWG1299.
There are other cases that also need to be handled under CWG1299, but are
not fixed by this patch.
PR c++/53288
DR 1299
gcc/cp/ChangeLog:
* call.cc (extend_ref_init_temps_1): Handle ptrmem expression.
gcc/testsuite/ChangeLog:
* g++.dg/init/lifetime4.C: New test.
---
gcc/cp/call.cc| 38 ++
gcc/testsuite/g++.dg/init/lifetime4.C | 39 +++
2 files changed, 77 insertions(+)
create mode 100644 gcc/testsuite/g++.dg/init/lifetime4.C
diff --git a/gcc/cp/call.cc b/gcc/cp/call.cc
index bd174b8d655..37297738d0f 100644
--- a/gcc/cp/call.cc
+++ b/gcc/cp/call.cc
@@ -13950,6 +13950,34 @@ static tree
extend_ref_init_temps_1 (tree decl, tree init, vec **cleanups,
tree *cond_guard)
{
+ /* CWG1299 (C++20): The temporary object to which the reference is bound or
+ the temporary object that is the complete object of a subobject to which
+ the reference is bound persists for the lifetime of the reference if the
+ glvalue to which the reference is bound was obtained through one of the
+ following:
+ - a temporary materialization conversion ([conv.rval]),
+ - ( expression ), where expression is one of these expressions,
+ - subscripting ([expr.sub]) of an array operand, where that operand is one
+ of these expressions,
+ - a class member access ([expr.ref]) using the . operator where the left
+ operand is one of these expressions and the right operand designates a
+ non-static data member of non-reference type,
+ - a pointer-to-member operation ([expr.mptr.oper]) using the .* operator
+ where the left operand is one of these expressions and the right operand
+ is a pointer to data member of non-reference type,
+ - a const_cast ([expr.const.cast]), static_cast ([expr.static.cast]),
+ dynamic_cast ([expr.dynamic.cast]), or reinterpret_cast
+ ([expr.reinterpret.cast]) converting, without a user-defined conversion,
+ a glvalue operand that is one of these expressions to a glvalue that
+ refers to the object designated by the operand, or to its complete
+ object or a subobject thereof,
+ - a conditional expression ([expr.cond]) that is a glvalue where the
+ second or third operand is one of these expressions, or
+ - a comma expression ([expr.comma]) that is a glvalue where the right
+ operand is one of these expressions. */
+
+ /* FIXME several cases are still handled wrong (101572, 81420). */
+
tree sub = init;
tree *p;
STRIP_NOPS (sub);
@@ -13960,6 +13988,16 @@ extend_ref_init_temps_1 (tree decl, tree init,
vec **cleanups,
cond_guard);
return init;
}
+ if (TREE_CODE (sub) == POINTER_PLUS_EXPR
+ && TYPE_PTRDATAMEM_P (TREE_TYPE (tree_strip_nop_conversions
+ (TREE_OPERAND (sub, 1)
+{
+ /* A pointer-to-member operation. */
+ TREE_OPERAND (sub, 0)
+ = extend_ref_init_temps_1 (decl, TREE_OPERAND (sub, 0), cleanups,
+ cond_guard);
+ return init;
+}
if (TREE_CODE (sub) == COND_EXPR)
{
tree cur_cond_guard = NULL_TREE;
diff --git a/gcc/testsuite/g++.dg/init/lifetime4.C
b/gcc/testsuite/g++.dg/init/lifetime4.C
new file mode 100644
index 000..4106af7070c
--- /dev/null
+++ b/gcc/testsuite/g++.dg/init/lifetime4.C
@@ -0,0 +1,39 @@
+// PR c++/53288
+// { dg-do compile { target c++11 } }
+
+struct B {
+ B(int data) : _data(data) { }
+ ~B() { }
+
+ int _data;
+
+private:
+ B() = delete;
+ B(const B &) = delete;
+ B(B &&) = delete;
+};
+
+int c,d;
+struct A {
+ B b;
+ A(int data) : b(data) { ++c; }
+ ~A() { ++d; }
+
+private:
+ A() = delete;
+ A(const A &) = delete;
+ A(A &&) = delete;
+};
+
+template
+void f(T t) {
+ const B &b = A(1).*t;
+ if (d) __builtin_abort ();
+}
+
+int main() {
+ const B &b = A(1).*(&A::b);
+ if (d) __builtin_abort ();
+
+ f(&A::b);
+}
base-commit: 1dcc9779d6196db6dd881fffc91d731cbea7c8bc
--
2.31.1
[wwwdocs] lists: Add documentation about the Sourceware public-inbox
--- Evening, I've gone through lists.html and documented the Sourceware public-inbox instance, since it seems to be commonly missed, yet some might find useful. This patch includes: - A brief summary of what the public-inbox provides, - A brief summary on alternative methods of accessing the archives, and - Convenience links next to each ML link that allows the reader to quickly jump to the public-inbox. Thanks in advance, have a lovely night! htdocs/lists.html | 110 -- 1 file changed, 88 insertions(+), 22 deletions(-) diff --git a/htdocs/lists.html b/htdocs/lists.html index b50e9ac3..89be66c9 100644 --- a/htdocs/lists.html +++ b/htdocs/lists.html @@ -21,11 +21,57 @@ Please make yourself familiar with our policies before subscribing and posting to these lists. + + The mailing lists are available in two frontends: the traditional Pipermail + and the newer https://public-inbox.org/";>public-inbox, which + some might find more friendly or useful, as it allows following threads that + span months, etc. Both are linked below, with (inbox) leading + to the public-inbox archive. + + + + The public-inbox archives also provide an alternative search interface. It + is described on the help page for each index (as an example, see the + https://inbox.sourceware.org/gcc-help/_/text/help/";>gcc-help help +page), in the search section. + + + + You might also be interested in accessing the archives via alternative + protocols. Two are supported: + + + + Git + +The archives are indexed by https://git-scm.com/";>git, and +hence, they can be downloaded in full or mirrored by anyone. The format +for the URLs of these repositories +is https://inbox.sourceware.org/listname/epoch. +Please consult each lists respective page for a list of available epochs, +as well as complete instructions. + + NNTP + Sourceware exposes read-only NNTP access +via nntp://inbox.sourceware.org/inbox.gcc.listname. +A similar scheme works for other projects indexed on +the https://inbox.sourceware.org/";>public-inbox, but with +different prefixes. Please consult the mirror page of each list for more +information. + + IMAP + Similarly, archives are also exposed over IMAP via + imap://;AUTH=anonym...@inbox.sourceware.org/inbox.gcc.listname. +More information about IMPA access is also available on the respective +lists mirror page. + + Announcement lists: - https://gcc.gnu.org/ml/gcc-announce/";>gcc-announce + https://gcc.gnu.org/ml/gcc-announce/";>gcc-announce + https://inbox.sourceware.org/gcc-announce";>(inbox) is a read-only low volume list where we post announcements about releases or other important events. @@ -33,11 +79,13 @@ before subscribing and posting to these lists. Open lists: - https://gcc.gnu.org/ml/gcc-help/";>gcc-help + https://gcc.gnu.org/ml/gcc-help/";>gcc-help + https://inbox.sourceware.org/gcc-help";>(inbox) is a relatively high volume list for people searching for help in building or using GCC. - https://gcc.gnu.org/ml/gcc/";>gcc + https://gcc.gnu.org/ml/gcc/";>gcc + https://inbox.sourceware.org/gcc";>(inbox) is a high volume list for general development discussions about GCC. Anything relevant to the development or testing of GCC and not covered by other mailing lists is suitable for discussion here. @@ -52,25 +100,30 @@ before subscribing and posting to these lists. sufficient to follow the major trends and important news in GCC's development process. - https://gcc.gnu.org/ml/gcc-bugs/";>gcc-bugs + https://gcc.gnu.org/ml/gcc-bugs/";>gcc-bugs + https://inbox.sourceware.org/gcc-bugs";>(inbox) is a relatively high volume list with mails from our bug-tracking system. - https://gcc.gnu.org/ml/gcc-patches/";>gcc-patches + https://gcc.gnu.org/ml/gcc-patches/";>gcc-patches + https://inbox.sourceware.org/gcc-patches";>(inbox) is a relatively high volume list for patch submissions and discussion of particular patches. All patches (including those for front ends and web pages) and all discussion for a particular patch should be sent to this list. - https://gcc.gnu.org/ml/gcc-testresults/";> - gcc-testresults is a moderate volume list where test results for + https://gcc.gnu.org/ml/gcc-testresults/";>gcc-testresults + https://inbox.sourceware.org/gcc-testresults";>(inbox) + is a moderate volume list where test results for the GCC compilers are posted. - https://gcc.gnu.org/ml/gcc-regression/";>gcc-regression + https://gcc.gnu.org/ml/gcc-regression/";>gcc-regression + https://inbox.sourceware.org/gcc-regression";>(inbox) is a moderate volume list where regression results for the GCC compilers are posted. - https://gcc.gnu.org/ml/gcc-rust/";>gcc-rust + https://gcc.gnu.org/ml/gcc-rust/";>gcc-rust + https://inbox.sourceware.org/gcc-rust";>(inbox) is for di
Re: [wwwdocs] lists: Add documentation about the Sourceware public-inbox
Arsen Arsenović writes: > --- > Evening, > > I've gone through lists.html and documented the Sourceware public-inbox > instance, since it seems to be commonly missed, yet some might find useful. > > This patch includes: > - A brief summary of what the public-inbox provides, > - A brief summary on alternative methods of accessing the archives, and > - Convenience links next to each ML link that allows the reader to quickly >jump to the public-inbox. > > Thanks in advance, have a lovely night! > > htdocs/lists.html | 110 -- > 1 file changed, 88 insertions(+), 22 deletions(-) > > diff --git a/htdocs/lists.html b/htdocs/lists.html > index b50e9ac3..89be66c9 100644 > --- a/htdocs/lists.html > +++ b/htdocs/lists.html > @@ -21,11 +21,57 @@ Please make yourself familiar with href="#policies">our policies > before subscribing and posting to these lists. > > > + > + The mailing lists are available in two frontends: the traditional Pipermail > + and the newer https://public-inbox.org/";>public-inbox, which > + some might find more friendly or useful, as it allows following threads > that > + span months, etc. Both are linked below, with (inbox) leading > + to the public-inbox archive. > + > + > + > + The public-inbox archives also provide an alternative search interface. It > + is described on the help page for each index (as an example, see the > + https://inbox.sourceware.org/gcc-help/_/text/help/";>gcc-help help > +page), in the search section. > + > + > + > + You might also be interested in accessing the archives via alternative > + protocols. Two are supported: > + Gah! This should say three, of course. I didn't notice before sending. Please amend if applying. > + > + Git > + > +The archives are indexed by https://git-scm.com/";>git, and > +hence, they can be downloaded in full or mirrored by anyone. The format > +for the URLs of these repositories > +is > https://inbox.sourceware.org/listname/epoch. > +Please consult each lists respective page for a list of available epochs, > +as well as complete instructions. > + > + NNTP > + Sourceware exposes read-only NNTP access > +via nntp://inbox.sourceware.org/inbox.gcc.listname. > +A similar scheme works for other projects indexed on > +the https://inbox.sourceware.org/";>public-inbox, but with > +different prefixes. Please consult the mirror page of each list for more > +information. > + > + IMAP > + Similarly, archives are also exposed over IMAP via > + > imap://;AUTH=anonym...@inbox.sourceware.org/inbox.gcc.listname. > +More information about IMPA access is also available on the respective > +lists mirror page. > + > + > > Announcement lists: > > > - https://gcc.gnu.org/ml/gcc-announce/";>gcc-announce > + https://gcc.gnu.org/ml/gcc-announce/";>gcc-announce > + https://inbox.sourceware.org/gcc-announce";>(inbox) >is a read-only low volume list where >we post announcements about releases or other important events. > > @@ -33,11 +79,13 @@ before subscribing and posting > to these lists. > Open lists: > > > - https://gcc.gnu.org/ml/gcc-help/";>gcc-help > + https://gcc.gnu.org/ml/gcc-help/";>gcc-help > + https://inbox.sourceware.org/gcc-help";>(inbox) >is a relatively high volume list for people searching for help in >building or using GCC. > > - https://gcc.gnu.org/ml/gcc/";>gcc > + https://gcc.gnu.org/ml/gcc/";>gcc > + https://inbox.sourceware.org/gcc";>(inbox) >is a high volume list for general development discussions about GCC. >Anything relevant to the development or testing of GCC and not >covered by other mailing lists is suitable for discussion here. > @@ -52,25 +100,30 @@ before subscribing and posting > to these lists. >sufficient to follow the major trends and important news in GCC's >development process. > > - https://gcc.gnu.org/ml/gcc-bugs/";>gcc-bugs > + https://gcc.gnu.org/ml/gcc-bugs/";>gcc-bugs > + https://inbox.sourceware.org/gcc-bugs";>(inbox) >is a relatively high volume list with mails from our >bug-tracking system. > > - https://gcc.gnu.org/ml/gcc-patches/";>gcc-patches > + https://gcc.gnu.org/ml/gcc-patches/";>gcc-patches > + https://inbox.sourceware.org/gcc-patches";>(inbox) >is a relatively high volume list for patch submissions and discussion of >particular patches. All patches (including those for front ends and web >pages) and all discussion for a particular patch should be sent to this >list. > > - https://gcc.gnu.org/ml/gcc-testresults/";> > - gcc-testresults is a moderate volume list where test results for > + href="https://gcc.gnu.org/ml/gcc-testresults/";>gcc-testresults > + https://inbox.sourceware.org/gcc-testresults";>(inbox) > + is a moderate volume list where test results for >the GCC compilers are posted. > > - href="https://gcc.gnu.org/ml/gcc
Re: [PATCH v4] xtensa: Eliminate the use of callee-saved register that saves and restores only once
On 2023/01/23 0:45, Max Filippov wrote: > On Fri, Jan 20, 2023 at 8:39 PM Takayuki 'January June' Suwa > wrote: >> On 2023/01/21 0:14, Max Filippov wrote: >>> After having this many attempts and getting to the issues that are >>> really hard to detect I wonder if the target backend is the right place >>> for this optimization? >>> >> I guess they are not hard to detect > > I mean, on the testing side. check-gcc testsuite passed without new > regressions with this change, linux kernel smoke test passed, I was > almost convinced that it's ok to commit. > >> but just issues I didn't anticipate (and I just need a little more work). > > Looking at other peephole2 patterns I see that their code transformations > are much more compact and they don't need to track additional properties > of unrelated instructions. > >> And where else should it be done? What about implementing a >> target-specific pass just for one-point optimization? > > I don't even understand what's target-specific in this optimization? > It looks very generic to me. > Ah, I seem to have misunderstood what you meant, sorry. Now, what this patch is trying to do depends on whether register moves can be converted to stack pointer indirect loads/stores with offsets, and whether there is any benefit in doing so, but they are not target dependent. Is it? If we want the target-independent part to do something like this, we will need a mechanism (macro, hook, etc.) to write appropriate information in the machine description and pass it on. For example, offset ranges for register indirect loads and stores, or whether the ABI requires that callee-saved registers always be associated with stack slots, or even the need for stack frame construction... I totally agree that the peephole2 pattern is not the best implementation location.
[PATCH][_GLIBCXX_DEBUG] Remove useless checks
libstdc++: [_GLIBCXX_DEBUG] Remove useless constructor checks
Creating a safe iterator from a normal iterator is done within the
library where we
already know that it is done correctly. The rare situation where a
user would use safe
iterators for his own purpose is non-Standard code so outside
_GLIBCXX_DEBUG scope. For
those reasons the __msg_init_singular is useless and can be removed.
Additionally in the copy constructor used for post-increment and
post-decrement operators
the __msg_init_copy_singular check can also be ommitted because of
the preliminary
__msg_bad_inc and __msg_bad_dec checks.
libstdc++-v3/ChangeLog:
* include/debug/safe_iterator.h
(_Safe_iterator<>::_Unsafe_call): New.
(_Safe_iterator(const _Safe_iterator&, _Unsafe_call): New.
(_Safe_iterator::operator++(int)): Use latter.
(_Safe_iterator::operator--(int)): Likewise.
(_Safe_iterator(_Iterator, const _Safe_sequence_base*)):
Remove !_M_insular()
check.
* include/debug/safe_local_iterator.h
(_Safe_local_iterator<>::_Unsafe_call):
New.
(_Safe_local_iterator(const _Safe_local_iterator&,
_Unsafe_call): New.
(_Safe_local_iterator::operator++(int)): Use latter.
* src/c++11/debug.cc (_S_debug_messages): Add as comment
the _Debug_msg_id
entry associated to the array entry.
Tested under Linux x64.
Ok to commit ?
François
diff --git a/libstdc++-v3/include/debug/safe_iterator.h b/libstdc++-v3/include/debug/safe_iterator.h
index f364477a00c..570c826649f 100644
--- a/libstdc++-v3/include/debug/safe_iterator.h
+++ b/libstdc++-v3/include/debug/safe_iterator.h
@@ -129,6 +129,12 @@ namespace __gnu_debug
typename _Sequence::_Base::iterator,
typename _Sequence::_Base::const_iterator>::__type _OtherIterator;
+ struct _Unsafe_call { };
+
+ _Safe_iterator(const _Safe_iterator& __x, _Unsafe_call) _GLIBCXX_NOEXCEPT
+ : _Iter_base(__x.base()), _Safe_base()
+ { _M_attach(__x._M_sequence); }
+
public:
typedef _Iterator iterator_type;
typedef typename _Traits::iterator_category iterator_category;
@@ -154,11 +160,7 @@ namespace __gnu_debug
_Safe_iterator(_Iterator __i, const _Safe_sequence_base* __seq)
_GLIBCXX_NOEXCEPT
: _Iter_base(__i), _Safe_base(__seq, _S_constant())
- {
- _GLIBCXX_DEBUG_VERIFY(!this->_M_singular(),
- _M_message(__msg_init_singular)
- ._M_iterator(*this, "this"));
- }
+ { }
/**
* @brief Copy construction.
@@ -339,7 +341,7 @@ namespace __gnu_debug
_GLIBCXX_DEBUG_VERIFY(this->_M_incrementable(),
_M_message(__msg_bad_inc)
._M_iterator(*this, "this"));
- _Safe_iterator __ret = *this;
+ _Safe_iterator __ret(*this, _Unsafe_call());
++*this;
return __ret;
}
@@ -514,6 +516,13 @@ namespace __gnu_debug
protected:
typedef typename _Safe_base::_OtherIterator _OtherIterator;
+ typedef typename _Safe_base::_Unsafe_call _Unsafe_call;
+
+ _Safe_iterator(const _Safe_iterator& __x,
+ _Unsafe_call __unsafe_call) _GLIBCXX_NOEXCEPT
+ : _Safe_base(__x, __unsafe_call)
+ { }
+
public:
/// @post the iterator is singular and unattached
_Safe_iterator() _GLIBCXX_NOEXCEPT { }
@@ -596,7 +605,7 @@ namespace __gnu_debug
_GLIBCXX_DEBUG_VERIFY(this->_M_incrementable(),
_M_message(__msg_bad_inc)
._M_iterator(*this, "this"));
- _Safe_iterator __ret = *this;
+ _Safe_iterator __ret(*this, _Unsafe_call());
++*this;
return __ret;
}
@@ -627,7 +636,7 @@ namespace __gnu_debug
_GLIBCXX_DEBUG_VERIFY(this->_M_decrementable(),
_M_message(__msg_bad_dec)
._M_iterator(*this, "this"));
- _Safe_iterator __ret = *this;
+ _Safe_iterator __ret(*this, _Unsafe_call());
--*this;
return __ret;
}
@@ -653,6 +662,12 @@ namespace __gnu_debug
typedef _Safe_iterator<_OtherIterator, _Sequence,
std::random_access_iterator_tag> _OtherSelf;
+ typedef typename _Safe_base::_Unsafe_call _Unsafe_call;
+ _Safe_iterator(const _Safe_iterator& __x,
+ _Unsafe_call __unsafe_call) _GLIBCXX_NOEXCEPT
+ : _Safe_base(__x, __unsafe_call)
+ { }
+
public:
typedef typename _Safe_base::difference_type difference_type;
typedef typename _Safe_base::reference reference;
@@ -744,7 +759,7 @@ namespace __gnu_debug
_GLIBCXX_DEBUG_VERIFY(this->_M_incrementable(),
_M_message(__msg_bad_inc)
._M_iterator(*this, "this"));
- _Safe_iterator __ret = *this;
+ _Safe_iterator __ret(*this, _Unsafe_call());
++*this;
return __ret;
}
@@ -771,7 +786,7 @@ namespace __gnu_debug
_GLIBCXX_DEBUG_VERIFY(this->_M_decrementable(),
_M_message(__msg_bad_dec)
._M_iterator(*this, "this"));
- _Safe_iterator __ret = *this;
+ _Safe_iterator __ret(*this, _Unsafe_call());
--*this;
return _
Re: [PATCH] modula-2, driver, Front end: Revise handling of I and L paths [PR108182].
On Tue, Jan 17, 2023 at 6:05 PM Iain Sandoe via Gcc-patches
wrote:
>
> Tested on x86_64-linux-gnu (with a 32b multilib), powerpc, i686 and
> x86_64-darwin. OK for trunk?
Reading through the patch I fear there's more issues lurking
(-sysroot?) but this seems to be
a step in the right direction, so OK for trunk unless Gaius has more
comments or objections.
Can you mention PR108480 in the commit log?
Thanks,
Richard.
> thanks,
> Iain
>
> --- 8< ---
>
> The adds the includes in the FE as done in other GCC languages.
> It also revises the library handling to avoid additional -L options
> from hiding LIBDIR.
>
> For the include/import paths as presented to the front end initialisation,
> we capture them and then arrange to emit the 'standard library' paths in
> the same order as specified for C.
>
> The specs are tidied up.
>
> Signed-off-by: Iain Sandoe
>
> PR modula2/108182
>
> gcc/m2/ChangeLog:
>
> * Make-lang.in: Pass libsubdir to the language init
> build.
> * gm2-lang.cc (INCLUDE_VECTOR): Define.
> (add_one_import_path): New.
> (add_m2_import_paths): New.
> (gm2_langhook_post_options): Arrange to add the include
> paths (and add the system ones) in the same order as C
> uses.
> * gm2spec.cc (build_archive_path): Remove.
> (add_default_combination): Remove.
> (add_default_archives): Remove.
> (add_default_libs): We no longer need a '-L' option, just
> emit the -l and each library in use.
> (build_include_path): Remove.
> (add_include): Remove.
> (add_default_includes): Remove.
> (library_installed): Remove.
> (check_valid_library): Remove.
> (check_valid_list): Remove.
> (convert_abbreviation): Diagnose unhandled cases.
> (lang_specific_driver): Skip options where we will add back
> a validated version.
> * lang-specs.h (M2CPP): Reformat, append %I when -fcpp is not
> in use. Revise the cc1gm2 spec to omit mentioning options that
> are handled in the c pre-processor line.
> * lang.opt: Allow preprocessing and path options as input to the
> cc1gm2 invocation, so that they can be passed to the preprocessor
> invocation.
> ---
> gcc/m2/Make-lang.in | 1 +
> gcc/m2/gm2-lang.cc | 168 --
> gcc/m2/gm2spec.cc | 344
> gcc/m2/lang-specs.h | 13 +-
> gcc/m2/lang.opt | 48 +++
> 5 files changed, 304 insertions(+), 270 deletions(-)
>
> diff --git a/gcc/m2/Make-lang.in b/gcc/m2/Make-lang.in
> index 367be8e8af7..00cca7de617 100644
> --- a/gcc/m2/Make-lang.in
> +++ b/gcc/m2/Make-lang.in
> @@ -543,6 +543,7 @@ m2/gm2-gcc/m2configure.o:
> $(srcdir)/m2/gm2-gcc/m2configure.cc \
>
> m2/gm2-lang.o: $(srcdir)/m2/gm2-lang.cc gt-m2-gm2-lang.h
> $(GCC_HEADER_DEPENDENCIES_FOR_M2)
> $(COMPILER) -c -g $(GM2GCC) $(ALL_COMPILERFLAGS) \
> + -DLIBSUBDIR=\"$(libsubdir)\" \
> $(ALL_CPPFLAGS) $(INCLUDES) $< $(OUTPUT_OPTION)
>
> m2/stor-layout.o: $(srcdir)/stor-layout.cc $(GCC_HEADER_DEPENDENCIES_FOR_M2)
> diff --git a/gcc/m2/gm2-lang.cc b/gcc/m2/gm2-lang.cc
> index b8123273368..98707430ef5 100644
> --- a/gcc/m2/gm2-lang.cc
> +++ b/gcc/m2/gm2-lang.cc
> @@ -20,6 +20,7 @@ along with GNU Modula-2; see the file COPYING. If not,
> write to the
> Free Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA
> 02110-1301, USA. */
>
> +#define INCLUDE_VECTOR
> #include "gm2-gcc/gcc-consolidation.h"
>
> #include "langhooks-def.h" /* FIXME: for lhd_set_decl_assembler_name. */
> @@ -45,6 +46,18 @@ static void write_globals (void);
>
> static int insideCppArgs = FALSE;
>
> +/* We default to pim in the absence of fiso. */
> +static bool iso = false;
> +
> +/* The language include paths are based on the libraries in use. */
> +static bool allow_libraries = true;
> +static const char *flibs = nullptr;
> +static const char *iprefix = nullptr;
> +static const char *imultilib = nullptr;
> +static std::vectorIpaths;
> +static std::vectorisystem;
> +static std::vectoriquote;
> +
> #define EXPR_STMT_EXPR(NODE) TREE_OPERAND (EXPR_STMT_CHECK (NODE), 0)
>
> /* start of new stuff. */
> @@ -198,34 +211,41 @@ gm2_langhook_handle_option (
>return 1;
> case OPT_I:
>if (insideCppArgs)
> -{
> - const struct cl_option *option = &cl_options[scode];
> - const char *opt = (const char *)option->opt_text;
> - M2Options_CppArg (opt, arg, TRUE);
> -}
> + {
> + const struct cl_option *option = &cl_options[scode];
> + const char *opt = (const char *)option->opt_text;
> + M2Options_CppArg (opt, arg, (option->flags & CL_JOINED)
> + && !(option->flags & CL_SEPARATE));
> + }
>else
> -M2Options_SetSearchPath (arg);
> + Ipaths.push_back (arg);
>return 1;
Re: [PATCH] modula2/108144 - Fix multilib install of libgm2
On Fri, 20 Jan 2023, NightStrike wrote: > On Fri, Jan 20, 2023 at 1:40 PM Gaius Mulley via Gcc-patches > wrote: > > > > Richard Biener writes: > > > > > The following adjusts libgm2 to properly use the multilib build > > > infrastructure, thereby fixing the install with > > > --enable-version-specific-runtime-libs > > > > > > In particular config-ml.pl needs to be applied to generated Makefiles > > > as documented in the manual and we have to avoid clobbering the > > > variables via make arguments. The explicit install rules used different > > > ways to construct the multilib dir which isn't necessary and breaks > > > when MUTLIDIR is now finally set correctly. Instead use > > > $(toolexeclibdir). > > > > > > This results in some dead variables in the Makefile.am (and there were > > > some before), I refrained from doing even more changes here. > > > > > > Verified with an install with and without > > > --enable-version-specific-runtime-libs > > > and checking the result. > > > > > > OK? > > > > > > Thanks, > > > Richard. > > > > Many thanks for this fix - and the deep magic AC_FOREACH config-ml.in > > recursion rhunes. LGTM > > > > regards, > > Gaius > > AC_FOREACH is obsolete and shouldn't be used in new code. It's been > replaced with m4_foreach_w: > https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Obsolete-Macros.html I've pushed with AC_FOREACH which I cut&pasted from elsewhere. If somebody feels like replacing all AC_FOREACH in the tree then that's of course good. Richard.
Re: [PATCH] tree-optimization/108449 - keep maybe_special_function_p behavior
On Sat, 21 Jan 2023, Jan Hubicka wrote:
> > When we have a static declaration without definition we diagnose
> > that and turn it into an extern declaration. That can alter
> > the outcome of maybe_special_function_p here and there's really
> > no point in doing that, so don't.
> >
> > Bootstrapped and tested on x86_64-unknown-linux-gnu, OK?
> >
> > Thanks,
> > Richard.
> >
> > PR tree-optimization/108449
> > * cgraphunit.cc (check_global_declaration): Do not turn
> > undefined statics into externs.
> Looks OK to me. I got kind of suprrised we still have
> maybe_special_function_p and we do chane of public flag.
Yeah, well ...
> I wonder if we can run into similar problem when promoting declaration
> at LTO time?
Possibly - I guess we could amend maybe_special_function_p to check
if there's a visible definition. Or somehow get rid of this thing
and apply the special-function 'name' thing as explicit attributes
during parsing instead ...
Richard.
> Honza
> >
> > * gcc.dg/pr108449.c: New testcase.
> > ---
> > gcc/cgraphunit.cc | 2 --
> > gcc/testsuite/gcc.dg/pr108449.c | 5 +
> > 2 files changed, 5 insertions(+), 2 deletions(-)
> > create mode 100644 gcc/testsuite/gcc.dg/pr108449.c
> >
> > diff --git a/gcc/cgraphunit.cc b/gcc/cgraphunit.cc
> > index 59ce2708b7b..832818d651f 100644
> > --- a/gcc/cgraphunit.cc
> > +++ b/gcc/cgraphunit.cc
> > @@ -1087,8 +1087,6 @@ check_global_declaration (symtab_node *snode)
> >else
> > warning (OPT_Wunused_function, "%q+F declared % but never "
> >"defined", decl);
> > - /* This symbol is effectively an "extern" declaration now. */
> > - TREE_PUBLIC (decl) = 1;
> > }
> >
> >/* Warn about static fns or vars defined but not used. */
> > diff --git a/gcc/testsuite/gcc.dg/pr108449.c
> > b/gcc/testsuite/gcc.dg/pr108449.c
> > new file mode 100644
> > index 000..4a3ae5b3ed4
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.dg/pr108449.c
> > @@ -0,0 +1,5 @@
> > +/* { dg-do compile } */
> > +/* { dg-options "-O" } */
> > +
> > +static int vfork(); /* { dg-warning "used but never defined" } */
> > +void f() { vfork(); }
> > --
> > 2.35.3
>
--
Richard Biener
SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg,
Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman;
HRB 36809 (AG Nuernberg)
Re: [PATCH] Fortran: fix ICE in check_charlen_present [PR108420]
Hi Harald, This is fine for mainline and for backporting if you feel so inclined. Thanks for the patch. Paul On Mon, 16 Jan 2023 at 21:12, Harald Anlauf via Fortran wrote: > Dear all, > > it appears that the fix for pr107874 uncovered a latent bug > for the case of arrays of type character and size zero when > passed to the intrinsics MERGE and SPREAD as SOURCE. In that > case, there is no constructor from which we could obtain > another character length. A reasonable solution seems to > retain the array's character length. > > Since I could not find a simple case where this fails, I've > added an assertion that we actually have a meaningful length. > > Regtested on x86_64-pc-linux-gnu. OK for mainline? > > Thanks, > Harald > > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
