On Sat, Oct 19, 2019 at 9:11 PM Miguel Saldivar wrote:
>
> Updated patch that uses `_Complex` and `_Imaginary`
>
> Thanks,
> Miguel Saldivar
>
> From 742b37c88bea0118046ac359cabe5f250d69ee30 Mon Sep 17 00:00:00 2001
> From: Miguel Saldivar
> Date: Sat, 19 Oct 2019 21:06:07 -0700
> Subject: [PATCH
Updated patch that uses `_Complex` and `_Imaginary`
Thanks,
Miguel Saldivar
>From 742b37c88bea0118046ac359cabe5f250d69ee30 Mon Sep 17 00:00:00 2001
From: Miguel Saldivar
Date: Sat, 19 Oct 2019 21:06:07 -0700
Subject: [PATCH] Fix for complex and imaginary values
gcc/libiberty/
* cp-demangle.c (d
Hi!
On Sat, Oct 19, 2019 at 12:46:56AM -0400, Jason Merrill wrote:
> gcc/testsuite/g++.dg/cpp2a
> * nodiscard-construct.C: New test.
> * nodiscard-once.C: New test.
> * nodiscard-reason-nonstring.C: New test.
> * nodiscard-reason-only-one.C: New
On October 19, 2019 5:06:40 PM GMT+02:00, Richard Sandiford
wrote:
>After the previous patch, it seems more natural to apply the
>PARAM_SLP_MAX_INSNS_IN_BB threshold as soon as we know what
>the region is, rather than delaying it to vect_slp_analyze_bb_1.
>(But rather than carve out the biggest r
After the previous patch, it seems more natural to apply the
PARAM_SLP_MAX_INSNS_IN_BB threshold as soon as we know what
the region is, rather than delaying it to vect_slp_analyze_bb_1.
(But rather than carve out the biggest region possible and then
reject it, wouldn't it be better to stop when the
On October 19, 2019 5:04:51 PM GMT+02:00, Richard Sandiford
wrote:
>If the first attempt at applying BB SLP to a region fails, the main
>loop
>in vect_slp_bb recomputes the region's bounds and datarefs for the next
>vector size. AFAICT this isn't needed any more; we should be able
>to reuse the
Prathamesh Kulkarni writes:
> Hi Richard,
> Sorry for not adding the test in PR91532 fix.
> Is the attached patch OK to commit ?
>
> Thanks,
> Prathamesh
>
> 2019-10-18 Prathamesh Kulkarni
>
> PR tree-optimization/91532
> testsuite/
> * gcc.target/aarch64/sve/fmla_2.c: Add dg-scan c
If the first attempt at applying BB SLP to a region fails, the main loop
in vect_slp_bb recomputes the region's bounds and datarefs for the next
vector size. AFAICT this isn't needed any more; we should be able
to reuse the datarefs from the first attempt instead.
Tested on aarch64-linux-gnu and
Tobias,
You are quite right to take me to task. As I wrote in the original
message to the list, I was trying to respond rapidly before stepping
out of the door on vacation. The original patch is attached. The fix
to this problem is to revert that part in
libgfortran/runtime/ISO_Fortran_binding.c.
Hi Richard,
On Fri, Oct 18, 2019 at 08:48:31PM +0100, Richard Earnshaw wrote:
>
> This series of patches rewrites all the DImode arithmetic patterns for
> the Arm backend when compiling for Arm or Thumb2 to split the
> operations during expand (the thumb1 code is unchanged and cannot
> benefit fr
On Fri, Oct 18, 2019 at 08:48:42PM +0100, Richard Earnshaw wrote:
>
> Consider this sequence during combine:
>
> Trying 18, 7 -> 22:
>18: r118:SI=r122:SI
> REG_DEAD r122:SI
> 7: r114:SI=0x1-r118:SI-ltu(cc:CC_RSB,0)
> REG_DEAD r118:SI
> REG_DEAD cc:CC_RSB
>22: r1:SI=r
On 10/19/19 2:56 AM, Iain Sandoe wrote:
Andreas Schwab wrote:
On Okt 19 2019, Iain Sandoe wrote:
This test has failed always on Darwin, because Darwin does not mark
entries in string.h with nonnull attributes. Since the purpose of the test
is to check that the warnings are issued for an in
On 19 October 2019 15:04:39 CEST, Bernhard Reutner-Fischer
wrote:
>On 18 October 2019 17:08:54 CEST, Chung-Lin Tang
> wrote:
>
>>Also, I've added a new libgomp.oacc-fortran/deviceptr-2.f90 testcase
>>that
>>actually copies out and verifies the deviceptr computation.
>
>In testcases please do not
On 18 October 2019 17:08:54 CEST, Chung-Lin Tang
wrote:
>Also, I've added a new libgomp.oacc-fortran/deviceptr-2.f90 testcase
>that
>actually copies out and verifies the deviceptr computation.
In testcases please do not 'call abort' which is nonstandard but use 'stop N'
which is standard, idea
On Fri, Oct 18, 2019 at 08:48:40PM +0100, Richard Earnshaw wrote:
>
> The cost routine for Arm and Thumb2 was not recognising the idioms that
> describe the addition with carry, this results in the instructions
> appearing more expensive than they really are, which occasionally can lead
> to poor
On Sat, Oct 19, 2019 at 7:54 AM Jakub Jelinek wrote:
>
> Hi!
>
> As mentioned in the PR, x == 0 can be equivalently tested as x < 1U
> and the latter form has the advantage that it sets the carry flag and if it
> is consumed by an instruction that can directly use the carry flag, it is a
> win.
>
And this makes it a bit nicer (and shorter).
Committed, too.
Gerald
diff --git a/htdocs/about.html b/htdocs/about.html
index a812a7f9..48918c83 100644
--- a/htdocs/about.html
+++ b/htdocs/about.html
@@ -51,13 +51,14 @@ a higher chance of being implemented soon. ;-)
Using the git repository
A
Andreas Schwab wrote:
> On Okt 19 2019, Iain Sandoe wrote:
>
>> This test has failed always on Darwin, because Darwin does not mark
>> entries in string.h with nonnull attributes. Since the purpose of the test
>> is to check that the warnings are issued for an inlined function, not that
>> the
On Okt 19 2019, Iain Sandoe wrote:
> This test has failed always on Darwin, because Darwin does not mark
> entries in string.h with nonnull attributes. Since the purpose of the test
> is to check that the warnings are issued for an inlined function, not that
> the target headers are marked up, w
This test has failed always on Darwin, because Darwin does not mark
entries in string.h with nonnull attributes. Since the purpose of the test
is to check that the warnings are issued for an inlined function, not that
the target headers are marked up, we can provide locally marked up
function decl
As discussed in the list thread on PR65342, and pre-approved by Segher,
this removes a comment that's no longer relevant.
Bootstrap checked on powerpc64-linux-gnu,
applied to mainline
thanks
Iain
gcc/ChangeLog:
2019-10-19 Iain Sandoe
* config/rs6000/rs6000.md: Delete out-of-date comm
On Sat, Oct 19, 2019 at 08:27:31AM +0200, Jakub Jelinek wrote:
> And as questioned in the PR, are there other cases where we can safely
> assume no wrap (e.g. use it if use->iv->no_overflow && cand->iv->no_overflow
> without those extra precision checks)?
Like, is there a way to find out if an iv_
22 matches
Mail list logo
