In this PR we are dealing with a missing .UBSAN_BOUNDS, so the
out-of-bounds access in the test makes the program crash before
a UBSan diagnostic was emitted. In C and C++, c_genericize gets
a[b] = a[b] | c;
but in C, both a[b] are one identical shared tree (not in C++ because
cp_fold/ARRAY_RE
On Thu, Mar 09, 2023 at 09:44:49AM +0100, Jakub Jelinek wrote:
> On Thu, Mar 09, 2023 at 08:12:47AM +, Richard Biener wrote:
> > I think this is a reasonable way to address the regression, so OK.
>
> It is true that both C and C++ (including c++14_down and c++17 and later
> where the latter ha
We crash here since r10-3661, the store_init_value hunk in particular.
Before, we called cp_fully_fold_init, so e.g.
{.str=VIEW_CONVERT_EXPR("")}
was folded into
{.str=""}
but now we don't fold and keep the VCE around, and it causes trouble in
cxx_eval_store_expression: in the !refs->is_emp
On Fri, Mar 10, 2023 at 07:07:36PM +0100, Jakub Jelinek wrote:
> On Thu, Mar 09, 2023 at 07:44:53PM -0500, Marek Polacek wrote:
> > On Thu, Mar 09, 2023 at 09:44:49AM +0100, Jakub Jelinek wrote:
> > > On Thu, Mar 09, 2023 at 08:12:47AM +, Richard Biener wrote:
> > > > I think this is a reasonab
std::span is a view and therefore should be treated as a reference
wrapper class for the purposes of -Wdangling-reference. I'm not sure
there's a pattern that we could check for.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
PR c++/107532
gcc/cp/ChangeLog:
* call
Here we're failing to detect a signed overflow with -O because match.pd,
since r8-1516, transforms
c = (a + 1) - (int) (short int) b;
into
c = (int) ((unsigned int) a + 4294946117);
wrongly eliding the overflow. This kind of problems is usually
avoided by using TYPE_OVERFLOW_SANITIZED in t
On Fri, Mar 10, 2023 at 01:47:46PM -0500, Jason Merrill wrote:
> On 3/10/23 11:17, Marek Polacek wrote:
> > We crash here since r10-3661, the store_init_value hunk in particular.
> > Before, we called cp_fully_fold_init, so e.g.
> >
> >{.str=VIEW_CONVERT_EXPR("")}
> >
> > was folded into
> >
On Wed, Mar 15, 2023 at 12:48:27PM -0400, Jason Merrill wrote:
> On 3/15/23 10:37, Marek Polacek wrote:
> > On Fri, Mar 10, 2023 at 01:47:46PM -0500, Jason Merrill wrote:
> > > On 3/10/23 11:17, Marek Polacek wrote:
> > > > We crash here since r10-3661, the store_init_value hunk in particular.
> >
On Wed, May 03, 2023 at 03:37:03PM -0400, Jason Merrill wrote:
> On 5/2/23 19:10, Marek Polacek wrote:
> > This PR points out that std::is_convertible has given the wrong answer
> > in
> >
> >static_assert (!std::is_convertible_v , "");
> >
> > since r13-2822 implemented __is_{,nothrow_}conve
Ping.
On Tue, May 09, 2023 at 03:41:58PM -0400, Marek Polacek via Gcc-patches wrote:
> [ This is my third attempt to add this configure option. The first
> version was approved but it came too late in the development cycle.
> The second version was also approved, but I had to revert it:
As promised in the --enable-host-pie patch, this patch adds another
configure option, --enable-host-bind-now, which adds -z now when linking
the compiler executables in order to extend hardening. BIND_NOW with RELRO
allows the GOT to be marked RO; this prevents GOT modification attacks.
This opti
In check_return_expr, we suppress the -Wdangling-reference warning when
we're sure it would be a false positive. It wasn't working in a
template, though, because the suppress_warning call was never reached.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk and 13.2?
PR c++/1097
On Thu, Jan 21, 2021 at 01:55:24AM -0500, Jason Merrill wrote:
> > + /* Now that we've gone through all the members, instantiate those
> > + marked with attribute used. */
> > + for (tree &x : used)
>
> This doesn't need to be a reference. And I think we want this to happen
> even later, a
On Tue, Jan 19, 2021 at 05:38:20PM -0500, Marek Polacek via Gcc-patches wrote:
> On Tue, Jan 19, 2021 at 03:47:47PM -0500, Jason Merrill via Gcc-patches wrote:
> > On 1/13/21 6:39 PM, Marek Polacek wrote:
> > > r11-6301 added some asserts in mangle.c, and now we trip over one
On Thu, Jan 21, 2021 at 11:22:24AM -0500, Patrick Palka via Gcc-patches wrote:
> Here at parse time finish_qualified_id_expr adds an implicit 'this->' to
> the expression tmp::integral (because it's type-dependent, and also
> current_class_ptr is set) within the trailing return type, and later
> du
I discovered very strange code in inject_parm_decls:
if (args && is_this_parameter (args))
{
gcc_checking_assert (current_class_ptr == NULL_TREE);
current_class_ptr = NULL_TREE;
We are tripping up on the assert because when we call inject_parm_decls,
current_class_ptr is set
On Thu, Jan 21, 2021 at 05:41:06PM -0500, Jason Merrill via Gcc-patches wrote:
> On 1/21/21 2:44 PM, Marek Polacek wrote:
> > @@ -3349,7 +3349,12 @@ write_expression (tree expr)
> > else if (dependent_name (expr))
> > {
> > tree name = dependent_name (expr);
> > - gcc_assert
On Thu, Jan 21, 2021 at 09:47:35PM -0500, Jason Merrill via Gcc-patches wrote:
> On 1/21/21 5:45 PM, Marek Polacek wrote:
> > I discovered very strange code in inject_parm_decls:
> >
> > if (args && is_this_parameter (args))
> > {
> > gcc_checking_assert (current_class_ptr == NUL
On Fri, Jan 22, 2021 at 04:44:42PM -0500, Jason Merrill wrote:
> On 1/22/21 4:01 PM, Marek Polacek wrote:
> > On Thu, Jan 21, 2021 at 09:47:35PM -0500, Jason Merrill via Gcc-patches
> > wrote:
> > > On 1/21/21 5:45 PM, Marek Polacek wrote:
> > > > I discovered very strange code in inject_parm_decl
A year ago I submitted this patch:
~~
Here we trip on the TYPE_USER_ALIGN (t) assert in strip_typedefs: it
gets "const d[0]" with TYPE_USER_ALIGN=0 but the result built by
build_cplus_array_type is "const char[0]" with TYPE_USER_ALIGN=1.
When we strip_typedefs the element of the array "const d",
On Thu, Jan 28, 2021 at 03:18:55PM -0500, Jason Merrill via Gcc-patches wrote:
> On 1/28/21 10:34 AM, Marek Polacek wrote:
> > A year ago I submitted this patch:
> >
> > ~~
> > Here we trip on the TYPE_USER_ALIGN (t) assert in strip_typedefs: it
> > gets "const d[0]" with TYPE_USER_ALIGN=0 but the
On Thu, Jan 28, 2021 at 11:02:36PM +0100, Eric Botcazou wrote:
> > Bootstrapped/regtested on
> > * x86_64-pc-linux-gnu
> > * powerpc64le-unknown-linux-gnu
> > * aarch64-linux-gnu
> > ok for trunk?
>
> None of them is strict alignment though, isn't it?
Aware. I don't have access to, e.g., a sparc
On Thu, Jan 28, 2021 at 11:38:34PM +0100, Eric Botcazou wrote:
> > Aware. I don't have access to, e.g., a sparc box. But the test I've added
> > uses -mstrict-align where possible to check that the issue is resolved.
>
> There are relatively fast SPARC64/Linux (gcc202) and SPARC/Solaris machines
My r11-86 adjusted cp_parser_class_name to do
- scope = parser->scope;
+ scope = parser->scope ? parser->scope : parser->context->object_type;
if (scope == error_mark_node)
return error_mark_node;
but that caused endless looping in cp_parser_type_specifier_seq (the
while (true) loop) in
__builtin_has_attribute doesn't work in templates yet (bug 92104), so
in r11-471 I added a sorry. But that only caught type-dependent
expressions and we also want to sorry on value-dependent expressions.
This patch uses v_d_e_p rather than uses_template_parms because u_t_p
sets p_t_d and then v_d_
On Fri, Jan 29, 2021 at 04:02:51PM -0500, Marek Polacek via Gcc-patches wrote:
> __builtin_has_attribute doesn't work in templates yet (bug 92104), so
> in r11-471 I added a sorry. But that only caught type-dependent
> expressions and we also want to sorry on value-dependent expre
On Fri, Jan 29, 2021 at 04:23:14PM -0500, Marek Polacek via Gcc-patches wrote:
> On Fri, Jan 29, 2021 at 04:02:51PM -0500, Marek Polacek via Gcc-patches wrote:
> > __builtin_has_attribute doesn't work in templates yet (bug 92104), so
> > in r11-471 I added a sorry. But t
On Fri, Jan 29, 2021 at 06:18:35PM -0500, Jason Merrill via Gcc-patches wrote:
> On 1/29/21 5:52 PM, Marek Polacek wrote:
> > On Fri, Jan 29, 2021 at 04:23:14PM -0500, Marek Polacek via Gcc-patches
> > wrote:
> > > On Fri, Jan 29, 2021 at 04:02:51PM -0500, Marek
; > On Fri, Jan 29, 2021 at 04:23:14PM -0500, Marek Polacek via Gcc-patches
> > > > wrote:
> > > > > On Fri, Jan 29, 2021 at 04:02:51PM -0500, Marek Polacek via
> > > > > Gcc-patches wrote:
> > > > > > __builtin_has_attribute doesn't
Here we crash with a noexcept-specifier in a nested template class,
because my handling of such deferred-parse noexcept-specifiers was
gronked when we need to instantiate a DEFERRED_PARSE before it was
actually parsed at the end of the outermost class.
In
struct S {
template struct B {
On Wed, Feb 03, 2021 at 04:15:24PM +0100, Martin Liška wrote:
> The patch documents -mprefer-vector-width which is a valid target
> attribute/pragma.
> diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
> index 8daa1c67974..a14875cec37 100644
> --- a/gcc/doc/extend.texi
> +++ b/gcc/doc/extend
These member functions look like they could be marked const, since
they don't modify any (non-mutable) class members.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
PR c++/98951
* call.c (struct z_candidate): Mark rewritten and reversed as const.
(struct NonP
Since most of volatile is deprecated in C++20, we are required to warn
for compound assignments to volatile variables and so on. But here we
have
volatile int x, y, z;
(b ? x : y) = 1;
and we shouldn't warn, because simple assignments like x = 24; should
not provoke the warning when they are
On Thu, Feb 04, 2021 at 10:59:21AM -0500, Jason Merrill wrote:
> On 2/3/21 7:03 PM, Marek Polacek wrote:
> > Since most of volatile is deprecated in C++20, we are required to warn
> > for compound assignments to volatile variables and so on. But here we
> > have
> >
> >volatile int x, y, z;
>
On Thu, Feb 04, 2021 at 03:43:33PM -0500, Jason Merrill via Gcc-patches wrote:
> Nice when fixing a bug is as easy as removing incorrect checks.
>
> gcc/cp/ChangeLog:
>
> PR c++/98717
> * constraint.cc (build_concept_check_arguments): Remove assert.
> (build_concept_check): Allo
On Thu, Feb 04, 2021 at 03:47:54PM -0500, Jason Merrill via Gcc-patches wrote:
> On 2/4/21 1:11 PM, Marek Polacek wrote:
> > On Thu, Feb 04, 2021 at 10:59:21AM -0500, Jason Merrill wrote:
> > > On 2/3/21 7:03 PM, Marek Polacek wrote:
> > > > Since most of volatile is deprecated in C++20, we are req
Here we ICE in finish_nonmember_using_decl -> lookup_using_decl ->
... -> find_namespace_slot because "name" is not an IDENTIFIER_NODE.
It is a BIT_NOT_EXPR because this broken test uses
using E::~E; // SCOPE::NAME
A using-decl can't refer to a destructor, and lookup_using_decl already
checks t
Hi,
a few comments:
On Fri, Feb 05, 2021 at 03:39:25PM +, Anthony Sharp via Gcc-patches wrote:
> 2021-02-05 Anthony Sharp
>
> * semantics.c (get_class_access_diagnostic_decl): New function.
> (enforce_access): Altered function.
Pedantically, "Altered function." is not very go
On Fri, Feb 05, 2021 at 05:28:07PM +, Anthony Sharp wrote:
> Hi Marek,
>
> > Pedantically, "Altered function." is not very good, it should say what
> > in enforce_access changed.
>
> I would normally 100% agree, but the changes are a bit too complicated
> to be concisely (and helpfully) descr
gcc/cp/ChangeLog:
* cp-tree.h (CLASSTYPE_TI_TEMPLATE): Fix typo.
---
gcc/cp/cp-tree.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 970ed5e77bb..41472a895b5 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -3775,8
My r10-7007 patch tweaked tsubst not to reduce the template level of
template parameters when tf_partial. That caused infinite looping in
is_specialization_of: we ended up with a class template specialization
whose TREE_TYPE (CLASSTYPE_TI_TEMPLATE (t)) == t, so the second for
loop in is_specializa
Freeing the condition chain needs to use vec_free which does ->release,
or we leak memory.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
gcc/c/ChangeLog:
* c-parser.c (c_parser_if_statement): Use vec_free.
gcc/cp/ChangeLog:
* parser.c (cp_parser_selection_stateme
We ICE in handle_assume_aligned_attribute since r271338 which added
@@ -2935,8 +2936,8 @@ handle_assume_aligned_attribute (tree *node, tree name,
tree args, int,
/* The misalignment specified by the second argument
must be non-negative and less than the alignment. */
On Wed, Feb 10, 2021 at 03:54:52PM -0700, Martin Sebor via Gcc-patches wrote:
> On 2/10/21 3:33 PM, Marek Polacek wrote:
> > We ICE in handle_assume_aligned_attribute since r271338 which added
> >
> > @@ -2935,8 +2936,8 @@ handle_assume_aligned_attribute (tree *node, tree
> > name, tree args, int
On Wed, Feb 10, 2021 at 04:48:56PM -0500, Jason Merrill wrote:
> On 2/10/21 12:35 PM, Marek Polacek wrote:
> > Freeing the condition chain needs to use vec_free which does ->release,
> > or we leak memory.
>
> OK, but if chain were an auto_vec, delete would work.
Yes.
> Can we merge auto_vec wit
Here an unexpanded parameter pack snuck into prep_operand which doesn't
expect to see an operand without a type, and since r247842
NONTYPE_ARGUMENT_PACK doesn't have a type anymore.
This only happens with the do-while loop whose condition may not
contain a declaration so we never called finish_con
On Thu, Feb 11, 2021 at 05:30:24PM +0100, Jakub Jelinek via Gcc-patches wrote:
> Hi!
>
> As the testcase shows, if we reach CPP_EOF during parsing of requirement
> sequence, we end up with endless loop where we always report invalid
> requirement expression, don't consume any token (as we are at e
On Thu, Feb 11, 2021 at 11:30:07AM -0500, Jason Merrill via Gcc-patches wrote:
> On 2/9/21 5:41 PM, Marek Polacek wrote:
> > My r10-7007 patch tweaked tsubst not to reduce the template level of
> > template parameters when tf_partial. That caused infinite looping in
> > is_specialization_of: we en
On Thu, Feb 11, 2021 at 02:24:22PM -0500, Marek Polacek via Gcc-patches wrote:
> On Thu, Feb 11, 2021 at 11:30:07AM -0500, Jason Merrill via Gcc-patches wrote:
> > On 2/9/21 5:41 PM, Marek Polacek wrote:
> > > My r10-7007 patch tweaked tsubst not to reduce the template level
We represent deduction guides with FUNCTION_DECLs, but they are built
without DECL_CONTEXT, leading to an ICE in type_dependent_expression_p
on the assert that the type of a function template with no dependent
(innermost!) template arguments must be non-dependent. Consider the
attached class-deduc
Here we reject
constexpr const int *p = nullptr;
constexpr int *q = const_cast(p);
with "conversion of 'const int*' null pointer to 'int*' is not a
constant expression", which seems bogus. This code has been rejected
since r238909 which added the can_convert check when converting a null
poin
Ping.
On Fri, Feb 12, 2021 at 06:12:12PM -0500, Marek Polacek via Gcc-patches wrote:
> We represent deduction guides with FUNCTION_DECLs, but they are built
> without DECL_CONTEXT, leading to an ICE in type_dependent_expression_p
> on the assert that the type of a function templat
On Wed, Feb 24, 2021 at 10:32:59PM -0500, Jason Merrill wrote:
> On 2/24/21 5:34 PM, Marek Polacek wrote:
> > Here we reject
> >
> >constexpr const int *p = nullptr;
> >constexpr int *q = const_cast(p);
> >
> > with "conversion of 'const int*' null pointer to 'int*' is not a
> > constant
On Thu, Feb 25, 2021 at 10:59:49AM -0500, Jason Merrill wrote:
> On 2/12/21 6:12 PM, Marek Polacek wrote:
> > We represent deduction guides with FUNCTION_DECLs, but they are built
> > without DECL_CONTEXT
>
> Hmm, that seems wrong: "A deduction-guide shall be declared in the
> same scope as the co
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/ChangeLog:
* builtins.c (warn_for_access): Fix typos.
---
gcc/builtins.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/gcc/builtins.c b/gcc/builtins.c
index 42150cee0bd..d804b0e6617 100644
--- a/gcc/builtins.c
On Thu, Feb 25, 2021 at 10:45:29PM -0500, Jason Merrill via Gcc-patches wrote:
> On 2/25/21 5:41 PM, Marek Polacek wrote:
> > On Thu, Feb 25, 2021 at 10:59:49AM -0500, Jason Merrill wrote:
> > > On 2/12/21 6:12 PM, Marek Polacek wrote:
> > > > We represent deduction guides with FUNCTION_DECLs, but
On Mon, Mar 01, 2021 at 03:08:58PM -0500, Jason Merrill wrote:
> On 3/1/21 2:54 PM, Marek Polacek wrote:
> > On Thu, Feb 25, 2021 at 10:45:29PM -0500, Jason Merrill via Gcc-patches
> > wrote:
> > > On 2/25/21 5:41 PM, Marek Polacek wrote:
> > > > On Thu, Feb 25, 2021 at 10:59:49AM -0500, Jason Mer
On Mon, Mar 01, 2021 at 09:29:19PM -0500, Jason Merrill via Gcc-patches wrote:
> On 3/1/21 7:59 PM, Marek Polacek wrote:
> > On Mon, Mar 01, 2021 at 03:08:58PM -0500, Jason Merrill wrote:
> > > On 3/1/21 2:54 PM, Marek Polacek wrote:
> > > > On Thu, Feb 25, 2021 at 10:45:29PM -0500, Jason Merrill v
Was happy to find out that my recent dguide fix (r11-7483) fixed
this test too. In particular, the
+ /* Wait until the enclosing scope is non-dependent. */
+ if (DECL_CLASS_SCOPE_P (tmpl)
+ && dependent_type_p (DECL_CONTEXT (tmpl)))
+return ptype;
bit.
Tested x86_64-pc-linux-gnu, ap
In this test we are building a call in a template, but since neither
the function nor any of its arguments are dependent, we go down the
normal path in finish_call_expr. convert_arguments sees that we're
binding a reference to int to double and therein convert_to_integer
creates a FIX_TRUNC_EXPR.
The issue in this PR is that we wrongly reject converting pointers to
member function of incomplete types, one of which has noexcept. Recall
that pointers (including pointers to member functions) to non-throwing
functions can be implicitly converted to potentially-throwing functions
(but not vice
This PR complains that we issue a -Wconversion warning in
template struct X {};
template X foo();
saying "conversion from 'long unsigned int' to 'int' may change value".
While it's not technically wrong, I suspect -Wconversion warnings aren't
all that useful for value-dependent expressions.
We crash here, because in a template, an enumerator doesn't have
a type until we've called finish_enum_value_list. But our -Wshadow
implementation, check_local_shadow, is called when we pushdecl in
build_enumerator, which takes place before finish_enum_value_list.
Bootstrapped/regtested on x86_64
On Fri, Mar 05, 2021 at 06:00:04PM +0100, Eric Botcazou wrote:
> > Here, when substituting still-dependent args into an alias template, we see
> > a non-const type because the default argument is non-const, and is not a
> > template parm object because it's still dependent.
> >
> > Tested x86_64-p
This is an ICE on invalid where we crash because since r269032 we
keep error_mark_node around instead of using noexcept_false_spec
when things go wrong; see the walk_field_subobs hunk.
We crash in deduce_inheriting_ctor which calls synthesized_method_walk
to deduce the exception-specification, but
This works since the recent r11-7102, but we didn't have a test for
a template-argument context.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/testsuite/ChangeLog:
PR c++/96268
* g++.dg/cpp2a/nontype-class41.C: New test.
---
gcc/testsuite/g++.dg/cpp2a/nontype-class41.C | 13
On Fri, Mar 05, 2021 at 05:03:45PM -0500, Jason Merrill wrote:
> On 3/4/21 9:37 PM, Marek Polacek wrote:
> > This PR complains that we issue a -Wconversion warning in
> >
> >template struct X {};
> >template X foo();
> >
> > saying "conversion from 'long unsigned int' to 'int' may chang
On Fri, Mar 05, 2021 at 05:15:49PM -0500, Jason Merrill via Gcc-patches wrote:
> On 3/3/21 7:55 PM, Marek Polacek wrote:
> > In this test we are building a call in a template, but since neither
> > the function nor any of its arguments are dependent, we go down the
> > normal path in finish_call_ex
On Mon, Mar 08, 2021 at 06:10:05PM -0700, Martin Sebor wrote:
> On 3/5/21 3:03 PM, Jason Merrill via Gcc-patches wrote:
> > On 3/4/21 9:37 PM, Marek Polacek wrote:
> > > This PR complains that we issue a -Wconversion warning in
> > >
> > > template struct X {};
> > > template X foo();
> >
On Mon, Aug 16, 2021 at 03:06:08PM -0400, Patrick Palka via Gcc-patches wrote:
> During aggregate CTAD, collect_ctor_idx_types always recurses into a
> sub-CONSTRUCTOR, regardless of whether the corresponding pair of braces
> was elided in the original initializer. This causes us to reject some
>
On Mon, Aug 30, 2021 at 05:25:01PM -0400, Jason Merrill via Gcc-patches wrote:
> While working on the patch for PR101460, I noticed that we were losing the
> expression location when folding class prvalue expressions. The final patch
> doesn't fold class prvalues, but this still seems a worthwhile
On Mon, Sep 14, 2020 at 12:45:33PM -0400, Nathan Sidwell wrote:
> Now we consistently mark local externs with DECL_LOCAL_DECL_P, we can
> teach the template machinery not to give them a TEMPLATE_DECL head,
> and the instantiation machinery treat them as the local specialiations
> they are. (openmp
This patch implements a new warning, -Wsizeof-array-div. It warns about
code like
int arr[10];
sizeof (arr) / sizeof (short);
where we have a division of two sizeof expressions, where the first
argument is an array, and the second sizeof does not equal the size
of the array element. See e.g
On Mon, Sep 14, 2020 at 12:53:18PM -0400, Nathan Sidwell wrote:
> On 9/14/20 12:49 PM, Marek Polacek wrote:
> > On Mon, Sep 14, 2020 at 12:45:33PM -0400, Nathan Sidwell wrote:
> > > Now we consistently mark local externs with DECL_LOCAL_DECL_P, we can
> > > teach the template machinery not to give
On Mon, Sep 14, 2020 at 11:13:18AM -0400, Jason Merrill via Gcc-patches wrote:
> On Mon, Jun 29, 2020 at 1:25 PM Martin Liška wrote:
> >
> > On 6/29/20 4:57 PM, Marek Polacek wrote:
> > > On Mon, Jun 29, 2020 at 09:51:57AM +0200, Martin Liška wrote:
> > >> O
On Mon, Sep 14, 2020 at 08:39:36PM +, Joseph Myers wrote:
> On Mon, 14 Sep 2020, Marek Polacek via Gcc-patches wrote:
>
> > so I followed suit. In the C++ FE this was rather easy, because
> > finish_parenthesized_expr already set TREE_NO_WARNING. In the C FE
> > it
On Tue, Sep 15, 2020 at 09:04:41AM +0200, Jakub Jelinek via Gcc-patches wrote:
> On Mon, Sep 14, 2020 at 09:30:44PM -0400, Marek Polacek via Gcc-patches wrote:
> > --- a/gcc/c/c-tree.h
> > +++ b/gcc/c/c-tree.h
> > @@ -147,6 +147,11 @@ struct c_expr
> > et
Here we ICE in char_span::subspan because the offset it gets is -1.
It's -1 because get_substring_ranges_for_loc gets a location whose
column was 0. That only happens in testcases like the attached where
we're dealing with extremely long lines (at least 4065 chars it seems).
This does happen in pr
On Wed, Sep 16, 2020 at 03:15:19PM -0400, David Malcolm via Gcc-patches wrote:
> On Wed, 2020-09-16 at 11:16 -0400, Marek Polacek wrote:
> > Here we ICE in char_span::subspan because the offset it gets is -1.
> > It's -1 because get_substring_ranges_for_loc gets a location whose
> > column was 0.
Bugzilla inspection turned up a bunch of old(er) PRs that have been
fixed. Let's include them not to regress in the future.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/87530
PR c++/58156
PR c++/68828
PR c++/86002
PR c++/91525
PR c++/96223
Ping.
On Thu, Sep 10, 2020 at 06:15:24PM -0400, Marek Polacek via Gcc-patches wrote:
> To quickly recap, P0846 says that a name is also considered to refer to
> a template if it is an unqualified-id followed by a < and name lookup
> finds either one or more functions or finds nothin
[temp.deduct.guide]p3: Two deduction guide declarations in the same
translation unit for the same class template shall not have equivalent
parameter-declaration-clauses.
So let's detect that.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
gcc/cp/ChangeLog:
PR c++/97099
This PR points out that we accept
template struct tuple { tuple(T); }; // #1
template explicit tuple(T t) -> tuple; // #2
tuple t = { 1 };
despite the 'explicit' deduction guide in a copy-list-initialization
context. That's because in deduction_guides_for we first find the
user-defined ded
I noticed that clang++ has this CTAD warning and thought that it might
be useful to have it. From clang++: "Some style guides want to allow
using CTAD only on types that "opt-in"; i.e. on types that are designed
to support it and not just types that *happen* to work with it."
So this warning warn
Fixed by r11-2998, which fixed this ICE too.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/90199
* g++.dg/cpp1y/constexpr-90199.C: New test.
---
gcc/testsuite/g++.dg/cpp1y/constexpr-90199.C | 28
1 file changed, 28 insertions(+)
create mode 100644 gc
We crash here because since r11-3302 the C FE uses codes like SWITCH_STMT
in the else branches in the attached test, and inchash::add_expr in
do_warn_duplicated_branches doesn't handle these front-end codes. In
the C++ FE this works because by the time we get to do_warn_duplicated_branches
we've a
On Mon, Sep 21, 2020 at 10:41:19AM -0700, sunil.k.pandey via Gcc-patches wrote:
> On Linux/x86_64,
>
> 79f4e20dd1280e6a44736070b0d5213f9a8f85d4 is the first bad commit
> commit 79f4e20dd1280e6a44736070b0d5213f9a8f85d4
> Author: Martin Liska
> Date: Wed Sep 2 14:30:16 2020 +0200
>
> Use SIZ
On Mon, Sep 21, 2020 at 01:04:27AM -0400, Jason Merrill via Gcc-patches wrote:
> On 9/19/20 5:34 PM, Marek Polacek wrote:
> > I noticed that clang++ has this CTAD warning and thought that it might
> > be useful to have it. From clang++: "Some style guides want to allow
> > using CTAD only on types
DR 1722 clarifies that the conversion function from lambda to pointer to
function should be noexcept(true).
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
gcc/cp/ChangeLog:
PR c++/90583
DR 1722
* lambda.c (maybe_add_lambda_conv_op): Mark the conversion funct
On Tue, Sep 22, 2020 at 09:07:36AM +0200, Martin Liška wrote:
> On 9/21/20 9:43 PM, Marek Polacek wrote:
> > Ok for trunk? Tested by running timevar2.C a couple of dozen times.
>
> Thank you for the fix. It seems to me obvious, I would install it.
Ok, I've pushed the patch.
Marek
On Tue, Sep 22, 2020 at 10:30:00AM +0200, Martin Liška wrote:
> On 9/22/20 9:47 AM, Christophe Lyon wrote:
> > On Wed, 2 Sep 2020 at 15:29, Martin Liška wrote:
> > >
> > > On 9/1/20 4:04 PM, Jan Hubicka wrote:
> > > > > The patch is about usage of MiB in memory allocation reports.
> > > > > I see
On Tue, Sep 22, 2020 at 09:02:08AM -0400, Marek Polacek via Gcc-patches wrote:
> On Tue, Sep 22, 2020 at 10:30:00AM +0200, Martin Liška wrote:
> > On 9/22/20 9:47 AM, Christophe Lyon wrote:
> > > On Wed, 2 Sep 2020 at 15:29, Martin Liška wrote:
> > > >
> >
Ping.
On Tue, Sep 15, 2020 at 04:33:05PM -0400, Marek Polacek via Gcc-patches wrote:
> On Tue, Sep 15, 2020 at 09:04:41AM +0200, Jakub Jelinek via Gcc-patches wrote:
> > On Mon, Sep 14, 2020 at 09:30:44PM -0400, Marek Polacek via Gcc-patches
> > wrote:
> > > --- a/gcc/c/
On Tue, Sep 22, 2020 at 08:18:09PM -0600, Sandra Loosemore wrote:
> On 9/20/20 5:08 PM, Marek Polacek via Gcc-patches wrote:
> > We crash here because since r11-3302 the C FE uses codes like SWITCH_STMT
> > in the else branches in the attached test, and incha
This new warning can be used to prevent expensive copies inside range-based
for-loops, for instance:
struct S { char arr[128]; };
void fn () {
S arr[5];
for (const auto x : arr) { }
}
where auto deduces to S and then we copy the big S in every iteration.
Using "const auto &x" would
On Fri, Sep 25, 2020 at 04:09:44PM -0400, Jason Merrill via Gcc-patches wrote:
> On 9/24/20 8:05 PM, Marek Polacek wrote:
> > This new warning can be used to prevent expensive copies inside range-based
> > for-loops, for instance:
> >
> >struct S { char arr[128]; };
> >void fn () {
> >
On Sat, Sep 26, 2020 at 01:22:41AM -0400, Jason Merrill wrote:
> > +bool
> > +ref_conv_binds_directly_p (tree type, tree expr)
> > +{
> > + gcc_assert (TYPE_REF_P (type));
> > + conversion *conv = implicit_conversion (type, TREE_TYPE (expr), expr,
> > + /*c_cas
On Fri, Sep 25, 2020 at 04:31:16PM -0600, Martin Sebor wrote:
> On 9/24/20 6:05 PM, Marek Polacek via Gcc-patches wrote:
> > This new warning can be used to prevent expensive copies inside range-based
> > for-loops, for instance:
> >
> >struct S { char
On Tue, Sep 22, 2020 at 04:07:41PM -0400, Jason Merrill wrote:
> On 9/22/20 1:29 PM, Marek Polacek wrote:
> > Ping.
>
> The C++ change is OK.
Ping for the C parts.
> > On Tue, Sep 15, 2020 at 04:33:05PM -0400, Marek Polacek via Gcc-patches
> > wrote:
> > >
Ping.
On Sat, Sep 19, 2020 at 05:33:36PM -0400, Marek Polacek via Gcc-patches wrote:
> This PR points out that we accept
>
> template struct tuple { tuple(T); }; // #1
> template explicit tuple(T t) -> tuple; // #2
> tuple t = { 1 };
>
> despite the 'explic
101 - 200 of 1049 matches
Mail list logo
