On Wed, 30 Mar 2016, Jakub Jelinek wrote:
> On Wed, Mar 30, 2016 at 02:07:07PM +0200, Richard Biener wrote:
> > The patch for PR63764 (accepts-invalid / ICE) caused us to generate
> > worse code for rvalue vector indexing by forcing the vector to a
> > temporary. It turns out this is not necessar
On 31 March 2016 at 16:43, Andrey Belevantsev wrote:
> Hello,
>
> On 14.03.2016 12:10, Andrey Belevantsev wrote:
>>
>> Hello,
>>
>> In this thread I will be posting the patches for the fixed selective
>> scheduling PRs (except the one that was already kindly checked in by
>> Jeff).
>> The patches
On Fri, Apr 1, 2016 at 6:54 AM, Segher Boessenkool
wrote:
> Sometimes people write loops that they do not want optimized away, even
> when the compiler can replace those loops by a simple expression (or
> nothing). For such people, this patch adds a compiler option.
>
> Bootstrapped on powerpc64-
On 31 March 2016 at 16:55, Andrey Belevantsev wrote:
> Hello,
>
> On 12.03.2016 20:13, Jeff Law wrote:
>>
>>
>> As Andrey outlined in the PR, selective-scheduling was missing a check &
>> handling of hard registers in modes that span more than one hard reg. This
>> caused an incorrect register sel
Hi Christophe,
On 01.04.2016 10:33, Christophe Lyon wrote:
On 31 March 2016 at 16:43, Andrey Belevantsev wrote:
Hello,
On 14.03.2016 12:10, Andrey Belevantsev wrote:
Hello,
In this thread I will be posting the patches for the fixed selective
scheduling PRs (except the one that was already
Hi!
On Thu, 24 Mar 2016 22:31:29 +0100, I wrote:
> On Wed, 23 Mar 2016 19:57:50 +0100, Bernd Schmidt wrote:
> > Ok with [...].
>
> Thanks for the review; committed in r234471:
> Also test -O0 for OpenACC C, C++ offloading test cases
Merged into gomp-4_0-branch in r234664:
commit 9973610b0
RTL DSE uses true_dependence to see whether a store may be killed by
anothe store - that's obviously broken. The following patch makes
it use output_dependence instead (introducing a canon_ variant of that).
Bootstrap & regtest running on x86_64-unknown-linux-gnu.
Ok?
Thanks,
Richard.
2016-04
On Fri, Apr 01, 2016 at 11:08:09AM +0200, Richard Biener wrote:
>
> RTL DSE uses true_dependence to see whether a store may be killed by
> anothe store - that's obviously broken. The following patch makes
> it use output_dependence instead (introducing a canon_ variant of that).
I think it would
On Fri, 1 Apr 2016, Jakub Jelinek wrote:
> On Fri, Apr 01, 2016 at 11:08:09AM +0200, Richard Biener wrote:
> >
> > RTL DSE uses true_dependence to see whether a store may be killed by
> > anothe store - that's obviously broken. The following patch makes
> > it use output_dependence instead (intr
On Mon, Jan 25, 2016 at 12:15:48PM +, James Greenhalgh wrote:
> On Wed, Jan 20, 2016 at 09:27:41PM +0100, Roger Ferrer Ibáñez wrote:
> > Hi James,
> >
> > > This patch looks technically correct to me, though there is a small
> > > style issue to correct (in-line below), and your ChangeLogs don
Hi,
This fixes the write access violation detailed in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70498 (and a few other unreported
cases).
Sometimes length-variables for strings and arrays are of type long other times
of type int. Since cp-demangle.h exports structs and methods with
length-
Hi,
This patch replaces "string.h" with "strlenopt.h" in all tests
checking string function optimizations with CHKP. I added memmove
definition to strlenopt.h for that.
Regtested on x86_64-pc-linux-gnu and checked PR69890 is resolved
on Darwin by Dominique d'Humieres. Is strlenopt.h extension a
On Fri, Apr 01, 2016 at 01:28:10PM +0300, Ilya Enkovich wrote:
> This patch replaces "string.h" with "strlenopt.h" in all tests
> checking string function optimizations with CHKP. I added memmove
> definition to strlenopt.h for that.
>
> Regtested on x86_64-pc-linux-gnu and checked PR69890 is res
Thanks to all for the helpful explanations. We plan to leave things as
they are. I hope someday we can make some time to do some basic
investigations here.
Bill
On Fri, 2016-04-01 at 00:09 -0500, Aldy Hernandez wrote:
> Richard Biener writes:
>
> > Hell, even slapping a xfail powerpc*-*-* on
On 04/01/2016 12:21 PM, Marcel Böhme wrote:
This fixes the write access violation detailed in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70498 (and a few other
unreported cases).
Sometimes length-variables for strings and arrays are of type long
other times of type int. Since cp-demangle.h exp
Cc'ing Matt Thomas who is listed as the vax maintainer; most of the
patch should be reviewed by him IMO. If he is no longer active I'd
frankly rather deprecate the port rather than invest effort in keeping
it running.
Index: gcc/except.c
===
On Thu, Mar 31, 2016 at 05:18:13PM -0400, Patrick Palka wrote:
> I hope someone else could do it since I'm not very familiar with the C
> parser :) I think Marek said he would take care of it.
Sure, happy to.
Marek
On 31 March 2016 at 10:57, Jakub Jelinek wrote:
> On Thu, Mar 31, 2016 at 09:53:28AM +0100, Kyrill Tkachov wrote:
>>
>> On 31/03/16 09:48, Christophe Lyon wrote:
>> >On 30 March 2016 at 14:49, Jakub Jelinek wrote:
>> >>Hi!
>> >>
>> >>I've bootstrapped/regtested on x86_64-linux and i686-linux foll
A stackoverflow poster was confused by the comments on
basic_string::length() which talk about null-temrination, as it isn't
obvious that embedded nulls are not terminators.
I think this makes it clearer, but would appreciate other opinions.
(The @{ and @} commands tell doxygen to use the same c
In working on 55635 I noticed the comment for TRY_CATCH_EXPR was confusing. It
is using 'operand 1' and 'operand 2' to mean 'first' and 'second', not literally
op[1] and op[2]. Fixed to use indices 0 and 1.
Applied as obvious.
nathan
2016-04-01 Nathan Sidwell
* tree.def (TRY_CATCH_EXP
On 1 April 2016 at 10:54, Andrey Belevantsev wrote:
> Hi Christophe,
>
>
> On 01.04.2016 10:33, Christophe Lyon wrote:
>>
>> On 31 March 2016 at 16:43, Andrey Belevantsev wrote:
>>>
>>> Hello,
>>>
>>> On 14.03.2016 12:10, Andrey Belevantsev wrote:
Hello,
In this thread I
Hi Christophe, Andrey,
On 01/04/16 14:09, Christophe Lyon wrote:
On 1 April 2016 at 10:54, Andrey Belevantsev wrote:
Hi Christophe,
On 01.04.2016 10:33, Christophe Lyon wrote:
On 31 March 2016 at 16:43, Andrey Belevantsev wrote:
Hello,
On 14.03.2016 12:10, Andrey Belevantsev wrote:
Hel
Hi!
As the testcase below shows, we can end up with lots of useless
instructions from multi-word arithmetics.
simplify-rtx.c can optimize x {&,|,^}= {0,-1}, but while
x &= 0 or x {|,^}= -1 are optimized into constants and CSE can handle those
fine, we keep x &= -1 and x {|,^}= 0 in the IL until ex
Hi!
As the testcase below shows, we generate awful code for double word
additions/subtractions if the last argument is a constant that has the
whole low word 0 (and only nonzero some of the upper bits).
In that case, there is no point doing useless addl $0, ... followed by
adcl $something, ... bec
Hi!
The previous patch apparently isn't enough for TImode, because
we don't even allow the CONST_WIDE_INT operands in there, it uses
"e" constraint and similar predicate. All we care about is that
both of the words of the argument can be expressed as addq/adcq/subq/sbbq
immediates, so this patch
On 1 April 2016 at 15:12, Kyrill Tkachov wrote:
> Hi Christophe, Andrey,
>
>
> On 01/04/16 14:09, Christophe Lyon wrote:
>>
>> On 1 April 2016 at 10:54, Andrey Belevantsev wrote:
>>>
>>> Hi Christophe,
>>>
>>>
>>> On 01.04.2016 10:33, Christophe Lyon wrote:
On 31 March 2016 at 16:43, An
On 04/01/2016 03:14 PM, Jakub Jelinek wrote:
As the testcase below shows, we can end up with lots of useless
instructions from multi-word arithmetics.
simplify-rtx.c can optimize x {&,|,^}= {0,-1}, but while
x &= 0 or x {|,^}= -1 are optimized into constants and CSE can handle those
fine, we keep
Hi Bernd,
Thanks for the feedback!
> Patches need to be bootstrapped and regression tested, and patch submissions
> should include which target this was done on.
>
> Ideally you'd also want to include testcases along with your patches,
> although I'm not entirely sure how we can arrange for th
Evandro Menezes wrote:
>
> Ping^1
I haven't seen a newer version that incorporates my feedback. To recap what
I'd like to see is a more general way to select approximations based on mode.
I don't believe that looking at the inner mode works in general, and it doesn't
make sense to add internal tu
Hi,
The attached patch introduces param max-lto-partition which creates an upper
bound for partition size.
My primary motivation for this patch is to fix building chromium for arm
with -flto-partition=one.
Chromium fails to build with -flto-partition={none, one} with assembler error:
"branch out o
> Since d_identifier takes an int as length, d_identifier is called with a
> negative length after the implicit cast:
Sorry, d_make_name called from d_identifier in cp_demangle.c:1721 takes an int
as length.
Best regards
- Marcel
Evandro Menezes wrote:
On 03/23/16 11:24, Evandro Menezes wrote:
> On 03/17/16 15:09, Evandro Menezes wrote:
>> This patch implements FP division by an approximation using the Newton
>> series.
>>
>> With this patch, DF division is sped up by over 100% and SF division,
>> zilch, both on A57 and on
On Fri, Apr 01, 2016 at 02:47:05PM +0100, Wilco Dijkstra wrote:
> Evandro Menezes wrote:
> >
> > Ping^1
>
> I haven't seen a newer version that incorporates my feedback. To recap what
> I'd like to see is a more general way to select approximations based on mode.
> I don't believe that looking at
On 03/31/2016 06:56 AM, Marcel Böhme wrote:
Hi Bernd,
Are all the places being patched really problematic ones where an input file
could realistically cause an overflow, or just the string functions?
The loop in demangle_args allows to call the patched register*- and
remember*-methods arbitr
On 04/01/2016 03:39 PM, Marcel Böhme wrote:
Hi Bernd,
Thanks for the feedback!
Patches need to be bootstrapped and regression tested, and patch
submissions should include which target this was done on.
Ideally you'd also want to include testcases along with your
patches, although I'm not enti
The bug in PR70289 is an assertion failure triggered by a static
variable used inside an offloaded acc region which doesn't have a data
clause associated with it. Basically, that static variable ends up in a
different lto partition, which was not streamed to the offloaded
compiler. I'm not sure if
On 04/01/16 08:47, Wilco Dijkstra wrote:
Evandro Menezes wrote:
Ping^1
I haven't seen a newer version that incorporates my feedback. To recap what
I'd like to see is a more general way to select approximations based on mode.
I don't believe that looking at the inner mode works in general, and i
On Fri, Apr 01, 2016 at 03:35:19PM +0200, Bernd Schmidt wrote:
> On 04/01/2016 03:14 PM, Jakub Jelinek wrote:
> >As the testcase below shows, we can end up with lots of useless
> >instructions from multi-word arithmetics.
> >simplify-rtx.c can optimize x {&,|,^}= {0,-1}, but while
> >x &= 0 or x {|
Hi!
Committed to gomp-4_0-branch in r234674:
commit e7e9a6012dca0546a8b1cd16bf51acdd85ec7654
Merge: 9973610 ef4f1cb
Author: tschwinge
Date: Fri Apr 1 14:23:38 2016 +
svn merge -r 234471:234572 svn+ssh://gcc.gnu.org/svn/gcc/trunk
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/
On 04/01/16 09:06, James Greenhalgh wrote:
On Fri, Apr 01, 2016 at 02:47:05PM +0100, Wilco Dijkstra wrote:
Evandro Menezes wrote:
Ping^1
I haven't seen a newer version that incorporates my feedback. To recap what
I'd like to see is a more general way to select approximations based on mode.
I d
On Fri, Apr 01, 2016 at 07:49:16AM -0700, Cesar Philippidis wrote:
> The bug in PR70289 is an assertion failure triggered by a static
> variable used inside an offloaded acc region which doesn't have a data
> clause associated with it. Basically, that static variable ends up in a
> different lto pa
On 04/01/2016 04:51 PM, Jakub Jelinek wrote:
On Fri, Apr 01, 2016 at 03:35:19PM +0200, Bernd Schmidt wrote:
On 04/01/2016 03:14 PM, Jakub Jelinek wrote:
As the testcase below shows, we can end up with lots of useless
instructions from multi-word arithmetics.
simplify-rtx.c can optimize x {&,|,^
Hi,
While doing the unified asm rewrite - I inadvertently changed the
meaning of ASM_APP_OFF which causes failures when folks who know what
they are doing switch between arm and thumb states within a
function. The intent of the unified asm rewrite was not to affect any
inline assembler cod
This is another case where a C_MAYBE_CONST_EXPR leaks into the gimplifier.
Starting with r229128 and thus introduction of build_vec_cmp we now create
VEC_COND_EXPR when building a vector comparison. The C_MAYBE_CONST_EXPR
originated in build_compound_literal when creating a COMPOUND_LITERAL_EXPR.
On Fri, Apr 01, 2016 at 11:44:16AM +0200, Richard Biener wrote:
> On Fri, 1 Apr 2016, Jakub Jelinek wrote:
>
> > On Fri, Apr 01, 2016 at 11:08:09AM +0200, Richard Biener wrote:
> > >
> > > RTL DSE uses true_dependence to see whether a store may be killed by
> > > anothe store - that's obviously b
On 04/01/2016 07:56 AM, Jakub Jelinek wrote:
> On Fri, Apr 01, 2016 at 07:49:16AM -0700, Cesar Philippidis wrote:
>> The bug in PR70289 is an assertion failure triggered by a static
>> variable used inside an offloaded acc region which doesn't have a data
>> clause associated with it. Basically, th
Hi!
The new warn_placement_new_too_small function blindly assumes that
if {DECL,TYPE}_SIZE_UNIT is non-NULL, then it must be INTEGER_CST
that fits into uhwi. That is not the case, it could be a VLA, etc.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
ok for trunk?
OT, as I
On Fri, Apr 01, 2016 at 08:07:24AM -0700, Cesar Philippidis wrote:
> On 04/01/2016 07:56 AM, Jakub Jelinek wrote:
> > On Fri, Apr 01, 2016 at 07:49:16AM -0700, Cesar Philippidis wrote:
> >> The bug in PR70289 is an assertion failure triggered by a static
> >> variable used inside an offloaded acc r
On 04/01/2016 05:05 PM, Jakub Jelinek wrote:
with my usual pair of rtl,yes checking bootstraps/regtests (x86_64-linux
and i686-linux, former one with ada, latter without), both without your
patch and with the patch.
Without the patch got 66555 successful replace_reads, with your patch
only 65971,
On Fri, Apr 01, 2016 at 09:36:49AM +0200, Richard Biener wrote:
> On Fri, Apr 1, 2016 at 6:54 AM, Segher Boessenkool
> wrote:
> > Sometimes people write loops that they do not want optimized away, even
> > when the compiler can replace those loops by a simple expression (or
> > nothing). For such
On 04/01/2016 09:11 AM, Jakub Jelinek wrote:
Hi!
The new warn_placement_new_too_small function blindly assumes that
if {DECL,TYPE}_SIZE_UNIT is non-NULL, then it must be INTEGER_CST
that fits into uhwi. That is not the case, it could be a VLA, etc.
Fixed thusly, bootstrapped/regtested on x86_6
this fixes bug 55635 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55635
Somewhat surprisingly, a delete expression should always call the operator
delete function, regardless of whether the object destructor(s) throw. See this
note at the end of 5.3.5/7:
[Note: The deallocation function is c
While the expander accepts general_operand as src operand the risbg
pattern only immediate_operand. Unfortunately the expander called
force_reg only for VOIDmode constants missing things like
e.g. symbol_refs. Fixed with the attached patch.
Bootstrapped on s390 and s390x.
This fixes the pr70174
On 04/01/2016 11:08 AM, Richard Biener wrote:
{
! if (canon_true_dependence (s_info->mem,
!GET_MODE (s_info->mem),
!s_info->mem_addr,
!mem, mem_addr))
{
Hi,
On Thu, Mar 31, 2016 at 12:50:54PM +0200, Martin Liska wrote:
> On 03/29/2016 01:44 PM, Martin Liška wrote:
> > Second part of the patch set which omits one split_block (compared to the
> > original patch).
> > Acceptable just in case the first part will be accepted.
> >
> > Thanks
> > Marti
I've had this in my tree for a few months now but never got
around to submitting it.
This partially fixes PR target/53440 atleast in ARM and
Thumb2 state. I haven't yet managed to get my head around
rewriting the Thumb1 support yet.
Tested on armhf with a bootstrap and regression test
with no reg
On Thu, Mar 31, 2016 at 9:54 PM, Segher Boessenkool
wrote:
> Sometimes people write loops that they do not want optimized away, even
> when the compiler can replace those loops by a simple expression (or
> nothing). For such people, this patch adds a compiler option.
The Linux kernel has a nice
On Fri, Apr 1, 2016 at 3:18 PM, Jakub Jelinek wrote:
> Hi!
>
> As the testcase below shows, we generate awful code for double word
> additions/subtractions if the last argument is a constant that has the
> whole low word 0 (and only nonzero some of the upper bits).
> In that case, there is no poin
On 04/01/2016 09:11 AM, Jakub Jelinek wrote:
Hi!
The new warn_placement_new_too_small function blindly assumes that
if {DECL,TYPE}_SIZE_UNIT is non-NULL, then it must be INTEGER_CST
that fits into uhwi. That is not the case, it could be a VLA, etc.
Fixed thusly, bootstrapped/regtested on x86_6
On 04/01/2016 11:21 AM, Nathan Sidwell wrote:
this fixes bug 55635 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55635
Please include the word "patch" in the subject line of patch email.
The patch looks good, but this doesn't seem to be a regression; do you
think it's an important enough bug t
On 04/01/2016 03:44 AM, Richard Biener wrote:
On Fri, 1 Apr 2016, Jakub Jelinek wrote:
On Fri, Apr 01, 2016 at 11:08:09AM +0200, Richard Biener wrote:
RTL DSE uses true_dependence to see whether a store may be killed by
anothe store - that's obviously broken. The following patch makes
it use
On 04/01/16 11:36, Jason Merrill wrote:
On 04/01/2016 11:21 AM, Nathan Sidwell wrote:
this fixes bug 55635 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55635
Please include the word "patch" in the subject line of patch email.
The patch looks good, but this doesn't seem to be a regression; do
On 04/01/2016 09:03 AM, Marek Polacek wrote:
This is another case where a C_MAYBE_CONST_EXPR leaks into the gimplifier.
Starting with r229128 and thus introduction of build_vec_cmp we now create
VEC_COND_EXPR when building a vector comparison. The C_MAYBE_CONST_EXPR
originated in build_compound_
On Fri, Apr 01, 2016 at 08:32:28AM -0700, Andrew Pinski wrote:
> On Thu, Mar 31, 2016 at 9:54 PM, Segher Boessenkool
> wrote:
> > Sometimes people write loops that they do not want optimized away, even
> > when the compiler can replace those loops by a simple expression (or
> > nothing). For such
On Fri, Apr 01, 2016 at 09:54:39AM -0600, Jeff Law wrote:
> >--- gcc/c/c-fold.c
> >+++ gcc/c/c-fold.c
> >@@ -528,6 +528,23 @@ c_fully_fold_internal (tree expr, bool in_init, bool
> >*maybe_const_operands,
> > *maybe_const_itself &= op2_const_self;
> >goto out;
> >
> >+case VEC_COND
On Fri, Apr 01, 2016 at 06:02:24PM +0200, Jakub Jelinek wrote:
> On Fri, Apr 01, 2016 at 09:54:39AM -0600, Jeff Law wrote:
> > >--- gcc/c/c-fold.c
> > >+++ gcc/c/c-fold.c
> > >@@ -528,6 +528,23 @@ c_fully_fold_internal (tree expr, bool in_init, bool
> > >*maybe_const_operands,
> > > *maybe_const
On Fri, Apr 01, 2016 at 06:14:00PM +0200, Marek Polacek wrote:
> On Fri, Apr 01, 2016 at 06:02:24PM +0200, Jakub Jelinek wrote:
> > On Fri, Apr 01, 2016 at 09:54:39AM -0600, Jeff Law wrote:
> > > >--- gcc/c/c-fold.c
> > > >+++ gcc/c/c-fold.c
> > > >@@ -528,6 +528,23 @@ c_fully_fold_internal (tree e
On 04/01/2016 07:26 AM, Christophe Lyon wrote:
On 1 April 2016 at 15:12, Kyrill Tkachov wrote:
Hi Christophe, Andrey,
On 01/04/16 14:09, Christophe Lyon wrote:
On 1 April 2016 at 10:54, Andrey Belevantsev wrote:
Hi Christophe,
On 01.04.2016 10:33, Christophe Lyon wrote:
On 31 March 2
>
> Forgot about this issue, sorry. At least this needs guarding with #ifdef
> HAVE_LIMITS_H, as in the other files in libiberty. Several of them also go to
> trouble to define the macros if limits.h is missing; not sure how much of an
> issue that is nowadays, but you might want to adapt some
On Fri, Apr 01, 2016 at 06:17:57PM +0200, Jakub Jelinek wrote:
> Those comparisons with truthvalue_*_node would fail and DTRT.
> Or just c_fully_fold_internal all the arguments, be ready for any future
> further uses of VEC_COND_EXPR early?
..thus revive my earlier version of the patch that does i
On Fri, Apr 01, 2016 at 07:10:06PM +0200, Marek Polacek wrote:
> On Fri, Apr 01, 2016 at 06:17:57PM +0200, Jakub Jelinek wrote:
> > Those comparisons with truthvalue_*_node would fail and DTRT.
> > Or just c_fully_fold_internal all the arguments, be ready for any future
> > further uses of VEC_COND
On April 1, 2016 5:26:21 PM GMT+02:00, Bernd Schmidt
wrote:
>On 04/01/2016 11:08 AM, Richard Biener wrote:
>> {
>> ! if (canon_true_dependence (s_info->mem,
>> ! GET_MODE (s_info->mem),
>> ! s_info->mem_addr,
>> !
On April 1, 2016 3:48:35 PM GMT+02:00, Prathamesh Kulkarni
wrote:
>Hi,
>The attached patch introduces param max-lto-partition which creates an
>upper
>bound for partition size.
>
>My primary motivation for this patch is to fix building chromium for
>arm
>with -flto-partition=one.
>Chromium fails
On 03/31/2016 05:35 AM, Christophe Lyon wrote:
On 30 March 2016 at 18:01, Vladimir Makarov wrote:
The patch for PR69614 has been backported to gcc-5 branch:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69614
Committed as rev. 234577.
Hi,
As I've already reported:
https://gcc.gnu.org/
On Fri, Apr 01, 2016 at 07:22:24PM +0200, Jakub Jelinek wrote:
> On Fri, Apr 01, 2016 at 07:10:06PM +0200, Marek Polacek wrote:
> > On Fri, Apr 01, 2016 at 06:17:57PM +0200, Jakub Jelinek wrote:
> > > Those comparisons with truthvalue_*_node would fail and DTRT.
> > > Or just c_fully_fold_internal
On April 1, 2016 5:18:10 PM GMT+02:00, Segher Boessenkool
wrote:
>On Fri, Apr 01, 2016 at 09:36:49AM +0200, Richard Biener wrote:
>> On Fri, Apr 1, 2016 at 6:54 AM, Segher Boessenkool
>> wrote:
>> > Sometimes people write loops that they do not want optimized away,
>even
>> > when the compiler c
On 1 April 2016 at 19:34, Vladimir Makarov wrote:
> On 03/31/2016 05:35 AM, Christophe Lyon wrote:
>>
>> On 30 March 2016 at 18:01, Vladimir Makarov wrote:
>>>
>>>The patch for PR69614 has been backported to gcc-5 branch:
>>>
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69614
>>>
>>>C
On 04/01/2016 11:21 AM, Marcel Böhme wrote:
> static inline void
> -d_append_num (struct d_print_info *dpi, long l)
> +d_append_num (struct d_print_info *dpi, int l)
> {
>char buf[25];
>sprintf (buf,"%ld", l);
Doesn't this warn about %ld format vs int type mismatch?
Thanks,
Pedro Alves
On 04/01/2016 07:41 PM, Pedro Alves wrote:
On 04/01/2016 11:21 AM, Marcel Böhme wrote:
static inline void
-d_append_num (struct d_print_info *dpi, long l)
+d_append_num (struct d_print_info *dpi, int l)
{
char buf[25];
sprintf (buf,"%ld", l);
Doesn't this warn about %ld format vs i
On 03/30/2016 05:23 PM, Christophe Lyon wrote:
On 29 March 2016 at 18:28, Vladimir Makarov wrote:
The following patch improves the code in 2 out of 3 cases in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68695
The patch uses more accurate costs for the RA cost improvement
optimization a
On Fri, Apr 1, 2016 at 3:23 PM, Jakub Jelinek wrote:
> Hi!
>
> The previous patch apparently isn't enough for TImode, because
> we don't even allow the CONST_WIDE_INT operands in there, it uses
> "e" constraint and similar predicate. All we care about is that
> both of the words of the argument c
Hi,
I apologize for the poor quality of the initial version of the patch that I
submitted. I think I may have also mangled it by not disabling the "smart
quotes" feature on my Mac before I pasted in the diff from the terminal window.
I intentionally did not use gmail for fear of adding word wra
Currently during constexpr CALL_EXPR evaluation we create a new copy of
the callee function's body for each separate call with no attempt made
at reusing the function body. So when a function ends up getting called
10s of thousands of times durnig constexpr evaluuation, we end up
creating 10s of t
Hi!
As the testcase shows, when not in a template, cxx_eval_call_expression
already complains about self-recursive calls in constexpr contexts,
but if we are in a function template, we ICE on the testcase,
because we try to instantiate the function template we are in the middle of
parsing, e.g. fu
On Fri, Apr 1, 2016 at 3:13 PM, Patrick Palka wrote:
> Currently during constexpr CALL_EXPR evaluation we create a new copy of
> the callee function's body for each separate call with no attempt made
> at reusing the function body. So when a function ends up getting called
> 10s of thousands of t
[AArch64] Add more choices for the reciprocal square root
approximation
Allow a target to prefer such operation depending on the
operation mode.
gcc/
* config/aarch64/aarch64-protos.h
(AARCH64_APPROX_MODE): New macro.
(AARCH64_APP
On 04/01/16 08:58, Wilco Dijkstra wrote:
Evandro Menezes wrote:
On 03/23/16 11:24, Evandro Menezes wrote:
On 03/17/16 15:09, Evandro Menezes wrote:
This patch implements FP division by an approximation using the Newton
series.
With this patch, DF division is sped up by over 100% and SF divisio
On 03/31/16 04:52, James Greenhalgh wrote:
On Wed, Mar 30, 2016 at 11:18:27AM -0500, Evandro Menezes wrote:
Add scalar 0.0 to the aarch64_simd_reg_or_zero predicate.
2016-03-30 Evandro Menezes
* gcc/config/aarch64/predicates.md
(aarch64_simd_reg_or_zero predicate):
On 1 April 2016 at 18:19, Jeff Law wrote:
> On 04/01/2016 07:26 AM, Christophe Lyon wrote:
>>
>> On 1 April 2016 at 15:12, Kyrill Tkachov
>> wrote:
>>>
>>> Hi Christophe, Andrey,
>>>
>>>
>>> On 01/04/16 14:09, Christophe Lyon wrote:
On 1 April 2016 at 10:54, Andrey Belevantsev wro
On 03/30/2016 05:23 PM, Christophe Lyon wrote:
On 29 March 2016 at 18:28, Vladimir Makarov wrote:
The following patch improves the code in 2 out of 3 cases in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68695
The patch uses more accurate costs for the RA cost improvement
optimization a
On Fri, Apr 01, 2016 at 04:26:41PM -0400, Vladimir Makarov wrote:
> >I've noticed that after this patch, 2 tests regress (PASS -> FAIL) on arm:
> > gcc.dg/ira-shrinkwrap-prep-2.c scan-rtl-dump pro_and_epilogue
> >"Performing shrink-wrapping"
> > gcc.dg/pr10474.c scan-rtl-dump pro_and_epilogue "
Evandro Menezes wrote:
> > The division variant should use the same latency reduction trick I
> > mentioned for sqrt.
>
> I don't think that it applies here, since it doesn't have to deal with
> special cases.
No it applies as it's exactly the same calculation: x * rsqrt(y) and x *
recip(y). In
On 04/01/2016 01:39 PM, Christophe Lyon wrote:
On 1 April 2016 at 19:34, Vladimir Makarov wrote:
O
Sorry, I tried to reproduce it on today trunk on a real hardware but I've
failed.
You have hardware running big-endian natively?
Oops, I missed that it is a big endian machine. Thanks.
On 04/01/16 16:22, Wilco Dijkstra wrote:
Evandro Menezes wrote:
The division variant should use the same latency reduction trick I mentioned
for sqrt.
I don't think that it applies here, since it doesn't have to deal with
special cases.
No it applies as it's exactly the same calculation: x *
This problem is when array indexes are given that have non-integer expressions
or otherwise bad arrays, not just related to reshape.
There are several test cases presented in the PR. Most of these are fixed by
adding a check for any non-integer in match_array_element_spec. The patch-let
in gfc_s
On 03/24/16 14:11, Evandro Menezes wrote:
On 03/17/16 17:46, Evandro Menezes wrote:
This patch refactors the function to emit the reciprocal square root
approximation to also emit the square root approximation.
This version of the patch cleans up the changes to the MD files and
fixes some bugs
Evandro Menezes wrote:
> However, I don't think that there's the need to handle any special case
> for division. The only case when the approximation differs from
> division is when the numerator is infinity and the denominator, zero,
> when the approximation returns infinity and the division, NA
On 04/01/16 17:45, Wilco Dijkstra wrote:
Evandro Menezes wrote:
However, I don't think that there's the need to handle any special case
for division. The only case when the approximation differs from
division is when the numerator is infinity and the denominator, zero,
when the approximation r
Fair enough. I don't think we can impose an arbitrary 64K limit,
however, as that is a lot smaller than the 8MB default stack size, and
programs can use setrlimit to increase the stack farther. For GCC 6 let
not impose any limit beyond non-negative/overflowing, and as you say we
can do something
Evandro Menezes wrote:
>
> I hope that this gets in the ballpark of what's been discussed previously.
Yes that's very close to what I had in mind. A minor issue is that the vector
modes cannot work as they start at MAX_MODE_FLOAT (which is > 32):
+/* Control approximate alternatives to certain F
1 - 100 of 107 matches
Mail list logo
