On Nov 20, 2023, David Malcolm wrote:
> On Sun, 2023-11-19 at 04:39 -0300, Alexandre Oliva wrote:
>>
>> On platforms that enable -fshort-enums by default, various switch-
>> enum
>> analyzer tests fail, because apply_constraints_for_gswitch doesn't
>> expect the integral promotion type cast.
On 21.11.2023 23:20, David Malcolm wrote:
> @@ -101,6 +109,29 @@ had_warnings (void)
>return warning_count;
> }
>
> +#if USE_LIBDIAGNOSTICS
> +static diagnostic_manager *diag_mgr;
> +#endif
> +
> +void messages_init (void)
> +{
> +#if USE_LIBDIAGNOSTICS
> + diag_mgr =
On Wed, Nov 22, 2023 at 11:31 AM Hongyu Wang wrote:
>
> Hi,
>
> The push2/pop2 operand order does not match the binutils implementation
> for AT syntax that it will first push operands[2] then operands[1].
> Correct it by reverse operand order for AT syntax.
>
> Bootstrapped/regtested on
在 2023/11/19 下午3:01, Xi Ruoyao 写道:
The vec_perm expander was wrongly defined. GCC internal says:
Operand 3 is the “selector”. It is an integral mode vector of the same
width and number of elements as mode M.
With this mistake, the generic code manages to work around and it ends
up creating
LGTM.
Regards
Robin
This patch fixes following FAILs on zvl512b:
FAIL: gcc.target/riscv/rvv/autovec/partial/slp_run-1.c execution test
FAIL: gcc.target/riscv/rvv/autovec/partial/slp_run-1.c execution test
FAIL: gcc.target/riscv/rvv/autovec/partial/slp_run-16.c execution test
FAIL:
LGTM。
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-11-22 14:03
To: juzhe.zh...@rivai.ai; gcc-patches; palmer; kito.cheng; jeffreyalaw
CC: rdapp.gcc
Subject: Re: [PATCH] RISC-V: testsuite: Remove redundant vector_hw and zvfh_hw.
> I don't get it. Why do we need remove them ?
It's just
> I don't get it. Why do we need remove them ?
It's just replaced by riscv_zvfh. I should probably edit the
patch description and changelog entries to make it clearer.
Regards
Robin
Hi Ruoyao,
Thanks for the tips, I'll keep it in mind
I've seen the contribution style guide, but it can be pretty difficult
to format gcc's source in a patch, at least for me :(
Noted, I'll add more descriptions to prove it's use case, thanks
best regards,
Julian
On Wed, Nov 22, 2023 at 4:28
From: "Zhang, Annita"
Avoid_fma_chain was enabled in m_SAPPHIRERAPIDS, m_ALDERLAKE and
m_CORE_HYBRID. It can also be enabled in m_GENERIC to improve the
performance of -march=x86-64-v3/v4 with -mtune=generic set by
default. One SPEC2017 benchmark 510.parest_r can improve greatly due
to it. From
On 11/21/23 17:51, Jakub Jelinek wrote:
On Tue, Nov 21, 2023 at 11:19:56PM +0100, Jakub Jelinek wrote:
+ error_at (location, "% message must be a string "
+ "literal or object with % and "
+ "% members");
Let's print the type of
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
In review of the deducing 'this' patch, it came up that the logic in
start_preparsed_function around the ctype variable was convoluted, being
set for non-static member functions and friends, but not for static member
functions. Let's set
Hi,
The push2/pop2 operand order does not match the binutils implementation
for AT syntax that it will first push operands[2] then operands[1].
Correct it by reverse operand order for AT syntax.
Bootstrapped/regtested on x86-64-linux-pc-gnu{-m32,}
Ok for master?
gcc/ChangeLog:
*
On 11/21/23 08:04, waffl3x wrote:
Bootstrapped and tested on x86_64-linux with no regressions.
Hopefully this patch is legible enough for reviewing purposes, I've not
been feeling the greatest so it was a task to get this finished.
Tomorrow I will look at putting the diagnostics in
This fixes the testcase.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/movk.c: Add noipa on dummy_number_generator
and remove -fno-inline option.
Signed-off-by: Andrew Pinski
---
gcc/testsuite/gcc.target/aarch64/movk.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
This fixes the testcase.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/movk.c: Add noipa on dummy_number_generator
and remove -fno-inline option.
Signed-off-by: Andrew Pinski
---
gcc/testsuite/gcc.target/aarch64/movk.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
Hi Richard S,
Thanks a lot for reviewing and comments. May I know is there any concern or
further comments for landing this patch to GCC-14?
Pan
-Original Message-
From: Li, Pan2
Sent: Wednesday, November 15, 2023 8:25 AM
To: gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; Wang,
On Mon, 13 Nov 2023, Jeff Law wrote:
> > > The testcase is generic enough I thought it wouldn't hurt to place it in
> > > a generic part of the testsuite, where it has been verified to pass with
> > > the `powerpc64le-linux-gnu', `riscv64-linux-gnu', and `vax-netbsdelf'
> > > targets. I'm fine
On Sun, 19 Nov 2023, Jeff Law wrote:
> > Verified with the `riscv64-linux-gnu' target and the C language
> > testsuite. OK to apply?
> Not sure why it is the way it is -- I walked back to Zdenek's change which
> introduced the scan-assembler-times and nothing about the -inline argument.
I
I added that xfail in February for { ilp32 && c++98_only } and it
looks like it's moved on to lp64 now. :-/ Noted by Rainer
Orth, see the PR.
Tested cris-elf and x86_64-pc-linux-gnu w/wo. -m32.
Ok to commit?
-- >8 --
The conditions under which this this bogus warning is
emitted has changed to
Use non-capturing parentheses for the subexpressions used with
`scan-assembler-times', to avoid a quirk with double-counting.
gcc/testsuite/
* gcc.target/arm/pr53447-5.c: Use non-capturing parentheses with
`scan-assembler-times'.
---
Hi,
The `scan-assembler-times'
On Sun, 19 Nov 2023, Jeff Law wrote:
> > gcc/
> > * config/riscv/riscv-protos.h (riscv_expand_float_scc): Add
> > `invert_ptr' parameter.
> > * config/riscv/riscv.cc (riscv_emit_float_compare): Add NE
> > inversion handling.
> > (riscv_expand_float_scc): Pass `invert_ptr'
On Mon, 20 Nov 2023, Richard Biener wrote:
> > > ok
> >
> > Thank you for your review, but I think I need a general maintainer's ack
> > for this one.
>
> OK.
I have committed this change now, thank you for your review.
Maciej
On Sun, 19 Nov 2023, Jeff Law wrote:
> > Verified with the `riscv64-linux-gnu' target and the C language
> > testsuite. OK to apply?
> OK
Applied now, thank you for your review.
Maciej
On 11/21/23 18:07, Costas Argyris wrote:
This patch makes the inclusion of the utf8 manifest on the
mingw hosts optional by introducing the configure option
--disable-win32-utf8-manifest (has no effect on non-mingw
hosts).
Bootstrapped OK on i686-w64-mingw32 and x86_64-w64-mingw32
with and
在 2023/11/22 03:35, Björn Schäpers 写道:
I'll guess it is not needed here, but otherwise defines the macros max and min, they
then conflict e.g. with C++'s std::max/std::min. So I consider it best practice to always define it,
before including .
The mingw-w64 header does not define them for
I don't get it. Why do we need remove them ?
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-11-22 03:43
To: gcc-patches; palmer; Kito Cheng; jeffreyalaw; juzhe.zh...@rivai.ai
CC: rdapp.gcc
Subject: [PATCH] RISC-V: testsuite: Remove redundant vector_hw and zvfh_hw.
Hi,
this removes the
On Tue, 21 Nov 2023, Florian Weimer wrote:
> This program is compiled with an installed "cc" compiler, not the
> built GCC compiler, so it should be as compatible as possible across a
> wide range of compilers.
>
> gcc/testsuite/
>
> * gcc.misc-tests/linkage-y.c (puts): Declare.
>
On Tue, 21 Nov 2023, Tobias Burnus wrote:
> On 21.11.23 14:57, David Malcolm wrote:
> > On Tue, 2023-11-21 at 02:09 +0100, Hans-Peter Nilsson wrote:
> > > Sorry for barging in though I did try finding the relevant
> > > discussion, but is committing this generated stuff necessary?
> > > Is it
On Mon, 20 Nov 2023, Jakub Jelinek wrote:
> > Note that stdc_bit_ceil now has defined behavior (return 0) on overflow:
> > CD2 comment FR-135 was accepted for the DIS at the June WG14 meeting.
> > This affects both the documentation and the implementation, as they need
> > to avoid an
The vectorizer picks up these loops and disables unrolling on targets
with variable vector factors. That result in better code here, but it
trips up the unrolling tests. So just disable vectorization for these.
gcc/testsuite/ChangeLog:
PR target/112531
* gcc.dg/unroll-8.c:
I was poking around with this test failure and noticed it was exercising
undefined behavior. The return type doesn't matter for what's being
tested, so just mark it as void.
gcc/testsuite/ChangeLog:
* gcc.dg/unroll-8.c: Remove UB.
---
I didn't tes this, but it seems trivial enough that
Hi Simon,
Thanks for persevering - I will keep the original patch, pending some chance to
fix the earlier OS issues.
I’ll check this on OS versions with older SDKs that do not have the TARGET_OS_XX
conditionals.
-
One small nit below,
Iain
> On 21 Nov 2023, at 20:25, Simon Wright wrote:
On Tue, Nov 21, 2023 at 2:43 PM Andrew Pinski wrote:
>
> On Wed, Nov 15, 2023 at 6:42 AM Tamar Christina
> wrote:
> >
> > Hi All,
> >
> > This changes unpack instructions to use zip{1,2} when doing a zero-extending
> > widening operation. Permutes generally have a higher throughput than the
>
On Tue, Nov 21, 2023 at 11:19:56PM +0100, Jakub Jelinek wrote:
> > > + error_at (location, "% message must be a string "
> > > + "literal or object with % and "
> > > + "% members");
> >
> > Let's print the type of the message as well.
>
> so add "
On Wed, Nov 15, 2023 at 6:42 AM Tamar Christina wrote:
>
> Hi All,
>
> This changes unpack instructions to use zip{1,2} when doing a zero-extending
> widening operation. Permutes generally have a higher throughput than the
> widening operations. Zeros are shuffled into the top half of the
Thank you for your efforts.
Having the wiki page to track this definitely is useful!
I'll have a look at the "real patch" later, likely next week.
But for patch 4+5 which look quite clean: can we get an early
improvement and inclusion into GCC for those?
They only adjust internals and should
Changed in v2:
* Changed diagnostic_location_t -> const diagnostic_physical_location *
* new entrypoint: diagnostic_finish_va
* new debugging entrypoints for dumping to a FILE *
* Makefile.in: dropped FULL_DRIVER_NAME from libdiagnostics
* fix up for my recent changes to gcc/diagnostic.h
Blurb
Changed in v2:
* updated for change from diagnostic_location_t to
const diagnostic_physical_location *
* fix #if USE_DIAGNOSTICS to retain context and listing code
Output from the example below with v2 is now:
testsuite/gas/all/warn-1.s:3: warning: a warning message
3 | .warning "a
No functional change intended.
gcc/ChangeLog:
* diagnostic.cc (diagnostic_get_location_text): Convert to...
(diagnostic_context::get_location_text): ...this, and convert
return type from char * to label_text.
(diagnostic_build_prefix): Update for above change.
Changed in v2:
* Changed from diagnostic_location_t -> const diagnostic_physical_location *
* Add entrypoint: diagnostic_finish_va
* add new type diagnostic_text_sink, and new entrypoints for
enabling/disabling options on it
* add new debugging entrypoints for dumping objects to a FILE *
* new
This is new in v2: a C++ wrapper API that provides some syntactic sugar for
calling into libdiagnostics.{h,so}.
I've been "eating my own dogfood" with this by using it to write a simple
client that reads a SARIF file and dumps it using the text sink:
gcc/ChangeLog:
* diagnostic-show-locus.cc (layout::maybe_add_location_range):
Don't print annotation lines for ranges when there's no column
info.
(selftest::test_one_liner_no_column): New.
(selftest::test_diagnostic_show_locus_one_liner): Call it.
---
Here's v2 of the "libdiagnostics" shared library idea; see:
https://gcc.gnu.org/wiki/libdiagnostics
As in v1, patch 1 (for GCC) shows libdiagnostic.h (the public
header file), along with examples of simple self-contained programs that
show various uses of the API.
As in v1, patch 2 (for GCC)
On Tue, Nov 21, 2023 at 04:44:01PM -0500, Jason Merrill wrote:
> > Or do you want to just use
> > error_at (location, "% message must be a "
> > "unevaluated string literal or object with "
> > "% and % members");
> > wording (even when it
Uhh, it happened again. Attached a wrong patch.
Only looked at the -v3 ... My bad.
Sorry!
Harald
On 11/21/23 22:54, Harald Anlauf wrote:
Hi Mikael, Steve,
On 11/21/23 12:33, Mikael Morin wrote:
Harald, you mentioned the lack of GFC_STD_F2023_DEL feature group in
your first message, but I
Hi Mikael, Steve,
On 11/21/23 12:33, Mikael Morin wrote:
Harald, you mentioned the lack of GFC_STD_F2023_DEL feature group in
your first message, but I don't quite understand why you didn't add one.
It seems to me the most natural way to do this.
thanks for insisting on this variant.
In my
On 11/21/23 12:17, Jakub Jelinek wrote:
On Thu, Oct 26, 2023 at 09:21:47PM -0400, Jason Merrill wrote:
On 9/18/23 13:21, Jakub Jelinek wrote:
Here is an updated version of the patch.
Compared to the last version, based on the discussion in the PR, the patch
1) warns (but only that) if
> From:
> Date: Tue, 24 Oct 2023 17:11:24 +0300
> From: Daniil Frolov
>
> PR 66487 is asking to provide sanitizer-like detection for C++ object lifetime
> violations that are worked around with -fno-lifetime-dse in Firefox, LLVM,
> OpenJade.
>
> The discussion in the PR was centered around
Hi Honza!
On 2023-11-21T15:06:54+0100, Jan Hubicka wrote:
>> After this patch in addition to the problem already reported about
>> vlda1.c and return-value-range-1.c, [...]
> return-value_range-1.c should be fixed now and I do not have vlda1.c in
> my tree. I will check.
Typo, I suppose;
Hi!
On 2023-11-19T16:05:42+0100, Jan Hubicka wrote:
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/tree-ssa/return-value-range-1.c
Pushed to master branch commit a0240662b22312ffb3e3fefb85f258ab0e7010f4
"Fix 'gcc.dg/tree-ssa/return-value-range-1.c' for 'char' defaulting to
'unsigned'", see
On 11/15/23 00:13, Sam James wrote:
Florian Weimer writes:
* Sam James:
Florian Weimer writes:
Most -Wimplicit-int warnings were unconditionally disabled for system
headers. Only missing types for parameters in old-style function
definitions resulted in warnings. This is inconsistent
On Tue, Nov 21, 2023 at 8:51 AM Arsen Arsenović wrote:
>
>
> Arsen Arsenović writes:
>
> > Bruno Haible writes:
> >
> >> Arsen Arsenović wrote:
> >>> Comparing stages 2 and 3
> >>> Bootstrap comparison failure!
> >>> gettext/libasprintf/autosprintf.o differs
> >>> make[2]: ***
On 11/19/23 02:21, Sandra Loosemore wrote:
This patch introduces enumerators to represent trait-set names and
trait names, which makes it easier to use tables to control other
behavior and for switch statements to dispatch on the tags. The tags
are stored in the same place in the TREE_LIST
On Mon, 2023-11-20 at 16:35 +0800, Julian Waters wrote:
> Hi all, I'd like to ping the following patch
>
> https://gcc.gnu.org/pipermail/gcc-patches/2023-November/636924.html
You posted the patch Friday and then pinged it in Monday. There is
literally zero working days for people to review the
On 21 Nov 2023, at 11:22, Iain Sandoe wrote:
>
> Hello Simon, Arno,
>
>> On 17 Nov 2023, at 13:43, Simon Wright wrote:
>>
>>>
Apple’s naming is definitely confusing in this area!
In current SDKs, TARGET_OS_MAC means code is being generated for a Mac OS
X variant,
Hi!
Solaris as apparently doesn't accept %function and requires @function
instead.
This cherry-picks upstream commit.
Bootstrapped/regtested on x86_64-linux and i686-linux and built tested
on sparc-solaris2.11, committed to trunk as obvious.
2023-11-21 Jakub Jelinek
PR
>> Bootstrapped and regtested on aarch64 and regtested on riscv. x86 is
>> still running.
Just to confirm: x86 bootstrap and regtest unchanged. Going to commit
it soon.
Regards
Robin
Hi,
this removes the now-redundant vector_hw and zvfh_hw checks in the
testsuite.
Regards
Robin
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/binop/copysign-zvfh-run.c:
Remove zvfh_hw.
* gcc.target/riscv/rvv/autovec/binop/vadd-zvfh-run.c: Ditto.
*
I'll guess it is not needed here, but otherwise defines the macros
max and min, they then conflict e.g. with C++'s std::max/std::min. So I consider
it best practice to always define it, before including .
Am 20.11.2023 um 21:07 schrieb Eli Zaretskii:
Date: Mon, 20 Nov 2023 20:57:38 +0100
Cc:
I have bootstrapped and checked for no testsuite regressions on x86 and aarch64.
Thanks,
Manolis
On Tue, Nov 21, 2023 at 8:00 PM Manolis Tsamis wrote:
>
> The existing implementation of need_cmov_or_rewire and
> noce_convert_multiple_sets_1 assumes that sets are either REG or SUBREG.
> This
I have made this independent from the rest of the series, cleaned up
some comments and moved some code to its original position.
Re-submitted as
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637660.html.
Manolis
On Mon, Nov 13, 2023 at 2:40 PM Manolis Tsamis wrote:
>
> Hi Jeff,
>
>
On Tue, 21 Nov 2023, Jonathan Wakely wrote:
CC Marc Glisse who added the relocation support. He might recall why
we use memmove when all uses are for newly-allocated storage, which
cannot overlap the existing storage.
Going back a bit:
Retested, made independent of the rest of the series and submitted as
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637662.html.
Manolis
On Mon, Nov 13, 2023 at 2:43 PM Manolis Tsamis wrote:
>
> Yes, my finding back then was that this is leftover code from the
> initial
Bootstrapped and tested on x86 and aarch64. This only assumes that the
mode of what simplify_replace_rtx returns is the same with its first
argument.
Thanks,
Manolis
On Tue, Nov 21, 2023 at 8:04 PM Manolis Tsamis wrote:
>
> This code used to handle SUBREG for register replacement when ifcvt was
This patch makes the inclusion of the utf8 manifest on the
mingw hosts optional by introducing the configure option
--disable-win32-utf8-manifest (has no effect on non-mingw
hosts).
Bootstrapped OK on i686-w64-mingw32 and x86_64-w64-mingw32
with and without --disable-win32-utf8-manifest.
Costas
This code used to handle SUBREG for register replacement when ifcvt was doing
the replacements manually. This special handling is not needed anymore
because simplify_replace_rtx is used for the replacements and it properly
handles these cases.
gcc/ChangeLog:
* ifcvt.cc
On 11/18/23 20:09, Jeff Law wrote:
On 11/15/23 17:03, Patrick O'Neill wrote:
Ping.
Testsuite fixup similar to:
https://inbox.sourceware.org/gcc-patches/974e9e5e-8f07-46dd-b9b9-db8aa4685...@gmail.com/T/#t
The existing implementation of need_cmov_or_rewire and
noce_convert_multiple_sets_1 assumes that sets are either REG or SUBREG.
This commit enchances them so they can handle/rewire arbitrary set statements.
To do that a new helper struct noce_multiple_sets_info is introduced which is
used by
On Tue, Nov 21, 2023 at 06:17:02PM +0100, Jakub Jelinek wrote:
> The
> static_assert (false, "foo"_myd);
> in the new testcase shows where it is valid (in C++26 and as extension in
> older standards). For C++26 we could use unevaluated string literal rather
> than string literal in the wording,
On Thu, Oct 26, 2023 at 09:21:47PM -0400, Jason Merrill wrote:
> On 9/18/23 13:21, Jakub Jelinek wrote:
> > Here is an updated version of the patch.
> > Compared to the last version, based on the discussion in the PR, the patch
> > 1) warns (but only that) if size()/data() methods aren't declared
On Tue, 21 Nov 2023 at 16:24, Jan Hubicka wrote:
>
> Hi,
> this patch turns memmove to memcpy where we can and also avoids extra
> guard checking if block is non-empty. This does not show as performance
> improvement in my push_back micro-benchmark because vector rellocation
> does not happen
Richard Sandiford writes:
> Alex Coplan writes:
>> This adds some helpers to access-utils.h for removing accesses from an
>> access_array. This is needed by the upcoming aarch64 load/store pair
>> fusion pass.
>>
>> Bootstrapped/regtested as a series on aarch64-linux-gnu, OK for trunk?
>>
>>
On Tue, Nov 21, 2023 at 8:51 AM Arsen Arsenović wrote:
>
> Arsen Arsenović writes:
>
> > Bruno Haible writes:
> >
> >> Arsen Arsenović wrote:
> >>> Comparing stages 2 and 3
> >>> Bootstrap comparison failure!
> >>> gettext/libasprintf/autosprintf.o differs
> >>> make[2]: ***
Hi,
this patch turns memmove to memcpy where we can and also avoids extra
guard checking if block is non-empty. This does not show as performance
improvement in my push_back micro-benchmark because vector rellocation
does not happen that often. In general, however, we optimize memcpy better
then
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This was recently approved for C++26.
We should define the __cpp_lib_freestanding_cstring macro in
as well as , but we do not currently install our own
for most targets.
libstdc++-v3/ChangeLog:
* include/bits/version.def
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This C++26 change makes several classes "partially freestanding", but we
already fully supported them in freestanding mode. All we need to do is
define the new feature test macros and add tests for them.
libstdc++-v3/ChangeLog:
*
Tested x86_64-linux. Pushed to trunk.
-- >8 --
Also define the new feature test macros from P2833R2, indicating that
std::span and std::expected are supported for freestanding mode.
libstdc++-v3/ChangeLog:
* include/bits/version.def (freestanding_expected): New macro.
(span):
Tested x86_64-linux. Pushed to trunk. Backports to follow.
-- >8 --
libstdc++-v3/ChangeLog:
* include/tr2/dynamic_bitset (dynamic_bitset): Pass zero and one
characters to _M_copy_from_string.
* testsuite/tr2/dynamic_bitset/string.cc: New test.
---
I'm going to hold off for 24 hours on this to give some chance for
feedback before committing. Is using EXTRA_PARTS in this way
acceptable? If not, what method would you recommend? Is there a
better way of achieving this than using --defsym (which seems to have
the side effect of causing the
Alex Coplan writes:
> This patch overhauls the load/store pair patterns with two main goals:
>
> 1. Fixing a correctness issue (the current patterns are not RA-friendly).
> 2. Allowing more flexibility in which operand modes are supported, and which
>combinations of modes are allowed in the
Rainer Orth writes:
> either this patch or the previous one broke D bootstrap with GCC 9. On
> both i386-pc-solaris2.11 with gdc 9.4.0 and sparc-sun-solaris2.11 with
> gdc 9.3.0, stage 1 d21 fails to link with
>
> Undefined first referenced
> symbol
Hi Iain,
> This patch merges the D front-end and runtime library with upstream dmd
> ff57fec515, and the standard library with phobos 17bafda79.
>
> Synchronizing with the upstream release candidate of v2.106.0.
>
> D front-end changes:
>
> - Import dmd v2.106.0-rc.1.
> - New'ing
On Mon, Nov 20, 2023 at 05:32:47PM +0100, Jakub Jelinek wrote:
> LGTM.
Thanks a lot. Since Richi seems to be fine with the patch as well,
I'll push it tomorrow AM if no comments.
Marek
On Tue, 2023-11-21 at 15:12 +0100, Tobias Burnus wrote:
> On 21.11.23 14:57, David Malcolm wrote:
> > On Tue, 2023-11-21 at 02:09 +0100, Hans-Peter Nilsson wrote:
> > > Sorry for barging in though I did try finding the relevant
> > > discussion, but is committing this generated stuff necessary?
>
Gentle Ping for the patch below:
On 11/9/23 16:14, Richard Ball wrote:
> ACLE has added intrinsics to bridge between SVE and Neon.
>
> The NEON_SVE Bridge adds intrinsics that allow conversions between NEON and
> SVE vectors.
>
> This patch adds support to GCC for the following 3 intrinsics:
>
Alex Coplan writes:
> Thus far the writeback forms of ldp/stp have been exclusively used in
> prologue and epilogue code for saving/restoring of registers to/from the
> stack.
>
> As such, forms of ldp/stp that weren't needed for prologue/epilogue code
> weren't supported by the aarch64 backend.
This program is compiled with an installed "cc" compiler, not the
built GCC compiler, so it should be as compatible as possible across a
wide range of compilers.
gcc/testsuite/
* gcc.misc-tests/linkage-y.c (puts): Declare.
(main): Add int return type and return 0.
---
On Tue, 21 Nov 2023, Robin Dapp wrote:
> Hi,
>
> in PR112406 Tamar found another problem with COND_OP reductions.
> I wrongly assumed that the reduction variable will always remain in
> operand 1, just as we create the COND_OP in ifcvt. But of course,
> addition being commutative, we are free
Hi,
in PR112406 Tamar found another problem with COND_OP reductions.
I wrongly assumed that the reduction variable will always remain in
operand 1, just as we create the COND_OP in ifcvt. But of course,
addition being commutative, we are free to swap operand 1 and 2 and
can end up with e.g.
On Tue, Nov 21, 2023 at 02:35:02PM +, Richard Biener wrote:
> For vec_pack_trunc patterns there can be an ambiguity for the
> source mode for BFmode vs HFmode. The vectorizer checks
> the insns operand mode for this, the following makes forwprop
> do the same. That of course doesn't help if
For vec_pack_trunc patterns there can be an ambiguity for the
source mode for BFmode vs HFmode. The vectorizer checks
the insns operand mode for this, the following makes forwprop
do the same. That of course doesn't help if the target supports
both conversions.
Bootstrapped and tested on
The following moves the check whether the maximum vectorization
factor determined by data dependence analysis is in conflict with
the chosen vectorization factor to after the point where we applied
both the SLP and the unrolling adjustment to the vectorization
factor. We check the latter before
Hi Thomas!
A newer version of the library has been force-pushed to the branch
`libgrust-v2/to-submit`.
On 11/20/23 15:55, Thomas Schwinge wrote:
Hi!
Arthur and Pierre-Emmanuel have prepared a GCC/Rust libgrust-v2/to-submit
branch:
On 11/20/23 20:09, Xi Ruoyao wrote:
On Tue, 2023-11-21 at 08:00 +0800, Xi Ruoyao wrote:
/* snip */
This has broken libgcc builds when target libc isn't yet available.
In file included from
/scratch/jmyers/glibc-bot/src/gcc/libgcc/../gcc/config/loongarch/loongarch-def.h:49,
On 21.11.23 14:57, David Malcolm wrote:
On Tue, 2023-11-21 at 02:09 +0100, Hans-Peter Nilsson wrote:
Sorry for barging in though I did try finding the relevant
discussion, but is committing this generated stuff necessary?
Is it because we don't want to depend on Python being
present at build
ok Replied Message FromRobin DappDate11/21/2023 21:35 Togcc-patches,palmer,Kito Cheng,jeffreyalaw,juzhe.zh...@rivai.ai Ccrdapp@gmail.comSubjectRe: [PATCH] RISC-V: testsuite: Fix popcount test.> Mhm, not so obvious after all. We vectorize 250 instances with
> rv32gcv, 229 with rv64gcv
> After this patch in addition to the problem already reported about
> vlda1.c and return-value-range-1.c, we have noticed these regressions
> on aarch64:
> Running gcc:gcc.target/aarch64/aarch64.exp ...
> FAIL: gcc.target/aarch64/movk.c scan-assembler movk\tx[0-9]+, 0x4667, lsl 16
> FAIL:
On Tue, 21 Nov 2023 at 09:48, Jakub Jelinek wrote:
>
> Hi!
>
> ARM defaults to -fshort-enums and the following testcase FAILs there in 2
> lines. The difference is that in C++, E0 has enum E type, which normally
> has unsigned int underlying type, so it isn't int nor something that
> promotes to
Hi!
On Sun, 19 Nov 2023 at 16:05, Jan Hubicka wrote:
>
> Hi,
> this is updated version which also adds testuiste compensation
> I lost earlier while maintaining the patch in my testing tree.
> There are quite few testcases that use constant return values to hide
> something from optimizer.
>
>
1 - 100 of 188 matches
Mail list logo
