Hi Segher,
on 2019/11/20 上午1:29, Segher Boessenkool wrote:
> Hi!
>
> On Tue, Nov 12, 2019 at 06:41:07PM +0800, Kewen.Lin wrote:
>> +;; code iterators and attributes for vector FP comparison operators:
>> +(define_code_iterator vector_fp_comparison_operator [lt le ne
>> +
On Wed, 20 Nov 2019, Jakub Jelinek wrote:
> Hi!
>
> I agree that we shouldn't have made __builtin_stack_{save,restore} public,
> but I'd fear it is too late to remove it now (and replace by internal fn),
> I'd think some code might use it to control when e.g. alloca will be
> released. As the co
On Wed, 20 Nov 2019, Jakub Jelinek wrote:
> Hi!
>
> On the following testcase we ICE on i686-linux (32-bit), because we store
> (first 96-bit, then 72-bit) structure into the first part of a 2x 96-bit
> complex long double, and for 96-bit floats there is no corresponding
> integral mode that cove
P9LE generated instruction is not worse than P8LE.
mtvsrdd;xxlnot;stxv vs. not;not;std;std.
Update the test case to fix failures.
v3:
Define and use check_effective_target_xxx etc.
pre_power8: ... power6, power7.
power8: power8 only.
post_power8: power8, power9 ...
post_power9: power9, power10 ...
On 16.11.2019. 00:33, Jeff Law wrote:
> On 11/15/19 10:27 AM, Dragan Mladjenovic wrote:
>> From: "Dragan Mladjenovic"
>>
>> This patch tightens the instruction definitions to make sure
>> that MSA branch instructions cannot be put into delay slots and have their
>> delay slots eligible for
On Wed, Nov 20, 2019 at 12:53 AM Jakub Jelinek wrote:
>
> Hi!
>
> The arch= handling in target attribute right now clears almost all isa_flags
> and all isa_flags2, so that later call to ix86_option_override_internal
> can set just the isa options for the specific arch and nothing else.
> Unfortun
On 11/19/19 11:38 PM, Jakub Jelinek wrote:
Hi!
The following patch is a minimal fix to avoid
cannot convert ‘‘addr_expr’ not supported by dump_type’ to ‘X*’
and similar messages. The recently added complain_about_bad_argument
function expects a from_type argument, but conv->from isn't necessari
On 11/19/19 11:46 PM, Jakub Jelinek wrote:
Hi!
In lambdas, the only valid decl specifiers are mutable, constexpr or
consteval. For various other simple specifiers it is fine to parse them
and reject afterwards if the parsing is simple consuming of a single token
and setting some flags, but as t
On Nov 6, 2019, Alexandre Oliva wrote:
> (CALLEE_FROM_CGRAPH_P): New.
> (dump_final_callee_vcg, dump_final_node_vcg): New.
I goofed in the testing of this last-minute change. It only works with
optimization disabled. With any optimization enabled,
pass_remove_cgraph_callee_edges r
On Tue, 19 Nov 2019, Joseph Myers wrote:
> > > 4. How does this interact with sysroot suffixes (again, this should be
> > > made clear in the documentation)?
> >
> > There is no interaction, the patch merely changes where the libraries are
> > installed. If the installation sysroot directory
On 11/19/19 4:42 PM, Jakub Jelinek wrote:
> Hi!
>
> On the following testcase we ICE on i686-linux (32-bit), because we store
> (first 96-bit, then 72-bit) structure into the first part of a 2x 96-bit
> complex long double, and for 96-bit floats there is no corresponding
> integral mode that cover
On 11/19/19 4:58 PM, Jakub Jelinek wrote:
> Hi!
>
> I agree that we shouldn't have made __builtin_stack_{save,restore} public,
> but I'd fear it is too late to remove it now (and replace by internal fn),
> I'd think some code might use it to control when e.g. alloca will be
> released. As the com
On 11/19/19 5:03 PM, Jakub Jelinek wrote:
> On Tue, Sep 03, 2019 at 02:27:29PM -0600, Jeff Law wrote:
+ /* The transformation below will inherently introduce a memory load,
+ for which LHS may not be initialized yet if it is not in NOTRAP,
+ so a -Wmaybe-uninitialized warnin
Add flags to find libatomic in build-tree testing, fixing a catastrophic
libgomp testsuite failure with `riscv*-*-linux*' targets, which imply
`-latomic' with the `-pthread' GCC option, implied in turn by the
`-fopenacc' and `-fopenmp' options, removing failures like:
.../bin/riscv64-linux-gnu-
I've committed this patch to add release notes for new C2X features in GCC
10.
diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
index 1e9c3f8d..52eb303c 100644
--- a/htdocs/gcc-10/changes.html
+++ b/htdocs/gcc-10/changes.html
@@ -63,6 +63,44 @@ a work-in-progress.
+C
+
+
The standard [[]] attributes currently defined in C2x are all not
valid on types not being defined at the time.
Use on such types results in a warning from attribs.c about attributes
appertaining to types (the warning that I think is bogus in general
for both C and C++, applying as it does to all
On Tue, Sep 03, 2019 at 02:27:29PM -0600, Jeff Law wrote:
> >> + /* The transformation below will inherently introduce a memory load,
> >> + for which LHS may not be initialized yet if it is not in NOTRAP,
> >> + so a -Wmaybe-uninitialized warning message could be triggered.
> >> + Since
On 11/19/19 2:02 AM, Claudiu Zissulescu wrote:
> ARC processors can use scaled addresses, i.e., the offset part of the
> load address can be shifted by 2 (multiplied by 4). Add this pattern
> and a test for it.
>
> gcc/
> -xx-xx Claudiu Zissulescu
>
> * config/arc/arc.md (load_scaled
Hi!
I agree that we shouldn't have made __builtin_stack_{save,restore} public,
but I'd fear it is too late to remove it now (and replace by internal fn),
I'd think some code might use it to control when e.g. alloca will be
released. As the comment on insert_clobber* says, the addition of the
clob
On 11/19/19 2:02 AM, Claudiu Zissulescu wrote:
> Use arc-passes.def to register ARC specific passes.
>
> Ok to apply?
> Claudiu
>
> gcc/
> -xx-xx Claudiu Zissulescu
>
> * config/arc/arc-protos.h (make_pass_arc_ifcvt): Declare.
> (make_pass_arc_predicate_delay_insns): Likewise.
Hi!
The arch= handling in target attribute right now clears almost all isa_flags
and all isa_flags2, so that later call to ix86_option_override_internal
can set just the isa options for the specific arch and nothing else.
Unfortunately, it doesn't work, because next to the ix86_isa_flags{,2}
we ha
Hi!
In lambdas, the only valid decl specifiers are mutable, constexpr or
consteval. For various other simple specifiers it is fine to parse them
and reject afterwards if the parsing is simple consuming of a single token
and setting some flags, but as the testcase shows, especially allowing
type s
Hi!
On the following testcase we ICE on i686-linux (32-bit), because we store
(first 96-bit, then 72-bit) structure into the first part of a 2x 96-bit
complex long double, and for 96-bit floats there is no corresponding
integral mode that covers it and we ICE when op0 is not in MEM (it is a
REG).
Hi!
The following patch is a minimal fix to avoid
cannot convert ‘‘addr_expr’ not supported by dump_type’ to ‘X*’
and similar messages. The recently added complain_about_bad_argument
function expects a from_type argument, but conv->from isn't necessarily a
type, it can be an expression too.
With
Hi!
The following patch fixes build of older GCC releases with newer ones.
In GCC 4.6 and earlier, we had:
struct cgraph_node;
struct cgraph_node *cgraph_node (tree);
and that is something on which GCC 9+ code errors on if it sees any
__gcc_diag__ and similar attributes, because cgraph_node it wan
On Tue, Nov 19, 2019 at 11:11:39PM +, Maciej W. Rozycki wrote:
> Why do you think it is important that it is only the relevant (i.e.
> `riscv*') targets that the directory providing newly-built libatomic is
> pointed at ?
Such changes don't happen every day, no other port added it similarly
Hi Richard,
On Tue, Nov 19, 2019 at 07:35:10PM +, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > r278411 causes bootstrap to fail on at least all powerpc*. Also, I am
> > author of this simplify-rtx code, and I think what you did is all wrong.
> > Also, it should be two patches, t
Add flags to find libatomic in build-tree testing, fixing a catastrophic
libgomp testsuite failure with targets such as `riscv-linux-gnu' that
imply `-latomic' with the `-pthread' GCC option, implied in turn by the
`-fopenacc' and `-fopenmp' options, removing failures like:
.../bin/riscv64-linu
This libgo patch by Than McIntosh updates cgo's
gccgoPkgpathToSymbolNew() to bring it into conformance with the way
that gccgo now handles package paths with embedded dots (see
https://golang.org/cl/200838). See also https://gcc.gnu.org/PR61880,
a related bug. This patch is a copy of https://gola
Am 19.11.19 um 11:39 schrieb Bernhard Reutner-Fischer:
+ char name[GFC_MAX_SYMBOL_LEN + 1];
+ snprintf (name, GFC_MAX_SYMBOL_LEN, "__dummy_%d_%s", var_num++,
+ f->sym->name);
+
+ if (gfc_get_sym_tree (name, ns, &symtree, false) != 0)
(I) you should + siz
On 11/18/19 3:45 PM, Paolo Carlini wrote:
functions like c_common_truthvalue_conversion are shared with the C
front-end thus don't get a tsubst_flags_t argument. It seems clear that
long term we have to do something about those but in the meanwhile we
have been using warning sentinels which, a
On 11/18/19 7:04 PM, Marek Polacek wrote:
The newly added diagnostic causes an ICE because the new grokdeclarator call
returned error_mark_node and DECL_SOURCE_LOCATION crashes on that. So don't
attempt to print the new diagnostic if we've encountered something not
resembling a bit-field.
Boots
On 11/19/19 1:44 AM, Marek Polacek wrote:
It also looks like you're using the LOOKUP flag to mean two different
things:
1) try to treat parenthesized args as an aggregate initializer
(build_new_method_call_1)
2) treat this CONSTRUCTOR as coming from parenthesized args
(store_init_value/digest_in
On Tue, 19 Nov 2019, David Malcolm wrote:
> If we're going with this approach (which I'll leave to Joseph), perhaps
I think reusing the glibc generator is appropriate.
--
Joseph S. Myers
jos...@codesourcery.com
On Tue, 19 Nov 2019, Richard Biener wrote:
> > +/* For nested functions disqualify ones taking VLAs by value
> > + from inlining since the middle-end cannot deal with this.
> > + ??? We should arrange for those to be passed by reference
> > + with emitting the copy on the ca
On Sat, 2019-11-16 at 21:42 +0100, Thomas Schwinge wrote:
> Hi David!
>
> On 2019-11-15T20:22:47-0500, David Malcolm
> wrote:
> > This patch kit
>
> (I have not looked at the patches.) ;-)
>
> > introduces a static analysis pass for GCC that can diagnose
> > various kinds of problems in C code
On 11/18/19 11:22 PM, Jakub Jelinek wrote:
On Mon, Nov 18, 2019 at 02:38:51PM -0500, Jason Merrill wrote:
On 11/8/19 9:14 AM, Jakub Jelinek wrote:
Hi!
We ICE on the following testcase, because DECL_INITIAL (decl) is
error_mark_node due to previously reported error and
cxx_eval_outermost_consta
On Tue, Nov 19, 2019 at 11:33:13AM +, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > On Sun, Nov 17, 2019 at 11:35:26PM +, Richard Sandiford wrote:
> >> While working on SVE, I've noticed several cases in which we fail
> >> to combine instructions because the combined form would
The C++ committee continues to discuss how best to avoid breaking existing
code with the new rules for reversed operators. A recent suggestion was to
base the tie-breaker on the parameter types of the candidates, which made a
lot of sense to me, so this patch implements that.
This patch also ment
Hi!
On Mon, Nov 18, 2019 at 04:21:07PM +0800, luoxhu wrote:
> On 2019/11/15 18:17, Segher Boessenkool wrote:
> > On Thu, Nov 14, 2019 at 09:12:32PM -0600, Xiong Hu Luo wrote:
> >> P9LE generated instruction is not worse than P8LE.
> >> mtvsrdd;xxlnot;stxv vs. not;not;std;std.
> >> Update the test
Segher Boessenkool writes:
> Hi,
>
> r278411 causes bootstrap to fail on at least all powerpc*. Also, I am
> author of this simplify-rtx code, and I think what you did is all wrong.
> Also, it should be two patches, the CSE part should be separate. (I can
> not tell if that is the part that regr
Hi,
this patch removes unused argument of estimate_edge_size_and_time.
Bootstrapped/regtested x86_64-linux, comitted.
* ipa-fnsummary.c (estimate_edge_size_and_time): Drop parameter PROP.
(estimate_calls_size_and_time): Update.
Index: ipa-fnsummary.c
===
On 19.11.19 20:01, Jeff Law wrote:
> On 11/19/19 12:00 PM, Tim Rühsen wrote:
>> Thanks. Where exactly did it go ? Still can't see it in
>> git://sourceware.org/git/binutils-gdb.git. Is there another repository ?
> It's in the GCC repo. binutils-gdb will (at some point) pull it from GCC.
> jeff
Th
Hi,
this patch avoids some extra calculation in edge_badness.
Bootstrapped/regtested x86_64-linux. Comitted.
* ipa-inline.c (inlining_speedup): New function.
(edge_badness): Use it.
Index: ipa-inline.c
===
--- ipa-inl
On 16.11.19 18:14, Jeff Law wrote:
> On 11/12/19 9:39 AM, Tim Rühsen wrote:
>> On 11/12/19 4:15 PM, Ian Lance Taylor wrote:
>>> On Tue, Nov 12, 2019 at 6:15 AM Tim Rühsen wrote:
this is a proposal to fix
https://sourceware.org/bugzilla/show_bug.cgi?id=25180
In short:
cxxfi
On 11/19/19 12:00 PM, Tim Rühsen wrote:
> On 16.11.19 18:14, Jeff Law wrote:
>> On 11/12/19 9:39 AM, Tim Rühsen wrote:
>>> On 11/12/19 4:15 PM, Ian Lance Taylor wrote:
On Tue, Nov 12, 2019 at 6:15 AM Tim Rühsen wrote:
> this is a proposal to fix
> https://sourceware.org/bugzilla/show_
On 11/17/19 5:25 AM, Iain Sandoe wrote:
+++ b/gcc/cp/coroutines.cc
+/* = Morph and Expand. =
+/* Helpers for label creation. */
+static tree
+create_anon_label_with_ctx (location_t loc, tree ctx)
+{
+ tree lab = build_decl (loc, LABEL_DECL, NULL_TREE, void
On Tue, 19 Nov 2019, David Malcolm wrote:
> If we're going with this approach, and redistributing those unicode data
> files as part of our repo and tarballs, do we need some kind of
> copyright/license statement that spells out the situation? What does
> glibc do for this?
glibc includes the fi
On Wed, Nov 13, 2019 at 01:15:18PM +0100, Ilya Leoshkevich wrote:
> > But OTOH it may well be the case that other things in cleanup_cfg make
> > the known dominance info invalid as well, in which case just the comment
> > is a bit misleading. Sounds likely to me :-)
>
> Yeah, that's what I worry
On Fri, 2019-09-27 at 16:41 -0400, Lewis Hyatt wrote:
> On Thu, Sep 26, 2019 at 08:46:56PM +, Joseph Myers wrote:
> > On Thu, 26 Sep 2019, Lewis Hyatt wrote:
> >
> > > A couple notes:
> > > - In order to avoid any portability problems with wchar_t,
> > > the
> > > equivalent of wcwidth()
Hi!
On Tue, Nov 12, 2019 at 06:41:07PM +0800, Kewen.Lin wrote:
> +;; code iterators and attributes for vector FP comparison operators:
> +(define_code_iterator vector_fp_comparison_operator [lt le ne
> + ungt unge unlt unle])
Let's indent that diff
On Tue, Nov 19, 2019 at 10:19:05AM -0600, Segher Boessenkool wrote:
> On Tue, Nov 19, 2019 at 03:53:43PM +0100, Jan Hubicka wrote:
> > > Sounds perfectly fine to me, but how many tests will need changing? Is
> > > it only those that use symbol versioning directly?
> >
> > There are no tests prese
On Tue, Nov 19, 2019 at 04:32:09PM +, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > r278411 causes bootstrap to fail on at least all powerpc*. Also, I am
> > author of this simplify-rtx code, and I think what you did is all wrong.
> > Also, it should be two patches, the CSE part s
Segher Boessenkool writes:
> Hi,
>
> r278411 causes bootstrap to fail on at least all powerpc*. Also, I am
> author of this simplify-rtx code, and I think what you did is all wrong.
> Also, it should be two patches, the CSE part should be separate. (I can
> not tell if that is the part that regr
On Tue, Nov 19, 2019 at 03:53:43PM +0100, Jan Hubicka wrote:
> > Sounds perfectly fine to me, but how many tests will need changing? Is
> > it only those that use symbol versioning directly?
>
> There are no tests presently, I plan to write some so those will get
> dg-require-symver.
>
> .symver
Hi,
r278411 causes bootstrap to fail on at least all powerpc*. Also, I am
author of this simplify-rtx code, and I think what you did is all wrong.
Also, it should be two patches, the CSE part should be separate. (I can
not tell if that is the part that regresses us, either).
Could you please re
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90007
Sometime ago a code which permits LRA to reload hard register into
memory as it did for pseudo were added. But this LRA possibility was
not reflected in recog.c. The following patch fixes this discrepancy
and as a
Hi Richard,
> I acked this here:
> https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01229.html
Thanks - I missed your email, but it's committed now. Yes we will
need to look at the vector costs again and retune them based on
recent vectorizer improvements and latest microarchitectures.
Cheers,
Wil
On 11/19/19 3:01 AM, Alexandre Oliva wrote:
> Hello, Bernd,
>
> Apologies for taking so long to respond. I had not noticed your patch
> before being explicitly copied on it.
>
> IIUC you're describing a problem in GDB, that could be summed up as its
> not paying attention to is_stmt and being un
On 11/19/19 4:19 AM, Richard Biener wrote:
On Tue, Nov 19, 2019 at 10:04 AM Jakub Jelinek wrote:
Hi!
xchg instruction is smaller, in some cases much smaller than 3 moves,
(e.g. in the testcase 2 bytes vs. 8 bytes), and is not a performance
disaster, but from Agner Fog tables and
https://stacko
Wilco Dijkstra writes:
> ping
I acked this here: https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01229.html
>
> PR79262 has been fixed for almost all AArch64 cpus, however the example is
> still
> vectorized in a few cases, resulting in lower performance. Increase the cost
> of
> vector-to-scal
ping
PR79262 has been fixed for almost all AArch64 cpus, however the example is still
vectorized in a few cases, resulting in lower performance. Increase the cost of
vector-to-scalar moves so it is more similar to the other vector costs. As a
result
-mcpu=cortex-a53 no longer vectorizes the te
ping
The current pressure scheduler doesn't appear to correctly track register
pressure and avoid creating unnecessary spills when register pressure is high.
As a result disabling the early scheduler improves integer performance
considerably and reduces codesize as a bonus. Since scheduling floati
ping
Various CPUs have max_cond_insns set to 5 due to historical reasons.
Benchmarking shows that max_cond_insns=2 is fastest on modern Cortex-A
cores, so change it to 2 for all Cortex-A cores. Set max_cond_insns
to 4 on Thumb-2 architectures given it's already limited to that by
MAX_INSN_PER_IT_
On Tue, Nov 19, 2019 at 12:58:19PM +, Richard Sandiford wrote:
> Fow the record, I think the assert was valid and I'd have preferred it
> if we'd fixed the targets so that they don't return bogus modes for
> preferred_simd_mode. After all, it's the targets that decide which
> vector modes are
> On Tue, Nov 19, 2019 at 07:29:37AM +0100, Jan Hubicka wrote:
> > Current patch makes GCC to accept symver attribute on all ELF targets
> > and simply output .symver directive into the assembly file hoping for
> > the best. I hope that is acceptable since user will be informed by
> > assembler th
On Tue, Nov 19, 2019 at 2:54 PM Martin Liška wrote:
>
> On 11/19/19 10:25 AM, Richard Biener wrote:
> > On Mon, Nov 18, 2019 at 10:17 AM Martin Liška wrote:
> >>
> >> On 11/14/19 1:15 PM, Richard Biener wrote:
> >>> Hmm. I was thinking of moving the pass instead of adding another one.
> >>> What
On Tue, Nov 19, 2019 at 2:18 PM Martin Liška wrote:
>
> On 11/19/19 1:42 PM, Richard Biener wrote:
> > Well, then call it from the caller of init_options_struct instead,
> > right after it or after the
> > langhook variant is called?
>
> Yes, that's definitely possible, there's a patch that I've j
I've committed this minor testcase update. The change updates the
expected result for amdgcn, but shouldn't affect any other target.
The compiler used to calculate the function address once and then call
it five times. Now it repeats the calculation five times, so the pattern
doesn't match. Th
On 11/19/19 11:25 AM, Jakub Jelinek wrote:
The point I'm trying to make is that with if-to-switch, if cswitch doesn't
handle it, we have a regression. If user writes it as a switch, it is a
missed optimization if we generate worse code than we could, but not a
regression.
Sure, but the questio
On 11/19/19 10:25 AM, Richard Biener wrote:
On Mon, Nov 18, 2019 at 10:17 AM Martin Liška wrote:
On 11/14/19 1:15 PM, Richard Biener wrote:
Hmm. I was thinking of moving the pass instead of adding another one.
What's the reason to run switch-conversion during early optimization again?
I'm
On 11/19/19 1:41 PM, Dennis Zhang wrote:
Hi Kyrill,
On 19/11/2019 11:21, Kyrill Tkachov wrote:
Hi Dennis,
On 11/12/19 5:32 PM, Dennis Zhang wrote:
Hi Kyrill,
On 12/11/2019 15:57, Kyrill Tkachov wrote:
On 11/12/19 3:50 PM, Dennis Zhang wrote:
Hi Kyrill,
On 12/11/2019 09:40, Kyrill Tkacho
Hi Kyrill,
On 19/11/2019 11:21, Kyrill Tkachov wrote:
> Hi Dennis,
>
> On 11/12/19 5:32 PM, Dennis Zhang wrote:
>> Hi Kyrill,
>>
>> On 12/11/2019 15:57, Kyrill Tkachov wrote:
>>> On 11/12/19 3:50 PM, Dennis Zhang wrote:
Hi Kyrill,
On 12/11/2019 09:40, Kyrill Tkachov wrote:
> Hi
On 11/19/19 1:42 PM, Richard Biener wrote:
Well, then call it from the caller of init_options_struct instead,
right after it or after the
langhook variant is called?
Yes, that's definitely possible, there's a patch that I've just locally tested.
Ready for trunk?
Thanks,
Martin
>From b868170d58
On Tue, Nov 19, 2019 at 12:58:19PM +, Richard Sandiford wrote:
> Jakub Jelinek writes:
> > This patch restores the previous behavior, there could be many reasons why
> > TYPE_MODE is BLKmode or some integral mode instead of a vector mode,
> > unsupported vector mode, lack of available register
Jakub Jelinek writes:
> Hi!
>
> This patch restores the previous behavior, there could be many reasons why
> TYPE_MODE is BLKmode or some integral mode instead of a vector mode,
> unsupported vector mode, lack of available registers etc.
Fow the record, I think the assert was valid and I'd have p
On Tue, Nov 19, 2019 at 12:37 PM Martin Liška wrote:
>
> On 11/19/19 11:03 AM, Richard Biener wrote:
> > On Mon, Nov 18, 2019 at 1:24 PM Martin Liška wrote:
> >>
> >> Hello.
> >>
> >> After my param to option transformation, we lost automatic GGC
> >> detection. It's because init_ggc_heuristics i
On Tue, Nov 19, 2019 at 12:36 PM Martin Liška wrote:
>
> On 11/19/19 10:12 AM, Richard Biener wrote:
> > On Tue, Nov 19, 2019 at 9:12 AM Martin Liška wrote:
> >>
> >> One potential improvement is to enable the heuristics
> >> for ENABLE_GC_CHECKING. The macro is about sanity checking
> >> and poi
On Tue, Nov 19, 2019 at 07:29:37AM +0100, Jan Hubicka wrote:
> Current patch makes GCC to accept symver attribute on all ELF targets
> and simply output .symver directive into the assembly file hoping for
> the best. I hope that is acceptable since user will be informed by
> assembler that symver
This patch adds GCN special casing for most of the OpenACC libgomp tests
that require it. It also disables one testcase that explicitly uses CUDA.
OK to commit?
Andrew
Update OpenACC tests for amdgcn
2019-11-19 Andrew Stubbs
libgomp/
* testsuite/libgomp.oacc-c-c++-common/acc_prof-init-1.
We are now vectorizing condition reduction chains but epilogue generation
doesn't consider them. The following fixes this by simply emitting
a chain of index vector updates rather than trying to be clever
and combining the conditions which is quite target dependent.
Bootstrap & regtest running
On 11/19/19 11:03 AM, Richard Biener wrote:
On Mon, Nov 18, 2019 at 1:24 PM Martin Liška wrote:
Hello.
After my param to option transformation, we lost automatic GGC
detection. It's because init_ggc_heuristics is called before
init_options_struct which memsets all the values to zero first.
I
On 11/19/19 10:12 AM, Richard Biener wrote:
On Tue, Nov 19, 2019 at 9:12 AM Martin Liška wrote:
One potential improvement is to enable the heuristics
for ENABLE_GC_CHECKING. The macro is about sanity checking
and poisoning of GGC memory. Which seems to me completely
independent to setting of t
Segher Boessenkool writes:
> On Sun, Nov 17, 2019 at 11:35:26PM +, Richard Sandiford wrote:
>> While working on SVE, I've noticed several cases in which we fail
>> to combine instructions because the combined form would need to be
>> placed earlier in the instruction stream than the last of th
Hi Dennis,
On 11/12/19 5:32 PM, Dennis Zhang wrote:
Hi Kyrill,
On 12/11/2019 15:57, Kyrill Tkachov wrote:
On 11/12/19 3:50 PM, Dennis Zhang wrote:
Hi Kyrill,
On 12/11/2019 09:40, Kyrill Tkachov wrote:
Hi Dennis,
On 11/7/19 1:48 PM, Dennis Zhang wrote:
Hi Kyrill,
I have rebased the patch
On 19/11/2019 10:35, Richard Henderson wrote:
I'm not sure what happened to v2. I can see it in my sent email, but it never
made it to the mailing list, and possibly not to Richard E. either.
So resending, with an extra testsuite fix for ilp32, spotted by Christophe.
Re thumb1, rather than an
On 16 November 2019 21:33:58 CET, Thomas Koenig wrote:
>Hello world,
>
>here is an update to the patch.
+ char name[GFC_MAX_SYMBOL_LEN + 1];
+ snprintf (name, GFC_MAX_SYMBOL_LEN, "__dummy_%d_%s", var_num++,
+ f->sym->name);
+
+ if (gfc_get_sym_tree (name,
I'm not sure what happened to v2. I can see it in my sent email, but it never
made it to the mailing list, and possibly not to Richard E. either.
So resending, with an extra testsuite fix for ilp32, spotted by Christophe.
Re thumb1, rather than an ifdef in config/arm/aarch-common.c, as I did in
On Tue, Nov 19, 2019 at 11:20:16AM +0100, Martin Liška wrote:
> On 11/19/19 10:12 AM, Jakub Jelinek wrote:
> > On Mon, Nov 18, 2019 at 03:34:35PM +0100, Martin Liška wrote:
> > > > Now, I believe with the if to gswitch optimization these will only
> > > > rarely
> > > > kick in, because the IL wil
On 11/19/19 10:12 AM, Jakub Jelinek wrote:
On Mon, Nov 18, 2019 at 03:34:35PM +0100, Martin Liška wrote:
Now, I believe with the if to gswitch optimization these will only rarely
kick in, because the IL will have switches that reassoc doesn't handle,
instead of series of ifs.
Yes, so my questi
On Nov 18 2019, Jeff Law wrote:
> On 11/18/19 6:17 AM, Martin Liška wrote:
>> Hi.
>>
>> The patch is about yet another bootstrap -Wmaybe-uninitialized warning.
>> I've just tested that on risv64 cross compiler with latest trunk.
>>
>> Ready to be installed?
>> Thanks,
>> Martin
>>
>> gcc/Change
On Mon, Nov 18, 2019 at 1:24 PM Martin Liška wrote:
>
> Hello.
>
> After my param to option transformation, we lost automatic GGC
> detection. It's because init_ggc_heuristics is called before
> init_options_struct which memsets all the values to zero first.
>
> I've tested the patch with --enable
On Tue, 19 Nov 2019 at 10:23, Richard Henderson
wrote:
>
> On 11/19/19 9:29 AM, Christophe Lyon wrote:
> > On Mon, 18 Nov 2019 at 20:54, Richard Henderson
> > wrote:
> >>
> >> On 11/18/19 1:30 PM, Christophe Lyon wrote:
> >>> I'm sorry to notice that the last test (asm-flag-6.c) fails to execute
On Sun, Nov 17, 2019 at 11:27 AM Iain Sandoe wrote:
>
>
> As described in the covering note, the main part of this is the
> expansion of the library support builtins, these are simple boolean
> or numerical substitutions.
>
> The functionality of implementing an exit from scope without cleanup
> i
> Hi!
>
> xchg instruction is smaller, in some cases much smaller than 3 moves,
> (e.g. in the testcase 2 bytes vs. 8 bytes), and is not a performance
> disaster, but from Agner Fog tables and
> https://stackoverflow.com/questions/45766444/why-is-xchg-reg-reg-a-3-micro-op-instruction-on-modern-int
On Mon, 18 Nov 2019 at 16:17, Kyrill Tkachov
wrote:
>
> Hi Prathamesh,
>
> On 11/14/19 6:47 PM, Prathamesh Kulkarni wrote:
> > Hi,
> > As suggested in PR, the attached patch falls back to distributing
> > rshift over plus_expr instead of fallback widening -> arithmetic ->
> > narrowing sequence, i
On 19/11/19 08:51 +, Jonathan Wakely wrote:
On 19/11/19 09:38 +0100, Stephan Bergmann wrote:
On 17/11/2019 02:07, Jonathan Wakely wrote:
This adds another chunk of the header.
The changes from P1456R1 (Move-only views) and P1862R1 (Range adaptors
for non-copyable iterators) are included,
On Mon, Nov 18, 2019 at 10:17 AM Martin Liška wrote:
>
> On 11/14/19 1:15 PM, Richard Biener wrote:
> > Hmm. I was thinking of moving the pass instead of adding another one.
> > What's the reason to run switch-conversion during early optimization again?
>
> I'm adding CC, as he's the author of cs
On 11/19/19 9:29 AM, Christophe Lyon wrote:
> On Mon, 18 Nov 2019 at 20:54, Richard Henderson
> wrote:
>>
>> On 11/18/19 1:30 PM, Christophe Lyon wrote:
>>> I'm sorry to notice that the last test (asm-flag-6.c) fails to execute
>>> when compiling with -mabi=ilp32. I have less details than for Arm,
On Tue, Nov 19, 2019 at 10:04 AM Jakub Jelinek wrote:
>
> Hi!
>
> xchg instruction is smaller, in some cases much smaller than 3 moves,
> (e.g. in the testcase 2 bytes vs. 8 bytes), and is not a performance
> disaster, but from Agner Fog tables and
> https://stackoverflow.com/questions/45766444/wh
1 - 100 of 119 matches
Mail list logo
