------------------------------------------------------------------------------- GOMP - version 0.1 ------------------------------------------------------------------------------- In a nutshell: Allow for serial execution of openMP C programs!!! That is, allow gcc to do a line-based '#pragma omp' syntax check (incomplete openMP syntax check) and provide stubs for all the openMP runtime-library call. In short, gcc -fgomp -o foo foo.c -lgomp should produce a serial executable. Moreover, it should complain if the '#pragma omp' lines are incorrect (not in the context but only as single lines). Any library call should simply return the stub implementation from the specification. Environment variables relating to openMP should have no effect. ------------------------------------------------------------------------------- The front-end - version 0.1 ------------------------------------------------------------------------------- If foo is valid openMP code then it should be able to do a line-based '#pragma omp' syntax check of the input and approve/reject it based on this parse. It doesn't have to do serious syntax checking, i.e. it doesn't have to catch things like restriction violations and violations of the rules for directive nesting,... . That is, we will allow non-compliant samples such as those in A.19 to pass. ------------------------------------------------------------------------------- The middle-end - version 0.1 ------------------------------------------------------------------------------- Experts, relax. Feel free to have another zip of your favorite beverage and prepare yourselves for version 0.2 :) ------------------------------------------------------------------------------- The openMP runtime-library - version 0.1 ------------------------------------------------------------------------------- Make a stub implementation of the openMP run-time library (cf. app. B) allowing applications to link with and apply the stub functions in the library. Construct some tests that will allow us to validate the library functions. Maybe: implement some of the straightforward functions, e.g. omp_get_wtick(), omp_get_wtime(), omp_get_num_procs(). ------------------------------------------------------------------------------- Sample code for openMP - version 0.1 ------------------------------------------------------------------------------- Ensure that all programs from app. A are valid C programs (a quick scan showed that some of them lack variable declarations, header inclusions, functions, library linkage, ...). ------------------------------------------------------------------------------- Build environment ------------------------------------------------------------------------------- Ensure that we can build the library (static as well as shared) and that all the samples from app. B can be built. Moreover, ensure that we can construct a proper source package from the CVS extract that we can put on the web-page for people to download. We should not burden people with auto* problems if they just wish to play with the source. ------------------------------------------------------------------------------- code organization - version 0.1 ------------------------------------------------------------------------------- How should the code be organized in CVS and how should it be organized in the source snapshots (releases) ??? Below is a proposal to give us something to discuss from. ------------------------------------------------------------------------------- CVS organization - current roadmap ------------------------------------------------------------------------------- /doc/specs gompspec.tex /libgomp Makefile.am bootstrap configure.ac libgomp.h /libgomp/lib: This directory contains the stub implementation from the specification, cf. App. B. /libgomp/misc This directory contains the examples from the specification, cf. App. A. ------------------------------------------------------------------------------- CVS organization - proposal ------------------------------------------------------------------------------- Makefile.am bootstrap configure.ac TODO README Changelog /doc Makefile.am gompspec.tex /lib README Makefile.am as lib is today AND libgomp.h (PROPASAL: 'mv libgomp.h omp.h') /misc README Makefile.am as misc is today /test/gcc (samles of wrong openMP usage that we should catch) README Makefile.am foo.c ... /test/lib (various programs to test the library) README Makefile.am bar.c ... /gcc (the patches various versions of gcc) README Makefile.am gcc-/gcc/ flags.h toplev.c c-common.c c-parse.y c-pragma.[ch] ... As to the patches to gcc, I would suggest that we in CVS maintain a structure as described above. At first, I think that it would suffice to keep only the files from the upstream versions of gcc that we actually patch in the GOMP CVS. Alternatively, we could cvs import from upstream versions of gcc or we could even confine ourselves by simply leaving the gcc--gomp.patch in this directory. Yet another approach would be to have separate directories for each developer and then merge relevant parts once we have gathered some experiences from our individual experiments. ------------------------------------------------------------------------------- Source ball organization - version 0.1 ------------------------------------------------------------------------------- The target 'make dist' should produce the following source-packages: gomp-.tar.gz gcc--gomp-.tar.gz The 'gomp-.tar.gz' should contain both the library and the gcc-patches (as they appear in the GOMP CVS) whereas the gcc--gomp-.tar.gz packages only contains the two files: README gcc--gomp-.patch A description of how one applies the patch to the of gcc and the patch itself (a single file). It should make perfect sense to apply the patch gcc--gomp-.patch without applying the run-time library. -------------------------------------------------------------------------------