Hi.
> > * gcc.target/i386/avx-vround-roundeven-1.c: New test.
> > * gcc.target/i386/avx-vround-roundeven-2.c: New test.
>
> roundss and roundsd are sse4_1 instructions, also please change tests
> to use -O2:
I have made the following changes you suggested and changed the file names to:
This patch aims to fix PR69678 caused by PGO indirect call profiling
performance issues.
The bug that profiling data is never working was fixed by Martin's pull
back of topN patches, performance got GEOMEAN ~1% improvement.
Still, currently the default profile only generates SINGLE indirect target
Introduce exception handler ABI #1 to ensure single release, no access
after release of reraised Machine_Occurrences, and no failure to
re-reraise a Machine_Occurrence.
Unlike Ada exceptions, foreign exceptions do not get a new
Machine_Occurrence upon reraise, but each handler would delete the
exc
On Mon, Jul 29, 2019 at 03:35:08PM +0200, Martin Liška wrote:
> I'm sending v2 of the patch that can newly auto-detect make
> jobserver and use it.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Thanks,
> Martin
> >From df747a46241dcdb8ad0
On 2019-07-30 5:58 a.m., Richard Sandiford wrote:
lra_insn_reg and lra_operand_data have both a bitmask of earlyclobber
alternatives and an overall boolean. The danger is that we then test
the overall boolean when really we should be testing for a particular
alternative. This patch gets rid o
...like the others.
Committed.
Gerald
Index: readings.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/readings.html,v
retrieving revision 1.316
diff -u -r1.316 readings.html
--- readings.html 28 Jul 2019 08:54:12 - 1.316
+
On Tue, 2019-07-30 at 14:31 +0100, Richard Sandiford wrote:
>
> > -
> > - tree new_type = build_distinct_type_copy (TREE_TYPE (node-
> > >decl));
> > - TYPE_ARG_TYPES (new_type) = new_reversed;
>
> I think you still need this line, just applied to the existing type
> rather than a new o
Hi Richard,
it is already a while ago, but I had not found time to continue
with this patch until now.
I think I have now a better solution, which properly addresses your
comments below.
On 3/25/19 9:41 AM, Richard Biener wrote:
> On Fri, 22 Mar 2019, Bernd Edlinger wrote:
>
>> On 3/21/19 12:15
On Tue, Jul 30, 2019 at 08:17:39PM +0200, Thomas Koenig wrote:
> Hi Steve,
>
> > The attach patch has been regression tested on x86_64-*-freebsd.
> > There were no regression.
> >
> > The patch prevents an ICE when checking for aliasing and the
> > actual arguments are the real and imaginary part
On 7/30/19 1:13 AM, Akshat Garg wrote:
Hi,
This patch includes C front-end code for a type qualifier _Dependent_ptr.
Just some very high-level comments/questions. I only followed
the _Dependent_ptr discussion from a distance and I'm likely
missing some context so the first thing I looked for i
ping
On Tue, Jul 23, 2019 at 10:27 AM Matthew Beliveau wrote:
>
> ping
>
> On Tue, Jul 16, 2019 at 8:40 AM Marek Polacek wrote:
> >
> > On Mon, Jul 15, 2019 at 09:47:26AM -0400, Matthew Beliveau wrote:
> > > Okay I kept the TYPE_MAIN_VARIANT and dropped the accidental new line!
> > > Hopefully t
Hi Steve,
The attach patch has been regression tested on x86_64-*-freebsd.
There were no regression.
The patch prevents an ICE when checking for aliasing and the
actual arguments are the real and imaginary parts of a complex
entity. See the testcase for more information.
OK to commit to both
On Tue, Jul 30, 2019 at 5:33 PM Peter Bergner wrote:
>
> On 7/30/19 7:52 AM, Uros Bizjak wrote:
> > On Thu, Jul 25, 2019 at 7:34 PM Peter Bergner wrote:
> >>> +#define DRIVER_SELF_SPECS SUBTARGET_DRIVER_SELF_SPECS
> >>> +
> >>> +#ifndef SUBTARGET_DRIVER_SELF_SPECS
> >>> +# define SUBTARGET_DRIVER
Hi all,
The neoversen1 tuning struct gives better performance on the Cortex-A76,
so use that.
The only difference from the current tuning is the function and label
alignment settings.
This gives about 1.3% improvement on SPEC2006 int and 0.3% on SPEC2006 fp.
Tested on aarch64-none-elf.
Ok f
The attach patch has been regression tested on x86_64-*-freebsd.
There were no regression.
The patch prevents an ICE when checking for aliasing and the
actual arguments are the real and imaginary parts of a complex
entity. See the testcase for more information.
OK to commit to both trunk and 9-b
My previous change to the Thumb-2 movsi patterns [1] caused a codesize
regression
with -Os in large functions. Fix this by using the literal pool offset of the
16-bit literal load so that the literal pool is dumped earlier, reducing the
number of 32-bit literal loads.
Bootstrap & regress OK on a
On 7/30/19 7:52 AM, Uros Bizjak wrote:
> On Thu, Jul 25, 2019 at 7:34 PM Peter Bergner wrote:
>>> +#define DRIVER_SELF_SPECS SUBTARGET_DRIVER_SELF_SPECS
>>> +
>>> +#ifndef SUBTARGET_DRIVER_SELF_SPECS
>>> +# define SUBTARGET_DRIVER_SELF_SPECS
>>> +#endif
>
> Shouldn't we swap these two defines, so
On 7/30/19 9:19 AM, Jakub Jelinek wrote:
On Tue, Jul 30, 2019 at 09:16:45AM -0600, Martin Sebor wrote:
Say something like this POC:
We have those already, see ctz_hwi, clz_hwi etc.
The thing is that BITMAP_WORD isn't always the same type as unsigned
HOST_WIDE_INT, and so we need ones with the
On Tue, Jul 30, 2019 at 09:16:45AM -0600, Martin Sebor wrote:
> Say something like this POC:
We have those already, see ctz_hwi, clz_hwi etc.
The thing is that BITMAP_WORD isn't always the same type as unsigned
HOST_WIDE_INT, and so we need ones with the BITMAP_WORD type.
Jakub
On 7/30/19 8:37 AM, Richard Biener wrote:
I've played with different BITMAP_WORD and BITMAP_ELEMENT_WORDS
values and found the code using CTZ and friends a bit unwieldly
to adjust. So I came up with a set of macros wrapping them
(_maybe_ inline overloads would be a cleaner solution, but ...).
Hi all,
>On 30/07/2019 10:31, Ramana Radhakrishnan wrote:
>> On 30/07/2019 10:08, Christophe Lyon wrote:
>>> Hi Wilco,
>>>
>>> Do you know which benchmarks were used when this was checked-in?
>>> It isn't clear from
>>> https://gcc.gnu.org/ml/gcc-patches/2012-07/msg00706.html
>>
>> It
On 7/30/19 4:55 AM, Richard Biener wrote:
On Fri, Jul 26, 2019 at 4:32 PM Andrew MacLeod wrote:
On 7/25/19 11:37 PM, Jeff Law wrote:
On 7/24/19 12:33 PM, Richard Biener wrote:
On July 24, 2019 8:18:57 PM GMT+02:00, Jeff Law
wrote:
On 7/24/19 11:00 AM, Richard Biener wrote: [ Big snip, ignor
On 7/30/19 3:37 PM, Martin Liška wrote:
> Hi.
>
> Thanks to Martin I was able to prepare a proper fix. The issue is that
> cgraph_edge::resolve_speculation can delete this pointer (yes, it's
> super nasty) and so that the caller can't use this->something
> right after the function returns.
>
> Fo
On 7/30/19 2:44 AM, Richard Biener wrote:
On Tue, Jul 30, 2019 at 10:35 AM Jakub Jelinek wrote:
On Tue, Jul 30, 2019 at 10:21:15AM +0200, Richard Biener wrote:
Would you need to LTO stream & merge the bitmaps / maps somehow?
Yes. And if we do not throw unneeded warnings from the sets norma
The following addresses value_range::union_ranges which ends up
doing quite some redundant work for the PR91257 testcase via
PHI argument processing. compare_values isn't really much
slower once you may end up needing more than a single
operand_less_p - in fact for non-constant ranges it often e
I've played with different BITMAP_WORD and BITMAP_ELEMENT_WORDS
values and found the code using CTZ and friends a bit unwieldly
to adjust. So I came up with a set of macros wrapping them
(_maybe_ inline overloads would be a cleaner solution, but ...).
Specifically it looks like for PR91257 maki
On Tue, 30 Jul 2019, Martin Liška wrote:
Ah, that's bad, both of them need a care:
Yes, that makes more sense to me, thanks.
I tried to experiment to understand, but it is complicated because including
disables the optimization:
#include
void fn1() {
char*p=new char;
delete p;
}
On 29/05/2019 15:47, Srinath Parvathaneni wrote:
Hello,
The initial implementation of the FP16 extension added HFmode support to
a limited number of the standard names. Following
https://gcc.gnu.org/ml/gcc-patches/2016-08/msg00168.html , this patch
extends the HFmode support to the names imp
On 7/29/19 3:35 PM, Martin Liška wrote:
> Hi.
>
> I'm sending v2 of the patch that can newly auto-detect make
> jobserver and use it.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Thanks,
> Martin
>
Ok, I've discussed the latest version
On Tue, 30 Jul 2019, Jakub Jelinek wrote:
> On Tue, Jul 30, 2019 at 12:20:00PM +0200, Richard Biener wrote:
> > + if (compl_p)
> > + for (ix = 0; ix < BITMAP_ELEMENT_WORDS; ix++)
> > + {
> > + and_elt.bits[ix] = b_elt->bits[ix] & ~c_elt->bits[ix];
> > + overall |= and_elt.bi
On 7/30/19 3:09 PM, Marc Glisse wrote:
> On Tue, 30 Jul 2019, Martin Liška wrote:
>
>> On 7/30/19 1:35 PM, Marc Glisse wrote:
>>> + /* Some delete operators have size as 2nd argument. */
>>>
>>> Some delete operators have 3 arguments. From cp/decl.c:
>>>
>>> /* operator delet
Hi.
Thanks to Martin I was able to prepare a proper fix. The issue is that
cgraph_edge::resolve_speculation can delete this pointer (yes, it's
super nasty) and so that the caller can't use this->something
right after the function returns.
For the long term, I'll rework the ::resolve_speculation f
Hi,
Thanks for the useful feedback.
On Tue, 16 Jul 2019 at 11:54, Richard Sandiford
wrote:
>
> Thanks for doing this in a generic way.
>
> Christophe Lyon writes:
> > @@ -2224,6 +2234,50 @@ handle_weak_attribute (tree *node, tree name,
> >return NULL_TREE;
> > }
> >
> > +/* Handle a "noin
Steve Ellcey writes:
> On Fri, 2019-07-19 at 19:24 +0100, Richard Sandiford wrote:
>>
>> You can probably also remove:
>>
>> tree new_type = build_distinct_type_copy (TREE_TYPE (node->decl));
>> ...
>> TREE_TYPE (node->decl) = new_type;
>>
>> in simd_clone_adjust_argument_type
On 30/07/2019 13:16, Andre Vieira (lists) wrote:
Hi Richard,
I believe this is in line with what you were explaining to me earlier.
The one thing I haven't quite done here is the jump around for if there
is no prolog peeling. Though I think skip_vectors introduces the jumping
we need.
Th
On Tue, 30 Jul 2019, Martin Liška wrote:
On 7/30/19 1:35 PM, Marc Glisse wrote:
+ /* Some delete operators have size as 2nd argument. */
Some delete operators have 3 arguments. From cp/decl.c:
/* operator delete (void *, size_t, align_val_t); */
Yep, I know. The patch
On Thu, Jul 25, 2019 at 7:34 PM Peter Bergner wrote:
>
> Uros and Jan,
>
> I should have CC'd you for the i386 portion of the patch. Are you ok with
> the i386.h change if Iain's x86 Darwin testing comes out clean?
>
> Peter
>
>
> On 7/25/19 9:41 AM, Peter Bergner wrote:
> > On 7/25/19 2:50 AM, I
On 30/07/2019 10:31, Ramana Radhakrishnan wrote:
On 30/07/2019 10:08, Christophe Lyon wrote:
On Mon, 29 Jul 2019 at 18:49, Wilco Dijkstra
wrote:
Currently the Arm backend selects the alternative sched pressure
algorithm.
The issue is that this doesn't take register pressure into account,
> Most but not all of the tests that expect M_PI, M_PI_2 and/or M_PI_4
> to be defined in math.h explicitly exclude one target system that does
> not satisfy this non-standard assumption.
>
> This patch introduces a wrapper header that includes math.h and then
> conditionally supplies the missing n
On 30/07/2019 11:50, Richard Sandiford wrote:
Richard Biener writes:
On Tue, Jul 30, 2019 at 12:04 PM Richard Sandiford
wrote:
tree-ssa-math-opts supports FMA optabs for integers as well as
floating-point types, even though there's no distinction between
fused and unfused there. It turns
Hi Richard,
I believe this is in line with what you were explaining to me earlier.
The one thing I haven't quite done here is the jump around for if there
is no prolog peeling. Though I think skip_vectors introduces the jumping
we need.
The main gist of it is:
1) if '--param vect-epilogues-n
On Mon, 29 Jul 2019, Richard Biener wrote:
>
> The following patch addresses appearant quadraticness in PTAs
> SCC merging algorithm which does (simplified)
>
> for (node N in SCC)
>bitmap_ior_into (pred(leader), pred(N));
>
> with the linked list implementation this leads to increasingly
On 7/30/19 1:35 PM, Marc Glisse wrote:
> + /* Some delete operators have size as 2nd argument. */
>
> Some delete operators have 3 arguments. From cp/decl.c:
>
> /* operator delete (void *, size_t, align_val_t); */
>
Yep, I know. The patch I installed expects at least 2 ar
+ /* Some delete operators have size as 2nd argument. */
Some delete operators have 3 arguments. From cp/decl.c:
/* operator delete (void *, size_t, align_val_t); */
--
Marc Glisse
On Tue, Jul 30, 2019 at 12:50 PM Richard Sandiford
wrote:
>
> Richard Biener writes:
> > On Tue, Jul 30, 2019 at 12:04 PM Richard Sandiford
> > wrote:
> >>
> >> tree-ssa-math-opts supports FMA optabs for integers as well as
> >> floating-point types, even though there's no distinction between
>
Richard Biener writes:
> On Tue, Jul 30, 2019 at 12:04 PM Richard Sandiford
> wrote:
>>
>> tree-ssa-math-opts supports FMA optabs for integers as well as
>> floating-point types, even though there's no distinction between
>> fused and unfused there. It turns out to be pretty handy for the
>> IFN
On Tue, Jul 30, 2019 at 12:20:00PM +0200, Richard Biener wrote:
> + if (compl_p)
> + for (ix = 0; ix < BITMAP_ELEMENT_WORDS; ix++)
> + {
> + and_elt.bits[ix] = b_elt->bits[ix] & ~c_elt->bits[ix];
> + overall |= and_elt.bits[ix];
> + }
> + else
> + for (
On Tue, Jul 30, 2019 at 12:04 PM Richard Sandiford
wrote:
>
> tree-ssa-math-opts supports FMA optabs for integers as well as
> floating-point types, even though there's no distinction between
> fused and unfused there. It turns out to be pretty handy for the
> IFN_COND_* handling though, so I don
On Tue, Jul 30, 2019 at 12:01 PM Richard Sandiford
wrote:
>
> This patch extends the FMA handling in tree-ssa-math-opts.c so
> that it can cope with conditional multiplications as well as
> unconditional multiplications. The addition or subtraction must then
> have the same condition as the multi
On Tue, Jul 30, 2019 at 12:11 PM Martin Liška wrote:
>
> On 7/30/19 10:40 AM, Richard Biener wrote:
> > On Tue, Jul 30, 2019 at 10:07 AM Martin Liška wrote:
> >>
> >> On 7/30/19 9:46 AM, Martin Liška wrote:
> >>> Anyway that's not a candidate for DCE. I'm testing following patch.
> >>
> >> Patch
On Tue, 30 Jul 2019, Richard Biener wrote:
>
> bitmap_ior_and_compl_into is currently doing bitmap_and_compl into
> a temporary bitmap and then bitmap_ior_into. The following uses
> the existing implementation of bitmap_ior_and_into and exchanges
> the core worker based on a template parameter.
bitmap_ior_and_compl_into is currently doing bitmap_and_compl into
a temporary bitmap and then bitmap_ior_into. The following uses
the existing implementation of bitmap_ior_and_into and exchanges
the core worker based on a template parameter.
This results in a slight savings in out-of-SSA time
On 7/30/19 10:40 AM, Richard Biener wrote:
> On Tue, Jul 30, 2019 at 10:07 AM Martin Liška wrote:
>>
>> On 7/30/19 9:46 AM, Martin Liška wrote:
>>> Anyway that's not a candidate for DCE. I'm testing following patch.
>>
>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>>
>>
tree-ssa-math-opts supports FMA optabs for integers as well as
floating-point types, even though there's no distinction between
fused and unfused there. It turns out to be pretty handy for the
IFN_COND_* handling though, so I don't want to remove it, however
weird it might seem.
Instead this patc
This patch extends the FMA handling in tree-ssa-math-opts.c so
that it can cope with conditional multiplications as well as
unconditional multiplications. The addition or subtraction must then
have the same condition as the multiplication (at least for now).
E.g. we can currently fold:
(IFN_CO
lra_insn_reg and lra_operand_data have both a bitmask of earlyclobber
alternatives and an overall boolean. The danger is that we then test
the overall boolean when really we should be testing for a particular
alternative. This patch gets rid of the boolean and tests the mask
against zero when we
On Tue, Jul 30, 2019 at 11:33 AM Jan Hubicka wrote:
>
> > On Tue, Jul 30, 2019 at 10:09 AM Jan Hubicka wrote:
> > >
> > > > Hi,
> > > > this patch updates znver2 costs to match reality. In particular we
> > > > re-benchmarked memcpy strategies and it looks that glibc now wins even
> > > > for re
> On Tue, Jul 30, 2019 at 10:09 AM Jan Hubicka wrote:
> >
> > > Hi,
> > > this patch updates znver2 costs to match reality. In particular we
> > > re-benchmarked memcpy strategies and it looks that glibc now wins even
> > > for relatively small blocks.
> > > Moreover I updated costs of moves to r
On 30/07/2019 10:08, Christophe Lyon wrote:
On Mon, 29 Jul 2019 at 18:49, Wilco Dijkstra wrote:
Currently the Arm backend selects the alternative sched pressure algorithm.
The issue is that this doesn't take register pressure into account, and so
it causes significant additional spilling on Ar
> Hi,
> this patch adds znver2 scheduler model. Znver2 is close enough to znver1
> that I have decided to implement it in one automaton. The main
> difference is extra AGU unit that seems to be used for store only
> (according to CPU diagram), the fact that 256bit vector operations are
> no longer
On Mon, 29 Jul 2019 at 18:49, Wilco Dijkstra wrote:
>
> Currently the Arm backend selects the alternative sched pressure algorithm.
> The issue is that this doesn't take register pressure into account, and so
> it causes significant additional spilling on Arm where there are only 14
> allocatable
Hi Gerald,
The update link will be
http://www.andestech.com/en/products-solutions/product-documentation/
Thanks for your kindly remind,
Shiva
Gerald Pfeifer 於 2019年7月28日 週日 下午4:54寫道：
> I could not find an updated link on www.andestech.com, in fact the
> reference I could find there was broken a
On Fri, Jul 26, 2019 at 4:32 PM Andrew MacLeod wrote:
>
> On 7/25/19 11:37 PM, Jeff Law wrote:
> > On 7/24/19 12:33 PM, Richard Biener wrote:
> >> On July 24, 2019 8:18:57 PM GMT+02:00, Jeff Law
> >> wrote:
> >>> On 7/24/19 11:00 AM, Richard Biener wrote: [ Big snip, ignore
> >>> missing reply at
> 0) complexifies comparison of thread IDs without obvious benefits, and
The reverse argument is also true: using IDs would complexify everything else
with the only benefit of simplifying the equal primitive.
> 1) does not work reliably because handles can be duplicated, and
That's pure FUD.
>
On Jul 17, 2019, Alexandre Oliva wrote:
> Most but not all of the tests that expect M_PI, M_PI_2 and/or M_PI_4
> to be defined in math.h explicitly exclude one target system that does
> not satisfy this non-standard assumption.
> This patch introduces a wrapper header that includes math.h and th
On 7/30/19 10:36 AM, Richard Biener wrote:
> On Tue, Jul 30, 2019 at 9:27 AM Martin Liška wrote:
>>
>> Hi.
>>
>> We have to clean up dangling pointers before we call ggc_free for a
>> cgraph_edge.
>>
>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>> And it survives --en
On Tue, Jul 30, 2019 at 10:35 AM Jakub Jelinek wrote:
>
> On Tue, Jul 30, 2019 at 10:21:15AM +0200, Richard Biener wrote:
> > Would you need to LTO stream & merge the bitmaps / maps somehow?
>
> Yes. And if we do not throw unneeded warnings from the sets normally, LTO
> streaming might be a good
On Tue, Jul 30, 2019 at 10:09 AM Jan Hubicka wrote:
>
> > Hi,
> > this patch updates znver2 costs to match reality. In particular we
> > re-benchmarked memcpy strategies and it looks that glibc now wins even
> > for relatively small blocks.
> > Moreover I updated costs of moves to reflect that zn
On Tue, Jul 30, 2019 at 10:07 AM Martin Liška wrote:
>
> On 7/30/19 9:46 AM, Martin Liška wrote:
> > Anyway that's not a candidate for DCE. I'm testing following patch.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> One alternative approach can be to drop DECL_SET_I
On Tue, Jul 30, 2019 at 9:27 AM Martin Liška wrote:
>
> Hi.
>
> We have to clean up dangling pointers before we call ggc_free for a
> cgraph_edge.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> And it survives --enable-checking=release bootstrap on x86_64-linux-gnu.
On Tue, Jul 30, 2019 at 10:21:15AM +0200, Richard Biener wrote:
> Would you need to LTO stream & merge the bitmaps / maps somehow?
Yes. And if we do not throw unneeded warnings from the sets normally, LTO
streaming might be a good time to do that, so that we merge in only warnings
that will be te
On Mon, Jul 29, 2019 at 6:03 PM Jakub Jelinek wrote:
>
> On Wed, Jul 24, 2019 at 12:07:36PM -0600, Martin Sebor wrote:
> > > > There are a number of existing instances of setting TREE_NO_WARNING
> > > > to suppress -Wuninitialized, and some are the cause of known problems.
> > > > Bugs 51545, 5895
> Hi,
> this patch enables logic which avoid FMA for matrix multiplicaiton loop
> for 256 bit vectors. The underlying issue is same as with znver1. While
> combined latency of mutliply and add operations is slower than FMA, the
> dependency chain in matrix multiplication depends only on additions
>
> Hi,
> this patch updates znver2 costs to match reality. In particular we
> re-benchmarked memcpy strategies and it looks that glibc now wins even
> for relatively small blocks.
> Moreover I updated costs of moves to reflect that znver2 has 256 vector
> paths and faster multiplication.
>
> Boot
On 7/30/19 9:46 AM, Martin Liška wrote:
> Anyway that's not a candidate for DCE. I'm testing following patch.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
One alternative approach can be to drop DECL_SET_IS_OPERATOR_DELETE in:
cat -n gcc/cp/decl.c | less
...
4410
On 7/29/19 3:46 PM, Georg-Johann Lay wrote:
> Hi Martin.
>
> In SVN r273662 you changed a comment in avr.c from __gnu_lto_v1 to
> __gnu_lto_slim without changing the relevant code:
Yes.
>
> /* __gnu_lto_slim is just a marker for the linker injected by toplev.c.
> There is no need to tri
Hi.
After playing with the test-case, I noticed that we don't want
to handle new/delete operators with a varying (SSA_NAME) as a second argument.
Considering following test-case:
$ cat /tmp/new.C
struct S {
S ();
~S();
};
int a = 123;
void fn1() {
S *s = new S[a];
delete[] s;
}
$ ./xg++
On Tue, Jul 30, 2019 at 09:35:04AM +0200, Richard Biener wrote:
> Looks OK to me but I'd like Joseph to chime in here. I think for
Ok, will wait for Joseph.
> FE support it means adding actual _widening_ casts to the effective
> compute precision type (thus long double). But once that's done
>
On Tue, 30 Jul 2019, Jakub Jelinek wrote:
> On Tue, Jul 02, 2019 at 04:43:54PM +, Tamar Christina wrote:
> > Here's an updated patch with the changes processed from the previous review.
> >
> > I've bootstrapped and regtested on aarch64-none-linux-gnu and
> > x86_64-pc-linux-gnu and no issue
Hi!
We ICE on the following testcase, because the reduction is expanded as
__atomic_* operation on the address of the global variable which makes the
global var, previously not TREE_ADDRESSABLE, suddenly TREE_ADDRESSABLE
during the lowering, but after scanning when we decided how to pass certain
v
On Tue, 30 Jul 2019, Jakub Jelinek wrote:
> On Tue, Jul 30, 2019 at 09:05:35AM +0200, Rainer Orth wrote:
> > > This new testcase FAILs e.g. on i686-linux. The problem is that
> >
> > this is PR middle-end/91282.
>
> Indeed.
>
> > > with no dg-options, the testcase options default to -ansi, whi
Hi.
We have to clean up dangling pointers before we call ggc_free for a cgraph_edge.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
And it survives --enable-checking=release bootstrap on x86_64-linux-gnu.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
2019-07-30
Testing the following.
Richard.
2019-07-30 Richard Biener
PR tree-optimization/91291
* tree-ssa-sccvn.c (rpo_elim::eliminate_push_avail): Ignore
constant values.
Index: gcc/tree-ssa-sccvn.c
===
--- gcc/
Hi!
Neither c_expr_sizeof_expr nor c_expr_sizeof_type bother with filling up
the locations in c_expr struct they return. Normally, this isn't a problem,
as the sole caller of those calls set_c_expr_source_range. It doesn't call
it though if we reach CPP_EOF while parsing the sizeof expression.
L
Hi!
As the following testcase shows, for V64QImode expand_vec_perm_blend
needs to build a 64-bit mask, so using unsigned type for it results in
wrong-code.
While the testcase in the PR which also requires AVX512VBMI regressed
recently, the actual bug as shown by this different testcase is there
si
Hi,
This patch includes C front-end code for a type qualifier _Dependent_ptr.
The patch has been tested using the following
make bootstrap -j 4
make -k check -j 4
on x86_64-linux-gnu.
Thanks,
Akshat
gcc/ChangeLog:
2019-07-30 Akshat Garg
* c-family/c-common.c (struct c_common_resword
On Tue, Jul 30, 2019 at 09:05:35AM +0200, Rainer Orth wrote:
> > This new testcase FAILs e.g. on i686-linux. The problem is that
>
> this is PR middle-end/91282.
Indeed.
> > with no dg-options, the testcase options default to -ansi, which
> > implies -fexcess-precision=standard. On i686-linux,
On Tue, Jul 02, 2019 at 04:43:54PM +, Tamar Christina wrote:
> Here's an updated patch with the changes processed from the previous review.
>
> I've bootstrapped and regtested on aarch64-none-linux-gnu and
> x86_64-pc-linux-gnu and no issues.
These changes also broke gcc.dg/torture/c99-contr
Hi Jakub,
> On Tue, Jul 02, 2019 at 04:43:54PM +, Tamar Christina wrote:
>> --- /dev/null
>> +++ b/gcc/testsuite/gcc.dg/type-convert-var.c
>> @@ -0,0 +1,9 @@
>> +/* { dg-do compile } */
>> +/* { dg-additional-options "-O1 -fdump-tree-optimized" } */
>> +void foo (float a, float b, float *c)
>>
89 matches
Mail list logo
