[Bug c/88392] New: Incorrect error message when using bitfields in void *pointer

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[Bug c/88392] New: Incorrect error message when using bitfields in void *pointer

kargl at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88392

            Bug ID: 88392
           Summary: Incorrect error message when using bitfields in void
                    *pointer
           Product: gcc
           Version: 8.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: [hidden email]
  Target Milestone: ---

Hello,

the following (arguably quite strange) structure declaration outputs a somewhat
misleading error message on a x86_64 host (Thanks to Mathieu Barbe for pointing
it to my attention):

$ cat b.c
struct {
   void    *v:44;
} z;
$ gcc -Wall -Wextra -fsyntax-only b.c
b.c:2:13: error: bit-field ‘v’ has invalid type
    void    *v:44;
             ^
b.c:2:13: error: width of ‘v’ exceeds its type

The first message is fine, but the second is I believe erroneous as sizeof
(void *) is 8 on that machine. A bit misleading but not a big deal, though.

All the best,
Frédéric
Reply | Threaded
Open this post in threaded view
|

[Bug c/88392] Incorrect error message when using bitfields in void *pointer

kargl at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88392

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2018-12-07
     Ever confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
I suspect error recovery parses the bogus type as 'int' to be able to continue
and report further errors.  Well, or it's simply error_mark_node which likely
has precision zero ;)