[PATCH, OBVIOUS] Fix -Wshadow=local warnings in gcc/[a-c]*.c

Hi, this fixes -Wshadow=local warnings in the following files: M gcc/asan.c M gcc/attribs.c M gcc/auto-inc-dec.c M gcc/bb-reorder.c M gcc/builtins.c M gcc/caller-save.c M gcc/calls.c M gcc/cfgbuild.c M gcc/cfg.c M gcc/cfgcleanup.c M

Re: [PATCH] Fix -Wshadow=local warnings in elfos.h

On 10/4/19 10:26 PM, Jeff Law wrote: > On 10/4/19 12:24 PM, Bernd Edlinger wrote: >> Hi, >> >> these macros don't use reserved names for local variables. >> This caused -Wshadow=local warnings in varasm.c IIRC. >> >> Fixed by using _lowercase reserved names for macro parameters. >> >> >> Bootstr

Re: [PATCH] Fix -Wshadow=local warnings in rtl.h

On 10/4/19 10:26 AM, Segher Boessenkool wrote: > On Thu, Oct 03, 2019 at 05:25:55PM +0200, Jakub Jelinek wrote: >> On Thu, Oct 03, 2019 at 03:17:47PM +, Bernd Edlinger wrote: >>> this fixes -Wshadow=local warnings in the RTL_FLAG_CHECKx macros, >>> which happen when this macro is used recursive

Re: [PATCH] Fix -Wshadow=local warnings in defaults.h

On 10/4/19 10:23 PM, Jeff Law wrote: > On 10/4/19 12:24 PM, Bernd Edlinger wrote: >> Hi, >> >> this macro caused -Wshadow=local warnings in varasm.c with >> the microblaze target. >> >> >> Only built a bare metal cross compiler that was able to compile >> libgcc for that target. >> >> Is it OK for

Re: [PATCH] Fix -Wshadow=local warnings in rtl.h

On 10/3/19 5:25 PM, Jakub Jelinek wrote: > On Thu, Oct 03, 2019 at 03:17:47PM +, Bernd Edlinger wrote: >> Hi, >> >> this fixes -Wshadow=local warnings in the RTL_FLAG_CHECKx macros, >> which happen when this macro is used recursively in a macro >> argument. The __typeof (RTX) const _rtx in

Re: [SVE] PR91532

On Fri, 4 Oct 2019 at 12:18, Richard Biener wrote: > > On Thu, 3 Oct 2019, Prathamesh Kulkarni wrote: > > > On Wed, 2 Oct 2019 at 12:28, Richard Biener wrote: > > > > > > On Wed, 2 Oct 2019, Prathamesh Kulkarni wrote: > > > > > > > On Wed, 2 Oct 2019 at 01:08, Jeff Law wrote: > > > > > > > > > >

[PATCH] PR fortran/47054 -- Don't search parent namespace for symbol

I plan to commit this as obviously correct tomorrow morning. However, as the bug has been open for nearly 9 years, I give anyone reading this a chance to speak up. 2019-10-04 Steven G. Kargl PR fortran/47045 * decl.c (variable_decl): Do not search parent namespace for symbol. 2019-10-04 St

C++ PATCH for C++20 P0388R4 (conversions to arrays of unknown bounds) and CWG 1307 (c++/91364, c++/69531)

This patch implements P0388R4, Permit conversions to arrays of unknown bound, . CWG 393 allowed references to arrays of unknown bound and this C++20 feature allows conversions like void f(int(&)[]); int arr[1]; void g() { f(arr); } int(&r)[] = arr; The proposal

[PATCH] PR fortran/89943 -- Duplicate BIND(c) allowed (?)

The attached patch allows the declaration of a BIND(C) module function or module subroutine to appear in a submodule (see testcases). Regression test was clean. OK to commit? Before a rubber stamped 'OK'. I do NOT use submodules. A submodule user needs to pipe up on the validity of the patch.

Re: [PATCH][RFC] Add new ipa-reorder pass

On 9/19/19 2:33 AM, Martin Liška wrote: > Hi. > > Function reordering has been around for quite some time and a naive > implementation was also part of my diploma thesis some time ago. > Currently, the GCC can reorder function based on first execution, which > happens with PGO and LTO of course. K

Add strftime format checking support for C2x %OB and %Ob (bug 82752)

C2x adds strftime %OB and %Ob formats, for alternative forms of month names (for mainly Slavic languages where a month name on its own is declined differently from a month name together with a date within that month). This patch adds corresponding format checking support. (glibc support for these

Re: [21/32] Remove global call sets: LRA

On Fri, Oct 4, 2019 at 11:03 AM H.J. Lu wrote: > > On Wed, Sep 11, 2019 at 12:14 PM Richard Sandiford > wrote: > > > > lra_reg has an actual_call_used_reg_set field that is only used during > > inheritance. This in turn required a special lra_create_live_ranges > > pass for flag_ipa_ra to set up

[PATCHv2] Change the library search path when using --with-advance-toolchain

Michael Meissner writes: > And then I built Spec 2006 and 2017 with my normal options on a power8 system > running Ubuntu and an older set of host libraries. If I have this patch > installed, it breaks linking some/all of the C++ and Fortran benchmarks, > because it finds the host C++/Fortran li

Re: [Patch, GCC]Backporting r269039 to gcc8

On 10/4/19 9:11 AM, Delia Burduv wrote: > Ping. Has anyone had a look at the patch? Please let me know if it is fine. I think it's fine to backport to the gcc-8 branch. Do you have commit access? jeff

Re: Add a simulate_builin_function_decl langhook

On 9/26/19 6:04 AM, Richard Sandiford wrote: > Although it's possible to define the SVE intrinsics in a normal header > file, it's much more convenient to define them directly in the compiler. > This also speeds up compilation and gives better error messages. > > The idea is therefore for arm_sve.

Re: [PATCH] fold more string comparison with known result (PR 90879)

On 9/23/19 4:14 PM, Martin Sebor wrote: > > Yes, it looks redundant.  I never remember which of these functions > ICE when their argument is not a constant (e.g., tree_int_cst_lt) > and which ones handle it gracefully (e.g., tree_int_cst_equal) so > I often check even when it isn't necessary.  It

Re: [PATCH] Fix up sqrt(x) < c and sqrt(x) >= c match.pd folding (PR tree-optimization/91734, take 2)

On 9/21/19 12:14 AM, Jakub Jelinek wrote: > On Mon, Sep 16, 2019 at 08:56:58AM +0200, Richard Biener wrote: >>> As mentioned in the PR, the sqrt (x) < c optimization into x < c*c >>> sometimes breaks the boundary case, if c2=c*c is inexact then in some cases >>> we need to optimize it into x <= c*c

Re: [PATCH] PR fortran/91959 -- Re-arrange matching of %FILL

On Fri, Oct 04, 2019 at 09:59:14PM +0200, Thomas Koenig wrote: > Hi Steve, > > > The attached patch has been tested on x86_64-*-freebsd. > > OK to commit. > > OK. > > Thanks a lot for the patch! > > Since this seems to be a regression to before when %FILL was introduced, > also OK to backport a

Re: [PATCH] Improve _Safe_iterator _M_distance_to

I eventually committed the attach patch. The usage of __dp_sign_max_size will come later. François On 9/27/19 1:45 PM, Jonathan Wakely wrote: On 16/09/19 22:31 +0200, François Dumont wrote:     Here is the patch to improve _Safe_iterator<>::_M_get_distance_to implementation. I introduced a

Re: [PR target/85401] Add test-cases

On 10/4/19 1:43 PM, co...@sdf.org wrote: > On Tue, Oct 01, 2019 at 01:26:16PM -0600, Jeff Law wrote: >> On 9/30/19 2:45 PM, co...@sdf.org wrote: >>> On Mon, Sep 30, 2019 at 11:46:24AM -0400, Vladimir Makarov wrote: Yes, the patch is mostly ok.  You can commit it into the trunk after apply

Re: [PATCH] Fix -Wshadow=local warnings in elfos.h

On 10/4/19 12:24 PM, Bernd Edlinger wrote: > Hi, > > these macros don't use reserved names for local variables. > This caused -Wshadow=local warnings in varasm.c IIRC. > > Fixed by using _lowercase reserved names for macro parameters. > > > Bootstrapped and reg-tested on x86_64-pc-linux-gnu. >

Re: [PATCH] Fix -Wshadow=local warnings in defaults.h

On 10/4/19 12:24 PM, Bernd Edlinger wrote: > Hi, > > this macro caused -Wshadow=local warnings in varasm.c with > the microblaze target. > > > Only built a bare metal cross compiler that was able to compile > libgcc for that target. > > Is it OK for trunk? > > > Thanks > Bernd. > > > > pat

Re: [PATCH] Fix -Wshadow=local warnings in defaults.h

On 10/4/19 12:24 PM, Bernd Edlinger wrote: > Hi, > > this macro caused -Wshadow=local warnings in varasm.c with > the microblaze target. > > > Only built a bare metal cross compiler that was able to compile > libgcc for that target. > > Is it OK for trunk? > > > Thanks > Bernd. > > > > pat

Re: [PATCH] PR fortran/91497 -- Silence conversion warnings

On Fri, Oct 04, 2019 at 05:49:13PM +0200, Rainer Orth wrote: > > > The attach patch silences -Wconversion and -Wconversion-extra > > warnings that had previously been issued for explicit conversions > > (see testcase for examples). > > > > The patch has been tested on x86-*-freebsd. OK to commit?

Re: [PATCH] PR fortran/91959 -- Re-arrange matching of %FILL

Hi Steve, The attached patch has been tested on x86_64-*-freebsd. OK to commit. OK. Thanks a lot for the patch! Since this seems to be a regression to before when %FILL was introduced, also OK to backport as far as you care to do it. Regards Thomas

Merge from trunk to gccgo branch

I've merged trunk revision 276594 to the gccgo branch. Ian

[PR target/85401] Add test-cases

On Tue, Oct 01, 2019 at 01:26:16PM -0600, Jeff Law wrote: > On 9/30/19 2:45 PM, co...@sdf.org wrote: > > On Mon, Sep 30, 2019 at 11:46:24AM -0400, Vladimir Makarov wrote: > >> Yes, the patch is mostly ok.  You can commit it into the trunk after > >> applying changes mentioned below. If you do not h

Re: [C++ PATCH] PR c++/91369 - Implement P0784R7: constexpr new

On 10/4/19 1:50 PM, Jakub Jelinek wrote: On Thu, Oct 03, 2019 at 04:07:14PM -0400, Jason Merrill wrote: I believe it doesn't, because the heap VAR_DECLs are TREE_STATIC (things really don't work at all if they aren't). Ah, sure. I suppose you could clear TREE_STATIC from them before the verif

[PATCH] Fix -Wshadow=local warnings in genautomata.c

Hi, this is probably on the border to obvious. The REGEXP_xxx macros in genautomata are invoked recursively, and the local values are all named _regexp and shadow each other. Fixed by using different names _regexp1..6 for each macro. Bootstrapped and reg-tested on x86_64-pc-linux-gnu. Is it O

Re: -O2 inliner retuning 3/n: make inline hints more systematic

Hi, this is fix I commit as obvious. Index: ipa-inline.c === --- ipa-inline.c(revision 276564) +++ ipa-inline.c(working copy) @@ -396,7 +396,7 @@ can_inline_edge_p (struct cgraph_edge *e static int inline_insns_singl

Type representation in CTF and DWARF

Hello, At GNU Tools Cauldron this year, some folks were curious to know more on how the "type representation" in CTF compares vis-a-vis DWARF. I use small testcase below to gather some numbers to help drive this discussion. [ibhagat@ibhagatpc ctf-size]$ cat ctf_sizeme.c #define MAX_NUM_MSGS 5

[preprocessor/91991] column location overflow

this patch fixes 91991. My fix for 91639 tickled a latent bug in the line map code. In that patch I set highest_line when linemap_line_start ran out of locations. But I did not clear max_column_hint. The latter's clearing is presumed by linemap_position_for_column. It was happily reporting

Re: [PATCH] Simplify sinh (x) / cosh (x)

On 10/2/19 12:08 PM, Rafael Tsuha wrote: > Hi Jeff, > > I've just checked and the proposed optimization is under > -funsafe-math-optimizations and canonicalize_math_p(): > `(if (flag_unsafe_math_optimizations && canonicalize_math_p ())` > > I'm sorry, but I don't quite understand what you mean w

[PATCH] Fix -Wshadow=local warnings in defaults.h

Hi, this macro caused -Wshadow=local warnings in varasm.c with the microblaze target. Only built a bare metal cross compiler that was able to compile libgcc for that target. Is it OK for trunk? Thanks Bernd. 2019-10-04 Bernd Edlinger * defaults.h (ASM_OUTPUT_ASCII): Rename local vars i

[PATCH] Fix -Wshadow=local warnings in elfos.h

Hi, these macros don't use reserved names for local variables. This caused -Wshadow=local warnings in varasm.c IIRC. Fixed by using _lowercase reserved names for macro parameters. Bootstrapped and reg-tested on x86_64-pc-linux-gnu. Is it OK for trunk? Thanks Bernd. 2019-10-04 Bernd Edlinge

[PATCH] PR fortran/91959 -- Re-arrange matching of %FILL

The attached patch has been tested on x86_64-*-freebsd. OK to commit. Apparently, DEC Fortran allows one to use %FILL as a variable name. When the -fdec code was added to gfortran, variable_decl was updated to match %FILL. This was done by first ilooking for the % character, and if found, it is b

Go patch committed: Include constant types during export processing

This patch to the Go frontend by Than McIntosh includes selected constant types during export processing. The machinery that collects types referenced by expressions that are part of inlinable function bodies was missing the types of local named constants in certain cases. This patch updates the

Re: [PATCH] Fix -Wshadow=local warnings in rtl.h

On 10/4/19 7:09 PM, Richard Sandiford wrote: > Bernd Edlinger writes: >> >> Actually I wanted to do it with a template, and invoke it using >> __typeof(RTX). >> >> BUT with that I ran into a lmitation of the template vs. block statements >> See PR#91803: We cannot instantiate a template on the >

Re: [patch] disentangle range_fold_*ary_expr into various pieces

On 10/4/19 7:25 AM, Aldy Hernandez wrote: > I promised I would clean up the VRP/range-ops interface once the patch > went in.  I was afraid of shuffling things too much initially, because I > was trying to keep to the original structure of > extract_range_from_*ary_expr.  Now that things are in pla

Re: -O2 inliner retuning 3/n: make inline hints more systematic

> On Fri, 4 Oct 2019, Jan Hubicka wrote: > > > > I don't really understand the purpose of having 2 params where one is used > > > for -O2 and the other for -O3 (I didn't check -Os), instead of a single > > > param whose default value depends on -On (what we had before?). Is it so > > > that we can

Re: [21/32] Remove global call sets: LRA

On Wed, Sep 11, 2019 at 12:14 PM Richard Sandiford wrote: > > lra_reg has an actual_call_used_reg_set field that is only used during > inheritance. This in turn required a special lra_create_live_ranges > pass for flag_ipa_ra to set up this field. This patch instead makes > the inheritance code

Re: [PATCH] Fix -Wshadow=local warnings in dumpfile.h

On 10/4/19 2:16 PM, Richard Sandiford wrote: > Bernd Edlinger writes: >> Hi, >> >> this fixes a -Wshadow=local warning when using AUTO_DUMP_SCOPE in >> nested blocks. Since NAME i a string I cannot use it to create >> a unique name for the auto_dump_scope object. >> >> So I used XCONCAT2 from goo

Re: [C++ PATCH] PR c++/91369 - Implement P0784R7: constexpr new

On Thu, Oct 03, 2019 at 04:07:14PM -0400, Jason Merrill wrote: > > I believe it doesn't, because the heap VAR_DECLs are TREE_STATIC (things > > really don't work at all if they aren't). > > Ah, sure. I suppose you could clear TREE_STATIC from them before the > verify_constant in this function? T

Re: [patch] canonicalize unsigned [1,MAX] ranges into ~[0,0]

On 10/4/19 10:14 AM, Aldy Hernandez wrote: > > > On 10/4/19 12:02 PM, Jeff Law wrote: >> On 10/4/19 9:49 AM, Aldy Hernandez wrote: >>> >>> >>> On 10/4/19 11:38 AM, Jeff Law wrote: On 10/4/19 6:59 AM, Aldy Hernandez wrote: > When I did the value_range canonicalization work, I noticed that

Re: [PATCH] Fix -Wshadow=local warnings in rtl.h

Bernd Edlinger writes: > On 10/4/19 2:38 PM, Richard Sandiford wrote: >> Bernd Edlinger writes: >>> Hi, >>> >>> this fixes -Wshadow=local warnings in the RTL_FLAG_CHECKx macros, >>> which happen when this macro is used recursively in a macro >>> argument. The __typeof (RTX) const _rtx in the inn

Re: [PATCH] C testsuite, silence a FreeBSD libc warning

On 9/30/19 12:47 PM, Andreas Tobler wrote: > On 30.09.19 20:37, Kamil Rytarowski wrote: >> On 30.09.2019 19:47, Jakub Jelinek wrote: >>> On Mon, Sep 30, 2019 at 07:41:00PM +0200, Andreas Tobler wrote: --- fprintf-2.c    (revision 276292) +++ fprintf-2.c    (working copy) @@ -1,7 +1,8

Re: [ping][PATCH][MSP430] Don't generate 430X insns when handling data in the lower memory region

On 9/25/19 10:24 AM, Jozef Lawrynowicz wrote: > ping > > On Wed, 11 Sep 2019 11:25:58 +0100 > Jozef Lawrynowicz wrote: > >> The MSP430 target has a "430X" extension which increases the directly >> addressable memory range from 64KB (16-bit) to 1MB (20-bit). >> This 1MB memory range is split into

Re: -O2 inliner retuning 3/n: make inline hints more systematic

On Fri, 4 Oct 2019, Jan Hubicka wrote: I don't really understand the purpose of having 2 params where one is used for -O2 and the other for -O3 (I didn't check -Os), instead of a single param whose default value depends on -On (what we had before?). Is it so that we can more easily mix some func

Re: [PATCH] Fix -Wshadow=local warnings in rtl.h

On 10/4/19 2:38 PM, Richard Sandiford wrote: > Bernd Edlinger writes: >> Hi, >> >> this fixes -Wshadow=local warnings in the RTL_FLAG_CHECKx macros, >> which happen when this macro is used recursively in a macro >> argument. The __typeof (RTX) const _rtx in the inner macro >> expansions shadows t

Re: [patch] canonicalize unsigned [1,MAX] ranges into ~[0,0]

On October 4, 2019 5:38:09 PM GMT+02:00, Jeff Law wrote: >On 10/4/19 6:59 AM, Aldy Hernandez wrote: >> When I did the value_range canonicalization work, I noticed that an >> unsigned [1,MAX] and an ~[0,0] could be two different representations >> for the same thing.  I didn't address the problem t

Re: [patch] canonicalize unsigned [1,MAX] ranges into ~[0,0]

On 10/4/19 12:02 PM, Jeff Law wrote: On 10/4/19 9:49 AM, Aldy Hernandez wrote: On 10/4/19 11:38 AM, Jeff Law wrote: On 10/4/19 6:59 AM, Aldy Hernandez wrote: When I did the value_range canonicalization work, I noticed that an unsigned [1,MAX] and an ~[0,0] could be two different represent

Re: [PATCH] Remove extra lib directory from --with-advance-toolchain

On 10/3/19 11:08 AM, Tulio Magno Quites Machado Filho wrote: > Remove the extra -L directory so that user directories specified at > build time have higher preference over the advance toolchain libraries. > > 2019-10-03 Tulio Magno Quites Machado Filho > > * config.gcc: Remove an extra -

Re: Mark C2x built-in functions as such

On 10/3/19 4:57 PM, Joseph Myers wrote: > Various built-in functions that GCC has as extensions are now standard > functions in C2x. This patch adds DEF_C2X_BUILTIN and uses it to mark > them as such. Some of the so-marked functions were previously > DEF_EXT_LIB_BUILTIN, while some DFP ones were

Re: [patch] canonicalize unsigned [1,MAX] ranges into ~[0,0]

On 10/4/19 9:49 AM, Aldy Hernandez wrote: > > > On 10/4/19 11:38 AM, Jeff Law wrote: >> On 10/4/19 6:59 AM, Aldy Hernandez wrote: >>> When I did the value_range canonicalization work, I noticed that an >>> unsigned [1,MAX] and an ~[0,0] could be two different representations >>> for the same thin

Re: [PATCH] PR fortran/91497 -- Silence conversion warnings

On Fri, Oct 04, 2019 at 05:49:13PM +0200, Rainer Orth wrote: > > > The attach patch silences -Wconversion and -Wconversion-extra > > warnings that had previously been issued for explicit conversions > > (see testcase for examples). > > > > The patch has been tested on x86-*-freebsd. OK to commit?

Re: Use CONSTEXPR in machmode.h

On 10/4/19 9:01 AM, Richard Sandiford wrote: > I'd like to use CONSTEXPR to get static initialisation of some > aarch64-specific variables. This obviously means that cross toolchains > built with old compilers won't benefit, but I hope toolchains built with > newer compilers are faster for other r

Re: [patch] canonicalize unsigned [1,MAX] ranges into ~[0,0]

On 10/4/19 11:38 AM, Jeff Law wrote: On 10/4/19 6:59 AM, Aldy Hernandez wrote: When I did the value_range canonicalization work, I noticed that an unsigned [1,MAX] and an ~[0,0] could be two different representations for the same thing.  I didn't address the problem then because callers to ra

Re: [PATCH] PR fortran/91497 -- Silence conversion warnings

Hi Steve, > The attach patch silences -Wconversion and -Wconversion-extra > warnings that had previously been issued for explicit conversions > (see testcase for examples). > > The patch has been tested on x86-*-freebsd. OK to commit? > > 2019-10-03 Steven G. Kargl > > PR fortran/91497 >

Re: [PR target/85401] initialize the move cost table before using it (in another place, too)

On 10/4/19 7:23 AM, co...@sdf.org wrote: > On Tue, Oct 01, 2019 at 01:26:16PM -0600, Jeff Law wrote: >> On 9/30/19 2:45 PM, co...@sdf.org wrote: >>> On Mon, Sep 30, 2019 at 11:46:24AM -0400, Vladimir Makarov wrote: Yes, the patch is mostly ok.  You can commit it into the trunk after apply

Re: [PATCH] Add missing gimple_call_set_fntype

On 10/4/19 7:07 AM, Martin Jambor wrote: > Hi, > > when looking for detected call argument type incompatibilities I > stumbled over a call to builtin_memcpy which originally was a call to > builtin_memset but simplify_builtin_call changed it to the former > without setting the gimple statement fnt

Re: [patch] canonicalize unsigned [1,MAX] ranges into ~[0,0]

On 10/4/19 6:59 AM, Aldy Hernandez wrote: > When I did the value_range canonicalization work, I noticed that an > unsigned [1,MAX] and an ~[0,0] could be two different representations > for the same thing.  I didn't address the problem then because callers > to ranges_from_anti_range() would go int

Re: [Patch, GCC]Backporting r269039 to gcc8

Ping. Has anyone had a look at the patch? Please let me know if it is fine. Thanks, Delia From: Delia Burduv Sent: 18 September 2019 15:54 To: gcc-patches@gcc.gnu.org Cc: nd ; l...@redhat.com ; i...@airs.com ; rguent...@suse.de Subject: [Patch, GCC]Backporting

[PATCH] Build filesystem library with large file support

Enable AC_SYS_LARGEFILE to set the macros needed for large file APIs to be used by default. We do not want to define those macros in the public headers that users include. The values of the macros are copied to a separate file that is only included by the filesystem sources during the build, and t

[PATCH] Replace uses of std::tr1::unordered_map in testsuite

I see no reason to use tr1::unordered_map unless we have to (because we're compiling a test in C++98 mode). * testsuite/util/testsuite_abi.h: Use std::unordered_map instead of std::tr1::unordered_map. * testsuite/util/testsuite_allocator.h: Likewise. Tested x86_64-linux,

Use CONSTEXPR in machmode.h

I'd like to use CONSTEXPR to get static initialisation of some aarch64-specific variables. This obviously means that cross toolchains built with old compilers won't benefit, but I hope toolchains built with newer compilers are faster for other reasons too. :-) The variables in question have scala

Re: [PATCH] Fix -Wshadow=local warnings and a minor bug in expr.c

On 10/4/19 6:01 AM, Richard Sandiford wrote: > Bernd Edlinger writes: >> @@ -4481,16 +4478,16 @@ emit_push_insn (rtx x, machine_mode mode, tree typ >>/* Get the address of the stack space. >> In this case, we do not deal with EXTRA separately. >> A single stack adjust w

[committed] Disable broken H8/SX patterns/expanders

Spurred by an IRC discussion with Segher a week or so ago this is a patch I've been carrying around for a long time that I'm going to push into the trunk. The H8 port will fail to build parts of libgcc because of its block move patterns will fail at compile time. Whether or not they fail depends

Re: [29/32] Remove global call sets: sched-deps.c

On Fri, 4 Oct 2019 at 16:35, Richard Sandiford wrote: > Christophe Lyon writes: > > On Mon, 30 Sep 2019 at 00:20, Jeff Law wrote: > > > > On 9/11/19 1:17 PM, Richard Sandiford wrote: > > > This is a straight replacement of an existing "full or partial" > > > call-clobber check. > >

Re: [29/32] Remove global call sets: sched-deps.c

Christophe Lyon writes: > On Mon, 30 Sep 2019 at 00:20, Jeff Law wrote: > > On 9/11/19 1:17 PM, Richard Sandiford wrote: > > This is a straight replacement of an existing "full or partial" > > call-clobber check. > > > > > > 2019-09-11 Richard Sandiford > > > >

Re: [29/32] Remove global call sets: sched-deps.c

On Mon, 30 Sep 2019 at 00:20, Jeff Law wrote: > On 9/11/19 1:17 PM, Richard Sandiford wrote: > > This is a straight replacement of an existing "full or partial" > > call-clobber check. > > > > > > 2019-09-11 Richard Sandiford > > > > gcc/ > > * sched-deps.c (deps_analyze_insn): Use the A

Re: [preprocessor/91639] #includes at EOF

Hi, On Thu, Sep 05 2019, Nathan Sidwell wrote: > This fixes 91639. > #include processing needs to rewind by one line before doing the > inclusion, so that that happens on the #include line itself. Except > that the lexer doesn't increment the lineno on the last \n of a file -- > because there'

[committed] Avoid ranger self-test failures for 16bit integer targets

My tester started spitting out failures for targets with 16bit integers after the introduction of range-ops. It turns out two of the selftests in range_tests assume that shorts and ints are different sizes. The first creates a range with [0, MAXINT] bounds, converts it to a short and verifies th

Go patch committed: Change frontend code to avoid shadowing locals

This patch to the Go frontend adjusts the frontend code to avoid shadowing local variables, to be clean with the proposed -Wshadow=local option. This also add a couple of missing calls to free after mpz_get_str. This is based on a patch by Bernd Edlinger. Bootstrapped and ran Go testsuite on x86_

[patch][OpenMP,Fortran] Fix trans-openmp.c, add use_device_addr run-time test case (has known issues with actual offloading)

This use_device_addr patch does: * Add trivial but crucial missing change to "fortran/trans-openmp.c (Ups!) * Add a comprehensive set of test cases (only scalars and non-array-descriptor arrays) Remarks: * The test cases are known to mishandle "cc/dd/ee/ff" (= scalars with allocatable + point

Re: [AArch64] Strengthen aarch64_hard_regno_call_part_clobbered

Christophe Lyon writes: > On Mon, 30 Sep 2019 at 17:24, Richard Sandiford > wrote: > > Richard Sandiford writes: > > The aarch64_vector_pcs handling in > aarch64_hard_regno_call_part_clobbered > > checks whether the mode might be bigger than 16 bytes, since on SVE > > targets th

[patch] disentangle range_fold_*ary_expr into various pieces

I promised I would clean up the VRP/range-ops interface once the patch went in. I was afraid of shuffling things too much initially, because I was trying to keep to the original structure of extract_range_from_*ary_expr. Now that things are in place, it's easier to abstract things out, and cl

[PR target/85401] initialize the move cost table before using it (in another place, too)

On Tue, Oct 01, 2019 at 01:26:16PM -0600, Jeff Law wrote: > On 9/30/19 2:45 PM, co...@sdf.org wrote: > > On Mon, Sep 30, 2019 at 11:46:24AM -0400, Vladimir Makarov wrote: > >> Yes, the patch is mostly ok.  You can commit it into the trunk after > >> applying changes mentioned below. If you do not h

[PATCH], V4, patch #19 [Same as patch #8], Enable -mpcrel on Linux 64-bit systems

This is the same as patch #8, but re-issued after patches 9-15 replaced the old patch #4. This patch enables -mpcrel for the default on Linux 64-bit systems when compiling for -mcpu=future. If/when other OSs add support for prefixed instructions (including PC-relative instructions), it is simple

[PATCH] Adjust tr1::_Hashtable to work with std::allocator in C++20

In C++20 std::allocator will no longer define construct and destroy member functions, so using them needs to go via allocator_traits. * include/tr1/hashtable.h (tr1::_Hashtable::_M_allocate_node): Use __gnu_cxx::__alloc_traits for allocator construct function. (tr1::_Hash

[PATCH], V4, patch #18 [Same as patch #7], Use PADDI to add 34-bit constants

This is the same as patch #7, but was re-issued after patches 9-15 replaced the old patch #4. This patch generates the PADDI instruction to add 34-bit constant values on the 'future' system. Using all of the patches in this series, I have bootstrapped the compiler on a little endian power8 system

[PATCH], V4, patch #17 [Same as patch #6], Use PADDI to load up 32-bit SImode constants

This is the same as patch #6, but re-issued after patches 9-15 replaced the old patch #4. This patch supports using PADDI (PLI) to load up 32-bit SImode constants. Using all of the patches in this series, I have bootstrapped the compiler on a little endian power8 system and ran the regression tes

[PATCH], V4, patch #16 [Same as patch #5], Support DImode 34-bt constants

This is the same as patch #5, but re-issued after patches 9-15 replaced the old patch #4. This patch adds support for using PADDI (PLI) to load up 34-bit DImode constants. Using all of the patches in this series, I have bootstrapped the compiler on a little endian power8 system and ran the regres

[PATCH] Add missing gimple_call_set_fntype

Hi, when looking for detected call argument type incompatibilities I stumbled over a call to builtin_memcpy which originally was a call to builtin_memset but simplify_builtin_call changed it to the former without setting the gimple statement fntype. That's probably not a big deal but since I know

[PATCH], V4, patch #15 [part of patch #4.2], Make vector extract/insert support prefixed instructions

I was asked to split V4 patch #4.2 into smaller chuncks. This patch is one of 8 patches that were broken out from 4.2. Another patch from 4.2 to use SIGNED_16BIT_OFFSET_EXTRA_P has already been committed. This patch updates the functions that adjust a vector address to access a scalar element to

[patch] canonicalize unsigned [1,MAX] ranges into ~[0,0]

When I did the value_range canonicalization work, I noticed that an unsigned [1,MAX] and an ~[0,0] could be two different representations for the same thing. I didn't address the problem then because callers to ranges_from_anti_range() would go into an infinite loop trying to extract ~[0,0] in

[PATCH], V4, patch #14 [part of patch #4.2], Update vector 128-bit instruction sizes

I was asked to split V4 patch #4.2 into smaller chuncks. This patch is one of 8 patches that were broken out from 4.2. Another patch from 4.2 to use SIGNED_16BIT_OFFSET_EXTRA_P has already been committed. This patch adjusts the instruction size for prefixed addresses for vector 128-bit types. C

[PATCH], V4, patch #13 [part of patch #4.2], Update stack protect insns for prefixed addresses

I was asked to split V4 patch #4.2 into smaller chuncks. This patch is one of 8 patches that were broken out from 4.2. Another patch from 4.2 to use SIGNED_16BIT_OFFSET_EXTRA_P has already been committed. This patch makes the stack_protect_setdi and stack_protect_testdi insns work if the stack s

[PATCH], V4, patch #12 [part of patch #4.2], Update predicates

I was asked to split V4 patch #4.2 into smaller chuncks. This patch is one of 8 patches that were broken out from 4.2. Another patch from 4.2 to use SIGNED_16BIT_OFFSET_EXTRA_P has already been committed. This patch adds some new predicates that will be used in future patches. It also updates t

[PATCH], V4, patch #11 [part of patch #4.2], Adjust insn cost for prefixed instructions

I was asked to split V4 patch #4.2 into smaller chuncks. This patch is one of 8 patches that were broken out from 4.2. Another patch from 4.2 to use SIGNED_16BIT_OFFSET_EXTRA_P has already been committed. This patch adjusts the insn cost to treat prefixed instructions the same as non-prefixed in

Re: [PATCH] Fix -Wshadow=local warnings in rtl.h

Bernd Edlinger writes: > Hi, > > this fixes -Wshadow=local warnings in the RTL_FLAG_CHECKx macros, > which happen when this macro is used recursively in a macro > argument. The __typeof (RTX) const _rtx in the inner macro > expansions shadows the outer macro expansions. > > So reworked the macro

[PATCH], V4, patch #10 [part of patch #4.2], Set prefixed length for 128-bit non-vector type

I was asked to split V4 patch #4.2 into smaller chuncks. This patch is one of 8 patches that were broken out from 4.2. Another patch from 4.2 to use SIGNED_16BIT_OFFSET_EXTRA_P has already been committed. This patch sets the prefixed and non-prefixed instruction sizes for the non-vector 128-bit

[PATCH], V4, patch #9 [part of patch #4.2], Add prefixed address offset checks

I was asked to split V4 patch #4.2 into smaller chuncks. This patch is one of 8 patches that were broken out from 4.2. Another patch from 4.2 to use SIGNED_16BIT_OFFSET_EXTRA_P has already been committed. This patch adds checks in the various places that check whether an offset is valid to allow

Re: [PATCH] Add -Wshadow=local

On Fri, Oct 4, 2019 at 1:21 PM Bernd Edlinger wrote: > > On 10/4/19 12:43 PM, Richard Biener wrote: > > On Thu, Oct 3, 2019 at 5:17 PM Bernd Edlinger > > wrote: > >> > >> Hi, > >> > >> this adds -Wshadow=local to the GCC build rules. > >> > >> It is to be applied after all other patches in this

[PATCH][PR83534] C++17: typeinfo for noexcept function lacks noexcept information

bootstrapped and regtested on x86_64. ChangeLog: 2019-10-04 Kamlesh Kumar * rtti.c (get_tinfo_decl_dynamic): Do not call TYPE_MAIN_VARIANT for function. (get_typeid): Likewise. * g++.dg/rtti/pr83534.C: New Test. diff --git a/gcc/cp/rtti.c b/gcc/cp/rtti.c index

[PATCH] Add to precompiled header

* include/precompiled/stdc++.h: Include for C++20. * testsuite/17_intro/names.cc: Do not define 'e' for C++20. Tested powerpc64le-linux, committed to trunk. commit 006bdafbe76441914f0743ea6879a27f2fa2edfd Author: redi Date: Fri Oct 4 12:16:56 2019 + Add to precomp

Re: [PATCH] Fix -Wshadow=local warnings in dumpfile.h

Bernd Edlinger writes: > Hi, > > this fixes a -Wshadow=local warning when using AUTO_DUMP_SCOPE in > nested blocks. Since NAME i a string I cannot use it to create > a unique name for the auto_dump_scope object. > > So I used XCONCAT2 from good old symcat.h, to mangle the __LINE__ > macro into th

Re: [PATCH] Fix -Wshadow=local warnings in hash-table.h

Bernd Edlinger writes: > Hi, > > this fixes a few -Wshadow=local warnings in hash-table.h. > > Since values of type size_t are assigned here to int variables > an overflow may happen resulting in memory leaks or malfunction. > > > Bootstrapped and reg-tested on x86_64-pc-linux-gnu. > Is it OK for

Re: [PATCH] Fix -Wshadow=local warnings and a minor bug in expr.c

Bernd Edlinger writes: > @@ -4481,16 +4478,16 @@ emit_push_insn (rtx x, machine_mode mode, tree typ > /* Get the address of the stack space. >In this case, we do not deal with EXTRA separately. >A single stack adjust will do. */ > - poly_int64 offset; > +

Re: [PATCH] Fix -Wshadow=local warnings in genmatch.c

On Fri, Oct 04, 2019 at 11:52:11AM +, Bernd Edlinger wrote: > Admittedly I was also completely surprised that the if scope > extends to the else block. If that is in fact wrong, we ought to > fix that before I ruin the while code-base with changes like that. It is correct. http://eel.is/c++dr

Re: [PATCH] Fix -Wshadow=local warnings in genmatch.c

On 10/4/19 12:54 PM, Richard Biener wrote: > On Thu, Oct 3, 2019 at 5:18 PM Bernd Edlinger > wrote: >> >> Hi, >> >> this fixes -Wshadow=local warnings in genmatch.c itself and in generated >> files as well. >> >> The non-trivial part of this patch is renaming the generated local variables >> in t

  1   2   >