This is an archive of the discontinued LLVM Phabricator instance.

[SystemZ][z/OS] Add z/OS Target and define macros
ClosedPublic

Authored by abhina.sreeskantharajan on Aug 5 2020, 9:35 AM.

Diff Detail

Event Timeline

Herald added a project: Restricted Project. · View Herald TranscriptAug 5 2020, 9:35 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript
abhina.sreeskantharajan requested review of this revision.Aug 5 2020, 9:35 AM
anirudhp added inline comments.
clang/lib/Basic/Targets/OSTargets.h
745

What about the __LP64__ and the _LP64 macros?

clang/lib/Basic/Targets/OSTargets.h
745

These two are already added in the common code, so it would be redundant to add them again.

anirudhp added inline comments.Aug 5 2020, 9:48 AM
clang/lib/Basic/Targets/OSTargets.h
745

Alright Thanks!

abhina.sreeskantharajan added a reviewer: MaskRay.

Thanks MaskRay, I removed the extra braces.

abhina.sreeskantharajan marked an inline comment as done.Aug 5 2020, 10:24 AM
clang/lib/Basic/Targets/OSTargets.h
732

This is not defined by z/OS XL C/C++. It seems that this is more of a macro to be defined by a user application (perhaps as part of its configuration/port for z/OS) and less a macro that should be predefined by the compiler.

750

Shouldn't UTF literals be reported as being enabled under strict C++11?

753

Is this consistent with __has_extension with respect to -pedantic-errors?
That is, -pedantic-errors causes __has_extension to report the value that __has_feature would report. Compiler Explorer link: https://godbolt.org/z/EEn8rr

Same question for all of the other IBM-style feature test macros.

758

Should the comment instead say that __wchar_t should be defined so that the system headers do not try to declare wchar_t as a typedef?

761

Same comment as before re: macros that should be declared by the application.

764

I don't see the relation between C++11 and _Noreturn. It's an extension in C++ that's available under, e.g., -std=c++03.

767

char16_t is not a keyword in C11, so __IBM_CHAR16_T__ should not be defined for C. Same re: char32_t.

Also, char16_t and char32_t are indeed keywords in C++11.

770

The "IBMCPP" macro should not be defined in C modes.

I'm not familiar with the z/OS target, so I cannot check the correctness of the target-specific changes. The overall patch looks good.

clang/lib/Basic/Targets/OSTargets.h
780

It is possible to use inheriting constructor here instead (i.e. using OSTargetInfo<Target>::OSTargetInfo;).

clang/lib/Basic/Targets/OSTargets.h
780

Thanks Tatyana for your review! I think an inheriting constructor is also a good solution, but in order to maintain consistency with the other targets' constructors, I would prefer to keep it this way. Please let me know if there is a reason for using inherited constructors for this target, I may have missed something.

abhina.sreeskantharajan marked 2 inline comments as done.Aug 7 2020, 8:54 AM
abhina.sreeskantharajan added inline comments.
clang/lib/Basic/Targets/OSTargets.h
732

This is required for building libcxx, I'll add a comment here.

750

I will get back to you on this. I will need to investigate whether we are keeping this macro.

753

This macro is unused, so we are able to remove this.

758

You're right. I'll update the comment to be more accurate.

761

Same as above: This is required for building libcxx.

764

Thanks, I will remove CPlusPlus11.

767

Right, these seem to only require C++, so I will update the check. But I will also follow up on whether we plan to keep these macros here.

770

See above: I will update this, but continue to investigate whether we need this macro.

abhina.sreeskantharajan marked 2 inline comments as done.

Thanks Hubert for reviewing. I updated the patch to fix the wchar_t comment and the if guards for the macros. I also updated the lit test to reflect these new changes.

abhina.sreeskantharajan marked 4 inline comments as done.Aug 7 2020, 10:18 AM
abhina.sreeskantharajan retitled this revision from [z/OS] Add z/OS Target and define macros to [SystemZ][z/OS] Add z/OS Target and define macros .Aug 11 2020, 5:12 AM
clang/lib/Basic/Targets/OSTargets.h
730

The comment from https://reviews.llvm.org/D85324?id=283290#inline-786609 applies here as well. _LONG_LONG should not be defined under -std=c89 -pedantic-errors or -std=c89 -Werror=long-long.

753

s/so wchar_t/so that the wchar_t/;

755

The corresponding AIX code checks for -Xclang -fno-wchar. The behaviour of stddef.h differs when using -fno-wchar between AIX and Linux though. Linux suppresses the typedef based on __cplusplus. Arguably, the OS header difference should not really factor into whether the compiler defines a macro that indicates the presence of a wchar_t fundamental type.

766

The GNU extension modes do not cause u-prefixed, etc. string literals to be accepted where the base language level would treat the prefix as a separate identifier. Also noting here that the previous comment from https://reviews.llvm.org/D85324?id=283290#inline-786628 was made based on noting that __IBM_UTF_LITERAL is defined by the XL compiler in the appropriate C++ modes.

767

I would expect that the Clang implementation of the "IBM-style" feature test macros would behave similarly to the native feature testing in Clang. That is, __IBMC_NORETURN is defined when _Noreturn is available as an extension. _Noreturn is available as an "orthogonal" or "conforming" extension in modes such as -std=c89 and -std=c++03. The extension is disabled via warnings-as-errors.

770

See comment above re: GNU extension modes not enabling u-prefixed, etc. literals.

clang/lib/Basic/Targets/OSTargets.h
730

I can add a FIXME here similar to what AIX did.

//FIXME: LONG_LONG should not be defined under -std=c89

Let me know if there is a better solution.

755

Thanks, I will add the same guard that AIX uses.

766

We've updated the system headers so that we no longer need to define these macros.

767

Right, we are able to remove this macro.

Addressed Hubert's comments, and removed some macros that are unnecessary with system header updates.

abhina.sreeskantharajan marked 9 inline comments as done.Aug 17 2020, 7:09 AM
MaskRay added inline comments.Aug 17 2020, 10:43 AM
clang/test/Preprocessor/init.c
5633

The file has been split. You'll want to add new tests to init-zos.c or the like.

Not sure it is important to run so many invocations of clang_cc1. Can you pick some essential ones? The many invocations make the test slow.

Thanks MaskRay. I moved the zos testcase to a new file called init-zos.c instead and reduced the number of RUN commands.

abhina.sreeskantharajan marked an inline comment as done.Aug 17 2020, 11:16 AM
abhina.sreeskantharajan added inline comments.
clang/test/Preprocessor/init.c
5633

Thanks for the suggestion. I created a new file and reduced the number of invocations.

clang/lib/Basic/Targets/OSTargets.h
730

Minor nit: Typo.

The FIXME is okay until there's a reason to fix this. The review necessary for addressing the FIXME deserves another patch anyway.

The situation between z/OS and AIX is different for this case. On AIX, the C ABI compatibility of imaxdiv_t is affected. In other words, on AIX, fixing this might cause surprising behaviour.

737

Sorry for not catching this earlier, but this also needs a FIXME re: strict C89.

clang/test/Preprocessor/init-zos.c
5 ↗(On Diff #286092)

Should this be GNUXX?

abhina.sreeskantharajan marked an inline comment as done.

Thanks Hubert, I updated the comments, and also the check-prefix to your suggestion.

abhina.sreeskantharajan marked 3 inline comments as done.Aug 20 2020, 10:25 AM
abhina.sreeskantharajan added inline comments.
clang/lib/Basic/Targets/OSTargets.h
737

I've added a comment here.

clang/test/Preprocessor/init-zos.c
5 ↗(On Diff #286092)

I agree this is a better name, I've updated the name to your suggestion.

abhina.sreeskantharajan marked 2 inline comments as done.Aug 20 2020, 10:26 AM
MaskRay added inline comments.Aug 20 2020, 12:54 PM
clang/lib/Basic/Targets/OSTargets.h
737

What is strict -std=c89? !Opts.C99 ?

751

This is strange. On other systems the user requests it.

767

Does it need a value?

clang/test/Preprocessor/init-zos.c
4 ↗(On Diff #286853)

We usually drop // 'empty' lines. Their absence makes navigation easier.

clang/lib/Basic/Targets/OSTargets.h
737

The comment has a typo. The macro should not be defined with strict C89 modes.

What is strict -std=c89? !Opts.C99 ?

In the context of this macro, "strict C89" means !Opts.C99 and the severity of ext_c99_feature diagnostics is at least an error. This occurs, for example, with -std=gnu89 -Werror=c99-extensions.

Thanks for reviewing. I've updated the comments and removed ISOC99_SOURCE macro. I've updated the lit test to reflect these changes.

abhina.sreeskantharajan marked 5 inline comments as done.Aug 21 2020, 8:45 AM
abhina.sreeskantharajan added inline comments.
clang/lib/Basic/Targets/OSTargets.h
737

Thanks, I've fixed the comment.

751

Thanks, I've removed this macro to maintain consistency with other platforms.

767

No, this macro doesn't require a number. This macro is defined when the wchar_t type is available, so that the system headers do not declare it.

abhina.sreeskantharajan marked 3 inline comments as done.Aug 21 2020, 8:46 AM

LGTM from my end; although @MaskRay might want another look.

clang/lib/Basic/Targets/OSTargets.h
752

Minor nit: s/XOPEN_SOURCE/_XOPEN_SOURCE/;

This revision is now accepted and ready to land.Aug 21 2020, 11:49 AM

Thanks Hubert, I fixed the comment.

abhina.sreeskantharajan marked an inline comment as done.Aug 24 2020, 4:19 AM

Thanks Hubert, I fixed the comment.

Got it; I'll look into committing this.

Thanks Hubert, I fixed the comment.

Got it; I'll look into committing this.

Thanks again!

MaskRay added inline comments.Aug 26 2020, 10:34 AM
clang/test/Preprocessor/init-zos.c
4 ↗(On Diff #287757)

--match-full-lines is different from --match-full-lines --strict-whitespace. You can freely add leading and trailing spaces to align # for readability.

Might not be necessary changing now.

clang/test/Preprocessor/init-zos.c
4 ↗(On Diff #287757)

Thanks MaskRay, I will try to update this testcase in upcoming patches that touch this file.

abhina.sreeskantharajan marked an inline comment as done.Sep 1 2020, 7:02 AM