Thread safety of libgfortran

[Jakub Jelinek <jakub at redhat dot com>]

Hi!

I have noticed libgfortran uses a bunch of global variables that make
it unusable in a threaded environment (like OpenMP).

>From what I understood, OpenMP only says results are undefined only if
multiple threads write into the same unit, so I guess concurent prints
into different units e.g. should be defined.

I skimmed global variables in libgfortran.so:

>From the public interfaces, it seems to be
_gfortran_filename, _gfortran_ioparm, _gfortran_line - all unsafe

environ.c:
variable_tables, options - might be ok if it is ever written before MAIN__
signal_choices, precision, rounding - should be IMHO const and is ok
error.c:
buffer - looks unsafe, will need redesigning of gfc_itoa/xtoa
magic - unsafe, though might not be a big deal, as it is printed
	on fatal messages only
main.c:
argc_save, argv_save - might be safe, if set_args is only ever called before
		       MAIN__
l8_to_l4_offset - this is doable at configure time or compile time,
		  shouldn't be done at runtime
memory.c:
mem_root - unsafe, all of memory.c will probably need locking
close.c:
status_opt - should be IMHO const and is ok
lock.c:
ionml, g - unsafe
format.c:
avail, array, format_string, string, error, saved_token,
value, format_string_len, reversion_ok, saved_format, colon_node - unsafe
posint_required, period_required, nonneg_required,
unexpected_element, unexpected_end, bad_string,
bad_hollerith, reversion_error - should be IMHO const, ok
inquire.c:
undefined - should be IMHO const and is ok
list_read.c:
repeat_count, saved_length, saved_used, input_complete,
at_eol, comma_flag, last_char, saved_string, saved_type,
namelist_mode, nml_read_error, value, parse_err_msg, nml_err_msg,
prev_nl, clow, chigh - unsafe
open.c:
access_opt, action_opt, blank_opt, delim_opt, pad_opt,
form_opt, position_opt, status_opt - should be IMHO const and is ok
transfer.c:
current_unit, sf_seen_eor, eor_condition, max_pos, skips,
pending_spaces, scratch, line_buffer, advance_status,
transfer, data - unsafe
advance_opt - should be IMHO const and is ok
unit.c:
unit_cache, internal_unit - unsafe
x0 - unsafe, either would need locking, __sync_compare_and_swap
     or why can't it use libc's random generator?
unix.c:
error - might need locking
yes, no, unknown - would be much better to make these
		   static const char yes[] = "YES" etc. rather
		   than static const char *yes = "YES"; when
		   nobody is really taking their address or
		   writing into those variables
write.c:
no_leading_blank, nml_delim, char_flag - unsafe
rand.c:
rand_seed - might need locking, or __thread or something
random.c:
kiss_seed - might need locking, or __thread or something
system_clock.c:
tp0 - unsafe
compile_options.c:
compile_options - not sure, might be safe

	Jakub