Re: update_vtable_references segfault

> On 12/12/15 09:44, Nathan Sidwell wrote: > >On 12/11/15 13:15, Jan Hubicka wrote: > >>>Jan, > > > >>>b) augment can_replace_by_local_alias_in_vtable to check whether > >>>aliases can be created? > >> > >>I think this is best: can_replace_by_local_alias_in_vtable exists to > >>prevent the > >>bod

Re: [PATCH][WIP] libstdc++: Make certain exceptions transaction_safe.

Sorry for the delay finishing this review, some of the code kept melting my brain ;-) On 14/11/15 20:45 +0100, Torvald Riegel wrote: diff --git a/libstdc++-v3/config/abi/pre/gnu.ver b/libstdc++-v3/config/abi/pre/gnu.ver index 1b3184a..d902b03 100644 --- a/libstdc++-v3/config/abi/pre/gnu.ver ++

Re: [PATCH] C and C++ FE: better source ranges for binary ops

On 12/16/2015 11:04 AM, David Malcolm wrote: Currently trunk emits range information for most bad binary operations in the C++ frontend; but not in the C frontend. The helper function binary_op_error shared by C and C++ takes a location_t. In the C++ frontend, a location_t containing the range

ISL version check patch

This patch https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01273.html breaks builds using static libisl & libgmp. (a whole slew of undefined __gmpz_FOO symbols). Fixed with the attached patch to add -lgmp etc to the isl link test. ok? nathan 2015-12-16 Nathan Sidwell * config/isl.m4 (ISL_C

Re: [PATCHES, PING*5] Enhance standard DWARF for Ada

On 12/16/2015 03:53 AM, Pierre-Marie de Rodat wrote: + /* Called from finalize_size_functions for functions whose body is needed to + generate complete debug info. For instance, functions used to compute the + size of variable-length structures. */ + void (* function_body) (tree decl)

Re: [PATCH][AArch64] Replace insn to zero up DF register

On 10/30/2015 05:24 AM, Marcus Shawcroft wrote: On 20 October 2015 at 00:40, Evandro Menezes wrote: In the existing targets, it seems that it's always faster to zero up a DF register with "movi %d0, #0" instead of "fmov %d0, xzr". This patch modifies the respective pattern. Hi Evandro, This

Re: [PATCH] Fix PR c++/21802 (two-stage name lookup fails for operators)

On Wed, 16 Dec 2015, Michael Matz wrote: Hi, On Mon, 14 Dec 2015, Patrick Palka wrote: This should use cp_tree_operand_length. Hmm, I don't immediately see how I can use this function here. It expects a tree but I dont have an appropriate tree to give to it, only a tree_code. True. So le

Re: [PATCH] Fix PR c++/21802 (two-stage name lookup fails for operators)

Looks good. Jason

Re: [PATCH] Fix some blockers of PR c++/24666 (arrays decay to pointers too early)

On 12/15/2015 04:16 PM, Patrick Palka wrote: + if (MAYBE_CLASS_TYPE_P (type)) +; What does this patch do with conversion to const reference to class? I think we want to check MAYBE_CLASS_TYPE_P (non_reference (type)) here. Jason

Re: [PATCH] Fix PR c++/21802 (two-stage name lookup fails for operators)

On 2015.12.14 at 19:34 -0500, Jason Merrill wrote: > OK. This patch caused https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68936 -- Markus

[PATCH] Fix INTEGER_CST handling for > 64 bits wide bitfields (PR tree-optimization/68835)

Hi! As can be seen on the testcases below, on > 64 bit precision bitfields we either ICE or miscompile. get_int_cst_ext_nunits already has code that for unsigned precision in multiplies of HOST_BITS_PER_WIDE_INT it forces TREE_INT_CST_EXT_NUNITS to be bigger than TREE_INT_CST_NUNITS, the former h

Re: [PATCH] Fix some blockers of PR c++/24666 (arrays decay to pointers too early)

On Wed, 16 Dec 2015, Jason Merrill wrote: On 12/15/2015 04:16 PM, Patrick Palka wrote: + if (MAYBE_CLASS_TYPE_P (type)) +; What does this patch do with conversion to const reference to class? I think we want to check MAYBE_CLASS_TYPE_P (non_reference (type)) here. That makes sense.

[v3 PATCH] PR libstdc++/68276

Tested on Linux-PPC64. 2015-12-17 Ville Voutilainen PR libstdc++/68276 * src/c++11/ios.cc (_M_grow_words): Use nothrow new. * testsuite/27_io/ios_base/storage/11584.cc: Adjust. diff --git a/libstdc++-v3/src/c++11/ios.cc b/libstdc++-v3/src/c++11/ios.cc index 4adc701..4241bef 100644

Re: Fix PR66208

On 12/16/2015 10:13 AM, Bernd Schmidt wrote: This is a relatively straightforward PR where we should mention a macro expansion in a warning message. The patch below implements the suggestion by Marek to pass a location down from build_function_call_vec. Ok if tests pass on x86_64-linux? One ques

Re: ISL version check patch

On 12/16/2015 02:22 PM, Nathan Sidwell wrote: This patch https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01273.html breaks builds using static libisl & libgmp. (a whole slew of undefined __gmpz_FOO symbols). Fixed with the attached patch to add -lgmp etc to the isl link test. ok? OK. jeff

Re: [v3 PATCH] PR libstdc++/68276

On 17 December 2015 at 00:12, Ville Voutilainen wrote: > Tested on Linux-PPC64. > > 2015-12-17 Ville Voutilainen > > PR libstdc++/68276 > > * src/c++11/ios.cc (_M_grow_words): Use nothrow new. > * testsuite/27_io/ios_base/storage/11584.cc: Adjust. Shock horror, inconsistent indenta

[PATCH] [graphite] attach schedule tree to the scop

we used to translate the just computed schedule tree into a union_map, and then in the code generation it would be translated back to a schedule tree just before generating AST code. --- gcc/graphite-isl-ast-to-gimple.c | 65 ++-- gcc/graphite-optimize-isl.c

Re: [gomp4] [WIP] OpenACC bind, nohost clauses

On 12/14/2015 12:36 PM, Cesar Philippidis wrote: > On 12/08/2015 11:55 AM, Thomas Schwinge wrote: >> On Sat, 14 Nov 2015 09:36:36 +0100, I wrote: >> C front end: >> >> --- gcc/c/c-parser.c >> +++ gcc/c/c-parser.c >> @@ -11607,6 +11607,8 @@ c_parser_oacc_clause_async (c_parser *parser,

libgcc: unwind-ia64.c without malloc/free

Hi, this is just an idea, how to avoid use of malloc in unwind-ia64.c. I can compile this with my cross-compiler, but can not test anything. If you find it interesting, then someone should continue this work and test and/or fix it until it really works. The idea is, I can use alloca instead of

[PATCH] Pr 68805, Fix PowerPC little endian -mvsx-timode

My first mail did not seem to be delivered, so I'm trying again. This fixes a bug with the debug switch -mvsx-timode that we would eventually like to enable by default on PowerPC little endian server systems. The bug is that the load with rotate or rotate with store instructions needed on power8

[PATCH] PR target/68937: i686: -fno-plt produces wrong code (maybe only with tailcall

Since sibcall never returns, we can only use call-clobbered register as GOT base. Otherwise, callee-saved register used as GOT base won't be properly restored. Tested on x86-64 with -m32. OK for trunk? H.J. --- gcc/ PR target/68937 * config/i386/i386.c (ix86_function_ok_for_si

[PATCH] [graphite] move all isl include files to graphite.h

* graphite-dependences.c: Move all isl include files to... * graphite-isl-ast-to-gimple.c: Same. * graphite-optimize-isl.c: Same. * graphite-poly.c: Same. * graphite-scop-detection.c: Same. * graphite.c: Same. * graphite.h: ... here. --- gcc/

Re: [PATCH] Pr 68805, Fix PowerPC little endian -mvsx-timode

On Wed, Dec 16, 2015 at 6:20 PM, Michael Meissner wrote: > My first mail did not seem to be delivered, so I'm trying again. > > This fixes a bug with the debug switch -mvsx-timode that we would eventually > like to enable by default on PowerPC little endian server systems. The bug is > that the l

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

Kyrill, I have attached a patch that address your comments. The only change I would ask you to re-consider renaming is the function 'bool aarch32_simd_check_vect_par_cnst_half'. This function was copied from the aarch64 port and I thought it as important to match the naming for maintenance pu

[committed] Fix HPPA/PARISC 32-bit Linux kernel build

The attached patch fixes a reload error in one of the new 64-bit atomic patterns in a 32-bit kernel build. Kernel builds disable the use of floating point registers with -mdisable-fpregs. The atomic patterns need to use floating point loads and stores and should have been disabled when -mdisab

[PATCH] C FE: improvements to ranges of bad return values

In the C FE, c_parser_statement_after_labels passes "xloc" to c_finish_return, which is the location of the first token within the returned expression. Hence we don't get a full underline for the following: diagnostic-range-bad-return.c:34:10: warning: function returns address of local variable

Re: [PATCH] Fix some blockers of PR c++/24666 (arrays decay to pointers too early)

OK, thanks. Jason

[PATCH, GCC, V8M 0/6] Add support for ARMv8-M

Hi, I'll be posting a patch series intended for trunk whose aim is to add support for ARMv8-M. This patch series does not include changes to support the security extensions [nor does it include atomics for ARMv8-M Baseline]. This will be posted as a separate patch series. === Quick overview o

[arm-embedded][PATCH, libgcc/ARM 1/6] Fix Thumb-1 only == ARMv6-M & Thumb-2 only == ARMv7-M assumptions

Hi, We decided to apply the following patch to the ARM embedded 5 branch. This is *not* intended for trunk for now. We will send a separate email for trunk. This patch is part of a patch series to add support for ARMv8-M[1] to GCC. This specific patch fixes some assumptions related to M profile

RE: [arm-embedded][PATCH, libgcc/ARM 1/6] Fix Thumb-1 only == ARMv6-M & Thumb-2 only == ARMv7-M assumptions

The following was committed, once rebased on top of the embedded branch (patch was generated on top of gcc-5-branch): diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h index 8c10ea3c9053e89b8eae1e5353b92d6020499409..bf1a0e874b1669f3ebe1e5870556a46b80686b82 100644 --- a/gcc/config/arm/arm

[PATCH, ARM 2/6] Add support for ARMv8-M

Hi, This patch is part of a patch series to add support for ARMv8-M[1] to GCC. This specific patch adds basic support for the new architecture, allowing the new names to be accepted by -march and the compiler to behave like ARMv6-M (for ARMv8-M Baseline) and or ARMv7-M (for ARMv8-M Mainline). T

Re: [build] Only support -gstabs on Mac OS X if assember supports it (PR target/67973)

Mike Stump writes: > On Dec 15, 2015, at 5:35 AM, Rainer Orth > wrote: >> Right: I'm effectively keeping just the first configure test for .stabs >> support in the assembler to enable or disable >> DBX_DEBUG/DBX_DEBUGGING_INFO. I'll post it later since … > >> ... testing revealed another insta

[gomp4] Merge trunk r231689 (2015-12-16) into gomp-4_0-branch

Hi! Committed to gomp-4_0-branch in r231738: commit d0b110f2163a5b186f15d05c9bfc6f51a42d652c Merge: 2a5a682 565bc8f Author: tschwinge Date: Thu Dec 17 07:11:02 2015 + svn merge -r 231118:231689 svn+ssh://gcc.gnu.org/svn/gcc/trunk git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc

[arm-embedded][PATCH, ARM 2/6] Add support for ARMv8-M

Hi, We decided to apply the following patch to the ARM embedded 5 branch. Best regards, Thomas > -Original Message- > From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches- > ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme > Sent: Thursday, December 17, 2015 3:25 PM > To: gcc-patch

[PATCH, ARM 3/8] Fix indentation of FL_FOR_ARCH* definition after adding support for ARMv8-M

Hi, This patch is part of a patch series to add support for ARMv8-M[1] to GCC. This specific patch fixes the indentation of FL_FOR_ARCH* macros definition following the patch to add support for ARMv8-M. Since this is an obvious change, I'm not expecting a review and will commit it as soon as th

[arm-embedded][PATCH, ARM 3/6] Fix indentation of FL_FOR_ARCH* definition after adding support for ARMv8-M

Hi, We decided to apply the following patch to the ARM embedded 5 branch. Best regards, Thomas > -Original Message- > From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches- > ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme > Sent: Thursday, December 17, 2015 3:51 PM > To: gcc-patch

RE: [PATCH, ARM 3/6] Fix indentation of FL_FOR_ARCH* definition after adding support for ARMv8-M

[Fixed the subject and added ARM maintainers to recipient.] > -Original Message- > From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches- > ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme > Sent: Thursday, December 17, 2015 3:51 PM > To: gcc-patches@gcc.gnu.org > Subject: [PATCH, ARM

<    1   2