Re: [PATCH][C++] Fix PR71694, store data race with tail-padding

On December 19, 2016 11:25:49 PM GMT+01:00, Jeff Law wrote: >On 12/14/2016 03:44 AM, Richard Biener wrote: >> >> The following implements Jasons suggestion of using a langhook to >> return the size of an aggregate without tail padding that might >> be re-used when it is inherited

[PATCH] Add testcases to test builtin-expansion of memcmp and strncmp

This patch adds tests gcc.dg/memcmp-1.c and gcc.dg/strncmp-1.c that test builtin expansion of memcmp and strncmp for short strings and also varying alignment of one arg. The strncmp test checks that things work when one of the strings crosses a 4k boundary as well. I've included interested

Re: [PATCH] PR 78534 Change character length from int to size_t

On 12/19/16 11:33 AM, Janne Blomqvist wrote: On Mon, Dec 19, 2016 at 6:43 PM, Bob Deen wrote: Hi all... I never saw any followup on this...? It's one thing to break the ABI between the compiler and the gfortran library; those can generally be expected to be in sync.

Re: Reorganise machmode.h headers

On 11/16/2016 09:32 AM, Richard Sandiford wrote: Later patches will make machmode.h rely on wide-int.h and the new poly-int.h, so it needs to appear later in the coretypes.h include list. Previously machmode.h included insn-modes.h, which as well as the main mode enum contains configuration

Re: [PR tree-optimization/71691] Fix unswitching in presence of maybe-undef SSA_NAMEs (take 2)

On 12/16/2016 07:41 AM, Aldy Hernandez wrote: BTW, I don't understand why we don't have auto_bitmap's, as we already have auto_sbitmap's. I've implemented the former based on auto_sbitmap's code we already have. Trevor poked at it a bit. bitmaps are a bit more complex than sbitmaps in terms

Re: [PATCH] Fix bug in MEM parsing in patches 8a/8b

On Mon, 2016-12-19 at 15:10 -0700, Jeff Law wrote: > On 12/08/2016 01:39 PM, David Malcolm wrote: > > Testing the patch kit on i686 showed numerous failures of this > > assertion in set_mem_attributes_minus_bitpos in emit-rtl.c: > > > > 1821gcc_assert (!defattrs->offset_known_p); > > >

Re: [fortran, patch] Remove unused elements in array argument to set_options

On Mon, Dec 19, 2016 at 11:29:45PM +0100, FX wrote: > > Thinking out loud here. I wonder, however, if we want > > to future proof the library against changes to the > > options passed by having a few spare unused entried > > available. This of course only helps if a new option > > needs to be

Re: [PATCH] fix integer overflow bugs in gimple-ssa-sprintf.c (PR 78608)

On 12/14/2016 09:41 AM, Martin Sebor wrote: - if (i < 0) + if (HOST_WIDE_INT_MIN == i) nit. I think most folks would probably prefer this as if (i == HOST_WIDE_INT_MIN). HOST_WIDE_INT_MIN is a constant and when we can write an expression in either order variable OP const is the

Re: [fortran, patch] Remove unused elements in array argument to set_options

> Thinking out loud here. I wonder, however, if we want > to future proof the library against changes to the > options passed by having a few spare unused entried > available. This of course only helps if a new option > needs to be added. It does nothing for removal. That’s actually the way

Re: [PATCH][C++] Fix PR71694, store data race with tail-padding

On 12/14/2016 03:44 AM, Richard Biener wrote: The following implements Jasons suggestion of using a langhook to return the size of an aggregate without tail padding that might be re-used when it is inherited from. Using this langhook we can fix the size of the representative for the bitfield

Re: [PATCH] correct %g handling with unknown arguments in -fprintf-return-value (PR 78696)

On 12/12/2016 05:06 PM, Martin Sebor wrote: +/* The lower bound when precision isn't specified is 8 bytes + ("1.23456" since precision is taken to be 6). When precision + is zero, the lower bound is 1 byte (e.g., "1"). Otherwise, + when precision is greater than zero,

RE: [PATCH, testsuite] MIPS: Relax instruction order check in msa-builtins.c.

> -Original Message- > From: Toma Tabacu [mailto:toma.tab...@imgtec.com] > Sent: Thursday, December 15, 2016 9:51 AM > To: gcc-patches@gcc.gnu.org > Cc: Matthew Fortune ; Moore, > Catherine > Subject: [PATCH, testsuite] MIPS: Relax

Re: [fortran, patch] Remove unused elements in array argument to set_options

On Mon, Dec 19, 2016 at 10:47:09PM +0100, FX wrote: > For ABI compatibility, we kept some unused elements in the array argument to > _gfortran_set_options (options that we have removed). With the current ABI > breakage, we might as well remove those. > > Bootstrapped and regtested on

Re: [PATCH] Fix bug in MEM parsing in patches 8a/8b

On 12/08/2016 01:39 PM, David Malcolm wrote: Testing the patch kit on i686 showed numerous failures of this assertion in set_mem_attributes_minus_bitpos in emit-rtl.c: 1821gcc_assert (!defattrs->offset_known_p); when expanding "main" in the rtl.exp test files, after parsing an

Re: [PATCH] fix powerpc64le bootstrap failure caused by r243661 (PR 78817)

On 12/19/2016 01:09 PM, Martin Sebor wrote: By moving the warning earlier, we'll still warn for the most cases, but won't warn in the more convoluted cases. We can perhaps work on it further in GCC 8. If we keep it as is, I think most users will just -Wno-nonnull as soon as they run into some

[fortran, patch] Remove unused elements in array argument to set_options

For ABI compatibility, we kept some unused elements in the array argument to _gfortran_set_options (options that we have removed). With the current ABI breakage, we might as well remove those. Bootstrapped and regtested on x86_64-apple-darwin16.3.0 OK to commit? FX set_options.ChangeLog

Re: [PATCH] [PR rtl-optimization/65618] Fix MIPS ADA bootstrap failure

On 12/19/2016 08:44 AM, James Cowgill wrote: Hi, This patch fixes PR 65618 where ADA cannot be bootstrapped natively on mips due to a bootstrap comparison failure. The PR is currently in the target component, but should be in the rtl-optimization component. The underlying bug is in

Re: [PATCH] detect null sprintf pointers (PR 78519)

On Mon, Dec 19, 2016 at 01:24:34PM -0700, Jeff Law wrote: > > PR middle-end/78519 - missing warning for sprintf %s with null pointer > > > > gcc/ChangeLog: > > > > PR middle-end/78519 > > * gimple-ssa-sprintf.c (format_string): Handle null pointers. > > (format_directive): Diagnose

[committed] print_rtx_function: update example in comment

The patch updates the example dump in the comment for print_rtx_function to reflect various changes: - r241593: addition of insn UIDs - r241908: removal of trailing "(nil)" and other default values - r242023: addition of "param" directives - r243798: change of format of regnos in non-virtual

Re: [PATCH][GCC][PATCHv3] Improve fpclassify w.r.t IEEE like numbers in GIMPLE.

On 12/15/2016 03:14 AM, Tamar Christina wrote: On a high level, presumably there's no real value in keeping the old code to "fold" fpclassify. By exposing those operations as integer logicals for the fast path, if the FP value becomes a constant during the optimization pipeline we'll see the

[PATCH, i386] Add *popcounthi2_1 insn and splitter

Hello! This patch just adds missing popcounthi2 insn and splitter to enable POPCNTW generation from _builtin_popcount builtin with zero-extended unsigned short argument. 2016-12-19 Uros Bizjak * config/i386/i386.md (*popcounthi2_1): New insn_and_split pattern.

[PATCH] Add "__RTL" to cc1 (v7)

This is the final part of the RTL "frontend" patch kit, implemented as a special case for functions marked with __RTL within the C frontend. Successfully bootstrapped on x86_64-pc-linux-gnu on top of the rest of the RTL frontend patch kit. OK for trunk? Changed in v7: - remove i?86-*-* from

Re: [PATCH] detect null sprintf pointers (PR 78519)

On 12/14/2016 09:21 PM, Martin Sebor wrote: I suppose setting a range seemed better than giving up. Then again, since with this patch GCC will warn on null %s pointers there may not be much point in trying to see if there's also some other problem after that, except perhaps in code that

Re: [PATCH] Optimiza aggregate a = b = c = {} (PR c/78408, take 2)

On 12/16/2016 05:50 AM, Richard Biener wrote: + gimple *defstmt = SSA_NAME_DEF_STMT (vuse); + tree src2 = NULL_TREE, len2 = NULL_TREE; + HOST_WIDE_INT offset, offset2; + tree val = integer_zero_node; + if (gimple_store_p (defstmt) + && gimple_assign_single_p (defstmt) + &&

[doc, committed] CPP manual cleanup, part 1

I've checked in this patch to do some initial cleanup of bit-rotten content in the CPP manual. I've rewritten some passages that made it sound like C99 support is a brand-new thing, and removed text that describes how the preprocessor used to work in ancient versions of GCC. This is all

Re: [PATCH] fix powerpc64le bootstrap failure caused by r243661 (PR 78817)

By moving the warning earlier, we'll still warn for the most cases, but won't warn in the more convoluted cases. We can perhaps work on it further in GCC 8. If we keep it as is, I think most users will just -Wno-nonnull as soon as they run into some warning that will be hard to figure out what

Re: [PATCH] fix powerpc64le bootstrap failure caused by r243661 (PR 78817)

On 12/16/2016 10:10 AM, Martin Sebor wrote: On 12/16/2016 09:46 AM, Jakub Jelinek wrote: On Fri, Dec 16, 2016 at 09:36:25AM -0700, Martin Sebor wrote: It does for me with an allmodconf. At -O2 I get three warnings, and at -O3 I get two additional warnings. Now these additional ones happen way

Re: [PATCH] fix powerpc64le bootstrap failure caused by r243661 (PR 78817)

On Mon, Dec 19, 2016 at 12:50:00PM -0700, Jeff Law wrote: > > Unrelated to where the warning is issued, it might be a good idea to use > > %K to emit it with inlining stack, otherwise figuring out why it warns > > will be harder than needed. > I would think that would apply to any warning

Re: [PATCH] fix powerpc64le bootstrap failure caused by r243661 (PR 78817)

On 12/19/2016 12:12 PM, Jakub Jelinek wrote: On Mon, Dec 19, 2016 at 07:58:54PM +0100, Jakub Jelinek wrote: On Mon, Dec 19, 2016 at 11:54:06AM -0700, Jeff Law wrote: I don't claim it can't be improved but it seems pretty good as it is already. Among the 6 instances it's found in GCC three

Re: [PATCH] fix powerpc64le bootstrap failure caused by r243661 (PR 78817)

On 12/19/2016 11:56 AM, Jakub Jelinek wrote: On Mon, Dec 19, 2016 at 11:46:24AM -0700, Jeff Law wrote: But I don't see that as inherently blocking this patch. It's pointing out a bad API interface. It's no different than when I added teh NULL pointer dereference warnings a while ago -- we had

Re: [PATCH] PR 78534 Change character length from int to size_t

On Mon, Dec 19, 2016 at 6:43 PM, Bob Deen wrote: > Hi all... > > I never saw any followup on this...? > > It's one thing to break the ABI between the compiler and the gfortran > library; those can generally be expected to be in sync. It's another to > break the ABI between

Re: [PATCH] fix powerpc64le bootstrap failure caused by r243661 (PR 78817)

On Mon, Dec 19, 2016 at 07:58:54PM +0100, Jakub Jelinek wrote: > On Mon, Dec 19, 2016 at 11:54:06AM -0700, Jeff Law wrote: > > > > I don't claim it can't be improved but it seems pretty good as > > > > it is already. Among the 6 instances it's found in GCC three > > > > look like real bugs. > > >

Re: [PATCH] fix powerpc64le bootstrap failure caused by r243661 (PR 78817)

On Mon, Dec 19, 2016 at 11:54:06AM -0700, Jeff Law wrote: > > > I don't claim it can't be improved but it seems pretty good as > > > it is already. Among the 6 instances it's found in GCC three > > > look like real bugs. > > > > None look like real bugs to me. > But is the warning rate so high

Re: [PATCH] fix powerpc64le bootstrap failure caused by r243661 (PR 78817)

On Mon, Dec 19, 2016 at 11:46:24AM -0700, Jeff Law wrote: > But I don't see that as inherently blocking this patch. It's pointing out a > bad API interface. It's no different than when I added teh NULL pointer > dereference warnings a while ago -- we had the exact same kinds of problems. > >

Re: [PATCH] fix powerpc64le bootstrap failure caused by r243661 (PR 78817)

On 12/16/2016 09:46 AM, Jakub Jelinek wrote: On Fri, Dec 16, 2016 at 09:36:25AM -0700, Martin Sebor wrote: It does for me with an allmodconf. At -O2 I get three warnings, and at -O3 I get two additional warnings. Now these additional ones happen way too deep into the pipeline to be reliable.

Re: [gimplefe] reject invalid pass name in startwith

The message passed to error_at should not end in \n; the diagnostics machinery deals with inserting the newline. -- Joseph S. Myers jos...@codesourcery.com

Re: [PATCH] fix powerpc64le bootstrap failure caused by r243661 (PR 78817)

On 12/19/2016 11:30 AM, Jakub Jelinek wrote: On Mon, Dec 19, 2016 at 10:52:13AM -0700, Jeff Law wrote: No, it highlights that the warning is done in a wrong place where it suffers from too many false positives. I don't inherently see this as generating "too many false positives". And as Martin

Re: [PATCH] fix powerpc64le bootstrap failure caused by r243661 (PR 78817)

On 12/19/2016 11:00 AM, Martin Sebor wrote: On 12/19/2016 10:31 AM, Jeff Law wrote: On 12/17/2016 02:55 PM, Martin Sebor wrote: On 12/17/2016 01:01 PM, Markus Trippelsdorf wrote: I agree that these warnings should probably not be issued, though it's interesting to see where they come from.

Re: [PATCH] fix powerpc64le bootstrap failure caused by r243661 (PR 78817)

On Mon, Dec 19, 2016 at 10:52:13AM -0700, Jeff Law wrote: > > No, it highlights that the warning is done in a wrong place where it suffers > > from too many false positives. > I don't inherently see this as generating "too many false positives". And as > Martin says, the warning works with

Re: [PATCH] PR 78534 Change character length from int to size_t

On Mon, Dec 19, 2016 at 08:43:01AM -0800, Bob Deen wrote: > > It's one thing to break the ABI between the compiler and the gfortran > library; those can generally be expected to be in sync. It's another to > break the ABI between two *languages*, when there might be no such > expectation

Re: [PATCH] fix powerpc64le bootstrap failure caused by r243661 (PR 78817)

On Mon, Dec 19, 2016 at 10:52:13AM -0700, Jeff Law wrote: > > > > None look like real bugs to me. > > > > > > They do to me. There are calls in gengtype.c to a function decorated > > > with attribute nonnull (lbasename) that pass to it a pointer that's > > > potentially null. For example below.

[PATCH] Add support for Fuchsia (OS)

Ping? On 12/12/16 1:31 PM, Josh Conner wrote: On 12/10/16 3:26 AM, Richard Earnshaw wrote: On 08/12/16 22:55, Josh Conner wrote: +arm*-*-fuchsia*) + tm_file="${tm_file} fuchsia.h arm/fuchsia-elf.h glibc-stdint.h" + tmake_file="${tmake_file} arm/t-bpabi" + ;; This will

Re: [PATCH] fix powerpc64le bootstrap failure caused by r243661 (PR 78817)

On 12/19/2016 10:31 AM, Jeff Law wrote: On 12/17/2016 02:55 PM, Martin Sebor wrote: On 12/17/2016 01:01 PM, Markus Trippelsdorf wrote: I agree that these warnings should probably not be issued, though it's interesting to see where they come from. The calls are in the code emitted by GCC, are

libgo patch committed: Copy/rewrite cgo support code from Go 1.7 runtime

This patch copies the cgo support code from the Go 1.7 runtime to libgo. The cgo support in gccgo is rather different, so all the code in cgo_gccgo.go is gccgo-specific. The rest of the code is similar but slightly different. This drops _cgo_allocate, which was removed from the gc toolchain

[Patch] Turn -fexcess-precision=fast on when in -ffast-math

> On Thu, Dec 8, 2016 at 10:44 PM, Uros Bizjak wrote: > > Hello! > > > > Attached patch fixes fall-out from excess-precision improvements > > patch. As shown in the PR, the code throughout the compiler assumes > > FLAG_PRECISION_FAST when flag_unsafe_math_optimizations flag is

Re: [PATCH] libstdc++: Allow using without lock free atomic int

On 16/12/16 17:52 +, Jonathan Wakely wrote: On 09/11/16 23:26 +0200, Pauli wrote: Compiling programs using std::future for old arm processors fails. The problem is caused by preprocessor check for atomic lock free int. Future can be changed to work correctly without lock free atomics with

Re: [PATCH] fix powerpc64le bootstrap failure caused by r243661 (PR 78817)

On 12/16/2016 10:27 AM, Jakub Jelinek wrote: On Fri, Dec 16, 2016 at 10:10:00AM -0700, Martin Sebor wrote: No. The first call to sm_read_sector just doesn't exit. So it is warning about dead code. If the code is dead then GCC should eliminate it. With it eliminated There is (especially

Re: [PATCH, rs6000] Fold vector multiply built-ins in GIMPLE

Hi Will, On Mon, Dec 19, 2016 at 11:01:19AM -0600, Will Schmidt wrote: > This patch implements folding of the vector Multiply built-ins. > > As part of this patch, I have also marked variables in an existing > testcase (mult-even-odd-be-order.c) as volatile, to prevent their being > optimized

Re: [PATCH, rs6000] Fold vector subtract built-ins in GIMPLE

Hi, uh, Will, On Mon, Dec 19, 2016 at 11:01:08AM -0600, Will Schmidt wrote: > This patch implements folding of the vector subtract built-ins. This > follows the form used by Bill in his previous "Fold vector addition > built-ins in GIMPLE" patch. :-) > > Bootstrapped and tested on

Re: [PATCH] fix powerpc64le bootstrap failure caused by r243661 (PR 78817)

On 12/16/2016 01:17 PM, Jakub Jelinek wrote: On Fri, Dec 16, 2016 at 01:01:13PM -0700, Jeff Law wrote: Thanks. Reduced to something like: int foo (const char *name) { if (name) return 6; return __builtin_strlen (name); } This is warned about both with Martin's late warning and my after

Re: [PATCH] fix powerpc64le bootstrap failure caused by r243661 (PR 78817)

On 12/19/2016 02:42 AM, Jakub Jelinek wrote: The ubsan pass runs before IPA, so not sure how do you want to do that (and it is needed to run it early). One question is if we should perform path isolation in this case at all, since the branches to __builtin___ubsan_handle_nonnull_arg are with

Re: [PATCH] fix powerpc64le bootstrap failure caused by r243661 (PR 78817)

On 12/17/2016 02:55 PM, Martin Sebor wrote: On 12/17/2016 01:01 PM, Markus Trippelsdorf wrote: I agree that these warnings should probably not be issued, though it's interesting to see where they come from. The calls are in the code emitted by GCC, are reachable, and end up taking place with

Re: [PATCH] builtin expansion of strncmp for rs6000

Hi Aaron, On Mon, Dec 19, 2016 at 09:57:07AM -0600, Aaron Sawdey wrote: > Bootstrap/regtest in progress on ppc64le -mcpu=power8, ok for trunk if > results are clean? > +/* Generate alignment check and branch code to set up for > + strncmp when we don't have DI alignment. > + STRNCMP_LABEL

[PATCH] Externalize definition of create_tmp_reg_or_ssa_name

Hi, For some future rs6000 vector folding patches, I will be needing access to the create_tmp_reg_or_ssa_name() function in rs6000.c. Thus... Externalize the definition of create_tmp_reg_or_ssa_name for use in rs6000.c. The actual usage will show up in later patches. I'll note that I do not

Re: [PATCH] fix powerpc64le bootstrap failure caused by r243661 (PR 78817)

On 12/19/2016 09:51 AM, Jakub Jelinek wrote: On Mon, Dec 19, 2016 at 09:34:44AM -0700, Martin Sebor wrote: That would be just weird, have one behavior for selected subset of functions and another for the rest? Ugh. The selected set of the string built-ins are special -- they are known not to

Re: [PATCH][GCC][PATCHv3] Improve fpclassify w.r.t IEEE like numbers in GIMPLE.

Hi All, I've respun the patch with the feedback from Jeff and Joseph. > I think an integer mode should always exist - even in the case of TFmode > on 32-bit systems (32-bit sparc / s390, for example, use TFmode long > double for GNU/Linux, and it's supported as _Float128 and __float128 on >

Re: [PATCH, rs6000] Fold vector addition built-ins in GIMPLE

On Tue, 2016-12-06 at 09:59 +0100, Andreas Schwab wrote: > On Dez 05 2016, Bill Schmidt wrote: > > > What's your target triple? > > http://gcc.gnu.org/ml/gcc-testresults/2016-12/msg00471.html > > Andreas. > I *suspect* this is fixable with the addition of this

[PATCH, rs6000] Fold vector multiply built-ins in GIMPLE

Hi, This patch implements folding of the vector Multiply built-ins. As part of this patch, I have also marked variables in an existing testcase (mult-even-odd-be-order.c) as volatile, to prevent their being optimized out, which happens once this vector multiply folding was able to occur.

[PATCH, rs6000] Fold vector subtract built-ins in GIMPLE

Hi, This patch implements folding of the vector subtract built-ins. This follows the form used by Bill in his previous "Fold vector addition built-ins in GIMPLE" patch. :-) Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no regressions. Is this ok for trunk? Thanks, -Will

Re: [PATCH v2] Run tests only if the machine supports the instruction set.

On Mon, Dec 19, 2016 at 05:50:40PM +0100, Dominik Vogt wrote: > * config/s390/s390-c.c (s390_cpu_cpp_builtins_internal): Define > __S390_ARCH_LEVEL__. > gcc/testsuite/ChangeLog-setmem > > * gcc.target/s390/md/setmem_long-1.c: Use "runnable". > *

Re: [PATCH] S/390: Run md tests with -march=native instead of -march=z13.

On Tue, Dec 13, 2016 at 11:42:40AM +0100, Jakub Jelinek wrote: > On Tue, Dec 13, 2016 at 11:18:31AM +0100, Dominik Vogt wrote: > > > IMHO you want something like x86 avx_runtime effective target > > > (z13_runtime?), which would stand for running on z13 capable hw and > > > with z13 assembler

Re: [PATCH] Offer suggestions for misspelled attributes (PR c/70186)

Hi! On Mon, Dec 19, 2016 at 11:51:29AM -0500, David Malcolm wrote: > +/* Look for near matches for the scoped attribute with namespace NS and > + name NAME. > + Return the best matching attribute name, or NULL if none is found. > + If it returns non-NULL then *UNDERSCORES is written to,

Re: [PATCH] fix powerpc64le bootstrap failure caused by r243661 (PR 78817)

On Mon, Dec 19, 2016 at 09:34:44AM -0700, Martin Sebor wrote: > > That would be just weird, have one behavior for selected subset of functions > > and another for the rest? Ugh. > > The selected set of the string built-ins are special -- they are > known not to recover from null pointers so I

Re: [PATCH v2] Run tests only if the machine supports the instruction set.

On Mon, Dec 19, 2016 at 03:28:06PM +0100, Dominik Vogt wrote: > The attached patch is specific to S/390 but contains a small > common code change in gcc-dg.exp. It fixes the notorious problem > of md tests running on an S/390 machine that does not support the > z13 instruction set. > >

Re: [PATCH] fix powerpc64le bootstrap failure caused by r243661 (PR 78817)

On Mon, Dec 19, 2016 at 05:43:38PM +0100, Markus Trippelsdorf wrote: > On 2016.12.19 at 09:34 -0700, Martin Sebor wrote: > > On 12/19/2016 09:17 AM, Jakub Jelinek wrote: > > > Or apply the patch I've posted which doesn't suffer from this problem, > > > or revert the -Wnonnull changes and resolve

Re: [PATCH] fix powerpc64le bootstrap failure caused by r243661 (PR 78817)

On 2016.12.19 at 09:34 -0700, Martin Sebor wrote: > On 12/19/2016 09:17 AM, Jakub Jelinek wrote: > > Or apply the patch I've posted which doesn't suffer from this problem, > > or revert the -Wnonnull changes and resolve somehow in GCC 8. > > I would prefer your patch if it solves the problem. In

Re: [PATCH] PR 78534 Change character length from int to size_t

Hi all... I never saw any followup on this...? It's one thing to break the ABI between the compiler and the gfortran library; those can generally be expected to be in sync. It's another to break the ABI between two *languages*, when there might be no such expectation (especially if gcc does

[PATCH] Add x86_64-specific selftests for RTL function reader (v2)

Note to i386 maintainters: this patch is part of the RTL frontend. It adds selftests for verifying that the RTL dump reader works as expected, with a mixture of real and hand-written "dumps" to exercise various aspects of the loader. Many RTL dumps contain target-specific features (e.g. names of

Re: [PATCH] fix powerpc64le bootstrap failure caused by r243661 (PR 78817)

On 12/19/2016 09:17 AM, Jakub Jelinek wrote: On Mon, Dec 19, 2016 at 08:52:44AM -0700, Martin Sebor wrote: Another thing is that what the compiler does can very well just happen in some generic function that is called by the function that calls these strlen/strcpy etc. functions (fns with

Re: [v3 PATCH] Make the perfect-forwarding constructor of a two-element tuple sfinae away when the first argument is an allocator_arg.

On 19/12/16 14:34 +0200, Ville Voutilainen wrote: On 19 December 2016 at 12:19, Jonathan Wakely wrote: On 18/12/16 13:33 +0200, Ville Voutilainen wrote: Andrzej Krzemienski pointed this out in a discussion related to any and tags. Our two-element tuple specialization

Re: [PATCH] Remove unused libgfortran functions

On Mon, Dec 19, 2016 at 6:15 PM, FX wrote: >> Thanks, committed as r243799. > > I think something went wrong in your commit, as none of the “removed” files > were removed: https://gcc.gnu.org/viewvc/gcc?view=revision=243799 Indeed, thanks for bringing it up. Fixed by

Re: [libgfortran, patch] Rename numeric STOP runtime functions

> The patch you posted contains some apparently unrelated changes to > gfortran.map. Without those, Ok. Thanks for the reviews. Patches committed. Wiki updated. I’ll work tonight on some of the remaining items on the “abi cleanup” list. > As a minor cosmetic improvement, you could fold_convert

[PATCH] Offer suggestions for misspelled attributes (PR c/70186)

Our -Wattributes warnings can be rather cryptic. The following patch improves this warning: ../../src/pr70186.c:1:8: warning: 'visbility' attribute directive ignored [-Wattributes] struct S *foo __attribute__ ((visbility("hidden"))); ^ by adding suggestions when unrecognized

Re: [PATCH] fix powerpc64le bootstrap failure caused by r243661 (PR 78817)

On Mon, Dec 19, 2016 at 08:52:44AM -0700, Martin Sebor wrote: > > Another thing is that what the compiler does can very well just happen > > in some generic function that is called by the function that calls these > > strlen/strcpy etc. functions (fns with nonnull attribute). > > For the string

Re: [PATCH] Remove unused libgfortran functions

> Thanks, committed as r243799. I think something went wrong in your commit, as none of the “removed” files were removed: https://gcc.gnu.org/viewvc/gcc?view=revision=243799 FX

Re: [PATCH] Remove unused libgfortran functions

On Mon, Dec 19, 2016 at 12:59 PM, FX wrote: >> Yes, I agree (in general, though I was thinking of making the new one >> "GFORTRAN_7" to match the release series). > > Given that there will not be a 1-to-1 mapping of release series with major > ABI versions (hopefully!), I

Re: [libgfortran, patch] Remove runtime TRANSPOSE support functions

> No, this was actually part of r243799 which I just committed (after you Ok'd > it. :) ) Oops. Sorry!

Re: [PATCH] builtin expansion of strncmp for rs6000

On Fri, 2016-12-16 at 17:14 -0600, Segher Boessenkool wrote: > Please repost.  Thanks, Hi Segher, Thanks for the review. Attached is an updated patch that should address the issues you noted. Bootstrap/regtest in progress on ppc64le -mcpu=power8, ok for trunk if results are clean? Thanks,

Re: [PATCH] fix powerpc64le bootstrap failure caused by r243661 (PR 78817)

On 12/19/2016 02:42 AM, Jakub Jelinek wrote: On Sat, Dec 17, 2016 at 02:55:15PM -0700, Martin Sebor wrote: I agree that these warnings should probably not be issued, though it's interesting to see where they come from. The calls are in the code emitted by GCC, are reachable, and end up taking

Re: [libgfortran, patch] Remove runtime clz() and ctz() bit intrisic functions

On Mon, Dec 19, 2016 at 4:48 PM, FX wrote: > We implement the LEADZ and TRAILZ intrinsics in terms of the built-in clz() > and ctz() functions. Since these are not available for 128-bit integer types, > we used to have support functions _gfortran_clz128() and

Re: [libgfortran, patch] Remove iso_c_binding runtime functions

On Mon, Dec 19, 2016 at 3:54 PM, FX wrote: > The ISO_C_BINDING procedures have been emitted directly by the front-end > since 2012 (see for example > https://gcc.gnu.org/ml/fortran/2012-06/msg00152.html and > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32600). Having now

[PATCH] [PR rtl-optimization/65618] Fix MIPS ADA bootstrap failure

Hi, This patch fixes PR 65618 where ADA cannot be bootstrapped natively on mips due to a bootstrap comparison failure. The PR is currently in the target component, but should be in the rtl-optimization component. The underlying bug is in gcc/emit-rtl.c:try_split and is a result of the fix for PR

Re: [libgfortran, patch] Rename numeric STOP runtime functions

On Mon, Dec 19, 2016 at 4:13 PM, FX wrote: > When support for F2008 requirements on numeric STOP statements was > implemented, the old _gfortran_stop_numeric() runtime function was made > obsolete and a new _gfortran_stop_numeric_f08() function was created, which > is the

Re: [libgfortran, patch] Remove runtime TRANSPOSE support functions

On Mon, Dec 19, 2016 at 4:31 PM, FX wrote: > Since 2010, gfortran does not rely on library support functions to handle > TRANSPOSE, but instead emits code directly in the front-end > (https://gcc.gnu.org/ml/fortran/2010-09/msg00109.html). We have since kept > the various

Re: [PATCH] Remove unused libgfortran functions

On Mon, Dec 19, 2016 at 4:44 PM, FX wrote: >> Now that the libgfortran ABI major version has been bumped, we can >> remove functions for which the frontend nowadays generates inline >> code. >> >> This removes the malloc, free, exponent, fraction, nearest, rrspacing, >>

Re: [PATCH v3] add -fprolog-pad=N,M option

I'll consider myself agnostic as to whether this is a feature we want or need, so I'll just comment on some style questions. There's a fair amount of coding style violations, I'll point some of them out but please read the documents we have linked on this page:

Re: [PATCH][ARM] PR target/71436: Restrict *load_multiple pattern till after LRA

On Thu, Dec 15, 2016 at 10:00:14AM +, Richard Earnshaw (lists) wrote: > sorry, pasted the wrong bit of code. > > That should read when we generate: > > (insn 55 19 67 3 (parallel [ > (set (reg:SI 0 r0) > (mem/u/c:SI (reg/f:SI 147) [2 c+0 S4 A32])) >

[libgfortran, patch] Remove runtime clz() and ctz() bit intrisic functions

We implement the LEADZ and TRAILZ intrinsics in terms of the built-in clz() and ctz() functions. Since these are not available for 128-bit integer types, we used to have support functions _gfortran_clz128() and _gfortran_ctz128() in libgfortran. In 2010, I applied a patch to avoid this and emit

Re: [PATCH] Remove unused libgfortran functions

> Now that the libgfortran ABI major version has been bumped, we can > remove functions for which the frontend nowadays generates inline > code. > > This removes the malloc, free, exponent, fraction, nearest, rrspacing, > spacing, set_exponent and transpose intrinsics. Also the unused >

[libgfortran, patch] Remove runtime TRANSPOSE support functions

Since 2010, gfortran does not rely on library support functions to handle TRANSPOSE, but instead emits code directly in the front-end (https://gcc.gnu.org/ml/fortran/2010-09/msg00109.html). We have since kept the various _gfortran_transpose_* functions in libgfortran for ABI compatbility, but

Re: [PATCH 1/2] print-rtl.c: use '<' and '>' rather than % for pseudos in compact mode

On 12/16/2016 09:18 PM, David Malcolm wrote: The following patch implements the change for print-rtl.c. OK for trunk assuming it passes bootstrap? Yes. Bernd

Run tests only if the machine supports the instruction set.

The attached patch is specific to S/390 but contains a small common code change in gcc-dg.exp. It fixes the notorious problem of md tests running on an S/390 machine that does not support the z13 instruction set. Bootstrapped and tested on s390x biarch. Ciao Dominik ^_^ ^_^ -- Dominik Vogt

[libgfortran, patch] Rename numeric STOP runtime functions

When support for F2008 requirements on numeric STOP statements was implemented, the old _gfortran_stop_numeric() runtime function was made obsolete and a new _gfortran_stop_numeric_f08() function was created, which is the only one used in the front-end nowadays. The old _gfortran_stop_numeric()

[v3 PATCH] Implement LWG 2842, in_place_t check for optional::optional(U&&) should decay U.

Tested on Linux-x64. The perfect forwarder needs to sfinae out of the way of the in_place_t signature, and the in_place_t signature needs to check is_constructible. I also did some housekeeping to get rid of the int-pack constraints, because in case of empty packs it's unclear what a compiler is

[Ping^2][1/9][RFC][DWARF] Reserve three DW_OP numbers in vendor extension space

Jiong Wang writes: > Jiong Wang writes: > >> On 16/11/16 14:02, Jakub Jelinek wrote: >>> On Wed, Nov 16, 2016 at 02:54:56PM +0100, Mark Wielaard wrote: On Wed, 2016-11-16 at 10:00 +, Jiong Wang wrote: > The two operations DW_OP_AARCH64_paciasp and >

[libgfortran, patch] Remove iso_c_binding runtime functions

The ISO_C_BINDING procedures have been emitted directly by the front-end since 2012 (see for example https://gcc.gnu.org/ml/fortran/2012-06/msg00152.html and https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32600). Having now broken the library ABI, we can remove them from the library, where they

[committed, libgfortran]

In the case where CHMOD is called with a numeric mode, the current code assumes that “mode_t” corresponds to an unsigned int. This is true on linux/glibc, but not true on macOS (where mode_t is an unsigned short) and thus creates a warning and possibly a runtime error. This had been spotted

[PATCH] c++/78771 ICE with inheriting ctor

Jason, this patch fixes 78771, were an assert fires due to recursive instantiation of an inheriting ctor. Normally when a recursive instantiation is needed, we've already constructed and registered the declaration, so simply return it. For ctors though we need to construct the clones after

Re: [PATCH][ARM] Remove movdi_vfp_cortexa8

Ramana Radhakrishnan wrote: > On Wed, Dec 14, 2016 at 5:43 PM, Wilco Dijkstra > wrote: > > Yes, the reason to split the pattern was to introduce the '!' to discourage > > Neon->int moves on Cortex-A8 (https://patches.linaro.org/patch/541/). I am > > not removing the

RE: [PATCH,gcc/MIPS] Make loongson3a use fused madd.d

Hi Paul, Apologies for the delay in responding. > I get the copyright assignment, it's ok for commit. Thanks for going through copyright assignment, I can see you listed and also you have commit access now. Is the trunk build failure still present for you, if it is now resolved then please go

  1   2   >