Hi,
Add missing require-effect-target alloca directives.
Tested on nvptx.
Committed to trunk.
Thanks,
- Tom
[testsuite] Add missing require-effective-target alloca
gcc/testsuite/ChangeLog:
2020-09-25 Tom de Vries
* gcc.dg/analyzer/pr93355-localealias.c: Require effective target
It's a small refactoring which I consider as obvious.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Martin
gcc/ChangeLog:
* cgraph.c (cgraph_node::dump): Always print space at the end
of a message. Remove one extra space.
---
gcc/cgraph.c | 9 -
The following change adds support for non-rectangular simd loops.
While working on that, I've noticed we actually don't vectorize collapsed
simd loops at all, because the code that I thought would be vectorizable
actually is not vectorized. While in theory for the constant lower/upper
bounds and c
Hi.
As mentioned in the PR, we should not mangle .gcno files.
I'm going to install the fix if there are no concerns.
Martin
gcc/ChangeLog:
PR gcov-profile/97193
* coverage.c (coverage_init): GCDA note files should not be
mangled and should end in output directory.
---
Hi!
As mentioned in the PR, since 2005 we reject if array elements are smaller
than their alignment (i.e. overaligned elements), because such arrays don't
make much sense, only their first element is guaranteed to be aligned as
user requested, but the next element can't be.
The following testcases
Hi!
libcpp has two specialized altivec implementations of search_line_fast,
one for power8+ and the other one otherwise.
Both use __attribute__((altivec(vector))) and the GCC builtins rather than
altivec.h and the APIs from there, which is fine, but should be restricted
to when libcpp is built wit
Hello.
All right, I come up with a rapid speed up that can allow us to remove
the introduced parameter. It contains 2 parts:
- BIT TEST: we allow at maximum a range that is smaller GET_MODE_BITSIZE
- JT: we spent quite some time in density calculation, we can guess it first
and it leads to a fa
The RTL expansion code for CTORs doesn't handle VECTOR_BOOLEAN_TYPE_P
with bit-precision elements correctly as the testcase shows before
the PR97085 fix. The following makes it do the correct thing
(not 100% sure for CTOR of sub-vectors due to the lack of a testcase).
The alternative would be to
This patch fixes ICEs in gcc.dg/torture/float16-basic.c for
-march=armv8.1-m.main+mve -mfloat-abi=hard. The problem was
that an fp16 argument was (rightly) being passed in FPRs,
but the fp16 move patterns only handled GPRs. LRA then cycled
trying to look for a way of handling the FPR.
It looks l
This fixes the testcase writing to adjacent stack vars, exposed
my IPA modref.
Tested on x86_64-unknown-linux-gnu, pushed.
2020-09-25 Richard Biener
PR testsuite/97204
* gcc.target/i386/sse2-mmx-pinsrw.c: Fix.
---
gcc/testsuite/gcc.target/i386/sse2-mmx-pinsrw.c | 8
Hi Richard,
> -Original Message-
> From: Richard Sandiford
> Sent: 25 September 2020 10:35
> To: gcc-patches@gcc.gnu.org
> Cc: ni...@redhat.com; Richard Earnshaw ;
> Ramana Radhakrishnan ; Kyrylo
> Tkachov
> Subject: [PATCH] arm: Fix fp16 move patterns for base MVE
>
> This patch fixes
Hi all,
I'd like to backport this patch to the GCC 9 branch implementing the RNG
intrinsics from Armv8.5-a.
It should have been supported there from the start.
It doesn't apply cleanly since the SVE ACLE work in GCC 10 reworked some of the
builtin handling,
but the resolution isn't complex.
Boo
Hi all,
We got a request to support the RNG intrinsics on GCC 8 as some cores used with
this compiler will support the instructions
and the intrinsics are not very invasive to implement.
This does require adding the +rng arch extension to GCC 8, which is simple to
do.
Otherwise the patch looks v
Since r11-3402 (g:65c9878641cbe0ed898aa7047b7b994e9d4a5bb1), the
vtrn_half, vuzp_half and vzip_half started failing with
vtrn_half.c:76:17: error: redeclaration of 'vector_float64x2' with no linkage
vtrn_half.c:77:17: error: redeclaration of 'vector2_float64x2' with no linkage
vtrn_half.c:80:17: e
> -Original Message-
> From: Gcc-patches On Behalf Of
> Christophe Lyon via Gcc-patches
> Sent: 25 September 2020 11:35
> To: gcc Patches ; Kyrill Tkachov
>
> Subject: testsuite: [aarch64] Fix aarch64/advsimd-intrinsics/v{trn, uzp,
> zip}_half.c
>
> Since r11-3402 (g:65c9878641cbe0ed89
Hi,
parameter tracking in ipa-modref causes failure of ipa-pta-13 testcase.
In partiuclar the check for "= x;" in fre3 is failing since we optimize
it out in fre1. As far as I can tell this is correct transform because
ipa-modref propagates the fact that the call is passed pointer to y.
Comment sp
This fixes a corner case with virtual operand update in if-conversion
by re-organizing the code to remove edges only after the last point
we need virtual PHI operands to be available.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2020-09-25 Richard Biener
PR tree-optimi
This adds rough support to avoid "'target_mem_ref' not supported by"
in diagnostics. There were recent patches by Martin to sanitize
dumping of MEM_REF so I'm not trying to interfere with this here.
Bootstrap & regtest pending.
OK?
2020-09-25 Richard Biener
PR c++/97197
cp/
Hi,
this patch prepares support for iterative dataflow in ipa-modref-tree.h by
making inserts to track if anyting has changed at all.
Bootstrapped/regtested x86_64-linux and also tested with the actual iterative
dataflow in modref. I plan to commit it later today unless there are comments.
Honza
Hi,
this patch implement trakcing wehther argument points to readonly memory. This
is is useful for ipa-modref as well as for inline heuristics. It is desirable
to inline functions that dereference pointers to local variables in order
to support SRA. We always did the oposite heuristics (guessing
Hello,
This simple follow-on patch adds a missing feature (FP16) to the
Neoverse V1 description in AArch32 GCC.
OK for master?
Thanks,
Alex
---
gcc/ChangeLog:
* config/arm/arm-cpus.in (neoverse-v1): Add FP16.
diff --git a/gcc/config/arm/arm-cpus.in b/gcc/config/arm/arm-cpus.in
index
> -Original Message-
> From: Alex Coplan
> Sent: 25 September 2020 12:18
> To: gcc-patches@gcc.gnu.org
> Cc: ni...@redhat.com; Richard Earnshaw ;
> Ramana Radhakrishnan ; Kyrylo
> Tkachov
> Subject: [PATCH] arm: Add missing Neoverse V1 feature
>
> Hello,
>
> This simple follow-on patc
On Fri, Sep 25, 2020 at 1:04 PM Jan Hubicka wrote:
>
> Hi,
> parameter tracking in ipa-modref causes failure of ipa-pta-13 testcase.
> In partiuclar the check for "= x;" in fre3 is failing since we optimize
> it out in fre1. As far as I can tell this is correct transform because
> ipa-modref prop
On Fri, Sep 25, 2020 at 01:11:37PM +0200, Richard Biener wrote:
> This adds rough support to avoid "'target_mem_ref' not supported by"
> in diagnostics. There were recent patches by Martin to sanitize
> dumping of MEM_REF so I'm not trying to interfere with this here.
Is that correct?
I mean, TAR
On Wed, Sep 23, 2020 at 05:45:12PM +0200, Tobias Burnus wrote:
> On 9/23/20 4:06 PM, Jakub Jelinek wrote:
>
> > What I really meant was:
> I did now something based on this.
> > > + gcc_assert (node->alias && node->analyzed);
>
> I believe from previous testing that node->analyzed is
On Fri, Sep 25, 2020 at 8:51 AM xionghu luo wrote:
>
> Hi,
>
> On 2020/9/24 20:39, Richard Sandiford wrote:
> > xionghu luo writes:
> >> @@ -2658,6 +2659,43 @@ expand_vect_cond_mask_optab_fn (internal_fn, gcall
> >> *stmt, convert_optab optab)
> >>
> >> #define expand_vec_cond_mask_optab_fn ex
On Fri, 25 Sep 2020, Jakub Jelinek wrote:
> On Fri, Sep 25, 2020 at 01:11:37PM +0200, Richard Biener wrote:
> > This adds rough support to avoid "'target_mem_ref' not supported by"
> > in diagnostics. There were recent patches by Martin to sanitize
> > dumping of MEM_REF so I'm not trying to inte
On 9/24/20 5:05 PM, Richard Biener wrote:
> On Thu, 24 Sep 2020, Jonathan Wakely wrote:
>
>> On 24/09/20 11:11 +0200, Richard Biener wrote:
>>> On Wed, 26 Aug 2020, Richard Biener wrote:
>>>
On Thu, 6 Aug 2020, Richard Biener wrote:
> On Thu, 6 Aug 2020, Richard Biener wrote:
>
>
Hi!
I'd like to ping a few patches:
https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552451.html
- allow plugins to deal with global_options layout changes
https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553420.html
- --enable-link-serialization{,=N} support
https://gcc.gnu.or
Now that G++ defaults to gnu++17 we don't need special rules for
compiling the C++17 allocation and deallocation functions.
libstdc++-v3/ChangeLog:
* libsupc++/Makefile.am: Remove redundant -std=gnu++1z flags.
* libsupc++/Makefile.in: Regenerate.
Tested powerpc64le-linux. Committ
Richard Biener writes:
> The RTL expansion code for CTORs doesn't handle VECTOR_BOOLEAN_TYPE_P
> with bit-precision elements correctly as the testcase shows before
> the PR97085 fix. The following makes it do the correct thing
> (not 100% sure for CTOR of sub-vectors due to the lack of a testcase
Richard Biener writes:
> On Thu, Sep 24, 2020 at 9:38 PM Segher Boessenkool
> wrote:
>>
>> Hi!
>>
>> On Thu, Sep 24, 2020 at 04:55:21PM +0200, Richard Biener wrote:
>> > Btw, on x86_64 the following produces sth reasonable:
>> >
>> > #define N 32
>> > typedef int T;
>> > typedef T V __attribute__
Andrea Corallo writes:
> Hi Richard,
>
> thanks for reviewing
>
> Richard Sandiford writes:
>
>> Andrea Corallo writes:
>>> Hi all,
>>>
>>> having a look for force_reg returned rtx later on modified I've found
>>> this other case in `aarch64_general_expand_builtin` while expanding
>>> pointer a
On Fri, 25 Sep 2020, Richard Sandiford wrote:
> Richard Biener writes:
> > The RTL expansion code for CTORs doesn't handle VECTOR_BOOLEAN_TYPE_P
> > with bit-precision elements correctly as the testcase shows before
> > the PR97085 fix. The following makes it do the correct thing
> > (not 100% s
On 15/09/2020 09:57, Jakub Jelinek via Gcc-patches wrote:
The following testcase is miscompiled (in particular the a and i
initialization). The problem is that build_special_member_call due to
the immediate constructors (but not evaluated in constant expression mode)
doesn't create a CALL_EXPR,
This implements the missing move assignment to make std::swap work
on auto_vec<>
Bootstrapped / tesed on x86_64-unknown-linux-gnu, pushed.
Richard.
2020-09-25 Richard Biener
PR middle-end/97207
* vec.h (auto_vec::operator=(auto_vec&&)): Implement.
---
gcc/vec.h | 8 +++-
Qing Zhao writes:
> Hi, Richard,
>
> As you suggested, I added a default implementation of the target hook
> “zero_cal_used_regs (HARD_REG_SET)” as following in my latest patch
>
>
> /* The default hook for TARGET_ZERO_CALL_USED_REGS. */
>
> void
> default_zero_call_used_regs (HARD_REG_SET need_
Richard Biener writes:
>> What do we allow for non-boolean constructors. E.g. for:
>>
>> v2hi = 0xf001;
>>
>> do we allow the CONSTRUCTOR to be { 0xf001 }? Is the type of an
>> initialiser value allowed to be arbitrarily different from the type
>> of the elements being initialised?
>>
>> Or
Richard Biener writes:
> On Fri, 25 Sep 2020, Richard Sandiford wrote:
>
>> Richard Biener writes:
>> >> What do we allow for non-boolean constructors. E.g. for:
>> >>
>> >> v2hi = 0xf001;
>> >>
>> >> do we allow the CONSTRUCTOR to be { 0xf001 }? Is the type of an
>> >> initialiser value al
On 9/24/20 5:51 PM, Martin Sebor via Gcc-patches wrote:
On 9/18/20 12:38 PM, Aldy Hernandez via Gcc-patches wrote:
3. Conversion of sprintf/strlen pass to class.
This is a nonfunctional change to the sprintf/strlen passes. That is,
no effort was made to change the passes to multi-ranges. Ho
On Fri, Sep 25, 2020 at 11:13 AM Martin Liška wrote:
>
> Hello.
>
> All right, I come up with a rapid speed up that can allow us to remove
> the introduced parameter. It contains 2 parts:
> - BIT TEST: we allow at maximum a range that is smaller GET_MODE_BITSIZE
> - JT: we spent quite some time in
On Fri, 25 Sep 2020, Richard Sandiford wrote:
> Richard Biener writes:
> >> What do we allow for non-boolean constructors. E.g. for:
> >>
> >> v2hi = 0xf001;
> >>
> >> do we allow the CONSTRUCTOR to be { 0xf001 }? Is the type of an
> >> initialiser value allowed to be arbitrarily different
xionghu luo writes:
> @@ -2658,6 +2659,45 @@ expand_vect_cond_mask_optab_fn (internal_fn, gcall
> *stmt, convert_optab optab)
>
> #define expand_vec_cond_mask_optab_fn expand_vect_cond_mask_optab_fn
>
> +/* Expand VEC_SET internal functions. */
> +
> +static void
> +expand_vec_set_optab_fn
On 9/25/20 3:18 PM, Richard Biener wrote:
On Fri, Sep 25, 2020 at 11:13 AM Martin Liška wrote:
Hello.
All right, I come up with a rapid speed up that can allow us to remove
the introduced parameter. It contains 2 parts:
- BIT TEST: we allow at maximum a range that is smaller GET_MODE_BITSIZE
This patch introduces various improvements to the logic that merges
field compares.
Before the patch, we could merge:
(a.x1 EQNE b.x1) ANDOR (a.y1 EQNE b.y1)
into something like:
(((type *)&a)[Na] & MASK) EQNE (((type *)&b)[Nb] & MASK)
if both of A's fields live within the same alignme
Hi!
On Fri, Sep 25, 2020 at 01:37:16PM +0200, Richard Biener wrote:
> See my comment above for Martins attempts to improve things. I don't
> really want to try decide what to do with those late diagnostic IL
> printing but my commit was blamed for showing target-mem-ref unsupported.
>
> I don't
Hi,
When compiling nvptx.c using -save-temps, I ran into Wimplicit-fallthrough
warnings.
The fallthrough locations have been marked with a fallthrough comment, but
that doesn't work with -save-temps, something that has been filed as
PR78497.
Work around this by using gcc_fallthrough () in additi
On Fri, Sep 25, 2020 at 3:32 PM Martin Liška wrote:
>
> On 9/25/20 3:18 PM, Richard Biener wrote:
> > On Fri, Sep 25, 2020 at 11:13 AM Martin Liška wrote:
> >>
> >> Hello.
> >>
> >> All right, I come up with a rapid speed up that can allow us to remove
> >> the introduced parameter. It contains 2
On Tue, Sep 22, 2020 at 10:48 AM H.J. Lu wrote:
>
> On Fri, Sep 18, 2020 at 10:21 AM H.J. Lu wrote:
> >
> > On Thu, Sep 17, 2020 at 3:52 PM Jeff Law wrote:
> > >
> > >
> > > On 9/16/20 8:46 AM, Richard Sandiford wrote:
> > >
> > > "H.J. Lu" writes:
> > >
> > > On Tue, Sep 15, 2020 at 7:44 AM Ri
On Fri, Sep 25, 2020 at 11:13:06AM +0200, Martin Liška wrote:
> --- a/gcc/tree-switch-conversion.c
> +++ b/gcc/tree-switch-conversion.c
> @@ -1268,6 +1268,15 @@ jump_table_cluster::can_be_handled (const vec *> &clusters,
>if (range == 0)
> return false;
>
> + unsigned HOST_WIDE_INT lhs
We currently detect builtin decls via DECL_ARTIFICIAL &&
!DECL_HIDDEN_FUNCTION_P, which, besides being clunky, is a problem as
hiddenness is a property of the symbol table -- not the decl being
hidden. This adds DECL_BUILTIN_P, which just looks at the
SOURCE_LOCATION -- we have a magic one for b
On 9/24/20 2:41 PM, Richard Biener wrote:
On Wed, Sep 2, 2020 at 1:53 PM Martin Liška wrote:
On 9/1/20 4:50 PM, David Malcolm wrote:
Hope this is constructive
Dave
Thank you David. All of them very very useful!
There's updated version of the patch.
Hey.
What a juicy patch review!
I n
On Thu, Sep 24, 2020 at 06:22:10PM -0500, Segher Boessenkool wrote:
> On Wed, Sep 23, 2020 at 05:12:44PM -0500, Paul A. Clarke wrote:
> > +extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__,
> > __artificial__))
> > +_mm_insert_epi8 (__m128i const __A, int const __D, int cons
On 9/25/20 3:52 PM, Jakub Jelinek wrote:
On Fri, Sep 25, 2020 at 11:13:06AM +0200, Martin Liška wrote:
--- a/gcc/tree-switch-conversion.c
+++ b/gcc/tree-switch-conversion.c
@@ -1268,6 +1268,15 @@ jump_table_cluster::can_be_handled (const vec
&clusters,
if (range == 0)
return false;
On 9/25/20 3:45 PM, Richard Biener wrote:
On Fri, Sep 25, 2020 at 3:32 PM Martin Liška wrote:
On 9/25/20 3:18 PM, Richard Biener wrote:
On Fri, Sep 25, 2020 at 11:13 AM Martin Liška wrote:
Hello.
All right, I come up with a rapid speed up that can allow us to remove
the introduced paramet
Hello.
I'm going to install quite obvious patch which allow negative values
for HIST_TYPE_IOR as it tracks pointers.
Martin
gcc/ChangeLog:
PR gcov-profile/64636
* value-prof.c (stream_out_histogram_value): Allow negative
values for HIST_TYPE_IOR.
---
gcc/value-prof.c |
Hi All,
This patch series adds support for SLP vectorization of complex instructions
[1].
These instructions exist only in their vector forms and require you to recognize
two statements in parallel. Complex operations usually require a permute due to
the fact that the real and imaginary numbers
Hi All,
This is a small refactoring which exposes some helper functions in the
vectorizer so they can be used in other places.
Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
Ok for master?
Thanks,
Tamar
gcc/ChangeLog:
* tree-vect-patterns.c (vect_mark_pattern_stmts):
Hi All,
This is a small refactoring which introduces SLP_TREE_REF_COUNT and replaces
the uses of refcnt with it. This for consistency between the other properties.
A similar patch was pre-approved last year but since there are more use now I am
sending it for review anyway.
Bootstrapped Regtest
Hi All,
This patch adds the basic infrastructure for doing pattern matching on SLP
trees.
This is done immediately after the SLP tree creation because it can change the
shape of the tree in radical ways and so we would like to do it before any
analysis is performed on the tree.
A new file tree-v
Hi All,
This patch adds pattern detections for the following operation:
Addition with rotation of the second argument around the Argand plane.
Supported rotations are 90 and 180.
c = a + (b * I) and c = a + (b * I * I)
where a, b and c are complex numbers.
Bootstrapped Regtested on
Hi All,
This patch adds shared machinery for detecting patterns having to do with
complex number operations. The class ComplexPattern provides helpers for
matching and ultimately undoing the permutation in the tree by rebuilding the
graph.
Bootstrapped Regtested on aarch64-none-linux-gnu and no
Hi All,
This adds the dissolve code to undo the patterns created by the pattern matcher
in case SLP is to be aborted.
As mentioned in the cover letter this has one issue in that the number of copies
can needed can change depending on whether TWO_OPERATORS is needed or not.
Because of this I don'
Hi All,
This patch adds pattern detections for the following operation:
Complex multiplication and Conjucate Complex multiplication of the second
parameter.
c = a * b and c = a * conj (b)
For the conjucate cases it supports under fast-math that the operands that is
being conjucat
Hi All,
This adds some documentation for some test directives that are missing.
Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
Ok for master?
Thanks,
Tamar
gcc/ChangeLog:
* doc/sourcebuild.texi (vect_complex_rot_,
arm_v8_3a_complex_neon_ok, arm_v8_3a_complex_n
Hi All,
This patch adds pattern detections for the following operation:
Complex FMLA, Conjucate FMLA of the second parameter and FMLS.
c += a * b, c += a * conj (b), c -= a * b and c -= a * conj (b)
For the conjucate cases it supports under fast-math that the operands that is
being co
Hi All,
This adds implementation for the optabs for complex operations. With this the
following C code:
void f90 (float complex a[restrict N], float complex b[restrict N],
float complex c[restrict N])
{
for (int i=0; i < N; i++)
c[i] = a[i] + (b[i] * I);
}
generates
Hi All,
This adds support to the auto-vectorizer to support HFmode vectorization for
AArch32. This is supported when +fp16 is used. I wonder if I should disable
the returning of the type if the option isn't enabled.
At the moment it will be returned but the vectorizer will try and fail to use
i
Hi All,
This adds implementation for the optabs for complex operations. With this the
following C code:
void f90 (int _Complex a[restrict N], int _Complex b[restrict N],
int _Complex c[restrict N])
{
for (int i=0; i < N; i++)
c[i] = a[i] + (b[i] * I);
}
generates
Hi All,
This adds implementation for the optabs for complex additions. With this the
following C code:
void f90 (float complex a[restrict N], float complex b[restrict N],
float complex c[restrict N])
{
for (int i=0; i < N; i++)
c[i] = a[i] + (b[i] * I);
}
generates
Hi All,
This adds implementation for the optabs for complex operations. With this the
following C code:
void f90 (float complex a[restrict N], float complex b[restrict N],
float complex c[restrict N])
{
for (int i=0; i < N; i++)
c[i] = a[i] + (b[i] * I);
}
generates
Hi All,
These are just initial testcases to show what the patch is testing for,
however it is incomplete and I am working on better test setup
to test all targets and add middle-end tests.
These were just included for completeness.
Thanks,
Tamar
gcc/testsuite/ChangeLog:
* gcc.target/aa
Hi All,
This adds implementation for the optabs for complex operations. With this the
following C code:
void f90 (int _Complex a[restrict N], int _Complex b[restrict N],
int _Complex c[restrict N])
{
for (int i=0; i < N; i++)
c[i] = a[i] + (b[i] * I);
}
generates
On Thu, 2020-09-24 at 08:30 +0200, Jan Hubicka wrote:
> Hi,
> This patch makes ggc_delete to be paired with ggc_alloc_no_dtor.
> I copy same scheme as used by Martin in ipa-fnsummary, that is
> creating a
> static member function create_ggc hidding the ugly bits and using it
> in
> ipa-modref.c.
>
PING^5
On 7/21/20 6:24 PM, Qing Zhao wrote:
PING^4.
Our company is waiting for this patch to be committed to upstream.
Thanks a lot.
Qing
On Jun 16, 2020, at 7:49 AM, Martin Liška wrote:
PING^3
On 6/2/20 11:16 AM, Martin Liška wrote:
PING^2
On 5/15/20 11:58 AM, Martin Liška wrote:
We'r
> On Sep 25, 2020, at 7:53 AM, Richard Sandiford
> wrote:
>
> Qing Zhao writes:
>> Hi, Richard,
>>
>> As you suggested, I added a default implementation of the target hook
>> “zero_cal_used_regs (HARD_REG_SET)” as following in my latest patch
>>
>>
>> /* The default hook for TARGET_ZERO_
Hello,
Latest Debian snapshot of gcc (20200917-1) FTBFS due to a missing hurd
entry in the // +build line of libgo/go/net/fd_posix.go. Attached is a
patch for that missing entry.
With it the latest Debian snapshot has been successfully built. Test
results for libgo and go are:
==
On 9/24/20 6:22 PM, Segher Boessenkool wrote:
>> + result [(__N & 0b)] = __D;
>
> Hrm, GCC supports binary constants like this since 2007, so okay. But I
> have to wonder if this improves anything over hex (or decimal even!)
> The parens are superfluous (and only hinder legibility), fwiw.
+
On 30/07/2020 12:10, Andrew Stubbs wrote:
On 29/07/2020 15:05, Andrew Stubbs wrote:
This patch does not implement anything new, but simply separates
OpenACC 'enter data' and 'exit data' into two libgomp API functions.
The original API name is kept for backward compatibility, but no
longer ref
Qing Zhao writes:
>> On Sep 25, 2020, at 7:53 AM, Richard Sandiford
>> wrote:
>>
>> Qing Zhao writes:
>>> Hi, Richard,
>>>
>>> As you suggested, I added a default implementation of the target hook
>>> “zero_cal_used_regs (HARD_REG_SET)” as following in my latest patch
>>>
>>>
>>> /* The de
On Thu, 2020-09-24 at 19:40 -0500, Segher Boessenkool wrote:
> On Thu, Sep 24, 2020 at 11:04:38AM -0500, will schmidt wrote:
> > [PATCH 2/2, rs6000] VSX load/store rightmost element operations
> >
> > Hi,
> > This adds support for the VSX load/store rightmost element
> > operations.
> > This inc
Hi All,
The original testcase turned out to be relatively easy to fix - the chunks
in trans-expr.c and trans-stmt.c do this. However, I tested character
actual arguments to 'write_array' in the testcase and found that the _len
component of the unlimited polymorphic dummy was not being used for the
> On Sep 25, 2020, at 10:28 AM, Richard Sandiford
> wrote:
>
> Qing Zhao mailto:qing.z...@oracle.com>> writes:
>>> On Sep 25, 2020, at 7:53 AM, Richard Sandiford
>>> wrote:
>>>
>>> Qing Zhao writes:
Hi, Richard,
As you suggested, I added a default implementation of the tar
Hi all,
I'd like to backport some patches from Tamar in GCC 9 to GCC 8 that implement
the complex arithmetic intrinsics for Advanced SIMD.
These should have been present in GCC 8 that gained support for Armv8.3-a.
There were 4 follow-up fixes that I've rolled into the one commit.
Bootstrapped a
Hi all,
The Linux kernel has defined the cpuinfo string for the +rng feature, so this
patch adds that to GCC so that -march=native can pick it up.
Bootstrapped and tested on aarch64-none-linux-gnu.
Committing to trunk and later to the branches.
Thanks,
Kyrill
gcc/
* config/aarch64/aarch
Qing Zhao writes:
>> On Sep 25, 2020, at 10:28 AM, Richard Sandiford
>> wrote:
>>
>> Qing Zhao mailto:qing.z...@oracle.com>> writes:
On Sep 25, 2020, at 7:53 AM, Richard Sandiford
wrote:
Qing Zhao writes:
> Hi, Richard,
>
> As you suggested, I added a defaul
> On Sep 25, 2020, at 11:58 AM, Richard Sandiford
> wrote:
>
> Qing Zhao writes:
Which data structure in GCC should be used here to hold this returned
value as Set of RTX ?
>>>
>>> A HARD_REG_SET is enough. All the caller needs to know is: which registers
>>> were cl
I always found tag_scope confusing, as it is not a scope, but a
direction of how to lookup or insert an elaborated type tag. This
replaces it with a enum class TAG_how. I also add a new value,
HIDDEN_FRIEND, to distinguish the two cases of innermost-non-class
insertion that we currently conflat
Qing Zhao writes:
> Last question, in the following code portion:
>
> /* Now we get a hard register set that need to be zeroed, pass it to
> target to generate zeroing sequence. */
> HARD_REG_SET zeroed_hardregs;
> start_sequence ();
> zeroed_hardregs = targetm.calls.zero_call_used_r
Hi!
On Thu, Sep 24, 2020 at 03:35:24PM -0500, will schmidt wrote:
> We have extraneous BTM entry (RS6000_BTM_POWERPC64) in the define for
> our P10 MISC 2 builtin definition. This does not exist for the '0',
> '1' or '3' definitions. It appears to me that this was erroneously
> copied from th
On 9/23/20 7:53 PM, Martin Sebor via Gcc-patches wrote:
On 9/18/20 12:38 PM, Aldy Hernandez via Gcc-patches wrote:
As part of the ranger work, we have been trying to clean up and
generalize interfaces whenever possible. This not only helps in
reducing the maintenance burden going forward, but p
> On Sep 25, 2020, at 12:31 PM, Richard Sandiford
> wrote:
>
> Qing Zhao writes:
>> Last question, in the following code portion:
>>
>> /* Now we get a hard register set that need to be zeroed, pass it to
>> target to generate zeroing sequence. */
>> HARD_REG_SET zeroed_hardregs;
>>
Hi!
On Thu, Sep 24, 2020 at 04:56:27PM -0400, Michael Meissner wrote:
> On Thu, Sep 24, 2020 at 10:24:52AM +0200, Florian Weimer wrote:
> > * Michael Meissner via Gcc-patches:
> >
> > > These patches are my latest versions of the patches to add IEEE 128-bit
> > > min,
> > > max, and conditional
The C and C++ representations of zero-length arrays are different:
C uses a null upper bound of the type's domain while C++ uses
SIZE_MAX. This makes the middle end logic more complicated (and
prone to mistakes) because it has to be prepared for both. A recent
change to -Warray-bounds has the mi
The decl pushing APIs and duplicate_decls take an 'is_friend' parm,
when what they actually mean is 'hide this from name lookup'. That
conflation has gotten more anachronistic as time moved on. We now
have anticipated builtins, and I plan to have injected extern decls
soon. So this patch is mai
> On Sep 25, 2020, at 9:55 AM, Martin Liška wrote:
>
> PING^5
>
Thanks a lot for ping this patch again.
Hopefully it can be committed into GCC 11 very soon.
Qing
> On 7/21/20 6:24 PM, Qing Zhao wrote:
>> PING^4.
>> Our company is waiting for this patch to be committed to upstream.
>> Thank
On 9/24/20 10:59 AM, will schmidt via Gcc-patches wrote:
> +;; Move DI value from GPR to TI mode in VSX register, word 1.
> +(define_insn "mtvsrdd_diti_w1"
> + [(set (match_operand:TI 0 "register_operand" "=wa")
> + (unspec:TI [(match_operand:DI 1 "register_operand" "r")]
> +UN
On 9/25/20 2:30 AM, Richard Biener wrote:
On Thu, 24 Sep 2020, Jason Merrill wrote:
On 9/24/20 3:43 AM, Richard Biener wrote:
On Wed, 23 Sep 2020, Jason Merrill wrote:
On 9/23/20 2:42 PM, Richard Biener wrote:
On September 23, 2020 7:53:18 PM GMT+02:00, Jason Merrill
wrote:
On 9/23/20 4:1
On 9/24/20 8:05 PM, Marek Polacek wrote:
This new warning can be used to prevent expensive copies inside range-based
for-loops, for instance:
struct S { char arr[128]; };
void fn () {
S arr[5];
for (const auto x : arr) { }
}
where auto deduces to S and then we copy the big S
On 9/15/20 3:57 AM, Jakub Jelinek wrote:
Hi!
The following testcase is miscompiled (in particular the a and i
initialization). The problem is that build_special_member_call due to
the immediate constructors (but not evaluated in constant expression mode)
doesn't create a CALL_EXPR, but returns
1 - 100 of 121 matches
Mail list logo
