I've renamed some of the function names in range-ops we've been dragging
around to something more sensible. I've also adjusted the comments,
which were a bit dated.
Committed as obvious.
commit 9734aa22a81bf5a5f7c38631df67005ece63894b
Author: Aldy Hernandez
Date: Thu Oct 3 10:43:44 2019 +02
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 the (non-SVE) vector PCS only guarantees that the l
Yes, it is a 32-bit host and 32-bit target.
HOST_WIDE_INT is long long (on ARM).
Also it says 4 lines above that the type of value_long is unsigned long, so
lets use the specifier for unsigned long.
Jonas
-Ursprüngliche Nachricht-
Von: Segher Boessenkool
Gesendet: Sonntag, 22. September
On Fri, 27 Sep 2019 at 10:12, Richard Sandiford
wrote:
> Yuliang Wang writes:
> > Hi,
> >
> > This patch adds combining support for SVE2's shift-right accumulate
> instructions.
> >
> > Example snippet:
> >
> > #define IMM ...
> >
> > void foo (TYPE a, TYPE b, int n)
> > {
> > for (int i = 0;
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 recursively in a macro
> > argument. The __typeof (RTX) co
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2019-10-04 Richard Biener
PR tree-optimization/91982
* tree-vect-loop.c (vectorizable_live_operation): Also guard
against EXTRACT_LAST_REDUCTION.
* tree-vect-stmts.c (vect_transform_stmt):
On Thu, 3 Oct 2019, Jan Hubicka wrote:
-/* Return inlining_insns_single limit for function N */
+/* Return inlining_insns_single limit for function N. If HINT is true
+ scale up the bound. */
static int
-inline_insns_single (cgraph_node *n)
+inline_insns_single (cgraph_node *n, bool hint)
{
On Thu, 3 Oct 2019, Jan Hubicka wrote:
Tests that now fail, but worked before (15 tests):
g++.dg/tree-ssa/pr61034.C -std=gnu++14 scan-tree-dump-times fre3 ";;
Function" 1
g++.dg/tree-ssa/pr61034.C -std=gnu++14 scan-tree-dump-times fre3 "free" 14
g++.dg/tree-ssa/pr61034.C -std=gnu++14 sca
Hi,
The new test added as part of r276174 fails on an ilp32 target, which this
patch fixes. Thanks to Christophe Lyon for pointing this out.
Regression tested on aarch64-none-elf.
Best Regards,
Yuliang Wang
gcc/testsuite/ChangeLog:
2019-10-04 Yuliang Wang
* gcc.target/aarch64/sve
Hi Christophe,
Thanks for pointing this out, uploaded a fix.
Regards,
Yuliang
From: Christophe Lyon
Sent: 04 October 2019 09:25
To: Richard Sandiford
Cc: Yuliang Wang ; gcc-patches@gcc.gnu.org; nd
Subject: Re: [AArch64][SVE2] Shift-Right Accumulate combine patterns
On Fri, 27 Sep 2019 at
On Thu, Oct 3, 2019 at 1:42 AM Prathamesh Kulkarni
wrote:
>
> On Wed, 25 Sep 2019 at 09:17, Prathamesh Kulkarni
> wrote:
> >
> > On Mon, 16 Sep 2019 at 08:54, Prathamesh Kulkarni
> > wrote:
> > >
> > > On Mon, 9 Sep 2019 at 09:36, Prathamesh Kulkarni
> > > wrote:
> > > >
> > > > On Mon, 9 Sep 2
On Thu, Oct 3, 2019 at 4:33 PM Andrew Burgess
wrote:
>
> My motivation for the patch below comes from GDB. The binutils-gdb
> project maintains a copy of the contrib directory that it keeps in
> sync with upstream GCC, and patches to contrib/ are ideally first
> applied to GCC then backported to
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 series
> including the trivial ones are applied.
>
> Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
> Is it OK for trunk?
Yuliang Wang writes:
> Hi,
>
> The new test added as part of r276174 fails on an ilp32 target, which
> this patch fixes. Thanks to Christophe Lyon for pointing this out.
>
> Regression tested on aarch64-none-elf.
>
> Best Regards,
> Yuliang Wang
>
>
> gcc/testsuite/ChangeLog:
>
> 2019-10-04 Yulia
On 04/10/19 06:39 +0200, François Dumont wrote:
Hi
May I add this convenient function ? I'll also use it in coming
patches.
Note that I removed a template parameter in
__is_random_access_iter in C++11.
* include/bits/stl_iterator_base_types.h (__iterator_category_t):
Define
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 the gimple-match.c, to use different names for variables
On Thu, Oct 3, 2019 at 5:18 PM Bernd Edlinger wrote:
>
> Hi,
>
> this fixes a -Wshadow=local warning in the FOR_EACH_ALIAS macro
> that happens when it is used in lto/lto-partition.c in a nested
> block.
>
> For now to keep the patch simple, using the fact that the ALIAS
> parameter is always a si
On Thu, Oct 3, 2019 at 1:55 PM Vladislav Ivanishin wrote:
>
> Hi!
>
> This series implements the -Wclobbered warning on GIMPLE in place of the
> old RTL implementation.
>
> This cover letter contains a high-level explanation of what is going on
> and why. The new implementation itself is in the p
On 04/10/19 07:01 +0200, François Dumont wrote:
On 9/27/19 1:00 PM, Jonathan Wakely wrote:
On 19/07/19 23:37 +0200, François Dumont wrote:
It sounds reasonable to overload std::copy_n for istreambuf_iterator.
I wonder whether it's worth doing:
#if __cplusplus >= 201703L
if constexpr (is_sa
On 01.10.2019. 21:37, Jeff Law wrote:
> On 9/25/19 1:16 AM, Dragan Mladjenovic wrote:
>> From: "Dragan Mladjenovic"
>>
>> This fixes the issue by checking that addr's base reg is not part of dest
>> multiword reg instead just checking the first reg of dest.
>>
>> gcc/ChangeLog:
>>
>> 2019-09-25 D
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 series
>> including the trivial ones are applied.
>>
>> Bootstrapped and r
Bootstrapped / tested on x86_64-unknown-linux-gnu, applied.
Richard.
2019-10-04 Richard Biener
PR lto/91968
* tree.c (find_decls_types_r): Do not remove LABEL_DECLs from
BLOCK_VARS.
Index: gcc/tree.c
==
Which invokes undefined behavior.
Committed as obvious.
Richard.
2019-10-04 Richard Biener
* gcc.c-torture/execute/loop-3.c: Fix undefined behavior.
diff --git a/gcc/testsuite/gcc.c-torture/execute/loop-3.c
b/gcc/testsuite/gcc.c-torture/execute/loop-3.c
index e314a01b1f1..33eb188
> On Thu, 3 Oct 2019, Jan Hubicka wrote:
>
> > -/* Return inlining_insns_single limit for function N */
> > +/* Return inlining_insns_single limit for function N. If HINT is true
> > + scale up the bound. */
> >
> > static int
> > -inline_insns_single (cgraph_node *n)
> > +inline_insns_single
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
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
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;
> +
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
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
* 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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_
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
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'
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
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
> >
> >
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.
> >
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
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
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
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,
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
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
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
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
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
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
>
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
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
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?
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
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
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 -
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
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
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
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
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
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
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
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
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
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
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
> 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
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
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
>
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
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
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
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
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
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
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
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
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
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
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
I've merged trunk revision 276594 to the gccgo branch.
Ian
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
1 - 100 of 124 matches
Mail list logo
