On Mon, Nov 28, 2022 at 9:06 PM liuhongt wrote:
>
> For __builtin_ia32_vec_set_v16qi (a, -1, 2) with
> !flag_signed_char. it's transformed to
> __builtin_ia32_vec_set_v16qi (_4, 255, 2) in the gimple,
> and expanded to (const_int 255) in the rtl. But for immediate_operand,
> it expects (const_int
On Mon, 28 Nov 2022 20:49:00 PST (-0800), jeffreya...@gmail.com wrote:
On 11/28/22 19:56, Palmer Dabbelt wrote:
On Mon, 28 Nov 2022 17:46:16 PST (-0800), juzhe.zh...@rivai.ai wrote:
Yeah, I personally want to support RVV intrinsics in GCC13. As RVV
intrinsic is going to release soon next week
On 11/28/22 18:53, Feng Wang wrote:
on 2022-11-28 23:39 Jeff Law wrote:
On 11/27/22 19:14, Feng Wang wrote:
From: wangfeng
There is no Immediate operand of ins "rol" accroding to the B-ext,
so the immediate operand should be loaded into register at first.
But we can convert it to the in
On 11/28/22 19:56, Palmer Dabbelt wrote:
On Mon, 28 Nov 2022 17:46:16 PST (-0800), juzhe.zh...@rivai.ai wrote:
Yeah, I personally want to support RVV intrinsics in GCC13. As RVV
intrinsic is going to release soon next week.
OK, that's fine with me -- I was leaning that way, and I think Jeff
Hi Jeff,
Thanks a lot for your comments!
Jeff Law writes:
> On 11/22/22 19:58, Jiufu Guo wrote:
>> Hi Jeff,
>>
>> Thanks a lot for your comments!
>>
>> Jeff Law writes:
>>
>>> On 11/20/22 20:07, Jiufu Guo wrote:
Jiufu Guo writes:
> Hi,
>
> As mentioned in the previous
On Mon, 28 Nov 2022 19:07:24 PST (-0800), juzhe.zh...@rivai.ai wrote:
In case of RVV intrinsic support, there is no changes outside RISC-V backend
since we don't do the autovectorization support for now.
OK, I'm fine with that. Sounds like Kito is too?
I will postpone autovectorization until
In case of RVV intrinsic support, there is no changes outside RISC-V backend
since we don't do the autovectorization support for now.
I will postpone autovectorization until GCC14 is open.
juzhe.zh...@rivai.ai
From: Palmer Dabbelt
Date: 2022-11-29 10:56
To: juzhe.zhong
CC: Kito Cheng; jeffreya
On Mon, 28 Nov 2022 17:46:16 PST (-0800), juzhe.zh...@rivai.ai wrote:
Yeah, I personally want to support RVV intrinsics in GCC13.
As RVV intrinsic is going to release soon next week.
OK, that's fine with me -- I was leaning that way, and I think Jeff only
had a weak opposition. Are there any
On Mon, Nov 28, 2022 at 10:40 PM Martin Liška wrote:
>
> On 11/11/22 02:26, liuhongt via Gcc-patches wrote:
> >2 years ago, ARM folks support HWASAN[1] in GCC[2], and introduced
> > several
> > target hooks(Many thanks to their work) so other backends can do similar
> > things if they have si
On Mon, Nov 28, 2022 at 6:40 AM Martin Liška wrote:
>
> On 11/11/22 02:26, liuhongt via Gcc-patches wrote:
> >2 years ago, ARM folks support HWASAN[1] in GCC[2], and introduced
> > several
> > target hooks(Many thanks to their work) so other backends can do similar
> > things if they have sim
on 2022-11-28 23:39 Jeff Law wrote:
>
>
>On 11/27/22 19:14, Feng Wang wrote:
>> From: wangfeng
>>
>> There is no Immediate operand of ins "rol" accroding to the B-ext,
>> so the immediate operand should be loaded into register at first.
>> But we can convert it to the ins "rori" or "roriw", and t
Yeah, I personally want to support RVV intrinsics in GCC13.
As RVV intrinsic is going to release soon next week.
juzhe.zh...@rivai.ai
From: Kito Cheng
Date: 2022-11-29 09:38
To: Jeff Law
CC: 钟居哲; gcc-patches; palmer
Subject: Re: [PATCH] RISC-V: Add attributes for VSETVL PASS
Actually, I am st
Actually, I am strongly support those stuff keep merge to trunk until
February, my goal is intrinsic support for vector, but not including any
vectorization like SLP or Loop vectorization, the most critical part is the
vsetvli which is the mode switching, and its almost done.
Those part is kind of
From: Ju-Zhe Zhong
Sorry for resend this patch, I found I miss commit a file.
1. vector.md: remove tail && mask policy operand for mask mode operations since
we don't need them according to RVV ISA.
2. riscv-v.cc: adapt emit_pred_op for mask mode predicated mov since all RVV
modes
includin
Hi Richard,
在 2022/11/29 2:46, Richard Biener 写道:
> Anyhow - my question still stands - what's the fallback for the callers
> that do not check for failure? How are we sure we're not running into
> these when relaxing the requirement that a MODE_CC prepare_cmp_insn
> must not fail?
I examed the
Import include/xtensa-dynconfig.h that defines XCHAL_* macros as fields
of a structure returned from the xtensa_get_config_v function call.
Define that structure and fill it with default parameter values
specified in the include/xtensa-config.h.
Define reusable function xtensa_load_config that trie
Now that gcc provides __XCHAL_* definitions use them instead of XCHAL_*
definitions from the include/xtensa-config.h. That makes libgcc
dynamically configurable for the target xtensa core.
libgcc/
* config/xtensa/crti.S (xtensa-config.h): Replace #inlcude with
xtensa-config-builtin
Hello,
this series addresses the long standing issue with xtensa configuration
support by adding a way to configure toolchain for a specific xtensa
core at runtime using the xtensa-dynconfig [1] library as a plugin.
On a platform with shared library support single toolchain binary
becomes capable
On Sun, Nov 27, 2022 at 09:21:00AM -0500, David Malcolm via Gcc-patches wrote:
> We're currently in "stage 3" of GCC 13 development, which means that
> we're focusing on bug-fixing, rather than cleanups and feature work.
> Though exceptions can be made for low-risk work, at the discretion of
> the
Hi!
On Sat, Nov 26, 2022 at 09:16:13PM -0500, Charlie Sale via Gcc-patches wrote:
> This is my first contribution to GCC :) one of the beginner projects
> suggested on the website was to add and use RTL type predicates.
It says "See which ones are worth having a predicate for, and add them."
Non
On Mon, 28 Nov 2022, Patrick Palka wrote:
> [temp.res.general]/3 says, in a note, "the usual qualified name lookup
> ([basic.lookup.qual]) applies even in the presence of typename". Thus
> when resolving a TYPENAME_TYPE, it seems we shouldn't be looking past
> non-type members.
>
> This patch fi
On 11/28/22 15:52, 钟居哲 wrote:
>> I'm tempted to push this into the next stage1 given its arrival after
stage1 close, but if the wider RISC-V maintainers want to see it move
forward, I don't object strongly.
Ok, let's save these patches and merge them when GCC14 stage1 is open.
Would you mi
On 11/28/22 15:16, Patrick Palka wrote:
Here we're crashing when using an explicit specialization of a function
template with trailing requirements ultimately because decls_match
(called indirectly from register_specialization) returns false since the
template has trailing requirements whereas th
On Mon, 28 Nov 2022 15:10:15 PST (-0800), juzhe.zh...@rivai.ai wrote:
Thanks.
I think we still can continue RVV feature reviewing process in github branch
that we have talked about. Such patches that have been reviewed I will still
send
them to GCC mail list and not to merge right now, we can
Thanks.
I think we still can continue RVV feature reviewing process in github branch
that we have talked about. Such patches that have been reviewed I will still
send
them to GCC mail list and not to merge right now, we can wait until stage1 is
open.
Is it a good idea ? I don't want to make RV
On Mon, Nov 28, 2022 at 07:46:07PM +0100, Richard Biener wrote:
> Anyhow - my question still stands - what's the fallback for the callers
> that do not check for failure? How are we sure we're not running into
> these when relaxing the requirement that a MODE_CC prepare_cmp_insn
> must not fail?
OK.
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2022-11-29 00:49
To: juzhe.zhong; gcc-patches
CC: kito.cheng
Subject: Re: [PATCH] RISC-V: Add duplicate vector support.
On 11/25/22 09:06, juzhe.zh...@rivai.ai wrote:
> From: Ju-Zhe Zhong
>
> gcc/ChangeLog:
>
> * config/riscv/constraint
Yes, it's a cleanup.
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2022-11-29 00:48
To: juzhe.zhong; gcc-patches
CC: kito.cheng; palmer
Subject: Re: [PATCH] RISC-V: Remove tail && mask policy operand for vmclr,
vmset, vmld, vmst
On 11/28/22 07:21, juzhe.zh...@rivai.ai wrote:
> From: Ju-Zhe Zhon
>> I'm tempted to push this into the next stage1 given its arrival after
>> stage1 close, but if the wider RISC-V maintainers want to see it move
>> forward, I don't object strongly.
Ok, let's save these patches and merge them when GCC14 stage1 is open.
Would you mind telling me when will stage 1
On Fri, 25 Nov 2022, Zopolis0 via Gcc-patches wrote:
> Firstly, to get feedback and reviews on the 56 already existing
> patches, even though most are just re-adding code or making idiomatic
> changes, so that when the final issue is solved everything has already
> been approved (hopefully) and th
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_option_override): Fix comment
wording.
---
Just stumbled on this one looking at the output of that sed script. The
script itself was fine, the original comment was to blame.
---
gcc/config/riscv/riscv.cc | 2 +-
1 file changed, 1 inse
[temp.res.general]/3 says, in a note, "the usual qualified name lookup
([basic.lookup.qual]) applies even in the presence of typename". Thus
when resolving a TYPENAME_TYPE, it seems we shouldn't be looking past
non-type members.
This patch fixes this by passing want_type=false instead of =true du
On Mon, Mar 7, 2022 at 6:06 AM Jakub Jelinek via Gcc-patches
wrote:
>
> Hi!
>
> Like in r10-7215-g700d4cb08c88aec37c13e21e63dd61fd698baabc 2 years ago,
> I've run
> grep -v 'long long\|optab optab\|template template\|double double'
> *.{[chS],cc} */*.{[chS],cc} *.def config/*/* 2>/dev/null | grep
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Usually a requirement starting with 'typename' is a type-requirement, but it
might be a simple-requirement such as a functional cast to a typename-type.
PR c++/101733
gcc/cp/ChangeLog:
* parser.cc (cp_parser_requirement):
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Some clang folks mailed me asking about being less permissive about
'concept bool', so let's bump it up from pedwarn to permerror.
gcc/cp/ChangeLog:
* parser.cc (cp_parser_decl_specifier_seq): Change 'concept bool'
diagnost
Hi Adrian,
Again thanks for working on this and getting it into a suitable state for
posting.
It’s a good idea to CC relevant maintainer(s) on patches [see MAINTAINERS] and
I’d welcome cc on any coroutines ones (it’s easy to miss a patch otherwise).
> On 28 Nov 2022, at 11:55, Adrian Perl via G
On 28/11/22 19:35, Jonathan Wakely wrote:
On Mon, 28 Nov 2022 at 06:07, François Dumont via Libstdc++
mailto:libstdc%2b...@gcc.gnu.org>> wrote:
This patch is fixing those tests:
20_util/to_chars/float128_c++23.cc
std/format/formatter/requirements.cc
std/format/functions/form
Here we're crashing when using an explicit specialization of a function
template with trailing requirements ultimately because decls_match
(called indirectly from register_specialization) returns false since the
template has trailing requirements whereas the specialization doesn't.
In r12-2230-gdd
From: Andrew Pinski
There was a small typo where Also was done
twice. The second also should have been
handled. This fixes that.
Committed as obvious after a build.
gcc/ChangeLog:
* match.pd ((A / (1 << B)) -> (A >> B).):
Fix comment.
---
gcc/match.pd | 2 +-
1 file changed, 1
Dear all,
as reported, the Fortran standard requires all actual argument
expressions to be evaluated (e.g. F2018:15.5.3).
There were two cases for intrinsic MERGE where we failed to do so:
- non-constant mask; Steve provided the patch
- constant scalar mask; we need to be careful to simplify on
On 11/10/22 07:37, Lin Sinan via Gcc-patches wrote:
The motivation of this patch is to correct the wrong estimation of the number
of instructions needed for loading a 64bit constant in rv32 in the current cost
model(riscv_interger_cost). According to the current implementation, if a
constant
On Mon, 28 Nov 2022, Jeff Law wrote:
> > Given the false negatives how about getting a bit stricter and also
> > checking there's nothing following the XORI instruction, like here?
> >
> > It might be an overkill to have a check both for the sequence and for the
> > absence of ANDI or SEXT.W
On Mon, 28 Nov 2022 11:15:01 PST (-0800), gcc-patches@gcc.gnu.org wrote:
>
>
> On 11/24/22 00:43, Sinan wrote:
>>> The motivation of this patch is to correct the wrong estimationÂ
>>>of
 the number of instructions needed for loading a 64bit constantÂ
in
 rv32 in
On 11/24/22 00:43, Sinan wrote:
The motivation of this patch is to correct the wrong estimation of
the number of instructions needed for loading a 64bit constant in
rv32 in the current cost model(riscv_interger_cost). According to
the current implementation, if a constant requires more th
On Mon, Nov 28, 2022 at 6:58 PM Segher Boessenkool
wrote:
>
> On Mon, Nov 28, 2022 at 09:42:05AM +0100, Richard Biener wrote:
> > Since the function seems to be allowed to fail the patch looks
> > reasonable - still I wonder
> > what the "fallback" for a MODE_CC style compare-and-branch is? There
On Fri, 18 Nov 2022 09:01:08 PST (-0800), Palmer Dabbelt wrote:
On Thu, 17 Nov 2022 22:59:08 PST (-0800), Kito Cheng wrote:
Wait, what's Xgnuzihintpausestate???
I just made it up, it's defined right next to the name like those
profile extensions are. I figured that's the most RISC-V way to de
I forgot to add the patch but as you already made another feedback I'll
clean my patch first.
On 28/11/22 19:43, François Dumont wrote:
On 28/11/22 11:21, Jonathan Wakely wrote:
On Mon, 28 Nov 2022 at 10:10, Jonathan Wakely wrote:
On Mon, 28 Nov 2022 at 06:07, François Dumont via Li
On 28/11/22 11:21, Jonathan Wakely wrote:
On Mon, 28 Nov 2022 at 10:10, Jonathan Wakely wrote:
On Mon, 28 Nov 2022 at 06:07, François Dumont via Libstdc++
mailto:libstdc%2b...@gcc.gnu.org>> wrote:
This patch is fixing those tests:
20_util/to_chars/float128_c++23.cc
The following avoids ICEing for V2SI -> DImode vec_unpacks_lo.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/107896
* tree-vect-stmts.cc (supportable_widening_operation):
Handle non-vector mode intermediate mode.
---
gcc/tree-vect-stmts
On Mon, 28 Nov 2022 at 06:07, François Dumont via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> This patch is fixing those tests:
>
> 20_util/to_chars/float128_c++23.cc
> std/format/formatter/requirements.cc
> std/format/functions/format.cc
> std/format/functions/format_to_n.cc
> std/format/function
On 11/28/22 10:44, Maciej W. Rozycki wrote:
Your patch is probably still useful. I think Kito's only concern was to make
sure we don't have the ANDI instruction in addition to not having the SEXT
instruction. So still approved for trunk, just update the testcases to make
sure we don't hav
On Mon, 28 Nov 2022 08:44:16 PST (-0800), jeffreya...@gmail.com wrote:
On 11/28/22 07:14, juzhe.zh...@rivai.ai wrote:
From: Ju-Zhe Zhong
gcc/ChangeLog:
* config/riscv/riscv-protos.h (enum vlmul_type): New enum.
(get_vlmul): New function.
(get_ratio): Ditto.
On 28/11/22 14:39, Jonathan Wakely wrote:
On Mon, 28 Nov 2022 at 10:08, Jonathan Wakely wrote:
On Mon, 28 Nov 2022 at 10:06, Jonathan Wakely
wrote:
On Mon, 28 Nov 2022 at 06:02, François Dumont via Libstdc++
mailto:libstdc%2b...@gcc.gnu.org>> wrote:
On Mon, Nov 28, 2022 at 09:42:05AM +0100, Richard Biener wrote:
> Since the function seems to be allowed to fail the patch looks
> reasonable - still I wonder
> what the "fallback" for a MODE_CC style compare-and-branch is? There
> are callers
> of this function that do not seem to expect failure
On 9/16/22 07:52, Jason Merrill wrote:
On 6/24/22 01:23, Alexandre Oliva via Gcc-patches wrote:
On Jun 23, 2022, Alexandre Oliva wrote:
Here's the patch. Regstrapped on x86_64-linux-gnu, also tested with a
cross to aarch64-rtems6. Ok to install?
Introduce -nostdlib++ option
Uhh, I went
We produce inefficient code for some synthesized SImode conditional set
operations (i.e. ones that are not directly implemented in hardware) on
RV64. For example a piece of C code like this:
int
sleu (unsigned int x, unsigned int y)
{
return x <= y;
}
gets compiled (at `-O2') to this:
sleu:
On 1/26/22 04:11, Martin Liška wrote:
Hello.
Right now, switch lowering does not update basic_block::count values
so that they are uninitiliazed. Moreover, I've updated probability scaling
when a more complex expansion happens. There are still some situations
where
the profile is a bit impre
On 9/1/22 03:41, Даниил Александрович Фролов via Gcc-patches wrote:
Subject:
Re: -Wformat-overflow handling for %b and %B directives in C2X standard
From:
Даниил Александрович Фролов via Gcc-patches
Date:
9/1/22, 03:41
To:
Marek Polacek
CC:
"gcc-patches@gcc.gnu.org"
From eb9e8241d991450
On Mon, Nov 28, 2022 at 03:51:59PM +0800, Jiufu Guo wrote:
> Jiufu Guo via Gcc-patches writes:
> > Segher Boessenkool writes:
> >>> > + else
> >>> > + {
> >>> > + emit_move_insn (temp,
> >>> > + GEN_INT (((ud2 << 16) ^ 0x8000) -
> >>> > 0x8000))
Tested x86_64-linux, built on msp430-elf and h8300-elf. Pushed to trunk.
-- >8 --
For H8/300 with -msx -mn -mint32 the type of (_M_len - __pos) is int,
because int is wider than size_t so the operands are promoted.
libstdc++-v3/ChangeLog:
* include/std/string_view (basic_string_view::co
On 11/22/22 19:58, Jiufu Guo wrote:
Hi Jeff,
Thanks a lot for your comments!
Jeff Law writes:
On 11/20/22 20:07, Jiufu Guo wrote:
Jiufu Guo writes:
Hi,
As mentioned in the previous version patch:
https://gcc.gnu.org/pipermail/gcc-patches/2022-October/604646.html
The suboptimal code is
Tested x86_64-linux, built on msp430-elf and h8300-elf. Pushed to trunk.
-- >8 --
This fixes compilation failures for H8 multilibs. For the normal
multilib (ILP16L32?), the chunk struct does not have the expected size,
because uint32_t is type long and has alignment 4 (by default). This
forces si
Tested x86_64-linux, built on msp430-elf and h8300-elf. Pushed to trunk.
-- >8 --
For H8/300 size_t is 32 bits wide, but (unsigned char)buf[2] << 16
promotes to int which is only 16 bits wide. The shift is then undefined.
This fixes it by converting to size_t before shifting.
libstdc++-v3/Change
On 11/27/22 22:28, Fei Gao wrote:
In current riscv stack frame allocation, 2 steps are used. The first step
allocates memories at least for callee saved GPRs and FPRs, and the second step
allocates the rest if stack size is greater than signed 12-bit range. But it's
observed in some cases, l
On 11/28/22 06:59, Joakim Nohlgård wrote:
The check for HAVE_LD_RO_RW_SECTION_MIXING fails on targets where ld
does not support shared objects, even though the answer to the test
should be 'read-write'. One such target is riscv64-unknown-elf. Failing
this test results in a libgcc crtbegin.o whi
On 11/25/22 09:06, juzhe.zh...@rivai.ai wrote:
From: Ju-Zhe Zhong
gcc/ChangeLog:
* config/riscv/constraints.md (Wdm): New constraint.
* config/riscv/predicates.md (direct_broadcast_operand): New predicate.
* config/riscv/riscv-protos.h (RVV_VLMAX): New macro.
On 11/28/22 07:21, juzhe.zh...@rivai.ai wrote:
From: Ju-Zhe Zhong
Since mask instruction doesn't need policy, so remove it to make it look
reasonable.
gcc/ChangeLog:
* config/riscv/vector.md: Remove TA && MA operands.
Does this fix a known bug or is it just a cleanup? I think t
On 11/28/22 07:14, juzhe.zh...@rivai.ai wrote:
From: Ju-Zhe Zhong
gcc/ChangeLog:
* config/riscv/riscv-protos.h (enum vlmul_type): New enum.
(get_vlmul): New function.
(get_ratio): Ditto.
* config/riscv/riscv-v.cc (struct mode_vtype_group): New struct.
On 11/28/22 08:38, Maciej W. Rozycki wrote:
On Mon, 28 Nov 2022, Jeff Law wrote:
LGTM, but with a nit, I don't get set.w but get an andi like below, so
maybe we should also scan-assembler-not andi? feel free to commit that
directly with that fix
```asm
sleu:
sgtua0,a0,a1
Hi Richard,
On 25/11/2022 21:08, Richard Biener via Gcc-patches wrote:
>
>
> On Fri, 25 Nov 2022, Vaseeharan Vinayagamoorthy wrote:
>
> > Hi,
> >
> > I am seeing an internal compiler error, related to this patch:
>
> Can you please open a bugzilla for this and attach preprocessed
> source so
On 2022-11-28 12:21, Nathan Sidwell wrote:
On 11/25/22 14:03, Torbjorn SVENSSON wrote:
Hi,
Ping, https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606528.html
ok, thanks!
Pushed.
Kind regards,
Torbjörn
On 2022-11-17 14:20, Torbjörn SVENSSON wrote:
v1 -> v2:
Paths without "C:
Hi,
On Wed, Nov 16 2022, Jan Hubicka wrote:
>> IPA-CP transformation summary streaming code currently won't stream
>> out transformations necessary for clones which are only necessary for
>> materialization of other clones (such as an IPA-CP clone which is then
>> cloned again by IPA-SRA). Howeve
On 11/27/22 19:14, Feng Wang wrote:
From: wangfeng
There is no Immediate operand of ins "rol" accroding to the B-ext,
so the immediate operand should be loaded into register at first.
But we can convert it to the ins "rori" or "roriw", and then one
immediate load ins can be reduced.
Please r
scan-assembler-not sext\\.w
FAIL: gcc.target/riscv/sleu.c -O1 scan-assembler-not sext\\.w
FAIL: gcc.target/riscv/sleu.c -Og -g scan-assembler-not sext\\.w
when applied on top of:
$ riscv64-linux-gnu-gcc --version
riscv64-linux-gnu-gcc (GCC) 13.0.0 20221128 (experimental)
Not anymore with th
On Mon, 28 Nov 2022 at 15:20, Jonathan Wakely via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> Tested x86_64-linux. Pushed to trunk.
>
I didn't notice until my mailer flagged it that this commit has a non-ASCII
character. Fixed by the attached patch, pushed to trunk.
commit c775e2b81fca39f366040d4
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This means we don't need to use "(__8::)?" in dg-prune-output
directives.
libstdc++-v3/ChangeLog:
* testsuite/20_util/is_complete_or_unbounded/memoization_neg.cc:
Simplify dg-prune-output pattern.
* testsuite/lib/prune.exp (
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This implements the proposed resolution of LWG 3809, so that
std::subtract_with_carry_engine can be used with a 16-bit result_type.
Currently this produces a narrowing error when instantiating the
std::linear_congruential_engine to create the initial
On 11/25/22 07:07, Maciej W. Rozycki wrote:
Hi Kito,
On Fri, 12 Aug 2022, Maciej W. Rozycki wrote:
LGTM, but with a nit, I don't get set.w but get an andi like below, so
maybe we should also scan-assembler-not andi? feel free to commit that
directly with that fix
```asm
sleu:
sgtu
> "Joel" == Joel Brobecker via Gdb-patches
> writes:
Joel> ChangeLog:
Joel> * src-release.sh (GDB_SUPPORT_DIRS): Add libsframe.
Joel> Ok to apply to master?
Looks good to me.
I think we recently agreed that gdb and binutils maintainers can approve
patches like this... ?
thank
On 11/11/22 02:26, liuhongt via Gcc-patches wrote:
2 years ago, ARM folks support HWASAN[1] in GCC[2], and introduced several
target hooks(Many thanks to their work) so other backends can do similar
things if they have similar feature.
Intel LAM(linear Address Masking)[3 Charpter 14] suppor
From: Ju-Zhe Zhong
Since mask instruction doesn't need policy, so remove it to make it look
reasonable.
gcc/ChangeLog:
* config/riscv/vector.md: Remove TA && MA operands.
---
gcc/config/riscv/vector.md | 2 --
1 file changed, 2 deletions(-)
diff --git a/gcc/config/riscv/vector.md b/g
On Mon, Nov 28, 2022 at 11:37:34AM +0800, Jiufu Guo wrote:
> Segher Boessenkool writes:
> > On Fri, Nov 25, 2022 at 04:11:49PM +0800, Kewen.Lin wrote:
> >> on 2022/10/26 19:40, Jiufu Guo wrote:
> >> for "li/lis + oris/xoris", I interpreted it into four combinations:
> >>
> >>li + oris, lis +
From: Ju-Zhe Zhong
gcc/ChangeLog:
* config/riscv/riscv-protos.h (enum vlmul_type): New enum.
(get_vlmul): New function.
(get_ratio): Ditto.
* config/riscv/riscv-v.cc (struct mode_vtype_group): New struct.
(ENTRY): Adapt for attributes.
(enum vlmul_
When CPLUSPLUS_CPP_SPEC is set to a string literal it is not possible to
modify it through external spec files by renaming the original cpp spec
and replacing it because the compiler cpp_spec will still point to the
original, renamed cpp spec. Not defining CPLUSPLUS_CPP_SPEC makes gcc.cc
fall back
The check for HAVE_LD_RO_RW_SECTION_MIXING fails on targets where ld
does not support shared objects, even though the answer to the test
should be 'read-write'. One such target is riscv64-unknown-elf. Failing
this test results in a libgcc crtbegin.o which has a writable .eh_frame
section leading to
On Mon, 28 Nov 2022 at 10:08, Jonathan Wakely wrote:
>
>
> On Mon, 28 Nov 2022 at 10:06, Jonathan Wakely wrote:
>
>>
>>
>> On Mon, 28 Nov 2022 at 06:02, François Dumont via Libstdc++ <
>> libstd...@gcc.gnu.org> wrote:
>>
>>> libstdc++: [_GLIBCXX_INLINE_VERSION] Adapt dg error messages
>>>
>>> li
For __builtin_ia32_vec_set_v16qi (a, -1, 2) with
!flag_signed_char. it's transformed to
__builtin_ia32_vec_set_v16qi (_4, 255, 2) in the gimple,
and expanded to (const_int 255) in the rtl. But for immediate_operand,
it expects (const_int 255) to be signed extended to
(const_int -1). The mismatch ca
On 11/15/22 15:51, Andre Vieira (lists) wrote:
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.
From: Eric Botcazou
gcc/ada/
* libgnat/g-traceb.ads: Minor tweaks in the commentary.
(Executable_Load_Address): New function.
* doc/gnat_ugn/gnat_and_program_execution.rst (Non-Symbolic
Traceback): Adjust to PIE default on Linux.
(Symbolic Traceback): Like
From: Joel Brobecker
This commit adjust the sphinx configuration to use the "Read The Docs"
theme, which has the advantage of allowing the navigation bar
(containing among other things a search bar, and the TOC) to stay
fixed while scrolling the contents of the page being read. This is
particular
From: Eric Botcazou
gcc/ada/
* adaint.c [Linux]: Include .
(__gnat_get_executable_load_address) [Linux]: Enable.
Tested on x86_64-pc-linux-gnu, committed on master.
---
gcc/ada/adaint.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/gcc/ada/adaint.c
From: Claire Dross
So it can be used safely from SPARK code. The abstract state represents
the source code information that is accessed by the functions defined
in Source_Info. It is volatile as it is updated asyncronously when
moving in the code.
gcc/ada/
* libgnat/g-souinf.ads (Source
From: Eric Botcazou
The problem is that the regular expansion of the conversion around the
call to the subprogram is disabled by the expansion of the validity check
around the same call, as documented in Expand_Actuals:
-- This case is given higher priority because the subsequent check
--
From: Yannick Moy
SPARK RM 7.1.4(4) does not mandate anymore that a package with abstract
states has a completing body, unless the package state is mentioned in
Part_Of specifications. Implement that change.
gcc/ada/
* sem_prag.adb (Check_Part_Of_Abstract_State): Add verification
Hi,
please have a look at the patch below for a potential fix that addresses the
incorrect 'promotion'
of members found in temporaries within co_await statements.
To summarize my post in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99576#c5,
the recursive
promotion of temporaries is too eager a
Le 27/11/2022 à 21:32, Harald Anlauf via Fortran a écrit :
Dear Fortranners,
in dependency checking of arguments of elemental prodecures
we should treat dummy arguments with the value attribute as
implicitly having intent(in). This is simple and obvious.
The PR by Gerhard provides a series of
On Mon, 21 Nov 2022 at 14:37, Prathamesh Kulkarni
wrote:
>
> On Fri, 4 Nov 2022 at 14:00, Prathamesh Kulkarni
> wrote:
> >
> > On Mon, 31 Oct 2022 at 15:27, Richard Sandiford
> > wrote:
> > >
> > > Prathamesh Kulkarni writes:
> > > > On Wed, 26 Oct 2022 at 21:07, Richard Sandiford
> > > > wrot
On 11/25/22 14:03, Torbjorn SVENSSON wrote:
Hi,
Ping, https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606528.html
ok, thanks!
Kind regards,
Torbjörn
On 2022-11-17 14:20, Torbjörn SVENSSON wrote:
v1 -> v2:
Paths without "C:" part can still be absolute if they start with / or
\ on W
On Mon, 28 Nov 2022 at 10:10, Jonathan Wakely wrote:
>
>
> On Mon, 28 Nov 2022 at 06:07, François Dumont via Libstdc++ <
> libstd...@gcc.gnu.org> wrote:
>
>> This patch is fixing those tests:
>>
>> 20_util/to_chars/float128_c++23.cc
>> std/format/formatter/requirements.cc
>> std/format/functions/
This shows another case where trying to validate conversions during
the CHREC SCC analysis fails because said analysis assumes we are
converting a complete SCC. Like the constraint on the initial
conversion seen restrict all conversions handled to sign-changes.
Bootstrapped and tested on x86_64-u
1 - 100 of 114 matches
Mail list logo
