[Bug target/107540] New: [13 Regression] ICE: SIGSEGV in memory_operand(rtx_def*, machine_mode) (recog.cc:1834) with -flive-range-shrinkage

2022-11-06 Thread zsojka at seznam dot cz via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107540

Bug ID: 107540
   Summary: [13 Regression] ICE: SIGSEGV in
memory_operand(rtx_def*, machine_mode) (recog.cc:1834)
with -flive-range-shrinkage
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  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 53838
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53838&action=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -flive-range-shrinkage -mavx testcase.c -wrapper
valgrind,-q
==15852== Invalid read of size 2
==15852==at 0x1328AAA: memory_operand(rtx_def*, machine_mode)
(recog.cc:1834)
==15852==by 0x1C0A905: get_attr_memory(rtx_insn*) (i386.md:5270)
==15852==by 0x202F5B7: insn_default_latency_generic(rtx_insn*)
(i386.md:19121)
==15852==by 0x2485921: insn_sched_cost(rtx_insn*) (haifa-sched.cc:1421)
==15852==by 0x2489FE2: dep_cost_1(_dep*, unsigned int)
(haifa-sched.cc:1474)
==15852==by 0x248BCD1: dep_cost (haifa-sched.cc:1510)
==15852==by 0x248BCD1: priority(rtx_insn*, bool) [clone .part.0]
(haifa-sched.cc:1661)
==15852==by 0x248C5D2: priority (haifa-sched.cc:1593)
==15852==by 0x248C5D2: set_priorities(rtx_insn*, rtx_insn*)
(haifa-sched.cc:7166)
==15852==by 0x137D6A2: compute_priorities() (sched-rgn.cc:3025)
==15852==by 0x13803D5: schedule_region (sched-rgn.cc:3139)
==15852==by 0x13803D5: schedule_insns() [clone .part.0] (sched-rgn.cc:3527)
==15852==by 0x13809FB: schedule_insns (sched-rgn.cc:3513)
==15852==by 0x13809FB: rest_of_handle_live_range_shrinkage
(sched-rgn.cc:3715)
==15852==by 0x13809FB: (anonymous
namespace)::pass_live_range_shrinkage::execute(function*) (sched-rgn.cc:3802)
==15852==by 0x12D855A: execute_one_pass(opt_pass*) (passes.cc:2644)
==15852==by 0x12D8E3F: execute_pass_list_1(opt_pass*) (passes.cc:2753)
==15852==  Address 0xabababababababab is not stack'd, malloc'd or (recently)
free'd
==15852== 
during RTL pass: lr_shrinkage
testcase.c: In function 'foo':
testcase.c:9:1: internal compiler error: Segmentation fault
9 | }
  | ^
0x13e1bbf crash_signal
/repo/gcc-trunk/gcc/toplev.cc:314
0x1328aaa memory_operand(rtx_def*, machine_mode)
/repo/gcc-trunk/gcc/recog.cc:1834
0x1c0a905 get_attr_memory(rtx_insn*)
/repo/gcc-trunk/gcc/config/i386/i386.md:5270
0x202f5b7 insn_default_latency_generic(rtx_insn*)
/repo/gcc-trunk/gcc/config/i386/i386.md:19121
0x2485921 insn_sched_cost(rtx_insn*)
/repo/gcc-trunk/gcc/haifa-sched.cc:1421
0x2489fe2 dep_cost_1(_dep*, unsigned int)
/repo/gcc-trunk/gcc/haifa-sched.cc:1474
0x248bcd1 dep_cost(_dep*)
/repo/gcc-trunk/gcc/haifa-sched.cc:1510
0x248bcd1 priority
/repo/gcc-trunk/gcc/haifa-sched.cc:1661
0x248c5d2 priority
/repo/gcc-trunk/gcc/haifa-sched.cc:1593
0x248c5d2 set_priorities(rtx_insn*, rtx_insn*)
/repo/gcc-trunk/gcc/haifa-sched.cc:7166
0x137d6a2 compute_priorities()
/repo/gcc-trunk/gcc/sched-rgn.cc:3025
0x13803d5 schedule_region
/repo/gcc-trunk/gcc/sched-rgn.cc:3139
0x13803d5 schedule_insns()
/repo/gcc-trunk/gcc/sched-rgn.cc:3527
0x13809fb schedule_insns()
/repo/gcc-trunk/gcc/sched-rgn.cc:3513
0x13809fb rest_of_handle_live_range_shrinkage
/repo/gcc-trunk/gcc/sched-rgn.cc:3715
0x13809fb execute
/repo/gcc-trunk/gcc/sched-rgn.cc:3802
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.


$ 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-r13-3702-20221106155652-g3628025ac60-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/13.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-r13-3702-20221106155652-g3628025ac60-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20221104 (experimental) (GCC)

[Bug tree-optimization/107541] New: wrong code at -O1, -O2 and -O3 on x86_64-linux-gnu

2022-11-06 Thread zhendong.su at inf dot ethz.ch via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107541

Bug ID: 107541
   Summary: wrong code at -O1, -O2 and -O3 on x86_64-linux-gnu
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

This appears to be a recent regression; 12.2 compiles it correctly. 

Compiler Explorer: https://godbolt.org/z/6nq8jxn57

[661] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
--with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20221104 (experimental) [master r13-3701-g07b0096e5b6] (GCC) 
[662] % 
[662] % gcctk -O0 small.c; ./a.out
[663] % 
[663] % gcctk -O1 small.c
[664] % ./a.out
Aborted
[665] % 
[665] % cat small.c
unsigned char a = 1;
char b, e;
long c;
short d;
int main() {
  a = ~(1 && a);
  c = ~((~a / 8 | -2) & 11007578330939886389LLU);
  e = -c;
  d = ~c / e;
  if (d < 2000)
__builtin_abort();
  return 0;
}

[Bug libstdc++/39796] cin/cout/cerr constructors should run at high priority when possible

2022-11-06 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39796

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

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

commit r13-3707-g4e4e3ffd10f53ef71696bc728ab40258751a2df4
Author: Patrick Palka 
Date:   Sun Nov 6 11:16:00 2022 -0500

libstdc++: Move stream initialization into compiled library [PR44952]

This patch moves the static object for constructing the standard streams
out from  and into the compiled library on systems that support
init priorities.  This'll mean  no longer introduces a separate
global constructor in each TU that includes it.

We can do this only if the init_priority attribute is supported because
we need a way to ensure the stream initialization runs first before any
user global initializer, particularly when linking with a static
libstdc++.a.

PR libstdc++/44952
PR libstdc++/39796
PR libstdc++/98108

libstdc++-v3/ChangeLog:

* include/std/iostream (__ioinit): No longer define here if
the init_priority attribute is usable.
* src/c++98/ios_init.cc (__ioinit): Define here instead if
init_priority is usable, via ...
* src/c++98/ios_base_init.h: ... this new file.

[Bug libstdc++/44952] #include implies global constructor.

2022-11-06 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44952

--- Comment #18 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

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

commit r13-3707-g4e4e3ffd10f53ef71696bc728ab40258751a2df4
Author: Patrick Palka 
Date:   Sun Nov 6 11:16:00 2022 -0500

libstdc++: Move stream initialization into compiled library [PR44952]

This patch moves the static object for constructing the standard streams
out from  and into the compiled library on systems that support
init priorities.  This'll mean  no longer introduces a separate
global constructor in each TU that includes it.

We can do this only if the init_priority attribute is supported because
we need a way to ensure the stream initialization runs first before any
user global initializer, particularly when linking with a static
libstdc++.a.

PR libstdc++/44952
PR libstdc++/39796
PR libstdc++/98108

libstdc++-v3/ChangeLog:

* include/std/iostream (__ioinit): No longer define here if
the init_priority attribute is usable.
* src/c++98/ios_init.cc (__ioinit): Define here instead if
init_priority is usable, via ...
* src/c++98/ios_base_init.h: ... this new file.

[Bug libstdc++/98108] Broken Schwarz counter for iostreams initialization

2022-11-06 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98108

--- Comment #10 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

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

commit r13-3707-g4e4e3ffd10f53ef71696bc728ab40258751a2df4
Author: Patrick Palka 
Date:   Sun Nov 6 11:16:00 2022 -0500

libstdc++: Move stream initialization into compiled library [PR44952]

This patch moves the static object for constructing the standard streams
out from  and into the compiled library on systems that support
init priorities.  This'll mean  no longer introduces a separate
global constructor in each TU that includes it.

We can do this only if the init_priority attribute is supported because
we need a way to ensure the stream initialization runs first before any
user global initializer, particularly when linking with a static
libstdc++.a.

PR libstdc++/44952
PR libstdc++/39796
PR libstdc++/98108

libstdc++-v3/ChangeLog:

* include/std/iostream (__ioinit): No longer define here if
the init_priority attribute is usable.
* src/c++98/ios_init.cc (__ioinit): Define here instead if
init_priority is usable, via ...
* src/c++98/ios_base_init.h: ... this new file.

[Bug c++/98052] Allocation with new and deallocation with std::allocator should result in an error

2022-11-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98052

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug c++/95797] Can std::allocator.deallocate newed pointer during constant evaluation

2022-11-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95797

Andrew Pinski  changed:

   What|Removed |Added

 CC||src at andyf dot de

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

[Bug tree-optimization/107541] [13 Regression] wrong code at -O1, -O2 and -O3 on x86_64-linux-gnu

2022-11-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107541

Andrew Pinski  changed:

   What|Removed |Added

 Target||x86_64-linux-gnu
   Target Milestone|--- |13.0
Summary|wrong code at -O1, -O2 and  |[13 Regression] wrong code
   |-O3 on x86_64-linux-gnu |at -O1, -O2 and -O3 on
   ||x86_64-linux-gnu

[Bug tree-optimization/107541] [13 Regression] wrong code at -O1, -O2 and -O3 on x86_64-linux-gnu

2022-11-06 Thread franckbehaghel_gcc at protonmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107541

Franck Behaghel  changed:

   What|Removed |Added

 CC||franckbehaghel_gcc@protonma
   ||il.com

--- Comment #1 from Franck Behaghel  
---
Created attachment 53839
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53839&action=edit
reduce testcase

Confirmed on master ( 3ad2167bbac8ae83b1e91305b105ab5287bdac55 )

It might be related with integer promotion on char type with ~ and / .
A reduce testcase.

gccmain.cpp -O2   ; ./a.out ;echo "*" ;  gcc  main.cpp ; ./a.out
b: 128
*
b: 129

[Bug tree-optimization/107541] [13 Regression] wrong code at -O1, -O2 and -O3 on x86_64-linux-gnu

2022-11-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107541

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2022-11-06
 Ever confirmed|0   |1
   Keywords||needs-bisection
 Status|UNCONFIRMED |NEW

--- Comment #2 from Andrew Pinski  ---
ccp3 does:
Visiting statement:
# RANGE [irange] short int [1909, 1909][31001, 31001] NONZERO 0x7fff
_19 = (short intD.25) _18;
which is likely CONSTANT
Match-and-simplified (short int) _18 to 1909
Lattice value changed to CONSTANT 1909.  Adding SSA edges to worklist.
marking stmt to be not simulated again

That is due to rhs side of the divisor being a constant ...
Someone else has to look into why it is one.

[Bug target/107540] [13 Regression] ICE: SIGSEGV in memory_operand(rtx_def*, machine_mode) (recog.cc:1834) with -flive-range-shrinkage

2022-11-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107540

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug c++/107542] New: ICE in spaceship_comp_cat, at cp/method.cc:1055

2022-11-06 Thread danakj at orodu dot net via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107542

Bug ID: 107542
   Summary: ICE in spaceship_comp_cat, at cp/method.cc:1055
   Product: gcc
   Version: 12.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danakj at orodu dot net
  Target Milestone: ---

Repro: https://godbolt.org/z/KPfsn8hPf

Reproduces in 12.2 and trunk on Godbolt.org.

Output:
: In substitution of 'template  requires  Ord constexpr auto operator<=>(const S&, const S&) [with T =
int; U = char]':
:6:11:   required from here
:6:11: internal compiler error: in spaceship_comp_cat, at
cp/method.cc:1055
6 | { lhs <=> rhs } -> std::same_as;
  |   ^~~
0x2393c6e internal_error(char const*, ...)
???:0
0xaa9b58 fancy_abort(char const*, int, char const*)
???:0
0xd4a507 cp_build_binary_op(op_location_t const&, tree_code, tree_node*,
tree_node*, int)
???:0
0xadb22c build_new_op(op_location_t const&, tree_code, int, tree_node*,
tree_node*, tree_node*, tree_node*, tree_node**, int)
???:0
0xd3b412 build_x_binary_op(op_location_t const&, tree_code, tree_node*,
tree_code, tree_node*, tree_code, tree_node*, tree_node**, int)
???:0
0xb25576 tsubst_requires_expr(tree_node*, tree_node*, int, tree_node*)
???:0
0xb27052 constraints_satisfied_p(tree_node*, tree_node*)
???:0
0xcdd84a fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, conversion**, bool,
bool)
???:0
0xadaefe build_new_op(op_location_t const&, tree_code, int, tree_node*,
tree_node*, tree_node*, tree_node*, tree_node**, int)
???:0
0xd3b412 build_x_binary_op(op_location_t const&, tree_code, tree_node*,
tree_code, tree_node*, tree_code, tree_node*, tree_node**, int)
???:0
0xb25576 tsubst_requires_expr(tree_node*, tree_node*, int, tree_node*)
???:0
0xb2715f evaluate_concept_check(tree_node*)
???:0
0xb18962 maybe_constant_value(tree_node*, tree_node*, bool)
???:0
0xcfdb3f finish_unary_op_expr(unsigned int, tree_code, cp_expr, int)
???:0
0xc872a7 c_parse_file()
???:0
0xdd0579 c_common_parse_file()
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/107542] ICE in spaceship_comp_cat, at cp/method.cc:1055

2022-11-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107542

--- Comment #1 from Andrew Pinski  ---
Created attachment 53840
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53840&action=edit
testcase

Note please next time also attach the testcase (or put it inline) and not just
link against godbolt.

[Bug c++/107542] ICE in spaceship_comp_cat, at cp/method.cc:1055

2022-11-06 Thread danakj at orodu dot net via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107542

--- Comment #2 from danakj at orodu dot net ---
The same thing works okay with operator== instead of operator<=>

https://godbolt.org/z/qnPx3bYT4

```
#include 
#include 

template 
concept Ord = requires(const Lhs& lhs, const Rhs& rhs) {
{ lhs <=> rhs } -> std::same_as;
};

template 
concept Eq = requires(const Lhs& lhs, const Rhs& rhs) {
{ lhs == rhs } -> std::same_as;
};

template 
struct S {
T* p;
};

template 
requires(Eq)
bool operator==(const S& l, const S& r) {
return l.p == r.p;
}

template 
requires(Ord)
constexpr inline auto operator<=>(const S& l, const S& r) noexcept {
return l.p <=> r.p;
}

static_assert(Ord, S>);  // Works.
// static_assert(!Ord, S>>);  // ICE.

static_assert(Eq, S>);  // Works.
static_assert(!Eq, S>);  // Works.
```

[Bug c++/107542] ICE in spaceship_comp_cat, at cp/method.cc:1055

2022-11-06 Thread danakj at orodu dot net via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107542

--- Comment #3 from danakj at orodu dot net ---
> Note please next time also attach the testcase (or put it inline) and not 
> just link against godbolt.

Will do, thanks for attaching it for me.

[Bug c++/107543] New: c-family/c-cppbuiltin.cc: Undefine __GNUC_STDC_INLINE__ in C++ mode?

2022-11-06 Thread i at maskray dot me via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107543

Bug ID: 107543
   Summary: c-family/c-cppbuiltin.cc: Undefine
__GNUC_STDC_INLINE__ in C++ mode?
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: i at maskray dot me
  Target Milestone: ---

-fgnu89-inline / C99 / C++  inline modes are all different. For C++, perhaps
neither 
__GNUC_STDC_INLINE__ nor __GNUC_GNUC_INLINE__ should be defined.

% g++ -dM -E -xc++ /dev/null | grep __GNUC_STDC_INLINE__
#define __GNUC_STDC_INLINE__ 1


gcc/doc/cpp.texi does not talk about C++

@item __GNUC_STDC_INLINE__
GCC defines this macro if functions declared @code{inline} will be
handled according to the ISO C99 or later standards.  Object files will contain
externally visible definitions of all functions declared @code{extern
inline}.  They will not contain definitions of any functions declared
@code{inline} without @code{extern}.

If this macro is defined, GCC supports the @code{gnu_inline} function
attribute as a way to always get the gnu90 behavior.


Side note: there is "warning: command-line option ‘-fgnu89-inline’ is valid for
C/ObjC but not for C++" but  __attribute__((gnu_inline)) is usable in C++ mode
and has strange codegen behaviors.

[Bug c++/107544] New: Friended struct with concept gives different output in clang/gcc/MSVC

2022-11-06 Thread danakj at orodu dot net via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107544

Bug ID: 107544
   Summary: Friended struct with concept gives different output in
clang/gcc/MSVC
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danakj at orodu dot net
  Target Milestone: ---

I don't know which compiler is right, but all three give a different output. So
I will report it here, as the GCC result looks wrong and exposes private data.

https://godbolt.org/z/7Pq3eWhc8

```
#include 
#include 
#include 

template 
concept HasTag = requires {
T::Tag;
requires std::same_as;
};

template 
struct check_tag final {
static constexpr bool value()
requires(!HasTag)
{
return false;
}

static constexpr bool value()
requires(HasTag)
{
return T::Tag;
};
};

struct S {
   private:
template 
friend struct check_tag;
static constexpr bool Tag = true;
};

int main() {
std::cout << HasTag << "\n";
std::cout << check_tag::value() << "\n";
}
```

Clang output (the concept sees private data if used in friend):
0
1

GCC output (the concept always sees private data):
1
1

MSVC output (the concept never sees private data):
0
0

[Bug c++/107544] Friended struct with concept gives different output in clang/gcc/MSVC

2022-11-06 Thread danakj at orodu dot net via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107544

--- Comment #1 from danakj at orodu dot net ---
Clang report: https://github.com/llvm/llvm-project/issues/58833

[Bug c++/107544] Friended struct with concept gives different output in clang/gcc/MSVC

2022-11-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107544

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
I think this is a dup of bug 104111.
Specifically there is an issue reported against the C++ standard too:
https://cplusplus.github.io/CWG/issues/2589.html

--- Comment #3 from Andrew Pinski  ---
I think this is a dup of bug 104111.
Specifically there is an issue reported against the C++ standard too:
https://cplusplus.github.io/CWG/issues/2589.html

[Bug c++/107544] Friended struct with concept gives different output in clang/gcc/MSVC

2022-11-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107544

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
I think this is a dup of bug 104111.
Specifically there is an issue reported against the C++ standard too:
https://cplusplus.github.io/CWG/issues/2589.html

--- Comment #3 from Andrew Pinski  ---
I think this is a dup of bug 104111.
Specifically there is an issue reported against the C++ standard too:
https://cplusplus.github.io/CWG/issues/2589.html

[Bug tree-optimization/107541] [13 Regression] wrong code at -O1, -O2 and -O3 on x86_64-linux-gnu

2022-11-06 Thread franckbehaghel_gcc at protonmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107541

--- Comment #3 from Franck Behaghel  
---
Not sure that would help but disabling those pair of passes :
 -fdisable-tree-ccp3 -fdisable-tree-ccp4
  or -fdisable-tree-ccp4  -fdisable-tree-dom2
  or -fdisable-tree-dom2 -fdisable-tree-dom3

removes the issue.

[Bug c++/107544] Friended struct with concept gives different output in clang/gcc/MSVC

2022-11-06 Thread danakj at orodu dot net via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107544

--- Comment #4 from danakj at orodu dot net ---
It looks related but I am not sure it is a duplicate. In this case, the concept
is being used from a non-friend context first and still accessing the private
data. In that bug, they demonstrate clang having the same output, but here
clang and GCC differ as well.

```
std::cout << HasTag << "\n";
std::cout << check_tag::value() << "\n";
```

Reordering these statements does not change the output.

[Bug target/107540] [13 Regression] ICE: SIGSEGV in memory_operand(rtx_def*, machine_mode) (recog.cc:1834) with -flive-range-shrinkage

2022-11-06 Thread crazylht at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107540

Hongtao.liu  changed:

   What|Removed |Added

 CC||crazylht at gmail dot com

--- Comment #1 from Hongtao.liu  ---
Guess hit some insn attribute automatical detection assert. I'll take a look.

[Bug target/107540] [13 Regression] ICE: SIGSEGV in memory_operand(rtx_def*, machine_mode) (recog.cc:1834) with -flive-range-shrinkage

2022-11-06 Thread crazylht at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107540

--- Comment #2 from Hongtao.liu  ---
diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index fa93ae7bf21..4e8463addc3 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -12203,7 +12203,7 @@ (define_insn "avx512f_movddup512"
 (const_int 6) (const_int 14)])))]
   "TARGET_AVX512F"
   "vmovddup\t{%1, %0|%0, %1}"
-  [(set_attr "type" "sselog")
+  [(set_attr "type" "sselog1")
(set_attr "prefix" "evex")
(set_attr "mode" "V8DF")])

@@ -12234,7 +12234,7 @@ (define_insn "avx_movddup256"
 (const_int 2) (const_int 6)])))]
   "TARGET_AVX && "
   "vmovddup\t{%1, %0|%0, %1}"
-  [(set_attr "type" "sselog")
+  [(set_attr "type" "sselog1")
(set_attr "prefix" "")
(set_attr "mode" "V4DF")])



Testing.

[Bug c++/107545] New: __is_abstract intrinsic fails to compile on incomplete unions

2022-11-06 Thread eric41293 at comcast dot net via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107545

Bug ID: 107545
   Summary: __is_abstract intrinsic fails to compile on incomplete
unions
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric41293 at comcast dot net
  Target Milestone: ---

[meta.unary.props] states for std::is_abstract, "If T is a non-union class
type, T shall be a complete type." A union cannot have virtual functions, so an
incomplete union can safely be determined not to be abstract. Thus, is_abstract
is required to work for incomplete unions. However, the __is_abstract
intrinsic, and hence also std::is_abstract, generates a compiler error in this
case:

$ g++ --version
g++ (Ubuntu 12.1.0-2ubuntu1~22.04) 12.1.0
Copyright (C) 2022 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.

$ cat > is_abstract.cpp
union U;
bool b = __is_abstract(U);
$ g++ is_abstract.cpp
is_abstract.cpp:2:25: error: invalid use of incomplete type ‘union U’
2 | bool b = __is_abstract(U);
  | ^
is_abstract.cpp:1:7: note: forward declaration of ‘union U’
1 | union U;
  |   ^

[Bug c++/107545] __is_abstract intrinsic fails to compile on incomplete unions

2022-11-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107545

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Fixed in GCC 13 most likely by the patch which fixed 106838.

[Bug tree-optimization/105414] constant folding for fmin/max(snan, snan) is wrong

2022-11-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105414

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug rtl-optimization/105455] ICE: verify_flow_info failed (error: verify_flow_info: REG_BR_PROB does not match cfg)

2022-11-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105455

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.2
  Known to fail||12.1.0
  Known to work||12.2.0, 13.0

[Bug debug/105261] schedule-insns2 and ipa-sra make alive constant variables not available

2022-11-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105261

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection

--- Comment #2 from Andrew Pinski  ---
The IPA-SRA issue seems to be fixed on the trunk.

That is in the optimized dump we now have:

  # DEBUG BEGIN_STMT
  # DEBUG INLINE_ENTRY b
  # DEBUG BEGIN_STMT
  # DEBUG l_5 => 0
  # DEBUG l_54 => 5
  # DEBUG l_362 => 4
  # DEBUG BEGIN_STMT
  # DEBUG l_53 => 4
  # DEBUG l_55 => 0

While in GCC 12 we did not have that.


The scheduler issue I have not looked into at all since it is harder to figure
out RTL level debug info really.

[Bug rtl-optimization/107546] New: simd, redundant pcmpeqb and pxor

2022-11-06 Thread i.nixman at autistici dot org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107546

Bug ID: 107546
   Summary: simd, redundant pcmpeqb and pxor
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: i.nixman at autistici dot org
  Target Milestone: ---

Hello,

this code sample(https://godbolt.org/z/TnGMsfMs6):
```
#include 

auto foo(const char *p) {
const auto substr = _mm_loadu_si128((const __m128i *)p);
return _mm_cmplt_epi8(substr, _mm_set1_epi8('0'));
}

```
produces the following ASM code:
```
1: foo(char const*):
2:movdqu  xmm0, XMMWORD PTR [rdi]
3:pxorxmm1, xmm1
4:pcmpgtb xmm0, XMMWORD PTR .LC0[rip]
5:pcmpeqb xmm0, xmm1
6:ret
```
please look at line 5.
is there any reason for `pcmpeqb` and `pxor` instruction?

just for info, clang's output(https://godbolt.org/z/MPnvEMdhr):
```
1: foo(char const*):
2:movdqu  xmm1, xmmword ptr [rdi]
3:movdqa  xmm0, xmmword ptr [rip + .LCPI0_0]
4:pcmpgtb xmm0, xmm1
5:ret
```

it looks like the issue started at version 9 and up to the current trunk.

[Bug target/107546] simd, redundant pcmpeqb and pxor

2022-11-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107546

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Well it is definitely a target issue:
;; _3 = _4 <= { 47, 47, 47, 47, 47, 47, 47, 47, 47, 47, 47, 47, 47, 47, 47, 47
};

(insn 9 8 10 (set (reg:V16QI 89)
(mem/u/c:V16QI (symbol_ref/u:DI ("*.LC0") [flags 0x2]) [0  S16 A128]))
"/opt/compiler-explorer/gcc-trunk-20221106/lib/gcc/x86_64-linux-gnu/13.0.0/include/emmintrin.h":1353:34
-1
 (expr_list:REG_EQUAL (const_vector:V16QI [
(const_int 47 [0x2f]) repeated x16
])
(nil)))

(insn 10 9 11 (set (reg:V16QI 90)
(gt:V16QI (reg:V16QI 83 [ _4 ])
(reg:V16QI 89)))
"/opt/compiler-explorer/gcc-trunk-20221106/lib/gcc/x86_64-linux-gnu/13.0.0/include/emmintrin.h":1353:34
-1
 (nil))

(insn 11 10 12 (set (reg:V16QI 91)
(const_vector:V16QI [
(const_int 0 [0]) repeated x16
]))
"/opt/compiler-explorer/gcc-trunk-20221106/lib/gcc/x86_64-linux-gnu/13.0.0/include/emmintrin.h":1353:34
-1
 (nil))

(insn 12 11 13 (set (reg:V16QI 92)
(eq:V16QI (reg:V16QI 90)
(reg:V16QI 91)))
"/opt/compiler-explorer/gcc-trunk-20221106/lib/gcc/x86_64-linux-gnu/13.0.0/include/emmintrin.h":1353:34
-1
 (nil))

(insn 13 12 0 (set (reg:V16QI 82 [ _3 ])
    (reg:V16QI 92))
"/opt/compiler-explorer/gcc-trunk-20221106/lib/gcc/x86_64-linux-gnu/13.0.0/include/emmintrin.h":1353:34
-1
 (nil))


Reduced testcase using GNU C++ vector types instead:

#define vector __attribute__((vector_size(16)))
auto foo1(const char *p) {
vector signed char a = *(vector signed char*)p;
vector signed char a47 = {47, 47, 47, 47,47, 47, 47, 47,47, 47, 47, 47,47,
47, 47, 47};
return a <= a47;
}

[Bug target/107546] [10/11/12/13 Regression] simd, redundant pcmpeqb and pxor

2022-11-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107546

Andrew Pinski  changed:

   What|Removed |Added

Summary|simd, redundant pcmpeqb and |[10/11/12/13 Regression]
   |pxor|simd, redundant pcmpeqb and
   ||pxor
   Target Milestone|--- |10.5

--- Comment #2 from Andrew Pinski  ---
For GNU C++ vectors produced
GCC 4.8 until GCC 11 produced:
movdqa  xmm0, XMMWORD PTR [rdi]
pcmpeqd xmm1, xmm1
pcmpgtb xmm0, XMMWORD PTR .LC0[rip]
pandn   xmm0, xmm1
ret

GCC 11+ produces:
movdqa  xmm0, XMMWORD PTR [rdi]
pxorxmm1, xmm1
pcmpgtb xmm0, XMMWORD PTR .LC0[rip]
pcmpeqb xmm0, xmm1
ret

But the intrinics produced the expected thing until GCC 9.

in GCC 8 the intrinsics produces:
  _3 = VEC_COND_EXPR <_4 < { 48, 48, 48, 48, 48, 48, 48, 48, 48, 48, 48, 48,
48, 48, 48, 48 }, { -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1,
-1 }, { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }>;

even. Notice the < vs <= there.
I suspect the <= expansion part of the x86_64 backend needs to be fixed up to
produce better code.

So this is a regression for the intrinsics and marking it as such.

[Bug c++/107535] -fvisibility=hidden should not hide C++17 inline static variables

2022-11-06 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107535

Richard Biener  changed:

   What|Removed |Added

   Keywords||ABI

--- Comment #1 from Richard Biener  ---
kind-of a pilot error, maybe we should diagnose those cases instead?

[Bug ada/107536] [12/13 regression] Wrong 'not referenced' warning on renamed variable

2022-11-06 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107536

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |12.3
Summary|[12 regression] Wrong 'not  |[12/13 regression] Wrong
   |referenced' warning on  |'not referenced' warning on
   |renamed variable|renamed variable
   Keywords||diagnostic
   Priority|P3  |P4

[Bug tree-optimization/107541] [13 Regression] wrong code at -O1, -O2 and -O3 on x86_64-linux-gnu

2022-11-06 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107541

Richard Biener  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org
   Priority|P3  |P1

[Bug target/107546] [10/11/12/13 Regression] simd, redundant pcmpeqb and pxor

2022-11-06 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107546

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
 Target|x86_64  |x86_64-*-* i?86-*-*

[Bug target/107546] [10/11/12/13 Regression] simd, redundant pcmpeqb and pxor

2022-11-06 Thread crazylht at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107546

--- Comment #3 from Hongtao.liu  ---
Failed to match this instruction:
(set (reg:V16QI 95)
(eq:V16QI (gt:V16QI (subreg:V16QI (reg:V2DI 89 [ MEM[(const __m128i_u *
{ref-all})p_2(D)] ]) 0)
(mem/u/c:V16QI (symbol_ref/u:DI ("*.LC0") [flags 0x2]) [0  S16
A128]))
(const_vector:V16QI [
(const_int 0 [0]) repeated x16
])))


I think rtl can simplify vector comparison

(eq (gt op1 op2) const0_rtx) to just (gt op2 op1).

[Bug target/107546] [10/11/12/13 Regression] simd, redundant pcmpeqb and pxor

2022-11-06 Thread crazylht at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107546

--- Comment #4 from Hongtao.liu  ---

> even. Notice the < vs <= there.
> I suspect the <= expansion part of the x86_64 backend needs to be fixed up
> to produce better code.

Hmm, we do have a extra pcmpeq to negate the result.

--cut from ix86_expand_int_vec_cmp---
  rtx cmp = ix86_expand_int_sse_cmp (operands[0], code, operands[2],
 operands[3], NULL, NULL, &negate);

  if (!cmp)
return false;

  if (negate)
cmp = ix86_expand_int_sse_cmp (operands[0], EQ, cmp,
   CONST0_RTX (GET_MODE (cmp)),
   NULL, NULL, &negate);
---cut end---

[Bug target/107546] [10/11/12/13 Regression] simd, redundant pcmpeqb and pxor

2022-11-06 Thread glisse at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107546

--- Comment #5 from Marc Glisse  ---
typedef signed char v16qs __attribute__((vector_size(16)));
auto bar(v16qs x) { return x < 48; }

clang does expand it as 48 gt x. Gcc however does its usual change to x <= 47,
which it then tries to expand as ~(x > 47). I guess the expansion for x <= y
could be tweaked in the case where one argument is constant to undo what was
done earlier in the pipeline and expand as 48 > x.

[Bug target/107546] [10/11/12/13 Regression] simd, redundant pcmpeqb and pxor

2022-11-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107546

--- Comment #6 from Andrew Pinski  ---
(In reply to Marc Glisse from comment #5)
> typedef signed char v16qs __attribute__((vector_size(16)));
> auto bar(v16qs x) { return x < 48; }
> 
> clang does expand it as 48 gt x. Gcc however does its usual change to x <=
> 47, which it then tries to expand as ~(x > 47). I guess the expansion for x
> <= y could be tweaked in the case where one argument is constant to undo
> what was done earlier in the pipeline and expand as 48 > x.

I was going to suggest that ...
Or maybe that could be done in isel.

[Bug tree-optimization/107413] Perf loss ~14% on 519.lbm_r SPEC cpu2017 benchmark with r8-7132-gb5b33e113434be

2022-11-06 Thread rvmallad at amazon dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107413

--- Comment #11 from Rama Malladi  ---
(In reply to Wilco from comment #10)
> I'm seeing about 1.5% gain on Neoverse V1 and 0.5% loss on Neoverse N1. I'll
> post a patch that allows per-CPU settings for FMA reassociation, so you'll
> get good performance with -mcpu=native. However reassociation really needs
> to be taught about the existence of FMAs.

Thank you very much Wilco.

[Bug tree-optimization/107541] [13 Regression] wrong code at -O1, -O2 and -O3 on x86_64-linux-gnu

2022-11-06 Thread aldyh at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107541

--- Comment #4 from Aldy Hernandez  ---
This is an issue with the TRUNC_DIV_EXPR range-op entry optimizing divisions by
powers of 2 into right shifts.  We're right shifting the mask by the shift
amount.

operator_div::fold_range():
...
...
  tree t;
  if (rh.singleton_p (&t))
{
  wide_int wi = wi::to_wide (t);
  int shift = wi::exact_log2 (wi);
  if (shift != -1)
{
  wide_int nz = lh.get_nonzero_bits ();
  nz = wi::rshift (nz, shift, TYPE_SIGN (type));
  r.set_nonzero_bits (nz);
}
}

The operands are:
[irange] int [-256, -255] NONZERO 0xff01
[irange] int [8, 8] NONZERO 0x8

Result before optimization:
[irange] int [-32, -31] NONZERO 0xffe1

Result after the optimization:
[irange] int [-32, -31] NONZERO 0xffe0

I'll take a look.