Currently we have 2 rounding mode enum:
/* Rounding mode bitfield for fixed point VXRM. */
enum vxrm_field_enum
{
VXRM_RNU,
VXRM_RNE,
VXRM_RDN,
VXRM_ROD
};
/* Rounding mode bitfield for floating point FRM. The value of enum comes
from the below link.
https://github.com/riscv/riscv-
Hi Alexandre,
On Apr 6, 2023, Bernhard Reutner-Fischer wrote:
29 For C_BOOL, the internal representation of .TRUE._C_BOOL and
.FALSE._C_BOOL shall be the same as those of
30 the C values (_Bool)1 and (_Bool)0 respectively.
I'm not changing any of the standard types, FWIW. The proposed
ext
There's no reason to constrain this to AVX512VL, unless instructed so by
-mprefer-vector-width=, as the wider operation is unusable for more
narrow operands only when the possible memory source is a non-broadcast
one. This way even the scalar copysign3 can benefit from the
operation being a single-
The input constraint for the %vmovddup alternative was wrong, as the
upper 16 XMM registers require AVX512VL to be used with this insn. To
compensate, introduce a new alternative permitting all 32 registers, by
broadcasting to the full 512 bits in that case if AVX512VL is not
available.
gcc/
On Aug 9, 2022, Alexandre Oliva wrote:
> Ping?
Ping? Refreshed, added setting of ENUM_UNDERLYING_TYPE, retested on
x86_64-linux-gnu (also on gcc-13).
Introduce hardbool attribute for C
This patch introduces hardened booleans in C. The hardbool attribute,
when attached to an integral type,
x86_64/i686/AArch64 has for a few months working std::bfloat16_t
support, __bf16 there is no longer a storage only type, but can
be used for arithmetics and is supported in libgcc and libstdc++.
The patch adds similar support for RISC-V. __bf16 has been merged
in psABI. The c
On 6/12/23 6:18 AM, P Jeevitha wrote:
> Bitwise xor performed on bool
> is similar to checking inequality. So changed to inequality
> operator (!=) instead of bitwise xor (^).
[snip'
> - if (swapped ^ !BYTES_BIG_ENDIAN
[snip]
> + if (swapped != !BYTES_BIG_ENDIAN
I know Andreas mentione
Hi,
Segher Boessenkool writes:
> On Thu, Jun 15, 2023 at 03:00:40PM +0800, Jiufu Guo wrote:
>> >> This is the existing pattern. It may be read as an action
>> >> to clean an unknown-size memory block.
>> >
>> > Including a size zero memory block, yes. BLKmode was originally to do
>> > th
The packing in vpacksswb/vpackssdw is not a simple concat, it's an
interweave from src1 and src2 for every 128 bit(or 64-bit for the
ss_truncate result).
.i.e.
dst[192-255] = ss_truncate (src2[128-255])
dst[128-191] = ss_truncate (src1[128-255])
dst[64-127] = ss_truncate (src2[0-127])
dst[0-63] =
packuswb/packusdw does unsigned saturation for signed source, but rtl
us_truncate means does unsigned saturation for unsigned source.
So for value -1, packuswb will produce 0, but us_truncate produces
255. The patch reimplement those related patterns and functions with
UNSPEC_US_TRUNCATE instead of
PR c/107583 notes that we weren't issuing a hint for
struct foo {
time_t mytime; /* missing include should trigger fixit */
};
in the C frontend.
The root cause is that one of the "unknown type name" diagnostics
was missing logic to emit hints, which this patch fixes.
Successfully boot
On Thu, 15 Jun 2023, Qing Zhao via Gcc-patches wrote:
> B. The argument of the new attribute “counted_by” is an identifier that can be
> accepted by “c_parser_attribute_arguments”:
>
> struct trailing_array_B {
> Int count;
> int array_B[] __attribute ((counted_by (count)));
> };
>
>
> From
Hi Uros,
> On the 7th June 2023, Uros Bizkak wrote:
> The register allocator considers the instruction-to-be-split as one
> instruction, so it
> can allocate output register to match an input register (or a register that
> forms an
> input address), So, you have to either add an early clobber t
On Mon, Jun 05, 2023 at 09:06:43PM -0600, Jeff Law wrote:
>
>
> On 6/5/23 10:18, Marek Polacek via Gcc-patches wrote:
> > Ping. Anyone have any further comments?
> Given this was approved before, but got reverted due to issues (which have
> since been addressed) -- I think you might as well go f
Rebased, retested, and applied to trunk. Thanks!
--Philipp.
On Thu, 8 Jun 2023 at 00:18, Jeff Law wrote:
>
>
>
> On 5/25/23 06:35, Manolis Tsamis wrote:
> > Propagation of the stack pointer in cprop_hardreg is currenty forbidden
> > in all cases, due to maybe_mode_change returning NULL. Relax t
> On Jun 15, 2023, at 12:55 PM, Joseph Myers wrote:
>
> On Thu, 15 Jun 2023, Qing Zhao via Gcc-patches wrote:
>
>> Comparing B with A, I don’t see too much benefit, either from
>> user-interface point of view, or from implementation point of view.
>>
>> For implementation, both A and B need
Since the combining of sin/cos into cexpi is depedent
on the target, this adds another testcase which had failed (earlier in
evpr rather than vrp2) that will fail on all targets rather than
ones which have sincos or C99 math functions.
Committed as obvious after a quick test.
gcc/testsuite/Change
The new target-independant implementation of fold-mem-offsets pass can
be found in the list (link is
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/621920.html)
Aside from now being target independent, I have fixed a number of new
bugs that emerged when running this on other targets and a min
This is a new RTL pass that tries to optimize memory offset calculations
by moving them from add immediate instructions to the memory loads/stores.
For example it can transform this:
addi t4,sp,16
add t2,a6,t4
shl t3,t2,1
ld a2,0(t3)
addi a2,1
sd a2,8(t2)
into the following (one
Add unary testcase of fp16 into zvfhmin-1.c (make sure they don't ICE and no
vectorize when -march=rv64gc_zvfhmin).
Make sure we won't do wrong in case of ZVFHMIN.
/* We can't enable FP16 NEG/PLUS/MINUS/MULT/DIV auto-vectorization when
-march="*zvfhmin*". */
/* { dg-final { scan-tree-dump-times
On Thu, 15 Jun 2023, Qing Zhao via Gcc-patches wrote:
> Comparing B with A, I don’t see too much benefit, either from
> user-interface point of view, or from implementation point of view.
>
> For implementation, both A and B need to search the fields of the
> containing structure by the name of
Hi Robin,
Looks good to me except for note that this seems to depend on a new
function: emit_vlmax_fp_insn which appears to be part of your autovec FP
binary operation. So that patch would need to be merged first from what
I can see.
On 6/15/23 11:12, Robin Dapp via Gcc-patches wrote:
Hi,
Robin,
Why do we need '-ffast-math' with the tests?
On 6/15/23 11:10, Robin Dapp via Gcc-patches wrote:
Hi,
changes from V1:
- Add VF_AUTO iterator and use it.
- Ensured we don't ICE with -march=rv64gcv_zfhmin.
this implements the floating-point autovec expanders for binary
operations: vf
On Thu, Jun 15, 2023 at 03:00:40PM +0800, Jiufu Guo wrote:
> >> This is the existing pattern. It may be read as an action
> >> to clean an unknown-size memory block.
> >
> > Including a size zero memory block, yes. BLKmode was originally to do
> > things like bcopy (before modern names like m
With the expanded capabilities of range-op dispatch, floating point
complex objects can appear when folding, whic they couldn't before. In
the processing for extracting integers from complex int's, make sure it
actually is an integer.
Bootstraps on x86_64-pc-linux-gnu. Regtesting currently un
> Am 15.06.2023 um 16:04 schrieb Andrew Stubbs :
>
> On 15/06/2023 15:00, Richard Biener wrote:
>>> On Thu, 15 Jun 2023, Andrew Stubbs wrote:
>>> On 15/06/2023 14:34, Richard Biener wrote:
On Thu, 15 Jun 2023, Andrew Stubbs wrote:
> On 15/06/2023 12:06, Richard Biener wrote:
>>>
Hi!
On 2023-06-15T17:15:54+0200, I wrote:
> On 2023-06-06T20:31:21+0100, Jonathan Wakely wrote:
>> On Tue, 6 Jun 2023 at 20:14, Thomas Schwinge wrote:
>>> This issue comes up in context of me working on C++ support for GCN and
>>> nvptx target. Those targets shall default to '-fno-exceptions' -
On Tue, 2023-06-13 at 11:24 +0800, Kewen.Lin wrote:
> Hi Carl,
>
> on 2023/5/31 04:41, Carl Love wrote:
> > GCC maintainers:
> >
> > The following patch fixes the first argument in the builtin
> > definition
> > and the corresponding test cases. Initially, the builtin
> > specification
> > was w
GCC maintainers:
Version 2, fixed various typos. Updated the change log body to say the
instruction counts were updated. The instruction counts changed as a
result of changing the first argument of the vec_replace_unaligned
builtin call from vector unsigned long long (vull) to vector unsigned
ch
On 6/15/23 09:30, Manolis Tsamis wrote:
On Thu, Jun 15, 2023 at 6:04 PM Jeff Law wrote:
On 5/25/23 07:42, Jeff Law wrote:
Thanks Manolis. Do you happen to know if this includes the fixes I
passed along to Philipp a few months back? My recollection is one fixed
stale DF data which prev
Hi!
On 2023-06-15T17:15:54+0200, I wrote:
> On 2023-06-06T20:31:21+0100, Jonathan Wakely wrote:
>> On Tue, 6 Jun 2023 at 20:14, Thomas Schwinge wrote:
>>> This issue comes up in context of me working on C++ support for GCN and
>>> nvptx target. Those targets shall default to '-fno-exceptions' -
On Thu, Jun 15, 2023 at 6:04 PM Jeff Law wrote:
>
>
>
> On 5/25/23 07:42, Jeff Law wrote:
>
> > Thanks Manolis. Do you happen to know if this includes the fixes I
> > passed along to Philipp a few months back? My recollection is one fixed
> > stale DF data which prevented an ICE during bootstrap
Hi!
On 2023-06-06T20:31:21+0100, Jonathan Wakely wrote:
> On Tue, 6 Jun 2023 at 20:14, Thomas Schwinge wrote:
>> This issue comes up in context of me working on C++ support for GCN and
>> nvptx target. Those targets shall default to '-fno-exceptions' -- or,
>> "in other words", '-fexceptions' i
Hi,
changes from V1:
- Use VF_AUTO iterator.
- Don't mention vfsqrt7.
This patch adds floating-point autovec expanders for vfneg, vfabs as well as
vfsqrt and the accompanying tests.
Similary to the binop tests, there are flavors for zvfh now.
gcc/ChangeLog:
* config/riscv/autovec.m
Hi,
changes from V1:
- Add VF_AUTO iterator and use it.
- Ensured we don't ICE with -march=rv64gcv_zfhmin.
this implements the floating-point autovec expanders for binary
operations: vfadd, vfsub, vfdiv, vfmul, vfmax, vfmin and adds
tests.
The existing tests are split up into non-_Float16 and
Hi, Joseph,
I studied c_parser_attribute_arguments and related source code,
and also studied PLACEHOLDER_EXPR and related source code.
Right now, I still cannot decide what’s the best user-interface should be for
the
argument of the new attribute “element_count". (Or the new attribute
name “
Hi,
Changes from v1:
- Revamped the target selectors again.
- Fixed some syntax as well as caching errors that were still present.
- Adjusted some test cases I missed.
The current situation with target selectors is improvable at best.
We definitely need to discern between being able to build a
On 5/25/23 07:42, Jeff Law wrote:
Thanks Manolis. Do you happen to know if this includes the fixes I
passed along to Philipp a few months back? My recollection is one fixed
stale DF data which prevented an ICE during bootstrapping, the other
needed to ignore debug insns in one or two plac
> Btw. I'm currently running the testsuite with rv64gcv_zfhmin
> default march and see some additional FAILs. Will report back.
Reporting back - the FAILs are a combination of an older qemu
version and not fully comprehensive target selectors. I'm going
to send a V2 for the testsuite patch as we
On 15/06/2023 15:00, Richard Biener wrote:
On Thu, 15 Jun 2023, Andrew Stubbs wrote:
On 15/06/2023 14:34, Richard Biener wrote:
On Thu, 15 Jun 2023, Andrew Stubbs wrote:
On 15/06/2023 12:06, Richard Biener wrote:
On Thu, 15 Jun 2023, Andrew Stubbs wrote:
On 15/06/2023 10:58, Richard Biene
On Thu, 15 Jun 2023, Andrew Stubbs wrote:
> On 15/06/2023 14:34, Richard Biener wrote:
> > On Thu, 15 Jun 2023, Andrew Stubbs wrote:
> >
> >> On 15/06/2023 12:06, Richard Biener wrote:
> >>> On Thu, 15 Jun 2023, Andrew Stubbs wrote:
> >>>
> On 15/06/2023 10:58, Richard Biener wrote:
> >
On 15/06/2023 14:34, Richard Biener wrote:
On Thu, 15 Jun 2023, Andrew Stubbs wrote:
On 15/06/2023 12:06, Richard Biener wrote:
On Thu, 15 Jun 2023, Andrew Stubbs wrote:
On 15/06/2023 10:58, Richard Biener wrote:
On Thu, 15 Jun 2023, Andrew Stubbs wrote:
On 14/06/2023 15:29, Richard Biene
On Thu, 15 Jun 2023, Andrew Stubbs wrote:
> On 15/06/2023 12:06, Richard Biener wrote:
> > On Thu, 15 Jun 2023, Andrew Stubbs wrote:
> >
> >> On 15/06/2023 10:58, Richard Biener wrote:
> >>> On Thu, 15 Jun 2023, Andrew Stubbs wrote:
> >>>
> On 14/06/2023 15:29, Richard Biener wrote:
> >
From: Ju-Zhe Zhong
This patch bootstrap pass on X86, ok for trunk ?
Accoding to comments from Richi, split the first patch to add ifn && optabs
of LEN_MASK_{LOAD,STORE} only, we don't apply them into vectorizer in this
patch. And also add BIAS argument for possible s390's future use.
The descri
On 15/06/2023 12:06, Richard Biener wrote:
On Thu, 15 Jun 2023, Andrew Stubbs wrote:
On 15/06/2023 10:58, Richard Biener wrote:
On Thu, 15 Jun 2023, Andrew Stubbs wrote:
On 14/06/2023 15:29, Richard Biener wrote:
Am 14.06.2023 um 16:27 schrieb Andrew Stubbs :
On 14/06/2023 12:54, Richa
On Thu, 15 Jun 2023, Richard Biener wrote:
> On Wed, 14 Jun 2023, Richard Sandiford wrote:
>
> > Richard Biener via Gcc-patches writes:
> > > This implemens fully masked vectorization or a masked epilog for
> > > AVX512 style masks which single themselves out by representing
> > > each lane with
This patch lets libstdc++ use new built-in trait __remove_pointer.
libstdc++-v3/ChangeLog:
* include/std/type_traits (remove_pointer): Use __remove_pointer
built-in trait.
Signed-off-by: Ken Matsui
---
libstdc++-v3/include/std/type_traits | 8 +++-
1 file changed, 7 insertions(+),
This patch implements built-in trait for std::remove_pointer.
gcc/cp/ChangeLog:
* cp-trait.def: Define __remove_pointer.
* semantics.cc (finish_trait_type): Handle CPTK_REMOVE_POINTER.
gcc/testsuite/ChangeLog:
* g++.dg/ext/has-builtin-1.C: Test existence of __remove_poin
On Wed, 14 Jun 2023, Richard Sandiford wrote:
> Richard Biener via Gcc-patches writes:
> > This implemens fully masked vectorization or a masked epilog for
> > AVX512 style masks which single themselves out by representing
> > each lane with a single bit and by using integer modes for the mask
>
> On 15 Jun 2023, at 12:54, David Malcolm wrote:
>
> On Thu, 2023-06-15 at 01:43 +0100, Sam James wrote:
>>
>> Eric Gallager via Gcc-patches writes:
>>
>>> On Wed, Jun 14, 2023 at 8:29 PM David Malcolm via Gcc-patches
>>> wrote:
PR c++/110164 notes that in cases where we have a
Some refactoring I thought would be useful while looking at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77576
I think some duplicated code can go away by doing this,
while also saving a bit of memory.
From c3f3b2fd53291805b5d0be19df6d1a348c5889ec Mon Sep 17 00:00:00 2001
From: Costas Argyris
Dat
On Thu, 2023-06-15 at 01:43 +0100, Sam James wrote:
>
> Eric Gallager via Gcc-patches writes:
>
> > On Wed, Jun 14, 2023 at 8:29 PM David Malcolm via Gcc-patches
> > wrote:
> > >
> > > PR c++/110164 notes that in cases where we have a forward decl
> > > of a std library type such as:
> > >
>
On 6/13/23 12:29, Jakub Jelinek wrote:
Hi!
As can be seen in the testcase, we don't diagnose #include/#include_next
of a non-existent header if __has_include/__has_include_next is done for
that header first.
The problem is that we normally error the first time some header is not
found, but in th
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 existing loop-doloop
mechanisms that are used for
On 6/14/23 09:31, Alex Coplan wrote:
Hi,
This is a v2 patch addressing feedback for:
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/621050.html
macOS SDK headers using the CF_ENUM macro can expand to invalid C++ code
of the form:
typedef enum T : BaseType T;
i.e. an elaborated-type-speci
On Thu, 15 Jun 2023, Robin Dapp wrote:
> > the minus in 'operand 2 - operand 3' should be a plus if the
> > bias is really zero or -1. I suppose
>
> Yes, that somehow got lost from when the bias was still +1. Maybe
> Juzhe can fix this in the course of his patch.
>
> > that's quite conservativ
On Thu, 15 Jun 2023, Andrew Stubbs wrote:
> On 15/06/2023 10:58, Richard Biener wrote:
> > On Thu, 15 Jun 2023, Andrew Stubbs wrote:
> >
> >> On 14/06/2023 15:29, Richard Biener wrote:
> >>>
> >>>
> Am 14.06.2023 um 16:27 schrieb Andrew Stubbs :
>
> On 14/06/2023 12:54, Richard Bi
Hi,
For those curious about the performance improvements of this patch, I
conducted a benchmark that instantiates 256k specializations of
is_object_v based on Patrick's code. You can find the benchmark code
at this link:
https://github.com/ken-matsui/gcc-benches/blob/main/is_object_benchmark.cc
On Thu, 15 Jun 2023, 01:49 Alexandre Oliva via Libstdc++, <
libstd...@gcc.gnu.org> wrote:
>
> rtems, like vxworks, uses fast-float doubles for from_chars even for
> long double, so it loses precision, so expect the long double bits to
> fail on aarch64.
>
> Regstrapped on x86_64-linux-gnu, also te
On Thu, 15 Jun 2023, 01:46 Alexandre Oliva via Libstdc++, <
libstd...@gcc.gnu.org> wrote:
>
> Contributing a patch by Joel Brobecker .
> Regstrapped on x86_64-linux-gnu just to be sure, also tested with
> aarch64-rtems6. I'm going to put this in later this week if there
> aren't any objections.
>
On 15/06/2023 10:58, Richard Biener wrote:
On Thu, 15 Jun 2023, Andrew Stubbs wrote:
On 14/06/2023 15:29, Richard Biener wrote:
Am 14.06.2023 um 16:27 schrieb Andrew Stubbs :
On 14/06/2023 12:54, Richard Biener via Gcc-patches wrote:
This implemens fully masked vectorization or a masked
> the minus in 'operand 2 - operand 3' should be a plus if the
> bias is really zero or -1. I suppose
Yes, that somehow got lost from when the bias was still +1. Maybe
Juzhe can fix this in the course of his patch.
> that's quite conservative. I think you can do better when the
> loads are ali
Hi, Richi. I have sent the first splitted patch (only add ifn and optabs) as
you suggested.
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/621874.html
Could you take a look at it?
After this patch is approved, I will send the second patch (Support them into
vectorizer) next.
Thanks!
juzh
From: Ju-Zhe Zhong
Accoding to comments from Richi, split the first patch to add ifn && optabs
of LEN_MASK_{LOAD,STORE} only, we don't apply them into vectorizer in this
patch. And also add BIAS argument for possible s390's future use.
The description of the patterns in doc are coming Robin.
Af
Andrew Stubbs writes:
> One
> comment: building a vector constant {0, 1, 2, 3, , 63} results in a
> very large entry in the constant pool and an unnecessary memory load (it
> literally has to use this sequence to generate the addresses to load the
> constant!) Generating the sequence via V
On Thu, 15 Jun 2023, Andrew Stubbs wrote:
> On 14/06/2023 15:29, Richard Biener wrote:
> >
> >
> >> Am 14.06.2023 um 16:27 schrieb Andrew Stubbs :
> >>
> >> On 14/06/2023 12:54, Richard Biener via Gcc-patches wrote:
> >>> This implemens fully masked vectorization or a masked epilog for
> >>> AV
> diff --git a/gcc/config/riscv/iterators.md b/gcc/config/riscv/iterators.md
> index 5b70ab20758..6349f032bc8 100644
> --- a/gcc/config/riscv/iterators.md
> +++ b/gcc/config/riscv/iterators.md
> @@ -61,10 +61,15 @@
> ;; Iterator for hardware-supported floating-point modes.
> (define_mode_iterator
On Thu, 15 Jun 2023, Robin Dapp wrote:
> > Meh, PoP is now behind a paywall, trying to get through ... I wonder
> > if there's a nice online html documenting the s390 len_load/store
> > instructions to better understand the need for the bias.
>
> https://publibfp.dhe.ibm.com/epubs/pdf/a227832c.pd
The mod-subtract optimization with ncounts==1 produced incorrect edge
probabilities due to incorrect conditional probability calculation. This
patch fixes the calculation.
gcc/ChangeLog:
* value-prof.cc (gimple_mod_subtract_transform): Correct edge
prob calculation.
Signed-off-
Hi Alex
> On 14 Jun 2023, at 14:31, Alex Coplan wrote:
>
> Hi,
>
> This is a v2 patch addressing feedback for:
> https://gcc.gnu.org/pipermail/gcc-patches/2023-June/621050.html
>
> macOS SDK headers using the CF_ENUM macro can expand to invalid C++ code
> of the form:
>
> typedef enum T : Bas
On 14/06/2023 15:29, Richard Biener wrote:
Am 14.06.2023 um 16:27 schrieb Andrew Stubbs :
On 14/06/2023 12:54, Richard Biener via Gcc-patches wrote:
This implemens fully masked vectorization or a masked epilog for
AVX512 style masks which single themselves out by representing
each lane with
On 13 June 2023 17:11:13 CEST, Martin Jambor wrote:
>Ping.
s/funtction/function/
s/runing/running/
>
>Thanks,
On 6/15/23 11:18, Robin Dapp wrote:
>> Meh, PoP is now behind a paywall, trying to get through ... I wonder
>> if there's a nice online html documenting the s390 len_load/store
>> instructions to better understand the need for the bias.
This is z16, but obviously no changes for vll/vstl:
https://p
> Meh, PoP is now behind a paywall, trying to get through ... I wonder
> if there's a nice online html documenting the s390 len_load/store
> instructions to better understand the need for the bias.
https://publibfp.dhe.ibm.com/epubs/pdf/a227832c.pdf
Look for vector load with length (store). The
On Thu, 15 Jun 2023, Robin Dapp wrote:
> >>> Can you try using the same wording for length and mask operands
> >>> as for len_load and maskload? Also len_load has the "bias"
> >>> operand which you omit here - IIRC that was added for s390 which
> >>> for unknown reason behaves a little different
On 2023-06-13 17:18, Jiufu Guo via Gcc-patches wrote:
Hi David,
Thanks for your valuable comments!
David Edelsohn writes:
...
Do you have any measurement of how expensive it is to test all of
these additional methods to generate a constant? How much does this
affect the
compile time?
Xuerui: I guess this makes it sensible to show "ret" instead of "jirl
$zero, $ra, 0" in objdump -d output, but I don't know how to implement
it. Do you have some idea?
On Thu, 2023-06-15 at 16:27 +0800, Lulu Cheng wrote:
> Pushed to trunk and gcc-12 gcc-13.
> r14-1866
> r13-7448
> r12-9698
>
> 在
Ok. I will add BIAS argument too for the convenience of possible s390 needed.
Even though we (RVV) don't really need it.
Thank. Will send a small patch V3 soon.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-06-15 16:58
To: juzhe.zh...@rivai.ai; rguenther
CC: rdapp.gcc; gcc-patches; richard.
>>> Can you try using the same wording for length and mask operands
>>> as for len_load and maskload? Also len_load has the "bias"
>>> operand which you omit here - IIRC that was added for s390 which
>>> for unknown reason behaves a little different than power. If
>>> len support for s390 ever ex
>> I don't know BIAS well and It seems to be a Power target dependent feature.
>>I think len_mask_* in general should only need lenght and mask operand.
>>Actually, the function argument is totally same as vp_load/vp_store in LLVM.
>>Could I just keep current format (without BIAS argument)? And ex
Hi, Richard.
Thanks for comments.
>>Can you try using the same wording for length and mask operands
>>as for len_load and maskload? Also len_load has the "bias"
>>operand which you omit here - IIRC that was added for s390 which
>>for unknown reason behaves a little different than power. If
>>le
On Thu, Jun 15, 2023 at 10:15 AM Jan Beulich wrote:
>
> On 15.06.2023 09:45, Hongtao Liu wrote:
> > On Thu, Jun 15, 2023 at 3:07 PM Uros Bizjak via Gcc-patches
> > wrote:
> >> On Thu, Jun 15, 2023 at 8:03 AM Jan Beulich via Gcc-patches
> >> wrote:
> >>> +case 3:
> >>> + return "%vmovddu
Pushed r14-1839.
On Thu, 2023-06-15 at 09:12 +0800, Lulu Cheng wrote:
> LGTM! Thanks!
>
> 在 2023/6/14 上午8:43, Xi Ruoyao 写道:
> > The LA464 micro-architecture is sensitive to alignment of code. The
> > Loongson team has benchmarked various combinations of function, the
> > results [1] show that 16
Pushed to trunk and gcc-12 gcc-13.
r14-1866
r13-7448
r12-9698
在 2023/6/15 上午9:30, Lulu Cheng 写道:
Micro-architecture unconditionally treats a "jr $ra" as "return from
subroutine",
hence doing "jr $ra" would interfere with both subroutine return prediction and
the more general indirect branch pre
Hi Juzhe,
I like the iterator solution better, I added it to the
binops V2 patch with a comment and will post it in a while.
Also realized there is already a testcase and the "enabled"
attribute is set properly now but I hadn't rebased to the
current master branch in a while...
Btw. I'm currentl
On 15.06.2023 09:45, Hongtao Liu wrote:
> On Thu, Jun 15, 2023 at 3:07 PM Uros Bizjak via Gcc-patches
> wrote:
>> On Thu, Jun 15, 2023 at 8:03 AM Jan Beulich via Gcc-patches
>> wrote:
>>> +case 3:
>>> + return "%vmovddup\t{%1, %0|%0, %1}";
>>> +case 4:
>>> + return "movlhps\t%0,
On Mon, 12 Jun 2023, juzhe.zh...@rivai.ai wrote:
> From: Ju-Zhe Zhong
>
> Target like ARM SVE in GCC has an elegant way to handle both loop control
> and flow control simultaneously:
>
> loop_control_mask = WHILE_ULT
> flow_control_mask = comparison
> control_mask = loop_control_mask & flow_con
From: Eric Botcazou
The special handling of temporaries created for return values and subject
to a renaming needs to be restricted to the top level, where it is needed
to prevent dangling references to the frame of the elaboration routine from
being created, because, at a lower level, the front-e
From: Ronan Desplanques
gcc/ada/
* doc/gnat_ugn/about_this_guide.rst: Fix typo. Uniformize punctuation.
* doc/gnat_ugn/the_gnat_compilation_model.rst: Uniformize punctuation.
Fix capitalization. Fix indentation of code block. Fix RST formatting
syntax errors.
From: Eric Botcazou
gcc/ada/
* gcc-interface/utils2.cc (build_binary_op) : Do not
remove a VIEW_CONVERT_EXPR on the LHS if it is also on the RHS.
Tested on x86_64-pc-linux-gnu, committed on master.
---
gcc/ada/gcc-interface/utils2.cc | 8 ++--
1 file changed, 6 insertions(
From: Yannick Moy
This rule was incompletely stated in SPARK RM and not checked.
This is now fixed.
gcc/ada/
* sem_attr.adb (Analyze_Attribute): Reject case of Loop_Entry
inside the prefix of Loop_Entry, as per SPARK RM 5.5.3.1(4,8).
Tested on x86_64-pc-linux-gnu, committed on
gcc/ada/ChangeLog:
* vxworks7-cert-rtp-base-link.spec: Removed.
* vxworks7-cert-rtp-base-link__ppc64.spec: Removed.
* vxworks7-cert-rtp-base-link__x86.spec: Removed.
* vxworks7-cert-rtp-base-link__x86_64.spec: Removed.
* vxworks7-cert-rtp-link.spec: Removed.
From: Eric Botcazou
The problem is that the condition of the iterator filter is expanded early,
before it is integrated into an if statement of the loop body, so there is
no place to attach the actions generated by this expansion.
This happens only for simple loops, i.e. with a parameter specifi
From: Eric Botcazou
The Condition_Actions field can only be populated for while loops.
gcc/ada/
* exp_ch5.adb (Expand_Iterator_Loop_Over_Container): Do not insert
an always empty list. Remove unused parameter Isc.
(Expand_Iterator_Loop): Adjust call to above procedure.
From: Eric Botcazou
The previous fix did not address a latent issue whereby the allocation
would be made using the (static) subtype of the conversion instead of
the (dynamic) subtype of the return object, so this change rewrites the
code responsible for determining the type used for the allocatio
From: Ronan Desplanques
This patch removes a few dangling references to the late front-end
implementation of exceptions from the comments of targparm.ads, and
also fixes a thinko there.
gcc/ada/
* targparm.ads: Remove references to front-end-based exceptions. Fix
thinko.
Tested
From: Eric Botcazou
The issue is that, if an aggregate is both below a conditional expression
and above another conditional expression in the tree, we have currently no
place to put the finalization actions generated by the innermost expression
in the context of the aggregate before it is expande
From: Johannes Kliemann
The Ada priority range of the QNX runtime started from 0, differing from
the QNX system priorities range starting from 1. As this may cause
confusion, especially if used in a mixed language environment, the Ada
priority range now starts at 1.
The default priority of Ada t
From: Eric Botcazou
This restores the specific treatment of aggregates that are returned through
an extended return statement in a function returning a class-wide type, and
which was incorrectly dropped in an earlier change.
gcc/ada/
* exp_ch3.adb (Make_Allocator_For_Return): Deal again
From: Piotr Trojanek
The recently added aspect Always_Terminates is allowed on both
procedures and entries.
gcc/ada/
* sem_prag.adb (Analyze_Pragma): Accept pragma Always_Terminates when
it applies to an entry.
Tested on x86_64-pc-linux-gnu, committed on master.
---
gcc/ada/s
1 - 100 of 121 matches
Mail list logo
