Re: drop -aux{dir,base}, revamp -dump{dir,base}

On Tue, 21 Jan 2020, Alexandre Oliva wrote: > On Jan 20, 2020, Richard Biener wrote: > > > On Thu, 16 Jan 2020, Alexandre Oliva wrote: > > >> Here it is, at last, regstrapped on x86_64-linux-gnu. Ok to install? > > > I'm hesitant to approve it now since we're in stage4 and been too > > permis

libgo patch committed: Update to Go1.14beta1

I've committed a patch to update libgo to Go 1.14beta1. As usual with these updates the patch is far too large to include in this e-mail message. I've included the diffs for gccgo-specific files. Bootstrapped and ran Go tests on x86_64-pc-linux-gnu. Committed to mainline. Ian gotools/ChangeLog

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

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

[cris-decc0 9/9] testsuite: cris: xfail parts of gcc.target/cris/sync-2i.c, sync-2s.c

PR target/93372 * gcc.target/cris/sync-2s.c, gcc.target/cris/sync-2i.c: XFAIL. Unfortunately, some assembly-code-matches have to be xfailed until the port is improved to use other than straight compare-insns. --- gcc/testsuite/gcc.target/cris/sync-2i.c | 5 +++-- gcc/testsuite/gcc.target/cris/syn

[cris-decc0 7/9] gcc/config/cris: Remove shared-library and CRIS v32 support.

gcc: * config/cris: Remove shared-library and CRIS v32 support. Part of the removal of crisv32-* and cris-*-linux* (cris-elf remains). Essentially everything is gone, including functions and target-specific definitions and most obvious knock-on effects, like removing unused functions and argument

[cris-decc0 6/9] config/cris/t-elfmulti: Remove crisv32 multilib.

gcc: * config/cris/t-elfmulti: Remove crisv32 multilib. Part of the removal of crisv32-* and cris-*-linux* (cris-elf remains). --- gcc/config/cris/t-elfmulti | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/gcc/config/cris/t-elfmulti b/gcc/config/cris/t-elfmulti index 3c

[cris-decc0 5/9] gcc/testsuite: Remove traces of crisv32-* outside gcc.target/cris

testsuite: * gcc.dg/20020919-1.c, gcc.dg/pr31866.c, gcc.dg/pr46647.c, gcc.dg/sibcall-10.c, gcc.dg/sibcall-3.c, gcc.dg/sibcall-4.c, gcc.dg/sibcall-9.c, gcc.dg/torture/cris-asm-mof-1.c, gcc.dg/torture/cris-volatile-1.c, gcc.dg/torture/pr38948.c, gcc.dg/tree-ssa/20040204-1.c, gcc.dg/tree-ssa/loop-1.c,

[cris-decc0 4/9] gcc/testsuite: gcc.target/cris: Remove crisv32-* and cris-linux-* tests.

testsuite: * gcc.target/cris/: Adjust for removing crisv32-* and cris-linux-*. Part of the removal of crisv32-* and cris-*-linux* (cris-elf remains). After this, within gcc.target, grep -i v32 and grep -i linux finds no matches, except for a comment in gcc.target/cris/asmreg-1.c, now grammar-corre

[cris-decc0 3/9] libgcc: cris: Remove support for crisv32-*-* and cris*-*-linux

libgcc: * config.host: Remove support for crisv32-*-* and cris*-*-linux. * config/cris/libgcc-glibc.ver, config/cris/t-linux: Remove. Part of the removal of crisv32-* and cris-*-linux* (cris-elf remains). --- libgcc/config.host | 9 - libgcc/config/cris/libgcc-glibc.ver |

[cris-decc0 2/9] gcc: cris: Remove from gcc/config/cris: t-linux, linux.h, linux.opt

gcc: * config/cris/t-linux, config/cris/linux.h, config/cris/linux.opt: Remove. Part of the removal of crisv32-* and cris-*-linux* (cris-elf remains). --- gcc/config/cris/linux.h | 150 -- gcc/config/cris/linux.opt | 33 -- gcc/config/cris/t-

[cris-decc0 1/9] config.gcc: Remove support for crisv32-*-* and cris-*-linux*.

gcc: * config.gcc: Remove support for crisv32-*-* and cris-*-linux*. Or really, move from the obsolete targets section, to unsupported targets section, and remove crisv32-*-* and cris-*-linux* from the rest. --- gcc/config.gcc | 28 ++-- 1 file changed, 2 insertions(+), 26

[0/9] simplification and decc0ration of CRIS port

This patchset is applied to vendors/axis/cris-decc0. The intent is to apply it myself to master, once master opens for stage 1, before the planned destruction of cc0 targets that was announced last September. I've earlier obsoleted the crisv32-* and cris-*-linux* sub-ports as no longer relevant (

Re: [C++ PATCH] PR c++/92907 - noexcept does not consider "const" in member functions.

On 1/21/20 9:08 PM, Marek Polacek wrote: Here the problem is that if the noexcept specifier is used in the context of a const member function, const is not considered for the member variables, leading to a bogus error. g's const makes its 'this' const, so the first overload of f should be select

[C++ PATCH] PR c++/92907 - noexcept does not consider "const" in member functions.

Here the problem is that if the noexcept specifier is used in the context of a const member function, const is not considered for the member variables, leading to a bogus error. g's const makes its 'this' const, so the first overload of f should be selected. In cp_parser_noexcept_specification_op

Re: tolerate padding in mbstate_t

On Jan 21, 2020, Jonathan Wakely wrote: > 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 >

Re: [C++ PATCH v2] PR c++/93324 - ICE with -Wall on constexpr if.

On 1/19/20 4:18 PM, Marek Polacek wrote: On Sun, Jan 19, 2020 at 10:00:42PM +0100, Jakub Jelinek wrote: On Sun, Jan 19, 2020 at 03:34:48PM -0500, Marek Polacek wrote: Bootstrapped/regtested on x86_64-linux, ok for trunk? * semantics.c (is_std_constant_evaluated_p): Check fndecl.

Re: [PATCH] Fix a couple of memory leaks in the C++ frontend

On 1/20/20 8:06 PM, Patrick Palka wrote: 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. Hmm, perhaps vec should static_assert __is_trivial(T) when supported. @@ -15344,6

[PATCH] Allow tree-ssa.exp to be run by itself

From: Andrew Pinski tree-ssa testcases sometimes check autovect effective target but does not set it up. On MIPS, those testcases fail with some TCL error messages. This fixes the issue by calling check_vect_support_and_set_flags inside tree-ssa.exp. There might be other .exp files which need t

Update update_web_docs_svn references in sourcebuild.texi

These needed updating after the replacement of update_web_docs_svn by update_web_docs_git. Committed. 2020-01-22 Joseph Myers * doc/sourcebuild.texi (Texinfo Manuals, Front End): Refer to update_web_docs_git instead of update_web_docs_svn. diff --git a/gcc/doc/sourcebuild.tex

[PATCH] Fix target/93119 (aarch64): ICE with traditional TLS support on ILP32

From: Andrew Pinski This is what I committed after Richard's comments. 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

Fix ICE with cast of division by zero (PR c/93348)

Bug 93348 reports an ICE on certain cases of casts of expressions that may appear only in unevaluated parts of integer constant expressions, arising from the generation of nested C_MAYBE_CONST_EXPRs. This patch fixes it by adding a call to remove_c_maybe_const_expr in the integer-operands case, as

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

On Tue, 21 Jan 2020, Richard Biener wrote: > Second. Fact is RTL does not distinguish between pointers and > integers and thus any attempt to make something valid when you > use integers and invalid when you use pointers is not going to work. That simply means that an earlier stage in the compil

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

On Tue, 21 Jan 2020, Alexander Monakov wrote: > My intent was more basic. I observed that the paragraph can be interpreted as > saying that if you have a cast 'I1 = (intptr_t) P1', then perform some > computations on I1 that do not in any way depend on values of other pointers, > then casting the

Re: drop -aux{dir,base}, revamp -dump{dir,base}

On Jan 20, 2020, Richard Biener wrote: > On Thu, 16 Jan 2020, Alexandre Oliva wrote: >> Here it is, at last, regstrapped on x86_64-linux-gnu. Ok to install? > I'm hesitant to approve it now since we're in stage4 and been too > permissive already. So ... > OK for GCC 11. Thanks, that sounds

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?

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

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

[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

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. > >

[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

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] 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

[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

[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.

[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

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

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

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: [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

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: [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

[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: [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.

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: [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: [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: 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: [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

[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, 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

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] 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, 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][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

[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, 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

[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: [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

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: 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

[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: [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: 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/

[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 [

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:

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

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] 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

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] 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] 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, 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] 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] 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] 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

[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] 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))

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] 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.

> 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

[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, 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

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

[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

[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] 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, 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

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

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 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][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

[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] 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] 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] 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

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] 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,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

[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 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

  1   2   >