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

Martin Liška writes: Hi Martin, > On 5/19/20 11:45 AM, Frederik Harwath wrote: > Thank you Frederick for the patch. > > Looking at what I grepped: > https://github.com/marxin/gcc-changelog/issues/1#issuecomment-621910248 I get a 404 error when I try to access this URL. The repository also does

Re: [PATCH 2/2] rs6000: tune loop size for cunroll at O2

Hi Jeff, on 2020/5/20 上午11:58, Jiufu Guo via Gcc-patches wrote: > Hi, > > This patch check the size of a loop to be unrolled/peeled completely, > and set the limits to a number (24). This prevents large loop from > being unrolled, then avoid binary size increasing, and this limit keeps >

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

On Tue, May 19, 2020 at 10:39:59AM -0400, Jason Merrill wrote: > 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

Re: [PATCH 2/2] rs6000: tune loop size for cunroll at O2

Jiufu Guo writes: > Hi, > > This patch check the size of a loop to be unrolled/peeled completely, > and set the limits to a number (24). This prevents large loop from > being unrolled, then avoid binary size increasing, and this limit keeps > performance. > > Bootstrap pass on powerpc64le, ok

[PATCH 2/2] rs6000: tune loop size for cunroll at O2

Hi, This patch check the size of a loop to be unrolled/peeled completely, and set the limits to a number (24). This prevents large loop from being unrolled, then avoid binary size increasing, and this limit keeps performance. Bootstrap pass on powerpc64le, ok for trunk? Jiufu ---

[PATCH 1/2] rs6000: tune cunroll for simple loops at O2

Hi, In r10-4525, and r10-4161, loop unroller was enabled for simply loops at -O2. At the same time, the GIMPLE cunroll is also enabled, while it is not only for simple loops. This patch introduces a hook to check if a loop is suitable to unroll completely. The hook can be used to check if a

[PATCH] c++: spec_hasher and TYPENAME_TYPE resolution [PR95223]

After enabling sanitization of the specialization tables, we are triggering one of the hash table sanity checks in the below testcase. The reason is that when looking up the specialization j in the type_specializations table, the sanity check finds that the existing entry j::m> compares equal to

[PATCH] x86: Update VPCLMULQDQ check

Update VPCLMULQDQ check to support processors with AVX version of VPCLMULQDQ. PR target/91695 * config/i386/cpuinfo.c (get_available_features): Fix VPCLMULQDQ check. --- libgcc/config/i386/cpuinfo.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

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

Apologies on this test, the problem is -mdejagnu-cpu doesn't get matched by the spec logic If I pass -mcpu=power8, then indeed the test passes fine. I'm not sure how to fix this cleanly.

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 v2] c++: Change the default dialect to C++17.

On Mon, May 18, 2020 at 03:51:36PM -0400, Jason Merrill wrote: > On 5/16/20 6:34 PM, Marek Polacek wrote: > > Since GCC 9, C++17 support is no longer experimental. It was too late > > to change the default C++ dialect to C++17 in GCC 10, but I think now > > it's time to pull the trigger (C++14

Re: [PATCH][GCC][Arm]: Fix bootstrap failure with rtl-checking

On Mon, Apr 27, 2020 at 2:22 PM Andre Vieira (lists) wrote: > > Hi, > > The code change that caused this regression was not meant to affect neon > code-gen, however I missed the REG fall through. This patch makes sure > we only get the left-hand of the PLUS if it is indeed a PLUS expr. > > I

[committed] libstdc++: Use RDRAND as fallback if RDSEED keeps failing (PR 94087)

It's not difficult for multiple threads to drain the entropy available to the RDSEED instruction, at which point we throw an exception. This change will try to use RDRAND after RDSEED fails repeatedly, and only throw if RDRAND also fails repeatedly. This doesn't guarantee a random value can always

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

On 5/19/20 3:03 PM, Segher Boessenkool wrote: This is a compile test, so it does not matter at all what the kernel is doing or not doing. And the -mcpu=power8 flag should enable altivec. Apparently it doesn't for you, but why is that? It's likely the specs file we use for the kernel we

Re: ChangeLog files - server and client scripts

On Tue, 19 May 2020 at 23:19, Jonathan Wakely wrote: > > On Tue, 19 May 2020 at 11:44, Martin Liška wrote: > > > > 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

Re: ChangeLog files - server and client scripts

On Tue, 19 May 2020 at 11:44, Martin Liška wrote: > > 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

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

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

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

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

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

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

[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

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

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

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,

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

[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

[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

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

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

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

[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

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,

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

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

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

[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

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

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.

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

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

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

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

[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

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)

[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

[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

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; };

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

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

[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

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

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 >

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

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

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

[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

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 () > > { > >

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

'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

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

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

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

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

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

[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

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

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

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

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

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

[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

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

[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

[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

[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

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

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

[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

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

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

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

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

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

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

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

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

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

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

  1   2   >