date:20210707

[Bug bootstrap/101372] New: [12 Regression] Bootstrap failure compiling gcc/cp/module.cc

2021-07-07 Thread tnfchris at gcc dot gnu.org via Gcc-bugs

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

Bug ID: 101372
   Summary: [12 Regression] Bootstrap failure compiling
gcc/cp/module.cc
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tnfchris at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64-*

At the current HEAD (g:852b11da11a181df517c0348df044354ff0656d6) the bootstrap
is broken with a number of -Werror failures such as

ibiberty/libiberty.a ../libdecnumber/libdecnumber.a
In file included from ../../gcc-fsf/gcc/c-family/c-common.h:26,
 from ../../gcc-fsf/gcc/cp/cp-tree.h:40,
 from ../../gcc-fsf/gcc/cp/module.cc:209:
In function ‘tree_node* identifier(const cpp_hashnode*)’,
inlined from ‘bool module_state::read_macro_maps()’ at
../../gcc-fsf/gcc/cp/module.cc:16305:10:
../../gcc-fsf/gcc/tree.h:1089:58: error: array subscript -1 is outside array
bounds of ‘cpp_hashnode [288230376151711743]’ [-Werror=array-bounds]
 1089 |   ((tree) ((char *) (NODE) - sizeof (struct tree_common)))
  |  ^
../../gcc-fsf/gcc/cp/module.cc:277:10: note: in expansion of macro
‘HT_IDENT_TO_GCC_IDENT’
  277 |   return HT_IDENT_TO_GCC_IDENT (HT_NODE (const_cast
(node)));
  |  ^
In file included from ../../gcc-fsf/gcc/tree.h:23,
 from ../../gcc-fsf/gcc/c-family/c-common.h:26,
 from ../../gcc-fsf/gcc/cp/cp-tree.h:40,
 from ../../gcc-fsf/gcc/cp/module.cc:209:
../../gcc-fsf/gcc/tree-core.h: In member function ‘bool
module_state::read_macro_maps()’:
../../gcc-fsf/gcc/tree-core.h:1445:24: note: at offset -24 into object
‘tree_identifier::id’ of size 16
 1445 |   struct ht_identifier id;
  |^~

The macro defined in gcc/tree.h:1089 

#define HT_IDENT_TO_GCC_IDENT(NODE) \
  ((tree) ((char *) (NODE) - sizeof (struct tree_common)))

does no null check on NODE which can then result in a value of -1 for the
resulting size_t.

I can't really see what caused this to be triggered, don't see a recent commit
that touched this (from a quick search).

Should a simple null check be added here?

[Bug c++/101371] New: constexpr expansions trigger internal Compiler Error

2021-07-07 Thread warren_graeme at yahoo dot co.uk via Gcc-bugs

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

Bug ID: 101371
   Summary: constexpr expansions trigger internal Compiler Error
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: warren_graeme at yahoo dot co.uk
  Target Milestone: ---

Created attachment 51115
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51115&action=edit
preprocessed source code

Hello,

When attempting to compile a C++ function with gcc I have triggered an Internal
Compiler Error. I achieved this with the following commands:

g++-7 --std=c++17 -E init.cc > init.ii
g++-7 --std=c++17 -c init.ii



1) the peccant function (init.cc) follows:

++
#include 
#include 
using namespace std;

constexpr unsigned short N_citruss = 8;

enum class berry: unsigned{cran, straw, rasp, bil, black, huckle, elder,
goose};
constexpr berry operator++(berry& b, int) noexcept {
return b = berry(static_cast(b) + 1); }

struct berry_set_CX{
bitset<8> bset;
constexpr berry_set_CX(const bitset<8>& bits) noexcept: bset(bits) {}
constexpr berry_set_CX(const char  bits) noexcept: bset(bits) {}
constexpr berry_set_CX() noexcept : bset() {}
constexpr berry_set_CX(const berry_set_CX& rhs) noexcept :
bset(rhs.bset) {}
};

struct bersets_by_citrus_CX{
array berrysets;
};

struct entree0_CX{
bersets_by_citrus_CX passes;
constexpr entree0_CX(const bersets_by_citrus_CX& bsbc) noexcept :
passes(bsbc) {}
};

struct berrybox_CX{
constexpr entree0_CX make_entree() const noexcept {
bersets_by_citrus_CX bsbc {};
return entree0_CX(bsbc);
}
constexpr berrybox_CX(berry w, berry_set_CX hs) noexcept {}
};

void init() noexcept{
const berry_set_CX fixed(bitset<8>(1));
for (berry root_berry = berry::cran; root_berry <= berry::goose;
root_berry++){
berrybox_CX nu_cs0(root_berry, fixed);
const entree0_CX& pas = nu_cs0.make_entree();
}
return;
}
--

2) the preprocessed source file (init.ii) is attached;

3) the compiler version used (gcc -v output)  is:

+++

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/7/lto-wrapper
OFFLOAD_TARGET_NAMES=hsa:nvptx-none
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,ada,go
--enable-offload-targets=hsa,nvptx-none, --without-cuda-driver
--enable-checking=release --disable-werror
--with-gxx-include-dir=/usr/include/c++/7 --enable-ssp --disable-libssp
--disable-libvtv --disable-libcc1 --disable-plugin
--with-bugurl=https://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--with-slibdir=/lib64 --with-system-zlib --enable-libstdcxx-allocator=new
--disable-libstdcxx-pch --enable-version-specific-runtime-libs
--with-gcc-major-version-only --enable-linker-build-id --enable-linux-futex
--enable-gnu-indirect-function --program-suffix=-7 --without-system-libunwind
--enable-multilib --with-arch-32=x86-64 --with-tune=generic
--build=x86_64-suse-linux --host=x86_64-suse-linux
Thread model: posix
gcc version 7.5.0 (SUSE Linux) 

--

4) the compiler output is:

i+
init.cc: In function ‘void init()’:
init.cc:40:46:   in constexpr expansion of ‘berrybox_CX::make_entree() const()’
init.cc:40:46:   in constexpr expansion of ‘entree0_CX(((const
bersets_by_citrus_CX&)(& bsbc)))’
init.cc:25:79:   in constexpr expansion of
‘((entree0_CX*)this)->entree0_CX::passes.bersets_by_citrus_CX::bersets_by_citrus_CX(bsbc)’
init.cc:19:8:   in constexpr expansion of
‘((bersets_by_citrus_CX*)this)->bersets_by_citrus_CX::berrysets.std::array::array(bersets_by_citrus_CX::berrysets)’
init.cc:40:46:   in constexpr expansion of
‘berry_set_CX(std::array::_M_elems[0])’
init.cc:40:46: internal compiler error: in cxx_eval_component_reference, at
cp/constexpr.c:2479
   const entree0_CX& pas = nu_cs0.make_entree();
  ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

--

Initially the program which incorporated this function was developed under
OpenSuse Leap 42.3 . The default compiler on that OS did not support the
constexpr functionality I needed, so I installed g++-

[Bug tree-optimization/98176] Loop invariant memory could not be hoisted when nonpure_call in loop body

2021-07-07 Thread wwwhhhyyy333 at gmail dot com via Gcc-bugs

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

--- Comment #9 from Hongyu Wang  ---
(In reply to Richard Biener from comment #8)

> I'm failing to reproduce with the sincos example since sincos is transformed
> to __builtin_cexpi for me.  When using

I always generate sincosf with g++ -Ofast -fopenmp-simd -std=c++11, perhaps it
is related to libm? I'm using RHEL8 with glibc 2.28.

> so I don't think it buys us anything to handle calls yet.  sincos would
> also be considered as possibly not returning.
> 

Perhaps, since the sincosf case could only be vectorized with #pragma omp simd.
But I think it is better to allow those functions with libmvec implementation
if the input params are proved to be safe (such as local variables).

[Bug target/100809] PPC: __int128 divide/modulo does not use P10 instructions vdivsq/vdivuq

2021-07-07 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Michael Meissner :

https://gcc.gnu.org/g:852b11da11a181df517c0348df044354ff0656d6

commit r12-2135-g852b11da11a181df517c0348df044354ff0656d6
Author: Michael Meissner 
Date:   Wed Jul 7 21:55:38 2021 -0400

Generate 128-bit int divide/modulus on power10.

This patch adds support for the VDIVSQ, VDIVUQ, VMODSQ, and VMODUQ
instructions to do 128-bit arithmetic.

2021-07-07  Michael Meissner  

gcc/
PR target/100809
* config/rs6000/rs6000.md (udivti3): New insn.
(divti3): New insn.
(umodti3): New insn.
(modti3): New insn.

gcc/testsuite/
PR target/100809
* gcc.target/powerpc/p10-vdivq-vmodq.c: New test.

[Bug c++/101370] miscompile of self-referential constexpr or constinit array initializer

2021-07-07 Thread mpolacek at gcc dot gnu.org via Gcc-bugs

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

Marek Polacek  changed:

   What|Removed |Added

   Last reconfirmed||2021-07-08
 Status|UNCONFIRMED |NEW
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

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

[Bug c++/101232] Bad error message with stray semicolon in initializer

2021-07-07 Thread tobi at gcc dot gnu.org via Gcc-bugs

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

--- Comment #1 from Tobias Schlüter  ---
BTW an equivalent C example gives the proper error both with C and C++
https://godbolt.org/z/sWc67eWT8
=
struct X {
int a;
int b;
};

void f() {
struct X x = { 1, 2; };
}
=

: In function 'void f()':
:7:24: error: expected '}' before ';' token
7 | struct X x = { 1, 2; };
  |  ~ ^
: At global scope:
:8:1: error: expected declaration before '}' token
8 | }
  | ^

[Bug c++/101370] New: miscompile of self-referential constexpr or constinit array initializer

2021-07-07 Thread richard-gccbugzilla at metafoo dot co.uk via Gcc-bugs

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

Bug ID: 101370
   Summary: miscompile of self-referential constexpr or constinit
array initializer
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: richard-gccbugzilla at metafoo dot co.uk
  Target Milestone: ---

Testcase (reduced from tcmalloc):


struct Elem {
Elem* next_ = this;
Elem* prev_ = this;
};

constinit Elem qs[3];


GCC generates a zero initializer for qs:


qs:
.zero   48


If the `constinit` is removed, GCC instead incorrectly generates a dynamic
initializer, so presumably GCC knows that this variable *should* have a
constant initializer but can't actually form one.

The same problem can be observed without constinit:


constexpr Elem rs[3];
const void *p = rs;


... again results in a zero-initialized global and no dynamic initializer.

[Bug c++/100109] [9/10/11 Regression] ICE: unexpected expression 'E' of kind template_parm_index

2021-07-07 Thread jason at gcc dot gnu.org via Gcc-bugs

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|9.5 |12.0

--- Comment #6 from Jason Merrill  ---
Not worth backporting.

[Bug target/100909] [12 Regression] powerpc64le: Regression causing unexpected error with IBM long double

2021-07-07 Thread bergner at gcc dot gnu.org via Gcc-bugs

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

--- Comment #3 from Peter Bergner  ---
(In reply to Martin Liška from comment #2)
> Mine, I've got a patch for it.

Hi Martin, any status on how your patch worked out?

[Bug c++/101087] [9/10/11/12 Regression] Unevaluated operand of sizeof affects noexcept operator

2021-07-07 Thread mpolacek at gcc dot gnu.org via Gcc-bugs

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
Testing a patch.

[Bug tree-optimization/77980] missing optimization with division

2021-07-07 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #7 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #6)
> >The only time _3 is nonzero 0 is _2 == 1 but we already know _2 can't be 2.
> Should be:
> The only time _3 is nonzero 0 is _2 == 1 but we already know _2 can't be 1
> as "NONZERO 4294967294" (which is 0xfffe)

operator_div::wi_fold in range-op.cc is where it needs to be improved.

[Bug c++/101181] [11/12 Regression] ICE when using an alias template

2021-07-07 Thread ppalka at gcc dot gnu.org via Gcc-bugs

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

Patrick Palka  changed:

   What|Removed |Added

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

[Bug tree-optimization/77980] missing optimization with division

2021-07-07 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #6 from Andrew Pinski  ---
>The only time _3 is nonzero 0 is _2 == 1 but we already know _2 can't be 2.
Should be:
The only time _3 is nonzero 0 is _2 == 1 but we already know _2 can't be 1 as
"NONZERO 4294967294" (which is 0xfffe)

[Bug tree-optimization/77980] missing optimization with division

2021-07-07 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

--- Comment #5 from Andrew Pinski  ---
So we start out with:
  x2.0_1 = x2D.3906;
  # RANGE VR_VARYING NONZERO 4294967294
  _2 = x2.0_1 * 2;
  # RANGE [0, 1] NONZERO 1
  _3 = 1 / _2;
  # VUSE <.MEM_7(D)>
  x1.1_4 = x1D.3905;
  x1.2_5 = (unsigned intD.10) x1.1_4;
  _6 = _3 * x1.2_5;
  if (_6 != 0)


So _6 will either be x1.2_5 or 0 (if _3 == 0)
So this means (_6 != 0) can be changed to (x1.2_5 !=0 || _3 == 0).

The only time _3 is nonzero 0 is _2 == 1 but we already know _2 can't be 2.

So the way to fix this is to improve VRP to get the range on _3 correct.

[Bug tree-optimization/77980] missing optimization with division

2021-07-07 Thread vitong at microsoft dot com via Gcc-bugs

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

Victor Tong  changed:

   What|Removed |Added

 CC||vitong at microsoft dot com

--- Comment #4 from Victor Tong  ---
Would a fix for this be more appropriate in the WPA analysis pass? It seems
that if x2 can be proved to be a constant, then all instances of x2 should be
replaced with 1 and t1 would get optimized to 0.

I tried writing a pattern in match.pd for 1/n but I found that the expression
looked like this:

  x2.0_1 = x2;
  _2 = x2.0_1 * 2;
  _3 = 1 / _2;

There wasn't any information on x2 so gimple-match wasn't able to reduce the
expression.

When I alter the definition of x2 to be "const unsigned int" instead of
"unsigned int", the code generated by gcc(trunk) and clang(trunk) are
equivalent.

[Bug bootstrap/101369] Bootstrap failure of gcc-12-20210704 on Cygwin

2021-07-07 Thread mckelvey at maskull dot com via Gcc-bugs

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

James McKelvey  changed:

   What|Removed |Added

 CC||mckelvey at maskull dot com

--- Comment #2 from James McKelvey  ---
(In reply to Andrew Pinski from comment #1)
> What binutils (as/ld) you are using?  Have you tried a newer version of
> binutils?
> This could be a binutils bug.

$ ld -v
GNU ld (GNU Binutils) 2.36.1

My Cygwin is up-to-date AFAIK.

[Bug bootstrap/101369] Bootstrap failure of gcc-12-20210704 on Cygwin

2021-07-07 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #1 from Andrew Pinski  ---
What binutils (as/ld) you are using?  Have you tried a newer version of
binutils?
This could be a binutils bug.

[Bug bootstrap/101369] New: Bootstrap failure of gcc-12-20210704 on Cygwin

2021-07-07 Thread mckelvey at maskull dot com via Gcc-bugs

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

Bug ID: 101369
   Summary: Bootstrap failure of gcc-12-20210704 on Cygwin
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mckelvey at maskull dot com
  Target Milestone: ---

Created attachment 51114
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51114&action=edit
Tarball of build.log and config.log

Recent gcc-11 and gcc-12 snapshots fail with:

/bin/sh: build/genmodes.exe: cannot execute binary file: Exec format error

Using gcc version 11.1.1 20210619:

$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-cygwin/11.1.1/lto-wrapper.exe
Target: x86_64-pc-cygwin
Configured with: ./configure --enable-languages=c,c++ --enable-threads=posix
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.1.1 20210619 (GCC)

(Fails the same way on the gcc-10 provided in Cygwin.)

$ uname -r
3.2.0(0.340/5/3)


More context of failure:

/home/McKelvey/gcc-12-20210704/host-x86_64-pc-cygwin/prev-gcc/xg++
-B/home/McKelvey/gcc-12-20210704/host-x86_64-pc-cygwin/prev-gcc/
-B/usr/local/x86_64-pc-cygwin/bin/ -nostdinc++
-B/home/McKelvey/gcc-12-20210704/prev-x86_64-pc-cygwin/libstdc++-v3/src/.libs
-B/home/McKelvey/gcc-12-20210704/prev-x86_64-pc-cygwin/libstdc++-v3/libsupc++/.libs

-I/home/McKelvey/gcc-12-20210704/prev-x86_64-pc-cygwin/libstdc++-v3/include/x86_64-pc-cygwin
 -I/home/McKelvey/gcc-12-20210704/prev-x86_64-pc-cygwin/libstdc++-v3/include 
-I/home/McKelvey/gcc-12-20210704/libstdc++-v3/libsupc++
-L/home/McKelvey/gcc-12-20210704/prev-x86_64-pc-cygwin/libstdc++-v3/src/.libs
-L/home/McKelvey/gcc-12-20210704/prev-x86_64-pc-cygwin/libstdc++-v3/libsupc++/.libs
  -g -O2 -fno-checking -gtoggle -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-error=format-diag -Wmissing-format-attribute
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Werror -fno-common  -DHAVE_CONFIG_H  -DGENERATOR_FILE
-fno-PIE -static-libstdc++ -static-libgcc -Wl,--stack,12582912 -no-pie -o
build/genmodes.exe \
build/genmodes.o build/errors.o
../../host-x86_64-pc-cygwin/libiberty/libiberty.a
build/genmodes.exe -h > tmp-modes.h
/bin/sh: build/genmodes.exe: cannot execute binary file: Exec format error
make[3]: *** [Makefile:2531: s-modes-h] Error 126
make[3]: Leaving directory
'/home/McKelvey/gcc-12-20210704/host-x86_64-pc-cygwin/gcc'
make[2]: *** [Makefile:4803: all-stage2-gcc] Error 2
make[2]: Leaving directory '/home/McKelvey/gcc-12-20210704'
make[1]: *** [Makefile:23134: stage2-bubble] Error 2
make[1]: Leaving directory '/home/McKelvey/gcc-12-20210704'
make: *** [Makefile:1000: all] Error 2

[Bug c++/101040] [11/12 Regression] Internal compiler error: in get_or_insert_ctor_field, at cp/constexpr.c:3571 since r11-7980-gc3d3bb0f03dbd025

2021-07-07 Thread jason at gcc dot gnu.org via Gcc-bugs

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #5 from Jason Merrill  ---
Fixed for 11.2/12.

[Bug c++/101072] [12 Regression] ICE in build_target_expr_with_type, at cp/tree.c:845 since r11-5681-gd9288bd28e24c755

2021-07-07 Thread jason at gcc dot gnu.org via Gcc-bugs

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

Jason Merrill  changed:

   What|Removed |Added

Summary|[11/12 Regression] ICE in   |[12 Regression] ICE in
   |build_target_expr_with_type |build_target_expr_with_type
   |, at cp/tree.c:845 since|, at cp/tree.c:845 since
   |r11-5681-gd9288bd28e24c755  |r11-5681-gd9288bd28e24c755

--- Comment #3 from Jason Merrill  ---
Fixed for 11.2 so far.

[Bug c++/101072] [11/12 Regression] ICE in build_target_expr_with_type, at cp/tree.c:845 since r11-5681-gd9288bd28e24c755

2021-07-07 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #2 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Jason Merrill
:

https://gcc.gnu.org/g:79663c962588e8c033ff39be39e938e2cc866e12

commit r11-8705-g79663c962588e8c033ff39be39e938e2cc866e12
Author: Jason Merrill 
Date:   Wed Jul 7 17:57:40 2021 -0400

Revert "c++: Improve init handling"

Apparently looking through these codes means that in a template, we end up
feeding a TARGET_EXPR to fold_non_dependent_expr, which should never
happen.  This is a broader issue, but for now let's just revert the change.

This reverts commit d9288bd28e24c755a7216311ee5247e7c88270a6.

PR c++/101072

gcc/cp/ChangeLog:

* decl.c (check_initializer): Don't look through STMT_EXPR and
BIND_EXPR.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/constexpr-empty14.C: Add -fno-elide-constructors.

[Bug c/101358] Warn when saving a pointer to an object with temporary lifetime

2021-07-07 Thread msebor at gcc dot gnu.org via Gcc-bugs

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Blocks||87403
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2021-07-07
   Severity|normal  |enhancement

--- Comment #1 from Martin Sebor  ---
Confirmed as an enhancement request for the front end.  The Gimplifier
introduces a local variable for the return value so the problem is no longer
detectable:

$ cat pr101358.c && /build/gcc-master/gcc/xgcc -B /build/gcc-master/gcc -S
-Wall -fdump-tree-original=/dev/stdout -fdump-tree-gimple=/dev/stdout
pr101358.c
typedef struct {
int x[1];
} foo;

foo f(void);

int g(void) {
int *p = f().x;
return *p;
}

;; Function g (null)
;; enabled by -tree-original


{
  int * p = (int *) &f ().x;

int * p = (int *) &f ().x;
  return *p;
}

int g ()
{
  struct 
{
  int x[1];
} D.1952;
  int D.1953;
  int * p;

  D.1952 = f ();
  p = &D.1952.x;
  D.1953 = *p;
  return D.1953;
}


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403
[Bug 87403] [Meta-bug] Issues that suggest a new warning

[Bug c/101364] [12 Regression] ICE: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in c_type_promotes_to, at c/c-typeck.c:278

2021-07-07 Thread msebor at gcc dot gnu.org via Gcc-bugs

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

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed||2021-07-07
 Ever confirmed|0   |1
   Keywords||error-recovery,
   ||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
 CC||msebor at gcc dot gnu.org

--- Comment #1 from Martin Sebor  ---
Confirmed.  Doesn't appear to be a regression (ICEs all the way to 4.1).

[Bug c++/101072] [11/12 Regression] ICE in build_target_expr_with_type, at cp/tree.c:845 since r11-5681-gd9288bd28e24c755

2021-07-07 Thread jason at gcc dot gnu.org via Gcc-bugs

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/101040] [11/12 Regression] Internal compiler error: in get_or_insert_ctor_field, at cp/constexpr.c:3571 since r11-7980-gc3d3bb0f03dbd025

2021-07-07 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Jason Merrill
:

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

commit r11-8704-g38fed4dfa25ac4894546f0589340ebfc5eef3bee
Author: Jason Merrill 
Date:   Thu Jun 24 17:32:02 2021 -0400

c++: constexpr aggr init of empty class [PR101040]

This is basically the aggregate initializer version of PR97566; as in that
bug, we are trying to initialize empty field 'obj' in 'single' when there's
no CONSTRUCTOR entry for the 'single' base class subobject of 'derived'. 
As
with that bug, the fix is to stop trying to add entries for empty fields,
this time in cxx_eval_bare_aggregate.

The change to the other function isn't necessary for this version of
the patch, but seems worthwhile for robustness anyway.

PR c++/101040
PR c++/97566

gcc/cp/ChangeLog:

* class.c (is_empty_field): Handle null argument.
* constexpr.c (cxx_eval_bare_aggregate): Discard initializer
for empty field.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/no_unique_address13.C: New test.

[Bug c++/97566] [[no_unique_address]] causes miscompiles when mixed with EBO in constexpr context

2021-07-07 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Jason Merrill
:

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

commit r11-8704-g38fed4dfa25ac4894546f0589340ebfc5eef3bee
Author: Jason Merrill 
Date:   Thu Jun 24 17:32:02 2021 -0400

c++: constexpr aggr init of empty class [PR101040]

This is basically the aggregate initializer version of PR97566; as in that
bug, we are trying to initialize empty field 'obj' in 'single' when there's
no CONSTRUCTOR entry for the 'single' base class subobject of 'derived'. 
As
with that bug, the fix is to stop trying to add entries for empty fields,
this time in cxx_eval_bare_aggregate.

The change to the other function isn't necessary for this version of
the patch, but seems worthwhile for robustness anyway.

PR c++/101040
PR c++/97566

gcc/cp/ChangeLog:

* class.c (is_empty_field): Handle null argument.
* constexpr.c (cxx_eval_bare_aggregate): Discard initializer
for empty field.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/no_unique_address13.C: New test.

[Bug tree-optimization/88443] [meta-bug] bogus/missing -Wstringop-overflow warnings

2021-07-07 Thread msebor at gcc dot gnu.org via Gcc-bugs

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

Bug 97027 Summary: missing warning on buffer overflow storing a larger scalar 
into a smaller array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97027

   What|Removed |Added

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

[Bug middle-end/97027] missing warning on buffer overflow storing a larger scalar into a smaller array

2021-07-07 Thread msebor at gcc dot gnu.org via Gcc-bugs

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Sebor  ---
Fixed in GCC 12.0.

[Bug tree-optimization/100137] [10/11 Regression] -Warray-bounds false positive on varying offset plus negative

2021-07-07 Thread msebor at gcc dot gnu.org via Gcc-bugs

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

Martin Sebor  changed:

   What|Removed |Added

  Known to fail|11.0|11.1.0
Summary|[10/11/12 Regression]   |[10/11 Regression]
   |-Warray-bounds false|-Warray-bounds false
   |positive on varying offset  |positive on varying offset
   |plus negative   |plus negative

--- Comment #7 from Martin Sebor  ---
Fixed in GCC 12.0.  The patch is too big to backport but a more targeted/modest
fix should be possible.

[Bug tree-optimization/99121] [9/10/11 Regression] ICE tree check: expected integer_cst, have var_decl in get_len, at tree.h:6037

2021-07-07 Thread msebor at gcc dot gnu.org via Gcc-bugs

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

Martin Sebor  changed:

   What|Removed |Added

  Known to fail|11.0|11.1.0
Summary|[9/10/11/12 Regression] ICE |[9/10/11 Regression] ICE
   |tree check: expected|tree check: expected
   |integer_cst, have var_decl  |integer_cst, have var_decl
   |in get_len, at tree.h:6037  |in get_len, at tree.h:6037

--- Comment #6 from Martin Sebor  ---
Fixed in GCC 12.0.  The committed patch is too intrusive to backport.

[Bug middle-end/97027] missing warning on buffer overflow storing a larger scalar into a smaller array

2021-07-07 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Martin Sebor :

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

commit r12-2132-ga110855667782dac7b674d3e328b253b3b3c919b
Author: Martin Sebor 
Date:   Wed Jul 7 14:05:25 2021 -0600

Correct handling of variable offset minus constant in -Warray-bounds
[PR100137]

Resolves:
PR tree-optimization/100137 - -Warray-bounds false positive on varying
offset plus negative
PR tree-optimization/99121 - ICE in -Warray-bounds on a multidimensional
PR tree-optimization/97027 - missing warning on buffer overflow storing a
larger scalar into a smaller array

gcc/ChangeLog:

PR tree-optimization/100137
PR tree-optimization/99121
PR tree-optimization/97027
* builtins.c (access_ref::access_ref): Also set offmax.
(access_ref::offset_in_range): Define new function.
(access_ref::add_offset): Set offmax.
(access_ref::inform_access): Handle access_none.
(handle_mem_ref): Clear ostype.
(compute_objsize_r): Handle ASSERT_EXPR.
* builtins.h (struct access_ref): Add offmax member.
* gimple-array-bounds.cc (array_bounds_checker::check_mem_ref): Use
compute_objsize() and simplify.

gcc/testsuite/ChangeLog:

PR tree-optimization/100137
PR tree-optimization/99121
PR tree-optimization/97027
* c-c++-common/Warray-bounds-3.c: Remove xfail
* c-c++-common/Warray-bounds-4.c: Add an expected warning.
* c-c++-common/Warray-bounds-9.c: New test.
* c-c++-common/Warray-bounds-10.c: New test.
* g++.dg/asan/asan_test.C: Suppress expected warnings.
* g++.dg/pr95768.C: Same.
* g++.dg/warn/Warray-bounds-10.C: Adjust text of expected messages.
* g++.dg/warn/Warray-bounds-11.C: Same.
* g++.dg/warn/Warray-bounds-12.C: Same.
* g++.dg/warn/Warray-bounds-13.C: Same.
* g++.dg/warn/Warray-bounds-17.C: Same.
* g++.dg/warn/Warray-bounds-20.C: Same.
* gcc.dg/Warray-bounds-29.c: Same.
* gcc.dg/Warray-bounds-30.c: Add xfail.
* gcc.dg/Warray-bounds-31.c: Adjust text of expected messages.
* gcc.dg/Warray-bounds-32.c: Same.
* gcc.dg/Warray-bounds-52.c: Same.
* gcc.dg/Warray-bounds-53.c: Same.
* gcc.dg/Warray-bounds-58.c: Remove xfail.
* gcc.dg/Warray-bounds-63.c: Adjust text of expected messages.
* gcc.dg/Warray-bounds-66.c: Same.
* gcc.dg/Warray-bounds-69.c: Same.
* gcc.dg/Wstringop-overflow-34.c: Same.
* gcc.dg/Wstringop-overflow-47.c: Same.
* gcc.dg/Wstringop-overflow-61.c: Same.
* gcc.dg/Warray-bounds-77.c: New test.
* gcc.dg/Warray-bounds-78.c: New test.
* gcc.dg/Warray-bounds-79.c: New test.

[Bug tree-optimization/99121] [9/10/11/12 Regression] ICE tree check: expected integer_cst, have var_decl in get_len, at tree.h:6037

2021-07-07 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Martin Sebor :

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

commit r12-2132-ga110855667782dac7b674d3e328b253b3b3c919b
Author: Martin Sebor 
Date:   Wed Jul 7 14:05:25 2021 -0600

Correct handling of variable offset minus constant in -Warray-bounds
[PR100137]

Resolves:
PR tree-optimization/100137 - -Warray-bounds false positive on varying
offset plus negative
PR tree-optimization/99121 - ICE in -Warray-bounds on a multidimensional
PR tree-optimization/97027 - missing warning on buffer overflow storing a
larger scalar into a smaller array

gcc/ChangeLog:

PR tree-optimization/100137
PR tree-optimization/99121
PR tree-optimization/97027
* builtins.c (access_ref::access_ref): Also set offmax.
(access_ref::offset_in_range): Define new function.
(access_ref::add_offset): Set offmax.
(access_ref::inform_access): Handle access_none.
(handle_mem_ref): Clear ostype.
(compute_objsize_r): Handle ASSERT_EXPR.
* builtins.h (struct access_ref): Add offmax member.
* gimple-array-bounds.cc (array_bounds_checker::check_mem_ref): Use
compute_objsize() and simplify.

gcc/testsuite/ChangeLog:

PR tree-optimization/100137
PR tree-optimization/99121
PR tree-optimization/97027
* c-c++-common/Warray-bounds-3.c: Remove xfail
* c-c++-common/Warray-bounds-4.c: Add an expected warning.
* c-c++-common/Warray-bounds-9.c: New test.
* c-c++-common/Warray-bounds-10.c: New test.
* g++.dg/asan/asan_test.C: Suppress expected warnings.
* g++.dg/pr95768.C: Same.
* g++.dg/warn/Warray-bounds-10.C: Adjust text of expected messages.
* g++.dg/warn/Warray-bounds-11.C: Same.
* g++.dg/warn/Warray-bounds-12.C: Same.
* g++.dg/warn/Warray-bounds-13.C: Same.
* g++.dg/warn/Warray-bounds-17.C: Same.
* g++.dg/warn/Warray-bounds-20.C: Same.
* gcc.dg/Warray-bounds-29.c: Same.
* gcc.dg/Warray-bounds-30.c: Add xfail.
* gcc.dg/Warray-bounds-31.c: Adjust text of expected messages.
* gcc.dg/Warray-bounds-32.c: Same.
* gcc.dg/Warray-bounds-52.c: Same.
* gcc.dg/Warray-bounds-53.c: Same.
* gcc.dg/Warray-bounds-58.c: Remove xfail.
* gcc.dg/Warray-bounds-63.c: Adjust text of expected messages.
* gcc.dg/Warray-bounds-66.c: Same.
* gcc.dg/Warray-bounds-69.c: Same.
* gcc.dg/Wstringop-overflow-34.c: Same.
* gcc.dg/Wstringop-overflow-47.c: Same.
* gcc.dg/Wstringop-overflow-61.c: Same.
* gcc.dg/Warray-bounds-77.c: New test.
* gcc.dg/Warray-bounds-78.c: New test.
* gcc.dg/Warray-bounds-79.c: New test.

[Bug tree-optimization/100137] [10/11/12 Regression] -Warray-bounds false positive on varying offset plus negative

2021-07-07 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Martin Sebor :

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

commit r12-2132-ga110855667782dac7b674d3e328b253b3b3c919b
Author: Martin Sebor 
Date:   Wed Jul 7 14:05:25 2021 -0600

Correct handling of variable offset minus constant in -Warray-bounds
[PR100137]

Resolves:
PR tree-optimization/100137 - -Warray-bounds false positive on varying
offset plus negative
PR tree-optimization/99121 - ICE in -Warray-bounds on a multidimensional
PR tree-optimization/97027 - missing warning on buffer overflow storing a
larger scalar into a smaller array

gcc/ChangeLog:

PR tree-optimization/100137
PR tree-optimization/99121
PR tree-optimization/97027
* builtins.c (access_ref::access_ref): Also set offmax.
(access_ref::offset_in_range): Define new function.
(access_ref::add_offset): Set offmax.
(access_ref::inform_access): Handle access_none.
(handle_mem_ref): Clear ostype.
(compute_objsize_r): Handle ASSERT_EXPR.
* builtins.h (struct access_ref): Add offmax member.
* gimple-array-bounds.cc (array_bounds_checker::check_mem_ref): Use
compute_objsize() and simplify.

gcc/testsuite/ChangeLog:

PR tree-optimization/100137
PR tree-optimization/99121
PR tree-optimization/97027
* c-c++-common/Warray-bounds-3.c: Remove xfail
* c-c++-common/Warray-bounds-4.c: Add an expected warning.
* c-c++-common/Warray-bounds-9.c: New test.
* c-c++-common/Warray-bounds-10.c: New test.
* g++.dg/asan/asan_test.C: Suppress expected warnings.
* g++.dg/pr95768.C: Same.
* g++.dg/warn/Warray-bounds-10.C: Adjust text of expected messages.
* g++.dg/warn/Warray-bounds-11.C: Same.
* g++.dg/warn/Warray-bounds-12.C: Same.
* g++.dg/warn/Warray-bounds-13.C: Same.
* g++.dg/warn/Warray-bounds-17.C: Same.
* g++.dg/warn/Warray-bounds-20.C: Same.
* gcc.dg/Warray-bounds-29.c: Same.
* gcc.dg/Warray-bounds-30.c: Add xfail.
* gcc.dg/Warray-bounds-31.c: Adjust text of expected messages.
* gcc.dg/Warray-bounds-32.c: Same.
* gcc.dg/Warray-bounds-52.c: Same.
* gcc.dg/Warray-bounds-53.c: Same.
* gcc.dg/Warray-bounds-58.c: Remove xfail.
* gcc.dg/Warray-bounds-63.c: Adjust text of expected messages.
* gcc.dg/Warray-bounds-66.c: Same.
* gcc.dg/Warray-bounds-69.c: Same.
* gcc.dg/Wstringop-overflow-34.c: Same.
* gcc.dg/Wstringop-overflow-47.c: Same.
* gcc.dg/Wstringop-overflow-61.c: Same.
* gcc.dg/Warray-bounds-77.c: New test.
* gcc.dg/Warray-bounds-78.c: New test.
* gcc.dg/Warray-bounds-79.c: New test.

[Bug target/101366] memset codegen for constant sized does not use SSE instructions

2021-07-07 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Target||x86_64-linux-gnu
   Last reconfirmed||2021-07-07
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
Summary|x86 memset codegen for  |memset codegen for constant
   |constant sized is   |sized does not use SSE
   |suboptimal  |instructions
   Severity|normal  |enhancement

--- Comment #1 from Andrew Pinski  ---
AARCH64 is fine:
TestStd(char*):
ldr b0, [x0, -1]
dup v0.16b, v0.b[0]
stp q0, q0, [x0]
stp q0, q0, [x0, 32]
ret

[Bug c++/101303] [9/10/11/12 Regression] ICE from modified lambda-generic-100362.C test case from bug 100362

2021-07-07 Thread ppalka at gcc dot gnu.org via Gcc-bugs

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

Patrick Palka  changed:

   What|Removed |Added

   Target Milestone|--- |9.5
Summary|ICE from modified   |[9/10/11/12 Regression] ICE
   |lambda-generic-100362.C |from modified
   |test case from bug 100362   |lambda-generic-100362.C
   ||test case from bug 100362
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||jason at gcc dot gnu.org,
   ||ppalka at gcc dot gnu.org
   Last reconfirmed||2021-07-07
  Known to fail||10.3.0, 11.1.0, 9.4.0

--- Comment #2 from Patrick Palka  ---
Confirmed, started with r8-4571.

[Bug c++/101368] -Wlogical-op and string comparison

2021-07-07 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug c++/101182] [concepts] ICE with ++ in non-template requires-expression

2021-07-07 Thread ppalka at gcc dot gnu.org via Gcc-bugs

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

Patrick Palka  changed:

   What|Removed |Added

 CC||gcc_report_187375@mailfence
   ||.com

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

[Bug c++/100423] Internal compiler error when evaluating a requires-expression referencing variables from outer scope in a function invocation.

2021-07-07 Thread ppalka at gcc dot gnu.org via Gcc-bugs

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #2 from Patrick Palka  ---
This is apparently a dup of the recently fixed PR101182.

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

[Bug c++/101368] -Wlogical-op and string comparison

2021-07-07 Thread mpolacek at gcc dot gnu.org via Gcc-bugs

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||diagnostic
 Ever confirmed|0   |1
 CC||mpolacek at gcc dot gnu.org
   Last reconfirmed||2021-07-07
 Status|UNCONFIRMED |NEW

[Bug c++/101368] New: -Wlogical-op and string comparison

2021-07-07 Thread arnaud02 at users dot sourceforge.net via Gcc-bugs

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

Bug ID: 101368
   Summary: -Wlogical-op and string comparison
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arnaud02 at users dot sourceforge.net
  Target Milestone: ---

Considering
#include 
bool f(int num) {
return num != 2 || num != 3;
}

bool g(std::string_view s) {
using namespace std::literals;
return s != "AA"sv || s != "BB"sv;
}

"g++ -std=c++17 -Wlogical-op -O2" emits:
: In function 'bool f(int)':
:3:21: warning: logical 'or' of collectively exhaustive tests is always
true [-Wlogical-op]
3 | return num != 2 || num != 3;
  |~^~~

g++ spots the defect in "f". It would be incredibly useful if the similar
defect was reported in "g".

In this case, the gcc x64 backend emits identical code for f and g:
f(int):
mov eax, 1
ret
g(std::basic_string_view >):
mov eax, 1
ret

[Bug c++/101367] [coroutines] destructor for capture in lambda temporary operand to co_yield expression called twice

2021-07-07 Thread noah at vectorized dot io via Gcc-bugs

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

--- Comment #1 from Noah Watkins  ---
In the reproducer there are no errors for:

generator f() {
co_yield resource{[]{}};
}

but `free(): invalid pointer` occurs for:

generator f() {
std::string s;
co_yield resource{[s]{}};
}

[Bug c++/101367] New: [coroutines] destructor for capture in lambda temporary operand to co_yield expression called twice

2021-07-07 Thread noah at vectorized dot io via Gcc-bugs

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

Bug ID: 101367
   Summary: [coroutines] destructor for capture in lambda
temporary operand to co_yield expression called twice
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: noah at vectorized dot io
  Target Milestone: ---

I'm observing an issue in which it appears that the destructor for a captured
object in a lambda which is passed as a temporary to a co_await/co_yield
expression is being called twice.

Here is a reproducer https://godbolt.org/z/8jrGx7qsT which is a slight
modification of the reproducer used in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95599 that was related to the
order of destructors in co_await/co_yield expressions.

In the reproducer I gave when the lambda temporary doesn't capture a
std::string value things work, but when it does you can see that gcc reports
`free(): invalid pointer`.

It also appears that https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100611 may be
closely related.

[Bug target/101363] many ICEs after r12-2089 on aarch64

2021-07-07 Thread msebor at gcc dot gnu.org via Gcc-bugs

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #9 from Martin Sebor  ---
Looks like r12-2100 fixes the ICE as well.  I don't see any other %K or %G in
these calls anywhere so let me resolve this as fixed.

[Bug target/101363] many ICEs after r12-2089 on aarch64

2021-07-07 Thread clyon at gcc dot gnu.org via Gcc-bugs

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

--- Comment #8 from Christophe Lyon  ---
Here are the options I see in gcc.log:
-O0  -march=armv8.2-a+bf16

[Bug target/101363] many ICEs after r12-2089 on aarch64

2021-07-07 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Martin Sebor :

https://gcc.gnu.org/g:06357071d0557c4f0e9b0a6dfc4d37f5680e34cc

commit r12-2100-g06357071d0557c4f0e9b0a6dfc4d37f5680e34cc
Author: Martin Sebor 
Date:   Wed Jul 7 08:49:13 2021 -0600

aarch64: Remove a vestigial %K [PR101363]

gcc/ChangeLog:
PR target/101363
* config/aarch64/aarch64.c (aarch64_simd_lane_bounds): Remove
a stray %K from error_at() missed in r12-2088.

[Bug target/101363] many ICEs after r12-2089 on aarch64

2021-07-07 Thread tnfchris at gcc dot gnu.org via Gcc-bugs

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

--- Comment #6 from Tamar Christina  ---
yeah, the ICEs don't make sense to me either, let me see if I can debug one of
them.

[Bug target/101363] many ICEs after r12-2089 on aarch64

2021-07-07 Thread msebor at gcc dot gnu.org via Gcc-bugs

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

--- Comment #5 from Martin Sebor  ---
No, you didn't.  I missed the one %K in aarch64.c.  Let me commit the fix below
to fix the bootstrap error.  I'm still not sure what the deal is with the tests
though.

diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 2753c852abd..f5b25a7f704 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -20128,7 +20128,8 @@ aarch64_simd_lane_bounds (rtx operand, HOST_WIDE_INT
low, HOST_WIDE_INT high,
   if (lane < low || lane >= high)
   {
 if (exp)
-  error ("%Klane %wd out of range %wd - %wd", exp, lane, low, high - 1);
+  error_at (EXPR_LOCATION (exp), "lane %wd out of range %wd - %wd",
+   lane, low, high - 1);
 else
   error ("lane %wd out of range %wd - %wd", lane, low, high - 1);
   }

[Bug target/101363] many ICEs after r12-2089 on aarch64

2021-07-07 Thread clyon at gcc dot gnu.org via Gcc-bugs

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

--- Comment #4 from Christophe Lyon  ---
(In reply to Martin Sebor from comment #2)
> I don't see the ICE with my cross-compiler and the stack trace doesn't
> correspond to the latest sources (there's no call to error() at
> gcc/config/aarch64/aarch64-builtins.c:1588; a call to error_at() that
> replaced the error() in r12-2088 is on line 1601) so it's hard for me to say
> what's going on.
> 
> What is the bootstrap problem?
> 
> Christophe, I thought you had successfully bootstrapped and tested the patch
> on aarch64?

I didn't bootstrap, I only run cross-builds, sorry.

And yes I did test the patches you provided on aarch64:
https://people.linaro.org/~christophe.lyon/cross-validation/gcc-test-patches/r12-1929-gf6bc9d9bddad7f9e3aad939bb6750770ac67f003-martin.patch/report-build-info.html

There were a few errors on aarch64/arm (which you already knew about), the full
patch I tested is:
https://people.linaro.org/~christophe.lyon/cross-validation/gcc-test-patches/r12-1929-gf6bc9d9bddad7f9e3aad939bb6750770ac67f003-martin.patch/commit.txt.
Did I mess something up? IIRC I tested patches 1+2+3, and it seems the problem
comes from patch 4?

[Bug target/101363] many ICEs after r12-2089 on aarch64

2021-07-07 Thread tnfchris at gcc dot gnu.org via Gcc-bugs

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

--- Comment #3 from Tamar Christina  ---
Bootstrap turns on -Werror so the warning generated in
gcc/config/aarch64/aarch64.c at aarch64_simd_lane_bounds for the use of `%K`
becomes fatal.

[Bug target/101177] sh3: internal compiler error: Illegal instruction

2021-07-07 Thread segher at gcc dot gnu.org via Gcc-bugs

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #4 from Segher Boessenkool  ---
(In reply to Harold Gutch from comment #1)
> I cannot claim to understand the details of this patch, but note that in the
> second part of the diff the condition gets inverted.

Yes, that looks like a clear mistake.  I don't know why I did that, perhaps
at first I flipped the control flow there?  Who knows.  Sorry for it anyway!

[Bug target/101363] many ICEs after r12-2089 on aarch64

2021-07-07 Thread msebor at gcc dot gnu.org via Gcc-bugs

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

--- Comment #2 from Martin Sebor  ---
I don't see the ICE with my cross-compiler and the stack trace doesn't
correspond to the latest sources (there's no call to error() at
gcc/config/aarch64/aarch64-builtins.c:1588; a call to error_at() that replaced
the error() in r12-2088 is on line 1601) so it's hard for me to say what's
going on.

What is the bootstrap problem?

Christophe, I thought you had successfully bootstrapped and tested the patch on
aarch64?

[Bug rtl-optimization/101366] New: x86 memset codegen for constant sized is suboptimal

2021-07-07 Thread kutdanila at yandex dot ru via Gcc-bugs

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

Bug ID: 101366
   Summary: x86 memset codegen for constant sized is suboptimal
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kutdanila at yandex dot ru
  Target Milestone: ---

https://gcc.godbolt.org/z/hP99MYMEG

void Test(char* dst) {
__m128i pattern = _mm_set1_epi8(dst[-1]);
for (int i = 0; i < 4; i++) {
_mm_loadu_si128(reinterpret_cast<__m128i*>(dst + 16 * i), pattern);
}
}

vs

void TestStd(char* s) {
memset(s, s[-1], 64);
}


-O3 -msse4.2

Test(char*):
movzbl  -1(%rdi), %eax
pxor%xmm1, %xmm1
movd%eax, %xmm0
pshufb  %xmm1, %xmm0
movups  %xmm0, (%rdi)
movups  %xmm0, 16(%rdi)
movups  %xmm0, 32(%rdi)
movups  %xmm0, 48(%rdi)
ret
TestStd(char*):
movabsq $72340172838076673, %rdx
movzbl  -1(%rdi), %eax
movq%rax, %rcx
imulq   %rdx, %rcx
mulq%rdx
addq%rcx, %rdx
movq%rax, (%rdi)
movq%rdx, 8(%rdi)
movq%rax, 16(%rdi)
movq%rdx, 24(%rdi)
movq%rax, 32(%rdi)
movq%rdx, 40(%rdi)
movq%rax, 48(%rdi)
movq%rdx, 56(%rdi)
ret

[Bug c/101365] New: [12 Regression] ICE: in fold_convert_loc, at fold-const.c:243

2021-07-07 Thread anbu1024.me at gmail dot com via Gcc-bugs

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

Bug ID: 101365
   Summary: [12 Regression] ICE: in fold_convert_loc, at
fold-const.c:243
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anbu1024.me at gmail dot com
  Target Milestone: ---

$ cat test.c 

int var_0;

void func_0()
{
  var_0++;
}

int var_0[] = {1};



$ gcc-sp12 --version
gcc (GCC) 12.0.0 20210704 (experimental)
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-sp12 test.c 
test.c:9:5: error: conflicting types for ‘var_0’; have ‘int[]’
9 | int var_0[] = {1};
  | ^
test.c:2:5: note: previous declaration of ‘var_0’ with type ‘int’
2 | int var_0;
  | ^
test.c: In function ‘func_0’:
test.c:6:8: internal compiler error: in fold_convert_loc, at fold-const.c:2431
6 |   var_0++;
  |   ~^~
0x6d5399 fold_convert_loc(unsigned int, tree_node*, tree_node*)
../../gcc-12-20210704/gcc/fold-const.c:2431
0xbddc1e gimplify_self_mod_expr(tree_node**, gimple**, gimple**, bool,
tree_node*)
../../gcc-12-20210704/gcc/gimplify.c:3204
0xbc77b8 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-12-20210704/gcc/gimplify.c:14140
0xbcb3f6 gimplify_stmt(tree_node**, gimple**)
../../gcc-12-20210704/gcc/gimplify.c:6869
0xbcbb4d gimplify_bind_expr
../../gcc-12-20210704/gcc/gimplify.c:1426
0xbc96ae gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-12-20210704/gcc/gimplify.c:14411
0xbe0f59 gimplify_stmt(tree_node**, gimple**)
../../gcc-12-20210704/gcc/gimplify.c:6869
0xbe0f59 gimplify_body(tree_node*, bool)
../../gcc-12-20210704/gcc/gimplify.c:15442
0xbe139d gimplify_function_tree(tree_node*)
../../gcc-12-20210704/gcc/gimplify.c:15596
0xa202e7 cgraph_node::analyze()
../../gcc-12-20210704/gcc/cgraphunit.c:670
0xa22d17 analyze_functions
../../gcc-12-20210704/gcc/cgraphunit.c:1234
0xa239bd symbol_table::finalize_compilation_unit()
../../gcc-12-20210704/gcc/cgraphunit.c:2508
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.



$ gcc-sp11 --version
gcc (GCC) 11.1.1 20210703
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-sp11 test.c 
test.c:9:5: error: conflicting types for ‘var_0’; have ‘int[]’
9 | int var_0[] = {1};
  | ^
test.c:2:5: note: previous declaration of ‘var_0’ with type ‘int’
2 | int var_0;
  | ^
test.c:6: confused by earlier errors, bailing out

[Bug tree-optimization/101229] [11 Regression] ICE on valid code with -O3 only: in vect_get_vec_defs_for_operand, at tree-vect-stmts.c:1450

2021-07-07 Thread rguenth at gcc dot gnu.org via Gcc-bugs

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/101025] [11 Regression] wrong code at -O3 on x86_64-linux-gnu

2021-07-07 Thread rguenth at gcc dot gnu.org via Gcc-bugs

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||11.1.1
 Resolution|--- |FIXED

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

[Bug c/101364] New: [12 Regression] ICE: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in c_type_promotes_to, at c/c-typeck.c:278

2021-07-07 Thread anbu1024.me at gmail dot com via Gcc-bugs

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

Bug ID: 101364
   Summary: [12 Regression] ICE: tree check: expected class
‘type’, have ‘exceptional’ (error_mark) in
c_type_promotes_to, at c/c-typeck.c:278
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anbu1024.me at gmail dot com
  Target Milestone: ---

$ cat test.c 

void fruit();

struct Apple{
  int apple[4];
};

void fruit(
struct Apple a,
int b[x],
unsigned char c)
{
  return 0;
}



$ gcc-sp12 --version 
gcc (GCC) 12.0.0 20210704 (experimental)
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-sp12 test.c 
test.c:10:11: error: ‘x’ undeclared here (not in a function)
   10 | int b[x],
  |   ^
test.c:8:6: error: conflicting types for ‘fruit’; have ‘void(struct Apple, 
,  unsigned char)’
8 | void fruit(
  |  ^
test.c:12:1: internal compiler error: tree check: expected class ‘type’, have
‘exceptional’ (error_mark) in c_type_promotes_to, at c/c-typeck.c:278
   12 | {
  | ^
0x7ad81c tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc-12-20210704/gcc/tree.c:8734
0x668e82 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
../../gcc-12-20210704/gcc/tree.h:3496
0x668e82 c_type_promotes_to(tree_node*)
../../gcc-12-20210704/gcc/c/c-typeck.c:278
0x874d07 diagnose_arglist_conflict
../../gcc-12-20210704/gcc/c/c-decl.c:1826
0x874d07 diagnose_mismatched_decls
../../gcc-12-20210704/gcc/c/c-decl.c:2134
0x8767e4 duplicate_decls
../../gcc-12-20210704/gcc/c/c-decl.c:2956
0x8791a9 pushdecl(tree_node*)
../../gcc-12-20210704/gcc/c/c-decl.c:3149
0x88c359 start_function(c_declspecs*, c_declarator*, tree_node*)
../../gcc-12-20210704/gcc/c/c-decl.c:9642
0x8ea09e c_parser_declaration_or_fndef
../../gcc-12-20210704/gcc/c/c-parser.c:2440
0x8f2983 c_parser_external_declaration
../../gcc-12-20210704/gcc/c/c-parser.c:1777
0x8f33c9 c_parser_translation_unit
../../gcc-12-20210704/gcc/c/c-parser.c:1650
0x8f33c9 c_parse_file()
../../gcc-12-20210704/gcc/c/c-parser.c:22121
0x952ead c_common_parse_file()
../../gcc-12-20210704/gcc/c-family/c-opts.c:1219
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.



$ gcc-sp11 --version
gcc (GCC) 11.1.1 20210703
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-sp11 test.c 
test.c:10:11: error: ‘x’ undeclared here (not in a function)
   10 | int b[x],
  |   ^
test.c:8:6: error: conflicting types for ‘fruit’; have ‘void(struct Apple, 
,  unsigned char)’
8 | void fruit(
  |  ^
test.c:12:1: note: an argument type that has a default promotion cannot match
an empty parameter name list declaration
   12 | {
  | ^
test.c:2:6: note: previous declaration of ‘fruit’ with type ‘void()’
2 | void fruit();
  |  ^
test.c: In function ‘fruit’:
test.c:13:10: warning: ‘return’ with a value, in function returning void
   13 |   return 0;
  |  ^
test.c:8:6: note: declared here
8 | void fruit(
  |  ^

[Bug tree-optimization/101229] [11 Regression] ICE on valid code with -O3 only: in vect_get_vec_defs_for_operand, at tree-vect-stmts.c:1450

2021-07-07 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Richard Biener
:

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

commit r11-8700-gbd5391d309efc8533deb04dd0b5a7b8072592c1d
Author: Richard Biener 
Date:   Mon Jun 28 11:05:46 2021 +0200

tree-optimization/101229 - fix vectorizer SLP hybrid detection with PHIs

This fixes the missing handling of PHIs in gimple_walk_op which causes
the new vectorizer SLP hybrid detection scheme to fail.

2021-06-28  Richard Biener  

PR tree-optimization/101229
* gimple-walk.c (gimple_walk_op): Handle PHIs.

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

(cherry picked from commit f80c4eaca0805bc9e68ed944519519c3dd1c12e1)

[Bug tree-optimization/101280] [12 Regression] TSVC s231 slower with -Ofast -march=znver1 since r12-1836-g0ad9d88a3d7170b3

2021-07-07 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Richard Biener
:

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

commit r11-8699-ge46ec6e243c704f0858d16af380a7d9c36fc4244
Author: Richard Biener 
Date:   Wed Jun 23 09:59:28 2021 +0200

tree-optimization/101173 - fix interchange dependence checking

This adjusts the loop interchange dependence checking to properly
guard all dependence checks with DDR_REVERSED_P or its inverse.

2021-07-07  Richard Biener  

PR tree-optimization/101173
PR tree-optimization/101280
* gimple-loop-interchange.cc
(tree_loop_interchange::valid_data_dependences): Properly
guard all dependence checks with DDR_REVERSED_P or its
inverse.

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

[Bug tree-optimization/101173] [9/10/11 Regression] wrong code at -O3 on x86_64-linux-gnu

2021-07-07 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

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

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

commit r11-8699-ge46ec6e243c704f0858d16af380a7d9c36fc4244
Author: Richard Biener 
Date:   Wed Jun 23 09:59:28 2021 +0200

tree-optimization/101173 - fix interchange dependence checking

This adjusts the loop interchange dependence checking to properly
guard all dependence checks with DDR_REVERSED_P or its inverse.

2021-07-07  Richard Biener  

PR tree-optimization/101173
PR tree-optimization/101280
* gimple-loop-interchange.cc
(tree_loop_interchange::valid_data_dependences): Properly
guard all dependence checks with DDR_REVERSED_P or its
inverse.

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

[Bug middle-end/101156] [9/10/11 Regression] ICE: ‘verify_gimple’ failed, verify_gimple_in_seq(gimple*)

2021-07-07 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Richard Biener
:

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

commit r11-8698-g9e1173009150086a927a6f0e001fd04c5cac54cb
Author: Richard Biener 
Date:   Tue Jun 22 12:13:44 2021 +0200

middle-end/101156 - remove not working optimization in gimplification

This removes a premature and not working optimization from the
gimplifier.  When gimplification is requested not to produce a SSA
name we try to avoid generating a copy when we did so anyway but
instead replace the LHS of its definition.  But that only works in
case there are no uses of the SSA name already which is something
we cannot easily check, so the following removes said optimization.

Statistics on the whole bootstrap shows we hit this optimization
only for libiberty/cp-demangle.c and overall we have 21652112
gimplifications where just 240 copies are elided.  Preserving
the optimization would require scanning the original expression
and the pre and post sequences for SSA names and uses, that seems
excessive to avoid these 240 copies.

2021-06-22  Richard Biener  

PR middle-end/101156
* gimplify.c (gimplify_expr): Remove premature incorrect
optimization.

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

(cherry picked from commit b4e21c80462682c4e6e5e487fe87107b27f8b4bd)

[Bug tree-optimization/100923] [9/10/11 Regression] wrong code at -O2 and above on x86_64-linux-gnu

2021-07-07 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:2afae9ff16c45747e8e9c2ad477d28ee159fb1f7

commit r11-8697-g2afae9ff16c45747e8e9c2ad477d28ee159fb1f7
Author: Richard Biener 
Date:   Tue Jun 8 12:52:12 2021 +0200

tree-optimization/100923 - fix alias-ref construction wrt availability

This PR shows that building an ao_ref from value-numbers is prone to
expose bogus contextual alias info to the oracle.  The following makes
sure to construct ao_refs from SSA names available at the program point
only.

On the way it modifies the awkward valueize_refs[_1] API.

2021-06-08  Richard Biener  

PR tree-optimization/100923
* tree-ssa-sccvn.c (valueize_refs_1): Take a pointer to
the operand vector to be valueized.
(valueize_refs): Likewise.
(valueize_shared_reference_ops_from_ref): Adjust.
(valueize_shared_reference_ops_from_call): Likewise.
(vn_reference_lookup_3): Likewise.
(vn_reference_lookup_pieces): Likewise.  Re-valueize
with honoring availability when we are about to create
the ao_ref and valueized before.
(vn_reference_lookup): Likewise.
(vn_reference_insert_pieces): Adjust.

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

(cherry picked from commit 7a56d3d3e99cc77ad8a6a674870c814da6225675)

[Bug tree-optimization/101088] [12 Regression] ICE in sm_seq_valid_bb, at tree-ssa-loop-im.c:2383

2021-07-07 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:91fc9610464281bb28e3c6529399fdcfb57fa812

commit r11-8696-g91fc9610464281bb28e3c6529399fdcfb57fa812
Author: Richard Biener 
Date:   Wed Jun 16 09:49:18 2021 +0200

tree-optimization/101088 - fix SM invalidation issue

When we face a sm_ord vs sm_unord for the same ref during
store sequence merging we assert that the ref is already marked
unsupported.  But it can be that it will only be marked so
during the ongoing merging so instead of asserting mark it here.

Also apply some optimization to not waste resources to search
for already unsupported refs.

2021-06-16  Richard Biener  

PR tree-optimization/101088
* tree-ssa-loop-im.c (sm_seq_valid_bb): Only look for
supported refs on edges.  Do not assert same ref but
different kind stores are unsuported but mark them so.
(hoist_memory_references): Only look for supported refs
on exits.

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

(cherry picked from commit 43fc4234ad3d9302d3460385b6fdb5e3f59b6986)

[Bug tree-optimization/101025] [11 Regression] wrong code at -O3 on x86_64-linux-gnu

2021-07-07 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #9 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Richard Biener
:

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

commit r11-8695-g8a1defec135c51531e7a0fd5085c47fca10cb147
Author: Richard Biener 
Date:   Fri Jun 11 12:06:08 2021 +0200

tree-optimization/101025 - fix store-motion dependence checking

This plugs a hole in store-motion where it fails to perform dependence
checking on conditionally executed but not store-motioned refs.

2021-06-11  Richard Biener  

PR tree-optimization/101025
* tree-ssa-loop-im.c (sm_seq_valid_bb): Make sure to process
all refs that require dependence checking.

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

(cherry picked from commit b8b80b8aa3d9a7abbcb59b651ea5e84c2ea12d0b)

[Bug target/101363] many ICEs after r12-2089 on aarch64

2021-07-07 Thread tnfchris at gcc dot gnu.org via Gcc-bugs

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

Tamar Christina  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-07-07
 CC||tnfchris at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Tamar Christina  ---
It also broke the bootstrap.

[Bug tree-optimization/99728] code pessimization when using wrapper classes around SIMD types

2021-07-07 Thread rguenth at gcc dot gnu.org via Gcc-bugs

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

Richard Biener  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #17 from Richard Biener  ---
So we have

  val$v_62 = *d_28(D).lam1D.32701.vD.32579;
  *d_28(D).lam1D.32701 = *d_28(D).lam2D.32702;
  *d_28(D).lam2D.32702.vD.32579 = _34;

I believe that the SRA pass has the best analysis capabilities to eventually
decompose aggregate copies into register pieces (with cost considerations).
In particular it knows (but without flow info) what kind of types
sub-accesses use.  Since we want the aggregate copy replaced with pieces
that match the rest of the accesses (here because of LIMs restrictions).

In particular we'd like to use 'vector double' typed accesses here, sth
the middle-end usually avoids for block-copies which aggregate copies
are to the middle-end.

That said, it would be _much_ easier if the frontend with its language specific
semantic knowledge could avoid doing block-copies for such simple wrappers
and instead perform (recursively) memberwise copy (for single member
aggregates).

Of course the simple fix in source is to add

  Tvsimple &operator=(const Tvsimple &other) { v = other.v; return *this;}

producing optimal code.  Jason - would you consider this premature
"optimization" in the C++ frontend?  It doesn't seem that there's
a operator= synthesized, instead we directly emit

   lam2) >;

from

d.lam1 = d.lam2;

from build_over_call which has a series of optimizations at

  else if (DECL_ASSIGNMENT_OPERATOR_P (fn)
   && DECL_OVERLOADED_OPERATOR_IS (fn, NOP_EXPR)
   && trivial_fn_p (fn))
{
...
  if (is_really_empty_class (type, /*ignore_vptr*/true))
{
  /* Avoid copying empty classes.  */
  val = build2 (COMPOUND_EXPR, type, arg, to);
  suppress_warning (val, OPT_Wunused);
}
  else if (tree_int_cst_equal (TYPE_SIZE (type), TYPE_SIZE (as_base)))
{
  if (is_std_init_list (type)
  && conv_binds_ref_to_prvalue (convs[1]))
warning_at (loc, OPT_Winit_list_lifetime,
"assignment from temporary % does "
"not extend the lifetime of the underlying array");
  arg = cp_build_fold_indirect_ref (arg);
  val = build2 (MODIFY_EXPR, TREE_TYPE (to), to, arg);

so we handle empty classes, maybe we can also handle single data-member
classes (not sure how to exactly test for this - walking TYPE_FIELDs
repeatedly for each considered assignment would be slow I guess).

[Bug testsuite/101321] gcc.dg/debug/btf/btf-bitfields-3.c fail on arm-eabi

2021-07-07 Thread clyon at gcc dot gnu.org via Gcc-bugs

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

--- Comment #7 from Christophe Lyon  ---

> PS: I let -fno-short-enums remain in the testcase for now. If the patch
> fixes the issue while removing -fno-short-enums, the testcase can be updated
> to not have -fno-short-enums anymore.

I just checked, and committed the removal of -fno-short-enums as it is not
necessary anymore.
Thanks

[Bug testsuite/101321] gcc.dg/debug/btf/btf-bitfields-3.c fail on arm-eabi

2021-07-07 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Christophe Lyon :

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

commit r12-2099-ge8073c04536214c856a6340fea23d676cd7436af
Author: Christophe Lyon 
Date:   Wed Jul 7 12:42:34 2021 +

testsuite: gcc.dg/debug/btf/btf-bitfields-3.c remove -fno-short-enums PR
debug/101321

After r12-2094, -fno-short-enums is non longer necessary.

2021-07-07  Christophe Lyon  

PR debug/101321
gcc/testsuite/
* gcc.dg/debug/btf/btf-bitfields-3.c: Remove -fno-short-enums.

[Bug target/101325] [12 Regression] arm: Wrong code with MVE vcmpeqq intrinsic since r12-671-gd083fbf72

2021-07-07 Thread rearnsha at gcc dot gnu.org via Gcc-bugs

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

--- Comment #11 from Richard Earnshaw  ---
(In reply to Christophe Lyon from comment #10)
> This was introduced by my change at r12-671 in mve.md:
> -;; [vcmpneq_])
> +;; [vcmpneq_, vcmpcsq_, vcmpeqq_, vcmpgeq_, vcmpgtq_, vcmphiq_, vcmpleq_,
> vcmpltq_])
>  ;;
> -(define_insn "mve_vcmpneq_"
> +(define_insn "mve_vcmpq_"
>[
> (set (match_operand:HI 0 "vpr_register_operand" "=Up")
> -   (unspec:HI [(match_operand:MVE_2 1 "s_register_operand" "w")
> -   (match_operand:MVE_2 2 "s_register_operand" "w")]
> -VCMPNEQ))
> +   (MVE_COMPARISONS:HI (match_operand:MVE_2 1 "s_register_operand" "w")
> +   (match_operand:MVE_2 2 "s_register_operand" "w")))
> +  ]
> +  "TARGET_HAVE_MVE"
> +  "vcmp.%#  , %q1, %q2"
> +  [(set_attr "type" "mve_move")
> +])
> 
> So should that use MVE_COMPARISONS:MVE_2, and somehow include a conversion
> from MVE_2 modes into HI for vpr.p0 in the pattern?

Thinking about it some more, it might be the use of HI on the 'eq' that is
incorrect.  If the result were a vector, then the construct might have more
meaning.

I think you'll need to look at how predicates are handled in the aarch64 SVE
code.  For example, you might need to introduce the concept of
VECTOR_BOOL_MODEs.

[Bug tree-optimization/98176] Loop invariant memory could not be hoisted when nonpure_call in loop body

2021-07-07 Thread rguenth at gcc dot gnu.org via Gcc-bugs

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed|2020-12-08 00:00:00 |2021-7-7

--- Comment #8 from Richard Biener  ---
I've just pushed the change g:9f34b780b0461ec7b2b2defe96e44ab616ea2aa3 which
allows store-motion to handle some unanalyzed refs (but not yet calls because I
wanted a testcase showing usefulness).

I'm failing to reproduce with the sincos example since sincos is transformed
to __builtin_cexpi for me.  When using

float frexpf(float x, int *exp);
float foo(int *x, int n, float tx)
{
float ret[n];
int exp; 
for (int i = 0; i < n; i++)
  ret[0] += frexpf (tx, &exp);
return ret[0];
}

as alternate example we are not able to move ret[] as it seems we consider
the access to not always happen since it seems we consider frexpf possibly
not returning because it's a non-pure call:

/* Fills ALWAYS_EXECUTED_IN information for basic blocks, i.e.
   for each such basic block bb records the outermost loop for that execution
   of its header implies execution of bb.  */

static void
fill_always_executed_in (void)
{
  basic_block bb;
  class loop *loop;

  auto_sbitmap contains_call (last_basic_block_for_fn (cfun));
  bitmap_clear (contains_call);
  FOR_EACH_BB_FN (bb, cfun)
{
  gimple_stmt_iterator gsi;
  for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi); gsi_next (&gsi))
{
  if (nonpure_call_p (gsi_stmt (gsi)))
break;
}

  if (!gsi_end_p (gsi))
bitmap_set_bit (contains_call, bb->index);
}

  for (loop = current_loops->tree_root->inner; loop; loop = loop->next)
fill_always_executed_in_1 (loop, contains_call);
}

so I don't think it buys us anything to handle calls yet.  sincos would
also be considered as possibly not returning.

I don't think we have any IPA analysis helping us here (yet).

[Bug target/101325] [12 Regression] arm: Wrong code with MVE vcmpeqq intrinsic since r12-671-gd083fbf72

2021-07-07 Thread clyon at gcc dot gnu.org via Gcc-bugs

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

--- Comment #10 from Christophe Lyon  ---
This was introduced by my change at r12-671 in mve.md:
-;; [vcmpneq_])
+;; [vcmpneq_, vcmpcsq_, vcmpeqq_, vcmpgeq_, vcmpgtq_, vcmphiq_, vcmpleq_,
vcmpltq_])
 ;;
-(define_insn "mve_vcmpneq_"
+(define_insn "mve_vcmpq_"
   [
(set (match_operand:HI 0 "vpr_register_operand" "=Up")
-   (unspec:HI [(match_operand:MVE_2 1 "s_register_operand" "w")
-   (match_operand:MVE_2 2 "s_register_operand" "w")]
-VCMPNEQ))
+   (MVE_COMPARISONS:HI (match_operand:MVE_2 1 "s_register_operand" "w")
+   (match_operand:MVE_2 2 "s_register_operand" "w")))
+  ]
+  "TARGET_HAVE_MVE"
+  "vcmp.%#  , %q1, %q2"
+  [(set_attr "type" "mve_move")
+])

So should that use MVE_COMPARISONS:MVE_2, and somehow include a conversion from
MVE_2 modes into HI for vpr.p0 in the pattern?

[Bug tree-optimization/99728] code pessimization when using wrapper classes around SIMD types

2021-07-07 Thread rguenth at gcc dot gnu.org via Gcc-bugs

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

--- Comment #16 from Richard Biener  ---
This has the situation improved but the aggregate copy and one dependent store
are still not moved (so not fixed).

[Bug tree-optimization/66610] Aggregate assignment prevents store-motion

2021-07-07 Thread rguenth at gcc dot gnu.org via Gcc-bugs

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

Richard Biener  changed:

   What|Removed |Added

 Blocks||99728

--- Comment #4 from Richard Biener  ---
PR99728 is similar, but I think that store-motion itself is the wrong place to
"tear apart" aggregate assignments.  Taking the first example from the
testcase:

/* This loop doesn't get optimized away.  */
void
loop2_using_struct_assignment (int num_iters, struct value *arr)
{
  int i;
  for (i = 0; i < num_iters; i++)
{
  arr[0].union_field.int_field = i;
  arr[0].type_code = TYPE_CODE_INT;
  arr[1] = arr[0];
}
}

the aggregate assignment could be sunk out of the loop but then this moves
loads later which store-motion does not do in general.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99728
[Bug 99728] code pessimization when using wrapper classes around SIMD types

[Bug tree-optimization/47575] store-motion removes global stores from endless loops

2021-07-07 Thread rguenth at gcc dot gnu.org via Gcc-bugs

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #3 from Richard Biener  ---
Indeed, nothing to see here.

[Bug tree-optimization/34195] missed optimization with store motion (vectorizer)

2021-07-07 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

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

https://gcc.gnu.org/g:005f31a0370cf35e332db9415a0ff538320bcddc

commit r12-2098-g005f31a0370cf35e332db9415a0ff538320bcddc
Author: Richard Biener 
Date:   Wed Jul 7 13:46:48 2021 +0200

tree-optimization/34195 - testcase for fixed vectorization

This adds a testcase for an old fixed PR.

2021-07-07  Richard Biener  

PR tree-optimization/34195
* gcc.dg/vect/pr34195.c: New testcase.

[Bug tree-optimization/99728] code pessimization when using wrapper classes around SIMD types

2021-07-07 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

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

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

commit r12-2097-g9f34b780b0461ec7b2b2defe96e44ab616ea2aa3
Author: Richard Biener 
Date:   Wed Jul 7 11:41:03 2021 +0200

tree-optimization/99728 - improve LIM for loops with aggregate copies

This improves LIM by recording aggregate copies for disambiguation
purposes instead of as UNANALYZABLE_MEM which will prevent any
invariant or store motion across it.  This allows four of the six
references in the loop of the testcase to be promoted.

2021-07-07  Richard Biener  

PR tree-optimization/99728
* tree-ssa-loop-im.c (gather_mem_refs_stmt): Record
aggregate copies.
(mem_refs_may_alias_p): Add assert we handled aggregate
copies elsewhere.
(sm_seq_valid_bb): Give up when running into aggregate copies.
(ref_indep_loop_p): Handle aggregate copies as never
being invariant themselves but allow other refs to be
disambiguated against them.
(can_sm_ref_p): Do not try to apply store-motion to aggregate
copies.

* g++.dg/opt/pr99728.C: New testcase.

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

2021-07-07 Thread rguenth at gcc dot gnu.org via Gcc-bugs

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

Bug 34195 Summary: missed optimization with store motion (vectorizer)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34195

   What|Removed |Added

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

[Bug tree-optimization/34195] missed optimization with store motion (vectorizer)

2021-07-07 Thread rguenth at gcc dot gnu.org via Gcc-bugs

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #7 from Richard Biener  ---
We apply store-motion to the inner loop (if you disable unrolling with a pragma
or -fdisable-tree-cunrolli or by incrasing M).  We apply outer loop
vectorization with the inner loop not unrolled and loop vectorization when it
is unrolled.

So IMHO nothing left to fix here (whatever the exact desire was ;)).

I'll add a testcase.

[Bug target/101325] [12 Regression] arm: Wrong code with MVE vcmpeqq intrinsic since r12-671-gd083fbf72

2021-07-07 Thread rearnsha at gcc dot gnu.org via Gcc-bugs

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

--- Comment #9 from Richard Earnshaw  ---
(insn 7 4 8 2 (set (reg:HI 117)
(eq:HI (reg:V16QI 119)
(reg:V16QI 120))) {mve_vcmpeqq_v16qi}
 (expr_list:REG_DEAD (reg:V16QI 120)
(expr_list:REG_DEAD (reg:V16QI 119)
(nil

This is wrong.  EQ has a result of 0 or 1, regardless of the mode.

[Bug tree-optimization/56360] Loop invariant motion by default can introduce speculative store

2021-07-07 Thread rguenth at gcc dot gnu.org via Gcc-bugs

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |FIXED
  Known to work||10.1.0
 Status|NEW |RESOLVED

--- Comment #8 from Richard Biener  ---
Fixed in GCC 10 where there now is (default off) -fallow-store-data-races.

[Bug target/101325] [12 Regression] arm: Wrong code with MVE vcmpeqq intrinsic since r12-671-gd083fbf72

2021-07-07 Thread clyon at gcc dot gnu.org via Gcc-bugs

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

--- Comment #8 from Christophe Lyon  ---
Indeed, it's what happens in try_combine():
i2src = subst (i2src, pc_rtx, pc_rtx, 0, 0, 0);

converts i2src
(zero_extend:SI (reg:HI 117))
into:
(and:SI (subreg:SI (reg:HI 117) 0)
(const_int 1 [0x1]))

[Bug target/101325] [12 Regression] arm: Wrong code with MVE vcmpeqq intrinsic since r12-671-gd083fbf72

2021-07-07 Thread clyon at gcc dot gnu.org via Gcc-bugs

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

--- Comment #7 from Christophe Lyon  ---
Before the patch:
Trying 8 -> 14:
8: r113:SI=zero_extend(r117:HI)
  REG_DEAD r117:HI
   14: r0:SI=r113:SI
  REG_DEAD r113:SI
Successfully matched this instruction:
(set (reg/i:SI 0 r0)
(zero_extend:SI (reg:HI 117)))
allowing combination of insns 8 and 14
original costs 4 + 2 = 6
replacement cost 4
deferring deletion of insn with uid = 8.
modifying insn i314: r0:SI=zero_extend(r117:HI)
  REG_DEAD r117:HI
deferring rescan insn with uid = 14.

After:
Trying 8 -> 14:
8: r113:SI=zero_extend(r117:HI)
  REG_DEAD r117:HI
   14: r0:SI=r113:SI
  REG_DEAD r113:SI
Successfully matched this instruction:
(set (reg/i:SI 0 r0)
(and:SI (subreg:SI (reg:HI 117) 0)
(const_int 1 [0x1])))
allowing combination of insns 8 and 14
original costs 4 + 2 = 6
replacement cost 4
deferring deletion of insn with uid = 8.
modifying insn i314: r0:SI=r117:HI#0&0x1
  REG_DEAD r117:HI
deferring rescan insn with uid = 14.

So with the same inputs, combine makes a different decision, I guess that's
because it has some knowledge that reg:HI 117 is the result of a comparison
rather than an unspec.

[Bug target/101363] New: many ICEs after r12-2089 on aarch64

2021-07-07 Thread clyon at gcc dot gnu.org via Gcc-bugs

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

Bug ID: 101363
   Summary: many ICEs after r12-2089 on aarch64
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

I've noticed lots of regressions likely after r12-2089. For instance:

FAIL: gcc.target/aarch64/advsimd-intrinsics/bfdot-3.c   -O0  (test for excess
errors)
Excess errors:
during RTL pass: expand
in pp_format, at pretty-print.c:1478
0x1bc39f8 pp_format(pretty_printer*, text_info*)
/gcc/pretty-print.c:1478
0x1ba6245 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
/gcc/diagnostic.c:1331
0x1ba6727 diagnostic_impl
/gcc/diagnostic.c:1493
0x1ba6fc6 error(char const*, ...)
/gcc/diagnostic.c:1789
0x12d4f5c aarch64_simd_expand_args
/gcc/config/aarch64/aarch64-builtins.c:1588
0x12d557c aarch64_simd_expand_builtin(int, tree_node*, rtx_def*)
/gcc/config/aarch64/aarch64-builtins.c:1739
0x12d5fac aarch64_general_expand_builtin(unsigned int, tree_node*, rtx_def*,
int)
/gcc/config/aarch64/aarch64-builtins.c:2179
0x882c54 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
/gcc/builtins.c:9807
0xa0a09b expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/gcc/expr.c:11440
0xa185c9 store_expr(tree_node*, rtx_def*, int, bool, bool)
/gcc/expr.c:5997
0xa1a7d5 expand_assignment(tree_node*, tree_node*, bool)
/gcc/expr.c:5729
0x8bbe3e expand_call_stmt
/gcc/cfgexpand.c:2844
0x8bbe3e expand_gimple_stmt_1
/gcc/cfgexpand.c:3877
0x8bbe3e expand_gimple_stmt
/gcc/cfgexpand.c:4041
0x8bd204 expand_gimple_basic_block
/gcc/cfgexpand.c:6083
0x8bf831 execute
/gcc/cfgexpand.c:6809

[Bug target/101351] ICE on valid code with -O1: in lra_split_hard_reg_for, at lra-assigns.c:1837

2021-07-07 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords|ice-on-valid-code   |ice-on-invalid-code
 Ever confirmed|0   |1
   Last reconfirmed||2021-07-07
 Status|UNCONFIRMED |NEW

--- Comment #2 from Andrew Pinski  ---
(In reply to Richard Biener from comment #1)
> I think this is invalid code but hard to diagnose (_Complex long doesn't fit
> "rax", not sure if we're supposed to allocate a register pair here
> magically).

The register pair part is done by ix86_hard_regno_nregs which has:
  if (COMPLEX_MODE_P (mode))
return 2;

I noticed in VALID_INT_MODE_P accepts C*Imode's.  I don't know if it that is
expected or not.


Note on aarch64 if I use x1 instead of eax, I get:
error: register specified for 'a' isn't suitable for data type

Because the aarch64 backend rejects the complex integer modes.

I really doubt the complex integer modes show up in RTL these days anyways.
The only thing to take care of is making sure the ABI is the same for complex
int arguments.

[Bug target/101325] [12 Regression] arm: Wrong code with MVE vcmpeqq intrinsic since r12-671-gd083fbf72

2021-07-07 Thread clyon at gcc dot gnu.org via Gcc-bugs

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

--- Comment #6 from Christophe Lyon  ---
Before r12-671 before combine we have:
(insn 7 4 8 2 (set (reg:HI 117)
(unspec:HI [
(reg/v:V16QI 115 [ v ])
(reg/v:V16QI 116 [ w ])
] VCMPEQQ_S)) "arm_mve.h":4210:10 3228 {mve_vcmpeqq_v16qi}
 (expr_list:REG_DEAD (reg/v:V16QI 116 [ w ])
(expr_list:REG_DEAD (reg/v:V16QI 115 [ v ])
(nil
(insn 8 7 14 2 (set (reg:SI 113 [ _5 ])
(zero_extend:SI (reg:HI 117))) "arm_mve.h":4210:10 1019
{*thumb2_zero_extendhisi2_v6}
 (expr_list:REG_DEAD (reg:HI 117)
(nil)))

After r12-671, we have:
(insn 7 4 8 2 (set (reg:HI 117)
(eq:HI (reg/v:V16QI 115 [ v ])
(reg/v:V16QI 116 [ w ]))) "arm_mve.h":4210:10 3173
{mve_vcmpeqq_v16qi}
 (expr_list:REG_DEAD (reg/v:V16QI 116 [ w ])
(expr_list:REG_DEAD (reg/v:V16QI 115 [ v ])
(nil
(insn 8 7 14 2 (set (reg:SI 113 [ _5 ])
(zero_extend:SI (reg:HI 117))) "arm_mve.h":4210:10 1019
{*thumb2_zero_extendhisi2_v6}
 (expr_list:REG_DEAD (reg:HI 117)
(nil)))

[Bug target/101296] Addition of x86 addsub SLP patterned slowed down 433.milc by 12% on znver2 with -Ofast -flto

2021-07-07 Thread rguenth at gcc dot gnu.org via Gcc-bugs

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

--- Comment #6 from Richard Biener  ---
Btw, there's no effect of the change visible on Haswell.

[Bug target/101325] [12 Regression] arm: Wrong code with MVE vcmpeqq intrinsic since r12-671-gd083fbf72

2021-07-07 Thread clyon at gcc dot gnu.org via Gcc-bugs

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

--- Comment #5 from Christophe Lyon  ---
Before the patch, combine says:
allowing combination of insns 8 and 14
original costs 4 + 2 = 6
replacement cost 4
deferring deletion of insn with uid = 8.
modifying insn i314: r0:SI=zero_extend(r117:HI)
  REG_DEAD r117:HI
deferring rescan insn with uid = 14.
starting the processing of deferred insns
rescanning insn with uid = 7.
rescanning insn with uid = 14.
ending the processing of deferred insns

After the patch:
allowing combination of insns 8 and 14
original costs 4 + 2 = 6
replacement cost 4
deferring deletion of insn with uid = 8.
modifying insn i314: r0:SI=r117:HI#0&0x1
  REG_DEAD r117:HI
deferring rescan insn with uid = 14.
starting the processing of deferred insns
rescanning insn with uid = 7.
rescanning insn with uid = 14.
ending the processing of deferred insns

[Bug target/101325] [12 Regression] arm: Wrong code with MVE vcmpeqq intrinsic since r12-671-gd083fbf72

2021-07-07 Thread clyon at gcc dot gnu.org via Gcc-bugs

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

Christophe Lyon  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2021-07-07
 Ever confirmed|0   |1

--- Comment #4 from Christophe Lyon  ---
Before r12-671, in combine we have:
(insn 7 4 8 2 (set (reg:HI 117)
(unspec:HI [
(reg:V16QI 119)
(reg:V16QI 120)
] VCMPEQQ_S)) {mve_vcmpeqq_v16qi}
 (expr_list:REG_DEAD (reg:V16QI 120)
(expr_list:REG_DEAD (reg:V16QI 119)
(nil
(note 8 7 14 2 NOTE_INSN_DELETED)
(insn 14 8 15 2 (set (reg/i:SI 0 r0)
(zero_extend:SI (reg:HI 117))) "pr101325.c":7:1 1019
{*thumb2_zero_extendhisi2_v6}
 (expr_list:REG_DEAD (reg:HI 117)
(nil)))


After the patch:
(insn 7 4 8 2 (set (reg:HI 117)
(eq:HI (reg:V16QI 119)
(reg:V16QI 120))) {mve_vcmpeqq_v16qi}
 (expr_list:REG_DEAD (reg:V16QI 120)
(expr_list:REG_DEAD (reg:V16QI 119)
(nil
(note 8 7 14 2 NOTE_INSN_DELETED)
(insn 14 8 15 2 (set (reg/i:SI 0 r0)
(and:SI (subreg:SI (reg:HI 117) 0)
(const_int 1 [0x1]))) "pr101325.c":7:1 90 {*arm_andsi3_insn}
 (expr_list:REG_DEAD (reg:HI 117)
(nil)))

[Bug ipa/101362] can_change_signature does not consider 'used' attribute

2021-07-07 Thread rguenth at gcc dot gnu.org via Gcc-bugs

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

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org
 Target||i?86-*-*

--- Comment #1 from Richard Biener  ---
In particular can_change_signature is one of the keys for ix86_function_regparm
to use local calling conventions on i?86

[Bug ipa/101362] New: can_change_signature does not consider 'used' attribute

2021-07-07 Thread rguenth at gcc dot gnu.org via Gcc-bugs

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

Bug ID: 101362
   Summary: can_change_signature does not consider 'used'
attribute
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

For

static int __attribute__((used)) fn (int x)
{
  return x;
}

int main() { return fn (0); }

compute_fn_summary will end up with ->can_change_signature = true; but I think
'used' implies the function will be used in ways not visible to GCC.

89 matches

Mail list logo