[AMD Public Use]
Hi Honza,
> -Original Message-
> From: Jan Hubicka
> Sent: Saturday, December 5, 2020 1:06 AM
> To: Uros Bizjak
> Cc: Kumar, Venkataramanan ; gcc-
> patc...@gcc.gnu.org
> Subject: Re: [PATCH] [X86_64]: Enable support for next generation AMD
> Zen3 CPU
>
> [CAUTION: Ext
On Wed, Dec 02, 2020 at 09:50:33PM -0500, Jason Merrill wrote:
> On 12/2/20 6:18 PM, Marek Polacek wrote:
> > In this testcase we are crashing trying to gimplify a switch, because
> > the types of the switch condition and case constants have different
> > TYPE_PRECISIONs.
> >
> > This started with
verify_sequence_points uses verify_tree to recursively walk the
subexpressions of an expression, and while recursing, it also
keeps lists of expressions found after/before a sequence point.
For a large expression, the list can grow significantly. And
merge_tlist is at least N(n^2): for a list of l
On Wed, Dec 02, 2020 at 09:01:48PM -0500, Jason Merrill wrote:
> On 12/2/20 6:18 PM, Marek Polacek wrote:
> > -fsanitize=vptr initializes all vtable pointers to null so that it can
> > catch invalid calls; see cp_ubsan_maybe_initialize_vtbl_ptrs. That
> > means that evaluating a vtable reference c
I've now merged trunk revision
918a5b84a2c51dc9d011d39461cc276e6558069d to the gccgo branch.
Ian
Ping?
Samuel Thibault, le dim. 08 nov. 2020 23:52:51 +0100, a ecrit:
> The binutils bugs seem to have been fixed.
>
> 2020-11-08 Samuel Thibault
>
> gcc/
> * config.gcc: Enable default_gnu_indirect_function in *-*-gnu*
> target (but not *-*-kfreebsd*-gnu | *-*-kopensolaris*-
This libgo patch updates the type descriptor name in the fieldtrack C
support code. We were using the old name, but nothing noticed because
it is a weak reference that is permitted to be nil, so that it works
with code that does not use the field tracking library. Bootstrapped
and ran Go testsuit
The check in do_class_deduction to handle passing one class placeholder
template parm as an argument for itself needed to be extended to also handle
equivalent parms from other templates.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
PR c++/93083
* pt.c (conver
On 12/4/20 4:33 PM, Patrick Palka wrote:
The re-normalization performed from diagnose_nested_requirement doesn't
always work because we may have already lost the necessary template
context that determines the set of in-scope template parameters used by
the nested-requirement. This leads to norma
On 12/4/20 4:33 PM, Patrick Palka wrote:
I've convinced myself to do away with the whole diagnose_requires_expr /
tsubst_requires_expr consolidation, since that part is just a pure
refactoring change and the added overloadedness of the flags is not
ideal. This simplifies the patch considerably.
On 12/4/20 2:55 PM, Mike Stump wrote:
> On Nov 30, 2020, at 8:00 AM, Jeff Law via Gcc-patches
> wrote:
>> This patch fixes a handful of tests with non-unique names which confuse
>> the living hell out of compare_tests, particularly if one of two tests
>> [x]fail while the other is [x]pass whic
On Nov 30, 2020, at 8:00 AM, Jeff Law via Gcc-patches
wrote:
>
> This patch fixes a handful of tests with non-unique names which confuse
> the living hell out of compare_tests, particularly if one of two tests
> [x]fail while the other is [x]pass which compare_tests will flag as a
> regression e
The re-normalization performed from diagnose_nested_requirement doesn't
always work because we may have already lost the necessary template
context that determines the set of in-scope template parameters used by
the nested-requirement. This leads to normalization producing atoms
that have incomple
During satisfaction, the flag info.noisy() controls three things:
whether to diagnose ill-formed satisfaction (such as the satisfaction
value of an atom being non-bool or non-constant); whether to diagnose
unsatisfaction; and whether to bypass the satisfaction cache.
The flag turns out to be too c
On Thu, 3 Dec 2020, Jason Merrill wrote:
> On 12/3/20 9:24 AM, Patrick Palka wrote:
> > During satisfaction, the flag info.noisy() controls three things:
> > whether to diagnose fatal errors (such as the satisfaction value of an
> > atom being non-bool); whether to diagnose unsatisfaction; and whe
On 12/4/20 12:27 PM, Jakub Jelinek wrote:
Hi!
We currently incorrectly reject the first testcase, because
cxx_fold_indirect_ref_1 doesn't attempt to handle UNION_TYPEs.
As the second testcase shows, it isn't that easy, because I believe we need
to take into account the active member and prefer t
On 12/4/20 3:39 AM, Richard Biener wrote:
On Thu, Dec 3, 2020 at 10:46 PM Jeff Law via Gcc-patches
wrote:
On 12/3/20 10:53 AM, Jason Merrill via Gcc-patches wrote:
It looks cleaner if we can use a vec* directly as a range for the C++11
range-based 'for' loop, without needing to indirect fro
> On Fri, Dec 4, 2020 at 6:50 PM Kumar, Venkataramanan
> wrote:
> >
> > [AMD Public Use]
> >
> > Hi Uros
> >
> > > -Original Message-
> > > From: Uros Bizjak
> > > Sent: Friday, December 4, 2020 2:30 PM
> > > To: Kumar, Venkataramanan
> > > Cc: gcc-patches@gcc.gnu.org; Jan Hubicka (hubi.
From: Aaron Sawdey
This patch adds the first batch of patterns to support p10 fusion. These
will allow combine to create a single insn for a pair of instructions
that that power10 can fuse and execute. These particular ones have the
requirement that only cr0 can be used when fusing a load with a
On 11/24/20 11:39 AM, Martin Sebor wrote:
> On 11/24/20 10:44 AM, Andrew MacLeod wrote:
>> On 11/24/20 12:42 PM, Andrew MacLeod wrote:
>>> On 11/23/20 4:38 PM, Martin Sebor wrote:
On 11/21/20 6:26 AM, Andrew MacLeod wrote:
> On 11/21/20 12:07 AM, Jeff Law wrote:
>>
>> On 11/9/20
On Fri, 4 Dec 2020, Richard Biener via Gcc-patches wrote:
> Per rule changes to targets are allowed at any point per discretion of target
> maintainers. Heck, we even accept _new_ targets during stage3/4!
For architectures that are neither primary nor secondary targets, that's
definitely the ca
On 12/2/20 6:06 PM, Jim Wilson wrote:
> On Tue, Dec 1, 2020 at 3:24 PM Jeff Law via Gcc-patches
> mailto:gcc-patches@gcc.gnu.org>> wrote:
>
>
> Kito's recent change to multilib handling seems to have exposed a
> latent
> mcore bug.
>
> The mcore 210 does not support little endian
On 12/4/20 7:51 AM, Hans-Peter Nilsson via Gcc-patches wrote:
>> From: Martin Sebor via Gcc-patches
>> Date: Fri, 4 Dec 2020 01:49:51 +0100
>> On 12/3/20 12:14 PM, Hans-Peter Nilsson via Gcc-patches wrote:
>>> Belatedly, here's an updated version, using Martin Sebor's
>>> suggested wording from
On Fri, Dec 04, 2020 at 07:32:43PM +0100, Uros Bizjak wrote:
> On Fri, Dec 4, 2020 at 7:26 PM Segher Boessenkool
> wrote:
> > A splitter can *already* split to only one insn.
>
> Oh... brown paper bag time... I really don't know where and when I
> pick that info, since the docs indeed say:
At so
On 12/4/20 4:45 AM, Richard Biener wrote:
> split_constant_offset currently gives up looking at ranges when
> dealing with possibly wrapping operations for looking through
> conversions when the downstream analysis does not yield a SSA name.
> That's overly conservative and we have a nice helper
On Fri, Dec 4, 2020 at 7:26 PM Segher Boessenkool
wrote:
>
> Hi!
>
> On Fri, Dec 04, 2020 at 07:06:45PM +0100, Uros Bizjak wrote:
> > On Fri, Dec 4, 2020 at 6:57 PM Jakub Jelinek wrote:
> > >
> > > On Fri, Dec 04, 2020 at 06:53:49PM +0100, Uros Bizjak wrote:
> > > > > > I was trying that first, b
On Fri, Dec 4, 2020 at 7:09 PM Jakub Jelinek wrote:
>
> On Fri, Dec 04, 2020 at 07:06:45PM +0100, Uros Bizjak wrote:
> > No, I didn't want to burden you with the additional task - the patch
> > is OK as it is. I was just thinking out loud, as I remembered that
> > changing bt patterns to combine s
‐‐‐ Original Message ‐‐‐
On Thursday, August 20, 2020 1:48 PM, Segher Boessenkool
wrote:
> On Thu, Aug 20, 2020 at 04:19:36PM +, GT wrote:
>
> > > Great! Please repost with what I already pointed out fixed, that
> > > explanation added, and working links to the documentation?
> >
> >
Hi!
On Fri, Dec 04, 2020 at 07:06:45PM +0100, Uros Bizjak wrote:
> On Fri, Dec 4, 2020 at 6:57 PM Jakub Jelinek wrote:
> >
> > On Fri, Dec 04, 2020 at 06:53:49PM +0100, Uros Bizjak wrote:
> > > > > I was trying that first, but it didn't work. Without the
> > > > > clobber it actually works right
On Fri, Dec 04, 2020 at 07:06:45PM +0100, Uros Bizjak wrote:
> No, I didn't want to burden you with the additional task - the patch
> is OK as it is. I was just thinking out loud, as I remembered that
> changing bt patterns to combine splitter regressed one testcase. IIRC
> combination of two insns
[AMD Public Use]
Hi Uros,
> -Original Message-
> From: Uros Bizjak
> Sent: Friday, December 4, 2020 11:31 PM
> To: Kumar, Venkataramanan
> Cc: gcc-patches@gcc.gnu.org; Jan Hubicka (hubi...@ucw.cz)
>
> Subject: Re: [PATCH] [X86_64]: Enable support for next generation AMD
> Zen3 CPU
>
>
On Fri, Dec 4, 2020 at 6:57 PM Jakub Jelinek wrote:
>
> On Fri, Dec 04, 2020 at 06:53:49PM +0100, Uros Bizjak wrote:
> > > > I was trying that first, but it didn't work. Without the
> > > > clobber it actually works right, we don't have the rotate insn with the
> > > > masking and no clobber, so
On December 4, 2020 6:06:20 PM GMT+01:00, Jakub Jelinek
wrote:
>Hi!
>
>As mentioned in the PR, we shouldn't treat non-replaceable operator
>new/delete (e.g. with the placement new) as replaceable ones.
>
>There is some pending discussion that perhaps operator delete called
>from
>delete if not re
On Fri, Dec 4, 2020 at 6:50 PM Kumar, Venkataramanan
wrote:
>
> [AMD Public Use]
>
> Hi Uros
>
> > -Original Message-
> > From: Uros Bizjak
> > Sent: Friday, December 4, 2020 2:30 PM
> > To: Kumar, Venkataramanan
> > Cc: gcc-patches@gcc.gnu.org; Jan Hubicka (hubi...@ucw.cz)
> >
> > Subj
On Fri, Dec 04, 2020 at 06:53:49PM +0100, Uros Bizjak wrote:
> > > I was trying that first, but it didn't work. Without the
> > > clobber it actually works right, we don't have the rotate insn with the
> > > masking and no clobber, so in the end combiner does add the clobber there
> > > (or would
On Fri, Dec 4, 2020 at 6:42 PM Uros Bizjak wrote:
>
> On Fri, Dec 4, 2020 at 6:41 PM Jakub Jelinek wrote:
> >
> > On Fri, Dec 04, 2020 at 06:37:02PM +0100, Uros Bizjak wrote:
> > > > + "(INTVAL (operands[3]) & (GET_MODE_BITSIZE (mode) - 1))
> > > > + == GET_MODE_BITSIZE (mode) - 1"
> > > > + [(
[AMD Public Use]
Hi Uros
> -Original Message-
> From: Uros Bizjak
> Sent: Friday, December 4, 2020 2:30 PM
> To: Kumar, Venkataramanan
> Cc: gcc-patches@gcc.gnu.org; Jan Hubicka (hubi...@ucw.cz)
>
> Subject: Re: [PATCH] [X86_64]: Enable support for next generation AMD
> Zen3 CPU
>
> [
On Fri, Dec 4, 2020 at 6:41 PM Jakub Jelinek wrote:
>
> On Fri, Dec 04, 2020 at 06:37:02PM +0100, Uros Bizjak wrote:
> > > + "(INTVAL (operands[3]) & (GET_MODE_BITSIZE (mode) - 1))
> > > + == GET_MODE_BITSIZE (mode) - 1"
> > > + [(set (match_dup 4) (match_dup 1))
> > > + (set (match_dup 0)
> >
On Fri, Dec 04, 2020 at 06:37:02PM +0100, Uros Bizjak wrote:
> > + "(INTVAL (operands[3]) & (GET_MODE_BITSIZE (mode) - 1))
> > + == GET_MODE_BITSIZE (mode) - 1"
> > + [(set (match_dup 4) (match_dup 1))
> > + (set (match_dup 0)
> > + (any_rotate:SWI48 (match_dup 4)
> > +
On Fri, Dec 4, 2020 at 6:32 PM Jakub Jelinek wrote:
>
> Hi!
>
> As mentioned in the PR, we can combine ~(1 << x) into -2 r<< x, but we give
> up in the ~(1 << (x & 31)) cases, as *3_mask* don't allow
> immediate operand 1 and find_split_point prefers to split (x & 31) instead
> of the constant.
>
Hi!
As mentioned in the PR, we can combine ~(1 << x) into -2 r<< x, but we give
up in the ~(1 << (x & 31)) cases, as *3_mask* don't allow
immediate operand 1 and find_split_point prefers to split (x & 31) instead
of the constant.
With these combine splitters we help combine decide how to split th
Hi!
We currently incorrectly reject the first testcase, because
cxx_fold_indirect_ref_1 doesn't attempt to handle UNION_TYPEs.
As the second testcase shows, it isn't that easy, because I believe we need
to take into account the active member and prefer that active member over
other members, becaus
Hi!
As mentioned in the PR, we shouldn't treat non-replaceable operator
new/delete (e.g. with the placement new) as replaceable ones.
There is some pending discussion that perhaps operator delete called from
delete if not replaceable should return some other fnspec, but can we handle
that increme
The changes reverted here are exposing an existing problem with alias
template comparisons. The typename_type changes are also incomplete,
possibly for similar reasons. It seems safer to revert them, fix the
underlying issue and then move forwards.
The testcases is adjusted to more robustly ch
On 11/19/20, 10:52 AM, "Richard Earnshaw (lists)"
wrote:
> Having the same option have a completely different meaning would be even
> worse than not having the option at all. So no, that's a non-starter.
The attached patch 0001 removes --with-{cpu,arch,tune}-32.
Bootstrap and regression testing
> On Dec 4, 2020, at 2:50 AM, Richard Biener wrote:
>
> On Thu, Dec 3, 2020 at 6:33 PM Richard Sandiford
> mailto:richard.sandif...@arm.com>> wrote:
>>
>> Richard Biener via Gcc-patches writes:
>>> On Tue, Nov 24, 2020 at 4:47 PM Qing Zhao wrote:
Another issue is, in order to check whe
When definitions marked with used attribute and unmarked definitions are
placed in the section with the same name, switch to a new section if the
SECTION_RETAIN bit doesn't match.
gcc/
PR target/98146
* output.h (switch_to_section): Add a tree argument, default to
nullptr.
When SECTION_RETAIN is used, definitions marked with used attribute and
unmarked definitions are placed in a section with the same name. Instead
of issue an error:
[hjl@gnu-cfl-2 gcc]$ /usr/gcc-11.0.0-x32/bin/gcc -S c.c
-fdiagnostics-plain-output
c.c:2:49: error: ‘foo1’ causes a section type con
When SECTION_RETAIN is used, issue a warning when a symbol without used
attribute and a symbol with used attribute are placed in the section with
the same name, like
int __attribute__((used,section(".data.foo"))) foo2 = 2;
int __attribute__((section(".data.foo"))) foo1 = 1;
since assembler will p
On Wed, 25 Nov 2020, Hans-Peter Nilsson wrote:
> Current cc0 head-count is down to avr, cr16, h8300, vax, with
> two of them recently having patches posted, alas not a lot of
> ports left to try this advice.
Hmm, the VAX port surely did not qualify for an innovative approach
anyway (though stil
On 12/3/20 9:30 AM, Richard Biener wrote:
> On Wed, 2 Dec 2020, Bernd Edlinger wrote:
>
>> On 12/2/20 8:50 AM, Richard Biener wrote:
>>> On Tue, 1 Dec 2020, Bernd Edlinger wrote:
>>>
Hi!
This removes gimple_debug stmts without block info after a
NULL INLINE_ENTRY.
>>>
> From: Martin Sebor via Gcc-patches
> Date: Fri, 4 Dec 2020 01:49:51 +0100
> On 12/3/20 12:14 PM, Hans-Peter Nilsson via Gcc-patches wrote:
> > Belatedly, here's an updated version, using Martin Sebor's
> > suggested wording from
> > "https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549580.ht
On Fri, Dec 04, 2020 at 05:16:38AM -0800, H.J. Lu via Gcc-patches wrote:
> On Fri, Dec 4, 2020 at 4:17 AM Jozef Lawrynowicz
> wrote:
> >
> > On Thu, Dec 03, 2020 at 04:06:50PM -0800, H.J. Lu via Gcc-patches wrote:
> > > When SECTION_RETAIN is used, definitions marked with used attribute and
> > >
On 12/4/20 2:38 PM, Matthias Klose wrote:
> On 12/4/20 9:07 AM, Kito Cheng via Gcc-patches wrote:
>> Committed, thanks :)
>>
>> On Thu, Dec 3, 2020 at 8:51 AM Jim Wilson wrote:
>>>
>>> On Tue, Dec 1, 2020 at 12:13 AM Kito Cheng wrote:
- We would like to canonicalize the arch string for
Hi Jakub,
this is a new version of the structure element mapping patch for OpenMP 5.0
requirement
changes.
This one uses the approach you've outlined in your concept patch [1], basically
to
use more special REFCOUNT_* values to mark them, and link following structure
element
splay_tree_keys ba
On Fri, Dec 4, 2020 at 2:35 PM Jakub Jelinek wrote:
>
> On Fri, Dec 04, 2020 at 02:30:45PM +0100, Martin Liška wrote:
> > On 12/4/20 10:03 AM, Richard Biener wrote:
> > > Otherwise 0001- looks good to me.
> >
> > Pushed that to master.
> >
> > > As said I'd like to see opinions
> > > from others o
PING
May I please ping the patch, it's waiting here for a review
for quite some time.
Thanks,
Martin
On 7/23/20 12:17 PM, Martin Liška wrote:
On 7/21/20 6:07 AM, Fangrui Song wrote:
If the value does not contain any path component separator (e.g. a
slash), the linker will be searched for usin
On Fri, Dec 04, 2020 at 02:38:54PM +0100, Matthias Klose wrote:
> On 12/4/20 9:07 AM, Kito Cheng via Gcc-patches wrote:
> > Committed, thanks :)
> >
> > On Thu, Dec 3, 2020 at 8:51 AM Jim Wilson wrote:
> >>
> >> On Tue, Dec 1, 2020 at 12:13 AM Kito Cheng wrote:
> >>>
> >>> - We would like to ca
> OK, I'll start with -alt then, thanks.
Andrew is exactly correct, contracts-jac-alt is still the current branch
we're focusing our upstreaming efforts on.
It's trailing upstream master by a fair bit at this point. I'll get a merge
pushed shortly.
Please let me know if there's anything I can do
On 12/4/20 9:07 AM, Kito Cheng via Gcc-patches wrote:
> Committed, thanks :)
>
> On Thu, Dec 3, 2020 at 8:51 AM Jim Wilson wrote:
>>
>> On Tue, Dec 1, 2020 at 12:13 AM Kito Cheng wrote:
>>>
>>> - We would like to canonicalize the arch string for --with-arch for
>>>easier handling multilib,
On Fri, Dec 04, 2020 at 02:30:45PM +0100, Martin Liška wrote:
> On 12/4/20 10:03 AM, Richard Biener wrote:
> > Otherwise 0001- looks good to me.
>
> Pushed that to master.
>
> > As said I'd like to see opinions
> > from others on the
> > driver / backend communication for 0002.
>
> To be honest,
On 12/4/20 10:03 AM, Richard Biener wrote:
Otherwise 0001- looks good to me.
Pushed that to master.
As said I'd like to see opinions
from others on the
driver / backend communication for 0002.
To be honest, we moved back to the original implementation which used
a temporary file. There hasn
Here are the declarations of module.cc. I'll fill these in with
nop-stubs when adding the remaining pieces of the modules
infrastructure. Finally replacing the contents of module.cc with the
real thing when victory is within reach.
This provides the inline predicates about module state, and
On Fri, Dec 4, 2020 at 4:17 AM Jozef Lawrynowicz
wrote:
>
> On Thu, Dec 03, 2020 at 04:06:50PM -0800, H.J. Lu via Gcc-patches wrote:
> > When SECTION_RETAIN is used, definitions marked with used attribute and
> > unmarked definitions are placed in the same section. Instead of issue
> > an error:
On Fri, Dec 4, 2020 at 5:35 AM Rainer Orth
wrote:
> On AIX 7.2, there are changes like
>
> -PASS: g++.dg/gomp/tls-5.C -std=c++2a scan-assembler-symbol-section symbol
> ^_?ir$ (found ir) has section ^\\.tbss|\\[TL\\] (found _tls5.tls_[TL],4)
> +PASS: g++.dg/gomp/tls-5.C -std=c++2a scan-assem
[AMD Public Use]
Hi Honza,
> -Original Message-
> From: Jan Hubicka
> Sent: Friday, December 4, 2020 5:25 PM
> To: Kumar, Venkataramanan
> Cc: gcc-patches@gcc.gnu.org; Uros Bizjak
> Subject: Re: [PATCH] [X86_64]: Enable support for next generation AMD
> Zen3 CPU
>
> [CAUTION: External
On Thu, Dec 03, 2020 at 04:06:50PM -0800, H.J. Lu via Gcc-patches wrote:
> When SECTION_RETAIN is used, definitions marked with used attribute and
> unmarked definitions are placed in the same section. Instead of issue
> an error:
>
> [hjl@gnu-cfl-2 gcc]$ /usr/gcc-11.0.0-x32/bin/gcc -S c.c
> -fd
Hi H.J.,
On Thu, Dec 03, 2020 at 04:06:51PM -0800, H.J. Lu via Gcc-patches wrote:
> When definitions marked with used attribute and unmarked definitions are
> placed in the same section, switch to a new section if the SECTION_RETAIN
> bit doesn't match.
GAS doesn't create separate sections for
> [AMD Official Use Only - Internal Distribution Only]
>
> Hi Maintainers,
>
> PFA, the patch that enables support for the next generation AMD Zen3 CPU via
> -march=znver3.
> This is a very basic enablement patch. As of now the cost, tuning and
> scheduler changes are kept same as znver2.
> Fur
split_constant_offset currently gives up looking at ranges when
dealing with possibly wrapping operations for looking through
conversions when the downstream analysis does not yield a SSA name.
That's overly conservative and we have a nice helper that can
deal with arbitrary expresssions. Use that
Hi Rainer,
thanks for looking at this, I was trying to see how to fix the failing Darwin
tests last week, and concluded that the absence of target selectors/xfail
meant skipping some tests - this is a much better solution.
Rainer Orth wrote:
I recently started looking into scan-assembler-symb
On Thu, 3 Dec 2020 at 16:50, Kyrylo Tkachov wrote:
>
> Hi Prathamesh,
>
> > -Original Message-
> > From: Prathamesh Kulkarni
> > Sent: 03 December 2020 10:50
> > To: gcc Patches ; Kyrylo Tkachov
> >
> > Subject: [PR66791][ARM] Replace __builtin_neon_vcreate* for vcreate
> > intrinsics
>
On Fri, 4 Dec 2020, Jakub Jelinek wrote:
> Hi!
>
> The following testcase is rejected, because when trying to encode a zeroing
> CONSTRUCTOR, the code was using build_constructor to build initializers for
> the elements but when recursing the function handles CONSTRUCTOR only for
> aggregate type
On Fri, 4 Dec 2020, Jakub Jelinek wrote:
> Hi!
>
> The PR88587 fix changes DECL_MODE of vars with vector type during
> inlining/cloning
> when the vars are copied, so that their DECL_MODE matches their TYPE_MODE in
> the new function. Unfortunately, the following testcase still ICEs, the var
>
Hi!
The following testcase is rejected, because when trying to encode a zeroing
CONSTRUCTOR, the code was using build_constructor to build initializers for
the elements but when recursing the function handles CONSTRUCTOR only for
aggregate types.
The following patch fixes that by using build_zero
I recently started looking into scan-assembler-symbol-section since all
tests using it were FAILing on Solaris/SPARC. Unfortuntely, the more I
looked the more issues I found, both with the implementation and the
interface. This patch addresses some of those, but there are quite a
number of open q
Hi!
The PR88587 fix changes DECL_MODE of vars with vector type during
inlining/cloning
when the vars are copied, so that their DECL_MODE matches their TYPE_MODE in
the new function. Unfortunately, the following testcase still ICEs, the var
isn't really used in the new function and so it isn't co
---
gcc/ipa-dfe.c | 262 +++---
gcc/ipa-dfe.h | 108 +++---
gcc/ipa-field-reorder.c| 134 +++
gcc/ipa-type-escape-analysis.c | 636 -
gcc/ipa-type-escape-analysis.h | 160 -
5 files changed, 643 insert
---
gcc/common.opt| 4 ++
gcc/ipa-type-escape-analysis.c| 11 +
.../ipa/ipa-access-counter-00-simple-read-0.c | 22 ++
.../ipa-access-counter-01-simple-write-0.c| 22 ++
.../ipa-access-counter-02-pointer-read-0.c| 22 +
We add a heuristic in order to be able to transform functions which
receive void* arguments as a way to generalize over arguments. An
example of this is qsort. The heuristic works by first inspecting
leaves in the call graph. If the leaves only contain a reference
to a single RECORD_TYPE then we
2020-11-04 Erick Ochoa
* ipa-field-reorder: Add flag to exit transformation.
* ipa-type-escape-analysis: Same.
---
gcc/ipa-field-reorder.c| 3 +-
gcc/ipa-type-escape-analysis.c | 54 --
gcc/ipa-type-escape-analysis.h | 2 ++
3 files changed,
2020-11-04 Erick Ochoa
* Makefile.in: Add file to documentation sources.
* doc/dfe.texi: New section.
* doc/gccint.texi: Include new section.
---
gcc/Makefile.in | 3 +-
gcc/doc/dfe.texi| 187
gcc/doc/gccint.texi | 2 +
3
Field reordering of structs at link-time
2020-11-04 Erick Ochoa
* Makefile.in: Add new file to list of sources.
* common.opt: Add new flag for field reordering.
* passes.def: Add new pass.
* tree-pass.h: Same.
* ipa-field-reorder.c: New file.
* ipa-type-escape-analys
Using the Dead Field Analysis, Dead Field Elimination
automatically transforms gimple to eliminate fields that
are never read.
2020-11-04 Erick Ochoa
* Makefile.in: Add file to list of sources.
* ipa-dfe.c: New.
* ipa-dfe.h: Same.
* ipa-type-escape-analysis.h: Export code us
This commit includes the following components:
Type-based escape analysis to determine structs that can be modified at
link-time.
Field access analysis to determine which fields are never read.
The type-based escape analysis provides a list of types, that are not
visible outside of the c
Hello,
I'm sharing the most recent version of dead-field elimination. In this
patchset the following issues have been addressed:
* CamelCase -> snake_case
* STL -> GCC specific data structures
* Fixed the commit messages (the last two commits will be squashed in
future patchset so the commit
gcc/testsuite/ChangeLog:
PR testsuite/98123
* gcc.dg/tree-ssa/if-to-switch-4.c: Add param to make the test
stable on all architectures.
* gcc.dg/tree-ssa/if-to-switch-6.c: Likewise.
* gcc.dg/tree-ssa/if-to-switch-8.c: Likewise.
---
gcc/testsuite/gcc.dg/tre
> I think you need to add an effective-target check, because the new test
> fails on aarch64/arm:
Done.
--
Eric Botcazou
On Thu, 3 Dec 2020 at 13:33, Richard Biener via Gcc-patches
wrote:
>
> On Thu, Dec 3, 2020 at 11:49 AM Eric Botcazou wrote:
> >
> > Hi,
> >
> > this replaces the ICE by a sorry message for the use of reverse scalar
> > storage
> > order with a 128-bit decimal floating-point type on 32-bit platfo
Following submission of the heterogeneous lookup in unordered containers
I rebased this patch on top of it.
Appart from reducing its size because of some code reuse the
heterogeneous lookup had no impact on this one. This is because when I
cannot find out if conversion from inserted element ty
mtune=generic -march=x86-64 -g -O2
> -frecord-gcc-switches-file=/tmp/ccm3kL7d.cmdline
>
> 3) DWARF producer:
>
> DW_AT_producer: (indirect string, offset: 0x97): GNU C17
> 11.0.0 20201204 (experimental) -dumpbase-ext .c -mtune=generic -march=x86-64
> -g -O2
>
> and
>
On Thu, Dec 3, 2020 at 4:29 PM Kumar, Venkataramanan
wrote:
>
> [AMD Public Use]
>
>
>
>
> Hi Maintainers,
>
>
>
> PFA, the patch that enables support for the next generation AMD Zen3 CPU via
> -march=znver3.
>
> This is a very basic enablement patch. As of now the cost, tuning and
> scheduler c
On Thu, Dec 3, 2020 at 6:33 PM Richard Sandiford
wrote:
>
> Richard Biener via Gcc-patches writes:
> > On Tue, Nov 24, 2020 at 4:47 PM Qing Zhao wrote:
> >> Another issue is, in order to check whether an auto-variable has
> >> initializer, I plan to add a new bit in “decl_common” as:
> >> /*
On Thu, Dec 3, 2020 at 11:13 PM Jeff Law via Gcc-patches
wrote:
>
>
>
> On 12/3/20 8:29 AM, Kumar, Venkataramanan via Gcc-patches wrote:
> > [AMD Public Use]
> >
> >
> > Hi Maintainers,
> >
> > PFA, the patch that enables support for the next generation AMD Zen3 CPU
> > via -march=znver3.
> > Thi
On Thu, Dec 3, 2020 at 10:46 PM Jeff Law via Gcc-patches
wrote:
>
>
>
> On 12/3/20 10:53 AM, Jason Merrill via Gcc-patches wrote:
> > It looks cleaner if we can use a vec* directly as a range for the C++11
> > range-based 'for' loop, without needing to indirect from it, and also works
> > with nul
Pushed to master.
Martin
contrib/ChangeLog:
* check-params-in-docs.py: use flake8 and add some
tweaks to ignore aarch64 params.
gcc/ChangeLog:
* doc/invoke.texi: Add missing params.
---
contrib/check-params-in-docs.py | 12 +-
gcc/doc/invoke.texi |
On Thu, Dec 3, 2020 at 8:13 PM Eric Botcazou wrote:
>
> Hi,
>
> this is a regression present on the mainline and 10 branch: on the one hand,
> IPA-SRA does *not* disqualify accesses with zero size but, on the other hand,
> it checks that accesses present in the tree have a (strictly) positive size
--param ggc-min-expand=30 --param ggc-min-heapsize=4096
# options passed: -dumpbase-ext .c -mtune=generic -march=x86-64 -g -O2
-frecord-gcc-switches-file=/tmp/ccm3kL7d.cmdline
3) DWARF producer:
DW_AT_producer: (indirect string, offset: 0x97): GNU C17 11.0.0
20201204 (experimental) -
Committed, thanks :)
On Thu, Dec 3, 2020 at 8:51 AM Jim Wilson wrote:
>
> On Tue, Dec 1, 2020 at 12:13 AM Kito Cheng wrote:
>>
>> - We would like to canonicalize the arch string for --with-arch for
>>easier handling multilib, so split canonicalization part to a stand
>>along script to s
99 matches
Mail list logo
