[Bug lto/106170] x86_64-w64-mingw32 host GCC with win32 thread model does not provide pthread.h. lto-plugin fails with canadian compilation

[unlvsur at live dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106170

cqwrteur  changed:

   What|Removed |Added

  Attachment #53242|0   |1
is obsolete||

--- Comment #3 from cqwrteur  ---
Created attachment 53243
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53243=edit
Update patch

[Bug lto/106170] x86_64-w64-mingw32 host GCC with win32 thread model does not provide pthread.h. lto-plugin fails with canadian compilation

[unlvsur at live dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106170

cqwrteur  changed:

   What|Removed |Added

 CC||unlvsur at live dot com

--- Comment #2 from cqwrteur  ---
Created attachment 53242
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53242=edit
This patch just fixed the compilation part for windows. -pthread flag is a huge
issue

I do not know how to fix that.

[Bug lto/106118] lto-plugin/lto-plugin.c: -pthread not passed to AM_LDFLAGS

[unlvsur at live dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106118

cqwrteur  changed:

   What|Removed |Added

 CC||unlvsur at live dot com

--- Comment #4 from cqwrteur  ---
(In reply to Martin Liška from comment #3)
> Should be fixed now.

This patch is just wrong. Since windows simply does not provide libpthread.a

you have win32, posix, and mcf 3 kinds of threads.

Plus a lot of single-thread targets.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106170

[Bug lto/106170] x86_64-w64-mingw32 host GCC with win32 thread model does not provide pthread.h. lto-plugin fails with canadian compilation

[unlvsur at live dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106170

--- Comment #1 from cqwrteur  ---
windows does not provide those things. You can use EnterCriticalSection/
LeaveCriticalSection instead.

I can write a patch to fix it for windows.

[Bug lto/106170] New: win32 thread model does not pthread.h. lto-plugin fails with canadian compilation

[unlvsur at live dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106170

Bug ID: 106170
   Summary: win32 thread model does not pthread.h. lto-plugin
fails with canadian compilation
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

make[4]: Entering directory
'/home/cqwrteur/toolchains_build/gcc_build/x86_64-w64-mingw32/x86_64-w64-mingw32/gcc/gmp/demos'
Making all in calc
../../../../../gcc/lto-plugin/lto-plugin.c:62:10: fatal error: pthread.h: No
such file or directory
   62 | #include 
  |  ^~~

win32 thread model's gcc does not have pthread.h

[Bug fortran/105473] semicolon allowed when list-directed read integer with decimal='point'

[harper at msor dot vuw.ac.nz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473

--- Comment #25 from harper at msor dot vuw.ac.nz ---
I received your patch but I have no idea how to install it - I have been 
using Fortran off and on since 1963 but I am not a systems programmer.
My version of gfortran is

gcc version 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.04.1)

On Sat, 2 Jul 2022, jvdelisle at gcc dot gnu.org wrote:

> Date: Sat, 2 Jul 2022 17:14:05 +
> From: jvdelisle at gcc dot gnu.org 
> To: John Harper 
> Subject: [Bug fortran/105473] semicolon allowed when list-directed read
> integer with decimal='point'
> Resent-Date: Sun, 3 Jul 2022 05:14:17 +1200 (NZST)
> Resent-From: 
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473
>
> Jerry DeLisle  changed:
>
>   What|Removed |Added
> 
>  Attachment #52981|0   |1
>is obsolete||
>
> --- Comment #24 from Jerry DeLisle  ---
> Created attachment 53241
>  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53241=edit
> Revised patch that may be as good as it gets.
>
> I have not had time to commit this, but this would be it.  If you can test it
> and point out any issues it is appreciated.
>
> -- 
> You are receiving this mail because:
> You reported the bug.
>


-- John Harper, School of Mathematics and Statistics
Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand.
e-mail john.har...@vuw.ac.nz phone +64(0) 4 463 5276

[Bug gcov-profile/106090] [GCOV] Wrong coverage for loop statements

[njuwy at smail dot nju.edu.cn via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106090

--- Comment #3 from Yang Wang  ---
(In reply to Yang Wang from comment #2)
> (In reply to Martin Liška from comment #1)
> > No, it's correct as it only contains do_it() call that is triggered the same
> > number times as line 20 minus one.
> 
> (In reply to Martin Liška from comment #1)
> > No, it's correct as it only contains do_it() call that is triggered the same
> > number times as line 20 minus one.
> 
> -:0:Source:test.c
> -:0:Graph:test.gcno
> -:0:Data:test.gcda
> -:0:Runs:1
> -:1:volatile int cnt = 0;
> -:2:
> -:3:__attribute__((noinline, noclone)) static int
> 5:4:last (void)
> -:5:{
> 5:6:  return ++cnt % 5 == 0;
> -:7:}
> -:8:
> -:9:__attribute__((noinline, noclone)) static void
> 6:   10:do_it (void)
> -:   11:{
> 6:   12:  asm volatile ("" : : "r" () : "memory");
> 6:   13:}
> -:   14:
> 1:   15:static void f1 (void)
> -:   16:{
> 1:   17:  do_it();
> 4:   18:  for (; 0<1; do_it())
> -:   19:{
> 5:   20:  if (last ())
> 1:   21:  break;
> -:   22:}
> 1:   23:  do_it ();
> 1:   24:}
> -:   25:
> -:   26:int
> 1:   27:main ()
> -:   28:{
> 1:   29:  f1 ();
> -:   30:}
> 
> do_it() is indeed called 4 times,but I wonder how the coverage statistiscs
> of the for-statement is calculated. It doesn't become 5 untill the
> for-stamentment is completed.
> -:0:Source:test.c
> -:0:Graph:test.gcno
> -:0:Data:test.gcda
> -:0:Runs:1
> -:1:volatile int cnt = 0;
> -:2:
> -:3:__attribute__((noinline, noclone)) static int
> 5:4:last (void)
> -:5:{
> 5:6:  return ++cnt % 5 == 0;
> -:7:}
> -:8:
> -:9:__attribute__((noinline, noclone)) static void
> 6:   10:do_it (void)
> -:   11:{
> 6:   12:  asm volatile ("" : : "r" () : "memory");
> 6:   13:}
> -:   14:
> 1:   15:static void f1 (void)
> -:   16:{
> 1:   17:  do_it();
> 5:   18:  for (int a=0;0<1;do_it())
> -:   19:{
> 5:   20:  if (last ())
> 1:   21:  break;
> -:   22:}
> 1:   23:  do_it ();
> 1:   24:}
> -:   25:
> -:   26:int
> 1:   27:main ()
> -:   28:{
> 1:   29:  f1 ();
> -:   30:}

Besides, GCov doesn't seem to provide voerage statistics for "for(;;)" .
-:0:Source:test.c
-:0:Graph:test.gcno
-:0:Data:test.gcda
-:0:Runs:1
-:1:volatile int cnt = 0;
-:2:
-:3:__attribute__((noinline, noclone)) static int
5:4:last (void)
-:5:{
5:6:  return ++cnt % 5 == 0;
-:7:}
-:8:
-:9:__attribute__((noinline, noclone)) static void
6:   10:do_it (void)
-:   11:{
6:   12:  asm volatile ("" : : "r" () : "memory");
6:   13:}
-:   14:
1:   15:static void f1 (void)
-:   16:{
1:   17:  do_it();
-:   18:  for (; ; )
-:   19:{
5:   20:  if (last ())
1:   21:break;
4:   22: do_it();
-:   23:}
1:   24:  do_it ();
1:   25:}
-:   26:
-:   27:int
1:   28:main ()
-:   29:{
1:   30:  f1 ();
-:   31:}

[Bug gcov-profile/106090] [GCOV] Wrong coverage for loop statements

[njuwy at smail dot nju.edu.cn via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106090

--- Comment #2 from Yang Wang  ---
(In reply to Martin Liška from comment #1)
> No, it's correct as it only contains do_it() call that is triggered the same
> number times as line 20 minus one.

(In reply to Martin Liška from comment #1)
> No, it's correct as it only contains do_it() call that is triggered the same
> number times as line 20 minus one.

-:0:Source:test.c
-:0:Graph:test.gcno
-:0:Data:test.gcda
-:0:Runs:1
-:1:volatile int cnt = 0;
-:2:
-:3:__attribute__((noinline, noclone)) static int
5:4:last (void)
-:5:{
5:6:  return ++cnt % 5 == 0;
-:7:}
-:8:
-:9:__attribute__((noinline, noclone)) static void
6:   10:do_it (void)
-:   11:{
6:   12:  asm volatile ("" : : "r" () : "memory");
6:   13:}
-:   14:
1:   15:static void f1 (void)
-:   16:{
1:   17:  do_it();
4:   18:  for (; 0<1; do_it())
-:   19:{
5:   20:  if (last ())
1:   21:break;
-:   22:}
1:   23:  do_it ();
1:   24:}
-:   25:
-:   26:int
1:   27:main ()
-:   28:{
1:   29:  f1 ();
-:   30:}

do_it() is indeed called 4 times,but I wonder how the coverage statistiscs of
the for-statement is calculated. It doesn't become 5 untill the for-stamentment
is completed.
-:0:Source:test.c
-:0:Graph:test.gcno
-:0:Data:test.gcda
-:0:Runs:1
-:1:volatile int cnt = 0;
-:2:
-:3:__attribute__((noinline, noclone)) static int
5:4:last (void)
-:5:{
5:6:  return ++cnt % 5 == 0;
-:7:}
-:8:
-:9:__attribute__((noinline, noclone)) static void
6:   10:do_it (void)
-:   11:{
6:   12:  asm volatile ("" : : "r" () : "memory");
6:   13:}
-:   14:
1:   15:static void f1 (void)
-:   16:{
1:   17:  do_it();
5:   18:  for (int a=0;0<1;do_it())
-:   19:{
5:   20:  if (last ())
1:   21:break;
-:   22:}
1:   23:  do_it ();
1:   24:}
-:   25:
-:   26:int
1:   27:main ()
-:   28:{
1:   29:  f1 ();
-:   30:}

Re: [PATCH] loongarch: use -mno-check-zero-division as the default for optimized code

[Xi Ruoyao via Gcc-patches]

On Sat, 2022-07-02 at 16:35 +0800, Lulu Cheng wrote:
> 在 2022/7/2 下午4:24, Xi Ruoyao 写道:
> > 
> > I'll commit the patch with the hook removed after another regtest on
> > loongarch64-linux-gnu.  I just rebuilt the entire system on my
> > 3A5000,
> > so I need some time to set it up.  Expectation time to commit is
> > today
> > evening or tomorrow morning.
> > 
> > BTW I've included this patch building my system, no bad things has
> > happened so far.
> Ok,Thanks!:-)

Pushed as r13-1410.

How do you think about the suggestion from Richard about a backport into
gcc-12 branch?  Normally we don't backport behavior changes, but making
12.1 the only exception seems compelling.

Re: analyzer: implement five new warnings for misuse of POSIX

[Jay K via Gcc]

 > check for double "close" of a FD (CWE-1341).
 > check for read/write of a closed file descriptor 
 
 These sound good but kinda non general or incomplete to me. 
 I mean, isn't the "right" thing, to disallow passing 
 a closed fd to "almost any" function?  

 But I realize "almost any" is difficult to pin down. 
  fd = open(); 
  close(fd); 
  printf("%d", fd);  

is often ok (assuming nobody reads the output, string to int,
back to close/read/write). It is any path leading to,
a long list, like close, read, write, ioctl, send, recv, etc.
and I don't know if "path leading to" is possible to model here, haven't 
looked, sorry.

 - Jay

Re: [PATCH] analyzer: Use fixed-width types in allocation size tests

[David Malcolm via Gcc-patches]

On Sun, 2022-07-03 at 01:20 +0200, Tim Lange wrote:
> Hi,
> 
> thanks for the mail! Embarrassingly, I did not account for the
> different
> sizes types may have on different systems. I've switched all
> testcases
> to the fixed-width types of stdint.h. 
> 
> Does this patch need an approval?

Arguably falls under the "obvious" rule.

That said, the patch looks good to me, though given that the sizes are
now fixed the \\d+ regexps could be made more precise, if you like; I
think it's good either way.

Dave

> 
> - Tim
> 
> The patch changes the types inside the tests for the allocation size
> checker to fixed-width types of stdint.h to account for different
> architectures with different type widths.
> 
> 2022-07-03  Tim Lange  
> 
> gcc/testsuite/ChangeLog:
> 
> * gcc.dg/analyzer/allocation-size-1.c: Use fixed-length
> types.
> * gcc.dg/analyzer/allocation-size-2.c: Likewise.
> * gcc.dg/analyzer/allocation-size-3.c: Likewise.
> * gcc.dg/analyzer/allocation-size-4.c: Likewise.
> * gcc.dg/analyzer/allocation-size-5.c: Likewise.
> 
> ---
>  .../gcc.dg/analyzer/allocation-size-1.c   | 53 +++---
>  .../gcc.dg/analyzer/allocation-size-2.c   | 73 ++---
> --
>  .../gcc.dg/analyzer/allocation-size-3.c   | 19 ++---
>  .../gcc.dg/analyzer/allocation-size-4.c   | 13 ++--
>  .../gcc.dg/analyzer/allocation-size-5.c   | 23 +++---
>  5 files changed, 93 insertions(+), 88 deletions(-)
> 
> diff --git a/gcc/testsuite/gcc.dg/analyzer/allocation-size-1.c
> b/gcc/testsuite/gcc.dg/analyzer/allocation-size-1.c
> index 4fc2bf75d6c..e6d021a128f 100644
> --- a/gcc/testsuite/gcc.dg/analyzer/allocation-size-1.c
> +++ b/gcc/testsuite/gcc.dg/analyzer/allocation-size-1.c
> @@ -1,79 +1,80 @@
>  #include 
>  #include 
> +#include 
>  
>  /* Tests with constant buffer sizes.  */
>  
>  void test_1 (void)
>  {
> -  short *ptr = malloc (21 * sizeof (short));
> +  int16_t *ptr = malloc (21 * sizeof (int16_t));
>    free (ptr);
>  }
>  
>  void test_2 (void)
>  {
> -  int *ptr = malloc (21 * sizeof (short)); /* { dg-line malloc2 } */
> +  int32_t *ptr = malloc (21 * sizeof (int16_t)); /* { dg-line
> malloc2 } */
>    free (ptr);
>  
>    /* { dg-warning "allocated buffer size is not a multiple of the
> pointee's size \\\[CWE-131\\\]" "warning" { target *-*-* } malloc2 }
> */
>    /* { dg-message "\\d+ bytes" "note" { target *-*-* } malloc2 } */
> -  /* { dg-message "'int \\*' here; 'sizeof \\(int\\)' is '\\d+'"
> "note" { target *-*-* } malloc2 } */
> +  /* { dg-message "'int32_t \\*' (\\\{aka 'int \\*'\\\})? here;
> 'sizeof \\(int32_t (\\\{aka int\\\})\\)' is '\\d+'" "note" { target
> *-*-* } malloc2 } */
>  }
>  
>  void test_3 (void)
>  {
> -  void *ptr = malloc (21 * sizeof (short));
> -  short *sptr = (short *)ptr;
> +  void *ptr = malloc (21 * sizeof (int16_t));
> +  int16_t *sptr = (int16_t *)ptr;
>    free (sptr);
>  }
>  
>  void test_4 (void)
>  {
> -  void *ptr = malloc (21 * sizeof (short)); /* { dg-message "\\d+
> bytes" } */
> -  int *iptr = (int *)ptr; /* { dg-line assign4 } */
> +  void *ptr = malloc (21 * sizeof (int16_t)); /* { dg-message "\\d+
> bytes" } */
> +  int32_t *iptr = (int32_t *)ptr; /* { dg-line assign4 } */
>    free (iptr);
>  
>    /* { dg-warning "allocated buffer size is not a multiple of the
> pointee's size \\\[CWE-131\\\]" "warning" { target *-*-* } assign4 }
> */
> -  /* { dg-message "'int \\*' here; 'sizeof \\(int\\)' is '\\d+'"
> "note" { target *-*-* } assign4 } */
> +  /* { dg-message "'int32_t \\*' (\\\{aka 'int \\*'\\\})? here;
> 'sizeof \\(int32_t (\\\{aka int\\\})\\)' is '\\d+'" "note" { target
> *-*-* } assign4 } */
>  }
>  
>  void test_5 (void)
>  {
> -  int user_input;
> +  int32_t user_input;
>    scanf("%i", _input);
> -  int n;
> +  int32_t n;
>    if (user_input == 0)
> -    n = 21 * sizeof (short);
> +    n = 21 * sizeof (int16_t);
>    else
> -    n = 42 * sizeof (short);
> +    n = 42 * sizeof (int16_t);
>    void *ptr = malloc (n);
> -  short *sptr = (short *)ptr;
> +  int16_t *sptr = (int16_t *)ptr;
>    free (sptr);
>  }
>  
>  void test_6 (void)
>  {
> -  int user_input;
> +  int32_t user_input;
>    scanf("%i", _input);
> -  int n;
> +  int32_t n;
>    if (user_input == 0)
> -    n = 21 * sizeof (short);
> +    n = 21 * sizeof (int16_t);
>    else
> -    n = 42 * sizeof (short);
> +    n = 42 * sizeof (int16_t);
>    void *ptr = malloc (n); /* { dg-message "" "note" } */
>    /* ^^^ on widening_svalues no expr is
> returned
>   by get_representative_tree at the
> moment.  */ 
> -  int *iptr = (int *)ptr; /* { dg-line assign6 } */
> +  int32_t *iptr = (int32_t *)ptr; /* { dg-line assign6 } */
>    free (iptr);
>  
>    /* { dg-warning "allocated buffer size is not a multiple of the
> pointee's size \\\[CWE-131\\\]" "warning" { target *-*-* } assign6 }
> */
> -  /* { dg-message "'int \\*' here; 'sizeof \\(int\\)' is '\\d+'"
> "note" { target *-*-* } 

[PATCH] analyzer: Use fixed-width types in allocation size tests

[Tim Lange]

Hi,

thanks for the mail! Embarrassingly, I did not account for the different
sizes types may have on different systems. I've switched all testcases
to the fixed-width types of stdint.h. 

Does this patch need an approval?

- Tim

The patch changes the types inside the tests for the allocation size
checker to fixed-width types of stdint.h to account for different
architectures with different type widths.

2022-07-03  Tim Lange  

gcc/testsuite/ChangeLog:

* gcc.dg/analyzer/allocation-size-1.c: Use fixed-length types.
* gcc.dg/analyzer/allocation-size-2.c: Likewise.
* gcc.dg/analyzer/allocation-size-3.c: Likewise.
* gcc.dg/analyzer/allocation-size-4.c: Likewise.
* gcc.dg/analyzer/allocation-size-5.c: Likewise.

---
 .../gcc.dg/analyzer/allocation-size-1.c   | 53 +++---
 .../gcc.dg/analyzer/allocation-size-2.c   | 73 ++-
 .../gcc.dg/analyzer/allocation-size-3.c   | 19 ++---
 .../gcc.dg/analyzer/allocation-size-4.c   | 13 ++--
 .../gcc.dg/analyzer/allocation-size-5.c   | 23 +++---
 5 files changed, 93 insertions(+), 88 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/analyzer/allocation-size-1.c 
b/gcc/testsuite/gcc.dg/analyzer/allocation-size-1.c
index 4fc2bf75d6c..e6d021a128f 100644
--- a/gcc/testsuite/gcc.dg/analyzer/allocation-size-1.c
+++ b/gcc/testsuite/gcc.dg/analyzer/allocation-size-1.c
@@ -1,79 +1,80 @@
 #include 
 #include 
+#include 
 
 /* Tests with constant buffer sizes.  */
 
 void test_1 (void)
 {
-  short *ptr = malloc (21 * sizeof (short));
+  int16_t *ptr = malloc (21 * sizeof (int16_t));
   free (ptr);
 }
 
 void test_2 (void)
 {
-  int *ptr = malloc (21 * sizeof (short)); /* { dg-line malloc2 } */
+  int32_t *ptr = malloc (21 * sizeof (int16_t)); /* { dg-line malloc2 } */
   free (ptr);
 
   /* { dg-warning "allocated buffer size is not a multiple of the pointee's 
size \\\[CWE-131\\\]" "warning" { target *-*-* } malloc2 } */
   /* { dg-message "\\d+ bytes" "note" { target *-*-* } malloc2 } */
-  /* { dg-message "'int \\*' here; 'sizeof \\(int\\)' is '\\d+'" "note" { 
target *-*-* } malloc2 } */
+  /* { dg-message "'int32_t \\*' (\\\{aka 'int \\*'\\\})? here; 'sizeof 
\\(int32_t (\\\{aka int\\\})\\)' is '\\d+'" "note" { target *-*-* } malloc2 } */
 }
 
 void test_3 (void)
 {
-  void *ptr = malloc (21 * sizeof (short));
-  short *sptr = (short *)ptr;
+  void *ptr = malloc (21 * sizeof (int16_t));
+  int16_t *sptr = (int16_t *)ptr;
   free (sptr);
 }
 
 void test_4 (void)
 {
-  void *ptr = malloc (21 * sizeof (short)); /* { dg-message "\\d+ bytes" } */
-  int *iptr = (int *)ptr; /* { dg-line assign4 } */
+  void *ptr = malloc (21 * sizeof (int16_t)); /* { dg-message "\\d+ bytes" } */
+  int32_t *iptr = (int32_t *)ptr; /* { dg-line assign4 } */
   free (iptr);
 
   /* { dg-warning "allocated buffer size is not a multiple of the pointee's 
size \\\[CWE-131\\\]" "warning" { target *-*-* } assign4 } */
-  /* { dg-message "'int \\*' here; 'sizeof \\(int\\)' is '\\d+'" "note" { 
target *-*-* } assign4 } */
+  /* { dg-message "'int32_t \\*' (\\\{aka 'int \\*'\\\})? here; 'sizeof 
\\(int32_t (\\\{aka int\\\})\\)' is '\\d+'" "note" { target *-*-* } assign4 } */
 }
 
 void test_5 (void)
 {
-  int user_input;
+  int32_t user_input;
   scanf("%i", _input);
-  int n;
+  int32_t n;
   if (user_input == 0)
-n = 21 * sizeof (short);
+n = 21 * sizeof (int16_t);
   else
-n = 42 * sizeof (short);
+n = 42 * sizeof (int16_t);
   void *ptr = malloc (n);
-  short *sptr = (short *)ptr;
+  int16_t *sptr = (int16_t *)ptr;
   free (sptr);
 }
 
 void test_6 (void)
 {
-  int user_input;
+  int32_t user_input;
   scanf("%i", _input);
-  int n;
+  int32_t n;
   if (user_input == 0)
-n = 21 * sizeof (short);
+n = 21 * sizeof (int16_t);
   else
-n = 42 * sizeof (short);
+n = 42 * sizeof (int16_t);
   void *ptr = malloc (n); /* { dg-message "" "note" } */
   /* ^^^ on widening_svalues no expr is returned
  by get_representative_tree at the moment.  */ 
-  int *iptr = (int *)ptr; /* { dg-line assign6 } */
+  int32_t *iptr = (int32_t *)ptr; /* { dg-line assign6 } */
   free (iptr);
 
   /* { dg-warning "allocated buffer size is not a multiple of the pointee's 
size \\\[CWE-131\\\]" "warning" { target *-*-* } assign6 } */
-  /* { dg-message "'int \\*' here; 'sizeof \\(int\\)' is '\\d+'" "note" { 
target *-*-* } assign6 } */
+  /* { dg-message "'int32_t \\*' (\\\{aka 'int \\*'\\\})? here; 'sizeof 
\\(int32_t (\\\{aka int\\\})\\)' is '\\d+'" "note" { target *-*-* } assign6 } */
 }
 
 void test_7 (void)
 {
-  int user_input;
+  int32_t user_input;
   scanf("%i", _input);
-  int n;
+  int32_t n;
   if (user_input == 0)
 n = 1;
   else if (user_input == 2)
@@ -82,18 +83,18 @@ void test_7 (void)
 n = 7;
   /* n is an unknown_svalue at this point.  */
   void *ptr = malloc (n);
-  int *iptr = (int *)ptr;
+  int32_t *iptr = (int32_t *)ptr;
   free (iptr);
 }
 

gcc-12-20220702 is now available

[GCC Administrator via Gcc]

Snapshot gcc-12-20220702 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/12-20220702/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 12 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch 
releases/gcc-12 revision ad5d760b815b3d491bdb5d97f6e053d60d6991b9

You'll find:

 gcc-12-20220702.tar.xz   Complete GCC

  SHA256=5c73f3961cafdcf6c1969976793c9191f10e96ca694c7dc647ff22ba55b03775
  SHA1=384234a12b1786b1f17da9e4d0fa063e48454683

Diffs from 12-20220625 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-12
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

[r13-1405 Regression] FAIL: gcc.dg/analyzer/allocation-size-4.c warning at line 31 (test for warnings, line 28) on Linux/x86_64

[skpandey--- via Gcc-patches]

On Linux/x86_64,

e6c3bb379f515b27268d08e62b4b3e5d7200b437 is the first bad commit
commit e6c3bb379f515b27268d08e62b4b3e5d7200b437
Author: Tim Lange 
Date:   Fri Jul 1 00:02:17 2022 +0200

analyzer: add allocation size checker [PR105900]

caused

FAIL: gcc.dg/analyzer/allocation-size-4.c note at line 32 (test for warnings, 
line 28)
FAIL: gcc.dg/analyzer/allocation-size-4.c note at line 33 (test for warnings, 
line 28)
FAIL: gcc.dg/analyzer/allocation-size-4.c warning at line 31 (test for 
warnings, line 28)

with GCC configured with

../../gcc/configure 
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r13-1405/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="analyzer.exp=gcc.dg/analyzer/allocation-size-4.c 
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="analyzer.exp=gcc.dg/analyzer/allocation-size-4.c 
--target_board='unix{-m32\ -march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at skpgkp2 at gmail dot com)

[Bug analyzer/105898] RFE: -fanalyzer should complain about overlapping args to memcpy and mempcpy

[tlange at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105898

Tim Lange  changed:

   What|Removed |Added

 CC||tlange at gcc dot gnu.org

--- Comment #2 from Tim Lange  ---
(In reply to Eric Gallager from comment #1)
> Doesn't -Wrestrict already kinda do this?

Partly. -Wrestrict only warns when you actually use the same variable, e.g.
memcpy (buf, buf, 4).

Doing that in the analyzer could also warn on cases like:
- memcpy (buf, alias_to_buf, 4)
- memcpy (buf, buf + 2, 4)

[Bug fortran/106089] false positives with -Wuninitialized for allocation on assignment

[kargl at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106089

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||kargl at gcc dot gnu.org
   Last reconfirmed||2022-07-02
 Ever confirmed|0   |1
   Priority|P3  |P4
   Keywords|diagnostic  |

--- Comment #3 from kargl at gcc dot gnu.org ---
Removed 'diagnostic' keyword.  This is much worse than just a bad diagnostic.

Consider a much shorter testcase.

program foo
   integer, allocatable :: i(:)
   i = [1,1]
   if (any(i /= 1)) stop
end program foo

% gfortran11 -Wall -c a.f90 |& grep -i warn
Warning: 'i.offset' is used uninitialized [-Wuninitialized]
Warning: 'i.dim[0].lbound' is used uninitialized [-Wuninitialized]
Warning: 'i.dim[0].ubound' is used uninitialized [-Wuninitialized]
Warning: 'i.dim[0].lbound' may be used uninitialized [-Wmaybe-uninitialized]
Warning: 'i.dim[0].ubound' may be used uninitialized [-Wmaybe-uninitialized]
Warning: 'i.dim[0].ubound' may be used uninitialized [-Wmaybe-uninitialized]
Warning: 'i.dim[0].lbound' may be used uninitialized [-Wmaybe-uninitialized]

With the patch that follows, I get

% gfcx -Wall -c a.f90 |& grep -i warn
Warning: 'i.offset' is used uninitialized [-Wuninitialized]
Warning: 'i.dim[0].lbound' is used uninitialized [-Wuninitialized]
Warning: 'i.dim[0].ubound' is used uninitialized [-Wuninitialized]

so 4 of the rogue warnings are no longer issued.

diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc
index 05134952db4..793e6a21e6d 100644
--- a/gcc/fortran/trans-array.cc
+++ b/gcc/fortran/trans-array.cc
@@ -10734,27 +10734,27 @@ gfc_alloc_allocatable_for_assignment (gfc_loopinfo
*loop,

   /* If the lhs shape is not the same as the rhs jump to setting the
  bounds and doing the reallocation...  */
-  for (n = 0; n < expr1->rank; n++)
+  if (expr1->shape)
 {
-  /* Check the shape.  */
-  lbound = gfc_conv_descriptor_lbound_get (desc, gfc_rank_cst[n]);
-  ubound = gfc_conv_descriptor_ubound_get (desc, gfc_rank_cst[n]);
-  tmp = fold_build2_loc (input_location, MINUS_EXPR,
-gfc_array_index_type,
-loop->to[n], loop->from[n]);
-  tmp = fold_build2_loc (input_location, PLUS_EXPR,
-gfc_array_index_type,
-tmp, lbound);
-  tmp = fold_build2_loc (input_location, MINUS_EXPR,
-gfc_array_index_type,
-tmp, ubound);
-  cond = fold_build2_loc (input_location, NE_EXPR,
- logical_type_node,
- tmp, gfc_index_zero_node);
-  tmp = build3_v (COND_EXPR, cond,
- build1_v (GOTO_EXPR, jump_label1),
- build_empty_stmt (input_location));
-  gfc_add_expr_to_block (, tmp);
+  for (n = 0; n < expr1->rank; n++)
+   {
+ /* Check the shape.  */
+ lbound = gfc_conv_descriptor_lbound_get (desc, gfc_rank_cst[n]);
+ ubound = gfc_conv_descriptor_ubound_get (desc, gfc_rank_cst[n]);
+ tmp = fold_build2_loc (input_location, MINUS_EXPR,
+gfc_array_index_type,
+loop->to[n], loop->from[n]);
+ tmp = fold_build2_loc (input_location, PLUS_EXPR,
+gfc_array_index_type, tmp, lbound);
+ tmp = fold_build2_loc (input_location, MINUS_EXPR,
+gfc_array_index_type, tmp, ubound);
+ cond = fold_build2_loc (input_location, NE_EXPR,
+ logical_type_node, tmp, gfc_index_zero_node);
+ tmp = build3_v (COND_EXPR, cond,
+ build1_v (GOTO_EXPR, jump_label1),
+ build_empty_stmt (input_location));
+ gfc_add_expr_to_block (, tmp);
+   }
 }

   /* ...else if the element lengths are not the same also go to


So, what's the problem.  The scalarizer is broken, which was
originally written before (re)allocation of the LHS was introduced
to Fortran.  The above is not valid Fortran 95.  The LHS and RHS
of the assignment must be conformable.  This means that, if an
error had not been emitted, then the LHS and RHS have the same
array descriptor.  This leads to two problems.  The first is 
the scalarizer appears to write the descriptors into the intermediate
representation (IR).

% gfortran11 -Wall -c a.f90 -fdump-tree-original
% more a.f90.005t.original  (NOte inline annotations)
void foo ()
{
  struct array01_integer(kind=4) i;

  i.data = 0B;
  i.dtype = {.elem_len=4, .rank=1, .type=1};
  {

*** This is the descriptor for the RHS
integer(kind=4)[0:] * 

[PATCH] MAINTAINERS: Add myself to write after approval and DCO

[Tim Lange]

Hi everyone,

I've added myself to write after approval and DCO section.

- Tim

2022-07-02  Tim Lange  

ChangeLog:

* MAINTAINERS: Add myself.
---
 MAINTAINERS | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 3c448ba9eb6..17bebefa2db 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -495,6 +495,7 @@ Razya Ladelsky  

 Thierry Lafage 
 Rask Ingemann Lambertsen   
 Jerome Lambourg
+Tim Lange  
 Asher Langton  
 Chris Lattner  
 Terry Laurenzo 
@@ -716,6 +717,7 @@ information.
 
 
 Matthias Kretz 
+Tim Lange  
 Jeff Law   
 Jeff Law   
 Gaius Mulley   
-- 
2.36.1

[Bug fortran/106065] Crash when reading extended derived type array in namelist

[jvdelisle at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106065

--- Comment #2 from Jerry DeLisle  ---
I was a bit curious to see what flang would do with the test case.  It gives
the exact same error message as gfortran, word for word.

Re: [PATCH take 2] middle-end: Support ABIs that pass FP values as wider integers.

[Jeff Law via Gcc-patches]

On 6/26/2022 6:55 AM, Roger Sayle wrote:

Hi Jeff,
Sorry for the long delay getting back to this, but after deeper
investigation, it turns out that your tingling spider senses that
the original patch wasn't updating everywhere that was required
were spot on.  Although my nvptx testing showed no problems with -O2,
compiling the same tests with -O0 found several additional assertion
ICEs (exactly where you'd predicted they should/would be).

Here's a revised patch that updates five locations (up from the
previous two).  Finding any remaining locations (if any) might be
easier once folks are able to test things on their targets.


This patch has been tested on x86_64-pc-linux-gnu with make bootstrap
and make -k check with no new failures, and on nvptx-none, where it is
the middle-end portion of a pair of patches to allow the default ISA to
be advanced.  Ok for mainline?


2022-06-26  Roger Sayle  

gcc/ChangeLog
PR target/104489
* calls.cc (precompute_register_parameters): Allow promotion
of floating point values to be passed in wider integer modes.
(expand_call): Allow floating point results to be returned in
wider integer modes.
* cfgexpand.cc (expand_value_return): Allow backends to promote
a scalar floating point return value to a wider integer mode.
* expr.cc (expand_expr_real_1) : Likewise, allow
backends to promote scalar FP PARM_DECLs to wider integer modes.
* function.cc (assign_parm_setup_stack): Allow floating point
values to be passed on the stack as wider integer modes.
OK.  Though please consider factoring the code which reinterprets the 
original into a new mode.  It looks to me like we've got 5 copies of it 
now :-)




Jeff

[Bug fortran/105473] semicolon allowed when list-directed read integer with decimal='point'

[jvdelisle at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473

Jerry DeLisle  changed:

   What|Removed |Added

  Attachment #52981|0   |1
is obsolete||

--- Comment #24 from Jerry DeLisle  ---
Created attachment 53241
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53241=edit
Revised patch that may be as good as it gets.

I have not had time to commit this, but this would be it.  If you can test it
and point out any issues it is appreciated.

[Bug analyzer/105887] [meta-bug] clang analyzer warnings that GCC's -fanalyzer could implement

[tlange at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105887
Bug 105887 depends on bug 105900, which changed state.

Bug 105900 Summary: RFE: -fanalyzer could check malloc sizes when casting the 
result to a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105900

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

[Bug analyzer/105900] RFE: -fanalyzer could check malloc sizes when casting the result to a pointer

[tlange at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105900

Tim Lange  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #5 from Tim Lange  ---
Committed my patch to master.

[Bug analyzer/105900] RFE: -fanalyzer could check malloc sizes when casting the result to a pointer

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105900

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Tim Lange :

https://gcc.gnu.org/g:e6c3bb379f515b27268d08e62b4b3e5d7200b437

commit r13-1405-ge6c3bb379f515b27268d08e62b4b3e5d7200b437
Author: Tim Lange 
Date:   Fri Jul 1 00:02:17 2022 +0200

analyzer: add allocation size checker [PR105900]

This patch adds an checker that warns about code paths in which a buffer
is assigned to a incompatible type, i.e. when the allocated buffer size
is not a multiple of the pointee's size.

Regression-tested on x86_64 Linux. Also compiled coreutils, curl, openssh
and
httpd with the patch enabled.

2022-07-01  Tim Lange  

gcc/analyzer/ChangeLog:

PR analyzer/105900
* analyzer.opt: Added Wanalyzer-allocation-size.
* checker-path.cc (region_creation_event::get_desc): Added call to
new
virtual function
pending_diagnostic::describe_region_creation_event.
* checker-path.h: Added region_creation_event::get_desc.
* diagnostic-manager.cc
(diagnostic_manager::add_event_on_final_node):
New function.
* diagnostic-manager.h:
Added diagnostic_manager::add_event_on_final_node.
* pending-diagnostic.h (struct region_creation): New event_desc
struct.
(pending_diagnostic::describe_region_creation_event): Added virtual
function to overwrite description of a region creation.
* region-model.cc (class dubious_allocation_size): New class.
(capacity_compatible_with_type): New helper function.
(class size_visitor): New class.
(struct_or_union_with_inheritance_p): New helper function.
(is_any_cast_p): New helper function.
(region_model::check_region_size): New function.
(region_model::set_value): Added call to
region_model::check_region_size.
* region-model.h (class region_model): New function
check_region_size.
* svalue.cc (region_svalue::accept): Changed to post-order
traversal.
(initial_svalue::accept): Likewise.
(unaryop_svalue::accept): Likewise.
(binop_svalue::accept): Likewise.
(sub_svalue::accept): Likewise.
(repeated_svalue::accept): Likewise.
(bits_within_svalue::accept): Likewise.
(widening_svalue::accept): Likewise.
(unmergeable_svalue::accept): Likewise.
(compound_svalue::accept): Likewise.
(conjured_svalue::accept): Likewise.
(asm_output_svalue::accept): Likewise.
(const_fn_result_svalue::accept): Likewise.

gcc/ChangeLog:

PR analyzer/105900
* doc/invoke.texi: Added Wanalyzer-allocation-size.

gcc/testsuite/ChangeLog:

PR analyzer/105900
* gcc.dg/analyzer/pr96639.c: Changed buffer size to omit warning.
* gcc.dg/analyzer/allocation-size-1.c: New test.
* gcc.dg/analyzer/allocation-size-2.c: New test.
* gcc.dg/analyzer/allocation-size-3.c: New test.
* gcc.dg/analyzer/allocation-size-4.c: New test.
* gcc.dg/analyzer/allocation-size-5.c: New test.

Signed-off-by: Tim Lange 

[Bug analyzer/106003] RFE: -fanalyzer could complain about misuse of file-descriptors

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106003

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Immad Mir :

https://gcc.gnu.org/g:97baacba963c06e3d0e33cde04e7e687671e60e7

commit r13-1404-g97baacba963c06e3d0e33cde04e7e687671e60e7
Author: Immad Mir 
Date:   Sat Jul 2 22:09:37 2022 +0530

analyzer: implement five new warnings for misuse of POSIX file descriptor
APIs [PR106003].

This patch adds a new state machine to the analyzer for checking usage of
POSIX file descriptor
APIs with five new warnings.

It adds:
- check for FD leaks (CWE 775).
- check for double "close" of a FD (CWE-1341).
- check for read/write of a closed file descriptor.
- check whether a file descriptor was used without being checked for
validity.
- check for read/write of a descriptor opened for just writing/reading.

gcc/ChangeLog:
PR analyzer/106003
* Makefile.in (ANALYZER_OBJS): Add sm-fd.o.
* doc/invoke.texi:  Add -Wanalyzer-fd-double-close,
-Wanalyzer-fd-leak,
-Wanalyzer-fd-access-mode-mismatch,
-Wanalyzer-fd-use-without-check,
-Wanalyzer-fd-use-after-close.

gcc/analyzer/ChangeLog:
PR analyzer/106003
* analyzer.opt (Wanalyzer-fd-leak): New option.
(Wanalyzer-fd-access-mode-mismatch): New option.
(Wanalyzer-fd-use-without-check): New option.
(Wanalyzer-fd-double-close): New option.
(Wanalyzer-fd-use-after-close): New option.
* sm.h (make_fd_state_machine): New decl.
* sm.cc (make_checkers): Call make_fd_state_machine.
* sm-fd.cc: New file.

gcc/testsuite/ChangeLog:
PR analyzer/106003
* gcc.dg/analyzer/fd-1.c: New test.
* gcc.dg/analyzer/fd-2.c: New test.
* gcc.dg/analyzer/fd-3.c: New test.
* gcc.dg/analyzer/fd-4.c: New test.

[Bug ada/106037] ICE with Aggregate aspect

[p.p11 at orange dot fr via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106037

Pascal Pignard  changed:

   What|Removed |Added

 CC||p.p11 at orange dot fr

--- Comment #2 from Pascal Pignard  ---
Same error with iterated element association in aggregate:

597.  declare
598. Keys : constant array (Positive range <>) of Integer := [2, 3,
5, 7, 11];
599.  begin
600. 
601. --  A map aggregate where the values produced by the
602. --  iterated_element_association are of the same type as the
key
603. --  (eliminating the need for a separate key_expression):
604. 
605.M := [for Key1 of Keys => Integer'Image (Key1)];

+===GNAT BUG DETECTED==+
| 12.1.0 (x86_64-apple-darwin19.6.0) Program_Error sem_type.adb:837 explicit
raise|
| Error detected at aarm_202x_ch04.adb:605:21

[Bug libcc1/104799] Header issue with x86_64-linux-musl based cross-compiler

[slyfox at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104799

Sergei Trofimovich  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Target Milestone|--- |12.2
 Status|UNCONFIRMED |RESOLVED

--- Comment #4 from Sergei Trofimovich  ---
> libcc1/libcc1plugin.cc

(In reply to Mosè Giordano from comment #2)
> Created attachment 52568 [details]
> Patch for poisoned calloc on Musl systems
> 
> Following the example of
> https://git.alpinelinux.org/aports/tree/main/gcc/0042-Fix-attempt-to-use-
> poisoned-calloc-error-in-libgccji.patch, reported in
> https://bugs.gentoo.org/828580, I wrote the attached patch for libcc1, which
> seems to solve the issue for me.

I think the change looks reasonable. Should be fixed by "c++: avoid 
poisoning on musl [PR106102]" patch from PR106102 in master and gcc-12
branches.

Can you give it a try?

Re: [PATCH] PR 106003

[David Malcolm via Gcc]

On Sat, 2022-07-02 at 19:34 +0530, Mir Immad wrote:
> From 62b7b7736975172f03b30783436fbc9217324223 Mon Sep 17 00:00:00 2001
> From: mir 
> Date: Sat, 2 Jul 2022 15:04:37 +0530
> Subject: [PATCH] analyzer: implement five new warnings for misuse of
> POSIX
>  file descriptor APIs [PR106003].
> 
> This patch adds a new state machine to the analyzer for checking usage
> of
> POSIX file descriptor
> APIs with five new warnings.
> 
> It adds:
> - check for FD leaks (CWE 775).
> - check for double "close" of a FD (CWE-1341).
> - check for read/write of a closed file descriptor.
> - check whether a file descriptor was used without being checked for
> validity.
> - check for read/write of a descriptor opened for just writing/reading.
> 
> gcc/ChangeLog:
> PR analyzer/106003
> * Makefile.in (ANALYZER_OBJS): Add sm-fd.o.
> * doc/invoke.texi:  Add -Wanalyzer-fd-double-close, -Wanalyzer-fd-leak,
> -Wanalyzer-fd-access-mode-mismatch, -Wanalyzer-fd-use-without-check,
> -Wanalyzer-fd-use-after-close.
> 
> gcc/analyzer/ChangeLog:
> PR analyzer/106003
> * analyzer.opt (Wanalyzer-fd-leak): New option.
> (Wanalyzer-fd-access-mode-mismatch): New option.
> (Wanalyzer-fd-use-without-check): New option.
> (Wanalyzer-fd-double-close): New option.
> (Wanalyzer-fd-use-after-close): New option.
> * sm.h (make_fd_state_machine): New decl.
> * sm.cc (make_checkers): Call make_fd_state_machine.
> * sm-fd.cc: New file.
> 
> gcc/testsuite/ChangeLog:
> PR analyzer/106003
> * gcc.dg/analyzer/fd-1.c: New test.
> * gcc.dg/analyzer/fd-2.c: New test.
> * gcc.dg/analyzer/fd-3.c: New test.
> * gcc.dg/analyzer/fd-4.c: New test.

[...snip...]

Hi Immad.

Thanks for the updated patch.

For everyone else, we've been discussing this patch off-list.  We've
had some issues with gmail mangling patches; FWIW a pristine version of
the patch can be seen at:
  https://mirimmad.github.io/patch-02-07.txt

As discussed off-list, you've successfully bootstrapped this patch and
run the testsuite without regressions (and a bunch of extra PASSes), so
this patch is ready for you to push it to the "master" git branch (aka
trunk).  Please go ahead with that (or let me know if you need help
[1]).

Note that Tim's first analyzer patch is also ready to push, so there's
a chance that your patches might conflict with each other (though I
think you're touching different areas of the analyzer, so I'm hoping
that won't happen).

There's plenty of scope for followups, such as adding attributes for
parameters that expect an open file-descriptor, or for handling socket
APIs, etc.  Also, Murphy's Law means that there's sure to be at least
something we missed in review :/

Let's move followup patches to the gcc-patches mailing list, rather
than the "gcc" list.

Thanks
Dave

[1] though I'll only be checking email intermittently this weekend and
on Monday (which is a holiday here in the USA).

[Bug c++/106102] gcc/cp/mapper-resolver.cc fails to build against musl: musl-1.2.3-dev/include/sched.h:84:7: error: attempt to use poisoned "calloc"

[slyfox at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106102

Sergei Trofimovich  changed:

   What|Removed |Added

   Target Milestone|--- |12.2
 Status|UNCONFIRMED |RESOLVED
   Assignee|unassigned at gcc dot gnu.org  |slyfox at gcc dot 
gnu.org
 Resolution|--- |FIXED

--- Comment #10 from Sergei Trofimovich  ---
Pulled fixes as is to gcc-12.

Not going to pull it in to gcc-11 and lower as it depends on larger headers
reshuffle like commit b8f7ff76d6f0b7fdffc314a19425423606b5e296.

[Bug c++/106102] gcc/cp/mapper-resolver.cc fails to build against musl: musl-1.2.3-dev/include/sched.h:84:7: error: attempt to use poisoned "calloc"

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106102

--- Comment #9 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Sergei Trofimovich
:

https://gcc.gnu.org/g:ad5d760b815b3d491bdb5d97f6e053d60d6991b9

commit r12-8540-gad5d760b815b3d491bdb5d97f6e053d60d6991b9
Author: Sergei Trofimovich 
Date:   Mon Jun 27 23:42:44 2022 +0100

jit: avoid calloc() poisoning on musl [PR106102]

On musl  uses calloc() (via ). jit/ includes
it directly and exposes use of poisoned calloc():

/build/build/./prev-gcc/xg++ ...
../../gcc-13-20220626/gcc/jit/jit-playback.cc
make[3]: *** [Makefile:1143: jit/libgccjit.o] Error 1
make[3]: *** Waiting for unfinished jobs
In file included from /<>/musl-1.2.3-dev/include/pthread.h:30,
 from ../../gcc-13-20220626/gcc/jit/jit-playback.cc:44:
/<>/musl-1.2.3-dev/include/sched.h:84:7: error: attempt to use
poisoned "calloc"
   84 | void *calloc(size_t, size_t);
  |   ^
/<>/musl-1.2.3-dev/include/sched.h:124:36: error: attempt to use
poisoned "calloc"
  124 | #define CPU_ALLOC(n) ((cpu_set_t *)calloc(1,CPU_ALLOC_SIZE(n)))
  |^

The change moves  inclusion to "system.h" under new
INCLUDE_PTHREAD_H guard and uses this mechanism in libgccjit.

gcc/

PR c++/106102
* system.h: Introduce INCLUDE_PTHREAD_H macros to include
.

gcc/jit/

PR c++/106102
* jit-playback.cc: Include  via "system.h" to avoid
calloc()
poisoning.
* jit-recording.cc: Ditto.
* libgccjit.cc: Ditto.

(cherry picked from commit 49d508065bdd36fb1a9b6aad9666b1edb5e06474)

[Bug c++/106102] gcc/cp/mapper-resolver.cc fails to build against musl: musl-1.2.3-dev/include/sched.h:84:7: error: attempt to use poisoned "calloc"

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106102

--- Comment #8 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Sergei Trofimovich
:

https://gcc.gnu.org/g:de6f402a54f7e6a3f8a79d723a25724e6274cc3e

commit r12-8539-gde6f402a54f7e6a3f8a79d723a25724e6274cc3e
Author: Sergei Trofimovich 
Date:   Mon Jun 27 13:27:24 2022 +0100

c++: avoid  poisoning on musl [PR106102]

On musl  uses calloc() (via ).  includes
it indirectly and exposes use of poisoned calloc() when module code
is built:

/build/build/./prev-gcc/xg++ ...
../../gcc-13-20220626/gcc/cp/mapper-resolver.cc
In file included from /<>/musl-1.2.3-dev/include/pthread.h:30,
 from
/build/build/prev-x86_64-unknown-linux-musl/libstdc++-v3/include/x86_64-unknown-linux-musl/bits/gthr-default.h:35,
 
 from
/build/build/prev-x86_64-unknown-linux-musl/libstdc++-v3/include/memory:77,
 from ../../gcc-13-20220626/gcc/../libcody/cody.hh:24,
 from
../../gcc-13-20220626/gcc/cp/../../c++tools/resolver.h:25,
 from
../../gcc-13-20220626/gcc/cp/../../c++tools/resolver.cc:23,
 from ../../gcc-13-20220626/gcc/cp/mapper-resolver.cc:32:
/<>/musl-1.2.3-dev/include/sched.h:84:7: error: attempt to use
poisoned "calloc"
   84 | void *calloc(size_t, size_t);
  |   ^
/<>/musl-1.2.3-dev/include/sched.h:124:36: error: attempt to use
poisoned "calloc"
  124 | #define CPU_ALLOC(n) ((cpu_set_t *)calloc(1,CPU_ALLOC_SIZE(n)))
  |^

gcc/cp/

PR c++/106102
* mapper-client.cc: Include  via "system.h".
* mapper-resolver.cc: Ditto.
* module.cc: Ditto.

libcc1/

PR c++/106102
* libcc1plugin.cc: Include  via "system.h".
* libcp1plugin.cc: Ditto.

(cherry picked from commit 3b21c21f3f5726823e19728fdd1571a14aae0fb3)

[Bug ada/106169] New: Error with iterated element association in aggregate.

[p.p11 at orange dot fr via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106169

Bug ID: 106169
   Summary: Error with iterated element association in aggregate.
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: p.p11 at orange dot fr
  Target Milestone: ---

Created attachment 53240
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53240=edit
Full source code

Following the example section of RM Ada 2022 § 4.3.5 Container Aggregate, the
iterated element association aggregate is line 32:

32.M := [for P of Table use P.Key => P.Value.all];

GNAT 12.1.0 issues the following error:
% gcc -c -gnatX 2022/test_20220702_iter_agg.adb
test_20220702_iter_agg.adb:32:39: error: invalid prefix in selected component
"Value"

Re: [PATCH] PR 106003

[Mir Immad via Gcc]

Hi everyone,

This is a patch for PR 106003
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106003; tested on x86_64.

On Sat, Jul 2, 2022 at 7:34 PM Mir Immad  wrote:

> From 62b7b7736975172f03b30783436fbc9217324223 Mon Sep 17 00:00:00 2001
> From: mir 
> Date: Sat, 2 Jul 2022 15:04:37 +0530
> Subject: [PATCH] analyzer: implement five new warnings for misuse of POSIX
>  file descriptor APIs [PR106003].
>
> This patch adds a new state machine to the analyzer for checking usage of
> POSIX file descriptor
> APIs with five new warnings.
>
> It adds:
> - check for FD leaks (CWE 775).
> - check for double "close" of a FD (CWE-1341).
> - check for read/write of a closed file descriptor.
> - check whether a file descriptor was used without being checked for
> validity.
> - check for read/write of a descriptor opened for just writing/reading.
>
> gcc/ChangeLog:
> PR analyzer/106003
> * Makefile.in (ANALYZER_OBJS): Add sm-fd.o.
> * doc/invoke.texi:  Add -Wanalyzer-fd-double-close, -Wanalyzer-fd-leak,
> -Wanalyzer-fd-access-mode-mismatch, -Wanalyzer-fd-use-without-check,
> -Wanalyzer-fd-use-after-close.
>
> gcc/analyzer/ChangeLog:
> PR analyzer/106003
> * analyzer.opt (Wanalyzer-fd-leak): New option.
> (Wanalyzer-fd-access-mode-mismatch): New option.
> (Wanalyzer-fd-use-without-check): New option.
> (Wanalyzer-fd-double-close): New option.
> (Wanalyzer-fd-use-after-close): New option.
> * sm.h (make_fd_state_machine): New decl.
> * sm.cc (make_checkers): Call make_fd_state_machine.
> * sm-fd.cc: New file.
>
> gcc/testsuite/ChangeLog:
> PR analyzer/106003
> * gcc.dg/analyzer/fd-1.c: New test.
> * gcc.dg/analyzer/fd-2.c: New test.
> * gcc.dg/analyzer/fd-3.c: New test.
> * gcc.dg/analyzer/fd-4.c: New test.
> ---
>  gcc/Makefile.in  |   1 +
>  gcc/analyzer/analyzer.opt|  20 +
>  gcc/analyzer/sm-fd.cc| 847 +++
>  gcc/analyzer/sm.cc   |   1 +
>  gcc/analyzer/sm.h|   1 +
>  gcc/doc/invoke.texi  |  55 ++
>  gcc/testsuite/gcc.dg/analyzer/fd-1.c |  39 ++
>  gcc/testsuite/gcc.dg/analyzer/fd-2.c |  49 ++
>  gcc/testsuite/gcc.dg/analyzer/fd-3.c |  85 +++
>  gcc/testsuite/gcc.dg/analyzer/fd-4.c |  62 ++
>  10 files changed, 1160 insertions(+)
>  create mode 100644 gcc/analyzer/sm-fd.cc
>  create mode 100644 gcc/testsuite/gcc.dg/analyzer/fd-1.c
>  create mode 100644 gcc/testsuite/gcc.dg/analyzer/fd-2.c
>  create mode 100644 gcc/testsuite/gcc.dg/analyzer/fd-3.c
>  create mode 100644 gcc/testsuite/gcc.dg/analyzer/fd-4.c
>
> diff --git a/gcc/Makefile.in b/gcc/Makefile.in
> index b6dcc45a58a..04631f737ea 100644
> --- a/gcc/Makefile.in
> +++ b/gcc/Makefile.in
> @@ -1269,6 +1269,7 @@ ANALYZER_OBJS = \
>   analyzer/region-model-reachability.o \
>   analyzer/sm.o \
>   analyzer/sm-file.o \
> + analyzer/sm-fd.o \
>   analyzer/sm-malloc.o \
>   analyzer/sm-pattern-test.o \
>   analyzer/sm-sensitive.o \
> diff --git a/gcc/analyzer/analyzer.opt b/gcc/analyzer/analyzer.opt
> index 23dfc797cea..479990b0e5e 100644
> --- a/gcc/analyzer/analyzer.opt
> +++ b/gcc/analyzer/analyzer.opt
> @@ -66,6 +66,26 @@ Wanalyzer-exposure-through-output-file
>  Common Var(warn_analyzer_exposure_through_output_file) Init(1) Warning
>  Warn about code paths in which sensitive data is written to a file.
>
> +Wanalyzer-fd-access-mode-mismatch
> +Common Var(warn_analyzer_fd_mode_mismatch) Init(1) Warning
> +Warn about code paths in which read on a write-only file descriptor is
> attempted, or vice versa.
> +
> +Wanalyzer-fd-double-close
> +Common Var(warn_analyzer_fd_double_close) Init(1) Warning
> +Warn about code paths in which a file descriptor can be closed more than
> once.
> +
> +Wanalyzer-fd-leak
> +Common Var(warn_analyzer_fd_leak) Init(1) Warning
> +Warn about code paths in which a file descriptor is not closed.
> +
> +Wanalyzer-fd-use-after-close
> +Common Var(warn_analyzer_fd_use_after_close) Init(1) Warning
> +Warn about code paths in which a read or write is performed on a closed
> file descriptor.
> +
> +Wanalyzer-fd-use-without-check
> +Common Var(warn_analyzer_fd_use_without_check) Init(1) Warning
> +Warn about code paths in which a file descriptor is used without being
> checked for validity.
> +
>  Wanalyzer-file-leak
>  Common Var(warn_analyzer_file_leak) Init(1) Warning
>  Warn about code paths in which a stdio FILE is not closed.
> diff --git a/gcc/analyzer/sm-fd.cc b/gcc/analyzer/sm-fd.cc
> new file mode 100644
> index 000..4058ac53308
> --- /dev/null
> +++ b/gcc/analyzer/sm-fd.cc
> @@ -0,0 +1,847 @@
> +/* A state machine for detecting misuses of POSIX file descriptor APIs.
> +   Copyright (C) 2019-2022 Free Software Foundation, Inc.
> +   Contributed by Immad Mir .
> +
> +This file is part of GCC.
> +
> +GCC is free software; you can redistribute it and/or modify it
> +under the terms of the GNU General Public License as published by
> +the Free Software Foundation; either version 3, or (at your option)
> +any later 

[PATCH] PR 106003

[Mir Immad via Gcc]

>From 62b7b7736975172f03b30783436fbc9217324223 Mon Sep 17 00:00:00 2001
From: mir 
Date: Sat, 2 Jul 2022 15:04:37 +0530
Subject: [PATCH] analyzer: implement five new warnings for misuse of POSIX
 file descriptor APIs [PR106003].

This patch adds a new state machine to the analyzer for checking usage of
POSIX file descriptor
APIs with five new warnings.

It adds:
- check for FD leaks (CWE 775).
- check for double "close" of a FD (CWE-1341).
- check for read/write of a closed file descriptor.
- check whether a file descriptor was used without being checked for
validity.
- check for read/write of a descriptor opened for just writing/reading.

gcc/ChangeLog:
PR analyzer/106003
* Makefile.in (ANALYZER_OBJS): Add sm-fd.o.
* doc/invoke.texi:  Add -Wanalyzer-fd-double-close, -Wanalyzer-fd-leak,
-Wanalyzer-fd-access-mode-mismatch, -Wanalyzer-fd-use-without-check,
-Wanalyzer-fd-use-after-close.

gcc/analyzer/ChangeLog:
PR analyzer/106003
* analyzer.opt (Wanalyzer-fd-leak): New option.
(Wanalyzer-fd-access-mode-mismatch): New option.
(Wanalyzer-fd-use-without-check): New option.
(Wanalyzer-fd-double-close): New option.
(Wanalyzer-fd-use-after-close): New option.
* sm.h (make_fd_state_machine): New decl.
* sm.cc (make_checkers): Call make_fd_state_machine.
* sm-fd.cc: New file.

gcc/testsuite/ChangeLog:
PR analyzer/106003
* gcc.dg/analyzer/fd-1.c: New test.
* gcc.dg/analyzer/fd-2.c: New test.
* gcc.dg/analyzer/fd-3.c: New test.
* gcc.dg/analyzer/fd-4.c: New test.
---
 gcc/Makefile.in  |   1 +
 gcc/analyzer/analyzer.opt|  20 +
 gcc/analyzer/sm-fd.cc| 847 +++
 gcc/analyzer/sm.cc   |   1 +
 gcc/analyzer/sm.h|   1 +
 gcc/doc/invoke.texi  |  55 ++
 gcc/testsuite/gcc.dg/analyzer/fd-1.c |  39 ++
 gcc/testsuite/gcc.dg/analyzer/fd-2.c |  49 ++
 gcc/testsuite/gcc.dg/analyzer/fd-3.c |  85 +++
 gcc/testsuite/gcc.dg/analyzer/fd-4.c |  62 ++
 10 files changed, 1160 insertions(+)
 create mode 100644 gcc/analyzer/sm-fd.cc
 create mode 100644 gcc/testsuite/gcc.dg/analyzer/fd-1.c
 create mode 100644 gcc/testsuite/gcc.dg/analyzer/fd-2.c
 create mode 100644 gcc/testsuite/gcc.dg/analyzer/fd-3.c
 create mode 100644 gcc/testsuite/gcc.dg/analyzer/fd-4.c

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index b6dcc45a58a..04631f737ea 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -1269,6 +1269,7 @@ ANALYZER_OBJS = \
  analyzer/region-model-reachability.o \
  analyzer/sm.o \
  analyzer/sm-file.o \
+ analyzer/sm-fd.o \
  analyzer/sm-malloc.o \
  analyzer/sm-pattern-test.o \
  analyzer/sm-sensitive.o \
diff --git a/gcc/analyzer/analyzer.opt b/gcc/analyzer/analyzer.opt
index 23dfc797cea..479990b0e5e 100644
--- a/gcc/analyzer/analyzer.opt
+++ b/gcc/analyzer/analyzer.opt
@@ -66,6 +66,26 @@ Wanalyzer-exposure-through-output-file
 Common Var(warn_analyzer_exposure_through_output_file) Init(1) Warning
 Warn about code paths in which sensitive data is written to a file.

+Wanalyzer-fd-access-mode-mismatch
+Common Var(warn_analyzer_fd_mode_mismatch) Init(1) Warning
+Warn about code paths in which read on a write-only file descriptor is
attempted, or vice versa.
+
+Wanalyzer-fd-double-close
+Common Var(warn_analyzer_fd_double_close) Init(1) Warning
+Warn about code paths in which a file descriptor can be closed more than
once.
+
+Wanalyzer-fd-leak
+Common Var(warn_analyzer_fd_leak) Init(1) Warning
+Warn about code paths in which a file descriptor is not closed.
+
+Wanalyzer-fd-use-after-close
+Common Var(warn_analyzer_fd_use_after_close) Init(1) Warning
+Warn about code paths in which a read or write is performed on a closed
file descriptor.
+
+Wanalyzer-fd-use-without-check
+Common Var(warn_analyzer_fd_use_without_check) Init(1) Warning
+Warn about code paths in which a file descriptor is used without being
checked for validity.
+
 Wanalyzer-file-leak
 Common Var(warn_analyzer_file_leak) Init(1) Warning
 Warn about code paths in which a stdio FILE is not closed.
diff --git a/gcc/analyzer/sm-fd.cc b/gcc/analyzer/sm-fd.cc
new file mode 100644
index 000..4058ac53308
--- /dev/null
+++ b/gcc/analyzer/sm-fd.cc
@@ -0,0 +1,847 @@
+/* A state machine for detecting misuses of POSIX file descriptor APIs.
+   Copyright (C) 2019-2022 Free Software Foundation, Inc.
+   Contributed by Immad Mir .
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify it
+under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 3, or (at your option)
+any later version.
+
+GCC is distributed in the hope that it will be useful, but
+WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3.  If not see
+.  */
+

Re: [RFC] fortran: restore array indexing for all descriptor arrays [PR102043]

[Mikael Morin]

Le 02/07/2022 à 13:18, Thomas Koenig a écrit :
> 
> One thought: If we have to bite the bullet and break the ABI, why not go
> all the way and use the C descriptors in ISO_Fortran_binding.h as
> gfortran's native format?
> 
As far as I know, CFI descriptors are mutually exclusive with
non-negative array indexes.

CFI descriptors' base_addr field points to the first element in
descriptor indexing order, so they can be indexed negatively and we
can’t safely use array indexing with them.

With an additional offset field it would be possible though (with a
different semantics for the base_addr field).  Or we just keep the
different semantics of the base_addr field and assume that there is an
implicit offset with value sum(extent * max(-sm, 0)).

Anyway, this is the long-delayed array descriptor reform, right?  Any
one remembers how far we are from it?

[Bug ada/106168] New: Errors with empty array aggregate.

[p.p11 at orange dot fr via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106168

Bug ID: 106168
   Summary: Errors with empty array aggregate.
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: p.p11 at orange dot fr
  Target Milestone: ---

Created attachment 53239
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53239=edit
Full source code

Following the example section of RM Ada 2022 § 4.3.3 Array Aggregate, the empty
aggregate is line 8:

3.type Real is digits 8;
4.type Matrix is array (Integer range <>, Integer range <>) of Real;
5. 
6.-- AARM (Draft 22) Section_4_3_3_Paragraph_47
7.
8.Empty_Matrix : constant Matrix := []; -- A matrix without elements

GNAT 12.1.0 issues the following errors:
% gcc -c -gnat2022 2022/test_20220702_array_agg.adb
test_20220702_array_agg.adb:8:38: error: value not in range of type
"Standard.Integer"
test_20220702_array_agg.adb:8:38: error: static expression fails
Constraint_Check

Re: [RFC] fortran: restore array indexing for all descriptor arrays [PR102043]

[Thomas Koenig via Gcc-patches]

Hi Mikael,


Feel free to comment, do we need this?


Thanks for taking this on.

One thought: If we have to bite the bullet and break the ABI, why not go
all the way and use the C descriptors in ISO_Fortran_binding.h as
gfortran's native format?

Best regards

Thomas

[Bug target/106167] New: Missed optimization (memory vs register read)

[vluchits at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106167

Bug ID: 106167
   Summary: Missed optimization (memory vs register read)
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vluchits at gmail dot com
  Target Milestone: ---
Target: sh

Created attachment 53238
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53238=edit
Test case

Hello,

in the provided example, this piece of C code:

if (newclipbounds)
{
int newfloorclipx = floorclipx;
int newceilingclipx = ceilingclipx;
uint16_t newclip;

// rewrite clipbounds
if (actionbits & AC_NEWFLOOR)
newfloorclipx = low;
if (actionbits & AC_NEWCEILING)
newceilingclipx = high;

newclip = (newceilingclipx << 8) + newfloorclipx;
clipbounds[x] = newclip;
newclipbounds[x] = newclip;
}

is compiled to the following assembler code:

if (newclipbounds)
 16c:   54 f7   mov.l   @(28,r15),r4
 16e:   24 48   tst r4,r4
 170:   8d 10   bt.s194 <_R_SegLoop+0x194>
 172:   e0 54   mov #84,r0
if (actionbits & AC_NEWFLOOR)
 174:   05 fe   mov.l   @(r0,r15),r5
 176:   25 58   tst r5,r5
 178:   8f 01   bf.s17e <_R_SegLoop+0x17e>
 17a:   e0 58   mov #88,r0
floorclipx = ceilingclipx & 0x00ff;
 17c:   67 a3   mov r10,r7
if (actionbits & AC_NEWCEILING)
 17e:   00 fe   mov.l   @(r0,r15),r0
 180:   20 08   tst r0,r0
 182:   8f 01   bf.s188 <_R_SegLoop+0x188>
 184:   50 fb   mov.l   @(44,r15),r0
int newceilingclipx = ceilingclipx;
 186:   66 93   mov r9,r6
newclip = (newceilingclipx << 8) + newfloorclipx;
 188:   46 18   shll8   r6
 18a:   37 6c   add r6,r7
 18c:   67 7d   extu.w  r7,r7
clipbounds[x] = newclip;
 18e:   08 75   mov.w   r7,@(r0,r8)
newclipbounds[x] = newclip;


The following lines are of particular interest:
if (newclipbounds)
 16c:   54 f7   mov.l   @(28,r15),r4
 16e:   24 48   tst r4,r4
...
newclipbounds[x] = newclip;
 190:   50 f7   mov.l   @(28,r15),r0
 192:   08 75   mov.w   r7,@(r0,r8)

The compiler fails to notice that it's already holding the value of @(28,r15)
in r4 and re-reads the value from stack instead of doing the mov r4,r0.

CFLAGS: -c -std=c11 -g -m2 -mb -Os -fomit-frame-pointer -Wall -Wextra -pedantic
-Wno-unused-parameter -Wimplicit-fallthrough=0 -Wno-missing-field-initializers
-Wnonnull

This may or may not be relevant to bug #106161

[Bug analyzer/106000] RFE: -fanalyzer should complain about memory accesses that are definitely out-of-bounds

[dmalcolm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106000

--- Comment #4 from David Malcolm  ---
For example, the "classic test" referred to in section 1.2 of
  https://open-std.org/JTC1/SC22/WG14/www/docs/n3005.pdf

has:

#include 
#include 
int y=2, x=1;
int main() {
  int *p =  + 1;
  int *q = 
  printf("Addresses: p=%p q=%p\n" ,(void*)p,(void*)q);
  if (memcmp(, , sizeof(p)) == 0) {
*p = 11;   // does  this  have  undefined  behaviour?
printf("x=%d y=%d *p=%d *q=%d\n",x,y,*p,*q);
  }
}

where N3005 notes that "the mere formation of the +1 one-past pointer is
explicitly permitted by the ISO standard".

I think -fanalyzer ought to complain with an definite-out-of-bounds warning at
the *p dereference: assuming sizeof(int) == 4, we'd have a decl_region of size
4, where only bytes 0 to 3 are validly accessible, whereas here the code
attempts to accessing bytes 4-7 of the decl_region for x, which is
out-of-bounds.

(I think the memcpy result would be a conjured_svalue, and hence we would
consider both true and false out-edges after the test; if the user is relying
on the two vars to be next to each other in memory we ought to be warning them
about that)

Re: [PATCH] loongarch: use -mno-check-zero-division as the default for optimized code

[Lulu Cheng]

在 2022/7/2 下午4:24, Xi Ruoyao 写道:

On Sat, 2022-07-02 at 15:39 +0800, Lulu Cheng wrote:


diff --git a/gcc/common/config/loongarch/loongarch-common.cc
b/gcc/common/config/loongarch/loongarch-common.cc
index b6cbd84b873..f8b4660fabf 100644
--- a/gcc/common/config/loongarch/loongarch-common.cc
+++ b/gcc/common/config/loongarch/loongarch-common.cc
@@ -38,7 +38,4 @@ static const struct default_options
loongarch_option_optimization_table[] =
     { OPT_LEVELS_NONE, 0, NULL, 0 }
   };

-#undef TARGET_DEFAULT_TARGET_FLAGS
-#define TARGET_DEFAULT_TARGET_FLAGS    MASK_CHECK_ZERO_DIV
-

I think this modifications are needed, and there is no problem with the
rest.

Yes, this hook is unneeded now.  Though the removal is not strictly
needed, it's good to remove irrelevant code (CWE-1164 says we shouldn't
keep any irrelevant code).

I'll commit the patch with the hook removed after another regtest on
loongarch64-linux-gnu.  I just rebuilt the entire system on my 3A5000,
so I need some time to set it up.  Expectation time to commit is today
evening or tomorrow morning.

BTW I've included this patch building my system, no bad things has
happened so far.

Ok,Thanks!:-)

Re: [PATCH] loongarch: use -mno-check-zero-division as the default for optimized code

[Xi Ruoyao via Gcc-patches]

On Sat, 2022-07-02 at 15:39 +0800, Lulu Cheng wrote:

> diff --git a/gcc/common/config/loongarch/loongarch-common.cc 
> b/gcc/common/config/loongarch/loongarch-common.cc
> index b6cbd84b873..f8b4660fabf 100644
> --- a/gcc/common/config/loongarch/loongarch-common.cc
> +++ b/gcc/common/config/loongarch/loongarch-common.cc
> @@ -38,7 +38,4 @@ static const struct default_options 
> loongarch_option_optimization_table[] =
>     { OPT_LEVELS_NONE, 0, NULL, 0 }
>   };
> 
> -#undef TARGET_DEFAULT_TARGET_FLAGS
> -#define TARGET_DEFAULT_TARGET_FLAGS    MASK_CHECK_ZERO_DIV
> -
> 
> I think this modifications are needed, and there is no problem with the 
> rest.

Yes, this hook is unneeded now.  Though the removal is not strictly
needed, it's good to remove irrelevant code (CWE-1164 says we shouldn't
keep any irrelevant code).

I'll commit the patch with the hook removed after another regtest on
loongarch64-linux-gnu.  I just rebuilt the entire system on my 3A5000,
so I need some time to set it up.  Expectation time to commit is today
evening or tomorrow morning.

BTW I've included this patch building my system, no bad things has
happened so far.

Re: [PATCH] loongarch: use -mno-check-zero-division as the default for optimized code

[Lulu Cheng]

在 2022/6/30 下午2:55, Richard Biener 写道:

On Thu, Jun 30, 2022 at 5:00 AM Xi Ruoyao via Gcc-patches
 wrote:

Hi,

We've made a consensus [1] that not to enable trapping for division by
zero by default for LLVM, and we think GCC should behave similarly.

The main rationales:

1. Division by zero is undefined behavior, so in theory any portable
program shall not depend on it.
2. There are already many targets where both the hardware and GCC port
do nothing to trap on division by zero.  A list taken from
gcc.c-torture/execute/20101011-1.c:  PowerPC, RISC-V, ARM64, MSP430, and
many others.  So in practice any portable program cannot depend on this
trap.
3. As an ICPC assistant coach, I'm well aware that the main disadvantage
not to trap on division by zero is "it breaks expectations of newbies".
So, we keep -mcheck-zero-division defaulted for -O0 and -Og.  For other
optimization levels, it's well known that UBs are already breaking
newbies' expectations [2].
4. GCC is going to optimize more heavily exploiting integer division by
zero [3].  So let's stop encouraging people to rely on any integer
division by zero behavior from now.

[1]: https://reviews.llvm.org/D128572/new/#3612039
[2]: http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html
[3]: https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595099.html

Patch content following.  Bootstrapped and regtested on loongarch64-
linux-gnu. Ok for trunk?

It might be worth backporting this behavioral change to the GCC 12 branch
as well (so 12.1 is the only release with different default behavior) and
documenting the change in changes.html
diff --git a/gcc/common/config/loongarch/loongarch-common.cc 
b/gcc/common/config/loongarch/loongarch-common.cc

index b6cbd84b873..f8b4660fabf 100644
--- a/gcc/common/config/loongarch/loongarch-common.cc
+++ b/gcc/common/config/loongarch/loongarch-common.cc
@@ -38,7 +38,4 @@ static const struct default_options 
loongarch_option_optimization_table[] =

   { OPT_LEVELS_NONE, 0, NULL, 0 }
 };

-#undef TARGET_DEFAULT_TARGET_FLAGS
-#define TARGET_DEFAULT_TARGET_FLAGS    MASK_CHECK_ZERO_DIV
-

I think this modifications are needed, and there is no problem with the 
rest.


Thanks!

Lulu Cheng

[Bug c++/106166] Improve diagnostic for explicit constructor

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106166

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-07-02
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Yes I've been bothered by this for a while. I think this diagnostic is
mentioned in another PR too, contrasting it to the way we display errors for
non-explicit ctors.