Re: [PATCH, i386] Spellcheck hints for the i386 backend option handling (PR middle-end/77475)

On Mon, Sep 05, 2016 at 07:54:15PM -0400, David Malcolm wrote: > The calls into spellcheck.h are minimal and look reasonable (I can't > really comment on the x86 aspects). So I have little to add beyond the > cleanups that Manu already observed. > > One thing: shouldn't this have testcases that g

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

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 regtested on x86_64-linux. Ping for the patch submitted at

Re: Ping for a gfortran testsuite patch

Dear Uros, Yes, that's fine. OK for trunk, 6- and 5-branches. Thanks Paul On 5 September 2016 at 22:42, Uros Bizjak wrote: > Hello Paul! > > I would like to point out my testsuite patch [1] to one of gfortran > testsuite file, authored by you. The patch corrects fortran call to a > prototyped

Re: Implement C _FloatN, _FloatNx types [version 6]

On Mon, Sep 5, 2016 at 1:40 PM, Joseph Myers wrote: > On Sat, 3 Sep 2016, Andreas Schwab wrote: > >> On Aug 17 2016, Joseph Myers wrote: >> >> > Index: gcc/testsuite/gcc.dg/torture/float32-basic.c >> > === >> > --- gcc/testsuite/gcc.

Re: Make max_align_t respect _Float128 [version 2]

On Mon, Sep 5, 2016 at 7:06 PM, Joseph Myers wrote: > [Patch version 2 adds an update to cxx_fundamental_alignment_p.] > > The _FloatN, _FloatNx, _DecimalN and _DecimalNx types are specified in > such a way that they are basic types, meaning that max_align_t must be > at least as aligned as those

Re: [PATCH] Delete GCJ

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 5:13:06 PM GMT+02:00, Andrew Haley >> wrote: >>> As discussed. I think I should ask a Global reviewer to approve this >>> one. For obvious reasons I haven't included the diffs

Re: C/C++ PATCH for c/77423 (bogus warning with -Wlogical-not-parentheses)

On Mon, Sep 05, 2016 at 10:35:26AM -0600, Sandra Loosemore wrote: > On 09/05/2016 09:55 AM, Bernd Schmidt wrote: > > > > > > On 09/05/2016 12:52 PM, Marek Polacek wrote: > > > On Mon, Sep 05, 2016 at 12:35:13PM +0200, Bernd Schmidt wrote: > > > > On 09/02/2016 05:13 PM, Marek Polacek wrote: > > >

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

On Tue, Sep 6, 2016 at 2:24 AM, Kugan Vivekanandarajah wrote: > Hi Richard, > > On 5 September 2016 at 17:57, Richard Biener > wrote: >> On Mon, Sep 5, 2016 at 7:26 AM, Kugan Vivekanandarajah >> wrote: >>> Hi All, >>> >>> While looking at gcc source, I noticed that we are iterating over SSA >>>

Re: [PATCH] Delete GCJ

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 5:13:06 PM GMT+02:00, Andrew Haley > >> wrote: > >>> As discussed. I think I should ask a Global reviewer

Re: [PATCH 3/4][PR 71931] Fix libitm tests

On Wed, 2016-08-24 at 20:08 +0100, Szabolcs Nagy wrote: > Pass build time CC make var down to dejagnu so the sysroot > is set correctly when gcc is built with --with-build-sysroot. > > libitm/ > 2016-08-24 Szabolcs Nagy > > PR testsuite/71931 > * configure.ac: Add AC_CONFIG_FILES.

Re: Make max_align_t respect _Float128 [version 2]

On 09/05/2016 07:06 PM, Joseph Myers wrote: Such an increase is of course an ABI change, but a reasonably safe one, in that max_align_t doesn't tend to appear in library interfaces (rather, it's something to use when writing allocators and similar code; most matches found on codesearch.debian.ne

[DOC] Boolean -> boolean changes

As discussed , this patch makes the Boolean -> boolean change in our doc/ directory. Ok for trunk? 2016-09-06 Marek Polacek * doc/extend.texi: Use lowercase "boolean". * doc/invoke.texi: Likewise. * doc/md.texi:

[Patch AArch64] Add floatdihf2 and floatunsdihf2 patterns

Hi, This patch adds patterns for conversion from 64-bit integer to 16-bit floating-point values under AArch64 targets which don't have support for the ARMv8.2-A 16-bit floating point extensions. We implement these by first saturating to a SImode (we know that any values >= 65504 will round to in

Re: Make max_align_t respect _Float128 [version 2]

On Tue, Sep 6, 2016 at 11:11 AM, Florian Weimer wrote: > On 09/05/2016 07:06 PM, Joseph Myers wrote: > >> Such an increase is of course an ABI change, but a reasonably safe >> one, in that max_align_t doesn't tend to appear in library interfaces >> (rather, it's something to use when writing alloc

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

Hi, ISO/IEC TS 18661-3 redefines FLT_EVAL_METHOD. In this patch I'm interested in updating the code in GCC to handle two of the changes. The redefinition of the meanings of {0, 1, 2}, and the meaning of "N" for the specific case of N=16. In ISO/IEC TS 18661-3, these are defined as so: 0

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

Hi Richard, On 6 September 2016 at 19:08, Richard Biener wrote: > On Tue, Sep 6, 2016 at 2:24 AM, Kugan Vivekanandarajah > wrote: >> Hi Richard, >> >> On 5 September 2016 at 17:57, Richard Biener >> wrote: >>> On Mon, Sep 5, 2016 at 7:26 AM, Kugan Vivekanandarajah >>> wrote: Hi All,

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

On Tue, Sep 6, 2016 at 11:33 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 >> wrote: >>> Hi Richard, >>> >>> On 5 September 2016 at 17:57, Richard Biener >>> wrote: On Mo

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

Hi Richard, On 6 September 2016 at 19:57, Richard Biener wrote: > On Tue, Sep 6, 2016 at 11:33 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 >>> wrote: Hi Richard

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

On 5 September 2016 at 19:20, Jakub Jelinek wrote: > Hi! > > While it would be perhaps nice to pass explicit location_t in the target > option handling code, there are hundreds of error/warning/sorry calls > in lots of backends, and lots of those routines are used not just > for the process_option

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

On Tue, Sep 06, 2016 at 12:07:47PM +0200, Christophe Lyon wrote: > On 5 September 2016 at 19:20, Jakub Jelinek wrote: > > Hi! > > > > While it would be perhaps nice to pass explicit location_t in the target > > option handling code, there are hundreds of error/warning/sorry calls > > in lots of ba

Re: [libstdc++-v3] Fix dg-require before dg-run directives in testsuite.

On 02/09/16 14:17 +0100, Matthew Wahab wrote: Hello, Tests in the libstdc++-v3 testsuite were recently changed to use { dg-do .. { target c++11 } } instead of using a dg-options to set -std (https://gcc.gnu.org/ml/libstdc++/2016-08/msg00102.html). As a consequence, several tests were left with d

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

On Tue, Sep 6, 2016 at 12:07 PM, Kugan Vivekanandarajah wrote: > Hi Richard, > > > On 6 September 2016 at 19:57, Richard Biener > wrote: >> On Tue, Sep 6, 2016 at 11:33 AM, Kugan Vivekanandarajah >> wrote: >>> Hi Richard, >>> >>> On 6 September 2016 at 19:08, Richard Biener >>> wrote: On

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

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: >> > Hi! >> > >> > While it would be perhaps nice to pass explicit location_t in the target >> > option handling code, there

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

On 08/16/2016 04:30 PM, Nathan Sidwell wrote: > On 08/16/16 08:55, Martin Liška wrote: >> Hello. >> >> As reported in [1], m68k has been broken since I installed the patch. Reason >> is that the target >> does not support atomic operations (add, or) for a mode of gcov_type. >> Because of that, we

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

On Tue, Sep 6, 2016 at 6:45 AM, Martin Liška wrote: >>> Proper fix contains of 2 parts: >>> a) compiler emission must verify that -fprofile-update=atomic is doable for >>> a given target; it's done >>> via a new function can_generate_atomic_builtin >>> b) libgcc must detect whether __atomic_fetc

Re: Implement C _FloatN, _FloatNx types [version 6]

On Tue, 6 Sep 2016, Richard Biener wrote: > Note that this makes it maybe a good idea to only enable _FloatXX support > for targets that have explicitely done so once we near the GCC 7 release. I don't think that's a good idea; it's a recipe for most targets never supporting the new types when i

Re: [PATCH][RFC] Early LTO debug

On Fri, 26 Aug 2016, Richard Biener wrote: > > The patch below is my current development state of Early LTO debug lumped > into one big patch (no changelog, sorry). It contains previously posted > > https://gcc.gnu.org/ml/gcc-patches/2015-08/msg01089.html > > which extends dwarf2asm.h and ad

Re: Make max_align_t respect _Float128 [version 2]

On Tue, 6 Sep 2016, Richard Biener wrote: > > On 32-bit x86, max_align_t is currently 8-byte aligned, but > > _Decimal128 and _Float128 are 16-byte aligned, so the alignment of > > max_align_t needs to increase to meet the standard requirements for > > these types. > > As doubles on 32bit x86 are

Re: Make max_align_t respect _Float128 [version 2]

On Tue, 6 Sep 2016, Florian Weimer wrote: > Why aren't there any users? The standard isn't very clear what the value of > _Alignof (max_align_t) actually means. Does the phrase “all contexts” include > pointers returned malloc? Even if the requested size is smaller than the > fundamental alignm

Re: [PATCH][AArch64] Improve stack adjustment

ping     Richard Earnshaw wrote: > I see you've added a default argument for your new parameter.  I think > doing that is fine, but I have two comments about how we might use that > in this case. > > Firstly, if this parameter is suitable for having a default value, then > I think the preceding

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

Ping. On 2016/8/29 03:46 PM, Chung-Lin Tang wrote: > Hi Jakub, > this patch is a port of some changes from gomp-4_0-branch, > including adding additional map type handling in OpenACC enter/exit data > directives, and some pointer set handling changes. Updated > testsuite case are also included. >

Re: Make max_align_t respect _Float128 [version 2]

On 09/06/2016 11:11 AM, Florian Weimer wrote: I think this change is only safe because nothing relies on it. max_align_t is a committee invention with no actual users. I tried to verify that and ran grep over all the packages in /usr/portage/distfiles. That did get a number of matches, fairly

[Patch, testsuite, avr] Skip gcc.dg/Wno-frame-address.c for avr

Hi, The below patch adds avr to the list of targets excluded for Wno-frame-address.c. Like the other excluded targets, the avr backend only supports the builtin for the current stack frame. Committed to trunk. Regards Senthil gcc/testsuite/ChangeLog: 2016-09-06 Senthil Kumar Selvaraj

Re: [DOC] Boolean -> boolean changes

On 09/06/2016 11:19 AM, Marek Polacek wrote: As discussed , this patch makes the Boolean -> boolean change in our doc/ directory. Ok for trunk? Yes, thanks. Bernd

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

Hi! On Mon, 29 Aug 2016 15:46:47 +0800, Chung-Lin Tang wrote: > this patch is a port of some changes from gomp-4_0-branch, > including adding additional map type handling in OpenACC enter/exit data > directives, and some pointer set handling changes. Updated > testsuite case are also included. >

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

On 09/06/16 06:57, David Edelsohn wrote: What about Jakub's comment in the PR? https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77378#c6 This needs addressing. Can you clarify PPC behaviour, because I may have misunderstood: 1) PPC currently has 64 bit counters -- but cannot support 64bit ato

Re: [PATCH][RFC] Early LTO debug

On 2016.09.06 at 13:17 +0200, Richard Biener wrote: > > The following is an updated patch, mainly stripped out old unnecessary > cruft and some fixes for an issue that arised when LTOing Firefox. One minor issue that I've noticed is that the patch generates a lot of empty *debugobj* files in $TMP

Re: [PATCH][RFC] Early LTO debug

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 unnecessary > > cruft and some fixes for an issue that arised when LTOing Firefox. > > One minor issue that I've noticed is that

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

On Tue, Sep 06, 2016 at 08:14:58AM -0400, Nathan Sidwell wrote: > On 09/06/16 06:57, David Edelsohn wrote: > > >What about Jakub's comment in the PR? > > > >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77378#c6 > > This needs addressing. Can you clarify PPC behaviour, because I may have > misund

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

On Tue, Sep 6, 2016 at 8:14 AM, Nathan Sidwell wrote: > On 09/06/16 06:57, David Edelsohn wrote: > >> What about Jakub's comment in the PR? >> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77378#c6 > > > This needs addressing. Can you clarify PPC behaviour, because I may have > misunderstood: >

[PATCH] Fix PR77450

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 c-family/ * c-common.c (c_common_mark_addressable_vec): Handle COMPOUND_LITERAL_EXPR. * c-c++-common/vec

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

On Tue, Sep 6, 2016 at 8:26 AM, Jakub Jelinek wrote: > On Tue, Sep 06, 2016 at 08:14:58AM -0400, Nathan Sidwell wrote: >> On 09/06/16 06:57, David Edelsohn wrote: >> >> >What about Jakub's comment in the PR? >> > >> >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77378#c6 >> >> This needs addressing

[PATCH] Fix PR77479

The following fixes PR77479. Boosttrapped and tested on x86_64-unknown-linux-gnu, applied to trunk. Richard. 2016-09-06 Richard Biener PR tree-optimization/77479 * tree-vrp.c (update_value_range): Extend overflow handling to VARYING. * gcc.dg/torture/pr77479

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

On 09/06/2016 02:38 PM, David Edelsohn wrote: > On Tue, Sep 6, 2016 at 8:14 AM, Nathan Sidwell wrote: >> On 09/06/16 06:57, David Edelsohn wrote: >> >>> What about Jakub's comment in the PR? >>> >>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77378#c6 >> >> >> This needs addressing. Can you clar

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

On Tue, Sep 06, 2016 at 02:45:32PM +0200, Martin Liška wrote: > --- a/gcc/tree-profile.c > +++ b/gcc/tree-profile.c > @@ -528,6 +528,13 @@ gimple_gen_ior_profiler (histogram_value value, unsigned > tag, unsigned base) >gsi_insert_before (&gsi, call, GSI_NEW_STMT); > } > > +#ifndef HAVE_sync

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

On 09/06/2016 02:51 PM, Jakub Jelinek wrote: > On Tue, Sep 06, 2016 at 02:45:32PM +0200, Martin Liška wrote: >> --- a/gcc/tree-profile.c >> +++ b/gcc/tree-profile.c >> @@ -528,6 +528,13 @@ gimple_gen_ior_profiler (histogram_value value, >> unsigned tag, unsigned base) >>gsi_insert_before (&gsi

[PATCH][AArch64] Improve legitimize_address

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 fewer base address calculations: int f(int *p) {

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

On Tue, Sep 06, 2016 at 03:13:09PM +0200, Martin Liška wrote: > @@ -535,6 +549,27 @@ tree_profiling (void) > { >struct cgraph_node *node; > > + /* Verify whether we can utilize atomic update operations. */ > + if (flag_profile_update == PROFILE_UPDATE_ATOMIC) > +{ > + bool can_su

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

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) > == 4 vs. 8). > As SImode and DImode are in fact 4*BITS_PER_UNIT and 8*BITS_P

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

On Tue, Sep 06, 2016 at 03:45:09PM +0200, Martin Liška wrote: > --- a/libgcc/libgcov-profiler.c > +++ b/libgcc/libgcov-profiler.c > @@ -24,8 +24,20 @@ see the files COPYING3 and COPYING.RUNTIME respectively. > If not, see > . */ > > #include "libgcov.h" > +#incl

Re: [PATCH][RFC] Early LTO debug

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 unnecessary > > > cruft and some fixes for an issue that arised whe

Re: Make max_align_t respect _Float128 [version 2]

On 09/06/2016 01:59 PM, Bernd Schmidt wrote: On 09/06/2016 11:11 AM, Florian Weimer wrote: I think this change is only safe because nothing relies on it. max_align_t is a committee invention with no actual users. I tried to verify that and ran grep over all the packages in /usr/portage/distfi

Re: [DOC] Boolean -> boolean changes

On Tue, 6 Sep 2016, Marek Polacek wrote: > * doc/tm.texi: Likewise. You can't modify tm.texi directly; you have to modify whichever is appropriate of target.def and tm.texi.in, then regenerate tm.texi. -- Joseph S. Myers jos...@codesourcery.com

Re: Make max_align_t respect _Float128 [version 2]

On 09/06/2016 01:25 PM, Joseph Myers wrote: On Tue, 6 Sep 2016, Florian Weimer wrote: Why aren't there any users? The standard isn't very clear what the value of _Alignof (max_align_t) actually means. Does the phrase “all contexts” include pointers returned malloc? Even if the requested size

Re: [PATCH, i386] Fix ICE with a md builtin call (PR target/69255)

On Mon, Sep 05, 2016 at 08:58:12PM +0200, Uros Bizjak wrote: > ... perhaps we can emit a warning here and expand the builtin as a > call? This way, we will mirror the case when builtin requires some > ISA, e.g.: > > void foo () > { > __builtin_ia32_stmxcsr(); > } > > $ gcc -S -mno-sse dd.c > dd

[PATCH][v3] GIMPLE store merging pass

Hi all, The v3 of this patch addresses feedback I received on the version posted at [1]. The merged store buffer is now represented as a char array that we splat values onto with native_encode_expr and native_interpret_expr. This allows us to merge anything that native_encode_expr accepts, incl

Re: Make max_align_t respect _Float128 [version 2]

On Tue, 6 Sep 2016, Florian Weimer wrote: > So that's what ties the two things together. I still don't like what's > implied in PR1, that all object sizes have to be multiples of the > fundamental alignment. I don't think there's any such requirement in the case of flexible array members; i

Re: [PATCH, i386] Fix ICE with a md builtin call (PR target/69255)

On Tue, Sep 6, 2016 at 5:06 PM, Jakub Jelinek wrote: > On Mon, Sep 05, 2016 at 08:58:12PM +0200, Uros Bizjak wrote: >> ... perhaps we can emit a warning here and expand the builtin as a >> call? This way, we will mirror the case when builtin requires some >> ISA, e.g.: >> >> void foo () >> { >>

[RFC,PATCH] Using equivalences to help eliminate_regs_in_insn

I've found a case of suboptimal code coming from LRA when we have a large frame and have the frame grow downwards with MIPS. A good testcase for this is the qsort benchmark from the automotive section of mibench[1]. Any frame access where the offset is not supported as an add-immediate should bene

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

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 posted at > [1]. > The merged store buffer is now represented as a char array that we splat > values onto with > native_encode_expr and native_interpret_expr. This a

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

Ping? CC-ing an i386 maintainer since the patch mostly touches i386-specific files. Also, to clarify, I say "warnings/errors" because they start off as warnings in stage 1 but then become errors in stage 2. Note also that my patch leaves out the part where I modify the configure script to enable -W

Re: Make max_align_t respect _Float128 [version 2]

On 09/06/2016 08:16 AM, Joseph Myers wrote: I don't think there's any such requirement in the case of flexible array members; if you use malloc to allocate a structure with a flexible array member, you can access as many trailing array elements as would fit within the allocated size, whether or n

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

Hi Jakub, 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 posted at [1]. The merged store buffer is now represented as a char array that we splat values onto with native_en

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

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 posted at > >>[1]. > >>The merged store buffer is now r

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

On 06/09/16 17:21, 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 posted at [1]. The

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

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. Also, to clarify, I say "warnings/errors" because > they start off as warnings in stage 1 but then become errors in stage > 2. Note also that my patch leaves

Re: [PATCH 3/4][PR 71931] Fix libitm tests

On Sep 6, 2016, at 2:11 AM, Torvald Riegel wrote: > > On Wed, 2016-08-24 at 20:08 +0100, Szabolcs Nagy wrote: >> Pass build time CC make var down to dejagnu so the sysroot >> is set correctly when gcc is built with --with-build-sysroot. >> >> libitm/ >> 2016-08-24 Szabolcs Nagy >> >> PR

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

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. Also, to clarify, I say "warnings/errors" because >> they start off as warnings in stage 1 but then become errors in stage

Re: Make max_align_t respect _Float128 [version 2]

Hi, I'd like to share some of my thoughts about the max_align_t, if you don't mind. I think that for _Float128 to become a fundamental data type, it is *not* sufficient that gcc supports it alone, because glibc needs to support also all the necessary math library functions. When that is done, gl

Re: [PATCH 3/4][PR 71931] Fix libitm tests

On 06/09/16 18:34, Mike Stump wrote: > On Sep 6, 2016, at 2:11 AM, Torvald Riegel wrote: >> >> On Wed, 2016-08-24 at 20:08 +0100, Szabolcs Nagy wrote: >>> Pass build time CC make var down to dejagnu so the sysroot >>> is set correctly when gcc is built with --with-build-sysroot. >>> >>> libitm/ >>

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

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 guard/branch before loops checking if the fol

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

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 2016-09-01 Bin Cheng * cfg.c (reset_o

[PATCH GCC 6/9]Simplify control flow graph for vectorized loop

Hi, This is the main patch improving control flow graph for vectorized loop. It generally rewrites loop peeling stuff in vectorizer. As described in patch, for a typical loop to be vectorized like: preheader: LOOP: header_bb: loop_body if (exit_loop_cond) g

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

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 Bin Cheng * gcc.target/i386/l_f

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

Hi, LOOP_VINFO_NITERS is computed as LOOP_VINFO_NITERSM1 + 1, which could overflow in loop niters' type. Vectorizer needs to generate more code computing vectorized niters if overflow does happen. However, For common loops, there is no overflow actually, this patch tries to prove the no-overfl

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

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 of live var, it simply replaces all uses outs

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

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 to read. I assume this is good for basic b

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

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 guard on the vectorized loop. Though the loo

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

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 this. Thanks, bin 2016-09-01 Bin Cheng

Re: [PATCH 3/4][PR 71931] Fix libitm tests

On Sep 6, 2016, at 11:13 AM, Szabolcs Nagy wrote: > > On 06/09/16 18:34, Mike Stump wrote: >> On Sep 6, 2016, at 2:11 AM, Torvald Riegel wrote: >>> >>> On Wed, 2016-08-24 at 20:08 +0100, Szabolcs Nagy wrote: Pass build time CC make var down to dejagnu so the sysroot is set correctly w

Re: Debug algorithms

Hi Any final decision regarding this patch ? Note that __std_a namespace is optional, I can remove this change from the patch if you want. François On 18/07/2016 21:25, François Dumont wrote: On 13/07/2016 19:45, Jonathan Wakely wrote: On 22/06/16 22:05 +0200, François Dumont wrot

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

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 other testcase shows, there were various ICEs with -fnon-c

[PATCH, i386] Spellcheck hints for the i386 backend option handling (PR middle-end/77475, take 2, generic part)

Hi! On Mon, Sep 05, 2016 at 09:59:03PM +0200, Jakub Jelinek wrote: > Plus obviously the unrecognized_argument_error needs to be declared in some > header file. > > That said, for x86 -march/-mtune uses this is problematic, as it uses either > %<-march=%> argument or target("march=") attribute wor

[PATCH, i386] Spellcheck hints for the i386 backend option handling (PR middle-end/77475, take 2, i386 part)

Hi! On Mon, Sep 05, 2016 at 09:00:30PM +0200, Uros Bizjak wrote: > OK as far as x86 target is concerned, but please allow a day for David > to eventually comment on the implementation. And here is the updated i386 patch, on top of the generic patch I've just posted. Compared to the last patch, t

Re: Make max_align_t respect _Float128 [version 2]

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 of flexible array members anticipate needin

Re: Make max_align_t respect _Float128 [version 2]

On Tue, 6 Sep 2016, Bernd Edlinger wrote: > I think that for _Float128 to become a fundamental data type, > it is *not* sufficient that gcc supports it alone, because glibc > needs to support also all the necessary math library functions. No, the definition of basic types for a freestanding imple

Re: Make max_align_t respect _Float128 [version 2]

On Tue, Sep 6, 2016 at 11:16 AM, Joseph Myers wrote: > GCC is supposed to support all mallocs that produce results aligned to at > least MALLOC_ABI_ALIGNMENT (which may be smaller than the alignment of > max_align_t). I've just been running into problems with MALLOC_ABI_ALIGNMENT being smaller th

Re: Make max_align_t respect _Float128 [version 2]

On Tue, 6 Sep 2016, Jason Merrill wrote: > On Tue, Sep 6, 2016 at 11:16 AM, Joseph Myers wrote: > > GCC is supposed to support all mallocs that produce results aligned to at > > least MALLOC_ABI_ALIGNMENT (which may be smaller than the alignment of > > max_align_t). > > I've just been running in

Re: [PATCH] Delete GCJ

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 5:13:06 PM GMT+02:00, Andrew Haley wrote: As discussed. I think I s

Re: [PATCH, rs6000] Fix PR72827 (ada bootstrap failure)

On 08/31/2016 01:08 AM, Eric Botcazou wrote: DSE should really detect this is happening and not do the wrong thing. Maybe add an assert somewhere? Much easier to debug, that way. That sounds fragile, functions are allowed to fiddle with the frame pointer in the prologue or epilogue (but of cou

Re: Make max_align_t respect _Float128 [version 2]

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 calling it a defect, as most code I've seen de

Re: Make max_align_t respect _Float128 [version 2]

On Tue, Sep 6, 2016 at 5:03 PM, Joseph Myers wrote: > On Tue, 6 Sep 2016, Jason Merrill wrote: > >> On Tue, Sep 6, 2016 at 11:16 AM, Joseph Myers >> wrote: >> > GCC is supposed to support all mallocs that produce results aligned to at >> > least MALLOC_ABI_ALIGNMENT (which may be smaller than th

Re: Make max_align_t respect _Float128 [version 2]

On Tue, 6 Sep 2016, Jason Merrill wrote: > The reason I care is that C++17 aligned new (wg21.link/p0035) > specifies that for types that require more alignment than the usual > operator new provides, the new-expression instead calls an operator > new with an explicit alignment parameter. MALLOC_A

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

On 09/05/2016 01:57 AM, Richard Biener wrote: On Mon, Sep 5, 2016 at 7:26 AM, Kugan Vivekanandarajah wrote: Hi All, While looking at gcc source, I noticed that we are iterating over SSA variable from 0 to num_ssa_names in some cases and 1 to num_ssa_names in others. It seems that variable 0 is

Re: [PATCH] Move class substring_loc from c-family into gcc

On 09/03/2016 03:13 AM, 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 @@ -20,6 +20,73 @@ along with GCC; see the fi

[PATCHv2] Fix a few simple cases where -Wparentheses does not warn for omitted middle value

On 09/05/16 23:50, Bernd Edlinger wrote: > Hi, > > I've noticed that there is already a -Wparentheses warning for code like > > int y = x == 2 ?: 1 > > => warning: the omitted middle operand in ?: will always be 'true', > suggest explicit middle operand [-Wparentheses] > > But it is not emitted f

Re: [PATCH, rs6000] Fix PR72827 (ada bootstrap failure)

On Tue, Sep 06, 2016 at 03:24:24PM -0600, Jeff Law wrote: > On 08/31/2016 01:08 AM, Eric Botcazou wrote: > >>DSE should really detect this is happening and not do the wrong thing. > >>Maybe add an assert somewhere? Much easier to debug, that way. > > > >That sounds fragile, functions are allowed t

Re: [PATCH, rs6000] Fix PR72827 (ada bootstrap failure)

On 09/06/2016 04:14 PM, Segher Boessenkool wrote: On Tue, Sep 06, 2016 at 03:24:24PM -0600, Jeff Law wrote: On 08/31/2016 01:08 AM, Eric Botcazou wrote: DSE should really detect this is happening and not do the wrong thing. Maybe add an assert somewhere? Much easier to debug, that way. That

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

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 computing vectorized niters if overflow does happen. However, For common loops, there is no overflow ac

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

Hi Richard, On 6 September 2016 at 19:08, Richard Biener wrote: > On Tue, Sep 6, 2016 at 2:24 AM, Kugan Vivekanandarajah > wrote: >> Hi Richard, >> >> On 5 September 2016 at 17:57, Richard Biener >> wrote: >>> On Mon, Sep 5, 2016 at 7:26 AM, Kugan Vivekanandarajah >>> wrote: Hi All,

  1   2   >