David: PING
In case you missed it, that's the last patch left to review for now.
Le dimanche 21 novembre 2021 à 16:44 -0500, Antoni Boucher a écrit :
> Thanks for the review!
> I updated the patch.
>
> See notes below.
>
> Le samedi 20 novembre 2021 à 13:50 -0500, David Malcolm a écrit :
> >
On Thu, Dec 02, 2021 at 12:56:38PM -0500, Jason Merrill wrote:
> On 12/2/21 10:27, Marek Polacek wrote:
> > On Wed, Dec 01, 2021 at 11:24:58PM -0500, Jason Merrill wrote:
> > > On 12/1/21 10:16, Marek Polacek wrote:
> > > > In C++23, auto(x) is valid, so decltype(auto(x)) should also be valid,
> >
On 11/8/2021 7:34 PM, Martin Sebor via Gcc-patches wrote:
The pointer-query code that implements compute_objsize() that's
in turn used by most middle end access warnings now has a few
warts in it and (at least) one bug. With the exception of
the bug the warts aren't behind any user-visible
On 12/2/21 4:24 PM, Segher Boessenkool wrote:
> On Thu, Dec 02, 2021 at 10:43:24AM -0600, Bill Schmidt wrote:
>> The new built-in infrastructure is now enabled!
>
> Congratulations, and thanks for all the work!
A big +1!
Peter
On 12/2/21 9:46 PM, Kewen.Lin via Gcc-patches wrote:
> on 2021/11/30 上午12:57, Segher Boessenkool wrote:
>> On Wed, Sep 01, 2021 at 02:55:51PM +0800, Kewen.Lin wrote:
>>> This patch is to fix the inconsistent behaviors for non-LTO mode
>>> and LTO mode. As Martin pointed out, currently the
On Fri, Dec 03, 2021 at 11:27:27AM +0100, Jakub Jelinek wrote:
> Hi!
>
> The https://gcc.gnu.org/pipermail/gcc-patches/2020-November/557903.html
> change broke the following testcases. The problem is when a pragma
> namespace allows expansion (i.e. p->is_nspace && p->allow_expansion),
> e.g. the
Tested powerpc64le-linux, pushed to trunk.
This introduces a new RAII type to simplify the emplace members which
currently use try-catch blocks to deallocate a node if an exception is
thrown by the comparisons done during insertion. The new type is created
on the stack and manages the allocation
On Mon, 22 Nov 2021 at 16:31, Stephan Bergmann via Libstdc++
wrote:
>
> When using recent libstc++ trunk with Clang in C++20 mode,
> std::u16string literals as in
>
> > #include
> > int main() {
> > using namespace std::literals;
> > u""s;
> > }
>
> started to cause linker failures due to
On 12/3/21 3:27 PM, Peter Bergner wrote:
> On 12/3/21 2:39 PM, Peter Bergner wrote:
>> On 10/29/21 4:45 PM, Segher Boessenkool wrote:
>>> On Wed, Oct 27, 2021 at 10:17:39PM -0500, Peter Bergner wrote:
2021-10-27 Martin Liska
gcc/
PR target/101324
*
We can make some function signatures shorter to print by omitting redundant
nested-name-specifiers in the rest of the declarator.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
* error.c (current_dump_scope): New variable.
(dump_scope): Check it.
I intend to merge this patch next week, unless I hear objections. I
consider it a bug fix which fits the Stage 3 criteria. It fixes the
RPMSG firmware examples in the latest version 6.0 of TI's PRU Software
Package.
The .pru_irq_map section has been introduced by Linux kernel 5.10:
On 12/3/21 2:39 PM, Peter Bergner wrote:
> On 10/29/21 4:45 PM, Segher Boessenkool wrote:
>> On Wed, Oct 27, 2021 at 10:17:39PM -0500, Peter Bergner wrote:
>>> 2021-10-27 Martin Liska
>>>
>>> gcc/
>>> PR target/101324
>>> * config/rs6000/rs6000.c (rs6000_option_override_internal): Move
When a request is made for the range of an ssa_name at some location,
the first thing we do is invoke range_of_stmt() to ensure we have looked
at the definition and have an evaluation for the name at a global
level. I recently added a patch which dramatically reduces the call
stack
has_edge_range_p() and may_recompute_p() currently only take an optional
edge as a parameter. They only indicate if a range *might* be
calculated for a name, but they do not do any calculations.
To determine the results, they always consult the exports for the
edge->src block. the value is
On 10/29/21 4:45 PM, Segher Boessenkool wrote:
> On Wed, Oct 27, 2021 at 10:17:39PM -0500, Peter Bergner wrote:
>> 2021-10-27 Martin Liska
>>
>> gcc/
>> PR target/101324
>> * config/rs6000/rs6000.c (rs6000_option_override_internal): Move the
>> disabling of shrink-wrapping when
On 12/2/21 5:15 PM, Segher Boessenkool wrote:
>> Tested on powerpc64le*-linux with no regressions. Ok for mainline?
>
> What can "*" be there other than the empty string? Which valuse of "*"
> did you test? :-)
Heh, too used to typing powerpc64*-linux. Yeah, in this case * == "".
> Okay
It can be used to speed up the libgcc unwinder, and the internal
_dl_find_dso_for_object function (which is used for caller
identification in dlopen and related functions, and in dladdr).
_dl_find_object is in the internal namespace due to bug 28503.
If libgcc switches to _dl_find_object, this
Doh! This time with the patch attached...
This patch resolves PR target/43892 (suboptimal add with carry) by adding
four new define_insn_and_split to the rs6000 backend, that all recognize
pairs of instructions where the first instruction sets the carry flag and
the second one consumes it. It
On 12/2/21 15:56, Jakub Jelinek wrote:
On Thu, Dec 02, 2021 at 03:32:58PM -0500, Jason Merrill wrote:
So IMHO we need the patch I've posted (with the testcases slightly adjusted
not to do those extra copies afterwards for now),
and try to deal with the lvalue-to-rvalue conversion of
On 12/2/21 18:12, Marek Polacek wrote:
On Wed, Dec 01, 2021 at 11:16:27PM -0500, Jason Merrill wrote:
On 12/1/21 10:16, Marek Polacek wrote:
In r11-4758, I tried to fix this problem:
int & = 0;
decltype(auto) j = i; // should behave like int & = i; error
wherein do_auto_deduction was
From: Bill Schmidt
Hi!
While we had two sets of built-in infrastructure at once, I added _x as a
suffix to two arrays to disambiguate the old and new versions. Time to fix
that also.
Bootstrapped and tested on powerpc64le-linux-gnu with no regressions. Is this
okay for trunk?
Thanks!
Bill
From: Bill Schmidt
Hi!
While we had two sets of built-in functionality at the same time, I put "new"
in the names of quite a few functions. Time to undo that.
Bootstrapped and tested on powerpc64le-linux-gnu with no regressions. Is this
okay for trunk?
Thanks!
Bill
2021-12-02 Bill Schmidt
From: Bill Schmidt
Hi!
This patch just renames a file and updates the build machinery accordingly.
Bootstrapped and tested on powerpc64le-linux-gnu with no regressions. Is this
okay for trunk?
Thanks!
Bill
2021-12-02 Bill Schmidt
gcc/
* config/rs6000/rs6000-builtin-new.def:
From: Bill Schmidt
Hi!
Now that the new built-in function support is all upstream and enabled, it
seems safe and prudent to remove the old code to avoid confusion. I broke this
up to the extent possible, but the first patch is a bit large and messy because
so many dead functions have to be
On 12/3/21 10:26 AM, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Dec 02, 2021 at 04:53:18PM -0600, Bill Schmidt wrote:
>> I discovered this bug while working on patches to remove the old built-ins
>> infrastructure. I missed a spot in converting from the rs6000_builtins enum
>> to
>> the
On Fri, Dec 3, 2021 at 8:55 AM Uros Bizjak wrote:
>
> On Fri, Dec 3, 2021 at 2:24 PM H.J. Lu wrote:
> >
> > On Thu, Nov 25, 2021 at 2:47 PM H.J. Lu wrote:
> > >
> > > Add -mmove-max=bits and -mstore-max=bits to enable 256-bit/512-bit move
> > > and store, independent of
On 12/3/2021 12:53 AM, Iain Sandoe wrote:
On 3 Dec 2021, at 03:12, Jeff Law wrote:
On 11/22/2021 7:49 AM, Maxim Blinov wrote:
Hi all, apologies for forgetting to add the cover letter.
No worries. I'd already assumed this was to support aarch64 trampolines on
darwin by having them
Update PR target/83782 tests to scan leal for x32 to fix:
FAIL: gcc.target/i386/pr83782-1.c scan-assembler leaq[ \\t]foo\\(%rip\\),[
\\t]%rax
FAIL: gcc.target/i386/pr83782-2.c scan-assembler leaq[ \\t]foo\\(%rip\\),[
\\t]%rax
PR target/83782
* gcc.target/i386/pr83782-1.c: Also
On Fri, Nov 19, 2021 at 09:54:12PM +0800, Chung-Lin Tang wrote:
> 2021-11-19 Chung-Lin Tang
>
> gcc/c/ChangeLog:
>
> * c-parser.c (struct omp_dim): New struct type for use inside
> c_parser_omp_variable_list.
> (c_parser_omp_variable_list): Allow multiple levels of array and
On Fri, Dec 3, 2021 at 2:24 PM H.J. Lu wrote:
>
> On Thu, Nov 25, 2021 at 2:47 PM H.J. Lu wrote:
> >
> > Add -mmove-max=bits and -mstore-max=bits to enable 256-bit/512-bit move
> > and store, independent of -mprefer-vector-width=bits:
> >
> > 1. Add X86_TUNE_AVX512_MOVE_BY_PIECES and
On Tue, Nov 16, 2021 at 08:43:27PM +0800, Chung-Lin Tang wrote:
> 2021-11-16 Chung-Lin Tang
>
> PR middle-end/92120
>
> gcc/cp/ChangeLog:
>
> * cp-tree.h (finish_omp_target): New declaration.
> (finish_omp_target_clauses): Likewise.
> * parser.c
On December 3, 2021 3:15:25 PM GMT+01:00, Andrew MacLeod
wrote:
>When something like the loop unswitching code adds elements to the CFGs,
>does this invalidate the dominators? or are they updated? or is it in
>an in between state.
>
>Im curious because a) the relation code uses it under the
Hi!
On Thu, Dec 02, 2021 at 04:53:18PM -0600, Bill Schmidt wrote:
> I discovered this bug while working on patches to remove the old built-ins
> infrastructure. I missed a spot in converting from the rs6000_builtins enum
> to
> the rs6000_gen_builtins enum. This fixes it. The fix is
Hi SiYu:
Committed, thanks!
On Thu, Nov 25, 2021 at 12:42 AM Palmer Dabbelt wrote:
>
> On Wed, 24 Nov 2021 02:00:33 PST (-0800), Kito Cheng wrote:
> > I would prefer to accept those patchset even with no builtin function
> > or intrinsic function yet,
> > this not only add the support of -march
On 28/10/2021 12:42, Tejas Belagod via Gcc-patches wrote:
-Original Message-
From: Richard Earnshaw
Sent: Monday, October 11, 2021 1:58 PM
To: Tejas Belagod ; gcc-patches@gcc.gnu.org
Subject: Re: [Patch 2/7, Arm, GCC] Add option -mbranch-protection.
On 08/10/2021 13:17, Tejas
gcc/ChangeLog:
* common/config/riscv/riscv-common.c (riscv_implied_info): Add
vector extensions.
(riscv_ext_version_table): Add version info for vector extensions.
(riscv_ext_flag_table): Add option mask for vector extensions.
* config/riscv/riscv-opts.h
RISC-V spec only allow alphabetical name for extension before, however
vector extension add several extension named with digits, so we try to
extend the naming rule.
Ref:
https://github.com/riscv/riscv-isa-manual/pull/718
gcc/ChangeLog:
* common/config/riscv/riscv-common.c
This patch set adding basic -march option support and feature test marco for
vector extensions, and also extend the syntax of arch string for vector
extensions, although that should change RISC-V ISA manual first would be
better, but we don't got response[1] yet, and that will block whole vector
On 11/29/2021 4:51 PM, Navid Rahimi wrote:
Jeff,
Sorry for bringing back this thread.
Quick question, you mentioned checking the TYPE_PRECISION to make sure the type
is a canonical Boolean type (and not a fancy signed/unsigned Boolean type from
Ada Andrew mentioned).
But I noticed that
On 12/2/2021 7:53 PM, Eugene Rozenfeld via Gcc-patches wrote:
When a basic block A has been annotated with a count and it has only one
successor (or predecessor) B, we can propagate the A's count to B.
The algorithm without this change could leave B without an annotation if B had
other
On 28/10/2021 12:41, Tejas Belagod via Gcc-patches wrote:
-Original Message-
From: Richard Earnshaw
Sent: Monday, October 11, 2021 1:29 PM
To: Tejas Belagod ; gcc-patches@gcc.gnu.org
Subject: Re: [Patch 1/7, Arm, GCC] Add Armv8.1-M Mainline target feature
+pacbti.
On 08/10/2021
On Wed, Oct 20, 2021 at 12:54:05PM +0200, Tobias Burnus wrote:
> libgomp/ChangeLog:
>
> * libgomp.texi (OMP_PLACES): Extend description for OMP 5.1 changes.
>
> diff --git a/libgomp/libgomp.texi b/libgomp/libgomp.texi
> index e9fa8ba0bf7..aee82ef2ba2 100644
> --- a/libgomp/libgomp.texi
>
On 12/2/2021 9:26 PM, Jojo R wrote:
Skip renaming if instruction is noop move, and it will
been removed for performance.
gcc/
* regrename.c (find_rename_reg): Return satisfied regno
if instruction is noop move.
OK
jeff
On 12/3/2021 2:21 AM, Alexandre Oliva via Gcc-patches wrote:
When -fif-conversion2 is enabled, we attempt to replace conditional
branches around unconditional traps with conditional traps. That
canonicalizes compares, which may change an immediate that barely fits
into one that doesn't.
The
On 30/11/2021 11:11, Andrea Corallo via Gcc-patches wrote:
Tejas Belagod via Gcc-patches writes:
Ping for this series.
Thanks,
Tejas.
Hi all,
pinging this series.
BR
Andrea
It would be easier to find the 'series' if the messages were properly
threaded together...
R.
On 10/11/2021 13:55, Andrea Corallo via Gcc-patches wrote:
Tejas Belagod via Gcc-patches writes:
[...]
This change refactors all the mbranch-protection option parsing code and types
to make it common to both AArch32 and AArch64 backends. This change also pulls
in some supporting types
On Mon, Nov 15, 2021 at 12:29:31PM +0100, Tobias Burnus wrote:
> --- a/gcc/fortran/dump-parse-tree.c
> +++ b/gcc/fortran/dump-parse-tree.c
> @@ -1926,6 +1930,22 @@ show_omp_clauses (gfc_omp_clauses *omp_clauses)
>fputc (' ', dumpfile);
>fputs (memorder, dumpfile);
> }
> + if
When something like the loop unswitching code adds elements to the CFGs,
does this invalidate the dominators? or are they updated? or is it in
an in between state.
Im curious because a) the relation code uses it under the covers, and b)
Im looking to add a ranger caching improvement which
On 12/2/21 11:02, Martin Liška wrote:
On 12/2/21 15:27, Andrew MacLeod wrote:
ranger->gori().outgoing_edge_range_p (irange , edge e, tree name,
*get_global_range_query ());
Thank you! It works for me!
Martin
btw, this applies to names not on the stmt as well. The function
returns TRUE
On Thu, Nov 25, 2021 at 2:47 PM H.J. Lu wrote:
>
> Add -mmove-max=bits and -mstore-max=bits to enable 256-bit/512-bit move
> and store, independent of -mprefer-vector-width=bits:
>
> 1. Add X86_TUNE_AVX512_MOVE_BY_PIECES and X86_TUNE_AVX512_STORE_BY_PIECES
> which are enabled for Intel Sapphire
On 02/12/2021 22:48, Harald Anlauf via Fortran wrote:
Dear Fortranners,
specifying invalid constant array declarations (e.g. real array bounds)
could lead to an ICE because the array specs were checked for consistency.
A possible solution is to try an early simplification before doing that
Andrew Pinski via Gcc-patches writes:
> On Thu, Nov 18, 2021 at 5:55 PM apinski--- via Gcc-patches
> wrote:
>>
>> From: Andrew Pinski
>>
>> The problem here is that aarch64_expand_setmem does not change the alignment
>> for strict alignment case. This is a simplified patch from what I had
>>
Tamar Christina writes:
>> This hashing looks unnecessarily complex. The values we're hashing are
>> vector SSA_NAMEs, so I think we should be able to hash and compare them
>> as a plain pair of pointers.
>>
>> The type could then be std::pair and the hashing could be done using
>> pair_hash
> On 3 Dec 2021, at 11:27, Rasmus Villemoes wrote:
>
> Reverting my fix and applying this on top of my gcc-11.2 based branch
> seems to work. I haven't used the compiler for building or running any
> modules (don't have the hardware handy), but I've done an 'objdump -d'
> comparison on all
On Wed, Dec 01, 2021 at 02:01:59PM +0530, Siddhesh Poyarekar wrote:
> PR tree-optimization/103456
> * gcc.dg/ubsan/pr103456.c: New test.
ubsan.exp cycles through torture options, and that includes
-O2 -flto -fno-fat-lto-objects. But with those options
tree dump scans don't work for
Hi!
The https://gcc.gnu.org/pipermail/gcc-patches/2020-November/557903.html
change broke the following testcases. The problem is when a pragma
namespace allows expansion (i.e. p->is_nspace && p->allow_expansion),
e.g. the omp or acc namespaces do, then when parsing the second pragma
token we do
On 02/12/2021 16.29, Olivier Hainque wrote:
> Hi Rasmus,
>
> Some new on this.
>
>> On 20 Nov 2021, at 09:07, Olivier Hainque wrote:
>>
>> I'll check how our build sequence proceeds.
>
> Turns out our build succeeds thanks to the presence
> of a vendor version of stdint.h in the VxWorks6/7
On Fri, Dec 3, 2021 at 7:19 AM liuhongt wrote:
>
> Hi:
> > Please also consider TARGET_INTER_UNIT_MOVES_TO_VEC and
> > TARGET_INTER_UNIT_MOVES_FROM_VEC.
> Here's updated patch.
>
> Also honor TARGET_INTER_UNIT_MOVES_TO/FROM_VEC and in
> preferred_{,out_}reload_class.
>
> Bootstrapped and
Dear
This is a manufacturer with 20 year's solid experience in the lighting industry.
We can provide good quality with lower price.
Making your products in your market has a great competition.
Our main products are ceiling lights, down lights, led bulbs,flood lights and
so on.
If you have any
> On 11/27/21 16:56, Jan Hubicka via Gcc-patches wrote:
> > Hi,
> > Profile-report was never properly updated after switch to new profile
> > representation. This patch fixes the way profile mismatches are
> > calculated: we used to collect separately count and freq mismatches,
> > while now we
When -fif-conversion2 is enabled, we attempt to replace conditional
branches around unconditional traps with conditional traps. That
canonicalizes compares, which may change an immediate that barely fits
into one that doesn't.
The compare for the trap is first checked using the predicates of
On Dec 2, 2021, Richard Biener wrote:
> While adding ASMNESIA looks OK at this point, I'm not sure about the
> asm handling stuff. You mention 'reload' above, do you mean LRA?
I meant the allocation was first visible in -fdump-rtl-reload. I've
added a note about this problem, and a modified
On Sun, 28 Nov 2021 19:52:08 +0100
Jan Hubicka via Gcc-patches wrote:
> Basic block 136 guessed freq: 17.548 cummulative: 0.60% feedback
> freq: 51.848 cummulative: 1.94% cnt: 101811269914
> diff --git a/gcc/profile.c b/gcc/profile.c
> index d07002d265e..dbf42ff7b2b 100644
>
On Sat, 27 Nov 2021 16:56:32 +0100
Jan Hubicka via Gcc-patches wrote:
> --- a/gcc/cfghooks.h
> +++ b/gcc/cfghooks.h
> @@ -36,22 +36,25 @@ along with GCC; see the file COPYING3. If not see
> and one CFG hook per CFG mode. */
> struct profile_record
> {
> - /* Likewise for a basic
> The transposition nolto -> notlo is confusing and it makes the long
> name even harder to read than it already is - I kept reading it as
> "not lo" until I realized it was a simply typo.
Thanks for catching this!
--
Eric Botcazou
From: Andrew Pinski
This testcase used to fail before GCC 6.4.0 due to the wrong
type being used for auto when used with bitfields, the C++
front-end was using the "bitfield" type rather than the
underlaying type.
Committed the testcase after a quick check.
PR c++/71792
66 matches
Mail list logo
