Re: [PATCH] Add constant folding support for next{after,toward}{,f,l} (PR libstdc++/85466)

On Thu, 3 May 2018, Jakub Jelinek wrote: > On Thu, May 03, 2018 at 06:35:50PM +0200, Jakub Jelinek wrote: > > That requires a machine_mode or tree, but I don't have either of those, > > nor the caller (fold_const_call_sss) has those. > > > > I could change it to: > > if (flag_signalling_nans >

Re: GCC 8.1 Released

On Fri, May 4, 2018 at 9:31 AM, Janne Blomqvist wrote: > On Fri, May 4, 2018 at 9:22 AM, Bert Wesarg > wrote: > >> Hi, >> >> On Wed, May 2, 2018 at 2:15 PM, Jakub Jelinek wrote: >> > Some code that compiled successfully with older GCC versions might >> require >> > source changes, see http://gc

[ARM] Fix PR85434: spill of stack protector's guard address

I'll make a fool of myself but I still have further questions if you don't mind (see inline). On Friday, 4 May 2018, Segher Boessenkool wrote: > Hi! > > On Wed, May 02, 2018 at 07:57:55AM +0100, Thomas Preudhomme wrote: >> As mentionned in the ticket this was my first thought but this means >> ma

libgo patch committed: update mkalldocs.sh

Update mkalldocs.sh from the current master sources, replacing the old mkdoc.sh. I think this got left out of the merges. Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed to mainline. Ian Index: gcc/go/gofrontend/MERGE =

libgo patch committed: enable tests of go tool invoking vet

Since libgo does have the vet tool now, enable the tests in which the go tool invokes it. Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed to mainline. Ian Index: gcc/go/gofrontend/MERGE === --- gcc/go/gofrontend/

libgo patch committed: Update go tool to match recent upstream changes

In https://golang.org/cl/111097 the gc version of cmd/go, which is part of libgo, was updated to include some gccgo-specific changes. The libgo code already has different versions of those changes; this patch makes the libgo match the upstream code. Bootstrapped and ran Go testsuite on x86_64-pc-l

C++ PATCH for c++/85600, virtual delete failure

When I removed some of the save_exprs, I was missing that we don't save_expr on the virtual delete path, but then we use addr again to check that it's non-null. This patch simplifies the logic a bit so that we always save_expr when we're deleting; if we're just calling the destructor we don't need

[PATCH] PR libstdc++/82644 define TR1 hypergeometric functions in strict modes

Following a recent change for PR 82644 the non-standard hypergeomtric functions are not defined by when __STRICT_ANSI__ is defined (e.g. for -std=c++17, or -std=c++14 -D__STDCPP_WANT_MATH_SPEC_FUNCS__). That caused errors in because the using-declarations for tr1::hyperg et al are invalid in str

Re: libgo patch committed: break dependence on unwind-pe.h

Hi Than, > Thanks for catching that. > > I don't have access to test machines, but could you possibly try the > attached patch? I just did. However, it made no difference, while a full reversal of the patch fixed all new go and libgo failures on sparc-sun-solaris2.11. Rainer -- --

Re: [PATCH 1/2, expr.c] Optimize switch with sign-extended index.

On Thu, May 3, 2018 at 12:29 AM, Richard Biener wrote: > Just as a note, IIRC all the SUBREG_PROMOTED_* stuff is quite fragile > - I remember > Eric fixing things up a bit but some verification would be nice to > have (instrumentation > at RTL level that for SUBREG_PROMOTED_* the bits are as expec

[REPOST] [PATCH] Avoid excessive function type casts with splay-trees

Hi, this is basically the same patch I posted a few months ago, with a few formatting nits by Jakub fixed. Bootstrapped and reg-tested again with current trunk. Is it OK for trunk? Bernd. On 12/15/17 11:44, Bernd Edlinger wrote: > Hi, > > when working on the -Wcast-function-type patch I noti

Re: Rb_tree constructor optimization

On 02/05/2018 13:49, Jonathan Wakely wrote: On 01/05/18 21:56 +0200, François Dumont wrote: Hi If not told otherwise I'll commit attached patch tomorrow. Please do not commit it, see below. Already discussed here: https://gcc.gnu.org/ml/libstdc++/2017-10/msg00053.html There's no changelo

Re: libgo patch committed: break dependence on unwind-pe.h

strongly suspect that this patch severely broke Go on Solaris/SPARC: > between 20180502 (r259840) and 20180503 (r259897) there appeared tons of > new execution failures, both 32 and 64-bit: > +FAIL: go.go-torture/execute/printnil.go execution, -O0 > +FAIL: go.go-torture/execute/print

[C++ Patch] Kill -ffriend-injection

As prophesied in GCC 8.1, it's time to kill friend injection. Committing to trunk. nathan -- Nathan Sidwell 2018-05-03 Nathan Sidwell * doc/extend.texi (Deprecated Features): Remove -ffriend-injection. (Backwards Compatibility): Likewise. * doc/invoke.texi (C++ Language Options): Likewis

Re: libgo patch committed: break dependence on unwind-pe.h

and ran > Go testsuite on x86_64-pc-linux-gnu. Committed to mainline. I strongly suspect that this patch severely broke Go on Solaris/SPARC: between 20180502 (r259840) and 20180503 (r259897) there appeared tons of new execution failures, both 32 and 64-bit: +FAIL: go.go-torture/execute/printn

Re: [PATCH v1] PR libstdc++/84769 qualify std::get to avoid ADL

On 03/05/18 20:55 +0200, Duarte Nunes wrote: PR libstdc++/84769 * include/std/variant (visit<_Visitor, _Variants...>): Qualify call to std::get<_Np, _Types...>. Thanks for the patch, I was already testing the same change and just committed the attached patch to trunk. Backports for other branch

[PATCH] PR libstdc++/85632 fix wraparound in filesystem::space

On 32-bit targets any values over 4GB would wrap and produce the wrong result. PR libstdc++/85632 use uintmax_t for arithmetic * src/filesystem/ops.cc (experimental::filesystem::space): Perform arithmetic in result type. * src/filesystem/std-ops.cc (filesystem::spa

[PATCH v1] PR libstdc++/84769 qualify std::get to avoid ADL

PR libstdc++/84769 * include/std/variant (visit<_Visitor, _Variants...>): Qualify call to std::get<_Np, _Types...>. Signed-off-by: Duarte Nunes --- ChangeLog| 6 ++ libstdc++-v3/include/std/variant | 2 +- 2 files changed, 7 insertions(+), 1 deletion(-) diff --git a/

[PATCH] PowerPC: Reformat move insns to make them clearing, patch #5 of 5

These patches were previously posted in March as RFC's. These patches just reformat the floating point move insns to make it easier to figure out which constraints and attributes are used for particular alternatives. I have built the compiler on a little endian power8 system with all 5 patches ap

[PATCH] PowerPC: Reformat move insns to make them clearing, patch #3 of 5

These patches were previously posted in March as RFC's. These patches just reformat the floating point move insns to make it easier to figure out which constraints and attributes are used for particular alternatives. I have built the compiler on a little endian power8 system with all 5 patches ap

[PATCH] PowerPC: Reformat move insns to make them clearing, patch #4 of 5

These patches were previously posted in March as RFC's. These patches just reformat the floating point move insns to make it easier to figure out which constraints and attributes are used for particular alternatives. I have built the compiler on a little endian power8 system with all 5 patches ap

[PATCH] PowerPC: Reformat move insns to make them clearing, patch #2 of 5

These patches were previously posted in March as RFC's. These patches just reformat the floating point move insns to make it easier to figure out which constraints and attributes are used for particular alternatives. I have built the compiler on a little endian power8 system with all 5 patches ap

[PATCH] PowerPC: Reformat move insns to make them clearing, patch #1 of 5

These patches were previously posted in March as RFC's. These patches just reformat the floating point move insns to make it easier to figure out which constraints and attributes are used for particular alternatives. I have built the compiler on a little endian power8 system with all 5 patches ap

Re: Patch ping (Re: [PATCH] Add _mm512_{,mask_}mullox_epi64 intrinsics (PR target/85530))

Hi Jakub, > On 3 May 2018, at 12:28, Jakub Jelinek wrote: > > On Thu, Apr 26, 2018 at 10:09:48PM +0200, Jakub Jelinek wrote: >> ICC apparently has these two intrinsics (why it doesn't have a maskz_ one >> is unclear to me) which are like _mm512_{,mask_}mullo_epi64, except they are >> available i

Re: [PATCH] Fix PR85627 (and more)

> Test coverage of -fnon-call-exceptions is notoriously bad and I'm not > sure whether Ada uses GCCs complex types. Eric? It does, but only with a GNAT-specific pragma: https://gcc.gnu.org/onlinedocs/gcc-8.1.0/gnat_rm/Pragma-Complex_005fRepresentation.html#Pragma-Complex_005fRepresentation who

Re: [PATCH] PowerPC address support clean, patch 4 of 4

These patches were previously posted in March as a RFC, and I would like to check them into the trunk. These patches make the mode_supports* functions use similar names for the functions that return if a mode supports D-FORM, DS-FORM, and/or DQ-FORM instructions, and add the ability to ask whether

Re: [PATCH] PowerPC address support clean, patch 3 of 4

These patches were previously posted in March as a RFC, and I would like to check them into the trunk. These patches make the mode_supports* functions use similar names for the functions that return if a mode supports D-FORM, DS-FORM, and/or DQ-FORM instructions, and add the ability to ask whether

Go patch committed: Avoid crashing on invalid non-integer array length

This patch to the Go frontend by Than McIntosh tweaks the array type checking code to avoid crashing on array types whose length expressions are explicit non-integer types (for example, "float64(10)"). If such constructs are seen, issue an "invalid array bound" error. This fixes https://golang.or

[PATCH] PowerPC address support clean, patch 2 of 4

These patches were previously posted in March as a RFC, and I would like to check them into the trunk. These patches make the mode_supports* functions use similar names for the functions that return if a mode supports D-FORM, DS-FORM, and/or DQ-FORM instructions, and add the ability to ask whether

[PATCH] PowerPC address support clean, patch 1 of 4

These patches were previously posted in March as a RFC, and I would like to check them into the trunk. These patches make the mode_supports* functions use similar names for the functions that return if a mode supports D-FORM, DS-FORM, and/or DQ-FORM instructions, and add the ability to ask whether

Re: [PATCH] [Microblaze]: PIC Data Text Relative

--resend Michael's reply On Mon, Apr 30, 2018 at 1:19 PM, Michael Eager wrote: > > Applied -- Committed revision 259758. > > Andrew -- Please re-run GCC regression test to verify that nothing > was lost in the editing. > > > > -- > Michael Eagerea...@eagerm.com > 1960 Park Blvd., Palo Alto,

[gomp5] Extend defaultmap clause

Hi! OpenMP 5.0 will extend the defaultmap clause from always just the default(tofrom:scalar) form to have various default behaviors before the : and various categories after the : (plus no : category to cover all categories). There are some issues I've raised on omp-lang, this patch implements wh

Re: [ARM] Fix PR85434: spill of stack protector's guard address

On 05/03/2018 10:55 AM, Segher Boessenkool wrote: > Hi! > > On Wed, May 02, 2018 at 07:57:55AM +0100, Thomas Preudhomme wrote: >> As mentionned in the ticket this was my first thought but this means >> making the pattern aware of all the possible way the address could be >> access (PIC Vs non-PIC,

Re: [PATCH] Define std::remove_cvref and std::remove_cvref_t for C++2a

On 03/05/18 12:59 +0100, Jonathan Wakely wrote: Also define __remove_cvref_t for internal use before C++2a. * include/std/any (any_cast): Use __remove_cvref_t. * include/std/tuple (__make_tuple): Likewise. * include/std/type_traits (__remove_cvref_t): Define. (__r

Re: [ARM] Fix PR85434: spill of stack protector's guard address

Hi! On Wed, May 02, 2018 at 07:57:55AM +0100, Thomas Preudhomme wrote: > As mentionned in the ticket this was my first thought but this means > making the pattern aware of all the possible way the address could be > access (PIC Vs non-PIC, Arm Vs Thumb-2 Vs Thumb-1) to decide how many > scratch re

Re: [PATCH] Add constant folding support for next{after,toward}{,f,l} (PR libstdc++/85466)

On Thu, May 03, 2018 at 06:35:50PM +0200, Jakub Jelinek wrote: > That requires a machine_mode or tree, but I don't have either of those, > nor the caller (fold_const_call_sss) has those. > > I could change it to: > if (flag_signalling_nans > && !flag_finite_math_only > && format->has

Re: [PATCH, rs6000] Add missing vec_max tests

Hi Carl, On Mon, Apr 30, 2018 at 09:52:27AM -0700, Carl Love wrote: > gcc/testsuite/ChangeLog: > > 2018-04-30 Carl Love > * gcc.target/powerpc/vsx-vector-6.h (foo): Add test for vec_max, > vec_trunc. > * gcc.target/powerpc/vsx-vector-6-le.c (dg-final): Update xvcmpeqdp, >

Re: [PATCH] Add constant folding support for next{after,toward}{,f,l} (PR libstdc++/85466)

On Thu, May 03, 2018 at 11:44:09AM +0200, Richard Biener wrote: > > + *RESULT = nextafter (*ARG0, *ARG1) > > + > > + or > > + > > + *RESULT = nexttoward (*ARG0, *ARG1) > > + > > + in format FORMAT. Return true on success. */ > > + > > +static bool > > +fold_const_nextafter (real_val

Re: [PATCH] PR libstdc++/84087 add default arguments to basic_string members (LWG 2268)

On 29/01/18 13:23 +, Jonathan Wakely wrote: This implements LWG DR 2268, which is part of C++14 and so we should have implemented it some time ago. The change should be safe, but I think it's best to wait for Stage 1 rather than changing it now (even though I'll also backport it to the branc

[Aarch64] PR target/83009: Relax strict address checking for store pair lanes

Hi, See below a patch to address PR 83009. Tested with aarch64-linux-gnu bootstrap and regtests for c, c++ and fortran. Ran the adjusted testcase for -mabi=ilp32. Is this OK for gcc-9? Cheers, Andre PR target/83009: Relax strict address checking for store pair lanes The operand constraint for

[testsuite] Add scan-offload-rtl-dump

Hi, I'm posting this patch for the record. I wrote it but haven't found a use for it yet. I find it easier to write asm scans for nvptx than rtl ones. Thanks, - Tom [testsuite] Add scan-offload-rtl-dump 2018-03-28 Tom de Vries * lib/scanoffloadrtl.exp: New file. * doc/sourcebuild.texi

[PATCH] Fix PR85615

We're threading into a loop across an inner exit. Bootstrapped and tested on x86_64-unknown-linux-gnu, applied. Richard. 2018-05-03 Richard Biener PR tree-optimization/85615 * tree-ssa-threadupdate.c (thread_block_1): Only allow exits to loops not nested in BBs loop

[PATCH] PR libstdc++/84535 constrain std::thread constructor

The standard requires that the std::thread constructor is constrained so it can't be called with a first argument of type std::thread. The current implementation only meets that requirement if the constructor is called with one argument, by using deleted overloads. This uses an enable_if constrain

Re: [PATCH][tree-complex.c] PR tree-optimization/70291: Inline floating-point complex multiplication more aggressively

On 03/05/18 10:20, Richard Biener wrote: > On Thu, May 3, 2018 at 10:39 AM, Kyrill Tkachov > wrote: >> >> On 02/05/18 17:45, Wilco Dijkstra wrote: >>> >>> Richard Biener wrote: >>> why use BUILT_IN_ISUNORDERED but not a GIMPLE_COND with UNORDERED_EXPR? Note again that might trap/throw

[PATCH] Use std::invoke_result in std::async instead of std::result_of

* include/std/future (__async_result_of): Use __invoke_result instead of result_of. Tested powerpc64le-linux, committed to trunk. commit b5db9a5482919074071cf9ae7922ad4b8b34549d Author: Jonathan Wakely Date: Wed May 2 20:56:28 2018 +0100 Use std::invoke_result in std::asy

[PATCH] Define std::remove_cvref and std::remove_cvref_t for C++2a

Also define __remove_cvref_t for internal use before C++2a. * include/std/any (any_cast): Use __remove_cvref_t. * include/std/tuple (__make_tuple): Likewise. * include/std/type_traits (__remove_cvref_t): Define. (__result_of_memobj, __result_of_memfun): Use __remov

[PATCH] Fix PR85627 (and more)

The following fixes PR85627 and more generally complex lowering not preserving EH information with -fnon-call-exceptions when replacing complex multiplication or division with a libcall. This requires changing BUILT_IN_COMPLEX_{MUL,DIV} to be no longer declared nothrow - complex lowering (which l

Re: [PATCH, PR82428] Add __builtin_goacc_{gang,worker,vector}_{id,size}

On 01/18/2018 09:55 AM, Tom de Vries wrote: diff --git a/libgomp/testsuite/libgomp.oacc-c-c++-common/gang-static-2.c b/libgomp/testsuite/libgomp.oacc-c-c++-common/gang-static-2.c index 6de739a..e273a79 100644 --- a/libgomp/testsuite/libgomp.oacc-c-c++-common/gang-static-2.c +++ b/libgomp/testsui

Re: [PATCH] Fix the GNU Stack markings on libgcc.a

torsdag 3 maj 2018 kl. 06:19:20 CEST skrev du: > On 05/02/2018 07:05 PM, Magnus Granberg wrote: > > torsdag 3 maj 2018 kl. 01:48:16 CEST skrev du: > >> On 05/02/2018 06:17 PM, Magnus Granberg wrote: > >>> torsdag 3 maj 2018 kl. 01:07:51 CEST skrev Daniel Santos: > Hello > > On 05/0

Re: RFA: Sanitize deprecation messages (PR 84195)

Hi Jeff, Thanks for the review. > The docs still say "Control characters in the string will be replaced > with spaces", but they're being escaped now. That needs to be fixed. Done. > I note you overload the cast operator in your new class. Why not just > use an accessor? Was this style som

Re: [PATCH] Add constant folding support for next{after,toward}{,f,l} (PR libstdc++/85466)

On Sat, 21 Apr 2018, Jakub Jelinek wrote: > Hi! > > This patch adds constant folding for next{after,toward}{,f,l}. > It doesn't handle decimal (we don't have a builtins that would need it), > nor composite modes (IBM double double; nextafter/nexttoward for variable > precision types isn't really

Patch ping (Re: [PATCH] Add _mm512_{,mask_}mullox_epi64 intrinsics (PR target/85530))

On Thu, Apr 26, 2018 at 10:09:48PM +0200, Jakub Jelinek wrote: > ICC apparently has these two intrinsics (why it doesn't have a maskz_ one > is unclear to me) which are like _mm512_{,mask_}mullo_epi64, except they are > available in AVX512F rather than just AVX512DQ and if AVX512DQ is not > enabled

Re: [PATCH] Verify early releasing.html steps in gcc_release -f (PR other/85622)

On Thu, 3 May 2018, Jakub Jelinek wrote: > Hi! > > The following is an attempt to verify two steps from releasing.html > which are needed before the gcc_release is run, but we sometimes forget to > do it before that, so either NEWS in the tarballs doesn't contain info > about the new major releas

Re: [PATCH][tree-complex.c] PR tree-optimization/70291: Inline floating-point complex multiplication more aggressively

On Thu, May 3, 2018 at 10:39 AM, Kyrill Tkachov wrote: > > On 02/05/18 17:45, Wilco Dijkstra wrote: >> >> Richard Biener wrote: >> >>> why use BUILT_IN_ISUNORDERED but not a GIMPLE_COND with >>> UNORDERED_EXPR? Note again that might trap/throw with -fsignalling-nans >>> so better avoid this tran

[PATCH] Verify early releasing.html steps in gcc_release -f (PR other/85622)

Hi! The following is an attempt to verify two steps from releasing.html which are needed before the gcc_release is run, but we sometimes forget to do it before that, so either NEWS in the tarballs doesn't contain info about the new major release at all, or doesn't contain info about the current re

Re: [patch, i386] false dependencies fix

> This patch fixes false dependencies for vmovss, vmovsd, vrcpss, vrsqrtss, > vsqrtss and vsqrtsd > instructions. > > Tested on x86-64/Linux, no new test fails, some SPEC 2006/2017 performance > gains. > Please let me know if something is wrong here and should be changed. Your submission needs a

Re: [PATCH][tree-complex.c] PR tree-optimization/70291: Inline floating-point complex multiplication more aggressively

On 02/05/18 17:45, Wilco Dijkstra wrote: Richard Biener wrote: why use BUILT_IN_ISUNORDERED but not a GIMPLE_COND with UNORDERED_EXPR? Note again that might trap/throw with -fsignalling-nans so better avoid this transform for flag_signalling_nans as well... Both currently trap on signalling

New template for 'gcc' made available

Hello, gentle maintainer. This is a message from the Translation Project robot. (If you have any questions, send them to .) A new POT file for textual domain 'gcc' has been made available to the language teams for translation. It is archived as: http://translationproject.org/POT-files/gcc-

[PATCH] Fix gfortran.dg/pr51434.f90 testcase

As noted in the bug the testcase is bogus. The following should hopefully fix the observed runtime failures on powerpc and arm. I've changed the bug to a FE accepts-invalid one. Committed. Richard. 2018-05-03 Richard Biener PR testsuite/85579 * fortran.dg/pr51434.f90: Trunc

Re: [PATCH 1/2, expr.c] Optimize switch with sign-extended index.

On Thu, May 3, 2018 at 12:05 AM, Jim Wilson wrote: > This improves the code for a switch statement on targets that sign-extend > function arguments, such as RISC-V. Given a simple testcase > > extern void asdf(int); > void foo(int x) { > switch (x) { > case 0: asdf(10); break; > case 1: asd

Re: [RFC] Improve tree DSE

On Wed, May 2, 2018 at 7:39 PM, Jeff Law wrote: > On 05/02/2018 11:36 AM, Richard Biener wrote: >> On May 2, 2018 6:17:50 PM GMT+02:00, Jeff Law wrote: >>> On 05/02/2018 03:27 AM, Richard Biener wrote: On Tue, Apr 10, 2018 at 2:52 AM, Kugan Vivekanandarajah wrote: > I would like to

Re: [testsuite] Add scan-offload-tree-dump

On Wed, 2 May 2018, Tom de Vries wrote: > [ was: [PATCH, 0/2] Add scan-ltrans-tree-dump and scan-wpa-ipa-dump ] > > Likewise, this patch adds scan-offload-tree-dump, and uses it in > testsuite/libgomp.oacc-c/vec.c, fixing the todo there. > > > [ The discussion on how to address to todo started

Re: [PATCH] Build i386's crti.o and crtn.o for x86_64-*-rtems*

Hey! Just thought I'd bump this patch and see if anyone had a chance to look at it! Let me know if you have any questions or would like anything to be different (for eg. to split "x86_64-*-elf*" and "x86_64-*-rtems*" into their own case statements, instead of what I have here. On Tue, May 1, 2018