On November 21, 2019 8:02:14 PM GMT+01:00, Richard Sandiford
wrote:
>Richard Biener writes:
>> We're doing quite some useless work here and in the case we
>> actually manage to "vectorize" it, we've done a no-op (bb-slp-42.c).
>
>The point of that test was that we could share a vector load at b
On November 21, 2019 9:27:15 PM GMT+01:00, Jan Hubicka wrote:
>Hi,
>here is updated patch. Bootstrapped/regtested x86_64-linux, OK?
Ok.
Richard.
>Honza
>
> * ggc-page.c (ggc_collect): Call memory_block_pool::trim.
> * memory-block.cc (memory_block_pool::clear_free_list): Rename
Hi Segher,
Update the code as you wish, Thanks:
P9LE generated instruction is not worse than P8LE.
mtvsrdd;xxlnot;stxv vs. not;not;std;std.
Update the test case to fix failures.
v4:
Define and use check_effective_target_xxx etc.
power9+: power9, power10 ...
power8: power8 only.
Honza, Martin,
Hope your more comments on this patch. Not sure you base option on it. I
think this can be a start point for
recursive versioning. And later we definitely need further cost-model tuning
not only on this, but also whole
ipa-cp to enable more aggressive cloning.
Thanks,
Feng
On Wed, 2019-11-20 at 11:35 -0500, Lewis Hyatt wrote:
> My apologies, that patch had whitespace issues. Corrected version
> attached.
>
> On Wed, Nov 20, 2019 at 11:27:08AM -0500, Lewis Hyatt wrote:
> > On Tue, Nov 19, 2019 at 12:30:39PM -0500, David Malcolm wrote:
> > > Thanks for posting this
attribs.c has code to ignore all scoped attributes appertaining to
types except when they are part of the definition of that type.
I think the premise of that code is incorrect, and its presence is a
bug; such attributes are clearly valid in both C and C++, which
explicitly specify that
> On Nov 21, 2019, at 7:42 PM, Segher Boessenkool
> wrote:
>
> ...
> Maybe i386 should implement the insn_cost hook as well? For most targets
> that is a lot simpler to get right than rtx_cost, but allowing memory in
> many insns and all the different insn lengths complicates matters. At
>
On 11/21/19 3:38 PM, Jeff Law wrote:
On 11/21/19 10:11 AM, Martin Sebor wrote:
Attached is another revision of this enhancement, this one
incorporating Richard's request for a more efficient encoding
of the attributes to enable faster parsing. There is just one
attribute called access, with
On 11/22/19 1:42 AM, Segher Boessenkool wrote:
> On Thu, Nov 21, 2019 at 02:36:53PM +0100, Bernd Schmidt wrote:
>> Thanks. Just FYI, this is held up a little. I decided I'd also test on
>> x86, and there it shows a case where ix86_rtx_cost misses something: the
>> i386/pr30315.c testcase wants to
Thank you for the review!
- I moved the concepts back into the class and changed them to
template aliases because class local concepts aren't a thing that
works.
+ They are not inline constexpr bools because that ICE's GCC
pretty hard, as you explained to me earlier, so we use ::value in
On 11/21/19 2:24 PM, Dimitar Dimitrov wrote:
On Thu, 21 Nov 2019, 20:09:23 EET Martin Sebor wrote:
On 11/21/19 10:11 AM, Dimitar Dimitrov wrote:
One of the passed arguments is actually a string with size 4 ("123").
Adjust the destination buffer accordingly.
gcc/testsuite/ChangeLog:
On Thu, Nov 21, 2019 at 02:36:53PM +0100, Bernd Schmidt wrote:
> On 11/13/19 5:16 PM, Segher Boessenkool wrote:
> > On Wed, Nov 13, 2019 at 02:13:48PM +0100, Bernd Schmidt wrote:
> >> Also, it does not compute costs for jump
> >> insns, so they are always set to zero. As a consequence, any
On Thu, 21 Nov 2019, Harald van Dijk wrote:
> On 21/11/2019 22:15, Joseph Myers wrote:
> > On Thu, 21 Nov 2019, Harald van Dijk wrote:
> >
> > > Hi,
> > >
> > > The patch to make -fcommon the default introduces a bogus claim into the
> > > GCC
> > > documentation. I already raised this issue on
On 21/11/2019 22:15, Joseph Myers wrote:
On Thu, 21 Nov 2019, Harald van Dijk wrote:
Hi,
The patch to make -fcommon the default introduces a bogus claim into the GCC
documentation. I already raised this issue on the patch itself, where it was
unfortunately ignored. Please find attached a
Thanks for your feedback on this Richard,
Back on this after a few days away.
> On 15 Nov 2019, at 16:37, Richard Earnshaw (lists)
> wrote:
> My first thought is that if we need a permanent reservation it would be
> better to put this at the top of the list. r16 and r17 have defined ABI
> On Nov 21, 2019, at 4:09 PM, Richard Sandiford
> wrote:
>
> This probably isn't helpful, sorry, but the fact that the second point
> is a (reasonable) area of debate IMO shows the problems with doing
> the first point. If we go for (1) but not (2), everyone will need
> to specify the four
On Fri, Aug 18, 2017 at 12:17 PM Andrew Pinski wrote:
>
> Like https://gcc.gnu.org/ml/gcc-patches/2010-09/msg00060.html for
> PowerPC, we should do something similar for aarch64. This pattern
> does show up in SPEC CPU 2006 in astar but I did not look into
> performance improvement of it though.
On 11/21/19 1:33 AM, Richard Biener wrote:
>
> This gets away with the top caller of sbitmap_alloc in a tramp3d
> compile which is pre_and_rev_post_order_compute_fn (yeah, we're
> invoking that way too often). I've introduced those auto_*_flag
> things for region based VN but I think it makes
On 11/21/19 10:11 AM, Martin Sebor wrote:
> Attached is another revision of this enhancement, this one
> incorporating Richard's request for a more efficient encoding
> of the attributes to enable faster parsing. There is just one
> attribute called access, with the rest being arguments. This
>
On Thu, 21 Nov 2019, Harald van Dijk wrote:
> Hi,
>
> The patch to make -fcommon the default introduces a bogus claim into the GCC
> documentation. I already raised this issue on the patch itself, where it was
> unfortunately ignored. Please find attached a followup patch to remove this
> bogus
On Thu, 21 Nov 2019, Tamar Christina wrote:
> Hi Joseph,
>
> > FE_TONEAREST is the default rounding mode, so it would be better just to
> > remove the fesetround call and include and fenv effective-target
> > and -frounding-math option and let this test run for all configurations with
> >
Hi!
On Wed, Nov 20, 2019 at 02:58:33PM +0800, luoxhu wrote:
> v3:
> Define and use check_effective_target_xxx etc.
> pre_power8: ... power6, power7.
> power8: power8 only.
> post_power8: power8, power9 ...
> post_power9: power9, power10 ...
"post_xxx" does not include "xxx", normally.
Maybe was
Szabolcs Nagy writes:
> On 14/11/2019 20:23, Szabolcs Nagy wrote:
>> Sorry v2 had a bug.
>>
>> v2: added documentation and tests.
>> v3: fixed expand_simd_clones so different isa variants are actually
>> generated.
>>
>> GCC currently supports two ways to declare the availability of vector
On Thu, 21 Nov 2019, 20:09:23 EET Martin Sebor wrote:
> On 11/21/19 10:11 AM, Dimitar Dimitrov wrote:
> > One of the passed arguments is actually a string with size 4 ("123").
> > Adjust the destination buffer accordingly.
> >
> > gcc/testsuite/ChangeLog:
> >
> > 2019-11-21 Dimitar Dimitrov
>
On 21/11/19 13:33 -0500, JeanHeyd Meneide wrote:
This is an attempt to use concepts and constraints rather than
ranges::. It builds and run the tests I ran on x86_64 Linux decently
(albeit I'm still new at doing this). I wanted to get a feel for
whether or not this had been done right:
Thanks
Segher Boessenkool writes:
> On Wed, Nov 20, 2019 at 06:20:34PM +, Richard Sandiford wrote:
>> > Why don't you use DF for the DU chains?
>>
>> The problem with DF_DU_CHAIN is that it's quadratic in the worst case.
>
> Oh, wow.
>
>> fwprop.c gets around that by using the MD problem and having
Hi,
here is updated patch. Bootstrapped/regtested x86_64-linux, OK?
Honza
* ggc-page.c (ggc_collect): Call memory_block_pool::trim.
* memory-block.cc (memory_block_pool::clear_free_list): Rename to ...
(memory_block_pool::reduce_free_list): ... this one.
On Thu, 21 Nov 2019 at 13:42, Richard Biener wrote:
>
> On Thu, 21 Nov 2019, Prathamesh Kulkarni wrote:
>
> > Hi,
> > The issue seems to happen with -O1, because header only contains phi:
> >
> >[local count: 118111600]:
> > # iter.12_9 = PHI <0(2), iter.12_10(10)>
> >
> > and thus we hit
Changes after the -fcommon switch.
These two tests are explicitly testing the use of specific sections or
assembler directives for data that is placed in common. Append
-fcommon to the flags to restore them.
tested on x86_64-darwin16,
applied to mainline,
thanks
Iain
gcc/testsuite/ChangeLog:
It turns out that all of my testing of the analyzer has been with
--enable-host-shared; on building without it, the link of the plugin
failed with messages like this for all of the .o file:
/usr/bin/ld: analyzer/analysis-plan.o: relocation R_X86_64_32 against
`.rodata' can not be used when
Hi Nick,
Thanks for the comments.
Nicholas Krause writes:
>> Index: gcc/passes.def
>> ===
>> --- gcc/passes.def 2019-10-29 08:29:03.224443133 +
>> +++ gcc/passes.def 2019-11-17 23:15:31.200500531 +
>> @@ -437,7 +437,9
Hi,
The patch to make -fcommon the default introduces a bogus claim into the
GCC documentation. I already raised this issue on the patch itself,
where it was unfortunately ignored. Please find attached a followup
patch to remove this bogus claim.
-fcommon was claimed to be incompatible with
On 11/20/19 4:15 PM, Joseph Myers wrote:
> Various bad uses of the [[fallthrough]] attribute are constraint
> violations in C2x, so need pedwarns rather than warnings.
>
> This patch duly turns the relevant warnings into pedwarns. The
> relevant code is not specific to C, and does not know which
On 11/21/19 9:35 AM, Claudiu Zissulescu wrote:
> PING
>
> On Mon, Nov 11, 2019 at 4:42 PM Claudiu Zissulescu wrote:
>>
>> Hi,
>>
>> Fix ARC specific tests by improving the matching pattern and adding
>> the missing functionality in arc.exp
>>
>>
>> OK to appy?
>> Claudiu
>>
>>
>> gcc/tests
>>
Richard Biener writes:
> We're doing quite some useless work here and in the case we
> actually manage to "vectorize" it, we've done a no-op (bb-slp-42.c).
The point of that test was that we could share a vector load at b with
four constructors, so it's not really a no-op:
On 11/17/19 6:35 PM, Richard Sandiford wrote:
(It's 23:35 local time, so it's still just about stage 1. :-))
While working on SVE, I've noticed several cases in which we fail
to combine instructions because the combined form would need to be
placed earlier in the instruction stream than the
This is an attempt to use concepts and constraints rather than
ranges::. It builds and run the tests I ran on x86_64 Linux decently
(albeit I'm still new at doing this). I wanted to get a feel for
whether or not this had been done right:
Thoughts?
diff --git a/libstdc++-v3/include/Makefile.am
Joseph Myers wrote:
On Mon, 18 Nov 2019, Joseph Myers wrote:
On Sat, 16 Nov 2019, Iain Sandoe wrote:
Joseph Myers wrote:
This patch adds support for the C2x [[]] attribute syntax to the C
front end.
gcc.dg/gnu2x-attrs-1.c: New tests.
This test fails on targets without symbol alias
On Mon, 18 Nov 2019, Joseph Myers wrote:
> On Sat, 16 Nov 2019, Iain Sandoe wrote:
>
> > Joseph Myers wrote:
> >
> > > This patch adds support for the C2x [[]] attribute syntax to the C
> > > front end.
> >
> > > gcc.dg/gnu2x-attrs-1.c: New tests.
> >
> > This test fails on targets
Hi Joseph,
> FE_TONEAREST is the default rounding mode, so it would be better just to
> remove the fesetround call and include and fenv effective-target
> and -frounding-math option and let this test run for all configurations with
> int128 support.
>
Hmm right, doing makes the execution of
On Wed, Nov 20, 2019 at 11:17:11PM +, Segher Boessenkool wrote:
> We currently expand various floating point comparisons early, to some
> sequences with cror insns and the like. This doesn't optimize well.
>
> Change that to allow any of the 14 floating point comparisons in the
> instruction
On 11/21/19 10:11 AM, Dimitar Dimitrov wrote:
One of the passed arguments is actually a string with size 4 ("123").
Adjust the destination buffer accordingly.
gcc/testsuite/ChangeLog:
2019-11-21 Dimitar Dimitrov
* gcc.dg/strlenopt-66.c (test_strncmp_a4_cond_a5_a3_n): Fix array
Hi Srinath,
On 11/21/19 4:32 PM, Srinath Parvathaneni wrote:
Hello,
This patch fixes arm acle testcase crc_hf_1.c by modifying the
compiler options directive.
Regression tested on arm-none-eabi and found no regressions.
Ok for trunk? If ok, please commit on my behalf, I don't have the
On 11/21/19 3:59 AM, Richard Sandiford wrote:
Sandra Loosemore writes:
This patch is for PR target/92499, a bug reported by GLIBC maintainers
against nios2 target. The initial failure symptom was a linker error
resulting from use of GP-relative addressing on an object that wasn't
allocated in
Hi!
I've backported following 16 commits from trunk to 8.x branch,
bootstrapped/regtested on x86_64-linux and i686-linux and committed for 8.4.
Jakub
2019-11-21 Jakub Jelinek
Backported from mainline
2019-08-02 Jakub Jelinek
* quadmath.h (M_Eq, M_LOG2Eq,
One of the passed arguments is actually a string with size 4 ("123").
Adjust the destination buffer accordingly.
gcc/testsuite/ChangeLog:
2019-11-21 Dimitar Dimitrov
* gcc.dg/strlenopt-66.c (test_strncmp_a4_cond_a5_a3_n): Fix array size.
Signed-off-by: Dimitar Dimitrov
---
Attached is another revision of this enhancement, this one
incorporating Richard's request for a more efficient encoding
of the attributes to enable faster parsing. There is just one
attribute called access, with the rest being arguments. This
is transformed to access (mode-string) where the
On Nov 21 2019, Palmer Dabbelt wrote:
> It's always initialized: the only path by which riscv_classify_address()
> doesn't initialize it is on an error,
That is not true. Only if GET_CODE (x) == LO_SUM, but then it is only
accessed if addr.type is ADDRESS_LO_SUM, which is equivalent.
Andreas.
On Mon, 18 Nov 2019 09:58:19 PST (-0800), l...@redhat.com wrote:
On 11/18/19 6:17 AM, Martin Liška wrote:
Hi.
The patch is about yet another bootstrap -Wmaybe-uninitialized warning.
I've just tested that on risv64 cross compiler with latest trunk.
Ready to be installed?
Thanks,
Martin
This fixes two issues with the recently added absent-optional patch for
use_device_…
(a) For nonallocatable, nonpointer arrays the data component of the
array descriptor is replaced by a local variable – if the argument is
absent, this variable is not initialized and, unless it is NULL, a
PING
On Mon, Nov 11, 2019 at 4:42 PM Claudiu Zissulescu wrote:
>
> Hi,
>
> Fix ARC specific tests by improving the matching pattern and adding
> the missing functionality in arc.exp
>
>
> OK to appy?
> Claudiu
>
>
> gcc/tests
> -xx-xx Claudiu Zissulescu
>
> *
It seems it leads to this commit
c1760d8b599ddd7253b3a72f5219f0457f8d3130, but I need to double check.
Thank you Jeff,
Claudiu
On Thu, Nov 21, 2019 at 6:30 PM Jeff Law wrote:
>
> On 11/21/19 9:21 AM, Claudiu Zissulescu wrote:
> > Thank you for the feedback.
> >
> > Regarding the error, it is
Hello,
This patch fixes arm acle testcase crc_hf_1.c by modifying the compiler options
directive.
Regression tested on arm-none-eabi and found no regressions.
Ok for trunk? If ok, please commit on my behalf, I don't have the commit rights.
Thanks,
Srinath.
gcc/testsuite/ChangeLog:
On 11/21/19 9:21 AM, Claudiu Zissulescu wrote:
> Thank you for the feedback.
>
> Regarding the error, it is just spins when it tries to vectorize a
> loop in tree-vect-slp.c. Quite strange ... I will look into asap. If
> you have any hint please let me know :)
Nope. Haven't looked at it at all
Thank you for the feedback.
Regarding the error, it is just spins when it tries to vectorize a
loop in tree-vect-slp.c. Quite strange ... I will look into asap. If
you have any hint please let me know :)
Claudiu
On Wed, Nov 20, 2019 at 7:41 PM Jeff Law wrote:
>
> On 11/19/19 2:02 AM, Claudiu
I managed to somehow commit sth bogus on trunk (the branch is correct).
Bootstrapped / tested on x86_64-unknown-linux-gnu, applied.
Richard.
2019-11-21 Richard Biener
PR tree-optimization/92596
* tree-vect-slp.c (vect_build_slp_tree): Fix pasto.
*
Hi,
this patch fixes remaining quadratic behaviour on inlining into large functions
(in gcc the avrage function we inline into has 498 callees) by avoiding
re-checking inlinability of the call edges in the caller of inline call that
was not affected by inlining.
This is not complete no-op as can
Add a missing extern to ensure the test passes with -fno-common.
Committed as obvious.
ChangeLog:
2019-11-21 Wilco Dijkstra
testsuite/
* gfortran.dg/global_vars_f90_init_driver.c: Add missing extern.
--
diff --git a/gcc/testsuite/gfortran.dg/global_vars_f90_init_driver.c
On 11/21/19 3:59 AM, Richard Sandiford wrote:
Sandra Loosemore writes:
This patch is for PR target/92499, a bug reported by GLIBC maintainers
against nios2 target. The initial failure symptom was a linker error
resulting from use of GP-relative addressing on an object that wasn't
allocated in
On 21/11/2019 13:10, Martin Liška wrote:
> On 11/20/19 6:40 PM, Matthew Malcomson wrote:
>> On 20/11/2019 14:29, Martin Liška wrote:
>>> On 11/7/19 7:37 PM, Matthew Malcomson wrote:
I have rebased this series onto Martin Liska's patches that take the
most
recent libhwasan from
This cuts down the number significantly coming from
estimate_numbers_of_iterations where even loop exits
may not be computed in some callers and thus the single_exit ()
early-outs do not work.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2019-11-21 Richard Biener
On Thu, 21 Nov 2019, Tamar Christina wrote:
> Hi All,
>
> The test fp-int-convert-timode-1.c uses FE_TONEAREST without
> actually checking if the target has defined it.
>
> Like the rest of the tests I now add a check to see if the target
> has actually implemented it.
FE_TONEAREST is the
Hi Richard,
On 11/21/19 3:09 PM, Richard Biener wrote:
So I think what you'd need to do is make 'i' marked as TYPE_RESTRICT
then. I think we don't yet handle it but it means that bar() may not
modify 'i' but via 'i' (but it doesn't get 'i' as a parameter).
Okay, that would be then the
Hi Bernd!
This should work:
# binary default
deb http://ftp.ports.debian.org/debian-ports/ unstable main
deb http://incoming.ports.debian.org/buildd/ unstable main
deb http://ftp.ports.debian.org/debian-ports/ unreleased main
# source
deb-src http://ftp.debian.org/debian/ unstable main
deb-src
On 11/21/19 3:21 AM, Richard Biener wrote:
This eliminates one of the top callers for malloc when building
tramp3d. We're using alloc-pools for other structures already
so it looks somewhat obvious to also do for lra_insn_recog_data.
Bootstrapped / tested on x86_64-unknown-linux-gnu.
OK?
On Wed, 20 Nov 2019, Jan Hubicka wrote:
> Hi,
> sadly this patch seems to trigger false positive
> ../../gcc/vec.h:311:10: error: attempt to free a non-heap object ???@Xa???@Y
> [-Werror=free-nonheap-object]
>
> which is about vec destructor freeing heap allocated memory if the
> vector was
On Wed, Nov 20, 2019 at 4:28 PM Richard Sandiford
wrote:
>
> Allowing mixed vector sizes broke the assumption in the following assert,
> since it's now possible for different accesses to require different
> levels of alignment:
>
> /* FORNOW: use the same mask to test all
Hi All,
The test fp-int-convert-timode-1.c uses FE_TONEAREST without
actually checking if the target has defined it.
Like the rest of the tests I now add a check to see if the target
has actually implemented it.
This fixed Arm newlib target failures.
Regtested on aarch64-none-elf and
On Wed, Nov 20, 2019 at 1:39 PM Richard Sandiford
wrote:
>
> In vect-alias-check-1.c we unroll the inner loop and then vectorise
> the stores at a[c + 1][b]. Since the access has no guaranteed
> alignemnt, we need a realignment mechanism or support for unaligned
> accesses in order to vectorise.
On Thu, Nov 21, 2019 at 2:16 PM Tobias Burnus wrote:
>
> Hi Richard,
>
> On 11/21/19 1:16 PM, Richard Biener wrote:
> > OK, so I found it, it's handled via SSA_NAME_POINTS_TO_READONLY_MEMORY
> > which is initialized during the rewrite into SSA form from the
> > information given by the "fn spec"
On Thu, Nov 21, 2019 at 1:07 PM Richard Sandiford
wrote:
>
> gcc.target/aarch64/sve/clastb_[57].c started failing after the increase
> in the cost of vec_to_scalar (r278452). The problem is that we were
> double-counting the cost of the CLASTB: once in vect_model_reduction_cost
> as a
On Thu, Nov 21, 2019 at 1:08 PM Richard Sandiford
wrote:
>
> This patch fixes some cases in which we weren't checking whether we had
> a vector mode before calling related_vector_mode or before making vector
> optab queries.
>
> Tested on aarch64-linux-gnu and x86_64-linux-gnu. OK to install?
On 11/21/19 1:30 PM, Matthias Klose wrote:
>
> that would be apt build-dep gcc-9. The former would only install the build
> dependencies of the gcc-defaults package.
That gets me
E: You must put some 'source' URIs in your sources.list
where /etc/apt/sources.list looks like
deb
On 11/13/19 5:16 PM, Segher Boessenkool wrote:
> On Wed, Nov 13, 2019 at 02:13:48PM +0100, Bernd Schmidt wrote:
>> Also, it does not compute costs for jump
>> insns, so they are always set to zero. As a consequence, any possible
>> substitution is performed if a combination into a jump is
Hi Richard, hi all,
On 11/21/19 2:16 PM, Tobias Burnus wrote:
I wonder whether there is a 'fn attr' which can tell that the first
argument of 'print_i' does not cause the address of 'i' escape.
I think one needs two attributes, one which tells that the address of
the object itself does not
Andi Kleen writes:
Ping!
> From: Andi Kleen
>
> [v4: Rebased on current tree. Avoid some redundant log statements
> for locals and a few other fixes. Fix some comments. Improve
> documentation. Did some studies on the debug information quality,
> see below]
>
> Add a new pass to automatically
Hi Richard,
On 11/21/19 1:16 PM, Richard Biener wrote:
OK, so I found it, it's handled via SSA_NAME_POINTS_TO_READONLY_MEMORY
which is initialized during the rewrite into SSA form from the
information given by the "fn spec" attribute […] so when the frontend
sets "fn spec" from the intent it
Hi Segher,
on 2019/11/20 下午10:06, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Nov 20, 2019 at 03:31:36PM +0800, Kewen.Lin wrote:
> Yeah. Just doing can_create_pseudo in the insn condition (and in the
> split condition, via &&) will work -- there just is this window of
> failure you should be
On 11/20/19 6:40 PM, Matthew Malcomson wrote:
On 20/11/2019 14:29, Martin Liška wrote:
On 11/7/19 7:37 PM, Matthew Malcomson wrote:
I have rebased this series onto Martin Liska's patches that take the most
recent libhwasan from upstream LLVM.
On 11/20/19 4:45 PM, Matthew Malcomson wrote:
On 20/11/2019 14:33, Martin Liška wrote:
On 11/13/19 4:24 PM, Matthew Malcomson wrote:
On 12/11/2019 12:08, Martin Liška wrote:
On 11/11/19 5:03 PM, Matthew Malcomson wrote:
Ah!
My apologies -- I sent up a series with a few documentation
On 11/20/19 10:12 PM, David Malcolm wrote:
On Wed, 2019-11-20 at 16:07 +0100, Martin Liška wrote:
On 11/20/19 4:02 PM, David Malcolm wrote:
On Wed, 2019-11-20 at 15:51 +0100, Martin Liška wrote:
On 11/20/19 3:49 PM, David Malcolm wrote:
On Wed, 2019-11-06 at 11:30 +0100, Martin Liska wrote:
On 20.11.19 22:38, Richard Earnshaw wrote:
> On 20/11/2019 20:48, Bernd Schmidt wrote:
>> On 11/20/19 8:27 PM, Mikael Pettersson wrote:
>>> On Wed, Nov 20, 2019 at 3:16 PM Bernd Schmidt
>>> wrote:
Probably best to just run tests on stage1 and hope something shows up.
>>>
>>> Ok, how do I
> Hi!
>
> This patch doesn't fix the actual bug somewhere else, where inserting
> stmts on the edge between resx and corresponding landing pad confuses
> ehcleanup2, but attempts to restore previous behavior in the heuristics,
> which is IMHO desirable too (and makes the bug latent).
> r254698
On Thu, Nov 21, 2019 at 10:35 AM Tobias Burnus wrote:
>
> On 11/20/19 10:35 PM, Thomas König wrote:
> >> Is there a risk of performance regressions due to higher register
> >> pressure?
>
> richi points out (on IRC) that ideally LTO IPA opts would promote the
> call-by reference to call-by value
This patch fixes some cases in which we weren't checking whether we had
a vector mode before calling related_vector_mode or before making vector
optab queries.
Tested on aarch64-linux-gnu and x86_64-linux-gnu. OK to install?
Richard
2019-11-21 Richard Sandiford
gcc/
PR
gcc.target/aarch64/sve/clastb_[57].c started failing after the increase
in the cost of vec_to_scalar (r278452). The problem is that we were
double-counting the cost of the CLASTB: once in vect_model_reduction_cost
as a vec_to_scalar and once in vectorizable_condition as a plain
vector_stmt.
Bumping the cost of vec_to_scalar made the .s loop in
gcc.target/aarch64/sve2/whilerw_1.c use a runtime profitability check,
like the .d version already did. Since the cost model isn't really
being tested here, the most robust fix seemed to be to disable it,
which I should really have done from
The following avoids heap allocations for setting up the loop iterator
in most cases. It also avoids re-allocating the PHI vector all the
time in mark_phi_for_rewrite. Plus it fixes some of the slowness
we observe in compute_idf which uses a) bad iteration order and
b) a worklist
On Thu, Nov 21, 2019 at 11:40:33AM +, Wilco Dijkstra wrote:
> Hi Rainer,
>
> >> ld: warning: symbol 'err' has differing types:
> >> (file /var/tmp//ccWQCyMc.o type=OBJT; file /lib/libc.so
> >> type=FUNC);
> >> /var/tmp//ccWQCyMc.o definition taken
>
> So are glob and err
Hi Rainer,
>> ld: warning: symbol 'err' has differing types:
>> (file /var/tmp//ccWQCyMc.o type=OBJT; file /lib/libc.so type=FUNC);
>> /var/tmp//ccWQCyMc.o definition taken
So are glob and err somehow exported as globals by your GLIBC? I don't think
those
are standard
On Thu, Nov 21, 2019 at 12:03:19PM +0100, Rainer Orth wrote:
> I'm seeing those, too, plus the following that are apparently only
> diagnosed by Solaris ld:
>
> +FAIL: gcc.c-torture/execute/20030913-1.c -O0 (test for excess errors)
> +FAIL: gcc.c-torture/execute/20030913-1.c -O1 (test for
Hi Jakub,
> On Thu, Nov 21, 2019 at 01:41:47AM +0100, Rainer Orth wrote:
>> Same on sparc-sun-solaris2.11 and i386-pc-solaris2.11.
>>
>> There where quite a number of non-Go regressions all over the place.
>> Many are like this:
>>
>> FAIL: gcc.c-torture/execute/complex-6.c -O0 (test for
Please find attached an updated version of the patch originally
submitted on 15th November.
The comparisons with Holleriths are no only possible when using -fdec.
The test cases have been revised to check for errors when -fdec is not used.
OK to commit in stage 3 or delay until stage 1 in the
Sandra Loosemore writes:
> This patch is for PR target/92499, a bug reported by GLIBC maintainers
> against nios2 target. The initial failure symptom was a linker error
> resulting from use of GP-relative addressing on an object that wasn't
> allocated in the small data section. It turns out
On Thu, 21 Nov 2019, Jakub Jelinek wrote:
> Hi!
>
> This patch doesn't fix the actual bug somewhere else, where inserting
> stmts on the edge between resx and corresponding landing pad confuses
> ehcleanup2, but attempts to restore previous behavior in the heuristics,
> which is IMHO desirable
Hi!
This patch doesn't fix the actual bug somewhere else, where inserting
stmts on the edge between resx and corresponding landing pad confuses
ehcleanup2, but attempts to restore previous behavior in the heuristics,
which is IMHO desirable too (and makes the bug latent).
r254698 changed:
if
On Nov 19, 2019, Bernd Edlinger wrote:
> My question to you is this: can you explain, given the following debug
> info, extracted by readelf from alias.c, why the address 0x6e11 is in
> the inlined subroutine and *not* in the get_alias_set function?
The long version of the explanation is in
Hi!
While reading code (in this case tree-ssa-sink.c) I've noticed two further
spelling errors, fixed thusly, committed as obvious to trunk.
2019-11-21 Jakub Jelinek
* ipa-fnsummary.h (enum ipa_hints_vals): Fix comment typo,
preffer -> prefer.
* ipa-inline.c
On 11/20/19 10:35 PM, Thomas König wrote:
Is there a risk of performance regressions due to higher register
pressure?
richi points out (on IRC) that ideally LTO IPA opts would promote the
call-by reference to call-by value – but is not sure that it indeed
happens. [In any case, Linux distros
On Thu, Nov 21, 2019 at 12:31 AM Janne Blomqvist
wrote:
>
> On Thu, Nov 21, 2019 at 12:18 AM Janne Blomqvist
> wrote:
> >
> > On Wed, Nov 20, 2019 at 11:35 PM Thomas König wrote:
> > > (Why do we zero %eax
> > > before each call? It should not be a variadic call right?)
> >
> > Not sure. Maybe
1 - 100 of 109 matches
Mail list logo
