Error during the build.

./autogen.sh
./configure --with-osl=system --with-osl-exec-prefix=/home/thiago/Documents/periscop/install  --with-osl-prefix=/home/thiago/Documents/periscop/install --prefix=/home/thiago/Documents/periscop/install 
make V=1

Error:

/bin/bash ./libtool  --tag=CC   --mode=link gcc  -g -O2   -o clan source/clan-clan.o -losl  libclan.la -losl 
libtool: link: gcc -g -O2 -o .libs/clan source/clan-clan.o  ./.libs/libclan.so -losl -Wl,-rpath -Wl,/home/thiago/Documents/periscop/install/lib
/usr/bin/ld: cannot find -losl

they must have different names => they must have same names.

With GCC 8.3.1 and -Wextra and git commit 'bump to 0.8.1' (379eead), I see the following warning:

source/scanner.c: In function ‘yy_get_next_buffer’:
source/scanner.c:921:18: warning: comparison of integer expressions of different signedness: ‘size_t’ {aka ‘long unsigned int’} and ‘int’ [-Wsign-compare]
for ( n = 0; n < max_size &&
^
source/scanner.c:2031:3: note: in expansion of macro ‘YY_INPUT’
YY_INPUT( (&YY_CURRENT_BUFFER_LVALUE->yy_ch_buf[number_to_move]),

I was expecting max to be treated as a pure function here. However, I get an extraction failure. Renaming max to something else makes it work. A similar problem with min.

$ cat test/max.c

pragma scop

for (j=0; j<N; j++) {
c = max(a, b);
}

pragma endscop

$ clan/clan -v
clan 0.8.0 The Chunky Loop Analyzer
$ clan/clan test/max.c
[Clan] Info: parsing file #1 (test/max.c)
[Clan] Error: syntax error at line 3, column 11.
c = max(a, b);
~~~^

NULL scop

With commit: 379eead

When clan_scop_extract fails here (i.e., the return scop is NULL or scop->statement is NULL), I see a memory leak. Here's the trace from valgrind:

==7501== 136 (128 direct, 8 indirect) bytes in 4 blocks are definitely lost in loss record 44 of 52
==7501== at 0x483880B: malloc (vg_replace_malloc.c:309)
==7501== by 0x482A1D: clan_symbol_malloc (symbol.c:198)
==7501== by 0x482EDF: clan_symbol_clone_one (symbol.c:514)
==7501== by 0x483081: clan_symbol_new_iterator (symbol.c:596)
==7501== by 0x47E461: yyparse (parser.y:627)
==7501== by 0x4801F4: clan_parse (parser.y:2430)
==7501== by 0x40C16E: main (main.c:553)

To reproduce:

libtool --mode=execute valgrind --leak-check=full clan/clan test/heat-2d.c

[Clan] Info: parsing file #1 (test/heat-3d.c)
[Clan] Error: syntax error at line 91, column 21.
A[(t + 1) % 2][i][j][k] =
~~~^

NULL scop

==10699==
==10699== HEAP SUMMARY:
==10699== in use at exit: 44,996 bytes in 27 blocks
==10699== total heap usage: 835 allocs, 808 frees, 532,303 bytes allocated
==10699==
==10699== 136 (128 direct, 8 indirect) bytes in 4 blocks are definitely lost in loss record 5 of 8
==10699== at 0x483880B: malloc (vg_replace_malloc.c:309)
==10699== by 0x48554CD: clan_symbol_malloc (symbol.c:198)
==10699== by 0x485591F: clan_symbol_clone_one (symbol.c:514)
==10699== by 0x4855AE1: clan_symbol_new_iterator (symbol.c:596)
==10699== by 0x484FD26: yyparse (parser.y:627)
==10699== by 0x4851C5E: clan_parse (parser.y:2430)
==10699== by 0x401236: main (clan.c:85)
==10699==
==10699== LEAK SUMMARY:
==10699== definitely lost: 128 bytes in 4 blocks
==10699== indirectly lost: 8 bytes in 4 blocks
==10699== possibly lost: 0 bytes in 0 blocks
==10699== still reachable: 44,860 bytes in 19 blocks
==10699== suppressed: 0 bytes in 0 blocks
==10699== Reachable blocks (those to which a pointer was found) are not shown.
==10699== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==10699==
==10699== For counts of detected and suppressed errors, rerun with: -v
==10699== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

where test/heat-2d.c can be found at https://github.com/bondhugula/pluto

I've been able to reproduce this on other test cases that fail scop extraction this way - so it's not particular to this test case.

Parsing a code with more than MAX_DEPTH parameters results in an incorrect behavior, for example:

#pragma scop
for (i = 0; i < N; i++)
  a[i]++;
for (i = 0; i < M; i++)
  a[i]++;
for (i = 0; i < L; i++)
  a[i]++;
for (i = 0; i < K; i++)
  a[i]++;
for (i = 0; i < P; i++)
  a[i]++;
for (i = 0; i < U; i++)
  a[i]++;
#pragma endscop

results in

$ clan test2.c -o test2.scop
[Clan] Info: parsing file #1 (test2.c)
[osl] Warning: non integer array identifier (osl_relation_get_array_id).
+-- osl_relation_t (READ, 64 bits)
|   2 11 2 1 0 6
|   [    0   -1    0    0    0    0    0    0    0    3    3 ]
|   [    0    0   -1    1    0    0    0    0    0    0    0 ]
|   
[osl] Warning: OpenScop integrity check failed. Something may go wrong. (osl_scop_print).
[osl] Warning: non integer array identifier (osl_relation_get_array_id).
[osl] Warning: non integer array identifier (osl_relation_get_array_id).
[osl] Warning: non integer array identifier (osl_relation_get_array_id).
[osl] Warning: non integer array identifier (osl_relation_get_array_id).
[osl] Warning: non integer array identifier (osl_relation_get_array_id).
[osl] Warning: non integer array identifier (osl_relation_get_array_id).
[osl] Warning: non integer array identifier (osl_relation_get_array_id).
[osl] Warning: non integer array identifier (osl_relation_get_array_id).
[osl] Warning: non integer array identifier (osl_relation_get_array_id).
[osl] Warning: non integer array identifier (osl_relation_get_array_id).
[osl] Warning: non integer array identifier (osl_relation_get_array_id).
[osl] Warning: non integer array identifier (osl_relation_get_array_id).
[osl] Warning: non integer array identifier (osl_relation_get_array_id).
[osl] Warning: non integer array identifier (osl_relation_get_array_id).
[osl] Warning: non integer array identifier (osl_relation_get_array_id).
[osl] Warning: non integer array identifier (osl_relation_get_array_id).
[osl] Warning: non integer array identifier (osl_relation_get_array_id).
[osl] Warning: non integer array identifier (osl_relation_get_array_id).
[osl] Warning: non integer array identifier (osl_relation_get_array_id).
[osl] Warning: non integer array identifier (osl_relation_get_array_id).
[osl] Warning: non integer array identifier (osl_relation_get_array_id).
[osl] Warning: non integer array identifier (osl_relation_get_array_id).
[osl] Warning: non integer array identifier (osl_relation_get_array_id).
[osl] Warning: non integer array identifier (osl_relation_get_array_id).

MAX_DEPTH being set to five by default, this code doesn't reach it, but uses six parameters. Apparently, some parts of the code consider it as a limitation of parameter number, which is not the case.

You cannot call clan_scop_extract twice

In multiple projects, we have the -mcpu=pentium2 flag set. My recent Clang version does not support it anymore. Is there a reason to target specifically pentium 2 in 2014?

The original code

#pragma scop
for (i = 1; i < 42; i++) {
  S1(i);
}
#pragma endscop

generates a proper constraint in the matrix representation: i - 1 >= 0.

while introducing a non-unit stride makes it somehow inverted

#pragma scop
for (i = 1; i < 42; i += 2) {
  S1(i);
}
#pragma endscop

results in the constraint i + 1 >= 0, which does not correspond to the iteration domain at hand. Apparently, inversion is made to support the creation of the local dimension as i + 1 = 2*l1

Out-of-tree clean CMake build is broken

mkdir build
cd build
cmake .. -DCMAKE_INSTALL_PREFIX=$HOME/usr
make

results in

.../clan/source/scop.c:58:10: fatal error: 'source/parser.h' file not found
#include <source/parser.h>

This is caused by the fact that CMake (version 3.3.2) puts Bison-generated file parser.h in the build directory instead of source.

The error does not appear if the Clan was built at least once with autotools from the same source tree since the file parser.h was created. However, in this case, CMake silently uses an outdated file source/parser.h instead of the newly generated once creating room for tricky errors.

Clan accepts such a code without complaining or providing a correct support:
for (i = ...)
for (j = ...) {
f(A[i][j]); // Reference to an array cell
f(A[i]); // Address of the first element of A[i], i.e., &A[i][0]
f(A); // Address of the first element of A, i.e., &A[0], equivalent to &A[0][0]
}
Clan shoud either report an error stating that accesses do not have the same dimensionality, or support it correctly with a conservative approach using local dimensions: A[i] can be translated to an access to the whole row (i.e. A[i][ld] with no constraint on the local dimension ld) while A can be translated to an access to the whole array (i.e. A[ld1][ld2] with no constraint on the local dimensions ld1 and ld2).

The rule

loop_infinite:
    WHILE '(' INTEGER ')'
  | FOR '(' ';' ';' ')'
  ;

in source/parser.y does match the code

while (0) { 
}

which is not infinite and is not even executed.

Hello everyone,

It's already been a while since the paper "The polyhedral model is more widely applicable than you think" was published, but I am working on a small compiler project and I am interested in understanding the implementation. In particular, I would be interested in the benchmark implementations.

The paper mentions that it was implemented in CLAN. Is there any chance to see the details of the implementation (does not need to be working at all)?

Cheers,
Lukas

For the simplified code example similar to codes generated by CLooG for unconstrained parameters

if (N > 0) {                                                                     
  for (i = 0; i < N; i++) {                                                      
    S1(i);                                                                       
  }                                                                              
}                                                                                
if (N > 0) {                                                                     
  for (i = 0; i < N; i++) {                                                      
    S2(i);                                                                       
  }                                                                              
}

clan with -autopragma or -autoinsert finds a syntax error before the second loop:

[Clan] Info: parsing file #1 (foo.c)
[Clan] Error: syntax error at line 7, column 1.
  for (i = 0; i < N; i++) {
^

However, once surrounded by #pragma scop/endscop, this code is parsed properly.

Supposedly, scop detection marks first loop as the scop beginning and not the branch. It than consumes the closing brace for the branch resulting in brace mismatch. Scop detection should either consider loops as possible starting point or mark scop ending when exiting the block in which it started.

With non-unit stride, the first statement has two local dims, but the second -- only one; although this is not critical in this case (since dimensions are equivalent, it is critical in+++ nested loops where it essentially makes i = j through l2).

#pragma scop
for (int i = 0; i < 42; i += 2) {
  if (i%2 == 0)
    S1(i);
  if (i%2 == 0)
    S2(i);
}
#pragma endscop

# ----------------------------------------------  1.1 Domain
DOMAIN
4 5 1 0 2 0
# e/i|  i | l1   l2 |  1  
   1   -1    0    0   41    ## -i+41 >= 0
   1    1    0    0    0    ## i >= 0
   0   -1    2    0    0    ## i == 2*l1
   0    1    0   -2    0    ## i == 2*l2

# ----------------------------------------------  2.1 Domain
DOMAIN
3 4 1 0 1 0
# e/i|  i | l1 |  1  
   1   -1    0   41    ## -i+41 >= 0
   1    1    0    0    ## i >= 0
   0   -1    2    0    ## i == 2*l1