[Bug c++/105499] New: inconsistency between -Werror=c++-compat and g++ in __extension__ block

[Bug c++/105499] New: inconsistency between -Werror=c++-compat and g++ in __extension__ block

[vincent-gcc at vinc17 dot net]

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

            Bug ID: 105499
           Summary: inconsistency between -Werror=c++-compat and g++ in
                    __extension__ block
           Product: gcc
           Version: 11.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: vincent-gcc at vinc17 dot net
  Target Milestone: ---

Consider

int *f (void *q)
{
  return __extension__ ({ int *p = q; p; });
}

With GCC 11.3.0 under Debian (Debian package), I get the following:

$ gcc -Werror=c++-compat -c tst.c
$ g++ -c tst.c
tst.c: In function ‘int* f(void*)’:
tst.c:3:36: error: invalid conversion from ‘void*’ to ‘int*’ [-fpermissive]
    3 |   return __extension__ ({ int *p = q; p; });
      |                                    ^
      |                                    |
      |                                    void*

so no errors with "gcc -Werror=c++-compat", but an error with g++. This is not
consistent. Either this is regarded as a valid extension in C++ so that both
should succeed, or this is not valid C++ code even in __extension__ so that
both should fail.

Same issue with various GCC versions from 4.9 to 11.3.0.

AFAIK, the purpose of -Wc++-compat is to test whether code would still pass
when replacing C compilation by C++ (there might be false positives or false
negatives, but this should not be the case with the above example).

FYI, I got the above issue while testing GNU MPFR (tested with
-Werror=c++-compat first, and with g++ a bit later in a more extensive test).

[Bug c++/105499] inconsistency between -Werror=c++-compat and g++ in __extension__ block

[egallager at gcc dot gnu.org]

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

Eric Gallager <egallager at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=71003,
                   |                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=87274
                 CC|                            |egallager at gcc dot gnu.org

--- Comment #1 from Eric Gallager <egallager at gcc dot gnu.org> ---
This is probably another one of those issues with how the preprocessor works in
C++ mode in general; see for example bug 71003 and bug 87274

[Bug c++/105499] inconsistency between -Werror=c++-compat and g++ in __extension__ block

[vincent-gcc at vinc17 dot net]

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

--- Comment #2 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
(In reply to Eric Gallager from comment #1)
> This is probably another one of those issues with how the preprocessor works
> in C++ mode in general; see for example bug 71003 and bug 87274

Note, however, that bug 71003 and bug 87274 are about parsing (complaints about
an escape sequence and numeric literals), while in this PR, the error occurs at
the semantic level (type issues). Does the preprocessor know about types?

[Bug c/105499] inconsistency between -Werror=c++-compat and g++ in __extension__ block

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c++                         |c
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2022-10-31
     Ever confirmed|0                           |1

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed reduced testcase:
void f (void *q)
{
  __extension__ int *p1 = q;
}

At first I thought it was an issue with the statement expression but nope, it
is just __extension__ vs -Wc++-compat .

[Bug c/105499] inconsistency between -Werror=c++-compat and g++ in __extension__ block

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|diagnostic                  |documentation

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
__extension__ disables all compatibility warnings.

This is by design really as headers sometimes needs to be written using C code
and need to turn off these warnings. 

The documentation should mention that though like it does for -Wc90-c99-compat
, -Wc99-c11-compat and -Wc11-c2x-compat .

https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Warning-Options.html#index-Wc_002b_002b-compat

[Bug c/105499] inconsistency between -Werror=c++-compat and g++ in __extension__ block

[vincent-gcc at vinc17 dot net]

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

--- Comment #5 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
(In reply to Andrew Pinski from comment #4)
> __extension__ disables all compatibility warnings.
> 
> This is by design really as headers sometimes needs to be written using C
> code and need to turn off these warnings. 

I don't understand why. If the code is designed only for C (i.e. it will not
work with a C++ compiler), then the C++ compatibility option is not needed to
test the code. Otherwise, the code is buggy, so the compatibility warning is
useful.

[Bug c/105499] inconsistency between -Werror=c++-compat and g++ in __extension__ block

[vincent-gcc at vinc17 dot net]

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

--- Comment #6 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
To be clear... I'm not sure about what kind of compatibility warnings one can
get, but it is OK to silence valid extensions, i.e. those that will not give an
error. But invalid extensions, i.e. those that would give an error with a
compat-implied compiler (like in the testcase), should not be silenced by
__extension__.

The problem is that in my original testcase, __extension__ was used in order to
silence the warning for the ({...}) construct, which is still valid with g++.
But as a side effect, it also silences the conversion from the "int *p = q;",
which is invalid in C++ (and is actually *not* an extension as it fails as
shown in my bug report).

[Bug c/105499] inconsistency between -Werror=c++-compat and g++ in __extension__ block

[pinskia at gcc dot gnu.org]

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

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
__extension__ is supposed to disable compatibility warnings since they are
written in GNU C. Just happens that you enabled compatibility warnings to C++
which are also disabled.

This is the misunderstanding of what the warning and what __extension__ does.

[Bug c/105499] inconsistency between -Werror=c++-compat and g++ in __extension__ block

[vincent-gcc at vinc17 dot net]

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

--- Comment #8 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
It is bad that __extension__ does two completely different things:
1. Disable warnings associated with GNU extensions, like ({ ... }).
2. Disable compatibility warnings that do not correspond to GNU extensions,
like invalid conversions in C++.