Add align pragma for scalar data types (integer, logical, real, complex)

[GARRYHU]

Add support for aligning the first address of scalar data types (integer, logical, real, complex) with align pragma like "!dir$ align n".

For example:

!dir$ align 128
integer(kind=4) :: a

The align pragma enables the first address of variable "a" to be an integer multiple of 128.

The overall idea for this patch is as follows:

• flang1:
  1. recognize the align pragma in the source code in do_sw()
  2. add a field to the ST_VAR symbol table to store the align value
  3. add ALIGN_PRAGMA *align_pragma_base to store all the align pragmas info parsed in the first pass
  4. match all the align pragmas and corresponding variables and set the variable's align value at the end of parse
  5. print the variable's align value in lower_symbol()
• flang2:
  1. add a field to the ST_VAR symbol table to store the align value
  2. read and set the variable's align value in read_symbol()
  3. set the LL_Object::align_bytes field with the symbol's align field when creating an LLVM variable object
  4. adjust the size and align of common block according to the align value of variables in it, set the first address of a variable in the common block an integer multiple of the variable's align value.

This patch can be combined with #1360, which adds align pragma support for derived types and fixed shape array/character types. These two patches enable flang to support align pragma for most common data types.

I test locally through make check-flang-long, and also pass some custom tests and add them to the test folder.

[JiaweiHawk]

Hi @GARRYHU,

It appears that our two pull requests(my pr link) contain a lot of code overlap.

I am of the opinion that we could work together to extract shared infrastructure and then continue with the subsequent tasks.

Are you interested in this?

[GARRYHU]

Hi @GARRYHU,

It appears that our two pull requests(my pr link) contain a lot of code overlap.

I am of the opinion that we could work together to extract shared infrastructure and then continue with the subsequent tasks.

Are you interested in this?

Sure, I am glad to do that.

[bryanpkc]

@GARRYHU Thank you for your PR. As @JiaweiHawk already pointed out, there is probably an opportunity for you two to work together. We have already been reviewing #1360 for quite some time, so I suggest we get that one merged first, then you can submit a new version of this PR that's rebased on top of that one. How does that sound?

[GARRYHU]

@GARRYHU Thank you for your PR. As @JiaweiHawk already pointed out, there is probably an opportunity for you two to work together. We have already been reviewing #1360 for quite some time, so I suggest we get that one merged first, then you can submit a new version of this PR that's rebased on top of that one. How does that sound?

OK, we will work together to make #1360 merged first!

[bryanpkc]

@GARRYHU @JiaweiHawk Now that #1360 has been merged, what is your plan for this PR? Will you rewrite it based on the latest master branch?

[GARRYHU]

@GARRYHU @JiaweiHawk Now that #1360 has been merged, what is your plan for this PR? Will you rewrite it based on the latest master branch?

I'll try to rewrite my part based on the latest master branch next week (after my final exam)!

[GARRYHU]

@bryanpkc After the refactoring work @JiaweiHawk and I did on #1360, the new version can support not only the alignment of data types like array, but also scalar data types (integer, logical, real, complex). Therefore, I just need to add some testcases for scalar data types on the basis of #1360. I have rebased this PR to add the testcases.

[pawosm-arm]

Note that the sole commit in this PR is only about adding the test cases, not the feature advertised by the PR topic. As the test case looks ok and the regexp used in it seem generic enough, I'm approving it anyway.

[bryanpkc]

LGTM too.