[PATCH v3 3/3] Port libstdc++ pretty-printers to Python 2 + Python 3

Loosely based on Matthias Klose's earlier patch . This time with his name spelled correctly; sorry about that! Tested with: $ make check-target-libstdc++-v3 RUNTESTFLAGS='--directory libstdc++-prettyprinters' libstdc++-v3/ PR libstdc++/58962

[PATCH v2 3/3] Port libstdc++ pretty-printers to Python 2 + Python 3

Loosely based on Mathias Klose' earlier patch . Tested with: $ make check-target-libstdc++-v3 RUNTESTFLAGS='--directory libstdc++-prettyprinters' libstdc++-v3/ PR libstdc++/58962 * python/libstdcxx/v6/printers.py: Port to Python 2+3

[PATCH v2 2/3] libstdc++ testsuite: Turn off GDB's auto-load, list loaded libs

We load our pretty-printers explicitly, and we shouldn't need any other random -gdb.gdb or -gdb.py files from anywhere, so in this patch we turn that off by running "set auto-load no". Also, run "info share" so that the list of loaded libraries ends up in the logs for the GDB tests. libstdc++-v3

[PATCH v2 1/3] Make libstdc++ testsuite work with pre-color GCC versions again

When I try to build & test just libstdc++, or to run the testsuite from trunk against my installed libstdc++, the testsuite tries to pass "-fdiagnostics-color=never" to the system GCC, which is too old to know what that is. Since I really just want to test a patch for the gdb pretty-printers, and

[PATCH v2 0/3] Port libstdc++ pretty printers to Python 3

I've ported the libstdc++ pretty printers to work with Python 3 as well as Python 2, and made a couple of other changes that I think are improvements along the way. The important change here is the final patch; the others just made things easier at some point along the way. I started with a patch

libgo patch committed: Rename iface.goc to go-iface.goc

A new version of the master Go library has a new file runtime/iface.goc. It is not the same as the existing libgo file runtime/iface.goc. This patch renames the libgo file to go-iface.goc to avoid any future confusion. Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu. Committed to m

libgo patch committed: Drop reflectFlags

The Go library reflect package used to have a notion of reflectFlags that were used to indicate an invalid interface value. That has not been used for a while. This patch drops testing for it from the libgo runtime. Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu. Committed to mai

Re: [PATCH] -Wmemset-transposed-args (PR middle-end/61294, take 2)

On Thu, 10 Jul 2014, Jakub Jelinek wrote: > +Wmemset-transposed-args > +C ObjC C++ ObjC++ Var(warn_memset_transposed_args) Warning LangEnabledBy(C > ObjC C++ ObjC++,Wall) > +Warn about suspicious call to memset where the third argument is constant > zero and second is not zero "calls" (plural),

[PATCH libstdc++] Buglet in gcc/testsuite/g++.dg/cpp1y/digit-sep-neg.C

Index: gcc/testsuite/g++.dg/cpp1y/digit-sep-neg.C === --- gcc/testsuite/g++.dg/cpp1y/digit-sep-neg.C(revision 212440) +++ gcc/testsuite/g++.dg/cpp1y/digit-sep-neg.C(working copy) @@ -7,7 +7,7 @@ i = 1048''576; // { dg-error

Re: [C++ Patch/RFC] Back to PR 53159

... and of course the problem with all such ideas is that we easily end up warning twice in all the simple cases which check_narrowing can already handle. Something like the attached has more chances of passing the testsuite while not regressing in terms of duplicate warnings (which are hard to

Re: [C++ Patch/RFC] Back to PR 53159

... the below is another, very safe, option for setting LOOKUP_NO_NARROWING in flags. Paolo. Index: call.c === --- call.c (revision 212431) +++ call.c (working copy) @@ -3586,7 +3586,8 @@ build_user_type_conversion_1 (tree

Re: [C++ Patch/RFC] Back to PR 53159

Hi, On 07/10/2014 10:55 PM, Jason Merrill wrote: Hmm, why aren't we already getting the error from if (convs->check_narrowing) check_narrowing (totype, expr); in convert_like_real? Is it that we need to copy LOOKUP_NO_NARROWING into convflags in build_user_type_conversion_1? Ah, ah,

RE: [patch] Hide the caret for -Wstack-usage

> since displaying the caret was made the default, the -Wstack-usage warning has > a strange-looking final part: > > stack-usage-2.c: In function 'foo2': > stack-usage-2.c:16:1: warning: stack usage is 920 bytes [-Wstack-usage=] > } > ^ Your patch hides the caret but the location still points to

C++ PATCH for c++/61661 (constexpr and ptrmem)

If we handle PTRMEM_CST specially, we also need to handle any CONSTRUCTORs that wrap them. Tested x86_64-pc-linux-gnu, applying to trunk and 4.9. commit a2f90f6d52fa4c3d5391b23914c4177c3272817c Author: Jason Merrill Date: Thu Jul 10 17:05:28 2014 -0400 PR c++/61661 * semantics.c (r

Re: [PATCH][sched-deps] Generalise usage of macro fusion to work on any two insns

On Jul 10, 2014, at 8:00 PM, Kyrill Tkachov wrote: > > On 30/06/14 21:39, Jeff Law wrote: >> On 06/27/14 02:29, Kyrill Tkachov wrote: >>> Hi all, >>> >>> This patch generalises the TARGET_MACRO_FUSION_PAIR_P hook usage to work >>> on more than just >>> compares and conditional branches for whic

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

The fact that extra line directives are inserted around built-in tokens isn't ideal, but I must concur with Dodji's assessment that such a fix belongs in a separate patch. The purpose of this patch is to resolve a discrepancy between integrated-cpp and non-integrated-cpp. The locations of built-in

Re: [C++ Patch/RFC] Back to PR 53159

Hmm, why aren't we already getting the error from if (convs->check_narrowing) check_narrowing (totype, expr); in convert_like_real? Is it that we need to copy LOOKUP_NO_NARROWING into convflags in build_user_type_conversion_1? Jason

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

On 07/10/2014 08:13 AM, Dodji Seketeli wrote: Jason Merrill writes: On 07/04/2014 05:13 AM, Dodji Seketeli wrote: // 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

[C++ Patch/RFC] Back to PR 53159

Hi, after more than 2 years, I'm finally back to this issue: https://gcc.gnu.org/ml/gcc-patches/2012-05/msg01442.html https://gcc.gnu.org/ml/gcc-patches/2012-05/msg01502.html and the below draft, which passes testing, tries to implement as closely as possible what Jason suggested in th

C++ PATCH for c++/61687 (extra errors with -O2)

My earlier patch for 61659 caused more virtual functions to be instantiated when -fdevirtualize is on, leading to additional errors appearing at higher optimization levels. This patch shifts that instantiation to a new flag, -fuse-all-virtuals, which is on by default, and adds an explanatory n

[patch,gomp-4_0-branch] openacc collapse clause

Hi Thomas, These patch enables the collapse clause with a value greater than one. We had partial support for the collapse clause which supported a value of 1, because the fortran frontend always associated a collapse clause with each openacc for loop. However in terms of actual collapse support, a

[patch,gomp-4_0-branch] misc reduction clause bug fixes

Hi Thomas, This patch addresses two bugs openacc reduction clause bugs. The first bug occurred because I didn't anticipate a GIMPLE_BIND stmt to be passed to process_reduction_data. Turns out, this could happen with the collapse clause. That's because the variables which were declared inside the i

Re: Fwd: [RFC][gomp4] Offloading patches (2/3): Add tables generation

On 07/10/2014 08:24 PM, Ilya Verbin wrote: On 07 Jul 17:03, Bernd Schmidt wrote: Is libgomp the only problematic one? (Does the accel compiler even need one?) It seems to be installed in /usr/lib rather than in a gcc-specific directory, which is a little surprising to me. It may be necessary to

Re: Fwd: [RFC][gomp4] Offloading patches (2/3): Add tables generation

On 07 Jul 17:03, Bernd Schmidt wrote: > Is libgomp the only problematic one? (Does the accel compiler even > need one?) It seems to be installed in /usr/lib rather than in a > gcc-specific directory, which is a little surprising to me. It may > be necessary to give the accel compiler a different sy

Re: update address taken: don't drop clobbers

On 07/10/14 09:48, Michael Matz wrote: Hi, On Thu, 10 Jul 2014, Richard Biener wrote: Apart from the out-of-SSA patch you proposed elsewhere a possibility is to simply never mark undefined SSA names as SSA_NAME_OCCURS_IN_ABNORMAL_PHI ... (or not mark those as must-coalesce). The insight to n

[patch] Fix bug in experimental::any

This fixes the uses-allocator construction in experimental::any and re-orders the data members so that I can extract the stored value in a Python printer without having to walk the inheritance hierarchy of a std::tuple. The actual pretty printer for any (and string_view and optional) will follow

Re: [PATCH] -Wmemset-transposed-args (PR middle-end/61294, take 2)

OK. Jason

[patch] [4.9] Backport fix for ICEs with -gsplit-dwarf

I've backported this patch from trunk at r212211. Committed to gcc-4_9 at r212434. https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00076.html -cary 2014-07-01 Cary Coutant gcc/ * dwarf2out.c (remove_addr_table_entry): Remove unnecessary hash table lookup. (resolve_a

Re: [PATCH preprocessor/61389] - libcpp diagnostics shouldn't talk about ISO C99 for C++ input files

OK. Jason

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

> which means that the precision of the mode is used to set the size > of the type, which very likely means that the size of the mode is > larger. So the size of the mode will be larger than the size of the > type, which is a lie. For partial int modes, the precision and size are the same, and n

Re: update address taken: don't drop clobbers

Hi, On Thu, 10 Jul 2014, Richard Biener wrote: > Apart from the out-of-SSA patch you proposed elsewhere a possibility > is to simply never mark undefined SSA names as > SSA_NAME_OCCURS_IN_ABNORMAL_PHI ... (or not mark those > as must-coalesce). The insight to note is, that undefined SSA names sh

Re: [PATCH] Fix PR61762, reads from string constants

On Thu, Jul 10, 2014 at 05:12:53PM +0200, Richard Biener wrote: > The following makes sure we fold the reads from string constants > created from folding memcpy (&foo, &string_cst[0], ...) to > eventually create similar code as if that memcpy folding wasn't > done (move-by-pieces). > > Bootstrappe

Re: [PATCH 1/2, x86] Add palignr support for AVX2.

On Mon, Jul 7, 2014 at 6:40 PM, Richard Henderson wrote: > On 07/03/2014 02:53 AM, Evgeny Stupachenko wrote: >> -expand_vec_perm_palignr (struct expand_vec_perm_d *d) >> +expand_vec_perm_palignr (struct expand_vec_perm_d *d, int insn_num) > > insn_num might as well be "bool avx2", since it's only

[PATCH] Fix PR61762, reads from string constants

The following makes sure we fold the reads from string constants created from folding memcpy (&foo, &string_cst[0], ...) to eventually create similar code as if that memcpy folding wasn't done (move-by-pieces). Bootstrapped and tested on x86_64-unknown-linux-gnu. Comments? (yeah, those native_e

Re: [PATCH][RFC] Fix PR61473, inline small memcpy/memmove during tree opts

On Thu, Jul 10, 2014 at 04:30:13PM +0200, Richard Biener wrote: > Compromise "hack" below. It simply avoids the transform for > sources that c_strlen can compute a length of. That "fixes" all > strlenopt testcase apart from strlenopt-8.c which does > memcpy (, flag ? "a" : "b"); which then still

Re: update address taken: don't drop clobbers

On Sun, Jun 29, 2014 at 12:33 AM, Marc Glisse wrote: > Hello, > > we currently drop clobbers on variables whose address is not taken anymore. > However, rewrite_stmt has code to replace them with an SSA_NAME with a > default definition (an uninitialized variable), and I believe > rewrite_update_st

Re: SRA: don't drop clobbers

On Thu, Jul 10, 2014 at 04:54:53PM +0200, Richard Biener wrote: > > + else if (access->grp_to_be_debug_replaced) > > +{ > > Why would we care to create clobbers for debug stmts?! Are those > even valid? It is not valid. Though, the fields supposedly live nowhere after the clobber, so perha

Re: SRA: don't drop clobbers

On Mon, Jun 30, 2014 at 1:38 AM, Marc Glisse wrote: > Hello, > > with this patch on top of > https://gcc.gnu.org/ml/gcc-patches/2014-06/msg02315.html > we finally warn for the testcase of PR 60517. > > The new function is copied from init_subtree_with_zero right above. I guess > it might be possib

Re: [PATCH, rs6000] Fix ELFv2 homogeneous float aggregate ABI bug

Jakub Jelinek wrote: > On Wed, Jul 09, 2014 at 02:19:36PM -0400, David Edelsohn wrote: > > > This is an ABI change for the affected corner cases of the ELFv2 > > > ABI. However, those cases should be extremely rare; the full > > > compat.exe and struct-layout-1.exp ABI compatibility test suite > >

Re: [BUILDROBOT] xtensa fallout (was: Turn DECL_SECTION_NAME into string)

On Fri, Jul 4, 2014 at 2:11 PM, Jan-Benedict Glaw wrote: > On Wed, 2014-06-25 08:55:57 -0700, augustine.sterl...@gmail.com > wrote: >> On Tue, Jun 24, 2014 at 10:20 PM, Jan Hubicka wrote: >> > > This is the xtensa fallout, see >> > > http://toolchain.lug-owl.de/buildbot/show_build_details.php?

[PATCH] Restore bootstrap (PR61757)

The following patch partially reverts r212352 to restore bootstrap on i585-linux (where I reproduced and verified the fix). It makes phicprop honor that loop-depth condition again which doing not seems to cause a latent bug to pop up which miscompiles the stage2 compiler which in turn miscompiles

Re: [PATCH][RFC] Fix PR61473, inline small memcpy/memmove during tree opts

On Fri, 27 Jun 2014, Richard Biener wrote: > On Fri, 27 Jun 2014, Jakub Jelinek wrote: > > > On Fri, Jun 27, 2014 at 01:49:38PM +0200, Richard Biener wrote: > > > I'm going to go for a single load/store and MOVE_MAX for now - I > > > have quite some fallout to deal with anyway (analyzed strlenopt

[PATCH preprocessor/61389] - libcpp diagnostics shouldn't talk about ISO C99 for C++ input files

Here is a preprocessor patch to make error messages show C++11 and other relevant C++ language instead of C99. Built and tested on x86_64-linux. OK? libcpp/ 2014-07-09 Edward Smith-Rowland <3dw...@verizon.net> PR CPP/61389 * macro.c (_cpp_arguments_ok, parse_params, create

Re: Simplify gcc.target/mips/fuse-caller-save*.c

Tom de Vries writes: > The mips16e save/restore enabling is controlled by this code in mips.h: > ... > /* Generate mips16e code. Default 16bit ASE for mips32* and mips64* */ > #define GENERATE_MIPS16E(TARGET_MIPS16 && mips_isa >= 32) > /* Generate mips16e register save/restore sequences.

Re: Simplify gcc.target/mips/fuse-caller-save*.c

On 09-07-14 23:06, Tom de Vries wrote: On 09-07-14 20:32, Richard Sandiford wrote: Tom de Vries writes: Richard, during testing the gcc.target/mips/fuse-caller-save*.c test-cases with more combinations of -march, -mabi, -fpic etc, I found that the checks for amount of stores are rather fragil

Re: [PATCH] Fix for PR 61561

On Thu, Jun 19, 2014 at 9:19 PM, Yuri Gribov wrote: >> Thirdly, we also need to fix movhi_bytes (for pre-v4) thumb2_movhi_insn >> (for thumb2) and, quite possibly, thumb1_movhi_insn (for thumb1). There >> may well be additional changes for movqi variants as well. > > A general question: how shoul

Re: [PING][PATCH] Fix for PR 61561

On 30/06/14 16:21, Marat Zakirov wrote: Thank for your attention. This is OK for trunk - Sorry about the delayed response. Ramana Marat.

[PING v2][PATCH] Fix for PR 61561

Original Message Subject:[PING][PATCH] Fix for PR 61561 Date: Mon, 30 Jun 2014 19:21:49 +0400 From: Marat Zakirov To: gcc-patches@gcc.gnu.org CC: Ramana Radhakrishnan , Richard Earnshaw , Kyrill Tkachov , Slava Garbuzov , Yuri Gribov , mara...@gmail.com

[PATCH] -Wmemset-transposed-args (PR middle-end/61294, take 2)

On Wed, Jul 09, 2014 at 05:28:34PM -0400, Jason Merrill wrote: > On 07/09/2014 10:40 AM, Manuel López-Ibáñez wrote: > >>All of these warnings (-Wsizeof-pointer-memaccess, -Wsizeof-array-argument > >>and -Wmemset-transposed-args) are implemented in a hackish way, because we > >>fold everything too e

Re: [doc] install.texi, update links to packages for Solaris

On Wed, 9 Jul 2014, Tom G. Christensen wrote: > Patch applies to trunk, gcc 4.9 and gcc 4.8 branches. > > 2014-07-09 Tom G. Christensen > > * doc/install.texi: Remove links to defunct package providers for > Solaris Thanks, Tom! I was just going to create the same patch, but sinc

[PATCH] Fix PR61741 testcase

Noticed by David, applied as obvious (stupid C language!). Richard. 2014-07-10 Richard Biener PR c-family/61741 * c-c++-common/torture/pr61741.c: Use signed char. Index: gcc/testsuite/c-c++-common/torture/pr61741.c

Re: [PATCH 2/2] Enable elimination of zext/sext

On Mon, Jul 7, 2014 at 8:55 AM, Kugan wrote: >> For -fwrapv I don't see why you'd get into trouble ever, the VRP computation >> should be well aware of the -fwrapv semantics and the value ranges should >> reflect that. >> >> For -fno-strict-overflow, I have no idea since it is very weirdly defined

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

Jason Merrill writes: > On 07/04/2014 05:13 AM, Dodji Seketeli wrote: >>> >// 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 loca

Re: Move DECL_VINDEX and DECL_SAVED_TREE into function_decl

> I'm seeing ICEs: »tree check: expected function_decl, have type_decl in > fold_checksum_tree, at fold-const.c:14861«. Is the following the correct > fix, or should this be done differently? No, it seems fine to me. I added it to my local patch, thanks! Honza > > --- gcc/fold-const.c > +++ gcc

[gomp4] Merge trunk r212389 (2014-07-09) into gomp-4_0-branch

Hi! In r212427, I have committed a merge from trunk r212389 (2014-07-09) into gomp-4_0-branch. Grüße, Thomas pgppgDa3bbJhH.pgp Description: PGP signature

Re: Move DECL_VINDEX and DECL_SAVED_TREE into function_decl

On Thu, Jul 10, 2014 at 11:50 AM, Thomas Schwinge wrote: > Hi! > > On Mon, 23 Jun 2014 22:25:41 +0200, Jan Hubicka wrote: >> this patch makes DECL_VINDEX and DECL_SAVED_TREE to be FUNCTION_DECL only. > >> Bootstrapped/regtested x86_64-linux, OK? > > ... without --enable-checking=fold. ;-P > >>

Re: [PATCH, rs6000] Fix ELFv2 homogeneous float aggregate ABI bug

On Wed, Jul 09, 2014 at 02:19:36PM -0400, David Edelsohn wrote: > > This is an ABI change for the affected corner cases of the ELFv2 > > ABI. However, those cases should be extremely rare; the full > > compat.exe and struct-layout-1.exp ABI compatibility test suite > > passed, with the exception o

[patch] Hide the caret for -Wstack-usage

Hi, since displaying the caret was made the default, the -Wstack-usage warning has a strange-looking final part: stack-usage-2.c: In function 'foo2': stack-usage-2.c:16:1: warning: stack usage is 920 bytes [-Wstack-usage=] } ^ Tested on x86_64-suse-linux, OK for all active branches? 2014-07

Re: [PATCH, C++, CPP] Add C++1z to the preprocessor. Rename C++1y to C++14.

On Jul 10, 2014, at 2:12 AM, Ed Smith-Rowland <3dw...@verizon.net> wrote: > Rename C++1y to C++14. So generally when we do this we change most of the uses in the test suite of the c++1y flag to use the standard spelling. Some might appreciate that we have one test case testing the 1y spelling f

Fix PR middle-end/53590 again

The optimization was almost immediately disabled accidentally by: https://gcc.gnu.org/ml/gcc-cvs/2012-06/msg00577.html Of course I should have added a testcase in the first place... Tested on x86_64-suse-linux, applied on all active branches as obvious (this only affects the Ada compiler). 20

Re: [PATCH, rs6000] Fix ELFv2 homogeneous float aggregate ABI bug

On Wed, Jul 9, 2014 at 6:02 PM, Ulrich Weigand wrote: > Hello, > > the implementation of homogenous float aggregates for the ELFv2 ABI has > unfortunately shown to have a bug in a corner case. > > The problem is that because such aggregates are packed in the argument > save area, but each (4-byte)

Re: [gomp4] Merge trunk r209072 (2014-04-04) into gomp-4_0-branch

Hi! For the record: On Sat, 05 Apr 2014 12:34:30 +0200, I wrote: > In r209148, I have committed a merge from trunk r209072 (2014-04-04) into > gomp-4_0-branch. > > > Compared to trunk, there is one now regression: > > PASS: gcc.dg/lto/save-temps c_lto_save-temps_0.o assemble, -O -flto >

Re: [PATCH, libstdc++] Add the logistic distribution as an extension

.. I have another comment: are we sure the usual strategy: template result_type operator()(_UniformRandomNumberGenerator& __urng) { return this->operator()(__urng, this->_M_param); } doesn't make sense here too? Paolo.

Re: [PATCH, libstdc++] Add the logistic distribution as an extension

Hi, On 07/10/2014 10:07 AM, Ed Smith-Rowland wrote: The title says it all. I've been bootstrapping and testing with this on x86_64-linux for a month. OK? Look OK to me too, but I would move both operator() out of line, and definitely operator()(_UniformRandomNumberGenerator&, const param_ty

Re: [Patch ARM-AArch64/testsuite v2 01/21] Neon intrinsics execution tests initial framework.

On 1 July 2014 11:05, Christophe Lyon wrote: > * documentation (README) > * dejanu driver (neon-intrinsics.exp) > * support macros (arm-neon-ref.h, compute-ref-data.h) > * Tests for 3 intrinsics: vaba, vld1, vshl Hi, The terminology in armv8 is advsimd rather than neon. Can we rename neon-intrin

Re: Move DECL_VINDEX and DECL_SAVED_TREE into function_decl

Hi! On Mon, 23 Jun 2014 22:25:41 +0200, Jan Hubicka wrote: > this patch makes DECL_VINDEX and DECL_SAVED_TREE to be FUNCTION_DECL only. > Bootstrapped/regtested x86_64-linux, OK? ... without --enable-checking=fold. ;-P > * class.c (check_methods, create_vtable_ptr, determine_key_method,

Re: [PATCH] Generate more efficient memory barriers for LEON3

> The memory barriers generated for SPARC are targeting the weakest memory > model allowed for SPARC. That's not quite true, they are targeting the sparc_memory_model, which is the memory model selected for the architecture/OS pair by default and which can be overridden by the user with -mmemory

Re: [PATCH, libstdc++] Add the logistic distribution as an extension

On Thu, Jul 10, 2014 at 4:07 AM, Ed Smith-Rowland <3dw...@verizon.net> wrote: > The title says it all. > > I've been bootstrapping and testing with this on x86_64-linux for a month. > > OK? Looks good to me.

[PATCH, C++, CPP] Add C++1z to the preprocessor. Rename C++1y to C++14.

Here are some C++ versioning changes reflecting C++14 status and adding c++1z. It is a followup to Jason's patch on 2014-06-26 adding std=c++1z, etc. This will allow us to start making C++1z changes to the preprocessor (n3981 remove trigraphs). In fact, I made trigraphs opt-in for both c++1z

Re: [fortran, patch] IEEE intrinsic modules (ping)

> Since all modes are supported, you can unconditionally return 1 in the > code above, as is the case with fpu-387.h. Indeed. I’ve committed the attached patch, which performs this trivial cleanup, adds some comments about unreachable cases (I don’t think we want to error out at runtime, but a c

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

> Except gcc now knows the size of partial int modes. In this case, > PSImode is 20 bits and TYPE_SIZE is 20 bits, so they match. I don't understand. The problematic change is > - TYPE_SIZE (type) = bitsize_int (GET_MODE_BITSIZE (TYPE_MODE (type))); > + TYPE_SIZE (type) = bitsize_int

[PATCH, libstdc++] Add the logistic distribution as an extension

The title says it all. I've been bootstrapping and testing with this on x86_64-linux for a month. OK? Ed 2014-07-10 Edward Smith-Rowland <3dw...@verizon.net> Add the logistic_distribution as an extension. * include/ext/random: Add the logistic_distribution. * includ

[Patch 2/2][AArch64]Split insn type alu_reg into alu_sreg and alu_dsp_reg

Hi there, As the second and final patch in this series, it intends to update alu_reg and alus_reg types for AArch64 port. With this change, the gcc can be successfully built for AArch64. Is it OK to trunk? BR, Terry 2014-07-10 Terry Guo * config/aarch64/aarch64.md (*addsi3_aarch64, *add

Re: [Patch, PR 61720] Clear regex BFS match queue after every iteration

On 07/10/2014 06:30 AM, Tim Shen wrote: Here's the sane patch :) Ok, thanks! Paolo.

Re: [PATCH][sched-deps] Generalise usage of macro fusion to work on any two insns

On 30/06/14 21:39, Jeff Law wrote: On 06/27/14 02:29, Kyrill Tkachov wrote: Hi all, This patch generalises the TARGET_MACRO_FUSION_PAIR_P hook usage to work on more than just compares and conditional branches for which it was initially designed for (for x86). There are some instructions in ar

Re: [AArch64] Implement some vca*_f[32,64] intrinsics

On 02/07/14 08:59, Christophe Lyon wrote: Hi, It seems some of the scan-assembler directives fail: http://cbuild.validation.linaro.org/build/cross-validation/gcc/trunk/212196/aarch64-none-elf/diff-gcc-rh50-aarch64-none-elf-default-default-default.txt Christophe. This patch should fix the tes

[PATCH][AArch64] Handle fcvta[su] and frint in RTX cost function

Hi all, This patch adds rtx costing code for the round-to-integer instructions in AArch64. Some of them are implemented as UNSPECs, so I've added the appropriate case to the big switch that can be expanded upon to handle other unspecs in the future. Tested aarch64-none-elf and bootstrapped on

Re: [PATCH] Support addsub/subadd as non-isomorphic operations for SLP vectorizer.

Hello! > Ping? > While I added the new define_insn_and_split for vec_merge, a bug is > exposed: in config/i386/sse.md, [ define_expand "xop_vmfrcz2" ] > only takes one input, but the corresponding builtin functions have two > inputs, which are shown in i386.c:

[Patch 1/2][ARM]Split insn type alu_reg into alu_sreg and alu_dsp_reg

Hi there, Currently the insn type of DSP-kind instructions like QSUB8 is alu_reg which is same as other normal instructions like SUB. In order to distinguish those DSP-kind instructions, this patch intends to replace current alu_reg with two sub categories alu_sreg and alu_dsp_reg. Meanwhile the a

Re: [fortran, patch] IEEE intrinsic modules (ping)

Hello! >> The only thing I can see is that libgfortran/config/fpu-sysv.h assumes that >> FP_RM and others are macros, checking them with "#ifdef FP_RM”. Is that the >> reason? > > It is. > >> If so, we might just want to use them unconditionally… unless it creates a >> mess on some other SysV targ