Re: Do not use TYPE_CANONICAL in useless_type_conversion

> There must be a reason why I allowed modes to differ there btw ;) Thinking about it, I guess reason is that incomplete types do not have resonable modes set, so requiring modes to match will prevent complete and incomplete types to match. Here is updated patch which uses the earlier mode check

[PATCH] outline functions from stmt_simple_for_scop_p

From: hiraditya Outlined functions from stmt_simple_for_scop_p. No functional changes intended. Passes regtest and bootstrap. gcc/ChangeLog: 2015-10-01 Aditya Kumar * graphite-scop-detection.c (stmt_has_side_effects): New function outlined from stmt_simple_for_scop_p.

[patch 3/3] Header file reduction - FE files.

141 front end files.. all in subdirectories of gcc. Everything bootstraps an a x86_64-pc-linux-gnu and powerpc64le-unknown-linux-gnu with --enable-languages=all,ada,go,obj-c++,jit --enable-host-shared. All targets in config-list.mk still build. Regressions tests also came up clean. OK for

[patch 1/3] Header file reduction - backend files.

these are all in the main gcc directory. 297 files total. Everything bootstraps on x86_64-pc-linux-gnu and powerpc64le-unknown-linux-gnu. All targets in config-list.mk still build. Regressions tests also came up clean. OK for trunk? Andrew backend.patch.bz2 Description: application/bzip

[patch 2/3] Header file reduction - config files.

there are most of the config files... 109 files total. I built every target in config-list.mk. The reduction tool reduced each source file by examining *every* target object directory for the resulting object, and testing the reduction each of those targets. This took a long time to run

[patch 0/3] Header file reduction.

OK, newly regenerated patches to remove header files from the latest version of the tools. The patches are generated by a pair of tools. * gcc-order-includes goes through the headers and canonically reorders some of our more common/troublesome headers and removes any duplicates. This includes

Re: [PATCH] SH FDPIC backend support

On Thu, Oct 01, 2015 at 07:39:10PM -0400, Rich Felker wrote: > On Fri, Oct 02, 2015 at 07:36:27AM +0900, Oleg Endo wrote: > > On Thu, 2015-10-01 at 17:35 -0400, Rich Felker wrote: > > > This is a forward-port of the abandoned SH FDPIC patch from 2010: > > > > > > https://gcc.gnu.org/ml/gcc-patches

Re: [PATCH] rs6000: Add "cannot_copy" attribute, use it (PR67788, PR67789)

On Fri, Oct 02, 2015 at 10:24:07AM +0930, Alan Modra wrote: > On Thu, Oct 01, 2015 at 12:18:08PM -0500, Segher Boessenkool wrote: > > On Thu, Oct 01, 2015 at 12:14:44PM +0200, Richard Biener wrote: > > > So even if not "easy", can you try? > > > > I did, and after half a day had a big mess and lot

Re: [PATCH] rs6000: Add "cannot_copy" attribute, use it (PR67788, PR67789)

On Thu, Oct 01, 2015 at 12:18:08PM -0500, Segher Boessenkool wrote: > On Thu, Oct 01, 2015 at 12:14:44PM +0200, Richard Biener wrote: > > So even if not "easy", can you try? > > I did, and after half a day had a big mess and lots of things failing, > no idea where this was headed, and in the meant

Re: [patch] libstdc++/67747 Allocate space for dirent::d_name

On 01/10/15 19:38 +0100, Jonathan Wakely wrote: On 01/10/15 18:23 +0100, Jonathan Wakely wrote: +struct op_delete { + void operator()(void* p) const { ::operator delete(p); } +}; +std::unique_ptr<::dirent*, op_delete> ptr; Oops, that should be dirent not dirent* i.e. std::

Re: [PATCH] SH FDPIC backend support

On Fri, Oct 02, 2015 at 07:36:27AM +0900, Oleg Endo wrote: > On Thu, 2015-10-01 at 17:35 -0400, Rich Felker wrote: > > This is a forward-port of the abandoned SH FDPIC patch from 2010: > > > > https://gcc.gnu.org/ml/gcc-patches/2010-08/msg01536.html > > > > I'm submitting it at this point for ini

Re: [PATCH] fortran/67802 -- Numeric constant character length must ...

On Thu, Oct 01, 2015 at 11:19:37PM +0200, Dominique d'Humières wrote: > Without initialization the errors are of the kind: > > Error: Expression at (1) must be of INTEGER type, found * > > see https://gcc.gnu.org/ml/gcc-bugs/2015-10/msg00081.html. Should not we get > the same message with initia

Re: [patch] libstdc++/67747 Allocate space for dirent::d_name

Other than that, I tend to be leery of using plain char arrays as buffers for objects of bigger types. I don't know to what extent this is a problem for libstdc++ anymore as more and more hardware is tolerant of misaligned accesses and as the default new expression typically returns memory suitabl

Re: [PATCH] SH FDPIC backend support

On Thu, 2015-10-01 at 17:35 -0400, Rich Felker wrote: > This is a forward-port of the abandoned SH FDPIC patch from 2010: > > https://gcc.gnu.org/ml/gcc-patches/2010-08/msg01536.html > > I'm submitting it at this point for initial review, not to be applied > right away; I would not be surprised i

Re: [PATCH] Rename gimple_bb to gimple_poly_bb

On 10/01/2015 10:36 PM, Aditya Kumar wrote: From: hiraditya Renaming gimple_bb to gimple_poly_bb because there is a function gimple_bb by the same name in gimple.h. No functional change intended. Passes regtest and bootstrap. LGTM Tobias

Re: [PATCH] use sese_l throughout scop-detection

On 10/01/2015 11:23 PM, Aditya Kumar wrote: From: hiraditya Use sese_l throughout SCoP detection and create vec at the very end when all SCoPs have been identified. 'struct sese_l' is very lightweight (two pointers) compared to 'struct scop'. No functional change intended. Passes regtest and b

[PATCH] SH FDPIC backend support

This is a forward-port of the abandoned SH FDPIC patch from 2010: https://gcc.gnu.org/ml/gcc-patches/2010-08/msg01536.html I'm submitting it at this point for initial review, not to be applied right away; I would not be surprised if some changes are needed. It applies on top of gcc 5.2.0 with the

[PATCH] use sese_l throughout scop-detection

From: hiraditya Use sese_l throughout SCoP detection and create vec at the very end when all SCoPs have been identified. 'struct sese_l' is very lightweight (two pointers) compared to 'struct scop'. No functional change intended. Passes regtest and bootstrap. gcc/ChangeLog: 2015-10-01 Aditya

Re: [PATCH] fortran/67802 -- Numeric constant character length must ...

Without initialization the errors are of the kind: Error: Expression at (1) must be of INTEGER type, found * see https://gcc.gnu.org/ml/gcc-bugs/2015-10/msg00081.html. Should not we get the same message with initialization? Cheers, Dominique

Re: Fold acc_on_device

On 10/01/2015 01:11 PM, Nathan Sidwell wrote: On 10/01/15 13:00, Andrew MacLeod wrote: btw, not that it's necessarily important, but I'm about to submit the include reduction patches today, and it turns out this line is the first use of anything from cgraph.h in builtins.c. So if this is "th

Re: RFA: TM PATCH to volatile checking

On 09/30/2015 11:57 PM, Jason Merrill wrote: commit e946db577784ed4670944dd91e81666af16793b3 Author: Jason Merrill Date: Tue Sep 29 14:43:08 2015 -0400 Diagnose volatile accesses in transaction_safe function. * trans-mem.c (volatile_lvalue_p): Rename from volatile_var_p.

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

Ping. Torvald, David approved the code portion of the patch. How does the documentation part look to you? https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00315.html Peter

Re: [PATCH] fortran/67802 -- Numeric constant character length must ...

> Well, ahem, gfortran does have several error messages that use the > standard notation. I know. I wrote some of them. :-) > > I'll simply change it to "Expecting an INTEGER at %L” Thanks. I have no objections to using the full standard terminology (scalar integer expression), but not the sho

[gomp4] handle missing OMP_LIST_ clauses in fortran's parse tree debugger

While debugging gfortran with -fdump-fortran-*, I noticed that a couple of OMP_LIST_ entries weren't being handled show_omp_clauses so I've added them. I also took advantage of the opportunity to rearrange the the cases in the switch statement that handles those lists in a way that matches the enum

[AARCH64] Add missing entries in iterator vwcore

Hi, In "aarch64_get_lane" operand 0 is VEL, so for %0, iterator vwcore should (?) support all the modes in VEL. Ran into following error with a local patch for an existing test case. However it can also be reproduced with the attached test case. fnction ‘fn1’: t.c:25:1: internal compiler error:

[PATCH] Rename gimple_bb to gimple_poly_bb

From: hiraditya Renaming gimple_bb to gimple_poly_bb because there is a function gimple_bb by the same name in gimple.h. No functional change intended. Passes regtest and bootstrap. gcc/ChangeLog: 2015-10-01 Aditya Kumar Sebastian Pop * graphite-isl-ast-to-gimple.c (cla

Re: [PATCH] Convert SPARC to LRA

On Tue, 2015-09-29 at 09:27 -0500, Peter Bergner wrote: > The first ICE seems to be due to a conversion to long double and LRA ends > up going into a infinite loop spilling things until it hits a threshold and > quits with an ICE. I haven't spent enough time to determine whether this > is a LRA or

Re: [GCC, ARM] armv8 linux toolchain asan testcase fail due to stl missing conditional code

On 1 October 2015 at 11:10, Kyrill Tkachov wrote: > > On 30/09/15 17:39, Kyrill Tkachov wrote: >> >> On 09/06/15 09:17, Kyrill Tkachov wrote: >>> >>> On 05/06/15 14:14, Kyrill Tkachov wrote: On 05/06/15 14:11, Richard Earnshaw wrote: > > On 05/06/15 14:08, Kyrill Tkachov wrote: >

Re: [PATCH] fortran/67802 -- Numeric constant character length must ...

On Thu, Oct 01, 2015 at 09:19:15PM +0200, FX wrote: > > 2015-10-01 Steven G. Kargl > > > > PR fortran/67802 > > * decl.c (add_init_expr_to_sym): Numeric constant for character > > length must be an INTEGER. > > > > 2015-10-01 Steven G. Kargl > > > > PR fortran/67802 > >

Re: [PATCH] fortran/67802 -- Numeric constant character length must ...

> 2015-10-01 Steven G. Kargl > > PR fortran/67802 > * decl.c (add_init_expr_to_sym): Numeric constant for character > length must be an INTEGER. > > 2015-10-01 Steven G. Kargl > > PR fortran/67802 > * gfortran.dg/pr67802.f90: New test. OK, but not with that e

Re: [C++ PATCH] PR c++/54430

OK. Jason

[PATCH] fortran/67802 -- Numeric constant character length must ...

be an integer expression. The attached patch checks that a numerical constant in a CHARACTER(LEN=x) declaration is an integer. Regression tested on x86_64-*-freebsd*. OK to commit? 2015-10-01 Steven G. Kargl PR fortran/67802 * decl.c (add_init_expr_to_sym): Numeric constant

Re: [PATCH] correctly handle non affine data references

On 10/01/2015 06:31 PM, Sebastian Pop wrote: create mode 100644 gcc/testsuite/gcc.dg/graphite/scop-pr66980.c diff --git a/gcc/graphite-scop-detection.c b/gcc/graphite-scop-detection.c LGTM. Tobias

[patch mingw]: Fix PR/51726 - LTO and attribute 'selectany'

Hello, This patch fixes the reported LTO issue, which is caused by not implemented case of uniinitialized variables with selectany-attribute (as common), as such variables couldn't be placed into linkonce-section for pe-coff. I adjusted existing testcase to reflect now supported case of selectany

Re: [PATCH][RTL ifcvt] PR 67786, 67787: Check that intermediate instructions in the basic block don't clobber a reg used in condition

This patch fixes the two wrong-code PRs. The problem is related to the way the noce_emit_cmove helper function emits conditional moves. For some targets it re-emits the comparison from the condition block and then the conditional move after we have emitted the two basic blocks. Later passes always

Re: [PATCH] Clarify __atomic_compare_exchange_n docs

There's a typo in an example too. diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi index ce1b4ae..599ad87 100644 --- a/gcc/doc/extend.texi +++ b/gcc/doc/extend.texi @@ -9471,7 +9471,7 @@ alignment. A value of 0 indicates typical alignment should be used. The compiler may also ignore this

Re: [patch] libstdc++/67747 Allocate space for dirent::d_name

On 01/10/15 18:23 +0100, Jonathan Wakely wrote: +struct op_delete { + void operator()(void* p) const { ::operator delete(p); } +}; +std::unique_ptr<::dirent*, op_delete> ptr; Oops, that should be dirent not dirent* i.e. std::unique_ptr<::dirent, op_delete> ptr; (Found on

Re: [Patch match.pd] Add a simplify rule for x * copysign (1.0, y);

On Thu, Oct 01, 2015 at 02:57:15PM +0100, James Greenhalgh wrote: > 2015-10-01 James Greenhalgh > > * match.pd (mult (COPYSIGN:s real_onep @0) @1): New simplifier. Also, please note that + wide_int m = wi::min_value (TYPE_PRECISION (type), SIGNED); + tree tt + = build_nonst

Re: [PATCH] Clarify __atomic_compare_exchange_n docs

On 01/10/15 11:57 -0600, Sandra Loosemore wrote: H, yes. Looking at the section as a whole, is it a bug in the implementation that the built-ins only "approximately match" the C++11 requirements? AFAIK they exactly match, so I don't know why the docs say that. If there were an exact corr

[C++ PATCH] PR c++/54430

Tested on Linux-PPC64. /cp 2015-10-01 Ville Voutilainen PR c++/54430 * name-lookup.c (push_binding): Make non-static. * name-lookup.h (push_binding): Declare it. * parser.c (cp_parser_range_for): Use it, get the range declaration away from the scope until the range expressi

Re: [PATCH] Clarify __atomic_compare_exchange_n docs

On 10/01/2015 05:28 AM, Andrew Haley wrote: On 09/29/2015 04:21 PM, Sandra Loosemore wrote: What is "weak compare_exchange", and what is "the strong variation", and how do they differ in terms of behavior? It's in C++11 29.6.5: Remark: The weak compare-and-exchange operations may fail spuriou

Re: Do not use TYPE_CANONICAL in useless_type_conversion

> > - /* For aggregates we rely on TYPE_CANONICAL exclusively and require > > - explicit conversions for types involving to be structurally > > - compared types. */ > > + /* For aggregates compare only the size and mode. Accesses to fields do > > have > > + a type information by th

Re: Do not use TYPE_CANONICAL in useless_type_conversion

> > Do we require that to match? I don't remember that we do. > > For scalar types (and arrays of scalars), the alignment is essentially > encoded > in the size/mode pair but that's not the case for non-array aggregate types, > so declaring a conversion that changes the alignment as useless se

Re: [PATCH] Clarify __atomic_compare_exchange_n docs

On 01/10/15 18:34 +0100, Andrew Haley wrote: On 10/01/2015 06:32 PM, Jonathan Wakely wrote: I would suggest we don't try to reproduce the standard definition, but just say the weak version can fail spuriously and the strong can't. IMHO this isn't the place to educate people in the fine points of

Re: [PATCH] rs6000: Add "cannot_copy" attribute, use it (PR67788, PR67789)

On Thu, Oct 01, 2015 at 10:08:50AM -0400, David Edelsohn wrote: > Is this expensive enough that it is worth limiting the definition of > the hook to configurations that include 32-bit SVR4 support so that > not every configuration incurs the overhead? I don't think so. That won't save the call to

Re: [PATCH] Clarify __atomic_compare_exchange_n docs

On 10/01/2015 06:32 PM, Jonathan Wakely wrote: > I would suggest we don't try to reproduce the standard definition, but > just say the weak version can fail spuriously and the strong can't. > IMHO this isn't the place to educate people in the fine points of > low-level atomics. As it says, "when in

Re: [PATCH] Clarify __atomic_compare_exchange_n docs

On 01/10/15 12:28 +0100, Andrew Haley wrote: On 09/29/2015 04:21 PM, Sandra Loosemore wrote: What is "weak compare_exchange", and what is "the strong variation", and how do they differ in terms of behavior? It's in C++11 29.6.5: Remark: The weak compare-and-exchange operations may fail spurio

Re: [patch] libstdc++/67747 Allocate space for dirent::d_name

On 30/09/15 09:30 -0600, Martin Sebor wrote: On 09/30/2015 05:01 AM, Jonathan Wakely wrote: On 29/09/15 12:54 -0600, Martin Sebor wrote: On 09/29/2015 05:37 AM, Jonathan Wakely wrote: POSIX says that dirent::d_name has an unspecified length, so calls to readdir_r must pass a buffer with enough

Re: [PATCH] rs6000: Add "cannot_copy" attribute, use it (PR67788, PR67789)

On Thu, Oct 01, 2015 at 12:14:44PM +0200, Richard Biener wrote: > On Thu, Oct 1, 2015 at 8:08 AM, Segher Boessenkool > wrote: > > After the shrink-wrapping patches the prologue will often be pushed > > "deeper" into the function, which in turn means the software trace cache > > pass will more ofte

Re: Fold acc_on_device

On 10/01/15 13:00, Andrew MacLeod wrote: btw, not that it's necessarily important, but I'm about to submit the include reduction patches today, and it turns out this line is the first use of anything from cgraph.h in builtins.c. So if this is "the way" of doing the test, be aware it adds a dep

Do not describe -std=c11 etc. as experimental in c.opt help text

I noticed that c.opt still described -std=c11 and related options as experimental in the --help text. This patch fixes this. Jason, note that -std=gnu++11 and -std=gnu++14 still have that text, contrary to the descriptions of -std=c++11 and -std=c++14. Bootstrapped with no regressions on x86_64-

Re: Fold acc_on_device

On 09/30/2015 08:46 AM, Richard Biener wrote: On Wed, Sep 30, 2015 at 2:18 PM, Nathan Sidwell wrote: Please don't add any new GENERIC based builtin folders. Instead add to gimple-fold.c:gimple_fold_builtin Otherwise you're just generating more work for us who move foldings from builtins.c to

[PATCH] correctly handle non affine data references

PR tree-optimization/66980 * graphite-scop-detection.c (stmt_has_simple_data_refs_p): Return false when data reference analysis has failed. --- gcc/graphite-scop-detection.c| 7 +++ gcc/testsuite/gcc.dg/graphite/scop-pr66980.c | 10 ++ 2 files c

Re: [PATCH] fortran/67758 -- Prevent ICE caused by misplaced COMMON

On Thu, Oct 01, 2015 at 03:29:05PM +0200, Mikael Morin wrote: > Le 01/10/2015 14:16, Mikael Morin a écrit : > > Le 01/10/2015 02:07, Steve Kargl a écrit : > >> On Wed, Sep 30, 2015 at 05:06:30PM -0700, Steve Kargl wrote: > >>> Patch built and regression tested on x86_64-*-freebsd. > >>> OK to commi

Re: C PATCH for c/65345 (file-scope _Atomic expansion with floats)

On Thu, Oct 01, 2015 at 11:02:09AM -0400, David Edelsohn wrote: > On Thu, Oct 1, 2015 at 10:49 AM, Marek Polacek wrote: > > Joseph reminded me that I had forgotten about this patch. As mentioned > > here , I'm > > removing the XFAILs in th

Re: [PATCH] x86 interrupt attribute

On Thu, Oct 1, 2015 at 6:08 PM, H.J. Lu wrote: > On Thu, Oct 1, 2015 at 8:59 AM, Uros Bizjak wrote: >> On Thu, Oct 1, 2015 at 2:24 AM, H.J. Lu wrote: >>> On Wed, Sep 30, 2015 at 12:53 PM, Yulia Koval wrote: Done. >>> >>> + /* If true, the current function is an interrupt service >>>

Re: [Patch match.pd] Add a simplify rule for x * copysign (1.0, y);

Hi, On Thu, 1 Oct 2015, Joseph Myers wrote: > On Thu, 1 Oct 2015, Michael Matz wrote: > > > both cases. The catch is that strictly speaking (NaN * -1.0) needs to > > deliver NaN, not -NaN (operations involving quiet NaNs need to provide > > one of the input NaNs as result), and here both are

Re: [PATCH] Update SSA_NAME manager to use two lists

On 10/01/2015 04:00 AM, Richard Biener wrote: Apart from what Jakub said - this keeps the list non-recycled for example after DCE if that doesnt call cleanup_cfg. Likewise after passes that call cleanup_cfg manually. It also doesn't get called after IPA transform passes (which would require c

Re: [Patch match.pd] Add a simplify rule for x * copysign (1.0, y);

Hi, On Thu, 1 Oct 2015, Jakub Jelinek wrote: > But if x is a sNaN, then the multiplication will throw an exception, while > the transformed operation will not. Hmm, that's right, silly me. > So perhaps it should be guarded by > !HONOR_SNANS (TYPE_MODE (type)) > ? That makes sense, yes. Ciao,

Re: [PATCH] x86 interrupt attribute

On Thu, Oct 1, 2015 at 8:59 AM, Uros Bizjak wrote: > On Thu, Oct 1, 2015 at 2:24 AM, H.J. Lu wrote: >> On Wed, Sep 30, 2015 at 12:53 PM, Yulia Koval wrote: >>> Done. >>> >> >> + /* If true, the current function is an interrupt service >> + routine as specified by the "interrupt" attribute.

Re: [Patch match.pd] Add a simplify rule for x * copysign (1.0, y);

On Thu, 1 Oct 2015, Michael Matz wrote: > both cases. The catch is that strictly speaking (NaN * -1.0) needs to > deliver NaN, not -NaN (operations involving quiet NaNs need to provide > one of the input NaNs as result), and here both are not equivalent. OTOH > the sign of NaNs isn't specifie

Re: [PATCH] x86 interrupt attribute

On Thu, Oct 1, 2015 at 2:24 AM, H.J. Lu wrote: > On Wed, Sep 30, 2015 at 12:53 PM, Yulia Koval wrote: >> Done. >> > > + /* If true, the current function is an interrupt service > + routine as specified by the "interrupt" attribute. */ > + BOOL_BITFIELD is_interrupt : 1; > + > + /* If true

Re: [Patch match.pd] Add a simplify rule for x * copysign (1.0, y);

On Thu, Oct 01, 2015 at 05:43:15PM +0200, Michael Matz wrote: > Hi, > > On Thu, 1 Oct 2015, James Greenhalgh wrote: > > > > > x * copysign (1.0, y) > > > > > > > > x ^ (y & (1 << sign_bit_position)) > > > > > > Also I think this can only be done for finite and non trapping types. > > > > Th

Re: [PATCH] Fix warnings building pdp11 port

On 10/01/2015 03:49 AM, Richard Biener wrote: On Wed, Sep 30, 2015 at 6:43 PM, Jeff Law wrote: On 09/30/2015 01:48 AM, Richard Biener wrote: On Tue, Sep 29, 2015 at 6:55 PM, Jeff Law wrote: The pdp11 port fails to build with the trunk because of a warning. Essentially VRP determines that t

Re: [Patch match.pd] Add a simplify rule for x * copysign (1.0, y);

Hi, On Thu, 1 Oct 2015, James Greenhalgh wrote: > > > x * copysign (1.0, y) > > > > > > x ^ (y & (1 << sign_bit_position)) > > > > Also I think this can only be done for finite and non trapping types. > > That may be well true, I swithered either way and went for no checks, > but I'd happi

RE: [PATCH][AArch64] Add separate insn sched class for vector LDP & STP

Hi, Rama. My patch changed the type of a couple of A64 insns from "neon_load2_2reg_q" and "neon_store2_2reg_q". However, neither ThunderX nor Xgene referred to these types, only A57 and A53 did. So I didn't feel that I'd be the best person to add them to those machines. Thank you, -- Evand

Re: [PATCH] vectorizing conditional expressions (PR tree-optimization/65947)

On 30/09/2015 13:45, "Richard Biener" wrote: >On Wed, Sep 23, 2015 at 5:51 PM, Alan Hayward >wrote: >> >> >> On 18/09/2015 14:53, "Alan Hayward" wrote: >> >>> >>> >>>On 18/09/2015 14:26, "Alan Lawrence" wrote: >>> On 18/09/15 13:17, Richard Biener wrote: > > Ok, I see. >

[gomp4] gimple fold acc_on_device

I've applied this version of the acc_on_device folding to gomp4. See https://gcc.gnu.org/ml/gcc-patches/2015-10/msg00074.html for the trunk discussion. nathan 2015-10-01 Nathan Sidwell * builtins.c: Don't include gomp-constants.h. (fold_builtin_1): Don't fold acc_on_device here. * gimpl

Re: [Patch match.pd] Add a simplify rule for x * copysign (1.0, y);

> On Oct 1, 2015, at 7:51 AM, James Greenhalgh wrote: > > On Thu, Oct 01, 2015 at 03:28:22PM +0100, pins...@gmail.com wrote: >>> >>> On Oct 1, 2015, at 6:57 AM, James Greenhalgh >>> wrote: >>> >>> >>> Hi, >>> >>> If it is cheap enough to treat a floating-point value as an integer and >>> t

Re: C PATCH for c/65345 (file-scope _Atomic expansion with floats)

On Thu, Oct 1, 2015 at 10:49 AM, Marek Polacek wrote: > Joseph reminded me that I had forgotten about this patch. As mentioned > here , I'm > removing the XFAILs in the tests so people are likely to see new FAILs. > > I think the following

Re: [Patch match.pd] Add a simplify rule for x * copysign (1.0, y);

On Thu, Oct 01, 2015 at 03:28:22PM +0100, pins...@gmail.com wrote: > > > > On Oct 1, 2015, at 6:57 AM, James Greenhalgh > > wrote: > > > > > > Hi, > > > > If it is cheap enough to treat a floating-point value as an integer and > > to do bitwise arithmetic on it (as it is for AArch64) we can r

[PATCH, i386, AVX-512, doc] Mention all AVX-512 switches in invoke.texi.

Hello, This patch adds missing AVX-512 switches to invoke.texi. `make pdf` looks ok. Is it ok for trunk and gcc-5-branch (a week after check in to trunk)? gcc/ * doc/invoke.texi: Mention -mavx512vl, -mavx512bw, -mavx512dq, -mavx521vbmi, -mavx512ifma. Add missing opindex-es. -- T

C PATCH for c/65345 (file-scope _Atomic expansion with floats)

Joseph reminded me that I had forgotten about this patch. As mentioned here , I'm removing the XFAILs in the tests so people are likely to see new FAILs. I think the following targets will need similar fix as the one below: * MIPS * rs6000

Go patch committed: Only check OPT_m32 if TARGET_CAN_SPLIT_STACK_64BIT

The option OPT_m32 is not defined on all targets. This patch only checks for it if TARGET_CAN_SPLIT_STACK_64BIT is defined, which is the only case where we need to know the value. Bootstrapped on x86_64-unknown-linux-gnu. Committed to mainline. Ian 2015-10-01 Ian Lance Taylor PR go/66870 *

[PATCH, MIPS, PR/61114] Migrate to reduc_..._scal optabs.

Hello, This patch migrates the MIPS backend to the new vector reduction optabs. No new regressions, ok to apply? Thanks, Simon gcc/ChangeLog: * config/mips/loongson.md (vec_loongson_extract_lo_): New, extract low part to scalar. (reduc_uplus_): Remove. (reduc_p

Re: Do not use TYPE_CANONICAL in useless_type_conversion

> Do we require that to match? I don't remember that we do. For scalar types (and arrays of scalars), the alignment is essentially encoded in the size/mode pair but that's not the case for non-array aggregate types, so declaring a conversion that changes the alignment as useless seems weird. -

Re: [Patch match.pd] Add a simplify rule for x * copysign (1.0, y);

> > On Oct 1, 2015, at 6:57 AM, James Greenhalgh wrote: > > > Hi, > > If it is cheap enough to treat a floating-point value as an integer and > to do bitwise arithmetic on it (as it is for AArch64) we can rewrite: > > x * copysign (1.0, y) > > as: > > x ^ (y & (1 << sign_bit_position)) W

Re: Do not use TYPE_CANONICAL in useless_type_conversion

On Thu, 1 Oct 2015, Eric Botcazou wrote: > > After dropping the check I needed to solve two issues. First is that we need > > a definition of useless conversions for aggregates. As discussed earlier I > > made it to depend only on size. The basic idea is that only operations you > > can do on gimp

Re: Fold acc_on_device

On 10/01/15 08:46, Richard Biener wrote: On Thu, Oct 1, 2015 at 2:33 PM, Nathan Sidwell wrote: use TREE_TYPE (arg0) for the integer cst. Otherwise looks good to me. thanks, fixed up and applied (also noticed a copy & paste malfunction setting the location) nathan 2015-10-01 Nathan Sidw

Re: Do not use TYPE_CANONICAL in useless_type_conversion

> After dropping the check I needed to solve two issues. First is that we need > a definition of useless conversions for aggregates. As discussed earlier I > made it to depend only on size. The basic idea is that only operations you > can do on gimple with those are moves and field accesses. Field

Re: [PATCH] rs6000: Add "cannot_copy" attribute, use it (PR67788, PR67789)

On Thu, Oct 1, 2015 at 2:08 AM, Segher Boessenkool wrote: > After the shrink-wrapping patches the prologue will often be pushed > "deeper" into the function, which in turn means the software trace cache > pass will more often want to duplicate the basic block containing the > prologue. This cause

Re: [PATCH] rs6000: Add "cannot_copy" attribute, use it (PR67788, PR67789)

On Thu, Oct 1, 2015 at 2:08 AM, Segher Boessenkool wrote: > After the shrink-wrapping patches the prologue will often be pushed > "deeper" into the function, which in turn means the software trace cache > pass will more often want to duplicate the basic block containing the > prologue. This cause

Re: Cache reals for 1/4, 1/6 and 1/9

On 10/01/2015 03:51 PM, Richard Sandiford wrote: We have a global 1/2 and a cached 1/3, but recalculate 1/4, 1/6 and 1/9 each time we need them. That seems a bit arbitrary and makes the folding code more noisy (especially once it's moved to match.pd). This patch caches the other three constants

[Patch match.pd] Add a simplify rule for x * copysign (1.0, y);

Hi, If it is cheap enough to treat a floating-point value as an integer and to do bitwise arithmetic on it (as it is for AArch64) we can rewrite: x * copysign (1.0, y) as: x ^ (y & (1 << sign_bit_position)) This patch implements that rewriting rule in match.pd, and a testcase expecting th

[gomp4] backport some changes

I've applied this to gomp4 to apply some changes to these areas that occurred on merging to trunk. nathan 2015-10-01 Nathan Sidwell * config/nvptx/nvptx.c (nvptx_validate_dims): Rename to ... (nvptx_goacc_validate_dims): ... here. (TARGET_GOACC_VALIDATE_DIMS): Update. * target.def (valid

Re: Add a build_real_truncate helper function

On 10/01/2015 03:48 PM, Richard Sandiford wrote: ...which simplifies the match.pd patterns I'm about to add. Bootstrapped & regression-tested on x86_64-linux-gnu. OK to install? Ok. Bernd

Cache reals for 1/4, 1/6 and 1/9

We have a global 1/2 and a cached 1/3, but recalculate 1/4, 1/6 and 1/9 each time we need them. That seems a bit arbitrary and makes the folding code more noisy (especially once it's moved to match.pd). This patch caches the other three constants too. Bootstrapped & regression-tested on x86_64-l

Add a build_real_truncate helper function

...which simplifies the match.pd patterns I'm about to add. Bootstrapped & regression-tested on x86_64-linux-gnu. OK to install? Thanks, Richard gcc/ * real.h (build_real_truncate): Declare. * real.c (build_real_truncate): New function. (strip_float_extensions): Use it.

[PATCH] Remove gimplifier use from PRE

The following patch from the match-and-simplify branch removes gimplifier use from PRE replacing it with use of the gimple_build API building GIMPLE directly. Bootstrapped on x86_64-unknown-linux-gnu, testing in progress. Richard. 2015-10-01 Richard Biener * tree-ssa-pre.c (create_c

Re: [PATCH] Tune for lakemont

On Thu, Oct 1, 2015 at 5:42 AM, Uros Bizjak wrote: > On Thu, Oct 1, 2015 at 2:37 PM, Yulia Koval wrote: >> Hi, >> >> The patch below contains some tuning changes for Lakemont, introduced >> by H.J. Lu. Bootstraped/regtested for Linux/x86_64. Ok for trunk? >> >> * gcc/config/i386/x86-tune.

Re: [patch] Add counter inits to zero_iter_bb in expand_omp_for_init_counts

On 01/10/15 14:49, Jakub Jelinek wrote: On Thu, Oct 01, 2015 at 02:46:01PM +0200, Tom de Vries wrote: this patch adds initialization in zero_iter_bb of counters introduced in expand_omp_for_init_counts. This removes the need to set TREE_NO_WARNING on those counters. Why do you think it is a g

Re: [PATCH] Clear flow-sensitive info in phiopt (PR tree-optimization/67769)

On Thu, 1 Oct 2015, Marek Polacek wrote: > On Thu, Oct 01, 2015 at 03:26:34PM +0200, Richard Biener wrote: > > No, this looks fine. > > Thanks. Let me do proper testing then. (And I suppose we might want this > in gcc-5 as well.) Yes. All the bugs are latent for GCC 5 (and also 4.9), they ar

Re: [PATCH] Clear flow-sensitive info in phiopt (PR tree-optimization/67769)

On Thu, 1 Oct 2015, Marek Polacek wrote: > On Thu, Oct 01, 2015 at 09:57:54AM +0200, Richard Biener wrote: > > On Wed, 30 Sep 2015, Marek Polacek wrote: > > > > > Another instance of out of date SSA range info. Before phiopt1 we had > > > > > > : > > > if (N_2(D) >= 0) > > > goto ; > >

Re: [PATCH] Clear flow-sensitive info in phiopt (PR tree-optimization/67769)

On Thu, Oct 01, 2015 at 03:26:34PM +0200, Richard Biener wrote: > No, this looks fine. Thanks. Let me do proper testing then. (And I suppose we might want this in gcc-5 as well.) Marek

Re: [PATCH] fortran/67758 -- Prevent ICE caused by misplaced COMMON

Le 01/10/2015 14:16, Mikael Morin a écrit : Le 01/10/2015 02:07, Steve Kargl a écrit : On Wed, Sep 30, 2015 at 05:06:30PM -0700, Steve Kargl wrote: Patch built and regression tested on x86_64-*-freebsd. OK to commit? The patch prevents the dereferencing of a NULL pointer by jumping out of the

Re: [PATCH] Clear flow-sensitive info in phiopt (PR tree-optimization/67769)

On Thu, Oct 01, 2015 at 09:57:54AM +0200, Richard Biener wrote: > On Wed, 30 Sep 2015, Marek Polacek wrote: > > > Another instance of out of date SSA range info. Before phiopt1 we had > > > > : > > if (N_2(D) >= 0) > > goto ; > > else > > goto ; > > > > : > > iftmp.0_3 = MIN_E

[PATCH][RTL ifcvt] PR 67786, 67787: Check that intermediate instructions in the basic block don't clobber a reg used in condition

Hi all, This patch fixes the two wrong-code PRs. The problem is related to the way the noce_emit_cmove helper function emits conditional moves. For some targets it re-emits the comparison from the condition block and then the conditional move after we have emitted the two basic blocks. Later pa

[PATCH][AArch64] Don't allow -mgeneral-regs-only to change the .arch assembler directives

Hi all, As part of the SWITCHABLE_TARGET work I inadvertently changed the behaviour of -mgeneral-regs-only with respect to the .arch directives that we emit. The behaviour of -mgeneral-regs-only in GCC 5 and earlier is such that it disallows the usage of FP/SIMD registers but does *not* stop th

[PATCH, testsuite]: Skip gcc.dg/lto/pr55113_0.c on all x86 targets.

Hello! There is no point to use -fshort-double on x86 targets, although it works with -mno-sse, where it avoids construction of DFmode based vector builtins. So, disable non-sensical test on all x86 targets. 2015-10-01 Uros Bizjak * gcc.dg/lto/pr55113_0.c: Skip on all x86 targets. Teste

Re: [patch] Add counter inits to zero_iter_bb in expand_omp_for_init_counts

On Thu, Oct 01, 2015 at 02:46:01PM +0200, Tom de Vries wrote: > this patch adds initialization in zero_iter_bb of counters introduced in > expand_omp_for_init_counts. > > This removes the need to set TREE_NO_WARNING on those counters. Why do you think it is a good idea? I'd be afraid it slows th

  1   2   >