[PATCH] Check NULL loop->latch in verify_loop_structure

Hi, In verify_loop_structure, we stop checking the latch once we find that it's NULL. This patch tries a bit harder: - if !LOOPS_MAY_HAVE_MULTIPLE_LATCHES, we don't allow a NULL latch - if LOOPS_MAY_HAVE_MULTIPLE_LATCHES, we check that indeed there's no single loop latch. As a consequence

Re: Enable pointer TBAA for LTO

> > + tree t = TREE_TYPE (field); > > + if (in_lto_p) > > + { > > + /* VECTOR_TYPE and ARRAY_TYPE share the alias set with their > > + element type and that type has to be normalized to void *, > > + too, in the case it is a pointer. */ > > +

Re: [PATCH] Improve BB vectorization dependence analysis

On Mon, Nov 9, 2015 at 4:55 AM, Richard Biener wrote: > > Currently BB vectorization computes all dependences inside a BB > region and fails all vectorization if it cannot handle some of them. > > This is obviously not needed - BB vectorization can restrict the > dependence

[PATCH 0/2] Libsanitizer merge from upstream r253555.

Hi! Following recent discussion (https://gcc.gnu.org/ml/gcc-patches/2015-11/msg02310.html), I would like to merge recent sanitizer library to GCC to make available new useful features from upstream in GCC 6: * The shadow offset for ASan was unified on Aarch64 for 39 and 42 VMAs

Re: RFC: C++ delayed folding merge

Hi Jason! On Mon, 9 Nov 2015 01:30:34 -0500, Jason Merrill wrote: > I'm planning to merge the C++ delayed folding branch this week [...] Would be nice to get rid of the two following UNRESOLVEDs: > --- a/gcc/testsuite/g++.dg/init/self1.C > +++

Re: [ptx] partitioning optimization

Hi! On Fri, 13 Nov 2015 21:22:11 +0100, Bernd Schmidt wrote: > On 11/13/2015 09:06 PM, Nathan Sidwell wrote: > > On 11/11/15 09:19, Bernd Schmidt wrote: > >> On 11/11/2015 02:59 PM, Nathan Sidwell wrote: > >>> That's not the problem. How to conditionally enable the test is

[PATCH 2/2] Libsanitizer merge from upstream r253555.

This patch reflects to corresponding compiler changes. In particular, it just enables -fsanitize-recover=address switch and migrates two small testcases from upstream. I don't backport other stress tests because they are heavy and have unstable output. -Maxim gcc/testsuite/ChangeLog:

Re: Enable pointer TBAA for LTO

Hi, here is updated patch which I finally comitted today. It addresses all the comments and also fixes one nasty bug that really cost me a lot of time to understand. + /* LTO type merging does not make any difference between +component pointer types. We may have + +

Re: [PATCH] PR52251

On Sun, Nov 22, 2015 at 02:35:01PM -0800, Jerry DeLisle wrote: > Another old patch I forgot about. This one is fairly self > explanatory. We were not handling pending spaces for > ADVANCE_NO and T editing. > > Regression tested x86-64-linux. New test case. > > OK for trunk? > Looks ok to

Re: Enable pointer TBAA for LTO

> + tree t = TREE_TYPE (field); > + if (in_lto_p) > + { > + /* VECTOR_TYPE and ARRAY_TYPE share the alias set with their > +element type and that type has to be normalized to void *, > +too, in the case it is a pointer. */ > +

Re: Fix lto-symtab ICE during Ada LTO bootstrap

> > > ../../gcc/ada/s-os_lib.adb:1007:16: note: return value type > > > mismatch > > >function strerror (errnum : Integer) return System.Address; > > > ^ > > > > > > ../../gcc/ada/s-os_lib.adb:1007:16: note: > > > ???system__os_lib__errno_message__strerror??? was

[PATCH] Don't reapply loops flags if unnecessary in loop_optimizer_init

[ was: Re: [PATCH, 10/16] Add pass_oacc_kernels pass group in passes.def ] On 20/11/15 11:37, Richard Biener wrote: I'd rather make loop_optimizer_init do nothing if requested flags are already set and no fixup is needed and call the above unconditionally. Thus sth like Index: gcc/loop-init.c

[PATCH] PR52251

Another old patch I forgot about. This one is fairly self explanatory. We were not handling pending spaces for ADVANCE_NO and T editing. Regression tested x86-64-linux. New test case. OK for trunk? Jerry 2015-11-22 Jerry DeLisle PR libfortran/52251

Re: [Aarch64] Use vector wide add for mixed-mode adds

On 11/22/2015 8:48 AM, James Greenhalgh wrote: On Sun, Nov 08, 2015 at 11:51:47PM -0700, Michael Collison wrote: 2015-11-06 Michael Collison * config/aarch64/aarch64-simd.md (widen_ssum, widen_usum) (aarch64_w_internal): New patterns *

update zlib to 1.2.8

In GCC zlib is only used for libjava; for binutils and gdb it is used when building without --with-system-zlib. This just updates zlib from 1.2.7 to 1.2.8 (released in 2013). Applies cleanly, libjava still builds and doesn't show any regressions in the testsuite. Ok to apply (even if we

Re: [PATCH] (Partial) Implementation of simplificaiton of CSHIFT

Hi Steve, Compiling the attached code after revision r230710 gives the ICE f951: internal compiler error: in gfc_simplify_cshift, at fortran/simplify.c:1823 while it compiled before. TIA Dominique mhd.f90 Description: Binary data

Re: GCC 5.3 Status Report (2015-11-20)

On 20/11/2015 14:14, David Edelsohn wrote: > On Fri, Nov 20, 2015 at 7:53 AM, Richard Biener wrote: >> >> Status >> == >> >> We plan to do a GCC 5.3 release candidate at the end of next week >> followed by the actual release a week after that. >> >> So now is the time to

Re: [AARCH64][PATCH 2/3] Implementing vmulx_lane NEON intrinsic variants

On Mon, Nov 09, 2015 at 11:03:28AM +, Bilyan Borisov wrote: > > > On 03/11/15 11:16, James Greenhalgh wrote: > >On Fri, Oct 30, 2015 at 09:31:08AM +, Bilyan Borisov wrote: > >>In this patch from the series, all vmulx_lane variants have been > >>implemented as > >>a vdup followed by a

Re: [Aarch64] Use vector wide add for mixed-mode adds

On Sun, Nov 08, 2015 at 11:51:47PM -0700, Michael Collison wrote: > 2015-11-06 Michael Collison > * config/aarch64/aarch64-simd.md (widen_ssum, widen_usum) > (aarch64_w_internal): New patterns > * config/aarch64/iterators.md (Vhalf, VDBLW): New mode

Re: [PATCH] Fix PR objc/68438 (uninitialized source ranges)

On Fri, 2015-11-20 at 23:28 +, Joseph Myers wrote: > On Fri, 20 Nov 2015, David Malcolm wrote: > > > The source ranges are verified using the same unit-testing plugin used > > for C expressions. This leads to a wart, which is that it means having > > a .m test file lurking below

[PATCH] Add TARGET_FUNCTION_INCOMING_ARG_RTL

On Sat, Nov 21, 2015 at 11:19:57AM -0800, H.J. Lu wrote: > When implementing interrupt attribute for x86 interrupt handlers, we > have a difficult time to access interrupt data passed down by x86 > processors. On x86, interrupt handlers are only called by processors > which push interrupt data

Re: Fix lto-symtab ICE during Ada LTO bootstrap

> this patch fixes an ICE seen with Ada LTO bootstrap in reporting type > mismatches and it also makes us to stop complaining about C++ ODR > violation. The warnings are however correct. I looked at few: > > ../../libiberty/xstrerror.c:40:14: warning: type of �strerror� does not > match

Re: Fix lto-symtab ICE during Ada LTO bootstrap

> > ../../gcc/ada/s-os_lib.adb:1007:16: note: return value type > > mismatch > >function strerror (errnum : Integer) return System.Address; > > ^ > > > > ../../gcc/ada/s-os_lib.adb:1007:16: note: > > ???system__os_lib__errno_message__strerror??? was previously > > declared

Re: [PATCH] lround for PowerPC

On Sun, Nov 22, 2015 at 2:34 AM, Richard Biener wrote: > On November 22, 2015 2:52:53 AM GMT+01:00, David Edelsohn > wrote: >>PowerPC was missing a definition of the lroundMN pattern, which can be >>implemented with VSX instructions available in

Re: [AARCH64][PATCH 3/3] Adding tests to check proper error reporting of out of bounds accesses to vmulx_lane* NEON intrinsics

On Fri, Oct 30, 2015 at 09:32:07AM +, Bilyan Borisov wrote: > Implementing vmulx_* and vmulx_lane* NEON intrinsics > > Hi all, > > This series of patches focuses on the different vmulx_ and vmulx_lane NEON > intrinsics variants. All of the existing inlined assembly block > implementations >

[PATCH v2] Add uaddv_optab, usubv4_optab

The full round of testing from v1 turned up a couple of problems. One of which I believe I've worked around in the i386 backend, but I believe to be a latent problem within combine. With the following patch, disable the add3_*_overflow_2 patterns. Then compile

[Back port r227760] PR67460 [5 Regression] Spurious: f951: all warnings being treated as errors

Is it OK to back port revision r227760 to 5.3? Tested on x86_64-apple-darwin14 Dominique Index: gcc/ChangeLog === --- gcc/ChangeLog (revision 230703) +++ gcc/ChangeLog (working copy) @@ -1,3 +1,17 @@ +2015-11-22

Re: [PATCH] fortran/openmp.c -- Fix bootstrap

Hi, Patch committed to trunk as obvious. Thanks to Dominique and Steve. Jim On 11/22/2015 12:59 PM, Steve Kargl wrote: I have no idea if this is actually correct, but it restores bootstrap. OK to commit? 2015-11-22 Steven G. Kargl * openmp.c

Re: Fix lto-symtab ICE during Ada LTO bootstrap

> > this patch fixes an ICE seen with Ada LTO bootstrap in reporting type > > mismatches and it also makes us to stop complaining about C++ ODR > > violation. The warnings are however correct. I looked at few: > > > > ../../libiberty/xstrerror.c:40:14: warning: type of �strerror� does not > >

Fix tree-ssa-dce Ada LTO bootstrap ice

Hi, this patch fixes tree-ssa-dce ICE seen during Ada bootstrap. It is updated version of https://gcc.gnu.org/ml/gcc-patches/2015-05/msg02876.html for current mainline Bootstrapped/regtested x86_64-linux, OK? PR middle-end/65337 * tree-ssa-dce.c (bb_postorder): New static var.

[PATCH] fortran/openmp.c -- Fix bootstrap

I have no idea if this is actually correct, but it restores bootstrap. OK to commit? 2015-11-22 Steven G. Kargl * openmp.c (match_oacc_clause_gang): Fix bootstrap. Index: openmp.c === --- openmp.c

Re: [Back port r227760] PR67460 [5 Regression] Spurious: f951: all warnings being treated as errors

On 11/22/2015 01:14 AM, Dominique d'Humières wrote: > Is it OK to back port revision r227760 to 5.3? > Tested on x86_64-apple-darwin14 > > Dominique > I think its OK. Jerry

Re: [PATCH] fortran/openmp.c -- Fix bootstrap

On 11/22/2015 10:59 AM, Steve Kargl wrote: > I have no idea if this is actually correct, but it restores bootstrap. > OK to commit? > This looks correct to me. There should be no more in the lists than OMP_LIST_NUM. Was there a PR for this and do we know when it broke? Jerry

Re: [PATCH] (Partial) Implementation of simplificaiton of CSHIFT

On Sun, Nov 22, 2015 at 09:51:09AM +0100, Dominique d'Humi??res wrote: > > Compiling the attached code after revision r230710 gives the ICE > > f951: internal compiler error: in gfc_simplify_cshift, at > fortran/simplify.c:1823 > > while it compiled before. > File a bug report, then fix rank

Re: [PATCH] (Partial) Implementation of simplificaiton of CSHIFT

> Le 22 nov. 2015 à 17:21, Steve Kargl a > écrit : > > On Sun, Nov 22, 2015 at 09:51:09AM +0100, Dominique d'Humi??res wrote: >> >> Compiling the attached code after revision r230710 gives the ICE >> >> f951: internal compiler error: in gfc_simplify_cshift,

Re: [PATCH v2] Add uaddv_optab, usubv4_optab

Hi Richard, On Sun, Nov 22, 2015 at 11:38:31AM +0100, Richard Henderson wrote: > One of which I believe I've worked around in the i386 backend, but I > believe to be a latent problem within combine. > > With the following patch, disable the add3_*_overflow_2 patterns. > Then compile

Re: [PATCH] lround for PowerPC

v2 of the patch. Seems to pass the GCC testsuite, although the testsuite doesn't stress FP. There is something wrong with current VSX SFmode constraints. Index: rs6000.md === --- rs6000.md (revision 230723) +++ rs6000.md (working

Re: [PATCH v2] Add uaddv_optab, usubv4_optab

On Sun, Nov 22, 2015 at 11:38 AM, Richard Henderson wrote: > The full round of testing from v1 turned up a couple of problems. > > One of which I believe I've worked around in the i386 backend, but I believe > to be a latent problem within combine. > > With the following patch,

[COMMITTED] libitm: Fix recent changes to allocations log.

This fixes an oversight in the recent changes to the allocations log for supporting sized delete. Tested libitm on x86_64-linux. COmmitted as obvious. libitm/ * libitm_i.h (gtm_alloc_action): Remove union. * testsuite/libitm.c/alloc-1.c: New. commit

[PATCH] Fix leading zero with g0 editing

This minor patch brings the leading zero to emitting floats with g0 editing by moving the block of code up a little before the g0 is handled. This has been lurking in my trunk for several moths and I would like to get it out of the way. Updated Test case also. Regression tested on x86-64-linux.

Re: [PATCH] Fix leading zero with g0 editing

On Sun, Nov 22, 2015 at 01:32:56PM -0800, Jerry DeLisle wrote: > This minor patch brings the leading zero to emitting floats with g0 editing by > moving the block of code up a little before the g0 is handled. This has been > lurking in my trunk for several moths and I would like to get it out of

Re: Short-cut generation of simple built-in functions

On Sat, Nov 7, 2015 at 5:31 AM, Richard Sandiford wrote: > This patch short-circuits the builtins.c expansion code for a particular > gimple call if: > > - the function has an associated internal function > - the target implements that internal function > - the call has

Re: [PATCH] Fix leading zero with g0 editing

On 11/22/2015 01:44 PM, Steve Kargl wrote: > On Sun, Nov 22, 2015 at 01:32:56PM -0800, Jerry DeLisle wrote: >> This minor patch brings the leading zero to emitting floats with g0 editing >> by >> moving the block of code up a little before the g0 is handled. This has been >> lurking in my trunk