C++ PATCH for c++/85256, ICE capturing pointer to VLA

Here if we return immediately after the diagnostic about unsupported variably-modified type capture, we avoid the crash. I'm also changing the diagnostic from error to sorry, since it would make sense to support this usage and apparently Clang already does. The second patch below is the

Set insn_last_address in final_1

final_1 already sets insn_current_address for each instruction, making it possible to use some of the address functions in final.c during assembly generation. This patch also sets insn_last_address, since as the comment says, we can treat final as a shorten_branches pass that does nothing. It's

RE: [PATCH] [ARC] Add/update combiner patterns.

Committed. Thank you for your review, Claudiu > -Original Message- > From: Andrew Burgess [mailto:andrew.burg...@embecosm.com] > Sent: Saturday, April 07, 2018 11:07 AM > To: Claudiu Zissulescu > Cc: gcc-patches@gcc.gnu.org; claudiu.zissule...@synopsys.com; >

Re: Improve code quality across partition boundaries

On April 9, 2018 4:17:45 PM GMT+02:00, Jan Hubicka wrote: >Hi, >this patch fixes most offending artifacts across the function partition >bounary with -freorder-blocks-and-partitions which is now on by default >for i386 (no other targets). The problem is that most of cfgcleanup

C++ PATCH for c++/85264, ICE with extra template parameter list

cp_parser_check_template_parameters is supposed to catch when we have the wrong number of template parameter lists, but it wasn't diagnosing this case. Fixed by checking whether the thing we're declaring used a template-id; the case of declaring a primary template, when we allow one more template

Re: Fix PRs 80463, 83972, 83480

On Mon, Apr 09, 2018 at 01:30:12PM +0300, Andrey Belevantsev wrote: > I think that should be fine, that is, as long as the insn moved up through > all those debug insns, the copy will do that as well. It's that > problematic conditional in sched-deps.c that we should take care of. > > I've

Re: [PATCH] Assorted -masm=intel fixes (PR target/85281)

On Mon, Apr 9, 2018 at 11:37 AM, Jakub Jelinek wrote: > Hi! > > I've tested make check-gcc > RUNTESTFLAGS='--target_board=unix\{-m32/-masm=intel,-m64/-masm=intel\} > i386.exp vect.exp' > testing and looked solely at assembly Error: (there are many scan-assembler* > directives

Re: C++ PATCH for c++/85032, rejects-valid with if constexpr in template

On Fri, Apr 6, 2018 at 2:17 PM, Marek Polacek wrote: > On Mon, Mar 26, 2018 at 01:17:22PM -0400, Jason Merrill wrote: >> On Sat, Mar 24, 2018 at 6:59 AM, Marek Polacek wrote: >> > Recently the code in finish_static_assert was changed to use >> >

Re: [C++ PATCH] Fix invalid structured binding range for parsing error recovery (PR c++/85194)

OK. On Wed, Apr 4, 2018 at 3:48 PM, Jakub Jelinek wrote: > Hi! > > The maybe_range_for_decl argument is documented on > cp_parser_simple_declaration as: >If MAYBE_RANGE_FOR_DECL is not NULL, the pointed tree will be set to the >parsed declaration if it is an

[PATCH] Fix some broadcasts in -masm=intel mode (PR target/85281)

Hi! As the following testcase shows, we emit an incorrect PTR prefix in a vpbroadcastb instruction in -masm=intel mode; gas accepts and the manual documents that the input operand is xmm2/m8 for vpbroadcastb and xmm2/m16 for vpbroadcastw, so we need to use BYTE PTR and WORD PTR instead of XMMWORD

Re: [PATCH] v2: Show pertinent parameter (PR c++/85110)

OK. On Fri, Apr 6, 2018 at 3:54 PM, David Malcolm wrote: > On Thu, 2018-03-29 at 09:20 -0400, Jason Merrill wrote: >> On Wed, Mar 28, 2018 at 4:44 PM, David Malcolm >> wrote: >> > This followup patch updates the specific error-handling path >> > to add

[patch, fortran] Remove parallell annotation from DO CONCURRENT

Hello world, the attached patch removes the parallel annotation from DO CONCURRENT. As discussed in the PR, the autoparallellizer currently generates wrong code. The only feasible way is to disable the annotation for gcc-8 and work on the wrong-code issues for gcc-9. This is an 8 regression.

Re: [patch, fortran] Remove parallell annotation from DO CONCURRENT

On Mon, Apr 09, 2018 at 10:10:13PM +0200, Thomas Koenig wrote: > Hello world, > > the attached patch removes the parallel annotation from DO CONCURRENT. > As discussed in the PR, the autoparallellizer currently generates > wrong code. The only feasible way is to disable the annotation for > gcc-8

C++ PATCH for c++/85277, ICE with invalid offsetof

Here, the code was improperly assuming that the member argument must be a decl at the point of the error, but since we stopped folding foo[0] to foo, in this case it's an INDIRECT_REF. And the existing error for INDIRECT_REF is inaccurate for this case, so let's stick to complaining about asking

Re: [patch, fortran] Remove parallell annotation from DO CONCURRENT

On Mon, Apr 09, 2018 at 10:10:13PM +0200, Thomas Koenig wrote: > > the attached patch removes the parallel annotation from DO CONCURRENT. > As discussed in the PR, the autoparallellizer currently generates > wrong code. The only feasible way is to disable the annotation for > gcc-8 and work on

[PATCH] Assorted -masm=intel fixes (PR target/85281)

Hi! I've tested make check-gcc RUNTESTFLAGS='--target_board=unix\{-m32/-masm=intel,-m64/-masm=intel\} i386.exp vect.exp' testing and looked solely at assembly Error: (there are many scan-assembler* directives that just fail, and some tests use e.g. only att inline asm etc.). The following patch

C++ PATCH for c++/85262, ICE with redundant qualification on constructor

A::A names the constructor, but you can't call the constructor directly, you should just write A(args). Our error recovery was failing in a template because we'd wrapped the arguments with NON_DEPENDENT_EXPR, and then kept the result as part of the template tree, whereas we're supposed to throw

Re: [patch, fortran] Remove parallell annotation from DO CONCURRENT

Hi Steve, On Mon, Apr 09, 2018 at 10:10:13PM +0200, Thomas Koenig wrote: the attached patch removes the parallel annotation from DO CONCURRENT. As discussed in the PR, the autoparallellizer currently generates wrong code. The only feasible way is to disable the annotation for gcc-8 and work

C++ PATCH for c++/85279, dump_expr vs. decltype

For some reason, cp_parser_name_lookup_error uses %E for printing the parsing scope, so dump_expr needs to know how to handle some _TYPEs. DECLTYPE_TYPE was missing. Tested x86_64-pc-linux-gnu, applying to trunk. commit 4d380464839058b3d70e1262339ed973642d6741 Author: Jason Merrill

Re: [patch, fortran] Remove parallell annotation from DO CONCURRENT

On Mon, Apr 09, 2018 at 10:58:13PM +0200, Thomas Koenig wrote: > > On Mon, Apr 09, 2018 at 10:10:13PM +0200, Thomas Koenig wrote: > >> > >> the attached patch removes the parallel annotation from DO CONCURRENT. > >> As discussed in the PR, the autoparallellizer currently generates > >> wrong code.

[PR 84149] From 3b967c133f7f62e3c2951a971d8690d242364f5d Mon Sep 17 00:00:00 2001

Hi, changes in predictors caused that LTO IPA-CP no longer clones the qsort implementation for both of the comparators used in 505.mcf_r from Spec 2017 to be quite and this resulted in quite some slowdown of the benchmark. I have tried various way of teaching IPA-CP that the remaining contexts

Re: [PATCH][explow] PR target/85173: validize memory before passing it on to target probe_stack

On 04/05/2018 08:20 AM, Kyrill Tkachov wrote: > Hi all, > > In this PR the expansion code emits an invalid memory address for the > stack probe, which the backend fails to recognise. > The address is created explicitly in > anti_adjust_stack_and_probe_stack_clash in explow.c and passed down to >

Re: [PATCH][RFC] Fix PR85180, find_base_term is exponential

On 04/05/2018 06:32 AM, Richard Biener wrote: > > This fixes exponential time spent in find_base_term by extending the > existing fix of NULL-ifying VALUE locations during their processing > to keep them NULL-ified during the whole recursion. > > As Jakub figured this has the chance of returning

Re: [PATCH][GCC][mid-end] Allow larger copies when target supports unaligned access [Patch (1/2)]

On 04/04/2018 06:43 AM, Peter Bergner wrote: > On 4/4/18 4:06 AM, Tamar Christina wrote: >> Now that I know how the loads are done, I have a patch should be both >> correct and generate better code in most cases. >> It just calculates bitsize inside the loop and does the copying in the >>

Re: C++ PATCH for c++/85264, ICE with extra template parameter list

Hi, On 09/04/2018 21:39, Jason Merrill wrote: cp_parser_check_template_parameters is supposed to catch when we have the wrong number of template parameter lists, but it wasn't diagnosing this case. Fixed by checking whether the thing we're declaring used a template-id; the case of declaring a

[PATCH] PR libstdc++/85222 allow catching iostream errors as gcc4-compatible ios::failure

Define a new exception type derived from std::ios::failure[abi:cxx11] which also aggregates an object of the gcc4-compatible ios::failure type. Make __throw_ios_failure throw this new type for iostream errors that raise exceptions. Provide custom type info for the new type so that it can be caught

Re: [doc patch] remove hyphen from side-effect

Ping: I will go ahead and commit this patch sometime this week unless I hear objections: https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00036.html Martin On 04/02/2018 03:55 PM, Martin Sebor wrote: Attached is a patch to remove the hyphen from uses of side-effect in the manual as per the

Re: [doc patch] remove hyphen from side-effect

On 04/09/2018 05:58 PM, Martin Sebor wrote: Ping:  I will go ahead and commit this patch sometime this week unless I hear objections:   https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00036.html This patch is mostly OK, except for these hunks: Index: gcc/doc/invoke.texi

[RFC] Improve tree DSE

I would like to queue this patch for stage1 review. In DSE, while in dse_classify_store, as soon as we see a PHI use statement that is part of the loop, we are immediately giving up. As far as I understand, this can be improved. Attached patch is trying to walk the uses of the PHI statement (by

Re: [PATCH/doc] - mention all optimization options that enable inlining options

On 04/09/2018 01:36 AM, Richard Biener wrote: On Sun, 8 Apr 2018, Martin Sebor wrote: While updating the -Wrestrict option to mention that it works best not just with -O2 but also at higher optimization levels I looked around for other options that might benefit from a similar clarification.

Re: Add missing cases to vect_get_smallest_scalar_type (PR 85286)

On Mon, Apr 09, 2018 at 06:47:45PM +0100, Richard Sandiford wrote: > In this PR we used WIDEN_SUM_EXPR to vectorise: > > short i, y; > int sum; > [...] > for (i = x; i > 0; i--) > sum += y; > > with 4 ints and 8 shorts per vector. The problem was that we set > the VF based only on

Add missing cases to vect_get_smallest_scalar_type (PR 85286)

In this PR we used WIDEN_SUM_EXPR to vectorise: short i, y; int sum; [...] for (i = x; i > 0; i--) sum += y; with 4 ints and 8 shorts per vector. The problem was that we set the VF based only on the ints, then calculated the number of vector copies based on the shorts, giving 4/8.

Re: [C++ Patch] PR 85227 ("[7/8/ Regression] ICE with structured binding of a forward declared variable")

OK. On Fri, Apr 6, 2018 at 3:05 PM, Paolo Carlini wrote: > Hi, > > On 06/04/2018 19:04, Jason Merrill wrote: >> >> On Fri, Apr 6, 2018 at 5:01 AM, Paolo Carlini >> wrote: >>> >>> here, for an incomplete type we ICE pretty soon in >>>

RE: [PATCH] [ARC] Fix stack usage info for naked functions.

Accepted & committed, thank you for your contribution, Claudiu > -Original Message- > From: Alexey Brodkin [mailto:abrod...@synopsys.com] > Sent: Friday, April 06, 2018 6:02 PM > To: gcc-patches@gcc.gnu.org > Cc: Claudiu Zissulescu ; Alexey Brodkin >

Re: [PATCH, GCC/ARM] Fix PR85261: ICE with FPSCR setter builtin

Hi Ramana, On 06/04/18 17:17, Thomas Preudhomme wrote: On 06/04/18 17:08, Ramana Radhakrishnan wrote: On 06/04/2018 16:54, Thomas Preudhomme wrote: Instruction pattern for setting the FPSCR expects the input value to be in a register. However, __builtin_arm_set_fpscr expander does not

Re: [PATCH] Assorted -masm=intel fixes (PR target/85281)

>>> "H.J. Lu" 04/09/18 9:09 PM >>> >On Mon, Apr 9, 2018 at 11:37 AM, Jakub Jelinek wrote: >> BTW, -masm=intel seems to be in quite bad shape even in the assembler, in >> various testcases I'm getting errors like on the following reduced one: >> int k1,

Re: Fix PR 83913

On 06.04.2018 19:10, Alexander Monakov wrote: > On Tue, 3 Apr 2018, Andrey Belevantsev wrote: > >> Hello, >> >> This issue ended up being fixed the way different from described in the PR. >> We do not want to walk away from the invariant "zero SCHED_TIMES -- insn >> is not scheduled" even for

Re: Fix PR 83530

On 06.04.2018 18:55, Alexander Monakov wrote: > On Tue, 3 Apr 2018, Andrey Belevantsev wrote: > >> Hello, >> >> This issue is when we cannot correctly make insn tick data for the >> unscheduled code (but processed by the modulo scheduler). Fixed by closely >> following usual scheduling process

Re: [wwwdocs] GCC-7.3 changes: Add note about LEON3FT erratum workaround

On Mon, 9 Apr 2018, Daniel Hellstrom wrote: > I received feedback from the webmaster that the preferred link is > "http://www.gaisler.com/notes; so I updated it just be pushing. Maybe, but then they should reconfigure their server such that it does not redirect. We've had to many cases in the

Re: Fix PR 83962

On 06.04.2018 18:59, Alexander Monakov wrote: > On Tue, 3 Apr 2018, Andrey Belevantsev wrote: > >> Hello, >> >> This issues is about the correct order in which we need to call the >> routines that fix up the control flow for us. > > OK with formatting both in the new comment and the Changelog

Re: Fix PRs 80463, 83972, 83480

On 06.04.2018 19:18, Alexander Monakov wrote: > On Tue, 3 Apr 2018, Andrey Belevantsev wrote: > >> Hello, >> >> In these PRs we deal with the dependencies we are forced to make between a >> debug insn and its previous insn (unless bb head). In the latter case, if >> such an insn has been moved,

Re: [PATCH/doc] - mention all optimization options that enable inlining options

On Sun, 8 Apr 2018, Martin Sebor wrote: > While updating the -Wrestrict option to mention that it works > best not just with -O2 but also at higher optimization levels > I looked around for other options that might benefit from > a similar clarification. I found a few inlining options that >

Re: [wwwdocs] GCC-7.3 changes: Add note about LEON3FT erratum workaround

On 2018-04-07 22:08, Gerald Pfeifer wrote: On Thu, 1 Feb 2018, Daniel Hellstrom wrote: I would like to commit the following comment about LEON3-FT errata now available in GCC-7.3. Thanks, I have now committed it. Apparently the ultimate URL is the one below (which I applied for now)? Gerald

Re: [Aarch64] Fix conditional branches with target far away.

Hi Richard, I do not see the said patch applied in ToT yet. When do you expect it to be available in ToT? - Thanks and regards, Sameera D. On 30 March 2018 at 17:01, Sameera Deshpande wrote: > Hi Richard, > > The testcase is working with the patch you suggested,

Re: [nvptx, PR81352] Add exit insn after noreturn call for neutered threads in warp (fwd)

Somehow ended up off-list only. -- Forwarded message -- Date: Mon, 9 Apr 2018 09:30:15 +0200 (CEST) From: Richard Biener To: Gerald Pfeifer Subject: Re: [nvptx, PR81352] Add exit insn after noreturn call for neutered threads in warp

Re: [PATCH] MIPS/GCC: Mark text contents as code or data

Hi Paul, Apologies for the delay in reply, my @imgtec.com address has since become defunct and I have only come across your e-mail in my ever-lagging routine mailing traffic review. On Wed, 14 Mar 2018, Paul Hua wrote: > I noticed that data-sym-pool.c fails on -O0 flags. > > -O0 output : >

Re: [PATCH] Handle empty infinite loops in OpenACC for PR84955

On Fri, 6 Apr 2018, Jakub Jelinek wrote: > On Fri, Apr 06, 2018 at 06:48:52AM -0700, Cesar Philippidis wrote: > > 2018-04-06 Cesar Philippidis > > > > PR middle-end/84955 > > > > gcc/ > > * cfgloop.c (flow_loops_find): Add assert. > > * omp-expand.c

Re: [PATCH] Be more carefull about DECL merging in LTO (PR lto/85248).

On Mon, Apr 9, 2018 at 3:55 PM, Martin Liška wrote: > Hi. > > Following patch adds checking of noreturn attribute when we merge DECLs in > LTO. > Note that proper fix is probably > https://gcc.gnu.org/bugzilla/attachment.cgi?id=43884=diff > but that would be applicable after MPX

Improve code quality across partition boundaries

Hi, this patch fixes most offending artifacts across the function partition bounary with -freorder-blocks-and-partitions which is now on by default for i386 (no other targets). The problem is that most of cfgcleanup and cfgrtl is disabled on crossing edges and thus we produce pretty ugly code.

Re: [PATCH] Prefer mempcpy to memcpy on x86_64 target (PR middle-end/81657).

Hi. I'm sending updated version of the patch. Patch can bootstrap on ppc64le-redhat-linux and x86_64-linux and survives regression tests. Martin >From 6d19b1bf0c28a683e1458e16943e34bb547d36d6 Mon Sep 17 00:00:00 2001 From: marxin Date: Wed, 14 Mar 2018 09:44:18 +0100 Subject:

[nvptx, PR84041] Add memory_barrier insn

Hi, we've been having hanging OpenMP tests for nvptx offloading: for-{3,5,6}.c and the corresponding C++ test-cases. The failures have now been analyzed down to gomp_ptrlock_get in libgomp/config/nvptx/ptrlock.h: ... static inline void *gomp_ptrlock_get (gomp_ptrlock_t *ptrlock) {

[PATCH] Fix PR85284

The following fixes the new capability of analyzing a wrapping IV as non-wrapping under a condition that ensures we do not wrap by restricting it to the case where the exit test must be executed when it reaches that bound. Otherwise we may not analyze the IV with the assumption that the exit

Re: [PATCH v2, rs6000] Tidy implementation of vec_ldl

Hi! On Wed, Apr 04, 2018 at 10:32:58AM -0500, Kelvin Nilsen wrote: > 2018-04-03  Kelvin Nilsen  > >     * config/rs6000/rs6000-c.c (altivec_overloaded_builtins): Remove >     erroneous entries for >     "vector int vec_ldl (int, long int *)", and >     "vector unsigned int

[PATCH] Be more carefull about DECL merging in LTO (PR lto/85248).

Hi. Following patch adds checking of noreturn attribute when we merge DECLs in LTO. Note that proper fix is probably https://gcc.gnu.org/bugzilla/attachment.cgi?id=43884=diff but that would be applicable after MPX is removed. Thus in next stage1. Patch can bootstrap on x86_64-linux-gnu and