Hi!
As mentioned in the PR, the following patch attempts to address two issues.
In remove_unused_ivs we first find the best iv_cand (we prefer primarily the
same step, next same mode and lastly constant base) and only then call
get_computation_at to determine the replacement expression. Unfortuna
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.
The following patch adds a couple of (pre-reload only) define_insn_an
On 10/18/19 1:54 AM, JeanHeyd Meneide wrote:
... And I am very tired and forgot to attach the patch. Again. Sorry...!
On Fri, Oct 18, 2019 at 1:54 AM JeanHeyd Meneide
wrote:
Dear Jason,
On Thu, Oct 17, 2019 at 3:51 PM Jason Merrill wrote:
> FAIL: g++.dg/cpp0x/gen-attrs-67.C -std=c++11
Hello, Jason,
On Oct 14, 2019, Jason Merrill wrote:
> Alex, you had a lot of helpful comments when I first wrote this, any thoughts
> on this revision?
I think the check of the pid file could be made slightly simpler and
cheaper if we created it using:
echo $$ > $lockdir/pidT && mv $lockdir
On 10/18/19 4:27 PM, Martin Sebor wrote:
> The optimization to fold (strcmp() == 0) results involving
> arrays/strings of unequal size/length has a bug where it is
> unprepared for the compute_string_length() function to return
> an invalid length as an indication that the length is unknown.
> This
The optimization to fold (strcmp() == 0) results involving
arrays/strings of unequal size/length has a bug where it is
unprepared for the compute_string_length() function to return
an invalid length as an indication that the length is unknown.
This leads to some strings that are unequal being cons
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 check for deleted store.
diff --git a/gcc/tests
In thumb2 we now generate a NEGS instruction rather than RSBS, so this
test needs updating.
* gcc.target/arm/negdi-3.c: Update expected output to allow NEGS.
---
gcc/testsuite/gcc.target/arm/negdi-3.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/testsuite/g
This is the first step of early splitting all the DImode comparison
operations. We start by factoring the DImode handling out of
arm_gen_compare_reg into its own function.
Simple DImode equality comparisions (such as equality with zero, or
equality with a constant that is zero in one of the two
Now that we early split DImode subtracts, the patterns to emit the
original and to match zero-extend with subtraction or negation are
no-longer useful.
* config/arm/arm.md (arm_subdi3): Delete insn.
(zextendsidi_negsi, negdi_extendsidi): Delete insn_and_split.
---
gcc/config/arm/
Similar to the improvements for uaddvsi4, this patch improves the code
generation for addvsi4 to handle immediates and to add alternatives
that better target thumb2. To do this we separate out the expansion
of uaddvsi4 from that of uaddvdi4 and then add an additional pattern
to handle constants.
This patch adds early splitting of subdi3 so that the individual
operations can be seen by the optimizers, particuarly combine. This
should allow us to do at least as good a job as previously, but with
far fewer patterns in the machine description.
This is just the initial patch to add the early
The uaddv patterns in the arm back-end do not currenty handle immediates
during expansion. This patch adds this support for uaddvsi4. It's really
a stepping-stone towards early expansion of uaddvdi4, but it complete and
a useful change in its own right.
Whilst making this change I also observed
Now that all the major patterns for DImode have been converted to
early expansion, we can safely clean up some dead code for the old way
of handling DImode.
* config/arm/arm-modes.def (CC_NCV, CC_CZ): Delete CC modes.
* config/arm/arm.c (arm_select_cc_mode): Remove old selection c
This patch matches the signed add-with-overflow patterns when the
summation itself is dropped. In this case we can use CMN (or CMP with
some immediates). There are a small number of constants in thumb2
where this can result in less dense code (as we lack 16-bit CMN with
immediate patterns). To
This code borrows strongly on the uaddvti4 expansion for aarch64 since
the principles are similar. Firstly, if the one of the low words of
the expansion is 0, we can simply copy the other low word to the
destination and use uaddvsi4 for the upper word. If that doesn't work
we have to handle thre
The generic expansion code for negv does not try the subv patterns,
but instead emits a sub and a compare separately. Fortunately, the
patterns can make use of the new subv operations, so just call those.
We can also rewrite this using an iterator to simplify things further.
Finally, we can now m
The add-with-carry operation which involves a shift doesn't match at present
because it isn't matching the canonical form generated by combine. Fixing
this is simply a matter of re-ordering the operands.
* config/arm/arm.md (addsi3_carryin_shift_): Reorder operands
to match canon
In almost all cases it is better to handle inequality handling against constants
by transforming comparisons of the form (reg const) into
(reg (const+1)). However, there are many cases that we could
handle but currently failed to do so because we forced the constant into a
register too early in
This patch addresses constant handling in subvsi4. Either operand may
be a constant. If the second input (operand[2]) is a constant, then
we can canonicalize this into an addition form, providing we take care
of the INT_MIN case. In that case the negation has to handle the fact
that -INT_MIN is
addsi3_carryin_alt2 has a more strict constraint than the predicate
when adding a constant. This leads to sub-optimal code in some
circumstances.
* config/arm/arm.md (addsi3_carryin_alt2): Use arm_not_operand for
operand 2.
---
gcc/config/arm/arm.md | 2 +-
1 file changed, 1 ins
In a small number of cases it is preferable to handle comparisons with
constants using the sequence
RSBStmp, Xlo, constlo
RSCStmp, Xhi, consthi
which allows us to handle a small number of LE/GT/LEU/GEU cases when
changing the code to use LT/GE/LTU/GEU would make the const
An earlier patch introduced arm_borrow_operation, this one introduces
the carry variant, which is the same except that the logic of the
carry-setting is inverted. Having done this we can now match more
cases where the carry flag is propagated from comparisons with
different modes without having t
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 choices by combine. Recognising all the possible variants is
a little trick
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=r114:SI
REG_DEAD r114:SI
Failed to match this instruction:
(set (reg:SI 1 r1 [+4
This patch adds a couple of alternative canonicalizations to allow
combine to match a subtract-with-carry operation when one of the operands
is shifted first. The most common case of this is when combining a
sign-extend of one operand with a long-long value during subtraction.
The RSC variant is
This patch adds early expansion of subvdi4. The expansion sequence
is broadly based on the expansion of usubvdi4.
* config/arm/arm.md (subvdi4): Decompose calculation into 32-bit
operations.
(subdi3_compare1): Delete pattern.
(subvsi3_borrow): New insn pattern.
This patch adds early splitting for addvdi4; it's very similar to the
uaddvdi4 splitter, but the details are just different enough in
places, especially for the patterns that match the splitting, where we
have to compare against the non-widened version to detect if overflow
occurred.
I've also ad
When the carry flag is appropriately set by a comprison, negscc
patterns can expand into a simple SBC of a register with itself. This
means we can convert two conditional instructions into a single
non-conditional instruction. Furthermore, in Thumb2 we can avoid the
need for an IT instruction as
The rtx_cost calculations when a borrow operation was being performed were
not being calculated correctly. The borrow is free as part of the
subtract-with-carry instructions. This patch recognizes the various
idioms that can describe this and returns the correct costs.
* config/arm/arm.
This patch adds early expansion of usubvdi4, allowing us to handle some
constants in place, which previously we were unable to do.
* config/arm/arm.md (usubvdi4): Allow registers or integers for
incoming operands. Early split the calculation into SImode
operations.
This patch improves the expansion of usubvsi4 by allowing suitable
constants to be passed directly. Unlike normal subtraction, either
operand may be a constant (and indeed I have seen cases where both can
be with LTO enabled). One interesting testcase that improves as a
result of this is:
unsig
This patch does most of the work for early splitting the DImode
comparisons. We now handle EQ, NE, LT, GE, LTU and GEU during early
expansion, in addition to EQ and NE, for which the expansion has now
been reworked to use a standard conditional-compare pattern already in
the back-end.
To handle
The first step towards early splitting of addition and subtraction at
DImode is to rip out the old patterns that are designed to propagate
DImode through the RTL optimization passes and the do late splitting.
This patch does cause some code size regressions, but it should still
execute correctly.
This patch changes the insn patterns for zero- and sign-extend into
define_expands that generate the appropriate word operations
immediately.
* config/arm/arm.md (zero_extenddi2): Convert to define_expand.
(extenddi2): Likewise.
---
gcc/config/arm/arm.md | 75
This patch causes the expansion of adddi3 to split the operation
immediately for Arm and Thumb-2. This is desirable as it frees up the
register allocator to pick what ever combination of registers suits
best and reduces the number of auxiliary patterns that we need in the
back-end. Three of the
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 from early splitting as we are unable to expose the carry
flag).
This has a number of bene
On Fri, Oct 18, 2019 at 05:17:38PM +0100, Iain Sandoe wrote:
>
> something like this, perhaps (I regret my Fortran skills are in the f77 era):
>
If you know/knew F77 and have some working knowledge of C/C++ and
you want to see where modern Fortran sits, I recommend Modern Fortran
Explained iby M
The only reason I wanted `float complex` was for interoperability
between the two other demanglers. Although the go demangler
does use `_Complex` and `_Imaginary`, so I guess it's sort of split.
But I agree, `_Complex` and `_Imaginary` is probably the
better option.
Thanks,
Miguel Saldivar
On Fr
I will deal with this and various other issues associated with
ISO_Fortran_binding tomorrow.
Thanks for your help
Paul
On Thu, 17 Oct 2019 at 18:30, Tobias Burnus wrote:
>
> Hi,
>
> + fprintf (stderr, "CFI_setpointer: Result is NULL.\n");
> …
> > + return CFI_INVALID_DESCRIPTOR;
> > +! { d
On Fri, Oct 11, 2019 at 09:03:53AM +0200, Jan Hubicka wrote:
> Bootstrapped/regtested x86_64-linux, OK?
>
> * ggc-page.c (release_pages): Output statistics when !quiet_flag.
> (ggc_collect): Dump later to not interfere with release_page dump.
> (ggc_trim): New function.
> *
Hi!
While reviewing
<20191003163505.49997-2-julian@codesourcery.com">http://mid.mail-archive.com/20191003163505.49997-2-julian@codesourcery.com>
"OpenACC reference count overhaul", I've just now stumbled over one thing
that originally was designed here:
On 2018-12-10T19:41:37+, Julian Brown
On Thu, Oct 17, 2019 at 10:20 PM Miguel Saldivar wrote:
>
> This is a small fix for Bug 67299, where symbol: `Z1fCf` which would become
> `f(float complex)` instead of `f(floatcomplex )`.
> I thought this would be the preferred way of printing, because both
> `llvm-cxxfilt` and `cpp_filt` both pri
On 18 Oct 2019, Pedro Alves stated:
> On 10/18/19 2:21 PM, Richard Biener wrote:
>
In most cases local types etc are a fairly small contributor to the
total volume -- but macros can contribute a lot in some codebases.
>>> (The
Linux kernel's READ_ONCE macro is one I've personally be
Hi,
a few days ago I noticed that for, say, g++.dg/parse/qualified2.C we
were issuing two additional misleading errors after the first one,
mentioning in particular a certain "unnamed class" (I'm reproducing only
the error messages proper):
namespace Glib {
template class Value {};
temp
Here is some more cases fixed for small targets for noise reduction.
Ok to apply?
Johann
gcc/testsuite/
Fix some fallout for small targets.
PR testsuite/52641
* gcc.dg/torture/pr86034.c: Use 32-bit base type for a bitfield of
width > 16 bits.
* gcc.dg/to
I experienced the following ICE when working on a downstream patch for msp430:
void
foo (unsigned int r, unsigned int y)
{
__builtin_umul_overflow ((unsigned int) (-1), y, &r);
}
> msp430-elf-gcc -S tester.c -O0
tester.c: In function 'foo':
tester.c:4:1: error: unrecognizable insn:
4 | }
On 10/18/19 2:21 PM, Richard Biener wrote:
>>> In most cases local types etc are a fairly small contributor to the
>>> total volume -- but macros can contribute a lot in some codebases.
>> (The
>>> Linux kernel's READ_ONCE macro is one I've personally been bitten by
>> in
>>> the past, with a new
Hi,
SVE2 vectorization for BSL and NBSL fails when the element type is unsigned
8/16-bit.
The operands are being converted implicitly to corresponding signed types,
which the mid-end fold pattern does not take into account; this patch augments
the pattern with type conversion checks in order t
Hi Thomas,
this is the updated Fortran deviceptr patche, originated from Cesar, and one of
the tests was from James Norris:
https://gcc.gnu.org/ml/gcc-patches/2018-05/msg00286.html
https://gcc.gnu.org/ml/gcc-patches/2018-08/msg00532.html
There were a few style cleanups, but the goal of modificati
On 10/18/19 12:52 AM, Jakub Jelinek wrote:
On Thu, Oct 17, 2019 at 06:07:37PM -0600, Martin Sebor wrote:
On 10/17/19 1:00 AM, Jakub Jelinek wrote:
Hi!
The following bug has been introduced when cond_expr_object_size has been
added in 2007. We want to treat a COND_EXPR like a PHI with 2 argume
Hi,
Updated the patch with respect to Richard Earnshaw's comments and
committed in r277156.
gcc/ChangeLog:
2019-10-18 Andre Vieira
* config/arm/t-multilib: Add rule to regenerate mutlilib header
file with any change to t-multilib, t-aprofile and t-rmprofile.
Also ad
Ping.
On Fri, Oct 11, 2019 at 04:23:34PM -0400, Marek Polacek wrote:
> has_value_dependent_address wasn't stripping location wrappers so it
> gave the wrong answer for "&x" in the static_assert. That led us to
> thinking that the expression isn't instantiation-dependent, and we
> skipped static i
Here's a version rebased on top of Nathan's C++ patch yesterday.
This actually makes the patch simpler; the changes to the frontends
are now pure additions, so no existing frontend code should be affected.
FWIW, this patch and the enum one:
https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01523.ht
On Fri, Sep 27, 2019 at 4:41 PM Lewis Hyatt wrote:
>
> On Thu, Sep 26, 2019 at 08:46:56PM +, Joseph Myers wrote:
> > On Thu, 26 Sep 2019, Lewis Hyatt wrote:
> >
> > > A couple notes:
> > > - In order to avoid any portability problems with wchar_t, the
> > > equivalent of wcwidth() from lib
Hi!
On 2019-10-15T23:32:32+0200, Tobias Burnus wrote:
> This OpenACC-only patch extends the support for /common/ blocks.
I'll be quick to note that I don't have any first-hand experience with
Fortran common blocks. :-P
> [In OpenMP (4.0 to 5.0, unchanged) and gfortran, common blocks are suppor
On October 18, 2019 1:59:36 PM GMT+02:00, Pedro Alves wrote:
>On 10/17/19 7:59 PM, Nick Alcock wrote:
>> On 17 Oct 2019, Richard Biener verbalised:
>>
>>> On Thu, Oct 17, 2019 at 7:36 PM Nick Alcock
>wrote:
On 11 Oct 2019, Indu Bhagat stated:
> Compile with -g -gdwarf-like-ctf and
Ping...
for the c++ FE and testsuite changes in the updated patch
here: https://gcc.gnu.org/ml/gcc-patches/2019-10/msg00916.html
Thanks
Bernd.
On 10/12/19 8:10 PM, Bernd Edlinger wrote:
> On 10/11/19 6:31 PM, Jason Merrill wrote:
>> On 10/10/19 2:06 PM, Bernd Edlinger wrote:
>>> On 10/10/19
Hi,
All these tests fail when using -mpure-code:
* some force A or R profile
* some use Neon
* some use -fpic/-fPIC
all of which are not supported by this option.
OK?
Thanks,
Christophe
2019-10-18 Christophe Lyon
gcc/testsuite/
* gcc.target/arm/attr-crypto.c: Skip if -mpure-
Hi,
This patch extends support for -mpure-code to all thumb-1 processors,
by removing the need for MOVT.
Symbol addresses are built using upper8_15, upper0_7, lower8_15 and
lower0_7 relocations, and constants are built using sequences of
movs/adds and lsls instructions.
The extension of the *thu
Re-instate error message which got by dereferrencing a NULL pointer.
Commited as r277153 to the trunk.
Committed as r277154 to the GCC 9 branch (as it was a 9/10 regression).
Thanks,
Tobias
commit f9aef7e7d320df8560e602d863e97ea324e68644
Author: burnus
Date: Fri Oct 18 12:04:31 2019 +
I noticed that we use a bitfield flag to note types with names for
linkage purposes:
typedef struct {} foo;
but, we can infer this by comparing TYPE_STUB_DECL and TYPE_DECL of the
main variant. It's only checked in two places -- the C++ parser and the
objective C++ encoder.
Committing this
Hi Julian!
On 2019-10-06T15:32:34-0700, Julian Brown wrote:
> This patch adds a function to pretty-print OpenACC clause names from
> OMP_CLAUSE_MAP_KINDs, for error output.
Indeed talking about (OpenMP) 'map' clauses in an OpenACC context is not
quite ideal -- that's what PR65095 is about, so pl
On 10/17/19 7:59 PM, Nick Alcock wrote:
> On 17 Oct 2019, Richard Biener verbalised:
>
>> On Thu, Oct 17, 2019 at 7:36 PM Nick Alcock wrote:
>>>
>>> On 11 Oct 2019, Indu Bhagat stated:
Compile with -g -gdwarf-like-ctf and use dwz -o
(using
dwz compiled from the master branch) on
On 10/17/19 6:36 PM, Nick Alcock wrote:
> A side note here: the sizes given above are uncompressed sizes, but in
> the real world CTF is almost always compressed: the threshold for
> compression is in theory customizable but at the moment is hardwired at
> 4KiB-uncompressed in the linker. I usually
OS X 10.15 adds aligned_alloc but it has the same restriction as the AIX
version, namely that alignments smaller than sizeof(void*) are not
supported.
PR libstdc++/92143
* libsupc++/new_opa.cc (operator new) [__APPLE__]: Increase alignment
to at least sizeof(void*).
Teste
On 17/10/19 16:40 +0100, Jonathan Wakely wrote:
Define std::identity, std::ranges::equal_to, std::ranges::not_equal_to,
std::ranges::greater, std::ranges::less, std::ranges::greater_equal and
std::ranges::less_equal.
* include/Makefile.am: Add new header.
* include/Makefile.in: R
On 18/10/2019 11:53, Andre Vieira (lists) wrote:
Hi
This patch maps multilibs using -march=armv7-r+vfpv3-d16-fp16 and
-march=armv7-r+vfpv3-d16-fp16+idiv to v7+fp. This patch also adds a new
multilib for armv7-r+fp.sp and maps -march=armv7-r+fp.sp+idiv,
-march=armv7-r+vfpv3xd-fp16 and -march=arm
On Fri, 18 Oct 2019, Christophe Lyon wrote:
> On Wed, 16 Oct 2019 at 15:09, Richard Biener wrote:
> >
> >
> > It happens we cannot have different typed data and index for
> > integer condition reductions right now, for whatever reason.
> > The following makes that work, even for double data and i
Hi
This patch maps multilibs using -march=armv7-r+vfpv3-d16-fp16 and
-march=armv7-r+vfpv3-d16-fp16+idiv to v7+fp. This patch also adds a new
multilib for armv7-r+fp.sp and maps -march=armv7-r+fp.sp+idiv,
-march=armv7-r+vfpv3xd-fp16 and -march=armv7-r+vfpv3xd-fp16+idiv to it.
This solves issues
On Fri, Oct 18, 2019 at 11:06:45AM +0200, Ilya Leoshkevich wrote:
> Bootstrapped and regtested on x86_64-redhat-linux, s390x-redhat-linux
> and ppc64le-redhat-linux. The offending patch is in gcc-9_1_0-release
> and gcc-9_2_0-release - do I need to backport this fix to gcc-9-branch?
It is a regre
Currently, one has for
!$omp target exit data map(delete:x)
in the original dump:
#pragma omp target exit data map(delete:*x) map(alloc:x [pointer
assign, bias: 0])
The "alloc:" not only does not make sense but also gives run-time
messages like:
libgomp: GOMP_target_enter_exit_data unhand
Bootstrapped and regtested on x86_64-redhat-linux, s390x-redhat-linux
and ppc64le-redhat-linux. The offending patch is in gcc-9_1_0-release
and gcc-9_2_0-release - do I need to backport this fix to gcc-9-branch?
r266734 has introduced a new instance of jump threading pass in order to
take advant
Prathamesh Kulkarni writes:
> Hi,
> The attached patch tries to fix PR91272.
> Does it look OK ?
>
> With patch, I see following failures for aarch64-sve.exp:
> FAIL: gcc.target/aarch64/sve/clastb_1.c -march=armv8.2-a+sve
> scan-assembler \\tclastb\\tw[0-9]+, p[0-7], w[0-9]+, z[0-9]+\\.s
> FAIL: g
74 matches
Mail list logo
