Re: [PATCH], PR 71493, Fix PowerPC ABI breakage on GCC trunk/6.1

On Mon, Jul 18, 2016 at 06:42:02PM -0500, Segher Boessenkool wrote: > On Mon, Jul 18, 2016 at 07:25:09PM -0400, Michael Meissner wrote: > > When I added the support for __float128 last year, I accidentally broke > > returning structures containing a single float or double item using the > >

Re: RFA: new pass to warn on questionable uses of alloca() and VLAs

How does this look? I think it's 99% there. You've addressed all of my comments so far -- thanks for that and for being so patient. I realize it would be a lot more efficient to get all the feedback (or as much of it as possible) up front. Unfortunately, some things don't get noticed until

Re: [PATCH] Avoid invoking ranlib on libbackend.a

On Mon, Jul 18, 2016 at 08:39:34PM -0400, Patrick Palka wrote: > One thing that was not clear to me is whether the object file paths > stored in a thin archive are relative or absolute paths. If they are > absolute paths then that would be a problem due to how the build system > moves build

Re: [PATCH] Avoid invoking ranlib on libbackend.a

On Mon, 18 Jul 2016, Segher Boessenkool wrote: > On Mon, Jul 18, 2016 at 06:35:11AM -0500, Segher Boessenkool wrote: > > Or, if using GNU ar, you can even use -S, if that helps (after testing > > for it in configure, of course). > > I meant -T. Some day I will learn how to type, promise!

Re: [PATCH], PR 71493, Fix PowerPC ABI breakage on GCC trunk/6.1

On Mon, Jul 18, 2016 at 07:25:09PM -0400, Michael Meissner wrote: > When I added the support for __float128 last year, I accidentally broke > returning structures containing a single float or double item using the System > V 32-bit calling sequence. > > This patch goes back to using

[PATCH], PR 71493, Fix PowerPC ABI breakage on GCC trunk/6.1

When I added the support for __float128 last year, I accidentally broke returning structures containing a single float or double item using the System V 32-bit calling sequence. This patch goes back to using SCALAR_FLOAT_TYPE_P (which looks at the tree node) instead of

Re: [PATCH] c++/60760 - arithmetic on null pointers should not be allowed in constant expressions

On 07/18/2016 11:51 AM, Jason Merrill wrote: On 07/06/2016 06:20 PM, Martin Sebor wrote: @@ -2911,6 +2923,14 @@ cxx_eval_indirect_ref (const constexpr_ctx *ctx, tree t, if (*non_constant_p) return t; + if (integer_zerop (op0)) +{ + if (!ctx->quiet)

Re: [PATCH] Giant concepts patch

On Sun, Jul 10, 2016 at 11:20 AM, Andrew Sutton wrote: > I just tried building a fresh pull of cmcstl2, and I'm not seeing any > errors as a result of not handling those missing codes in > tsubst_constraint. At one point, I think it was not possible to get > those other

[C++ PATCH] cp_parser_save_member_function_body fix (PR c++/71909)

Hi! This patch fixes two issues: 1) as shown in the first testcase, cp_parser_save_member_function_body adds the catch () { ... } tokens into the saved token range even when there is no function try block (missing try keyword) 2) if the method starts with __transaction_{atomic,relaxed},

Re: [C++ PATCH] Allow frexp etc. builtins in c++14 constexpr (PR c++/50060)

On Mon, Jul 18, 2016 at 02:42:43PM -0400, Jason Merrill wrote: > Ah, I guess we need to check cxx_dialect in cxx_eval_store_expression, > not just in potential_constant_expression. Here is an updated version, bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2016-07-18 Jakub

Re: [patch, Fortran] Fix some string temporaries

Le 18/07/2016 à 22:20, Thomas Koenig a écrit : Am 18.07.2016 um 20:58 schrieb Mikael Morin: Unfortunately not. The original code (before I lifted out the functionality) sometimes had GFC_DEP_ERROR at the end of the function, which was then removed by return fin_dep == GFC_DEP_OVERLAP;

Re: [patch, Fortran] Fix some string temporaries

Am 18.07.2016 um 20:58 schrieb Mikael Morin: Unfortunately not. The original code (before I lifted out the functionality) sometimes had GFC_DEP_ERROR at the end of the function, which was then removed by return fin_dep == GFC_DEP_OVERLAP; That is very strange, there is an assert just a

Re: Debug algorithms

On 13/07/2016 19:45, Jonathan Wakely wrote: On 22/06/16 22:05 +0200, François Dumont wrote: Hi Here is eventually the so long promized patch to introduce Debug algos similarly to Debug containers. I'm trying to decide how much benefit this really gives us, and whether the obfuscation to

Re: [patch, Fortran] Fix some string temporaries

Le 17/07/2016 à 18:21, Thomas Koenig a écrit : Hi Mikael, Do we actually want to backport this? Technically, it is a regression, but people are not likely to notice much. It is not an ICE, neither a code correctness issue as far as I can see, so I would rather not backport. Fine with me.

Re: [C++ PATCH] Allow frexp etc. builtins in c++14 constexpr (PR c++/50060)

On Mon, Jul 18, 2016 at 2:33 PM, Jakub Jelinek wrote: > On Mon, Jul 18, 2016 at 02:07:50PM -0400, Jason Merrill wrote: >> >/* Fold away the NOP_EXPR from fold_builtin_n. */ >> >new_call = fold (new_call); >> >force_folding_builtin_constant_p = save_ffbcp; >> > + >>

Re: [C++ PATCH] Allow frexp etc. builtins in c++14 constexpr (PR c++/50060)

On Mon, Jul 18, 2016 at 02:07:50PM -0400, Jason Merrill wrote: > On Mon, Jul 18, 2016 at 2:03 PM, Jakub Jelinek wrote: > > On Mon, Jul 18, 2016 at 01:16:26PM -0400, Jason Merrill wrote: > > That is reasonable, but not 100% sure what to do if it returns NULL > > - it should

Re: [C++ PATCH] Fix ICE with SIZEOF_EXPR in default arg (PR c++/71822)

OK. On Mon, Jul 11, 2016 at 3:25 PM, Jakub Jelinek wrote: > Hi! > > For SIZEOF_EXPR, we rely on cp_fold to fold it. > But, for VEC_INIT_EXPR initialization, we actually just genericize it > without ever folding the expressions, so e.g. if the ctor has default args > and some

Re: [C++ PATCH] Fix error recovery in tsubst_baselink (PR c++/71826)

OK. On Mon, Jul 11, 2016 at 3:34 PM, Jakub Jelinek wrote: > Hi! > > Most of the spots in tsubst_baselink that actually access baselink after > it has been assigned lookup_fnfields () test that it is a BASELINK_P, except > one - the BASELINK_OPTYPE update. lookup_fnfields can

Re: [C++ PATCH] Fix lval {REAL,IMAG}PART_EXPR constexpr evaluation (PR c++/71828)

OK. On Mon, Jul 11, 2016 at 4:08 PM, Jakub Jelinek wrote: > Hi! > > REALPART_EXPR and IMAGPART_EXPR are handled like unary expressions, even > though they are references. For !lval that makes no difference, but for > lval it means we can get ADDR_EXPR of INTEGER_CST etc., or

Re: [C++ PATCH] Fix diagnostics ICE (PR c++/71835)

OK. On Mon, Jul 11, 2016 at 4:15 PM, Jakub Jelinek wrote: > Hi! > > add_conv_candidate creates cand->fn which is not a FUNCTION_DECL, but > some type, all spots in convert_like_real assume that if fn is non-NULL, it > is some decl. Just a couple of lines above this hunk we

Re: [C++ PATCH] Fix ICE with PTRMEM_CST (PR c++/70869)

OK for trunk; just the earlier patch is fine for 6.2. On Mon, Jul 11, 2016 at 4:17 PM, Jakub Jelinek wrote: > On Thu, Jul 07, 2016 at 03:06:55PM -0400, Jason Merrill wrote: >> On Thu, Jul 7, 2016 at 2:23 PM, Jakub Jelinek wrote: >> > On Thu, Jul 07, 2016 at

Re: [C++ RFC/Patch] PR c++/71665

On Tue, Jul 12, 2016 at 10:30 AM, Paolo Carlini wrote: > On 30/06/2016 19:49, Jason Merrill wrote: >> I think we should check the type before calling cxx_constant_value. >> > Ok, I got the point. I'm not sure however how far we want to go with this > and which kind of

Re: [C++ PATCH] Allow frexp etc. builtins in c++14 constexpr (PR c++/50060)

On Mon, Jul 18, 2016 at 2:03 PM, Jakub Jelinek wrote: > On Mon, Jul 18, 2016 at 01:16:26PM -0400, Jason Merrill wrote: > That is reasonable, but not 100% sure what to do if it returns NULL > - it should return t, but if I do VERIFY_CONSTANT (t); there or > manually > if

Patch ping

Hi! I'd like to ping a couple of C++ patches: - PR70869 - change fix from cp_genericize_r tweak to cp_walk_subtrees http://gcc.gnu.org/ml/gcc-patches/2016-07/msg00568.html - PR71835 - fix diagnostic ICE http://gcc.gnu.org/ml/gcc-patches/2016-07/msg00567.html - PR71828 - fix *PART_EXPR

Re: [C++ PATCH] Allow frexp etc. builtins in c++14 constexpr (PR c++/50060)

On Mon, Jul 18, 2016 at 01:16:26PM -0400, Jason Merrill wrote: > On Fri, Jul 15, 2016 at 2:42 PM, Jakub Jelinek wrote: > > While in C++11, builtins returning two results, one of them by dereferencing > > a pointer argument can't be constexpr, in my understanding in C++14 > >

Re: [PATCH] c++/60760 - arithmetic on null pointers should not be allowed in constant expressions

On 07/06/2016 06:20 PM, Martin Sebor wrote: @@ -2911,6 +2923,14 @@ cxx_eval_indirect_ref (const constexpr_ctx *ctx, tree t, if (*non_constant_p) return t; + if (integer_zerop (op0)) + { + if (!ctx->quiet) + error ("dereferencing a

Re: [PATCH] Add qsort comparator consistency checking (PR71702)

On Mon, 18 Jul 2016, Richard Biener wrote: > Ugh. What impact does this have on stage2 compile-time? It doesn't seem to be high enough to be measured reliably. I've made a trial run with -time=time.log in BOOT_CFLAGS, but there's a lot of variability in timings and the sum total of times ended

Re: [C++ PATCH] Allow frexp etc. builtins in c++14 constexpr (PR c++/50060)

On Fri, Jul 15, 2016 at 2:42 PM, Jakub Jelinek wrote: > While in C++11, builtins returning two results, one of them by dereferencing > a pointer argument can't be constexpr, in my understanding in C++14 > generalized constexprs they can. Yes. > So, this patch tweaks

Re: [C++ PATCH] Fix up vector cond expr handling in templates (PR c++/71871)

OK. Jason On Thu, Jul 14, 2016 at 11:21 AM, Jakub Jelinek wrote: > Hi! > > This patch reverts part of > https://gcc.gnu.org/ml/gcc-patches/2012-10/msg01665.html > which looks wrong to me. > The problem is that in templates, if the build_x_conditional_expr > arguments aren't

Re: [PATCH 8/9] shrink-wrap: shrink-wrapping for separate concerns

On 07/18/2016 06:34 PM, Segher Boessenkool wrote: + /* The frequency of executing the prologue for this BB and all BBs + dominated by it. */ + gcov_type cost; Is this frequency consideration the only thing that attempts to prevent placing prologue insns into loops? Yes. The

[PATCH, Fortran] DEC extra integer intrinsics

All, Attached is another extension patch introducing a new DEC compatibility flag -fdec-intrinsic-ints. With this flag the compiler recognizes the following variants for integer intrinsics which use a B/I/J/K prefix (with byte/integer/long/quad kind parameters): IABS (babs, iiabs, jiabs, kiabs)

Re: [PATCH] c++/58796 Make nullptr match exception handlers of pointer type

Perhaps the right answer is to drop support for catching nullptr as a pointers to member from the language. Jason

Re: [PATCH 8/9] shrink-wrap: shrink-wrapping for separate concerns

Hi Bernd, Thanks for the review. On Fri, Jul 15, 2016 at 02:42:24PM +0200, Bernd Schmidt wrote: > I still have misgivings about all the changes needed to the following > passes, but I guess there's no choice but to live with it. So, I'm > trying to look at this patch, but I'm finding it

[PATCH GCC]Improve no-overflow check in SCEV using value range info.

Hi, Scalar evolution needs to prove no-overflow for source variable when handling type conversion. This is important because otherwise we would fail to recognize result of the conversion as SCEV, resulting in missing loop optimizations. Take case added by this patch as an example, the loop

Merge switch statements in tree-cfgcleanup

The motivating example for this patch was a change that was submitted for genattrtab last year, which would have made us generate switch (type = get_attr_type (insn)) { ... some cases ... default: switch (type = get_attr_type (insn))) { ... some other cases ...

[PATCH, testsuite]: There is no warning for stack check with large frames on alpha

Hello! Alpha uses its own stack checking routine (part of the ABI), and doesn't use generic functionality. Disable check for warning for large frames on alpha. 2016-07-18 Uros Bizjak * gcc.dg/pr70017.c: Do not check for warning on alpha*-*-*. Tested on

Re: [PATCH GCC]Remove support for -funsafe-loop-optimizations

On Mon, Jul 18, 2016 at 4:28 PM, NightStrike wrote: > On Mon, Jul 18, 2016 at 3:55 AM, Bin.Cheng wrote: >> On Sat, Jul 16, 2016 at 6:28 PM, NightStrike wrote: >>> On Fri, Jul 15, 2016 at 1:07 PM, Bin Cheng

Re: [PATCH GCC]Remove support for -funsafe-loop-optimizations

On Mon, Jul 18, 2016 at 3:55 AM, Bin.Cheng wrote: > On Sat, Jul 16, 2016 at 6:28 PM, NightStrike wrote: >> On Fri, Jul 15, 2016 at 1:07 PM, Bin Cheng wrote: >>> Hi, >>> This patch removes support for -funsafe-loop-optimizations,

Re: Importing gnulib into the gcc tree

Replies inline -- Thanks, Ayush Goel On 17 July 2016 at 9:44:27 PM, Manuel López-Ibáñez (lopeziba...@gmail.com) wrote: > On 16 July 2016 at 10:54, ayush goel wrote: > > Hi, > > Thanks for the feedbacks. > > > > —> I’m already configuring gcc with multiple languages and multilib enabled > >

Re: C++ PATCHes to mangling of sizeof... and fold-expressions

On Fri, Jul 15, 2016 at 12:52 PM, Jason Merrill wrote: > Similarly, 71711 shows that we never implemented mangling of C++17 > fold-expressions, or partial instantiation of them. ...but this patch didn't implement demangling. So here's that part. commit

Re: [patch] Add new hook to diagnose address space usage

On 07/14/2016 05:11 PM, Georg-Johann Lay wrote: The hook allows better diagnostics: The address spaces are registered with c_register_addr_space and if the parser comes across an address space it provides the hook with the needed information, in particular the location of the token so that the

Shared libbackend.so (was: [PATCH] Avoid invoking ranlib on libbackend.a)

Hi, On Mon, 18 Jul 2016, Jakub Jelinek wrote: > On Mon, Jul 18, 2016 at 02:32:40PM +0200, Richard Biener wrote: > > While eliding ranlib sounds like a no-brainer the real benefit (I/O wise) is > > when you get rid of the archive or save link time by creating a (partially) > > linked DSO. ISTR

Re: [PATCH] Avoid invoking ranlib on libbackend.a

On Mon, Jul 18, 2016 at 9:53 AM, Segher Boessenkool wrote: > On Mon, Jul 18, 2016 at 09:05:13AM -0400, Patrick Palka wrote: >> On Mon, Jul 18, 2016 at 8:44 AM, Segher Boessenkool >> wrote: >> > On Mon, Jul 18, 2016 at 06:35:11AM -0500,

Re: [v3 PATCH] Minor comment cleanup on optional.

On 18/07/16 15:43 +0300, Ville Voutilainen wrote: Clean up optional's comments. * include/std/optional: Remove incorrect section headers from comments when redundant, replace bare section headers with more descriptive comments. OK for trunk, thanks.

Re: [PATCH] Avoid invoking ranlib on libbackend.a

On Mon, Jul 18, 2016 at 09:05:13AM -0400, Patrick Palka wrote: > On Mon, Jul 18, 2016 at 8:44 AM, Segher Boessenkool > wrote: > > On Mon, Jul 18, 2016 at 06:35:11AM -0500, Segher Boessenkool wrote: > >> Or, if using GNU ar, you can even use -S, if that helps (after

Re: Ping: Fix PR fortran/71688

Dear Martin, This looks like an 'obvious' fix. OK for all the branches, 4.9->trunk. Thanks for the patch Paul On 18 July 2016 at 14:53, Martin Jambor wrote: > Ping (this time also CCing fort...@gcc.gnu and Honza). > > I really think this should be backported to 4.9 in time

[PATCH 3/4] Support movbe as a i386 target optimization node

gcc/testsuite/ChangeLog: 2016-07-18 Martin Liska * gcc.target/i386/movbe-4.c: New test. gcc/ChangeLog: 2016-07-18 Martin Liska * config/i386/i386.c (ix86_valid_target_attribute_inner_p): Handle movbe. --- gcc/config/i386/i386.c

[PATCH 1/4] Fix PR target/71652

gcc/ChangeLog: 2016-07-18 Martin Liska PR target/71652 * config/i386/i386.c (ix86_option_override_internal): Change signature and return false when there's an error related to arch string. (release_options_strings): New function.

[PATCH 4/4] Remove fused-madd from documentation

gcc/ChangeLog: 2016-07-18 Martin Liska * doc/extend.texi: Remove fused-madd from i386 target options. --- gcc/doc/extend.texi | 5 - 1 file changed, 5 deletions(-) diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi index 5b9e617..30957ce 100644 ---

[PATCH 2/4] Support crc32 as a i386 target optimization node

gcc/ChangeLog: 2016-07-18 Martin Liska * config/i386/i386.c (ix86_valid_target_attribute_inner_p): Handle crc32. gcc/testsuite/ChangeLog: 2016-07-18 Martin Liska * gcc.target/i386/crc32-5.c: New test. --- gcc/config/i386/i386.c

[PATCH 0/4] Properly handle GCC target("march=") (PR71652)

Hello. Following small patch set targets $subject, where we ICE if someone uses #pragma GCC target ("arch=generic"). My attempt is to not to create a new target optimization node in case of a wrong value of march string. Such approach does not generate multiple errors. Apart from that, I also

[PATCH] Fix PR71907

The following avoids PR71907 (tree_nonartificial_location failing) by making sure to not completely drop BLOCK_ABSTRACT_ORIGIN but instead add self-references (a "this has been inlined flag basically") for BLOCKs not being inlined_function_outer_scope_p. LTO bootstrapped on

[PATCH] Fix PR71908

The following fixes PR71908. Bootstrapped on x86_64-unknown-linux-gnu, testing in progress. Richard. 2016-07-18 Richard Biener PR tree-optimization/71908 * tree-ssa-structalias.c (get_constraint_for_component_ref): Handle symbolic constants in a

[PATCH] Fix PR71901 (and PR71893 in a different way)

The following fixes the PRs by not storing expressions inside the reference ops for ARRAY_REFs for their element size but their original operand 3. This requires keeping track of the element alignment and avoids any issues with not folding * /[ex] chains. It also enables "real" VN of those

Re: [PATCH v5] Allocate constant size dynamic stack space in the prologue

> gcc/ChangeLog > > * cfgexpand.c (expand_stack_vars): Implement synamic stack space > allocation in the prologue. > * explow.c (get_dynamic_stack_base): New function to return an address > expression for the dynamic stack base. > (get_dynamic_stack_size): New

Re: [PATCH] Avoid invoking ranlib on libbackend.a

On Mon, Jul 18, 2016 at 8:44 AM, Segher Boessenkool wrote: > On Mon, Jul 18, 2016 at 06:35:11AM -0500, Segher Boessenkool wrote: >> Or, if using GNU ar, you can even use -S, if that helps (after testing >> for it in configure, of course). > > I meant -T. Some day I

GCC 4.9.4 Status Report (2016-07-18)

Status == The GCC 4.9 branch is still open for regression and documentation fixes but given GCC 6.2 is close it's about time to close the branch with a last release from it. Thus in the next week I plan to do a RC for GCC 4.9.4 following with a release and the branch closing game. Please

Ping: Fix PR fortran/71688

Ping (this time also CCing fort...@gcc.gnu and Honza). I really think this should be backported to 4.9 in time for the last release. Thanks, Martin - Original message from Martin Jambor - Date: Thu, 30 Jun 2016 11:13:17 +0200 From: Martin Jambor To:

Re: [PATCH] Avoid invoking ranlib on libbackend.a

On Mon, Jul 18, 2016 at 06:35:11AM -0500, Segher Boessenkool wrote: > Or, if using GNU ar, you can even use -S, if that helps (after testing > for it in configure, of course). I meant -T. Some day I will learn how to type, promise! Segher

Re: [PATCH] Avoid invoking ranlib on libbackend.a

On Mon, Jul 18, 2016 at 2:37 PM, Jakub Jelinek wrote: > On Mon, Jul 18, 2016 at 02:32:40PM +0200, Richard Biener wrote: >> While eliding ranlib sounds like a no-brainer the real benefit (I/O wise) is >> when you get rid of the archive or save link time by creating a (partially)

[v3 PATCH] Minor comment cleanup on optional.

Tested on Linux-x64. This should be fairly straightforward. :) 2016-07-18 Ville Voutilainen Clean up optional's comments. * include/std/optional: Remove incorrect section headers from comments when redundant, replace bare section headers with more

Re: [PATCH] c++/58796 Make nullptr match exception handlers of pointer type

On 18/07/16 11:51 +0100, Jonathan Wakely wrote: say anything about the identity of the caught objects when nullptr is thrown). Not sure what happened to this sentence, it was supposed to say: (The standard doesn't say anything about the identity of the caught objects when nullptr is thrown).

Re: [PATCH] Avoid invoking ranlib on libbackend.a

On Mon, Jul 18, 2016 at 02:32:40PM +0200, Richard Biener wrote: > While eliding ranlib sounds like a no-brainer the real benefit (I/O wise) is > when you get rid of the archive or save link time by creating a (partially) > linked DSO. ISTR Michael Matz has patches to do that. Whether it's DSO?

Re: [PATCH] Avoid invoking ranlib on libbackend.a

On Mon, Jul 18, 2016 at 1:35 PM, Segher Boessenkool wrote: > On Sun, Jul 17, 2016 at 10:04:13PM -0400, Patrick Palka wrote: >> I did some digging to figure out the origin of libbackend.a. It was was >> created to work around a command line length limit on a VAX system

Re: [PATCH, rs6000] Fix vec_construct vectorization cost to be somewhat more accurate

On Mon, Jul 18, 2016 at 1:56 PM, Segher Boessenkool wrote: > Hi Bill, > > On Fri, Jul 15, 2016 at 08:55:08AM -0500, Bill Schmidt wrote: >> This patch is a follow-up to Richard's patch of >> https://gcc.gnu.org/ml/gcc-patches/2016-06/msg00584.html. The cost of a >>

Re: [PATCH][RFC] PR middle-end/22141 GIMPLE store widening pass

On Fri, Jul 15, 2016 at 5:13 PM, Kyrill Tkachov wrote: > Hi all, > > This is a GIMPLE pass to implement PR middle-end/22141. that is merge narrow > stores of constants > into fewer wider stores. A 2009 patch from Jakub [1] contains many > testcases but a simple

Re: [PATCH] Avoid invoking ranlib on libbackend.a

Segher Boessenkool writes: > Or, if using GNU ar, you can even use -S, if that helps (after testing > for it in configure, of course). BSD ar has it too. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748

Re: [PATCH, rs6000] Fix vec_construct vectorization cost to be somewhat more accurate

Hi Bill, On Fri, Jul 15, 2016 at 08:55:08AM -0500, Bill Schmidt wrote: > This patch is a follow-up to Richard's patch of > https://gcc.gnu.org/ml/gcc-patches/2016-06/msg00584.html. The cost of a > vec_construct (initialization of an N-way vector by N scalars) is too low, > which can cause

Re: [RFC][IPA-VRP] Early VRP Implementation

On Fri, Jul 15, 2016 at 9:33 AM, kugan wrote: > Hi Andrew, > > On 15/07/16 17:28, Andrew Pinski wrote: >> >> On Fri, Jul 15, 2016 at 12:08 AM, kugan >> wrote: >>> >>> Hi Andrew, >>> Why separate out early VRP from

Re: [PATCH] Avoid invoking ranlib on libbackend.a

On Sun, Jul 17, 2016 at 10:04:13PM -0400, Patrick Palka wrote: > I did some digging to figure out the origin of libbackend.a. It was was > created to work around a command line length limit on a VAX system > (https://gcc.gnu.org/ml/gcc-bugs/2000-06/msg00438.html). The 1600 byte > command line

Re: [RFC][IPA-VRP] Teach tree-vrp to use the VR set in params

On Fri, Jul 15, 2016 at 6:47 AM, kugan wrote: > Hi, > > > > This patch teaches tree-vrp to use the VR set in params. diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c index 8c87c06..ad3891c 100644 --- a/gcc/tree-vrp.c +++ b/gcc/tree-vrp.c @@ -667,6 +667,20 @@

Re: [PATCH, rs6000] Fix vec_construct vectorization cost to be somewhat more accurate

On Fri, Jul 15, 2016 at 3:55 PM, Bill Schmidt wrote: > Hi, > > This patch is a follow-up to Richard's patch of > https://gcc.gnu.org/ml/gcc-patches/2016-06/msg00584.html. The cost of a > vec_construct (initialization of an N-way vector by N scalars) is too low, >

[Committed] S/390: Fix alignment check for literal pool references.

Committed to head and GCC 6 branch. gcc/ChangeLog: 2016-07-18 Andreas Krebbel * config/s390/s390.c (s390_encode_section_info): Always set notaligned marker if mode size is 0 or no MEM_ALIGN info could be found. gcc/testsuite/ChangeLog:

Re: [PATCH] c++/58796 Make nullptr match exception handlers of pointer type

On 16/07/16 11:11 +0200, Jakub Jelinek wrote: On Fri, Jul 15, 2016 at 11:14:03PM +0100, Jonathan Wakely wrote: On 15/07/16 22:53 +0100, Jonathan Wakely wrote: >On 15/07/16 23:36 +0200, Jakub Jelinek wrote: >>On Fri, Jul 15, 2016 at 10:07:03PM +0100, Jonathan Wakely wrote: + if (typeid

Re: RFA: new pass to warn on questionable uses of alloca() and VLAs

On 07/16/2016 05:07 PM, Martin Sebor wrote: [Addressed all of Manu's suggestions as well.] Done. -Walloca and -Wvla warn on any use of alloca and VLAs accordingly, with or without optimization. I sorry() on the bounded cases. I think it's an improvement though I suspect we each have a

Re: [PATCH] Add qsort comparator consistency checking (PR71702)

On Fri, Jul 15, 2016 at 6:00 PM, Alexander Monakov wrote: > Hi, > > this patch adds internal checking for comparator functions that GCC passes to > qsort. PR71702 describes an ICE that happens because comparator > 'dr_group_sort_cmp' used to be non-transitive in some cases

Re: [PATCH PR71734] Add missed check that reference defined inside loop.

On Fri, Jul 8, 2016 at 4:07 PM, Yuri Rumyantsev wrote: > Hi Richard, > > Thanks for your help - your patch looks much better. > Here is new patch in which additional argument was added to determine > source loop of reference. > > Bootstrap and regression testing did not show

Re: RFA: new pass to warn on questionable uses of alloca() and VLAs

On 07/17/2016 11:52 AM, Manuel López-Ibáñez wrote: On 15/07/16 18:05, Aldy Hernandez wrote: +case OPT_Walloca_larger_than_: + if (!value) +inform (loc, "-Walloca-larger-than=0 is meaningless"); + break; + +case OPT_Wvla_larger_than_: + if (!value) +inform (loc,

Re: [PATCH GCC]Remove support for -funsafe-loop-optimizations

On Fri, Jul 15, 2016 at 6:23 PM, Richard Biener wrote: > On July 15, 2016 7:16:42 PM GMT+02:00, Bernd Schmidt > wrote: >>On 07/15/2016 07:07 PM, Bin Cheng wrote: >> >>> Bootstrap and test on x86_64. Is it OK? >> >>If you do this you'll also need

Re: [patch, Fortran] Fix some string temporaries

Hi Thomas, > So, OK with a comment why this appears? Or should I simply > rename GFC_DEP_ERROR to GFC_DEP_NODEPFOUND to make this a bit > clearer? I recommend the latter. Reporting an error should be done only when an error occurred, but no dependency detected does not feel like an error. Let's

Re: [PATCH GCC]Remove support for -funsafe-loop-optimizations

On Sat, Jul 16, 2016 at 6:28 PM, NightStrike wrote: > On Fri, Jul 15, 2016 at 1:07 PM, Bin Cheng wrote: >> Hi, >> This patch removes support for -funsafe-loop-optimizations, as well as >> -Wunsafe-loop-optimizations. By its name, this option does

Re: [RFC, v2] Test coverage for --param boundary values

On 07/15/2016 09:22 AM, Thomas Schwinge wrote: > Hi! > > On Fri, 8 Jul 2016 14:47:46 +0200, Martin Liška wrote: >> From f84ce7be4a998089541fb4512e19f54a4ec25cf6 Mon Sep 17 00:00:00 2001 >> From: marxin >> Date: Fri, 8 Jul 2016 10:59:24 +0200 >> Subject: [PATCH]

Re: [PATCH] Fix PR71893

Hi! On Fri, 15 Jul 2016 15:19:59 +0200 (CEST), Richard Biener wrote: > This PR shows that (There is also PR71901 suspected to be related; David CCed.) > array_ref_element_size may apply spurious casts which > in turn end up confusing VN/PRE. > > Fixed as follows,

Re: [patch,avr] make progmem work on AVR_TINY, use TARGET_ADDR_SPACE_DIAGNOSE_USAGE

2016-07-15 18:26 GMT+03:00 Georg-Johann Lay : > This patch needs new hook TARGET_ADDR_SPACE_DIAGNOSE_USAGE: > https://gcc.gnu.org/ml/gcc-patches/2016-07/msg00839.html > > This patch turns attribute progmem into a working feature for AVR_TINY > cores. > > It boils down to adding