[Bug tree-optimization/106138] Inefficient code generation for cases when results can be deduced at compile time

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||amacleod at redhat dot com

--- Comment #1 from Richard Biener  ---
So we're seeing

  b1_8 = x_7(D) == 4;
  # RANGE [0, 3] NONZERO 3
  _3 = x_7(D) & 3;
  b2_9 = _3 != 0;
  _5 = b1_8 & b2_9;

and fail to optimize that.  It somewhat looks like "relations" (on x_7), but
I'm not sure if suitable to handle for ranger.

Adding something in match.pd might be possible - the key is of course that
both b1 and b2 are derived from the same value.  I think we already have
a pattern looking at not intersecting nonzero bits.

[Bug middle-end/106142] [13 Regression] Wrong code on pcre-8.45, minimized

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
I can confirm it is fixed.

[Bug tree-optimization/106138] Inefficient code generation for cases when results can be deduced at compile time

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
I'd say reassoc would be a better place to handle it, so that we handle both
the logical op short circuit && and x == 4 && y == 25 && z != 16 && (x & 3) !=
0.

[Bug tree-optimization/106131] [10/11/12/13 Regression] -fstrict-aliasing breaks normal program that does not use any pointer or reference

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #8 from Richard Biener  ---
So the issue seems to be that fre1 transforms

   :
  _1 = (long unsigned int) i_13;
  _2 = _1 * 8;
  _3 = _18 + _2;
  _40 = MEM[(const struct Pair &)_18].a;
  _3->a = _40;
  _44 = MEM[(const struct Pair &)_18].b;
  _3->b = _44;
  if (i_13 == 0)
goto ; [INV]
  else
goto ; [INV]

   :
  _5 = (long unsigned int) i_13;
  _6 = _5 * 8;
  _7 = _18 + _6;
  _45 = MEM[(const struct Pair &)_18 + 16].a;
  _7->a = _45;
  _46 = MEM[(const struct Pair &)_18 + 16].b;
  _7->b = _46;

   :
  _9 = (long unsigned int) i_13;
  _10 = _9 * 8;
  _11 = _18 + _10;
  x = MEM[(const struct Pair &)_11];
  y = MEM[(const struct Pair &)_18 + 8];
  _47 = MEM[(const int &)&x + 4];
  _48 = MEM[(const int &)&y + 4];
  if (_47 < _48)
goto ; [50.00%]
  else
goto ; [50.00%]

into

...
   :
  x = MEM[(const struct Pair &)_3];
  y = MEM[(const struct Pair &)_18 + 8];
  _48 = MEM[(const int &)&y + 4];
  if (_44 < _48)
goto ; [50.00%]
  else
goto ; [50.00%]

CSEing the load _47 = MEM[(const int &)&x + 4]; to _44 crossing the
conditional clobber in BB4.

[Bug target/106069] [12/13 Regression] wrong code with -O -fno-tree-forwprop -maltivec on ppc64le

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

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

--- Comment #4 from luoxhu at gcc dot gnu.org ---
Reduced to:

#include 
extern "C" void *memcpy(void *, const void *, unsigned long);
typedef __attribute__((altivec(vector__))) unsigned native_simd_type;

union {
native_simd_type V;
int R[4];
} store_le_vec;

struct S {
S() = default;
S(unsigned B0) {
native_simd_type val{B0};
m_simd = val;
}
void store_le(unsigned char out[]) {
store_le_vec.V = m_simd;
unsigned int x0 = store_le_vec.R[0];
memcpy(out, &x0, 1);
}
static void transpose(S &B0, S B1, S B2, S B3) {
native_simd_type T0 = __builtin_vec_mergeh(B0.m_simd,
B2.m_simd);
native_simd_type T1 = __builtin_vec_mergeh(B1.m_simd,
B3.m_simd);
native_simd_type T2 = __builtin_vec_mergel(B0.m_simd,
B2.m_simd);
native_simd_type T3 = __builtin_vec_mergel(B1.m_simd,
B3.m_simd);
B0 = __builtin_vec_mergeh(T0, T1);
B3 = __builtin_vec_mergel(T2, T3);
printf ("B0: %x, %x,%x,%x\n", B0.m_simd[0], B0.m_simd[1],
B0.m_simd[2], B0.m_simd[3]);
}
S(native_simd_type x) : m_simd(x) {}
native_simd_type m_simd;
};

void
foo (unsigned char output[], unsigned state[], native_simd_type R0,
native_simd_type R1, native_simd_type R2, native_simd_type R3)
{
S R00; R00.m_simd = R0;
S R01; R01.m_simd = R1;
S R02; R02.m_simd = R2;
S R03; R03.m_simd = R3;
S::transpose(R00, R01, R02, R03);
R00.store_le(output);
}

unsigned char res[1];
unsigned main_state[]{1634760805, 60878,  2036477234, 6,
0,  825562964,  1471091955, 1346092787,
506976774,  4197066702, 518848283,  118491664,
0,  0,  0,  0};
int
main ()
{
native_simd_type R0 = native_simd_type {0x41fcef98, 0,0,0};
native_simd_type R1 =  native_simd_type {0x91648e8b, 0,0,0};
native_simd_type R2 = native_simd_type  {0x7dca18c6, 0,0,0};
native_simd_type R3 = native_simd_type  {0x61707865, 0,0,0};
foo (res, main_state, R0, R1, R2, R3);
if (res[0] != 152)
__builtin_abort();
}

[Bug target/106069] [12/13 Regression] wrong code with -O -fno-tree-forwprop -maltivec on ppc64le

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

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

--- Comment #5 from luoxhu at gcc dot gnu.org ---
Seems combine wrongly merged two vec_select instructions:

Trying 188 -> 199:
  188: r343:V4SI=vec_select(vec_concat(r168:V4SI,r338:V4SI),parallel)
  REG_DEAD r338:V4SI
  REG_DEAD r168:V4SI
  199: {r353:SI=vec_select(r343:V4SI,parallel);clobber scratch;}
Failed to match this instruction:
(parallel [
(set (reg:SI 353)
(vec_select:SI (reg:V4SI 338)
(parallel [
(const_int 3 [0x3])
])))
(clobber (scratch:V4SI))
(set (reg:V4SI 343)
(vec_select:V4SI (vec_concat:V8SI (reg/v:V4SI 168 [ R02$m_simd ])
(reg:V4SI 338))
(parallel [
(const_int 2 [0x2])
(const_int 6 [0x6])
(const_int 3 [0x3])
(const_int 7 [0x7])
])))
])
Failed to match this instruction:
(parallel [
(set (reg:SI 353)
(vec_select:SI (reg:V4SI 338)
(parallel [
(const_int 3 [0x3])
])))
(set (reg:V4SI 343)
(vec_select:V4SI (vec_concat:V8SI (reg/v:V4SI 168 [ R02$m_simd ])
(reg:V4SI 338))
(parallel [
(const_int 2 [0x2])
(const_int 6 [0x6])
(const_int 3 [0x3])
(const_int 7 [0x7])
])))
])
Successfully matched this instruction:
(set (reg:V4SI 343)
(vec_select:V4SI (vec_concat:V8SI (reg/v:V4SI 168 [ R02$m_simd ])
(reg:V4SI 338))
(parallel [
(const_int 2 [0x2])
(const_int 6 [0x6])
(const_int 3 [0x3])
(const_int 7 [0x7])
])))
Successfully matched this instruction:
(set (reg:SI 353)
(vec_select:SI (reg:V4SI 338)
(parallel [
(const_int 3 [0x3])
])))
allowing combination of insns 188 and 199
original costs 4 + 8 = 12
replacement costs 4 + 8 = 12
modifying insn i2   188:
r343:V4SI=vec_select(vec_concat(r168:V4SI,r338:V4SI),parallel)
  REG_DEAD r168:V4SI
deferring rescan insn with uid = 188.
modifying insn i3   199: {r353:SI=vec_select(r338:V4SI,parallel);clobber
scratch;}
  REG_DEAD r338:V4SI
deferring rescan insn with uid = 199.

[Bug c++/86491] bogus and unsuppressible warning: 'YYY' has a base 'ZZZ' whose type uses the anonymous namespace

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #12 from Jonathan Wakely  ---
In C++98 entities in an anonymous namespace did not have internal linkage, that
was changed for C++11. But they can still cause ODR violations. So the
diagnostic talks about anonymous namespaces because that's what causes the
potential for ODR violations, not linkage. THat was changed for C++11 so that
anonymous namespacs give internal linkage, and things with internal linkage can
now be used in templates, so the existing warning was extended to cover those
cases, but without rewording it.

In C++98 the testcase in comment 7 is simply ill-formed:

tM.C:3:15: error: ‘& d’ is not a valid template argument of type ‘int*’ in
C++98 because ‘d’ does not have external linkage

But if you change it to use an anonymous namespace it's valid in C++98:

# 1 "t1.H"
template < int *_C_OBJ_> struct NT{};
# 2 "tM.C"
namespace { int d; }
struct D : NT<&d> {};

This is valid in C++98 because 'd' doesn't have internal linkage (it's just
different in every translation unit), but it is still a potential ODR
violation, so there's a warning:

tM.C:3:8: warning: ‘D’ has a base ‘NT<(& {anonymous}::d)>’ whose type uses the
anonymous namespace [-Wsubobject-linkage]


Maybe for C++98 it should always say "anonymous namespace" since that's the
only way to trigger the warning, and for C++11 and later it should say internal
linkage, since that is true for names declared 'static' or in an anon
namespace. That seems like an easy change.

[Bug tree-optimization/106131] [10/11/12/13 Regression] -fstrict-aliasing breaks normal program that does not use any pointer or reference

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

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

--- Comment #9 from Richard Biener  ---
So the issue is in processing

  x = MEM[(const struct Pair &)_11];
  _47 = MEM[(const int &)&x + 4];

where we when visiting the def for 'x' continue the lookup with an
effective MEM[(const struct Pair &)_11 + 4]; but that looks for a store
of TBAA 'Pair' where we then correctly determine that _7->b = _46;
doesn't possibly alias.

A conservative fix restoring behavior before the relevant change is to
force alias set zero (no TBAA) for the offsetted lookup.

[Bug c++/106143] New: Add fix-it for missing ::value on trait with std::integral_constant base

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

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

Bug ID: 106143
   Summary: Add fix-it for missing ::value on trait with
std::integral_constant base
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

#include 
static_assert( std::is_void, "void is void is void" );
constexpr bool b = std::is_void;

v.C:2:34: error: expected primary-expression before ',' token
2 | static_assert( std::is_void, "void is void is void" );
  |  ^
v.C:3:38: error: expected primary-expression before ';' token
3 | constexpr bool b = std::is_void;
  |  ^

I do this all the time: forget to take the ::value of the trait and just use
the type itself. The diagnostic could be improved for this case, by detecting
that the type has a base that is a specialization of std::integral_constant and
suggesting adding ::value as a fix-it:

v.C:2:34: error: expected primary-expression before ',' token
2 | static_assert( std::is_void, "void is void is void" );
  |  ^
  |  ::value
v.C:3:38: error: expected primary-expression before ';' token
3 | constexpr bool b = std::is_void;
  |  ^
  |  ::value

[Bug c++/106143] Add fix-it for missing ::value on trait with std::integral_constant base

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
But the other suggestion could be to use std::is_void_v instead (at least
for C++17 and later), no?

[Bug c++/106143] Add fix-it for missing ::value on trait with std::integral_constant base

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

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

--- Comment #2 from Jonathan Wakely  ---
Clang gives a different error, but no more helpful:

v.C:2:34: error: expected '(' for function-style cast or type construction
static_assert( std::is_void, "void is void is void" );
   ~~^
v.C:3:38: error: expected '(' for function-style cast or type construction
constexpr bool b = std::is_void;
   ~~^
2 errors generated.

This is pointing out that std::is_void() would fix it, which is true. And
it's maybe more helpful than just saying "expected primary-expression" (which
means nothing to most users). But for the specific case of type traits we can
do better: using ::value to access the static member is more efficient to
compile than constructing a temporary and then finding its implicit conversion
to bool. So we should suggest ::value and not suggest ()

Maybe for C++17 we could also recognise when the derived trait type is in
namespace std and suggest the std::is_void_v variable template instead, on the
assumption that every std:: trait has a corresponding variable template now.

Ville suggests that instead of checking for a std::integral_constant base we
could just check if there's a nested ::value that is convertible to bool. That
would make it also work for boost-style traits that use an enumerator instead
of a static member, e.g.

struct is_foo { enum value = true; }; };


So maybe if we're using C++17, and it's a type defined in namespace std that
has a base class of std::integral_constant, then suggest is_foo_v.

Otherwise, if is_foo::value exists and is convertible to bool, then suggest
is_foo::value.

Otherwise, either print the current diagnostic, or maybe something more
user-friendly that says "you used a type where a value is needed", like EDG
does:

"v.C", line 2: error: type name is not allowed
  static_assert( std::is_void, "void is void is void" );
 ^

"v.C", line 3: error: type name is not allowed
  constexpr bool b = std::is_void;
 ^

[Bug c++/106143] Add fix-it for missing ::value on trait with std::integral_constant base

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

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Jakub Jelinek from comment #1)
> But the other suggestion could be to use std::is_void_v instead (at
> least for C++17 and later), no?

Indeed :-)

[Bug target/105930] [12/13 Regression] Excessive stack spill generation on 32-bit x86

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

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

--- Comment #26 from CVS Commits  ---
The master branch has been updated by Roger Sayle :

https://gcc.gnu.org/g:00193676a5a3e7e50e1fa6646bb5abb5a7b2acbb

commit r13-1362-g00193676a5a3e7e50e1fa6646bb5abb5a7b2acbb
Author: Roger Sayle 
Date:   Thu Jun 30 11:00:03 2022 +0100

Use xchg for DImode double word rotate by 32 bits with -m32 on x86.

This patch was motivated by the investigation of Linus Torvalds' spill
heavy cryptography kernels in PR 105930.  The di3 expander
handles all rotations by an immediate constant for 1..63 bits with the
exception of 32 bits, which FAILs and is then split by the middle-end.
This patch makes these 32-bit doubleword rotations consistent with the
other DImode rotations during reload, which results in reduced register
pressure, fewer instructions and the use of x86's xchg instruction
when appropriate.  In theory, xchg can be handled by register renaming,
but even on micro-architectures where it's implemented by 3 uops (no
worse than a three instruction shuffle), avoiding nominating a
"temporary" register, reduces user-visible register pressure (and
has obvious code size benefits).

The effects are best shown with the new testcase:

unsigned long long bar();
unsigned long long foo()
{
  unsigned long long x = bar();
  return (x>>32) | (x<<32);
}

for which GCC with -m32 -O2 currently generates:

subl$12, %esp
callbar
addl$12, %esp
movl%eax, %ecx
movl%edx, %eax
movl%ecx, %edx
ret

but with this patch now generates:

subl$12, %esp
callbar
addl$12, %esp
xchgl   %edx, %eax
ret

With this patch, the number of lines of assembly language generated
for the blake2b kernel (from the attachment to PR105930) decreases
from 5626 to 5404. Although there's an impressive reduction in
instruction count, there's no change/reduction in stack frame size.

2022-06-30  Roger Sayle  
Uroš Bizjak  

gcc/ChangeLog
* config/i386/i386.md (swap_mode): Rename from *swap to
provide gen_swapsi.
(di3): Handle !TARGET_64BIT rotations by 32 bits
via new gen_32di2_doubleword below.
(32di2_doubleword): New define_insn_and_split
that splits after reload as either a pair of move instructions
or an xchgl (using gen_swapsi).

gcc/testsuite/ChangeLog
* gcc.target/i386/xchg-3.c: New test case.

[Bug sanitizer/105614] mips64: sanitizer_platform_limits_linux.cpp:75:38: error: static assertion failed

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

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

--- Comment #14 from Xi Ruoyao  ---
(In reply to Chris Packham from comment #13)
> (In reply to Xi Ruoyao from comment #12)
> > Please provide info about how libsanitizer end up building with GCC 11.3 and
> > MIPS64 (such a combination is not supported and libsanitizer should not be
> > enabled automatically with it).
> 
> Original user report was
> https://github.com/crosstool-ng/crosstool-ng/issues/1733
> 
> In that case the user specifically enabled LIBSANITZER support so
> --enable-libsanitizer was passed to GCC's configure.
> 
> Based on what you're saying we should gate the LIBSANITZER on the
> architecture and GCC version. We do that for some options but LIBSANITZER is
> just enabled or disabled. We should probably also have LIBSANITZER tristate
> so we can let GCC decide to enable it if the stars align.

I think you can just put a warning like "enabling libsanitizer for unsupported
targets may break the build or produce unusable libsanitizer".  I guess a
similar warning should be added into gcc configure.ac as well.

[Bug target/104862] extern thread_local (emutls) code crashes with ASLR on Windows

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

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #3 from Eric Botcazou  ---
Investigating.

[Bug c++/100157] Support `__type_pack_element` like Clang

[m.cencora at gmail dot com via Gcc-bugs]

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

m.cencora at gmail dot com changed:

   What|Removed |Added

 CC||m.cencora at gmail dot com

--- Comment #2 from m.cencora at gmail dot com ---
Please consider also adding a builtin for fetching index of type in type list.
While there are some easy implementations (like following), they are still not
very performant.

template 
constexpr auto uniqId()
{
return __PRETTY_FUNCTION__;
}

template 
constexpr unsigned index_of_impl(U needle, const U (&haystack)[N])
{
for (unsigned i = 0u; i != N; ++i)
{
if (haystack[i] == needle)
{
return i;
}
}
return -1;
}

template 
constexpr auto index_of_v = index_of_impl(uniqId, { uniqId...});

using T1 = float;
using T2 = int;
struct A;
struct B;

auto c = index_of_v;

[Bug target/105782] [sparc64] Emission of questionable movxtod/movdtox with -mvis3

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

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #5 from Eric Botcazou  ---
Investigating.

[Bug tree-optimization/106114] [13 Regression] wrong code at -O1, -O2 and -O3 on x86_64-linux-gnu since r13-1268-g8c99e307b20c502e

[sam at gentoo dot org via Gcc-bugs]

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

--- Comment #11 from Sam James  ---
>This is less likely to occur in GCC12 as less places rewrite the IL under the 
>covers, but it should still be applied ot that branch just in case.

Should the bug be reopened for now then?

[Bug middle-end/106144] New: wide_int shifted_mask() and mask() do not agree

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

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

Bug ID: 106144
   Summary: wide_int shifted_mask() and mask() do not agree
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aldyh at gcc dot gnu.org
CC: amacleod at redhat dot com, mikestump at comcast dot net,
rsandifo at gcc dot gnu.org
  Target Milestone: ---

A mask of 128 bits should match a shifted mask of 128 bits where the shift is
0, but the following assert is failing:

  {
wide_int mask1 = wi::mask (128, false, 128);
wide_int mask2 = wi::shifted_mask (0, 128, false, 128);
mask1.dump ();
mask2.dump ();
gcc_assert (mask1 == mask2);
  }

The output is:

[...,0x], precision = 128
[0x,0x], precision = 128

I would expect both masks to be the same.

[Bug c++/100157] Support `__type_pack_element` like Clang

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

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to m.cencora from comment #2)
> Please consider also adding a builtin for fetching index of type in type
> list.

I am already considering it and it's one of the reasons I don't like the name
"type pack element". That name isn't easily extensible to the reverse case.

I would prefer a pair of similar names involving "type at index" and "index of
type" or something like that. Or "index to type" and "tpe to index".

> While there are some easy implementations (like following), they are still
> not very performant.

The uses in the standard library also require an error if the type occurs more
than once, which yours doesn't check. I intend to add a built-in that supports
both cases with a boolean flag to say whether to fail if the type is repeated.

FWIW I think __find_uniq_type_in_pack() in libstdc++'s  scales
better than yours (and checks for uniqueness).

[Bug c++/100157] Support `__type_pack_element` like Clang

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

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #3)
> I would prefer a pair of similar names involving "type at index" and "index
> of type" or something like that. Or "index to type" and "tpe to index".

Another option I considered is to just use the same name and make the same
built-in support both cases. If the first argument is an integer, return a
type, if the first argument is a type, return an integer. But that's a bit
subtle, and is complicated by wanting the boolean flag for the type-to-index
case.

[Bug bootstrap/106145] New: [12/13 Regression] /usr/bin/ld: libcommon.a(input.o): copy relocation against non-copyable protected symbol `__cxa_pure_virtual' on aarch64-linux-gnu

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

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

Bug ID: 106145
   Summary: [12/13 Regression] /usr/bin/ld: libcommon.a(input.o):
copy relocation against non-copyable protected symbol
`__cxa_pure_virtual' on aarch64-linux-gnu
   Product: gcc
   Version: 12.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

this is seen building a native compiler on aarch64-linux-gnu using trunk and
also using the current gcc-12 branch. binutils trunk and glibc 2.35 are used
for the build.

[Bug c++/100157] Support `__type_pack_element` like Clang

[m.cencora at gmail dot com via Gcc-bugs]

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

--- Comment #5 from m.cencora at gmail dot com ---
Yeah, __is_same builtin beats custom unique-id comparisons, but it is available
only since gcc-10 so unavailable for me.

Recently I discovered this one (only works for unique types), and it is twice
as fast as __is_same in my scenarios (I guess mainly due to memoization):

template 
struct indexed_type
{
   unsigned idx;
};

template 
struct indexed_type_list : indexed_type...
{
   constexpr indexed_type_list(unsigned i = 0)
 : indexed_type{i++}...
   {}
};

template 
constexpr indexed_type_list indexed_type_list_instance;


template 
constexpr auto index_of =
static_cast>(indexed_type_list_instance).idx;

Anyway, thanks for working on this topic!

[Bug fortran/103413] [10/11/12/13 Regression] ICE: Invalid expression in gfc_element_size since r10-2083-g8dc63166e0b85954

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

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

--- Comment #8 from Martin Liška  ---
> I'm not subscribed to fortran@ or gcc-patches@.
> Even If I subscribe to a list what good would it
> do to send an email?  Someone might glance at 
> it.  Then what?  I cannot commit as I don't use
> git (an unfortunate consequence of dropping svn)?

Then somebody can review the patch and commit on your behalf, that's not
problem.
Btw. why do you refuse to learn git, it's much better tool than SVN and for
simple use-case (committing to master) is pretty simple.

> 
> I don't add patches to a PR if they do not fix
> the problem.

[Bug c/106146] New: [instcombine] a redundant movprfx insn compare to llvm

[zhongyunde at huawei dot com via Gcc-bugs]

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

Bug ID: 106146
   Summary: [instcombine] a redundant movprfx insn compare to llvm
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhongyunde at huawei dot com
  Target Milestone: ---

* test case, gcc has a redundant movprfx insn in the kernel loop body, see
detail https://gcc.godbolt.org/z/8vG4PzM18. 

```
#include 

#define ARRAY_ALIGNMENT 64
#define LEN_2D 128ll
#define LEN_1D 8000ll
#define iterations 1
typedef float real_t;

__attribute__((aligned(ARRAY_ALIGNMENT))) real_t a[LEN_1D],b[LEN_1D];

void s113_tuned(void) {
for (int nl = 0; nl < 4*iterations; nl++) {
int64_t i = 1;
svbool_t pg = svwhilelt_b32(i, LEN_1D);
svfloat32_t a0v = svdup_f32(a[0]);
do {
svfloat32_t bv = svld1_f32(pg, &b[i]);
svfloat32_t res = svadd_z(pg, bv, a0v);
svst1(pg, &a[i], res);
i += svcntw();
pg = svwhilelt_b32(i, LEN_1D);
} while (svptest_any(svptrue_b32(), pg));
}
return;
}
```

* gcc's kernel loop
```
.L2:
ld1wz0.s, p0/z, [x3, x0, lsl 2]
movprfx z0.s, p0/z, z0.s
faddz0.s, p0/m, z0.s, z1.s
st1wz0.s, p0, [x1, x0, lsl 2]
incwx0
whilelt p0.s, x0, x2
b.any   .L2
```

* llvm's kernel loop:
```
.LBB0_2://   Parent Loop BB0_1 Depth=1
ld1w{ z1.s }, p2/z, [x13, x14, lsl #2]
faddz1.s, p2/m, z1.s, z0.s
st1w{ z1.s }, p2, [x12, x14, lsl #2]
add x14, x10, x14
whilelt p2.s, x14, x9
b.ne.LBB0_2
```

[Bug analyzer/106147] New: RFE: -fanalyzer could complain about some cases of infinite loops and infinite recursion

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

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

Bug ID: 106147
   Summary: RFE: -fanalyzer could complain about some cases of
infinite loops and infinite recursion
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

We can't solve the halting problem, but maybe we can detect some cases where
the code *definitely* loops forever or has infinite recursion, where there are
no state changes or possible interactions with the outside world.

See:
  https://cwe.mitre.org/data/definitions/674.html
and:
  https://cwe.mitre.org/data/definitions/835.html

Juliet 1.3 has testcases for:
  (a) CWE674_Uncontrolled_Recursion/
  (b) CWE835_Infinite_Loop/

where (a) makes a distinction between actually unbounded vs a buggy loop that
counts down from UINT_MAX (pushing UINT_MAX stack frames is probably going to
crash).

All of the test cases in (b) perform output in an infinite loop, which I'd
argue is not a bug, as the program is generating output that's visible to the
outside world.

Compare CWE 835 examples 1 and 2.  Example 1 repeatedly calls "connect" in a
loop, which I don't think -fanalyzer is going to be able to reason about,
whereas 2 has logic:

  while (inventoryCount > minimumCount) {
inventoryCount = inventoryCount - rateSold;
days++;
  }

where if rateSold is 0, this effectively becomes:

  while (inventoryCount > minimumCount) {
days++;
  }

and thus an infinite loop with no observable effects; possible interaction with
taint (e.g. if rateSold is under attacker control)

[Bug c++/100157] Support `__type_pack_element` like Clang

[vittorio.romeo at outlook dot com via Gcc-bugs]

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

--- Comment #6 from Vittorio Romeo  ---
Thank you, Jonathan, for looking into this. I feel like it might be worthwhile
to keep the same name as Clang for compatibility, or maybe talk to some Clang
developers and see if there can be an agreement on naming and design that works
for both compilers -- would be nice to have something that works for both GCC
and Clang in the same way.

[Bug analyzer/106147] RFE: -fanalyzer could complain about some cases of infinite loops and infinite recursion

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

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

--- Comment #1 from David Malcolm  ---
Possible implementation idea: look at state merging when building the exploded
graph: if we're merging an identical state in a loop, with no variants, then
complain.

[Bug tree-optimization/106126] [12 Regression] tree check fail in useless_type_conversion_p, at gimple-expr.cc:87 since r13-1184-g57424087e82db140

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #14 from Martin Liška  ---
(In reply to luoxhu from comment #13)
> Otherwise we need record first_bb when conditions_in_bbs->is_empty, then
> check that in is_beneficial, ordered_remove the info entry if that bb is not
> the first "if condition" with side_effect statement in it, the fix would be

No, we need to record if a BB has a side effect and allow only side effects for
a first BB in the main loop in pass_if_to_switch::execute. I'm testing a patch
candidate.

> as below, but I am not sure whether it is worth&correct way doing this to
> handle both PR105740 and PR106126?

Well, I replied in PR105740 where the problem is one needs to run the pass
later.

[Bug c++/100157] Support `__type_pack_element` like Clang

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

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

--- Comment #7 from Jonathan Wakely  ---
(In reply to m.cencora from comment #5)
> Yeah, __is_same builtin beats custom unique-id comparisons, but it is
> available only since gcc-10 so unavailable for me.

GCC has had __is_same_as since 6.1 though. Much later, __is_same was added as
another spelling for it (PR 92271).

[Bug c++/100157] Support `__type_pack_element` like Clang

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

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

--- Comment #8 from Jonathan Wakely  ---
(In reply to Vittorio Romeo from comment #6)
> worthwhile to keep the same name as Clang for compatibility,

No, that's not an option. Clang's is a built-in template, GCC's can't be (it
would require considerable internal reworking to support that).

That's also why we have __integer_pack(N)... instead of __make_integer_seq<>.

Since GCC's built-in has to use different syntax, it would be a disaster to use
the same name.

#if __has_builtin(__type_pack_element)
// now what? is it a template or a function?
#endif

[Bug c++/100157] Support `__type_pack_element` like Clang

[vittorio.romeo at outlook dot com via Gcc-bugs]

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

--- Comment #9 from Vittorio Romeo  ---
(In reply to Jonathan Wakely from comment #8)
> (In reply to Vittorio Romeo from comment #6)
> > worthwhile to keep the same name as Clang for compatibility,
> 
> No, that's not an option. Clang's is a built-in template, GCC's can't be (it
> would require considerable internal reworking to support that).
> 
> That's also why we have __integer_pack(N)... instead of __make_integer_seq<>.
> 
> Since GCC's built-in has to use different syntax, it would be a disaster to
> use the same name.
> 
> #if __has_builtin(__type_pack_element)
> // now what? is it a template or a function?
> #endif

Got it, I didn't realize that they had to be wildly different. I guess that as
long as a library developer can wrap either under a portable macro, it should
be fine.

[Bug c++/100157] Support `__type_pack_element` like Clang

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

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

--- Comment #10 from Jonathan Wakely  ---
FWIW std::tuple_element_t<1000, tuple> takes 97% less
memory and takes 80% less time with my patch. I just need to fix a problem with
debuginfo generation.

[Bug libstdc++/88881] std::filesystem::status gives bad results on mingw32

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

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

--- Comment #24 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:6c96b14a19a9e6c365eacc59868a866b99f9786d

commit r13-1365-g6c96b14a19a9e6c365eacc59868a866b99f9786d
Author: Jonathan Wakely 
Date:   Tue Jun 28 15:56:30 2022 +0100

libstdc++: Fix experimental::filesystem::status on Windows [PR1]

Although the Filesystem TS isn't properly supported on Windows (unlike
the C++17 Filesystem lib), most tests do pass. Two of the failures are
due to PR 1 which was only fixed for std::filesystem not the TS.
This applies the fix to the TS implementation too.

libstdc++-v3/ChangeLog:

PR libstdc++/1
* src/filesystem/ops.cc (has_trailing_slash): New helper
function.
(fs::status): Strip trailing slashes.
(fs::symlink_status): Likewise.
*
testsuite/experimental/filesystem/operations/temp_directory_path.cc:
Clean the environment before each test and use TMP instead of
TMPDIR so the test passes on Windows.

[Bug bootstrap/106145] [12/13 Regression] /usr/bin/ld: libcommon.a(input.o): copy relocation against non-copyable protected symbol `__cxa_pure_virtual' on aarch64-linux-gnu

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

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

--- Comment #1 from Andrew Pinski  ---
This sounds like a binutils bug 

[Bug c++/106084] using constructor fails to inherit consteval

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #1 from Patrick Palka  ---
dup

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

[Bug c++/104490] Cannot inherit consteval constructor

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ldalessandro at gmail dot com

--- Comment #3 from Patrick Palka  ---
*** Bug 106084 has been marked as a duplicate of this bug. ***

[Bug middle-end/106133] ICE: SIGSEGV in diagnostic_output_format_init_json_file() with -fdiagnostics-format=json-file -E

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||dmalcolm at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-06-30

--- Comment #1 from Martin Liška  ---
With -E the base_file_name == NULL. What about the following patch:

diff --git a/gcc/diagnostic.cc b/gcc/diagnostic.cc
index 22f7b0b6d6e..5d0137fd974 100644
--- a/gcc/diagnostic.cc
+++ b/gcc/diagnostic.cc
@@ -2246,6 +2246,9 @@ diagnostic_output_format_init (diagnostic_context
*context,
   const char *base_file_name,
   enum diagnostics_output_format format)
 {
+  if (base_file_name == NULL)
+return;
+
   switch (format)
 {
 default:

David, what do you think?

[Bug middle-end/106133] ICE: SIGSEGV in diagnostic_output_format_init_json_file() with -fdiagnostics-format=json-file -E

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

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug lto/106129] [12/13 Regression] LTO option merging broken

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Joseph Myers :

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

commit r13-1368-g8a8ee37a3325f1009034245676ef4e482c0444a2
Author: Joseph Myers 
Date:   Thu Jun 30 16:41:40 2022 +

lto: Fix option merging [PR106129]

The LTO merging of options from different input files was broken by:

commit 227a2ecf663d69972b851f51f1934d18927b62cd
Author: Martin Liska 
Date:   Fri Mar 12 11:53:47 2021 +0100

lto-wrapper: Use vec data type.

Previously, find_and_merge_options would merge options it read into
those in *opts. After this commit, options in *opts on entry to
find_and_merge_options are ignored; the only merging that takes place
is between multiple sets of options in the same input file that are
read in the same call to this function (not sure how that case can
occur at all). The effects include, for example, that if some objects
are built with PIC enabled and others with it disabled, and the last
LTO object processed has PIC enabled, the choice of PIC for the last
object will result in the whole program being built as PIC, when the
merging logic is intended to ensure that a mixture of PIC and non-PIC
objects results in the whole program being built as non-PIC.

Fix this with an extra argument to find_and_merge_options to determine
whether merging should take place.  This shows up a second issue with
that commit (which I think wasn't actually intended to change code
semantics at all): once merging is enabled again, the check for
-Xassembler options became an infinite loop in the case where both
inputs had -Xassembler options, with the same first option, so fix
that loop to restore the previous semantics.

Note that I'm not sure how LTO option merging might be tested in the
testsuite (clearly there wasn't sufficient, if any, coverage to detect
these bugs).

Bootstrapped with no regressions for x86_64-pc-linux-gnu.

PR lto/106129
* lto-wrapper.cc (find_option): Add argument start.
(merge_and_complain): Loop over existing_opt_index and
existing_opt2_index for Xassembler check.  Update calls to
find_option.
(find_and_merge_options): Add argument first to determine whether
to merge options with those passed in *opts.
(run_gcc): Update calls to find_and_merge_options.

[Bug lto/106129] [12 Regression] LTO option merging broken

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

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

Joseph S. Myers  changed:

   What|Removed |Added

   Last reconfirmed||2022-06-30
 Ever confirmed|0   |1
Summary|[12/13 Regression] LTO  |[12 Regression] LTO option
   |option merging broken   |merging broken
 Status|UNCONFIRMED |NEW

--- Comment #2 from Joseph S. Myers  ---
Fixed so far for GCC 13.

[Bug target/106069] [12/13 Regression] wrong code with -O -fno-tree-forwprop -maltivec on ppc64le

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

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

--- Comment #6 from Segher Boessenkool  ---
What is wrong there?  It isn't obvious.  You may need to show insns 188 and 199
in non-slim form, "slim" is very lossy.

[Bug target/106069] [12/13 Regression] wrong code with -O -fno-tree-forwprop -maltivec on ppc64le

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

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

--- Comment #7 from Segher Boessenkool  ---
(The original insns, before this combination.)

[Bug c/106148] New: RFE: warn about =- typos

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

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

Bug ID: 106148
   Summary: RFE: warn about =- typos
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

Spot the mistake in the following code:

  inbuf += OCB_BLOCK_LEN;
  inbuflen -= OCB_BLOCK_LEN;
  outbuf += OCB_BLOCK_LEN;
  outbuflen =- OCB_BLOCK_LEN;


The C and C++ frontends should warn that the:

  outbuflen =- OCB_BLOCK_LEN;

is parsed as:

  outbuflen = -OCB_BLOCK_LEN;

when presumably the user meant to write:

  outbuflen -= OCB_BLOCK_LEN;

but transposed the - and =.

A similar thing was seen in OpenJDK's java code:
  https://bugs.openjdk.org/browse/JDK-8286689
which had:
  to =- (int) TimeUnit.NANOSECONDS.toMillis(adjust);
rather than:
  to -= (int) TimeUnit.NANOSECONDS.toMillis(adjust);
fixed by:
 
https://github.com/openjdk/jdk/commit/0be1f3e1b0f4ac515a86e9f8e1999dc090b1bdd2

I wondered if any other operators could be confused this way: you need a unary
prefix operator that can also be part of an assignment operator.

Comparing
  https://en.cppreference.com/w/c/language/operator_assignment
and the unary prefix operators on:
  https://en.cppreference.com/w/c/language/expressions

I think the confusable operators are: +, -, *, and &
i.e.
   =+   vs   +=
   =-   vs   -=
   =*   vs   *=
   =&   vs   &=

of which I think the * and & are likely to result in type errors, whereas =+
and =- are probably most likely typos to lead to silently doing what a casual
reader doesn't expect.  =+ has only a shift key difference; - and = seem most
likely due to visual impact and U.S. keyboard location.

Proposed implementation: if the C/C++ tokenizers see:

   [..., EQUAL token, no whitespace, OPERATOR token, whitespace, ...] 

where OPERATOR is PLUS or MINUS

then complain that "=OP" is not "OP=" or somesuch.

What to call it?  (bikeshed alert)
  -Wmisleading-unary-operator
  -Wprobable-typo
  -Wmisleading-whitespace
  -Wsuspicious-token

Clang warns about this:
  https://godbolt.org/z/Kqd9nja3E
but doesn't seem to have a command-line option to control the warning.

[Bug c/106148] RFE: warn about =- typos

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
I think this was also requested in bug 45358.

[Bug middle-end/106144] wide_int shifted_mask() and mask() do not agree

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
I think this is a bug in wi::shifted_mask, { -1 } with len = 1 from wi::mask is
canonical 128-bit precision -1, { -1, -1 } with len = 2 from wi::shifted_mask
is not.

[Bug libstdc++/106149] New: [13 regression] g++.dg/warn/Warray-bounds-16.C had bogus errors after r13-1366-g1eef21ccfa5988

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

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

Bug ID: 106149
   Summary: [13 regression] g++.dg/warn/Warray-bounds-16.C had
bogus errors after r13-1366-g1eef21ccfa5988
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:1eef21ccfa5988a23a3b71a99613f27ea6a26da6, r13-1366-g1eef21ccfa5988
make  -k check-gcc RUNTESTFLAGS="--target_board=unix'{-m32}'
dg.exp=g++.dg/warn/Warray-bounds-16.C"
FAIL: g++.dg/warn/Warray-bounds-16.C  -std=gnu++98 pr102690 (test for bogus
messages, line 22)
FAIL: g++.dg/warn/Warray-bounds-16.C  -std=gnu++14 pr102690 (test for bogus
messages, line 22)
FAIL: g++.dg/warn/Warray-bounds-16.C  -std=gnu++17 pr102690 (test for bogus
messages, line 22)
FAIL: g++.dg/warn/Warray-bounds-16.C  -std=gnu++20 pr102690 (test for bogus
messages, line 22)
# of expected passes4
# of unexpected failures4


I am seeing this only for -m32 test runs.


spawn -ignore SIGHUP
/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++/../../xg++
-B/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++/../../
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/warn/Warray-bounds-16.C -m32
-fdiagnostics-plain-output -nostdinc++
-I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/32/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/32/libstdc++-v3/include
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/libsupc++
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/include/backward
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/util -fmessage-length=0
-std=gnu++98 -O2 -Wall -fdump-tree-optimized -S -o Warray-bounds-16.s
In constructor 'S::S(int)',
inlined from 'void __static_initialization_and_destruction_0()' at
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/warn/Warray-bounds-16.C:26:7,
inlined from '(static initializers for
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/warn/Warray-bounds-16.C)' at
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/warn/Warray-bounds-16.C:26:8:
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/warn/Warray-bounds-16.C:22:7:
warning: array subscript [0, 536870911] is outside array bounds of 'void [0]'
[-Warray-bounds]
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/warn/Warray-bounds-16.C:19:51:
note: object of size 0 allocated by 'operator new []'
FAIL: g++.dg/warn/Warray-bounds-16.C  -std=gnu++98 pr102690 (test for bogus
messages, line 22)


commit 1eef21ccfa5988a23a3b71a99613f27ea6a26da6
Author: Jonathan Wakely 
Date:   Tue Jun 28 16:09:21 2022 +0100

libstdc++: Improve exceptions thrown from fs::temp_directory_path

[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)

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

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #44 from Segher Boessenkool  ---
This was fixed on 9 and later.  Closing.

[Bug c++/106150] New: Incorrect error for defaulted anonymous union member

[jens.maurer at gmx dot net via Gcc-bugs]

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

Bug ID: 106150
   Summary: Incorrect error for defaulted anonymous union member
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jens.maurer at gmx dot net
  Target Milestone: ---

The following is valid, but yields an error with gcc 12.1:

struct A {
   A() { }
};

struct V {
   V() { };
   ~V() { }
};


struct S {
   S();
   ~S() {}

   union {
 A a = {};
 V v;
   };
};

S::S() = default;


x.cc:22:1: note: ‘S::S()’ is implicitly deleted because the default definition
would be ill-formed:
   22 | S::S() = default;
  | ^
x.cc:18:8: error: union member ‘Sv’ with non-trivial
‘V::V()’
   18 |  V v;
  |^


Replacing "= default" with "{}" makes the error go away.

None of the items in [class.default.ctor] p2 applies, in particular p2.2 does
not apply because S::a has a default member initializer.

[Bug middle-end/106144] wide_int shifted_mask() and mask() do not agree

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Last reconfirmed||2022-06-30
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

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

Untested fix.

[Bug fortran/103693] [12/13 Regression] ICE in gfc_array_dimen_size(): Bad EXPR_ARRAY expr since r12-4967-gbcf3728abe848888

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

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

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

https://gcc.gnu.org/g:4c233cabbe388a6b8957c1507e129090e9267ceb

commit r13-1370-g4c233cabbe388a6b8957c1507e129090e9267ceb
Author: Harald Anlauf 
Date:   Wed Jun 29 21:36:17 2022 +0200

Fortran: error recovery on invalid CLASS(), PARAMETER declarations
[PR105243]

gcc/fortran/ChangeLog:

PR fortran/103137
PR fortran/103138
PR fortran/103693
PR fortran/105243
* decl.cc (gfc_match_data_decl): Reject CLASS entity declaration
when it is given the PARAMETER attribute.

gcc/testsuite/ChangeLog:

PR fortran/103137
PR fortran/103138
PR fortran/103693
PR fortran/105243
* gfortran.dg/class_58.f90: Fix test.
* gfortran.dg/class_73.f90: New test.

Co-authored-by: Steven G. Kargl 

[Bug fortran/103138] [12/13 Regression] ICE in gfc_simplify_cshift, at fortran/simplify.c:2139 since r12-4967-gbcf3728abe848888

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

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

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

https://gcc.gnu.org/g:4c233cabbe388a6b8957c1507e129090e9267ceb

commit r13-1370-g4c233cabbe388a6b8957c1507e129090e9267ceb
Author: Harald Anlauf 
Date:   Wed Jun 29 21:36:17 2022 +0200

Fortran: error recovery on invalid CLASS(), PARAMETER declarations
[PR105243]

gcc/fortran/ChangeLog:

PR fortran/103137
PR fortran/103138
PR fortran/103693
PR fortran/105243
* decl.cc (gfc_match_data_decl): Reject CLASS entity declaration
when it is given the PARAMETER attribute.

gcc/testsuite/ChangeLog:

PR fortran/103137
PR fortran/103138
PR fortran/103693
PR fortran/105243
* gfortran.dg/class_58.f90: Fix test.
* gfortran.dg/class_73.f90: New test.

Co-authored-by: Steven G. Kargl 

[Bug fortran/103137] [12/13 Regression] ICE in gfc_simplify_transpose, at fortran/simplify.c:8181 since r12-4967-gbcf3728abe848888

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

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

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

https://gcc.gnu.org/g:4c233cabbe388a6b8957c1507e129090e9267ceb

commit r13-1370-g4c233cabbe388a6b8957c1507e129090e9267ceb
Author: Harald Anlauf 
Date:   Wed Jun 29 21:36:17 2022 +0200

Fortran: error recovery on invalid CLASS(), PARAMETER declarations
[PR105243]

gcc/fortran/ChangeLog:

PR fortran/103137
PR fortran/103138
PR fortran/103693
PR fortran/105243
* decl.cc (gfc_match_data_decl): Reject CLASS entity declaration
when it is given the PARAMETER attribute.

gcc/testsuite/ChangeLog:

PR fortran/103137
PR fortran/103138
PR fortran/103693
PR fortran/105243
* gfortran.dg/class_58.f90: Fix test.
* gfortran.dg/class_73.f90: New test.

Co-authored-by: Steven G. Kargl 

[Bug fortran/105243] ICE in next_char, at fortran/io.cc:160

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

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

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

https://gcc.gnu.org/g:4c233cabbe388a6b8957c1507e129090e9267ceb

commit r13-1370-g4c233cabbe388a6b8957c1507e129090e9267ceb
Author: Harald Anlauf 
Date:   Wed Jun 29 21:36:17 2022 +0200

Fortran: error recovery on invalid CLASS(), PARAMETER declarations
[PR105243]

gcc/fortran/ChangeLog:

PR fortran/103137
PR fortran/103138
PR fortran/103693
PR fortran/105243
* decl.cc (gfc_match_data_decl): Reject CLASS entity declaration
when it is given the PARAMETER attribute.

gcc/testsuite/ChangeLog:

PR fortran/103137
PR fortran/103138
PR fortran/103693
PR fortran/105243
* gfortran.dg/class_58.f90: Fix test.
* gfortran.dg/class_73.f90: New test.

Co-authored-by: Steven G. Kargl 

[Bug c++/106151] New: Inconsistent optimization when defaulting aggregate vs non-aggregate

[barry.revzin at gmail dot com via Gcc-bugs]

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

Bug ID: 106151
   Summary: Inconsistent optimization when defaulting aggregate vs
non-aggregate
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

Consider this example:

using size_t = decltype(sizeof(0));

struct string_view {
// string_view() : ptr(nullptr), len(0) { }
string_view() = default;

char const* ptr = nullptr;
size_t len = 0;
};

struct Fields
{
string_view a;
string_view b;
string_view c;
string_view d;
string_view e;
string_view f;
};

struct Foo : Fields
{
void clear();

Foo() = default;
};

void Foo::clear() {
*this = Foo{};
}

struct Bar : Fields
{
// No constructor, not even defaulted.

void clear();
};

void Bar::clear() {
*this = Bar{};
}


On gcc 12.1 -std=c++20 -O2 -mavx2, this emits:

Foo::clear():
mov QWORD PTR [rdi], 0
mov QWORD PTR [rdi+8], 0
mov QWORD PTR [rdi+16], 0
mov QWORD PTR [rdi+24], 0
mov QWORD PTR [rdi+32], 0
mov QWORD PTR [rdi+40], 0
mov QWORD PTR [rdi+48], 0
mov QWORD PTR [rdi+56], 0
mov QWORD PTR [rdi+64], 0
mov QWORD PTR [rdi+72], 0
mov QWORD PTR [rdi+80], 0
mov QWORD PTR [rdi+88], 0
ret
Bar::clear():
mov ecx, 12
xor eax, eax
rep stosq
ret

There are a lot of subtle changes you can make to change the generated code:

* if Fields has 3 members or fewer, it's a bunch of mov's either way
* if Fields has 4 or 5 members, Bar::clear uses vmov insead of mov. 
* if Fields has 6+ members, Bar::clear uses stosq
* if Fields has an array of string_view, Foo::clear and Bar::clear are
identical for sizes 2, 3, and >= 9.

If string_view uses the constructor I have commented out (with the member
initializer list, instead of defaulted and using the default member
initializers, then:
* if Fields holds an array of string_view with at least 4 string_views, both
Foo::clear and Bar::clear emit a loop.
* otherwise, it's always a bunch of mov's for both Foo and Bar, regardless of
how many members. 


Feels like something is up here.

[Bug middle-end/106151] Inconsistent optimization when defaulting aggregate vs non-aggregate

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug c++/106152] New: New ICE compiling template expressions

[byteslice at airmail dot cc via Gcc-bugs]

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

Bug ID: 106152
   Summary: New ICE compiling template expressions
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: byteslice at airmail dot cc
  Target Milestone: ---

Created attachment 53229
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53229&action=edit
Reduced example

Compile with -std=gnu++20. No ICE on 12.

g++ (f35dbc02092fbcd3d814fcd9fe8e871c3f741fd, binutils-2.38) 13.0.0 20220626

--

: In instantiation of 'struct invert_typelist_impl >':
:20:75:   required from 'struct invert_typelist >'
:22:11:   required from here
:15:21: internal compiler error: in iterative_hash_template_arg, at
cp/pt.cc:1819
   15 |   static const long last_idx;
  | ^~~~
0x2212db9 internal_error(char const*, ...)
???:0
0x74a531 fancy_abort(char const*, int, char const*)
???:0
0x9a2397 iterative_hash_template_arg(tree_node*, unsigned int)
???:0
0x9a16bd iterative_hash_template_arg(tree_node*, unsigned int)
???:0
0x9cb387 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0x9f7d56 tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
???:0
0x9caeea tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0x9e6987 tsubst_pack_expansion(tree_node*, tree_node*, int, tree_node*)
???:0
0x9f7fd2 tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
???:0
0x9cb0e9 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0x9cb387 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0xa118b1 instantiate_class_template(tree_node*)
???:0
0xa11b27 instantiate_class_template(tree_node*)
???:0
0xa87f8b complete_type_or_maybe_complain(tree_node*, tree_node*, int)
???:0
0x9b8750 process_template_parm(tree_node*, unsigned int, tree_node*, bool,
bool)
???:0
0x993a5d c_parse_file()
???:0
0xb2a161 c_common_parse_file()
???:0
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++/106151] Inconsistent optimization when defaulting aggregate vs non-aggregate

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|middle-end  |c++

--- Comment #1 from Andrew Pinski  ---
This is really interesting.
-std=c++17 produces {} for both. -std=c++11/-std=c++14 produces the long code
for both while -std=c++20 produces the wrose code for Foo::clear.

[Bug go/105225] build failure with musl libc 1.2.3 due to sysinfo.go error: redefinition of 'SYS_SECCOMP'

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Ian Lance Taylor :

https://gcc.gnu.org/g:762fd5e5547e464e25b4bee435db6df4eda0de90

commit r13-1371-g762fd5e5547e464e25b4bee435db6df4eda0de90
Author: Ian Lance Taylor 
Date:   Wed Jun 29 15:32:04 2022 -0700

libgo: handle stat st_atim32 field and SYS_SECCOMP

Patches for musl support, from Sören Tempel.

Fixes PR go/105225

Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/415294

[Bug tree-optimization/106126] [12 Regression] tree check fail in useless_type_conversion_p, at gimple-expr.cc:87 since r13-1184-g57424087e82db140

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #15 from David Binderman  ---
Created attachment 53230
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53230&action=edit
gzipped C++ source code


Please find attached an additional C++ test case. -O3 required this time:

$ /home/dcb/gcc/results/bin/g++ -c -O3 q1.ii
during GIMPLE pass: iftoswitch
../src/common/uri.cpp: In member function ‘const char*
wxURI::ParseUserInfo(const char*)’:
../src/common/uri.cpp:1086:1: internal compiler error: Segmentation fault
0x10ba099 crash_signal(int)
../../trunk.git/gcc/toplev.cc:322
0x134244a gimple_nop_p(gimple const*)
../../trunk.git/gcc/gimple.h:6747
0x134244a verify_use(basic_block_def*, basic_block_def*, ssa_use_operand_t*,
gimple*, bool, bitmap_head*)
../../trunk.git/gcc/tree-ssa.cc:880

[Bug fortran/105813] ICE in gfc_simplify_unpack, at fortran/simplify.cc:8490

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

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

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

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

commit r12-8529-geb4336f546b2a770717af608c79b4d46f45ef7c2
Author: Harald Anlauf 
Date:   Fri Jun 24 22:21:39 2022 +0200

Fortran: fix checking of arguments to UNPACK when MASK is a variable
[PR105813]

gcc/fortran/ChangeLog:

PR fortran/105813
* check.cc (gfc_check_unpack): Try to simplify MASK argument to
UNPACK so that checking of the VECTOR argument can work when MASK
is a variable.

gcc/testsuite/ChangeLog:

PR fortran/105813
* gfortran.dg/unpack_vector_1.f90: New test.

(cherry picked from commit f21f17f95c0237f4f987a5fa9f1fa9c7e0db3c40)

[Bug go/105225] build failure with musl libc 1.2.3 due to sysinfo.go error: redefinition of 'SYS_SECCOMP'

[ian at airs dot com via Gcc-bugs]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #2 from Ian Lance Taylor  ---
Fixed on mainline.  Thanks for reporting it.

[Bug fortran/105691] Incorrect calculation of INDEX(str1,str2) at compile time

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

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

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

https://gcc.gnu.org/g:26ea506a1e8719f8b1f559e70bee9f5d3392eb37

commit r12-8530-g26ea506a1e8719f8b1f559e70bee9f5d3392eb37
Author: Harald Anlauf 
Date:   Tue Jun 21 23:20:18 2022 +0200

Fortran: fix simplification of INDEX(str1,str2) [PR105691]

gcc/fortran/ChangeLog:

PR fortran/105691
* simplify.cc (gfc_simplify_index): Replace old simplification
code by the equivalent of the runtime library implementation.  Use
HOST_WIDE_INT instead of int for string index, length variables.

gcc/testsuite/ChangeLog:

PR fortran/105691
* gfortran.dg/index_6.f90: New test.

(cherry picked from commit ff35dbc02092fbcd3d814fcd9fe8e871c3f741fd)

[Bug fortran/105954] ICE in gfc_element_size, at fortran/target-memory.cc:132

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

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

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

https://gcc.gnu.org/g:6bcab64467d7393d69bf5abd7b2a0aba22d2896e

commit r12-8531-g6bcab64467d7393d69bf5abd7b2a0aba22d2896e
Author: Harald Anlauf 
Date:   Mon Jun 20 20:59:55 2022 +0200

Fortran: handle explicit-shape specs with constant bounds [PR105954]

gcc/fortran/ChangeLog:

PR fortran/105954
* decl.cc (variable_decl): Adjust upper bounds for explicit-shape
specs with constant bound expressions to ensure non-negative
extents.

gcc/testsuite/ChangeLog:

PR fortran/105954
* gfortran.dg/pr105954.f90: New test.

(cherry picked from commit a312407bd715647f7c11b67e0a52effc94d0f15d)

[Bug analyzer/106006] RFE: analyzer should treat data from a socket as "tainted"

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

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2022-06-30
 Ever confirmed|0   |1

--- Comment #1 from David Malcolm  ---
I'm looking at adding attribute(s) for this.

[Bug c++/106151] Inconsistent optimization when defaulting aggregate vs non-aggregate

[barry.revzin at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Barry Revzin  ---
I guess that's like:

C++11/14: neither is an aggregate (base class).
C++17: both are aggregates.
C++20: Bar is an aggregate, but Foo is not (user-declared constructor).

But that really shouldn't affect the code-gen here? (right???)

[Bug c++/106151] Inconsistent optimization when defaulting aggregate vs non-aggregate

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Barry Revzin from comment #2)
> I guess that's like:
> 
> C++11/14: neither is an aggregate (base class).
> C++17: both are aggregates.
> C++20: Bar is an aggregate, but Foo is not (user-declared constructor).
> 
> But that really shouldn't affect the code-gen here? (right???)

It changes because if the constructor is used or it is zero-initialized . And
it just happens GCC is not able to optimize it back to what the
zero-initialized can be done.

[Bug c/106153] New: Generated arm64 code writing below stack pointer without updating SP

[andy at plausible dot org via Gcc-bugs]

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

Bug ID: 106153
   Summary: Generated arm64 code writing below stack pointer
without updating SP
   Product: gcc
   Version: 10.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andy at plausible dot org
  Target Milestone: ---

The compiler is a arm64 gcc 10.3.0 from the Zephyr project SDK.  It's
a pretty standard crosstools-ng build.  Binaries at zephyrproject.org,
config/source at https://github.com/zephyrproject-rtos/sdk-ng

The short summary is that variable length array usage is generating
incorrect stack pointers; the memory gets used before the SP register
is decremented, leading to a race with the Zephyr interrupt handling
(which uses the interrupted stack during interrupt entry in some
configurations) that then corrupts the interrupted context.

See upstream Zephyr bug here:
https://github.com/zephyrproject-rtos/zephyr/pull/46967

A preprocessed "main.i" is attached that shows the bug fairly easily.
We build it with these arguments:

   aarch64-zephyr-elf-gcc -Os -fno-common -g -gdwarf-4 -mcpu=cortex-a53
-mabi=lp64 -Wall -Wformat -Wformat-security -Wno-format-zero-length -Wno-main
-Wno-pointer-sign -Wpointer-arith -Wexpansion-to-defined
-Wno-unused-but-set-variable -Werror=implicit-int
-fno-asynchronous-unwind-tables -fno-pie -fno-pic -ftls-model=local-exec
-fno-reorder-functions -fno-defer-pop -ffunction-sections -fdata-sections
-std=c99 -S -o - main.i

Doing so, it's easy to see constructions like this (scan down for the
"log_msgs:" function):

mov x19, sp   ;<-- x19 == sp
mov x22, x19  ;<-- x22 == sp
str xzr, [x29, 128]
str wzr, [x29, 136]
str x0, [x19, 24]
mov x0, x20
str x23, [x22, 16]!   ;<-- store through x22 into memory BELOW sp!
strhwzr, [x29, 140]
mov x2, x22
bl  z_log_msg_static_create ;<-- and hand it to a function as an
argument!

We've worked around it with a compiler barrier for now.  As far as I can tell
it's only happening with arm64, plausibly because of the auto indexed "push"
addressing mode generation?

[Bug target/106153] Generated arm64 code writing below stack pointer without updating SP

[andy at plausible dot org via Gcc-bugs]

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

--- Comment #1 from Andy Ross  ---
Just submitted the same code at godbolt and their "ARM64 gcc trunk" build shows
the same behavior.

[Bug target/106153] Generated arm64 code writing below stack pointer without updating SP

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2022-06-30
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
Can you attach the preprocessed source where the assembly was generated from?

[Bug target/106153] Generated arm64 code writing below stack pointer without updating SP

[andy at plausible dot org via Gcc-bugs]

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

--- Comment #3 from Andy Ross  ---
Created attachment 53231
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53231&action=edit
Preprocessed source file (gzipped)

Sorry, I thought I attached it with the submission.  Looks like it got kicked
out for being 50 bytes over the limit.  Compressed and resubmitted.  The
macrobatics is admittedly pretty thick in this API, and the expansions are
messy.  The upstream source (discussed in the linked github issue) might help
clarify.

[Bug target/106153] Generated arm64 code writing below stack pointer without updating SP

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|1   |0
 Status|WAITING |UNCONFIRMED

--- Comment #4 from Andrew Pinski  ---
  saved_stack.50_2 = __builtin_stack_save ();
  _ll_buf.24_379 = __builtin_alloca_with_align (/*size=*/32,
/*align(bits)=*/64);
  _pbuf_381 = &MEM[(struct log_msg *)_ll_buf.24_379].data;
  MEM[(const void * *)_ll_buf.24_379 + 24B] = "Error message example.";
  MEM[(union cbprintf_package_hdr *)&hdr] = 4;
  MEM[(union cbprintf_package_hdr *)_ll_buf.24_379 + 16B] = hdr;
  hdr ={v} {CLOBBER};
  MEM[(struct log_msg_desc *)&_desc] = 8256;
  z_log_msg_static_create (&log_const_syst, _desc, _pbuf_381, 0B);
  __builtin_stack_restore (saved_stack.50_2);




The alloca gets expanded as:
(insn 15 14 16 (set (reg/f:DI 31 sp)
(plus:DI (reg/f:DI 31 sp)
(const_int -32 [0xffe0])))
"/home/andyross/z/zephyr/samples/subsys/logging/syst/src/main.c":47:49 -1
 (nil))

(insn 16 15 17 (set (reg:DI 214)
(reg/f:DI 88 virtual-stack-dynamic))
"/home/andyross/z/zephyr/samples/subsys/logging/syst/src/main.c":47:49 -1
 (nil))

(insn 17 16 18 (set (reg:DI 215)
(plus:DI (reg:DI 214)
(const_int 7 [0x7])))
"/home/andyross/z/zephyr/samples/subsys/logging/syst/src/main.c":47:49 -1
 (nil))

(insn 18 17 19 (set (reg:DI 216)
(lshiftrt:DI (reg:DI 215)
(const_int 3 [0x3])))
"/home/andyross/z/zephyr/samples/subsys/logging/syst/src/main.c":47:49 -1
 (expr_list:REG_EQUAL (udiv:DI (reg:DI 215)
(const_int 8 [0x8]))
(nil)))

(insn 19 18 20 (set (reg/f:DI 217)
(ashift:DI (reg:DI 216)
(const_int 3 [0x3])))
"/home/andyross/z/zephyr/samples/subsys/logging/syst/src/main.c":47:49 -1
 (nil))

(insn 20 19 0 (set (reg/f:DI 117 [ _ll_buf.24 ])
(reg/f:DI 217))
"/home/andyross/z/zephyr/samples/subsys/logging/syst/src/main.c":47:49 -1
 (nil))


Which looks correct (64 bit aligned is 8 byte aligned).

[Bug target/106153] Generated arm64 code writing below stack pointer without updating SP

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

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

--- Comment #5 from Andrew Pinski  ---
I don't see any below accesses either.

Right before the assembler code you posted has:
sub sp, sp, #32 

So 
Maybe I am missing something.

[Bug c/45358] Diagnostic could be issued for old C style a =+ b and similar cases

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

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

Eric Gallager  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #7 from Eric Gallager  ---
*** Bug 106148 has been marked as a duplicate of this bug. ***

[Bug c/106148] RFE: warn about =- typos

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

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #2 from Eric Gallager  ---
(In reply to Marek Polacek from comment #1)
> I think this was also requested in bug 45358.

Yeah that was my first thought, too; closing this as a dup of that

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

[Bug c/106154] New: Error when missing a : inside an inline-asm could be improved

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

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

Bug ID: 106154
   Summary: Error when missing a : inside an inline-asm could be
improved
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: diagnostic, inline-asm
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take:
```
void f(void)
{
__asm__(""::"memory");
}
```
I forgot there should be 3 : and the error message for this should be improved.
Currently it is:
```
: In function 'f':
:3:25: error: expected '(' before ')' token
3 | __asm__(""::"memory");
  | ^
  | (
```
I was like what does that even mean and then I remembered there is output,
input and clobber for the asm statement.

Note both the C and C++ front-ends have the same issue and produce the same
error message.

Well C++ produces some extra ones error messages:
```
:3:25: error: expected primary-expression before ')' token
:3:26: error: expected ')' before ';' token
3 | __asm__(""::"memory");
  |  ^
  |  )
```

clang is not only slightly better:
```
:3:25: error: expected '(' after 'asm operand'
__asm__(""::"memory");
^
```

[Bug tree-optimization/106151] Inconsistent optimization when defaulting aggregate vs non-aggregate

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

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

--- Comment #4 from Jonathan Wakely  ---
Ideally the middle end should optimize it. But until then, I wonder if the
front end could detect when a non-trivial ctor is just doing zero-init of every
member, and fold it early.

[Bug c/106154] Error when missing a : inside an inline-asm could be improved

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug c++/106150] Incorrect error for defaulted anonymous union member

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

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

--- Comment #1 from Andrew Pinski  ---
clang also rejects it:
:21:4: error: defaulting this default constructor would delete it after
its first declaration
S::S() = default;
   ^
:17:8: note: default constructor of 'S' is implicitly deleted because
variant field 'v' has a non-trivial default constructor
 V v;
   ^

[Bug c++/106150] Incorrect error for defaulted anonymous union member

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

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

--- Comment #2 from Andrew Pinski  ---
MSVC and ICC accept it though.

[Bug tree-optimization/106155] New: [12/13 Regression] spurious "may be used uninitialized" warning

[vincent-gcc at vinc17 dot net via Gcc-bugs]

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

Bug ID: 106155
   Summary: [12/13 Regression] spurious "may be used
uninitialized" warning
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vincent-gcc at vinc17 dot net
  Target Milestone: ---

With "-O -Wmaybe-uninitialized", I get a spurious "may be used uninitialized"
on the following code on an x86_64 Debian/unstable machine:

int *e;
int f1 (void);
void f2 (int);
long f3 (void *, long, int *);
void f4 (void *);
int *fh;

void tst (void)
{
  int status;
  unsigned char badData[3][3] = { { 7 }, { 16 }, { 23 } };
  int badDataSize[3] = { 1, 1, 1 };
  int i;

  for (i = 0; i < 3; i++)
{
  int emax;
  if (i == 2)
emax = f1 ();
  status = f3 (&badData[i][0], badDataSize[i], fh);
  if (status)
{
  f1 ();
  f1 ();
  f1 ();
}
  f4 (fh);
  *e = 0;
  f1 ();
  if (i == 2)
f2 (emax);
}
}

Note that even a small change such as changing "long" to "int" as the second
parameter of f3 makes the warning disappear.

$ gcc-12 -O -Wmaybe-uninitialized -c -o tfpif.o tfpif.c
tfpif.c: In function ‘tst’:
tfpif.c:31:9: warning: ‘emax’ may be used uninitialized [-Wmaybe-uninitialized]
   31 | f2 (emax);
  | ^
tfpif.c:17:11: note: ‘emax’ was declared here
   17 |   int emax;
  |   ^~~~
$ gcc-12 --version
gcc-12 (Debian 12.1.0-5) 12.1.0
[...]

$ gcc-snapshot -O -Wmaybe-uninitialized -c -o tfpif.o tfpif.c
tfpif.c: In function 'tst':
tfpif.c:31:9: warning: 'emax' may be used uninitialized [-Wmaybe-uninitialized]
   31 | f2 (emax);
  | ^
tfpif.c:17:11: note: 'emax' was declared here
   17 |   int emax;
  |   ^~~~
$ gcc-snapshot --version
gcc (Debian 20220630-1) 13.0.0 20220630 (experimental) [master
r13-1359-gaa1ae74711b]
[...]

No such issue with:
  gcc-9 (Debian 9.5.0-1) 9.5.0
  gcc-10 (Debian 10.4.0-1) 10.4.0
  gcc-11 (Debian 11.3.0-4) 11.3.0

I detected this issue by testing GNU MPFR. The above code is derived from
"tests/tfpif.c", function check_bad.

[Bug target/106069] [12/13 Regression] wrong code with -O -fno-tree-forwprop -maltivec on ppc64le

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

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

--- Comment #8 from luoxhu at gcc dot gnu.org ---
init-regs:

(insn 13 8 17 2 (set (reg:V4SI 141)
(vec_select:V4SI (vec_concat:V8SI (reg/v:V4SI 135 [ R2 ])
(reg/v:V4SI 133 [ R0 ]))
(parallel [
(const_int 2 [0x2])
(const_int 6 [0x6])
(const_int 3 [0x3])
(const_int 7 [0x7])
]))) "q.C":22:45 1785 {altivec_vmrglw_direct_v4si}
 (expr_list:REG_DEAD (reg/v:V4SI 135 [ R2 ])
(expr_list:REG_DEAD (reg/v:V4SI 133 [ R0 ])
(nil
(insn 17 13 21 2 (set (reg:V4SI 146)
(vec_select:V4SI (vec_concat:V8SI (reg/v:V4SI 136 [ R3 ])
(reg/v:V4SI 134 [ R1 ]))
(parallel [
(const_int 2 [0x2])
(const_int 6 [0x6])
(const_int 3 [0x3])
(const_int 7 [0x7])
]))) "q.C":23:45 1785 {altivec_vmrglw_direct_v4si}
 (expr_list:REG_DEAD (reg/v:V4SI 136 [ R3 ])
(expr_list:REG_DEAD (reg/v:V4SI 134 [ R1 ])
(nil
(insn 21 17 24 2 (set (reg:V4SI 150)
(vec_select:V4SI (vec_concat:V8SI (reg:V4SI 146)
(reg:V4SI 141))
(parallel [
(const_int 2 [0x2])
(const_int 6 [0x6])
(const_int 3 [0x3])
(const_int 7 [0x7])
]))) "q.C":26:6 1785 {altivec_vmrglw_direct_v4si}
 (expr_list:REG_DEAD (reg:V4SI 146)
(expr_list:REG_DEAD (reg:V4SI 141)
(nil
(insn 24 21 25 2 (parallel [
(set (reg:SI 151)
(vec_select:SI (reg:V4SI 150)
(parallel [
(const_int 3 [0x3])
])))
(clobber (scratch:V4SI))
]) "q.C":28:10 1400 {*vsx_extract_si}
 (nil))
(insn 25 24 26 2 (set (reg:DI 152)
(zero_extend:DI (reg:SI 151))) "q.C":28:10 16 {zero_extendsidi2}
 (expr_list:REG_DEAD (reg:SI 151)
(nil)))
(insn 26 25 27 2 (parallel [
(set (reg:SI 153)
(vec_select:SI (reg:V4SI 150)
(parallel [
(const_int 2 [0x2])
])))
(clobber (scratch:V4SI))
]) "q.C":28:10 1400 {*vsx_extract_si}
 (nil))
(insn 27 26 28 2 (set (reg:DI 154)
(zero_extend:DI (reg:SI 153))) "q.C":28:10 16 {zero_extendsidi2}
 (expr_list:REG_DEAD (reg:SI 153)
(nil)))
(insn 28 27 29 2 (parallel [
(set (reg:SI 155)
(vec_select:SI (reg:V4SI 150)
(parallel [
(const_int 1 [0x1])
])))
(clobber (scratch:V4SI))
]) "q.C":28:10 1400 {*vsx_extract_si}
 (nil))
(insn 29 28 30 2 (set (reg:DI 156)
(zero_extend:DI (reg:SI 155))) "q.C":28:10 16 {zero_extendsidi2}
 (expr_list:REG_DEAD (reg:SI 155)
(nil)))
(insn 30 29 31 2 (parallel [
(set (reg:SI 157)
(vec_select:SI (reg:V4SI 150)
(parallel [
(const_int 0 [0])
])))
(clobber (scratch:V4SI))
]) "q.C":28:10 1400 {*vsx_extract_si}
 (expr_list:REG_DEAD (reg:V4SI 150)
(nil)))


combine:

Trying 13 -> 28:
   13: r141:V4SI=vec_select(vec_concat(r164:V4SI,r162:V4SI),parallel)
  REG_DEAD r164:V4SI
   28: {r155:SI=vec_select(r141:V4SI,parallel);clobber scratch;}
  REG_DEAD r141:V4SI
Successfully matched this instruction:
(parallel [
(set (reg:SI 155)
(vec_select:SI (reg:V4SI 164)
(parallel [
(const_int 3 [0x3])
])))
(clobber (scratch:V4SI))
])
allowing combination of insns 13 and 28
original costs 4 + 8 = 12
replacement cost 8
deferring deletion of insn with uid = 13.
modifying insn i328: {r155:SI=vec_select(r164:V4SI,parallel);clobber
scratch;}
  REG_DEAD r164:V4SI
deferring rescan insn with uid = 28.



(note 7 47 8 2 NOTE_INSN_DELETED)
(note 8 7 13 2 NOTE_INSN_FUNCTION_BEG)
(note 13 8 17 2 NOTE_INSN_DELETED)
(note 17 13 21 2 NOTE_INSN_DELETED)
(note 21 17 24 2 NOTE_INSN_DELETED)
(insn 24 21 25 2 (parallel [
(set (reg:SI 151)
(vec_select:SI (reg:V4SI 162)
(parallel [
(const_int 3 [0x3])
])))
(clobber (scratch:V4SI))
]) "q.C":28:10 1400 {*vsx_extract_si}
 (expr_list:REG_DEAD (reg:V4SI 162)
(nil)))
(note 25 24 26 2 NOTE_INSN_DELETED)
(insn 26 25 27 2 (parallel [
(set (reg:SI 153)
(vec_select:SI (reg:V4SI 163)
(parallel [
(const_int 3 [0x3])
])))
(clobber (scratch:V4SI))
]) "q.C":28:10 1400 {*vsx_extract_

[Bug c++/106150] Incorrect error for defaulted anonymous union member

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
>The following is valid,

No the code is invalid but because of the non-trival deconstructor of V.
Here is an example which is valid (after
https://cplusplus.github.io/CWG/issues/2084.html):
struct S1 {
S1();
};
struct S {
S();
};
union U {
S s{};
S1 s1;
} u;

The check in GCC for this seems to be off, if only the variant s is there, GCC
(and clang) accepts it.

So the full check for the defect report was never really done (and it was not
even mentioned in the defect report commentary either).

[Bug c++/106150] [DR 2084] union with more than one variant and non-trivial constructor is not accepted

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|Incorrect error for |[DR 2084] union with more
   |defaulted anonymous union   |than one variant and
   |member  |non-trivial constructor is
   ||not accepted
   Keywords||rejects-valid

--- Comment #4 from Andrew Pinski  ---
Let me also file the other bug about the deconstructor for anonymous unions
since that is a different issue.

[Bug c++/106150] [DR 2084] union with more than one variant and non-trivial constructor is not accepted

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #4)
> Let me also file the other bug about the deconstructor for anonymous unions
> since that is a different issue.

Actually I take that back, the anonymous union case for the deconstructor is
not invalid in the end; I just misunderstood.
Anyways the reduced testcase shows the problem even without the deconstructor.

[Bug tree-optimization/106155] [12/13 Regression] spurious "may be used uninitialized" warning

[vincent-gcc at vinc17 dot net via Gcc-bugs]

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

--- Comment #1 from Vincent Lefèvre  ---
I detected the issue on tests/tfpif.c with the upgrade of Debian's package
gcc-snapshot from 1:20220126-1 to 1:20220630-1 (it doesn't occur on
tests/tfpif.c with gcc-snapshot 1:20220126-1). However, the simplified testcase
I've provided fails with gcc-snapshot 1:20220126-1.

[Bug tree-optimization/105740] missed optimization switch transformation for conditions with duplicate conditions

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

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

--- Comment #10 from luoxhu at gcc dot gnu.org ---
(In reply to Martin Liška from comment #9)
> (In reply to luoxhu from comment #8)
> > (In reply to rguent...@suse.de from comment #6)
> > > On Tue, 21 Jun 2022, jakub at gcc dot gnu.org wrote:
> > > 
> > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105740
> > > > 
> > > > --- Comment #5 from Jakub Jelinek  ---
> > > > The problem with switch-conversion done multiple times is that when it 
> > > > is done
> > > > early, it can do worse job than when it is done late, e.g. we can have 
> > > > better
> > > > range information later which allows (unfortunately switch-conversion 
> > > > doesn't
> > > > use that yet, there is a PR about it) to ignore some never reachable 
> > > > values
> > > > etc.
> > > > So ideally we either need to be able to undo switch-conversion and redo 
> > > > it if
> > > > things have changed, or do it only late and for e.g. inlining costs 
> > > > perform it
> > > > only in analysis mode and record somewhere what kind of lowering would 
> > > > be done
> > > > and how much it would cost.
> > > > With multiple if-to-switch, don't we risk that we turn some ifs into 
> > > > switch,
> > > > then
> > > > switch-conversion lowers it back to ifs and then another if-to-switch 
> > > > matches
> > > > it again and again lowers it?
> > > 
> > > Yeah, I think ideally switch conversion would be done as part of switch
> > > lowering (plus maybe an extra if-to-switch).  The issue might be what
> > > I said - some passes don't like switches, but they probably need to be
> > > taught.  As of inline cost yes, doing likely-switch-converted analysis
> > > would probably work.
> > 
> > git diff
> > diff --git a/gcc/passes.def b/gcc/passes.def
> > index b257307e085..1376e7cb28d 100644
> > --- a/gcc/passes.def
> > +++ b/gcc/passes.def
> > @@ -243,8 +243,6 @@ along with GCC; see the file COPYING3.  If not see
> >  Clean them up.  Failure to do so well can lead to false
> >  positives from warnings for erroneous code.  */
> >NEXT_PASS (pass_copy_prop);
> >/* Identify paths that should never be executed in a conforming
> >  program and isolate those paths.  */
> >NEXT_PASS (pass_isolate_erroneous_paths);
> > @@ -329,6 +327,7 @@ along with GCC; see the file COPYING3.  If not see
> >POP_INSERT_PASSES ()
> >NEXT_PASS (pass_simduid_cleanup);
> >NEXT_PASS (pass_lower_vector_ssa);
> > +  NEXT_PASS (pass_if_to_switch);
> >NEXT_PASS (pass_lower_switch);
> >NEXT_PASS (pass_cse_reciprocals);
> >NEXT_PASS (pass_reassoc, false /* early_p */);
> > 
> > Tried this to add the second if_to_switch before lower_switch, but switch
> > lowering doesn't work same as switch_conversion:
> 
> Note the lowering expand to a decision tree where node of such tree can be
> jump-tables,
> bit-tests or simple comparisons.
> 
> > 
> > ;; Function test2 (test2, funcdef_no=0, decl_uid=1982, cgraph_uid=1,
> > symbol_order=0)
> > 
> > beginning to process the following SWITCH statement ((null):0) : ---
> > switch (_2)  [INV], case 1:  [INV], case 2:  [INV],
> > case 3:  [INV], case 4:  > 3> [INV], case 5:  [INV], case 6:  [INV]>
> > 
> > ;; GIMPLE switch case clusters: JT(values:6 comparisons:6 range:6 density:
> > 100.00%):1-6
> 
> So jump-table is selected. Where do you see this GIMPLE representation?

This is dumped by the second run of iftoswitch after fre5.

> 
> ...
> 
> > 
> > ASM still contains indirect jump table like -fno-switch-conversion:
> 
> > 
> > Is this bug of lower_switch or expected?
> 
> What bug do you mean? 

Sorry, it not a bug, got to know that switch lower and switch conversion are
doing two different things, different with "pass_lower_switch
also performs the transforms switch-conversion does" in c#4?

> 
> > From the code, they have different
> > purpose as switch_conversion turns switch to single if-else while
> 
> No switch_conversion expands a switch statement to a series of assignment
> based on CSWITCH[index] arrays.
> 
> > lower_switch expand CLUSTERS as a decision tree.

Yes, rerun pass_convert_switch after the second if_to_switch could generate the
CSWITCH[index]. 

pr105740.c.195t.switchconv2:

   [local count: 1073741824]:
  if (x_4(D) > 3)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 536870913]:
  _1 = f_6(D)->arr[3];
  _10 = (unsigned int) _1;
  _2 = _10 + 4294967295;
  if (_2 <= 5)
goto ; [INV]
  else
goto ; [INV]

   [local count: 1073741822]:
:
  _8 = 0;
  goto ; [100.00%]

   [local count: 1073741822]:
:
  _9 = CSWTCH.4[_2];

   [local count: 2147483644]:
  # _3 = PHI <_8(4), 0(2), _9(5)>
:
:
  return _3;

[Bug tree-optimization/106155] [12/13 Regression] spurious "may be used uninitialized" warning

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2022-07-01
   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Target Milestone|--- |12.2
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---

init_from_control_deps {{0 -> 3}}:
i_44 != 2 (expanded)
NOT (i_44 == 2)
After normalization [DEF]:
i_44 != 2 (expanded)
NOT (i_44 == 2)
After normalization [USE]:
f2 (emax_8);
  is conditional on:
ivtmp.7_37 == 2 (expanded)
ivtmp.7_37 == 2

Which is funny we get:

  # ivtmp.7_37 = PHI 
  i_44 = (int) ivtmp.7_37;
  if (i_44 == 2)
goto ; [12.49%]
  else
goto ; [87.51%]

  if (ivtmp.7_37 == 2)
goto ; [12.49%]
  else
goto ; [87.51%]

   [local count: 268435456]:
  f2 (emax_8);

I don't know why ivopts only changed the second if and not the first.

Oh because the second is the exit check:
Replacing exit test: if (ivtmp_39 != 0)
Replacing exit test: if (i_40 == 2)

If we change the size to 4 and keep the 2 as 2, there would be no warning.
And if then change 2 to 3, the warning is back.

So there is a missed optimization of changing the internal comparison for the
IV to the new type if the right side is a constant.

[Bug tree-optimization/106155] [12/13 Regression] spurious "may be used uninitialized" warning

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection

--- Comment #3 from Andrew Pinski  ---
I can't figure out why 11.x didn't warn but 12+ does though. The IR looks the
same to me.

[Bug testsuite/106149] [13 regression] g++.dg/warn/Warray-bounds-16.C had bogus errors after r13-1366-g1eef21ccfa5988

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|libstdc++   |testsuite

--- Comment #1 from Andrew Pinski  ---
Actually I think it is g:0f6eef398045deb2a62d18b526831719c7c20c8a  .

[Bug tree-optimization/106138] Inefficient code generation: logical AND of disjoint booleans from equal and bitwise AND not optimized to constant false

[peter at cordes dot ca via Gcc-bugs]

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

Peter Cordes  changed:

   What|Removed |Added

 CC||peter at cordes dot ca

--- Comment #3 from Peter Cordes  ---
Ideally, bitwise & of booleans should also be handled, not just &&.
A testcase (https://godbolt.org/z/qvosv8q7c) makes it easy to check both.

//#define LOGIC_AND 
_Bool f2(char x)
{
_Bool b1 = x == 2;
_Bool b2 = x & 1;

#ifdef LOGIC_AND
  return b1 && b2;
#else
  return b1 & b2;
#endif
}

(Clang optimized it to return false for the && version, but not bitwise.  GCC
currently doesn't optimize either way.)
This was originally posted on Stack Overflow
(https://stackoverflow.com/q/72802469/224132), BTW.

[Bug bootstrap/106156] New: [13 Regression] libtool fails to link liblto_plugin.la on riscv64-linux-gnu

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

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

Bug ID: 106156
   Summary: [13 Regression] libtool fails to link liblto_plugin.la
on riscv64-linux-gnu
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

seen with trunk 20220630 on riscv64-linux-gnu, using binutils trunk/2.39. Not
seen in the same environment building GCC 11 and 12:

/bin/bash ./libtool --tag=CC --tag=disable-static  --mode=link
/<>/build/./prev-gcc
/xgcc -B/<>/build/./prev-gcc/
-B/usr/lib/gcc-snapshot/riscv64-linux-gnu/bin/ -B/usr
/lib/gcc-snapshot/riscv64-linux-gnu/bin/
-B/usr/lib/gcc-snapshot/riscv64-linux-gnu/lib/ -isystem
 /usr/lib/gcc-snapshot/riscv64-linux-gnu/include -isystem
/usr/lib/gcc-snapshot/riscv64-linux-gn
u/sys-include   -fno-checking -Wall  -g -O2 -fno-checking -gtoggle   -module
-avoid-version -bin
dir /usr/lib/gcc-snapshot/libexec/gcc/riscv64-linux-gnu/13
-export-symbols-regex onload-Xcom
piler '-static-libstdc++' -Xcompiler '-static-libgcc' '-Wl,-z,relro' -o
liblto_plugin.la -rpath 
/usr/lib/gcc-snapshot/libexec/gcc/riscv64-linux-gnu/13 lto-plugin.lo 
-Wc,../libiberty/pic/libib
erty.a 
libtool: link: riscv64-linux-gnu-nm  .libs/lto-plugin.o   |  | /bin/sed 's/.*
//' | sort | uniq 
> .libs/liblto_plugin.exp
./libtool: eval: line 1118: syntax error near unexpected token `|'
./libtool: eval: line 1118: `riscv64-linux-gnu-nm  .libs/lto-plugin.o   |  |
/bin/sed 's/.* //' 
| sort | uniq > .libs/liblto_plugin.exp'
make[6]: *** [Makefile:471: liblto_plugin.la] Error 2
make[6]: Leaving directory '/<>/build/lto-plugin'
make[5]: *** [Makefile:382: all] Error 2
make[5]: Leaving directory '/<>/build/lto-plugin'
make[4]: *** [Makefile:15935: all-stage2-lto-plugin] Error 2

GCC is configured with

Configured with: -v
 --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++
 --prefix=/usr/lib/gcc-snapshot
 --with-gcc-major-version-only
 --program-prefix=
 --enable-shared
 --enable-linker-build-id
 --disable-nls
 --enable-clocale=gnu
 --enable-libstdcxx-debug
 --enable-libstdcxx-time=yes
 --with-default-libstdcxx-abi=new
 --enable-gnu-unique-object
 --disable-libitm
 --disable-libquadmath
 --disable-libquadmath-support
 --enable-plugin
 --with-system-zlib
 --enable-libphobos-checking=release
 --with-target-system-zlib=auto
 --enable-objc-gc=auto
 --enable-multiarch
 --disable-werror
 --disable-multilib
 --with-arch=rv64gc
 --with-abi=lp64d
 --enable-checking=yes
 --build=riscv64-linux-gnu
 --host=riscv64-linux-gnu
 --target=riscv64-linux-gnu

[Bug target/106153] Generated arm64 code writing below stack pointer without updating SP

[andy at plausible dot org via Gcc-bugs]

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

--- Comment #6 from Andy Ross  ---
No, I just had a thinko (hur dur stack grows down, sigh) and jumped too quickly
once I thought I had it.  All the circumstantial evidence is pointing at a
compiler bug here, but this smoking gun isn't.  I'll keep looking.  Feel free
to close this if you need to, I can always reopen if I find something.

[Bug c++/106150] [DR 2084] union with more than one variant and non-trivial constructor is not accepted

[jens.maurer at gmx dot net via Gcc-bugs]

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

--- Comment #6 from Jens Maurer  ---
Related clang bug: https://github.com/llvm/llvm-project/issues/56313

[Bug tree-optimization/106126] [12 Regression] tree check fail in useless_type_conversion_p, at gimple-expr.cc:87 since r13-1184-g57424087e82db140

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

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

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

https://gcc.gnu.org/g:618bac5b486832edd3f8eb3ada74740e389dfcb8

commit r13-1375-g618bac5b486832edd3f8eb3ada74740e389dfcb8
Author: Martin Liska 
Date:   Thu Jun 30 15:00:17 2022 +0200

if-to-switch: properly allow side effects only for first condition

Properly allow side effects only for a first BB in a condition chain.

PR tree-optimization/106126

gcc/ChangeLog:

* gimple-if-to-switch.cc (struct condition_info): Save
has_side_effect.
(find_conditions): Parse all BBs.
(pass_if_to_switch::execute): Allow only side effects for first
BB.

gcc/testsuite/ChangeLog:

* gcc.dg/tree-ssa/pr106126.c: New test.

[Bug tree-optimization/106126] [13 Regression] tree check fail in useless_type_conversion_p, at gimple-expr.cc:87 since r13-1184-g57424087e82db140

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

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

Martin Liška  changed:

   What|Removed |Added

Summary|[12 Regression] tree check  |[13 Regression] tree check
   |fail in |fail in
   |useless_type_conversion_p,  |useless_type_conversion_p,
   |at gimple-expr.cc:87 since  |at gimple-expr.cc:87 since
   |r13-1184-g57424087e82db140  |r13-1184-g57424087e82db140
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #17 from Martin Liška  ---
Fixed now.

[Bug tree-optimization/106126] [13 Regression] tree check fail in useless_type_conversion_p, at gimple-expr.cc:87 since r13-1184-g57424087e82db140

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

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

--- Comment #18 from Martin Liška  ---
(In reply to David Binderman from comment #15)
> Created attachment 53230 [details]
> gzipped C++ source code
> 
> 
> Please find attached an additional C++ test case. -O3 required this time:
> 
> $ /home/dcb/gcc/results/bin/g++ -c -O3 q1.ii
> during GIMPLE pass: iftoswitch
> ../src/common/uri.cpp: In member function ‘const char*
> wxURI::ParseUserInfo(const char*)’:
> ../src/common/uri.cpp:1086:1: internal compiler error: Segmentation fault
> 0x10ba099 crash_signal(int)
>   ../../trunk.git/gcc/toplev.cc:322
> 0x134244a gimple_nop_p(gimple const*)
>   ../../trunk.git/gcc/gimple.h:6747
> 0x134244a verify_use(basic_block_def*, basic_block_def*, ssa_use_operand_t*,
> gimple*, bool, bitmap_head*)
>   ../../trunk.git/gcc/tree-ssa.cc:880

I've just verified the following test-case is resolved fine with the current
master.

[Bug tree-optimization/106131] [10/11/12 Regression] -fstrict-aliasing breaks normal program that does not use any pointer or reference

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||13.0
Summary|[10/11/12/13 Regression]|[10/11/12 Regression]
   |-fstrict-aliasing breaks|-fstrict-aliasing breaks
   |normal program that does|normal program that does
   |not use any pointer or  |not use any pointer or
   |reference   |reference

--- Comment #11 from Richard Biener  ---
Fixed on trunk sofar.

[Bug tree-optimization/106131] [10/11/12/13 Regression] -fstrict-aliasing breaks normal program that does not use any pointer or reference

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

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

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

https://gcc.gnu.org/g:9701432ff79926a5dd3303be3417e0bd0c24140b

commit r13-1376-g9701432ff79926a5dd3303be3417e0bd0c24140b
Author: Richard Biener 
Date:   Thu Jun 30 10:33:40 2022 +0200

tree-optimization/106131 - wrong code with FRE rewriting

The following makes sure to not use the original TBAA type for
looking up a value across an aggregate copy when we had to offset
the read.

2022-06-30  Richard Biener  

PR tree-optimization/106131
* tree-ssa-sccvn.cc (vn_reference_lookup_3): Force alias-set
zero when offsetting the read looking through an aggregate
copy.

* g++.dg/torture/pr106131.C: New testcase.

[Bug bootstrap/106145] [12/13 Regression] /usr/bin/ld: libcommon.a(input.o): copy relocation against non-copyable protected symbol `__cxa_pure_virtual' on aarch64-linux-gnu

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||build
   Target Milestone|--- |12.2