search

sourceryinstitute / OpenCoarrays

A parallel application binary interface for Fortran 2018 compilers.
http://www.opencoarrays.org
BSD 3-Clause "New" or "Revised" License
245 stars 58 forks source link

Defect: GCC C extensions used in multiple locations #549

Closed zbeekman closed 5 years ago

zbeekman commented 6 years ago
Avg response time
Issue Stats

Defect/Bug Report

Observed Behavior

See also discussion at https://github.com/Homebrew/homebrew-core/pull/28534

SEE ALSO: #485 these issues are nearly duplicates.

Expected Behavior

Be able to compile all components written in C because the C code is standards conforming

Steps to Reproduce

compile using clang instead of gcc

Discussion

@dcelisgarza:

  1. Is there no option other than enumerating every possible rank?
  2. Could this be done with a macro?
  3. Could you point from within the struct to an external VLA?

I don't want you to have to do anything that is "tedious as hell" but it would be nice to get standard complying C code. Otherwise I can just test for the ability to compile the code in question and if it fails exclude the iso_fortran_binding stuff.

fxcoudert commented 6 years ago

“Variable Length Array's in Structs (VLAIS) and why they don't belong in your C code” https://blog.linuxplumbersconf.org/2013/ocw/system/presentations/1221/original/VLAIS.pdf

rouson commented 6 years ago

FX,

The student who worked on this did so as part of an 11-week visit to Sourcery Institute that ended yesterday. He's unlikely to be able to work on OpenCoarrays going forward other than writing up his work. He's also on vacation for all of June. It sounds like you might have the expertise to fix this and I'm hoping you might pitch in. Very nearly all OpenCoarrays development going forward will be from community contributions as there are no related contracts and the few people who have related funding have very specific objectives that don't relate to this file.

Damian

On Fri, Jun 1, 2018 at 7:55 AM, FX Coudert notifications@github.com wrote:

“Variable Length Array's in Structs (VLAIS) and why they don't belong in your C code” https://blog.linuxplumbersconf.org/2013/ ocw/system/presentations/1221/original/VLAIS.pdf

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/sourceryinstitute/OpenCoarrays/issues/549#issuecomment-393906044, or mute the thread https://github.com/notifications/unsubscribe-auth/AMgGhL7n-DBIoreGnYZQbePvPUzur7aAks5t4VXfgaJpZM4UWwSj .

fxcoudert commented 6 years ago

Hi @rouson I personally have no use for Opencoarrays, and though I wish the project well, I have no time to contribute. I also would not like to contribute to a project were certain contributors are paid, and myself (with what I would consider to be similar expertise, academic background and software skills) doing it on my free time.

It is sad that development is contract-based and does not include producing standard code. This could have been caught during review of the student's code, if GCC was systematically called with a standard-compliance option (-std=c99), or if multiple compilers were tested (in this case, clang/llvm).

Regarding Homebrew, if there is no incentive to commit to cross-platform code, given this is the second release of Opencoarrays that is broken, I will recommend simply removing it unless there is a commitment from the Opencoarrays team to make a release which fixes the issue.

scrasmussen commented 6 years ago

Hi @rouson, fyi if you'd like this is something that I could start working on tomorrow. On my flight I'll try to take a look at it. -Soren

rouson commented 6 years ago

Thanks, @scrasmussen. That would be great!

dcelisgarza commented 6 years ago

I have thought about this and there might be a solution.

I don't know if you can include if statements in macros, or perhaps pounded ifs? That would make it so C can declare a variable according to a given an explicitly typed struct. That would solve our issue, we'd only have to define explicitly typed structs and the function-like macro.

zbeekman commented 6 years ago

@fxcoudert We are committed to fixing this and using standard conforming code.

Most of the development of OpenCoarrays is unfunded with very sporadic funding here and there. The goals of OpenCoarrays and SourceryInstitute are to (as best we can) advance support for the latest modern Fortran language standards in the broader community. Any funding for OpenCoarrays is usually from donations, and most work is performed by volunteers. We are committed to open source and supporting and enhancing the open source computing and broader scientific computing community.

The first issue that broke OpenCoarrays was due to a sloppy commit to the GFortran code base right before the 8.1 release, that was completely out of our control. In fact it can cause ICEs with any coarray code, even when using the serial testing backend that ships with GFortran.

We agree that OpenCoarrays should be portable and standards conforming and will ensure that OpenCoarrays can build cleanly on MacOS with Homebrew ASAP.

Thanks for your contributions to Homebrew, GFortran and your patience in working with us as we resolve this issue.

Best, Zaak

zbeekman commented 6 years ago

In general, we are not C99 or C11 compliant AFAICT. The first errors show up compiling mpi_caf.c in macros for type conversion:

OpenCoarrays/src/mpi/mpi_caf.c:7180:70: error: expected ';' before 'opr'
               type ## _t_by_value = (typeof (VALUE_FUNC(type ## _t)))opr; \
                                                                      ^~~

My C macro wrangling fu is not quite strong enough to see what the obvious solution to this is, but it seems like it should be fairly trivial. Perhaps an additional ##?

zbeekman commented 6 years ago

PR #557 excludes ISO_Fortran_binding.h when the C compiler is not GCC. This is a work around for now... in the long run we should plan to remove VLAs

stale[bot] commented 5 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

zbeekman commented 5 years ago

I'm closing this. We're back down to only two warnings about structs with arrays that are not the final component. I should open a new issue for that.