From: Sergei Trofimovich
gcc's build system has BOOT_CFLAGS and various STAGE_C{,XX}FLAGS
variables. BOOT_CXXFLAGS is not handled anywhere.
config/
* mh-mingw: Drop assignment of unused BOOT_CXXFLAGS variable.
---
config/mh-mingw | 1 -
1 file changed, 1 deletion(-)
diff --git a/confi
Hi all,
This patch fix a typo which will not cause any behavior difference.
Commited as obvious change.
Thx,
Haochen
gcc/ChangeLog:
* config/i386/i386.opt: Fix a typo.
---
gcc/config/i386/i386.opt | 5 -
1 file changed, 5 deletions(-)
diff --git a/gcc/config/i386/i386.opt b/gcc/c
Hi,
we have flow_loop_dump and print_loop. While print_loop was extended to dump
stuff from loop structure we added over years (loop info), flow_loop_dump was
not.
-fdump-tree-all files contains flow_loop_dump which makes it hard to see what
metadata we have attached to loop.
This patch unifies d
On Fri, Jul 21, 2023 at 9:48 AM Sergei Trofimovich via Gcc-patches
wrote:
>
> From: Sergei Trofimovich
>
> gcc's build system has BOOT_CFLAGS and various STAGE_C{,XX}FLAGS
> variables. BOOT_CXXFLAGS is not handled anywhere.
OK.
> config/
>
> * mh-mingw: Drop assignment of unused BOOT_CX
On Fri, Jul 21, 2023 at 9:57 AM Jan Hubicka via Gcc-patches
wrote:
>
> Hi,
> we have flow_loop_dump and print_loop. While print_loop was extended to dump
> stuff from loop structure we added over years (loop info), flow_loop_dump was
> not.
> -fdump-tree-all files contains flow_loop_dump which ma
Commited, thanks Richard.
Bootstrap and regression passed.
-- Original --
From:
"Richard Biener"
Commited, thanks Richard.
Bootstrap and regression passed.
-- Original --
From:
"Richard Biener"
On Jul 20, 2023, Richard Biener wrote:
> I wonder if we could have shared some of the cgraph/varasm bits
> with the symver attribute handling? It's just a new 'sym' but
> without the version part?
Possibly. process_common_attributes could be a good place to create the
alias decl, like symver d
Notice there is mistakes for RISC-V I made in the last patch.
Fix it. Sorry about that.
gcc/ChangeLog:
* config/riscv/riscv-v.cc (expand_gather_scatter): Remove redundant
variables.
---
gcc/config/riscv/riscv-v.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/
Hello Lehua,
On Wed, Jul 12 2023, Lehua Ding wrote:
> Hi,
>
> This tiny patch add --append option to mklog.py that support add generated
> ChangeLog to the corresponding patch file. With this option there is no need
> to manually copy the generated ChangeLog to the patch file. e.g.:
>
> Run `mklog
From: Ju-Zhe Zhong
Hi, Richard and Richi.
This patch support floating-point in-order reduction for loop length control.
Consider this following case:
float foo (float *__restrict a, int n)
{
float result = 1.0;
for (int i = 0; i < n; i++)
result += a[i];
return result;
}
When compile
Hi, all. From all previous cleanup patches.
Every thing related to "mask && len" are consistent now.
I rebase to the trunk and send V2 patch:
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625159.html
Thanks.
juzhe.zh...@rivai.ai
From: Richard Biener
Date: 2023-07-20 15:21
To: Robin Dap
The improve_allocation() routine does not update the
allocated_hardreg_p[] array after an allocno is assigned a register.
If the register chosen in improve_allocation() is one that already has
been assigned to a conflicting allocno, then allocated_hardreg_p[]
already has the corresponding bit set
Hi Martin,
> this patch caused flake8 to complain about contrib/mklog.py:
>
> $ flake8 contrib/mklog.py
> contrib/mklog.py:377:80: E501 line too long (85 > 79 characters)
> contrib/mklog.py:388:26: E127 continuation line over-indented for
visual indent
> contrib/mklog.py:388:36: W605 invalid es
Hello Lehua,
On Fri, Jul 21 2023, Lehua Ding wrote:
> Hi Martin,
>
>
> > this patch caused flake8 to complain about contrib/mklog.py:
> >
> > $ flake8 contrib/mklog.py
> > contrib/mklog.py:377:80: E501 line too long (85 > 79 characters)
> > contrib/mklog.py:388:26: E127 continuation line over-ind
> I am no python expert but the following seems to work:
Thank you so much, it works for me.
Lehua
On Fri, 21 Jul 2023, juzhe.zh...@rivai.ai wrote:
> From: Ju-Zhe Zhong
>
> Hi, Richard and Richi.
>
> This patch support floating-point in-order reduction for loop length control.
>
> Consider this following case:
>
> float foo (float *__restrict a, int n)
> {
> float result = 1.0;
> for (
Hi Martin,
By the way, is there a standard format required for these Python files?
I see that other Python files have similar format error when checked
using flake8. If so, it feels necessary to configure a git hook on git
server
to do this check.
Best,
Lehua
From: Ju-Zhe Zhong
Hi, Richard and Richi.
This patch support floating-point in-order reduction for loop length control.
Consider this following case:
float foo (float *__restrict a, int n)
{
float result = 1.0;
for (int i = 0; i < n; i++)
result += a[i];
return result;
}
When compile
Thanks Richi,
Address comment on V3:
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625167.html
Bootstrap and regression is on the way.
juzhe.zh...@rivai.ai
From: Richard Biener
Date: 2023-07-21 18:51
To: Ju-Zhe Zhong
CC: gcc-patches; richard.sandiford
Subject: Re: [PATCH V2] VECT: Sup
From: Ju-Zhe Zhong
Hi, Richard and Richi.
This patch support floating-point in-order reduction for loop length control.
Consider this following case:
float foo (float *__restrict a, int n)
{
float result = 1.0;
for (int i = 0; i < n; i++)
result += a[i];
return result;
}
When compile
Oh. Sorry for missing a fix, Now I fix as you suggested on V4
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625169.html
Change it as follows:
if (mask_reduc_fn == IFN_MASK_LEN_FOLD_LEFT_PLUS)
new_stmt = gimple_build_call_internal (mask_reduc_fn, 5, reduc_var,
Consider Signed-Off-By lines as part of the ending of the initial
commit to avoid having these in the middle of the log when the
changelog part is injected after.
This is particularly usefull with:
$ git gcc-commit-mklog --amend -s
that can be used to create the changelog and add the Signed-Off
This patch adds a warning for allocations with insufficient size
based on the "alloc_size" attribute and the type of the pointer
the result is assigned to. While it is theoretically legal to
assign to the wrong pointer type and cast it to the right type
later, this almost always indicates an er
Hi,
we have finite_p flag in loop structure. finite_loop_p already know to
use it, but we also may set the flag when we prove loop to be finite by
SCEV analysis to avoid duplicated work.
Bootstrapped/regtested x86_64-linux, OK?
gcc/ChangeLog:
* tree-ssa-loop-niter.cc (finite_loop_p): Re
On Fri, Jul 21, 2023 at 1:45 PM Jan Hubicka via Gcc-patches
wrote:
>
> Hi,
> we have finite_p flag in loop structure. finite_loop_p already know to
> use it, but we also may set the flag when we prove loop to be finite by
> SCEV analysis to avoid duplicated work.
>
> Bootstrapped/regtested x86_64
Hi everyone,
Looking forward to all your reviews.
Best regards,
Cupertino
New pseudo-c BPF assembly dialect already supported by clang and widely
used in the linux kernel.
gcc/ChangeLog:
* config/bpf/bpf.opt: Added option -masm=.
* config/bpf/bpf-opts.h: Likewize.
* con
On Fri, Jul 21, 2023 at 8:08 AM Kewen.Lin wrote:
>
> Hi,
>
> The function vect_update_epilogue_niters which has been
> removed by r14-2281 has some code taking care of that if
> there is only one scalar iteration left for epilogue then
> we won't try to vectorize it any more.
>
> Although costing
Hi,
currently loop-ch skips all do-while loops. But when loop is not do-while
in addition to original goal of turining it to do-while it can do additional
things:
1) move out loop invariant computations
2) duplicate loop invariant conditionals and eliminate them in loop body.
3) prove that some
Hello Lehua,
On Fri, Jul 21 2023, Lehua Ding wrote:
> Hi Martin,
>
>
> By the way, is there a standard format required for these Python files?
Generally, our Python coding conventions are at
https://gcc.gnu.org/codingconventions.html#python
> I see that other Python files have similar format err
gcc.dg/tree-ssa/forwprop-12.c looks for reconstruction of an
ARRAY_REF from pointer arithmetic and dereference. That's not
safe because ARRAY_REFs carry special semantics we later exploit
during data dependence analysis.
The following removes the testcase, closing the bug as WONTFIX.
Pushed.
On some AArch64 bootstrapped builds, we were getting a flaky test
because the floating point operations in `get_time` were being fused
with the floating point operations in `timevar_accumulate`.
This meant that the rounding behaviour of our multiplication with
`ticks_to_msec` was different when us
On Fri, Jul 21, 2023 at 1:53 PM Jan Hubicka via Gcc-patches
wrote:
>
> Hi,
> currently loop-ch skips all do-while loops. But when loop is not do-while
> in addition to original goal of turining it to do-while it can do additional
> things:
> 1) move out loop invariant computations
> 2) duplicat
On Fri, 21 Jul 2023, Matthew Malcomson wrote:
> On some AArch64 bootstrapped builds, we were getting a flaky test
> because the floating point operations in `get_time` were being fused
> with the floating point operations in `timevar_accumulate`.
>
> This meant that the rounding behaviour of our
On Fri, 2023-07-21 at 13:11 +0100, Matthew Malcomson via Gcc-patches
wrote:
> This change ensures those operations are not fused and hence stops the test
> being flaky on that particular machine. There is no expected change in the
> generated code.
> Bootstrap & regtest on AArch64 passes with no r
> > The patch requires bit of testsuite changes
> > - I disabled ch in loop-unswitch-17.c since it tests unswitching of
> >loop invariant conditional.
> > - pr103079.c needs ch disabled to trigger vrp situation it tests for
> >(otherwise we optimize stuff earlier and better)
> > - copy-h
Hello Cuper.
Thanks for the patch.
We will need an update for the "eBPF Options" section in the GCC manual,
documenting -masm=@var{dialect} and the supported values. Can you
please add it and re-submit?
> Hi everyone,
>
> Looking forward to all your reviews.
>
> Best regards,
> Cupertino
>
>
Responding to two emails at the same time ;-)
On 7/21/23 13:47, Richard Biener wrote:
On Fri, 21 Jul 2023, Matthew Malcomson wrote:
On some AArch64 bootstrapped builds, we were getting a flaky test
because the floating point operations in `get_time` were being fused
with the floating point ope
> Am 21.07.2023 um 15:12 schrieb Matthew Malcomson :
>
> Responding to two emails at the same time ;-)
>
>> On 7/21/23 13:47, Richard Biener wrote:
>>> On Fri, 21 Jul 2023, Matthew Malcomson wrote:
>>> On some AArch64 bootstrapped builds, we were getting a flaky test
>>> because the floating
On Fri, 2023-07-21 at 14:11 +0100, Matthew Malcomson wrote:
> My understanding is that this is not a hardware bug and that it's
> specified that rounding does not happen on the multiply "sub-part" in
> `FNMSUB`, but rounding happens on the `FMUL` that generates some input
> to it.
AFAIK the C st
On Fri, 21 Jul 2023, Xi Ruoyao via Gcc-patches wrote:
> Perhaps -ffp-contract=on (not off) is enough to fix the issue (if you
> are building GCC 14 snapshot). The default is "fast" (if no -std=
> option is used), which allows some contractions disallowed by the
> standard.
Not fully, see below
Hi Jose,
Thanks for the review.
New patch is inline attached.
Regards,
Cupertino
Jose E. Marchesi writes:
> Hello Cuper.
>
> Thanks for the patch.
>
> We will need an update for the "eBPF Options" section in the GCC manual,
> documenting -masm=@var{dialect} and the supported values. Can you
>
> gcc/ChangeLog:
>
> * config/bpf/bpf.opt: Added option -masm=.
> * config/bpf/bpf-opts.h: Likewize.
> * config/bpf/bpf.cc: Changed it to conform with new pseudoc
> dialect support.
> * config/bpf/bpf.h: Likewise.
> * config/bpf/bpf.md: Added pseudo-c templat
Hi Martin,
Thank you for telling me about the Python code format specification.
I'm no idea how to add checks for pushed commits.
Anyway, first make sure I don't introduce new format errors myself.
Best,
Lehua
Fix sreal::to_int and implement sreal::to_nearest_int
while exploring new loop estimate dumps, I noticed that loop iterating 1.8
times by profile is etimated as iterating once instead of 2 by nb_estimate.
While nb_estimate should really be a sreal and I will convert it incrementally,
I found probl
Tested with Darwin linker versions that do/do not support the option
and on x86_64-linux-gnu, pushed to trunk, thanks
Iain
--- 8< ---
Most of the Darwin linkers in use support this option which we will
now pass by default (matching the Xcode clang impl.)>
Signed-off-by: Iain Sandoe
gcc/ChangeL
Thanks for the suggestions/fixes in changelog.
Inlined new patch.
Cupertino
>> gcc/ChangeLog:
>>
>> * config/bpf/bpf.opt: Added option -masm=.
>> * config/bpf/bpf-opts.h: Likewize.
>> * config/bpf/bpf.cc: Changed it to conform with new pseudoc
>>dialect support.
>> *
On Thu, Jul 20, 2023 at 17:00:32 -0400, Nathan Sidwell wrote:
> On 7/19/23 20:47, Ben Boeckel wrote:
> > But it is inhibiting distributed builds because the distributing tool
> > would need to know:
> >
> > - what CMIs are actually imported (here, "read the module mapper file"
> >(in CMake's c
Simplifies (x << c) >> c where x is a signed integral type of
width >= int and c = precision(type) - 1 into -(x & 1). Tested successfully
on x86_64 and x86 targets.
PR middle-end/101955
gcc/ChangeLog:
* match.pd (x << c) >> c -> -(x & 1): New simplification.
gcc/testsuite/Change
> Thanks for the suggestions/fixes in changelog.
> Inlined new patch.
>
> Cupertino
>
>>> gcc/ChangeLog:
>>>
>>> * config/bpf/bpf.opt: Added option -masm=.
>>> * config/bpf/bpf-opts.h: Likewize.
>>> * config/bpf/bpf.cc: Changed it to conform with new pseudoc
>>> dialect support.
On Fri, 2023-07-21 at 16:58 +0300, Alexander Monakov wrote:
>
> On Fri, 21 Jul 2023, Xi Ruoyao via Gcc-patches wrote:
>
> > Perhaps -ffp-contract=on (not off) is enough to fix the issue (if you
> > are building GCC 14 snapshot). The default is "fast" (if no -std=
> > option is used), which allow
The test deliberately reads beyond bounds to exersize ubsan and the
return value may be anything, based on previous allocations. The OFF
test caters for it by ANDing the return with 0, do the same for the DYN
test.
gcc/testsuite/ChangeLog:
PR testsuite/110763
* gcc.dg/ubsan/objec
On 7/21/23 14:45, Xi Ruoyao wrote:
On Fri, 2023-07-21 at 14:11 +0100, Matthew Malcomson wrote:
My understanding is that this is not a hardware bug and that it's
specified that rounding does not happen on the multiply "sub-part" in
`FNMSUB`, but rounding happens on the `FMUL` that generates some
Hi,
Upon David's request I've joined the in progress patch to the below email.
I hope it makes more sense now.
Best,
Benjamin.
-- Forwarded message -
From: Benjamin Priour
Date: Tue, Jul 18, 2023 at 3:30 PM
Subject: [RFC] analyzer: Add optional trim of the analyzer diagnostics
g
Hi,
this patch adds maybe_flat_loop_profile which can be used in loop profile udpate
to detect situation where the profile may be unrealistically flat and should
not be dwonscalled after vectorizing, unrolling and other transforms that
assume that loop has high iteration count even if the CFG profi
Hi,
this patch fixes template in the two testcases so it matches the output
correctly. I did not re-test after last changes in the previous patch,
sorry for that.
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/copy-headers-9.c: Fix template for
tree-ssa-loop-ch.cc changes.
* gcc.dg/
On Fri, 21 Jul 2023, Xi Ruoyao wrote:
> > See also PR 99903 for an earlier known issue which appears due to x87
> > excess precision and so tweaking -ffp-contract wouldn't help:
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99903
>
> Does it affect AArch64 too?
Well, not literally (A
gcc/ChangeLog:
* config/bpf/bpf.md: fixed template for neg instruction.
---
gcc/config/bpf/bpf.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/config/bpf/bpf.md b/gcc/config/bpf/bpf.md
index 329f62f55c33..bb414d8a4428 100644
--- a/gcc/config/bpf/bpf.md
+++ b/gcc
>From 9db2044c1d20bd9f05acf3c910ad0ffc9d5fda8f Mon Sep 17 00:00:00 2001
From: Cupertino Miranda
Date: Fri, 21 Jul 2023 17:40:07 +0100
Subject: [PATCH v2] bpf: fixed template for neg (added second operand)
gcc/ChangeLog:
* config/bpf/bpf.md: fixed template for neg instruction.
---
gcc/config/bp
Hi Cupertino,
On 7/21/23 09:43, Cupertino Miranda wrote:
> gcc/ChangeLog:
>
> * config/bpf/bpf.md: fixed template for neg instruction.
> ---
> gcc/config/bpf/bpf.md | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/config/bpf/bpf.md b/gcc/config/bpf/bpf.md
> ind
Avoid scaling flat loop profiles of vectorized loops
As discussed, when vectorizing loop with static profile, it is not always good
idea
to divide the header frequency by vectorization factor because the profile may
not realistically represent the expected number of iterations. Since in such
ca
>From 7756a4becd1934e55d6d14ac4a9fd6d408a4797b Mon Sep 17 00:00:00 2001
From: Cupertino Miranda
Date: Fri, 21 Jul 2023 17:40:07 +0100
Subject: [PATCH v3] bpf: fixed template for neg (added second operand)
gcc/ChangeLog:
* config/bpf/bpf.md: fixed template for neg instruction.
---
gcc/config/bp
Jan Hubicka writes:
> Avoid scaling flat loop profiles of vectorized loops
>
> As discussed, when vectorizing loop with static profile, it is not always
> good idea
> to divide the header frequency by vectorization factor because the profile may
> not realistically represent the expected number o
On Fri, Jul 21, 2023 at 8:09 AM Drew Ross via Gcc-patches
wrote:
>
> Simplifies (x << c) >> c where x is a signed integral type of
> width >= int and c = precision(type) - 1 into -(x & 1). Tested successfully
> on x86_64 and x86 targets.
Thinking about this some more, I think this should be handl
> On Mon, Jul 17, 2023 at 12:36 PM Jan Hubicka via Gcc-patches
> wrote:
> >
> > Hi,
> > While looking into sphinx3 regression I noticed that vectorizer produces
> > BBs with overall probability count 120%. This patch fixes it.
> > Richi, I don't know how to create a testcase, but having one would
On Fri, Jul 21, 2023 at 5:13 AM Matthew Malcomson via Gcc-patches
wrote:
>
> On some AArch64 bootstrapped builds, we were getting a flaky test
> because the floating point operations in `get_time` were being fused
> with the floating point operations in `timevar_accumulate`.
>
> This meant that th
On 7/20/23 17:58, Marek Polacek wrote:
On Thu, Jul 20, 2023 at 03:51:32PM -0400, Marek Polacek wrote:
On Thu, Jul 20, 2023 at 02:37:07PM -0400, Jason Merrill wrote:
On 7/20/23 14:13, Marek Polacek wrote:
On Wed, Jul 19, 2023 at 10:11:27AM -0400, Patrick Palka wrote:
On Tue, 18 Jul 2023, Marek
On 7/20/23 15:51, Marek Polacek wrote:
On Thu, Jul 20, 2023 at 02:37:07PM -0400, Jason Merrill wrote:
On 7/20/23 14:13, Marek Polacek wrote:
On Wed, Jul 19, 2023 at 10:11:27AM -0400, Patrick Palka wrote:
On Tue, 18 Jul 2023, Marek Polacek via Gcc-patches wrote:
Bootstrapped/regtested on x86_
DF +0.0 is bitwise all zeros so int x0 store to mem can be used to optimize it.
void zd(double *) { *d = 0.0; }
currently:
| fmv.d.x fa5,zero
| fsd fa5,0(a0)
| ret
With patch
| sd zero,0(a0)
| ret
This came to light when testing the in-flight f-m-o patch where an ICE
was gettinh trig
Hi Cuper.
OK. Thanks!
> From 7756a4becd1934e55d6d14ac4a9fd6d408a4797b Mon Sep 17 00:00:00 2001
> From: Cupertino Miranda
> Date: Fri, 21 Jul 2023 17:40:07 +0100
> Subject: [PATCH v3] bpf: fixed template for neg (added second operand)
>
> gcc/ChangeLog:
>
> * config/bpf/bpf.md: fixed temp
Hi everyone,
Just to confirm that I pushed the change in MAINTAINERS file, adding
myself to the write after approval list.
Thanks,
Cupertino
On Fri, 21 Jul 2023 at 19:56, Vineet Gupta wrote:
>
> DF +0.0 is bitwise all zeros so int x0 store to mem can be used to optimize
> it.
>
> void zd(double *) { *d = 0.0; }
>
> currently:
>
> | fmv.d.x fa5,zero
> | fsd fa5,0(a0)
> | ret
>
> With patch
>
> | sd zero,0(a0)
> | ret
> This ca
Adds a simplification for (~X | Y) ^ X to be folded into ~(X & Y).
Also adds the macro bitwise_equal_p for generic and gimple which
returns true iff EXPR1 and EXPR2 have the same value. This helps
to reduce the number of nop_converts necessary to match the pattern.
Tested successfully on x86_64 a
This patch fixes define_insn for "neg" to support 2 operands.
Initial implementation assumed the format "neg %0" while the instruction
allows both a destination and source operands. The second operand can
either be a register or an immediate value.
gcc/ChangeLog:
* config/bpf/bpf.md: fixe
Better with the commit message.
OK. Thanks.
> This patch fixes define_insn for "neg" to support 2 operands.
> Initial implementation assumed the format "neg %0" while the instruction
> allows both a destination and source operands. The second operand can
> either be a register or an immediate v
On 7/21/23 11:15, Philipp Tomsich wrote:
On Fri, 21 Jul 2023 at 19:56, Vineet Gupta wrote:
DF +0.0 is bitwise all zeros so int x0 store to mem can be used to optimize it.
void zd(double *) { *d = 0.0; }
currently:
| fmv.d.x fa5,zero
| fsd fa5,0(a0)
| ret
With patch
| sd zero,0(
Fixes: ef85d150b5963 ("RISC-V: Enable TARGET_SUPPORTS_WIDE_INT")
(gcc-13 regression)
DF +0.0 is bitwise all zeros so int x0 store to mem can be used to optimize it.
void zd(double *) { *d = 0.0; }
currently:
| fmv.d.x fa5,zero
| fsd fa5,0(a0)
| ret
With patch
| sd zero,0(a0)
| ret
T
On Fri, 21 Jul 2023 10:55:52 PDT (-0700), Vineet Gupta wrote:
DF +0.0 is bitwise all zeros so int x0 store to mem can be used to optimize it.
void zd(double *) { *d = 0.0; }
currently:
| fmv.d.x fa5,zero
| fsd fa5,0(a0)
| ret
With patch
| sd zero,0(a0)
| ret
This came to light when
(This is a follow-up of
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624951.html)
Bootstrapped and regtested on x86_64-pc-linux-gnu, how does this look?
-- >8 --
The previous fix doesn't work for partially instantiated ttps primarily
because most_general_template doesn't work for them. T
This patch fixes define_insn for "neg" to support 2 operands.
Initial implementation assumed the format "neg %0" while the instruction
allows both a destination and source operands. The second operand can
either be a register or an immediate value.
gcc/ChangeLog:
* config/bpf/bpf.md: fi
On 7/21/23 12:31, Palmer Dabbelt wrote:
(define_expand "len_mask_gather_load"
[(match_operand:VNX1_QHSD 0 "register_operand")
- (match_operand 1 "pmode_reg_or_0_operand")
+ (match_operand:P 1 "pmode_reg_or_0_operand")
(match_operand:VNX1_QHSDI 2 "register_operand")
(match_oper
On 7/21/23 11:31, Palmer Dabbelt wrote:
On Fri, 21 Jul 2023 10:55:52 PDT (-0700), Vineet Gupta wrote:
DF +0.0 is bitwise all zeros so int x0 store to mem can be used to
optimize it.
void zd(double *) { *d = 0.0; }
currently:
| fmv.d.x fa5,zero
| fsd fa5,0(a0)
| ret
With patch
| sd
Hi,
In the current GCC13 release note, the URL to the option -fstrict-flex-array
is wrong (pointing to -Wstrict-flex-array).
This is the change to correct the URL and also add the URL in another place
where -fstrict-flex-array is mentioned.
I have checked the resulting HTML file, works well.
Oka
>> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
>> index 3063e71c8906..b3be65d3efae 100644
>> --- a/gcc/doc/invoke.texi
>> +++ b/gcc/doc/invoke.texi
>> @@ -946,8 +946,8 @@ Objective-C and Objective-C++ Dialects}.
>>
>> @emph{eBPF Options}
>> @gccoptlist{-mbig-endian -mlittle-endian -
On 7/21/23 11:31, Palmer Dabbelt wrote:
IIUC the pattern to emit fmv suffers from the same bug -- it's fixed
in the same
way, but I think we might be able to come up with a test for it:
`fmv.d.x FREG,
x0` would be the fastest way to generate 0.0, so maybe something like
double sum(doub
The asmgoto feature requires LRA support.
Committed to trunk. Tested on hppa64-hp-hpux11.11.
Dave
---
Require target lra in gcc.c-torture/compile/asmgoto-6.c
2023-07-21 John David Anglin
gcc/testsuite/ChangeLog:
* gcc.c-torture/compile/asmgoto-6.c: Require target lra.
diff --git a
On 7/20/23 16:45, Rainer Orth wrote:
Hi Vladimir,
The following patch is necessary for porting avr to LRA.
The patch was successfully bootstrapped and tested on x86-64, aarch64, and
ppc64le.
There is still avr poring problem with reloading of subreg of frame
pointer. I'll address it later
On Thu, 2023-07-06 at 16:43 +0200, priour...@gmail.com wrote:
> As per David's suggestion.
> - Improved leading comment of "is_placement_new_p"
> - "kf_operator_new::matches_call_types_p" now checks that arg 0 is of
> integral type and that arg 1, if any, is of pointer type.
> - Changed ambiguous
On 7/21/23 10:57, Ben Boeckel wrote:
On Thu, Jul 20, 2023 at 17:00:32 -0400, Nathan Sidwell wrote:
On 7/19/23 20:47, Ben Boeckel wrote:
But it is inhibiting distributed builds because the distributing tool
would need to know:
- what CMIs are actually imported (here, "read the module mapper fil
On 7/21/23 14:34, Patrick Palka wrote:
(This is a follow-up of
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624951.html)
Bootstrapped and regtested on x86_64-pc-linux-gnu, how does this look?
-- >8 --
The previous fix doesn't work for partially instantiated ttps primarily
because most_g
> On Jul 21, 2023, at 7:21 AM, Martin Uecker via Gcc-patches
> wrote:
>
>
>
> This patch adds a warning for allocations with insufficient size
> based on the "alloc_size" attribute and the type of the pointer
> the result is assigned to. While it is theoretically legal to
> assign to the wr
../../gcc/config/riscv/riscv.cc: In function 'void riscv_option_override()':
../../gcc/config/riscv/riscv.cc:6716:7: error: misspelled term 'can not' in
format; use 'cannot' instead [-Werror=format-diag]
6716 | "Current RISC-V GCC can not support VLEN > 4096bit for 'V'
Extension");
|
On 7/21/23 15:16, Andreas Schwab wrote:
../../gcc/config/riscv/riscv.cc: In function 'void riscv_option_override()':
../../gcc/config/riscv/riscv.cc:6716:7: error: misspelled term 'can not' in
format; use 'cannot' instead [-Werror=format-diag]
6716 | "Current RISC-V GCC can not suppor
P1642 includes the header cstdarg to the freestanding implementation.
This was probably left out by accident, this patch puts it in.
Since this is one of the headers that go in whole cloth, there should be no
further actions needed.
This might be related to PR106953, but since that one touches the
Commit 92d1425ca780 "c++: redundant targ coercion for var/alias tmpls"
changed the compiler error message in this testcase from
: In instantiation of 'void foo() [with T = int]':
:14:11: required from here
:8:22: error: 'int' is not a class, struct, or union type
:8:22: error: 'int' is not a cla
On 7/21/23 01:39, Nathaniel Shead wrote:
On Thu, Jul 20, 2023 at 11:46:47AM -0400, Jason Merrill wrote:
On 7/20/23 05:36, Nathaniel Shead wrote:
Currently, when typeck discovers that a return statement will refer to a
local variable it rewrites to return a null pointer. This causes the
error me
On Fri, 2023-07-21 at 17:35 +0200, Benjamin Priour wrote:
> Hi,
>
> Upon David's request I've joined the in progress patch to the below
> email.
> I hope it makes more sense now.
>
> Best,
> Benjamin.
Thanks for posting the work-in-progress patch; it makes the idea
clearer.
Some thoughts about
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/13?
-- >8 --
This code in cxx_eval_array_reference has been hard to get right.
In r12-2304 I added some code; in r13-5693 I removed some of it.
Here the problematic line is "S s = arr[0];" which causes a crash
on the assert in verify_ct
Hello-
This is an update to the v2 patch series last sent in January:
https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609473.html
While I did not receive any feedback on the v2 patches yet, they did need some
rebasing on top of other recent commits to input.cc, so I thought it would be
hel
Class edit_context handles outputting fixit hints in diff form that could be
manually or automatically applied by the user. This will not make sense for
generated data locations, such as the contents of a _Pragma string, because
the text to be modified does not appear in the user's input files. We
1 - 100 of 120 matches
Mail list logo
