[patch,libgfortran] PR48298 DTIO implementation for Internal Units

Hi All, The attached patch implements the necessary changes for DTIO to/from internal units. Prior to this patch, internal unit character strings and related data were kept within the dtp structure with a pseudo unit number assigned. Since child I/O procedures need this information passed to

Re: C/C++ PATCH to implement -Wpointer-compare warning (PR c++/64767)

On Sat, Sep 10, 2016 at 10:58 AM, Marek Polacek wrote: > Spurred by the recent findings, I decided > to > implement a warning that warns when a pointer is compared with a zero > character > literal (constant), because this isn't likely to

Re: [PATCH] Add -Wshadow-local and -Wshadow-compatible-local.

On Mon, Sep 12, 2016 at 1:38 PM, Jim Meyering wrote: > On Mon, Sep 12, 2016 at 7:05 AM, Eric Gallager wrote: >> On 9/11/16, Manuel López-Ibáñez wrote: >>> On 11/09/16 14:02, Mark Wielaard wrote: -Wshadow-local which warns if

Re: [C++ PATCH] Fix ICE in C++ lookup_name_fuzzy (PR c++/77549)

On Tue, Sep 13, 2016 at 3:26 PM, Jakub Jelinek wrote: >for (tree t = lvl->names; t; t = TREE_CHAIN (t)) > { > + /* OVERLOADs or decls from using declaration are wrapped into > +TREE_LIST. */ > + if (TREE_CODE (t) == TREE_LIST) > + { > +

Re: [PATCH 3/4][Ada,DJGPP] Ada support for DJGPP

On 09/13/2016 11:39 PM, Eric Botcazou wrote: Found that the first revision causing this problem (of course with DJGPP related patches applied) is 239113. Native bootstrap with same DJGPP related patches applied on top of revision 239112 succeeds without problems. [andris@ap gcc]$ git bisect

Re: C++ PATCH to forbid use of bool with the ++ operator

On Tue, Sep 13, 2016 at 3:55 PM, Martin Sebor wrote: > Having said all that, since this is C++ the message could and > arguably should refer to a bool expression (or type) instead > and avoid having to deal with this altogether. In fact, it > would be simpler to rephrase the

[PATCH] fix-it hints for warn_uninit

We warn about uses of uninitialized variables from the middle end, via warn_uninit. This patch adds the ability for such warnings to contain fix-it hints, showing the user how to zero-initialize the relevant variables. Naturally this is highly frontend-dependent, so the patch adds a langhook:

Re: [PATCH 1/3] Put a TARGET_LRA_P into every target

On 09/12/2016 04:22 PM, Segher Boessenkool wrote: This patch adds a TARGET_LRA_P (defined to hook_bool_void_false) to every target that didn't yet override the hook. No functional change. Segher 2016-09-12 Segher Boessenkool * config/alpha/alpha.c

Re: [PATCH 3/4][Ada,DJGPP] Ada support for DJGPP

> Found that the first revision causing this problem (of course with DJGPP > related patches applied) is 239113. Native bootstrap with same DJGPP > related patches applied on top of revision 239112 succeeds without > problems. > > [andris@ap gcc]$ git bisect good >

Re: [PATCH 0/9] RFC: selftests based on RTL dumps

On 09/12/2016 12:57 PM, David Malcolm wrote: I'm not sure I follow - this sounds like a dedicated target for selftesting. That's exactly what it is. We'd essentially put in knobs so that we could control the different things we need to. For example, if we wanted to test a particular

debug container mutex association

Hi When I proposed to change std::hash for pointers my plan was to use this approach for the debug containers. So here is the patch leveraging on this technique to avoid going through _Hash_impl to hash address and get mutex index from it. I think it is obious that new access is faster

Re: [PATCH] Handle VECTOR_CST in integer_nonzerop()

On 08/19/2016 05:30 PM, Patrick Palka wrote: integer_nonzerop() currently unconditionally returns false for a VECTOR_CST argument. This is confusing because one would expect that integer_onep(x) => integer_nonzerop(x) for all x but that is currently not the case. For a VECTOR_CST of all ones

Re: PING: new pass to warn on questionable uses of alloca() and VLAs

On 08/19/2016 08:58 AM, Aldy Hernandez wrote: I'd just drop the /*strict_mode_p*/ comment in both places it appears in your patch's change to passes.def. I think we've generally frowned on those embedded comments, even though some have snuck in. I've seen a lot of embedded comments

Re: [PATCH][msp430] Don't output __interrupt_vector sections for weak functions

Approved and committed. Thanks! Sorry for the delay, I was away for the holiday weekend and it slipped through the cracks when I returned.

Re: [PATCH 1/3] Put a TARGET_LRA_P into every target

On Tue, Sep 13, 2016 at 04:15:45PM +, Joseph Myers wrote: > On Tue, 13 Sep 2016, Segher Boessenkool wrote: > > > Yes, many targets need the hook definition after this series; that should > > stick out like a sore thumb, help to remind people to change their target > > to use LRA (not a huge

Re: [PATCH] Fix aarch64 fallout of [PATCH, LRA] Fix PR rtl-optimization 77289, LRA matching constraint problem

On 09/12/2016 07:43 AM, Bernd Edlinger wrote: Hi, the attached patch boot-straps and reg-tests cleanly on x86_64-pc-linux-gnu, powerpc and aarch64 targets. Is it OK for trunk? Thanks Bernd. patch-pr77289.diff 2016-09-12 Bernd Edlinger PR

Re: C++ PATCH to forbid use of bool with the ++ operator

- /* Forbid using -- on `bool'. */ + /* Forbid using -- or ++ in C++17 on `bool'. */ if (TREE_CODE (declared_type) == BOOLEAN_TYPE) { if (code == POSTDECREMENT_EXPR || code == PREDECREMENT_EXPR) @@ -6040,6 +6040,20 @@ cp_build_unary_op (enum tree_code

[C++ PATCH] Fix ICE in C++ lookup_name_fuzzy (PR c++/77549)

Hi! push_local_binding/push_overloaded_decl* sometimes inserts OVERLOADs into the lvl->names chain, and for both OVERLOADs and decls from using directive it also wraps them into TREE_LIST. The following patch teaches the spelling check hints processing to handle those, otherwise we ICE in each of

Re: [PATCH] Fix cond updating in tree-ssa-dom (PR tree-optimization/77454)

On Tue, Sep 13, 2016 at 04:02:17PM +0200, Richard Biener wrote: > Yes please, this should be safe. All of the above do not look at immediate > uses but at most use-def links. Ok, here is what I've committed after another bootstrap/regtest: 2016-09-13 Jakub Jelinek

Re: [C++ PATCH] Implement P0028R4, C++17 using attribute namespaces without repetition

On Tue, Sep 13, 2016 at 11:40:20AM -0400, Jason Merrill wrote: > On Tue, Sep 13, 2016 at 4:03 AM, Jakub Jelinek wrote: > > This patch implements the P0028R4 C++17 enhancement. > > First I found a bug in the C++11 std attribute handling, where > > [[bitand, bitand::foo]] has been

C++ PATCH to forbid use of bool with the ++ operator

For historical reasons, incrementing a boolean was allowed (because anything non-0 is true), while decrementing is forbidden. This has now changed, and since C++17 even ++ on bool is invalid. And C++ 03/11/14 [depr.incr.bool] says that ++ is deprecated, but we never diagnosed this. A bunch of

[PATCH] Improve string::clear() performance

In !_GLIBCXX_USE_CXX11_ABI implementation, string::clear() calls _M_mutate(), which could allocate memory as we do COW. This hurts performance when string::clear() is on the hot path. This patch improves it by using _S_empty_rep directly when _GLIBCXX_FULLY_DYNAMIC_STRING is not enabled. And

[PING][PATCH][msp430] Don't output __interrupt_vector sections for weak functions

Is the revised patch acceptable? If it is, I don't have commit access, so I'd apprecite it if someone could commit it for me. Similarly, I can comment on the Bugzilla entry but can't change it's state - assuming that would be appropriate if the patch is accepted. Thanks, Joe On 01/09/2016

Re: [Committed] PR fortran/77420 -- revert previous commit

On Tue, Sep 13, 2016 at 10:05:56AM -0700, Steve Kargl wrote: > --- gcc/fortran/module.c (revision 240117) > +++ gcc/fortran/module.c (working copy) > @@ -4647,7 +4647,7 @@ load_equiv (void) >} > > /* Check for duplicate equivalences being loaded from different modules >

Re: [PATCH 1/3] Put a TARGET_LRA_P into every target

On Sep 13, 2016, at 9:07 AM, Jeff Law wrote: > > On 09/13/2016 09:45 AM, Peter Bergner wrote: >> On 9/13/16 9:26 AM, Andrew Pinski wrote: >>> On Tue, Sep 13, 2016 at 12:03 PM, Segher Boessenkool And all new ports should use LRA, so it should be the default. >>> >>> I am

[Committed] PR fortran/77420 -- revert previous commit

I've reverted my previous fix for PR fortran/77420. It was causing a regression that could, in principle, effect a significant nubmer of gfortran users. 2016-09-13 Steven G. Kargl PR fortran/77420 * module.c (load_equiv): Revert revision 240063.

Re: [PATCH 1/2][AArch64] Add missing support for poly64x1_t

On Tue, Sep 13, 2016 at 01:39:39PM +0100, Tamar Christina wrote: > Hi all, > > This fixes a bug in the name mangling which prevented mangling > of functions with return type void and arguments that require > any qualifiers. e.g. void(unsigned int, unsigned int). > > Ran regression tests on

Re: [PATCH 3/4][Ada,DJGPP] Ada support for DJGPP

On 09/07/2016 08:59 PM, Andris Pavenis wrote: On 09/05/2016 09:42 AM, Eric Botcazou wrote: Attached output is from last test build (r239639 with DJGPP related patches applied, last version of patches for Ada). Very strange error, line 28 of gtype-ada.h is supposed to have a guard for nodes

Re: [PATCH 1/3] Put a TARGET_LRA_P into every target

On Tue, 13 Sep 2016, Segher Boessenkool wrote: > Yes, many targets need the hook definition after this series; that should > stick out like a sore thumb, help to remind people to change their target > to use LRA (not a huge amount of work for most, although it can get tricky). I would also

Re: [PATCH] Optimise the fpclassify builtin to perform integer operations when possible

On 09/13/2016 02:41 AM, Jakub Jelinek wrote: On Mon, Sep 12, 2016 at 04:19:32PM +, Tamar Christina wrote: This patch adds an optimized route to the fpclassify builtin for floating point numbers which are similar to IEEE-754 in format. The goal is to make it faster by: 1. Trying to

[committed] fix-it hints: insert_before vs insert_after

The API for adding "insert text" fix-it hints was unclear about exactly where the text should be inserted relative to the given insertion point. This patch clarifies things by renaming the pertinent methods from richloc.add_fixit_insert to richloc.add_fixit_insert_before and adding:

Re: [PATCH] Add braces to a condition in predict.c (PR middle-end/77574)

On 09/13/2016 09:53 AM, Martin Liška wrote: Hi. Simple patch fixes warning spotted by upcoming -Wint-in-bool-context option. Survives regression tests and bootstraps on ppc64le-linux-gnu. Ready from trunk? Thanks, Martin 0001-Add-braces-to-a-condition-in-predict.c-PR-middle-end.patch From

Re: [PATCH] Optimise the fpclassify builtin to perform integer operations when possible

On Tue, 13 Sep 2016, Wilco Dijkstra wrote: > I would suggest someone with access to a machine with slow FP moves (POWER?) > to benchmark this using the fpclassify test > (glibc/benchtests/bench-math-inlines.c) > so we know for sure. And if for some operations on some architectures the

Re: [PATCH 1/3] Put a TARGET_LRA_P into every target

On 09/13/2016 09:45 AM, Peter Bergner wrote: On 9/13/16 9:26 AM, Andrew Pinski wrote: On Tue, Sep 13, 2016 at 12:03 PM, Segher Boessenkool And all new ports should use LRA, so it should be the default. Since nobody else has said anything on this patch besides Bernd, I am going to say yes

Re: Verify package integrity of downloaded prerequisites (partially fixes 61439)

On Tue, 13 Sep 2016, Moritz Klammler wrote: > I have made an actual diff now, containing also the checksum files. I I don't think checksums of lots of miscellaneous files should be included, just the checksums for those files the current script will actually use. -- Joseph S. Myers

[PATCH] Add braces to a condition in predict.c (PR middle-end/77574)

Hi. Simple patch fixes warning spotted by upcoming -Wint-in-bool-context option. Survives regression tests and bootstraps on ppc64le-linux-gnu. Ready from trunk? Thanks, Martin >From 73ef3ea13b9e52b8ead1de18343fe222ea81f718 Mon Sep 17 00:00:00 2001 From: marxin Date: Tue, 13 Sep

Re: [PATCH 1/3] Put a TARGET_LRA_P into every target

On 09/13/2016 04:26 AM, Bernd Schmidt wrote: On 09/13/2016 12:22 AM, Segher Boessenkool wrote: This patch adds a TARGET_LRA_P (defined to hook_bool_void_false) to every target that didn't yet override the hook. No functional change. This patch series makes very little sense to me. Adding 35

Re: [C++ PATCH] Implement P0028R4, C++17 using attribute namespaces without repetition

On Tue, Sep 13, 2016 at 4:03 AM, Jakub Jelinek wrote: > This patch implements the P0028R4 C++17 enhancement. > First I found a bug in the C++11 std attribute handling, where > [[bitand, bitand::foo]] has been allowed, but not [[foo::bitand]] > (i.e. the identifier after ::

Re: [PATCH 1/3] Put a TARGET_LRA_P into every target

On 9/13/16 9:26 AM, Andrew Pinski wrote: On Tue, Sep 13, 2016 at 12:03 PM, Segher Boessenkool And all new ports should use LRA, so it should be the default. Since nobody else has said anything on this patch besides Bernd, I am going to say yes please. This patch in my mind is the right way

Re: [C++ PATCH] Fix constexpr POINTER_PLUS_EXPR handling (PR c++/77553)

OK. On Tue, Sep 13, 2016 at 3:55 AM, Jakub Jelinek wrote: > Hi! > > The testcase below shows a bug in POINTER_PLUS_EXPR constexpr handling. > It is handled by 2 different functions, cxx_eval_pointer_plus_expression > and cxx_eval_binary_expression, where the first one calls >

Re: [PATCH, rs6000] Remove optimize_insn_for_speed_p check on divide -> recip splitter

On Tue, Sep 13, 2016 at 10:14:57AM -0500, Pat Haugen wrote: > PRs 77536 and 68212 document cases where the estimated frequencies become > unreliable to make appropriate decisions based on them. This patch removes > the optimize_insn_for_speed_p check on the splitter so that the > transformation

Re: [PATCH, c++, PR77427 ] Set TYPE_STRUCTURAL_EQUALITY for sysv_abi va_list

On Tue, Sep 13, 2016 at 11:10 AM, Tom de Vries wrote: > On 13/09/16 03:36, Jason Merrill wrote: >> >> On Wed, Sep 7, 2016 at 5:22 AM, Richard Biener >> wrote: >>> >>> On Mon, Sep 5, 2016 at 6:11 PM, Tom de Vries >>>

[PATCH, rs6000] Remove optimize_insn_for_speed_p check on divide -> recip splitter

PRs 77536 and 68212 document cases where the estimated frequencies become unreliable to make appropriate decisions based on them. This patch removes the optimize_insn_for_speed_p check on the splitter so that the transformation will take place when -ffast-math is specified. Bootstrap/regtest

Re: [PATCH, c++, PR77427 ] Set TYPE_STRUCTURAL_EQUALITY for sysv_abi va_list

On 13/09/16 03:36, Jason Merrill wrote: On Wed, Sep 7, 2016 at 5:22 AM, Richard Biener wrote: On Mon, Sep 5, 2016 at 6:11 PM, Tom de Vries wrote: On 05/09/16 09:49, Richard Biener wrote: On Sun, Sep 4, 2016 at 11:30 PM, Tom de Vries

Re: [Patch, Fortran] Test for implied sequence in structures in common blocks

On 09/13/2016 07:33 AM, Fritz Reese wrote: Jim, While the test exhibits no particular regression, IMVHO I don't see any reason not to add it. None of my previous testcases include a STRUCTURE within a COMMON block so this would certainly tickle some new code paths, which could expose a future

Re: [Patch, Fortran] Test for implied sequence in structures in common blocks

Jim, While the test exhibits no particular regression, IMVHO I don't see any reason not to add it. None of my previous testcases include a STRUCTURE within a COMMON block so this would certainly tickle some new code paths, which could expose a future regression. I'll give this through the

Re: [PATCH 1/3] Put a TARGET_LRA_P into every target

On Tue, Sep 13, 2016 at 12:03 PM, Segher Boessenkool wrote: > On Tue, Sep 13, 2016 at 12:26:04PM +0200, Bernd Schmidt wrote: >> On 09/13/2016 12:22 AM, Segher Boessenkool wrote: >> >This patch adds a TARGET_LRA_P (defined to hook_bool_void_false) to >> >every target

Re: RFC: PATCH to consider MAX_OFILE_ALIGNMENT for targetm.absolute_biggest_alignment

On 09/13/2016 04:24 PM, Jason Merrill wrote: But we could define TARGET_ABSOLUTE_BIGGEST_ALIGNMENT on nvptx instead of on x86; is this OK? That's what I had in mind. It would be good if Thomas or Nathan could give this patch a spin, I'm not currently really set up for it. But it looks like

Re: RFC: PATCH to consider MAX_OFILE_ALIGNMENT for targetm.absolute_biggest_alignment

On Tue, Sep 13, 2016 at 6:42 AM, Bernd Schmidt wrote: > On 09/12/2016 08:58 PM, Jason Merrill wrote: >> >> TARGET_ABSOLUTE_BIGGEST_ALIGNMENT is documented to be the largest >> alignment possible for any type or variable, and defaults to >> BIGGEST_ALIGNMENT. But

Re: [PATCH] Fix cond updating in tree-ssa-dom (PR tree-optimization/77454)

On September 13, 2016 3:32:33 PM GMT+02:00, Jakub Jelinek wrote: >On Tue, Sep 13, 2016 at 03:21:47PM +0200, Richard Biener wrote: >> > The following testcase ICEs because SSA_NAME IMM links are broken. >> > I've tracked it to DOM's optimize_stmt, a GIMPLE_COND in there is >> >

[Patch, Fortran] Test for implied sequence in structures in common blocks

Hi, I'd like to contribute this small test. I have legacy code which uses STRUCTURE statements in common blocks, and was happy to find Fritz's DEC support assumes ordering in STRUCTUREs, as the Oracle compiler does. Jim MacArthur -- 2016-09-13 Jim MacArthur

Re: [PATCH] Fix cond updating in tree-ssa-dom (PR tree-optimization/77454)

On Tue, Sep 13, 2016 at 03:21:47PM +0200, Richard Biener wrote: > > The following testcase ICEs because SSA_NAME IMM links are broken. > > I've tracked it to DOM's optimize_stmt, a GIMPLE_COND in there is > > changed, marked as modified, then in optimize_stmt > > if (gimple_modified_p (stmt) ||

Re: [PATCH] Fix cond updating in tree-ssa-dom (PR tree-optimization/77454)

On Tue, Sep 13, 2016 at 9:46 AM, Jakub Jelinek wrote: > Hi! > > The following testcase ICEs because SSA_NAME IMM links are broken. > I've tracked it to DOM's optimize_stmt, a GIMPLE_COND in there is > changed, marked as modified, then in optimize_stmt > if (gimple_modified_p

Re: RFA (libstdc++): PATCH to implement C++17 over-aligned new

On Tue, Sep 13, 2016 at 9:03 AM, Andreas Schwab wrote: > On Sep 13 2016, Jason Merrill wrote: > >> Does this help? > > Unfortunatly no. It occurs to me that this function doesn't need to restrict types at all. I'm checking this in; hopefully it will do

Re: RFA (libstdc++): PATCH to implement C++17 over-aligned new

On Sep 13 2016, Jason Merrill wrote: > Does this help? Unfortunatly no. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."

Re: RFA (libstdc++): PATCH to implement C++17 over-aligned new

On 10/09/16 07:59, Christophe Lyon wrote: > On 9 September 2016 at 23:20, Jason Merrill wrote: >> On Thu, Sep 8, 2016 at 7:06 AM, Jonathan Wakely wrote: >>> On 08/09/16 09:10 +0200, Marc Glisse wrote: Do we want a generic fallback implementation

Re: RFA (libstdc++): PATCH to implement C++17 over-aligned new

Does this help? On Tue, Sep 13, 2016 at 8:32 AM, Andreas Schwab wrote: > On Sep 12 2016, Jason Merrill wrote: > >> I'm checking in this patch, which should fix the remaining issues: > > Unfortunatly that breaks a few other tests: > > FAIL:

Re: [PATCH] Optimise the fpclassify builtin to perform integer operations when possible

On Tue, 13 Sep 2016, Tamar Christina wrote: > On 12/09/16 23:41, Joseph Myers wrote: > > Are you making endianness assumptions - specifically, does the > > reinterpretation as an integer require that WORDS_BIG_ENDIAN and > > FLOAT_WORDS_BIG_ENDIAN are the same? If so, I think that's OK (in that

Re: [PATCH] Optimize strchr (s, 0) to strlen

On Tue, 2016-09-13 at 12:36 +, Wilco Dijkstra wrote: > Richard Biener wrote: > > > > On Wed, May 18, 2016 at 2:29 PM, Wilco Dijkstra > .com> wrote: > > > > > > Richard Biener wrote: > > > > > > > > > > > Yeah ;)  I'm currently

Re: [PATCH] Optimise the fpclassify builtin to perform integer operations when possible

On Tue, 13 Sep 2016, Tamar Christina wrote: > > > On 12/09/16 23:33, Joseph Myers wrote: > > Why is this boolean false for ieee_quad_format, mips_quad_format and > > ieee_half_format? They should meet your description (even if the x86 / > > m68k "extended" formats don't because of the leading

[PATCH 1/2][AArch64] Add missing support for poly64x1_t

Hi all, This fixes a bug in the name mangling which prevented mangling of functions with return type void and arguments that require any qualifiers. e.g. void(unsigned int, unsigned int). Ran regression tests on aarch64-none-linux-gnu. Ok for trunk? Thanks, Tamar gcc/ 2016-08-02 Tamar

Re: [PATCH] Optimize strchr (s, 0) to strlen

Richard Biener wrote: > On Wed, May 18, 2016 at 2:29 PM, Wilco Dijkstra > wrote: >> Richard Biener wrote: >> >>> Yeah ;) I'm currently bootstrapping/testing the patch that makes it >>> possible to >>> write all this in match.pd. >> >> So

Re: RFA (libstdc++): PATCH to implement C++17 over-aligned new

On Sep 12 2016, Jason Merrill wrote: > I'm checking in this patch, which should fix the remaining issues: Unfortunatly that breaks a few other tests: FAIL: g++.dg/cpp0x/alignas5.C -std=c++11 (test for excess errors) FAIL: g++.dg/cpp0x/alignas5.C -std=c++14 (test for excess

Re: [PATCH] Optimise the fpclassify builtin to perform integer operations when possible

On 12/09/16 23:41, Joseph Myers wrote: Are you making endianness assumptions - specifically, does the reinterpretation as an integer require that WORDS_BIG_ENDIAN and FLOAT_WORDS_BIG_ENDIAN are the same? If so, I think that's OK (in that the only target where they aren't the same seems to be

Re: [PATCH] Optimise the fpclassify builtin to perform integer operations when possible

On 12/09/16 23:33, Joseph Myers wrote: Why is this boolean false for ieee_quad_format, mips_quad_format and ieee_half_format? They should meet your description (even if the x86 / m68k "extended" formats don't because of the leading mantissa bit being set for infinities). Ah, I played it a

Re: [PATCH] Optimise the fpclassify builtin to perform integer operations when possible

On 12/09/16 23:28, Joseph Myers wrote: On Mon, 12 Sep 2016, Tamar Christina wrote: Similar changes may be useful for __builtin_isfinite, __builtin_isnan, __builtin_isinf, __builtin_isinf_sign, __builtin_isnormal. Will your version always use only integer operations if the format is IEEE

Re: [GCC][PATCH] Add __artificial__ attribute to Aarch64 NEON intrinsics

On 05/09/16 22:37, Andrew Pinski wrote: On Mon, Sep 5, 2016 at 4:53 AM, Tamar Christina wrote: Hi all, This patch adds __artificial__ attribute to the intrinsics in arm_neon.h so that costs are associated to the user function during profiling and during the

Re: [PATCH] Optimise the fpclassify builtin to perform integer operations when possible

Jakub wrote: > On Mon, Sep 12, 2016 at 04:19:32PM +, Tamar Christina wrote: > > This patch adds an optimized route to the fpclassify builtin > > for floating point numbers which are similar to IEEE-754 in format. > > > > The goal is to make it faster by: > > 1. Trying to determine the most

Re: [PATCH 0/9] RFC: selftests based on RTL dumps

On 09/12/2016 08:57 PM, David Malcolm wrote: I'm not sure I follow - this sounds like a dedicated target for selftesting. Would it be a separate configuration i.e. something like: ../src/configure --target=rtl-selftest or somesuch? The way I imagine it working, the top-level Makefile

Re: [PATCH] Allow FP to be used as a call-saved registe

Hi Jeff, On 12/09/16 18:16, Jeff Law wrote: On 09/05/2016 08:59 AM, Tamar Christina wrote: Hi All, This patch allows the FP register to be used as a call-saved register when -fomit-frame-pointer is used. The change is done in such a way that the defaults do not change. To use the FP

Re: [PATCH 1/3] Put a TARGET_LRA_P into every target

On Tue, Sep 13, 2016 at 12:26:04PM +0200, Bernd Schmidt wrote: > On 09/13/2016 12:22 AM, Segher Boessenkool wrote: > >This patch adds a TARGET_LRA_P (defined to hook_bool_void_false) to > >every target that didn't yet override the hook. No functional change. > > This patch series makes very

Re: RFC: PATCH to consider MAX_OFILE_ALIGNMENT for targetm.absolute_biggest_alignment

On 09/12/2016 08:58 PM, Jason Merrill wrote: TARGET_ABSOLUTE_BIGGEST_ALIGNMENT is documented to be the largest alignment possible for any type or variable, and defaults to BIGGEST_ALIGNMENT. But MAX_OFILE_ALIGNMENT is typically much larger than BIGGEST_ALIGNMENT, and is documented as the limit

Re: [PATCH 1/3] Put a TARGET_LRA_P into every target

On 09/13/2016 12:22 AM, Segher Boessenkool wrote: This patch adds a TARGET_LRA_P (defined to hook_bool_void_false) to every target that didn't yet override the hook. No functional change. This patch series makes very little sense to me. Adding 35 new instances of a hook definition so you can

Re: [PATCH] optabs.c: Update inline documentation

On Mon, 12 Sep 2016, Jeff Law wrote: > > gcc/ > > * optabs.c (prepare_cmp_insn): Update documentation comment. > > > > OK to apply? > OK. > jeff Committed, thanks. Maciej

Re: [PATCH][v3] GIMPLE store merging pass

On 08/09/16 16:25, Bernhard Reutner-Fischer wrote: On 8 September 2016 at 10:31, Kyrill Tkachov wrote: On 07/09/16 20:03, Bernhard Reutner-Fischer wrote: On September 6, 2016 5:14:47 PM GMT+02:00, Kyrill Tkachov wrote: Thanks, fixed

Re: [Patch AArch64] Add floatdihf2 and floatunsdihf2 patterns

On Tue, Sep 06, 2016 at 10:19:50AM +0100, James Greenhalgh wrote: > This patch adds patterns for conversion from 64-bit integer to 16-bit > floating-point values under AArch64 targets which don't have support for > the ARMv8.2-A 16-bit floating point extensions. > > We implement these by first

Re: [C PATCH] Tidy build_unary_op

On Mon, Sep 12, 2016 at 09:53:52PM +, Joseph Myers wrote: > On Sat, 10 Sep 2016, Marek Polacek wrote: > > > A minor cleanup. First, FLAG is a really bad name for a parameter, and > > second, > > using two vars for the same thing is redundant (we never modify any of > > them). > > Also some

Re: [Patch] Implement std::experimental::variant

On 26/08/16 18:56, Tim Shen wrote: >> >> Adding '#include ' to >> 'include/c++/7.0.0/variant' "fixes" that. Not sure its the right >> approach though. > > Why not? > I'm not saying its the wrong approach, I'm just saying thats the first thing I tried and it "seemed" to solve it but I didnt

Re: [PATCH] Optimise the fpclassify builtin to perform integer operations when possible

On Mon, Sep 12, 2016 at 04:19:32PM +, Tamar Christina wrote: > This patch adds an optimized route to the fpclassify builtin > for floating point numbers which are similar to IEEE-754 in format. > > The goal is to make it faster by: > 1. Trying to determine the most common case first >

Re: RFA (libstdc++): PATCH to implement C++17 over-aligned new

On 12 September 2016 at 22:57, Jason Merrill wrote: > I'm checking in this patch, which should fix the remaining issues: > Hi Jason, Since this commit (r240100), I'm seeing failures on: g++.dg/cpp0x/gen-attrs-21.C -std=c++11 (test for excess errors)

Re: Verify package integrity of downloaded prerequisites (partially fixes 61439)

Joseph Myers writes: > On Sun, 11 Sep 2016, Moritz Klammler wrote: > >> gmp='gmp-4.3.2.tar.bz2' >> mpfr='mpfr-2.4.2.tar.bz2' >> mpc='mpc-0.8.1.tar.gz' >> isl='isl-0.15.tar.bz2' > > These are not the versions used in the current script (given which, > presumably you need

Re: [v3 PATCH] Implement P0040R3, Extending memory management tools.

On 13/09/16 00:59 +0300, Ville Voutilainen wrote: @@ -682,6 +686,98 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION std::__iterator_category(__first)); } #endif +#if __cplusplus > 201402L + template +inline void +

[C++ PATCH] Implement P0028R4, C++17 using attribute namespaces without repetition

Hi! This patch implements the P0028R4 C++17 enhancement. First I found a bug in the C++11 std attribute handling, where [[bitand, bitand::foo]] has been allowed, but not [[foo::bitand]] (i.e. the identifier after :: accepted only non-keyword and keyword identifiers but not alternative tokens,

[C++ PATCH] Fix constexpr POINTER_PLUS_EXPR handling (PR c++/77553)

Hi! The testcase below shows a bug in POINTER_PLUS_EXPR constexpr handling. It is handled by 2 different functions, cxx_eval_pointer_plus_expression and cxx_eval_binary_expression, where the first one calls cxx_eval_constant_expression on both operands and in some cases optimizes it, in other

[PATCH] Fix cond updating in tree-ssa-dom (PR tree-optimization/77454)

Hi! The following testcase ICEs because SSA_NAME IMM links are broken. I've tracked it to DOM's optimize_stmt, a GIMPLE_COND in there is changed, marked as modified, then in optimize_stmt if (gimple_modified_p (stmt) || modified_p) { tree val = NULL; update_stmt_if_modified