Re: [PATCH] Improve BB vectorization dependence analysis

On Tue, 17 Nov 2015, Richard Biener wrote: > On Mon, 16 Nov 2015, Alan Lawrence wrote: > > > On 09/11/15 12:55, Richard Biener wrote: > > > > > > Currently BB vectorization computes all dependences inside a BB > > > region and fails all vectorization if it cannot handle some of them. > > > > >

Re: [PATCH, PR middle-end/68134] Reject scalar modes in default get_mask_mode hook

On Tue, Nov 17, 2015 at 12:49 PM, Ilya Enkovich wrote: > Hi, > > Default hook for get_mask_mode is supposed to return integer vector modes. > This means it should reject calar modes returned by mode_for_vector. > Bootstrapped and regtested on x86_64-unknown-linux-gnu,

Re: [PATCH] Clarify that -fwrapv covers all signed arithmetic overflow

On Tue, 17 Nov 2015, Paolo Bonzini wrote: > GCC's -fwrapv option does not affect code generation for shifts > because currently GCC does not rely on the fact that certain > signed shifts trigger undefined behavior. However, the definition > of signed arithmetic overflow does extend to shifts; it

[RFC PATCH] Do not sanitize left shifts for -fwrapv

Left shifts into the sign bit is a kind of overflow, and the standard chooses to treat left shifts of negative values the same way. However, the -fwrapv option modifies the language to one where integers are defined as two's complement---which also defines entirely the behavior of shifts.

[v3] Handle C++11 overloads on Solaris 12

Solaris 12 recently introduced the C++11 overloads, which caused bootstrap to be broken on both mainline and the gcc-5 branch: In file included from /vol/gcc/src/hg/trunk/local/libstdc++-v3/include/precompiled/stdc++.h:41:0:

Re: [PATCH 00/16] Unit tests framework (v3)

On 11/17/2015 02:53 AM, Mike Stump wrote: On Nov 16, 2015, at 3:12 PM, Jeff Law wrote: So I'd tend to want them either at the end of the file with a single #if CHECKING_P or as a separate foo-tests file. Hum… I kinda don’t want the main files mucked up with tests. I think

Port libvtv to Solaris

Now that init priority support on Solaris is on mainline, porting libvtv proved to be relatively easy, though it discovered a couple of quirks on a non-gld non-x86 platform. A considerable part of the patch lives in Solaris-specific files and thus doesn't need approval, though some changes

Re: [PATCH][ARM] PR 68143 Properly update memory offsets when expanding setmem

On 06/11/15 10:46, Kyrill Tkachov wrote: > Hi all, > > In this wrong-code PR the vector setmem expansion and > arm_block_set_aligned_vect in particular > use the wrong offset when calling adjust_automodify_address. In the attached > testcase during the > initial zeroing out we get two V16QI

Re: [PATCH, PR middle-end/68134] Reject scalar modes in default get_mask_mode hook

On 11/17/2015 12:49 PM, Ilya Enkovich wrote: Default hook for get_mask_mode is supposed to return integer vector modes. This means it should reject calar modes returned by mode_for_vector. Bootstrapped and regtested on x86_64-unknown-linux-gnu, regtested on aarch64-unknown-linux-gnu. OK for

Re: C++ PATCH to integrate c++-delayed-folding branch

On 11/17/2015 04:09 AM, Andreas Schwab wrote: Can we please get trunk back to bootstrap land? Which target isn't bootstrapping for you? Jason

[PATCH] Improve comments in pass_tree_loop_init::execute

Hi, this no-functional-changes patch improves comments in pass_tree_loop_init::execute. For the discussion related to the comment for scev_initialize, see: - https://gcc.gnu.org/ml/gcc-patches/2013-02/msg01127.html - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56426 OK for trunk? Thanks, -

Re: [AArch64][PATCH 4/7] Add ACLE feature macro for ARMv8.1,Adv.SIMD instructions.

On Tue, Oct 27, 2015 at 11:33:21AM +, James Greenhalgh wrote: > On Fri, Oct 23, 2015 at 01:22:16PM +0100, Matthew Wahab wrote: > > The ARMv8.1 architecture extension adds two Adv.SIMD instructions, > > sqrdmlah and sqrdmlsh. This patch adds the feature macro > > __ARM_FEATURE_QRDMX to indicate

Re: [PATCH, PR middle-end/68134] Reject scalar modes in default get_mask_mode hook

2015-11-17 15:26 GMT+03:00 Bernd Schmidt : > On 11/17/2015 12:49 PM, Ilya Enkovich wrote: >> >> Default hook for get_mask_mode is supposed to return integer vector >> modes. This means it should reject calar modes returned by >> mode_for_vector. Bootstrapped and regtested on

[visium] Provide user-mode version of libraries

This adds a user-mode set of multilibs to the visium-elf port. Applied on the mainline. 2015-11-17 Eric Botcazou * config/visium/t-visium (MULTILIB_OPTIONS): Add muser-mode. (MULTILIB_DIRNAMES): Adjust accordingly. -- Eric BotcazouIndex:

Re: [PATCH] Improve comments in pass_tree_loop_init::execute

On Tue, 17 Nov 2015, Tom de Vries wrote: > Hi, > > this no-functional-changes patch improves comments in > pass_tree_loop_init::execute. > > For the discussion related to the comment for scev_initialize, see: > - https://gcc.gnu.org/ml/gcc-patches/2013-02/msg01127.html > -

Re: [PATCH][RTL-ree] PR rtl-optimization/68194: Restrict copy instruction in presence of conditional moves

On 11/17/2015 10:08 AM, Kyrill Tkachov wrote: Yes, I had considered that as well. It should be equivalent. I didn't use !reg_used_between_p because I thought it'd be more expensive than checking reg_overlap_mentioned_p since we must iterate over a number of instructions and call

Re: [PATCH][GCC] Make stackalign test LTO proof

On 11/16/2015 04:48 PM, Andre Vieira wrote: On 16/11/15 15:34, Joern Wolfgang Rennecke wrote: I just happened to stumble on this problem with another port. The volatile & test solution doesn't work, though. What does work, however, is: __asm__ ("" : : "" (dummy)); I can confirm that Joern's

Re: [PATCH] Clarify that -fwrapv covers all signed arithmetic overflow

On 17/11/2015 13:58, Joseph Myers wrote: >> > GCC's -fwrapv option does not affect code generation for shifts >> > because currently GCC does not rely on the fact that certain >> > signed shifts trigger undefined behavior. However, the definition >> > of signed arithmetic overflow does extend

Re: [PATCH][ARM] PR 68143 Properly update memory offsets when expanding setmem

On 17/11/15 12:58, Kyrill Tkachov wrote: Hi Ramana, On 17/11/15 12:02, Ramana Radhakrishnan wrote: On 06/11/15 10:46, Kyrill Tkachov wrote: Hi all, In this wrong-code PR the vector setmem expansion and arm_block_set_aligned_vect in particular use the wrong offset when calling

[PATCH] Clarify that -fwrapv covers all signed arithmetic overflow

GCC's -fwrapv option does not affect code generation for shifts because currently GCC does not rely on the fact that certain signed shifts trigger undefined behavior. However, the definition of signed arithmetic overflow does extend to shifts; it is only code generation that is limited to

Re: Aw: Re: TR1 Special Math

On 17/11/15 02:00, Ed Smith-Rowland wrote: On 11/16/2015 07:28 PM, Florian Goth wrote: Any particular pointers how I can help in improving the implementation? Immediately: I have a good patch with xfails where #include should inject into namespace std. That's probably a one liner in the

Re: [PATCH][ARM] PR 68143 Properly update memory offsets when expanding setmem

Hi Ramana, On 17/11/15 12:02, Ramana Radhakrishnan wrote: On 06/11/15 10:46, Kyrill Tkachov wrote: Hi all, In this wrong-code PR the vector setmem expansion and arm_block_set_aligned_vect in particular use the wrong offset when calling adjust_automodify_address. In the attached testcase

Re: [PATCH] Clarify that -fwrapv covers all signed arithmetic overflow

On Tue, 17 Nov 2015, Paolo Bonzini wrote: > * it doesn't promise that GCC will never rely on undefined behavior > rules for signed left shifts I think we should remove the ", but this is subject to change" in implement-c.texi (while replacing it with noting that ubsan will still diagnose such

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

Kirill, * c-c++-common/attr-simd.c and * c-c++-common/attr-simd-3.c fail on 32 bit systems, e.g., see powerpc64-linux tested in 32 bit mode. - David

[PATCH] PR fortran/43996 -- Too large array constructor in SPREAD

The attached patch fixes an issue with SPREAD and the PARAMETER attribute when an array constructor is too large for expansion. gfortran now issues an error message and points to the -fmax-array-constructor. Patch built on i386-*-freebsd and x86_64-*-freebsd. There are no regressions. OK to

[PATCH] g++.dg/cpp1y/pr58708.C wchar_t size

The testcase in the GCC testsuite assumes that wchar_t is 32 bits, which is not correct on AIX. 32 bit AIX maintains 16 bit wchar_t for backward compatibility (64 bit AIX uses 32 bit wchar_t). What is the preferred method to make the testcase safe for smaller wchar_t? The following patch works

Re: [PATCH] g++.dg/cpp1y/pr58708.C wchar_t size

On 17 November 2015 at 16:04, David Edelsohn wrote: > The testcase in the GCC testsuite assumes that wchar_t is 32 bits, > which is not correct on AIX. 32 bit AIX maintains 16 bit wchar_t for > backward compatibility (64 bit AIX uses 32 bit wchar_t). > > What is the preferred method to make the

Re: [gomp4, ptx] worker & gang complex double reductions

On 11/16/15 17:07, Nathan Sidwell wrote: I've committed this patch to the gomp4 branch. It adds support for worker and gang level complex double reductions. I was unsatisfied with that approach, so I've separated the two mechanisms into different functions with the attached patch. The

Re: [PATCH][GCC] Make stackalign test LTO proof

On 17/11/15 12:29, Bernd Schmidt wrote: On 11/16/2015 04:48 PM, Andre Vieira wrote: On 16/11/15 15:34, Joern Wolfgang Rennecke wrote: I just happened to stumble on this problem with another port. The volatile & test solution doesn't work, though. What does work, however, is: __asm__ ("" : :

Re: [PATCH] Add LANG_HOOKS_EMPTY_RECORD_P for C++ empty class

On Tue, Nov 17, 2015 at 12:01 PM, H.J. Lu wrote: > Empty record should be returned and passed the same way in C and C++. > This patch adds LANG_HOOKS_EMPTY_RECORD_P for C++ empty class, which > defaults to return false. For C++, LANG_HOOKS_EMPTY_RECORD_P is defined > to

Re: [PATCH][RTL-ree] PR rtl-optimization/68194: Restrict copy instruction in presence of conditional moves

On 17/11/15 12:10, Bernd Schmidt wrote: On 11/17/2015 10:08 AM, Kyrill Tkachov wrote: Yes, I had considered that as well. It should be equivalent. I didn't use !reg_used_between_p because I thought it'd be more expensive than checking reg_overlap_mentioned_p since we must iterate over a number

Re: [PATCH] Fix uninitialized src_range within c_expr (Re: libcpp/C FE source range patch committed (r230331))

On Mon, 2015-11-16 at 22:34 +0100, Bernd Schmidt wrote: > On 11/16/2015 09:50 PM, David Malcolm wrote: > > The root cause is uninitialized data. Specifically, the C parser's > > struct c_expr gained a "src_range" field, and it turns out there are a > > few places where I wasn't initializing this

Re: [PATCH] Fix uninitialized src_range within c_expr (Re: libcpp/C FE source range patch committed (r230331))

On 11/17/2015 04:13 PM, David Malcolm wrote: On Mon, 2015-11-16 at 22:34 +0100, Bernd Schmidt wrote: Should c_expr perhaps acquire a constructor so that this problem is avoided in the future? The whole thing seems somewhat error-prone. I agree that it's error prone, and the ctor approach is

Re: [PATCH] Clarify that -fwrapv covers all signed arithmetic overflow

On Tue, 17 Nov 2015, Paolo Bonzini wrote: > Can you suggest a wording for "if the GNU C language definition changes > [which, no matter how unlikely, is explicitly not ruled out by the > manual] -fwrapv will be extended to signed shifts, and shifts of > negative numbers would return A*2^B

Re: [PATCH, 10/16] Add pass_oacc_kernels pass group in passes.def

On 17/11/15 11:05, Richard Biener wrote: On Tue, Nov 17, 2015 at 12:20 AM, Tom de Vries wrote: On 16/11/15 13:45, Richard Biener wrote: + NEXT_PASS (pass_scev_cprop); What's that for? It's supposed to help removing loops - I don't expect kernels to

Re: [PATCH] PR 65751 Bogus in error message

On Tue, Nov 17, 2015 at 10:53:52AM +0100, Dominique d'Humi??res wrote: > Is the following patch OK for trunk and 5.3? OK. > > I have used the legalese found in my draft for Fortran 2015. > Would it be acceptable to replace > "with the BIND attribute or the SEQUENCE attribute" > with > "with

Re: C++ PATCH to integrate c++-delayed-folding branch

On Mon, Nov 16, 2015 at 10:47 PM, Jason Merrill wrote: > On 11/16/2015 09:39 PM, David Edelsohn wrote: >> >> The PPC port seems to be bootstrapping again, but I'm not sure why. >> Mike Meissner's patch only should have affected long double. > > >> It's hard to know if there is a

[PING] [PATCH] Improve C++ loop's backward-jump location

Ping: https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01192.html > gcc/cp/ChangeLog: > > * cp-gimplify.c (genericize_cp_loop): Change LOOP_EXPR's location > to start of loop body instead of start of loop. > > gcc/testsuite/ChangeLog: > > * g++.dg/guality/pr67192.C: New

Re: [PATCH, 10/16] Add pass_oacc_kernels pass group in passes.def

On Tue, 17 Nov 2015, Tom de Vries wrote: > On 17/11/15 11:05, Richard Biener wrote: > > On Tue, Nov 17, 2015 at 12:20 AM, Tom de Vries > > wrote: > > > On 16/11/15 13:45, Richard Biener wrote: > > > > > > > > > > > > + NEXT_PASS (pass_scev_cprop); > > > > > >

Re: [PATCH, 10/16] Add pass_oacc_kernels pass group in passes.def

On 17/11/15 16:18, Richard Biener wrote: IMHO autopar needs to handle induction itself. > >I'm not sure what you mean. Could you elaborate? Autopar handles induction >variables, but it doesn't handle exit phis reading the final value of the >induction variable. Is that what you want fixed?

Re: [PATCH] Clarify that -fwrapv covers all signed arithmetic overflow

On 17/11/2015 16:27, Joseph Myers wrote: > > Can you suggest a wording for "if the GNU C language definition changes > > [which, no matter how unlikely, is explicitly not ruled out by the > > manual] -fwrapv will be extended to signed shifts, and shifts of > > negative numbers would return A*2^B

Re: Extend tree-call-cdce to calls whose result is used

On Tue, Nov 17, 2015 at 10:19 AM, Richard Sandiford wrote: > Richard Biener writes: >> On Fri, Nov 13, 2015 at 2:12 PM, Richard Sandiford >> wrote: >>> Richard Biener writes: On

Re: RFA (GGC): PATCH to support GGC finalizers with PCH

On Tue, Nov 17, 2015 at 3:09 PM, Jason Merrill wrote: > While I was looking at the interaction of delayed folding with GGC, I > noticed that ggc_handle_finalizers currently runs no finalizers if > G.context_depth != 0. So any GC objects in a greater depth will still be >

Re: C++ PATCH to integrate c++-delayed-folding branch

Jason Merrill writes: > On 11/17/2015 04:09 AM, Andreas Schwab wrote: >> Can we please get trunk back to bootstrap land? > > Which target isn't bootstrapping for you? PR68346, PR68361 Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9

Re: Add genmatch support for internal functions

On Tue, Nov 17, 2015 at 9:52 AM, Richard Sandiford wrote: > Richard Sandiford writes: >> This patch makes genmatch match calls based on combined_fn rather >> than built_in_function and extends the matching to internal functions. >> It also

Re: Ping: [PATCH 3/6] Vectorize internal functions

On Tue, Nov 17, 2015 at 10:30 AM, Richard Sandiford wrote: > Thanks for all the reviews for this series. I think the patch below > is the only target-independent one that hasn't had any comments. This patch is ok. Thanks, Richard. > Richard > > Richard Sandiford

RFA (GGC): PATCH to support GGC finalizers with PCH

While I was looking at the interaction of delayed folding with GGC, I noticed that ggc_handle_finalizers currently runs no finalizers if G.context_depth != 0. So any GC objects in a greater depth will still be collected, but they won't have their finalizers run. This specifically affects

Re: C++ PATCH to integrate c++-delayed-folding branch

On 14/11/15 00:07, Jason Merrill wrote: And here's the final patch integrating the delayed folding branch. The general idea is to mostly avoid folding until the end of the function, at which point we fold everything as part of genericization. Since many warnings rely on looking at folded

Re: Replace match.pd DEFINE_MATH_FNs with auto-generated lists

On Tue, Nov 17, 2015 at 10:23 AM, Richard Sandiford wrote: > Richard Biener writes: >> On November 10, 2015 9:13:25 PM GMT+01:00, Richard Sandiford >> wrote: >>>Richard Biener writes:

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

On Tue, Nov 17, 2015 at 10:55 AM, Richard Sandiford wrote: > Richard Sandiford writes: >> Richard Biener writes: >>> On Tue, Nov 10, 2015 at 10:24 PM, Richard Sandiford >>> wrote:

Re: [PATCH] g++.dg/cpp1y/pr58708.C wchar_t size

On Tue, Nov 17, 2015 at 11:22 AM, Jonathan Wakely wrote: > On 17 November 2015 at 16:04, David Edelsohn wrote: >> The testcase in the GCC testsuite assumes that wchar_t is 32 bits, >> which is not correct on AIX. 32 bit AIX maintains 16 bit wchar_t for >> backward

Re: [PATCH] Clarify that -fwrapv covers all signed arithmetic overflow

On 17/11/2015 17:02, Joseph Myers wrote: > On Tue, 17 Nov 2015, Paolo Bonzini wrote: > >> * it doesn't promise that GCC will never rely on undefined behavior >> rules for signed left shifts > > I think we should remove the ", but this is subject to change" in > implement-c.texi (while

Re: [PATCH] Clarify that -fwrapv covers all signed arithmetic overflow

On 17/11/2015 17:02, Joseph Myers wrote: > On Tue, 17 Nov 2015, Paolo Bonzini wrote: > >> * it doesn't promise that GCC will never rely on undefined behavior >> rules for signed left shifts > > I think we should remove the ", but this is subject to change" in > implement-c.texi (while

Re: [PATCH] Clarify that -fwrapv covers all signed arithmetic overflow

On Tue, 17 Nov 2015, Paolo Bonzini wrote: > On 17/11/2015 17:02, Joseph Myers wrote: > > On Tue, 17 Nov 2015, Paolo Bonzini wrote: > > > >> * it doesn't promise that GCC will never rely on undefined behavior > >> rules for signed left shifts > > > > I think we should remove the ", but this is

Re: nvptx priority queues nonsupport in libgomp

On 11/17/2015 09:23 AM, Nathan Sidwell wrote: > On 11/17/15 12:23, Nathan Sidwell wrote: >> On 11/17/15 12:16, Cesar Philippidis wrote: >>> This patch adds an empty priority_queues.c in libgomp for nvptx targets. >>> Nvptx targets don't have sufficient support for a complete libgomp >>> library,

nvptx priority queues nonsupport in libgomp

This patch adds an empty priority_queues.c in libgomp for nvptx targets. Nvptx targets don't have sufficient support for a complete libgomp library, so we're only building a subset of it. And without that empty file, I was seeing an error message that looked like this: libgomp/libgomp.h:122:17:

Re: [PATCH] PR/67682, break SLP groups up if only some elements match

On 16/11/15 14:42, Christophe Lyon wrote: Hi Alan, I've noticed that this new test (gcc.dg/vect/bb-slp-subgroups-3.c) fails for armeb targets. I haven't had time to look at more details yet, but I guess you can reproduce it quickly enough. Thanks - yes I see it now. -fdump-tree-optimized

Re: nvptx priority queues nonsupport in libgomp

On Tue, Nov 17, 2015 at 09:16:05AM -0800, Cesar Philippidis wrote: > This patch adds an empty priority_queues.c in libgomp for nvptx targets. > Nvptx targets don't have sufficient support for a complete libgomp > library, so we're only building a subset of it. And without that empty > file, I was

Re: nvptx priority queues nonsupport in libgomp

On 11/17/15 12:23, Nathan Sidwell wrote: On 11/17/15 12:16, Cesar Philippidis wrote: This patch adds an empty priority_queues.c in libgomp for nvptx targets. Nvptx targets don't have sufficient support for a complete libgomp library, so we're only building a subset of it. And without that empty

Re: nvptx priority queues nonsupport in libgomp

On 11/17/15 12:16, Cesar Philippidis wrote: This patch adds an empty priority_queues.c in libgomp for nvptx targets. Nvptx targets don't have sufficient support for a complete libgomp library, so we're only building a subset of it. And without that empty file, I was seeing an error message that

Re: nvptx priority queues nonsupport in libgomp

On Tue, Nov 17, 2015 at 12:23:51PM -0500, Nathan Sidwell wrote: > On 11/17/15 12:23, Nathan Sidwell wrote: > >On 11/17/15 12:16, Cesar Philippidis wrote: > >>This patch adds an empty priority_queues.c in libgomp for nvptx targets. > >>Nvptx targets don't have sufficient support for a complete

[wwwdocs] Update libstdc++ release notes in gcc-6/changes.html

Committed to cvs. Index: htdocs/gcc-6/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-6/changes.html,v retrieving revision 1.42 diff -u -r1.42 changes.html --- htdocs/gcc-6/changes.html 15 Nov 2015 08:01:27 - 1.42 +++

[PATCH] Add LANG_HOOKS_EMPTY_RECORD_P for C++ empty class

Empty record should be returned and passed the same way in C and C++. This patch adds LANG_HOOKS_EMPTY_RECORD_P for C++ empty class, which defaults to return false. For C++, LANG_HOOKS_EMPTY_RECORD_P is defined to is_really_empty_class, which returns true for C++ empty classes. For LTO, we

[PATCH, PR middle-end/68134] Reject scalar modes in default get_mask_mode hook

Hi, Default hook for get_mask_mode is supposed to return integer vector modes. This means it should reject calar modes returned by mode_for_vector. Bootstrapped and regtested on x86_64-unknown-linux-gnu, regtested on aarch64-unknown-linux-gnu. OK for trunk? Thanks, Ilya -- gcc/ 2015-11-17

Re: [PATCH] Add configure flag for operator new (std::nothrow)

On 05/11/15 16:22, Daniel Gutson wrote: On Wed, Nov 4, 2015 at 3:20 AM, Jonathan Wakely wrote: >On 4 November 2015 at 02:11, Daniel Gutson wrote: >>Since this is a nothrow new, we thought that probably the system >>might not be exceptions-friendly (such as certain

[patch, doc] fix PR53587, missing documentation for -mms-bitfields

I've checked in this patch to fix PR53587, which is about missing documentation for the -mms-bitfields command-line option for x86. It turns out there *was* documentation, but it was buried in the discussion of the corresponding variable attributes with no pointers in the option summary or

C++ PATCHes for bootstrap/68346, 68361

A couple of bootstrap issues on some targets: 68346: My earlier change to avoid folding the arguments to warn_tautological_cmp wasn't quite right, either. This patch folds within the function, at the place where we are interested in a constant value. 68361: The way we were trying to

Re: [PATCH 00/16] Unit tests framework (v3)

On 11/17/2015 05:51 AM, Bernd Schmidt wrote: On 11/17/2015 02:53 AM, Mike Stump wrote: On Nov 16, 2015, at 3:12 PM, Jeff Law wrote: So I'd tend to want them either at the end of the file with a single #if CHECKING_P or as a separate foo-tests file. Hum… I kinda don’t want

[PATCH] fix c++/68308 - [6 Regression] ICE: tree check: expected integer_cst

Attached is a patch fixing the ICE caused by a prior change of mine: https://gcc.gnu.org/viewcvs/gcc?view=revision=230081 Tested on x86_64, committing to trunk as per Jason via IRC. Martin gcc/ChangeLog: 2015-11-17 Martin Sebor PR c++/68308 * cp/init.c

[committed] Remove dead macros

Nothing uses these macros and removing them makes it more likely that future code will use CASE_CFN_* instead. Tested on x86_64-linux-gnu, aarch64-linux-gnu and arm-linux-gnueabi. Applied as obvious. Thanks, Richard gcc/ * tree.h (BUILTIN_EXP10_P, BUILTIN_EXPONENT_P, BUILTIN_SQRT_P)

Re: [PATCH] PR fortran/59910 -- structure constructor in DATA statement

> … but I suspect gfc_reduce_init_expr() > may be useful for PARAMETER statements as well (need to > check this!). As in the following test module m implicit none type t integer :: i end type t type(t), dimension(2), parameter :: a1 = (/ t(1), t(2) /) type(t),

Re: [PATCH 5/5] [AARCH64] Add variant support to -m*=native and add thunderxt88pass1.

invoke.texi needs updating for thunderxt88pass1 support. -- Joseph S. Myers jos...@codesourcery.com

Re: [PATCH][RTL-ree] PR rtl-optimization/68194: Restrict copy instruction in presence of conditional moves

On 11/17/2015 02:03 PM, Kyrill Tkachov wrote: + || !reg_overlap_mentioned_p (tmp_reg, SET_SRC (PATTERN (cand->insn return false; Well, I think the statement we want to make is "return false from this function if the two expressions contain the same register number". I

POWERPC64_TOC_POINTER_ALIGNMENT

David noticed that gcc112 was generating gcc/auto-host.h with #define POWERPC64_TOC_POINTER_ALIGNMENT 32768 This is not the correct value of either 8 or 256 depending on how old ld is. On investigating I found the cause is Fedora 21 modifying the toolchain to default to -z relro. ld -z relro

Re: [PATCH] g++.dg/cpp1y/pr58708.C wchar_t size

On Nov 17, 2015, at 8:50 AM, David Edelsohn wrote: > > Thanks for the pointer. How about the following? Ok. sizeof (*wfoo) or sizeof (wchar_t) or some such might be even more portable. > > Thanks, David > > > Index: pr58708.C >

Re: vector lightweight debug mode

On 16/11/2015 11:29, Jonathan Wakely wrote: > On 15/11/15 22:12 +0100, François Dumont wrote: >> Here is a last version I think. >> >>I completed the debug light mode by adding some check on iterator >> ranges. >> >>Even if check are light I made some changes to make sure that >>

Re: Incorrect code due to indirect tail call of varargs function with hard float ABI

On 17/11/15 21:05, Ramana Radhakrishnan wrote: > Hi Kugan, > > It does look like an issue. > > Please open a bug report. > >> >> >> On 17/11/15 12:00, Charles Baylis wrote: >>> On 16 November 2015 at 22:24, Kugan >>> wrote: >>> Please note that we

[patch] libstdc++/66059 optimise std::make_integer_sequence

I've been talking about a compiler built-in to implement make_integer_sequence since before the proposal even made it into the standard, so I tried to implement one that would allow: template using make_integer_sequence = integer_sequence< __intseq(_Tp, _Num) >; But I don't know the front-end

[PATCH] PR fortran/59910 -- structure constructor in DATA statement

Here's what looks like a fairly simple patch, but it leads to a question. Why does gfortran not try to reduce the components in a structure constructor in general? I've hidden the gfc_reduce_init_expr() behind a check for a DATA statement, but I suspect gfc_reduce_init_expr() may be useful for

Re: RFA (GGC): PATCH to support GGC finalizers with PCH

On 11/17/2015 09:39 AM, Richard Biener wrote: On Tue, Nov 17, 2015 at 3:09 PM, Jason Merrill wrote: While I was looking at the interaction of delayed folding with GGC, I noticed that ggc_handle_finalizers currently runs no finalizers if G.context_depth != 0. So any GC

Re: [Patch, vrp] Allow VRP type conversion folding only for widenings upto word mode

On Mon, Nov 16, 2015 at 10:02:15AM +0100, Richard Biener wrote: > On Sat, 14 Nov 2015, Senthil Kumar Selvaraj wrote: > > > On Sat, Nov 14, 2015 at 09:57:40AM +0100, Richard Biener wrote: > > > On November 14, 2015 9:49:28 AM GMT+01:00, Senthil Kumar Selvaraj > > >

Re: POWERPC64_TOC_POINTER_ALIGNMENT

On Wed, Nov 18, 2015 at 09:52:41AM +1030, Alan Modra wrote: > David noticed that gcc112 was generating gcc/auto-host.h with > #define POWERPC64_TOC_POINTER_ALIGNMENT 32768 > > This is not the correct value of either 8 or 256 depending on how old > ld is. On investigating I found the cause is

Re: [PATCH] PR fortran/59910 -- structure constructor in DATA statement

On Tue, Nov 17, 2015 at 04:36:01PM -0800, Steve Kargl wrote: > On Wed, Nov 18, 2015 at 12:24:29AM +0100, Dominique d'Humières wrote: > > > ??? but I suspect gfc_reduce_init_expr() > > > may be useful for PARAMETER statements as well (need to > > > check this!). > > > > As in the following test >

Re: POWERPC64_TOC_POINTER_ALIGNMENT

On Tue, Nov 17, 2015 at 07:53:18PM -0500, Michael Meissner wrote: > Here is the temporary patch I'm using to get past rs6000.c. But I suspect the > TOC alignment should never be 256. Yes, it should be. Recent GNU ld aligns .TOC. to a 256 byte boundary. I have this patch in my tree. diff --git

Re: Incorrect code due to indirect tail call of varargs function with hard float ABI

> Hi Ramana, > > Thanks for the review. I have opened a gcc bug-report for this. I tested > the attached patch for arm-none-linux-gnueabihf and > arm-none-linux-gnueabi with no new regressions. Is this OK? > > > Thanks, > Kugan > > gcc/ChangeLog: > > 2015-11-18 Kugan Vivekanandarajah

Re: [PATCH] PR fortran/59910 -- structure constructor in DATA statement

On Wed, Nov 18, 2015 at 12:24:29AM +0100, Dominique d'Humières wrote: > > ??? but I suspect gfc_reduce_init_expr() > > may be useful for PARAMETER statements as well (need to > > check this!). > > As in the following test > > module m > implicit none > type t > integer :: i >

Re: [PATCH][GCC][ARM] Disable neon testing for armv7-m

On Mon, Nov 16, 2015 at 01:15:32PM +, Andre Vieira wrote: > On 16/11/15 12:07, James Greenhalgh wrote: > >On Mon, Nov 16, 2015 at 10:49:11AM +, Andre Vieira wrote: > >>Hi, > >> > >> This patch changes the target support mechanism to make it > >>recognize any ARM 'M' profile as a non-neon

Re: [PATCH][RTL-ree] PR rtl-optimization/68194: Restrict copy instruction in presence of conditional moves

Hi Bernd, On 16/11/15 18:40, Bernd Schmidt wrote: On 11/16/2015 03:07 PM, Kyrill Tkachov wrote: I've explained in the comments in the patch what's going on but the short version is trying to change the destination of a defining insn that feeds into an extend insn is not valid if the defining

Re: [PATCH][RTL-ree] PR rtl-optimization/68194: Restrict copy instruction in presence of conditional moves

On 17/11/15 09:08, Kyrill Tkachov wrote: Hi Bernd, On 16/11/15 18:40, Bernd Schmidt wrote: On 11/16/2015 03:07 PM, Kyrill Tkachov wrote: I've explained in the comments in the patch what's going on but the short version is trying to change the destination of a defining insn that feeds into

Re: [PATCH] Make fdump-tree-sccp-details more complete

On Mon, Nov 16, 2015 at 10:39 PM, Tom de Vries wrote: > Hi, > > pass_scev_cprop contains a bit where it replaces uses of an ssa-name with > constants. This is currently not noted in the dump-file, even with > TDF_DETAILS. > > This patch adds that information in the

Re: [PATCH AArch64]Handle REG+REG+CONST and REG+NON_REG+CONST in legitimize address

On Tue, Nov 17, 2015 at 05:21:01PM +0800, Bin Cheng wrote: > Hi, > GIMPLE IVO needs to call backend interface to calculate costs for addr > expressions like below: >FORM1: "r73 + r74 + 16380" >FORM2: "r73 << 2 + r74 + 16380" > > They are invalid address expression on AArch64, so will be

Re: [PATCH] Improve BB vectorization dependence analysis

On Mon, 16 Nov 2015, Alan Lawrence wrote: > On 09/11/15 12:55, Richard Biener wrote: > > > > Currently BB vectorization computes all dependences inside a BB > > region and fails all vectorization if it cannot handle some of them. > > > > This is obviously not needed - BB vectorization can

[PATCH] PR 65751 Bogus in error message

Is the following patch OK for trunk and 5.3? I have used the legalese found in my draft for Fortran 2015. Would it be acceptable to replace "with the BIND attribute or the SEQUENCE attribute" with "with the BIND or SEQUENCE attribute"? Dominique Index: gcc/fortran/ChangeLog

Re: Extend tree-call-cdce to calls whose result is used

Richard Biener writes: > On Fri, Nov 13, 2015 at 2:12 PM, Richard Sandiford > wrote: >> Richard Biener writes: >>> On Mon, Nov 9, 2015 at 10:03 PM, Michael Matz wrote: Hi, On Mon, 9

[PATCH, testsuite]: Add ieee options for gcc.dg/torture/pr68264.c

This test uses NaN, so it requires ieee options for certain targets. 2015-11-17 Uros Bizjak * gcc.dg/torture/pr68264.c: Use dg-add-options ieee. Tested on alphaev68-linux-gnu and committed to mainline SVN. Uros. Index: gcc.dg/torture/pr68264.c

Re: [Patch AArch64] Add support for Cortex-A35

On 16 November 2015 at 14:36, James Greenhalgh wrote: > 2015-11-16 James Greenhalgh > > * config/aarch64/aarch64-cores.def (cortex-a35): New. > * config/aarch64/aarch64.c (cortexa35_tunings): New. > *

Re: Add genmatch support for internal functions

Richard Sandiford writes: > This patch makes genmatch match calls based on combined_fn rather > than built_in_function and extends the matching to internal functions. > It also uses fold_const_call to fold the calls to a constant, rather > than going through

Re: [Patch ARM] Add support for Cortex-A35

On Mon, Nov 16, 2015 at 2:42 PM, James Greenhalgh wrote: > > Hi, > > This patch adds support to the ARM back-end for the Cortex-A35 > processor, as recently announced by ARM. The ARM Cortex-A35 provides > full support for the ARMv8-A architecture, including the CRC

[embedded-5-branch][PATCH 0/2] Backporting algorithmic optimization and testcase change

This series is aimed at backporting algorithmic optimizations and a change to a test it affects from trunk to the embedded-5-branch. Andre Vieira(2): Backporting algorithmic optimization in match and simplify Backporting fix for PR-67948.

[embedded-5-branch][PATCH 2/2]Backporting fix for PR-67948.

This patch backports the fix for PR-67948 from trunk to the embedded-5-branch. The original patch is at: https://gcc.gnu.org/ml/gcc-patches/2015-10/msg02193.html Tested for Cortex-M3. Is this OK to commit? Thanks, Andre gcc/testsuite/ChangeLog 2015-10-27 Andre Vieira

  1   2   >