RFA: Small PATCH to add pow2p_hwi to hwint.h

Various places in GCC use negate, bit-and and compare to test whether an integer is a power of 2, but I think it would be clearer for this test to be wrapped in a function. OK for trunk? commit e2ca9914ce46d56775854f50c21506b220fd50b6 Author: Jason Merrill Date: Wed Sep 7

Re: [RFC][SSA] Iterator to visit SSA

Hi Richard, On 7 September 2016 at 19:35, Richard Biener wrote: > On Wed, Sep 7, 2016 at 2:21 AM, Kugan Vivekanandarajah > wrote: >> Hi Richard, >> >> On 6 September 2016 at 19:08, Richard Biener >>

Re: [PATCH GCC 9/9]Prove no-overflow in computation of LOOP_VINFO_NITERS and improve code generation

Hi Bin, On 07/09/16 17:52, Bin.Cheng wrote: On Wed, Sep 7, 2016 at 1:10 AM, kugan wrote: Hi Bin, On 07/09/16 04:54, Bin Cheng wrote: Hi, LOOP_VINFO_NITERS is computed as LOOP_VINFO_NITERSM1 + 1, which could overflow in loop niters' type. Vectorizer

Re: Make max_align_t respect _Float128 [version 2]

On 09/07/2016 04:52 AM, Mark Wielaard wrote: If valgrind believes the memory isn't in valid memory then it will complain about an invalid access. But if the memory is accessible but uninitialised then it will just track the undefinedness complain later if such a value is used. I think the

Re: [Patch libgcc] Enable HCmode multiply and divide (mulhc3/divhc3)

On 09/07/2016 06:05 PM, James Greenhalgh wrote: Hi, This patch arranges for half-precision complex multiply and divide routines to be built if __LIBGCC_HAS_HF_MODE__. This will be true if the target supports the _Float16 type. OK? Ok, but please see Joseph's patch from today: I think you

Re: Correct libgcc complex multiply excess precision handling

On 09/07/2016 11:48 PM, Joseph Myers wrote: libgcc complex multiply is meant to eliminate excess precision from certain internal values by forcing them to memory in exactly those cases where the type has excess precision. But in https://gcc.gnu.org/ml/gcc-patches/2014-09/msg01894.html I

Correct libgcc complex multiply excess precision handling

libgcc complex multiply is meant to eliminate excess precision from certain internal values by forcing them to memory in exactly those cases where the type has excess precision. But in https://gcc.gnu.org/ml/gcc-patches/2014-09/msg01894.html I accidentally inverted the logic so that values get

Re: Make max_align_t respect _Float128 [version 2]

On Wed, 7 Sep 2016, Bernd Edlinger wrote: > Apparently the different -msse default setting made the situation worse. > I think that will not run on a pentium4 any more. I think that's x86_64-* defaulting to an x86_64 processor (which implies SSE2 support) even with -m32 (unless a

Re: [Fortran, Patch] First patch for coarray FAILED IMAGES (TS 18508)

Dear all, the attached patch supports failed images also when -fcoarray=single is used. Built and regtested on x86_64-pc-linux-gnu. Cheers, Alessandro 2016-08-09 5:22 GMT-06:00 Paul Richard Thomas : > Hi Sandro, > > As far as I can see, this is OK barring a couple

Re: [Patch RFC] Modify excess precision logic to permit FLT_EVAL_METHOD=16

On Wed, 7 Sep 2016, Joseph Myers wrote: > How about instead having more than one target macro / hook. One would > indicate that excess precision is used by insn patterns (and be set only > for i386 and m68k). Another would indicate the API-level excess precision Or, maybe there would be a

Re: Make max_align_t respect _Float128 [version 2]

On 09/07/16 22:04, Joseph Myers wrote: > On Wed, 7 Sep 2016, Bernd Edlinger wrote: > >> interesting. I just tried the test case from PR 77330 with _Decimal128. >> result: _Decimal128 did *not* trap with gcc4.8.4, but it does trap with >> gcc-7.0.0. > > I checked with GCC 4.3; __alignof__

Re: [PATCH][v3] GIMPLE store merging pass

On Wed, Sep 07, 2016 at 10:19:11AM +0200, Richard Biener wrote: > > If you want a 64-bit store, you'd need to merge the two, and that would be > > even more expensive. It is a matter of say: > > movl $0x12345678, (%rsp) > > movl $0x09abcdef, 4(%rsp) > > vs. > > movabsq

Re: [PATCH][v3] GIMPLE store merging pass

On September 6, 2016 5:14:47 PM GMT+02:00, Kyrill Tkachov wrote: >Hi all, s/contigous/contiguous/ s/ where where/ where/ +struct merged_store_group +{ + HOST_WIDE_INT start; + HOST_WIDE_INT width; + unsigned char *val; + unsigned int align; + auto_vec stores;

Re: [PATCH] -fsanitize=thread fixes (PR sanitizer/68260)

On Wed, Sep 07, 2016 at 09:07:45AM +0200, Richard Biener wrote: > > @@ -493,6 +504,8 @@ instrument_builtin_call (gimple_stmt_ite > > if (!tree_fits_uhwi_p (last_arg) > > || memmodel_base (tree_to_uhwi (last_arg)) >= MEMMODEL_LAST) > > return; > > + if

Re: [PATCH] Fix location of command line backend reported issues (PR middle-end/77475)

On 6 September 2016 at 12:41, Christophe Lyon wrote: > On 6 September 2016 at 12:12, Jakub Jelinek wrote: >> On Tue, Sep 06, 2016 at 12:07:47PM +0200, Christophe Lyon wrote: >>> On 5 September 2016 at 19:20, Jakub Jelinek wrote:

Re: Ping**2! Re: [PATCH, Fortran] Extension: AUTOMATIC/STATIC symbol attributes with -fdec-static

On Wed, Sep 7, 2016 at 9:31 AM, Andre Vehreschild wrote: > Hi Fritz, > > please note: I do not have official review privileges. So my vote here > is rather an advise to you and the official reviewers. Often such a > inofficial review helps to speed things up, because the official

[ARM] PR 67591 ARM v8 Thumb IT blocks are deprecated

Hi, The attached patch is a first part to solve PR 67591: it removes several occurrences of "IT blocks containing 32-bit Thumb instructions are deprecated in ARMv8" messages in the gcc/g++/libstdc++/fortran testsuites. It does not remove them all yet. This patch only modifies the *cmp_and,

Re: Make max_align_t respect _Float128 [version 2]

On Wed, 7 Sep 2016, Bernd Edlinger wrote: > interesting. I just tried the test case from PR 77330 with _Decimal128. > result: _Decimal128 did *not* trap with gcc4.8.4, but it does trap with > gcc-7.0.0. I checked with GCC 4.3; __alignof__ (_Decimal128) was 16 back then. Whether particular

Re: [PATCH][AArch64] Improve legitimize_address

Hi Wilco, On 7 September 2016 at 14:43, Richard Earnshaw (lists) wrote: > On 06/09/16 14:14, Wilco Dijkstra wrote: >> Improve aarch64_legitimize_address - avoid splitting the offset if it is >> supported. When we do split, take the mode size into account. BLKmode >>

Re: Make max_align_t respect _Float128 [version 2]

On Wed, 7 Sep 2016, Joseph Myers wrote: > On Wed, 7 Sep 2016, Florian Weimer wrote: > > > The existence of such a cut-off constant appears useful, but it's not clear if > > it should be tied to the fundamental alignment (especially, as this discussion > > shows, the fundamental alignment

Re: [Patch RFC] Modify excess precision logic to permit FLT_EVAL_METHOD=16

On Tue, 6 Sep 2016, James Greenhalgh wrote: > In c-family/c-cppbuiltin.c I've updated cpp_iec_559_value such that also > allow setting __GEC_IEC_559 if FLT_EVAL_METHOD=16, and I've updated > c_cpp_builtins to handle the new value, and use the new enum names. I think the special cases in this

Re: [Patch libgcc] Enable HCmode multiply and divide (mulhc3/divhc3)

On Wed, 7 Sep 2016, James Greenhalgh wrote: > 2016-09-07 James Greenhalgh > I'd think this should say PR target/63250 as being part of fixing that bug (although not a fix by itself). -- Joseph S. Myers jos...@codesourcery.com

Re: [PATCH 3/4][Ada,DJGPP] Ada support for DJGPP

On 09/05/2016 09:42 AM, Eric Botcazou wrote: Attached output is from last test build (r239639 with DJGPP related patches applied, last version of patches for Ada). Very strange error, line 28 of gtype-ada.h is supposed to have a guard for nodes containing the 'common' structure. Can you post

Re: Make max_align_t respect _Float128 [version 2]

On Wed, 7 Sep 2016, Florian Weimer wrote: > The existence of such a cut-off constant appears useful, but it's not clear if > it should be tied to the fundamental alignment (especially, as this discussion > shows, the fundamental alignment will be somewhat in flux). I don't think it's in flux. I

[PATCH] [PR libcpp/71681] Fix handling header.gcc in subdirectories

This patch fixes handling header.gcc in subdirectories when command line option -remap has been used. Current version finds header.gcc in directories from GCC include directory search path but fails to find them in subdirectories due to missing directory separator. Andris 2016-09-07 Andris

[committed] Move class substring_loc from c-family into gcc

On Sat, 2016-09-03 at 10:13 +0100, Manuel López-Ibáñez wrote: > On 02/09/16 23:55, Martin Sebor wrote: > > > diff --git a/gcc/substring-locations.h b/gcc/substring > > > -locations.h > > > index f839c74..bb0de4f 100644 > > > --- a/gcc/substring-locations.h > > > +++ b/gcc/substring-locations.h > >

[Patch libgcc] Enable HCmode multiply and divide (mulhc3/divhc3)

Hi, This patch arranges for half-precision complex multiply and divide routines to be built if __LIBGCC_HAS_HF_MODE__. This will be true if the target supports the _Float16 type. OK? Thanks, James --- libgcc/ 2016-09-07 James Greenhalgh * Makefile.in

Re: [PATCH] Detect whether target can use -fprofile-update=atomic

On 7 September 2016 at 11:34, Martin Liška wrote: > On 09/07/2016 09:45 AM, Christophe Lyon wrote: >> On 6 September 2016 at 15:45, Martin Liška wrote: >>> On 09/06/2016 03:31 PM, Jakub Jelinek wrote: sizeof (gcov_type) talks about the host gcov type, you

Re: [PING] Re: [PATCH, i386] Fix some warnings/errors that appear when enabling -Wnarrowing when building gcc

On Tue, Sep 6, 2016 at 8:06 PM, Eric Gallager wrote: > On 9/6/16, Uros Bizjak wrote: >> On Tue, Sep 6, 2016 at 5:33 PM, Eric Gallager wrote: >>> Ping? CC-ing an i386 maintainer since the patch mostly touches >>> i386-specific files.

Re: [x86] Disable STV pass if -mstackrealign is enabled.

On Wed, Aug 31, 2016 at 12:29 PM, Uros Bizjak wrote: >> the new STV pass generates SSE instructions in 32-bit mode very late in the >> pipeline and doesn't bother about realigning the stack, so it wreaks havoc on >> OSes where you need to realign the stack, e.g. Windows, but I

PING: Re: [PATCH, LRA] Fix PR rtl-optimization 77289, LRA matching constraint problem

Ping this patch: https://gcc.gnu.org/ml/gcc-patches/2016-08/msg02099.html Peter

Re: Ping**2! Re: [PATCH, Fortran] Extension: AUTOMATIC/STATIC symbol attributes with -fdec-static

Hi Fritz, please note: I do not have official review privileges. So my vote here is rather an advise to you and the official reviewers. Often such a inofficial review helps to speed things up, because the official ones are pointed to the nics and nacs and don't have to bother with the minor

Re: [PATCH][v3] GIMPLE store merging pass

On 09/07/2016 10:19 AM, Richard Biener wrote: On Tue, 6 Sep 2016, Jakub Jelinek wrote: If you want a 64-bit store, you'd need to merge the two, and that would be even more expensive. It is a matter of say: movl $0x12345678, (%rsp) movl $0x09abcdef, 4(%rsp) vs.

[PATCH][expmed.c] PR middle-end/77426 Delete duplicate condition in synth_mult

Hi all, The duplicate mode check in synth can just be deleted IMO. It was introduced as part of r139821 that was a much larger change introducing size/speed differentiation to the RTL midend. So I think it's just a typo/copy-pasto. Tested on aarch64-none-elf. Ok? Thanks, Kyrill 2016-09-07

Re: [PATCH][AArch64] Improve legitimize_address

On 06/09/16 14:14, Wilco Dijkstra wrote: > Improve aarch64_legitimize_address - avoid splitting the offset if it is > supported. When we do split, take the mode size into account. BLKmode > falls into the unaligned case but should be treated like LDP/STP. > This improves codesize slightly due to

Re: [PATCH GCC 8/9]Adjust test case for CFG changes in vectorized loop

On 09/06/2016 12:53 PM, Bin Cheng wrote: Hi, After CFG changes in vectorizer, the epilog loop now can be completely peeled, resulting in changes in the number of instructions that these tests check. This patch adjusts related checking strings. Thanks, bin gcc/testsuite/ChangeLog 2016-09-01

Re: [PATCH][v3] GIMPLE store merging pass

On 09/07/2016 02:19 AM, Richard Biener wrote: On Tue, 6 Sep 2016, Jakub Jelinek wrote: On Tue, Sep 06, 2016 at 04:59:23PM +0100, Kyrill Tkachov wrote: On 06/09/16 16:32, Jakub Jelinek wrote: On Tue, Sep 06, 2016 at 04:14:47PM +0100, Kyrill Tkachov wrote: The v3 of this patch addresses

Re: [PATCH GCC 7/9]Skip loops iterating only 1 time in predictive commoning

On 09/06/2016 12:53 PM, Bin Cheng wrote: Hi, For loops which are bounded to iterate only 1 time (thus loop's latch doesn't roll), there is nothing to predictive common, this patch detects/skips these cases. A test is also added in gcc/testsuite/gfortran.dg/vect/fast-math-mgrid-resid.f for

Re: [PATCH GCC 3/9]Support rewriting non-lcssa phis for vars live outside of vect-loop

On 09/06/2016 12:51 PM, Bin Cheng wrote: Hi, Current implementation requires that variables live outside of vect-loop satisfying LCSSA form, this patch relaxes the restriction. It keeps the old behavior for LCSSA PHI node by replacing use of live var with result of that PHI; for other uses

Re: [PATCH GCC 5/9]Put copied loop after its preheader and after the original loop's latch in basic block link list

On 09/06/2016 12:52 PM, Bin Cheng wrote: Hi, This simple patch changes slpeel_tree_duplicate_loop_edge_cfg by putting copied loop after its new preheader and after the original loop's latch in basic block's linked list. It doesn't change CFG at all, but makes the dump cfg a little bit easier

Re: [PATCH GCC 4/9]Check niters for peeling for data access gaps in analyzer

On 09/06/2016 12:51 PM, Bin Cheng wrote: Hi, This patch checks if loop has enough niters for peeling for data access gaps in vect_analyze_loop_2, while now this check is in vect_transform_loop stage. The problem is vectorizer may vectorize loops without enough iterations and generate false

Re: Advice sought for debugging a lto1 ICE (was: Implement C _FloatN, _FloatNx types [version 6])

On Wed, Sep 7, 2016 at 1:52 PM, Thomas Schwinge wrote: > Hi! > > I trimmed the CC list -- I'm looking for advice about debugging a lto1 > ICE. > > On Fri, 19 Aug 2016 11:05:59 +, Joseph Myers > wrote: >> On Fri, 19 Aug 2016, Richard Biener

Re: [PATCH GCC 2/9]Add interface reseting original copy tables in cfg.c

On 09/06/2016 12:50 PM, Bin Cheng wrote: Hi, This simple patch adds interface reseting original copy table in cfg.c. This will be used in rewriting vect_do_peeling_* functions in vectorizer so that we don't need to release/allocate tables between prolog and epilog peeling. Thanks, bin

Re: [PATCH GCC 1/9]Delete useless code in tree-vect-loop-manip.c

On 09/06/2016 12:49 PM, Bin Cheng wrote: Hi, This is a patch set generating new control flow graph for vectorized loop and its peeling loops. At the moment, CFG for vecorized loop is complicated and sub-optimal. Major issues are like: A) For both prologue and vectorized loop, it generates

Advice sought for debugging a lto1 ICE (was: Implement C _FloatN, _FloatNx types [version 6])

Hi! I trimmed the CC list -- I'm looking for advice about debugging a lto1 ICE. On Fri, 19 Aug 2016 11:05:59 +, Joseph Myers wrote: > On Fri, 19 Aug 2016, Richard Biener wrote: > > Can you quickly verify if LTO works with the new types? I don't see > > anything >

Re: Make max_align_t respect _Float128 [version 2]

On Wed, Sep 07, 2016 at 11:15:34AM +0200, Florian Weimer wrote: > On 09/06/2016 11:31 PM, Paul Eggert wrote: > >On 09/06/2016 01:40 PM, Joseph Myers wrote: > >>Sounds like a defect in C11 to me - none of the examples of flexible > >>array > >>members anticipate needing to add to the size to allow

Re: [PATCH] Delete GCJ

On 06/09/16 22:17, Jeff Law wrote: > On 09/06/2016 03:08 AM, Jakub Jelinek wrote: >> On Tue, Sep 06, 2016 at 11:06:36AM +0200, Richard Biener wrote: >>> On Mon, Sep 5, 2016 at 6:17 PM, Andrew Haley wrote: On 05/09/16 17:15, Richard Biener wrote: > On September 5, 2016

Re: [PATCH] Set -fprofile-update=atomic when -pthread is present

On 08/18/2016 06:06 PM, Richard Biener wrote: > On August 18, 2016 5:54:49 PM GMT+02:00, Jakub Jelinek > wrote: >> On Thu, Aug 18, 2016 at 08:51:31AM -0700, Andi Kleen wrote: I'd prefer to make updates atomic in multi-threaded applications. The best proxy we have for

Re: [RFC][SSA] Iterator to visit SSA

On Wed, Sep 7, 2016 at 2:21 AM, Kugan Vivekanandarajah wrote: > Hi Richard, > > On 6 September 2016 at 19:08, Richard Biener > wrote: >> On Tue, Sep 6, 2016 at 2:24 AM, Kugan Vivekanandarajah >>

Re: [PATCH] Detect whether target can use -fprofile-update=atomic

On 09/07/2016 09:45 AM, Christophe Lyon wrote: > On 6 September 2016 at 15:45, Martin Liška wrote: >> On 09/06/2016 03:31 PM, Jakub Jelinek wrote: >>> sizeof (gcov_type) talks about the host gcov type, you want instead the >>> target gcov type. So >>> TYPE_SIZE (gcov_type_node)

Re: [PATCH, PING] DWARF: process all TYPE_DECL nodes when iterating on scopes

On Tue, Sep 6, 2016 at 10:43 AM, Pierre-Marie de Rodat wrote: > Hello, > > On 08/29/2016 11:03 AM, Pierre-Marie de Rodat wrote: >> >> Here is another attempt to solve the original issue. This time, with a >> proper testcase. ;-) >> >> Rebased against trunk, boostrapped and

Re: [PATCH, c++, PR77427 ] Set TYPE_STRUCTURAL_EQUALITY for sysv_abi va_list

On Mon, Sep 5, 2016 at 6:11 PM, Tom de Vries wrote: > On 05/09/16 09:49, Richard Biener wrote: >> >> On Sun, Sep 4, 2016 at 11:30 PM, Tom de Vries >> wrote: >>> >>> > On 04/09/16 16:08, Richard Biener wrote: >> >> On September 4,

Re: Make max_align_t respect _Float128 [version 2]

On 09/06/2016 11:31 PM, Paul Eggert wrote: On 09/06/2016 01:40 PM, Joseph Myers wrote: Sounds like a defect in C11 to me - none of the examples of flexible array members anticipate needing to add to the size to allow for tail padding with unknown alignment requirements. Yes, I would prefer

Re: Make max_align_t respect _Float128 [version 2]

On 09/06/2016 10:40 PM, Joseph Myers wrote: On Tue, 6 Sep 2016, Paul Eggert wrote: One way to correct the code is to increase malloc's argument up to a multiple of alignof(max_align_t). (One cannot portably use alignof(struct s) due to Sounds like a defect in C11 to me - none of the examples

Re: [PATCH][v3] GIMPLE store merging pass

On Tue, 6 Sep 2016, Jakub Jelinek wrote: > On Tue, Sep 06, 2016 at 04:59:23PM +0100, Kyrill Tkachov wrote: > > On 06/09/16 16:32, Jakub Jelinek wrote: > > >On Tue, Sep 06, 2016 at 04:14:47PM +0100, Kyrill Tkachov wrote: > > >>The v3 of this patch addresses feedback I received on the version

Re: [PATCH] Fix PR77450

On Wed, 7 Sep 2016, Yvan Roux wrote: > Hi Richard, > > On 6 September 2016 at 14:41, Richard Biener wrote: > > > > The following fixes PR77450. > > > > Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk. > > > > Richard. > > > > 2016-09-06 Richard Biener

Re: [RFC][SSA] Iterator to visit SSA

I am not sure about the process, but it may also be nice/useful to add your new macro to ForEachMacros in contrib/clang-format. Dominik > On 07 Sep 2016, at 02:21, Kugan Vivekanandarajah > wrote: > > Hi Richard, > > On 6 September 2016 at 19:08, Richard

Re: [PATCH GCC 9/9]Prove no-overflow in computation of LOOP_VINFO_NITERS and improve code generation

On Wed, Sep 7, 2016 at 1:10 AM, kugan wrote: > Hi Bin, > > > On 07/09/16 04:54, Bin Cheng wrote: >> >> Hi, >> LOOP_VINFO_NITERS is computed as LOOP_VINFO_NITERSM1 + 1, which could >> overflow in loop niters' type. Vectorizer needs to generate more code >>

Re: [PATCH] Detect whether target can use -fprofile-update=atomic

On 6 September 2016 at 15:45, Martin Liška wrote: > On 09/06/2016 03:31 PM, Jakub Jelinek wrote: >> sizeof (gcov_type) talks about the host gcov type, you want instead the >> target gcov type. So >> TYPE_SIZE (gcov_type_node) == 32 vs. 64 (or TYPE_SIZE_UNIT (gcov_type_node) >> ==

Re: Make max_align_t respect _Float128 [version 2]

On 09/06/2016 11:23 AM, Richard Biener wrote: The question then is, how can we make max_align_t more useful? If it is supposed to reflect a malloc property, it cannot be a compile-time constant because we don't know at compile time which malloc is going to be used (malloc has to remain

Re: [PATCH][RFC] Early LTO debug

On Tue, 6 Sep 2016, Markus Trippelsdorf wrote: > On 2016.09.06 at 14:26 +0200, Richard Biener wrote: > > On Tue, 6 Sep 2016, Markus Trippelsdorf wrote: > > > > > On 2016.09.06 at 13:17 +0200, Richard Biener wrote: > > > > > > > > The following is an updated patch, mainly stripped out old

Re: [PATCH] -fsanitize=thread fixes (PR sanitizer/68260)

On Tue, 6 Sep 2016, Jakub Jelinek wrote: > Hi! > > As the PRs show, -fsanitize=thread hasn't been instrumenting __atomic_clear > and __atomic_test_and_set builtins (i.e. those that operate on bool always), > so we reported a data race on the testcase even when there wasn't one. > And, as the

Re: [PATCH] Fix PR77450

Hi Richard, On 6 September 2016 at 14:41, Richard Biener wrote: > > The following fixes PR77450. > > Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk. > > Richard. > > 2016-09-06 Richard Biener > > PR c/77450 >