On Thu, Dec 3, 2020 at 2:22 AM Jakub Jelinek wrote:
>
> 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);
> > +
On Thu, Dec 3, 2020 at 3:11 AM Jeff Law wrote:
>
>
>
> 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
VAX has interlocked branch instructions used for atomic operations and
we want to have them wrapped in UNSPEC_VOLATILE so as not to have code
carried across. This however breaks with jump optimization and leads
to an ICE in the build of libbacktrace like:
.../libbacktrace/mmap.c:190:1: internal
In this testcase we weren't catching the error in A::f because the parameter
'I' wasn't in scope, so the default argument for 'b' found the global
typedef I. Fixed by pushing the parms before parsing. This is a bit
complicated because pushdecl clears DECL_CHAIN; do_push_parm_decls deals
with
Jakub noticed that we weren't recognizing a default argument for a consteval
member function as being in immediate function context because there was no
function parameter scope to look at.
Note that this patch doesn't actually push the parameters into the scope,
that happens in a separate
On 12/2/20 6:18 PM, Marek Polacek wrote:
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
On 12/2/20 6:06 PM, Ilya Leoshkevich via Gcc-patches wrote:
Bootstrap ang regtest running on x86_64-redhat-linux. Ok for master?
I'd consider the fix obviously correct.
Thank you!
Martin
gcc/ChangeLog:
2020-12-03 Ilya Leoshkevich
* tree-ssa-strlen.c (printf_strlen_execute):
On 12/2/20 6:18 PM, Marek Polacek wrote:
-fsanitize=vptr initializes all vtable pointers to null so that it can
catch invalid calls; see cp_ubsan_maybe_initialize_vtbl_ptrs. That
means that evaluating a vtable reference can produce a null pointer
in this mode, so cxx_eval_dynamic_cast_fn should
According to
https://gcc.gnu.org/pipermail/gcc/2020-November/234344.html, GCC is
allowed to perform optimizations that remove floating point traps,
since they do not affect the modeled control flow. This interferes with
two signaling comparison tests, where (a <= b && a >= b) is turned into
(a <=
On Tue, Dec 1, 2020 at 3:24 PM Jeff Law via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
>
> Kito's recent change to multilib handling seems to have exposed a latent
> mcore bug.
>
> The mcore 210 does not support little endian. Yet we try to build a
> mcore-210 little-endian multilibs.
>
> I
Bootstrap ang regtest running on x86_64-redhat-linux. Ok for master?
gcc/ChangeLog:
2020-12-03 Ilya Leoshkevich
* tree-ssa-strlen.c (printf_strlen_execute): Avoid division by
0.
---
gcc/tree-ssa-strlen.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On Tue, Dec 1, 2020 at 12:13 AM Kito Cheng wrote:
> - We would like to canonicalize the arch string for --with-arch for
>easier handling multilib, so split canonicalization part to a stand
>along script to shared the logic.
>
> gcc/ChangeLog:
>
> *
On 12/2/20 1:31 PM, Jeff Law wrote:
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
On 12/2/20 2:37 PM, Jason Merrill wrote:
> But this patch is OK.
Ok, pushed to trunk. Thanks!
Peter
On 12/2/20 2:36 PM, Jakub Jelinek wrote:
> Just a random question, do you have some testsuite coverage for constant
> expression evaluation (primarily C++) with the opaque types, do you verify
> any object with that type is treated as something that may not appear in
> constant expression and does
-fsanitize=vptr initializes all vtable pointers to null so that it can
catch invalid calls; see cp_ubsan_maybe_initialize_vtbl_ptrs. That
means that evaluating a vtable reference can produce a null pointer
in this mode, so cxx_eval_dynamic_cast_fn should check that.
Bootstrapped/regtested on
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
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
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:
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
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?
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':
>
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
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
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
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
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
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
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.
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.
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
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
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
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
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
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
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
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
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
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.
>>
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,
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
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
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
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
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
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
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
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
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
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/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
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/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/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
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
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
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:
>
> *
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
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 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
> > >
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
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
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,
> 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]
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
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,
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
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
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
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
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
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
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
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,
>
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
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
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
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):
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
> 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
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
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
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
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
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
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(+)
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
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
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 &) =
> 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
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
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): "^
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
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
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 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
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
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'
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
1 - 100 of 116 matches
Mail list logo
