Re: [patch] New libstdc++ docs on testing and library versioning

On 08/04/2016 06:37 PM, Jonathan Wakely wrote: I've been working on some changes to the libstdc++ manual recently. A lot of the changes are just using DocBook markup with more semantic meaning (e.g. or instead of using for everything that should use a monospace font) but there are some

Re: [avr,RFC,patch] Add var attribute "absdata" to support LDS / STS on AVR_TINY.

On 08/03/2016 10:17 AM, Georg-Johann Lay wrote: Index: doc/extend.texi === --- doc/extend.texi (revision 238983) +++ doc/extend.texi (working copy) @@ -5957,6 +5957,25 @@ memory-mapped peripherals that may lie o volatile

Re: [PATCH 0/7, GCC, V8M] ARMv8-M Security Extensions

On 07/25/2016 07:17 AM, Andre Vieira (lists) wrote: [PATCH 0/7, GCC, V8M] ARMv8-M Security Extensions Hello, This is a respin of a previous patch series for ARMv8-M Security Extensions. In this version I have removed one patch, rebased the rest and changed some of them. This patch series aims

Set nonnull attribute to ptr_info_def based on VRP

Hi, This patch tries to add nonnull_p attribute to ptr_info_def. As it stands, range_info_def is bigger in size than ptr_info_def. Therefore adding nonnull_p should not change the size. I am setting this based on the VRP analysis. Right there is no uses for this. But the idea is, this can

Re: [PATCH, RELOAD] Don't assume subreg mem address is ok

On Mon, Aug 08, 2016 at 12:13:18PM +0930, Alan Modra wrote: > This patch fixes a case where reload blindly assumes a subreg mem > is OK if its address has been partially reloaded by > legitimize_reload_address. The change ought to be fairly obvious > considering that the analogous non-subreg case

[PATCH, RELOAD] Don't assume subreg mem address is ok

This patch fixes a case where reload blindly assumes a subreg mem is OK if its address has been partially reloaded by legitimize_reload_address. The change ought to be fairly obvious considering that the analogous non-subreg case only gives a win to address_reloaded[i] == 1. Bootstrapped and

[RFC] Use ccp mask and val to refine value_range

Hi All, I was experimenting with using ccp mask and value to refine value_ranges for SSA_NAME. Attached patch does this. This might be particularly useful for early_vrp. Bootstrap on x86_64-linux-gnu is OK. However, there are some test-cases (as shown below) are failing. Is this worth

Re: libgo patch committed: Change build procedure to use build tags

On Sun, Aug 7, 2016 at 8:18 AM, Matthias Klose wrote: > On 07.08.2016 14:14, Andreas Schwab wrote: >> That breaks ia64: >> >> ../../../libgo/go/internal/syscall/unix/getrandom_linux.go:29:5: error: >> reference to undefined name 'randomTrap' >> if randomTrap == 0 { >> ^

[RFC] [ipa bitwise cp] tree-ssa-ccp changes

Hi Richard, In the attached version, I tried to address your suggestions from: https://gcc.gnu.org/ml/gcc-patches/2016-08/msg00279.html In ccp_finalize we do: wide_int nonzero_bits = wide_int::from (val->mask, precision, UNSIGNED) | val->value;

Re: [RFC] ipa bitwise constant propagation

On 5 August 2016 at 18:06, Martin Jambor wrote: > Hi, Hi Martin, Thanks for the review. Please find my responses inline. > > generally speaking, the ipa-cp.c and ipa-cp.[hc] bits look reasonable, > but I have a few comments: > > On Thu, Aug 04, 2016 at 12:06:18PM +0530,

Re: [PATCH] gcov tool: Implement Hawick's algorithm for cycle detection, (PR gcov-profile/67992)

On 08/06/2016 12:31 PM, Jakub Jelinek wrote: On Fri, Aug 05, 2016 at 08:27:39AM -0700, Andrew Pinski wrote: On Fri, Aug 5, 2016 at 12:32 AM, Martin Liška wrote: On 08/05/2016 09:30 AM, Martin Liška wrote: Hi. Sorry for the mistake with the enum, that was silly ;) New patch

Re: backward threading heuristics tweek

On Mon, Jun 6, 2016 at 3:19 AM, Jan Hubicka wrote: > Hi, > while looking into profile mismatches introduced by the backward threading > pass > I noticed that the heuristics seems quite simplistics. First it should be > profile sensitive and disallow duplication when optimizing

Re: libgo patch committed: Change build procedure to use build tags

On 07.08.2016 14:14, Andreas Schwab wrote: > That breaks ia64: > > ../../../libgo/go/internal/syscall/unix/getrandom_linux.go:29:5: error: > reference to undefined name 'randomTrap' > if randomTrap == 0 { > ^ > ../../../libgo/go/internal/syscall/unix/getrandom_linux.go:38:34: error: >

Re: [Fortran, Patch, PR72698, v1] [5/6/7 Regression] ICE in lhd_incomplete_type_error, at langhooks.c:205

To prevent further confusion: The patch-file pr72698_1.patch is for trunk and the gcc-6-branch, the pr72698_v5_1.patch is for gcc-5-branch. Sorry for not pointing that out immediately. - Andre On Sun, 7 Aug 2016 13:52:34 +0200 Andre Vehreschild wrote: > Hi all, > > attached

[Fortran, patch, pr71936, v1] [6/7 Regression] ICE in wide_int_to_tree, at tree.c:1487

Hi all, attached patch fixes the ICE by ensuring that when the SOURCE=/MOLD= expression is an array-valued function call with no ref, the ref of object to allocate is taken. The array properties nevertheless are taken from the function's result. Bootstraps and regtests ok on

Re: libgo patch committed: Change build procedure to use build tags

That breaks ia64: ../../../libgo/go/internal/syscall/unix/getrandom_linux.go:29:5: error: reference to undefined name 'randomTrap' if randomTrap == 0 { ^ ../../../libgo/go/internal/syscall/unix/getrandom_linux.go:38:34: error: reference to undefined name 'randomTrap' r1, _, errno :=

[Fortran, Patch, PR72698, v1] [5/6/7 Regression] ICE in lhd_incomplete_type_error, at langhooks.c:205

Hi all, attached patch fixes the ICE caused by a zero-sized string. Assigning that string to a temporary variable obviously did not work out. The patch fixes this by checking for zero-sized strings in SOURCE= and not producing the code to assign "nothing" to the temporary variable and later to

Re: [PATCH] Allow relayout_decl on FIELD_DECLs (PR c/72816)

On August 6, 2016 9:09:08 PM GMT+02:00, Jakub Jelinek wrote: >Hi! > >As the testcase shows, the C FE can call relayout_decl even on >FIELD_DECLs >in certain cases. Trying to call only layout_decl on FIELD_DECL and >relayout_decl on other decls would be insufficient, we'd need