Pushed.
Gerald
---
htdocs/fortran/index.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/htdocs/fortran/index.html b/htdocs/fortran/index.html
index b7a71de2..1d140b3a 100644
--- a/htdocs/fortran/index.html
+++ b/htdocs/fortran/index.html
@@ -14,7 +14,7 @@
The purpose of
None of our own pages refers to svn.html any longer after the updates
of the last week or two; there may be some external reference, though.
Pushed.
Gerald
---
htdocs/.htaccess | 1 +
1 file changed, 1 insertion(+)
diff --git a/htdocs/.htaccess b/htdocs/.htaccess
index e80d14e4..7aa9f8bb 100644
On Mon, Jan 20, 2020 at 6:46 PM Maciej W. Rozycki wrote:
>
> Ian: Can we please coordinate this somehow? The libgo/ part, like all,
> relies on config/toolexeclibdir.m4, so I can either:
>
> 1. push the whole change all at once and you'll push the libgo/ part to
>your repo independently, whi
Hi
This patch does minor fix on changing context of label_decl from
original function to actor function which avoid assertion in gimplify pass.
Bootstrap and test on X86_64, is it OK?
Regards
JunMa
gcc/cp
2020-01-21 Jun Ma
* coroutines.cc (transform_await_wrapper): Set actor funcion
在 2020/1/21 上午9:31, JunMa 写道:
在 2020/1/20 下午11:49, Nathan Sidwell 写道:
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 c
在 2020/1/21 上午9:31, JunMa 写道:
在 2020/1/20 下午11:49, Nathan Sidwell 写道:
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 c
On Mon, Jan 20, 2020 at 10:59 PM Iain Sandoe wrote:
>
> 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 t
On Tue, 21 Jan 2020, Joseph Myers wrote:
> > Provide means, in the form of a `--with-toolexeclibdir=' configuration
> > option, to override the default installation directory for target
> > libraries, otherwise known as $toolexeclibdir. This is so that it is
> > possible to get newly-built lib
Hi Jim:
Thanks, fixed and committed, and it's OK to commit to gcc 8/9 next week?
On Tue, Jan 21, 2020 at 7:13 AM Jim Wilson wrote:
> On Mon, Jan 20, 2020 at 12:04 AM Kito Cheng wrote:
> > gcc/ChangeLog
> >
> > PR target/93304
> > * config/riscv/riscv-protos.h (riscv_hard_regno_
On Tue, 14 Jan 2020, Chung-Lin Tang wrote:
> Can you test if the attached patch works for you? The patch exports the build
> sysroot
> setting from the toplevel to target library subdirs, and adds the --sysroot=
> option
> when doing build-tree testing (I assume that blddir != "" test is suffici
On Mon, 2 Dec 2019, Maciej W. Rozycki wrote:
> Provide means, in the form of a `--with-toolexeclibdir=' configuration
> option, to override the default installation directory for target
> libraries, otherwise known as $toolexeclibdir. This is so that it is
> possible to get newly-built librari
On Fri, 20 Dec 2019, Mike Stump wrote:
> >> This patch series addresses a problem with the testsuite compiler being
> >> set up across libatomic, libffi, libgo, libgomp with no correlation
> >> whatsoever to the target compiler being used in GCC compilation.
> >> Consequently there in no arran
在 2020/1/21 上午9:34, JunMa 写道:
在 2020/1/21 上午12:39, Iain Sandoe 写道:
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 a co
On Mon, Jan 20, 2020 at 5:44 AM Nathan Sidwell wrote:
> I've pushed this to master, to address 80005
>
> __has_include is funky in that it is macro-like from the POV of #ifdef
> ...
With this patch, __has_include__ no longer works. There is a use of
this in the RISC-V glibc port. I see the docs
> From: Hans-Peter Nilsson
> Date: Tue, 21 Jan 2020 02:47:57 +0100
> (I did not use gcc-git-customization.sh or git-fetch-vendor.sh before
> XX, so there's presumably nothing to clean up.)
Bah; "before 24b178184f260a6ec1516cfb8bb8876874a078a7".
brgds, H-P
> From: "Richard Earnshaw (lists)"
> Date: Fri, 17 Jan 2020 12:21:07 +0100
> As far as possible, I've made the script automatically restructure any
> existing fetch or push lines that earlier versions of the scripts may
> have created - the gcc-git-customization.sh script will convert all
> ve
在 2020/1/21 上午12:39, Iain Sandoe 写道:
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 a coroutine is invoked, a copy is c
在 2020/1/20 下午11:49, Nathan Sidwell 写道:
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_c
On 1/20/20 6:51 PM, Segher Boessenkool wrote:
On Tue, Jan 21, 2020 at 12:23:02AM +0100, Jakub Jelinek wrote:
On Mon, Jan 20, 2020 at 05:10:55PM -0600, Segher Boessenkool wrote:
On Mon, Jan 20, 2020 at 11:52:55PM +0100, Jakub Jelinek wrote:
PR target/93073
* config/rs6000/rs6
The leak in get_mapped_args is due to auto_vec not properly supporting
destructible elements, in that auto_vec's destructor doesn't call the
destructors of its elements.
Successfully bootstrapped and regtested on x86_64-pc-linux-gnu, OK to commit?
gcc/cp/ChangeLog:
* constraint.cc (get_m
On Mon, 2 Dec 2019, Maciej W. Rozycki wrote:
> Provide means, in the form of a `--with-toolexeclibdir=' configuration
> option, to override the default installation directory for target
> libraries, otherwise known as $toolexeclibdir. This is so that it is
> possible to get newly-built librari
On Fri, 10 Jan 2020, Jason Merrill wrote:
> Joseph argued that those warnings are sometimes useful, and that they should
> be controlled by a separate flag. So this patch introduces
> -Warith-conversion, which is off by default in this patch.
>
> Joseph, is that default OK with you?
I am OK wit
On Tue, Jan 21, 2020 at 12:23:02AM +0100, Jakub Jelinek wrote:
> On Mon, Jan 20, 2020 at 05:10:55PM -0600, Segher Boessenkool wrote:
> > On Mon, Jan 20, 2020 at 11:52:55PM +0100, Jakub Jelinek wrote:
> > > PR target/93073
> > > * config/rs6000/rs6000.c (rs6000_emit_cmove): Punt for compare_mode
On Mon, 20 Jan 2020, Alexander Monakov wrote:
> 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
On Mon, Jan 20, 2020 at 05:10:55PM -0600, Segher Boessenkool wrote:
> On Mon, Jan 20, 2020 at 11:52:55PM +0100, Jakub Jelinek wrote:
> > PR target/93073
> > * config/rs6000/rs6000.c (rs6000_emit_cmove): Punt for compare_mode
> > other than SFmode or DFmode.
>
> "If using fsel, punt for
On Mon, Jan 20, 2020 at 12:04 AM Kito Cheng wrote:
> 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): Def
Hi!
On Mon, Jan 20, 2020 at 11:52:55PM +0100, Jakub Jelinek wrote:
> PR target/93073
> * config/rs6000/rs6000.c (rs6000_emit_cmove): Punt for compare_mode
> other than SFmode or DFmode.
"If using fsel, punt for..." etc.
> + /* Don't allow compare_mode other than SFmode or DFmo
On Mon, 20 Jan 2020, Prathamesh Kulkarni wrote:
> Hi,
> This patch attempts to add returns_arg attribute for c-family
> languages. For C++ methods, first arg is assumed to be this pointer,
This is missing .texi documentation explaining the attribute and the cases
for which it would be useful.
A
Hi!
The following testcase ICEs, because for TFmode the particular subtraction
pattern (*subtf3) is not enabled with the given options. Using
expand_simple_binop instead of emitting the subtraction by hand just moves
the ICE one insn later, NEG of ABS is not then recognized, etc., but
ultimately
On Mon, 20 Jan 2020, Sandra Loosemore wrote:
> I'm not happy with this -- we shouldn't be talking about internal concepts
> like GIMPLE and RTL in the GCC user manual. Can we instead talk about which
> user-visible optimization options cause problems, so that users who feel the
> urgent need to w
On 19/01/20 20:06 -0700, Sandra Loosemore wrote:
On 1/13/20 9:12 AM, Joseph Myers wrote:
On Mon, 13 Jan 2020, Sandra Loosemore wrote:
On 1/13/20 7:02 AM, Eric S. Raymond wrote:
Clean up references to SVN in in the GCC docs, redirecting to Git
documentation as appropriate.
This is OK, althou
On Mon, Jan 20, 2020 at 5:24 AM H.J. Lu wrote:
>
> 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 1/20/20 3:08 AM, Tobias Burnus wrote:
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
On 1/20/20 8:08 AM, Alexander Monakov wrote:
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 a
Jonathan spotted this, so I went ahead and addressed it (adding
"git show" as another relevant command, slightly reordering the
list, and removing a link to the SvnHelp wiki entry).
Pushed.
Gerald
---
htdocs/bugs/reghunt.html | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
di
On 20/01/2020 18:25, Mihail Ionescu wrote:
> Hi,
>
>
> This patch fixes the uninitialised 'last_regno' variable introduced in:
> https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01299.html
> and makes the clear_operation_p code more readable.
>
> *** gcc/ChangeLog ***
>
> 2020-01-20 Mihail-Calin
And this was the last reference to svn.html in our tree. :)
Pushed.
---
htdocs/releases.html | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/htdocs/releases.html b/htdocs/releases.html
index 30b777f4..1c8e87e2 100644
--- a/htdocs/releases.html
+++ b/htdocs/releases.html
@@
Hi,
This patch fixes the uninitialised 'last_regno' variable introduced in:
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01299.html
and makes the clear_operation_p code more readable.
*** gcc/ChangeLog ***
2020-01-20 Mihail-Calin Ionescu
* gcc/config/arm/arm.c (clear_operation_p):
Hi Christophe,
On 01/20/2020 01:19 PM, Christophe Lyon wrote:
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:
ASR
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
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
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?
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
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
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 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
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 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
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
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
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/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,
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 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
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 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
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:
>>>
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
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
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
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 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, 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
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
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!
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
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
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
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, 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 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
"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 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
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
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
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 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, 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
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 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
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 *
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:
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 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.
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, 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
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
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
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
在 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 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
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
在 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
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
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,
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
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
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
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 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
1 - 100 of 139 matches
Mail list logo
