[PATCH] D107972: [Flang] Fix build failure on MacOS
Dimitry Andric via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu Aug 19 12:27:19 PDT 2021
dim added a comment.
In D107972#2955218 <https://reviews.llvm.org/D107972#2955218>, @kiranchandramohan wrote:
> In D107972#2945251 <https://reviews.llvm.org/D107972#2945251>, @kiranchandramohan wrote:
>
>> In D107972#2941882 <https://reviews.llvm.org/D107972#2941882>, @dim wrote:
>>
>>> Thanks. This should be merged to 13.0.0, if possible.
>>>
>>> Meanwhile, if I may take a moment of your attention, I ran into this particular error (narrowing `{-1}` to `clock_t`) while doing the 13.0.0 rc1 builds for i386-freebsd, i.e. 32-bit x86. Since I encountered a whole lot of other issues where 32 and 64 bit quantities were mixed, does it make sense at all to attempt to build flang on 32-bit systems?
>>>
>>> My guess is that this was never a goal, and 64 bit systems (i.e. LP64) are really the only support targets?
>>
>> Could @sscalpone or @klausler or @schweitz take this question?
>
> @dim I did not get a chance to discuss this with everyone. But my understanding is that at the moment we test only for 64 bit systems. Support for 32 bit systems (I think) is not ruled out but is not of immediate interest.
Thank you! This was just out of interest, to see if I could add the flang component to my FreeBSD release builds for 32-bit x86. (For x86_64 I did not encounter build issues in flang itself, except maybe for a few warnings.)
I think it might be quite some effort to make it buildable on 32-bit systems, since I've seen that flang uses many 'index' variables which are declared explicitly as int64_t or uint64_t, and these are freely mixed with size_t's. You'd have to carefully go over all of these to see where you can cleanly convert back and forth...
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D107972/new/
https://reviews.llvm.org/D107972
More information about the llvm-commits
mailing list