Re: [PATCH] attribs: Don't diagnose attribute exclusions during error recovery [PR94705]

On Wed, 22 Apr 2020, Jakub Jelinek wrote: > Hi! > > On the following testcase GCC ICEs, because last_decl is error_mark_node, > and diag_attr_exclusions assumes that if it is not NULL, it must be a decl. > > The following patch just doesn't diagnose attribute exclusions if the > other decl is

Re: [PATCH] Do not remove ifunc_resolver in LTO.

On 4/22/20 8:11 PM, Jan Hubicka wrote: On Mon, 2020-04-20 at 11:34 +0200, Martin Liška wrote: Hi. The patch prevents a ifunc alias from removal in remove unreachable nodes. Note that ifunc alias lives in a COMDAT section and so that cgraph_node::can_remove_if_no_direct_calls_and_refs_p

Re: [PATCH] libstdc++: don't use #include_next in c_global headers

Hi, On Mon, Apr 20, 2020 at 10:12:37AM +0100, Jonathan Wakely wrote: > > Now you are probably going to say that "-isystem /usr/include" is a bad > > idea and that you shouldn't do that. > > Right. > > > I'm inclined to agree. This isn't a > > problem just yet. Debian wants to move

[PATCH] c++: Explicit constructor called in copy-initialization [PR90320]

This test is rejected with a bogus "use of deleted function" error starting with r225705 whereby convert_like_real/ck_base no longer sets LOOKUP_ONLYCONVERTING for user_conv_p conversions. This does not seem to be always correct. To recap, when we have something like T t = x where T is a class

Re: [RFC] split pseudos during loop unrolling in RTL unroller

On Wed, 2020-04-22 at 15:50 -0500, Segher Boessenkool wrote: > > > > In some ways it feels like it would be easier to resurrect RTL SSA :-) > > Why was RTL SSA abandoned? > > It might well work to keep everything in SSA form all the way to RA. > Hrm, that doesn't sound bad at all :-) > > (The

Re: [PATCH] c++: Fix misuse of "override" in -Weffc++ warnings (PR 94698)

On 22/04/20 20:43 +0100, Jonathan Wakely wrote: On 22/04/20 15:33 -0400, Jason Merrill wrote: On Wed, Apr 22, 2020 at 3:31 PM Jonathan Wakely wrote: On 22/04/20 15:19 -0400, Jason Merrill wrote: On 4/22/20 2:37 AM, Jonathan Wakely wrote: These warnings have nothing to do with virtual

Re: [PATCH] rs6000: Fix C++14 vs. C++17 ABI bug on powerpc64le [PR94707]

Hi! On Wed, Apr 22, 2020 at 03:11:48PM +0200, Jakub Jelinek wrote: > The problem is that the presence or absence of the C++17 > artificial empty base fields, which have non-zero TYPE_SIZE, but zero > DECL_SIZE, change the ABI decisions, if it is present (-std=c++17), the type > might not be

[PATCH] PR preprocessor/94657: use $AR, not 'ar',

From: Sergei Trofimovich On system with 'ar' and '${CHOST}-ar' the latter is preferred. as it might not match default 'ar'. Bug is initially reported downstream as https://bugs.gentoo.org/718004. libcpp/ChangeLog: PR libcpp/94657 * Makefile.in: use @AR@ placeholder *

[committed 8/8] libstdc++: Define __cpp_lib_execution feature test macro

This macro has never been defined by libstdc++, despite supporting the parallel algorithms. It should have a different value for C++17 and C++20, because P1001R2 should not be supported in C++17, but unsequenced_policy is defined for C++17 (see PR p4702). * include/std/execution

[committed 7/8] libstdc++: Update (and revert) value of __cpp_lib_array_constexpr

This macro should have been updated to 201811 when the last C++20 changes were implemented. However those changes are not enabled for C++17 mode, so the macro should only have the new value in C++20 mode. This change ensures that the macro is defined to 201603 for C++17 and 201811 for C++20.

[committed 4/8] libstdc++: Rename __cpp_lib_constexpr_invoke macro

This macro was renamed after it was added to the working draft, but we never renamed it in libstdc++. We haven't made a release with the old macro name, so I see no need to keep it around. * include/std/functional (__cpp_lib_constexpr_invoke): Rename to

[committed 6/8] libstdc++: Do not define __cpp_lib_constexpr_algorithms in

The C++20 draft and SD-6 both say this should only be in and , not in . * include/std/utility (__cpp_lib_constexpr_algorithms): Do not define here. * testsuite/20_util/exchange/constexpr.cc: Do not expect macro to be defined by . --- libstdc++-v3/ChangeLog

[committed 3/8] libstdc++: Add missing feature test macros

These macros all correspond to features that are already supported, but the macro was not defined when the feature was implemented. * include/bits/ptr_traits.h (__cpp_lib_constexpr_memory): Define to indicate P1006R1 support. (__cpp_lib_to_address): Define to indicate

[committed 5/8] libstdc++: Update __cpp_lib_concepts value

* include/std/functional (__cpp_lib_concepts): Update macro value to indicate P1964R2 support. * include/std/version (__cpp_lib_concepts): Likewise. * testsuite/std/concepts/1.cc: Adjust expected value. * testsuite/std/concepts/2.cc: Likewise. ---

[committed 2/8] libstdc++: Remove non-standard feature test macros

These macros were replaced by __cpp_lib_map_try_emplace and __cpp_lib_unordered_map_try_emplace, because those names are more descriptive. We've kept both old and new names so far, but I think we can remove the old ones now. * include/bits/stl_map.h (__cpp_lib_map_insertion): Remove old

[committed 1/8] libstdc++: Update value of __cpp_lib_jthread macro

* include/std/condition_variable (__cpp_lib_jthread): Remove redundant definition. * include/std/stop_token (__cpp_lib_jthread): Update macro value to indicate P1869R1 support. * include/std/version (__cpp_lib_jthread): Update value. *

[committed 0/8] libstdc++: Add/update/fix feature test macros

This series of patches fixes a number of omissions and errors in the feature test macros we define. Tested powerpc64le-linux, committed to master. Jonathan Wakely (8): libstdc++: Update value of __cpp_lib_jthread macro libstdc++: Remove non-standard feature test macros libstdc++: Add

[PATCH] handle initialized flexible array members in __builtin_object_size [PR92815]

When computing the size of an object with a flexible array member the object size pass doesn't consider that the initializer of such an object can result in its size being in excess of the size of the enclosing type. As a result, stores into such objects by string functions causes false positive

[PATCH] amdgcn: Add stub personality function

Hello This patch adds a stub implementation of __gxx_personality_v0, which is used in C++ exception handling. AMD GCN currently does not actually support exception handling (the unwind functions are all stubs too), so adding an extra stub function does not regress the current level of

[PATCH] attribs: Don't diagnose attribute exclusions during error recovery [PR94705]

Hi! On the following testcase GCC ICEs, because last_decl is error_mark_node, and diag_attr_exclusions assumes that if it is not NULL, it must be a decl. The following patch just doesn't diagnose attribute exclusions if the other decl is erroneous (and thus we've already reported errors for it).

Re: [RFC] split pseudos during loop unrolling in RTL unroller

On Wed, Apr 22, 2020 at 11:58:38AM +0200, Richard Biener wrote: > On Wed, Apr 22, 2020 at 11:26 AM Richard Sandiford > wrote: > > Richard Biener via Gcc-patches writes: > > > On Mon, Apr 20, 2020 at 3:38 PM Segher Boessenkool > > > wrote: > > >> On Mon, Apr 20, 2020 at 09:56:34AM +0200, Richard

[PATCH] aarch64: eliminate redundant zero extend after bitwise negation

Hello, The attached patch eliminates a redundant zero extend from the AArch64 backend. Given the following C code: unsigned long long foo(unsigned a) { return ~a; } prior to this patch, AArch64 GCC at -O2 generates: foo: mvn w0, w0 uxtwx0, w0 ret but the

Re: [PATCH] coroutines, libstdc++-v3: Update headers to n4861 C++20 DIS.

On 22/04/20 19:44 +0100, Iain Sandoe wrote: Hi, this is a bit of ‘housekeeping’ bringing the coroutines library header into line with the C++20 DIS. Note that we allow coroutines on C++14+ (probably they would work on C++11 too, but that’s untested). So the header reflects this by exporting

Re: [PATCH] c++: Fix misuse of "override" in -Weffc++ warnings (PR 94698)

On 22/04/20 15:33 -0400, Jason Merrill wrote: On Wed, Apr 22, 2020 at 3:31 PM Jonathan Wakely wrote: On 22/04/20 15:19 -0400, Jason Merrill wrote: >On 4/22/20 2:37 AM, Jonathan Wakely wrote: >>These warnings have nothing to do with virtual functions, so "override" >>is inappropriate. The

Re: [PATCH] c++: Fix misuse of "override" in -Weffc++ warnings (PR 94698)

On Wed, Apr 22, 2020 at 3:31 PM Jonathan Wakely wrote: > On 22/04/20 15:19 -0400, Jason Merrill wrote: > >On 4/22/20 2:37 AM, Jonathan Wakely wrote: > >>These warnings have nothing to do with virtual functions, so "override" > >>is inappropriate. The warnings are just talking about defining

Re: [PATCH] c++: Fix misuse of "override" in -Weffc++ warnings (PR 94698)

On 22/04/20 15:19 -0400, Jason Merrill wrote: On 4/22/20 2:37 AM, Jonathan Wakely wrote: These warnings have nothing to do with virtual functions, so "override" is inappropriate. The warnings are just talking about defining special members, so let's say that. PR translation/94698

Re: [PATCH] c++: Add test for c++/93807

On 4/21/20 6:29 PM, Marek Polacek wrote: This PR was initially accepts-invalid, but I think it's actually valid C++20 code. My reasoning is that in C++20 we no longer require the declaration of operator== (#if-defed in the test), because C++20's [temp.names]/2 says "A name is also considered to

[PATCH v2] aarch64: Add TX3 machine model

Yes, Bellsoft's contribution is to be covered under the Marvell copyright assignment, as this is a work for hire. Joel >Yes, Bellsoft's contribution is to be covered under the Marvell copyright >assignment, as this is a work for hire. > >Joel > >>>Hi Anton, >>> -Original Message-

Re: [PATCH] c++: Fix misuse of "override" in -Weffc++ warnings (PR 94698)

On 4/22/20 2:37 AM, Jonathan Wakely wrote: These warnings have nothing to do with virtual functions, so "override" is inappropriate. The warnings are just talking about defining special members, so let's say that. PR translation/94698 * class.c (check_field_decls): Change

Re: [PATCH] c++: Inherited constructor template arguments [PR94719]

On 4/22/20 2:55 PM, Patrick Palka wrote: My fix for PR94549 broke constraints_satisfied_p in the case where the inherited constructor decl points to an instantiation of a constructor template coming from an instantiation of a class template. This is because the DECL_TI_ARGS of the inherited

[PATCH] c++: Inherited constructor template arguments [PR94719]

My fix for PR94549 broke constraints_satisfied_p in the case where the inherited constructor decl points to an instantiation of a constructor template coming from an instantiation of a class template. This is because the DECL_TI_ARGS of the inherited constructor decl in this case contains only

[PATCH] coroutines, libstdc++-v3: Update headers to n4861 C++20 DIS.

Hi, this is a bit of ‘housekeeping’ bringing the coroutines library header into line with the C++20 DIS. Note that we allow coroutines on C++14+ (probably they would work on C++11 too, but that’s untested). So the header reflects this by exporting the __cpp_lib_coroutine define from then,

[PATCH] [Stage1] Refactor tree-ssa-operands.c

This patch refactors tree-ssa-operands.c by wrapping the global variables into a class, and also removes unused code. Just sending this for when Stage1 is back again. I ran the testsuite and bootstraped in a x86_64 linux machine and found no issues. gcc/ChangeLog: 2020-04-22 Giuliano Belinassi

Re: [RFC][PR target PR90000] (rs6000) Compile time hog w/impossible asm constraint lra loop

On Fri, 2020-04-10 at 16:40 -0500, will schmidt via Gcc-patches wrote: > [RFC][PR target/9] Compile time hog w/impossible asm constraint lra loop > > Hi, > RFC for a bandaid/patch to partially address target PR/9. > > This adds an escape condition from the forever loop where > LRA

Re: [PING] [PATCH] [ARM] Adjust test expectations of unaligned-memcpy-2/3.c (PR 91614)

On Thu, 2020-03-26 at 04:23 +0100, Bernd Edlinger wrote: > Hi, > > I am pinging this because PR 91614 has been raised to P2 now: > https://gcc.gnu.org/legacy-ml/gcc-patches/2019-09/msg00370.html It's been nearly a month since the ping and many since the patch was posted originally. I interpret

[PATCH] rs6000, Fix header comment for intrinsic function

GCC maintainers: The following is a trivial patch to fix a comment describing the intrinsic function _mm_movemask_epi8. The comment was expanded to clarify the layout of the returned result. The patch does not make any functional changes. Please let me know if the patch is OK for mainline

Re: introduce target tmpnam and require it in tests relying on it

On Fri, 2020-04-17 at 14:48 -0300, Alexandre Oliva wrote: > On Apr 9, 2020, Alexandre Oliva wrote: > > > Some target C libraries that aren't recognized as freestanding don't > > have filesystem support, so calling tmpnam, fopen/open and > > remove/unlink fails to link. > > This patch introduces

Re: [PATCH] Do not remove ifunc_resolver in LTO.

> On Mon, 2020-04-20 at 11:34 +0200, Martin Liška wrote: > > Hi. > > > > The patch prevents a ifunc alias from removal in remove unreachable nodes. > > Note that ifunc alias lives in a COMDAT section and so that > > cgraph_node::can_remove_if_no_direct_calls_and_refs_p returned true for it. > >

Re: [PATCH] Do not remove ifunc_resolver in LTO.

On Mon, 2020-04-20 at 11:34 +0200, Martin Liška wrote: > Hi. > > The patch prevents a ifunc alias from removal in remove unreachable nodes. > Note that ifunc alias lives in a COMDAT section and so that > cgraph_node::can_remove_if_no_direct_calls_and_refs_p returned true for it. > > Patch can

Re: [PATCH v5 GCC] libffi/test: Fix compilation for build sysroot

On Mon, 2020-04-20 at 14:18 +0100, Maciej W. Rozycki wrote: > Fix a problem with the libffi testsuite using a method to determine the > compiler to use resulting in the tool being different from one the > library has been built with, and causing a catastrophic failure from the > inability to

Re: [PATCH] csa, postreload: Improve csa after recent cselib changes [PR94516]

On Tue, 2020-04-21 at 01:00 +0200, Jakub Jelinek wrote: > Hi! > > This patch addresses a missed optimization caused by the cselib changes. > Already in the past postreload could replace sp = sp + const_int with > sp = regxy if regxy already has the right value, but with the cselib > changes it

Re: [PATCH] add missing -Wno-stack-usage etc. options [PR90983]

On Tue, 2020-04-21 at 13:37 -0600, Martin Sebor via Gcc-patches wrote: > In addition to accepting argument values in excess of INT_MAX in > options like -Walloca-larger-than=byte-size, GCC 9 has changed > the behavior of such options with byte-size of zero. While in prior > versions zero disables

Re: [PATCH] aarch64：Add an error message in large code model for ilp32 [PR94577]

"duanbo (C)" writes: > Hi > > Thank you for your suggestions. > I have adjust the testcases and used this command to test . > "runtest --tool gcc --tool_opts -mabi=ilp32 aarch64.exp= > reload-valid-spoff.c" > > The results of those tests changed from unexpected failures to > unsupported.

Re: Ping: [PATCH] wwwdocs: Document support for extended identifiers added to GCC 10

On Wed, Mar 11, 2020 at 9:12 AM Lewis Hyatt wrote: > On Sat, Mar 7, 2020 at 6:23 PM Gerald Pfeifer wrote: > > > > On Tue, 25 Feb 2020, Lewis Hyatt wrote: > > > Just checking whether the below is OK for gcc 10 changes.html please. > > > Thanks! > > >

Re: [PATCH PR94678] aarch64: unexpected result with -mgeneral-regs-only and sve

"Yangfei (Felix)" writes: > Hi, > >> -Original Message- >> From: Richard Sandiford [mailto:richard.sandif...@arm.com] >> Sent: Wednesday, April 22, 2020 6:03 PM >> To: Yangfei (Felix) >> Cc: gcc-patches@gcc.gnu.org >> Subject: Re: [PATCH PR94678] aarch64: unexpected result with

Re: [wwwdocs] Update list of new C++20 features in libstdc++

On 21/04/20 20:30 +0100, Jonathan Wakely wrote: Committed to wwwdocs. commit ba9d172720e36f93daf9c1b4569d4babe34e307e Author: Jonathan Wakely Date: Tue Apr 21 20:28:48 2020 +0100 Update list of new C++20 features in libstdc++ diff --git a/htdocs/gcc-10/changes.html

Re: [PATCH] free() was missing from a part of the documentation

On Tue, 2020-04-21 at 18:18 -0600, Zackery Spytz via Gcc-patches wrote: > Hello, > > The free() function was missing from a part of the documentation! Thanks. I've pushed this fix to the trunk. jeff >

Re: [rtl] Harden 'set_noop_p' for non-constant selectors [PR94279]

Andrew Stubbs writes: > On 22/04/2020 17:43, Thomas Schwinge wrote: >> In "[amdgcn] internal compiler error: RTL >> check: expected code 'const_int', have 'reg' in rtx_to_poly_int64, at >> rtl.h:2379", we recently found that that it's wrong to expect constant >>

Re: [PATCH] Update documentation on optimizations turned on by O3

On Wed, 2020-04-22 at 17:14 +0200, Erick Ochoa wrote: > Hello, > > I noted that the optimizations turned on by O3 was outdated in the > documentation. Here is the discussion that brought it to my attention: > https://gcc.gnu.org/pipermail/gcc/2020-April/232164.html THanks. I've created a

[PATCH, libgfortran] Protect the trigd functions in libgfortran from unavailable math functions [PR94586, PR94694]

This patch here is a follow-on to Jakub's in his message "[PATCH] libgfortran: Provide some further math library fallbacks [PR94694]" at https://gcc.gnu.org/pipermail/fortran/2020-April/054252.html. I think this should be committed along with Jakub's patch in response to PRs 94586 and 94694.

Re: [PATCH] libgfortran: Provide some further math library fallbacks [PR94694]

On Wed, 2020-04-22 at 16:42 +0200, Jakub Jelinek via Gcc-patches wrote: > Hi! > > The following patch provides some further math library fallbacks. > fmaf can be implemented using fma if available, fma and fmal can use > x * y + z as fallback, it is not perfect, but e.g. glibc on various arches >

Re: [rtl] Harden 'set_noop_p' for non-constant selectors [PR94279]

On 22/04/2020 17:43, Thomas Schwinge wrote: In "[amdgcn] internal compiler error: RTL check: expected code 'const_int', have 'reg' in rtx_to_poly_int64, at rtl.h:2379", we recently found that that it's wrong to expect constant selectors, at least in the current code

Re: [PATCH] rs6000: Fix C++14 vs. C++17 ABI bug on powerpc64le [PR94707]

On 4/22/20 11:49 AM, Jakub Jelinek wrote: On Wed, Apr 22, 2020 at 11:24:09AM -0500, Bill Schmidt wrote: Hm, but this patch violates the ELFv2 ABI as written. The ABI includes: "Floating-point and vector aggregates that contain padding words and integer fields with a width of 0 should not be

Re: [PATCH] rs6000: Fix C++14 vs. C++17 ABI bug on powerpc64le [PR94707]

On Wed, Apr 22, 2020 at 11:24:09AM -0500, Bill Schmidt wrote: > Hm, but this patch violates the ELFv2 ABI as written. The ABI includes: > > "Floating-point and vector aggregates that contain padding words and > integer fields with a width of 0 should not be treated as homogeneous > aggregates."

[rtl] Harden 'set_noop_p' for non-constant selectors [PR94279] (was: [Patch, RTL] Eliminate redundant vec_select moves)

Hi! First: please be gentle: I don't speak RTL. ;-) And second: it's been some time. On 2013-12-04T16:06:48+, Tejas Belagod wrote: > gcc/ > * rtlanal.c (set_noop_p): Return nonzero in case of redundant vec_select > for overlapping register lanes. This got committed to trunk in

Re: [PATCH] rs6000: Fix C++14 vs. C++17 ABI bug on powerpc64le [PR94707]

On 4/22/20 8:11 AM, Jakub Jelinek via Gcc-patches wrote: Hi! As mentioned in the PR and on IRC, the recently added struct-layout-1.exp new tests FAIL on powerpc64le-linux (among other targets). FAIL: tmpdir-g++.dg-struct-layout-1/t032 cp_compat_x_tst.o-cp_compat_y_tst.o execute FAIL:

Re: [Patch v2, fortran] PR fortran/90350 - ubound ICE on assumed size array even though explicit bound is specified

Hi Jose, On 21/04/20 16:38, Thomas Koenig wrote: Do you have commit privileges? It not, I can commit it for you. No i do not. I would be grateful if you could. Done, as https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=808a6eadda1a353ce3a70556feac128580491b24 . Thanks a lot for the

Re: [Patch v2, fortran] PR fortran/90350 - ubound ICE on assumed size array even though explicit bound is specified

Hi Thomas, On 21/04/20 16:38, Thomas Koenig wrote: Do you have commit privileges? It not, I can commit it for you. No i do not. I would be grateful if you could. Best regards, José Rui

Re: [PATCH][RFC] extend DECL_GIMPLE_REG_P to all types

Richard Biener writes: > On Wed, 22 Apr 2020, Richard Biener wrote: > >> >> This extends DECL_GIMPLE_REG_P to all types so we can clear >> TREE_ADDRESSABLE even for integers with partial defs, not just >> complex and vector variables. To make that transition easier >> the patch inverts

Re: [PATCH] correct strncpy range computation in restrict pass (PR 94647)

On Wed, 2020-04-22 at 09:36 -0600, Martin Sebor via Gcc-patches wrote: > On 4/22/20 7:28 AM, Christophe Lyon wrote: > > On Tue, 21 Apr 2020 at 11:07, Richard Biener via Gcc-patches > > wrote: > > > On Mon, Apr 20, 2020 at 11:29 PM Martin Sebor via Gcc-patches > > > wrote: > > > > The restrict

Re: [PATCH] correct strncpy range computation in restrict pass (PR 94647)

On 4/22/20 7:28 AM, Christophe Lyon wrote: On Tue, 21 Apr 2020 at 11:07, Richard Biener via Gcc-patches wrote: On Mon, Apr 20, 2020 at 11:29 PM Martin Sebor via Gcc-patches wrote: The restrict pass computes the wrong lower bound of the size of accesses to member arrays passed to strncpy as

[PATCH] Update documentation on optimizations turned on by O3

Hello, I noted that the optimizations turned on by O3 was outdated in the documentation. Here is the discussion that brought it to my attention: https://gcc.gnu.org/pipermail/gcc/2020-April/232164.html diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi index e2bc2559218..a28001a5adf

RE: [PATCH 0/19][GCC-8] aarch64: Backport outline atomics

> -Original Message- > From: Kyrylo Tkachov > Sent: 22 April 2020 11:00 > To: Andre Vieira (lists) ; gcc- > patc...@gcc.gnu.org > Cc: Richard Sandiford ; s...@amazon.com > Subject: RE: [PATCH 0/19][GCC-8] aarch64: Backport outline atomics > > Hi Andre, > > > -Original Message-

Re: [PATCH v2] S/390: Fix several test cases

On Wed, Apr 22, 2020 at 02:14:11PM +0200, Andreas Krebbel wrote: > On 22.04.20 13:56, Stefan Schulze Frielinghaus wrote: > > Hi, > > > > Added option `--save-temps` back to `addsub-signed-overflow-{1,2}.c`. > > Ok for master? > > > > Cheers, > > Stefan > > > > gcc/ChangeLog: > > > > 2020-04-21

[PATCH] libgfortran: Provide some further math library fallbacks [PR94694]

Hi! The following patch provides some further math library fallbacks. fmaf can be implemented using fma if available, fma and fmal can use x * y + z as fallback, it is not perfect, but e.g. glibc on various arches has been using that as fallback for many years, and copysign/copysignl/fabs/fabsl

Re: [PATCH] calls: Introduce cxx17_empty_base_field_p [PR94383]

On Wed, 2020-04-22 at 11:50 +0200, Jakub Jelinek via Gcc-patches wrote: > Hi! > > On Tue, Apr 21, 2020 at 03:58:52PM +0100, Richard Sandiford wrote: > > > if (TREE_CODE (field) != FIELD_DECL) > > > continue; > > > > > > - sub_count = aapcs_vfp_sub_candidate (TREE_TYPE (field),

Re: introduce target tmpnam and require it in tests relying on it

On 4/22/20 2:03 AM, Bernhard Reutner-Fischer wrote: On Tue, 21 Apr 2020 at 16:59, Martin Sebor wrote: https://gcc.gnu.org/pipermail/gcc-patches/2020-April/543672.html I'm okay with the changes to the tests. The target-supports.exp changes look reasonable to me as well but I can't approve

Re: [PATCH] ia64: Fix C++14 vs. C++17 ABI issue on ia64 [PR94706]

On Wed, 2020-04-22 at 15:36 +0200, Jakub Jelinek wrote: > Hi! > > ia64 seems to be affected too, but the backend doesn't have any > -Wpsabi warnings and I'm not sure if we really need them for an (almost?) > dead target. > > Untested by me, but Andreas confirmed it fixed all struct-layout-1.exp

Re: PING [PATCH][gcc][PR94230]provide an option to change the size limitation for -Wmisleading-indent

Hi, Richard And Dave: Thanks a lot for the review and comments. > On Apr 21, 2020, at 1:46 PM, Richard Sandiford > wrote: > > David Malcolm writes: >> On Tue, 2020-04-21 at 15:04 +0100, Richard Sandiford wrote >>> >>> Please add: >>> >>> PR c/94230 Will do. >>> *

[committed][gcc-9] aarch64: Fix bootstrap with old binutils [PR93053]

Went ahead and committed the backport to gcc-9. As reported in the PR, GCC 10 (and also 9.3.1 but not 9.3.0) fails to build when using older binutils which lack LSE support, because those instructions are used in libgcc. Thanks to Kyrylo's hint, the following patches (hopefully) allow it to

Re: [PATCH] c++: Fix misuse of "override" in -Weffc++ warnings (PR 94698)

On 4/22/20 2:37 AM, Jonathan Wakely via Gcc-patches wrote: These warnings have nothing to do with virtual functions, so "override" is inappropriate. The warnings are just talking about defining special members, so let's say that. PR translation/94698 * class.c

Re: [PATCH][RFC] extend DECL_GIMPLE_REG_P to all types

On Wed, 22 Apr 2020, Richard Biener wrote: > > This extends DECL_GIMPLE_REG_P to all types so we can clear > TREE_ADDRESSABLE even for integers with partial defs, not just > complex and vector variables. To make that transition easier > the patch inverts DECL_GIMPLE_REG_P to

Re: [PATCH] aarch64：Add an error message in large code model for ilp32 [PR94577]

On Wed, 22 Apr 2020 at 15:16, duanbo (C) wrote: > > Hi > > Thank you for your suggestions. > I have adjust the testcases and used this command to test . > "runtest --tool gcc --tool_opts -mabi=ilp32 aarch64.exp= > reload-valid-spoff.c" > > The results of those tests changed from unexpected

[PATCH] ia64: Fix C++14 vs. C++17 ABI issue on ia64 [PR94706]

Hi! ia64 seems to be affected too, but the backend doesn't have any -Wpsabi warnings and I'm not sure if we really need them for an (almost?) dead target. Untested by me, but Andreas confirmed it fixed all struct-layout-1.exp regressions. Ok for trunk? 2020-04-22 Jakub Jelinek PR

Re: [PATCH] coroutines: Handle lambda capture objects in the way as clang.

On 4/22/20 8:48 AM, Iain Sandoe wrote: Hi, There is no PR for this, at present, but the implementation of clang and GCC's handling of lambda capture object implicit parms is currently different. There is still some discussion about 'correct' interpretation of the standard - but in the

RE: [PATCH 5/5] testsuite: [arm/mve] Include arm_mve.h in arm_v8_1m_mve_ok

> -Original Message- > From: Gcc-patches On Behalf Of Andre > Vieira (lists) > Sent: 14 April 2020 09:40 > To: Christophe Lyon > Cc: gcc-patches@gcc.gnu.org > Subject: Re: [PATCH 5/5] testsuite: [arm/mve] Include arm_mve.h in > arm_v8_1m_mve_ok > > > On 10/04/2020 14:55, Christophe

RE: [PATCH 3/5] testsuite: [arm/mve] Fix mve_move_gpr_to_gpr.c

> -Original Message- > From: Gcc-patches On Behalf Of Andre > Vieira (lists) > Sent: 14 April 2020 09:39 > To: christophe Lyon > Cc: gcc-patches@gcc.gnu.org > Subject: Re: [PATCH 3/5] testsuite: [arm/mve] Fix mve_move_gpr_to_gpr.c > > On 10/04/2020 14:55, Christophe Lyon via

RE: [PATCH 4/5] testsuite: [arm/mve] Use dg-add-options arm_v8_1m_mve in MVE tests

> -Original Message- > From: Gcc-patches On Behalf Of Andre > Vieira (lists) > Sent: 14 April 2020 09:38 > To: Christophe Lyon > Cc: gcc-patches@gcc.gnu.org > Subject: Re: [PATCH 4/5] testsuite: [arm/mve] Use dg-add-options > arm_v8_1m_mve in MVE tests > > On 10/04/2020 14:55,

Re: [PATCH] correct strncpy range computation in restrict pass (PR 94647)

On Tue, 21 Apr 2020 at 11:07, Richard Biener via Gcc-patches wrote: > > On Mon, Apr 20, 2020 at 11:29 PM Martin Sebor via Gcc-patches > wrote: > > > > The restrict pass computes the wrong lower bound of the size > > of accesses to member arrays passed to strncpy as the source: > > it uses the

Re: [PATCH] aarch64, libgcc: Fix unwinding from pac-ret to normal frames [PR94514]

Hi, On Tue, 21 Apr 2020 at 18:52, Szabolcs Nagy wrote: > > The 04/17/2020 11:05, Kyrylo Tkachov wrote: > > Hi Szabolcs, > > > > > -Original Message- > > > From: Szabolcs Nagy > > > Sent: 09 April 2020 15:20 > > > To: gcc-patches@gcc.gnu.org > > > Cc: Richard Earnshaw ; Richard

RE: [PATCH] aarch64：Add an error message in large code model for ilp32 [PR94577]

Hi Thank you for your suggestions. I have adjust the testcases and used this command to test . "runtest --tool gcc --tool_opts -mabi=ilp32 aarch64.exp= reload-valid-spoff.c" The results of those tests changed from unexpected failures to unsupported. Attached please find the v5 patch. Any

[PATCH] rs6000: Fix C++14 vs. C++17 ABI bug on powerpc64le [PR94707]

Hi! As mentioned in the PR and on IRC, the recently added struct-layout-1.exp new tests FAIL on powerpc64le-linux (among other targets). FAIL: tmpdir-g++.dg-struct-layout-1/t032 cp_compat_x_tst.o-cp_compat_y_tst.o execute FAIL: tmpdir-g++.dg-struct-layout-1/t058

RE: [PATCH PR94678] aarch64: unexpected result with -mgeneral-regs-only and sve

Hi, > -Original Message- > From: Richard Sandiford [mailto:richard.sandif...@arm.com] > Sent: Wednesday, April 22, 2020 6:03 PM > To: Yangfei (Felix) > Cc: gcc-patches@gcc.gnu.org > Subject: Re: [PATCH PR94678] aarch64: unexpected result with -mgeneral- > regs-only and sve > > Mostly

[GCC][PATCH][ARM]: Modify the MVE polymorphic variant arguments to match the MVE intrinsic definition.

Hello, When MVE intrinsic's are called, few implicit typecasting are done on the formal arguments to match the intrinsic parameters. But when same intrinsics are called through MVE polymorphic variants, _Generic feature used here does strict type checking and fails to match the exact

Re: [PATCH][v3], rs6000: Use plq/pstq for atomic_{load, store} (PR94622)

Hi! On Tue, Apr 21, 2020 at 04:53:53PM -0500, Aaron Sawdey via Gcc-patches wrote: > For future architecture with prefix instructions, always use plq/pstq > rather than lq/stq for atomic load of quadword. Then we never have to > do the doubleword swap on little endian. Before this fix, -mno-pcrel

Re: [PATCH] calls: Introduce cxx17_empty_base_field_p [PR94383]

On Wed, Apr 22, 2020 at 01:33:45PM +0100, Richard Sandiford wrote: > Jakub Jelinek writes: > > On Wed, Apr 22, 2020 at 12:17:02PM +0100, Richard Sandiford wrote: > >> But my point was that, if the DECL_NAME does actually act to exclude > > > > I'm fine with dropping DECL_NAME test there, on the

[PATCH] coroutines: Handle lambda capture objects in the way as clang.

Hi, There is no PR for this, at present, but the implementation of clang and GCC's handling of lambda capture object implicit parms is currently different. There is still some discussion about 'correct' interpretation of the standard - but in the short-term it is probably best to have consistent

Re: [PATCH] calls: Introduce cxx17_empty_base_field_p [PR94383]

Jakub Jelinek writes: > On Wed, Apr 22, 2020 at 12:17:02PM +0100, Richard Sandiford wrote: >> But my point was that, if the DECL_NAME does actually act to exclude > > I'm fine with dropping DECL_NAME test there, on the other side would like to > add > && TYPE_SIZE (TREE_TYPE (field)) > &&

Re: [PATCH] tree-inline: Simplify IPA-CP type conversion (PR 93385)

On Wed, 22 Apr 2020, Martin Jambor wrote: > Hi, > > when callers and callees do not quite agree on the type of a > parameter, usually with ill-defined K or with smilarly wrong LTO > input, IPA-CP can attempt to try and substitute a wrong type for a > parameter (see e.g.

[PATCH][arm] Add initial support for Arm Cortex-M55

Hi all, This patch adds initial -mcpu support for the Arm Cortex-M55 CPU. This CPU is an Armv8.1-M Mainline CPU supporting MVE. An option to disable floating-point (and MVE) is provided with the +nofp. For GCC 11 I'd like to add further fine-grained options to enable integer-only MVE but that

Re: [PATCH v2] S/390: Fix several test cases

On 22.04.20 13:56, Stefan Schulze Frielinghaus wrote: > Hi, > > Added option `--save-temps` back to `addsub-signed-overflow-{1,2}.c`. > Ok for master? > > Cheers, > Stefan > > gcc/ChangeLog: > > 2020-04-21 Stefan Schulze Frielinghaus > > * config/s390/s390.md ("*_ior_and_sr_ze"):

Re: [Patch, committed][Fortran] Truncate warn with OpenMP/OpenACC/!GCC$ (PR94709)

On Wed, Apr 22, 2020 at 01:53:00PM +0200, Tobias Burnus wrote: > PR fortran/94709 > * scanner.c (load_line): In fixed form, also tread 'C' as comment and s/tread/treat/ > 'D'/'d' only with -fd-lines-as-comments. Treat '!$' with -fopenmp, > '!$acc' with -fopenacc and

[PATCH] tree-inline: Simplify IPA-CP type conversion (PR 93385)

Hi, when callers and callees do not quite agree on the type of a parameter, usually with ill-defined K or with smilarly wrong LTO input, IPA-CP can attempt to try and substitute a wrong type for a parameter (see e.g. gcc.dg/torture/pr48063.c). Function tree_function_versioning attempts to handle

[PATCH v2] S/390: Fix several test cases

Hi, Added option `--save-temps` back to `addsub-signed-overflow-{1,2}.c`. Ok for master? Cheers, Stefan gcc/ChangeLog: 2020-04-21 Stefan Schulze Frielinghaus * config/s390/s390.md ("*_ior_and_sr_ze"): lift from SI mode to DSI ("*trunc_sidi_and_subreg_ze"): new

[Patch, committed][Fortran] Truncate warn with OpenMP/OpenACC/!GCC$ (PR94709)

Hi all, when looking into 94690, I was wondering why it didn't accept 'collapse(2)'. Well, it turned out that the line was too long and the string got clipped. There is a nice check whether a comment is a real comment or an OpenACC/OpenMP directive or an !GCC$ attribute – but this check in

Re: [PATCH] calls: Introduce cxx17_empty_base_field_p [PR94383]

On Wed, Apr 22, 2020 at 12:17:02PM +0100, Richard Sandiford wrote: > But my point was that, if the DECL_NAME does actually act to exclude I'm fine with dropping DECL_NAME test there, on the other side would like to add && TYPE_SIZE (TREE_TYPE (field)) && !integer_zerop (TYPE_SIZE (TREE_TYPE

Re: [PATCH] calls: Introduce cxx17_empty_base_field_p [PR94383]

Richard Biener writes: > On Wed, 22 Apr 2020, Richard Sandiford wrote: > >> Jakub Jelinek writes: >> > On Wed, Apr 22, 2020 at 11:45:19AM +0100, Richard Sandiford wrote: >> >> Given what was said on irc about DECL_NAME not necessarily being >> >> significant for DECL_ARTIFICIAL decls, would it

Re: [PATCH] calls: Introduce cxx17_empty_base_field_p [PR94383]

On Wed, 22 Apr 2020, Richard Sandiford wrote: > Jakub Jelinek writes: > > On Wed, Apr 22, 2020 at 11:45:19AM +0100, Richard Sandiford wrote: > >> Given what was said on irc about DECL_NAME not necessarily being > >> significant for DECL_ARTIFICIAL decls, would it be better to drop > >> this part

Re: [PATCH] calls: Introduce cxx17_empty_base_field_p [PR94383]

Jakub Jelinek writes: > On Wed, Apr 22, 2020 at 11:45:19AM +0100, Richard Sandiford wrote: >> Given what was said on irc about DECL_NAME not necessarily being >> significant for DECL_ARTIFICIAL decls, would it be better to drop >> this part of the check? > > My preference was have it as narrow as

Re: [PATCH] calls: Introduce cxx17_empty_base_field_p [PR94383]

On Wed, Apr 22, 2020 at 12:58:52PM +0200, Richard Biener wrote: > On Wed, 22 Apr 2020, Jakub Jelinek wrote: > > > On Wed, Apr 22, 2020 at 11:45:19AM +0100, Richard Sandiford wrote: > > > Given what was said on irc about DECL_NAME not necessarily being > > > significant for DECL_ARTIFICIAL decls,

  1   2   >