This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

A list of gfortran junior jobs


Hi all,

As was asked some time ago on the list, we currently don't have a list of "junior jobs", i.e. tasks that require only limited understanding of the guts of the compiler. Since GCC development is now back in stage 1, which is the right time window for adding new features, I'd like to list here a few features that are probably easy- to-medium difficulty, and that I personnaly would be glad to have into the next gfortran release series.

The criterion of choice is "the kind of things that would have seemed doable when I submitted my first few patches". Feel free to assign them to yourself in bugzilla and tell the list which one you'll be trying: that's no commitment, you can always unassign yourself if you can't make it work. Ask the list for things you don't understand, come and see us on the GCC IRC channel, in short: join the club!

Now, the list itself.

-- PR28484, "SYSTEM_CLOCK with real-type COUNT_RATE": intrinsics are probably the easier part of the Fortran front-end; what is needed here is to relax the checking (in check.c, function gfc_check_system_clock) and change the resolution to call two different library functions depending on the type of the COUNT_RATE argument (in iresolve.c, function gfc_resolve_system_clock). Copy the existing implementation of SYSTEM_CLOCK in libgfortran to make a version for real COUNT_RATE argument.

-- PR29240, "allow an additional arg to SIGNAL": once again, intrinsics are usually easy to deal with. There are already numerous intrinsic with optional args that you can peek at to see how it's handled, both on front-end and library side.

-- PR29452, "compile-time and run-time checks for I/O specifiers": the problem and solutions are very well described by Tobias Burnus in comment #2.

-- PR28378, "Intrinsic extensions should be deselectable via command line": adding a new option is fairly easy; this one needs a bit of C programming, probably creating a linked-list of names specified by the user to check them later on.

-- PR24285, "format(1000(a,$)) is not accepted": probably not too difficult, you simply have to change an error into a warning; but it first requires checking what other compilers accept and do.

Happy hacking!

FX


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]