Hi,
On Sun, Mar 27, 2022 at 06:25:16PM -0300, Alexandre Oliva via Gcc-patches wrote:
> Hello, Marek,
>
> The patch looks good to me, and I'd have no trouble approving it if we
> were in stage1. Since we aren't, I'd prefer if we waited for another
> build system maintainer to give it a look, if
The attached 93280 test no longer ICEs but looks like it was never added to the
testsuite. The 104583 test, modified so that it closely resembles 93280, still
ICEs.
The problem is that in 104583 we have a value-init from {} (the line A a{};),
so this code in convert_like_internal
7960
On Fri, Mar 25, 2022 at 12:07:31PM -0400, Patrick Palka via Gcc-patches wrote:
> When an if-stmt is deemed non-constant because both of its branches are
> non-constant, we issue a rather generic error which, given that it points
> to the 'if' token, misleadingly suggests the condition is at fault:
On Fri, Mar 25, 2022 at 09:36:10AM -0400, Jason Merrill wrote:
> On 3/24/22 18:43, Marek Polacek wrote:
> > On Thu, Mar 24, 2022 at 05:12:12PM -0400, Jason Merrill wrote:
> > > On 3/24/22 15:56, Marek Polacek wrote:
> > > > On Thu, Mar 24, 2022 at 12:02:29PM -0400, Jason Merrill wrote:
> > > > >
On Thu, Mar 24, 2022 at 05:12:12PM -0400, Jason Merrill wrote:
> On 3/24/22 15:56, Marek Polacek wrote:
> > On Thu, Mar 24, 2022 at 12:02:29PM -0400, Jason Merrill wrote:
> > > On 3/24/22 11:49, Marek Polacek wrote:
> > > > I started looking into this PR because in GCC 4.9 we were able to
> > > >
On Thu, Mar 24, 2022 at 11:40:11AM -0400, Jason Merrill wrote:
> On 3/18/22 17:55, Marek Polacek wrote:
> > On Fri, Mar 11, 2022 at 06:46:42PM -0500, Jason Merrill wrote:
> > > On 3/10/22 18:04, Marek Polacek wrote:
> > > > Since r9-6073 cxx_eval_store_expression preevaluates the value to
> > > >
On Thu, Mar 24, 2022 at 12:02:29PM -0400, Jason Merrill wrote:
> On 3/24/22 11:49, Marek Polacek wrote:
> > I started looking into this PR because in GCC 4.9 we were able to
> > detect the invalid
> >
> >struct alignas(void) S{};
> >
> > but I broke it in r210262.
> >
> > It's ill-formed
On Thu, Mar 24, 2022 at 09:32:19AM -0400, Jason Merrill wrote:
> On 3/23/22 19:26, Marek Polacek wrote:
> > On Wed, Mar 23, 2022 at 04:35:32PM -0400, Jason Merrill wrote:
> > > On 3/22/22 19:55, Marek Polacek wrote:
> > > > This is a crash where a FIX_TRUNC_EXPR gets into tsubst_copy_and_build
> >
I started looking into this PR because in GCC 4.9 we were able to
detect the invalid
struct alignas(void) S{};
but I broke it in r210262.
It's ill-formed code in C++:
[dcl.align]/3: "An alignment-specifier of the form alignas(type-id) has
the same effect as alignas(alignof(type-id))", and
On Wed, Mar 23, 2022 at 04:35:32PM -0400, Jason Merrill wrote:
> On 3/22/22 19:55, Marek Polacek wrote:
> > This is a crash where a FIX_TRUNC_EXPR gets into tsubst_copy_and_build
> > where it hits gcc_unreachable ().
> >
> > The history of tsubst_copy_and_build/FIX_TRUNC_EXPR is such that it
> >
This is a crash where a FIX_TRUNC_EXPR gets into tsubst_copy_and_build
where it hits gcc_unreachable ().
The history of tsubst_copy_and_build/FIX_TRUNC_EXPR is such that it
was introduced in r181478, but it did the wrong thing, whereupon it
was turned into gcc_unreachable () in r258821 (see this
On Tue, Mar 22, 2022 at 08:39:21PM +, Ed Catmur wrote:
> If two arrays do not have the exact same element type including
> qualification, this could be e.g. f(int (&&)[]) vs. f(int const (&)[]), which
> can still be distinguished by the lvalue-rvalue tiebreaker.
>
> By tightening this
This patch fixes two kinds of wrong -Wmissing-field-initializers
warnings. Our docs say that this warning "does not warn about designated
initializers", but we give a warning for
1) the array case:
struct S {
struct N {
int a;
int b;
} c[1];
} d = {
.c[0].a = 1,
On Fri, Mar 11, 2022 at 06:46:42PM -0500, Jason Merrill wrote:
> On 3/10/22 18:04, Marek Polacek wrote:
> > Since r9-6073 cxx_eval_store_expression preevaluates the value to
> > be stored, and that revealed a crash where a template code (here,
> > code=IMPLICIT_CONV_EXPR) leaks into cxx_eval*.
> >
On Wed, Mar 16, 2022 at 06:54:51AM +0530, Siddhesh Poyarekar wrote:
> On 16/03/2022 02:06, Martin Sebor wrote:
> > The intended use of the strncmp bound is to limit the comparison to
> > at most the size of the arrays or (in a subset of cases) the length
> > of an initial substring. Providing an
Zero-length pack expansions are treated as if no list were provided
at all, that is, with
template struct S { };
template
void g() {
S...>;
}
g will result in S<>. In the following test we have something
similar:
template
using IsOneOf = disjunction...>;
and then we have
It was high time I updated our C++ DR table.
Pushed.
---
htdocs/projects/cxx-dr-status.html | 153 +++--
1 file changed, 122 insertions(+), 31 deletions(-)
diff --git a/htdocs/projects/cxx-dr-status.html
b/htdocs/projects/cxx-dr-status.html
index b49a97f2..63ec6d51
On Mon, Mar 14, 2022 at 01:48:21PM +0100, David Seifert via Gcc-patches wrote:
> Bug: https://bugs.gentoo.org/654748
>
> gcc/configure.ac
> * Add --enable-systemtap switch to explicitly allow for
> disabling systemtap even if the target libc supports it.
> ---
> gcc/configure.ac
On Thu, Mar 10, 2022 at 05:04:59PM -0500, Marek Polacek via Gcc-patches wrote:
> Since r9-6073 cxx_eval_store_expression preevaluates the value to
> be stored, and that revealed a crash where a template code (here,
> code=IMPLICIT_CONV_EXPR) leaks into cxx_eval*.
>
> It happen
Since r9-6073 cxx_eval_store_expression preevaluates the value to
be stored, and that revealed a crash where a template code (here,
code=IMPLICIT_CONV_EXPR) leaks into cxx_eval*.
It happens because we're performing build_vec_init while processing
a template, which calls get_temp_regvar which
This is an ICE-on-invalid with "auto operator delete[] (void *)" whose
return type must be void. The return type is checked in coerce_delete_type
but we never got there in this test, because we took the wrong path in
grokdeclarator, set type to error_mark_node, ended up creating a FIELD_DECL
with
On Tue, Mar 08, 2022 at 02:47:42PM -0500, Jason Merrill wrote:
> On 3/2/22 14:31, Marek Polacek wrote:
> > 104752 points out that
> >
> >template
> >concept C = true;
> >auto y = C auto(1);
> >
> > is ill-formed as per [dcl.type.auto.deduct]: "For an explicit type
> > conversion,
>
In r10-6329 I tried to optimize the number of calls to v_d_e_p in
convert_nontype_argument by remembering whether the expression was
value-dependent in a bool flag. I did that wrongly assuming that its
value-dependence will not be changed by build_converted_constant_expr.
This testcase shows that
On Tue, Mar 08, 2022 at 10:24:50AM -0600, Segher Boessenkool wrote:
> On Tue, Mar 08, 2022 at 05:12:43PM +0100, Jakub Jelinek wrote:
> > On Tue, Mar 08, 2022 at 09:49:15AM -0600, Segher Boessenkool wrote:
> > > > But like I said above, even if we didn't copy these XVECLEN 0 rtvecs,
> > > > the
On Tue, Mar 08, 2022 at 05:12:43PM +0100, Jakub Jelinek wrote:
> On Tue, Mar 08, 2022 at 09:49:15AM -0600, Segher Boessenkool wrote:
> > > But like I said above, even if we didn't copy these XVECLEN 0 rtvecs,
> > > the crash would not go away.
> >
> > An rtvec should never have length 0. Look at
On Tue, Mar 08, 2022 at 09:49:15AM -0600, Segher Boessenkool wrote:
> On Tue, Mar 08, 2022 at 10:25:45AM -0500, Marek Polacek wrote:
> > On Tue, Mar 08, 2022 at 09:14:56AM -0600, Segher Boessenkool wrote:
> > > On Tue, Mar 08, 2022 at 10:08:25AM -0500, Marek Polacek wrote:
> > > > ...I don't see
On Tue, Mar 08, 2022 at 09:14:56AM -0600, Segher Boessenkool wrote:
> Hi!
>
> On Tue, Mar 08, 2022 at 10:08:25AM -0500, Marek Polacek wrote:
> > On Mon, Mar 07, 2022 at 07:19:09PM -0600, Segher Boessenkool wrote:
> > > On Mon, Mar 07, 2022 at 07:03:17PM -0500, Marek
On Mon, Mar 07, 2022 at 07:19:09PM -0600, Segher Boessenkool wrote:
> On Mon, Mar 07, 2022 at 07:03:17PM -0500, Marek Polacek via Gcc-patches wrote:
> > In r270550, Jakub fixed classify_insn to handle asm goto: if the asm can
> > jump to a label, the insn should be a JUMP_INSN.
&
In r270550, Jakub fixed classify_insn to handle asm goto: if the asm can
jump to a label, the insn should be a JUMP_INSN.
However, as the following testcase shows, non-null ASM_OPERANDS_LABEL_VEC
doesn't guarantee that the rtx has any actual labels it can branch to.
Here, the rtvec has 0 elements
On Fri, Feb 25, 2022 at 12:04:32AM +, Joseph Myers wrote:
> On Thu, 24 Feb 2022, Marek Polacek via Gcc-patches wrote:
>
> > gmp/mpfr/mpc/isl are DSOs I believe and therefore always PIC.
>
> They are *not* DSOs when built in-tree (see the use of --disable-shared in
&g
104752 points out that
template
concept C = true;
auto y = C auto(1);
is ill-formed as per [dcl.type.auto.deduct]: "For an explicit type conversion,
T is the specified type, which shall be auto." which doesn't allow
type-constraint auto.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok
Attributes deprecated and unavailable are largely the same, except
that the former produces a warning whereas the latter produces an error.
So is_late_template_attribute should treat them the same. Confirmed by
Iain that this divergence is not intentional:
On Mon, Feb 28, 2022 at 12:31:37PM -0400, Jason Merrill wrote:
> On 2/22/22 17:46, Marek Polacek wrote:
> > Here we have a forward declaration of Parameter for which we create
> > an implicit typedef, which is a TYPE_DECL. Then, when looking it up
> > at template definition time,
On Mon, Feb 28, 2022 at 04:30:01PM +, Iain Sandoe wrote:
>
>
> > On 28 Feb 2022, at 16:13, Jason Merrill wrote:
> >
> > On 2/25/22 17:59, Marek Polacek wrote:
> >> [ Most likely a GCC 13 patch, but I'm posting it now so that I don't lose
> >> it. ]
> >> When looking into the other PR I
On Mon, Feb 28, 2022 at 12:16:47PM -0400, Jason Merrill wrote:
> On 2/25/22 17:59, Marek Polacek wrote:
> > When processing a template, the enumerators we build don't have a type
> > yet. But is_late_template_attribute is not prepared to see a _DECL
> > without a type, so we crash on
> >
> >
On Mon, Feb 28, 2022 at 12:13:36PM -0400, Jason Merrill wrote:
> On 2/25/22 17:59, Marek Polacek wrote:
> > [ Most likely a GCC 13 patch, but I'm posting it now so that I don't lose
> > it. ]
> >
> > When looking into the other PR I noticed that we fail to give a warning
> > for a deprecated
[ Most likely a GCC 13 patch, but I'm posting it now so that I don't lose it. ]
When looking into the other PR I noticed that we fail to give a warning
for a deprecated enumerator when the enum is in a class template. This
only happens when the attribute doesn't have an argument. The reason is
When processing a template, the enumerators we build don't have a type
yet. But is_late_template_attribute is not prepared to see a _DECL
without a type, so we crash on
enum tree_code code = TREE_CODE (type);
(I found that we don't give the "is deprecated" warning for the enumerator
'f' in
On Thu, Feb 10, 2022 at 09:10:17PM +, Joseph Myers wrote:
> Some general observations:
Thanks for the comment and sorry for the delay (I was on vacation).
> * There are various toplevel GCC subdirectories that are built for the
> host (possibly in addition to the target in some cases) but
A nice side effect of r12-1822 was improving the diagnostic
we emit for the following test.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/79493
gcc/testsuite/ChangeLog:
* g++.dg/diagnostic/undeclared1.C: New test.
---
gcc/testsuite/g++.dg/diagnostic/undeclared1.C | 7
Fixed with r10-1280.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/70077
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/noexcept76.C: New test.
---
gcc/testsuite/g++.dg/cpp0x/noexcept76.C | 17 +
1 file changed, 17 insertions(+)
create mode 100644
Here we have a forward declaration of Parameter for which we create
an implicit typedef, which is a TYPE_DECL. Then, when looking it up
at template definition time, cp_parser_template_id gets (since r12-6754)
this TYPE_DECL which it can't handle.
This patch defers lookup for implicit typedefs, a
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
This patch implements the --enable-host-pie configure option which
makes the compiler executables PIE. This can be used to enhance
protection against ROP attacks, and can be viewed as part of a wider
trend to harden binaries.
It is similar to the option --enable-host-shared, except that --e-h-s
On Fri, Feb 04, 2022 at 10:26:07AM +0100, Martin Liška wrote:
> On 2/3/22 22:51, Jakub Jelinek wrote:
> > On Thu, Feb 03, 2022 at 04:29:39PM -0500, Marek Polacek wrote:
> > > On Thu, Feb 03, 2022 at 10:13:36PM +0100, Martin Liška wrote:
> > > > On 2/3/22 19:44, Andreas Schwab wrote:
> > > > > On
On Thu, Feb 03, 2022 at 10:13:36PM +0100, Martin Liška wrote:
> On 2/3/22 19:44, Andreas Schwab wrote:
> > On Feb 03 2022, Martin Liška wrote:
> >
> > > +cd $LIB
> > > +echo "$all_dirs" | xargs mkdir -p
> > > +cd ..
> > > +
> >
> > $LIB always contains slashes.
> >
>
> And what is the problem?
Weird things are going to happen if you define your std::initializer_list
as a union. In this case, we crash in output_constructor_regular_field.
Let's not allow such a definition in the first place.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
PR c++/102434
in Liška wrote:
> > > > > On 1/24/22 23:36, Marek Polacek via Gcc-patches wrote:
> > > > > > |@@ -7820,6 +7820,10 @@ bidi contexts. @option{-Wbidi-chars=none}
> > > > > > turns the warning off. @option{-Wbidi-chars=any} warns about an
On Thu, Jan 27, 2022 at 10:17:00PM -0500, Jason Merrill wrote:
> On 1/27/22 20:02, Marek Polacek wrote:
> > @@ -11159,8 +11159,16 @@ create_array_type_for_decl (tree name, tree type,
> > tree size, location_t loc)
> > /* Figure out the index type for the array. */
> > if (size)
> > -
On Fri, Jan 28, 2022 at 04:08:18PM +0100, Martin Liška wrote:
> On 1/28/22 15:59, Marek Polacek wrote:
> > On Fri, Jan 28, 2022 at 02:53:16PM +0100, Martin Liška wrote:
> > > On 1/24/22 23:36, Marek Polacek via Gcc-patches wrote:
> > > > |@@ -7820,6 +7820,10 @@ bidi
On Fri, Jan 28, 2022 at 02:53:16PM +0100, Martin Liška wrote:
> On 1/24/22 23:36, Marek Polacek via Gcc-patches wrote:
> > |@@ -7820,6 +7820,10 @@ bidi contexts. @option{-Wbidi-chars=none} turns the
> > warning off. @option{-Wbidi-chars=any} warns about any use of bidirection
Here we ICE in unify_array_domain when we're trying to deduce the type
of an array, as in
auto(*p)[i] = (int(*)[i])0;
but unify_array_domain doesn't arbitrarily complex bounds. Another
test is, e.g.,
auto (*b)[0/0] =
where the type of the array is
<<< Unknown tree: template_type_parm
In r12-1933 I attempted to implement DR2397 aka allowing
int a[3];
auto ()[3] = a;
by removing the type_uses_auto check in create_array_type_for_decl.
That may have gone too far, because it also allows arrays of
CLASS_PLACEHOLDER_TEMPLATE and it looks like [dcl.type.class.deduct]
prohibits
On Wed, Jan 26, 2022 at 09:39:46AM -0700, Martin Sebor wrote:
> On 1/26/22 08:24, Jason Merrill via Gcc-patches wrote:
> > On 1/25/22 18:33, Marek Polacek wrote:
> > > Here, -Wuse-after-free warns about using 'this' which, on ARM, cdtors
> > > return, as mandated by the EABI. To be entirely
On Tue, Jan 25, 2022 at 05:35:20PM -0700, Martin Sebor wrote:
> On 1/25/22 16:33, Marek Polacek via Gcc-patches wrote:
> > Here, -Wuse-after-free warns about using 'this' which, on ARM, cdtors
> > return, as mandated by the EABI. To be entirely correct, it only
> > requires i
Here, -Wuse-after-free warns about using 'this' which, on ARM, cdtors
return, as mandated by the EABI. To be entirely correct, it only
requires it for C1 and C2 ctors and D2 and D1 dtors, but I don't feel
like changing that now and possibly running into issues later on.
This patch uses
Here's an updated version of the patch which uses EnumSet (great
to have it, thanks Jakub!) rather than hardcoding strings.
With this patch we accept -Wbidi-chars=none,ucn as well as -Wbidi-chars=ucn.
I think that's OK.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
On Mon, Jan 24, 2022 at 10:27:40AM -0500, Patrick Palka via Gcc-patches wrote:
> Avoid using the macro current_template_depth, which expands to an
> expression in terms of __FUNCTION__, within the signature of a function.
> Clang warns about this and MSVC rejects it.
>
> Bootstrapped and
On Fri, Jan 21, 2022 at 09:27:17AM -0500, Jason Merrill wrote:
> On 1/20/22 20:03, Marek Polacek wrote:
> > @@ -2815,12 +2816,23 @@ fixup_deferred_exception_variants (tree type, tree
> > raises)
> > cp_cv_quals var_quals = TYPE_QUALS (variant);
> > cp_ref_qualifier rqual =
On Thu, Jan 20, 2022 at 03:23:24PM -0500, Jason Merrill wrote:
> On 1/18/22 11:05, Marek Polacek wrote:
> > On Mon, Jan 17, 2022 at 01:48:48PM -0500, Jason Merrill wrote:
> > > On 1/14/22 19:22, Marek Polacek wrote:
> > > > This is a "canonical types differ for identical types" ICE, which
> > > >
This was fixed by r12-6025 and is sufficiently different from
noexcept71.C that I think we should add it.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/102338
gcc/testsuite/ChangeLog:
* g++.dg/cpp1y/noexcept2.C: New test.
---
gcc/testsuite/g++.dg/cpp1y/noexcept2.C | 20
Stephan Bergmann reported that our -Wbidi-chars breaks the build
of LibreOffice because we warn about UCNs even when their usage
is correct: LibreOffice constructs strings piecewise, as in:
aText = u"\u202D" + aText;
and warning about that is overzealous. Since no editor (AFAIK)
interprets
On Sat, Jan 15, 2022 at 09:24:05AM -0500, Patrick Palka wrote:
> On Fri, 14 Jan 2022, Marek Polacek via Gcc-patches wrote:
>
> > This is a "canonical types differ for identical types" ICE, which started
> > with r11-4682. It's a bit tricky to explain. Consider:
&
On Mon, Jan 17, 2022 at 01:48:48PM -0500, Jason Merrill wrote:
> On 1/14/22 19:22, Marek Polacek wrote:
> > This is a "canonical types differ for identical types" ICE, which started
> > with r11-4682. It's a bit tricky to explain. Consider:
> >
> >template struct S {
> > S bar()
Ping, could a global maintainer take a look at this?
On Mon, Jan 03, 2022 at 07:32:25PM -0800, H.J. Lu via Gcc-patches wrote:
> On Sat, Dec 11, 2021 at 10:44 AM H.J. Lu wrote:
> >
> > On Thu, Nov 25, 2021 at 9:54 AM H.J. Lu wrote:
> > >
> > > On Mon, Nov 1, 2021 at 7:02 AM H.J. Lu wrote:
> > >
This is a "canonical types differ for identical types" ICE, which started
with r11-4682. It's a bit tricky to explain. Consider:
template struct S {
S bar() noexcept(T::value); // #1
S foo() noexcept(T::value); // #2
};
template S S::foo() noexcept(T::value) {} // #3
We ICE
On Fri, Jan 14, 2022 at 10:23:16AM +0100, Stephan Bergmann wrote:
> On 30/11/2021 16:27, Marek Polacek wrote:
> > I guess we were concerned with programs that generate other programs.
> > Maybe UCNs should be ignored by default. There's still time to adjust
> > the behavior.
>
> Is there any
A new batch of DRs.
Pushed.
commit ecbd709b2ecb1e3c35fa4ede09bcb7ceb443def6
Author: Marek Polacek
Date: Thu Jan 6 17:06:24 2022 -0500
Update C++ DR table
diff --git a/htdocs/projects/cxx-dr-status.html
b/htdocs/projects/cxx-dr-status.html
index e8002b27..cc2afc03 100644
---
Let's use "%, %, or %" rather than "[x|y|z]" as in the rest of
our codebase.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/11?
PR c++/103758
gcc/c-family/ChangeLog:
* c-pragma.c (handle_pragma_scalar_storage_order): Use %< %> in
diagnostic messages.
On Mon, Dec 20, 2021 at 09:53:25PM +0100, Jakub Jelinek wrote:
> On Mon, Dec 20, 2021 at 03:21:04PM -0500, Jason Merrill via Gcc-patches wrote:
> > > @@ -3215,6 +3215,14 @@ check_tokens (const token_t *tokens, unsigned
> > > ntoks,
> > > plural = "s";
> > > }
On Sat, Dec 18, 2021 at 07:43:55PM -0500, Eric Gallager wrote:
> On Fri, Dec 17, 2021 at 5:59 PM Marek Polacek via Gcc-patches
> wrote:
> >
> > This fixes
> >
> > gcc/cp/parser.c:4618:41: warning: narrowing conversion of '(char)(*(str +
> > ((sizetype
I'm tired of seeing
cp/parser.c:15923:55: warning: misspelled term 'decl' in format; use
'declaration' instead [-Wformat-diag]
cp/parser.c:15925:57: warning: misspelled term 'decl' in format; use
'declaration' instead [-Wformat-diag]
every time I compile cp/parser.c, which happens...a lot.
This fixes
gcc/cp/parser.c:4618:41: warning: narrowing conversion of '(char)(*(str +
((sizetype)i)))' from 'char' to 'unsigned char' [-Wnarrowing]
4618 | unsigned char s[3] = { '\'', str[i], '\'' };
|~^
Bootstrapped/regtested on
On Fri, Dec 17, 2021 at 02:33:01PM -0500, Jason Merrill wrote:
> On 12/17/21 13:14, Marek Polacek wrote:
> > @@ -28979,7 +28979,9 @@ cp_parser_std_attribute (cp_parser *parser, tree
> > attr_ns)
> > /* A GNU attribute that takes an identifier in parameter. */
> > attr_flag =
On Thu, Dec 16, 2021 at 08:06:43PM -0500, Jason Merrill wrote:
> On 12/16/21 19:52, Marek Polacek wrote:
> > --- /dev/null
> > +++ b/gcc/testsuite/c-c++-common/Wno-attributes-6.c
> > @@ -0,0 +1,14 @@
> > +/* PR c/103649 */
> > +/* { dg-do compile { target { c || c++11 } } } */
> > +/* {
On Thu, Dec 16, 2021 at 08:13:01PM -0500, Jason Merrill wrote:
> On 12/16/21 17:36, Marek Polacek wrote:
> > + if (DECL_CLASS_TEMPLATE_P (decl)
> > + && !template_header_p
> > + && how == TAG_how::CURRENT_ONLY)
> > +{
> > + error ("%qD was declared as template but no template
For code like
template
struct bar;
struct bar {
int baz;
};
bar var;
we emit a fairly misleading and unwieldy diagnostic:
~
$ g++ -c u.cc
u.cc:6:8: error: template argument required for 'struct bar'
6 | struct bar {
|
My patch to implement -Wno-attribute=A::b caused a bogus error when
parsing
[[foo::bar(1, 2)]];
when -Wno-attributes=foo::bar was specified on the command line, because
when we create a fake foo::bar attribute and insert it into our attribute
table, it is created with max_length == 0 which
Some time ago I noticed that we don't properly delay parsing of
noexcept for member function templates. This patch fixes that.
It didn't work because even though we set CP_PARSER_FLAGS_DELAY_NOEXCEPT
in cp_parser_member_declaration, member template declarations take
a different path: we call
On Wed, Dec 15, 2021 at 04:17:37PM -0500, Jason Merrill wrote:
> On 12/15/21 15:20, Marek Polacek wrote:
> > On Mon, Dec 13, 2021 at 10:02:24AM -0500, Jason Merrill wrote:
> > > On 12/10/21 17:29, Marek Polacek wrote:
> > > > My r11-2202 was trying to enforce [dcl.type.auto.deduct]/4, which says
>
On Mon, Dec 13, 2021 at 10:02:24AM -0500, Jason Merrill wrote:
> On 12/10/21 17:29, Marek Polacek wrote:
> > My r11-2202 was trying to enforce [dcl.type.auto.deduct]/4, which says
> > "If the placeholder-type-specifier is of the form type-constraint[opt]
> > decltype(auto), T shall be the
My r11-2202 was trying to enforce [dcl.type.auto.deduct]/4, which says
"If the placeholder-type-specifier is of the form type-constraint[opt]
decltype(auto), T shall be the placeholder alone." But this made us
reject 'constexpr decltype(auto)', which, after clarification from CWG,
should be
I was curious if our auto(x) works in contexts like bit-field width
and similar. It appears that it does. Might be worth adding a test
for it.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/testsuite/ChangeLog:
* g++.dg/cpp23/auto-fncast10.C: New test.
---
On Fri, Dec 10, 2021 at 10:48:00AM -0500, Patrick Palka via Gcc-patches wrote:
> This flag is never set because non-dependent COMPOUND_EXPRs are fully
> resolved into a CALL_EXPR at template definition time (in
> build_x_compound_expr) ever since r6-5772.
>
> Bootstrapped and regtested on
On Wed, Dec 08, 2021 at 03:09:00PM -0500, Jason Merrill wrote:
> On 12/8/21 13:32, Marek Polacek wrote:
> > On Wed, Dec 08, 2021 at 09:15:05AM -0500, Jason Merrill wrote:
> > > On 12/7/21 19:25, Marek Polacek wrote:
> > > > On Mon, Dec 06, 2021 at 04:44:06PM -0500, Jason Merrill wrote:
> > > > >
On Wed, Dec 08, 2021 at 09:15:05AM -0500, Jason Merrill wrote:
> On 12/7/21 19:25, Marek Polacek wrote:
> > On Mon, Dec 06, 2021 at 04:44:06PM -0500, Jason Merrill wrote:
> > > Please also make this change to cp_parser_sizeof_operand, and add tests
> > > involving sizeof/alignof in array bounds.
On Mon, Dec 06, 2021 at 04:44:06PM -0500, Jason Merrill wrote:
> Please also make this change to cp_parser_sizeof_operand, and add tests
> involving sizeof/alignof in array bounds. OK with that change.
Turns out we reject sizeof(auto(4)) because cp_parser_type_id_1 errors
"invalid use of auto".
This test was failing on i?86 because of:
warning: width of 'A::l' exceeds its type
so change the type to 'long long' and make the test run only on arches
where sizeof(long long) == 8 to avoid failing like this again.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/testsuite/ChangeLog:
On Tue, Dec 07, 2021 at 09:59:42AM -0800, apinski--- via Gcc-patches wrote:
> From: Andrew Pinski
>
> There are a few issues here with typenames and unions (and even struct
> keywords with unions). First in cp_parser_check_class_key,
> we need to allow typenames to name union types and union key
This was fixed by r11-86.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/93614
gcc/testsuite/ChangeLog:
* g++.dg/template/lookup18.C: New test.
---
gcc/testsuite/g++.dg/template/lookup18.C | 17 +
1 file changed, 17 insertions(+)
create mode 100644
Here, decltype deduces the wrong type for certain expressions involving
bit-fields. Unlike in C, in C++ bit-field width is explicitly not part
of the type, so I think decltype should never deduce to 'int:N'. The
problem isn't that we're not calling unlowered_expr_type--we are--it's
that
On Thu, Dec 02, 2021 at 12:56:38PM -0500, Jason Merrill wrote:
> On 12/2/21 10:27, Marek Polacek wrote:
> > On Wed, Dec 01, 2021 at 11:24:58PM -0500, Jason Merrill wrote:
> > > On 12/1/21 10:16, Marek Polacek wrote:
> > > > In C++23, auto(x) is valid, so decltype(auto(x)) should also be valid,
> >
On Fri, Dec 03, 2021 at 11:27:27AM +0100, Jakub Jelinek wrote:
> Hi!
>
> The https://gcc.gnu.org/pipermail/gcc-patches/2020-November/557903.html
> change broke the following testcases. The problem is when a pragma
> namespace allows expansion (i.e. p->is_nspace && p->allow_expansion),
> e.g. the
On Wed, Dec 01, 2021 at 11:16:27PM -0500, Jason Merrill wrote:
> On 12/1/21 10:16, Marek Polacek wrote:
> > In r11-4758, I tried to fix this problem:
> >
> >int & = 0;
> >decltype(auto) j = i; // should behave like int & = i; error
> >
> > wherein do_auto_deduction was getting confused
On Wed, Dec 01, 2021 at 11:24:58PM -0500, Jason Merrill wrote:
> On 12/1/21 10:16, Marek Polacek wrote:
> > In C++23, auto(x) is valid, so decltype(auto(x)) should also be valid,
> > so
> >
> >void f(decltype(auto(0)));
> >
> > should be just as
> >
> >void f(int);
> >
> > but
On Wed, Dec 01, 2021 at 12:17:47PM -0500, Patrick Palka wrote:
> On Wed, Dec 1, 2021 at 10:26 AM Marek Polacek via Gcc-patches
> wrote:
> >
> > Here we ICE on
> >
> > int f() requires (auto(0));
> >
> > in do_auto_deduction when handling the a
Here we issue a bogus:
error: '(0 ? fake_tuple_size_v : fake_tuple_size_v)' is not a
constant expression
because cxx_constant_value in expand_integer_pack gets
*(0 ? VIEW_CONVERT_EXPR(fake_tuple_size_v) : VIEW_CONVERT_EXPR(fake_tuple_size_v))
which is a REFERENCE_REF_P and we evaluate its
In r11-4758, I tried to fix this problem:
int & = 0;
decltype(auto) j = i; // should behave like int & = i; error
wherein do_auto_deduction was getting confused with a REFERENCE_REF_P
and it didn't realize its operand was a name, not an expression, and
deduced the wrong type.
Unfortunately
Here we crash when issuing the "constraint C has type T, not bool"
error, because pp_cxx_parameter_mapping wasn't prepared to see an
anonymous template parameter. With this patch we print
error: constraint 'auto() [with = 0]' has type '',
not 'bool'
The "" is what this patch adds.
Here we ICE on
int f() requires (auto(0));
in do_auto_deduction when handling the auto: we're in a non-templated
requires-expression which are parsed under processing_template_decl == 1
and empty current_template_parms, so 'current_template_args ()' will
crash. This code is invalid as per
401 - 500 of 1048 matches
Mail list logo
