https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56145
--- Comment #16 from Mircea Namolaru mircea.namolaru at inria dot fr ---
Right, the NULL check fixed this for previous versions of GCC.
For the current version, it works without these NULL checks (the NULL paths are
not followed). The relevant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56145
Mircea Namolaru mircea.namolaru at inria dot fr changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62630
--- Comment #18 from Mircea Namolaru mircea.namolaru at inria dot fr ---
I've succeeded to explain why these casts are generated, and they seem correct.
Graphite introduces new induction variables with a larger size type (then the
type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62630
--- Comment #16 from Mircea Namolaru mircea.namolaru at inria dot fr ---
Yes, but it seems to me that the cast (not in the original code) should not
be generated at all if it could not be guaranteed that the casted-to type is
larger
enough
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62630
--- Comment #10 from Mircea Namolaru mircea.namolaru at inria dot fr ---
On my Intel x86-64 platform changed in graphite-isl-ast-to-gimple.c:
- static int graphite_expression_type_precision = 128 = max_mode_int_precision
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62630
--- Comment #14 from Mircea Namolaru mircea.namolaru at inria dot fr ---
It seems to me that scalar evolution succeeds to determine
the number of iterations for the case of signed longs. Looking
in vectorization dump, first a symbolic expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62630
Mircea Namolaru mircea.namolaru at inria dot fr changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64098
--- Comment #1 from Mircea Namolaru mircea.namolaru at inria dot fr ---
Bug confirmed. The error message points to a problem in the way in which the
unroll-and-jam code manage the isl objects (the space is not freed properly).
I pinned down
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61000
--- Comment #2 from Mircea Namolaru mircea.namolaru at inria dot fr ---
Again, the problem is due to representation of arrays in Fortran as array with
a single dimnesion (for similar code in C profitability check work as
expected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61000
--- Comment #4 from Mircea Namolaru mircea.namolaru at inria dot fr ---
Right, C arrays expressed as pointers suffers from the same problem.
But for C at least there is a way to avoid this.
Many thanks for your suggestion of how to de-linearize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60997
--- Comment #3 from Mircea Namolaru mircea.namolaru at inria dot fr ---
It is not that -floop-interchange is disabled, but the code received by
graphite is different if the option -fopenmp is enabled. In this case the check
for data
dependencies
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61000
--- Comment #1 from Mircea Namolaru mircea.namolaru at inria dot fr ---
The built-in heuristics assess that loop interchange is not profitable. Indeed
there is a problem, I would expected that the second loop to be found
profitable.
Need to look
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55022
--- Comment #27 from Mircea Namolaru mircea.namolaru at inria dot fr ---
Hi,
Many thanks.
I've passed over the meta-bug opened by you for Graphite,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59859 and seems to me
that many of the problem have
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59586
Mircea Namolaru mircea.namolaru at inria dot fr changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55022
Mircea Namolaru mircea.namolaru at inria dot fr changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59121
--- Comment #19 from Mircea Namolaru mircea.namolaru at inria dot fr ---
The problem for many of these simple cases is with Graphite formulation of
memory accesses constraints. For Fortran, or C (if arrays are declared as
pointers), a memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59121
--- Comment #17 from Mircea Namolaru mircea.namolaru at inria dot fr ---
Yes, data dependencies computation is expensive in the polyehdral model
and it could take considerable time - but it is worrying that in too many
cases fails to provide
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59121
--- Comment #14 from Mircea Namolaru mircea.namolaru at inria dot fr ---
Confirmed.
Start looking at it. This test also enters in an endless loop with the
options -fgraphite-identiy -floop-nest-optimize -O2 -c.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59121
Mircea Namolaru mircea.namolaru at inria dot fr changed:
What|Removed |Added
CC
19 matches
Mail list logo
