[Bug c++/65547] New: Gcc not giving preprocessor error for invalid invocation of variadic macro

[Bug c++/65547] New: Gcc not giving preprocessor error for invalid invocation of variadic macro

[eldlistmailingz at tropicsoft dot com]

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

            Bug ID: 65547
           Summary: Gcc not giving preprocessor error for invalid
                    invocation of variadic macro
           Product: gcc
           Version: 4.9.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: eldlistmailingz at tropicsoft dot com

Given the variadic macro:

  #define VMACRO(x,...) x __VA_ARGS__

if it is invoked with

  VMACRO(1)

a compiler error should occur according to section 16.3 paragraph 4 of the
C++11 standard:

"If the identifier-list in the macro definition does not end with an ellipsis,
the number of arguments (including those arguments consisting of no
preprocessing tokens) in an invocation of a function-like macro shall equal the
number of parameters in the macro definition. Otherwise, there shall be more
arguments in the invocation than there are parameters in the macro definition
(excluding the ...). There shall exist a ) preprocessing token that terminates
the invocation."

The second sentence is the relevant one.

Instead gcc outputs the warning:

"warning: ISO C99 requires rest arguments to be used".

But since the compile is done with C++11 support the reference should be to the
C++11 standard and an error should occur. That an error does not occur I
consider a bug.

Relevant command line parameters are:

"-ftemplate-depth-128 -O0 -fno-inline -Wall -pedantic -g -Wno-variadic-macros
-ftrack-macro-expansion=0 -std=c++0x"

If there is some reason why this is a warning rather than a compiler error I
would like to know about it.

[Bug c++/65547] Gcc not giving preprocessor error for invalid invocation of variadic macro

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Try -pedantic-error instead.

[Bug c++/65547] Gcc not giving preprocessor error for invalid invocation of variadic macro

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Edward Diener from comment #0)
> Instead gcc outputs the warning:
> 
> "warning: ISO C99 requires rest arguments to be used".
> 
> But since the compile is done with C++11 support the reference should be to
> the C++11 standard

Already fixed for GCC 5.

v.c:2:21: warning: ISO C++11 requires at least one argument for the "..." in a
variadic macro


> and an error should occur. That an error does not occur I
> consider a bug.

No, the standard doesn't require an error, it requires a diagnostic message.

"If a program contains a violation of any diagnosable rule or an occurrence of
a construct described in this Standard as “conditionally-supported” when the
implementation does not support that construct, a conforming implementation
shall issue at least one diagnostic message."

A warning is a diagnostic message, ergo there is no bug.

As Andrew pointed out, use -pedantic-errors (or -Werror=pedantic) if you want
to turn such warnings into errors.
>From gcc-bugs-return-481582-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Mar 25 10:47:36 2015
Return-Path: <gcc-bugs-return-481582-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 16084 invoked by alias); 25 Mar 2015 10:47:36 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 16044 invoked by uid 48); 25 Mar 2015 10:47:32 -0000
From: "avi@cloudius-systems.com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug debug/65549] New: crash in htab_hash_string with -flto
Date: Wed, 25 Mar 2015 11:47:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: debug
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: avi@cloudius-systems.com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter
Message-ID: <bug-65549-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-03/txt/msg02726.txt.bz2
Content-length: 1451

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide549

            Bug ID: 65549
           Summary: crash in htab_hash_string with -flto
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: debug
          Assignee: unassigned at gcc dot gnu.org
          Reporter: avi@cloudius-systems.com

lto1: internal compiler error: Segmentation fault
0xa283bf crash_signal
    ../../gcc/toplev.c:383
0x111c7b0 htab_hash_string
    ../../libiberty/hashtab.c:839
0x6d06bf external_ref_hasher::hash(external_ref const*)
    ../../gcc/dwarf2out.c:7763
0x6d06bf hash_table<external_ref_hasher, xcallocator,
false>::find_slot(external_ref const*, insert_option)
    ../../gcc/hash-table.h:652
0x6d06bf lookup_external_ref
    ../../gcc/dwarf2out.c:7791
0x6d075d optimize_external_refs_1
    ../../gcc/dwarf2out.c:7829
0x6d0788 optimize_external_refs_1
    ../../gcc/dwarf2out.c:7833
0x6d0bc6 optimize_external_refs
    ../../gcc/dwarf2out.c:7882
0x6d0dfd output_comp_unit
    ../../gcc/dwarf2out.c:9122
0x6f6cd9 dwarf2out_finish
    ../../gcc/dwarf2out.c:24800
Please submit a full bug report,

g++5 (GCC) 5.0.0 20150324 (experimental)

To reproduce, clone seastar (https://github.com/cloudius-systems/seastar)

  ./configure.py --compiler /path/to/g++5 --cflags='-flto
-D_GLIBCXX_USE_CXX11_ABI=0'
  ninja build/release/tests/tcp_client   # named ninja-build on Fedora)

[Bug c++/65547] Gcc not giving preprocessor error for invalid invocation of variadic macro

[eldlistmailingz at tropicsoft dot com]

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

--- Comment #3 from Edward Diener <eldlistmailingz at tropicsoft dot com> ---
Where do you get the idea that the standard doesn't require an error, it
requires a diagnostic message ?

It clearly is a violation of the C++11 standard according to the section and
paragraph I cited in my bug report.

[Bug c++/65547] Gcc not giving preprocessor error for invalid invocation of variadic macro

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Edward Diener from comment #3)
> Where do you get the idea that the standard doesn't require an error, it
> requires a diagnostic message ?

1.4 [intro.compliance], the text I quoted. Where do you get the idea it
requires an error?

[Bug c++/65547] Gcc not giving preprocessor error for invalid invocation of variadic macro

[eldlistmailingz at tropicsoft dot com]

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

--- Comment #6 from Edward Diener <eldlistmailingz at tropicsoft dot com> ---
(In reply to Jonathan Wakely from comment #4)
> (In reply to Edward Diener from comment #3)
> > Where do you get the idea that the standard doesn't require an error, it
> > requires a diagnostic message ?
> 
> 1.4 [intro.compliance], the text I quoted. Where do you get the idea it
> requires an error?

You are not following the C++ standard as specified by the section I quoted.
Does gcc just decide arbitrarily if it does not follow the C++ standard it can
either issue an error, warning, or diagnostic message. That is an odd way to
create a language compiler. Is not the idea of a compiler like gcc that it
should follow the C++ standard as to be a standard-conforming compiler, and if
the end-user writes C++ code that does not follow the C++ standard an error
should be issued by the compiler ?

I am clearly missing something here. The C++ standard, in the section/paragraph
I quoted, is saying that when a macro accepts variadic parameters as its final
parameter, some input, even if it is an argument consisting of no preprocessing
tokens, must be passed for the variadic parameter. In the example I gave, no
argument at all is being passed for the variadic parameter. If the invocation
had been VMACRO(1,) then there is no problem. But some argument must be passed.