The Close() procedure in MemStream is missing a guard to prevent it from
printing in non-debug mode.
gcc/gm2:
* gm2-libs-iso/MemStream.mod: Guard debug output.
Signed-off-by: Wilken Gottwalt
---
gcc/m2/gm2-libs-iso/MemStream.mod | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
Hi,
I composed some patches to generalize lane-reducing (dot-product is a typical
representative) pattern recognition, and prepared a RFC document so as to help
review. The original intention was to make a complete solution for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114440. For sure, th
The work for RFC
(https://gcc.gnu.org/pipermail/gcc-patches/2024-July/657860.html)
involves not a little code change, so I have to separate it into several batches
of patchset. This and the following patches constitute the first batch.
Since pattern statement coexists with normal statements in a
This patch extends original vect analysis and transform to support a new kind
of lane-reducing operation that participates in loop reduction indirectly. The
operation itself is not reduction statement, but its value would be accumulated
into reduction result finally.
Thanks,
Feng
---
gcc/
For sum-based loop reduction, its affine closure is composed by statements
whose results and derived computation only end up in the reduction, and are
not used in any non-linear transform operation. The concept underlies the
generalized lane-reducing pattern recognition in the coming patches. As
ma
Previously, only simple lane-reducing case is supported, in which one loop
reduction statement forms one pattern match:
char *d0, *d1, *s0, *s1, *w;
for (i) {
sum += d0[i] * d1[i]; // sum = DOT_PROD(d0, d1, sum);
sum += abs(s0[i] - s1[i]); // sum = SAD(s0, s1, sum);
sum += w[i
This patch adds a pattern to fold a summation into the last operand of lane-
reducing operation when appropriate, which is a supplement to those operation-
specific patterns for dot-prod/sad/widen-sum.
sum = lane-reducing-op(..., 0) + value;
=>
sum = lane-reducing-op(..., value);
Thanks,
Feng
From: Pan Li
Rearrange the test help header files, as well as align the name
conventions.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/binop/vec_sat_binary.h: Move to...
* gcc.target/riscv/rvv/autovec/binop/vec_sat_binary_vvv_run.h: ...here.
* gcc.target/risc
As in other places we have to be careful to use FP modes to represent
the underlying bit representation of an object. With x87 floating-point
types there are no load or store instructions that preserve this and
XFmode can have padding.
When SRA faces the situation that a field is accessed with mu
The following addresses another case where x87 FP loads mangle the
bit representation and thus are not suitable for a representative
in other types. VN was value-numbering a later integer load of 'x'
as the same as a former float load of 'x'.
The following disables this when the result is not kno
On Mon, 2024-07-15 at 15:53 +0800, Lulu Cheng wrote:
> Hi,
>
> g++.dg/opt/pr107569.C and range-sincos.c vrp-float-abs-1.c is the same
> issue, right?
>
> And I have no objection to code modifications. But I think it's better
> to wait until this builtin
>
> function is fixed.
Oops https://gcc.
Richard Biener writes:
>> Am 20.07.2024 um 02:31 schrieb Andrew Pinski :
>>
>> On Fri, Jul 19, 2024 at 5:23 PM Sam James wrote:
>>>
>>> Originally added in r0-44646-g204250d2fcd084 and r0-44627-gfd350d241fecf6
>>> whic
>>> moved -fno-common from all builds to just checking builds.
>>>
>>> S
So I'm not yet sure how I'm going to break everything down, but this is
easy enough to break out as 1/N of ext-dce fixes/improvements.
When handling uses in an insn, we first determine what bits are set in
the destination which is represented in DST_MASK. Then we use that to
refine what bits
While debugging pr115877, I noticed we were failing to remove the
destination register from LIVENOW bitmap when it was set to a constant
value. ie (set (dest) (const_int)). This was a trivial oversight in
safe_for_live_propagation.
I don't have an example of this affecting code generation,
Xi Ruoyao writes:
> On Sat, 2024-07-20 at 06:52 +0100, Sam James wrote:
>> Some distributions like Gentoo make -Wformat and -Wformat-security
>> enabled by default. Pass -Wno-format to the test to avoid a spurious
>> fail in such environments.
>>
>> gcc/testsuite/
>> PR rtl-optimization/1159
Richard Sandiford writes:
> Xi Ruoyao writes:
>> On Sat, 2024-07-20 at 06:52 +0100, Sam James wrote:
>>> Some distributions like Gentoo make -Wformat and -Wformat-security
>>> enabled by default. Pass -Wno-format to the test to avoid a spurious
>>> fail in such environments.
>>>
>>> gcc/testsui
Informations were took from gcc/Makefile.in
---
gcc/doc/sourcebuild.texi | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
index 66c4206bfc2..455836a583d 100644
--- a/gcc/doc/sourcebuild.texi
+++ b/gcc/doc/sourcebuild.t
Hi Sam,
on 2024/7/20 07:10, Sam James wrote:
> "Kewen.Lin" writes:
>
>> Hi Sam,
>
> Hi Kewen,
>
>>
>> on 2024/7/19 11:28, Sam James wrote:
>>> 'dg-run' is not a valid dejagnu directive, 'dg-do run' is needed here
>>> for the test to be executed.
>>>
>>> 2024-07-18 Sam James
>>>
>>> PR t
Hi,
This patch adds const0 move checking for CLEAR_BY_PIECES. The original
vec_duplicate handles duplicates of non-constant inputs. But 0 is a
constant. So even a platform doesn't support vec_duplicate, it could
still do clear by pieces if it supports const0 move by that mode.
Compared to the
Hi,
Gently ping it.
https://gcc.gnu.org/pipermail/gcc-patches/2024-July/656937.html
Thanks
Gui Haochen
在 2024/7/11 15:32, HAO CHEN GUI 写道:
> Hi,
> The builtin isinf is not folded at front end if the corresponding optab
> exists. It causes the range evaluation failed on the targets which has
>
Hi,
Gently ping it.
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/653095.html
Thanks
Gui Haochen
在 2024/7/1 9:12, HAO CHEN GUI 写道:
> Hi,
> Gently ping it.
> https://gcc.gnu.org/pipermail/gcc-patches/2024-May/653095.html
>
> Thanks
> Gui Haochen
>
> 在 2024/6/24 9:41, HAO CHEN GUI 写道:
>>
Hi,
Gently ping it.
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/653094.html
Thanks
Gui Haochen
在 2024/7/1 9:11, HAO CHEN GUI 写道:
> Hi,
> Gently ping it.
> https://gcc.gnu.org/pipermail/gcc-patches/2024-May/653094.html
>
> Thanks
> Gui Haochen
>
> 在 2024/6/24 9:41, HAO CHEN GUI 写道:
>>
After an OK from Harald,
commit r15-2187-g838999bb23303edc14e96b6034cd837fa4454cfd
Author: Paul Thomas
Date: Sun Jul 21 17:48:47 2024 +0100
Fortran: Fix regression caused by r14-10477 [PR59104]
2024-07-21 Paul Thomas
gcc/fortran
PR fortran/59104
* gfort
On Sun, Jul 21, 2024 at 3:57 AM Xi Ruoyao wrote:
>
> On Mon, 2024-07-15 at 15:53 +0800, Lulu Cheng wrote:
> > Hi,
> >
> > g++.dg/opt/pr107569.C and range-sincos.c vrp-float-abs-1.c is the same
> > issue, right?
> >
> > And I have no objection to code modifications. But I think it's better
> > to w
Hi all,
For prefetchi instructions, RIP-relative address is explicitly mentioned
for operand and assembler obeys that rule strictly. This makes
instruction like:
prefetchit0 bar
got illegal for assembler, which should be a broad usage for prefetchi.
Explicitly add (%rip) after funct
It is not trivial to decide when a write of a register pair terminates
or starts a new chain. For example, prior regrename we have
(insn 91 38 36 5 (set (reg:FPRX2 16 %f0 [orig:76 x ] [76])
(const_double:FPRX2 0.0 [0x0.0p+0]))
"float-cast-overflow-7-reduced.c":5:55 discrim 2 1507 {*movfp
We have been carrying this note on the "original" export feature for ages,
and I believe it's not actually a FAQ, if it ever was.
Jonathan moved this down when adding a note on ADL last fall.
I now propose to drop it.
Thoughts?
Gerald
diff --git a/htdocs/bugs/index.html b/htdocs/bugs/index.
On Fri, Jul 19, 2024 at 4:25 AM Joern Wolfgang Rennecke
wrote:
>
> As discussed before on gcc@gcc,gnu.org, this patch reduces the iteration
> counts of the tsvc tests to avoid timeouts when using simulators.
> A few tests needed special attention because they divided "iterations"
> by some constan
28 matches
Mail list logo