From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) by sourceware.org (Postfix) with ESMTPS id 9DC71385841C; Fri, 18 Nov 2022 18:26:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9DC71385841C Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ed1-x52b.google.com with SMTP id i29so772975edj.11; Fri, 18 Nov 2022 10:26:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=QIOy7ykxYsTpnEBjllKrbusHbTPErtbjJF7fmbPdY2I=; b=pT9SGG4mIZTEd4WHWW1fYQZ1b5yO5t47ZcT3zLWPRELzvvPXrK0VM5WRnWe3vxyRQ4 RZXEslVlnG3x8h89Q/M53aRvv4voFWrd05Uqub+itLOM5ivei3GMDAVYdrb4ci3J6A7c vTf9s4/eHqA9V4y986o+aG8UT29ibzzN9beGd2w7YUToR+FYoIIP0se2W5h9SgsbRGvh 8uILZtv+0vTYUCinwHmkTLSZ0p2rmX1kV8hoWFOmuypQT3+jGvXnBaVdl/My7sd1cyCp nJkzvEYsiHQ8XJenzMdxVus9ox01jHWOMeTfwL01gHV2xySLsziSVay2bnwdozimjCTq KBqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=QIOy7ykxYsTpnEBjllKrbusHbTPErtbjJF7fmbPdY2I=; b=i7717ggkZGKJVtgWxXGgHXUKcVlDxi/YcNCczXzJnA3Sk2QJZ+MWqYgj8TyHAm91yf c6JJVP1sAIW5g/mV27YEXkd20mOBvanJ9iKxmWSTmbGw+PQRox8eWd7y/ZfbR+B6Bmig UTx/kpfzhng7bjyPZwVv/faVcDeA4l9/aCAJrGrY3806/xHRIUJDDWMQ6cyd8WAqyG2L 6IqngRTFoDVq2rc8qgiMRCAND9pAxdhojGkRQWEnBjLE9qkMhubyFGKptfiwhw1gDgAL tBvmZNXOHpns3m70ePe9cTS2gV3PK8I8fUrrOxkC4dP0Lwet2pN9EpWHUi73cwh87UHg sczQ== X-Gm-Message-State: ANoB5pmDiexaYgDlCuFJNZow0cgPcvMdjvwFCWnP12dG72qQMgNi8/A/ 2g8/f6RbXO5KSgQMWvFtvS8= X-Google-Smtp-Source: AA0mqf7ORIJ5Jy5Edc6/eU8qIUh2UHpXuq6ik/sn1uWRvXUiFQxJUEm65dfoc6Vn5UolHFldDQpc0g== X-Received: by 2002:aa7:c9c3:0:b0:461:8f21:5f12 with SMTP id i3-20020aa7c9c3000000b004618f215f12mr7326643edt.54.1668795964387; Fri, 18 Nov 2022 10:26:04 -0800 (PST) Received: from nbbrfq ([2001:871:227:81c4:d7ff:3a0e:48da:5fe3]) by smtp.gmail.com with ESMTPSA id z15-20020a170906434f00b0072af4af2f46sm1988908ejm.74.2022.11.18.10.26.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 18 Nov 2022 10:26:04 -0800 (PST) Date: Fri, 18 Nov 2022 19:26:00 +0100 From: Bernhard Reutner-Fischer To: Jason Merrill Cc: rep.dot.nop@gmail.com, gcc-patches@gcc.gnu.org, Bernhard Reutner-Fischer , Nathan Sidwell Subject: Re: [PATCH 2/5] c++: Set the locus of the function result decl Message-ID: <20221118192600.508d55c0@nbbrfq> In-Reply-To: <3e8757c8-cb16-9446-6953-5d6de9deeb5b@redhat.com> References: <20221112234543.95441-1-aldot@gcc.gnu.org> <20221112234543.95441-3-aldot@gcc.gnu.org> <20221117095647.42fefe06@nbbrfq> <4fcd1dd6-1691-6974-f181-3c57a4c305c9@redhat.com> <20221117200208.3048de7a@nbbrfq> <8b923e25-db47-4d68-504f-6b3c664349c7@redhat.com> <20221118114938.48a39cbd@nbbrfq> <3e8757c8-cb16-9446-6953-5d6de9deeb5b@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Fri, 18 Nov 2022 11:06:29 -0500 Jason Merrill wrote: > Ah, so the problem is deferred parsing of methods, rather than > templates. Building the DECL_RESULT sooner does seem like the right > approach to handling that, whether that's in grokfndecl or grokmethod. > >> I'd like to get the template case right while we're looking at it. I > >> guess I can add that myself if you're done trying. Please do, i'd be glad if you could take care of these locations. It icks me that they are wrong, and be it just for the sake of QOI :) > >>> Is the hunk for normal functions OK for trunk? > >> > >> You also need a testcase for the desired behavior, with e.g. > >> { dg-error "23:" } > > > > I'd have to think about how to test that with trunk, yes. > > There are no existing warnings that want to point to the return type, > > are there? > > Good point. Do any of your later patches add such a warning? I didn't mean to have that -Wtype-demotion applied in it's current form, or at all, so no. I was curious if anybody liked the idea of pointing out such code though. I've had no feedback but everybody is or was busy with end of stage3 and real work, so that's expected. The only real purpose i had for it was to find places in the Fortran FE that could use narrower types, bools for the most part. IMHO it would be a nice thing to have, but then, embedded software usually is cautious to use sensible types in the first place and the rest doesn't really care anyway, supposedly. Maybe it would have made more sense to just do an IPA pass that does the demotion silently where it's feasable. As to the test, i don't think these locations in the c++ FE are changed all that often, so chances are rather low that they would be broken once in. So, short of trying to use the result decl locus for any existing -Wreturn-type, -Waggregate-return, -Wno-return-local-addr, -Wsuggest-attribute=[pure|const|noreturn|format|malloc] or another existing warning that would be concerned, we could, as said, have a plugin with fix-it hints and ideally -fdiagnostics-generate-patch to test these bits. Patch generation has the advantage that it will ICE more often than not if asked to generate patches for locations that have a negative relative start (think: memcpy(...,..., -7)), which you can get easily if the locations are off IMHO. > > Maybe a g++.dg/plugin/result_decl_plugin.c then.