This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [C++ Patch] PR 83921 ("[7/8 Regression] GCC rejects constexpr initialization of empty aggregate")
- From: Jason Merrill <jason at redhat dot com>
- To: Paolo Carlini <paolo dot carlini at oracle dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Nathan Sidwell <nathan at acm dot org>
- Date: Fri, 19 Jan 2018 17:28:25 -0500
- Subject: Re: [C++ Patch] PR 83921 ("[7/8 Regression] GCC rejects constexpr initialization of empty aggregate")
- Authentication-results: sourceware.org; auth=none
- References: <b9481a3d-97d9-16da-beae-f78a41b5fd8f@oracle.com>
On Thu, Jan 18, 2018 at 5:53 PM, Paolo Carlini <paolo.carlini@oracle.com> wrote:
> Hi,
>
> I'm finishing testing on x86_64-linux the below - which anyway seems very
> unlikely to cause regressions because we aren't really stress testing the
> relevant checks in potential_constant_expression_1 much, if at all (surely
> stmtexpr19.C tests static).
>
> Anyway, the issue is the following. In 239268 aka "Implement C++17 constexpr
> lambda" Jason added some checks to potential_constant_expression_1 covering
> static, thread_local and uninitialized var declaration in constexpr function
> context. Then extended to constexpr context more generally in 249382 aka
> "constexpr and static var in statement-expression", with ext/stmtexpr19.C
> covering the static case. Now, it looks like the check for uninitialized
> vars in constexpr functions context is more correctly carried out by
> check_for_uninitialized_const_var instead, because the simple check in
> potential_constant_expression_1 as-is causes the regression pointed out by
> this bug. Thus the fix below which just restricts the check in
> potential_constant_expression_1, and the testcases, one for this bug proper,
> plus one, very similar to stmtexpr19.C, double checking that we are still
> diagnosing in the statement-expression context. I also verified under the
> debugger how for constexpr-83921.C we are actually running
> check_for_uninitialized_const_var on 'f' - which obviously passes.
Seems like this code should either be removed because it's covered by
check_for_uninitialized_const_var, or it should be fixed to check
default_init_uninitialized_part.
So this code is still needed for stmtexpr19.C? Why doesn't
check_for_... handle that case?
Jason