[PATCH 5/5] Support IEEE 128-bit overload test data built-in functions.
This patch adds support for overloading the IEEE 128-bit test data and
test data negate built-in functions bewteeen KFmode and TFmode arguments.
I have tested these patches on a power10 that is running Fedora 36, which
[PATCH 4/5] Support IEEE 128-bit overload extract and insert built-in functions.
This patch adds support for overloading the IEEE 128-bit extract and
insert built-in functions bewteeen KFmode and TFmode arguments.
I have tested these patches on a power10 that is running Fedora 36, which
defaults
PATCH 3/5] Support IEEE 128-bit overload comparison built-in functions.
This patch adds support for overloading the IEEE 128-bit comparison
built-in functions bewteeen KFmode and TFmode arguments.
I have tested these patches on a power10 that is running Fedora 36, which
defaults to using long
[PATCH 2/5] Support IEEE 128-bit overload round_to_odd built-in functions.
This patch adds support for overloading the IEEE 128-bit round to odd
built-in functions bewteeen KFmode and TFmode arguments.
I have tested these patches on a power10 that is running Fedora 36, which
defaults to using
[PATCH 1/5] IEEE 128-bit built-in overload support.
This patch lays the ground work that future patches will use to add
builtin support (both normal and overloaded) for the case where long
double uses the IEEE 128-bit encoding.
This adds a new stanza (ieee128-hw-ld) for when we have IEEE 128-bit
The following patches add support for doing built-in function overloading
between the two 128-bit IEEE types (i.e. _Float182/__float128 using KFmode and
when long double uses the IEEE 128-bit encoding with TFmode).
These patches lay the foundation for a set of follow-on patches that will
change
This patch adds the additional options on RISC-V target.
"-fprefetch-loop-arrays" option needs enable prefetch instruction,
for RISC-V that contained in "zicbop" extension.
Use "-march" with "zicbop" will enable this feature.
gcc/testsuite/ChangeLog:
* gcc.dg/pr106397.c: New
在 2022/7/26 下午8:01, Xi Ruoyao 写道:
On Tue, 2022-07-26 at 19:42 +0800, Lulu Cheng wrote:
在 2022/7/26 下午5:44, Xi Ruoyao 写道:
Should we indicate that our .eh_frame section format has changed?
I don't really understand C++ exception handling, so: does the change
breaks something? For example,
We already have a warning that warns about pessimizing std::move
in a return statement, when it prevents the NRVO:
T fn()
{
T t;
return std::move (t); // warning \o/
}
However, the warning doesn't warn when what we are returning is a class
prvalue, that is, when std::move prevents
On Mon, 25 Jul 2022, Tom Honermann via Gcc-patches wrote:
> This change provides new tests for the core language and compiler
> dependent library changes adopted for C2X via WG14 N2653.
I'd expect this patch also to add tests verifying that u8"" strings have
the old type for C11 (unless there
On Mon, 25 Jul 2022, Tom Honermann via Gcc-patches wrote:
> diff --git a/gcc/ginclude/stdatomic.h b/gcc/ginclude/stdatomic.h
> index bfcfdf664c7..75ed7965689 100644
> --- a/gcc/ginclude/stdatomic.h
> +++ b/gcc/ginclude/stdatomic.h
> @@ -49,6 +49,10 @@ typedef _Atomic long atomic_long;
> typedef
On Sun, 24 Jul 2022, Tom Honermann via Gcc-patches wrote:
> Gcc's '#pragma GCC diagnostic' directives are processed in "early mode"
> (see handle_pragma_diagnostic_early) for the C++ frontend and, as such,
> require that the target diagnostic option be enabled for the preprocessor
> (see
On Tue, 19 Jul 2022, Maciej W. Rozycki wrote:
> Our documentation indicates that it is the `-frounding-math' invocation
> option that controls whether we respect what the FENV_ACCESS pragma
> would imply, should we implement it, regarding the floating point
> environment. It is only a part of
On Tue, Jul 19, 2022 at 02:09:46PM +, Qing Zhao wrote:
> [...]
> diff --git a/gcc/c-family/c-attribs.cc b/gcc/c-family/c-attribs.cc
> index c8d96723f4c..10d16532f0d 100644
> --- a/gcc/c-family/c-attribs.cc
> +++ b/gcc/c-family/c-attribs.cc
> @@ -101,6 +101,8 @@ static tree
I've backported the following patches to the releases/gcc-12 branch:
r12-8631-g1321183a13540b:
"analyzer: add .fpath.txt dumps to -fdump-analyzer-feasibility"
from r13-6-gd8586b00dd00a1783862da5f0c8811a740400074
r12-8632-g05530fcea07a9e:
"analyzer: handle repeated accesses after init of
Hi!
On Wed, Jul 27, 2022 at 02:42:25PM +0100, Roger Sayle wrote:
> This patch implements some additional zero-extension and sign-extension
> related optimizations in simplify-rtx.cc. The original motivation comes
> from PR rtl-optimization/71775, where in comment #2 Andrew Pinski sees:
>
>
> _Complex int are strange beasts, I'd simply avoid the transform for them.
>
>
I added to the match.pd rule to not simplify if the operands are complex.
There is now a test case for complex types to make sure they do not
simplify. I had to move the "dg-do run" test to g++.dg to accommodate the
On 7/27/22 21:45, Harald Anlauf via Fortran wrote:
Hi Mikael,
Am 26.07.22 um 21:25 schrieb Mikael Morin:
Le 25/07/2022 à 22:18, Harald Anlauf a écrit :
I would normally trust NAG more than Intel and Cray.
… and yourself, it seems. Too bad.
May I suggest that, if well known Fortran
Hi Mikael,
Am 26.07.22 um 21:25 schrieb Mikael Morin:
Le 25/07/2022 à 22:18, Harald Anlauf a écrit :
I would normally trust NAG more than Intel and Cray.
… and yourself, it seems. Too bad.
If somebody else convinces me to accept that NAG has it wrong this
time, I would be happy to proceed.
On Wed, Jul 27, 2022 at 08:51:58AM +0100, Roger Sayle wrote:
> > They can be, as clearly documented (and obvious from the code), but you
> can
> > not ever have that in the RTL stream, which is needed for your patch to do
> > anything.
>
> That's the misunderstanding; neither this nor the
On 7/12/22 08:13, Jose E. Marchesi via Gcc-patches wrote:
>
> The kernel bpftool expects BTF_KIND_FUNC entries in BTF to include an
> annotation reflecting the linkage of functions (static, global). For
> whatever reason they abuse the `vlen' field of the BTF_KIND_FUNC entry
> instead of
I merged trunk revision 5eb9f117a361538834b9740d59219911680717d1 to
the gccgo branch.
Ian
ChangeLog:
* MAINTAINERS: Add myself as reviewer for CTF and BTF.
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 7408396471f..1a37f4419b9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -267,6 +267,7 @@ arc port
On Mon, 11 Jul 2022, Lewis Hyatt via Gcc-patches wrote:
> Hello-
>
> As discussed here:
> https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598136.html
>
> Here is another short patch that improves "#pragma GCC diagnostic" handling.
> Longer term, it will be desirable to make the handling of
On Wed, 2022-07-27 at 14:40 +0100, herron.philip--- via Gcc-patches
wrote:
> This is the initial version 1 patch set for the Rust front-end. There
> are more changes that need to be extracted out for all the target
> hooks we have implemented. The goal is to see if we are implementing
> the target
Hi Tom!
Ping.
Grüße
Thomas
On 2022-07-20T14:46:03+0200, I wrote:
> Hi Tom!
>
> Ping.
>
>
> Grüße
> Thomas
>
>
> On 2022-07-13T10:42:44+0200, I wrote:
>> Hi Tom!
>>
>> Ping.
>>
>>
>> Grüße
>> Thomas
>>
>>
>> On 2022-07-05T16:59:23+0200, I wrote:
>>> Hi Tom!
>>>
>>> Ping.
>>>
>>>
>>> Grüße
Hi Tom!
Ping.
Grüße
Thomas
On 2022-07-20T14:44:36+0200, I wrote:
> Hi Tom!
>
> Ping.
>
>
> Grüße
> Thomas
>
>
> On 2022-07-13T10:41:23+0200, I wrote:
>> Hi Tom!
>>
>> Ping.
>>
>>
>> Grüße
>> Thomas
>>
>>
>> On 2022-07-05T16:58:54+0200, I wrote:
>>> Hi Tom!
>>>
>>> Ping.
>>>
>>>
>>> Grüße
On Thu, Jul 21, 2022 at 11:53 AM H.J. Lu wrote:
>
> We can't always use the PLT entry as the function address for local IFUNC
> functions. When the PIC register is needed for PLT call, indirect call
> via the PLT entry will fail since the PIC register may not be set up
> properly for indirect
On Tue, Jul 26, 2022 at 10:14 PM Alexandre Oliva wrote:
>
>
> g++.dg/ext/attr-ifunc-3.C and gcc.target/i386/mvc10.c, not changed,
> have made it clear that there were problems in the optimizations to
> use @GOTOFF to refer to locally-bound ifuncs. GNU ld as recently as
> May 2018 would reject
On Fri, Jul 1, 2022 at 8:31 AM Uros Bizjak wrote:
>
> On Thu, Jun 30, 2022 at 4:50 PM H.J. Lu wrote:
> >
> > 1. Add a predicate for constant vectors which can be converted to integer
> > constants suitable for constant integer stores. For a 8-byte constant
> > vector, the converted 64-bit
This reference has been wrong since 2007; committed as an obvious fix.
gcc/ChangeLog:
* doc/loop.texi: Refer to LOOPS_HAVE_RECORDED_EXITS instead.
diff --git a/gcc/doc/loop.texi b/gcc/doc/loop.texi
index
d7b71a24dbfed284b13da702bd5037691a515535..6e8657a074d2447db7ae9b75cbfbb71282b84287
On 27/07/2022 14:40, herron.philip--- via Gcc-patches wrote:
From: Philip Herron
This adds the nessecary target hooks for the arm target.
gcc/ChangeLog:
* config.gcc: add rust_target_objs for arm
gcc/config/arm/ChangeLog:
* arm-protos.h: define arm_rust_target_cpu_info
This patch implements some additional zero-extension and sign-extension
related optimizations in simplify-rtx.cc. The original motivation comes
from PR rtl-optimization/71775, where in comment #2 Andrew Pinski sees:
Failed to match this instruction:
(set (reg:DI 88 [ _1 ])
(sign_extend:DI
From: Philip Herron
This patch introduces a new set of interfaces to define the target info as
expected by the rust front-end. It takes advantage of the information
within gcc/config/target directories which gets called by the front-end
to populate rust front-end datastructures by calling into:
From: Philip Herron
This adds the nessecary target hooks for the arm target.
gcc/ChangeLog:
* config.gcc: add rust_target_objs for arm
gcc/config/arm/ChangeLog:
* arm-protos.h: define arm_rust_target_cpu_info
* arm-rust.cc: new file to generate info
* arm.h:
From: Philip Herron
This is a skeleton front-end which is used so we can ensure each patch is
buildable:
gcc/rust/ChangeLog:
* Make-lang.in
* config-lang.in
* lang-specs.h
* lang.opt
* rust-lang.cc
* rustspec.cc
---
gcc/rust/Make-lang.in | 308
This is the initial version 1 patch set for the Rust front-end. There are more
changes that need to be extracted out for all the target hooks we have
implemented. The goal is to see if we are implementing the target hooks
information for x86 and arm. We have more patches for the other targets I
Thank you for your reply. I am gonna try another to implement the fractional
vector spilling of RVV in RISC-V backend.
If this patch is really having a bad impact on other targets. I think this
patch may needs to be abandon.
juzhe.zh...@rivai.ai
From: Richard Sandiford
Date: 2022-07-27
On Wed, 2022-07-27 at 17:57 +0800, WANG Xuerui wrote:
> On 2022/7/27 17:28, Lulu Cheng wrote:
> >
> >
> > 在 2022/7/27 下午5:15, Xi Ruoyao 写道:
> > > On Wed, 2022-07-27 at 16:47 +0800, Lulu Cheng wrote:
> > >
> > > > > "Use or do not use assembler relocation operators when dealing with
> > > > >
After consideration. Maybe I can try another solution. I aggree with you that
it is not good idea that fake the BYTESIZE of vint8mf2_t and let GCC think it
is a full vector. I think the best way is let GCC understand the real size of
'vint8mf2_t' as a half of a vector and then RISC-V backend
Dimitrije Milosevic writes:
>> Do you know someone very familiar with MIPS and GCC and capable as a
>> port maintainer? An active MIPS port maintainer will make the situation
>> better.
> Sadly, no. I agree it would make things easier.
Yeah, I agree that's what we need. I stepped down from
On Wed, 27 Jul 2022, juzhe.zh...@rivai.ai wrote:
> For vint8m1_t:
>VECTOR_MODES_WITH_PREFIX (VNx, INT, 16, 0)
> ADJUST_NUNITS (VNx16QI, riscv_vector_chunks * 8);
> ADJUST_BYTES (VNx16QI, riscv_vector_chunks * 8);
> For vint8mf2_t:
>VECTOR_MODES_WITH_PREFIX (VNx, INT, 8, 0)
>
Richard Biener writes:
> On Wed, 27 Jul 2022, juzhe.zh...@rivai.ai wrote:
>
>> From: zhongjuzhe
>>
>> gcc/ChangeLog:
>>
>> * expr.cc (expand_assignment): Change GET_MODE_PRECISION to
>> GET_MODE_BITSIZE
>>
>> ---
>> gcc/expr.cc | 2 +-
>> 1 file changed, 1 insertion(+), 1
Ping
في الاثنين، ٤ يوليو، ٢٠٢٢ ١٠:٣٤ م Ahmed Sayed Mousse <
ahmedsayedmou...@gmail.com> كتب:
> *This patch is the initial implementation of OpenMP-API specs book section
> **20.5.5 with title "Thread Handles".*
>
> *I have fixed the first version after revising the notes on it.*
>
>
Hi all,
On 05.05.22 11:12, Jakub Jelinek via Gcc-patches wrote:
→ https://gcc.gnu.org/pipermail/gcc-patches/2022-May/594082.html
On Wed, Mar 09, 2022 at 07:04:24PM +0800, Chung-Lin Tang wrote:
→ https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591449.html
Now in OpenMP 5.x, static members
On Tue, 26 Jul 2022, Andre Vieira (lists) wrote:
> Hi,
>
> This is a RFC for my prototype for bitfield read vectorization. This patch
> enables bit-field read vectorization by removing the rejection of bit-field
> read's during DR analysis and by adding two vect patterns. The first one
>
On Wed, Jul 27, 2022 at 06:41:09AM +, Richard Biener via Gcc-patches wrote:
> On Tue, 26 Jul 2022, Marek Polacek wrote:
>
> > Since r11-5188-g32934a4f45a721, we drop qualifiers during l-to-r
> > conversion by creating a NOP_EXPR. For e.g.
> >
> > const int i = i;
> >
> > that means that
On Wed, 27 Jul 2022, Tamar Christina wrote:
> > -Original Message-
> > From: Richard Biener
> > Sent: Tuesday, July 12, 2022 2:19 PM
> > To: Tamar Christina
> > Cc: gcc-patches@gcc.gnu.org; nd ; ja...@redhat.com
> > Subject: RE: [PATCH 2/2]middle-end: Support recognition of three-way
>
Summary: __register_frame and the corresponding _Unwind_Find_FDE use a
global mutex for frame registration and unwinding. This can lead to very
poor performance on machines with high core counts. This patch organizes
the frames in a b-tree with read-optimized synchronization instead,
which
On Wed, 27 Jul 2022, Jakub Jelinek wrote:
> On Wed, Jul 27, 2022 at 10:09:34AM +, Richard Biener wrote:
> > > We chose to sanitize not just explicit user __builtin_unreachable calls,
> > > but also the internally generated __builtin_unreachable calls (with the
> > > one exception of fall
> -Original Message-
> From: Richard Biener
> Sent: Tuesday, July 12, 2022 2:19 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; ja...@redhat.com
> Subject: RE: [PATCH 2/2]middle-end: Support recognition of three-way
> max/min.
>
> On Tue, 5 Jul 2022, Tamar Christina wrote:
Hi Maciej:
I am convinced that is OK for now, I agree modeling fflags would be a
rabbit hole, I tried to build a full GNU toolchain with my quick patch
and saw many ICE during build libraries, that definitely should be a
long-term optimization project.
Although I'm thinking if we should default
On Wed, 27 Jul 2022, Kito Cheng wrote:
> Ooops, thanks for fixing that, the change was gotten from kernel
> folks. I assume they have already used that for a while, but it's
> really weird no bug report from those guys...
>
> OK for trunk and backport for release branch.
Change now committed
On Thu, 21 Jul 2022, Kito Cheng wrote:
> LGTM, thanks for modeling this in cost model!
Patch applied now, thank you for your review.
Maciej
On Wed, Jul 27, 2022 at 10:09:34AM +, Richard Biener wrote:
> > We chose to sanitize not just explicit user __builtin_unreachable calls,
> > but also the internally generated __builtin_unreachable calls (with the
> > one exception of fall through to end of C++ function returning non-void,
> >
Status
==
The gcc-12 branch is open for regression and documentation fixes.
It is time for a GCC 12.2 release, we are comparatively late with it
already. The plan is to create a GCC 12.2 release candidate on
August 12th which should give plenty of time to backport or implement
important
Hi!
These tests fail on ia32, because we get -Wpsabi warnings.
Fixed by adding -Wno-psabi. The pr94920.C test still fails the
ABS_EXPR scan-tree-dump though, I think we'll need to add vect
options and use vect_int effective target or something similar.
2022-07-27 Jakub Jelinek
PR
On Wed, 27 Jul 2022, Jakub Jelinek wrote:
> On Wed, Jul 27, 2022 at 09:33:47AM +, Richard Biener wrote:
> > > __builtin_unreachable and __ubsan_handle_builtin_unreachable don't
> > > use vops, they are marked const/leaf/noreturn/nothrow/cold.
> > > But __builtin_trap uses vops, isn't const,
Hi!
-fprefetch-loop-arrays isn't supported on ia32 with just -march=i386 and
similar, the following patch adds extra options similar testcases use.
2022-07-27 Jakub Jelinek
PR tree-optimization/106397
* gcc.dg/pr106397.c: For ia32, add dg-additional-options
On 2022/7/27 17:28, Lulu Cheng wrote:
在 2022/7/27 下午5:15, Xi Ruoyao 写道:
On Wed, 2022-07-27 at 16:47 +0800, Lulu Cheng wrote:
"Use or do not use assembler relocation operators when dealing with
symbolic addresses. The alternative is to use assembler macros
instead, which may limit
On Wed, Jul 27, 2022 at 09:33:47AM +, Richard Biener wrote:
> > __builtin_unreachable and __ubsan_handle_builtin_unreachable don't
> > use vops, they are marked const/leaf/noreturn/nothrow/cold.
> > But __builtin_trap uses vops, isn't const, just leaf/noreturn/nothrow/cold.
> > This is I
I've made the mistake of cut the bouncing address at least
twice.
Pushed.
* MAINTAINERS (Roger Sayle): Update e-mail address.
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 46c9e48a497..7408396471f 100644
---
On Wed, 27 Jul 2022, Jakub Jelinek wrote:
> Hi!
>
> When -dx option is used (didn't know we have it and no idea what is it
> useful for), we just expand functions to RTL and then omit all further
> RTL passes, so the normal functions aren't actually emitted into assembly,
> just variables.
> The
Hi!
When -dx option is used (didn't know we have it and no idea what is it
useful for), we just expand functions to RTL and then omit all further
RTL passes, so the normal functions aren't actually emitted into assembly,
just variables.
The following testcase ICEs, because we don't emit the
Hi Joseph:
On Wed, Jul 27, 2022 at 5:42 AM Joseph Myers wrote:
>
> On Thu, 7 Jul 2022, Kito Cheng wrote:
>
> > +/* Implement TARGET_MANGLE_TYPE. */
> > +
> > +static const char *
> > +riscv_mangle_type (const_tree type)
> > +{
> > + /* Half-precision float. */
> > + if (TREE_CODE (type) ==
On Wed, 27 Jul 2022, Jakub Jelinek wrote:
> Hi!
>
> __builtin_unreachable and __ubsan_handle_builtin_unreachable don't
> use vops, they are marked const/leaf/noreturn/nothrow/cold.
> But __builtin_trap uses vops, isn't const, just leaf/noreturn/nothrow/cold.
> This is I believe so that when
Hi!
The following patch is partially a workaround for bogus warnings
when the compiler isn't able to fold _M_disjunct call into constant
false, but also an optimization attempt - assuming _M_disjunct (__s)
is rare, the patch should shrink code size for the common case and
use library or for
在 2022/7/27 下午5:15, Xi Ruoyao 写道:
On Wed, 2022-07-27 at 16:47 +0800, Lulu Cheng wrote:
"Use or do not use assembler relocation operators when dealing with
symbolic addresses. The alternative is to use assembler macros
instead, which may limit optimization.
The default value for the
Hi!
__builtin_unreachable and __ubsan_handle_builtin_unreachable don't
use vops, they are marked const/leaf/noreturn/nothrow/cold.
But __builtin_trap uses vops, isn't const, just leaf/noreturn/nothrow/cold.
This is I believe so that when users explicitly use __builtin_trap in their
sources they
On Wed, 27 Jul 2022, Jakub Jelinek wrote:
> Hi!
>
> This function would have UB if called with empty candidates vector
> (accessing p[-1] where p is malloc (0) result).
> As analyzed in the PR, we never call it with empty vector, so this just
> adds an assertion to make it clear.
>
>
Hi!
This function would have UB if called with empty candidates vector
(accessing p[-1] where p is malloc (0) result).
As analyzed in the PR, we never call it with empty vector, so this just
adds an assertion to make it clear.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
On Wed, 2022-07-27 at 16:47 +0800, Lulu Cheng wrote:
> > "Use or do not use assembler relocation operators when dealing with
> > symbolic addresses. The alternative is to use assembler macros
> > instead, which may limit optimization.
> >
> > The default value for the option is determined
On Tue, Jul 05, 2022 at 04:44:41PM -0400, Jason Merrill wrote:
> But preeval should always be true, so we'd never reach the new handling in
> the if (!preeval) block. Certainly the new testcase doesn't exercise this
> code.
Ok, changed now.
I had to keep the ctors[i] = valp; statement in the
在 2022/7/27 下午3:21, WANG Xuerui 写道:
Hi,
On 2022/7/27 15:06, Xi Ruoyao wrote:
Document newly introduced -m[no-]explicit-relocs options. Ok for trunk?
-- >8 --
gcc/ChangeLog:
* doc/invoke.texi: Document -m[no-]explicit-relocs for
LoongArch.
---
gcc/doc/invoke.texi | 12
On Tue, Jul 26, 2022 at 4:32 PM Sam Feifer via Gcc-patches
wrote:
>
> >
> > int f(_Complex int x, _Complex int y)
> > {
> > return x == x / y * y;
> > }
> >
>
> After some research about mod with complex types, I found that the binary
> mod operation does not work with complex types. If so, the
For vint8m1_t:
VECTOR_MODES_WITH_PREFIX (VNx, INT, 16, 0)
ADJUST_NUNITS (VNx16QI, riscv_vector_chunks * 8);
ADJUST_BYTES (VNx16QI, riscv_vector_chunks * 8);
For vint8mf2_t:
VECTOR_MODES_WITH_PREFIX (VNx, INT, 8, 0)
ADJUST_NUNITS (VNx8QI, riscv_vector_chunks * 4);
ADJUST_BYTES (VNx16QI,
On Wed, 27 Jul 2022, juzhe.zh...@rivai.ai wrote:
> Let's take look at these 2 cases: https://godbolt.org/z/zP16frPnb. In
> RVV, we have vle8 and vsetvli to specify loading vint8mf2 (vsetvli a1,
> zero + vle8.v). You can see it in foo function. In this case we don't
> need to confuse compiler
Let's take look at these 2 cases: https://godbolt.org/z/zP16frPnb.
In RVV, we have vle8 and vsetvli to specify loading vint8mf2 (vsetvli a1, zero
+ vle8.v). You can see it in foo function. In this case we don't need to
confuse compiler the size of vint8mf2.
However, The second case is I write
Hi Segher,
> Thank you for telling the maintainer of combine the basics of what all of
this
> does! I hadn't noticed any of that before.
You're welcome. I've also been maintaining combine for some time now:
https://gcc.gnu.org/legacy-ml/gcc/2003-10/msg00455.html
> They can be, as clearly
On Wed, 27 Jul 2022, juzhe.zh...@rivai.ai wrote:
> Thank you so much for the fast reply. Ok, it is true that I didn't think
> about it carefully. Can you help me with the following the issue?
>
> For RVV (RISC-V 'V' Extension), we have full vector type 'vint8m1_t' (LMUL =
> 1) and fractional
Hi,
On 2022/7/27 15:06, Xi Ruoyao wrote:
Document newly introduced -m[no-]explicit-relocs options. Ok for trunk?
-- >8 --
gcc/ChangeLog:
* doc/invoke.texi: Document -m[no-]explicit-relocs for
LoongArch.
---
gcc/doc/invoke.texi | 12
1 file changed, 12
Thank you so much for the fast reply. Ok, it is true that I didn't think about
it carefully. Can you help me with the following the issue?
For RVV (RISC-V 'V' Extension), we have full vector type 'vint8m1_t' (LMUL = 1)
and fractional vector type 'vint8mf2_t' (LMUL = 1/2).
Because in the ISA, we
Document newly introduced -m[no-]explicit-relocs options. Ok for trunk?
-- >8 --
gcc/ChangeLog:
* doc/invoke.texi: Document -m[no-]explicit-relocs for
LoongArch.
---
gcc/doc/invoke.texi | 12
1 file changed, 12 insertions(+)
diff --git a/gcc/doc/invoke.texi
> Do you know someone very familiar with MIPS and GCC and capable as a
> port maintainer? An active MIPS port maintainer will make the situation
> better.
Sadly, no. I agree it would make things easier.
From: Xi Ruoyao
Sent: Wednesday, July 27, 2022 8:43 AM
To: Dimitrije Milosevic ;
On Wed, 27 Jul 2022, juzhe.zh...@rivai.ai wrote:
> From: zhongjuzhe
>
> gcc/ChangeLog:
>
> * expr.cc (expand_assignment): Change GET_MODE_PRECISION to
> GET_MODE_BITSIZE
>
> ---
> gcc/expr.cc | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/expr.cc
On Wed, 2022-07-27 at 06:41 +, Dimitrije Milosevic wrote:
> Gentle ping, requiring someone to push this change, as I do not have
> commit access. :)
Do you know someone very familiar with MIPS and GCC and capable as a
port maintainer? An active MIPS port maintainer will make the situation
Gentle ping, requiring someone to push this change, as I do not have commit
access. :)
From: Dimitrije Milosevic
Sent: Monday, July 25, 2022 8:55 AM
To: gcc-patches@gcc.gnu.org
Cc: Djordje Todorovic ; xry...@xry111.site
Subject: [PATCH] libsanitizer: Cherry-pick 2bfb0fcb51510f22723c8cdfefe
On Tue, 26 Jul 2022, Marek Polacek wrote:
> Since r11-5188-g32934a4f45a721, we drop qualifiers during l-to-r
> conversion by creating a NOP_EXPR. For e.g.
>
> const int i = i;
>
> that means that the DECL_INITIAL is '(int) i' and not 'i' anymore.
> Consequently, we don't suppress_warning
88 matches
Mail list logo
