[C++PATCH] [PR87322] move cp_evaluated up to tsubst all lambda parms

From: Alexandre Oliva A lambda capture variable initialized with a lambda expr taking more than one parameter got us confused. The first problem was that the parameter list was cut short during tsubsting because we tsubsted it with cp_unevaluated_operand. We reset it right after, to tsubst th

Re: [patch, fortran] Move some array packing to front end

Hi, I just compiled gcc-trunk after applying your patches (p8.diff) and H.J. Lu's patches from *Bug 88713* (vectorized code slow vs Flang) fixing rsqrt. Thomas Koenig already confirmed it fixed the problem I recorded there, but figured I'd add t

Re: [PATCH] Updated patches for the port of gccgo to GNU/Hurd

On Thu, Jan 31, 2019 at 7:40 AM Svante Signell wrote: > > As advised by the Debian gcc maintainer Matthias Klose and golang > developer Ian Lance Taylor I'm re-submitting the patches for > the port of gccgo to GNU/Hurd again. Now GOOS value is changed from gnu > to hurd as requested. > > The 12 pa

libgo patch committed: A couple of Hurd fixes for tests

This libgo patch based on a patch by Svante Signell fixes a couple of tests for the Hurd. 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: Add hurd support to os, net, crypto/x509

This libgo patch by Svante Signell adds Hurd support to the os, net, and crypto/x509 packages. Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed to mainline. Ian Index: gcc/go/gofrontend/MERGE === --- gcc/go/gofron

[PATCH] i386: Fix typo in *movoi_internal_avx/movti_internal

PR target/89229 * config/i386/i386.md (*movoi_internal_avx): Set mode to OI for TARGET_AVX512VL. (*movti_internal): Set mode to TI for TARGET_AVX512VL. --- gcc/config/i386/i386.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/gcc/config/i38

libgo patch committed: Add hurd support to syscall package

This libco patch adds hurd support to the syscall package. This is loosely based on a patch by Svante Signell, but I rewrote it to reduce duplication. Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed to mainline. Ian Index: gcc/go/gofrontend/MERGE

libgo patch committed: Add hurd constants to internal/syscall/unix

This patch by Svante Signell adds a couple of hurd constants to internal/syscall/unix. Bootstrapped and ran a few tests on x86_64-pc-linux-gnu. Committed to mainline. Ian Index: gcc/go/gofrontend/MERGE === --- gcc/go/gofrontend/MERG

[PATCH] Fix excess warnings from -Wtype-limits with location wrappers (PR c++/88680)

PR c++/88680 reports excess warnings from -Wtype-limits after the C++ FE's use of location wrappers was extended in r267272 for cases such as: const unsigned n = 8; static_assert (n >= 0 && n % 2 == 0, ""); t.C:3:18: warning: comparison of unsigned expression >= 0 is always true [-Wtype-lim

[PATCH] improve out-of-bounds pointer warning (PR 88771)

The attached patch doesn't avoid the false positive but only improves the warning to make it more readable (as suggested in the PR by Richard for GCC 9). With the patch, for a call like: memcpy (d, s, -1); where d and s are pointers with unknown provenances the patch has GCC in LP32 issue

[PATCH] correct __clear_cache signature

Recent libgcc builds have been triggering -Wbuiltin-declaration-mismatch due to the declaration of the __clear_cache built-in being incompatible with how GCC declares it internally. The attached patch adjusts the libgcc declaration and the one in the manual to match what GCC expects. Tested on x

Re: [Patch] PR rtl-optimization/87763 - generate more bfi instructions on aarch64

On Tue, 2019-02-05 at 21:12 +, Wilco Dijkstra wrote: > +bool > +aarch64_masks_and_shift_for_bfi_p (scalar_int_mode mode, > + unsigned HOST_WIDE_INT mask1, > + unsigned HOST_WIDE_INT shft_amnt, > +

[rs6000] 64-bit integer loads/stores and FP instructions

Hi, as reported e.g. at https://gcc.gnu.org/ml/gcc-help/2018-11/msg00038.html, the 7 series of compilers started to use FP instructions for simple 64-bit integer loads/stores in unexpected ways. Consider: uint64_t var; void foo1 (uint64_t *p) { var = *p; } void foo2 (uint64_t *p) { *p =

patch to fix PR89225

  The following patch fixes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89225   The patch was bootstrapped and tested on x86-64.   Committed as rev. 268597. Index: ChangeLog === --- ChangeLog (revision 268596) +++ ChangeLog (work

[patch, committed] Test case for PR 71860

Hi, I have committed the attached test case as obvious, to trunk, as r268590 (after checking that it passes). The PR is marked as a 7/8/9 regression. I plan to wait for a few days to see if anything comes up, then also commit to the other open branches (I have already checked that it passes the

[PATCH] PR libstdc++/89164 enforce constraints for uninitialized algos

The memmove optimizations for std::uninitialized_copy/fill/_n will compile even if the type is not copy constructible, because std::copy doesn't require copy construction to work. But the uninitialized algorithms do require it. This adds explicit static assertions to ensure we don't allow ill-for

libgo patch committed: Use strong form of atomic_compare_exchange_n

In GCC PR 89199 Lynn Boger points out that I used the weak form of atomic_compare_exchange_n. The upstream library uses, in effect, the strong form, and the rest of the library expects the strong form. This patch fixes libgo accordingly. Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.

[patch, fortran] Fix PR 71237

Hello world, this patch fixes a 7/8/9 regression where we tried to accept invalid code, which led to an ICE later on. The patch is rather straightforward. The reason why I could not use gfc_expr_attr is that it does not actually return the flags the way they can be found in the original attribu

[committed] Fix locations in conversion_null_warnings (PR c++/71302)

PR c++/71302 reports that g++ shows poor locations for -Wzero-as-null-pointer-constant for pointers in function calls, using the close parenthesis of the call, rather than showing the pertinent argument. This particular case was fixed in GCC 8, but regressed on trunk in r260973. This patch fixes

New Esperanto PO file for 'cpplib' (version 9.1-b20190203)

Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'cpplib' has been submitted by the Esperanto team of translators. The file is available at: https://translationproject.org/latest/cpplib/eo.po (This file, 'cpplib-9.1-b20190

Contents of PO file 'cpplib-9.1-b20190203.eo.po'

cpplib-9.1-b20190203.eo.po.gz Description: Binary data The Translation Project robot, in the name of your translation coordinator.

Re: [Patch] [arm] Fix 88714, Arm LDRD/STRD peepholes

Hi Matthew, On 05/02/19 14:44, Matthew Malcomson wrote: These peepholes match a pair of SImode loads or stores that can be implemented with a single LDRD or STRD instruction. When compiling for TARGET_ARM, these peepholes originally created a set pattern in DI mode to be caught by movdi patterns

Re: [PATCH doc] correct/expand -Wreturn-type

On 2/6/19 10:20 AM, Jakub Jelinek wrote: On Wed, Feb 06, 2019 at 10:15:27AM -0700, Martin Sebor wrote: -For C++, a function without return type always produces a diagnostic -message, even when @option{-Wno-return-type} is specified. The only -exceptions are @code{main} and functions defined in

Re: [Aarch64][SVE] Vectorise sum-of-absolute-differences

On Mon, Feb 04, 2019 at 07:34:05AM -0600, Alejandro Martinez Vicente wrote: > Hi, > > This patch adds support to vectorize sum of absolute differences (SAD_EXPR) > using SVE. It also uses the new functionality to ensure that the resulting > loop > is masked. Therefore, it depends on > > https://

Re: [PATCH][AArch64] Use implementation namespace consistently in arm_neon.h

Hi James, On 06/02/19 17:27, James Greenhalgh wrote: On Wed, Feb 06, 2019 at 07:52:42AM -0600, Kyrill Tkachov wrote: [resending with patch compressed] Hi all, We're somewhat inconsistent in arm_neon.h when it comes to using the implementation namespace for local identifiers. This means thing

Re: [PATCH] PR libstdc++/89102 fix common_type<> and common_type specializations

On 06/02/19 17:25 +, Jonathan Wakely wrote: This is a partial implementation of the revised std::common_type rules from P0435R1. PR libstdc++/89102 (partial) * include/std/type_traits (common_type<>): Define. (common_type): Derive from common_type. * testsuite

Re: [PATCH doc] correct/expand -Wreturn-type

On Wed, Feb 06, 2019 at 06:20:35PM +0100, Jakub Jelinek wrote: > "For C++, flowing off the end of a function other than @code{main} is Oops, either replace function above with value-returning function, or non-@code{void} function. > undefined even if the return value from the function is not used

Re: [PATCH][AArch64] Change representation of SABD in RTL

On Mon, Feb 04, 2019 at 04:23:32AM -0600, Kyrill Tkachov wrote: > Hi all, > > Richard raised a concern about the RTL we use to represent the AdvSIMD SABD > (vector signed absolute difference) instruction. > We currently represent it as ABS (MINUS op1 op2). > > This isn't exactly what SABD does. A

Re: [PATCH][AArch64] Use neon_dot_q type for 128-bit [US]DOT instructions where appropriate

On Tue, Feb 05, 2019 at 11:52:10AM -0600, Kyrill Tkachov wrote: > Hi all, > > For the Dot Product instructions we have the scheduling types neon_dot and > neon_dot_q for the 128-bit versions. > It seems that we're only using the former though, not assigning the > neon_dot_q type anywhere. > > T

Re: [PATCH][AArch64] Use implementation namespace consistently in arm_neon.h

On Wed, Feb 06, 2019 at 07:52:42AM -0600, Kyrill Tkachov wrote: > [resending with patch compressed] > > Hi all, > > We're somewhat inconsistent in arm_neon.h when it comes to using the > implementation namespace for local > identifiers. This means things like: > #define hash_abcd 0 > #define has

Re: [testsuite] Fix gcc.dg/debug/dwarf2/inline5.c with Solaris as (PR debug/87451)

On February 6, 2019 3:47:19 PM GMT+01:00, Rainer Orth wrote: >Hi Richard, > >> On Fri, 4 Jan 2019, Rainer Orth wrote: >> >>> Hi Richard, >>> >>> >> On Thu, 3 Jan 2019, Rainer Orth wrote: >>> >> >>> >>> gcc.dg/debug/dwarf2/inline5.c currently FAILs with Solaris as >(both >>> >>> sparc and x86): >

[PATCH] PR libstdc++/89102 fix common_type<> and common_type specializations

This is a partial implementation of the revised std::common_type rules from P0435R1. PR libstdc++/89102 (partial) * include/std/type_traits (common_type<>): Define. (common_type): Derive from common_type. * testsuite/20_util/common_type/requirements/explicit_instan

Re: [PATCH doc] correct/expand -Wreturn-type

On Wed, Feb 06, 2019 at 10:15:27AM -0700, Martin Sebor wrote: > > > -For C++, a function without return type always produces a diagnostic > > > -message, even when @option{-Wno-return-type} is specified. The only > > > -exceptions are @code{main} and functions defined in system headers. > > > +For

Re: [PATCH doc] correct/expand -Wreturn-type

On 2/6/19 9:56 AM, Jakub Jelinek wrote: On Wed, Feb 06, 2019 at 09:51:59AM -0700, Martin Sebor wrote: -For C++, a function without return type always produces a diagnostic -message, even when @option{-Wno-return-type} is specified. The only -exceptions are @code{main} and functions defined in s

Re: [gmane.comp.gdb.patches] [RFA] Fix splay tree KEY leak detected in GDB test gdb.base/macscp.exp

On February 6, 2019 2:59:21 PM GMT+01:00, Tom Tromey wrote: >Philippe Waroquiers found another splay-tree memory leak and sent this >patch to the gdb patch list. I'm forwarding it here, as splay-tree is >canonically maintained in gcc; if approved I will check it in for him. > >Note that the analy

Re: [PATCH][wwwdocs][Arm][AArch64] Update changes with new features and flags.

Hi Gerald, I've updated the patch with your suggested changes and have grouped the Arm and AArch64 targets a bit. Ok for commit? Thanks, Tamar The 01/31/2019 10:21, Ramana Radhakrishnan wrote: > > > On Thu, 31 Jan 2019, 10:09 Tamar Christina > mailto:tamar.christ...@arm.com> wrote: > Hi Gera

Re: [PATCH doc] correct/expand -Wreturn-type

On Wed, Feb 06, 2019 at 09:51:59AM -0700, Martin Sebor wrote: > -For C++, a function without return type always produces a diagnostic > -message, even when @option{-Wno-return-type} is specified. The only > -exceptions are @code{main} and functions defined in system headers. > +For C++, calling a

[PATCH doc] correct/expand -Wreturn-type

A recent flurry of bug reports about wrong code in C++ due to flowing (AKA falling) off the end of a function prompted me to look at what the manual has to say about the undefined behavior that the warning is meant to point out. It turns out that the manual not only doesn't mention it, but it als

Go patch committed: Update README

This patch updates the go/gofrontend/README file, which had gotten very out of date, and had diverged from the version in the GCC repo. Committed to mainline. Ian Index: gcc/go/gofrontend/MERGE === --- gcc/go/gofrontend/MERGE (rev

[PATCH doc] correct/improve -Wmissing-attributes and -Wattribute-alias

The manual documents the -Wno-missing-attributes form of the option as if it was enabled by default, even though it's enabled by -Wall (I can't get this -Wno- convention straight in my head). I also got private comments on the documentation of the option suggesting to add cross-references, and to

New Russian PO file for 'cpplib' (version 9.1-b20190203)

Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'cpplib' has been submitted by the Russian team of translators. The file is available at: https://translationproject.org/latest/cpplib/ru.po (This file, 'cpplib-9.1-b2019020

Contents of PO file 'cpplib-9.1-b20190203.ru.po'

cpplib-9.1-b20190203.ru.po.gz Description: Binary data The Translation Project robot, in the name of your translation coordinator.

RE: [PATCH][GCC][AArch64] Fix command line options canonicalization. (PR target/88530)

Friendly Ping, is there anything I can do to move this one along? Thanks, Tamar > -Original Message- > From: gcc-patches-ow...@gcc.gnu.org > On Behalf Of Tamar Christina > Sent: Wednesday, January 30, 2019 14:02 > To: Kyrill Tkachov > Cc: gcc-patches@gcc.gnu.org; nd ; James Greenhalgh >

Re: [testsuite] Fix gcc.dg/debug/dwarf2/inline5.c with Solaris as (PR debug/87451)

Hi Richard, > On Fri, 4 Jan 2019, Rainer Orth wrote: > >> Hi Richard, >> >> >> On Thu, 3 Jan 2019, Rainer Orth wrote: >> >> >> >>> gcc.dg/debug/dwarf2/inline5.c currently FAILs with Solaris as (both >> >>> sparc and x86): >> >>> >> >>> FAIL: gcc.dg/debug/dwarf2/inline5.c scan-assembler-not (

Re: [C++ Patch] PR 88986 ("[7/8/9 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'error_mark' in member_vec_binary_search, at cp/name-lookup.c:1136")

... the below passes testing on x86_64-linux. Note, we have to handle separately the empty pack case, otherwise we don't emit any diagnostics and we crash pretty soon. Thanks, Paolo. / Index: cp/decl.c =

Re: [PATCH][GCC][Arm] Fix NEON REG to REG reload failures. (PR/target 88850)

On 06/02/19 14:28, Tamar Christina wrote: > Hi Kyrill, > > > > > So you add a new alternative but don't modify any of the output logic, which > > means it will use output_move_double. Can that handle an "r,r" alternative? > > Or do you expect a split to always happen here? If so, the output should

RE: [PATCH][GCC][Arm] Fix NEON REG to REG reload failures. (PR/target 88850)

Hi Kyrill, > > So you add a new alternative but don't modify any of the output logic, which > means it will use output_move_double. Can that handle an "r,r" alternative? > Or do you expect a split to always happen here? If so, the output should be > '#' Yes.. so output_move_double can't indeed h

Re: [RS6000] Set uses_pic_offset_table on sysv secure-plt calls and tls.

On Wed, Feb 06, 2019 at 05:45:17AM -0600, Segher Boessenkool wrote: > On Wed, Feb 06, 2019 at 04:43:18PM +1030, Alan Modra wrote: > > Segher, you'll recognize these as your patches from pr88343. All I've > > done here is give you a testcase for the legitimize_tls_address change > > (which you said

[gmane.comp.gdb.patches] [RFA] Fix splay tree KEY leak detected in GDB test gdb.base/macscp.exp

Philippe Waroquiers found another splay-tree memory leak and sent this patch to the gdb patch list. I'm forwarding it here, as splay-tree is canonically maintained in gcc; if approved I will check it in for him. Note that the analysis from the previous splay-tree patch applies here as well: there

Re: [PATCH][GCC][Arm] Fix NEON REG to REG reload failures. (PR/target 88850)

Hi Tamar, On 05/02/19 10:13, Tamar Christina wrote: Hi All, We currently return cost 2 for NEON REG to REG moves, which would be incorrect for 64 bit moves. We currently don't have a pattern for this in the neon_move alternatives because this is a bit of a special case. We would almost never

[PATCH][AArch64] Use implementation namespace consistently in arm_neon.h

[resending with patch compressed] Hi all, We're somewhat inconsistent in arm_neon.h when it comes to using the implementation namespace for local identifiers. This means things like: #define hash_abcd 0 #define hash_e 1 #define wk 2 #include "arm_neon.h" uint32x4_t foo (uint32x4_t a, uint32_t

Re: [v3 PATCH, RFC] Rewrite variant. Also PR libstdc++/85517

On Wed, 6 Feb 2019 at 12:21, Ville Voutilainen wrote: > > I think the assumption was this would produce smaller code. Does that > > hold true? > > I think the assumption was that this produces equivalent or better > code than fixing the current > semantics bugs with some sort of separate constexpr

Re: [RS6000] Set uses_pic_offset_table on sysv secure-plt calls and tls.

On Wed, Feb 06, 2019 at 05:45:17AM -0600, Segher Boessenkool wrote: > On Wed, Feb 06, 2019 at 04:43:18PM +1030, Alan Modra wrote: > > Segher, you'll recognize these as your patches from pr88343. All I've > > done here is give you a testcase for the legitimize_tls_address change > > (which you said

Re: Make clear, when contributions will be ignored

On Fri, Dec 07, 2018 at 10:55:11AM +, Дилян Палаузов wrote: > will it help, if Bugzilla is reprogrammed to send automatically weekly > reminders on all patches, that are not integrated yet? No, that will not help. If an interested party sends a friendly ping, that is of course welcome. But au

Re: [RS6000] Set uses_pic_offset_table on sysv secure-plt calls and tls.

> On 6 Feb 2019, at 11:45, Segher Boessenkool > wrote: > > On Wed, Feb 06, 2019 at 04:43:18PM +1030, Alan Modra wrote: >> Segher, you'll recognize these as your patches from pr88343. All I've >> done here is give you a testcase for the legitimize_tls_address change >> (which you said you had

[Ada] fix gnatlib build on x32 runtime

This has been reported on https://github.com/mattgodbolt/compiler-explorer-image/issues/161 The failure has been introduced 2018-11-14 when updating the list of signals in s-linux*.ads files, s-linux__x32.ads was forgotten. Tested on x86_64-pc-linux-gnu, committed on trunk. 2019-02-06 Arnaud C

Re: [RS6000] Set uses_pic_offset_table on sysv secure-plt calls and tls.

On Wed, Feb 06, 2019 at 04:43:18PM +1030, Alan Modra wrote: > Segher, you'll recognize these as your patches from pr88343. All I've > done here is give you a testcase for the legitimize_tls_address change > (which you said you had no idea what the patch was for!) I don't see a testcase, and the r

Re: [PATCH, rs6000] Fix instruction counts on powerpc64 test cases. (take 2)

Hi Bill, On Tue, Feb 05, 2019 at 02:14:16PM -0600, Bill Seurer wrote: > [PATCH, rs6000] Fix instruction counts on powerpc64 test cases. > > This patch fixes the assembler instruction counts for some test cases > that started failing due to changes in code generation. The targets > were adjusted

Re: [i386] Fix wrong argument value on Windows

> this is a regression present on all active branches: if you compile the > attached Ada testcase with -O2 -gnatp -fno-omit-frame-pointer for 32-bit > Windows, you'll see that the compiler swaps a load based on the stack pointer > with a store based on the frame pointer, thus clobbering a saved arg

Re: [v3 PATCH, RFC] Rewrite variant. Also PR libstdc++/85517

On Wed, 6 Feb 2019 at 12:13, Jonathan Wakely wrote: > Did you compare the codegen? No. Getting the metaprograms to work took all the time I had thus far. :) > I think the assumption was this would produce smaller code. Does that > hold true? I think the assumption was that this produces equival

[i386] Fix wrong argument value on Windows

Hi, this is a regression present on all active branches: if you compile the attached Ada testcase with -O2 -gnatp -fno-omit-frame-pointer for 32-bit Windows, you'll see that the compiler swaps a load based on the stack pointer with a store based on the frame pointer, thus clobbering a saved arg

Re: [v3 PATCH, RFC] Rewrite variant. Also PR libstdc++/85517

On 06/02/19 00:05 +0200, Ville Voutilainen wrote: Okay then. This patch takes the hopefully biggest steps towards a std::variant rewrite. The problem we have with the current approach is that we'd really like to write fairly straightforward code for variant's special member functions, but can't,

[PATCH] Fix PR89182

This adds a cache around scalar_evolution_in_region avoiding re-analysis during code-generation where out-of-date SSA form can cause minor differences in SCEV analysis (follow_copies_to_constant ...). Bootstrap and regtest running on x86_64-unknown-linux-gnu. It leaves a (tiny) hole via scev_an

Re: [PATCH] Fix fold_const_vec_convert (PR middle-end/89210)

Jakub Jelinek writes: > Hi! > > Apparently VECTOR_CSTs shouldn't be stepped if they contain floating > elements and also widening conversions can be problematic if there is > wrapping in the narrower type. On the following testcase, we create a > stepped VECTOR_CST with REAL_CST elts and ICE when