[Bug tree-optimization/103799] switch expansion could be smarter

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=95821
   Severity|normal  |enhancement

--- Comment #1 from Andrew Pinski  ---
I found this while looking into PR 95821.

[Bug tree-optimization/103799] New: switch expansion could be smarter

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

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

Bug ID: 103799
   Summary: switch expansion could be smarter
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take:
auto f(char c)
{
  int t1;
  switch (c)
{
   case '1':
 t1 = 1;
 break;
   case '2':
 t1 = 2;
 break;
   case '3':
 t1 = 3;
 break;
   case '\0':
 t1 = 4;
 break;
   default:
 t1 = -1;
}
   return t1;
}


auto f1(char c)
{
  int t1;
  switch (c)
{
   case '1':
 t1 = 1;
 break;
   case '2':
 t1 = 2;
 break;
   case '3':
 t1 = 3;
 break;
default:
  if (c == '\0') t1 = 4; else t1 = -1;
}
   return t1;
}

f1 produces better code than f.

[Bug tree-optimization/95821] Failure to optimize strchr to use memchr for string constant

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #2)
> Confirmed.
> auto f(char c)
> {
>   auto t = "123";
>   int t1;
>   switch (c)
> {
>case '1':
>  t1 = 1;
>case '2':
>  t1 = 2;
>case '3':
>  t1 = 3;
>default:
>  t = 0;
>  return t;
> }
>return t+t1;
> }

I missed '\0' (and break's):

auto f(char c)
{
  auto t = "123";
  int t1;
  switch (c)
{
   case '1':
 t1 = 1;
 break;
   case '2':
 t1 = 2;
 break;
   case '3':
 t1 = 3;
 break;
   case '\0':
 t1 = 4;
 break;
   default:
 t = 0;
 return t;
}
   return t+t1;
}

[Bug tree-optimization/95821] Failure to optimize strchr to use memchr for string constant

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Severity|normal  |enhancement
 Ever confirmed|0   |1
   Last reconfirmed||2021-12-22

--- Comment #2 from Andrew Pinski  ---
Confirmed.
Though for small strings it might even make sense to inline it, eg.:
auto f(char c)
{
return strchr("123", c);
}
to
auto f(char c)
{
  auto t = "123";
  int t1;
  switch (c)
{
   case '1':
 t1 = 1;
   case '2':
 t1 = 2;
   case '3':
 t1 = 3;
   default:
 t = 0;
 return t;
}
   return t+t1;
}

[Bug tree-optimization/103798] memchr with a (small) constant string should be expanded inline.

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|libstdc++   |tree-optimization
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Severity|normal  |enhancement
Summary|Missed optimization:|memchr with a (small)
   |char_traits::find |constant string should be
   |(and thus   |expanded inline.
   |string_view::find_first_of) |
   |is slow when invoked with   |
   |short strings   |
   Last reconfirmed||2021-12-22

--- Comment #1 from Andrew Pinski  ---
Really the issue is:
  _8 = __builtin_memchr ("eE", _7, 2);
  if (_8 != 0B)


Should just be expanded to _7 == 'e' || _7 == 'E' .

That is:
int f(char a)
{
   return  __builtin_memchr ("e", a, 1) != 0;
}
int f1(char a)
{
   return a == 'e';
}
int g(char a)
{
   return  __builtin_memchr ("eE", a, 2) != 0;
}
int g1(char a)
{
   return a == 'e' || a == 'E';
}

f and f1 should produce the same assembly
and g and g1 should produce the same (similar) assembly.

[Bug c++/103490] Linkage type of typeinfo of polymorphic object with OOL functions

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to John McCall from comment #3)
> I'm not sure I agree that that's the letter of the law, but even taken that
> as given, I think I would argue that it's a defect rather than something
> that has to be followed.  The purpose of the key-function optimization is to
> avoid the overheads of having to redundantly emit and unique v-tables.  A
> lot of uniquing can happen at link time, of course, but not all, and
> optimizing load times is important.

https://itanium-cxx-abi.github.io/cxx-abi/cxx-closed.html#B5

There was an open issue a long time ago which resolved this. If you think there
should be a new defect opened against the ABI be my guest but the resolution of
the original issue was resolved to say comdat in all cases.

"Resolution: Vtables will be emitted with the key function (first virtual
function that is not inline at the point of class definition), if any. If no
key function, emit everywhere used (i.e. referred to by name). Place in a
comdat group in all cases."

Given clang is the only compiler out there that is not complaint I think clang
should change.

[Bug libstdc++/103798] New: Missed optimization: char_traits::find (and thus string_view::find_first_of) is slow when invoked with short strings

[zhaoweiliew at gmail dot com via Gcc-bugs]

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

Bug ID: 103798
   Summary: Missed optimization: char_traits::find (and thus
string_view::find_first_of) is slow when invoked with
short strings
   Product: gcc
   Version: 11.2.1
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhaoweiliew at gmail dot com
  Target Milestone: ---

Given the following code:

#include 

size_t findFirstE_slow(std::string_view sv) {
  return sv.find_first_of("eE");
}

size_t findFirstE_fast(std::string_view sv) {
  auto it{sv.begin()};
  for (; it != sv.end() && *it != 'e' && *it != 'E'; ++it)
;
  return it == sv.end() ? std::string_view::npos : size_t(it - sv.begin());
}


x86-64 gcc (trunk) -std=c++20 -O3 generates the following assembly:

.LC0:
.string "eE"
findFirstE_slow(std::basic_string_view >):
pushr12
pushrbp
pushrbx
testrdi, rdi
je  .L4
mov rbx, rdi
mov rbp, rsi
xor r12d, r12d
jmp .L3
.L8:
add r12, 1
cmp rbx, r12
je  .L4
.L3:
movsx   esi, BYTE PTR [rbp+0+r12]
mov edx, 2
mov edi, OFFSET FLAT:.LC0
callmemchr
testrax, rax
je  .L8
mov rax, r12
pop rbx
pop rbp
pop r12
ret
.L4:
mov r12, -1
pop rbx
pop rbp
mov rax, r12
pop r12
ret

findFirstE_fast(std::basic_string_view >):
add rdi, rsi
cmp rdi, rsi
je  .L13
mov rax, rsi
jmp .L12
.L15:
add rax, 1
cmp rdi, rax
je  .L13
.L12:
movzx   edx, BYTE PTR [rax]
and edx, -33
cmp dl, 69
jne .L15
sub rax, rsi
ret
.L13:
mov rax, -1
ret


Even though both findFirstE_slow() and findFirstE_fast() are logically
equivalent, findFirstE_slow() calls memchr() for every character in the input
string.

findFirstE_fast() does what we would reasonably expect, comparing every
character in the input string with 'e' and 'E'.

In practice, when the set of characters to be found is small, findFirstE_slow()
runs noticeably slower than findFirstE_fast(). This seems to be a missed
optimization in char_traits::find(), which affects several find-related
methods in string_view.

Relevant StackOverflow question with quick-bench output, Compiler Explorer
output, and more discussion:
https://stackoverflow.com/questions/70433152/missed-optimization-with-string-viewfind-first-of

[Bug c++/103490] Linkage type of typeinfo of polymorphic object with OOL functions

[rjmccall at gmail dot com via Gcc-bugs]

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

John McCall  changed:

   What|Removed |Added

 CC||rjmccall at gmail dot com

--- Comment #3 from John McCall  ---
I'm not sure I agree that that's the letter of the law, but even taken that as
given, I think I would argue that it's a defect rather than something that has
to be followed.  The purpose of the key-function optimization is to avoid the
overheads of having to redundantly emit and unique v-tables.  A lot of uniquing
can happen at link time, of course, but not all, and optimizing load times is
important.

Does GCC ever emit actually v-tables redundantly which would otherwise be
unique under the key-function optimization?  If not, it's a fixable defect. 
The sample code here does not count as an observation of the difference, as
it's not at all a well-formed program under C++ rules.

[Bug debug/103788] [9/10/11/12 Regression] '-fcompare-debug' failure (length) w/ -O1

[asolokha at gmx dot com via Gcc-bugs]

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

--- Comment #5 from Arseny Solokha  ---
Can it be related to PR94276?

[Bug c++/86126] Note when linking libraries built with different -std options

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||lto
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=103681

--- Comment #1 from Andrew Pinski  ---
The types should be compatiable between the different -std=c++ options.
Note one (now) known imcompatiablity is recored in PR 103681.
Someone would need to look into this one further to make sure there is not
another floating around.

[Bug c++/98500] ICE template template parameter with default parameter lambda

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-12-22

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

[Bug c++/54367] [meta-bug] lambda expressions

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

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

Bug 97458 Summary: C++ parsing fails when calling specialized template method 
inside lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97458

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

[Bug c++/82980] [9/10/11/12 Regression] template keyword should not be required for captured decl of the "base" type

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||gabriel_machado at live dot com

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

[Bug c++/97458] C++ parsing fails when calling specialized template method inside lambda

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Andrew Pinski  ---
Dup of bug 82980.

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

[Bug c++/82980] [9/10/11/12 Regression] template keyword should not be required for captured decl of the "base" type

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|Regression in determination |[9/10/11/12 Regression]
   |of current instantiation|template keyword should not
   |(invalid requirement of |be required for captured
   |template keyword)   |decl of the "base" type
   Last reconfirmed||2021-12-22
 Ever confirmed|0   |1
  Known to work||6.1.0
 Status|UNCONFIRMED |NEW
   Keywords||rejects-valid
  Known to fail||7.1.0

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

[Bug c++/82326] static_cast should be allowed when converting between vectors of just different signedness

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
Summary|static_cast for vector  |static_cast should be
   |extension not working?  |allowed when converting
   ||between vectors of just
   ||different signedness

[Bug c++/81973] alias virtual function does not cause the vtable to be emitted even if the aliased function is defined in the TU

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||link-failure
 Ever confirmed|0   |1
   Last reconfirmed||2021-12-22
 Status|UNCONFIRMED |NEW
Summary|Aliased virtual methods are |alias virtual function does
   |treated as undefined, so|not cause the vtable to be
   |the vtable is not generated |emitted even if the aliased
   ||function is defined in the
   ||TU

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

Note GCC (since 8) does warn about the types being different now:
:14:22: warning: 'void s::g()' alias between functions of incompatible
types 'void (s::)()' and 'void(s*)' [-Wattribute-alias=]
   14 | void g() __attribute__ ((alias ("s_g_alias")));
  |  ^
:25:14: note: aliased declaration here
   25 | void s_g_alias(s* this_){
  |  ^

[Bug d/103604] [12 Regression] trunk 20210506 fails to build in libphobos on mips64el-linux-gnu

[syq at debian dot org via Gcc-bugs]

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

--- Comment #26 from YunQiang Su  ---
(In reply to Iain Buclaw from comment #25)
> Fixed layout has been pushed out, should be all good now.

(In reply to YunQiang Su from comment #19)
> (In reply to Iain Buclaw from comment #18)
> > (In reply to Iain Buclaw from comment #16)
> > > (In reply to Iain Buclaw from comment #15)
> > > > Don't think it would fail now the statically allocated size is *at 
> > > > least*
> > > > same as C.  But some alias is still not matching up.
> > > core.sys.posix.sys.types is implicitly assuming X86 sizes.
> > 
> > (In reply to Iain Buclaw from comment #15)
> > > Created attachment 51999 [details]
> > > mips stat_t patch
> > > 
> > > Patch matches field declarations I can see in the headers, and it for sure
> > > reigns it in.
> > > 
> > > |  C  |  D  |
> > >  32 | 144 | 160 |
> > > o64 | 160 | 176 |
> > > n32 | 160 | 176 |
> > >  64 | 216 | 216 |
> > > 
> > > Don't think it would fail now the statically allocated size is *at least*
> > > same as C.  But some alias is still not matching up.
> > Ah, no, this is right, I just didn't build the C source with
> > -D_FILE_OFFSET_BITS=64
> 
> FYI: I find that gcc/glibc (for C) generates wrong code for O32 with
> -D_FILE_OFFSET_BITS=64.
> 
> I am digging it.

mipsel has no problem: I should use %lld to print the st_size.

[Bug driver/81371] Too many C++ templates output in build error

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c++ |driver
   Keywords||diagnostic

--- Comment #6 from Andrew Pinski  ---
The string "std::__cxx11::basic_string,
std::allocator >" comes from ld, though the demangler sources upstream is
part of GCC. I don't know if we want to special case this from the demangler
point of view or not.

[Bug c++/79424] dtor synthesized before abstractness correctly determined

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Keywords||rejects-valid
   Last reconfirmed||2021-12-22

--- Comment #1 from Andrew Pinski  ---
Confirmed, looks like only clang gets this right.

[Bug testsuite/103270] [12 regression] gcc.dg/vect/pr96698.c inner loop turned from hot to cold after r12-4526

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

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

luoxhu at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #7 from luoxhu at gcc dot gnu.org ---
Fixed on master.

[Bug middle-end/36282] [4.7 Regression] Spurious warning "asm declaration ignored due to conflict with previous rename"

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||ian at airs dot com

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

[Bug c++/35606] Unresolved #pragma weak prevents all function aliasing in C++

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Andrew Pinski  ---
Dup of bug 36282.

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

[Bug tree-optimization/103793] [12 Regression] ICE: in to_reg_br_prob_base, at profile-count.h:277 with -O3 -fno-guess-branch-probability since r12-6086-gcd5ae148c47c6dee

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

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

luoxhu at gcc dot gnu.org changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |luoxhu at gcc dot 
gnu.org

--- Comment #2 from luoxhu at gcc dot gnu.org ---

Confirmed. -fno-guess-branch-probability requires the profile_count be
initialized, so add guard like this?


+   if (true_edge->probability.initialized_p ())
+ {
+   edge exit_to_latch1 = single_pred_edge (loop1->latch);
+   exit_to_latch1->probability
+ = exit_to_latch1->probability.apply_scale (
+   true_edge->probability.to_reg_br_prob_base (),
+   REG_BR_PROB_BASE);
+   single_exit (loop1)->probability
+ = exit_to_latch1->probability.invert ();
+ }

[Bug c++/85461] A simple recursive TMP static const initializer defeats gcc

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

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

--- Comment #3 from Andrew Pinski  ---
Using constexpr is a decent workaround.
Note enum version of this is rejected by all compilers:
template
struct bitWidthHolding {
enum {width = (v == 0) ? 0 : bitWidthHolding<(v>>1)>::width + 1};
};
int a = bitWidthHolding<255>::width;

Which I find interesting.

[Bug tree-optimization/103797] Clang vectorized LightPixel while GCC does not

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Severity|normal  |enhancement

[Bug tree-optimization/103797] New: Clang vectorized LightPixel while GCC does not

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

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

Bug ID: 103797
   Summary: Clang vectorized LightPixel while GCC does not
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hubicka at gcc dot gnu.org
  Target Milestone: ---

Clang vectorises divss in LightPixel while GCC does not (at -O3).  This seems
to account for 17% difference in resteflood_svg benchmark of Firefox.

   │01864660  const&, mozilla::gfx::Point3DTyped
const&, unsigned int)>:
   │mozilla::gfx::(anonymous
namespace)::SpecularLightingSoftware::LightPixel(mozilla::gfx::Point3DTyped const&, mozilla::gfx::Point3DTyped
const&, unsigned int):
  0.05 │  push  %rbp
  0.07 │  mov   %rsp,%rbp
  0.71 │  xorps %xmm6,%xmm6
  0.32 │  addss %xmm6,%xmm4
   │  unpcklps  %xmm3,%xmm5
  0.78 │  movss
anon.5bcbce9b5eeaaf1a18a99b9a5b62e1ce.3.llvm.5306652999446557335+0x6d8,%xmm8
  0.01 │  addps %xmm8,%xmm5
  1.47 │  movaps%xmm4,%xmm9
   │  mulss %xmm4,%xmm9
   │  movaps%xmm5,%xmm7
  0.01 │  mulps %xmm5,%xmm7
  3.35 │  movaps%xmm7,%xmm3
   │  shufps$0x55,%xmm7,%xmm3
  0.99 │  addss %xmm9,%xmm3
  1.59 │  addss %xmm7,%xmm3
  2.01 │  sqrtss%xmm3,%xmm3
 11.43 │  divss %xmm3,%xmm4
  6.76 │  shufps$0x0,%xmm3,%xmm3
  0.01 │  divps %xmm3,%xmm5
  2.58 │  mulss %xmm1,%xmm4
  0.04 │  unpcklps  %xmm0,%xmm2
   │  mulps %xmm5,%xmm2
  2.67 │  movaps%xmm2,%xmm0
  0.04 │  shufps$0x55,%xmm2,%xmm0
  2.11 │  addss %xmm4,%xmm0
  1.87 │  addss %xmm2,%xmm0
  2.82 │  cmpless   %xmm0,%xmm6
  2.20 │  andps %xmm8,%xmm6
  1.05 │  mulss %xmm0,%xmm6
  4.04 │  mulss .str.6.llvm.231702015065810902+0x77,%xmm6
  3.14 │  cvttss2si %xmm6,%eax
  4.45 │  mov   0x8(%rdi),%ecx
  0.00 │  mov   0xc(%rdi),%edx
   │  movzwl%ax,%eax
  1.10 │  test  %edx,%edx
   │↓ jle   92
   │88:   imul  %eax,%eax
  9.06 │  shr   $0xf,%eax
  3.12 │  dec   %edx
   │↑ jne   88
   │92:   shr   $0x8,%eax
  1.95 │  movzwl0x10(%rdi,%rax,2),%eax
  6.48 │  imul  %eax,%ecx
  0.99 │  shr   $0x8,%ecx
  1.06 │  mov   %esi,%eax
  0.01 │  shr   $0x8,%eax
   │  mov   %esi,%edx
   │  shr   $0x10,%edx
  0.01 │  mov   $0xff,%edi
   │  and   %edi,%esi
  0.01 │  imul  %ecx,%esi
  3.32 │  shr   $0xf,%esi
  1.81 │  cmp   %edi,%esi ▒
  0.04 │  cmovae%edi,%esi ▒
  1.99 │  and   %edi,%eax ▒
  0.01 │  imul  %ecx,%eax ▒
   │  shr   $0xf,%eax ▒
  0.01 │  cmp   %edi,%eax ▒
  0.28 │  cmovae%edi,%eax ▒
  0.96 │  and   %edi,%edx ▒
   │  imul  %ecx,%edx ▒
   │  shr   $0xf,%edx ▒
  0.92 │  cmp   %edi,%edx ▒
  0.85 │  cmovae%edi,%edx ▒
  1.00 │  cmp   %eax,%edx ▒
  1.20 │  mov   %eax,%ecx ▒
   │  cmova %edx,%ecx ▒
  2.17 │  cmp   %esi,%ecx ▒
  1.15 │  cmovbe%esi,%ecx ▒
  1.79 │  shl   $0x18,%ecx▒
  1.17 │  shl   $0x10,%edx▒
   │  shl   $0x8,%eax ▒
  0.03 │  or%edx,%eax ▒
  0.01 │  or%esi,%eax ▒
  0.14 │  or%ecx,%eax ▒
  0.72 │  pop   %rbp  ▒
  0.04 │← ret  
   
   
  ▒

[Bug c++/66153] Internal compiler error in nested template function

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

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

--- Comment #10 from Andrew Pinski  ---
A little more reduced:
template struct c { obj data; };
struct r {};
template obj g(const obj );
template
  auto g(const c & arg)
-> c(arg.data))>
{
  return c(arg.data))>{};
}
int main()
{
  c array;  
  g<1>(array);
}
 CUT 
Without the guide for the return type, GCC accepts the code. Somehow GCC is
messing up g, Removing the template argument N also allows GCC to accept the
code.

[Bug c++/66153] Internal compiler error in nested template function

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

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

--- Comment #9 from Andrew Pinski  ---
Here is the full on reduced testcase (the previous one was wrong):
template struct Container {
  obj data[1];
};
template struct Recursive {};
template obj function(const obj )
{
  return obj{};
}
template
  auto function(const Container & arg)
-> Container(arg.data[0]))>
{
  Container(arg.data[0]))> ret;
  return ret;
}
int main(int argc,char **argv)
{
  Container > > array;  
  function<1>(array);
}

[Bug target/103611] GCC generates suboptimal code for SSE2/SSE4.1 64-bit integer element extraction on 32-bit x86 targets

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
 CC||roger at nextmovesoftware dot 
com

--- Comment #7 from Roger Sayle  ---
This should now be fixed on mainline.

[Bug c++/66153] Internal compiler error in nested template function

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

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

--- Comment #8 from Andrew Pinski  ---
Reduced further:
#include 

template  struct TypeMapper { static const int NestLevel =
T::NestLevel; };
template<> struct TypeMapper { static const int NestLevel = 0; };
template struct Container { obj data; };
template struct Recursive {
  enum { NestLevel = TypeMapper::NestLevel + 1};
};
template::type *
= nullptr >
auto function(const obj )-> obj
{
  return arg;
}
template::type * =
nullptr >
  auto function(const obj )-> obj
{
  return obj{};
}
template
  auto function(const Container & arg) ->
Container(arg.data))>
{
  Container > > ret;
  return ret;
}
int main(int argc,char **argv)
{
  Container > > array;
  Container > > ret;

  function<1>(array);
}

- CUT -
I have seen another one similar to this recently.

[Bug c++/66153] Internal compiler error in nested template function

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||rejects-valid
   Severity|major   |normal

[Bug d/103739] Bootstrap broken on powerpc64-linux

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

Iain Buclaw  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=103528
 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #6 from Iain Buclaw  ---
Fix committed as part of PR103528.

[Bug d/103528] [12 regression] d21 doesn't build on Solaris

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

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

--- Comment #9 from CVS Commits  ---
The master branch has been updated by Iain Buclaw :

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

commit r12-6091-g7c6ae994fb587c19ca14aebe18dbc9aca83be609
Author: Iain Buclaw 
Date:   Thu Dec 16 23:56:16 2021 +0100

config: Add check whether D compiler works (PR103528)

As well as checking for the existence of a GDC compiler, also validate
that it has also been built with libphobos, otherwise warn or fail with
the message that GDC is required to build d.

config/ChangeLog:

PR d/103528
* acx.m4 (ACX_PROG_GDC): Add check whether D compiler works.

ChangeLog:

* configure: Regenerate.

[Bug fortran/103794] ICE in gfc_check_reshape, at fortran/check.c:4727

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed||2021-12-21
 CC||anlauf at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.  We're not trying hard enough to simplify constant expressions
involving iterators.

The following fixes the testcases, but may not be the best/generic solution:

diff --git a/gcc/fortran/check.c b/gcc/fortran/check.c
index b4db9337e9f..9f597ccb4b4 100644
--- a/gcc/fortran/check.c
+++ b/gcc/fortran/check.c
@@ -33,6 +33,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "intrinsic.h"
 #include "constructor.h"
 #include "target-memory.h"
+#include "match.h"


 /* Reset a BOZ to a zero value.  This is used to prevent run-on errors
@@ -4721,6 +4722,7 @@ gfc_check_reshape (gfc_expr *source, gfc_expr *shape,
 {
   gfc_expr *e;
   int i, extent;
+  gfc_reduce_init_expr (shape);
   for (i = 0; i < shape_size; ++i)
{
  e = gfc_constructor_lookup_expr (shape->value.constructor, i);

[Bug c++/100673] [coroutines] Non-template, UDT await_suspend return-type results in ICE.

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||jack.cui2 at foxmail dot com

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

[Bug c++/103790] internal compiler error: Segmentation fault when playing with coroutine

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #5 from Andrew Pinski  ---
Dup of bug 100673 then.

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

[Bug middle-end/103791] A "segmentation fault" error appears when trying to compile a kernel

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

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

--- Comment #2 from Andrew Pinski  ---
>For some reason I can't find a preprocessed file.

Because you used -E with -save-temps, so the preprocessed source will be in the
output file.

[Bug ipa/103766] [12 Regression] Initialization of variable passed via static chain is lost.

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

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu.org

--- Comment #13 from Francois-Xavier Coudert  ---
I think this is a Fortran reproducer that does not depend on printing to
stdout:

program crash
  implicit none
  real :: a
  a = 1.
  call sub()
contains
  subroutine sub()
character(len=100) :: s
real :: x

write(s,*) a
read(s,*) x
if (x /= 1.) stop 1
  end subroutine sub
end program crash


It fails for me with trunk (before patch), but passed with 11.2.0
Could it be added to the testsuite please?

[Bug driver/82534] [meta-bug] POSIX compliant compiler options

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

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||documentation

--- Comment #2 from Eric Gallager  ---
This would involve updating the "Invoking GCC" page of the manual, which
explicitly specifies that things work the way they currently work:
https://gcc.gnu.org/onlinedocs/gcc/Invoking-GCC.html#Invoking-GCC

[Bug objc++/58783] Fast enumeration is not supported for Objective-C++

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

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

--- Comment #10 from Eric Gallager  ---
Note that on the Standards page of the manual, it currently says "fast
enumeration (only for Objective-C)", so once this bug is fixed, that
parenthetical can be removed:
https://gcc.gnu.org/onlinedocs/gcc/Standards.html#Standards

[Bug debug/103788] [9/10/11/12 Regression] '-fcompare-debug' failure (length) w/ -O1

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

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

--- Comment #4 from Andrew Pinski  ---
In .gimple already:
-g2:
  [/app/example.cpp:11:5] goto ;
vs -g0:
  [/app/example.cpp:10:17] goto ;


-g2:
  :;
  # DEBUG BEGIN STMT;
  SAVE_EXPR ;, x = (SAVE_EXPR ) + x;;
  # DEBUG BEGIN STMT;
   ++i;
  # DEBUG BEGIN STMT;
  goto ;


vs -g0:
  :;
  SAVE_EXPR ;, x = (SAVE_EXPR ) + x;;
   ++i;
  goto ;

[Bug debug/103788] [9/10/11/12 Regression] '-fcompare-debug' failure (length) w/ -O1

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #2)
> (In reply to Martin Liška from comment #1)
> > Likely latent which was exposed with r9-3352-g87bd153645f393a1.

here is a slightly modified (just line rather than column change) which fails
in GCC 8 also:
int
bar (void);

int
foo (int x)
{
  int i;

  for (i = 0; i <= __INT_MAX__; ++i)
x += bar () < (
x ? 2 : 1 );
  return x;
}

[Bug debug/103788] [9/10/11/12 Regression] '-fcompare-debug' failure (length) w/ -O1

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=100733

--- Comment #2 from Andrew Pinski  ---
(In reply to Martin Liška from comment #1)
> Likely latent which was exposed with r9-3352-g87bd153645f393a1.

[Bug debug/103788] [9/10/11/12 Regression] '-fcompare-debug' failure (length) w/ -O1

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Target Milestone|--- |9.5
 CC||pinskia at gcc dot gnu.org

[Bug fortran/103796] New: ICE in gfc_conv_expr_val, at fortran/trans-expr.c:9446

[gscfq--- via Gcc-bugs]

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

Bug ID: 103796
   Summary: ICE in gfc_conv_expr_val, at fortran/trans-expr.c:9446
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started with r8 :


$ cat z1.f90
program p
   form team ('a', team)
end


$ cat z2.f90
program p
   form team (1, team)
end


$ gfortran-12-20211219 -c z1.f90 -fcoarray=single
$
$ gfortran-12-20211219 -c z1.f90 -fcoarray=lib
z1.f90:2:24:

2 |form team ('a', team)
  |1
internal compiler error: in gfc_conv_expr_val, at fortran/trans-expr.c:9446
0x888132 gfc_conv_expr_val(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.c:9446
0x8ce5bd gfc_trans_form_team(gfc_code*)
../../gcc/fortran/trans-stmt.c:744
0x854747 trans_code
../../gcc/fortran/trans.c:2068
0x87d6be gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:7644
0x80063e translate_all_program_units
../../gcc/fortran/parse.c:6651
0x80063e gfc_parse_file()
../../gcc/fortran/parse.c:6938
0x84d53f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:216

[Bug fortran/103795] New: ICE in gfc_conv_array_constructor_expr, at fortran/trans-expr.c:8325

[gscfq--- via Gcc-bugs]

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

Bug ID: 103795
   Summary: ICE in gfc_conv_array_constructor_expr, at
fortran/trans-expr.c:8325
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started with r7 (expecting STAT=scalar-int-variable) :


$ cat z1.f90
program p
   integer :: a[*] = 2
   print *, a[1, stat=[1]]
end


$ cat z2.f90
program p
   integer :: a[*] = 2
   print *, a[1, stat=1]
end


$ cat z3.f90
program p
   integer :: a[*] = 2
   real :: stat[*]   ! character ...
   print *, a[1, stat=stat]
end


$ cat z4.f90
program p
   integer :: a[*] = 2
   integer :: stat[*]
   print *, a[1, stat=stat[1]]
end


$ gfortran-12-20211219 -c z1.f90 -fcoarray=single
$
$ gfortran-12-20211219 -c z1.f90 -fcoarray=lib
z1.f90:3:26:

3 |print *, a[1, stat=[1]]
  |  1
internal compiler error: in gfc_conv_array_constructor_expr, at
fortran/trans-expr.c:8325
0x886066 gfc_conv_array_constructor_expr
../../gcc/fortran/trans-expr.c:8325
0x886066 gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.c:9418
0x88cfa2 gfc_conv_expr_reference(gfc_se*, gfc_expr*, bool)
../../gcc/fortran/trans-expr.c:9540
0x8a26b9 gfc_conv_intrinsic_caf_get
../../gcc/fortran/trans-intrinsic.c:1701
0x8b1c2e gfc_conv_intrinsic_function(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-intrinsic.c:10303
0x8852da gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.c:9394
0x88cfa2 gfc_conv_expr_reference(gfc_se*, gfc_expr*, bool)
../../gcc/fortran/trans-expr.c:9540
0x8b74a7 gfc_trans_transfer(gfc_code*)
../../gcc/fortran/trans-io.c:2582
0x8546d7 trans_code
../../gcc/fortran/trans.c:2136
0x8b4f8e build_dt
../../gcc/fortran/trans-io.c:2026
0x8546b7 trans_code
../../gcc/fortran/trans.c:2108
0x87d6be gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:7644
0x80063e translate_all_program_units
../../gcc/fortran/parse.c:6651
0x80063e gfc_parse_file()
../../gcc/fortran/parse.c:6938
0x84d53f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:216

[Bug fortran/103794] New: ICE in gfc_check_reshape, at fortran/check.c:4727

[gscfq--- via Gcc-bugs]

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

Bug ID: 103794
   Summary: ICE in gfc_check_reshape, at fortran/check.c:4727
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to at least r5 :


$ cat z1.f90
program p
   integer, parameter :: a(2) = 2
   print *, reshape([1,2,3], [(a*i, i=1,2)])
end


$ cat z2.f90
program p
   print *, reshape([1,2,3], [([2,2]*i, i=1,2)])
end


$ gfortran-12-20211219 -c z1.f90
f951: internal compiler error: Segmentation fault
0xd6d1ff crash_signal
../../gcc/toplev.c:322
0x7739c7 gfc_check_reshape(gfc_expr*, gfc_expr*, gfc_expr*, gfc_expr*)
../../gcc/fortran/check.c:4727
0x7b4339 do_check
../../gcc/fortran/intrinsic.c:4770
0x7b4339 check_specific
../../gcc/fortran/intrinsic.c:4783
0x7bc3a4 gfc_intrinsic_func_interface(gfc_expr*, int)
../../gcc/fortran/intrinsic.c:5020
0x81001c resolve_unknown_f
../../gcc/fortran/resolve.c:2972
0x81001c resolve_function
../../gcc/fortran/resolve.c:3329
0x81001c gfc_resolve_expr(gfc_expr*)
../../gcc/fortran/resolve.c:7166
0x8164d4 gfc_resolve_expr(gfc_expr*)
../../gcc/fortran/resolve.c:7133
0x8164d4 gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.c:11923
0x814e8f gfc_resolve_blocks(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.c:10939
0x8151e8 gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.c:11913
0x817b27 resolve_codes
../../gcc/fortran/resolve.c:17532
0x817bee gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:17567
0x7fff14 resolve_all_program_units
../../gcc/fortran/parse.c:6586
0x7fff14 gfc_parse_file()
../../gcc/fortran/parse.c:6842
0x84d53f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:216

[Bug tree-optimization/103793] [12 Regression] ICE: in to_reg_br_prob_base, at profile-count.h:277 with -O3 -fno-guess-branch-probability since r12-6086-gcd5ae148c47c6dee

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-12-21
 Ever confirmed|0   |1
 CC||luoxhu at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
   Target Milestone|--- |12.0
Summary|[12 Regression] ICE: in |[12 Regression] ICE: in
   |to_reg_br_prob_base, at |to_reg_br_prob_base, at
   |profile-count.h:277 with|profile-count.h:277 with
   |-O3 |-O3
   |-fno-guess-branch-probabili |-fno-guess-branch-probabili
   |ty  |ty since
   ||r12-6086-gcd5ae148c47c6dee

--- Comment #1 from Martin Liška  ---
Started with r12-6086-gcd5ae148c47c6dee.

[Bug c/103791] A "segmentation fault" error appears when trying to compile a kernel

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
   Last reconfirmed||2021-12-21

--- Comment #1 from Martin Liška  ---
> For some reason I can't find a preprocessed file.

Maybe it's saved to the .o file? For what object file does it crash?

[Bug tree-optimization/103793] New: [12 Regression] ICE: in to_reg_br_prob_base, at profile-count.h:277 with -O3 -fno-guess-branch-probability

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 103793
   Summary: [12 Regression] ICE: in to_reg_br_prob_base, at
profile-count.h:277 with -O3
-fno-guess-branch-probability
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu

Created attachment 52040
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52040=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O3 -fno-guess-branch-probability testcase.c
during GIMPLE pass: lsplit
testcase.c: In function 'foo':
testcase.c:4:1: internal compiler error: in to_reg_br_prob_base, at
profile-count.h:277
4 | foo (int x, int w)
  | ^~~
0x7c38c2 profile_probability::to_reg_br_prob_base() const
/repo/gcc-trunk/gcc/profile-count.h:277
0x7c38c2 profile_probability::to_reg_br_prob_base() const
/repo/gcc-trunk/gcc/profile-count.h:275
0x7c38c2 split_loop
/repo/gcc-trunk/gcc/tree-ssa-loop-split.c:630
0x14ea62b tree_ssa_split_loops
/repo/gcc-trunk/gcc/tree-ssa-loop-split.c:1693
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r12-6087-20211220211250-g51a24e4a984-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r12-6087-20211220211250-g51a24e4a984-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.0 20211221 (experimental) (GCC)

[Bug target/103773] wrong code at -Oz due to sign extension

[zsojka at seznam dot cz via Gcc-bugs]

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

--- Comment #4 from Zdenek Sojka  ---
(In reply to Roger Sayle from comment #3)
> Patch proposed
> https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587258.html

Thank you for the patch. Does it work correctly with the red zone? I am asking
since the "mov" instruction normally doesn't affect stack, and I don't see any
indication that the "push" alternative does. But I definitely do not have
enough knowledge about the GCC internals.

[Bug tree-optimization/103173] strncpy output may be truncated copying 32 bytes from a string of length 1439 (bogus) [-Werror=stringop-truncation]

[patrickdepinguin at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Thomas De Schampheleire  
---
Note also that in the test program of comment #3, there is no problem if using
the 'password' or 'application' fields, rather than 'user', which is first in
the structure.

[Bug target/103773] wrong code at -Oz due to sign extension

[roger at nextmovesoftware dot com via Gcc-bugs]

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

--- Comment #3 from Roger Sayle  ---
Patch proposed
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587258.html

[Bug sanitizer/103792] stack-use-after-scope false positive with exceptions on ARM EABI

[mcross at irobot dot com via Gcc-bugs]

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

--- Comment #1 from Matt Cross  ---
Address Sanitizer output from executing this:

=
==29328==ERROR: AddressSanitizer: stack-use-after-scope on address 0xbed737e0
at pc 0xb319b875 bp 0xbed733a0 sp 0xbed733a8
WRITE of size 388 at 0xbed737e0 thread T0
#0 0xb319b872 in memcpy (/usr/lib/brewst.so.d/libasan.so.6+0x2e872)
#1 0x10d92 in process_dummy_recursive(int, Dummy)
/home/mcross/sources/brewst3/utils/mcross-test/mcross-test1.cpp:41
#2 0x10dd8 in exc_cleanup_test()
/home/mcross/sources/brewst3/utils/mcross-test/mcross-test1.cpp:65
#3 0x10de4 in main
/home/mcross/sources/brewst3/utils/mcross-test/mcross-test1.cpp:70
#4 0xb2eb455a in __libc_start_main (/usr/lib/brewst.so.d/libc.so.6+0x1755a)

Address 0xbed737e0 is located in stack of thread T0
SUMMARY: AddressSanitizer: stack-use-after-scope
(/usr/lib/brewst.so.d/libasan.so.6+0x2e872) in memcpy
Shadow bytes around the buggy address:
  0x37dae6a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x37dae6b0: 00 00 00 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8
  0x37dae6c0: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
  0x37dae6d0: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
  0x37dae6e0: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 00 00 00 00 00 00
=>0x37dae6f0: 00 00 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8[f8]f8 f8 f8
  0x37dae700: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
  0x37dae710: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
  0x37dae720: f8 f8 f8 f8 00 00 00 00 00 00 00 00 00 00 00 00
  0x37dae730: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x37dae740: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:   fa
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  Array cookie:ac
  Intra object redzone:bb
  ASan internal:   fe
  Left alloca redzone: ca
  Right alloca redzone:cb
  Shadow gap:  cc
==29328==ABORTING

[Bug sanitizer/103792] New: stack-use-after-scope false positive with exceptions on ARM EABI

[mcross at irobot dot com via Gcc-bugs]

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

Bug ID: 103792
   Summary: stack-use-after-scope false positive with exceptions
on ARM EABI
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mcross at irobot dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

Created attachment 52039
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52039=edit
reproduction code

This is the same issue as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81021 ,
except specific to ARM EABI.  I think the same change needs to be applied to
the ARM EABI specific code that sets up the call to __cxa_end_cleanup() in
gcc/tree-eh.c.

I have attached minimal code that reproduces the issue (well, as minimal as I
could get it).

To reproduce, this must be compiled with "-O1 -fsanitize=address".

The reproduction code is also available on Compiler Explorer here:
https://godbolt.org/z/5q1Yq5za3  Unfortunately it cannot run it there, but here
is what I see when I run it (based on generated code addresses in that view):

* At address 10cce is where the exception is thrown in the intermediate()
function (it has inline the calls to the constructors for "struct Bad" and
optimized it down to just throwing an exception).
* The clean-up for for this PC in intermediate() is at 10cd2, and if you follow
it through it effectively just poisons the stack and then calls
__cxa_end_cleanup().

This leaves the stack poisoned after exception handling is complete, which
later code then trips over.

[Bug target/103785] [12 Regression] Ada bootstrap ICEs on i?86

[roger at nextmovesoftware dot com via Gcc-bugs]

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

--- Comment #4 from Roger Sayle  ---
This is either (i) related to PR 103773, where GNAT is somehow setting
optimize_size to a value greater than 1 (i.e. -Oz) and getting hit by the known
memory corruption or (ii) somehow related to the highpart multiplication
changes (which on double checking look sound) or (iii) caused by someone elses
changes.
If we could identify which patch to revert to resolve the issue, or even which
hunk, that would help.  I'm attempting various gnat bootstraps myself.

Sorry for the inconvenience.

[Bug tree-optimization/103173] strncpy output may be truncated copying 32 bytes from a string of length 1439 (bogus) [-Werror=stringop-truncation]

[patrickdepinguin at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Thomas De Schampheleire  
---
While the original test program failed on gcc 11.2.0 but not on gcc 9.4.0, I
now encounter a very similar case that does fail on gcc 9.4.0:

--
#include 

#define MAX_NR_USERS 10

struct user_data {
  char user[32];
  char password[32];
  char application[32];
};

struct user_data users[MAX_NR_USERS];

void login_process()
{
char tmp_user[33];

for (int i = 0; i < MAX_NR_USERS; i++)
{
snprintf(tmp_user, sizeof(tmp_user), "%s", &(users[i].user[0]));
}
}
--


arm-cortex_a53-linux-gnueabi-gcc /tmp/gcc-9-test.c -c -Wall -O2 
/tmp/gcc-9-test.c: In function 'login_process':
/tmp/gcc-9-test.c:19:47: warning: '%s' directive output may be truncated
writing up to 959 bytes into a region of size 33 [-Wformat-truncation=]
   19 | snprintf(tmp_user, sizeof(tmp_user), "%s",
&(users[i].user[0]));
  |   ^~
/tmp/gcc-9-test.c:19:9: note: 'snprintf' output between 1 and 960 bytes into a
destination of size 33
   19 | snprintf(tmp_user, sizeof(tmp_user), "%s",
&(users[i].user[0]));
  | ^~~


Here, the claimed 960 bytes are the total size of 'users' (3 * 32 * 10), while
the copied 'user' field is only 33 byte and there should be no problem.
The error is now -Wformat-truncation instead of -Wstringop-truncation but
otherwise this looks to be the same underlying problem.

This compiler is:

Using built-in specs.
COLLECT_GCC=.../buildroot-toolchains-bis/output/host/opt/ext-toolchain/bin/arm-cortex_a53-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=.../buildroot-toolchains-bis/output/host/opt/ext-toolchain/arm/bin/../libexec/gcc/arm-cortex_a53-linux-gnueabi/9.4.0/lto-wrapper
Target: arm-cortex_a53-linux-gnueabi
Configured with:
.../ctng/crosstool-ng/.build/arm-cortex_a53-linux-gnueabi/src/gcc/configure
--build=x86_64-build_pc-linux-gnu --host=x86_64-build_pc-linux-gnu
--target=arm-cortex_a53-linux-gnueabi
--prefix=.../ctng/crosstool-ng/targets/arm-cortex_a53-linux-gnueabi
--exec_prefix=.../ctng/crosstool-ng/targets/arm-cortex_a53-linux-gnueabi
--with-sysroot=.../ctng/crosstool-ng/targets/arm-cortex_a53-linux-gnueabi/arm-cortex_a53-linux-gnueabi/sysroot
--enable-languages=c,c++,fortran --with-cpu=cortex-a53 --with-fpu=neon-fp-armv8
--with-float=hard --with-pkgversion='crosstool-NG 1.24.0.487_10ac846'
--enable-__cxa_atexit --disable-tm-clone-registry --disable-libmudflap
--disable-libgomp --disable-libssp --disable-libquadmath
--disable-libquadmath-support --disable-libsanitizer --disable-libmpx
--with-gmp=.../ctng/crosstool-ng/.build/arm-cortex_a53-linux-gnueabi/buildtools
--with-mpfr=.../ctng/crosstool-ng/.build/arm-cortex_a53-linux-gnueabi/buildtools
--with-mpc=.../ctng/crosstool-ng/.build/arm-cortex_a53-linux-gnueabi/buildtools
--with-isl=.../ctng/crosstool-ng/.build/arm-cortex_a53-linux-gnueabi/buildtools
--disable-lto --without-zstd --enable-threads=posix --enable-target-optspace
--disable-plugin --disable-nls --disable-multilib
--with-local-prefix=.../ctng/crosstool-ng/targets/arm-cortex_a53-linux-gnueabi/arm-cortex_a53-linux-gnueabi/sysroot
--enable-long-long
Thread model: posix
gcc version 9.4.0 (crosstool-NG 1.24.0.487_10ac846)

[Bug c/103791] New: A "segmentation fault" error appears when trying to compile a kernel

[ak47.almank at gmail dot com via Gcc-bugs]

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

Bug ID: 103791
   Summary: A "segmentation fault" error appears when trying to
compile a kernel
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ak47.almank at gmail dot com
  Target Milestone: ---

So I am trying to compile a kernel (the last step of building Linux from
scratch) and when I enter the command 'make mrproper', it just errors and says:

'gcc: internal compiler error: Segmentation fault signal terminated program cc1
Please submit a full bug report,
with preprocessed source if appropriate.'

The output of the command with the flags -v and -save-temps:

gcc: internal compiler error: Segmentation fault signal terminated program cc1
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Using built-in specs.
COLLECT_GCC=gcc
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/usr LD=ld --enable-languages=c,c++
--disable-multilib --disable-bootstrap --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.0 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-E' '-mtune=generic' '-march=x86-64'
 /usr/libexec/gcc/x86_64-pc-linux-gnu/11.2.0/cc1 -E -quiet -v - -mtune=generic
-march=x86-64 -fpch-preprocess -dumpbase -


I got the output of this from the command:
CFLAGS="-v -save-temps" make mrproper

The options that were used:

Collecting options:
-v -save-temps -E -mtune=generic -march=x86-64

cc1 options (where the error occurred):
-E -quiet -v -mtune=generic -march=x86-64 -fpch-preprocess -dumpbase -

For some reason I can't find a preprocessed file.

Please can you help me with all this information? it will be much appreciated.

Thanks.

[Bug c++/103790] internal compiler error: Segmentation fault when playing with coroutine

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

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

--- Comment #4 from Iain Sandoe  ---
(In reply to Martin Liška from comment #3)
> > the error is correct suspend_always{} is not a valid return for
> > await_suspend() - but we should not ICE, of course.
> 
> Note, we don't ICE on master since the revision.

Ah OK - I have quite a backlog of pending backports for 11.x and 10.x so I
expect that will be fixed for the next release.

[Bug c++/103790] internal compiler error: Segmentation fault when playing with coroutine

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

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

--- Comment #3 from Martin Liška  ---
> the error is correct suspend_always{} is not a valid return for
> await_suspend() - but we should not ICE, of course.

Note, we don't ICE on master since the revision.

[Bug c++/103790] internal compiler error: Segmentation fault when playing with coroutine

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

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

Iain Sandoe  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code

--- Comment #2 from Iain Sandoe  ---
(In reply to Martin Liška from comment #1)
> Apparently, master reject the code now since r12-4101-g8009c79b64b532d8:
> 
> test_co_await.cpp: In function ‘task foo()’:
> test_co_await.cpp:48:5: error: ‘await_suspend’ must return ‘void’, ‘bool’ or
> a coroutine handle

the error is correct suspend_always{} is not a valid return for await_suspend()
- but we should not ICE, of course.

[Bug c++/103790] internal compiler error: Segmentation fault when playing with coroutine

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||iains at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
   Last reconfirmed||2021-12-21
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Apparently, master reject the code now since r12-4101-g8009c79b64b532d8:

test_co_await.cpp: In function ‘task foo()’:
test_co_await.cpp:48:5: error: ‘await_suspend’ must return ‘void’, ‘bool’ or a
coroutine handle

[Bug target/92137] [ia32] Missing documentation for ia32 builtins

[frankhb1989 at gmail dot com via Gcc-bugs]

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

frankhb1989 at gmail dot com changed:

   What|Removed |Added

 CC||frankhb1989 at gmail dot com

--- Comment #8 from frankhb1989 at gmail dot com ---
(In reply to Richard Biener from comment #1)
> You shouldn't use those, they are for internal use only.  That's the reason
> they are not documented.

There are cases of legitimate use, e.g. given that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29776 is still not fixed, one may
want something like:

int
floor2(uint64_t x)
{
#if __has_builtin(__builtin_ia32_bsrdi)
return __builtin_ia32_bsrdi(x);
#elif __has_builtin(__builtin_clzll)
return 63 - size_t(__builtin_clzll(x));
#else
// ...
#endif
}

The key point is that __has_builtin checks are apparently cleaner than
traditional #if defined(__xxx__)+headers+intrinsics way. Moreover,
__has_builtin and __builtin_xxx may be even more portable (among compilers) and
preferred in new code. The intentional statement you quoted was posted in 2005;
this seems outdated today.

[Bug rtl-optimization/63281] powerpc64le creates 64 bit constants from scratch instead of loading them

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

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

--- Comment #13 from Segher Boessenkool  ---
If we need more than three insns to create a constant we are better off loading
it from memory, in all cases.  Maybe three is too much already, at least on
some processors?

[Bug rtl-optimization/63281] powerpc64le creates 64 bit constants from scratch instead of loading them

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

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

--- Comment #12 from Segher Boessenkool  ---
This is my g:72b2f3317b44, two years and a day old :-)

[Bug c++/103790] New: internal compiler error: Segmentation fault when playing with coroutine

[jack.cui2 at foxmail dot com via Gcc-bugs]

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

Bug ID: 103790
   Summary: internal compiler error: Segmentation fault when
playing with coroutine
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jack.cui2 at foxmail dot com
  Target Milestone: ---

Created attachment 52038
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52038=edit
preprocessed file that trigger the issue

Using built-in specs.
COLLECT_GCC=g++-11
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
11.1.0-1ubuntu1~18.04.1' --with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-11
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin
--enable-default-pie --with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-werror --disable-cet --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-11-YRKbe7/gcc-11-11.1.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-11-YRKbe7/gcc-11-11.1.0/debian/tmp-gcn/usr
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.1.0 (Ubuntu 11.1.0-1ubuntu1~18.04.1)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++20' '-fcoroutines' '-c'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/11/cc1plus -E -quiet -v -imultiarch
x86_64-linux-gnu -D_GNU_SOURCE test_co_await.cpp -mtune=generic -march=x86-64
-std=c++20 -fcoroutines -fpch-preprocess -fasynchronous-unwind-tables
-fstack-protector-strong -Wformat -Wformat-security -o test_co_await.ii
ignoring duplicate directory "/usr/include/x86_64-linux-gnu/c++/11"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/11/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/11/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/11
 /usr/include/x86_64-linux-gnu/c++/11
 /usr/include/c++/11/backward
 /usr/lib/gcc/x86_64-linux-gnu/11/include
 /usr/local/include
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++20' '-fcoroutines' '-c'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/11/cc1plus -fpreprocessed test_co_await.ii
-quiet -dumpbase test_co_await.cpp -dumpbase-ext .cpp -mtune=generic
-march=x86-64 -std=c++20 -version -fcoroutines -fasynchronous-unwind-tables
-fstack-protector-strong -Wformat -Wformat-security -o test_co_await.s
GNU C++20 (Ubuntu 11.1.0-1ubuntu1~18.04.1) version 11.1.0 (x86_64-linux-gnu)
compiled by GNU C version 11.1.0, GMP version 6.1.2, MPFR version
4.0.1, MPC version 1.1.0, isl version isl-0.19-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++20 (Ubuntu 11.1.0-1ubuntu1~18.04.1) version 11.1.0 (x86_64-linux-gnu)
compiled by GNU C version 11.1.0, GMP version 6.1.2, MPFR version
4.0.1, MPC version 1.1.0, isl version isl-0.19-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: fa8709337e38341bd283d8a4fb935104
test_co_await.cpp: In function ‘task foo()’:
test_co_await.cpp:48:18: internal compiler error: Segmentation fault
   48 | co_await bar{};
  |  ^
0x1702697 internal_error(char const*, ...)
???:0
0x68de56 finish_co_await_expr(unsigned int, tree_node*)
???:0
0x7888ee c_parse_file()
???:0
0x85988d c_common_parse_file()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug fortran/103789] ICE when providing kind argument to mask{l,r}

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2021-12-21
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #2 from Martin Liška  ---
Old at least as 4.8.0.

[Bug debug/103788] [9/10/11/12 Regression] '-fcompare-debug' failure (length) w/ -O1

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-12-21
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Likely latent which was exposed with r9-3352-g87bd153645f393a1.

[Bug middle-end/99578] [11/12 Regression] gcc-11 -Warray-bounds or -Wstringop-overread warning when accessing a pointer from integer literal

[pmenzel+gcc at molgen dot mpg.de via Gcc-bugs]

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

--- Comment #20 from Paul Menzel  ---
(In reply to Andrew Pinski from comment #19)
> *** Bug 103768 has been marked as a duplicate of this bug. ***

It’d be great, if you could advise how to address the warning in SeaBIOS.

In file included from src/fw/smm.c:18:
src/fw/smm.c: In function 'smm_save_and_copy':
src/string.h:23:16: warning: '__builtin_memcpy' offset [0, 511] is out of
the bounds [0, 0] [-Warray-bounds]
   23 | #define memcpy __builtin_memcpy
src/fw/smm.c:148:5: note: in expansion of macro 'memcpy'
  148 | memcpy(>cpu, >cpu, sizeof(smm->cpu));
  | ^~

[Bug d/103604] [12 Regression] trunk 20210506 fails to build in libphobos on mips64el-linux-gnu

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

Iain Buclaw  changed:

   What|Removed |Added

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

--- Comment #25 from Iain Buclaw  ---
Fixed layout has been pushed out, should be all good now.

[Bug d/103604] [12 Regression] trunk 20210506 fails to build in libphobos on mips64el-linux-gnu

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

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

--- Comment #24 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Iain Buclaw
:

https://gcc.gnu.org/g:38d8dec9c9d6a735759ddebe6d90a50719a7f94c

commit r9-9881-g38d8dec9c9d6a735759ddebe6d90a50719a7f94c
Author: Iain Buclaw 
Date:   Tue Dec 21 14:07:37 2021 +0100

libphobos: Fix definition of stat_t for MIPS64 (PR103604)

Backported specific change from commit r12-6003.

libphobos/ChangeLog:

PR d/103604
* libdruntime/core/sys/posix/sys/stat.d (struct stat_t): Fix
definition for MIPS64.

(cherry picked from commit 96a09dec2421af3e201f5a54dadb35f00917ea5b)

[Bug d/103604] [12 Regression] trunk 20210506 fails to build in libphobos on mips64el-linux-gnu

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

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

--- Comment #23 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Iain Buclaw
:

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

commit r10-10354-gecd9684ec16ec0de2e4c0bb3f2097f98e6686cbe
Author: Iain Buclaw 
Date:   Tue Dec 21 14:07:37 2021 +0100

libphobos: Fix definition of stat_t for MIPS64 (PR103604)

Backported specific change from commit r12-6003.

libphobos/ChangeLog:

PR d/103604
* libdruntime/core/sys/posix/sys/stat.d (struct stat_t): Fix
definition for MIPS64.

(cherry picked from commit 96a09dec2421af3e201f5a54dadb35f00917ea5b)

[Bug d/103604] [12 Regression] trunk 20210506 fails to build in libphobos on mips64el-linux-gnu

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

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

--- Comment #22 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Iain Buclaw
:

https://gcc.gnu.org/g:96a09dec2421af3e201f5a54dadb35f00917ea5b

commit r11-9408-g96a09dec2421af3e201f5a54dadb35f00917ea5b
Author: Iain Buclaw 
Date:   Tue Dec 21 14:07:37 2021 +0100

libphobos: Fix definition of stat_t for MIPS64 (PR103604)

Backported specific change from commit r12-6003.

libphobos/ChangeLog:

PR d/103604
* libdruntime/core/sys/posix/sys/stat.d (struct stat_t): Fix
definition for MIPS64.

[Bug target/49001] GCC uses VMOVAPS/PD AVX instructions to access stack variables that are not 32-byte aligned

[thiago at kde dot org via Gcc-bugs]

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

--- Comment #7 from Thiago Macieira  ---
Hack to workaround:

asm(
".macro vmovapd args:vararg\n"
"vmovupd \\args\n"
".endm\n"
".macro vmovaps args:vararg\n"
"vmovups \\args\n"
".endm\n"
".macro vmovdqa args:vararg\n"
"vmovdqu \\args\n"
".endm\n"
".macro vmovdqa32 args:vararg\n"
"vmovdqu32 \\args\n"
".endm\n"
".macro vmovdqa64 args:vararg\n"
"vmovdqu64 \\args\n"
".endm\n"
);

See:
https://github.com/opendcdiag/opendcdiag/blob/main/framework/sysdeps/windows/win32_stdlib.h#L11-L34

[Bug fortran/103789] ICE when providing kind argument to mask{l,r}

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

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

--- Comment #1 from Mikael Morin  ---
maskr is the same.

Fix probably similar to PR87851.

[Bug fortran/103789] New: ICE when providing kind argument to mask{l,r}

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

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

Bug ID: 103789
   Summary: ICE when providing kind argument to mask{l,r}
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mikael at gcc dot gnu.org
  Target Milestone: ---

program p
   integer :: z(2), y(2)
   y = [1, 13]
   z = maskl(y, kind=4) + 1
end


test.f90:4:27:

4 |z = maskl(y, kind=4) + 1
  |   1
internal compiler error: in gfc_conv_constant, at fortran/trans-const.c:415
0x682a2a gfc_conv_constant(gfc_se*, gfc_expr*)
../../src/gcc/fortran/trans-const.c:415
0x9b83b7 gfc_conv_expr_op
../../src/gcc/fortran/trans-expr.c:3894
0x9b83b7 gfc_conv_expr(gfc_se*, gfc_expr*)
../../src/gcc/fortran/trans-expr.c:9390
0x9c52ac gfc_trans_assignment_1
../../src/gcc/fortran/trans-expr.c:11687
0x975837 trans_code
../../src/gcc/fortran/trans.c:1916
0x9a7b4f gfc_generate_function_code(gfc_namespace*)
../../src/gcc/fortran/trans-decl.c:7644
0x92223e translate_all_program_units
../../src/gcc/fortran/parse.c:6638
0x92223e gfc_parse_file()
../../src/gcc/fortran/parse.c:6925
0x9726ff gfc_be_parse_file
../../src/gcc/fortran/f95-lang.c:216

[Bug debug/103788] New: [9/10/11/12 Regression] '-fcompare-debug' failure (length) w/ -O1

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 103788
   Summary: [9/10/11/12 Regression] '-fcompare-debug' failure
(length) w/ -O1
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc 12.0.0 20211219 snapshot (g:fcbf94a5be9e0c1ecad92da773a6632b86b7f70a) fails
-fcompare-debug check when compiling the following testcase w/ -O1:

int
bar (void);

int
foo (int x)
{
  int i;

  for (i = 0; i <= __INT_MAX__; ++i)
x += bar () < (x ? 2 : 1);

  return x;
}

% gcc-12.0.0 -O1 -fcompare-debug -c ohtuq2al.c
gcc-12.0.0: error: ohtuq2al.c: '-fcompare-debug' failure (length)

--- ohtuq2al.c.gkd  2021-12-21 18:49:49.840375354 +0700
+++ ohtuq2al.gk.c.gkd   2021-12-21 18:49:49.891375611 +0700
@@ -75,7 +75,7 @@
 (expr_list:REG_UNUSED (reg:CC 17 flags)
 (nil
 (jump_insn # 0 0 3 (set (pc)
-(label_ref #)) "ohtuq2al.c":10:17# {jump}
+(label_ref #)) "ohtuq2al.c":10:5# {jump}
  (nil)
  -> 3)
 (barrier # 0 0)

[Bug target/93002] while(i--) optimization

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug target/93130] PPC simple memset not inlined

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug target/69143] PowerPC64: aggregate results are badly handled

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Blocks||101926
   Severity|normal  |enhancement


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101926
[Bug 101926] [meta-bug] struct/complex argument passing and return should be
improved

[Bug target/30354] -Os doesn't optimize a/CONST even if it saves size.

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug target/91502] suboptimal atomic_fetch_sub and atomic_fetch_add

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug target/86011] Inefficient code generated for ldivmod with constant value

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
Fixed in GCC 11:

lsrsr1, r2, #30
push{r4, lr}
orr r1, r1, r3, lsl #2
bic lr, r1, #-1073741824
bic r1, r2, #-1073741824
add r1, r1, lr
asrsr4, r3, #31
add r3, r1, r3, lsr #28
and r1, r4, #137
add r3, r3, r1
movwr1, #57025
movtr1, 13617
bic r4, r4, #75
umull   lr, r1, r1, r3
mov lr, #77
lsrsr1, r1, #4
mls r3, lr, r1, r3
movwr1, #14469
movtr1, 16171
add r3, r3, r4
str r3, [r0, #4]
subsr2, r2, r3
umull   r2, r1, r2, r1
str r2, [r0]
pop {r4, pc}

For:
#define N 7723
struct foo { long a, b; };
struct foo test(long long x)
{
return (struct foo){x / N, x % N};
}
GCC 11+ Produces:

push{r4, lr}
mov r4, r0
mov r1, r3
mov r0, r2
movsr3, #0
movwr2, #7723
bl  __aeabi_ldivmod
strdr0, r2, [r4]
mov r0, r4
pop {r4, pc}

Which is exactly what you want too.

[Bug target/92549] Use x86 xchg instruction more

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |10.0
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Andrew Pinski  ---
Fixed for -Os in GCC 10.

[Bug target/80517] [missed optimization] constant propagation through Intel intrinsics

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug target/92135] Implement popcountsi expansion for arm

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-12-21
   Severity|normal  |enhancement

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

[Bug target/87206] Suboptimal code generation for __atomic_compare_exchange_n followed by a comparison

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Last reconfirmed||2021-12-21
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
Confirmed.
Note GCC does produce better code than LLVM which produces two branches:

mov ecx, 1
xor eax, eax
lockcmpxchg dword ptr [rdi], ecx
je  .LBB0_2
# %bb.1:
testeax, eax
je  .LBB0_2
# %bb.3:
jmp bar # TAILCALL
.LBB0_2:
ret

[Bug target/82328] x86 rdrand: flags not used directly when branching on success/failure

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

--- Comment #2 from Andrew Pinski  ---
There are two issues here.
The way to fix the storing issue is to have an internal/builtin function which
returns a "complex unsigned long", the real part is for the argument and imag
part is for the original return value.

The compare issue can/should be easy to fix after that.

[Bug target/90622] Suboptimal code generated for __builtin_avr_insert_bits

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug target/88013] can't vectorize rgb to grayscale conversion code

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug target/88402] inefficient code generation for mask from CC

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-12-21
   Severity|normal  |enhancement
 Status|UNCONFIRMED |NEW

--- Comment #5 from Andrew Pinski  ---
.

[Bug rtl-optimization/63281] powerpc64le creates 64 bit constants from scratch instead of loading them

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

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

--- Comment #11 from Jiu Fu Guo  ---
While for the const which Bill said in comment9, 0x0008411
The code sequence still contains a few instructions:
e.g.
li %r11,0
ori %r11,%r11,0x8000
sldi %r11,%r11,32
oris %r11,%r11,0x410
ori %r11,%r11,0x1
std %r11,0(%r3)

[Bug tree-optimization/87601] Missed opportunity for flag reuse and macro-op fusion on x86

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2021-12-21
 Status|UNCONFIRMED |NEW
  Component|target  |tree-optimization
   Severity|normal  |enhancement
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
But IV-OPTs could have changed:
  i_19 = (int) ivtmp.8_22;
  if (i_19 != 0)
goto ; [89.00%]
  else
goto ; [11.00%]

Into:
  if (ivtmp.8_22 != 0)
goto ; [89.00%]
  else
goto ; [11.00%]

Which would have done the correct thing.

[Bug target/87601] Missed opportunity for flag reuse and macro-op fusion on x86

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

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

--- Comment #1 from Andrew Pinski  ---
sub rsi, 1
testesi, esi
jne .L3

To
sub rsi, 1
jne .L3

Is not the same, the first is a 64bit subtract followed by a 32bit compare. in
the 2nd case, you have a 64bit subtract with the 64bit compare happening.

[Bug target/87565] suboptimal memory-indirect tailcalls on arm

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug target/87548] Optimize fetch atomics with unused results

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

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

--- Comment #3 from Andrew Pinski  ---
.file   "example.cpp"
.intel_syntax noprefix
.text
.p2align 4,,15
.globl  f(int*)
.type   f(int*), @function
f(int*):
.LFB0:
.cfi_startproc
lock andDWORD PTR [rdi], 10
ret
.cfi_endproc
.LFE0:
.size   f(int*), .-f(int*)
.p2align 4,,15
.globl  f1(int*)
.type   f1(int*), @function
f1(int*):
.LFB1:
.cfi_startproc
lock andDWORD PTR [rdi], 10
ret
.cfi_endproc
.LFE1:
.size   f1(int*), .-f1(int*)
.p2align 4,,15
.globl  f2(int*)
.type   f2(int*), @function
f2(int*):
.LFB2:
.cfi_startproc
lock xorDWORD PTR [rdi], 10
ret
.cfi_endproc
.LFE2:
.size   f2(int*), .-f2(int*)
.p2align 4,,15
.globl  f12(int*)
.type   f12(int*), @function
f12(int*):
.LFB3:
.cfi_startproc
lock xorDWORD PTR [rdi], 10
ret
.cfi_endproc
.LFE3:
.size   f12(int*), .-f12(int*)
.ident  "GCC: (GCC-Explorer-Build) 4.7.1"
.section.note.GNU-stack,"",@progbits

[Bug target/87548] Optimize fetch atomics with unused results

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
This was implemented back in GCC 4.7.x when __atomic_fetch_and and
__atomic_and_fetch was added.
I get the lock and and lock xor for the following already back then:
void f (int *a)
{
__atomic_fetch_and(a, 10, 5);
}
void f1 (int *a)
{
__atomic_and_fetch(a, 10, 5);
}

void f2 (int *a)
{
__atomic_fetch_xor(a, 10, 5);
}
void f12 (int *a)
{
__atomic_xor_fetch(a, 10, 5);
}

[Bug target/87223] -Os produces sub-optimal x86 machine code for initialization with zero

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords|ra  |
   Severity|normal  |enhancement

--- Comment #2 from Andrew Pinski  ---
The trunk (for 64bit) produces:
xor eax, eax
xor edx, edx
mov BYTE PTR [rdi], 0
mov QWORD PTR [rdi+8], rax
mov WORD PTR [rdi+16], 0
mov QWORD PTR [rdi+24], rdx


Which is better but still misses out and uses two registers instead of one.

[Bug target/103785] [12 Regression] Ada bootstrap ICEs on i?86

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords|lto |

--- Comment #3 from Andrew Pinski  ---
As reported in PR 103787, PGO and LTO is not needed.