Cicro benchmark suite - missing features

[mrigger]

Hi,

We are working on a new C benchmarking suite, which also provides Docker images to build and run a variety of tools. While we were able to create a working Dockerfile for ack, we could not use it to compile our C-Hayai-based benchmark harness. It seems that this is due to missing features in ack. For example, here is some output generated when building chayai_console_outputter.c:

[ 44%] Building C object src/CMakeFiles/chayai.dir/chayai_console_outputter.c.o
"/benchmarks/C-Hayai/src/chayai_clock.h", line 93: (warning) old-fashioned function declaration
"/benchmarks/C-Hayai/src/chayai_clock.h", line 101: int64_t is not a type identifier
"/benchmarks/C-Hayai/src/chayai_clock.h", line 105: int64_t is not a type identifier
"/benchmarks/C-Hayai/src/chayai_clock.h", line 105: (warning) old-fashioned function declaration
"/benchmarks/C-Hayai/src/chayai_clock.h", line 109: int64_t is not a type identifier
"/benchmarks/C-Hayai/src/chayai_clock.h", line 109: (warning) old-fashioned function declaration
"/benchmarks/C-Hayai/src/chayai_clock.h", line 113: (warning) old-fashioned function declaration
"/benchmarks/C-Hayai/src/chayai_clock.c", line 5: int64_t is not a type identifier
"/benchmarks/C-Hayai/src/chayai_clock.c", line 5: (warning) 'chayai_clock_resolution_measured' old-fashioned function definition
"/benchmarks/C-Hayai/src/chayai_clock.c", line 6: int64_t is not a type identifier
"/benchmarks/C-Hayai/src/chayai_clock.c", line 6: (warning) constant too large for target machine
"/benchmarks/C-Hayai/src/chayai_clock.c", line 10: int64_t is not a type identifier
"/benchmarks/C-Hayai/src/chayai_clock.c", line 11: ; missing before int
"/benchmarks/C-Hayai/src/chayai_clock.c", line 11: < deleted
"/benchmarks/C-Hayai/src/chayai_clock.c", line 14: p2 undefined
"/benchmarks/C-Hayai/src/chayai_clock.c", line 15: cur_time undefined
"/benchmarks/C-Hayai/src/chayai_clock.c", line 15: p2 undefined
"/benchmarks/C-Hayai/src/chayai_clock.c", line 17: min_time undefined
"/benchmarks/C-Hayai/src/chayai_clock.c", line 22: return deleted
"/benchmarks/C-Hayai/src/chayai_clock.c", line 23: } deleted
"/benchmarks/C-Hayai/src/chayai_clock.c", line 211: (warning) 'chayai_clock_now' old-fashioned function definition
"/benchmarks/C-Hayai/src/chayai_clock.c", line 217: int64_t is not a type identifier
"/benchmarks/C-Hayai/src/chayai_clock.c", line 223: int64_t is not a type identifier
"/benchmarks/C-Hayai/src/chayai_clock.c", line 223: (warning) 'chayai_clock_resolution' old-fashioned function definition
"/benchmarks/C-Hayai/src/chayai_clock.c", line 227: (warning) 'chayai_clock_type_str' old-fashioned function definition
src/CMakeFiles/chayai.dir/build.make:86: recipe for target 'src/CMakeFiles/chayai.dir/chayai_clock.c.o' failed
make[4]: *** [src/CMakeFiles/chayai.dir/chayai_clock.c.o] Error 1

A full list is available at https://github.com/jku-ssw/cicro-benchmarks/tree/master/docker-failed/BENCHMARK_ACK. I expect that the missing features cannot be implemented without significant engineering effort, or what do you think? In any case, let me know if you want to dig deeper, so I can write down the steps involved to reproduce this output.

[davidgiven]

You're probably using the linux386 code generator, right? If so, I'm afraid it just doesn't support 64 bit integers. That's what's probably causing all the other errors.

Does your benchmark have a mode where it doesn't use these?

[kernigh]

/usr/local/lib/ack/em_cemcom.ansi died with signal 11 is a bug: 11 is probably SIGSEGV, a segfault. I would like to have a .c file that causes the bug.

ACK's C compiler is missing long long and int64_t types. I want these types, but they would need several changes to ACK tools to allow 64-bit integers.

[davidgiven]

I didn't spot the crash (was at work and didn't take the time to look at the whole log!).

I think the file is this one: https://github.com/jku-ssw/cicro-benchmarks/blob/master/C-Hayai/src/chayai_console_outputter.c

It looks like it's crashed just after a static inline prototypes, which is very much not supported by C89 (which is what the ACK understands).

[kernigh]

Yes, that file causes the bug. I can now reproduce the crash by declaring a static inline function and defining it:

pehcehwahn$ cat crash-ack.c                                                    
static inline void fu(void);

static inline void fu(void)
{
}
pehcehwahn$ ack -c crash-ack.c                                                 
"crash-ack.c", line 1: making function body for non-function
"crash-ack.c", line 1: (warning) fu is a function; cannot be formal
"crash-ack.c", line 1: fu not in parameter list
"crash-ack.c", line 3: static formal illegal
"crash-ack.c", line 3: inline not in parameter list
"crash-ack.c", line 3: ; missing before void
"crash-ack.c", line 4: (warning) fu is a function; cannot be formal
"crash-ack.c", line 4: fu redeclared
"crash-ack.c", line 4: ; missing before {
ack: /home/kernigh/park/ack-build/staging/lib/ack/em_cemcom.ansi died with signal 11

[mrigger]

Thank you for your quick responses!

Unfortunately, the benchmark suite does not provide a mode where no 64-bit integers are used. Furthermore, the programs are not necessarily C89 compliant, so that could be another problem even when the 64-bit integer issue is addressed. Anyway, thanks again for your help!

[davidgiven]

Useful context from util/LLgen/doc/LLgen_NCER.n:

Another example is in the ACK C compiler. For some reason, the
grammar accepts function definitions without `()', so according
to the syntax a function definition can look like:
.br
.nf

    int func
    {
      ....
    }
.fi

.LP
The absence of the `()', however, causes `func' to be entered in the
symbol table as non-function, and when the parser encounters the body
a semantic action will complain with the error message "Making function body
for non-function". This again will cause the non-correcting error
recovery to miss errors. Consider this piece of code:
.br
.nf

int i int j = 1;
{}

.fi

.LP
where apparently there's a `;' missing between the declarations
of i and j. The original LLgen-generated parser only gives semantic errors:
.br
.nf
"Making function body for non-function"
"j is not in parameter list"
"Illegal initialization of formal parameter, ignored"
.fi
.LP
As a result, the non-correcting error recovery will not report
any errors in this piece of code, because it does not execute the
semantic actions that recognize and report the error. Unfortunately,
due to the way the C-grammar is written, it is not possible to solve
this problem using a %erroneous directive; the part of the grammar 
that deals with declaratons would have to be rewritten so as to
syntactically reject functions without `()'. 

[davidgiven]

inline is not part of cemcom's grammar, so I think it's parsing the code as:

static inline() void fu(void); static inline() void fu(void); {}

...with K&R function definitions. The crash is, I think, because the function inline isn't set as a function because that bit's done by the missing parentheses, but the grammar assumes it has to be one and so isn't bothering to check the type.