On 6/16/20 7:11 PM, H.J. Lu wrote:
On Tue, Jun 9, 2020 at 9:35 AM H.J. Lu wrote:
On Tue, May 26, 2020 at 6:27 AM Martin Liška wrote:
On 5/26/20 1:59 PM, H.J. Lu wrote:
On Tue, May 26, 2020 at 2:30 AM Martin Liška wrote:
On 5/25/20 7:42 PM, H.J. Lu wrote:
Here is the updated patch. OK
Hi,
When I am working on IFNs for vector with length, I noticed that the
current optab support query for mask_load/mask_store looks unexpected.
The mask_load/mask_store requires two modes for convert_optab query,
but the macros direct_mask_{load,store}_optab_supported_p uses
direct_optab_supported
On Tue, Jun 23, 2020 at 5:21 AM Richard Sandiford
wrote:
> MVE and Power both set inactive lanes to zero. But I'm not sure about RVV.
> AIUI, for RVV the approach instead would be to reduce the effective vector
> length for the final iteration of the vector loop, and I'm not sure
> whether in tha
Bootstrapped and regtested x86_64-redhat-linux, ppc64le-redhat-linux and
s390x-redhat-linux. I also ran SPEC 2006 and 2017 on these platforms,
and the only measurable regression was 3% in 520.omnetpp_r on ppc, which
went away after inserting a single nop at the beginning of
cDynamicExpression::eva
This patch adds some unit tests for omp-tools.h header. It also adds some simple
functions related to OMPD API versions. It also partially defines the OMPD
initialization function.
2020-06-23 Tony Sim
libgomp/ChangeLog:
* Makefile.am (toolexeclib_LTLIBRARIES and related): Add libgompd
95568 complains that CTAD for aggregates doesn't work within
requires-clause and it turned out that it doesn't work when we try
the deduction in a template. The reason is that maybe_aggr_guide
creates a guide that can look like this
template X(decltype (X::x))-> X
where the parameter is a decl
On Mon, 22 Jun 2020, Richard Sandiford wrote:
> OK, I've applied the below as (hopefully) obvious after testing
> on aarch64-linux-gnu.
>
>> I filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95805 and included
>> the relevant part of the build log.
>
> But I forgot about the PR, sorry, so didn
On Tue, Jun 23, 2020 at 04:47:42PM -0500, Bill Schmidt wrote:
> >Okay for trunk. Thanks! Also okay for backport to 10, if you want that.
>
> IMO, should backport to 9 and 8 also. It's a wrong-code problem.
Oh yes, certainly, for some reason I thought this wasn't there before
GCC 10 :-)
Seghe
In i386-builtins.c, arch_names_table is used to to map architecture name
string to internal model. A switch statement is used to map internal
processor name to architecture name string and internal priority.
model and priority are added to processor_alias_table so that a single
entry contains arc
Ups – old patch :-(
Correct one attached.
Tobias
On 6/23/20 11:41 PM, Tobias Burnus wrote:
Found when looking at another issue …
OK for the trunk?
Tobias
PS: Without the patch, it fails to compile with:
Error: Character ‘\U0001F600’ in string at (1) cannot be converted
into character kind 1
OK, and once again, thanks.
Jerry
On 6/17/20 12:27 PM, Harald Anlauf wrote:
Another corner case of buffer overflows during name mangling found by
Gerhard. We now check that the new buffer sizes suffice.
The patch is on top of the patches for PRs 95687, 95688, 95689.
Regtested on x86_64-pc-lin
Hi!
On Mon, Jun 15, 2020 at 04:37:47PM -0700, Carl Love wrote:
> * config/rs6000/altivec.md: (UNSPEC_EXTRACTL, UNSPEC_EXTRACTR)
No colon here.
> (vextractl, vextractr)
> (vextractl_internal, vextractr_internal)
> (VI2): Move to gcc/config/rs6000/vsx.md.
Will explaine
P2082R1 adjusted the rules for class template argument deduction for an
aggregate to better handle arrays and pack expansions.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
PR c++/93976
Implement C++20 P2082R1, Fixing CTAD for aggregates.
* cp-tree.h (T
On 6/23/20 4:36 PM, Segher Boessenkool wrote:
Hi!
On Tue, Jun 16, 2020 at 10:53:07AM -0500, will schmidt wrote:
target pr/94954
PR target/94954
* config/rs6000/altivec.h (vec_pack_to_short_fp32) Update.
Colon?
* config/rs6000/rs6000-call.c (P9V_BUILTIN_VEC_CONVERT_4F32_8F16)
OK, and thanks for Patch.
On 6/23/20 2:08 PM, Harald Anlauf wrote:
Dear all,
here's another case with a buffer that did overflow.
Regtested on x86_64-pc-linux-gnu.
OK for master / backports?
Thanks,
Harald
PR fortran/95827 - Buffer overflows with PDTs and long symbols
With submodules and
Found when looking at another issue …
OK for the trunk?
Tobias
PS: Without the patch, it fails to compile with:
Error: Character ‘\U0001F600’ in string at (1) cannot be converted into
character kind 1
Error: Operands of comparison operator ‘/=’ at (1) are
CHARACTER(3)/CHARACTER(3,4)
Hi!
On Tue, Jun 16, 2020 at 10:53:07AM -0500, will schmidt wrote:
> target pr/94954
PR target/94954
> * config/rs6000/altivec.h (vec_pack_to_short_fp32) Update.
Colon?
> * config/rs6000/rs6000-call.c (P9V_BUILTIN_VEC_CONVERT_4F32_8F16): New
> overloaded builtin entry.
Only one
Dear all,
here's another case with a buffer that did overflow.
Regtested on x86_64-pc-linux-gnu.
OK for master / backports?
Thanks,
Harald
PR fortran/95827 - Buffer overflows with PDTs and long symbols
With submodules and coarrays, name mangling results in long internal
symbols. Enlarge int
Dear all,
here's another fix for a buffer overflow with long symbols.
OK for master / backports?
Regtested on x86_64-pc-linux-gnu.
Thanks,
Harald
PR fortran/95826 - Buffer overflows with PDTs and long symbols
With PDTs (parameterized derived types), name mangling results in variably
long int
On Tue, 23 Jun 2020 at 15:28, Andre Vieira (lists)
wrote:
>
> On 23/06/2020 13:10, Kyrylo Tkachov wrote:
> >
> >> -Original Message-
> >> From: Andre Vieira (lists)
> >> Sent: 22 June 2020 09:52
> >> To: gcc-patches@gcc.gnu.org
> >> Cc: Kyrylo Tkachov
> >> Subject: [PATCH][GCC][Arm] PR t
Hello,
I needed to test [1] on AIX and OpenBSD and noticed
download_prerequisites doesn't work there. The attached patch fixes
it.
OK for master?
Best regards,
Ilya
[1] https://gcc.gnu.org/pipermail/gcc-patches/2020-June/548182.html
---
contrib/ChangeLog:
2020-06-11 Ilya Leoshkevich
On 6/18/20 5:48 PM, will schmidt wrote:
On Thu, 2020-06-18 at 17:01 -0500, Bill Schmidt wrote:
Thanks for the review, Will! Responses below...
On 6/18/20 11:08 AM, will schmidt wrote:
On Wed, 2020-06-17 at 14:46 -0500, Bill Schmidt wrote:
I posted a version of these patches back in stage 4 (
On 23/06/2020 20:36, Thomas Schwinge wrote:
Eventually (not now...), instead of special-casing more and more options
(I somehow doubt that '-fpic', '-fPIC' are the only ones?), shouldn't we
solve this in some more generic way, like re-invoking the host compiler
exactly as invoked before (if that
From: Nicholas Krause
This fixes the PR95672 by adding the missing TYPE_PACK_EXPANSION case in
cxx_incomplete_type_diagnostic in order to avoid ICES on diagnosing
incomplete template pack expansion cases. In v2, add the missing required
test case for all new patches. v3 Fixes both the test case t
Hi!
On 2020-06-23T17:21:06+0200, Tobias Burnus wrote:
> If the offloading code is (only) in a library, one can come up
> with the idea to build those parts as shared library – and link
> it to the nonoffloading code.(*)
> (*) Thomas mentioned that this is supposed to work also in more
> complex
On 6/23/20 1:27 PM, Marco Elver wrote:
Is this one good to go, or any objections?
Hello.
Thanks for it, it's fine. Please install it.
Martin
The correct subject should be more like
c++: Handle TYPE_PACK_EXPANSION in cxx_incomplete_type_diagnostic [PR95672]
See git log --oneline for examples.
On Tue, Jun 23, 2020 at 03:11:44PM -0400, Nicholas Krause via Gcc-patches wrote:
> From: Nicholas Krause
>
> This fixs the PR95672 by adding th
From: Nicholas Krause
This fixs the PR95672 by adding the missing TYPE_PACK_EXPANSION case in
cxx_incomplete_type_diagnostic in order to avoid ICES on diagnosing
incomplete template pack expansion cases. In v2, add the missing required
test case for all new patches. v3 Fixes both the test case to
Hi!
On Tue, Jun 23, 2020 at 01:25:42PM -0500, Aaron Sawdey via Gcc-patches wrote:
> Update config.gcc so that we can use --with-cpu=power10.
> * config.gcc: Identify power10 as a 64-bit processor and as valid
> for --with-cpu and --with-tune.
> diff --git a/gcc/config.gcc b/gcc/confi
Update config.gcc so that we can use --with-cpu=power10.
I've tested that this does do the expected thing
with --with-cpu=power10 and also that it still builds and
bootstraps correctly using --with-cpu=power9 on power9. If there isn't
any other testing I need to do for this, ok for trunk?
Thanks
On 6/23/20 8:27 AM, Marek Polacek wrote:
On Mon, Jun 22, 2020 at 11:11:48PM -0400, Nicholas Krause wrote:
On 6/22/20 10:01 PM, Marek Polacek wrote:
On Mon, Jun 22, 2020 at 09:42:51PM -0400, Nicholas Krause via Gcc-patches wrote:
From: Nicholas Krause
This fixs the PR95672 by adding the mis
Matthew Malcomson writes:
> On 23/06/2020 16:48, Richard Sandiford wrote:
>> Matthew Malcomson writes:
>>> @@ -14466,6 +14466,81 @@ aarch64_validate_mcpu (const char *str, const
>>> struct processor **res,
>>> return false;
>>> mfix-cortex-a53-835769
>>> Target Report Var(aarch64_fix_a53
Dmitrij Pochepko writes:
> + unsigned int encoded_nelts = d->perm.encoding ().encoded_nelts ();
> + for (unsigned int i = 0; i < encoded_nelts; ++i)
> +if (!d->perm[i].is_constant ())
> + return false;
I think it would be better to test this as part of the loop below.
> +
> + /* to_c
On 23/06/2020 16:48, Richard Sandiford wrote:
Matthew Malcomson writes:
@@ -14466,6 +14466,81 @@ aarch64_validate_mcpu (const char *str, const struct
processor **res,
return false;
mfix-cortex-a53-835769
Target Report Var(aarch64_fix_a53_err835769) Init(2) Save
Workaround for ARM Cor
On 23/06/2020 17:56, Richard Sandiford wrote:
Matthew Malcomson writes:
On 23/06/2020 17:17, Richard Sandiford wrote:
Matthew Malcomson writes:
--- a/gcc/config/aarch64/aarch64-protos.h
+/* Ensure there are no BR or RET instructions which are not directly followed
+ by a speculation barrie
Matthew Malcomson writes:
> On 23/06/2020 17:17, Richard Sandiford wrote:
>> Matthew Malcomson writes:
>>> --- a/gcc/config/aarch64/aarch64-protos.h
>>> +/* Ensure there are no BR or RET instructions which are not directly
>>> followed
>>> + by a speculation barrier. */
>>> +/* { dg-final { s
Sorry for the slow review.
Dmitrij Pochepko writes:
> @@ -20074,6 +20076,83 @@ aarch64_evpc_trn (struct expand_vec_perm_d *d)
>return true;
> }
>
> +/* Try to re-encode the PERM constant so it use the bigger size up.
> + This rewrites constants such as {0, 1, 4, 5}/V4SF to {0, 2}/V2DI.
>
On Tue, Jun 23, 2020 at 06:44:26PM +0200, Thomas Schwinge wrote:
> On 2020-06-15T21:28:12+0100, Kwok Cheung Yeung wrote:
> > This patch adds support on nvptx for __sync_val_compare_and_swap operations
> > on
> > 1- and 2-byte values.
>
> Is this a thorough review that these are the only function
On 23/06/2020 17:17, Richard Sandiford wrote:
Matthew Malcomson writes:
--- a/gcc/config/aarch64/aarch64-protos.h
+/* Ensure there are no BR or RET instructions which are not directly followed
+ by a speculation barrier. */
+/* { dg-final { scan-assembler-not
"\t(br|ret|retaa|retab)\tx\[0-9
Hi!
On 2020-06-15T21:28:12+0100, Kwok Cheung Yeung wrote:
> This patch adds support on nvptx for __sync_val_compare_and_swap operations on
> 1- and 2-byte values.
Is this a thorough review that these are the only functions missing, or
did you just implement what you found missing for some test c
Hi Nick.
libctf wants a bsearch that takes a void * arg pointer to avoid a
nonportable use of __thread.
bsearch_r is required, not optional, at this point because as far as I
can see this obvious-sounding function is not implemented by anyone's
libc. We can easily move
The problem is that Has_Constrained_Partial_View must be tested on the base
type of the designated type of an allocator.
Tested on x86-64/Linux, applied on all active branches.
2020-06-23 Eric Botcazou
* gcc-interface/trans.c (gnat_to_gnu) : Minor tweaks.
Call Has_Constraine
This makes it possible for global dynamic types to reference the DIE of these
integral variables.
Tested on x86-64/Linux, applied on the mainline.
2020-06-23 Eric Botcazou
* gcc-interface/utils.c (gnat_write_global_declarations): Output the
integral global variables first an
The main changes are 1) the bulk of the implementation is put back entirely in
gnat_to_gnu_entity and 2) the handling of lvalues is unified, i.e. no longer
depends on the Materialize_Entity flag being present on the entity.
Tested on x86-64/Linux, applied on the mainline.
2020-06-23 Eric Botc
This changes the compiler to emit debug info for user-defined subtypes even
with -fgnat-encodings=minimal, as they might be needed by the debugger.
Tested on x86-64/Linux, applied on the mainline.
2020-06-23 Eric Botcazou
* gcc-interface/decl.c (gnat_to_gnu_entity) : Set
the
Matthew Malcomson writes:
> diff --git a/gcc/config/aarch64/aarch64.h b/gcc/config/aarch64/aarch64.h
> index
> f996472d6990b7709602ae93f7a2cb7daa0e84b0..9795c929b8733f89722d3660456f5e7d6405d902
> 100644
> --- a/gcc/config/aarch64/aarch64.h
> +++ b/gcc/config/aarch64/aarch64.h
> @@ -643,6 +643,16
Matthew Malcomson writes:
> --- a/gcc/config/aarch64/aarch64-protos.h
> +++ b/gcc/config/aarch64/aarch64-protos.h
> @@ -780,6 +780,7 @@ extern const atomic_ool_names aarch64_ool_ldeor_names;
>
> tree aarch64_resolve_overloaded_builtin_general (location_t, tree, void *);
>
> +const char * aarc
libctf wants a bsearch that takes a void * arg pointer to avoid a
nonportable use of __thread.
bsearch_r is required, not optional, at this point because as far as I
can see this obvious-sounding function is not implemented by anyone's
libc. We can easily move it to AC_LIBOBJ later if it proves n
Adding AArch64 maintainers.
> -Original Message-
> From: Gcc-patches On Behalf Of Dmitrij
> Pochepko
> Sent: Thursday, June 11, 2020 12:22 PM
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH][RFC] __builtin_shuffle sometimes should produce zip1
> rather than TBL (PR82199)
>
> The followin
Adding AArch64 maintainers,
Also Dmitrij the patch lacks a changelog.
> -Original Message-
> From: Gcc-patches On Behalf Of Dmitrij
> Pochepko
> Sent: Wednesday, June 17, 2020 10:09 AM
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH][RFC] vector creation from two parts of two vectors
> pr
Matthew Malcomson writes:
> @@ -14466,6 +14466,81 @@ aarch64_validate_mcpu (const char *str, const struct
> processor **res,
>return false;
> }
>
> +
Should just be one blank line here.
> +/* Straight line speculation indicators. */
> +enum aarch64_sls_hardening_type
> +{
> +SLS_NON
On Tue, Jun 23, 2020 at 11:35:21AM -0400, David Edelsohn wrote:
> This patch removes ifneq from Makefile fragments in gcc/Makefile.in
> and empty.mk in libgcc/Makefile.in.
>
> GNU Make supports the "-include" keyword to prevent warnings and errors due to
> inclusion of non-existent files. This pa
This patch removes ifneq from Makefile fragments in gcc/Makefile.in
and empty.mk in libgcc/Makefile.in.
GNU Make supports the "-include" keyword to prevent warnings and errors due to
inclusion of non-existent files. This patch changes gcc/ and libgcc/ to use
"-include" in place of the historical
On 23/06/2020 16:21, Tobias Burnus wrote:
If the offloading code is (only) in a library, one can come up
with the idea to build those parts as shared library – and link
it to the nonoffloading code.(*)
Currently, this fails as the mkoffload calls the nonoffloading
compiler without the -fpic/-fPI
From: Sunil K Pandey
Default for this hook is NOP. For x86, in 32 bit mode, this hook
sets alignment of long long on stack to 32 bits if preferred stack
boundary is 32 bits.
- This patch fixes
gcc.target/i386/pr69454-2.c
gcc.target/i386/stackalign/longlong-1.c
- Regression test
If the offloading code is (only) in a library, one can come up
with the idea to build those parts as shared library – and link
it to the nonoffloading code.(*)
Currently, this fails as the mkoffload calls the nonoffloading
compiler without the -fpic/-fPIC flags, even though the compiler
was origi
This patch introduces the mitigation for Straight Line Speculation past
the BLR instruction.
This mitigation replaces BLR instructions with a BL to a stub which uses
a BR to jump to the original value. These function stubs are then
appended with a speculation barrier to ensure no straight line
sp
libctf wants a bsearch that takes a void * arg pointer to avoid a
nonportable use of __thread.
bsearch_r is required, not optional, at this point because as far as I
can see this obvious-sounding function is not implemented by anyone's
libc. We can easily move it to AC_LIBOBJ later if it proves n
On Jun 8, 2020, Alexandre Oliva wrote:
> * outputs.exp (skip_lto): Set when missing the linker plugin.
I withdraw the above work-around patch in favor of the fix proper below.
It's also supposed to fix the FAILs caused by .dSYM directories on
platforms that create them; I'd appreciate co
> -Original Message-
> From: Andre Vieira (lists)
> Sent: 23 June 2020 14:28
> To: Kyrylo Tkachov ; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH][GCC][Arm] PR target/95646: Do not clobber callee saved
> registers with CMSE
>
> On 23/06/2020 13:10, Kyrylo Tkachov wrote:
> >
> >> -Or
On 23/06/2020 13:10, Kyrylo Tkachov wrote:
-Original Message-
From: Andre Vieira (lists)
Sent: 22 June 2020 09:52
To: gcc-patches@gcc.gnu.org
Cc: Kyrylo Tkachov
Subject: [PATCH][GCC][Arm] PR target/95646: Do not clobber callee saved
registers with CMSE
Hi,
As reported in bugzilla wh
On 6/12/20 4:06 PM, Iain Sandoe wrote:
Iain Sandoe wrote:
Nathan Sidwell wrote:
On 6/8/20 5:17 AM, Iain Sandoe wrote:
+ r = gro_is_void_p ? integer_zero_node : rvalue (gro);
+ /* The return object is constructed, even if the gro is void. */
Would error_mark_node work here?
On Mon, Jun 22, 2020 at 11:11:48PM -0400, Nicholas Krause wrote:
>
>
> On 6/22/20 10:01 PM, Marek Polacek wrote:
> > On Mon, Jun 22, 2020 at 09:42:51PM -0400, Nicholas Krause via Gcc-patches
> > wrote:
> > > From: Nicholas Krause
> > >
> > > This fixs the PR95672 by adding the missing TYPE_PAC
Richard Biener writes:
> On Tue, Jun 23, 2020 at 11:53 AM Richard Sandiford
> wrote:
>>
>> Things have moved on due to the IRC conversation, but…
>>
>> "Kewen.Lin" writes:
>> > on 2020/6/23 上午3:59, Richard Sandiford wrote:
>> >> "Kewen.Lin" writes:
>> >>> @@ -5167,6 +5167,24 @@ mode @var{n}.
>>
> -Original Message-
> From: Andre Vieira (lists)
> Sent: 22 June 2020 09:52
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov
> Subject: [PATCH][GCC][Arm] PR target/95646: Do not clobber callee saved
> registers with CMSE
>
> Hi,
>
> As reported in bugzilla when the -mcmse option is
Hi,
On Tue, Jun 23 2020, Alexandre Oliva wrote:
> Hello, Thomas,
>
> On Jun 9, 2020, Thomas Schwinge wrote:
>
>> We're trying to scan 'variables.hsail.brig.*', but for input file name
>> 'variables.hsail.brig', we're now creating:
>
> I understand this was fixed by Martin Jambor's last week's pa
On Fri, 19 Jun 2020 at 14:25, Marco Elver wrote:
>
> Document TSAN changes to support alternative runtimes, such as KCSAN.
Is this one good to go, or any objections?
Thanks,
-- Marco
> ---
> htdocs/gcc-11/changes.html | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/
On Tue, Jun 23, 2020 at 11:53 AM Richard Sandiford
wrote:
>
> Things have moved on due to the IRC conversation, but…
>
> "Kewen.Lin" writes:
> > on 2020/6/23 上午3:59, Richard Sandiford wrote:
> >> "Kewen.Lin" writes:
> >>> @@ -5167,6 +5167,24 @@ mode @var{n}.
> >>>
> >>> This pattern is not allo
Hi Jason!
On 2020-05-22T17:03:01-0400, Jason Merrill via Gcc-patches
wrote:
> [...]
>
> This issue suggests that we should be running the ubsan tests in multiple
> standard modes like the rest of the G++ testsuite, so I've made that change
> as well.
> --- a/gcc/testsuite/g++.dg/ubsan/ubsan.exp
Also test with an enumeration type. Move the dg-error directives outside
the #if block, because DejaGnu would process them whether or not wchar_t
support is present.
libstdc++-v3/ChangeLog:
* testsuite/20_util/from_chars/1_c++20_neg.cc: Check enumeration
type.
* testsuite/
Things have moved on due to the IRC conversation, but…
"Kewen.Lin" writes:
> on 2020/6/23 上午3:59, Richard Sandiford wrote:
>> "Kewen.Lin" writes:
>>> @@ -5167,6 +5167,24 @@ mode @var{n}.
>>>
>>> This pattern is not allowed to @code{FAIL}.
>>>
>>> +@cindex @code{lenload@var{m}} instruction p
On Jun 9, 2020, Thomas Schwinge wrote:
> Previously, for '-foffload=nvptx-none -foffload=-fdump-rtl-mach
> -save-temps -o ./nvptx-merged-loop.exe', GCC produced the expected
> 'nvptx-merged-loop.o.307r.mach'.
I believe the patch I've just installed fixes the UNRESOLVED results
caused by not fin
Hello, Thomas,
On Jun 9, 2020, Thomas Schwinge wrote:
> We're trying to scan 'variables.hsail.brig.*', but for input file name
> 'variables.hsail.brig', we're now creating:
I understand this was fixed by Martin Jambor's last week's patch for
brig.exp; can you please confirm whether the problem
G++ implements P1972R2 since r11-1597-0ca22d027ecc and so we no longer
need the P0608R3 special case to prevent narrowing conversions to bool.
Since non-GNU compilers don't necessarily implment P1972R2 yet, this
may cause a regression for those compilers. There is no feature-test
macro we can use
On Mon, 22 Jun 2020, Alexandre Oliva wrote:
> On Jun 22, 2020, Tobias Burnus wrote:
>
> > On 6/22/20 8:08 AM, Alexandre Oliva wrote:
> >>> I additionally did run the test case manually → files.log for the
> >>> produced files.
> >> This is with -save-temps, right?
>
> > Yes. Without, there are
libstdc++-v3/ChangeLog:
* doc/Makefile.in: Regenerate.
* include/Makefile.in: Regenerate.
* libsupc++/Makefile.in: Regenerate.
* po/Makefile.in: Regenerate.
* python/Makefile.in: Regenerate.
* src/Makefile.in: Regenerate.
* src/c++11/Makefile
On Tue, Jun 23, 2020 at 12:22 AM Martin Sebor via Gcc-patches
wrote:
>
> On 6/22/20 12:55 PM, Jason Merrill wrote:
> > On 6/22/20 1:25 PM, Martin Sebor wrote:
> >> The attached fix parallels the one for the equivalent C bug 95580
> >> where the pretty printers don't correctly handle MEM_REF argume
77 matches
Mail list logo
