Hi,
Add myself as PowerPC port co-maintainer and to DCO section. Pushed below as
r13-127.
ChangeLog:
* MAINTAINERS: Add myself as PowerPC port co-maintainer and to DCO
section.
---
MAINTAINERS | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS
Optimize
_1 = *srcp_3(D);
_4 = VEC_PERM_EXPR <_1, _1, { 4, 5, 6, 7, 4, 5, 6, 7 }>;
_5 = BIT_FIELD_REF <_4, 128, 0>;
to
_1 = *srcp_3(D);
_5 = BIT_FIELD_REF <_1, 128, 128>;
the upper will finally be optimized to
_5 = BIT_FIELD_REF <*srcp_3(D), 128, 128>;
Bootstrapped and regtested on
On 5/4/22 19:20, Marek Polacek wrote:
On Wed, May 04, 2022 at 05:44:45PM -0400, Jason Merrill wrote:
On 5/4/22 16:03, Marek Polacek wrote:
This patch fixes the second half of 64679. Here we issue a wrong
"redefinition of 'int x'" for the following:
struct Bar {
Bar(int, int, int);
On Wed, May 04, 2022 at 05:44:45PM -0400, Jason Merrill wrote:
> On 5/4/22 16:03, Marek Polacek wrote:
> > This patch fixes the second half of 64679. Here we issue a wrong
> > "redefinition of 'int x'" for the following:
> >
> >struct Bar {
> > Bar(int, int, int);
> >};
> >
> >
On Wed, May 4, 2022 at 1:59 AM Martin Liška wrote:
>
> Hello.
>
> I'm going to do merge from upstream.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests. I've
> also tested
> on ppc64le-linux-gnu and verified the ABI.
>
> The only real change is a small change in
>
On Wed, 4 May 2022 at 12:14, Jonathan Wakely wrote:
>
> On Tue, 3 May 2022 at 11:57, Jakob Hasse via Libstdc++
> wrote:
> >
> > This is a patch for the bug 105387 reported in bugzilla: 105387
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105387. This report should
> > contain all the
In my previous PR104470 patch I added yet another place that needs to handle
dependent member rewriting for deduction guides; this patches centralizes
rewriting into maybe_dependent_member_ref. tsubst_baselink still has its
own handling because that's simpler than teaching
On 5/4/22 16:03, Marek Polacek wrote:
This patch fixes the second half of 64679. Here we issue a wrong
"redefinition of 'int x'" for the following:
struct Bar {
Bar(int, int, int);
};
int x = 1;
Bar bar(int(x), int(x), int{x}); // #1
cp_parser_parameter_declaration_list does
On 2022-04-21 09:11, Kaz Kylheku wrote:
> libcpp/ChangeLog
> 2022-04-21 Kaz Kylheku
>
> This change introduces a pair of related macros
> __EXP_COUNTER__ and __UEXP_COUNTER__. These macros access
> integer values which enumerate macro expansions.
> They can be used for
This patch fixes the second half of 64679. Here we issue a wrong
"redefinition of 'int x'" for the following:
struct Bar {
Bar(int, int, int);
};
int x = 1;
Bar bar(int(x), int(x), int{x}); // #1
cp_parser_parameter_declaration_list does pushdecl every time it sees
a named
On Tue, May 03, 2022 at 04:43:05PM -0400, Jason Merrill via Gcc-patches wrote:
> On 5/2/22 12:18, Marek Polacek wrote:
> > Consider
> >
> >struct F {
> > F(int) {}
> > F operator()(int) const { return *this; }
> >};
> >
> > and
> >
> >F(i)(0)(0);
> >
> > where we're
If the index of a constructor_elt is a FIELD_DECL, the CONSTRUCTOR is
already reshaped, so we can save time and memory by returning immediately.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
* decl.cc (reshape_init): Shortcut already-reshaped init.
On 5/4/22 10:09, Patrick Palka wrote:
Here we're crashing from maybe_aggr_guide ultimately because
processing_template_decl isn't set when partially instantiating the
guide's parameter list. This causes us to prematurely force completion
of the dependent type Visitor_functior, which fails and
> On 4 May 2022, at 20:14, Martin Liška wrote:
>
> Right now, when a \$x escape sequence occures, the
> next character after $x is skipped, which is bogus.
>
> The code has very low coverage right now.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to
Right now, when a \$x escape sequence occures, the
next character after $x is skipped, which is bogus.
The code has very low coverage right now.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
*
On 1/14/22 22:56, Jason Merrill wrote:
On 1/14/22 16:49, David Malcolm wrote:
On Mon, 2021-12-13 at 09:58 -0500, Jason Merrill via Gcc-patches wrote:
On 12/13/21 06:02, Jonathan Wakely wrote:
On Sun, 12 Dec 2021 at 05:39, Jason Merrill mailto:ja...@redhat.com>> wrote:
>
> In reading C++
There's no reason to call cxx_printable_name_translate here instead of using
%D in the format string.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
* error.c (cp_print_error_function): Use %qD.
(function_category): Use %qD.
---
gcc/cp/error.cc | 29
On 5/3/22 15:32, Joseph Myers wrote:
On Mon, 2 May 2022, David Faust via Gcc-patches wrote:
Consider the following example:
#define __typetag1 __attribute__((btf_type_tag("tag1")))
#define __typetag2 __attribute__((btf_type_tag("tag2")))
#define __typetag3
On Fri, Feb 18, 2022 at 11:13:16PM +, Hafiz Abid Qadeer wrote:
> An allocate clause in target region must specify an allocator
> unless the compilation unit has requires construct with
> dynamic_allocators clause. Current implementation of the allocate
> clause did not check for this
Hi Jakub,
On 04.05.22 14:03, Jakub Jelinek wrote:
On Wed, Apr 20, 2022 at 03:19:38PM +0200, Tobias Burnus wrote:
--- a/gcc/omp-low.cc
+++ b/gcc/omp-low.cc
@@ -13656,26 +13656,30 @@ lower_omp_target (gimple_stmt_iterator *gsi_p,
omp_context *ctx)
new_var = lookup_decl (var, ctx);
On Wed, May 04, 2022 at 06:16:14PM +0200, Tobias Burnus wrote:
> See also https://gcc.gnu.org/gcc-12/changes.html#languages and
> https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html#index-foffload
>
> -foffload= was never officially documented, albeit most users will
> have encountered it.
See also https://gcc.gnu.org/gcc-12/changes.html#languages and
https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html#index-foffload
-foffload= was never officially documented, albeit most users will
have encountered it. Since GCC 12 it is - but the -foffload=-
part is officially only handled
On 5/4/22 11:15, Marek Polacek wrote:
On Tue, May 03, 2022 at 04:46:11PM -0400, Jason Merrill wrote:
On 5/3/22 16:43, Jakub Jelinek wrote:
On Tue, May 03, 2022 at 04:26:51PM -0400, Jason Merrill wrote:
On 5/2/22 12:19, Marek Polacek wrote:
This patch fixes an oversight whereby we treated >=
On 04.05.22 17:12, Jakub Jelinek via Gcc-patches wrote:
Though, there is one gotcha, if we had code where we parsed some var first
and another one later and there was interdependence between the two, in
environ they can appear in any order.
I think for interdependence it depends whether in a
On Tue, May 03, 2022 at 04:46:11PM -0400, Jason Merrill wrote:
> On 5/3/22 16:43, Jakub Jelinek wrote:
> > On Tue, May 03, 2022 at 04:26:51PM -0400, Jason Merrill wrote:
> > > On 5/2/22 12:19, Marek Polacek wrote:
> > > > This patch fixes an oversight whereby we treated >= as the end of
> > > > a
On Tue, Jan 18, 2022 at 05:10:47PM +0100, Marcel Vollweiler wrote:
> Hi,
>
> This patch considers the environment variable syntax extension for
> device-specific variants of environment variables from OpenMP 5.1 (see
> OpenMP 5.1 specification, p. 75 and p. 639). An environment variable
> (e.g.
On Wed, 4 May 2022 15:31:32 +0200
Martin Liška wrote:
> On 5/4/22 15:10, Alexander Monakov wrote:
> > On Wed, 4 May 2022, Martin Liška wrote:
> >
> >> On 5/4/22 14:32, Alexander Monakov wrote:
> >>> On Wed, 4 May 2022, Martin Liška wrote:
> >>>
> The patch is a follow-up of the
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'cpplib' has been submitted
by the Spanish team of translators. The file is available at:
https://translationproject.org/latest/cpplib/es.po
(This file,
cpplib-12.1-b20220213.es.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'cpplib' has been submitted
by the Spanish team of translators. The file is available at:
https://translationproject.org/latest/cpplib/es.po
(This file,
cpplib-12.1-b20220213.es.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.
> Yes this looks good to me (still needs maintainer approval).
Thanks again Wilco for your review.
> One minor nitpick,
> a few of the tests check for __aarch64_cas2 - this should be
> __aarch64_cas2_sync.
Fixed in the attached patch.
> Note the patch still needs an appropriate commit
On 5/4/22 15:20, Andreas Schwab wrote:
> On Mai 04 2022, Martin Liška wrote:
>
>> diff --git a/gcc/gengtype-state.cc b/gcc/gengtype-state.cc
>> index ea566af3249..dfd9ea52785 100644
>> --- a/gcc/gengtype-state.cc
>> +++ b/gcc/gengtype-state.cc
>> @@ -473,43 +473,43 @@ read_a_state_token (void)
>>
Here we're crashing from maybe_aggr_guide ultimately because
processing_template_decl isn't set when partially instantiating the
guide's parameter list. This causes us to prematurely force completion
of the dependent type Visitor_functior, which fails and results in
an unexpected error_mark_node.
Jakub pointed out that cdtor_label is unnecessary, we should get all the
desired semantics with a normal return.
Tested x86_64-pc-linux-gnu and arm-eabi//arm-sim, applying to trunk.
gcc/cp/ChangeLog:
* cp-tree.h (struct language_function): Remove x_cdtor_label.
(cdtor_label,
On 04/05/2022 12:14, Richard Biener wrote:
On Wed, May 4, 2022 at 12:16 PM Richard Earnshaw via Gcc-patches
wrote:
Gimple isel already handles x CMP y ? -1 : 0 when lowering vector cond
operations, but this can be generalized further when the comparison
forms a natural mask so that we can
On 5/4/22 15:10, Alexander Monakov wrote:
> On Wed, 4 May 2022, Martin Liška wrote:
>
>> On 5/4/22 14:32, Alexander Monakov wrote:
>>> On Wed, 4 May 2022, Martin Liška wrote:
>>>
The patch is a follow-up of the discussion we've got in:
On Mai 04 2022, Martin Liška wrote:
> diff --git a/gcc/gengtype-state.cc b/gcc/gengtype-state.cc
> index ea566af3249..dfd9ea52785 100644
> --- a/gcc/gengtype-state.cc
> +++ b/gcc/gengtype-state.cc
> @@ -473,43 +473,43 @@ read_a_state_token (void)
> {
> case 'a':
>
On Wed, 4 May 2022, Richard Sandiford wrote:
> Richard Biener writes:
> > The testcase shows that we can end up with a contiguous access across
> > loop iterations but by means of permutations the elements accessed
> > might only cover parts of a vector. In this case we end up with
> >
On Wed, 4 May 2022, Martin Liška wrote:
> On 5/4/22 14:32, Alexander Monakov wrote:
> > On Wed, 4 May 2022, Martin Liška wrote:
> >
> >> The patch is a follow-up of the discussion we've got in:
> >> https://gcc.gnu.org/pipermail/gcc-patches/2022-May/593901.html
> >>
> >> Mold linker would
Richard Biener writes:
> The testcase shows that we can end up with a contiguous access across
> loop iterations but by means of permutations the elements accessed
> might only cover parts of a vector. In this case we end up with
> GROUP_GAP == 0 but still need to avoid accessing excess elements
gcc/ChangeLog:
* gengtype-state.cc (read_a_state_token): Remove dead code.
* ipa-profile.cc (ipa_profile_read_summary_section): Likewise.
---
gcc/gengtype-state.cc | 22 +++---
gcc/ipa-profile.cc| 1 -
2 files changed, 11 insertions(+), 12 deletions(-)
diff
On 5/4/22 14:32, Alexander Monakov wrote:
> On Wed, 4 May 2022, Martin Liška wrote:
>
>> The patch is a follow-up of the discussion we've got in:
>> https://gcc.gnu.org/pipermail/gcc-patches/2022-May/593901.html
>>
>> Mold linker would appreciate knowing in advance if get_symbols_v3 is
>>
On Fri, Mar 25, 2022 at 08:03:38PM -0600, Sandra Loosemore wrote:
> This patch adds support for OMP 5.1 "canonical loop nest form" to the
> Fortran front end, marks non-rectangular loops for processing
> by the middle end, and implements missing checks in the gimplifier
> for
On Wed, 4 May 2022, Martin Liška wrote:
> The patch is a follow-up of the discussion we've got in:
> https://gcc.gnu.org/pipermail/gcc-patches/2022-May/593901.html
>
> Mold linker would appreciate knowing in advance if get_symbols_v3 is supported
> by a GCC plug-in or not.
>
> Ready to be
The patch is a follow-up of the discussion we've got in:
https://gcc.gnu.org/pipermail/gcc-patches/2022-May/593901.html
Mold linker would appreciate knowing in advance if get_symbols_v3 is supported
by a GCC plug-in or not.
Ready to be installed?
Thanks,
Martin
lto-plugin/ChangeLog:
*
On Wed, Apr 20, 2022 at 03:19:38PM +0200, Tobias Burnus wrote:
> For array-descriptor vars, the descriptor is assigned to a temporary. However,
> this failed when the clause's argument was in turn in a data-sharing clause
> as the outer context's VALUE_EXPR wasn't used.
>
> gcc/ChangeLog:
>
>
In PR105049 we had
return VIEW_CONVERT_EXPR( VEC_PERM_EXPR < {<<< Unknown tree:
compound_literal_expr
V D.1984 = { 0 }; >>>, { 0 }} , {<<< Unknown tree: compound_literal_expr
V D.1985 = { 0 }; >>>, { 0 }} , { 0, 0 } > & {(short int) SAVE_EXPR
, (short int) SAVE_EXPR });
On Wed, May 4, 2022 at 12:16 PM Richard Earnshaw via Gcc-patches
wrote:
>
>
> Gimple isel already handles x CMP y ? -1 : 0 when lowering vector cond
> operations, but this can be generalized further when the comparison
> forms a natural mask so that we can also handle x CMP y ? z : 0 by
>
Gimple isel already handles x CMP y ? -1 : 0 when lowering vector cond
operations, but this can be generalized further when the comparison
forms a natural mask so that we can also handle x CMP y ? z : 0 by
transforming it into (x CMP y) & z. This will, in most cases save
having to load a
The testcase shows that we can end up with a contiguous access across
loop iterations but by means of permutations the elements accessed
might only cover parts of a vector. In this case we end up with
GROUP_GAP == 0 but still need to avoid accessing excess elements
in the last loop iterations.
On Wed, May 04, 2022 at 10:57:57AM +0200, Richard Biener wrote:
> On Wed, 4 May 2022, Jakub Jelinek wrote:
>
> > Hi!
> >
> > Somebody complained on IRC that when writing a new backend one can get
> > an error while compiling build/gencondmd.cc.
> > The problem is that when host compiler is g++ 3
On Wed, 4 May 2022, Jakub Jelinek wrote:
> Hi!
>
> Somebody complained on IRC that when writing a new backend one can get
> an error while compiling build/gencondmd.cc.
> The problem is that when host compiler is g++ 3 or later (or when
> bootstrapping), we compile it with g++ -std=c++11
Hi Tom!
On 2022-04-01T13:23:06+0200, Tom de Vries wrote:
> When running test-case libgomp.oacc-c-c++-common/vector-length-128-7.c on an
> RTX A2000 (sm_86) with driver 510.60.02 I run into:
> ...
> FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/vector-length-128-7.c \
>
On 5/4/22 10:03, Kyrylo Tkachov wrote:
-Original Message-
From: Gcc-patches On Behalf Of Christophe
Lyon via Gcc-patches
Sent: Wednesday, May 4, 2022 8:51 AM
To: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] arm: Restrict support of vectors of boolean immediates
(PR target/104662)
Hi!
Somebody complained on IRC that when writing a new backend one can get
an error while compiling build/gencondmd.cc.
The problem is that when host compiler is g++ 3 or later (or when
bootstrapping), we compile it with g++ -std=c++11 -pedantic and
the generated insn_conditions array contains
> -Original Message-
> From: Gcc-patches bounces+kyrylo.tkachov=arm@gcc.gnu.org> On Behalf Of Christophe
> Lyon via Gcc-patches
> Sent: Wednesday, May 4, 2022 8:51 AM
> To: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] arm: Restrict support of vectors of boolean immediates
> (PR
Supports change in libsanitizer where it newly reports:
READ of size 4 at 0xc3d4 tags: 02/01(00) (ptr/mem) in thread T0
So the 'tags' contains now 3 entries compared to 2 entries.
gcc/testsuite/ChangeLog:
* c-c++-common/hwasan/alloca-outside-caught.c: Update dg-output.
*
ping?
On 4/20/22 10:50, Christophe Lyon wrote:
This simple patch avoids the ICE described in the PR:
internal compiler error: in simd_valid_immediate, at config/arm/arm.cc:12866
with an early exit from simd_valid_immediate if we are trying to
handle a vector of booleans and MVE is not enabled.
On Tue, May 03, 2022 at 05:46:50PM -0700, Palmer Dabbelt wrote:
> This test was relying on undefined behavior, with -Wundef I get
>
> gcc/testsuite/gcc.dg/pr102892-1.c: In function 'main':
> cc/testsuite/gcc.dg/pr102892-1.c:14:18: warning: 'a' is used
> uninitialized [-Wuninitialized]
>
On Wed, May 4, 2022 at 2:47 AM Palmer Dabbelt wrote:
>
> This test was relying on undefined behavior, with -Wundef I get
>
> gcc/testsuite/gcc.dg/pr102892-1.c: In function 'main':
> cc/testsuite/gcc.dg/pr102892-1.c:14:18: warning: 'a' is used
> uninitialized [-Wuninitialized]
>14
61 matches
Mail list logo
