Hi,
As discussed in PR90078, this patch checks possible infinite_cost overflow in
ivopts.
Also as discussed, overflow happens mostly because of cost scaling wrto
bb_freq/loop_freq.
For the moment, we only implement capping in comp_cost operators, while in next
stage1, we may instead implement cap
Hi,
This patch adds missing macros that the dmd front-end makes use of, as
seen on one of the BSDs where the include for int_const.h is guarded,
and defines any __unix__ system as being POSIX.
Bootstrapped and regression tested on x86_64-linux-gnu.
Committed to trunk as r270403.
--
Iain
---
20
On 4/15/19 7:12 AM, Christophe Lyon wrote:
On Sat, 13 Apr 2019 at 00:38, Martin Sebor wrote:
On 4/12/19 3:42 PM, Jakub Jelinek wrote:
On Fri, Apr 12, 2019 at 10:45:25AM -0600, Jeff Law wrote:
gcc/ChangeLog:
PR c/89797
* targhooks.c (default_vector_alignment): Avoid assuming
a
While testing the fix I also discovered that operator== assumes the
elements are comparable with operator!= which is not required.
PR libstdc++/90105
* include/bits/forward_list.h (operator==): Do not use operator!= to
compare elements.
(forward_list::sort(Comp)):
Hi,
This patch updates the build and invocation of idgen and impcnvgen,
ensuring that they are removed when cleaning the build directory.
Added BUILD_LIBDEPS on the link command, which is necessary when the
system installed compiler is not gcc, as noticed when testing
compilation on OpenBSD.
Boo
* include/pstl/algorithm_impl.h
(__internal::__brick_equal): use "4 iterator" version of
std::equal().
(__internal::__brick_equal): use simd for random access
iterators on unsequenced execution policies.
(__internal::__pattern_equal): add "4 iterator
Hi!
The following PR has been fixed by the changes to evaluate constexpr
functions on pre-folding/genericization trees.
I've tested the following testcase on x86_64-linux and committed to trunk as
obvious, so that we don't regress it.
2019-04-16 Jakub Jelinek
PR c++/86953
* g
On Tue, Apr 16, 2019 at 06:21:25PM +0200, Eric Botcazou wrote:
> > The runtime check assures that at runtime, the upper 32 bits of pseudo 104
> > must be always 0 (in this case, in some other case could be sign bit
> > copies).
>
> OK, as Richard pointed out, that's not sufficient if we allow...
>
On Tue, Apr 16, 2019 at 07:50:35PM +0200, Jakub Jelinek wrote:
> On Fri, Apr 12, 2019 at 05:10:48PM +0100, Ramana Radhakrishnan wrote:
> > No, that's not right. we should get rid of this.
>
> Here is a patch for that.
>
> Bootstrapped/regtested on armv7hl-linux-gnueabi, ok for trunk?
And here is
On Fri, Apr 12, 2019 at 05:10:48PM +0100, Ramana Radhakrishnan wrote:
> No, that's not right. we should get rid of this.
Here is a patch for that.
Bootstrapped/regtested on armv7hl-linux-gnueabi, ok for trunk?
2019-04-16 Jakub Jelinek
PR target/89093
* config/arm/arm.c (arm_v
In looking at the IRA dumps from PR87871, I see that we're missing some \n's
in the output of an allocno's conflicts and we fail to even print the lines
for the hard reg conflicts. This causes us to start printing the copy and
shuffle info on the same line as the alloc conflicts, like so:
;; a5(r
On April 16, 2019 6:14:45 PM GMT+02:00, Jakub Jelinek wrote:
>On Tue, Apr 16, 2019 at 04:10:11PM +, Michael Matz wrote:
>> I was quickly testing also with some early-outs but didn't get
>conclusive
>> performance results (but really only superficial testing) so I'm not
>> proposing it, like
On Tue, 16 Apr 2019 at 15:18, Jonathan Wakely wrote:
>
> On 16/04/19 14:08 +0100, Nina Dinka Ranns wrote:
> >Tested on Linux-PPC64
> >Adding noexcept-specification on tuple constructors (LWG 2899)
>
> Thanks, Nina!
>
> This looks great, although as I think Ville has explained we won't
> commit it
On April 16, 2019 6:10:11 PM GMT+02:00, Michael Matz wrote:
>Hi,
>
>On Tue, 16 Apr 2019, Richard Biener wrote:
>
>> Comments?
>
>I was quickly testing also with some early-outs but didn't get
>conclusive
>performance results (but really only superficial testing) so I'm not
>proposing it, like so
Hi Mike,
> On 16 Apr 2019, at 21:05, Mike Stump wrote:
>
>> On Apr 15, 2019, at 11:59 PM, Iain Sandoe wrote:
>> OK for trunk (after wider testing)?
>
> Didn't we make you a Darwin maintainer yet?
/me is willing .. (given the usual comment about finite time available, of
course)
> Ok.
>
>>
Re-ping. I know there are discussions about bigger changes to fix the
various failures listed in PR rtl-optimization/87763 but this patch
at least fixes one of them (gcc.target/aarch64/lsl_asr_sbfiz.c).
Steve Ellcey
sell...@marvell.com
On Wed, 2019-04-10 at 15:35 -0700, Steve Ellcey wrote:
> On
> The runtime check assures that at runtime, the upper 32 bits of pseudo 104
> must be always 0 (in this case, in some other case could be sign bit
> copies).
OK, as Richard pointed out, that's not sufficient if we allow...
> The question is if it would be valid say for forward propagation to fir
On Tue, Apr 16, 2019 at 04:10:11PM +, Michael Matz wrote:
> I was quickly testing also with some early-outs but didn't get conclusive
> performance results (but really only superficial testing) so I'm not
> proposing it, like so:
>
> diff --git a/gcc/cp/typeck.c b/gcc/cp/typeck.c
> index 704
Hi,
On Tue, 16 Apr 2019, Richard Biener wrote:
> Comments?
I was quickly testing also with some early-outs but didn't get conclusive
performance results (but really only superficial testing) so I'm not
proposing it, like so:
diff --git a/gcc/cp/typeck.c b/gcc/cp/typeck.c
index 7045284..33f56f
On 4/16/19 9:35 AM, Michael Matz wrote:
> Hi,
>
> On Tue, 16 Apr 2019, Jeff Law wrote:
>
>>> I still don't think that what you want follows. Imagine this:
>>>
>>> int foo (int i) { ++i; return i; }
>>>
>>> To claim that this function is anything else than const+pure seems weird
>>> (in fact t
On Tue, Apr 16, 2019 at 8:36 AM Martin Liška wrote:
>
> On 4/16/19 4:50 PM, H.J. Lu wrote:
> > On Tue, Apr 16, 2019 at 1:28 AM Martin Liška wrote:
> >>
> >> On 4/15/19 5:09 PM, H.J. Lu wrote:
> >>> On Mon, Apr 15, 2019 at 12:26 AM Martin Liška wrote:
>
> On 4/12/19 4:12 PM, H.J. Lu wro
On 4/16/19 4:50 PM, H.J. Lu wrote:
> On Tue, Apr 16, 2019 at 1:28 AM Martin Liška wrote:
>>
>> On 4/15/19 5:09 PM, H.J. Lu wrote:
>>> On Mon, Apr 15, 2019 at 12:26 AM Martin Liška wrote:
On 4/12/19 4:12 PM, H.J. Lu wrote:
> On Fri, Apr 12, 2019 at 4:41 AM Martin Liška wrote:
>>
> On Apr 15, 2019, at 11:59 PM, Iain Sandoe wrote:
> OK for trunk (after wider testing)?
Didn't we make you a Darwin maintainer yet?
Ok.
> branches?
Ok.
Hi,
On Tue, 16 Apr 2019, Jeff Law wrote:
> > I still don't think that what you want follows. Imagine this:
> >
> > int foo (int i) { ++i; return i; }
> >
> > To claim that this function is anything else than const+pure seems weird
> > (in fact this function doesn't access anything that must
On 4/15/19 6:51 AM, Michael Matz wrote:
> Hi,
>
> On Fri, 12 Apr 2019, Jeff Law wrote:
>
>>> I don't think this follows. Imagine a pure foo tailcalling a pure bar.
>>> To make the tailcall, foo may need to change some of its argument slots
>>> to pass new arguments to bar.
>> I'd claim that a pur
On Tue, 16 Apr 2019 at 17:18, Jonathan Wakely wrote:
> >--- libstdc++-v3/testsuite/20_util/tuple/cons/noexcept_specs.cc
> >(nonexistent)
> >+++ libstdc++-v3/testsuite/20_util/tuple/cons/noexcept_specs.cc
> >(working copy)
> >@@ -0,0 +1,191 @@
> >+// { dg-options { -std=gnu++2a } }
On Tue, Apr 16, 2019 at 03:08:23PM +0300, Roman Zhuykov wrote:
> This issue unfortunately was not solved correctly. In that example we
> don’t have -fmodulo-sched-allow-regmoves enabled and we should not
> create any register moves at all.
Yes, but if we do for whatever reason, we should never
On Tue, Apr 16, 2019 at 1:28 AM Martin Liška wrote:
>
> On 4/15/19 5:09 PM, H.J. Lu wrote:
> > On Mon, Apr 15, 2019 at 12:26 AM Martin Liška wrote:
> >>
> >> On 4/12/19 4:12 PM, H.J. Lu wrote:
> >>> On Fri, Apr 12, 2019 at 4:41 AM Martin Liška wrote:
>
> On 4/11/19 6:30 PM, H.J. Lu wro
On 11/04/19 20:58 +0100, Jonathan Wakely wrote:
The epiphany-elf target aligns structs to 8 bytes, which causes the
static_assert(alignof(_Chunk) == 1) to fail.
Instead of requiring _Chunks to be positionable at any alignment, ensure
new buffers are aligned to alignof(_Chunk). Because the buffer
On 16/04/19 14:08 +0100, Nina Dinka Ranns wrote:
Tested on Linux-PPC64
Adding noexcept-specification on tuple constructors (LWG 2899)
Thanks, Nina!
This looks great, although as I think Ville has explained we won't
commit it until the next stage 1, after the GCC 9 release.
The changes look go
> Le 16 avr. 2019 à 15:07, Jakub Jelinek a écrit :
>
> On Tue, Apr 16, 2019 at 02:51:14PM +0200, Jan Hubicka wrote:
>>> Hi Jan,
>>>
>>> The test causes
>>>
>>> WARNING: lto.exp does not support dg-do
>>> WARNING: lto.exp does not support dg-options in primary source file
>>>
>>> This is fix
Tested on Linux-PPC64
Adding noexcept-specification on tuple constructors (LWG 2899)
2019-04-13 Nina Dinka Ranns
Adding noexcept-specification on tuple constructors (LWG 2899)
* libstdc++-v3/include/std/tuple:
(tuple()): Add noexcept-specification.
(tuple(const _
On Tue, Apr 16, 2019 at 02:51:14PM +0200, Jan Hubicka wrote:
> > Hi Jan,
> >
> > The test causes
> >
> > WARNING: lto.exp does not support dg-do
> > WARNING: lto.exp does not support dg-options in primary source file
> >
> > This is fixed by the following patch
> >
> > --- ../_clean/gcc/testsui
On Tue, Apr 16, 2019 at 12:20:16PM +0200, Eric Botcazou wrote:
> > If I remember correctly and read the cfgexpand.c comment
> >
> > /* For a promoted variable, X will not be used directly but wrapped in a
> > SUBREG with SUBREG_PROMOTED_VAR_P set, which means that the RTL land
> > will
On Tue, Apr 16, 2019 at 2:51 PM Jan Hubicka wrote:
>
> > Hi Jan,
> >
> > The test causes
> >
> > WARNING: lto.exp does not support dg-do
> > WARNING: lto.exp does not support dg-options in primary source file
> >
> > This is fixed by the following patch
> >
> > --- ../_clean/gcc/testsuite/g++.dg/l
The following makes the C++ FEs heavy use of build_qualified_type
cheaper. When looking at a tramp3d -fsyntax-only compile you can
see that for 470.000 build_qualified_type calls we end up
with 9.492.205 calls to check_qualified_type (thus we visit around
20 variant type candidates) ending up fi
> Hi Jan,
>
> The test causes
>
> WARNING: lto.exp does not support dg-do
> WARNING: lto.exp does not support dg-options in primary source file
>
> This is fixed by the following patch
>
> --- ../_clean/gcc/testsuite/g++.dg/lto/pr89358_0.C2019-04-15
> 00:04:48.0 +0200
> +++ gcc/tes
Hi Jan,
The test causes
WARNING: lto.exp does not support dg-do
WARNING: lto.exp does not support dg-options in primary source file
This is fixed by the following patch
--- ../_clean/gcc/testsuite/g++.dg/lto/pr89358_0.C 2019-04-15
00:04:48.0 +0200
+++ gcc/testsuite/g++.dg/lto/pr89
Hi Pat,
On Mon, Apr 15, 2019 at 03:43:26PM -0500, Pat Haugen wrote:
> As pointed out in the PR, the test is failing because a store->load
> dependency is reporting zero cost. Fixed by leaving existing costs as is
> (i.e. cost for update forms), and just adding a simple bypass for store->load
>
Two cases from a -fsynax-only tramp3d callgrind profile.
Bootstrapped / tested on x86_64-unknown-linux-gnu.
OK for trunk?
Richard.
2019-04-16 Richard Biener
cp/
* call.c (null_ptr_cst_p): Order checks according to expensiveness.
(conversion_null_warnings): Likewise
This issue unfortunately was not solved correctly. In that example we
don’t have -fmodulo-sched-allow-regmoves enabled and we should not
create any register moves at all.
I’ll describe here everything I found while looking on the issue. At
the first step I have patched trunk compiler like th
Current algorithm which finds recurrence_length for all DDG strongly
connected components works in like O(N^6) time, where N in the number of
nodes in DDG. The time is so bad mostly for graphs with lots of edges,
like almost N^2 edges. My proposed algorithm works in O(N^3).
Algorithm of find
We divide by zero when we try to schedule loop body in zero cycles.
Both res_mii and rec_mii estimations equals zero. We have to start with
one cycle in this situation.
Same failure happens in the following tests on ia64 platform with
-fmodulo-sched enabled (with any of -O1, -O2, -Os):
gcc.
There is the following mistake in logic behind the code.
We want to schedule the branch instructions only as a last instruction
in a row. But when branch was scheduled and we add other instructions
into partial schedule, we sometimes allow them to be in same row after
the branch.
The issue h
Last few days I’ve added my comments/patches into almost all
modulo-scheduler PRs appeared in the last two years. Here I want to
discuss five PRs. First of all, I have four patches which fix
regressions, so technically I can ask about applying them right now on
stage4. But we don’t have a ma
Hi!
I'd like to ping the PR89888 patch:
https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00360.html
Thanks
Jakub
Hi Xiong,
Sorry I took so long to review this.
On Thu, Apr 04, 2019 at 02:49:29AM -0500, luo...@linux.ibm.com wrote:
> These patches are followed changes for r25 on testcases
> vsx-vector-6*.c. backport them to update file names and fix regressions
> for GCC7 on power9.
(See e.g. https://gc
On 2019-04-16 12:39 a.m., Eric Gallager wrote:
> Hey Montréal, I might actually be able to go this year! How do I register?
Hi Eric,
Happy to hear this! Please see the Registration section on the wiki:
https://gcc.gnu.org/wiki/cauldron2019#Registration
Simon
On Tue, Apr 16, 2019 at 12:16:16PM +0200, Jakub Jelinek wrote:
> On Tue, Apr 16, 2019 at 11:33:39AM +0200, Florian Weimer wrote:
> > * Segher Boessenkool:
> >
> > > On Mon, Apr 15, 2019 at 01:54:11PM +0200, Florian Weimer wrote:
> > >> * Richard Biener:
> > >>
> > >> > Of course adding sth like a
Committed. Thank you,
Claudiu
On Thu, Apr 11, 2019 at 12:56 AM Andrew Burgess
wrote:
>
> * Claudiu Zissulescu [2019-03-25 12:03:13 +0100]:
>
> > New LRA algorithms require the all the register constraints to be
> > defined using define_register_constraint keyword. However, Rs5
> > constraint was
Committed. Thank you,
Claudiu
On Thu, Apr 11, 2019 at 12:54 AM Andrew Burgess
wrote:
>
> * Claudiu Zissulescu [2019-03-25 12:03:12 +0100]:
>
> > Refurbish eliminable regs howto by introducing a fake
> > FRAME_POINTER_REGNUM with the purpose to release FP register to be
> > used freely by the reg
Committed with the suggested info.
Thank you for your review,
Claudiu
On Thu, Apr 11, 2019 at 12:47 AM Andrew Burgess
wrote:
>
> * Claudiu Zissulescu [2019-03-25 12:03:11 +0100]:
>
> > 1.The delay slot scheduler can reschedule some of the frame related
> > instructions resulting in having incor
> If I remember correctly and read the cfgexpand.c comment
>
> /* For a promoted variable, X will not be used directly but wrapped in a
> SUBREG with SUBREG_PROMOTED_VAR_P set, which means that the RTL land
> will assume that its upper bits can be inferred from its lower bits.
> T
On Tue, Apr 16, 2019 at 11:33:39AM +0200, Florian Weimer wrote:
> * Segher Boessenkool:
>
> > On Mon, Apr 15, 2019 at 01:54:11PM +0200, Florian Weimer wrote:
> >> * Richard Biener:
> >>
> >> > Of course adding sth like a .robss section would be nice.
> >>
> >> I think this is strictly a link edi
On Tue, Apr 16, 2019 at 12:05:56PM +0200, Richard Biener wrote:
> On Tue, Apr 16, 2019 at 11:33 AM Florian Weimer wrote:
> >
> > * Segher Boessenkool:
> >
> > > On Mon, Apr 15, 2019 at 01:54:11PM +0200, Florian Weimer wrote:
> > >> * Richard Biener:
> > >>
> > >> > Of course adding sth like a .rob
On Tue, Apr 16, 2019 at 11:33:39AM +0200, Florian Weimer wrote:
> * Segher Boessenkool:
>
> > On Mon, Apr 15, 2019 at 01:54:11PM +0200, Florian Weimer wrote:
> >> * Richard Biener:
> >>
> >> > Of course adding sth like a .robss section would be nice.
> >>
> >> I think this is strictly a link edi
On Tue, Apr 16, 2019 at 11:33 AM Florian Weimer wrote:
>
> * Segher Boessenkool:
>
> > On Mon, Apr 15, 2019 at 01:54:11PM +0200, Florian Weimer wrote:
> >> * Richard Biener:
> >>
> >> > Of course adding sth like a .robss section would be nice.
> >>
> >> I think this is strictly a link editor issue
* Segher Boessenkool:
> On Mon, Apr 15, 2019 at 01:54:11PM +0200, Florian Weimer wrote:
>> * Richard Biener:
>>
>> > Of course adding sth like a .robss section would be nice.
>>
>> I think this is strictly a link editor issue because a read-only PT_LOAD
>> directive with a memory size larger tha
On Tue, Apr 16, 2019 at 10:07 AM Jakub Jelinek wrote:
>
> Hi!
>
> Most of the x86 builtins don't have OPTION_MASK_ISA_64BIT in their bisa
> mask, but when printing an error if some builtin is used from a function
> without right isa flags, we always print that case as -m32, so we end up
> with bog
On Tue, 16 Apr 2019, Jakub Jelinek wrote:
> Hi!
>
> In expand_mul_overflow, we emit (depending on operand ranges etc.) more than
> one multiplication to optimize for the common case. One of those is where
> we are guaranteed that both operands are either sign or zero extended from
> half precisi
On 4/15/19 5:09 PM, H.J. Lu wrote:
> On Mon, Apr 15, 2019 at 12:26 AM Martin Liška wrote:
>>
>> On 4/12/19 4:12 PM, H.J. Lu wrote:
>>> On Fri, Apr 12, 2019 at 4:41 AM Martin Liška wrote:
On 4/11/19 6:30 PM, H.J. Lu wrote:
> On Thu, Apr 11, 2019 at 1:38 AM Martin Liška wrote:
>>
On Mon, Apr 15, 2019 at 7:09 PM Andrew Pinski wrote:
>
> On Sun, Apr 14, 2019 at 11:50 PM Richard Biener
> wrote:
> >
> > On Sat, Apr 13, 2019 at 12:34 AM Jeff Law wrote:
> > >
> > > On 4/12/19 3:24 PM, Jason Merrill wrote:
> > > > If a noexcept function calls a function that might throw, doing
Hi!
Most of the x86 builtins don't have OPTION_MASK_ISA_64BIT in their bisa
mask, but when printing an error if some builtin is used from a function
without right isa flags, we always print that case as -m32, so we end up
with bogus messages like
needs isa option -m32 -mavx512vl
It doesn't really
Hi!
In expand_mul_overflow, we emit (depending on operand ranges etc.) more than
one multiplication to optimize for the common case. One of those is where
we are guaranteed that both operands are either sign or zero extended from
half precision types to the full precision, we can then use much sh
On Tue, 16 Apr 2019, Jakub Jelinek wrote:
> Hi!
>
> Recently I've added an assert that if !can_alter_cfg DCE (fast DCE in that
> case) doesn't actually alter the cfg. The following testcase shows
> something where it still does. Even when a (const or pure) call doesn't
> throw, it could have ED
On Tue, 16 Apr 2019, Jakub Jelinek wrote:
> Hi!
>
> While we in theory could move over the EH stuff from the division
> instructions to the multiplication ones (right now we do not do even that),
> we would need to add EH even to the divisions added by insert_reciprocals.
>
> The following patch
Hi!
Recently I've added an assert that if !can_alter_cfg DCE (fast DCE in that
case) doesn't actually alter the cfg. The following testcase shows
something where it still does. Even when a (const or pure) call doesn't
throw, it could have EDGE_ABNORMAL{,_CALL} edges added to setjmp etc.
The foll
Hi!
While we in theory could move over the EH stuff from the division
instructions to the multiplication ones (right now we do not do even that),
we would need to add EH even to the divisions added by insert_reciprocals.
The following patch just punts on divisions that can throw internally,
boots
Hi,
TL;DR
So, it turns out that there’s an interaction between standards wording that
makes an implementation conforming when it has extensions that, when used, make
a program ill-formed (but with no diagnostic required) (see the PR for more
detail).
One might argue that using such extensions
69 matches
Mail list logo
