Re: [PATCH] Fix PR81921

I'm seeing a build failure for s390x-linux-gnu that looks like it could be related to this change (build was OK at r251332, failed at r251358). https://sourceware.org/ml/libc-testresults/2017-q3/msg00329.html In file included from /scratch/jmyers/glibc-bot/src/gcc/libitm/libitm_i.h:39:0,

Re: [1/2] PR 78736: New warning -Wenum-conversion

On Tue, 11 Jul 2017, Prathamesh Kulkarni wrote: > On 13 June 2017 at 01:47, Joseph Myers wrote: > > This is OK with one fix: > > > >> +C ObjC Var(warn_enum_conversion) Init(0) Warning LangEnabledBy(C > >> Objc,Wall) > > > > I believe the LangEnabledBy arguments are

Re: [PATCH 1/2] Don't warn function alignment if warn_if_not_aligned_p is true

gt; attribute conflicts are at present diagnosed with -Wattributes). >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> It can be changed to warning. >>>>> >>>>> >>>>> >>>>> >>&g

Re: [PATCH 1/2] Don't warn function alignment if warn_if_not_aligned_p is true

On 08/25/2017 03:05 PM, H.J. Lu wrote: On Fri, Aug 25, 2017 at 1:14 PM, Martin Sebor wrote: On 08/25/2017 01:35 PM, H.J. Lu wrote: On Fri, Aug 25, 2017 at 12:24 PM, Martin Sebor wrote: On 08/25/2017 11:31 AM, H.J. Lu wrote: On Fri, Aug 25, 2017 at

Re: [PATCH 1/2] Don't warn function alignment if warn_if_not_aligned_p is true

On Fri, Aug 25, 2017 at 1:14 PM, Martin Sebor wrote: > On 08/25/2017 01:35 PM, H.J. Lu wrote: >> >> On Fri, Aug 25, 2017 at 12:24 PM, Martin Sebor wrote: >>> >>> On 08/25/2017 11:31 AM, H.J. Lu wrote: On Fri, Aug 25, 2017 at 10:15 AM, Martin

Re: 0006-Part-6.-Add-x86-tests-for-Intel-CET-implementation

On 08/01/2017 02:56 AM, Tsimbalist, Igor V wrote: > Part#6. Add x86 tests for Intel CET implementation. > > > 0006-Part-6.-Add-x86-tests-for-Intel-CET-implementation.patch > > > From e4a8227e83e8e9f3ddbaa97707f3d335009e0e77 Mon Sep 17 00:00:00 2001 > From: Igor Tsimbalist

Re: 0003-Part-3.-Add-tests-for-finstrument-control-flow-and-notrack attribute

On 08/01/2017 02:56 AM, Tsimbalist, Igor V wrote: > Part#3. Add tests for -finstrument-control-flow and notrack attribute. > > > 0003-Part-3.-Add-tests-for-finstrument-control-flow-and-n.patch > > > From 7869de8a0c0ec55c4e9240c2483fefee97bf34c9 Mon Sep 17 00:00:00 2001 > From: Igor Tsimbalist

Re: 0002-Part-2.-Document-finstrument-control-flow-and-notrack attribute

On 08/01/2017 02:56 AM, Tsimbalist, Igor V wrote: > Part#2. Document -finstrument-control-flow and notrack attribute. > > > 0002-Part-2.-Document-finstrument-control-flow-and-notrac.patch > > > From c3e45c80731672e74d638f787e80ba975279b9b9 Mon Sep 17 00:00:00 2001 > From: Igor Tsimbalist

Re: 0001-Part-1.-Add-generic-part-for-Intel-CET-enabling

On 08/01/2017 02:56 AM, Tsimbalist, Igor V wrote: > Part#1. Add generic part for Intel CET enabling. > > The spec is available at > > https://software.intel.com/sites/default/files/managed/4d/2a/control-flow-enforcement-technology-preview.pdf > > High-level design. > -- > > A

Re: 0001-Part-1.-Add-generic-part-for-Intel-CET-enabling

On 08/15/2017 07:42 AM, Richard Biener wrote: > > Please change the names to omit 'with_', thus just notrack > and GF_CALL_NOTRACK. > > I think 'notrack' is somewhat unspecific of a name, what prevented > you to use 'nocet'? I think we should look for something better than notrack. I think

Re: [PATCH 1/2] Don't warn function alignment if warn_if_not_aligned_p is true

On 08/25/2017 01:35 PM, H.J. Lu wrote: On Fri, Aug 25, 2017 at 12:24 PM, Martin Sebor wrote: On 08/25/2017 11:31 AM, H.J. Lu wrote: On Fri, Aug 25, 2017 at 10:15 AM, Martin Sebor wrote: On 08/21/2017 06:21 AM, H.J. Lu wrote: When

Re: [PATCH] istream_iterator: unexpected read in ctor

On Thu, Aug 24, 2017 at 4:55 AM, Petr Ovtchenkov wrote: > istream_iterator do unexpected read from stream > when initialized by istream&. > This is pretty much required by the specification. See the discussion in

Re: [RFC] [PATCH] Introduce configure flag --with-stage1-cflags.

On 07/31/2017 01:47 AM, Martin Liška wrote: > I would like to ping this. Input from other people will be appreciated ;) I think the thing to keep in mind here is that IIUC this only affects things when we've configured using the --with-stage1-cflags option. So questions about is -O1 more stable

Re: [PATCH 1/2] Don't warn function alignment if warn_if_not_aligned_p is true

On Fri, Aug 25, 2017 at 12:24 PM, Martin Sebor wrote: > On 08/25/2017 11:31 AM, H.J. Lu wrote: >> >> On Fri, Aug 25, 2017 at 10:15 AM, Martin Sebor wrote: >>> >>> On 08/21/2017 06:21 AM, H.J. Lu wrote: When warn_if_not_aligned_p is true, a

Re: [PATCH 1/2] Don't warn function alignment if warn_if_not_aligned_p is true

On 08/25/2017 11:31 AM, H.J. Lu wrote: On Fri, Aug 25, 2017 at 10:15 AM, Martin Sebor wrote: On 08/21/2017 06:21 AM, H.J. Lu wrote: When warn_if_not_aligned_p is true, a warning will be issued on function declaration later. There is no need to warn function alignment when

Re: [PATCHv2][PING][PR 59521] Respect __builtin_expect in switch statements

On 07/27/2017 09:21 PM, Yury Gribov wrote: > Hi all, > > This is a ping for > https://gcc.gnu.org/ml/gcc-patches/2017-07/msg01275.html . I've fixed > attachment type, hopefully it's easier to read now. > > This patch adds support for __builtin_expect in switch statements at > tree level (RTL

Re: [PATCH][GCC][AARCH64]Bad code-gen for structure/block/unaligned memory access

On Sun, Jul 2, 2017 at 11:17 PM, Tamar Christina wrote: > Hi All, > > Sorry I just realized I never actually sent the updated patch... > > So here it is :) > Are there any testcases? -- H.J.

Re: [PATCH][GCC][AARCH64]Bad code-gen for structure/block/unaligned memory access

On 07/03/2017 12:17 AM, Tamar Christina wrote: > Hi All, > > Sorry I just realized I never actually sent the updated patch... AFAICT this never got resolved. I'll let the aarch64 folks own those changes. I'm going to focus just on the small change to expr.c where you change the computation of

[PATCH] Fix fortran tests to not print out non-ascii characters

This is a minor patch for a minor problem, I will check it in as obvious if no one objects.  While looking at another issue I found that the gfortran.log file created by testing contains some non-ascii characters, this bothered me and caused some problems when grepping for things.  I tracked down

Re: Statement Frontier Notes, Location Views, and Inlined Entry Point Markers

On Aug 23, 2017, Richard Biener wrote: > Just curious if, for example, --with-build-config=bootstrap-lto > --enable-languages=c > --disable-multilib and make -j1 shows any difference in time and/or peak > memory > use (the interesting peak memory use is that of the

Re: [PATCH 2/2] [ARM] Add table of costs for AAarch32 addressing modes.

On Fri, Aug 25, 2017 at 10:43 AM, Charles Baylis wrote: > On 9 June 2017 at 15:13, Richard Earnshaw (lists) > wrote: >> On 21/02/17 16:54, charles.bay...@linaro.org wrote: >>> From: Charles Baylis >>> >>> This patch

Re: [PATCH 2/2] [ARM] Add table of costs for AAarch32 addressing modes.

On 9 June 2017 at 15:13, Richard Earnshaw (lists) wrote: > On 21/02/17 16:54, charles.bay...@linaro.org wrote: >> From: Charles Baylis >> >> This patch adds support for modelling the varying costs of >> different addressing modes. The generic

Re: [PATCH 1/2] [ARM] Refactor costs calculation for MEM.

On 9 June 2017 at 14:59, Richard Earnshaw (lists) wrote: > On 21/02/17 16:54, charles.bay...@linaro.org wrote: >> From: Charles Baylis >> >> This patch moves the calculation of costs for MEM into a >> separate function, and reforms the

Re: [PATCH] handle pathological anti-ranges in gimple_fold_builtin_memory_op (PR 81908)

Martin Sebor writes: >> Just a stylistic thing, but since the only use of "wone" is in >> the eq_p, it'd be simpler just to use "1". Also, the maximum >> value is better calculated as "wi::max_value (prec, SIGNED)". So: >> >> /* Compute the value of SSIZE_MAX, the largest

Re: [PATCH 1/2] Don't warn function alignment if warn_if_not_aligned_p is true

On Fri, Aug 25, 2017 at 10:15 AM, Martin Sebor wrote: > On 08/21/2017 06:21 AM, H.J. Lu wrote: >> >> When warn_if_not_aligned_p is true, a warning will be issued on function >> declaration later. There is no need to warn function alignment when >> warn_if_not_aligned_p is true.

Re: [PATCH 1/2] Don't warn function alignment if warn_if_not_aligned_p is true

On 08/21/2017 06:21 AM, H.J. Lu wrote: When warn_if_not_aligned_p is true, a warning will be issued on function declaration later. There is no need to warn function alignment when warn_if_not_aligned_p is true. OK for trunk? H.J. -- * c-attribs.c (common_handle_aligned_attribute):

Re: [77/77] Add a complex_mode class

On 07/13/2017 03:05 AM, Richard Sandiford wrote: > This patch adds another machine_mode wrapper for modes that are > known to be COMPLEX_MODE_P. There aren't yet many places that make > use of it, but that might change in future. > > 2017-07-13 Richard Sandiford

Re: Add a partial_integral_type_p helper function

On 08/18/2017 02:13 AM, Richard Sandiford wrote: This patch adds a partial_integral_type_p function, to go along with the full_integral_type_p added by the previous patch. Of the changes that didn't previously have an INTEGRAL_TYPE_P check: - the convert_to_integer_1 hunks are dominated by a

Re: [76/77] Add a scalar_mode_pod class

On 07/13/2017 03:05 AM, Richard Sandiford wrote: > This patch adds a scalar_mode_pod class and uses it to > replace the machine_mode in fixed_value. > > 2017-07-13 Richard Sandiford > Alan Hayward > David Sherwood

[PATCH] Fix fortran vector tests on powerpc and aarch64, PR tree-optimization/80925

My earlier patch to update tests and resolve PR tree-optimization/80925 did not include FORTRAN, just C and C++.  This patch makes the same changes as the earlier patches but for FORTRAN.  Tested on aarch64. OK to checkin? Steve Ellcey sell...@cavium.com Orginal patches/discussion is at:

Re: [74/77] Various small scalar_mode changes

On 07/13/2017 03:04 AM, Richard Sandiford wrote: > This patch uses scalar_mode in a few miscellaneous places: > > - Previous patches mean mode_to_vector can take a scalar_mode without > further changes. > > - Implicit promotion is limited to scalar types (affects promote_mode > and

Re: [75/77] Use scalar_mode in the AArch64 port

On 07/13/2017 03:04 AM, Richard Sandiford wrote: > Similar to the previous scalar_int_mode patch. > > 2017-07-13 Richard Sandiford > Alan Hayward > David Sherwood > > gcc/ > *

Re: [73/77] Pass scalar_mode to scalar_mode_supported_p

On 07/13/2017 03:04 AM, Richard Sandiford wrote: > This patch makes the preferred_simd_mode target hook take a scalar_mode > rather than a machine_mode. > > 2017-07-13 Richard Sandiford > Alan Hayward > David Sherwood

Re: [72/77] Pass scalar_mode to scalar_mode_supported_p

On 07/13/2017 03:04 AM, Richard Sandiford wrote: > This patch makes the scalar_mode_supported_p target hook take a > scalar_mode rather than a machine_mode. > > 2017-07-13 Richard Sandiford > Alan Hayward > David

Re: [71/77] Use opt_scalar_mode for mode iterators

On 07/13/2017 03:03 AM, Richard Sandiford wrote: > This patch uses opt_scalar_mode when iterating over scalar modes. > > 2017-07-13 Richard Sandiford > Alan Hayward > David Sherwood > > gcc/ >

Re: [PATCH] Fix file find utils and add unit tests (PR driver/81829).

On 08/18/2017 04:17 AM, Martin Liška wrote: On 08/15/2017 02:45 PM, Martin Liška wrote: Hi. As shown in the PR, remove_prefix function is written wrongly. It does not distinguish in between a node in linked list and pprefix->plist. So I decide to rewrite it. Apart from that, I identified

Re: [PATCH] handle pathological anti-ranges in gimple_fold_builtin_memory_op (PR 81908)

Just a stylistic thing, but since the only use of "wone" is in the eq_p, it'd be simpler just to use "1". Also, the maximum value is better calculated as "wi::max_value (prec, SIGNED)". So: /* Compute the value of SSIZE_MAX, the largest positive value that can be stored in ssize_t, the

Re: [pr 81982] wide-int.h change broke native arm-* gcc

On 25/08/17 14:27, Szabolcs Nagy wrote: > i don't see corresponding email thread in gcc-patches, but > since this commit: > https://gcc.gnu.org/viewcvs/gcc?view=revision=251260 > > i see arm-* native compiler miscompile libstdc++, > note that the cross compiler compiles it correctly. > > i guess

Re: [Patch][aarch64] Use IFUNCs to enable LSE instructions in libatomic on aarch64

On 07/08/17 21:44, Steve Ellcey wrote: > This patch uses the libatomic IFUNC infrastructure so that aarch64 > machines that support the LSE instructions can use them. Note that > aarch64 still isn't enabling IFUNC support by default though I have > submitted a patch to do that. You can enable

Re: Statement Frontier Notes, Location Views, and Inlined Entry Point Markers

On Aug 23, 2017, Richard Biener wrote: > On Wed, Aug 23, 2017 at 12:29 AM, Alexandre Oliva wrote: >> All debug options that support negation seem to have adopted this idiom; >> without it, the negated options end up misparsed as -g with an

Re: Statement Frontier Notes, Location Views, and Inlined Entry Point Markers

On Aug 23, 2017, Richard Biener wrote: >>> if they are not a problem up until here why care now? >> IIRC we do have a limit for VTA notes too, but there's a C++ testcase >> (g++.dg/tree-ssa/pr14703.C) that expands and inlines fibonacci template >> functions so deep,

[pr 81982] wide-int.h change broke native arm-* gcc

i don't see corresponding email thread in gcc-patches, but since this commit: https://gcc.gnu.org/viewcvs/gcc?view=revision=251260 i see arm-* native compiler miscompile libstdc++, note that the cross compiler compiles it correctly. i guess it can be some latent bug that got uncovered, but it is

Re: [PATCH v2] Simplify pow with constant

Jeff Law wrote: > Right.  exp is painful in glibc, but pow is *dramatically* more painful > and likely always will be. > > Siddhesh did some great work in bringing those costs down in glibc but > the more code we can reasonably shunt into exp instead of pow, the better. > > It's likely pow will

Re: c-family PATCH to improve -Wtautological-compare (PR c/81783)

Ping. On Wed, Aug 16, 2017 at 05:24:56PM +0200, Marek Polacek wrote: > On Wed, Aug 16, 2017 at 11:07:36AM -0400, David Malcolm wrote: > > On Wed, 2017-08-16 at 16:29 +0200, Marek Polacek wrote: > > > This patch improves -Wtautological-compare so that it also detects > > > bitwise comparisons

[C++ PATCH] METHOD_VEC sorting

While I intend to kill METHOD_VEC, I noticed its comparison function contemplated functions with NULL DECL_NAMEs. Those aren't a thing. applied to trunk. nathan -- Nathan Sidwell 2017-08-25 Nathan Sidwell * class.c (method_name_cmp, resort_method_name_cmp): Method names

[C++ PATCH] Find conv ops by name

Conversion operators squirrel the target type on their IDENTIFIER_TYPE, thus have to have distinct IDENTIFIER_NODEs. That doesn't work with find-by-name, and hence they currently have a unique slot in the METHOD_VEC -- yesterday's patch put them all on the same slot. This patch allows them

Re: [PATCH, GCC/ARM] Remove ARMv8-M code for D17-D31

Hi, I've now also added a couple more changes: * size to_clear_bitmap according to maxregno to be consistent with its use * use directly TARGET_HARD_FLOAT instead of clear_vfpregs Original message below (ChangeLog unchanged): Function cmse_nonsecure_entry_clear_before_return has code to deal

Re: [PATCH 0/2] backport c++ header fixes to gcc-5-branch

Szabolcs, Can you help get these back ports into gcc-5-branch? https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00478.html https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00477.html Thanks in advance. Jack On Mon, Aug 7, 2017 at 1:12 AM, Ryan Mounce wrote: > Fixes

Re: [PATCH] Enable libitm DLL build on Cygwin/Mingw

On 08/09/2017 01:02 PM, JonY wrote: > Fixes libtool calls in libitm. Patch OK for trunk? > > 2017-08-09 Jonathan Yong <10wa...@gmail.com> > > * configure.ac: Check libtool flags. > * Makefile.am: Use lt_host_flags. > * configure: Regenerated. > * Makefile.in:

[PATCH] libstdc++: test for copy_n/istreambuf_iterator

copy_n return result + n (i.e. increment OutputIterator n times) and increment InputIterator max(0, n - 1). This is issue 81857. See also https://cplusplus.github.io/LWG/issue2471 --- .../testsuite/25_algorithms/copy_n/81857.cc| 83 ++ 1 file changed, 83

Re: [PATCH] handle pathological anti-ranges in gimple_fold_builtin_memory_op (PR 81908)

Martin Sebor writes: > On 08/24/2017 08:03 AM, Richard Biener wrote: >> On Wed, Aug 23, 2017 at 9:42 PM, Martin Sebor wrote: >>> Bug 81908 is about a -Wstringop-overflow warning for a Fortran >>> test triggered by a recent VRP improvement. A simple test case

Re: [PATCH GCC][04/06]Add copying interface for dependence_info

On August 25, 2017 12:25:57 AM GMT+02:00, Jeff Law wrote: >On 08/14/2017 03:19 AM, Bin Cheng wrote: >> HI, >> This patch adds copying interface for dependence_info. The >methodology >> is we don't copy such information by default, and this interface >should >> be called

Re: [PATCH] handle pathological anti-ranges in gimple_fold_builtin_memory_op (PR 81908)

On August 24, 2017 11:52:41 PM GMT+02:00, Jeff Law wrote: >On 08/24/2017 09:03 AM, Martin Sebor wrote: >> On 08/24/2017 08:03 AM, Richard Biener wrote: >>> On Wed, Aug 23, 2017 at 9:42 PM, Martin Sebor >wrote: Bug 81908 is about a -Wstringop-overflow