[Bug tree-optimization/95396] [8/9/10/11 Regression] GCC produces incorrect code with -O3 for loops since r8-6511-g3ae129323d150621

[babokin at gmail dot com]

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

--- Comment #4 from Dmitry Babokin  ---
Richard Sandiford, could you please have a look as author of the commit, which
brought the regression?

We have a bunch of other fails, which might be or might be not the same as this
one. We'd like to avoid spamming developers with duplicates, so waiting for
this bug to be fixed.

Also, if there's a way how we can help investigating this bug, we would
appreciate your guidance.

[Bug tree-optimization/95396] [8/9/10/11 Regression] GCC produces incorrect code with -O3 for loops since r8-6511-g3ae129323d150621

[babokin at gmail dot com]

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

--- Comment #3 from Dmitry Babokin  ---
Could anyone please have a look at this bug? Fixing it would help us not to
file duplicate bugs discovered in random testing.

[Bug sanitizer/83382] UBSAN tiggers false-positive warning [-Werror=uninitialized]

[babokin at gmail dot com]

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

--- Comment #2 from Dmitry Babokin  ---
(In reply to Richard Biener from comment #1)
> The interaction between sanitizers and middle-end emitted warnings is
> difficult at best.  Can you avoid -Werror when sanitizing?

I can, if it's absolutely needed. But it's convenient. I use it in creduce as a
criteria that reduction haven't introduced undefined behavior. UBSAN doesn't
catch uninitialized variables, so I have to add this switch. An alternative is
to have two separate runs.

[Bug tree-optimization/83383] New: Wrong code with a bunch of type conversion and ternary operators

[babokin at gmail dot com]

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

Bug ID: 83383
   Summary: Wrong code with a bunch of type conversion and ternary
operators
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
  Target Milestone: ---

gcc trunk, rev 255537, x86_64.

> cat f.cpp
unsigned long long int tf_3_var_118 = 12702665990007799801ULL;
unsigned char tf_3_var_84 = 195;
unsigned long int tf_3_var_220 = 10859745545766433084UL;
unsigned char tf_3_var_108 = 183;
unsigned long int tf_3_array_1 [2] = {3625445792498952486UL,
1515764644577139006UL};
unsigned long int tf_3_array_4 [2] = {6823003974340523417ul,
8985037393681294663ul};
unsigned long int tf_3_var_132 = 5052410635626804928UL;
void foo() {
  tf_3_var_118 = char(tf_3_var_118) < tf_3_var_84;
  tf_3_var_220 = (tf_3_var_108 ? tf_3_array_1[0] : 0) -
 (tf_3_array_4[1] * tf_3_var_118 ? 1 : tf_3_var_132);
}

int main() {
foo();
__builtin_printf("%lld, %ld\n", tf_3_var_118, tf_3_var_220);
return 0;
}

> g++ f.cpp -o out -O0; ./out
1, 3625445792498952485
> g++ f.cpp -o out -O2; ./out
1, -142696484312785244

[Bug sanitizer/83382] New: UBSAN tiggers false-positive warning [-Werror=uninitialized]

[babokin at gmail dot com]

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

Bug ID: 83382
   Summary: UBSAN tiggers false-positive warning
[-Werror=uninitialized]
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

gcc trunk, rev 255537, x86_64.

Not sure if this is duplicate of #42145 or not, so filing as a separate bug.

The issue goes away if either sanitizer flags removed, "extern" removed from
tf_0_var_14 definition, or "const" removed from the same definition. Though it
points to different variable. So, something fishy is going on here.

You may argue that this analysis is inexact and I shouldn't rely on that, but
it's definitely usability bug, when unrelated things are causing troubles. And
it stops me from using -Werror=uninitialized in test case reduction, where it
really does useful job. 

> cat f.cpp
int tf_0_var_36;
signed char tf_0_var_58;
extern const int tf_0_var_14;
int *tf_0_ptr_8;
void tf_0_foo() {
  tf_0_var_36 >> ((!0 || tf_0_var_58) && (0 ? tf_0_var_14 : *tf_0_ptr_8));
}

> g++  -std=c++11 -fsanitize=undefined -Werror=uninitialized -o 
> ubsan_gcc_o2_func.o -c f.cpp
f.cpp: In function ‘void tf_0_foo()’:
f.cpp:6:72: error: ‘tf_0_ptr_8.1’ is used uninitialized in this function
[-Werror=uninitialized]
   tf_0_var_36 >> ((!0 || tf_0_var_58) && (0 ? tf_0_var_14 : *tf_0_ptr_8));
^
cc1plus: some warnings being treated as errors

[Bug target/83252] Wrong code with "-march=skylake-avx512 -O3"

[babokin at gmail dot com]

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

--- Comment #11 from Dmitry Babokin  ---
(In reply to Andrew Pinski from comment #10)

> We can add this if needed.  I think regression could be made make generic
> and add a generic new bug component.  We do have some very active people
> reading bug reports that can re-categorize them (not to sound special but I
> am one of them; note sometimes I get it wrong too).

Yes, in practice bugs are usually dispatched to the correct owner quite fast
(thanks for that, it really helps). So "new" category would not change much in
this sense, but it would definitely make the process more friendly and less
confusing for outsiders.

[Bug target/83252] Wrong code with "-march=skylake-avx512 -O3"

[babokin at gmail dot com]

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

--- Comment #9 from Dmitry Babokin  ---
(In reply to Richard Biener from comment #8)
> I suppose one could try scripting something with -fdisable-{tree,rtl}-$dump
> and seeding the list of passes to enable/disable with -fdump-{tree,rtl}-all.
> 
> Of course some -fdisable-* are "invalid" and will cause "interesting"
> downstream
> effects...
> 
> Sometimes I do this manually for cases where it isn't obvious who's doing sth
> wrong...

The main downside of this approach is that it requires understanding of GCC
compiler internals. And GCC bug tracker doesn't even have generic "new bugs"
component to assign, which means people need to have secret knowledge about
compiler internals. Would be good to address this problem in the long run and
make bug filing process more friendly for outsiders.

Don't take me wrong, my bugs are almost always are addressed blazingly fast and
I'm super happy about it. But I still think there are things which can make
life for bug filing people easier.

[Bug target/83252] Wrong code with "-march=skylake-avx512 -O3"

[babokin at gmail dot com]

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

--- Comment #6 from Dmitry Babokin  ---
(In reply to Jakub Jelinek from comment #1)
> Option bisection is rarely useful for GCC, debugging issues with -Ox -fthat
> -fno-this -fwhatever is usually not beneficial over just -Ox or whatever
> minimal options you need it.  Bisecting to what GCC version introduced the
> bug or changed behavior is usually much better.

Bisecting optimizations is orthogonal to bisecting of revision the bug started
with. In my experience it's extremely useful (with icc and clang) for
understanding the root cause of the bug (just compare two assemblers or IRs
with and without the guilty optimization). It's also very useful for
distinguishing bugs in automatic way - in case of multiple failing test cases I
can sort them in different buckets corresponding to guilty optmizations. This
analysis is not 100% accurate, but is very useful. And the third useful feature
of such bisection - finding an optimization for initial bug assignment.

I'm not insisting on such functionality, as my bugs were always analysed and
fixed in timely manner (unlike with other compilers). But I still think gcc
would benefit from such mechanism a lot.

[Bug target/83252] Wrong code with "-march=skylake-avx512 -O3"

[babokin at gmail dot com]

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

--- Comment #5 from Dmitry Babokin  ---
The original test case is also fixed. Thanks for investigation.

[Bug target/83252] New: Wrong code with "-march=skylake-avx512 -O3"

[babokin at gmail dot com]

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

Bug ID: 83252
   Summary: Wrong code with "-march=skylake-avx512 -O3"
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
  Target Milestone: ---

Created attachment 42775
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42775=edit
reproducer

gcc trunk rev255248, x86_64.

Attached test case produces wrong code:
> g++ -O0 f.cpp -o out
> g++ -march=skylake-avx512 -O3 f.cpp -o out3
> ./out
88480289
> ./out3
88480288

I was not able to reduce it further. At this point the test case doesn't
contain undefined behavior (at least address and undefined behavior sanitizers
think so). Original test case didn't have undefined behavior guaranteed by the
way it was generated, but while reduction it could be possibly introduced, but
to my judgement it's a valid test case without UB.

Note that to reproduce it's essential to compile with "-march=skylake-avx512
-O3".

Sadly, gcc doesn't provide any bug pointing functionality, which would help
understanding the root cause of the bug without digging into compiler
internals. icc and clang have triaging flags (see
https://llvm.org/docs/OptBisect.html for clang implementation of this
mechanism). It would be very helpful to have similar functionality in gcc. If
I'm missing something, I would appreciate pointers to documents describing how
to triage this kind of bugs in gcc.

[Bug tree-optimization/83221] New: qsort comparator not anti-commutative: -2147483648, -2147483648

[babokin at gmail dot com]

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

Bug ID: 83221
   Summary: qsort comparator not anti-commutative: -2147483648,
-2147483648
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
  Target Milestone: ---

Created attachment 42748
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42748=edit
reproducer

gcc trunk rev255248, x86_64.

> time g++ -std=c++11 -w -O2 -o gcc_skx_opt_func.o -c 
> func_reduced_gcc_skx_opt.cpp
func_reduced_gcc_skx_opt.cpp: In function ‘void tf_4_foo()’:
func_reduced_gcc_skx_opt.cpp:250:14: error: qsort comparator not
anti-commutative: -2147483648, -2147483648
 void tf_4_foo () {
  ^~~~
during GIMPLE pass: reassoc
func_reduced_gcc_skx_opt.cpp:250:14: internal compiler error: qsort checking
failed
0x8f5c3a qsort_chk_error
../../gcc/gcc/vec.c:222
0x8f5ca5 qsort_chk(void*, unsigned long, unsigned long, int (*)(void const*,
void const*))
../../gcc/gcc/vec.c:276
0x7db30b vec<operand_entry*, va_heap, vl_embed>::qsort(int (*)(void const*,
void const*))
../../gcc/gcc/vec.h:1050
0x7db30b vec<operand_entry*, va_heap, vl_ptr>::qsort(int (*)(void const*, void
const*))
../../gcc/gcc/vec.h:1812
0x7db30b reassociate_bb
../../gcc/gcc/tree-ssa-reassoc.c:5831
0x7dae22 reassociate_bb
../../gcc/gcc/tree-ssa-reassoc.c:5983
0x7dae22 reassociate_bb
../../gcc/gcc/tree-ssa-reassoc.c:5983
0x7dae22 reassociate_bb
../../gcc/gcc/tree-ssa-reassoc.c:5983
0x7dae22 reassociate_bb
../../gcc/gcc/tree-ssa-reassoc.c:5983
0x7dae22 reassociate_bb
../../gcc/gcc/tree-ssa-reassoc.c:5983
0x7dae22 reassociate_bb
../../gcc/gcc/tree-ssa-reassoc.c:5983
0x7dae22 reassociate_bb
../../gcc/gcc/tree-ssa-reassoc.c:5983
0x7dae22 reassociate_bb
../../gcc/gcc/tree-ssa-reassoc.c:5983
0x7dae22 reassociate_bb
../../gcc/gcc/tree-ssa-reassoc.c:5983
0x7dae22 reassociate_bb
../../gcc/gcc/tree-ssa-reassoc.c:5983
0x7dae22 reassociate_bb
../../gcc/gcc/tree-ssa-reassoc.c:5983
0x7dae22 reassociate_bb
../../gcc/gcc/tree-ssa-reassoc.c:5983
0x7dae22 reassociate_bb
../../gcc/gcc/tree-ssa-reassoc.c:5983
0x7dae22 reassociate_bb
../../gcc/gcc/tree-ssa-reassoc.c:5983
0x7dae22 reassociate_bb
../../gcc/gcc/tree-ssa-reassoc.c:5983
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug ipa/82957] New: internal compiler error: in to_cgraph_frequency, at profile-count.c:251

[babokin at gmail dot com]

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

Bug ID: 82957
   Summary: internal compiler error: in to_cgraph_frequency, at
profile-count.c:251
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Building compiler-rt (LLVM libs) with GCC trunk (rev 254666, x86_64) I get this
error.

Here's reduced test case:

> cat cfi.i
namespace a {
typedef long b;
void c() { __builtin_trap(); }
}
using namespace a;
namespace d {
class e {
public:
  bool f();
};
__attribute__((always_inline)) void g(b, void *, void *) {
  e h;
  if (h.f())
c();
}
}
using namespace d;
void i() { g(0, 0, 0); }
sctpiel1:/users/dybaboki/llvm/build-trunk-20171112_temp/projects/compiler-rt/lib/cfi>
g++ -std=c++11 -O2 cfi.i -c -m32
cfi.i:11:37: warning: always_inline function might not be inlinable
[-Wattributes]
 __attribute__((always_inline)) void g(b, void *, void *) {
 ^
during GIMPLE pass: einline
cfi.i: In function ‘void i()’:
cfi.i:18:24: internal compiler error: in to_cgraph_frequency, at
profile-count.c:251
 void i() { g(0, 0, 0); }
^
0xde7859 profile_count::to_cgraph_frequency(profile_count) const
../../gcc/gcc/profile-count.c:251
0xcb2cd7 cgraph_edge::frequency()
../../gcc/gcc/cgraph.h:3118
0xcb2cd7 estimate_edge_size_and_time
../../gcc/gcc/ipa-fnsummary.c:2581
0xcb2cd7 estimate_calls_size_and_time
../../gcc/gcc/ipa-fnsummary.c:2620
0xcb2ed6 estimate_calls_size_and_time
../../gcc/gcc/ipa-fnsummary.c:2627
0xcb3625 ipa_update_overall_fn_summary(cgraph_node*)
../../gcc/gcc/ipa-fnsummary.c:3114
0x6fb64e early_inline_small_functions
../../gcc/gcc/ipa-inline.c:2636
0x6fb64e early_inliner(function*)
../../gcc/gcc/ipa-inline.c:2730
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug rtl-optimization/82778] New: crash: insn does not satisfy its constraints

[babokin at gmail dot com]

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

Bug ID: 82778
   Summary: crash: insn does not satisfy its constraints
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
  Target Milestone: ---

gcc trunk rev254211, x86_64.

> cat f.cpp
template  struct c {
  typedef a d[b];
  static a e(d f, int g) { return f[g]; }
};
template  struct B {
  typedef c<a, b> h;
  typename h::d i;
  long j;
  a at() { return h::e(i, j); }
};
int k, m, r, s, t;
char l, n, q;
short o, p, w;
struct C {
  int u;
};
B<C, 4> v;
void x() {
  if (((p > (q ? v.at().u : k)) >> l - 226) + !(n ^ r * m))
s = ((-(((p > (q ? v.at().u : k)) >> l - 226) + !(n ^ r * m)) < 0) /
 (-(((p > (q ? v.at().u : k)) >> l - 226) + !(n ^ r * m)) ^
  -25 & o) &&
 p) >>
(0 <= 0
 ? 0 ||
   (-(((p > (q ? v.at().u : k)) >> l - 226) + !(n ^ r * m)) <
0) /
   (-(((p > (q ? v.at().u : k)) >> l - 226) +
  !(n ^ r * m)) ^
-25 & o)
 : 0);
  w = (p > (q ? v.at().u : k)) >> l - 226;
  t = !(n ^ r * m);
}

> gcc -O2 -c f.cpp
f.cpp: In function ‘void x()’:
f.cpp:34:1: error: insn does not satisfy its constraints:
 }
 ^
(insn 77 75 37 4 (parallel [
(set (reg:CCZ 17 flags)
(compare:CCZ (plus:SI (reg:SI 0 ax [orig:95 _9 ] [95])
(reg:SI 1 dx [orig:102 _16 ] [102]))
(const_int 0 [0])))
(set (reg:SI 2 cx [orig:103 _17 ] [103])
(plus:SI (reg:SI 0 ax [orig:95 _9 ] [95])
(reg:SI 1 dx [orig:102 _16 ] [102])))
]) "f.cpp":19 225 {*addsi_2}
 (expr_list:REG_UNUSED (reg:SI 2 cx [orig:103 _17 ] [103])
(nil)))
during RTL pass: cprop_hardreg
f.cpp:34:1: internal compiler error: in extract_constrain_insn, at recog.c:2207
0x61c877 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc/gcc/rtl-error.c:108
0x61c89d _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc/gcc/rtl-error.c:118
0xdf60bd extract_constrain_insn(rtx_insn*)
../../gcc/gcc/recog.c:2207
0xdff55f copyprop_hardreg_forward_1
../../gcc/gcc/regcprop.c:790
0xe001df execute
../../gcc/gcc/regcprop.c:1296
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug rtl-optimization/82576] New: sbitmap_vector_alloc() not ready for 64 bits

[babokin at gmail dot com]

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

Bug ID: 82576
   Summary: sbitmap_vector_alloc() not ready for 64 bits
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
  Target Milestone: ---

Created attachment 42382
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42382=edit
Reproducer

gcc trunk, rev253744, x86_64.

Trying compile attached test case with UBSAN I get segfault:
during RTL pass: cprop
f.cpp: In function ‘void tf_1_foo()’:
f.cpp:335:3: internal compiler error: Segmentation fault
   }
   ^
0xf4b65f crash_signal
../../gcc/gcc/toplev.c:326
0x1684418 sbitmap_vector_alloc(unsigned int, unsigned int)
../../gcc/gcc/sbitmap.c:171
0x1562dc3 alloc_cprop_mem
../../gcc/gcc/cprop.c:558
0x1562dc3 one_cprop_pass
../../gcc/gcc/cprop.c:1818
0x1562dc3 execute_rtl_cprop
../../gcc/gcc/cprop.c:1932
0x1562dc3 execute
../../gcc/gcc/cprop.c:1970

This is due to sbitmap_vector_alloc() implementation using "unsigned int",
instead of size_t. Fixing this make test case compile (even though consuming a
lot of memory, about 80Gb).

>g++ -std=c++11 -fsanitize=undefined -fno-sanitize-recover=undefined -w 
>-Werror=uninitialized -O2 -c f.cpp

[Bug rtl-optimization/81423] [6/7 Regression] Wrong code at -O2

[babokin at gmail dot com]

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

--- Comment #16 from Dmitry Babokin  ---
ll = -5597998501375493990LL;

// result is 2595916314 here.
ll = unsigned(5677365550390624949L - ll) - (ull1 > 0);

So:
  // t1 is 466811183
  unsigned long long int t1 = ll + -2129105131L;
  // t2 is 10280750143997242019
  unsigned long long int t2 = t1 ^ 10280750144413668236ULL;
  // t3 is 10
  unsigned long long int t3 = t2 - 10280750143997242009ULL;

So the test case looks correct to me.

UBSAN also doesn't complain.

[Bug c/82413] New: -O0 crash (ICE in decompose, at tree.h:5179)

[babokin at gmail dot com]

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

Bug ID: 82413
   Summary: -O0 crash (ICE in decompose, at tree.h:5179)
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
  Target Milestone: ---

GCC trunk, rev 253367, x86_64.

Rev 253307 works fine, so it's a fresh regression.

> cat f.cpp
bool a;
int b;
void c() { b & <= 0; }

> g++ -c f.cpp
f.cpp: In function ‘void c()’:
f.cpp:3:21: internal compiler error: in decompose, at tree.h:5179
 void c() { b & <= 0; }
 ^
0x6cbe00 wi::int_traits::decompose(long*, unsigned int,
tree_node const*)
../../gcc/gcc/tree.h:5179
0x6cbe00 wide_int_ref_storage::wide_int_ref_storage(tree_node const* const&, unsigned int)
../../gcc/gcc/wide-int.h:976
0x6cbe00 generic_wide_int<wide_int_ref_storage
>::generic_wide_int(tree_node const* const&, unsigned int)
../../gcc/gcc/wide-int.h:753
0x6cbe00 bool wi::eq_p<generic_wide_int, tree_node
const*>(generic_wide_int const&, tree_node const* const&)
../../gcc/gcc/wide-int.h:1760
0x6cbe00 bool
generic_wide_int::operator==<tree_node*>(tree_node* const&)
const
../../gcc/gcc/wide-int.h:704
0x6cbe00 build_range_check(unsigned int, tree_node*, tree_node*, int,
tree_node*, tree_node*)
../../gcc/gcc/fold-const.c:4854
0xcd4a08 build_range_check(unsigned int, tree_node*, tree_node*, int,
tree_node*, tree_node*)
../../gcc/gcc/fold-const.c:4809
0xb4c404 warn_logical_operator(unsigned int, tree_code, tree_node*, tree_code,
tree_node*, tree_code, tree_node*)
../../gcc/gcc/c-family/c-warn.c:270
0x91af33 build_new_op_1
../../gcc/gcc/cp/call.c:5978
0x91b42e build_new_op(unsigned int, tree_code, int, tree_node*, tree_node*,
tree_node*, tree_node**, int)
../../gcc/gcc/cp/call.c:6051
0xabf972 build_x_binary_op(unsigned int, tree_code, tree_node*, tree_code,
tree_node*, tree_code, tree_node**, int)
../../gcc/gcc/cp/typeck.c:3960
0xa03a2e cp_parser_binary_expression
../../gcc/gcc/cp/parser.c:9274
0xa04f74 cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:9407
0xa05678 cp_parser_expression
../../gcc/gcc/cp/parser.c:9576
0xa07388 cp_parser_expression_statement
../../gcc/gcc/cp/parser.c:11091
0xa0d543 cp_parser_statement
../../gcc/gcc/cp/parser.c:10907
0xa0e5f0 cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:11234
0xa0e6c7 cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:11188
0xa2400a cp_parser_function_body
../../gcc/gcc/cp/parser.c:21669
0xa2400a cp_parser_ctor_initializer_opt_and_function_body
../../gcc/gcc/cp/parser.c:21707
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug tree-optimization/82381] New: internal compiler error: qsort checking failed

[babokin at gmail dot com]

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

Bug ID: 82381
   Summary: internal compiler error: qsort checking failed
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
  Target Milestone: ---

GCC trunk rev 253307, x86_64.

This looks like a fresh regression. I see quite many fails like this one.

> cat f.cpp
char b, h;
unsigned short c, e;
short d, f, g;
void i() {
  if (h) {
short a(-(d + c - b));
f = e - a - -d;
  }
  if (c)
g = 0;
}

> g++ -O2 -c f.cpp
f.cpp: In function ‘void i()’:
f.cpp:4:6: error: qsort comparator non-negative on sorted output: 1
 void i() {
  ^
during GIMPLE pass: reassoc
f.cpp:4:6: internal compiler error: qsort checking failed
0x8fbc82 qsort_chk_error
../../gcc/gcc/vec.c:222
0x8fbcfb qsort_chk(void*, unsigned long, unsigned long, int (*)(void const*,
void const*))
../../gcc/gcc/vec.c:274
0x7d9118 vec<operand_entry*, va_heap, vl_embed>::qsort(int (*)(void const*,
void const*))
../../gcc/gcc/vec.h:973
0x7d9118 vec<operand_entry*, va_heap, vl_ptr>::qsort(int (*)(void const*, void
const*))
../../gcc/gcc/vec.h:1735
0x7d9118 reassociate_bb
../../gcc/gcc/tree-ssa-reassoc.c:5839
0x7d755b reassociate_bb
../../gcc/gcc/tree-ssa-reassoc.c:5979
0x7d755b reassociate_bb
../../gcc/gcc/tree-ssa-reassoc.c:5979
0x7d755b reassociate_bb
../../gcc/gcc/tree-ssa-reassoc.c:5979
0x109673c do_reassoc
../../gcc/gcc/tree-ssa-reassoc.c:6093
0x109673c execute_reassoc
../../gcc/gcc/tree-ssa-reassoc.c:6180
0x109673c execute
../../gcc/gcc/tree-ssa-reassoc.c:6219
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug sanitizer/82353] runtime ubsan crash

[babokin at gmail dot com]

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

--- Comment #1 from Dmitry Babokin  ---
Created attachment 42256
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42256=edit
original test case

I'm also attaching original test case, just in case. For the bug to reproduce
it's important to compile with -std=c++11 switch.

> g++ -std=c++11 -fsanitize=undefined -fno-sanitize-recover=undefined -w -O2 
> func.cpp driver.cpp -o out
> ./out
func.cpp:2448:96: runtime error: pointer index expression with base
0x0063a3a0 overflowed to 0x0063a3b8

[Bug sanitizer/82353] New: runtime ubsan crash

[babokin at gmail dot com]

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

Bug ID: 82353
   Summary: runtime ubsan crash
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

Created attachment 42255
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42255=edit
reduced test case

GCC trunk, rev 253244, x86_64.

> g++ -std=c++11 -fsanitize=undefined -fno-sanitize-recover=undefined -w -O2 
> ff.cpp dd.cpp -o out
> ./out
ff.cpp:20:27: runtime error: pointer index expression with base 0x006022f0
overflowed to 0x00602300

Test case was reduced from a larger UB-free program.

I failed to reduce test case to a single file reproducer.

[Bug tree-optimization/81814] New: Incorrect behaviour at -O0 (conditional operator)

[babokin at gmail dot com]

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

Bug ID: 81814
   Summary: Incorrect behaviour at -O0 (conditional operator)
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
  Target Milestone: ---

gcc trunk, x86_64.

The test case is simple and my understanding that the correct result is
0x0100, while gcc produces 0. Slight massaging of the code (like removal of
"* m2") changes the behaviour to be correct. Not sure whom to blame - front-end
or optimizations (even though it's -O0).

> cat f.cpp
#include 
unsigned long long int m2 = 1;
int xxx = 0x0100;

int main() {
int a = ( ( (char) xxx) ? 0 : xxx) * m2;
printf("0x%x (expected 0x0100)\n", a);
return 0;
}

> g++ -O0 f.cpp -o out; ./out;
0x0 (expected 0x0100)

> clang++ -O0 f.cpp -o out; ./out
0x100 (expected 0x0100)

[Bug c++/81607] [6/7 Regression] Conditional operator: "type mismatch in shift expression" error

[babokin at gmail dot com]

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

--- Comment #12 from Dmitry Babokin  ---
The fix helped all fails that I see (with all 7 different symptoms). Thanks!

[Bug middle-end/81705] [8 Regression] UBSAN: yet another false positive

[babokin at gmail dot com]

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

--- Comment #7 from Dmitry Babokin  ---
That's an excellent new! This means UBSAN becomes finally fully functional in
GCC. No known false positives anymore (on quite large test base). Great job and
thank you!

[Bug tree-optimization/81705] New: UBSAN: yet another false positive

[babokin at gmail dot com]

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

Bug ID: 81705
   Summary: UBSAN: yet another false positive
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
  Target Milestone: ---

gcc trunk, rev250857, x86_64.

After recent fix for #81148, this case is the last one failing UBSAN false
positive that I see on my radars.

> cat f.cpp
int var_4 = -1716607962;
int var_14 = 943738830;
volatile int a;
int main() {
//  (-(-1716607962) - 516151698) - -(9403738830)
  a = (-var_4 - 516151698) - -var_14;
  return 0;
}

> g++ -fsanitize=undefined f.cpp -o out; ./out
f.cpp:6:28: runtime error: signed integer overflow: -943738830 + -1716607962
cannot be represented in type 'int'
f.cpp:6:28: runtime error: signed integer overflow: -516151698 - 1634620504
cannot be represented in type 'int'

[Bug tree-optimization/81607] New: Conditional operator: "type mismatch in shift expression" error

[babokin at gmail dot com]

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

Bug ID: 81607
   Summary: Conditional operator: "type mismatch in shift
expression" error
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
  Target Milestone: ---

gcc trunk, rev250630, x86_64.

I see a lot of crashes involving conditional operator and struct field access.
I see at least 7 different kind of crashes. They may be related, so I'm filing
only this one for now to avoid spamming the bug tracker. After fixing this one,
I'll proceed with others if they are not fixed.

> cat f.cpp
int a;
struct b {
  long c : 32;
} d;
char f = (903092 ? int(d.c) : 0) << a;

> g++ -c f.cpp
f.cpp: In function ‘void __static_initialization_and_destruction_0(int, int)’:
f.cpp:5:38: error: type mismatch in shift expression
 char f = (903092 ? int(d.c) : 0) << a;
  ^
int
long int
int
_4 = _2 << a.0_3;
f.cpp:5:38: internal compiler error: verify_gimple failed
0xf5e57d verify_gimple_in_seq(gimple*)
../../gcc_svn_intel/gcc/tree-cfg.c:4975
0xd1d2ad gimplify_body(tree_node*, bool)
../../gcc_svn_intel/gcc/gimplify.c:12589
0xd1d47c gimplify_function_tree(tree_node*)
../../gcc_svn_intel/gcc/gimplify.c:12679
0xbb64b7 cgraph_node::analyze()
../../gcc_svn_intel/gcc/cgraphunit.c:668
0xbb8b73 analyze_functions
../../gcc_svn_intel/gcc/cgraphunit.c:1129
0xbb9a12 symbol_table::finalize_compilation_unit()
../../gcc_svn_intel/gcc/cgraphunit.c:2607
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug tree-optimization/81588] New: Wrong code at -O2

[babokin at gmail dot com]

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

Bug ID: 81588
   Summary: Wrong code at -O2
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
  Target Milestone: ---

gcc trunk, rev250630, x86_64.

> cat f.cpp
#include 
long int var_34 = 5011877430933453486L;
unsigned short var_82 = 24847;
long int var_58 = 1;
void foo() {
  if (var_82 > var_34 ^ true + (var_34 < 0))
var_58 = 0;
}
int main() {
  foo();
  printf("%ld\n", var_58);
  return 0;
}

> g++ -O0 f.cpp -o out; ./out
0

> g++ -O2 f.cpp -o out; ./out
1

[Bug tree-optimization/81555] Wrong code at -O1

[babokin at gmail dot com]

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

--- Comment #4 from Dmitry Babokin  ---
(In reply to Marc Glisse from comment #3)
> -fno-tree-reassoc should help both.
It helps.

> It is often a combination of optimizations that causes the bug. Reassoc is
> doing a good transformation, but it leaves wrong information around, which
> only matters if some other pass (rightfully) takes advantage of that
> information. Still, it was good to report both, and I expect we may add (a
> modified version of) both to the testsuite once this is fixed, thanks.

Agree, two regression tests are better than one.

As a side note, it would be really useful to have a general mechanism for
blaming particular optimization by turning off optimizer after certain point
(defined through command line switch). Clang and icc both have such mechanism
and it's extremely useful. In clang it's "-mllvm -opt-bisect-limit=X". So it
enables automated attribution of the bug to particular optimization. Of course
it's not 100% precise, but in most of the cases it points to the right place.
In other cases it gives good clue where to start the investigation.

[Bug tree-optimization/81555] Wrong code at -O1

[babokin at gmail dot com]

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

--- Comment #2 from Dmitry Babokin  ---
Hmmm, but this one is triggered at -O1, another only at -O2.

[Bug tree-optimization/81556] New: Wrong code at -O2

[babokin at gmail dot com]

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

Bug ID: 81556
   Summary: Wrong code at -O2
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
  Target Milestone: ---

gcc trunk, rev250545, x86_64.

This one seems to be different from previously reported bugs. Minimum opt level
to trigger bug is -O2, switching slsr doesn't help (-fno-tree-slsr).

> cat f.cpp
#include 

unsigned long int var_0 = 13272098465497875865UL;
unsigned long int var_1 = 15341539099603541390UL;
unsigned long int var_2 = 2;
unsigned long int var_3 = 17471558040813171499UL;
unsigned long int var_4 = 1;
unsigned long int var_5 = 0;
unsigned long int var_6 = 0;

void foo() {
  bool a = var_2 > 1;
  var_5 = var_4 % ((var_2 > 1) << 9);
  var_6 = a & (var_3 & (a & var_0 & var_1));
}

int main() {
  foo();
  printf("0x%llx, 0x%llx\n", var_5, var_6);
  return 0;
}

> g++ -O0 f.cpp -o out; ./out
0x1, 0x0

> g++ -O2 f.cpp -o out; ./out
0x1, 0x90201108

[Bug tree-optimization/81555] New: Wrong code at -O1

[babokin at gmail dot com]

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

Bug ID: 81555
   Summary: Wrong code at -O1
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
  Target Milestone: ---

gcc trunk, rev250545, x86_64.

> cat f.cpp
#include 

unsigned int var_1 = 1;
bool var_2 = false;
unsigned int var_3 = 679743406U;
unsigned int var_4 = 3054363510U;
bool var_5 = true;
unsigned char var_6 = 1;

void foo() {
  bool c = var_1 != var_2;
  if (c)
var_5 = 0;
  if (var_4 & c & (unsigned char)var_3 & c)
var_6 = 0;
}

int main() {
  foo();
  printf("%d, %d\n", var_5, var_6);
  return 0;
}

> g++ -O0 f.cpp -o out; ./out
0, 1

> g++ -O1 f.cpp -o out; ./out
0, 0

[Bug rtl-optimization/81553] New: ICE in immed_wide_int_const, at emit-rtl.c:607

[babokin at gmail dot com]

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

Bug ID: 81553
   Summary: ICE in immed_wide_int_const, at emit-rtl.c:607
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
  Target Milestone: ---

gcc trunk, rev250527, x86_64

> cat f.cpp
int a, b, c;
struct d {
  static int e;
} f;
d g, h;
void i() {
  f.e = (10834211066969351267ULL || 0) >> c >> 1;
  b = ~(209883449764912897ULL & h.e) << (0 >= a) | ~g.e;
}

> g++ f.cpp -c -O2
during RTL pass: combine
f.cpp: In function ‘void i()’:
f.cpp:9:1: internal compiler error: in immed_wide_int_const, at emit-rtl.c:607
 }
 ^
0x6b2cc1 immed_wide_int_const(generic_wide_int<wide_int_ref_storage >
const&, machine_mode)
../../gcc_svn_intel/gcc/emit-rtl.c:607
0xf0fc34 simplify_const_unary_operation(rtx_code, machine_mode, rtx_def*,
machine_mode)
../../gcc_svn_intel/gcc/simplify-rtx.c:1882
0xf0df4e simplify_unary_operation(rtx_code, machine_mode, rtx_def*,
machine_mode)
../../gcc_svn_intel/gcc/simplify-rtx.c:883
0xf0f290 simplify_gen_unary(rtx_code, machine_mode, rtx_def*, machine_mode)
../../gcc_svn_intel/gcc/simplify-rtx.c:384
0x152bea0 if_then_else_cond
../../gcc_svn_intel/gcc/combine.c:9044
0x152bcef if_then_else_cond
../../gcc_svn_intel/gcc/combine.c:9063
0x15365f5 combine_simplify_rtx
../../gcc_svn_intel/gcc/combine.c:5636
0x1538d21 subst
../../gcc_svn_intel/gcc/combine.c:5519
0x1536a87 combine_simplify_rtx
../../gcc_svn_intel/gcc/combine.c:5653
0x1538d21 subst
../../gcc_svn_intel/gcc/combine.c:5519
0x1538aac subst
../../gcc_svn_intel/gcc/combine.c:5457
0x1538b95 subst
../../gcc_svn_intel/gcc/combine.c:5386
0x153be5e try_combine
../../gcc_svn_intel/gcc/combine.c:3368
0x15420de combine_instructions
../../gcc_svn_intel/gcc/combine.c:1434
0x15420de rest_of_handle_combine
../../gcc_svn_intel/gcc/combine.c:14646
0x15420de execute
../../gcc_svn_intel/gcc/combine.c:14691
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug tree-optimization/81546] ICE at -O3 during GIMPLE pass dom

[babokin at gmail dot com]

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

--- Comment #2 from Dmitry Babokin  ---
Reduced test case consumes about 11Gb. That's a lot and looks like it's just
the consequence of the real problem. But the test case in #81488 consumes 128Gb
and dies on my machine because of lack of available memory.

This makes me think that two things need to be fixed - SSA bug itself and
proper thresholds need to be imposed.

By the way, slight massaging of the test case makes the problem go away. For
example, manual folding of -112 & 18444684886795439976ULL "fixes" the problem.

[Bug tree-optimization/81503] [8 Regression] Wrong code at -O2

[babokin at gmail dot com]

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

--- Comment #6 from Dmitry Babokin  ---
How can I switch off optimization phases to workaround the bug?

I have another instances of wrong code bugs, so I'd like to make sure that I
don't create duplicate reports for the same problem.

[Bug tree-optimization/81546] New: ICE at -O3 during GIMPLE pass dom

[babokin at gmail dot com]

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

Bug ID: 81546
   Summary: ICE at -O3 during GIMPLE pass dom
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
  Target Milestone: ---

Created attachment 41823
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41823=edit
reduced and original test cases

gcc trunk rev250367, x86_64

Test case is reduced from much larger code. During reduction blame phase has
changed from slsr to dom, but looks like it's still the same problem.

Another interesting observation, during test case reduction one of intermediate
results triggered too aggressive memory allocation (more that 128Gb), this was
reported separately in #81488


> time g++ -O0 -c fff.cpp

real0m0.048s
user0m0.035s
sys 0m0.012s

> time g++ -O2 -c fff.cpp

real0m0.085s
user0m0.075s
sys 0m0.010s

> time g++ -O3 -c fff.cpp
 IMM ERROR : (use_p : tree - 0x7f63cea18b68:0x7f63cea18b88)_5
for SSA_NAME: _5 in statement:
if (_5 != 0)
during GIMPLE pass: dom
fff.cpp: In function ‘void foo()’:
fff.cpp:30:6: internal compiler error: verify_ssa failed
 void foo() {
  ^~~
0x10f9043 verify_ssa(bool, bool)
../../gcc_svn_intel/gcc/tree-ssa.c:1186
0xe9088d execute_function_todo
../../gcc_svn_intel/gcc/passes.c:1996
0xe915ee execute_todo
../../gcc_svn_intel/gcc/passes.c:2043
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

real2m12.280s
user2m6.464s
sys 0m5.786s

[Bug tree-optimization/81503] New: Wrong code at -O2

[babokin at gmail dot com]

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

Bug ID: 81503
   Summary: Wrong code at -O2
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
  Target Milestone: ---

gcc trunk, rev250367, x86_64.

> cat f.cpp
#include 
unsigned short a = 41461;
unsigned short b = 3419;
int c = 0;

void foo() {
  if (a + b * ~(0 != 5))
c = -~(b * ~(0 != 5)) + 2147483647;
}

int main() {
  foo();
  printf("%d\n", c);
  return 0;
}

> g++ f.cpp -O0; ./a.out
2147476810

> g++ f.cpp -O2; ./a.out
-2147483648

[Bug tree-optimization/81488] New: gcc goes off the limits allocating memory in gimple-ssa-strength-reduction.c

[babokin at gmail dot com]

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

Bug ID: 81488
   Summary: gcc goes off the limits allocating memory in
gimple-ssa-strength-reduction.c
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
  Target Milestone: ---

Created attachment 41792
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41792=edit
reproducer

gcc trunk, rev250217, x86_64.

The attached test case was obtained by reducing the bigger test case with
another SSA problem, which is manifested as the following:
 IMM ERROR : (use_p : tree - 0x7f06c0e56d68:0x7f06c0e56d88)_95049
for SSA_NAME: _95049 in statement:
slsr_55910 = PHI <_95049(199), _95049(200)>
PHI argument
_95049
for PHI node
slsr_55910 = PHI <_95049(199), _95049(200)>
during GIMPLE pass: slsr

Anyway, during the test case reduction (which keep the program at all reduction
steps correct and UB-free) compilation started consuming enormous amount of
memory - basically all available on the machine (128Gb) and crashing after
that. Compilation doesn't take long, it's typically about 2 minutes before it
crashes.

Here's example of the stack while gcc actively allocating memory:


#0  0x7f7aa06ab70b in __memset_sse2 () from /lib64/libc.so.6
#1  0x00a65e4f in ggc_internal_alloc(unsigned long, void (*)(void*),
unsigned long, unsigned long) () at ../../gcc/gcc/ggc-page.c:1392
#2  0x00f4acd9 in ggc_internal_alloc (s=) at
../../gcc/gcc/ggc.h:130
#3  allocate_phi_node (len=) at
../../gcc/gcc/tree-phinodes.c:117
#4  make_phi_node (len=, var=) at
../../gcc/gcc/tree-phinodes.c:174
#5  create_phi_node(tree_node*, basic_block_def*) () at
../../gcc/gcc/tree-phinodes.c:342
#6  0x0159219b in create_phi_basis(slsr_cand_d*, gimple*, tree_node*,
unsigned int, bool) () at ../../gcc/gcc/gimple-ssa-strength-reduction.c:2405
#7  0x015926ce in create_phi_basis(slsr_cand_d*, gimple*, tree_node*,
unsigned int, bool) () at ../../gcc/gcc/gimple-ssa-strength-reduction.c:2386
#8  0x015926ce in create_phi_basis(slsr_cand_d*, gimple*, tree_node*,
unsigned int, bool) () at ../../gcc/gcc/gimple-ssa-strength-reduction.c:2386
#9  0x015926ce in create_phi_basis(slsr_cand_d*, gimple*, tree_node*,
unsigned int, bool) () at ../../gcc/gcc/gimple-ssa-strength-reduction.c:2386
#10 0x015926ce in create_phi_basis(slsr_cand_d*, gimple*, tree_node*,
unsigned int, bool) () at ../../gcc/gcc/gimple-ssa-strength-reduction.c:2386
#11 0x015926ce in create_phi_basis(slsr_cand_d*, gimple*, tree_node*,
unsigned int, bool) () at ../../gcc/gcc/gimple-ssa-strength-reduction.c:2386
#12 0x015926ce in create_phi_basis(slsr_cand_d*, gimple*, tree_node*,
unsigned int, bool) () at ../../gcc/gcc/gimple-ssa-strength-reduction.c:2386
#13 0x015926ce in create_phi_basis(slsr_cand_d*, gimple*, tree_node*,
unsigned int, bool) () at ../../gcc/gcc/gimple-ssa-strength-reduction.c:2386
#14 0x015926ce in create_phi_basis(slsr_cand_d*, gimple*, tree_node*,
unsigned int, bool) () at ../../gcc/gcc/gimple-ssa-strength-reduction.c:2386
#15 0x015926ce in create_phi_basis(slsr_cand_d*, gimple*, tree_node*,
unsigned int, bool) () at ../../gcc/gcc/gimple-ssa-strength-reduction.c:2386
#16 0x015926ce in create_phi_basis(slsr_cand_d*, gimple*, tree_node*,
unsigned int, bool) () at ../../gcc/gcc/gimple-ssa-strength-reduction.c:2386
#17 0x015926ce in create_phi_basis(slsr_cand_d*, gimple*, tree_node*,
unsigned int, bool) () at ../../gcc/gcc/gimple-ssa-strength-reduction.c:2386
#18 0x015926ce in create_phi_basis(slsr_cand_d*, gimple*, tree_node*,
unsigned int, bool) () at ../../gcc/gcc/gimple-ssa-strength-reduction.c:2386
#19 0x015926ce in create_phi_basis(slsr_cand_d*, gimple*, tree_node*,
unsigned int, bool) () at ../../gcc/gcc/gimple-ssa-strength-reduction.c:2386
#20 0x015926ce in create_phi_basis(slsr_cand_d*, gimple*, tree_node*,
unsigned int, bool) () at ../../gcc/gcc/gimple-ssa-strength-reduction.c:2386
#21 0x015926ce in create_phi_basis(slsr_cand_d*, gimple*, tree_node*,
unsigned int, bool) () at ../../gcc/gcc/gimple-ssa-strength-reduction.c:2386
#22 0x015926ce in create_phi_basis(slsr_cand_d*, gimple*, tree_node*,
unsigned int, bool) () at ../../gcc/gcc/gimple-ssa-strength-reduction.c:2386
#23 0x015926ce in create_phi_basis(slsr_cand_d*, gimple*, tree_node*,
unsigned int, bool) () at ../../gcc/gcc/gimple-ssa-strength-reduction.c:2386
#24 0x015926ce in create_phi_basis(slsr_cand_d*, gimple*, tree_node*,
unsigned int, bool) () at ../../gcc/gcc/gimple-ssa-strength-reduction.c:2386
#25 0x015926ce in create_phi_basis(slsr_cand_d*, gimple*, tree_node*,
unsigned int, bool) () at ../../gcc/gcc/gimple-ssa-strength-reduc

[Bug tree-optimization/81423] New: Wrong code at -O2

[babokin at gmail dot com]

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

Bug ID: 81423
   Summary: Wrong code at -O2
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
  Target Milestone: ---

gcc trunk, rev250140, x86_64.

Test case has no undefined behavior, but -O2 produces incorrect result.

> cat f.cpp
#include 

unsigned long long int ll = 0;
unsigned long long int ull1 = 1ULL;
unsigned long long int ull2 = 12008284144813806346ULL;
unsigned long long int ull3;

void foo() {
  ll = -5597998501375493990LL;

  ll = unsigned(5677365550390624949L - ll) - (ull1 > 0);
  ull3 = unsigned(2067854353L << (((ll + -2129105131L) ^
10280750144413668236ULL) - 10280750143997242009ULL)) >>
((2873442921854271231ULL | ull2) - 12098357307243495419ULL);
}

int main() {
  foo();
  std::cout << ull3 << " (expected 3998784)\n";
  return 0;
}

> g++ f.cpp -O0 -o out; ./out
3998784 (expected 3998784)

> g++ f.cpp -O2 -o out; ./out
3493659712 (expected 3998784)

[Bug tree-optimization/81403] New: wrong code at -O3

[babokin at gmail dot com]

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

Bug ID: 81403
   Summary: wrong code at -O3
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
  Target Milestone: ---

gcc rev250140, x86_64.

> cat f.cpp
#include 

short var_9 = 19581;
unsigned char var_33 = 21;
long int var_55 = 286697804684061197L;
long int var_59 = -1962393262513510540L;
long int var_71 = 4731868609112929952L;
long int var_773 = -478463345624769L;
short var_776 = 5894;
long int var_1321 = 7573221950916697355L;
unsigned char uc = 217;

void foo() {
  if (var_55)
var_71 = 0;
  if (var_9 != ~(0 < uc))
var_773 = 0;
  else
var_776 = 1 / ~var_9 * -1;
  if (var_33)
var_59 = ~var_9 & 10393;
  var_1321 = ~var_9;
}

int main() {
  foo();
  std::cout << "var_59 = " << var_59 << " (8320 expected)\n";

  return 0;
}

> g++ -w -O3 -o out f.cpp; ./out
var_59 = -19582 (8320 expected)
> g++ -w -O2 -o out f.cpp; ./out
var_59 = 8320 (8320 expected)
> g++ -w -O0 -o out f.cpp; ./out
var_59 = 8320 (8320 expected)

[Bug sanitizer/81387] UBSAN consumes too much memory at -O2

[babokin at gmail dot com]

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

--- Comment #3 from Dmitry Babokin  ---
Interesting that you've mentioned -fno-sanitize-recover, I haven't realized
that it has effect on the number of basic blocks. But by default I run
"-fsanitize=undefined -fno-sanitize-recover=undefined", so the numbers that I
posted are for this combination (-fno-sanitize-recover=all is effectively the
same). I've tried without -fno-sanitize-recover=undefined and it is:
-O2 -fsanitize=undefined: 358s, 62Gb
-O1 -fsanitize=undefined: 280s, 2.7Gb

Also clang trunk:
-O2 -fsanitize=undefined: 173s, 1.5Gb
-O2 -fsanitize=undefined -fno-sanitize-recover=undefined: 224s, 1.8Gb

I understand that the reasons for consuming more memory with UBSAN enabled are
quite fundamental, but looking at such an extreme increase may uncover problems
when algorithms consume more that they supposed to.

Again, I'm not insisting on fixing it, I'm rather drawing attention to
suspicious behaviour, which you may consider worth looking at.

[Bug sanitizer/81387] New: UBSAN consumes too much memory at -O2

[babokin at gmail dot com]

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

Bug ID: 81387
   Summary: UBSAN consumes too much memory at -O2
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

Created attachment 41712
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41712=edit
reproducer

I understand that compiling with UBSAN should require more memory, but in case
of scalar code increase in memory consumption by 50x looks a bit too much.

-O0: 13sec, 0.8Gb
-O2: 5s, 0.4Gb
-O0 -fsanitize=undefined: 100s, 2.7Gb
-O2 -fsanitize=undefined: 255s 42.9Gb

So, it may be useful test case to make sure that memory consumption is
reasonable and not beyond expected limits.

Here is stack when memory consumption goes wild:

#0  bitmap_elt_insert_after(bitmap_head*, bitmap_element*, unsigned int) () at
../../gcc/gcc/bitmap.c:409
#1  0x00a6d7cd in bitmap_set_range (head=head@entry=0x249bac630,
start=start@entry=0, count=) at ../../gcc/gcc/bitmap.c:1233
#2  0x00a6fd3e in bitmap_set_range (head=head@entry=0x249bac630,
start=start@entry=0, count=) at ../../gcc/gcc/bitmap.c:1197
#3  0x00b0b186 in df_mir_alloc(bitmap_head*) () at
../../gcc/gcc/df-problems.c:1913
#4  0x00b05971 in df_analyze_problem (dflow=0xe5f0440,
blocks_to_consider=0x5232ed8, postorder=0x27ebe678, n_blocks=120403) at
../../gcc/gcc/df-core.c:1161
#5  0x00b05a7c in df_analyze_1() () at ../../gcc/gcc/df-core.c:1222
#6  0x015d8cbf in find_and_remove_re () at ../../gcc/gcc/ree.c:1216
#7  rest_of_handle_ree () at ../../gcc/gcc/ree.c:1310
#8  (anonymous namespace)::pass_ree::execute(function*) () at
../../gcc/gcc/ree.c:1338
#9  0x00dce3bb in execute_one_pass(opt_pass*) () at
../../gcc/gcc/passes.c:2492
#10 0x00dcec15 in execute_pass_list_1(opt_pass*) () at
../../gcc/gcc/passes.c:2581
#11 0x00dcec27 in execute_pass_list_1(opt_pass*) () at
../../gcc/gcc/passes.c:2582
#12 0x00dcec27 in execute_pass_list_1(opt_pass*) () at
../../gcc/gcc/passes.c:2582
#13 0x00dcec59 in execute_pass_list(function*, opt_pass*) () at
../../gcc/gcc/passes.c:2592
#14 0x00ae11e0 in cgraph_node::expand() () at
../../gcc/gcc/cgraphunit.c:2052
#15 0x00ae2361 in expand_all_functions () at
../../gcc/gcc/cgraphunit.c:2188
#16 symbol_table::compile() [clone .part.54] () at
../../gcc/gcc/cgraphunit.c:2540
#17 0x00ae4807 in compile (this=0x7fb63a52e100) at
../../gcc/gcc/cgraphunit.c:2632
#18 symbol_table::finalize_compilation_unit (this=0x7fb63a52e100) at
../../gcc/gcc/cgraphunit.c:2629
#19 0x00e9c018 in compile_file () at ../../gcc/gcc/toplev.c:493
#20 0x007ffcb6 in do_compile () at ../../gcc/gcc/toplev.c:2021
#21 toplev::main(int, char**) () at ../../gcc/gcc/toplev.c:2155
#22 0x00801cbb in main (argc=15, argv=0x7ffe16a14d48) at
../../gcc/gcc/main.c:39


I don't mind if this bug is closed as "will not be fixed", but such behaviour
is definitely make using UBSAN problematic on larger code bases, as it may
basically nuke the build system. And I'm not sure if it's UBSAN implementation
is to blame or DF analysis consumes more than it should.

[Bug rtl-optimization/81332] GCC crash during "RTL pass: expand" - verify_flow_info: REG_BR_PROB does not match cfg

[babokin at gmail dot com]

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

--- Comment #1 from Dmitry Babokin  ---
I've jut hit another instance on this bug, which mean that it's probably not
too rare and quite possible to hit in the wild.

[Bug rtl-optimization/81332] New: GCC crash during "RTL pass: expand" - verify_flow_info: REG_BR_PROB does not match cfg

[babokin at gmail dot com]

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

Bug ID: 81332
   Summary: GCC crash during "RTL pass: expand" -
verify_flow_info: REG_BR_PROB does not match cfg
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
  Target Milestone: ---

gcc rev250008, x86_64.

> cat f.cpp
extern int var_8, var_18, var_29, var_1365;
long a;
int b;
bool c;
void foo() {
  if (c + 7 << bool(var_8) - 1)
b = 1;
  if (var_29 | b)
var_1365 = a && b && var_18;
}

> g++ -O2 -c f.cpp
f.cpp: In function ‘void foo()’:
f.cpp:10:1: error: verify_flow_info: REG_BR_PROB does not match cfg 3750 7500
 }
 ^
during RTL pass: expand
f.cpp:10:1: internal compiler error: verify_flow_info failed
0xab17ba verify_flow_info()
../../gcc_svn_intel/gcc/cfghooks.c:259
0x1541f26 checking_verify_flow_info
../../gcc_svn_intel/gcc/cfghooks.h:198
0x1541f26 try_optimize_cfg
../../gcc_svn_intel/gcc/cfgcleanup.c:3040
0x1541f26 cleanup_cfg(int)
../../gcc_svn_intel/gcc/cfgcleanup.c:3204
0xaaf38e execute
../../gcc_svn_intel/gcc/cfgexpand.c:6486
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug sanitizer/81281] New: UBSAN: false positive, dropped promotion to long type.

[babokin at gmail dot com]

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

Bug ID: 81281
   Summary: UBSAN: false positive, dropped promotion to long type.
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

gcc x86_64, rev249877.

Looks like this one is deferent from other currently open ubsan bugs.

Promotion to long was dropped, so -2024172551 - (long)ci overflows. Also note,
that removing const modifier from ci definition hides the problem.

> cat f_init.cpp
extern const int ci = 1716607962;
int i = -943738830;
long long ll = -43165919987465092LL;

> cat f.cpp
extern const int ci;
extern int i;
extern long long ll;

int foo() {
  int a = int(-2024172551 - i - (ci - ll)) -
(int(-2024172551 - i - (ci - ll)) -
 int(-2024172551 - (long)ci));
  return a;
}

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

> g++ -fsanitize=undefined -O0 f.cpp f_init.cpp -o out
> ./out
f.cpp:6:7: runtime error: signed integer overflow: -2024172551 - 1716607962
cannot be represented in type 'int'

[Bug tree-optimization/81162] New: UBSAN switch triggers incorrect optimization

[babokin at gmail dot com]

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

Bug ID: 81162
   Summary: UBSAN switch triggers incorrect optimization
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
  Target Milestone: ---

gcc trunk rev249427, x86_64

In presence of -fsanitize=undefined optimisations (-O2) produce wrong code.

> cat f.cpp
#include 
short s;
int i1 = 1;
int i2 = 1;
unsigned char uc = 147;

int main() {
  s = (-uc + 2147483647) << 0;
  if (9031239389974324562ULL >= (-((i1 && i2) + uc) ^ -21096) ) {
printf("OK\n");
  } else {
printf("FAIL\n");
  }

  return 0;
}

> g++ -std=c++11 -fsanitize=undefined -O0 f.cpp -o out
> ./out
OK
> g++ -std=c++11 -fsanitize=undefined -O2 f.cpp -o out
> ./out
FAIL

[Bug sanitizer/81148] New: UBSAN: two more false positives

[babokin at gmail dot com]

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

Bug ID: 81148
   Summary: UBSAN: two more false positives
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

gcc rev249427, x86_64.

> cat f.cpp
int x = -106;
int main() {
  // -123 - (0x8000 - -1)
  bool a = -123 - ((9223372036854775806 ^ ~(x && true)) - -1);
  return 0;
}

> gcc -fsanitize=undefined f.cpp -o out
> ./out
f.cpp:4:41: runtime error: negation of -9223372036854775808 cannot be
represented in type 'long int'; cast to an unsigned type to negate this value
to itself
f.cpp:4:17: runtime error: signed integer overflow: -9223372036854775808 + -124
cannot be represented in type 'long int'

[Bug sanitizer/81097] New: UBSAN: false positive for not existing negation operator and a bogus message

[babokin at gmail dot com]

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

Bug ID: 81097
   Summary: UBSAN: false positive for not existing negation
operator and a bogus message
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

gcc rev249202.

Test case doesn't contain negations, but ubsan claims that negation has a
problem.

Error message also contains reference to '' type. Though problems seem
to be related.

> cat f.cpp
unsigned int a = 3309568;
unsigned int b = -1204857327;
short c = -10871;
short x;
int main() {
  x = (short(~a) | ~c) +  (short(~b) | ~c);
  return 0;
}

> g++ -fsanitize=undefined -O0 f.cpp -o out
> ./out
f.cpp:6:18: runtime error: negation of -32768 cannot be represented in type
''; cast to an unsigned type to negate this value to itself

[Bug sanitizer/81065] UBSAN: false positive as a result of distribution involving different types

[babokin at gmail dot com]

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

--- Comment #5 from Dmitry Babokin  ---
Thanks for blazingly fast fixes. This enables filing more bugs, as it's
difficult to distinguish between unrelated fails before one of them is actually
fixed.

[Bug sanitizer/81088] New: UBSAN: false positive as a result of reassosiation

[babokin at gmail dot com]

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

Bug ID: 81088
   Summary: UBSAN: false positive as a result of reassosiation
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

gcc rev249171.

> cat f.cpp
short s = 2;
short y = 1;
int i;
int main() {
  i = -(s + int(~unsigned(0 / y))) + 0x7fff;
  return 0;
}

> g++ -fsanitize=undefined -O0 f.cpp -o out
> ./out
f.cpp:5:36: runtime error: signed integer overflow: -2 + -2147483648 cannot be
represented in type 'int'

[Bug sanitizer/81065] New: UBSAN: false positive as a result of distribution involving different types

[babokin at gmail dot com]

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

Bug ID: 81065
   Summary: UBSAN: false positive as a result of distribution
involving different types
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

Similar to #80932, but note that x is unsigned char, it's essential.

> cat f.cpp
unsigned char x = 154;
int foo() {
  // 8575 * (254408 - 9057) = 8575 * 245351 = 2103884825 = 0x7d66bc19
  return 8575 * (1652 * x - 9057);
}

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

> g++ -fsanitize=undefined -O0 f.cpp -o out

> ./out
f.cpp:4:33: runtime error: signed integer overflow: 154 * 14165900 cannot be
represented in type 'int'
f.cpp:4:33: runtime error: signed integer overflow: -2113418696 + -77663775
cannot be represented in type 'int'

[Bug middle-end/66313] Unsafe factorization of a*b+a*c

[babokin at gmail dot com]

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

--- Comment #20 from Dmitry Babokin  ---
I've created #80932 for c1*(c2*v1-c3*v2)=>c1*c2*v1-c1*c3*v2 issue.

--- Comment #21 from Dmitry Babokin  ---
I've created #80932 for c1*(c2*v1-c3*v2)=>c1*c2*v1-c1*c3*v2 issue.

[Bug middle-end/66313] Unsafe factorization of a*b+a*c

[babokin at gmail dot com]

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

--- Comment #20 from Dmitry Babokin  ---
I've created #80932 for c1*(c2*v1-c3*v2)=>c1*c2*v1-c1*c3*v2 issue.

--- Comment #21 from Dmitry Babokin  ---
I've created #80932 for c1*(c2*v1-c3*v2)=>c1*c2*v1-c1*c3*v2 issue.

[Bug sanitizer/80932] New: UBSAN: false positive as a result of distribution: c1*(c2*v1-c3*v2)=>c1*c2*v1-c1*c3*v2

[babokin at gmail dot com]

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

Bug ID: 80932
   Summary: UBSAN: false positive as a result of distribution:
c1*(c2*v1-c3*v2)=>c1*c2*v1-c1*c3*v2
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

gcc trunk rev248580, x86_64.

Transformation causing troubles: const1 * (const2 * var1 - const3 * var2) =>
const1*const2*var1 - const3*var2;

> cat f.cpp

#include 
signed char var_10 = 77;
long long int var_13 = 1547580415367384384LL;

long foo() {
  long a = -6 *
// 0xbf8a6c24aa342bc0 = -4644781160949077056
   (long(16636733186465668563ULL * var_13 ) -
// 0xd4cdd0f8c2df13cf = -3112602000603278385
long(678280911954875019ULL * var_10));
  return a;
}

int main () {
long a = foo ();
std::cout << a << std::endl;
return 0;
}

> g++ -fsanitize=undefined -O0 f.cpp; ./a.out

f.cpp:6:8: runtime error: signed integer overflow: -9024801181724640896 -
228867929910118694 cannot be represented in type 'long int'
9193074962074792026

[Bug middle-end/66313] Unsafe factorization of a*b+a*c

[babokin at gmail dot com]

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

--- Comment #17 from Dmitry Babokin  ---
Any chances for the fix for this bug?

Looks like this one stands as a last obstacle to claim UBSAN in GCC fully
functional.

I still see quite a few errors, but looks like all of them are attributed to
this problem. Anyway, I have no way to verify this before this bug is fixed.

[Bug sanitizer/80875] New: UBSAN: compile time crash in fold_binary_loc at fold-const.c:9817

[babokin at gmail dot com]

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

Bug ID: 80875
   Summary: UBSAN: compile time crash in fold_binary_loc at
fold-const.c:9817
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

gcc rev248384, x86_64.

> cat f.cpp
void foo() {
~2147483647 * (0 / 0);
}

> g++ -fsanitize=undefined -w -c f.cpp
f.cpp: In function ‘void foo()’:
f.cpp:3:1: internal compiler error: tree check: expected class ‘constant’, have
‘unary’ (negate_expr) in fold_binary_loc, at fold-const.c:9817
 }
 ^
0x10384a7 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc_svn/gcc/tree.c:9909
<...>

[Bug middle-end/66313] Unsafe factorization of a*b+a*c

[babokin at gmail dot com]

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

--- Comment #16 from Dmitry Babokin  ---
Here's another test case with a contrary example, where a variable gets pulled
into the braces and it also causes false positive. Transformation is: const1 *
(const2 * var1 - const3 * var2) => const1*const2*var1 - const3*var2;

> cat f.cpp
#include 
signed char var_10 = 77;
long long int var_13 = 1547580415367384384LL;

long foo() {
  long a = -6 *
// 0xbf8a6c24aa342bc0 = -4644781160949077056
   (long(16636733186465668563ULL * var_13 ) -
// 0xd4cdd0f8c2df13cf = -3112602000603278385
long(678280911954875019ULL * var_10));
  return a;
}

int main () {
long a = foo ();
std::cout << a << std::endl;
return 0;
}

> g++ -fsanitize=undefined -O0 f.cpp; ./a.out
f.cpp:6:8: runtime error: signed integer overflow: -9024801181724640896 -
228867929910118694 cannot be represented in type 'long int'
9193074962074792026

If it's unrelated issue, let me know and I'll file a separate bug for it.

[Bug ipa/80597] [8 Regression] internal compiler error: in compute_inline_parameters, at ipa-inline-analysis.c:3126

[babokin at gmail dot com]

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

--- Comment #17 from Dmitry Babokin  ---
Yes, it's fix with current trunk.

[Bug middle-end/66313] Unsafe factorization of a*b+a*c

[babokin at gmail dot com]

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

--- Comment #15 from Dmitry Babokin  ---
The bug is almost 2 years old. I consider it's quite important, as false
positives make UBSAN not usable on any large codebases.

[Bug sanitizer/80847] UBSAN: yet another false positive (part2)

[babokin at gmail dot com]

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

Dmitry Babokin  changed:

   What|Removed |Added

 CC||babokin at gmail dot com,
   ||mpolacek at gcc dot gnu.org,
   ||vsevolod.livinskij at frtk dot 
ru

--- Comment #1 from Dmitry Babokin  ---
Seems like UBSAN instrumentation is done too late.

[Bug sanitizer/80847] New: UBSAN: yet another false positive (part2)

[babokin at gmail dot com]

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

Bug ID: 80847
   Summary: UBSAN: yet another false positive (part2)
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

gcc rev248312, x86_64.

> cat f.cpp
long long int a = -8619712598616233901LL;
long long int b = -2492839055825936744LL;
long long int c = 0;
int main() {
  if (c * a + b * c)
return 1;
  return 0;
}

> g++ -fsanitize=undefined -O0 f.cpp

> ./a.out
f.cpp:5:13: runtime error: signed integer overflow: -8619712598616233901 +
-2492839055825936744 cannot be represented in type 'long long int'

[Bug ipa/80597] [8 Regression] internal compiler error: in compute_inline_parameters, at ipa-inline-analysis.c:3126

[babokin at gmail dot com]

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

--- Comment #14 from Dmitry Babokin  ---
Disregard my previous comment.

Original test case still fails with compiler switches that I've originally
reported (-fsanitize=undefined).

[Bug ipa/80597] [8 Regression] internal compiler error: in compute_inline_parameters, at ipa-inline-analysis.c:3126

[babokin at gmail dot com]

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

--- Comment #13 from Dmitry Babokin  ---
The attached patch fixes my original test case.

[Bug sanitizer/80800] New: UBSAN: yet another false positive

[babokin at gmail dot com]

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

Bug ID: 80800
   Summary: UBSAN: yet another false positive
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

gcc rev248130, x86_64

> cat f.cpp
short var_29 = 26289;
unsigned short var_48 = 20359;
unsigned short var_80 = 21070;
int foo() {
  return 72 * (var_48 * 8531 * (var_80 / var_29));
}

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

> g++ -fsanitize=undefined f.cpp

> ./a.out
f.cpp:5:49: runtime error: signed integer overflow: 20359 * 614232 cannot be
represented in type 'int'

[Bug sanitizer/80386] UBSAN: false positive - constant folding and reassosiation before instrumentation

[babokin at gmail dot com]

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

--- Comment #8 from Dmitry Babokin  ---
Many failing tests are fixed, but quite few still failing. Should I add failing
test cases here or create a separate bug?

[Bug ipa/80597] New: internal compiler error: in compute_inline_parameters, at ipa-inline-analysis.c:3126

[babokin at gmail dot com]

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

Bug ID: 80597
   Summary: internal compiler error: in compute_inline_parameters,
at ipa-inline-analysis.c:3126
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
  Target Milestone: ---

Created attachment 41299
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41299=edit
reproducer

gcc top of the trunk, r247455, x86_64

Test is quite big, I failed to reduce it. UBSAN switch is also required to
reproduce.

> time g++ -std=c++11 -fsanitize=undefined -w -O0 -c func.i
func.cpp: In function ‘void foo()’:
func.cpp:1181:1: internal compiler error: in compute_inline_parameters, at
ipa-inline-analysis.c:3126
 }
 ^
0xb96459 compute_inline_parameters(cgraph_node*, bool)
../../gcc_svn/gcc/ipa-inline-analysis.c:3125
0xb96668 compute_inline_parameters_for_current
../../gcc_svn/gcc/ipa-inline-analysis.c:3137
0xb96668 execute
../../gcc_svn/gcc/ipa-inline-analysis.c:3167
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

real4m53.780s
user4m49.790s
sys 0m3.985s

[Bug sanitizer/80536] New: UBSAN: compile time segfault

[babokin at gmail dot com]

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

Bug ID: 80536
   Summary: UBSAN: compile time segfault
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---

> cat f.cpp
extern unsigned char var_67;
void foo() {
  2 * (var_67 * (unsigned long long)(-0 - -2565537134464303311UL)) % 1;
}

> g++ -fsanitize=undefined -O0 -c f.cpp
g++: internal compiler error: Segmentation fault (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.

gcc is top of the trunk (r247282), x86_64.

[Bug sanitizer/80349] [6 Regression] UBSAN: compile time crash with "type mismatch in binary expression" message

[babokin at gmail dot com]

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

--- Comment #12 from Dmitry Babokin  ---
int var;
long a;
long foo() {
  int i = !(1 & 808U ^ 1 & var) >> 0;
  long l = 0 % ((a & 1) != (3053241240409UL & 1));
  return i+l;
}

[Bug sanitizer/80349] [6 Regression] UBSAN: compile time crash with "type mismatch in binary expression" message

[babokin at gmail dot com]

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

--- Comment #8 from Dmitry Babokin  ---
I also see crashes reporting problems with ^ operator.

[Bug sanitizer/80349] [6 Regression] UBSAN: compile time crash with "type mismatch in binary expression" message

[babokin at gmail dot com]

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

--- Comment #7 from Dmitry Babokin  ---
One more. GCC r247062.

> cat f.cpp
unsigned long int ll;
int foo() {
  return (2036854775807 >> ll & char(207648476159223) | 502810590243120797UL)
<< 0;
}

> g++ -fsanitize=undefined -O0 -c f.cpp
f.cpp: In function ‘int foo()’:
f.cpp:2:5: error: type mismatch in binary expression
 int foo() {
 ^~~
long unsigned int

long int

long unsigned int

D.2746 = _2 | 502810590243120797;
f.cpp:2:5: internal compiler error: verify_gimple failed

[Bug sanitizer/80386] UBSAN: false positive - constant folding and reassosiation before instrumentation

[babokin at gmail dot com]

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

--- Comment #4 from Dmitry Babokin  ---
Any update? This bug makes gcc ubsan implementation almost unusable on any real
application.

[Bug sanitizer/80403] UBSAN: compile time crash with "type mismatch in binary expression" message in / and % expr

[babokin at gmail dot com]

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

--- Comment #11 from Dmitry Babokin  ---
I confirm that the latest patch fixes all UBSAN compile time problems that I
have. Thanks!

Though correctness issues remain - PR80386.

[Bug sanitizer/80403] UBSAN: compile time crash with "type mismatch in binary expression" message in / and % expr

[babokin at gmail dot com]

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

--- Comment #8 from Dmitry Babokin  ---
Three errors in one test case. GCC r246882.

> cat f.cpp
extern const long long int var_7;
extern unsigned long int var_59;
int foo() {
  int a = (0 - 40U <= (0 == 8)) << !var_59 << (0 < var_7) == 0;
  int b = ((0 ^ 0) < long(1066066618772207110 <= 0)) / 0 << 0;
  return a+b;
}

> g++ -w -fsanitize=undefined -O0 -c f.cpp
f.cpp: In function ‘int foo()’:
f.cpp:3:5: error: mismatching comparison operand types
 int foo() {
 ^~~
unsigned int
int
_4 = D.2761 < 0;
f.cpp:3:5: error: type mismatch in shift expression
int
unsigned int
int
_19 = D.2761 << _18;
f.cpp:3:5: error: type mismatch in binary expression
int

long int

int

D.2772 = 0 / 0;
f.cpp:3:5: internal compiler error: verify_gimple failed

[Bug sanitizer/80403] UBSAN: compile time crash with "type mismatch in binary expression" message in / and % expr

[babokin at gmail dot com]

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

--- Comment #7 from Dmitry Babokin  ---
80404 and 80405 seemed similar, but different to me, so I decided to report
them separately. Anyway, after the latest fixes I still see 2 compile crashes.
I'm reducing them and will report here.

[Bug sanitizer/80405] New: UBSAN: compile time crash with "type mismatch in shift expression" error

[babokin at gmail dot com]

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

Bug ID: 80405
   Summary: UBSAN: compile time crash with "type mismatch in shift
expression" error
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---

gcc x86_64, top of the trunk.

> cat f.cpp
extern unsigned int var_60, var_110;
void foo() {
var_110 = (!~0 >= unsigned(0 < 0)) << var_60;
}

> g++ -fsanitize=undefined -w -O0 -c f.cpp
f.cpp: In function ‘void foo()’:
f.cpp:2:6: error: type mismatch in shift expression
 void foo() {
  ^~~
int
unsigned int
unsigned int
_2 = 1 << var_60.0;
f.cpp:2:6: internal compiler error: verify_gimple failed
<...>

[Bug sanitizer/80404] New: UBSAN: compile time crash with "non-trivial conversion at assignment" error

[babokin at gmail dot com]

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

Bug ID: 80404
   Summary: UBSAN: compile time crash with "non-trivial conversion
at assignment" error
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---

gcc x86_64, top of the trunk.

> cat f.cpp
extern short var_54;
unsigned foo() {
  unsigned a = (0 < 0 >= (0 >= 0)) / unsigned(var_54);
  return a;
}

> g++ -fsanitize=undefined -w -O0 -c f.cpp
f.cpp: In function ‘unsigned int foo()’:
f.cpp:2:10: error: non-trivial conversion at assignment
 unsigned foo() {
  ^~~
unsigned int
int
a = 0;
f.cpp:2:10: internal compiler error: verify_gimple failed
<...>

[Bug sanitizer/80403] New: UBSAN: compile time crash with "type mismatch in binary expression" message in / and % expr

[babokin at gmail dot com]

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

Bug ID: 80403
   Summary: UBSAN: compile time crash with "type mismatch in
binary expression" message in / and % expr
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---

gcc x86_64, top of the trunk with patch from 80349. This seems related, but
different.

> cat f.cpp
unsigned foo() {
   unsigned a = unsigned(!(6044238 >> 0) >= (0 < 0)) % 0;
   unsigned b = unsigned(!(6044238 >> 0) >= (0 < 0)) / 0;
   return a+b;
}

> g++ -fsanitize=undefined -w -O0 -c f.cpp
f.cpp: In function ‘unsigned int foo()’:
f.cpp:1:10: error: type mismatch in binary expression
 unsigned foo() {
  ^~~
unsigned int

int

unsigned int

a = 1 % 0;
f.cpp:1:10: error: type mismatch in binary expression
unsigned int

int

unsigned int

b = 1 / 0;
f.cpp:1:10: internal compiler error: verify_gimple failed

[Bug sanitizer/80386] New: UBSAN: false positive - constant folding and reassosiation before instrumentation

[babokin at gmail dot com]

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

Bug ID: 80386
   Summary: UBSAN: false positive - constant folding and
reassosiation before instrumentation
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---

gcc ubsan incorrectly does code instrumentation triggering false positive
alarm.

This looks like expression reassosiation and constant folding were done before
UBSAN instrumentation, turning legal code to illegal. 

> cat f.cpp
static unsigned long long int member_1_3 = 13996271126042720493ULL;

int main() {
  // 2921 - 14573 + MAX_INT
  (((2921 + 0) - short(member_1_3)) + 0x7fff) >> 0;
  return 0;
}


> g++ -fsanitize=undefined -O0 -o out f.cpp
> ./out
f.cpp:5:37: runtime error: signed integer overflow: -2147480728 - 14573 cannot
be represented in type 'int'


I'm using top of the trunk gcc.

[Bug sanitizer/80349] [6/7 Regression] UBSAN: compile time crash with "type mismatch in binary expression" message

[babokin at gmail dot com]

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

--- Comment #3 from Dmitry Babokin  ---
PR80348 is fixed, but this still fails.

[Bug sanitizer/80348] [6 Regression] UBSAN: compile time crash in ubsan_instrument_division

[babokin at gmail dot com]

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

--- Comment #7 from Dmitry Babokin  ---
These tests are still failing:
> cat f1.cpp
void foo() { 0 / unsigned(!(0 - 3) >= (0 > 0)); }
> cat f2.cpp
extern long long int var_58;
void foo() { (0 >= 10253361740180 >= long(0 >= 0)) % var_58; }
> cat f3.cpp
void foo() { (0 < 0 >= (0 < 0 < 0)) % (unsigned(2) << 0); }

gcc revision 246776

[Bug sanitizer/80348] UBSAN: compile time crash in ubsan_instrument_division

[babokin at gmail dot com]

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

--- Comment #1 from Dmitry Babokin  ---
*** Bug 80347 has been marked as a duplicate of this bug. ***

[Bug sanitizer/80347] UBSAN: compile time crash in ubsan_instrument_division

[babokin at gmail dot com]

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

Dmitry Babokin  changed:

   What|Removed |Added

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

--- Comment #1 from Dmitry Babokin  ---
Sorry for duplication. I had a glitch in browser and submitted two identical
bugs.

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

[Bug sanitizer/80350] New: UBSAN changes code semantics when -fno-sanitize-recover=undefined is used

[babokin at gmail dot com]

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

Bug ID: 80350
   Summary: UBSAN changes code semantics when
-fno-sanitize-recover=undefined is used
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---

Top of the trunk, x86_64.

The following test case when compiled with "-fsanitize=undefined
-fno-sanitize-recover=undefined -O0" produces incorrect result. Correct result
is 1. Incorrect is 0.

> cat f.cpp
#include 
unsigned int x = 3153848182U;
unsigned int y = 0;

void foo() {
  int a(!0 >> !x * 500740718);
  y = a;
}

int main () {
foo ();
printf("Result = %u\n", y);
return 0;
}

> g++ f.cpp -o out -fsanitize=undefined -fno-sanitize-recover=undefined -O0
> ./out
Result = 0
> g++ f.cpp -o out -fsanitize=undefined -fno-sanitize-recover=undefined -O2
> ./out
Result = 1
> g++ f.cpp -o out -O0
> ./out
Result = 1
> g++ f.cpp -o out -O2
> ./out
Result = 1

[Bug sanitizer/80349] New: UBSAN: compile time crash with "type mismatch in binary expression" message

[babokin at gmail dot com]

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

Bug ID: 80349
   Summary: UBSAN: compile time crash with "type mismatch in
binary expression" message
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---

Top of the trunk gcc on x86_64

> cat f.cpp
extern const long long int var_20;
void foo() { int((var_20 & 50 | 051UL) << 0) << 0; }

> g++ -fsanitize=undefined -w -O0 -c f.cpp
f.cpp: In function ‘void foo()’:
f.cpp:2:6: error: type mismatch in binary expression
 void foo() { int((var_20 & 50 | 051UL) << 0) << 0; }
  ^~~
long long unsigned int

long long int

long long unsigned int

_11 = var_20.2_10 & 18;
f.cpp:2:6: internal compiler error: verify_gimple failed
0xdae9ad verify_gimple_in_seq(gimple*)
../../gcc_svn_intel/gcc/tree-cfg.c:4934
0xafe2bd gimplify_body(tree_node*, bool)
../../gcc_svn_intel/gcc/gimplify.c:12500
0xafe624 gimplify_function_tree(tree_node*)
../../gcc_svn_intel/gcc/gimplify.c:12590
0x96e9df cgraph_node::analyze()
../../gcc_svn_intel/gcc/cgraphunit.c:657
0x9719c9 analyze_functions
../../gcc_svn_intel/gcc/cgraphunit.c:1118
0x972a82 symbol_table::finalize_compilation_unit()
../../gcc_svn_intel/gcc/cgraphunit.c:2603
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug sanitizer/80348] New: UBSAN: compiler time crash in ubsan_instrument_division

[babokin at gmail dot com]

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

Bug ID: 80348
   Summary: UBSAN: compiler time crash in
ubsan_instrument_division
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---

Top of the trunk gcc on x86_64

> cat f.cpp
void foo() {
  if (0)
unsigned((0 != 60806) > (0 != 0)) / 0;
}

> g++ -fsanitize=undefined -w -O0 -c f.cpp
f.cpp: In function ‘void foo()’:
f.cpp:3:41: internal compiler error: in ubsan_instrument_division, at
c-family/c-ubsan.c:46
 unsigned((0 != 60806) > (0 != 0)) / 0;
 ^
0x8d5ffb ubsan_instrument_division(unsigned int, tree_node*, tree_node*)
../../gcc/gcc/c-family/c-ubsan.c:45
0x76d95a cp_build_binary_op(unsigned int, tree_code, tree_node*, tree_node*,
int)
../../gcc/gcc/cp/typeck.c:5226
0x6158b4 build_new_op_1
../../gcc/gcc/cp/call.c:5982
0x61635e build_new_op(unsigned int, tree_code, int, tree_node*, tree_node*,
tree_node*, tree_node**, int)
../../gcc/gcc/cp/call.c:6026
0x75e622 build_x_binary_op(unsigned int, tree_code, tree_node*, tree_code,
tree_node*, tree_code, tree_node**, int)
../../gcc/gcc/cp/typeck.c:3928
<...>

[Bug sanitizer/80347] New: UBSAN: compiler time crash in ubsan_instrument_division

[babokin at gmail dot com]

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

Bug ID: 80347
   Summary: UBSAN: compiler time crash in
ubsan_instrument_division
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---

Top of the trunk gcc on x86_64

> cat f.cpp
void foo() {
  if (0)
unsigned((0 != 60806) > (0 != 0)) / 0;
}

> g++ -fsanitize=undefined -w -O0 -c f.cpp
f.cpp: In function ‘void foo()’:
f.cpp:3:41: internal compiler error: in ubsan_instrument_division, at
c-family/c-ubsan.c:46
 unsigned((0 != 60806) > (0 != 0)) / 0;
 ^
0x8d5ffb ubsan_instrument_division(unsigned int, tree_node*, tree_node*)
../../gcc/gcc/c-family/c-ubsan.c:45
0x76d95a cp_build_binary_op(unsigned int, tree_code, tree_node*, tree_node*,
int)
../../gcc/gcc/cp/typeck.c:5226
0x6158b4 build_new_op_1
../../gcc/gcc/cp/call.c:5982
0x61635e build_new_op(unsigned int, tree_code, int, tree_node*, tree_node*,
tree_node*, tree_node**, int)
../../gcc/gcc/cp/call.c:6026
0x75e622 build_x_binary_op(unsigned int, tree_code, tree_node*, tree_code,
tree_node*, tree_code, tree_node**, int)
../../gcc/gcc/cp/typeck.c:3928
<...>

[Bug regression/80297] New: Compiler time crash: type mismatch in binary expression

[babokin at gmail dot com]

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

Bug ID: 80297
   Summary: Compiler time crash: type mismatch in binary
expression
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: regression
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
  Target Milestone: ---

Top of the tree gcc crashes when compiler the following test case. Gcc 4.8
works well.

> cat f.cpp
extern const unsigned long int var_14;
extern const long long int var_15;
void foo() {
  if (0)
int a = 809 >> -(var_14 & !var_15) + var_14 - (long long)(var_14 &
!var_15);
}


> g++ -std=c++11 -w -O0 -c f.cpp
f.cpp: In function ‘void foo()’:
f.cpp:3:6: error: type mismatch in binary expression
 void foo() {
  ^~~
unsigned int

unsigned int

bool

_8 = _6 - _7;
f.cpp:3:6: internal compiler error: verify_gimple failed
0xdae8dd verify_gimple_in_seq(gimple*)
../../gcc/gcc/tree-cfg.c:4934
0xafe1cd gimplify_body(tree_node*, bool)
../../gcc/gcc/gimplify.c:12500
0xafe534 gimplify_function_tree(tree_node*)
../../gcc/gcc/gimplify.c:12590
0x96e90f cgraph_node::analyze()
../../gcc/gcc/cgraphunit.c:657
0x9718f9 analyze_functions
../../gcc/gcc/cgraphunit.c:1118
0x9729b2 symbol_table::finalize_compilation_unit()
../../gcc/gcc/cgraphunit.c:2603
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug middle-end/79399] GCC fails to compile big source at -O0

[babokin at gmail dot com]

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

--- Comment #11 from Dmitry Babokin  ---
With new patch it compiled successfully. It took 41G of memory and 5:25 hours
to complete.

[Bug middle-end/79399] GCC fails to compile big source at -O0

[babokin at gmail dot com]

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

--- Comment #7 from Dmitry Babokin  ---
It crashed.
> /usr/bin/time --format="Max %M kb\nreal %E\nuser %U\nsys%S" g++ -std=c++11 -w 
> -O0 -march=nehalem -o gcc_no_opt_func.o -c func.cpp
func.cpp: In function ‘void foo()’:
func.cpp:26656:1: internal compiler error: Segmentation fault
 }
 ^
0xd62f9f crash_signal
../../gcc_svn/gcc/toplev.c:333
0xbb902e find_costs_and_classes
../../gcc_svn/gcc/ira-costs.c:1697
0xbba119 ira_costs()
../../gcc_svn/gcc/ira-costs.c:2242
0xbb3569 ira_build()
../../gcc_svn/gcc/ira-build.c:3420
0xba9d42 ira
../../gcc_svn/gcc/ira.c:5236
0xba9d42 execute
../../gcc_svn/gcc/ira.c:5541
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
Max 30306372 kb
real 40:09.53
user 2349.01
sys53.94

[Bug middle-end/79399] GCC fails to compile big source at -O0

[babokin at gmail dot com]

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

--- Comment #6 from Dmitry Babokin  ---
I've started the compilation, it should take more than an hour to finish. Will
report back when it's done.

[Bug middle-end/79399] GCC fails to compile big source at -O0

[babokin at gmail dot com]

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

--- Comment #4 from Dmitry Babokin  ---
The purpose of the generator is to break a compiler, that's why it's a single
function in this case, but not many. Though with smaller functions we break
compilers too.

This is the generator: https://github.com/01org/yarpgen

[Bug middle-end/79399] New: GCC fails to compile big source at -O0

[babokin at gmail dot com]

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

Bug ID: 79399
   Summary: GCC fails to compile big source at -O0
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
  Target Milestone: ---

The bug report is not very typical, but it may help fixing the real issue,
which is hard to find and debug in other corricumstances. I don't mind if it's
closed as "will not be fixed", but still hope it could be useful.

The test case is huge auto generated C++ file - 260Mb of source code (1.7Mb
when compressed). The code is scalar. So I would expect that GCC compiles it
without issues at least at -O0. But it fails trying to allocate
18446744071569032860 bytes, which is... 1.8*10^19. Which is too much in any
case. This is unreasonable value. But if converted to hex format it's
0x806a469c. Probably someone tries to allocate more than 2^32 bytes in
64bit compiler and has an issue with passing 64 bit size (size_t actually) and
uses 32 bit value instead?

> /usr/bin/time --format="Max %M kb\nreal %E\nuser %U\nsys %S" g++ -std=c++11 
> -w -O0 -march=nehalem -o gcc_no_opt_func.o -c func.cpp

cc1plus: out of memory allocating 18446744071569032860 bytes after a total of
9836802048 bytes
Max 24979592 kb
real 22:27.38
user 1321.54
sys 24.45

The test case is, again, 1.7Mb when compressed, so I can't attach it to the bug
report. But it's available here:

https://drive.google.com/open?id=0Bxh4sVF04yhxWFNzazVxUWVnUDA

Compiler that I'm using is couple days old trunk:
> gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/gcc/bin_svn/libexec/gcc/x86_64-pc-linux-gnu/7.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc_svn/configure --with-arch=corei7 --with-cpu=corei7
--enable-clocale=gnu --with-system-zlib --enable-shared --with-demangler-in-ld
--enable-cloog-backend=isl --with-fpmath=sse --prefix=/gcc/bin_svn/
--enable-languages=c,c++,lto : (reconfigured) ../gcc_svn_intel/configure
--with-arch=corei7 --with-cpu=corei7 --enable-clocale=gnu --with-system-zlib
--enable-shared --with-demangler-in-ld --enable-cloog-backend=isl
--with-fpmath=sse --prefix=/gcc/bin_svn/ --enable-languages=c,c++,lto
--no-create --no-recursion : (reconfigured) ../gcc_svn/configure
--with-arch=corei7 --with-cpu=corei7 --enable-clocale=gnu --with-system-zlib
--enable-shared --with-demangler-in-ld --enable-cloog-backend=isl
--with-fpmath=sse --prefix=/gcc/bin_svn/ --enable-languages=c,c++,lto
--no-create --no-recursion : (reconfigured) ../gcc_svn/configure
--with-arch=corei7 --with-cpu=corei7 --enable-clocale=gnu --with-system-zlib
--enable-shared --with-demangler-in-ld --enable-cloog-backend=isl
--with-fpmath=sse --prefix=/gcc/bin_svn/ --enable-languages=c,c++,lto
--no-create --no-recursion
Thread model: posix
gcc version 7.0.1 20170203 (experimental) (GCC)

[Bug middle-end/78769] [7 Regression] Incorrect arithmetic optimization for (a < 0) << 29 >> 1;

[babokin at gmail dot com]

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

--- Comment #2 from Dmitry Babokin  ---
I've used r243504, the latest available on git://gcc.gnu.org/git/gcc.git

[Bug middle-end/78769] New: [7 Regression] Incorrect arithmetic optimization for (a < 0) << 29 >> 1;

[babokin at gmail dot com]

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

Bug ID: 78769
   Summary: [7 Regression] Incorrect arithmetic optimization for
(a < 0) << 29 >> 1;
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
  Target Milestone: ---

> cat bug.cpp
#include 
char a = -110;
unsigned long long int b;

void foo();

int main() {
  foo();
  printf("0x%llx\n", b);
  return 0;
}

> cat bug2.cpp
extern char a;
extern unsigned long long int b;
void foo() {
  b = (a < 0) << 29 >> 1;
}

> g++ -w -O0 -o no_opt bug.cpp bug2.cpp
> ./no_opt
0x1000

> g++ -w -O1 -o opt bug.cpp bug2.cpp
> ./opt
0x0

> g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/home/dybaboki/gcc/bin/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc_github/configure --with-arch=corei7 --with-cpu=corei7
--enable-clocale=gnu --with-system-zlib --enable-shared --with-demangler-in-ld
--enable-cloog-backend=isl --with-fpmath=sse --prefix=/home/dybaboki/gcc/bin
--enable-languages=c,c++,lto : (reconfigured) ../gcc_github/configure
--with-arch=corei7 --with-cpu=corei7 --enable-clocale=gnu --with-system-zlib
--enable-shared --with-demangler-in-ld --enable-cloog-backend=isl
--with-fpmath=sse --prefix=/home/dybaboki/gcc/bin --enable-languages=c,c++,lto
--no-create --no-recursion
Thread model: posix
gcc version 7.0.0 20161209 (experimental) (GCC)

[Bug middle-end/78726] New: [5/6/7 Regression] Incorrect unsigned arithmetic optimization

[babokin at gmail dot com]

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

Bug ID: 78726
   Summary: [5/6/7 Regression] Incorrect unsigned arithmetic
optimization
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
  Target Milestone: ---

Created attachment 40279
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40279=edit
reproducer

-O2 produces different result than -O0 for unsigned arithmetic.

Reproduces with gcc 5, 6, and 7, while 4.9 works fine.

> cat driver.cpp
#include 

unsigned char A = 36;
unsigned char B = 173;
unsigned long int C;

extern void foo ();

int main () {
foo ();
printf("%lu\n", C);
return 0;
}
> cat func.cpp
extern unsigned char A;
extern unsigned char B;
extern unsigned long int C;

void foo() {
  unsigned a = ~A;
  C = a * B * B + 1023094746 * a;
}

> g++ -O0 -o no_opt driver.cpp func.cpp
> ./no_opt
799092689
> g++ -O2 -o opt driver.cpp func.cpp
> ./opt
800200062

[Bug target/78720] New: [7 Regression] Illegal instruction in generated code

[babokin at gmail dot com]

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

Bug ID: 78720
   Summary: [7 Regression] Illegal instruction in generated code
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
  Target Milestone: ---

Created attachment 40278
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40278=edit
reproducer

> g++ -O2 -march=nehalem -o opt illegal_inst.cpp illegal_inst_const.cpp
> ./opt
Illegal instruction

This is regression, which was introduced in trunk couple days ago.

> gcc --version
gcc (GCC) 7.0.0 20161207 (experimental)

[Bug target/78438] New: incorrect comparison optimization

[babokin at gmail dot com]

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

Bug ID: 78438
   Summary: incorrect comparison optimization
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
  Target Milestone: ---

Created attachment 40093
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40093=edit
reproducer

> g++ -O0 main.cpp func.cpp -o no_opt; ./no_opt
0
> g++ -O1 main.cpp func.cpp -o opt; ./opt
2

> cat main.cpp
#include 

char C = 0;
int I = 197412621;

void foo();

int main() {
  foo();
  printf("%d\n", C);
}

> cat func.cpp
extern char C;
extern int I;
void foo() {
  C = 0 > (short) (I >> 11);
}

> g++ -v

Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/home/dybaboki/gcc/bin/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --with-arch=corei7 --with-cpu=corei7
--enable-clocale=gnu --with-system-zlib --enable-shared --with-demangler-in-ld
--enable-cloog-backend=isl --with-fpmath=sse --prefix=/home/dybaboki/gcc/bin
--enable-languages=c,c++,fortran,lto : (reconfigured) ../gcc/configure
--with-arch=corei7 --with-cpu=corei7 --enable-clocale=gnu --with-system-zlib
--enable-shared --with-demangler-in-ld --enable-cloog-backend=isl
--with-fpmath=sse --prefix=/home/dybaboki/gcc/bin
--enable-languages=c,c++,fortran,lto : (reconfigured) ../gcc/configure
--with-arch=corei7 --with-cpu=corei7 --enable-clocale=gnu --with-system-zlib
--enable-shared --with-demangler-in-ld --enable-cloog-backend=isl
--with-fpmath=sse --prefix=/home/dybaboki/gcc/bin
--enable-languages=c,c++,fortran,lto : (reconfigured) ../gcc_github/configure
--with-arch=corei7 --with-cpu=corei7 --enable-clocale=gnu --with-system-zlib
--enable-shared --with-demangler-in-ld --enable-cloog-backend=isl
--with-fpmath=sse --prefix=/home/dybaboki/gcc/bin
--enable-languages=c,c++,fortran,lto --no-create --no-recursion :
(reconfigured) ../gcc/configure --with-arch=corei7 --with-cpu=corei7
--enable-clocale=gnu --with-system-zlib --enable-shared --with-demangler-in-ld
--enable-cloog-backend=isl --with-fpmath=sse --prefix=/home/dybaboki/gcc/bin
--enable-languages=c,c++,fortran,lto --no-create --no-recursion
Thread model: posix
gcc version 7.0.0 20161119 (experimental) (GCC)

[Bug target/78436] New: incorrect write to larger-than-type bitfield (signed char x:9)

[babokin at gmail dot com]

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

Bug ID: 78436
   Summary: incorrect write to larger-than-type bitfield (signed
char x:9)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
  Target Milestone: ---

Created attachment 40091
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40091=edit
reproducer

The test is correct C++ program with bitfield larger than its base type, i.e.
signed char : 9.
-O2 produces incorrect result.

The C++14 standard states explicitly the following (9.3.1, [class.bit]):
The value of the integral constant expression may be larger than the number of
bits in the object representation (3.9) of the bit-field’s type; in such cases
the extra bits are used as padding bits and do not participate in the value
representation (3.9) of the bit-field.

> g++ -O0 -w -o no_opt bitfield.cpp main.cpp;./no_opt
0
> g++ -O2 -w -o opt bitfield.cpp main.cpp;./opt
-1

> cat bitfield.h
struct S {
long int  : 23;
long int m0 : 24;
long int m1 : 10;
long int m2 : 24;
signed char m3 : 9;
};

extern struct S s1;

> cat bitfield.cpp
#include "bitfield.h"

void foo() {
  s1.m3 = 0;
  s1.m2 = -1193165L;
}

> cat main.cpp
#include 
#include "bitfield.h"

struct S s1;

void init () {
s1.m0 = 0L;
s1.m1 = 0L;
s1.m2 = 0L;
s1.m3 = 0;
}

void foo();

int main() {
  init();
  foo();
  printf("%d\n",s1.m3);
  return 0;
}

> g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/home/dybaboki/gcc/bin/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --with-arch=corei7 --with-cpu=corei7
--enable-clocale=gnu --with-system-zlib --enable-shared --with-demangler-in-ld
--enable-cloog-backend=isl --with-fpmath=sse --prefix=/home/dybaboki/gcc/bin
--enable-languages=c,c++,fortran,lto : (reconfigured) ../gcc/configure
--with-arch=corei7 --with-cpu=corei7 --enable-clocale=gnu --with-system-zlib
--enable-shared --with-demangler-in-ld --enable-cloog-backend=isl
--with-fpmath=sse --prefix=/home/dybaboki/gcc/bin
--enable-languages=c,c++,fortran,lto : (reconfigured) ../gcc/configure
--with-arch=corei7 --with-cpu=corei7 --enable-clocale=gnu --with-system-zlib
--enable-shared --with-demangler-in-ld --enable-cloog-backend=isl
--with-fpmath=sse --prefix=/home/dybaboki/gcc/bin
--enable-languages=c,c++,fortran,lto : (reconfigured) ../gcc_github/configure
--with-arch=corei7 --with-cpu=corei7 --enable-clocale=gnu --with-system-zlib
--enable-shared --with-demangler-in-ld --enable-cloog-backend=isl
--with-fpmath=sse --prefix=/home/dybaboki/gcc/bin
--enable-languages=c,c++,fortran,lto --no-create --no-recursion :
(reconfigured) ../gcc/configure --with-arch=corei7 --with-cpu=corei7
--enable-clocale=gnu --with-system-zlib --enable-shared --with-demangler-in-ld
--enable-cloog-backend=isl --with-fpmath=sse --prefix=/home/dybaboki/gcc/bin
--enable-languages=c,c++,fortran,lto --no-create --no-recursion
Thread model: posix
gcc version 7.0.0 20161119 (experimental) (GCC)

[Bug tree-optimization/77544] New: [Regression 6/7] segfault at -O0 - infinite loop in simplification

[babokin at gmail dot com]

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

Bug ID: 77544
   Summary: [Regression 6/7] segfault at -O0 - infinite loop in
simplification
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
  Target Milestone: ---

Created attachment 39594
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39594=edit
reproducer

> g++ -O0 -c func.cpp
g++: internal compiler error: Segmentation fault (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

Here's top of the stack when it fails (stack is huge):
#0  0x00a37c59 in operand_equal_p (...) at
./svn/trunk/gcc/fold-const.c:2744
#1  0x00a37e50 in operand_equal_p (...) at
./svn/trunk/gcc/fold-const.c:2750
#2  0x0115c676 in generic_simplify_MINUS_EXPR (...) at
generic-match.c:11785
#3  0x01174bbe in generic_simplify (...) at generic-match.c:31249
#4  0x00a47af3 in fold_binary_loc (...) at
./svn/trunk/gcc/fold-const.c:9161
#5  0x00a52a0b in fold_build2_stat_loc (...) at
./svn/trunk/gcc/fold-const.c:12291
#6  0x01138dc0 in generic_simplify_181 (...) at generic-match.c:6690
#7  0x0114c81b in generic_simplify_PLUS_EXPR (...) at
generic-match.c:11152
#8  0x01174bde in generic_simplify (...) at generic-match.c:31245
#9  0x00a47af3 in fold_binary_loc (...) at
./svn/trunk/gcc/fold-const.c:9161
#10 0x00a52a0b in fold_build2_stat_loc (...) at
./svn/trunk/gcc/fold-const.c:12291
#11 0x00a4a142 in fold_binary_loc (...) at
./svn/trunk/gcc/fold-const.c:9695
#12 0x00a52a0b in fold_build2_stat_loc (...) at
./svn/trunk/gcc/fold-const.c:12291
#13 0x0115c762 in generic_simplify_MINUS_EXPR (...) at
generic-match.c:12390

It's reproducible with gcc6 and trunk. gcc5 works.

GCC build details:
> g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/users/ddd/gcc_20160909/bin/../libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /users/ddd/stability/svn/trunk/configure --with-arch=corei7
--with-cpu=corei7 --enable-clocale=gnu --enable-libmpx=yes --with-system-zlib
--enable-shared --with-demangler-in-ld --enable-cloog-backend=isl
--with-fpmath=sse --with-pkgversion=Revision=240038/svn-rev:240038/
--prefix=/users/ddd/stability/work/trunk/64/install
--enable-languages=c,c++,fortran,java,lto
Thread model: posix
gcc version 7.0.0 20160908 (experimental) (Revision=240038/svn-rev:240038/)

[Bug target/77476] New: [Regression 7] [AVX-512] illegal kmovb instruction on KNL

[babokin at gmail dot com]

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

Bug ID: 77476
   Summary: [Regression 7] [AVX-512] illegal kmovb instruction on
KNL
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
  Target Milestone: ---

Created attachment 39554
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39554=edit
reproducer

> g++ -std=c++11 -O3 -march=knl -o out init.cpp driver.cpp func.cpp check.cpp 
> hash.cpp -w
> sde -knl -- ./out
TID 0 SDE-ERROR: Executed instruction not valid for specified chip (KNL):
0x4022c6: kmovb ecx, k0
Image: ./out+0x22c6 (in multi-region image, region# 0)
Function: _Z3foov
Instruction bytes are: c5 f9 93 c8

> g++ --version
g++ (Revision=239971/svn-rev:239971/) 7.0.0 20160903 (experimental)
Copyright (C) 2016 Free Software Foundation, Inc.

This is a regression, which appeared between August 22 (rev 239643) and August
23 (rev 239673).

[Bug tree-optimization/73714] New: [Regression 7] Incorrect unsigned long long arithmetic optimization

[babokin at gmail dot com]

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

Bug ID: 73714
   Summary: [Regression 7] Incorrect unsigned long long arithmetic
optimization
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
  Target Milestone: ---

Test case:
#include 

int var_s2 = 0;

int main () {
unsigned long long a = 1ULL << (57 - var_s2);
// result is truncated 0x3800ULL, it so should be 0. 
int result = (int) (7679674331924488348ULL * a);

std::cout<<result<<"\n";

return 0;
}

O0 and O2 produce different results, while test case doesn't have undefined
behavior.

> g++ -O0 pr.cpp; ./a.out
0
> g++ -O2 pr.cpp; ./a.out
939524096

> g++ --version
g++ (Revision=239334/svn-rev:239337/) 7.0.0 20160810 (experimental)
Copyright (C) 2016 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 6.1.1 is fine ( (Revision=239178/svn-rev:239179/) 6.1.1 20160805)

[Bug tree-optimization/72835] New: [Regression 7] Incorrect arithmetic optimization involving bitfield arguments

[babokin at gmail dot com]

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

Bug ID: 72835
   Summary: [Regression 7] Incorrect arithmetic optimization
involving bitfield arguments
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
  Target Milestone: ---

Created attachment 39074
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39074=edit
reproducer

-O0 and -O2 produce different results, while the test doesn't contain undefined
behavior.

> g++ -O0 bit_field_math.cpp ; ./a.out
4098873984
> g++ -O2 bit_field_math.cpp ; ./a.out
0
> g++ --version
gcc (Revision=238966/svn-rev:238969/) 7.0.0 20160801 (experimental)

GCC version 6 works correctly.

The test case is attached.

One thing that might look suspicious in the test is negation of unsigned int.
But it's well defined in the standard (same bit pattern as if it's signed, but
the result is treated as unsigned).