Thank you for the report!
(1) FAIL: gcc.dg/graphite/vect-pr43423.c scan-tree-dump-times vect
vectorized 2 loops 1
before I saw
[Book15] f90/bug% grep vectorized vect-pr43423.c.114t.vect
/opt/gcc/p_work/gcc/testsuite/gcc.dg/graphite/vect-pr43423.c:14:17: note: ===
I see two regressions after r214069 on x86_64-apple-darwin13 for both -m32 and
-m64:
(1) FAIL: gcc.dg/graphite/vect-pr43423.c scan-tree-dump-times vect vectorized
2 loops 1
before I saw
[Book15] f90/bug% grep vectorized vect-pr43423.c.114t.vect
I think it's a issue in isl library check for (Canadian)
cross_compiling. Will send a patch soon.
Thanks,
bin
On Wed, Aug 20, 2014 at 1:47 PM, Bin.Cheng amker.ch...@gmail.com wrote:
On Wed, Aug 20, 2014 at 1:24 PM, Roman Gareev gareevro...@gmail.com wrote:
Which configure options do you use?
I suspect this causes arm/aarch64 native bootstrap failure with below messages.
aarch64-none-linux-gnu-g++ -c -g -O2 -DIN_GCC-fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute
-Woverloaded-virtual -pedantic
Which configure options do you use? Have you tried to bootstrap
r214105 with same configure options?
Have you tried to manually export the path to isl to LD_RUN_PATH?
(You’ve probably tried. I just want to make sure.)
2014-08-20 9:28 GMT+06:00 Bin.Cheng amker.ch...@gmail.com:
I suspect this
On Wed, Aug 20, 2014 at 1:24 PM, Roman Gareev gareevro...@gmail.com wrote:
Which configure options do you use? Have you tried to bootstrap
r214105 with same configure options?
Have you tried to manually export the path to isl to LD_RUN_PATH?
(You've probably tried. I just want to make sure.)
On Fri, Aug 15, 2014 at 1:13 PM, Roman Gareev gareevro...@gmail.com wrote:
I've attached the patch, which should eliminate CLooG library
installation dependency from GCC. The CLooG AST generator is still the
main code generator, but the isl ast generator will be chosen in case
of
This patch is ok. I assume you have tested compiling with/without cloog
and isl.
Yes, I’ve tested compiling with/without cloog and isl. Thank you very
much for review!
--
Cheers, Roman Gareev.
On 16/08/2014 13:28, Roman Gareev wrote:
Richard, could you please review these patches? We would be very glad
for your comments.
P.S: I’ve attached an improved ChangeLog_entry.
The patch and changelog looks good to me, but we still need a
non-graphite reviewer oking the changes.
Tobias
I've attached the patch, which should eliminate CLooG library
installation dependency from GCC. The CLooG AST generator is still the
main code generator, but the isl ast generator will be chosen in case
of nonavailability of CLooG library.
However, I've found out a problem. Almost all the
On Fri, Aug 15, 2014 at 1:13 PM, Roman Gareev gareevro...@gmail.com wrote:
I've attached the patch, which should eliminate CLooG library
installation dependency from GCC. The CLooG AST generator is still the
main code generator, but the isl ast generator will be chosen in case
of
Richard, could you please review these patches? We would be very glad
for your comments.
P.S: I’ve attached an improved ChangeLog_entry.
2014-08-15 17:44 GMT+06:00 Richard Biener richard.guent...@gmail.com:
On Fri, Aug 15, 2014 at 1:13 PM, Roman Gareev gareevro...@gmail.com wrote:
I've
If I’m not mistaken all tree nodes, which have pointer type, can be
divided into two groups: the type is a is a pointer to data member
(TYPE_PTRMEM_P is true for it), the type is a pointer type, and the
pointee is not a data member (TYPE_PTR_P is true for it). I think that
we’re interested in
On 13/08/2014 16:07, Roman Gareev wrote:
If I’m not mistaken all tree nodes, which have pointer type, can be
divided into two groups: the type is a is a pointer to data member
(TYPE_PTRMEM_P is true for it), the type is a pointer type, and the
pointee is not a data member (TYPE_PTR_P is true
On Wed, Aug 13, 2014 at 10:07 AM, Roman Gareev gareevro...@gmail.com wrote:
If I’m not mistaken all tree nodes, which have pointer type, can be
divided into two groups: the type is a is a pointer to data member
(TYPE_PTRMEM_P is true for it), the type is a pointer type, and the
pointee is
- I assume you verified this passes all graphite tests.
Yes, I’ve found out that there is no regression.
- Please add a brief comment in the source code regarding why we
do not want to detect such SCoPs.
Would you add anything to the following comment: “We disable the
handling of
Thank you for the comment!
2014-08-13 15:55 GMT+06:00 Richard Biener richard.guent...@gmail.com:
On Wed, Aug 13, 2014 at 10:07 AM, Roman Gareev gareevro...@gmail.com wrote:
If I’m not mistaken all tree nodes, which have pointer type, can be
divided into two groups: the type is a is a pointer
On 09/08/2014 12:05, Roman Gareev wrote:
With just C++ code, Sven can help little. He has no knowledge about graphite
internals.
I want to ask him about correctness of ISL ASTs generated from
mentioned isl_codegens.
I am not sure if he can see it just like this.
Do you now have a setup
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?
I’ve manually selected parts of code, which produce the scope.
I’ve found out that this bug is most probably caused by absence of
On 11/08/2014 09:11, Roman Gareev wrote:
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?
I’ve manually selected parts of code, which produce the scope.
I’ve found out that this bug
Did you try your code with 64bit pointer types?
Yes. It seems that the result is the same.
In any case, I don't think it is worth spending time on this. I would check
in the scop detection that we disable the handling of unsigned and pointer
types. It is a complex thing to model and the
Is this segmentation fault at compile time or at run-time? I believe it was
a segfault at run-time due to a miscompile.
Yes, it's a segfault at run-time. These source codes produce wrong object files.
Possibly. Can you split the .cpp files such that you only compile a single
function with
On 09/08/2014 09:42, Roman Gareev wrote:
Is this segmentation fault at compile time or at run-time? I believe it was
a segfault at run-time due to a miscompile.
Yes, it's a segfault at run-time. These source codes produce wrong object files.
Possibly. Can you split the .cpp files such that
With just C++ code, Sven can help little. He has no knowledge about graphite
internals.
I want to ask him about correctness of ISL ASTs generated from
mentioned isl_codegens.
Do you now have a setup where you can just compile one of the attached files
with graphite and everything else
I think this is fine. On the other side, I think the test case itself
is unnecessarily large. I would assume the majority of the code could
be deleted while still triggering the bug. Could you give it a shot.
I've attached an improved version of the patch.
Is there anything else you still
On 08/08/2014 15:11, Roman Gareev wrote:
I think this is fine. On the other side, I think the test case itself
is unnecessarily large. I would assume the majority of the code could
be deleted while still triggering the bug. Could you give it a shot.
I've attached an improved version of the
Hi Tobias,
I've attached the patch, which should eliminate CLooG library
installation dependency from GCC. The CLooG AST generator is still the
main code generator, but the isl ast generator will be chosen in case
of nonavailability of CLooG library.
However, I've found out a problem. Almost all
On 06/08/2014 17:21, Roman Gareev wrote:
Hi Tobias,
I've attached the patch, which should eliminate CLooG library
installation dependency from GCC. The CLooG AST generator is still the
main code generator, but the isl ast generator will be chosen in case
of nonavailability of CLooG library.
28 matches
Mail list logo
