maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/flang/test/Semantics/shape.f90

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

50 lines
2.0 KiB
Fortran
Raw Normal View History

[flang] Fix "EQ" comparison of arrays When comparing arrays whose shapes do not conform, the contant folding code ran into problems trying to get the value of an extent that did not exist. There were actually two problems. First, the routine "CheckConformance()" was returning "true" when the compiler was unable to get the extent of an array. Second, the function "ApplyElementwise()" was calling "CheckConformance()" prior to folding the elements of two arrays, but it was ignoring the return value. Differential Revision: https://reviews.llvm.org/D91440
2020-11-14 01:31:41 +08:00
! RUN: %S/test_errors.sh %s %t %f18
! Test comparisons that use the intrinsic SHAPE() as an operand
program testShape
contains
subroutine sub1(arrayDummy)
integer :: arrayDummy(:)
integer, allocatable :: arrayDeferred(:)
integer :: arrayLocal(2) = [88, 99]
[flang] Fix classification of shape inquiries in specification exprs In some contexts, including the motivating case of determining whether the expressions that define the shape of a variable are "constant expressions" in the sense of the Fortran standard, expression rewriting via Fold() is not necessary, and should not be required. The inquiry intrinsics LBOUND, UBOUND, and SIZE work correctly now in specification expressions and are classified correctly as being constant expressions (or not). Getting this right led to a fair amount of API clean-up as a consequence, including the folding of shapes and TypeAndShape objects, and new APIs for shapes that do not fold for those cases where folding isn't needed. Further, the symbol-testing predicate APIs in Evaluate/tools.h now all resolve any associations of their symbols and work transparently on use-, host-, and construct-association symbols; the tools used to resolve those associations have been defined and documented more precisely, and their clients adjusted as needed. Differential Revision: https://reviews.llvm.org/D94561
2021-01-13 07:36:45 +08:00
!ERROR: Dimension 1 of left operand has extent 1, but right operand has extent 0
!ERROR: Dimension 1 of left operand has extent 1, but right operand has extent 0
[flang] Fix "EQ" comparison of arrays When comparing arrays whose shapes do not conform, the contant folding code ran into problems trying to get the value of an extent that did not exist. There were actually two problems. First, the routine "CheckConformance()" was returning "true" when the compiler was unable to get the extent of an array. Second, the function "ApplyElementwise()" was calling "CheckConformance()" prior to folding the elements of two arrays, but it was ignoring the return value. Differential Revision: https://reviews.llvm.org/D91440
2020-11-14 01:31:41 +08:00
if (all(shape(arrayDummy)==shape(8))) then
print *, "hello"
end if
[flang] Fix classification of shape inquiries in specification exprs In some contexts, including the motivating case of determining whether the expressions that define the shape of a variable are "constant expressions" in the sense of the Fortran standard, expression rewriting via Fold() is not necessary, and should not be required. The inquiry intrinsics LBOUND, UBOUND, and SIZE work correctly now in specification expressions and are classified correctly as being constant expressions (or not). Getting this right led to a fair amount of API clean-up as a consequence, including the folding of shapes and TypeAndShape objects, and new APIs for shapes that do not fold for those cases where folding isn't needed. Further, the symbol-testing predicate APIs in Evaluate/tools.h now all resolve any associations of their symbols and work transparently on use-, host-, and construct-association symbols; the tools used to resolve those associations have been defined and documented more precisely, and their clients adjusted as needed. Differential Revision: https://reviews.llvm.org/D94561
2021-01-13 07:36:45 +08:00
!ERROR: Dimension 1 of left operand has extent 0, but right operand has extent 1
!ERROR: Dimension 1 of left operand has extent 0, but right operand has extent 1
[flang] Fix "EQ" comparison of arrays When comparing arrays whose shapes do not conform, the contant folding code ran into problems trying to get the value of an extent that did not exist. There were actually two problems. First, the routine "CheckConformance()" was returning "true" when the compiler was unable to get the extent of an array. Second, the function "ApplyElementwise()" was calling "CheckConformance()" prior to folding the elements of two arrays, but it was ignoring the return value. Differential Revision: https://reviews.llvm.org/D91440
2020-11-14 01:31:41 +08:00
if (all(shape(27)==shape(arrayDummy))) then
print *, "hello"
end if
if (all(64==shape(arrayDummy))) then
print *, "hello"
end if
[flang] Fix classification of shape inquiries in specification exprs In some contexts, including the motivating case of determining whether the expressions that define the shape of a variable are "constant expressions" in the sense of the Fortran standard, expression rewriting via Fold() is not necessary, and should not be required. The inquiry intrinsics LBOUND, UBOUND, and SIZE work correctly now in specification expressions and are classified correctly as being constant expressions (or not). Getting this right led to a fair amount of API clean-up as a consequence, including the folding of shapes and TypeAndShape objects, and new APIs for shapes that do not fold for those cases where folding isn't needed. Further, the symbol-testing predicate APIs in Evaluate/tools.h now all resolve any associations of their symbols and work transparently on use-, host-, and construct-association symbols; the tools used to resolve those associations have been defined and documented more precisely, and their clients adjusted as needed. Differential Revision: https://reviews.llvm.org/D94561
2021-01-13 07:36:45 +08:00
!ERROR: Dimension 1 of left operand has extent 1, but right operand has extent 0
!ERROR: Dimension 1 of left operand has extent 1, but right operand has extent 0
[flang] Fix "EQ" comparison of arrays When comparing arrays whose shapes do not conform, the contant folding code ran into problems trying to get the value of an extent that did not exist. There were actually two problems. First, the routine "CheckConformance()" was returning "true" when the compiler was unable to get the extent of an array. Second, the function "ApplyElementwise()" was calling "CheckConformance()" prior to folding the elements of two arrays, but it was ignoring the return value. Differential Revision: https://reviews.llvm.org/D91440
2020-11-14 01:31:41 +08:00
if (all(shape(arrayDeferred)==shape(8))) then
print *, "hello"
end if
[flang] Fix classification of shape inquiries in specification exprs In some contexts, including the motivating case of determining whether the expressions that define the shape of a variable are "constant expressions" in the sense of the Fortran standard, expression rewriting via Fold() is not necessary, and should not be required. The inquiry intrinsics LBOUND, UBOUND, and SIZE work correctly now in specification expressions and are classified correctly as being constant expressions (or not). Getting this right led to a fair amount of API clean-up as a consequence, including the folding of shapes and TypeAndShape objects, and new APIs for shapes that do not fold for those cases where folding isn't needed. Further, the symbol-testing predicate APIs in Evaluate/tools.h now all resolve any associations of their symbols and work transparently on use-, host-, and construct-association symbols; the tools used to resolve those associations have been defined and documented more precisely, and their clients adjusted as needed. Differential Revision: https://reviews.llvm.org/D94561
2021-01-13 07:36:45 +08:00
!ERROR: Dimension 1 of left operand has extent 0, but right operand has extent 1
!ERROR: Dimension 1 of left operand has extent 0, but right operand has extent 1
[flang] Fix "EQ" comparison of arrays When comparing arrays whose shapes do not conform, the contant folding code ran into problems trying to get the value of an extent that did not exist. There were actually two problems. First, the routine "CheckConformance()" was returning "true" when the compiler was unable to get the extent of an array. Second, the function "ApplyElementwise()" was calling "CheckConformance()" prior to folding the elements of two arrays, but it was ignoring the return value. Differential Revision: https://reviews.llvm.org/D91440
2020-11-14 01:31:41 +08:00
if (all(shape(27)==shape(arrayDeferred))) then
print *, "hello"
end if
if (all(64==shape(arrayDeferred))) then
print *, "hello"
end if
!ERROR: Dimension 1 of left operand has extent 1, but right operand has extent 0
!ERROR: Dimension 1 of left operand has extent 1, but right operand has extent 0
if (all(shape(arrayLocal)==shape(8))) then
print *, "hello"
end if
!ERROR: Dimension 1 of left operand has extent 0, but right operand has extent 1
!ERROR: Dimension 1 of left operand has extent 0, but right operand has extent 1
if (all(shape(27)==shape(arrayLocal))) then
print *, "hello"
end if
if (all(64==shape(arrayLocal))) then
print *, "hello"
end if
end subroutine sub1
end program testShape