On 7/21/23 11:27, Andrew Pinski via Gcc-patches wrote:
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.
Thin
On 7/21/23 12:30, Vineet Gupta wrote:
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
On 7/21/23 12:55, Vineet Gupta wrote:
Apparently this is a regression in gcc-13, introduced by commit
ef85d150b5963 ("RISC-V: Enable TARGET_SUPPORTS_WIDE_INT") and the fix
thus is a partial revert of that change.
Given that it can ICE, we should probably backport it to 13.
FWIW ICE is on
On Thu, Jul 20, 2023 at 10:42:29AM -0400, Jason Merrill wrote:
> On 7/20/23 05:35, Nathaniel Shead wrote:
> > This adds rudimentary lifetime tracking in C++ constexpr contexts,
> > allowing the compiler to report errors with using values after their
> > backing has gone out of scope. We don't yet h
On Fri, Jul 21, 2023 at 3:00 AM Jason Merrill wrote:
>
> On 7/20/23 05:37, Nathaniel Shead wrote:
> > This patch updates 'input_location' during constant evaluation to ensure
> > that errors in subexpressions that lack location information still
> > provide accurate diagnostics.
> >
> > By itself
On Fri, Jul 21, 2023 at 05:44:51PM -0400, Jason Merrill wrote:
> 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
On 7/21/23 09:16, Siddhesh Poyarekar wrote:
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:
On 7/21/23 18:38, Marek Polacek wrote:
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
On Wed, Jul 19, 2023 at 4:12 PM Alexandre Oliva via Gcc-patches
wrote:
>
> On Jul 18, 2023, Richard Biener wrote:
>
> > I think the __symver__ attribute does something similar already so
> > maybe use __attribute__((__sym__("foo")))?
>
> Cool, thanks, that will do. Regstrapped on x86_64-linux-gn
On Tue, Aug 17, 2021 at 1:43 AM Sebastian Huber
wrote:
>
> abort() is used in gcc_assert() and gcc_unreachable() which is used by target
> libraries such as libgcov.a. This patch changes the abort() definition under
> certain conditions. If inhibit_libc is defined and abort is not already
> defi
The following patch fixes sparc solaris bootstrap. The explanation of
the patch is in the commit message.
The patch was successfully bootstrap on x86-64, aarch64, and sparc64
solaris.
commit d17be8f7f36abe257a7d026dad61e5f8d14bdafc
Author: Vladimir N. Makarov
Date: Fri Jul 21 20:28:50 202
GCC maintainers:
Version 5, Fixed patch description, the first argument should be of
type vector. Fixed comment in vsx.md to say "Vector and scalar
extract_elt iterator/attr ". Removed a few of the changes in
version 4. Specifically, reverted the names of REPLACE_ELT_V_sh back
to REPLACE_EL
GCC maintainers:
Version 2: Updated a number of formatting and spacing issues. Added
the NARGS description to the header comment for function find_instance.
This patch was tested on Power 8 LE/BE, Power 9 LE/BE and Power 10 LE
with no regressions.
The rs6000 function find_instance assumes that
GCC maintianers:
Version 2. Both patches have been updated the first patch was approved
with minor issues to be fixed. I will post the updated version as
version 2 for completeness of the series. There were a few changes
with the second patch as well. The second patch has not been approved
yet
On Mon, 17 Jul 2023, Michael Matz via Gcc-patches wrote:
> So, essentially you want unignorable attributes, right? Then implement
> exactly that: add one new keyword "__known_attribute__" (invent a better
> name, maybe :) ), semantics exactly as with __attribute__ (including using
> the same u
On Fri, 2023-07-21 at 13:04 +0800, Kewen.Lin wrote:
> Hi Carl,
>
> on 2023/7/18 03:20, Carl Love wrote:
> > GCC maintainers:
> >
> > Version 4, changed the new RS6000_OVLD_VEC_REPLACE_UN case
> > statement
> > rs6000/rs6000-c.cc. The existing REPLACE_ELT iterator name was
> > changed
> > to REPL
On Fri, 2023-07-21 at 10:19 +0800, Kewen.Lin wrote:
> Hi Carl,
>
> on 2023/7/18 03:19, Carl Love wrote:
> > GCC maintainers:
> >
> > The rs6000 function find_instance assumes that it is called for
> > built-
> > ins with only two arguments. There is no checking for the actual
> > number of arugu
Add a new linemap reason LC_GEN which enables encoding the location of data
that was generated during compilation and does not appear in any source file.
There could be many use cases, such as, for instance, referring to the content
of builtin macros (not yet implemented, but an easy lift after thi
Currently, the tokens obtained from a destringified _Pragma string do not get
assigned proper locations while they are being lexed. After the tokens have
been obtained, they are reassigned the same location as the _Pragma token,
which is sufficient to make things like _Pragma("GCC diagnostic ignor
The diagnostics routines for SARIF output need to read the source code back
in, so that they can generate "snippet" and "content" records, so they need to
be able to cope with generated data locations. Add support for that in
diagnostic-format-sarif.cc.
gcc/ChangeLog:
* diagnostic-format
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
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
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
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
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
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
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
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
../../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 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
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 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 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/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
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/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
>> 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 -
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
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
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
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
(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
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
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 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(
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
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
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
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
Hi everyone,
Just to confirm that I pushed the change in MAINTAINERS file, adding
myself to the write after approval list.
Thanks,
Cupertino
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
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
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_
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 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 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 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
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
>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
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
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
>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
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
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
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/
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,
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
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
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 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
> 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.
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
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
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.
>> *
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
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
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
> 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 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
>
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
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
> 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
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
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
>
>
> > 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
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
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, 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 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
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.
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
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
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 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 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,
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
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
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
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,
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
1 - 100 of 120 matches
Mail list logo
