Why does this invalid-looking code compile successfully on g++ 6.0?

Question

Consider this strange program:

int main()
{
    int(*){} Is it C++14 or any other language?
}

(See a live demo here & here.)

Even though the comment // is missing, the code compiles fine without any errors & warnings even when I use -pedantic-errorsoptions in g++ 6.0. This seems like a compiler bug to me. Is it really a bug in the compiler?

I can build it with `g++ -std=c++11 -Wall socc.cc -o socc`, using version 4.9.3 on cygwin. — R Sahu, Nov 09 '15 at 17:23
@KarolyHorvath: How about "Why does GCC 6 accept spurious barewords in the source code?"? — Kerrek SB, Nov 09 '15 at 17:32
@vsoftco At least better than the actual title. Anyways who would write such silly nonsensical code for any practical uses? I think cases for research will be narrowed to almost zero. Better to ask in GCC forums maybe. — πάντα ῥεῖ, Nov 09 '15 at 17:34
@PravasiMeet Unclear title, silly code, rare chance being helpful for future research. Hence my downvote. — πάντα ῥεῖ, Nov 09 '15 at 17:37
Lookie here http://coliru.stacked-crooked.com/a/db84bfda29e986bb — n. m. could be an AI, Nov 09 '15 at 18:07
related: http://stackoverflow.com/questions/23015482/strange-code-that-compiles-with-g — NathanOliver, Nov 09 '15 at 18:24
@πάνταῥεῖ a compiler unit test would be a practical use for this silly nonsensical code. Such nonsensical code routinely comes up in my development in the form of mistakes, and many of my mistakes I expect my compiler to catch. This code violates my expectations and I would like to know why. — djechlin, Nov 09 '15 at 21:45

score 41 · Accepted Answer · edited May 23 '17 at 11:51

41

This looks to be an bug/feature/issue with g++ in all of the versions I can test it on. Running

int main()
{
    int(*){} Is it C++14 or any other language?
}

On godbolt.org for all versions of g++ with no compilation flags give the following assembly ouput.

main:
    pushq   %rbp
    movq    %rsp, %rbp
    movl    $0, %eax
    leave
    ret

The only diagnosis I get is on godbolt.org and that is

!!warning: extended initializer lists only available with -std=c++0x or -std=gnu++0x

Clang, ICC and MSVS all fail to compile this.

EDIT:

From the comments zwol filed a bug with gcc on this. The bug report can be found here.

edited May 23 '17 at 11:51

Community

1
1

answered Nov 09 '15 at 17:24

NathanOliver

171,901
28
288
402

3

File a bug report: https://gcc.gnu.org/bugzilla/ if you haven't already. – zwol Nov 09 '15 at 23:17
As far as I can tell, your disassembly shows a simple `return 0;` meaning that the provided line of... whatever it is, is basically a `no-op`. Must be treated like some sort of declaration... – nonsensickle Nov 10 '15 at 00:18
@zwol Bug? It looks like it is interpreting it as array initialization and then stripping it because it's not used. How is that a bug? – Loren Pechtel Nov 10 '15 at 01:12
6

@LorenPechtel This code is syntactically invalid, gcc should issue a diagnostic and fail compilation, not doing so is a bug. – zwol Nov 10 '15 at 01:15
10

I filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68265 – zwol Nov 10 '15 at 01:26
1

@zwol Thanks for that. I hadn't gotten to it yet. I'll add it into the answer. – NathanOliver Nov 10 '15 at 01:33

nonsensickle · Answer 2 · 2015-11-09T23:00:28.330

I've run the command on my Fedora VM with g++ version 5.1.1 and found the following:

[user:~] 1 $ g++ -fdump-tree-original-raw tmp.cpp
tmp.cpp: In function ‘int main()’:
tmp.cpp:3:11: warning: extended initializer lists only available with -std=c++11 or -std=gnu++11
     int(*){} Is it C++14 or any other language?
       ^

However that still managed to compile... So I've dumped the AST and got this:

$ cat tmp.cpp.003t.original 

;; Function int main() (null)
;; enabled by -tree-original

@1      return_expr      type: @2       expr: @3      
@2      void_type        name: @4       algn: 8       
@3      init_expr        type: @5       op 0: @6       op 1: @7      
@4      type_decl        name: @8       type: @2       srcp: <built-in>:0      
                         note: artificial 
@5      integer_type     name: @9       size: @10      algn: 32      
                         prec: 32       sign: signed   min : @11     
                         max : @12     
@6      result_decl      type: @5       scpe: @13      srcp: tmp.cpp:1      
                         note: artificial              size: @10     
                         algn: 32      
@7      integer_cst      type: @5      int: 0
@8      identifier_node  strg: void     lngt: 4       
@9      type_decl        name: @14      type: @5       srcp: <built-in>:0      
                         note: artificial 
@10     integer_cst      type: @15     int: 32
@11     integer_cst      type: @5      int: -2147483648
@12     integer_cst      type: @5      int: 2147483647
@13     function_decl    name: @16      type: @17      scpe: @18     
                         srcp: tmp.cpp:1               lang: C       
                         link: extern  
@14     identifier_node  strg: int      lngt: 3       
@15     integer_type     name: @19      size: @20      algn: 128     
                         prec: 128      sign: unsigned min : @21     
                         max : @22     
@16     identifier_node  strg: main     lngt: 4       
@17     function_type    size: @23      algn: 8        retn: @5      
                         prms: @24     
@18     translation_unit_decl 
@19     identifier_node  strg: bitsizetype             lngt: 11      
@20     integer_cst      type: @15     int: 128
@21     integer_cst      type: @15     int: 0
@22     integer_cst      type: @15     int: -1
@23     integer_cst      type: @15     int: 8
@24     tree_list        valu: @2

Which is too big to fit inside a comment but should be useful in determining what is going on. I'm still going through this but I'm just posting this information for others to build from.

Which is visualized like this .

Down-voter(s) please leave a comment with your reasoning so that this answer can be improved. — nonsensickle, Nov 15 '15 at 21:44

Why does this invalid-looking code compile successfully on g++ 6.0?

2 Answers2

Linked