public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "f.heckenbach@fh-soft.de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/114248] New: invalid "scalar object" error
Date: Wed, 06 Mar 2024 02:05:13 +0000	[thread overview]
Message-ID: <bug-114248-4@http.gcc.gnu.org/bugzilla/> (raw)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114248

            Bug ID: 114248
           Summary: invalid "scalar object" error
           Product: gcc
           Version: 12.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: f.heckenbach@fh-soft.de
  Target Milestone: ---

% cat test.cpp  
// #pragma GCC diagnostic ignored "-Wnarrowing"
// #pragma GCC diagnostic warning "-Wnarrowing"

template <unsigned> struct S
{
  S (int, int) { }
};

// template <> using S <-1> = int;

int main ()
{
  S <-1> i { 1, 2 };
}
% g++ test.cpp 
test.cpp: In function 'int main()':
test.cpp:13:8: error: narrowing conversion of '-1' from 'int' to 'unsigned int'
[-Wnarrowing]
   13 |   S <-1> i { 1, 2 };
      |        ^
test.cpp:13:10: error: scalar object 'i' requires one element in initializer
   13 |   S <-1> i { 1, 2 };
      |          ^

The first error is correct, of course, but the second one is not because "i" is
not scalar.

Sure, the declaration of "i" is wrong, but this leaves two possible
conclusions:

- We don't know what "i" is meant to be, so any claim about it is unjustified.

- We see that the type of "i" is meant to be an instance of S which is a
struct, and not scalar. AFAIK, even potential specializations of S cannot
change this fact (cf. the commented-out line which is doubly wrong).

Interestingly, when turning the first error off or into a warning (cf. one of
the commented-out pragmas), the second error disappears as well.

I would have expected that those options/pragmas merely control if the
narrowing problem is reported, and if so, whether it causes the compilation to
fail, but apparently it does influence gcc's representation of "i" afterwards
as well.

But that's just a side note actually -- even with a clearly wrong declaration
of "i" such as

  S <""> i { 1, 2 };

gcc gives the "scalar" error which it shouldn't.

             reply	other threads:[~2024-03-06  2:05 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-06  2:05 f.heckenbach@fh-soft.de [this message]
2024-03-06  2:11 ` [Bug c++/114248] " pinskia at gcc dot gnu.org
2024-03-06  2:13 ` pinskia at gcc dot gnu.org

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=bug-114248-4@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /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).