[PATCH 4/4] Convert lto streamer out hashing to inchash

From: Andi Kleen No substantial changes, although the hash values will be slightly different. gcc/: 2014-07-10 Andi Kleen * lto-streamer-out.c (hash_tree): Convert to inchash. (add_flag): New macro. --- gcc/lto-streamer-out.c | 245 ++

[PATCH 1/4] Add an abstract incremental hash data type

From: Andi Kleen Some files in gcc, like lto or tree, do large scale incremential hashing. The current jhash implementation of this could be likely improved by using an incremential hash that does not do a full rehashing for every new value added. This patch adds a new "inchash" class that abstr

[PATCH 3/4] Convert the tree.c type hashing over to inchash

From: Andi Kleen Again should not really change any behavior (except for some minor differences with empty types) gcc/: 2014-07-10 Andi Kleen * tree.c (build_type_attribute_qual_variant): Use inchash. (type_hash_list): Dito. (attribute_hash_list): Dito (itera

[PATCH 2/4] Convert LTO type hashing to the new inchash interface

From: Andi Kleen Should not really change any behavior, it's just a more abstract interface, but uses the same underlying hash functions. lto/: 2014-07-10 Andi Kleen * lto.c (hash_canonical_type): Convert to inchash. (iterative_hash_canonical_type): Dito. --- gcc/lto/lto.c

Abstract incremental hashing

This patchkit abstracts incremental hashing in tree.c and lto.c to make it easier to plug in new and more efficient hash algorithms. Right now it uses the old hash algorithms. So it's just a cleanup. Passes bootstrap and testing on x86_64-linux. -Andi

[patch 0/2] gcc re-arch status

I don't have the time I'd like to since I'm running about a month behind schedule, but I wanted to make the code I've been experimenting with available a bit before cauldron so we can discuss it both here and in the upcoming BOF. I created a quick overview document, and managed to keep it to

Re: [C++ Patch/RFC] PR 50961

Hi, On 07/15/2014 11:46 PM, Jason Merrill wrote: You need to call resolve_nondeduced_context at some point. This doesn't seem to be the right place, since you also want to handle code like "if (foo)". Maybe in resolve_address_of_overloaded_function just before the error? Thanks, that helps (

Re: [Info], Add suport for PowerPC IEEE 128-bit floating point

On Tue, Jul 15, 2014 at 05:20:31PM -0400, Michael Meissner wrote: > I did some timing tests to compare the new PowerPC IEEE 128-bit results to the > current implementation of long double using the IBM extended format. > > The test consisted a short loop doing the operation over arrays of 1,024 > e

[PATCH, rs6000] Fix many powerpc*-linux ASAN test suite failures

With a recent libsanitizer merge from upstream, we're now seeing a lot of ASAN test suite failures with the following error: ==26426==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD. This is c

Re: [C++ Patch/RFC] PR 50961

You need to call resolve_nondeduced_context at some point. This doesn't seem to be the right place, since you also want to handle code like "if (foo)". Maybe in resolve_address_of_overloaded_function just before the error? Jason

Re: [PATCH, docs] Document -z option

Thanks :) dzur:~/sources/gcc> svn ci Enter passphrase for key '/usr/local/google/home/echristo/.ssh/id_dsa': Sendinggcc/ChangeLog Sendinggcc/doc/invoke.texi Transmitting file data .. Committed revision 212575. -eric On Tue, Jul 15, 2014 at 2:30 PM, Diego Novillo wrote: > On Tue

Re: [PATCH, docs] Document -z option

On Tue, Jul 15, 2014 at 5:23 PM, Eric Christopher wrote: > Just to document that it's passed directly on to the linker. > > OK? Wording changes? > > -eric > > 2014-07-15 Eric Christopher > > * doc/invoke.texi (Link Options): Document -z option. > > Index: gcc/doc/invoke.texi > =

[PATCH, docs] Document -z option

Just to document that it's passed directly on to the linker. OK? Wording changes? -eric 2014-07-15 Eric Christopher * doc/invoke.texi (Link Options): Document -z option. Index: gcc/doc/invoke.texi === --- gcc/doc/invoke

Re: [Info], Add suport for PowerPC IEEE 128-bit floating point

I did some timing tests to compare the new PowerPC IEEE 128-bit results to the current implementation of long double using the IBM extended format. The test consisted a short loop doing the operation over arrays of 1,024 elements, reading in two values, doing the operation, and then storing it bac

[C++ Patch/RFC] PR 50961

Hi, I have another half-baked issue about which I'd like to have some guidance... In this case too at least the draft patch works and passes the testsuite. Essentially, something seems missing in the way we handle operator! applied to a TEMPLATE_ID_EXPR, whereas the non-template version alre

Re: Some DWARFv5 proposal prototypes (atomic_type, aligned_type)

On Tue, Jul 15, 2014 at 4:36 AM, Mark Wielaard wrote: > On Mon, 2014-07-14 at 13:58 -0600, Tom Tromey wrote: >> > "Mark" == Mark Wielaard writes: >> Mark> The following two patches are based on the earlier "dwarf2out.c: Pass >> Mark> one cv_quals argument" and "Emit DW_tag_restrict_type" patc

Re: [PATCH, fortran testsuite]: A couple of fixes in gfortran.dg/ieee directory

> And yes, I learned in a hard way that there is a difference between > f90 and F90 file extension. Yup, pre-processing. Sorry I wasn’t fast enough to reply to your earlier email, and thanks for doing this. FX

C++ PATCH for c++/61723 (invalid std::initializer_list)

People keep submitting bug reports about the compiler crashing when they define std::initializer_list to something broken, so let's diagnose it. I'm not sure where these testcases are coming from, maybe creduce? Tested x86_64-pc-linux-gnu, applying to trunk. commit 853b9ecb5c8025c733c756bd9fb2

Re: symtab PATCH for c++/61623 (comdat issue in verify_symtab)

On 07/15/2014 04:46 AM, Jan Hubicka wrote: I think we still want to check that the local comdats are linked into the corresponding comdat group, so we probably want to test node->definition instead of node->public, or perhaps just clear COMDAT_GROUP info when removing symbol? Like this? commi

Re: [PATCH 2/2] PR preprocessor/60723 - missing system-ness marks for macro tokens

OK. Jason

Re: [PATCH 1/2] Support location tracking for built-in macro tokens

OK, thanks. Jason

Re: [PATCH, fortran testsuite]: A couple of fixes in gfortran.dg/ieee directory

On Tue, Jul 15, 2014 at 6:15 PM, Uros Bizjak wrote: > Attached trivial patch renames a couple of files to more consistent > names (as suggested by FX). > > The patch also adds -mieee-with-inexact for alpha where needed. > > 2014-07-15 Uros Bizjak > > * gfortran.dg/ieee/rounding_1.f90: Rena

Re: [PATCH, 5 of 5], Add suport for PowerPC IEEE 128-bit floating point

These patches are patches to the testsuite to add tests for IEEE 128-bit floating point. Both -mfloat128-vsx and -mfloat128-ref are tested in two tests. The first is a simple test whether it works, and the second test insures that we have at least 60 bits of accuracy in the mantissa. 2014-07-15

Re: [PATCH, 3 of 5], Add suport for PowerPC IEEE 128-bit floating point

These patches are the machine independent changes needed to add IEEE 128-bit floating point to the PowerPC. The change is to add a new mode macro, SPECIAL_FLOATING_MODE, that is similar to FRACTIONAL_FLOATING_MODE, except that the normal widening functions skip SPECIAL_FLOATING_MODE's modes. In p

Re: Move DECL_RESULT into function_decl

On 07/15/2014 11:29 AM, Jan Hubicka wrote: Yep, you are right. I was looking into this, too. I think dump_ada_template should be moved into C++ FE somehow because it deals with C++ trees. What would be most appropriate way to do so? I suppose we could pass a pointer to it into dump_ada_specs l

Re: [PATCH, 2 of 5], Add suport for PowerPC IEEE 128-bit floating point

These patches are the PowerPC specific patches to add IEEE 128-bit support to libgcc. These patches need to be co-ordinated with the glibc support that provides the software floating point emulation. The compiler patches need to be installed before these patches can be installed. 2014-07-15 Mic

Re: [PATCH, 1 of 5], Add suport for PowerPC IEEE 128-bit floating point

This patch is the machine independent patch for libgcc to add IEEE 128-bit floating point to the PowerPC. This patch allows the PowerPC port to override the TFtype in quad.h to allow it to use __float128 instead of attribute ((TF)). On most of the PowerPC systems, TFmode by default is the IBM ext

[PATCH, 0 of 5], Add suport for PowerPC IEEE 128-bit floating point

I will be submitting 5 patches in this thread to add support for IEEE 128-bit floating point on the PowerPC. I have tested this on power7 big endian systems, power8 big endian systems, and power8 little endian systems, and there were no regressions. Ideally, I would like to install this in trunk,

Re: [Patch] PR 61662

Hello! > The detailed description and examples can be found in pr61662, but in short: > using "#ifdef > __x86_64__" to determine the size of a 'long' does not reliably yield the > correct result. This > causes _lrotl and _lrotr to return incorrect results on LLP64 systems (like > Windows). > >

Re: [PATCH] PR preprocessor/60723 - missing system-ness marks for macro

Hello Nicholas, Nicholas Ormrod writes: [...] > If you are also going to fix the locations of built-in tokens, it > would also be worth adjusting their expansion locations. As mentioned > in the bug report, built-in tokens are expanded at the closing paren > of a macro call, whereas non-built-i

Re: [PATCH] Clarify always_inline docs, fix PR61782

On Tue, 15 Jul 2014, Richard Biener wrote: > Does this look ok? > 2014-07-15 Richard Biener > > PR other/61782 > * doc/extend.texi (always_inline): Clarify. Make sense to me and looks fine. Gerald

[PATCH, fortran testsuite]: A couple of fixes in gfortran.dg/ieee directory

Hello! Attached trivial patch renames a couple of files to more consistent names (as suggested by FX). The patch also adds -mieee-with-inexact for alpha where needed. 2014-07-15 Uros Bizjak * gfortran.dg/ieee/rounding_1.f90: Rename from ieee_rounding_1.f90. * gfortran.dg/ieee/ieee_1.

Re: [GSoC] generation of Gimple code from isl_ast_node_user

On 15/07/2014 16:59, Roman Gareev wrote: >> >This is a pure style change which seems unrelated. Also, is the original >line really too long? I may have miscounted, but it seems to fit >exactly. If I am not mistaken, lines should be limited to 80 characters, according to conventions, which are m

Re: [PATCH, alpha]: Add TARGET_ATOMIC_ASSIGN_EXPAND_FENV hook

On Sat, Jul 12, 2014 at 12:19 AM, Uros Bizjak wrote: > Attached patch implements TARGET_ATOMIC_ASSIGN_EXPAND_FENV hook for > alpha. The implementation is mostly copied from arm/arm.c, where calls > to target builtins are replaced with calls to > __ieee_{get,set}_fp_control function, as defined in

Re: [GOOGLE] Rewrite FUNCTION_DECL references after LIPO linking

ok. This is now consistent with how cgraph targets are handled. (Changes like this may shake up more bugs due to bad assumptions. More extensive testing after this is expected). David On Tue, Jul 15, 2014 at 3:24 AM, Teresa Johnson wrote: > This patch will rewrite references to function decls in

Re: [GSoC] Addition of ISL AST generation to Graphite

On 15/07/2014 17:02, Roman Gareev wrote: I'm seeing the error: gcc/graphite-isl-ast-to-gimple.c:31:25: warning: isl/val_gmp.h: No such file or directory when building for aarch64. isl/val_gmp.h is included in 0.12 AFAICS so perhaps we should demand 0.12 instead of 0.11 ? According to isl's C

Re: Move DECL_RESULT into function_decl

> On 07/15/2014 10:19 AM, Jan Hubicka wrote: > >@@ -1722,7 +1722,7 @@ dump_ada_template (pretty_printer *buffe > >/* DECL_VINDEX is DECL_TEMPLATE_INSTANTIATIONS in this context. */ > >tree inst = DECL_VINDEX (t); > >/* DECL_RESULT_FLD is DECL_TEMPLATE_RESULT in this context. */ > >-

Re: [RFC, rs6000, v2] Fix alignment of non-Altivec vector struct fields

Richard Biener wrote: > On Mon, Jul 14, 2014 at 8:55 PM, Ulrich Weigand wrote: > > Hello, > > > > this is an attempt to update the prior patch: > > https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00635.html > > to add a -Wpsabi note as discussed. > > > > However, this is causing a bit of difficultie

Re: Move DECL_RESULT into function_decl

On 07/15/2014 10:19 AM, Jan Hubicka wrote: @@ -1722,7 +1722,7 @@ dump_ada_template (pretty_printer *buffe /* DECL_VINDEX is DECL_TEMPLATE_INSTANTIATIONS in this context. */ tree inst = DECL_VINDEX (t); /* DECL_RESULT_FLD is DECL_TEMPLATE_RESULT in this context. */ - tree result = D

Re: [GSoC] generation of Gimple loops with empty bodies

I've found out that int128_integer_type_node and long_long_integer_type_node are NULL at the moment of definition of the graphite_expression_size_type. Maybe we should use long_long_integer_type_node, because, as you said before, using of signed 64 has also been proved to be very robust. What do yo

Re: [GSoC] Addition of ISL AST generation to Graphite

> I'm seeing the error: > > gcc/graphite-isl-ast-to-gimple.c:31:25: warning: isl/val_gmp.h: No such file > or directory > > when building for aarch64. > > isl/val_gmp.h is included in 0.12 AFAICS so perhaps we should demand 0.12 > instead of 0.11 ? According to isl's ChangeLog, isl_val abstraction

Re: [GSoC] generation of Gimple code from isl_ast_node_user

> No, no idea. To my understanding the entry block should not even appear > within a scop (see build_scops, where we only start detecting scops at > the successor of the entry_block). Maybe we replace this with an assert > to get a good error message in case I have missed something. Yes, I think t

Move DECL_RESULT into function_decl

Hi, this patch continues by moving DECL_RESULT into FUNCTION_DECL. tree_decl_non_common becomes empty, but I decided to get rid of it in an followup patch - it needs more changes and doing it all at once would be bit convoluted. Bootstrappred/regtested x86_64-linux, OK? Honza * tree-co

Re: [PATCH 1/2] Support location tracking for built-in macro tokens

I forgot to say that ... Dodji Seketeli writes: [...] > When a built-in macro is expanded, the location of the token in the > epansion list is the location of the expansion point of the built-in > macro. > > This patch creates a virtual location for that token instead, > effectively tracking lo

Re: [PATCH, i386] Add prefixes avoidance tuning for silvermont target

On Tue, Jul 15, 2014 at 1:01 PM, Ilya Enkovich wrote: > On 15 Jul 10:42, Uros Bizjak wrote: >> On Tue, Jul 15, 2014 at 10:25 AM, Ilya Enkovich >> wrote: >> >> > Also fully restrict xmm8-15 does not seem right. It is just costly >> > but not fully disallowed. >> >> As said earl

[PATCH 2/2] PR preprocessor/60723 - missing system-ness marks for macro tokens

Hello, When a system macro is expanded in a non-system file during out-of-line preprocessing, it can happen that the preprocessor forgets to emit line markers to express the system-ness status of tokens that come after the expansion of the macro. That can lead to situations where the entire non-s

[PATCH 1/2] Support location tracking for built-in macro tokens

Hello, When a built-in macro is expanded, the location of the token in the epansion list is the location of the expansion point of the built-in macro. This patch creates a virtual location for that token instead, effectively tracking locations of tokens resulting from built-in macro tokens. libc

[C++ Patch, committed] Small diagnostic fix

Hi, while looking into an old issue I noticed that in one place we don't check the return value of permerror. I'm going to commit the below as obvious. Thanks, Paolo. // 2014-07-15 Paolo Carlini * call.c (convert_like_real): Call print_z_candidate and inform only

Re: [PATCH] PR preprocessor/60723 - missing system-ness marks for macro

Hello, Jason Merrill writes: >> // preprocessed output >> # 3 "test.cpp" 3 4 >> sys_token >> # 3 "test.cpp" >> 3 >> # 3 "test.cpp" 3 4 >> sys_token >>> Yeah. For Built-in tokens that are expanded like that we only do track their the location of their expans

Re: calloc = malloc + memset

On Tue, Jul 15, 2014 at 2:33 PM, Bernd Schmidt wrote: > On 02/28/2014 11:48 PM, Marc Glisse wrote: >> >> /* Optimize >> + ptr = malloc (n); >> + memset (ptr, 0, n); >> + into >> + ptr = calloc (n); >> + gsi_p is known to point to a call to __builtin_memset. */ > > > Is there anything in

Re: calloc = malloc + memset

On 02/28/2014 11:48 PM, Marc Glisse wrote: /* Optimize + ptr = malloc (n); + memset (ptr, 0, n); + into + ptr = calloc (n); + gsi_p is known to point to a call to __builtin_memset. */ Is there anything in here to prevent us making an infinite loop if the above pattern occurs in a fu

[PATCH][match-and-simplify] Remove broken duplicate pattern

Committed. Richard. 2014-07-15 Richard Biener * match.pd: Remove duplicated and broken rotate pattern. Index: gcc/match.pd === --- gcc/match.pd(revision 212544) +++ gcc/match.pd(working copy) @@ -351,15

[PATCH] Clarify always_inline docs, fix PR61782

The following tries to clarify the always_inline docs, in particular that it applies to non-O0 as well and what the failure mode is (derived from how our implementation behaves). Does this look ok? Thanks, Richard. 2014-07-15 Richard Biener PR other/61782 * doc/extend.texi (

Re: [patch] Add libstdc++ pretty printers for Library Fundamentals TS types

On 14/07/14 20:31 +0100, Jonathan Wakely wrote: This adds printers for the types in the std::experimental namespace. I've committed this slightly improved patch, which removes the duplicate _contained method from StdExpOptionalPrinter (it was meant to be using the base class version) and fixes

[PATCH] Disable bit-CCP at -Og

The following disables bit-CCP (which can cause quite some iteration with loops) at -Og. Bootstrapped on x86_64-unknown-linux-gnu, testing in progress. Richard. 2014-07-15 Richard Biener * opts.c (default_options_table): Disable bit-ccp at -Og. Index: gcc/opts.c ===

[PATCH] Limit combines work at -Og, introduce --param max-combine-insns

The following introduces a new param, max-combine-insns, to be able to limit the work done at -Og to linear complexity in the number of log-links (thus, two-insn combines). It also records statistics of performed combines where for fold-const.ii on x86_64 we see at -Og (unpatched): 208 combine "

Re: [PATCH 1/7] Add missing documentation of four IPA-CP params

On Mon, Jun 30, 2014 at 01:06:55AM +0200, Gerald Pfeifer wrote: > On Tue, 10 Jun 2014, Gerald Pfeifer wrote: > > On Wed, 21 May 2014, Martin Jambor wrote: > >> +@item ipa-cp-loop-hint-bonus > >> +When IPA-CP determines that a cloning candidate would make the number > >> +of iterations of a loop kno

Re: [patch] Add libstdc++ type printers for class templates

On 15/07/14 00:50 +0100, Jonathan Wakely wrote: One part of the patch I wasn't sure about was this, where 'mgr' is a function pointer: func = gdb.block_for_pc(int(mgr.cast(gdb.lookup_type('intptr_t' Is there a better way to get a pc from the function pointer? I tried simply int(mgr) but it

Re: Some DWARFv5 proposal prototypes (atomic_type, aligned_type)

On Mon, 2014-07-14 at 13:58 -0600, Tom Tromey wrote: > > "Mark" == Mark Wielaard writes: > Mark> The following two patches are based on the earlier "dwarf2out.c: Pass > Mark> one cv_quals argument" and "Emit DW_tag_restrict_type" patches I posted > Mark> earlier. Since there currently is not e

Re: [patch] fix the uninitialized variable problem in avx512f-vbroadcastf64x4-2.c

On Tue, Jul 15, 2014 at 12:28 PM, Petr Murzin wrote: > Hi, > I've fixed the uninitialized variable problem. Please have a look. Is > it ok for trunk? > > 2014-07-15 Petr Murzin > > * gcc.target/i386/avx512f-vbroadcastf64x4-2.c: Fix the uninitialized > variable problem. OK. Thanks, Uros.

Re: [PATCH, i386] Add prefixes avoidance tuning for silvermont target

On 15 Jul 10:42, Uros Bizjak wrote: > On Tue, Jul 15, 2014 at 10:25 AM, Ilya Enkovich > wrote: > > > Also fully restrict xmm8-15 does not seem right. It is just costly > > but not fully disallowed. > > As said earlier, you can try "Ya*x" as a constraint. > >>> > >>> I tried it

Re: [PATCH] Fix ubsan ICE with flexible array members

On Tue, Jul 15, 2014 at 01:01:10PM +0200, Marek Polacek wrote: > We were missing a check that the TYPE_MAX_VALUE is not NULL. > If it is, we ICE later when gimplifying the UBSAN_BOUNDS call arguments. > > Bootstrapped/regtested on x86_64-linux, ok for trunk? Ok, thanks. > > 2014-07-15 Marek Pol

[PATCH] Fix ubsan ICE with flexible array members

We were missing a check that the TYPE_MAX_VALUE is not NULL. If it is, we ICE later when gimplifying the UBSAN_BOUNDS call arguments. Bootstrapped/regtested on x86_64-linux, ok for trunk? 2014-07-15 Marek Polacek * c-ubsan.c (ubsan_instrument_bounds): Don't instrument if TYPE_

[PATCH][match-and-simplify] Fix equality check of matches

We don't share all trees for things we want to prove equivalent (FP constants for example). Bootstrapped on x86_64-unknown-linux-gnu, installed. Richard. 2014-07-15 Richard Biener * genmatch.c (dt_operand::gen_match_op): Fall back to use operand_equal_p if literal equality d

[patch] fix the uninitialized variable problem in avx512f-vbroadcastf64x4-2.c

Hi, I've fixed the uninitialized variable problem. Please have a look. Is it ok for trunk? 2014-07-15 Petr Murzin * gcc.target/i386/avx512f-vbroadcastf64x4-2.c: Fix the uninitialized variable problem. patch Description: Binary data

[GOOGLE] Rewrite FUNCTION_DECL references after LIPO linking

This patch will rewrite references to function decls in all statements after LIPO linking so that the subsequent cgraph rebuild will set up references correctly. Passes regression and internal testing. Ok for google/4_9? Thanks, Teresa 2014-07-15 Teresa Johnson Google ref b/16190119

Re: [RFC, PATCH 1/n] IPA C++ refactoring

> I tried to mark it as protected, by there's usage that blocks that: > > In file included from ../../gcc/symtab.c:40:0: > ../../gcc/cgraph.h: In member function ?void symtab_node::unregister()?: > ../../gcc/cgraph.h:1178:16: error: ?cgraph_node* > cgraph_node::find_replacement()? is protected >

[patch, avr] atmel avr new devices set-4

Hi, Attached patch adds support for new Atmel xmega devices (atxmega8e5, atxmega16e5, atxmega32c3, atxmega32d3). This patch is continuation of patch in https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01038.html If OK, could someone commit please? Regards, Pitchumani gcc/ChangeLog 2014-07-15 Pi

[PATCH][match-and-simplify] Fix bootstrap

GENERIC code-path checking TREE_SIDE_EFFECTS ICEs on NULL ops (obviously). Guard against that. Bootstrapped on x86_64-unknown-linux-gnu, applied. Richard. 2014-07-15 Richard Biener * genmatch.c (decision_tree::gen_generic): Guard against NULL_TREE operands. Index: genmatch

Re: Strenghten assumption about dynamic type changes (placement new)

> > On 07/02/2014 01:18 PM, Jan Hubicka wrote: > > >We propagate types from places we know instances are created across > > >pointers > > >passed to functions. Once non-POD type is created at a given memory > > >location, > > >one can not change its type by placement_new into something else. > >

Re: [GOMP4, RFC] OpenMP4 offload support for Intel PHI targets.

Hello, > Unfortunately currently it’s impossible to run make check-target-libgomp > from the build dir, since both accel- and host-compilers need to be installed > into the same dir, otherwise host’s gcc will not find accel’s mkoffload. We found workaround to allow make check-target-libgomp. So, he

[patch, avr] atmel avr new devices set-3

Hi, Attached patch adds support for following Atmel devices. ata5702m322 atmega325pa atmega64hve2 atmega644rfr2 atmega128rfr2 atmega1284rfr2 atmega256rfr2 atmega2564rfr2 If OK, could someone commit please? Regards, Pitchumani gcc/ChangeLog 2014-07-15 Pitchumani Sivanupandi * config/avr/

Re: symtab PATCH for c++/61623 (comdat issue in verify_symtab)

> The problem in this testcase is that we inlined the decloned > constructor into the calling thunks, so it was removed by > symtab_remove_unreachable_nodes. verify_symtab sees that it is no > longer linked to the calling thunks with same_comdat_group and > complains. > > Here I've changed verify

Re: [PATCH, i386] Add prefixes avoidance tuning for silvermont target

On Tue, Jul 15, 2014 at 10:25 AM, Ilya Enkovich wrote: > Also fully restrict xmm8-15 does not seem right. It is just costly > but not fully disallowed. As said earlier, you can try "Ya*x" as a constraint. >>> >>> I tried it. It does not seem to affect allocation much. I do not

[PATCH] Do emit certain artificial names into DW_AT_name in debug info

On Fri, Jul 23, 2010 at 02:00:11PM +0200, Jakub Jelinek wrote: > On Thu, Jul 22, 2010 at 12:19:35PM -0700, Roland McGrath wrote: > > Similarly: > > > > > location={locexpr}/> > > > > Should that really have a name? As it stands, the debugger is going to > > present ".omp_data_i" as a resolv

Re: [RFC, rs6000, v2] Fix alignment of non-Altivec vector struct fields

On Mon, Jul 14, 2014 at 8:55 PM, Ulrich Weigand wrote: > Hello, > > this is an attempt to update the prior patch: > https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00635.html > to add a -Wpsabi note as discussed. > > However, this is causing a bit of difficulties. First of all, the warning > trigge

Re: [PATCH, i386] Add prefixes avoidance tuning for silvermont target

2014-07-14 23:58 GMT+04:00 Uros Bizjak : > On Thu, Jul 3, 2014 at 3:38 PM, Ilya Enkovich wrote: >> 2014-07-03 16:07 GMT+04:00 Uros Bizjak : >>> On Thu, Jul 3, 2014 at 1:50 PM, Ilya Enkovich >>> wrote: >>> I didn't find a nice way to fix peephole2 patterns to take register constraints i

Re: [PATCH][www] disallow /git/ in robots.txt

On Tue, 15 Jul 2014, Gerald Pfeifer wrote: > On Tue, 15 Jul 2014, Richard Biener wrote: > > Seems like somebody is mirroring gitweb urls. > > > > 2014-07-15 Richard Biener > > > > * robots.txt: Disallow /git/ > > Makes sense. (I checked, and we already block /svn and /viewcvs.) > > How

[PATCH] Fix -imacros (PR c/57653)

This is a revised patch that Peter recently submitted , but it was lacking a testcase and a better comment. This patch adds a testcase (kind of a hacky one), the comment is hopefully better too. Joseph already said that the code changes lo

[PATCH][match-and-simplify] Silence genmatch, add -v flag

This adds a verbose -v argument to genmatch and silences it by default. Committed. Richard. 2014-07-15 Richard Biener * genmatch.c (main): Add -v flag and guard debug dumps on it. Index: gcc/genmatch.c === --- gcc/genm

[PATCH][match-and-simplify] "Handle" TREE_SIDE_EFFECTS operands properly

This handles them by not simplifying anything (for now). It also fixes two warnings that prevent bootstrap. Committed. Richard. 2014-07-15 Richard Biener * genmatch.c (decision_tree::gen_generic): Reject operands with TREE_SIDE_EFFECTS for now. (parse_for): Drop nam

Re: [GSoC] symbol to denote multiple operators

On Mon, Jul 14, 2014 at 8:40 PM, Prathamesh Kulkarni wrote: > On Mon, Jul 14, 2014 at 5:36 PM, Richard Biener > wrote: >> On Fri, Jul 11, 2014 at 4:59 PM, Prathamesh Kulkarni >> wrote: >>> On 7/11/14, Richard Biener wrote: On Thu, Jul 10, 2014 at 8:05 PM, Prathamesh Kulkarni wrote: >

Re: [PATCH][www] disallow /git/ in robots.txt

On Tue, Jul 15, 2014 at 09:54:02AM +0200, Gerald Pfeifer wrote: > On Tue, 15 Jul 2014, Richard Biener wrote: > > Seems like somebody is mirroring gitweb urls. > > > > 2014-07-15 Richard Biener > > > > * robots.txt: Disallow /git/ > > Makes sense. (I checked, and we already block /svn and

Re: [PATCH][www] disallow /git/ in robots.txt

On Tue, 15 Jul 2014, Richard Biener wrote: > Seems like somebody is mirroring gitweb urls. > > 2014-07-15 Richard Biener > > * robots.txt: Disallow /git/ Makes sense. (I checked, and we already block /svn and /viewcvs.) How did you find out? Gerald

[PATCH][www] disallow /git/ in robots.txt

Seems like somebody is mirroring gitweb urls. Committed as obvious. Richard. 2014-07-15 Richard Biener * robots.txt: Disallow /git/ Index: robots.txt === RCS file: /cvs/gcc/wwwdocs/htdocs/robots.txt,v retrieving revisio