public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jason Merrill <jason@redhat.com>
To: Matthias Kretz <m.kretz@gsi.de>, gcc-patches@gcc.gnu.org
Cc: libstdc++@gcc.gnu.org, David Malcolm <dmalcolm@redhat.com>,
	Jonathan Wakely <jwakely@redhat.com>
Subject: Re: [PATCH] Add gnu::diagnose_as attribute
Date: Tue, 15 Jun 2021 11:51:20 -0400	[thread overview]
Message-ID: <9926a8f5-5513-11eb-75a2-ef405e14ff1a@redhat.com> (raw)
In-Reply-To: <2132675.qKCeTcHjAi@excalibur>

On 6/11/21 6:01 AM, Matthias Kretz wrote:
> How can we make progress here? I could try to produce some "Tony Tables" of
> diagnostic output of my modified stdx::simd. I believe it's a major
> productivity boost to see abbreviated / "obfuscated" diagnostics *out-of-the
> box* (with the possibility to opt-out). Actually, it already *is* a
> productivity boost to me. Understanding diagnostics has improved from
> 
> "1. ooof, I'm not going to read this, let me rather guess what the issue was
> 2. sh** I have to read it
> 3. several minutes later: I finally found the five words to understand the
> problem; I could use a break"
> 
> to
> 
> "1. right, let me check that"

That's great.

> For reference I'll attach my stdx::simd diagnose_as patch.
> 
> We could also talk about extending the feature to provide more information
> about the diagnose_as substition. E.g. print a list of all diagnose_as
> substitutions, which were used, at the end of the output stream. Or simpler,
> print "note: some identifiers were simplified, use -fno-diagnostics-use-
> aliases to see their real names".

Or perhaps before the first use of a name that doesn't correspond to a 
source-level name.

> On Tuesday, 1 June 2021 21:12:18 CEST Jason Merrill wrote:
>>> Right, but then two of my design goals can't be met:
>>>
>>> 1. Diagnostics have an improved signal-to-noise ratio out of the box.
>>>
>>> 2. We can use replacement names that are not valid identifiers.
>>
>> This is the basic disconnect: I think that these goals are
>> contradictory, and that replacement names that are not valid identifiers
>> will just confuse users that don't know about them.
>>
>> If a user sees stdx::foo in a diagnostic and then tries to refer to
>> stdx::foo and gets an error, the diagnostic is not more helpful than one
>> that uses the fully qualified name.
>>
>> Jonathan, David, any thoughts on this issue?

> -struct _Scalar;
> +  struct [[__gnu__::__diagnose_as__("scalar")]] _Scalar;

>  template <int _Np>
> -  struct _Fixed;
> +  struct [[__gnu__::__diagnose_as__("fixed_size")]] _Fixed;

Thes two could be the variant of the attribute without an explicit 
string, attached to the alias-declaration.

> +using __sse [[__gnu__::__diagnose_as__("[SSE]")]] = _VecBuiltin<16>;
> +using __avx [[__gnu__::__diagnose_as__("[AVX]")]] = _VecBuiltin<32>;
> +using __avx512 [[__gnu__::__diagnose_as__("[AVX512]")]] = _VecBltnBtmsk<64>;
> +  using __odr_helper [[__gnu__::__diagnose_as__("[ODR helper]")]]

These [] names seem like minimal improvements over the __ names that you 
would get from the attribute without an explicit string.

> +	inline namespace parallelism_v2 [[__gnu__::__diagnose_as__("std\u2093")]] {

This could go on std::experimental itself, along with my proposed change 
to hide inline namespaces by default (with a note similar to the one above).

Jason


  reply	other threads:[~2021-06-15 15:51 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <14205410.xuKvIAzr1H@excalibur>
     [not found] ` <20210427094648.GL3008@redhat.com>
2021-05-04 11:13   ` Matthias Kretz
2021-05-04 13:34     ` David Malcolm
2021-05-04 14:23       ` Matthias Kretz
2021-05-04 14:32         ` Matthias Kretz
2021-05-04 19:00         ` David Malcolm
2021-05-04 19:22           ` Matthias Kretz
2021-05-14 16:05     ` Martin Sebor
2021-05-26 21:33       ` Matthias Kretz
2021-05-27 17:39     ` Jason Merrill
2021-05-27 18:54       ` Matthias Kretz
2021-05-27 21:15         ` Jason Merrill
2021-05-27 22:07           ` Matthias Kretz
2021-05-28  3:05             ` Jason Merrill
2021-05-28  7:42               ` Matthias Kretz
2021-06-01 19:12                 ` Jason Merrill
2021-06-01 21:01                   ` Matthias Kretz
2021-06-11 10:01                   ` Matthias Kretz
2021-06-15 15:51                     ` Jason Merrill [this message]
2021-06-15 20:56                       ` Matthias Kretz
2021-06-16  0:48                         ` Jason Merrill
2021-06-22  7:30                           ` Matthias Kretz
2021-06-22 19:52                             ` Jason Merrill
2021-06-22 20:01                               ` Matthias Kretz
2021-06-22 20:12                                 ` Jason Merrill
2021-07-01  9:28                                   ` Matthias Kretz
2021-07-01 15:18                                     ` Jason Merrill
2021-07-05 14:18                                       ` Matthias Kretz
2021-07-07 22:34                                         ` Jason Merrill
2021-07-07  8:23                               ` Matthias Kretz
2021-07-08  1:19                                 ` Jason Merrill

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9926a8f5-5513-11eb-75a2-ef405e14ff1a@redhat.com \
    --to=jason@redhat.com \
    --cc=dmalcolm@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jwakely@redhat.com \
    --cc=libstdc++@gcc.gnu.org \
    --cc=m.kretz@gsi.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).