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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96841
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96646
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94355
--- Comment #5 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:d4a906e7b51f3fc31f3328810f45ae4cf2e7bbc3
commit r11-3472-gd4a906e7b51f3fc31f3328810f45ae4cf2e7bbc3
Author: David Malcolm
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96841
--- Comment #1 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:29f5db8ef81fac4db8e66e5f06fdf1d469e8161c
commit r11-3471-g29f5db8ef81fac4db8e66e5f06fdf1d469e8161c
Author: David Malcolm
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96646
--- Comment #1 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:29f5db8ef81fac4db8e66e5f06fdf1d469e8161c
commit r11-3471-g29f5db8ef81fac4db8e66e5f06fdf1d469e8161c
Author: David Malcolm
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97206
--- Comment #4 from Martin Sebor ---
A different/simpler test case that doesn't involve a call to
handle_access_attribute():
$ cat pr97206.c && gcc -O2 -S -Wall pr97206.c
void a (char *);
void a (char [restrict]);
extern const char b[];
extern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88335
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88323
Bug 88323 depends on bug 88335, which changed state.
Bug 88335 Summary: Implement P1073R3, C++20 immediate functions (consteval).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88335
What|Removed |Added
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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97201
Martin Sebor changed:
What|Removed |Added
Keywords||patch
--- Comment #4 from Martin Sebor
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
> >
Snapshot gcc-9-20200925 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/9-20200925/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 9 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84930
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
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:
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:
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
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_,
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
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96817
--- Comment #16 from Yuxuan Shui ---
But yeah, that's definitely a bug in itself as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96817
--- Comment #15 from Yuxuan Shui ---
(In reply to Jonathan Wakely from comment #13)
> (In reply to Yuxuan Shui from comment #1)
> > Example:
> >
> > This program normally deadlocks when using linked pthread:
> >
> >
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',
> >
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96817
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97211
Bug ID: 97211
Summary: __cxa_guard_acquire fails to detect recursive init in
multithreaded code
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
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")]
> +
'nitems()' calculates the length of an array in number of items.
It is safe: if a pointer is passed to the macro (or function, in C++),
the compilation is broken due to:
- In >= C11: _Static_assert()
- In C89, C99: Negative anonymous bitfield
- In C++: The template requires an array
Some BSDs
> 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.
>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97210
Bug ID: 97210
Summary: Intrinsic function get_team() does not work
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97198
--- Comment #3 from Marek Polacek ---
(In reply to Jonathan Wakely from comment #2)
> Hmm. It should be false for construction from no arguments i.e.
> __is_constructible(int[]).
>
> But thanks to parenthesized aggregate init, you can actually
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97111
--- Comment #1 from David Malcolm ---
References:
https://en.cppreference.com/w/cpp/language/exceptions
https://itanium-cxx-abi.github.io/cxx-abi/abi-eh.html ("Itanium C++ ABI:
Exception Handling")
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97198
--- Comment #2 from Jonathan Wakely ---
Hmm. It should be false for construction from no arguments i.e.
__is_constructible(int[]).
But thanks to parenthesized aggregate init, you can actually do:
using T = int[];
T t(1);
It's still true
> 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;
>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96817
--- Comment #13 from Jonathan Wakely ---
(In reply to Yuxuan Shui from comment #1)
> Example:
>
> This program normally deadlocks when using linked pthread:
>
> https://godbolt.org/z/Yrza4e
>
> But it will throw recursive_init_error when
On 2020-09-25 19:39, Jonathan Wakely wrote:
> Yes, I'm aware of all the rationale. I already said that it makes
> sense in C++ where you have generic code. I am not convinced that it's
> necessary to add to when all it does is a cast from
> size_t to ptrdiff_t.
>
While I would prefer a
On 25/09/20 18:30 +0200, Alejandro Colomar via Libstdc++ wrote:
I have a similar number of ARRAY_SIZE() and ARRAY_SSIZE().
I could have '#define snitems(arr) ((ptrdiff_t)nitems(arr))' in my projects,
but is it really necessary?
The barrier for adding something to glibc headers should be a LOT
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97206
Martin Sebor changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
On 25/09/20 18:30 +0200, Alejandro Colomar via Libstdc++ wrote:
Hello Jonathan,
On 2020-09-25 16:48, Jonathan Wakely wrote:
Do you really need to provide snitems?
Users can use (ptrdiff_t)nitems if needed, can't they?
They can, but that adds casts in the code,
which makes longer lines that
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
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 =
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97198
Marek Polacek changed:
What|Removed |Added
CC||redi at gcc dot gnu.org
> 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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95464
--- Comment #9 from CVS Commits ---
The releases/gcc-10 branch has been updated by Vladimir Makarov
:
https://gcc.gnu.org/g:038b65f378b36624b1fd3867fa5e578c1bfa50cc
commit r10-8799-g038b65f378b36624b1fd3867fa5e578c1bfa50cc
Author: Vladimir N.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95464
--- Comment #10 from CVS Commits ---
The releases/gcc-10 branch has been updated by Vladimir Makarov
:
https://gcc.gnu.org/g:957e37ac288fe6c40ee0bb98a0b06a85be8a35e3
commit r10-8800-g957e37ac288fe6c40ee0bb98a0b06a85be8a35e3
Author: Vladimir N.
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/
*
Hello Jonathan,
On 2020-09-25 16:48, Jonathan Wakely wrote:
> Do you really need to provide snitems?
>
> Users can use (ptrdiff_t)nitems if needed, can't they?
They can, but that adds casts in the code,
which makes longer lines that are somewhat harder to read.
To avoid that, users may
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71233
--- Comment #45 from CVS Commits ---
The releases/gcc-8 branch has been updated by Kyrylo Tkachov
:
https://gcc.gnu.org/g:1788d74b05b7936e9e8dd01a8f66701ad2bc2951
commit r8-10536-g1788d74b05b7936e9e8dd01a8f66701ad2bc2951
Author: Tamar
> 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97209
Bug ID: 97209
Summary: TODO: building array references needs a big tidy up
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97127
--- Comment #17 from Alexander Monakov ---
To me this suggests that in fact it's okay to carry the combined form in RTL up
to register allocation, but RA should decompose it to load+fma instead of
inserting a register copy that preserves the
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96394
--- Comment #15 from Martin Jambor ---
so after Martin asked some good questions, it turns out this should probably be
avoided in ipa-prop, after all, as with, for example (untested):
diff --git a/gcc/ipa-prop.c b/gcc/ipa-prop.c
index
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97045
--- Comment #2 from Paul Thomas ---
Created attachment 49272
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49272=edit
Updated patch
It turned out that with the original patch, character payloads of the unlimited
polymorphic array were
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97201
--- Comment #3 from Martin Sebor ---
The decision to use null for the upper bound can be traced to this message:
https://gcc.gnu.org/pipermail/gcc-patches/2015-December/437361.html
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97201
--- Comment #2 from Martin Sebor ---
Just a correction to the comment:
+ /* Zero-length arrays have a null upper bound in C++ and
+SIZE_MAX in C. */
It's actually the other way around.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97201
Martin Sebor changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot
gnu.org
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
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:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95464
--- Comment #8 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #7)
> Vlad, do you plan to backport this to 10.3?
I guess so. We had enough time to test it. I don't see any complaints about
this patch. I'll backport it today
> 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
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:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97197
--- Comment #4 from David Fink ---
Hi Jakub,
I tried to reduce the code as much as possible before reporting, which is why
the example has the "this != " check in the copy constructor.
The original code where I saw this problem had the "this
On 25/09/20 16:10 +0200, Alejandro Colomar wrote:
On 2020-09-25 15:20, Alejandro Colomar wrote:
'nitems()' calculates the length of an array in number of items.
It is safe: if a pointer is passed to the macro (or function, in C++),
the compilation is broken due to:
- In >= C11:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97169
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
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:
*
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
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
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,
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
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
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
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
1 - 100 of 259 matches
Mail list logo
