Re: RFC: Faster for_each_rtx-like iterators

Richard Sandiford writes: > Trevor Saunders writes: >> On Wed, May 07, 2014 at 09:52:49PM +0100, Richard Sandiford wrote: >>> I noticed for_each_rtx showing up in profiles and thought I'd have a go >>> at using worklist-based iterators instead. So far I have three: >>> >>> FOR_EACH_SUBRTX: it

Re: RFC: Faster for_each_rtx-like iterators

Trevor Saunders writes: > On Wed, May 07, 2014 at 09:52:49PM +0100, Richard Sandiford wrote: >> I noticed for_each_rtx showing up in profiles and thought I'd have a go >> at using worklist-based iterators instead. So far I have three: >> >> FOR_EACH_SUBRTX: iterates over const_rtx subrtxes of

Re: [patch] change specific int128 -> generic intN

> OK (presuming the usual bootstrap and regression test, which should > provide a reasonably thorough test of this code through the > tests). Bootstrapped with and without the patch on x86-64, no regressions. Committed. Thanks!

Re: genattrtab error reporting

On May 7, 2014, at 6:12 PM, Segher Boessenkool wrote: >>> Does this fix >>> >>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31778 >> >> Only if it is applied to the tree! :-) Yes. > > It also is PR57062. Thanks for fixing it! Thanks, marked as dup.

Re: [RS6000] PR60737, expand_block_clear uses word stores

On Wed, May 07, 2014 at 01:39:50PM -0400, David Edelsohn wrote: > On Tue, May 6, 2014 at 4:32 AM, Alan Modra wrote: > > BTW, the latest patch in my tree has a slight refinement, the > > reload-by-hand addition. > > > > PR target/60737 > > * config/rs6000/rs6000.c (expand_block_move

[RS6000] Fix PR61098, Poor code setting count register

On powerpc64, to set a large loop count we have code like the following after split1: (insn 67 14 68 4 (set (reg:DI 160) (const_int 99942400 [0x5f5])) /home/amodra/unaligned_load.c:14 -1 (nil)) (insn 68 67 42 4 (set (reg:DI 160) (ior:DI (reg:DI 160) (const_int

Re: RFC: Faster for_each_rtx-like iterators

On Wed, May 07, 2014 at 09:52:49PM +0100, Richard Sandiford wrote: > I noticed for_each_rtx showing up in profiles and thought I'd have a go > at using worklist-based iterators instead. So far I have three: > > FOR_EACH_SUBRTX: iterates over const_rtx subrtxes of a const_rtx > FOR_EACH_SUBRTX

Re: genattrtab error reporting

> > Does this fix > > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31778 > > Only if it is applied to the tree! :-) Yes. It also is PR57062. Thanks for fixing it! Segher

Fix some tests for TARGET_SSE_PACKED_SINGLE_INSN_OPTIMAL

Having fixed TARGET_SSE_PACKED_SINGLE_INSN_OPTIMAL to apply only to 128-bit vectors, some --with-arch=bdver3 --with-cpu=bdver3 scan-assembler failures relating to that tuning remain, because of different choices of instructions for 128-bit vectors from the choices expected by the tests. This patch

[v3] Mini-tweak to acinclude.m4

Hi, I don't think we have any reason to trigger a -Wwrite-strings warning, thus, barring objections, I'm going to commit the below. Thanks, Paolo. /// 2014-05-08 Paolo Carlini * acinclude.m4 ([GLIBCXX_ENABLE_C99]): Avoid -Wwrite-strings warning. * confi

Re: genattrtab error reporting

On May 7, 2014, at 5:22 PM, H.J. Lu wrote: > On Wed, May 7, 2014 at 2:21 PM, Mike Stump wrote: >> getattrtab looses track of which file the given rtl came from during error >> reporting. A port that uses multiple .md files for the port will tend to >> list the last .md file processed instead o

Re: genattrtab error reporting

On Wed, May 7, 2014 at 2:21 PM, Mike Stump wrote: > getattrtab looses track of which file the given rtl came from during error > reporting. A port that uses multiple .md files for the port will tend to > list the last .md file processed instead of the correct md file. We preserve > the filena

Re: [PATCH, PR58066] preferred_stack_boundary update for tls expanded call

This is the updated patch of pr58066-3.patch. The calls added in the templates of tls_local_dynamic_base_32 and tls_global_dynamic_32 in pr58066-3.patch are used to prevent sched2 from moving sp setting across implicit tls calls, but those calls make the combine of UNSPEC_TLS_LD_BASE and UNSPEC_DT

AutoFDO profile toolchain is open-sourced

We have open-sourced AutoFDO profile toolchain in: https://github.com/google/autofdo For GCC developers, the most important tool is create_gcov, which converts sampling based profile to GCC-readable profile. Please refer to the readme file (https://raw.githubusercontent.com/google/autofdo/master/

libgo patch committed: Define more TIOC constants

This patch to libgo defines more TIOC constants, constants that are non-trivial constants on GNU/Linux systems. Boostrapped and ran Go testsuite on x86_64-unknown-linux-gnu. Committed to mainline and 4.9 branch. Ian diff -r bbf6c7c22954 libgo/mksysinfo.sh --- a/libgo/mksysinfo.sh Wed May 07 14:

libgo patch committed: Define CLONE flags in syscall package

Domink Vogt pointed out that the gccgo syscall package does not define the CLONE flags. This patch defines them. Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu. Committed to mainline and 4.9 branch. Ian diff -r c8ae29f0c4c6 libgo/configure.ac --- a/libgo/configure.ac Tue May 06

Re: [PATCH] AutoFDO patch for trunk

Have you announced the autofdo profile tool to gcc list? David On Wed, May 7, 2014 at 2:24 PM, Dehao Chen wrote: > Hi, > > I'm planning to port the AutoFDO patch upstream. Attached is the > prepared patch. You can also find the patch in > http://codereview.appspot.com/99010043 > > I've tested th

Re: RFC: Faster for_each_rtx-like iterators

On May 7, 2014, at 1:52 PM, Richard Sandiford wrote: > > I've locally replaced all for_each_rtx calls in the generic code with > these iterators and they make things reproducably faster. The speed-up > on full --enable-checking=release ./cc1 and ./cc1plus times is only about 1%, > but maybe tha

genattrtab error reporting

getattrtab looses track of which file the given rtl came from during error reporting. A port that uses multiple .md files for the port will tend to list the last .md file processed instead of the correct md file. We preserve the filename upon read, and during post processing, we reset the file

RFC: Faster for_each_rtx-like iterators

I noticed for_each_rtx showing up in profiles and thought I'd have a go at using worklist-based iterators instead. So far I have three: FOR_EACH_SUBRTX: iterates over const_rtx subrtxes of a const_rtx FOR_EACH_SUBRTX_VAR: iterates over rtx subrtxes of an rtx FOR_EACH_SUBRTX_PTR: iterates ov

Re: [patch libgcc]: Fix PR c++/57440

2014-05-07 21:41 GMT+02:00 Jonathan Wakely : > On 7 May 2014 20:06, Kai Tietz wrote: >> >> PR c++/57440 > > N.B. that should be libstdc++/57440 in the ChangeLog Oh, yes of course. Thanks. Kai

[SH, committeð] PR 60884 - reduce code size of inlined strlen

Hi, The attached patch reduces the code size of inlined builtin strlen functions on SH a little bit. Tested on r210083 with make -k check RUNTESTFLAGS="--target_board=sh-sim \{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}" and no new failures, except for gcc.target/sh/pr53976-1.c on

Re: [patch libgcc]: Fix PR c++/57440

On 7 May 2014 20:06, Kai Tietz wrote: > > PR c++/57440 N.B. that should be libstdc++/57440 in the ChangeLog

Committed: [PATCH 19/89] Const-correctness of gimple_call_builtin_p

On Mon, 2014-04-21 at 12:56 -0400, David Malcolm wrote: > gcc/ > * gimple.h (gimple_builtin_call_types_compatible_p): Accept a > const_gimple, rather than a gimple. > (gimple_call_builtin_p): Likewise, for the three variants. > > * gimple.c (gimple_builtin_call_types_compat

RE: [PATCH, MIPS] Alter default number of single-precision registers

Richard Sandiford writes: > Matthew Fortune writes: > > diff --git a/gcc/testsuite/gcc.target/mips/oddspreg-6.c > b/gcc/testsuite/gcc.target/mips/oddspreg-6.c > > new file mode 100644 > > index 000..2d1b129 > > --- /dev/null > > +++ b/gcc/testsuite/gcc.target/mips/oddspreg-6.c > > @@ -0,0 +1,

[jit] Add a soname

gcc/jit/ * Make-lang.in (LIBGCCJIT_LINKER_NAME): New. (LIBGCCJIT_VERSION_NUM): New. (LIBGCCJIT_MINOR_NUM): New. (LIBGCCJIT_RELEASE_NUM): New. (LIBGCCJIT_SONAME): New. (LIBGCCJIT_FILENAME): New. (LIBGCCJIT_LINKER_NAME_SYMLINK): New. (LI

Re: [PATCH, MIPS] Alter default number of single-precision registers

Matthew Fortune writes: > diff --git a/gcc/testsuite/gcc.target/mips/oddspreg-6.c > b/gcc/testsuite/gcc.target/mips/oddspreg-6.c > new file mode 100644 > index 000..2d1b129 > --- /dev/null > +++ b/gcc/testsuite/gcc.target/mips/oddspreg-6.c > @@ -0,0 +1,15 @@ > +/* Check that we disable odd-nu

[patch libgcc]: Fix PR c++/57440

Hi, this patch adds for Windows targets the define _GTHREAD_USE_MUTEX_INIT_FUNC, which is necessary as pthread-emulation for those targets are just handling pthread_mutext_init, othread_mutex_destroy proper. ChangeLog libgcc 2014-05-07 Kai Tietz PR c++/57440 * gthr-posix.h (_

Re: [C++ Patch] PR 61083

On 05/07/2014 01:15 PM, Paolo Carlini wrote: curiously, convert_nontype_argument still has most of its error calls not protected by complain & tf_error. The obvious fix works for this SFINAE issue. Not a regression, but could be safe for the branch too? Sure, OK for trunk and 4.9. Jason

Re: [C PATCH] Don't reject valid code with _Alignas (PR c/61053)

On Wed, May 7, 2014 at 10:15 AM, Joseph S. Myers wrote: > On Mon, 5 May 2014, Marek Polacek wrote: > >> In this PR the issue is that we reject (valid) code such as >> _Alignas (long long) long long foo; >> with -m32, because we trip this condition: >> >>alignas_align = 1U << declspecs->align_l

[committed] PR 61095: tsan fallout from wide-int merge

This PR was due to code in which -(int) foo was suposed to be sign-extended, but was being ORed with an unsigned int and so ended up being zero-extended. Fixed by using the proper-width type. Tested on x86_64-linux-gnu and applied as obvious. Sorry for the breakage. Thanks, Richard gcc/

Re: [PATCH GCC]Add 'force-dwarf-lexical-blocks' command line option

On May 7, 2014, at 10:19 AM, Herman, Andrei wrote: > Thanks for the suggestion. > I can add the suggested sentence at the beginning of the description, to save > time for users not interested in the more detailed explanation. I’d put it at the end… I think the description you have it more imp

Re: [PATCH GCC]Add 'force-dwarf-lexical-blocks' command line option

On Wed, 7 May 2014, Herman, Andrei wrote: > When this flag is set, a DW_TAG_lexical_block DIE will be emitted for every > function body, loop body, switch body, case statement, if-then and if-else > statement, even if the body is a single statement. > Likewise, a lexical block will be emitted for

Re: [C PATCH] Warn about variadic main (PR c/60156)

On Tue, 6 May 2014, Marek Polacek wrote: > On Thu, May 01, 2014 at 11:37:58PM +, Joseph S. Myers wrote: > > As a matter of QoI we should also diagnose use of _Atomic in the return > > type or argument types of main (something I deferred doing in the initial > > _Atomic support). > > Ok, I o

Re: [PATCH GCC]Add 'force-dwarf-lexical-blocks' command line option

On Wed, May 7, 2014 at 10:19 AM, Herman, Andrei wrote: > Thanks for the suggestion. > The current patch includes the following text added in gcc/doc/invoke.texi: > > @item -fforce-dwarf-lexical-blocks > Produce debug information (a DW_TAG_lexical_block) for every function > body, loop body, switch

RE: [PATCH GCC]Add 'force-dwarf-lexical-blocks' command line option

Thanks for the suggestion. The current patch includes the following text added in gcc/doc/invoke.texi: @item -fforce-dwarf-lexical-blocks Produce debug information (a DW_TAG_lexical_block) for every function body, loop body, switch body, case statement, if-then and if-else statement, even if the b

[C++ Patch] PR 61083

Hi, curiously, convert_nontype_argument still has most of its error calls not protected by complain & tf_error. The obvious fix works for this SFINAE issue. Not a regression, but could be safe for the branch too? Tested x86_64-linux. Thanks, Paolo. // /cp 2014-05-07 Pao

Re: [C PATCH] Don't reject valid code with _Alignas (PR c/61053)

On Mon, 5 May 2014, Marek Polacek wrote: > In this PR the issue is that we reject (valid) code such as > _Alignas (long long) long long foo; > with -m32, because we trip this condition: > >alignas_align = 1U << declspecs->align_log; >if (alignas_align < TYPE_ALIGN_UNIT (type)) > { >

Re: [DOC PATCH] Rewrite docs for inline asm

On Mon, 5 May 2014, Gerald Pfeifer wrote: > > I've changed this to @code{"="}. Is that what you meant? > > This is a question for Joseph. I see how a single character > under @code{} won't work, yet @code{"="} doesn't feel right, > either. Perhaps ``@code{=}''? If you are referring to an actu

Re: [patch] change specific int128 -> generic intN

On Sun, 4 May 2014, DJ Delorie wrote: > > I'm not aware of any reason those macros need to have decimal values. I'd > > suggest removing the precomputed table and printing them in hex, which is > > easy for values of any precision. > > Here's an independent change that removes the decimal tabl

Re: [SH, committed] Fix PR 61026 sh-*-* Fails to Compile on FreeBSD

On Sat, 3 May 2014, Oleg Endo wrote: > +#include > +#include > +#include > + > #include "config.h" It's never OK to include any system headers (C or C++) before "config.h". config.h may define feature test macros such as _FILE_OFFSET_BITS that affect system headers in various ways and are

Re: [PATCH, PR 60897] Clear DECL_LANG_SPECIFIC when creating ISRA clones

On May 7, 2014 5:30:53 PM CEST, Martin Jambor wrote: >Hi, > >I nearly forgot about this patch to fix PR 60897 where we get a >mangled name in a warning for IPA-SRA functions because IPA-SRA >currently does not clear DECL_LANG_SPECIFIC when it messes with formal >parameters and the front-end then d

[4.7] Various backports

Hi! I've backported some fixes I've committed (plus one support change from Jason and one fix from Marek) to 4.8 branch in the last year or so to 4.7 branch, after bootstrapping/regtesting them on x86_64-linux and i686-linux. Sorry for the delay. Jakub 2014-05-07 Jakub Jelinek

Re: [PATCH] rs6000: New attributes for load/store: "sign_extend", "update" and "indexed"

On Sun, May 4, 2014 at 10:13 PM, Segher Boessenkool wrote: > The new attributes replace the instruction types *_ext*, *_u, *_ux. > > This simplifies all code that does not care about the addressing modes, > putting the burden on the code that does care (mostly the scheduling > descriptions for cer

Re: [PATCH GCC]Add 'force-dwarf-lexical-blocks' command line option

On May 7, 2014, at 2:32 AM, Herman, Andrei wrote: > However, code coverage tools that process the DWARF debug information to > implement block/path coverage need more complete lexical block information. So, it would be nice to give a hint in the actual documentation, why a user might use the f

Re: PR 61084: SPARC fallout from wide-int merge

Mike Stump writes: > On May 7, 2014, at 2:26 AM, Richard Sandiford > wrote: >> The DImode constant spliiter assigned the result of trunc_int_for_mode >> to an unsigned int rather than a HOST_WIDE_INT. This then produced >> const_ints >> that were zero-extended rather than sign-extended and trip

[PATCH] copyprop_hardreg_forward needs to check HARD_REGNO_CALL_PART_CLOBBERED

The MIPS O32 FPXX ABI exposes a bug in regcprop where call part clobbered information is not checked when calculating clobbered registers. This is only one of many places that regs_invalidated_by_call is used without also checking HARD_REGNO_CALL_PART_CLOBBERED. This patch ensures that a part cl

[Committed] Add myself to MAINTAINERS

Committed as r210164. Index: MAINTAINERS === --- MAINTAINERS (revision 210161) +++ MAINTAINERS (working copy) @@ -315,6 +315,7 @@ Simon Baldwin sim...@google.com Scott Bambrough

Re: [C++ PATCH] demangler fix

OK, thanks. Jason

Re: PR 61084: SPARC fallout from wide-int merge

On May 7, 2014, at 2:26 AM, Richard Sandiford wrote: > The DImode constant spliiter assigned the result of trunc_int_for_mode > to an unsigned int rather than a HOST_WIDE_INT. This then produced const_ints > that were zero-extended rather than sign-extended and tripped the assert: > > gcc

[C++ PATCH] demangler fix

Hi all, A patch I committed to libiberty last year [1, 2] caused a regression that caused the demangler to segfault on certain symbols [3, 4, 5, 6]. The attached patch fixes, and adds regression tests for all symbols referenced in those bugs. Ok to commit? Thanks, Gary -- http://gbenson.net/ [

Re: [PATCH] Fix GDB PR15559 (inferior calls using "thiscall" calling convention)

Tom> The usual approach is some appropriate text somewhere on the GCC wiki Tom> (though I suppose a note in the mail archives would do in a pinch) Tom> along with a URL in a comment in the appropriate file (dwarf2.h or Tom> dwarf2.def). Tom> Could you please do that? Julian> How's this, as a firs

[PATCH, PR 60897] Clear DECL_LANG_SPECIFIC when creating ISRA clones

Hi, I nearly forgot about this patch to fix PR 60897 where we get a mangled name in a warning for IPA-SRA functions because IPA-SRA currently does not clear DECL_LANG_SPECIFIC when it messes with formal parameters and the front-end then does not look at abstract origin when it is not NULL. Bootst

Re: [Patch ARM 1/3] Neon intrinsics TLC : Replace intrinsics with GNU C implementations where possible.

On 28/04/14 14:01, Ramana Radhakrishnan wrote: > > On Mon, Apr 28, 2014 at 12:44 PM, Julian Brown > wrote: > > On Mon, 28 Apr 2014 11:44:01 +0100 > > Ramana Radhakrishnan wrote: > > > >> I've special cased the ffast-math case for the _f32 intrinsics to > >> prevent the auto-vectorizer from

[patch] libstdc++/61023 - copy comparison functor in RB tree move assignment

As noted in the PR, the standard doesn't actually say what containers should do with their functors on move construction/assignment. Our unordered containers currently move the hash and predicate functions. Our RB trees copy the comparison function in the move constructor but do nothing with it

Re: [C++ Patch] PR 61080

OK. Jason

Re: debug container patch

On 07/05/14 14:17 +0100, Ramana Radhakrishnan wrote: Can someone regenerate and commit the Makefile.in changes soon ? I'm seeing testsuite failures thanks to missing debug/safe_container.h on arm-none-linux-gnueabihf It was done hours ago by http://gcc.gnu.org/ml/gcc-cvs/2014-05/msg00170.html

Re: debug container patch

On Wed, May 7, 2014 at 2:22 PM, Jonathan Wakely wrote: > On 07/05/14 14:17 +0100, Ramana Radhakrishnan wrote: >> >> Can someone regenerate and commit the Makefile.in changes soon ? I'm >> seeing testsuite failures thanks to missing debug/safe_container.h on >> arm-none-linux-gnueabihf > > > It was

[PATCH][1/n] Fix PR61034

The following fixes part of PR61034 - we are hindered by false clobbering during FRE/PRE on paths we try to look through by means of the alias walker. The following makes us also consider lattice-based disambiguation there and in particular also try harder to disambiguate against builtins. Boots

Re: debug container patch

On Wed, May 7, 2014 at 2:13 AM, Paolo Carlini wrote: > -- Francois, > > remember to regenerate and commit the Makefile.in changes. Can someone regenerate and commit the Makefile.in changes soon ? I'm seeing testsuite failures thanks to missing debug/safe_container.h on arm-none-linux-gnueabihf I

Re: [patch] libstdc++/61086 - fix ubsan errors in std::vector

Hi, On 05/07/2014 02:33 PM, Jonathan Wakely wrote: Yes, I checked. deque::const_iterator, list::const_iterator, vector::const_iterator and the _Rb_tree_const_iterator types all have _M_const_cast but they do not dereference anything. It only really affected std::vector because that's the only

Re: [PATCH][RFC] Remove RTL loop unswitching

On Wed, 7 May 2014, Thomas Schwinge wrote: > Hi! > > On Tue, 15 Apr 2014 11:26:29 +0200 (CEST), Richard Biener > wrote: > > This removes RTL loop unswitching > > > 2014-04-15 Richard Biener > > > > * Makefile.in (OBJS): Remove loop-unswitch.o. > > * loop-unswitch.c: Delete. > >

Re: [PATCH][RFC] Remove RTL loop unswitching

Hi! On Tue, 15 Apr 2014 11:26:29 +0200 (CEST), Richard Biener wrote: > This removes RTL loop unswitching > 2014-04-15 Richard Biener > > * Makefile.in (OBJS): Remove loop-unswitch.o. > * loop-unswitch.c: Delete. > * tree-pass.h (make_pass_rtl_unswitch): Remove. > * p

Re: [patch] libstdc++/61086 - fix ubsan errors in std::vector

On 07/05/14 14:21 +0200, Paolo Carlini wrote: On 05/07/2014 02:07 PM, Jonathan Wakely wrote: The testcase in the PR calls __position._M_const_cast() to get a mutable iterator and that dereferences the pointer as suggested in http://gcc.gnu.org/ml/libstdc++/2013-05/msg00031.html That's invalid b

Re: [patch] libstdc++/61086 - fix ubsan errors in std::vector

On 05/07/2014 02:07 PM, Jonathan Wakely wrote: The testcase in the PR calls __position._M_const_cast() to get a mutable iterator and that dereferences the pointer as suggested in http://gcc.gnu.org/ml/libstdc++/2013-05/msg00031.html That's invalid because the pointer is not dereferenceable (in t

[patch] libstdc++/61086 - fix ubsan errors in std::vector

The testcase in the PR calls __position._M_const_cast() to get a mutable iterator and that dereferences the pointer as suggested in http://gcc.gnu.org/ml/libstdc++/2013-05/msg00031.html That's invalid because the pointer is not dereferenceable (in this case it's null but is past-the-end at all tim

Re: [AArch64] Fix integer vabs intrinsics

On 07/05/14 11:32, Richard Biener wrote: > On Wed, May 7, 2014 at 12:30 PM, Richard Earnshaw wrote: >> On 05/05/14 09:04, Richard Biener wrote: >>> On Fri, May 2, 2014 at 12:39 PM, Richard Earnshaw wrote: On 02/05/14 11:28, James Greenhalgh wrote: > On Fri, May 02, 2014 at 10:29:06AM +01

Re: [PATCH][RFC] Remove RTL loop unswitching

Hi! On Tue, 15 Apr 2014 11:26:29 +0200 (CEST), Richard Biener wrote: > This removes RTL loop unswitching > 2014-04-15 Richard Biener > > * Makefile.in (OBJS): Remove loop-unswitch.o. > * loop-unswitch.c: Delete. > * tree-pass.h (make_pass_rtl_unswitch): Remove. > * p

Re: [AArch64] Fix integer vabs intrinsics

On Wed, May 7, 2014 at 12:30 PM, Richard Earnshaw wrote: > On 05/05/14 09:04, Richard Biener wrote: >> On Fri, May 2, 2014 at 12:39 PM, Richard Earnshaw wrote: >>> On 02/05/14 11:28, James Greenhalgh wrote: On Fri, May 02, 2014 at 10:29:06AM +0100, pins...@gmail.com wrote: > > >>

Re: [AArch64] Fix integer vabs intrinsics

On 05/05/14 09:04, Richard Biener wrote: > On Fri, May 2, 2014 at 12:39 PM, Richard Earnshaw wrote: >> On 02/05/14 11:28, James Greenhalgh wrote: >>> On Fri, May 02, 2014 at 10:29:06AM +0100, pins...@gmail.com wrote: > On May 2, 2014, at 2:21 AM, James Greenhalgh > wrote: >

Re: we are starting the wide int merge

Jan-Benedict Glaw writes: > On Tue, 2014-05-06 12:20:54 -0700, Mike Stump wrote: >> On May 6, 2014, at 8:19 AM, Kenneth Zadeck wrote: >> > please hold off on committing patches for the next couple of hours >> > as we have a very large merge to do. >> > thanks. >> >> All done… It is in. > > Jus

Re: [PATCH][RFC] Always require a 64bit HWI

On Wed, 30 Apr 2014, Richard Biener wrote: > On Tue, 29 Apr 2014, Jeff Law wrote: > > > On 04/29/14 05:21, Richard Biener wrote: > > > > > > The following patch forces the availability of a 64bit HWI > > > (without applying the cleanups that result from this). I propose > > > this exact patch f

[PATCH][1/n] Always-64bit HWI cleanups

This removes the need_64bit_hwi logic, nothing else (well, brings libcpp in line with gcc). Bootstrap / regtest pending on x86_64-unknown-linux-gnu. Just as I promised to send this before committing the "let's try this" patch (which is now said to fix wide-int fallout). Richard. 2014-05-07 Ri

RE: [PATCH GCC]Add 'force-dwarf-lexical-blocks' command line option

Thanks for the note. I will make the needed changes and resubmit. Regards, Andrei Herman Mentor Graphics Corporation Israel branch > -Original Message- > From: pins...@gmail.com [mailto:pins...@gmail.com] > Sent: Wednesday, May 07, 2014 12:37 PM > To: Herman, Andrei > Cc: gcc-patches@gcc

Re: we are starting the wide int merge

On 7 May 2014 09:48, Andreas Schwab wrote: > Christophe Lyon writes: > >> It also looks like the git-svn-id property is now wrong/incomplete. >> For instance, commit 9a5942c1d4d9116ab74b0741cfe3894a89fd17fb has: >> git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/wide-int@201706 >> 138bc75d

Re: [PATCH GCC]Add 'force-dwarf-lexical-blocks' command line option

> On May 7, 2014, at 2:32 AM, "Herman, Andrei" > wrote: > > > Hi, > > Currently GCC only emits DWARF debug information (DW_TAG_lexical_block DIEs) > for compound statements containing significant local declarations. > However, code coverage tools that process the DWARF debug information to >

[PATCH GCC]Add 'force-dwarf-lexical-blocks' command line option

Hi, Currently GCC only emits DWARF debug information (DW_TAG_lexical_block DIEs) for compound statements containing significant local declarations. However, code coverage tools that process the DWARF debug information to implement block/path coverage need more complete lexical block information.

Re: [PATCH] [PING^2] Fix for PR libstdc++/60758

On 05/07/14 09:19, Yury Gribov wrote: Original Message Subject: [PING] [PATCH] Fix for PR libstdc++/60758 Date: Thu, 17 Apr 2014 17:48:12 +0400 From: Alexey Merzlyakov To: Ramana Radhakrishnan CC: gcc-patches@gcc.gnu.org , Viacheslav Garbuzov , Yury Gribov Hi, This fixes in

PR 61084: SPARC fallout from wide-int merge

The DImode constant spliiter assigned the result of trunc_int_for_mode to an unsigned int rather than a HOST_WIDE_INT. This then produced const_ints that were zero-extended rather than sign-extended and tripped the assert: gcc_checking_assert (INTVAL (x.first)

[C++ Patch] PR 61080

Hi, thus I prepared this simple patch. Tested x86_64-linux. Thanks, Paolo. / /cp 2014-05-07 Paolo Carlini PR c++/61080 * pt.c (instantiate_decl): Avoid generating the body of a deleted function. /testsuite 2014-05-07 Paolo Carlini PR

Re: [PATCH] [PING^2] Fix for PR libstdc++/60758

Hi, On 05/07/2014 10:19 AM, Yury Gribov wrote: Original Message Subject: [PING] [PATCH] Fix for PR libstdc++/60758 Date: Thu, 17 Apr 2014 17:48:12 +0400 From: Alexey Merzlyakov To: Ramana Radhakrishnan CC: gcc-patches@gcc.gnu.org , Viacheslav Garbuzov , Yury Gribov Hi, T

[PATCH] [PING^2] Fix for PR libstdc++/60758

Original Message Subject: [PING] [PATCH] Fix for PR libstdc++/60758 Date: Thu, 17 Apr 2014 17:48:12 +0400 From: Alexey Merzlyakov To: Ramana Radhakrishnan CC: gcc-patches@gcc.gnu.org , Viacheslav Garbuzov , Yury Gribov Hi, This fixes infinite backtrace in __cxa_end_cleanup

patch1.diff updated + test results Was: Re: GCC's -fsplit-stack disturbing Mach's vm_allocate

On Tue, 2014-05-06 at 15:26 +0200, Samuel Thibault wrote: > Svante Signell, le Tue 06 May 2014 15:25:38 +0200, a écrit : > > On Tue, 2014-05-06 at 15:07 +0200, Samuel Thibault wrote: > > > Svante Signell, le Tue 06 May 2014 15:05:20 +0200, a écrit : > > > > On Tue, 2014-05-06 at 14:51 +0200, Samuel

Re: [PATCH] Change HONOR_REG_ALLOC_ORDER to a marco for C expression

2014-05-02 14:41 GMT+08:00 Kito Cheng : > Hi Jeff: > >> I fixed up some minor whitespace issues and committed your patch. > > Thanks for your help :) Hi, I noticed the commit date in ChangeLog was incorrect for the patch. Fixed it as obvious. Committed into Rev.210138. Index: gcc/ChangeLog

[PATCH][4.7] Fix PR57864

This backports a piece of 2012-09-24 Richard Guenther * tree-ssa-pre.c (bitmap_find_leader, create_expression_by_pieces, find_or_generate_expression): Remove dominating stmt argument. (find_leader_in_sets, phi_translate_1, bitmap_find_leader, create_component_ref_b

Re: we are starting the wide int merge

Christophe Lyon writes: > It also looks like the git-svn-id property is now wrong/incomplete. > For instance, commit 9a5942c1d4d9116ab74b0741cfe3894a89fd17fb has: > git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/wide-int@201706 > 138bc75d-0d04-0410-961f-82ee72b054a4 > > How does it map to

[PATCH, nds32] Committed: Enable HONOR_REG_ALLOC_ORDER when optimizing for size.

Hi, all, There was a patch to have HONOR_REG_ALLOC_ORDER using C expression: http://gcc.gnu.org/ml/gcc-patches/2014-02/msg01546.html http://gcc.gnu.org/ml/gcc-patches/2014-05/msg00048.html This is very helpful to nds32 port since we can decide when to apply HONOR_REG_ALLOC_ORDER against code

Re: we are starting the wide int merge

On Tue, 2014-05-06 12:20:54 -0700, Mike Stump wrote: > On May 6, 2014, at 8:19 AM, Kenneth Zadeck wrote: > > please hold off on committing patches for the next couple of hours as we > > have a very large merge to do. > > thanks. > > All done… It is in. Just found one more: g++ -c -g -O2 -D