[Bug c++/71182] New: parser.c cp_lexer_previous_token sanitizer detects member call on null pointer

[zeccav at gmail dot com]

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

Bug ID: 71182
   Summary: parser.c cp_lexer_previous_token sanitizer detects
member call on null pointer
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

// ../../gcc7/gcc/cp/parser.c:766:7: runtime error: member call on null pointer
of type 'struct vec'
class A {
  template  void As();
};
template  class B : A {
  void f() {
A *g ;
g ? g->As() : nullptr;
  }
};

[Bug tree-optimization/70876] ICE in chkp_find_bounds: Unexpected tree code with_size_expr

[zeccav at gmail dot com]

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

--- Comment #4 from Vittorio Zecca  ---
Will you please check gcc 6.1 with your fix against bug 70877?

I get an ICE, could it be a regression?

gcc -fcheck-pointer-bounds  -mmpx gccerr36.c
gccerr36.c: In function ‘bar’:
gccerr36.c:12:8: warning: function called through a non-compatible type
   d = ((double (*) (int)) foo) (i);
   ~^~~
gccerr36.c: In function ‘bar.chkp’:
gccerr36.c:12:5: internal compiler error: in convert_move, at expr.c:268
   d = ((double (*) (int)) foo) (i);
   ~~^~
0x768d88 convert_move(rtx_def*, rtx_def*, int)
../../gcc-6.1.0/gcc/expr.c:268
0x76e585 store_expr_with_bounds(tree_node*, rtx_def*, int, bool, bool,
tree_node*)
../../gcc-6.1.0/gcc/expr.c:5483
0x76e9ff expand_assignment(tree_node*, tree_node*, bool)
../../gcc-6.1.0/gcc/expr.c:5175
0x691b0c expand_call_stmt
../../gcc-6.1.0/gcc/cfgexpand.c:2658
0x691b0c expand_gimple_stmt_1
../../gcc-6.1.0/gcc/cfgexpand.c:3548
0x691b0c expand_gimple_stmt
../../gcc-6.1.0/gcc/cfgexpand.c:3714
0x6934a5 expand_gimple_basic_block
../../gcc-6.1.0/gcc/cfgexpand.c:5720
0x698386 execute
../../gcc-6.1.0/gcc/cfgexpand.c:6335

[Bug c/71074] New: combine.c in simplify_comparison sanitizer detects left shift of negative value

[zeccav at gmail dot com]

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

Bug ID: 71074
   Summary: combine.c in simplify_comparison sanitizer detects
left shift of negative value
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

/* gcc -O2 sanitizer undefined runtime error */
/* In gcc trunk 7.0 */
/* ../../gcc7/gcc/combine.c:12340:18: runtime error: left shift of negative
value -13 */
/* combine.c:12340 is "const_op <<= INTVAL (XEXP (op0, 1));" */
/* From PR target/49238 */
int bar (void);

void
foo (unsigned long long a, int b)
{
  int i;

for (a = -12; a >= 10; a = bar ())
  break;

if (i == bar () || bar () >= a)
  bar ();
}

[Bug c/71074] combine.c in simplify_comparison sanitizer detects left shift of negative value

[zeccav at gmail dot com]

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

Vittorio Zecca  changed:

   What|Removed |Added

   Severity|normal  |minor

[Bug fortran/67497] data.c sanitizer runtime error: null pointer passed as argument 2, which is declared to never be null

[zeccav at gmail dot com]

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

--- Comment #5 from Vittorio Zecca  ---
Still in trunk:

../../gcc7/gcc/fortran/data.c:191:32: runtime error: null pointer passed as
argument 2, which is declared to never be null

here:

memcpy ([start], rvalue->value.character.string, len * sizeof
(gfc_char_t));

Probably len==0 and preponing an if(len) should do the trick

[Bug c++/71158] New: ICE in tree_to_uhwi with -fsanitize=address

[zeccav at gmail dot com]

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

Bug ID: 71158
   Summary: ICE in tree_to_uhwi with -fsanitize=address
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

Compiling the following with
g++ -fsanitize=address 
int main()
{
int offset=1;
char buf[offset]="";
}

I get the following:

p.C:5:1: internal compiler error: in tree_to_uhwi, at tree.c:7345
 }
 ^
0xff3be2 tree_to_uhwi(tree_node const*)
/home/vitti/gcc7/gcc/tree.c:7345
0xd8005e asan_add_global
/home/vitti/gcc7/gcc/asan.c:2268
0xd80a74 add_string_csts(constant_descriptor_tree**,
asan_add_string_csts_data*)
/home/vitti/gcc7/gcc/asan.c:2478
0xd80fca void hash_table<tree_descriptor_hasher,
xcallocator>::traverse_noresize<asan_add_string_csts_data*,
&(add_string_csts(constant_descriptor_tree**,
asan_add_string_csts_data*))>(asan_add_string_csts_data*)
/home/vitti/gcc7/gcc/hash-table.h:950
0xd80fca void hash_table<tree_descriptor_hasher,
xcallocator>::traverse<asan_add_string_csts_data*,
&(add_string_csts(constant_descriptor_tree**,
asan_add_string_csts_data*))>(asan_add_string_csts_data*)
/home/vitti/gcc7/gcc/hash-table.h:972
0xd80fca asan_finish_file()
/home/vitti/gcc7/gcc/asan.c:2550

[Bug middle-end/70526] [5/6 Regression] GCC 6 miscompiles Firefox JIT compiler

[zeccav at gmail dot com]

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

Vittorio Zecca  changed:

   What|Removed |Added

 CC||zeccav at gmail dot com

--- Comment #29 from Vittorio Zecca  ---
It still fails on gcc 6.1 and 7.
And it inhibits building of firefox with default options.

[Bug sanitizer/71163] New: ICE in get_ubsan_type_info_for_type

[zeccav at gmail dot com]

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

Bug ID: 71163
   Summary: ICE in get_ubsan_type_info_for_type
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav 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: ---

This one seems to be fixed in trunk, I am opening it just in case:

/* gcc -fsanitize=undefined */
/*p.c: In function ‘foo’:
 * p.c:15:6: internal compiler error: in get_ubsan_type_info_for_type, at
ubsan.c:305
 *  void foo(int n)
 *   ^~~
 *0xba9f60 get_ubsan_type_info_for_type
 *../../gcc-7-235689/gcc/ubsan.c:305
 *0xba9f60 ubsan_type_descriptor(tree_node*, ubsan_print_style)
 *../../gcc-7-235689/gcc/ubsan.c:454
 *0xbaa4ec ubsan_expand_bounds_ifn(gimple_stmt_iterator*)
 *../../gcc-7-235689/gcc/ubsan.c:692
 *0xbb01d9 execute
 *../../gcc-7-235689/gcc/sanopt.c:696
 */
void foo(int n)
{
  struct S
  {
int i[n];
  } ;

  struct S s[1];
  int k=0;
  s[k];
}

[Bug middle-end/70526] [5/6 Regression] GCC 6 miscompiles Firefox JIT compiler

[zeccav at gmail dot com]

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

--- Comment #31 from Vittorio Zecca  ---
It seems the following is related to the FF compilation issue:
The program runs differently depending on the optimization level.
With gcc 5.3.0 runs same regardless of the optimization level.
// g++ -Os/-O2/-O3/-Ofast
// 5.3.0 OK
// 6.1 & 7 FAIL
// 70526
#include 
#include 

template
struct AlignedStorage2
{
  union U
  {
char mBytes[sizeof(T)];
uint64_t mDummy;
  } u;

  const T* addr() const { return reinterpret_cast(u.mBytes); }
  T* addr() { return static_cast(static_cast(u.mBytes)); }
};

enum MIRType { MIRType_Object, MIRType_Value, MIRType_None };

struct Register {
uint32_t reg_;
static Register FromCode(uint32_t i) {
Register r = { i };
return r;
}
uint32_t code() const { return reg_; }
};

class TypedOrValueRegister
{
MIRType type_;
AlignedStorage2 typed;
__attribute__((noinline)) Register& dataTyped() { return *typed.addr(); }
  public:
TypedOrValueRegister()
  : type_(MIRType_None) {}
TypedOrValueRegister(MIRType type, Register reg)
  : type_(type)
{
  dataTyped() = reg;
}
Register typedReg() const { return *typed.addr(); }
};

class ConstantOrRegister
{
TypedOrValueRegister reg_;
  public:
ConstantOrRegister(TypedOrValueRegister reg) : reg_(reg) {}
TypedOrValueRegister reg() const { return reg_; }
};

class LAllocation
{
public:
  __attribute__((noinline)) bool isConstant() const { return false; }
};

class LInstruction {
  LAllocation alloc;
public:
  virtual __attribute__((noinline)) LAllocation* getOperand(size_t n)
{ return  }
};

__attribute__((noinline)) Register
ToAnyRegister(const LAllocation* a)
{
  return Register::FromCode(10);
}

__attribute__((noinline)) ConstantOrRegister
ToConstantOrRegister(LInstruction* lir, size_t n, MIRType type) {
if (type == MIRType_Value)
return TypedOrValueRegister();
const LAllocation* value = lir->getOperand(n);
if (value->isConstant())
return TypedOrValueRegister();
return TypedOrValueRegister(type, ToAnyRegister(value));
}

int main() {
LInstruction lir;
ConstantOrRegister cr = ToConstantOrRegister(, 0, MIRType_Object);
if (cr.reg().typedReg().code() != 10)
fprintf(stderr, "Fail\n");
return 0;
}

[Bug libstdc++/70722] include_next in cmath skips user-defined wrapper

[zeccav at gmail dot com]

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

--- Comment #7 from Vittorio Zecca  ---
Yes, this fixed my problem with mozilla firefox compilation,
Thank you!

[Bug fortran/67497] data.c sanitizer runtime error: null pointer passed as argument 2, which is declared to never be null

[zeccav at gmail dot com]

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

--- Comment #4 from Vittorio Zecca  ---
And in 6.1.0 

../../gcc-6.1.0/gcc/fortran/data.c:191:32: runtime error: null pointer passed
as argument 2, which is declared to never be null

[Bug fortran/50410] [4.9/5/6/7 Regression] ICE in record_reference

[zeccav at gmail dot com]

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

--- Comment #22 from Vittorio Zecca  ---
Same ICE in 6.1.0

[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization

[zeccav at gmail dot com]

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

--- Comment #11 from Vittorio Zecca  ---
Same ICE in 6.1.0

[Bug other/69412] bootstrap-ubsan profiledbootstrap issues

[zeccav at gmail dot com]

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

--- Comment #5 from Vittorio Zecca  ---
Bug in comment 4 still in gcc 7

[Bug rtl-optimization/67483] combine.c sanitizer detects undefined negative left shift

[zeccav at gmail dot com]

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

--- Comment #2 from Vittorio Zecca  ---
Yes I confirm it is in trunk:

../../gcc7/gcc/combine.c:7727:40: runtime error: shift exponent -1 is negative

combine.c:7727 is "& unsigned HOST_WIDE_INT) 1 << count)) - 1)) == 0"

count==-1 ?

[Bug middle-end/70877] [MPX] ICE in in convert_move

[zeccav at gmail dot com]

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

--- Comment #2 from Vittorio Zecca  ---
I confirm fixed in 6.1.0 and trunk.
Thank you!

[Bug debug/67482] dwarf2out.c sanitizer detects undefined behaviour negation of -9223372036854775808

[zeccav at gmail dot com]

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

--- Comment #3 from Vittorio Zecca  ---
I confirm I cannot reproduce it on 6.1.0 nor 7

[Bug debug/67482] dwarf2out.c sanitizer detects undefined behaviour negation of -9223372036854775808

[zeccav at gmail dot com]

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

--- Comment #5 from Vittorio Zecca  ---
Running the sanitized version of gcc against the testsuite I got no
runtime error in dwarf2out.c

So I believe this issue can be closed as FIXED.

[Bug fortran/71027] New: -fsanitize=address catches out of bounds access on assumed size array only with -O0

[zeccav at gmail dot com]

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

Bug ID: 71027
   Summary: -fsanitize=address catches out of bounds access on
assumed size array only with -O0
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

! -fsanitize=address -O0 catches out of bounds access on assumed size array
! any other optimization level, even -Og, inhibits catching
  dimension v(10)
  call sub(v)
  contains
  subroutine sub(vv)
  dimension vv(*)
  x=vv(20) ! out of bounds access
  end subroutine
  end

[Bug fortran/71027] -fsanitize=address catches out of bounds access on assumed size array only with -O0

[zeccav at gmail dot com]

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

--- Comment #2 from Vittorio Zecca  ---
Yes, you are right, and probably in real programs the subroutine would
not be optimized away.
Thank you for the explanation.

[Bug fortran/50410] [5/6/7 Regression] ICE in record_reference

[zeccav at gmail dot com]

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

Vittorio Zecca  changed:

   What|Removed |Added

Version|4.8.0   |7.0

--- Comment #26 from Vittorio Zecca  ---
Still there in gcc 7.0 trunk 239276

[Bug fortran/61907] load of invalid value for 'bool' in trans-array.c trans_array_constructor

[zeccav at gmail dot com]

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

Vittorio Zecca  changed:

   What|Removed |Added

Version|4.9.1   |7.0

--- Comment #6 from Vittorio Zecca  ---
Still there in gcc 7.0 trunk 239276

[Bug fortran/61910] undefined computation in trans-expr.c gfc_conv_cst_int_power

[zeccav at gmail dot com]

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

--- Comment #7 from Vittorio Zecca  ---
Still there in gcc 7.0 trunk 239276

[Bug fortran/61908] load of invalid value for 'expr_t' in interface.c compare_actual_formal

[zeccav at gmail dot com]

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

Vittorio Zecca  changed:

   What|Removed |Added

Version|4.9.1   |7.0

--- Comment #6 from Vittorio Zecca  ---
Still there in gcc 7.0 trunk 239276

[Bug c/74265] address sanitizer detects stack-buffer-overflow in set_nonincremental_init_from_string in c-typeck.c

[zeccav at gmail dot com]

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

--- Comment #1 from Vittorio Zecca  ---
The following is a shorter reproducer:

struct B {
  __CHAR32_TYPE__ S[6];
} d[] = { { { U"foo" } }, [0].S[2] = U'x' };

[Bug java/74750] New: Address sanitizer detects stack-buffer-underflow in GC_push_all_eager in mark.c

[zeccav at gmail dot com]

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

Bug ID: 74750
   Summary: Address sanitizer detects stack-buffer-underflow in
GC_push_all_eager in mark.c
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: java
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

While generating 7.0 trunk with sanitized java I get the following
in mark.c:1468

"q = *p;"

libtool: link: /home/vitti/1tb/vitti/gcc-7-address/./gcc/gcj
-B/home/vitti/1tb/vitti/gcc-7-address/x86_64-pc-linux-gnu/libjava/
-B/home/vitti/1tb/vitti/gcc-7-address/./gcc/
-B/home/vitti/1tb/vitti/local/gcc-7-address/x86_64-pc-linux-gnu/bin/
-B/home/vitti/1tb/vitti/local/gcc-7-address/x86_64-pc-linux-gnu/lib/ -isystem
/home/vitti/1tb/vitti/local/gcc-7-address/x86_64-pc-linux-gnu/include -isystem
/home/vitti/1tb/vitti/local/gcc-7-address/x86_64-pc-linux-gnu/sys-include
-fomit-frame-pointer -Usun -g -O2 -o .libs/gcj-dbtool
--main=gnu.gcj.tools.gcj_dbtool.Main -shared-libgcc
gnu/gcj/tools/gcj_dbtool/natMain.o gnu/gcj/tools/.libs/gcj_dbtool.o 
-L/home/vitti/1tb/vitti/gcc-7-address/x86_64-pc-linux-gnu/libjava/.libs
-L/home/vitti/1tb/vitti/gcc-7-address/x86_64-pc-linux-gnu/libjava
./.libs/libgcj.so /home/vitti/1tb/vitti/local/gcc-7/lib/../lib64/libasan.so
-ldl -lrt -lpthread /home/vitti/1tb/vitti/local/gcc-7/lib/../lib64/libstdc++.so
-lm -Wl,-rpath -Wl,/home/vitti/1tb/vitti/local/gcc-7-address/lib/../lib64
-Wl,-rpath -Wl,/home/vitti/1tb/vitti/local/gcc-7/lib/../lib64
./gcj-dbtool -n classmap.db || touch classmap.db
=
==16985==ERROR: AddressSanitizer: stack-buffer-underflow on address
0x7ffd646e1ff0 at pc 0x2b760583a7c1 bp 0x7ffd646e1f90 sp 0x7ffd646e1f88
READ of size 8 at 0x7ffd646e1ff0 thread T0
#0 0x2b760583a7c0 in GC_push_all_eager
/home/vitti/1tb/vitti/test/gcc-trunk-239276/boehm-gc/mark.c:1468
#1 0x2b760583c607 in GC_push_current_stack
/home/vitti/1tb/vitti/test/gcc-trunk-239276/boehm-gc/mark_rts.c:497
#2 0x2b7605849561 in GC_with_callee_saves_pushed
/home/vitti/1tb/vitti/test/gcc-trunk-239276/boehm-gc/mach_dep.c:476
#3 0x2b76058495f0 in GC_generic_push_regs
/home/vitti/1tb/vitti/test/gcc-trunk-239276/boehm-gc/mach_dep.c:487
#4 0x2b760583c7c8 in GC_push_roots
/home/vitti/1tb/vitti/test/gcc-trunk-239276/boehm-gc/mark_rts.c:637
#5 0x2b760583b3cc in GC_mark_some
/home/vitti/1tb/vitti/test/gcc-trunk-239276/boehm-gc/mark.c:326
#6 0x2b760582c330 in GC_stopped_mark
/home/vitti/1tb/vitti/test/gcc-trunk-239276/boehm-gc/alloc.c:531
#7 0x2b760582d1cf in GC_try_to_collect_inner
/home/vitti/1tb/vitti/test/gcc-trunk-239276/boehm-gc/alloc.c:378
#8 0x2b760583ddf2 in GC_init_inner
/home/vitti/1tb/vitti/test/gcc-trunk-239276/boehm-gc/misc.c:789
#9 0x2b760583df2e in GC_init
/home/vitti/1tb/vitti/test/gcc-trunk-239276/boehm-gc/misc.c:493
#10 0x2b7605833e60 in GC_init_gcj_malloc
/home/vitti/1tb/vitti/test/gcc-trunk-239276/boehm-gc/gcj_mlc.c:60
#11 0x2b7605048a6f in _Jv_InitGC()
/home/vitti/1tb/vitti/test/gcc-trunk-239276/libjava/boehm.cc:537
#12 0x2b7604f7f242 in _Jv_CreateJavaVM
/home/vitti/1tb/vitti/test/gcc-trunk-239276/libjava/prims.cc:1631
#13 0x2b7604f7f692 in _Jv_RunMain(_Jv_VMInitArgs*, java::lang::Class*, char
const*, int, char const**, bool)
/home/vitti/1tb/vitti/test/gcc-trunk-239276/libjava/prims.cc:1720
#14 0x2b7604f7fc55 in _Jv_RunMain(java::lang::Class*, char const*, int,
char const**, bool)
/home/vitti/1tb/vitti/test/gcc-trunk-239276/libjava/prims.cc:1815
#15 0x2b7604f7fc70 in JvRunMain
/home/vitti/1tb/vitti/test/gcc-trunk-239276/libjava/prims.cc:1821
#16 0x40302f in main /tmp/cccH4paM.i:12
#17 0x390da1ffdf in __libc_start_main (/lib64/libc.so.6+0x390da1ffdf)
#18 0x403077 
(/home/vitti/1tb/vitti/gcc-7-address/x86_64-pc-linux-gnu/libjava/.libs/lt-gcj-dbtool+0x403077)

Address 0x7ffd646e1ff0 is located in stack of thread T0 at offset 0 in frame
#0 0x2b76058494ed in GC_with_callee_saves_pushed
/home/vitti/1tb/vitti/test/gcc-trunk-239276/boehm-gc/mach_dep.c:410

  This frame has 1 object(s):
[32, 40) 'dummy'
HINT: this may be a false positive if your program uses some custom stack
unwind mechanism or swapcontext
  (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-underflow
/home/vitti/1tb/vitti/test/gcc-trunk-239276/boehm-gc/mark.c:1468 in
GC_push_all_eager
Shadow bytes around the buggy address:
  0x10002c8d43a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10002c8d43b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10002c8d43c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10002c8d43d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10002c8d43e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x10002c8d43f0: 00 00 00 00 00 00 00 00 0

[Bug middle-end/67485] expmed.c sanitizer detects overflow

[zeccav at gmail dot com]

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

Vittorio Zecca  changed:

   What|Removed |Added

Version|5.2.0   |7.0

--- Comment #3 from Vittorio Zecca  ---
Still in trunk:

~/1tb/vitti/local/gcc-7-undefined/bin/gcc -S gccerr28.c
/home/vitti/1tb/vitti/test/gcc-trunk-239276/gcc/expmed.c:3115:15: runtime
error: signed integer overflow: -9223372036854775808 - 1 cannot be represented
in type 'long int [3]'

expmed.c:3115 is ""val_so_far -= HOST_WIDE_INT_1 << log;

[Bug c++/75860] Segmentation violation in tree_check while compiling firefox 48

[zeccav at gmail dot com]

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

--- Comment #2 from Vittorio Zecca  ---
The preprocessed source is too big to be meaningful.
I did try to shorten it but still too big and using so many firefox
header files.
It will be faster if you could download the firefox-48 source and try it.
Using the following

CFLAGS="-g -w -O0 -fsanitize=address -fno-omit-frame-pointer"
CXXFLAGS=$CFLAGS ../firefox-48.0/configure
--prefix=/home/vitti/1tb/vitti/local/firefox-48.0-address

[Bug c++/75860] Segmentation violation in tree_check while compiling firefox 48

[zeccav at gmail dot com]

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

--- Comment #4 from Vittorio Zecca  ---
Created attachment 39369
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39369=edit
xz-ipped reproducer

This is the xzipped test case that is my reproducer for this issue.
There are many compilation errors due to shortening it,
but I still get the ICE segmentation fault message.
I hope it helps.

[Bug c++/75860] New: Segmentation violation in tree_check while compiling firefox 48

[zeccav at gmail dot com]

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

Bug ID: 75860
   Summary: Segmentation violation in tree_check while compiling
firefox 48
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

While compiling firefox version 48 with the trunk gcc 7.0 I get the following
segmentation violation

tree.h:3022 is "if (TREE_CODE (__t) != __c)"

Maybe __t is NULL?

I put MAJOR severity because this happens compiling a real software,
not a custom built fragment.

/home/vitti/1tb/vitti/local/gcc-7-239276/bin/g++ -std=gnu++11 -o
Unified_cpp_gfx_thebes0.o -c
-I/home/vitti/1tb/vitti/rpmbuild/SOURCES/firefox-48.0-obj/dist/stl_wrappers
-I/home/vitti/1tb/vitti/rpmbuild/SOURCES/firefox-48.0-obj/dist/system_wrappers
-include
/home/vitti/1tb/vitti/rpmbuild/SOURCES/firefox-48.0/config/gcc_hidden.h
-DNDEBUG=1 -DTRIMMED=1 -DOS_POSIX=1 -DOS_LINUX=1 -DMOZ_ENABLE_FREETYPE
-DGRAPHITE2_STATIC -DSTATIC_EXPORTABLE_JS_API -DMOZILLA_INTERNAL_API
-DIMPL_LIBXUL -I/home/vitti/1tb/vitti/rpmbuild/SOURCES/firefox-48.0/gfx/thebes
-I/home/vitti/1tb/vitti/rpmbuild/SOURCES/firefox-48.0-obj/gfx/thebes
-I/home/vitti/1tb/vitti/rpmbuild/SOURCES/firefox-48.0/intl/icu/source/common
-I/home/vitti/1tb/vitti/rpmbuild/SOURCES/firefox-48.0/intl/icu/source/i18n
-I/home/vitti/1tb/vitti/rpmbuild/SOURCES/firefox-48.0-obj/ipc/ipdl/_ipdlheaders
-I/home/vitti/1tb/vitti/rpmbuild/SOURCES/firefox-48.0/ipc/chromium/src
-I/home/vitti/1tb/vitti/rpmbuild/SOURCES/firefox-48.0/ipc/glue
-I/home/vitti/1tb/vitti/rpmbuild/SOURCES/firefox-48.0/dom/workers
-I/home/vitti/1tb/vitti/rpmbuild/SOURCES/firefox-48.0/dom/xml
-I/home/vitti/1tb/vitti/rpmbuild/SOURCES/firefox-48.0/gfx/skia
-I/home/vitti/1tb/vitti/rpmbuild/SOURCES/firefox-48.0/gfx/skia/skia/include/config
-I/home/vitti/1tb/vitti/rpmbuild/SOURCES/firefox-48.0/gfx/skia/skia/include/core
-I/home/vitti/1tb/vitti/rpmbuild/SOURCES/firefox-48.0/gfx/skia/skia/include/gpu
-I/home/vitti/1tb/vitti/rpmbuild/SOURCES/firefox-48.0/gfx/skia/skia/include/utils
-I/home/vitti/1tb/vitti/rpmbuild/SOURCES/firefox-48.0-obj/dist/include 
-I/home/vitti/1tb/vitti/rpmbuild/SOURCES/firefox-48.0-obj/dist/include/nspr
-I/home/vitti/1tb/vitti/rpmbuild/SOURCES/firefox-48.0-obj/dist/include/nss 
 -fPIC  -DMOZILLA_CLIENT -include
/home/vitti/1tb/vitti/rpmbuild/SOURCES/firefox-48.0-obj/mozilla-config.h -MD
-MP -MF .deps/Unified_cpp_gfx_thebes0.o.pp  -Wall -Wc++11-compat -Wempty-body
-Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith -Wsign-compare
-Wtype-limits -Wunreachable-code -Wwrite-strings -Wc++14-compat
-Wno-invalid-offsetof -Wno-error=maybe-uninitialized
-Wno-error=deprecated-declarations -Wno-error=array-bounds -g -w -O0
-fno-omit-frame-pointer -fno-exceptions -fno-strict-aliasing -fno-rtti
-fno-exceptions -fno-math-errno -pthread -pipe  -g -freorder-blocks -Os
-fomit-frame-pointer  -Wshadow
-I/home/vitti/1tb/vitti/rpmbuild/SOURCES/firefox-48.0-obj/dist/include/cairo
-I/home/vitti/1tb/vitti/rpmbuild/SOURCES/firefox-48.0/widget/gtk/compat-gtk3
-pthread -I/usr/include/gtk-3.0/unix-print -I/usr/include/gtk-3.0
-I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0
-I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include -I/usr/include/gtk-3.0
-I/usr/include/gio-unix-2.0/ -I/usr/include/cairo -I/usr/include/pango-1.0
-I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/atk-1.0
-I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2
-I/usr/include/libpng16 -I/usr/include/freetype2 -I/usr/include/libdrm
-I/usr/include/libpng16 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -pthread
-I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0
-I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
-I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng16
-I/usr/include/freetype2 -I/usr/include/libdrm -I/usr/include/libpng16  
/home/vitti/1tb/vitti/rpmbuild/SOURCES/firefox-48.0-obj/gfx/thebes/Unified_cpp_gfx_thebes0.cpp
In file included from
/home/vitti/1tb/vitti/rpmbuild/SOURCES/firefox-48.0/gfx/thebes/gfxBaseSharedMemorySurface.cpp:7:0,
 from
/home/vitti/1tb/vitti/rpmbuild/SOURCES/firefox-48.0-obj/gfx/thebes/Unified_cpp_gfx_thebes0.cpp:38:
/home/vitti/1tb/vitti/rpmbuild/SOURCES/firefox-48.0/gfx/thebes/gfxBaseSharedMemorySurface.h:
In static member function ‘static bool gfxBaseSharedMemorySurface<Base,
Sub>::IsSharedImage(gfxASurface*)’:
/home/vitti/1tb/vitti/rpmbuild/SOURCES/firefox-48.0/gfx/thebes/gfxBaseSharedMemorySurface.h:108:39:
internal compiler error: Segmentation fault
 && aSurface->GetData(_KEY));
   ^~~
0xd2a04f crash_signal
../../

[Bug c++/75860] Segmentation violation in tree_check while compiling firefox 48

[zeccav at gmail dot com]

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

--- Comment #6 from Vittorio Zecca  ---
Created attachment 39410
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39410=edit
xz-ipped original firefox source file

Original firefox source file in xz format.
This one is error free except for the ICE segmentation fault from g++.

[Bug c++/75860] Segmentation violation in tree_check while compiling firefox 48

[zeccav at gmail dot com]

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

--- Comment #8 from Vittorio Zecca  ---
Compiling the big test case, 231025 lines, with trunk level 239276 of August
9th

g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/home/vitti/1tb/vitti/local/gcc-7-239276/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ./configure --prefix=/home/vitti/1tb/vitti/local/gcc-7-239276
Thread model: posix
gcc version 7.0.0 20160809 (experimental) (GCC) 
[vitti ~]$g++ -S pbase.C
In file included from
/home/vitti/1tb/vitti/rpmbuild/SOURCES/firefox-48.0-obj/dist/include/nsCycleCollectionTraversalCallback.h:10:0,
 from
/home/vitti/1tb/vitti/rpmbuild/SOURCES/firefox-48.0-obj/dist/include/nsCycleCollectionNoteChild.h:13,
 from
/home/vitti/1tb/vitti/rpmbuild/SOURCES/firefox-48.0-obj/dist/include/nsCOMPtr.h:33,
 from
/home/vitti/1tb/vitti/rpmbuild/SOURCES/firefox-48.0-obj/dist/include/nsAutoPtr.h:10,
 from
/home/vitti/1tb/vitti/rpmbuild/SOURCES/firefox-48.0/ipc/chromium/src/base/revocable_store.h:10,
 from
/home/vitti/1tb/vitti/rpmbuild/SOURCES/firefox-48.0/ipc/chromium/src/base/task.h:9,
 from
/home/vitti/1tb/vitti/rpmbuild/SOURCES/firefox-48.0/ipc/chromium/src/base/message_loop.h:17,
 from
/home/vitti/1tb/vitti/rpmbuild/SOURCES/firefox-48.0/ipc/chromium/src/base/thread.h:11,
 from
/home/vitti/1tb/vitti/rpmbuild/SOURCES/firefox-48.0/gfx/thebes/SoftwareVsyncSource.h:13,
 from
/home/vitti/1tb/vitti/rpmbuild/SOURCES/firefox-48.0/gfx/thebes/SoftwareVsyncSource.cpp:7,
 from
/home/vitti/1tb/vitti/rpmbuild/SOURCES/firefox-48.0-obj/gfx/thebes/Unified_cpp_gfx_thebes0.cpp:11:
/home/vitti/1tb/vitti/rpmbuild/SOURCES/firefox-48.0-obj/dist/include/jspubtd.h:411:50:
warning: offsetof within non-standard-layout type
‘js::PerThreadDataFriendFields::RuntimeDummy’ is undefined [-Winvalid-offsetof]
 static const size_t RuntimeMainThreadOffset = offsetof(RuntimeDummy,
mainThread);

In file included from
/home/vitti/1tb/vitti/rpmbuild/SOURCES/firefox-48.0/gfx/thebes/gfxBaseSharedMemorySurface.cpp:7:0,
 from
/home/vitti/1tb/vitti/rpmbuild/SOURCES/firefox-48.0-obj/gfx/thebes/Unified_cpp_gfx_thebes0.cpp:38:
/home/vitti/1tb/vitti/rpmbuild/SOURCES/firefox-48.0/gfx/thebes/gfxBaseSharedMemorySurface.h:
In static member function ‘static bool gfxBaseSharedMemorySurface::IsSharedImage(gfxASurface*)’:
/home/vitti/1tb/vitti/rpmbuild/SOURCES/firefox-48.0/gfx/thebes/gfxBaseSharedMemorySurface.h:108:39:
internal compiler error: Segmentation fault
 && aSurface->GetData(_KEY));
   ^~~
0xd2a04f crash_signal
../.././gcc/toplev.c:335
0x6c42a8 tree_check(tree_node*, char const*, int, char const*, tree_code)
../.././gcc/tree.h:3022
0x6c42a8 is_really_empty_class(tree_node*)
../.././gcc/cp/class.c:8426
0x82a2b3 cxx_eval_constant_expression
../.././gcc/cp/constexpr.c:3702
0x83107b cxx_eval_outermost_constant_expr
../.././gcc/cp/constexpr.c:4382
0x834248 fold_non_dependent_expr(tree_node*)
../.././gcc/cp/constexpr.c:4662
0x64bd5c build_non_dependent_expr(tree_node*)
../.././gcc/cp/pt.c:23802
0x74feb7 build_x_unary_op(unsigned int, tree_code, cp_expr, int)
../.././gcc/cp/typeck.c:5353
0x710b39 cp_parser_unary_expression
../.././gcc/cp/parser.c:7966
0x71abf3 cp_parser_cast_expression
../.././gcc/cp/parser.c:8693
0x71b1f7 cp_parser_binary_expression
../.././gcc/cp/parser.c:8794
0x71bac4 cp_parser_assignment_expression
../.././gcc/cp/parser.c:9081
0x71d5c6 cp_parser_parenthesized_expression_list
../.././gcc/cp/parser.c:7487
0x71231b cp_parser_postfix_expression
../.././gcc/cp/parser.c:6792
0x710a90 cp_parser_unary_expression
../.././gcc/cp/parser.c:8016
0x71abf3 cp_parser_cast_expression
../.././gcc/cp/parser.c:8693
0x71b5ff cp_parser_simple_cast_expression
../.././gcc/cp/parser.c:26014
0x71b5ff cp_parser_binary_expression
../.././gcc/cp/parser.c:8858
0x71bac4 cp_parser_assignment_expression
../.././gcc/cp/parser.c:9081
0x71e3ea cp_parser_expression
../.././gcc/cp/parser.c:9250
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/75860] Segmentation violation in tree_check while compiling firefox 48

[zeccav at gmail dot com]

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

--- Comment #11 from Vittorio Zecca  ---
I applied the fix from bug 72849 and the ICE disappeared.
Many thanks for pointing me to the right place!

[Bug libgcc/77273] New: 1 << 31 is undefined in gcc/config/i386/cpuid.h:93

[zeccav at gmail dot com]

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

Bug ID: 77273
   Summary: 1 << 31 is undefined in gcc/config/i386/cpuid.h:93
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

While compiling gcc itself, the sanitizer complains as follows:

gcc-trunk-239276/libgcc/config/i386/cpuinfo.c:346:17: runtime error: left shift
of 1 by 31 places cannot be represented in type 'int'

cpuinfo.c:346 is "if (ebx & bit_AVX512VL)"

bit_AVX512VL is defined in cpuid.h:249 as

#define bit_AVX512VL(1 << 31)

I believe 1 << 31 is undefined, because "1" is int,
it should be 1u << 31 or 1U << 31

cpuid.h:66 is "#define bit_3DNOW   (1 << 31)" by the way

[Bug debug/67482] dwarf2out.c sanitizer detects undefined behaviour negation of -9223372036854775808

[zeccav at gmail dot com]

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

Vittorio Zecca  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

[Bug fortran/67496] trans-array.c sanitizer runtime error: load of value 124, which is not a valid value for type 'bool'

[zeccav at gmail dot com]

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

Vittorio Zecca  changed:

   What|Removed |Added

Version|5.2.0   |7.0
   Severity|normal  |minor

[Bug fortran/67496] trans-array.c sanitizer runtime error: load of value 124, which is not a valid value for type 'bool'

[zeccav at gmail dot com]

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

--- Comment #11 from Vittorio Zecca  ---
Still in trunk 7.0

gcc-trunk-239276/gcc/fortran/trans-array.c:2243:27: runtime error: load of
value 48, which is not a valid value for type 'bool'

[Bug fortran/67497] data.c sanitizer runtime error: null pointer passed as argument 2, which is declared to never be null

[zeccav at gmail dot com]

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

--- Comment #7 from Vittorio Zecca  ---
Traveling now, back home end of March.
Did you check the value of variable "len" maybe it's zero so it's not
really a bug.

[Bug fortran/77327] AddressSanitizer: heap-use-after-free gcc-trunk-239276/gcc/fortran/interface.c:403 in compare_components

[zeccav at gmail dot com]

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

--- Comment #5 from Vittorio Zecca  ---
The test case you propose, dec_structure_13.f90, does not trigger the asan
memory checker.

As I wrote before, the test case gfortran.dg/import4.f90 does trigger
the asan memory checker.

In your test case I do not understand the final statement "call
sub2(u2)" because
sub2 is not defined.

[Bug fortran/77327] AddressSanitizer: heap-use-after-free gcc-trunk-239276/gcc/fortran/interface.c:403 in compare_components

[zeccav at gmail dot com]

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

--- Comment #6 from Vittorio Zecca  ---
After applying the proposed patch the asan memory checker did not report
any memory fault, in particular the heap-use-after-free in interface.c

Fritz, do you have a -fsanitize=address version of gfortran, in
particular of f951?

[Bug fortran/77327] AddressSanitizer: heap-use-after-free gcc-trunk-239276/gcc/fortran/interface.c:403 in compare_components

[zeccav at gmail dot com]

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

--- Comment #4 from Vittorio Zecca  ---
The reproducer I proposed comes from testcase gfortran.dg/import4.f90

[Bug fortran/69604] ICE in gfc_add_modify_loc, at fortran/trans.c:159

[zeccav at gmail dot com]

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

Vittorio Zecca  changed:

   What|Removed |Added

 CC||zeccav at gmail dot com

--- Comment #10 from Vittorio Zecca  ---
(In reply to Gerhard Steinmetz from comment #1)
> While playing around, one example from ./gcc/testsuite/gfortran.dg/
> shows the same error with v6.0.0, but not with v5.3.1 :
> 
> 
> $ gfortran-6 -c complex_intrinsic_6.f90
> internal compiler error: in gfc_add_modify_loc, at fortran/trans.c:159
> 
> 
> $ gfortran-5 -c complex_intrinsic_6.f90
> # no ICE
> 
> 
> ---
> 
> Please correct : last line was cut away for example z4.f90 -- add "end"

Here it still fails with gcc trunk version 7.

[Bug c/77486] New: ubsan detects runtime error: left shift of negative value -3 at real_hash in real.c:2890

[zeccav at gmail dot com]

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

Bug ID: 77486
   Summary: ubsan detects runtime error: left shift of negative
value -3 at real_hash in real.c:2890
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

Compiling the following with ubsan sanitized gcc

f(void)
{
 float y=0;
 if(y<0.1) y=1.0;
}

I get

../../gcc-trunk-239945/gcc/real.c:2890:25: runtime error: left shift of
negative value -3

real.c:2890 is " h |= REAL_EXP (r) << 3;"

[Bug sanitizer/65828] [LTO] ICE in streamer_get_builtin_tree, at tree-streamer-in.c:1127

[zeccav at gmail dot com]

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

--- Comment #11 from Vittorio Zecca  ---
Sorry I am traveling now I cannot help you.

[Bug fortran/77327] New: AddressSanitizer: heap-use-after-free gcc-trunk-239276/gcc/fortran/interface.c:403 in compare_components

[zeccav at gmail dot com]

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

Bug ID: 77327
   Summary: AddressSanitizer: heap-use-after-free
gcc-trunk-239276/gcc/fortran/interface.c:403 in
compare_components
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

Compiling the following:

  subroutine foo(a)
  type myT
   sequence
   character :: c
  end type myT
  type(myT) :: a
  end subroutine

  module modtest
  type myT
   sequence
   character :: c
  end type myT
  interface
   subroutine foo(c)
import :: myT
type(myT) :: c
   end subroutine foo
  end interface
  contains
   subroutine test2()
type(myT) :: z
call foo(z)
   end subroutine test2
  end module modtest

with an address sanitized version of gfortran I get the following:

$gcc-7-address/bin/gfortran ~/f95/gfbug126.f
=
==15602==ERROR: AddressSanitizer: heap-use-after-free on address 0x6040c462
at pc 0x0067217d bp 0x7ffd1903f720 sp 0x7ffd1903f718
READ of size 1 at 0x6040c462 thread T0
#0 0x67217c in compare_components
/home/vitti/1tb/vitti/test/gcc-trunk-239276/gcc/fortran/interface.c:403
#1 0x672839 in gfc_compare_derived_types(gfc_symbol*, gfc_symbol*)
/home/vitti/1tb/vitti/test/gcc-trunk-239276/gcc/fortran/interface.c:570
#2 0x798343 in gfc_type_compatible(gfc_typespec*, gfc_typespec*)
/home/vitti/1tb/vitti/test/gcc-trunk-239276/gcc/fortran/symbol.c:4869
#3 0x671da3 in gfc_compare_types(gfc_typespec*, gfc_typespec*)
/home/vitti/1tb/vitti/test/gcc-trunk-239276/gcc/fortran/interface.c:630
#4 0x672b3f in compare_type
/home/vitti/1tb/vitti/test/gcc-trunk-239276/gcc/fortran/interface.c:646
#5 0x675600 in gfc_check_dummy_characteristics(gfc_symbol*, gfc_symbol*,
bool, char*, int)
/home/vitti/1tb/vitti/test/gcc-trunk-239276/gcc/fortran/interface.c:1187
#6 0x674ebd in gfc_compare_interfaces(gfc_symbol*, gfc_symbol*, char
const*, int, int, char*, int, char const*, char const*)
/home/vitti/1tb/vitti/test/gcc-trunk-239276/gcc/fortran/interface.c:1644
#7 0x73cb61 in resolve_global_procedure
/home/vitti/1tb/vitti/test/gcc-trunk-239276/gcc/fortran/resolve.c:2463
#8 0x74d055 in resolve_call
/home/vitti/1tb/vitti/test/gcc-trunk-239276/gcc/fortran/resolve.c:3455
#9 0x764d17 in gfc_resolve_code(gfc_code*, gfc_namespace*)
/home/vitti/1tb/vitti/test/gcc-trunk-239276/gcc/fortran/resolve.c:10659
#10 0x767b59 in resolve_codes
/home/vitti/1tb/vitti/test/gcc-trunk-239276/gcc/fortran/resolve.c:15667
#11 0x7679dd in resolve_codes
/home/vitti/1tb/vitti/test/gcc-trunk-239276/gcc/fortran/resolve.c:15652
#12 0x73c2b1 in gfc_resolve(gfc_namespace*)
/home/vitti/1tb/vitti/test/gcc-trunk-239276/gcc/fortran/resolve.c:15701
#13 0x711dd7 in gfc_parse_file()
/home/vitti/1tb/vitti/test/gcc-trunk-239276/gcc/fortran/parse.c:6061
#14 0x7b4d6d in gfc_be_parse_file
/home/vitti/1tb/vitti/test/gcc-trunk-239276/gcc/fortran/f95-lang.c:198
#15 0x165aada in compile_file
/home/vitti/1tb/vitti/test/gcc-trunk-239276/gcc/toplev.c:465
#16 0x165ff74 in do_compile
/home/vitti/1tb/vitti/test/gcc-trunk-239276/gcc/toplev.c:1998
#17 0x16604aa in toplev::main(int, char**)
/home/vitti/1tb/vitti/test/gcc-trunk-239276/gcc/toplev.c:2132
#18 0x2e2a5ca in main
/home/vitti/1tb/vitti/test/gcc-trunk-239276/gcc/main.c:39
#19 0x390da1ffdf in __libc_start_main (/lib64/libc.so.6+0x390da1ffdf)
#20 0x5eafd8 
(/home/vitti/1tb/vitti/local/gcc-7-address/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/f951+0x5eafd8)

0x6040c462 is located 18 bytes inside of 40-byte region
[0x6040c450,0x6040c478)
freed by thread T0 here:
#0 0x2b862c1d8330 in __interceptor_free
../../.././libsanitizer/asan/asan_malloc_linux.cc:45
#1 0x2e61f00 in release<(anonymous namespace)::line_span>
/home/vitti/1tb/vitti/test/gcc-trunk-239276/gcc/vec.h:307
#2 0x2e66774 in release
/home/vitti/1tb/vitti/test/gcc-trunk-239276/gcc/vec.h:1492
#3 0x2e66774 in ~auto_vec
/home/vitti/1tb/vitti/test/gcc-trunk-239276/gcc/vec.h:1286
#4 0x2e66774 in calculate_line_spans
/home/vitti/1tb/vitti/test/gcc-trunk-239276/gcc/diagnostic-show-locus.c:894
#5 0x2e67b02 in layout
/home/vitti/1tb/vitti/test/gcc-trunk-239276/gcc/diagnostic-show-locus.c:785
#6 0x2e6802e in diagnostic_show_locus(diagnostic_context*, diagnostic_info
const*)
/home/vitti/1tb/vitti/test/gcc-trunk-239276/gcc/diagnostic-show-locus.c:1302
#7 0x6572e4 in gfc_diagnostic_starter
/home/vitti/1tb/vitti/test/gcc-trunk-239276/gcc/fortran/error.c:1096
#8 0x2e5c244 in diagnostic_report_diagnostic(diagnostic_context*,
diagnostic_info*)
/home/vitti/1tb

[Bug c++/67737] [C++1z] ICE in make_decl_rtl, at varasm.c:1299

[zeccav at gmail dot com]

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

--- Comment #9 from Vittorio Zecca  ---
(In reply to Andrew Pinski from comment #8)
> (In reply to Vittorio Zecca from comment #7)
> > With gcc 6.1.0, maybe a shorter reproducer
> > /* gcc -fcheck-pointer-bounds -mmpx p.c */
> 
> That is a different issue and should be filed separately if not already.

Bug 77383 submitted.
Thank you for the suggestion.

[Bug fortran/77327] AddressSanitizer: heap-use-after-free gcc-trunk-239276/gcc/fortran/interface.c:403 in compare_components

[zeccav at gmail dot com]

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

--- Comment #8 from Vittorio Zecca  ---
Yes, it seems to me that import4.f90 is sufficient to trigger the asan
memory checker.

How strange, even without "implicit none" the loader should have complained
that "sub2" was referenced but undefined. This is how I find the bug.

It is not that trivial to build a sanitized version of
gcc/g++/gfortran but nonetheless
it is possible.

Once you have a sanitized gfortran and f951 then you can check it
against the gcc testsuite
Fortran files, as I did.

[Bug c/77383] New: -fcheck-pointer-bounds -mmpx ICE in make_decl_rtl at varasm.c

[zeccav at gmail dot com]

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

Bug ID: 77383
   Summary: -fcheck-pointer-bounds -mmpx ICE in make_decl_rtl at
varasm.c
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

/* gcc -fcheck-pointer-bounds -mmpx */
int main ()
{
  int size = 10;
  typedef struct
{
  char val[size];
} block;
  block b;
  block retframe_block () {}
  retframe_block ();
}
/* gccerr37.c: In function ‘main.chkp’:
 * gccerr37.c:12:3: internal compiler error: in make_decl_rtl, at varasm.c:1310
 *retframe_block ();
 *   ^~
 * 0xe3219d make_decl_rtl(tree_node*)
 *  /home/vitti/1tb/vitti/gcc-7/gcc/varasm.c:1306
 * 0x82cf32 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
 *  /home/vitti/1tb/vitti/gcc-7/gcc/expr.c:9755
 *0xe9d807 expand_normal
 *  /home/vitti/1tb/vitti/gcc-7/gcc/expr.h:285
 * 0xe9d807 ix86_expand_builtin
 *  /home/vitti/1tb/vitti/gcc-7/gcc/config/i386/i386.c:41212
 * 0x707354 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
 *  /home/vitti/1tb/vitti/gcc-7/gcc/builtins.c:5801
 * 0x82cf69 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
 *  /home/vitti/1tb/vitti/gcc-7/gcc/expr.c:10733
 * 0x71272c initialize_argument_information
 *  /home/vitti/1tb/vitti/gcc-7/gcc/calls.c:1204
 * 0x714f01 expand_call(tree_node*, rtx_def*, int)
 *  /home/vitti/1tb/vitti/gcc-7/gcc/calls.c:2857
 * 0x82cb4d expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
 *  /home/vitti/1tb/vitti/gcc-7/gcc/expr.c:10736
 * 0x83838b store_expr_with_bounds(tree_node*, rtx_def*, int, bool, bool,
tree_node*)
 *  /home/vitti/1tb/vitti/gcc-7/gcc/expr.c:5547
 * 0x839e13 expand_assignment(tree_node*, tree_node*, bool)
 *  /home/vitti/1tb/vitti/gcc-7/gcc/expr.c:5316
 * 0x729b45 expand_call_stmt
 *  /home/vitti/1tb/vitti/gcc-7/gcc/cfgexpand.c:2665
 * 0x729b45 expand_gimple_stmt_1
 *  /home/vitti/1tb/vitti/gcc-7/gcc/cfgexpand.c:3580
 * 0x729b45 expand_gimple_stmt
 *  /home/vitti/1tb/vitti/gcc-7/gcc/cfgexpand.c:3746
 * 0x72c740 expand_gimple_basic_block
 *  /home/vitti/1tb/vitti/gcc-7/gcc/cfgexpand.c:5753
 * 0x7314ee execute
 *  /home/vitti/1tb/vitti/gcc-7/gcc/cfgexpand.c:6367
 * Please submit a full bug report,
 * with preprocessed source if appropriate.
 * Please include the complete backtrace with any bug report.
 * See <http://gcc.gnu.org/bugs.html> for instructions.
 */

[Bug fortran/49630] [OOP] ICE on obsolescent deferred-length type bound character function

[zeccav at gmail dot com]

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

--- Comment #14 from Vittorio Zecca  ---
(In reply to Dominique d'Humieres from comment #13)
> > I am still having an ICE as in comment 11.
> 
> Me too even on trunk (7.0.1)!-(I also get an ICE with the original test.)
> Reopening the PR.
> 
> > Opening a new bug.
> 
> Did you do it?

No I did not open a new bug, because it already exists as 68045.

[Bug middle-end/67338] fold-const sanitizer runtime error in roundup_loc

[zeccav at gmail dot com]

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

--- Comment #1 from Vittorio Zecca  ---
Still in 7.0.1

../../gcc-7-246252/gcc/fold-const.c:14253:11: runtime error: negation of
-2147483648 cannot be represented in type 'int'; cast to an unsigned type to
negate this value to itself

[Bug testsuite/67359] struct-layout-1_generate.c undefined behaviour

[zeccav at gmail dot com]

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

Vittorio Zecca  changed:

   What|Removed |Added

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

--- Comment #1 from Vittorio Zecca  ---
I cannot reproduce it in 7.0.1.
Closing as Resolved Fixed.

[Bug fortran/33056] [Meta-bug] Data - statement related bugs

[zeccav at gmail dot com]

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

Bug 67497 Summary: data.c sanitizer runtime error: null pointer passed as 
argument 2, which is declared to never be null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67497

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

[Bug fortran/67497] data.c sanitizer runtime error: null pointer passed as argument 2, which is declared to never be null

[zeccav at gmail dot com]

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

Vittorio Zecca  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

[Bug fortran/67497] data.c sanitizer runtime error: null pointer passed as argument 2, which is declared to never be null

[zeccav at gmail dot com]

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

--- Comment #8 from Vittorio Zecca  ---
Just back from my travel.
The sanitizer error message disappeared on trunk level 246252.

[Bug middle-end/80100] New: simplify-rtx.c sanitizer detects undefined behaviour with optimization

[zeccav at gmail dot com]

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

Bug ID: 80100
   Summary: simplify-rtx.c sanitizer detects undefined behaviour
with optimization
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

//gcc 7.0.1 trunk 246252 undefined behaviour with optimization
//-O0 and -Og ok, higher levels get undefined
long int
f2 (long int k)
{
  return 2L | ((k - 1L) >> ((int) sizeof (long int) * __CHAR_BIT__ - 1));
}
//../../gcc-7-246252/gcc/simplify-rtx.c:2743:49: runtime error: left shift of 2
by 63 places cannot be represented in type 'long int'
//simplify-rtx.c:2743 is "HOST_WIDE_INT mask = INTVAL (trueop1) << count;

[Bug middle-end/67338] fold-const sanitizer runtime error in roundup_loc

[zeccav at gmail dot com]

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

--- Comment #5 from Vittorio Zecca  ---
I still have a similar issue in 7.0.1

../../gcc-7-246252/gcc/fold-const.c:14253:11: runtime error: negation of
-2147483648 cannot be represented in type 'int'; cast to an unsigned type to
negate this value to itself

compiling

struct { __attribute__((aligned (1 << 28))) double a; };

fold-const.c:14253 is "val &= - (int) divisor;"

Should I open a new bug?

[Bug fortran/49630] [OOP] ICE on obsolescent deferred-length type bound character function

[zeccav at gmail dot com]

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

--- Comment #12 from Vittorio Zecca  ---
I am still having an ICE as in comment 11.
Opening a new bug.

[Bug fortran/50542] gfortran should detect violation of Fortran 95 R536 (r178939)

[zeccav at gmail dot com]

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

--- Comment #3 from Vittorio Zecca  ---
Still present in 7.0.1

[Bug c++/68045] [concepts] segfault in contains_struct_check ../../gcc/gcc/tree.h:2971

[zeccav at gmail dot com]

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

Vittorio Zecca  changed:

   What|Removed |Added

 CC||zeccav at gmail dot com

--- Comment #1 from Vittorio Zecca  ---
On gfortran 7.0.1 I having the same ICE:

  module abc
  implicit none
  type,abstract::abc_abstract
  contains
  procedure(abc_interface),deferred::abc_function
  end type abc_abstract
  type,extends(abc_abstract)::abc_type
  contains
  procedure::abc_function
  end type abc_type
  abstract interface
  function abc_interface(this)
   import abc_abstract
   class(abc_abstract),intent(in)::this
   character(len=*)::abc_interface
  end function abc_interface
  end interface
  contains
  function abc_function(this)
  class(abc_type),intent(in)::this
  character(len=5)::abc_function
  abc_function="hello"
  end function abc_function
  subroutine do_something(this)
  class(abc_abstract),intent(in)::this
  print *,this%abc_function()
  end subroutine do_something
  end module abc


gfortran gfbug111.f
gfbug111.f:30:0:

   print *,this%abc_function()

internal compiler error: Segmentation fault
0xba9c5f crash_signal
../../gcc-7-246252/gcc/toplev.c:337
0x716a88 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc-7-246252/gcc/tree.h:3177
0x716a88 gfc_get_character_type(int, gfc_charlen*)
../../gcc-7-246252/gcc/fortran/trans-types.c:1059
0x6c1073 gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*,
gfc_expr*, vec<tree_node*, va_gc, vl_embed>*)
../../gcc-7-246252/gcc/fortran/trans-expr.c:6007
0x6c212a gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc-7-246252/gcc/fortran/trans-expr.c:7797
0x6ca242 gfc_conv_expr_reference(gfc_se*, gfc_expr*)
../../gcc-7-246252/gcc/fortran/trans-expr.c:7897
0x6f15d2 gfc_trans_transfer(gfc_code*)
../../gcc-7-246252/gcc/fortran/trans-io.c:2508
0x680de7 trans_code
../../gcc-7-246252/gcc/fortran/trans.c:2017
0x6ee252 build_dt
../../gcc-7-246252/gcc/fortran/trans-io.c:1986
0x680e07 trans_code
../../gcc-7-246252/gcc/fortran/trans.c:1989
0x6b2498 gfc_generate_function_code(gfc_namespace*)
../../gcc-7-246252/gcc/fortran/trans-decl.c:6332
0x685d59 gfc_generate_module_code(gfc_namespace*)
../../gcc-7-246252/gcc/fortran/trans.c:2195
0x6395fb translate_all_program_units
../../gcc-7-246252/gcc/fortran/parse.c:6061
0x6395fb gfc_parse_file()
../../gcc-7-246252/gcc/fortran/parse.c:6274
0x67cf6f gfc_be_parse_file
../../gcc-7-246252/gcc/fortran/f95-lang.c:204
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 fortran/44265] Link error with reference to parameter array in specification expression

[zeccav at gmail dot com]

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

--- Comment #24 from Vittorio Zecca  ---
It works on my x86_64-pc-linux-gnu with gfortran 7.0.1

[Bug fortran/50406] ld undefined reference to __MOD_str

[zeccav at gmail dot com]

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

--- Comment #5 from Vittorio Zecca  ---
With 7.0.1 20170318 compiles links and executes correctly.

[Bug fortran/50538] formal argument cannot be same as procedure name in ENTRY

[zeccav at gmail dot com]

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

--- Comment #3 from Vittorio Zecca  ---
Still in 7.0.1

[Bug c/67410] [5 Regression] c/c-typeck.c references out of bounds array

[zeccav at gmail dot com]

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

--- Comment #8 from Vittorio Zecca  ---
Fixed on 7.0.1

[Bug middle-end/77383] -fcheck-pointer-bounds -mmpx ICE with VLA struct return type

[zeccav at gmail dot com]

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

--- Comment #3 from Vittorio Zecca  ---
Still in 7.0.1

[Bug middle-end/80100] simplify-rtx.c sanitizer detects undefined behaviour with optimization

[zeccav at gmail dot com]

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

--- Comment #2 from Vittorio Zecca  ---
simplify-rtx.c:2743 is "HOST_WIDE_INT mask = INTVAL (trueop1) << count;"

[Bug middle-end/80100] simplify-rtx.c sanitizer detects undefined behaviour with optimization

[zeccav at gmail dot com]

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

--- Comment #7 from Vittorio Zecca  ---
(In reply to Jakub Jelinek from comment #5)
> Author: jakub
> Date: Tue Apr 11 17:21:51 2017
> New Revision: 246851
> 
> URL: https://gcc.gnu.org/viewcvs?rev=246851=gcc=rev
> Log:
>   PR middle-end/80100
>   * simplify-rtx.c (simplify_binary_operation_1) : Perform
>   left shift in unsigned HOST_WIDE_INT type.
> 
>   * gcc.dg/pr80100.c: New test.
> 
> Added:
> trunk/gcc/testsuite/gcc.dg/pr80100.c
> Modified:
> trunk/gcc/ChangeLog
> trunk/gcc/simplify-rtx.c
> trunk/gcc/testsuite/ChangeLog

Looking at the diff file, where is the change in line 2744? 
"int count = INTVAL (XEXP (op0, 1));"

Old and new look the same to me.

[Bug c/80413] New: sanitizer detects undefined behaviour in gcov-io.c using -ftest-coverage

[zeccav at gmail dot com]

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

Bug ID: 80413
   Summary: sanitizer detects undefined behaviour in gcov-io.c
using -ftest-coverage
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

/* gcc -ftest-coverage */
/* gcc-trunk-246751/gcc/gcov-io.c:351:10: runtime error: null pointer passed as
argument 2, which is declared to never be null*/
/* gcov-io.c:351 "memcpy ([1], string, length);" */
/* string is NULL but most probably length is zero */
int main () {}

[Bug middle-end/77486] ubsan detects runtime error: left shift of negative value -3 at real_hash in real.c:2890

[zeccav at gmail dot com]

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

--- Comment #2 from Vittorio Zecca  ---
Still in trunk

/home/vitti/1tb/vitti/test/gcc-trunk-239276/gcc/real.c:2889:25: runtime error:
left shift of negative value -3

[Bug middle-end/77486] ubsan detects runtime error: left shift of negative value -3 at real_hash in real.c:2890

[zeccav at gmail dot com]

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

Vittorio Zecca  changed:

   What|Removed |Added

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

--- Comment #6 from Vittorio Zecca  ---
Fixed in trunk level 246252.
Closing as Resolved Fixed.

[Bug middle-end/77486] ubsan detects runtime error: left shift of negative value -3 at real_hash in real.c:2890

[zeccav at gmail dot com]

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

--- Comment #7 from Vittorio Zecca  ---
(In reply to Jakub Jelinek from comment #5)
> Even r246252 is more than 2 weeks old.  Why not latest trunk?

Because I have no time to download and check every trunk.

[Bug middle-end/77486] ubsan detects runtime error: left shift of negative value -3 at real_hash in real.c:2890

[zeccav at gmail dot com]

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

--- Comment #4 from Vittorio Zecca  ---
This is on trunk level 239276.
Going to check on newer level 246252.

[Bug fortran/80395] New: verify_gimple fails with Error: invalid reference prefix with -O3 -finline-functions

[zeccav at gmail dot com]

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

Bug ID: 80395
   Summary: verify_gimple fails with Error: invalid reference
prefix with -O3 -finline-functions
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

Created attachment 41175
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41175=edit
To be compiled with -O3 and optionally -finline-functions

gfortran -S -O3 ~/f95/gfbug128.f -finline-functions 
/home/vitti/f95/gfbug128.f:32:0:

   SUBROUTINE CCHK6( SNAME, EPS, THRESH, NOUT, NTRA, TRACE, REWI,

Error: invalid reference prefix
MEM[base: yt_418(D), index: ivtmp.437_1019, step: 2, offset: 0B]
/home/vitti/f95/gfbug128.f:420:0:

  YT( IY ) = ZERO

note: in statement
# .MEM_748 = VDEF <.MEM_722>
IMAGPART_EXPR <MEM[base: yt_418(D), index: ivtmp.437_1019, step: 2, offset:
0B]> = 0.0;
/home/vitti/f95/gfbug128.f:32:0:

   SUBROUTINE CCHK6( SNAME, EPS, THRESH, NOUT, NTRA, TRACE, REWI,

internal compiler error: verify_gimple failed
0xbf501e verify_gimple_in_cfg(function*, bool)
../../gcc-trunk-246751/gcc/tree-cfg.c:5266
0xad86c6 execute_function_todo
../../gcc-trunk-246751/gcc/passes.c:1966
0xad9712 execute_todo
../../gcc-trunk-246751/gcc/passes.c:2016
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 libfortran/67540] string_intrinsics_inc.c sanitizer detects null pointer passed to memcpy

[zeccav at gmail dot com]

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

--- Comment #9 from Vittorio Zecca  ---
This test case is wrong.
It dereferences thrice a NULL pointer str4.
Unfortunately -fcheck=pointer does not detect this one. 
Just added to the CC list the test case author.

[Bug libfortran/67540] string_intrinsics_inc.c sanitizer detects null pointer passed to memcpy

[zeccav at gmail dot com]

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

--- Comment #13 from Vittorio Zecca  ---
In C strings are pointers, in Fortran they are not.

So ptr="string" is wrong.

As in the following:
character, pointer :: cptr
cptr="qwerty"
end
Running it I get a SIGSEGV.

[Bug sanitizer/80424] New: libasan uses tempnam tmpnam tmpnam_r

[zeccav at gmail dot com]

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

Bug ID: 80424
   Summary: libasan uses tempnam tmpnam tmpnam_r
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav 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: ---
  Host: x86_64-pc-linux-gnu

Running make check on an address sanitized version of gcc trunk 246751
I get lots of the following:

/home/vitti/1tb/vitti/local/gcc-7-246751/lib64/libasan.so.4: warning: the use
of `tempnam' is dangerous, better use `mkstemp'
/home/vitti/1tb/vitti/local/gcc-7-246751/lib64/libasan.so.4: warning: the use
of `tmpnam' is dangerous, better use `mkstemp'
/home/vitti/1tb/vitti/local/gcc-7-246751/lib64/libasan.so.4: warning: the use
of `tmpnam_r' is dangerous, better use `mkstemp'

Is the address sanitizer using dangerous system calls?

Then they should be changed to mkstemp. 

Otherwise is there a way to avoid those warnings?
Maybe setting a global variable?

[Bug libfortran/67540] string_intrinsics_inc.c sanitizer detects null pointer passed to memcpy

[zeccav at gmail dot com]

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

--- Comment #11 from Vittorio Zecca  ---
Actually, the null pointer str4 is dereferenced four times:
at lines 39, 40, 68, 69.

[Bug c++/80489] New: Regression no matching function

[zeccav at gmail dot com]

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

Bug ID: 80489
   Summary: Regression no matching function
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu

// REGRESSION g++ 6.3.0 compiles successfully
// g++ 7.0.1 trunk 246751 emits error message 
// In static member function ‘static void FixedBodyDescriptor<start_offset,
end_offset, size>::IB(int*, int)’:
// error: no matching function for call to ‘FixedBodyDescriptor<start_offset,
end_offset, size>::IterateBody(int*&)’
//IterateBody(obj);
template 
class FixedBodyDescriptor {

  template 
  static inline void IterateBody(int* obj) {}

  template 
   static inline void IB(int* obj, int object_size) {
   IterateBody(obj);
  }
};

[Bug c++/80489] Regression no matching function

[zeccav at gmail dot com]

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

--- Comment #2 from Vittorio Zecca  ---
I did not know that one, my C++ knowledge is so limited.
This is a fragment I took from chromium web browser and I was fooled because
it is succesfully compiled by older g++, clang, and Intel icpc.

[Bug libfortran/80365] New: undefined memcpy while writing zero length array on unformatted stream in unix.c

[zeccav at gmail dot com]

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

Bug ID: 80365
   Summary: undefined memcpy while writing zero length array on
unformatted stream in unix.c
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

! undefined memcpy writing zero length array on unformatted stream
! must be compiled and run
! ../../../gcc-trunk-246751/libgfortran/io/unix.c:596:7: runtime error: null
pointer passed as argument 2, which is declared to never be null
! unix.c:596 is "memcpy (s->buffer + (s->logical_offset - s->buffer_offset),
buf, nbyte);"
! buf is zero but luckily nbyte is zero as well
! just in case I suggest putting "assert(buf || !nbyte);" before memcpy
  real v(1:0)
  open(1,form='unformatted',access='stream')
  write(unit=1,pos=1) v
  end

This is related to bug 67536

[Bug libfortran/67540] string_intrinsics_inc.c sanitizer detects null pointer passed to memcpy

[zeccav at gmail dot com]

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

Vittorio Zecca  changed:

   What|Removed |Added

 Target||x86_64-pc-linux-gnu
   Host||x86_64-pc-linux-gnu
Version|5.2.0   |7.0.1

--- Comment #8 from Vittorio Zecca  ---
Still in trunk 246751.

Running testsuite program allocate_deferred_char_scalar_1.exe

[Bug c/80364] New: sanitizer detects signed integer overflow in gimple-ssa-sprintf.c

[zeccav at gmail dot com]

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

Bug ID: 80364
   Summary: sanitizer detects signed integer overflow in
gimple-ssa-sprintf.c
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

/* from pr72858.c */
/*../../gcc-trunk-246751/gcc/gimple-ssa-sprintf.c:1007:22: runtime error:
negation of -9223372036854775808 cannot be represented in type 'long int [3]';
cast to an unsigned type to negate this value to itself
../../gcc-trunk-246751/gcc/gimple-ssa-sprintf.c:773:7: runtime error: signed
integer overflow: 1 + 9223372036854775807 cannot be represented in type 'long
int [3]'
*/
/* COLLECT_GCC_OPTIONS='-S' '-v' '-mtune=generic' '-march=x86-64' */
#include 
void
test_everything (char *d, long lexpr)
{
  sprintf (d, "before %-+*.*lld after", lexpr, lexpr, lexpr);
}

[Bug middle-end/80100] simplify-rtx.c sanitizer detects undefined behaviour with optimization

[zeccav at gmail dot com]

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

--- Comment #1 from Vittorio Zecca  ---
Still in trunk 246751.

[Bug middle-end/67486] ira-color.c sanitizer detects signed integer overflow

[zeccav at gmail dot com]

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

Vittorio Zecca  changed:

   What|Removed |Added

Version|5.2.0   |7.0.1

--- Comment #2 from Vittorio Zecca  ---
Still in trunk 246751.

[Bug tree-optimization/62058] Undefined behaviour in tree-data-ref.c with options -O1 -ftree-loop-vectorize

[zeccav at gmail dot com]

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

Vittorio Zecca  changed:

   What|Removed |Added

Version|4.9.1   |7.0.1

--- Comment #5 from Vittorio Zecca  ---
Still in trunk 246751.

[Bug rtl-optimization/66940] ifcvt.c:1907 signed integer overflow

[zeccav at gmail dot com]

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

Vittorio Zecca  changed:

   What|Removed |Added

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

--- Comment #4 from Vittorio Zecca  ---
Fixed in trunk 246751.

[Bug middle-end/71074] combine.c in simplify_comparison sanitizer detects left shift of negative value

[zeccav at gmail dot com]

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

Vittorio Zecca  changed:

   What|Removed |Added

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

--- Comment #2 from Vittorio Zecca  ---
Fixed in trunk 246751.

[Bug rtl-optimization/66940] ifcvt.c:1907 signed integer overflow

[zeccav at gmail dot com]

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

--- Comment #5 from Vittorio Zecca  ---
Fixed in trunk 246751.

[Bug libfortran/80365] undefined memcpy while writing zero length array on unformatted stream in unix.c

[zeccav at gmail dot com]

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

--- Comment #4 from Vittorio Zecca  ---
Or you may add

assert(buf);

just before the memcpy library call.

If nbyte==0 then it should be harmless, but undefined.

assert(buf || !nbyte) should catch an error situation

[Bug fortran/80751] NULL pointer dereferencing in gfc_trans_call on compiling call to an elemental procedure (trunk 247930)

[zeccav at gmail dot com]

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

--- Comment #3 from Vittorio Zecca  ---
(In reply to Dominique d'Humieres from comment #1)
> > This issue is exposed by adding a gcc_assert at trans-stmt.c:455
> 
> Could you please be more explicit about what you changed in trans-stmt.c and
> why you are doing that?

I believe I answered your question.

The NULL pointer dereferencing is still in trunk 249961

[Bug fortran/80751] NULL pointer dereferencing in gfc_trans_call on compiling call to an elemental procedure (trunk 247930)

[zeccav at gmail dot com]

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

--- Comment #4 from Vittorio Zecca  ---
I believe I answered your question.

The NULL pointer dereferencing is still in trunk 249961

[Bug fortran/80751] NULL pointer dereferencing in gfc_trans_call on compiling call to an elemental procedure (trunk 247930)

[zeccav at gmail dot com]

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

--- Comment #6 from Vittorio Zecca  ---
I am sorry, I went by memory and I swapped two digits, I have trunk 249691,
tomorrow I am downloading the latest trunk.

[Bug c/81302] [7/8 Regression] Segmentation fault in diagnose_tm_1 at trans-mem.c

[zeccav at gmail dot com]

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

--- Comment #2 from Vittorio Zecca  ---
Maybe is this related?

// trunk 249883
// from pr46269.C
// Segmentation fault
// must be compiled with command g++ -fsanitize=address -fgnu-tm 
template class shared_ptr
{
public:
  shared_ptr( T * p )
  {
  }
};

class BuildingCompletedEvent
{
  public:
  __attribute__((transaction_callable)) void updateBuildingSite(void);
  BuildingCompletedEvent();
};

void BuildingCompletedEvent::updateBuildingSite(void)
{
  shared_ptr event(new BuildingCompletedEvent());
}
/*
 * during IPA pass: tmipa
 In member function ‘void BuildingCompletedEvent::updateBuildingSite()’:
 internal compiler error: Segmentation fault
 }
 ^
0xe66cef crash_signal
../../gcc-249883/gcc/toplev.c:338
0xe6b2e0 is_tm_irrevocable
../../gcc-249883/gcc/trans-mem.c:234
0xe6ca0f ipa_tm_scan_irr_block
../../gcc-249883/gcc/trans-mem.c:4408
0xe6ca0f ipa_tm_scan_irr_blocks
../../gcc-249883/gcc/trans-mem.c:4479
0xe6dc14 ipa_tm_scan_irr_function
../../gcc-249883/gcc/trans-mem.c:4641
0xe6f54e ipa_tm_execute
../../gcc-249883/gcc/trans-mem.c:5547
0xe6f54e execute
../../gcc-249883/gcc/trans-mem.c:5705
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c/81302] New: Segmentation fault in diagnose_tm_1 at trans-mem.c

[zeccav at gmail dot com]

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

Bug ID: 81302
   Summary: Segmentation fault in diagnose_tm_1 at trans-mem.c
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

/* from volatile-1.c */
/* in trunk 249883 */
/* must be compiled with command gcc -fgnu-tm -fsanitize=address */
__attribute ((transaction_safe))
int f() {
  int x;
 
}
/*
 * during GIMPLE pass: *diagnose_tm_blocks
 In function ‘f’:
 internal compiler error: Segmentation fault
 int f() {
 ^
0xc5f4df crash_signal
../../gcc-249883/gcc/toplev.c:338
0xc64cbe diagnose_tm_1
../../gcc-249883/gcc/trans-mem.c:664
0x9f071a walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc-249883/gcc/gimple-walk.c:568
0x9f09f5 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc-249883/gcc/gimple-walk.c:51
0x9f08d2 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc-249883/gcc/gimple-walk.c:631
0x9f09f5 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc-249883/gcc/gimple-walk.c:51
0x9f08aa walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc-249883/gcc/gimple-walk.c:595
0x9f09f5 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc-249883/gcc/gimple-walk.c:51
0x9f0a66 walk_gimple_seq(gimple*, tree_node* (*)(gimple_stmt_iterator*, bool*,
walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*)
../../gcc-249883/gcc/gimple-walk.c:81
0xc64b68 diagnose_tm_blocks
../../gcc-249883/gcc/trans-mem.c:848
0xc64b68 execute
../../gcc-249883/gcc/trans-mem.c:878
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 c++/81293] New: sanitized g++ crashes heap-use-after-free gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors_format.inc:543 in printf_common

[zeccav at gmail dot com]

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

Bug ID: 81293
   Summary: sanitized g++ crashes heap-use-after-free
gcc/libsanitizer/sanitizer_common/sanitizer_common_int
erceptors_format.inc:543 in printf_common
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

// in trunk 249883
// from devirt-45.C
// compile with -fdump-ipa-inline-details -fno-early-inlining -O2 
// SUMMARY: AddressSanitizer: heap-use-after-free
../../../../gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors_format.inc:543
in printf_common
struct A {
  virtual int foo () {return 1;}
  int wrapfoo () {foo();}
  A() {wrapfoo();}
};
inline void* operator new(__SIZE_TYPE__ s, void* buf) throw() {
   return buf;
}
struct B:A {virtual int foo () {return 2;}};

static void
test (struct A *a)
{
  static_cast<B*>(a)->~B();
  new(a) B();
}

main()
{
  struct B a;
  test ();
}
/*=
==10147==ERROR: AddressSanitizer: heap-use-after-free on address 0x60272470
at pc 0x2b6feac184fb bp 0x7ffcd9ff38e0 sp 0x7ffcd9ff3090
READ of size 2 at 0x60272470 thread T0
#0 0x2b6feac184fa in printf_common
../../../../gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors_format.inc:543
#1 0x2b6feac534ff in __asan::ErrorDescription::Print()
../../../../gcc/libsanitizer/asan/asan_errors.h:360
#2 0x2b6feac534ff in __asan::ScopedInErrorReport::~ScopedInErrorReport()
../../../../gcc/libsanitizer/asan/asan_report.cc:167
#3 0x2b6feac534ff in __asan::ReportGenericError(unsigned long, unsigned
long, unsigned long, unsigned long, bool, unsigned long, unsigned int, bool)
../../../../gcc/libsanitizer/asan/asan_report.cc:397
#4 0x2b6feac1832b in printf_common
../../../../gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors_format.inc:543
#5 0x2b6feac1925b in __interceptor_vfprintf
../../../../gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:1328
#6 0x2b6feac19326 in __interceptor_fprintf
../../../../gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:1373
#7 0x53ab70c in inline_small_functions ../../gcc/gcc/ipa-inline.c:2048
#8 0x53b10a5 in ipa_inline ../../gcc/gcc/ipa-inline.c:2429
#9 0x53b3fb8 in execute ../../gcc/gcc/ipa-inline.c:2835
#10 0x2833dc7 in execute_one_pass(opt_pass*) ../../gcc/gcc/passes.c:2492
#11 0x28384cc in execute_ipa_pass_list(opt_pass*)
../../gcc/gcc/passes.c:2927
#12 0x178ae2d in ipa_passes ../../gcc/gcc/cgraphunit.c:2388
#13 0x178be18 in symbol_table::compile() ../../gcc/gcc/cgraphunit.c:2474
#14 0x178cec5 in symbol_table::finalize_compilation_unit()
../../gcc/gcc/cgraphunit.c:2633
#15 0x2dbbe22 in compile_file ../../gcc/gcc/toplev.c:493
#16 0x2dc3f8a in do_compile ../../gcc/gcc/toplev.c:2021
#17 0x2dc49aa in toplev::main(int, char**) ../../gcc/gcc/toplev.c:2155
#18 0x56b3cbe in main ../../gcc/gcc/main.c:39
#19 0x2b6fed475400 in __libc_start_main (/usr/lib64/libc.so.6+0x20400)
#20 0x78a619 in _start
(/home/vitti/1tb/vitti/local/gcc-249691-sanitized/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/cc1plus+0x78a619)

0x60272470 is located 0 bytes inside of 7-byte region
[0x60272470,0x60272477)
freed by thread T0 here:
#0 0x2b6feac49088 in __interceptor_free
../../../../gcc/libsanitizer/asan/asan_malloc_linux.cc:45
#1 0x11611c1 in cxx_printable_name_internal ../../gcc/gcc/cp/tree.c:2544
#2 0x116153a in cxx_printable_name(tree_node*, int)
../../gcc/gcc/cp/tree.c:2555
#3 0x16fbf9e in symtab_node::name() const ../../gcc/gcc/symtab.c:522
#4 0x53ab69b in inline_small_functions ../../gcc/gcc/ipa-inline.c:2048
#5 0x53b10a5 in ipa_inline ../../gcc/gcc/ipa-inline.c:2429
#6 0x53b3fb8 in execute ../../gcc/gcc/ipa-inline.c:2835
#7 0x2833dc7 in execute_one_pass(opt_pass*) ../../gcc/gcc/passes.c:2492
#8 0x28384cc in execute_ipa_pass_list(opt_pass*)
../../gcc/gcc/passes.c:2927
#9 0x178ae2d in ipa_passes ../../gcc/gcc/cgraphunit.c:2388
#10 0x178be18 in symbol_table::compile() ../../gcc/gcc/cgraphunit.c:2474
#11 0x178cec5 in symbol_table::finalize_compilation_unit()
../../gcc/gcc/cgraphunit.c:2633
#12 0x2dbbe22 in compile_file ../../gcc/gcc/toplev.c:493
#13 0x2dc3f8a in do_compile ../../gcc/gcc/toplev.c:2021
#14 0x2dc49aa in toplev::main(int, char**) ../../gcc/gcc/toplev.c:2155
#15 0x56b3cbe in main ../../gcc/gcc/main.c:39
#16 0x2b6fed475400 in __libc_start_main (/usr/lib64/libc.so.6+0x20400)

previously allocated by thread T0 here:
#0 0x2b6feac493aa in __interceptor_malloc
../../../../gcc/libsanitizer/asan/asan_malloc_linux.cc:62
#1 0x595d890 in xmalloc ../../gcc/libiberty/xmalloc.c:1

[Bug fortran/80751] NULL pointer dereferencing in gfc_trans_call on compiling call to an elemental procedure (trunk 247930)

[zeccav at gmail dot com]

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

--- Comment #7 from Vittorio Zecca  ---
After downloading trunk 249883 I can confirm the bug disappeared.

[Bug sanitizer/81322] New: -fsanitize=address ICE in prepare_function_start, at function.c

[zeccav at gmail dot com]

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

Bug ID: 81322
   Summary: -fsanitize=address ICE in prepare_function_start, at
function.c
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav 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: ---

/* from times-two.c.before-df.c */
/* in trunk 249883 */
/* must be compiled with option -fsanitize=address */
/* ICE in prepare_function_start, at function.c */
int __RTL (startwith ("rtl-dfinit")) times_two (int i)
{
(function "times_two"
  (insn-chain
(block 2
  (edge-from entry (flags "FALLTHRU"))
  (cnote 4 [bb 2] NOTE_INSN_BASIC_BLOCK)
  (edge-to exit (flags "FALLTHRU"))
) ;; block 2
  ) ;; insn-chain
) ;; function "times_two"
}
/* In function ‘_GLOBAL__sub_I_00099_0_times_two’:
 internal compiler error: in prepare_function_start, at function.c:4974
 }
 ^
0x5dd409 prepare_function_start
../../gcc-249883/gcc/function.c:4974
0x9bdded init_function_start(tree_node*)
../../gcc-249883/gcc/function.c:5050
0x89661b cgraph_node::expand()
../../gcc-249883/gcc/cgraphunit.c:2036
0x896c47 cgraph_node::add_new_function(tree_node*, bool)
../../gcc-249883/gcc/cgraphunit.c:586
0xaa06dd cgraph_build_static_cdtor_1
../../gcc-249883/gcc/ipa.c:936
0xc7a3b6 asan_finish_file()
../../gcc-249883/gcc/asan.c:2727
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 c/81319] New: ICE in output_operand_lossage at final.c

[zeccav at gmail dot com]

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

Bug ID: 81319
   Summary: ICE in output_operand_lossage at final.c
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

/* from shrink-wrap-separate-0.c */
/* in trunk 249883 */
/* ICE in output_operand_lossage at final.c */
void f(int x)
{
register int r20 asm("20") = x;
}
/*
 * In function ‘f’:
error: frame cannot be used in asm here
 }
 ^
during RTL pass: final
internal compiler error: output_operand: invalid use of register 'frame'
0x975982 output_operand_lossage(char const*, ...)
../../gcc-249883/gcc/final.c:3459
0xf9a37c ix86_print_operand(_IO_FILE*, rtx_def*, int)
../../gcc-249883/gcc/config/i386/i386.c:19181
0x975c71 output_operand(rtx_def*, int)
../../gcc-249883/gcc/final.c:3893
0x97670f output_asm_insn(char const*, rtx_def**)
../../gcc-249883/gcc/final.c:3809
0x9777d7 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
../../gcc-249883/gcc/final.c:3060
0x978cca final(rtx_insn*, _IO_FILE*, int)
../../gcc-249883/gcc/final.c:2053
0x979099 rest_of_handle_final
../../gcc-249883/gcc/final.c:4494
0x979099 execute
../../gcc-249883/gcc/final.c:4567
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 target/79636] [5/6/7/8 Regression] ICE in assign_by_spills, at lra-assigns.c:1457

[zeccav at gmail dot com]

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

Vittorio Zecca  changed:

   What|Removed |Added

 CC||zeccav at gmail dot com

--- Comment #3 from Vittorio Zecca  ---
Still in trunk 249883:

/* from pr65693.c */
/* in trunk 249883 */
/* internal compiler error: in assign_by_spills, at lra-assigns.c */
void
foo (int (*fn) (int, int, int), unsigned int b)
{
  unsigned long *c = (unsigned long *) __builtin_alloca (b);
  register int d asm ("edx") = fn (0, 0, d);
}
/*
 * p.c: In function ‘foo’:
error: unable to find a register to spill
 }
 ^
error: this is the insn:
(insn 11 31 12 2 (parallel [
(set (reg:DI 94)
(udiv:DI (reg:DI 92)
(reg:DI 103)))
(set (reg:DI 104 [95])
(umod:DI (reg:DI 92)
(reg:DI 103)))
(clobber (reg:CC 17 flags))
]) "p.c":7 370 {*udivmoddi4}
 (expr_list:REG_UNUSED (reg:DI 104 [95])
(expr_list:REG_DEAD (reg:DI 103)
(expr_list:REG_DEAD (reg:DI 92)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil))
during RTL pass: reload
internal compiler error: in assign_by_spills, at lra-assigns.c:1476
0x6216cc _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc-249883/gcc/rtl-error.c:108
0xaf2f5e assign_by_spills
../../gcc-249883/gcc/lra-assigns.c:1476
0xaf4276 lra_assign()
../../gcc-249883/gcc/lra-assigns.c:1670
0xaef29c lra(_IO_FILE*)
../../gcc-249883/gcc/lra.c:2451
0xaa7281 do_reload
../../gcc-249883/gcc/ira.c:5440
0xaa7281 execute
../../gcc-249883/gcc/ira.c:5624
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 fortran/50402] ICE in gfc_conv_expr_descriptor

[zeccav at gmail dot com]

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

Vittorio Zecca  changed:

   What|Removed |Added

Version|4.8.0   |8.0

--- Comment #6 from Vittorio Zecca  ---
This is still in trunk 249883

The test case may be wrong, but

1) gfortran should never crash but deliver an error message instead

2) on this test case gfortran is giving no error message
   so how do I know it is wrong?

[Bug fortran/50402] ICE in gfc_conv_expr_descriptor

[zeccav at gmail dot com]

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

--- Comment #8 from Vittorio Zecca  ---
1) Sometimes error reports slip through the cracks, it happened to me,
and I found it's good
to remind that the bug is still around. Sometimes it happened the
contrary, the bug silently
disappears but the error report is still open.
There are more things in heaven and earth, Horatio, Than are
dreamt of in your philosophy.

2)  At least I got an answer from you, that an error would be better
than an ICE,
 this is obvious to me but not to everybody, it also influences
the credibility
 of a product, a crashing product is less credible than a product
issuing error messages.