Just completed the rv64imac test for fully regression test, there is NO
increased failures.
For FP_RETURN, I think the ABI side somehow has some restrictions similar to
TARGET_HARD_FLOAT (of course as is). For example, the rv64imac cannot work
with lp64f/d, thus the FP_RETURN will be right REG
On Fri, Apr 12, 2024 at 06:00:24PM +0100, Andrew Carlotti wrote:
> On Fri, Apr 12, 2024 at 04:49:03PM +0100, Richard Sandiford wrote:
> > Andrew Carlotti writes:
> > > We don't yet have a separate feature flag for FEAT_LRCPC2 (and adding
> > > one will require extending the feature bitmask).
The x86 instruction size limit is 15 bytes. If a NDD instruction has
a segment prefix byte, a 4-byte opcode prefix, a MODRM byte, a SIB byte,
a 4-byte displacement and a 4-byte immediate, adding an address size
prefix will exceed the size limit. Change TImode ADD, AND, OR and XOR
to allow
Hi Roger!
On 2023-01-09T13:29:14+, "Roger Sayle" wrote:
> The result of a POPCOUNT operation in RTL should have the same mode
> as its operand. This corrects the specification of popcount in
> the nvptx backend, splitting the current generic define_insn into
> two, one for popcountsi2 and
On Fri, 12 Apr 2024, 21:51 H.J. Lu, wrote:
> * config/abi/post/x86_64-linux-gnu/x32/baseline_symbols.txt:
> Updated.
>
OK thanks
---
> .../abi/post/x86_64-linux-gnu/x32/baseline_symbols.txt | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git
>
On Fri, Apr 12, 2024 at 04:15:45PM -0400, Jason Merrill wrote:
> On 3/14/24 17:26, Marek Polacek wrote:
> >
> > In the following patch, I'm taking a different tack. I believe
> > we ought to use TARGET_EXPR_ELIDING_P. The gimplify_arg bit I'm
> > talking about below is this:
> >
> >/*
* config/abi/post/x86_64-linux-gnu/x32/baseline_symbols.txt:
Updated.
---
.../abi/post/x86_64-linux-gnu/x32/baseline_symbols.txt | 6 ++
1 file changed, 6 insertions(+)
diff --git
a/libstdc++-v3/config/abi/post/x86_64-linux-gnu/x32/baseline_symbols.txt
On 4/11/24 11:23 PM, Peter Bergner wrote:
> I'll make the changes above, modulo leaving the option name unchanged until
> we hear from Segher on that and report back on the LE and BE testing.
I made all of the requested changes and went with -mpower8-internal since
Segher was fine with that
On Fri, 12 Apr 2024, Jason Merrill wrote:
> On 3/26/24 09:44, Patrick Palka wrote:
> > On Thu, 7 Mar 2024, Jason Merrill wrote:
> >
> > > On 1/29/24 17:42, Patrick Palka wrote:
> > > > On Mon, 29 Jan 2024, Patrick Palka wrote:
> > > >
> > > > > On Fri, 26 Jan 2024, Jason Merrill wrote:
> > > >
On 3/14/24 17:26, Marek Polacek wrote:
In the following patch, I'm taking a different tack. I believe
we ought to use TARGET_EXPR_ELIDING_P. The gimplify_arg bit I'm
talking about below is this:
/* Also strip a TARGET_EXPR that would force an extra copy. */
if (TREE_CODE
On 3/26/24 09:24, Nathaniel Shead wrote:
I wonder if more generally we need to be doing more work when importing
definitions from header units especially to handle all the work that
'make_rtl_for_nonlocal_decl' and 'rest_of_decl_compilation' would have
been performing.
Can we just call those
On 3/26/24 09:44, Patrick Palka wrote:
On Thu, 7 Mar 2024, Jason Merrill wrote:
On 1/29/24 17:42, Patrick Palka wrote:
On Mon, 29 Jan 2024, Patrick Palka wrote:
On Fri, 26 Jan 2024, Jason Merrill wrote:
On 1/26/24 17:11, Jason Merrill wrote:
On 1/26/24 16:52, Jason Merrill wrote:
On
On Fri, 12 Apr 2024 12:25:42 PDT (-0700), tschwi...@baylibre.com wrote:
Hi!
After having received around a dozen more buildbot notifications...
On 2024-04-10T06:46:04-0700, Palmer Dabbelt wrote:
On Tue, 09 Apr 2024 07:57:24 PDT (-0700), ishitatsuy...@gmail.com wrote:
Fixes: 97069657c4e
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
The second testcase in 113141 is a separate issue: we first decide that the
conversion is ill-formed, but then when recalculating the special c_cast_p
handling makes us think it's OK. We don't want that, it should continue to
fall back to
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
The original testcase in PR113141 is an instance of CWG1996; the standard
fails to consider conversion functions when initializing a reference
directly from an initializer-list of one element, but then does consider
them when initializing a
Hi!
After having received around a dozen more buildbot notifications...
On 2024-04-10T06:46:04-0700, Palmer Dabbelt wrote:
> On Tue, 09 Apr 2024 07:57:24 PDT (-0700), ishitatsuy...@gmail.com wrote:
>> Fixes: 97069657c4e ("RISC-V: Implement TLS Descriptors.")
>>
>> gcc/ChangeLog:
>> *
On 4/12/24 14:39, Patrick Palka wrote:
On Fri, 12 Apr 2024, Jason Merrill wrote:
On 4/12/24 13:48, Patrick Palka wrote:
On Fri, 12 Apr 2024, Jason Merrill wrote:
On 4/12/24 10:35, Patrick Palka wrote:
On Wed, 10 Apr 2024, Jason Merrill wrote:
On 4/10/24 14:48, Patrick Palka wrote:
On
On 3/8/24 03:56, Jakub Jelinek wrote:
Hi!
My r9-6136 changes to make a copy of constexpr function bodies before
genericization modifies it broke the constant evaluation of non-POD
arguments passed by value.
In the callers such arguments are passed as reference to usually a
TARGET_EXPR, but on
On Fri, 12 Apr 2024, Jason Merrill wrote:
> On 4/12/24 13:48, Patrick Palka wrote:
> > On Fri, 12 Apr 2024, Jason Merrill wrote:
> >
> > > On 4/12/24 10:35, Patrick Palka wrote:
> > > > On Wed, 10 Apr 2024, Jason Merrill wrote:
> > > >
> > > > > On 4/10/24 14:48, Patrick Palka wrote:
> > > > >
On 3/22/24 04:08, Jakub Jelinek wrote:
Hi!
The middle-end warns about the ANNOTATE_EXPR added for while/for loops
if they declare a var inside of the loop condition.
This is because the assumption is that ANNOTATE_EXPR argument is used
immediately in a COND_EXPR (later GIMPLE_COND), but
On 4/12/24 13:48, Patrick Palka wrote:
On Fri, 12 Apr 2024, Jason Merrill wrote:
On 4/12/24 10:35, Patrick Palka wrote:
On Wed, 10 Apr 2024, Jason Merrill wrote:
On 4/10/24 14:48, Patrick Palka wrote:
On Tue, 9 Apr 2024, Jason Merrill wrote:
On 3/5/24 10:31, Patrick Palka wrote:
On Tue,
On 4/11/24 20:41, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
OK.
-- >8 --
While working on some other fixes I noticed that the partition handling
code used the wrong flag to propagate OVL_HIDDEN_P on exported bindings
from partitions. This patch
On 4/11/24 20:40, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
The modules code currently neglects to set OVL_USING_P on the dependency
created for a using-decl, which causes it not to remember that the
OVL_EXPORT_P flag had been set on it
On Fri, 12 Apr 2024, Jason Merrill wrote:
> On 4/12/24 10:35, Patrick Palka wrote:
> > On Wed, 10 Apr 2024, Jason Merrill wrote:
> >
> > > On 4/10/24 14:48, Patrick Palka wrote:
> > > > On Tue, 9 Apr 2024, Jason Merrill wrote:
> > > >
> > > > > On 3/5/24 10:31, Patrick Palka wrote:
> > > > > >
On 4/11/24 20:40, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
OK.
-- >8 --
A typo in r14-6978 made us emit too many things. This ensures that we
don't emit using-declarations from the GMF that we don't need to.
PR c++/114600
On 4/12/24 09:12, Jakub Jelinek wrote:
Hi!
I had another look at this P1 PR today.
You said in the "c++: fix in-charge parm in constexpr" mail back in December
(as well as in the r14-6507 commit message):
"Since a class with vbases can't have constexpr 'tors there isn't actually
a need for an
On 4/12/24 09:47, Patrick Palka wrote:
The original PR114393 testcase is unfortunately still not accepted after
r14-9938-g081c1e93d56d35 due to return type deduction confusion when a
lambda-expr is used as a default template argument.
The below reduced testcase demonstrates the bug. Here,
Hello Alex:
On 12/04/24 8:15 pm, Alex Coplan wrote:
> On 12/04/2024 20:02, Ajit Agarwal wrote:
>> Hello Alex:
>>
>> On 11/04/24 7:55 pm, Alex Coplan wrote:
>>> On 10/04/2024 23:48, Ajit Agarwal wrote:
Hello Alex:
On 10/04/24 7:52 pm, Alex Coplan wrote:
> Hi Ajit,
>
> On
On 4/12/24 10:35, Patrick Palka wrote:
On Wed, 10 Apr 2024, Jason Merrill wrote:
On 4/10/24 14:48, Patrick Palka wrote:
On Tue, 9 Apr 2024, Jason Merrill wrote:
On 3/5/24 10:31, Patrick Palka wrote:
On Tue, 27 Feb 2024, Patrick Palka wrote:
Subject: [PATCH] c++/modules: local type merging
On Fri, Apr 12, 2024 at 04:49:03PM +0100, Richard Sandiford wrote:
> Andrew Carlotti writes:
> > We don't yet have a separate feature flag for FEAT_LRCPC2 (and adding
> > one will require extending the feature bitmask). Instead, make the
> > FEAT_LRCPC patterns available when either armv8.4-a or
The svzero_mask_za intrinsic tried to use the shortest combination
of .b, .h, .s and .d tiles, allowing mixtures of sizes where necessary.
However, Iain S pointed out that LLVM instead requires the tiles to
have the same suffix. GAS supports both versions, so this patch
generates the
Hi Andrew,
Thanks for doing this. I think it improves the organisation of the
FMV documentation and adds some details that were previously missing.
I've made some suggestions below, but documentation is subjective
and I realise that not everyone will agree with them.
I've also added Sandra to
Andrew Carlotti writes:
> We don't yet have a separate feature flag for FEAT_LRCPC2 (and adding
> one will require extending the feature bitmask). Instead, make the
> FEAT_LRCPC patterns available when either armv8.4-a or +rcpc3 is
> specified. On the other hand, we already have a +rcpc flag,
Andrew Carlotti writes:
> FEAT_CSSC is mandatory in the architecture from Armv8.9.
>
> gcc/ChangeLog:
>
> * config/aarch64/aarch64-arches.def: Add CSSC to V8_9A
> dependencies.
OK, thanks.
Richard
>
> ---
>
> Bootstrapped and regression tested on aarch64. Ok for master?
>
>
> diff
On 12/04/2024 20:02, Ajit Agarwal wrote:
> Hello Alex:
>
> On 11/04/24 7:55 pm, Alex Coplan wrote:
> > On 10/04/2024 23:48, Ajit Agarwal wrote:
> >> Hello Alex:
> >>
> >> On 10/04/24 7:52 pm, Alex Coplan wrote:
> >>> Hi Ajit,
> >>>
> >>> On 10/04/2024 15:31, Ajit Agarwal wrote:
> Hello Alex:
On Wed, 10 Apr 2024, Jason Merrill wrote:
> On 4/10/24 14:48, Patrick Palka wrote:
> > On Tue, 9 Apr 2024, Jason Merrill wrote:
> >
> > > On 3/5/24 10:31, Patrick Palka wrote:
> > > > On Tue, 27 Feb 2024, Patrick Palka wrote:
> > > >
> > > > Subject: [PATCH] c++/modules: local type merging
Hello Alex:
On 11/04/24 7:55 pm, Alex Coplan wrote:
> On 10/04/2024 23:48, Ajit Agarwal wrote:
>> Hello Alex:
>>
>> On 10/04/24 7:52 pm, Alex Coplan wrote:
>>> Hi Ajit,
>>>
>>> On 10/04/2024 15:31, Ajit Agarwal wrote:
Hello Alex:
On 10/04/24 1:42 pm, Alex Coplan wrote:
> Hi
We don't yet have a separate feature flag for FEAT_LRCPC2 (and adding
one will require extending the feature bitmask). Instead, make the
FEAT_LRCPC patterns available when either armv8.4-a or +rcpc3 is
specified. On the other hand, we already have a +rcpc flag, so this
dependency can be
FEAT_CSSC is mandatory in the architecture from Armv8.9.
gcc/ChangeLog:
* config/aarch64/aarch64-arches.def: Add CSSC to V8_9A
dependencies.
---
Bootstrapped and regression tested on aarch64. Ok for master?
diff --git a/gcc/config/aarch64/aarch64-arches.def
Hi!
On Thu, Apr 11, 2024 at 11:23:02PM -0500, Peter Bergner wrote:
> On 4/11/24 10:31 PM, Kewen.Lin wrote:
> >> +;; This option exists only to create its MASK. It is not intended for
> >> users.
> >> +mdo-not-use-this-option
> >> +Target RejectNegative Mask(POWER8) Var(rs6000_isa_flags)
Resending to CC some relevant reviewers.
I'll remove "memtag", "ssbs" and "ls64" from the AArch64 feature list before
committing, following changes to my recent AArch64 patch series.
On Tue, Apr 09, 2024 at 02:35:48PM +0100, Andrew Carlotti wrote:
> Add target_version attribute to Common
gcc/c-family/ChangeLog:
* c-ubsan.cc (get_bound_from_access_with_size): New function.
(ubsan_instrument_bounds): Handle call to .ACCESS_WITH_SIZE.
gcc/testsuite/ChangeLog:
* gcc.dg/ubsan/flex-array-counted-by-bounds-2.c: New test.
*
gcc/ChangeLog:
* tree-object-size.cc (access_with_size_object_size): New function.
(call_object_size): Call the new function.
gcc/testsuite/ChangeLog:
* gcc.dg/builtin-object-size-common.h: Add a new macro EXPECT.
* gcc.dg/flex-array-counted-by-3.c: New test.
to carry the TYPE of the flexible array.
Such information is needed during tree-object-size.cc.
We cannot use the result type or the type of the 1st argument
of the routine .ACCESS_WITH_SIZE to decide the element type
of the original array due to possible type casting in the
source code.
Including the following changes:
* The definition of the new internal function .ACCESS_WITH_SIZE
in internal-fn.def.
* C FE converts every reference to a FAM with a "counted_by" attribute
to a call to the internal function .ACCESS_WITH_SIZE.
(build_component_ref in c_typeck.cc)
This
'counted_by (COUNT)'
The 'counted_by' attribute may be attached to the C99 flexible
array member of a structure. It indicates that the number of the
elements of the array is given by the field "COUNT" in the
same structure as the flexible array member.
GCC may use this
Hi,
This is the 9th version of the patch.
Compare with the 8th version, the difference are:
updates per Joseph's comments:
1. in C FE, add checking for counted_by attribute for the new multiple
definitions of the same tag for C23 in the routine
"tagged_types_tu_compatible_p".
Add a new
On Wed, 10 Apr 2024, Jason Merrill wrote:
> On 3/27/24 10:01, Patrick Palka wrote:
> > On Mon, 25 Mar 2024, Patrick Palka wrote:
> > > On Mon, 25 Mar 2024, Patrick Palka wrote:
> > > >
> > > > The below testcases use a lambda-expr as a template argument and they
> > > > all trip over the below
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
The original PR114393 testcase is unfortunately still not accepted after
r14-9938-g081c1e93d56d35 due to return type deduction confusion when a
lambda-expr is used as a default template argument.
The below
Richard Biener writes:
> On Fri, 12 Apr 2024, Tamar Christina wrote:
>
>> Hi All,
>>
>> This is a story all about how the peeling for gaps introduces a bug in the
>> upper
>> bounds.
>>
>> Before I go further, I'll first explain how I understand this to work for
>> loops
>> with a single
On 4/12/24 10:16, Stefan Schulze Frielinghaus wrote:
> As mentioned in PR114678 those failures will be fixed by
> https://gcc.gnu.org/pipermail/gcc-patches/2024-March/648303.html
> For GCC 14 just xfail them which should be reverted once the patch is
> applied.
>
> gcc/testsuite/ChangeLog:
>
>
Hi!
I had another look at this P1 PR today.
You said in the "c++: fix in-charge parm in constexpr" mail back in December
(as well as in the r14-6507 commit message):
"Since a class with vbases can't have constexpr 'tors there isn't actually
a need for an in-charge parameter in a destructor" but
> Gentle ping. If this looks good, can someone commit to main (I don't have
> commit privileges). This is also something that could be considered for
> stable, since it's been around for many years.
Thanks for the patch. Pushed as
On Fri, 12 Apr 2024, Tamar Christina wrote:
> Hi All,
>
> This is a story all about how the peeling for gaps introduces a bug in the
> upper
> bounds.
>
> Before I go further, I'll first explain how I understand this to work for
> loops
> with a single exit.
>
> When peeling for gaps we peel
Alex Coplan writes:
> This is a v2 because I accidentally sent a WIP version of the patch last
> time round which used replace_equiv_address instead of
> replace_equiv_address_nv; that caused some ICEs (pointed out by the
> Linaro CI) since pair addressing modes aren't a subset of the addresses
>
Sure thing, the FP_RETURN only acts on ABI_xxx similar to below:
#define FP_RETURN (UNITS_PER_FP_ARG == 0 ? GP_RETURN : FP_ARG_FIRST)
I add some test for rv32/64imac option but don't cover all test cases without
f/d extension, will have a try and keep you posted.
Pan
-Original
From: Pan Li
This patch would like to fix the Werror=sign-compare similar to below:
gcc/config/riscv/riscv.cc: In function ‘void
riscv_validate_vector_type(const_tree, const char*)’:
gcc/config/riscv/riscv.cc:5614:23: error: comparison of integer
expressions of different signedness: ‘int’ and
Gentle ping. If this looks good, can someone commit to main (I don't have
commit privileges). This is also something that could be considered for stable,
since it's been around for many years.
-Ian
From: McInerney, Ian S
Sent: Thursday, April 4, 2024 4:16 PM
To: fort...@gcc.gnu.org ;
Hi All,
This is a story all about how the peeling for gaps introduces a bug in the upper
bounds.
Before I go further, I'll first explain how I understand this to work for loops
with a single exit.
When peeling for gaps we peel N < VF iterations to scalar.
This happens by removing N iterations
Does FP reg also need gurared with TARGET_HARD_FLOAT? could you try to
compile that case without F?
On Fri, Apr 12, 2024 at 2:19 PM Li, Pan2 wrote:
>
> Committed, thanks Juzhe.
>
>
>
> Pan
>
>
>
> From: juzhe.zh...@rivai.ai
> Sent: Friday, April 12, 2024 2:11 PM
> To: Li, Pan2 ; gcc-patches
>
On Fri, 12 Apr 2024, Haochen Jiang wrote:
> Uncomment that and commit as obvious.
Thank you!
Gerald
Hi,
On Fri, Apr 12 2024, Filip Kastl wrote:
> On Thu 2024-04-11 20:51:55, Thomas Schwinge wrote:
>> Hi!
>>
>> On 2024-04-11T19:52:51+0200, Martin Jambor wrote:
>> > contrib/check-params-in-docs.py is a script that checks that all
>> > options reported with ./gcc/xgcc -Bgcc --help=param are in
> Am 12.04.2024 um 09:58 schrieb Jakub Jelinek :
>
> Hi!
>
> While translation of the verifier messages is questionable, that case is
> something that ideally should never happen except to gcc developers
> and so pressumably English should be fine, we use error etc. APIs and
> those imply
Hi all,
When I am checking GCC14 documentation, I found that MCore forgot to uncomment
the title for their part, which caused the documentation is mixed with x86.
Uncomment that and commit as obvious.
Thx,
Haochen
---
htdocs/gcc-14/changes.html | 2 +-
1 file changed, 1 insertion(+), 1
> Am 12.04.2024 um 09:50 schrieb Jakub Jelinek :
>
> Hi!
>
> The tree-cfg.cc verifier only diagnoses returns_twice calls preceded
> by non-label/debug stmts if it is in a bb with abnormal predecessor.
> The following testcase shows that if a user lies in the attributes
> (a function which
This is a v2 because I accidentally sent a WIP version of the patch last
time round which used replace_equiv_address instead of
replace_equiv_address_nv; that caused some ICEs (pointed out by the
Linaro CI) since pair addressing modes aren't a subset of the addresses
that are accepted by
Hi,
This patch implemented optab_isnormal for SF/DF/TFmode by rs6000 test
data class instructions.
This patch relies on former patch which adds optab_isnormal.
https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649366.html
Bootstrapped and tested on powerpc64-linux BE and LE with no
As mentioned in PR114678 those failures will be fixed by
https://gcc.gnu.org/pipermail/gcc-patches/2024-March/648303.html
For GCC 14 just xfail them which should be reverted once the patch is
applied.
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/range-sincos.c: Xfail for s390.
*
Hi,
This patch adds an optab for __builtin_isnormal. The normal check can be
implemented on rs6000 by a single instruction. It needs an optab to be
expanded to the certain sequence of instructions.
The subsequent patches will implement the expand on rs6000.
Bootstrapped and tested on x86
Hi!
While translation of the verifier messages is questionable, that case is
something that ideally should never happen except to gcc developers
and so pressumably English should be fine, we use error etc. APIs and
those imply translatations and some translators translate it.
The following patch
Hi!
The tree-cfg.cc verifier only diagnoses returns_twice calls preceded
by non-label/debug stmts if it is in a bb with abnormal predecessor.
The following testcase shows that if a user lies in the attributes
(a function which never returns can't be pure, and can't return
twice when it doesn't
Hi!
On 2024-04-12T09:08:13+0200, Filip Kastl wrote:
> On Thu 2024-04-11 20:51:55, Thomas Schwinge wrote:
>> On 2024-04-11T19:52:51+0200, Martin Jambor wrote:
>> > contrib/check-params-in-docs.py is a script that checks that all
>> > options reported with ./gcc/xgcc -Bgcc --help=param are in
>>
On Fri, Apr 12, 2024 at 1:25 AM Andrew Pinski (QUIC)
wrote:
>
> > -Original Message-
> > From: Richard Biener
> > Sent: Thursday, April 11, 2024 2:31 AM
> > To: Andrew Pinski (QUIC)
> > Cc: gcc-patches@gcc.gnu.org
> > Subject: Re: [PATCH] match: Fix `!a?b:c` and `a?~t:t` patterns for
On Fri, Apr 12, 2024 at 6:53 AM Andrew Pinski wrote:
>
> The problem is `!a?b:c` pattern will create a COND_EXPR with an 1bit signed
> integer
> which breaks patterns like `a?~t:t`. This rejects when we have a signed
> operand for
> both patterns.
>
> Note for GCC 15, I am going to look at the
Hi Chung-Lin!
On 2024-04-11T22:08:47+0800, Chung-Lin Tang wrote:
> On 2024/3/15 7:24 PM, Thomas Schwinge wrote:
>> - if (n->refcount != REFCOUNT_INFINITY)
>> + if (n->refcount != REFCOUNT_INFINITY
>> + && n->refcount != REFCOUNT_ACC_MAP_DATA)
>>
On Thu 2024-04-11 20:51:55, Thomas Schwinge wrote:
> Hi!
>
> On 2024-04-11T19:52:51+0200, Martin Jambor wrote:
> > contrib/check-params-in-docs.py is a script that checks that all
> > options reported with ./gcc/xgcc -Bgcc --help=param are in
> > gcc/doc/invoke.texi and vice versa.
>
> Eh,
Committed, thanks Juzhe.
Pan
From: juzhe.zh...@rivai.ai
Sent: Friday, April 12, 2024 2:11 PM
To: Li, Pan2 ; gcc-patches
Cc: kito.cheng ; Li, Pan2
Subject: Re: [PATCH v1] RISC-V: Bugfix ICE non-vector in
TARGET_FUNCTION_VALUE_REGNO_P
LGTM。
On Thu, 11 Apr 2024, Thomas Schwinge wrote:
> Hi Chung-Lin, Richard!
>
> From me just a few mechanical pieces, see below. Richard, are you able
> to again comment on Chung-Lin's general strategy, as I'm not at all
> familiar with those parts of the code?
I've queued all stage1 material and
Hi,
This patch folds builtin_isfinite on IBM long double to builtin_isfinite on
double type. The former patch
https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649346.html
implemented the DFmode isfinite_optab.
Bootstrapped and tested on powerpc64-linux BE and LE with no
regressions. Is it
LGTM。
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2024-04-12 14:08
To: gcc-patches
CC: juzhe.zhong; kito.cheng; Pan Li
Subject: [PATCH v1] RISC-V: Bugfix ICE non-vector in
TARGET_FUNCTION_VALUE_REGNO_P
From: Pan Li
This patch would like to fix one ICE when vector is not enabled
in hook
From: Pan Li
This patch would like to fix one ICE when vector is not enabled
in hook TARGET_FUNCTION_VALUE_REGNO_P implementation. The vector
regno is available if and only if the TARGET_VECTOR is true. The
previous implement missed this condition and then result in ICE
when rv64gc build
On Fri, 12 Apr 2024, haochen.jiang wrote:
> On Linux/x86_64,
>
> c7e8a8d814229fd6fc4c16c2452f15dddc613479 is the first bad commit
> commit c7e8a8d814229fd6fc4c16c2452f15dddc613479
> Author: Richard Biener
> Date: Thu Apr 11 11:08:07 2024 +0200
>
> tree-optimization/109596 - wrong debug
Hi,
This patch implemented optab_finite for SF/DF/TFmode by rs6000 test
data class instructions.
This patch relies on former patch which adds optab_finite.
https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649339.html
Bootstrapped and tested on powerpc64-linux BE and LE with no
83 matches
Mail list logo
