gcc/ChangeLog
PR target/93304
* config/riscv/riscv-protos.h (riscv_hard_regno_rename_ok): New.
* config/riscv/riscv.c (riscv_hard_regno_rename_ok): New.
* config/riscv/riscv.h (HARD_REGNO_RENAME_OK): Defined.
gcc/testsuite/ChangeLog
PR target/93304
On Sat, Jan 18, 2020 at 2:02 PM Iain Sandoe wrote:
>
> Hi Jakub,
>
> Jakub Jelinek wrote:
>
> > On Sat, Jan 18, 2020 at 12:53:48PM +, Iain Sandoe wrote:
> > Thanks.
> >
> > Shouldn't this be mentioned in https://gcc.gnu.org/projects/cxx-status.html
> > ?
> >
> >> * This is not enabled by defa
On Mon, Jan 20, 2020 at 2:39 AM wrote:
>
> From: Andrew Pinski
>
> Reported as PR 93321, prepare_block_for_update with some huge
> recusive inlining can go past the stack limit. The loop
> at the end, could be transformed such that the last iteration goes
> back to the begining of the function i
Richard Biener wrote:
On Sat, Jan 18, 2020 at 2:02 PM Iain Sandoe wrote:
Hi Jakub,
Jakub Jelinek wrote:
On Sat, Jan 18, 2020 at 12:53:48PM +, Iain Sandoe wrote:
Thanks.
Shouldn't this be mentioned in
https://gcc.gnu.org/projects/cxx-status.html
?
* This is not enabled by default
On Wed, Jan 15, 2020 at 3:48 PM Martin Liška wrote:
>
> On 1/15/20 12:48 PM, Martin Liška wrote:
> > On 1/15/20 12:08 PM, Richard Biener wrote:
> >> On Wed, Jan 15, 2020 at 10:57 AM Martin Liška wrote:
> >>>
> >>> Hi.
> >>>
> >>> The patch is about caching of outer non-CLEANUP region
> >>> for a
On Sat, Jan 18, 2020 at 1:47 AM wrote:
>
> From: Andrew Pinski
>
> On MIPS, .set noreorder/reorder needs to emitted around
> the nop. The template for the nop instruction uses %(/%) to
> do that. But default_print_patchable_function_entry uses
> fprintf rather than output_asm_insn to output the
When versioning is run the IL is already mangled and finding
a VECTORIZED_CALL IFN can fail.
Bootstrapped / tested on x86_64-unknown-linux-gnu, pushed.
Richard.
2020-01-15 Richard Biener
PR tree-optimization/93094
* tree-vectorizer.h (vect_loop_versioning): Adjust.
(v
Hi Bin,
bin.cheng wrote:
The patch sets current_function_returns_value flag in templates for all
co_return/co_yield/co_await cases, as well as for ramp function. This
fixes false warning message for case like the added, or various cases in
cppcoro.
gcc/cp
2020-01-20 Bin Cheng
*
Hi JunMa,
JunMa wrote:
gcc/cp
2020-01-20 Jun Ma
* coroutines.cc (lookup_awaitable_member): Lookup an awaitable member.
(build_co_await): Use lookup_awaitable_member instead of lookup_member.
(finish_co_yield_expr, finish_co_await_expr): Add error check on return
Hi Bin,
bin.cheng wrote:
gcc/cp
2020-01-20 Bin Cheng
* coroutines.cc (build_co_await): Skip getting complete type for void.
gcc/testsuite
2020-01-20 Bin Cheng
* g++.dg/coroutines/co-await-void_type.C: New
test.<0001-Fix-ICE-when-co_awaiting-on-void-type.patch>
This LG
Ping.
On Sun, 5 Jan 2020, Alexander Monakov wrote:
> Hi,
>
> I noticed there's a costly signed 64-bit division in rtx_cost on x86 as well
> as
> any other target where UNITS_PER_WORD is implemented like TARGET_64BIT ? 8 :
> 4.
> It's also evident that rtx_cost does redundant work for a SET rtx
Hi
Accroding to N4835: When a coroutine is invoked, a copy is created
for each coroutine parameter. While in current implementation, we
only collect used parameters. This may lost behavior inside constructor
and destructor of unused parameters.
This patch change the implementation to collect all
On Mon, Jan 20, 2020 at 08:59:20AM +, Iain Sandoe wrote:
> Hi Bin,
>
> bin.cheng wrote:
>
> > gcc/cp
> > 2020-01-20 Bin Cheng
> >
> >* coroutines.cc (build_co_await): Skip getting complete type for
> > void.
> >
> > gcc/testsuite
> > 2020-01-20 Bin Cheng
> >
> >* g+
在 2020/1/20 下午4:55, Iain Sandoe 写道:
Hi JunMa,
JunMa wrote:
gcc/cp
2020-01-20 Jun Ma
* coroutines.cc (lookup_awaitable_member): Lookup an
awaitable member.
(build_co_await): Use lookup_awaitable_member instead of
lookup_member.
(finish_co_yield_expr, finish_co_awai
On Mon, Jan 20, 2020 at 5:28 PM Jakub Jelinek wrote:
>
> On Mon, Jan 20, 2020 at 08:59:20AM +, Iain Sandoe wrote:
> > Hi Bin,
> >
> > bin.cheng wrote:
> >
> > > gcc/cp
> > > 2020-01-20 Bin Cheng
> > >
> > >* coroutines.cc (build_co_await): Skip getting complete type for
> > > void
Hi Frederik,
On 20/01/2020 06:57, Harwath, Frederik wrote:
Hi,
this patch implements a runtime ISA check for amdgcn offloading.
The check verifies that the ISA of the GPU to which we try to offload matches
the ISA for which the code to be offloaded has been compiled. If it detects
a mismatch, it
Hi JunMa,
JunMa wrote:
Hi
Accroding to N4835: When a coroutine is invoked, a copy is created
for each coroutine parameter. While in current implementation, we
only collect used parameters. This may lost behavior inside constructor
and destructor of unused parameters.
This patch change the imp
Jakub Jelinek writes:
> On Mon, Jan 20, 2020 at 08:59:20AM +, Iain Sandoe wrote:
>> Hi Bin,
>>
>> bin.cheng wrote:
>>
>> > gcc/cp
>> > 2020-01-20 Bin Cheng
>> >
>> >* coroutines.cc (build_co_await): Skip getting complete type for
>> > void.
>> >
>> > gcc/testsuite
>> > 2020-01
On Mon, Jan 20, 2020 at 10:00:09AM +, Andrew Stubbs wrote:
> > @@ -396,6 +396,88 @@ struct gcn_image_desc
> >struct global_var_info *global_variables;
> > };
> > +/* This enum mirrors the corresponding LLVM enum's values for all ISAs
> > that we
> > + support.
> > + See https://llvm.o
Hi Sandra,
On 1/20/20 5:39 AM, Sandra Loosemore wrote:
I happen to have noticed a couple weeks ago that this language about
OpenACC support being experimental appears in multiple places in the
gfortran manual, […] The same disclaimer for that option in the main
GCC manual was removed years ag
On Wed, Jan 8, 2020 at 11:20 AM Prathamesh Kulkarni
wrote:
>
> On Tue, 5 Nov 2019 at 17:38, Richard Biener
> wrote:
> >
> > On Tue, Nov 5, 2019 at 12:17 AM Kugan Vivekanandarajah
> > wrote:
> > >
> > > Hi,
> > > Thanks for the review.
> > >
> > > On Tue, 5 Nov 2019 at 03:57, H.J. Lu wrote:
> >
On Fri, Jan 17, 2020 at 10:25 AM Martin Liška wrote:
>
> Hi.
>
> The patch removes need to have a gnu_indirect_function global
> symbol. That aligns the code with what ppc64 target does.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
Did you
Hi Bin,
Bin.Cheng wrote:
On Mon, Jan 20, 2020 at 5:28 PM Jakub Jelinek wrote:
On Mon, Jan 20, 2020 at 08:59:20AM +, Iain Sandoe wrote:
Hi Bin,
bin.cheng wrote:
gcc/cp
2020-01-20 Bin Cheng
* coroutines.cc (build_co_await): Skip getting complete type for void.
gcc/testsuite
Hi Richard,
Richard Sandiford wrote:
Jakub Jelinek writes:
On Mon, Jan 20, 2020 at 08:59:20AM +, Iain Sandoe wrote:
Do you really need one byte extra? I mean, sizeof ("__parm.") already
includes +1 for the terminating '\0', so unless you append something to
the buffer later, I don't
On 20/01/2020 10:08, Jakub Jelinek wrote:
On Mon, Jan 20, 2020 at 10:00:09AM +, Andrew Stubbs wrote:
@@ -396,6 +396,88 @@ struct gcn_image_desc
struct global_var_info *global_variables;
};
+/* This enum mirrors the corresponding LLVM enum's values for all ISAs that we
+ support.
+
We now require a C++ compiler to bootstrap. Short some text here and
there.
Pushed.
Gerald
---
htdocs/releases.html | 22 +-
1 file changed, 9 insertions(+), 13 deletions(-)
diff --git a/htdocs/releases.html b/htdocs/releases.html
index c7a9bf1c..30b777f4 100644
--- a/htdocs
On 17/01/2020 11:21, Richard Earnshaw (lists) wrote:
The initial structure for vendor and personal branches makes use of the
default remote (normally origin) for the upstream repository).
Unfortunately, this causes some confusion, especially for personal
branches because a push will not push to
"Kewen.Lin" writes:
> gcc/ChangeLog
>
> 2020-01-16 Kewen Lin
>
> * config/rs6000/rs6000.c (TARGET_STRIDE_DFORM_VALID_P): New macro.
> (rs6000_stride_dform_valid_p): New function.
> * doc/tm.texi: Regenerate.
> * doc/tm.texi.in (TARGET_STRIDE_DFORM_VALID_P): New hook.
>
On Mon, Jan 20, 2020 at 10:36:31AM +, Andrew Stubbs wrote:
> The HSA/ROCm runtime rejects binaries not built for the exact device
> present.
>
> In practice, binaries built by GCC for GCN3 "fiji" devices would probably
> run on any of the devices we currently support, if only the driver would
在 2020/1/20 下午6:07, Iain Sandoe 写道:
Hi JunMa,
JunMa wrote:
Hi
Accroding to N4835: When a coroutine is invoked, a copy is created
for each coroutine parameter. While in current implementation, we
only collect used parameters. This may lost behavior inside constructor
and destructor of unused p
On 19/01/2020 08:53, Fāng-ruì Sòng via gcc-patches wrote:
> It'd be great to have some tests, e.g.
>
> 1. -fpatchable-function-entry=0 -mbranch-protection=bti
> 2. -fpatchable-function-entry=2 -mbranch-protection=bti
>
> I have updated clang to emit `.Lfunc_begin0: bti c; nop; nop` for case 2.
On Mon, Jan 20, 2020 at 6:31 PM Iain Sandoe wrote:
>
> Hi Bin,
>
> Bin.Cheng wrote:
>
> > On Mon, Jan 20, 2020 at 5:28 PM Jakub Jelinek wrote:
> >> On Mon, Jan 20, 2020 at 08:59:20AM +, Iain Sandoe wrote:
> >>> Hi Bin,
> >>>
> >>> bin.cheng wrote:
> >>>
> gcc/cp
> 2020-01-20 Bin
On 20/01/2020 10:42, Jakub Jelinek wrote:
:(
Another option would be to build offloading code by GCN multiple times, once
for each incompatible ISA the user is asking for, so that one can have then
binaries that will work on different hw.
Because e.g. with the distro vendor hat, it is hard to gue
We were pruning type-local subroutine DIEs if their context is unused
despite us later needing those DIEs as abstract origins for inlines.
The patch makes code already present for -fvar-tracking-assignments
unconditional.
Bootstrapped and tested on x86_64-unknown-linux-gnu, OK?
Thanks,
Richard.
On Mon, Jan 20, 2020 at 11:00:58AM +, Andrew Stubbs wrote:
> Indeed, fat binaries would be a good solution.
>
> Presumably it's possible, but I'm not sure how we'd go about getting the
> offload mechanism to launch the backend multiple times? Having got that far,
> the libgomp and mkoffload ch
On Mon, Jan 20, 2020 at 12:04:12PM +0100, Richard Biener wrote:
>
> We were pruning type-local subroutine DIEs if their context is unused
> despite us later needing those DIEs as abstract origins for inlines.
> The patch makes code already present for -fvar-tracking-assignments
> unconditional.
>
Hi.
I've just tested the backport on both GCC 8 and 9 branches.
I'm going to install it.
Martin
>From 4a856551c0f969be6525371892277c206b4181da Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Mon, 20 Jan 2020 11:16:21 +0100
Subject: [PATCH] Backport f48c6014133c8989702458f9082e34ba6dd326d4
gc
Bin.Cheng wrote:
> On Mon, Jan 20, 2020 at 6:31 PM Iain Sandoe wrote:
>> Hi Bin,
>>
>> Bin.Cheng wrote:
>>
>>> On Mon, Jan 20, 2020 at 5:28 PM Jakub Jelinek wrote:
On Mon, Jan 20, 2020 at 08:59:20AM +, Iain Sandoe wrote:
> Hi Bin,
>
> bin.cheng wrote:
>
>> gcc
Pushed.
---
htdocs/projects/index.html | 3 ---
1 file changed, 3 deletions(-)
diff --git a/htdocs/projects/index.html b/htdocs/projects/index.html
index 26f667bd..282d79eb 100644
--- a/htdocs/projects/index.html
+++ b/htdocs/projects/index.html
@@ -69,9 +69,6 @@ informed of any substantial proj
On 20/01/2020 11:07, Jakub Jelinek wrote:
On Mon, Jan 20, 2020 at 11:00:58AM +, Andrew Stubbs wrote:
Indeed, fat binaries would be a good solution.
Presumably it's possible, but I'm not sure how we'd go about getting the
offload mechanism to launch the backend multiple times? Having got tha
On Mon, 20 Jan 2020, Richard Sandiford wrote:
> "Kewen.Lin" writes:
> > gcc/ChangeLog
> >
> > 2020-01-16 Kewen Lin
> >
> > * config/rs6000/rs6000.c (TARGET_STRIDE_DFORM_VALID_P): New macro.
> > (rs6000_stride_dform_valid_p): New function.
> > * doc/tm.texi: Regenerate.
> > * do
On 19/01/2020 14:09, Gerald Pfeifer wrote:
Hi Richard,
On Thu, 9 Jan 2020, Richard Earnshaw (lists) wrote:
The thread on gcc@ is now so long and complicated that this proposal
back at the start has dropped off the radar. With the switch now
imminent I'd like to re-propose this change, this tim
writes:
> From: Andrew Pinski
>
> The problem here was g:23b88fda665d2f995c was not a complete fix
> for supporting tranditional TLS on ILP32.
>
> So the problem here is a couple of things, first __tls_get_addr
> call will return a C pointer value so we need to use ptr_mode
> when we are creating
Hi,
By standard, coroutine body should be encapsulated in try-catch block
as following:
try {
// coroutine body
} catch(...) {
promise.unhandled_exception();
}
Given above try-catch block is implemented in the coroutine actor
function called by coroutine ramp function, so the promise
Hi,
This patch attempts to add returns_arg attribute for c-family
languages. For C++ methods, first arg is assumed to be this pointer,
similar to alloc_size.
I have a couple of doubts:
(a) I am not sure why DECL_ARGUMENTS (decl) in
handle_returns_arg_attribute returns NULL ? My intent was to check
Hi JunMa,
JunMa wrote:
> 在 2020/1/20 下午6:07, Iain Sandoe 写道:
>> Hi JunMa,
>>
>> JunMa wrote:
>>
>>> Hi
>>> Accroding to N4835: When a coroutine is invoked, a copy is created
>>> for each coroutine parameter. While in current implementation, we
>>> only collect used parameters. This may lost b
在 2020/1/20 下午7:55, Iain Sandoe 写道:
Hi JunMa,
JunMa wrote:
在 2020/1/20 下午6:07, Iain Sandoe 写道:
Hi JunMa,
JunMa wrote:
Hi
Accroding to N4835: When a coroutine is invoked, a copy is created
for each coroutine parameter. While in current implementation, we
only collect used parameters. This
JunMa wrote:
在 2020/1/20 下午7:55, Iain Sandoe 写道:
Hi JunMa,
JunMa wrote:
在 2020/1/20 下午6:07, Iain Sandoe 写道:
Hi JunMa,
JunMa wrote:
Hi
Accroding to N4835: When a coroutine is invoked, a copy is created
for each coroutine parameter. While in current implementation, we
only collect used
Hi Thomas,
On 1/19/20 7:21 PM, Thomas König wrote:
the attached patch fixes an ICE which could occur for empty
substrings (see test case).
I think one should rather fix the following issue. – While on x86-64 it
does not seem to cause problems, it might for other platforms.
Additionally, it i
在 2020/1/20 下午8:21, Iain Sandoe 写道:
JunMa wrote:
在 2020/1/20 下午7:55, Iain Sandoe 写道:
Hi JunMa,
JunMa wrote:
在 2020/1/20 下午6:07, Iain Sandoe 写道:
Hi JunMa,
JunMa wrote:
Hi
Accroding to N4835: When a coroutine is invoked, a copy is created
for each coroutine parameter. While in current
Hi!
On Thu, Jan 16, 2020 at 05:36:52PM +0800, Kewen.Lin wrote:
> As we discussed in the thread
> https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00196.html
> Original: https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00104.html,
> I'm working to teach IVOPTs to consider D-form group access during unrol
On 1/20/20 12:07 PM, Jakub Jelinek wrote:
I'd say easiest would be to do that in the gcn specific mkoffload. But
there needs to be a way for the user to specify that he wants only a
particular variant and not all of them (perhaps look for -march= in
the offload options?)?
I think that relates
g:3bd2918594dae34ae84f mishandled the case in which only the
tail end of a multireg hard register is invalidated by the call.
Walking all the entries should be both safer and more precise.
Avoiding cselib_invalidate_regno also means that we no longer
walk the same list multiple times (which is som
Hi!
On Thu, Jan 16, 2020 at 05:39:40PM +0800, Kewen.Lin wrote:
> --- a/gcc/cfgloop.h
> +++ b/gcc/cfgloop.h
> @@ -232,6 +232,9 @@ public:
> Other values means unroll with the given unrolling factor. */
>unsigned short unroll;
>
> + /* Like unroll field above, but it's estimated in mid
lra_assign has an assert to make sure that no pseudo is allocated
to a conflicting hard register. It used to be restricted to
!flag_ipa_ra, but in g:a1e6ee38e708ef2bdef4 I'd enabled it for
flag_ipa_ra too. It then tripped while building libstdc++
for mips-mti-linux.
The failure was due to code a
Hi,
On Thu, 16 Jan 2020 at 16:59, Stam Markianos-Wright
wrote:
>
>
>
> On 1/13/20 10:05 AM, Kyrill Tkachov wrote:
> > Hi Stam,
> >
> > On 1/10/20 6:45 PM, Stam Markianos-Wright wrote:
> >> Hi all,
> >>
> >> This is a respin of patch:
> >>
> >> https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01448.
Tamar Christina writes:
> Hi All,
>
> This marks the parameter &fi as unused so it doesn't
> cause a boostrap failure.
>
> Bootstrapped aarch64-none-linux-gnu.
>
> committed under the obvious rule.
>
> Thanks,
> Tamar
>
> gcc/ChangeLog:
>
> 2020-01-18 Tamar Christina
>
> * config/aarch64/
Hi!
On Mon, Jan 20, 2020 at 10:42:12AM +, Richard Sandiford wrote:
> "Kewen.Lin" writes:
> > gcc/ChangeLog
> >
> > 2020-01-16 Kewen Lin
> >
> > * config/rs6000/rs6000.c (TARGET_STRIDE_DFORM_VALID_P): New macro.
> > (rs6000_stride_dform_valid_p): New function.
> > * doc/tm.texi:
On Thu, 14 Nov 2019 at 15:19, Mihail Ionescu
wrote:
>
> Hi,
>
> This patch adds the new scalar shift instructions for Armv8.1-M
> Mainline to the arm backend.
> This patch is adding the following instructions:
>
> ASRL (reg)
> LSLL (reg)
>
>
> ChangeLog entry are as follow:
>
> *** gcc/ChangeLog *
On Thu, 14 Nov 2019 at 15:19, Mihail Ionescu
wrote:
>
> Hi,
>
> This is part of a series of patches where I am trying to add new
> instructions for Armv8.1-M Mainline to the arm backend.
> This patch is adding the following instructions:
>
> ASRL (imm)
> LSLL (imm)
> LSRL (imm)
>
>
> ChangeLog ent
Hi!
On Thu, Jan 16, 2020 at 05:42:41PM +0800, Kewen.Lin wrote:
> +/* At time the dform optimization pass was merged with trunk, 12
> + lxv instructions were emitted in place of the same number of lxvx
> + instructions. No need to require exactly this number, as it may
> + change when other
On Mon, Jan 20, 2020 at 2:25 AM Richard Biener
wrote:
>
> On Fri, Jan 17, 2020 at 10:25 AM Martin Liška wrote:
> >
> > Hi.
> >
> > The patch removes need to have a gnu_indirect_function global
> > symbol. That aligns the code with what ppc64 target does.
> >
> > Patch can bootstrap on x86_64-linu
On Sun, Jan 19, 2020 at 11:53 PM Uros Bizjak wrote:
>
> On Sun, Jan 19, 2020 at 10:00 PM H.J. Lu wrote:
> >
> > On Sun, Jan 19, 2020 at 12:16 PM Uros Bizjak wrote:
> > >
> > > On Sun, Jan 19, 2020 at 9:07 PM H.J. Lu wrote:
> > > >
> > > > On Sun, Jan 19, 2020 at 12:01 PM Uros Bizjak wrote:
> >
On Mon, 20 Jan 2020, H.J. Lu wrote:
> We can that only if function is static:
>
[ship asm]
>
> In this case, foo must be global.
H.J., can you rephrase more clearly? Your response seems contradictory and
does not help to explain the matter.
Alexander
On Mon, Jan 20, 2020 at 5:36 AM Alexander Monakov wrote:
>
>
>
> On Mon, 20 Jan 2020, H.J. Lu wrote:
> > We can that only if function is static:
> >
> [ship asm]
> >
> > In this case, foo must be global.
>
> H.J., can you rephrase more clearly? Your response seems contradictory and
> does not help
I've pushed this to master, to address 80005
__has_include is funky in that it is macro-like from the POV of #ifdef
and friends, but lexes its parenthesize argument #include-like. We were
failing the second part of that, because we used a forwarding macro to
an internal name, and hence always
Hi Kewen,
Would it not make more sense to use the TARGET_ADDRESS_COST hook
to return different costs for immediate offset and register offset addressing,
and ensure IVOpts correctly takes this into account?
On AArch64 we've defined different costs for immediate offset, register offset,
register o
"Fangrui Song via gcc-patches" writes:
> Fixes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93194
Applied, thanks.
Richard
> From 60f489f2bf2b32afd1bdbb2405bb028dcedf82cc Mon Sep 17 00:00:00 2001
> From: Fangrui Song
> Date: Tue, 7 Jan 2020 20:46:26 -0800
> Subject: [PATCH] Align __patchable_f
Hi Thomas,
I have attached a patch containing the changes that you suggested.
On 16.01.20 17:00, Thomas Schwinge wrote:
> On 2019-12-20T17:46:57+0100, "Harwath, Frederik"
> wrote:
>> --- /dev/null
>> +++ b/libgomp/testsuite/libgomp.oacc-c-c++-common/acc_get_property-2.c
>
> I suggest to rename
On Mon, 20 Jan 2020, H.J. Lu wrote:
> For,
>
> ---
> __attribute__((target_clones("avx","default")))
> int
> foo ()
> {
> return -2;
> }
>
>
> foo's resolver must be global. For
>
> ---
> __attribute__((target_clones("avx","default")))
> static int
> foo ()
> {
> return -2;
> }
> --
Hi Ian,
The libiberty testsuite in the gcc mainline is currently failing on
the last test:
FAIL at line 1452, options :
in: _Z3fooILPv0EEvPN9enable_ifIXeqT_LDnEEvE4typeE
out: void foo<(void*)0>(enable_if<((void*)0)==(decltype(nullptr)),
void>::type*)
exp: void foo<(void*)0>(
On Mon, Jan 20, 2020 at 6:16 AM Alexander Monakov wrote:
>
>
>
> On Mon, 20 Jan 2020, H.J. Lu wrote:
> > For,
> >
> > ---
> > __attribute__((target_clones("avx","default")))
> > int
> > foo ()
> > {
> > return -2;
> > }
> >
> >
> > foo's resolver must be global. For
> >
> > ---
> > __attri
Wilco Dijkstra writes:
> Hi Kyrill & Richard,
>
>> I was leaving this to others in case it was obvious to them. On the
>> basis that silence suggests it wasn't, :-) could you go into more details?
>> Is it expected on first principles that jump alignment doesn't matter
>> for Neoverse N1, or is t
Hi!
On Mon, Jan 20, 2020 at 01:47:56PM +, Wilco Dijkstra wrote:
> Would it not make more sense to use the TARGET_ADDRESS_COST hook
> to return different costs for immediate offset and register offset addressing,
> and ensure IVOpts correctly takes this into account?
>
> On AArch64 we've defin
PR 92829 reports failures in three -Wstringop-overflow tests on
powerpc64*. They seem to be due to VRP determining less than
perfectly accurate range for some of the expressions used by
the tests to set them.
In g:414231ba78973dfcb11648a0a5287b989e0148bb I've committed tweaks
to the tests to avo
Hi Richard,
> >
> > 2020-01-18 Tamar Christina
> >
> > * config/aarch64/aarch64-sve-builtins-base.cc
> (memory_vector_mode):
> > Mark parameter unused.
>
> Thanks for the quick fix.
>
> Sorry for indulging a personal preference, but for things like this, I think
> it's
> nicer to dro
On Mon, 20 Jan 2020, H.J. Lu wrote:
> > Bare IFUNC's don't seem to have this restriction. Why do we want to
> > constrain target clones this way?
> >
>
> foo's resolver acts as foo. It should have the same visibility as foo.
What do you mean by that? From the implementation standpoint, there
On Mon, Jan 20, 2020 at 6:41 AM Alexander Monakov wrote:
>
>
>
> On Mon, 20 Jan 2020, H.J. Lu wrote:
>
> > > Bare IFUNC's don't seem to have this restriction. Why do we want to
> > > constrain target clones this way?
> > >
> >
> > foo's resolver acts as foo. It should have the same visibility as
On Mon, Jan 20, 2020 at 3:46 PM H.J. Lu wrote:
>
> On Mon, Jan 20, 2020 at 6:41 AM Alexander Monakov wrote:
> >
> >
> >
> > On Mon, 20 Jan 2020, H.J. Lu wrote:
> >
> > > > Bare IFUNC's don't seem to have this restriction. Why do we want to
> > > > constrain target clones this way?
> > > >
> > >
>
On Thu, 9 Jan 2020 at 16:53, Matthew Malcomson
wrote:
>
> We take no action to ensure the SVE vector size is large enough. It is
> left to the user to check that before compiling this intrinsic or before
> running such a program on a machine.
>
> The main difference between ld1ro and ld1rq is in
Using "implicit none" multiple times in a scoping unit is not permitted
– and checked for.
However, using one in the parent name space and re-confirming it in the
current name space is permitted – but was before rejected.
OK for the trunk?
Tobias
PR fortran/93309
* interface.c (gfc_proced
Hi Bin,
bin.cheng wrote:
> By standard, coroutine body should be encapsulated in try-catch block
> as following:
> try {
>// coroutine body
> } catch(...) {
>promise.unhandled_exception();
> }
> Given above try-catch block is implemented in the coroutine actor
> function called by cor
On 1/20/20 1:07 PM, Christophe Lyon wrote:
> Hi,
>
>
> On Thu, 16 Jan 2020 at 16:59, Stam Markianos-Wright
> wrote:
>>
>>
>>
>> On 1/13/20 10:05 AM, Kyrill Tkachov wrote:
>>> Hi Stam,
>>>
>>> On 1/10/20 6:45 PM, Stam Markianos-Wright wrote:
Hi all,
This is a respin of patch:
>>>
On 20/01/2020 14:53, Christophe Lyon wrote:
> On Thu, 9 Jan 2020 at 16:53, Matthew Malcomson
> wrote:
>>
>> + (match_test "aarch64_sve_ld1ro_operand_p (op, DImode)")))
>> +
>
>
>> (define_predicate "aarch64_sve_ldff1_operand"
>> (and (match_code "mem")
>
>> (match_test "aar
Hi,
we have this paragraph in the documentation that attempts to prohibit something
that is allowed by the language. Instead, I think we should say that this
generally should work and explain that a problem in GCC implementation
breaks this.
OK to apply?
Thanks.
Alexander
* doc/implem
On Mon, 20 Jan 2020 at 16:02, Stam Markianos-Wright
wrote:
>
>
>
> On 1/20/20 1:07 PM, Christophe Lyon wrote:
> > Hi,
> >
> >
> > On Thu, 16 Jan 2020 at 16:59, Stam Markianos-Wright
> > wrote:
> >>
> >>
> >>
> >> On 1/13/20 10:05 AM, Kyrill Tkachov wrote:
> >>> Hi Stam,
> >>>
> >>> On 1/10/20 6:4
On 1/20/20 12:18 AM, JunMa wrote:
Hi
This patch adds lookup_awaitable_member, it outputs error messages when
any of
the await_ready/suspend/resume functions are missing in awaitable class.
This patch also add some error check on return value of build_co_await
since we
may failed to build co_
On 1/19/20 11:07 PM, bin.cheng wrote:
Hi,
The patch sets current_function_returns_value flag in templates for all
co_return/co_yield/co_await cases, as well as for ramp function. This
fixes false warning message for case like the added, or various cases in
cppcoro.
Bootstrap and test on X86_64,
Nick Clifton writes:
> Hi Ian,
>
> The libiberty testsuite in the gcc mainline is currently failing on
> the last test:
>
> FAIL at line 1452, options :
> in: _Z3fooILPv0EEvPN9enable_ifIXeqT_LDnEEvE4typeE
> out: void foo<(void*)0>(enable_if<((void*)0)==(decltype(nullptr)),
> voi
On 1/20/20 1:31 PM, Tobias Burnus wrote:
I think one should rather fix the following issue.
That's now https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93336
Tobias
Hi Honza,
The testcase I am looking at is perlbench from Spec2017 but still working on
isolating the exact cause for the slowdown.
It seems the change has a big impact on layout and so also some alignment
changes. So it's a bit hard to track down.
There does seem to be an extra 2k bytes in the
Hi Jakub, Thomas,
We had a customer with a C++ program using GPU offloading failing to compile
due to the code's extensive use of 'static constexpr' in its many template
classes (code was using OpenMP, but OpenACC is no different)
While the FE should ensure that no static members should exist for
JunMa wrote:
> 在 2020/1/20 下午8:21, Iain Sandoe 写道:
>> JunMa wrote:
>>
>>> 在 2020/1/20 下午7:55, Iain Sandoe 写道:
Hi JunMa,
JunMa wrote:
> 在 2020/1/20 下午6:07, Iain Sandoe 写道:
>> Hi JunMa,
>>
>> JunMa wrote:
>>
>>> Hi
>>> Accroding to N4835: When
Hi Andrew,
Thanks for the review! I have attached a revised patch containing the changes
that you suggested.
On 20.01.20 11:00, Andrew Stubbs wrote:
> On 20/01/2020 06:57, Harwath, Frederik wrote:
>> Is it ok to commit this patch to the master branch?
>
> I can't see anything significantly wron
On Tue, Jan 21, 2020 at 12:32:00AM +0800, Chung-Lin Tang wrote:
> Hi Jakub, Thomas,
> We had a customer with a C++ program using GPU offloading failing to compile
> due to the code's extensive use of 'static constexpr' in its many template
> classes (code was using OpenMP, but OpenACC is no differe
Hi All,
I've committed this testsuite-only patch to fix some test cases that
need GCN-specific settings in order to pass.
Test-case loop-auto-1.c is coded to require dimensions only suitable for
nvptx devices. It might be fixable, but for now I'm just disabling it
for amdgcn.
The other loo
yes, current expected entry is wrong and
Nick's patch corrects that.
./kamlesh
On Mon, Jan 20, 2020 at 9:29 PM Ian Lance Taylor wrote:
> Nick Clifton writes:
>
> > Hi Ian,
> >
> > The libiberty testsuite in the gcc mainline is currently failing on
> > the last test:
> >
> > FAIL at li
On 20/01/2020 16:42, Harwath, Frederik wrote:
Hi Andrew,
Thanks for the review! I have attached a revised patch containing the changes
that you suggested.
On 20.01.20 11:00, Andrew Stubbs wrote:
On 20/01/2020 06:57, Harwath, Frederik wrote:
Is it ok to commit this patch to the master branch?
kamlesh kumar writes:
> yes, current expected entry is wrong and
> Nick's patch corrects that.
Thanks. Nick, the patch is OK.
Ian
> On Mon, Jan 20, 2020 at 9:29 PM Ian Lance Taylor wrote:
>
>> Nick Clifton writes:
>>
>> > Hi Ian,
>> >
>> > The libiberty testsuite in the gcc mainline is cu
Hi,
This patch fixes the scalar shifts tests added in:
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01195.html
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01196.html
By adding mthumb and ensuring that the target supports
thumb2 instructions.
*** gcc/testsuite/ChangeLog ***
2020-01-20 Mihail
1 - 100 of 139 matches
Mail list logo
