[Bug libstdc++/106676] [C++20] Automatic iterator_category detection misbehaves when `::reference` is an rvalue reference, refuses to accept a forward iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106676 Jiang An changed: What|Removed |Added CC||de34 at live dot cn --- Comment #3 from Jiang An --- This is now LWG 3798 which has been accepted. https://cplusplus.github.io/LWG/issue3798
[Bug fortran/100972] Missing error with "implicit none (external)"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100972 Bernhard Reutner-Fischer changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Known to work||12.1.0 --- Comment #4 from Bernhard Reutner-Fischer --- Fixed for 12.1.0 onwards.
Re: [PATCH 1/2]middle-end: Add new tbranch optab to add support for bit-test-and-branch operations
On Mon, Nov 14, 2022 at 4:57 PM Tamar Christina via Gcc-patches
wrote:
>
> > -Original Message-
> > From: Richard Biener
> > Sent: Saturday, November 5, 2022 2:23 PM
> > To: Aldy Hernandez
> > Cc: Tamar Christina ; Jeff Law
> > ; gcc-patches@gcc.gnu.org; nd ;
> > MacLeod, Andrew
> > Subject: Re: [PATCH 1/2]middle-end: Add new tbranch optab to add support
> > for bit-test-and-branch operations
> >
> > On Wed, 2 Nov 2022, Aldy Hernandez wrote:
> >
> > > On Wed, Nov 2, 2022 at 10:55 AM Tamar Christina
> > wrote:
> > > >
> > > > Hi Aldy,
> > > >
> > > > I'm trying to use Ranger to determine if a range of an expression is a
> > single bit.
> > > >
> > > > If possible in case of a mask then also the position of the bit that's
> > > > being
> > checked by the mask (or the mask itself).
> > >
> > > Just instantiate a ranger, and ask for the range of an SSA name (or an
> > > arbitrary tree expression) at a particular gimple statement (or an
> > > edge):
> > >
> > > gimple_ranger ranger;
> > > int_range_max r;
> > > if (ranger.range_of_expr (r, , )) {
> > > // do stuff with range "r"
> > > if (r.singleton_p ()) {
> > > wide_int num = r.lower_bound ();
> > > // Check the bits in NUM, etc...
> > > }
> > > }
> > >
> > > You can see the full ranger API in gimple-range.h.
> > >
> > > Note that instantiating a new ranger is relatively lightweight, but
> > > it's not free. So unless you're calling range_of_expr sporadically,
> > > you probably want to have one instance for your pass. You can pass
> > > around the gimple_ranger around your pass. Another way of doing this
> > > is calling enable_rager() at pass start, and then doing:
> > >
> > > get_range_query (cfun)->range_of_expr (r, , ));
> > >
> > > gimple-loop-versioning.cc has an example of using enable_ranger /
> > > disable_ranger.
> > >
> > > I am assuming you are interested in ranges for integers / pointers.
> > > Otherwise (floats, etc) you'd have to use "Value_Range" instead of
> > > int_range_max. I can give you examples on that if necessary.
> > >
> > > Let me know if that helps.
>
> It Did! I ended up going with Richi's suggestion, but the snippet was very
> helpful
> for a different range based patch I'm trying a prototype for.
>
> Many thanks for the example!
>
> >
> > I think you maybe just want get_nonzero_bits?
>
> Ah, looks like that uses range info as well. Thanks!
>
> Ok for master?
>
> Thanks,
> Tamar
>
> gcc/ChangeLog:
>
> * dojump.cc (do_jump): Pass along value.
> (do_jump_by_parts_greater_rtx): Likewise.
> (do_jump_by_parts_zero_rtx): Likewise.
> (do_jump_by_parts_equality_rtx): Likewise.
> (do_compare_rtx_and_jump): Likewise.
> (do_compare_and_jump): Likewise.
> * dojump.h (do_compare_rtx_and_jump): New.
> * optabs.cc (emit_cmp_and_jump_insn_1): Refactor to take optab to
> check.
> (validate_test_and_branch): New.
> (emit_cmp_and_jump_insns): Optiobally take a value, and when value is
> supplied then check if it's suitable for tbranch.
> * optabs.def (tbranch$a4): New.
> * doc/md.texi (tbranch@var{mode}4): Document it.
> * optabs.h (emit_cmp_and_jump_insns):
> * tree.h (tree_zero_one_valued_p): New.
>
> --- inline copy of patch ---
> diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
> index
> 34825549ed4e315b07d36dc3d63bae0cc0a3932d..342e8c4c670de251a35689d1805acceb72a8f6bf
> 100644
> --- a/gcc/doc/md.texi
> +++ b/gcc/doc/md.texi
> @@ -6958,6 +6958,13 @@ case, you can and should make operand 1's predicate
> reject some operators
> in the @samp{cstore@var{mode}4} pattern, or remove the pattern altogether
> from the machine description.
>
> +@cindex @code{tbranch@var{mode}4} instruction pattern
> +@item @samp{tbranch@var{mode}4}
> +Conditional branch instruction combined with a bit test-and-compare
> +instruction. Operand 0 is a comparison operator. Operand 1 is the
> +operand of the comparison. Operand 2 is the bit position of Operand 1 to
> test.
> +Operand 3 is the @code{code_label} to jump to.
> +
> @cindex @code{cbranch@var{mode}4} instruction pattern
> @item @samp{cbranch@var{mode}4}
> Conditional branch instruction combined with a compare instruction.
> diff --git a/gcc/dojump.h b/gcc/dojump.h
> index
> e379cceb34bb1765cb575636e4c05b61501fc2cf..d1d79c490c420a805fe48d58740a79c1f25fb839
> 100644
> --- a/gcc/dojump.h
> +++ b/gcc/dojump.h
> @@ -71,6 +71,10 @@ extern void jumpifnot (tree exp, rtx_code_label *label,
> extern void jumpifnot_1 (enum tree_code, tree, tree, rtx_code_label *,
> profile_probability);
>
> +extern void do_compare_rtx_and_jump (rtx, rtx, enum rtx_code, int, tree,
> +machine_mode, rtx, rtx_code_label *,
> +rtx_code_label *, profile_probability);
> +
> extern void do_compare_rtx_and_jump (rtx, rtx, enum rtx_code, int,
>
[committed] c++: Fix a typo in function name
Hi!
I've noticed I've made a typo in the name of the function.
Fixed thusly.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed
as obvious to trunk.
2022-11-15 Jakub Jelinek
* cp-tree.h (next_common_initial_seqence): Rename to ...
(next_common_initial_sequence): ... this.
* typeck.cc (next_common_initial_seqence): Rename to ...
(next_common_initial_sequence): ... this.
(layout_compatible_type_p): Call next_common_initial_sequence
rather than next_common_initial_seqence.
* semantics.cc (is_corresponding_member_aggr): Likewise.
--- gcc/cp/cp-tree.h.jj 2022-11-14 13:35:34.311158621 +0100
+++ gcc/cp/cp-tree.h2022-11-14 13:41:29.817322405 +0100
@@ -7982,7 +7982,7 @@ extern bool comp_except_specs (const_t
extern bool comptypes (tree, tree, int);
extern bool same_type_ignoring_top_level_qualifiers_p (tree, tree);
extern bool similar_type_p (tree, tree);
-extern bool next_common_initial_seqence(tree &, tree &);
+extern bool next_common_initial_sequence (tree &, tree &);
extern bool layout_compatible_type_p (tree, tree);
extern bool compparms (const_tree, const_tree);
extern int comp_cv_qualification (const_tree, const_tree);
--- gcc/cp/typeck.cc.jj 2022-11-14 13:35:34.474156404 +0100
+++ gcc/cp/typeck.cc2022-11-14 13:42:07.328812124 +0100
@@ -1779,7 +1779,7 @@ similar_type_p (tree type1, tree type2)
the common initial sequence. */
bool
-next_common_initial_seqence (tree , tree )
+next_common_initial_sequence (tree , tree )
{
while (memb1)
{
@@ -1871,7 +1871,7 @@ layout_compatible_type_p (tree type1, tr
{
while (1)
{
- if (!next_common_initial_seqence (field1, field2))
+ if (!next_common_initial_sequence (field1, field2))
return false;
if (field1 == NULL_TREE)
return true;
--- gcc/cp/semantics.cc.jj 2022-11-14 13:35:34.429157016 +0100
+++ gcc/cp/semantics.cc 2022-11-14 13:41:47.930076022 +0100
@@ -11665,7 +11665,7 @@ is_corresponding_member_aggr (location_t
tree ret = boolean_false_node;
while (1)
{
- bool r = next_common_initial_seqence (field1, field2);
+ bool r = next_common_initial_sequence (field1, field2);
if (field1 == NULL_TREE || field2 == NULL_TREE)
break;
if (r
Jakub
Re: [PATCH v2 0/2] Basic support for the Ventana VT1 w/ instruction fusion
On Tue, Nov 15, 2022 at 12:01 AM Philipp Tomsich wrote: > > On Mon, 14 Nov 2022 at 23:47, Palmer Dabbelt wrote: > > > > [Trying to join the threads here.] > > > > On Mon, 14 Nov 2022 13:28:23 PST (-0800), philipp.toms...@vrull.eu wrote: > > > Jeff, > > > > > > On Mon, 14 Nov 2022 at 22:23, Jeff Law wrote: > > >> > > >> > > >> On 11/14/22 13:00, Palmer Dabbelt wrote: > > >> > On Sun, 13 Nov 2022 12:48:22 PST (-0800), philipp.toms...@vrull.eu > > >> > wrote: > > >> >> > > >> >> This series provides support for the Ventana VT1 (a 4-way superscalar > > >> >> rv64gc_zba_zbb_zbc_zbs_zifenci_xventanacondops core) including support > > >> >> for the supported instruction fusion patterns. > > >> >> > > >> >> This includes the addition of the fusion-aware scheduling > > >> >> infrastructure for RISC-V and implements idiom recognition for the > > >> >> fusion patterns supported by VT1. > > >> >> > > >> >> Note that we don't signal support for XVentanaCondOps at this point, > > >> >> as the XVentanaCondOps support is in-flight separately. Changing the > > >> >> defaults for VT1 can happen late in the cycle, so no need to link the > > >> >> two different changesets. > > >> >> > > >> >> Changes in v2: > > >> >> - Rebased and changed over to .rst-based documentation > > >> >> - Updated to catch more fusion cases > > >> >> - Signals support for Zifencei > > >> >> > > >> >> Philipp Tomsich (2): > > >> >> RISC-V: Add basic support for the Ventana-VT1 core > > >> >> RISC-V: Add instruction fusion (for ventana-vt1) > > >> >> > > >> >> gcc/config/riscv/riscv-cores.def | 3 + > > >> >> gcc/config/riscv/riscv-opts.h | 2 +- > > >> >> gcc/config/riscv/riscv.cc | 233 > > >> >> ++ > > >> >> .../risc-v-options.rst| 5 +- > > >> >> 4 files changed, 240 insertions(+), 3 deletions(-) > > >> > > > >> > I guess we never really properly talked about this on the GCC mailing > > >> > lists, but IMO it's fine to start taking code for designs that have > > >> > been announced under the assumption that if the hardware doesn't > > >> > actually show up according to those timelines that it will be assumed > > >> > to have never existed and thus be removed more quickly than usual. > > >> Absolutely. I have zero interest in carrying around code for > > >> nonexistent or dead variants. > > >> > > > >> > That said, I can't find anything describing that the VT-1 exists aside > > >> > from these patches. Is there anything that describes this design and > > >> > when it's expected to be available? > > >> > > >> What do you need? I can give some broad overview information on the > > >> design, but it would likely just mirror what's already been mentioned in > > >> these patches. > > >> > > >> > > >> As far as schedules. I'm not sure what I can say. I'll check on that. > > > > I'm less worried about the "does this pipeline model match the HW" bits, > > at least until the HW is publicly available then all we can do is rely > > on the vendor (and even after the HW is public the vendor might be the > > only one who cares enough to figure things out, nothing we can really do > > upstream there). We've had some issues with nobody caring enough about > > the C906 pipeline model to sort out whether some patches are a net win, > > but if nobody (including the vendor) cares about the HW enough to > > benchmark things then there's not much we can do. > > > > My bigger worry is getting roped in to supporting a bunch of hardware > > that doesn't actually exist yet and may never make it outside some > > vendor's lab. That can generally be a ton of work and filters > > throughout GCC, even outside of the RISC-V backend. We've already got > > enough chaos just trying to follow the ISA, chasing down issues related > > to hardware that may not ever manifest is just going to lead to > > craziness. > > > > So on my end the point of the schedule is to have something we can look > > at and determine that the hardware is somehow defunct. The fairest way > > we could come up with was to tie it to some sort of company announcement > > of the hardware: obviously everyone knows their internal timelines, but > > that's not fair to companies that don't employ someone with commit > > access. Requirement some sort of public announcement means everyone has > > the same rules to play by, IMO that's really important in RISC-V land as > > there's so many vendors. > > > > >> It was never my intention to bypass any process/procedures here. So if I > > >> did, my apologies. > > > > > > The controversial part is XVentanaCondOps (as it is a vendor-defined > > > extension), so I'll certainly hold off on that until both you and > > > Palmer are in agreement on how to proceed there. > > > > The pipeline models are essentially in the same spot. We've got a bit > > of a precedent there for taking them just based on an announcement, but > > there isn't one here. > > > > [and the
[Bug target/104688] gcc and libatomic can use SSE for 128-bit atomic loads on Intel and AMD CPUs with AVX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688 --- Comment #17 from Jakub Jelinek --- Fixed for AMD on the library side too. We need a statement from Zhaoxin and VIA for their CPUs.
[Bug target/104688] gcc and libatomic can use SSE for 128-bit atomic loads on Intel and AMD CPUs with AVX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688 --- Comment #16 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:4a7a846687e076eae58ad3ea959245b2bf7fdc07 commit r13-4048-g4a7a846687e076eae58ad3ea959245b2bf7fdc07 Author: Jakub Jelinek Date: Tue Nov 15 08:14:45 2022 +0100 libatomic: Handle AVX+CX16 AMD like Intel for 16b atomics [PR104688] We got a response from AMD in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688#c10 so the following patch starts treating AMD with AVX and CMPXCHG16B ISAs like Intel by using vmovdqa for atomic load/store in libatomic. We still don't have confirmation from Zhaoxin and VIA (anything else with CPUs featuring AVX and CX16?). 2022-11-15 Jakub Jelinek PR target/104688 * config/x86/init.c (__libat_feat1_init): Don't clear bit_AVX on AMD CPUs.
Re: [PATCH] [PR68097] Try to avoid recursing for floats in tree_*_nonnegative_warnv_p.
On Mon, Nov 14, 2022 at 8:05 PM Aldy Hernandez wrote:
>
>
>
> On 11/14/22 10:12, Richard Biener wrote:
> > On Sat, Nov 12, 2022 at 7:30 PM Aldy Hernandez wrote:
> >>
> >> It irks me that a PR named "we should track ranges for floating-point
> >> hasn't been closed in this release. This is an attempt to do just
> >> that.
> >>
> >> As mentioned in the PR, even though we track ranges for floats, it has
> >> been suggested that avoiding recursing through SSA defs in
> >> gimple_assign_nonnegative_warnv_p is also a goal. We can do this with
> >> various ranger components without the need for a heavy handed approach
> >> (i.e. a full ranger).
> >>
> >> I have implemented two versions of known_float_sign_p() that answer
> >> the question whether we definitely know the sign for an operation or a
> >> tree expression.
> >>
> >> Both versions use get_global_range_query, which is a wrapper to query
> >> global ranges. This means, that no caching or propagation is done.
> >> In the case of an SSA, we just return the global range for it (think
> >> SSA_NAME_RANGE_INFO). In the case of a tree code with operands, we
> >> also use get_global_range_query to resolve the operands, and then call
> >> into range-ops, which is our lowest level component. There is no
> >> ranger or gori involved. All we're doing is resolving the operation
> >> with the ranges passed.
> >>
> >> This is enough to avoid recursing in the case where we definitely know
> >> the sign of a range. Otherwise, we still recurse.
> >>
> >> Note that instead of get_global_range_query(), we could use
> >> get_range_query() which uses a ranger (if active in a pass), or
> >> get_global_range_query if not. This would allow passes that have an
> >> active ranger (with enable_ranger) to use a full ranger. These passes
> >> are currently, VRP, loop unswitching, DOM, loop versioning, etc. If
> >> no ranger is active, get_range_query defaults to global ranges, so
> >> there's no additional penalty.
> >>
> >> Would this be acceptable, at least enough to close (or rename the PR ;-))?
> >
> > I think the checks would belong to the gimple_stmt_nonnegative_warnv_p
> > function
> > only (that's the SSA name entry from the fold-const.cc ones)?
>
> That was my first approach, but I thought I'd cover the unary and binary
> operators as well, since they had other callers. But I'm happy with
> just the top-level tweak. It's a lot less code :).
@@ -9234,6 +9235,15 @@ bool
gimple_stmt_nonnegative_warnv_p (gimple *stmt, bool *strict_overflow_p,
int depth)
{
+ tree type = gimple_range_type (stmt);
+ if (type && frange::supports_p (type))
+{
+ frange r;
+ bool sign;
+ return (get_global_range_query ()->range_of_stmt (r, stmt)
+ && r.signbit_p (sign)
+ && sign == false);
+}
the above means we never fall through to the switch below if
frange::supports_p (type) - that's eventually good enough, I
don't think we ever call this very function directly but it gets
invoked via recursion through operands only. But of course
I wonder what types are not supported by frange and whether
the manual processing we fall through to does anything meaningful
for those?
I won't ask you to thoroughly answer this now but please put in
a comment reflecting the above before the switch stmt.
switch (gimple_code (stmt))
Otherwise OK, in case you tree gets back to bootstrapping ;)
> >
> > I also notice the use of 'bool' for the "sign". That's not really
> > descriptive. We
> > have SIGNED and UNSIGNED (aka enum signop), not sure if that's the
> > perfect match vs. NEGATIVE and NONNEGATIVE. Maybe the functions
> > name is just bad and they should be known_float_negative_p?
>
> The bool sign is to keep in line with real.*, and was suggested by Jeff
> (in real.* not here). I'm happy to change the entire frange API to use
> sgnop. It is cleaner. If that's acceptable, I could do that as a
> follow-up.
>
> How's this, pending tests once I figure out why my trees have been
> broken all day :-/.
>
> Aldy
>
> p.s. First it was sphinx failure, now I'm seeing this:
> /home/aldyh/src/clean/gcc/match.pd:7935:8 error: return statement not
> allowed in C expression
> return NULL_TREE;
> ^
Supposedly somebody pushed and reverted this transient error? Yep,
Tamar did.
Richard.
[Bug target/107692] [13 regression] r13-3950-g071e428c24ee8c breaks many test cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107692 --- Comment #2 from Hongyu Wang --- Created attachment 53897 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53897=edit A patch Sorry for introducing these fails. Here is the patch. I've tested the patch with cross-compler and all the fails disappeared, but I don't have a powerpc to do full bootstrap & regtest (I'm still applying for gcc farm account). I'll send out the patch after I can access gcc farm for a power machine, or hopefully someone can help testing the patch. I suppose s390 has similar issue and I will update that accordingly.
[Bug c/105180] [10/11/12/13 Regression] K style definition does not evaluate array size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105180
--- Comment #6 from Andrew Pinski ---
Here is a self contained tester:
int global = 0;
int func(void)
{
global++;
return global;
}
void crime(s, c)
char *s;
char c[static func()];
{
}
int main(void)
{
crime("1", "1");
if (global != 1)
__builtin_abort();
return 0;
}
[PATCH, V1 1/1] RISC-V: Make R_RISCV_SUB6 conforms to riscv abi standard
From: zengxiao
This patch makes R_RISCV_SUB6 conforms to riscv abi standard.
R_RISCV_SUB6 only the lower 6 bits of the code are valid.
The proposed specification which can be found in 8.5. Relocations of,
https://github.com/riscv-non-isa/riscv-elf-psabi-doc/releases/download/v1.0-rc4/riscv-abi.pdf
bfd/ChangeLog:
* elfxx-riscv.c (riscv_elf_add_sub_reloc):
binutils/ChangeLog:
* testsuite/binutils-all/riscv/dwarf-SUB6.d: New test.
* testsuite/binutils-all/riscv/dwarf-SUB6.s: New test.
reviewed-by: gao...@eswincomputing.com
jinyanji...@eswincomputing.com
Signed-off-by: zengxiao
---
bfd/elfxx-riscv.c | 7 +
.../testsuite/binutils-all/riscv/dwarf-SUB6.d | 31 +++
.../testsuite/binutils-all/riscv/dwarf-SUB6.s | 12 +++
3 files changed, 50 insertions(+)
create mode 100644 binutils/testsuite/binutils-all/riscv/dwarf-SUB6.d
create mode 100644 binutils/testsuite/binutils-all/riscv/dwarf-SUB6.s
diff --git a/bfd/elfxx-riscv.c b/bfd/elfxx-riscv.c
index 300ccf49534..e71d4a456f2 100644
--- a/bfd/elfxx-riscv.c
+++ b/bfd/elfxx-riscv.c
@@ -994,6 +994,13 @@ riscv_elf_add_sub_reloc (bfd *abfd,
relocation = old_value + relocation;
break;
case R_RISCV_SUB6:
+ {
+bfd_vma six_bit_valid_value = old_value & howto->dst_mask;
+six_bit_valid_value -= relocation;
+relocation = (six_bit_valid_value & howto->dst_mask) |
+ (old_value & ~howto->dst_mask);
+ }
+ break;
case R_RISCV_SUB8:
case R_RISCV_SUB16:
case R_RISCV_SUB32:
diff --git a/binutils/testsuite/binutils-all/riscv/dwarf-SUB6.d
b/binutils/testsuite/binutils-all/riscv/dwarf-SUB6.d
new file mode 100644
index 000..47d5ae570d7
--- /dev/null
+++ b/binutils/testsuite/binutils-all/riscv/dwarf-SUB6.d
@@ -0,0 +1,31 @@
+#PROG: objcopy
+#objdump: --dwarf=frames
+
+tmpdir/riscvcopy.o: file format elf32-littleriscv
+
+Contents of the .eh_frame section:
+
+
+ 0020 CIE
+ Version: 3
+ Augmentation: "zR"
+ Code alignment factor: 1
+ Data alignment factor: -4
+ Return address column: 1
+ Augmentation data: 1b
+ DW_CFA_def_cfa_register: r2 \(sp\)
+ DW_CFA_def_cfa_offset: 48
+ DW_CFA_offset: r1 \(ra\) at cfa-4
+ DW_CFA_offset: r8 \(s0\) at cfa-8
+ DW_CFA_def_cfa: r8 \(s0\) ofs 0
+ DW_CFA_restore: r1 \(ra\)
+ DW_CFA_restore: r8 \(s0\)
+ DW_CFA_def_cfa: r2 \(sp\) ofs 48
+ DW_CFA_def_cfa_offset: 0
+ DW_CFA_nop
+
+0024 0010 0028 FDE cie= pc=002c..002c
+ DW_CFA_nop
+ DW_CFA_nop
+ DW_CFA_nop
+
diff --git a/binutils/testsuite/binutils-all/riscv/dwarf-SUB6.s
b/binutils/testsuite/binutils-all/riscv/dwarf-SUB6.s
new file mode 100644
index 000..fe959f59d9b
--- /dev/null
+++ b/binutils/testsuite/binutils-all/riscv/dwarf-SUB6.s
@@ -0,0 +1,12 @@
+.attribute arch, "rv32i2p0_m2p0_a2p0_f2p0_c2p0"
+.cfi_startproc
+.cfi_def_cfa_offset 48
+.cfi_offset 1, -4
+.cfi_offset 8, -8
+.cfi_def_cfa 8, 0
+.cfi_restore 1
+.cfi_restore 8
+.cfi_def_cfa 2, 48
+.cfi_def_cfa_offset 0
+.cfi_endproc
+
\ No newline at end of file
--
2.34.1
[PATCH, V1 0/1] RISC-V: Make R_RISCV_SUB6 conforms to riscv abi standard
From: zengxiao Hi all RISC-V folks: When riscv-objdump is used to generate dwarf information, problems are found, like: DW_CFA_??? (User defined call frame op: 0x3c) This error is related to that riscv-objdump does not follow the riscv R_RISCV_SUB6 standard. Riscv-readelf is correct because it follows the R_RISCV_SUB6 standard. There are test cases in https://github.com/zeng-xiao/gnu-bug-fix/tree/main/EG-769 that describe the error in detail. zengxiao (1): RISC-V: Make R_RISCV_SUB6 conforms to riscv abi standard bfd/elfxx-riscv.c | 7 + .../testsuite/binutils-all/riscv/dwarf-SUB6.d | 31 +++ .../testsuite/binutils-all/riscv/dwarf-SUB6.s | 12 +++ 3 files changed, 50 insertions(+) create mode 100644 binutils/testsuite/binutils-all/riscv/dwarf-SUB6.d create mode 100644 binutils/testsuite/binutils-all/riscv/dwarf-SUB6.s -- 2.34.1
[Bug c/105180] [10/11/12/13 Regression] K style definition does not evaluate array size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105180 --- Comment #5 from Andrew Pinski --- (In reply to Andrew Pinski from comment #4) > I am suspecting r0-108564-ga04a722b88baf5 . That is https://gcc.gnu.org/legacy-ml/gcc-patches/2011-05/msg00319.html . I suspect there was a missing old style part to the parser but I am not 100% sure.
[PATCH, V1 1/1] RISC-V: Make R_RISCV_SUB6 conforms to riscv abi standard
From: zengxiao
This patch makes R_RISCV_SUB6 conforms to riscv abi standard.
R_RISCV_SUB6 only the lower 6 bits of the code are valid.
The proposed specification which can be found in 8.5. Relocations of,
https://github.com/riscv-non-isa/riscv-elf-psabi-doc/releases/download/v1.0-rc4/riscv-abi.pdf
bfd/ChangeLog:
* elfxx-riscv.c (riscv_elf_add_sub_reloc): Take the lower
6 bits as the significant bit
---
bfd/elfxx-riscv.c | 7 +
.../testsuite/binutils-all/riscv/dwarf-SUB6.d | 31 +++
.../testsuite/binutils-all/riscv/dwarf-SUB6.s | 12 +++
3 files changed, 50 insertions(+)
create mode 100644 binutils/testsuite/binutils-all/riscv/dwarf-SUB6.d
create mode 100644 binutils/testsuite/binutils-all/riscv/dwarf-SUB6.s
diff --git a/bfd/elfxx-riscv.c b/bfd/elfxx-riscv.c
index 300ccf49534..e71d4a456f2 100644
--- a/bfd/elfxx-riscv.c
+++ b/bfd/elfxx-riscv.c
@@ -994,6 +994,13 @@ riscv_elf_add_sub_reloc (bfd *abfd,
relocation = old_value + relocation;
break;
case R_RISCV_SUB6:
+ {
+bfd_vma six_bit_valid_value = old_value & howto->dst_mask;
+six_bit_valid_value -= relocation;
+relocation = (six_bit_valid_value & howto->dst_mask) |
+ (old_value & ~howto->dst_mask);
+ }
+ break;
case R_RISCV_SUB8:
case R_RISCV_SUB16:
case R_RISCV_SUB32:
diff --git a/binutils/testsuite/binutils-all/riscv/dwarf-SUB6.d
b/binutils/testsuite/binutils-all/riscv/dwarf-SUB6.d
new file mode 100644
index 000..47d5ae570d7
--- /dev/null
+++ b/binutils/testsuite/binutils-all/riscv/dwarf-SUB6.d
@@ -0,0 +1,31 @@
+#PROG: objcopy
+#objdump: --dwarf=frames
+
+tmpdir/riscvcopy.o: file format elf32-littleriscv
+
+Contents of the .eh_frame section:
+
+
+ 0020 CIE
+ Version: 3
+ Augmentation: "zR"
+ Code alignment factor: 1
+ Data alignment factor: -4
+ Return address column: 1
+ Augmentation data: 1b
+ DW_CFA_def_cfa_register: r2 \(sp\)
+ DW_CFA_def_cfa_offset: 48
+ DW_CFA_offset: r1 \(ra\) at cfa-4
+ DW_CFA_offset: r8 \(s0\) at cfa-8
+ DW_CFA_def_cfa: r8 \(s0\) ofs 0
+ DW_CFA_restore: r1 \(ra\)
+ DW_CFA_restore: r8 \(s0\)
+ DW_CFA_def_cfa: r2 \(sp\) ofs 48
+ DW_CFA_def_cfa_offset: 0
+ DW_CFA_nop
+
+0024 0010 0028 FDE cie= pc=002c..002c
+ DW_CFA_nop
+ DW_CFA_nop
+ DW_CFA_nop
+
diff --git a/binutils/testsuite/binutils-all/riscv/dwarf-SUB6.s
b/binutils/testsuite/binutils-all/riscv/dwarf-SUB6.s
new file mode 100644
index 000..fe959f59d9b
--- /dev/null
+++ b/binutils/testsuite/binutils-all/riscv/dwarf-SUB6.s
@@ -0,0 +1,12 @@
+.attribute arch, "rv32i2p0_m2p0_a2p0_f2p0_c2p0"
+.cfi_startproc
+.cfi_def_cfa_offset 48
+.cfi_offset 1, -4
+.cfi_offset 8, -8
+.cfi_def_cfa 8, 0
+.cfi_restore 1
+.cfi_restore 8
+.cfi_def_cfa 2, 48
+.cfi_def_cfa_offset 0
+.cfi_endproc
+
\ No newline at end of file
--
2.34.1
[PATCH, V1 0/1] RISC-V: Make R_RISCV_SUB6 conforms to riscv abi standard
From: zengxiao Hi all RISC-V folks: When riscv-objdump is used to generate dwarf information, problems are found, like: DW_CFA_??? (User defined call frame op: 0x3c) This error is related to that riscv-objdump does not follow the riscv R_RISCV_SUB6 standard. Riscv-readelf is correct because it follows the R_RISCV_SUB6 standard. There are test cases in https://github.com/zeng-xiao/gnu-bug-fix/tree/main/EG-769 that describe the error in detail. zengxiao (1): RISC-V: Make R_RISCV_SUB6 conforms to riscv abi standard bfd/elfxx-riscv.c | 7 + .../testsuite/binutils-all/riscv/dwarf-SUB6.d | 31 +++ .../testsuite/binutils-all/riscv/dwarf-SUB6.s | 12 +++ 3 files changed, 50 insertions(+) create mode 100644 binutils/testsuite/binutils-all/riscv/dwarf-SUB6.d create mode 100644 binutils/testsuite/binutils-all/riscv/dwarf-SUB6.s -- 2.34.1
[Bug c/105180] [10/11/12/13 Regression] K style definition does not evaluate array size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105180 --- Comment #4 from Andrew Pinski --- I am suspecting r0-108564-ga04a722b88baf5 .
[Bug debug/105158] ftree-ccp (CFG cleanup) drops DWARF const value attribute at -Og/-O1/-O2/-O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105158 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |13.0
[Bug web/65699] online docs lacks version that it documents
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65699 Andrew Pinski changed: What|Removed |Added Target Milestone|13.0|---
[Bug web/63873] target links in Concepts Index in gccint do not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63873 --- Comment #5 from Andrew Pinski --- >Can we move into the 21st century already? We tried this year but sphinx needs to improved to cover the same feature set as texinfo too.
[Bug web/65699] online docs lacks version that it documents
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65699 Andrew Pinski changed: What|Removed |Added Status|RESOLVED|NEW Last reconfirmed||2022-11-15 Resolution|FIXED |--- Ever confirmed|0 |1 --- Comment #6 from Andrew Pinski --- Sphinx generated manual was reverted for now so reopen this.
[Bug other/88472] attribute documentation poorly structured, lots of duplication
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88472 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=88860 Ever confirmed|0 |1 Last reconfirmed||2022-11-15 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug target/98167] [x86] Failure to optimize operation on indentically shuffled operands into a shuffle of the result of the operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98167 --- Comment #21 from CVS Commits --- The master branch has been updated by Hongyu Wang : https://gcc.gnu.org/g:dc95e1e9702f2f6367bbc108c8d01169be1b66d2 commit r13-4044-gdc95e1e9702f2f6367bbc108c8d01169be1b66d2 Author: Hongyu Wang Date: Mon Jan 17 13:01:51 2022 +0800 Optimize VEC_PERM_EXPR with same permutation index and operation The sequence c1 = VEC_PERM_EXPR (a, a, mask) c2 = VEC_PERM_EXPR (b, b, mask) c3 = c1 op c2 can be optimized to c = a op b c3 = VEC_PERM_EXPR (c, c, mask) for all integer vector operation, and float operation with full permutation. gcc/ChangeLog: PR target/98167 * match.pd: New perm + vector op patterns for int and fp vector. gcc/testsuite/ChangeLog: PR target/98167 * gcc.target/i386/pr98167.c: New test.
[Bug target/107692] [13 regression] r13-3950-g071e428c24ee8c breaks many test cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107692 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |13.0
[Bug libstdc++/107693] New: undefined reference to `_ZSt8to_charsPcS_DF128_St12chars_formati' std::format does not work on x86_64-w64-mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107693 Bug ID: 107693 Summary: undefined reference to `_ZSt8to_charsPcS_DF128_St12chars_formati' std::format does not work on x86_64-w64-mingw32 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: unlvsur at live dot com Target Milestone: --- g++ -o fstream_std_format fstream_std_format.cc -Ofast -std=c++23 -s -flto -march=native -I../../../include -static-libstdc++ lto-wrapper.exe: warning: using serial compilation of 2 LTRANS jobs lto-wrapper.exe: note: see the '-flto' option documentation for more information d:/x86_64-windows-gnu/x86_64-w64-mingw32/bin/../lib/gcc/x86_64-w64-mingw32/13.0.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\Users\unlvs\AppData\Local\Temp\ccc9ergr.ltrans0.ltrans.o::(.text+0x7243): undefined reference to `_ZSt8to_charsPcS_DF128_' d:/x86_64-windows-gnu/x86_64-w64-mingw32/bin/../lib/gcc/x86_64-w64-mingw32/13.0.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\Users\unlvs\AppData\Local\Temp\ccc9ergr.ltrans0.ltrans.o::(.text+0x7906): undefined reference to `_ZSt8to_charsPcS_DF128_St12chars_formati'
Re: C89isms in the test suite
> On 14 Nov 2022, at 08:19, Florian Weimer wrote: > > * Sam James: > >> Would you be able to backport 6be2672e4ee41c566a9e072088a263bab5f7 >> and 885b6660c17fb91980b5682514ef54668e544b02 to the active <13 >> branches? > > Jakub, okay to backport these two (to 12, 11, 10 I presume)? (Yes please. It's also given me something to poke at as I didn't log the failure and only noticed when libasan wasn't installed...) Thanks. signature.asc Description: Message signed with OpenPGP
[PATCH] Remove Score documentation
From: Andrew Pinski
Score target support was removed in r5-3909-g3daa7bbf791203
but it looks like some of the documentation was missed.
This removes it.
Committed as obvious after a "make html".
Thanks,
Andrew
gcc/ChangeLog:
* doc/invoke.texi: Remove Score option section.
---
gcc/doc/invoke.texi | 52
1 file changed, 52 deletions(-)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index ef88f2a..55e8a14 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -1316,13 +1316,6 @@ See RS/6000 and PowerPC Options.
-mwarn-framesize -mwarn-dynamicstack -mstack-size -mstack-guard @gol
-mhotpatch=@var{halfwords},@var{halfwords}}
-@emph{Score Options}
-@gccoptlist{-meb -mel @gol
--mnhwloop @gol
--muls @gol
--mmac @gol
--mscore5 -mscore5u -mscore7 -mscore7d}
-
@emph{SH Options}
@gccoptlist{-m1 -m2 -m2e @gol
-m2a-nofpu -m2a-single-only -m2a-single -m2a @gol
@@ -19726,7 +19719,6 @@ platform.
* RS/6000 and PowerPC Options::
* RX Options::
* S/390 and zSeries Options::
-* Score Options::
* SH Options::
* Solaris 2 Options::
* SPARC Options::
@@ -30424,50 +30416,6 @@ This option can be overridden for individual functions
with the
@code{hotpatch} attribute.
@end table
-@node Score Options
-@subsection Score Options
-@cindex Score Options
-
-These options are defined for Score implementations:
-
-@table @gcctabopt
-@item -meb
-@opindex meb
-Compile code for big-endian mode. This is the default.
-
-@item -mel
-@opindex mel
-Compile code for little-endian mode.
-
-@item -mnhwloop
-@opindex mnhwloop
-Disable generation of @code{bcnz} instructions.
-
-@item -muls
-@opindex muls
-Enable generation of unaligned load and store instructions.
-
-@item -mmac
-@opindex mmac
-Enable the use of multiply-accumulate instructions. Disabled by default.
-
-@item -mscore5
-@opindex mscore5
-Specify the SCORE5 as the target architecture.
-
-@item -mscore5u
-@opindex mscore5u
-Specify the SCORE5U of the target architecture.
-
-@item -mscore7
-@opindex mscore7
-Specify the SCORE7 as the target architecture. This is the default.
-
-@item -mscore7d
-@opindex mscore7d
-Specify the SCORE7D as the target architecture.
-@end table
-
@node SH Options
@subsection SH Options
--
1.8.3.1
Re: How can Autoconf help with the transition to stricter compilation defaults?
> On 13 Nov 2022, at 00:43, Paul Eggert wrote: > > On 2022-11-11 07:11, Aaron Ballman wrote: >> We believe the runtime behavior is sufficiently dangerous to >> warrant a conservative view that any call to a function will be a call >> that gets executed at runtime, hence a definitive signature mismatch >> is something we feel comfortable diagnosing (in some form) by default. > > As long as these diagnostics by default do not cause the compiler to exit > with nonzero status, we should be OK with Autoconf-generated 'configure' > scripts. Although there will be problems with people who run "./configure > CFLAGS='-Werror'", that sort of usage has always been problematic and > unsupported by Autoconf, so we can simply continue to tell people "don't do > that". > Is there somewhere in the autoconf docs we actually say this? I've seen a few instances of folks adding it themselves very early in their configure scripts (which is a pain for distros anyway) which then ends up affecting the rest. signature.asc Description: Message signed with OpenPGP
[PATCH v4] OpenMP: Generate SIMD clones for functions with "declare target"
Here is yet another attempt at a patch to auto-generate SIMD clones for functions that already have the "declare target" attribute. This version v4 is derived from the previous v2 version, since v3 seemed to be a dead end. I have added conditionals to restrict the auto-generation at -O2 to the offload compiler, and extended the syntax of the -fopenmp-target-simd-clone to allow explicit control over whether it applies to host, target, or both -- this primarily to allow better test coverage. I've added infrastructure to support testing on the offload compiler, added new test cases, and reworked the existing test cases to scan for interesting things written to the dump file instead of examining the .s output. I hope it is not too late to consider this patch given that I've been trying to get this feature in for months already. Also, I kind of got caught in the Sphinx churn last week, relating to the documentation parts of this patch. :-( I understand that if this patch is accepted I am also on the hook to come up with a further patch to try to GC unused clones after vectorization; I haven't started on that piece yet. -SandraFrom 771be96d2dc7b8868ba06cf8ec6afe7a3337ac89 Mon Sep 17 00:00:00 2001 From: Sandra Loosemore Date: Tue, 15 Nov 2022 03:40:12 + Subject: [PATCH] OpenMP: Generate SIMD clones for functions with "declare target" This patch causes the IPA simdclone pass to generate clones for functions with the "omp declare target" attribute as if they had "omp declare simd", provided the function appears to be suitable for SIMD execution. The filter is conservative, rejecting functions that write memory or that call other functions not known to be safe. A new option -fopenmp-target-simd-clone is added to control this transformation; it's enabled for offload processing at -O2 and higher. gcc/ChangeLog: * common.opt (fopenmp-target-simd-clone): New option. (target_simd_clone_device): New enum to go with it. * doc/invoke.texi (-fopenmp-target-simd-clone): Document. * flag-types.h (enum omp_target_simd_clone_device_kind): New. * omp-simd-clone.cc (auto_simd_fail): New function. (auto_simd_check_stmt): New function. (plausible_type_for_simd_clone): New function. (ok_for_auto_simd_clone): New function. (simd_clone_create): Add force_local argument, make the symbol have internal linkage if it is true. (expand_simd_clones): Also check for cloneable functions with "omp declare target". Pass explicit_p argument to simd_clone.compute_vecsize_and_simdlen target hook. * opts.cc (default_options_table): Add -fopenmp-target-simd-clone. * target.def (TARGET_SIMD_CLONE_COMPUTE_VECSIZE_AND_SIMDLEN): Add bool explicit_p argument. * doc/tm.texi: Regenerated. * config/aarch64/aarch64.cc (aarch64_simd_clone_compute_vecsize_and_simdlen): Update. * config/gcn/gcn.cc (gcn_simd_clone_compute_vecsize_and_simdlen): Update. * config/i386/i386.cc (ix86_simd_clone_compute_vecsize_and_simdlen): Update. gcc/testsuite/ChangeLog: * g++.dg/gomp/target-simd-clone-1.C: New. * g++.dg/gomp/target-simd-clone-2.C: New. * gcc.dg/gomp/target-simd-clone-1.c: New. * gcc.dg/gomp/target-simd-clone-2.c: New. * gcc.dg/gomp/target-simd-clone-3.c: New. * gcc.dg/gomp/target-simd-clone-4.c: New. * gcc.dg/gomp/target-simd-clone-5.c: New. * gcc.dg/gomp/target-simd-clone-6.c: New. * gcc.dg/gomp/target-simd-clone-7.c: New. * gcc.dg/gomp/target-simd-clone-8.c: New. * lib/scanoffloadipa.exp: New. libgomp/ChangeLog: * testsuite/lib/libgomp.exp: Load scanoffloadipa.exp library. * testsuite/libgomp.c/target-simd-clone-1.c: New. * testsuite/libgomp.c/target-simd-clone-2.c: New. * testsuite/libgomp.c/target-simd-clone-3.c: New. --- gcc/common.opt| 22 ++ gcc/config/aarch64/aarch64.cc | 24 +- gcc/config/gcn/gcn.cc | 10 +- gcc/config/i386/i386.cc | 27 +- gcc/doc/invoke.texi | 23 +- gcc/doc/tm.texi | 2 +- gcc/flag-types.h | 9 + gcc/omp-simd-clone.cc | 309 -- gcc/opts.cc | 2 + gcc/target.def| 2 +- .../g++.dg/gomp/target-simd-clone-1.C | 25 ++ .../g++.dg/gomp/target-simd-clone-2.C | 23 ++ .../gcc.dg/gomp/target-simd-clone-1.c | 25 ++ .../gcc.dg/gomp/target-simd-clone-2.c | 22 ++ .../gcc.dg/gomp/target-simd-clone-3.c | 22 ++ .../gcc.dg/gomp/target-simd-clone-4.c | 26 ++ .../gcc.dg/gomp/target-simd-clone-5.c | 28 ++ .../gcc.dg/gomp/target-simd-clone-6.c | 27 ++ .../gcc.dg/gomp/target-simd-clone-7.c | 15 + .../gcc.dg/gomp/target-simd-clone-8.c | 25 ++ gcc/testsuite/lib/scanoffloadipa.exp | 148 + libgomp/testsuite/lib/libgomp.exp | 1 +
[PATCH] Remove the picoChip documentation
From: Andrew Pinski
PicoChip support was removed in r5-3431-g157e859ffe3b5d but the
documentation was missed it seems.
Committed as obvious after running "make html" to make sure the
building of the documentation still works.
Thanks,
Andrew Pinski
gcc/ChangeLog:
* doc/extend.texi: Remove picoChip builtin section.
* doc/invoke.texi: Remove picoChip option section.
---
gcc/doc/extend.texi | 37 -
gcc/doc/invoke.texi | 53 -
2 files changed, 90 deletions(-)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index ca84f3a..608bbe1 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -14647,7 +14647,6 @@ instructions, but allow the compiler to schedule those
calls.
* Other MIPS Built-in Functions::
* MSP430 Built-in Functions::
* NDS32 Built-in Functions::
-* picoChip Built-in Functions::
* Basic PowerPC Built-in Functions::
* PowerPC AltiVec/VSX Built-in Functions::
* PowerPC Hardware Transactional Memory Built-in Functions::
@@ -17774,42 +17773,6 @@ Enable global interrupt.
Disable global interrupt.
@end deftypefn
-@node picoChip Built-in Functions
-@subsection picoChip Built-in Functions
-
-GCC provides an interface to selected machine instructions from the
-picoChip instruction set.
-
-@table @code
-@item int __builtin_sbc (int @var{value})
-Sign bit count. Return the number of consecutive bits in @var{value}
-that have the same value as the sign bit. The result is the number of
-leading sign bits minus one, giving the number of redundant sign bits in
-@var{value}.
-
-@item int __builtin_byteswap (int @var{value})
-Byte swap. Return the result of swapping the upper and lower bytes of
-@var{value}.
-
-@item int __builtin_brev (int @var{value})
-Bit reversal. Return the result of reversing the bits in
-@var{value}. Bit 15 is swapped with bit 0, bit 14 is swapped with bit 1,
-and so on.
-
-@item int __builtin_adds (int @var{x}, int @var{y})
-Saturating addition. Return the result of adding @var{x} and @var{y},
-storing the value 32767 if the result overflows.
-
-@item int __builtin_subs (int @var{x}, int @var{y})
-Saturating subtraction. Return the result of subtracting @var{y} from
-@var{x}, storing the value @minus{}32768 if the result overflows.
-
-@item void __builtin_halt (void)
-Halt. The processor stops execution. This built-in is useful for
-implementing assertions.
-
-@end table
-
@node Basic PowerPC Built-in Functions
@subsection Basic PowerPC Built-in Functions
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 12be55f..ef88f2a 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -1190,10 +1190,6 @@ Objective-C and Objective-C++ Dialects}.
-mint32 -mno-int16 -mint16 -mno-int32 @gol
-msplit -munix-asm -mdec-asm -mgnu-asm -mlra}
-@emph{picoChip Options}
-@gccoptlist{-mae=@var{ae_type} -mvliw-lookahead=@var{N} @gol
--msymbol-as-address -mno-inefficient-warnings}
-
@emph{PowerPC Options}
See RS/6000 and PowerPC Options.
@@ -19723,7 +19719,6 @@ platform.
* Nvidia PTX Options::
* OpenRISC Options::
* PDP-11 Options::
-* picoChip Options::
* PowerPC Options::
* PRU Options::
* RISC-V Options::
@@ -28396,54 +28391,6 @@ Use the new LRA register allocator. By default, the
old ``reload''
allocator is used.
@end table
-@node picoChip Options
-@subsection picoChip Options
-@cindex picoChip options
-
-These @samp{-m} options are defined for picoChip implementations:
-
-@table @gcctabopt
-
-@item -mae=@var{ae_type}
-@opindex mcpu
-Set the instruction set, register set, and instruction scheduling
-parameters for array element type @var{ae_type}. Supported values
-for @var{ae_type} are @samp{ANY}, @samp{MUL}, and @samp{MAC}.
-
-@option{-mae=ANY} selects a completely generic AE type. Code
-generated with this option runs on any of the other AE types. The
-code is not as efficient as it would be if compiled for a specific
-AE type, and some types of operation (e.g., multiplication) do not
-work properly on all types of AE.
-
-@option{-mae=MUL} selects a MUL AE type. This is the most useful AE type
-for compiled code, and is the default.
-
-@option{-mae=MAC} selects a DSP-style MAC AE. Code compiled with this
-option may suffer from poor performance of byte (char) manipulation,
-since the DSP AE does not provide hardware support for byte load/stores.
-
-@item -msymbol-as-address
-Enable the compiler to directly use a symbol name as an address in a
-load/store instruction, without first loading it into a
-register. Typically, the use of this option generates larger
-programs, which run faster than when the option isn't used. However, the
-results vary from program to program, so it is left as a user option,
-rather than being permanently enabled.
-
-@item -mno-inefficient-warnings
-Disables warnings about the generation of inefficient code. These
-warnings can be generated, for example, when compiling code that
[PATCH] Remove documentation for MeP
From: Andrew Pinski
MeP support was removed in r7-1614-g0609abdad81e26
but it looks like the documentation for the target
was missed.
Committed as obvious after doing "make html" to
make sure the documentation is fine.
Thanks,
Andrew Pinski
gcc/ChangeLog:
* doc/extend.texi: Remove MeP documentation.
* doc/invoke.texi: Remove MeP Options documentation.
---
gcc/doc/extend.texi | 190
gcc/doc/invoke.texi | 171 --
2 files changed, 361 deletions(-)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 8da0db9..ca84f3a 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -2542,7 +2542,6 @@ GCC plugins may provide their own attributes.
* M32R/D Function Attributes::
* m68k Function Attributes::
* MCORE Function Attributes::
-* MeP Function Attributes::
* MicroBlaze Function Attributes::
* Microsoft Windows Function Attributes::
* MIPS Function Attributes::
@@ -5392,45 +5391,6 @@ basic @code{asm} and C code may appear to work, they
cannot be
depended upon to work reliably and are not supported.
@end table
-@node MeP Function Attributes
-@subsection MeP Function Attributes
-
-These function attributes are supported by the MeP back end:
-
-@table @code
-@item disinterrupt
-@cindex @code{disinterrupt} function attribute, MeP
-On MeP targets, this attribute causes the compiler to emit
-instructions to disable interrupts for the duration of the given
-function.
-
-@item interrupt
-@cindex @code{interrupt} function attribute, MeP
-Use this attribute to indicate
-that the specified function is an interrupt handler. The compiler generates
-function entry and exit sequences suitable for use in an interrupt handler
-when this attribute is present.
-
-@item near
-@cindex @code{near} function attribute, MeP
-This attribute causes the compiler to assume the called
-function is close enough to use the normal calling convention,
-overriding the @option{-mtf} command-line option.
-
-@item far
-@cindex @code{far} function attribute, MeP
-On MeP targets this causes the compiler to use a calling convention
-that assumes the called function is too far away for the built-in
-addressing modes.
-
-@item vliw
-@cindex @code{vliw} function attribute, MeP
-The @code{vliw} attribute tells the compiler to emit
-instructions in VLIW mode instead of core mode. Note that this
-attribute is not allowed unless a VLIW coprocessor has been configured
-and enabled through command-line options.
-@end table
-
@node MicroBlaze Function Attributes
@subsection MicroBlaze Function Attributes
@@ -7336,7 +7296,6 @@ attributes.
* IA-64 Variable Attributes::
* LoongArch Variable Attributes::
* M32R/D Variable Attributes::
-* MeP Variable Attributes::
* Microsoft Windows Variable Attributes::
* MSP430 Variable Attributes::
* Nvidia PTX Variable Attributes::
@@ -8182,70 +8141,6 @@ Medium and large model objects may live anywhere in the
32-bit address space
addresses).
@end table
-@node MeP Variable Attributes
-@subsection MeP Variable Attributes
-
-The MeP target has a number of addressing modes and busses. The
-@code{near} space spans the standard memory space's first 16 megabytes
-(24 bits). The @code{far} space spans the entire 32-bit memory space.
-The @code{based} space is a 128-byte region in the memory space that
-is addressed relative to the @code{$tp} register. The @code{tiny}
-space is a 65536-byte region relative to the @code{$gp} register. In
-addition to these memory regions, the MeP target has a separate 16-bit
-control bus which is specified with @code{cb} attributes.
-
-@table @code
-
-@item based
-@cindex @code{based} variable attribute, MeP
-Any variable with the @code{based} attribute is assigned to the
-@code{.based} section, and is accessed with relative to the
-@code{$tp} register.
-
-@item tiny
-@cindex @code{tiny} variable attribute, MeP
-Likewise, the @code{tiny} attribute assigned variables to the
-@code{.tiny} section, relative to the @code{$gp} register.
-
-@item near
-@cindex @code{near} variable attribute, MeP
-Variables with the @code{near} attribute are assumed to have addresses
-that fit in a 24-bit addressing mode. This is the default for large
-variables (@code{-mtiny=4} is the default) but this attribute can
-override @code{-mtiny=} for small variables, or override @code{-ml}.
-
-@item far
-@cindex @code{far} variable attribute, MeP
-Variables with the @code{far} attribute are addressed using a full
-32-bit address. Since this covers the entire memory space, this
-allows modules to make no assumptions about where variables might be
-stored.
-
-@item io
-@cindex @code{io} variable attribute, MeP
-@itemx io (@var{addr})
-Variables with the @code{io} attribute are used to address
-memory-mapped peripherals. If an address is specified, the variable
-is assigned that address, else it is not assigned an address (it is
-assumed some other module assigns an
[PATCH] Fix @opindex for mcall-aixdesc and mcall-openbsd
From: Andrew Pinski
For mcall-aixdesc, the opindex was just m which was wrong.
For mcall-openbsd, the opindex was mcall-netbsd which was wrong.
This two have been broken since the options were added to the documentation
back in r0-92913-g244609a618b094 .
Committed as obvious after a "make html" and checking the options index.
Thanks,
Andrew
gcc/ChangeLog:
* doc/invoke.texi: Fix opindex for mcall-aixdesc and mcall-openbsd.
---
gcc/doc/invoke.texi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index dc2da464ebb..0276fbf4550 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -29640,7 +29640,7 @@ Specify both @option{-mcall-sysv} and @option{-meabi}
options.
Specify both @option{-mcall-sysv} and @option{-mno-eabi} options.
@item -mcall-aixdesc
-@opindex m
+@opindex mcall-aixdesc
On System V.4 and embedded PowerPC systems compile code for the AIX
operating system.
@@ -29660,7 +29660,7 @@ On System V.4 and embedded PowerPC systems compile code
for the
NetBSD operating system.
@item -mcall-openbsd
-@opindex mcall-netbsd
+@opindex mcall-openbsd
On System V.4 and embedded PowerPC systems compile code for the
OpenBSD operating system.
--
2.17.1
Re: [PATCH] RISC-V: Optimal RVV epilogue logic.
On 11/14/22 20:13, Kito Cheng wrote:
I would suggest add a sperated case and scan-assembly-not to demonstrate
this patch.
Agreed. One way to do this would be to have new tests which have the
proper dg-directives for testing this issue and #include the original test.
So, something like this:
/* { dg-do compile } */
/* { dg-options "-march=rv32gcv -mabi=ilp32 -mpreferred-stack-boundary=3
-O3 -fno-schedule-insns -fno-schedule-insns2" } */
#include "spill-1.c"
/* Make sure we do not have a useless SP adjustment. */
/* { dg-final { scan-assembler-not "addi sp, sp, 0" } } */
The key thing to know is that the dg directives are parsed by the
framework before preprocessing. So the dg-directives in spill-1.c would
not affect this new test. That requires us to provide our own, both for
how to run the test and what to look for.
Jeff
Re: [PATCH 7/7] riscv: Add support for str(n)cmp inline expansion
On 11/14/22 17:53, Palmer Dabbelt wrote: On Mon, 14 Nov 2022 16:46:37 PST (-0800), Kito Cheng wrote: Hi Christoph: This patch implements expansions for the cmpstrsi and the cmpstrnsi builtins using Zbb instructions (if available). This allows to inline calls to strcmp() and strncmp(). The expansion basically emits a peeled comparison sequence (i.e. a peeled comparison loop) which compares XLEN bits per step if possible. The emitted sequence can be controlled, by setting the maximum number of compared bytes (-mstring-compare-inline-limit). I would like to have a unified option interface, maybe -m[no-]inline-str[n]cmp and -minline-str[n]cmp-limit. And add some option like this: -minline-str[n]cmp=[bitmanip|vector|auto] in future, since I assume we'll have different versions of those things. Can we just decide that from mtune? We'll probably have uarch-specific string functions at some point, might as well start planning for it now. Sure, though the implementation isn't terribly tied to any uarch at the moment and I doubt uarch approaches would make significant impacts here -- we're peeling off some small number of iterations fairly generically. The uarch specific stuff would be the code in glibc selected by an ifunc. uarch variants for block copiers seem inevitable though :-) I don' t have strong opinions here, so if we want to key off mtune, sure. If we want to have variants for scalar vs vector that's quite reasonable too. Or if we want to go all the way to uarch specific implementations, I won't object. th gcc/ChangeLog: * config/riscv/riscv-protos.h (riscv_expand_strn_compare): New prototype. * config/riscv/riscv-string.cc (GEN_EMIT_HELPER3): New helper macros. (GEN_EMIT_HELPER2): New helper macros. (expand_strncmp_zbb_sequence): New function. (riscv_emit_str_compare_zbb): New function. (riscv_expand_strn_compare): New function. * config/riscv/riscv.md (cmpstrnsi): Invoke expansion functions for strn_compare. (cmpstrsi): Invoke expansion functions for strn_compare. * config/riscv/riscv.opt: Add new parameter '-mstring-compare-inline-limit'. We need to document this option. Yes, definitely needs documentation. Thanks for catching that. jeff
[Bug target/107676] Nonsensical docs for -mrelax-cmpxchg-loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107676 --- Comment #6 from Hongyu Wang --- (In reply to Andrew Pinski from comment #5) > (In reply to Jonathan Wakely from comment #4) > > I don't think __atomic_compare_exchange emits such a loop. This is about > > __atomic_fetch_xor and friends, which do emit cmpxchg loops. But there are > > four such functions to name. > > Oh yes right. > Then this: > For compare and exchange loops that are emitted by some __atomic_* builtins > (e.g. ), emit an atomic load before the loop and if the value was not > the expected value, emit a pause instruction. This might reduce execussive > cache bouncing of the memory. > > > I think that is better wording than it was before. I hope the person who > added this option can take over this to get it closer to what it should be. Thanks for all the suggestions, a patch has been posted at https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606212.html
[PATCH] doc: Reword the description of -mrelax-cmpxchg-loop [PR 107676]
Hi,
According to PR 107676, the document of -mrelax-cmpxchg-loop is nonsensical.
Adjust the wording according to the comments.
Bootstrapped on x86_64-pc-linux-gnu, ok for trunk?
gcc/ChangeLog:
PR target/107676
* doc/invoke.texi: Reword the description of
-mrelax-cmpxchg-loop.
---
gcc/doc/invoke.texi | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 40f667a630a..bdd7c319aef 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -33805,10 +33805,12 @@ registers.
@item -mrelax-cmpxchg-loop
@opindex mrelax-cmpxchg-loop
-Relax cmpxchg loop by emitting an early load and compare before cmpxchg,
-execute pause if load value is not expected. This reduces excessive
-cachline bouncing when and works for all atomic logic fetch builtins
-that generates compare and swap loop.
+For compare and swap loops that emitted by some __atomic_* builtins
+(e.g. __atomic_fetch_(or|and|xor|nand) and their __atomic_*_fetch
+counterparts), emit an atomic load before cmpxchg instruction. If the
+loaded value is not equal to expected, execute a pause instead of
+directly run the cmpxchg instruction. This might reduce excessive
+cacheline bouncing.
@item -mindirect-branch=@var{choice}
@opindex mindirect-branch
--
2.18.1
Re: [PATCH] RISC-V: Optimal RVV epilogue logic.
On 11/14/22 09:29, jiawei wrote:
Skip add insn generate if the adjust size equal to zero.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_expand_epilogue):
New if control segement.
---
gcc/config/riscv/riscv.cc | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 02a01ca0b7c..af138db7545 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -5186,24 +5186,26 @@ riscv_expand_epilogue (int style)
}
/* Get an rtx for STEP1 that we can add to BASE. */
- rtx adjust = GEN_INT (step1.to_constant ());
- if (!SMALL_OPERAND (step1.to_constant ()))
+ if (step1.to_constant () != 0){
This doesn't follow GCC formatting rules. The open-curley should go on
a new line, intended two spaces further in. This will (of course) cause
other code to need to be reindented as well.
Jeff
Re: Re: [PATCH] RISC-V: Optimal RVV epilogue logic.
I would suggest add a sperated case and scan-assembly-not to demonstrate
this patch.
juzhe.zh...@rivai.ai 於 2022年11月15日 週二 10:47 寫道：
> I think you'd better change assembler checking of "spill-*.c" cases.
> Check they don't have "addi sp,sp,0" redundant instruction.
> Let's see whether Kito aggree with that.
> --
> juzhe.zh...@rivai.ai
>
>
> *From:* jiawei
> *Date:* 2022-11-15 10:37
> *To:* Kito Cheng
> *CC:* gcc-patches ; kito.cheng
> ; palmer ; juzhe.zhong
> ; christoph.muellner ;
> philipp.tomsich ; wuwei2016
>
> *Subject:* Re: Re: [PATCH] RISC-V: Optimal RVV epilogue logic.
> -原始邮件-
> 发件人: "Kito Cheng"
> 发送时间: 2022-11-15 09:48:26 (星期二)
> 收件人: jiawei
> 抄送: gcc-patches@gcc.gnu.org, kito.ch...@sifive.com,
> pal...@rivosinc.com, juzhe.zh...@rivai.ai, christoph.muell...@vrull.eu,
> philipp.toms...@vrull.eu, wuwei2...@iscas.ac.cn
> 主题: Re: [PATCH] RISC-V: Optimal RVV epilogue logic.
>
> Could you provide some testcase?
>
> Sorry for not giving a clear description，
>
> You can use amost all testcases in gcc.target/riscv/rvv/base/spill-*.c
>
> compile with -march=rv64gcv and check the assemble file spill-*.s,
>
> before this patch, it will generate assemble code contain additional
>
> `addi sp,sp,0`:
>
> ```
> csrrt0,vlenb
> sllit1,t0,1
> add sp,sp,t1
> addisp,sp,0
> ld s0,24(sp)
> addisp,sp,32
> jr ra
> ```
>
> after this patch it will removed:
>
> ```
> csrrt0,vlenb
> sllit1,t0,1
> add sp,sp,t1
> ld s0,24(sp)
> addisp,sp,32
> jr ra
> ```
>
>
> On Tue, Nov 15, 2022 at 12:29 AM jiawei wrote:
>
> Skip add insn generate if the adjust size equal to zero.
>
> gcc/ChangeLog:
>
> * config/riscv/riscv.cc (riscv_expand_epilogue):
> New if control segement.
>
> ---
>gcc/config/riscv/riscv.cc | 18 ++
>1 file changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/gcc/config/riscv/riscv.cc
> b/gcc/config/riscv/riscv.cc
> index 02a01ca0b7c..af138db7545 100644
> --- a/gcc/config/riscv/riscv.cc
> +++ b/gcc/config/riscv/riscv.cc
> @@ -5186,24 +5186,26 @@ riscv_expand_epilogue (int style)
> }
>
> /* Get an rtx for STEP1 that we can add to BASE. */
> - rtx adjust = GEN_INT (step1.to_constant ());
> - if (!SMALL_OPERAND (step1.to_constant ()))
> + if (step1.to_constant () != 0){
> +rtx adjust = GEN_INT (step1.to_constant ());
> +if (!SMALL_OPERAND (step1.to_constant ()))
> {
> riscv_emit_move (RISCV_PROLOGUE_TEMP (Pmode), adjust);
> adjust = RISCV_PROLOGUE_TEMP (Pmode);
> }
>
> - insn = emit_insn (
> +insn = emit_insn (
> gen_add3_insn (stack_pointer_rtx,
> stack_pointer_rtx, adjust));
>
> - rtx dwarf = NULL_RTX;
> - rtx cfa_adjust_rtx = gen_rtx_PLUS (Pmode,
> stack_pointer_rtx,
> +rtx dwarf = NULL_RTX;
> +rtx cfa_adjust_rtx = gen_rtx_PLUS (Pmode,
> stack_pointer_rtx,
>GEN_INT (step2));
>
> - dwarf = alloc_reg_note (REG_CFA_DEF_CFA, cfa_adjust_rtx,
> dwarf);
> - RTX_FRAME_RELATED_P (insn) = 1;
> +dwarf = alloc_reg_note (REG_CFA_DEF_CFA,
> cfa_adjust_rtx, dwarf);
> +RTX_FRAME_RELATED_P (insn) = 1;
>
> - REG_NOTES (insn) = dwarf;
> +REG_NOTES (insn) = dwarf;
> + }
>}
> else if (frame_pointer_needed)
>{
> --
> 2.25.1
>
>
>
>
Re: Re: [PATCH] RISC-V: Optimal RVV epilogue logic.
I think you'd better change assembler checking of "spill-*.c" cases.
Check they don't have "addi sp,sp,0" redundant instruction.
Let's see whether Kito aggree with that.
juzhe.zh...@rivai.ai
From: jiawei
Date: 2022-11-15 10:37
To: Kito Cheng
CC: gcc-patches; kito.cheng; palmer; juzhe.zhong; christoph.muellner;
philipp.tomsich; wuwei2016
Subject: Re: Re: [PATCH] RISC-V: Optimal RVV epilogue logic.
-原始邮件-
发件人: "Kito Cheng"
发送时间: 2022-11-15 09:48:26 (星期二)
收件人: jiawei
抄送: gcc-patches@gcc.gnu.org, kito.ch...@sifive.com, pal...@rivosinc.com,
juzhe.zh...@rivai.ai, christoph.muell...@vrull.eu, philipp.toms...@vrull.eu,
wuwei2...@iscas.ac.cn
主题: Re: [PATCH] RISC-V: Optimal RVV epilogue logic.
Could you provide some testcase?
Sorry for not giving a clear description，
You can use amost all testcases in gcc.target/riscv/rvv/base/spill-*.c
compile with -march=rv64gcv and check the assemble file spill-*.s,
before this patch, it will generate assemble code contain additional
`addi sp,sp,0`:
```
csrrt0,vlenb
sllit1,t0,1
add sp,sp,t1
addisp,sp,0
ld s0,24(sp)
addisp,sp,32
jr ra
```
after this patch it will removed:
```
csrrt0,vlenb
sllit1,t0,1
add sp,sp,t1
ld s0,24(sp)
addisp,sp,32
jr ra
```
On Tue, Nov 15, 2022 at 12:29 AM jiawei wrote:
Skip add insn generate if the adjust size equal to zero.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_expand_epilogue):
New if control segement.
---
gcc/config/riscv/riscv.cc | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 02a01ca0b7c..af138db7545 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -5186,24 +5186,26 @@ riscv_expand_epilogue (int style)
}
/* Get an rtx for STEP1 that we can add to BASE. */
- rtx adjust = GEN_INT (step1.to_constant ());
- if (!SMALL_OPERAND (step1.to_constant ()))
+ if (step1.to_constant () != 0){
+rtx adjust = GEN_INT (step1.to_constant ());
+if (!SMALL_OPERAND (step1.to_constant ()))
{
riscv_emit_move (RISCV_PROLOGUE_TEMP (Pmode), adjust);
adjust = RISCV_PROLOGUE_TEMP (Pmode);
}
- insn = emit_insn (
+insn = emit_insn (
gen_add3_insn (stack_pointer_rtx, stack_pointer_rtx,
adjust));
- rtx dwarf = NULL_RTX;
- rtx cfa_adjust_rtx = gen_rtx_PLUS (Pmode, stack_pointer_rtx,
+rtx dwarf = NULL_RTX;
+rtx cfa_adjust_rtx = gen_rtx_PLUS (Pmode, stack_pointer_rtx,
GEN_INT (step2));
- dwarf = alloc_reg_note (REG_CFA_DEF_CFA, cfa_adjust_rtx,
dwarf);
- RTX_FRAME_RELATED_P (insn) = 1;
+dwarf = alloc_reg_note (REG_CFA_DEF_CFA, cfa_adjust_rtx,
dwarf);
+RTX_FRAME_RELATED_P (insn) = 1;
- REG_NOTES (insn) = dwarf;
+REG_NOTES (insn) = dwarf;
+ }
}
else if (frame_pointer_needed)
{
--
2.25.1
Re: Re: [PATCH] RISC-V: Optimal RVV epilogue logic.
-原始邮件-
发件人: "Kito Cheng"
发送时间: 2022-11-15 09:48:26 (星期二)
收件人: jiawei
抄送: gcc-patches@gcc.gnu.org, kito.ch...@sifive.com, pal...@rivosinc.com,
juzhe.zh...@rivai.ai, christoph.muell...@vrull.eu, philipp.toms...@vrull.eu,
wuwei2...@iscas.ac.cn
主题: Re: [PATCH] RISC-V: Optimal RVV epilogue logic.
Could you provide some testcase?
Sorry for not giving a clear description，
You can use amost all testcases in gcc.target/riscv/rvv/base/spill-*.c
compile with -march=rv64gcv and check the assemble file spill-*.s,
before this patch, it will generate assemble code contain additional
`addi sp,sp,0`:
```
csrrt0,vlenb
sllit1,t0,1
add sp,sp,t1
addisp,sp,0
ld s0,24(sp)
addisp,sp,32
jr ra
```
after this patch it will removed:
```
csrrt0,vlenb
sllit1,t0,1
add sp,sp,t1
ld s0,24(sp)
addisp,sp,32
jr ra
```
On Tue, Nov 15, 2022 at 12:29 AM jiawei wrote:
Skip add insn generate if the adjust size equal to zero.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_expand_epilogue):
New if control segement.
---
gcc/config/riscv/riscv.cc | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 02a01ca0b7c..af138db7545 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -5186,24 +5186,26 @@ riscv_expand_epilogue (int style)
}
/* Get an rtx for STEP1 that we can add to BASE. */
- rtx adjust = GEN_INT (step1.to_constant ());
- if (!SMALL_OPERAND (step1.to_constant ()))
+ if (step1.to_constant () != 0){
+rtx adjust = GEN_INT (step1.to_constant ());
+if (!SMALL_OPERAND (step1.to_constant ()))
{
riscv_emit_move (RISCV_PROLOGUE_TEMP (Pmode), adjust);
adjust = RISCV_PROLOGUE_TEMP (Pmode);
}
- insn = emit_insn (
+insn = emit_insn (
gen_add3_insn (stack_pointer_rtx, stack_pointer_rtx,
adjust));
- rtx dwarf = NULL_RTX;
- rtx cfa_adjust_rtx = gen_rtx_PLUS (Pmode, stack_pointer_rtx,
+rtx dwarf = NULL_RTX;
+rtx cfa_adjust_rtx = gen_rtx_PLUS (Pmode, stack_pointer_rtx,
GEN_INT (step2));
- dwarf = alloc_reg_note (REG_CFA_DEF_CFA, cfa_adjust_rtx,
dwarf);
- RTX_FRAME_RELATED_P (insn) = 1;
+dwarf = alloc_reg_note (REG_CFA_DEF_CFA, cfa_adjust_rtx,
dwarf);
+RTX_FRAME_RELATED_P (insn) = 1;
- REG_NOTES (insn) = dwarf;
+REG_NOTES (insn) = dwarf;
+ }
}
else if (frame_pointer_needed)
{
--
2.25.1
[Bug c++/107638] [13 Regression] options.h:239:36: error: token "." is not valid in preprocessor expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107638 --- Comment #4 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:fce38b7d13ae625301571dcd84f3774ddaa6ed04 commit r13-4039-gfce38b7d13ae625301571dcd84f3774ddaa6ed04 Author: Patrick Palka Date: Mon Nov 14 21:28:58 2022 -0500 c++: init_priority and SUPPORTS_INIT_PRIORITY [PR107638] The commit r13-3706-gd0a492faa6478c for fixing the result of __has_attribute(init_priority) causes a bootstrap failure on hppa64-hpux due to assuming the macro SUPPORTS_INIT_PRIORITY expands to a simple constant, but on this target the macro is defined as #define SUPPORTS_INIT_PRIORITY (TARGET_GNU_LD ? 1 : 0) (where TARGET_GNU_LD expands to something in terms of global_options) which means we can't use the macro to conditionally exclude the entry for init_priority when defining the cxx_attribute_table. So instead of trying to exclude init_priority from the attribute table, this patch just makes __has_attribute handle init_priority specially. PR c++/107638 gcc/c-family/ChangeLog: * c-lex.cc (c_common_has_attribute): Return 1 for init_priority iff SUPPORTS_INIT_PRIORITY. gcc/cp/ChangeLog: * tree.cc (cxx_attribute_table): Don't conditionally exclude the init_priority entry. (handle_init_priority_attribute): Remove ATTRIBUTE_UNUSED. Return error_mark_node if !SUPPORTS_INIT_PRIORITY.
Re: [PATCH 7/7] riscv: Add support for str(n)cmp inline expansion
On Tue, Nov 15, 2022 at 8:53 AM Palmer Dabbelt wrote: > > On Mon, 14 Nov 2022 16:46:37 PST (-0800), Kito Cheng wrote: > > Hi Christoph: > > > >> This patch implements expansions for the cmpstrsi and the cmpstrnsi > >> builtins using Zbb instructions (if available). > >> This allows to inline calls to strcmp() and strncmp(). > >> > >> The expansion basically emits a peeled comparison sequence (i.e. a peeled > >> comparison loop) which compares XLEN bits per step if possible. > >> > >> The emitted sequence can be controlled, by setting the maximum number > >> of compared bytes (-mstring-compare-inline-limit). > > > > I would like to have a unified option interface, > > maybe -m[no-]inline-str[n]cmp and -minline-str[n]cmp-limit. > > And add some option like this: > > -minline-str[n]cmp=[bitmanip|vector|auto] in future, > > since I assume we'll have different versions of those things. > > Can we just decide that from mtune? We'll probably have uarch-specific > string functions at some point, might as well start planning for it now. I assume you mean the -minline-str[n]cmp=[bitmanip|vector|auto] part? I think this part should have more discussion and could defer that until we reach consensus. But -m[no-]inline-str[n]cmp and -minline-str[n]cmp-limit part I favor having those two options to disable and/or fine tune those parameters. > > >> gcc/ChangeLog: > >> > >> * config/riscv/riscv-protos.h (riscv_expand_strn_compare): New > >> prototype. > >> * config/riscv/riscv-string.cc (GEN_EMIT_HELPER3): New helper > >> macros. > >> (GEN_EMIT_HELPER2): New helper macros. > >> (expand_strncmp_zbb_sequence): New function. > >> (riscv_emit_str_compare_zbb): New function. > >> (riscv_expand_strn_compare): New function. > >> * config/riscv/riscv.md (cmpstrnsi): Invoke expansion functions > >> for strn_compare. > >> (cmpstrsi): Invoke expansion functions for strn_compare. > >> * config/riscv/riscv.opt: Add new parameter > >> '-mstring-compare-inline-limit'. > > > > We need to document this option.
Re: [PATCH] RISC-V: Optimal RVV epilogue logic.
Could you provide some testcase?
On Tue, Nov 15, 2022 at 12:29 AM jiawei wrote:
>
> Skip add insn generate if the adjust size equal to zero.
>
> gcc/ChangeLog:
>
> * config/riscv/riscv.cc (riscv_expand_epilogue):
> New if control segement.
>
> ---
> gcc/config/riscv/riscv.cc | 18 ++
> 1 file changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
> index 02a01ca0b7c..af138db7545 100644
> --- a/gcc/config/riscv/riscv.cc
> +++ b/gcc/config/riscv/riscv.cc
> @@ -5186,24 +5186,26 @@ riscv_expand_epilogue (int style)
> }
>
>/* Get an rtx for STEP1 that we can add to BASE. */
> - rtx adjust = GEN_INT (step1.to_constant ());
> - if (!SMALL_OPERAND (step1.to_constant ()))
> + if (step1.to_constant () != 0){
> +rtx adjust = GEN_INT (step1.to_constant ());
> +if (!SMALL_OPERAND (step1.to_constant ()))
> {
> riscv_emit_move (RISCV_PROLOGUE_TEMP (Pmode), adjust);
> adjust = RISCV_PROLOGUE_TEMP (Pmode);
> }
>
> - insn = emit_insn (
> +insn = emit_insn (
>gen_add3_insn (stack_pointer_rtx, stack_pointer_rtx, adjust));
>
> - rtx dwarf = NULL_RTX;
> - rtx cfa_adjust_rtx = gen_rtx_PLUS (Pmode, stack_pointer_rtx,
> +rtx dwarf = NULL_RTX;
> +rtx cfa_adjust_rtx = gen_rtx_PLUS (Pmode, stack_pointer_rtx,
> GEN_INT (step2));
>
> - dwarf = alloc_reg_note (REG_CFA_DEF_CFA, cfa_adjust_rtx, dwarf);
> - RTX_FRAME_RELATED_P (insn) = 1;
> +dwarf = alloc_reg_note (REG_CFA_DEF_CFA, cfa_adjust_rtx, dwarf);
> +RTX_FRAME_RELATED_P (insn) = 1;
>
> - REG_NOTES (insn) = dwarf;
> +REG_NOTES (insn) = dwarf;
> + }
> }
>else if (frame_pointer_needed)
> {
> --
> 2.25.1
>
[Bug libstdc++/107660] Running binaries compiled with g++11 or later produces different results than g++ version 10 or earlier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107660 --- Comment #6 from Jonathan Wakely --- It's expected and required by the standard that std::mt19937 produces the same numbers every time. And if I run a test for GCC 10 and GCC 11 I see the same number produced for the first 2.14 billion results.
Re: [PATCH] lto: Stream current working directory for first streamed relative filename and adjust relative paths [PR93865]
On Thu, Sep 10, 2020 at 1:39 AM Jakub Jelinek via Gcc-patches
wrote:
>
> If the gcc -c -flto ... commands to compile some or all objects are run in a
> different directory (or in different directories) from the directory in
> which the gcc -flto link line is invoked, then the .debug_line will be
> incorrect if there are any relative filenames, it will use those relative
> filenames while .debug_info will contain a different DW_AT_comp_dir.
>
> The following patch streams (at most once after each clear_line_info)
> the current working directory (what we record in DW_AT_comp_dir) when
> encountering the first relative pathname, and when reading the location info
> reads it back and if the current working directory at that point is
> different from the saved one, adjusts relative paths by adding a relative
> prefix how to go from the current working directory to the previously saved
> path (with a fallback e.g. for DOS e:\\foo vs. d:\\bar change to use
> absolute directory).
>
> Bootstrapped/regtested on x86_64-linux (both lto bootstrap and normal one;
> i686-linux doesn't build due to some unrelated libgo bugs), ok for trunk?
>
> 2020-09-10 Jakub Jelinek
>
> PR debug/93865
> * lto-streamer.h (struct output_block): Add emit_pad member.
> * lto-streamer-out.c: Include toplev.h.
> (clear_line_info): Set emit_pwd.
> (lto_output_location_1): Encode the ob->current_file != xloc.file
> bit directly into the location number. If changing file, emit
> additionally a bit whether pwd is emitted and emit it before the
> first relative pathname since clear_line_info.
> (output_function, output_constructor): Don't call clear_line_info
> here.
> * lto-streamer-in.c (struct string_pair_map): New type.
> (struct string_pair_map_hasher): New type.
> (string_pair_map_hasher::hash): New method.
> (string_pair_map_hasher::equal): New method.
> (path_name_pair_hash_table, string_pair_map_allocator): New variables.
> (relative_path_prefix, canon_relative_path_prefix,
> canon_relative_file_name): New functions.
> (canon_file_name): Add relative_prefix argument, if non-NULL
> and string is a relative path, return canon_relative_file_name.
> (lto_location_cache::input_location_and_block): Decode file change
> bit from the location number. If changing file, unpack bit whether
> pwd is streamed and stream in pwd. Adjust canon_file_name caller.
> (lto_free_file_name_hash): Delete path_name_pair_hash_table
> and string_pair_map_allocator.
Hi, I've noticed that this patch is incomplete. It streams the result
of get_src_pwd without passing it through remap_debug_filename. As in
comp_dir_output in dwarf2out.cc, we should always remap all file and
directory names, including the result of get_src_pwd.
Ian
> --- gcc/lto-streamer.h.jj 2020-09-09 09:08:13.102815586 +0200
> +++ gcc/lto-streamer.h 2020-09-09 12:36:13.120070769 +0200
> @@ -718,6 +718,7 @@ struct output_block
>int current_col;
>bool current_sysp;
>bool reset_locus;
> + bool emit_pwd;
>tree current_block;
>
>/* Cache of nodes written in this section. */
> --- gcc/lto-streamer-out.c.jj 2020-09-09 09:08:13.077815963 +0200
> +++ gcc/lto-streamer-out.c 2020-09-09 13:21:34.093021582 +0200
> @@ -47,6 +47,7 @@ along with GCC; see the file COPYING3.
> #include "file-prefix-map.h" /* remap_debug_filename() */
> #include "output.h"
> #include "ipa-utils.h"
> +#include "toplev.h"
>
>
> static void lto_write_tree (struct output_block*, tree, bool);
> @@ -61,6 +62,7 @@ clear_line_info (struct output_block *ob
>ob->current_col = 0;
>ob->current_sysp = false;
>ob->reset_locus = true;
> + ob->emit_pwd = true;
>/* Initialize to something that will never appear as block,
> so that the first location with block in a function etc.
> always streams a change_block bit and the first block. */
> @@ -189,9 +191,6 @@ lto_output_location_1 (struct output_blo
> {
>location_t loc = LOCATION_LOCUS (orig_loc);
>
> - bp_pack_int_in_range (bp, 0, RESERVED_LOCATION_COUNT,
> - loc < RESERVED_LOCATION_COUNT
> - ? loc : RESERVED_LOCATION_COUNT);
>if (loc >= RESERVED_LOCATION_COUNT)
> {
>expanded_location xloc = expand_location (loc);
> @@ -207,13 +206,30 @@ lto_output_location_1 (struct output_blo
> ob->reset_locus = false;
> }
>
> - bp_pack_value (bp, ob->current_file != xloc.file, 1);
> + /* As RESERVED_LOCATION_COUNT is 2, we can use the spare value of
> +3 without wasting additional bits to signalize file change.
> +If RESERVED_LOCATION_COUNT changes, reconsider this. */
> + gcc_checking_assert (RESERVED_LOCATION_COUNT == 2);
> + bp_pack_int_in_range (bp, 0, RESERVED_LOCATION_COUNT + 1,
> +
[Bug target/107671] i386: Missed optimization: use of bt in bit test pattern (using -O2 -mtune=core2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107671 --- Comment #3 from Hongtao.liu --- We already have --cut from i386.md 15204;; Help combine recognize bt followed by setc 15205(define_insn_and_split "*bt_setcqi" 15206 [(set (subreg:SWI48 (match_operand:QI 0 "register_operand") 0) 15207(zero_extract:SWI48 15208 (match_operand:SWI48 1 "register_operand") 15209 (const_int 1) 15210 (zero_extend:SI (match_operand:QI 2 "register_operand" 15211 (clobber (reg:CC FLAGS_REG))] 15212 "TARGET_USE_BT && ix86_pre_reload_split ()" 15262;; Help combine recognize bt followed by setnc 15263(define_insn_and_split "*bt_setncqi" 15264 [(set (match_operand:QI 0 "register_operand") 15265(and:QI 15266 (not:QI 15267 (subreg:QI 15268 (lshiftrt:SWI48 (match_operand:SWI48 1 "register_operand") 15269 (match_operand:QI 2 "register_operand")) 0)) 15270 (const_int 1))) 15271 (clobber (reg:CC FLAGS_REG))] 15272 "TARGET_USE_BT && ix86_pre_reload_split ()" 15273 "#" 15274 "&& 1" ---cut end- Guess we need more variants for that.
Re: [PATCH 7/7] riscv: Add support for str(n)cmp inline expansion
On Mon, 14 Nov 2022 16:46:37 PST (-0800), Kito Cheng wrote: Hi Christoph: This patch implements expansions for the cmpstrsi and the cmpstrnsi builtins using Zbb instructions (if available). This allows to inline calls to strcmp() and strncmp(). The expansion basically emits a peeled comparison sequence (i.e. a peeled comparison loop) which compares XLEN bits per step if possible. The emitted sequence can be controlled, by setting the maximum number of compared bytes (-mstring-compare-inline-limit). I would like to have a unified option interface, maybe -m[no-]inline-str[n]cmp and -minline-str[n]cmp-limit. And add some option like this: -minline-str[n]cmp=[bitmanip|vector|auto] in future, since I assume we'll have different versions of those things. Can we just decide that from mtune? We'll probably have uarch-specific string functions at some point, might as well start planning for it now. gcc/ChangeLog: * config/riscv/riscv-protos.h (riscv_expand_strn_compare): New prototype. * config/riscv/riscv-string.cc (GEN_EMIT_HELPER3): New helper macros. (GEN_EMIT_HELPER2): New helper macros. (expand_strncmp_zbb_sequence): New function. (riscv_emit_str_compare_zbb): New function. (riscv_expand_strn_compare): New function. * config/riscv/riscv.md (cmpstrnsi): Invoke expansion functions for strn_compare. (cmpstrsi): Invoke expansion functions for strn_compare. * config/riscv/riscv.opt: Add new parameter '-mstring-compare-inline-limit'. We need to document this option.
Re: [PATCH 7/7] riscv: Add support for str(n)cmp inline expansion
Hi Christoph: > This patch implements expansions for the cmpstrsi and the cmpstrnsi > builtins using Zbb instructions (if available). > This allows to inline calls to strcmp() and strncmp(). > > The expansion basically emits a peeled comparison sequence (i.e. a peeled > comparison loop) which compares XLEN bits per step if possible. > > The emitted sequence can be controlled, by setting the maximum number > of compared bytes (-mstring-compare-inline-limit). I would like to have a unified option interface, maybe -m[no-]inline-str[n]cmp and -minline-str[n]cmp-limit. And add some option like this: -minline-str[n]cmp=[bitmanip|vector|auto] in future, since I assume we'll have different versions of those things. > > gcc/ChangeLog: > > * config/riscv/riscv-protos.h (riscv_expand_strn_compare): New > prototype. > * config/riscv/riscv-string.cc (GEN_EMIT_HELPER3): New helper > macros. > (GEN_EMIT_HELPER2): New helper macros. > (expand_strncmp_zbb_sequence): New function. > (riscv_emit_str_compare_zbb): New function. > (riscv_expand_strn_compare): New function. > * config/riscv/riscv.md (cmpstrnsi): Invoke expansion functions > for strn_compare. > (cmpstrsi): Invoke expansion functions for strn_compare. > * config/riscv/riscv.opt: Add new parameter > '-mstring-compare-inline-limit'. We need to document this option.
[PATCH v2] c++: Disable -Wignored-qualifiers for template args [PR107492]
On Thu, Nov 03, 2022 at 03:22:12PM -0400, Jason Merrill wrote:
> On 11/1/22 13:01, Marek Polacek wrote:
> > It seems wrong to issue a -Wignored-qualifiers warning for code like:
> >
> >static_assert(!is_same_v);
> >
> > because there the qualifier matters. Likewise in template
> > specialization:
> >
> >template struct S { };
> >template<> struct S { };
> >template<> struct S { }; // OK, not a redefinition
> >
> > I'm of the mind that we should disable the warning for template
> > arguments, as in the patch below.
>
> Hmm, I'm not sure why we would want to treat template arguments differently
> from other type-ids. Maybe only warn if funcdecl_p?
I think that makes sense. There are other contexts in which cv-quals
matter, for instance trailing-return-type. Updated patch below, plus
I've extended the testcase. Thanks,
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
It seems wrong to issue a -Wignored-qualifiers warning for code like:
static_assert(!is_same_v);
because there the qualifier matters. Likewise in template
specialization:
template struct S { };
template<> struct S { };
template<> struct S { }; // OK, not a redefinition
And likewise in other type-id contexts such as trailing-return-type:
auto g() -> const void (*)();
This patch limits the warning to the function declaration context only.
PR c++/107492
gcc/cp/ChangeLog:
* decl.cc (grokdeclarator): Only emit a -Wignored-qualifiers warning
when funcdecl_p.
gcc/testsuite/ChangeLog:
* g++.dg/warn/Wignored-qualifiers3.C: New test.
---
gcc/cp/decl.cc| 6 -
.../g++.dg/warn/Wignored-qualifiers3.C| 24 +++
2 files changed, 29 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/g++.dg/warn/Wignored-qualifiers3.C
diff --git a/gcc/cp/decl.cc b/gcc/cp/decl.cc
index 890cfcabd35..67b9f24d7d6 100644
--- a/gcc/cp/decl.cc
+++ b/gcc/cp/decl.cc
@@ -13038,7 +13038,11 @@ grokdeclarator (const cp_declarator *declarator,
if (type_quals != TYPE_UNQUALIFIED)
{
- if (SCALAR_TYPE_P (type) || VOID_TYPE_P (type))
+ /* It's wrong, for instance, to issue a -Wignored-qualifiers
+ warning for
+ static_assert(!is_same_v);
+ because there the qualifier matters. */
+ if (funcdecl_p && (SCALAR_TYPE_P (type) || VOID_TYPE_P (type)))
warning_at (typespec_loc, OPT_Wignored_qualifiers, "type "
"qualifiers ignored on function return type");
/* [dcl.fct] "A volatile-qualified return type is
diff --git a/gcc/testsuite/g++.dg/warn/Wignored-qualifiers3.C
b/gcc/testsuite/g++.dg/warn/Wignored-qualifiers3.C
new file mode 100644
index 000..dedb38fc995
--- /dev/null
+++ b/gcc/testsuite/g++.dg/warn/Wignored-qualifiers3.C
@@ -0,0 +1,24 @@
+// PR c++/107492
+// { dg-do compile { target c++14 } }
+// { dg-additional-options "-Wignored-qualifiers" }
+
+// Here the 'const' matters, so don't warn.
+template struct S { };
+template<> struct S { };
+template<> struct S { }; // { dg-bogus "ignored" }
+
+template constexpr bool is_same_v = false;
+template constexpr bool is_same_v = true;
+
+static_assert( ! is_same_v< void(*)(), const void(*)() >, ""); // { dg-bogus
"ignored" }
+
+// Here the 'const' matters as well -> don't warn.
+auto g() -> const void (*)(); // { dg-bogus "ignored" }
+auto g() -> const void (*)() { return nullptr; } // { dg-bogus "ignored" }
+
+// Here as well.
+const void (*h)() = static_cast(h); // { dg-bogus "ignored" }
+
+// But let's keep the warning here.
+const void f(); // { dg-warning "ignored" }
+const void f() { } // { dg-warning "ignored" }
base-commit: c41bbfcaf9d6ef5b57a7e89bba70b861c08a686b
--
2.38.1
[Bug tree-optimization/107326] [13 Regression] ICE: verify_gimple failed (error: type mismatch in binary expression) since r13-3219-g25413fdb2ac249
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107326 --- Comment #6 from Arseny Solokha --- Yes, this one is fixed. Thanks.
Re: [PATCH 7/7] riscv: Add support for str(n)cmp inline expansion
On 11/14/22 14:49, Christoph Müllner wrote: We can take this further, but then the following questions pop up: * how much data processing per loop iteration? I have no idea because I don't have any real data. Last time I gathered any data on this issue was circa 1988 :-) * what about unaligned strings? I'd punt. I don't think we can depend on having a high performance unaligned access. You could do a dynamic check of alignment, but you'd really need to know that they're aligned often enough that the dynamic check can often be recovered. Happy to get suggestions/opinions for improvement. I think this is pretty good without additional data that would indicate that handling unaligned cases or a different number of loop peels would be a notable improvement. Jeff
Re: [PATCH] ira: Remove duplicate `memset' over `full_costs' from `assign_hard_reg'
On 11/14/22 16:21, Maciej W. Rozycki wrote:
Remove duplicate clearing of `full_costs' made in `assign_hard_reg',
which has been there since the beginning, i.e. commit 058e97ecf33a
("IRA has been merged into trunk"),
.
gcc/
* ira-color.cc (assign_hard_reg): Remove duplicate `memset' over
`full_costs'.
---
Hi,
I find this fairly obvious, OK to apply?
Seems obvious to me as well. OK.
jeff
Re: [PATCH] c++: Add testcase for DR 2392
On 11/14/22 00:36, Jakub Jelinek wrote:
Hi!
Working virtually out of Baker Island.
The testcase from DR 2392 passes, so I assume we don't need to do
anything further for the DR.
Tested on x86_64-linux, ok for trunk?
OK.
2022-11-13 Jakub Jelinek
* g++.dg/DRs/dr2392.C: Add testcase for DR 2392.
--- gcc/testsuite/g++.dg/DRs/dr2392.C.jj2022-11-13 20:49:22.107817793
-1200
+++ gcc/testsuite/g++.dg/DRs/dr2392.C 2022-11-13 20:49:17.506880524 -1200
@@ -0,0 +1,12 @@
+// DR 2392
+// { dg-do compile { target c++11 } }
+
+template
+constexpr int
+foo ()
+{
+ T t;
+ return 1;
+}
+
+using V = decltype (new int[foo ()]);
Jakub
Re: [PATCH] c++: Allow attributes on concepts - DR 2428
On 11/14/22 00:40, Jakub Jelinek wrote:
Hi!
Working virtually out of Baker Island.
The following patch adds parsing of attributes to concept definition,
allows deprecated attribute to be specified (some ugliness needed
because CONCEPT_DECL is a cp/*.def attribute and so can't be mentioned
in c-family/ directly; used what is used for objc method decls,
an alternative would be a langhook)
Several of the codes in c-common.def are C++-only, you might just move
it over?
and checks TREE_DEPRECATED in
build_standard_check (not sure if that is the right spot, or whether
it shouldn't be checked also for variable and function concepts and
how to write testcase coverage for that).
I wouldn't bother with var/fn concepts, they're obsolete.
Lightly tested so far.
2022-11-13 Jakub Jelinek
gcc/c-family/
* c-common.h (c_concept_decl): Declare.
* c-attribs.cc (handle_deprecated_attribute): Allow deprecated
attribute on CONCEPT_DECL if flag_concepts.
gcc/c/
* c-decl.cc (c_concept_decl): New function.
gcc/cp/
* cp-tree.h (finish_concept_definition): Add ATTRS parameter.
* parser.cc (cp_parser_concept_definition): Parse attributes in
between identifier and =. Adjust finish_concept_definition
caller.
* pt.cc (finish_concept_definition): Add ATTRS parameter. Call
cplus_decl_attributes.
* constraint.cc (build_standard_check): If CONCEPT_DECL is
TREE_DEPRECATED, emit -Wdeprecated-declaration warnings.
* tree.cc (c_concept_decl): New function.
gcc/testsuite/
* g++.dg/cpp2a/concepts-dr2428.C: New test.
--- gcc/c-family/c-common.h.jj 2022-10-27 21:00:53.698247586 -1200
+++ gcc/c-family/c-common.h 2022-11-13 21:49:37.934598359 -1200
@@ -831,6 +831,7 @@ extern tree (*make_fname_decl) (location
/* In c-decl.cc and cp/tree.cc. FIXME. */
extern void c_register_addr_space (const char *str, addr_space_t as);
+extern bool c_concept_decl (enum tree_code);
/* In c-common.cc. */
extern bool in_late_binary_op;
--- gcc/c-family/c-attribs.cc.jj2022-10-09 19:31:57.177988375 -1200
+++ gcc/c-family/c-attribs.cc 2022-11-13 21:52:37.920152731 -1200
@@ -4211,7 +4211,8 @@ handle_deprecated_attribute (tree *node,
|| VAR_OR_FUNCTION_DECL_P (decl)
|| TREE_CODE (decl) == FIELD_DECL
|| TREE_CODE (decl) == CONST_DECL
- || objc_method_decl (TREE_CODE (decl)))
+ || objc_method_decl (TREE_CODE (decl))
+ || (flag_concepts && c_concept_decl (TREE_CODE (decl
TREE_DEPRECATED (decl) = 1;
else if (TREE_CODE (decl) == LABEL_DECL)
{
--- gcc/c/c-decl.cc.jj 2022-11-12 23:29:08.181504470 -1200
+++ gcc/c/c-decl.cc 2022-11-13 21:50:38.178779716 -1200
@@ -12987,6 +12987,14 @@ c_register_addr_space (const char *word,
ridpointers [rid] = id;
}
+/* C doesn't have CONCEPT_DECL. */
+
+bool
+c_concept_decl (enum tree_code)
+{
+ return false;
+}
+
/* Return identifier to look up for omp declare reduction. */
tree
--- gcc/cp/cp-tree.h.jj 2022-11-11 20:30:10.138056914 -1200
+++ gcc/cp/cp-tree.h2022-11-13 20:58:39.443218815 -1200
@@ -8324,7 +8324,7 @@ struct diagnosing_failed_constraint
extern cp_expr finish_constraint_or_expr (location_t, cp_expr, cp_expr);
extern cp_expr finish_constraint_and_expr (location_t, cp_expr, cp_expr);
extern cp_expr finish_constraint_primary_expr (cp_expr);
-extern tree finish_concept_definition (cp_expr, tree);
+extern tree finish_concept_definition (cp_expr, tree, tree);
extern tree combine_constraint_expressions (tree, tree);
extern tree append_constraint (tree, tree);
extern tree get_constraints (const_tree);
--- gcc/cp/parser.cc.jj 2022-11-08 22:39:13.325041007 -1200
+++ gcc/cp/parser.cc2022-11-13 20:58:15.692542640 -1200
@@ -29672,6 +29672,8 @@ cp_parser_concept_definition (cp_parser
return NULL_TREE;
}
+ tree attrs = cp_parser_attributes_opt (parser);
+
if (!cp_parser_require (parser, CPP_EQ, RT_EQ))
{
cp_parser_skip_to_end_of_statement (parser);
@@ -29688,7 +29690,7 @@ cp_parser_concept_definition (cp_parser
but continue as if it were. */
cp_parser_consume_semicolon_at_end_of_statement (parser);
- return finish_concept_definition (id, init);
+ return finish_concept_definition (id, init, attrs);
}
// -- //
--- gcc/cp/pt.cc.jj 2022-11-07 20:54:37.341399829 -1200
+++ gcc/cp/pt.cc2022-11-13 21:01:18.333053377 -1200
@@ -29027,7 +29027,7 @@ placeholder_type_constraint_dependent_p
the TEMPLATE_DECL. */
tree
-finish_concept_definition (cp_expr id, tree init)
+finish_concept_definition (cp_expr id, tree init, tree attrs)
{
gcc_assert (identifier_p (id));
gcc_assert (processing_template_decl);
@@ -29061,6 +29061,9 @@
Re: [PATCH 2/2] c++: remove i_c_e_p parm from tsubst_copy_and_build
On 11/10/22 09:56, Patrick Palka wrote: AFAICT the only purpose of tsubst_copy_and_build's integral_constant_expression_p boolean parameter is to diagnose certain constructs that aren't allowed to appear in a C++98 integral constant expression context, specifically casts to a non-integral type (diagnosed from the *_CAST_EXPR case of tsubst_copy_and_build) or dependent names that resolve to a non-constant decl (diagnosed from the IDENTIFIER_NODE case of tsubst_copy_and_build). The parameter has no effect outside of C++98 AFAICT. But diagnosing such constructs should arguably be done by is_constant_expression after substitution, and doing it during substitution by way of an additional parameter complicates the API of this workhouse function for functionality that's specific to C++98. And it seems is_constant_expression already does a good job of diagnosing the aforementioned two constructs in C++98 mode, at least as far as our testsuite is concerned. So this patch gets rid of this parameter from tsubst_copy_and_build, tsubst_expr and tsubst_copy_and_build_call_args. The only interesting changes are those to potential_constant_expression_1 and the IDENTIFIER_NODE and *_CAST_EXPR cases of tsubst_copy_and_build; the rest are mechanical adjustments to these functions and their call sites. Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? OK. gcc/cp/ChangeLog: * constexpr.cc (potential_constant_expression_1) : Use cast_valid_in_integral_constant_expression_p instead of open coding it. * constraint.cc (tsubst_valid_expression_requirement): Adjust calls to tsubst_copy_and_build and tsubst_expr. (tsubst_constraint): Likewise. (satisfy_atom): Likewise. (diagnose_trait_expr): Likewise. * cp-tree.h (tsubst_copy_and_build): Remove i_c_e_p parameter. (tsubst_expr): Likewise. * init.cc (get_nsdmi): Adjust calls to tsubst_copy_and_build and tsubst_expr. * pt.cc (expand_integer_pack): Likewise. (instantiate_non_dependent_expr_internal): Likewise. (tsubst_friend_function): Likewise. (tsubst_attribute): Likewise. (instantiate_class_template): Likewise. (tsubst_template_arg): Likewise. (gen_elem_of_pack_expansion_instantiation): Likewise. (tsubst_fold_expr_init): Likewise. (tsubst_pack_expansion): Likewise. (tsubst_default_argument): Likewise. (tsubst_function_decl): Likewise. (tsubst_decl): Likewise. (tsubst_arg_types): Likewise. (tsubst_exception_specification): Likewise. (tsubst): Likewise. (tsubst_init): Likewise. (tsubst_copy): Likewise. (tsubst_omp_clause_decl): Likewise. (tsubst_omp_clauses): Likewise. (tsubst_copy_asm_operands): Likewise. (tsubst_omp_for_iterator): Likewise. (tsubst_expr): Likewise. Remove i_c_e_p parameter. (tsubst_omp_udr): Likewise. (tsubst_non_call_postfix_expression): Likewise. Remove i_c_e_p parameter. (tsubst_lambda_expr): Likewise. (tsubst_copy_and_build_call_args): Likewise. (tsubst_copy_and_build): Likewise. Remove i_c_e_p parameter. : Adjust call to finish_id_expression following removal of i_c_e_p. : Remove C++98-specific cast validity check guarded by i_c_e_p. (maybe_instantiate_noexcept): Adjust calls to tsubst_copy_and_build and tsubst_expr. (instantiate_body): Likewise. (instantiate_decl): Likewise. (tsubst_initializer_list): Likewise. (tsubst_enum): Likewise. gcc/objcp/ChangeLog: * objcp-lang.cc (objcp_tsubst_copy_and_build): Likewise. gcc/testsuite/ChangeLog: * g++.dg/template/crash55.C: Don't expect additional C++98-specific diagnostics. * g++.dg/template/ref3.C: Remove C++98-specific xfail. --- gcc/cp/constexpr.cc | 4 +- gcc/cp/constraint.cc| 14 +- gcc/cp/cp-tree.h| 6 +- gcc/cp/init.cc | 6 +- gcc/cp/pt.cc| 240 gcc/objcp/objcp-lang.cc | 3 +- gcc/testsuite/g++.dg/template/crash55.C | 3 +- gcc/testsuite/g++.dg/template/ref3.C| 3 +- 8 files changed, 93 insertions(+), 186 deletions(-) diff --git a/gcc/cp/constexpr.cc b/gcc/cp/constexpr.cc index 15b4f2c4a08..e665839f5b1 100644 --- a/gcc/cp/constexpr.cc +++ b/gcc/cp/constexpr.cc @@ -9460,9 +9460,7 @@ potential_constant_expression_1 (tree t, bool want_rval, bool strict, bool now, case STATIC_CAST_EXPR: case REINTERPRET_CAST_EXPR: case IMPLICIT_CONV_EXPR: - if (cxx_dialect < cxx11 - && !dependent_type_p (TREE_TYPE (t)) - && !INTEGRAL_OR_ENUMERATION_TYPE_P (TREE_TYPE (t))) + if (!cast_valid_in_integral_constant_expression_p (TREE_TYPE
Re: [PATCH 1/2] c++: remove function_p parm from tsubst_copy_and_build
On 11/10/22 09:56, Patrick Palka wrote:
The function_p parameter of tsubst_copy_and_build (added in r69316) is
inspected only in its IDENTIFIER_NODE case, where it controls whether we
diagnose unqualified name lookup failure for the given identifier. But
I think ever since r173965, we never substitute an IDENTIFIER_NODE with
function_p=true for which the lookup can possibly fail, and therefore
the flag is effectively unneeded.
Before that commit, we would incorrectly repeat unqualified lookup for
an ADL-enabled CALL_EXPR at instantiation time, which naturally could
fail and thus motivated the flag. Afterwards, we no longer substitute
an IDENTIFIER_NODE callee when koenig_p is true so the flag isn't needed
for its original purpose. What about when koenig_p=false? Apparently
we still may have an IDENTIFIER_NODE callee in this case, namely when
unqualified name lookup found a dependent local function declaration,
but repeating that lookup can't fail. (It also can't fail for USING_DECL
callees.)
So this patch removes this effectively unneeded parameter from
tsubst_copy_and_build. It also updates a outdated comment in the
CALL_EXPR case about when we may see an IDENTIFIER_NODE callee with
koenig_p=false.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
OK.
gcc/cp/ChangeLog:
* cp-lang.cc (objcp_tsubst_copy_and_build): Remove
function_p parameter.
* cp-objcp-common.h (objcp_tsubst_copy_and_build):
Likewise.
* cp-tree.h (tsubst_copy_and_build): Likewise.
* init.cc (get_nsdmi): Adjust calls to tsubst_copy_and_build.
* pt.cc (expand_integer_pack): Likewise.
(instantiate_non_dependent_expr_internal): Likewise.
(tsubst_function_decl): Likewise.
(tsubst_arg_types): Likewise.
(tsubst_exception_specification): Likewise.
(tsubst): Likewise.
(tsubst_copy_asm_operands): Likewise.
(tsubst_expr): Likewise.
(tsubst_non_call_postfix_expression): Likewise.
(tsubst_lambda_expr): Likewise.
(tsubst_copy_and_build_call_args): Likewise.
(tsubst_copy_and_build): Remove function_p parameter
and adjust function comment. Adjust recursive calls.
: Update outdated comment about when
we can see an IDENTIFIER_NODE callee with koenig_p=false.
(maybe_instantiate_noexcept): Adjust calls to
tsubst_copy_and_build.
gcc/objcp/ChangeLog:
* objcp-lang.cc (objcp_tsubst_copy_and_build): Remove
function_p parameter.
---
gcc/cp/cp-lang.cc| 3 +--
gcc/cp/cp-objcp-common.h | 3 +--
gcc/cp/cp-tree.h | 2 +-
gcc/cp/init.cc | 2 +-
gcc/cp/pt.cc | 46
gcc/objcp/objcp-lang.cc | 5 ++---
6 files changed, 19 insertions(+), 42 deletions(-)
diff --git a/gcc/cp/cp-lang.cc b/gcc/cp/cp-lang.cc
index c3cfde56cc6..a3f29eda0d6 100644
--- a/gcc/cp/cp-lang.cc
+++ b/gcc/cp/cp-lang.cc
@@ -116,8 +116,7 @@ tree
objcp_tsubst_copy_and_build (tree /*t*/,
tree /*args*/,
tsubst_flags_t /*complain*/,
-tree /*in_decl*/,
-bool /*function_p*/)
+tree /*in_decl*/)
{
return NULL_TREE;
}
diff --git a/gcc/cp/cp-objcp-common.h b/gcc/cp/cp-objcp-common.h
index 1a67f14d9b3..f4ba0c9e012 100644
--- a/gcc/cp/cp-objcp-common.h
+++ b/gcc/cp/cp-objcp-common.h
@@ -24,8 +24,7 @@ along with GCC; see the file COPYING3. If not see
/* In cp/objcp-common.c, cp/cp-lang.cc and objcp/objcp-lang.cc. */
extern tree cp_get_debug_type (const_tree);
-extern tree objcp_tsubst_copy_and_build (tree, tree, tsubst_flags_t,
-tree, bool);
+extern tree objcp_tsubst_copy_and_build (tree, tree, tsubst_flags_t, tree);
extern int cp_decl_dwarf_attribute (const_tree, int);
extern int cp_type_dwarf_attribute (const_tree, int);
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index d13bb3d4c0e..40fd2e1ebb9 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -7383,7 +7383,7 @@ extern tree tsubst_default_argument (tree,
int, tree, tree,
tsubst_flags_t);
extern tree tsubst (tree, tree, tsubst_flags_t, tree);
extern tree tsubst_copy_and_build (tree, tree, tsubst_flags_t,
-tree, bool = false, bool =
false);
+tree, bool = false);
extern tree tsubst_expr (tree, tree, tsubst_flags_t,
tree, bool);
extern tree tsubst_pack_expansion (tree, tree, tsubst_flags_t,
tree);
diff --git a/gcc/cp/init.cc b/gcc/cp/init.cc
index 3d5d3904944..fee49090de7 100644
--- a/gcc/cp/init.cc
+++ b/gcc/cp/init.cc
@@ -622,7 +622,7 @@ get_nsdmi (tree
Re: [PATCH] c++: Implement C++23 P2589R1 - - static operator[]
On 11/10/22 21:40, Jakub Jelinek wrote:
Hi!
As stage1 is very close, here is a patch that implements the static
operator[] paper.
One thing that doesn't work properly is the same problem as I've filed
yesterday for static operator() - PR107624 - that side-effects of
the postfix-expression on which the call or subscript operator are
applied are thrown away, I assume we have to add them into COMPOUND_EXPR
somewhere after we find out that the we've chosen a static member function
operator.
Indeed. The code in build_new_method_call for this case has the comment
/* In an expression of the form `a->f()' where `f' turns
out to be a static member function, `a' is
none-the-less evaluated. */
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk
provided the paper gets voted into C++23?
OK.
2022-11-11 Jakub Jelinek
gcc/c-family/
* c-cppbuiltin.cc (c_cpp_builtins): Bump C++23
__cpp_multidimensional_subscript macro value to 202211L.
gcc/cp/
* decl.cc (grok_op_properties): Implement C++23 P2589R1
- static operator[]. Handle operator[] similarly to operator()
- allow static member functions, but pedwarn on it for C++20 and
older. Unlike operator(), perform rest of checks on it though for
C++20.
* call.cc (add_operator_candidates): For operator[] with class
typed first parameter, pass that parameter as first_arg and
an adjusted arglist without that parameter.
gcc/testsuite/
* g++.dg/cpp23/subscript9.C: New test.
* g++.dg/cpp23/feat-cxx2b.C: Expect a newer
__cpp_multidimensional_subscript value.
* g++.old-deja/g++.bugs/900210_10.C: Don't expect an error
for C++23 or later.
--- gcc/c-family/c-cppbuiltin.cc.jj 2022-10-14 09:35:56.182990495 +0200
+++ gcc/c-family/c-cppbuiltin.cc2022-11-10 22:29:12.539832741 +0100
@@ -1075,7 +1075,7 @@ c_cpp_builtins (cpp_reader *pfile)
cpp_define (pfile, "__cpp_size_t_suffix=202011L");
cpp_define (pfile, "__cpp_if_consteval=202106L");
cpp_define (pfile, "__cpp_constexpr=202110L");
- cpp_define (pfile, "__cpp_multidimensional_subscript=202110L");
+ cpp_define (pfile, "__cpp_multidimensional_subscript=202211L");
cpp_define (pfile, "__cpp_named_character_escapes=202207L");
cpp_define (pfile, "__cpp_static_call_operator=202207L");
cpp_define (pfile, "__cpp_implicit_move=202207L");
--- gcc/cp/decl.cc.jj 2022-11-08 09:54:37.313400209 +0100
+++ gcc/cp/decl.cc 2022-11-10 21:26:06.891359343 +0100
@@ -15377,7 +15377,15 @@ grok_op_properties (tree decl, bool comp
an enumeration, or a reference to an enumeration. 13.4.0.6 */
if (! methodp || DECL_STATIC_FUNCTION_P (decl))
{
- if (operator_code == CALL_EXPR)
+ if (operator_code == TYPE_EXPR
+ || operator_code == COMPONENT_REF
+ || operator_code == NOP_EXPR)
+ {
+ error_at (loc, "%qD must be a non-static member function", decl);
+ return false;
+ }
+
+ if (operator_code == CALL_EXPR || operator_code == ARRAY_REF)
{
if (! DECL_STATIC_FUNCTION_P (decl))
{
@@ -15386,52 +15394,41 @@ grok_op_properties (tree decl, bool comp
}
if (cxx_dialect < cxx23
/* For lambdas we diagnose static lambda specifier elsewhere. */
- && ! LAMBDA_FUNCTION_P (decl)
+ && (operator_code == ARRAY_REF || ! LAMBDA_FUNCTION_P (decl))
/* For instantiations, we have diagnosed this already. */
&& ! DECL_USE_TEMPLATE (decl))
pedwarn (loc, OPT_Wc__23_extensions, "%qD may be a static member "
- "function only with %<-std=c++23%> or %<-std=gnu++23%>", decl);
- /* There are no further restrictions on the arguments to an
-overloaded "operator ()". */
- return true;
- }
- if (operator_code == TYPE_EXPR
- || operator_code == COMPONENT_REF
- || operator_code == ARRAY_REF
- || operator_code == NOP_EXPR)
- {
- error_at (loc, "%qD must be a non-static member function", decl);
- return false;
+"function only with %<-std=c++23%> or %<-std=gnu++23%>",
+decl);
}
-
- if (DECL_STATIC_FUNCTION_P (decl))
+ else if (DECL_STATIC_FUNCTION_P (decl))
{
error_at (loc, "%qD must be either a non-static member "
"function or a non-member function", decl);
return false;
}
-
- for (tree arg = argtypes; ; arg = TREE_CHAIN (arg))
- {
- if (!arg || arg == void_list_node)
- {
- if (complain)
- error_at(loc, "%qD must have an argument of class or "
-"enumerated type", decl);
- return false;
- }
+ else
[PATCH] ira: Remove duplicate `memset' over `full_costs' from `assign_hard_reg'
Remove duplicate clearing of `full_costs' made in `assign_hard_reg',
which has been there since the beginning, i.e. commit 058e97ecf33a
("IRA has been merged into trunk"),
.
gcc/
* ira-color.cc (assign_hard_reg): Remove duplicate `memset' over
`full_costs'.
---
Hi,
I find this fairly obvious, OK to apply?
Maciej
---
gcc/ira-color.cc |1 -
1 file changed, 1 deletion(-)
gcc-ira-assign-hard-reg-full-costs-dup.diff
Index: gcc/gcc/ira-color.cc
===
--- gcc.orig/gcc/ira-color.cc
+++ gcc/gcc/ira-color.cc
@@ -1961,7 +1961,6 @@ assign_hard_reg (ira_allocno_t a, bool r
aclass = ALLOCNO_CLASS (a);
class_size = ira_class_hard_regs_num[aclass];
best_hard_regno = -1;
- memset (full_costs, 0, sizeof (int) * class_size);
mem_cost = 0;
memset (costs, 0, sizeof (int) * class_size);
memset (full_costs, 0, sizeof (int) * class_size);
Re: [PATCH] c++: init_priority and SUPPORTS_INIT_PRIORITY [PR107638]
On 11/11/22 08:47, Patrick Palka wrote:
The commit r13-3706-gd0a492faa6478c for correcting the result of
__has_attribute(init_priority) causes a bootstrap failure on hppa64-hpux
because it assumes SUPPORTS_INIT_PRIORITY expands to a simple constant,
but on this target SUPPORTS_INIT_PRIORITY is defined as
#define SUPPORTS_INIT_PRIORITY (TARGET_GNU_LD ? 1 : 0)
(where TARGET_GNU_LD expands to something in terms of global_options)
which means we can't use this macro to statically exclude the entry
for init_priority when defining the cxx_attribute_table.
So instead of trying to exclude init_priority from the attribute table
for sake of __has_attribute, this patch just makes __has_attribute
handle init_priority specially.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk? Also sanity checked by artificially defining SUPPORTS_INIT_PRIORITY
to 0.
OK.
PR c++/107638
gcc/c-family/ChangeLog:
* c-lex.cc (c_common_has_attribute): Return 1 for init_priority
iff SUPPORTS_INIT_PRIORITY.
gcc/cp/ChangeLog:
* tree.cc (cxx_attribute_table): Don't conditionally exclude
the init_priority entry.
(handle_init_priority_attribute): Remove ATTRIBUTE_UNUSED.
Return error_mark_node if !SUPPORTS_INIT_PRIORITY.
---
gcc/c-family/c-lex.cc | 9 +
gcc/cp/tree.cc| 11 +++
2 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/gcc/c-family/c-lex.cc b/gcc/c-family/c-lex.cc
index 89c65aca28a..2fe562c7ccf 100644
--- a/gcc/c-family/c-lex.cc
+++ b/gcc/c-family/c-lex.cc
@@ -380,6 +380,15 @@ c_common_has_attribute (cpp_reader *pfile, bool std_syntax)
result = 201907;
else if (is_attribute_p ("assume", attr_name))
result = 202207;
+ else if (is_attribute_p ("init_priority", attr_name))
+ {
+ /* The (non-standard) init_priority attribute is always
+included in the attribute table, but we don't want to
+advertise the attribute unless the target actually
+supports init priorities. */
+ result = SUPPORTS_INIT_PRIORITY ? 1 : 0;
+ attr_name = NULL_TREE;
+ }
}
else
{
diff --git a/gcc/cp/tree.cc b/gcc/cp/tree.cc
index c30bbeb0839..2324c2269fc 100644
--- a/gcc/cp/tree.cc
+++ b/gcc/cp/tree.cc
@@ -5010,10 +5010,8 @@ const struct attribute_spec cxx_attribute_table[] =
{
/* { name, min_len, max_len, decl_req, type_req, fn_type_req,
affects_type_identity, handler, exclude } */
-#if SUPPORTS_INIT_PRIORITY
{ "init_priority", 1, 1, true, false, false, false,
handle_init_priority_attribute, NULL },
-#endif
{ "abi_tag", 1, -1, false, false, false, true,
handle_abi_tag_attribute, NULL },
{ NULL, 0, 0, false, false, false, false, NULL, NULL }
@@ -5041,13 +5039,19 @@ const struct attribute_spec std_attribute_table[] =
/* Handle an "init_priority" attribute; arguments as in
struct attribute_spec.handler. */
-ATTRIBUTE_UNUSED static tree
+static tree
handle_init_priority_attribute (tree* node,
tree name,
tree args,
int /*flags*/,
bool* no_add_attrs)
{
+ if (!SUPPORTS_INIT_PRIORITY)
+/* Treat init_priority as an unrecognized attribute (mirroring the
+ result of __has_attribute) if the target doesn't support init
+ priorities. */
+return error_mark_node;
+
tree initp_expr = TREE_VALUE (args);
tree decl = *node;
tree type = TREE_TYPE (decl);
@@ -5105,7 +5109,6 @@ handle_init_priority_attribute (tree* node,
pri);
}
- gcc_assert (SUPPORTS_INIT_PRIORITY);
SET_DECL_INIT_PRIORITY (decl, pri);
DECL_HAS_INIT_PRIORITY_P (decl) = 1;
return NULL_TREE;
Re: [PATCH] c++: Disable -Wdangling-reference when initing T
On 11/11/22 10:22, Marek Polacek wrote:
Non-const lvalue references can't bind to a temporary, so the
warning should not be emitted if we're initializing something of that
type. I'm not disabling the warning when the function itself returns
a non-const lvalue reference, that would regress at least
const int = std::any_cast(std::any());
in Wdangling-reference2.C where the any_cast returns an int&.
Unfortunately, this patch means we'll stop diagnosing
int& fn(int&& x) { return static_cast(x); }
void test ()
{
int = fn(4);
}
where there's a genuine dangling reference. OTOH, the patch
should suppress false positives with iterators, like:
auto = *candidates.begin ();
and arguably that's more important than detecting some relatively
obscure cases. It's probably not worth it making the warning more
complicated by, for instance, not warning when a fn returns 'int&'
but takes 'const int&' (because then it can't return its argument).
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
OK.
gcc/cp/ChangeLog:
* call.cc (maybe_warn_dangling_reference): Don't warn when initializing
a non-const lvalue reference.
gcc/testsuite/ChangeLog:
* g++.dg/cpp23/elision4.C: Remove dg-warning.
* g++.dg/warn/Wdangling-reference1.C: Turn dg-warning into dg-bogus.
* g++.dg/warn/Wdangling-reference7.C: New test.
---
gcc/cp/call.cc | 10 --
gcc/testsuite/g++.dg/cpp23/elision4.C| 4 ++--
gcc/testsuite/g++.dg/warn/Wdangling-reference1.C | 4 ++--
gcc/testsuite/g++.dg/warn/Wdangling-reference7.C | 16
4 files changed, 28 insertions(+), 6 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/warn/Wdangling-reference7.C
diff --git a/gcc/cp/call.cc b/gcc/cp/call.cc
index bd3b64a7e26..ef618d5c485 100644
--- a/gcc/cp/call.cc
+++ b/gcc/cp/call.cc
@@ -13679,8 +13679,14 @@ maybe_warn_dangling_reference (const_tree decl, tree
init)
{
if (!warn_dangling_reference)
return;
- if (!(TYPE_REF_OBJ_P (TREE_TYPE (decl))
- || std_pair_ref_ref_p (TREE_TYPE (decl
+ tree type = TREE_TYPE (decl);
+ /* Only warn if what we're initializing has type T&& or const T&, or
+ std::pair. (A non-const lvalue reference can't
+ bind to a temporary.) */
+ if (!((TYPE_REF_OBJ_P (type)
+&& (TYPE_REF_IS_RVALUE (type)
+|| CP_TYPE_CONST_P (TREE_TYPE (type
+ || std_pair_ref_ref_p (type)))
return;
/* Don't suppress the diagnostic just because the call comes from
a system header. If the DECL is not in a system header, or if
diff --git a/gcc/testsuite/g++.dg/cpp23/elision4.C
b/gcc/testsuite/g++.dg/cpp23/elision4.C
index d39053ad741..77dcffcdaad 100644
--- a/gcc/testsuite/g++.dg/cpp23/elision4.C
+++ b/gcc/testsuite/g++.dg/cpp23/elision4.C
@@ -34,6 +34,6 @@ T& temporary2(T&& x) { return static_cast(x); }
void
test ()
{
- int& r1 = temporary1 (42); // { dg-warning "dangling reference" }
- int& r2 = temporary2 (42); // { dg-warning "dangling reference" }
+ int& r1 = temporary1 (42);
+ int& r2 = temporary2 (42);
}
diff --git a/gcc/testsuite/g++.dg/warn/Wdangling-reference1.C
b/gcc/testsuite/g++.dg/warn/Wdangling-reference1.C
index 97c81ee716c..1718c28165e 100644
--- a/gcc/testsuite/g++.dg/warn/Wdangling-reference1.C
+++ b/gcc/testsuite/g++.dg/warn/Wdangling-reference1.C
@@ -139,6 +139,6 @@ struct Y {
// x1 = Y::operator int&& (_EXPR )
int&& x1 = Y(); // { dg-warning "dangling reference" }
int&& x2 = Y{}; // { dg-warning "dangling reference" }
-int& x3 = Y(); // { dg-warning "dangling reference" }
-int& x4 = Y{}; // { dg-warning "dangling reference" }
+int& x3 = Y(); // { dg-bogus "dangling reference" }
+int& x4 = Y{}; // { dg-bogus "dangling reference" }
const int& t1 = Y().foo(10); // { dg-warning "dangling reference" }
diff --git a/gcc/testsuite/g++.dg/warn/Wdangling-reference7.C
b/gcc/testsuite/g++.dg/warn/Wdangling-reference7.C
new file mode 100644
index 000..4b0de2d8670
--- /dev/null
+++ b/gcc/testsuite/g++.dg/warn/Wdangling-reference7.C
@@ -0,0 +1,16 @@
+// { dg-do compile { target c++11 } }
+// { dg-options "-Wdangling-reference" }
+
+int& ref(const int&);
+int&& rref(const int&);
+
+void
+g ()
+{
+ const int& r1 = ref (1); // { dg-warning "dangling reference" }
+ int& r2 = ref (2); // { dg-bogus "dangling reference" }
+ auto& r3 = ref (3); // { dg-bogus "dangling reference" }
+ int&& r4 = rref (4); // { dg-warning "dangling reference" }
+ auto&& r5 = rref (5); // { dg-warning "dangling reference" }
+ const int&& r6 = rref (6); // { dg-warning "dangling reference" }
+}
base-commit: 0a7b437ca71e2721e9bcf070762fc54ef7991aeb
Re: [PATCH] c++: Add testcase for DR 2604
On 11/14/22 01:43, Jakub Jelinek wrote:
Hi!
Working virtually out of Baker Island.
As the following testcase shows, I think we don't inherit template's
attributes into specializations.
Tested on x86_64-linux, ok for trunk?
OK.
2022-11-13 Jakub Jelinek
* g++.dg/DRs/dr2604.C: New test.
--- gcc/testsuite/g++.dg/DRs/dr2604.C.jj2022-11-13 23:39:45.725712300
-1200
+++ gcc/testsuite/g++.dg/DRs/dr2604.C 2022-11-13 23:39:38.712807673 -1200
@@ -0,0 +1,53 @@
+// DR 2604 - Attributes for an explicit specialization.
+// { dg-do compile { target c++11 } }
+// { dg-options "-Wunused-parameter" }
+
+template
+[[noreturn]] void
+foo ([[maybe_unused]] int i)
+{
+ for (;;);
+}
+
+template<>
+void
+foo (int i) // { dg-warning "unused parameter 'i'" }
+{
+}
+
+template
+void
+bar (int i)// { dg-warning "unused parameter 'i'" }
+{
+}
+
+template<>
+[[noreturn]] void
+bar ([[maybe_unused]] int i)
+{
+ for (;;);
+}
+
+[[noreturn]] void
+baz ()
+{
+ foo (0);
+}
+
+[[noreturn]] void
+qux ()
+{
+ foo (0);
+} // { dg-warning "'noreturn' function does return" }
+
+[[noreturn]] void
+garply ()
+{
+ bar (0);
+} // { dg-warning "'noreturn' function does return" }
+
+[[noreturn]] void
+corge ()
+{
+ bar (0);
+}
Jakub
Re: [PATCH] c++: P2448 - Relaxing some constexpr restrictions [PR106649]
On 11/9/22 10:53, Marek Polacek wrote:
This patch implements C++23 P2448, which lifts more restrictions on the
constexpr keyword. It's effectively going the way of being just a hint
(hello, inline!).
This gist is relatively simple: in C++23, a constexpr function's return
type/parameter type doesn't have to be a literal type; and you can have
a constexpr function for which no invocation satisfies the requirements
of a core constant expression. For example,
void f(int& i); // not constexpr
constexpr void g(int& i) {
f(i); // unconditionally calls a non-constexpr function
}
is now OK, even though there isn't an invocation of 'g' that would be
a constant expression. Maybe 'f' will be made constexpr soon, or maybe
this depends on the version of C++ used, and similar. The patch is
unfortunately not that trivial. The important bit is to use the new
require_potential_rvalue_constant_expression_fncheck in
maybe_save_constexpr_fundef (and where appropriate). It has a new flag
that says that we're checking the body of a constexpr function, and in
that case it's OK to find constructs that aren't a constant expression.
Since it's useful to be able to check for problematic constructs even
in C++23, this patch implements a new warning, -Winvalid-constexpr,
which is a pedwarn turned on by default in C++20 and earlier, and which
can be turned on in C++23 as well, in which case it's an ordinary warning.
This I implemented by using the new function constexpr_error, used in
p_c_e_1 and friends. (In some cases I believe fundef_p will be always
false (= hard error), but it made sense to me to be consistent and use
constexpr_error throughout p_c_e_1.)
While working on this I think I found a bug, see constexpr-nonlit15.C
and . This patch doesn't address that.
I also don't love that in C++23, if you don't use -Winvalid-constexpr,
and call a constexpr function that in fact isn't constexpr-ready yet,
sometimes all you get is an error saying "called in a constant expression"
like in constexpr-nonlit12.C. This could be remedied by some tweaks to
explain_invalid_constexpr_fn, I reckon (it gives up on !DECL_DEFAULTED_FN).
And also in maybe_save_constexpr_fn: if -Wno-invalid-constexpr,
"complain" should be false so we save the definition for
explain_invalid_constexpr_fn to refer to.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
PR c++/106649
gcc/c-family/ChangeLog:
* c-cppbuiltin.cc (c_cpp_builtins): Update value of __cpp_constexpr for
C++23.
* c-opts.cc (c_common_post_options): Set warn_invalid_constexpr
depending on cxx_dialect.
* c.opt (Winvalid-constexpr): New option.
gcc/cp/ChangeLog:
* constexpr.cc (constexpr_error): New function.
(is_valid_constexpr_fn): Use constexpr_error.
(maybe_save_constexpr_fundef): Call
require_potential_rvalue_constant_expression_fncheck rather than
require_potential_rvalue_constant_expression.
(non_const_var_error): Add a bool parameter. Use constexpr_error.
(inline_asm_in_constexpr_error): Likewise.
(cxx_eval_constant_expression): Adjust calls to non_const_var_error
and inline_asm_in_constexpr_error.
(potential_constant_expression_1): Add a bool parameter. Use
constexpr_error.
(require_potential_rvalue_constant_expression_fncheck): New function.
* cp-tree.h (require_potential_rvalue_constant_expression_fncheck):
Declare.
* method.cc (struct comp_info): Call
require_potential_rvalue_constant_expression_fncheck rather than
require_potential_rvalue_constant_expression.
gcc/ChangeLog:
* doc/gcc/gcc-command-options/option-summary.rst: Add
-Winvalid-constexpr.
* doc/gcc/gcc-command-options/options-controlling-c++-dialect.rst:
Document -Winvalid-constexpr.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/constexpr-ctor2.C: Expect an error in c++20_down only.
* g++.dg/cpp0x/constexpr-default-ctor.C: Likewise.
* g++.dg/cpp0x/constexpr-diag3.C: Likewise.
* g++.dg/cpp0x/constexpr-ex1.C: Likewise.
* g++.dg/cpp0x/constexpr-friend.C: Likewise.
* g++.dg/cpp0x/constexpr-generated1.C: Likewise.
* g++.dg/cpp0x/constexpr-ice5.C: Likewise.
* g++.dg/cpp0x/constexpr-ice6.C: Likewise.
* g++.dg/cpp0x/constexpr-memfn1.C: Likewise.
* g++.dg/cpp0x/constexpr-neg2.C: Likewise.
* g++.dg/cpp0x/constexpr-non-const-arg.C: Likewise.
* g++.dg/cpp0x/constexpr-reinterpret1.C: Likewise.
* g++.dg/cpp0x/pr65327.C: Likewise.
* g++.dg/cpp1y/constexpr-105050.C: Likewise.
* g++.dg/cpp1y/constexpr-89285-2.C: Likewise.
* g++.dg/cpp1y/constexpr-89285.C: Likewise.
* g++.dg/cpp1y/constexpr-89785-2.C: Likewise.
* g++.dg/cpp1y/constexpr-local4.C: Likewise.
* g++.dg/cpp1y/constexpr-neg1.C: Likewise.
*
Re: [PATCH v2 0/2] Basic support for the Ventana VT1 w/ instruction fusion
On Mon, 14 Nov 2022 at 23:47, Palmer Dabbelt wrote: > > [Trying to join the threads here.] > > On Mon, 14 Nov 2022 13:28:23 PST (-0800), philipp.toms...@vrull.eu wrote: > > Jeff, > > > > On Mon, 14 Nov 2022 at 22:23, Jeff Law wrote: > >> > >> > >> On 11/14/22 13:00, Palmer Dabbelt wrote: > >> > On Sun, 13 Nov 2022 12:48:22 PST (-0800), philipp.toms...@vrull.eu wrote: > >> >> > >> >> This series provides support for the Ventana VT1 (a 4-way superscalar > >> >> rv64gc_zba_zbb_zbc_zbs_zifenci_xventanacondops core) including support > >> >> for the supported instruction fusion patterns. > >> >> > >> >> This includes the addition of the fusion-aware scheduling > >> >> infrastructure for RISC-V and implements idiom recognition for the > >> >> fusion patterns supported by VT1. > >> >> > >> >> Note that we don't signal support for XVentanaCondOps at this point, > >> >> as the XVentanaCondOps support is in-flight separately. Changing the > >> >> defaults for VT1 can happen late in the cycle, so no need to link the > >> >> two different changesets. > >> >> > >> >> Changes in v2: > >> >> - Rebased and changed over to .rst-based documentation > >> >> - Updated to catch more fusion cases > >> >> - Signals support for Zifencei > >> >> > >> >> Philipp Tomsich (2): > >> >> RISC-V: Add basic support for the Ventana-VT1 core > >> >> RISC-V: Add instruction fusion (for ventana-vt1) > >> >> > >> >> gcc/config/riscv/riscv-cores.def | 3 + > >> >> gcc/config/riscv/riscv-opts.h | 2 +- > >> >> gcc/config/riscv/riscv.cc | 233 ++ > >> >> .../risc-v-options.rst| 5 +- > >> >> 4 files changed, 240 insertions(+), 3 deletions(-) > >> > > >> > I guess we never really properly talked about this on the GCC mailing > >> > lists, but IMO it's fine to start taking code for designs that have > >> > been announced under the assumption that if the hardware doesn't > >> > actually show up according to those timelines that it will be assumed > >> > to have never existed and thus be removed more quickly than usual. > >> Absolutely. I have zero interest in carrying around code for > >> nonexistent or dead variants. > >> > > >> > That said, I can't find anything describing that the VT-1 exists aside > >> > from these patches. Is there anything that describes this design and > >> > when it's expected to be available? > >> > >> What do you need? I can give some broad overview information on the > >> design, but it would likely just mirror what's already been mentioned in > >> these patches. > >> > >> > >> As far as schedules. I'm not sure what I can say. I'll check on that. > > I'm less worried about the "does this pipeline model match the HW" bits, > at least until the HW is publicly available then all we can do is rely > on the vendor (and even after the HW is public the vendor might be the > only one who cares enough to figure things out, nothing we can really do > upstream there). We've had some issues with nobody caring enough about > the C906 pipeline model to sort out whether some patches are a net win, > but if nobody (including the vendor) cares about the HW enough to > benchmark things then there's not much we can do. > > My bigger worry is getting roped in to supporting a bunch of hardware > that doesn't actually exist yet and may never make it outside some > vendor's lab. That can generally be a ton of work and filters > throughout GCC, even outside of the RISC-V backend. We've already got > enough chaos just trying to follow the ISA, chasing down issues related > to hardware that may not ever manifest is just going to lead to > craziness. > > So on my end the point of the schedule is to have something we can look > at and determine that the hardware is somehow defunct. The fairest way > we could come up with was to tie it to some sort of company announcement > of the hardware: obviously everyone knows their internal timelines, but > that's not fair to companies that don't employ someone with commit > access. Requirement some sort of public announcement means everyone has > the same rules to play by, IMO that's really important in RISC-V land as > there's so many vendors. > > >> It was never my intention to bypass any process/procedures here. So if I > >> did, my apologies. > > > > The controversial part is XVentanaCondOps (as it is a vendor-defined > > extension), so I'll certainly hold off on that until both you and > > Palmer are in agreement on how to proceed there. > > The pipeline models are essentially in the same spot. We've got a bit > of a precedent there for taking them just based on an announcement, but > there isn't one here. > > [and the other side of the thread] > > On Mon, 14 Nov 2022 13:14:35 PST (-0800), philipp.toms...@vrull.eu wrote: > > On Mon, 14 Nov 2022 at 21:58, Palmer Dabbelt wrote: > >> > >> On Mon, 14 Nov 2022 12:03:38 PST (-0800), philipp.toms...@vrull.eu wrote: > >> > On Mon, 14 Nov 2022 at
[committed] wwwdocs: gcc-13: Add release notes for more C23 features
diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html index 41d07e57..d033628b 100644 --- a/htdocs/gcc-13/changes.html +++ b/htdocs/gcc-13/changes.html @@ -112,9 +112,41 @@ a work-in-progress. https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3042.htm;>N3042, Introduce the nullptr constant + https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2963.htm;>N2963, + Enhanced Enumerations (fixed underlying types) + https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2975.pdf;>N2975, + Relax requirements for variadic parameter lists + https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3007.htm;>N3007, + Type inference for object definitions (auto) + https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3018.htm;>N3018, + The constexpr specifier for object definitions + https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3038.htm;>N3038, + Introduce storage-class specifiers for compound literals + typeof (previously supported as an extension) + and typeof_unqual + New + keywords alignas, alignof, bool, + false, static_assert, thread_local, + true + https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2764.pdf;>N2764, + The noreturn attribute Support for empty initializer braces + __STDC_VERSION_*_H__ header version macros + Removal of ATOMIC_VAR_INIT + unreachable macro + in stddef.h + Removal of trigraphs + Removal of unprototyped functions + printf and scanf format checking + with -Wformat for %wN + and %wfN format length modifiers + https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2836.pdf;>N2836, + Identifier Syntax using Unicode Standard Annex 31 + In addition to those C23 features, existing features adopted in + C23 have been adjusted to follow C23 requirements and are not diagnosed + with -std=c2x -Wpedantic. New warnings: -Wenum-int-mismatch warns about mismatches between an -- Joseph S. Myers jos...@codesourcery.com
[pushed] c++: only declare satisfied friends
Tested x86_64-pc-linux-gnu, applying to trunk.
-- >8 --
A friend declaration can only have constraints if it is defined. If
multiple instantiations of a class template define the same friend function
signature, it's an error, but that shouldn't happen if it's constrained to
only be declared in one instantiation.
Currently we don't mangle requirements, so the foos all mangle the same and
actually instantiating #1 will break, but for now we can test that they're
considered distinct.
gcc/cp/ChangeLog:
* pt.cc (tsubst_friend_function): Check satisfaction.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/concepts-friend11.C: New test.
---
gcc/cp/pt.cc | 3 +++
.../g++.dg/cpp2a/concepts-friend11.C | 21 +++
2 files changed, 24 insertions(+)
create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-friend11.C
diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 57917de321f..af96c5ca25f 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -11284,6 +11284,9 @@ tsubst_friend_function (tree decl, tree args)
not_tmpl = DECL_TEMPLATE_RESULT (new_friend);
new_friend_result_template_info = DECL_TEMPLATE_INFO (not_tmpl);
}
+ else if (!constraints_satisfied_p (new_friend))
+ /* Only define a constrained hidden friend when satisfied. */
+ return error_mark_node;
/* Inside pushdecl_namespace_level, we will push into the
current namespace. However, the friend function should go
diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-friend11.C
b/gcc/testsuite/g++.dg/cpp2a/concepts-friend11.C
new file mode 100644
index 000..0350ac3553e
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/concepts-friend11.C
@@ -0,0 +1,21 @@
+// CWG2596
+// { dg-do compile { target c++20 } }
+
+struct Base {};
+
+int foo(Base&) { return 0; } // #0
+
+template
+struct S : Base {
+ friend int foo(Base&) requires (N == 1) { return 1; } // #1
+ // friend int foo(Base&) requires (N == 2) { return 3; } // #2
+};
+
+S<1> s1;
+S<2> s2; // OK, no conflict between #1 and #0
+int x = foo(s1); // { dg-error "ambiguous" }
+int y = foo(s2); // OK, selects #0
+
+// ??? currently the foos all mangle the same, so comment out #2
+// and only test that #1 isn't multiply defined and overloads with #0.
+// The 2596 example does not include #0 and expects both calls to work.
base-commit: e7c12a921525b2aa27ca4814c42c63d61a6d954e
--
2.31.1
Re: [PATCH v2 0/2] Basic support for the Ventana VT1 w/ instruction fusion
[Trying to join the threads here.] On Mon, 14 Nov 2022 13:28:23 PST (-0800), philipp.toms...@vrull.eu wrote: Jeff, On Mon, 14 Nov 2022 at 22:23, Jeff Law wrote: On 11/14/22 13:00, Palmer Dabbelt wrote: > On Sun, 13 Nov 2022 12:48:22 PST (-0800), philipp.toms...@vrull.eu wrote: >> >> This series provides support for the Ventana VT1 (a 4-way superscalar >> rv64gc_zba_zbb_zbc_zbs_zifenci_xventanacondops core) including support >> for the supported instruction fusion patterns. >> >> This includes the addition of the fusion-aware scheduling >> infrastructure for RISC-V and implements idiom recognition for the >> fusion patterns supported by VT1. >> >> Note that we don't signal support for XVentanaCondOps at this point, >> as the XVentanaCondOps support is in-flight separately. Changing the >> defaults for VT1 can happen late in the cycle, so no need to link the >> two different changesets. >> >> Changes in v2: >> - Rebased and changed over to .rst-based documentation >> - Updated to catch more fusion cases >> - Signals support for Zifencei >> >> Philipp Tomsich (2): >> RISC-V: Add basic support for the Ventana-VT1 core >> RISC-V: Add instruction fusion (for ventana-vt1) >> >> gcc/config/riscv/riscv-cores.def | 3 + >> gcc/config/riscv/riscv-opts.h | 2 +- >> gcc/config/riscv/riscv.cc | 233 ++ >> .../risc-v-options.rst| 5 +- >> 4 files changed, 240 insertions(+), 3 deletions(-) > > I guess we never really properly talked about this on the GCC mailing > lists, but IMO it's fine to start taking code for designs that have > been announced under the assumption that if the hardware doesn't > actually show up according to those timelines that it will be assumed > to have never existed and thus be removed more quickly than usual. Absolutely. I have zero interest in carrying around code for nonexistent or dead variants. > > That said, I can't find anything describing that the VT-1 exists aside > from these patches. Is there anything that describes this design and > when it's expected to be available? What do you need? I can give some broad overview information on the design, but it would likely just mirror what's already been mentioned in these patches. As far as schedules. I'm not sure what I can say. I'll check on that. I'm less worried about the "does this pipeline model match the HW" bits, at least until the HW is publicly available then all we can do is rely on the vendor (and even after the HW is public the vendor might be the only one who cares enough to figure things out, nothing we can really do upstream there). We've had some issues with nobody caring enough about the C906 pipeline model to sort out whether some patches are a net win, but if nobody (including the vendor) cares about the HW enough to benchmark things then there's not much we can do. My bigger worry is getting roped in to supporting a bunch of hardware that doesn't actually exist yet and may never make it outside some vendor's lab. That can generally be a ton of work and filters throughout GCC, even outside of the RISC-V backend. We've already got enough chaos just trying to follow the ISA, chasing down issues related to hardware that may not ever manifest is just going to lead to craziness. So on my end the point of the schedule is to have something we can look at and determine that the hardware is somehow defunct. The fairest way we could come up with was to tie it to some sort of company announcement of the hardware: obviously everyone knows their internal timelines, but that's not fair to companies that don't employ someone with commit access. Requirement some sort of public announcement means everyone has the same rules to play by, IMO that's really important in RISC-V land as there's so many vendors. It was never my intention to bypass any process/procedures here. So if I did, my apologies. The controversial part is XVentanaCondOps (as it is a vendor-defined extension), so I'll certainly hold off on that until both you and Palmer are in agreement on how to proceed there. The pipeline models are essentially in the same spot. We've got a bit of a precedent there for taking them just based on an announcement, but there isn't one here. [and the other side of the thread] On Mon, 14 Nov 2022 13:14:35 PST (-0800), philipp.toms...@vrull.eu wrote: On Mon, 14 Nov 2022 at 21:58, Palmer Dabbelt wrote: On Mon, 14 Nov 2022 12:03:38 PST (-0800), philipp.toms...@vrull.eu wrote: > On Mon, 14 Nov 2022 at 21:00, Palmer Dabbelt wrote: >> >> On Sun, 13 Nov 2022 12:48:22 PST (-0800), philipp.toms...@vrull.eu wrote: >> > >> > This series provides support for the Ventana VT1 (a 4-way superscalar >> > rv64gc_zba_zbb_zbc_zbs_zifenci_xventanacondops core) including support >> > for the supported instruction fusion patterns. >> > >> > This includes the addition of the fusion-aware scheduling >> >
Re: Revert Sphinx documentation [Was: Issues with Sphinx]
On Mon, 14 Nov 2022, Jonathan Wakely wrote: > I formatted my new region/endregion pragmas on one line because that > seemed to be how it should be done for rSt, e.g. we had: > > ``#pragma GCC push_options`` ``#pragma GCC pop_options`` > > But I think the attached patch is more correct for how we document > pragmas in texinfo. > > OK for trunk? Looks good to my eyes. Thank you for caring for such details, Jonathan! Gerald
Re: Revert Sphinx documentation [Was: Issues with Sphinx]
On Mon, 14 Nov 2022, Jonathan Wakely wrote: > I formatted my new region/endregion pragmas on one line because that > seemed to be how it should be done for rSt, e.g. we had: > > ``#pragma GCC push_options`` ``#pragma GCC pop_options`` > > But I think the attached patch is more correct for how we document > pragmas in texinfo. > > OK for trunk? Looks good to my eyes. Thank you for caring for such details, Jonathan! Gerald
[committed] ira: Fix `create_insn_allocnos' `outer' parameter documentation
The parameter of `create_insn_allocnos' for any parent expression of `x'
has always been called `outer' rather than `parent', just as added by
commit d1bb282efbf9 ("Fix for "FAIL: tmpdir-gcc.dg-struct-layout-1/t028
c_compat_x_tst.o compile, (internal compiler error)""),
. Correct
inline documentation accordingly.
gcc/
* ira-build.cc (create_insn_allocnos): Fix documentation.
---
Hi,
Committed as obvious.
Maciej
---
gcc/ira-build.cc |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
gcc-ira-create-insn-allocnos-outer-doc.diff
Index: gcc/gcc/ira-build.cc
===
--- gcc.orig/gcc/ira-build.cc
+++ gcc/gcc/ira-build.cc
@@ -1832,7 +1832,7 @@ static basic_block curr_bb;
/* This recursive function creates allocnos corresponding to
pseudo-registers containing in X. True OUTPUT_P means that X is
- an lvalue. PARENT corresponds to the parent expression of X. */
+ an lvalue. OUTER corresponds to the parent expression of X. */
static void
create_insn_allocnos (rtx x, rtx outer, bool output_p)
{
Re: [PATCH 2/2]AArch64 Perform more late folding of reg moves and shifts which arrive after expand
(Sorry, immediately following up to myself for a second time recently.)
Richard Sandiford writes:
> Tamar Christina writes:
>>>
>>> The same thing ought to work for smov, so it would be good to do both.
>>> That would also make the split between the original and new patterns more
>>> obvious: left shift for the old pattern, right shift for the new pattern.
>>>
>>
>> Done, though because umov can do multilevel extensions I couldn't combine
>> them
>> Into a single pattern.
>
> Hmm, but the pattern is:
>
> (define_insn "*si3_insn2_uxtw"
> [(set (match_operand:GPI 0 "register_operand" "=r,r,r")
> (zero_extend:GPI (LSHIFTRT_ONLY:SI
> (match_operand:SI 1 "register_operand" "w,r,r")
> (match_operand:QI 2 "aarch64_reg_or_shift_imm_si" "Usl,Uss,r"]
>
> GPI is just SI or DI, so in the SI case we're zero-extending SI to SI,
> which isn't a valid operation. The original patch was just for extending
> to DI, which seems correct. The choice between printing %x for smov and
> %w for umov can then depend on the code.
My original comment quoted above was about using smov in the zero-extend
pattern. I.e. the original:
(define_insn "*si3_insn2_uxtw"
[(set (match_operand:DI 0 "register_operand" "=r,?r,r")
(zero_extend:DI (LSHIFTRT:SI
(match_operand:SI 1 "register_operand" "w,r,r")
(match_operand:QI 2 "aarch64_reg_or_shift_imm_si" "Usl,Uss,r"]
could instead be:
(define_insn "*si3_insn2_uxtw"
[(set (match_operand:DI 0 "register_operand" "=r,?r,r")
(zero_extend:DI (SHIFTRT:SI
(match_operand:SI 1 "register_operand" "w,r,r")
(match_operand:QI 2 "aarch64_reg_or_shift_imm_si" "Usl,Uss,r"]
with the pattern using "smov %w0, ..." for ashiftft case.
Thanks,
Richard
>
>>
>> Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
>>
>> Ok for master?
>>
>> Thanks,
>> Tamar
>>
>> gcc/ChangeLog:
>>
>> * config/aarch64/aarch64.md (*si3_insn_uxtw): Split SHIFT into
>> left and right ones.
>> (*aarch64_ashr_sisd_or_int_3, *si3_insn2_sxtw): Support
>> smov.
>> * config/aarch64/constraints.md (Usl): New.
>> * config/aarch64/iterators.md (LSHIFTRT_ONLY, ASHIFTRT_ONLY): New.
>>
>> gcc/testsuite/ChangeLog:
>>
>> * gcc.target/aarch64/shift-read_1.c: New test.
>> * gcc.target/aarch64/shift-read_2.c: New test.
>> * gcc.target/aarch64/shift-read_3.c: New test.
>>
>> --- inline copy of patch ---
>>
>> diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
>> index
>> c333fb1f72725992bb304c560f1245a242d5192d..2bc2684b82c35a44e0a2cea6e3aaf32d939f8cdf
>> 100644
>> --- a/gcc/config/aarch64/aarch64.md
>> +++ b/gcc/config/aarch64/aarch64.md
>> @@ -5370,20 +5370,42 @@ (define_split
>>
>> ;; Arithmetic right shift using SISD or Integer instruction
>> (define_insn "*aarch64_ashr_sisd_or_int_3"
>> - [(set (match_operand:GPI 0 "register_operand" "=r,r,w,,")
>> + [(set (match_operand:GPI 0 "register_operand" "=r,r,w,r,,")
>> (ashiftrt:GPI
>> - (match_operand:GPI 1 "register_operand" "r,r,w,w,w")
>> + (match_operand:GPI 1 "register_operand" "r,r,w,w,w,w")
>>(match_operand:QI 2 "aarch64_reg_or_shift_imm_di"
>> - "Us,r,Us,w,0")))]
>> + "Us,r,Us,Usl,w,0")))]
>>""
>> - "@
>> - asr\t%0, %1, %2
>> - asr\t%0, %1, %2
>> - sshr\t%0, %1, %2
>> - #
>> - #"
>> - [(set_attr "type"
>> "bfx,shift_reg,neon_shift_imm,neon_shift_reg,neon_shift_reg")
>> - (set_attr "arch" "*,*,simd,simd,simd")]
>> + {
>> +switch (which_alternative)
>> +{
>> + case 0:
>> +return "asr\t%0, %1, %2";
>> + case 1:
>> +return "asr\t%0, %1, %2";
>> + case 2:
>> +return "sshr\t%0, %1, %2";
>> + case 3:
>> +{
>> + int val = INTVAL (operands[2]);
>> + int size = 32 - val;
>> +
>> + if (size == 16)
>> +return "smov\\t%w0, %1.h[1]";
>> + if (size == 8)
>> +return "smov\\t%w0, %1.b[3]";
>
> This only looks right for SI, not DI. (But we can do something
> similar for DI.)
>
> Thanks,
> Richard
>
>> + gcc_unreachable ();
>> +}
>> + case 4:
>> +return "#";
>> + case 5:
>> +return "#";
>> + default:
>> +gcc_unreachable ();
>> +}
>> + }
>> + [(set_attr "type" "bfx,shift_reg,neon_shift_imm,neon_to_gp,
>> neon_shift_reg,neon_shift_reg")
>> + (set_attr "arch" "*,*,simd,simd,simd,simd")]
>> )
>>
>> (define_split
>> @@ -5493,7 +5515,7 @@ (define_insn "*rol3_insn"
>> ;; zero_extend version of shifts
>> (define_insn "*si3_insn_uxtw"
>>[(set (match_operand:DI 0 "register_operand" "=r,r")
>> -(zero_extend:DI (SHIFT_no_rotate:SI
>> +(zero_extend:DI (SHIFT_arith:SI
>> (match_operand:SI 1 "register_operand" "r,r")
>> (match_operand:QI 2 "aarch64_reg_or_shift_imm_si" "Uss,r"]
>>""
>> @@ -5528,6 +5550,68 @@ (define_insn "*rolsi3_insn_uxtw"
>>[(set_attr "type" "rotate_imm")]
>> )
>>
>>
Re: [PATCH] [range-ops] Implement sqrt.
On Sun, 13 Nov 2022, Jakub Jelinek via Gcc-patches wrote: > So, I wonder if we don't need to add a target hook where targets will be > able to provide upper bound on error for floating point functions for > different floating point modes and some way to signal unknown accuracy/can't > be trusted, in which case we would give up or return just the range for > VARYING. Note that the figures given in the glibc manual are purely empirical (largest errors observed for inputs in the glibc testsuite on a system that was then used to update the libm-test-ulps files); they don't constitute any kind of guarantee about either the current implementation or the API, nor are they formally verified, nor do they come from exhaustive testing (though worst cases from exhaustive testing for float may have been added to the glibc testsuite in some cases). (I think the only functions known to give huge errors for some inputs, outside of any IBM long double issues, are the Bessel functions and cpow functions. But even if other functions don't have huge errors, and some architecture-specific implementations might have issues, there are certainly some cases where errors can exceed the 9ulp threshold on what the libm tests will accept in libm-test-ulps files, which are thus considered glibc bugs. (That's 9ulp from the correctly rounded value, computed in ulp of that value. For IBM long double it's 16ulp instead, treating the format as having a fixed 106 bits of precision. Both figures are empirical ones chosen based on what bounds sufficed for most libm functions some years ago; ideally, with better implementations of some functions we could probably bring those numbers down.)) -- Joseph S. Myers jos...@codesourcery.com
Re: [PATCH 2/2]AArch64 Perform more late folding of reg moves and shifts which arrive after expand
Tamar Christina writes:
>>
>> The same thing ought to work for smov, so it would be good to do both.
>> That would also make the split between the original and new patterns more
>> obvious: left shift for the old pattern, right shift for the new pattern.
>>
>
> Done, though because umov can do multilevel extensions I couldn't combine them
> Into a single pattern.
Hmm, but the pattern is:
(define_insn "*si3_insn2_uxtw"
[(set (match_operand:GPI 0 "register_operand" "=r,r,r")
(zero_extend:GPI (LSHIFTRT_ONLY:SI
(match_operand:SI 1 "register_operand" "w,r,r")
(match_operand:QI 2 "aarch64_reg_or_shift_imm_si" "Usl,Uss,r"]
GPI is just SI or DI, so in the SI case we're zero-extending SI to SI,
which isn't a valid operation. The original patch was just for extending
to DI, which seems correct. The choice between printing %x for smov and
%w for umov can then depend on the code.
>
> Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
>
> Ok for master?
>
> Thanks,
> Tamar
>
> gcc/ChangeLog:
>
> * config/aarch64/aarch64.md (*si3_insn_uxtw): Split SHIFT into
> left and right ones.
> (*aarch64_ashr_sisd_or_int_3, *si3_insn2_sxtw): Support
> smov.
> * config/aarch64/constraints.md (Usl): New.
> * config/aarch64/iterators.md (LSHIFTRT_ONLY, ASHIFTRT_ONLY): New.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/aarch64/shift-read_1.c: New test.
> * gcc.target/aarch64/shift-read_2.c: New test.
> * gcc.target/aarch64/shift-read_3.c: New test.
>
> --- inline copy of patch ---
>
> diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
> index
> c333fb1f72725992bb304c560f1245a242d5192d..2bc2684b82c35a44e0a2cea6e3aaf32d939f8cdf
> 100644
> --- a/gcc/config/aarch64/aarch64.md
> +++ b/gcc/config/aarch64/aarch64.md
> @@ -5370,20 +5370,42 @@ (define_split
>
> ;; Arithmetic right shift using SISD or Integer instruction
> (define_insn "*aarch64_ashr_sisd_or_int_3"
> - [(set (match_operand:GPI 0 "register_operand" "=r,r,w,,")
> + [(set (match_operand:GPI 0 "register_operand" "=r,r,w,r,,")
> (ashiftrt:GPI
> - (match_operand:GPI 1 "register_operand" "r,r,w,w,w")
> + (match_operand:GPI 1 "register_operand" "r,r,w,w,w,w")
> (match_operand:QI 2 "aarch64_reg_or_shift_imm_di"
> -"Us,r,Us,w,0")))]
> +"Us,r,Us,Usl,w,0")))]
>""
> - "@
> - asr\t%0, %1, %2
> - asr\t%0, %1, %2
> - sshr\t%0, %1, %2
> - #
> - #"
> - [(set_attr "type"
> "bfx,shift_reg,neon_shift_imm,neon_shift_reg,neon_shift_reg")
> - (set_attr "arch" "*,*,simd,simd,simd")]
> + {
> +switch (which_alternative)
> +{
> + case 0:
> + return "asr\t%0, %1, %2";
> + case 1:
> + return "asr\t%0, %1, %2";
> + case 2:
> + return "sshr\t%0, %1, %2";
> + case 3:
> + {
> + int val = INTVAL (operands[2]);
> + int size = 32 - val;
> +
> + if (size == 16)
> + return "smov\\t%w0, %1.h[1]";
> + if (size == 8)
> + return "smov\\t%w0, %1.b[3]";
This only looks right for SI, not DI. (But we can do something
similar for DI.)
Thanks,
Richard
> + gcc_unreachable ();
> + }
> + case 4:
> + return "#";
> + case 5:
> + return "#";
> + default:
> + gcc_unreachable ();
> +}
> + }
> + [(set_attr "type" "bfx,shift_reg,neon_shift_imm,neon_to_gp,
> neon_shift_reg,neon_shift_reg")
> + (set_attr "arch" "*,*,simd,simd,simd,simd")]
> )
>
> (define_split
> @@ -5493,7 +5515,7 @@ (define_insn "*rol3_insn"
> ;; zero_extend version of shifts
> (define_insn "*si3_insn_uxtw"
>[(set (match_operand:DI 0 "register_operand" "=r,r")
> - (zero_extend:DI (SHIFT_no_rotate:SI
> + (zero_extend:DI (SHIFT_arith:SI
>(match_operand:SI 1 "register_operand" "r,r")
>(match_operand:QI 2 "aarch64_reg_or_shift_imm_si" "Uss,r"]
>""
> @@ -5528,6 +5550,68 @@ (define_insn "*rolsi3_insn_uxtw"
>[(set_attr "type" "rotate_imm")]
> )
>
> +(define_insn "*si3_insn2_sxtw"
> + [(set (match_operand:GPI 0 "register_operand" "=r,r,r")
> + (sign_extend:GPI (ASHIFTRT_ONLY:SI
> + (match_operand:SI 1 "register_operand" "w,r,r")
> + (match_operand:QI 2 "aarch64_reg_or_shift_imm_si" "Usl,Uss,r"]
> + "mode != DImode || satisfies_constraint_Usl (operands[2])"
> + {
> +switch (which_alternative)
> +{
> + case 0:
> + {
> + int val = INTVAL (operands[2]);
> + int size = 32 - val;
> +
> + if (size == 16)
> + return "smov\\t%0, %1.h[1]";
> + if (size == 8)
> + return "smov\\t%0, %1.b[3]";
> + gcc_unreachable ();
> + }
> + case 1:
> + return "\\t%0, %1, %2";
> + case 2:
> + return "\\t%0, %1, %2";
> + default:
> + gcc_unreachable ();
> + }
> + }
> + [(set_attr "type" "neon_to_gp,bfx,shift_reg")]
> +)
> +
> +(define_insn "*si3_insn2_uxtw"
> +
[Bug target/107692] [13 regression] r13-3950-g071e428c24ee8c breaks many test cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107692 --- Comment #1 from Andrew Pinski --- Some of these testcases might need -mno-unroll-only-small-loops now.
Re: [PATCH 7/7] riscv: Add support for str(n)cmp inline expansion
On Mon, Nov 14, 2022 at 8:28 PM Jeff Law wrote: > > On 11/13/22 16:05, Christoph Muellner wrote: > > From: Christoph Müllner > > > > This patch implements expansions for the cmpstrsi and the cmpstrnsi > > builtins using Zbb instructions (if available). > > This allows to inline calls to strcmp() and strncmp(). > > > > The expansion basically emits a peeled comparison sequence (i.e. a peeled > > comparison loop) which compares XLEN bits per step if possible. > > > > The emitted sequence can be controlled, by setting the maximum number > > of compared bytes (-mstring-compare-inline-limit). > > > > gcc/ChangeLog: > > > > * config/riscv/riscv-protos.h (riscv_expand_strn_compare): New > > prototype. > > * config/riscv/riscv-string.cc (GEN_EMIT_HELPER3): New helper > > macros. > > (GEN_EMIT_HELPER2): New helper macros. > > (expand_strncmp_zbb_sequence): New function. > > (riscv_emit_str_compare_zbb): New function. > > (riscv_expand_strn_compare): New function. > > * config/riscv/riscv.md (cmpstrnsi): Invoke expansion functions > > for strn_compare. > > (cmpstrsi): Invoke expansion functions for strn_compare. > > * config/riscv/riscv.opt: Add new parameter > > '-mstring-compare-inline-limit'. > > Presumably the hybrid inline + out of line approach is to capture the > fact that most strings compare unequal early, then punt out to the > library if they don't follow that model? It looks like we're structured > for that case by peeling iterations rather than having a fully inlined > approach. Just want to confirm... > Yes, this was inspired by gcc/config/rs6000/rs6000-string.cc (e.g. expand_strncmp_gpr_sequence). The current implementation emits an unrolled loop to process up to N characters. For longer strings, we do a handover to libc to process the remainder there. The hand-over implies a call overhead and, of course, a well-optimized str(n)cmp implementation would be beneficial (once we have the information in user space for ifuncs). We can take this further, but then the following questions pop up: * how much data processing per loop iteration? * what about unaligned strings? Happy to get suggestions/opinions for improvement. > I was a bit worried about the "readahead" problem that arises when > reading more than a byte and a NUL is found in the first string. If > you're not careful, the readahead of the second string could fault. But > it looks like we avoid that by requiring word alignment on both strings. > Yes, aligned strings are not affected by the readahead. I wonder if we should add dynamic tests in case the compiler cannot derive XLEN-alignment so we capture more cases (e.g. character-arrays have guaranteed alignment 1, but are allocated with a higher actual alignment on the stack). > > + > > +/* Emit a string comparison sequence using Zbb instruction. > > + > > + OPERANDS[0] is the target (result). > > + OPERANDS[1] is the first source. > > + OPERANDS[2] is the second source. > > + If NO_LENGTH is zero, then: > > + OPERANDS[3] is the length. > > + OPERANDS[4] is the alignment in bytes. > > + If NO_LENGTH is nonzero, then: > > + OPERANDS[3] is the alignment in bytes. > > Ugh. I guess it's inevitable unless we want to drop the array and pass > each element individually (in which case we'd pass a NULL_RTX in the > case we don't have a length argument). > I will split the array into individual rtx arguments as suggested. > I'd like to give others a chance to chime in here. Everything looks > sensible here, but I may have missed something. So give the other > maintainers a couple days to chime in before committing. > > > Jeff > >
[Bug fortran/107680] ICE in arith_power, at fortran/arith.cc:989 and :1006
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107680 --- Comment #2 from anlauf at gcc dot gnu.org --- We could prohibit the simplification of ** like in the following: diff --git a/gcc/fortran/arith.cc b/gcc/fortran/arith.cc index fc9224ebc5c..540b8e2b945 100644 --- a/gcc/fortran/arith.cc +++ b/gcc/fortran/arith.cc @@ -845,6 +845,12 @@ arith_power (gfc_expr *op1, gfc_expr *op2, gfc_expr **resultp) if (!gfc_numeric_ts (>ts) || !gfc_numeric_ts (>ts)) return ARITH_INVALID_TYPE; + /* The result type shall accomodate the result of the simplification. */ + if (op1->ts.type == BT_INTEGER && op2->ts.type != BT_INTEGER) +return ARITH_NOT_REDUCED; + if (op1->ts.type == BT_REAL && op2->ts.type == BT_COMPLEX) +return ARITH_NOT_REDUCED; + rc = ARITH_OK; result = gfc_get_constant_expr (op1->ts.type, op1->ts.kind, >where);
Re: [PATCH v2 0/2] Basic support for the Ventana VT1 w/ instruction fusion
Jeff, On Mon, 14 Nov 2022 at 22:23, Jeff Law wrote: > > > On 11/14/22 13:00, Palmer Dabbelt wrote: > > On Sun, 13 Nov 2022 12:48:22 PST (-0800), philipp.toms...@vrull.eu wrote: > >> > >> This series provides support for the Ventana VT1 (a 4-way superscalar > >> rv64gc_zba_zbb_zbc_zbs_zifenci_xventanacondops core) including support > >> for the supported instruction fusion patterns. > >> > >> This includes the addition of the fusion-aware scheduling > >> infrastructure for RISC-V and implements idiom recognition for the > >> fusion patterns supported by VT1. > >> > >> Note that we don't signal support for XVentanaCondOps at this point, > >> as the XVentanaCondOps support is in-flight separately. Changing the > >> defaults for VT1 can happen late in the cycle, so no need to link the > >> two different changesets. > >> > >> Changes in v2: > >> - Rebased and changed over to .rst-based documentation > >> - Updated to catch more fusion cases > >> - Signals support for Zifencei > >> > >> Philipp Tomsich (2): > >> RISC-V: Add basic support for the Ventana-VT1 core > >> RISC-V: Add instruction fusion (for ventana-vt1) > >> > >> gcc/config/riscv/riscv-cores.def | 3 + > >> gcc/config/riscv/riscv-opts.h | 2 +- > >> gcc/config/riscv/riscv.cc | 233 ++ > >> .../risc-v-options.rst| 5 +- > >> 4 files changed, 240 insertions(+), 3 deletions(-) > > > > I guess we never really properly talked about this on the GCC mailing > > lists, but IMO it's fine to start taking code for designs that have > > been announced under the assumption that if the hardware doesn't > > actually show up according to those timelines that it will be assumed > > to have never existed and thus be removed more quickly than usual. > Absolutely. I have zero interest in carrying around code for > nonexistent or dead variants. > > > > That said, I can't find anything describing that the VT-1 exists aside > > from these patches. Is there anything that describes this design and > > when it's expected to be available? > > What do you need? I can give some broad overview information on the > design, but it would likely just mirror what's already been mentioned in > these patches. > > > As far as schedules. I'm not sure what I can say. I'll check on that. > > > It was never my intention to bypass any process/procedures here. So if I > did, my apologies. The controversial part is XVentanaCondOps (as it is a vendor-defined extension), so I'll certainly hold off on that until both you and Palmer are in agreement on how to proceed there. Thanks, Philipp. > jeff >
Re: [PATCH 1/5] c: Set the locus of the function result decl
On Sun, 13 Nov 2022, Bernhard Reutner-Fischer via Gcc-patches wrote: > Bootstrapped and regtested on x86_86-unknown-linux with no regressions. > Ok for trunk? > > Cc: Joseph Myers > --- > gcc/c/ChangeLog: > > * c-decl.cc (start_function): Set the result decl source > location to the location of the typespec. OK. -- Joseph S. Myers jos...@codesourcery.com
Re: [PATCH v2 0/2] Basic support for the Ventana VT1 w/ instruction fusion
On 11/14/22 13:00, Palmer Dabbelt wrote: On Sun, 13 Nov 2022 12:48:22 PST (-0800), philipp.toms...@vrull.eu wrote: This series provides support for the Ventana VT1 (a 4-way superscalar rv64gc_zba_zbb_zbc_zbs_zifenci_xventanacondops core) including support for the supported instruction fusion patterns. This includes the addition of the fusion-aware scheduling infrastructure for RISC-V and implements idiom recognition for the fusion patterns supported by VT1. Note that we don't signal support for XVentanaCondOps at this point, as the XVentanaCondOps support is in-flight separately. Changing the defaults for VT1 can happen late in the cycle, so no need to link the two different changesets. Changes in v2: - Rebased and changed over to .rst-based documentation - Updated to catch more fusion cases - Signals support for Zifencei Philipp Tomsich (2): RISC-V: Add basic support for the Ventana-VT1 core RISC-V: Add instruction fusion (for ventana-vt1) gcc/config/riscv/riscv-cores.def | 3 + gcc/config/riscv/riscv-opts.h | 2 +- gcc/config/riscv/riscv.cc | 233 ++ .../risc-v-options.rst | 5 +- 4 files changed, 240 insertions(+), 3 deletions(-) I guess we never really properly talked about this on the GCC mailing lists, but IMO it's fine to start taking code for designs that have been announced under the assumption that if the hardware doesn't actually show up according to those timelines that it will be assumed to have never existed and thus be removed more quickly than usual. Absolutely. I have zero interest in carrying around code for nonexistent or dead variants. That said, I can't find anything describing that the VT-1 exists aside from these patches. Is there anything that describes this design and when it's expected to be available? What do you need? I can give some broad overview information on the design, but it would likely just mirror what's already been mentioned in these patches. As far as schedules. I'm not sure what I can say. I'll check on that. It was never my intention to bypass any process/procedures here. So if I did, my apologies. jeff
[Bug target/107692] New: [13 regression] r13-3950-g071e428c24ee8c breaks many test cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107692 Bug ID: 107692 Summary: [13 regression] r13-3950-g071e428c24ee8c breaks many test cases Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:071e428c24ee8c1ed062597a093708bba29509c9, r13-3950-g071e428c24ee8c This commit broke a big pile of test cases on powerpc64. Here is the list for LE: FAIL: c-c++-common/tsan/thread_leak2.c -O2 output pattern test FAIL: c-c++-common/tsan/thread_leak2.c -O2 output pattern test FAIL: gcc.dg/pr94600-3.c scan-rtl-dump-times final "\\(mem/v" 1 FAIL: gcc.dg/pr94600-3.c scan-rtl-dump-times final "\\(set \\(mem/v" 1 FAIL: gcc.dg/pr94600-5.c scan-rtl-dump-times final "\\(mem/v" 1 FAIL: gcc.dg/pr94600-5.c scan-rtl-dump-times final "\\(set \\(mem/v" 1 FAIL: gcc.dg/pr94600-7.c scan-rtl-dump-times final "\\(mem/v" 1 FAIL: gcc.dg/pr94600-7.c scan-rtl-dump-times final "\\(set \\(mem/v" 1 FAIL: gcc.target/powerpc/ctz-3.c scan-assembler-times vctzw 2 FAIL: gcc.target/powerpc/div-vectorize-1.c scan-assembler-times \\mvdivsd\\M 1 FAIL: gcc.target/powerpc/div-vectorize-1.c scan-assembler-times \\mvdivsw\\M 1 FAIL: gcc.target/powerpc/div-vectorize-1.c scan-assembler-times \\mvdivud\\M 1 FAIL: gcc.target/powerpc/div-vectorize-1.c scan-assembler-times \\mvdivuw\\M 1 FAIL: gcc.target/powerpc/dive-vectorize-1.c scan-assembler-times \\mvdivesw\\M 1 FAIL: gcc.target/powerpc/dive-vectorize-1.c scan-assembler-times \\mvdiveuw\\M 1 FAIL: gcc.target/powerpc/dive-vectorize-2.c scan-assembler-times \\mvdivesd\\M 1 FAIL: gcc.target/powerpc/dive-vectorize-2.c scan-assembler-times \\mvdiveud\\M 1 FAIL: gcc.target/powerpc/doloop-2.c scan-assembler-not (?n)\\maddi .*,.*,-1$ FAIL: gcc.target/powerpc/loop_align.c scan-assembler .p2align 5 FAIL: gcc.target/powerpc/mod-vectorize.c scan-assembler-times \\mvmodsd\\M 1 FAIL: gcc.target/powerpc/mod-vectorize.c scan-assembler-times \\mvmodsw\\M 1 FAIL: gcc.target/powerpc/mod-vectorize.c scan-assembler-times \\mvmodud\\M 1 FAIL: gcc.target/powerpc/mod-vectorize.c scan-assembler-times \\mvmoduw\\M 1 FAIL: gcc.target/powerpc/mul-vectorize-1.c scan-assembler-times \\mvmuluwm\\M 2 FAIL: gcc.target/powerpc/mul-vectorize-2.c scan-assembler-times \\mvmulld\\M 2 FAIL: gcc.target/powerpc/mul-vectorize-3.c scan-assembler-times \\mvmulhsw\\M 1 FAIL: gcc.target/powerpc/mul-vectorize-3.c scan-assembler-times \\mvmulhuw\\M 1 FAIL: gcc.target/powerpc/mul-vectorize-4.c scan-assembler-times \\mvmulhsd\\M 1 FAIL: gcc.target/powerpc/mul-vectorize-4.c scan-assembler-times \\mvmulhud\\M 1 FAIL: gcc.target/powerpc/p10-bifs-vectorize-1.c scan-assembler-times \\mvcfuged\\M 1 FAIL: gcc.target/powerpc/p10-bifs-vectorize-1.c scan-assembler-times \\mvclzdm\\M 1 FAIL: gcc.target/powerpc/p10-bifs-vectorize-1.c scan-assembler-times \\mvctzdm\\M 1 FAIL: gcc.target/powerpc/p10-bifs-vectorize-1.c scan-assembler-times \\mvpdepd\\M 1 FAIL: gcc.target/powerpc/p10-bifs-vectorize-1.c scan-assembler-times \\mvpextd\\M 1 FAIL: gcc.target/powerpc/p8vector-vectorize-1.c scan-assembler-times [\t ]vaddudm[\t ] 2 FAIL: gcc.target/powerpc/p8vector-vectorize-1.c scan-assembler-times [\t ]vcmpequd[\t ] 2 FAIL: gcc.target/powerpc/p8vector-vectorize-1.c scan-assembler-times [\t ]vcmpgtsd[\t ] 1 FAIL: gcc.target/powerpc/p8vector-vectorize-1.c scan-assembler-times [\t ]vcmpgtud[\t ] 1 FAIL: gcc.target/powerpc/p8vector-vectorize-1.c scan-assembler-times [\t ]vmaxsd[\t ] 2 FAIL: gcc.target/powerpc/p8vector-vectorize-1.c scan-assembler-times [\t ]vmaxud[\t ] 1 FAIL: gcc.target/powerpc/p8vector-vectorize-1.c scan-assembler-times [\t ]vminsd[\t ] 1 FAIL: gcc.target/powerpc/p8vector-vectorize-1.c scan-assembler-times [\t ]vminud[\t ] 1 FAIL: gcc.target/powerpc/p8vector-vectorize-1.c scan-assembler-times [\t ]vsld[\t ] 2 FAIL: gcc.target/powerpc/p8vector-vectorize-1.c scan-assembler-times [\t ]vsrad[\t ] 1 FAIL: gcc.target/powerpc/p8vector-vectorize-1.c scan-assembler-times [\t ]vsrd[\t ] 1 FAIL: gcc.target/powerpc/p8vector-vectorize-1.c scan-assembler-times [\t ]vsubudm[\t ] 3 FAIL: gcc.target/powerpc/p8vector-vectorize-4.c scan-assembler-times vclzw 2 FAIL: gcc.target/powerpc/p8vector-vectorize-4.c scan-assembler-times vpopcntw 2 FAIL: gcc.target/powerpc/p8vector-vectorize-5.c scan-assembler-times xxleqv 1 FAIL: gcc.target/powerpc/p8vector-vectorize-5.c scan-assembler-times xxlnand 2 FAIL: gcc.target/powerpc/p8vector-vectorize-5.c scan-assembler-times xxlorc 2 FAIL: gcc.target/powerpc/p9-vec-length-epil-1.c scan-assembler-times \\mlxvx?\\M 20 FAIL: gcc.target/powerpc/p9-vec-length-epil-1.c scan-assembler-times \\mstxvx?\\M 10 FAIL: gcc.target/powerpc/p9-vec-length-epil-2.c scan-assembler-times \\mlxvx?\\M 20 FAIL: gcc.target/powerpc/p9-vec-length-epil-2.c scan-assembler-times \\mstxvx?\\M 10
Re: [PATCH v2 0/2] Basic support for the Ventana VT1 w/ instruction fusion
On Mon, 14 Nov 2022 at 21:58, Palmer Dabbelt wrote:
>
> On Mon, 14 Nov 2022 12:03:38 PST (-0800), philipp.toms...@vrull.eu wrote:
> > On Mon, 14 Nov 2022 at 21:00, Palmer Dabbelt wrote:
> >>
> >> On Sun, 13 Nov 2022 12:48:22 PST (-0800), philipp.toms...@vrull.eu wrote:
> >> >
> >> > This series provides support for the Ventana VT1 (a 4-way superscalar
> >> > rv64gc_zba_zbb_zbc_zbs_zifenci_xventanacondops core) including support
> >> > for the supported instruction fusion patterns.
> >> >
> >> > This includes the addition of the fusion-aware scheduling
> >> > infrastructure for RISC-V and implements idiom recognition for the
> >> > fusion patterns supported by VT1.
> >> >
> >> > Note that we don't signal support for XVentanaCondOps at this point,
> >> > as the XVentanaCondOps support is in-flight separately. Changing the
> >> > defaults for VT1 can happen late in the cycle, so no need to link the
> >> > two different changesets.
> >> >
> >> > Changes in v2:
> >> > - Rebased and changed over to .rst-based documentation
> >> > - Updated to catch more fusion cases
> >> > - Signals support for Zifencei
> >> >
> >> > Philipp Tomsich (2):
> >> > RISC-V: Add basic support for the Ventana-VT1 core
> >> > RISC-V: Add instruction fusion (for ventana-vt1)
> >> >
> >> > gcc/config/riscv/riscv-cores.def | 3 +
> >> > gcc/config/riscv/riscv-opts.h | 2 +-
> >> > gcc/config/riscv/riscv.cc | 233 ++
> >> > .../risc-v-options.rst| 5 +-
> >> > 4 files changed, 240 insertions(+), 3 deletions(-)
> >>
> >> I guess we never really properly talked about this on the GCC mailing
> >> lists, but IMO it's fine to start taking code for designs that have been
> >> announced under the assumption that if the hardware doesn't actually
> >> show up according to those timelines that it will be assumed to have
> >> never existed and thus be removed more quickly than usual.
> >>
> >> That said, I can't find anything describing that the VT-1 exists aside
> >> from these patches. Is there anything that describes this design and
> >> when it's expected to be available?
> >
> > I have to defer to Jeff on this one.
>
> Looks like you already committed it, though:
>
> 991cfe5b30c ("RISC-V: Add instruction fusion (for ventana-vt1)")
> b4fca4fc70d ("RISC-V: Add basic support for the Ventana-VT1 core")
>
> We talked about this multiple times and I thought you were on board with
> the proposed "hardware needs to be announced" changes, did I
> misunderstand that?
Sorry — I had assumed that the "basic support" changes were agreed
upon between you and Jeff, given that Jeff had given the OK.
My position is still the same as discussed at LPC that "hardware needs
to be announced".
Thanks,
Philipp.
Re: [PATCH 6/7] riscv: Add support for strlen inline expansion
On Mon, Nov 14, 2022 at 7:17 PM Jeff Law wrote:
>
> On 11/13/22 16:05, Christoph Muellner wrote:
> > From: Christoph Müllner
> >
> > This patch implements the expansion of the strlen builtin
> > using Zbb instructions (if available) for aligned strings
> > using the following sequence:
> >
> >li a3,-1
> >addia4,a0,8
> > .L2: ld a5,0(a0)
> >addia0,a0,8
> >orc.b a5,a5
> >beq a5,a3,6 <.L2>
> >not a5,a5
> >ctz a5,a5
> >srlia5,a5,0x3
> >add a0,a0,a5
> >sub a0,a0,a4
> >
> > This allows to inline calls to strlen(), with optimized code for
> > determining the length of a string.
> >
> > gcc/ChangeLog:
> >
> > * config/riscv/riscv-protos.h (riscv_expand_strlen): New
> > prototype.
> > * config/riscv/riscv-string.cc (riscv_emit_unlikely_jump): New
> > function.
> > (GEN_EMIT_HELPER2): New helper macro.
> > (GEN_EMIT_HELPER3): New helper macro.
> > (do_load_from_addr): New helper function.
> > (riscv_expand_strlen_zbb): New function.
> > (riscv_expand_strlen): New function.
> > * config/riscv/riscv.md (strlen): Invoke expansion
> > functions for strlen.
> >
> >
> > +extern bool riscv_expand_strlen (rtx[]);
>
> Consider adding the number of elements in the RTX array here. Martin S's
> work from a little while ago will make use of it to try and catch
> over-reads and over-writes if the data is available.
>
Done.
>
>
> >
> > /* Information about one CPU we know about. */
> > struct riscv_cpu_info {
> > diff --git a/gcc/config/riscv/riscv-string.cc
> b/gcc/config/riscv/riscv-string.cc
> > index 1137df475be..bf96522b608 100644
> > --- a/gcc/config/riscv/riscv-string.cc
> > +++ b/gcc/config/riscv/riscv-string.cc
> > @@ -38,6 +38,81 @@
> > #include "predict.h"
> > #include "optabs.h"
> >
> > +/* Emit unlikely jump instruction. */
> > +
> > +static rtx_insn *
> > +riscv_emit_unlikely_jump (rtx insn)
> > +{
> > + rtx_insn *jump = emit_jump_insn (insn);
> > + add_reg_br_prob_note (jump, profile_probability::very_unlikely ());
> > + return jump;
> > +}
>
> I was a bit surprised that we didn't have this as a generic routine.
> Consider adding this to emit-rtl.cc along with its companion
> emit_likely_jump. Not a requirement to move forward, but it seems like
> the right thing to do.
>
I created both and called them emit_[un]likely_jump_insn() to match
emit_jump_insn().
>
>
>
>
> > +
> > +/* Emit proper instruction depending on type of dest. */
>
> s/type/mode/
>
Done.
>
>
>
> > +
> > +/* Emit proper instruction depending on type of dest. */
>
> s/type/mode/
>
Done.
>
>
> You probably want to undefine GEN_EMIT_HELPER once you're done when
> them. That's become fairly standard practice for these kind of helper
> macros.
>
Done.
>
> OK with the nits fixed. Your call on whether or not to move the
> implementation of emit_likely_jump and emit_unlikely_jump into emit-rtl.cc.
>
I've made all the requested and suggested changes and rested again.
Thanks!
>
>
> Jeff
>
>
>
[Bug preprocessor/107691] [10/11/12/13 Regression] libcpp configure fails on empty expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107691 --- Comment #4 from rep.dot.nop at gmail dot com --- The problem was encountered with configure --enable-valgrind-annotations with valgrind not installed.
Re: [PATCH v2 0/2] Basic support for the Ventana VT1 w/ instruction fusion
On Mon, 14 Nov 2022 12:03:38 PST (-0800), philipp.toms...@vrull.eu wrote:
On Mon, 14 Nov 2022 at 21:00, Palmer Dabbelt wrote:
On Sun, 13 Nov 2022 12:48:22 PST (-0800), philipp.toms...@vrull.eu wrote:
>
> This series provides support for the Ventana VT1 (a 4-way superscalar
> rv64gc_zba_zbb_zbc_zbs_zifenci_xventanacondops core) including support
> for the supported instruction fusion patterns.
>
> This includes the addition of the fusion-aware scheduling
> infrastructure for RISC-V and implements idiom recognition for the
> fusion patterns supported by VT1.
>
> Note that we don't signal support for XVentanaCondOps at this point,
> as the XVentanaCondOps support is in-flight separately. Changing the
> defaults for VT1 can happen late in the cycle, so no need to link the
> two different changesets.
>
> Changes in v2:
> - Rebased and changed over to .rst-based documentation
> - Updated to catch more fusion cases
> - Signals support for Zifencei
>
> Philipp Tomsich (2):
> RISC-V: Add basic support for the Ventana-VT1 core
> RISC-V: Add instruction fusion (for ventana-vt1)
>
> gcc/config/riscv/riscv-cores.def | 3 +
> gcc/config/riscv/riscv-opts.h | 2 +-
> gcc/config/riscv/riscv.cc | 233 ++
> .../risc-v-options.rst| 5 +-
> 4 files changed, 240 insertions(+), 3 deletions(-)
I guess we never really properly talked about this on the GCC mailing
lists, but IMO it's fine to start taking code for designs that have been
announced under the assumption that if the hardware doesn't actually
show up according to those timelines that it will be assumed to have
never existed and thus be removed more quickly than usual.
That said, I can't find anything describing that the VT-1 exists aside
from these patches. Is there anything that describes this design and
when it's expected to be available?
I have to defer to Jeff on this one.
Looks like you already committed it, though:
991cfe5b30c ("RISC-V: Add instruction fusion (for ventana-vt1)")
b4fca4fc70d ("RISC-V: Add basic support for the Ventana-VT1 core")
We talked about this multiple times and I thought you were on board with
the proposed "hardware needs to be announced" changes, did I
misunderstand that?
[Bug preprocessor/107691] [10/11/12/13 Regression] libcpp configure fails on empty expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107691 --- Comment #3 from Andrew Pinski --- have_valgrind_h is never set anywhere. Adding before that code in configure.ac: dnl # This check AC_REQUIREs various stuff, so it *must not* be inside dnl # an if statement. This was the source of very frustrating bugs dnl # in converting to autoconf 2.5x! AC_CHECK_HEADER(valgrind.h, have_valgrind_h=yes, have_valgrind_h=no) Should fix the issue I think.
[Bug fortran/107576] [10/11/12/13 Regression] ICE in gfc_conv_procedure_call, at fortran/trans-expr.cc:6193
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107576 --- Comment #8 from anlauf at gcc dot gnu.org --- (In reply to G. Steinmetz from comment #7) > $ gfortran -c z3.f90 > z3.f90:2:10: > > 2 |call s(null()) > | 1 > Error: MOLD argument to NULL required at (1) I think that error message might be fine. It seems to be related to 16.9.144 NULL() and table 16.5: Characteristics of the result of NULL ( ). This is why z3c/z2i give no error: there is an explicit interface, and 16.9.144(5) explains how this is resolved. With gfortran -fallow-argument-mismatch, we have the bad situation that the user explicitly wants to leave the space of standard conformance, and we are entering extension space, with all its problems...
[Bug preprocessor/107691] [10/11/12/13 Regression] libcpp configure fails on empty expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107691 Andreas Schwab changed: What|Removed |Added Summary|[10/11/12/13 Regression]|[10/11/12/13 Regression] |libcpp configure fails on |libcpp configure fails on |bashism |empty expansion --- Comment #2 from Andreas Schwab --- That's 100% POSIX conforming, it's just $have_valgrind_h etc. expanding to nothing (only gcc/configure has the necessary checks).
Re: [PATCH v2] c, analyzer: support named constants in analyzer [PR106302]
On Fri, Nov 11, 2022 at 10:23:10PM -0500, David Malcolm wrote:
> Changes since v1: ported the doc changes from texinfo to sphinx
>
> Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
>
> Are the C frontend parts OK for trunk? (I can self-approve the
> analyzer parts)
Sorry for the delay.
> The patch adds an interface for frontends to call into the analyzer as
> the translation unit finishes. The analyzer can then call back into the
> frontend to ask about the values of the named constants it cares about
> whilst the frontend's data structures are still around.
>
> The patch implements this for the C frontend, which looks up the names
> by looking for named CONST_DECLs (which handles enum values). Failing
> that, it attempts to look up the values of macros but only the simplest
> cases are supported (a non-traditional macro with a single CPP_NUMBER
> token). It does this by building a buffer containing the macro
> definition and rerunning a lexer on it.
>
> The analyzer gracefully handles the cases where named values aren't
> found (such as anything more complicated than described above).
>
> The patch ports the analyzer to use this mechanism for "O_RDONLY",
> "O_WRONLY", and "O_ACCMODE". I have successfully tested my socket patch
> to also use this for "SOCK_STREAM" and "SOCK_DGRAM", so the technique
> seems to work.
So this works well for code like
enum __socket_type {
SOCK_STREAM = 1,
#define SOCK_STREAM SOCK_STREAM
};
?
> diff --git a/gcc/c/c-parser.cc b/gcc/c/c-parser.cc
> index d70697b1d63..efe19fbe70b 100644
> --- a/gcc/c/c-parser.cc
> +++ b/gcc/c/c-parser.cc
> @@ -72,6 +72,8 @@ along with GCC; see the file COPYING3. If not see
> #include "memmodel.h"
> #include "c-family/known-headers.h"
> #include "bitmap.h"
> +#include "analyzer/analyzer-language.h"
> +#include "toplev.h"
>
> /* We need to walk over decls with incomplete struct/union/enum types
> after parsing the whole translation unit.
> @@ -1662,6 +1664,87 @@ static bool c_parser_objc_diagnose_bad_element_prefix
>(c_parser *, struct c_declspecs *);
> static location_t c_parser_parse_rtl_body (c_parser *, char *);
>
> +#if ENABLE_ANALYZER
> +
> +namespace ana {
> +
> +/* Concrete implementation of ana::translation_unit for the C frontend. */
> +
> +class c_translation_unit : public translation_unit
> +{
> +public:
> + /* Implementation of translation_unit::lookup_constant_by_id for use by the
> + analyzer to look up named constants in the user's source code. */
> + tree lookup_constant_by_id (tree id) const final override
> + {
> +/* Consider decls. */
> +if (tree decl = lookup_name (id))
> + if (TREE_CODE (decl) == CONST_DECL)
> + if (tree value = DECL_INITIAL (decl))
> + if (TREE_CODE (value) == INTEGER_CST)
> + return value;
> +
> +/* Consider macros. */
> +cpp_hashnode *hashnode = C_CPP_HASHNODE (id);
> +if (cpp_macro_p (hashnode))
> + if (tree value = consider_macro (hashnode->value.macro))
> + return value;
> +
> +return NULL_TREE;
> + }
> +
> +private:
> + /* Attempt to get an INTEGER_CST from MACRO.
> + Only handle the simplest cases: where MACRO's definition is a single
> + token containing a number, by lexing the number again.
> + This will handle e.g.
> + #define NAME 42
> + and other bases but not negative numbers, parentheses or e.g.
> + #define NAME 1 << 7
> + as doing so would require a parser. */
> + tree consider_macro (cpp_macro *macro) const
> + {
> +if (macro->paramc > 0)
> + return NULL_TREE;
> +if (macro->kind == cmk_traditional)
Do you really want to handle cmk_assert? I'd say you want
if (macro->kind != cmk_macro)
> + return NULL_TREE;
> +if (macro->count != 1)
> + return NULL_TREE;
> +const cpp_token = macro->exp.tokens[0];
> +if (tok.type != CPP_NUMBER)
> + return NULL_TREE;
> +
> +cpp_reader *old_parse_in = parse_in;
> +parse_in = cpp_create_reader (c_dialect_cxx () ? CLK_GNUCXX: CLK_GNUC89,
> + ident_hash, line_table);
Why not always CLK_GNUC89 since we're in the C FE?
> +
> +pretty_printer pp;
> +pp_string (, (const char *)tok.val.str.text);
A space after ')'.
> +pp_newline ();
> +cpp_push_buffer (parse_in,
> + (const unsigned char *)pp_formatted_text (),
Likewise.
> + strlen (pp_formatted_text ()),
> + 0);
> +
> +tree value;
> +location_t loc;
> +unsigned char cpp_flags;
> +c_lex_with_flags (, , _flags, 0);
> +
> +cpp_destroy (parse_in);
> +parse_in = old_parse_in;
> +
> +if (value && TREE_CODE (value) == INTEGER_CST)
> + return value;
> +
> +return NULL_TREE;
> + }
> +};
> +
> +} // namespace ana
> +
> +#endif /* #if ENABLE_ANALYZER */
> +
> /* Parse a translation unit (C90 6.7, C99 6.9, C11 6.9).
>
> translation-unit:
> @@ -1722,6 +1805,14 @@
[Bug preprocessor/107691] [10/11/12/13 Regression] libcpp configure fails on bashism
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107691 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to fail||7.1.0 Known to work|7.0 |6.1.0 Summary|libcpp configure fails on |[10/11/12/13 Regression] |bashism |libcpp configure fails on ||bashism Ever confirmed|0 |1 Target Milestone|--- |10.5 Keywords||build Last reconfirmed||2022-11-14 --- Comment #1 from Andrew Pinski --- GCC 7 had the patch. r7-912-gceb17928e5d1d5 introduced the bad code into configure.ac. Confirmed.
[Bug fortran/107576] [10/11/12/13 Regression] ICE in gfc_conv_procedure_call, at fortran/trans-expr.cc:6193
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107576 --- Comment #7 from G. Steinmetz --- Yes, call s(z) is valid in z1, but is necessary to trigger the ICE somehow with -std=legacy and null(). Yes, 15.4.2.2(3) was it, explicit interface of the callee with all the characteristics of that procedure(subr/func) and dummies. Two things are mixed here.. The following is e.g. handled correctly, with a different error, but rejected without an explicit interface: $ cat z3.f90 program p call s(null()) end $ cat z3c.f90 program p call s(null()) contains subroutine s(x) integer, pointer :: x end end $ cat z3i.f90 program p interface subroutine s(x) integer, pointer :: x end end interface call s(null()) end $ gfortran -c z3c.f90 $ gfortran -c z3i.f90 $ gfortran -c z3.f90 z3.f90:2:10: 2 |call s(null()) | 1 Error: MOLD argument to NULL required at (1)
[Bug preprocessor/107691] New: libcpp configure fails on bashism
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107691 Bug ID: 107691 Summary: libcpp configure fails on bashism Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: rep.dot.nop at gmail dot com Target Milestone: --- New debian install, /bin/sh points to dash /scratch/src/gcc-13.orig/libcpp/configure: line 7847: test: =: unary operator expected line 7847 reads if (test $have_valgrind_h = no \ Why those superfluous braces? Removing them fixes the shell script.
[Bug fortran/107681] [13 Regression] ICE in gfc_type_is_extensible, at fortran/resolve.cc:9018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107681
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |13.0
Ever confirmed|0 |1
CC||anlauf at gcc dot gnu.org
Last reconfirmed||2022-11-14
Priority|P3 |P4
Status|UNCONFIRMED |NEW
--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.
NULL pointer dereference, e.g. fixed by:
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 5ff1cd070ac..24e5aa03556 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -12967,6 +12967,7 @@ resolve_fl_var_and_proc (gfc_symbol *sym, int mp_flag)
&& sym->ts.u.derived
&& !sym->attr.select_type_temporary
&& !UNLIMITED_POLY (sym)
+ && CLASS_DATA (sym)->ts.u.derived
&& !gfc_type_is_extensible (CLASS_DATA (sym)->ts.u.derived))
{
gfc_error ("Type %qs of CLASS variable %qs at %L is not extensible",
[Bug rtl-optimization/107690] [12/13 Regression] vectorization fails for std::ranges::transform due to IR changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107690 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.3 Summary|Regression in |[12/13 Regression] |ranges::transform |vectorization fails for |vectorization |std::ranges::transform due ||to IR changes Last reconfirmed||2022-11-14 Blocks||53947 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Keywords||missed-optimization, ||needs-bisection --- Comment #2 from Andrew Pinski --- In GCC 12 before the vectorizer we have: [local count: 114863530]: _4 = v_2(D) + 64; _5 = _2(D)->_M_elems; if (_4 != _5) goto ; [89.30%] else goto ; [10.70%] [local count: 102576004]: [local count: 958878296]: # __first1_24 = PHI <_11(6), _M_elems(5)> # __first2_25 = PHI <_12(6), _5(5)> _7 = MEM[(const int &)__first1_24]; _9 = *__first2_25; _10 = _7 + _9; *__first1_24 = _10; _11 = __first1_24 + 4; _12 = __first2_25 + 4; _15 = _4 != _12; _18 = [(void *) + 64B] != _11; _16 = _15 & _18; if (_16 != 0) goto ; [89.30%] else goto ; [10.70%] [local count: 856302294]: goto ; [100.00%] But with GCC 11 we had: [local count: 114863530]: _2 = [(void *)v_3(D) + 64B]; _5 = _3(D)->_M_elems; goto ; [100.00%] [local count: 114863532]: = u; return ; [local count: 899822495]: [local count: 1014686026]: # __first1_22 = PHI <_11(6), _M_elems(2)> # __first2_23 = PHI <_12(6), _5(2)> # ivtmp_24 = PHI _7 = MEM[(const int &)__first1_22]; _9 = *__first2_23; _10 = _7 + _9; *__first1_22 = _10; _11 = __first1_22 + 4; _12 = __first2_23 + 4; ivtmp_13 = ivtmp_24 - 1; if (ivtmp_13 != 0) goto ; [93.84%] else goto ; [6.16%] There is a missing optimization before the vectorizer which is causing the vectorizer not to know how many iterations the loop is for. I am tries tracking down which passes the IR changes to make things worse but I didn't do a good at doing that. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
[PATCH][committed]middle-end: Fix addsub patch removing return statements
Hi All,
My recent patch had return statements in the match.pd expressions
which were recently outlawed.. Unfornately I didn't rebase this
patch before committing so this broke the build.
I've just reflowed the conditions to avoid the returns.
Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
Committed to fix the build, but think it's still trivial as it just reflows the
code.
Thanks,
Tamar
gcc/ChangeLog:
* match.pd: Remove returns.
--- inline copy of patch --
diff --git a/gcc/match.pd b/gcc/match.pd
index
4701578c96451d56e5235d5e0bc5d0a0378c1435..946dcd1b301c8fbcfe36e534651ff0b183b324ef
100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -7984,51 +7984,51 @@ and,
{
/* Build a vector of integers from the tree mask. */
vec_perm_builder builder;
- if (!tree_to_vec_perm_builder (, @2))
- return NULL_TREE;
-
- /* Create a vec_perm_indices for the integer vector. */
- poly_uint64 nelts = TYPE_VECTOR_SUBPARTS (type);
- vec_perm_indices sel (builder, 2, nelts);
}
- (if (sel.series_p (0, 2, 0, 2))
+ (if (tree_to_vec_perm_builder (, @2))
(with
{
+ /* Create a vec_perm_indices for the integer vector. */
+ poly_uint64 nelts = TYPE_VECTOR_SUBPARTS (type);
+ vec_perm_indices sel (builder, 2, nelts);
machine_mode vec_mode = TYPE_MODE (type);
machine_mode wide_mode;
- if (!GET_MODE_WIDER_MODE (vec_mode).exists (_mode)
- || !VECTOR_MODE_P (wide_mode)
- || (GET_MODE_UNIT_BITSIZE (vec_mode) * 2
- != GET_MODE_UNIT_BITSIZE (wide_mode)))
-return NULL_TREE;
-
- tree stype = lang_hooks.types.type_for_mode (GET_MODE_INNER (wide_mode),
- TYPE_UNSIGNED (type));
- if (TYPE_MODE (stype) == BLKmode)
-return NULL_TREE;
- tree ntype = build_vector_type_for_mode (stype, wide_mode);
- if (!VECTOR_TYPE_P (ntype))
-return NULL_TREE;
-
- /* The format has to be a non-extended ieee format. */
- const struct real_format *fmt_old = FLOAT_MODE_FORMAT (vec_mode);
- const struct real_format *fmt_new = FLOAT_MODE_FORMAT (wide_mode);
- if (fmt_old == NULL || fmt_new == NULL)
-return NULL_TREE;
-
- /* If the target doesn't support v1xx vectors, try using scalar mode xx
- instead. */
- if (known_eq (GET_MODE_NUNITS (wide_mode), 1)
- && !target_supports_op_p (ntype, NEGATE_EXPR, optab_vector))
-ntype = stype;
}
- (if (fmt_new->signbit_rw
-== fmt_old->signbit_rw + GET_MODE_UNIT_BITSIZE (vec_mode)
- && fmt_new->signbit_rw == fmt_new->signbit_ro
- && targetm.can_change_mode_class (TYPE_MODE (ntype), TYPE_MODE
(type), ALL_REGS)
- && ((optimize_vectors_before_lowering_p () && VECTOR_TYPE_P (ntype))
- || target_supports_op_p (ntype, NEGATE_EXPR, optab_vector)))
- (plus (view_convert:type (negate (view_convert:ntype @1))) @0)))
+ (if (sel.series_p (0, 2, 0, 2)
+ && GET_MODE_WIDER_MODE (vec_mode).exists (_mode)
+ && VECTOR_MODE_P (wide_mode)
+ && (GET_MODE_UNIT_BITSIZE (vec_mode) * 2
+ == GET_MODE_UNIT_BITSIZE (wide_mode)))
+ (with
+{
+ tree stype
+= lang_hooks.types.type_for_mode (GET_MODE_INNER (wide_mode),
+ TYPE_UNSIGNED (type));
+ tree ntype = build_vector_type_for_mode (stype, wide_mode);
+
+ /* The format has to be a non-extended ieee format. */
+ const struct real_format *fmt_old = FLOAT_MODE_FORMAT (vec_mode);
+ const struct real_format *fmt_new = FLOAT_MODE_FORMAT (wide_mode);
+}
+(if (TYPE_MODE (stype) != BLKmode
+ && VECTOR_TYPE_P (ntype)
+ && fmt_old != NULL
+ && fmt_new != NULL)
+ (with
+ {
+/* If the target doesn't support v1xx vectors, try using
+ scalar mode xx instead. */
+ if (known_eq (GET_MODE_NUNITS (wide_mode), 1)
+ && !target_supports_op_p (ntype, NEGATE_EXPR, optab_vector))
+ ntype = stype;
+ }
+ (if (fmt_new->signbit_rw
+ == fmt_old->signbit_rw + GET_MODE_UNIT_BITSIZE (vec_mode)
+ && fmt_new->signbit_rw == fmt_new->signbit_ro
+ && targetm.can_change_mode_class (TYPE_MODE (ntype), TYPE_MODE
(type), ALL_REGS)
+ && ((optimize_vectors_before_lowering_p () && VECTOR_TYPE_P
(ntype))
+ || target_supports_op_p (ntype, NEGATE_EXPR, optab_vector)))
+ (plus (view_convert:type (negate (view_convert:ntype @1)))
@0)))
(simplify
(vec_perm @0 @1 VECTOR_CST@2)
--
diff --git a/gcc/match.pd b/gcc/match.pd
index
4701578c96451d56e5235d5e0bc5d0a0378c1435..946dcd1b301c8fbcfe36e534651ff0b183b324ef
100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -7984,51
[Bug c/96054] RFE: __attribute__((fatal))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96054 --- Comment #2 from H. Peter Anvin --- I agree, my naming was very poor. Perhaps "panic" or "abort" would work; those are classic names in software use for this. Another case of a function that could be so attributed would be the function typically called __assert_failed(). It is probably worth noting that all the ones I can think of should be noreturn functions. I don't know if that is truly inherent, but personally I cannot think of a case where it would not be.
Re: [PATCH v2 0/2] Basic support for the Ventana VT1 w/ instruction fusion
On Mon, 14 Nov 2022 at 21:00, Palmer Dabbelt wrote: > > On Sun, 13 Nov 2022 12:48:22 PST (-0800), philipp.toms...@vrull.eu wrote: > > > > This series provides support for the Ventana VT1 (a 4-way superscalar > > rv64gc_zba_zbb_zbc_zbs_zifenci_xventanacondops core) including support > > for the supported instruction fusion patterns. > > > > This includes the addition of the fusion-aware scheduling > > infrastructure for RISC-V and implements idiom recognition for the > > fusion patterns supported by VT1. > > > > Note that we don't signal support for XVentanaCondOps at this point, > > as the XVentanaCondOps support is in-flight separately. Changing the > > defaults for VT1 can happen late in the cycle, so no need to link the > > two different changesets. > > > > Changes in v2: > > - Rebased and changed over to .rst-based documentation > > - Updated to catch more fusion cases > > - Signals support for Zifencei > > > > Philipp Tomsich (2): > > RISC-V: Add basic support for the Ventana-VT1 core > > RISC-V: Add instruction fusion (for ventana-vt1) > > > > gcc/config/riscv/riscv-cores.def | 3 + > > gcc/config/riscv/riscv-opts.h | 2 +- > > gcc/config/riscv/riscv.cc | 233 ++ > > .../risc-v-options.rst| 5 +- > > 4 files changed, 240 insertions(+), 3 deletions(-) > > I guess we never really properly talked about this on the GCC mailing > lists, but IMO it's fine to start taking code for designs that have been > announced under the assumption that if the hardware doesn't actually > show up according to those timelines that it will be assumed to have > never existed and thus be removed more quickly than usual. > > That said, I can't find anything describing that the VT-1 exists aside > from these patches. Is there anything that describes this design and > when it's expected to be available? I have to defer to Jeff on this one. Philipp.
Re: [PATCH v2 0/2] Basic support for the Ventana VT1 w/ instruction fusion
On Sun, 13 Nov 2022 12:48:22 PST (-0800), philipp.toms...@vrull.eu wrote: This series provides support for the Ventana VT1 (a 4-way superscalar rv64gc_zba_zbb_zbc_zbs_zifenci_xventanacondops core) including support for the supported instruction fusion patterns. This includes the addition of the fusion-aware scheduling infrastructure for RISC-V and implements idiom recognition for the fusion patterns supported by VT1. Note that we don't signal support for XVentanaCondOps at this point, as the XVentanaCondOps support is in-flight separately. Changing the defaults for VT1 can happen late in the cycle, so no need to link the two different changesets. Changes in v2: - Rebased and changed over to .rst-based documentation - Updated to catch more fusion cases - Signals support for Zifencei Philipp Tomsich (2): RISC-V: Add basic support for the Ventana-VT1 core RISC-V: Add instruction fusion (for ventana-vt1) gcc/config/riscv/riscv-cores.def | 3 + gcc/config/riscv/riscv-opts.h | 2 +- gcc/config/riscv/riscv.cc | 233 ++ .../risc-v-options.rst| 5 +- 4 files changed, 240 insertions(+), 3 deletions(-) I guess we never really properly talked about this on the GCC mailing lists, but IMO it's fine to start taking code for designs that have been announced under the assumption that if the hardware doesn't actually show up according to those timelines that it will be assumed to have never existed and thus be removed more quickly than usual. That said, I can't find anything describing that the VT-1 exists aside from these patches. Is there anything that describes this design and when it's expected to be available?
[Bug rtl-optimization/107690] Regression in ranges::transform vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107690 --- Comment #1 from Andrew Pinski --- -std=c++20 -O3
[Bug rtl-optimization/107690] New: Regression in ranges::transform vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107690
Bug ID: 107690
Summary: Regression in ranges::transform vectorization
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: Mark_B53 at yahoo dot com
Target Milestone: ---
GCC 11.3 vectorizes the following code. GCC 12.2 fails to vectorize.
#include
#include
#include
std::array foo(std::array u, std::array const )
{
std::ranges::transform(u, v, u.begin(), std::plus());
return u;
}
https://godbolt.org/z/KnhdPs6G3
[Bug c/107683] [13 Regression] ICE in int_fits_type_p, at tree.cc:8044
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107683 Marek Polacek changed: What|Removed |Added Ever confirmed|0 |1 CC||mpolacek at gcc dot gnu.org Status|UNCONFIRMED |NEW Target Milestone|--- |13.0 Priority|P3 |P2 Last reconfirmed||2022-11-14 --- Comment #1 from Marek Polacek --- Confirmed. Started with commit e0997c14af5e8bc4d26e28549cbce99364a1601f Author: Joseph Myers Date: Fri Oct 28 00:37:28 2022 + c: C2x enums with fixed underlying type [PR61469]
Re: [PATCH 7/7] riscv: Add support for str(n)cmp inline expansion
On 11/13/22 16:05, Christoph Muellner wrote: From: Christoph Müllner This patch implements expansions for the cmpstrsi and the cmpstrnsi builtins using Zbb instructions (if available). This allows to inline calls to strcmp() and strncmp(). The expansion basically emits a peeled comparison sequence (i.e. a peeled comparison loop) which compares XLEN bits per step if possible. The emitted sequence can be controlled, by setting the maximum number of compared bytes (-mstring-compare-inline-limit). gcc/ChangeLog: * config/riscv/riscv-protos.h (riscv_expand_strn_compare): New prototype. * config/riscv/riscv-string.cc (GEN_EMIT_HELPER3): New helper macros. (GEN_EMIT_HELPER2): New helper macros. (expand_strncmp_zbb_sequence): New function. (riscv_emit_str_compare_zbb): New function. (riscv_expand_strn_compare): New function. * config/riscv/riscv.md (cmpstrnsi): Invoke expansion functions for strn_compare. (cmpstrsi): Invoke expansion functions for strn_compare. * config/riscv/riscv.opt: Add new parameter '-mstring-compare-inline-limit'. Presumably the hybrid inline + out of line approach is to capture the fact that most strings compare unequal early, then punt out to the library if they don't follow that model? It looks like we're structured for that case by peeling iterations rather than having a fully inlined approach. Just want to confirm... I was a bit worried about the "readahead" problem that arises when reading more than a byte and a NUL is found in the first string. If you're not careful, the readahead of the second string could fault. But it looks like we avoid that by requiring word alignment on both strings. + +/* Emit a string comparison sequence using Zbb instruction. + + OPERANDS[0] is the target (result). + OPERANDS[1] is the first source. + OPERANDS[2] is the second source. + If NO_LENGTH is zero, then: + OPERANDS[3] is the length. + OPERANDS[4] is the alignment in bytes. + If NO_LENGTH is nonzero, then: + OPERANDS[3] is the alignment in bytes. Ugh. I guess it's inevitable unless we want to drop the array and pass each element individually (in which case we'd pass a NULL_RTX in the case we don't have a length argument). I'd like to give others a chance to chime in here. Everything looks sensible here, but I may have missed something. So give the other maintainers a couple days to chime in before committing. Jeff
[Bug middle-end/107485] [10 Regression] gcc-10 ICE with -fnon-call-exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107485 --- Comment #10 from Sebastian Pop --- Thanks Richard. The patch fixed the larger test as well.
