On Tue, Dec 1, 2020 at 8:49 PM Qing Zhao wrote:
>
> Hi, Richard,
>
> Could you please comment on the following approach:
>
> Instead of adding the zero-initializer quite late at the pass “pass_expand”,
> we can add it as early as during gimplification.
> However, we will mark these new added zero
On Tue, Dec 1, 2020 at 9:04 PM Martin Liška wrote:
>
> On 12/1/20 8:57 PM, Jakub Jelinek wrote:
> > Would be better to use \[^\n\r]\* instead of .*, with .* you can match parts
> > even from completely different parts of the dump file.
>
> Thank you Jakub! I've just pushed a patch with that.
Mayb
Hey.
I see the current help description of GCC hooks not much useful:
$ help user-defined
break-on-diagnostic -- Put a breakpoint on diagnostic_show_locus, called
whenever a diagnostic
break-on-saved-diagnostic -- Put a breakpoint on
ana::diagnostic_manager::add_diagnostic, called within
dot-f
It's a simple fix of a division by zero.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
PR c/98087
* gimple-fold.c (clear_padding_type): Do not divide by zero.
gcc/testsuite/ChangeLog:
PR c/9
Hi Segher,
on 2020/12/1 上午4:49, Segher Boessenkool wrote:
> Hi!
>
> On Mon, Nov 30, 2020 at 06:36:30PM +0800, Kewen.Lin wrote:
>> --- a/gcc/config/rs6000/rs6000-cpus.def
>> +++ b/gcc/config/rs6000/rs6000-cpus.def
>> @@ -51,7 +51,6 @@
>> | OPTION_MASK_CRYPTO
Hi,
This patch is to use paradoxical subreg instead of
zero_extend for promoting QI/HI to SI/DI when we
want to construct one vector with these modes.
Since we do the gpr->vsx movement and vector merge
or pack later, the high part is useless and safe to
use paradoxical subreg. It can avoid useles
Hi,
On Wed, 2 Dec 2020, Martin Liška wrote:
> Hey.
>
> I see the current help description of GCC hooks not much useful:
>
> $ help user-defined
[snip]
> trt -- GCC hook: trt [tree]
>
> It's quite hard to be familiar what each hooks means and rather suggest:
>
[snip]
> trt -- GCC hook: TREE_TY
On Wed, Dec 02, 2020 at 10:25:32AM +0100, Martin Liška wrote:
> It's a simple fix of a division by zero.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Thanks,
> Martin
>
> gcc/ChangeLog:
>
> PR c/98087
> * gimple-fold.c (clea
On 12/2/20 10:47 AM, Alexander Monakov wrote:
Hi,
On Wed, 2 Dec 2020, Martin Liška wrote:
Hey.
I see the current help description of GCC hooks not much useful:
$ help user-defined
[snip]
trt -- GCC hook: trt [tree]
It's quite hard to be familiar what each hooks means and rather suggest:
On 12/2/20 11:11 AM, Jakub Jelinek wrote:
On Wed, Dec 02, 2020 at 10:25:32AM +0100, Martin Liška wrote:
It's a simple fix of a division by zero.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
PR c/98087
^PING
On 11/26/20 2:55 PM, Martin Liška wrote:
On 11/25/20 2:48 PM, Richard Biener wrote:
On Mon, Nov 23, 2020 at 2:02 PM Martin Liška wrote:
On 11/23/20 12:00 PM, Richard Biener wrote:
Can you split out the unifying of -[gf]record-gcc-switches processing
and the target hook adjustment from
This makes sure to not call maybe_set_vectorized_backedge_value when
we did not vectorize the latch def candidate.
Boostrapped and tested on x86_64-unknown-linux-gnu, pushed.
2020-12-02 Richard Biener
* tree-vect-loop.c (vect_transform_loop_stmt): Return whether
we vectorized
On Wed, 2020-12-02 at 08:15 +0100, Andreas Krebbel wrote:
> On 12/2/20 2:34 AM, Ilya Leoshkevich wrote:
> > Bootstrapped and regtesed on s390x-redhat-linux. There are slight
> > improvements in all SPEC benchmarks, no regressions that could not
> > be
> > "fixed" by adding nops. Ok for master?
>
gcc/testsuite/ChangeLog:
PR tree-optimization/98084
* gcc.dg/tree-ssa/pr98094.c: New test.
---
gcc/testsuite/gcc.dg/tree-ssa/pr98094.c | 21 +
1 file changed, 21 insertions(+)
create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr98094.c
diff --git a/gcc/testsu
On Tue, Dec 01, 2020 at 04:05:22PM -0500, Jason Merrill via Gcc-patches wrote:
> Or simpler might be to always defer immediate evaluation of
> source_location::current() until genericize time.
That works.
I had to change constexpr.c too so that it temporarily adjusts
current_function_decl from the
Hi Ian
Since the new gccgo mangling scheme, libgo compilation is broken on AIX (or in
Linux with -gstabs) because of a type symbol having a " in its name. I've made
a patch (see attachment) in order to fix stabstring generation, because, IMO,
it should be handled anyway.
However, it happens onl
libstdc++-v3/ChangeLog:
* include/ext/rope: Fix indentation of access specifiers.
Tested powerpc64le-linux. Committed to trunk.
commit d38fbb5a863dfc00631c74a525a908cef620e149
Author: Jonathan Wakely
Date: Wed Dec 2 11:25:42 2020
libstdc++: Fix indentation in rope
libstd
This fixes UBsan errors like:
/usr/include/c++/10/ext/ropeimpl.h:593:9: runtime error: member access within
null pointer of type 'struct _RopeRep'
/usr/include/c++/10/ext/ropeimpl.h:593:9: runtime error: member call on null
pointer of type 'struct _Rope_rep_base'
/usr/include/c++/10/ext/rope:556
Hi!
On Tue, Dec 01, 2020 at 01:03:52PM +, Jonathan Wakely via Gcc-patches wrote:
> I mentioned in PR 80780 that a __builtin__PRETTY_FUNCTION would have
> been nice, because __FUNCTION__ isn't very useful for C++, because of
> overloading and namespace/class scopes. There are an unlimited numbe
On 01/12/20 10:52 +, Jonathan Wakely wrote:
On 01/12/20 10:45 +0100, Christophe Lyon wrote:
On Mon, 30 Nov 2020 at 15:58, Jonathan Wakely wrote:
On 27/11/20 21:17 +0100, Christophe Lyon via Libstdc++ wrote:
On Fri, 27 Nov 2020 at 17:13, Jonathan Wakely via Gcc-patches
wrote:
The defau
Hello.
We create an IPA SRA (which has DECL_IS_MALLOC set to false), but later
IPA pure const propagates malloc attributes. I think we should not set
it for a void returning functions.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
On Tue, Dec 01, 2020 at 01:48:31PM +0100, Jakub Jelinek via Gcc-patches wrote:
> I guess it depends on whether for 32-bit target and -gdwarf64, when
> calling dw2_assemble_integer with non-CONST_INT argument we only
> need positive values or might need negative ones too.
> Because positive ones can
On Tue, Dec 1, 2020 at 9:23 PM Jeff Law wrote:
>
>
>
> On 11/18/20 7:00 AM, H.J. Lu wrote:
> > On Sat, Nov 7, 2020 at 7:47 AM H.J. Lu wrote:
> >> On Sat, Oct 31, 2020 at 5:01 AM H.J. Lu wrote:
> >>> On Fri, Oct 23, 2020 at 5:41 AM H.J. Lu wrote:
> On Fri, Oct 2, 2020 at 6:00 AM H.J. Lu wr
On Tue, Dec 1, 2020 at 6:28 PM H. J. Lu wrote:
>
> New failures:
> FAIL: compiler driver --help=target option(s): "^ +-.*[^:.]$" absent from
> output: " -mneededEmit GNU_PROPERTY_X86_ISA_1_NEEDED GNU
> property"
> FAIL: compiler driver --help=target option(s): "^ +-.*[^:.]$"
This fixes SLP cycles leaking memory by maintaining a double-linked
list of allocatd SLP nodes we can zap when we free the alloc pool.
Bootstrap & regtest running on x86_64-unknown-linux-gnu.
2020-12-02 Richard Biener
PR tree-optimization/97630
* tree-vectorizer.h (_slp_tree::
> Hello.
>
> We create an IPA SRA (which has DECL_IS_MALLOC set to false), but later
> IPA pure const propagates malloc attributes. I think we should not set
> it for a void returning functions.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
Hi!
Apparently vec.h doesn't build with -std=c++20/gnu++20, since the
DR2237 r11-532 change.
template
class auto_delete_vec
{
private:
auto_vec_delete (const auto_delete_vec &) = delete;
};
which vec.h uses is invalid C++20, one needs to use
auto_vec_delete (const auto_delete_vec &) = delete;
This is modified from the original patch. firstly it contains a few
more necessary bits. But mainly I renamed the entities from
'MODULE_foo' to 'BINDING_foo', as it's a vector of bindings used by
modules (not a vector of modules). It also belongs in name-lookup.h.
Pushing to trunk
This add
On Wed, Dec 2, 2020 at 3:08 PM Jakub Jelinek via Gcc-patches
wrote:
>
> Hi!
>
> Apparently vec.h doesn't build with -std=c++20/gnu++20, since the
> DR2237 r11-532 change.
> template
> class auto_delete_vec
> {
> private:
> auto_vec_delete (const auto_delete_vec &) = delete;
> };
> which vec.h u
Bring in a few lines that are in binutils-gdb's .gitignore but not
gcc's.
Note that I don't have push access to gcc, so I would appreciate
if somebody could push it for me.
ChangeLog:
* .gitignore: Sync with binutils-gdb.
---
.gitignore | 7 +++
1 file changed, 7 insertions(+)
diff
Bootstrapped and regtested on s390x-redhat-linux. Ok for master?
v1: https://gcc.gnu.org/pipermail/gcc-patches/2020-December/560822.html
v1 -> v2:
- Use SYMBOL_REF_P.
- Fix usage of gcc_assert.
- Use GEN_INT.
Currently GCC loads large immediates into GPRs from the literal pool,
which is not a
On Tue, Dec 01, 2020 at 10:36:10PM +, Jonathan Wakely wrote:
> I've attached a complete patch including those generated files, and
> I've also pushed the branch to refs/users/redi/heads/ieee128-squash in
> the gcc.gnu.org Git repo. That branch includes your patch for PR
> libgcc/97543 which is
On Wed, Dec 02, 2020 at 01:13:26PM +0100, Jakub Jelinek via Gcc-patches wrote:
> On Tue, Dec 01, 2020 at 04:05:22PM -0500, Jason Merrill via Gcc-patches wrote:
> > Or simpler might be to always defer immediate evaluation of
> > source_location::current() until genericize time.
>
> That works.
> I
Hi,
On Wed, Dec 02 2020, Jan Hubicka wrote:
>> We create an IPA SRA (which has DECL_IS_MALLOC set to false), but later
>> IPA pure const propagates malloc attributes. I think we should not set
>> it for a void returning functions.
>>
>> Patch can bootstrap on x86_64-linux-gnu and survives regress
I'm not sure why this didn't pop up on the earlier bootstrap. Anyway,
fixed thusly.
I made the prefix for dumping a binding-vector slightly too small.
Fixed thusly.
gcc/cp/
* ptree.c (cxx_print_xnode): Increase binding-vector prefix size.
--
Nathan Sidwell
diff --git i/gcc/cp/
> On Dec 2, 2020, at 2:45 AM, Richard Biener wrote:
>
> On Tue, Dec 1, 2020 at 8:49 PM Qing Zhao wrote:
>>
>> Hi, Richard,
>>
>> Could you please comment on the following approach:
>>
>> Instead of adding the zero-initializer quite late at the pass “pass_expand”,
>> we can add it as early
The modules machinery needs to construct array types, and that wanted
to determine type dependency. That doesn't work during loading, but
the module loader can stream that fact too and tell the array builder.
Thus this extends the API to allow a caller to specify the dependency
explicitly. The c
We need to call the lang_decl and type_decl creators from the module
loading machinery. This makes them reachable.
gcc/cp/
* cp-tree.h (maybe_add_lang_decl_raw, maybe_add_lang_type_raw):
Declare.
* lex.c (maybe_add_lang_decl_raw, maybe_add_lang_type_raw):
On 12/2/20 7:13 AM, Jakub Jelinek wrote:
On Tue, Dec 01, 2020 at 04:05:22PM -0500, Jason Merrill via Gcc-patches wrote:
Or simpler might be to always defer immediate evaluation of
source_location::current() until genericize time.
That works.
I had to change constexpr.c too so that it temporari
This upgrades the ACATS tesuite present in ada/acats from 2.5 to latest 2.6,
removing 3 tests and adding 11 tests, some of them written very recently.
Tested on x86-64/Linux, SPARC64/Linux, PowerPC64/Linux and SPARC/Solaris,
applied on the mainline.
2020-12-02 Eric Botcazou
Upgrade
This Go frontend patch changes the parser to not advance past an
unexpected semicolon, after it gives an error. We've already read the
unexpected semicolon, so advancing again causes us to skip the next
token, causing future errors to be out of sync. Bootstrapped and ran
Go testsuite on x86_64-pc
On Wed, Dec 2, 2020 at 4:24 AM CHIGOT, CLEMENT wrote:
>
> Since the new gccgo mangling scheme, libgo compilation is broken on AIX (or
> in Linux with -gstabs) because of a type symbol having a " in its name. I've
> made a patch (see attachment) in order to fix stabstring generation, because,
>
Hi all,
this is to fix in GCC 10 the incomplete backport done by 1aabb312f of
what at the time I fixed on master with dd019ef07.
Regtested and bootstraped on arm-linux-gnueabihf.
I guess should be under the obvious rule but prefer to ask, okay for
gcc-10?
Thanks
Andrea
>From a795f7aaf87fa36
given that this is a blocker for Darwin20 and is Darwin-local I plan to
apply it (with the spello fixes) if there are no more comments in the next
24h.
thanks
Iain
Jonathan Wakely wrote:
On 23/11/20 20:01 +, Iain Sandoe wrote:
Hi
This fixes a blocker for x86_64 darwin20 (a.k.a macOS 11)
Hi Ian,
Here is the test case.
If you're compiling with -gstabs you should have a line looking like:
.stabs "type..struct{Type go.bug1.ObjectIdentifier;Value
[][]go.bug1.Extension{asn1:"set"}}:G(0,7)=xsStructType:",32,0,0,0
As you can see the " around for "set" aren't escaped.
I didn't
This is a gcc-10 version of:
Richard Sandiford writes:
> This PR shows another problem with calculating value ranges for
> POLY_INT_CSTs. We have:
>
> ivtmp_76 = ASSERT_EXPR POLY_INT_CST [9, 4294967294]>
>
> where the VQ coefficient is unsigned but is effectively acting
> as a negative number
On 12/2/20 4:08 PM, Ilya Leoshkevich wrote:
> Bootstrapped and regtested on s390x-redhat-linux. Ok for master?
>
> v1: https://gcc.gnu.org/pipermail/gcc-patches/2020-December/560822.html
>
> v1 -> v2:
> - Use SYMBOL_REF_P.
> - Fix usage of gcc_assert.
> - Use GEN_INT.
>
>
>
> Currently GCC lo
This patch to the Go frontend improves the error message reported for
mixed named and unnamed parameters. This requires updating a test in
the testsuite to the current version in the source repo. Bootstrapped
and ran Go testsuite on x86_64-pc-linux-gnu. Committed to mainline.
Ian
ed281e4a944a8b
This is a gcc-10 version of:
Richard Sandiford writes:
> [Sorry, been sitting on this patch for a while and just realised
> I never sent it.]
>
> This is yet another PR caused by constant integer rtxes not storing
> a mode. We were calling REDUCE_BIT_FIELD on a constant integer that
> didn't fi
The module machinery needs to serialize tinfo types and vars by
meaning, not literally. This adds the necessary pieces to rtti.
gcc/cp/
* cp-tree.h (DECL_TINFO_P): Also for TYPE_DECLs.
(get_tinfo_decl_direct): Declare.
(get_pseudo_tinfo_index, get_pseudo_tinfo_ty
This patch to the Go frontend rewords the "declared and not used"
error message. This is a copy of https://golang.org/cl/203282 in the
gc compiler.
>From the CL 203282 description:
"declared and not used" is technically correct, but might confuse
the user. Switching "and" to "but" will h
> On Dec 1, 2020, at 6:16 PM, Jeff Law wrote:
From c2573c6c8552b7b4c2eedb0684ce48b5c11436ec Mon Sep 17 00:00:00 2001
From: qing zhao
Date: Thu, 19 Nov 2020 16:46:50 +0100
Subject: [PATCH] rtl-optimization: Fix data flow maintenance bug in
reg-stack.c [pr9]
>>
Andrea Corallo via Gcc-patches writes:
> Hi all,
>
> this is to fix in GCC 10 the incomplete backport done by 1aabb312f of
> what at the time I fixed on master with dd019ef07.
>
> Regtested and bootstraped on arm-linux-gnueabihf.
>
> I guess should be under the obvious rule but prefer to ask, oka
In addition to the existing powerpc targets, powerpc64 needs libatomic
for 64-bit atomics when testing the 32-bit multilib with -m32. Adjust
the existing target checks to match all 32-bit powerpc targets, but not
64-bit ones.
libstdc++-v3/ChangeLog:
* testsuite/lib/dg-options.exp (add_opt
Hi!
As discussed in https://sourceware.org/bugzilla/show_bug.cgi?id=26987 ,
for very large bounds (which don't fit into HOST_WIDE_INT) GCC emits invalid
DWARF.
In DWARF2, DW_AT_{lower,upper}_bound were constant reference class.
In DWARF3 they are block constant reference and the
Static and Dynamic
On Wed, Dec 02, 2020 at 10:42:51AM -0500, Jason Merrill via Gcc-patches wrote:
> On 12/2/20 7:13 AM, Jakub Jelinek wrote:
> > On Tue, Dec 01, 2020 at 04:05:22PM -0500, Jason Merrill via Gcc-patches
> > wrote:
> > > Or simpler might be to always defer immediate evaluation of
> > > source_location::
On Wed, Dec 2, 2020 at 7:47 AM Ian Lance Taylor wrote:
>
> This Go frontend patch changes the parser to not advance past an
> unexpected semicolon, after it gives an error. We've already read the
> unexpected semicolon, so advancing again causes us to skip the next
> token, causing future errors
On 12/2/20 7:44 AM, Simon Marchi via Gcc-patches wrote:
> Bring in a few lines that are in binutils-gdb's .gitignore but not
> gcc's.
>
> Note that I don't have push access to gcc, so I would appreciate
> if somebody could push it for me.
>
> ChangeLog:
>
> * .gitignore: Sync with binutils
Przemyslaw Wirkus writes:
> New +flagm (Condition flag manipulation from Armv8.4-A) feature option for
> -march command line option.
>
> Please note that FLAGM stays an Armv8.4-A feature but now can be
> assigned to other architectures or CPUs.
>
> OK for master?
>
> gcc/ChangeLog:
>
> * config/aa
On Tue, Dec 01, 2020 at 12:49:03PM +0800, Hongtao Liu via Gcc-patches wrote:
> +bool neq_p = INTVAL (operands[4]) >> 2;
> +/* LE: 2, NLT: 5, NLE: 6, LT: 1 */
> +rtx cmp_predicate = neq_p ? GEN_INT (6) : GEN_INT (2);
> +if (MEM_P (operands[1]))
> + {
> + std::swap (operands
On 11/10/20 7:35 PM, Alexandre Oliva wrote:
> This patch introduces maybe_emit_call_builtin___clear_cache for the
> builtin expander machinery and the trampoline initializers to use to
> clear the instruction cache, removing a source of inconsistencies and
> subtle errors in low-level machinery.
On 12/2/20 9:32 AM, Qing Zhao wrote:
>
>> So we are clearing the x87 registers with that option. Hence the change
>> in reg-stack behavior. I'm a bit surprised by this as I don't see
>> clearing the x87 registers as particularly helpful from a security
>> standpoint. But I haven't followed th
On 12/2/20 9:27 AM, Richard Sandiford via Gcc-patches wrote:
> This is a gcc-10 version of:
>
> Richard Sandiford writes:
>> This PR shows another problem with calculating value ranges for
>> POLY_INT_CSTs. We have:
>>
>> ivtmp_76 = ASSERT_EXPR POLY_INT_CST [9, 4294967294]>
>>
>> where the
On 12/1/20 11:15 PM, Alexandre Oliva wrote:
> There's a help.exp test that checks that the help message for
> -Wabsolute-value mentions it's available in C and ObjC, when compiling
> a C++ program.
>
> However, if GCC is built with the C++ language disabled, the
> .cc file is compiled as C, and
On 12/1/20 7:09 PM, Ilya Leoshkevich wrote:
> On Tue, 2020-12-01 at 15:34 -0700, Jeff Law wrote:
>> No strong opinions. I think whichever is less invasive in terms of
>> code
>> quality is probably the way to go. What we want to avoid is
>> suppressing
>> threading unnecessarily as that often
The r11-5622 change to -Wformat-overflow switched the warning
to using the maximm object size limit used by the other overflow
and out of bounds access warnings like -Wstringop-overflow.
That in turn exposed a subtle off-by-one mistake in the former
that was also reflected in a few tests, seen in
On 12/2/20 9:48 AM, Jakub Jelinek via Gcc-patches wrote:
> Hi!
>
> As discussed in https://sourceware.org/bugzilla/show_bug.cgi?id=26987 ,
> for very large bounds (which don't fit into HOST_WIDE_INT) GCC emits invalid
> DWARF.
> In DWARF2, DW_AT_{lower,upper}_bound were constant reference class.
On 12/2/20 11:43 AM, Martin Sebor wrote:
> The r11-5622 change to -Wformat-overflow switched the warning
> to using the maximm object size limit used by the other overflow
> and out of bounds access warnings like -Wstringop-overflow.
> That in turn exposed a subtle off-by-one mistake in the form
On 12/1/20 1:28 PM, Bernd Edlinger wrote:
On 11/24/20 11:10 PM, Jason Merrill wrote:
On 11/22/20 3:05 AM, Bernd Edlinger wrote:
Hi,
this avoids the need to use -fno-threadsafe-statics on
arm-none-eabi or working around that problem by supplying
a dummy __sync_synchronize function which might
j
On 12/2/20 12:35 PM, Jakub Jelinek wrote:
On Wed, Dec 02, 2020 at 10:42:51AM -0500, Jason Merrill via Gcc-patches wrote:
On 12/2/20 7:13 AM, Jakub Jelinek wrote:
On Tue, Dec 01, 2020 at 04:05:22PM -0500, Jason Merrill via Gcc-patches wrote:
Or simpler might be to always defer immediate evaluat
On 12/1/20 12:38 PM, Marek Polacek wrote:
I had a strong sense of deja vu when looking into this, and no wonder,
since this is almost identical to c++/95728.
Since r11-423 tsubst_copy_and_build/TREE_LIST uses tsubst_tree_list
instead of open coding it. While the latter could return an error
nod
A couple of buffer overflow checks in libbacktrace incorrectly used >=
when comparing the end of the value with the end of the buffer. It is
of course OK if the value ends at the very end of the buffer. This
patch corrects those cases to use > instead. Bootstrapped and ran
libbacktrace and Go te
On 11/25/20 9:47 PM, Hongtao Liu wrote:
> On Wed, Nov 25, 2020 at 7:37 PM Jakub Jelinek wrote:
>> On Wed, Nov 25, 2020 at 07:32:44PM +0800, Hongtao Liu wrote:
>>> Update patch:
>>> 1. ix86_expand_special_args_builtin is used for expanding mask load
>>> intrinsics, this function will always co
Thanks a lot for your review.
I will commit the patch soon.
Qing
> On Dec 2, 2020, at 12:27 PM, Jeff Law wrote:
>
>
>
> On 12/2/20 9:32 AM, Qing Zhao wrote:
>>
>>> So we are clearing the x87 registers with that option. Hence the change
>>> in reg-stack behavior. I'm a bit surprised by thi
On 12/1/20 12:38 PM, Marek Polacek wrote:
In this test, we have
static inline const int c = b;
in a class template, and we call store_init_value as usual. There, the
value is
IMPLICIT_CONV_EXPR(b)
which is is_nondependent_static_init_expression but isn't
is_nondependent_constant_expres
This is an updated patch for the new tree flags needed for modules.
Inspired by Richard's desire for documenting the flags, I realized that
three of them could already be merged. So that's done here.
Nothing uses these flags yet.
gcc/cp/
* cp-tree.h (DECL_MODULE_PURVIEW_P, DEC
Richard Sandiford via Gcc-patches writes:
> Przemyslaw Wirkus writes:
>> New +flagm (Condition flag manipulation from Armv8.4-A) feature option for
>> -march command line option.
>>
>> Please note that FLAGM stays an Armv8.4-A feature but now can be
>> assigned to other architectures or CPUs.
>>
I've been using
git send-email --annotate --suppress-from --to=gcc-patches@gcc.gnu.org \
${@:-HEAD^} ':!*/ChangeLog' ':!*configure'
for sending most patches, but it occurs to me that it would be useful to put
the To: address in the configury.
If someone were feeling ambitious, they could wri
On 12/2/20 7:30 AM, Jakub Jelinek wrote:
Hi!
On Tue, Dec 01, 2020 at 01:03:52PM +, Jonathan Wakely via Gcc-patches wrote:
I mentioned in PR 80780 that a __builtin__PRETTY_FUNCTION would have
been nice, because __FUNCTION__ isn't very useful for C++, because of
overloading and namespace/clas
My apologies for sending this a second time. I forgot to add the
mailing list to the CC list. :-(
c++: Treat OPAQUE_TYPE types as an aggregate type
MODE_OPAQUE and the associated OPAQUE_TYPE were added to stop the optimizers
from knowing how the bits in a variable with an opaque type are laid ou
On 12/2/20 11:43 AM, Martin Sebor wrote:
> The r11-5622 change to -Wformat-overflow switched the warning
> to using the maximm object size limit used by the other overflow
> and out of bounds access warnings like -Wstringop-overflow.
> That in turn exposed a subtle off-by-one mistake in the form
On 7/10/20 1:53 PM, Jeff Chapman wrote:
Hello again :)
Attached is a new squashed revision of the patch sans ChangeLogs. The
current work is now being done on github:
https://github.com/lock3/gcc/tree/contracts-jac-alt
I'm starting to review this now, sorry for the delay. Is this still the
br
On Wed, Dec 02, 2020 at 02:20:17PM -0600, Peter Bergner via Gcc-patches wrote:
> My apologies for sending this a second time. I forgot to add the
> mailing list to the CC list. :-(
>
>
> c++: Treat OPAQUE_TYPE types as an aggregate type
>
> MODE_OPAQUE and the associated OPAQUE_TYPE were added t
On 11/13/20 1:15 AM, Richard Sandiford via Gcc-patches wrote:
> We already have two splay tree implementations: the old C one in
> libiberty and a templated reimplementation of it in typed-splay-tree.h.
> However, they have some drawbacks:
>
> - They hard-code the assumption that nodes should ha
On 12/2/20 3:36 PM, Jakub Jelinek wrote:
On Wed, Dec 02, 2020 at 02:20:17PM -0600, Peter Bergner via Gcc-patches wrote:
My apologies for sending this a second time. I forgot to add the
mailing list to the CC list. :-(
c++: Treat OPAQUE_TYPE types as an aggregate type
MODE_OPAQUE and the assoc
On 12/2/20 3:37 PM, Jason Merrill wrote:
On 12/2/20 3:36 PM, Jakub Jelinek wrote:
On Wed, Dec 02, 2020 at 02:20:17PM -0600, Peter Bergner via
Gcc-patches wrote:
My apologies for sending this a second time. I forgot to add the
mailing list to the CC list. :-(
c++: Treat OPAQUE_TYPE types as an
For modules we need to compare structurally all the way down. This
means inhibiting typename_type resolution, independent of comparing
specializations.
gcc/cp/
* cp-tree.h (comparing_typenames): Declare.
* pt.c (comparing_typenames): Define.
(spec_hasher::equal):
While looking at another issue I noticed that in a template we were failing
to find the INIT_EXPR we were looking for, and so ended up doing redundant
processing. No testcase, as the redundant processing ended up getting the
right result.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/Cha
We were saying 'auto parameter not permitted' in a place where 'auto' is in
fact permitted in C++20, but a class template placeholder is not.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
* decl.c (grokdeclarator): Improve diagnostic for
disallowed CTAD placeho
On Linux/x86_64,
329ae1d7751346ba166d34e77a43e8cc33daa1c9 is the first bad commit
commit 329ae1d7751346ba166d34e77a43e8cc33daa1c9
Author: Nathan Sidwell
Date: Wed Dec 2 07:35:23 2020 -0800
c++: Extend build_array_type API
caused
FAIL: g++.dg/template/canon-type-4.C -std=c++17 (internal
On 12/2/20 8:50 AM, Richard Biener wrote:
> On Tue, 1 Dec 2020, Bernd Edlinger wrote:
>
>> Hi!
>>
>>
>> This removes gimple_debug stmts without block info after a
>> NULL INLINE_ENTRY.
>>
>> The line numbers from these stmts are from the inline function,
>> but since the inline function is complet
This patch (GCC commit 6fbec038f7a7ddf29f074943611b53210d17c40c) has
broken the glibc build (at least with current binutils master). The
errors are of the form:
In file included from :
gconv_dl.c: In function 'free_mem':
gconv_dl.c:202:18: error: 'free_mem' causes a section type conflict with
This fixes errors seen on powerpc64 (big endian only) due to the
printers for std::any and std::experimental::any being unable to find
the manager function.
libstdc++-v3/ChangeLog:
PR libstdc++/65480
PR libstdc++/68735
* python/libstdcxx/v6/printers.py (function_pointer_to
On 02/12/20 15:18 -0500, Jason Merrill wrote:
On 12/2/20 7:30 AM, Jakub Jelinek wrote:
Hi!
On Tue, Dec 01, 2020 at 01:03:52PM +, Jonathan Wakely via Gcc-patches wrote:
I mentioned in PR 80780 that a __builtin__PRETTY_FUNCTION would have
been nice, because __FUNCTION__ isn't very useful for
On Wed, Dec 2, 2020 at 1:31 PM Joseph Myers wrote:
>
> This patch (GCC commit 6fbec038f7a7ddf29f074943611b53210d17c40c) has
> broken the glibc build (at least with current binutils master). The
> errors are of the form:
>
> In file included from :
> gconv_dl.c: In function 'free_mem':
> gconv_dl.
On Wed, 2 Dec 2020, H.J. Lu via Gcc-patches wrote:
> > Not sure if this is a GCC bug or indicates that glibc's libc_freeres_fn or
> > related macros need to change to work with both old and new GCC.
>
> We may need to update glibc for GCC 11. Can you open a glibc bug and
> CC me?
https://source
On Wed, 2020-12-02 at 17:44 +0800, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> This patch is to use paradoxical subreg instead of
> zero_extend for promoting QI/HI to SI/DI when we
> want to construct one vector with these modes.
> Since we do the gpr->vsx movement and vector merge
> or pack later,
On Linux/x86_64,
0a7dc4b6440faa8cd57c630f1e394a719469c399 is the first bad commit
commit 0a7dc4b6440faa8cd57c630f1e394a719469c399
Author: Martin Sebor
Date: Wed Dec 2 11:29:11 2020 -0700
Adjust test to avoid ILP32 failures after r11-5622 (PR middle-end/97373)
caused
FAIL: gcc.dg/tree-ssa
On Tue, 2020-12-01 at 15:48 -0800, Carl Love via Gcc-patches wrote:
> Segher, Pat:
>
> I have updated the patch to address the comments below.
In all the excitement, i've lost track of some of the details throughout the
thread. :-)
Subject: Re: [PATCH v2] rs6000, vector integer multiply/divi
In this testcase we are crashing trying to gimplify a switch, because
the types of the switch condition and case constants have different
TYPE_PRECISIONs.
This started with my r5-3726 fix: SWITCH_STMT_TYPE is supposed to be the
original type of the switch condition before any conversions, so in th
1 - 100 of 116 matches
Mail list logo
