Re: [PATCH] Ensure that dump calls are guarded with dump_enabled_p

On Sat, 10 Nov 2018, David Malcolm wrote: > On Mon, 2018-10-22 at 16:08 +0200, Richard Biener wrote: > > On Mon, 22 Oct 2018, David Malcolm wrote: > > > > > On Mon, 2018-10-22 at 15:56 +0200, Richard Biener wrote: > > > [...snip...] > > > > > > > This is what I finally applied for the original p

Re: [RFC] support --with-multilib-list=@/path/name

On Nov 9, 2018, "Richard Earnshaw (lists)" wrote: > - I'm not sure if we really want to allow combinations of an arbitrary > multilib config with the builtin configurations. Those are tricky > enough to get right as it is, and requests to support additional libs as > well as those with changes

Re: [PATCH][RFC] Come up with -flive-patching master option.

On 11/12/18 3:28 AM, Qing Zhao wrote: > Hi, > > >> On Nov 10, 2018, at 2:51 AM, Martin Liška wrote: >> >> On 11/9/18 6:43 PM, Qing Zhao wrote: >>> Hi, Martin, >>> >>> thanks a lot for the previous two new options for live-patching. >>> >>> >>> I have two more questions below: >> >> Hello. >> >>

Re: Stack alignment on Darwin (PR78444)

Appending Uros’ comments from a second thread on Stack alignment. Note that as per the new analysis in pr78444 this can affect other x86-64 targets too. > On 15 Aug 2018, at 16:57, H.J. Lu wrote: > > On Wed, Aug 15, 2018 at 8:41 AM, Iain Sandoe wrote: >> Hi HJ, >> >> I am trying to track dow

[wwwdocs] Add powerpcspe line to backends.html

Now that the port has been spun off from the rs6000 port. Applied. -- Eric BotcazouIndex: htdocs/backends.html === RCS file: /cvs/gcc/wwwdocs/htdocs/backends.html,v retrieving revision 1.81 diff -u -r1.81 backends.html --- htdocs/ba

Re: [PATCH] Remove unreachable nodes before IPA profile pass (PR ipa/87706).

On 11/8/18 12:46 PM, Jan Hubicka wrote: >> On Thu, Nov 8, 2018 at 12:39 PM Martin Liška wrote: >>> >>> On 11/8/18 12:19 PM, Jan Hubicka wrote: > Hi. > > In order to fix the warnings mentioned in the PR, we need > to run remove_unreachable_nodes after early tree passes. That's >

Re: [PATCH][RFC] Come up with -flive-patching master option.

On 11/10/18 6:03 PM, Jan Hubicka wrote: >> On 11/9/18 6:43 PM, Qing Zhao wrote: >>> Hi, Martin, >>> >>> thanks a lot for the previous two new options for live-patching. >>> >>> >>> I have two more questions below: >> >> Hello. >> >>> >>> 1. do we still need new options to disable the following: >>

Re: [PATCH] Come up with htab_hash_string_vptr and use string-specific if possible.

On 11/9/18 2:28 PM, Michael Matz wrote: > Hi, > > On Thu, 8 Nov 2018, Martin Liška wrote: > >>> That seems better. But still, why declare this in system.h? It seems >>> hash-table.h seems more appropriate. >> >> I need to declare it before I'll poison it. As system.h is included very >> early

Re: [PATCH] minor FDO profile related fixes

On 11/8/18 1:49 AM, Indu Bhagat wrote: > I have been looking at -fdump-ipa-profile dump with an intention to sanitize > bits of information so that one may use it to judge the "quality of a profile" > in FDO. > > The overall question I want to address is - are there ways to know which > functions 

Re: cleanups and unification of value_range dumping code

I have rebased my value_range dumping patch after your value_range_base changes. I know you are not a fan of the gimple-pretty-print.c chunk, but I still think having one set of dumping code is preferable to catering to possible GC corruption while debugging. If you're strongly opposed (as,

Re: [PATCH] Add value_range_base (w/o equivs)

On 11/11/18 3:53 AM, Richard Biener wrote: On Fri, 9 Nov 2018, Aldy Hernandez wrote: On 11/9/18 9:19 AM, Richard Biener wrote: This adds value_range_base, a base class of class value_range with all members but the m_equiv one. First of all, thanks so much for doing this! I have looked

[PATCH] Add C++ runtime support for new 128-bit long double format

This adds support for the new 128-bit long double format on powerpc64, see https://fedoraproject.org/wiki/Changes/PPC64LE_Float128_Transition for more details. Most of the required changes are to the locale facets that parse and print long doubles, as used by iostreams for reading/writing numbers

Re: [PATCH] Add value_range_base (w/o equivs)

On Mon, 12 Nov 2018, Aldy Hernandez wrote: > > > On 11/11/18 3:53 AM, Richard Biener wrote: > > On Fri, 9 Nov 2018, Aldy Hernandez wrote: > > > > > On 11/9/18 9:19 AM, Richard Biener wrote: > > > > > > > > This adds value_range_base, a base class of class value_range > > > > with all members b

[PATCH] Change set_value_range_to_[non]null to not preserve equivs

This is a semantic change but AFAICS it shouldn't result in any pessimization. The behavior of the API is non-obvious. Bootstrapped and tested on x86_64-unknown-linux-gnu, applied. Richard. 2018-11-12 Richard Biener * tree-vrp.c (set_value_range_to_nonnull): Clear equiv.

Re: [PATCH] Add value_range_base (w/o equivs)

Ug ok. On Mon, Nov 12, 2018, 12:10 Richard Biener On Mon, 12 Nov 2018, Aldy Hernandez wrote: > > > > > > > On 11/11/18 3:53 AM, Richard Biener wrote: > > > On Fri, 9 Nov 2018, Aldy Hernandez wrote: > > > > > > > On 11/9/18 9:19 AM, Richard Biener wrote: > > > > > > > > > > This adds value_ran

[PATCH] Move more stuff to value-range-base

The simple stuff. I have some more stuff queued. Bootstrapped on x86_64-unknown-linux-gnu, testing in progress. Richard. 2018-11-12 Richard Biener * tree-vrp.h (value_range_base::symbolic_p, value_range_base::constant_p, value_range_base::zero_p, value_range_base::

[PATCH 0/3] [ARC] Glibc required patches

Hi Andrew, The attached three patches are required to reduce/enable glibc builds. Although not all of them are glibc related they are found when porting this library to ARC. OK to apply? Claudiu Claudiu Zissulescu (3): [ARC] Update EH code. [ARC] Do not emit ZOL in the presence of text jump

[PATCH 2/3] [ARC] Do not emit ZOL in the presence of text jump tables.

Avoid emitting lp instruction when in its ZOL body we find a jump table data in text section. gcc/ -xx-xx Claudiu Zissulescu * config/arc/arc.c (hwloop_optimize): Bailout when detecting a jump table data in the text section. --- gcc/config/arc/arc.c | 12 +++- 1 fi

[PATCH 1/3] [ARC] Update EH code.

Our ABI says the blink is pushed first on stack followed by an unknown number of register saves, and finally by fp. Hence we cannot use the EH_RETURN_ADDRESS macro as the stack is not finalized at that moment. The alternative is to use the eh_return pattern and to initialize all the bits after reg

[PATCH 3/3] [ARC] Add support for profiling in glibc.

Use PROFILE_HOOK to add mcount library calls in each toolchain. gcc/ -xx-xx Claudiu Zissulescu * config/arc/arc.h (FUNCTION_PROFILER): Redefine to empty. * config/arc/elf.h (PROFILE_HOOK): Define. * config/arc/linux.h (PROFILE_HOOK): Likewise. --- gcc/config/arc/ar

[RS6000] Use config/linux.h for powerpc*-*-linux*

Using the macros in config/linux.h rather than duplicating them helps stop future bitrot, and repairs existing bitrot (4 choices for libc in linux.h, fewer in the rs6000 files not that it matters much). Also fixes the fact that __gnu_linux__ was always defined rather than just when glibc was the l

Delete !HAVE_LD_PIE variants of startfile/endfile specs

This patch is a small cleanup. The HAVE_LD_PIE variant doesn't contain anything that will break linking when !HAVE_LD_PIE that isn't already broken if you choose to build PIEs with a linker that doesn't support PIE. All this HAVE_LD_PIE protects is the choice of different crt files, which is more

[PATCH] [ARC] Cleanup, fix and set LRA default.

From: claziss Hi Andrew, This is a patch which fixes and sets LRA by default. OK to apply? Claudiu Commit message LP_COUNT register cannot be freely allocated by the compiler as it size, and/or content may change depending on the ARC hardware configuration. Thus, make this register

Allow target to override gnu-user.h crti and crtn

Also give target access to the gnu-user.h LINK_GCC_C_SEQUENCE_SPEC. In preparation for using gnu-user.h in rs6000/. Bootstrapped etc. powerpc64le-linux. OK? * config/gnu-user.h (GNU_USER_TARGET_CRTI): Define. (GNU_USER_TARGET_STARTFILE_SPEC): Use it here. (GNU_USER_TARGET

Re: [PATCH 4/6] [ARC] Add peephole rules to combine store/loads into double store/loads

PING. On Wed, 2018-10-31 at 10:33 +0200, claz...@gmail.com wrote: > Thank you for your review. Please find attached a new respin patch > with > your feedback in. > > Please let me know if it is ok, > Claudiu

rs6000/sysv4.h using gnu-user.h

This patch removes some duplication in rs6000/sysv4.h of macros found in gnu-user.h that we want for linux. Including gnu-user.h will mean powerpc doesn't miss updates to that file. Requires https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00917.html and https://gcc.gnu.org/ml/gcc-patches/2018-11/ms

Re: [PATCH] [ARC] Cleanup, fix and set LRA default.

> This is a patch which fixes and sets LRA by default. You'll need to update htdocs/backends.html of wwwdocs once this is done: https://gcc.gnu.org/backends.html -- Eric Botcazou

Re: [C++ Patch] Fix two grokdeclarator locations

Hi again, On 08/11/18 10:26, Paolo Carlini wrote: Hi, two additional grokdeclarator locations that we can easily fix by using declarator->id_loc. Slightly more interesting, testing revealed a latent issue in the make_id_declarator uses: cp_parser_member_declaration wasn't setting declarator-

[RS6000] PowerPC -mcpu=native support

The -mcpu=native support has bit-rotted a little, in particular the fallback when the native cpu couldn't be determined. This patch fixes the bit-rot and reorganizes ASM_CPU_SPEC so that it should be a little easier to keep the -mcpu=native data up to date. The patch also changes the fix for PR63

[PowerPC] libgcc cfi

There are a few places in libgcc assembly where we don't emit call frame information for functions, potentially breaking unwinding from asynchronous signal handlers. This patch fixes most. Although I patch tramp.S there is no attempt made to provide CFI for the actual trampoline on the stack. Do

[PATCH][DOCS] Fix documentation of __builtin_cpu_is and __builtin_cpu_supports for x86.

Hi. The patch is adding missing values for aforementioned built-ins. Ready for trunk? Thanks, Martin gcc/ChangeLog: 2018-11-12 Martin Liska * doc/extend.texi: Add missing values for __builtin_cpu_is and __builtin_cpu_supports for x86 target. --- gcc/doc/extend.texi | 100 ++

[RS6000] Don't pass -many to the assembler

I'd like to remove -many from the options passed by default to the assembler, on the grounds that a gcc bug in instruction selection (eg. emitting a power9 insn for -mcpu=power8) is better found at assembly time than run time. This might annoy people for a while fixing user asm that we didn't diag

Re: [PATCH] combine: Do not combine moves from hard registers

On 11/08/2018 08:34 PM, Segher Boessenkool wrote: > On Thu, Nov 08, 2018 at 03:44:44PM +, Sam Tebbs wrote: >> Does your patch fix the incorrect generation of "scvtf s1, s1"? I was >> looking at the issue as well and don't want to do any overlapping work. > I don't know. Well, there are no in

[mcore] Remove duplicate preprocessor definition

The same definition, with a comment, is present a few lines above. Applied on the mainline as obvious. 2018-11-12 Eric Botcazou * config/mcore/mcore.h (WORD_REGISTER_OPERATIONS): Remove duplicate. -- Eric BotcazouIndex: config/mcore/mcore.h =

[PR81878]: fix --disable-bootstrap --enable-languages=ada, and cross-back gnattools build

gnattools build machinery uses just-build xgcc and xg++ as $(CC) and $(CXX) in native builds. However, if C and C++ languages are not enabled, it won't find them. So, enable C and C++ if Ada is enabled. Most of the time, this is probably no big deal: C is always enabled anyway, and C++ is already

Re: [PATCH 20/25] GCN libgcc.

On 09/11/2018 18:48, Jeff Law wrote: diff --git a/libgcc/Makefile.in b/libgcc/Makefile.in index 0c5b264..6f68257 100644 --- a/libgcc/Makefile.in +++ b/libgcc/Makefile.in @@ -429,9 +429,11 @@ LIB2ADD += enable-execute-stack.c # While emutls.c has nothing to do with EH, it is in LIB2ADDEH* # in

[PATCH] Do not allow -mabi=ms and -fsanitize={,kernel-}address (PR sanitizer/87930).

Hi. The patch reject usage of the mentioned options. Ready for trunk? Thanks, Martin gcc/ChangeLog: 2018-11-12 Martin Liska PR sanitizer/87930 * config/i386/i386.c (ix86_option_override_internal): Error about usage -mabi=ms and -fsanitize={,kernel-}address. --- gcc/

Re: [PR81878]: fix --disable-bootstrap --enable-languages=ada, and cross-back gnattools build

> I've considered sourcing ada/config-lang.in from within > gnattools/configure, and testing lang_requires as set by it, so as to > avoid a duplication of tests that ought to remain in sync, but decided > it would be too fragile, as ada/config-lang.in does not expect srcdir > to refer to gnattools.

Re: [PATCH] Do not allow -mabi=ms and -fsanitize={,kernel-}address (PR sanitizer/87930).

On Mon, Nov 12, 2018 at 01:03:41PM +0100, Martin Liška wrote: > The patch reject usage of the mentioned options. > > Ready for trunk? > Thanks, > Martin > > gcc/ChangeLog: > > 2018-11-12 Martin Liska > > PR sanitizer/87930 > * config/i386/i386.c (ix86_option_override_internal): E

Re: [GCC][AArch64] [middle-end][docs] Document the xorsign optab

Hi Sandra, > > Ok for trunk? > > > > +@cindex @code{xorsign@var{m}3} instruction pattern > > +@item @samp{xorsign@var{m}3} > > +Target suppports an efficient expansion of x * copysign (1.0, y) > > +as xorsign (x, y). Store a value with the magnitude of operand 1 > > +and the sign of operand 2 in

[PATCH] More value_range API cleanup

This mainly tries to rectify the workaround I put in place for ipa-cp.c needing to build value_range instead of value_range_base for calling extract_range_from_unary_expr. To make this easier I moved more set_* functions to methods. Then for some reason I chose to fix the rathole of equiv bitma

Re: [PATCH 21/25] GCN Back-end (part 1/2).

On 09/11/2018 19:11, Jeff Law wrote: There's a ton of work related to reduction setup, updates and teardown. I don't guess there's any generic code we can/should be re-using. Sigh. I'm not sure what can be shared, or not, here. For OpenMP we don't have any special code, but OpenACC is much

Re: [PATCH][DOCS] Fix documentation of __builtin_cpu_is and __builtin_cpu_supports for x86.

> The patch is adding missing values for aforementioned built-ins. > > Ready for trunk? > Thanks, > Martin > > gcc/ChangeLog: > > 2018-11-12 Martin Liska > > * doc/extend.texi: Add missing values for __builtin_cpu_is and > __builtin_cpu_supports for x86 target. OK. Thanks, Uros.

Re: [PATCH 3/9][GCC][AArch64] Add autovectorization support for Complex instructions

Hi Tamar, On 11/11/18 10:26, Tamar Christina wrote: Hi All, This patch adds the expander support for supporting autovectorization of complex number operations such as Complex addition with a rotation along the Argand plane. This also adds support for complex FMA. The instructions are descri

Re: [PATCH][LRA] Fix PR87899: r264897 cause mis-compiled native arm-linux-gnueabihf toolchain

Hi Peter, Thanks for the patch! It makes much more sense to me to split those functions, and use them separately. I tried to build a native arm-linuxeabihf toolchain with the patch. But I got the following ICE: /home/renlin/try-new/./gcc/xgcc -B/home/renlin/try-new/./gcc/ -B/usr/local/arm-non

Re: [PATCH 3/9][GCC][AArch64] Add autovectorization support for Complex instructions

Hi Kyrill, > Hi Tamar, > > On 11/11/18 10:26, Tamar Christina wrote: > > Hi All, > > > > This patch adds the expander support for supporting autovectorization of > > complex number operations > > such as Complex addition with a rotation along the Argand plane. This also > > adds support for co

Re: [PATCH 21/25] GCN Back-end (part 2/2).

On 09/11/2018 19:39, Jeff Law wrote: + +/* Generate epilogue. Called from gen_epilogue during pro_and_epilogue pass. + + See gcn_expand_prologue for stack details. */ + +void +gcn_expand_epilogue (void) You probably need a barrier in here to ensure that the scheduler doesn't move an aliased

Re: [PATCH] combine: Do not combine moves from hard registers

On Mon, Nov 12, 2018 at 11:54:37AM +, Sam Tebbs wrote: > On 11/08/2018 08:34 PM, Segher Boessenkool wrote: > > > On Thu, Nov 08, 2018 at 03:44:44PM +, Sam Tebbs wrote: > >> Does your patch fix the incorrect generation of "scvtf s1, s1"? I was > >> looking at the issue as well and don't wan

Re: [RS6000] Don't pass -many to the assembler

On Mon, Nov 12, 2018 at 10:19:04PM +1030, Alan Modra wrote: > I'd like to remove -many from the options passed by default to the > assembler, on the grounds that a gcc bug in instruction selection (eg. > emitting a power9 insn for -mcpu=power8) is better found at assembly > time than run time. > >

Re: [PATCH] Come up with htab_hash_string_vptr and use string-specific if possible.

Hi, On Mon, 12 Nov 2018, Martin Liška wrote: > > There's no fundamental reason why we can't poison identifiers in other > > headers. Indeed we do in vec.h. So move the whole thing including > > poisoning to hash-table.h? > > That's not feasible as gcc/gcc/genhooks.c files use the function an

[PATCH] Fix PR87985

The following fixes split_constant_offset unbound un-CSEing of expressions when following SSA def stmts. Simply limiting it to single-uses isn't good for consumers so the following instead limits analysis by implementing a cache. Note this may still end up un-CSEing stuff but I didn't want to t

Re: [PATCH] Change set_value_range_to_[non]null to not preserve equivs

On 11/12/18 4:11 AM, Richard Biener wrote: > > This is a semantic change but AFAICS it shouldn't result in any > pessimization. The behavior of the API is non-obvious. > > Bootstrapped and tested on x86_64-unknown-linux-gnu, applied. > > Richard. > > 2018-11-12 Richard Biener > > *

Re: [PATCH][GCC] Make DR_TARGET_ALIGNMENT compile time variable

On Fri, Nov 9, 2018 at 5:08 PM Andre Vieira (lists) wrote: > > On 05/11/18 12:41, Richard Biener wrote: > > On Mon, Nov 5, 2018 at 1:07 PM Andre Vieira (lists) > > wrote: > >> > >> > >> Hi, > >> > Hi, > > Thank you for the quick response! See inline responses below. > > >> This patch enables targ

Re: [PATCH] Simplify floating point comparisons

On Fri, Nov 9, 2018 at 6:05 PM Wilco Dijkstra wrote: > > Richard Biener wrote: > >Marc Glisse wrote: > >> Let's try with C = DBL_MIN and x = 婊BL_MAX. I don't believe it involves > >> signed zeros or infinities, just an underflow. First, the result depends on > >> the rounding mode. And in the defa

[PATCH] Replace sync builtins with atomic builtins

The old __sync builtins have been deprecated for a long time now in favor of the __atomic builtins following the C++11/C11 memory model. This patch converts libgfortran to use the modern __atomic builtins. At the same time I weakened the consistency to relaxed for incrementing and decrementing the

Re: [PATCH][cunroll] Add unroll-known-loop-iterations-only param and use it in aarch64

On Fri, Nov 9, 2018 at 6:57 PM Kyrill Tkachov wrote: > > On 09/11/18 12:18, Richard Biener wrote: > > On Fri, Nov 9, 2018 at 11:47 AM Kyrill Tkachov > > wrote: > >> > >> Hi all, > >> > >> In this testcase the codegen for VLA SVE is worse than it could be due to > >> unrolling: > >> > >> fully_pe

Re: [PATCH, GCC, AArch64] Branch Dilution Pass

On Fri, Nov 9, 2018 at 6:23 PM Sudakshina Das wrote: > > Hi > > I am posting this patch on behalf of Carey (cc'ed). I also have some > review comments that I will make as a reply to this later. > > > This implements a new AArch64 specific back-end pass that helps optimize > branch-dense code, whic

Re: [PATCH] Add sinh(tanh(x)) and cosh(tanh(x)) rules

On Sat, Nov 10, 2018 at 6:36 AM Segher Boessenkool wrote: > > On Fri, Nov 09, 2018 at 01:03:55PM -0700, Jeff Law wrote: > > >> And signed zeroes. Yeah. I think it would have to be > > >> flag_unsafe_math_optimizations + some more. > > > > > > Indeed. > > So we need to give Giuliano some clear gu

Re: [PATCH] Fix ICE with -fopt-info-inline (PR ipa/87955)

On Sun, Nov 11, 2018 at 2:33 AM David Malcolm wrote: > > PR ipa/87955 reports a problem I introduced in r265920, where I converted > the guard in report_inline_failed_reason from using: > if (dump_file) > to using > if (dump_enabled_p ()). > without updating the calls to cl_target_option_print

Re: RFA: vectorizer patches 1/2 : WIDEN_MULT_PLUS support

On Sun, Nov 11, 2018 at 8:21 AM Joern Wolfgang Rennecke wrote: > > Our target (eSi-RISC) doesn't have DOT_PROD_EXPR or WIDEN_SUM_EXPR > operations in > the standard vector modes; however, it has a vectorized WIDEN_MULT_PLUS_EXPR > implementation with a double-vector output, which works just as wel

Re: RFA: vectorizer patches 2/2: reduction splitting

On Sun, Nov 11, 2018 at 9:16 AM Joern Wolfgang Rennecke wrote: > > It's nice to use the processors vector arithmetic to good effect, but > it's all for naught when > there are too many moves from/to general registers cluttering up the > loop. With a > double-vector reduction variable, the standar

Re: [RS6000] Don't pass -many to the assembler

Hi, On Mon, 12 Nov 2018, Alan Modra wrote: > I'd like to remove -many from the options passed by default to the > assembler, on the grounds that a gcc bug in instruction selection (eg. > emitting a power9 insn for -mcpu=power8) is better found at assembly > time than run time. > > This might

Re: [RFC][PR87528][PR86677] Disable builtin popcount detection when back-end does not define it

On Mon, Nov 12, 2018 at 6:21 AM Kugan Vivekanandarajah wrote: > > Hi Richard, > > Thanks for the review. > On Thu, 8 Nov 2018 at 00:03, Richard Biener > wrote: > > > > On Fri, Nov 2, 2018 at 10:02 AM Kugan Vivekanandarajah > > wrote: > > > > > > Hi Richard, > > > Thanks for the review. > > > On

[PATCH] Fortran include line fixes and -fdec-include support

Hi! In fortran97.pdf I read: "Except in a character context, blanks are insignificant and may be used freely throughout the program." and while we handle that in most cases, we don't allow spaces in INCLUDE lines in fixed form, while e.g. ifort does. Another thing, which I haven't touched in the

Re: [RS6000] Don't pass -many to the assembler

On Nov 12 2018, Michael Matz wrote: > Wouldn't this also break compiling code that contains power9 instructions > but guarded by runtime tests to only be executed on power9 machines? That > seems a valid usecase, and it'd be bad if the assembler fails to compile > such. (You can't use -mcpu=

Re: [PATCH, GCC, ARM] Enable armv8.5-a and add +sb and +predres for previous ARMv8-a in ARM

Hi Kyrill On 09/11/18 18:21, Kyrill Tkachov wrote: > Hi Sudi, > > On 09/11/18 15:33, Sudakshina Das wrote: >> Hi >> >> This patch adds -march=armv8.5-a to the Arm backend. >> (https://developer.arm.com/products/architecture/cpu-architecture/a-profile/exploration-tools) >> >> >> Armv8.5-A also a

Re: [PATCH, GCC, AArch64] Branch Dilution Pass

Hi Richard, On 12/11/18 14:13, Richard Biener wrote: On Fri, Nov 9, 2018 at 6:23 PM Sudakshina Das wrote: > > Hi > > I am posting this patch on behalf of Carey (cc'ed). I also have some > review comments that I will make as a reply to this later. > > > This implements a new AArch64 specific bac

[PATCH] PR libstdc++/87963 fix build for 64-bit mingw

PR libstdc++/87963 * src/c++17/memory_resource.cc (chunk::_M_bytes): Change type from unsigned to uint32_t. (chunk): Fix static assertion for 64-bit targets that aren't LP64. (bigblock::all_ones): Fix undefined shift. Tested x86_64-linux, committed to trunk

C++ PATCH to implement C++20 P0634R3, Down with typename!

This patch implements C++20 P0634R3, Down with typename! which makes 'typename' optional in several contexts specified in [temp.res]. The gist of the patch is in cp_parser_simple_type_specifier, where, if the context makes type

Re: [PATCH][LRA] Fix PR87899: r264897 cause mis-compiled native arm-linux-gnueabihf toolchain

On 11/12/18 6:25 AM, Renlin Li wrote: > I tried to build a native arm-linuxeabihf toolchain with the patch. > But I got the following ICE: Why can't things ever be easy? :-) I think we're getting closer though. Anyway, can you please recompile the failing file but using -save-temps and send me t

Re: [PATCH] Instrument only selected files (PR gcov-profile/87442).

On 11/12/18 12:56 AM, Martin Liška wrote: > On 11/9/18 11:00 PM, Jeff Law wrote: >> On 11/8/18 6:42 AM, Martin Liška wrote: >>> Hi. >>> >>> The patch is about possibility to filter which files are instrumented. The >>> usage >>> is explained in the PR. >>> >>> Patch can bootstrap and survives regr

Re: [RS6000] Don't pass -many to the assembler

On Mon, Nov 12, 2018 at 03:52:29PM +0100, Andreas Schwab wrote: > On Nov 12 2018, Michael Matz wrote: > > > Wouldn't this also break compiling code that contains power9 instructions > > but guarded by runtime tests to only be executed on power9 machines? That > > seems a valid usecase, and it'

Re: [PATCH, GCC, AArch64] Branch Dilution Pass

On 12/11/2018 15:13, Kyrill Tkachov wrote: > Hi Richard, > > On 12/11/18 14:13, Richard Biener wrote: >> On Fri, Nov 9, 2018 at 6:23 PM Sudakshina Das wrote: >> > >> > Hi >> > >> > I am posting this patch on behalf of Carey (cc'ed). I also have some >> > review comments that I will make as a repl

Re: [GCC][AArch64] [middle-end][docs] Document the xorsign optab

On 11/12/18 5:10 AM, Tamar Christina wrote: Hi Sandra, Ok for trunk? +@cindex @code{xorsign@var{m}3} instruction pattern +@item @samp{xorsign@var{m}3} +Target suppports an efficient expansion of x * copysign (1.0, y) +as xorsign (x, y). Store a value with the magnitude of operand 1 +and the s

Re: [RS6000] Don't pass -many to the assembler

Hi, On Mon, 12 Nov 2018, Segher Boessenkool wrote: > > > Wouldn't this also break compiling code that contains power9 > > > instructions but guarded by runtime tests to only be executed on > > > power9 machines? That seems a valid usecase, and it'd be bad if the > > > assembler fails to compi

Re: [PATCH][DOCS] Fix documentation of __builtin_cpu_is and __builtin_cpu_supports for x86.

On 11/12/18 4:46 AM, Martin Liška wrote: Hi. The patch is adding missing values for aforementioned built-ins. Ready for trunk? Thanks, Martin gcc/ChangeLog: 2018-11-12 Martin Liska * doc/extend.texi: Add missing values for __builtin_cpu_is and __builtin_cpu_supports for x8

Re: [PATCH 21/25] GCN Back-end (part 2/2).

On Mon, Nov 12, 2018 at 12:53:26PM +, Andrew Stubbs wrote: > >>+/* Implement TARGET_LEGITIMATE_COMBINED_INSN. > >>+ > >>+ Return false if the instruction is not appropriate as a combination > >>of two > >>+ or more instructions. */ > >>+ > >>+bool > >>+gcn_legitimate_combined_insn (rtx_in

Re: [doc PATCH] Fix weakref description.

On 2018-11-02 1:59 p.m., Michael Ploujnikov wrote: > I came across this typo and also added a similar ld invocation for > illustration purposes as mentioned by Jakub on irc. > After talking to Jakub about it, I went with different terminology. - Michael From f14d7315e0dc9c4b6aff6137fd90e4d2595e

Re: [RS6000] Don't pass -many to the assembler

On 11/12/18 5:49 AM, Alan Modra wrote: > I'd like to remove -many from the options passed by default to the > assembler, on the grounds that a gcc bug in instruction selection (eg. > emitting a power9 insn for -mcpu=power8) is better found at assembly > time than run time. > > This might annoy peo

Re: [PATCH 21/25] GCN Back-end (part 2/2).

On 12/11/2018 17:20, Segher Boessenkool wrote: If you don't want useless USEs deleted, use UNSPEC_VOLATILE instead? Or actually use the register, i.e. as input to an actually needed instruction. They're not useless. If we want to do scalar operations in vector registers (and we often do, on th

Re: [PATCH][cunroll] Add unroll-known-loop-iterations-only param and use it in aarch64

On 12/11/18 14:10, Richard Biener wrote: On Fri, Nov 9, 2018 at 6:57 PM Kyrill Tkachov wrote: On 09/11/18 12:18, Richard Biener wrote: On Fri, Nov 9, 2018 at 11:47 AM Kyrill Tkachov wrote: Hi all, In this testcase the codegen for VLA SVE is worse than it could be due to unrolling: fully

Re: [PATCH 2/3][GCC][AARCH64] Add new -mbranch-protection option to combine pointer signing and BTI

Hi Sam On 02/11/18 17:31, Sam Tebbs wrote: > Hi all, > > The -mbranch-protection option combines the functionality of > -msign-return-address and the BTI features new in Armv8.5 to better reflect > their relationship. This new option therefore supersedes and deprecates the > existing -msign-retur

Re: [PATCH] detect attribute mismatches in alias declarations (PR 81824)

Hello Martin, The new testcase Wattribute-alias.c fails on targets without ifunc support (e.g. aarch64-none-elf cross-build). It seems that just adding a directive `{ dg-require-ifunc "" }` to the test file changes the test to unsupported instead of having a fail. I don't know much about this

Re: [PATCH 21/25] GCN Back-end (part 2/2).

On Mon, Nov 12, 2018 at 05:52:25PM +, Andrew Stubbs wrote: > On 12/11/2018 17:20, Segher Boessenkool wrote: > >If you don't want useless USEs deleted, use UNSPEC_VOLATILE instead? > >Or actually use the register, i.e. as input to an actually needed > >instruction. > > They're not useless. > >

Re: [PATCH] detect attribute mismatches in alias declarations (PR 81824)

On 11/12/2018 11:29 AM, Matthew Malcomson wrote: Hello Martin, The new testcase Wattribute-alias.c fails on targets without ifunc support (e.g. aarch64-none-elf cross-build). It seems that just adding a directive `{ dg-require-ifunc "" }` to the test file changes the test to unsupported instead

Re: [PATCH 21/25] GCN Back-end (part 2/2).

On 11/12/18 10:52 AM, Andrew Stubbs wrote: > On 12/11/2018 17:20, Segher Boessenkool wrote: >> If you don't want useless USEs deleted, use UNSPEC_VOLATILE instead? >> Or actually use the register, i.e. as input to an actually needed >> instruction. > > They're not useless. If we want to do scalar

RE: PING [PATCH] RX new builtin function

PING > -Original Message- > From: Sebastian Perta > Sent: 24 October 2018 18:19 > To: 'gcc-patches@gcc.gnu.org' > Cc: 'Nick Clifton' > Subject: [PATCH] RX new builtin function > > Hi, > > The following patch adds a new builtin function for rx ( __builtin_rx_bset) to > make it possible

[doc, committed] clarify rtl docs about mode of high and lo_sum

I've checked in this patch for PR 21110. As noted in the issue, RTL high and lo_sum expressions don't have to be Pmode and are not restricted to address operands. -Sandra 2018-11-12 Sandra Loosemore PR middle-end/21110 gcc/ * doc/rtl.texi (Constants): Clarify that mode of "high" doesn'

[PATCH 3/4] [aarch64] Add xgene1 prefetch tunings.

*** gcc/ChangeLog *** 2018-xx-xx Christoph Muellner * config/aarch64/aarch64.c (xgene1_tunings): Add Xgene1 specific prefetch tunings. --- gcc/config/aarch64/aarch64.c | 13 - 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/gcc/config/aarch64/aarch64.

[PATCH 4/4] [aarch64] Update xgene1 tuning struct.

*** gcc/ChangeLog *** 2018-xx-xx Christoph Muellner * config/aarch64/aarch64.c (xgene1_tunings): Optimize Xgene1 tunings for GCC 9. --- gcc/config/aarch64/aarch64.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/gcc/config/aarch64/aarch64.c b/gcc/confi

[PATCH 2/4] [aarch64] Update xgene1_addrcost_table.

*** gcc/ChangeLog *** 2018-xx-xx Christoph Muellner * config/aarch64/aarch64.c (xgene1_addrcost_table): Correct the post modify costs. --- gcc/config/aarch64/aarch64.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/config/aarch64/aarch64.c b/gcc/confi

[PATCH 1/4] [aarch64/arm] Updating the cost table for xgene1.

*** gcc/ChangeLog *** 2018-xx-xx Christoph Muellner * config/arm/aarch-cost-tables.h (xgene1_extra_costs): Update the cost table for Xgene1. --- gcc/config/arm/aarch-cost-tables.h | 88 +++--- 1 file changed, 44 insertions(+), 44 deletions(-)

Re: [PATCH 2/6] [RS6000] rs6000_output_indirect_call

On 11/6/18 11:37 PM, Alan Modra wrote: > Like the last patch for external calls, now handle most assembly code > for indirect calls in one place. The patch also merges some insns, > correcting some !rs6000_speculate_indirect_jumps cases branching to > LR, which don't require a speculation barrier.

Re: [PATCH][LRA] Fix PR87899: r264897 cause mis-compiled native arm-linux-gnueabihf toolchain

On 11/12/18 6:25 AM, Renlin Li wrote: > I tried to build a native arm-linuxeabihf toolchain with the patch. > But I got the following ICE: Ok, the issue was a problem in handling the src reg from a register copy. I thought I could just remove it from the dead_set, but forgot that the updating of t

Re: PR fortran/87919 patch for -fno-dec-structure

On Thu, Nov 8, 2018 at 12:54 PM Jakub Jelinek wrote: > > On Thu, Nov 08, 2018 at 12:09:33PM -0500, Fritz Reese wrote: > > > What about the > > > /* Allow legacy code without warnings. */ > > > gfc_option.allow_std |= GFC_STD_F95_OBS | GFC_STD_F95_DEL > > > | GFC_STD_GNU | GFC_

Re: [PATCH] RFC: elide repeated source locations (PR other/84889)

On 11/11/2018 07:43 PM, David Malcolm wrote: We often emit more than one diagnostic at the same source location. For example, the C++ frontend can emit many diagnostics at the same source location when suggesting overload candidates. For example: ../../src/gcc/testsuite/g++.dg/diagnostic/bad-bi

[PATCH, fortran] PR fortran/85982 -- Fix ICE on invalid attributes inside DEC structures

All, The simple patch below (and attached) fixes PR 85982. The issue is an omission of the macro gfc_comp_struct() which would include DEC structures in certain attribute checks that are performed for derived-TYPE declarations in decl.c. In the case described in the PR (https://gcc.gnu.org/bugzill

Re: PR fortran/87919 patch for -fno-dec-structure

On Mon, Nov 12, 2018 at 03:28:47PM -0500, Fritz Reese wrote: > Actually, the gcc frontend appears to move -std= before the > language-specific options before f951 is even executed regardless of > its location compared to the -fdec flags. I don't know if this is a That is because: #define F951_OPTI

Re: PR fortran/87919 patch for -fno-dec-structure

On Mon, Nov 12, 2018 at 3:42 PM Jakub Jelinek wrote: > Ok, so I'll ack it for trunk now, but please give the other Fortran > maintainers one day to disagree before committing. > For the release branches, I'd wait two weeks or so before backporting it. > Roger that. I'll happily give it some time.

Re: [PATCH] RFC: C/C++: print help when a header can't be found

On 11/11/2018 04:33 PM, David Malcolm wrote: When gcc can't find a header file, it's a hard error that stops the build, typically requiring the user to mess around with compile flags, Makefiles, dependencies, and so forth. Often the exact search paths aren't obvious to the user. Consider the ca

  1   2   >