Re: [patch] move value_range_equiv class to own file

On Mon, May 18, 2020 at 8:13 PM Aldy Hernandez via Gcc-patches wrote: > > We already moved the value_range class into its own class in the last > release. I think it's time to move the value_range_equiv stuff into its > own class, as it's a distraction from the VRP code. > > I've moved it to valu

Re: [patch] move array bounds checking into its own file

On Mon, May 18, 2020 at 8:21 PM Aldy Hernandez via Gcc-patches wrote: > > As a follow-up to the patch moving array bounds checking into its own > class, this moves the class into its own files. As I've mentioned > previously, having it in tree-vrp just pollutes the file with unrelated > stuff. >

Re: [PATCH][RFC] enfoce SLP_TREE_VECTYPE on invariants

On Mon, 18 May 2020, Richard Sandiford wrote: > Richard Biener writes: > > Hi, > > > > I'm trying to enforce SLP_TREE_VECTYPE being set (correctly) on > > external and invariant SLP nodes to avoid (re-)computing that > > in other places. > > Nice. > > > The responsible entity for specifying the

[RFC PATCH] i386: Add missing vector zero/sign_extend expanders [PR92658]

Hello! Attached patch adds missing vector zero/sign_extend expanders to allow vectorization of operations between different vector sizes. The patch regresses (progresses?): FAIL: gcc.target/i386/pr92645-4.c scan-tree-dump-times optimized "vec_unpack_lo" 3 but eyeballing the asm code before/afte

Re: [PATCH] Fortran : ICE in gfc_trans_label_assign PR50392

Messed up the e-mail addressed, gcc-patches now added. Also, I note that I missed the PR fortran/50392 which should be inserted at the start of the change log entries. On 19/05/2020 08:49, Mark Eggleston wrote: Please find attached patch for PR50392. This patch was extracted from the comment

Re: [PATCH] Fortran : ProcPtr function results: 'ppr@' in error message PR39695

Am 18.05.20 um 09:35 schrieb Mark Eggleston: > Please find attached a patch for PR39695 (this time it is attached). > > Commit message: > > Fortran  : ProcPtr function results: 'ppr@' in error message PR39695 > > The value 'ppr@' is set in the name of result symbol, the actual > name of the symbol

Re: New mklog script

On 5/15/20 5:06 PM, Martin Sebor wrote: On 5/15/20 2:59 AM, Martin Liška wrote: Hi. Since we moved to git world and we're in the preparation for ChangeLog messages being in git commit messages, I think it's the right time to also simplify mklog script. I'm sending a new version (which should e

Re: New mklog script

On Tue, May 19, 2020 at 10:11:28AM +0200, Martin Liška wrote: > > I find this format more helpful for the reasons below so unless your > > script can be tweaked to do something similar I'd like to be able to > > continue to use mine going forward with the new infrastructure. > > Let's extend the c

openmp: Add basic library allocator support

Hi! This patch adds very basic allocator support (omp_{init,destroy}_allocator, omp_{alloc,free}, omp_[sg]et_default_allocator). The plan is to use memkind (likely dlopened) for high bandwidth memory, but that part isn't implemented yet, probably mlock for pinned memory and see what other options

Re: testsuite: clarify scan-dump file globbing behavior

Hi Thomas, Thomas Schwinge writes: > I can't formally approve testsuite patches, but did a review anyway: Thanks for the review! > On 2020-05-15T12:31:54+0200, Frederik Harwath > wrote: >> The dump >> scanning procedures are changed to make the test unresolved >> if globbing matches more th

Re: [RFC PATCH] i386: Add missing vector zero/sign_extend expanders [PR92658]

On Tue, 19 May 2020, Uros Bizjak wrote: > Hello! > > Attached patch adds missing vector zero/sign_extend expanders to allow > vectorization of operations between different vector sizes. > > The patch regresses (progresses?): > > FAIL: gcc.target/i386/pr92645-4.c scan-tree-dump-times optimized >

Re: [PATCH] x86: Add cmpmemsi for -mgeneral-regs-only

On Sun, May 17, 2020 at 7:06 PM H.J. Lu wrote: > > Duplicate the cmpstrn pattern for cmpmem. The only difference is that > the length argument of cmpmem is guaranteed to be less than or equal to > lengths of 2 memory areas. Since "repz cmpsb" can be much slower than > memcmp function implemented

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

I've refreshed the patch, approved back on Jan 22 for gcc-11, in refs/users/aoliva/heads/aux-dump-revamp, and committed 3 other related patches on top of it, that I hope to get approved for folding and joint installation: - fix a build problem when targeting platforms with an executable suffix -

Re: New mklog script

On 5/19/20 10:11 AM, Martin Liška wrote: Can you please share how do you do it? It would be easy to add it. I added the feature via --fill-up-bug-titles option. It uses common request and beatifulsoup packages. Martin >From 5450c99b54131d1942ece3ffb6bbe415b1c85151 Mon Sep 17 00:00:00 2001 From

Re: New mklog script

On 5/19/20 10:23 AM, Jakub Jelinek wrote: On Tue, May 19, 2020 at 10:11:28AM +0200, Martin Liška wrote: I find this format more helpful for the reasons below so unless your script can be tweaked to do something similar I'd like to be able to continue to use mine going forward with the new infras

Re: [RFC PATCH] i386: Add missing vector zero/sign_extend expanders [PR92658]

On Tue, May 19, 2020 at 10:48 AM Richard Biener wrote: > > On Tue, 19 May 2020, Uros Bizjak wrote: > > > Hello! > > > > Attached patch adds missing vector zero/sign_extend expanders to allow > > vectorization of operations between different vector sizes. > > > > The patch regresses (progresses?):

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

On May 19, 2020, Alexandre Oliva wrote: > - fix spurious outputs.exp test failures on targets that do not support > -gsplit-dwarf cope with -gsplit-dwarf errors From: Alexandre Oliva On targets that did not support -gsplit-dwarf, we'd get tons of spurious failures. This patch tests for sup

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

On May 19, 2020, Alexandre Oliva wrote: > - fix a build problem when targeting platforms with an executable suffix aux and dump revamp: fix target exec suffix handling HAVE_TARGET_EXECUTABLE_SUFFIX is defined only in gcc.c, and in a way that requires testing whether it's defined, rather than fo

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

On May 19, 2020, Alexandre Oliva wrote: > - fix for outputs.exp for platforms with nonempty ldflags, libs, > ldscripts, or output_format in the dejagnu board configuration, and > for link tests with aux dumps in the testsuite when ldflags, libs or > ldscripts in the board config name files

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

On Tue, 19 May 2020, Alexandre Oliva wrote: > I've refreshed the patch, approved back on Jan 22 for gcc-11, in > refs/users/aoliva/heads/aux-dump-revamp, and committed 3 other related > patches on top of it, that I hope to get approved for folding and joint > installation: Thanks again for doing

Re: [PATCH] Fortran : ProcPtr function results: 'ppr@' in error message PR39695

On 19/05/2020 09:08, Manfred Schwarb wrote: Am 18.05.20 um 09:35 schrieb Mark Eggleston: Please find attached a patch for PR39695 (this time it is attached). Commit message: Fortran  : ProcPtr function results: 'ppr@' in error message PR39695 The value 'ppr@' is set in the name of result sy

[PATCH] testsuite: Match ASCII color code for ubsan's test pattern.

Run gcc testsuite with qemu will print out ascii color code like that: ^[[1mc-c++-common/ubsan/builtin-1.c:11:10:^[[1m^[[31m runtime error: ^[[1m^[[0m^[[1mpassing zero to ctz(), which is not a valid argument^[[1m^[[0m^M But the match logic in some testcase e.g c-c++-common/ubsan/builtin-1.c, did

Re: collect2.exe errors not pruned

Hello, Joseph, Andrew, Thanks for your feedback. On Feb 28, 2020, Joseph Myers wrote: > On Fri, 28 Feb 2020, Alexandre Oliva wrote: >> I'm not sure it's appropriate for the error to not omit the host >> platform's executable suffix, just as it omits directory components from >> argv[0], so I'm

Re: [PATCH] x86: Move cpuinfo.h from libgcc to common/config/i386

Am 19.05.20 um 04:16 schrieb H.J. Lu via Fortran: Tested on Linux/x86 and Linux/x86-64. OK for master? Libfortran parts are OK. Regards Thomas

Re: [PATCH] testsuite: Match ASCII color code for ubsan's test pattern.

On Tue, May 19, 2020 at 05:13:39PM +0800, Kito Cheng wrote: > Run gcc testsuite with qemu will print out ascii color code like that: > > ^[[1mc-c++-common/ubsan/builtin-1.c:11:10:^[[1m^[[31m runtime error: > ^[[1m^[[0m^[[1mpassing zero to ctz(), which is not a valid > argument^[[1m^[[0m^M > > B

Re: [PATCH] Describe coding conventions surrounding "auto"

Martin Sebor writes: >> By way of a random example from genrecog.c: >> >>int_set::iterator end >> = std::set_union (trans1->labels.begin (), trans1->labels.end >> (), >> combined->begin (), combined->end (), >>

Re: ChangeLog files - server and client scripts

Hello. We've just installed server git hooks that verify git messages for a correct ChangeLog format. For a limited time period, please still apply ChangeLog changes to the corresponding ChangeLog files. We'll use it for comparison of auto-generated CangeLog entries. The format is documented her

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

On Tue, 19 May 2020, Alexandre Oliva wrote: > On May 19, 2020, Alexandre Oliva wrote: > > > - fix a build problem when targeting platforms with an executable suffix > > aux and dump revamp: fix target exec suffix handling > > HAVE_TARGET_EXECUTABLE_SUFFIX is defined only in gcc.c, and in a way

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

On Tue, 19 May 2020, Alexandre Oliva wrote: > On May 19, 2020, Alexandre Oliva wrote: > > > - fix spurious outputs.exp test failures on targets that do not support > > -gsplit-dwarf > > cope with -gsplit-dwarf errors > > From: Alexandre Oliva > > On targets that did not support -gsplit-dwa

Re: [PATCH] Describe coding conventions surrounding "auto"

On 5/18/20 6:51 PM, Martin Sebor via Gcc-patches wrote: On 5/18/20 12:02 PM, Richard Sandiford wrote: Martin Sebor writes: On 5/16/20 4:43 AM, Richard Sandiford wrote: Sorry for the empty subject line earlier... Jason Merrill writes: On Fri, May 15, 2020 at 9:47 PM Martin Sebor wrote:

Re: New mklog script

On 5/19/20 10:53 AM, Martin Liška wrote: On 5/19/20 10:11 AM, Martin Liška wrote: Can you please share how do you do it? It would be easy to add it. I added the feature via --fill-up-bug-titles option. It uses common request and beatifulsoup packages. Martin Ok, I'm going to install the fol

[PATCH] contrib/gcc-changelog: Handle Reviewed-{by,on}

Hi, the new contrib/gcc-changelog/git_check_commit.py script (which, by the way, is very useful!) does not handle "Reviewed-by" and "Reviewed-on" lines yet and hence it expects those lines to be indented by a tab although those lines are usually not indented. The script already knows about "Co-Auth

Re: [PATCH] testsuite: Match ASCII color code for ubsan's test pattern.

Hi Jakub: > s/Ditoo/Ditto/g Thank for catching that. > I think I'd prefer instead exporting some env var for all the ubsan > tests in ubsan.exp that would disable the colorization. Sounds like it's a better solution, it seems like it can be disable by UBSAN_OPTIONS=color=never, I'll try and send

Re: [PATCH] contrib/gcc-changelog: Handle Reviewed-{by,on}

On 5/19/20 11:45 AM, Frederik Harwath wrote: Hi, the new contrib/gcc-changelog/git_check_commit.py script (which, by the way, is very useful!) does not handle "Reviewed-by" and "Reviewed-on" lines yet and hence it expects those lines to be indented by a tab although those lines are usually not in

[PATCH][WIP] enfoce SLP_TREE_VECTYPE a bit

So I came up with this, yet another overload of vect_is_simple_use (ick). But at least for the two functions I tackled it seems to be straight-forward. I'll see to enforce a type on all invariants in vect_get_constant_vectors and thus try to adjust all other vectorizable_* (but I'm sure I'll mis

[COMMITTED 0/2][BPF] Introduce -mxbpf and first extension

Hi people! I just committed these two BPF-specific small patches. See each commit for a description. Hope I didn't screw up with the ChangeLog entries in the commit message! :) Salud! Jose E. Marchesi (2): bpf: add support for the -mxbpf option bpf: do not save/restore callee-saved registe

[COMMITTED 2/2] bpf: do not save/restore callee-saved registers in function prolog/epilog

BPF considers that every call to a function allocates a fresh set of registers that are available to the callee, of which the first five may have bee initialized with the function arguments. This is implemented by both interpreter and JIT in the Linux kernel. This is enforced by the kernel BPF ve

[COMMITTED 1/2] bpf: add support for the -mxbpf option

This patch adds support for a new option -mxbpf. This tells GCC to generate code for an expanded version of BPF that relaxes some of the restrictions imposed by BPF. 2020-05-19 Jose E. Marchesi gcc/ * config/bpf/bpf.opt (mxbpf): New option. * doc/invoke.texi (Option Summary):

[PATCH][OBVIOUS] Fill up entries in reverse order.

Hi. Older entries should be added first. Installed. contrib/ChangeLog: * gcc-changelog/git_update_version.py: Fill up entries in reverse order. --- contrib/gcc-changelog/git_update_version.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contrib/gcc-chan

Re: [PATCH][WIP] enfoce SLP_TREE_VECTYPE a bit

Richard Biener writes: > So I came up with this, yet another overload of vect_is_simple_use (ick). > But at least for the two functions I tackled it seems to be straight-forward. > > I'll see to enforce a type on all invariants in vect_get_constant_vectors > and thus try to adjust all other vector

Re: [PATCH][WIP] enfoce SLP_TREE_VECTYPE a bit

On Tue, 19 May 2020, Richard Sandiford wrote: > Richard Biener writes: > > So I came up with this, yet another overload of vect_is_simple_use (ick). > > But at least for the two functions I tackled it seems to be > > straight-forward. > > > > I'll see to enforce a type on all invariants in vect_

[PATCH] mklog.py: improve parsing of struct names (ignore GTY).

Hi. It's a small tweak to the newly added script. Installed. Martin * mklog.py: Skip GTY for struct names. Make flake8 happy. * test_mklog.py: Add test for GTY. --- contrib/ChangeLog | 5 + contrib/mklog.py | 12 contrib/test_mklog.py | 29 +

Re: openmp: Add basic library allocator support

On Tue, May 19, 2020 at 1:27 AM Jakub Jelinek via Gcc-patches wrote: > > Hi! > > This patch adds very basic allocator support (omp_{init,destroy}_allocator, > omp_{alloc,free}, omp_[sg]et_default_allocator). > The plan is to use memkind (likely dlopened) for high bandwidth memory, but > that part

Re: [PATCH][PPC64] [PR88877]

can someone look at the patch, please? On Wed, Apr 8, 2020 at 9:29 PM Jeff Law wrote: > On Mon, 2020-04-06 at 14:58 +0530, kamlesh kumar via Gcc-patches wrote: > > Hi Richard, > > Here is a discussion we did some time ago > > https://gcc.gnu.org/pipermail/gcc/2019-January/227834.html > > please

Re: openmp: Add basic library allocator support

On Tue, May 19, 2020 at 04:56:51AM -0700, H.J. Lu wrote: > > 2020-05-19 Jakub Jelinek > > > > * omp.h.in (omp_uintptr_t): New typedef. > > (__GOMP_UINTPTR_T_ENUM): Define. > > (omp_memspace_handle_t, omp_allocator_handle_t, > > omp_alloctrait_key_t, > > omp_alloc

[PATCH] x86: Add cmpmemsi for -minline-all-stringops

On Tue, May 19, 2020 at 1:48 AM Uros Bizjak wrote: > > On Sun, May 17, 2020 at 7:06 PM H.J. Lu wrote: > > > > Duplicate the cmpstrn pattern for cmpmem. The only difference is that > > the length argument of cmpmem is guaranteed to be less than or equal to > > lengths of 2 memory areas. Since "r

Re: [PATCH] Fix component mappings with derived types for OpenACC

Hi! On 2020-01-28T13:41:00+, Julian Brown wrote: > On Fri, 24 Jan 2020 10:58:49 +0100 > Tobias Burnus wrote: >> the gfortran part is rather obvious and it and the test case look >> fine to me → OK. >> The oacc-mem.c also looks okay, but I assume Thomas needs to >> rubber-stamp it. > > I unde

Re: [PATCH] tsan: Add optional support for distinguishing volatiles

On 5/18/20 1:52 PM, Dmitry Vyukov via Gcc-patches wrote: Jakub, could you please give some update. Do we just wait? That's fine, just want to understand because there are some interesting discussions in the kernel re bumping compiler requirements. Thanks Hello. We switched to stage1 and we're

Re: [PATCH] Fortran : ProcPtr function results: 'ppr@' in error message PR39695

Hi Mark, On 5/18/20 9:35 AM, Mark Eggleston wrote: Please find attached a patch for PR39695 (this time it is attached). Looks okay – with the "dg-(do )compile" change as remarked by Manfred. [I did wonder whether BLOCK could cause problems with ns->proc_name, but I couldn't come up with a cas

[PR 95182] ICE with EOF in macro args

This was another latent case of us losing an EOF token, but succeeding anyway. Since my patch to make us pay more attention to EOFs it came to light. We also need to keep the EOF if we fall off the end of the main file. Forced includes look like regular nested includes at this point. pushed

Re: [PATCH] s390: Fix up -Wpsabi diagnostcs + analysis [PR94704]

On Tue, Apr 28, 2020 at 02:13:02PM +0200, Jakub Jelinek wrote: > struct X { }; > struct Y { int : 0; }; > struct Z { int : 0; Y y; }; > struct U : public X { X q; }; > struct A { double a; }; > struct B : public X { double a; }; > struct C : public Y { double a; }; > struct D : public Z { double a

gcc/testsuite/go: increase memory in issue4085b.go

Description: On aix/ppc64, it's possible to allocate an array of 1<<50 int, because of the wider address space. Thus, increase it to 1<<59 like in Golang toolchain in order to trigger the panic. Changelog: 2020-05-19 Clement Chigot * go.test/test/fixedbugs/issue4085b.go: increase the siz

'gomp_map_vars' locking protocol (was: [OpenACC] Update OpenACC data clause semantics to the 2.5 behavior - runtime)

Hi Jakub, Julian! Can you please help me understand the following: On 2018-06-19T10:01:20-0700, Cesar Philippidis wrote: > This patch implements the OpenACC 2.5 data clause semantics in libgomp. (This got committed as r261813, 2018-06-20. The code has seen some changes in the mean time, but th

Re: [PATCH] c++: Implement DR 2289, Uniqueness of structured binding names [PR94553]

On 5/18/20 5:07 PM, Marek Polacek wrote: On Mon, May 18, 2020 at 04:50:44PM -0400, Jason Merrill via Gcc-patches wrote: On 5/13/20 12:22 PM, Marek Polacek wrote: DR 2289 clarified that since structured bindings have no C compatibility implications, they should be unique in their declarative reg

Re: New mklog script

Hello, On Tue, 19 May 2020, Martin Liška wrote: > > The common problems I remember is that e.g. when changing a function comment > > above some function, it is attributed to the previous function rather than > > following, labels in function confusing it: > > void > > foo () > > { > > .

[Patch, fortran] PR fortran/66833,67938,95214 ICE on using assumed rank character array

Hi all! Proposed patch to PRs 66833, 67938 and 95214 ICE(s) on using assumed rank character array in different situations. Patch tested only on x86_64-pc-linux-gnu. Simple patch only add assumed-rank to the list of possible attributes. Thank you very much. Best regards, José Rui 2020-5-19

Re: [PATCH 02/13] OpenACC reference count overhaul

Hi Julian! On 2019-12-17T22:02:27-0800, Julian Brown wrote: > --- a/libgomp/oacc-mem.c > +++ b/libgomp/oacc-mem.c > @@ -571,14 +570,16 @@ present_create_copy (unsigned f, void *h, size_t s, int > async) > >goacc_aq aq = get_goacc_asyncqueue (async); > > - tgt = gomp_map_vars_async

Re: [PATCH 02/13] OpenACC reference count overhaul

Hi Julian! On 2019-12-17T22:02:27-0800, Julian Brown wrote: > --- a/libgomp/oacc-mem.c > +++ b/libgomp/oacc-mem.c (Unhelpful diff trimmed.) > +/* Some types of (pointer) variables use several consecutive mappings, which > + must be treated as a group for enter/exit data directives. This func

Re: New mklog script

On Tue, 19 May 2020, Martin Liška wrote: > On 5/19/20 10:11 AM, Martin Liška wrote: > > Can you please share how do you do it? It would be easy to add it. > > I added the feature via --fill-up-bug-titles option. It uses common > request and beatifulsoup packages. The REST interface is much bette

Re: [PATCH 02/13] OpenACC reference count overhaul

Hi Julian! On 2019-12-17T22:02:27-0800, Julian Brown wrote: > --- a/libgomp/oacc-mem.c > +++ b/libgomp/oacc-mem.c (Unhelpful diff trimmed.) > +/* Unmap variables for OpenACC "exit data", with optional finalization > + (affecting all mappings in this operation). */ > +static void > +goacc_ex

Re: New mklog script

On 19/05/2020 15:51, Michael Matz wrote: > Hello, > > On Tue, 19 May 2020, Martin Liška wrote: > >>> The common problems I remember is that e.g. when changing a function comment >>> above some function, it is attributed to the previous function rather than >>> following, labels in function confus

[PATCH] [aarch64] Fix PR94591: GCC generates invalid rev64 insns

Hello, This patch fixes PR94591. The problem was the function aarch64_evpc_rev_local() matching vector permutations that were not reversals. In particular, prior to this patch, this function matched the identity permutation which led to generating bogus REV64 insns which were rejected by the assem

Re: New mklog script

On Tue, May 19, 2020 at 05:21:16PM +0100, Richard Earnshaw wrote: > This is really a wart in the GNU coding style. And one reason why I > tend to indent such labels by a single space. It particularly affects > things like class definitions where public, private, etc statements > often appear in c

Re: [PATCH] [aarch64] Fix PR94591: GCC generates invalid rev64 insns

Alex Coplan writes: > Hello, > > This patch fixes PR94591. The problem was the function > aarch64_evpc_rev_local() > matching vector permutations that were not reversals. In particular, prior to > this patch, this function matched the identity permutation which led to > generating bogus REV64 ins

Re: [PATCH] s390: Fix up -Wpsabi diagnostcs + analysis [PR94704]

On 5/19/20 9:34 AM, Ulrich Weigand wrote: On Tue, Apr 28, 2020 at 02:13:02PM +0200, Jakub Jelinek wrote: struct X { }; struct Y { int : 0; }; struct Z { int : 0; Y y; }; struct U : public X { X q; }; struct A { double a; }; struct B : public X { double a; }; struct C : public Y { double a; }; s

[PATCH] Fix FAIL: gcc.target/i386/pr92645-4.c

This adjusts the testcase for the introduced vector promotion/demotion support. Pushed. 2020-05-19 Richard Biener * gcc.target/i386/pr92645-4.c: Adjust expected pattern. --- gcc/testsuite/gcc.target/i386/pr92645-4.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --

[PR 95149] reimplement raw literal lexing

pr95149 is a false positive static analysis checker. But it encouranged me to fix raw string lexing, which does contain a complicated macro and pointers to local variables. The reimplementation does away with that macro. Part of the complication is we need to undo some of the fresh line proc

Re: [PATCH][C] c/95141 - fix bogus integer overflow warning

On Tue, 19 May 2020, Richard Biener wrote: > This fixes an integer overflow warning that ultimatively happens because > of TREE_OVERFLOW propagating through transforms and the existing guard > against this, > > 375 if (TREE_OVERFLOW_P (ret) > 376 && !TREE_OVERFLOW_P (op0)

[PATCH] Add missing store in emission of asan_stack_free.

Hi. We make direct emission for asan_emit_stack_protection for smaller stacks. That's fine but we're missing the piece that marks the stack as released and we run out of pre-allocated stacks. I also included some stack-related constants that were used in asan.c. Patch can bootstrap on x86_64-lin

[PATCH] Use commit timestamp in git_update_version.py.

Hi. The patch is about usage of a git commit timestamp for generated ChangeLog entries. Installed to master. Martin contrib/ChangeLog: 2020-05-19 Martin Liska * gcc-changelog/git_commit.py: Add param use_commit_ts for to_changelog_entries. * gcc-changelog/git_update

Re: collect2.exe errors not pruned

On Tue, 19 May 2020, Alexandre Oliva wrote: > > I don't think the error should mention .exe, but I also don't think the > > error should mention collect2 (see what I said in > > , the existence > > of collect2 is an implementation detail

Re: [PATCH] c++: template instantiation during fold_for_warn [PR94038]

On 5/8/20 11:42 AM, Patrick Palka wrote: On Wed, 6 May 2020, Patrick Palka wrote: On Wed, 6 May 2020, Patrick Palka wrote: On Tue, 5 May 2020, Patrick Palka wrote: On Tue, 5 May 2020, Patrick Palka wrote: Unfortunately, the previous fix to PR94038 is fragile. When the argument to fold_fo

Re: [PATCH] Extend std::copy/std::copy_n char* overload to deque iterator

No chance to review this ? On 07/05/20 9:12 am, François Dumont wrote:     This patch purpose is to make sure that existing std::copy/std::copy_n overloads for char* will also be used for std::deque iterators when dealing with istreambuf_iterator. It also make sure that it still works when _G

Re: New mklog script

On 5/19/20 5:53 PM, Joseph Myers wrote: On Tue, 19 May 2020, Martin Liška wrote: On 5/19/20 10:11 AM, Martin Liška wrote: Can you please share how do you do it? It would be easy to add it. I added the feature via --fill-up-bug-titles option. It uses common request and beatifulsoup packages.

[PATCH] Add -fuse-ld= to specify an arbitrary executable as the linker

On 2020-04-06, Martin Liška wrote: On 4/6/20 12:32 AM, Fangrui Song wrote: On 2020-03-11, Martin Liška wrote: On 2/10/20 1:02 AM, Fangrui Song via gcc-patches wrote: Hello. Thank you for the patch. You haven't received a review because we are right now in stage4 of the development cycle: htt

[PATCH] Tweak some powerpc tests for altivec_ok and vsx_ok

Greetings, The proposed patch adds some checking for vsx and altivec being supported on several powerpc tests. For vxworks, we have to spec particular cpus, so these tests fail when they should show be N/A. --Douglas Rupp, AdaCore diff --git gcc/testsuite/gcc.target/powerpc/builtins-1-b

Re: [PATCH] handle std::byte in -Wclass-memaccess (PR 94923)

On 5/18/20 3:04 PM, Jason Merrill wrote: On 5/8/20 2:16 PM, Martin Sebor wrote: -Wclass-memaccess is suppressed for write accesses to trivially copyable but otherwise nontrivial class types by character types but the suppression neglects to consider the equivalent accesses by std::byte.  The att

V2 [PATCH] x86: Move cpuinfo.h from libgcc to common/config/i386

On Mon, May 18, 2020 at 10:56 PM Uros Bizjak wrote: > > On Tue, May 19, 2020 at 4:17 AM H.J. Lu wrote: > > > > On Mon, May 18, 2020 at 5:57 AM H.J. Lu wrote: > > > > > > On Mon, May 18, 2020 at 5:43 AM Uros Bizjak wrote: > > > > > > > > On Mon, May 18, 2020 at 2:34 PM H.J. Lu wrote: > > > > >

[preprocessor] Some cleanups

I've committed this bunch of cleanups to libcpp. This fixes a bunch of poorly formatted decls, marks some getters as PURE, deletes some C-relevant bool hackery, and finally uses a passed-in location rather than deducing a closely-related but not necessarily the same location. nathan -- Nath

Re: [patch] move array bounds checking into its own file

On Tue, 2020-05-19 at 09:10 +0200, Richard Biener wrote: > On Mon, May 18, 2020 at 8:21 PM Aldy Hernandez via Gcc-patches > wrote: > > As a follow-up to the patch moving array bounds checking into its own > > class, this moves the class into its own files. As I've mentioned > > previously, having

[c++] alias template instantiation

Here's a small cleanup discovered by modules. The alias instantiation machinery would setup template_info, and then sometime later overwrite that with equivalent info. The template info, once set, is logically immutable. Let's just not do that. pushed to master nathan -- Nathan Sidwell 202

[PATCH 0/5] OpenRISC GCC Fixes for Glibc Support

Hello, I am currently working on the glibc port for OpenRISC. This is a series of patches that fix issues and add features that were missing in GCC causing glibc testsuite failures. Pretty much all of these changes are just adding macros. These changes have been tested via the glibc test suite.

[PATCH 4/5] or1k: Add note to indicate execstack

Define TARGET_ASM_FILE_END as file_end_indicate_exec_stack to allow generation of the ".note.GNU-stack" section note. This allows binutils to properly set PT_GNU_STACK in the program header. This fixes a glibc execstack testsuite test failure found while working on the OpenRISC glibc port. gcc/C

[PATCH 3/5] or1k: Support for softfloat to emulate hw exceptions

This allows the openrisc softfloat implementation to set exceptions. This also sets the correct tininess after rounding value to be consistent with hardware and simulator implementations. libgcc/ChangeLog: * config/or1k/sfp-machine.h (FP_RND_NEAREST, FP_RND_ZERO, FP_RND_PINF, FP_R

[PATCH 1/5] or1k: Implement profile hook calling _mcount

Defining this to not abort as found when working on running tests in the glibc test suite. We implement this with a call to _mcount with no arguments. The required return address's will be pulled from the stack. Passing the LR (r9) as an argument had problems as sometimes r9 is clobbered by the

[PATCH 5/5] or1k: Fixup exception header data encodings

While running glibc tests several *-textrel tests failed showing that relocations remained against read only sections. It turned out this was related to exception headers data encoding being wrong. By default pointer encoding will always use the DW_EH_PE_absptr format. This patch uses format DW_

[PATCH 2/5] or1k: Add builtin define to detect hard float

This is used in libgcc and now glibc to detect when hardware floating point operations are supported by the target. gcc/ChangeLog: * config/or1k/or1k.h (TARGET_CPU_CPP_BUILTINS): Add builtin define for __or1k_hard_float__. --- gcc/config/or1k/or1k.h | 2 ++ 1 file changed, 2 in

Avoid SCC hashing on unmergeable trees

Hi, this is new incarantion of patch to identify unmergeable tree at streaming out time rather than streaming in and to avoid pickling them to sccs with with hash codes. Building cc1 plus this patch reduces: [WPA] read 4452927 SCCs of average size 1.986030 [WPA] 8843646 tree bodies read in total

Re: [patch] move value_range_equiv class to own file

On Tue, 2020-05-19 at 09:09 +0200, Richard Biener wrote: > On Mon, May 18, 2020 at 8:13 PM Aldy Hernandez via Gcc-patches > wrote: > > We already moved the value_range class into its own class in the last > > release. I think it's time to move the value_range_equiv stuff into its > > own class, a

Re: [PATCH] Tweak some powerpc tests for altivec_ok and vsx_ok

Hi! On Tue, May 19, 2020 at 12:29:40PM -0700, Douglas B Rupp wrote: > The proposed patch adds some checking for vsx and altivec being > supported on several powerpc tests. > > For vxworks, we have to spec particular cpus, so these tests fail when > they should show be N/A. > diff --git gcc/tes

Re: V2 [PATCH] x86: Move cpuinfo.h from libgcc to common/config/i386

On Tue, May 19, 2020 at 9:58 PM H.J. Lu wrote: > > On Mon, May 18, 2020 at 10:56 PM Uros Bizjak wrote: > > > > On Tue, May 19, 2020 at 4:17 AM H.J. Lu wrote: > > > > > > On Mon, May 18, 2020 at 5:57 AM H.J. Lu wrote: > > > > > > > > On Mon, May 18, 2020 at 5:43 AM Uros Bizjak wrote: > > > > >

[PATCH] x86: Add FEATURE_AVX512VP2INTERSECT and update GFNI check

Add FEATURE_AVX512VP2INTERSECT to libgcc so that enum processor_features in libgcc matches enum processor_features in i386-builtins.c. Update GFNI check to support processors with SSE and AVX versions of GFNI. PR target/95212 PR target/95220 * config/i386/cpuinfo.c (get_av

Re: [PATCH] x86: Add FEATURE_AVX512VP2INTERSECT and update GFNI check

On Tue, May 19, 2020 at 11:37 PM H.J. Lu wrote: > > Add FEATURE_AVX512VP2INTERSECT to libgcc so that enum processor_features > in libgcc matches enum processor_features in i386-builtins.c. Update > GFNI check to support processors with SSE and AVX versions of GFNI. > > PR target/95212 >

[PATCH] Suggest including for bool, true and false

Currently gcc suggests to use _Bool instead of bool and doesn't give any suggestions when true or false are used, but undefined. This patch makes it so that (for C99 or higher) a fixit hint is emitted to include . gcc/c-family/ChangeLog: * known-headers.cc (get_stdlib_header_for_name): Re

Re: V2 [PATCH] x86: Move cpuinfo.h from libgcc to common/config/i386

On Tue, May 19, 2020 at 2:07 PM Uros Bizjak wrote: > > On Tue, May 19, 2020 at 9:58 PM H.J. Lu wrote: > > > > On Mon, May 18, 2020 at 10:56 PM Uros Bizjak wrote: > > > > > > On Tue, May 19, 2020 at 4:17 AM H.J. Lu wrote: > > > > > > > > On Mon, May 18, 2020 at 5:57 AM H.J. Lu wrote: > > > > >

Re: [PATCH] Tweak some powerpc tests for altivec_ok and vsx_ok

On 5/19/20 1:53 PM, Segher Boessenkool wrote: How can altivec not be supported when you use -mcpu=power8? For the test in question: builtins-1-be-folded.c: The VxWorks header file altivec.h is included by builtins-1.fold.h and the error is: altivec.h:34:2: error: #error Use the "-maltivec"

Re: New mklog script

On Tue, 19 May 2020 at 17:13, Joseph Myers wrote: > > On Tue, 19 May 2020, Martin Liška wrote: > > > On 5/19/20 10:11 AM, Martin Liška wrote: > > > Can you please share how do you do it? It would be easy to add it. > > > > I added the feature via --fill-up-bug-titles option. It uses common > > requ

Re: New mklog script

On Tue, 19 May 2020 at 09:26, Jakub Jelinek via Gcc wrote: > > On Tue, May 19, 2020 at 10:11:28AM +0200, Martin Liška wrote: > > > I find this format more helpful for the reasons below so unless your > > > script can be tweaked to do something similar I'd like to be able to > > > continue to use m

Re: New mklog script

Hello, On Tue, 19 May 2020, Jakub Jelinek wrote: > On Tue, May 19, 2020 at 05:21:16PM +0100, Richard Earnshaw wrote: > > This is really a wart in the GNU coding style. And one reason why I > > tend to indent such labels by a single space. It particularly affects > > things like class definition

Re: [PATCH] Tweak some powerpc tests for altivec_ok and vsx_ok

On Tue, May 19, 2020 at 02:41:45PM -0700, Douglas B Rupp wrote: > > On 5/19/20 1:53 PM, Segher Boessenkool wrote: > >How can altivec not be supported when you use -mcpu=power8? > > > For the test in question: builtins-1-be-folded.c: > > The VxWorks header file altivec.h is included by builtins-1.

  1   2   >