Re: [wwwdocs] gcc-8/porting_to.html

Hi Thomas, On Wed, 22 Mar 2017, Thomas Preudhomme wrote: Is this ok for wwwdocs once [1] is committed in GCC 8 cycle? + GCC on Microsoft Windows can now be configured via + --enable-mingw-wildcard or + --disable-mingw-wildcard to force a specific behavior for + GCC itself

Re: [PATCH,rs6000] Handle conflicting target options -mno-power9-vector and -mcpu=power9

On Wed, Mar 22, 2017 at 05:55:53PM -0600, Kelvin Nilsen wrote: > > Or it could do -mpower9-dform-scalar but disable -mpower9-dform-vector? > > That seems more reasonable. > > The internal problem report sent to me said "-mno-power9-vector should > override power9-dform unless the latter has been d

Re: [PATCH,rs6000] Handle conflicting target options -mno-power9-vector and -mcpu=power9

On 03/22/2017 05:35 PM, Segher Boessenkool wrote: > On Wed, Mar 22, 2017 at 11:44:49AM -0600, Kelvin Nilsen wrote: >> Internal testing recently revealed that use of the -mno-power9-vector >> target option in combination with the -mcpu=power9 target option >> results in termination of gcc with the

Re: [PATCH] internal/syscall/unix: fix syscalls for m68k

On Wed, Mar 22, 2017 at 6:17 AM, Andreas Schwab wrote: > --- > libgo/go/internal/syscall/unix/getrandom_linux_m68k.go | 9 + > 1 file changed, 9 insertions(+) > create mode 100644 libgo/go/internal/syscall/unix/getrandom_linux_m68k.go > > diff --git a/libgo/go/internal/syscall/unix/getra

Re: [PATCH,rs6000] Handle conflicting target options -mno-power9-vector and -mcpu=power9

On Wed, Mar 22, 2017 at 11:44:49AM -0600, Kelvin Nilsen wrote: > Internal testing recently revealed that use of the -mno-power9-vector > target option in combination with the -mcpu=power9 target option > results in termination of gcc with the error message: > > power9-dform requires power9-vecto

Re: [wwwdocs] gcc-8/porting_to.html

On 03/22/2017 05:39 PM, Thomas Preudhomme wrote: > Hi JonY, > > Sorry for the delay. Please find updated patch as per Gerald and you > suggestion. > > Is this ok for wwwdocs once [1] is committed in GCC 8 cycle? > > [1] https://gcc.gnu.org/ml/gcc-patches/2017-02/msg01153.html > > Best regards,

Re: [PATCH] Fix reassoc very large TU handlng (PR tree-optimization/80072)

On March 22, 2017 7:52:40 PM GMT+01:00, Jakub Jelinek wrote: >Hi! > >On the huge testcase from the PR (not really reduceable) we run into >reassoc ranks bigger than INT_MAX (bb_rank is multiples of 65536, >so it might be enough to have just 32768+ basic blocks to reach that). >Rank is unsigned int

Go patch committed: initialize gogo fields

A few of the Gogo data fields were not being initialized correctly, causing Valgrind failures and possible confusion. This patch by Than McIntosh fixes the problem. Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed to mainline. Ian Index: gcc/go/gofrontend/go.cc ==

[committed] Fix OpenMP ICE with templates (PR c++/80141)

Hi! As can be seen on the testcase, apparently it is a bad idea to call maybe_constant_value when processing_template_decl, e.g. the 2 && 2 is at that point still 2 && 2 rather than true && true and constexpr code is unhappy about that. Fixed thusly, bootstrapped/regtested on x86_64-linux and i68

[PATCH] Fix reassoc very large TU handlng (PR tree-optimization/80072)

Hi! On the huge testcase from the PR (not really reduceable) we run into reassoc ranks bigger than INT_MAX (bb_rank is multiples of 65536, so it might be enough to have just 32768+ basic blocks to reach that). Rank is unsigned int, but we were returning (int) (oeb->rank - oea->rank); from the comp

[committed] Cherry-pick libtsan atomic fix (PR sanitizer/78158)

Hi! I've committed the following cherry-pick of upstream change for tsan atomics after bootstrapping/regtesting it on x86_64-linux and i686-linux. 2017-03-22 Jakub Jelinek PR sanitizer/78158 * tsan/tsan_interface_atomic.cc: Cherry-pick upstream r298378. --- libsanitizer/tsan/

Re: [PATCH] Decrease compile time memory with heavy find_base_{value,term} on i?86/x86_64 (PR rtl-optimization/63191, take 2)

On 03/22/2017 04:38 PM, Uros Bizjak wrote: LGTM, but I don't want to step on Bernd's toes, so let's wait for his opinion. I was waiting for yours really, that's the one that counts. Bernd

[PATCH,rs6000] Handle conflicting target options -mno-power9-vector and -mcpu=power9

Internal testing recently revealed that use of the -mno-power9-vector target option in combination with the -mcpu=power9 target option results in termination of gcc with the error message: power9-dform requires power9-vector This same problem is seen if the -mno-power9-vector target option is

Re: [wwwdocs] gcc-8/porting_to.html

Hi JonY, Sorry for the delay. Please find updated patch as per Gerald and you suggestion. Is this ok for wwwdocs once [1] is committed in GCC 8 cycle? [1] https://gcc.gnu.org/ml/gcc-patches/2017-02/msg01153.html Best regards, Thomas On 12/03/17 23:51, JonY wrote: On 03/12/2017 02:07 PM, Ger

[PING][PATCH][PR79542][Ada] Fix ICE in dwarf2out.c with nested func. inlining

Hello, This is a ping for the patch I posted there: . Thank you! -- Pierre-Marie de Rodat

Re: [PATCH] Fix r242743 change of gcc/system.h

Paolo Bonzini : > > On 19/03/2017 22:17, Gunther Nikl wrote: > > Hello Paolo! > > > > Building older GCC releases with clang tends to issue warnings. This > > can be annoying especially when they originate from a header. While > > backporting r242743 I noticed that the non-C++ cases of the change

Re: [build,darwin] Fix toplevel configure test for LTO on darwin

On Mar 17, 2017, at 3:36 AM, FX wrote: > > When LTO was introduced, on macOS it needed darwin9 to work. Over time, most > tests for “*-apple-darwin9” in the toplevel configure were changed to also > include later darwin versions: *-darwin[[912]]* However, the check for LTO > was not updated.

Re: [patch, libgfortran] PR78881 [F03] reading from string with DTIO procedure does not work properly

The patch works as expected. Note that the line ! { dg-final { cleanup-modules "t_m" } } in dtio_26.f03 and dtio_27.f03 can/should be removed IIRC. Cheers, Dominique

Re: [PATCH gfortran] Fix PRs 79602, 79844, 79853, 79859, and 80011.

Committed as revision r246391. Thanks for the quick review. Dominique > Le 22 mars 2017 à 17:08, Thomas Koenig a écrit : > > Hi Dominique, > >> Th attached patch fixes some of the diagnostic issues reported by Roland >> Illig. Ok for trunk? > > Yes, OK. Thanks for the patch! > > Regards >

RE: [wwwdocs] ARC's gcc7.x release notes

> By the way, any ARC maintainer or reviewer can approve such > changes (and in the case of reviewers, really self approve > web changes like this). :-) So you did not require approval, > though always happy to help review. > That's great news, thank you Gerald for the quick review. I still have

Re: [PATCH gfortran] Fix PRs 79602, 79844, 79853, 79859, and 80011.

Hi Dominique, Th attached patch fixes some of the diagnostic issues reported by Roland Illig. Ok for trunk? Yes, OK. Thanks for the patch! Regards Thomas

[PATCH] Add deduction guides for C++17 (P0433R2, partial)

This adds some of the C++17 deduction guides, all except for the allocator-aware containers and basic_regex. I have patches adding those guide too, but am still working on the tests (some cases I expected to work are ill-formed, so I'm still looking into why). * include/bits/shared_ptr.h

Re: [wwwdocs] ARC's gcc7.x release notes

Hi Claudiu, On Wed, 22 Mar 2017, Claudiu Zissulescu wrote: > I would like to add the attached patch to GCC7.x release notes. It > contains the news on ARC backend. s/cpu/CPU/g through, and then good to commit. By the way, any ARC maintainer or reviewer can approve such changes (and in the case

[PATCH gfortran] Fix PRs 79602, 79844, 79853, 79859, and 80011.

Th attached patch fixes some of the diagnostic issues reported by Roland Illig. Ok for trunk? 2017-03-22 Dominique d'Humieres PR fortran/79602 * decl.c: Replace '%s' with %qs. * expr.c: Likewise. * interface.c: Likewise. * match.c: Likewise. * p

[PATCH 4/5] tree-inline: implement SIMT privatization, part 3

This patch implements privatization for SIMT during inlining. We need to discover if the call being inlined belongs to a SIMT region (by looking at simduid of the containing loop), and if so, treat them similar to OpenMP-SIMD privatization: add the "omp simt private" attribute and mention them amo

[PATCH 5/5] address-taken: optimize SIMT privatized variables

This patch implements promotion of SIMT private variables if GOMP_SIMT_ENTER is the only remaining statement where their address is taken, by handling it similar to ASAN_MARK. To avoid rebuilding GOMP_SIMT_ENTER statement from scratch, set argument slot to a null pointer when the corresponding var

[PATCH 2/5] omp-low: implement SIMT privatization, part 1

This patch adjusts privatization in OpenMP SIMD loops lowered for SIMT targets. At lowering time, private variables receive "omp simt private" attribute, get mentioned in argument list of GOMP_SIMT_ENTER function, and get a clobbering assignment just prior to GOMP_SIMT_EXIT function. The following

[PATCH 1/5] nvptx: implement SIMT enter/exit insns

This patch adds handling of new omp_simt_enter/omp_simt_exit named insns in the NVPTX backend. * config/nvptx/nvptx-protos.h (nvptx_output_simt_enter): Declare. (nvptx_output_simt_exit): Declare. * config/nvptx/nvptx.c (nvptx_init_unisimt_predicate): Use cfun->machi

[PATCH 3/5] omp-offload: implement SIMT privatization, part 2

This patch implements rewriting of SIMT private variables as fields of a struct by setting DECL_VALUE_EXPR on them and regimplifying statements. * omp-offload.c: Include langhooks.h, tree-nested.h, stor-layout.h. (ompdevlow_adjust_simt_enter): New. (find_simtpriv_var_op): N

[PATCHv2 0/5] OpenMP/PTX: improve correctness in SIMD regions

Hello, This patchset implements privatization of addressable variables in OpenMP SIMD regions lowered for SIMT targets (i.e. NVPTX) via the approach identified in the review of the previous submission. Now instead of explicitly privatizing those variables as fields of an allocated struct up front

[PATCH v3] Fix PR79908 (and PR80136)

Hi, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79908 shows a case where pass_stdarg ICEs attempting to gimplify a COMPLEX_EXPR with side effects as an lvalue. This occurs when the LHS of a VA_ARG has been cast away. The previous patch (reverted) used force_gimple_operand to instantiate the ne

[wwwdocs] ARC's gcc7.x release notes

Hi, I would like to add the attached patch to GCC7.x release notes. It contains the news on ARC backend. Ok to apply? Claudiu changes.html.patch Description: changes.html.patch

Re: [PATCH] Decrease compile time memory with heavy find_base_{value,term} on i?86/x86_64 (PR rtl-optimization/63191, take 2)

On Mon, Mar 20, 2017 at 12:15 PM, Jakub Jelinek wrote: > Hi! > > On Fri, Mar 10, 2017 at 07:57:39PM +0100, Jakub Jelinek wrote: >> On Fri, Mar 10, 2017 at 07:52:37PM +0100, Bernd Schmidt wrote: >> > On 03/10/2017 06:53 PM, Jakub Jelinek wrote: >> > > + >> > > +template >> > > +static inline rtx >

Re: [PATCH][PR sanitizer/77631] Support separate debug info in libbacktrace

Hello everyone, I've fixed some issues and implemented functionality to search debug file by build-id. Can someone please review my patch. > As far as I know all the debuglink code is ELF-specific. I would do > it all in elf.c. While reading the sections of the executable, look > for a debuglin

[patch, fortran, committed] Fix PR 80162, warning about missing location information

Hello world, I have committed the attached patch as obvious and simple after regression-testing, as rev. 246388. This is a case where the location checking pass did its job and found a place where the location information was indeed missing. Regards Thomas 2017-03-22 Thomas Koenig

Backport to GCC5 (part 2)

And there's a single patch that I'll install after bootstrap and regression tests. Martin >From cc7922d08b8b5234758e31e2d91557fd7f6cac9b Mon Sep 17 00:00:00 2001 From: marxin Date: Wed, 22 Feb 2017 09:45:42 + Subject: [PATCH] Backport r245647 gcc/ChangeLog: 2017-02-22 Martin Liska PR l

Backport to GCC6 (part 2)

Hello. There are 4 patches I'm going to install. Patches can bootstrap on x86_64-linux-gnu and survives regression tests. Martin >From d0337d6690f925a323f6b271e9a138ae463c9e7e Mon Sep 17 00:00:00 2001 From: marxin Date: Fri, 3 Feb 2017 15:22:47 + Subject: [PATCH 1/4] Backport r245155 gcc/Ch

Go patch committed: check backend alignment for memequalNN functions

The Go frontend was assuming the usual required alignment for the memequalNN functions (16 bits for int16, 32 for int32, etc.). However, on m68k the required alignment of int32 is only 16 bits. Assuming the memequalNN alignment caused the compiler to incorrectly decide that int32 required a special

Re: [PATCH] Fix -fsanitize=thread with -fnon-call-exceptions (PR sanitizer/80110)

On Tue, Mar 21, 2017 at 09:26:49AM +0100, Richard Biener wrote: > On Tue, 21 Mar 2017, Jakub Jelinek wrote: > > > On Tue, Mar 21, 2017 at 09:12:51AM +0100, Richard Biener wrote: > > > > libtsan atomics aren't throwing, so if we transform atomics which > > > > are throwing with -fnon-call-exception

Re: [PATCH] Fix PR80029

On Wed, Mar 22, 2017 at 06:48:09AM -0700, Cesar Philippidis wrote: > On 03/22/2017 06:42 AM, Jakub Jelinek wrote: > > >> 2017-03-22 Cesar Philippidis > >> > >>PR c++/80029 > >> > >>gcc/ > >>* gimplify.c (is_oacc_declared): New function. > >>(oacc_default_clause): Use it to set d

Re: [PATCH] Fix PR80029

On Wed, Mar 22, 2017 at 06:40:03AM -0700, Cesar Philippidis wrote: > In addition to resolving the memory leak involving OpenACC delare > clauses, this patch also corrects an ICE involving VLA variables as data > clause arguments used in acc declare constructs. More details can be > found here

Re: [PATCH] Fix PR80029

On 03/22/2017 06:42 AM, Jakub Jelinek wrote: >> 2017-03-22 Cesar Philippidis >> >> PR c++/80029 >> >> gcc/ >> * gimplify.c (is_oacc_declared): New function. >> (oacc_default_clause): Use it to set default flags for acc declared >> variables inside parallel regions. >>

Re: [PATCH] Fix -fsanitize=thread with -fnon-call-exceptions (PR sanitizer/80110)

On Wed, 22 Mar 2017, Jakub Jelinek wrote: > On Tue, Mar 21, 2017 at 09:26:49AM +0100, Richard Biener wrote: > > On Tue, 21 Mar 2017, Jakub Jelinek wrote: > > > > > On Tue, Mar 21, 2017 at 09:12:51AM +0100, Richard Biener wrote: > > > > > libtsan atomics aren't throwing, so if we transform atomics

[PATCH] Fix PR80029

In addition to resolving the memory leak involving OpenACC delare clauses, this patch also corrects an ICE involving VLA variables as data clause arguments used in acc declare constructs. More details can be found here . Is this OK for trun

Re: [PATCH] Fix gimplification of const var initialization from COND_EXPR (PR c++/80129)

On Wed, 22 Mar 2017, Jakub Jelinek wrote: > On Wed, Mar 22, 2017 at 09:59:09AM +0100, Richard Biener wrote: > > Yeah, changing it to VAR_P and expanding the comment so it says > > it avoids incorrect promotion to readonly-static. (so it _is_ > > fishy that we have multiple assignments to TREE_REA

Re: [PATCH] Fix gimplification of const var initialization from COND_EXPR (PR c++/80129)

On Wed, Mar 22, 2017 at 09:59:09AM +0100, Richard Biener wrote: > Yeah, changing it to VAR_P and expanding the comment so it says > it avoids incorrect promotion to readonly-static. (so it _is_ > fishy that we have multiple assignments to TREE_READONLY objects > given that code looks at a single a

[PATCH] internal/syscall/unix: fix syscalls for m68k

--- libgo/go/internal/syscall/unix/getrandom_linux_m68k.go | 9 + 1 file changed, 9 insertions(+) create mode 100644 libgo/go/internal/syscall/unix/getrandom_linux_m68k.go diff --git a/libgo/go/internal/syscall/unix/getrandom_linux_m68k.go b/libgo/go/internal/syscall/unix/getrandom_linu

[PATCH] Fix PR80032 fix fallout

The following reportedly fixes a LLVM miscompile. Bootstrapped on x86_64-unknown-linux-gnu, testing in progress. Richard. 2017-03-22 Richard Biener PR tree-optimization/80032 * gimplify.c (gimple_push_cleanup): Forced unconditional cleanups still have to go to the co

Backport to GCC5

Hello. This is very same series as the one for GCC6. Only exception is toplev.c, which is squashed just to a single patch. And a multi-versioning patch is omitted. Patch can bootstrap on x86_64-linux-gnu and survives regression tests. I'm going to install the series. Martin >From 62b6cbefcf9eba

Re: [build,darwin] Fix toplevel configure test for LTO on darwin

*ping* When LTO was introduced, on macOS it needed darwin9 to work. Over time, most tests for “*-apple-darwin9” in the toplevel configure were changed to also include later darwin versions: *-darwin[[912]]* However, the check for LTO was not updated. As far as I know, this is merely an oversi

[PATCH, GCC/ARM, Stage 1] Rename FPSCR builtins to correct names

The GCC documentation in section 6.60.8 ARM Floating Point Status and Control Intrinsics states that the FPSCR register can be read and written to using the intrinsics __builtin_arm_get_fpscr and __builtin_arm_set_fpscr. However, these are misnamed within GCC itself and these intrinsic names are no

Re: [PATCH, GCC/ARM, stage4] Fix PR80082: LDRD erronously used for 64bit load on ARMv7-R

On 22/03/17 10:25, Thomas Preudhomme wrote: > Hi, > > Currently GCC is happy to use LDRD to perform a 64bit load on ARMv7-R, > as shown by the testcase on this patch. However, LDRD is only atomic > when LPAE extensions is available, which they are not for ARMv7-R. This > commit solve the issue by

Re: Backport to GCC6

On Wed, Mar 22, 2017 at 11:15 AM, Martin Liška wrote: > Hello. > > I would like to backport following set of revisions to GCC6: > > r246345 > r246321 > r246316 > r246276 > r246275 > r246129 > r246120 > r246098 > r246027 > r245998 > r245997 > r245993 > r245992 > r245870 > r245869 > r245868 > r24553

[PATCH, GCC/ARM, stage4] Fix PR80082: LDRD erronously used for 64bit load on ARMv7-R

Hi, Currently GCC is happy to use LDRD to perform a 64bit load on ARMv7-R, as shown by the testcase on this patch. However, LDRD is only atomic when LPAE extensions is available, which they are not for ARMv7-R. This commit solve the issue by introducing a new feature bit to distinguish LPAE exten

Backport to GCC6

Hello. I would like to backport following set of revisions to GCC6: r246345 r246321 r246316 r246276 r246275 r246129 r246120 r246098 r246027 r245998 r245997 r245993 r245992 r245870 r245869 r245868 r245531 r245532 r237353 Survives bootstrap on ppc64le-linux-gnu and x86_64-linux-gnu and the series

[PATCH] Support for Ada on aarch64 with -mabi=ilp32

PR ada/80117 * system-linux-arm-ilp32.ads: New file. * gcc-interface/Makefile.in (LIBGNAT_TARGET_PAIRS_COMMON): Use it for aarch64-linux with -mabi=ilp32. diff --git a/gcc/ada/gcc-interface/Makefile.in b/gcc/ada/gcc-interface/Makefile.in index e5a79f8d97..a4947b5f9

Re: [PATCH] Fix gimplification of const var initialization from COND_EXPR (PR c++/80129)

On Wed, 22 Mar 2017, Jakub Jelinek wrote: > On Wed, Mar 22, 2017 at 09:20:32AM +0100, Richard Biener wrote: > > > --- gcc/gimplify.c.jj 2017-03-21 07:56:55.0 +0100 > > > +++ gcc/gimplify.c2017-03-21 13:37:45.555612652 +0100 > > > @@ -5098,6 +5098,13 @@ gimplify_modify_expr_rhs

Re: [PATCH] Fix gimplification of const var initialization from COND_EXPR (PR c++/80129)

On Wed, Mar 22, 2017 at 09:20:32AM +0100, Richard Biener wrote: > > --- gcc/gimplify.c.jj 2017-03-21 07:56:55.0 +0100 > > +++ gcc/gimplify.c 2017-03-21 13:37:45.555612652 +0100 > > @@ -5098,6 +5098,13 @@ gimplify_modify_expr_rhs (tree *expr_p, > > if (ret != GS_ERROR) > >

Re: [PATCH] Fix gimplification of const var initialization from COND_EXPR (PR c++/80129)

On Tue, 21 Mar 2017, Jakub Jelinek wrote: > Hi! > > For non-gimple reg types var = x ? y : z; is gimplified as > x ? (var = y) : (var = z);. The problem is that if var is TREE_READONLY, > we can gimplify one of those assignments by promoting them to TREE_STATIC > (if not addressable) and making