This is the mail archive of the
mailing list for the GCC project.
Re: [GSoC] Elimination of CLooG library installation dependency
- From: Tobias Grosser <tobias at grosser dot es>
- To: Roman Gareev <gareevroman at gmail dot com>
- Cc: Mircea Namolaru <mircea dot namolaru at inria dot fr>, gcc-patches at gcc dot gnu dot org
- Date: Mon, 11 Aug 2014 08:26:33 +0200
- Subject: Re: [GSoC] Elimination of CLooG library installation dependency
- Authentication-results: sourceware.org; auth=none
- References: <CABGF_gco8bbFoBD=PORcSp=Q_wQpqca2M72mRzmyRO46B0juFQ at mail dot gmail dot com> <53E24E47 dot 2090803 at grosser dot es> <CABGF_geZoaTRwfc4on8NFehEdbrjH=xFD36QyH0a8AGi01yrBA at mail dot gmail dot com> <53E3806E dot 7040903 at grosser dot es> <CABGF_gfCmbvkSmwbzH20DibgUQvCj7WFasQw1yaRSOoNTPR6hA at mail dot gmail dot com> <53E4CD87 dot 5080105 at grosser dot es> <CABGF_gfnXsQhcZ3b55Fr43kzA_9qtTeN6oHUsk3suaDQQ5B7=w at mail dot gmail dot com> <53E5D33C dot 6050800 at grosser dot es> <CABGF_gcNZWxZriTAKaok_SsgadFj5n1hohbkQWErqPnLuGKDbg at mail dot gmail dot com>
On 09/08/2014 12:05, Roman Gareev wrote:
With just C++ code, Sven can help little. He has no knowledge about graphite
I want to ask him about correctness of ISL ASTs generated from
I am not sure if he can see it just like this.
Do you now have a setup where you can just compile one of the attached files
with graphite and everything else without and the code crashes?
No, I don't. As I mentioned earlier, all the files from this test case
individually produce object files which linked into the one
executable, which cause âSegmentation fault (core dumped)â (It'll
cause âSegmentation fault (core dumped)â, if we try to run it). I
think that it's very difficult to detach the code, which would produce
the executable and save the semantics of this big OOP project.
Furthermore, there is a possibility that the detached code can produce
no new useful information.
I've found that if we try to compile any of the btCollisionWorld.cpp,
and btDiscreteDynamicsWorld.llvm.cpp by modified Graphite, the
produced object file will lead to creation of the wrong executable
(after linking with other object files generated by origin Graphite).
I am confused. It seems you attached some kind of reduced version of
btCollisionWorld.cpp? How did you obtain it? Did you compile and test
with these versions?
That's why I think that we could consider only, for example,
btCollisionDispatcher.cpp. It contains only one scope, which is
incorrectly processed by Graphite with the ISL code generator as the
Why did you provide two files. I assume one should be sufficient to
reproduce the crash, no?
I've detached the code, which is used by Graphite to produce similar AST's.
OK. But did you check if they actually segfault or fail?
I think for the one file you choose, it would be interesting to look
at the code generation input as well as the kernels generated by CLooG and
isl. Maybe we can understand what is going on.
Yes, exactly those that you provided. At a first look, I don't see
anything obvious wrong, except that the huge modulo values, which arise
from some integer wrapping support Sebastian added once for unsigned
I see two approaches you can take:
1) The easy one
Disallow unsigned integers in the scop detection. I have doubts we can
do anything good with those huge modulo constraints placed all over the
2) Try to understand the test case
I would try a couple of easy unsigned int loops to see if we can handle
them properly. Something like:
for (unsigned long i = 0; i < M; i++)
A[i] += i;
At best, we could even write your test case as such a loop and reproduce
the bug outside of this huge C++ code. Maybe looking at the GIMPLE
allows you to write C code that has similar behavior and where we could
check the output?