[committed] testsuite: Fix up pr94482.c testcase [PR94482]

On Wed, Apr 08, 2020 at 08:34:08PM +0200, Martin Jambor wrote: > 2020-04-08 Martin Jambor > Richard Biener > > PR tree-optimization/94482 > * tree-sra.c (create_access_replacement): Dump new replacement with > TDF_UID. > (sra_modify_expr): Fix handling of cas

Re: [PATCH] cselib, var-tracking: Improve debug info after the cselib sp tracking changes [PR94495]

On Fri, Apr 10, 2020 at 11:54:49AM +0200, Jakub Jelinek via Gcc-patches wrote: > On Thu, Apr 09, 2020 at 10:57:46PM +0200, Christophe Lyon via Gcc-patches > wrote: > > This patch makes GCC fail to build newlib when configured for > > aarch64_be-none-elf: > > 0x10c488c vt_expand_var_loc_chain > >

Re: [PATCH] c++: Stray RESULT_DECLs in result of constexpr function call [PR94034]

On 4/10/20 5:47 PM, Patrick Palka wrote: On Fri, 10 Apr 2020, Jason Merrill wrote: On 4/10/20 2:15 PM, Patrick Palka wrote: On Fri, 10 Apr 2020, Patrick Palka wrote: On Fri, 10 Apr 2020, Jason Merrill wrote: On 4/10/20 1:04 PM, Patrick Palka wrote: On Thu, 9 Apr 2020, Patrick Palka wrote:

Re: [PATCH] On PPC32 GCC9 or later can throw an ICE when built with older GCCs

On Mon, 6 Apr 2020, Gustavo Romero via Gcc-patches wrote: > When GCC9 is built with older GCC (4.7) on FreeBSD 32-bit on PowerPC an ICE > is generated on stage 1 when selftests are performed. > > After an investigation the root cause was traced to an unnecessary and > harmful instantiation of a new

[committed] coroutines: Revise await expansions [PR94528]

The expansions for await expressions were specific to particular cases, this revises it to be more generic and thus handles the case that triggered the PR. Most of the change is code-factoring. Tested on x86_64-linux/darwin (and powerpc64-linux-gnu) approved by Nathan on the PR thread (I fixed

[PATCH][PR target/94542]Don't allow PC-relative addressing for TLS data

One of the things that address_to_insn_form() is used for is determining whether a PC-relative addressing instruction could be used. In particular predicate pcrel_external_address and function prefixed_paddi_p() both use it for this purpose. So what emerged in PR/94542 is that it should be look

Re: [PATCH] c++: Stray RESULT_DECLs in result of constexpr function call [PR94034]

On Fri, 10 Apr 2020, Jason Merrill wrote: > On 4/10/20 2:15 PM, Patrick Palka wrote: > > On Fri, 10 Apr 2020, Patrick Palka wrote: > > > > > On Fri, 10 Apr 2020, Jason Merrill wrote: > > > > > > > On 4/10/20 1:04 PM, Patrick Palka wrote: > > > > > On Thu, 9 Apr 2020, Patrick Palka wrote: > > > >

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

[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 gets stuck while attempting to handle constraints from an instruction that has previ

Re: [PATCH] c++: Stray RESULT_DECLs in result of constexpr function call [PR94034]

On 4/10/20 2:15 PM, Patrick Palka wrote: On Fri, 10 Apr 2020, Patrick Palka wrote: On Fri, 10 Apr 2020, Jason Merrill wrote: On 4/10/20 1:04 PM, Patrick Palka wrote: On Thu, 9 Apr 2020, Patrick Palka wrote: On Thu, 9 Apr 2020, Jason Merrill wrote: On 4/8/20 7:49 PM, Patrick Palka wrote:

Re: [committed] PR target/94530 (was [PATCH] PR target/48240)

Hi, On Thu, 9 Apr 2020 at 10:57, Andrea Corallo wrote: > > Hi all, > > Second version of the patch for PR94530 (pr num fixed) addressing > comments. > > Bootstrapped on aarch64-unknown-linux-gnu. > > Committed. > The new test causes an ICE: FAIL: gcc.target/aarch64/pr94530.c (internal compiler

Re: Merge from master to gccgo branch

On Tue, Apr 7, 2020 at 12:30 PM Ian Lance Taylor wrote: > > On Mon, Apr 6, 2020 at 5:51 PM Ian Lance Taylor wrote: > > > > I merged master revision 52fa80f853c0b0f623ea9e4c7198e324ce44ff30 to > > the gccgo branch. > > Another merge from master to gccgo branch, of revision > 50c7853216e8511971c55b

Re: [PATCH] c++: Stray RESULT_DECLs in result of constexpr function call [PR94034]

On Fri, 10 Apr 2020, Patrick Palka wrote: > On Fri, 10 Apr 2020, Jason Merrill wrote: > > > On 4/10/20 1:04 PM, Patrick Palka wrote: > > > On Thu, 9 Apr 2020, Patrick Palka wrote: > > > > On Thu, 9 Apr 2020, Jason Merrill wrote: > > > > > > > > > On 4/8/20 7:49 PM, Patrick Palka wrote: > > > > >

Re: [PATCH] c++: Stray RESULT_DECLs in result of constexpr function call [PR94034]

On Fri, 10 Apr 2020, Jason Merrill wrote: > On 4/10/20 1:04 PM, Patrick Palka wrote: > > On Thu, 9 Apr 2020, Patrick Palka wrote: > > > On Thu, 9 Apr 2020, Jason Merrill wrote: > > > > > > > On 4/8/20 7:49 PM, Patrick Palka wrote: > > > > > When evaluating the initializer of 'a' in the following

[PR C++ 94426] Lambda linkage

My fix for 94147 was confusing no-linkage with internal linkage, at the language level. That's wrong. (the std is confusing here, because it describes linkage of names (which is wrong), and lambdas have no names) Lambdas with extra-scope, have linkage. However, at the implementation-level th

Re: [PATCH v2 2/2] RISC-V: Handle implied extension for -march parser.

On Fri, Apr 10, 2020 at 2:20 AM Kito Cheng wrote: > - Implied rule are introduced into latest RISC-V ISA spec. > - Only implemented D implied F-extension. Zicsr and Zifence are not > implement yet, so the rule not included in this patch. > - Pass preprocessed arch string to arch. > - V

Re: [PATCH] c++: make __is_constructible work with paren-init of aggrs [PR94149]

On 4/9/20 5:00 PM, Marek Polacek wrote: In C++20 this is well-formed: using T = int[2]; T t(1, 2); which means that std::is_constructible_v should be true. But constructible_expr immediately returned the error_mark_node when it saw a list with more than one element. To give accurate resu

Re: [PATCH v2 1/2] RISC-V: Update march parser

On Fri, Apr 10, 2020 at 2:20 AM Kito Cheng wrote: > - The arch string rule has changed in latest spec, it introduced new >multi-letter extension prefix with 'h' and 'z', and drop `sx`. also >adjust parsing order for 's' and 'x'. This is OK. Jim

Re: [PATCH] c++: Stray RESULT_DECLs in result of constexpr function call [PR94034]

On 4/10/20 1:04 PM, Patrick Palka wrote: On Thu, 9 Apr 2020, Patrick Palka wrote: On Thu, 9 Apr 2020, Jason Merrill wrote: On 4/8/20 7:49 PM, Patrick Palka wrote: When evaluating the initializer of 'a' in the following example struct A { A *p = this; }; constexpr A foo() { return {};

Re: [PATCH] c++: Stray RESULT_DECLs in result of constexpr function call [PR94034]

On Thu, 9 Apr 2020, Patrick Palka wrote: > On Thu, 9 Apr 2020, Jason Merrill wrote: > > > On 4/8/20 7:49 PM, Patrick Palka wrote: > > > When evaluating the initializer of 'a' in the following example > > > > > >struct A { A *p = this; }; > > >constexpr A foo() { return {}; } > > >cons

Re: ICE on wrong colde [PR94192]

On Fri, Apr 10, 2020 at 8:27 AM Linus König wrote: > > Hi, > > I fixed the style issues. However, omitting the checks for NULL produced > several regressions in my previous tests. > The style looks good. Please share testcases which exhibit the regressions. They will also need to be included in g

Re: [PATCH, Fortran] -- PR fortran/87923 -- fix ICE when resolving I/O tags and simplify io.c

On Fri, Apr 10, 2020 at 8:14 AM Rainer Orth wrote: > > Hi Fritz, [...] > one new testcases comes up as UNRESOLVED everywhere: > > +UNRESOLVED: gfortran.dg/asynchronous_5.f03 -O scan-tree-dump-not > original "volatile.*?ivar_noasync" > +UNRESOLVED: gfortran.dg/asynchronous_5.f03 -O scan-t

Re: [PATCH] reject scalar array initialization with nullptr [PR94510]

On 4/9/20 4:23 PM, Martin Sebor wrote: On 4/9/20 1:32 PM, Jason Merrill wrote: On 4/9/20 3:24 PM, Martin Sebor wrote: On 4/9/20 1:03 PM, Jason Merrill wrote: On 4/8/20 1:23 PM, Martin Sebor wrote: On 4/7/20 3:36 PM, Marek Polacek wrote: On Tue, Apr 07, 2020 at 02:46:52PM -0600, Martin Sebor

Re: [Patch] libgomp – fix handling of 'target enter data'

On Fri, Apr 10, 2020 at 04:31:37PM +0200, Thomas Schwinge wrote: > Aha, thanks -- that resolves doubts I had (but Julian and I couldn't > allocate time to track down): see 'GOMP_target_enter_exit_data' mentioned > in > ff., for

Test cases for mixed structured/dynamic data lifetimes with OpenACC [PR92843] (was: [PATCH 0/3] Mixed static/dynamic data lifetimes with OpenACC (PR92843))

Hi! On 2020-01-17T12:18:18-0800, Julian Brown wrote: > This patch series provides fixes for some cases of mixing static and (It's "structured", not "static".) ;-) > dynamic data lifetimes in OpenACC, hopefully addressing some of Thomas's > concerns in PR92843 -- in particular that an "exit dat

Re: [Patch] libgomp – fix handling of 'target enter data'

Hi! On 2020-03-31T19:41:40+0200, Tobias Burnus wrote: > libgomp – fix handling of 'target enter data' > > * target.c (GOMP_target_enter_exit_data): Handle PSET/MAP_POINTER. > * testsuite/libgomp.fortran/target-enter-data-1.f90: New. > > libgomp/target.c

Re: [PATCH] Handle 'omp declare target' attribute set for both OpenACC and OpenMP 'target' [PR89433, PR93465]

Hi! On 2020-03-04T20:07:46+0100, Jakub Jelinek wrote: > On Wed, Mar 04, 2020 at 08:27:10PM +0100, Thomas Schwinge wrote: >> ... which as of PR89433 commit b48f44bf77a39fefc238a16cf1225c6464c82406 >> causes >> an ICE. Not sure if this is actually supposed to be valid or invalid code. >> Until th

[PATCH 2/5] testsuite: [arm/mve] Use arm_softfp and arm_hard as needed in MVE tests

Some MVE tests explicitly test a -mfloat-abi=hard option, but we need to check that the toolchain actually supports it (which may not be the case for arm-linux-gnueabi* targets). We also make use of dg-add-options arm_v8_1m_mve_fp and arm_v8_1m_mve instead of duplicating the corresponding options

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

Several ARM/MVE tests can be compiled even if the toolchain does not support -mfloat-abi=hard (softfp is OK). Use dg-add-options arm_v8_1m_mve or arm_v8_1m_mve_fp instead of using dg-additional-options. 2020-04-10 Christophe Lyon gcc/testsuite/ * gcc.target/arm/mve/intrinsics/

[PATCH 1/5] testsuite: [arm] Add arm_softfp_ok and arm_hard_ok effective targets.

For arm-linux-gnueabi* targets, a toolchain cannot support the float-abi opposite to the one it has been configured for: since glibc does not support such multilibs, we end up lacking gnu/stubs-*.h when including stdint.h for instance. This patch introduces two new effective targets to detect whet

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

Since arm_mve.h includes stdint.h, its use requires the presence of the right gnu/stub-*.h, so make sure to include it when checking the arm_v8_1m_mve_ok_nocache effective target, otherwise we can decide MVE is supported while it's not really. This makes several tests unsupported rather than fail.

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

This test can pass with a hard-float toolchain, provided we don't force -mfloat-abi=softfp. This patch removes this useless option, as well as -save-temps which is implied by arm_v8_1m_mve_fp. 2020-04-10 Christophe Lyon gcc/tesuite/ * gcc.target/arm/mve/intrinsics/mve_move_gpr

Re: [C/C++, OpenACC] Reject vars of different scope in acc declare (PR94120)

Hi Tobias! I do see the new 'libgomp.oacc-c++/declare-pr94120.C' (see below, for reference) FAIL for '-foffload=nvptx-none' execution testing. The reason is that the 'C' array doesn't have the content it's checked to have. Now, my question, shouldn't it be changed like the attached patch, or sim

Re: [C/C++, OpenACC] Reject vars of different scope in acc declare (PR94120)

Hi Tobias! On 2020-04-08T09:55:24+0200, Tobias Burnus wrote: > I have now committed this patch > as r10-7614-g13e41d8b9d3d7598c72c38acc86a3d97046c8373, > reading "so we shall accept it" as approval … That's OK. As I said: "I'm not at all familiar with the front ends' scoping implementation", an

ICE on wrong colde [PR94192]

Hi, I fixed the style issues. However, omitting the checks for NULL produced several regressions in my previous tests. Best regards, Linus König diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c index 23b5a2b4439..ca149c0dd00 100644 --- a/gcc/fortran/resolve.c +++ b/gcc/fortran/reso

Re: [PATCH] [ARC] Allow more ABIs in GLIBC_DYNAMIC_LINKER

Done. Thank you for your support, Claudiu On Thu, Apr 9, 2020 at 2:38 AM Vineet Gupta wrote: > > Hi Claudiu, > > For glibc needs can this be backported to gcc-9 please ! > > Thx, > -Vineet > > On 3/31/20 3:06 AM, Claudiu Zissulescu Ianculescu wrote: > > Pushed. > > > > Thank you, > > Claudiu > >

[PATCH] arc:commited: Allow more ABIs in GLIBC_DYNAMIC_LINKER

Backport to gcc9: Enable big-endian suffixed dynamic linker per glibc multi-abi support. And to avoid a future churn and version pairingi hassles, also allow arc700 although glibc for ARC currently doesn't support it. gcc/ -xx-xx Vineet Gupta * config/arc/linux.h: GLIBC_DYNAMIC_LIN

Re: [PATCH, Fortran] -- PR fortran/87923 -- fix ICE when resolving I/O tags and simplify io.c

Hi Fritz, > Thanks very much for the review. > > On Thu, Apr 9, 2020 at 5:21 AM Tobias Burnus wrote: >> >> Hi, >> >> On 4/6/20 7:25 PM, Fritz Reese via Fortran wrote: >> >> > The attached patch fixes PR 87923 while also simplifying the code in >> > io.c. >> >> Thanks for the work, which looks gre

[committed] libphobos: Use libdruntime as a convenience library for libphobos.

Hi, As a prerequesite for PR94304, it becomes easier to manage selectively compiling sublibraries when there's only one library to link to. So a druntime convenience library is built to be part of phobos, however separate druntime library is still built and installed, to allow linking only to the

Re: [PATCH] cselib, var-tracking: Improve debug info after the cselib sp tracking changes [PR94495]

On Thu, Apr 09, 2020 at 10:57:46PM +0200, Christophe Lyon via Gcc-patches wrote: > This patch makes GCC fail to build newlib when configured for > aarch64_be-none-elf: > 0x10c488c vt_expand_var_loc_chain > > /tmp/9192639_9.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/var-tracking.c:8355

[PATCH, vect] Check alignment for no peeling gaps handling

Hi, This is one fix following Richi's comments here: https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542232.html I noticed the current half vector support for no peeling gaps handled some cases which never check the half size vector support. By further investigation, those cases are safe to

[PATCH v2 2/2] RISC-V: Handle implied extension for -march parser.

- Implied rule are introduced into latest RISC-V ISA spec. - Only implemented D implied F-extension. Zicsr and Zifence are not implement yet, so the rule not included in this patch. - Pass preprocessed arch string to arch. - Verified with binutils 2.30 and 2.34. gcc/ChangeLog

[PATCH v2 1/2] RISC-V: Update march parser

- The arch string rule has changed in latest spec, it introduced new multi-letter extension prefix with 'h' and 'z', and drop `sx`. also adjust parsing order for 's' and 'x'. gcc/ChangeLog * riscv-common.c (parse_sv_or_non_std_ext): Rename to parse_multiletter_ext.

Re: [PATCH] Allow new/delete operator deletion only for replaceable.

On Fri, Apr 10, 2020 at 10:29:29AM +0200, Martin Liška wrote: > +/* Valid pairs of new and delete operators for DCE. */ > +static hash_set *valid_pairs = NULL; > + > +/* Return that NEW_CALL and DELETE_CALL are a valid pair of new > + and delete operators. */ > + > +static bool > +valid_new_de

Re: [PATCH] Allow new/delete operator deletion only for replaceable.

Marc Glisse wrote: On Fri, 10 Apr 2020, Martin Liška wrote: On 4/9/20 10:13 AM, Jonathan Wakely wrote: On Thu, 9 Apr 2020 at 09:05, Marc Glisse wrote: Note that the matching is not 1-to-1. Array vs non-array and aligned vs non-aligned seem important, but sized and unsized delete can both ma

Re: [PATCH] Allow new/delete operator deletion only for replaceable.

On Fri, 10 Apr 2020, Martin Liška wrote: On 4/9/20 10:13 AM, Jonathan Wakely wrote: On Thu, 9 Apr 2020 at 09:05, Marc Glisse wrote: Note that the matching is not 1-to-1. Array vs non-array and aligned vs non-aligned seem important, but sized and unsized delete can both match the same new, IIUC

Re: [PATCH] Allow new/delete operator deletion only for replaceable.

On 4/10/20 10:18 AM, Jonathan Wakely wrote: On Fri, 10 Apr 2020 at 09:08, Martin Liška wrote: Marc pointed out that some targets do not use the leading '_' (or use 2 dashes?) for mangled named? Double underscore at the start. I think darwin uses that. Ah yeah, not dashes, but underscores

Re: [PATCH] Allow new/delete operator deletion only for replaceable.

On Fri, 10 Apr 2020 at 09:08, Martin Liška wrote: > Marc pointed out that some targets do not use the leading '_' (or use 2 > dashes?) for mangled named? Double underscore at the start. I think darwin uses that.

Re: [PATCH] Allow new/delete operator deletion only for replaceable.

On 4/9/20 10:13 AM, Jonathan Wakely wrote: On Thu, 9 Apr 2020 at 09:05, Marc Glisse wrote: Note that the matching is not 1-to-1. Array vs non-array and aligned vs non-aligned seem important, but sized and unsized delete can both match the same new, IIUC. Right. Not sure about the nothrow ver

[committed] wwwdocs: Remove extraneous space around tags.

It's generally a good idea, but now that we have been moving more towards our web pages (HTML files) being more self contained including DOCTYPE and common headers as opposed to more pre-processing upon deployment, consistency in the sources has become more important to allow for easier automated c