Re: [PATCH 2/7] Libsanitizer merge from upstream r249633.

On Tue, Oct 13, 2015 at 02:16:23PM +0300, Maxim Ostapenko wrote: > This patch introduces required compiler changes. Now, we don't version > asan_init, we have a special __asan_version_mismatch_check_v[n] symbol for > this. For this, I just have to wonder what is the actual improvement over what we

Re: [PATCH 3/7] Libsanitizer merge from upstream r249633.

On Tue, Oct 13, 2015 at 02:17:46PM +0300, Maxim Ostapenko wrote: > This is just reapplied patch for SPARC by David S. Miller. I was unable to > test this, so could anyone help me here? This is ok if all the other changes are approved. You don't need to list my name in there, just list David's. W

Re: [PATCH 4/7] Libsanitizer merge from upstream r249633.

On Tue, Oct 13, 2015 at 02:18:41PM +0300, Maxim Ostapenko wrote: > This is a reapplied Jakub's patch for disabling ODR violation detection. > More details can be found here > (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888). This is ok when all the other changes are acked. > 2015-10-12 Maxim

Re: Merge from gomp-4_1-branch to trunk

Hello, I get now the following error: libtool: compile: /scratch/git-build/b-gcc-git-arm-rtems4.12/./gcc/xgcc -B/scratch/git-build/b-gcc-git-arm-rtems4.12/./gcc/ -nostdinc -B/scratch/git-build/b-gcc-git-arm-rtems4.12/arm-rtems4.12/newlib/ -isystem /scratch/git-build/b-gcc-git-arm-rtems4.12/a

Re: [PATCH 5/7] Libsanitizer merge from upstream r249633.

On Tue, Oct 13, 2015 at 02:20:06PM +0300, Maxim Ostapenko wrote: > This patch removes UBSan stubs from ASan and TSan code. We don't embed UBSan > to ASan and UBSan because that would lead to undefined references to C++ > stuff when linking with -static-libasan. AFAIK, sanitizer developers use > dif

Re: [PATCH 6/7] Libsanitizer merge from upstream r249633.

On Tue, Oct 13, 2015 at 02:21:21PM +0300, Maxim Ostapenko wrote: > This patch adjusts the fix for > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61771 to extract the last PC > from the stack frame if no valid FP is available for ARM. I guess this is ok once all other changes are acked. > 2015-10-

Re: [PATCH 7/7] Libsanitizer merge from upstream r249633.

On Tue, Oct 13, 2015 at 02:22:36PM +0300, Maxim Ostapenko wrote: > This is the final patch. Force libsanitizer to use an old ABI for ubsan > float cast data descriptors, because for some exprs (e.g. that type of > tcc_declaration) we can't get the right location for now. I'm not sure about > this,

Re: [PATCH 2/7] Libsanitizer merge from upstream r249633.

On 10/13/2015 02:16 PM, Maxim Ostapenko wrote: This patch introduces required compiler changes. Now, we don't version asan_init, we have a special __asan_version_mismatch_check_v[n] symbol for this. Also, asan_stack_malloc_[n] doesn't take a local stack as a second parameter anymore, so don't pa

Re: [PATCH 1/7] Libsanitizer merge from upstream r249633.

On Tue, Oct 13, 2015 at 07:54:33PM +0300, Maxim Ostapenko wrote: > On 13/10/15 14:15, Maxim Ostapenko wrote: > >This is the raw merge itself. I'm bumping SONAME to libasan.so.3. > > > >-Maxim > > I have just noticed that I've misused autoconf stuff (used wrong version). > Here a fixed version of t

Re: Merge from gomp-4_1-branch to trunk

On Wed, Oct 14, 2015 at 09:34:48AM +0200, Sebastian Huber wrote: > /home/EB/sebastian_h/archive/gcc-git/libgomp/fortran.c:28:0: > /home/EB/sebastian_h/archive/gcc-git/libgomp/fortran.c:73:18: note: expected > 'int *' but argument is of type 'int32_t * {aka long int *}' Ugh, wasn't aware that some

Re: Merge from gomp-4_1-branch to trunk

On 14/10/15 10:04, Jakub Jelinek wrote: On Wed, Oct 14, 2015 at 09:34:48AM +0200, Sebastian Huber wrote: >/home/EB/sebastian_h/archive/gcc-git/libgomp/fortran.c:28:0: >/home/EB/sebastian_h/archive/gcc-git/libgomp/fortran.c:73:18: note: expected >'int *' but argument is of type 'int32_t * {aka

Re: using scratchpads to enhance RTL-level if-conversion: revised patch

> If you're using one of the switches that checks for stack overflow at the > start of the function, you certainly don't want to do any such stores. There is a protection area for -fstack-check (STACK_CHECK_PROTECT bytes) so you can do stores just below the stack pointer as far as it's concerned.

[PATCH] More vectorizer TLC

Bootstrapped / tested on x86_64-unknown-linux-gnu, applied. Richard. 2015-10-14 Richard Biener * tree-vect-data-refs.c (vect_enhance_data_refs_alignment): Reset info at start. (vect_analyze_group_access_1): Add debug print. * tree-vect-loop.c (vect_get_single_

Re: Merge from gomp-4_1-branch to trunk

On 14/10/15 10:04, Jakub Jelinek wrote: No, both the above changes are wrong. There is not a single int32_t written, but could be many more, it is an array of 32-bit integers. I'd say you just want to cast explicitly, omp_get_place_proc_ids (*place_num, (int *) ids); and omp_get_parition_p

Re: [vec-cmp, patch 4/6] Support vector mask invariants

On Tue, Oct 13, 2015 at 4:52 PM, Ilya Enkovich wrote: > 2015-10-13 16:54 GMT+03:00 Richard Biener : >> On Thu, Oct 8, 2015 at 5:11 PM, Ilya Enkovich wrote: >>> Hi, >>> >>> This patch adds a special handling of boolean vector invariants. We need >>> additional code to determine type of generated

Re: Benchmarks of v2 (was Re: [PATCH 0/5] RFC: Overhaul of diagnostics (v2))

On Tue, Oct 13, 2015 at 5:32 PM, David Malcolm wrote: > On Thu, 2015-09-24 at 10:15 +0200, Richard Biener wrote: >> On Thu, Sep 24, 2015 at 2:25 AM, David Malcolm wrote: >> > On Wed, 2015-09-23 at 15:36 +0200, Richard Biener wrote: >> >> On Wed, Sep 23, 2015 at 3:19 PM, Michael Matz wrote: >> >>

Re: [PATCH] Optimize const1 * copysign (const2, y) in reassoc (PR tree-optimization/67815)

On Tue, 13 Oct 2015, Marek Polacek wrote: > This patch implements the copysign optimization for reassoc I promised > I'd look into. I.e., > > CST1 * copysign (CST2, y) -> copysign (CST1 * CST2, y) if CST1 > 0 > CST1 * copysign (CST2, y) -> -copysign (CST1 * CST2, y) if CST1 < 0 > > After gettin

Re: [PATCH 8/9] Add TARGET_ADDR_SPACE_ZERO_ADDRESS_VALID

On Tue, Oct 13, 2015 at 10:59 PM, Richard Henderson wrote: > On 10/14/2015 02:49 AM, Jeff Law wrote: >> >> The problem here is we don't know what address space the *0 is going to >> hit, >> right? > > > Correct, not before we do the walk of stmt to see what's present. > >> Isn't that also an issue

Re: [PATCH 8/9] Add TARGET_ADDR_SPACE_ZERO_ADDRESS_VALID

On Wed, Oct 14, 2015 at 11:19 AM, Richard Biener wrote: > On Tue, Oct 13, 2015 at 10:59 PM, Richard Henderson wrote: >> On 10/14/2015 02:49 AM, Jeff Law wrote: >>> >>> The problem here is we don't know what address space the *0 is going to >>> hit, >>> right? >> >> >> Correct, not before we do th

Re: [PR67891] drop is_gimple_reg test from set_parm_rtl

On Wed, Oct 14, 2015 at 5:25 AM, Alexandre Oliva wrote: > On Oct 12, 2015, Richard Biener wrote: > >> On Sat, Oct 10, 2015 at 3:16 PM, Alexandre Oliva wrote: >>> On Oct 9, 2015, Richard Biener wrote: >>> Ok. Note that I think emit_block_move shouldn't mess with the addressable flag

Re: [PATCH 1/7] Libsanitizer merge from upstream r249633.

On 14/10/15 10:54, Jakub Jelinek wrote: On Tue, Oct 13, 2015 at 07:54:33PM +0300, Maxim Ostapenko wrote: On 13/10/15 14:15, Maxim Ostapenko wrote: This is the raw merge itself. I'm bumping SONAME to libasan.so.3. -Maxim I have just noticed that I've misused autoconf stuff (used wrong version)

Re: [PATCH 1/7] Libsanitizer merge from upstream r249633.

On 10/14/2015 12:34 PM, Maxim Ostapenko wrote: On 14/10/15 10:54, Jakub Jelinek wrote: Do you plan to update the asan tests we have to reflect the changes in upstream? Hm, there aren't changes into instrumentation, so the only thing is new interceptors. If it is desirable, I can migrate some t

Re: [PATCH] Fix default_binds_local_p_2 for extern protected data

On 30/09/15 20:23, Andreas Krebbel wrote: On 09/30/2015 06:21 PM, Szabolcs Nagy wrote: On 30/09/15 14:47, Bernd Schmidt wrote: On 09/17/2015 11:15 AM, Szabolcs Nagy wrote: ping 2. this patch is needed for working visibility ("protected") attribute for extern data on targets using default_bind

Re: Move some bit and binary optimizations in simplify and match

On Wed, Oct 14, 2015 at 7:39 AM, Marc Glisse wrote: > > +(simplify > + (plus (convert? @0) (convert? (xdivamulminusa @0 @1))) > + (if ((INTEGRAL_TYPE_P (type) || VECTOR_INTEGER_TYPE_P (type)) > + && tree_nop_conversion_p (type, TREE_TYPE (@0))) > + (trunc_mod (convert @0) (convert @1

Re: [PATCH] Allow FSM to thread single block cases too

On Tue, Oct 13, 2015 at 2:52 PM, Richard Biener wrote: > On Tue, Oct 13, 2015 at 2:21 PM, Jeff Law wrote: >> >> One of the cases that was missing in the FSM support is threading when the >> path is a single block. ie, a control statement's output can be statically >> determined just by looking a

Re: Move some bit and binary optimizations in simplify and match

On Wed, 14 Oct 2015, Richard Biener wrote: +/* Fold (a * (1 << b)) into (a << b) */ +(simplify + (mult:c @0 (convert? (lshift integer_onep@1 @2))) + (if (! FLOAT_TYPE_P (type) +&& tree_nop_conversion_p (type, TREE_TYPE (@2))) + (lshift @0 (convert @2 You don't need/want to conve

Re: [vec-cmp, patch 4/6] Support vector mask invariants

2015-10-14 11:49 GMT+03:00 Richard Biener : > On Tue, Oct 13, 2015 at 4:52 PM, Ilya Enkovich wrote: >> I don't understand what you mean. vect_get_vec_def_for_operand has two >> changes made. >> 1. For boolean invariants use build_same_sized_truth_vector_type >> instead of get_vectype_for_scalar_ty

Re: [PATCH 7/7] Libsanitizer merge from upstream r249633.

On 14/10/15 10:48, Jakub Jelinek wrote: On Tue, Oct 13, 2015 at 02:22:36PM +0300, Maxim Ostapenko wrote: This is the final patch. Force libsanitizer to use an old ABI for ubsan float cast data descriptors, because for some exprs (e.g. that type of tcc_declaration) we can't get the right location

Re: Move some bit and binary optimizations in simplify and match

On Wed, Oct 14, 2015 at 12:45 PM, Marc Glisse wrote: > On Wed, 14 Oct 2015, Richard Biener wrote: > >>> +/* Fold (a * (1 << b)) into (a << b) */ >>> +(simplify >>> + (mult:c @0 (convert? (lshift integer_onep@1 @2))) >>> + (if (! FLOAT_TYPE_P (type) >>> +&& tree_nop_conversion_p (type, TR

Re: [PATCH 7/7] Libsanitizer merge from upstream r249633.

On Wed, Oct 14, 2015 at 01:51:44PM +0300, Maxim Ostapenko wrote: > Ok, got it. The first solution would require changes in libsanitizer because > heuristic doesn't work for GCC, so perhaps new UBSan entry point should go > upstream, right? Or this may be implemented as local patch for GCC? No. Th

Re: [vec-cmp, patch 2/6] Vectorization factor computation

2015-10-13 16:37 GMT+03:00 Richard Biener : > On Thu, Oct 8, 2015 at 4:59 PM, Ilya Enkovich wrote: >> Hi, >> >> This patch handles statements with boolean result in vectorization factor >> computation. For comparison its operands type is used instead of restult >> type to compute VF. Other boo

Re: Move some bit and binary optimizations in simplify and match

On Wed, 14 Oct 2015, Richard Biener wrote: On Wed, Oct 14, 2015 at 12:45 PM, Marc Glisse wrote: On Wed, 14 Oct 2015, Richard Biener wrote: +/* Fold (a * (1 << b)) into (a << b) */ +(simplify + (mult:c @0 (convert? (lshift integer_onep@1 @2))) + (if (! FLOAT_TYPE_P (type) +&& tree_n

Re: [gomp4] privatize internal array variables introduced by the fortran FE

Dear Cesar, > > Is there any reason why only certain arrays have array descriptors? The > arrays with descriptors don't have this problem. It's only the ones > without descriptors that leak new internal variables that cause errors > with default(none). > This is an obvious question to which there

Re: [PATCH 7/7] Libsanitizer merge from upstream r249633.

On 14/10/15 14:06, Jakub Jelinek wrote: On Wed, Oct 14, 2015 at 01:51:44PM +0300, Maxim Ostapenko wrote: Ok, got it. The first solution would require changes in libsanitizer because heuristic doesn't work for GCC, so perhaps new UBSan entry point should go upstream, right? Or this may be impleme

Re: libgomp testsuite: Remove some explicit acc_device_nvidia usage

On 10/09/2015 05:11 PM, Thomas Schwinge wrote: On Wed, 22 Jul 2015 16:39:54 +0200, I wrote: [...] cleanup; committed to gomp-4_0-branch in r226072: [...] OK for trunk? I think all three patches here look OK. Bernd

Re: [vec-cmp, patch 3/6] Vectorize comparison

2015-10-13 16:45 GMT+03:00 Richard Biener : > On Thu, Oct 8, 2015 at 5:03 PM, Ilya Enkovich wrote: >> Hi, >> >> This patch supports comparison statements vectrization basing on introduced >> optabs. >> >> Thanks, >> Ilya >> -- >> gcc/ >> >> 2015-10-08 Ilya Enkovich >> >> * tree-vect-da

Re: [PR libgomp/65437, libgomp/66518] Initialize runtime in acc_update_device, acc_update_self

On 10/09/2015 05:14 PM, Thomas Schwinge wrote: Hi! On Fri, 19 Jun 2015 09:47:41 +0200, I wrote: On Tue, 5 May 2015 11:43:20 +0200, I wrote: On Mon, 4 May 2015 10:20:14 -0400, John David Anglin wrote: FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/lib-42.c -DACC_DEVICE_TYPE_hos t=1 -DACC_

Re: [PATCH 7/7] Libsanitizer merge from upstream r249633.

On Wed, Oct 14, 2015 at 03:02:22PM +0300, Maxim Ostapenko wrote: > On 14/10/15 14:06, Jakub Jelinek wrote: > >On Wed, Oct 14, 2015 at 01:51:44PM +0300, Maxim Ostapenko wrote: > >>Ok, got it. The first solution would require changes in libsanitizer because > >>heuristic doesn't work for GCC, so perh

Re: [PATCH] Optimize const1 * copysign (const2, y) in reassoc (PR tree-optimization/67815)

On Wed, Oct 14, 2015 at 11:10:38AM +0200, Richard Biener wrote: > > + FOR_EACH_VEC_ELT (*ops, i, oe) > > +{ > > + if (TREE_CODE (oe->op) == SSA_NAME) > > I think you need to check whether the SSA_NAME has a single use only > as you are changing its value. Which also means you shouldn't

[PATCH][ARM] PR target/67929 Tighten vfp3_const_double_for_bits checks

Hi all, This patch fixes the referenced PR by rewriting the vfp3_const_double_for_bits function in arm.c The function is supposed to accept positive CONST_DOUBLE rtxes whose value is an exact power of 2 and whose log2 is between 1 and 32. That is values like 2.0, 4.0, 8.9, 16.0 etc... The cur

[PATCH][ARM][4.9/5 Backport] PR target/67929 Tighten vfp3_const_double_for_bits checks

Hi all, This is the 4.9 and GCC 5 version of the patch I posted earlier to fix the referenced PR. Bootstrapped and tested arm-none-linux-gnueabihf on those branches. Ok for the branches? Thanks, Kyrill 2015-10-12 Kyrylo Tkachov PR target/67929 * config/arm/arm.c (vfp3_const_double

[PATCH][AArch64] Enable fusion of AES instructions

Enable instruction fusion of dependent AESE; AESMC and AESD; AESIMC pairs. This can give up to 2x speedup on many AArch64 implementations. Also model the crypto instructions on Cortex-A57 according to the Optimization Guide. Passes regression tests. ChangeLog: 2015-10-14 Wilco Dijkstra

Re: [PATCH, VECTOR ABI] Add __attribute__((__simd__)) to GCC.

Hello, On 07 Oct 11:09, Jeff Law wrote: > On 10/05/2015 07:24 AM, Joseph Myers wrote: > >On Mon, 5 Oct 2015, Kirill Yukhin wrote: > > > >>To enable vectorization of loops w/ calls to math functions it is reasonable > >>to enable parsing of attribute vector for functions unconditionally and > >>chan

Re: [PATCH] Allow FSM to thread single block cases too

On 10/14/2015 04:16 AM, Richard Biener wrote: On Tue, Oct 13, 2015 at 2:52 PM, Richard Biener wrote: On Tue, Oct 13, 2015 at 2:21 PM, Jeff Law wrote: One of the cases that was missing in the FSM support is threading when the path is a single block. ie, a control statement's output can be st

Re: [PATCH] Optimize const1 * copysign (const2, y) in reassoc (PR tree-optimization/67815)

On Wed, 14 Oct 2015, Marek Polacek wrote: > On Wed, Oct 14, 2015 at 11:10:38AM +0200, Richard Biener wrote: > > > + FOR_EACH_VEC_ELT (*ops, i, oe) > > > +{ > > > + if (TREE_CODE (oe->op) == SSA_NAME) > > > > I think you need to check whether the SSA_NAME has a single use only > > as you

Re: [PATCH] Allow FSM to thread single block cases too

On Wed, Oct 14, 2015 at 2:42 PM, Jeff Law wrote: > On 10/14/2015 04:16 AM, Richard Biener wrote: >> >> On Tue, Oct 13, 2015 at 2:52 PM, Richard Biener >> wrote: >>> >>> On Tue, Oct 13, 2015 at 2:21 PM, Jeff Law wrote: One of the cases that was missing in the FSM support is threadi

Re: Benchmarks of v2 (was Re: [PATCH 0/5] RFC: Overhaul of diagnostics (v2))

Hi, On Wed, 14 Oct 2015, Richard Biener wrote: > The compile-time and memory-usage impact for the adhocloc at every token > patchkit is quite big. Remember that gaining 1% in compile-time is hard > and 20-40% memory increase for influence.i looks too much. Yes. OTOH the compile time and memo

Re: [PATCH] Allow FSM to thread single block cases too

On 10/14/2015 06:46 AM, Richard Biener wrote: This or other related patches in the range r228731:228774 has caused a quite big jump in SPEC CPU 2000 binary sizes (notably 176.gcc - so maybe affecting bootstrap as well, at -O3). Are you sure this doesn't re-introduce DOM effectively peeling all l

[PATCH] Fix PR67915

The following removes GENERIC folding from cleanup_control_expr_graph in favor of GIMPLE one. This likely doesn't solve the underlying issue of PR67915 fully but using const_binop as I originally wanted doesn't catch all cases fold_binary did because stmts that were previously folded get non-fold

[gomp4] More deferral of partitioning to target

I've committed this to gomp4 branch. It is another step towards deferring partitioned execution choices to the target compiler -- though sadly not the last step. At early omp lowering, we now attach partitioning flags to the HEAD_MARK function I introduced yesterday, and adjust the partitio

Re: [PATCH, VECTOR ABI] Add __attribute__((__simd__)) to GCC.

On Wed, 14 Oct 2015, Kirill Yukhin wrote: > Is it ok for trunk? This patch has no documentation. Documentation for new attributes must be added to extend.texi. > Enables creation of one or more versions that can process multiple > arguments using SIMD instructions from a single invocation fro

Re: [PATCH v2] PR rtl-optimization/66790: uninitialized registers handling in REE

On 10/13/2015 05:17 PM, Pierre-Marie de Rodat wrote: The first attached patch is the second attempt to fix PR rtl-optimization/66790 (see ). The second one is a fix for some inconsistency noticed while working on the original bug. This specific

[PATCH] More vectorizer TLC

This removes superfluous parameters from some analysis helpers. Bootstrapped and tested on x86_64-unknown-linux-gnu, applied. Richard. 2015-10-14 Richard Biener * tree-vectorizer.h (vect_is_simple_use): Remove unused parameters. (vect_is_simple_use_1): Likewise. Make overlo

Re: [patch] header file re-ordering.

On 10/12/2015 04:04 AM, Jeff Law wrote: <...> raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:423 ../gcc-interface/Makefile:311: recipe for target 's-regpat.o' failed However, the tool has been run, and I've made the minor adjustments required to the source files to make it work. (ie, a few m

[committed] Improve reassoc-39.c test

Jakub suggested that I improve a testcase I've added a while ago. Done in the following. Tested on x86_64-linux, applying to trunk. 2015-10-14 Marek Polacek * gcc.dg/tree-ssa/reassoc-39.c: Use -g. Adjust dg-final. (f6): New. (f7): New. (f8): New. (f9):

Re: [PATCH] c/67925 - update documentation on `inline'

On 10/13/2015 04:47 PM, Arkadiusz Drabczyk wrote: * gcc/doc/extend.texi: documentation says that functions declared `inline' would not be integrated if they are called before they are defined or if they are recursive. Both of these statements is now false as shown in examples on Bugzilla. It mi

[gomp4, committed] Backported param parloops-schedule

[ was: Re: [PATCH, 3/5] Handle original loop tree in expand_omp_for_generic ] On 13/10/15 23:48, Thomas Schwinge wrote: Hi Tom! On Mon, 12 Oct 2015 18:56:29 +0200, Tom de Vries wrote: >Handle original loop tree in expand_omp_for_generic > >2015-09-12 Tom de Vries > >PR tree-optimization

[AArch64] --with-arch in config.gcc support "."

Since armv8.1 added, we need to improve --with-arch recognition sed pattern to catch the new "." in the architecture base name. OK for trunk? 2015-10-14 Jiong Wang gcc/ * config.gcc: Recognize "." in architecture base name for AArch64. diff --git a/gcc/config.gcc b/gcc/config.gcc index 58

[PATCH] Fix pr67963

Hi, This patch fixes the issue: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67963 gcc/config/i386/i386.c (ix86_option_override_internal) Disable 80387 mask if lakemont target is set. diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c index 4c25c9e..db722aa 100644 --- a/gcc/confi

Re: [patch 4/3] Header file reduction - Tools for contrib - second cut

Here's the latest version of the tools for a sub directory in contrib. I've handled all the feedback, except I have not fully commented the python code in the tools, nor followed any particular coding convention... Documentation has been handled, and I've added some additional comments to t

Re: [PATCH] Fix pr67963

On Wed, Oct 14, 2015 at 8:08 AM, Yulia Koval wrote: > Hi, > > This patch fixes the issue: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67963 > > gcc/config/i386/i386.c (ix86_option_override_internal) Disable > 80387 mask if lakemont target is set. > > diff --git a/gcc/config/i386/i386.c b/

Re: [PATCH] Fix pr67963

On Wed, Oct 14, 2015 at 8:15 AM, H.J. Lu wrote: > On Wed, Oct 14, 2015 at 8:08 AM, Yulia Koval wrote: >> Hi, >> >> This patch fixes the issue: >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67963 >> >> gcc/config/i386/i386.c (ix86_option_override_internal) Disable >> 80387 mask if lakemont

Re: [PATCH 8/9] Add TARGET_ADDR_SPACE_ZERO_ADDRESS_VALID

On 10/13/2015 02:59 PM, Richard Henderson wrote: On 10/14/2015 02:49 AM, Jeff Law wrote: The problem here is we don't know what address space the *0 is going to hit, right? Correct, not before we do the walk of stmt to see what's present. So the address space information isn't part of the addr

Re: [patch 0/6] scalar-storage-order merge (2)

On Tue, Oct 13, 2015 at 07:32:08PM +0200, Eric Botcazou wrote: > > My main question about this series is - how generally useful do you > > expect it to be? I know of some different projects that would like > > bi-endian capability, but it looks like this series implements something > > that is a li

Re: [AArch64] --with-arch in config.gcc support "."

Jiong Wang writes: > diff --git a/gcc/config.gcc b/gcc/config.gcc > index 5818663..215ad9a 100644 > --- a/gcc/config.gcc > +++ b/gcc/config.gcc > @@ -3544,7 +3544,7 @@ case "${target}" in > > eval "val=\$with_$which" > base_val=`echo $val | sed -e 's/

Re: [PATCH 8/9] Add TARGET_ADDR_SPACE_ZERO_ADDRESS_VALID

On 10/14/2015 03:19 AM, Richard Biener wrote: On Tue, Oct 13, 2015 at 10:59 PM, Richard Henderson wrote: On 10/14/2015 02:49 AM, Jeff Law wrote: The problem here is we don't know what address space the *0 is going to hit, right? Correct, not before we do the walk of stmt to see what's pres

Re: [patch 0/6] scalar-storage-order merge (2)

On 10/14/2015 09:25 AM, Trevor Saunders wrote: I haven't looked at the C++ changes, but I tend to think they mat may be the language where this is the least useful. I expect it would be pretty "trivial" to write some wrapper classes that use bswap in operators so you could say things like struc

Re: [PATCH] Allow FSM to thread single block cases too

> >>> I think he asked for trivial forward threads though due to repeated > >>> tests. > >>> I hacked FRE to do this (I think), but maybe some trivial cleanup > >>> opportunities > >>> are still left here. Honza? Well, unthreaded jumps quite confuse profile prediction and create profiles that we

[gomp4.5] Support for monotonic and nonmonotonic schedule modifiers

Hi! I've created gomp-4_5-branch in svn, where further OpenMP 4.5 development will happen. The following patch which I've committed there (and after a while plan to merge to trunk together with other smaller changes) adds support for monotonic and nonmonotonic schedule modifiers. The older versi

Re: [PATCH] Allow FSM to thread single block cases too

On 10/14/2015 09:43 AM, Jan Hubicka wrote: I think he asked for trivial forward threads though due to repeated tests. I hacked FRE to do this (I think), but maybe some trivial cleanup opportunities are still left here. Honza? Well, unthreaded jumps quite confuse profile prediction and create p

[patch] Minor adjustment to gimplify_addr_expr

TED==+ | Pro 7.4.0w (20151014-60) (x86_64-suse-linux) GCC error: | | tree check: expected class 'expression', have | | 'exceptional' (ssa_name) in tree_operand_check, at tree.h:3431| | Error detected around c37213k.adb:95:37 It's recompute_

Re: [vec-cmp, patch 3/6] Vectorize comparison

On 14 Oct 15:06, Ilya Enkovich wrote: > > Will send an updated version after testing. > > Thanks, > Ilya > Here is an updated patch version. Thanks, Ilya -- gcc/ 2015-10-14 Ilya Enkovich * tree-vect-data-refs.c (vect_get_new_vect_var): Support vect_mask_var. (vect_create_d

Re: [vec-cmp, patch 4/6] Support vector mask invariants

On 14 Oct 13:50, Ilya Enkovich wrote: > 2015-10-14 11:49 GMT+03:00 Richard Biener : > > On Tue, Oct 13, 2015 at 4:52 PM, Ilya Enkovich > > wrote: > >> I don't understand what you mean. vect_get_vec_def_for_operand has two > >> changes made. > >> 1. For boolean invariants use build_same_sized_trut

[PATCH] PR middle-end/67220: GCC fails to properly handle libcall symbol visibility of built functions

By default, there is no visibility on builtin functions. When there is explicitly declared visibility on the C library function which a builtin function fall back on, we should honor the explicit visibility on the the C library function. There are 2 issues: 1. We never update visibility of the f

Re: [PATCH 5/7] Libsanitizer merge from upstream r249633.

On 14/10/15 10:37, Jakub Jelinek wrote: On Tue, Oct 13, 2015 at 02:20:06PM +0300, Maxim Ostapenko wrote: This patch removes UBSan stubs from ASan and TSan code. We don't embed UBSan to ASan and UBSan because that would lead to undefined references to C++ stuff when linking with -static-libasan.

Handle CONSTRUCTOR in operand_equal_p

Hi, this patch adds the CONSTRUCTOR case discussed while back. Only empty constructors are matched, as those are only appearing in gimple operand. I tested that during bootstrap about 7500 matches are for empty ctors. There are couple hundred for non-empty probably used on generic. Bootstrapped/

Add VIEW_CONVERT_EXPR to operand_equal_p

Hi, this patch adds VIEW_CONVERT_EXPR which is another code omitted in operand_equal_p. During bootstrap there are about 1000 matches. Bootstrapped/regtested x86_64-linux, OK? Honza * fold-const.c (operand_equal_p): Handle VIEW_CONVERT_EXPR. Index: fold-const.c =

Re: [PATCH] PR middle-end/67220: GCC fails to properly handle libcall symbol visibility of built functions

On Wed, Oct 14, 2015 at 5:21 PM, H.J. Lu wrote: > --- > gcc/c/ > > PR middle-end/67220 > * c-decl.c (diagnose_mismatched_decls): Copy explicit visibility > to builtin function. > > gcc/ > > PR middle-end/67220 > * expr.c (init_block_move_fn): Copy visibilit

PR67945: Fix oscillation between pow representations

This patch fixes some fallout from my patch to move the sqrt and cbrt folding rules to match.pd. The rules included canonicalisations like: sqrt(sqrt(x))->pow(x,1/4) which in the original code was only ever done at the generic level. My patch meant that we'd do it whenever we tried to fold a

Re: [PATCH] PR middle-end/67220: GCC fails to properly handle libcall symbol visibility of built functions

On Wed, Oct 14, 2015 at 9:46 AM, Ramana Radhakrishnan wrote: > On Wed, Oct 14, 2015 at 5:21 PM, H.J. Lu wrote: > >> --- >> gcc/c/ >> >> PR middle-end/67220 >> * c-decl.c (diagnose_mismatched_decls): Copy explicit visibility >> to builtin function. >> >> gcc/ >> >>

[PATCH] [PR testsuite/67959]Minor cleanup for ssa-thread-13.c

The enum rtx_code bitfield causes grief for arm-eabi. Given the test doesn't actually care about the size of that field, the easiest fix was just to make it a simple integer. Tested on both x86_64-linux-gnu and arm-eabi to ensure the updated test passes on both targets. Installed on the t

[gomp4] remove dead code

I've committed this to gomp4 branch. It removes some now unreachable code and removes the now bogus description about OpenACC. nathan 2015-10-14 Nathan Sidwell * omp-low.c (lower_reduction_clauses): Correct comment, remove unreachable code. Index: gcc/omp-low.c ==

[PATCH] Split ssa-dom-thread-2.c into separate files/tests

ssa-dom-thread-2.c is actually 6 distinct tests crammed into a single file. That's normally not a huge problem, but it can make tests hard to write when we're scanning dumps. This patch splits it into 6 distinct tests. ssa-dom-thread-2[a-f].c. It also tightens the expected output slightly

[PATCH] print help for undocumented options

Gcc's online help (the output of gcc --help -v) includes a large number of undocumented options (197 in 5.1.0). For example, the section listing language-related options starts with the following and another 44 or so undocumented options: The following options are language-related: --all-w

Re: [PATCH] PR middle-end/67220: GCC fails to properly handle libcall symbol visibility of built functions

On Wed, Oct 14, 2015 at 5:51 PM, H.J. Lu wrote: > On Wed, Oct 14, 2015 at 9:46 AM, Ramana Radhakrishnan > wrote: >> On Wed, Oct 14, 2015 at 5:21 PM, H.J. Lu wrote: >> >>> --- >>> gcc/c/ >>> >>> PR middle-end/67220 >>> * c-decl.c (diagnose_mismatched_decls): Copy explicit visibili

Re: [PATCH] print help for undocumented options

On Wed, 14 Oct 2015, Martin Sebor wrote: > + /* For undocumented options that are aliases for other > +options that are documented, print the other option's > +help and name. */ > + help = cl_options [option->alias_target].help; > + > +

Re: Handle CONSTRUCTOR in operand_equal_p

On 10/14/2015 10:27 AM, Jan Hubicka wrote: Hi, this patch adds the CONSTRUCTOR case discussed while back. Only empty constructors are matched, as those are only appearing in gimple operand. I tested that during bootstrap about 7500 matches are for empty ctors. There are couple hundred for non-em

Re: [patch] Minor adjustment to gimplify_addr_expr

NAT BUG DETECTED==+ | Pro 7.4.0w (20151014-60) (x86_64-suse-linux) GCC error: | | tree check: expected class 'expression', have | | 'exceptional' (ssa_name) in tree_operand_check, at tree.h:3431| | Error detected a

Re: [Patch PR target/67366 2/2] [gimple-fold.c] Support movmisalign optabs in gimple-fold.c

On 10/08/2015 08:10 AM, Ramana Radhakrishnan wrote: This patch by Richard allows for movmisalign optabs to be supported in gimple-fold.c. This caused a bit of pain in the testsuite with strlenopt-8.c in conjunction with the ARM support for movmisalign_optabs as the test was coded up to do differe

Re: Handle CONSTRUCTOR in operand_equal_p

> On 10/14/2015 10:27 AM, Jan Hubicka wrote: > >Hi, > >this patch adds the CONSTRUCTOR case discussed while back. Only empty > >constructors are matched, as those are only appearing in gimple operand. > >I tested that during bootstrap about 7500 matches are for empty ctors. > >There are couple hun

Re: using scratchpads to enhance RTL-level if-conversion: revised patch

On 10/13/2015 02:16 PM, Bernd Schmidt wrote: _Potentially_ so, yes. However, GCC is free to put the allocation into an otherwise-unused part of the stack frame. Well, I looked at code generation changes, and it usually seems to come with an increase in stack frame size - sometimes causing extr

Re: using scratchpads to enhance RTL-level if-conversion: revised patch

On 10/14/2015 02:28 AM, Eric Botcazou wrote: If you're using one of the switches that checks for stack overflow at the start of the function, you certainly don't want to do any such stores. There is a protection area for -fstack-check (STACK_CHECK_PROTECT bytes) so you can do stores just below

[PATCH] Fix accounting for num_threaded_edges

tree-ssa-threadupdate.c keeps running total of the number of edges it threads. Those totals are useful debugging tools and are also examined by the testsuite. While looking at the effects of using the FSM threader on ssa-dom-thread-2?.c I noticed the counters weren't being updated properl

Re: [PATCH 1/7] Libsanitizer merge from upstream r249633.

On 14-10-2015 04:54, Jakub Jelinek wrote: > On Tue, Oct 13, 2015 at 07:54:33PM +0300, Maxim Ostapenko wrote: >> On 13/10/15 14:15, Maxim Ostapenko wrote: >>> This is the raw merge itself. I'm bumping SONAME to libasan.so.3. >>> >>> -Maxim >> >> I have just noticed that I've misused autoconf stuff

Re: [PATCH 1/7] Libsanitizer merge from upstream r249633.

On Wed, Oct 14, 2015 at 11:03 AM, Adhemerval Zanella wrote: > > > On 14-10-2015 04:54, Jakub Jelinek wrote: >> On Tue, Oct 13, 2015 at 07:54:33PM +0300, Maxim Ostapenko wrote: >>> On 13/10/15 14:15, Maxim Ostapenko wrote: This is the raw merge itself. I'm bumping SONAME to libasan.so.3.

Re: [PATCH] print help for undocumented options

On 10/14/2015 11:24 AM, Joseph Myers wrote: On Wed, 14 Oct 2015, Martin Sebor wrote: + /* For undocumented options that are aliases for other +options that are documented, print the other option's +help and name. */ + help = cl_options [o

[PATCH] Fix wrong-code when folding X - (X / Y) * Y (PR tree-optimization/67953)

Evidently, the X - (X / Y) * Y -> X % Y pattern can't change the signedness of X from signed to unsigned, otherwise we'd generate wrong code. (But unsigned -> signed should be fine.) Does anyone see a better fix than this? Bootstrapped/regtested on x86_64-linux, ok for trunk? 2015-10-14 Marek

Re: [PATCH 1/7] Libsanitizer merge from upstream r249633.

On 14 October 2015 at 19:21, Evgenii Stepanov wrote: > Wait. As Jakub correctly pointed out in the other thread, there is no > obvious reason why there could not be a single shadow offset value > that would work for all 3 possible VMA settings. I suggest figuring > this out first. We are. cheers

Re: Handle CONSTRUCTOR in operand_equal_p

On October 14, 2015 6:27:02 PM GMT+02:00, Jan Hubicka wrote: >Hi, >this patch adds the CONSTRUCTOR case discussed while back. Only empty >constructors are matched, as those are only appearing in gimple >operand. >I tested that during bootstrap about 7500 matches are for empty ctors. >There are co

Re: [PATCH] Fix wrong-code when folding X - (X / Y) * Y (PR tree-optimization/67953)

On October 14, 2015 8:27:31 PM GMT+02:00, Marek Polacek wrote: >Evidently, the X - (X / Y) * Y -> X % Y pattern can't change the >signedness of X from signed to unsigned, otherwise we'd generate >wrong code. (But unsigned -> signed should be fine.) > >Does anyone see a better fix than this? > >B

  1   2   >