Hello Segher:
On 24/02/23 8:41 pm, Segher Boessenkool wrote:
> Hi!
>
> For future patches: please don't send patches as replies to existing
> threads. Just start a new thread for a new patch (series). You can
> mark it as [PATCH v2] in the subject, if you want.
>
> On Fri, Feb 24, 2023 at 01:4
On Fri, 24 Feb 2023 05:09:30 PST (-0800), gcc-patches@gcc.gnu.org wrote:
It did help people to identify what extension used in the binary, so I
would prefer keep that enable by default.
IMO it actually hurts more than helps, as it's not really encoding what
extensions are in the binary (or nec
Hi Rimvydas,
Am 24.02.23 um 06:16 schrieb Rimvydas Jasinskas via Gcc-patches:
On Thu, Feb 23, 2023 at 10:53 PM Harald Anlauf wrote:
the patch is mostly fine, but there is a minor style issue:
+ if (sym->attr.ext_attr & (1 << EXT_ATTR_WEAK))
+ gfc_error ("Symbol %qs at %L has the WE
Hi Tobias,
Am 24.02.23 um 12:31 schrieb Tobias Burnus:
(B) The attached patch:
With 'intent(out)' there is no reason to do the conversions. While for
nullified
pointers the bounds-conversion loop is skipped, it may still be executed
for undefined
pointers. (Which is usually harmless.) In either
Hello,
I have just pushed a for PR108923 (a memory leak).
It fixes the small reproducer that I pasted in bugzilla, and I have run
it through the fortran regression testsuite.
More details in the patch.From 545a7d5da5fcc338e29c5241b574ac99d03f4454 Mon Sep 17 00:00:00 2001
From: Mikael Morin
Dat
Dear all,
as reported by Richard - although without a testcase - we leak
gmp memory in do_subscript(). The attached patch was derived
by inspection of the code pointed at by valgrind and regtested
on x86_64-pc-linux-gnu.
Committed as obvious as
commit r13-6336-g45f406c4f62e516b58dcda20b5a7aa43f
I'll install this as obvious provided that the prerequisite
multiline.exp patch is approved.
-- >8 --
For 32-bit newlib targets (such as cris-elf and pru-elf),
that int32_t is "long int". See other regexps in the
testsuite matching "aka (long )?int" (with single-quotes
where needed) where the patt
Ok to commit?
-- >8 --
Those multi-line-patterns are literal. Sometimes a regexp
needs to be matched. This is a start: just three elements
are supported: "(" ")" and the compound ")?" (and on second
thought, it can be argued that "(...)" alone is not useful).
Note that Tcl "string map" is documen
On Fri, 2023-02-24 at 18:54 +0100, Hans-Peter Nilsson wrote:
> Ok to commit?
Looks good to me [1]
Thanks
Dave
[1] though FWIW although I wrote this code, my DejaGnu skills are weak
and I'm not a testsuite maintainer :-/
>
> -- >8 --
> I see overlong lines in the output when a test fails, for
>
On Friday, 24 February 2023 18:14:53 CET Jonathan Wakely wrote:
> Looks like there are a few remaining spaces that could be removed
> where you've joined lines, e.g.
Fixed and pushed.
> OK for trunk anyway (and the branches if you want).
I'll likely backport after I backported all other patches
On Linux/x86_64,
3da77f217c8b2089ecba3eb201e727c3fcdcd19d is the first bad commit
commit 3da77f217c8b2089ecba3eb201e727c3fcdcd19d
Author: Andrew Stubbs
Date: Thu Jul 28 16:07:22 2022 +0100
vect: inbranch SIMD clones
caused
FAIL: gcc.dg/vect/vect-simd-clone-16.c scan-tree-dump-times vect
on a structure with a C99 flexible array member being nested in
another structure.
"GCC extension accepts a structure containing an ISO C99 "flexible array
member", or a union containing such a structure (possibly recursively)
to be a member of a structure.
There are two situations:
* The st
GCC extension accepts the case when a struct with a C99 flexible array member
is embedded into another struct or union (possibly recursively).
__builtin_object_size should treat such struct as flexible size.
gcc/c/ChangeLog:
PR tree-optimization/101832
* c-decl.cc (finish_struct):
Hi, Joseph and Richard,
Could you please review this patch and let me know whether it???s ready
for committing into GCC13?
The fix to Bug PR101832 is an important patch for kernel security
purpose. it's better to be put into GCC13.
=
These are the 4th version of the
Ok to commit?
-- >8 --
I see overlong lines in the output when a test fails, for
example for a bug exposed for cris-elf and pru-elf in
gcc.dg/analyzer/allocation-size-multiline-3.c:
Running /x/gcc/testsuite/gcc.dg/analyzer/analyzer.exp ...
FAIL: gcc.dg/analyzer/allocation-size-multiline-3.c expec
On Thu, 23 Feb 2023 at 08:54, Matthias Kretz via Libstdc++
wrote:
>
>
>
> Whitespace changes only.
Looks like there are a few remaining spaces that could be removed
where you've joined lines, e.g.
+{ return static_cast<_Up*>( __builtin_assume_aligned(__ptr,
_S_alignment<_Tp, _Up>)); }
and
On Thu, 23 Feb 2023 at 08:54, Matthias Kretz via Libstdc++
wrote:
>
>
>
> For simd, the inlining behavior should be similar to builtin types. (No
> operator on buitin types is ever translated into a function call.)
> Therefore, always_inline is the right choice (i.e. inline on -O0 as
> well).
OK
On Thu, 23 Feb 2023 at 08:55, Matthias Kretz via Libstdc++
wrote:
>
OK for trunk (and maybe backport later if you want to).
>
> Signed-off-by: Matthias Kretz
>
> libstdc++-v3/ChangeLog:
>
> PR libstdc++/108856
> * include/experimental/bits/simd_builtin.h
> (_SimdImplBu
Ok to commit?
I suggest that when committed I'll also set the bugzilla
entry in SUSPENDED mode, as opposed to RESOLVED. I mean,
the issue isn't really solved; that'd be a patch improving
pointer tracking across ivopts.
-- >8 --
For cris-elf before this patch, ever since it was added,
this test g
Could you move those thead_* and th_* functions into thead.cc
> +static bool
> +thead_mempair_operand_p (rtx mem, machine_mode mode)
> +{
> + if (!MEM_SIZE_KNOWN_P (mem))
> +return false;
> +
> + /* Only DI or SI mempair instructions exist. */
add gcc_assert (mode == SImode || mode == DImo
On 2/24/23 10:07, Jakub Jelinek wrote:
> On Fri, Feb 24, 2023 at 10:00:01AM +0100, Martin Liška wrote:
>> As mentioned in the PR, when we use LTO, we wrongly use ltrans output
>> file name as a module name of a global variable. That leads to a
>> non-reproducible output.
>>
>> After the suggested c
From: Ju-Zhe Zhong
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/scalar_move-1.c: New test.
* gcc.target/riscv/rvv/base/scalar_move-2.c: New test.
* gcc.target/riscv/rvv/base/scalar_move-3.c: New test.
* gcc.target/riscv/rvv/base/scalar_move-4.c: New test.
From: Ju-Zhe Zhong
gcc/ChangeLog:
* config/riscv/constraints.md (Wb1): New constraint.
* config/riscv/predicates.md
(vector_least_significant_set_mask_operand): New predicate.
(vector_broadcast_mask_operand): Ditto.
* config/riscv/riscv-protos.h (enum vlmul_type)
Hi!
For future patches: please don't send patches as replies to existing
threads. Just start a new thread for a new patch (series). You can
mark it as [PATCH v2] in the subject, if you want.
On Fri, Feb 24, 2023 at 01:41:49PM +0530, Ajit Agarwal wrote:
> Here is the patch that uses xxlor instea
On Feb 24, 2023, Richard Earnshaw wrote:
> Given the logic of this macro, the text should be
> "!TARGET_CXX_METHOD_MAY_BE_INLINE".
I was thinking just "related to that macro", but yeah, negating it makes
sense.
> OK with that change.
Thanks, here's what I'm checking in.
[PR105224] C++ module
Tested x86_64-linux. Pushed to trunk.
-- >8 --
I messed up the endianness of the address_v4::bytes_type array, which
should always be in network byte order. We can just use bit_cast to
convert the _M_addr member to/from bytes_type.
libstdc++-v3/ChangeLog:
* include/experimental/internet
Tested x86_64-linux. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* include/experimental/internet (network_v4::netmask()): Avoid
undefined shift.
(network_v4::broadcast()): Optimize and fix for targets with
uint_least32_t wider than 32 bits.
(network_
Tested x86_64-linux. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* include/experimental/internet (basic_endpoint): Add missing
constexpr to comparison operators.
* testsuite/experimental/net/internet/endpoint/cons.cc: New test.
---
libstdc++-v3/include/experimental
Tested x86_64-linux. Pushed to trunk.
-- >8 --
The TS says the arguments to these constructors shall meet the Executor
requirements, so it's undefined if they don't. Constraining on a subset
of those requirements won't affect valid cases, but prevents the
majority of invalid cases from trying to
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This is an order of magnitude faster than calling inet_ntop (and not
only because we now avoid allocating a string that is one byte larger
than the SSO buffer).
libstdc++-v3/ChangeLog:
* include/experimental/internet (address_v4::to_string)
Tested powerpc64le-linux. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* include/ext/aligned_buffer.h (__aligned_buffer): Add
diagnostic pragmas.
---
libstdc++-v3/include/ext/aligned_buffer.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libstdc++-v3/include/ext/al
Tested x86_64-linux. Pushed to trunk.
-- >8 --
The options need to be set first, so that -std=gnu++20 is used when
checking the c++20 effective target.
libstdc++-v3/ChangeLog:
* testsuite/std/format/arguments/lwg3810.cc: Move dg-options
before dg-do.
---
libstdc++-v3/testsuite/
On Fri, 24 Feb 2023, Jakub Jelinek wrote:
> On Fri, Feb 24, 2023 at 02:47:39PM +0100, Richard Biener wrote:
> > * vec.h (vec::m_vecdata): Remove.
> > (vec::m_vecpfx): Align as T to avoid
> > changing alignment of vec and simplifying
> > address.
> > (vec::address): Compute as t
On Fri, Feb 24, 2023 at 02:47:39PM +0100, Richard Biener wrote:
> * vec.h (vec::m_vecdata): Remove.
> (vec::m_vecpfx): Align as T to avoid
> changing alignment of vec and simplifying
> address.
> (vec::address): Compute as this + 1.
> (vec::embedded_size): Use si
On Fri, Feb 24, 2023 at 02:46:21PM +0100, Richard Biener wrote:
> As preparation to remove m_vecdata in the vl_embed vector this
> changes references to it into calls to address ().
>
> As I was here it also fixes ::contains to avoid repeated bounds
> checking and the same issue in ::lower_bound w
> On Feb 23, 2023, at 7:56 PM, Joseph Myers wrote:
>
> On Thu, 23 Feb 2023, Qing Zhao via Gcc-patches wrote:
>
>> But the following:
>>
>> struct flex1 { int length1; char data1[]; };
>> struct flex2 { int length2; char data2[]; };
>> union union_flex { struct flex1 f1; struct flex2 f2; };
The following avoids default-initializing auto_vec storage for
non-POD T since that's not what the allocated storage fallback
will do and it's also not expected for existing cases like
auto_vec, 64> elts;
which exist to optimize the allocation.
It also fixes the array accesses done by vec to n
As preparation to remove m_vecdata in the vl_embed vector this
changes references to it into calls to address ().
As I was here it also fixes ::contains to avoid repeated bounds
checking and the same issue in ::lower_bound which also suffers
from unnecessary copying around values.
* vec.h
> Hi!
>
> The following testcase ICEs on x86_64-linux with -m32. The problem is
> we create an artificial thunk and because of -fPIC, ia32 and thunk
> destination which doesn't bind locally can't use a mi thunk.
> The ICE is because during expansion to RTL we see SSA_NAME for a PARM_DECL,
> but t
On Fri, Feb 24, 2023 at 12:15:04PM +, Richard Biener wrote:
> > > Anyway, I wonder if you get the -Werror=stringop-overflow= errors during
> > > bootstrap that I got with my version or not.
>
> Yes, I get this as well, not sure how to suppress it. I guess there's
> no standard way to get at t
It did help people to identify what extension used in the binary, so I
would prefer keep that enable by default.
and lld is begin fix those merge issue, so the situation should be improved
soon.
Palmer Dabbelt 於 2023年2月24日 週五 10:29 寫道：
> We generate a handful of attributes by default, but they
On Fri, Feb 24, 2023 at 12:15:04PM +, Richard Biener wrote:
> > > Also, I think it needs to be MAX (N, 2) instead of N, because auto_vec
> > > ctors use MAX (N, 2). We could also change all those to MAX (N, 1)
> > > now, but it can't be N because m_data[sizeof (T) * 0] is invalid in
> > > stan
On Fri, 24 Feb 2023, Jakub Jelinek wrote:
> On Fri, Feb 24, 2023 at 12:32:45PM +0100, Richard Biener via Gcc-patches
> wrote:
> > --- a/gcc/vec.h
> > +++ b/gcc/vec.h
> > @@ -614,7 +614,7 @@ public:
> >T *bsearch (const void *key, int (*compar)(const void *, const void *));
> >T *bsearch (
On Fri, 24 Feb 2023, Jonathan Wakely wrote:
> On Fri, 24 Feb 2023 at 11:52, Jakub Jelinek wrote:
> >
> > On Fri, Feb 24, 2023 at 12:44:44PM +0100, Richard Biener wrote:
> > > --- a/gcc/vec.h
> > > +++ b/gcc/vec.h
> > > @@ -586,8 +586,8 @@ public:
> > >unsigned allocated (void) const { return
Hi!
I've noticed the description of these wasn't updated when the mask2
argument has been added in 2019.
Committed to trunk as obvious.
2023-02-24 Jakub Jelinek
* config/i386/i386-builtin.def: Update description of BDESC
and BDESC_FIRST in file comment to include mask2.
---
On Fri, Feb 24, 2023 at 11:54:54AM +, Jonathan Wakely wrote:
> > The comment needs adjustment and don't we need
> > alignas (T) alignas (vec_prefix) ?
>
> Yes. If alignas(T) is less than the natural alignment then this will
> be an error. We want it to be the larger of the two alignments, so
On Fri, 24 Feb 2023 at 11:52, Jakub Jelinek wrote:
>
> On Fri, Feb 24, 2023 at 12:44:44PM +0100, Richard Biener wrote:
> > --- a/gcc/vec.h
> > +++ b/gcc/vec.h
> > @@ -586,8 +586,8 @@ public:
> >unsigned allocated (void) const { return m_vecpfx.m_alloc; }
> >unsigned length (void) const { r
On Fri, Feb 24, 2023 at 12:44:44PM +0100, Richard Biener wrote:
> --- a/gcc/vec.h
> +++ b/gcc/vec.h
> @@ -586,8 +586,8 @@ public:
>unsigned allocated (void) const { return m_vecpfx.m_alloc; }
>unsigned length (void) const { return m_vecpfx.m_num; }
>bool is_empty (void) const { return m
On Fri, Feb 24, 2023 at 12:32:45PM +0100, Richard Biener via Gcc-patches wrote:
> --- a/gcc/vec.h
> +++ b/gcc/vec.h
> @@ -614,7 +614,7 @@ public:
>T *bsearch (const void *key, int (*compar)(const void *, const void *));
>T *bsearch (const void *key,
> int (*compar)(const void *,
The following avoids default-initializing auto_vec storage for
non-POD T since that's not what the allocated storage fallback
will do and it's also not expected for existing cases like
auto_vec, 64> elts;
which exist to optimize the allocation.
It also fixes the array accesses done by vec to n
Hi all,
With the cleanup of the arch features in GCC 13 the comment on the FLAGS field
in aarch64-cores.def
is now outdated. It's now a comma-separated list rather than a bitwise or.
Spotted while reviewing an aarch64-cores.def patch.
Update the comment.
Pushing to trunk.
Thanks,
Kyrill
gcc/Cha
As preparation to remove m_vecdata in the vl_embed vector this
changes references to it into calls to address ().
As I was here it also fixes ::contains to avoid repeated bounds
checking and the same issue in ::lower_bound which also suffers
from unnecessary copying around values.
* vec.h
[The following is about Fortran pointers as actual argument to a CFI taking
procedure.]
The issue has been marked as 12/13 regression but the issue is just a
diagnostic one.
To disentangle:
(A) Bogus warning
[Now tracked as middle-end https://gcc.gnu.org/PR108906 ]
Assume:
nullify(p)
ca
On Fri, Feb 24, 2023 at 9:09 AM Kito Cheng wrote:
>
> Hi Christoph:
>
> OK for trunk for the 1~8, feel free to commit 1~8 after you address
> those minor comments, and could you also prepare release notes for
> those extensions?
I addressed the comment regarding XTheadBs.
But I have not done anyt
From: Christoph Müllner
This patch documents the new T-Head CPU support for RISC-V.
Signed-off-by: Christoph Müllner
---
htdocs/gcc-13/changes.html | 24 +++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.ht
On 2/24/23 10:32, Benson Muite via Gcc-patches wrote:
> On 2/24/23 04:02, Gerald Pfeifer wrote:
>> On Thu, 23 Feb 2023, Tobias Burnus wrote:
>>> PS: I also removed a stray , but admittedly only after the
>>> commit. I found it by manually running those through the w3 validator
>>> site. However, I
On Fri, Feb 24, 2023 at 11:59:53AM +0100, Jakub Jelinek via Gcc-patches wrote:
> > This needs to be alignas(T) unsigned char m_data[sizeof(T) * N];
>
> unsigned char m_data[MAX (N, 2) * sizeof (T)];
>
> if we want to preserve current behavior I think.
>
> I've screwed up, when I was about to c
On Fri, Feb 24, 2023 at 10:30:00AM +, Jonathan Wakely wrote:
> On Fri, 24 Feb 2023 at 10:24, Jakub Jelinek wrote:
> >
> > On Fri, Feb 24, 2023 at 11:02:07AM +0100, Jakub Jelinek via Gcc-patches
> > wrote:
> > > Maybe this would work, vl_relative even could be vl_embed.
> > > Because vl_embed
On Fri, Feb 24, 2023 at 11:05 AM Christoph Müllner
wrote:
>
> On Fri, Feb 24, 2023 at 10:54 AM Kito Cheng wrote:
> >
> > My impression is that md patterns will use first-match patterns? so
> > the zba will get higher priority than xtheadba if both patterns are
> > matched?
>
> Yes, I was just abo
> On 24 Feb 2023, at 10:23, Richard Earnshaw via Gcc-patches
> wrote:
>
>
>
> On 23/02/2023 21:20, Alexandre Oliva wrote:
>> On Feb 23, 2023, Alexandre Oliva wrote:
>>> On Feb 23, 2023, Richard Earnshaw wrote:
On 22/02/2023 19:57, Alexandre Oliva wrote:
> On Feb 21, 2023, Richard
On Fri, 24 Feb 2023 at 10:24, Jakub Jelinek wrote:
>
> On Fri, Feb 24, 2023 at 11:02:07AM +0100, Jakub Jelinek via Gcc-patches wrote:
> > Maybe this would work, vl_relative even could be vl_embed.
> > Because vl_embed I believe is used in two spots, part of
> > auto_vec where it is followed by m_d
On Fri, Feb 24, 2023 at 11:02:07AM +0100, Jakub Jelinek via Gcc-patches wrote:
> Maybe this would work, vl_relative even could be vl_embed.
> Because vl_embed I believe is used in two spots, part of
> auto_vec where it is followed by m_data and on heap or GGC
> allocated memory where vec<..., vl_em
On 23/02/2023 21:20, Alexandre Oliva wrote:
On Feb 23, 2023, Alexandre Oliva wrote:
On Feb 23, 2023, Richard Earnshaw wrote:
On 22/02/2023 19:57, Alexandre Oliva wrote:
On Feb 21, 2023, Richard Earnshaw wrote:
Rather than scanning for the triplet, a better test would be
{ xfail { a
On Fri, Feb 24, 2023 at 8:37 AM Kito Cheng wrote:
>
> > diff --git a/gcc/config/riscv/thead.md b/gcc/config/riscv/thead.md
> > index 158e9124c3a..2c684885850 100644
> > --- a/gcc/config/riscv/thead.md
> > +++ b/gcc/config/riscv/thead.md
> > @@ -29,3 +29,14 @@ (define_insn "*th_addsl"
> >"th.ad
On Fri, Feb 24, 2023 at 10:54 AM Kito Cheng wrote:
>
> My impression is that md patterns will use first-match patterns? so
> the zba will get higher priority than xtheadba if both patterns are
> matched?
Yes, I was just about to write this.
/opt/riscv-thead/bin/riscv64-unknown-linux-gnu-gcc -O2
On Fri, Feb 24, 2023 at 09:55:13AM +, Jonathan Wakely wrote:
> > You would still be accessing past the end of the
> > vec::m_vecdata array which is UB.
>
> My thinking is something like:
>
> // New tag type
> struct vl_relative { };
>
> // This must only be used as a member subobject of anot
On Fri, 24 Feb 2023 at 09:50, Jonathan Wakely wrote:
>
> On Fri, 24 Feb 2023 at 09:49, Jakub Jelinek wrote:
> >
> > Assuming a compiler handles the T m_vecdata[1]; as flexible array member
> > like (which we need because standard C++ doesn't have flexible array members
> > nor [0] arrays), I wonde
On Fri, Feb 24, 2023 at 09:50:33AM +, Jonathan Wakely wrote:
> On Fri, 24 Feb 2023 at 09:49, Jakub Jelinek wrote:
> >
> > Assuming a compiler handles the T m_vecdata[1]; as flexible array member
> > like (which we need because standard C++ doesn't have flexible array members
> > nor [0] arrays)
My impression is that md patterns will use first-match patterns? so
the zba will get higher priority than xtheadba if both patterns are
matched?
On Fri, Feb 24, 2023 at 2:52 PM Andrew Pinski via Gcc-patches
wrote:
>
> On Thu, Feb 23, 2023 at 9:55 PM Christoph Muellner
> wrote:
> >
> > From: Chri
On Fri, 24 Feb 2023 at 09:49, Jakub Jelinek wrote:
>
> Assuming a compiler handles the T m_vecdata[1]; as flexible array member
> like (which we need because standard C++ doesn't have flexible array members
> nor [0] arrays), I wonder if we instead of the m_auto followed by m_data
> trick couldn't
On Fri, Feb 24, 2023 at 09:34:46AM +, Richard Biener wrote:
> > Looking at vec::operator[] which just does
> >
> > template
> > inline const T &
> > vec::operator[] (unsigned ix) const
> > {
> > gcc_checking_assert (ix < m_vecpfx.m_num);
> > return m_vecdata[ix];
> > }
> >
> > the whole
> > +(define_memory_constraint "Qmx"
> > + "@internal
> > + An address valid for GPR."
> > + (and (match_code "mem")
> > + (match_test "!riscv_legitimize_address_index_p (
> > + XEXP (op, 0), GET_MODE (op), false)")))
>
> Check TARGET_XTHEADFMEMIDX, and I don't quite und
> diff --git a/gcc/config/riscv/riscv-opts.h b/gcc/config/riscv/riscv-opts.h
> index cf0cd669be4..5cd3f7673f0 100644
> --- a/gcc/config/riscv/riscv-opts.h
> +++ b/gcc/config/riscv/riscv-opts.h
> @@ -215,4 +215,7 @@ enum stack_protector_guard {
> #define TARGET_XTHEADMEMPAIR ((riscv_xthead_subext &
On Fri, 24 Feb 2023, Jakub Jelinek wrote:
> Hi!
>
> The following testcase ICEs on x86_64-linux with -m32. The problem is
> we create an artificial thunk and because of -fPIC, ia32 and thunk
> destination which doesn't bind locally can't use a mi thunk.
> The ICE is because during expansion to R
Hi!
The following testcase ICEs on x86_64-linux with -m32. The problem is
we create an artificial thunk and because of -fPIC, ia32 and thunk
destination which doesn't bind locally can't use a mi thunk.
The ICE is because during expansion to RTL we see SSA_NAME for a PARM_DECL,
but the PARM_DECL d
On Fri, 24 Feb 2023, Richard Biener wrote:
> On Thu, 23 Feb 2023, Jakub Jelinek wrote:
>
> > On Thu, Feb 23, 2023 at 03:02:01PM +, Richard Biener wrote:
> > > > > * vec.h (auto_vec): Turn m_data storage into
> > > > > uninitialized unsigned char.
> > > >
> > > > Given that we act
On Fri, Feb 24, 2023 at 10:01 AM Kito Cheng wrote:
>
> Got one fail:
>
> FAIL: gcc.target/riscv/xtheadmempair-1.c -O2 scan-assembler-times
> th.luwd\t 4
>
> It should scan lwud rather than luwd?
Yes, this should be th.lwud.
Must have been introduced after testing.
I also ran the whole patchs
Hi!
The builtins used in avx512bf16vlintrin.h implementation need both
avx512bf16 and avx512vl ISAs, which the header ensures for them, but
the builtins weren't actually requiring avx512vl, so when used by hand
with just -mavx512bf16 -mno-avx512vl it resulted in ICEs.
Fixed by adding OPTION_MASK_
Hi Thomas / Arthur!
On Wed, 2023-02-22 15:30:37 +0100, Arthur Cohen
wrote:
[..]
> > > --target=msp430-elfbare
> > > ~
> > >
> > > /var/lib/laminar/run/gcc-msp430-elfbare/24/toolchain-build/./gcc/xgcc
> > > -B/var/lib/laminar/run/gcc-msp430-elfbare/24/toolchain-
On Fri, Feb 24, 2023 at 10:00:01AM +0100, Martin Liška wrote:
> As mentioned in the PR, when we use LTO, we wrongly use ltrans output
> file name as a module name of a global variable. That leads to a
> non-reproducible output.
>
> After the suggested change, we emit context name of normal global
On Thu, 23 Feb 2023, Jakub Jelinek wrote:
> On Thu, Feb 23, 2023 at 03:02:01PM +, Richard Biener wrote:
> > > > * vec.h (auto_vec): Turn m_data storage into
> > > > uninitialized unsigned char.
> > >
> > > Given that we actually never reference the m_data array anywhere,
> > >
Got one fail:
FAIL: gcc.target/riscv/xtheadmempair-1.c -O2 scan-assembler-times
th.luwd\t 4
It should scan lwud rather than luwd?
As mentioned in the PR, when we use LTO, we wrongly use ltrans output
file name as a module name of a global variable. That leads to a
non-reproducible output.
After the suggested change, we emit context name of normal global
variables. And for artificial variables (like .Lubsan_data3), we use
aux
Hi,
In patch https://gcc.gnu.org/pipermail/gcc-patches/2023-February/612168.html,
we improved the bictcast from lowpart/highpart of DI to SF by using mtvsrws
or mtvsrd.
As investigating this functionality, we may improve the related code by using
bitcast subreg from SI to SF, and avoid generating
ASAN: keep support for Global::location
We as GCC still emit __asan_global_source_location for global variables
and we would like to use it in the future. On other hand, we don't
support llvm-symbolizer and the default libbacktraace symbolizer
does not support location info.
---
libsanitizer/asan
Hello All:
Here is the patch that uses xxlor instead of fmr where possible.
Performance results shows that fmr is better in power9 and
power10 architectures whereas xxlor is better in power7 and
power 8 architectures.
Bootstrapped and regtested powepc64-linux-gnu.
Thanks & Regards
Ajit
Hi Christoph:
OK for trunk for the 1~8, feel free to commit 1~8 after you address
those minor comments, and could you also prepare release notes for
those extensions?
And 9~11 needs to take a few more rounds of review and test.
On Fri, Feb 24, 2023 at 1:52 PM Christoph Muellner
wrote:
>
> Fr
87 matches
Mail list logo
