On 9/17/20 3:56 AM, Jeff Law wrote:
>
> If it's been ack'd by a maintainer, yes. Jakub definitely qualifies as
> a maintainer, so feel free to push it on Martin's behalf.
>
>
> jeff
Sure, it has been pushed, thanks all.
signature.asc
Description: OpenPGP digital signature
Qing Zhao writes:
> Segher and Richard,
>
> Now there are two major concerns from the discussion so far:
>
> 1. (From Richard): Inserting zero insns should be done after
> pass_thread_prologue_and_epilogue since later passes (for example,
> pass_regrename) might introduce new used caller-saved
On Wed, Aug 19, 2020 at 6:09 AM H.J. Lu wrote:
>
> On Tue, May 19, 2020 at 5:14 AM H.J. Lu wrote:
> >
> > On Tue, May 19, 2020 at 1:48 AM Uros Bizjak wrote:
> > >
> > > On Sun, May 17, 2020 at 7:06 PM H.J. Lu wrote:
> > > >
> > > > Duplicate the cmpstrn pattern for cmpmem. The only difference
On Wed, Aug 19, 2020 at 6:25 AM H.J. Lu wrote:
>
> On Wed, Jul 15, 2020 at 10:42:27AM -0700, H.J. Lu wrote:
> > Expand strncmp to "repz cmpsb" only with -minline-all-stringops since
> > "repz cmpsb" can be much slower than strncmp function implemented with
> > vector instructions, see
> >
> > http
On 9/11/20 6:21 AM, Christophe Lyon via Gcc-patches wrote:
> pz_tmp_base and pz_tmp_dot are always set, but used only when
> _PC_NAME_MAX is defined.
>
> This patch moves their declaration and definition undef #ifdef
> _PC_NAME_MAX to avoid this warning.
>
> 2020-09-11 Torbjörn SVENSSON
>
On 9/15/20 8:32 AM, H.J. Lu via Gcc-patches wrote:
> commit e95395926a84a2406faefe0995295d199d595440
> Author: Uros Bizjak
> Date: Thu Jun 18 20:12:48 2020 +0200
>
> i386: Fix mode of ZERO_EXTRACT RTXes, remove ext_register_operand
> predicate.
>
> caused
>
> FAIL: gcc.target/i386/pr78904-
On 9/15/20 9:20 PM, Hongtao Liu via Gcc-patches wrote:
> Hi:
> Rtx cost of sse_to_integer would be used by pass_stv as a
> measurement for the scalar-to-vector transformation. As
> https://gcc.gnu.org/pipermail/gcc-patches/2019-August/528839.html
> indicates, movement between sse regs and gprs s
On 9/7/20 6:13 PM, JonY via Gcc-patches wrote:
> On 9/4/20 12:47 PM, Martin Storsjö wrote:
>> Hi,
>>
>> On Fri, 4 Sep 2020, Jakub Jelinek wrote:
>>
>>> On Tue, Sep 01, 2020 at 04:01:42PM +0300, Martin Storsjö wrote:
This fixes compilation of codepaths for dos-like filesystems
with Clang
On 9/11/20 4:41 PM, Sergei Trofimovich via Gcc-patches wrote:
> From: Sergei Trofimovich
>
> Before the change 'man gcc' rendered "SOURCE_DATE_EPOCH" section as:
> ... the output of @command{date +%s} on GNU/Linux ...
> After the change it renders as:
> ... the output of "date +%s" on GNU
On 9/15/20 11:06 AM, Martin Sebor via Gcc-patches wrote:
> The attached patch updates the manual to mention that Wuninitialized
> and -Wmaybe-uninitialized are issued for both auto and allocated
> objects, as well as for passing pointers to uninitialized objects
> to const-qualified parameters. B
On 9/15/20 1:00 PM, Martin Sebor via Gcc-patches wrote:
> The -Wuninitialized/-Wmaybe-uninitialized enhancement to warn when
> a pointer or reference to an uninitialized object is passed to
> a const-qualified function argument tries to avoid triggering for
> objects of empty types. However, the
On Wed, Sep 16, 2020 at 07:02:06PM -0500, Segher Boessenkool wrote:
> Hi!
>
> On Tue, Sep 15, 2020 at 10:49:44AM +0930, Alan Modra wrote:
> > * config/rs6000/rs6000.c (rs6000_rtx_costs): Cost IOR.
>
> > case IOR:
> > - /* FIXME */
> >*total = COSTS_N_INSNS (1);
> > - re
On 9/15/20 1:47 PM, Martin Sebor wrote:
> Overflowing the size of a dynamic allocation (e.g., malloc or VLA)
> can lead to a subsequent buffer overflow corrupting the heap or
> stack. The attached patch diagnoses a subset of these cases where
> the overflow/wraparound is still detectable.
>
> Bes
Thanks!
On Wed, Sep 16, 2020 at 8:57 PM Uros Bizjak wrote:
>
> > gcc/ChangeLog
> >
> > * common/config/i386/i386-common.c
> > (OPTION_MASK_ISA_AVX_UNSET): Remove OPTION_MASK_ISA_XSAVE_UNSET.
> > (OPTION_MASK_ISA_XSAVE_UNSET): Add OPTION_MASK_ISA_AVX_UNSET.
> >
> > gcc/test
Thanks.
On Wed, Sep 16, 2020 at 8:54 PM Uros Bizjak wrote:
>
> > gcc/ChangeLog
> >
> > PR target/96861
> > * config/i386/x86-tune-costs.h (skylake_cost): increase rtx
> > cost of sse_to_integer from 2 to 6.
> >
> > gcc/testsuite
> >
> > * gcc.target/i386/pr95021-3.
On 9/16/20 6:11 PM, Patrick Palka wrote:
On Wed, 16 Sep 2020, Jason Merrill wrote:
On 9/16/20 1:34 PM, Patrick Palka wrote:
On Thu, 13 Aug 2020, Jason Merrill wrote:
On 8/13/20 11:21 AM, Patrick Palka wrote:
On Mon, 10 Aug 2020, Jason Merrill wrote:
On 8/10/20 2:18 PM, Patrick Palka wrote
On Wed, Sep 16, 2020 at 8:54 AM Alex Coplan wrote:
>
> On 16/09/2020 07:26, Ian Lance Taylor wrote:
> > On Wed, Sep 16, 2020, 4:03 AM Alex Coplan wrote:
> >
> > > Hi Ian,
> > >
> > > On 14/09/2020 14:12, Ian Lance Taylor via Gcc-patches wrote:
> > > > This patch to libbacktrace adds support for M
Hi!
On Tue, Sep 15, 2020 at 10:49:44AM +0930, Alan Modra wrote:
> * config/rs6000/rs6000.c (rs6000_rtx_costs): Cost IOR.
> case IOR:
> - /* FIXME */
>*total = COSTS_N_INSNS (1);
> - return true;
Hey this was okay for over five years :-)
> + left = XEXP (x, 0);
On Tue, Sep 15, 2020 at 10:49:43AM +0930, Alan Modra wrote:
> This small patch to rs6000_rtx_const considerably improves code
(_costs)
> generated for large constants in 64-bit code, teaching gcc that it is
> better to load a constant from memory than to generate a sequence of
> up to five depend
Hi!
This took a while to digest, sorry.
On Tue, Sep 15, 2020 at 10:49:42AM +0930, Alan Modra wrote:
> + 1) Calls from places like optabs.c:avoid_expensive_constant will
> + come here with OUTER_CODE set to an operation such as AND with X
> + being a CONST_INT or other CONSTANT_P type. This
Hi Honza – some input would be really helpful!
Hi Jakub – updated version below.
On 9/16/20 12:36 PM, Jakub Jelinek wrote:
I think you want Honza on this primarily, I'm always lost
in the cgraph alias code.
(Likewise as this thread shows)
+ while (node->alias_target)
+node = symt
Debugging the state explosion of the very large switch statement in
gcc.dg/analyzer/pr96653.c showed that the worklist was failing to
order the exploded nodes correctly; the in-edges at the join point
after the switch were not getting processed together, but were instead
being rocessed in smaller b
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to master as d2c4d5199cf277becc1f377536973815d1c9519c.
gcc/analyzer/ChangeLog:
* engine.cc (supernode_cluster::dump_dot): Show the SCC id
in the per-supernode clusters in FILENAME.eg.dot output.
(exploded
Prior to this patch the analyzer worklist considered only one node or
two nodes at a time, processing and/or merging state individually or
pairwise.
This could lead to explosions of merger nodes at CFG join points,
especially after switch statements, which could have large numbers
of in-edges, and
Avoid some future copy-and-paste by introducing a function.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to master as b9b5fc0c2175b34131d9fd0805b1b307f754f4f0.
gcc/analyzer/ChangeLog:
* engine.cc
(exploded_graph::process_node) :
Simplify by using p
I found this useful when debugging.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to master as 6dd96e24ea3cb9919fedd4da35fbfd36ed98b0ea.
gcc/analyzer/ChangeLog:
* engine.cc (exploded_graph::get_or_create_node): Show the
program point when issuing -Wanalyzer
Seen whilst debugging another issue, where the analyzer was assuming
conservatively that a call to getchar could clobber a global.
This is handled for most of the other stdio functions by the list
in sm-file.cc
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to master as e09
On Wed, 16 Sep 2020, Jason Merrill wrote:
> On 9/16/20 1:34 PM, Patrick Palka wrote:
> > On Thu, 13 Aug 2020, Jason Merrill wrote:
> >
> > > On 8/13/20 11:21 AM, Patrick Palka wrote:
> > > > On Mon, 10 Aug 2020, Jason Merrill wrote:
> > > >
> > > > > On 8/10/20 2:18 PM, Patrick Palka wrote:
> >
This introduces an ICE building the glibc testsuite for alpha (bisected),
s390 and sparc (symptoms appear the same, not bisected to confirm the
exact revision). See bug 97078.
--
Joseph S. Myers
jos...@codesourcery.com
On 9/16/20 1:34 PM, Patrick Palka wrote:
On Thu, 13 Aug 2020, Jason Merrill wrote:
On 8/13/20 11:21 AM, Patrick Palka wrote:
On Mon, 10 Aug 2020, Jason Merrill wrote:
On 8/10/20 2:18 PM, Patrick Palka wrote:
On Mon, 10 Aug 2020, Patrick Palka wrote:
In the below testcase, semantic analysi
Segher and Richard,
Now there are two major concerns from the discussion so far:
1. (From Richard): Inserting zero insns should be done after
pass_thread_prologue_and_epilogue since later passes (for example,
pass_regrename) might introduce new used caller-saved registers.
So, we should
Hi!
On Thu, Sep 10, 2020 at 07:18:01PM +0100, Richard Sandiford wrote:
> It's all a bit unfortunate really. Having different representations
> for shifts inside and outside MEMs is the Second Great RTL Mistake.
Yes... All targets with something that computes shifted addresses (like
in a LEA
On 9/15/20 5:15 PM, Joseph Myers wrote:
On Wed, 9 Sep 2020, Martin Sebor via Gcc-patches wrote:
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552500.html
Aldy provided a bunch of comments on this patch but I'm still looking
for a formal approval.
This patch is OK.
Some testin
On 9/16/20 11:52 AM, Joseph Myers wrote:
> On Wed, 16 Sep 2020, Jeff Law via Gcc-patches wrote:
>
>> ISTM this is a lot like the problem we have where we inline functions
>> with static data. To fix those we use STB_GNU_UNIQUE. But I don't see
>> any code in the C front-end which would utilize
On Wed, Sep 16, 2020 at 03:15:19PM -0400, David Malcolm via Gcc-patches wrote:
> On Wed, 2020-09-16 at 11:16 -0400, Marek Polacek wrote:
> > Here we ICE in char_span::subspan because the offset it gets is -1.
> > It's -1 because get_substring_ranges_for_loc gets a location whose
> > column was 0.
OG10 = devel/omp/gcc-10
e0e1d281472 Fortran: OpenMP - fix simd with (last)private (PR97061)
13ae89bc9c9 Merge remote-tracking branch 'origin/releases/gcc-10' into
devel/omp/gcc-10
5a7ae4f073f [OpenMP] Fix mapping of artificial variables (PR94874)
3a6cb32b2c7 OpenMP/Fortran: Permit impure ELEMENT
Hi!
On Wed, Sep 16, 2020 at 08:37:34PM +0200, Andrea Corallo wrote:
> Segher Boessenkool writes:
>
> > ... and it causes testsuite regressions on Power. We haven't determined
> > et if it actually is worse code, but there are testcases that trip on
> > it. Either way, all patches should be sen
On Wed, 2020-09-16 at 11:16 -0400, Marek Polacek wrote:
> Here we ICE in char_span::subspan because the offset it gets is -1.
> It's -1 because get_substring_ranges_for_loc gets a location whose
> column was 0. That only happens in testcases like the attached where
> we're dealing with extremely l
On 9/15/20 5:02 PM, Joseph Myers wrote:
On Wed, 9 Sep 2020, Martin Sebor via Gcc-patches wrote:
Joseph, do you have any concerns with or comments on the most
recent patch or is it okay as is?
https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552266.html
I'm not yet convinced by the logic
On 9/16/20 12:09 PM, Segher Boessenkool wrote:
On Wed, Sep 16, 2020 at 08:36:35AM -0500, Bill Schmidt wrote:
This is a cleanup requested by Segher in a previous review. Most
uses of rs6000_pcrel_p are called for the current function. A
specialized version for cfun is more efficient for these u
On 9/16/20 12:25 PM, Aldy Hernandez wrote:
>> // Swap min/max if they are out of order. Return TRUE if further
> these seems OK, but can't there be anti-ranges with symbolics too? ie
> ~[a_12, a_12]
> The code for that just does:
>
> else if (src.kind () == VR_ANTI_RANGE)
> set (src.m
Hi,
This adds the PPC architecture variants for Mach-O libbacktrace.
With this (as for X86 and Arm) when dsymutil is run on the binary
we get a basic usable backtrace.
Testsuite results on powerpc-apple-darwin9 are the same as for X86:
* btest fails (TBC why)
* dwarf5 tests fail because dsymu
On Wed, Sep 16, 2020 at 02:38:22PM -0400, Nathan Sidwell wrote:
> On 9/16/20 2:31 PM, Jakub Jelinek wrote:
> > On Wed, Sep 16, 2020 at 02:11:32PM -0400, Nathan Sidwell wrote:
> > > Jakub,
> > > are you ok with the bool return from cp_check_omp_declare_reduction? That
> > > seemed like the least inv
On 9/16/20 2:31 PM, Jakub Jelinek wrote:
On Wed, Sep 16, 2020 at 02:11:32PM -0400, Nathan Sidwell wrote:
Jakub,
are you ok with the bool return from cp_check_omp_declare_reduction? That
seemed like the least invasive change.
This corrects the earlier problems with removing the template header
f
Segher Boessenkool writes:
> ... and it causes testsuite regressions on Power. We haven't determined
> et if it actually is worse code, but there are testcases that trip on
> it. Either way, all patches should be send to gcc-patches@, whether
> pre-approved or not.
>
> Please correct this. Tha
On Wed, Sep 16, 2020 at 02:11:32PM -0400, Nathan Sidwell wrote:
> Jakub,
> are you ok with the bool return from cp_check_omp_declare_reduction? That
> seemed like the least invasive change.
>
> This corrects the earlier problems with removing the template header
> from local omp reductions. And i
On Wed, 16 Sep 2020, Tom de Vries wrote:
> [ cc-ing author omp support for nvptx. ]
The issue looks familiar. I recognized it back in 2017 (and LLVM people
recognized it too for their GPU targets). In an attempt to get agreement
to fix the issue "properly" for GCC I found a similar issue that
... and it causes testsuite regressions on Power. We haven't determined
et if it actually is worse code, but there are testcases that trip on
it. Either way, all patches should be send to gcc-patches@, whether
pre-approved or not.
Please correct this. Thanks!
Segher
Jakub,
are you ok with the bool return from cp_check_omp_declare_reduction?
That seemed like the least invasive change.
This corrects the earlier problems with removing the template header
from local omp reductions. And it uncovered a latent bug. When we
tsubst such a decl, we immediately tsu
On Wed, 16 Sep 2020, Jeff Law via Gcc-patches wrote:
> ISTM this is a lot like the problem we have where we inline functions
> with static data. To fix those we use STB_GNU_UNIQUE. But I don't see
> any code in the C front-end which would utilize STB_GNU_UNIQUE. It's
> support seems limited to
On 9/16/20 11:32 AM, H.J. Lu wrote:
> On Wed, Sep 16, 2020 at 10:24 AM Jeff Law wrote:
>>
>> On 9/16/20 11:13 AM, H.J. Lu wrote:
>>> On Wed, Sep 16, 2020 at 10:10 AM Jeff Law wrote:
On 9/16/20 11:05 AM, H.J. Lu wrote:
> On Wed, Sep 16, 2020 at 9:53 AM Jeff Law via Gcc-patches
> wro
Hello
I have committed this patch to xfail libgomp.oacc-fortran/privatized-ref-2.f90
when the offload target is nvptx, as the generated code has some alloca calls
which are currently not supported by nvptx (PR65181).
Kwok
commit 1245f6f615fa08d2ab4165598c9db72c4dad4467
Author: Kwok Cheung Ye
On Thu, 13 Aug 2020, Jason Merrill wrote:
> On 8/13/20 11:21 AM, Patrick Palka wrote:
> > On Mon, 10 Aug 2020, Jason Merrill wrote:
> >
> > > On 8/10/20 2:18 PM, Patrick Palka wrote:
> > > > On Mon, 10 Aug 2020, Patrick Palka wrote:
> > > >
> > > > > In the below testcase, semantic analysis of t
On Wed, Sep 16, 2020 at 10:24 AM Jeff Law wrote:
>
>
> On 9/16/20 11:13 AM, H.J. Lu wrote:
> > On Wed, Sep 16, 2020 at 10:10 AM Jeff Law wrote:
> >>
> >> On 9/16/20 11:05 AM, H.J. Lu wrote:
> >>> On Wed, Sep 16, 2020 at 9:53 AM Jeff Law via Gcc-patches
> >>> wrote:
> Consider a TU with file
On 9/16/20 11:13 AM, H.J. Lu wrote:
> On Wed, Sep 16, 2020 at 10:10 AM Jeff Law wrote:
>>
>> On 9/16/20 11:05 AM, H.J. Lu wrote:
>>> On Wed, Sep 16, 2020 at 9:53 AM Jeff Law via Gcc-patches
>>> wrote:
Consider a TU with file scoped "static const object utf8_sb_map". A
routine within
On Wed, Sep 16, 2020 at 10:10 AM Jeff Law wrote:
>
>
> On 9/16/20 11:05 AM, H.J. Lu wrote:
> > On Wed, Sep 16, 2020 at 9:53 AM Jeff Law via Gcc-patches
> > wrote:
> >>
> >> Consider a TU with file scoped "static const object utf8_sb_map". A
> >> routine within the TU will stuff &utf8_sb_map int
On Wed, Sep 16, 2020 at 08:36:35AM -0500, Bill Schmidt wrote:
> This is a cleanup requested by Segher in a previous review. Most
> uses of rs6000_pcrel_p are called for the current function. A
> specialized version for cfun is more efficient for these uses.
Then rename that one to rs6000_functio
On 9/16/20 11:05 AM, H.J. Lu wrote:
> On Wed, Sep 16, 2020 at 9:53 AM Jeff Law via Gcc-patches
> wrote:
>>
>> Consider a TU with file scoped "static const object utf8_sb_map". A
>> routine within the TU will stuff &utf8_sb_map into an object, something
>> like:
>>
>> fu (...)
>>
>> {
>>
>> if
Hi Richard,
On 10/09/2020 19:18, Richard Sandiford wrote:
> Alex Coplan writes:
> > Hello,
> >
> > Since r11-2903-g6b3034eaba83935d9f6dfb20d2efbdb34b5b00bf introduced a
> > canonicalization from mult to shift on address reloads, a missing
> > pattern in the AArch64 backend was exposed.
> >
> > In
On Wed, Sep 16, 2020 at 9:53 AM Jeff Law via Gcc-patches
wrote:
>
>
> Consider a TU with file scoped "static const object utf8_sb_map". A
> routine within the TU will stuff &utf8_sb_map into an object, something
> like:
>
> fu (...)
>
> {
>
> if (cond)
>
> dfa->sb_char = utf8_sb_map;
>
>
Consider a TU with file scoped "static const object utf8_sb_map". A
routine within the TU will stuff &utf8_sb_map into an object, something
like:
fu (...)
{
if (cond)
dfa->sb_char = utf8_sb_map;
else
dfa->sb_char = malloc (...);
}
There is another routine in the TU which loo
>> // Swap min/max if they are out of order. Return TRUE if further
> these seems OK, but can't there be anti-ranges with symbolics too? ie
> ~[a_12, a_12]
> The code for that just does:
>
> else if (src.kind () == VR_ANTI_RANGE)
> set (src.min (), src.max (), VR_ANTI_RANGE);
>
> That
Hi all,
This patch enables SIMD modes for MVE auto-vectorization.
In this patch, the integer and float MVE SIMD modes are returned by
arm_preferred_simd_mode (TARGET_VECTORIZE_PREFERRED_SIMD_MODE hook) when
MVE or MVE_FLOAT is enabled.
Then the expanders for auto-vectorization can be used for ge
On 9/16/20 1:24 PM, Alexander Monakov wrote:
> Can you supply a tar with tree dumps for me to look at please?
>
Hi Alexander,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95654#c6 .
> Also, if you can check if the problem can be triggered without a
> collapsed loop (e.g. try removing collapse(2
On 16/09/2020 07:26, Ian Lance Taylor wrote:
> On Wed, Sep 16, 2020, 4:03 AM Alex Coplan wrote:
>
> > Hi Ian,
> >
> > On 14/09/2020 14:12, Ian Lance Taylor via Gcc-patches wrote:
> > > This patch to libbacktrace adds support for MiniDebugInfo, as
> > > requested in PR 93608.
> >
> > This appears
Thanks Christophe for reporting the errors.
On 9/16/20, 7:45 AM, "Kyrylo Tkachov" wrote:
> > The new tests vld1x3 and vld1x4 fail on arm, I am seeing new failures
> > on gcc-8 and gcc-9 branches
> > after r8-10451, r8-10452 and r9-8874.
> > Is that expected/fixed later in the backport series?
> >
Here we ICE in char_span::subspan because the offset it gets is -1.
It's -1 because get_substring_ranges_for_loc gets a location whose
column was 0. That only happens in testcases like the attached where
we're dealing with extremely long lines (at least 4065 chars it seems).
This does happen in pr
On Wed, Sep 16, 2020 at 7:46 AM Richard Sandiford
wrote:
>
> "H.J. Lu" writes:
> > On Tue, Sep 15, 2020 at 7:44 AM Richard Sandiford
> > wrote:
> >>
> >> Thanks for looking at this.
> >>
> >> "H.J. Lu" writes:
> >> > commit 1bcb4c4faa4bd6b1c917c75b100d618faf9e628c
> >> > Author: Richard Sandifo
instantiate_body has a local var call 'nested', which indicates that
this instantiation was caused during the body of some function -- not
necessarily its containing scope. That's confusing, let's just use
'current_function_decl' directly. Then we can also simplify the
push_to_top_level logic,
"H.J. Lu" writes:
> On Tue, Sep 15, 2020 at 7:44 AM Richard Sandiford
> wrote:
>>
>> Thanks for looking at this.
>>
>> "H.J. Lu" writes:
>> > commit 1bcb4c4faa4bd6b1c917c75b100d618faf9e628c
>> > Author: Richard Sandiford
>> > Date: Wed Oct 2 07:37:10 2019 +
>> >
>> > [LRA] Don't make
On Wed, Sep 16, 2020, 4:03 AM Alex Coplan wrote:
> Hi Ian,
>
> On 14/09/2020 14:12, Ian Lance Taylor via Gcc-patches wrote:
> > This patch to libbacktrace adds support for MiniDebugInfo, as
> > requested in PR 93608.
>
> This appears to introduce a failure in the libbacktrace testsuite
> (observe
This refactors instantiate_decl, breaking out the actual instantiation
work to instantiate_body. That'll allow me to address the OMP UDR
issue, but it also means we have slightly neater code in
instantiate_decl anyway.
gcc/cp/
* pt.c (instantiate_body): New, broken out o
Ping this patch set.
Thanks,
Chung-Lin
On 2020/9/1 9:16 PM, Chung-Lin Tang wrote:
Hi Jakub,
this patch set implements parts of the target mapping changes introduced
in OpenMP 5.0, mainly the attachment requirements for pointer-based
list items, and the clause ordering.
The first patch here are
On Wed, Sep 16, 2020 at 04:08:16PM +0200, Tobias Burnus wrote:
> Using linear (added by the compiler) + explicit lastprivate gives an error.
>
> To quote Jakub from the PR:
> "If it is the FE that adds the linear clause, then it
> shouldn't when there is explicit lastprivate clause.
> This is a ne
Using linear (added by the compiler) + explicit lastprivate gives an error.
To quote Jakub from the PR:
"If it is the FE that adds the linear clause, then it
shouldn't when there is explicit lastprivate clause.
This is a new thing in OpenMP 5.0, in 4.5 it was invalid to
make the iterate anything
Hi Jakub,
this patch implements automatically adding map(tofrom: this[:1]) to omp target
regions inside non-static member functions, as specified in OpenMP 5.0.
This patch factors away some parts of cp_parser_omp_target, into a new
finish_omp_target function, and implements the new clause adding
This removes the canonicalization of X + -CST to X - CST to facilitate
SLP vectorization analysis where we currently treat the added testcase
as two-operation plus blend vectorization opportunity. While there
may be the possibility to avoid this in the vectorizer itself the
canonicalization is som
Richard Sandiford writes:
> OK with two incredibly petty comments fixed:
[...]
Installed with the two suggestions as 052204fac58.
Thanks for reviewing!
Andrea
On Tue, Sep 15, 2020 at 7:44 AM Richard Sandiford
wrote:
>
> Thanks for looking at this.
>
> "H.J. Lu" writes:
> > commit 1bcb4c4faa4bd6b1c917c75b100d618faf9e628c
> > Author: Richard Sandiford
> > Date: Wed Oct 2 07:37:10 2019 +
> >
> > [LRA] Don't make eliminable registers live (PR919
This is a cleanup requested by Segher in a previous review. Most
uses of rs6000_pcrel_p are called for the current function. A
specialized version for cfun is more efficient for these uses.
(Actually all uses are called for the current function, so now
rs6000_pcrel_p is an orphan. However, I th
On Wed, Sep 16, 2020 at 02:33:03PM +0200, Mark Wielaard wrote:
> > 2020-09-15 Jakub Jelinek
> >
> > * configure.ac (HAVE_AS_GDWARF_5_DEBUG_FLAG,
> > HAVE_AS_WORKING_DWARF_4_FLAG): New tests.
> > * gcc.c (ASM_DEBUG_DWARF_OPTION): Define.
> > (ASM_DEBUG_SPEC): Use ASM_DEBUG_DWARF_
On 9/16/20 5:32 AM, Segher Boessenkool wrote:
On Tue, Sep 15, 2020 at 08:38:42PM -0500, Bill Schmidt wrote:
The description in rs6000-builtin.def provides for a builtin named
__builtin_altivec_xst_len_r. However, it is hand-defined in
altivec_init_builtins as __builtin_xst_len_r, against the us
For platforms like Mingw and Cygwin, cygwin refuses to generate the
shared library without using -no-undefined.
Attached patch makes sure the right flags are used, since libtool is
already used to link libstdc++.
Patch OK?
From 4ba039687182fccd67e1170f89e259e1c4a58eeb Mon Sep 17 00:00:00 2001
Fro
> gcc/ChangeLog
>
> * common/config/i386/i386-common.c
> (OPTION_MASK_ISA_AVX_UNSET): Remove OPTION_MASK_ISA_XSAVE_UNSET.
> (OPTION_MASK_ISA_XSAVE_UNSET): Add OPTION_MASK_ISA_AVX_UNSET.
>
> gcc/testsuite/ChangeLog
>
> * gcc.target/i386/xsave-avx-1.c: New test.
OK fo
> gcc/ChangeLog
>
> PR target/96861
> * config/i386/x86-tune-costs.h (skylake_cost): increase rtx
> cost of sse_to_integer from 2 to 6.
>
> gcc/testsuite
>
> * gcc.target/i386/pr95021-3.c: Add -mtune=generic.
OK.
Thanks,
Uros.
> -Original Message-
> From: Christophe Lyon
> Sent: 16 September 2020 13:43
> To: Pop, Sebastian
> Cc: Kyrylo Tkachov ; gcc-patches@gcc.gnu.org
> Subject: Re: [aarch64] Backport missing NEON intrinsics to GCC8
>
> On Wed, 16 Sep 2020 at 07:21, Pop, Sebastian via Gcc-patches
> wrote:
On Wed, 16 Sep 2020 at 07:21, Pop, Sebastian via Gcc-patches
wrote:
>
> Thanks Kyrill for your review.
>
> I committed the patches to the gcc-8 branch:
> https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=2c55e6caa9432b2c1f081cb3aeddd36abec03233
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=a4004
Hi,
On Tue, 2020-09-15 at 20:40 +0200, Jakub Jelinek wrote:
> Ok, here it is in patch form.
> I've briefly tested it, with the older binutils I have around (no --gdwarf-N
> support), with latest gas (--gdwarf-N that can be passed to as even when
> compiling C/C++ etc. code and emitting .debug_line
On Tue, Sep 15, 2020 at 2:28 PM bin.cheng via Gcc-patches
wrote:
>
> Hi,
> As suggested by PR93334 comments, this patch adds an interface identifying
> output dependence which can be skipped in terms of reordering and skip it in
> loop distribution. It also adds a new test case. Any comment?
Lo
On Wed, Sep 16, 2020 at 10:54 AM Feng Xue OS via Gcc-patches
wrote:
>
> With the new pattern rule (T)(A) +- (T)(B) -> (T)(A +- B),
> some testcases are simplified and could not keep expected
> code pattern as test-check. Minor changes are made to those
> cases to avoid simplification effect of the
On 9/13/20 3:37 PM, JonY wrote:
> On 9/10/20 2:23 PM, JonY wrote:
>> Do a link test instead of just a grep. The linker can
>> support multiple targets, but not all targets can use it.
>>
>> Cygwin/MinGW ld can support ELF but the PE format for Windows itself
>> does not support such a feature. Atta
On 03.09.20 08:39, Ilya Leoshkevich wrote:
> Bootstrapped (with BOOT_CFLAGS='-g -O2 -Wno-error=maybe-uninitialized')
> and regtested on s390x-redhat-linux. Ok for master?
>
>
>
> Certain alternatives of *vec_tf_to_v1tf use "v" constraint for its
> TFmode source operand. Therefore it is assigned
On Wed, Sep 16, 2020 at 08:00:01AM -0400, Nathan Sidwell wrote:
> is libgomp/testsuite/libgomp.c++/udr-3.C well formed?
>
> Specifically V::baz?
>
> If you remove the templatedness and plug in typedefs for T & D on its only
> instantiation (as the attached does), you get the following errors:
>
Jakub,
is libgomp/testsuite/libgomp.c++/udr-3.C well formed?
Specifically V::baz?
If you remove the templatedness and plug in typedefs for T & D on its
only instantiation (as the attached does), you get the following errors:
devvm293:414>g++ -std=c++11 -c -fopenmp udr-3.C
udr-3.C: In member f
On Wed, Sep 16, 2020 at 12:34:50PM +0100, Richard Sandiford wrote:
> Jakub Jelinek via Gcc-patches writes:
> > On Mon, Sep 14, 2020 at 08:57:18AM -0700, H.J. Lu via Gcc-patches wrote:
> >> Something like this for GCC 8 and 9.
> >
> > Guess my preference would be to do this everywhere and then let'
gcc/ChangeLog:
* config/csky/csky.opt (msim): New.
* doc/invoke.texi (C-SKY Options): Document -msim.
* config/csky/csky-elf.h (LIB_SPEC): Add simulator runtime.
---
gcc/config/csky/csky-elf.h | 10 --
gcc/config/csky/csky.opt | 4
gcc/doc/invoke.texi
Andrea Corallo writes:
> @@ -2034,6 +2034,16 @@ aarch64_expand_fpsr_fpcr_setter (int unspec,
> machine_mode mode, tree exp)
>emit_insn (gen_aarch64_set (unspec, mode, op));
> }
>
> +/* Expand a fpsr or fpcr getter (depending on UNSPEC) using MODE.
> + Return the target. */
> +static rtx
All of the three pathes have been pushed to trunk.
Thanks,
Cooper
On 9/16/20 6:34 PM, Jojo R wrote:
gcc/testsuite/ChangeLog:
* lib/target-supports.exp (check_profiling_available): Refine name of
elf target.
---
gcc/testsuite/lib/target-supports.exp | 2 +-
1 file changed, 1 ins
Jakub Jelinek via Gcc-patches writes:
> On Mon, Sep 14, 2020 at 08:57:18AM -0700, H.J. Lu via Gcc-patches wrote:
>> Something like this for GCC 8 and 9.
>
> Guess my preference would be to do this everywhere and then let's discuss if
> we change the warning into error there or keep it being deprec
Can you supply a tar with tree dumps for me to look at please?
Also, if you can check if the problem can be triggered without a
collapsed loop (e.g. try removing collapse(2), remove mentions of
d2) and if so supply dumps from that instead, I'd appreciate that too.
Alexander
On Wed, 16 Sep 2020,
1 - 100 of 130 matches
Mail list logo
