In s390_expand_insv(), if generating code for ICM et al. src is a MEM
and gen_lowpart might force src into a register such that we end up with
patterns which do not match anymore. Use adjust_address() instead in
order to preserve a MEM.
Furthermore, it is not straight forward to enforce a subreg.
> On 15 Aug 2024, at 18:48, Andrew Carlotti wrote:
>
> External email: Use caution opening links or attachments
>
>
> On Thu, Aug 15, 2024 at 05:15:03PM +0100, Richard Sandiford wrote:
>> Andrew Carlotti writes:
>>> This series of patches fixes issues with some intrinsics being incorrectly
>
Sorry for long time no update of subreg stuff.
I am working on it but recently get stuck in other project and I will be back
after I finish my recent project :)
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2024-08-15 05:55
To: Jeff Law; Xianmiao Qu; gcc-patches; roger; juzhe.zhong; richard.sandi
Hi, Zeng.
Thanks for fixing it.
LGTM from myside but since I am no expert on dwarf stuff.
I'd like to let kito or Robin review it again.
Thanks.
juzhe.zh...@rivai.ai
Currently subregs originating from *tf_to_fprx2_0 and *tf_to_fprx2_1
survive register allocation. This in turn leads to wrong register
renaming. Keeping the current approach would mean we need two insns for
*tf_to_fprx2_0 and *tf_to_fprx2_1, respectively. Something along the
lines
(define_insn
LGTM, thanks for fixing that :)
On Wed, Aug 14, 2024 at 2:06 PM 曾治金 wrote:
>
> This patch is to fix the bug (BugId:116305) introduced by the commit
> bd93ef for risc-v target.
>
> The commit bd93ef changes the chunk_num from 1 to TARGET_MIN_VLEN/128
> if TARGET_MIN_VLEN is larger than 128 in risc
On Fri, Aug 16, 2024 at 01:43:58AM +0200, Jakub Jelinek wrote:
> My reading of it wasn't that whether it is
> # embed < h-char-sequence > embed-parameter-sequence[opt] new-line
> or
> # embed < h-char-sequence > embed-parameter-sequence[opt] new-line
> or
> # embed pp-tokens new-line
> depends sole
Hi,
This patch folds builtin_isinf on IBM long double to builtin_isinf on
its high-order double.
The isinf_optab was already implemented in this patch.
https://gcc.gnu.org/g:53945be1efb502f235d84ff67ceafe4a764b6e1c
Bootstrapped and tested on powerpc64-linux BE and LE with no
regressions. Is
Hi,
This patch folds builtin_isfinite on IBM long double to builtin_isfinite
on its high-order double.
The isfinite_optab was already implemented in this patch.
https://gcc.gnu.org/g:44eb45c2ef7192eb6a811fd46fcb2c7fbeb6f865
Bootstrapped and tested on powerpc64-linux BE and LE with no
regres
Hi all,
any one for a review? This patch is over a month old and starts to rot.
Regtests ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline?
- Andre
On Fri, 9 Aug 2024 16:27:42 +0200
Andre Vehreschild wrote:
> Ping!
>
> On Wed, 17 Jul 2024 15:11:33 +0200
> Andre Vehreschild wrote:
>
> >
Ok for trunk and releases/gcc-14?
Verified this on x86_64 and arm-none-eabi.
Don't know if the other "truth type" dg-lines can be removed as well.
--
On Cortex-M55 with MVE, the test case fails due to -INT_MAX being
undefined. Adding -fwrapv solves the issues.
Regtested on x86_64-pc-linux and a
From: Mikael Morin
Regression-tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
Disable rewriting of MINLOC/MAXLOC expressions for which inline code
generation is supported. Update the gfc_inline_intrinsic_function_p
predicate (already existing) for that, with the current state of
MINLOC/
From: Mikael Morin
Regression-tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
Enable generation of inline code for the MINLOC and MAXLOC intrinsic,
if the ARRAY argument is of integral type and of any rank (only the rank 1
case was previously inlined), and neither DIM nor MASK arguments
From: Mikael Morin
The next patch will need reindenting of the array bound check generation
code. This outlines it to its own function beforehand, reducing the churn
in the next patch.
Regression-tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
gcc/fortran/ChangeLog:
* trans-ar
From: Mikael Morin
This patch is new in the V2 series.
Regression-tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
Remove the frontend pass rewriting calls of MINLOC/MAXLOC without DIM to
calls with one-valued DIM enclosed in an array constructor. This
transformation was circumventing t
From: Mikael Morin
Regression-tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
Enable generation of inline MINLOC/MAXLOC code in the case where DIM
is not present, and either ARRAY is of floating point type or MASK is an
array. Those cases are the remaining bits to fully support inlining
From: Mikael Morin
Hello,
this is the second version of the inline MINLOC/MAXLOC without DIM patchset
whose first version was posted before at:
https://gcc.gnu.org/pipermail/gcc-patches/2024-July/658909.html
Appart from the NAN skipping conditional likeliness which is left unchanged,
it takes i
From: Mikael Morin
Regression-tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
Enable the generation of inline code for MINLOC/MAXLOC when argument ARRAY
is of integral type, DIM is not present, and MASK is present and is scalar
(only absent MASK or rank 1 ARRAY were inlined before).
Sca
From: Mikael Morin
Regression-tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
Continue the second set of loops where the first one stopped in the
generated inline MINLOC/MAXLOC code in the cases where the generated code
contains two sets of loops. This fixes a regression that was introd
From: Mikael Morin
Regression-tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
Enable inline code generation for the MINLOC and MAXLOC intrinsic, if the
DIM argument is not present and ARRAY has rank 1. This case is similar to
the case where the result is scalar (DIM present and rank 1 A
From: Mikael Morin
Compared to the previous version of the patch at
https://gcc.gnu.org/pipermail/gcc-patches/2024-July/658916.html
this uses the IEEE_ARITHMETIC module to generate NAN values in the
tests. This change required to move the affected tests to a separate file
in the ieee/ subdirecto
From: Mikael Morin
This patch is new in the V2 series.
Regression-tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
Introduce the -finline-intrinsics flag to control from the command line
whether to generate either inline code or calls to the functions from the
library, for the MINLOC and
On Sat, Jul 20, 2024 at 02:42:23PM -0600, Sandra Loosemore wrote:
> --- a/gcc/c/c-parser.cc
> +++ b/gcc/c/c-parser.cc
> @@ -263,9 +263,24 @@ struct GTY(()) c_parser {
> otherwise NULL. */
>vec *in_omp_attribute_pragma;
>
> + /* When in_omp_attribute_pragma is non-null, these fields sa
On 15/08/2024 16:55, Jason Merrill wrote:
> On 8/12/24 1:55 PM, Alex Coplan wrote:
> > Hi!
> >
> > This is a v2 patch of:
> > https://gcc.gnu.org/pipermail/gcc-patches/2024-August/659968.html
> > that addresses Jakub's feedback.
> >
> > FWIW, I tried to contrive a testcase where convert_from_refe
On Fri, Aug 16, 2024 at 11:38:03AM +0100, Alex Coplan wrote:
> Looking at the calls to build3 (ANNOTATE_EXPR, ...) in cp/semantics.cc,
> it looks like the other two operands of ANNOTATE_EXPRs are only ever
> INTEGER_CSTs (the code in tree-cfg.cc:replace_loop_annotate_in_block
> corroborates this).
While this already works correctly for the case when an inlined
subroutine contains only one subrange, a redundant DW_TAG_lexical_block
is still emitted when the subroutine has multiple blocks.
Fixes: ac02e5b75451 ("re PR debug/37801 (DWARF output for inlined functions
doesn'
On Sat, Jul 20, 2024 at 02:42:24PM -0600, Sandra Loosemore wrote:
> + const char *old_name = IDENTIFIER_POINTER (name);
> + char *new_name = (char *) alloca (strlen (old_name) + 32);
XALLOCAVEC like for the C FE patch.
> + /* FIXME: I believe it is an unimplemented feature rather
> +
On 16/08/2024 12:47, Jakub Jelinek wrote:
> On Fri, Aug 16, 2024 at 11:38:03AM +0100, Alex Coplan wrote:
> > Looking at the calls to build3 (ANNOTATE_EXPR, ...) in cp/semantics.cc,
> > it looks like the other two operands of ANNOTATE_EXPRs are only ever
> > INTEGER_CSTs (the code in tree-cfg.cc:rep
On Sat, Jul 20, 2024 at 02:42:25PM -0600, Sandra Loosemore wrote:
> --- /dev/null
> +++ b/gcc/testsuite/c-c++-common/gomp/attrs-metadirective-1.c
> @@ -0,0 +1,41 @@
> +/* { dg-do compile { target { c || c++11 } } } */
> +/* { dg-options "-fopenmp -std=c23" { target { c } } } */
> +
> +#define N 100
Hi all,
attached patch is a follow up on the pr110033 patch and fixes two ICEs
reported in pr46371. With the patch also pr56496 is fixed, although that could
have been fixed by pr110033 already. I just added the testcase from pr56496 here
as coarray/select_type_3.f90 (I like it when the name of th
Hi there,
Please feel free to let me know if you don't have authority to commit it. I can
help to commit this patch.
Pan
-Original Message-
From: Kito Cheng
Sent: Friday, August 16, 2024 3:48 PM
To: 曾治金
Cc: gcc-patches@gcc.gnu.org; gcc-b...@gcc.gnu.org
Subject: Re: [PATCH] RISC-V: F
On Sat, Jul 20, 2024 at 02:42:26PM -0600, Sandra Loosemore wrote:
> This patch adds support for metadirectives to the Fortran front end.
> + else if (c->op == EXEC_OMP_METADIRECTIVE)
> +{
> + gfc_omp_variant *variant
> + = c->ext.omp_variants;
Why two lines? This is short enough to
Thanks Jeff and waterman for comments.
> What's more important is that we get the RTL semantics right, the fact
> that it seems to work due to addiw seems to be more of an accident than
> by design.
The SImode has different handling from day 1 which follow the algorithm up to a
point.
11842 i
Hi Pan,
I am a new guy for GCC and don't have authority to commit. Please help to
commit this patch. Thank you very much.
Zhijin
> From: "Li, Pan2"
> Date: Fri, Aug 16, 2024, 20:15
> Subject: RE: [PATCH] RISC-V: Fix factor in dwarf_poly_indeterminate_value
> [PR116305]
> To: "曾治金"
> Cc: "gcc-p
On Sat, Jul 20, 2024 at 02:42:27PM -0600, Sandra Loosemore wrote:
> The OpenMP spec says:
>
> "If trait-property any is specified in the kind trait-selector of the
> device selector set or the target_device selector sets, no other
> trait-property may be specified in the same selector set."
That
Ok for trunk and releases/gcc-14?
--
For some targets, like Cortex-M on arm-none-eabi, the -fshort-enums is
enabled by default. For these targets, the test case fails as
sizeof(Alpha) < sizeof(int).
To make the test case bahave identical for targets that does enable
-fshort-enums and those that d
On Fri, Aug 16, 2024 at 02:58:05PM +0200, Torbjörn SVENSSON wrote:
> Ok for trunk and releases/gcc-14?
>
> --
>
> For some targets, like Cortex-M on arm-none-eabi, the -fshort-enums is
> enabled by default. For these targets, the test case fails as
> sizeof(Alpha) < sizeof(int).
> To make the tes
Is this you newest version?
https://patchwork.sourceware.org/project/gcc/patch/8fd4328940034d8778cca67eaad54e5a2c2b1a6c.1c2f51e1.0a9a.4367.9762.9b6eccc3b...@feishu.cn/
If so, you may need to rebase upstream, I got conflict when git am.
Applying: RISC-V: Fix factor in dwarf_poly_indeterminate_valu
Sorry, the line number changed. The newest version as follow,
This patch is to fix the bug (BugId:116305) introduced by the commit
bd93ef for risc-v target.
The commit bd93ef changes the chunk_num from 1 to TARGET_MIN_VLEN/128
if TARGET_MIN_VLEN is larger than 128 in riscv_convert_vector_bits. So
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
Here we initialize an enumerator with a class prvalue with a conversion
function. When we fold it in build_enumerator, we create a TARGET_EXPR
for the object, and subsequently crash in tsubst_expr, which should not
see such a c
Ok for trunk and releases/gcc-14?
Changes since v1:
- Changed original test case to use -fno-short-enums.
- Added pruning of "use of enum values across objects may fail" warnings.
- Created a copy of the original test case and added -fshort-enums and removed
the xfail.
--
For some targets, lik
On 8/16/24 4:12 AM, Torbjörn SVENSSON wrote:
Ok for trunk and releases/gcc-14?
Verified this on x86_64 and arm-none-eabi.
Don't know if the other "truth type" dg-lines can be removed as well.
--
On Cortex-M55 with MVE, the test case fails due to -INT_MAX being
undefined. Adding -fwrapv solv
On 8/15/24 9:56 PM, Alexandre Oliva wrote:
Dump ICF-unified decls, thunks, aliases and whatnot along with their
ultimate targets, with edges from the alias to the target.
Add support for dropping the source file's suffix when forming from
dump-base, so that auxiliary files can be scanned, su
On 8/15/24 6:55 AM, Richard Sandiford wrote:
scanltranstree.exp defines some LTO wrappers around standard
non-LTO scanners. Four of them are cut-&-paste variants of
one another, so this patch generates them from a single template.
It also does the same for scan-ltrans-tree-dump-times, so that
Ok for trunk and releases/gcc-14?
--
The test case assumes that sizeof(tree_code) >= 2. On some targets, like
Cortex-M on arm-none-eabi, -fshort-enums is enabled by default and in
that case, sizeof(tree_code) will be 1 and the following warning is
emitted:
.../pr97315-1.C:8:13: warning: width of
From: kelefth
In expressions like (a != b || ((a ^ b) & CST0) == CST1) and
(a != b || (a ^ b) == CST), (a ^ b) is folded to false.
In the equivalent expressions (((a ^ b) & CST0) == CST1 || a != b) and
((a ^ b) == CST, (a ^ b) || a != b) this is not happening.
This patch adds the following simpl
On Tue, Aug 13, 2024 at 09:58:31PM -0600, Jeff Law wrote:
> Note this changes target independent code. So it needs to be bootstrapped
> and regression tested on one of the primary platforms:
>
> > The primary platforms are:
> >
> > aarch64-none-linux-gnu
> > arm-linux-gnueabi
> > i586-unknown-fr
On 2024-08-16 16:07, Jeff Law wrote:
On 8/16/24 4:12 AM, Torbjörn SVENSSON wrote:
Ok for trunk and releases/gcc-14?
Verified this on x86_64 and arm-none-eabi.
Don't know if the other "truth type" dg-lines can be removed as well.
--
On Cortex-M55 with MVE, the test case fails due to -INT_
On 8/12/24 5:13 AM, Matevos Mehrabyan wrote:
On Fri, Aug 2, 2024, 14:25 Richard Biener
mailto:richard.guent...@gmail.com>> wrote:
> On Wed, Jul 31, 2024 at 12:42 PM Mariam Arutunian
> mailto:mariamarutun...@gmail.com>> wrote:
>
> Gives an opportunity to execute
Manolis Tsamis writes:
> This pass detects cases of expensive store forwarding and tries to avoid them
> by reordering the stores and using suitable bit insertion sequences.
> For example it can transform this:
>
> strbw2, [x1, 1]
> ldr x0, [x1] # Expensive store forwarding
On Fri, Aug 16, 2024 at 04:15:10PM +0200, Torbjörn SVENSSON wrote:
> Ok for trunk and releases/gcc-14?
>
> --
>
> The test case assumes that sizeof(tree_code) >= 2. On some targets, like
> Cortex-M on arm-none-eabi, -fshort-enums is enabled by default and in
> that case, sizeof(tree_code) will be
Thanks, fixed (
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/660631.html).
On Thu, Aug 15, 2024 at 3:57 PM Sam James wrote:
> Konstantinos Eleftheriou writes:
>
> > From: kelefth
> >
> > In expressions like (a != b || ((a ^ b) & CST0) == CST1) and
> > (a != b || (a ^ b) == CST), (a ^
On 2024-08-16 16:37, Jakub Jelinek wrote:
On Fri, Aug 16, 2024 at 04:15:10PM +0200, Torbjörn SVENSSON wrote:
Ok for trunk and releases/gcc-14?
--
The test case assumes that sizeof(tree_code) >= 2. On some targets, like
Cortex-M on arm-none-eabi, -fshort-enums is enabled by default and in
th
On Fri, Aug 16, 2024 at 03:51:01PM +0200, Torbjörn SVENSSON wrote:
> gcc/testsuite/ChangeLog:
>
> * g++.dg/warn/pr33738.C: Added -fno-short-enums.
> * g++.dg/warn/pr33738-2.C: Duplicate g++.dg/warn/pr33738.C with
> -fshort-enums and removed xfail.
>
> Signed-off-by: Torbjörn SVE
On 2024-08-16 16:45, Jakub Jelinek wrote:
On Fri, Aug 16, 2024 at 03:51:01PM +0200, Torbjörn SVENSSON wrote:
gcc/testsuite/ChangeLog:
* g++.dg/warn/pr33738.C: Added -fno-short-enums.
* g++.dg/warn/pr33738-2.C: Duplicate g++.dg/warn/pr33738.C with
-fshort-enums and rem
Kewen:
Ping.
Carl
On 8/7/24 10:15 AM, Carl Love wrote:
GCC maintainers:
The following patch fixes errors in the definition of the
__builtin_vsx_uns_floate_v2di, __builtin_vsx_uns_floato_v2di and
__builtin_vsx_uns_float2_v2di built-ins. The arguments should be
unsigned but are
Ping.
Carl
On 8/9/24 8:57 AM, Carl Love wrote:
Gcc maintainers:
Version 2, based on discussion additional overloaded instances of the
vec_test_lsbb_all_ones and, vec_test_lsbb_all_zeros built-ins has been
added. The additional instances are for arguments of vector signed
On Fri, Aug 9, 2024 at 7:22 PM Richard Sandiford
wrote:
> Sorry again for the slow review. :(
>
> I only really looked at the unreversed version earlier, on the basis
> that the comments would apply to both versions. But I've got a couple
> of comments about the reversed version below:
>
> Maria
> -Original Message-
> From: Richard Biener
> Sent: Tuesday, August 13, 2024 10:06 PM
> To: Thomas Schwinge
> Cc: Prathamesh Kulkarni ; Andrew Pinski
> ; gcc-patches@gcc.gnu.org; Jakub Jelinek
>
> Subject: Re: [nvptx] Pass -m32/-m64 to host_compiler if it has
> multilib support
>
> Ex
> > Here during default template argument substitution we wrongly consider
> > the (substituted) default arguments v and vt as value-dependent[1]
> > which ultimately leads to deduction failure for the calls.
> >
> > The bogus value_dependent_expression_p result aside, I noticed
> > type_unificatio
On Fri, 16 Aug 2024, Jakub Jelinek wrote:
> > Apart from any consequences for arguments of prefix/suffix/is_empty (where
> > there is a plausible argument that the argument should get expanded at
> > some point and that the current wording is undesirable for usability),
> > this would also mean
Am 13.08.24 um 10:59 schrieb Mark Wielaard:
avr added an -mlra option, but the avr.opt.url file wasn't
regenerated.
Note that commit 149a23ee2568 ("AVR: -mlra is not documeted in TEXI.")
did add the Undocumented flag, but that still needs the avr.op.urls
file to be updated.
Fixes: 09a87ea666b2
On Fri, 16 Aug 2024, Jakub Jelinek wrote:
> On Fri, Aug 16, 2024 at 01:43:58AM +0200, Jakub Jelinek wrote:
> > My reading of it wasn't that whether it is
> > # embed < h-char-sequence > embed-parameter-sequence[opt] new-line
> > or
> > # embed < h-char-sequence > embed-parameter-sequence[opt] new-
Hi Andre,
Am 16.08.24 um 07:46 schrieb Andre Vehreschild:
Hi Harald,
s/doumentation/documentation/
in the commit's title.
oops! Thanks for pointing this out.
Fixed and pushed as r15-2955-g07ece73d4712c6 .
Harald
Thanks for the patch, ok to commit.
- Andre
On Thu, 15 Aug 2024 22:37:53
On Fri, Aug 16, 2024 at 04:05:52PM +, Joseph Myers wrote:
> On Fri, 16 Aug 2024, Jakub Jelinek wrote:
>
> > > Apart from any consequences for arguments of prefix/suffix/is_empty
> > > (where
> > > there is a plausible argument that the argument should get expanded at
> > > some point and th
On Thu, 15 Aug 2024, Jakub Jelinek wrote:
> + else
> + {
> + if (res > INTTYPE_MAXIMUM (off_t))
> + cpp_error_with_line (pfile, CPP_DL_ERROR, loc, 0,
> + "too large 'gnu::offset' argument");
Having a testcase for this diagnostic
Hi Andre,
Am 16.08.24 um 14:10 schrieb Andre Vehreschild:
Hi all,
attached patch is a follow up on the pr110033 patch and fixes two ICEs
reported in pr46371. With the patch also pr56496 is fixed, although that could
have been fixed by pr110033 already. I just added the testcase from pr56496 her
On Fri, 16 Aug 2024, Jakub Jelinek wrote:
> Ok. So for now, should I work on a patch variant which tries to follow
> what is in C23 right now?
Not sure how useful having such a patch variant would be until we have a
better idea of what the desired semantics actually are.
--
Joseph S. Myers
jo
As PR target/116174 shown, we may need to verify the directive order.
Extend check-function-bodies to cover directives.
* gcc.target/i386/pr116174.c: Use check-function-bodies.
* lib/scanasm.exp (configure_check-function-bodies): Add an
argument for fluff. Set up_config(fl
Hi Andre,
Am 16.08.24 um 12:05 schrieb Andre Vehreschild:
Hi all,
any one for a review? This patch is over a month old and starts to rot.
Regtests ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline?
this is good to go.
Thanks for the patch!
Harald
- Andre
On Fri, 9 Aug 2024 16:27:42
Hi!
Here it is in patch form, at the same time I've turned it into bit-fields.
On x86_64-linux, this reduced .rodata by 532 bytes (so 5.75x reduction
of the variable) and grew the cpp_set_lang function by 26 bytes (8.4%
growth).
So far smoke tested, ok for trunk if it passes full bootstrap/regtes
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
Here we ICE since r14-8291 in C++11/C++14 modes. Fortunately
this is an easy one.
The important bit of r14-8291 is this:
@@ -20056,9 +20071,12 @@ tsubst_expr (tree t, tree args, tsubst_flags_t
complain, tree in_decl)
rs6000 patches should CC the rs6000 port maintainers. I've CC'd them on
this note.
Peter
On 8/15/24 3:44 AM, Victor Do Nascimento wrote:
> Following the migration of the dot_prod optab from a direct to a
> conversion-type optab, ensure all back-end patterns incorporate the
> second machine mode
Thanks Jeff. No, CodeView is effectively Windows-specific - it relies on PE for
reporting the PDB filename, and COFF for the .secidx relocation. I might look
into moving these bits into the config once I get down to plumbing it for
aarch64-w64-mingw32.
Mark
On 14/08/2024 05:09, Jeff Law wrote
On aarch64 (without !CSSC instructions), since popcount is implemented using
the SIMD instruction cnt,
instead of using two SIMD cnt (V8QI mode), it is better to use one 128bit cnt
(V16QI mode). And only one
reduction addition instead of 2. Currently fold_builtin_bit_query will expand
always wit
When CSSC is not enabled, 128bit popcount can be implemented
just via the vector (v16qi) cnt instruction followed by a reduction,
like how the 64bit one is currently implemented instead of
splitting into 2 64bit popcount.
Build and tested for aarch64-linux-gnu.
PR target/113042
gcc/Chang
Never mind, looks still conflict, could you please help to double check about
it?
Current upstream should be 3c9c93f3c923c4a0ccd42db4fd26a944a3c91458.
└─(09:18:27 on master ✭)──> git apply tmp.patch
To start working on more with expressions with more than one operand, converting
over to use gimple_match_op is needed.
The added side-effect here is factor_out_conditional_operation can now support
builtins/internal calls that has one operand without any extra code added.
Note on the changed test
The patch for 3c9c93 as follow. But it's a little strange that this patch
hasn't changed and I don't know why it apply fail. May you directly modify the
riscv.cc if this version still conflict? The riscv.cc just changed two lines.
Thank you again.
Zhijjin
This patch is to fix the bug (BugId:116
From: Pan Li
For QI/HImode of .SAT_ADD, the operands may be sign-extended and the
high bits of Xmode may be all 1 which is not expected. For example as
below code.
signed char b[1];
unsigned short c;
signed char *d = b;
int main() {
b[0] = -40;
c = ({ (unsigned short)d[0] < 0xFFF6 ? (unsig
Ok, I will commit it if no surprise from test as manually changing.
Pan
-Original Message-
From: Zhijin Zeng
Sent: Saturday, August 17, 2024 10:46 AM
To: Li, Pan2
Cc: gcc-patches@gcc.gnu.org; gcc-b...@gcc.gnu.org; Kito Cheng
Subject: Re: [PATCH] RISC-V: Fix factor in dwarf_poly_indet
Should be in upstream already.
Pan
-Original Message-
From: Li, Pan2
Sent: Saturday, August 17, 2024 11:45 AM
To: Zhijin Zeng
Cc: gcc-patches@gcc.gnu.org; gcc-b...@gcc.gnu.org; Kito Cheng
Subject: RE: [PATCH] RISC-V: Fix factor in dwarf_poly_indeterminate_value
[PR116305]
Ok, I wil
This is my first time submitting a patch to gcc and sincerely thank you all for
your help.
Zhijin
> From: "Li, Pan2"
> Date: Sat, Aug 17, 2024, 12:15
> Subject: RE: [PATCH] RISC-V: Fix factor in dwarf_poly_indeterminate_value
> [PR116305]
> To: "Li, Pan2", "Zhijin Zeng"
> Cc: "gcc-patches@gcc.
Thanks Richard for confirmation. Sorry almost forget this thread.
Hi Jakub,
Please feel free to let me know if there is anything I can do to fix this
issue. Thanks a lot.
Pan
-Original Message-
From: Richard Biener
Sent: Tuesday, July 16, 2024 11:29 PM
To: Li, Pan2
Cc: gcc-patches@
84 matches
Mail list logo
