> 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
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
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*-*-*]) } {
>>>
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
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
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
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 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
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
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
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
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
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
> 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
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
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
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:
>
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, 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
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 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
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
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
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*-*-*
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 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
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 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
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 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
"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
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
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
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
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
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 --
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 _
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-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
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< --
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
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
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
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
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
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!
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
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
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
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*-*-*]) } {
> > + return [check_no_compiler_messages power11_ok ob
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/pipermail/gcc-testresults/2024-May/816422.html
https://sourceware
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
-- >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-6789 we
incorrectly give function templates that use a concept-id in their
si
On 12/06/24 19:40 +0100, Jonathan Wakely wrote:
On 12/06/24 12:42 +0200, Rene Rebe wrote:
The following un-deprecates ia64*-*-linux for GCC 15. Since we plan to
support this for some years to come.
gcc/
* config.gcc: Only exlicitly list ia64*-*-(hpux|vms|elf) in the
"exlicitly"
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.sourceware.org/gcc-patches/3312c6a8-8f34-43f0-8562-99
> On 6/12/24 09:55, Jose E. Marchesi wrote:
>>
>> Hi Faust.
>> Thanks for the patch.
>> Please see a question below.
>>
>>> This patch enables -gprune-btf by default in the BPF backend when
>>> generating BTF information, and fixes BPF CO-RE generation when using
>>> -gprune-btf.
>>>
>>> When g
On 12/06/24 12:33 +0200, Rene Rebe wrote:
Hey there,
I wanted to come back to maintaining the ia64 port as discussed
preciously the other month on the gcc list.
It has been some days as we were busy releasing the biggest release of
our Embdded T2/Linux distribution [0] and we obviously did not
On 12/06/24 12:42 +0200, Rene Rebe wrote:
The following un-deprecates ia64*-*-linux for GCC 15. Since we plan to
support this for some years to come.
gcc/
* config.gcc: Only exlicitly list ia64*-*-(hpux|vms|elf) in the
list of obsoleted targets.
contrib/
* config-list.mk
I missed this target-specific usage of pretty_printer::buffer when
making the fields private in r15-1209-gc5e3be456888aa; sorry.
Verified that this fixes the build breakage with
--target=aarch64-unknown-linux-gnu.
Pushed as r15-1220-ge35f4eab68773b.
gcc/ChangeLog:
PR bootstrap/115465
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk/14?
-- >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 diagnose the case where a term parses to bare unre
On 6/12/24 11:12, Jeff Law wrote:
On 6/11/24 12:03 PM, Patrick O'Neill wrote:
This series moves the atomic-related riscv testcases into their own
folder and
fixes some minor bugs/rigidity of existing testcases.
This series is OK.
jeff
Committed, thanks.
Patrick
An update on this task. (Also need more suggestions -:)
I have an initial implemenation locally, with this gcc, I can get the following
message with the testing case in PR109071:
[ 109071]$ cat t.c
extern void warn(void);
static inline void assign(int val, int *regs, int *index)
{
if (*index >
On 6/11/24 12:21 PM, Patrick O'Neill wrote:
I made the whitespace cleanup patch (trailing whitespace, leading groups
of 8 spaces -> tabs) for
target-supports.exp and got a diff of 584 lines.
Is this still worth doing or will it be too disruptive for rebasing/
other people's development?
On 6/11/24 12:03 PM, Patrick O'Neill wrote:
This series moves the atomic-related riscv testcases into their own folder and
fixes some minor bugs/rigidity of existing testcases.
This series is OK.
jeff
On 6/11/24 8:53 AM, pan2...@intel.com wrote:
From: Pan Li
The test cases of pr115387 are target independent, at least x86
and riscv are able to reproduce. Thus, move these cases to
the gcc.dg/torture.
The below test suites are passed.
1. The rv64gcv fully regression test.
2. The x86 full
On Wed, 12 Jun 2024, 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
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 ever since r14-6522. These latter candidate
On 6/12/24 09:55, Jose E. Marchesi wrote:
>
> Hi Faust.
> Thanks for the patch.
> Please see a question below.
>
>> This patch enables -gprune-btf by default in the BPF backend when
>> generating BTF information, and fixes BPF CO-RE generation when using
>> -gprune-btf.
>>
>> When generating B
gcc/cp/ChangeLog:
* parser.cc (cp_parser_asm_string_expression): Use correct error
message.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1z/constexpr-asm-3.C: Adjust for new message.
---
gcc/cp/parser.cc | 2 +-
gcc/testsuite/g++.dg/cpp1z/constexpr-as
To get better error recovery.
gcc/cp/ChangeLog:
* parser.cc (cp_parser_asm_string_expression): Parse close
parent when constexpr extraction fails.
---
gcc/cp/parser.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
index 98
asm constexpr now only accepts the same string types as C++26 assert,
e.g. string_view and string. Adjust test suite and documentation.
gcc/cp/ChangeLog:
* parser.cc (cp_parser_asm_string_expression): Remove support
for const char * for asm constexpr.
gcc/ChangeLog:
*
On Wed, 12 Jun 2024 10:09:06 PDT (-0700), Patrick O'Neill wrote:
On 6/12/24 04:21, Andreas Schwab wrote:
On Jun 12 2024, Li, Pan2 wrote:
Do we need to upgrade the binutils of the riscv-gnu-toolchain repo? Or we may
have unknown prefixed ISA extension `zaamo' when building.
There needs to be
On 6/12/24 04:21, Andreas Schwab wrote:
On Jun 12 2024, Li, Pan2 wrote:
Do we need to upgrade the binutils of the riscv-gnu-toolchain repo? Or we may
have unknown prefixed ISA extension `zaamo' when building.
There needs to be a configure check if binutils can grok the extension.
Ack. I'l
Hi Faust.
Thanks for the patch.
Please see a question below.
> This patch enables -gprune-btf by default in the BPF backend when
> generating BTF information, and fixes BPF CO-RE generation when using
> -gprune-btf.
>
> When generating BPF CO-RE information, we must ensure that types used
> in C
Richard Biener writes:
> On Fri, May 10, 2024 at 4:25 AM HAO CHEN GUI wrote:
>>
>> Hi,
>>The cost return from set_src_cost might be zero. Zero for
>> pattern_cost means unknown cost. So the regularization converts the zero
>> to COSTS_N_INSNS (1).
>>
>>// pattern_cost
>>cost = set_src
Tested x86_64-linux. Pushed to trunk.
-- >8 --
The shift operations for dynamic_bitset fail to zero out words where the
non-zero bits were shifted to a completely different word.
For a right shift we don't need to sanitize the unused bits in the high
word, because we know they were already clear
Tested x86_64-linux. Pushed to trunk.
-- >8 --
Using memset is incorrect if the __bucket_ptr type is non-trivial, or
does not use an all-zero bit pattern for its null value.
Replace the three uses of memset with std::fill_n to set the pointers to
nullptr.
libstdc++-v3/ChangeLog:
* incl
On 6/12/24 10:02, Andi Kleen wrote:
No semantics changes.
gcc/cp/ChangeLog:
* cp-tree.h (extract): Add new overload to return tree.
* parser.cc (cp_parser_asm_string_expression): Use tree extract.
* semantics.cc (cexpr_str::extract): Add new overload to return
On Mon, 3 Jun 2024, David Malcolm wrote:
> > Thank you for fixing this up. Is this a new requirement now for
> > .opt
> > file changes?
>
> Yes, as of GCC 14.
>
> I posted the objectives here:
> https://gcc.gnu.org/pipermail/gcc-patches/2023-November/636060.html
Thank you for the pointer.
On 6/12/24 12:47 AM, Richard Biener wrote:
One of the points I wanted to make is that sched1 can make quite a
difference as to the relative distance of the store and load and
we have the instruction window the pass considers when scanning
(possibly driven by target uarch details). So doing
On 6/11/24 23:53, Andi Kleen wrote:
Sorry I must have misunderstood you. I thought the patch was already
approved earlier and I did commit. I can revert or do additional
changes.
I only meant to approve the refactoring patch, but no worries.
On Tue, Jun 11, 2024 at 04:31:30PM -0400, Jason Me
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/pipermail/gcc-testresults/2024-May/816422.html
https://sourceware.org/pipermail/gcc-testresults/2024-May/816346.h
Hi all,
On 12.06.24 15:19, René Rebe wrote:
On Jun 12, 2024, at 15:00, Richard Biener wrote:
On Wed, 12 Jun 2024, René Rebe wrote:
On Jun 12, 2024, at 13:01, Richard Biener wrote:
On Wed, 12 Jun 2024, Rene Rebe wrote:
not sure how you exactly did this though? I've never tried
testing of a
No semantics changes.
gcc/cp/ChangeLog:
* cp-tree.h (extract): Add new overload to return tree.
* parser.cc (cp_parser_asm_string_expression): Use tree extract.
* semantics.cc (cexpr_str::extract): Add new overload to return
tree.
---
gcc/cp/cp-tree.h| 1 +
Hello Richard:
On 12/06/24 3:02 am, Richard Sandiford wrote:
> Ajit Agarwal writes:
>> Hello Richard:
>>
>> On 11/06/24 9:41 pm, Richard Sandiford wrote:
>>> Ajit Agarwal writes:
>> Thanks a lot. Can I know what should we be doing with neg (fma)
>> correctness failures with load fusion.
No functional change intended.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Successful run of analyzer integration tests on x86_64-pc-linux-gnu.
Pushed to trunk as r15-1209-gc5e3be456888aa.
gcc/analyzer/ChangeLog:
* access-diagram.cc (access_range::dump): Update for fiel
No functional change intended.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Successful run of analyzer integration tests on x86_64-pc-linux-gnu.
Pushed to trunk as r15-1210-g1cae1a5ce088c1.
gcc/cp/ChangeLog:
* error.cc (append_formatted_chunk): Move part of body into
On 12/06/2024 09:53, Andre Vieira (lists) wrote:
>
>
> On 06/06/2024 12:53, Richard Earnshaw (lists) wrote:
>> On 05/06/2024 17:07, Andre Vieira (lists) wrote:
>>> Hi,
>>>
>>> This patch adds missing assembly directives to the CMSE library wrapper to
>>> call functions with attribute cmse_nonsec
On Jun 12, 2024, at 15:00, Richard Biener wrote:
>
> On Wed, 12 Jun 2024, René Rebe wrote:
>
>> Hi,
>>
>>> On Jun 12, 2024, at 13:01, Richard Biener wrote:
>>>
>>> On Wed, 12 Jun 2024, Rene Rebe wrote:
gcc/
* config/ia64/ia64.cc: Enable LRA for ia64.
* config
Hello Richard:
On 12/06/24 3:02 am, Richard Sandiford wrote:
> Ajit Agarwal writes:
>> Hello Richard:
>>
>> On 11/06/24 9:41 pm, Richard Sandiford wrote:
>>> Ajit Agarwal writes:
>> Thanks a lot. Can I know what should we be doing with neg (fma)
>> correctness failures with load fusion.
For one setting ld_ver in a conditional (no in-tree ld) when it's used,
for x86 at least, in unconditional ways can't be quite right. And then
prefixing relative paths to binaries with ${objdir}/, when ${objdir}
nowadays resolves to just .libs, can at best be a leftover that wasn't
properly cleaned
On Mon, Jun 10, 2024 at 9:27 PM Philipp Tomsich
wrote:
>
> On Mon, 10 Jun 2024 at 20:03, Jeff Law wrote:
> >
> >
> >
> > On 6/10/24 1:55 AM, Manolis Tsamis wrote:
> >
> > >>
> > > There was an older submission of a load-pair specific pass but this is
> > > a complete reimplementation and indeed s
On Wed, 12 Jun 2024, René Rebe wrote:
> Hi,
>
> > On Jun 12, 2024, at 13:01, Richard Biener wrote:
> >
> > On Wed, 12 Jun 2024, Rene Rebe wrote:
> >>
> >> gcc/
> >>* config/ia64/ia64.cc: Enable LRA for ia64.
> >>* config/ia64/ia64.md: Likewise.
> >>* config/ia64/predica
On Wed, Jun 12, 2024 at 6:39 AM Andrew Pinski wrote:
>
> As mentioned by Jeff in r15-831-g05daf617ea22e1d818295ed2d037456937e23530, we
> don't handle
> `(X | Y) & ~Y` -> `X & ~Y` on the gimple level when there are some different
> signed
> (but same precision) types dealing with matching `~Y` wi
Hi,
> On Jun 12, 2024, at 13:01, Richard Biener wrote:
>
> On Wed, 12 Jun 2024, Rene Rebe wrote:
>>
>> gcc/
>>* config/ia64/ia64.cc: Enable LRA for ia64.
>>* config/ia64/ia64.md: Likewise.
>>* config/ia64/predicates.md: Likewise.
>
> That looks simple enough. I cannot
On Tue, Jun 11, 2024 at 11:46 AM Victor Do Nascimento
wrote:
>
> At present the autovectorizer fails to vectorize simple loops
> involving calls to `__builtin_prefetch'. A simple example of such
> loop is given below:
>
> void foo(double * restrict a, double * restrict b, int n){
> int i;
> f
Andrew Stubbs wrote:
Compared to the previous v4 (1/5) posting of this patch:
- The enumeration of the ompx allocators have been moved (again) to 200
(as 100 is already in use by another toolchain vendor and this seems
like a possible source of confusion).
- The "ompx" has also been changed
Andrew Stubbs wrote:
The feature doesn't work on non-Linux hosts, at present, so skip the tests
entirely.
On Linux systems that have insufficient lockable memory configured we still
need to fail or else the feature won't be getting tested when we think it is,
but now there's a message to explain
On Thu, 5 May 2022, Alexandre Oliva via Gcc-patches wrote:
> [PR100106] Reject unaligned subregs when strict alignment is required
>
> From: Alexandre Oliva
>
> The testcase for pr100106, compiled with optimization for 32-bit
> powerpc -mcpu=604 with -mstrict-align expands the initialization of
From: Pan Li
After we support the scalar unsigned form 1 and 2, we would like
to introduce more forms include the branch and branchless. There
are forms 3-10 list as below:
Form 3:
#define SAT_SUB_U_3(T) \
T sat_sub_u_3_##T (T x, T y) \
{ \
return x > y ? x - y : 0; \
}
Form 4:
The introduction of the optional RCPC3 architectural extension for
Armv8.2-A upwards provides additional support for the release
consistency model, introducing the Load-Acquire RCpc Pair Ordered, and
Store-Release Pair Ordered operations in the form of LDIAPP and STILP.
These operations are single
1 - 100 of 149 matches
Mail list logo
