On Thu, 7 Mar 2024, Richard Sandiford wrote:
> Sorry, still catching up on email, but:
>
> Richard Biener writes:
> > We have optimize_vectors_before_lowering_p but we shouldn't even there
> > turn supported into not supported ops and as said, what's supported or
> > not cannot be finally decid
On Thu, Mar 7, 2024 at 8:29 PM Ken Matsui wrote:
>
> On Tue, Mar 5, 2024 at 7:58 AM Richard Biener
> wrote:
> >
> > On Tue, Mar 5, 2024 at 1:51 PM Ken Matsui wrote:
> > >
> > > On Tue, Mar 5, 2024 at 12:38 AM Richard Biener
> > > wrote:
> > > >
> > > > On Mon, Mar 4, 2024 at 9:40 PM Ken Matsui
Hi,
As known there are a few PRs (meta-bug PR101926) about
accessing aggregate param/returns which are passed through registers.
We could use the current SRA pass in a special mode right before
RTL expansion for the incoming/outgoing part, as the suggestion from:
https://gcc.gnu.org/pipermail/gcc
On Thu, 2024-03-07 at 21:07 +0800, chenglulu wrote:
>
> 在 2024/3/7 下午8:52, Xi Ruoyao 写道:
> > It should be better to extend the expected value before the ll/sc loop
> > (like what LLVM does), instead of repeating the extending in each
> > iteration. Something like:
>
> I wanted to do this at firs
On Mon, Nov 27, 2023 at 03:59:39PM +1100, Nathaniel Shead wrote:
> On Thu, Nov 23, 2023 at 03:03:37PM -0500, Nathan Sidwell wrote:
> > On 11/20/23 04:47, Nathaniel Shead wrote:
> > > Bootstrapped and regtested on x86_64-pc-linux-gnu. I don't have write
> > > access.
> > >
> > > -- >8 --
> > >
> >
Thanks a lot for coaching, really save my day. I will have a try for
usadd/ssadd includes both the scalar and vector (ISEL/widen_mult) modes in v3.
Pan
-Original Message-
From: Richard Biener
Sent: Thursday, March 7, 2024 4:41 PM
To: Li, Pan2
Cc: Tamar Christina ; gcc-patches@gcc.gnu.
Tested x86_64-linux. Pushed to trunk.
-- >8 --
With std::from_chars we can parse subsecond durations much faster than
with std::num_get, as shown in the microbenchmarks below. We were using
std::num_get and std::numpunct in order to parse a number with the
locale's decimal point character. But we
From: Pan Li
This patch would like to fix one ICE in vectorizable_store for both the
loop_masks and loop_lens. The ICE looks like below with "-march=rv64gcv -O3".
during GIMPLE pass: vect
test.c: In function ‘d’:
test.c:6:6: internal compiler error: in vectorizable_store, at
tree-vect-stmts.cc:
Tested x86_64-linux. Pushed to trunk.
-- >8 --
When converting a chrono::duration to a result type with an
integer representation we should use chrono::round<_Duration> so that we
don't truncate towards zero. Rounding ensures that e.g. 0.001999s
becomes 2ms not 1ms.
We can also remove some redun
On 1/29/24 17:42, Patrick Palka wrote:
On Mon, 29 Jan 2024, Patrick Palka wrote:
On Fri, 26 Jan 2024, Jason Merrill wrote:
On 1/26/24 17:11, Jason Merrill wrote:
On 1/26/24 16:52, Jason Merrill wrote:
On 1/25/24 14:18, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu,
On Thu, Mar 7, 2024 at 11:29 PM Segher Boessenkool
wrote:
>
> On Thu, Mar 07, 2024 at 11:07:18PM +0100, Uros Bizjak wrote:
> > On Thu, Mar 7, 2024 at 10:37 PM Segher Boessenkool
> > wrote:
> > > > but can be something else, such as the above noted
> > > >
> > > > (unspec:DI [
> > > > (r
On Thu, Mar 07, 2024 at 11:07:18PM +0100, Uros Bizjak wrote:
> On Thu, Mar 7, 2024 at 10:37 PM Segher Boessenkool
> wrote:
> > > but can be something else, such as the above noted
> > >
> > > (unspec:DI [
> > > (reg:CC 17 flags)
> > > ] UNSPEC_PUSHFL)
> >
> > But that is invalid RTL
On Thu, Mar 7, 2024 at 11:07 PM Uros Bizjak wrote:
>
> On Thu, Mar 7, 2024 at 10:37 PM Segher Boessenkool
> wrote:
> >
> > On Thu, Mar 07, 2024 at 10:04:32PM +0100, Uros Bizjak wrote:
> >
> > [snip]
> >
> > > The part we want to fix deals with the *user* of the CC register. It
> > > is not true t
On Thu, Mar 7, 2024 at 10:37 PM Segher Boessenkool
wrote:
>
> On Thu, Mar 07, 2024 at 10:04:32PM +0100, Uros Bizjak wrote:
>
> [snip]
>
> > The part we want to fix deals with the *user* of the CC register. It
> > is not true that this is always COMPARISON_P, so EQ, NE, GE, LT, ...
> > in the form
On Fri, Mar 08, 2024 at 03:01:04AM +0530, Ajit Agarwal wrote:
>
> >> + Copyright (C) 2020-2023 Free Software Foundation, Inc.
> >
> > What in here is from 2020?
> >
> > Most things will be from 2024, too. First publication date is what
> > counts.
>
> Please let me know the second publicati
On Thu, Mar 07, 2024 at 10:04:32PM +0100, Uros Bizjak wrote:
[snip]
> The part we want to fix deals with the *user* of the CC register. It
> is not true that this is always COMPARISON_P, so EQ, NE, GE, LT, ...
> in the form of
>
> (LT:CCGC (reg:CCGC 17 flags) (const_int 0))
>
> but can be somet
On Wed, Feb 28, 2024 at 11:32 AM Ken Matsui wrote:
>
> Hi,
>
> This patch series implements __is_const, __is_volatile, __is_pointer,
> and __is_unbounded_array built-in traits, which were isolated from my
> previous patch series "Optimize type traits compilation performance"
> because they contain
Hello Segher:
On 01/03/24 3:02 am, Segher Boessenkool wrote:
> Hi!
>
> On Mon, Feb 19, 2024 at 04:24:37PM +0530, Ajit Agarwal wrote:
>> --- a/gcc/config.gcc
>> +++ b/gcc/config.gcc
>> @@ -518,7 +518,7 @@ or1k*-*-*)
>> ;;
>> powerpc*-*-*)
>> cpu_type=rs6000
>> -extra_objs="rs6000-st
On Thu, Mar 7, 2024 at 10:04 PM Uros Bizjak wrote:
> The source code that deals with the *user* of the CC register assumes
> the former form, so it blindly tries to update the mode of the CC
> register inside LT comparison RTX (some other nearby source code even
> checks for (const_int 0) RTX). O
On Mon, 29 Jan 2024, Patrick Palka wrote:
> On Mon, 29 Jan 2024, Patrick Palka wrote:
>
> > On Fri, 26 Jan 2024, Jason Merrill wrote:
> >
> > > On 1/26/24 17:11, Jason Merrill wrote:
> > > > On 1/26/24 16:52, Jason Merrill wrote:
> > > > > On 1/25/24 14:18, Patrick Palka wrote:
> > > > > > Boots
On Thu, Mar 7, 2024 at 6:39 PM Segher Boessenkool
wrote:
>
> On Thu, Mar 07, 2024 at 10:55:12AM +0100, Richard Biener wrote:
> > On Thu, 7 Mar 2024, Uros Bizjak wrote:
> > > This is
> > >
> > > 3236 /* Just replace the CC reg with a new mode. */
> > > 3237 SUBST (XEXP (*
Sorry, still catching up on email, but:
Richard Biener writes:
> We have optimize_vectors_before_lowering_p but we shouldn't even there
> turn supported into not supported ops and as said, what's supported or
> not cannot be finally decided (if it's only vcond and not vcond_mask
> that is suppor
Tested x86_64-linux. Pushed to trunk.
-- >8 --
The whole point of these typedefs is to guarantee lock-freedom, so if
the target has no such types, we shouldn't defined the typedefs at all.
libstdc++-v3/ChangeLog:
PR libstdc++/114103
* include/bits/version.def (atomic_lock_free_t
Pushed to trunk.
On Fri, 1 Mar 2024 at 15:09, Jonathan Wakely wrote:
> Does the text of these new diagnostics look good?
>
> There are of course other ways for a type to be not-formattable (e.g.
> the formatter::format member doesn't return the right type or has some
> other kind of incorrect si
On Thu, 7 Mar 2024, Jason Merrill wrote:
> On 3/7/24 14:41, Patrick Palka wrote:
> > On Thu, 7 Mar 2024, Patrick Palka wrote:
> >
> > > On Wed, 6 Mar 2024, Jason Merrill wrote:
> > >
> > > > On 3/4/24 17:26, Patrick Palka wrote:
> > > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does t
Tested x86_64-linux. Pushed to trunk.
-- >8 --
The list in tzdb.cc isn't the only hardcoded list of leap seconds in the
library, there's the one defined inline in (to avoid loading
the tzdb for the common case) and another in a testcase. This updates
them to note that there are no new leap secon
Tested x86_64-linux. Pushed to trunk.
-- >8 --
I don't see why we should rely on __builtin_memset etc. in tests. We can
just include and use the public API.
libstdc++-v3/ChangeLog:
* testsuite/23_containers/deque/allocator/default_init.cc: Use
std::memset instead of __builtin_m
Wilco Dijkstra writes:
> Fix libatomic build to support --disable-gnu-indirect-function on AArch64.
> Always build atomic_16.S and add aliases to the __atomic_* functions if
> !HAVE_IFUNC.
This description is too brief for me. Could you say in detail how the
new scheme works? E.g. the descripti
Monday, March 4, 2024
Evgeny Karpov wrote:
>
> Changes from v1 to v2:
> Adjust the target name to aarch64-*-mingw* to exclude the big-endian target
> from support.
> Exclude 64-bit ISA.
> Rename enum calling_abi to aarch64_calling_abi.
> Move AArch64 MS ABI definitions FIXED_REGISTERS,
> CALL_REAL
The undefined symbols are allowed for C checks, but when
this is run as C++, the mangled foo() symbol is still
seen as undefined, and the testsuite thinks darwin does not
support -shared.
Pushed after approval by Iain Sandoe in PR114233
FX
0001-testsuite-darwin-improve-check-for-shared-suppor
On 3/7/24 14:41, Patrick Palka wrote:
On Thu, 7 Mar 2024, Patrick Palka wrote:
On Wed, 6 Mar 2024, Jason Merrill wrote:
On 3/4/24 17:26, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
-- >8 --
Alias templates are weird in that their spe
On 3/6/24 21:12, Patrick Palka wrote:
On Wed, 6 Mar 2024, Jason Merrill wrote:
On 3/6/24 14:10, Patrick Palka wrote:
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
-- >8 --
The unreduced testcase from this PR crashes at runtime ultimately
because we don't stream the abi_tag attr
On 3/7/24 07:49, Nathaniel Shead wrote:
On Wed, Mar 06, 2024 at 08:59:16AM -0500, Jason Merrill wrote:
On 3/5/24 22:06, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
Currently, reading a variable definition always marks that decl as
DECL_NOT_
On Thu, 7 Mar 2024, Patrick Palka wrote:
> On Wed, 6 Mar 2024, Jason Merrill wrote:
>
> > On 3/4/24 17:26, Patrick Palka wrote:
> > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> > > OK for trunk?
> > >
> > > -- >8 --
> > >
> > > Alias templates are weird in that their sp
On Tue, Mar 5, 2024 at 7:58 AM Richard Biener
wrote:
>
> On Tue, Mar 5, 2024 at 1:51 PM Ken Matsui wrote:
> >
> > On Tue, Mar 5, 2024 at 12:38 AM Richard Biener
> > wrote:
> > >
> > > On Mon, Mar 4, 2024 at 9:40 PM Ken Matsui wrote:
> > > >
> > > > (x - y) CMP 0 is equivalent to x CMP y where x
"Andre Vieira (lists)" writes:
> Hey,
>
> Dropped the first patch and dealt with the comments above, hopefully I
> didn't miss any this time.
>
> --
>
> This patch adds support for C23's _BitInt for the AArch64 port when
> compiling
> for little endianness. Big E
The test was trying to do too much by both checking for an error, and
checking the resulting assembly. Of course, due to the error no asm was
produced, so the scan-asm went unresolved. Split it into two separate
tests to fix the issue.
Tested on x86_64-linux-gnu host for bpf-unknown-none target.
BPF cannot fall back on library calls to implement memmove, memcpy and
memset, so we attempt to expand these inline always if possible.
However, this inline expansion was being attempted even for excessively
large operations, which could result in gcc consuming huge amounts of
memory and hanging.
On Thu, Mar 07, 2024 at 12:22:04PM +0100, Uros Bizjak wrote:
> As I understood find_single_use, it is returning RTX iff DEST is used
> only a single time in an insn sequence following INSN.
Connected by a log_link even, yeah.
> We can reject the combination without worries of multiple uses.
Yup.
On Thu, Mar 07, 2024 at 11:45:45AM +0100, Richard Biener wrote:
> The question is, whether a NULL cc_use_loc (find_single_use returning
> NULL) means "there is no use" or it can mean "huh, don't know, maybe
> more than one, maybe I was too stupid to indentify the single use".
> The implementation
On Thu, Mar 07, 2024 at 11:22:12AM +0100, Richard Biener wrote:
> > > > Undo the combination if *cc_use_loc is not COMPARISON_P.
Why, anyway? COMPARISON_P means things like LE. It does not even
include actual RTX COMPARE.
Segher
On Thu, Mar 07, 2024 at 10:55:12AM +0100, Richard Biener wrote:
> On Thu, 7 Mar 2024, Uros Bizjak wrote:
> > This is
> >
> > 3236 /* Just replace the CC reg with a new mode. */
> > 3237 SUBST (XEXP (*cc_use_loc, 0), newpat_dest);
> > 3238 undobuf.other_insn
Wilco Dijkstra writes:
> Hi Richard,
>
>> It looks like this is really doing two things at once: disabling the
>> direct emission of LDP/STP Qs, and switching the GPR handling from using
>> pairs of DImode moves to single TImode moves. At least, that seems to be
>> the effect of...
>
> No it stil
Andrew Pinski writes:
> This fixes the cost model for BFI instructions which don't
> use directly zero_extract on the LHS.
> aarch64_bfi_rtx_p does the heavy lifting by matching of
> the patterns.
>
> Note this alone does not fix PR 107270, it is a step in the right
> direction. There we get z zer
Ref: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632
Use INCLUDE_VECTOR before including system.h, instead of directly
including , to avoid running into poisoned identifiers.
Signed-off-by: Dimitry Andric
---
libcc1/libcc1plugin.cc | 3 +--
libcc1/libcp1plugin.cc | 3 +--
2 files changed, 2
Andrew Pinski writes:
> This enables construction of V4SF CST like `{1.0f, 1.0f, 0.0f, 0.0f}`
> (and other fp enabled CSTs) by using `fmov v0.2s, 1.0` as the instruction
> is designed to zero out the other bits.
> This is a small extension on top of the code that creates fmov for the case
> where
Richard Sandiford writes:
> Andrew Pinski writes:
>> Aarch64 has a way to form some floating point CSTs via the fmov instructions,
>> these instructions also zero out the upper parts of the registers so they can
>> be used for vector CSTs that have have one non-zero constant that would be
>> abl
Andrew Pinski writes:
> Aarch64 has a way to form some floating point CSTs via the fmov instructions,
> these instructions also zero out the upper parts of the registers so they can
> be used for vector CSTs that have have one non-zero constant that would be
> able
> to formed via the fmov in the
On Wed, 6 Mar 2024, Jason Merrill wrote:
> On 3/4/24 17:26, Patrick Palka wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> > OK for trunk?
> >
> > -- >8 --
> >
> > Alias templates are weird in that their specializations can appear in
> > both decl_specializations an
> On Thu, Feb 08 2024, Martin Jambor wrote:
> > Hi,
> >
> > PR 113757 shows that the code which was meant to debug-reset and
> > remove SSAs defined by LHSs of calls redirected to
> > __builtin_unreachable can trigger also when speculative
> > devirtualization creates a call to a noreturn function
Ping!
please review.
Thanks & Regards
Jeevitha
On 23/02/24 3:04 pm, jeevitha wrote:
> Hi All,
>
> The following patch has been bootstrapped and regtested on powerpc64le-linux.
>
> PTImode attribute assists in generating even/odd register pairs on 128 bits.
> When the user specifies PTImode as
Ping!
please review.
Thanks & Regards
Jeevitha
On 26/02/24 11:13 am, jeevitha wrote:
> Hi All,
>
> The following patch has been bootstrapped and regtested on powerpc64le-linux.
>
> PR110040 exposes an issue concerning moves from vector registers to GPRs.
> There are two moves, one for upper 64
Hi Thomas,
Thomas Schwinge wrote:
/* Return the number of GCN devices on the system. */
int
-GOMP_OFFLOAD_get_num_devices (void)
+GOMP_OFFLOAD_get_num_devices (unsigned int omp_requires_mask)
{
if (!init_hsa_context ())
return 0;
+ /* Return -1 if no omp_requires_mask cannot be
'python' on some systems (e.g. SLES 15) might be Python 2. Prefer python3,
then python, then python2 (as the script still tries to work there).
contrib/ChangeLog:
* dg-extract-results.sh: Check for python3 before python. Check for python2
last.
---
v2: Add python2 and drop EPYTHON.
contrib
This is a regression present on all active branches: the compiler gives a
bogus error on an allocator for an unconstrained array type declared with a
Dynamic_Predicate because Apply_Predicate_Check is invoked directly on a
subtype reference, which it cannot handle.
This moves the check to the r
On Thu, Mar 07, 2024 at 02:25:09PM +, Sam James wrote:
> Jakub Jelinek writes:
>
> > On Thu, Mar 07, 2024 at 02:16:37PM +, Sam James wrote:
> >> 'python' on some systems (e.g. SLES 15) might be Python 2. Prefer
> >> ${EPYTHON}
> >> if defined (used by Gentoo's python-exec wrapping), then
Jakub Jelinek writes:
> On Thu, Mar 07, 2024 at 02:16:37PM +, Sam James wrote:
>> 'python' on some systems (e.g. SLES 15) might be Python 2. Prefer ${EPYTHON}
>> if defined (used by Gentoo's python-exec wrapping), then python3, then
>> python.
>
> I'd say EPYTHON is too distro specific, just
On Thu, Mar 07, 2024 at 02:16:37PM +, Sam James wrote:
> 'python' on some systems (e.g. SLES 15) might be Python 2. Prefer ${EPYTHON}
> if defined (used by Gentoo's python-exec wrapping), then python3, then python.
I'd say EPYTHON is too distro specific, just use for python in python3 python ?
'python' on some systems (e.g. SLES 15) might be Python 2. Prefer ${EPYTHON}
if defined (used by Gentoo's python-exec wrapping), then python3, then python.
contrib/ChangeLog:
* dg-extract-results.sh: Check for python3 before python.
---
contrib/dg-extract-results.sh | 17 ++---
1
Hi Thomas,
first, I have the feeling we talk about (more or less) the same code
region and use the same words – but we talk about rather different
things. Thus, you confuse me (and possibly Andrew) – and my reply
confuses you.
Thomas Schwinge wrote:
On 2024-03-07T12:43:07+0100, Tobias Burnu
Hi,
the recent change to contrib/mklog.py broke contrib/test_mklog.py. It modified
mklog.py to produce "Move to..." instead of "Moved to..." note in changelog for
files that were moved. I've commited the fix as obvious.
Filip Kastl
-- 8< --
contrib/ChangeLog:
* test_mklog.py: "Moved
On 07/03/2024 13:37, Thomas Schwinge wrote:
Hi Andrew!
On 2024-03-07T11:38:27+, Andrew Stubbs wrote:
On 07/03/2024 11:29, Thomas Schwinge wrote:
On 2019-11-12T13:29:16+, Andrew Stubbs wrote:
This patch contributes the GCN libgomp plugin, with the various
configure and make bits to g
> I think it's an obvious change ...
Thanks, pushed.
Dimitry, I suggest you post the second patch for review.
FX
Hi Tobias!
On 2024-03-07T12:43:07+0100, Tobias Burnus wrote:
> Thomas Schwinge wrote:
>> An issue with libgomp GCN plugin 'GCN_SUPPRESS_HOST_FALLBACK' (which is
>> different from the libgomp-level host-fallback execution):
>>> +failure:
>>> + if (suppress_host_fallback)
>>> +GOMP_PLUGIN_fata
Hi Andrew!
On 2024-03-07T11:38:27+, Andrew Stubbs wrote:
> On 07/03/2024 11:29, Thomas Schwinge wrote:
>> On 2019-11-12T13:29:16+, Andrew Stubbs wrote:
>>> This patch contributes the GCN libgomp plugin, with the various
>>> configure and make bits to go with it.
>>
>> An issue with libg
在 2024/3/7 下午8:52, Xi Ruoyao 写道:
It should be better to extend the expected value before the ll/sc loop
(like what LLVM does), instead of repeating the extending in each
iteration. Something like:
I wanted to do this at first, but it didn't work out.
But then I thought about it, and there a
On Thu, Mar 7, 2024 at 1:25 PM Robin Dapp wrote:
>
> Attached v2 combines the checks.
>
> Bootstrapped and regtested on x86 an power10, aarch64 still running.
> Regtested on riscv64.
LGTM.
> Regards
> Robin
>
>
> Subject: [PATCH v2] vect: Do not peel epilogue for partial vectors.
>
> r14-7036-g
On Thu, 2024-03-07 at 09:30 +0100, Jakub Jelinek wrote:
> Hi!
>
> I'm seeing warnings like
> ../../gcc/analyzer/access-diagram.cc: In member function ‘void
> ana::bit_size_expr::print(pretty_printer*) const’:
> ../../gcc/analyzer/access-diagram.cc:399:26: warning: unknown
> conversion type charact
On Thu, 2024-03-07 at 09:12 +0800, Lulu Cheng wrote:
> + output_asm_insn ("1:", operands);
> + output_asm_insn ("ll.\t%0,%1", operands);
> +
> + /* Like the test case atomic-cas-int.C, in loongarch64, O1 and higher, the
> + return value of the val_without_const_folding will not be truncated
On Wed, Mar 06, 2024 at 08:59:16AM -0500, Jason Merrill wrote:
> On 3/5/24 22:06, Nathaniel Shead wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
> >
> > -- >8 --
> >
> > Currently, reading a variable definition always marks that decl as
> > DECL_NOT_REALLY_EXTERN, wit
Hi!
On 2022-06-08T05:56:02+0200, Tobias Burnus wrote:
> [...] On the libgomp side: The devices which do not fulfill the requirements
> are
> now filtered out. [...]
> --- a/libgomp/plugin/plugin-gcn.c
> +++ b/libgomp/plugin/plugin-gcn.c
> /* Return the number of GCN devices on the system. *
Attached v2 combines the checks.
Bootstrapped and regtested on x86 an power10, aarch64 still running.
Regtested on riscv64.
Regards
Robin
Subject: [PATCH v2] vect: Do not peel epilogue for partial vectors.
r14-7036-gcbf569486b2dec added an epilogue vectorization guard for early
break but PR11
Any objection to this update to make the docs reflect reality?
-- >8 --
The macro-based concept checks are unmaintained and do not support C++11
or later, so reject valid code. If nobody plans to update them we should
consider removing them. Alternatively, we could ignore the macro for
C++11 and
On Thu, Mar 07, 2024 at 12:53:31PM +0100, Thomas Schwinge wrote:
> >From 6a6520e01f7e7118b556683c2934f2c64c6dbc81 Mon Sep 17 00:00:00 2001
> From: Thomas Schwinge
> Date: Thu, 7 Mar 2024 12:31:52 +0100
> Subject: [PATCH] GCN, nvptx: Fatal error for missing symbols in
> 'libhsa-runtime64.so.1', 'l
Hi!
On 2017-01-13T19:11:23+0100, Jakub Jelinek wrote:
> [...] If the nvptx libgomp plugin is installed, but libcuda.so.1
> can't be found, then the plugin behaves as if there are no PTX devices
> available. [...]
ACK.
> --- libgomp/plugin/plugin-nvptx.c.jj 2017-01-13 12:07:56.0 +0100
Hi,
Thomas Schwinge wrote:
An issue with libgomp GCN plugin 'GCN_SUPPRESS_HOST_FALLBACK' (which is
different from the libgomp-level host-fallback execution):
+failure:
+ if (suppress_host_fallback)
+GOMP_PLUGIN_fatal ("GCN host fallback has been suppressed");
+ GCN_WARNING ("GCN target ca
On 07/03/2024 11:29, Thomas Schwinge wrote:
Hi!
On 2019-11-12T13:29:16+, Andrew Stubbs wrote:
This patch contributes the GCN libgomp plugin, with the various
configure and make bits to go with it.
An issue with libgomp GCN plugin 'GCN_SUPPRESS_HOST_FALLBACK' (which is
different from the
Hi!
On 2019-11-12T13:29:16+, Andrew Stubbs wrote:
> This patch contributes the GCN libgomp plugin, with the various
> configure and make bits to go with it.
An issue with libgomp GCN plugin 'GCN_SUPPRESS_HOST_FALLBACK' (which is
different from the libgomp-level host-fallback execution):
> -
On Thu, Mar 7, 2024 at 12:11 PM Richard Biener wrote:
>
> On Thu, 7 Mar 2024, Jakub Jelinek wrote:
>
> > On Thu, Mar 07, 2024 at 11:11:35AM +0100, Uros Bizjak wrote:
> > > > Since you CCed me - looking at the code I wonder why we fatally fail.
> > > > The following might also fix the issue and pre
On Thu, 7 Mar 2024, Jakub Jelinek wrote:
> On Thu, Mar 07, 2024 at 11:11:35AM +0100, Uros Bizjak wrote:
> > > Since you CCed me - looking at the code I wonder why we fatally fail.
> > > The following might also fix the issue and preserve more of the
> > > rest of the flow of the function.
> > >
>
Hello,
and ping please.
Martin
On Thu, Feb 08 2024, Martin Jambor wrote:
> Hi,
>
> PR 113757 shows that the code which was meant to debug-reset and
> remove SSAs defined by LHSs of calls redirected to
> __builtin_unreachable can trigger also when speculative
> devirtualization creates a call to
On Thu, 7 Mar 2024, Uros Bizjak wrote:
> On Thu, Mar 7, 2024 at 10:56?AM Richard Biener wrote:
> >
> > On Thu, 7 Mar 2024, Uros Bizjak wrote:
> >
> > > The compiler, configured with --enable-checking=yes,rtl,extra ICEs with:
> > >
> > > internal compiler error: RTL check: expected elt 0 type 'e'
On Thu, Mar 7, 2024 at 11:37 AM Jakub Jelinek wrote:
>
> On Thu, Mar 07, 2024 at 11:11:35AM +0100, Uros Bizjak wrote:
> > > Since you CCed me - looking at the code I wonder why we fatally fail.
> > > The following might also fix the issue and preserve more of the
> > > rest of the flow of the func
This patch fixes a bug where vect_recog_abd_pattern called vect_convert_output
with the incorrect vecitype for the corresponding pattern_stmt.
vect_convert_output expects vecitype to be the vector form of the scalar type
of the LHS of pattern_stmt, but we were passing in the vector form of the LHS
Found when glancing at it: A typo and an omission.
Committed. Seehttps://gcc.gnu.org/projects/gomp/#omp5.2 for the result.
Tobias
commit f99d0f3a2c61ad6677170b9068d511c20ba1bfe1
Author: Tobias Burnus
Date: Thu Mar 7 11:40:57 2024 +0100
projects/gomp/: Fix typo, mark an item as implemente
On Thu, Mar 07, 2024 at 11:11:35AM +0100, Uros Bizjak wrote:
> > Since you CCed me - looking at the code I wonder why we fatally fail.
> > The following might also fix the issue and preserve more of the
> > rest of the flow of the function.
> >
> > If that works I'd prefer it. But I'll defer appro
On Thu, Mar 7, 2024 at 10:56 AM Richard Biener wrote:
>
> On Thu, 7 Mar 2024, Uros Bizjak wrote:
>
> > The compiler, configured with --enable-checking=yes,rtl,extra ICEs with:
> >
> > internal compiler error: RTL check: expected elt 0 type 'e' or 'u',
> > have 'E' (rtx unspec) in try_combine, at c
On 06/03/2024 20:28, Alexandre Oliva wrote:
> On Mar 1, 2024, "Richard Earnshaw (lists)" wrote:
>
>> On 01/03/2024 04:38, Alexandre Oliva wrote:
>>> Thanks for the review.
>
>> For closure, Jakub has just pushed a patch to the generic code, so I
>> don't think we need this now.
>
> ACK. I see
On Thu, 7 Mar 2024, Uros Bizjak wrote:
> The compiler, configured with --enable-checking=yes,rtl,extra ICEs with:
>
> internal compiler error: RTL check: expected elt 0 type 'e' or 'u',
> have 'E' (rtx unspec) in try_combine, at combine.cc:3237
>
> This is
>
> 3236 /* Just replace
On Thu, 7 Mar 2024, Iain Sandoe wrote:
> Hi Dimitry, folks,
>
> > On 6 Mar 2024, at 23:02, Dimitry Andric wrote:
> >
> > On 6 Mar 2024, at 15:57, FX Coudert wrote:
> >>
> >>> Hmm I recall trying it and finding a problem - was there some different
> >>> fix applied
> >>> in the end?
> >>
> >
The compiler, configured with --enable-checking=yes,rtl,extra ICEs with:
internal compiler error: RTL check: expected elt 0 type 'e' or 'u',
have 'E' (rtx unspec) in try_combine, at combine.cc:3237
This is
3236 /* Just replace the CC reg with a new mode. */
3237 SUBST
> -Original Message-
> From: Richard Biener
> Sent: Thursday, March 7, 2024 8:47 AM
> To: Robin Dapp
> Cc: gcc-patches ; Tamar Christina
>
> Subject: Re: [PATCH] vect: Do not peel epilogue for partial vectors
> [PR114196].
>
> On Wed, Mar 6, 2024 at 9:21 PM Robin Dapp wrote:
> >
> > H
On Thu, 7 Mar 2024, Jakub Jelinek wrote:
> Hi!
>
> The following testcase ICEs, because fix_crossing_unconditional_branches
> thinks that asm goto is an unconditional jump and removes it, replacing it
> with unconditional jump to one of the labels.
> This doesn't happen on x86 because the functio
On Thu, 7 Mar 2024, Jakub Jelinek wrote:
> Hi!
>
> As documented in the function comment, choose_mult_variant attempts to
> compute costs of 3 different cases, val, -val and val - 1.
> The -val case is actually only done if val fits into host int, so there
> should be no overflow, but the val - 1
On Wed, Mar 6, 2024 at 9:21 PM Robin Dapp wrote:
>
> Hi,
>
> r14-7036-gcbf569486b2dec added an epilogue vectorization guard for early
> break but PR114196 shows that we also run into the problem without early
> break. Therefore remove early break from the conditions.
>
> gcc/ChangeLog:
>
>
On Thu, 7 Mar 2024, Jakub Jelinek wrote:
> Hi!
>
> When compiling libgcc or on e.g.
> int a[64];
> int p;
>
> void
> foo (void)
> {
> int s = 1;
> while (p)
> {
> s -= 11;
> a[s] != 0;
> }
> }
> sccvn invokes UB in the compiler as detected by ubsan:
> ../../gcc/poly-int.h
On Thu, Mar 7, 2024 at 2:54 AM Li, Pan2 wrote:
>
> Thanks Richard for comments.
>
> > gen_int_libfunc will no longer make it emit libcalls for fixed point
> > modes, so this can't be correct
> > and there's no libgcc implementation for integer mode saturating ops,
> > so it's pointless to emit cal
Pushed to r14-9352.
在 2024/3/6 下午4:54, chenxiaolong 写道:
In simd_correctness_check.h, the role of the macro ASSERTEQ_64 is to check the
result of the passed vector values for the 64-bit data of each array element.
It turns out that it uses the abs() function to check only the lower 32 bits
of the
Pushed to r14-9351.
在 2024/3/6 上午9:19, Yang Yujie 写道:
gcc/ChangeLog:
* config.gcc: Add a case for loongarch*-*-linux-musl*.
* config/loongarch/linux.h: Disable the multilib-compatible
treatment for *musl* targets.
* config/loongarch/musl.h: New file.
---
gcc/co
LGTM except a nit comment:
PR 114264 -> PR target/114264
No need to send V3, just commit it with this change.
juzhe.zh...@rivai.ai
From: demin.han
Date: 2024-03-07 16:32
To: gcc-patches
CC: juzhe.zhong; kito.cheng; pan2.li; jeffreyalaw
Subject: [PATCH v2] RISC-V: Fix ICE in riscv vector costs
1 - 100 of 108 matches
Mail list logo
