[Bug target/109317] -Os generates bigger code than -O2 on 32-bit ARM

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization, ra

--- Comment #1 from Richard Biener  ---
Uh, it's a single move ... possibly SSA coalescing or whatnot.

[Bug c++/109319] [13 Regression] ICE in build_min_non_dep_op_overload, at cp/tree.cc:3793

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-checking

--- Comment #2 from Richard Biener  ---
With release checking I see

t.C:3:14: warning: 'static int S::operator[](int)' may be a static member
function only with '-std=c++23' or '-std=gnu++23' [-Wc++23-extensions]
3 |   static int operator[] (int x) { int a[2]; return a[x]; }
  |  ^~~~
t.C: In function 'int f()':
t.C:8:10: error: lvalue required as increment operand
8 |   ++s[0,1];
  |  ^
t.C: At global scope:
t.C:13:1: error: '$' does not name a type
   13 | $ cat z2.cc
  | ^
t.C:18:23: error: redefinition of 'template int f()'
   18 | template int f ()
  |   ^
t.C:5:23: note: 'template int f()' previously declared here
5 | template int f ()
  |   ^

[Bug tree-optimization/109327] ICE on valid code at -O1 and above with "-fno-tree-ccp": Segmentation fault

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

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

Richard Biener  changed:

   What|Removed |Added

Version|unknown |13.0
   Last reconfirmed||2023-03-29
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #1 from Richard Biener  ---
Mine.

[Bug c++/109283] Destructor of co_yield conditional argument called twice

[StevenSun2021 at hotmail dot com via Gcc-bugs]

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

Steven Sun  changed:

   What|Removed |Added

 CC||StevenSun2021 at hotmail dot 
com

--- Comment #1 from Steven Sun  ---
It is indeed a bug. I currently only investigated into the gcc-12, it generates
something for

```
struct S{ /**/ };
bool w;

co_yield w ? S{"a"} : S{"b"};

```

pseudo-code for the generated gimple:

```
char __res[sizeof(S)];
char __a[sizeof(S)];
char __b[sizeof(S)];

new (__a) S("a");
new (__b) S("b");

if (w)
memcpy(__res, __a, sizeof(S));
else
memcpy(__res, __b, sizeof(S));

/*

...

*/

__b->~S();
__a->~S();
__c->~S();

```

So, clearly there is at least 3 bugs here:
i.   `__res` is never constructed.
ii.  only one of the `__a` and `__b` should be constructed, not both.
iii. the assignment is not corrected (it uses `gimple_assign` for value copy). 

If the ii is correctly implemented, iii will not happen.

Though, the code will work fine on all trivial types.

The correct code should be

```
char __res[sizeof(S)];

if (w)
new (__res) S("a");
else
new (__res) S("b");

/*

...

*/

__res->~S();

```

[Bug target/109329] New: rs6000: New testcases {mul,div}ic3* should run on systems without QP

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

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

Bug ID: 109329
   Summary: rs6000: New testcases {mul,div}ic3* should run on
systems without QP
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: segher at gcc dot gnu.org
  Target Milestone: ---

The testcases use ICmode, which exists fine on almost all systems.  But we
get the error
  cc1: error: '-mabi=ieeelongdouble' requires full ISA 2.06 support

We should not use that flag, or make the testcase not fail some other way.

[Bug target/109329] rs6000: New testcases {mul,div}ic3* should run on systems without QP

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

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

Segher Boessenkool  changed:

   What|Removed |Added

   Priority|P3  |P4
 Target||powerpc*-*-*

[Bug tree-optimization/108357] [13 Regression] Dead Code Elimination Regression at -O2 since r13-4607-g2dc5d6b1e7ec88

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

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

--- Comment #7 from Xi Ruoyao  ---
(In reply to Richard Biener from comment #6)
> (In reply to Xi Ruoyao from comment #5)
> > The test fails on loongarch64-linux-gnu.  foo is kept in 114t.threadfull1,
> > but removed in 135t.forwprop3.
> > 
> > Does this mean something is wrong for LoongArch, or we should simply check
> > the tree dump in a later pass (for e.g. 254t.optimized)?
> 
> I guess it depends on LOGICAL_OP_NON_SHORT_CIRCUIT, can you try
> --param logical-op-non-short-circuit=1 and see if that helps?

Nope, the result is same.

[Bug tree-optimization/108357] [13 Regression] Dead Code Elimination Regression at -O2 since r13-4607-g2dc5d6b1e7ec88

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

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

--- Comment #8 from Xi Ruoyao  ---
Created attachment 54783
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54783&action=edit
threadfull1 dump on LoongArch

[Bug ipa/109318] csmith: -fipa-cp seems to cause trouble since r12-2523-g13586172d0b70c

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

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

Martin Liška  changed:

   What|Removed |Added

Summary|csmith: -fipa-cp seems to   |csmith: -fipa-cp seems to
   |cause trouble   |cause trouble since
   ||r12-2523-g13586172d0b70c
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-03-29
   Keywords|needs-bisection |

--- Comment #5 from Martin Liška  ---
Started with r12-2523-g13586172d0b70c.

[Bug tree-optimization/109327] ICE on valid code at -O1 and above with "-fno-tree-ccp": Segmentation fault

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

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

--- Comment #2 from Richard Biener  ---
It's really an old issue I think.  We record a lattice in forwprop, marking
stmts to be removed.  But the early forwprop phase runs on the IL with
the stmt operands not substituted, instead relying on old get_prop_source_stmt
and remove_prop_source_from_use.  That mechanism can interfere with the
lattice recorded stmt removal.

Testing a patch.

[Bug ipa/109318] [12/13 Regression] csmith: -fipa-cp seems to cause trouble since r12-2523-g13586172d0b70c

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

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

Martin Liška  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |12.3
   Keywords|needs-reduction |
Summary|csmith: -fipa-cp seems to   |[12/13 Regression] csmith:
   |cause trouble since |-fipa-cp seems to cause
   |r12-2523-g13586172d0b70c|trouble since
   ||r12-2523-g13586172d0b70c

--- Comment #6 from Martin Liška  ---
Reduced test-case:

$ cat pr109318.c
#pragma pack(1)
struct S {
  signed : 31;
  unsigned f4 : 20;
};

int tmp, g;
static struct S global;

static struct S func_16(struct S *ptr) {
  for (; g > 0; g+= 8)
tmp &= 8;
  return *ptr;
}

int
main()
{
  struct S *local = &global;
  *local = func_16(local);

  return 0;
}

$ gcc pr109318.c -O2 && ./a.out
Segmentation fault (core dumped)

[Bug ipa/109318] [12/13 Regression] csmith: -fipa-cp seems to cause trouble since r12-2523-g13586172d0b70c

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P1  |P2
  Known to fail||12.1.0, 12.2.0

[Bug sanitizer/109330] New: ASAN since GCC-9 missed a stack-use-after-scope at -O3

[shaohua.li at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 109330
   Summary: ASAN since GCC-9 missed a stack-use-after-scope at -O3
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shaohua.li at inf dot ethz.ch
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

For the following code, ASAN at -O3 since GCC-9 missed the use-after-scope.
I checked the code and found that `*f=*g` and `return *f` were not optimized
away by the compiler.

Compiler explorer: https://godbolt.org/z/c96a6jWrY

% cat a.c
int a, c, d;
char b, e;
int main() {
  int *f = &a, *g = &c;
h:
  &g;
  for (; 0;)
goto h;
  d = 0;
  for (; d <= 3; d++) {
int i = *f;
b && (e = 1);
f = &i;
  }
  *f = *g;
  return *f;
}
% gcc-tk -O3 -fsanitize=address a.c && ./a.out
%
% gcc-8 -O3 -fsanitize=address a.c && ./a.out

==1==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7ffd6b6b94d0
at pc 0x004008e1 bp 0x7ffd6b6b94a0 sp 0x7ffd6b6b9498
WRITE of size 4 at 0x7ffd6b6b94d0 thread T0
#0 0x4008e0 in main /a.c:15
...
%

[Bug ipa/109318] [12/13 Regression] csmith: -fipa-cp seems to cause trouble since r12-2523-g13586172d0b70c

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

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

--- Comment #7 from Richard Biener  ---
With -O2 -fno-early-inlining it can be simplified:

#pragma pack(1)
struct S {
  signed : 31;
  unsigned f4 : 20;
};

static struct S global;

static struct S func_16(struct S *ptr) { return *ptr; }

int
main()
{
  struct S *local = &global;
  *local = func_16(local);
  return 0;
}

assembly:

main:
.LFB1:
.cfi_startproc
movlglobal(%rip), %eax
movl%eax, -7(%rsp)
movlglobal+3(%rip), %eax
movl%eax, -4(%rsp)
movl-7(%rsp), %edx
movl%edx, -14(%rsp)
movl%eax, -11(%rsp)
movl-14(%rsp), %eax
movl%eax, global(%rip)  <--- this faults, global was promoted R/O
xorl%eax, %eax
ret

note the #pragma pack is required to avoid optimizing everything away.

[Bug libstdc++/106608] [12/13 Regression] std::optional requires unavailable dtor

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

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

--- Comment #7 from Jonathan Wakely  ---
(In reply to Egor Pugin from comment #1)
> All major compilers (MSVC, GCC, Clang) of all (tried) modern versions (in
> case of GCC — before 12) build this code without problems. Is this a GCC
> regression?

Your links clearly show you're compiling with Clang though, not GCC. The paste
starts with:
[1/135] /usr/lib/ccache/bin/clang++


The code can be reduced to:

template
struct vector
{
  T* ptr;
  vector();
  vector(const vector&);
  ~vector() { ++ptr; } // requires T to be complete
};

struct nullopt_t { };
constexpr nullopt_t nullopt{};

template
struct optional_payload
{
  optional_payload() = default;
  ~optional_payload() { if (engaged) value.~T(); }
  union {
unsigned char dummy;
T value;
  };
  bool engaged = false;
};

template
struct optional_base
{
  optional_base() = default;
  ~optional_base() = default;
  optional_payload payload;
};

template
struct optional : optional_base
{
  constexpr optional(nullopt_t) { }
};

struct ScanInfo;

struct List {
  List(optional>&& = nullopt);
};

GCC compiles this, but Clang doesn't:

$ clang++ -std=c++17 -c inc.cc
inc.cc:36:13: error: call to implicitly-deleted default constructor of
'optional_base>'
  constexpr optional(nullopt_t) { }
^
inc.cc:47:39: note: in instantiation of member function
'optional>::optional' requested here
  List(optional>&& = nullopt);
  ^
inc.cc:28:3: note: explicitly defaulted function was implicitly deleted here
  optional_base() = default;
  ^
inc.cc:30:23: note: default constructor of 'optional_base>' is
implicitly deleted because field 'payload' has a deleted default constructor
  optional_payload payload;
  ^
inc.cc:16:3: note: explicitly defaulted function was implicitly deleted here
  optional_payload() = default;
  ^
inc.cc:20:7: note: default constructor of 'optional_payload>'
is implicitly deleted because variant field 'value' has a non-trivial default
constructor
T value;
  ^
1 error generated.


Neither does EDG:

$ edg --c++17 -c inc.cc
"inc.cc", line 36: error: the default constructor of
  "optional_base>" cannot be referenced -- it is a
  deleted function
constexpr optional(nullopt_t) { }
  ^
  detected during instantiation of "optional::optional(nullopt_t)
[with T=vector]" at line 42

"inc.cc", line 7: error: expression must be a pointer to a complete object type
~vector() { ++ptr; } // requires T to be complete
  ^
  detected during:
instantiation of "vector::~vector() [with T=ScanInfo]" at line
  17
instantiation of "optional_payload::~optional_payload() [with
  T=vector]" at line 43

2 errors detected in the compilation of "inc.cc".

Nor MSVC:

(7): error C2036: 'ScanInfo *': unknown size
(7): note: while compiling class template member function
'vector::~vector(void)'
(44): note: see reference to function template instantiation
'vector::~vector(void)' being compiled
(20): note: see reference to class template instantiation
'vector' being compiled
(30): note: see reference to class template instantiation
'optional_payload' being compiled
with
[
T=vector
]
(35): note: see reference to class template instantiation
'optional_base' being compiled
with
[
T=vector
]
(42): note: see reference to class template instantiation
'optional>' being compiled
Compiler returned: 2


Maybe the code is ill-formed (no diagnostic required), or maybe G++ is being
too generous to compile it, but I don't think there's a libstdc++ bug here.

[Bug tree-optimization/109327] ICE on valid code at -O1 and above with "-fno-tree-ccp": Segmentation fault

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:7fd1d28d2436065da7fc0fe01d787fcdf3c14b83

commit r13-6926-g7fd1d28d2436065da7fc0fe01d787fcdf3c14b83
Author: Richard Biener 
Date:   Wed Mar 29 09:51:58 2023 +0200

tree-optimization/109327 - forwprop stmt removal issue

There's interfering between the to_removed queue and other mechanisms
removing stmts, in this case remove_prop_source_from_use.  The following
makes the to_remove queue draining more permissive.

PR tree-optimization/109327
* tree-ssa-forwprop.cc (pass_forwprop::execute): Deal with
already removed stmts when draining to_remove.

* gcc.dg/pr109327.c: New testcase.

[Bug ipa/109318] [12/13 Regression] csmith: -fipa-cp seems to cause trouble since r12-2523-g13586172d0b70c

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

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

Martin Jambor  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jamborm at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

--- Comment #8 from Martin Jambor  ---
Mine

[Bug tree-optimization/109327] ICE on valid code at -O1 and above with "-fno-tree-ccp": Segmentation fault

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
   Keywords||ice-on-valid-code
 Resolution|--- |FIXED

--- Comment #4 from Richard Biener  ---
Fixed (it's probably latent on the branches).

[Bug libstdc++/106608] std::optional requires unavailable dtor when compiled with clang

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

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

Jonathan Wakely  changed:

   What|Removed |Added

Summary|[12/13 Regression]  |std::optional requires
   |std::optional requires  |unavailable dtor when
   |unavailable dtor|compiled with clang
   Keywords|needs-bisection,|
   |rejects-valid   |
   Target Milestone|12.3|---

--- Comment #8 from Jonathan Wakely  ---
Also, there's no regression. I don't know why you think this has anything to do
with GCC 12. Given this code:

#include 
#include 
using namespace std;

struct ScanInfo;

struct List {
  List(optional>&& = nullopt);
};

All versions of GCC compile it. Clang rejects it with all libstdc++ headers:


$ clang++ -std=c++17 -c inc.cc --gcc-toolchain=$HOME/gcc/8
In file included from inc.cc:2:
In file included from
/home/jwakely/gcc/8/lib/gcc/x86_64-pc-linux-gnu/8.5.0/../../../../include/c++/8.5.0/vector:62:
/home/jwakely/gcc/8/lib/gcc/x86_64-pc-linux-gnu/8.5.0/../../../../include/c++/8.5.0/bits/stl_construct.h:133:7:
error: static assertion failed due to requirement
'is_destructible::value': value type is destructible


$ clang++ -std=c++17 -c inc.cc --gcc-toolchain=$HOME/gcc/9
In file included from inc.cc:2:
In file included from
/home/jwakely/gcc/9/lib/gcc/x86_64-pc-linux-gnu/9.5.0/../../../../include/c++/9.5.0/vector:65:
/home/jwakely/gcc/9/lib/gcc/x86_64-pc-linux-gnu/9.5.0/../../../../include/c++/9.5.0/bits/stl_construct.h:133:7:
error: static assertion failed due to requirement
'is_destructible::value': value type is destructible


$ clang++ -std=c++17 -c inc.cc --gcc-toolchain=$HOME/gcc/10
In file included from inc.cc:1:
In file included from
/home/jwakely/gcc/10/lib/gcc/x86_64-pc-linux-gnu/10.4.1/../../../../include/c++/10.4.1/optional:36:
In file included from
/home/jwakely/gcc/10/lib/gcc/x86_64-pc-linux-gnu/10.4.1/../../../../include/c++/10.4.1/utility:70:
In file included from
/home/jwakely/gcc/10/lib/gcc/x86_64-pc-linux-gnu/10.4.1/../../../../include/c++/10.4.1/bits/stl_pair.h:59:
In file included from
/home/jwakely/gcc/10/lib/gcc/x86_64-pc-linux-gnu/10.4.1/../../../../include/c++/10.4.1/bits/move.h:57:
/home/jwakely/gcc/10/lib/gcc/x86_64-pc-linux-gnu/10.4.1/../../../../include/c++/10.4.1/type_traits:844:7:
error: static assertion failed due to requirement
'std::__is_complete_or_unbounded(std::__type_identity{})': template
argument must be a complete class or an unbounded array


$ clang++ -std=c++17 -c inc.cc --gcc-toolchain=$HOME/gcc/11
In file included from inc.cc:1:
In file included from
/home/jwakely/gcc/11/lib/gcc/x86_64-pc-linux-gnu/11.3.1/../../../../include/c++/11.3.1/optional:36:
In file included from
/home/jwakely/gcc/11/lib/gcc/x86_64-pc-linux-gnu/11.3.1/../../../../include/c++/11.3.1/utility:70:
In file included from
/home/jwakely/gcc/11/lib/gcc/x86_64-pc-linux-gnu/11.3.1/../../../../include/c++/11.3.1/bits/stl_pair.h:59:
In file included from
/home/jwakely/gcc/11/lib/gcc/x86_64-pc-linux-gnu/11.3.1/../../../../include/c++/11.3.1/bits/move.h:57:
/home/jwakely/gcc/11/lib/gcc/x86_64-pc-linux-gnu/11.3.1/../../../../include/c++/11.3.1/type_traits:885:7:
error: static assertion failed due to requirement
'std::__is_complete_or_unbounded(std::__type_identity{})': template
argument must be a complete class or an unbounded array


$ clang++ -std=c++17 -c inc.cc --gcc-toolchain=$HOME/gcc/12
In file included from inc.cc:1:
In file included from
/home/jwakely/gcc/12/lib/gcc/x86_64-pc-linux-gnu/12.2.1/../../../../include/c++/12.2.1/optional:37:
/home/jwakely/gcc/12/lib/gcc/x86_64-pc-linux-gnu/12.2.1/../../../../include/c++/12.2.1/type_traits:910:7:
error: static assertion failed due to requirement
'std::__is_complete_or_unbounded(std::__type_identity{})': template
argument must be a complete class or an unbounded array

[Bug fortran/92960] ICE tree check: expected tree that contains 'decl minimal' structure, have 'component_ref' in add_decl_as_local, at fortran/trans-decl.c:261

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

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

Paul Thomas  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Paul Thomas  ---
Fixed on 12-branch and mainline. I will add the testcase below, when the
current patch for some of PR87477 is committed.

Thanks

Paul

! { dg-do-run }
!
! Contributed by Gerhard Steinmetz  
!
program p
   type t(n)
  integer, len :: n
  character(n) :: c
   end type
   type(t(:)), allocatable :: z
   allocate (t(7) :: z)
   z%c = "1234567"
   associate (y => z%c)
   if (y .ne. "1234567") stop 1
   if (len (y) .ne. 7) stop 2
   end associate
   deallocate (z)
end

[Bug fortran/87477] [meta-bug] [F03] issues concerning the ASSOCIATE statement

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

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

Bug 92960 Summary: ICE tree check: expected tree that contains 'decl minimal' 
structure, have 'component_ref' in add_decl_as_local, at 
fortran/trans-decl.c:261
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92960

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o

[ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs]

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

--- Comment #22 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #21 from ro at CeBiTec dot Uni-Bielefeld.DE  Uni-Bielefeld.DE> ---
>> --- Comment #20 from Jakub Jelinek  ---
>> Tried valgrind on the cross d21 on x86_64 and didn't see anything.
>> Perhaps modify the makefiles such that it uses -fdump-tree-all -da already 
>> when
>> compiling typeinfo.lo?
>
> I'll give that a whirl.  However, my SPARC box is pretty busy right now
> with the weekly bootstraps, so this will be later this weekend only.

Bootstrapping with

GDCFLAGS_FOR_TARGET='-O2 -g -fdump-tree-optimized -da'

didn't show the comparison failure.

> In the meantime, I try to reproduce the issue on gcc211.

That didn't show the failure either.

To make things even more weird, I've run several regular bootstraps
since:

* Friday night:

** Solaris 11.4 trunk (latest development build, bare metal, SPARC-S7):
  32-bit gas/ld and 32-bit gas/gld bootstraps failed with the comparison
  failure, while 64-bit gas/ld completed.

** Solaris 11.4 (latest update, kernel zone/VM, different host,
   SPARC-T5): 32-bit gas/ld failed.

** Solaris 11.3 (latest update, kernel zone/VM, SPARC-S7): 32-bit gas/ld
   failed.

* Monday night: 32-bit gas/ld bootstrap passed.

* Tuesday night: 32-bit gas/ld bootstrap failed again.

Seems incredibly fragile, unfortunately.

[Bug c/109331] New: ice: definition in block 7 does not dominate use in block 8

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 109331
   Summary: ice: definition in block 7 does not dominate use in
block 8
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

This reduced C code:

ustol_dpp;
ustol(flags) {
  char *s;
  if (s)
flags |= 3;
  switch (flags & 3)
  case 3:
while (*s)
case '+':
  ++s;
  if (flags)
ustol_dpp = s;
}

when compiled by this morning's trunk gcc and flag -O1, does this:

$ ~/gcc/results/bin/gcc -c -w -O1 bug904.c
bug904.c: In function ‘ustol’:
bug904.c:2:1: error: definition in block 7 does not dominate use in block 8
2 | ustol(flags) {
  | ^
for SSA_NAME: s_8 in statement:
s.0_3 = (long int) s_8;
during GIMPLE pass: forwprop
bug904.c:2:1: internal compiler error: verify_ssa failed
0x110bc49 verify_ssa(bool, bool)
../../trunk.year/gcc/tree-ssa.cc:1211

This was fine with yesterday's compiler:

$ ~/gcc/results.20230328/bin/gcc -c -w -O1 bug904.c
$ 

Git range is g:304c7d44a2212e6f to g:36330e2e95564a36, which is 35 commits.

[Bug tree-optimization/108357] [13 Regression] Dead Code Elimination Regression at -O2 since r13-4607-g2dc5d6b1e7ec88

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

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

--- Comment #9 from Richard Biener  ---
(In reply to Xi Ruoyao from comment #7)
> (In reply to Richard Biener from comment #6)
> > (In reply to Xi Ruoyao from comment #5)
> > > The test fails on loongarch64-linux-gnu.  foo is kept in 114t.threadfull1,
> > > but removed in 135t.forwprop3.
> > > 
> > > Does this mean something is wrong for LoongArch, or we should simply check
> > > the tree dump in a later pass (for e.g. 254t.optimized)?
> > 
> > I guess it depends on LOGICAL_OP_NON_SHORT_CIRCUIT, can you try
> > --param logical-op-non-short-circuit=1 and see if that helps?
> 
> Nope, the result is same.

Aha, the issue is missing promotions, already in .original:

-short int g = a (5, (int) ((short int) b ^ 9854));
-  f ((int) g);
+short int g = a (5, (short int) b ^ 9854);
+  f (g);

(+ is loongarch, - is x86_64)

That results in different IL into threadfull1.  On loongarch forwprop3
elides the branch, probably with the help of nonzero bits set by CCP.

[Bug target/109332] New: Bug in gcc (13.0.1) support for ARM SVE, which randomly ignore the predict register

[wumingchuan1992 at foxmail dot com via Gcc-bugs]

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

Bug ID: 109332
   Summary: Bug in gcc (13.0.1) support for ARM SVE, which
randomly ignore the predict register
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wumingchuan1992 at foxmail dot com
  Target Milestone: ---

func_demo.c
#include 
#include 

#define VML_SVE_DOUBLE_SIGN_BIT svdup_n_u64(0x8000ULL)

svfloat64_t func_demo(svbool_t pg, svfloat64_t x, svbool_t cmpBig)
{
svuint64_t ux = svreinterpret_u64_f64(x);
svuint64_t sn = svand_u64_x(pg, ux, VML_SVE_DOUBLE_SIGN_BIT);
svint64_t isn = svreinterpret_s64_u64(sn);
svfloat64_t res = svcvt_f64_s64_x(pg, svsub_n_s64_x(cmpBig, isn, 0x4LL));
return res;
}

Run gcc(10.3.0 and 13.0.1 20230327) with the following command:
$ gcc -std=c99 -O2 -funroll-loops -march=armv8.3-a+fp+sve -o func_demo.o -c
func_demo.c
After objdump, the result is as follows:
 :
0: 05820800 and z0.d, z0.d, #0x8000
4: 25e1c080 sub z0.d, z0.d, #4
8: 65d6a000 scvtf z0.d, p0/m, z0.d
c: d65f03c0 ret

It can be seen that the predict register is ignored during the sub operation,
and the action similar to svptrue_b64() is used.

For comparison, use llvm for compilation：
$ clang -std=c99 -O2 -funroll-loops -march=armv8.3-a+fp+sve -o func_demo.o -c
func_demo.c
the result is as follows:
 :
0: 05c20801 mov z1.d, #0x8000
4: 04da0020 and z0.d, p0/m, z0.d, z1.d
8: 25f8c081 mov z1.d, #4
c: 04c10420 sub z0.d, p1/m, z0.d, z1.d
10: 65d6a000 scvtf z0.d, p0/m, z0.d
14: d65f03c0 ret

The sub operation is correct.
Any suggestions to proceed?

[Bug libstdc++/109333] New: Use std::move in std::accumulate etc. for std::string for C++11/14/17

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

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

Bug ID: 109333
   Summary: Use std::move in std::accumulate etc. for std::string
for C++11/14/17
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0616r0.pdf changed
some  algos to use std::move for the accumulator, which is an
observable semantic change. For that reason, we only implement the change for
C++20 and up, to retain the behaviour specified in earlier standards.

If the accumulator is std::string then we know it's not observable, and so we
can improve performance by always moving (except in C++98 mode).

[Bug tree-optimization/109331] ice: definition in block 7 does not dominate use in block 8

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

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

Richard Biener  changed:

   What|Removed |Added

  Component|c   |tree-optimization
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2023-03-29

--- Comment #1 from Richard Biener  ---
Mine.

[Bug target/109332] Bug in gcc (13.0.1) support for ARM SVE, which randomly ignore the predict register

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

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from ktkachov at gcc dot gnu.org ---
That's expected. Please see
https://github.com/ARM-software/acle/blob/main/main/acle.md#sve-naming-convention
Since the input uses the _x form of the intrinsic svsub_n_s64_x the predication
behaviour is left to the compiler and the ACLE specifies:
"This form of predication removes the need to choose between zeroing and
merging in cases where the inactive elements are unimportant. The code
generator can then pick whichever form of instruction seems to give the best
code. This includes using unpredicated instructions, where available and
suitable."

So using an unpredicated sub instruction is appropriate here and not a bug.

[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o

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

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

--- Comment #23 from Jakub Jelinek  ---
Ugh, that sounds like an uninitialized use of something somewhere,
unfortunately if it is really my commit, I don't understand how it could cause
it.
All it changes is that when tree_versioning is called, the push_struct_function
-> allocate_struct_function will not do the
  if (!abstract_p)
{
  /* Now that we have activated any function-specific attributes
 that might affect layout, particularly vector modes, relayout
 each of the parameters and the result.  */
  relayout_decl (result);
  for (tree parm = DECL_ARGUMENTS (fndecl); parm;
   parm = DECL_CHAIN (parm))
relayout_decl (parm);
}
and
  if (!abstract_p && aggregate_value_p (result, fndecl))
{
#ifdef PCC_STATIC_STRUCT_RETURN
  cfun->returns_pcc_struct = 1;
#endif
  cfun->returns_struct = 1;
}
parts it did before when abstract_p was false in this case.
As I wrote, initialize_cfun has
  cfun->returns_struct = src_cfun->returns_struct;
  cfun->returns_pcc_struct = src_cfun->returns_pcc_struct;
a few lines later, so whatever it sets cfun->returns* to should be overritten
quickly.
It is true allocate_stack_function calls before that allocate_stack_usage_info
and
stdarg_p but neither of those two should care about those flag or whatever
relayout_decl does.
Perhaps try to undo my patch in a different way, like
--- gcc/tree-inline.cc  2023-03-17 18:59:50.226199917 +0100
+++ gcc/tree-inline.cc  2023-03-29 12:47:21.546947442 +0200
@@ -2785,7 +2785,7 @@ initialize_cfun (tree new_fndecl, tree c
   gimple_register_cfg_hooks ();

   /* Get clean struct function.  */
-  push_struct_function (new_fndecl, true);
+  push_struct_function (new_fndecl, false);
   targetm.target_option.relayout_function (new_fndecl);

   /* We will rebuild these, so just sanity check that they are empty.  */
or
--- gcc/tree-inline.cc  2023-03-17 18:59:50.226199917 +0100
+++ gcc/tree-inline.cc  2023-03-29 12:49:16.580255668 +0200
@@ -2786,7 +2786,11 @@ initialize_cfun (tree new_fndecl, tree c

   /* Get clean struct function.  */
   push_struct_function (new_fndecl, true);
+  relayout_decl (DECL_RESULT (new_fndecl));
+  for (tree parm = DECL_ARGUMENTS (new_fndecl); parm; parm = DECL_CHAIN
(parm))
+relayout_decl (parm);
   targetm.target_option.relayout_function (new_fndecl);
+  aggregate_value_p (DECL_RESULT (new_fndecl), new_fndecl);

   /* We will rebuild these, so just sanity check that they are empty.  */
   gcc_assert (VALUE_HISTOGRAMS (cfun) == NULL);
and see if that changes anything?  Of course both of those patches break the
PR105554
again.  Or if the latter helps, try to comment out the different parts of it
too.

Seems there was some valgrind for SPARC Solaris out of tree, but can't find it
anymore...

[Bug tree-optimization/109334] New: tree-object-size: Improve size computation in arguments

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

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

Bug ID: 109334
   Summary: tree-object-size: Improve size computation in
arguments
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: siddhesh at gcc dot gnu.org
CC: jakub at gcc dot gnu.org, marxin at gcc dot gnu.org,
msebor at gcc dot gnu.org, muecker at gwdg dot de,
siddhesh at gcc dot gnu.org
Depends on: 104970
  Target Milestone: ---

The fix for bug 104970 is too restrictive, size computation should also work
for VLA bounds and also cases where it could work without attributes in simple
cases, e.g.

size_t
__attribute__ ((noinline))
test_parmsz_internal3 (size_t sz1, size_t sz2, double obj[sz1][sz2])
{
  return __builtin_dynamic_object_size (obj, 0);
}

or

__attribute__ ((noinline, access (read_only, 2, 1)))
int foo(int n, int buf[n])
{
buf[n] = 1;
return __builtin_dynamic_object_size(buf, 0);
}

int main() {
int n = 10;
int buf[n];
return foo(n, buf);
}


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104970
[Bug 104970] [12 Regression] ICE in execute_todo, at passes.cc:2133 since
r12-6480-gea19c8f33a3a8d2b

[Bug tree-optimization/104970] [12 Regression] ICE in execute_todo, at passes.cc:2133 since r12-6480-gea19c8f33a3a8d2b

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

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

--- Comment #14 from Siddhesh Poyarekar  ---
(In reply to Martin Uecker from comment #13)
> This fix seem too radical. It now prevents this from working even when there
> is an explicit attribute but there is also a VLA bound.  Also I think it
> would be nice if it worked without the explicit attribute at least in the
> simple cases where this should be now problem.

I've cloned this to bug 109334.

[Bug tree-optimization/107561] [13 Regression] g++.dg/pr71488.C and [g++.dg/warn/Warray-bounds-16.C -m32] regression due to -Wstringop-overflow problem

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
   Priority|P1  |P3

--- Comment #23 from Richard Biener  ---
So we can "mitigate" the diagnostic for g++.dg/pr17488.C with a hack, but for
g++.dg/warn/Warray-bounds-16.C we see

 [local count: 1073741824]:
a ={v} {CLOBBER};
a.m = 0;
_5 = operator new [] (0);
a.p = _5;
_2 = a.m;
if (_2 > 0)
  goto ; [89.00%]
else
  goto ; [11.00%]

 [local count: 955630225]:
_12 = (sizetype) _2;
_11 = _12 * 4;
__builtin_memset (_5, 0, _11); [tail call]

where we'd have a clear range (_2 > 0) even without the multiplication but
we're only now picking that up.  The bug here is quite the same
missed optimization though, we fail to CSE a.m around the 'operator new [] (0)'
call and so obviously dead code remains.

C++ is simply an awful language to work with here.  A static analyzer would
maybe simply look past possibly clobbering calls deriving the code is
likely dead and refrain from diagnosing it.

Note while for g++.dg/warn/Warray-bounds-16.C we are again working inside a
CTOR the issue extends to any code with intermediate allocations via
new or delete expressions.  Yes, we can add some flag like -fnew-is-not-stupid,
but then we couldn't make it the default.  Maybe(?) we can somehow detect
whether we are dealing with overloaded global new/delete with LTO, like
detecting we're resolving it to the copy in libstdc++?  The resolution info
just tells us RESOLVED_DYN though, maybe we can add something like
RESOLVED_STDLIB_DYN and handle a set of known libraries specially?

I'm putting this back to P3, we do have a load more (late) diagnostic
regressions in GCC 13.

[Bug tree-optimization/107561] [13 Regression] g++.dg/pr71488.C and [g++.dg/warn/Warray-bounds-16.C -m32] regression due to -Wstringop-overflow problem

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

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

--- Comment #24 from Richard Biener  ---
Created attachment 54784
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54784&action=edit
another hack

[Bug c++/109319] [12/13 Regression] ICE in build_min_non_dep_op_overload, at cp/tree.cc:3793 since r12-5510

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2
Summary|[13 Regression] ICE in  |[12/13 Regression] ICE in
   |build_min_non_dep_op_overlo |build_min_non_dep_op_overlo
   |ad, at cp/tree.cc:3793  |ad, at cp/tree.cc:3793
   ||since r12-5510

--- Comment #3 from Jakub Jelinek  ---
(In reply to Richard Biener from comment #2)
> With release checking I see

Those are two separate testcases which just differ in 0,1 vs. 1,0.

Anyway, adjusted testcase so that it isn't so invalid:
struct S
{
  static int &operator[] (int x) { static int a[2]; return a[x]; }
};

template 
int
foo ()
{
  S s;
  ++s[0, 1];
  return 0;
}
and without the template  line is accepted with a pedwarn.
And, if it is changed to:
struct S
{
  int &operator[] (int x) { static int a[2]; return a[x]; }
};

template 
int
foo ()
{
  S s;
  ++s[0, 1];
  return 0;
}
then it is also accepted with pedwarn without the template  line and
otherwise ICEs already starting with r12-5510-gb38c9cf6d570f6.

[Bug tree-optimization/109331] ice: definition in block 7 does not dominate use in block 8

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:86efc490ab86bfa00720479b4714da23cd7df797

commit r13-6928-g86efc490ab86bfa00720479b4714da23cd7df797
Author: Richard Biener 
Date:   Wed Mar 29 11:59:16 2023 +0200

tree-optimization/109331 - make sure to clean up the CFG after forwprop

When forwprop discovers unreachable code or makes decisions based
on unreachable edges make sure to cleanup the CFG since otherwise
SSA form can become invalid.

PR tree-optimization/109331
* tree-ssa-forwprop.cc (pass_forwprop::execute): When we
discover a taken edge make sure to cleanup the CFG.

* gcc.dg/torture/pr109331.c: New testcase.

[Bug tree-optimization/109331] ice: definition in block 7 does not dominate use in block 8

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Richard Biener  ---
Fixed.

[Bug driver/108865] gcc on Windows fails with Unicode path to source file

[costas.argyris at gmail dot com via Gcc-bugs]

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

--- Comment #31 from Costas Argyris  ---
This was initially done only for the 64-bit mingw Windows host
(x86_64-*-mingw*).

This is the patch that extended it to the 32-bit version as well
(i[34567]86-*-mingw32*):

https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=304c7d44a2212e6fd618587331cea2c266dc10bf

[Bug driver/108865] gcc on Windows fails with Unicode path to source file

[costas.argyris at gmail dot com via Gcc-bugs]

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

--- Comment #32 from Costas Argyris  ---
Followed by:

https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=e70e36cbef4f01e7d32bafe17698c3bf3e4624b8

[Bug driver/108865] gcc on Windows fails with Unicode path to source file

[costas.argyris at gmail dot com via Gcc-bugs]

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

--- Comment #33 from Costas Argyris  ---
It should be noted that with the current implementation, windres (part of
binutils) is mandatory when building for the mingw (Windows) hosts, both 32 and
64-bit versions.

That is, a build failure will occur if windres is not found for the mingw
hosts.

This means that for these hosts, gcc will *always* be built with UTF-8 as its
active code page on Windows, thereby eliminating the need to have a way to
query the active code page as a user.

If for example, it could be built either with or without windres, then the
active code page would also be conditional on that, so users would need a way
to tell what is the active code page being used by a given gcc.exe or g++.exe
executable.By having windres be a mandatory build tool for the mingw hosts,
this is not a requirement because the answer will always be UTF-8 (otherwise
the build would have failed).

This is all relevant for gcc 13 or later (as per Target Milestone above) and a
minimum Windows Version 1903 (May 2019 Update).If gcc is 13 or later but
Windows version is earlier than the minimum target version, gcc will not be
using UTF-8 as its active code page on its own - it will still be possible to
make it though by applying the UTF-8 manifest with mt.exe manually, or by
checking the Windows checkbox that sets UTF-8 globally.

[Bug sanitizer/109330] ASAN since GCC-9 missed a stack-use-after-scope at -O3

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Martin Liška  ---
We completely eliminate usage of 'f' with -O3 and thus there's no ASAN report.
Note, clang does not emit an error even with -O2.

[Bug bootstrap/109310] --enable-link-mutex is quite duplicate to --enable-link-serialization

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2023-03-29
   Keywords||patch

--- Comment #2 from Martin Liška  ---
(In reply to Jakub Jelinek from comment #1)
> So perhaps for GCC13 emit some kind of deprecation message for it and
> suggest using --enable-link-serialization instead and delete later?

Yes, I've just sent a patch:
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614841.html

[Bug bootstrap/109310] --enable-link-mutex is quite duplicate to --enable-link-serialization

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Martin Liska :

https://gcc.gnu.org/g:8b2766e87dbf0d20808bc92d8e6ee7f876d19ab2

commit r13-6929-g8b2766e87dbf0d20808bc92d8e6ee7f876d19ab2
Author: Martin Liska 
Date:   Wed Mar 29 14:52:42 2023 +0200

configure: deprecate --enable-link-mutex option

PR bootstrap/109310

gcc/ChangeLog:

* configure.ac: Emit a warning for deprecated option
--enable-link-mutex.
* configure: Regenerate.

[Bug tree-optimization/106511] [13 Regression] New -Werror=maybe-uninitialized since r13-1268-g8c99e307b20c502e

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||12.2.0

--- Comment #4 from Richard Biener  ---
Earlier GCC were confused enough to not diagnose this, they have the same
missed-optimization.

[Bug middle-end/106008] [11/12/13 Regression] warning: ‘(((char *)loadcmds.113_68 + _933 + 16))[329406144173384849].mapend’ may be used uninitialized [-Wmaybe-uninitialized]

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
   Keywords|missed-optimization,|
   |needs-reduction |
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #4 from Richard Biener  ---
(In reply to Richard Biener from comment #3)
> # VUSE <.MEM_699>
> _109 = MEM[(struct loadcmd *)_106 + -56B].mapend;
> 
> my only suspicion is that we somehow isolate (and not optimize as
> unreachable)
> the nloadcmds < 1 case in the preceeding case.

Nope the statement we are diagnosing is guarded by nloadcmds > 1.

A reduced testcase looks like the following, needs -Os -fno-ivopts to
reproduce the diagnostics.  It is somewhat of a fundamental limit of
the analysis since when walking the virtual use-def chain we look for
aliases but q[-1] doesn't alias q[0] but when walking the backedge
we simply arrive at the very same stmt again and interpret it as if
it were within the same context.  That might also be a problem for
passes using walk_aliased_vdefs for other purposes than diagnostics.
I think that when walking a backedge walk_aliased_vdefs would need to
be more careful with interpreting the defs it runs into.

int foo (int n)
{
  int *p = __builtin_malloc (n);
  int nloadcmds = 0;
  int found = 0;
  do
{
  int *q = &p[nloadcmds++];
  *q = n;
  if (nloadcmds > 1
  && q[-1] != 7)
found = 1;
}
  while (nloadcmds < n);
  return found;
}

[Bug c++/109319] [12/13 Regression] ICE in build_min_non_dep_op_overload, at cp/tree.cc:3793 since r12-5510

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Created attachment 54785
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54785&action=edit
gcc13-pr109319.patch

Untested fix.

[Bug target/109324] Genrecog reports "source missing a mode?" for H8

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
They can be muted by fixing the h8300/*.md...

[Bug analyzer/109335] New: -Wanalyzer-malloc-leak false positives and false negatives

[colomar.6.4.3 at gmail dot com via Gcc-bugs]

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

Bug ID: 109335
   Summary: -Wanalyzer-malloc-leak false positives and false
negatives
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: colomar.6.4.3 at gmail dot com
  Target Milestone: ---

Created attachment 54786
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54786&action=edit
Preprocessed reproducer

Link:


With both GCC 12.2.0 (Debian), and GCC 13.0.1 20230315 (built from source),
I can reproduce these false positives.  I'm on Debian Sid with
libbsd-dev 0.11.7-4, and libc-dev 2.36-8.

The reproducer program is a small program that checks a password against a
hardcoded string, and conditionally prints "validated".  I wrote it
precisely to demonstrate how [[gnu::malloc(deallocator)]] can be used to
ensure that passwords are not leaked in memory, but I found out that it
fails to detect some conditions.

Here's the program (it uses agetpass(), as defined in the shadow project):

$ cat pass.c 
#include 
#include 
#include 
#include 
#include 
#include 
#include 


#define PASS_MAX  BUFSIZ - 1


#define MALLOCARRAY(n, type)   ((type *) mallocarray(n, sizeof(type)))


[[gnu::malloc, gnu::malloc(free)]] void *mallocarray(size_t nmemb, size_t
size);
void erase_pass(char *pass);
[[gnu::malloc(erase_pass)]] char *agetpass(const char *prompt);


void
do_work(void)
{
char  *pass;

pass = agetpass("Enter your password: ");
if (pass == NULL)
err(EXIT_FAILURE, "agetpass");

if (strcmp(pass, "secret") == 0)
puts("validated");

/* erase_pass() zeroes the memory (think of memset(3), or bzero(3))
   and then releases the memory to the system (think of free(3)).
   If you only call free(pass), then you release the memory to the
   system without zeroing it.  Remember it contains a password!
   We would be leaking a password into the system memory, which can
   later be assigned to a different process.

   So, we should call erase_pass() as soon as possible, but let's
   say we forgot, and just call free():
*/
#if defined(BUG_1)
// We forgot to zero the memory.
free(pass);
// GCC correctly catches this as -Wmismatched-dealloc
#elif defined(BUG_2)
// We zeroed, but forgot to free(3).
bzero(pass, PASS_MAX + 2);
// GCC misses this.
#elif defined(BUG_3)
// We forgot both of them.
// GCC also misses this.
#else
erase_pass(pass);  // OK, but 2 false positives.
#endif
}


int
main(void)
{
do_work();

for (;;)
sleep(1);
}


void *
mallocarray(size_t nmemb, size_t size)
{
return reallocarray(NULL, nmemb, size);
}


char *
agetpass(const char *prompt)
{
char*pass;
size_t  len;

pass = MALLOCARRAY(PASS_MAX + 2, char);
if (pass == NULL)
return NULL;

if (readpassphrase(prompt, pass, PASS_MAX + 2, RPP_REQUIRE_TTY) ==
NULL)
goto fail;

len = strlen(pass);
if (len == PASS_MAX + 1) {
errno = ENOBUFS;
goto fail;
}

return pass;

fail:
freezero(pass, PASS_MAX + 2);
return NULL;
}


void
erase_pass(char *pass)
{
freezero(pass, PASS_MAX + 2);
}



This shows the false positives:


$ cc -Wall -Wextra pass.c $(pkgconf --cflags --libs libbsd-overlay) -fanalyzer
-O3
pass.c: In function ‘agetpass’:
pass.c:84:12: warning: leak of ‘pass’ [CWE-401] [-Wanalyzer-malloc-leak]
   84 | if (pass == NULL)
  |^
  ‘do_work’: events 1-3
|
|   22 | do_work(void)
|  | ^~~
|  | |
|  | (1) entry to ‘do_work’
|..
|   26 | pass = agetpass("Enter your password: ");
|  |~
|  ||
|  |(2) allocated here
|  |(3) calling ‘agetpass’ from ‘do_work’
|
+--> ‘agetpass’: events 4-5
   |
   |   78 | agetpass(const char *prompt)
   |  | ^~~~
   |  | |
   |  | (4) entry to ‘agetpass’
   |..
   |   84 | if (pass == NULL)
   |  |~
   |  ||
   |  |(5) ‘pass’ leaks here; was allocated at (2)
   |
pass.c:91:12: warning: leak of ‘pass’ [CWE-401] [-Wanalyzer-malloc-leak]
   91 | if (len == PASS_MAX + 1) {
  |^
  ‘do_work’: events 1-3
|
|   22 | do_work(void)
|  | ^~~
|  | |
|  | (1) entry to ‘do

[Bug modula2/109336] New: The -fmod= and -fdef= options do not work.

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

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

Bug ID: 109336
   Summary: The -fmod= and -fdef= options do not work.
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: modula2
  Assignee: gaius at gcc dot gnu.org
  Reporter: gaius at gcc dot gnu.org
  Target Milestone: ---

The -fmod= and -fdef= options do not work.  After the linking re-implementation
and subsequent restructuring the -fmod= amd -fdef= are now broken.

[Bug modula2/109336] The -fmod= and -fdef= options do not work.

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

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

Gaius Mulley  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2023-03-29

[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o

[ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs]

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

--- Comment #24 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #23 from Jakub Jelinek  ---
[...]
> Perhaps try to undo my patch in a different way, like
> --- gcc/tree-inline.cc  2023-03-17 18:59:50.226199917 +0100
> +++ gcc/tree-inline.cc  2023-03-29 12:47:21.546947442 +0200
> @@ -2785,7 +2785,7 @@ initialize_cfun (tree new_fndecl, tree c
>gimple_register_cfg_hooks ();
>
>/* Get clean struct function.  */
> -  push_struct_function (new_fndecl, true);
> +  push_struct_function (new_fndecl, false);
>targetm.target_option.relayout_function (new_fndecl);
>
>/* We will rebuild these, so just sanity check that they are empty.  */
> or
> --- gcc/tree-inline.cc  2023-03-17 18:59:50.226199917 +0100
> +++ gcc/tree-inline.cc  2023-03-29 12:49:16.580255668 +0200
> @@ -2786,7 +2786,11 @@ initialize_cfun (tree new_fndecl, tree c
>
>/* Get clean struct function.  */
>push_struct_function (new_fndecl, true);
> +  relayout_decl (DECL_RESULT (new_fndecl));
> +  for (tree parm = DECL_ARGUMENTS (new_fndecl); parm; parm = DECL_CHAIN
> (parm))
> +relayout_decl (parm);
>targetm.target_option.relayout_function (new_fndecl);
> +  aggregate_value_p (DECL_RESULT (new_fndecl), new_fndecl);
>
>/* We will rebuild these, so just sanity check that they are empty.  */
>gcc_assert (VALUE_HISTOGRAMS (cfun) == NULL);
> and see if that changes anything?  Of course both of those patches break the
> PR105554
> again.  Or if the latter helps, try to comment out the different parts of it
> too.

So far, I've tried both variants and in each case, the comparison
failure is gone.

> Seems there was some valgrind for SPARC Solaris out of tree, but can't find it
> anymore...

There was one back in the 2014-2017 timeframe, but the sources lived on
bitbucket and are gone, apparently.  The author (Ivo Raisr) since left
Oracle and works for RedHat/Prague AFAICT.  However, reviving that port
even if the sources were available would be a major feat.

[Bug tree-optimization/109213] [13 Regression] -Os generates significantly more code since r13-723

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

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

--- Comment #8 from Jan Hubicka  ---
We have large-stack-frame-growth that is relative, so yes, increasing stack
size of caller makes gcc to think that it is heavy and making it event heavier
will not hurt that much.

We originally ran into stack size growth issues after implementing logic to
inline functions called once. In things like glibc printf where we ended up
inlining some exotic formater (as called once) that made the stack too large
for multithreaded apps.  Also sometimes we inlined some heavy function that is
off the hot path. While relative growth cap may not be best possible for all
cases, I can't think of reasonable way doing this better.

With the new code to determine basic blocks that are executed at every
execution of the function I plan to relax stack size limits a bit by bypassing
them when the call is known to be always allocated (and thus the stack will be
always taken)

This is also relatively common problem in Fortran where fortran IO (typically
done somewhere in debug code) tends to crate large on-stack structures
preventing inlining.

[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o

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

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

--- Comment #25 from Jakub Jelinek  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #24)
> > --- Comment #23 from Jakub Jelinek  ---
> [...]
> > Perhaps try to undo my patch in a different way, like
> > --- gcc/tree-inline.cc  2023-03-17 18:59:50.226199917 +0100
> > +++ gcc/tree-inline.cc  2023-03-29 12:47:21.546947442 +0200
> > @@ -2785,7 +2785,7 @@ initialize_cfun (tree new_fndecl, tree c
> >gimple_register_cfg_hooks ();
> >
> >/* Get clean struct function.  */
> > -  push_struct_function (new_fndecl, true);
> > +  push_struct_function (new_fndecl, false);
> >targetm.target_option.relayout_function (new_fndecl);
> >
> >/* We will rebuild these, so just sanity check that they are empty.  */
> > or
> > --- gcc/tree-inline.cc  2023-03-17 18:59:50.226199917 +0100
> > +++ gcc/tree-inline.cc  2023-03-29 12:49:16.580255668 +0200
> > @@ -2786,7 +2786,11 @@ initialize_cfun (tree new_fndecl, tree c
> >
> >/* Get clean struct function.  */
> >push_struct_function (new_fndecl, true);
> > +  relayout_decl (DECL_RESULT (new_fndecl));
> > +  for (tree parm = DECL_ARGUMENTS (new_fndecl); parm; parm = DECL_CHAIN
> > (parm))
> > +relayout_decl (parm);
> >targetm.target_option.relayout_function (new_fndecl);
> > +  aggregate_value_p (DECL_RESULT (new_fndecl), new_fndecl);
> >
> >/* We will rebuild these, so just sanity check that they are empty.  */
> >gcc_assert (VALUE_HISTOGRAMS (cfun) == NULL);
> > and see if that changes anything?  Of course both of those patches break the
> > PR105554
> > again.  Or if the latter helps, try to comment out the different parts of it
> > too.
> 
> So far, I've tried both variants and in each case, the comparison
> failure is gone.

Given that the reproducers weren't reliable, I'm afraid it would take at least
2-3
runs to get something that says something.
Anyway, as I said for the second version, it would be nice to also try
subvariants:
//  relayout_decl (DECL_RESULT (new_fndecl));
  for (tree parm = DECL_ARGUMENTS (new_fndecl); parm; parm = DECL_CHAIN (parm))
relayout_decl (parm);
  targetm.target_option.relayout_function (new_fndecl);
//  aggregate_value_p (DECL_RESULT (new_fndecl), new_fndecl);
and
  relayout_decl (DECL_RESULT (new_fndecl));
//  for (tree parm = DECL_ARGUMENTS (new_fndecl); parm; parm = DECL_CHAIN
(parm))
//relayout_decl (parm);
  targetm.target_option.relayout_function (new_fndecl);
//  aggregate_value_p (DECL_RESULT (new_fndecl), new_fndecl);
and
//  relayout_decl (DECL_RESULT (new_fndecl));
//  for (tree parm = DECL_ARGUMENTS (new_fndecl); parm; parm = DECL_CHAIN
(parm))
//relayout_decl (parm);
  targetm.target_option.relayout_function (new_fndecl);
  aggregate_value_p (DECL_RESULT (new_fndecl), new_fndecl);
so see if the comparison failure is fixed by the result relayout, or by
argument
relayout or by the aggregate_value_p call actually having some side-effects
other than return value.

[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o

[ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs]

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

--- Comment #26 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #25 from Jakub Jelinek  ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #24)
>> > --- Comment #23 from Jakub Jelinek  ---
>> [...]
>> So far, I've tried both variants and in each case, the comparison
>> failure is gone.
>
> Given that the reproducers weren't reliable, I'm afraid it would take at least
> 2-3
> runs to get something that says something.

indeed, even though so far following the exact same procedure has always
failed (or succeeded) in the same way.

> Anyway, as I said for the second version, it would be nice to also try
> subvariants:
[...]
> so see if the comparison failure is fixed by the result relayout, or by
> argument
> relayout or by the aggregate_value_p call actually having some side-effects
> other than return value.

I certainly plan to do so once the machine is idle again, probably tomorrow.

[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o

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

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

--- Comment #27 from Jakub Jelinek  ---
Thanks.  It is a mystery so far :(.

[Bug ipa/109303] [13 Regression] ICE in push_agg_values_from_plats, at ipa-cp.cc:1458 since r13-3358-ge0403e95689af7d5

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Slightly adjusted testcase:

struct __attribute__((packed)) A { char c1; short a1[__INT_MAX__]; };
struct __attribute__((packed)) B { char c2; short a2[100]; };
struct S { struct A p1; struct B p2[4]; };
void bar (short int);

static void
foo (struct S *q)
{
  for (int i = 0; i < q->p1.c1; i++)
for (int j = 0; j < q->p2[i].c2; j++)
  bar (q->p2[i].a2[j]);
}

int
main ()
{
  struct S q = {};
  q.p2[0].c2 = q.p2[1].c2 = 3;
  foo (&q);
}

[Bug c++/109283] Destructor of co_yield conditional argument called twice

[ncm at cantrip dot org via Gcc-bugs]

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

--- Comment #2 from ncm at cantrip dot org ---
Betting this one is fixed by deleting code.

[Bug tree-optimization/109331] [13 Regression] ice: definition in block 7 does not dominate use in block 8

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Target Milestone|--- |13.0
Summary|ice: definition in block 7  |[13 Regression] ice:
   |does not dominate use in|definition in block 7 does
   |block 8 |not dominate use in block 8

[Bug c/108896] provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds

[muecker at gwdg dot de via Gcc-bugs]

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

--- Comment #34 from Martin Uecker  ---
Created attachment 54787
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54787&action=edit
patch for C FE to add size expressions to VM types in structs


Here is a preliminary patch for C FE just to see how this could work
look like VM-types in structs.

struct foo {
  int n;
  int (*buf)[.n];
};

It works with UBSan, but it isn't clear how this could pass the
information to the object size pass. This also does not work for
parameters: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109334

So it seems for an attribute it might make sense to implement
it differently.

[Bug ipa/109303] [13 Regression] ICE in push_agg_values_from_plats, at ipa-cp.cc:1458 since r13-3358-ge0403e95689af7d5

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

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

--- Comment #3 from Jakub Jelinek  ---
And the problem is similar to PR108605, most of IPA uses unsigned int as type
for byte offsets and while some spots check for offsets while bit offsets are
typically using HOST_WIDE_INT.  So, some larger bit offsets can't be
represented in unsigned int byte offset.

[Bug modula2/109336] The -fmod= and -fdef= options do not work.

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Gaius Mulley :

https://gcc.gnu.org/g:3be4e43a6a0f429648ea188c8e110b74268fed27

commit r13-6931-g3be4e43a6a0f429648ea188c8e110b74268fed27
Author: Gaius Mulley 
Date:   Wed Mar 29 17:38:22 2023 +0100

PR modula2/109336 - The -fmod= and -fdef= options do not work

The -fmod= and -fdef= options do not work.  After the linking
re-implementation and subsequent restructuring the -fmod= amd -fdef= are
now broken.  This patch adds -fmod= and -fdef= processing into gm2spec.cc.
It also reduces the complexity of extension handling within M2Search
by storing the preceeding "." in the extension.

gcc/m2/ChangeLog:

PR modula2/109336
PR modula2/109315
* gm2-compiler/M2FileName.mod (CalculateFileName): Simplified by
ensuring the extension contains the ".".
(CalculateStemName): Re-formatted.
(ExtractExtension): Re-formatted.
(ExtractModule): Re-formatted.
* gm2-compiler/M2Options.def (setdefextension): Add block comment.
(setmodextension): Add block comment.  Re-formatted.
* gm2-compiler/M2Options.mod (setdefextension): Add block comment.
(setmodextension): Add block comment.  Re-formatted.
* gm2-compiler/M2Search.mod (FindSourceDefFile): Use
DefaultDefExt.
(DefaultDefExt): New constant.
(DefaultModExt): New constant.
(FindSourceModFile): Use DefaultModExt.
* gm2-gcc/m2decl.cc (m2decl_DeclareKnownVariable): Correct
spelling.
* gm2spec.cc (M2SOURCE): New constant.
(LANGSPEC): New value.
(MATHLIB): New value.
(WITHLIBC): New value.
(SKIPOPT): New value.
(lang_specific_driver): Replace seen_module_extension bool with
module_extension char *.  Detect -fmod= and remember extension.
Use the extension to detect modula-2 source and mark it as such.

gcc/testsuite/ChangeLog:

PR modula2/109336
* gm2/link/nondefaultext/pass/hello.md: New test.
* gm2/link/nondefaultext/pass/liba.dm: New test.
* gm2/link/nondefaultext/pass/liba.md: New test.
* gm2/link/nondefaultext/pass/link-nondefaultext-pass.exp: New
test.

Signed-off-by: Gaius Mulley 

[Bug modula2/109315] typo: inconsistant

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Gaius Mulley :

https://gcc.gnu.org/g:3be4e43a6a0f429648ea188c8e110b74268fed27

commit r13-6931-g3be4e43a6a0f429648ea188c8e110b74268fed27
Author: Gaius Mulley 
Date:   Wed Mar 29 17:38:22 2023 +0100

PR modula2/109336 - The -fmod= and -fdef= options do not work

The -fmod= and -fdef= options do not work.  After the linking
re-implementation and subsequent restructuring the -fmod= amd -fdef= are
now broken.  This patch adds -fmod= and -fdef= processing into gm2spec.cc.
It also reduces the complexity of extension handling within M2Search
by storing the preceeding "." in the extension.

gcc/m2/ChangeLog:

PR modula2/109336
PR modula2/109315
* gm2-compiler/M2FileName.mod (CalculateFileName): Simplified by
ensuring the extension contains the ".".
(CalculateStemName): Re-formatted.
(ExtractExtension): Re-formatted.
(ExtractModule): Re-formatted.
* gm2-compiler/M2Options.def (setdefextension): Add block comment.
(setmodextension): Add block comment.  Re-formatted.
* gm2-compiler/M2Options.mod (setdefextension): Add block comment.
(setmodextension): Add block comment.  Re-formatted.
* gm2-compiler/M2Search.mod (FindSourceDefFile): Use
DefaultDefExt.
(DefaultDefExt): New constant.
(DefaultModExt): New constant.
(FindSourceModFile): Use DefaultModExt.
* gm2-gcc/m2decl.cc (m2decl_DeclareKnownVariable): Correct
spelling.
* gm2spec.cc (M2SOURCE): New constant.
(LANGSPEC): New value.
(MATHLIB): New value.
(WITHLIBC): New value.
(SKIPOPT): New value.
(lang_specific_driver): Replace seen_module_extension bool with
module_extension char *.  Detect -fmod= and remember extension.
Use the extension to detect modula-2 source and mark it as such.

gcc/testsuite/ChangeLog:

PR modula2/109336
* gm2/link/nondefaultext/pass/hello.md: New test.
* gm2/link/nondefaultext/pass/liba.dm: New test.
* gm2/link/nondefaultext/pass/liba.md: New test.
* gm2/link/nondefaultext/pass/link-nondefaultext-pass.exp: New
test.

Signed-off-by: Gaius Mulley 

[Bug modula2/109315] typo: inconsistant

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

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

Gaius Mulley  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Gaius Mulley  ---
Closing as a patch has been applied.

[Bug ipa/109303] [13 Regression] ICE in push_agg_values_from_plats, at ipa-cp.cc:1458 since r13-3358-ge0403e95689af7d5

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

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

--- Comment #4 from Jakub Jelinek  ---
--- gcc/ipa-cp.cc.jj2023-03-14 19:12:19.949553036 +0100
+++ gcc/ipa-cp.cc   2023-03-29 18:32:34.14423 +0200
@@ -3117,7 +3117,9 @@ propagate_aggs_across_jump_function (str
{
  HOST_WIDE_INT val_size;

- if (item->offset < 0 || item->jftype == IPA_JF_UNKNOWN)
+ if (item->offset < 0
+ || item->jftype == IPA_JF_UNKNOWN
+ || item->offset >= (HOST_WIDE_INT) UINT_MAX * BITS_PER_UNIT)
continue;
  val_size = tree_to_shwi (TYPE_SIZE (item->type));

fixes the ICE and is then similar to the PR108605 fix.  Dunno if the code can
overflow also offset + size computations or something protects against that.
Anyway, I think it would be worth it to switch all those unsigned int byte
offsets to
unsigned HOST_WIDE_INTs for GCC 14.

[Bug modula2/109336] The -fmod= and -fdef= options do not work.

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

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

Gaius Mulley  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Gaius Mulley  ---
Closing as a patch has been applied.

[Bug c++/59498] [DR 1430][10/11/12/13 Regression] Pack expansion error in template alias

[ncm at cantrip dot org via Gcc-bugs]

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

--- Comment #22 from ncm at cantrip dot org ---
CWG 1430 seems to be about disallowing a construct that requires capturing an
alias declaration into a name mangling. This bug and at least some of those
referred to it do not ask for any such action.

[Bug fortran/109322] -fc-prototypes does not correctly translate INTEGER(KIND=C_SIZE_T), and other sizes

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Priority|P3  |P5
 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
You stated what you think gfortran ought to produce, but you
did not articulate a "why?"  What problem are you trying to fix?
The prototype generated by -fc-prototypes correspond to the C
companion processor, and may not be portable to other C processors
such as tinyC or bcc.

Also note, C_SIZE_T etc are simply named constants for kind
type parameters.   All of INTEGER, INTEGER(4), INTEGER(C_INT),
and INTEGER(C_INT32_t) have the same value of 4 for the default
integer kind on 32-bit architectures in the absence of any
command line option (such as -finteger-4-integer-8).

[Bug analyzer/107396] [13 regression] new test case gcc.dg/analyzer/pipe-glibc.c in r13-3466-g792f039fc37faa fails with excess errors

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
I think the difference is
https://sourceware.org/git/?p=glibc.git;a=commit;h=c1760eaf3b575ad174fd88b252fd16bd525fa818
which added __attribute__((malloc)) to fdopen among other things.
It is strange that it is reported just for fwrite and not for fgetc in the
other function though, both access potentially NULL stream.
Probably because {fwrite,putc,fputc,fputs}{,_unlocked} and printf family are
builtins and have nonnull attribute for the FILE * argument, but fgetc or fread
is not and glibc
doesn't use nonnull for those.

Shall we than use
2023-03-29  Jakub Jelinek  

PR analyzer/107396
* gcc.dg/analyzer/pipe-glibc.c (read_from_pie, write_to_pipe): Exit
if fdopen returns NULL.

--- gcc/testsuite/gcc.dg/analyzer/pipe-glibc.c.jj   2022-10-25
10:37:28.106531709 +0200
+++ gcc/testsuite/gcc.dg/analyzer/pipe-glibc.c  2023-03-29 19:14:48.789766475
+0200
@@ -13,6 +13,8 @@ read_from_pipe (int file)
   FILE *stream;
   int c;
   stream = fdopen (file, "r");
+  if (stream == NULL)
+exit (EXIT_FAILURE);
   while ((c = fgetc (stream)) != EOF)
 putchar (c);
   fclose (stream);
@@ -25,6 +27,8 @@ write_to_pipe (int file)
 {
   FILE *stream;
   stream = fdopen (file, "w");
+  if (stream == NULL)
+exit (EXIT_FAILURE);
   fprintf (stream, "hello, world!\n");
   fprintf (stream, "goodbye, world!\n");
   fclose (stream);
because this warning is not what the test wants to verify?

[Bug tree-optimization/91645] Missed optimization with sqrt(x*x)

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

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

--- Comment #9 from Aldy Hernandez  ---
It looks like what we want for this test is actually !isgreaterequal() not
isless(), since we want to exclude the possibility of a NAN.  Like this:

float test (float x)
{
  if (!__builtin_isgreaterequal (x, 0.0))
__builtin_unreachable();
  return sqrtf (x);
}

After VRP1 removes the unreachable, the range for x_1 is correctly exported as
>= -0.0 without a NAN:

Global Exported (via unreachable): x_1(D) = [frange] float [-0.0 (-0x0.0p+0),
+Inf]

We end up with this:

float test (float x)
{
  float _4;

   [local count: 1073741824]:
  _4 = sqrtf (x_1(D));
  return _4;

}

which then CDCE expands with the unnecessary checking code:

   [local count: 1073741824]:
  DCE_COND_LB.2_5 = x_1(D);
  DCE_COND_LB_TEST.3_6 = DCE_COND_LB.2_5 u>= 0.0;
  if (DCE_COND_LB_TEST.3_6 != 0)
goto ; [99.95%]
  else
goto ; [0.05%]

   [local count: 1073204960]:
  _4 = .SQRT (x_1(D));
  goto ; [100.00%]

   [local count: 536864]:
  _7 = sqrtf (x_1(D));

So the CDCE pass needs to be enhanced to use the ranger, instead of heuristics,
to determine that the argument to sqrtf is neither negative nor NAN.

In this particular case, we could use global ranges for free, but there's no
reason we can't use an actual on-demand ranger for more complex scenarios.

Just a guess here, but use_internal_fn() in CDCE shrink wraps the call to sqrt
into a check with appropriate dispatch.  We could emit the .SQRT call directly
if the range of x_1 is not NAN and not negative.

[Bug tree-optimization/103559] Can't optimize away < 0 check on sqrt

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

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

Aldy Hernandez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE
 CC||aldyh at gcc dot gnu.org

--- Comment #5 from Aldy Hernandez  ---
(In reply to Jeremy R. from comment #0)
> For a simple invocation of sqrt, gcc inserts a < 0 check to set math errno
> if needed. E.g.
> 
> float f(float x) {
> return sqrt(x);
> }
> 
> Is generated as
> 
> f(float):
> vxorps  xmm1, xmm1, xmm1
> vucomissxmm1, xmm0
> ja  .L10
> vsqrtss xmm0, xmm0, xmm0
> ret
> .L10:
> jmp sqrtf
> 
> 
> Unfortunately, this check is still present when the GCC is able to prove
> that x is non-negative:
> 
> float f(float x) {
> if(x < 0) [[unlikely]] {
> __builtin_unreachable();
> } else {
> return sqrt(x);
> }
> }

x could also be a NAN which I *think* the hardware sqrt won't handle, so a
better test would be:

if (x < 0.0 || __builtin_isnan(x)) [[unlikely]]
  __builtin_unreachable ();

or perhaps:

if (!__builtin_isgreater(x, 0.0))

Either way, this is a subset of PR91645 so I'm closing it as a duplicate.

*** This bug has been marked as a duplicate of bug 91645 ***

[Bug tree-optimization/91645] Missed optimization with sqrt(x*x)

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

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

Aldy Hernandez  changed:

   What|Removed |Added

 CC||llvm at rifkin dot dev

--- Comment #10 from Aldy Hernandez  ---
*** Bug 103559 has been marked as a duplicate of this bug. ***

[Bug fortran/109322] -fc-prototypes does not correctly translate INTEGER(KIND=C_SIZE_T), and other sizes

[emr-gnu at hev dot psu.edu via Gcc-bugs]

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

--- Comment #2 from Eric Reischer  ---
I can't point to a specific standard that says, "thou shalt generate output
with these types..."; it's more of a "we probably should be doing this"-type
thing.  If you are compiling Fortran and C on the same system with the same
compiler suite, this is a non-issue.  However, if you are, say, creating an API
that has autogenerated files redistributed (e.g., a base Fortran package and
then autogenerated and distributed C/C++ header files), the types generated
using -fc-prototypes are not safely transportable to another compiler with the
requested variable sizes.

This is probably better demonstrated with another example:

Extending my original demonstrator, if you add a "INTEGER(KIND=C_INT64_T) ::
E", you get the following output:

> gfortran -m32 -fc-prototypes -fsyntax-only foo.f90

 long a;
 {...}
 long_long e;
} bar;

---

In the above, "long_long" is nonstandard and not recognized by most compilers
(it was apparently implemented in some locations as a workaround to a problem
on Windows with gcc compatibility).

What's worse, is if you run the above in 64-bit mode on x86 Linux, you get:

> gfortran -m64 -fc-prototypes -fsyntax-only foo.f90
 long a;
 {...}
 long e;
} bar;

---

This is most definitely wrong -- "long" will be 64 bits on Linux, but only 32
bits on Windows, so the size type emitted is ambiguous.  Additionally, the
structures will no longer be interoperable, because (again, on Windows) in
C/C++ you'll get a variable "E" that will only store 32 bits, whereas in
Fortran the corresponding variable will be 64 bits, thus offsetting every
variable that comes after it. Probably better to be safe (and definitely more
portable) to leave translation of the types to when the C/C++ files are
actually compiled (which may not be with gcc) by using the stdint.h types.

I will stipulate that, yes, int64_t is not *guaranteed* to be exactly 64 bits,
and size_t is not *guaranteed* to be 32 or 64 bits (based on what architecture
you're running).  But preserving the explicitly-specified data types across the
language translation is the point here.  An entirely separate argument could be
had for INTEGER*4, INTEGER*8, etc., but in this case, since you're explicitly
requesting C_INTxx_T, you're getting something else entirely out of the
prototype-generation subsystem.

[Bug analyzer/106573] Missing -Wanalyzer-use-of-uninitialized-value on calls handled by state machines

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

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-12 branch has been updated by David Malcolm
:

https://gcc.gnu.org/g:62a565e56763c65ec9e134735aa780cf2b1c3cfa

commit r12-9354-g62a565e56763c65ec9e134735aa780cf2b1c3cfa
Author: David Malcolm 
Date:   Wed Mar 29 14:16:46 2023 -0400

analyzer: fix missing -Wanalyzer-use-of-uninitialized-value on
special-cased functions [PR106573]

We were missing checks for uninitialized params on calls to functions
that the analyzer has hardcoded knowledge of - both for those that are
handled just by state machines, and for those that are handled in
region-model-impl-calls.cc (for those arguments for which the svalue
wasn't accessed in handling the call).

Fixed thusly.

Backported from r13-2007-gbddd8d86e3036e, dropping the test case
fd-uninit-1.c.

gcc/analyzer/ChangeLog:
PR analyzer/106573
* region-model.cc (region_model::on_call_pre): Ensure that we call
get_arg_svalue on all arguments.

gcc/testsuite/ChangeLog:
PR analyzer/106573
* gcc.dg/analyzer/error-uninit.c: New test.
* gcc.dg/analyzer/file-uninit-1.c: New test.

Signed-off-by: David Malcolm 

[Bug analyzer/106573] Missing -Wanalyzer-use-of-uninitialized-value on calls handled by state machines

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

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-12 branch has been updated by David Malcolm
:

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

commit r12-9355-gc63e5a234d0193e1f41024cf0eee840998e04c7f
Author: David Malcolm 
Date:   Wed Mar 29 14:16:46 2023 -0400

analyzer: better fix for -Wanalyzer-use-of-uninitialized-value [PR106573]

Cherrypicked from r13-2053-gca123e019bb92f.

gcc/analyzer/ChangeLog:
PR analyzer/106573
* region-model.cc (region_model::on_call_pre): Use check_call_args
when ensuring that we call get_arg_svalue on all args.  Remove
redundant call from handling for stdio builtins.

Signed-off-by: David Malcolm 

[Bug analyzer/107345] -Wanalyzer-null-dereference false positive with giving weird path infomation

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

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-12 branch has been updated by David Malcolm
:

https://gcc.gnu.org/g:111fb5d3cafd0f7f2a0d01aa9e1213013fa0cc83

commit r12-9357-g111fb5d3cafd0f7f2a0d01aa9e1213013fa0cc83
Author: David Malcolm 
Date:   Wed Mar 29 14:16:47 2023 -0400

analyzer: handle (NULL == &VAR) [PR107345]

Cherrypicked from r13-3468-g18faaeb3af42f3.

gcc/analyzer/ChangeLog:
PR analyzer/107345
* region-model.cc (region_model::eval_condition_without_cm):
Ensure that constants are on the right-hand side before checking
for them.

gcc/testsuite/ChangeLog:
PR analyzer/107345
* gcc.dg/analyzer/pr107345.c: New test.

Signed-off-by: David Malcolm 

[Bug analyzer/107582] - -Wanalyzer-use-of-uninitialized-value false positive with while loop in pthread_cleanup_push

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

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

--- Comment #11 from CVS Commits  ---
The releases/gcc-12 branch has been updated by David Malcolm
:

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

commit r12-9358-ge7f7483d50069fede8450091449714d122c58fca
Author: David Malcolm 
Date:   Wed Mar 29 14:16:47 2023 -0400

analyzer: fix feasibility false +ve on jumps through function ptrs
[PR107582]

PR analyzer/107582 reports a false +ve from
-Wanalyzer-use-of-uninitialized-value where
the analyzer's feasibility checker erroneously decides
that point (B) in the code below is reachable, with "x" being
uninitialized there:

pthread_cleanup_push(func, NULL);

while (ret != ETIMEDOUT)
ret = rand() % 1000;

/* (A): after the while loop  */

if (ret != ETIMEDOUT)
  x = &z;

pthread_cleanup_pop(1);

if (ret == ETIMEDOUT)
  return 0;

/* (B): after not bailing out  */

due to these contradictionary conditions somehow both holding:
  * (ret == ETIMEDOUT), at (A) (skipping the initialization of x), and
  * (ret != ETIMEDOUT), at (B)

The root cause is that after the while loop, state merger puts ret in
the exploded graph in an UNKNOWN state, and saves the diagnostic at (B).

Later, as we explore the feasibilty of reaching the enode for (B),
dynamic_call_info_t::update_model is called to push/pop the
frames for handling the call to "func" in pthread_cleanup_pop.
The "ret" at these nodes in the feasible_graph has a conjured_svalue for
"ret", and a constraint on it being either == *or* != ETIMEDOUT.

However dynamic_call_info_t::update_model blithely clobbers the
model with a copy from the exploded_graph, in which "ret" is UNKNOWN.

This patch fixes dynamic_call_info_t::update_model so that it
simulates pushing/popping a frame on the model we're working with,
preserving knowledge of the constraint on "ret", and enabling the
analyzer to "know" that the bail-out must happen.

Doing so fixes the false positive.

Cherrypicked from r13-4158-ga7aef0a5a2b7e2.

gcc/analyzer/ChangeLog:
PR analyzer/107582
* engine.cc (dynamic_call_info_t::update_model): Update the model
by pushing or pop a frame, rather than by clobbering it with the
model from the exploded_node's state.

gcc/testsuite/ChangeLog:
PR analyzer/107582
* gcc.dg/analyzer/feasibility-4.c: New test.
* gcc.dg/analyzer/feasibility-pr107582-1.c: New test.
* gcc.dg/analyzer/feasibility-pr107582-2.c: New test.

Signed-off-by: David Malcolm 

[Bug analyzer/105784] -Wanalyzer-use-of-uninitialized-value false positive on partly initialized array

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

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-12 branch has been updated by David Malcolm
:

https://gcc.gnu.org/g:1c66f1c6d69dbe0a855f7adb61df8d92ca523899

commit r12-9359-g1c66f1c6d69dbe0a855f7adb61df8d92ca523899
Author: David Malcolm 
Date:   Wed Mar 29 14:16:47 2023 -0400

analyzer: fix folding of '(PTR + 0) => PTR' [PR105784]

Cherrypicked from r13-4398-g3a32fb2eaa761a.

gcc/analyzer/ChangeLog:
PR analyzer/105784
* region-model-manager.cc
(region_model_manager::maybe_fold_binop): For POINTER_PLUS_EXPR,
PLUS_EXPR and MINUS_EXPR, eliminate requirement that the final
type matches that of arg0 in favor of a cast.

gcc/testsuite/ChangeLog:
PR analyzer/105784
* gcc.dg/analyzer/torture/fold-ptr-arith-pr105784.c: New test.

Signed-off-by: David Malcolm 

[Bug analyzer/108704] Many -Wanalyzer-use-of-uninitialized-value false positives seen in qemu's softfloat.c

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

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-12 branch has been updated by David Malcolm
:

https://gcc.gnu.org/g:5da2126c4df8d83c2b2f9de7bb393ab4f5832840

commit r12-9364-g5da2126c4df8d83c2b2f9de7bb393ab4f5832840
Author: David Malcolm 
Date:   Wed Mar 29 14:16:48 2023 -0400

analyzer: fix overzealous state purging with on-stack structs [PR108704]

PR analyzer/108704 reports many false positives seen from
-Wanalyzer-use-of-uninitialized-value on qemu's softfloat.c on code like
the following:

   struct st s;
   s = foo ();
   s = bar (s); // bogusly reports that s is uninitialized here

where e.g. "struct st" is "floatx80" in the qemu examples.

The root cause is overzealous purging of on-stack structs in the code I
added in r12-7718-gfaacafd2306ad7, where at:

s = bar (s);

state_purge_per_decl::process_point_backwards "sees" the assignment to 's'
and stops processing, effectively treating 's' as unneeded before this
stmt, not noticing the use of 's' in the argument.

Fixed thusly.

The patch greatly reduces the number of
-Wanalyzer-use-of-uninitialized-value warnings from my integration tests:
  ImageMagick-7.1.0-57:  10 ->  6   (-4)
  qemu-7.2: 858 -> 87 (-771)
 haproxy-2.7.1:   1 ->  0   (-1)
All of the above that I've examined appear to be false positives.

Cherrypicked from r13-5745-g77bb54b1b07add.

gcc/analyzer/ChangeLog:
PR analyzer/108704
* state-purge.cc (state_purge_per_decl::process_point_backwards):
Don't stop processing the decl if it's fully overwritten by
this stmt if it's also used by this stmt.

gcc/testsuite/ChangeLog:
PR analyzer/108704
* gcc.dg/analyzer/uninit-7.c: New test.
* gcc.dg/analyzer/uninit-pr108704.c: New test.

Signed-off-by: David Malcolm 

[Bug analyzer/107948] GCC Static Analyzer doesn't realize `0 - width <= 0` is always true when `width > 0` and `width is int` type，

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

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-12 branch has been updated by David Malcolm
:

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

commit r12-9360-ga7cc8ecefb72f06368b055fa60f5a2ff2eb6dfdb
Author: David Malcolm 
Date:   Wed Mar 29 14:16:48 2023 -0400

analyzer: handle comparisons against negated symbolic values [PR107948]

Cherrypicked from r13-4456-g0b737090a69624.

gcc/analyzer/ChangeLog:
PR analyzer/107948
* region-model-manager.cc
(region_model_manager::maybe_fold_binop): Fold (0 - VAL) to -VAL.
* region-model.cc (region_model::eval_condition): Handle e.g.
"-X <= 0" as equivalent to X >= 0".

gcc/testsuite/ChangeLog:
PR analyzer/107948
* gcc.dg/analyzer/feasibility-pr107948.c: New test.

Signed-off-by: David Malcolm 

[Bug analyzer/108968] fanalyzer false positive with the uninitalised-ness of the stack pointer

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

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

--- Comment #19 from CVS Commits  ---
The releases/gcc-12 branch has been updated by David Malcolm
:

https://gcc.gnu.org/g:833d822ff0e83478a4fe536d55dfb22cde8ddc40

commit r12-9366-g833d822ff0e83478a4fe536d55dfb22cde8ddc40
Author: David Malcolm 
Date:   Wed Mar 29 14:16:49 2023 -0400

analyzer: fix uninit false +ves reading from DECL_HARD_REGISTER [PR108968]

Cherrypicked from r13-6749-g430d7d88c1a123.

gcc/analyzer/ChangeLog:
PR analyzer/108968
* region-model.cc (region_model::get_rvalue_1): Handle VAR_DECLs
with a DECL_HARD_REGISTER by returning UNKNOWN.

gcc/testsuite/ChangeLog:
PR analyzer/108968
* gcc.dg/analyzer/uninit-pr108968-register.c: New test.

Signed-off-by: David Malcolm 

[Bug analyzer/106325] -Wanalyzer-null-dereference false positive due to analyzer not making assumptions for `__attribute__((nonnull))`

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

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

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

https://gcc.gnu.org/g:02fbda165b74179469d9eae436fed613aa6a6ebb

commit r12-9362-g02fbda165b74179469d9eae436fed613aa6a6ebb
Author: David Malcolm 
Date:   Wed Mar 29 14:16:48 2023 -0400

analyzer: use __attribute__((nonnull)) at top level of analysis [PR106325]

PR analyzer/106325 reports false postives from
-Wanalyzer-null-dereference on code like this:

__attribute__((nonnull))
void foo_a (Foo *p)
{
  foo_b (p);

  switch (p->type)
{
  /* ... */
}
}

where foo_b (p) has a:

  g_return_if_fail (p);

that expands to:

  if (!p)
{
  return;
}

The analyzer "sees" the comparison against NULL in foo_b, and splits the
analysis into the NULL and not-NULL cases; later, back in foo_a,  at
  switch (p->type)
it complains that p is NULL.

Previously we were only using __attribute__((nonnull)) as something to
complain about when it was violated; we weren't using it as a source of
knowledge.

This patch fixes things by making the analyzer respect
__attribute__((nonnull)) at the top-level of the analysis: any such
params are now assumed to be non-NULL, so that the analyzer assumes the
g_return_if_fail inside foo_b doesn't fail when called from foo_a

Doing so fixes the false positives.

Backported from r13-4520-gdcfc7ac94dbcf6.

gcc/analyzer/ChangeLog:
PR analyzer/106325
* region-model-manager.cc
(region_model_manager::get_or_create_null_ptr): New.
* region-model.cc (region_model::on_top_level_param): Add
"nonnull" param and make use of it.
(region_model::push_frame): When handling a top-level entrypoint
to the analysis, determine which params __attribute__((nonnull))
applies to, and pass to on_top_level_param.
* region-model.h (region_model_manager::get_or_create_null_ptr):
New decl.
(region_model::on_top_level_param): Add "nonnull" param.

gcc/testsuite/ChangeLog:
PR analyzer/106325
* gcc.dg/analyzer/attr-nonnull-pr106325.c: New test.
* gcc.dg/analyzer/attribute-nonnull.c (test_6): New.
(test_7): New.

Signed-off-by: David Malcolm 

[Bug analyzer/108733] -Wanalyzer-use-of-uninitialized-value false positives seen with __attribute__((cleanup))

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

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-12 branch has been updated by David Malcolm
:

https://gcc.gnu.org/g:98558117ba870d47398927f2066e469e47f39c16

commit r12-9365-g98558117ba870d47398927f2066e469e47f39c16
Author: David Malcolm 
Date:   Wed Mar 29 14:16:49 2023 -0400

analyzer: fix further overzealous state purging [PR108733]

PR analyzer/108733 reports various false positives in qemu from
-Wanalyzer-use-of-uninitialized-value with __attribute__((cleanup))
at -O1 and above.

Root cause is that the state-purging code was failing to treat:
   _25 = MEM[(void * *)&val];
as a usage of "val", leading to it erroneously purging the
initialization of "val" along an execution path that didn't otherwise
use "val", apart from the  __attribute__((cleanup)).

Fixed thusly.

Integration testing on the patch show this change in the number of
diagnostics:
  -Wanalyzer-use-of-uninitialized-value
   coreutils-9.1: 18 -> 16 (-2)
  qemu-7.2.0: 87 -> 80 (-7)
where all that I investigated appear to have been false positives, hence
an improvement.

Cherrypicked from r13-5745-g77bb54b1b07add.

gcc/analyzer/ChangeLog:
PR analyzer/108733
* state-purge.cc (get_candidate_for_purging): Add ADDR_EXPR
and MEM_REF.

gcc/testsuite/ChangeLog:
PR analyzer/108733
* gcc.dg/analyzer/torture/uninit-pr108733.c: New test.

Signed-off-by: David Malcolm 

[Bug target/109328] [13 Regression] Build fail in RISC-V port

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

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

--- Comment #3 from Andrew Pinski  ---
Created attachment 54788
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54788&action=edit
Patch which improves the depedencies

Note I am not 100% sure this is all the way. But you should get the idea and
take it over from there.

[Bug analyzer/109094] Uninit false positive from -fanalyzer when longjmp unwinds frames with return stmts

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

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

--- Comment #11 from CVS Commits  ---
The releases/gcc-12 branch has been updated by David Malcolm
:

https://gcc.gnu.org/g:7903e0bca003840751c109cfa41e5a1528ece12a

commit r12-9367-g7903e0bca003840751c109cfa41e5a1528ece12a
Author: David Malcolm 
Date:   Wed Mar 29 14:16:49 2023 -0400

analyzer: fix ICE on certain longjmp calls [PR109094]

PR analyzer/109094 reports an ICE in the analyzer seen on qemu's
target/i386/tcg/translate.c

The issue turned out to be that when handling a longjmp, the code
to pop the frames was generating an svalue for the result_decl of any
popped frame that had a non-void return type (and discarding it) leading
to "uninit" poisoned_svalue_diagnostic instances being saved since the
result_decl is only set by the greturn stmt.  Later, when checking the
feasibility of the path to these diagnostics, m_check_expr was evaluated
in the context of the frame of the longjmp, leading to an attempt to
evaluate the result_decl of each intervening frames whilst in the
context of the topmost frame, leading to an assertion failure in
frame_region::get_region_for_local here:

919 case RESULT_DECL:
920   gcc_assert (DECL_CONTEXT (expr) == m_fun->decl);
921   break;

This patch updates the analyzer's longjmp implementation so that it
doesn't attempt to generate svalues for the result_decls when popping
frames, fixing the assertion failure (and presumably fixing "uninit"
false positives in a release build).

Cherrypicked from r13-6749-g430d7d88c1a123.

gcc/analyzer/ChangeLog:
PR analyzer/109094
* region-model.cc (region_model::on_longjmp): Pass false for
new "eval_return_svalue" param of pop_frame.
(region_model::pop_frame): Add new "eval_return_svalue" param and
use it to suppress the call to get_rvalue on the result when
needed by on_longjmp.
* region-model.h (region_model::pop_frame): Add new
"eval_return_svalue" param.

gcc/testsuite/ChangeLog:
PR analyzer/109094
* gcc.dg/analyzer/setjmp-pr109094.c: New test.

Signed-off-by: David Malcolm 

[Bug target/109328] [13 Regression] Build fail in RISC-V port

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
Summary|Build fail in RISC-V port   |[13 Regression] Build fail
   ||in RISC-V port
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-03-29

--- Comment #2 from Andrew Pinski  ---
Confirmed there are a few missing dependencies.

[Bug tree-optimization/103559] Can't optimize away < 0 check on sqrt

[llvm at rifkin dot dev via Gcc-bugs]

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

--- Comment #6 from Jeremy R.  ---
Thanks!

[Bug tree-optimization/103559] Can't optimize away < 0 check on sqrt

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
The HW sqrt certainly handles NAN input by returning NAN output, the question
is if it is required to set some errno in that case as well or not.  One would
need to check what different libcs do in that case.

[Bug c++/109337] New: c++2a test concepts4.C passes when it should fail

[cjdb.ns at gmail dot com via Gcc-bugs]

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

Bug ID: 109337
   Summary: c++2a test concepts4.C passes when it should fail
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cjdb.ns at gmail dot com
  Target Milestone: ---

Clang and GCC disagree on the validity of concepts4.C. I think Clang is correct
here, because forming a reference to `void` should be ill-formed.

https://godbolt.org/z/es5GxYhzd

[Bug c++/109337] c++2a test concepts4.C passes when it should fail

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-03-29
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Confirmed.

Changing R42c to be a bool rather than a concept causes GCC to catch the
failure ...

That is:
```
template  struct A { static const int x = 42; };

template  concept A42 = A::x == 42;
template  concept Void = __is_same_as(Tv, void);
template  concept A42b = Void || A42;
template  bool R42c = A42b;

static_assert (R42c);
```

[Bug c++/109338] New: `S auto>` isn't valid C++20

[cjdb.ns at gmail dot com via Gcc-bugs]

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

Bug ID: 109338
   Summary: `S auto>` isn't valid C++20
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cjdb.ns at gmail dot com
  Target Milestone: ---

Clang and GCC disagree on whether or not this code is valid. This **may** be a
relic from the Concepts TS, which Clang doesn't implement.

https://godbolt.org/z/c7rGWE9s6

[Bug c++/109337] c++2a test concepts4.C passes when it should fail

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

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

--- Comment #2 from Andrew Pinski  ---
Reduced testcase:
```
template  concept A42b = true;
template  concept R42c = A42b;

static_assert (R42c);
```


GCC does the right thing for too:
```
template  bool A42b = true;
template  concept R42c = A42b;

static_assert (!R42c);
```

[Bug c++/100248] ICE with global "default" keyword

[arthur.j.odwyer at gmail dot com via Gcc-bugs]

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

Arthur O'Dwyer  changed:

   What|Removed |Added

 CC||arthur.j.odwyer at gmail dot 
com

--- Comment #3 from Arthur O'Dwyer  ---
Bug 107321 and bug 105202 are duplicates.
In bug 107321, Martin Liška writes: "Started with r10-4397-gb7689b962dd6536b."

[Bug c++/109338] `S auto>` isn't valid C++20

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

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

--- Comment #1 from Andrew Pinski  ---
Testcase:
```
template 
concept C = true;

template 
struct A {};

void f(A auto >) {}

```
Please place the testcase in the comment or attach it; don't just link to
godbolt.

[Bug c++/109337] c++2a test concepts4.C passes when it should fail

[cjdb.ns at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Christopher Di Bella  ---
This is apparently a Clang bug: the RHS of `R42c` isn't evaluated because of
short-circuiting. Apologies for the noise and thanks for helping me work
through it.

[Bug c++/109337] c++2a test concepts4.C passes when it should fail

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|NEW |RESOLVED

--- Comment #4 from Andrew Pinski  ---
invalid as noticed.

[Bug c++/109337] c++2a test concepts4.C passes when it should fail

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|RESOLVED|NEW
 Resolution|INVALID |---

--- Comment #5 from Andrew Pinski  ---
(In reply to Christopher Di Bella from comment #3)
> This is apparently a Clang bug: the RHS of `R42c` isn't evaluated because of
> short-circuiting. Apologies for the noise and thanks for helping me work
> through it.

No, clang and GCC disagree even on:
```
template  concept A42b = true;
template  concept R42c = A42b;

static_assert (R42c);
```

There is no short-circuting here.

[Bug analyzer/109094] Uninit false positive from -fanalyzer when longjmp unwinds frames with return stmts

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

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

David Malcolm  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #12 from David Malcolm  ---
Fixed for gcc 12 by the above commit; marking as resolved.

[Bug analyzer/105784] -Wanalyzer-use-of-uninitialized-value false positive on partly initialized array

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

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

David Malcolm  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #4 from David Malcolm  ---
Should be fixed on gcc 12 branch by the above; marking as resolved.

[Bug analyzer/107345] -Wanalyzer-null-dereference false positive with giving weird path infomation

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

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

David Malcolm  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #7 from David Malcolm  ---
Should be fixed on gcc 12 branch by the above (for the eventual gcc 12.3
release);  marking as resolved.

[Bug analyzer/108562] [meta-bug] tracker bug for issues with -Wanalyzer-null-dereference

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

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

Bug 107345 Summary: -Wanalyzer-null-dereference false positive with  giving 
weird path infomation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107345

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug analyzer/107582] - -Wanalyzer-use-of-uninitialized-value false positive with while loop in pthread_cleanup_push

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

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

David Malcolm  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #12 from David Malcolm  ---
Should be fixed on gcc 12 branch by the above (for the eventual gcc 12.3
release); marking as resolved.