On Wed, 7 Nov 2018, Jan Hubicka wrote:
> Hi,
> this patch simplfies types of arrays so we don't propagate duplicates
> when record/union contains array of pointers.
> With this we still miss simplification of pointers to arrays of
> structures (where we need to rebuild array same way as we rebuild
Hi.
In order to fix the warnings mentioned in the PR, we need
to run remove_unreachable_nodes after early tree passes. That's
however possible only within a IPA pass. Thus I'm calling that
before the profile PASS.
Patch survives regression tests on ppc64le-linux-gnu and majority
of warnings are g
Hi Richard,
>>the new testcase FAILs on Solaris:
>>
>>+FAIL: g++.dg/lto/pr87906 cp_lto_pr87906_0.o assemble, -O -fPIC -flto
>>+UNRESOLVED: g++.dg/lto/pr87906 cp_lto_pr87906_0.o-cp_lto_pr87906_1.o
>>execute -O -fPIC -flto
>>+UNRESOLVED: g++.dg/lto/pr87906 cp_lto_pr87906_0.o-cp_lto_pr87906_1.o
>
On 11/7/18 11:23 PM, Jeff Law wrote:
> On 10/30/18 6:28 AM, Martin Liška wrote:
>> On 10/30/18 11:03 AM, Jakub Jelinek wrote:
>>> On Mon, Oct 29, 2018 at 04:14:21PM +0100, Martin Liška wrote:
+hashtab_chk_error ()
+{
+ fprintf (stderr, "hash table checking failed: "
+ "equa
Hi,
two additional grokdeclarator locations that we can easily fix by using
declarator->id_loc. Slightly more interesting, testing revealed a latent
issue in the make_id_declarator uses: cp_parser_member_declaration
wasn't setting declarator->id_loc, thus I decided to add a location_t
paramet
On Nov 7, 2018, JonY <10wa...@gmail.com> wrote:
> On 11/07/2018 08:34 AM, Alexandre Oliva wrote:
>> On Nov 1, 2018, JonY wrote:
>>
>>> Looks like it causes an error on 64bit:
>>> /usr/libexec/gcc/x86_64-w64-mingw32/ld: unrecognized option
>>> '--large-address-aware'
>>
>> What does? The patch
Ping?
Best regards,
Thomas
On Thu, 1 Nov 2018 at 16:03, Thomas Preudhomme
wrote:
>
> Ping?
>
> Best regards,
>
> Thomas
> On Fri, 26 Oct 2018 at 22:41, Thomas Preudhomme
> wrote:
> >
> > Hi,
> >
> > Please find updated patch to fix PR85434: spilling of stack protector
> > guard's address on AR
On 07/11/2018 17:49, Mihail Ionescu wrote:
> Hi All,
>
> This is a backport from trunk for GCC 8 and 7.
>
> SVN revision: r264595.
>
> Regression tested on arm-none-eabi.
>
>
> gcc/ChangeLog
>
> 2018-11-02 Mihail Ionescu
>
> Backport from mainiline
> 2018-09-26 Eric Botcazou
Hi Christoph,
On 07/11/18 21:51, christoph.muell...@theobroma-systems.com wrote:
From: Christoph Muellner
The aarch64 ISA specification allows a left shift amount to be applied
after extension in the range of 0 to 4 (encoded in the imm3 field).
Indeed. That looks correct from my reading of
Bootstrapped & tested on x86_64-unknown-linux-gnu, applied.
Richard.
>From f3d02105b799975047a51ad80488f9cd928419bf Mon Sep 17 00:00:00 2001
From: Richard Guenther
Date: Thu, 8 Nov 2018 10:22:09 +0100
Subject: [PATCH] fix-pr87929
2018-11-08 Richard Biener
PR tree-optimization/8792
> On Wed, 7 Nov 2018, Jan Hubicka wrote:
>
> > Hi,
> > this patch simplfies types of arrays so we don't propagate duplicates
> > when record/union contains array of pointers.
> > With this we still miss simplification of pointers to arrays of
> > structures (where we need to rebuild array same way
Hi,
On 11/06/2018 06:58 PM, Jeff Law wrote:
On 11/6/18 3:52 AM, Renlin Li wrote:
Hi Jeff & Peter,
On 11/05/2018 07:41 PM, Jeff Law wrote:
On 11/5/18 12:36 PM, Peter Bergner wrote:
On 11/5/18 1:20 PM, Jeff Law wrote:
On 11/1/18 4:07 PM, Peter Bergner wrote:
On 11/1/18 1:50 PM, Renlin Li wro
On Tue, 6 Nov 2018, H.J. Lu wrote:
> On Sat, Oct 20, 2018 at 3:19 AM Romain Geissler
> wrote:
> >
> > I would like to raise again the question of supporting -fuse-ld=lld.
> >
>
> LGTM. But I can't approve it.
>
> --
> H.J.
Hi,
Is there any gcc reviewer that could comment whether or not this sm
When in_a resolves to a register set in the prev_clobber insn, we may
use the SET_SRC for the compare instead. However, when in_b so
resolves, we proceed to use the reg with its earlier value. When both
resolve to the same register and prev_clobber is an insn that modifies
the register, this arra
Hi all,
When allow-store-data-races is enabled, ifcvt would prefer to generated
conditional select and unconditional store to convert certain if statement
into:
_ifc_1 = val
_ifc_2 = A[i]
val = cond? _ifc_1 : _ifc_2
A[i] = val
When the loop got vectorized, this pattern will be turned into
MASK_
On Wed, Nov 7, 2018 at 5:22 PM David Malcolm wrote:
>
> This patch adds a selftest fixture for overriding the "symtab" global,
> so that selftests involving symtab nodes can be isolated from each
> other: each selftest can have its own symbol_table instance.
>
> In particular, this ensures that no
On Wed, Nov 7, 2018 at 5:22 PM David Malcolm wrote:
>
> Numerous formatted messages from the inliner use %f, mostly as %f, but
> occasionally with length modifiers.
>
> This patch implements the simplest case of "%f" for pp_format (with no
> modifier support) to make it easier to port these messag
On Wed, Nov 7, 2018 at 5:22 PM David Malcolm wrote:
>
> This patch implements support for %C in dump_printf for dumping
> cgraph_node *.
> (I would have preferred to have a code for printing symtab_node *
> and both subclasses, but there doesn't seem to be a good way for
> -Wformat to handle inher
On Wed, Nov 7, 2018 at 5:22 PM David Malcolm wrote:
>
> This patch ports various fprintf calls in the inlining code to using
> the dump API, using the %C format code for printing cgraph_node *.
> I focused on the dump messages that seemed most significant to
> end-users; I didn't port all of the c
On 11/8/18 12:19 PM, Jan Hubicka wrote:
>> Hi.
>>
>> In order to fix the warnings mentioned in the PR, we need
>> to run remove_unreachable_nodes after early tree passes. That's
>> however possible only within a IPA pass. Thus I'm calling that
>> before the profile PASS.
>>
>> Patch survives regres
On Thu, Nov 8, 2018 at 12:39 PM Martin Liška wrote:
>
> On 11/8/18 12:19 PM, Jan Hubicka wrote:
> >> Hi.
> >>
> >> In order to fix the warnings mentioned in the PR, we need
> >> to run remove_unreachable_nodes after early tree passes. That's
> >> however possible only within a IPA pass. Thus I'm c
> On Thu, Nov 8, 2018 at 12:39 PM Martin Liška wrote:
> >
> > On 11/8/18 12:19 PM, Jan Hubicka wrote:
> > >> Hi.
> > >>
> > >> In order to fix the warnings mentioned in the PR, we need
> > >> to run remove_unreachable_nodes after early tree passes. That's
> > >> however possible only within a IPA
On 11/8/18 12:46 PM, Jan Hubicka wrote:
>> On Thu, Nov 8, 2018 at 12:39 PM Martin Liška wrote:
>>>
>>> On 11/8/18 12:19 PM, Jan Hubicka wrote:
> Hi.
>
> In order to fix the warnings mentioned in the PR, we need
> to run remove_unreachable_nodes after early tree passes. That's
>
On Thu, Nov 8, 2018 at 12:00 PM Romain Geissler
wrote:
>
> On Tue, 6 Nov 2018, H.J. Lu wrote:
>
> > On Sat, Oct 20, 2018 at 3:19 AM Romain Geissler
> > wrote:
> > >
> > > I would like to raise again the question of supporting -fuse-ld=lld.
> > >
> >
> > LGTM. But I can't approve it.
> >
> > --
>
get/set_range_info() currently returns the extremes of a range. I have
implemented overloaded variants that return a proper range. In the
future we should use actual ranges throughout, and not depend on range
extremes, as depending on this behavior could causes us to lose precision.
I am als
As per $SUBJECT.
Depends on get_range_info() API changes I have just submitted.
OK for trunk?
commit 01b8d323f896692d2e999b607f4464861d9ccd8f
Author: Aldy Hernandez
Date: Thu Nov 8 12:56:41 2018 +0100
* vr-values.c (vr_values::get_value_range): Use value_range API
in
All this nonsense:
- rtype = get_range_info (t, &min, &max);
- if (rtype == VR_RANGE)
- {
- if (wi::lt_p (max, w, TYPE_SIGN (TREE_TYPE (t
- return true;
- if (wi::lt_p (w, min, TYPE_SIGN (TREE_TYPE (t
- return true;
- }
- else
On Thu, Nov 8, 2018 at 12:02 PM Renlin Li wrote:
>
> Hi all,
>
> When allow-store-data-races is enabled, ifcvt would prefer to generated
> conditional select and unconditional store to convert certain if statement
> into:
>
> _ifc_1 = val
> _ifc_2 = A[i]
> val = cond? _ifc_1 : _ifc_2
> A[i] = val
This patch fixes a flaw in the relationship between the way that
SCHED_PRESSURE_MODEL calculates the alap and depth vs how it uses
them in model_order_p. A comment in model_order_p says:
/* Combine the length of the longest path of satisfied true dependencies
that leads to each instruct
This completes the transition to HWI for lamda vectors. Previously
we propagated the HWI use of int_cst_value used throughout the dataref
code to local vars but left the actual lambda representation at int.
That's prone to overflows and silent wrong-code.
Bootstrapped and tested on x86_64-unkno
This one's rather obvious and does not depend on any get_range_info API
change.
OK for trunk?
* gimple-ssa-evrp-analyze.c
(evrp_range_analyzer::record_ranges_from_incoming_edge): Use
value_range API instead of piecing together ranges.
diff --git a/gcc/gimple-
Hi Martin,
On 23/10/18 14:17, Martin Liška wrote:
Hello.
As a follow up patch I would like to remove redundant string allocation
on string which is not needed in my opinion.
I think this change is correct, as these functions don't modify the string,
just read it in different ways.
You'll sti
Hi Kyrill,
> On 08.11.2018, at 11:16, Kyrill Tkachov wrote:
>
> Hi Christoph,
>
> On 07/11/18 21:51, christoph.muell...@theobroma-systems.com wrote:
>> From: Christoph Muellner
>>
>> The aarch64 ISA specification allows a left shift amount to be applied
>> after extension in the range of 0 to
Hi Christoph,
On 08/11/18 12:20, Christoph Müllner wrote:
Hi Kyrill,
> On 08.11.2018, at 11:16, Kyrill Tkachov wrote:
>
> Hi Christoph,
>
> On 07/11/18 21:51, christoph.muell...@theobroma-systems.com wrote:
>> From: Christoph Muellner
>>
>> The aarch64 ISA specification allows a left shift am
This is an obvious patch I will commit once testing completes.
Aldy
* tree-vrp.c (may_contain_p): Do not access m_min/m_max directly.
diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c
index 17b0b6c6037..7af676a416d 100644
--- a/gcc/tree-vrp.c
+++ b/gcc/tree-vrp.c
@@ -250,10 +250,10 @@ val
> On 08.11.2018, at 13:25, Kyrill Tkachov wrote:
>
> Hi Christoph,
>
> On 08/11/18 12:20, Christoph Müllner wrote:
>> Hi Kyrill,
>>
>> > On 08.11.2018, at 11:16, Kyrill Tkachov
>> > wrote:
>> >
>> > Hi Christoph,
>> >
>> > On 07/11/18 21:51, christoph.muell...@theobroma-systems.com wrote:
>
On Wed, 7 Nov 2018 at 16:50, Uros Bizjak wrote:
>
> 2018-11-07 Uros Bizjak
>
> * gcc.dg/pr87874.c: Compile only for int128 effective target.
>
> Tested on x86_64-linux-gnu {,-m32} and committed to mainline SVN.
>
This doesn't work on aarch64 -mabi=ilp32:
/gcc/testsuite/gcc.dg/pr87874.c: In
On 11/8/18 4:57 AM, Renlin Li wrote:
> I think I found the problem!
>
> As described in the PR, a hard register is used in
> an pre/post modify expression. The hard register is live, but updated.
> In this case, we should make it conflicting with all pseudos live at
> that point. Does it make sen
Stupid boring changes.
OK?
* tree-vrp.c (value_range::check): Do not access internals
directly.
(value_range::singleton_p): Same.
(value_range::type): Same.
(vrp_finalize): Use value_range API.
diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp
I believe I've seen this idiom more than once. I know for sure I've
used it in our ssa-range branch :). I'll hunt for the other uses and
adjust accordingly.
OK?
* tree-vrp.h (value_range::domain_p): New.
* tree-vrp.c (value_range::domain_p): New.
* tree-ssa
Hi,
On Wed, 7 Nov 2018, Martin Liška wrote:
> > Whereever the new function belongs it certainly isn't system.h. Also
> > the definition in a header seems excessive. Sure, it enables inlining
> > of it, but that seems premature optimization. It contains a loop, and
> > inlining anything with
The following fixes another instance of PR87914, this time it is
DOM wrecking loop-header copying presenting vectorization with
wrong loop form. The loop header copying pass right before
vectorization isn't of great help since nothing cleans up after
it so loop form is still bogus.
I've tried t
On Wed, Nov 07, 2018 at 06:08:33PM -0600, Segher Boessenkool wrote:
> On Wed, Nov 07, 2018 at 04:07:15PM +1030, Alan Modra wrote:
> > +extern const char *rs6000_output_call (rtx *, unsigned int, bool, const
> > char *);
>
> Maybe have a separate rs6000_output_call and rs6000_output_sibcall? Bare
On Wed, Nov 07, 2018 at 07:11:28PM -0600, Segher Boessenkool wrote:
> On Wed, Nov 07, 2018 at 04:08:26PM +1030, Alan Modra wrote:
> > There is really no need to define a TLSmode mode iterator that is
> > identical (since !TARGET_64BIT == TARGET_32BIT) to the much used P
> > mode iterator.
>
> Nice
[Richard, you're right. An overloaded debug() is better than
this->dump(). Anyone who thinks different is wrong. End of discussion.]
There's no reason to have multiple ways of dumping a value range. And
I'm not even talking about ipa-prop.* which decided that they should
implement their ow
Hi,
> But the max. error in sinh/cosh/atanh is less than 2 ULP, with some math
> libraries. It could be < 1 ULP, in theory, so sinh(atanh(x)) less than
> 2 ULP even.
You can't add ULP errors in general - a tiny difference in the input can
make a huge difference in the result if the derivative i
On 11/8/18 2:15 PM, Michael Matz wrote:
> Hi,
>
> On Wed, 7 Nov 2018, Martin Liška wrote:
>
>>> Whereever the new function belongs it certainly isn't system.h. Also
>>> the definition in a header seems excessive. Sure, it enables inlining
>>> of it, but that seems premature optimization. It
Hi.
The patch is about possibility to filter which files are instrumented. The usage
is explained in the PR.
Patch can bootstrap and survives regression tests on x86_64-linux-gnu.
Ready for trunk?
Thanks,
Martin
gcc/ChangeLog:
2018-11-08 Martin Liska
PR gcov-profile/87442
*
Hi Peter,
On 11/08/2018 12:35 PM, Peter Bergner wrote:
On 11/8/18 4:57 AM, Renlin Li wrote:
I think I found the problem!
As described in the PR, a hard register is used in
an pre/post modify expression. The hard register is live, but updated.
In this case, we should make it conflicting with al
On Mon, Nov 5, 2018 at 3:20 PM Bernd Edlinger wrote:
>
> On 11/5/18 1:28 AM, H.J. Lu wrote:
> > On Sun, Nov 4, 2018 at 10:02 AM Jeff Law wrote:
> >>
> >> On 10/22/18 9:08 AM, Bernd Edlinger wrote:
> >>> Hi!
> >>>
> >>> This makes c_strlen avoid an unsafe strlen folding of const arguments
> >>> wi
On Thu, Nov 8, 2018 at 12:52 PM Aldy Hernandez wrote:
>
> get/set_range_info() currently returns the extremes of a range. I have
> implemented overloaded variants that return a proper range. In the
> future we should use actual ranges throughout, and not depend on range
> extremes, as depending
On Thu, Nov 8, 2018 at 1:01 PM Aldy Hernandez wrote:
>
> As per $SUBJECT.
>
> Depends on get_range_info() API changes I have just submitted.
>
> OK for trunk?
OK
On 11/8/18 8:59 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 12:52 PM Aldy Hernandez wrote:
get/set_range_info() currently returns the extremes of a range. I have
implemented overloaded variants that return a proper range. In the
future we should use actual ranges throughout, and not
On Thu, Nov 8, 2018 at 1:29 PM Christophe Lyon
wrote:
>
> On Wed, 7 Nov 2018 at 16:50, Uros Bizjak wrote:
> >
> > 2018-11-07 Uros Bizjak
> >
> > * gcc.dg/pr87874.c: Compile only for int128 effective target.
> >
> > Tested on x86_64-linux-gnu {,-m32} and committed to mainline SVN.
> >
>
> T
On Thu, Nov 8, 2018 at 1:09 PM Aldy Hernandez wrote:
>
> All this nonsense:
>
> - rtype = get_range_info (t, &min, &max);
> - if (rtype == VR_RANGE)
> - {
> - if (wi::lt_p (max, w, TYPE_SIGN (TREE_TYPE (t
> - return true;
> - if (wi::lt_p (w, min, TYPE
On Thu, Nov 8, 2018 at 1:17 PM Aldy Hernandez wrote:
>
> This one's rather obvious and does not depend on any get_range_info API
> change.
>
> OK for trunk?
Hmm, no - that's broken. IIRC m_equiv are shared bitmaps if you
do tem = *old_vr so you modify it in place with equiv_clear().
Thus, opera
On 11/8/18 9:21 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 1:09 PM Aldy Hernandez wrote:
All this nonsense:
- rtype = get_range_info (t, &min, &max);
- if (rtype == VR_RANGE)
- {
- if (wi::lt_p (max, w, TYPE_SIGN (TREE_TYPE (t
- return true;
-
On 11/8/18 5:48 AM, Richard Biener wrote:
> Err, that looks very much like a hack that manages to hide the issue.
It's true we do not want to hide the issue by adding unneeded conflicts,
since that can lead to unnecessary spills. However, ...
> Esp. adding conflicts in a loop that says "See whi
On Thu, Nov 8, 2018 at 3:24 PM Richard Biener
wrote:
>
> On Thu, Nov 8, 2018 at 1:17 PM Aldy Hernandez wrote:
> >
> > This one's rather obvious and does not depend on any get_range_info API
> > change.
> >
> > OK for trunk?
>
> Hmm, no - that's broken. IIRC m_equiv are shared bitmaps if you
> do
On 11/8/18 9:24 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 1:17 PM Aldy Hernandez wrote:
This one's rather obvious and does not depend on any get_range_info API
change.
OK for trunk?
Hmm, no - that's broken. IIRC m_equiv are shared bitmaps if you
do tem = *old_vr so you modify it
On Thu, Nov 8, 2018 at 1:42 PM Aldy Hernandez wrote:
>
> Stupid boring changes.
>
> OK?
Well, IMHO using m_min is making clear you are accessing a member
while using min () does not.
So no, please do not make this kind of changes?
Richard.
On 11/8/18 9:31 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 1:42 PM Aldy Hernandez wrote:
Stupid boring changes.
OK?
Well, IMHO using m_min is making clear you are accessing a member
while using min () does not.
There is already prior art here. I believe I discussed this before a
On Thu, Nov 8, 2018 at 1:52 PM Aldy Hernandez wrote:
>
> I believe I've seen this idiom more than once. I know for sure I've
> used it in our ssa-range branch :). I'll hunt for the other uses and
> adjust accordingly.
domain_p?! Isn't that the same as varying_p()? Also
+ if (m_kind == VR_RA
On Thu, Nov 8, 2018 at 2:32 PM Aldy Hernandez wrote:
>
> [Richard, you're right. An overloaded debug() is better than
> this->dump(). Anyone who thinks different is wrong. End of discussion.]
>
> There's no reason to have multiple ways of dumping a value range. And
> I'm not even talking about
On 11/8/18 9:34 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 1:52 PM Aldy Hernandez wrote:
I believe I've seen this idiom more than once. I know for sure I've
used it in our ssa-range branch :). I'll hunt for the other uses and
adjust accordingly.
domain_p?! Isn't that the same as
On Thu, Nov 8, 2018 at 3:05 PM Aldy Hernandez wrote:
>
>
>
> On 11/8/18 8:59 AM, Richard Biener wrote:
> > On Thu, Nov 8, 2018 at 12:52 PM Aldy Hernandez wrote:
> >>
> >> get/set_range_info() currently returns the extremes of a range. I have
> >> implemented overloaded variants that return a pro
On Thu, Nov 8, 2018 at 3:27 PM Aldy Hernandez wrote:
>
>
>
> On 11/8/18 9:21 AM, Richard Biener wrote:
> > On Thu, Nov 8, 2018 at 1:09 PM Aldy Hernandez wrote:
> >>
> >> All this nonsense:
> >>
> >> - rtype = get_range_info (t, &min, &max);
> >> - if (rtype == VR_RANGE)
> >> - {
>
On 11/8/18 9:41 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 3:05 PM Aldy Hernandez wrote:
On 11/8/18 8:59 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 12:52 PM Aldy Hernandez wrote:
get/set_range_info() currently returns the extremes of a range. I have
implemented overloaded
On 11/8/18 7:44 AM, Aldy Hernandez wrote:
>
>
> On 11/8/18 9:41 AM, Richard Biener wrote:
>> On Thu, Nov 8, 2018 at 3:05 PM Aldy Hernandez wrote:
>>>
>>>
>>>
>>> On 11/8/18 8:59 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 12:52 PM Aldy Hernandez
wrote:
>
> get/set_range_i
On Thu, Nov 8, 2018 at 3:31 PM Aldy Hernandez wrote:
>
>
>
> On 11/8/18 9:24 AM, Richard Biener wrote:
> > On Thu, Nov 8, 2018 at 1:17 PM Aldy Hernandez wrote:
> >>
> >> This one's rather obvious and does not depend on any get_range_info API
> >> change.
> >>
> >> OK for trunk?
> >
> > Hmm, no -
On 11/8/18 9:43 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 3:27 PM Aldy Hernandez wrote:
On 11/8/18 9:21 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 1:09 PM Aldy Hernandez wrote:
All this nonsense:
- rtype = get_range_info (t, &min, &max);
- if (rtype == VR_RANGE
On Thu, Nov 8, 2018 at 3:34 PM Aldy Hernandez wrote:
>
>
>
> On 11/8/18 9:31 AM, Richard Biener wrote:
> > On Thu, Nov 8, 2018 at 1:42 PM Aldy Hernandez wrote:
> >>
> >> Stupid boring changes.
> >>
> >> OK?
> >
> > Well, IMHO using m_min is making clear you are accessing a member
> > while using
On 11/8/18 7:49 AM, Richard Biener wrote:
> On Thu, Nov 8, 2018 at 3:31 PM Aldy Hernandez wrote:
>>
>>
>>
>> On 11/8/18 9:24 AM, Richard Biener wrote:
>>> On Thu, Nov 8, 2018 at 1:17 PM Aldy Hernandez wrote:
This one's rather obvious and does not depend on any get_range_info API
ch
On Thu, Nov 8, 2018 at 3:40 PM Aldy Hernandez wrote:
>
>
>
> On 11/8/18 9:34 AM, Richard Biener wrote:
> > On Thu, Nov 8, 2018 at 1:52 PM Aldy Hernandez wrote:
> >>
> >> I believe I've seen this idiom more than once. I know for sure I've
> >> used it in our ssa-range branch :). I'll hunt for th
On 11/8/18 9:49 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 3:31 PM Aldy Hernandez wrote:
On 11/8/18 9:24 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 1:17 PM Aldy Hernandez wrote:
This one's rather obvious and does not depend on any get_range_info API
change.
OK for trunk?
On Thu, Nov 8, 2018 at 3:50 PM Aldy Hernandez wrote:
>
>
>
> On 11/8/18 9:43 AM, Richard Biener wrote:
> > On Thu, Nov 8, 2018 at 3:27 PM Aldy Hernandez wrote:
> >>
> >>
> >>
> >> On 11/8/18 9:21 AM, Richard Biener wrote:
> >>> On Thu, Nov 8, 2018 at 1:09 PM Aldy Hernandez wrote:
>
> A
On Thu, Nov 8, 2018 at 3:54 PM Aldy Hernandez wrote:
>
>
>
> On 11/8/18 9:49 AM, Richard Biener wrote:
> > On Thu, Nov 8, 2018 at 3:31 PM Aldy Hernandez wrote:
> >>
> >>
> >>
> >> On 11/8/18 9:24 AM, Richard Biener wrote:
> >>> On Thu, Nov 8, 2018 at 1:17 PM Aldy Hernandez wrote:
>
> T
Since expand_thunk no longer overrides the DECL_IGNORED_P setting on the thunk
from the front-end in every case, duplicate_thunk_for_node may create a new
thunk without DECL_IGNORED_P set and this doesn't play with inlining and early
debug info generation; fixed by forcing DECL_IGNORED_P as befo
> 2018-11-07 Martin Liska
>
> * common.opt: Add -fipa-stack-alignment flag.
> * doc/invoke.texi: Document it.
> * final.c (rest_of_clean_state): Guard stack
> shrinking with flag.
OK
> gcc/ChangeLog:
>
> 2018-11-07 Martin Liska
>
> * cgraph.h (ipa_discover_re
On 11/8/18 9:56 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 3:54 PM Aldy Hernandez wrote:
On 11/8/18 9:49 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 3:31 PM Aldy Hernandez wrote:
On 11/8/18 9:24 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 1:17 PM Aldy Hernandez wro
On 11/8/18 9:53 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 3:40 PM Aldy Hernandez wrote:
On 11/8/18 9:34 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 1:52 PM Aldy Hernandez wrote:
I believe I've seen this idiom more than once. I know for sure I've
used it in our ssa-range b
On Thu, Nov 8, 2018 at 4:00 PM Aldy Hernandez wrote:
>
>
>
> On 11/8/18 9:56 AM, Richard Biener wrote:
> > On Thu, Nov 8, 2018 at 3:54 PM Aldy Hernandez wrote:
> >>
> >>
> >>
> >> On 11/8/18 9:49 AM, Richard Biener wrote:
> >>> On Thu, Nov 8, 2018 at 3:31 PM Aldy Hernandez wrote:
>
>
>
We can have quite convoluted layouts in Ada when a representation clause is
given for a record type with variant part and this doesn't always play nice
with the DECL_BIT_FIELD_REPRESENTATIVE machinery. This patch arranges for
DECL_BIT_FIELD_TYPE to be cleared on the variant part in these cases.
On 11/8/18 4:57 AM, Renlin Li wrote:
> I think I found the problem!
>
> As described in the PR, a hard register is used in
> an pre/post modify expression. The hard register is live, but updated.
> In this case, we should make it conflicting with all pseudos live at
> that point. Does it make sen
On Tue, Oct 23, 2018 at 08:17:43AM -0500, Martin Liška wrote:
> Hello.
>
> As a follow up patch I would like to remove redundant string allocation
> on string which is not needed in my opinion.
>
> That bootstrap on aarch64-linux.
OK,
Thanks,
James
> From a21a626055442635057985323bb42ef29526e
On Thu, Nov 8, 2018 at 4:05 PM Aldy Hernandez wrote:
>
>
>
> On 11/8/18 9:53 AM, Richard Biener wrote:
> > On Thu, Nov 8, 2018 at 3:40 PM Aldy Hernandez wrote:
> >>
> >>
> >>
> >> On 11/8/18 9:34 AM, Richard Biener wrote:
> >>> On Thu, Nov 8, 2018 at 1:52 PM Aldy Hernandez wrote:
>
> I
On 11/8/18 8:14 AM, Richard Biener wrote:
> On Thu, Nov 8, 2018 at 4:00 PM Aldy Hernandez wrote:
>>
>>
>>
>> On 11/8/18 9:56 AM, Richard Biener wrote:
>>> On Thu, Nov 8, 2018 at 3:54 PM Aldy Hernandez wrote:
On 11/8/18 9:49 AM, Richard Biener wrote:
> On Thu, Nov 8, 2018 a
On 11/8/18 10:24 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 4:05 PM Aldy Hernandez wrote:
On 11/8/18 9:53 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 3:40 PM Aldy Hernandez wrote:
On 11/8/18 9:34 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 1:52 PM Aldy Hernandez wr
On 11/8/18 9:55 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 3:50 PM Aldy Hernandez wrote:
On 11/8/18 9:43 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 3:27 PM Aldy Hernandez wrote:
On 11/8/18 9:21 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 1:09 PM Aldy Hernandez wro
On Thu, 8 Nov 2018 at 15:11, Uros Bizjak wrote:
>
> On Thu, Nov 8, 2018 at 1:29 PM Christophe Lyon
> wrote:
> >
> > On Wed, 7 Nov 2018 at 16:50, Uros Bizjak wrote:
> > >
> > > 2018-11-07 Uros Bizjak
> > >
> > > * gcc.dg/pr87874.c: Compile only for int128 effective target.
> > >
> > > Test
On 11/08/2018 09:45 AM, Alexandre Oliva wrote:
> On Nov 7, 2018, JonY <10wa...@gmail.com> wrote:
>
>> On 11/07/2018 08:34 AM, Alexandre Oliva wrote:
>>> On Nov 1, 2018, JonY wrote:
>>>
Looks like it causes an error on 64bit:
/usr/libexec/gcc/x86_64-w64-mingw32/ld: unrecognized option
>
Hi Thomas,
On 08/11/18 09:52, Thomas Preudhomme wrote:
Ping?
Best regards,
Thomas
On Thu, 1 Nov 2018 at 16:03, Thomas Preudhomme
wrote:
Ping?
Best regards,
Thomas
On Fri, 26 Oct 2018 at 22:41, Thomas Preudhomme
wrote:
Hi,
Please find updated patch to fix PR85434: spilling of stack prot
This is a regression present since the -faggressive-loop-optimizations option
was introduced, leading to wrong code in some cases for "while" loops with
convoluted control flow. It's caused by a bad interaction between three
different things: specific support we have in gigi for -fnon-call-exce
On 11/8/18 9:39 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 2:32 PM Aldy Hernandez wrote:
[Richard, you're right. An overloaded debug() is better than
this->dump(). Anyone who thinks different is wrong. End of discussion.]
There's no reason to have multiple ways of dumping a value r
Hi Peter,
On 11/08/2018 03:21 PM, Peter Bergner wrote:
On 11/8/18 4:57 AM, Renlin Li wrote:
I think I found the problem!
As described in the PR, a hard register is used in
an pre/post modify expression. The hard register is live, but updated.
In this case, we should make it conflicting with al
On 11/07/2018 02:36 AM, Martin Liška wrote:
On 11/5/18 7:00 PM, Martin Sebor wrote:
On 11/01/2018 07:45 AM, Martin Liška wrote:
On 11/1/18 1:15 PM, Jakub Jelinek wrote:
On Thu, Nov 01, 2018 at 01:09:16PM +0100, Martin Liška wrote:
-range 0.0 to 1.0, inclusive.
+range 0.0 to 1.0, inclusive. T
On Thu, 8 Nov 2018, Kito Cheng wrote:
> Hi Joseph:
>
> I don't have commit right, could you help me to commit that, thanks :)
Done.
--
Joseph S. Myers
jos...@codesourcery.com
I've committed some "obvious" changes to GCC tests that fix failures when
running the GCC testsuite for msp430-elf.
Patch 1 adds a couple of new regexp strings to gcc-dg-prune to catch messages
emitted by GNU ld, when the size of an output section is too large for a memory
region, or the memory r
Patch 1 adds a couple of new regexp strings to gcc-dg-prune to catch messages
emitted by GNU ld, when the size of an output section is too large for a memory
region, or the memory region overflows.
>From af810d86c47092e56590f5c13d0633c490f53c9d Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
D
Patch 2 skips tests expecting NULL pointer checks to be deleted
with the -fdelete-null-pointer-checks flag, for targets which ignore this flag.
>From 55b405a4d2c694ffdbcbd6808e139d88cb2d2447 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Tue, 6 Nov 2018 12:59:33 +
Subject: [PATCH 2/4
1 - 100 of 154 matches
Mail list logo
