Ping patch
| Subject: [PATCH, V2] Add conversions between _Float128 and Decimal.
| Message-ID: <20210209073505.ga11...@ibm-toto.the-meissners.org>
https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565009.html
I was asked to resubmit the patch with the copyright dates fixed, and Will's
David,
Two items I needs answered to get you the patch.
1) The get_field_at_bit_offset function is static in region.cc, so I cannot use
it outside of the file (you want me to use it in store.cc) without updating
that definition to extern. I am assuming you want this.
2) I am updating my
-Warray-bounds makes a couple of assumptions about arrays that hold
neither for VLAs of zero-length arrays nor for zero-length arrays
of VLAs. The attached patch removes these assumptions and simplifies
the code that deals with them in the process.
This resolves a P2 GCC 9-11 regression so I'm
My change in r10-7718 to make build_aggr_init_expr set EXPR_LOCATION
(mimicking build_target_expr) causes the debuginfo regression PR96997.
Given that this change is mostly independent of the rest of the commit,
and that the only fallout of reverting it is a less accurate error
message location in
Hi all,
Attached patch adds to checks. In the case of IMPLICIT typing it checks
to see if the objects listed in the NAMELIST have defined types andf if
not, sets them to the default implicit types.
In the case of IMPLICIT NONE, the types are required be declared before
the NAMELIST. If
On Thu, Jan 21, 2021 at 2:25 AM Levy wrote:
> Added implementation for builtin overflow detection, new patterns are
> listed below.
>
For rv32 SImode and rv64 DImode, the unsigned add/sub and signed/unsigned
mul patterns seem to give the same result as the default code generation.
That has me
Hello,
What’s the status of this patch now? Is there any major technical issue with
the patch?
Our company has been waiting for this patch for almost one year, we need it for
our important application.
Could this one be approved and committed to gcc11?
Thanks.
Qing
> On Feb 5, 2021, at
This patch to the Go frontend unaliases the receiver type when
outputting export data for a method. This avoids a crash when
importing such a package. The test case for this is
https://golang.org/cl/292009. Bootstrapped and ran Go testsuite on
x86_64-pc-linux-gnu. Committed to mainline.
Ian
On February 16, 2021 7:32:16 PM GMT+01:00, "Martin Liška"
wrote:
>Hello.
>
>As Honza noticed, when using GCC 11 during train run of Clang leads to
>very slow training run. Apparently, it's caused by a corrupted TOP N
>profile.
>The patch fixed that by preallocating a buffer that is latter stream
We make sure files end in \n by placing one at the limit of the buffer
(just past the end of what is read). We need to do the same for buffers
generated via include-translation. Fortunately they have space.
libcpp/
* files.c (_cpp_stack_file): Make buffers end in unread \n.
On Tue, Feb 16, 2021 at 8:45 AM Jakub Jelinek wrote:
>
> On Mon, Feb 15, 2021 at 02:35:07PM -0800, H.J. Lu via Gcc-patches wrote:
> > When building Linux kernel, ld in bninutils 2.36 with GCC 11 generates
> > thousands of
> >
> > ld: warning: orphan section `.data.event_initcall_finish' from
> >
On Tue, 16 Feb 2021, Jeff Law via Gcc-patches wrote:
> I think this will be OK once the wording in patch 2/3 of this series is
> fixed.
As I noted with 2/3 I would like to know what this extra complication is
exactly needed for, and then whether we can't reuse the existing options.
Once
On Tue, 16 Feb 2021, Jeff Law via Gcc-patches wrote:
> > diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
> > index 4c38244ae58..6b9520569ba 100644
> > --- a/gcc/doc/install.texi
> > +++ b/gcc/doc/install.texi
> > @@ -1464,6 +1464,29 @@ systems that support conditional traps).
> >
On 2/5/21 2:53 AM, YunQiang Su wrote:
> For MIPSr6, we may wish to use compact-branches only.
> Currently, we have to use `always' option, while it is mark as conflict
> with pre-R6.
> cc1: error: unsupported combination: ‘mips32r2’ -mcompact-branches=always
>
> It make some trouble for
On 2/14/21 6:33 PM, YunQiang Su wrote:
> It is found by ada s-pack96.adb ftbfs, due to 96bit load: 96 = 64 + 32.
> While the 32bit pair of l r is mark as SUBREG, so they are
> not in SImode, make it fail to find suitable insn.
>
> gcc/ChangeLog:
>
>* config/mips/mips.c
On 2/16/21 12:04 PM, Martin Sebor via Gcc-patches wrote:
> On 2/10/21 5:24 PM, Marek Polacek via Gcc-patches wrote:
>> On Wed, Feb 10, 2021 at 03:54:52PM -0700, Martin Sebor via
>> Gcc-patches wrote:
>>> On 2/10/21 3:33 PM, Marek Polacek wrote:
We ICE in handle_assume_aligned_attribute
On 2/10/21 5:24 PM, Marek Polacek via Gcc-patches wrote:
On Wed, Feb 10, 2021 at 03:54:52PM -0700, Martin Sebor via Gcc-patches wrote:
On 2/10/21 3:33 PM, Marek Polacek wrote:
We ICE in handle_assume_aligned_attribute since r271338 which added
@@ -2935,8 +2936,8 @@
On 2/16/21 12:30 AM, Jeff Law wrote:
Given this is "just" a missed optimization, are we deferring to gcc-12?
Yes.
Thanks,
Martin
On 2/13/21 7:32 PM, Mike Frysinger via Gcc-patches wrote:
> Move custom macros to acinclude.m4 so we can autogenerate aclocal.m4
> with aclocal. This matches every other project in the tree.
>
> libiberty/ChangeLog:
>
> * Makefile.in (ACLOCAL, ACLOCAL_AMFLAGS, $(srcdir)/aclocal.m4):
On 2/11/21 10:18 PM, Jason Merrill via Gcc-patches wrote:
> The patch for PR92372 made us start warning about a flatten attribute on an
> alias. But in the case of C++ 'tor base/complete variants, the user didn't
> create the alias, so we shouldn't warn.
>
> I could also remove the attribute
On 2/5/21 2:53 AM, YunQiang Su wrote:
> For R6+, it allows to configure gcc to use compact branches only.
> ---
> gcc/config.gcc | 18 +-
> gcc/doc/install.texi | 23 +++
> 2 files changed, 40 insertions(+), 1 deletion(-)
>
> diff --git
On 2/5/21 2:53 AM, YunQiang Su wrote:
> GCC may be configured to use PIC by default, then the test with
> -mno-abicall may fail. Just add -fno-PIC option for it.
THanks. Installed on the trunk.
jeff
Hello.
As Honza noticed, when using GCC 11 during train run of Clang leads to
very slow training run. Apparently, it's caused by a corrupted TOP N profile.
The patch fixed that by preallocating a buffer that is latter stream out.
With the patch, I can profiledbootstrap GCC and the instrumented
Hi!
Tom, ping?
Also, I have now pushed to devel/omp/gcc-10 branch cherry-picks of Tom's
"[nvptx] Set -misa=sm_35 by default" in commit
d4b73f42df11282c7c170b55eb29cd8ff6b998d8, and Tobias' "nvptx -
invoke.texi: Update default of -misa" in commit
c77b42af4fa245ea87aee0ad55fa2b76611afb47, see
On Mon, Feb 15, 2021 at 02:35:07PM -0800, H.J. Lu via Gcc-patches wrote:
> When building Linux kernel, ld in bninutils 2.36 with GCC 11 generates
> thousands of
>
> ld: warning: orphan section `.data.event_initcall_finish' from `init/main.o'
> being placed in section
> "Martin" == Martin Sebor via Gcc-patches writes:
Martin> FWIW, I have prototyped
Martin> a simple string class over the weekend (based on auto_vec) that I'm
Martin> willing to contribute if std::string turns out to be out of favor.
I wonder whether GDB and GCC can or should collaborate in
On 2/15/21 7:39 AM, Richard Biener wrote:
On Mon, Feb 15, 2021 at 2:46 PM Martin Liška wrote:
On 2/12/21 5:56 PM, Martin Sebor wrote:
On 2/12/21 2:09 AM, Richard Biener via Gcc-patches wrote:
On Thu, Feb 11, 2021 at 6:41 PM Martin Liška wrote:
Hello.
This fixes 2 memory leaks I noticed.
Hi Tobias,
I think that constitutes an 'obvious' patch. OK for mainline.
Thanks
Paul
On Mon, 8 Feb 2021 at 18:53, Tobias Burnus wrote:
> Found when looking at Julian's 3/4 OpenACC patch, which has not
> yet been committed (and needs still to be revised a bit.)
>
> The fix (a) avoids an ICE
FYI - I reverted this patch:
commit ea43db9372133e84f95bdb2c6934a5cc3db3d530
Author: Catherine Moore
Date: Sat Feb 13 09:04:44 2021 -0800
Revert "Enable gimplify GOMP_MAP_STRUCT handling of (COMPONENT_REF
(INDIRECT_REF ...)) map clauses."
This reverts commit
Hi all,
This patch introduces an internal tune flag to break up VL-based scalar ops
into a GP-reg scalar op with the VL read kept separate. This can be preferable
on some CPUs.
I went for a tune param rather than extending the rtx costs as our RTX costs
tables aren't set up to track
this
Jakub Jelinek writes:
> On Tue, Feb 16, 2021 at 01:09:43PM +, Richard Sandiford wrote:
>> Can I put in a plea to put this in recog.[hc], and possibly also make
>> it a copy constructor for recog_data_d? I can't think of any legitimate
>> cases in which we'd want to copy the whole structure,
On Tue, Feb 16, 2021 at 01:09:43PM +, Richard Sandiford wrote:
> Can I put in a plea to put this in recog.[hc], and possibly also make
> it a copy constructor for recog_data_d? I can't think of any legitimate
> cases in which we'd want to copy the whole structure, instead of just
> the active
*PING*
this avoids an ICE in gfc_is_simplify_contiguous, which can be at least
triggered with OpenMP/OpenACC.
For %re/%im it outputs a nicer error than an ICE or misleading message.
[Whether %re may be used is still unclear, recently opened OpenMP +
OpenACC spec issues still have to be
On Tue, Feb 16, 2021 at 1:53 PM Jakub Jelinek wrote:
>
> On Tue, Feb 16, 2021 at 12:39:39PM +0100, Uros Bizjak wrote:
> > > @@ -5197,7 +5209,7 @@ (define_insn_and_split "*lea"
> > >
> > >/* ix86_avoid_lea_for_addr re-recognizes insn and may
> > > change operands[] array behind our back.
Jakub Jelinek via Gcc-patches writes:
> @@ -14897,6 +14892,32 @@ distance_agu_use (unsigned int regno0, r
>return distance >> 1;
> }
>
> +/* Copy recog_data_d from SRC to DEST. */
> +
> +static void
> +copy_recog_data (recog_data_d *dest, recog_data_d *src)
> +{
> + dest->n_operands =
On Tue, Feb 16, 2021 at 12:39:39PM +0100, Uros Bizjak wrote:
> > @@ -5197,7 +5209,7 @@ (define_insn_and_split "*lea"
> >
> >/* ix86_avoid_lea_for_addr re-recognizes insn and may
> > change operands[] array behind our back. */
> > - pat = PATTERN (curr_insn);
> > + pat = PATTERN
This improves a previous heuristic to sort address-taken variables
first (because those appear in points-to bitmaps) by tracking which
variables appear in ADDRESSOF constraints (there's also
graph->address_taken but that's computed only later).
This shaves off 30s worth of compile-time for the
On Tue, Feb 16, 2021 at 11:48 AM Alexandre Oliva wrote:
>
> On Feb 16, 2021, Alexandre Oliva wrote:
>
> >> So I wonder whether we should instead re-run CCP after loop opts which
> >> computes nonzero bits as well instead of the above "hack".
>
> That works. It takes care of both the dest
Hi Tobias,
The fix and the message are just fine for me. I am trying to imagine how
few people will ever encounter this!
OK for 10- and 11-branches
Thanks
Paul
On Tue, 16 Feb 2021 at 11:28, Tobias Burnus wrote:
> GCC started to accept as legacy extension array-valued
> non-characters,
On Tue, Feb 16, 2021 at 12:05 PM Jakub Jelinek wrote:
>
> On Tue, Feb 16, 2021 at 11:47:51AM +0100, Uros Bizjak wrote:
> > > In this case the match_scratch wouldn't work, since CC_REGNUM is fixed.
> > > But as you said on irc, there's peep2_regno_dead_p instead.
> > >
> > > Haven't tried it and
GCC started to accept as legacy extension array-valued
non-characters, which works for integer (+ real/logical).
Some other – mostly unrelated patch regarding resolving
array constructors (r10-5607-gde89b5748d68b76b, PR92996)
turned this into an ICE.
While it might be in theory fixable for
On Tue, Feb 16, 2021 at 11:47:51AM +0100, Uros Bizjak wrote:
> > In this case the match_scratch wouldn't work, since CC_REGNUM is fixed.
> > But as you said on irc, there's peep2_regno_dead_p instead.
> >
> > Haven't tried it and so don't know whether it would work with only
> > one construct in
> From: Bernd Edlinger
> Date: Tue, 16 Feb 2021 08:35:04 +0100
> Oops,
>
> thanks for fixing this problem.
>
> To my excuse I would like to note,
> that the script error does not happen on x86_64-pc-linux-gnu,
> probably it would only happen when a file is left over.
Sorry but that just
On Tue, Feb 16, 2021 at 11:28 AM Richard Sandiford
wrote:
>
> Jakub Jelinek via Gcc-patches writes:
> > On Tue, Feb 16, 2021 at 09:55:40AM +, Richard Sandiford wrote:
> >> I assume that's because pass_df_initialize_no_opt is slightly after
> >> the first pass_split_all_insns? Seems like it
On Feb 16, 2021, Alexandre Oliva wrote:
>> So I wonder whether we should instead re-run CCP after loop opts which
>> computes nonzero bits as well instead of the above "hack".
That works. It takes care of both the dest alignment and the len ctz.
Explicitly masking out the len tz from nonzero
Jakub Jelinek via Gcc-patches writes:
> On Tue, Feb 16, 2021 at 09:55:40AM +, Richard Sandiford wrote:
>> I assume that's because pass_df_initialize_no_opt is slightly after
>> the first pass_split_all_insns? Seems like it should just be a case
>> of moving it up.
>>
>> > And for noflow
On Tue, Feb 16, 2021 at 09:55:40AM +, Richard Sandiford wrote:
> I assume that's because pass_df_initialize_no_opt is slightly after
> the first pass_split_all_insns? Seems like it should just be a case
> of moving it up.
>
> > And for noflow where the cfg doesn't really exit I wouldn't even
On 12.02.21 16:46, Julian Brown wrote:
This patch disallows selecting components of array sections in update
directives for OpenACC, as specified in OpenACC 3.0, "2.14.4. Update
Directive", "Restrictions":
"In Fortran, members of variables of derived type may appear, including
a subarray
On 12.02.21 16:46, Julian Brown wrote:
This patch fixes lowering of derived-type mappings which select elements
of arrays of derived types, and similar. These would previously lead
to ICEs.
With this change, OpenACC directives can pass through constructs that
are no longer recognized by the
Jakub Jelinek writes:
> On Tue, Feb 16, 2021 at 09:16:40AM +, Richard Sandiford wrote:
>> But doing it on demand like this seems fragile. And the targets aren't
>> a fixed… target. I think we need to design the interface so that things
>> are unlikely to go wrong in future rather than
On Tue, Feb 16, 2021 at 09:16:40AM +, Richard Sandiford wrote:
> But doing it on demand like this seems fragile. And the targets aren't
> a fixed… target. I think we need to design the interface so that things
> are unlikely to go wrong in future rather than design it on the basis
> that
Jakub Jelinek writes:
> On Tue, Feb 16, 2021 at 09:42:22AM +0100, Richard Biener wrote:
>> Just to get an idea whether it's worth doing the extra df_analyze.
>> Since we have possibly 5 split passes it's a lot of churn for things
>> like that WRF ltrans unit that already spends 40% of its time in
On Tue, Feb 16, 2021 at 08:56:13AM +, Richard Sandiford wrote:
> Yeah, but the updates are incremental. I think in many cases we'll
df_analyze e.g. computes postorder, so it has some costs even if everything
is really up to date.
Jakub
On Tue, Feb 16, 2021 at 09:42:22AM +0100, Richard Biener wrote:
> Just to get an idea whether it's worth doing the extra df_analyze.
> Since we have possibly 5 split passes it's a lot of churn for things
> like that WRF ltrans unit that already spends 40% of its time in DF ...
Yeah, df_analyze
Richard Biener writes:
> On Tue, 16 Feb 2021, Richard Sandiford wrote:
>
>> Jakub Jelinek via Gcc-patches writes:
>> > Hi!
>> >
>> > The following testcase started ICEing with my recent changes to enable
>> > split4 after sel-sched, but it seems the bug is more general.
>> > Some of the i386
On Tue, 16 Feb 2021, Richard Sandiford wrote:
> Jakub Jelinek via Gcc-patches writes:
> > Hi!
> >
> > The following testcase started ICEing with my recent changes to enable
> > split4 after sel-sched, but it seems the bug is more general.
> > Some of the i386 splitter condition functions use and
Jakub Jelinek via Gcc-patches writes:
> Hi!
>
> The following testcase started ICEing with my recent changes to enable
> split4 after sel-sched, but it seems the bug is more general.
> Some of the i386 splitter condition functions use and rely on df, but
> the split passes don't really
Hi!
fixup_partitions sometimes changes some basic blocks from hot partition to
cold partition, in particular if after unreachable block removal or other
optimizations a hot partition block is dominated by cold partition block(s).
It fixes up the edges and jumps on those edges, but when after
Hi!
The following testcase started ICEing with my recent changes to enable
split4 after sel-sched, but it seems the bug is more general.
Some of the i386 splitter condition functions use and rely on df, but
the split passes don't really df_analyze/df_finish_pass, so the DF info
may be stale or
Hi!
As mentioned in the PR, ix86_simd_clone_usable didn't make it more desirable
to use 'e' mangled AVX512F entrypoints over 'd' mangled ones (AVX2) with the
same simdlen. This patch fixes that. I have tweaked the generic code too
to make more room for these target specific badness factors.
60 matches
Mail list logo
