On 4/30/24 10:34, Stefan Schulze Frielinghaus wrote:
> Starting with r14-2047-gd0e891406b16dc we see through subregs which
> means for f10 in risbg-ll-2.c we do not end up with rosbg_si_noshift but
> rather rosbg_di_noshift which materializes in slightly different start
> index. This saves us an
On 4/30/24 10:32, Stefan Schulze Frielinghaus wrote:
> Starting with r12-2731-g96146e61cd7aee we do not generate code like
>
> _5 = (unsigned int) c_2(D);
> i_6 = _5 << 8;
> _7 = _5 << 20;
> i_8 = i_6 | _7;
>
> anymore but instead
>
> _5 = (unsigned int) c_2(D);
> _3 = _5 * 1048832;
>
> which
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk (and
later 14.2)? I don't think making it a GTY root is necessary but I felt
perhaps better to be safe than sorry.
Potentially another approach would be to use DECL_UID instead like how
entity_map does; would that be preferable?
--
On Tue, Apr 30, 2024 at 8:54 PM Jeff Law wrote:
>
>
> In doing some preparation work for using zbkb's pack instructions for
> constant synthesis I figured it would be wise to get a sense of how well
> our constant synthesis is actually working and address any clear issues.
>
> So the first
This adds a few more of what is currently done in phiopt's value_replacement
to match. I noticed this when I was hooking up phiopt's value_replacement
code to use match and disabling the old code. But this can be done
independently from the hooking up phiopt's value_replacement as phiopt
is
This patch improves GCC’s vectorization of __builtin_popcount for aarch64 target
by adding popcount patterns for vector modes besides QImode, i.e., HImode,
SImode and DImode.
With this patch, we now generate the following for HImode:
cnt v1.16b, v.16b
uaddlp v2.8h, v1.16b
For SImode, we
On Tue, Apr 30, 2024 at 05:51:20PM -0400, Jason Merrill wrote:
> On 4/30/24 14:45, Qing Zhao wrote:
> >
> >
> > > On Apr 30, 2024, at 15:27, Jason Merrill wrote:
> > >
> > > On 4/30/24 07:58, Qing Zhao wrote:
> > > > The request for GCC to accept that the C99 flexible array member can be
> > >
On 4/30/24 2:36 PM, Patrick O'Neill wrote:
gcc/testsuite/ChangeLog:
PR middle-end/114734
* gcc.target/riscv/rvv/autovec/pr114734.c: New test.
OK
jeff
> On Apr 30, 2024, at 15:52, Jason Merrill wrote:
>
> On 4/30/24 14:49, Qing Zhao wrote:
>>> On Apr 30, 2024, at 15:45, Qing Zhao wrote:
>>>
>>>
>>>
> gcc/doc/extend.texi | 34 ++
> 1 file changed, 34 insertions(+)
> diff --git
On 4/30/24 14:49, Qing Zhao wrote:
On Apr 30, 2024, at 15:45, Qing Zhao wrote:
gcc/doc/extend.texi | 34 ++
1 file changed, 34 insertions(+)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 7b54a241a7bf..cba98c8aadd7 100644
---
On 4/30/24 14:45, Qing Zhao wrote:
On Apr 30, 2024, at 15:27, Jason Merrill wrote:
On 4/30/24 07:58, Qing Zhao wrote:
The request for GCC to accept that the C99 flexible array member can be
in a union or alone in a structure has been made a long time ago
around 2012
for supporting
On Apr 30, 2024, at 15:45, Qing Zhao wrote:
gcc/doc/extend.texi | 34 ++
1 file changed, 34 insertions(+)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 7b54a241a7bf..cba98c8aadd7 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@
On Apr 30, 2024, at 15:27, Jason Merrill wrote:
On 4/30/24 07:58, Qing Zhao wrote:
The request for GCC to accept that the C99 flexible array member can be
in a union or alone in a structure has been made a long time ago around 2012
for supporting several practical cases including glibc.
A GCC
On Apr 30, 2024, at 15:29, Jason Merrill wrote:
On 4/30/24 07:58, Qing Zhao wrote:
Add testing cases to test the _bos for flexible array members in unions
or alone in structures.
gcc/c/ChangeLog:
* c-decl.cc (add_flexible_array_elts_to_size): Handle the cases
when the DECL is union.
On Tue, Apr 30, 2024 at 11:12:30PM +0200, Martin Jambor wrote:
> Would the following then perhaps describe the situation accurately?
> Note that I have moved the whole thing to C++ section because it seems
> porting issues in C because of this are quite unlikely.
>
> Michal, I assume that the
On 4/30/24 07:58, Qing Zhao wrote:
Add testing cases to test the _bos for flexible array members in unions
or alone in structures.
gcc/c/ChangeLog:
* c-decl.cc (add_flexible_array_elts_to_size): Handle the cases
when the DECL is union.
gcc/cp/ChangeLog:
* decl.cc
On 4/30/24 07:58, Qing Zhao wrote:
The request for GCC to accept that the C99 flexible array member can be
in a union or alone in a structure has been made a long time ago around 2012
for supporting several practical cases including glibc.
A GCC PR has been opened for such request at that time:
while working on some new range-op enhancements, I found a couple of
developing asserts that no longer apply. This removed them.
Bootstrapped on x86_64-pc-linux-gnu with no regressions. pushed.
Andrew
From a89de3a24d2312438848e513a0b02b480d52c81e Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Also during stage 3/4, we discovered that it is unsafe to call ranger
from within SCEV. This is because ranger uses SCEV to resolve PHIS, and
we can end up in a bad loop under the right conditions.
The fix is for ranger's cache to NOT try to pre-evaluate PHIs (which is
kind of waste anyway
It was also requested that I make range_on_entry() and range_on_exit ()
part of the fomal API for a range_query. These are now provided along
with the orignal range_of_expr (), range_of_stmt (), and range_on_edge
(). The routines were already there, just not published for consumption
in the
If range_of_expr is called on an ssa-name with no context, ranger just
grabs whatever the global value is.
It was pointed out we can do better than this. If the name is in the
IL, there is no reason for ranger to not try to fold the statement and
see if we get a better result for it. It
This came up during stage 4 when someone noticed a comment that said
when legacy EVRP was removed, the wrapper around accessing
SSA_NAME_RANGES for initial values could be removed.
To be clearer, the original discussion is here:
https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571709.html
Hi,
On Thu, Apr 25 2024, Jakub Jelinek wrote:
> On Thu, Apr 25, 2024 at 02:34:22PM +0200, Martin Jambor wrote:
>> when looking at a package build issue with GCC 14, Michal Jireš noted a
>> different behavior of pragma GCC Target. This snippet tries to describe
>> the gist of the problem. I have
On 2/28/24 11:26, Ken Matsui wrote:
This patch implements built-in trait for std::is_nothrow_invocable.
OK after addressing comments on other traits.
gcc/cp/ChangeLog:
* cp-trait.def: Define __is_nothrow_invocable.
* constraint.cc (diagnose_trait_expr): Handle
On 2/28/24 11:26, Ken Matsui wrote:
This patch implements built-in trait for std::rank.
__rank seems too short, maybe __array_rank?
Actually, it occurs to me that perhaps we should have been adding
__builtin to all of these rather than just __ and the library trait
name. I guess it's too
On 2/28/24 11:26, Ken Matsui wrote:
This patch implements built-in trait for std::decay.
OK.
gcc/cp/ChangeLog:
* cp-trait.def: Define __decay.
* semantics.cc (finish_trait_type): Handle CPTK_DECAY.
gcc/testsuite/ChangeLog:
* g++.dg/ext/has-builtin-1.C: Test
On 2/28/24 11:26, Ken Matsui wrote:
This patch implements built-in trait for std::add_rvalue_reference.
gcc/cp/ChangeLog:
* cp-trait.def: Define __add_rvalue_reference.
* semantics.cc (finish_trait_type): Handle
CPTK_ADD_RVALUE_REFERENCE.
gcc/testsuite/ChangeLog:
On 2/28/24 11:26, Ken Matsui wrote:
This patch implements built-in trait for std::add_lvalue_reference.
OK.
gcc/cp/ChangeLog:
* cp-trait.def: Define __add_lvalue_reference.
* semantics.cc (finish_trait_type): Handle
CPTK_ADD_LVALUE_REFERENCE.
On 2/28/24 11:26, Ken Matsui wrote:
This patch implements built-in trait for std::remove_extent.
OK.
gcc/cp/ChangeLog:
* cp-trait.def: Define __remove_extent.
* semantics.cc (finish_trait_type): Handle CPTK_REMOVE_EXTENT.
gcc/testsuite/ChangeLog:
*
On 2/28/24 11:26, Ken Matsui wrote:
This patch implements built-in trait for std::remove_all_extents.
OK.
gcc/cp/ChangeLog:
* cp-trait.def: Define __remove_all_extents.
* semantics.cc (finish_trait_type): Handle
CPTK_REMOVE_ALL_EXTENTS.
gcc/testsuite/ChangeLog:
On 2/28/24 11:26, Ken Matsui wrote:
This patch implements built-in trait for std::add_pointer.
OK.
gcc/cp/ChangeLog:
* cp-trait.def: Define __add_pointer.
* semantics.cc (finish_trait_type): Handle CPTK_ADD_POINTER.
gcc/testsuite/ChangeLog:
*
On 2/28/24 11:26, Ken Matsui wrote:
This patch implements built-in trait for std::is_unbounded_array.
OK.
gcc/cp/ChangeLog:
* cp-trait.def: Define __is_unbounded_array.
* constraint.cc (diagnose_trait_expr): Handle
CPTK_IS_UNBOUNDED_ARRAY.
* semantics.cc
On 2/28/24 11:26, Ken Matsui wrote:
This patch implements built-in trait for std::is_pointer.
OK.
gcc/cp/ChangeLog:
* cp-trait.def: Define __is_pointer.
* constraint.cc (diagnose_trait_expr): Handle CPTK_IS_POINTER.
* semantics.cc (trait_expr_value): Likewise.
On Tue, Apr 30, 2024 at 1:50 PM Jason Merrill wrote:
>
> On 3/15/24 01:15, Ken Matsui wrote:
> > Added diagnostics for build_invoke.
> >
> > Ok for 15?
>
> Thanks, just a few tweaks needed. Will you have time to make them? Or
> Patrick?
I believe I will have time later next week. Thank you so
On 2/28/24 11:26, Ken Matsui wrote:
This patch implements built-in trait for std::is_volatile.
OK.
gcc/cp/ChangeLog:
* cp-trait.def: Define __is_volatile.
* constraint.cc (diagnose_trait_expr): Handle CPTK_IS_VOLATILE.
* semantics.cc (trait_expr_value): Likewise.
On 2/28/24 11:26, Ken Matsui wrote:
This patch implements built-in trait for std::is_const.
OK.
gcc/cp/ChangeLog:
* cp-trait.def: Define __is_const.
* constraint.cc (diagnose_trait_expr): Handle CPTK_IS_CONST.
* semantics.cc (trait_expr_value): Likewise.
On 3/15/24 01:15, Ken Matsui wrote:
Added diagnostics for build_invoke.
Ok for 15?
Thanks, just a few tweaks needed. Will you have time to make them? Or
Patrick?
[...]
diff --git a/gcc/cp/method.cc b/gcc/cp/method.cc
index 98c10e6a8b5..2282ce71c06 100644
--- a/gcc/cp/method.cc
+++
gcc/testsuite/ChangeLog:
PR middle-end/114734
* gcc.target/riscv/rvv/autovec/pr114734.c: New test.
Signed-off-by: Patrick O'Neill
---
Tested on rv64gcv before and after Richard Biener's fix:
4d3a5618de5a949c61605f545f90e81bc502
---
.../gcc.target/riscv/rvv/autovec/pr114734.c |
On 4/29/24 08:59, Wilco Dijkstra wrote:
According to documentation, '^' should only have an effect during reload.
However ira-costs.cc treats it in the same way as '?' during early costing.
As a result using '^' can accidentally disable valid alternatives and cause
significant regressions (see
Hi Paul,
On 4/30/24 07:50, Paul Richard Thomas wrote:
Hi Harald,
This patch is verging on 'obvious', . once one sees it :-)
Yes, it's good for mainline and all active branches, when available.
thanks for your quick review.
I haven't committed it yet, because I forgot to check what
On 4/30/24 12:04, Andrew Pinski wrote:
On Tue, Apr 30, 2024 at 11:54 AM Jason Merrill wrote:
On 2/20/24 19:06, Andrew Pinski wrote:
After r7-987-gf17a223de829cb, the access for the elements of a vector type
would lose the qualifiers.
So if we had `constvector[0]`, the type of the element of
On Tue, Apr 30, 2024 at 11:54 AM Jason Merrill wrote:
>
> On 2/20/24 19:06, Andrew Pinski wrote:
> > After r7-987-gf17a223de829cb, the access for the elements of a vector type
> > would lose the qualifiers.
> > So if we had `constvector[0]`, the type of the element of the array would
> > not
On 2/20/24 19:06, Andrew Pinski wrote:
After r7-987-gf17a223de829cb, the access for the elements of a vector type
would lose the qualifiers.
So if we had `constvector[0]`, the type of the element of the array would not
have const on it.
This was due to a missing build_qualified_type for the
On 3/4/24 06:18, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu. This should probably
wait for GCC 15 I suppose, but sending it in now in case there are any
comments.
OK for trunk.
-- >8 --
This clarifies which kinds of declarations may and may not be exported
in
The definition of LIMITS_H_TEST evaluates its existence in
BUILD_SYSTEM_HEADER_DIR, but we'd actually need it to check a target
version. Hence this check occasionally produces misdetections when build
and target differ. In some cases such as cygming, the header is only
installed after performing
On 4/30/24 00:59, Nathaniel Shead wrote:
On Sun, Apr 14, 2024 at 01:40:18AM +1000, Nathaniel Shead wrote:
On Fri, Apr 12, 2024 at 01:50:47PM -0400, Jason Merrill wrote:
On 4/11/24 20:40, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
The
On 30/04/2024 16:37, Torbjorn SVENSSON wrote:
>
>
> On 2024-04-30 17:11, Richard Earnshaw (lists) wrote:
>> On 27/04/2024 15:13, Torbjörn SVENSSON wrote:
>>> Add regression test to the existing zero/sign extend tests for CMSE to
>>> verify that r0, r1, r2 and r3 are properly extended, not just
The problem here is the quote mark is for English's
possessiveness rather than a quote but the error message
format detection is too simple so it warns which causes
-Werror to fail.
Committed as obvious after a quick build.
gcc/ChangeLog:
* tree-cfg.cc (verify_gimple_assign): Remove
Add target_version attribute to Common Function Attributes and update
target and target_clones documentation. Move shared detail and examples
to the Function Multiversioning page. Add target-specific details to
target-specific pages.
---
Changes since v1:
- Various typo fixes.
- Reordered
On Fri, Apr 12, 2024 at 05:41:11PM +0100, Richard Sandiford wrote:
> Hi Andrew,
>
> Thanks for doing this. I think it improves the organisation of the
> FMV documentation and adds some details that were previously missing.
>
> I've made some suggestions below, but documentation is subjective
>
On 4/30/24 8:43 AM, Gaius Mulley wrote:
> Christophe Lyon writes:
>
>> On Tue, 30 Apr 2024 at 04:01, Simon Marchi wrote:
>>>
>>> I get a diff when running "autoreconf" in this directory. I think that
>>> the current state is erroneous: it appears to have been generated using
>>>
>>>
On 4/30/24 4:54 AM, Christophe Lyon wrote:
> On Tue, 30 Apr 2024 at 04:25, Simon Marchi wrote:
>>
>> Add an "AC_CONFIG_MACRO_DIRS" call in configure.ac, with the same
>> directories as specified in "ACLOCAL_AMFLAGS", in Makefile.in.
>>
>> This makes it possible to re-generate aclocal.m4 using
This is almost exclusively Jivan's work. His original post:
https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg336483.html
This patch is primarily meant to improve the code we generate for FP
rounding such as ceil/floor. It also addresses some unnecessary sign
extensions in the
On 2024-04-30 17:11, Richard Earnshaw (lists) wrote:
On 27/04/2024 15:13, Torbjörn SVENSSON wrote:
Add regression test to the existing zero/sign extend tests for CMSE to
verify that r0, r1, r2 and r3 are properly extended, not just r0.
Test is done using -O0 to ensure the instructions are
> On Tue, Apr 30, 2024 at 10:23 AM Roger Sayle
> wrote:
> > Hi Richard,
> > Thanks for looking into this.
> >
> > It’s not the call to size_binop_loc (for CEIL_DIV_EXPR) that's
> > problematic, but the call to fold_convert_loc (loc, size_type_node, value)
> > on line
> 4009 of c-common.cc.
> >
On 27/04/2024 15:13, Torbjörn SVENSSON wrote:
> Add regression test to the existing zero/sign extend tests for CMSE to
> verify that r0, r1, r2 and r3 are properly extended, not just r0.
>
> Test is done using -O0 to ensure the instructions are in a predictable
> order.
>
>
Add testing cases to test the _bos for flexible array members in unions
or alone in structures.
gcc/c/ChangeLog:
* c-decl.cc (add_flexible_array_elts_to_size): Handle the cases
when the DECL is union.
gcc/cp/ChangeLog:
* decl.cc (layout_var_decl): Handle the cases when
gcc/testsuite/ChangeLog:
* c-c++-common/fam-in-union-alone-in-struct-1.c: New testcase.
* c-c++-common/fam-in-union-alone-in-struct-2.c: New testcase.
* c-c++-common/fam-in-union-alone-in-struct-3.c: New testcase.
---
.../fam-in-union-alone-in-struct-1.c | 52
to support flexible array members
in unions and alone in structures. Adjust testcases for flexible array member
in union and alone in structure extension.
gcc/c/ChangeLog:
* c-decl.cc (finish_struct): Change errors to pedwarns for the cases
flexible array members in union or
Hi,
This is the 3rd version for
Allow flexible array members in unions and alone in structures [PR53548]
(for your reference, the 1st version is at:
https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649737.html
The 2nd version is at:
The request for GCC to accept that the C99 flexible array member can be
in a union or alone in a structure has been made a long time ago around 2012
for supporting several practical cases including glibc.
A GCC PR has been opened for such request at that time:
On Thu, Apr 25, 2024 at 2:40 AM Hans-Peter Nilsson wrote:
>
> On Tue, 23 Apr 2024, Manolis Tsamis wrote:
> > diff --git a/gcc/testsuite/gcc.target/aarch64/ifcvt_multiple_sets_arithm.c
> > b/gcc/testsuite/gcc.target/aarch64/ifcvt_multiple_sets_arithm.c
> ...
> > +/* { dg-final {
Rainer Orth writes:
> Hi Gaius,
>
>> yes this looks good to me please apply. Thanks for the rationale
>
> done for trunk. I guess it's ok to apply to the gcc-14 branch after the
> release and some soak time?
many thanks - and yes certainly also to gcc-14 (after an appropriate
amount of
Pushed the commit c74a573fa888f3970b6b38d57020f0160e49e58a
frontends.html: Mention modula-2 was merged during gcc-13.
gcc-14/changes.html: New section heading for modula-2 and populate.
index.html: Add modula-2 to the list of languages supported by GCC.
readings.html (Modula 2
Christophe Lyon writes:
> On Tue, 30 Apr 2024 at 04:01, Simon Marchi wrote:
>>
>> I get a diff when running "autoreconf" in this directory. I think that
>> the current state is erroneous: it appears to have been generated using
>>
>> aclocal -I ../config -I ..
>>
>> even though
Hi Alexandre,
On Tue, 30 Apr 2024 at 01:31, Alexandre Oliva wrote:
>
> On Apr 22, 2024, Richard Biener wrote:
>
> >> Regstrapped on x86_64-linux-gnu and ppc64el-linux-gnu. Also tested with
> >> gcc-13 on ppc64-vx7r2 and ppc-vx7r2. Ok to install?
>
> > That makes sense. OK
>
> >> for
Hi Gaius,
> yes this looks good to me please apply. Thanks for the rationale
done for trunk. I guess it's ok to apply to the gcc-14 branch after the
release and some soak time?
> described in the PR. As suggested, locally changing site.exp is more
> appropriate should the need arise. The
Rainer Orth writes:
> A large number of gm2 tests are timing out even on current Solaris/SPARC
> systems. As detailed in the PR, the problem is that the gm2 testsuite
> artificially lowers many timeouts way below the DejaGnu default of 300
> seconds, often as short as 10 seconds. The problem
Linaro reports one build failure for arm but works well in aarch64.
/home/tcwg-build/workspace/tcwg_gnu_2/abe/snapshots/gcc.git~master/gcc/dse.cc:1951:45:
error: 'REGMODE_NATURAL_SIZE' was not declared in this scope
Looks only part of backend implemented REGMODE_NATURAL_SIZE, then reference
On Mon, Apr 29, 2024 at 5:12 PM Joe Ramsay wrote:
>
> This optimisation does not honour signed zeros, so should not be
> enabled except with -fno-signed-zeros.
>
> Cherry-pick of 7dd3b2b09cbeb6712ec680a0445cb0ad41070423.
>
> Applies cleanly on releases/gcc-13, regression-tested with no new
>
On 20/11/23 11:22 -0500, Ben Boeckel wrote:
---
htdocs/gcc-14/changes.html | 11 +++
1 file changed, 11 insertions(+)
diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index 7278f753..b506eeb1 100644
--- a/htdocs/gcc-14/changes.html
+++ b/htdocs/gcc-14/changes.html
@@
On Tue, Apr 30, 2024 at 10:23 AM Roger Sayle wrote:
>
>
> Hi Richard,
> Thanks for looking into this.
>
> It’s not the call to size_binop_loc (for CEIL_DIV_EXPR) that's problematic,
> but the
> call to fold_convert_loc (loc, size_type_node, value) on line 4009 of
> c-common.cc.
> At this point,
On Tue, 30 Apr 2024, Jakub Jelinek wrote:
> Hi!
>
> The assertion doesn't allow IFN_COND_MIN/IFN_COND_MAX, which are
> commutative conditional binary operations like ADD/MUL/AND/IOR/XOR,
> and can be handled just fine.
> In particular, we emit
> vminpd %zmm3, %zmm5, %zmm0{%k2}
>
On Tue, 30 Apr 2024, Jakub Jelinek wrote:
> Hi!
>
> Seems when Martin S. implemented this, he coded there strict reading
> of the standard, which said that %lc with (wint_t) 0 argument is handled
> as wchar_t[2] temp = { arg, 0 }; %ls with temp arg and so shouldn't print
> any values. But, most
On Tue, 30 Apr 2024 at 04:25, Simon Marchi wrote:
>
> Add an "AC_CONFIG_MACRO_DIRS" call in configure.ac, with the same
> directories as specified in "ACLOCAL_AMFLAGS", in Makefile.in.
>
> This makes it possible to re-generate aclocal.m4 using "autoreconf".
Thanks, this LGTM, although like in
On Tue, 30 Apr 2024 at 04:01, Simon Marchi wrote:
>
> I get a diff when running "autoreconf" in this directory. I think that
> the current state is erroneous: it appears to have been generated using
>
> aclocal -I ../config -I ..
>
> even though configure.ac and Makefile.am list the include
Ughhh, you're right. Thanks for spotting this.
I'm testing the attached patch and will commit if it passes tests.
Aldy
On Tue, Apr 30, 2024 at 9:46 AM Richard Biener
wrote:
>
> On Sun, Apr 28, 2024 at 9:07 PM Aldy Hernandez wrote:
> >
> > Fix some Value_Range's that we know ahead of time
Starting with r14-2047-gd0e891406b16dc we see through subregs which
means for f10 in risbg-ll-2.c we do not end up with rosbg_si_noshift but
rather rosbg_di_noshift which materializes in slightly different start
index. This saves us an extend.
gcc/testsuite/ChangeLog:
*
Starting with r12-2731-g96146e61cd7aee we do not generate code like
_5 = (unsigned int) c_2(D);
i_6 = _5 << 8;
_7 = _5 << 20;
i_8 = i_6 | _7;
anymore but instead
_5 = (unsigned int) c_2(D);
_3 = _5 * 1048832;
which leads finally to slightly different assembly code where we
previously ended up
Hi Richard,
Thanks for looking into this.
It’s not the call to size_binop_loc (for CEIL_DIV_EXPR) that's problematic, but
the
call to fold_convert_loc (loc, size_type_node, value) on line 4009 of
c-common.cc.
At this point, value is (NOP_EXPR:sizetype (VAR_DECL:error_mark_node)).
Ultimately,
On Sun, Apr 28, 2024 at 8:31 AM Andrew Pinski wrote:
>
> I noticed that single_non_singleton_phi_for_edges could
> return a phi whos entry are all the same for the edge.
> This happens only if there was a single phis in the first place.
> Also gimple_seq_singleton_p walks the sequence to see if
On Sun, Apr 28, 2024 at 8:31 AM Andrew Pinski wrote:
>
> This adds a few early outs to value_replacement that I noticed
> while rewriting this to use match-and-simplify but could be committed
> seperately.
> * virtual operands won't change so return early for them
> * special case `A ? B : B` as
On Tue, Apr 30, 2024 at 3:38 PM Jakub Jelinek wrote:
>
> On Tue, Apr 30, 2024 at 09:30:00AM +0200, Richard Biener wrote:
> > On Mon, Apr 29, 2024 at 5:30 PM H.J. Lu wrote:
> > >
> > > On Mon, Apr 29, 2024 at 6:47 AM liuhongt wrote:
> > > >
> > > > The Fortran standard does not specify what the
On Sat, Apr 27, 2024 at 1:04 AM Andrew Pinski wrote:
>
> When cfgexpand was changed to support expanding from tuple gimple
> (r0-95521-g28ed065ef9f345), the code was added to support
> doing nontemporal stores with LHS of a SSA_NAME but that will
> never be a nontemporal store.
> This patch
On Sat, Apr 27, 2024 at 1:04 AM Andrew Pinski wrote:
>
> Currently the middle-end only knows how to support temporal stores
> (the undocumented storent optab) so let's verify that the only time
> we set nontemporal_move on an assign is if the the lhs is not a
> gimple reg.
>
> Bootstrapped and
On Sun, Apr 14, 2024 at 01:40:18AM +1000, Nathaniel Shead wrote:
> On Fri, Apr 12, 2024 at 01:50:47PM -0400, Jason Merrill wrote:
> > On 4/11/24 20:40, Nathaniel Shead wrote:
> > > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
> > >
> > > -- >8 --
> > >
> > > The modules code
On Fri, Apr 19, 2024 at 11:49 AM Arthur Cohen wrote:
>
> Hi everyone,
>
> This patch checks for the presence of dlopen and pthread_create in libc. If
> that is not the
> case, we check for the existence of -ldl and -lpthread, as these libraries
> are required to
> link the Rust runtime to our
On Sun, Apr 28, 2024 at 9:07 PM Aldy Hernandez wrote:
>
> Fix some Value_Range's that we know ahead of time will be only
> integers. This avoids using the polymorphic Value_Range unnecessarily
But isn't Value_Range a variable-size irange but int_range<2> doesn't
support more than two
On Sun, Apr 28, 2024 at 10:24 AM Alexandre Oliva wrote:
>
>
> The fact that both options accept negative forms suggests that maybe
> they aren't negative forms of each other. They are, but that isn't
> clear even by examining common.opt. Use NegativeAlias to make it
> abundantly clear.
>
> The
On Tue, Apr 30, 2024 at 09:30:00AM +0200, Richard Biener wrote:
> On Mon, Apr 29, 2024 at 5:30 PM H.J. Lu wrote:
> >
> > On Mon, Apr 29, 2024 at 6:47 AM liuhongt wrote:
> > >
> > > The Fortran standard does not specify what the result of the MAX
> > > and MIN intrinsics are if one of the
On Tue, Apr 30, 2024 at 1:06 AM Roger Sayle wrote:
>
>
> This patch solves another ICE-after-error problem in the C family
> front-ends. Upon a conflicting type redeclaration, the ambiguous
> type is poisoned with an error_mark_node to indicate to the middle-end
> that the type is suspect, but
Hi!
The assertion doesn't allow IFN_COND_MIN/IFN_COND_MAX, which are
commutative conditional binary operations like ADD/MUL/AND/IOR/XOR,
and can be handled just fine.
In particular, we emit
vminpd %zmm3, %zmm5, %zmm0{%k2}
vminpd %zmm0, %zmm3, %zmm5{%k1}
and
vmaxpd
On Mon, Apr 29, 2024 at 5:30 PM H.J. Lu wrote:
>
> On Mon, Apr 29, 2024 at 6:47 AM liuhongt wrote:
> >
> > The Fortran standard does not specify what the result of the MAX
> > and MIN intrinsics are if one of the arguments is a NaN. So it
> > should be ok to tranform reduction for IFN_COND_MIN
A large number of gm2 tests are timing out even on current Solaris/SPARC
systems. As detailed in the PR, the problem is that the gm2 testsuite
artificially lowers many timeouts way below the DejaGnu default of 300
seconds, often as short as 10 seconds. The problem lies both in the
values (they
Hi!
Seems when Martin S. implemented this, he coded there strict reading
of the standard, which said that %lc with (wint_t) 0 argument is handled
as wchar_t[2] temp = { arg, 0 }; %ls with temp arg and so shouldn't print
any values. But, most of the libc implementations actually handled that
case
Hi,
It's the forth patch of a series of patches optimizing CC modes on
rs6000.
The single CC bit reverse can be implemented by setbcr on Power10 or
isel on Power9 or mfcr on Power8 and below. Originally CCFP is not
supported for isel and setbcr as bcd insns use CCFP and its bit reverse
is not
Hi,
It's the third patch of a series of patches optimizing CC modes on
rs6000.
This patch sets CC mode of vector string isolate insns to CCEQ instead
of CCFP as these insns only set/check CR bit 2.
Bootstrapped and tested on powerpc64-linux BE and LE with no
regressions. Is it OK for the
Hi,
It's the second patch of a series of patches optimizing CC modes on
rs6000.
This patch adds a new type of CC mode - CCLTEQ used for the case which
only set CR bit 0 and 2. The bit 1 and 3 are not used. The vector compare
and test data class instructions are the cases.
Bootstrapped and
Hi,
It's the first patch of a series of patches optimizing CC modes on
rs6000.
bcd insns set all four bits of a CR field. But it has different single
bit reverse behavior than CCFP's. The forth bit of bcd cr fields is used
to indict overflow or invalid number. It's not a bit for unordered
From: Pan Li
We allowed vector type for get_stored_val when read is less than or
equal to store in previous. Unfortunately, the valididate_subreg
treats the vector type's size is less than vector register as
invalid. Then we will have ICE here.
This patch would like to fix it by filter-out
1 - 100 of 101 matches
Mail list logo
