[ Resending since this was somehow sent in HMTL mode and was scrubbed ]
On 30 Oct 2024, at 17:16, Simon Martin wrote:
> Hi,
>
> Just closing the loop on this...
>
> On 19 Oct 2024, at 11:57, Iain Sandoe wrote:
>
> On 19 Oct 2024, at 10:16, Simon Martin <si...@nasilyan.com> wrote:
>
> On 18 Oct 2024, at 10:55, Sam James wrote:
>
> Simon Martin <si...@nasilyan.com> writes:
>
> Hi Sam,
>
> Hi Simon,
>
> On 16 Oct 2024, at 22:06, Sam James wrote:
>
> Simon Martin <si...@nasilyan.com> writes:
>
> We ICE upon the following invalid code because we end up calling
> finalize_nrv_r with a RETURN_EXPR with no operand.
>
> === cut here ===
> struct X {
> ~X();
> };
> X test(bool b) {
> {
> X x;
> return x;
> }
> if (!(b)) return;
> }
> === cut here ===
>
> This patch fixes this by simply returning error_mark_node when
> detecting
> a void return in a function returning non-void.
>
> Successfully tested on x86_64-pc-linux-gnu.
>
> PR c++/117099
>
> gcc/cp/ChangeLog:
>
> * typeck.cc (check_return_expr): Return error_mark_node upon
> void return for function returning non-void.
>
> gcc/testsuite/ChangeLog:
>
> * g++.dg/parse/crash77.C: New test.
>
> ---
> gcc/cp/typeck.cc | 1 +
> gcc/testsuite/g++.dg/parse/crash77.C | 14 ++++++++++++++
> 2 files changed, 15 insertions(+)
> create mode 100644 gcc/testsuite/g++.dg/parse/crash77.C
>
> diff --git a/gcc/cp/typeck.cc b/gcc/cp/typeck.cc
> index 71d879abef1..22a6ec9a185 100644
> --- a/gcc/cp/typeck.cc
> +++ b/gcc/cp/typeck.cc
> @@ -11238,6 +11238,7 @@ check_return_expr (tree retval, bool
> *no_warning, bool *dangling)
> RETURN_EXPR to avoid control reaches end of non-void function
> warnings in tree-cfg.cc. */
> *no_warning = true;
> + return error_mark_node;
> }
> /* Check for a return statement with a value in a function that
> isn't supposed to return a value. */
> diff --git a/gcc/testsuite/g++.dg/parse/crash77.C
> b/gcc/testsuite/g++.dg/parse/crash77.C
> new file mode 100644
> index 00000000000..d3f0ae6a877
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/parse/crash77.C
> @@ -0,0 +1,14 @@
> +// PR c++/117099
> +// { dg-compile }
>
> dg-do compile
>
> Aarg, of course, thanks for spotting this! Fixed in the attached
> version.
>
> +
> +struct X {
> + ~X();
> +};
> +
> +X test(bool b) {
> + {
> + X x;
> + return x;
> + }
> + if (!(b)) return; // { dg-error "return-statement with no value" }
> +}
> --
> 2.44.0
>
> BTW, the line-endings on this seem a bit odd. Did you use
> git-send-email?
>
> I did use git-send-email indeed. What oddities do you see with line
> endings?
> cat -A over the patch file looks good.
>
> Weird -- if I open your original email in mu4e, I see a bunch of ^M at
> the end of the lines.
>
> Strange. FWIW I’m generating and sending the patches from a MacOS
> box,
> and there might be some weirdness coming from that. I’ll check and
> try
> to fix.
>
> macOS Mail messes up whitespace, for sure (but I’ve not seen it
> append <CR>).
> AFAIK “git send-email” works fine (at least no-one has reported a
> problem).
>
> maybe the editor in use thinks the target format is Windows and has
> changed
> line endings accordingly?
>
> I investigated further and the issue was actually linked to the AWS
> WorkMail SMTP server: when I use the native AWS SES one instead, my
> test
>
> messages don’t have any =0D=0A anymore.
>
I’ve permanently updated my configuration to use SES, and all my
future
git send-email’s should be good (note that this was purely a SMTP
issue,
and the commits that I actually pushed never had any \r).
Thanks, Simon
