Message ID | 56BF19DE.9040404@netcologne.de |
---|---|
State | New |
Headers | show |
On Sat, Feb 13, 2016 at 1:56 PM, Thomas Koenig <tkoenig@netcologne.de> wrote: > Am 12.02.2016 um 11:42 schrieb Janne Blomqvist: >> >> On Fri, Feb 12, 2016 at 12:16 PM, Andre Vehreschild <vehre@gmx.de> wrote: > > >>> The proposed alloca() call >>> has according to the documentation of libc some availability issues on >>> certain platforms, too. > > > These availablity issues cannot be too serious, or we would be having > trouble already: > > ig25@linux-fd1f:~/Gcc/trunk/gcc/fortran> fgrep -H -n 'alloca (' *.c > cpp.c:839: to_file_quoted = (unsigned char *) alloca (to_file_len * 4 + > 1); > cpp.c:1079: (unsigned char *) alloca (to_file_len * 4 + 1); > error.c:898: buffer = (char *) alloca (strlen (msg) + strlen (msg2) + 2); > module.c:6042: filename = (char *) alloca (n); > module.c:6048: filename = (char *) alloca (n); > module.c:6058: filename_tmp = (char *) alloca (n + 1); > options.c:267: source_path = (char *) alloca (i + 1); > primary.c:214: buffer = (char *) alloca (length + 1); > primary.c:438: buffer = (char *) alloca (length + 1); > primary.c:600: buffer = (char *) alloca (count + 1); > scanner.c:321: q = (char *) alloca (len + 1); > simplify.c:6381: buffer = (unsigned char*)alloca (buffer_size); > target-memory.c:674: buffer = (unsigned char*)alloca (len); > target-memory.c:781: buffer = (unsigned char*)alloca (buffer_size); > >>> Therefore why not going with the fixed size >>> stack array and adding a check for possible overflow to it and be done? >> >> >> Yes, I agree. That sounds like the best approach in this case. > > > OK, here is the final version of the patch. I'd like to get this > committed so I can turn to PR 69742. Ok, thanks for the patch.
On Sat, Feb 13, 2016 at 3:56 AM, Thomas Koenig <tkoenig@netcologne.de> wrote: > Am 12.02.2016 um 11:42 schrieb Janne Blomqvist: >> >> On Fri, Feb 12, 2016 at 12:16 PM, Andre Vehreschild <vehre@gmx.de> wrote: > > >>> The proposed alloca() call >>> has according to the documentation of libc some availability issues on >>> certain platforms, too. > > > These availablity issues cannot be too serious, or we would be having > trouble already: > > ig25@linux-fd1f:~/Gcc/trunk/gcc/fortran> fgrep -H -n 'alloca (' *.c > cpp.c:839: to_file_quoted = (unsigned char *) alloca (to_file_len * 4 + > 1); > cpp.c:1079: (unsigned char *) alloca (to_file_len * 4 + 1); > error.c:898: buffer = (char *) alloca (strlen (msg) + strlen (msg2) + 2); > module.c:6042: filename = (char *) alloca (n); > module.c:6048: filename = (char *) alloca (n); > module.c:6058: filename_tmp = (char *) alloca (n + 1); > options.c:267: source_path = (char *) alloca (i + 1); > primary.c:214: buffer = (char *) alloca (length + 1); > primary.c:438: buffer = (char *) alloca (length + 1); > primary.c:600: buffer = (char *) alloca (count + 1); > scanner.c:321: q = (char *) alloca (len + 1); > simplify.c:6381: buffer = (unsigned char*)alloca (buffer_size); > target-memory.c:674: buffer = (unsigned char*)alloca (len); > target-memory.c:781: buffer = (unsigned char*)alloca (buffer_size); > >>> Therefore why not going with the fixed size >>> stack array and adding a check for possible overflow to it and be done? >> >> >> Yes, I agree. That sounds like the best approach in this case. > > > OK, here is the final version of the patch. I'd like to get this > committed so I can turn to PR 69742. > > Regards > > Thomas > > > > 2016-02-03 Thomas Koenig <tkoenig@gcc.gnu.org> > > PR fortran/60526 > * decl.c (build_sym): If the name has already been defined as a > type, issue error and return false. > > 2016-02-03 Thomas Koenig <tkoenig@gcc.gnu.org> > > PR fortran/60526 > * gfortran.dg/type_decl_4.f90: New test. > It breaks bootstrap on x86: ../../../src-trunk/libgfortran/intrinsics/selected_int_kind.f90:28:40: integer :: _gfortran_selected_int_kind 1 Error: Symbol \u2018_gfortran_selected_int_kind\u2019 at (1) also declared as a type at (2) f951: Fatal Error: Option \u2018-fallow-leading-underscore\u2019 is for use only by gfortran developers, and should not be used for implicitly typed variables compilation terminated. Makefile:5679: recipe for target 'selected_int_kind.lo' failed make[6]: *** [selected_int_kind.lo] Error 1
Index: decl.c =================================================================== --- decl.c (Revision 232864) +++ decl.c (Arbeitskopie) @@ -1215,10 +1215,30 @@ build_sym (const char *name, gfc_charlen *cl, bool { symbol_attribute attr; gfc_symbol *sym; + int nlen; + char u_name[GFC_MAX_SYMBOL_LEN + 1]; + gfc_symtree *st; if (gfc_get_symbol (name, NULL, &sym)) return false; + /* Check if the name has already been defined as a type. The + first letter of the symtree will be in upper case then. */ + + nlen = strlen(name); + gcc_assert (nlen <= GFC_MAX_SYMBOL_LEN); + strncpy (u_name, name, nlen + 1); + u_name[0] = TOUPPER(u_name[0]); + + st = gfc_find_symtree (gfc_current_ns->sym_root, u_name); + + if (st != 0) + { + gfc_error ("Symbol %qs at %C also declared as a type at %L", name, + &st->n.sym->declared_at); + return false; + } + /* Start updating the symbol table. Add basic type attribute if present. */ if (current_ts.type != BT_UNKNOWN && (sym->attr.implicit_type == 0