On 12/06/24 12:43 +0200, Rene Rebe wrote:
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index e2870eef2ef..4328ca5f84c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -78,6 +78,7 @@ i386 port Jan Hubicka
i386 port Uro
testsuite: Fix pr66144-3.c test to accept multiple equivalent insns. [PR115262]
Jeff's commit r15-831-g05daf617ea22e1 changed the instruction we expected
for this test case into an equivalent instruction. Modify the test case
so it will accept any of three equivalent instructions we could get dep
Hi!
On Wed, Jun 12, 2024 at 02:49:40PM -0500, Peter Bergner wrote:
> testsuite: Fix pr66144-3.c test to accept multiple equivalent insns.
> [PR115262]
("rs6000:", not "testsuite")
> Jeff's commit r15-831-g05daf617ea22e1 changed the instruction we expected
> for this test case into an equivalent
On 6/12/24 11:46, Patrick O'Neill wrote:
This patch removes trailing whitespace and replaces leading groups of 8-16
spaces with tabs.
gcc/testsuite/ChangeLog:
* lib/target-supports.exp: Cleanup whitespace.
Signed-off-by: Patrick O'Neill
---
Pre-approved here:
https://inbox.sourcewa
Hi Robin,
I did a test run without the subreg condition and it also appears to
work when running on rv32gcv and rv64gcv newlib. Would it be better to
remove the subreg?
Edwin
On 6/12/2024 12:42 AM, Robin Dapp wrote:
Hi Edwin,
this is OK but did you check if we can get rid of the subreg
con
This patch makes more use of m32bcst and m64bcst addressing modes in
ix86_expand_ternlog. Previously, the i386 backend would only consider
using a m32bcst if the inner mode of the vector was 32-bits, or using
m64bcst if the inner mode was 64-bits. For ternlog (and other logic
operations) this is
On 6/12/2024 12:39 AM, Robin Dapp wrote:
Hi Edwin,
this LGTM but I just remembered I intended to turn the assert
into a more descriptive error.
The attached patch has been sitting on my local branch for a
while. Maybe we should rather fold yours into it?
That's fine with me! Having more desc
On 6/12/24 14:49, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
OK for trunk and 14, I'd say.
-- >8 --
It seems we don't maintain visibility flags for concepts either, so
min_vis_expr_r should ignore them for now, otherwise after r14-678
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
The r15-1180 adjustments to this testcase broke a couple of tests in C++26
mode.
gcc/testsuite/ChangeLog:
* g++.dg/cpp26/static_assert1.C: Fix diagnostic typos.
---
gcc/testsuite/g++.dg/cpp26/static_assert1.C | 4 ++--
1 file chan
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
exception_ptr.h contains
namespace __exception_ptr
{
class exception_ptr;
}
using __exception_ptr::exception_ptr;
so when module std tries to 'export using std::exception_ptr', it names
another using-directive rather than the c
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
A sample implementation of module std was breaking because the exports
included 'using std::operator&' twice. Since Nathaniel's r15-964 for
PR114867, the first using added an extra instance of each function that was
revealed/exported by tha
This should be safe to test when the class is instantiated (unlike
testing that the hash function is invocable, which we delay until it's
needed). A disabled std::hash specialization is not copy constructible,
and std::hash for a forward-declared std::string is
disabled, so this greatly improves th
Tested x86_64-linux.
-- >8 --
The P2278R4 additions for C++23 are currently guarded by a check for
__cplusplus > 202002L but can use __glibcxx_ranges_as_const instead.
libstdc++-v3/ChangeLog:
* include/bits/ranges_base.h (const_iterator_t): Change
preprocessor condition to use _
Jason noticed this was missing.
Tested x86_64-linux.
-- >8 --
LWG 3860 added this alias template. Both libc++ and MSVC treat this as a
DR for C++20, so this change does so too.
libstdc++-v3/ChangeLog:
* include/bits/ranges_base.h (range_common_reference_t): New
alias template,
Tested x86_64-linux.
-- >8 --
For the GNU locale model, codecvt::do_out and codecvt::do_in incorrectly
return 'ok' when the destination range is empty. That happens because
detecting incomplete output is done in the loop body, and the loop is
never even entered if to == to_end.
By restructuring
This is enough to fix the regression for now.
I think we should revert more of the upstream change that switched #if
to #ifdef everywhere, as much of it was unnecessary and causes issues
for people combining our pstl headers with the one's in Intel oneAPI
(which share the same names for pstl_confi
On Wed, Jun 12, 2024 at 1:32 PM Jason Merrill wrote:
>
> Tested x86_64-pc-linux-gnu, applying to trunk.
>
> -- 8< --
>
> A sample implementation of module std was breaking because the exports
> included 'using std::operator&' twice. Since Nathaniel's r15-964 for
> PR114867, the first using added
Hi Jonathan, Richard,
On 12.06.24 20:54, Jonathan Wakely wrote:
On 12/06/24 16:09 +0200, Frank Scheiner wrote:
Dear Richard,
On 12.06.24 13:01, Richard Biener wrote:
[...]
I can find two gcc-testresult postings, one appearantly with LRA
and one without? Both from May:
https://sourceware.org
"Richard Earnshaw (lists)" writes:
> On 10/06/2024 15:04, Torbjörn SVENSSON wrote:
>> Properly handle zero and sign extension for Armv8-M.baseline as
>> Cortex-M23 can have the security extension active.
>> Currently, there is an internal compiler error on Cortex-M23 for the
>> epilog processing o
On Jun 12, 2024, Jonathan Wakely wrote:
> On Wed, 12 Jun 2024, 02:17 Alexandre Oliva, wrote:
>>
>> Some c++23 tests fail on targets that don't satisfy dg-require-cmath,
>> because referenced math functions don't get declared in std.
> Are they present on the target at all? Is not declaring the
Binutils 2.42 and before don't support Zaamo/Zalrsc. Add a configure
check to prevent emitting Zaamo/Zalrsc in the arch string when the
assember does not support it.
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc
(riscv_subset_list::to_string): Skip zaamo/zalrsc when not
On Wed, 12 Jun 2024 16:20:26 PDT (-0700), Patrick O'Neill wrote:
Binutils 2.42 and before don't support Zaamo/Zalrsc. Add a configure
check to prevent emitting Zaamo/Zalrsc in the arch string when the
assember does not support it.
Should we just rewrite these to A when binutils doesn't support
Palmer Dabbelt writes:
> On Wed, 12 Jun 2024 16:20:26 PDT (-0700), Patrick O'Neill wrote:
>> Binutils 2.42 and before don't support Zaamo/Zalrsc. Add a configure
>> check to prevent emitting Zaamo/Zalrsc in the arch string when the
>> assember does not support it.
>
> Should we just rewrite these
On 6/12/24 16:49, Sam James wrote:
Palmer Dabbelt writes:
On Wed, 12 Jun 2024 16:20:26 PDT (-0700), Patrick O'Neill wrote:
Binutils 2.42 and before don't support Zaamo/Zalrsc. Add a configure
check to prevent emitting Zaamo/Zalrsc in the arch string when the
assember does not support it.
S
On Wed, 12 Jun 2024 16:56:09 PDT (-0700), Patrick O'Neill wrote:
On 6/12/24 16:49, Sam James wrote:
Palmer Dabbelt writes:
On Wed, 12 Jun 2024 16:20:26 PDT (-0700), Patrick O'Neill wrote:
Binutils 2.42 and before don't support Zaamo/Zalrsc. Add a configure
check to prevent emitting Zaamo/Za
On 6/12/24 3:00 PM, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Jun 12, 2024 at 02:49:40PM -0500, Peter Bergner wrote:
>> testsuite: Fix pr66144-3.c test to accept multiple equivalent insns.
>> [PR115262]
>
> ("rs6000:", not "testsuite")
Done.
>> /* { dg-do compile { target { powerpc64*-*-*
Palmer Dabbelt writes:
> On Wed, 12 Jun 2024 16:56:09 PDT (-0700), Patrick O'Neill wrote:
>>
>> On 6/12/24 16:49, Sam James wrote:
>>> Palmer Dabbelt writes:
>>>
On Wed, 12 Jun 2024 16:20:26 PDT (-0700), Patrick O'Neill wrote:
> Binutils 2.42 and before don't support Zaamo/Zalrsc. Add a
Andrea Parri recently pointed out that we were emitting overly conservative
fences for seq_cst atomic loads/stores. This adds support for the optimized
fences specified in the PSABI:
https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/2092568f7896ceaa1ec0f02569b19eaa42cd51c9/riscv-atomic.adoc
On Thu, Jun 13, 2024 at 4:20 AM Roger Sayle wrote:
>
>
> This patch makes more use of m32bcst and m64bcst addressing modes in
> ix86_expand_ternlog. Previously, the i386 backend would only consider
> using a m32bcst if the inner mode of the vector was 32-bits, or using
> m64bcst if the inner mode
r15-1100-gec985bc97a0157 improves handling of ternlog instructions,
now GCC can recognize lots of pternlog_operand with different
variants.
The patch adjust rtx_costs for that, so pass_combine can
reasonably generate more optimal vpternlog instructions.
.i.e
for avx512f-vpternlog-3.c, with the pa
On Thu, Jun 6, 2024 at 4:49 PM Kong, Lingling wrote:
>
> Enable ZU for IMUL (opcodes 0x69 and 0x6B) and SETcc.
>
> gcc/ChangeLog:
>
> * config/i386/i386-opts.h (enum apx_features):Add apx_zu.
> * config/i386/i386.h (TARGET_APX_ZU): Define.
> * config/i386/i386.md (*imulhizu
On Wed, Jun 12, 2024 at 07:02:31PM -0500, Peter Bergner wrote:
> On 6/12/24 3:00 PM, Segher Boessenkool wrote:
> >> /* { dg-do compile { target { powerpc64*-*-* } } } */
> >
> > Probably should be an "lp64" instead?
>
> Actually, there is nothing inherently 64-bit about the test case.
> I remove
On Thu, May 30, 2024 at 1:52 PM Hu, Lin1 wrote:
>
> Hi, all
>
> This patch aims to extend __builtin_ia32_cmp[p|s][s|d] from avx to
> sse/sse2/avx, where its immediate is in range of [0, 7].
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
Ok.
>
> BRs,
> Lin
>
> gcc/ChangeLog:
>
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 V8HI:
cnt v1.16b, v.16b
uaddlp v2.8h, v1.16b
For V4HI, we gene
Thanks for the advice, updated patch in attachment.
Bootstrapped/regtested on x86-64-pc-linux-gnu. Ok for trunk?
Uros Bizjak 于2024年6月12日周三 18:12写道：
>
> On Wed, Jun 12, 2024 at 12:00 PM Uros Bizjak wrote:
> >
> > On Wed, Jun 12, 2024 at 5:12 AM Hongyu Wang wrote:
> > >
> > > Hi,
> > >
> > > For
> Pengxuan Zheng writes:
> > 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.16
Hi,
For "-m32 -mpowerpc64", it is also ok to use just one instruciton (p?ld)
to loading 64bit constant from memory. So, splitting the complicate 64bit
constant to constant pool should also work under this case.
Compare with previous version, this update the threshold for the insn number
of the co
Hi,
Sometimes, a complicated constant is built via 3(or more)
instructions. Generally speaking, it would not be as fast
as loading it from the constant pool (as the discussions in
PR63281):
"ld" is one instruction. If consider "address/toc" adjust,
we may count it as 2 instructions. And "pld" ma
Committed, thanks Jeff.
Pan
-Original Message-
From: Jeff Law
Sent: Thursday, June 13, 2024 2:11 AM
To: Li, Pan2 ; gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; richard.guent...@gmail.com;
pins...@gmail.com
Subject: Re: [PATCH v2] Test: Move target independent
Ping.
On 6/7/24 11:06 PM, Peter Bergner wrote:
> We currently only compute the offset for the ROP hash save location in
> the stack frame for Altivec compiles. For non-Altivec compiles when we
> emit ROP mitigation instructions, we use a default offset of zero which
> corresponds to the backchain
Hi,
In cfgexpand, there is an optimization for branch which tests
targetm.gen_ccmp_first == NULL. However for target like x86-64, the
hook was implemented but it does not indicate that ccmp was enabled.
Add a new target hook TARGET_HAVE_CCMP and replace the middle-end
check for the existance of ge
On 6/12/24 14:22, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk/14?
OK.
-- >8 --
Since the terms of a requires-clause are grammatically primary-expressions
rather than e.g. postfix-expressions, it seems we need to explicitly
handle and di
On 6/12/24 13:56, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk/14?
-- >8 --
Here during overload resolution we have two strictly viable ambiguous
candidates #1 and #2, and two non-strictly viable candidates #3 and #4
which we hold on to eve
On 6/12/24 13:20, Andi Kleen wrote:
asm constexpr now only accepts the same string types as C++26 assert,
e.g. string_view and string. Adjust test suite and documentation.
This patchset is all OK, thanks.
gcc/cp/ChangeLog:
* parser.cc (cp_parser_asm_string_expression): Remove support
Use reg_or_subregno instead.
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Committed as an obvious patch.
gcc/ChangeLog:
PR target/115452
* config/i386/i386-features.cc (scalar_chain::convert_op): Use
reg_or_subregno instead of REGNO to avoid ICE.
gcc/testsui
Hi Peter,
on 2024/6/8 12:06, Peter Bergner wrote:
> We currently only compute the offset for the ROP hash save location in
> the stack frame for Altivec compiles. For non-Altivec compiles when we
> emit ROP mitigation instructions, we use a default offset of zero which
> corresponds to the backch
Hi,
on 2024/6/13 02:56, Michael Meissner wrote:
> On Wed, Jun 12, 2024 at 02:23:18PM +0800, Kewen.Lin wrote:
>> Hi Mike,
>>
>>> +# Return 1 if this is a PowerPC target supporting -mcpu=power11.
>>> +
>>> +proc check_effective_target_power11_ok { } {
>>> +if { ([istarget powerpc*-*-*]) } {
>>>
On Thu, Jun 13, 2024 at 3:44 AM Hongyu Wang wrote:
>
> Thanks for the advice, updated patch in attachment.
>
> Bootstrapped/regtested on x86-64-pc-linux-gnu. Ok for trunk?
>
> Uros Bizjak 于2024年6月12日周三 18:12写道：
> >
> > On Wed, Jun 12, 2024 at 12:00 PM Uros Bizjak wrote:
> > >
> > > On Wed, Jun 1
> Perhaps the constraint can be slightly optimized to avoid repeating
> (,) pairs.
>
> ",m,"
> "C ,,"
Yes, will check-in with this change. Thanks!
Uros Bizjak 于2024年6月13日周四 14:06写道：
>
> On Thu, Jun 13, 2024 at 3:44 AM Hongyu Wang wrote:
> >
> > Thanks for the advice, updated patch in attac
101 - 149 of 149 matches
Mail list logo
