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
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.pd
Sometimes "step1 -= scalable_frame" will cause adjust equal to
zero. And it will generate additional redundant instruction
"addi sp,sp,0". Add checking segement to skip that case.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_expand_epilogue):
Current epilogue will generate "addi sp,sp,0" redundant instruction.
```
csrrt0,vlenb
sllit1,t0,1
add sp,sp,t1
addisp,sp,0
ld s0,24(sp)
addisp,sp,32
jr ra
```
Optimize it by check if adjust equal to zero, remove
This testcase mix exist spill-1.c and adding new fun to check if
there have redundant addi intructions. Idea provided by Jeff Law.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/spill-sp-adjust.c: New test.
---
.../gcc.target/riscv/rvv/base/spill-sp-adjust.c | 13 +
Hi:
I'm from https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606040.html.
> }
>
>/* See if we can get a better vector mode before extracting. */
> diff --git a/gcc/optabs.cc b/gcc/optabs.cc
> index
> cff37ccb0dfc3dd79b97d0abfd872f340855dc96..f338df410265dfe55b6896160090a453cc6a
LGTM. Thanks for fixing my mistake.
Let's see whether other RISC-V folks are happy with this patch.
juzhe.zh...@rivai.ai
From: jiawei
Date: 2022-11-15 16:33
To: gcc-patches
CC: kito.cheng; palmer; juzhe.zhong; jeffreyalaw; christoph.muellner;
philipp.tomsich; wuwei2016; jiawei
Subject: [PATC
> -Original Message-
> From: Hongtao Liu
> Sent: Tuesday, November 15, 2022 8:36 AM
> To: Tamar Christina
> Cc: Richard Sandiford ; Tamar Christina via
> Gcc-patches ; nd ;
> rguent...@suse.de
> Subject: Re: [PATCH 3/8]middle-end: Support extractions of subvectors from
> arbitrary element
On Mon, Nov 14, 2022 at 07:00:54PM -0500, Jason Merrill wrote:
> > 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/
On Tue, Nov 15, 2022 at 09:54:00AM +0100, Jakub Jelinek via Gcc-patches wrote:
> On Mon, Nov 14, 2022 at 07:00:54PM -0500, Jason Merrill wrote:
> > > The following patch adds parsing of attributes to concept definition,
> > > allows deprecated attribute to be specified (some ugliness needed
> > > b
On Sat, 2022-11-12 at 17:45 +0800, Xi Ruoyao via Gcc-patches wrote:
> void prefetch(char *ptr, int off)
> {
> return __builtin_prefetch(ptr + off);
> }
>
> It's compiled to "preldx 0,$r4,$r5". I don't think it's correct
> because
> according to the doc, rk should contains several bit-fiel
在 2022/11/15 下午5:17, Xi Ruoyao 写道:
On Sat, 2022-11-12 at 17:45 +0800, Xi Ruoyao via Gcc-patches wrote:
void prefetch(char *ptr, int off)
{
return __builtin_prefetch(ptr + off);
}
It's compiled to "preldx 0,$r4,$r5". I don't think it's correct
because
according to the doc, rk should
On Tue, Nov 15, 2022 at 4:51 PM Tamar Christina wrote:
>
> > -Original Message-
> > From: Hongtao Liu
> > Sent: Tuesday, November 15, 2022 8:36 AM
> > To: Tamar Christina
> > Cc: Richard Sandiford ; Tamar Christina via
> > Gcc-patches ; nd ;
> > rguent...@suse.de
> > Subject: Re: [PATCH
> -Original Message-
> From: Hongtao Liu
> Sent: Tuesday, November 15, 2022 9:37 AM
> To: Tamar Christina
> Cc: Richard Sandiford ; Tamar Christina via
> Gcc-patches ; nd ;
> rguent...@suse.de
> Subject: Re: [PATCH 3/8]middle-end: Support extractions of subvectors from
> arbitrary element
On 11/14/22 18:21, Xi Ruoyao wrote:
> Hi Martin,
>
Hello.
> Is it allowed to merge libsanitizer from LLVM in stage 3? If not I'd
> like to cherry pick some commits from LLVM [to fix some stupid errors
> I've made in LoongArch libasan :(].
I'm sorry but I was really busy with the porting of the
On 11/14/22 14:06, Gerald Pfeifer wrote:
> On Mon, 14 Nov 2022, Martin Liška wrote:
>> The situation with the Sphinx migration went out of control. The TODO
>> list overwhelmed me and there are road-blocks that can't be easily fixed
>> with what Sphinx currently supports.
>
> This migration was/
On Tue, Nov 15, 2022 at 11:02:53AM +0100, Martin Liška wrote:
> > Is it allowed to merge libsanitizer from LLVM in stage 3? If not I'd
> > like to cherry pick some commits from LLVM [to fix some stupid errors
> > I've made in LoongArch libasan :(].
>
> I'm sorry but I was really busy with the por
Hi Richard,
On 11/10/22 11:52, Richard Biener wrote:
On Wed, Oct 26, 2022 at 10:16 AM wrote:
This is the fixed version of our previous patch set for gccrs - We've adressed
the comments raised in our previous emails.
This patch set does not contain any work that was not previously included, s
Hi All,
After the fix to the addsub patch yesterday for bootstrap I had only regtested
on x86.
While looking today it seemed the new tests were failing, this was caused
by a change in the behavior of the GET_MODE_WIDER_MODE macro on trunk.
This patch fixes that issue. Sorry for the mess, have re
On Mon, 14 Nov 2022 at 17: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 ++--
Tamar Christina writes:
> Hello,
>
> Ping and updated patch.
>
> Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
>
> Ok for master?
>
> Thanks,
> Tamar
>
> gcc/ChangeLog:
>
> * config/aarch64/aarch64.md (*tb1): Rename to...
> (*tb1): ... this.
> (tbranch4):
> -Original Message-
> From: Richard Sandiford
> Sent: Tuesday, November 15, 2022 10:36 AM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; Richard Earnshaw
> ; nd ; Marcus Shawcroft
>
> Subject: Re: [PATCH 2/2]AArch64 Support new tbranch optab.
>
> Tamar Christina writes:
> > Hell
Philipp Tomsich writes:
> Richard,
>
> is this OK for backport to GCC-12 and GCC-11?
The fusion part seems potentially risky for a stable branch, but since
it's conditional on the new flag (and thus new CPU), I think it should
be OK.
So yeah, OK for both, thanks.
Richard
> Thanks,
> Philipp.
>
Hi,
I saw that Stage 1 of GCC 13 development is just ended. So is this
considered? Or should I bring this up when general development is
reopened?
Thanks,
Di Zhao
> -Original Message-
> From: Di Zhao OS
> Sent: Tuesday, October 25, 2022 8:18 AM
> To: gcc-patches@gcc.gnu.org
> Cc: Richa
On 11/15/22 08:15, Richard Biener wrote:
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
Tamar Christina writes:
>> -Original Message-
>> From: Richard Sandiford
>> Sent: Tuesday, November 15, 2022 10:36 AM
>> To: Tamar Christina
>> Cc: gcc-patches@gcc.gnu.org; Richard Earnshaw
>> ; nd ; Marcus Shawcroft
>>
>> Subject: Re: [PATCH 2/2]AArch64 Support new tbranch optab.
>>
>
On 15/11/22 11:35 +0800, Hongyu Wang wrote:
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: Rewo
> -Original Message-
> From: Richard Sandiford
> Sent: Tuesday, November 15, 2022 10:51 AM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; Richard Earnshaw
> ; nd ; Marcus Shawcroft
>
> Subject: Re: [PATCH 2/2]AArch64 Support new tbranch optab.
>
> Tamar Christina writes:
> >> ---
Tamar Christina writes:
> Hi,
>
>> > --- a/gcc/config/aarch64/aarch64-simd.md
>> > +++ b/gcc/config/aarch64/aarch64-simd.md
>> > @@ -4259,7 +4259,7 @@ (define_insn
>> "*aarch64_get_lane_zero_extend"
>> > ;; Extracting lane zero is split into a simple move when it is
>> > between SIMD ;; register
Tamar Christina writes:
>> -Original Message-
>> From: Richard Sandiford
>> Sent: Tuesday, November 15, 2022 10:51 AM
>> To: Tamar Christina
>> Cc: gcc-patches@gcc.gnu.org; Richard Earnshaw
>> ; nd ; Marcus Shawcroft
>>
>> Subject: Re: [PATCH 2/2]AArch64 Support new tbranch optab.
>>
>
On Fri, Nov 11, 2022 at 10:47 PM Tamar Christina via Gcc-patches
wrote:
>
> Hi All,
>
> The current i386 implementation of the TARGET_CAN_CHANGE_MODE_CLASS is
> currently
> not useful before re-alloc.
>
> In particular before regalloc optimization passes query the hook using
> ALL_REGS,
> but be
> -Original Message-
> From: Richard Sandiford
> Sent: Tuesday, November 15, 2022 11:15 AM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; Richard Earnshaw
> ; nd ; Marcus Shawcroft
>
> Subject: Re: [PATCH 2/2]AArch64 Support new tbranch optab.
>
> Tamar Christina writes:
> >> ---
On Mon, 14 Nov 2022, Jeff Law wrote:
> > 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.
Thanks, now committed.
Maciej
Tamar Christina writes:
>> -Original Message-
>> From: Richard Sandiford
>> Sent: Tuesday, November 15, 2022 11:15 AM
>> To: Tamar Christina
>> Cc: gcc-patches@gcc.gnu.org; Richard Earnshaw
>> ; nd ; Marcus Shawcroft
>>
>> Subject: Re: [PATCH 2/2]AArch64 Support new tbranch optab.
>>
>
Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* doc/xml/manual/documentation_hacking.xml: Document use of
Markdown for Doxygen comments. Tweak formatting.
* doc/html/manual/documentation_hacking.html: Regenerate.
---
.../html/manual/documentation_hacking.html| 21
> -Original Message-
> From: Richard Sandiford
> Sent: Tuesday, November 15, 2022 11:34 AM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; Richard Earnshaw
> ; nd ; Marcus Shawcroft
>
> Subject: Re: [PATCH 2/2]AArch64 Support new tbranch optab.
>
> Tamar Christina writes:
> >> ---
Tamar Christina via Gcc-patches writes:
> Hi All,
>
> After the fix to the addsub patch yesterday for bootstrap I had only
> regtested on x86.
> While looking today it seemed the new tests were failing, this was caused
> by a change in the behavior of the GET_MODE_WIDER_MODE macro on trunk.
>
> T
[Public]
Hi,
Thank you for reviewing the patch.
> Hi. I'm still waiting for feedback on fixes for existing models:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Finbox.
> sourceware.org%2Fgcc-patches%2F5ae6fc21-edc6-133-aee2-
> a41e16eb5b7%40ispras.ru%2FT%2F%23t&data=05%7C01
From: Oria Chen
gcc/testsuite/ChangeLog:
2022-11-15 Yixuan Chen
* gcc.dg/fold-overflow-1.c: Optimize testcase, because riscv will use
".LC0" intead of ".LC1" and ".LC2" with "-O" compile option
---
gcc/testsuite/gcc.dg/fold-overflow-1.c | 3 ++-
1 file changed, 2 insertions(+), 1 d
Am 14.11.22 um 18:55 schrieb Jason Merrill:
On 11/10/22 06:40, Georg-Johann Lay wrote:
Am 10.11.22 um 15:08 schrieb Paul Iannetta:
On Thu, Nov 03, 2022 at 02:38:39PM +0100, Georg-Johann Lay wrote:
[PATCH v3] c++: parser - Support for target address spaces in C++
2. Will it work with comp
On Tue, Nov 15, 2022 at 08:13:45PM +0800, Yixuan Chen wrote:
> From: Oria Chen
>
> gcc/testsuite/ChangeLog:
>
> 2022-11-15 Yixuan Chen
>
> * gcc.dg/fold-overflow-1.c: Optimize testcase, because riscv will use
> ".LC0" intead of ".LC1" and ".LC2" with "-O" compile option
This is wro
Hi!
On Mon, Nov 14, 2022 at 06:29:44PM -0500, Jason Merrill wrote:
> 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
>
On 11/15/22 11:07, Jakub Jelinek wrote:
> On Tue, Nov 15, 2022 at 11:02:53AM +0100, Martin Liška wrote:
>>> Is it allowed to merge libsanitizer from LLVM in stage 3? If not I'd
>>> like to cherry pick some commits from LLVM [to fix some stupid errors
>>> I've made in LoongArch libasan :(].
>>
>> I
On Tue, 15 Nov 2022, Joshi, Tejas Sanjay wrote:
> > > +;; AVX instructions
> > > +(define_insn_reservation "znver4_sse_log" 1
> > > + (and (eq_attr "cpu" "znver4")
> > > + (and (eq_attr "type" "sselog,sselog1")
> > > +
On Tue, Nov 15, 2022 at 01:49:36PM +0100, Martin Liška wrote:
> On 11/15/22 11:07, Jakub Jelinek wrote:
> > On Tue, Nov 15, 2022 at 11:02:53AM +0100, Martin Liška wrote:
> >>> Is it allowed to merge libsanitizer from LLVM in stage 3? If not I'd
> >>> like to cherry pick some commits from LLVM [to
gcc/ChangeLog:
* config/loongarch/sync.md:
Add atomic_cas_value_exchange_and_7 and fix atomic_exchange.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/sync-1.c: New test.
---
gcc/config/loongarch/sync.md| 27 -
gcc/testsuite/gcc.target/loongarch/sync-1.c | 104
> -Original Message-
> From: Richard Sandiford
> Sent: Tuesday, November 15, 2022 11:59 AM
> To: Tamar Christina via Gcc-patches
> Cc: Tamar Christina ; nd ;
> rguent...@suse.de; j...@ventanamicro.com
> Subject: Re: [PATCH]middle-end: replace GET_MODE_WIDER_MODE with
> GET_MODE_NEXT_MODE
Using depth == 1 it makes the cloning much faster.
libsanitizer/ChangeLog:
* merge.sh: Use git clone --depth 1.
---
libsanitizer/merge.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libsanitizer/merge.sh b/libsanitizer/merge.sh
index 95ded4f9634..7d1b553e2bb 10075
On Tue, 15 Nov 2022, Jonathan Wakely via Gcc-patches wrote:
> > @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 whe
On Tue, 15 Nov 2022 at 13:34, Alexander Monakov wrote:
>
> On Tue, 15 Nov 2022, Jonathan Wakely via Gcc-patches wrote:
>
> > > @item -mrelax-cmpxchg-loop
> > > @opindex mrelax-cmpxchg-loop
> > >-Relax cmpxchg loop by emitting an early load and compare before cmpxchg,
> > >-execute pause if load va
On 11/9/22 14:53, Richard Biener wrote:
On Wed, Oct 26, 2022 at 10:37 AM wrote:
From: Philip Herron
This patch contains the entry point and utilities used for the lowering
of HIR nodes to `tree`s. It also contains a constant evaluator, ported
over from the C++ frontend.
Co-authored-by: Da
On Mon, Nov 14, 2022 at 10:12 AM 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 t
On Tue, 15 Nov 2022, Jonathan Wakely wrote:
> > How about the following:
> >
> > When emitting a compare-and-swap loop for @ref{__sync Builtins}
> > and @ref{__atomic Builtins} lacking a native instruction, optimize
> > for the highly contended case by issuing an atomic load before the
> > @code
On Tue, 2022-11-15 at 21:03 +0800, Jinyang He wrote:
> gcc/ChangeLog:
>
> * config/loongarch/sync.md:
> Add atomic_cas_value_exchange_and_7 and fix atomic_exchange.
nit:
* config/loongarch/sync.md (atomic_cas_value_exchange_and_7):
New define_insn.
(atomic_exchange): Use
Tested x86_64-linux and x86_64-w64-mingw32. Pushed to trunk.
-- >8 --
std::format gives linker errors on targets that define __float128 but
do not support using it with std::to_chars. This improves the handling
of 128-bit flaoting-point types so they are disabled if unsupportable.
libstdc++-v3/C
Tested x86_64-linux and x86_64-w64-mingw32. Pushed to trunk.
-- >8 --
This concept was added by a C++23 proposal, so don't define it for
C++20.
Split the format/formatter/formatter.cc test into two parts, one that
tests the C++20 requirements and one that tests the C++23 concept.
libstdc++-v3/C
Tested x86_64-linux and x86_64-w64-mingw32. Pushed to trunk.
-- >8 --
Adjust a test to avoid using std::make_unsigned_t<__int128>. That's
ill-formed in strict modes because std::is_integral_v<__int128> is
false.
libstdc++-v3/ChangeLog:
* testsuite/std/format/functions/format.cc: Do not
On Tue, Nov 15, 2022 at 02:31:19PM +, Jonathan Wakely via Gcc-patches wrote:
> Tested x86_64-linux and x86_64-w64-mingw32. Pushed to trunk.
>
> -- >8 --
>
> std::format gives linker errors on targets that define __float128 but
> do not support using it with std::to_chars. This improves the ha
Tamar Christina writes:
>> -Original Message-
>> From: Richard Sandiford
>> Sent: Tuesday, November 15, 2022 11:59 AM
>> To: Tamar Christina via Gcc-patches
>> Cc: Tamar Christina ; nd ;
>> rguent...@suse.de; j...@ventanamicro.com
>> Subject: Re: [PATCH]middle-end: replace GET_MODE_WIDER
Hello,
Is there still any interest in merging this patch?
Thanks,
Daniel
On Mon, Oct 31, 2022, at 8:44 AM, Daniel Engel wrote:
> Hi Richard,
>
> I am re-submitting my libgcc patch from 2021:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563585.html
> https://gcc.gnu.org/p
Ping on this patch.
thanks.
Qing
> On Nov 8, 2022, at 9:51 AM, Qing Zhao wrote:
>
> '-Wstrict-flex-arrays'
> Warn about inproper usages of flexible array members according to
> the LEVEL of the 'strict_flex_array (LEVEL)' attribute attached to
> the trailing array field of a struct
On Tue, 15 Nov 2022 at 14:42, Jakub Jelinek wrote:
>
> On Tue, Nov 15, 2022 at 02:31:19PM +, Jonathan Wakely via Gcc-patches
> wrote:
> > Tested x86_64-linux and x86_64-w64-mingw32. Pushed to trunk.
> >
> > -- >8 --
> >
> > std::format gives linker errors on targets that define __float128 but
Hi.
I've just pushed libsanitizer update that was tested on x86_64-linux and
ppc64le-linux systems.
Moreover, I run bootstrap on x86_64-linux and checked ABI difference with
abidiff.
Pushed as r13-4068-g3037f11fb86eda.
Cheers,
Martin
On 11/11/2022 17:40, Stam Markianos-Wright via Gcc-patches wrote:
Hi all,
This is the 2/2 patch that contains the functional changes needed
for MVE Tail Predicated Low Overhead Loops. See my previous email
for a general introduction of MVE LOLs.
This support is added through the already exis
On Thu, 20 Oct 2022 at 16:53, Arsen Arsenović via Libstdc++
wrote:
>
> This enables us to provide symbols for placeholders and numeric limits,
I'm not convinced this is worth doing.
The placeholders and the numeric_limits members are all inline
variables for C++17 and later, and C++17 is the co
On 11/15/22 03:44, Di Zhao OS via Gcc-patches wrote:
Hi,
I saw that Stage 1 of GCC 13 development is just ended. So is this
considered? Or should I bring this up when general development is
reopened?
Yes, it can still be considered. The guideline is the patch must be
posted before stage1 c
> From: Patrick Palka via Gcc-patches
> Date: Fri, 4 Nov 2022 16:05:25 +0100
> This patch moves the global object for constructing the standard streams
> out from and into the compiled library on targets that support
> the init_priority attribute. This means that no longer
> introduces a separ
On 06/10/22 19:38 +0200, François Dumont wrote:
Hi
Looks like the previous patch was not enough. When using it in the
context of a build without dual abi and versioned namespace I started
having failures again. I guess I hadn't rebuild everything properly.
This time I think the problem was in t
On 11/15/22 07:54, Richard Sandiford via Gcc-patches wrote:
Tamar Christina writes:
-Original Message-
From: Richard Sandiford
Sent: Tuesday, November 15, 2022 11:59 AM
To: Tamar Christina via Gcc-patches
Cc: Tamar Christina ; nd ;
rguent...@suse.de; j...@ventanamicro.com
Subject: R
I know it's past the end of stage1, but I'm afraid we'll drag this
around forever in the GCC12 branch, and it's an easy readbility fix.
p.s. Or if you prefer:
if (!lb_nan && !ub_nan && !maybe_nan && )
r.clear_nan ();
OK for trunk?
gcc/ChangeLog:
* range-op-float.cc (range_operato
On 11/14/22 08:38, Christoph Müllner wrote:
Ok, I will add the check.
Still, I don't think that the optimization changes the behavior in the
case of different ABIs
(i.e. the situation is problematic regardless if there is an indirect call
or a guarded direct call).
What could be done addition
On 11/13/22 13:41, Philipp Tomsich wrote:
RISC-V's .p2align (currently) ignores the max-skip argument. As we
have experimental patches underway to address this in a
backwards-compatible manner, let's prepare GCC for the day when
binutils gets updated.
gcc/ChangeLog:
* config/riscv/ri
On 11/13/22 13:41, Philipp Tomsich wrote:
The Zihintpause extension uses an opcode from the 'fence' opcode range
to add a true hint instruction (i.e. if it is not supported on any
given platform, the 'fence' that is encoded will not enforce any
specific ordering on memory accesses) for entering
Permit running vector tests outside `check_vect_support_and_set_flags'
environment, removing errors such as:
ERROR: gcc.dg/analyzer/torture/pr93350.c -O0 : can't read
"EFFECTIVE_TARGETS": no such variable for " dg-require-effective-target 1
vect_int "
or:
ERROR: gcc.dg/bic-bitmask-13.c: err
On 11/13/22 13:48, Philipp Tomsich wrote:
For a straightforward application of bext for the following function
long bext64(long a, char bitno)
{
return (a & (1UL << bitno)) ? 0 : -1;
}
we generate
srl a0,a0,a1# 7 [c=4 l=4] lshrdi3
andia0,a0,1 #
On Mon, 14 Nov 2022 23:25:54 PST (-0800), richard.guent...@gmail.com wrote:
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
On 11/13/22 13:48, Philipp Tomsich wrote:
We avoid reassociating "(~(a >> BIT_NO)) & 1" into "((~a) >> BIT_NO) & 1"
by splitting it into a zero-extraction (bext) and an xori. This both
avoids burning a register on a temporary and generates a sequence that
clearly captures 'extract bit, then in
Tamar Christina writes:
>> -Original Message-
>> From: Hongtao Liu
>> Sent: Tuesday, November 15, 2022 9:37 AM
>> To: Tamar Christina
>> Cc: Richard Sandiford ; Tamar Christina via
>> Gcc-patches ; nd ;
>> rguent...@suse.de
>> Subject: Re: [PATCH 3/8]middle-end: Support extractions of su
On 11/11/22 09:21, Richard Sandiford via Gcc-patches wrote:
Arm's SME adds a new processor mode called streaming mode.
This mode enables some new (matrix-oriented) instructions and
disables several existing groups of instructions, such as most
Advanced SIMD vector instructions and a much smalle
"Andre Vieira (lists)" writes:
> Updated version of the patch to account for the testsuite changes in the
> first patch.
>
> On 10/11/2022 11:20, Andre Vieira (lists) via Gcc-patches wrote:
>> Hi,
>>
>> This patch adds support for the widening LDAPR instructions.
>>
>> Bootstrapped and regression
"Andre Vieira (lists)" writes:
> On 07/11/2022 11:05, Richard Biener wrote:
>> On Fri, 4 Nov 2022, Andre Vieira (lists) wrote:
>>
>>> Sorry for the delay, just been reminded I still had this patch outstanding
>>> from last stage 1. Hopefully since it has been mostly reviewed it could go
>>> in
>>
Jonathan Wakely writes:
> On Thu, 20 Oct 2022 at 16:53, Arsen Arsenović via Libstdc++
> wrote:
>>
>> This enables us to provide symbols for placeholders and numeric limits,
>
>
> I'm not convinced this is worth doing.
>
> The placeholders and the numeric_limits members are all inline
> variable
On Mon, 2022-11-14 at 15:42 -0500, Marek Polacek wrote:
> 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 f
On Tue, Nov 15, 2022 at 01:35:05PM -0500, David Malcolm wrote:
> On Mon, 2022-11-14 at 15:42 -0500, Marek Polacek wrote:
> > 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 &
Found when working on real reverse offload - as
the reverse-offload stub function was added to the reverse-offload table.
Reason - as mentioned in the commit log: lhd_set_decl_assembler_name.
I intent to commit it tomorrow as obvious, unless there are further
comments.
Tobias
-
S
[Fixing typo in the Subject ("git" -> "jit" ); CCing jit mailing list]
On Fri, 2022-11-11 at 17:16 +, Jonathan Wakely wrote:
> On Mon, 7 Nov 2022 at 13:51, Jonathan Wakely wrote:
> >
> > On Mon, 7 Nov 2022 at 13:33, LIU Hao wrote:
> > >
> > > 在 2022-11-07 20:57, Jonathan Wakely 写道:
> > > > I
On Tue, 15 Nov 2022 at 18:50, David Malcolm wrote:
>
> [Fixing typo in the Subject ("git" -> "jit" ); CCing jit mailing list]
>
> On Fri, 2022-11-11 at 17:16 +, Jonathan Wakely wrote:
> > On Mon, 7 Nov 2022 at 13:51, Jonathan Wakely wrote:
> > >
> > > On Mon, 7 Nov 2022 at 13:33, LIU Hao wrote
On Fri, 2022-11-11 at 22:27 -0500, David Malcolm wrote:
> Changed in v2: ported doc changes from texinfo to sphinx
>
> Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
>
> I can self-approve this patch, but it depends on the named constants
> patch here:
> * [PATCH v2] c, analyzer
Fix a maybe-uninitialized warning introduced in commit:
068baae1864 bpf: add preserve_field_info builtin
Thanks to Jan-Benedict Glaw for pointing this out.
Tested on bpf-unknown-none, committed as obvious.
gcc/
* config/bpf/bpf.cc (bpf_expand_builtin): Avoid use of uninitialized
The gimple generated by riscv is identical to that of powerpc64
currently. It seems like the change at
r12-4790-4b3a325f07acebf47e82de227ce1d5ba62f5bcae also affected riscv64 like
powerpc64 and cris.
gcc/testsuite/ChangeLog:
* gcc.dg/uninit-pred-9_b.c: Xfail for riscv64
---
gcc/testsui
On 11/15/22 12:08, Kevin Lee wrote:
The gimple generated by riscv is identical to that of powerpc64
currently. It seems like the change at
r12-4790-4b3a325f07acebf47e82de227ce1d5ba62f5bcae also affected riscv64 like
powerpc64 and cris.
gcc/testsuite/ChangeLog:
* gcc.dg/uninit-pred-9
Mark Wielaard writes:
> https://code.wildebeest.org/git/user/mjw/gccrs/commit/?h=no-Rust-old
> if someone wants to push that, to merge for a v4.
Sorry, missed that part, taking care of merging it right now :)
https://github.com/Rust-GCC/gccrs/pull/1649
Thanks,
Marc
Dear all,
when constant expressions involve parentheses, array constructors,
typespecs, and the power operator (**), we could fail with an ICE
during simplification in arith_power.
Debugging of the testcase showed we call the proper type conversions
needed for the arithmetic operation, but under
Jeff,
On Tue, 15 Nov 2022 at 17:37, Jeff Law wrote:
>
>
> On 11/13/22 13:41, Philipp Tomsich wrote:
>
> RISC-V's .p2align (currently) ignores the max-skip argument. As we
> have experimental patches underway to address this in a
> backwards-compatible manner, let's prepare GCC for the day when
>
On 11/15/22 02:28, Jakub Jelinek wrote:
Hi!
On Mon, Nov 14, 2022 at 06:29:44PM -0500, Jason Merrill wrote:
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 membe
On 11/14/22 22:54, Jakub Jelinek wrote:
On Tue, Nov 15, 2022 at 09:54:00AM +0100, Jakub Jelinek via Gcc-patches wrote:
On Mon, Nov 14, 2022 at 07:00:54PM -0500, Jason Merrill wrote:
The following patch adds parsing of attributes to concept definition,
allows deprecated attribute to be specified
On 11/14/22 14:33, Marek Polacek wrote:
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
On Tue, 15 Nov 2022 at 17:40, Jeff Law wrote:
>
>
> On 11/13/22 13:41, Philipp Tomsich wrote:
> > The Zihintpause extension uses an opcode from the 'fence' opcode range
> > to add a true hint instruction (i.e. if it is not supported on any
> > given platform, the 'fence' that is encoded will not e
On Tue, Nov 15, 2022 at 1:46 AM 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
From: Christoph Müllner
This patch fixes a wrong placed closing bracket in the RISC-V section of
invoke.texi.
gcc/ChangeLog:
* doc/invoke.texi: Fix closing block bracket
Signed-off-by: Christoph Müllner
---
gcc/doc/invoke.texi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
1 - 100 of 149 matches
Mail list logo
