On 6/24/21 12:42 AM, Ilya Leoshkevich wrote:
> Bootstrapped and regtested on s390x-redhat-linux. Ok for master?
>
> v1: https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573348.html
> v1 -> v2: Use ATTRIBUTE_UNUSED, compact op[] array (Andreas).
> I've also noticed that one of the
On 6/23/2021 1:47 PM, Martin Sebor via Gcc-patches wrote:
On 6/22/21 5:28 PM, David Malcolm wrote:
On Tue, 2021-06-22 at 19:18 -0400, David Malcolm wrote:
On Fri, 2021-06-04 at 15:41 -0600, Martin Sebor wrote:
The attached patch introduces the suppress_warning(),
warning_suppressed(), and
On 6/4/2021 3:43 PM, Martin Sebor via Gcc-patches wrote:
The attached patch introduces declarations of the new
suppress_warning(), warning_suppressed_p(), and copy_warning() APIs,
and replaces the uses of TREE_NO_WARNING in the middle end with them.
gcc-no-warning-middle-end.diff
Add
On 6/4/2021 3:42 PM, Martin Sebor via Gcc-patches wrote:
The attached patch replaces the uses of TREE_NO_WARNING in the C++
front end with the new suppress_warning(), warning_suppressed_p(),
and copy_warning() APIs.
gcc-no-warning-cp.diff
Add support for per-location warning groups.
On 6/4/2021 3:41 PM, Martin Sebor via Gcc-patches wrote:
The attached patch replaces the uses of TREE_NO_WARNING in the C front
end with the new suppress_warning(), warning_suppressed_p(), and
copy_warning() APIs.
gcc-no-warning-c.diff
Add support for per-location warning groups.
On 6/4/2021 3:41 PM, Martin Sebor via Gcc-patches wrote:
The attached patch replaces the uses of TREE_NO_WARNING in the Ada front
end with the new suppress_warning(), warning_suppressed_p(), and
copy_warning() APIs.
gcc-no-warning-ada.diff
Add support for per-location warning groups.
On 6/4/2021 3:42 PM, Martin Sebor via Gcc-patches wrote:
The attached patch replaces the uses of TREE_NO_WARNING in the shared
C family front end with the new suppress_warning(),
warning_suppressed_p(), and copy_warning() APIs.
gcc-no-warning-c-family.diff
Add support for per-location
On 6/4/2021 3:42 PM, Martin Sebor via Gcc-patches wrote:
The attached patch replaces the uses of TREE_NO_WARNING in the RL78
back end with the new suppress_warning() and warning_suppressed_p()
APIs.
gcc-no-warning-rl78.diff
Add support for per-location warning groups.
gcc/ChangeLog:
On 6/4/2021 3:42 PM, Martin Sebor via Gcc-patches wrote:
The attached patch replaces the uses of TREE_NO_WARNING in the FORTRAN
front end with the new suppress_warning() API.
gcc-no-warning-fortran.diff
Add support for per-location warning groups.
gcc/fortran/ChangeLog:
*
On 6/4/2021 3:42 PM, Martin Sebor via Gcc-patches wrote:
The attached patch replaces the uses of TREE_NO_WARNING in libcc1 with
the new suppress_warning() API.
gcc-no-warning-libcc1.diff
Add support for per-location warning groups.
libcc1/ChangeLog:
* libcp1plugin.cc
On 6/4/2021 3:43 PM, Martin Sebor via Gcc-patches wrote:
The attached patch replaces the uses of TREE_NO_WARNING in the LTO
front end with the new suppress_warning() API. It adds a couple of
FIXMEs that I plan to take care of in a follow up.
gcc-no-warning-lto.diff
Add support for
On 6/4/2021 3:43 PM, Martin Sebor via Gcc-patches wrote:
The attached patch replaces the uses of TREE_NO_WARNING in
the Objective-C front end with the new suppress_warning(),
warning_suppressed_p(), and copy_warning() APIs.
gcc-no-warning-objc.diff
Add support for per-location warning
On 6/4/2021 3:43 PM, Martin Sebor via Gcc-patches wrote:
The attached patch removes the definitions of the TREE_NO_WARNING macro
and the gimple_get_no_warning_p() and gimple_set_no_warning() functions.
gcc-no-warning-remove-api.diff
Remove legacy TREE_NO_WARNING amd gimple_*no_warning*
On Wed, Jun 23, 2021 at 5:08 PM Richard Biener
wrote:
>
> On Wed, Jun 23, 2021 at 10:01 AM Jakub Jelinek wrote:
> >
> > On Wed, Jun 23, 2021 at 09:53:27AM +0200, Richard Biener via Gcc-patches
> > wrote:
> > > On Wed, Jun 23, 2021 at 9:19 AM Hongtao Liu via Gcc-patches
> > > wrote:
> > > >
> >
On 6/4/2021 3:43 PM, Martin Sebor via Gcc-patches wrote:
The attached patch adds regression tests for two closely related bugs
resolved by the patch series.
gcc-no-warning-tests.diff
Regression tests for TREE_NO_WARNING enhancement to warning groups.
PR middle-end/74765 - missing
On Wed, Jun 23, 2021 at 5:55 PM Uros Bizjak wrote:
>
> On Wed, Jun 23, 2021 at 11:41 AM Uros Bizjak wrote:
> >
> > On Wed, Jun 23, 2021 at 11:32 AM Hongtao Liu wrote:
> >
> > > > > > > > Also when allocano cost of GENERAL_REGS is same as MASK_REGS,
> > > > > > > > allocate
> > > > > > > >
Hi!
On Thu, Jun 17, 2021 at 03:18:48PM -0400, Michael Meissner wrote:
> > The actual insns only check TARGET_POWER10 (so no TARGET_FLOAT128_HW).
> > Which is right, this or that?
>
> It should include TARGET_FLOAT128_HW.
Okay, so fix that :-)
> The problem area is a power10 running in
> big
On 6/23/2021 7:16 AM, Richard Biener wrote:
This adjusts the loop interchange dependence checking to disallow
an outer loop dependence distance of zero.
Bootstrapped and tested on x86_64-unknown-linux-gnu, OK?
Thanks,
Richard.
2021-06-23 Richard Biener
PR
On 6/23/2021 4:46 AM, Richard Biener wrote:
We were ignoring DR_STEP for VF == 1 which is OK only in case
the scalar order is preserved or both DR steps are the same.
Bootstrapped and tested on x86_64-unknown-linux-gnu, OK?
Thanks,
Richard.
2021-06-23 Richard Biener
PR
On 6/22/21 11:23 PM, Trevor Saunders wrote:
On Tue, Jun 22, 2021 at 02:01:24PM -0600, Martin Sebor wrote:
On 6/21/21 1:15 AM, Richard Biener wrote:
On Fri, Jun 18, 2021 at 6:03 PM Martin Sebor wrote:
On 6/18/21 4:38 AM, Richard Biener wrote:
On Thu, Jun 17, 2021 at 4:43 PM Martin Sebor
Here we're crashing because cp_fold_function walks into the (templated)
requirements of a requires-expression outside a template, but the
folding routines aren't prepared to handle templated trees. This patch
fixes this by making cp_fold use evaluate_requires_expr to fold a
requires-expression as
On 6/23/21 1:43 AM, Richard Biener wrote:
On Wed, Jun 23, 2021 at 7:23 AM Trevor Saunders wrote:
On Tue, Jun 22, 2021 at 02:01:24PM -0600, Martin Sebor wrote:
On 6/21/21 1:15 AM, Richard Biener wrote:
[...]
But maybe I'm misunderstanding C++ too much :/
Well, I guess b) from above means
Hi!
On Wed, Jun 23, 2021 at 03:22:34PM +0200, Martin Liška wrote:
> As mentioned in the "Fallout: save/restore target options in
> handle_optimize_attribute"
> thread, we need to support target option restore of
> rs6000_long_double_type_size == FLOAT_PRECISION_TFmode.
I have no idea? Could
Bootstrapped and regtested on s390x-redhat-linux. Ok for master?
v1: https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573348.html
v1 -> v2: Use ATTRIBUTE_UNUSED, compact op[] array (Andreas).
I've also noticed that one of the nops that we generate for
-mnop-mcount is not
From: Andrew Pinski
To improve phiopt and be able to remove abs_replacement, this ports
most of "A CMP 0 ? A : -A" from fold_cond_expr_with_comparison to
match.pd. There is a few extra changes that are needed to remove
the "A CMP 0 ? A : -A" part from fold_cond_expr_with_comparison:
* Need
From: Andrew Pinski
While converting some fold_cond_expr_with_comparison
to match, I found that I wanted to use "for cnd (cond vec_cond)"
but that was not causing the lowering of cond to happen.
What was happening was the lowering of the for loop
was happening after the lowering of the cond. So
From: Andrew Pinski
To move a few things more to match-and-simplify from phiopt,
we need to allow match_simplify_replacement to run in early
phiopt. To do this we add a replacement for gimple_simplify
that is explictly for phiopt.
OK? Bootstrapped and tested on x86_64-linux-gnu with no
From: Andrew Pinski
Since match and simplify does not have all of the inverted
comparison patterns, it make sense to just have
phi-opt try to do the inversion and try match and simplify again.
OK? Bootstrapped and tested on x86_64-linux-gnu.
Thanks,
Andrew Pinski
gcc/ChangeLog:
*
From: Andrew Pinski
Since match_simplify_replacement uses gimple_simplify, there is a new
ssa name created sometimes and then we go and replace the phi edge with
this new ssa name, the range information on the phi is lost.
Placing this in replace_phi_edge_with_variable is the best option instead
From: Andrew Pinski
To make things slightly easiler to convert fold_cond_expr_with_comparison
over to match.pd, expanding the arg0 argument into 3 different arguments
is done. Also this was simple because we don't use arg0 after grabbing
the code and the two operands.
Also since we do this, we
From: Andrew Pinski
I had missed this when wrote the patch which allowed the
gimple to be moved from inside the conditional as it. It
was also missed in the review. Anyways the range information
needs to be reset for the moved gimple as it was under a
conditional and the flow has changed to be
From: Andrew Pinski
To able to move PHI-OPT's abs_replacement to match.pd, a bunch
of support needed to be added to PHI-OPT.
This is a set of 7 patches which allows us to remove abs_replacement
and even does one set further and does a few extra transformations
that abs_replacement did not do
On 6/23/21 4:49 PM, Patrick Palka wrote:
On Wed, 23 Jun 2021, Jason Merrill wrote:
On 6/23/21 2:18 PM, Patrick Palka wrote:
We set DECL_CONTEXT on implicitly generated deduction guides so that
their access is consistent with that of the constructor. But this
apparently leads to excessive
On Wed, 23 Jun 2021, Jason Merrill wrote:
> On 6/23/21 2:18 PM, Patrick Palka wrote:
> > We set DECL_CONTEXT on implicitly generated deduction guides so that
> > their access is consistent with that of the constructor. But this
> > apparently leads to excessive instantiation in some cases,
On Mon, Jun 21, 2021 at 08:09:20AM +0200, Richard Biener wrote:
> On Sun, 20 Jun 2021, Dimitar Dimitrov wrote:
>
> > Slim LTO object files have been the default for quite a while, since:
> > commit e9f67e625c2a4225a7169d7220dcb85b6fdd7ca9
> > Author: Jan Hubicka
> > common.opt
Indeed, I somehow managed to use the wrong of the two enums in the cast ...
Fixed in r12-1760-gcac3527793b38164e2a83c7ccbfe0cfcf5ac95b8
On 23.06.21 16:13, Martin Liška wrote:
I noticed the patch causes the following clang warnings:
gcc/fortran/dump-parse-tree.c:1786:11: warning: comparison of
On 6/23/21 2:18 PM, Patrick Palka wrote:
We set DECL_CONTEXT on implicitly generated deduction guides so that
their access is consistent with that of the constructor. But this
apparently leads to excessive instantiation in some cases, ultimately
because instantiation of a deduction guide should
On 6/22/21 5:28 PM, David Malcolm wrote:
On Tue, 2021-06-22 at 19:18 -0400, David Malcolm wrote:
On Fri, 2021-06-04 at 15:41 -0600, Martin Sebor wrote:
The attached patch introduces the suppress_warning(),
warning_suppressed(), and copy_no_warning() APIs without making
use of them in the rest
On 6/23/21 2:37 PM, Richard Biener via Gcc-patches wrote:
On June 23, 2021 5:03:05 PM GMT+02:00, Aldy Hernandez via Gcc-patches
wrote:
The call to gimple_call_fntype() in gimple_call_return_type() may
return
NULL, which causes the TREE_TYPE(lhs) to ICE. I think it would be best
to
return
Note, as I mentioned previously, this patch needs to go into GCC 11.
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797
Note, this patch should go into GCC 11 after baking on the master branch.
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797
Ping this patch.
| Date: Tue, 8 Jun 2021 20:24:47 -0400
| Subject: [PATCH 3/3] Add IEEE 128-bit fp conditional move on PowerPC.
| Message-ID: <20210609002447.gc18...@ibm-toto.the-meissners.org>
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email:
Ping this patch:
| Date: Thu, 17 Jun 2021 18:56:09 -0400
| Subject: [PATCH 2/3 V2] Fix IEEE 128-bit min/max test.
| Message-ID: <20210617225609.ga4...@ibm-toto.the-meissners.org>
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email:
Ping this patch.
| Date: Fri, 4 Jun 2021 11:10:37 -0400
| Subject: Generate 128-bit divide/modulus
| Message-ID: <20210604151037.ga27...@ibm-toto.the-meissners.org>
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1
On 6/22/2021 3:41 AM, Xi Ruoyao via Gcc-patches wrote:
On Tue, 2021-06-22 at 10:37 +0200, Richard Biener wrote:
On Mon, Jun 21, 2021 at 6:53 PM Xi Ruoyao via Gcc-patches
wrote:
This test relies on wrap behavior of signed overflow. Without -
fwrapv
it is known to fail on mips (and maybe
On 6/21/2021 10:51 AM, Xi Ruoyao via Gcc-patches wrote:
This test relies on wrap behavior of signed overflow. Without -fwrapv
it is known to fail on mips (and maybe some other targets as well).
gcc/testsuite/
* gcc.c-torture/execute/950704-1.c: Add -fwrapv to avoid
On June 23, 2021 5:03:05 PM GMT+02:00, Aldy Hernandez via Gcc-patches
wrote:
>The call to gimple_call_fntype() in gimple_call_return_type() may
>return
>NULL, which causes the TREE_TYPE(lhs) to ICE. I think it would be best
>to
>return NULL (or void_type_node) rather than aborting.
>
>I'm
We set DECL_CONTEXT on implicitly generated deduction guides so that
their access is consistent with that of the constructor. But this
apparently leads to excessive instantiation in some cases, ultimately
because instantiation of a deduction guide should be independent of
instantiation of the
On 23/06/21 18:51 +0100, Jonathan Wakely wrote:
Here's what I've committed. Tested x86_64-linux and powerpc64le-linux.
Pushed to trunk.
commit b92d12d3fe3f1aa56d190d960e40c62869a6cfbb
Author: Cassio Neri
Date: Wed Jun 23 15:32:16 2021
libstdc++: More efficient
On 23/06/21 14:16 +0100, Jonathan Wakely wrote:
On 23/06/21 12:45 +0100, Jonathan Wakely wrote:
On 21/05/21 19:44 +0100, Cassio Neri via Libstdc++ wrote:
I've checked the generated code and the compiler doesn't figure out
the logic. I added a comment to explain.
(Revised patch below and
On Wed, Jun 23, 2021 at 12:17:07PM +0800, Kewen.Lin wrote:
> >> +#ifdef FLOAT128_HW_INSNS_ISA3_1
> >> TFtype __floattikf (TItype_ppc)
> >>__attribute__ ((__ifunc__ ("__floattikf_resolve")));
> >
> > I wonder if we now need TItype_ppc at all anymore, btw?
>
> Sorry that I don't quite follow
On Tue, Jun 22, 2021 at 12:41:27AM +0200, Jakub Jelinek wrote:
> On Mon, Jun 21, 2021 at 11:36:48PM +0100, Gaius Mulley via Gcc-patches wrote:
> > > : error: the file containing the definition module
> > > <80><98>M2RTS
> > > <80><99> cannot be found
> > > compiler exited with status 1
> > >
On Wed, 23 Jun 2021, Martin Liška wrote:
> @Joseph: Can you share your thoughts about the used Makefile integration? What
> do you suggest for 2)
> (note that explicit listing of all .rst file would be crazy)?
You can write dependencies on e.g. doc/gcc/*.rst (which might be more
files than
On Fri, 4 Jun 2021 at 23:31, Thomas Rodgers wrote:
>
> This cleans up the implementation of atomic_timed_wait.h and fixes the
> accidental pessimization of spinning after waiting in
> __timed_waiter_pool::_M_do_wait_until.
This one's still pending review, right?
>
> libstdc++-v3/ChangeLog:
>
>
On Tue, 8 Jun 2021 at 09:57, Matthias Kretz wrote:
>
> As discussed a long time ago on IRC, this improves (i.e. decreases by default)
> the verbosity of make check-simd, gives more verbosity options, and finally
> documents how the simd testsuite is used and how it works. In addition, after
>
The call to gimple_call_fntype() in gimple_call_return_type() may return
NULL, which causes the TREE_TYPE(lhs) to ICE. I think it would be best to
return NULL (or void_type_node) rather than aborting.
I'm running into this because fold_using_range::range_of_call, calls
gimple_call_return_type
Hi!
On Tue, Jun 22, 2021 at 04:13:36PM -0500, Aaron Sawdey wrote:
> SPEC2017 testing on p10 shows that this optimization does not have a
> positive impact on performance. So we are no longer going to enable it
> by default. The test cases for it needed to be updated so they always
> enable it to
Wilco Dijkstra writes:
> Hi Richard,
>
>> So rather than have two patterns that generate frintn, I think
>> it would be better to change the existing frint_pattern entry to
>> "roundeven" instead, and fix whatever the fallout is. Hopefully it
>> shouldn't be too bad, since we already use the
On 6/23/2021 3:53 AM, Eric Botcazou wrote:
The issues are that 1) they use readelf instead of objdump and 2) they use
ELF syntax in the assembly code.
Tested on x86-64/Linux and x86[-64]/Windows, OK for mainline and 11 branch?
2021-06-23 Eric Botcazou
* configure.ac (--gdwarf-5
On 6/23/2021 4:06 AM, Eric Botcazou wrote:
Hi,
when the assembler supports it, the compiler automatically passes --gdwarf-5
to it, which has an interesting side effect: any assembly instruction prior
to the first .file directive defines a new line associated with .file 0 in
the .debug_line
This file removes all the fold_using_range related code from
gimple-range.{h,cc} and moves it into its own file, gimple-range-fold.{h,cc}
A couple of routines were also relocated to gimple-range-gori.{h,cc} as
they were strictly related to unwind calculations and belong there.
This leaves
As described in PR 101014, this patch should fix both PRs.
The cache propagation engine works by combining incoming ranges to a
block and if that is different than that current on-entry range,
proceeds to push this new value on outgoing edges.
What was happening here is this new value that
The introduction of the sparse bitmap on-entry cache for large BB
functions also introduced the concept that the value we ask to be
written to the cache may not be properly represented. It is limited to
15 unique ranges for any given ssa-name, then it reverts to varying for
any additional
When we are dumping the rangers state, we tend to do it at the end when
EVRP is shutting down. The dumping routine is checking to see if the
cache has an on-entry value or the edge generates a range before
dumping, but when it does the actual dump, its calling range_on_edge
which can go and
Nothing too special here, this allows using generic logicals to
eliminate redundant test/compare instructions.
We need to pass in the INSN to the support routines so that it can be
examined to see if CC is relevant after this insn. If the condition
codes are relevant, then we can't use the
Hi José,
> Thus: Do you have a list of patches pending review?
https://gcc.gnu.org/pipermail/fortran/2021-April/055924.html
PRs 100029 and 100040. I have the patch in my working tree
for a long time. It works as expected. OK to commit.
Add emulation of V8QI PPERM permutations for TARGET_XOP target. Similar
to PSHUFB, the permutation is performed with V16QI PPERM instruction,
where selector is defined in V16QI mode with inactive elements set to 0x80.
Specific to two operand permutations is the remapping of elements from
the
Hello.
I noticed the patch causes the following clang warnings:
gcc/fortran/dump-parse-tree.c:1786:11: warning: comparison of different
enumeration types in switch statement ('enum gfc_omp_defaultmap' and
'gfc_omp_defaultmap_category') [-Wenum-compare-switch]
On 5/21/21 10:29 AM, Martin Liška wrote:
On 5/20/21 5:55 PM, Jan Hubicka wrote:
Quick solution is to also modify partitioner to use the local symbol
names when doing incremental linking (those mixing in source code and
random seeds) to avoid clashes.
Good hint. I added hash based on object
This refactors SLP permute propagation to record the outgoing permute
separately from the incoming/materialized one. Instead of separate
arrays/bitmaps I've now created a struct to represent the state.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
WDYT?
Richard.
2021-06-23
On 6/1/21 5:35 PM, Richard Earnshaw wrote:
My initial reaction is 'that can't be right'.
How would -mfp16-format=alternative ever work in this case?
You are right. I'm going to revert the hunk done
in g:ebd5e86c0f41dc1d692f9b2b68a510b1f6835a3e
Martin
>From
On Wed, 23 Jun 2021, Martin Jambor wrote:
> Hi,
>
> On Wed, Jun 23 2021, Richard Biener wrote:
> > On Wed, 23 Jun 2021, Martin Jambor wrote:
> >
> >> Hi,
> >>
> >> tree-inline leaves behind VAR_DECLs which are TREE_READONLY (because
> >> they are copies of const parameters) but are written to
Hello.
As mentioned in the "Fallout: save/restore target options in
handle_optimize_attribute"
thread, we need to support target option restore of
rs6000_long_double_type_size == FLOAT_PRECISION_TFmode.
Patch can bootstrap on ppc64le-linux-gnu and survives regression tests.
Ready to be
On 23/06/21 12:45 +0100, Jonathan Wakely wrote:
On 21/05/21 19:44 +0100, Cassio Neri via Libstdc++ wrote:
I've checked the generated code and the compiler doesn't figure out
the logic. I added a comment to explain.
(Revised patch below and attached.)
Best wishes,
Cassio.
---
Simple change
This adjusts the loop interchange dependence checking to disallow
an outer loop dependence distance of zero.
Bootstrapped and tested on x86_64-unknown-linux-gnu, OK?
Thanks,
Richard.
2021-06-23 Richard Biener
PR tree-optimization/101173
* gimple-loop-interchange.cc
On 6/23/21 2:38 PM, Jan Hubicka wrote:
Is there reason to prevent the inlining once instrumentation is done?
No ;)
I think you can just block it for early inliner.
Sure. Do you have a handy predicate function that tells if einliner is done?
Thanks,
Martin
Hello.
I've just made a first version of the patchset that sits in GCC source tree:
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=log;h=refs/users/marxin/heads/sphinx-v2
Changes since the last submission:
1) I made a brief proofreading and fixed most of the formatting and other issues
2)
> Hello.
>
> Similarly to e.g. sanitizer attributes, we sould prevent inlining when one
> function
> is marked as not instrumented. We should do that with -fprofile-generate only.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Thanks,
>
Hello.
Similarly to e.g. sanitizer attributes, we sould prevent inlining when one
function
is marked as not instrumented. We should do that with -fprofile-generate only.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
Adds
On 21/05/21 19:44 +0100, Cassio Neri via Libstdc++ wrote:
I've checked the generated code and the compiler doesn't figure out
the logic. I added a comment to explain.
(Revised patch below and attached.)
Best wishes,
Cassio.
---
Simple change to std::chrono::year::is_leap. If a year is
Hi,
while evaluating another patch that introduces more lvalue paradoxical
subregs I ran into an ICE in combine at
wide_int o = wi::insert (rtx_mode_t (outer, temp_mode),
rtx_mode_t (inner, dest_mode),
offset,
Hi,
On Wed, Jun 23 2021, Richard Biener wrote:
> On Wed, 23 Jun 2021, Martin Jambor wrote:
>
>> Hi,
>>
>> tree-inline leaves behind VAR_DECLs which are TREE_READONLY (because
>> they are copies of const parameters) but are written to because they
>> need to be initialized. This patch resets the
On 23/06/2021 12:11, Jonathan Wakely wrote:
On Wed, 23 Jun 2021 at 10:43, Christophe LYON wrote:
On 23/06/2021 11:17, Jonathan Wakely via Libstdc++ wrote:
On Wed, 23 Jun 2021 at 08:21, Christophe Lyon wrote:
This patch causes GCC build failures for bare-metal targets
(aarch64-elf,
The current RTX pattern for BSR allows combine pass to convert LZCNT insn
to BSR. Note that the LZCNT has a defined behavior to return the operand
size when operand is zero, where BSR has not.
Add a BSR specific setting of zero-flag to RTX pattern of BSR insn
in order to avoid matching unwanted
We were ignoring DR_STEP for VF == 1 which is OK only in case
the scalar order is preserved or both DR steps are the same.
Bootstrapped and tested on x86_64-unknown-linux-gnu, OK?
Thanks,
Richard.
2021-06-23 Richard Biener
PR tree-optimization/101105
* tree-vect-data-refs.c
Richard Biener writes:
> On Wed, Jun 23, 2021 at 7:23 AM Trevor Saunders wrote:
>>
>> On Tue, Jun 22, 2021 at 02:01:24PM -0600, Martin Sebor wrote:
>> > On 6/21/21 1:15 AM, Richard Biener wrote:
> [...]
>> > >
>> > > But maybe I'm misunderstanding C++ too much :/
>> > >
>> > > Well, I guess b)
On Wed, 23 Jun 2021, Martin Jambor wrote:
> Hi,
>
> tree-inline leaves behind VAR_DECLs which are TREE_READONLY (because
> they are copies of const parameters) but are written to because they
> need to be initialized. This patch resets the flag if any
> initialization is performed, regardless
On 6/23/21 11:30 AM, Prathamesh Kulkarni via Gcc-patches wrote:
Hi,
This patch adds an entry for cscope.out in .gitignore.
OK to commit ?
Sure.
Note that clangd provides much better support than legacy C cscope.
Cheers,
Martin
Thanks,
Prathamesh
On Wed, 23 Jun 2021 at 10:43, Christophe LYON wrote:
>
>
> On 23/06/2021 11:17, Jonathan Wakely via Libstdc++ wrote:
> > On Wed, 23 Jun 2021 at 08:21, Christophe Lyon wrote:
> >> This patch causes GCC build failures for bare-metal targets
> >> (aarch64-elf, arm-eabi). For instance on arm-eabi, I'm
Hi,
when the assembler supports it, the compiler automatically passes --gdwarf-5
to it, which has an interesting side effect: any assembly instruction prior
to the first .file directive defines a new line associated with .file 0 in
the .debug_line section and, of course, the numbering of these
On 23/06/2021 10:53, Tobias Burnus wrote:
+ additionally the following features which were available in C and C++
+ before: depobj, mutexinoutset and
I realise that you did not invent this awkward wording, but I'd prefer ...
"the following features that were previously only
On Wed, Jun 23, 2021 at 11:41 AM Uros Bizjak wrote:
>
> On Wed, Jun 23, 2021 at 11:32 AM Hongtao Liu wrote:
>
> > > > > > > Also when allocano cost of GENERAL_REGS is same as MASK_REGS,
> > > > > > > allocate
> > > > > > > MASK_REGS first since it has already been disparaged.
> > > > > > >
> >
Hi all,
this patch updates OpenMP for the non-bug-fix commits which have
been done in the last weeks.
It also updates GCN. The change assumes that the just approved
patch is committed ...
Comments, thoughts, wording suggestions? Did I miss some commit/feature?
Tobias
-
Mentor
The issues are that 1) they use readelf instead of objdump and 2) they use
ELF syntax in the assembly code.
Tested on x86-64/Linux and x86[-64]/Windows, OK for mainline and 11 branch?
2021-06-23 Eric Botcazou
* configure.ac (--gdwarf-5 option): Use objdump instead of readelf.
On Wed, Jun 23, 2021 at 11:32 AM Hongtao Liu wrote:
> > > > > > Also when allocano cost of GENERAL_REGS is same as MASK_REGS,
> > > > > > allocate
> > > > > > MASK_REGS first since it has already been disparaged.
> > > > > >
> > > > > > gcc/ChangeLog:
> > > > > >
> > > > > > PR
On 22/06/2021 18:14, Hafiz Abid Qadeer wrote:
Map GCN address spaces to the proposed DWARF address spaces defined by AMD at
https://llvm.org/docs/AMDGPUUsage.html#amdgpu-dwarf-address-class-mapping-table
gcc/
* config/gcn/gcn.c: Include dwarf2.h.
(gcn_addr_space_debug): New
On 22/06/2021 18:14, Hafiz Abid Qadeer wrote:
As size of address is bigger than registers in amdgcn, we are forced to use
DW_CFA_def_cfa_expression to make an expression that concatenates multiple
registers for the value of the CFA. This then prohibits us from using many
of the dwarf ops which
On 22/06/2021 18:14, Hafiz Abid Qadeer wrote:
Currently we don't get any call frame information for the amdgcn target.
This patch makes necessary adjustments to generate CFI that can work with
ROCGDB (ROCm 3.8+).
gcc/
* config/gcn/gcn.c (move_callee_saved_registers): Emit CFI notes for
On Wed, Jun 23, 2021 at 4:50 PM Hongtao Liu wrote:
>
> On Wed, Jun 23, 2021 at 3:59 PM Uros Bizjak wrote:
> >
> > On Mon, Jun 21, 2021 at 10:08 AM Hongtao Liu wrote:
> > >
> > > On Mon, Jun 21, 2021 at 3:28 PM Uros Bizjak via Gcc-patches
> > > wrote:
> > > >
> > > > On Mon, Jun 21, 2021 at
Hi,
This patch adds an entry for cscope.out in .gitignore.
OK to commit ?
Thanks,
Prathamesh
ignore-cscope.diff
Description: Binary data
1 - 100 of 121 matches
Mail list logo
