Re: [PATCH] Fix up orig_loop_num handling during move_sese_region_to_fn (PR tree-optimization/81945)

On December 5, 2017 10:05:43 PM GMT+01:00, Jakub Jelinek wrote: >Hi! > >move_sese_region_to_fn moves a subset of the original loop tree >to the dest_cfun (and adds the outermost loop new). >Now, some loops might have non-zero orig_loop_num field. In the caller >that is fine,

Re: [PATCH] Fix PR80846, change vectorizer reduction epilogue (on x86)

On December 5, 2017 9:18:46 PM GMT+01:00, Jeff Law wrote: >On 11/28/2017 08:15 AM, Richard Biener wrote: >> >> The following adds a new target hook, >targetm.vectorize.split_reduction, >> which allows the target to specify a preferred mode to perform the >> final reducion on

Re: [043/nnn] poly_int: frame allocations

On 10/23/2017 11:18 AM, Richard Sandiford wrote: > This patch converts the frame allocation code (mostly in function.c) > to use poly_int64 rather than HOST_WIDE_INT for frame offsets and > sizes. > > > 2017-10-23 Richard Sandiford > Alan Hayward

Re: [063/nnn] poly_int: vectoriser vf and uf

On 10/23/2017 11:26 AM, Richard Sandiford wrote: > This patch changes the type of the vectorisation factor and SLP > unrolling factor to poly_uint64. This in turn required some knock-on > changes in signedness elsewhere. > > Cost decisions are generally based on estimated_poly_value, > which for

Re: [103/nnn] poly_int: TYPE_VECTOR_SUBPARTS

On 10/23/2017 11:41 AM, Richard Sandiford wrote: > This patch changes TYPE_VECTOR_SUBPARTS to a poly_uint64. The value is > encoded in the 10-bit precision field and was previously always stored > as a simple log2 value. The challenge was to use this 10 bits to > encode the number of elements in

Re: [101/nnn] poly_int: GET_MODE_NUNITS

On 10/23/2017 11:41 AM, Richard Sandiford wrote: > This patch changes GET_MODE_NUNITS from unsigned char > to poly_uint16, although it remains a macro when compiling > target code with NUM_POLY_INT_COEFFS == 1. > > If the number of units isn't known at compile time, we use: > > (const:M

Re: [068/nnn] poly_int: current_vector_size and TARGET_AUTOVECTORIZE_VECTOR_SIZES

On 10/23/2017 11:28 AM, Richard Sandiford wrote: > This patch changes the type of current_vector_size to poly_uint64. > It also changes TARGET_AUTOVECTORIZE_VECTOR_SIZES so that it fills > in a vector of possible sizes (as poly_uint64s) instead of returning > a bitmask. The documentation claimed

Re: [073/nnn] poly_int: vectorizable_load/store

On 10/23/2017 11:29 AM, Richard Sandiford wrote: > This patch makes vectorizable_load and vectorizable_store cope with > variable-length vectors. The reverse and permute cases will be > excluded by the code that checks the permutation mask (although a > patch after the main SVE submission adds

Re: [056/nnn] poly_int: MEM_REF offsets

On 10/23/2017 11:23 AM, Richard Sandiford wrote: > This patch allows MEM_REF offsets to be polynomial, with mem_ref_offset > now returning a poly_offset_int instead of an offset_int. The > non-mechanical changes to callers of mem_ref_offset were handled by > previous patches. > > > 2017-10-23

Re: [027/nnn] poly_int: DWARF CFA offsets

On 10/23/2017 11:10 AM, Richard Sandiford wrote: > This patch makes the DWARF code use poly_int64 rather than > HOST_WIDE_INT for CFA offsets. The main changes are: > > - to make reg_save use a DW_CFA_expression representation when > the offset isn't constant and > > - to record the CFA

Re: [070/nnn] poly_int: vectorizable_reduction

On 11/22/2017 11:09 AM, Richard Sandiford wrote: > Richard Sandiford writes: >> This patch makes vectorizable_reduction cope with variable-length vectors. >> We can handle the simple case of an inner loop reduction for which >> the target has native support for the

Re: [030/nnn] poly_int: get_addr_unit_base_and_extent

On 10/23/2017 11:12 AM, Richard Sandiford wrote: > This patch changes the values returned by > get_addr_unit_base_and_extent from HOST_WIDE_INT to poly_int64. > > maxsize in gimple_fold_builtin_memory_op goes from HOST_WIDE_INT > to poly_uint64 (rather than poly_int) to match the previous use >

Re: [019/nnn] poly_int: lra frame offsets

On 10/23/2017 11:07 AM, Richard Sandiford wrote: > This patch makes LRA use poly_int64s rather than HOST_WIDE_INTs > to store a frame offset (including in things like eliminations). > > > 2017-10-23 Richard Sandiford > Alan Hayward

Re: [045/nnn] poly_int: REG_ARGS_SIZE

On 10/23/2017 11:19 AM, Richard Sandiford wrote: > This patch adds new utility functions for manipulating REG_ARGS_SIZE > notes and allows the notes to carry polynomial as well as constant sizes. > > The code was inconsistent about whether INT_MIN or HOST_WIDE_INT_MIN > should be used to

Re: [PATCH] emit a trap for buffer overflow in placement new

On 12/05/2017 06:53 AM, Jonathan Wakely wrote: On 05/12/17 09:48 +0100, Marc Glisse wrote: On Mon, 4 Dec 2017, Martin Sebor wrote: On 12/04/2017 03:44 PM, Marc Glisse wrote: On Mon, 4 Dec 2017, Martin Sebor wrote: The -Wplacement-new option warns for buffer overflow in placement new

Re: [031/nnn] poly_int: aff_tree

On 10/23/2017 11:12 AM, Richard Sandiford wrote: > This patch changes the type of aff_tree::offset from widest_int to > poly_widest_int and adjusts the function interfaces in the same way. > > > 2017-10-23 Richard Sandiford > Alan Hayward

Re: [PATCH] avoid bogus -Wstringop-overflow for strncpy with _FORTIFY_SOURCE (PR 82646)

On 12/05/2017 04:47 PM, Martin Sebor wrote: > PR middle-end/82646 - bogus -Wstringop-overflow with > -D_FORTIFY_SOURCE=2 on strncpy with range to a member array, > > The bug points out a false positive in a call to strncpy() when > _FORTIFY_SOURCE is defined that doesn't exist otherwise. > > The 

Re: [023/nnn] poly_int: store_field & co

On 10/23/2017 11:09 AM, Richard Sandiford wrote: > This patch makes store_field and related routines use poly_ints > for bit positions and sizes. It keeps the existing choices > between signed and unsigned types (there are a mixture of both). > > > 2017-10-23 Richard Sandiford

[PATCH] avoid bogus -Wstringop-overflow for strncpy with _FORTIFY_SOURCE (PR 82646)

PR middle-end/82646 - bogus -Wstringop-overflow with -D_FORTIFY_SOURCE=2 on strncpy with range to a member array, The bug points out a false positive in a call to strncpy() when _FORTIFY_SOURCE is defined that doesn't exist otherwise. The problem is that __builtin_strncpy buffer overflow

Re: [021/nnn] poly_int: extract_bit_field bitrange

On 10/23/2017 11:08 AM, Richard Sandiford wrote: > Similar to the previous store_bit_field patch, but for extractions > rather than insertions. The patch splits out the extraction-as-subreg > handling into a new function (extract_bit_field_as_subreg), both for > ease of writing and because a

Re: [020/nnn] poly_int: store_bit_field bitrange

On 10/23/2017 11:08 AM, Richard Sandiford wrote: > This patch changes the bitnum and bitsize arguments to > store_bit_field from unsigned HOST_WIDE_INTs to poly_uint64s. > The later part of store_bit_field_1 still needs to operate > on constant bit positions and sizes, so the patch splits > it out

Re: [022/nnn] poly_int: C++ bitfield regions

On 10/23/2017 11:08 AM, Richard Sandiford wrote: > This patch changes C++ bitregion_start/end values from constants to > poly_ints. Although it's unlikely that the size needs to be polynomial > in practice, the offset could be with future language extensions. > > > 2017-10-23 Richard Sandiford

Re: [086/nnn] poly_int: REGMODE_NATURAL_SIZE

On 10/23/2017 11:34 AM, Richard Sandiford wrote: > This patch makes target-independent code that uses REGMODE_NATURAL_SIZE > treat it as a poly_int rather than a constant. > > > 2017-10-23 Richard Sandiford > Alan Hayward >

Re: [100/nnn] poly_int: memrefs_conflict_p

On 10/23/2017 11:40 AM, Richard Sandiford wrote: > The xsize and ysize arguments to memrefs_conflict_p are encode such > that: > > - 0 means the size is unknown > - >0 means the size is known > - <0 means that the negative of the size is a worst-case size after > alignment > > In other words,

Re: [051/nnn] poly_int: emit_group_load/store

On 10/23/2017 11:21 AM, Richard Sandiford wrote: > This patch changes the sizes passed to emit_group_load and > emit_group_store from int to poly_int64. > > > 2017-10-23 Richard Sandiford > Alan Hayward > David Sherwood

Re: [048/nnn] poly_int: cfgexpand stack variables

On 10/23/2017 11:20 AM, Richard Sandiford wrote: > This patch changes the type of stack_var::size from HOST_WIDE_INT > to poly_uint64. The difference in signedness is because the > field was set by: > > v->size = tree_to_uhwi (size); > > > 2017-10-23 Richard Sandiford

Re: [037/nnn] poly_int: get_bit_range

On 10/23/2017 11:14 AM, Richard Sandiford wrote: > This patch makes get_bit_range return the range and position as poly_ints. > > > 2017-10-23 Richard Sandiford > Alan Hayward > David Sherwood

[PATCH] v4: C/C++: don't suggest implementation names as spelling fixes (PR c/83236)

On Mon, 2017-12-04 at 15:34 -0500, Jason Merrill wrote: > On Mon, Dec 4, 2017 at 12:00 PM, David Malcolm > wrote: > > * don't filter suggestions if the name name being looked up > > is itself reserved for implementation > > I wonder if we want to avoid filtering if the name

Re: [024/nnn] poly_int: ira subreg liveness tracking

Jeff Law writes: > On 10/23/2017 11:09 AM, Richard Sandiford wrote: >> Normmaly the IRA-reload interface tries to track the liveness of >> individual bytes of an allocno if the allocno is sometimes written >> to as a SUBREG. This isn't possible for variable-sized allocnos, >>

Re: [PATCH, GCC/testsuite] Fix dump-noaddr dumpbase

On Dec 5, 2017, at 12:56 PM, Thomas Preudhomme wrote: > > Thanks, I've tested after the two commits and it works both in tree and out > of tree. It'll simplify comparing in tree results Vs out of tree for us, > thanks a lot! > > Would you consider a backport

[PATCH] Fix up orig_loop_num handling during move_sese_region_to_fn (PR tree-optimization/81945)

Hi! move_sese_region_to_fn moves a subset of the original loop tree to the dest_cfun (and adds the outermost loop new). Now, some loops might have non-zero orig_loop_num field. In the caller that is fine, if the orig_loop_num loop is moved, then get_loop will just return NULL and we'll clear it

Re: [PATCH, GCC/testsuite] Fix dump-noaddr dumpbase

Hi Mike, Thanks, I've tested after the two commits and it works both in tree and out of tree. It'll simplify comparing in tree results Vs out of tree for us, thanks a lot! Would you consider a backport to stable branches if nobody complains after a week? Best regards, Thomas On 05/12/17

Re: [PATCH] Fix PR80846, change vectorizer reduction epilogue (on x86)

On 11/28/2017 08:15 AM, Richard Biener wrote: > > The following adds a new target hook, targetm.vectorize.split_reduction, > which allows the target to specify a preferred mode to perform the > final reducion on using either vector shifts or scalar extractions. > Up to that mode the vector

Re: [PATCH] [pr#83069] Keep profile_count for bb under real_bb_freq_max

On 11/28/2017 04:34 AM, Siddhesh Poyarekar wrote: > On Friday 24 November 2017 05:36 PM, Siddhesh Poyarekar wrote: >> freq_max < 1, i.e. highest frequency among bbs in the function being >> higher than real_bb_freq_max means that the bb ends up with a profile >> count larger than real_bb_freq_max

Re: [PATCH, GCC/testsuite] Fix dump-noaddr dumpbase

On Dec 5, 2017, at 11:11 AM, Thomas Preudhomme wrote: > > On 05/12/17 17:54, Andrew Pinski wrote: >> On Tue, Dec 5, 2017 at 9:50 AM, Thomas Preudhomme >> wrote: >>> Hi, >>> >>> dump-noaddr test FAILS when $tmpdir is not the same

Re: [PATCH, GCC/testsuite] Fix dump-noaddr dumpbase

On Dec 5, 2017, at 9:54 AM, Andrew Pinski wrote: > > On Tue, Dec 5, 2017 at 9:50 AM, Thomas Preudhomme > wrote: >> Hi, >> >> dump-noaddr test FAILS when $tmpdir is not the same as the directory >> where runtest is called from. Note that this

Re: [PATCH, GCC/testsuite] Fix dump-noaddr dumpbase

On 05/12/17 17:54, Andrew Pinski wrote: On Tue, Dec 5, 2017 at 9:50 AM, Thomas Preudhomme wrote: Hi, dump-noaddr test FAILS when $tmpdir is not the same as the directory where runtest is called from. Note that this does not happen when running make check

Re: [PATCH libstdc++/66689] comp_ellint_3 and ellint_3 return garbage values

On Mon, Nov 20, 2017 at 4:51 PM, Jonathan Wakely wrote: > On 20/11/17 21:07 +, Jonathan Wakely wrote: >> >> On 20/11/17 21:01 +, Jonathan Wakely wrote: >>> >>> On 20/11/17 21:43 +0100, Christophe Lyon wrote: On 20 November 2017 at 17:02, David Edelsohn

Re: [PATCH] PR ada/66205 gnatbind generates invalid code when finalization is enabled in restricted runtime

> I've come up with a considerably simpler patch, which merely causes the > procedure adafinal to be generated with a null body if the restriction > No_Task_Termination is set (note, this restriction is part of the > Ravenscar profile; if tasks can't terminate, program level finalization > can't

C++ PATCH for c++/82331, ICE with variadic specialization of auto template parm

The problem here is that deduction of F tries to substitute into the type of F, but we haven't deduced R or A yet, so we can't do anything. tsubst_pack_expansion knows how to handle this, but only expects to see it within a template. In general, substitution in the middle of deduction needs to be

Re: [Patch, Fortran, F2008] PR 44549: Type-bound procedure: bogus error from list after PROCEDURE

On 16 June 2010 at 14:56, Janus Weil wrote: >>> Regtested on x86_64-unknown-linux-gnu. Ok for trunk? >>> >> >> OK. Kudos to Dominique for finding it and thanks, Janus, for fixing it. > > Thanks. Committed as r160834. @@ -4591,12 +4591,14 @@ gfc_check_symbol_typed (gfc_symbol*

[AArch64] Fix ICEs in aarch64_print_operand

Three related regression fixes: - We can't use asserts like: gcc_assert (GET_MODE_SIZE (mode) == 16); in aarch64_print_operand because it could trigger for invalid user input. - The output_operand_lossage in aarch64_print_address_internal: output_operand_lossage ("invalid operand

Re: [PATCH, GCC/testsuite] Fix dump-noaddr dumpbase

On Tue, Dec 5, 2017 at 9:50 AM, Thomas Preudhomme wrote: > Hi, > > dump-noaddr test FAILS when $tmpdir is not the same as the directory > where runtest is called from. Note that this does not happen when > running make check because tmpdir is set to srcdir. > > In

[PATCH, GCC/testsuite] Fix dump-noaddr dumpbase

Hi, dump-noaddr test FAILS when $tmpdir is not the same as the directory where runtest is called from. Note that this does not happen when running make check because tmpdir is set to srcdir. In that case, file mkdir will create the directory in the current directory while GCC is invoked from

Re: [076/nnn] poly_int: vectorizable_conversion

On 11/28/2017 11:09 AM, Richard Sandiford wrote: > Jeff Law writes: >> On 10/23/2017 11:30 AM, Richard Sandiford wrote: >>> This patch makes vectorizable_conversion cope with variable-length >>> vectors. We already require the number of elements in one vector >>> to be a

Re: [080/nnn] poly_int: tree-vect-generic.c

On 10/23/2017 11:32 AM, Richard Sandiford wrote: > This patch makes tree-vect-generic.c cope with variable-length vectors. > Decomposition is only supported for constant-length vectors, since we > should never generate unsupported variable-length operations. > > > 2017-10-23 Richard Sandiford

Re: [079/nnn] poly_int: vect_no_alias_p

On 10/23/2017 11:32 AM, Richard Sandiford wrote: > This patch replaces the two-state vect_no_alias_p with a three-state > vect_compile_time_alias that handles polynomial segment lengths. > > > 2017-10-23 Richard Sandiford > Alan Hayward

Re: [071/nnn] poly_int: vectorizable_induction

On 10/23/2017 11:29 AM, Richard Sandiford wrote: > This patch makes vectorizable_induction cope with variable-length > vectors. For now we punt on SLP inductions, but patchees after > the main SVE submission add support for those too. > > > 2017-10-23 Richard Sandiford

Re: [064/nnn] poly_int: SLP max_units

On 10/23/2017 11:26 AM, Richard Sandiford wrote: > This match makes tree-vect-slp.c track the maximum number of vector > units as a poly_uint64 rather than an unsigned int. > > > 2017-10-23 Richard Sandiford > Alan Hayward >

Re: [066/nnn] poly_int: omp_max_vf

On 10/23/2017 11:27 AM, Richard Sandiford wrote: > This patch makes omp_max_vf return a polynomial vectorization factor. > We then need to be able to stash a polynomial value in > OMP_CLAUSE_SAFELEN_EXPR too: > >/* If max_vf is non-zero, then we can use only a vectorization factor > up

Re: [065/nnn] poly_int: vect_nunits_for_cost

On 10/23/2017 11:27 AM, Richard Sandiford wrote: > This patch adds a function for getting the number of elements in > a vector for cost purposes, which is always constant. It makes > it possible for a later patch to change GET_MODE_NUNITS and > TYPE_VECTOR_SUBPARTS to a poly_int. > > >

Re: [062/nnn] poly_int: prune_runtime_alias_test_list

On 10/23/2017 11:25 AM, Richard Sandiford wrote: > This patch makes prune_runtime_alias_test_list take the iteration > factor as a poly_int and tracks polynomial offsets internally > as well. > > > 2017-10-23 Richard Sandiford > Alan Hayward

Re: [060/nnn] poly_int: loop versioning threshold

On 10/23/2017 11:25 AM, Richard Sandiford wrote: > This patch splits the loop versioning threshold out from the > cost model threshold so that the former can become a poly_uint64. > We still use a single test to enforce both limits where possible. > > > 2017-10-23 Richard Sandiford

[PR C++/83287] Mark lookup for keeping

This fixes 83287, a case where we failed to mark a lookup occuring inside a template definition as being kept for instantiation. It turns out that CAST_EXPR's single argument is a TREE_LIST, so we need to check it for OVERLOADS. CAST_EXPR behaves this way because it's modelling a function

Re: [059/nnn] poly_int: tree-ssa-loop-ivopts.c:iv_use

On 10/23/2017 11:24 AM, Richard Sandiford wrote: > This patch makes ivopts handle polynomial address offsets > when recording potential IV uses. > > > 2017-10-23 Richard Sandiford > Alan Hayward > David Sherwood

Re: [052/nnn] poly_int: bit_field_size/offset

On 10/23/2017 11:22 AM, Richard Sandiford wrote: > verify_expr ensured that the size and offset in gimple BIT_FIELD_REFs > satisfied tree_fits_uhwi_p. This patch extends that so that they can > be poly_uint64s, and adds helper routines for accessing them when the > verify_expr requirements apply.

Re: [042/nnn] poly_int: reload1.c

On 10/23/2017 11:18 AM, Richard Sandiford wrote: > This patch makes a few small poly_int64 changes to reload1.c, > mostly related to eliminations. Again, there's no real expectation > that reload will be used for targets that have polynomial-sized modes, > but it seemed easier to convert it

Re: [PATCH] PR ada/66205 gnatbind generates invalid code when finalization is enabled in restricted runtime

On 7 Mar 2017, at 16:20, Simon Wright wrote: > > On 19 Dec 2015, at 22:05, Simon Wright wrote: >> >> On 12 Nov 2015, at 10:02, Arnaud Charlet wrote: >>> > This situation arises, for example, with an embedded RTS that >

Re: [041/nnn] poly_int: reload.c

On 10/23/2017 11:18 AM, Richard Sandiford wrote: > This patch makes a few small poly_int64 changes to reload.c, > such as in the "decomposition" structure. In practice, any > port with polynomial-sized modes should be using LRA rather > than reload, but it's easier to convert reload anyway than >

Re: [035/nnn] poly_int: expand_debug_expr

On 10/23/2017 11:14 AM, Richard Sandiford wrote: > This patch makes expand_debug_expr track polynomial memory offsets. > It simplifies the handling of the case in which the reference is not > to the first byte of the base, which seemed non-trivial enough to > make it worth splitting out as a

Re: [GCC 9][RFC][PATCH] Optimize PHIs with constant arguments better

On 12/04/2017 02:25 PM, Michael Matz wrote: > Hi, > > On Thu, 30 Nov 2017, Jeff Law wrote: > >> And after PHI propagation we have: >> # m_5 = PHI <10(5), 12(6), 14(7)> >> # _2 = PHI <10(5), 12(6), 14(7)> >> # _3 = PHI <320(5), 384(6), 448(7)> >> : >> goto ; [100.00%] >> >> DCE will come

Re: [PATCH] enhance documentation of -Wstringop-truncation

On 12/03/2017 04:55 PM, Martin Sebor wrote: > It was suggested to me that it might be helpful to mention > attribute nonstring as a solution to -Wstringop-truncation > warnings.  I think it's a good idea to add a reference to > the attribute to the manual.  The attached patch does that. > > Since 

[Patch ARM] Fix probe_stack constraint.

The probe_stack pattern uses r0 as a fixed register. This can cause issues if we have auto-increment instructions coming out that have r0 as the base register. Tested with a bootstrap and regression run. richi reports that the original issue was fixed in the run. I did consider whether

[committed] Fix avx256-unaligned* testcases (PR testsuite/83289)

Hi! As Segher mentioned, the -dp printed alternative numbers used to be one based, but now are zero based. This adjusts all the -dp testcases that have /[1-9] regexps. Tested on x86_64-linux and i686-linux, committed to trunk. 2017-12-05 Jakub Jelinek PR

Re: libstdc++ PATCH to harmonize noexcept

On 01/12/17 15:32 +, Jonathan Wakely wrote: On 14/11/17 13:56 -0500, Jason Merrill wrote: While working on an unrelated issue I noticed that the compiler didn't like some of these declarations after preprocessing, when they aren't protected by system-header permissiveness. I thought about

[PATCH] Fix PR83277

The following fixes a code-gen error in GRAPHITE. liveout handling is still somewhat flaky and the easiest fix is to force code generation of defs where ISL scheduled them (rather than at the PHI edge src). Bootstrapped and tested on x86_64-unknown-linux-gnu, applied. Richard. 2017-12-05

Re: [Patch][aarch64] Add missing thunderx2-t99 instruction scheduling pipeline descriptions.

On Mon, Dec 04, 2017 at 05:33:37PM +, Steve Ellcey wrote: > On Mon, 2017-12-04 at 17:18 +, Kyrill Tkachov wrote: > > > > +(define_insn_reservation "thunderx2t99_multiple" 1 > > > +  (and (eq_attr "tune" "thunderx2t99") > > > +   (eq_attr "type" "multiple")) > > > +  

Re: [AArch64] Fix some define_insn_and_split conditions

On Tue, Dec 05, 2017 at 02:28:56PM +, Richard Sandiford wrote: > The split conditions for aarch64_simd_bsldi_internal and > aarch64_simd_bsldi_alt were: > > "&& GP_REGNUM_P (REGNO (operands[0]))" > > But since they (deliberately) can be split before reload, the operand > matched by

Re: [PATCH] gcc: xtensa: enable address sanitizer

On Mon, Dec 4, 2017 at 9:37 PM, augustine.sterl...@gmail.com wrote: > On Mon, Dec 4, 2017 at 1:28 PM, Max Filippov wrote: >> gcc/ >> 2017-12-04 Max Filippov >> >> * config/xtensa/xtensa.c

[AArch64] Fix some define_insn_and_split conditions

The split conditions for aarch64_simd_bsldi_internal and aarch64_simd_bsldi_alt were: "&& GP_REGNUM_P (REGNO (operands[0]))" But since they (deliberately) can be split before reload, the operand matched by register_operand can be a SUBREG rather than a REG. This triggered a boostrap failure

Re: C++ PATCH for c++/79228, complex literal suffixes

OK, thanks. On Tue, Dec 5, 2017 at 7:33 AM, Jakub Jelinek wrote: > On Fri, Dec 01, 2017 at 03:16:23PM -0500, Jason Merrill wrote: >> commit e39b7d506d236ce7ef9f64d1bcf0b384bb2d8038 >> Author: Jason Merrill >> Date: Fri Dec 1 07:45:03 2017 -0500 >> >>

Re: [PATCH] emit a trap for buffer overflow in placement new

On 05/12/17 09:48 +0100, Marc Glisse wrote: On Mon, 4 Dec 2017, Martin Sebor wrote: On 12/04/2017 03:44 PM, Marc Glisse wrote: On Mon, 4 Dec 2017, Martin Sebor wrote: The -Wplacement-new option warns for buffer overflow in placement new expressions with objects of constant sizes, but

[PATCH] Avoid introducing UB in match.pd (T)(P+A)-(T)(P+B) and similar optimizations (PR sanitizer/81281)

Hi! As mentioned in the PR, while (T)(P + A) - (T)P -> (T) A shouldn't introduce UB when it wasn't there earlier, (T)P - (T)(P + A) -> -(T) A and (T)(P + A) - (T)(P + B) -> (T)A - (T)B can, so if the conversion to T isn't widening and T has undefined overflow, then we need to perform the negation

[committed] Avoid i suffixes in libgomp oacc testsuite (PR testsuite/83281)

Hi! The i suffix in C++14 does something different now, so I've changed it to use the j suffix which stayed as is. Regtested on x86_64-linux and i686-linux, committed to trunk. 2017-12-05 Jakub Jelinek PR testsuite/83281 *

[committed] Add testcase for already fixed PR (PR tree-optimization/83283)

Hi! This testcase has been fixed by r253146 but that testcase is quite different from this one, so I've committed this to trunk as obvious. 2017-12-05 Jakub Jelinek PR tree-optimization/83283 * g++.dg/torture/pr83283.C: New test. ---

[PATCH] Add timevars to tree-ssa-math-opts.c passes

Just noticed they're missing. Bootstrapped and tested on x86_64-unknown-linux-gnu, applied. Richard. 2017-12-05 Richard Biener * timevar.def (TV_TREE_RECIP, TV_TREE_SINCOS, TV_TREE_WIDEN_MUL): Add. * tree-ssa-math-opts.c

Re: [PATCH][gimple-interchange] Final cleanup stuff

On Tue, Dec 5, 2017 at 1:02 PM, Richard Biener wrote: > > This is my final sweep through the code doing cleanup on-the-fly. Hi, Thanks very much for all your help! > > I think the code is ready to go now (after you committed your changes). > > What I'd eventually like to see is

Re: [PR 83141] Prevent SRA from removing type changing assignment

On Tue, 5 Dec 2017, Martin Jambor wrote: > On Tue, Dec 05 2017, Martin Jambor wrote: > > On Tue, Dec 05 2017, Martin Jambor wrote: > > Hi, > > > >> Hi, > >> > >> this is a followup to Richi's > >> https://gcc.gnu.org/ml/gcc-patches/2017-11/msg02396.html to fix PR > >> 83141. The basic idea is

[PATCH][gimple-interchange] Final cleanup stuff

This is my final sweep through the code doing cleanup on-the-fly. I think the code is ready to go now (after you committed your changes). What I'd eventually like to see is merge the two loop_cand objects into a single interchange_cand object, having two really confuses me when reading and

Re: [PATCH] Add testcase for PR83252 (was Re: patch to fix PR80818)

On Mon, Dec 04, 2017 at 11:52:01AM +0100, Jakub Jelinek wrote: > On Wed, Nov 29, 2017 at 05:21:22PM -0500, Vladimir Makarov wrote: > > The following patch fixes > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80818 > > > > The patch was successfully tested and bootstrapped on x86_64.

[Ada] Improve debugging of task type discriminants

This patch improves the debugging information generated by the compiler for task discriminant. No test available. Tested on x86_64-pc-linux-gnu, committed on trunk 2017-12-05 Javier Miranda * exp_ch9.adb (Install_Private_Data_Declarations): Add missing

[Ada] Spurious error with private overriding of overloaded subprogram

This patch fixds a spurious error report on a prefixed call where the operation is a private overriding of a visible operation, and the operation has various overloadings in the visible and private parts. Tested on x86_64-pc-linux-gnu, committed on trunk gcc/ada/ 2017-12-05 Ed Schonberg

[Ada] Reject properly an aspect Predicate on a formal type

This patch adds a check to reject an aspect Predicate on a formal type declaration. Compiling gen.adb must yield: gen.ads:2:55: predicate cannot apply to formal type --- generic type T is array (Integer range <>) of Integer with Predicate => T'First /= 1; function Gen return

Re: C++ PATCH for c++/79228, complex literal suffixes

On Fri, Dec 01, 2017 at 03:16:23PM -0500, Jason Merrill wrote: > commit e39b7d506d236ce7ef9f64d1bcf0b384bb2d8038 > Author: Jason Merrill > Date: Fri Dec 1 07:45:03 2017 -0500 > > PR c++/79228 - extensions hide C++14 complex literal operators > > libcpp/ >

Re: [PATCH 1/2] [SPARC] Prevent -mfix-ut699 from generating b2bst errata sequences

But isn't that the change I already rejected back in July? You are right, that was a mistake from our side to submit it again. We had rediscovered the sequence using our scanning script and I forgot that the sequence was harmless in this case. We will update our scripts and revert the patch.

[Ada] Warn on weal elaboration model for SPARK

This patch introduces a check which ensures that SPARK elaboration code is processed using the static elaboration model as it guarantees the highest degree of safety. -- Source -- -- spark_pack.ads package SPARK_Pack with SPARK_Mode is pragma Elaborate_Body;

[Ada] Fix indirect calls to imported subprograms within generic

Our trampoline avoidance scheme based on subprogram descriptors should always be disconnected for subprograms with foreign convention. For access to subprogram subtypes, the Set_Convention front-end procedure is expected to take care of this, but it currently only does so for subtypes not within a

Re: [i386] Mask generation in avx2intrin.h

Adding Cc: Uros and Kirill https://gcc.gnu.org/ml/gcc-patches/2017-11/msg02233.html On Sat, 25 Nov 2017, Marc Glisse wrote: Hello, the way full masks are generated currently in avx2intrin.h is questionable: opaque for the inline functions, weird/wrong for the macros. It is possible we may

[Ada] Fix end-of dwarf section detection in address symbolizer

When executing a Line Number program statement, the state machine bails out a few bytes before the current offset reaches the end of section to account for possible padding bytes at the end. The current test is checking if current_offset + 4 >= section_length, which is too early for e.g. a

Re: [PR 83141] Prevent SRA from removing type changing assignment

On Tue, Dec 05 2017, Martin Jambor wrote: > On Tue, Dec 05 2017, Martin Jambor wrote: > Hi, > >> Hi, >> >> this is a followup to Richi's >> https://gcc.gnu.org/ml/gcc-patches/2017-11/msg02396.html to fix PR >> 83141. The basic idea is simple, be just as conservative about type >> changing

[Ada] Propagate SLOC in iteration over array

Expand_Iterator_Loop_Over_Array turns a loop over an array: for Element of Array loop into a loop with an explicit iteration variable, but it doesn't propagate the SLOC of Element onto the new iteration variable. This results in inaccurate information when precise coverage is requested, as

[Ada] Fix handling of load addresses for backtraces through SO

The processing of shared library load addresses for backtrace symbolization suffers from disconnects between various parts in the runtime library regarding where run-time vs shared-object-file-relative addresses are at hand. At some points the code processes a local copy of each address coming

[Ada] Improper visibility of loop parameter with Iterable aspect

This patch fixes a visibility bug in the expansion of a loop over an object whose type carries the GNAT-specific Iterable aspect. Prior to this patch, the loop variable remained visible after exit from the loop. Compiling iterator_test.adb must yield: iterator_test.adb:26:61: "number" is not

Re: [PATCH branch/gimple-interchange]obvious cleanup

On Tue, Dec 5, 2017 at 11:07 AM, Bin Cheng wrote: > Hi, > This is an obvious cleanup patch doing variable renaming, function inlining. > Is it OK? Yes. Thanks, Richard. > Thanks, > bin > 2017-12-05 Bin Cheng > > * gimple-loop-interchange.cc

Re: [PATCH 1/2] [SPARC] Prevent -mfix-ut699 from generating b2bst errata sequences

> The sequence > st > fdivd / fsqrtd > std > was generated in some cases with -mfix-ut699 when there was > a st before the div/sqrt. This sequence could trigger the b2bst errata. > > Now the following safe sequence is generated instead: > st > nop > fdivd / fsqrtd > std > >

[PATCH branch/gimple-interchange]obvious cleanup

Hi, This is an obvious cleanup patch doing variable renaming, function inlining. Is it OK? Thanks, bin 2017-12-05 Bin Cheng * gimple-loop-interchange.cc (struct induction): Rename fields. (dump_induction, loop_cand::analyze_induction_var): Update uses.

Re: [PATCH] ARM testsuite: force hardfp for addr-modes-float.c

On 01/12/17 15:43, Charles Baylis wrote: On 30 November 2017 at 15:56, Kyrill Tkachov wrote: So is it the case that you don't run any arm tests that include arm_neon.h in your configuration? No, it is only the case that any arm test which includes arm_neon.h

Re: [PATCH] Add -fsanitize=pointer-{compare,subtract}.

On Tue, Nov 21, 2017 at 12:59:46PM +0100, Martin Liška wrote: > On 10/16/2017 10:39 PM, Martin Liška wrote: > > Hi. > > > > All nits included in mainline review request I've just done: > > https://reviews.llvm.org/D38971 > > > > Martin > > Hi. > > There's updated version of patch where I added

Re: [PATCH][gimple-interchange] Add reduction validity check

On Mon, 4 Dec 2017, Richard Biener wrote: > On Mon, 4 Dec 2017, Bin.Cheng wrote: > > > On Mon, Dec 4, 2017 at 1:11 PM, Richard Biener wrote: > > > > > > I've noticed we perform FP reduction association without the required > > > checks for associative math. I've added > > >

[PING 2] Ability to remap file names in __FILE__, etc (PR other/70268)

Hi, I would like to again ping this patch: https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01451.html While the patch touches a few places, it is mostly reshuffling, generalizing, and fixing existing code. It also includes tests for the new functionality. Seeing that there is interest[1] in

  1   2   >