[Bug target/70894] ICE when using neon intrinsic with mabi=apcs-gnu

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

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

--- Comment #2 from Andrew Pinski  ---
This specific builtin was removed in GCC 12 by r12-2848.

But here is a testcase which still ICEs on the trunk:
typedef __simd64_int8_t int8x8_t;

int8x8_t
g (signed char __a, int8x8_t __b, const int __c)
{
  return (int8x8_t)__builtin_neon_vset_lanev8qi ((__builtin_neon_qi) __a, __b,
__c);
}

The problem is obvious the char (QImode) argument gets prompoted to int
(SImode) and copy_to_mode_reg is used without the change of the mode back down
to QImode.

[Bug rtl-optimization/103830] New: volatile optimized away

[bernd.edlinger at hotmail dot de via Gcc-bugs]

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

Bug ID: 103830
   Summary: volatile optimized away
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bernd.edlinger at hotmail dot de
  Target Milestone: ---

the following test case is intentionally writing at address 0,
it is IMHO invalid to optimize it away (at -Og):

$ cat empty-inline.cc
/* This testcase is part of GDB, the GNU debugger.

   Copyright 2021 Free Software Foundation, Inc.

   This program is free software; you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by
   the Free Software Foundation; either version 3 of the License, or
   (at your option) any later version.

   This program is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
   GNU General Public License for more details.

   You should have received a copy of the GNU General Public License
   along with this program.  If not, see .  */

/* PR 25987 */
struct MyClass;
struct ptr {
MyClass* get() { return t; } /* line 21 */
MyClass* t;
};
struct MyClass { void call(); };
void MyClass::call() {
*(volatile char*)(nullptr) = 1;  /* line 26 */
}
static void intermediate(ptr p) {
p.get()->call(); /* line 29 */
}
int main() {
intermediate(ptr{new MyClass});
}
/* EOF */

previously this used to SIGSEGV in line 26, but no longer with
git master from December 18th at least.
I think it is rather common to have something at address zero,
for instance interrupt tables or device registers,
and therefore it's not OK to optimize those volatile accesses away.

[Bug c++/103653] GCC rejected int x = 0; auto(x); in C++23

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

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

--- Comment #4 from Jonathan Wakely  ---
Yes this changed in C++23 so auto(X) creates an rvalue of the decayed type of
x.

[Bug rtl-optimization/103830] volatile optimized away

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

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

--- Comment #1 from Andrew Pinski  ---
> I think it is rather common to have something at address zero,
> for instance interrupt tables or device registers,
> and therefore it's not OK to optimize those volatile accesses away.
-fno-delete-null-pointer-checks is designed for that use case.

[Bug c++/39385] ICE in gen_type_die_with_usage

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Fixed a long time ago.

[Bug d/103728] Allow to run unittests before main()

[pierrick.bouvier at posteo dot net via Gcc-bugs]

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

--- Comment #4 from Pierrick Bouvier  ---
Thanks for your suggestion.

We will follow this to upgrade our compiler.

[Bug d/103728] Allow to run unittests before main()

[pierrick.bouvier at posteo dot net via Gcc-bugs]

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

Pierrick Bouvier  changed:

   What|Removed |Added

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

--- Comment #5 from Pierrick Bouvier  ---
gdc does not have to support this use case, since it is related to D runtime.

[Bug ipa/103830] [12 Regression] null pointer access optimized away by removing function call at -Og

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|rtl-optimization|ipa
   Last reconfirmed||2021-12-26
   Target Milestone|--- |12.0
Summary|volatile optimized away |[12 Regression] null
   ||pointer access optimized
   ||away by removing function
   ||call at -Og
 Status|UNCONFIRMED |NEW
 CC||hubicka at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org,
   ||pinskia at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
What was removed is not the null pointer itself but rather the function calls
to both MyClass::call and intermediate.


cddce:
Eliminating unnecessary statements:
Deleting : MyClass::call (_4);


Eliminating unnecessary statements:
Deleting : intermediate (D.2427);


>From local-const-pure:

 local analysis of void MyClass::call()/1
   NULL memory access; terminating BB
checking previously known:
void MyClass::call()/1 is not a malloc candidate, reason: No return value.
Function is locally const.



The question is do we want to do const-pure at -Og really.

>it is IMHO invalid to optimize it away (at -Og):

No, it is valid to remove as it is undefined behavior, the question comes do we
want to do the removal at -Og; I suspect no.

[Bug fortran/83078] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1110

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

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

--- Comment #3 from Andrew Pinski  ---
The trunk gives:
/app/example.f90:7:20:

7 |type(t) :: x = t([1, 2])
  |1
Error: Bad array spec of component 'a' referenced in structure constructor at
(1)

[Bug fortran/83078] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1110

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||10.3.1, 11.2.1
 Status|NEW |RESOLVED
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=102816
   Target Milestone|--- |10.4
 Resolution|--- |FIXED

--- Comment #4 from Andrew Pinski  ---
Fixed by the patch which fixed PR 102816. So this means it is fixed for GCC
10.4.0, 11.3.0 and GCC 12.

[Bug c/100501] [9/10/11/12 Regression] ICE with inline-asm and void statement expression

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||4.1.2
Summary|ICE with inline-asm and |[9/10/11/12 Regression] ICE
   |void statement expression   |with inline-asm and void
   ||statement expression
  Known to fail||4.4.7
   Keywords||ice-on-invalid-code
   Target Milestone|--- |9.5

--- Comment #7 from Andrew Pinski  ---
4.1.2 used to error out:
:3: error: memory input 0 is not directly addressable

[Bug c/100792] ICE: gimplify_expr, at gimplify.c:14879

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-checking
  Known to fail||10.1.0, 11.1.0, 12.0, 9.1.0
   Severity|normal  |trivial

--- Comment #3 from Andrew Pinski  ---
Confirmed, this only ICEs with checking enable.

[Bug c/100792] ICE: gimplify_expr, at gimplify.c:14879

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

[Bug libfortran/98076] Increase speed of integer I/O

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

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

--- Comment #9 from Francois-Xavier Coudert  ---
After my patch, measurements seem to indicate the output of integers is mostly
bound the library overhead. Inspection of the various itoa/btoa/otoa/xtoa
functions seems to show they're reasonably efficient.

Reading of integers is still quite inefficient. The function read_decimal()
always works with the largest integer kind, performing additions and
multiplications by 10. This is, I think, available in hardware (not library
call).

read_radix() is probably also quite inefficient. It is written in a completely
generic fashion, although it operates on fixed radices (2, 8 or 16); such
multiplications could be done by bit shift. Even if we told the compilers that
the radix was 2, 8 or 16 in each case (three functions), it would optimise the
multiplications into bit shifts itself.

[Bug libstdc++/103831] New: views::lazy_split accepts Pattern as span when V is input_range

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 103831
   Summary: views::lazy_split accepts Pattern as span when
V is input_range
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

This is an extremely strange case that I suspect is a language bug, consider:

  #include 
  #include 
  #include 
  #include 
  int main() {
auto ints = std::istringstream{"42"};
auto r = std::ranges::istream_view(ints);
std::array arr{42};
std::span p{arr};
std::ranges::lazy_split_view s(r, p);
  }

https://godbolt.org/z/o9EY9oPx6

In the above example, lazy_split_view should be rejected.
According to [range.lazy.split.view], when V does not model forward_range,
Pattern must be a tiny_range, however, span does not model tiny_range
since it does not have a static size function, so lazy_split_view should be
ill-formed. 
I really don’t know why it will still be accepted.

[Bug c++/103832] New: vectorized code segfaults due to misaligned access

[joakim.rosqvist at gmail dot com via Gcc-bugs]

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

Bug ID: 103832
   Summary: vectorized code segfaults due to misaligned access
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joakim.rosqvist at gmail dot com
  Target Milestone: ---

Created attachment 52059
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52059&action=edit
preprocessed version of source file optim.cc

The attached code, which adds up values in an array, crashes due to a
misaligned memory access. The array is properly aligned at index 0, but the sum
starts at index 1 and so I expected the optimizer to either not vectorize the
loop or to add up the first few elements separately and vectorize the sum from
the first "aligned" index. 

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

System used is Ubuntu 21.10 on an AMD Ryzen 3700X cpu.

Commandline used to compile, which gives no output:
>g++ -O -Wall -Wextra -ftree-loop-vectorize -fno-strict-aliasing -fwrapv 
>-fno-aggressive-loop-optimizations -fsanitize=undefined -save-temps -o optim 
>optim.cc

Commandline to trigger the issue with output
>./optim
optim.cc:12:15: runtime error: load of misaligned address 0x564849975f04 for
type 'aligned_float', which requires 64 byte alignment
0x564849975f04: note: pointer points here
  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00
00 00 00 00 00 00 00
  ^

[Bug c++/103832] vectorized code segfaults due to misaligned access

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
You are using the attribute aligned incorrectly.


aligned_float *data = static_cast(aligned_alloc(64,
8192*sizeof(float)));

float sum = 0.0f;
for (int i=1; i<8192; i++)
  sum += data[i];


You are saying data+i are all 64byte aligned which is obviously not correct.
If you want to say data+0 is aligned at a 64byte boundary you should use
instead __builtin_assume_aligned .


https://gcc.gnu.org/onlinedocs/gcc-11.2.0/gcc/Other-Builtins.html#index-_005f_005fbuiltin_005fassume_005faligned

[Bug middle-end/47033] loop distribution has problems on sane testcases

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=43884,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=45948,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=44334
   Target Milestone|--- |4.6.0

--- Comment #5 from Andrew Pinski  ---
(In reply to Jan Hubicka from comment #0)
> The following patch:

Which was committed as r0-106204 with the change of the testcase too but not
the number of memset's so I assume the problem reported here was fixed.


Note r8-18 removed the undefined behavior from the testcase and updated the
testcase, as PRE is able to remove one of the stores even.

[Bug c++/103833] New: Overloaded static member function cannot be resolved unlike overloaded global function

[fchelnokov at gmail dot com via Gcc-bugs]

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

Bug ID: 103833
   Summary: Overloaded static member function cannot be resolved
unlike overloaded global function
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fchelnokov at gmail dot com
  Target Milestone: ---

In the following code:
```
void g(int) {}
void g(double) {}

struct A {
static void m(int) {}
static void m(double) {}
};

int main() {
   (&g)(0);//ok
   (&A::m)(0); //error in GCC and Clang
}
```
the resolution of overloaded global function `g` goes fine, but as to similar
static member function `A::m` the overload resolution fails, which looks wrong. 

MSVC has not problem with either case. Demo:
https://gcc.godbolt.org/z/585e5Gc4b

Related discussion: https://stackoverflow.com/q/68947849/7325599

[Bug rtl-optimization/49148] Certain expressions take an extremely long time for no apparent reason

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #8 from Andrew Pinski  ---
(In reply to John Peyton from comment #7)
> > Try -ffast-math (the default for ICC) which disables subnormals.
> 
> Thanks, this helped it run much faster!

Yes so you confirm this is a subnormal issue.

> 
> Could this also be related to subnormal numbers, or is this just a different
> issue?

Different issue related to /4.0 can be done as *0.25 but I think that might be
solved in newer versions of GCC; I didn't try.

[Bug c++/103833] Overloaded static member function cannot be resolved unlike overloaded global function

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug middle-end/47990] Missed promotion of double precision constants to single precision for -funsafe-math-optimizations

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

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

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

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

--- Comment #12 from CVS Commits  ---
The master branch has been updated by H.J. Lu :

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

commit r12-6118-gd87483015d476a95f521f0c9dcf6988ca889063b
Author: H.J. Lu 
Date:   Fri Dec 24 12:50:21 2021 -0800

i386: Check AX input in any_mul_highpart peepholes

When applying peephole optimization to transform

mov imm, %reg0
mov %reg1, %AX_REG
imul %reg0

to

mov imm, %AX_REG
imul %reg1

disable peephole optimization if reg1 == AX_REG.

gcc/

PR target/103785
* config/i386/i386.md: Swap operand order in comments and check
AX input in any_mul_highpart peepholes.

gcc/testsuite/

PR target/103785
* gcc.target/i386/pr103785.c: New test.

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

[hjl.tools at gmail dot com via Gcc-bugs]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #13 from H.J. Lu  ---
Fixed.

[Bug rtl-optimization/103834] New: ICE: qsort comparator non-negative on sorted output: 1 with custom flags

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 103834
   Summary: ICE: qsort comparator non-negative on sorted output: 1
with custom flags
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

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

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O2 -fno-guess-branch-probability
-fharden-conditional-branches -fno-sched-critical-path-heuristic -fno-peephole2
-fsched2-use-superblocks testcase.C 
testcase.C: In member function 'virtual void C::_ZThn8_N1C3fooEi(int)':
testcase.C:15:16: error: qsort comparator non-negative on sorted output: 1
   15 |   virtual void foo (int);
  |^~~
during RTL pass: sched2
testcase.C:15:16: internal compiler error: qsort checking failed
0xdd17db qsort_chk_error
/repo/gcc-trunk/gcc/vec.c:204
0xdd18ed qsort_chk(void*, unsigned long, unsigned long, int (*)(void const*,
void const*, void*), void*)
/repo/gcc-trunk/gcc/vec.c:246
0x27f18d5 gcc_qsort(void*, unsigned long, unsigned long, int (*)(void const*,
void const*))
/repo/gcc-trunk/gcc/sort.cc:270
0x2605888 ready_sort_real
/repo/gcc-trunk/gcc/haifa-sched.c:3095
0x260dfb4 ready_sort
/repo/gcc-trunk/gcc/haifa-sched.c:3111
0x260dfb4 schedule_block(basic_block_def**, void*)
/repo/gcc-trunk/gcc/haifa-sched.c:6718
0x26e5f1b schedule_ebb(rtx_insn*, rtx_insn*, bool)
/repo/gcc-trunk/gcc/sched-ebb.c:536
0x26e6642 schedule_ebbs()
/repo/gcc-trunk/gcc/sched-ebb.c:655
0x15faf6c rest_of_handle_sched2
/repo/gcc-trunk/gcc/sched-rgn.c:3740
0x15faf6c execute
/repo/gcc-trunk/gcc/sched-rgn.c:3878
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r12-6113-20211224170936-g8f921393e33-checking-yes-rtl-df-extra-nobootstrap-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
--disable-bootstrap --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-6113-20211224170936-g8f921393e33-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.0 20211224 (experimental) (GCC)

[Bug libstdc++/103831] views::lazy_split accepts Pattern as span when V is input_range

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

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

Patrick Palka  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
   Last reconfirmed||2021-12-26
 CC||ppalka at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Patrick Palka  ---
Interestingly, adding the (correct and passing) assert

  static_assert(!std::ranges::__detail::__tiny_range);

before the last line causes us to reject the last line with

  /home/patrick/code/gcc/libstdc++-v3/include/std/ranges:2953:12: error:
satisfaction value of atomic constraint
‘requires{std::ranges::__detail::__require_constant<(std::remove_reference<_Tp>::type::size)()>;}
[with _Range = std::span]’ changed from ‘false’ to ‘true’


Looks like this is indeed a frontend bug, which can be distilled into the
testcase

struct A {
  constexpr int size() { return 42; }
};

template
struct B : T {
  static_assert(A::size() == 42);
};

We incorrectly accept the non-dependent call A::size() here even though it's
being performed from a context where there is no 'this' object.

[Bug c/103835] New: Bogus sprintf warnings

[lavr at ncbi dot nlm.nih.gov via Gcc-bugs]

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

Bug ID: 103835
   Summary: Bogus sprintf warnings
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lavr at ncbi dot nlm.nih.gov
  Target Milestone: ---

Please address these warnings because they create more noise than they help!

$ cat test.c
#include 
#include 
#include 


const char* fun(char* buf, const char* pfx, int a, int b)
{
sprintf(buf, "%sa = %d\n"
 "%sb = %d\n",
 pfx, a, pfx, b);
return buf;
}


int main(int argc, char* argv[])
{
char buf[500];
const char* str;
strcpy(buf, "\t");
str = fun(buf + strlen(buf) + 1, buf, atoi(argv[1]), atoi(argv[2]));
printf("%s\n", str);
return 0;
}

$ gcc --version
gcc (GCC) 11.2.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ gcc -Wall -O6 test.c
test.c: In function ‘main’:
test.c:8:21: warning: ‘a = ’ directive writing 4 bytes into a region of size
between 0 and 499 [-Wformat-overflow=]
8 | sprintf(buf, "%sa = %d\n"
  | ^~~~
test.c:8:5: note: ‘sprintf’ output between 13 and 1031 bytes into a destination
of size 499
8 | sprintf(buf, "%sa = %d\n"
  | ^
9 |  "%sb = %d\n",
  |  ~
   10 |  pfx, a, pfx, b);
  |  ~~~
test.c:8:5: warning: ‘sprintf’ arguments 3, 5 may overlap destination object
‘buf’ [-Wrestrict]
test.c:17:10: note: destination object referenced by ‘restrict’-qualified
argument 1 was declared here
   17 | char buf[500];
  |  ^~~

It's clear that the destination buffer will NOT overlap with anything related
to "pfx" in the fun() function.  Is also clear that output will NOT contain
that many characters that the warning claims (up to 1031).  If GCC can't
estimate the length for sure, it's better NOT to emit any warnings, rather than
printing this annoying noise.

Please be mindful of your users -- and their time to re-analyze the code that
suddenly is now flagged with these senseless warnings, only to realize that
it's all red herring.

Thank you

[Bug debug/103836] New: '-fcompare-debug' failure (length) w/ -fopenacc --param openacc-kernels=decompose

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 103836
   Summary: '-fcompare-debug' failure (length) w/ -fopenacc
--param openacc-kernels=decompose
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: openacc
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

Created attachment 52061
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52061&action=edit
diff -u o5cia6mf.*.gkd

g++ 12.0.0 20211219 snapshot (g:fcbf94a5be9e0c1ecad92da773a6632b86b7f70a) fails
-fcompare-debug check when compiling the following testcase w/, extracted from
gcc/testsuite/c-c++-common/goacc/nesting-1.c, w/ -fopenacc --param
openacc-kernels=decompose:

extern int i;

void
f_acc_kernels (void)
{
#pragma acc kernels
  {
#pragma acc loop
for (i = 0; i < 2; ++i)
  ;
  }
}

% x86_64-unknown-linux-gnu-g++-12.0.0 -O1 -fcompare-debug -fopenacc --param
openacc-kernels=decompose -c o5cia6mf.c
x86_64-unknown-linux-gnu-g++-12.0.0: error: o5cia6mf.c: '-fcompare-debug'
failure (length)

Diff between two gkd files attached. I can reproduce the issue only w/ C++
front-end.

[Bug c++/103831] non-dependent call to non-static member function not rejected ahead of time when there are dependent bases and no 'this'

[hewillk at gmail dot com via Gcc-bugs]

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

--- Comment #2 from 康桓瑋  ---
Please let me add a digression, is the standard overconstrained the definition
of tiny_range? 
In the current standard, it seems that only single_view and empty_view satisfy
tiny_range. However, std::array and span or even int[1], in my
opinion, should be valid Pattern types when V is an input_range, because we can
directly extract their size from the type, but none of the three have a static
size() function. This also means that the constructor lazy_split_view(R&&, P&&)
has an *extremely* limited set of P when R is an input_range.

[Bug debug/103837] New: [12 Regression] '-fcompare-debug' failure (length) w/ -Og -fmove-loop-invariants -fnon-call-exceptions -fno-tree-dce

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 103837
   Summary: [12 Regression] '-fcompare-debug' failure (length) w/
-Og -fmove-loop-invariants -fnon-call-exceptions
-fno-tree-dce
   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: ---
Target: x86_64-unknown-linux-gnu

gcc 12.0.0 20211219 snapshot (g:fcbf94a5be9e0c1ecad92da773a6632b86b7f70a) fails
-fcompare-debug check when compiling the following testcase w/ -Og
-fmove-loop-invariants -fnon-call-exceptions -fno-tree-dce:

unsigned long int
foo (int x)
{
  double a;
  int b;
  unsigned long int ret = a;

  for (;;)
{
  b = !!((int) a);
  a = x;
}

  return ret;
}

% x86_64-unknown-linux-gnu-gcc-12.0.0 -Og -fcompare-debug
-fmove-loop-invariants -fnon-call-exceptions -fno-tree-dce -c dbvufwcn.c
x86_64-unknown-linux-gnu-gcc-12.0.0: error: dbvufwcn.c: '-fcompare-debug'
failure (length)

--- dbvufwcn.c.gkd  2021-12-26 23:40:50.743359823 +0700
+++ dbvufwcn.gk.c.gkd   2021-12-26 23:40:50.794356341 +0700
@@ -17,16 +17,6 @@
  (expr_list:REG_DEAD (reg/v:DF 20 xmm0 [orig:84 a ] [84])
 (expr_list:REG_UNUSED (reg:CCFP 17 flags)
 (nil
-(insn # 0 0 2 (set (reg:V2DF 20 xmm0 [orig:84 a ] [84])
-(const_vector:V2DF [
-(const_double:DF 0.0 [0x0.0p+0]) repeated x2
-])) "dbvufwcn.c":11:9# {movv2df_internal}
- (nil))
-(insn # 0 0 2 (set (reg:V2DF 20 xmm0 [orig:84 a ] [84])
-(vec_merge:V2DF (vec_duplicate:V2DF (float:DF (reg:SI 5 di [94])))
-(reg:V2DF 20 xmm0 [orig:84 a ] [84])
-(const_int 1 [0x1]))) "dbvufwcn.c":11:9# {sse2_cvtsi2sd}
- (nil))
 (code_label # 0 0 3 4 (nil) [1 uses])
 (note # 0 0 [bb 3] NOTE_INSN_BASIC_BLOCK)
 (jump_insn # 0 0 3 (set (pc)

[Bug fortran/103828] Type generated for CHARACTER(C_CHAR), VALUE arguments is wrong

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

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

--- Comment #2 from Francois-Xavier Coudert  ---
So, even modifying gfc_sym_type() in trans-types.c to emit the proper type does
not fix the issue. Why? Because the rug is pulled under our feet later. Turns
out there is a function that deals with this, much later in the front-end:
gfc_conv_scalar_char_value()

But that function is really wrong. It's called in generate_local_decl(), which
says:

   /* Modify the tree type for scalar character dummy arguments of bind(c)
 procedures if they are passed by value.  The tree type for them will
 be promoted to INTEGER_TYPE for the middle end, which appears to be
 what C would do with characters passed by-value.  The value attribute
 implies the dummy is a scalar.  */

and gfc_conv_scalar_char_value() does this:

   /* This becomes the nominal_type in
 function.c:assign_parm_find_data_types.  */
   TREE_TYPE (sym->backend_decl) = unsigned_char_type_node;
   /* This becomes the passed_type in
 function.c:assign_parm_find_data_types.  C promotes char to
 integer for argument passing.  */
   DECL_ARG_TYPE (sym->backend_decl) = unsigned_type_node;

But this is completely wrong. In C, `char` arguments are only promoted to `int`
when the destination type is unknown, i.e., in unprototyped functions (K&R
style) or variadic arguments. C interoperability only interoperates with
prototyped C functions, so this promotion should not happen, and `char` should
be passed as `char`!

I am attaching the patch under testing.

[Bug fortran/103828] Type generated for CHARACTER(C_CHAR), VALUE arguments is wrong

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

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

--- Comment #3 from Francois-Xavier Coudert  ---
Created attachment 52062
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52062&action=edit
Patch, v1

[Bug debug/103838] New: [11/12 Regression] '-fcompare-debug' failure (length) w/ -O2 --param max-early-inliner-iterations=0 --param max-inline-insns-auto=2

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 103838
   Summary: [11/12 Regression] '-fcompare-debug' failure (length)
w/ -O2 --param max-early-inliner-iterations=0 --param
max-inline-insns-auto=2
   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: ---
Target: x86_64-unknown-linux-gnu

Created attachment 52063
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52063&action=edit
diff -u uarspwmr.*.gkd

gcc 12.0.0 20211219 snapshot (g:fcbf94a5be9e0c1ecad92da773a6632b86b7f70a) fails
-fcompare-debug check when compiling the following testcase w/ -O2 --param
max-early-inliner-iterations=0 --param max-inline-insns-auto=2:

__int128 m;
int n;

void
bar (void)
{
  n += !!m;
}

void
foo (void)
{
  int i;

  for (i = 0; i < 2; ++i)
{
  bar ();
  m /= 3;
}
}

% x86_64-unknown-linux-gnu-gcc-12.0.0 -O2 -fcompare-debug --param
max-early-inliner-iterations=0 --param max-inline-insns-auto=2 -c uarspwmr.c
x86_64-unknown-linux-gnu-gcc-12.0.0: error: uarspwmr.c: '-fcompare-debug'
failure (length)

Diff between two gkd files attached.

[Bug fortran/103828] Type generated for CHARACTER(C_CHAR), VALUE arguments is wrong

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

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

--- Comment #4 from Francois-Xavier Coudert  ---
Wait, there is more, lower in gfc_conv_scalar_char_value():

  /* If we have a constant character expression, make it into an
 integer.  */
  if ((*expr)->expr_type == EXPR_CONSTANT)
{
  gfc_typespec ts;
  gfc_clear_ts (&ts);

  *expr = gfc_get_int_expr (gfc_default_character_kind, NULL,
(*expr)->value.character.string[0]);
  if ((*expr)->ts.kind != gfc_c_int_kind)
{
  /* The expr needs to be compatible with a C int.  If the
 conversion fails, then the 2 causes an ICE.  */
  ts.type = BT_INTEGER;
  ts.kind = gfc_c_int_kind;
  gfc_convert_type (*expr, &ts, 2);
}
}

And… we're forcing it into a C int. Again. The commit that introduced this
function is:

+2007-08-06  Christopher D. Rickett  
+
+   PR fortran/32732
+   * trans-expr.c (gfc_conv_scalar_char_value): Convert the tree and
+   actual arg expressions for scalar characters passed by-value to
+   bind(c) routines.
+   (gfc_conv_function_call): Call gfc_conv_scalar_char_value.
+   * trans.h: Add prototype for gfc_conv_scalar_char_value.
+   * trans-decl.c (generate_local_decl): Convert by-value character
+   dummy args of bind(c) procedures using
+   gfc_conv_scalar_char_value.

It's interesting to note that, at the time, the testcase was failing on IA64
HP-UX, although the bug was still marked as fixed.

[Bug fortran/32732] [Bind C] Character scalars are passed as arrays

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

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu.org

--- Comment #7 from Francois-Xavier Coudert  ---
I think the problem never really went away, but it was simply not seen on most
targets. It has reappeared on aarch64-darwin, and was painful to chase down:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103828

[Bug middle-end/103839] New: __builtin_clear_padding doesn't zero alignment holes of unions with fields that overlap padding

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

Bug ID: 103839
   Summary: __builtin_clear_padding doesn't zero alignment holes
of unions with fields that overlap padding
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ibuclaw at gdcproject dot org
  Target Milestone: ---

Consider:

---
// { dg-additional-options "-ftrivial-auto-var-init=zero" }
union U
{
  struct { char a; int b; } c;
  int d;
};

int main()
{
  U u[2] = {{1, 2}, {3, 4}};
}
---

Because of `int d`, the three byte padding that would be required to fill the
gap between the two struct fields is ignored.

So after gimple lowering, we are left with:
---
  u[0].c.a = 1;
  u[0].c.b = 2;
  u[1].c.a = 3;
  u[1].c.b = 4;
  GIMPLE_NOP
---

Instead of the expected:
---
  u[0].c.a = 1;
  u[0].c.b = 2;
  u[1].c.a = 3;
  u[1].c.b = 4;
  MEM  [(union U[2] *)&a + 1B] = {};
  MEM  [(union U[2] *)&a + 9B] = {};
---

And inspecting the data in gdb, we visibly have garbage in the object.
---
(gdb) p u
$1 = {{c = {a = 1 '\001', b = 2}, d = 1025}, {c = {a = 3 '\003', b = 4}, d =
4355}}
---

I can work around this by setting DECL_PADDING_P on all fields in unions except
the first.  However I suspect this is a mistake, and the proper thing to do
would be to only consider the first field when clear padding a union.

[Bug middle-end/103839] __builtin_clear_padding doesn't zero alignment holes of unions with fields that overlap padding

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

--- Comment #1 from Iain Buclaw  ---
(In reply to Iain Buclaw from comment #0)
> I can work around this by setting DECL_PADDING_P on all fields in unions
> except the first.  However I suspect this is a mistake, and the proper thing
> to do would be to only consider the first field when clear padding a union.
The fix to do this being a one-liner in gimple-fold.c

diff --git a/gcc/gimple-fold.c b/gcc/gimple-fold.c
index 64515aabc04..9426e9ca473 100644
--- a/gcc/gimple-fold.c
+++ b/gcc/gimple-fold.c
@@ -4537,6 +4537,7 @@ clear_padding_union (clear_padding_struct *buf, tree
type,
clear_padding_type (union_buf, TREE_TYPE (field), fldsz,
for_auto_init);
clear_padding_add_padding (union_buf, sz - fldsz);
clear_padding_flush (union_buf, true);
+   break;
   }

   if (buf == union_buf)

[Bug middle-end/103839] __builtin_clear_padding doesn't zero alignment holes of unions with fields that overlap padding

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

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

--- Comment #2 from Jakub Jelinek  ---
For __builtin_clear_padding builtin, that behavior is completely intentional,
for unions the compiler most of the time doesn't know which union member is
currently active, so it acts conservatively, only clears bits that are padding
bits in all union members rather than some of them.
For the internal uses of the __builtin_clear_padding code we'd need some way
how to tell the code which union member is the currently active one so that it
could work differently.

[Bug testsuite/103823] g++.dg/torture/pr31863.C fails on darwin with "using serial compilation of 2 LTRANS jobs"

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

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

--- Comment #7 from Francois-Xavier Coudert  ---
Did not work: I think it's because it's lto-wrapper not lto1.

Executing on host: /private/tmp/ibin/gcc/testsuite/g++/../../xg++
-B/private/tmp/ibin/gcc/testsuite/g++/../../  /tmp/gcc-darwin-arm6
4/gcc/testsuite/g++.dg/torture/pr31863.C-fdiagnostics-plain-output 
-nostdinc++ -I/tmp/ibin/aarch64-apple-darwin21.2.0/libstdc++
-v3/include/aarch64-apple-darwin21.2.0
-I/tmp/ibin/aarch64-apple-darwin21.2.0/libstdc++-v3/include
-I/tmp/gcc-darwin-arm64/libstdc++
-v3/libsupc++ -I/tmp/gcc-darwin-arm64/libstdc++-v3/include/backward
-I/tmp/gcc-darwin-arm64/libstdc++-v3/testsuite/util -fmessage-le
ngth=0   -O2 -flto 
-L/private/tmp/ibin/aarch64-apple-darwin21.2.0/./libstdc++-v3/src/.libs 
-B/private/tmp/ibin/aarch64-apple-d
arwin21.2.0/./libstdc++-v3/src/.libs 
-L/private/tmp/ibin/aarch64-apple-darwin21.2.0/./libstdc++-v3/src/.libs
-B/private/tmp/ibin/aa
rch64-apple-darwin21.2.0/./libitm/
-L/private/tmp/ibin/aarch64-apple-darwin21.2.0/./libitm/.libs -multiply_defined
suppress -lm  -o 
pr31863.exe(timeout = 600)
spawn -ignore SIGHUP /private/tmp/ibin/gcc/testsuite/g++/../../xg++
-B/private/tmp/ibin/gcc/testsuite/g++/../../ /tmp/gcc-darwin-arm
64/gcc/testsuite/g++.dg/torture/pr31863.C -fdiagnostics-plain-output
-nostdinc++ -I/tmp/ibin/aarch64-apple-darwin21.2.0/libstdc++-v3
/include/aarch64-apple-darwin21.2.0
-I/tmp/ibin/aarch64-apple-darwin21.2.0/libstdc++-v3/include
-I/tmp/gcc-darwin-arm64/libstdc++-v3
/libsupc++ -I/tmp/gcc-darwin-arm64/libstdc++-v3/include/backward
-I/tmp/gcc-darwin-arm64/libstdc++-v3/testsuite/util -fmessage-lengt
h=0 -O2 -flto
-L/private/tmp/ibin/aarch64-apple-darwin21.2.0/./libstdc++-v3/src/.libs
-B/private/tmp/ibin/aarch64-apple-darwin21.2.0
/./libstdc++-v3/src/.libs
-L/private/tmp/ibin/aarch64-apple-darwin21.2.0/./libstdc++-v3/src/.libs
-B/private/tmp/ibin/aarch64-apple-
darwin21.2.0/./libitm/
-L/private/tmp/ibin/aarch64-apple-darwin21.2.0/./libitm/.libs -multiply_defined
suppress -lm -o pr31863.exe
lto-wrapper: warning: using serial compilation of 2 LTRANS jobs
lto-wrapper: note: see the
ESC]8;;https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-flto^G'-flto'
option documentation
ESC]8;;^G for more information
FAIL: g++.dg/torture/pr31863.C   -O2 -flto  (test for excess errors)
Excess errors:
lto-wrapper: warning: using serial compilation of 2 LTRANS jobs


I am attaching a slightly amended version, accepting stuff after "lto", which
passes.

[Bug testsuite/103823] g++.dg/torture/pr31863.C fails on darwin with "using serial compilation of 2 LTRANS jobs"

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

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

--- Comment #8 from Francois-Xavier Coudert  ---
Created attachment 52064
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52064&action=edit
Revised patch

[Bug fortran/103828] Type generated for CHARACTER(C_CHAR), VALUE arguments is wrong

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

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

   Keywords||patch
URL||https://gcc.gnu.org/piperma
   ||il/fortran/2021-December/05
   ||7226.html

--- Comment #5 from Francois-Xavier Coudert  ---
Patch posted: https://gcc.gnu.org/pipermail/fortran/2021-December/057226.html

[Bug middle-end/103839] __builtin_clear_padding doesn't zero alignment holes of unions with fields that overlap padding

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

--- Comment #3 from Iain Buclaw  ---
(In reply to Jakub Jelinek from comment #2)
> For __builtin_clear_padding builtin, that behavior is completely
> intentional, for unions the compiler most of the time doesn't know which
> union member is currently active, so it acts conservatively, only clears
> bits that are padding bits in all union members rather than some of them.
> For the internal uses of the __builtin_clear_padding code we'd need some way
> how to tell the code which union member is the currently active one so that
> it could work differently.
OK, poking around in another language, I certainly understand this considering
that C++ allows some more contrived cases.

union U
{
struct { char a; int b; } c;
struct { int d; char e; } f;
};
U u = { .f={1, 2} };

D certainly only considers the first field to be the definitive shape of the
object, so it's not possible to initialize it in a constructor like the above.

I'll just go ahead with DECL_PADDING_P for now, as I can't see any downsides
just yet on doing so.

[Bug tree-optimization/103835] Bogus sprintf warnings

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2021-12-26
   Keywords||diagnostic,
   ||missed-optimization
 Ever confirmed|0   |1
  Component|c   |tree-optimization
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
Looks like atoi is not know and GCC thinks atoi will write into buf.
But that does not fix the restrict warning which does not use string length
analysis to figure out it does not overlap.

Confirmed.

[Bug testsuite/103823] g++.dg/torture/pr31863.C fails on darwin with "using serial compilation of 2 LTRANS jobs"

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

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

--- Comment #9 from Andrew Pinski  ---
(In reply to Francois-Xavier Coudert from comment #8)
> Created attachment 52064 [details]
> Revised patch

Can you submit this? But it looks correct. And thanks for correcting my patch.

[Bug debug/103838] [11/12 Regression] '-fcompare-debug' failure (length) w/ -O2 --param max-early-inliner-iterations=0 --param max-inline-insns-auto=2

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code,
   ||needs-bisection
   Target Milestone|--- |11.3

[Bug debug/103837] [12 Regression] '-fcompare-debug' failure (length) w/ -Og -fmove-loop-invariants -fnon-call-exceptions -fno-tree-dce

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Target Milestone|--- |12.0

[Bug tree-optimization/61818] unused code fails to be removed after dom1, thread updated

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||7.1.0
 Resolution|--- |FIXED
  Known to fail||5.1.0, 6.1.0
   Target Milestone|--- |7.0

--- Comment #2 from Andrew Pinski  ---
Fixed in GCC 7.

What was missing was not optimizing:
  ppnode.1_5 = &_15->m_next;
  if (&n == ppnode.1_5)

Even though n never escaped.

[Bug target/33717] slow code generated for 64-bit arithmetic

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

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

--- Comment #5 from Andrew Pinski  ---
#include 
#include 

#define rdtscl(low) \
 __asm__ __volatile__ ("rdtsc" : "=a" (low) : : "edx")

int main() {
  unsigned int x[100];
  unsigned int y[100];
  unsigned int z[100];

  long a,b,c;
  size_t i;

  unsigned long long l;

  for (i=0; i<100; ++i) {
x[i]=0; y[i]=-1;
z[i]=0;
  }
  x[0]=1;
  rdtscl(a);
  l=0;
  for (i=0; i<100; ++i) {
l += (unsigned long long)x[i] + y[i];
z[i]=l;
l>>=32;
  }
  rdtscl(b);
  printf("C: %ld cycles\n",b-a);

  for (i=0; i<100; ++i)
assert(z[i]==0);
  assert(l==1);

  rdtscl(a);
  asm volatile(
"mov (%%esi,%%ecx),%%eax\n"
"add (%%edi,%%ecx),%%eax\n"
"mov %%eax,(%%ebx,%%ecx)\n"
"1:\n"
"lea 4(%%ecx),%%ecx\n"
"jecxz 1f\n"
"mov (%%esi,%%ecx),%%eax\n"
"adc (%%edi,%%ecx),%%eax\n"
"mov %%eax,(%%ebx,%%ecx)\n"
"jmp 1b\n"
"1:\n"
: : "S" (x+100), "D" (y+100), "b" (z+100), "c" (-400) : "eax" );

  rdtscl(b);
  printf("asm: %ld cycles\n",b-a);

  for (i=0; i<100; ++i)
assert(z[i]==0);
  assert(l==1);

}

[Bug target/33717] slow code generated for 64-bit arithmetic

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

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

--- Comment #6 from Andrew Pinski  ---
GCC does better now since GCC 10:
.L2:
movl(%ebx,%ecx,4), %eax
xorl%edx, %edx
addl$-1, %eax
adcl$0, %edx
addl%eax, %esi
adcl%edx, %edi
movl%esi, -424(%ebp,%ecx,4)
addl$1, %ecx
movl%edi, %esi
xorl%edi, %edi
cmpl$100, %ecx
jne .L2

But still not as good as ICC:
..B1.4: # Preds ..B1.4 ..B1.3
# Execution count [5.00e+01]
addl  32(%esp,%eax,8), %ebx #25.5
movl  %esi, %edx#25.5
adcl  $0, %edx  #25.5
addl  432(%esp,%eax,8), %ebx#25.37
movl  %ebx, 832(%esp,%eax,8)#26.5
movl  %esi, %ebx#25.5
adcl  $0, %edx  #25.37
addl  36(%esp,%eax,8), %edx #25.5
adcl  $0, %ebx  #25.5
addl  436(%esp,%eax,8), %edx#25.37
movl  %edx, 836(%esp,%eax,8)#26.5
adcl  $0, %ebx  #25.37
incl  %eax  #24.3
cmpl  $50, %eax #24.3
jb..B1.4# Prob 98%


LLVM just falls over:
.LBB0_1:# =>This Inner Loop Header: Depth=1
xorl%ebx, %ebx
addl808(%esp,%edx,4), %eax
setb%bl
addl408(%esp,%edx,4), %eax
adcl$0, %ebx
movl%eax, 8(%esp,%edx,4)
cmpl$100, %edx
je  .LBB0_3
# %bb.2:#   in Loop: Header=BB0_1 Depth=1
xorl%eax, %eax
addl812(%esp,%edx,4), %ebx
setb%al
addl412(%esp,%edx,4), %ebx
adcl$0, %eax
movl%ebx, 12(%esp,%edx,4)
addl$2, %edx
jmp .LBB0_1
.LBB0_3:

[Bug tree-optimization/23970] loop-invariant-motion is not doing it's work

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

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

--- Comment #2 from Andrew Pinski  ---
We are able to do the LIM at -O3 which enables loop unswitching.
I wonder if there is a way to enable a limited form of loop unswitching for -O2
where one branch of the loop to unswitch is empty.

[Bug d/103840] New: d: Errors message: Please submit a full bug report in testsuite

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

Bug ID: 103840
   Summary: d: Errors message: Please submit a full bug report in
testsuite
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ibuclaw at gdcproject dot org
  Target Milestone: ---

A number of fail_compilation tests are silently passing with the error: Please
submit a full bug report.  They should all be fixed.

---
299.o fail_compilation/fail299.d^M
^M
in pp_format, at pretty-print.c:1478^M
0x9db102 pp_format(pretty_printer*, text_info*)^M
../../gcc/pretty-print.c:1478^M
0x20ae97c diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)^M
../../gcc/diagnostic.c:1346^M
0xbe43aa d_diagnostic_report_diagnostic^M
../../gcc/d/d-diagnostic.cc:203^M
0xbe450c verror(Loc const&, char const*, __va_list_tag*, char const*, char
const*, char const*)^M
../../gcc/d/d-diagnostic.cc:242^M
0xab2769 error(Loc const&, char const*, ...)^M
../../gcc/d/dmd/errors.d:100^M
0xacdf78
_D3dmd13expressionsem3fitFCQz7dstruct17StructDeclarationKxSQCf7globals3LocPSQCw6dscope5ScopePSQDo4root5array__T5ArrayTCQEn10expression10ExpressionZQBkCQFt5mtype4TypeZb^M
../../gcc/d/dmd/expressionsem.d:13111^M


---
fail_compilation/fail1995.d:12:24: note: Path(s) searched (as provided by
'-J'):^M
^M
in pp_format, at pretty-print.c:1478^M
0x9db102 pp_format(pretty_printer*, text_info*)^M
../../gcc/pretty-print.c:1478^M
0x20ae97c diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)^M
../../gcc/diagnostic.c:1346^M
0xbe43aa d_diagnostic_report_diagnostic^M
../../gcc/d/d-diagnostic.cc:203^M
0xaba431 Expression::errorSupplemental(char const*, ...)^M
../../gcc/d/dmd/expression.d:815^M
---

[Bug d/103840] d: Errors message: Please submit a full bug report in testsuite

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

--- Comment #1 from Iain Buclaw  ---
In both cases, the dmd front-end has an error with %zu as a format specifier in
the message.

[Bug rtl-optimization/50107] [IRA, i386] allocates registers in very non-optimal way

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #15 from Andrew Pinski  ---
All of the register allocation issues referenced in this bug report were fixed
in GCC 4.8 and above as far as I can test.

[Bug target/51954] __int128_t (and long long on x86) negation can be optimized

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

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

--- Comment #2 from Andrew Pinski  ---
We get this now:

movq%rdi, %rax
movq%rsi, %rdx
negq%rax
adcq$0, %rdx
negq%rdx

ICC produces:
xorl  %edx, %edx#3.10
xorl  %eax, %eax#3.10
subq  %rdi, %rax#3.10
sbbq  %rsi, %rdx#3.10
ret #3.10

Which seems even better.

LLVM does produce:
movq%rdi, %rax
xorl%edx, %edx
negq%rax
sbbq%rsi, %rdx

Which basically combines the addcq and negq together and changes one mov into
an exor.

[Bug target/56876] Combine does not invent new moves

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2021-12-26
  Known to fail||4.7.3

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

[Bug tree-optimization/64745] Generic vectorization missed opportunities

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug tree-optimization/64745] Generic vectorization missed opportunities

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||10.1.0
 Resolution|--- |FIXED
  Known to fail||6.1.0, 8.1.0, 9.1.0
   Target Milestone|--- |10.0

--- Comment #3 from Andrew Pinski  ---
Both are caught in GCC 10+ now for SLP.

Note store merging is able to catch it in GCC 8+ too.

So closing as fixed in GCC 10 for the SLP part of the bug.

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

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

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

Bug 64745 Summary: Generic vectorization missed opportunities
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64745

   What|Removed |Added

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

[Bug tree-optimization/57962] Missed SLP opportunity

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

[Bug tree-optimization/79349] unused std::string is not optimized away in presense of a call

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|libstdc++   |tree-optimization

--- Comment #5 from Andrew Pinski  ---
here is the current IR (with -fno-exceptions) at -O3:

  MEM[(struct basic_string *)&s] ={v} {CLOBBER};
  MEM[(struct _Alloc_hider *)&s] ={v} {CLOBBER};
  MEM[(struct _Alloc_hider *)&s]._M_p = &s.D.26433._M_local_buf;
  __builtin_memcpy (&s.D.26433._M_local_buf, "abc", 3);
  s._M_string_length = 3;
  MEM[(char_type &)&s + 19] = 0;
  foo ();
  _3 = s._M_dataplus._M_p;
  if (&s.D.26433._M_local_buf != _3)
goto ; [53.47%]
  else
goto ; [46.53%]

   [local count: 574129753]:
  _7 = s.D.26433._M_allocated_capacity;
  _8 = _7 + 1;
  operator delete (_3, _8);

for some reason GCC thinks foo can modify s so the load for s._M_dataplus._M_p
is not be optimized to just &s.D.26433._M_local_buf

[Bug target/86693] inefficient atomic_fetch_xor

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Hongtao.liu  ---
Change testcase a little bit, gcc now can generate lock btc


void func1();

void func(unsigned long *counter)
{
if (__atomic_fetch_xor(counter, 1, __ATOMIC_ACQ_REL) & 1) {
func1();
}
}


func(unsigned long*):
lock btcQWORD PTR [rdi], 0
jc  .L4
ret
.L4:
jmp func1()

[Bug target/103623] [12 Regression] error: unable to generate reloads (ICE in curr_insn_transform, at lra-constraints.c:4132), or error: insn does not satisfy its constraints (ICE in extract_constrain

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

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

--- Comment #14 from Kewen Lin  ---
> % powerpc-e300c3-linux-gnu-gcc-12.0.0 -v
> Using built-in specs.
> COLLECT_GCC=powerpc-e300c3-linux-gnu-gcc-12.0.0
> COLLECT_LTO_WRAPPER=/usr/libexec/gcc/powerpc-e300c3-linux-gnu/12.0.0/lto-
> wrapper
> Target: powerpc-e300c3-linux-gnu
> Configured with:
[snip]
> Thread model: posix
> Supported LTO compression algorithms: zlib
> gcc version 12.0.0 20211219 (experimental) (GCC)

Thanks!  I tried

Target: powerpc-e300c3-linux-gnu
Configured with: /home/linkw/gcc/gcc-test/configure
--prefix=/home/linkw/gcc/install/gcc-test-debug
--target=powerpc-e300c3-linux-gnu --enable-languages=c,c++,fortran
--enable-obsolete --disable-werror --with-system-zlib --disable-nls
--disable-libunwind-exceptions --enable-checking=yes --disable-esp
--enable-libstdcxx-time --disable-libstdcxx-pch
--enable-poison-system-directories --with-sysroot=/usr/powerpc-e300c3-linux-gnu
--disable-bootstrap --enable-__cxa_atexit --enable-clocale=gnu
--disable-multilib --disable-fixed-point --enable-targets=all --enable-libgomp
--disable-libssp --disable-libada --disable-cet --disable-systemtap
--enable-valgrind-annotations --disable-vtable-verify --disable-libvtv
--without-zstd --enable-lto --with-isl --disable-isl-version-check
--disable-libsanitizer --enable-default-pie --enable-default-ssp
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20211219 (experimental) (GCC)

on powerpc64le-linux-gnu, failed to reproduce it.

I tried it on a x86_64 cfarm machine:

/home/linkw/gcc/gcc-test/configure --host=x86_64-pc-linux-gnu
--target=powerpc-e300c3-linux-gnu --build=x86_64-pc-linux-gnu
--prefix=/home/linkw/gcc/install/gcc-test-debug
--enable-languages=c,c++,fortran --enable-obsolete --disable-werror
--with-system-zlib --disable-nls --disable-libunwind-exceptions
--enable-checking=yes --disable-esp --enable-libstdcxx-time
--disable-libstdcxx-pch --enable-poison-system-directories
--with-sysroot=/usr/powerpc-e300c3-linux-gnu --disable-bootstrap
--enable-__cxa_atexit --enable-clocale=gnu --disable-multilib
--disable-fixed-point --enable-targets=all --enable-libgomp --disable-libssp
--disable-libada --disable-cet --disable-systemtap --disable-vtable-verify
--disable-libvtv --without-zstd --enable-lto --disable-libsanitizer
--enable-default-pie --enable-default-ssp

Some options which caused it failed to build were omitted:
--enable-valgrind-annotations  --with-isl  --disable-isl-version-check
--enable-secureplt
I guess they don't really matter. 

Not sure what's wrong there.

[Bug target/103623] [12 Regression] error: unable to generate reloads (ICE in curr_insn_transform, at lra-constraints.c:4132), or error: insn does not satisfy its constraints (ICE in extract_constrain

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

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

--- Comment #15 from Kewen Lin  ---
> 
> I tried it on a x86_64 cfarm machine:
> 
> /home/linkw/gcc/gcc-test/configure --host=x86_64-pc-linux-gnu
> --target=powerpc-e300c3-linux-gnu --build=x86_64-pc-linux-gnu
> --prefix=/home/linkw/gcc/install/gcc-test-debug
> --enable-languages=c,c++,fortran --enable-obsolete --disable-werror
> --with-system-zlib --disable-nls --disable-libunwind-exceptions
> --enable-checking=yes --disable-esp --enable-libstdcxx-time
> --disable-libstdcxx-pch --enable-poison-system-directories
> --with-sysroot=/usr/powerpc-e300c3-linux-gnu --disable-bootstrap
> --enable-__cxa_atexit --enable-clocale=gnu --disable-multilib
> --disable-fixed-point --enable-targets=all --enable-libgomp --disable-libssp
> --disable-libada --disable-cet --disable-systemtap --disable-vtable-verify
> --disable-libvtv --without-zstd --enable-lto --disable-libsanitizer
> --enable-default-pie --enable-default-ssp
> 

Forgot to note that this configuration on x86_64 can't reproduce it either.

[Bug tree-optimization/83389] std::tie generates sub-optimal code when used to compare POD fields

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Last reconfirmed|2017-12-12 00:00:00 |2021-12-26

[Bug tree-optimization/103802] [12 regression] recip-3.c fails after r12-6087 on Power m32

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

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

--- Comment #1 from luoxhu at gcc dot gnu.org ---
MOVE_MAX_PIECES is 4 on m32 but it is 8 on m64, then estimate_move_cost is
different between them 2 vs 1 for “((size + MOVE_MAX_PIECES - 1) /
MOVE_MAX_PIECES)".

recip-3.m32.c.172t.cunroll:

 BB: 11, after_exit: 0
 BB: 7, after_exit: 0
  size:   2 _4 = F[i_23];
  size:   1 _5 = _4 + iftmp.1_10;
  size:   2 F[i_23] = _5;
 BB: 5, after_exit: 0
  size:   1 _2 = d_14 +
1.00088817841970012523233890533447265625e-1;
  size:   1 reciptmp_12 = 1.0e+0 / d_14;
  size:   1 iftmp.1_18 = reciptmp_12 * _2;
 BB: 6, after_exit: 0
  size:   1 _3 = -1.00088817841970012523233890533447265625e-1 -
d_14;
  size:   1 reciptmp_25 = 1.0e+0 / d_14;
  size:   1 iftmp.1_17 = reciptmp_25 * _3;
 BB: 4, after_exit: 0
  size:   2 if (e.0_1 <
-5.00444089209850062616169452667236328125e-2)
size: 19-4, last_iteration: 19-4
  Loop size: 19
  Estimated size after unrolling: 20
Not unrolling loop 1: size would grow.


But recip-3.m64.c.172t.cunroll:

 BB: 11, after_exit: 0
 BB: 7, after_exit: 0
  size:   1 _4 = F[i_23];
  size:   1 _5 = _4 + iftmp.1_10;
  size:   1 F[i_23] = _5;
 BB: 5, after_exit: 0
  size:   1 _2 = d_14 +
1.00088817841970012523233890533447265625e-1;
  size:   1 reciptmp_12 = 1.0e+0 / d_14;
  size:   1 iftmp.1_18 = reciptmp_12 * _2;
 BB: 6, after_exit: 0
  size:   1 _3 = -1.00088817841970012523233890533447265625e-1 -
d_14;
  size:   1 reciptmp_25 = 1.0e+0 / d_14;
  size:   1 iftmp.1_17 = reciptmp_25 * _3;
 BB: 4, after_exit: 0
  size:   2 if (e.0_1 <
-5.00444089209850062616169452667236328125e-2)
size: 17-4, last_iteration: 17-4
  Loop size: 17
  Estimated size after unrolling: 17
Making edge 18->9 impossible by redistributing probability to other edges.
Making edge 8->10 impossible by redistributing probability to other edges.
/home/luoxhu/workspace/gcc-master/gcc/testsuite/gcc.dg/tree-ssa/recip-3.c:16:14:
optimized: loop with 1 iterations completely unrolled (header execution count
357878154)

[Bug target/86693] inefficient atomic_fetch_xor

[hjl.tools at gmail dot com via Gcc-bugs]

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

--- Comment #5 from H.J. Lu  ---
(In reply to Hongtao.liu from comment #4)
> Change testcase a little bit, gcc now can generate lock btc
> 
> 
> void func1();
> 
> void func(unsigned long *counter)
> {
> if (__atomic_fetch_xor(counter, 1, __ATOMIC_ACQ_REL) & 1) {
> func1();
> }
> }
> 
> 
> func(unsigned long*):
> lock btcQWORD PTR [rdi], 0
> jc  .L4
> ret
> .L4:
> jmp func1()

We should rewrite the original test to the canonical form, similar to r12-5102.
Hongtao, can you do that?

[Bug tree-optimization/103802] [12 regression] recip-3.c fails after r12-6087 on Power m32

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

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

--- Comment #2 from luoxhu at gcc dot gnu.org ---
-funroll-loops could work around this, is this reasonable?

[Bug target/103623] [12 Regression] error: unable to generate reloads (ICE in curr_insn_transform, at lra-constraints.c:4132), or error: insn does not satisfy its constraints (ICE in extract_constrain

[asolokha at gmx dot com via Gcc-bugs]

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

--- Comment #16 from Arseny Solokha  ---
Could there be any ld, or as, or glibc features involved that gcc's configure
detects at build time?

[Bug c++/85747] suboptimal code without constexpr

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #9 from Andrew Pinski  ---
size: 13-3, last_iteration: 13-3
  Loop size: 13
  Estimated size after unrolling: 40
Not unrolling loop 1: it is not innermost and code would grow.

There are a few others like this one.
Note LLVM is able even to handle:
template 
constexpr void sort(It first, It last) {
for (;first != last; ++first) {
auto it = first;
++it;
for (; it != last; ++it) {
if (*it < *first) {
auto tmp = *it;
*it = *first;
*first = tmp;
}
}
}
}

static int generate() {
int a[] = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21};
a[5] = 55;
sort(a + 0, a + 21);
return a[0] + a[6] + a[1] + a[2] + a[3] + a[4];
}

I suspect the cost estimate it does for the loop is the removal of the load of
a[i] knowing that a is fully written to.

[Bug tree-optimization/97077] Missed loop unrolling with range for over initializer list

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
Dup of bug 85747.

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

[Bug c++/85747] suboptimal code without constexpr

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||bmburstein at gmail dot com

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

[Bug tree-optimization/87543] Inconsistency in noticing a constant result rather than emitting code for a loop

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #7 from Andrew Pinski  ---
Dup of bug 85747.

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

[Bug c++/85747] suboptimal code without constexpr

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||eyalroz1 at gmx dot com

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

[Bug tree-optimization/89922] Loop on fixed size array is not unrolled and poorly optimized at -O2

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #7 from Andrew Pinski  ---
Dup of bug 85747.

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

[Bug c++/85747] suboptimal code without constexpr

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

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

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

[Bug ipa/81000] std::any improvement

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed|2017-06-07 00:00:00 |2021-12-26
   Severity|normal  |enhancement

[Bug tree-optimization/92867] Use ERF_RETURNS_ARG in more places

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #7 from Andrew Pinski  ---
Dup of bug 67797.

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

[Bug middle-end/67797] builtin functions should be able to know when their first argument is returned

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

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

[Bug tree-optimization/83142] Missed tail-call opportunity with memmove and other mem*/str* functions which return the first argument back

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
Dup of bug 67797.

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

[Bug tree-optimization/67797] builtin functions should be able to know when their first argument is returned for tail calls

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

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

[Bug tree-optimization/82991] memcpy and strcpy return value can be assumed to be equal to first argument

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

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

Bug 83142 Summary: Missed tail-call opportunity with memmove and other 
mem*/str* functions which return the first argument back
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83142

   What|Removed |Added

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

[Bug tree-optimization/88361] gcc does not unroll loop

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

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

--- Comment #3 from Andrew Pinski  ---

 is executed at most 19 (bounded by 19) + 1 times in loop 1.
Analyzing # of iterations of loop 1
  exit condition [19, + , 4294967295] != 0
  bounds on difference of bases: -19 ... -19
  result:
# of iterations 19, bounded by 19
Loop 1 iterates 19 times.
Loop 1 iterates at most 19 times.
Loop 1 likely iterates at most 19 times.
Not unrolling loop 1 (--param max-completely-peel-times limit reached).

Increasing the param allows the loop to be unrolled.

[Bug rtl-optimization/88428] Fails to consider lea -1(%rax), %rax compared to sub 1, %rax failing to CSE test

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Confirmed, we get now:

xorl%eax, %eax
cmpl%esi, %edi
setl%al
negq%rax
movq%rax, mask(%rip)
cmpl%esi, %edi
jl  .L5

Because we produce similar to the following C testcase:
long mask;

void bar ();
void f (int a, int b)
{
  long _3;
  _3 = a < b;
  _3 = -_3;
  mask = _3;
  if (a < b)
bar ();
  return;
}

[Bug target/103623] [12 Regression] error: unable to generate reloads (ICE in curr_insn_transform, at lra-constraints.c:4132), or error: insn does not satisfy its constraints (ICE in extract_constrain

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

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

--- Comment #17 from Kewen Lin  ---
(In reply to Arseny Solokha from comment #16)
> Could there be any ld, or as, or glibc features involved that gcc's
> configure detects at build time?

Good point, what's the version of binutils you used? Does it have any special
configuration options?  btw, could you try the above configuration which I used
on x86_64 to confirm the configuration actually fails to reproduce? Note that I
don't have one actual directory for the sysroot locally.

If you can confirm the above configuration also fails to reproduce on your
side, maybe you can isolate which configuration option matters by adding those
omitted back one by one on your side.

[Bug target/77438] Vector lowering should also consider larger vector sizes (MMX -> SSE)

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Target Milestone|--- |10.0
  Component|tree-optimization   |target
 Status|NEW |RESOLVED

--- Comment #6 from Andrew Pinski  ---
The x86_64 specific case was fixed in GCC 10 so closing.
We get now:

mmx:
.LFB129:
.cfi_startproc
paddb   %xmm1, %xmm0
ret

As expected, There has been improvements later on even.

[Bug middle-end/88670] [meta-bug] generic vector extension issues

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

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

Bug 77438 Summary: Vector lowering should also consider larger vector sizes 
(MMX -> SSE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77438

   What|Removed |Added

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

[Bug target/103623] [12 Regression] error: unable to generate reloads (ICE in curr_insn_transform, at lra-constraints.c:4132), or error: insn does not satisfy its constraints (ICE in extract_constrain

[asolokha at gmx dot com via Gcc-bugs]

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

--- Comment #18 from Arseny Solokha  ---
(In reply to Kewen Lin from comment #17)
> (In reply to Arseny Solokha from comment #16)
> > Could there be any ld, or as, or glibc features involved that gcc's
> > configure detects at build time?
> 
> Good point, what's the version of binutils you used? Does it have any
> special configuration options?

binutils 2.37.

./configure --enable-plugins --enable-gold --disable-nls --with-system-zlib
--enable-64-bit-bfd --build=x86_64-pc-linux-gnu
--with-sysroot=/usr/powerpc-e300c3-linux-gnu --enable-poison-system-directories
--enable-secureplt --enable-default-hash-style=gnu --prefix=/usr
--host=x86_64-pc-linux-gnu --target=powerpc-e300c3-linux-gnu
--datadir=/usr/share/binutils-data/powerpc-e300c3-linux-gnu/2.37_p1
--datarootdir=/usr/share/binutils-data/powerpc-e300c3-linux-gnu/2.37_p1
--infodir=/usr/share/binutils-data/powerpc-e300c3-linux-gnu/2.37_p1/info
--mandir=/usr/share/binutils-data/powerpc-e300c3-linux-gnu/2.37_p1/man
--bindir=/usr/x86_64-pc-linux-gnu/powerpc-e300c3-linux-gnu/binutils-bin/2.37_p1
--libdir=/usr/lib64/binutils/powerpc-e300c3-linux-gnu/2.37_p1
--libexecdir=/usr/lib64/binutils/powerpc-e300c3-linux-gnu/2.37_p1
--includedir=/usr/lib64/binutils/powerpc-e300c3-linux-gnu/2.37_p1/include
--enable-obsolete --enable-shared --enable-threads --enable-relro
--enable-install-libiberty --enable-textrel-check=warning --enable-new-dtags
--disable-werror --disable-static --disable-gdb --disable-libdecnumber
--disable-readline --disable-sim --without-stage1-ldflags --without-debuginfod
--disable-cet

[Bug target/88705] [ARM][Generic Vector Extensions] float32x4/float64x2 vector operator overloads scalarize on NEON

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Last reconfirmed|2019-01-05 00:00:00 |2021-12-26

[Bug target/103623] [12 Regression] error: unable to generate reloads (ICE in curr_insn_transform, at lra-constraints.c:4132), or error: insn does not satisfy its constraints (ICE in extract_constrain

[asolokha at gmx dot com via Gcc-bugs]

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

--- Comment #19 from Arseny Solokha  ---
(In reply to Kewen Lin from comment #17)
> (In reply to Arseny Solokha from comment #16)
> > Could there be any ld, or as, or glibc features involved that gcc's
> > configure detects at build time?
> 
> btw, could you try the above configuration
> which I used on x86_64 to confirm the configuration actually fails to
> reproduce? Note that I don't have one actual directory for the sysroot
> locally.
> 
> If you can confirm the above configuration also fails to reproduce on your
> side, maybe you can isolate which configuration option matters by adding
> those omitted back one by one on your side.

No, w/ your configuration gcc also ICEs for me on that testcase.

Is there any useful data that I could extract for you using gdb?

[Bug target/56876] Combine does not invent new moves

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Dup of bug 53652.

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

[Bug rtl-optimization/53652] *andn* isn't used for vectorization

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||glisse at gcc dot gnu.org

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

[Bug rtl-optimization/53652] *andn* isn't used for vectorization

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #7 from Andrew Pinski  ---
Simplified testcase from PR 56876:

typedef unsigned long long vec __attribute__((vector_size(16)));
vec g;
vec f1(vec a, vec b){
  return ~a&b;
}
vec f2(vec a, vec b){
  return ~g&b;
}

f2 is similar to the testcase referenced in comment #0.

[Bug middle-end/95922] Failure to optimize `((b ^ a) & c) ^ a` to `(a & ~c) | (b & c)` the right way on architectures with andnot

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
Dup of bug 94790.

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

[Bug rtl-optimization/94790] Failure to use andn in specific pattern in which it is available

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

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

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

[Bug tree-optimization/91459] Tail-Call Optimization is not performed when return value is assumed.

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed|2019-08-16 00:00:00 |2021-12-26

--- Comment #4 from Andrew Pinski  ---
So when DOM3 changes:

  result_5 = function_returns_only_1_or_doesnt_return (a_2(D), b_3(D));
  if (result_5 == 1)
goto ; [100.00%]
  else
goto ; [0.00%]

   [local count: 1073741824]:
  return 1;

   [count: 0]:
  __builtin_unreachable ();

To

  result_5 = function_returns_only_1_or_doesnt_return (a_2(D), b_3(D));
  return 1;

I wonder if it could change 1 back into result_5 because it comes from a
function call.

[Bug target/103623] [12 Regression] error: unable to generate reloads (ICE in curr_insn_transform, at lra-constraints.c:4132), or error: insn does not satisfy its constraints (ICE in extract_constrain

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

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

--- Comment #20 from Kewen Lin  ---
(In reply to Arseny Solokha from comment #19)
> (In reply to Kewen Lin from comment #17)
> > (In reply to Arseny Solokha from comment #16)
> > > Could there be any ld, or as, or glibc features involved that gcc's
> > > configure detects at build time?
> > 
> > btw, could you try the above configuration
> > which I used on x86_64 to confirm the configuration actually fails to
> > reproduce? Note that I don't have one actual directory for the sysroot
> > locally.
> > 
> > If you can confirm the above configuration also fails to reproduce on your
> > side, maybe you can isolate which configuration option matters by adding
> > those omitted back one by one on your side.
> 
> No, w/ your configuration gcc also ICEs for me on that testcase.
> 
> Is there any useful data that I could extract for you using gdb?

Thanks for the information! I'll go with your provided binutils information and
try again. How about the information on glibc as well?

As to gdb, I would expect that:

1） (TARGET_LONG_DOUBLE_128 && TARGET_HARD_FLOAT && !TARGET_IEEEQUAD)

this return false on your side, which is the flag used for previous bif
support.
Could you check all the values?

2) FLOAT128_2REG_P (TFmode)

this return true on your side, and as the below defintion,

#define FLOAT128_2REG_P(MODE)   \
  (FLOAT128_IBM_P (MODE)\
   || ((MODE) == TDmode)\
   || (!TARGET_FLOAT128_TYPE && FLOAT128_IEEE_P (MODE)))

#define FLOAT128_IBM_P(MODE)\
  ((!TARGET_IEEEQUAD && TARGET_LONG_DOUBLE_128  \
&& ((MODE) == TFmode || (MODE) == TCmode))  \
   || (TARGET_HARD_FLOAT && ((MODE) == IFmode || (MODE) == ICmode)))

Could you check which condition arm makes FLOAT128_2REG_P true on your side?

[Bug target/103623] [12 Regression] error: unable to generate reloads (ICE in curr_insn_transform, at lra-constraints.c:4132), or error: insn does not satisfy its constraints (ICE in extract_constrain

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

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

Kewen Lin  changed:

   What|Removed |Added

   Last reconfirmed|2021-12-10 00:00:00 |2021-12-27

--- Comment #21 from Kewen Lin  ---
> 1） (TARGET_LONG_DOUBLE_128 && TARGET_HARD_FLOAT && !TARGET_IEEEQUAD)
> 
> this return false on your side, which is the flag used for previous bif
> support.
> Could you check all the values?
> 
> 2) FLOAT128_2REG_P (TFmode)
> 
> this return true on your side, and as the below defintion,
> 
> #define FLOAT128_2REG_P(MODE) \
>   (FLOAT128_IBM_P (MODE)  \
>|| ((MODE) == TDmode)  \
>|| (!TARGET_FLOAT128_TYPE && FLOAT128_IEEE_P (MODE)))
> 
> #define FLOAT128_IBM_P(MODE)  \
>   ((!TARGET_IEEEQUAD && TARGET_LONG_DOUBLE_128
> \
> && ((MODE) == TFmode || (MODE) == TCmode))
> \
>|| (TARGET_HARD_FLOAT && ((MODE) == IFmode || (MODE) == ICmode)))
> 
> Could you check which condition arm makes FLOAT128_2REG_P true on your side?

After typing these checks, I just tried and realized that my local cross-build
on ppc64le can reproduce this if I specify -mlong-double-128. So Arseny's local
env make this option default as -mlong-double-128 while mine uses
-mlong-double-64.  Thanks Arseny! :)

So confirmed.

[Bug target/103623] [12 Regression] error: unable to generate reloads (ICE in curr_insn_transform, at lra-constraints.c:4132), or error: insn does not satisfy its constraints (ICE in extract_constrain

[asolokha at gmx dot com via Gcc-bugs]

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

--- Comment #22 from Arseny Solokha  ---
(In reply to Kewen Lin from comment #21)
> After typing these checks, I just tried and realized that my local
> cross-build on ppc64le can reproduce this if I specify -mlong-double-128. So
> Arseny's local env make this option default as -mlong-double-128 while mine
> uses -mlong-double-64.  Thanks Arseny! :)
> 
> So confirmed.

OK, JFTR:

% powerpc-e300c3-linux-gnu-gcc-12.0.0 -mcpu=401 -Q --help=target | grep
mlong-double
  -mlong-double-127

[Bug target/103623] [12 Regression] error: unable to generate reloads (ICE in curr_insn_transform, at lra-constraints.c:4132), or error: insn does not satisfy its constraints (ICE in extract_constrain

[asolokha at gmx dot com via Gcc-bugs]

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

--- Comment #23 from Arseny Solokha  ---
And, for the record:

(gdb) p TARGET_LONG_DOUBLE_128
$1 = true
(gdb) p TARGET_HARD_FLOAT
$2 = false
(gdb) p TARGET_IEEEQUAD
$3 = 0

[Bug target/54273] ICE with global floating register and soft float

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code,
   ||testsuite-fail

--- Comment #1 from Andrew Pinski  ---
The code should have been rejected as floating registers are turned off with
soft-float 
Also the testcase should have not run with soft-float targets either.