[committed] fix typos in attribute malloc example

2021-02-07 Thread Martin Sebor via Gcc-patches

I noticed typos in the example of the new form of attribute malloc.
I pushed the attached patch to correct them.

Martin
commit fe2034e9c039c998fc5da730ed531c61cf2e0b7d
Author: Martin Sebor 
Date:   Sun Feb 7 17:21:32 2021 -0700

Correct typos in attribute malloc documentation.

gcc/ChangeLog:
* doc/extend.texi (attribute malloc): Correct typos.

diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 2cfd8cdf883..e110cb01061 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -3258,7 +3258,9 @@ objects.
 
 Associating a function with a @var{deallocator} helps detect calls to
 mismatched allocation and deallocation functions and diagnose them under
-the control of options such as @option{-Wmismatched-dealloc}.  To indicate
+the control of options such as @option{-Wmismatched-dealloc}.  It also
+makes it possible to diagnose attempts to deallocate objects that were not
+allocated dynamically, by @option{-Wfree-nonheap-object}.  To indicate
 that an allocation function both satisifies the nonaliasing property and
 has a deallocator associated with it, both the plain form of the attribute
 and the one with the @var{deallocator} argument must be used.  The same
@@ -3273,21 +3275,21 @@ not alias any others, the following declarations make @code{fclose}
 a suitable deallocator for pointers returned from all functions except
 @code{popen}, and @code{pclose} as the only suitable deallocator for
 pointers returned from @code{popen}.  The deallocator functions must
-declared before they can be referenced in the attribute.
+be declared before they can be referenced in the attribute.
 
 @smallexample
 int fclose (FILE*);
 int pclose (FILE*);
 
-__attribute__ ((malloc, malloc (fclose (1
-  FILE* fdopen (int);
-__attribute__ ((malloc, malloc (fclose (1
+__attribute__ ((malloc, malloc (fclose, 1)))
+  FILE* fdopen (int, const char*);
+__attribute__ ((malloc, malloc (fclose, 1)))
   FILE* fopen (const char*, const char*);
-__attribute__ ((malloc, malloc (fclose (1
+__attribute__ ((malloc, malloc (fclose, 1)))
   FILE* fmemopen(void *, size_t, const char *);
-__attribute__ ((malloc, malloc (pclose (1
+__attribute__ ((malloc, malloc (pclose, 1)))
   FILE* popen (const char*, const char*);
-__attribute__ ((malloc, malloc (fclose (1
+__attribute__ ((malloc, malloc (fclose, 1)))
   FILE* tmpfile (void);
 @end smallexample
 


[PATCH] mklog: automatically fill in generated entries

2021-02-07 Thread Mike Frysinger via Gcc-patches
contrib/ChangeLog:

* mklog.py (generated_files): New set.
(generate_changelog): Add entries based on generated_files.
---
 contrib/mklog.py | 5 +
 1 file changed, 5 insertions(+)

diff --git a/contrib/mklog.py b/contrib/mklog.py
index a70536a6849a..6509886741d7 100755
--- a/contrib/mklog.py
+++ b/contrib/mklog.py
@@ -55,6 +55,9 @@ bugzilla_url = 
'https://gcc.gnu.org/bugzilla/rest.cgi/bug?id=%s&;' \
 
 function_extensions = {'.c', '.cpp', '.C', '.cc', '.h', '.inc', '.def', '.md'}
 
+# NB: Makefile.in isn't listed as it's not always generated.
+generated_files = {'aclocal.m4', 'config.h.in', 'configure'}
+
 help_message = """\
 Generate ChangeLog template for PATCH.
 PATCH must be generated using diff(1)'s -up or -cp options
@@ -192,6 +195,8 @@ def generate_changelog(data, no_functions=False, 
fill_pr_titles=False):
 if new_path.startswith(changelog):
 new_path = new_path[len(changelog):].lstrip('/')
 out += '\t* %s: ...here.\n' % (new_path)
+elif os.path.basename(file.path) in generated_files:
+out += '\t* %s: Regenerate.\n' % (relative_path)
 else:
 if not no_functions:
 for hunk in file:
-- 
2.30.0



Re: [patch, libgfortran] PR98825 Unexpected behavior of FORTRAN FORMAT expressions when suppressing new line with '$'

2021-02-07 Thread Thomas Koenig via Gcc-patches



Hi Jerry,


OK for trunk and backport to 10 since it is simple enough?


OK for trunk.

Because this is a user-visible change (even if we did the wrong
thing before) I don't feel that we should backport (but I am
open to suggestions otherwise).

Could you also mention this in gcc-11/changes.html ?

Best regards

Thomas


[patch, libgfortran] PR98825 Unexpected behavior of FORTRAN FORMAT expressions when suppressing new line with '$'

2021-02-07 Thread Jerry DeLisle

Hello all,

Attached patch fixes this and adds a test case. The "$" edit descriptor 
was being completely ignored when next_record_w is processed. Fixed by 
adding a simple check.


OK for trunk and backport to 10 since it is simple enough?

Regards,

Jerry

libgfortran: Do not emit end-of-record if seen_dollar.

2021-02-07  Jerry DeLisle  

libgfortran/ChangeLog:
    PR libgfortran/98825
    * io/transfer.c (next_record_w): Insert check for seen_dollar and if
    so, skip issueing next record.

gcc/testsuite/ChangeLog:

    * gfortran.dg/dollar_edit_descriptor_4.f: New test.

diff --git a/gcc/testsuite/gfortran.dg/dollar_edit_descriptor_4.f b/gcc/testsuite/gfortran.dg/dollar_edit_descriptor_4.f
new file mode 100644
index 000..c8453ce6bc8
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/dollar_edit_descriptor_4.f
@@ -0,0 +1,16 @@
+! { dg-do run }
+! { dg-options "-std=gnu" }
+! PR98825 Test for fix of '$' edit descriptor.
+  character(30) :: line
+   10 format (i3,$)
+
+  open(10, status='scratch')
+  write (10,10) 1
+  write (10,10) 2,3,4,5
+! Check the result.
+  line = 'abcdefg'
+  rewind(10)
+  read(10, '(a)') line
+  close(10)
+  if (line .ne. '  1  2  3  4  5') call abort
+  end
diff --git a/libgfortran/io/transfer.c b/libgfortran/io/transfer.c
index 8ab0583dd55..27bee9d4e01 100644
--- a/libgfortran/io/transfer.c
+++ b/libgfortran/io/transfer.c
@@ -4020,6 +4020,8 @@ next_record_w (st_parameter_dt *dtp, int done)
 		}
 	}
 	}
+  else if (dtp->u.p.seen_dollar == 1)
+	break;
   /* Handle legacy CARRIAGECONTROL line endings.  */
   else if (dtp->u.p.current_unit->flags.cc == CC_FORTRAN)
 	next_record_cc (dtp);


Re: [PATCH 2/2] RISC-V: Add riscv{32, 64}be with big endian as default

2021-02-07 Thread Marcus Comstedt


Hi again.

Sorry, but I just realized that the "-melf" part isn't the same in all
of {elf,linux,freebsd}.h; linux.h has a LD_EMUL_SUFFIX which the other
two are lacking.  Which means that the only truly common part is

  %{mbig-endian:-EB} \
  %{mlittle-endian:-EL} \

So is it worth a define to change two lines duplicated in three files
into one line duplicated in three files?  The define would not even
cover all of the endianness stuff.


  // Marcus