mirrors/llvm-project
0
0
Fork 0
mirror of https://github.com/llvm/llvm-project.git synced 2025-04-26 19:36:05 +00:00
Code Issues Projects Releases Wiki Activity
llvm-project/flang/test/Semantics/array-constr-big.f90

29 lines
712 B
Fortran
Raw Normal View History

[Flang] Ported test_errors.sh to Python To enable Flang testing on Windows, shell scripts have to be ported to Python. In this patch the "test_errors.sh" script is ported to python ("test_errors.py"). The RUN line of existing tests was changed to make use of the python script. Used python regex in place of awk/sed. Reviewed By: Meinersbur Differential Revision: https://reviews.llvm.org/D107575
2021-09-06 08:19:20 +00:00
! RUN: %python %S/test_errors.py %s %flang_fc1
[flang] Allow large and erroneous ac-implied-do's We sometimes unroll an ac-implied-do of an array constructor into a flat list of values. We then re-analyze the array constructor that contains the resulting list of expressions. Such a list may or may not contain errors. But when processing an array constructor with an unrolled ac-implied-do, the compiler was building an expression to represent the extent of the resulting array constructor containing the list of values. The number of operands in this extent expression was based on the number of elements in the unrolled list of values. For very large lists, this created an expression so large that it could not be evaluated by the compiler without overflowing the stack. I fixed this by continuously folding the extent expression as each operand is added to it. I added the test .../flang/test/Semantics/array-constr-big.f90 that will cause the compiler to seg fault without this change. Also, when the unrolled ac-implied-do expression contains errors, we were repeating the same error message referencing the same source line for every instance of the erroneous expression in the unrolled list. This potentially resulted in a very long list of messages for a single error in the source code. I fixed this by comparing the message being emitted to the previously emitted message. If they are the same, I do not emit the message. This change is also tested by the new test array-constr-big.f90. Several of the existing tests had duplicate error messages for the same source line, and this change caused differences in their output. So I adjusted the tests to match the new message emitting behavior. Differential Revision: https://reviews.llvm.org/D102210
2021-05-10 19:39:05 -07:00
! Ensure that evaluating a very large array constructor does not crash the
! compiler
program BigArray
integer, parameter :: limit = 30
!ERROR: Must be a constant value
integer(foo),parameter :: jval4(limit,limit,limit) = &
!ERROR: Must be a constant value
reshape( (/ &
( &
( &
(0,ii=1,limit), &
jj=-limit,kk &
), &
( &
i4,jj=-kk,kk &
), &
( &
( &
!ERROR: Must be a constant value
0_foo,ii=1,limit &
[flang] Stricter "implicit continuation" in preprocessing The prescanner performs implicit line continuation when it looks like the parenthesized arguments of a call to a function-like macro may span multiple lines. In an attempt to work more like a Fortran-oblivious C preprocessor, the prescanner will act as if the following lines had been continuations so that the function-like macro could be invoked. This still seems like a good idea, but a recent bug report on LLVM's GitHub issue tracker shows one way in which it could trigger inadvertently and mess up a program. So this patch makes the conditions for implicit line continuation much more strict. First, the leading parenthesis has to have been preceded by an identifier that's known to be a macro name. (It doesn't have to be a function-like macro, since it's possible for a keyword-like macro to expand to the name of a function-like macro.) Second, no macro definition can ever have had unbalanced parentheses in its replacement text. Also cleans up some parenthesis recognition code to fix some issues found in testing, so that a token with leading or trailing spaces can still be recognized as a parenthesis or comma. Fixes https://github.com/llvm/llvm-project/issues/63844. Differential Revision: https://reviews.llvm.org/D155499
2023-07-13 16:26:23 -07:00
), &
[flang] Allow large and erroneous ac-implied-do's We sometimes unroll an ac-implied-do of an array constructor into a flat list of values. We then re-analyze the array constructor that contains the resulting list of expressions. Such a list may or may not contain errors. But when processing an array constructor with an unrolled ac-implied-do, the compiler was building an expression to represent the extent of the resulting array constructor containing the list of values. The number of operands in this extent expression was based on the number of elements in the unrolled list of values. For very large lists, this created an expression so large that it could not be evaluated by the compiler without overflowing the stack. I fixed this by continuously folding the extent expression as each operand is added to it. I added the test .../flang/test/Semantics/array-constr-big.f90 that will cause the compiler to seg fault without this change. Also, when the unrolled ac-implied-do expression contains errors, we were repeating the same error message referencing the same source line for every instance of the erroneous expression in the unrolled list. This potentially resulted in a very long list of messages for a single error in the source code. I fixed this by comparing the message being emitted to the previously emitted message. If they are the same, I do not emit the message. This change is also tested by the new test array-constr-big.f90. Several of the existing tests had duplicate error messages for the same source line, and this change caused differences in their output. So I adjusted the tests to match the new message emitting behavior. Differential Revision: https://reviews.llvm.org/D102210
2021-05-10 19:39:05 -07:00
jj=kk,limit &
), &
kk=1,limit &
) /), &
(/ limit /) )
end
Reference in New Issue Copy Permalink