On Mon, Feb 21, 2022 at 4:54 PM Richard Biener via Gcc-patches
wrote:
>
> The following fixes an omission in bool pattern detection that
> makes it fail when check_bool_pattern fails for COND_EXPR. That's
> not what it should do, instead it should still pattern recog
> to var != 0 even if no furt
The async call and future variable initialization may take a while to
complete on uniprocessors, especially if the async call and other
unrelated processes run before context switches back to the main
thread.
Taking steady_begin only then sometimes causes the 11*100ms in the
slow clock, counted
On Wed, 4 May 2022, Richard Earnshaw wrote:
>
>
> 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 gen
The testcase for pr100106, compiled with optimization for 32-bit
powerpc -mcpu=604 with -mstrict-align expands the initialization of a
union from a float _Complex value into a load from an SCmode
constant pool entry, aligned to 4 bytes, into a DImode pseudo,
requiring 8-byte alignment.
The patch
On Thu, May 5, 2022 at 8:15 AM Richard Biener
wrote:
>
> On Wed, May 4, 2022 at 3:31 PM 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š
On Wed, May 4, 2022 at 3:31 PM 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 discussion we'v
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 b
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);
> >};
> >
> >i
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
> gcc/tes
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 necessa
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 maybe_dependent_member_r
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 parameter
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 suppos
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.
(reshape_in
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 re
> 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 b
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:
* gengtype-state.
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++ di
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 __attribute__((btf_typ
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 restricti
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. S
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 >= a
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 fi
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 t
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. OM
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 discus
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-b202202
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-b202202
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 message
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, LABE
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:
https://gcc.gnu.org/pipermail/gcc-patches/2022-May/5
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
> > GROUP_GAP
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 appreci
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
>> support
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 additi
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 instal
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:
* l
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 });
where
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
> transfor
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 register
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. Pe
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 -pedanti
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 \
> -DACC_DEVICE_TYPE_nvi
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 pai
> -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 tar
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.
65 matches
Mail list logo
