[Bug c/84764] Wrong warning "so large that it is unsigned" for __int128 constant

[daniel.lundin.mail at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Daniel Lundin  ---
Call it what you will, either way there is nothing here that's "so large that
it is unsigned". The main point is that the diagnostic message is wrong.

typeof(18446744073709551615) x = -1;

Gives a 128 bit integer type with the value -1. If it was "so large that it is
unsigned" then this would have resulted in an unsigned type with an unsigned
value. The diagnostic message is plain wrong and misleading.

[Bug tree-optimization/108547] [13 Regression] ice in decompose, at wide-int.h:984 for -O2 with -Wall

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #6 from Richard Biener  ---
I will have a look.

[Bug fortran/108546] [11/12/13 Regression] ICE in expand_expr_real_1, at expr.cc:10910

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.4

[Bug fortran/108545] [13 Regression] ICE in install_var_field, at omp-low.cc:799

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug c++/108542] [13 Regression] ICE in instantiate_type, at cp/class.cc:8833

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug tree-optimization/108523] [13 Regression] -O1 -fcode-hoisting causes long compilation time ?

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/108523] [13 Regression] -O1 -fcode-hoisting causes long compilation time ?

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

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

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

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

commit r13-5378-g1f6d05e9ad858b59b824f57d09400adcb2c5e4ad
Author: Richard Biener 
Date:   Thu Jan 26 08:38:35 2023 +0100

tree-optimization/108523 - testcase for the bug

This adds a reduced testcase for the PR.

PR tree-optimization/108523
* gcc.dg/torture/pr108523.c: New testcase.

[Bug modula2/108551] gcc/m2/gm2-libs-pim/Termbase.mod:128:1: error: control reaches end of non-void function [-Werror=return-type]

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||build, diagnostic

--- Comment #1 from Richard Biener  ---
The function is

PROCEDURE KeyPressed () : BOOLEAN ;
BEGIN
   IF rStack=NIL
   THEN
  Halt(__FILE__, __LINE__, __FUNCTION__, 'no active status procedure')
   ELSE
  RETURN( rStack^.s() )
   END
END KeyPressed ;


I'm not sure how the middle-end diagnostic issued from CFG build is confused
here though, I'm not yet familiar with using cc1gm2 to debug things, nor
produce standalone modula-2 testcases ;)

It also means people might see bogus diagnostics for code like this.

[Bug modula2/108551] New: gcc/m2/gm2-libs-pim/Termbase.mod:128:1: error: control reaches end of non-void function [-Werror=return-type]

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

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

Bug ID: 108551
   Summary: gcc/m2/gm2-libs-pim/Termbase.mod:128:1: error: control
reaches end of non-void function [-Werror=return-type]
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: modula2
  Assignee: gaius at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

We see a build failure with -Werror=return-type (injected from our
RPM_OPT_FLAGS) when building modula2 target libs:

[ 8737s] libtool: compile: 
/home/abuild/rpmbuild/BUILD/gcc-13.0.1+git5374/obj-i586-suse-linux/./gcc/gm2
-B/home/abuild/rpmbuild/BUILD/gcc-13.0.1+git5374/obj-i586-suse-linux/./gcc/ -c
-g -fomit-frame-pointer -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3
-funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection
-Werror=return-type -U_FORTIFY_SOURCE -g -fomit-frame-pointer -O2
-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -funwind-tables
-fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type
-U_FORTIFY_SOURCE -I../libm2pim
-I/home/abuild/rpmbuild/BUILD/gcc-13.0.1+git5374/gcc/m2/gm2-libs-pim
-I/home/abuild/rpmbuild/BUILD/gcc-13.0.1+git5374/gcc/m2/gm2-libs
-I/home/abuild/rpmbuild/BUILD/gcc-13.0.1+git5374/gcc/m2/gm2-libs-iso
../../../../libgm2/libm2log/../../gcc/m2/gm2-libs-pim/Termbase.mod  -fPIC -DPIC
-o .libs/Termbase.o
[ 8737s] ../../../../libgm2/libm2log/../../gcc/m2/gm2-libs-pim/Termbase.mod: In
function 'Termbase_KeyPressed':
[ 8737s]
../../../../libgm2/libm2log/../../gcc/m2/gm2-libs-pim/Termbase.mod:128:1:
error: control reaches end of non-void function [-Werror=return-type]
[ 8737s]   128 | END KeyPressed ;
[ 8737s]   | ^~~
[ 8737s] cc1gm2: some warnings being treated as errors
[ 8737s] make[5]: *** [Makefile:782: Termbase.lo] Error 1

[Bug other/108549] [12 regression] gcc.dg/pr107554.c fails for 32 bits after r12-9062-gca8b8191983d1a

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
I cherry-picked r13-3951-ge7ebdf51ea514a.

[Bug tree-optimization/108523] [13 Regression] -O1 -fcode-hoisting causes long compilation time ?

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords|needs-reduction |

--- Comment #17 from Richard Biener  ---
Thanks a lot!

[Bug tree-optimization/107952] tree-object-size: inconsistent size for flexible arrays nested in structs

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

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

--- Comment #18 from Richard Biener  ---
(In reply to Qing Zhao from comment #15)
> > On Jan 25, 2023, at 11:12 AM, siddhesh at gcc dot gnu.org 
> >  wrote:
> >> 
> >>> The first is handled by the function just fine,
> >> 
> >> No, even the first case is not recognized by the current
> >> “array_ref_flexible_size_p”, it’s not been identified as a flexible array
> >> right now.
> >> Shall we include this case into “array_ref_flexible_size_p”?  (It’s a GCC
> >> extension).
> > 
> > In the first case, array_ref_flexible_size_p recognizes S2.flex.data as 
> > having
> > flexible size.  The tests in my patch[1] for this bug checks for this.
> Oh, yes. That’s right.
> > 
> > However, array_ref_flexible_size_p does not recognize S2.flex as having
> > flexible size.  It might make sense to support that, i.e. any struct or 
> > union
> > with the last element as a flex array should be recognized as having 
> > flexible
> > size.
> 
> Since S2.flex is not an “array_ref”, it’s correct for
> array_ref_fleixble_size_p to return false for it, I think. 

Yes, that's correct.

The routine is supposed to answer if an actual _access_ is to a flexible
size part.  The whole aggregate is not part of a flexible size part here.

tree-object-size usually wants to know if a pointer points to an object
with flexible size which is really something different and might not
share much with the logic in array_ref_fleixble_size_p

[Bug c++/87512] Error: the type ‘const auto’ of ‘constexpr’ variable is not literal

[coyorkdow at outlook dot com via Gcc-bugs]

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

--- Comment #9 from Guo Youtao  ---
(In reply to Jonathan Wakely from comment #8)
> Yes please

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

[Bug c++/108550] New: the type 'const auto' of 'constexpr' variable is not literal

[coyorkdow at outlook dot com via Gcc-bugs]

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

Bug ID: 108550
   Summary: the type 'const auto' of 'constexpr' variable is not
literal
   Product: gcc
   Version: 11.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: coyorkdow at outlook dot com
  Target Milestone: ---

Created attachment 54344
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54344&action=edit
generated by `-save-temps`

This bug can be triggered in gcc-11 and gcc-12. (I don't have gcc-13 so I
didn't try.)

Here are the codes (the preprocessed file is attached)
```
#include 
#include 

template 
constexpr auto is_pointer_v = std::is_pointer::value;

template 
auto Wrap1(int) -> std::integral_constant().operator->())>>;

template 
auto Wrap1(...) -> std::is_pointer;

int main() {
  static_assert(!is_pointer_v>); // this line can compile
  static_assert(decltype(Wrap1>(0))::value); // error
  return 0;
}
```

The err msgs
```
% g++-11 a.cc -save-temps
a.cc: In instantiation of 'constexpr const auto is_pointer_v':
a.cc:8:49:   required by substitution of 'template > std::integral_constant().operator->())> > Wrap1(int) [with Tp =
std::unique_ptr; decltype (& Tp::operator*)*  = ]'
a.cc:15:53:   required from here
a.cc:5:16: error: the type 'const auto' of 'constexpr' variable
'is_pointer_v' is not literal
5 | constexpr auto is_pointer_v = std::is_pointer::value;
  |^~~~
a.cc:5:16: error: 'const auto is_pointer_v' has incomplete type
a.cc: In function 'int main()':
a.cc:15:59: error: static assertion failed
   15 |   static_assert(decltype(Wrap1>(0))::value); //
this line incurs error
  | ~~^
```


GCC version:
```
% gcc-11 -v
Using built-in specs.
COLLECT_GCC=gcc-11
COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc/11.3.0_2/bin/../libexec/gcc/x86_64-apple-darwin21/11/lto-wrapper
Target: x86_64-apple-darwin21
Configured with: ../configure --prefix=/usr/local/opt/gcc
--libdir=/usr/local/opt/gcc/lib/gcc/11 --disable-nls --enable-checking=release
--with-gcc-major-version-only --enable-languages=c,c++,objc,obj-c++,fortran,d
--program-suffix=-11 --with-gmp=/usr/local/opt/gmp
--with-mpfr=/usr/local/opt/mpfr --with-mpc=/usr/local/opt/libmpc
--with-isl=/usr/local/opt/isl --with-zstd=/usr/local/opt/zstd
--with-pkgversion='Homebrew GCC 11.3.0_2'
--with-bugurl=https://github.com/Homebrew/homebrew-core/issues
--enable-libphobos --build=x86_64-apple-darwin21 --with-system-zlib
--with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.3.0 (Homebrew GCC 11.3.0_2)
```

If remove the parameter `decltype(&Tp::operator*)* = nullptr` then codes can be
compiled. Other parameter like `class =
std::enable_if_t::value>` can also trigger.

The error also happens in gcc-12.

There is another similar but unrelated bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87512

[Bug fortran/103506] [10/11/12/13 Regression] ICE in gfc_free_namespace, at fortran/symbol.c:4039 since r10-2798-ge68a35ae4a65d2b3

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

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

--- Comment #5 from Jerry DeLisle  ---
I found that the attached patch does not work.  At the point of assertion many
of the other functions to free memory have null pointers which leads to
segfaults all along the way.

The following approach appears to work, however, obviously there is a lot of
memory left not freed, so we would rely on the OS to clean it up. Maybe this is
ok, not sure.

+++ b/gcc/fortran/symbol.cc
@@ -4032,7 +4032,7 @@ void
 gfc_free_namespace (gfc_namespace *&ns)
 {
   gfc_namespace *p, *q;
-  int i;
+  int i, ecnt;
   gfc_was_finalized *f;

   if (ns == NULL)
@@ -4042,6 +4042,12 @@ gfc_free_namespace (gfc_namespace *&ns)
   if (ns->refs > 0)
 return;

+  /* In the presence of errors, the namespace may be
+ corrupted or non-sense.  Don't assert() and bail out.  */
+  gfc_get_errors (NULL, &ecnt);
+  if (ecnt > 0)
+return;
+
   gcc_assert (ns->refs == 0);

   gfc_free_statements (ns->code);

[Bug c/84764] Wrong warning "so large that it is unsigned" for __int128 constant

[joseph at codesourcery dot com via Gcc-bugs]

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

--- Comment #5 from joseph at codesourcery dot com  ---
Also, for it to become an extended integer type, it would be necessary to 
define integer constant suffixes and implement printf / scanf support in 
the library, because  is now required to provide intN_t / 
uintN_t when there is a matching standard or extended integer type, so 
would be required to provide int128_t / uint128_t, which in turn would 
require the corresponding  and  macros, so requiring 
constant suffixes and printf / scanf support.

[Bug other/108549] [12 regression] gcc.dg/pr107554.c fails for 32 bits after r12-9062-gca8b8191983d1a

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

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

--- Comment #1 from seurer at gcc dot gnu.org ---
I am also seeing the same error with gcc 11.  r11-10483-g23a9270c999a24

[Bug c/108531] Imaginary types are not supported, violating ISO C Annex G

[joseph at codesourcery dot com via Gcc-bugs]

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

--- Comment #6 from joseph at codesourcery dot com  ---
My only real addition to my previous comments in the referenced glibc bug 
report is that, given we defined _Float32 which has the same "not promoted 
at language level in variable arguments" property as _Imaginary float and 
let it have the ABI arising naturally from the back ends in the absence of 
target maintainers / ABI maintainers choosing something different, it 
would probably be reasonable to do the same thing for imaginary types; 
this case is rather different from _BitInt where there are significant ABI 
choices to be made for each architecture (and I've filed bugs on various 
ABI repositories to request that such ABIs be defined).  It would be good 
if psABI maintainers kept up more with C standard features, however.

[Bug modula2/108135] Modula2 meets clang

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

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

Gaius Mulley  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Gaius Mulley  ---
Closing as bugfixes has been git pushed.  Thanks for reporting the clang
warnings - the WITH statement has been improved from the user debugging
perspective.

[Bug modula2/108135] Modula2 meets clang

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

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

Gaius Mulley  changed:

   What|Removed |Added

 CC||gaius at gcc dot gnu.org

--- Comment #4 from Gaius Mulley  ---
Created attachment 54343
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54343&action=edit
Potential fix for remaining clang warnings

Here is a patch which fixes the parameter withTok, unused variable Dim and
removes all redefinitions of PACKAGE macros.

[Bug other/108549] New: [12 regression] gcc.dg/pr107554.c fails for 32 bits after r12-9062-gca8b8191983d1a

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

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

Bug ID: 108549
   Summary: [12 regression] gcc.dg/pr107554.c fails for 32 bits
after r12-9062-gca8b8191983d1a
   Product: gcc
   Version: 12.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:ca8b8191983d1a211a718b39ca07e35b8c626416, r12-9062-gca8b8191983d1a

This happens on 32 bit test runs on BE.

make  -k check-gcc RUNTESTFLAGS="--target_board=unix'{-m32}'
dg.exp=gcc.dg/pr107554.c"
FAIL: gcc.dg/pr107554.c (test for excess errors)
# of unexpected failures1

commit ca8b8191983d1a211a718b39ca07e35b8c626416
Author: Richard Biener 
Date:   Fri Nov 11 14:28:52 2022 +0100

tree-optimization/107554 - fix ICE in stlen optimization

spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-12-test/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-12-test/gcc/
/home/seurer/gcc/git/gcc-12-test/gcc/testsuite/gcc.dg/pr107554.c -m32
-fdiagnostics-plain-output -O -foptimize-strlen -S -o pr107554.s^M
/home/seurer/gcc/git/gcc-12-test/gcc/testsuite/gcc.dg/pr107554.c:6:5: error:
size of array 'a' exceeds maximum object size '2147483647'^M
/home/seurer/gcc/git/gcc-12-test/gcc/testsuite/gcc.dg/pr107554.c:7:5: error:
size of array 'b' exceeds maximum object size '2147483647'^M
compiler exited with status 1

[Bug c/52381] asm goto output operands diagnostics

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |11.0
 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Andrew Pinski  ---
Fixed in GCC 11 by allowing output operands in inline-asm gotos.

That is the code is accepted ...

[Bug rtl-optimization/103979] asm goto is not considered volatile with output operands

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||ndesaulniers at google dot com

--- Comment #2 from Andrew Pinski  ---
*** Bug 108548 has been marked as a duplicate of this bug. ***

[Bug middle-end/108548] gcc asm goto with outputs not implicitly volatile

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Andrew Pinski  ---
Dup of bug 103979.

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

[Bug c/108548] New: gcc asm goto with outputs not implicitly volatile

[ndesaulniers at google dot com via Gcc-bugs]

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

Bug ID: 108548
   Summary: gcc asm goto with outputs not implicitly volatile
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ndesaulniers at google dot com
CC: eli.friedman at gmail dot com, foom at fuhm dot net
  Target Milestone: ---

https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Volatile mentions:

> GCC’s optimizers sometimes discard asm statements if they determine there is 
> no need for the output variables. ... Using the volatile qualifier disables 
> these optimizations. asm statements that have no output operands and asm goto 
> statements, are implicitly volatile.

So what about asm goto statements that do have outputs, which GCC recently
gained support for?

Looks like I get different codegen targeting x86 at -O2 with:

```
int foo (void) {
void *x;
asm goto (
"movq   %l1, %0\n\t"
"jmp*%0"
:"=r"(x):::bar);
return 0;
bar:
return 1;
}
```
based on whether the asm goto statement is marked volatile or not.

Should asm goto statements with outputs be implicitly volatile (implying a bug
currently in GCC) or not (implying the documentation could perhaps be updated)?

[Bug fortran/108544] ICE in check_host_association, at fortran/resolve.cc:6135

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from anlauf at gcc dot gnu.org ---
Submitted: https://gcc.gnu.org/pipermail/fortran/2023-January/058835.html

[Bug c/101832] __builtin_object_size(P->M, 1) where M ends with a flex-array behaves like sizeof()

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

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

--- Comment #8 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #3)
> This is intentional, if you embed an aggregate with flex array into another
> struct and ask not to cross the field boundaries (i.e. bos1), then the size
> of that field is exactly what is the maximum size.

As we discussed in PR 107952
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107952):

GCC extension accepts the following two cases:

**Case 1:

struct A { char data[1]; };
struct B { int n; struct A a; };

as if the a.data[] array is a flex-array.  

**Case 2: 

struct C { int n; struct A a; int x; };

as if a.data[] can be up to 4 elements. 

So, what's you mean by "not to cross the field boundaries" is for the above
Case 2? 
For Case 1, we should treat A.data as flexible array, and then B.A as a
structure that has flexible array, therefore B.A's size is flexible too. 

Is my understanding correct?

[Bug tree-optimization/107952] tree-object-size: inconsistent size for flexible arrays nested in structs

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

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

--- Comment #17 from qinzhao at gcc dot gnu.org ---
(In reply to Siddhesh Poyarekar from comment #16)
> > We might add a new utility routine to determine whether a ref to a struct or
> > union have flexible array?
> 
> It will be useful for __bos/__bdos for sure.

Yes, this new utility routine can be added and used by tree-object-size, then
we can fix the PR 101832 separately.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101832

[Bug fortran/108544] ICE in check_host_association, at fortran/resolve.cc:6135

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

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

--- Comment #2 from anlauf at gcc dot gnu.org ---
I played a little and found a variation of testcase pr96102.f90
that was silently accepted but is rejected by Intel, NAG, Cray, NVidia:

module m
  type mytype
integer :: i
  end type
  type(mytype) :: d = mytype (42) ! { dg-error "is host associated" }
  integer  :: n = 2   ! { dg-error "is host associated" }
contains
  subroutine s
if ( n   /= 0 ) stop 1  ! { dg-error "internal procedure of the same name"
}
if ( d%i /= 0 ) stop 2  ! { dg-error "internal procedure of the same name"
}
  contains
subroutine n()
end
subroutine d()
end
  end
end

This need removing just one line of code in addition to comment#1:

diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 94213cd3cd4..b40e04513b5 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -6087,7 +6093,6 @@ check_host_association (gfc_expr *e)
   gfc_find_symbol (e->symtree->name, gfc_current_ns, 1, &sym);

   if (sym && old_sym != sym
- && sym->ts.type == old_sym->ts.type
  && sym->attr.flavor == FL_PROCEDURE
  && sym->attr.contained)
{
@@ -6132,6 +6137,9 @@ check_host_association (gfc_expr *e)
  return false;
}

+ if (ref == NULL)
+   return false;
+
  gcc_assert (ref->type == REF_ARRAY);

  /* Grab the start expressions from the array ref and

Am I missing something?

[Bug tree-optimization/107952] tree-object-size: inconsistent size for flexible arrays nested in structs

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

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

--- Comment #16 from Siddhesh Poyarekar  ---
(In reply to Qing Zhao from comment #15)
> Since S2.flex is not an “array_ref”, it’s correct for
> array_ref_fleixble_size_p to return false for it, I think. 
> We might add a new utility routine to determine whether a ref to a struct or
> union have flexible array?

It will be useful for __bos/__bdos for sure.

[Bug fortran/108544] ICE in check_host_association, at fortran/resolve.cc:6135

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2023-01-25
 Status|UNCONFIRMED |NEW

--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.

The following patch avoids a NULL pointer dereference:

diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 94213cd3cd4..c6f12bfecdb 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -6132,6 +6138,9 @@ check_host_association (gfc_expr *e)
  return false;
}

+ if (ref == NULL)
+   return false;
+
  gcc_assert (ref->type == REF_ARRAY);

  /* Grab the start expressions from the array ref and

[Bug fortran/108528] [13 Regression] ICE in gfc_compare_array_spec(): Array spec clobbered

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #6 from anlauf at gcc dot gnu.org ---
Fixed on mainline for gcc-13.

Thanks for the report, and to Steve for the patch.

[Bug fortran/108528] [13 Regression] ICE in gfc_compare_array_spec(): Array spec clobbered

[sgk at troutmask dot apl.washington.edu via Gcc-bugs]

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

--- Comment #5 from Steve Kargl  ---
On Wed, Jan 25, 2023 at 07:44:05PM +, anlauf at gcc dot gnu.org wrote:
> 
> --- Comment #3 from anlauf at gcc dot gnu.org ---
> Steve, I'm going to commit your patch.
> 

Thanks.

[Bug tree-optimization/108547] [13 Regression] ice in decompose, at wide-int.h:984 for -O2 with -Wall

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
Summary|ice in decompose, at|[13 Regression] ice in
   |wide-int.h:984 for -O2 with |decompose, at
   |-Wall   |wide-int.h:984 for -O2 with
   ||-Wall

--- Comment #5 from Andrew Pinski  ---
My bet this was introduced by r13-4408-gb628cad9e093f7 or
r13-4406-g9500877d05c56c.

[Bug fortran/108528] [13 Regression] ICE in gfc_compare_array_spec(): Array spec clobbered

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

https://gcc.gnu.org/g:9fb9da3d38513d320bfea72050f7a59688595e0b

commit r13-5374-g9fb9da3d38513d320bfea72050f7a59688595e0b
Author: Steve Kargl 
Date:   Wed Jan 25 20:38:43 2023 +0100

Fortran: ICE in gfc_compare_array_spec [PR108528]

gcc/fortran/ChangeLog:

PR fortran/108528
* array.cc (compare_bounds): Return false instead of generating an
internal error on an invalid argument type.

gcc/testsuite/ChangeLog:

PR fortran/108528
* gfortran.dg/pr108528.f90: New test.

[Bug fortran/108528] [13 Regression] ICE in gfc_compare_array_spec(): Array spec clobbered

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from anlauf at gcc dot gnu.org ---
Steve, I'm going to commit your patch.

[Bug target/105753] [avr] ICE: in add_clobbers, at config/avr/avr-dimode.md:2705

[user99627 at gmx dot com via Gcc-bugs]

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

--- Comment #11 from User99627  ---
I can also tell the bug occurs regardless of the -flto flag is present or not.

[Bug fortran/108527] [13 Regression] ICE in compare_bound_int(): Bad expression

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

  Known to work||7.5.0
  Known to fail||10.4.1, 11.3.1, 12.2.1,
   ||8.5.0, 9.5.0

--- Comment #8 from anlauf at gcc dot gnu.org ---
(In reply to Martin Liška from comment #7)
> Btw. started with r8-7594-g078c5aff5ed83e9c.

Right.  Adding known to work and known to fail versions.

[Bug c++/108543] [10/11/12/13 Regression] ICE in build_call_expr_loc_array, at tree.cc:10686

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
I have a fix.

[Bug c++/108543] [10/11/12/13 Regression] ICE in build_call_expr_loc_array, at tree.cc:10686

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

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

--- Comment #3 from Marek Polacek  ---
Started with r255404.

[Bug tree-optimization/108547] ice in decompose, at wide-int.h:984 for -O2 with -Wall

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

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

--- Comment #4 from Andrew Pinski  ---
I suspect it is trying to simplifying:
((NOT (us_8.1_2 != 0)))
OR ((func_7_ptr_13.8_9 != 0) AND (_8 != 0) AND (func_7_ptr_13.8_9 & 1)
AND (NOT (_49 != 0)) AND (NOT (prephitmp_37 != 0)))
OR ((func_7_ptr_13.8_9 & 1) AND (NOT (_49 != 0)) AND (NOT (_11 != 0)))
OR ((NOT (_30 != 0)) AND (NOT (_49 != 0)) AND (NOT (prephitmp_37 !=
0)))

Note the & 1 there  That seems like the issue, trying to simplify:
(func_7_ptr_13.8_9 != 0) AND (func_7_ptr_13.8_9 & 1)

[Bug c++/108543] [10/11/12/13 Regression] ICE in build_call_expr_loc_array, at tree.cc:10686

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

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

--- Comment #2 from Marek Polacek  ---
struct _Bit_iterator_base {
  long _M_p;
  friend bool operator<(_Bit_iterator_base __x, _Bit_iterator_base __y) {
return &__x._M_p - &__y._M_p;
  }
};

[Bug tree-optimization/108547] ice in decompose, at wide-int.h:984 for -O2 with -Wall

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

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

--- Comment #3 from Andrew Pinski  ---
Here is a slightly better testcase that does not depend on implicit conversion
from a function pointer to an integer.

int li_4, li_5, us_8;
unsigned char func_7_ptr_13, func_7_uc_14;
long t;
int func_7_uc_10li_19(int);
void func_7_ptr_18() {
  if (li_5) {
for (;;)
  ;
short s_15;
for (; func_7_uc_14;) {
  us_8 = 7;
  for (; us_8; us_8 += 1)
  lblD2AF1FAB:
if (us_8)
  li_4 = 1;
  func_7_uc_14 += t;
  if (func_7_ptr_13 & 1 && (func_7_uc_14 &= func_7_ptr_13))
s_15 %= func_7_uc_10li_19(s_15);
}
  }
  goto lblD2AF1FAB;
}

[Bug target/105753] [avr] ICE: in add_clobbers, at config/avr/avr-dimode.md:2705

[user99627 at gmx dot com via Gcc-bugs]

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

User99627  changed:

   What|Removed |Added

 CC||user99627 at gmx dot com

--- Comment #10 from User99627  ---
Created attachment 54342
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54342&action=edit
Complete Arduino compile trace after compiling the sample sketch (see comment)

I'm running Manjaro and I cannot chose which version of avr-gcc I run on my
system. It currently is avr-gcc 12.2.0. As a consequence I cannot run most
Arduino sketches either, so long as I'm using the system AVR compiler.

Here's a sample sketch that exhibits the error (see attachments):

void setup()
{
  Serial.begin(9600);
}

void loop()
{
  enum { OPEN, CLOSE };

  static uint32_t prevMillis;  // Unsigned long, not int! ;)
  static uint16_t interval;
  static uint8_t state;// Defaults to OPEN

  uint32_t currentMillis = millis();
  if (currentMillis - prevMillis >= interval)
  {
prevMillis = currentMillis;
// Could use a switch/case here:
if (state == OPEN)
{
  interval = random(3000, 1);
  Serial.print("interval blink : ");
  Serial.println(interval);
  state = CLOSE;
}
if (state == CLOSE)
{
  interval = 300;
  Serial.println("open");
  state = OPEN;
}
  }
}

[Bug tree-optimization/108547] ice in decompose, at wide-int.h:984 for -O2 with -Wall

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-01-25
 Status|UNCONFIRMED |NEW

--- Comment #2 from Andrew Pinski  ---
#7  0x02c9c926 in value_sat_pred_p (val=0x77265138,
boundary=0x773f7a80, cmpc=BIT_AND_EXPR, exact_p=false) at
/home/apinski/src/upstream-gcc/gcc/gcc/gimple-predicate-analysis.cc:731
731   wide_int andw = wi::to_wide (val) & wi::to_wide (boundary);
(gdb) p debug_tree(val)
  constant 0>
$7 = void
(gdb) p debug_tree(boundary)
 
constant 1>
$8 = void

Confirmed.

[Bug target/100962] Poor optimization of AVR code when using structs in __flash

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #5 from Georg-Johann Lay  ---
The code is optimized fine with -Os.

With -Og, you can expect less optimized code.  For the provided code and -Og,
you can improve code quality by means of -mstrict-X (where I am not sure
whether it would be appropriate to have -mstrict-X as the default).

[Bug tree-optimization/108547] ice in decompose, at wide-int.h:984 for -O2 with -Wall

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

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

--- Comment #1 from Andrew Pinski  ---
Here is the full backtrace:
0xc7c58b wi::int_traits >
>::decompose(long*, unsigned int, generic_wide_int > const&)
/home/apinski/src/upstream-gcc/gcc/gcc/wide-int.h:984
0xc7c7a4 wide_int_ref_storage::wide_int_ref_storage > >(generic_wide_int > const&,
unsigned int)
/home/apinski/src/upstream-gcc/gcc/gcc/wide-int.h:1034
0xc7bd5e generic_wide_int
>::generic_wide_int >
>(generic_wide_int > const&, unsigned int)
/home/apinski/src/upstream-gcc/gcc/gcc/wide-int.h:790
0x1084abf wi::binary_traits
>, generic_wide_int >,
wi::int_traits >
>::precision_type, wi::int_traits > >::precision_type>::result_type
wi::bit_and >,
generic_wide_int >
>(generic_wide_int > const&,
generic_wide_int > const&)
/home/apinski/src/upstream-gcc/gcc/gcc/wide-int.h:2338
0x1081df1 wi::binary_traits
>, generic_wide_int >,
wi::int_traits >
>::precision_type, wi::int_traits > >::precision_type>::operator_result
operator& >,
generic_wide_int >
>(generic_wide_int > const&,
generic_wide_int > const&)
/home/apinski/src/upstream-gcc/gcc/gcc/wide-int.h:3309
0x2c9c925 value_sat_pred_p
/home/apinski/src/upstream-gcc/gcc/gcc/gimple-predicate-analysis.cc:731
0x2c9ca99 subset_of
/home/apinski/src/upstream-gcc/gcc/gcc/gimple-predicate-analysis.cc:765
0x2c9cb89 subset_of
/home/apinski/src/upstream-gcc/gcc/gcc/gimple-predicate-analysis.cc:792
0x2c9cc09 predicate::includes(vec const&) const
/home/apinski/src/upstream-gcc/gcc/gcc/gimple-predicate-analysis.cc:815
0x2c9cc71 predicate::superset_of(predicate const&) const
/home/apinski/src/upstream-gcc/gcc/gcc/gimple-predicate-analysis.cc:834
0x2ca09e6 uninit_analysis::is_use_guarded(gimple*, basic_block_def*, gphi*,
unsigned int, hash_set >*)
   
/home/apinski/src/upstream-gcc/gcc/gcc/gimple-predicate-analysis.cc:2250
0x2ca0a86 uninit_analysis::is_use_guarded(gimple*, basic_block_def*, gphi*,
unsigned int)
   
/home/apinski/src/upstream-gcc/gcc/gcc/gimple-predicate-analysis.cc:2263
0x19370ab find_uninit_use
/home/apinski/src/upstream-gcc/gcc/gcc/tree-ssa-uninit.cc:1234
0x193745f warn_uninitialized_phi
/home/apinski/src/upstream-gcc/gcc/gcc/tree-ssa-uninit.cc:1304
0x193791e execute_late_warn_uninitialized
/home/apinski/src/upstream-gcc/gcc/gcc/tree-ssa-uninit.cc:1425
0x19379f5 execute
/home/apinski/src/upstream-gcc/gcc/gcc/tree-ssa-uninit.cc:1442
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/108543] [10/11/12/13 Regression] ICE in build_call_expr_loc_array, at tree.cc:10686

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

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

Marek Polacek  changed:

   What|Removed |Added

   Last reconfirmed||2023-01-25
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1
   Target Milestone|--- |10.5
 Status|UNCONFIRMED |NEW
Summary|ICE in  |[10/11/12/13 Regression]
   |build_call_expr_loc_array,  |ICE in
   |at tree.cc:10686|build_call_expr_loc_array,
   ||at tree.cc:10686
   Priority|P3  |P2

--- Comment #1 from Marek Polacek  ---
Confirmed, reducing...

[Bug c/102760] ICE: in decompose, at wide-int.h:984

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #8 from David Binderman  ---
(In reply to Andrew Pinski from comment #7)
> (In reply to David Binderman from comment #6)
> > I see very similar for this legal C code:
> 
> That seems like a different issue, please file it seperately.

Done, see 108547.

[Bug c/108547] New: ice in decompose, at wide-int.h:984 for -O2 with -Wall

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 108547
   Summary: ice in decompose, at wide-int.h:984 for -O2 with -Wall
   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 legal C source code:

int li_4, li_5, us_8;
unsigned char func_7_ptr_13, func_7_uc_14;
void func_7_ptr_18() {
  if (li_5) {
for (;;)
  ;
short s_15;
for (; func_7_uc_14;) {
  us_8 = 7;
  for (; us_8; us_8 += 1)
  lblD2AF1FAB:
if (us_8)
  li_4 = 1;
  func_7_uc_14 += func_7_ptr_18;
  if (func_7_ptr_13 & 1 && (func_7_uc_14 &= func_7_ptr_13))
s_15 %= func_7_uc_10li_19(s_15);
}
  }
  goto lblD2AF1FAB;
}

when compiled with recent gcc trunk, does this:

$ ~/gcc/results//bin/gcc -c -O2 -Wall bug876.c 
bug876.c: In function ‘func_7_ptr_18’:
bug876.c:14:20: warning: assignment to ‘unsigned char’ from ‘void (*)()’ makes
integer from pointer without a cast [-Wint-conversion]
   14 |   func_7_uc_14 += func_7_ptr_18;
  |^~
bug876.c:16:17: warning: implicit declaration of function ‘func_7_uc_10li_19’
[-Wimplicit-function-declaration]
   16 | s_15 %= func_7_uc_10li_19(s_15);
  | ^
during GIMPLE pass: uninit
bug876.c:3:6: internal compiler error: in decompose, at wide-int.h:984
3 | void func_7_ptr_18() {
  |  ^
0x1df0eb9 value_sat_pred_p(tree_node*, tree_node*, tree_code, bool)
../../trunk.d1/gcc/wide-int.h:0

The bug first seems to appear sometime before git hash g:9b111debbfb79a0a
dated 20221229.

[Bug target/99435] avr: incorrect I/O address ranges for some cores

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
   Last reconfirmed||2023-01-25

--- Comment #2 from Georg-Johann Lay  ---
Still wainting for a reply.

[Bug c/102760] ICE: in decompose, at wide-int.h:984

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

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

--- Comment #7 from Andrew Pinski  ---
(In reply to David Binderman from comment #6)
> I see very similar for this legal C code:

That seems like a different issue, please file it seperately.

[Bug c/102760] ICE: in decompose, at wide-int.h:984

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #6 from David Binderman  ---
I see very similar for this legal C code:

int li_4, li_5, us_8;
unsigned char func_7_ptr_13, func_7_uc_14;
void func_7_ptr_18() {
  if (li_5) {
for (;;)
  ;
short s_15;
for (; func_7_uc_14;) {
  us_8 = 7;
  for (; us_8; us_8 += 1)
  lblD2AF1FAB:
if (us_8)
  li_4 = 1;
  func_7_uc_14 += func_7_ptr_18;
  if (func_7_ptr_13 & 1 && (func_7_uc_14 &= func_7_ptr_13))
s_15 %= func_7_uc_10li_19(s_15);
}
  }
  goto lblD2AF1FAB;
}

when compiled as follows:

$ ~/gcc/results//bin/gcc -c -O2 -Wall bug876.c 
bug876.c: In function ‘func_7_ptr_18’:
bug876.c:14:20: warning: assignment to ‘unsigned char’ from ‘void (*)()’ makes
integer from pointer without a cast [-Wint-conversion]
   14 |   func_7_uc_14 += func_7_ptr_18;
  |^~
bug876.c:16:17: warning: implicit declaration of function ‘func_7_uc_10li_19’
[-Wimplicit-function-declaration]
   16 | s_15 %= func_7_uc_10li_19(s_15);
  | ^
during GIMPLE pass: uninit
bug876.c:3:6: internal compiler error: in decompose, at wide-int.h:984
3 | void func_7_ptr_18() {

[Bug c/108531] Imaginary types are not supported, violating ISO C Annex G

[Keith.S.Thompson at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Keith Thompson  ---
FYI, I've sent an email to the C standard editors (the addresses at
the top of the N3054 draft) suggesting that imaginary number support
should be optional even if __STDC_IEC_559_COMPLEX__ and
__STDC_IEC_60559_COMPLEX__ are defined.

It's probably too late to make such a change in C23.

(__STDC_IEC_60559_COMPLEX__ is replacing __STDC_IEC_559_COMPLEX__,
which is obsolescent.)

[Bug fortran/108546] New: [11/12/13 Regression] ICE in expand_expr_real_1, at expr.cc:10910

[gscfq--- via Gcc-bugs]

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

Bug ID: 108546
   Summary: [11/12/13 Regression] ICE in expand_expr_real_1, at
expr.cc:10910
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started with r10, between 20191110 and 20191117 :


$ cat z1.f90
module m
   use iso_c_binding
contains
   subroutine s(x)
  type(c_ptr), optional :: x
  !$omp target is_device_ptr(x)
  if (c_associated(x)) stop
  !$omp end target
   end
end


$ cat z2.f90# compiles, for reference only
module m
   use iso_c_binding
contains
   subroutine s(x)
  type(c_ptr) :: x
  !$omp target is_device_ptr(x)
  if (c_associated(x)) stop
  !$omp end target
   end
end


$ gfortran-13-20230122 -c z2.f90 -fopenmp
$ gfortran-10-20191110 -c z1.f90 -fopenmp
$
$ gfortran-13-20230122 -c z1.f90 -fopenmp
during RTL pass: expand
z1.f90:6:35:

6 |   !$omp target is_device_ptr(x)
  |   ^
internal compiler error: in expand_expr_real_1, at expr.cc:10910
0xa570bf expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/expr.cc:10904
0xa5e66e expand_expr
../../gcc/expr.h:310
0xa5e66e expand_operands(tree_node*, tree_node*, rtx_def*, rtx_def**,
rtx_def**, expand_modifier)
../../gcc/expr.cc:8582
0xa6a23a do_store_flag
../../gcc/expr.cc:13113
0xa6574e expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
../../gcc/expr.cc:10259
0x94fba2 expand_gimple_stmt_1
../../gcc/cfgexpand.cc:3983
0x94fba2 expand_gimple_stmt
../../gcc/cfgexpand.cc:4044
0x9548d7 expand_gimple_basic_block
../../gcc/cfgexpand.cc:6096
0x95739e execute
../../gcc/cfgexpand.cc:6831

[Bug c++/87512] Error: the type ‘const auto’ of ‘constexpr’ variable is not literal

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

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

--- Comment #8 from Jonathan Wakely  ---
Yes please

[Bug fortran/108545] New: [13 Regression] ICE in install_var_field, at omp-low.cc:799

[gscfq--- via Gcc-bugs]

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

Bug ID: 108545
   Summary: [13 Regression] ICE in install_var_field, at
omp-low.cc:799
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started between 20220911 and 20220918 :


$ cat z1.f90
program p
   type t
  integer, pointer :: a(:)
   end type
   type(t), volatile :: x
   !$omp target enter data map(to: x%a)
end


$ cat z2.f90
program p
   type t
  integer, pointer :: a(:)
   end type
   type(t) :: x
   !$omp target enter data map(to: x%a)
end


$ gfortran-13-20230122 -c z2.f90 -fopenmp
$ gfortran-12  -c z1.f90 -fopenmp
$
$ gfortran-13-20230122 -c z1.f90 -fopenmp
during GIMPLE pass: omplower
z1.f90:6:39:

6 |!$omp target enter data map(to: x%a)
  |   ^
internal compiler error: in install_var_field, at omp-low.cc:799
0xc6accb install_var_field
../../gcc/omp-low.cc:798
0xc6f882 scan_sharing_clauses
../../gcc/omp-low.cc:1678
0xc71c24 scan_omp_target
../../gcc/omp-low.cc:3111
0xc7282d scan_omp_1_stmt
../../gcc/omp-low.cc:4327
0xaf96a6 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gimple-walk.cc:608
0xaf9880 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.cc:51
0xaf9761 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gimple-walk.cc:635
0xaf9880 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.cc:51
0xaf9761 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gimple-walk.cc:635
0xaf9880 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.cc:51
0xc6852d scan_omp
../../gcc/omp-low.cc:4377
0xc7c73a execute_lower_omp
../../gcc/omp-low.cc:14691
0xc7c73a execute
../../gcc/omp-low.cc:14755

[Bug target/100000] non-leaf epologue/prologue used if MVE v4sf is used for load/return

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

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

--- Comment #3 from Richard Earnshaw  ---
Given that the hard-float ABI essentially requires V4SF as a type, it might be
better to consider this mode supported unconditionally in this case, and
although that might make the compiler try some pointless vectorizations it
would generate better code for cases like this.

[Bug fortran/108544] New: ICE in check_host_association, at fortran/resolve.cc:6135

[gscfq--- via Gcc-bugs]

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

Bug ID: 108544
   Summary: ICE in check_host_association, at
fortran/resolve.cc:6135
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to at least r5 :


$ cat z1.f90
module m
   implicit none
contains
   subroutine s
  select type (s => 1)
  end select
   end
end


$ cat z3.f90
module m
contains
   subroutine s
  select type (s => null())
  end select
   end
end


$ cat z4.f90
module m
   type t
   end type
   type(t) :: x
contains
   subroutine s
  select type (s => x)
  end select
   end
end


$ gfortran-13-20230122 -c z1.f90
f951: internal compiler error: Segmentation fault
0xdaa49f crash_signal
../../gcc/toplev.cc:314
0x838506 check_host_association
../../gcc/fortran/resolve.cc:6135
0x838506 gfc_resolve_expr(gfc_expr*)
../../gcc/fortran/resolve.cc:7194
0x83fa6c gfc_resolve_expr(gfc_expr*)
../../gcc/fortran/resolve.cc:7162
0x83fa6c gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.cc:11982
0x8416a7 resolve_codes
../../gcc/fortran/resolve.cc:17629
0x8415de resolve_codes
../../gcc/fortran/resolve.cc:17612
0x84176e gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.cc:17664
0x8292d2 gfc_parse_file()
../../gcc/fortran/parse.cc:6862
0x8774bf gfc_be_parse_file
../../gcc/fortran/f95-lang.cc:229

[Bug c++/108543] New: ICE in build_call_expr_loc_array, at tree.cc:10686

[gscfq--- via Gcc-bugs]

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

Bug ID: 108543
   Summary: ICE in build_call_expr_loc_array, at tree.cc:10686
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started with r8 :


$ cat z1.cc
#include 


$ g++-13-20230122 -c z1.cc -fsanitize=address -fno-sanitize=kernel-address
-fsanitize=pointer-subtract
In file included from .../gcc-13-20230122/include/c++/13.0.1/vector:67,
 from z1.cc:1:
.../gcc-13-20230122/include/c++/13.0.1/bits/stl_bvector.h: In function
'std::ptrdiff_t std::operator-(const _Bit_iterator_base&, const
_Bit_iterator_base&)':
.../gcc-13-20230122/include/c++/13.0.1/bits/stl_bvector.h:269:50: internal
compiler error: Segmentation fault
  269 |   return (int(_S_word_bit) * (__x._M_p - __y._M_p)
  |  ^~~~
0xeb575f crash_signal
../../gcc/toplev.cc:314
0x114833e build_call_expr_loc_array(unsigned int, tree_node*, int, tree_node**)
../../gcc/tree.cc:10686
0x114842f build_call_expr_loc(unsigned int, tree_node*, int, ...)
../../gcc/tree.cc:10719
0x98b393 pointer_diff
../../gcc/cp/typeck.cc:6728
0x98b393 cp_build_binary_op(op_location_t const&, tree_code, tree_node*,
tree_node*, int)
../../gcc/cp/typeck.cc:5350
0x7c8c8c build_new_op(op_location_t const&, tree_code, int, tree_node*,
tree_node*, tree_node*, tree_node*, tree_node**, int)
../../gcc/cp/call.cc:7369
0x97de10 build_x_binary_op(op_location_t const&, tree_code, tree_node*,
tree_code, tree_node*, tree_code, tree_node*, tree_node**, int)
../../gcc/cp/typeck.cc:4722
0x8d16e3 cp_parser_binary_expression
../../gcc/cp/parser.cc:10283
0x8d1eb4 cp_parser_assignment_expression
../../gcc/cp/parser.cc:10444
0x8d35f2 cp_parser_expression
../../gcc/cp/parser.cc:10614
0x8e50c1 cp_parser_primary_expression
../../gcc/cp/parser.cc:5722
0x8e8a76 cp_parser_postfix_expression
../../gcc/cp/parser.cc:7731
0x8fbfff cp_parser_unary_expression
../../gcc/cp/parser.cc:9095
0x8d0bff cp_parser_cast_expression
../../gcc/cp/parser.cc:
0x8d190c cp_parser_simple_cast_expression
../../gcc/cp/parser.cc:32523
0x8d190c cp_parser_binary_expression
../../gcc/cp/parser.cc:10168
0x8d1eb4 cp_parser_assignment_expression
../../gcc/cp/parser.cc:10444
0x8d35f2 cp_parser_expression
../../gcc/cp/parser.cc:10614
0x8e50c1 cp_parser_primary_expression
../../gcc/cp/parser.cc:5722
0x8e8a76 cp_parser_postfix_expression
../../gcc/cp/parser.cc:7731

[Bug c++/108542] New: [13 Regression] ICE in instantiate_type, at cp/class.cc:8833

[gscfq--- via Gcc-bugs]

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

Bug ID: 108542
   Summary: [13 Regression] ICE in instantiate_type, at
cp/class.cc:8833
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started between 20221106 and 20221120 :


$ cat z1.cc
template
void f (T n) {}
[[pre: f]]


$ g++-13-20230122 -c z1.cc
z1.cc:3:8: internal compiler error: in instantiate_type, at cp/class.cc:8833
3 | [[pre: f]]
  |^
0x7d34ef instantiate_type(tree_node*, tree_node*, int)
../../gcc/cp/class.cc:8833
0x7b2c27 implicit_conversion_error
../../gcc/cp/call.cc:4658
0x7c05bc perform_implicit_conversion_flags(tree_node*, tree_node*, int, int)
../../gcc/cp/call.cc:13366
0x97e5cc contextual_conv_bool(tree_node*, int)
../../gcc/cp/typeck.cc:6952
0x97e5cc condition_conversion(tree_node*)
../../gcc/cp/typeck.cc:6961
0x81665a grok_contract(tree_node*, tree_node*, tree_node*, cp_expr, unsigned
int)
../../gcc/cp/contracts.cc:783
0x8f0a2f cp_parser_contract_attribute_spec
../../gcc/cp/parser.cc:29740
0x8f0a2f cp_parser_std_attribute_spec
../../gcc/cp/parser.cc:29886
0x8f0a2f cp_parser_std_attribute_spec_seq
../../gcc/cp/parser.cc:30011
0x8f0f51 cp_parser_attributes_opt
../../gcc/cp/parser.cc:28909
0x8e11e7 cp_parser_decl_specifier_seq
../../gcc/cp/parser.cc:15734
0x8e1aa1 cp_parser_simple_declaration
../../gcc/cp/parser.cc:15217
0x90c638 cp_parser_declaration
../../gcc/cp/parser.cc:15030
0x90d010 cp_parser_translation_unit
../../gcc/cp/parser.cc:5090
0x90d010 c_parse_file()
../../gcc/cp/parser.cc:49400
0x9f4e01 c_common_parse_file()
../../gcc/c-family/c-opts.cc:1248

[Bug target/100000] non-leaf epologue/prologue used if MVE v4sf is used for load/return

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

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

--- Comment #2 from Richard Earnshaw  ---
If the testcase is built with -march=armv8.1-m.main+mve.fp then the useless
stack adjustments go away.  I think that's because V4SFmode is not a supported
vector mode for integer MVE - see arm_vector_mode_supported_p() in arm.cc. 
When it isn't a builtin type we end up with a BLKmode object that the compiler
creates a stack-slot for, even though no RTL is ever generated to use the slot
in this case.

[Bug analyzer/108507] [13 regression] new test case gcc.dg/analyzer/SARD-tc841-basic-00182-min.c in r13-5244-gc6a011119bfa03 fails

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

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

David Malcolm  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2023-01-25

--- Comment #1 from David Malcolm  ---
Also seen on aarch64-unknown-linux-gnu:
  https://godbolt.org/z/Yzbxvf8j4

I'll add -Wno-stringop-overflow to the failing test (the point of the test is
to see if -fanalyzer can detect the problem).

[Bug analyzer/108524] -Wanalyzer-infinite-recursion false positives seen in qemu's JSON parser

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

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Last reconfirmed||2023-01-25

--- Comment #1 from David Malcolm  ---
I'm testing a fix for this.

[Bug c++/108538] unexpected -Wnarrowing errors in -fpermissive mode

[stsp at users dot sourceforge.net via Gcc-bugs]

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

--- Comment #4 from Stas Sergeev  ---
(In reply to Jonathan Wakely from comment #3)
> It seems like you might be expecting more from -fpermissive than it actually
> provides. It only affects a very limited set of diagnostics, and isn't a
> general "compile invalid code" switch.

I always used it to compile the
(valid) C code in C++ mode. I thought
that's what it is for. It violates the
C++ standard up and down. And that
-Wnarrowing case is "better" than others
because it was a warning in c++03.
Other problems that -fpermissive allows,
were always an errors in any c++ mode.

[Bug tree-optimization/108523] [13 Regression] -O1 -fcode-hoisting causes long compilation time ?

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #16 from David Binderman  ---
cvise produces:

int g_149, g_167, g_481;
main() {
  int *l_1478 = &g_149;
  *l_1478 ^= g_167;
lbl_1481:
  for (;;) {
g_481 = 1;
for (; g_481; g_481 += 1) {
  g_167 ^= *l_1478;
  if (g_149)
goto lbl_1481;
}
  }
}

[Bug c++/87512] Error: the type ‘const auto’ of ‘constexpr’ variable is not literal

[coyorkdow at outlook dot com via Gcc-bugs]

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

--- Comment #7 from Guo Youtao  ---
(In reply to Andrew Pinski from comment #6)
> (In reply to Guo Youtao from comment #5)
> > This bug can still be triggered in gcc-11 and gcc-12.
> 
> That is unrelated bug. Most likely an issue with pointer to member functions
> which is might have some known issues too.

Should I open a new topic for this bug since this is unrelated?

[Bug tree-optimization/108523] [13 Regression] -O1 -fcode-hoisting causes long compilation time ?

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #15 from David Binderman  ---
(In reply to Richard Biener from comment #14)
> Fixed, but I'll see if somebody comes up with a reduced testcase.

I have a reduction running with cvise.

[Bug c++/87512] Error: the type ‘const auto’ of ‘constexpr’ variable is not literal

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

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Guo Youtao from comment #5)
> This bug can still be triggered in gcc-11 and gcc-12.

That is unrelated bug. Most likely an issue with pointer to member functions
which is might have some known issues too.

[Bug c++/108536] Difference when using requires and enable_if with class constructor

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug sanitizer/108541] New: ASAN since GCC 9 missed a stack-buffer-overflow

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

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

Bug ID: 108541
   Summary: ASAN since GCC 9 missed a stack-buffer-overflow
   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 -O0 missed the stack-buffer-overflow while
other opt levels caught it. This issue happens since GCC-9. GCC-8 and before
worked fine.

I also noticed that there is an incompatible pointer assignment `i = &m`, but
anyway the bufferoverflow should be reported.

Clang can detect it at all opt levels.

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

% cat a.c
struct a {
  long b;
  int c;
  long d;
  short e;
  long f;
  long g;
};
struct {
  struct a b;
  unsigned : 6;
} h, *i;
int j;
int main() {
  struct a *k;
  &k;
  long l[3];
  l[j] = 4;
  int m = 1;
  i = &m;
  *i = h;
  return m;
}
% 
% gcc-tk -fsanitize=address -w -O0 a.c && ./a.out
% 
% gcc-tk -fsanitize=address -w -O1 a.c && ./a.out
=
==1==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7f8605800030
at pc 0x004012e0 bp 0x7ffdfd9e9b10 sp 0x7ffdfd9e9b08
WRITE of size 56 at 0x7f8605800030 thread T0
#0 0x4012df in main /a.c:21
#1 0x7f860810f082 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId:
1878e6b475720c7c51969e69ab2d276fae6d1dee)
#2 0x4010cd in _start (/a.s+0x4010cd) (BuildId:
62f9205a5d8cda9f9cd98eb2592c0ba25a6a0a20)

Address 0x7f8605800030 is located in stack of thread T0 at offset 48 in frame
#0 0x401195 in main /app/example.c:14

  This frame has 2 object(s):
[48, 52) 'm' (line 19) <== Memory access at offset 48 partially overflows
this variable
[64, 88) 'l' (line 17) <== Memory access at offset 48 partially underflows
this variable
HINT: this may be a false positive if your program uses some custom stack
unwind mechanism, swapcontext or vfork
  (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow /a.c:21 in main
Shadow bytes around the buggy address:
...
%

[Bug tree-optimization/107952] tree-object-size: inconsistent size for flexible arrays nested in structs

[qing.zhao at oracle dot com via Gcc-bugs]

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

--- Comment #15 from Qing Zhao  ---
> On Jan 25, 2023, at 11:12 AM, siddhesh at gcc dot gnu.org 
>  wrote:
>> 
>>> The first is handled by the function just fine,
>> 
>> No, even the first case is not recognized by the current
>> “array_ref_flexible_size_p”, it’s not been identified as a flexible array
>> right now.
>> Shall we include this case into “array_ref_flexible_size_p”?  (It’s a GCC
>> extension).
> 
> In the first case, array_ref_flexible_size_p recognizes S2.flex.data as having
> flexible size.  The tests in my patch[1] for this bug checks for this.
Oh, yes. That’s right.
> 
> However, array_ref_flexible_size_p does not recognize S2.flex as having
> flexible size.  It might make sense to support that, i.e. any struct or union
> with the last element as a flex array should be recognized as having flexible
> size.

Since S2.flex is not an “array_ref”, it’s correct for array_ref_fleixble_size_p
to return false for it, I think. 
We might add a new utility routine to determine whether a ref to a struct or
union have flexible array?

[Bug target/105549] aarch64: Wrong va_arg alignment handling with packed bitfields and alignment

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug rtl-optimization/108519] [13 regression] gcc.target/powerpc/pr105586.c fails after r13-5154-g733a1b777f16cd

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

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

--- Comment #1 from Alexander Monakov  ---
We diverge in sched1 due to extra calls to advance_one_cycle when scheduling a
BB that is empty apart from one debug insn. The following patch adds a hexdump
of automaton state to make the problem evident:

diff --git a/gcc/sched-rgn.cc b/gcc/sched-rgn.cc
index 420c45dff..c09398897 100644
--- a/gcc/sched-rgn.cc
+++ b/gcc/sched-rgn.cc
@@ -3098,8 +3098,14 @@ save_state_for_fallthru_edge (basic_block last_bb,
state_t state)
 memcpy (bb_state[f->dest->index], state,
dfa_state_size);
 if (sched_verbose >= 5)
-  fprintf (sched_dump, "saving state for edge %d->%d\n",
-  f->src->index, f->dest->index);
+  {
+   fprintf (sched_dump, "saving state for edge %d->%d\n",
+f->src->index, f->dest->index);
+   for (size_t i = 0; i < dfa_state_size; i++)
+ fprintf (sched_dump, "%02x%c", i[(unsigned char *)state],
+  (i+1) % 16 ? ' ' : '\n');
+   fprintf(sched_dump, "\n---\n");
+  }
   }
 }

With the above patch it's obvious we advance the automaton state a few extra
times when scheduling BB 3, and then inherit the modified state to BB 4.

I think we don't need to schedule blocks that only contain debug insns. IBM
folks, care to test the following?

diff --git a/gcc/haifa-sched.cc b/gcc/haifa-sched.cc
index 4efaa9445..f00a92e26 100644
--- a/gcc/haifa-sched.cc
+++ b/gcc/haifa-sched.cc
@@ -5040,7 +5040,7 @@ no_real_insns_p (const rtx_insn *head, const rtx_insn
*tail)
 {
   while (head != NEXT_INSN (tail))
 {
-  if (!NOTE_P (head) && !LABEL_P (head))
+  if (!NOTE_P (head) && !LABEL_P (head) && !DEBUG_INSN_P (head))
return 0;
   head = NEXT_INSN (head);
 }
diff --git a/gcc/sched-rgn.cc b/gcc/sched-rgn.cc
index 420c45dff..c09398897 100644
--- a/gcc/sched-rgn.cc
+++ b/gcc/sched-rgn.cc
@@ -2753,7 +2753,7 @@ free_block_dependencies (int bb)

   get_ebb_head_tail (EBB_FIRST_BB (bb), EBB_LAST_BB (bb), &head, &tail);

-  if (no_real_insns_p (head, tail))
+  if (0 && no_real_insns_p (head, tail))
 return;

   sched_free_deps (head, tail, true);

[Bug tree-optimization/107952] tree-object-size: inconsistent size for flexible arrays nested in structs

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

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

--- Comment #14 from Siddhesh Poyarekar  ---
(In reply to Qing Zhao from comment #13)
> > 
> > The first is handled by the function just fine,
> 
> No, even the first case is not recognized by the current
> “array_ref_flexible_size_p”, it’s not been identified as a flexible array
> right now.
> Shall we include this case into “array_ref_flexible_size_p”?  (It’s a GCC
> extension).

In the first case, array_ref_flexible_size_p recognizes S2.flex.data as having
flexible size.  The tests in my patch[1] for this bug checks for this.

However, array_ref_flexible_size_p does not recognize S2.flex as having
flexible size.  It might make sense to support that, i.e. any struct or union
with the last element as a flex array should be recognized as having flexible
size.

[1] https://sourceware.org/pipermail/gcc-patches/2022-December/608912.html

[Bug tree-optimization/108540] [13 Regression] Frange miscompilation of ruby since r13-3261

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-01-25
 CC||aldyh at gcc dot gnu.org,
   ||amacleod at redhat dot com
   Target Milestone|--- |13.0
 Ever confirmed|0   |1
   Priority|P3  |P1

--- Comment #1 from Jakub Jelinek  ---
stdarg.h isn't needed, so:
__attribute__((noipa)) void
bar (const char *cp, unsigned long size, char sign, int dsgn)
{
  if (__builtin_strcmp (cp, "ZERO") != 0 || size != 4 || sign != '-' || dsgn !=
1)
__builtin_abort ();
}

__attribute__((noipa)) void
foo (int x, int ch, double d)
{
  const char *cp = "";
  unsigned long size = 0;
  char sign = '\0';
  switch (x)
{
case 42:
  if (__builtin_isinf (d))
{
  if (d < 0)
sign = '-';
  cp = "Inf";
  size = 3;
  break;
}
  if (__builtin_isnan (d))
{
  cp = "NaN";
  size = 3;
  break;
}
  if (d < 0)
{
  d = -d;
  sign = '-';
}
  else if (d == 0.0 && __builtin_signbit (d))
sign = '-';
  else
sign = '\0';
  if (ch == 'a' || ch == 'A')
{
  union U { long long l; double d; } u;
  int dsgn;
  u.d = d;
  if (u.l < 0)
{
  dsgn = 1;
  u.l &= 0x7fffLL;
}
  else
dsgn = 0;
  if (__builtin_isinf (d))
{
  cp = "INF";
  size = 3;
}
  else if (__builtin_isnan (d))
{
  cp = "NAN";
  size = 3;
}
  else if (d == 0)
{
  cp = "ZERO";
  size = 4;
}
  else
{
  cp = "WRONG";
  size = 5;
}
  bar (cp, size, sign, dsgn);
}
}
}

int
main ()
{
  foo (42, 'a', -0.0);
  return 0;
}

The testcase is hand-written from what I see in
https://github.com/ruby/ruby/blob/a528908271c678360d2d8ca232c178e7cdd340b4/vsnprintf.c#L529
https://github.com/ruby/ruby/blob/a528908271c678360d2d8ca232c178e7cdd340b4/vsnprintf.c#L1229
https://github.com/ruby/ruby/blob/a528908271c678360d2d8ca232c178e7cdd340b4/missing/dtoa.c#L3387
where hdtoa is inlined into cvt which is inlined into vfprintf.  This reduced
testcase reproduces on x86_64-linux too.

[Bug tree-optimization/108540] New: [13 Regression] Frange miscompilation of ruby since r13-3261

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

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

Bug ID: 108540
   Summary: [13 Regression] Frange miscompilation of ruby since
r13-3261
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

Since r13-3261-ga0c1a059101a3067d96211cbc4fae5905796d1db ruby is miscompiled
with LTO on powerpc64le-linux.
I've hand reduced it to:
#include 

__attribute__((noipa)) void
bar (const char *cp, unsigned long size, char sign, int dsgn)
{
  if (__builtin_strcmp (cp, "ZERO") != 0 || size != 4 || sign != '-' || dsgn !=
1)
__builtin_abort ();
}

__attribute__((noipa)) void
foo (int x, int ch, ...)
{
  va_list ap;
  const char *cp = "";
  unsigned long size = 0;
  char sign = '\0';
  double d;
  va_start (ap, ch);
  switch (x)
{
case 42:
  d = va_arg (ap, double);
  if (__builtin_isinf (d))
{
  if (d < 0)
sign = '-';
  cp = "Inf";
  size = 3;
  break;
}
  if (__builtin_isnan (d))
{
  cp = "NaN";
  size = 3;
  break;
}
  if (d < 0)
{
  d = -d;
  sign = '-';
}
  else if (d == 0.0 && __builtin_signbit (d))
sign = '-';
  else
sign = '\0';
  if (ch == 'a' || ch == 'A')
{
  union U { long long l; double d; } u;
  int dsgn;
  u.d = d;
  if (u.l < 0)
{
  dsgn = 1;
  u.l &= 0x7fffLL;
}
  else
dsgn = 0;
  if (__builtin_isinf (d))
{
  cp = "INF";
  size = 3;
}
  else if (__builtin_isnan (d))
{
  cp = "NAN";
  size = 3;
}
  else if (d == 0)
{
  cp = "ZERO";
  size = 4;
}
  else
{
  cp = "WRONG";
  size = 5;
}
  bar (cp, size, sign, dsgn);
}
}
  va_end (ap);
}

int
main ()
{
  foo (42, 'a', -0.0);
  return 0;
}

[Bug modula2/108182] gm2 driver mishandles target and multilib options

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

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #20 from Iain Sandoe  ---
there are undoubtedly improvements we can make to the driver - but in terms of
basic correctness, this can be considered fixed on trunk.

[Bug modula2/102343] gm2/cpp/pass/subaddr.mod FAILs for non-default multilib

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

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #5 from Iain Sandoe  ---
so fixed on trunk

[Bug modula2/102343] gm2/cpp/pass/subaddr.mod FAILs for non-default multilib

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Iain D Sandoe :

https://gcc.gnu.org/g:80cf2c5e8f496bed9c6facf55f9ae31d0d90fd28

commit r13-5373-g80cf2c5e8f496bed9c6facf55f9ae31d0d90fd28
Author: Iain Sandoe 
Date:   Mon Jan 16 14:07:20 2023 +

modula-2: Fixes for preprocessing [PR102343, PR108182].

Modula-2 uses the C preprocessor to implement handling for conditional
code and macros.  However, this is not done directly, because the process
is applied recursively to imported definitions and modules.

The cc1gm2 executable records the parameters as a template command line
needed to create a composite 'cc1 -E' for each file to be preprocessed
starting with the main file from the original command line.

This patch fixes the capture of the C preprocessor template to include
the target information needed for correct multilib operation.

In order to match the existing semantics of '-E, -M and -MM' these have
to be handled as a 'pre-processor only' job (i.e. the recursion is omitted
and only the main file is processed).

Whereas C-family front ends always pre-process, Modula-2 only does so
when specifically requested (via the -fcpp option).

'-MD, -MMD and -MQ' also require special handling, since (in principle)
these options can be applied to any command line (with -fcpp) providing
dependency information as a by-product.

TODO: the preprocessor is not able to determine def and mod dependencies
for Modula-2 and so the output of this only shows the object to module
dep.  We should be able to append the .def and .mod dependencies.

The patch amends save-temps handling to cater for the preprocessor
recursion and to avoid writing saved files into the source directories.

The patch changes the extension for Modula-2 preprocessed source to .m2i
to avoid clashes with .i.

The main driver code is amended to add default handlers for .mod and .m2i
so that a useful error message will be emitted if the Modula-2 compiler
is not built-in.

The compiler will now also handle code generation from a .m2i preprocessed
source.

TODO: We should not need to pass the '-c' option to the compiler to alter
the processing of init code.

Signed-off-by: Iain Sandoe 

PR modula2/102343
PR modula2/108182

gcc/ChangeLog:

* gcc.cc: Provide default specs for Modula-2 so that when the
language is not built-in better diagnostics are emitted for
attempts to use .mod or .m2i file extensions.

gcc/m2/ChangeLog:

* gm2-compiler/M2Comp.mod: Early exit for pre-processor-only jobs.
* gm2-compiler/M2Options.def (SetPPOnly, GetPPOnly, SetMD, GetMD,
SetMMD, GetMMD, SetMQ, GetMQ, SetObj, GetObj, SetDumpDir,
GetDumpDir):New.
* gm2-compiler/M2Options.mod:(SetPPOnly, GetPPOnly, SetMD, GetMD,
SetMMD, GetMMD, SetMQ, GetMQ, SetObj, GetObj, SetDumpDir,
GetDumpDir):New.
* gm2-compiler/M2Preprocess.def (PreprocessModule): Add flag to
indicate the main file.
* gm2-compiler/M2Preprocess.mod: Handle Preprocess-only jobs,
handle MD, MMD and MQ options.
* gm2-gcc/m2options.h (M2Options_SetPPOnly, M2Options_GetPPOnly,
M2Options_SetDumpDir, M2Options_SetMD, M2Options_GetMD,
M2Options_SetMMD, M2Options_GetMMD, M2Options_SetMQ,
M2Options_GetMQ,
M2Options_SetObj, M2Options_GetObj): New.
* gm2-gcc/m2type.cc (m2type_InitBaseTypes): Early exit for pre-
processor-only jobs.
* gm2-lang.cc (gm2_langhook_init): Handle preprocess-only commands.
(gm2_langhook_option_lang_mask): Claim C and Driver options so that
we can intercept them for building pre-processor commands.
(gm2_langhook_init_options): Collect the preprocessor line here.
Save options that have different actions for preprocessor and
compile
commands.
(gm2_langhook_handle_option): Only handle the modula-2 options
here.
(gm2_langhook_post_options): Do not create a back-end for pre-
processor-only jobs.
* gm2spec.cc (lang_specific_driver): Ignore PCH options, append a
scaffold-main for cases where we are building a main module with
-c.
* lang-specs.h: Revise to handle preprocessor-only jobs and to
consume pre-processed files.
* lang.opt: Remove Driver and C options copies (we claim these
separately).

[Bug modula2/108182] gm2 driver mishandles target and multilib options

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

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

--- Comment #19 from CVS Commits  ---
The master branch has been updated by Iain D Sandoe :

https://gcc.gnu.org/g:80cf2c5e8f496bed9c6facf55f9ae31d0d90fd28

commit r13-5373-g80cf2c5e8f496bed9c6facf55f9ae31d0d90fd28
Author: Iain Sandoe 
Date:   Mon Jan 16 14:07:20 2023 +

modula-2: Fixes for preprocessing [PR102343, PR108182].

Modula-2 uses the C preprocessor to implement handling for conditional
code and macros.  However, this is not done directly, because the process
is applied recursively to imported definitions and modules.

The cc1gm2 executable records the parameters as a template command line
needed to create a composite 'cc1 -E' for each file to be preprocessed
starting with the main file from the original command line.

This patch fixes the capture of the C preprocessor template to include
the target information needed for correct multilib operation.

In order to match the existing semantics of '-E, -M and -MM' these have
to be handled as a 'pre-processor only' job (i.e. the recursion is omitted
and only the main file is processed).

Whereas C-family front ends always pre-process, Modula-2 only does so
when specifically requested (via the -fcpp option).

'-MD, -MMD and -MQ' also require special handling, since (in principle)
these options can be applied to any command line (with -fcpp) providing
dependency information as a by-product.

TODO: the preprocessor is not able to determine def and mod dependencies
for Modula-2 and so the output of this only shows the object to module
dep.  We should be able to append the .def and .mod dependencies.

The patch amends save-temps handling to cater for the preprocessor
recursion and to avoid writing saved files into the source directories.

The patch changes the extension for Modula-2 preprocessed source to .m2i
to avoid clashes with .i.

The main driver code is amended to add default handlers for .mod and .m2i
so that a useful error message will be emitted if the Modula-2 compiler
is not built-in.

The compiler will now also handle code generation from a .m2i preprocessed
source.

TODO: We should not need to pass the '-c' option to the compiler to alter
the processing of init code.

Signed-off-by: Iain Sandoe 

PR modula2/102343
PR modula2/108182

gcc/ChangeLog:

* gcc.cc: Provide default specs for Modula-2 so that when the
language is not built-in better diagnostics are emitted for
attempts to use .mod or .m2i file extensions.

gcc/m2/ChangeLog:

* gm2-compiler/M2Comp.mod: Early exit for pre-processor-only jobs.
* gm2-compiler/M2Options.def (SetPPOnly, GetPPOnly, SetMD, GetMD,
SetMMD, GetMMD, SetMQ, GetMQ, SetObj, GetObj, SetDumpDir,
GetDumpDir):New.
* gm2-compiler/M2Options.mod:(SetPPOnly, GetPPOnly, SetMD, GetMD,
SetMMD, GetMMD, SetMQ, GetMQ, SetObj, GetObj, SetDumpDir,
GetDumpDir):New.
* gm2-compiler/M2Preprocess.def (PreprocessModule): Add flag to
indicate the main file.
* gm2-compiler/M2Preprocess.mod: Handle Preprocess-only jobs,
handle MD, MMD and MQ options.
* gm2-gcc/m2options.h (M2Options_SetPPOnly, M2Options_GetPPOnly,
M2Options_SetDumpDir, M2Options_SetMD, M2Options_GetMD,
M2Options_SetMMD, M2Options_GetMMD, M2Options_SetMQ,
M2Options_GetMQ,
M2Options_SetObj, M2Options_GetObj): New.
* gm2-gcc/m2type.cc (m2type_InitBaseTypes): Early exit for pre-
processor-only jobs.
* gm2-lang.cc (gm2_langhook_init): Handle preprocess-only commands.
(gm2_langhook_option_lang_mask): Claim C and Driver options so that
we can intercept them for building pre-processor commands.
(gm2_langhook_init_options): Collect the preprocessor line here.
Save options that have different actions for preprocessor and
compile
commands.
(gm2_langhook_handle_option): Only handle the modula-2 options
here.
(gm2_langhook_post_options): Do not create a back-end for pre-
processor-only jobs.
* gm2spec.cc (lang_specific_driver): Ignore PCH options, append a
scaffold-main for cases where we are building a main module with
-c.
* lang-specs.h: Revise to handle preprocessor-only jobs and to
consume pre-processed files.
* lang.opt: Remove Driver and C options copies (we claim these
separately).

[Bug tree-optimization/107952] tree-object-size: inconsistent size for flexible arrays nested in structs

[qing.zhao at oracle dot com via Gcc-bugs]

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

--- Comment #13 from Qing Zhao  ---
> On Jan 25, 2023, at 2:32 AM, rguenther at suse dot de 
>  wrote:
>> 
>> A little confused here:  
>>when the structure with a trailing flexible-array member is a middle
>> field of 
>>an outer structure, GCC extension will treat it as a flexible-array
>> too? But the
>>maximum size of this flexible-array will be bounded by the size of the
>> padding
>>of that field? 
>> Is the above understanding correct?
> 
> That's correct - at least when using the get_ref_base_and_extent
> API.  I see that when using array_ref_flexible_size_p it doesn't
> return true (but it's technically not _flexible_, we just treat it with
> a bound size that doesn't match the declared bound).
For the current array_ref_flexible_size_p, we include the following 3 cases:

   A. a ref to a flexible array member at the end of a structure;
   B. a ref to an array with a different type against the original decl;
  for example:

   short a[16] = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16 };
   (*((char(*)[16])&a[0]))[i+8]

   C. a ref to an array that was passed as a parameter;
  for example:

   int test (uint8_t *p, uint32_t t[1][1], int n) {
   for (int i = 0; i < 4; i++, p++)
 t[i][0] = …;

It basically mean: return true if REF is to an array whose actual size might be
larger than its upper bound implies. 

I feel that the case "when the structure with a trailing flexible-array member
is a middle field of an outer structure” still fit here, but not very sure,
need more thinking...

> 
> The first is handled by the function just fine,

No, even the first case is not recognized by the current
“array_ref_flexible_size_p”, it’s not been identified as a flexible array right
now.
Shall we include this case into “array_ref_flexible_size_p”?  (It’s a GCC
extension).

> it's the second with the bound size that's not and that isn't a good fit 
> there,
> though we do handle padding to the end of a declaration where
> we return true.
> 
>> Handle them separately instead?
> 
> I'm not sure how important it is to hande the middle array
> extending to padding, ISTR there was some real world code
> "miscompiled" when treating the array domain as written.

We can leave the 2nd case in a later time to resolve -:)
>

[Bug fortran/107424] [13 Regression] ICE in gfc_trans_omp_do, at fortran/trans-openmp.cc:5397 - and wrong code - with non-rectangular loops

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

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

--- Comment #10 from Tobias Burnus  ---
> now filed as PR middle-end/108459.

This has been fixed to mainline. Cross ref: also about collapsed loops but
otherwise unrelated: PR middle-end/108435 (loop-var with function nesting
issue)

 * * *

Patch for this PR, sorry-ing for non-unit loop steps, but otherwise working:

  https://gcc.gnu.org/pipermail/gcc-patches/2023-January/610584.html

Follow-up work needed (once accepted): Handling some/all cases of non-unit
steps; for some thoughts on handling this, see:

  https://gcc.gnu.org/pipermail/gcc-patches/2023-January/610351.html

[Bug target/105549] aarch64: Wrong va_arg alignment handling with packed bitfields and alignment

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

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

Christophe Lyon  changed:

   What|Removed |Added

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

--- Comment #9 from Christophe Lyon  ---
Fixed.

[Bug c++/108538] unexpected -Wnarrowing errors in -fpermissive mode

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2023-01-25
 Status|UNCONFIRMED |NEW
   Severity|normal  |enhancement
 CC||jason at gcc dot gnu.org
 Ever confirmed|0   |1
   Keywords||diagnostic

--- Comment #3 from Jonathan Wakely  ---
(In reply to Stas Sergeev from comment #2)
> But I used -fpermissive mode to
> compile the mix of c/c++.

It seems like you might be expecting more from -fpermissive than it actually
provides. It only affects a very limited set of diagnostics, and isn't a
general "compile invalid code" switch.

It might be reasonable to make it affect narrowing diagnostics though. The
downside would be complicating the code by adding even more interactions
between different switches and dialects.

Confirming as an enhancement request to relax some narrowing errors with
-fpermissive, but C++ front end maintainers should decide whether that's
actually desirable.

[Bug target/105549] aarch64: Wrong va_arg alignment handling with packed bitfields and alignment

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

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

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

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

commit r12-9067-gf593bfa059fbd2c145d8dd2bae4860959e9e55fe
Author: Christophe Lyon 
Date:   Tue Jun 14 21:08:33 2022 +

aarch64: fix warning emission for ABI break since GCC 9.1

While looking at PR 105549, which is about fixing the ABI break
introduced in GCC 9.1 in parameter alignment with bit-fields, we
noticed that the GCC 9.1 warning is not emitted in all the cases where
it should be.  This patch fixes that and the next patch in the series
fixes the GCC 9.1 break.

We split this into two patches since patch #2 introduces a new ABI
break starting with GCC 13.1.  This way, patch #1 can be back-ported
to release branches if needed to fix the GCC 9.1 warning issue.

The main idea is to add a new global boolean that indicates whether
we're expanding the start of a function, so that aarch64_layout_arg
can emit warnings for callees as well as callers.  This removes the
need for aarch64_function_arg_boundary to warn (with its incomplete
information).  However, in the first patch there are still cases where
we emit warnings were we should not; this is fixed in patch #2 where
we can distinguish between GCC 9.1 and GCC.13.1 ABI breaks properly.

The fix in aarch64_function_arg_boundary (replacing & with &&) looks
like an oversight of a previous commit in this area which changed
'abi_break' from a boolean to an integer.

We also take the opportunity to fix the comment above
aarch64_function_arg_alignment since the value of the abi_break
parameter was changed in a previous commit, no longer matching the
description.

2022-11-28  Christophe Lyon  
Richard Sandiford  

gcc/ChangeLog:

* config/aarch64/aarch64.cc (aarch64_function_arg_alignment): Fix
comment.
(aarch64_layout_arg): Factorize warning conditions.
(aarch64_function_arg_boundary): Fix typo.
* function.cc (currently_expanding_function_start): New variable.
(expand_function_start): Handle
currently_expanding_function_start.
* function.h (currently_expanding_function_start): Declare.

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/bitfield-abi-warning-align16-O2.c: New test.
* gcc.target/aarch64/bitfield-abi-warning-align16-O2-extra.c: New
test.
* gcc.target/aarch64/bitfield-abi-warning-align32-O2.c: New test.
* gcc.target/aarch64/bitfield-abi-warning-align32-O2-extra.c: New
test.
* gcc.target/aarch64/bitfield-abi-warning-align8-O2.c: New test.
* gcc.target/aarch64/bitfield-abi-warning.h: New test.
* g++.target/aarch64/bitfield-abi-warning-align16-O2.C: New test.
* g++.target/aarch64/bitfield-abi-warning-align16-O2-extra.C: New
test.
* g++.target/aarch64/bitfield-abi-warning-align32-O2.C: New test.
* g++.target/aarch64/bitfield-abi-warning-align32-O2-extra.C: New
test.
* g++.target/aarch64/bitfield-abi-warning-align8-O2.C: New test.
* g++.target/aarch64/bitfield-abi-warning.h: New test.

(cherry picked from commit 3df1a115be22caeab3ffe7afb12e71adb54ff132)

[Bug target/105549] aarch64: Wrong va_arg alignment handling with packed bitfields and alignment

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

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Christophe Lyon
:

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

commit r11-10485-gd7f8b1c54bd054d214a73d4b534d599365f8658b
Author: Christophe Lyon 
Date:   Tue Jun 14 21:08:33 2022 +

aarch64: fix warning emission for ABI break since GCC 9.1

While looking at PR 105549, which is about fixing the ABI break
introduced in GCC 9.1 in parameter alignment with bit-fields, we
noticed that the GCC 9.1 warning is not emitted in all the cases where
it should be.  This patch fixes that and the next patch in the series
fixes the GCC 9.1 break.

We split this into two patches since patch #2 introduces a new ABI
break starting with GCC 13.1.  This way, patch #1 can be back-ported
to release branches if needed to fix the GCC 9.1 warning issue.

The main idea is to add a new global boolean that indicates whether
we're expanding the start of a function, so that aarch64_layout_arg
can emit warnings for callees as well as callers.  This removes the
need for aarch64_function_arg_boundary to warn (with its incomplete
information).  However, in the first patch there are still cases where
we emit warnings were we should not; this is fixed in patch #2 where
we can distinguish between GCC 9.1 and GCC.13.1 ABI breaks properly.

The fix in aarch64_function_arg_boundary (replacing & with &&) looks
like an oversight of a previous commit in this area which changed
'abi_break' from a boolean to an integer.

We also take the opportunity to fix the comment above
aarch64_function_arg_alignment since the value of the abi_break
parameter was changed in a previous commit, no longer matching the
description.

2022-11-28  Christophe Lyon  
Richard Sandiford  

gcc/ChangeLog:

* config/aarch64/aarch64.c (aarch64_function_arg_alignment): Fix
comment.
(aarch64_layout_arg): Factorize warning conditions.
(aarch64_function_arg_boundary): Fix typo.
* function.c (currently_expanding_function_start): New variable.
(expand_function_start): Handle
currently_expanding_function_start.
* function.h (currently_expanding_function_start): Declare.

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/bitfield-abi-warning-align16-O2.c: New test.
* gcc.target/aarch64/bitfield-abi-warning-align16-O2-extra.c: New
test.
* gcc.target/aarch64/bitfield-abi-warning-align32-O2.c: New test.
* gcc.target/aarch64/bitfield-abi-warning-align32-O2-extra.c: New
test.
* gcc.target/aarch64/bitfield-abi-warning-align8-O2.c: New test.
* gcc.target/aarch64/bitfield-abi-warning.h: New test.
* g++.target/aarch64/bitfield-abi-warning-align16-O2.C: New test.
* g++.target/aarch64/bitfield-abi-warning-align16-O2-extra.C: New
test.
* g++.target/aarch64/bitfield-abi-warning-align32-O2.C: New test.
* g++.target/aarch64/bitfield-abi-warning-align32-O2-extra.C: New
test.
* g++.target/aarch64/bitfield-abi-warning-align8-O2.C: New test.
* g++.target/aarch64/bitfield-abi-warning.h: New test.

(cherry picked from commit 3df1a115be22caeab3ffe7afb12e71adb54ff132)

[Bug target/105549] aarch64: Wrong va_arg alignment handling with packed bitfields and alignment

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

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Christophe Lyon
:

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

commit r10-11174-gfea013065580084578b1b78d8f727c0323f2a9a0
Author: Christophe Lyon 
Date:   Tue Jan 24 09:46:30 2023 +

[PATCH] aarch64: fix warning emission for ABI break since GCC 9.1

While looking at PR 105549, which is about fixing the ABI break
introduced in GCC 9.1 in parameter alignment with bit-fields, we
noticed that the GCC 9.1 warning is not emitted in all the cases where
it should be.  This patch fixes that and the next patch in the series
fixes the GCC 9.1 break.

We split this into two patches since patch #2 introduces a new ABI
break starting with GCC 13.1.  This way, patch #1 can be back-ported
to release branches if needed to fix the GCC 9.1 warning issue.

The main idea is to add a new global boolean that indicates whether
we're expanding the start of a function, so that aarch64_layout_arg
can emit warnings for callees as well as callers.  This removes the
need for aarch64_function_arg_boundary to warn (with its incomplete
information).  However, in the first patch there are still cases where
we emit warnings were we should not; this is fixed in patch #2 where
we can distinguish between GCC 9.1 and GCC.13.1 ABI breaks properly.

The fix in aarch64_function_arg_boundary (replacing & with &&) looks
like an oversight of a previous commit in this area which changed
'abi_break' from a boolean to an integer.

We also take the opportunity to fix the comment above
aarch64_function_arg_alignment since the value of the abi_break
parameter was changed in a previous commit, no longer matching the
description.

2022-11-28  Christophe Lyon  
Richard Sandiford  

gcc/ChangeLog:

* config/aarch64/aarch64.c (aarch64_function_arg_alignment): Fix
comment.
(aarch64_layout_arg): Factorize warning conditions.
(aarch64_function_arg_boundary): Fix typo.
* function.c (currently_expanding_function_start): New variable.
(expand_function_start): Handle
currently_expanding_function_start.
* function.h (currently_expanding_function_start): Declare.

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/bitfield-abi-warning-align16-O2.c: New test.
* gcc.target/aarch64/bitfield-abi-warning-align16-O2-extra.c: New
test.
* gcc.target/aarch64/bitfield-abi-warning-align32-O2.c: New test.
* gcc.target/aarch64/bitfield-abi-warning-align32-O2-extra.c: New
test.
* gcc.target/aarch64/bitfield-abi-warning-align8-O2.c: New test.
* gcc.target/aarch64/bitfield-abi-warning.h: New test.
* g++.target/aarch64/bitfield-abi-warning-align16-O2.C: New test.
* g++.target/aarch64/bitfield-abi-warning-align16-O2-extra.C: New
test.
* g++.target/aarch64/bitfield-abi-warning-align32-O2.C: New test.
* g++.target/aarch64/bitfield-abi-warning-align32-O2-extra.C: New
test.
* g++.target/aarch64/bitfield-abi-warning-align8-O2.C: New test.
* g++.target/aarch64/bitfield-abi-warning.h: New test.

(cherry picked from commit 3df1a115be22caeab3ffe7afb12e71adb54ff132)

[Bug c++/108525] [13 Regression] ICE in write_method_parms with static on lambda with ... argument

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
Fixed.

[Bug c++/108525] [13 Regression] ICE in write_method_parms with static on lambda with ... argument

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:9d4c00cdaccc3decd07740e817387ce844ef3ac9

commit r13-5372-g9d4c00cdaccc3decd07740e817387ce844ef3ac9
Author: Jakub Jelinek 
Date:   Wed Jan 25 15:13:30 2023 +0100

c++: Fix up mangling of static lambdas [PR108525]

Before the P1169R4 changes, operator () of a lambda was
always a method, so it was fine to pass method_p = 1 unconditionally,
but it isn't always the case, so this patch adds a check for whether
it is a method or nor.

2023-01-25  Jakub Jelinek  

PR c++/108525
* mangle.cc (write_closure_type_name): Don't assume all
lambda operator() fns are methods.

* g++.dg/cpp23/static-operator-call5.C: New test.

[Bug c++/108503] [13 Regression] ICE in get_array_or_vector_nelts, at cp/constexpr.cc:4119

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

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

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

This hack works around it, by pretending the VAR_DECLs don't have
DECL_VALUE_EXPR between the deduction of the type and actually finalizing their
DECL_VALUE_EXPR (for !processing_template_decl only where we do the deduction
with temporarily incremented processing_template_decl).

[Bug c++/108539] Wrong register usage for -m16 -masm=intel -march=i386 on asm volatile

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
That is just misunderstanding of the inline asm syntax, please read the
documentation.
"=dl" doesn't mean that _a output is in %dl register, but either in %edx
register or
in any of the index registers (%eax %ebx %ecx %edx %esi %edi %ebp).
"=dh" means either in %edx register or in nowhere (h isn't a valid constraint).
So, when doing RA _b needs to be put into %edx (the low 8 bits of that aka %dl)
and _a into some index register other than %edx.

[Bug c++/108539] Wrong register usage for -m16 -masm=intel -march=i386 on asm volatile

[arheik at dnainternet dot net via Gcc-bugs]

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

--- Comment #1 from arheik at dnainternet dot net ---
Reproduced with these:

Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
11.3.0-1ubuntu1~22.04' --with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-11
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--enable-libphobos-checking=release --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-11-xKiWfi/gcc-11-11.3.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-11-xKiWfi/gcc-11-11.3.0/debian/tmp-gcn/usr
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
--with-build-config=bootstrap-lto-lean --enable-link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.3.0 (Ubuntu 11.3.0-1ubuntu1~22.04)

and

Using built-in specs.
COLLECT_GCC=g++-12
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/12/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
12.1.0-2ubuntu1~22.04' --with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-12
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin
--enable-default-pie --with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-12-sZcx2y/gcc-12-12.1.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-12-sZcx2y/gcc-12-12.1.0/debian/tmp-gcn/usr
--enable-offload-defaulted --without-cuda-driver --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.1.0 (Ubuntu 12.1.0-2ubuntu1~22.04)

[Bug c++/108539] New: Wrong register usage for -m16 -masm=intel -march=i386 on asm volatile

[arheik at dnainternet dot net via Gcc-bugs]

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

Bug ID: 108539
   Summary: Wrong register usage for -m16 -masm=intel -march=i386
on asm volatile
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arheik at dnainternet dot net
  Target Milestone: ---

Consider the following code (test.cpp):

void test(unsigned char& a, unsigned char& b)
{
unsigned char _a, _b;
asm volatile(
"mov dx, 0\n"
"mov bx, 0\n"
: "=dl" (_a), "=dh" (_b)
:
: "bx"
);
a = _a;
b = _b;
}

void main(void)
{
unsigned char a, b;
test(a, b);
}

Compiled with:
g++ -m16 -masm=intel -march=i386 -ffreestanding -fno-inline -mregparm=3
-fno-dwarf2-cfi-asm -fno-asynchronous-unwind-tables -fno-ident -O2 test.cpp -o
- -S

This generates for test():

_Z4testRhS_:
.LFB0:
pushesi
.LCFI0:
pushebx
.LCFI1:
mov ecx, edx
#APP
# 4 "test.cpp" 1
mov dx, 0
mov bx, 0

# 0 "" 2
#NO_APP
mov ebx, esi
mov BYTE PTR [eax], bl
mov BYTE PTR [ecx], dl
pop ebx
.LCFI2:
pop esi
.LCFI3:
ret

In which bl usage is clearly wrong (dh is missing) and ebx/eax/esi usage looks
suspect.

Compling with -mregparm=0 produces for test():

_Z4testRhS_:
.LFB0:
pushebx
.LCFI0:
#APP
# 4 "test.cpp" 1
mov dx, 0
mov bx, 0

# 0 "" 2
#NO_APP
mov eax, DWORD PTR 8[esp]
mov BYTE PTR [eax], cl
mov eax, DWORD PTR 12[esp]
mov BYTE PTR [eax], dl
pop ebx
.LCFI1:
ret

Which should use dh instead of cl.

[Bug libstdc++/107792] Output of default contract violation handler could be improved

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
Done

[Bug c++/104234] ICE with -fmodules-ts and std::map/_Rb_tree

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

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

Patrick Palka  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
 CC||ppalka at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2023-01-25

[Bug tree-optimization/107952] tree-object-size: inconsistent size for flexible arrays nested in structs

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

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

--- Comment #12 from Siddhesh Poyarekar  ---
(In reply to qinzhao from comment #7)
> (In reply to Richard Biener from comment #1)
> > GCC considered this as a flex-array. 
> 
> do you mean for the following example:
> 
> typedef struct {
>   char pad;
>   char data[];
> } F2;
> 
> typedef struct {
>   unsigned pad;
>   F2 flex;
> } S2;
> 
> although C standard disallow the above, GCC extension treats S2.flex.data as
> a flex-array? 
> 
> How about:
> 
> typedef struct {
>   char pad;
>   char data[];
> } F2;
> 
> typedef struct {
>   F2 flex;
>   unsigned pad;
> } S2;
> 
> do we have any documentation on this Gcc extension?

There's an open bug to document these semantics:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77650(In reply to
rguent...@suse.de from comment #11)
> On Tue, 24 Jan 2023, qing.zhao at oracle dot com wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107952
> > 
> > --- Comment #10 from Qing Zhao  ---
> > > --- Comment #9 from Richard Biener  ---
> > > 
> > > GCC handles for example
> > > 
> > > struct A { char data[1]; };
> > > struct B { int n; struct A a; };
> > > 
> > > as if the a.data[] array is a flex-array.
> > 
> > Okay. Then the maximum size of __builtin_object_size for it should be -1,
> > right?
> 
> I think so.

Why?  If the a B object is allocated with a visible allocator call, we can
return the correct size here too.

[Bug tree-optimization/108523] [13 Regression] -O1 -fcode-hoisting causes long compilation time ?

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

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

--- Comment #14 from Richard Biener  ---
Fixed, but I'll see if somebody comes up with a reduced testcase.

[Bug tree-optimization/108523] [13 Regression] -O1 -fcode-hoisting causes long compilation time ?

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

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

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

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

commit r13-5348-gc29d85359add807200a1a851026b4e4a9d6b714c
Author: Richard Biener 
Date:   Wed Jan 25 13:31:46 2023 +0100

tree-optimization/108523 - fix endless iteration in VN

The following fixes not converging iteration in value-numbering of
PHI nodes when we use an equivalence to prove the PHI node is
degenerate.  We have to avoid the situation where we oscillate
between the two equivalent values because the result is fed back
via a backedge.

PR tree-optimization/108523
* tree-ssa-sccvn.cc (visit_phi): Avoid using the exclusive
backedge value for the result when using predication to
prove equivalence.

[Bug c++/108538] unexpected -Wnarrowing errors in -fpermissive mode

[stsp at users dot sourceforge.net via Gcc-bugs]

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

--- Comment #2 from Stas Sergeev  ---
(In reply to Andreas Schwab from comment #1)
> It depends on the selected C++ standard.  C++11 does not allow narrowing
> conversions unconditionally.

Yes, I am not disputing that.
But I used -fpermissive mode to
compile the mix of c/c++.
-fpermissive downgrades many C++
errors to a warning, eating most
of the regular C. So my question
here is explicitly about -fpermissive
mode, I think it should downgrade
-Wnarrowing back into the warning.