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: ===
> vect_mark_stmt
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
/opt/gcc/p_work/gcc/testsuite/gcc.dg/graphit
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 wrote:
> On Wed, Aug 20, 2014 at 1:24 PM, Roman Gareev wrote:
>> Which configure options do you use? Have you tried to bootstrap
>> r214105 w
On Wed, Aug 20, 2014 at 1:24 PM, Roman Gareev 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.)
I can't access the
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 :
> I suspect this causes arm/aarch64 nativ
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 -W
> 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 Fri, Aug 15, 2014 at 1:13 PM, Roman Gareev 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 nonavailability of CLooG li
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
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 :
> On Fri, Aug 15, 2014 at 1:13 PM, Roman Gareev wrote:
>>> I've attached the patch, which should eliminate CLooG
On Fri, Aug 15, 2014 at 1:13 PM, Roman Gareev 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 nonavailability of CLooG li
> 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 t
Thank you for the comment!
2014-08-13 15:55 GMT+06:00 Richard Biener :
> On Wed, Aug 13, 2014 at 10:07 AM, 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 f
> - 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 poin
On Wed, Aug 13, 2014 at 10:07 AM, 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 (
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 f
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 di
> 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 a
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 i
> 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
p
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 wher
> 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 wit
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 yo
> 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 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 pat
> 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 07/08/2014 15:18, Roman Gareev wrote:
To commit 2), I would like you to run a wider set of tests (e.g., the LLVM
test suite). If this passes successful, we should give a headsup on the GCC
mailing list and ask other people to try the new isl support.
If now bugs have found, we switch.
I've t
> To commit 2), I would like you to run a wider set of tests (e.g., the LLVM
> test suite). If this passes successful, we should give a headsup on the GCC
> mailing list and ask other people to try the new isl support.
> If now bugs have found, we switch.
I've tested the modified version of Graphi
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.
Ni
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
30 matches
Mail list logo
