> On September 26, 2020 12:04:24 AM GMT+02:00, Jan Hubicka
> wrote:
> >Hi,
> >while adding check for gimple_clobber I reversed the return value
> >so instead of ignoring the statement ipa-modref gives up. Fixed thus.
> >This explains the drop between originally reported disambinguations
> >stats
Hi,
this is variant i comitted. Some further testing has shown a problem in
merge operation returing true even if summary was cleanuped to its
original form. This resulted in infinite loop building firefox.
Second problem was that for recurisve functions we need to merge summary
to itself and for
On September 26, 2020 12:04:24 AM GMT+02:00, Jan Hubicka wrote:
>Hi,
>while adding check for gimple_clobber I reversed the return value
>so instead of ignoring the statement ipa-modref gives up. Fixed thus.
>This explains the drop between originally reported disambinguations
>stats and ones I got
On 9/25/20 6:01 PM, Marek Polacek wrote:
On Fri, Sep 25, 2020 at 04:09:44PM -0400, Jason Merrill via Gcc-patches wrote:
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]; };
On 9/22/20 4:05 PM, Martin Sebor wrote:
The rebased and retested patches are attached.
On 9/21/20 3:17 PM, Martin Sebor wrote:
Ping:
https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553906.html
(I'm working on rebasing the patch on top of the latest trunk which
has changed some of the
Successfully regrtested on x86_64-pc-linux-gnu.
Pushed to master as r11-3472-gd4a906e7b51f3fc31f3328810f45ae4cf2e7bbc3.
gcc/testsuite/ChangeLog:
PR analyzer/94355
* g++.dg/analyzer/placement-new.C: New test.
---
gcc/testsuite/g++.dg/analyzer/placement-new.C | 26 ++
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to master as r11-3471-g29f5db8ef81fac4db8e66e5f06fdf1d469e8161c.
gcc/analyzer/ChangeLog:
PR analyzer/96646
PR analyzer/96841
* region-model.cc (region_model::get_representative_path_var):
When han
On Fri, Sep 25, 2020 at 03:34:49PM -0500, will schmidt wrote:
> On Fri, 2020-09-25 at 12:36 -0500, Segher Boessenkool wrote:
> > No, it cannot.
> >
> > This is used for pdepd/pextd/cntlzdm/cnttzdm/cfuged, all of which do
> > need 64-bit registers to do anything sane.
> >
> > This should really ha
On Fri, Sep 25, 2020 at 02:54:01PM -0500, Pat Haugen wrote:
> > +(define_expand "extendditi2"
> > + [(set (match_operand:TI 0 "gpc_reg_operand")
> > +(sign_extend:DI (match_operand:DI 1 "gpc_reg_operand")))]
> > + "TARGET_POWER10"
> > + {
> > +/* Move 64-bit src from GPR to vector re
On Fri, Sep 25, 2020 at 10:41:05AM -0500, will schmidt wrote:
> On Thu, 2020-09-24 at 19:40 -0500, Segher Boessenkool wrote:
> > > +++ b/gcc/testsuite/gcc.target/powerpc/vsx-load-element-extend-
> > > char.c
> > > @@ -0,0 +1,168 @@
> > > +/*
> > > + * Test of vec_xl_sext and vec_xl_zext (load into
Hi!
On Fri, Sep 25, 2020 at 09:07:46AM -0500, Paul A. Clarke wrote:
> On Thu, Sep 24, 2020 at 06:22:10PM -0500, 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 an
On Fri, Sep 25, 2020 at 08:58:35AM +0200, Richard Biener wrote:
> On Thu, Sep 24, 2020 at 9:38 PM Segher Boessenkool
> wrote:
> > after which I get (-march=znver2)
> >
> > setg:
> > vmovd %edi, %xmm1
> > vmovd %esi, %xmm2
> > vpbroadcastd%xmm1, %ymm1
> > vpb
On 9/24/20 6:05 PM, Marek Polacek via Gcc-patches 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 w
Hi,
ipa-modref propagates knowledge about callee to caller function. This is
not compatible with live patching and thus this patch makes
-flive-patching to imply -fno-ipa-modref.
Bootstrapped/regtested x86_64-linux, comitted.
gcc/ChangeLog:
2020-09-26 Jan Hubicka
* doc/invoke.texi: A
Hi,
while adding check for gimple_clobber I reversed the return value
so instead of ignoring the statement ipa-modref gives up. Fixed thus.
This explains the drop between originally reported disambinguations
stats and ones I got later.
Bootstrapped/regtested x86_64-linux.
gcc/ChangeLog:
2020-09
On Fri, Sep 25, 2020 at 04:09:44PM -0400, Jason Merrill via Gcc-patches wrote:
> 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 () {
> >
Hi!
On Fri, Sep 25, 2020 at 11:09:39AM +0200, Jakub Jelinek wrote:
> 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 the
On 9/25/20 8:29 AM, Tamar Christina wrote:
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_,
a
From: Sergei Trofimovich
Before the change gcc did not stream correctly TOPN counters
if counters belonged to a non-local shared object.
As a result zero-section optimization generated TOPN sections
in a form not recognizable by '__gcov_merge_topn'.
The problem happens because in a case of mult
In the testcase concepts7.C below, we currently reject the call to f1
but we accept the call to f2, even though their associated constraints
are functionally equivalent.
The reason satisfaction differs for (!!C is due to normalization: the former is already an
atom, and the latter is not. Normali
On Fri, 2020-09-25 at 12:36 -0500, Segher Boessenkool wrote:
> 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
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
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/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 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 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
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
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
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
> 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;
>>
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
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
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
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
> 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
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
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
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
> 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,
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 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
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 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
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.
+
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 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_
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 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.
>
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
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,
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 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 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 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 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 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 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 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 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 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
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 |
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
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 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/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
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 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
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 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
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
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
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
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
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 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
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 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
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
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
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_
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 +++-
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,
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
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
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__
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
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
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
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:
>
>
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 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 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 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
> -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
1 - 100 of 121 matches
Mail list logo
