[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

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" >

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

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

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

[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

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

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

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

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. >

[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

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

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

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

[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_tree_invariant_for_addr_e

[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 ---

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

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

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: 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 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: 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

[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

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

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

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

[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

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

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

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.

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 >>

[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

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

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

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

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

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.

[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

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

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

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.

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

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. >

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,

[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. *

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

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

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

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 >

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

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,

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

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,

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

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

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

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

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

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: [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

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

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:

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

On Wed, Oct 14, 2015 at 11:38 AM, Renato Golin wrote: > 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

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

On 14 October 2015 at 20:00, Andrew Pinski wrote: > Then until that happens I think we should disable asan and tsan for > AARCH64 for GCC. I can't comment on that, but we'll continue running the tests on our side on both 39 and 42 VMA configurations, to make sure we don't

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

On Wed, Oct 14, 2015 at 12:15 PM, Renato Golin wrote: > On 14 October 2015 at 20:00, Andrew Pinski wrote: >> Then until that happens I think we should disable asan and tsan for >> AARCH64 for GCC. > > I can't comment on that, but we'll continue running

Re: [PATCH] print help for undocumented options

On Wed, 14 Oct 2015, Martin Sebor wrote: > IMO, printing the aliased option's help text makes using the output > easier for users who find the undocumented option first, in that > they don't then have to go look for the one that does have > documentation, so I left that part in place. If you or

Re: Do not use TYPE_CANONICAL in useless_type_conversion

On Oct 14, 2015, Jan Hubicka wrote: >> On Oct 13, 2015, Eric Botcazou wrote: >> >> > Note that this is PR middle-end/67912. >> >> Thanks. I added this piece of information to the ChangeLog entry, and >> checked the patch in. > Thanks, Alexandre. That

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

On Wed, 14 Oct 2015, 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? I was wondering about

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

On 10/14/2015 07:43 PM, Jeff Law wrote: Obviously some pessimization relative to current code is necessary to fix some of the problems WRT thread safety and avoiding things like introducing faults in code which did not previously fault. Huh? This patch is purely an (attempt at) optimization,

[PATCH, i386]: Fix PR 67967, ICE in i386_pe_seh_unwind_emit

Attached patch fixes PR 67967, where we emit REG_CFA_EXPRESSION, attached to aligned SSE store. This is unnecessary, and confuses SEH targets. 2015-10-14 Uros Bizjak PR target/67967 * config/i386/i386.c (ix86_emit_save_reg_using_mov): Do not add

RE: [PATCH, mips]: Use ROUND_UP and ROUND_DOWN macros

Uros Bizjak writes: > Fairly trivial patch that introduces no functional changes. > > * config/mips/mips.h (MIPS_STACK_ALIGN): Implement using > ROUND_UP macro. > * config/mips/mips.c (mips_setup_incoming_varargs): Use > ROUND_DOWN to calculate off. >

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

On Wed, Oct 14, 2015 at 08:36:43AM -0600, Martin Sebor wrote: > 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

Re: [patch] Minor adjustment to gimplify_addr_expr

On 10/14/2015 02:57 PM, Eric Botcazou wrote: Can you use the TMR_OFFSET macro rather than TREE_OPERAND (op0, 1)? It also seems that you need a stronger check here. Essentially you have to verify that STEP * INDEX + INDEX2 + OFFSET == 0 Right? No, it's MEM_REF, not TARGET_MEM_REF, see

Re: [PATCH 8/9] Add TARGET_ADDR_SPACE_ZERO_ADDRESS_VALID

On 10/14/2015 08:22 PM, Richard Biener wrote: I think you could trigger bogus CSE of dereferences of literal addresses from different address-spaces. Good catch. You're spot on with that. r~ int test(void) { int __seg_fs *f = (int __seg_fs *)16; int __seg_gs *g = (int __seg_gs *)16;

Re: [PATCH, mips]: Use ROUND_UP and ROUND_DOWN macros

On Wed, Oct 14, 2015 at 11:38 PM, Matthew Fortune wrote: > Uros Bizjak writes: >> Fairly trivial patch that introduces no functional changes. >> >> * config/mips/mips.h (MIPS_STACK_ALIGN): Implement using >> ROUND_UP macro. >> *

Re: [PATCH, rs6000] Add memory barriers to tbegin, tend, etc.

On Fri, 2015-10-09 at 22:19 +0200, Torvald Riegel wrote: > On Fri, 2015-10-09 at 11:52 -0500, Peter Bergner wrote: >> Thanks for the review! I've attached the changes to the documentation below. >> Is this better? > > Yes, thanks! Great, thanks! This is committed a revision 228827. I'm just

Re: [PATCH 1/3] [ARM] PR63870 Add qualifiers for NEON builtins

On 12 October 2015 at 11:58, Alan Lawrence wrote: > On 07/10/15 00:59, charles.bay...@linaro.org wrote: >> >> diff --git a/gcc/config/arm/arm-builtins.c b/gcc/config/arm/arm-builtins.c > > ... >> >> case NEON_ARG_MEMORY: >> /* Check if expand

Re: [patch] Minor adjustment to gimplify_addr_expr

> Can you use the TMR_OFFSET macro rather than TREE_OPERAND (op0, 1)? > > It also seems that you need a stronger check here. > > Essentially you have to verify that > STEP * INDEX + INDEX2 + OFFSET == 0 > > Right? No, it's MEM_REF, not TARGET_MEM_REF, see build_fold_addr_expr_with_type_loc.

Re: [PATCH] New attribute to create target clones

Bootstrap and make check for x86 passed. No new fails. Please ignore an empty line added to omp-low.c in the patch, the misprint will be removed prior to a commit. Thanks, Evgeny On Tue, Oct 13, 2015 at 2:35 AM, Evgeny Stupachenko wrote: > Hi All, > > Here is a new version

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

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.

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

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

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

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) >>> +&&

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

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

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

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

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

On 10/14/2015 03:42 PM, Arkadiusz Drabczyk wrote: On Wed, Oct 14, 2015 at 08:36:43AM -0600, Martin Sebor wrote: 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

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/ >> >>

[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

[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: [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

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

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

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

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 >

  1   2   >