On Tue, May 28, 2024 at 1:24 AM Andrew MacLeod wrote:
>
> The strlen pass currently has a local ranger instance, but when it
> invokes SCEV or any other shared component, SCEV will not be able to
> access to this ranger as it uses get_range_query(). They will be stuck
> with global ranges.
>
> En
On Mon, May 27, 2024 at 5:16 PM Jeff Law wrote:
>
>
>
> On 5/27/24 12:38 AM, Richard Biener wrote:
> > On Fri, May 24, 2024 at 10:44 AM Mariam Arutunian
> > wrote:
> >>
> >> This patch introduces new built-in functions to GCC for computing
> >> bit-forward and bit-reversed CRCs.
> >> These built
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.
Compared to previous version, the
Hi,
This patch adds an optab for __builtin_isfinite. The finite 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.
Compared to previous version, the
On Mon, May 27, 2024 at 10:33 AM MayShao wrote:
>
> From: mayshao
>
> Hi all:
> This patch enables -march/-mtune=shijidadao, costs and tunings are set
> according to the characteristics of the processor.
>
> Bootstrapped /regtested X86_64.
>
> Ok for trunk?
OK.
Thanks,
Uros.
> BR
On Tue, May 28, 2024 at 4:48 AM liuhongt wrote:
>
> For MEM, rtx_cost iterates each subrtx, and adds up the costs,
> so for MEM (reg) and MEM (reg + 4), the former costs 5,
> the latter costs 9, it is not accurate for x86. Ideally
> address_cost should be used, but it reduce cost too much.
> So cu
When I applied Roger's patch [1], there's ICE due to it.
The patch fix the latent bug.
[1] https://gcc.gnu.org/pipermail/gcc-patches/2024-May/651365.html
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Pushed to trunk.
gcc/ChangeLog:
* config/i386/sse.md
(___mask): Ali
On 5/24/24 2:42 AM, Mariam Arutunian wrote:
This patch adds a new compiler pass aimed at identifying naive CRC
implementations,
characterized by the presence of a loop calculating a CRC (polynomial
long division).
Upon detection of a potential CRC, the pass prints an informational message.
From: Pan Li
This patch would like to add new internal fun for the below 2 IFN.
* mask_len_strided_load
* mask_len_strided_store
The GIMPLE v = MASK_LEN_STRIDED_LOAD (ptr, stride, mask, len, bias) will
be expanded into v = mask_len_strided_load (ptr, stried, mask, len, bias).
The GIMPLE MASK_LE
For MEM, rtx_cost iterates each subrtx, and adds up the costs,
so for MEM (reg) and MEM (reg + 4), the former costs 5,
the latter costs 9, it is not accurate for x86. Ideally
address_cost should be used, but it reduce cost too much.
So current solution is make constant disp as cheap as possible.
B
On Mon, May 27, 2024 at 4:30 PM haochen.jiang
wrote:
>
> On Linux/x86_64,
>
> c5a7628470a7fb801ebeea82e16a4549db43bfa5 is the first bad commit
> commit c5a7628470a7fb801ebeea82e16a4549db43bfa5
> Author: Andrew Pinski
> Date: Sun May 26 17:59:21 2024 -0700
>
> match: Use uniform_integer_cst_
This just moves the tree scan earlier so we can detect the optimization and not
need to detect the vector splitting too.
Committed as obvious after a quick test.
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/bitops-9.c: Look at cdcde1 rather than optmization.
Signed-off-by: Andrew Pinski
On Linux/x86_64,
c5a7628470a7fb801ebeea82e16a4549db43bfa5 is the first bad commit
commit c5a7628470a7fb801ebeea82e16a4549db43bfa5
Author: Andrew Pinski
Date: Sun May 26 17:59:21 2024 -0700
match: Use uniform_integer_cst_p in bitwise_inverted_equal_p [PR115238]
caused
FAIL: gcc.dg/tree-ss
The strlen pass currently has a local ranger instance, but when it
invokes SCEV or any other shared component, SCEV will not be able to
access to this ranger as it uses get_range_query(). They will be stuck
with global ranges.
Enable/disable ranger should be used instead of a local version wh
>
> Ya, makes sense -- I guess the current values aren't that exciting for
> execution, but we could just add some more interesting ones...
During the development of the patch, I have an issue with large numbers
(2e34, -2e34).
They are used in gfortran.fortran-torture/execute/intrinsic_aint_anint
Sure, I'll try to have a look.
But for the moment this patch introduces some regressions so I keep on
working on it.
FAIL: 23_containers/vector/modifiers/moveable.cc -std=gnu++14 execution
test
FAIL: 23_containers/vector/modifiers/moveable2.cc -std=gnu++14
execution test
On 27/05/2024 22
François Dumont writes:
> In C++98 this test fails with:
For this, and your other -Wfree-nonheap-object patches, could you see if
it helps with any of the bugs reported for both -Wstringop-overflow and
-Wfree-nonheap-object in libstdc++? There's a bunch of (possible) dupes
that it'd be worth tag
In C++98 this test fails with:
Excess errors:
/home/fdumont/dev/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h:452:
warning: 'void* __builtin_memcpy(void*, const void*, long unsigned int)'
writing between 2 and 9223372036854775806 bytes into a region of size 0
overflows
On 5/27/24 11:54 AM, Hans-Peter Nilsson wrote:
Regtested cris-elf. Ok to commit?
-- >8 --
No functional change.
- We always have a target_hash_table and bb_ticks because
init_resource_info is always called. These conditionals are
an ancient artifact: it's been quite a while since
resource.
On 5/27/24 11:53 AM, Hans-Peter Nilsson wrote:
Regtested cris-elf. Ok to commit?
-- >8 --
No functional change.
A "git diff -wb" (ignore whitespace diff) shows that this
commit just removes a "if (b != -1)" after a "gcc_assert (b
!= -1)" and also removes the subsequent "else" clause.
On 5/27/24 11:52 AM, Hans-Peter Nilsson wrote:
Regtested cris-elf. Ok to commit?
-- >8 --
...and call compute_bb_for_insn in init_resource_info and
free_bb_for_insn in free_resource_info.
I put a gcc_unreachable in that else-clause for a failing
find_basic_block in mark_target_live_regs aft
On 5/27/24 11:52 AM, Hans-Peter Nilsson wrote:
The problem is in mark_target_live_regs: it consults a hash-table
indexed by insn uid, where it tracks the currently live registers with
a "generation" count to handle when it moves around insn, filling
delay-slots. As a fall-back, it starts wi
On 5/27/24 11:51 AM, Hans-Peter Nilsson wrote:
The code in resource.cc is exclusively used by the delay-slot-filling
machinery: the "dbr" pass in reorg.cc, sometimes referred to just as
"reorg". Its implementation is quite arcane, scanning RTL, with only
a little dash of cfgrtl. I'm sure som
Regtested cris-elf. Ok to commit?
-- >8 --
No functional change.
- We always have a target_hash_table and bb_ticks because
init_resource_info is always called. These conditionals are
an ancient artifact: it's been quite a while since
resource.cc was used elsewhere than exclusively from reorg.cc
Regtested cris-elf. Ok to commit?
-- >8 --
No functional change.
A "git diff -wb" (ignore whitespace diff) shows that this
commit just removes a "if (b != -1)" after a "gcc_assert (b
!= -1)" and also removes the subsequent "else" clause.
* resource.cc (mark_target_live_regs): Remove red
Regtested cris-elf. Ok to commit?
-- >8 --
...and call compute_bb_for_insn in init_resource_info and
free_bb_for_insn in free_resource_info.
I put a gcc_unreachable in that else-clause for a failing
find_basic_block in mark_target_live_regs after the comment that says:
/* We didn't find the
Regtested cris-elf. Ok to commit?
-- >8 --
The PR115182 regression is that a delay-slot for a conditional branch,
is no longer filled with an insn that has been "sunk" because of
r15-518-g99b1daae18c095, for cris-elf w. -O2 -march=v10.
There are still sufficient "nearby" dependency-less insns th
Hello,
Le 17/05/2024 à 16:03, Aldy Hernandez a écrit :
If the intersection of the bitmasks made the range span the entire
domain, normalize the range to VARYING.
gcc/ChangeLog:
PR middle-end/115131
* value-range.cc (prange::intersect): Set VARYING if intersection
of bit
And here's Lyut's basic Zbkb support. Essentially it's four new
patterns for packh, packw, pack plus a bridge pattern needed for packh.
packw is a bit ugly as we need to match a sign extension in an
inconvenient location. We pull it out so that the extension is exposed
in a convenient place
On Sat, May 25, 2024 at 10:32 PM Jeff Law wrote:
>
>
> On 5/24/24 2:41 AM, Mariam Arutunian wrote:
> > If the target is ZBC or ZBKC, it uses clmul instruction for the CRC
> > calculation.
> > Otherwise, if the target is ZBKB, generates table-based CRC,
> > but for reversing inputs and the output
On 5/27/24 12:39 AM, Richard Biener wrote:
On Sat, May 25, 2024 at 8:34 PM Jeff Law wrote:
On 5/24/24 2:42 AM, Mariam Arutunian wrote:
gcc/testsuite/gcc.c-torture/compile/
* crc-11.c: New test.
* crc-15.c: Likewise.
* crc-16.c: Likewise.
* crc-19.c: Likewise.
On 5/27/24 12:38 AM, Richard Biener wrote:
On Fri, May 24, 2024 at 10:44 AM Mariam Arutunian
wrote:
This patch introduces new built-in functions to GCC for computing bit-forward
and bit-reversed CRCs.
These builtins aim to provide efficient CRC calculation capabilities.
When the target arc
>> + /* By default, when -mno-vector-strict-align is not specified, do not
>> allow
>> + unaligned vector memory accesses except if -mtune's setting explicitly
>> + allows it. */
>> + riscv_vector_unaligned_access_p = rvv_vector_strict_align == 0 ||
>
> opts->x_rvv_vector_strict_align
> @@ -9536,6 +9549,12 @@ riscv_override_options_internal (struct gcc_options
> *opts)
>riscv_slow_unaligned_access_p = (cpu->tune_param->slow_unaligned_access
>|| TARGET_STRICT_ALIGN);
>
> + /* By default, when -mno-vector-strict-align is not specified, do
On Sat, May 25, 2024 at 9:40 PM Jeff Law wrote:
>
>
> On 5/24/24 2:41 AM, Mariam Arutunian wrote:
> > Add two new internal functions (IFN_CRC, IFN_CRC_REV), to provide faster
> > CRC generation.
> > One performs bit-forward and the other bit-reversed CRC computation.
> > If CRC optabs are support
When points-to analysis finds SCCs it marks the wrong node as being
part of a found cycle. It only wants to mark the node it collapses
to but marked the entry node found rather than the one it collapses
to. This causes fallout in the patch for PR115236 but generally
weakens the points-to solution
On Mon, May 27, 2024 at 11:37 AM HAO CHEN GUI wrote:
>
> Hi,
> This patch adds an optab for __builtin_isfinite. The finite 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 i
On Fri, 24 May 2024, Richard Biener wrote:
> This is the second merge proposed from the SLP vectorizer branch.
> I have again managed without adding and using --param vect-single-lane-slp
> but instead this provides always enabled functionality.
>
> This makes us use SLP reductions (a group of re
Attached is v3 with the discussed changes. It now has
-mscalar-strict-align which is an alias to -mstrict-align as well
as -mvector-strict-align.
Testsuite shows no new regressions on rv64gcv_zvfh_zvbb.
Regards
Robin
gcc/ChangeLog:
* config/riscv/riscv-opts.h (TARGET_VECTOR_MISALIGN_S
First of all we have not been using CVS for a while, second cvsweb
itself is not actively maintained any more. And on the way refer to
it as a tool, not a package.
Gerald
---
htdocs/news.html | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/htdocs/news.html b/htdocs/news.html
This patch adds support for the `dispatch` construct and the `adjust_args`
clause to the Fortran front-end.
gcc/fortran/ChangeLog:
* dump-parse-tree.cc (show_omp_clauses): Handle novariants and nocontext
clauses.
(show_omp_node): Handle EXEC_OMP_DISPATCH.
(show_cod
This patch adds support to the C front-end to parse the `dispatch` construct and
the `adjust_args` clause. It also includes some common C/C++ bits for pragmas
and attributes.
Additional common C/C++ testcases are in a later patch in the series.
gcc/c-family/ChangeLog:
* c-attribs.cc (c_c
libgomp/ChangeLog:
* libgomp.texi:
---
libgomp/libgomp.texi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libgomp/libgomp.texi b/libgomp/libgomp.texi
index 71d62105a20..b72accd0d26 100644
--- a/libgomp/libgomp.texi
+++ b/libgomp/libgomp.texi
@@ -294,8 +294,8 @@ T
This patch introduces the OMP_DISPATCH tree node, as well as two new clauses
`nocontext` and `novariants`. It defines/exposes interfaces that will be
used in subsequent patches that add front-end and middle-end support, but
nothing generates these nodes yet.
It also adds support for new OpenMP con
This patch adds C++ support for the `dispatch` construct and the `adjust_args`
clause. It relies on the c-family bits comprised in the corresponding C front
end patch for pragmas and attributes.
Additional C/C++ common testcases are provided in a subsequent patch in the
series.
gcc/cp/ChangeLog:
gcc/testsuite/ChangeLog:
* c-c++-common/gomp/declare-variant-2.c: Adjust dg-error directives.
* c-c++-common/gomp/adjust-args-1.c: New test.
* c-c++-common/gomp/adjust-args-2.c: New test.
* c-c++-common/gomp/dispatch-1.c: New test.
* c-c++-common/gomp/dispat
This patch adds middle-end support for the `dispatch` construct and the
`adjust_args` clause. The heavy lifting is done in `gimplify_omp_dispatch` and
`gimplify_call_expr` respectively. For `adjust_args`, this mostly consists in
emitting a call to `gomp_get_mapped_ptr` for the adequate device.
For
This series of patches implement two tightly-knit OpenMP features: the
`dispatch` construct and the `adjust_args` clause to the `declare variant`
directive. `adjust_args` can only be used if the `dispatch` selector appears in
the `match` clause. The "interoperability requirement set" and the `appen
The following makes sure the virtual operand updating when sinking
stores works for the case we ignore paths to kills. The final
sink location might not post-dominate the original stmt location
which would require inserting of a virtual PHI which we do not support.
Bootstrapped and tested on x86_
Yes, this pass can detect only bitwise (naive) implementations of CRC32C
and replace them with hardware crc32* instructions (if supported), or
alternatively
generate CRC using CLMUL-based or table-based methods.
Here is an example of such a CRC32C implementation, where the entire loop
will be repla
On 5/27/24 05:16, Julian Waters wrote:
Hi all,
Please review a trivial change that defines which threading model is
used on Windows, so applications can check it. This is also useful for
system headers, since some headers should be switched off if pthread
is the threading model (Currently they a
ping
On Wednesday, 15 May 2024 21:49:56 GMT+2 Matthias Kretz wrote:
> Tested on aarch64-linux-gnu, arm-linux-gnueabihf, powerpc64le-linux-gnu,
> x86_64-linux-gnu (-m64, -m32, -mx32), and arm-linux-gnueabi
>
> OK for trunk? And when backporting, should I squash it with the commit that
> introduced
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.
Compared to previous version, the
Hi,
This patch adds an optab for __builtin_isfinite. The finite 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.
Compared to previous version, the
On Mon, May 27, 2024 at 11:11:43AM +0200, Richard Biener wrote:
> For the following testcase we fail to demangle
> _ZZN5OuterIvE6methodIvEEvvQ3cstITL0__EEN5InnernwEm and
> _ZZN5OuterIvE6methodIvEEvvQ3cstITL0__EEN5InnerdlEPv and in turn end
> up building NULL references. The following puts in a saf
For the following testcase we fail to demangle
_ZZN5OuterIvE6methodIvEEvvQ3cstITL0__EEN5InnernwEm and
_ZZN5OuterIvE6methodIvEEvvQ3cstITL0__EEN5InnerdlEPv and in turn end
up building NULL references. The following puts in a safeguard for
faile demangling into -Waccess.
Bootstrapped and tested on x
On Mon, May 27, 2024 at 2:48 PM Hongtao Liu wrote:
>
> On Sat, May 18, 2024 at 4:10 AM Roger Sayle
> wrote:
> >
> >
> > Hi Hongtao,
> > Many thanks for the review, bug fixes and suggestions for improvements.
> > This revised version of the patch, implements all of your corrections. In
> > theo
From: mayshao
Hi all:
This patch enables -march/-mtune=shijidadao, costs and tunings are set
according to the characteristics of the processor.
Bootstrapped /regtested X86_64.
Ok for trunk?
BR
Mayshao
gcc/ChangeLog:
* common/config/i386/cpuinfo.h (get_zhaoxin_cpu): Recogni
Hi!
The r13-8207-g17acf9fbeb10d7adad commit changed some tests to use
-lstdc++exp instead of -lstdc++_libbacktrace, but it didn't change
the 19_diagnostics/stacktrace/hash.cc test, presumably because
when it was added on the trunk, it already had -lstdc++exp and
it was changed to -lstdc++_libbackt
Hi Haochen,
on 2024/5/27 15:22, HAO CHEN GUI wrote:
> Hi Kewen,
> Thanks for your comments.
>
> 在 2024/5/27 11:18, Kewen.Lin 写道:
>> Does this require "This pattern is not allowed to FAIL."?
>>
>> I guess yes? Since if it's decided to go with this pattern
>> expanding, there is no fall back?
>
Return NULL_TREE when genop3 equal EXACT_DIV_EXPR.
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/652641.html
version log v3: remove additional POLY_INT_CST check.
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/652795.html
gcc/ChangeLog:
* tree-ssa-pre.cc (create_component_ref_by
Earlier this year someone added a redirect from http to https to
gcc.gnu.org; taking this as a hint to generally use https.
Pushed.
Gerald
gcc:
* doc/gm2.texi (What is GNU Modula-2): Move gcc.gnu.org links to
https.
(Other languages): Ditto. And fix casing of GCC.
---
"www" prefixes come and go...
Pushed.
Gerald
---
htdocs/news.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/htdocs/news.html b/htdocs/news.html
index d2168528..2490d69e 100644
--- a/htdocs/news.html
+++ b/htdocs/news.html
@@ -168,7 +168,7 @@
BRIG/HSAIL (Heterogeneous
Pushed.
Gerald
---
htdocs/gcc-3.1/criteria.html | 2 +-
htdocs/gcc-3.3/criteria.html | 2 +-
htdocs/gcc-3.4/criteria.html | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/htdocs/gcc-3.1/criteria.html b/htdocs/gcc-3.1/criteria.html
index 2a9febc3..2a51da81 100644
--- a/htdocs
Hi Kewen,
Thanks for your comments.
在 2024/5/27 11:18, Kewen.Lin 写道:
> Does this require "This pattern is not allowed to FAIL."?
>
> I guess yes? Since if it's decided to go with this pattern
> expanding, there is no fall back?
The builtin is inline folded if the optab doesn't exist on
the
On Mon, May 27, 2024 at 12:01 AM Rainer Orth
wrote:
> > This is an RFC series that adds FDPIC ELF target support to
> > libbacktrace.
> >
> > While debugging this I've noticed that there's no unwinding info for the
> > libstdc++ version of libbacktrace, which made backtraces empty for me,
> > both
Hi Max,
> This is an RFC series that adds FDPIC ELF target support to
> libbacktrace.
>
> While debugging this I've noticed that there's no unwinding info for the
> libstdc++ version of libbacktrace, which made backtraces empty for me,
> both on xtensa-linux-uclibcfdpic and on regular xtensa-linux
67 matches
Mail list logo
