Re: [PATCH] powerpc: Fix ICE with fp conditional move (PR target/93073)

Hi! On Mon, Jan 20, 2020 at 08:31:43PM -0500, Nicholas Krause wrote: > On 1/20/20 6:51 PM, Segher Boessenkool wrote: > >We can (and should) use other instructions than just fsel here as well > >(say, xscmpgedp followed by xxsel). This can also work for QP float, > >which also can be TFmode, just

Re: [PATCH Coroutines] Fix issue with unused corutine function parameters

JunMa wrote: 在 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

Re: [PR 80005] __has_include parsing

On Mon, Jan 20, 2020 at 06:01:27PM -0800, Jim Wilson wrote: > 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 longe

Re: [PATCH Coroutines] Fix issue with unused corutine function parameters

在 2020/1/21 下午4:07, Iain Sandoe 写道: JunMa wrote: 在 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 Jun

[PATCH] riscv: Fix up riscv_rtx_costs for RTL checking (PR target/93333)

Hi! As mentioned in the PR, during combine rtx_costs can be called sometimes even on RTL that has not been validated yet and so can contain even operands that aren't valid in any instruction. The following patch ought to fix this case, ok for trunk? 2020-01-21 Jakub Jelinek PR target

Re: [PATCH] PR target/93319: x32: Add x32 support to -mtls-dialect=gnu2

On Mon, Jan 20, 2020 at 10:46 PM H.J. Lu wrote: > > > OK. Let's go with this version, but please investigate if we need to > > > calculate TLS address in ptr_mode instead of Pmode. Due to quite some > > > zero-extension from ptr_mode to Pmode hacks in this area, it looks to > > > me that the whol

[PATCHv2] Change recursive prepare_block_for_update to use a worklist

From: Andrew Pinski Reported as PR 93321, prepare_block_for_update with some huge recusive inlining can go past the stack limit. Transforming this recursive into worklist improves the stack usage here and we no longer seg fault for the testcase. Note the order we OK? Bootstrapped and tested on

Re: [PATCH Coroutines]Fix ICE when co_awaiting on void type

Hi Nathan, This corrects my mixup between the error returns for complete_type and complete_type_or_else, spotted by Jakub, I have included Bin’s change that makes the coro-specific error message fire if a void type is provided for this. Additional comments below. Iain Sandoe wrote: > Bin.Chen

Re: [PATCH Coroutines]Fix ICE when co_awaiting on void type

On Tue, Jan 21, 2020 at 10:12:21AM +, Iain Sandoe wrote: > @@ -633,7 +634,13 @@ build_co_await (location_t loc, tree a, > suspend_point_kind suspend_kind) >else > o = a; /* This is most likely about to fail anyway. */ > > - tree o_type = complete_type_or_else (TREE_TYPE (o), o); >

Re: [PATCH Coroutines]Access promise via actor function's frame pointer argument

Hi Nathan, Bin, bin.cheng wrote: > 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.unhan

Re: [v2] contrib: New remotes structure for vendor and personal refs

On 21/01/2020 01:47, Hans-Peter Nilsson wrote: 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-customi

Re: [PATCH] PR target/93319: x32: Add x32 support to -mtls-dialect=gnu2

On Tue, Jan 21, 2020 at 9:47 AM Uros Bizjak wrote: > > On Mon, Jan 20, 2020 at 10:46 PM H.J. Lu wrote: > > > > > OK. Let's go with this version, but please investigate if we need to > > > > calculate TLS address in ptr_mode instead of Pmode. Due to quite some > > > > zero-extension from ptr_mode

Re: [v2] contrib: New remotes structure for vendor and personal refs

On 21/01/2020 10:26, Richard Earnshaw (lists) wrote: On 21/01/2020 01:47, Hans-Peter Nilsson wrote: 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

Re: [PATCHv2] Change recursive prepare_block_for_update to use a worklist

On Tue, Jan 21, 2020 at 10:27 AM wrote: > > From: Andrew Pinski > > Reported as PR 93321, prepare_block_for_update with some huge > recusive inlining can go past the stack limit. Transforming this > recursive into worklist improves the stack usage here and we no > longer seg fault for the testcas

[AArch64] effective_target for aarch64 f64mm asm

Commit 9ceec73 introduced intrinsics for the AArch64 FP64 matrix multiply instructions. These require binutils support for the same instructions. ( See https://gcc.gnu.org/ml/gcc-patches/2020-01/msg01234.html for the testsuite failures this introduced. ) This patch adds a DejaGNU test to ensure t

[PATCH/commited] Change recursive prepare_block_for_update to use a worklist

From: Andrew Pinski This is what I committed. Reported as PR 93321, prepare_block_for_update with some huge recusive inlining can go past the stack limit. Transforming this recursive into worklist improves the stack usage here and we no longer seg fault for the testcase. Note the order we walk

[PATCH Coroutines] Handle type deduction of auto and decltype(auto) with indirect_ref expression

Hi When test gcc with cppcoro, I find case like:   int& awaitable::await_resume()   auto x1 = co_await awaitable;   decltype(auto) x2 = co_await awaitable; Based on standard, typeof(x1) should be int, typeof(x2) is int&. However, we get both x1 and x2 as int, this because we donot consider indir

Re: [PATCH][AArch64] PR92424: Fix -fpatchable-function-entry=N,M with BTI

Hi Szabolcs, Answers from a linux dev perspective below. On Mon, Jan 20, 2020 at 10:53:33AM +, Szabolcs Nagy wrote: > 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. -f

Re: [Patch,Fortran] PR93309 – permit repeated 'implicit none(external)' in sub-scoping unit

On 20 January 2020 15:55:23 CET, Tobias Burnus wrote: >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. + if

[PATCH] tree-optimization/92328 fix value-number with bogus type

We were actually value-numbering two entities with different type the same rather than just having the same representation in the hashtable. The following fixes that by wrapping the value in a to be inserted VIEW_CONVERT_EXPR. Bootstrapped & tested on x86_64-unknown-linux-gnu, pushed. Richard.

Re: [AArch64] effective_target for aarch64 f64mm asm

Matthew Malcomson writes: > Commit 9ceec73 introduced intrinsics for the AArch64 FP64 matrix > multiply instructions. These require binutils support for the same > instructions. > ( See https://gcc.gnu.org/ml/gcc-patches/2020-01/msg01234.html for the > testsuite failures this introduced. ) > > Th

Re: [PR 80005] __has_include parsing

On 1/20/20 9:01 PM, Jim Wilson wrote: 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

Re: [PATCH Coroutines 1/2] Add error messages for missing methods of awaitable class

On 1/20/20 10:38 PM, JunMa wrote: 在 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.

Re: [PATCH Coroutines 2/2] Add error check on return value of build_co_await

On 1/20/20 10:44 PM, JunMa wrote: 在 2020/1/21 上午9:31, JunMa 写道: Regards JunMa nathan Hi nathan, attachment is the updated patch which check error_mark_node of build_co_coawait. Regards JunMa gcc/cp 2020-01-21  Jun Ma * coroutines.cc (finish_co_await_expr): Add error check on

Re: [PATCH Coroutines]Fix ICE when co_awaiting on void type

On 1/21/20 5:12 AM, Iain Sandoe wrote: Hi Nathan, This corrects my mixup between the error returns for complete_type and complete_type_or_else, spotted by Jakub, I have included Bin’s change that makes the coro-specific error message fire if a void type is provided for this. ok thanks. nath

[PATCH] RX update functions with string constraint

Hello, The following patch updates the setmemsi and rx_setmem functions. The patch adds the rx_allow_string_insns constraint to these functions in order to be used only when the string support is enabled. Regression test is OK, without additional fails, and was tested with the following command:

Re: [Patch,Fortran] PR93309 – permit repeated 'implicit none(external)' in sub-scoping unit

Hi Bernhard, On 1/21/20 12:43 PM, Bernhard Reutner-Fischer wrote: + if (sym->attr.proc == PROC_UNKNOWN) + for (gfc_namespace *ns = sym->ns; ns; ns = ns->parent) + if (ns->has_implicit_none_export) +has_implicit_none_export = true; s/;/, break;/ If we don't do th

Re: [PATCH] Make target_clones resolver fn static.

On 1/20/20 3:52 PM, Richard Biener wrote: 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?

Re: [PATCH][AArch64] PR92424: Fix -fpatchable-function-entry=N,M with BTI

On 21/01/2020 11:34, Mark Rutland wrote: > Hi Szabolcs, > > Answers from a linux dev perspective below. thanks. > On Mon, Jan 20, 2020 at 10:53:33AM +, Szabolcs Nagy wrote: >> i have to ask some linux developers which way they prefer: >> >> e.g. -fpatchable-function-entry=3,1 is >> >> .sect

Re: [PATCH] doc: clarify the situation with pointer arithmetic

On Mon, 20 Jan 2020, Joseph Myers wrote: > 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 an

[patch] contrib: script to create a new vendor branch

This script is intended to create a new vendor branch. Doing so is not completely obvious if you are not familiar with the upstream structure, so this takes the pain out of getting it right. It doesn't check out the branch locally, but does set everything up so that, if you have push enabled

Re: [patch] contrib: script to create a new vendor branch

On 21/01/2020 13:29, Richard Earnshaw (lists) wrote: This script is intended to create a new vendor branch.  Doing so is not completely obvious if you are not familiar with the upstream structure, so this takes the pain out of getting it right. It doesn't check out the branch locally, but does

[PATCH] ipa-profile.c: reset call_sums state within ipa-profile.c (v2; PR 93315)

On Sat, 2020-01-18 at 18:42 +0100, Jan Hubicka wrote: > > > > On Mon, 2020-01-13 at 11:23 +0800, luoxhu wrote: > > > > On 2020/1/10 19:08, Jan Hubicka wrote: > > > > > OK. You will need to do the obvious updates for Martin's > > > > > patch > > > > > which turned some member functions into static f

Re: [PATCH][ARM] Correctly set SLOW_BYTE_ACCESS

ping (updated comment to use the same wording as the AArch64 version on trunk) Contrary to all documentation, SLOW_BYTE_ACCESS simply means accessing bitfields by their declared type, which results in better codegeneration on practically any target. So set it correctly to 1 on Arm. As a result w

Re: [PATCH v2][ARM] Disable code hoisting with -O3 (PR80155)

ping Hi, While code hoisting generally improves codesize, it can affect performance negatively. Benchmarking shows it doesn't help SPEC and negatively affects embedded benchmarks. Since the impact is relatively small with -O2 and mainly affects -O3, the simplest option is to disable code hoisting

Re: [PATCH Coroutines 1/2] Add error messages for missing methods of awaitable class

在 2020/1/21 下午8:06, Nathan Sidwell 写道: On 1/20/20 10:38 PM, JunMa wrote: 在 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 fu

Re: [PATCH] doc: clarify the situation with pointer arithmetic

On Tue, 21 Jan 2020, Alexander Monakov wrote: > On Mon, 20 Jan 2020, Joseph Myers wrote: > > > 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

[PATCH, v2] wwwdocs: e-mail subject lines for contributions

[updated, following some comments from Gerald, main differences are slight tweaks to the html markup and changing "email" to "e-mail"] This patch proposes some new (additional) rules for email subject lines when contributing to GCC. The goal is to make sure that, as far as possible, the subject

[PATCH] Remove dead variable.

Hi. The patch is obvious and approved by Segher. Martin gcc/ChangeLog: 2020-01-21 Martin Liska * config/rs6000/rs6000.c (common_mode_defined): Remove unused variable. --- gcc/config/rs6000/rs6000.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/gcc/config/rs6000/rs

[PATCH] testsuite: Add target/xfail argument to check-function-bodies

check-function-bodies allows individual function tests to be annotated with target/xfail selectors, but sometimes it's useful to have the same selector for all functions. Tested on aarch64-linux-gnu and x86_64-linux-gnu, and with a following ILP32 patch that needs it. OK to install? Richard 20

[PATCH v2][AArch64] PR92424: Fix -fpatchable-function-entry=N,M with BTI

v2: - emit bti based on feedback from Richard Sandiford (dont copy varasm logic). - add testcases. - kept bti outside the patch area if possible, i.e. option (b) in earlier discussion. This fix does not update the documentation of the generic option, I think some text would be useful there abo

Re: [PATCH] doc: clarify the situation with pointer arithmetic

On Tue, 21 Jan 2020, Richard Biener wrote: > Fourth. That PNVI (I assume it's the whole pointer-provenance stuff) > wants to get the "best" of both which can never be done since a compiler > needs to have a way to be conservative - in this area it's conflicting > conservative treatment which is i

Re: [PATCH, v2] wwwdocs: e-mail subject lines for contributions

On Tue, Jan 21, 2020 at 02:52:00PM +, Richard Earnshaw (lists) wrote: > [updated, following some comments from Gerald, main differences are > slight tweaks to the html markup and changing "email" to "e-mail"] > > This patch proposes some new (additional) rules for email subject lines > when c

[PATCH] Prune invalid filename due to makefile syntax.

Hi. The patch strips '#' in filenames used for Makefile. Ready to be installed? Thanks, Martin gcc/ChangeLog: 2020-01-21 Martin Liska PR driver/93057 * lto-wrapper.c (prune_filename_for_make): Prune characters like '#'. --- gcc/lto-wrapper.c | 11 +++ 1 fil

Re: [PATCH] Prune invalid filename due to makefile syntax.

> Hi. > > The patch strips '#' in filenames used for Makefile. > > Ready to be installed? > Thanks, > Martin > > gcc/ChangeLog: > > 2020-01-21 Martin Liska > > PR driver/93057 > * lto-wrapper.c (prune_filename_for_make): Prune > characters like '#'. I think this is not en

Re: [PATCH] ipa-profile.c: reset call_sums state within ipa-profile.c (v2; PR 93315)

> > If we do, then, if I understand correctly, this would only affect > someone who tried to use libgccjit to generate .o files with -flto, > repeatedly, within a single process. I don't know of anyone doing > that, and if that's broken, that would be a separate, pre-existing, > bug, I think. Ye

Re: [PATCH] Prune invalid filename due to makefile syntax.

On Jan 21 2020, Martin Liška wrote: > diff --git a/gcc/lto-wrapper.c b/gcc/lto-wrapper.c > index fe8f292f877..f2504cc5b4f 100644 > --- a/gcc/lto-wrapper.c > +++ b/gcc/lto-wrapper.c > @@ -1241,6 +1241,16 @@ jobserver_active_p (void) > && is_valid_fd (wfd)); > } > > +/* Prune invalid char

Re: [PATCH] Prune invalid filename due to makefile syntax.

On 1/21/20 4:15 PM, Andreas Schwab wrote: On Jan 21 2020, Martin Liška wrote: diff --git a/gcc/lto-wrapper.c b/gcc/lto-wrapper.c index fe8f292f877..f2504cc5b4f 100644 --- a/gcc/lto-wrapper.c +++ b/gcc/lto-wrapper.c @@ -1241,6 +1241,16 @@ jobserver_active_p (void) && is_valid_fd (wfd))

[PATCH] PR c++/91476 - anon-namespace reference temp clash between TUs.

The problem in the PR was that make_temporary_var_for_ref_to_temp ran before determine_visibility, so when we copied the linkage of the reference variable it had not yet been restricted by its anonymous namespace context, so the temporary wrongly ended up with TREE_PUBLIC set. The natural solution

Re: [PATCH] PR c++/91476 - anon-namespace reference temp clash between TUs.

On 1/21/20 10:17 AM, Jason Merrill wrote: The problem in the PR was that make_temporary_var_for_ref_to_temp ran before determine_visibility, so when we copied the linkage of the reference variable it had not yet been restricted by its anonymous namespace context, so the temporary wrongly ended up

Re: [PATCH] Relax invalidation of TOP N counters in PGO.

> Ok, after personal discussion with Honza that I had, > we should be more conservative and prune only > a run-time TOP N counters before we merge them. > The patch does that. Can you please Honza test me the patch of Firefox? > > Thanks, > Martin For a record, we ran tests of Firefox. It does no

Re: [PATCH] ipa-profile.c: reset call_sums state within ipa-profile.c (v2; PR 93315)

On Tue, 2020-01-21 at 16:10 +0100, Jan Hubicka wrote: > > If we do, then, if I understand correctly, this would only affect > > someone who tried to use libgccjit to generate .o files with -flto, > > repeatedly, within a single process. I don't know of anyone doing > > that, and if that's broken,

Re: [PATCH, v2] wwwdocs: e-mail subject lines for contributions

On 21/01/2020 15:04, Jakub Jelinek wrote: On Tue, Jan 21, 2020 at 02:52:00PM +, Richard Earnshaw (lists) wrote: [updated, following some comments from Gerald, main differences are slight tweaks to the html markup and changing "email" to "e-mail"] This patch proposes some new (additional)

Re: [PATCH] Prune invalid filename due to makefile syntax.

On 1/21/20 4:08 PM, Jan Hubicka wrote: I think this is not enough - you need to take into consideration all special characters used by make and bash, such as $ and others... Hm, you are right. Do you have a reasonable list which we should support? Or should we leave this known limitation? Mart

Re: [PATCH] ipa-profile.c: reset call_sums state within ipa-profile.c (v2; PR 93315)

> On Tue, 2020-01-21 at 16:10 +0100, Jan Hubicka wrote: > > > If we do, then, if I understand correctly, this would only affect > > > someone who tried to use libgccjit to generate .o files with -flto, > > > repeatedly, within a single process. I don't know of anyone doing > > > that, and if that'

Re: [PATCH v2][AArch64] PR92424: Fix -fpatchable-function-entry=N,M with BTI

Szabolcs Nagy writes: > v2: > - emit bti based on feedback from Richard Sandiford > (dont copy varasm logic). > - add testcases. > - kept bti outside the patch area if possible, i.e. option (b) > in earlier discussion. > > This fix does not update the documentation of the generic > option, I t

Re: [PATCH] Prune invalid filename due to makefile syntax.

> On 1/21/20 4:08 PM, Jan Hubicka wrote: > > I think this is not enough - you need to take into consideration all > > special characters used by make and bash, such as $ and others... > > Hm, you are right. Do you have a reasonable list which we should support? No - I guess one needs to dig into m

Fix updating of call_stmt_site_hash

Hi, this patch fixes ICE causes by call stmt site hash going out of sync. For speculative edges it is assumed to contain a direct call so if we are removing it hashtable needs to be updated. I realize that the code is ugly but I will leave cleanup for next stage1. Bootstrapped/regtested x86_64-l

Re: [PATCH, v2] wwwdocs: e-mail subject lines for contributions

On Tue, Jan 21, 2020 at 03:33:22PM +, Richard Earnshaw (lists) wrote: > > Some examples would be useful I'd say, e.g. it is unclear in what way you > > want the PR number to be appended, shall it be > > something: whatever words describe it PR12345 > > or > > something: whatever words describe

Re: [PATCH, v2] wwwdocs: e-mail subject lines for contributions

On 21/01/2020 15:39, Jakub Jelinek wrote: On Tue, Jan 21, 2020 at 03:33:22PM +, Richard Earnshaw (lists) wrote: Some examples would be useful I'd say, e.g. it is unclear in what way you want the PR number to be appended, shall it be something: whatever words describe it PR12345 or something:

[PATCH] remove bogus asserts in expr.c

If running "make check-gcc" with -mcpu=m68040 you get an internal compiler error during the combine pass in expr.c since there are checks at lines 4107/4108 which seem to be not reasonable. It combines (insn 8 5 9 2 (parallel [ (set (reg:SI 41) (udiv:SI (reg/v:SI 38 [

[committed] aarch64: Fix SVE ACLE handling of SImode pointers

This long-overdue patch promotes SImode pointers to DImode addresses, avoiding various ICEs in the existing tests. Tested on aarch64-linux-gnu and aarch64_be-elf, applied. There are still other ILP32-related ACLE failures to go... Richard 2020-01-21 Richard Sandiford gcc/ * config/

Re: [PATCH] Prune invalid filename due to makefile syntax.

On January 21, 2020 4:37:00 PM GMT+01:00, Jan Hubicka wrote: >> On 1/21/20 4:08 PM, Jan Hubicka wrote: >> > I think this is not enough - you need to take into consideration >all >> > special characters used by make and bash, such as $ and others... >> >> Hm, you are right. Do you have a reasonabl

[committed] aarch64: Use stdint types for SVE ACLE elements

I'd used mode-based element types in the SVE ACLE implementation, but it turns out that they don't correspond to the types used by ILP32 newlib. GCC already knows what the correct types are, I just wasn't using the right interface to find them. A consequence of this is that ILP32 newlib code ne

Re: Fix updating of call_stmt_site_hash

On January 21, 2020 4:37:31 PM GMT+01:00, Jan Hubicka wrote: >Hi, >this patch fixes ICE causes by call stmt site hash going out of sync. >For >speculative edges it is assumed to contain a direct call so if we are >removing it hashtable needs to be updated. I realize that the code is >ugly >but I

Re: [PATCH] Prune invalid filename due to makefile syntax.

On 1/21/20 11:26 AM, Richard Biener wrote: On January 21, 2020 4:37:00 PM GMT+01:00, Jan Hubicka wrote: I would say we want to fix that... Even GCC gets idea to put # info filenames and I am sure except for HHVM there are others. Can't w just quote them somehow? IIUC there are two issues

Re: [PR 80005] __has_include parsing

On Tue, Jan 21, 2020 at 12:22 AM Jakub Jelinek wrote: > I only see one spot where it has been added and then > 2019-06-06 Florian Weimer > > * sysdeps/unix/sysv/linux/riscv/flush-icache.c: Do not use > internal GCC preprocessor identifier __has_include__. > which corrected it to

[PATCH] handle virtual registers inside PLUS - taking an address plus offset

The function instantiate_virtual_regs_in_insn does not handle the case if an address with offset is taken. Then a virtual register may appear (e.g argptr) inside a PLUS. This patch adds the handling for PLUS. Stefan --- a/gcc/function.c +++ b/gcc/function.c @@ -1,5 +1,5 @@ /* Expands

Re: [PATCH, v2] wwwdocs: e-mail subject lines for contributions

On 1/21/20 10:40 AM, Richard Earnshaw (lists) wrote: On 21/01/2020 15:39, Jakub Jelinek wrote: On Tue, Jan 21, 2020 at 03:33:22PM +, Richard Earnshaw (lists) wrote: Some examples would be useful I'd say, e.g. it is unclear in what way you want the PR number to be appended, shall it be some

[GCC][IRA] Revert 11b8091fb to fix Bug 93221

Hi all, A previous change to simplify LRA introduced in 11b809 (From-SVN: r279550) disabled hard register splitting for -O0. This causes a problem on aarch64 in cases where parameters are passed in multiple registers (in the bug report an OI passed in 2 V4SI registers). This is mandated by the

Re: [PATCH][AArch64] PR92424: Fix -fpatchable-function-entry=N,M with BTI

On 2020-01-21, Szabolcs Nagy wrote: On 21/01/2020 11:34, Mark Rutland wrote: Hi Szabolcs, Answers from a linux dev perspective below. thanks. On Mon, Jan 20, 2020 at 10:53:33AM +, Szabolcs Nagy wrote: i have to ask some linux developers which way they prefer: e.g. -fpatchable-function

Re: [patch, fortran] Fix PR 85781, ICE on valid

Hi Tobias, the attached patch fixes an ICE which could occur for empty substrings (see test case). I think one should rather fix the following issue. I am not sure what you mean. Does that mean that fixing the following issue will also fix PR 85781, or that the PR should not be fixed? Rega

Re: [PATCH] RISC-V: Disallow regrenme if the TO register never used before for interrupt functions

On Mon, Jan 20, 2020 at 6:44 PM Kito Cheng wrote: > Thanks, fixed and committed, and it's OK to commit to gcc 8/9 next week? Yes, that is OK with me. Jim

Re: [PATCH] riscv: Fix up riscv_rtx_costs for RTL checking (PR target/93333)

On Tue, Jan 21, 2020 at 12:36 AM Jakub Jelinek wrote: > 2020-01-21 Jakub Jelinek > > PR target/9 > * config/riscv/riscv.c (riscv_rtx_costs) : Verify > the last two operands are CONST_INT_P before using them as such. > > * gcc.c-torture/compile/pr9.c: New

Re: [PATCH, v2] wwwdocs: e-mail subject lines for contributions

On 21/01/2020 17:20, Jason Merrill wrote: On 1/21/20 10:40 AM, Richard Earnshaw (lists) wrote: On 21/01/2020 15:39, Jakub Jelinek wrote: On Tue, Jan 21, 2020 at 03:33:22PM +, Richard Earnshaw (lists) wrote: Some examples would be useful I'd say, e.g. it is unclear in what way you want the

[PATCH] wwwdocs: document scripts to access personal and vendor spaces

This patch documents some of the scripts that I've published for managing the personal and vendor spaces on the server. It also covers some of the other features that those scripts enable, so that it's all in one place. This is a complete rewrite of the material I had written previously since

Re: [PATCH][AArch64] PR92424: Fix -fpatchable-function-entry=N,M with BTI

On 21/01/2020 17:51, Fāng-ruì Sòng via gcc-patches wrote: > The Clang inconvenience is in the other way... > > (My previous Clang patch series do not implement M>0. >  https://reviews.llvm.org/D73070 will add support for M>0.) > > AsmPrinter (assembly printer/object file emitter) does the followi

Re: Fix updating of call_stmt_site_hash

> On January 21, 2020 4:37:31 PM GMT+01:00, Jan Hubicka wrote: > >Hi, > >this patch fixes ICE causes by call stmt site hash going out of sync. > >For > >speculative edges it is assumed to contain a direct call so if we are > >removing it hashtable needs to be updated. I realize that the code is

Re: [GCC][IRA] Revert 11b8091fb to fix Bug 93221

On 1/21/20 12:20 PM, Joel Hutton wrote: Hi all, A previous change to simplify LRA introduced in 11b809 (From-SVN: r279550) disabled hard register splitting for -O0. This causes a problem on aarch64 in cases where parameters are passed in multiple registers (in the bug report an OI passed in 2 V4

Re: [PATCH] PR target/93319: x32: Add x32 support to -mtls-dialect=gnu2

On Tue, Jan 21, 2020 at 2:29 AM Uros Bizjak wrote: > > On Tue, Jan 21, 2020 at 9:47 AM Uros Bizjak wrote: > > > > On Mon, Jan 20, 2020 at 10:46 PM H.J. Lu wrote: > > > > > > > OK. Let's go with this version, but please investigate if we need to > > > > > calculate TLS address in ptr_mode instead

Re: [PATCH, v2] wwwdocs: e-mail subject lines for contributions

Hi! Thanks for doing this. On Tue, Jan 21, 2020 at 02:52:00PM +, Richard Earnshaw (lists) wrote: > This patch proposes some new (additional) rules for email subject lines > when contributing to GCC. The goal is to make sure that, as far as > possible, the subject for a patch will form a good

Re: [GCC][IRA] Revert 11b8091fb to fix Bug 93221

On Tue, Jan 21, 2020 at 05:20:51PM +, Joel Hutton wrote: > 2020-01-21  Joel Hutton  > >     * ira.c (ira): Revert use of simplified LRA algorithm. > > gcc/testsuite/ChangeLog: > > 2020-01-21  Joel Hutton  > >     PR bug/93221 >     * gcc.target/aarch64/pr93221.c: New test.

[committed, obvious] Fix line terminator pattern in testcase.

I observed this testcase was failing on nios2-elf. The more general regexp was copied from other tests using dg-output. 2020-01-21 Sandra Loosemore gcc/testsuite/ * g++.dg/coroutines/torture/mid-suspend-destruction-0.C: Generalize line terminators in patterns. --- gcc

Re: [PATCH] Relax invalidation of TOP N counters in PGO.

On 1/21/20 4:27 PM, Jan Hubicka wrote: If distro build takes seriously FDO and reproducibility it will eventually run into the limitation for single-threaded programs and we will need to do reproducible runs for multithread apps which means putting indirect call profiles into thread local storage

Re: [GCC][IRA] Revert 11b8091fb to fix Bug 93221

On 21/01/2020 19:26, Jakub Jelinek wrote: > Not a review, just nitpicking. Please avoid the backslash before >. > The PR number should go to both gcc/ and gcc/testsuite/ ChangeLog > entry and we don't have bug/ category; the bug is target category, > so it should be PR target/93221, or could be re

Re: [GCC][IRA] Revert 11b8091fb to fix Bug 93221

Updated changelog: Changelog: 2020-01-21 Joel Hutton PR target/93221 * ira.c (ira): Revert use of simplified LRA algorithm. gcc/testsuite/ChangeLog: 2020-01-21 Joel Hutton PR target/93221 * gcc.targe

Re: [GCC][IRA] Revert 11b8091fb to fix Bug 93221

Changelog was mangled by thunderbird, updated changelog: Changelog: 2020-01-21 Joel Hutton PR target/93221 * ira.c (ira): Revert use of simplified LRA algorithm. gcc/testsuite/ChangeLog: 2020-01-21 Joel Hutton PR target/93221 * gcc.target/aarch64/

Re: [PATCH] PR target/93319: x32: Add x32 support to -mtls-dialect=gnu2

On Tue, Jan 21, 2020 at 8:16 PM H.J. Lu wrote: > > On Tue, Jan 21, 2020 at 2:29 AM Uros Bizjak wrote: > > > > On Tue, Jan 21, 2020 at 9:47 AM Uros Bizjak wrote: > > > > > > On Mon, Jan 20, 2020 at 10:46 PM H.J. Lu wrote: > > > > > > > > > OK. Let's go with this version, but please investigate i

Home care Centers

Hi, Just wanted to check your interest in acquiring the records of Home care Centers/Agencies. If you are interested please let me know your target Geography, so that I can revert with further information on counts and pricing. Thank you and I look forward for your response. Regards

[COMMITTED] PR c++/90732 - ICE with VLA capture and generic lambda.

We were failing to handle VLA capture in tsubst_lambda_expr; initially building a DECLTYPE_TYPE for the capture and then tsubsting it doesn't give the special VLA handling. So with this patch we call add_capture again for VLAs. Tested x86_64-pc-linux-gnu, applying to trunk. * pt.c (tsubs

[COMMITTED] PR c++/60855 - ICE with sizeof VLA capture.

For normal captures we usually look through them within unevaluated context, but that doesn't work here; trying to take the sizeof of the array in the enclosing scope tries and fails to evaluate a SAVE_EXPR from the enclosing scope. Tested x86_64-pc-linux-gnu, applying to trunk. * lambda.

[patch, testsuite] Add -fdelete-null-pointer-checks to some C++ testcases

In doing some nios2-elf testing, I ran into a bunch of failures in constexpr-related tests in the C++ testsuite. This target defaults to -fno-delete-null-pointer-checks at the request of Altera/Intel, in order to support some of their BSPs where 0 is a legitimate memory address. Some other bar

[PATCH] libstdc++: Always return a sentinel from __gnu_test::test_range::end()

It seems that in practice std::sentinel_for is always true, and so the test_range container doesn't help us detect bugs in ranges code in which we wrongly assume that a sentinel can be manipulated like an iterator. Make the test_range container more strict by having end() unconditionally return a

testsuite: More uses of effective-target march_option for cris

gcc/testsuite: * gcc.target/cris/asm-v8.S, gcc.target/cris/inasm-v8.c, gcc.target/cris/sync-1.c: Apply effective_target_march_option. Oops. A few stragglers, same as recent update: differing -march=... options is an error, noticed with e.g. "make check RUNTESTFLAGS=--target_board=

[PATCH] RISC-V: Fix rtl checking enabled failure with -msave-restore.

Found with an rtl checking enabled build and check. This triggered failures in the gcc.target/riscv/save-restore* tests. We are using XINT to access an XWINT value; INTVAL is the preferred solution. Since existing tests trigger it we don't need a new one. Tested with riscv32-elf and riscv64-lin

Re: [patch] contrib: script to create a new vendor branch

> From: "Richard Earnshaw (lists)" > Date: Tue, 21 Jan 2020 14:36:32 +0100 > Correction, the branch should be named /, so the push > should be > > git push vendors/ / > > For example, for the ARM vendor, the push would be > > git push vendors/ARM ARM/ > > R. > > > will work as expected. > >

[COMMITTED] analyzer: fix qsort issue with array_region keys (PR 93352)

PR analyzer/93352 reports a qsort failure "comparator not anti-symmetric: -2147483648, -2147483648)" within the analyzer on code involving an array access of [0x7fff + 1]. The issue is that array_region (which uses int for keys into known values in the array) uses subtraction to implement in

tolerate padding in mbstate_t

Padding in mbstate_t objects may get the memcmp to fail. Attempt to avoid the failure with zero initialization. Regstrapped on x86_64-linux-gnu, and also tested on a platform that used to fail because of padding in std::mbstate_t. Ok to install? for libstdc++-v3/ChangeLog * testsui

Re: Define HAVE_ for math long double functions declared in vxworks headers

On Jan 3, 2020, Jonathan Wakely wrote: >> +#include >> +#ifdef HAVE_IEEEFP_H >> +# include >> +#endif >> +], [ >> + void (*f)(void) = (void (*)(void))$1; > I wondered whether using ($1) here instead of just $1 would give any > benefit. It would mean that function-like macros are ignored. Th

Re: tolerate padding in mbstate_t

On 21/01/20 21:36 -0300, Alexandre Oliva wrote: Padding in mbstate_t objects may get the memcmp to fail. Attempt to avoid the failure with zero initialization. Regstrapped on x86_64-linux-gnu, and also tested on a platform that used to fail because of padding in std::mbstate_t. Ok to install?

  1   2   >