Hello,
The following is patch v3 to update BTF/CTF backend supporting
BTF_KIND_ENUM64 type. Changes from v2:
+ Add a new `dtd_enum_unsigned' field in `ctf_dtdef' to indicate
signedness of the enum type.
+ Fix endianness for representing BTF enum 64-bits enumerators.
+ Add {little,big}-e
On 10/11/22 13:55, Indu Bhagat wrote:
Hi Guillermo,
Hi Indu,
On 10/3/22 7:39 AM, Guillermo E. Martinez via Gcc-patches wrote:
diff --git a/gcc/ctfc.cc b/gcc/ctfc.cc
index 9773358a475..253c36b6a0a 100644
--- a/gcc/ctfc.cc
+++ b/gcc/ctfc.cc
@@ -604,6 +604,7 @@ ctf_add_enum (ctf_container_r
On Fri, 14 Oct 2022 14:57:22 PDT (-0700), Palmer Dabbelt wrote:
On Fri, 14 Oct 2022 13:39:33 PDT (-0700), jeffreya...@gmail.com wrote:
On 10/14/22 05:03, Christoph Müllner wrote:
My guess is people like the ISA mapping (more) because it has been
documented and reviewed.
And it is the product
On 10/14/22 15:21, Koning, Paul wrote:
On Oct 14, 2022, at 5:15 PM, Jeff Law via Gcc-patches
wrote:
On 10/14/22 11:36, Koning, Paul wrote:
On Oct 14, 2022, at 1:10 PM, Jeff Law wrote:
On 10/14/22 10:37, Koning, Paul wrote:
...
But that approach falls down with reload/lra doing substit
C2x has, like C++, adopted rules for identifiers based directly on an
unversioned normative reference to Unicode. Make libcpp follow those
rules for c2x / gnu2x standards (this involves bringing back a flag
separate from the C++ one for whether to use these identifier rules,
but this time enabled
From: Ju-Zhe Zhong
Hi, this patch fixed my mistake in the previous commit patch.
Since "mangle_builtin_type" is a global function will be called in riscv.cc.
It's reasonable move it down and put them together stay with other global
functions.
gcc/ChangeLog:
* config/riscv/riscv-vector-
On Fri, 14 Oct 2022 12:56:48 PDT (-0700), Palmer Dabbelt wrote:
We have had an implementation of __builtin___clear_cache since the
beginning, but didn't have the cooresponding __clear_cache library
routine implemented. This directly conflicts the GCC manual in a
handful of places, which indicate
On Fri, 14 Oct 2022 13:39:33 PDT (-0700), jeffreya...@gmail.com wrote:
On 10/14/22 05:03, Christoph Müllner wrote:
My guess is people like the ISA mapping (more) because it has been
documented and reviewed.
And it is the product of a working group that worked out the
RVWMO specification.
Thi
We have had an implementation of __builtin___clear_cache since the
beginning, but didn't have the cooresponding __clear_cache library
routine implemented. This directly conflicts the GCC manual in a
handful of places, which indicates that __clear_cache should work and
that __builtin_clear_cache sh
On 10/14/22 15:21, Koning, Paul wrote:
On Oct 14, 2022, at 5:15 PM, Jeff Law via Gcc-patches
wrote:
On 10/14/22 11:36, Koning, Paul wrote:
On Oct 14, 2022, at 1:10 PM, Jeff Law wrote:
On 10/14/22 10:37, Koning, Paul wrote:
...
But that approach falls down with reload/lra doing substit
> On Oct 14, 2022, at 5:15 PM, Jeff Law via Gcc-patches
> wrote:
>
>
> On 10/14/22 11:36, Koning, Paul wrote:
>>
>>> On Oct 14, 2022, at 1:10 PM, Jeff Law wrote:
>>>
>>> On 10/14/22 10:37, Koning, Paul wrote:
> ...
> But that approach falls down with reload/lra doing substitutions
On Fri, Oct 14, 2022 at 10:43:16PM +0200, Martin Uecker wrote:
> Am Montag, den 10.10.2022, 10:54 +0200 schrieb Jakub Jelinek:
> > Hi!
> >
> > My earlier patches gimplify the simplest non-side-effects assumptions
> > into if (cond) ; else __builtin_unreachable (); and throw the rest
> > on the flo
Long introduction - but the patch is rather simple: Don't use kind=1
as type where kind=4 should be used.
Long introduction + background, feel free to skip.
This popped up for libgomp/testsuite/libgomp.fortran/struct-elem-map-1.f90
which uses kind=4 characters –
On 10/14/22 11:36, Koning, Paul wrote:
On Oct 14, 2022, at 1:10 PM, Jeff Law wrote:
On 10/14/22 10:37, Koning, Paul wrote:
...
But that approach falls down with reload/lra doing substitutions without
validating the result. I guess it might be possible to cobble together
something with s
On Fri, Oct 14, 2022 at 1:32 PM Jeff Law via Gcc-patches
wrote:
>
>
> On 10/10/22 09:50, H.J. Lu via Gcc-patches wrote:
> > On Thu, Jul 28, 2022 at 5:40 AM Richard Sandiford via Gcc-patches
> > wrote:
> >> Seems this thread has become a bit heated, so I'll try to proceed
> >> with caution :-)
> >
Am Montag, den 10.10.2022, 10:54 +0200 schrieb Jakub Jelinek:
> Hi!
>
> My earlier patches gimplify the simplest non-side-effects assumptions
> into if (cond) ; else __builtin_unreachable (); and throw the rest
> on the floor.
> The following patch attempts to do something with the rest too.
My r
> On Oct 14, 2022, at 4:12 PM, Segher Boessenkool
> wrote:
>
> On Fri, Oct 14, 2022 at 07:58:39PM +, Koning, Paul wrote:
>>> On Oct 14, 2022, at 2:03 PM, Jeff Law via Gcc-patches
>>> wrote:
>>> On 10/14/22 11:35, Segher Boessenkool wrote:
On Fri, Oct 14, 2022 at 11:07:43AM -0600, J
On 10/14/22 05:03, Christoph Müllner wrote:
My guess is people like the ISA mapping (more) because it has been
documented and reviewed.
And it is the product of a working group that worked out the
RVWMO specification.
This gives some confidence that we don't need to rework it massively
beca
On 10/10/22 09:50, H.J. Lu via Gcc-patches wrote:
On Thu, Jul 28, 2022 at 5:40 AM Richard Sandiford via Gcc-patches
wrote:
Seems this thread has become a bit heated, so I'll try to proceed
with caution :-)
In the below, I'll use "X-mode const_int" to mean "a const_int that
is known from cont
On 7/26/22 11:44, Segher Boessenkool wrote:
Hi!
On Tue, Jul 26, 2022 at 01:13:02PM +0100, Roger Sayle wrote:
This patch is a major revision of the patch I originally proposed here:
https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598040.html
The primary motivation of this patch is to avoi
On Fri, Oct 14, 2022 at 07:58:39PM +, Koning, Paul wrote:
> > On Oct 14, 2022, at 2:03 PM, Jeff Law via Gcc-patches
> > wrote:
> > On 10/14/22 11:35, Segher Boessenkool wrote:
> >> On Fri, Oct 14, 2022 at 11:07:43AM -0600, Jeff Law wrote:
> LRA only ever generates insns that pass recog.
> On Oct 14, 2022, at 2:03 PM, Jeff Law via Gcc-patches
> wrote:
>
>
> On 10/14/22 11:35, Segher Boessenkool wrote:
>> On Fri, Oct 14, 2022 at 11:07:43AM -0600, Jeff Law wrote:
LRA only ever generates insns that pass recog. The backend allows this
define_insn, requiring it to be s
Le 09/10/2022 à 20:57, Harald Anlauf via Fortran a écrit :
Dear all,
the check of data transfer elements needs to verify that for
polymorphic objects there is a user defined DTIO procedure.
This check worked fine for scalars, but skipped arrays,
leading to an ICE later.
The obvious fix is to al
On Tuesday, 11 October 2022 08:47:32 CEST Richard Biener wrote:
> OK.
Thanks for the review. I don't have push rights currently, so could you
push this for me?
Have a good evening,
--
Arsen Arsenović
signature.asc
Description: This is a digitally signed message part.
On Fri, Oct 14, 2022 at 11:27:07AM +, Richard Biener wrote:
> > --- gcc/function.h.jj 2022-10-10 11:57:40.163722972 +0200
> > +++ gcc/function.h 2022-10-12 19:48:28.887554771 +0200
> > @@ -438,6 +438,10 @@ struct GTY(()) function {
> >
> >/* Set if there are any OMP_TARGET regions
On 10/14/22 11:35, Segher Boessenkool wrote:
On Fri, Oct 14, 2022 at 11:07:43AM -0600, Jeff Law wrote:
LRA only ever generates insns that pass recog. The backend allows this
define_insn, requiring it to be split (it returns template "#"), but
then somehow it doesn't match in any split pass?
Florian Weimer via Gcc-patches writes:
> On many architectures, there is a padding gap after the how array
> member, and cfa_how can be moved there. This reduces the size of the
> struct and the amount of memory that uw_frame_state_for has to clear.
>
> There is no measurable performance benefit
> On Oct 14, 2022, at 1:10 PM, Jeff Law wrote:
>
> On 10/14/22 10:37, Koning, Paul wrote:
>>
>>> ...
>>> But that approach falls down with reload/lra doing substitutions without
>>> validating the result. I guess it might be possible to cobble together
>>> something with secondary reloads,
On Fri, Oct 14, 2022 at 11:07:43AM -0600, Jeff Law wrote:
> >LRA only ever generates insns that pass recog. The backend allows this
> >define_insn, requiring it to be split (it returns template "#"), but
> >then somehow it doesn't match in any split pass?
>
> Nope. The elimination code will just
>
> 2022-08-26 Martin Jambor
>
> * ipa-prop.h (ipa_agg_value): Remove type.
> (ipa_agg_value_set): Likewise.
> (ipa_copy_agg_values): Remove function.
> (ipa_release_agg_values): Likewise.
> (ipa_auto_call_arg_values) Add a forward declaration.
> (ipa_call_a
> gcc/ChangeLog:
>
> 2022-08-26 Martin Jambor
>
> * ipa-prop.h (IPA_PROP_ARG_INDEX_LIMIT_BITS): New.
> (ipcp_transformation): Added forward declaration.
> (ipa_argagg_value): New type.
> (ipa_argagg_value_list): New type.
> (ipa_agg_replacement_value): Removed typ
On 10/14/22 10:39, Richard Biener wrote:
Am 14.10.2022 um 16:40 schrieb Jeff Law via Gcc-patches
:
On 10/14/22 06:37, Koning, Paul wrote:
On Oct 13, 2022, at 9:07 PM, Jeff Law via Gcc-patches
wrote:
On 10/13/22 17:56, Segher Boessenkool wrote:
h8300 fails during GCC build:
/home/s
On 10/14/22 10:37, Koning, Paul wrote:
On Oct 14, 2022, at 10:38 AM, Jeff Law via Gcc-patches
wrote:
On 10/14/22 06:37, Koning, Paul wrote:
On Oct 13, 2022, at 9:07 PM, Jeff Law via Gcc-patches
wrote:
On 10/13/22 17:56, Segher Boessenkool wrote:
h8300 fails during GCC build:
/home/s
On 10/14/22 10:37, Segher Boessenkool wrote:
Hi!
On Thu, Oct 13, 2022 at 10:47:20PM -0600, Jeff Law wrote:
On 10/13/22 17:56, Segher Boessenkool wrote:
h8300 fails during GCC build:
/home/segher/src/gcc/libgcc/unwind.inc: In function
'_Unwind_SjLj_RaiseException':
/home/segher/src/gcc/libgcc
This patch fixes a problem in which fatal errors inside mutex-locked
regions (i.e. basically anything in the plugin) will cause it to hang up
trying to take the lock to clean everything up.
Using abort() instead of exit(1) bypasses the atexit handlers and solves
the problem.
OK for mainline?
IIUC we currently avoid streaming the RESULT_DECL and PARM_DECLs
of a constexpr_fundef entry under the assumption that they're just
copies of the DECL_RESULT and DECL_ARGUMENTS of the FUNCTION_DECL.
Thus we can just make new copies of DECL_RESULT and DECL_ARGUMENTs
on stream in rather than separate
> On Oct 14, 2022, at 12:18 PM, Segher Boessenkool
> wrote:
>
> On Fri, Oct 14, 2022 at 12:36:47AM +, Koning, Paul wrote:
>> I guess I'll have to look harder to see if it's possible to make LRA handle
>> CISC addressing modes like memory indirect, autoincrement, autodecrement,
>> and ot
On many architectures, there is a padding gap after the how array
member, and cfa_how can be moved there. This reduces the size of the
struct and the amount of memory that uw_frame_state_for has to clear.
There is no measurable performance benefit from this on x86-64 (even
though the memset goes
> Am 14.10.2022 um 16:40 schrieb Jeff Law via Gcc-patches
> :
>
>
>> On 10/14/22 06:37, Koning, Paul wrote:
>>
On Oct 13, 2022, at 9:07 PM, Jeff Law via Gcc-patches
wrote:
>>>
>>>
>>> On 10/13/22 17:56, Segher Boessenkool wrote:
h8300 fails during GCC build:
/home/se
Just spotted this. It did only compile instead of also run and was the
only occurrence I could find for 'dg-.*execute'.
Committed as https://gcc.gnu.org/r13-3306
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit besc
Hi!
On Thu, Oct 13, 2022 at 10:47:20PM -0600, Jeff Law wrote:
> On 10/13/22 17:56, Segher Boessenkool wrote:
> >h8300 fails during GCC build:
> >/home/segher/src/gcc/libgcc/unwind.inc: In function
> >'_Unwind_SjLj_RaiseException':
> >/home/segher/src/gcc/libgcc/unwind.inc:141:1: error: could not
> On Oct 14, 2022, at 10:38 AM, Jeff Law via Gcc-patches
> wrote:
>
>
> On 10/14/22 06:37, Koning, Paul wrote:
>>
>>> On Oct 13, 2022, at 9:07 PM, Jeff Law via Gcc-patches
>>> wrote:
>>>
>>>
>>> On 10/13/22 17:56, Segher Boessenkool wrote:
h8300 fails during GCC build:
/home/s
Excerpts from herron.phi...@googlemail.com's message of August 24, 2022 1:59 pm:
> From: Philip Herron
>
> This specifies the extensions of the Rust language.
> ---
> gcc/rust/lang-specs.h | 26 ++
> 1 file changed, 26 insertions(+)
> create mode 100644 gcc/rust/lang-spe
On Fri, Oct 14, 2022 at 03:20:40PM +0900, Takayuki 'January June' Suwa wrote:
> On 2022/10/14 8:56, Segher Boessenkool wrote:
> > And finally, xtensa does
> > /home/segher/src/gcc/libgcc/libgcc2.c:840:1: error: insn does not satisfy
> > its constraints:
> > 840 | }
> > | ^
> > (insn 8 7 9
On Fri, Oct 14, 2022 at 12:36:47AM +, Koning, Paul wrote:
> I guess I'll have to look harder to see if it's possible to make LRA handle
> CISC addressing modes like memory indirect, autoincrement, autodecrement, and
> others that the old reload handles at least somewhat. Ideally LRA should d
On Fri, Oct 14, 2022 at 05:08:51PM +0200, Aldy Hernandez wrote:
> [Jakub, while we're on the subject of signed zeros and copysign, does
> this look OK to you?]
>
> copysign(MAGNITUDE, SIGN) is implemented as the absolute of MAGNITUDE,
> with SIGN applied. If the sign of "SIGN" cannot be determine
On 10/13/22 17:57, Paul Iannetta wrote:
On Thu, Oct 13, 2022 at 03:41:16PM -0400, Jason Merrill wrote:
On 10/13/22 12:02, Paul Iannetta wrote:
On Thu, Oct 13, 2022 at 11:47:42AM -0400, Jason Merrill wrote:
On 10/13/22 11:23, Paul Iannetta wrote:
On Thu, Oct 13, 2022 at 11:02:24AM -0400, Jason
On 10/14/22 06:04, Arsen Arsenović wrote:
On Thursday, 13 October 2022 23:16:02 CEST Jason Merrill wrote:
I liked in the previous version that you checked the return type of
main when !flag_hosted, here and in c_missing_noreturn_ok_p. Let's
bring that back.
Ah, right; I forgot about that. Wha
[Jakub, while we're on the subject of signed zeros and copysign, does
this look OK to you?]
copysign(MAGNITUDE, SIGN) is implemented as the absolute of MAGNITUDE,
with SIGN applied. If the sign of "SIGN" cannot be determined, we
return a range of [-MAGNITUDE, +MAGNITUDE].
gcc/ChangeLog:
On Fri, Oct 14, 2022 at 5:00 PM Jakub Jelinek wrote:
>
> On Fri, Oct 14, 2022 at 04:53:13PM +0200, Aldy Hernandez wrote:
> > > This looks wrong to me.
> > > !HONOR_NANS is different from !HONOR_SIGNED_ZEROS.
> > > The former says that either NaNs aren't supported or if they appear,
> > > it will b
On Fri, Oct 14, 2022 at 04:53:13PM +0200, Aldy Hernandez wrote:
> > This looks wrong to me.
> > !HONOR_NANS is different from !HONOR_SIGNED_ZEROS.
> > The former says that either NaNs aren't supported or if they appear,
> > it will be UB.
> > The latter says that either -0.0 doesn't exist, or user
On Fri, Oct 14, 2022 at 4:33 PM Jakub Jelinek wrote:
>
> On Fri, Oct 14, 2022 at 04:26:50PM +0200, Aldy Hernandez via Gcc-patches
> wrote:
> > Similar to what we do for NANs when !HONOR_NANS and Inf when
> > flag_finite_math_only, we can remove -0.0 from the range at creation
> > time.
> >
> > We
On 10/14/22 06:37, Koning, Paul wrote:
On Oct 13, 2022, at 9:07 PM, Jeff Law via Gcc-patches
wrote:
On 10/13/22 17:56, Segher Boessenkool wrote:
h8300 fails during GCC build:
/home/segher/src/gcc/libgcc/unwind.inc: In function
'_Unwind_SjLj_RaiseException':
/home/segher/src/gcc/libgcc/u
On Fri, Oct 14, 2022 at 04:30:47PM +0200, Aldy Hernandez wrote:
> [Jakub, thanks for pointing this out. OK?]
>
> [-Inf, -Inf] is being flushed to [-Inf, -0.0] because real_isdenormal
> is being overly pessimistic. It is missing a check for rvc_normal.
> This doesn't cause problems in real.cc bec
Tested x86_64-linux. Pushed to trunk.
-- >8 --
For a zero-sized static pool we can completely elide all code for the EH
pool.
We no longer need to adjust the static buffer size to ensure at least
one free_entry can be created in it, because we no longer use a static
buffer at all if obj_count ==
Tested powerpc64le-linux. Pushed to trunk.
-- >8 --
Replace two uses of print_raw where it's clearer to just use fprintf
directly. Then the only remaining use of print_raw is as the print_func
argument of pretty_print. When called by pretty_print the count is
either a positive integer or -1, so w
On Fri, Oct 14, 2022 at 04:26:50PM +0200, Aldy Hernandez via Gcc-patches wrote:
> Similar to what we do for NANs when !HONOR_NANS and Inf when
> flag_finite_math_only, we can remove -0.0 from the range at creation
> time.
>
> We were kinda sorta doing this because there is a bug in
> real_isdenorm
[Jakub, thanks for pointing this out. OK?]
[-Inf, -Inf] is being flushed to [-Inf, -0.0] because real_isdenormal
is being overly pessimistic. It is missing a check for rvc_normal.
This doesn't cause problems in real.cc because all uses of
real_isdenormal are already on the rvc_normal path. The
gcc/ChangeLog:
* gimple-range-op.cc
(gimple_range_op_handler::maybe_builtin_call): Replace
CFN_BUILTIN_SIGNBIT* cases with CASE_FLT_FN.
---
gcc/gimple-range-op.cc | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/gcc/gimple-range-op.cc b/gcc/gimple-ran
Similar to what we do for NANs when !HONOR_NANS and Inf when
flag_finite_math_only, we can remove -0.0 from the range at creation
time.
We were kinda sorta doing this because there is a bug in
real_isdenormal that is causing flush_denormals_to_zero to saturate
[x, -0.0] to [x, +0.0] when !HONOR_SI
[-Inf, +Inf] was being chopped correctly for -ffinite-math-only, but
[-Inf, -Inf] was not. This was latent because a bug in
real_isdenormal is causing us to flush -Inf to zero.
gcc/ChangeLog:
* value-range.cc (frange::set): Normalize ranges for both bounds.
---
gcc/value-range.cc | 4 ++
Done.
Thanks.
Aldy
On Fri, Oct 14, 2022 at 12:17 PM Jakub Jelinek wrote:
>
> On Fri, Oct 14, 2022 at 12:03:16PM +0200, Aldy Hernandez via Gcc-patches
> wrote:
> > gcc/ChangeLog:
> >
> > * gimple-range-op.cc
> > (gimple_range_op_handler::maybe_builtin_call): Add
> > CFN_BUILT_I
On Wed, Oct 12, 2022 at 01:18:19AM +0200, Paul Iannetta wrote:
> On Mon, Oct 10, 2022 at 11:07:06PM +, Joseph Myers wrote:
> > On Mon, 10 Oct 2022, Paul Iannetta via Gcc-patches wrote:
> >
> > > I have a patch to bring this feature to the C front-end as well, and
> > > would like to hear your
This patch prevents compiler-generated artificial variables from being
treated as privatization candidates for OpenACC.
The rationale is that e.g. "gang-private" variables actually must be
shared by each worker and vector spawned within a particular gang, but
that sharing is not necessary for any
The GCN backend uses a heuristic to determine whether to use FLAT or
GLOBAL addressing in a particular (offload) function: namely, if a
function takes a pointer-to-scalar parameter, it is assumed that the
pointer may refer to "flat scratch" space, and thus FLAT addressing must
be used instead of GL
> On Oct 13, 2022, at 9:07 PM, Jeff Law via Gcc-patches
> wrote:
>
>
> On 10/13/22 17:56, Segher Boessenkool wrote:
>>
>> h8300 fails during GCC build:
>> /home/segher/src/gcc/libgcc/unwind.inc: In function
>> '_Unwind_SjLj_RaiseException':
>> /home/segher/src/gcc/libgcc/unwind.inc:141:1:
Martin Liška writes:
>> This patch set contains the bootstrap linking tool as well as python3
>> scripts to automatically generate texi libraries section of the gm2
>> documentation. In the fullness of time this will be changed to emit
>> sphinx.
>
> Yep, looking forward to it. I'm going to writ
On 10/13/22 11:27, Jason Merrill wrote:
On 10/11/22 13:40, Nathan Sidwell wrote:
On 10/11/22 11:35, Patrick Palka wrote:
IIUC the function depset::hash::add_binding_entity has an assert
verifying that if a namespace contains an exported entity, then
the namespace must have been opened in the mo
Hello,
On Fri, Oct 14 2022, Martin Liška wrote:
> On 10/14/22 08:12, Richard Biener wrote:
>> On Fri, Oct 14, 2022 at 12:54 AM Eric Botcazou via Gcc-patches
>> wrote:
>>>
Not a fan as it could potentially hide a real issue, but I don't really
have a better solution.
>>>
>>> Thanks.
>>>
On Thu, 13 Oct 2022, Jakub Jelinek wrote:
> On Wed, Oct 12, 2022 at 11:48:27AM -0400, Jason Merrill wrote:
> > > --- gcc/cp/pt.cc.jj 2022-10-10 09:31:21.947480379 +0200
> > > +++ gcc/cp/pt.cc 2022-10-10 09:59:49.299646482 +0200
> > > @@ -21105,6 +21105,8 @@ tsubst_copy_and_build (tree t,
>
On 10/13/22 15:04, Patrick Palka wrote:
The FUNCTION_DECL we build for __dynamic_cast has an empty DECL_CONTEXT,
but trees_out::tree_node expects all FUNCTION_DECLs to have non-empty
DECL_CONTEXT thus we crash when streaming out the dynamic_cast in the
below testcase.
This patch naively fixes th
On Fri, Oct 14, 2022 at 1:15 AM Palmer Dabbelt wrote:
> On Thu, 13 Oct 2022 15:39:39 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
> >
> > On 10/11/22 17:31, Vineet Gupta wrote:
> >>
> >>>
> >>> I expect that the pressure for a proper fix upstream (instead of a
> >>> backward compatible compromise)
On 10/14/22 08:12, Richard Biener wrote:
> On Fri, Oct 14, 2022 at 12:54 AM Eric Botcazou via Gcc-patches
> wrote:
>>
>>> Not a fan as it could potentially hide a real issue, but I don't really
>>> have a better solution.
>>
>> Thanks.
>>
>>> I pondered suggesting "access" affect type identity, bu
On Fri, Oct 14, 2022 at 12:03:16PM +0200, Aldy Hernandez via Gcc-patches wrote:
> gcc/ChangeLog:
>
> * gimple-range-op.cc
> (gimple_range_op_handler::maybe_builtin_call): Add
> CFN_BUILT_IN_SIGNBIT[FL]* entries.
> ---
> gcc/gimple-range-op.cc | 2 ++
> 1 file changed, 2 insertio
On 13/10/2022 13:39, Richard Biener wrote:
> On Tue, Oct 11, 2022 at 2:43 PM Jørgen Kvalsvik
> wrote:
>>
>> The coverage support will under some conditions decide to split edges to
>> accurately report coverage. By running the test suite with/without this
>> edge splitting a small diff shows up, a
On Thursday, 13 October 2022 23:16:02 CEST Jason Merrill wrote:
> I liked in the previous version that you checked the return type of
> main when !flag_hosted, here and in c_missing_noreturn_ok_p. Let's
> bring that back.
Ah, right; I forgot about that. What do you think of this?
Thanks,
--
A
gcc/ChangeLog:
* gimple-range-op.cc
(gimple_range_op_handler::maybe_builtin_call): Add
CFN_BUILT_IN_SIGNBIT[FL]* entries.
---
gcc/gimple-range-op.cc | 2 ++
1 file changed, 2 insertions(+)
diff --git a/gcc/gimple-range-op.cc b/gcc/gimple-range-op.cc
index bc4389eb2e1..9bd
This is the infamous PR rtl-optimization/38644 rearing its ugly head for leaf
functions on SPARC more than a decade later... Richard E.'s generic solution
has never been implemented so let's do as other RISC back-ends did.
Tested on SPARC64/Linux, applied on all active branches.
2022-10-14 E
The following fixes an omission from adding SLP permute nodes which
is live lanes originating from those. We have to check that we
can extract the lane and have to actually code generate them.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
PR tree-optimization/107254
On Fri, 14 Oct 2022, Andrew Stubbs wrote:
> On 14/10/2022 08:07, Richard Biener wrote:
> > On Tue, 11 Oct 2022, Richard Sandiford wrote:
> >
> >> Richard Biener writes:
> >>> On Mon, 10 Oct 2022, Andrew Stubbs wrote:
> On 10/10/2022 12:03, Richard Biener wrote:
> > The following picks u
On 14/10/2022 08:07, Richard Biener wrote:
On Tue, 11 Oct 2022, Richard Sandiford wrote:
Richard Biener writes:
On Mon, 10 Oct 2022, Andrew Stubbs wrote:
On 10/10/2022 12:03, Richard Biener wrote:
The following picks up the prototype by Ju-Zhe Zhong for vectorizing
first order recurrences.
On 10/11/22 13:22, LIU Hao wrote:
在 2022-10-10 23:56, LIU Hao 写道:
在 2022-10-04 20:44, LIU Hao 写道:
Attached are revised patches. These are exported from trunk.
Revised further. The patch for libgfortran has been committed to trunk
today, so I include only the other two.
* In the second
Pushed to trunk.
-- >8 --
This makes the comment easier to read in the source, without altering
the Doxygen output.
libstdc++-v3/ChangeLog:
* include/std/iostream: Use markdown in Doxygen comment.
---
libstdc++-v3/include/std/iostream | 6 +++---
1 file changed, 3 insertions(+), 3 dele
This patch tries to add a parameter to generate instruction prefetch
instead of data prefetch. Currently, __builtin_prefetch assumes data
prefetch only.
On Fri, Oct 14, 2022 at 4:39 PM Haochen Jiang via Gcc-patches
wrote:
>
> gcc/ChangeLog:
>
> * builtins.cc (expand_builtin_prefetch): Han
gcc/ChangeLog:
* builtins.cc (expand_builtin_prefetch): Handle the fourth parameter in
expand function.
* config/aarch64/aarch64-sve.md: Add default parameter value.
* config/aarch64/aarch64.md (prefetch): New define_expand.
(*prefetch): Add default paramete
gcc/ChangeLog:
* common/config/i386/cpuinfo.h (get_available_features):
Detect PREFETCHI.
* common/config/i386/i386-common.cc
(OPTION_MASK_ISA2_PREFETCHI_SET,
OPTION_MASK_ISA2_PREFETCHI_UNSET): New.
(ix86_handle_option): Handle -mprefetchi.
*
> On 14 Oct 2022, at 09:30, Hongtao Liu wrote:
>
> On Fri, Oct 14, 2022 at 4:24 PM Iain Sandoe wrote:
>>
>>
>>
>>> On 14 Oct 2022, at 09:20, Hongtao Liu wrote:
>>>
>>> On Fri, Oct 14, 2022 at 4:14 PM Iain Sandoe via Gcc-patches
>>> wrote:
Hi Haochen
> On 14 Oct 2022
Hi all,
Sorry for the previous cover-letter stucking and disturbance and this
is the right cover letter.
These two patches aimed to add Intel PREFETCHI.
The information is based on newly released
Intel Architecture Instruction Set Extensions and Future Features.
The document comes following:
ht
> >> I could not see any target-requires changes in the testcases .. hence my
> >> question.
> >>
> > Guess you are looking at compile tests?
>
> yes, compile tests would need support from the assembler.
> >
In my understanding, dg-do compile tests don't need assembler support,
it just scan dump o
On Fri, Oct 14, 2022 at 4:24 PM Iain Sandoe wrote:
>
>
>
> > On 14 Oct 2022, at 09:20, Hongtao Liu wrote:
> >
> > On Fri, Oct 14, 2022 at 4:14 PM Iain Sandoe via Gcc-patches
> > wrote:
> >>
> >> Hi Haochen
> >>
> >>> On 14 Oct 2022, at 08:54, Haochen Jiang via Gcc-patches
> >>> wrote:
> >>>
>
> On 14 Oct 2022, at 09:20, Hongtao Liu wrote:
>
> On Fri, Oct 14, 2022 at 4:14 PM Iain Sandoe via Gcc-patches
> wrote:
>>
>> Hi Haochen
>>
>>> On 14 Oct 2022, at 08:54, Haochen Jiang via Gcc-patches
>>> wrote:
>>>
>>
>>> These six patches aimed to add Intel Sierra Forest instructions,
On Fri, Oct 14, 2022 at 4:14 PM Iain Sandoe via Gcc-patches
wrote:
>
> Hi Haochen
>
> > On 14 Oct 2022, at 08:54, Haochen Jiang via Gcc-patches
> > wrote:
> >
>
> > These six patches aimed to add Intel Sierra Forest instructions, including
> > AVX-IFMA, AVX-VNNI0INT8, AVX-NE-CONVERT, CMPccXADD.
gcc/ChangeLog:
* builtins.cc (expand_builtin_prefetch): Handle the fourth parameter in
expand function.
* config/aarch64/aarch64-sve.md: Add default parameter value.
* config/aarch64/aarch64.md (prefetch): New define_expand.
(*prefetch): Add default paramete
gcc/ChangeLog:
* common/config/i386/cpuinfo.h (get_available_features):
Detect PREFETCHI.
* common/config/i386/i386-common.cc
(OPTION_MASK_ISA2_PREFETCHI_SET,
OPTION_MASK_ISA2_PREFETCHI_UNSET): New.
(ix86_handle_option): Handle -mprefetchi.
*
Hi Haochen
> On 14 Oct 2022, at 08:54, Haochen Jiang via Gcc-patches
> wrote:
>
> These six patches aimed to add Intel Sierra Forest instructions, including
> AVX-IFMA, AVX-VNNI0INT8, AVX-NE-CONVERT, CMPccXADD. We also added intrinsic
> for vector __bf16 in this series of patch and Sierra Fore
On Thu, Oct 13, 2022 at 3:52 PM Toon Moene wrote:
>
> It was just a comment on the code of the PR ...
Ahh... the patch adds support for ranger handling of floating point
PLUS_EXPRs in the IL. The PR's testcase is just one of the many
things it will be able to solve.
Aldy
>
> Toon.
>
> On 10/13
From: Hongyu Wang
Hi all,
This patch aimed to add Intel AMX-FP16 ISA according to newly
released Intel Architecture Instruction Set Extensions and Future Features.
The document comes following:
https://www.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extension
From: Kong Lingling
gcc/ChangeLog:
* common/config/i386/i386-common.cc
(OPTION_MASK_ISA2_AVXNECONVERT_SET,
OPTION_MASK_ISA2_AVXNECONVERT_UNSET): New.
(ix86_handle_option): Handle -mavxneconvert, unset
avxneconvert when avx2 is disabled.
* common/co
gcc/ChangeLog:
* common/config/i386/cpuinfo.h (get_available_features):
Detect cmpccxadd.
* common/config/i386/i386-common.cc
(OPTION_MASK_ISA2_CMPCCXADD_SET,
OPTION_MASK_ISA2_CMPCCXADD_UNSET): New.
(ix86_handle_option): Handle -mcmpccxadd, unset cmp
From: Kong Lingling
gcc/ChangeLog
* common/config/i386/cpuinfo.h (get_available_features): Detect
avxvnniint8.
* common/config/i386/i386-common.cc
(OPTION_MASK_ISA2_AVXVNNIINT8_SET): New.
(OPTION_MASK_ISA2_AVXVNNIINT8_UNSET): Ditto.
(ix86_handle_op
1 - 100 of 111 matches
Mail list logo
