Re: [PATCHv3, resent] Add a warning for suspicious use of conditional expressions in boolean context

On 9/20/16, Trevor Saunders wrote: > On Wed, Sep 21, 2016 at 01:13:41AM +0200, Bernd Schmidt wrote: >> On 09/21/2016 01:09 AM, Trevor Saunders wrote: >> > >> > I thought I remember discussing this macro with you, but see what was >> > checked in I'll believe I'm thinking of

Re: [PATCH] - improve sprintf buffer overflow detection (middle-end/49905)

On 09/20/2016 01:38 PM, David Malcolm wrote: On Tue, 2016-09-20 at 13:35 -0600, Martin Sebor wrote: [...] +#if 0 ... +#else ... +#endif Please remove the #if 0'd code. Sorry about that. This was left over from my effort to persuade the substring_loc class to underline just the last

Re: [PATCHv3, resent] Add a warning for suspicious use of conditional expressions in boolean context

On Wed, Sep 21, 2016 at 01:13:41AM +0200, Bernd Schmidt wrote: > On 09/21/2016 01:09 AM, Trevor Saunders wrote: > > > > I thought I remember discussing this macro with you, but see what was > > checked in I'll believe I'm thinking of something similar but different. > > I think this here was an

Re: [PATCH] Optimise the fpclassify builtin to perform integer operations when possible

On Tue, 20 Sep 2016, Michael Meissner wrote: > It would be better to have a fpclassify2 pattern, and if it isn't > defined, then do the machine independent processing. That is the way it is > done elsewhere. But note: * The __builtin_fpclassify function takes arguments for all the possible

[PATCH], PR 77670, Fix PowerPC ISA 3.0 -mpower9-minmax code generation

There are some instructions in PowerPC ISA 3.0 that are not currently enabled by default when you use -mcpu=power9. These instructions are currently added with the -mpower9-minmax switch. I recently built Spec 2006 with the current trunk compiler, and I discovered that three of the benchmarks

Re: [PATCHv3, resent] Add a warning for suspicious use of conditional expressions in boolean context

On 09/21/2016 01:09 AM, Trevor Saunders wrote: I thought I remember discussing this macro with you, but see what was checked in I'll believe I'm thinking of something similar but different. I think this here was an earlier patch and the one we were discussing recently was the other macro

Re: [PATCHv3, resent] Add a warning for suspicious use of conditional expressions in boolean context

On Tue, Sep 20, 2016 at 05:30:36PM +0200, Bernd Schmidt wrote: > On 09/20/2016 05:18 PM, Jeff Law wrote: > > > I assume HARD_FRAME_POINTER_REGNUM is never zero. > > It could be zero. It's just a hard register number. No target has the > > property that its hard frame pointer register is 0 though

RE: [PATCH] Fix PR tree-optimization/77654

It looks like the original message was dropped, resending. Doug From: Doug Gilmore Sent: Tuesday, September 20, 2016 2:12 PM To: gcc-patches@gcc.gnu.org; rgue...@gcc.gnu.org Subject: [PATCH] Fix PR tree-optimization/77654 From:

RE: [PATCH] Fix PR tree-optimization/77654

Add missing attachment. Doug gcc/ PR tree-optimization/77654 * tree-ssa-alias.c (issue_prefetch_ref): Add call to duplicate_ssa_name_ptr_info. From ec9069b7b7b07d5fda9c04aaa9b385fba89a6e16 Mon Sep 17 00:00:00 2001 From: Doug Gilmore Date: Tue, 6

[PATCH] PR68212, Correct frequencies/counts when unrolling

The following patch corrects frequency/count values computed when generating the switch blocks/peeled loop copies before the loop. The two main problem areas were for the peeled copies duplicate_loop_to_header_edge was not using the preheader frequency as part of the scale factor when peeling a

Re: [Patch, fortran] PR77657 - link error with implementation of user-defined derived type input/output (UD-DTIO) in child extending abstract parent

On 09/20/2016 01:15 PM, Paul Richard Thomas wrote: > Dear All, > > Once found, the fix for this PR is trivial. The generic name is only > to be found in the parent derived type. Since this is over-ridden in > the type extension, not only is the wrong symbol selected for the dtio > procedure but,

Re: [PATCH] Optimise the fpclassify builtin to perform integer operations when possible

On Tue, Sep 20, 2016 at 01:19:07PM +0100, Tamar Christina wrote: > On 19/09/16 23:16, Michael Meissner wrote: > >On Mon, Sep 12, 2016 at 04:19:32PM +, Tamar Christina wrote: > >>Hi All, > >> > >>This patch adds an optimized route to the fpclassify builtin > >>for floating point numbers which

Re: Document OpenACC status for GCC 6

[ Old e-mail alert ] On Fri, 22 Apr 2016, Thomas Schwinge wrote: > Thanks for the review; OK to commit as follows? And then, should > something be added to the "News" section on > itself, too? (I don't know the policy for that. We didn't suggest that > for GCC 5, because

[Patch, fortran] PR77657 - link error with implementation of user-defined derived type input/output (UD-DTIO) in child extending abstract parent

Dear All, Once found, the fix for this PR is trivial. The generic name is only to be found in the parent derived type. Since this is over-ridden in the type extension, not only is the wrong symbol selected for the dtio procedure but, being abstract, the procedure does not exist. The mechanism is

Re: [PATCH] - improve sprintf buffer overflow detection (middle-end/49905)

On Tue, 2016-09-20 at 13:35 -0600, Martin Sebor wrote: [...] > > > +#if 0 > ... > > > +#else > ... > > > +#endif > > Please remove the #if 0'd code. > > Sorry about that. This was left over from my effort to persuade > the substring_loc class to underline just the last quote of the > format

Re: [PATCH] - improve sprintf buffer overflow detection (middle-end/49905)

+ /* The minimum and maximum length. The MAXLEN pointer stays unchanged + but MINLEN may be cleared during the execution of the function. */ + tree *minlen = length; + tree* const maxlen = length + 1; Check formatting here. I'm not sure if the formatting standards explicitly state how

Re: [gofrontend-dev] Go patch committed: Avoid warning by using a local var for std::ofstream

* Ian Lance Taylor: > GCC PR 77625 is about a warning while compiling the Go frontend. The > Go frontend called `new std::ofstream()`, and the warning is "error: > ‘new’ of type ‘std::ofstream {aka std::basic_ofstream}’ with > extended alignment 16". Frankly I'm not sure how this supposed to >

Re: Register numbers in RTL dumps (was Re: [PATCH 0/9] RFC: selftests based on RTL dumps)

On Tue, 2016-09-20 at 09:20 -0600, Jeff Law wrote: > On 09/20/2016 08:34 AM, Bernd Schmidt wrote: > > On 09/20/2016 04:32 PM, David Malcolm wrote: > > > > > > To summarize so far: you want every pseudo to have its regno > > > dumped > > > with a 'p' prefix, and renumber them on dump (and then on

[PATCH] Fix JUMP_LABEL documentation

On Tue, Sep 20, 2016 at 12:11:45PM -0500, Segher Boessenkool wrote: > I'm just pointing out the documentation is out-of-date here. I'll do > a patch. Like this. Okay for trunk, 6, 5? Thanks, Segher 2016-09-20 Segher Boessenkool * doc/rtl.texi

[committed] Adjust fall through comment

This patch adjusts a fall through comment so that our -Wimplicit-fallthrough comment parsing handles this well. Applying to trunk. 2016-09-20 Marek Polacek * trans-intrinsic.c (conv_expr_ref_to_caf_ref): Adjust fall through comment. diff --git

Re: [PATCHv3, resent] Add a warning for suspicious use of conditional expressions in boolean context

On 09/20/16 16:51, Jason Merrill wrote: > On Tue, Sep 20, 2016 at 10:11 AM, Bernd Edlinger > wrote: >> On 09/20/16 13:29, Kyrill Tkachov wrote: >>> >>> arm bootstrap is now failing: >>> $SRC/gcc/config/arm/arm.h:2229:40: error: ?: using integer constants in >>> boolean

Re: Fix libgo syscall test on Solaris

On Mon, Sep 12, 2016 at 1:07 AM, Rainer Orth wrote: > The libgo syscall test has been failing on Solaris for quite some time: > > exec_unix_test.go:174:19: error: reference to undefined identifier > 'syscall.Ioctl' > errno := syscall.Ioctl(tty.Fd(),

Re: [PATCH] libstdc++/77641 fix std::variant for literal types

On Mon, Sep 19, 2016 at 1:06 PM, Tim Shen wrote: > I believe that it's a "typo" from me - it should be > is_trivially_destructible, not is_default_constructible (so that we > can avoid using aligned_storage in the corresponding specialization). > is_literal_type works, since

Re: [PATCH] - improve sprintf buffer overflow detection (middle-end/49905)

David, in the way of feedback, I spent hours debugging the simple multiline test I added. It seems that DejaGnu is exquisitely sensitive to whitespaces in the multiline output. I appreciate that spacing is essential to lining up the caret and the tildes with the text of the program but tests

[PATCH, i386]: Use pow2p_hwi some more

2016-09-20 Uros Bizjak * config/i386/i386.md (mult->ashift peephole2s): Use pow2p_hwi instead of exact_log2. Bootstrapped and regression tested on x86_64-linux-gnu {,-m32} , committed to mainline SVN. Uros. Index: config/i386/i386.md

Re: [PATCH][ARM][v2] Use snprintf rather than sprintf

On 09/20/2016 05:49 PM, Kyrill Tkachov wrote: > Ok, I'm proposing a new function defined in system.h > (though I'm open to suggestions for other location). > It would be something like: > > static inline int ATTRIBUTE_PRINTF_3 > gcc_snprintf (char *str, size_t size, const char *format, ...) > {

Go patch committed: Avoid warning by using a local var for std::ofstream

GCC PR 77625 is about a warning while compiling the Go frontend. The Go frontend called `new std::ofstream()`, and the warning is "error: ‘new’ of type ‘std::ofstream {aka std::basic_ofstream}’ with extended alignment 16". Frankly I'm not sure how this supposed to work: shouldn't it be possible

Re: [PATCH 0/8] make next_*_insn take rtx_insn * arguments

On 09/20/2016 11:11 AM, Segher Boessenkool wrote: On Tue, Sep 20, 2016 at 08:52:46AM -0600, Jeff Law wrote: - JUMP_LABEL can be a return which is not an insn. That also seems like something that should be improved at some point. The JUMP_LABEL field within a JUMP_INSN? That sounds like a

Re: [PATCH] Optimise the fpclassify builtin to perform integer operations when possible

On Tue, 20 Sep 2016, Jeff Law wrote: > Could we defer lowering in the case where the object is not addressable until > gimple->rtl expansion time? That's the best time to introduce target > dependencies into the code we generate. If we do that (remembering that -fsignaling-nans always wants the

Re: C/C++ PATCH to implement -Wbool-operation (PR c/77490)

On Mon, Sep 19, 2016 at 02:41:04PM -0400, Jason Merrill wrote: > On 09/16/2016 05:01 AM, Marek Polacek wrote: > > @@ -5853,7 +5853,16 @@ cp_build_unary_op (enum tree_code code, tree xarg, > > bool noconvert, > >arg, true))) > > errstring =

Re: [patch,avr] Fix PR77326: CC_NONE might clobber condition code

2016-09-20 13:07 GMT+03:00 Georg-Johann Lay : > This fixes the case of CC_NONE (insn attribute for cc is "none"): > > Even in cases where the instructions of an insn do not change the condition > code of the machine, they still might change some registers by clobber, set, > etc. If

Re: [PATCH 0/8] make next_*_insn take rtx_insn * arguments

On Tue, Sep 20, 2016 at 08:52:46AM -0600, Jeff Law wrote: > >- JUMP_LABEL can be a return which is not an insn. That also seems > > like something that should be improved at some point. > The JUMP_LABEL field within a JUMP_INSN? That sounds like a bug. > >>> > >>>yes, see the

Re: [PATCH] accept flexible arrays in struct in unions (c++/71912 - [6/7 regression])

On 09/16/2016 12:19 PM, Jason Merrill wrote: On 09/14/2016 01:03 PM, Martin Sebor wrote: Attached is an updated patch that does away with the "overlapping" warning and instead issues the same warnings as the C front end (though with more context). In struct flexmems_t I've retained the NEXT

[PATCH, i386]: Fix PR77621 (target part), handle Atom V2DFmode tuning through vector cost infrastructure

Hello! Attached patch improves Atom V2DFmode vectorization by penalizing V2DF mode insns through vector cost infrastructure. Looking at Agner Fog's instruction tables, it is evident that only V2DFmode arithmetic insns (e.g. addpd, maxpd, sqrtpd, ...) have increased latencies, and we shouldn't

Re: [PATCH][ARM][v2] Use snprintf rather than sprintf

On 20/09/16 17:49, Kyrill Tkachov wrote: > > On 20/09/16 15:13, Richard Earnshaw (lists) wrote: >> On 08/09/16 12:00, Kyrill Tkachov wrote: >>> Hi all, >>> >>> This is a rebase and slight respin of [1] that I sent out last November >>> to change all uses of >>> sprintf to snprintf in the arm

Re: [PATCH][ARM][v2] Use snprintf rather than sprintf

On 20/09/16 15:13, Richard Earnshaw (lists) wrote: On 08/09/16 12:00, Kyrill Tkachov wrote: Hi all, This is a rebase and slight respin of [1] that I sent out last November to change all uses of sprintf to snprintf in the arm backend. Bootstrapped and tested on arm-none-linux-gnueabihf. Ok

libgo patch committed: Fix type passed to __splitstack_find

PR 77642 points out that since the change to generate runtime types from Go libgo is passing the wrong type to __splitstack_find: it is passing uintptr* to a function that expects size_t*. This breaks on s390. This patch, based on one from Andreas Krebbel in the PR, fixes the problem.

Re: [PATCHv3, resent] Add a warning for suspicious use of conditional expressions in boolean context

On 09/20/16 18:29, Kyrill Tkachov wrote: >> >> I'll try bootstrapping and testing this change on >> arm-none-linux-gnueabihf. >> > > ... and I'm hitting the same issue in sel-sched.c: > if (fixed_regs[regno] > || global_regs[regno] > || (!HARD_FRAME_POINTER_IS_FRAME_POINTER &&

Re: [patch, libgomp, OpenACC] Additional enter/exit data map handling

On 08/29/2016 12:46 AM, Chung-Lin Tang wrote: > Index: oacc-parallel.c > === > --- oacc-parallel.c (revision 239814) > +++ oacc-parallel.c (working copy) > @@ -38,15 +38,23 @@ > #include > #include > > +/* Returns the

Re: [PATCH, docs] invoke.texi: random copy-editing

On Mon, 5 Sep 2016, Sandra Loosemore wrote: > Adjective phrases immediately before the noun they modify are > hyphenated. This is the same reason why we write "floating-point > arithmetic" but "floating point", unhyphenated, as a noun. Thanks for the explanation / background, Sandra. Below is

Re: [PATCH] More trivial bits from early LTO debug merge

dbxout.c has two definitions of the structure: dbx and xcoff. The patch forgot to update the xcoff one (lucky AIX :-). * dbxout.c (xcoff_debug_hooks): Add filename parameter to early_finish hook. Thanks, David Index: dbxout.c ===

Re: [PATCHv3, resent] Add a warning for suspicious use of conditional expressions in boolean context

On 20/09/16 17:12, Kyrill Tkachov wrote: On 20/09/16 16:30, Bernd Schmidt wrote: On 09/20/2016 05:18 PM, Jeff Law wrote: I assume HARD_FRAME_POINTER_REGNUM is never zero. It could be zero. It's just a hard register number. No target has the property that its hard frame pointer register is

Re: [PATCHv3, resent] Add a warning for suspicious use of conditional expressions in boolean context

On 09/20/16 18:12, Kyrill Tkachov wrote: > > On 20/09/16 16:30, Bernd Schmidt wrote: >> On 09/20/2016 05:18 PM, Jeff Law wrote: I assume HARD_FRAME_POINTER_REGNUM is never zero. >>> It could be zero. It's just a hard register number. No target has the >>> property that its hard frame

Re: Implement -Wimplicit-fallthrough (version 9)

On 09/20/2016 11:33 AM, Marek Polacek wrote: @@ -5135,6 +5135,30 @@ cp_parser_primary_expression (cp_parser *parser, case RID_AT_SELECTOR: return cp_parser_objc_expression (parser); + case RID_ATTRIBUTE: Attribute handling doesn't belong in this function; we don't want

[C++ PATCH] Fix constexpr switch handling (PR c++/77467, take 2)

On Mon, Sep 19, 2016 at 02:34:17PM -0400, Jason Merrill wrote: > > For STATEMENT_LIST that is called by cxx_eval_constant_expression, > > for BIND_EXPR if we are lucky enough that BIND_EXPR_BODY is a STATEMENT_LIST > > too (otherwise I assume even my patch doesn't fix it, it would need to > >

Re: [PATCHv3, resent] Add a warning for suspicious use of conditional expressions in boolean context

On 20/09/16 16:30, Bernd Schmidt wrote: On 09/20/2016 05:18 PM, Jeff Law wrote: I assume HARD_FRAME_POINTER_REGNUM is never zero. It could be zero. It's just a hard register number. No target has the property that its hard frame pointer register is 0 though :-) git blame to the rescue.

Re: [PATCH] [AArch64] Add missing attributes to arm_neon.h

On Tue, Sep 20, 2016 at 04:37:42PM +0100, Tamar Christina wrote: > Hi All, > > This patch fixes the regression failures introduced by r240256. > It adds some missing attributes to the functions: > > * vst2_s64 > * vst2_u64 > * vst2_f64 > * vst2_s8 > * vst3_s64 > * vst3_u64 > * vst3_f64 >

Re: [PATCH] Fix PR tree-optimization/77550

On 09/20/16 09:41, Richard Biener wrote: > On Mon, 19 Sep 2016, Bernd Edlinger wrote: > >> On 09/19/16 11:25, Richard Biener wrote: >>> On Sun, 18 Sep 2016, Bernd Edlinger wrote: >>> Hi, this PR shows that in vectorizable_store and vectorizable_load as well, the vector access

[PATCH] [AArch64] Add missing attributes to arm_neon.h

Hi All, This patch fixes the regression failures introduced by r240256. It adds some missing attributes to the functions: * vst2_s64 * vst2_u64 * vst2_f64 * vst2_s8 * vst3_s64 * vst3_u64 * vst3_f64 * vst3_s8 * vst4_s64 * vst4_u64 * vst4_f64 * vst4_s8 These were always missing but

Implement -Wimplicit-fallthrough (version 9)

Time for another latest & greatest version of -Wimplicit-fallthrough. Hope this time it's near its end. Changes from last time: * I addressed Jakub's comment, for details see * in the C FE: case 0: __attribute)) ((fallthrough));

Re: Register numbers in RTL dumps (was Re: [PATCH 0/9] RFC: selftests based on RTL dumps)

On 09/20/2016 05:20 PM, Jeff Law wrote: On 09/20/2016 08:34 AM, Bernd Schmidt wrote: (reg/f:DI v1 virtual-stack-vars) this. Doesn't the same apply to the number of virtual stack regs? Those are in the same array as pseudos. So ISTM we prefix in the dump, but do adjustment of the number

Re: [PATCHv3, resent] Add a warning for suspicious use of conditional expressions in boolean context

On 09/20/2016 05:18 PM, Jeff Law wrote: I assume HARD_FRAME_POINTER_REGNUM is never zero. It could be zero. It's just a hard register number. No target has the property that its hard frame pointer register is 0 though :-) git blame to the rescue. The current state comes from one of

Re: [PATCH] Tree-level fix for PR 69526

On 09/20/2016 06:31 AM, Robin Dapp wrote: Hi, I meant to do sth like Index: tree-ssa-propagate.c === --- tree-ssa-propagate.c(revision 240133) +++ tree-ssa-propagate.c(working copy) @@ -1105,10 +1105,10 @@

[PATCH GCC][v2]Simplify alias check code generation in vectorizer

Hi, I originally posted a patch improving code generation for alias check in vectorizer at https://gcc.gnu.org/ml/gcc-patches/2016-06/msg00929.html. Here it's the 2nd version (better) patch. It detects data reference pair in which the two references are only different to each other wrto

Re: Register numbers in RTL dumps (was Re: [PATCH 0/9] RFC: selftests based on RTL dumps)

On 09/20/2016 08:34 AM, Bernd Schmidt wrote: On 09/20/2016 04:32 PM, David Malcolm wrote: To summarize so far: you want every pseudo to have its regno dumped with a 'p' prefix, and renumber them on dump (and then on load). OK. Renumbering is not helpful because it interferes with the view

Re: [PATCHv3, resent] Add a warning for suspicious use of conditional expressions in boolean context

On 09/20/2016 08:38 AM, Bernd Edlinger wrote: On 09/20/16 16:20, Kyrill Tkachov wrote: On 20/09/16 15:11, Bernd Edlinger wrote: On 09/20/16 13:29, Kyrill Tkachov wrote: arm bootstrap is now failing: $SRC/gcc/config/arm/arm.h:2229:40: error: ?: using integer constants in boolean context

Re: [C++ PATCH] Fix parser ICE with [[...]] and [[unused,...]] (PR c++/77637)

OK. On Mon, Sep 19, 2016 at 5:50 PM, Jakub Jelinek wrote: > Hi! > > As the testcase shows, while the grammar has > attribute-list: > attribute[opt] > attribute-list , attribute[opt] > attribute ... > attribute-list , attribute ... > we are actually parsing it as if the

Re: [C++ PATCH] Fix ICE on operator"" template (PR c++/77638)

OK. On Mon, Sep 19, 2016 at 5:54 PM, Jakub Jelinek wrote: > Hi! > > As the testcase shows for C++14 and up, for 1 argument template we don't ICE > even if the template argument is invalid, because it checks > if (TREE_TYPE (parm) != char_type_node > ||

Re: [C++ PATCH] Fix ICE with class fields with invalid types (PR c++/77626)

OK. On Mon, Sep 19, 2016 at 5:57 PM, Jakub Jelinek wrote: > Hi! > > layout_class_type for FIELD_DECLs with error_mark_node skips further > processing, so such fields don't have DECL_FIELD_OFFSET and > DECL_FIELD_BIT_OFFSET, thus byte_position ICEs on it. > > So, when we walk in

Re: Report DejaGnu ERROR messages in dg-extract-results

On 09/20/2016 03:26 AM, Christophe Lyon wrote: Hello, We recently faced a problem where a DejaGnu error went un-noticed (https://gcc.gnu.org/ml/gcc-patches/2016-08/msg01879.html). To help identify these problems earlier, here is a patch for dg-extract-results that makes such error obvious in

Re: [C++ PATCH] Fix C++ violation in g++.jason/init3.C (PR testsuite/63299)

On 09/19/2016 04:04 PM, Jakub Jelinek wrote: Hi! As valgrind reports, this testcase allocates the string with new [], but deallocates with delete str. Fixed thusly, regtested on x86_64-linux and i686-linux, ok for trunk? 2016-09-19 Maxim Ostapenko Jakub

Re: [BUILDROBOT] vax-netbsdelf / vax-linux: ‘ELIMINABLE_REGS’ was not declared in this scope

On 09/19/2016 04:24 PM, Bernd Edlinger wrote: On 09/19/16 23:51, Jeff Law wrote: On 09/17/2016 05:29 PM, Bernd Edlinger wrote: On 09/17/16 22:29, Jan-Benedict Glaw wrote: On Fri, 2016-09-09 21:40:38 +, Bernd Edlinger wrote: Hi, I think it is time to remove

Re: Report DejaGnu ERROR messages in compare_tests

On 09/20/2016 03:26 AM, Christophe Lyon wrote: Hello, We recently faced a problem where a DejaGnu error went un-noticed (https://gcc.gnu.org/ml/gcc-patches/2016-08/msg01879.html). To help identify these problems earlier, here is a patch for compare_tests that will report such cases as:

Re: [PATCH 0/8] make next_*_insn take rtx_insn * arguments

On 09/20/2016 04:38 AM, Bernd Schmidt wrote: On 09/20/2016 01:16 AM, Segher Boessenkool wrote: On Mon, Sep 19, 2016 at 06:07:46PM -0400, Trevor Saunders wrote: - JUMP_LABEL can be a return which is not an insn. That also seems like something that should be improved at some point. The

Re: [PATCHv3, resent] Add a warning for suspicious use of conditional expressions in boolean context

On Tue, Sep 20, 2016 at 10:11 AM, Bernd Edlinger wrote: > On 09/20/16 13:29, Kyrill Tkachov wrote: >> >> arm bootstrap is now failing: >> $SRC/gcc/config/arm/arm.h:2229:40: error: ?: using integer constants in >> boolean context [-Werror=int-in-bool-context] >> :

Re: [PATCH] Optimise the fpclassify builtin to perform integer operations when possible

On 09/20/2016 06:00 AM, Tamar Christina wrote: On 16/09/16 20:49, Jeff Law wrote: On 09/12/2016 10:19 AM, Tamar Christina wrote: Hi All, + + /* Re-interpret the float as an unsigned integer type + with equal precision. */ + int_arg_type = build_nonstandard_integer_type

Re: [PATCHv3, resent] Add a warning for suspicious use of conditional expressions in boolean context

On 09/20/16 16:20, Kyrill Tkachov wrote: > > On 20/09/16 15:11, Bernd Edlinger wrote: >> On 09/20/16 13:29, Kyrill Tkachov wrote: >>> arm bootstrap is now failing: >>> $SRC/gcc/config/arm/arm.h:2229:40: error: ?: using integer constants in >>> boolean context [-Werror=int-in-bool-context] >>>

Re: Implement -Wimplicit-fallthrough (version 8)

On Tue, Sep 20, 2016 at 04:24:35PM +0200, Marek Polacek wrote: > > (to skip over the koenig_p etc. cases) and fallthrough into the argument > > handling and add another if (function == NULL_TREE) handling after that, > > which would just build another internal call with the tsubsted arguments. >

Re: Register numbers in RTL dumps (was Re: [PATCH 0/9] RFC: selftests based on RTL dumps)

On 09/20/2016 04:32 PM, David Malcolm wrote: To summarize so far: you want every pseudo to have its regno dumped with a 'p' prefix, and renumber them on dump (and then on load). OK. Renumbering is not helpful because it interferes with the view you have in the debugger. So, IMO just a

Register numbers in RTL dumps (was Re: [PATCH 0/9] RFC: selftests based on RTL dumps)

On Mon, 2016-09-19 at 11:35 -0600, Jeff Law wrote: > On 09/16/2016 03:27 PM, David Malcolm wrote: > > > We should also twiddle how we represent registers in the dumps. > > > Identifying hard regs by name (so we can map back to a hard reg > > > if > > > the > > > hard regs change), identifying

Re: Implement -Wimplicit-fallthrough (version 8)

On Fri, Sep 09, 2016 at 06:44:44PM +0200, Jakub Jelinek wrote: > Hi! Finally getting back to this... > On Thu, Sep 01, 2016 at 03:40:49PM +0200, Marek Polacek wrote: > > @@ -1749,6 +1758,16 @@ c_parser_declaration_or_fndef (c_parser *parser, > > bool fndef_ok, > > { > >if

Re: PR35503 - warn for restrict pointer

On Tue, 20 Sep 2016, Martin Sebor wrote: > > That's much harder to support in format checking (which expects one length > > modifier, not a combination like that). > > I haven't looked into it detail but since the format checker supports > one-to-two character sequences of length modifiers (h or

Re: PR35503 - warn for restrict pointer

On 09/20/2016 07:00 AM, Joseph Myers wrote: On Tue, 20 Sep 2016, Martin Sebor wrote: That said, since this specifier formats a vec, it seems that it might be useful to be able to format vectors of other elements, such as short and long. With that in mind, would adding a new V length modifier

Re: [PATCHv3, resent] Add a warning for suspicious use of conditional expressions in boolean context

On 20/09/16 15:11, Bernd Edlinger wrote: On 09/20/16 13:29, Kyrill Tkachov wrote: arm bootstrap is now failing: $SRC/gcc/config/arm/arm.h:2229:40: error: ?: using integer constants in boolean context [-Werror=int-in-bool-context] : (TARGET_VFP_DOUBLE ? (TARGET_FP16 ? 14 : 12) : 0)) \

Re: [PATCH][ARM][v2] Use snprintf rather than sprintf

On 08/09/16 12:00, Kyrill Tkachov wrote: > Hi all, > > This is a rebase and slight respin of [1] that I sent out last November > to change all uses of > sprintf to snprintf in the arm backend. > > Bootstrapped and tested on arm-none-linux-gnueabihf. > Ok for trunk? > > Thanks, > Kyrill > > [1]

Re: [PATCHv3, resent] Add a warning for suspicious use of conditional expressions in boolean context

On 09/20/16 13:29, Kyrill Tkachov wrote: > > arm bootstrap is now failing: > $SRC/gcc/config/arm/arm.h:2229:40: error: ?: using integer constants in > boolean context [-Werror=int-in-bool-context] > : (TARGET_VFP_DOUBLE ? (TARGET_FP16 ? 14 : 12) : 0)) \ >

Re: [v3 PATCH] PR libstdc++/77619

On 18/09/16 21:07 +0300, Ville Voutilainen wrote: diff --git a/libstdc++-v3/include/bits/stl_construct.h b/libstdc++-v3/include/bits/stl_construct.h index 3d12628..c7ca1f8 100644 --- a/libstdc++-v3/include/bits/stl_construct.h +++ b/libstdc++-v3/include/bits/stl_construct.h @@ -83,6 +83,10 @@

Re: PR77661 - Fix: --enable-maintainer-mode causes in-tree-build of MPC to fail

On Tue, Sep 20, 2016 at 3:21 PM, Tobias Burnus wrote: > Currently, --enable-maintainer-mode causes an in-tree build MPC to fail (cf. > PR). > The attached patch fixes this for --enable-maintainer-mode. > > OK for the trunk? Ok if nobody objects within 48

PR77661 - Fix: --enable-maintainer-mode causes in-tree-build of MPC to fail

Currently, --enable-maintainer-mode causes an in-tree build MPC to fail (cf. PR). The attached patch fixes this for --enable-maintainer-mode. OK for the trunk? Cheers, Tobias PS: Thanks to Richard for the suggestion. PR boot/77661 * Makefile.def: Don't pass --enable-maintainer-mode on to an

Re: [GCC][PATCH] Add __artificial__ attribute to Aarch64 NEON intrinsics

On Tue, Sep 20, 2016 at 10:09:14AM +0100, James Greenhalgh wrote: > On Tue, Sep 13, 2016 at 01:15:39PM +0100, Tamar Christina wrote: >> > Thanks, I applied this following your script above, and committed it as > revision 240256, after tweaking one part of the script to replace a double > space

[PATCH][simple-object] Early LTO debug "debug copier"

This implements (for ELF sofar) the Early LTO debug information copier. To remind people what this is about with Early LTO Debug the compile-stage emits the DWARF DIEs as they are at dwarf2out_early_finish into the object files that also contain the LTO IL. On ELF they end up in sections

Re: [PATCH] manual: _Bool has trap representations

On Tue, 20 Sep 2016, Florian Weimer wrote: > On 09/19/2016 11:26 PM, Joseph Myers wrote: > > On powerpc-darwin _Bool is 4-byte not 1-byte, so saying values are > > represented as bytes isn't accurate for all systems supported by GCC. > > Interesting. > > Is the treatment of 0/1/the rest still

Re: PR35503 - warn for restrict pointer

On Tue, 20 Sep 2016, Prathamesh Kulkarni wrote: > Could someone please take a look at the change to c-format.c, I am not sure > if I have added that correctly. Any changes to these GCC formats also require tests to be updated (gcc.dg/format/gcc_diag*). -- Joseph S. Myers

Re: PR35503 - warn for restrict pointer

On Tue, 20 Sep 2016, Martin Sebor wrote: > That said, since this specifier formats a vec, it seems that > it might be useful to be able to format vectors of other elements, > such as short and long. With that in mind, would adding a new V > length modifier instead be a more regular way to extend

Re: Re: [PATCH, 5.x/6.x/7.x] Be more conservative in early inliner if FDO is enabled

> >> > Btw, It occurs to me that then win in code-size might be purely due to > >> > the > >> > smaller base value for the TU size we use to compute the maximum unit > >> > growth with ... any idea how to improve it on this side? Say, computing > >> > the TU size before early optimization (uh,

Re: [accaf, fortran, 4/4] Allocatable components support in derived typed coarrays

Hi Andreas, thanks for the report. I better use + there instead of the fixed number of digits. Fixed as obvious as r240262. Thanks again. - Andre On Tue, 20 Sep 2016 14:18:46 +0200 Andreas Schwab wrote: > On Sep 19 2016, Andre Vehreschild wrote: > > > Index:

Re: [PATCH 3/3] S/390: Improved risbg usage.

On Tue, Sep 20, 2016 at 01:37:18PM +0100, Dominik Vogt wrote: > The following series of patches improves usage of the risbg and > risbgn instructions on s390/s390x. The patches have been > regression tested on s390 and s390x and pass the Spec2006 > testsuite without any negative effects. > Patch

Re: [PATCH 2/3] S/390: Enable wraparound in s390_contiguous_bitmask_p.

On Tue, Sep 20, 2016 at 01:37:18PM +0100, Dominik Vogt wrote: > The following series of patches improves usage of the risbg and > risbgn instructions on s390/s390x. The patches have been > regression tested on s390 and s390x and pass the Spec2006 > testsuite without any negative effects. > Patch

Re: [PATCH 1/3] S/390: Mode attrs "bitoff[_plus]" simplify risbg instructions.

On Tue, Sep 20, 2016 at 01:37:18PM +0100, Dominik Vogt wrote: > The following series of patches improves usage of the risbg and > risbgn instructions on s390/s390x. The patches have been > regression tested on s390 and s390x and pass the Spec2006 > testsuite without any negative effects. >

[PATCH 0/3] S/390: Improved risbg usage.

The following series of patches improves usage of the risbg and risbgn instructions on s390/s390x. The patches have been regression tested on s390 and s390x and pass the Spec2006 testsuite without any negative effects. Patch 1 introduces a new mode attribute to simplify some instruction

Re: [PATCH] Tree-level fix for PR 69526

Hi, > I meant to do sth like > > Index: tree-ssa-propagate.c > === > --- tree-ssa-propagate.c(revision 240133) > +++ tree-ssa-propagate.c(working copy) > @@ -1105,10 +1105,10 @@

Re: [PATCH] Handle VECTOR_CST in integer_nonzerop()

On Mon, 19 Sep 2016, Patrick Palka wrote: On Wed, Sep 14, 2016 at 1:58 AM, Marc Glisse wrote: On Fri, 19 Aug 2016, Patrick Palka wrote: On Fri, Aug 19, 2016 at 7:30 PM, Patrick Palka wrote: integer_nonzerop() currently unconditionally returns

Re: [accaf, fortran, 4/4] Allocatable components support in derived typed coarrays

On Sep 19 2016, Andre Vehreschild wrote: > Index: gcc/testsuite/gfortran.dg/coarray_allocate_7.f08 > === > --- gcc/testsuite/gfortran.dg/coarray_allocate_7.f08 (nicht existent) > +++

[PATCH] Fix PR77646

This fixes the PR. Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk. Richard. 2016-09-20 Richard Biener PR tree-optimization/77646 * tree-ssa-sccvn.c (visit_reference_op_call): Always value-number a VDEF. *

Re: [PATCH, 5.x/6.x/7.x] Be more conservative in early inliner if FDO is enabled

On Tue, Sep 20, 2016 at 1:57 PM, Yuan, Pengfei wrote: >> > Btw, It occurs to me that then win in code-size might be purely due to the >> > smaller base value for the TU size we use to compute the maximum unit >> > growth with ... any idea how to improve it on this side? Say,

Re: PR35503 - warn for restrict pointer

On 20 September 2016 at 08:57, Martin Sebor wrote: >> and used >> pp_format for formatting arg_positions by adding specifier %I (name >> chosen arbitrarily). >> Does that look OK ? > > > diff --git a/gcc/pretty-print.c b/gcc/pretty-print.c > index a39815e..e8bd1ef 100644 > ---

Re: [PATCH] Optimise the fpclassify builtin to perform integer operations when possible

On 16/09/16 20:49, Jeff Law wrote: On 09/12/2016 10:19 AM, Tamar Christina wrote: Hi All, + + /* Re-interpret the float as an unsigned integer type + with equal precision. */ + int_arg_type = build_nonstandard_integer_type (TYPE_PRECISION (type), 0); + int_arg =

Re: [PATCH, 5.x/6.x/7.x] Be more conservative in early inliner if FDO is enabled

> > Btw, It occurs to me that then win in code-size might be purely due to the > > smaller base value for the TU size we use to compute the maximum unit > > growth with ... any idea how to improve it on this side? Say, computing > > the TU size before early optimization (uh, probably not ...) > >

Re: [PR72835] Incorrect arithmetic optimization involving bitfield arguments

On Tue, Sep 20, 2016 at 1:32 AM, kugan wrote: > Hi Richard, > Thanks for the review. > > > On 19/09/16 23:40, Richard Biener wrote: >> >> On Sun, Sep 18, 2016 at 10:21 PM, kugan >> wrote: >>> >>> Hi Richard, >>> >>> >>> On

Re: [PATCH, 5.x/6.x/7.x] Be more conservative in early inliner if FDO is enabled

On Tue, Sep 20, 2016 at 1:31 PM, Richard Biener wrote: > On Fri, Sep 16, 2016 at 2:00 PM, Jan Hubicka wrote: >>> > > I also like a new param better as it avoids a new magic constant and >>> > > makes playing with >>> > > it easier (your patch removes

  1   2   >