[Bug sanitizer/99662] New: GNAT compiled with the address sanitizer fails at build time

[zeccav at gmail dot com via Gcc-bugs]

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

Bug ID: 99662
   Summary: GNAT compiled with the address sanitizer fails at
build time
   Product: gcc
   Version: 11.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: ---

Building the ada compiler with address sanitation I get the following:

atree.adb:3764 "pragma Assert (Nkind (N) in N_Entity);"


make[7]: Entering directory '/home/vitti/gcc-150321-ada-address/gcc/ada/rts'
/home/vitti/gcc-150321-ada-address/./gcc/xgcc
-B/home/vitti/gcc-150321-ada-address/./gcc/
-B/home/vitti/local/gcc-150321-ada-address/x86_64-pc-linux-gnu/bin/
-B/home/vitti/local/gcc-150321-ada-address/x86_64-pc-linux-gnu/lib/ -isystem
/home/vitti/local/gcc-150321-ada-address/x86_64-pc-linux-gnu/include -isystem
/home/vitti/local/gcc-150321-ada-address/x86_64-pc-linux-gnu/sys-include-c
-g -O2  -fpic  -W -Wall -gnatpg -nostdinc   a-assert.adb -o a-assert.o
+===GNAT BUG DETECTED==+
| 11.0.1 20210315 (experimental) (x86_64-pc-linux-gnu) Assert_Failure
atree.adb:3764|
| Error detected at system.ads:47:4|
| Please submit a bug report; see https://gcc.gnu.org/bugs/ .  |
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact command that you entered.  |
| Also include sources listed below.   |
+==+

[Bug other/86656] [meta-bug] Issues found with -fsanitize=address

[zeccav at gmail dot com via Gcc-bugs]

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

Bug 99624 Summary: Address sanitizer detects heap-buffer-overflow in namet.adb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99624

   What|Removed |Added

 Status|SUSPENDED   |RESOLVED
 Resolution|--- |INVALID

[Bug ada/99624] Address sanitizer detects heap-buffer-overflow in namet.adb

[zeccav at gmail dot com via Gcc-bugs]

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

Vittorio Zecca  changed:

   What|Removed |Added

 Status|SUSPENDED   |RESOLVED
 Resolution|--- |INVALID

--- Comment #9 from Vittorio Zecca  ---
I believe this is invalid issue, the real issue is that gcc miscompiles 
the Ada compiler with the option -fsanitize=address.

I am opening a new issue with the GNAT BUG DETECTED message.

[Bug ada/99624] Address sanitizer detects heap-buffer-overflow in namet.adb

[zeccav at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Vittorio Zecca  ---
Address sanitizer of Version 11.0.1 current trunk miscompiles the Ada
compiler, maybe a previous version would work.
Undefined behavior sanitizer works.
I am now trying to build the Ada compiler with gcc 9.1.0.

[Bug ada/99624] Address sanitizer detects heap-buffer-overflow in namet.adb

[zeccav at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Vittorio Zecca  ---
It is not that easy, unfortunately.

If I compile the build with -gnata, thereby arming the pragma assert,
the build fails.
So I had to build without -gnata.

Now trying to build Ada with gcc 9.1.0
Earlier versions do not work.
Did you try building Ada with address sanitation?

[Bug ada/99624] Address sanitizer detects heap-buffer-overflow in namet.adb

[zeccav at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Vittorio Zecca  ---
I added

pragma Assert (Id in Name_Entries.Table'Range);

at namet.adb:156, but then I get at compile time

namet.adb:156:25: warning: condition can only be False if invalid values
present

and the build stops.
I am very very rusty on Ada, what should I do to check that Id is good?

[Bug ada/99624] Address sanitizer detects heap-buffer-overflow in namet.adb

[zeccav at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Vittorio Zecca  ---
Yes, probably gcc -fsanitize=address is miscompiling the Ada compiler.
I had to take out the -gnata option to disable pragma assert that was failing.

So I do not know if this is a genuine compiler bug or it is due to
miscompilation.

The Ada compiler compiled with the undefined behavior sanitizer
compiles and works fine
with a successful run of the testsuite.

[Bug c/99623] Code behaves differently at -O2 optimization

[zeccav at gmail dot com via Gcc-bugs]

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

Vittorio Zecca  changed:

   What|Removed |Added

 CC||zeccav at gmail dot com

--- Comment #3 from Vittorio Zecca  ---
Where is prb.h ?

[Bug ada/99624] New: Address sanitizer detects heap-buffer-overflow in namet.adb

[zeccav at gmail dot com via Gcc-bugs]

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

Bug ID: 99624
   Summary: Address sanitizer detects heap-buffer-overflow in
namet.adb
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

While building the ada compiler the address sanitizer detecst an
heap-buffer-overflow in namet.adb line 157:

 Index : constant Int   := Name_Entries.Table (Id).Name_Chars_Index;

because Id=-3

make[7]: Entering directory '/home/vitti/gcc-150321-ada-address/gcc/ada/rts'
/home/vitti/gcc-150321-ada-address/./gcc/xgcc
-B/home/vitti/gcc-150321-ada-address/./gcc/
-B/home/vitti/local/gcc-150321-ada-address/x86_64-pc-linux-gnu/bin/
-B/home/vitti/local/gcc-150321-ada-address/x86_64-pc-linux-gnu/lib/ -isystem
/home/vitti/local/gcc-150321-ada-address/x86_64-pc-linux-gnu/include -isystem
/home/vitti/local/gcc-150321-ada-address/x86_64-pc-linux-gnu/sys-include-c
-g -O2  -fpic  -W -Wall -gnatpg -nostdinc   a-assert.adb -o a-assert.o
=
==1168930==ERROR: AddressSanitizer: heap-buffer-overflow on address
0x632007e0 at pc 0x0093e734 bp 0x7ffe21e0f6b0 sp 0x7ffe21e0f6a8
READ of size 4 at 0x632007e0 thread T0
#0 0x93e733 in namet__append__5 ../../gcc-150321/gcc/ada/namet.adb:157
#1 0x93f260 in namet__append_decoded ../../gcc-150321/gcc/ada/namet.adb:177
#2 0x942c2c in namet__get_decoded_name_string
../../gcc-150321/gcc/ada/namet.adb:787
#3 0xe1769e in sem_util__get_default_external_name
../../gcc-150321/gcc/ada/sem_util.adb:10490
#4 0x8adfd5 in freeze__freeze_entity
../../gcc-150321/gcc/ada/freeze.adb:5493
#5 0x8ac9a5 in freeze__freeze_before
../../gcc-150321/gcc/ada/freeze.adb:2126
#6 0xbb087c in sem_ch3__analyze_object_declaration
../../gcc-150321/gcc/ada/sem_ch3.adb:4152
#7 0xaa2e76 in sem__analyze ../../gcc-150321/gcc/ada/sem.adb:351
#8 0xbaadf0 in sem_ch3__analyze_declarations
../../gcc-150321/gcc/ada/sem_ch3.adb:2655
#9 0xc63de4 in sem_ch7__analyze_package_specification
../../gcc-150321/gcc/ada/sem_ch7.adb:1582
#10 0xaa3092 in sem__analyze ../../gcc-150321/gcc/ada/sem.adb:459
#11 0xc638b0 in sem_ch7__analyze_package_declaration
../../gcc-150321/gcc/ada/sem_ch7.adb:1210
#12 0xaa3065 in sem__analyze ../../gcc-150321/gcc/ada/sem.adb:450
#13 0xb0386d in sem_ch10__analyze_compilation_unit
../../gcc-150321/gcc/ada/sem_ch10.adb:913
#14 0xaa2b1f in sem__analyze ../../gcc-150321/gcc/ada/sem.adb:180
#15 0xaa5125 in sem__semantics__do_analyze
../../gcc-150321/gcc/ada/sem.adb:1421
#16 0xaa5d48 in sem__semantics ../../gcc-150321/gcc/ada/sem.adb:1615
#17 0xb0376a in sem_ch10__analyze_compilation_unit
../../gcc-150321/gcc/ada/sem_ch10.adb:878
#18 0xaa2b1f in sem__analyze ../../gcc-150321/gcc/ada/sem.adb:180
#19 0xaa5125 in sem__semantics__do_analyze
../../gcc-150321/gcc/ada/sem.adb:1421
#20 0xaa5d48 in sem__semantics ../../gcc-150321/gcc/ada/sem.adb:1615
#21 0xb0957b in sem_ch10__analyze_with_clause
../../gcc-150321/gcc/ada/sem_ch10.adb:2634
#22 0xaa338d in sem__analyze ../../gcc-150321/gcc/ada/sem.adb:613
#23 0xb04fdd in sem_ch10__analyze_context
../../gcc-150321/gcc/ada/sem_ch10.adb:1433
#24 0xb03268 in sem_ch10__analyze_compilation_unit
../../gcc-150321/gcc/ada/sem_ch10.adb:700
#25 0xaa2b1f in sem__analyze ../../gcc-150321/gcc/ada/sem.adb:180
#26 0xaa5125 in sem__semantics__do_analyze
../../gcc-150321/gcc/ada/sem.adb:1421
#27 0xaa5d48 in sem__semantics ../../gcc-150321/gcc/ada/sem.adb:1615
#28 0xb032b7 in sem_ch10__analyze_compilation_unit
../../gcc-150321/gcc/ada/sem_ch10.adb:719
#29 0xaa2b1f in sem__analyze ../../gcc-150321/gcc/ada/sem.adb:180
#30 0xaa5125 in sem__semantics__do_analyze
../../gcc-150321/gcc/ada/sem.adb:1421
#31 0xaa5d48 in sem__semantics ../../gcc-150321/gcc/ada/sem.adb:1615
#32 0x8d0e5f in _ada_frontend ../../gcc-150321/gcc/ada/frontend.adb:422
#33 0xefdd8c in _ada_gnat1drv ../../gcc-150321/gcc/ada/gnat1drv.adb:1237
#34 0x496d83 in gnat_parse_file
../../gcc-150321/gcc/ada/gcc-interface/misc.c:118
#35 0x2182d2d in compile_file ../../gcc-150321/gcc/toplev.c:457
#36 0x218bfe8 in do_compile ../../gcc-150321/gcc/toplev.c:2201
#37 0x218c84b in toplev::main(int, char**)
../../gcc-150321/gcc/toplev.c:2340
#38 0x4c08b33 in main ../../gcc-150321/gcc/main.c:39
#39 0x1468000181e1 in __libc_start_main (/usr/lib64/libc.so.6+0x281e1)
#40 0x41c48d in _start
(/home/vitti/gcc-150321-ada-address/gcc/gnat1+0x41c48d)

0x632007e0 is located 32 bytes to the left of 96000-byte region
[0x63200800,0x63217f00)
allocated by thread T0 here:
#0 0x146800786a8f in __interceptor_malloc
../../../../gcc-150221/libsani

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

[zeccav at gmail dot com via Gcc-bugs]

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

--- Comment #30 from Vittorio Zecca  ---
On the following source code I still have the ICE:

  type t
   integer g
  end type
  type(t) :: u=t(1)
  data u%g /2/ ! should emit diagnostic here
  end

gfortran -S gfbug63.f
gfbug63.f:6:72:

6 |   type t
  |   
1
internal compiler error: Segmentation fault
0xe7a01f crash_signal
../../gcc-150221/gcc/toplev.c:327
0x94a42d gfc_conv_structure(gfc_se*, gfc_expr*, int)
../../gcc-150221/gcc/fortran/trans-expr.c:8746
0x94a01f gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool,
bool)
../../gcc-150221/gcc/fortran/trans-expr.c:7895
0x92ed34 gfc_get_symbol_decl(gfc_symbol*)
../../gcc-150221/gcc/fortran/trans-decl.c:1917
0x931c03 generate_local_decl
../../gcc-150221/gcc/fortran/trans-decl.c:5950
0x8ead22 do_traverse_symtree
../../gcc-150221/gcc/fortran/symbol.c:4170
0x932d93 generate_local_vars
../../gcc-150221/gcc/fortran/trans-decl.c:6156
0x932d93 gfc_generate_function_code(gfc_namespace*)
../../gcc-150221/gcc/fortran/trans-decl.c:6815
0x8afaee translate_all_program_units
../../gcc-150221/gcc/fortran/parse.c:6351
0x8afaee gfc_parse_file()
../../gcc-150221/gcc/fortran/parse.c:6620
0x90112f gfc_be_parse_file
../../gcc-150221/gcc/fortran/f95-lang.c:212
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug libstdc++/99382] New: Address sanitizer detects stack-buffer-overflow in stl_construct.h

[zeccav at gmail dot com via Gcc-bugs]

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

Bug ID: 99382
   Summary: Address sanitizer detects stack-buffer-overflow in
stl_construct.h
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

// From test case sizes.cc
// must be compiled and executed
// /home/vitti/gcc-150221-full-address/./gcc/xg++
-B/home/vitti/gcc-150221-full-address/./gcc -nostdinc++
-L/home/vitti/gcc-150221-full-address/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
 -O0 -w -D_GNU_SOURCE -DLOCALEDIR="."
-I/home/vitti/gcc-150221-full-address/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu
-I/home/vitti/gcc-150221-full-address/x86_64-pc-linux-gnu/libstdc++-v3/include
-I/home/vitti/gcc-150221/libstdc++-v3/libsupc++-o ./sizes.exe
/home/vitti/f95/cc/gccerr79.cc -fsanitize=address -fno-omit-frame-pointer -g
// ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffcfe09a19c at
pc 0x00401687 bp 0x7ffcfe099fe0 sp 0x7ffcfe099fd8
//WRITE of size 4 at 0x7ffcfe09a19c thread T0
//#0 0x401686 in void std::_Construct(int*)
/home/vitti/gcc-150221-full-address/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_construct.h:109
//#1 0x4015b6 in __uninit_default_n
/home/vitti/gcc-150221-full-address/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_uninitialized.h:578
//#2 0x4014c6 in __uninitialized_default_n
/home/vitti/gcc-150221-full-address/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_uninitialized.h:639
//#3 0x4013d5 in main
/home/vitti/gcc-150221/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_default_n/p.cc:16
//#4 0x14e2a634c1e1 in __libc_start_main (/usr/lib64/libc.so.6+0x281e1)
//#5 0x40115d in _start
(/home/vitti/gcc-150221/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_default_n/sizes.exe+0x40115d)

//Address 0x7ffcfe09a19c is located in stack of thread T0 at offset 76 in frame
//#0 0x4012f0 in main
/home/vitti/gcc-150221/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_default_n/p.cc:4
//
// stl_construct.h:109 -> "{ ::new(static_cast(__p))
_Tp(std::forward<_Args>(__args)...); }"
//
#include 

int main()
{
  struct Size
  {
int value;

void operator--() { --value; }

int operator>(void*) { return value != 0; }
  };

  int i[3];
  Size n = {4};
  auto j = std::__uninitialized_default_n(i, n); // Fails here
}

[Bug rtl-optimization/99376] New: Sanitizer detects undefined behaviour in rtlanal.c compiling ada

[zeccav at gmail dot com via Gcc-bugs]

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

Bug ID: 99376
   Summary: Sanitizer detects undefined behaviour in rtlanal.c
compiling ada
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

Needs option -O2

-- /home/vitti/gcc-150221-full-undefined/gcc/xgcc -S
-B/home/vitti/gcc-150221-full-undefined/gcc/
-I/home/vitti/gcc-150221-full-undefined/gcc/testsuite/ada/acats/support
~/f95/ada1.adb -O2

-- ../../gcc-150221/gcc/rtlanal.c:5060:35: runtime error: shift exponent 126 is
too large for 64-bit type 'long unsigned int'

-- rtlanal.c:5060 "nonzero &= ~((HOST_WIDE_INT_1U << result_low) - 1);"

WITH REPORT; USE REPORT;
PROCEDURE ada1 IS

 F : LONG_INTEGER;

 FUNCTION IDENT_LONG(A : LONG_INTEGER) RETURN LONG_INTEGER IS
 BEGIN
  IF EQUAL (3, 3) THEN
   RETURN A;
  ELSE
   RETURN 0;
  END IF;
 END IDENT_LONG;

 FUNCTION LONG_OK (X : LONG_INTEGER) RETURN BOOLEAN IS
 BEGIN
return true;
 END;

BEGIN

 F := IDENT_LONG(LONG_INTEGER'FIRST);


 BEGIN
  IF LONG_OK (F*F) THEN
   return ;
  END IF;

 END;



END ada1;

[Bug fortran/82721] [8/9/10/11 Regression] Error message with corrupted text, sometimes ICE

[zeccav at gmail dot com via Gcc-bugs]

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

Vittorio Zecca  changed:

   What|Removed |Added

 CC||zeccav at gmail dot com

--- Comment #13 from Vittorio Zecca  ---
On my sanitized trunk version I get the following.
This is on x86-64 Fedora 33 and line numbers
~/local/gcc-150221-sanitized/bin/gfortran z82721.f90 -S
z82721.f90:3:25:

3 |character(len(c)) :: b
  | 1
Error: Symbol ‘b’ at (1) already has basic type of REAL
=
==147959==ERROR: AddressSanitizer: heap-use-after-free on address
0x604017f8 at pc 0x008b02df bp 0x7fffc363cef0 sp 0x7fffc363cee8
READ of size 8 at 0x604017f8 thread T0
#0 0x8b02de in check_host_association
../../gcc-150221/gcc/fortran/resolve.c:5978
#1 0x8c1b4b in gfc_resolve_expr(gfc_expr*)
../../gcc-150221/gcc/fortran/resolve.c:7096
#2 0x91d1bf in resolve_index_expr
../../gcc-150221/gcc/fortran/resolve.c:12406
#3 0x91d79f in resolve_charlen ../../gcc-150221/gcc/fortran/resolve.c:12459
#4 0x96f604 in resolve_types ../../gcc-150221/gcc/fortran/resolve.c:17294
#5 0x970adf in gfc_resolve(gfc_namespace*)
../../gcc-150221/gcc/fortran/resolve.c:17411
#6 0x81fc90 in resolve_all_program_units
../../gcc-150221/gcc/fortran/parse.c:6290
#7 0x82229f in gfc_parse_file() ../../gcc-150221/gcc/fortran/parse.c:6542
#8 0xa64b7c in gfc_be_parse_file
../../gcc-150221/gcc/fortran/f95-lang.c:212
#9 0x33fa43d in compile_file ../../gcc-150221/gcc/toplev.c:457
#10 0x34097a2 in do_compile ../../gcc-150221/gcc/toplev.c:2197
#11 0x340a39f in toplev::main(int, char**)
../../gcc-150221/gcc/toplev.c:2336
#12 0x7f24cb9 in main ../../gcc-150221/gcc/main.c:39
#13 0x147bdbb291e1 in __libc_start_main (/usr/lib64/libc.so.6+0x281e1)
#14 0x41958d in _start
(/home/vitti/1TB/local/gcc-150221-sanitized/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/f951+0x41958d)

0x604017f8 is located 40 bytes inside of 48-byte region
[0x604017d0,0x60401800)
freed by thread T0 here:
#0 0x147bdca7b797 in __interceptor_free
../../../../gcc-150221/libsanitizer/asan/asan_malloc_linux.cpp:127
#1 0xa1cd6f in gfc_delete_symtree(gfc_symtree**, char const*)
../../gcc-150221/gcc/fortran/symbol.c:2964
#2 0xa25801 in gfc_restore_last_undo_checkpoint()
../../gcc-150221/gcc/fortran/symbol.c:3706
#3 0xa25a5f in gfc_undo_symbols()
../../gcc-150221/gcc/fortran/symbol.c:3739
#4 0x80175f in reject_statement ../../gcc-150221/gcc/fortran/parse.c:2678
#5 0x7f2bb0 in match_word ../../gcc-150221/gcc/fortran/parse.c:70
#6 0x7f445d in decode_statement ../../gcc-150221/gcc/fortran/parse.c:376
#7 0x7fd6c8 in next_free ../../gcc-150221/gcc/fortran/parse.c:1316
#8 0x7fe845 in next_statement ../../gcc-150221/gcc/fortran/parse.c:1548
#9 0x80cb86 in parse_spec ../../gcc-150221/gcc/fortran/parse.c:3967
#10 0x81bef7 in parse_progunit ../../gcc-150221/gcc/fortran/parse.c:5896
#11 0x821732 in gfc_parse_file() ../../gcc-150221/gcc/fortran/parse.c:6437
#12 0xa64b7c in gfc_be_parse_file
../../gcc-150221/gcc/fortran/f95-lang.c:212
#13 0x33fa43d in compile_file ../../gcc-150221/gcc/toplev.c:457
#14 0x34097a2 in do_compile ../../gcc-150221/gcc/toplev.c:2197
#15 0x340a39f in toplev::main(int, char**)
../../gcc-150221/gcc/toplev.c:2336
#16 0x7f24cb9 in main ../../gcc-150221/gcc/main.c:39
#17 0x147bdbb291e1 in __libc_start_main (/usr/lib64/libc.so.6+0x281e1)

previously allocated by thread T0 here:
#0 0x147bdca7bc47 in __interceptor_calloc
../../../../gcc-150221/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0x83c3e31 in xcalloc ../../gcc-150221/libiberty/xmalloc.c:162
#2 0xa1cade in gfc_new_symtree(gfc_symtree**, char const*)
../../gcc-150221/gcc/fortran/symbol.c:2934
#3 0xa20eed in gfc_get_sym_tree(char const*, gfc_namespace*, gfc_symtree**,
bool) ../../gcc-150221/gcc/fortran/symbol.c:3384
#4 0xa21e11 in gfc_get_ha_sym_tree(char const*, gfc_symtree**)
../../gcc-150221/gcc/fortran/symbol.c:3469
#5 0x846df0 in gfc_match_rvalue(gfc_expr**)
../../gcc-150221/gcc/fortran/primary.c:3512
#6 0x7191c4 in match_primary ../../gcc-150221/gcc/fortran/matchexp.c:157
#7 0x7194a7 in match_level_1 ../../gcc-150221/gcc/fortran/matchexp.c:211
#8 0x719832 in match_mult_operand
../../gcc-150221/gcc/fortran/matchexp.c:267
#9 0x71a031 in match_add_operand
../../gcc-150221/gcc/fortran/matchexp.c:356
#10 0x71a9bd in match_level_2 ../../gcc-150221/gcc/fortran/matchexp.c:480
#11 0x71af3e in match_level_3 ../../gcc-150221/gcc/fortran/matchexp.c:551
#12 0x71b368 in match_level_4 ../../gcc-150221/gcc/fortran/matchexp.c:599
#13 0x71c2f7 in match_and_operand
../../gcc-150221/gcc/fortran/matchexp.c:693
#14 0x71c5b1 in match_or_operand
../../gcc-150221/gcc

[Bug fortran/79524] [8/9/10/11 Regression] valgrind error for gcc/testsuite/gfortran.dg/fimplicit_none_2.f90

[zeccav at gmail dot com via Gcc-bugs]

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

Vittorio Zecca  changed:

   What|Removed |Added

 CC||zeccav at gmail dot com

--- Comment #9 from Vittorio Zecca  ---
On sanitized current trunk, note I have line numbers.

~/local/gcc-150221-sanitized/bin/gfortran
~/gcc-150221/gcc/testsuite/gfortran.dg/fimplicit_none_2.f90 -S 
/home/vitti/gcc-150221/gcc/testsuite/gfortran.dg/fimplicit_none_2.f90:5:34:

5 |character(*), parameter :: z(2) = [character(n) :: 'x', 'y'] ! {
dg-error "Scalar INTEGER expression expected" }
  |  1
Error: Cannot initialize parameter array at (1) with variable length elements
=
==130180==ERROR: AddressSanitizer: heap-use-after-free on address
0x60401628 at pc 0x008c1918 bp 0x7ffceba92260 sp 0x7ffceba92258
READ of size 8 at 0x60401628 thread T0
#0 0x8c1917 in gfc_resolve_expr(gfc_expr*)
../../gcc-150221/gcc/fortran/resolve.c:7079
#1 0x91d45b in resolve_charlen ../../gcc-150221/gcc/fortran/resolve.c:12436
#2 0x96f604 in resolve_types ../../gcc-150221/gcc/fortran/resolve.c:17294
#3 0x970adf in gfc_resolve(gfc_namespace*)
../../gcc-150221/gcc/fortran/resolve.c:17411
#4 0x81fc90 in resolve_all_program_units
../../gcc-150221/gcc/fortran/parse.c:6290
#5 0x82229f in gfc_parse_file() ../../gcc-150221/gcc/fortran/parse.c:6542
#6 0xa64b7c in gfc_be_parse_file
../../gcc-150221/gcc/fortran/f95-lang.c:212
#7 0x33fa43d in compile_file ../../gcc-150221/gcc/toplev.c:457
#8 0x34097a2 in do_compile ../../gcc-150221/gcc/toplev.c:2197
#9 0x340a39f in toplev::main(int, char**)
../../gcc-150221/gcc/toplev.c:2336
#10 0x7f24cb9 in main ../../gcc-150221/gcc/main.c:39
#11 0x152cd7c9a1e1 in __libc_start_main (/usr/lib64/libc.so.6+0x281e1)
#12 0x41958d in _start
(/home/vitti/1TB/local/gcc-150221-sanitized/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/f951+0x41958d)

0x60401628 is located 24 bytes inside of 48-byte region
[0x60401610,0x60401640)
freed by thread T0 here:
#0 0x152cd8bec797 in __interceptor_free
../../../../gcc-150221/libsanitizer/asan/asan_malloc_linux.cpp:127
#1 0xa1cd6f in gfc_delete_symtree(gfc_symtree**, char const*)
../../gcc-150221/gcc/fortran/symbol.c:2964
#2 0xa25801 in gfc_restore_last_undo_checkpoint()
../../gcc-150221/gcc/fortran/symbol.c:3706
#3 0xa25a5f in gfc_undo_symbols()
../../gcc-150221/gcc/fortran/symbol.c:3739
#4 0x80175f in reject_statement ../../gcc-150221/gcc/fortran/parse.c:2678
#5 0x7f2bb0 in match_word ../../gcc-150221/gcc/fortran/parse.c:70
#6 0x7f445d in decode_statement ../../gcc-150221/gcc/fortran/parse.c:376
#7 0x7fd6c8 in next_free ../../gcc-150221/gcc/fortran/parse.c:1316
#8 0x7fe845 in next_statement ../../gcc-150221/gcc/fortran/parse.c:1548
#9 0x80bfe5 in parse_spec ../../gcc-150221/gcc/fortran/parse.c:3783
#10 0x81bef7 in parse_progunit ../../gcc-150221/gcc/fortran/parse.c:5896
#11 0x821732 in gfc_parse_file() ../../gcc-150221/gcc/fortran/parse.c:6437
#12 0xa64b7c in gfc_be_parse_file
../../gcc-150221/gcc/fortran/f95-lang.c:212
#13 0x33fa43d in compile_file ../../gcc-150221/gcc/toplev.c:457
#14 0x34097a2 in do_compile ../../gcc-150221/gcc/toplev.c:2197
#15 0x340a39f in toplev::main(int, char**)
../../gcc-150221/gcc/toplev.c:2336
#16 0x7f24cb9 in main ../../gcc-150221/gcc/main.c:39
#17 0x152cd7c9a1e1 in __libc_start_main (/usr/lib64/libc.so.6+0x281e1)

previously allocated by thread T0 here:
#0 0x152cd8becc47 in __interceptor_calloc
../../../../gcc-150221/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0x83c3e31 in xcalloc ../../gcc-150221/libiberty/xmalloc.c:162
#2 0xa1cade in gfc_new_symtree(gfc_symtree**, char const*)
../../gcc-150221/gcc/fortran/symbol.c:2934
#3 0xa20eed in gfc_get_sym_tree(char const*, gfc_namespace*, gfc_symtree**,
bool) ../../gcc-150221/gcc/fortran/symbol.c:3384
#4 0xa21e11 in gfc_get_ha_sym_tree(char const*, gfc_symtree**)
../../gcc-150221/gcc/fortran/symbol.c:3469
#5 0x846df0 in gfc_match_rvalue(gfc_expr**)
../../gcc-150221/gcc/fortran/primary.c:3512
#6 0x7191c4 in match_primary ../../gcc-150221/gcc/fortran/matchexp.c:157
#7 0x7194a7 in match_level_1 ../../gcc-150221/gcc/fortran/matchexp.c:211
#8 0x719832 in match_mult_operand
../../gcc-150221/gcc/fortran/matchexp.c:267
#9 0x71a031 in match_add_operand
../../gcc-150221/gcc/fortran/matchexp.c:356
#10 0x71a9bd in match_level_2 ../../gcc-150221/gcc/fortran/matchexp.c:480
#11 0x71af3e in match_level_3 ../../gcc-150221/gcc/fortran/matchexp.c:551
#12 0x71b368 in match_level_4 ../../gcc-150221/gcc/fortran/matchexp.c:599
#13 0x71c2f7 in match_and_operand
../../gcc-150221/gcc/fortran/matchexp.c:693
#14 0x71c5b1

[Bug d/99337] Sanitizer detect heap-buffer-overflow in checkModFileAlias

[zeccav at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Vittorio Zecca  ---
(In reply to Iain Buclaw from comment #3)
> Fix is trivial
> 
> --- a/gcc/d/dmd/dmodule.c
> +++ b/gcc/d/dmd/dmodule.c
> @@ -195,7 +195,7 @@ static void checkModFileAlias(OutBuffer *buf, OutBuffer
> *dotmods,
>  const char *m = (*ms)[j];
>  const char *q = strchr(m, '=');
>  assert(q);
> -if (dotmods->length() <= (size_t)(q - m) &&
> memcmp(dotmods->peekChars(), m, q - m) == 0)
> +if (dotmods->length() == (size_t)(q - m) &&
> memcmp(dotmods->peekChars(), m, q - m) == 0)
>  {
>  buf->reset();
>  size_t qlen = strlen(q + 1);

After applying the suggested fix

make check-gcc-d

runs without address sanitizer errors.

[Bug fortran/52622] heap-use-after-free with instrumented compiler

[zeccav at gmail dot com via Gcc-bugs]

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

Vittorio Zecca  changed:

   What|Removed |Added

 CC||zeccav at gmail dot com

--- Comment #16 from Vittorio Zecca  ---
On my sanitized gfortran, trunk version, I do not see sanitizer errors.
Maybe must be compiled with some special options?

By the way the delta-reduced-testcase contains syntax errors that I had to fix.

[Bug d/99337] Sanitizer detect heap-buffer-overflow in checkModFileAlias

[zeccav at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Vittorio Zecca  ---
This issue was found with the address sanitizer, while issues in bug
63426 were found with the undefined behavior sanitizer.

[Bug d/99337] New: Sanitizer detect heap-buffer-overflow in checkModFileAlias

[zeccav at gmail dot com via Gcc-bugs]

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

Bug ID: 99337
   Summary: Sanitizer detect heap-buffer-overflow in
checkModFileAlias
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

The address sanitizer detects the following running 
/home/vitti/gcc-150221-full-address/gcc/gdc
-B/home/vitti/gcc-150221-full-address/gcc compilable/test16798.d 
-I/home/vitti/gcc-150221/libphobos/libdruntime   
-fmodule-file=its.a.dessert.topping=imports/imp16798.d
-fmodule-file=its.a.floorwax=imports/ -S -o test16798.s

dmodule.c:200 is "if (memcmp(dotmods->peekChars(), m, q - m) == 0)"
I split the original if to understand which arm was causing the issue.

ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60210440 at pc
0x1483adc6651e bp 0x7fffd8642480 sp 0x7fffd8641c30
READ of size 21 at 0x60210440 thread T0
#0 0x1483adc6651d in MemcmpInterceptorCommon(void*, int (*)(void const*,
void const*, unsigned long), void const*, void const*, unsigned long)
../../../../gcc-150221/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:843
#1 0x1483adc66b78 in __interceptor_memcmp
../../../../gcc-150221/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:875
#2 0x1483adc66b78 in __interceptor_memcmp
../../../../gcc-150221/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:870
#3 0x539741 in checkModFileAlias ../../gcc-150221/gcc/d/dmd/dmodule.c:200
#4 0x539b45 in getFilename ../../gcc-150221/gcc/d/dmd/dmodule.c:241
#5 0x53a127 in Module::load(Loc, Array*, Identifier*)
../../gcc-150221/gcc/d/dmd/dmodule.c:348
#6 0x4e0c78 in Import::load(Scope*)
../../gcc-150221/gcc/d/dmd/dimport.c:154
#7 0x4e0ef5 in Import::importAll(Scope*)
../../gcc-150221/gcc/d/dmd/dimport.c:173
#8 0x4e1b95 in Import::setScope(Scope*)
../../gcc-150221/gcc/d/dmd/dimport.c:243
#9 0x42f975 in AttribDeclaration::setScope(Scope*)
../../gcc-150221/gcc/d/dmd/attrib.c:142
#10 0x4359de in ConditionalDeclaration::setScope(Scope*)
../../gcc-150221/gcc/d/dmd/attrib.c:864
#11 0x53d99b in Module::importAll(Scope*)
../../gcc-150221/gcc/d/dmd/dmodule.c:805
#12 0x4e0f9c in Import::importAll(Scope*)
../../gcc-150221/gcc/d/dmd/dimport.c:176
#13 0x53dabc in Module::importAll(Scope*)
../../gcc-150221/gcc/d/dmd/dmodule.c:811
#14 0x8f0c46 in d_parse_file ../../gcc-150221/gcc/d/d-lang.cc:1038
#15 0x1fed707 in compile_file ../../gcc-150221/gcc/toplev.c:457
#16 0x1ff69b9 in do_compile ../../gcc-150221/gcc/toplev.c:2197
#17 0x1ff721d in toplev::main(int, char**)
../../gcc-150221/gcc/toplev.c:2336
#18 0x4fba3ef in main ../../gcc-150221/gcc/main.c:39
#19 0x1483ad4dd1e1 in __libc_start_main (/usr/lib64/libc.so.6+0x281e1)
#20 0x419c8d in _start
(/home/vitti/gcc-150221-full-address/gcc/d21+0x419c8d)

0x60210440 is located 0 bytes to the right of 16-byte region
[0x60210430,0x60210440)
allocated by thread T0 here:
#0 0x1483adc85a8f in __interceptor_malloc
../../../../gcc-150221/libsanitizer/asan/asan_malloc_linux.cpp:145
#1 0x52231eb in xmalloc ../../gcc-150221/libiberty/xmalloc.c:147
#2 0x7cbb2a in Mem::xrealloc(void*, unsigned long)
../../gcc-150221/gcc/d/dmd/root/rmem.c:83
#3 0x78c726 in OutBuffer::reserve(unsigned long)
../../gcc-150221/gcc/d/dmd/root/outbuffer.c:30
#4 0x78ca2c in OutBuffer::write(void const*, unsigned long)
../../gcc-150221/gcc/d/dmd/root/outbuffer.c:59
#5 0x78cb15 in OutBuffer::writestring(char const*)
../../gcc-150221/gcc/d/dmd/root/outbuffer.c:66
#6 0x539662 in checkModFileAlias ../../gcc-150221/gcc/d/dmd/dmodule.c:192
#7 0x539b45 in getFilename ../../gcc-150221/gcc/d/dmd/dmodule.c:241
#8 0x53a127 in Module::load(Loc, Array*, Identifier*)
../../gcc-150221/gcc/d/dmd/dmodule.c:348
#9 0x4e0c78 in Import::load(Scope*)
../../gcc-150221/gcc/d/dmd/dimport.c:154
#10 0x4e0ef5 in Import::importAll(Scope*)
../../gcc-150221/gcc/d/dmd/dimport.c:173
#11 0x4e1b95 in Import::setScope(Scope*)
../../gcc-150221/gcc/d/dmd/dimport.c:243
#12 0x42f975 in AttribDeclaration::setScope(Scope*)
../../gcc-150221/gcc/d/dmd/attrib.c:142
#13 0x4359de in ConditionalDeclaration::setScope(Scope*)
../../gcc-150221/gcc/d/dmd/attrib.c:864
#14 0x53d99b in Module::importAll(Scope*)
../../gcc-150221/gcc/d/dmd/dmodule.c:805
#15 0x4e0f9c in Import::importAll(Scope*)
../../gcc-150221/gcc/d/dmd/dimport.c:176
#16 0x53dabc in Module::importAll(Scope*)
../../gcc-150221/gcc/d/dmd/dmodule.c:811
#17 0x8f0c46 in d_parse_file ../../gcc-150221/gcc/d/d-lang.cc:1038
#18 0x1fed707 in compile_file ../../gcc-150221/gcc/toplev.c:457
#19 0x1ff69b9 in do_compile ../../gcc-150221/gcc/toplev.c:2197
#20 0x1ff721d in toplev::m

[Bug fortran/50551] Argumentless NULL() cannot be used with assumed-length dummy (r178939)

[zeccav at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Vittorio Zecca  ---
Still in trunk.
The NAG nagfor and Intel ifort compilers detect the issue.

gfortran -S gfbug89.f

[vitti f95]$nagfor -S -w gfbug89.f
NAG Fortran Compiler Release 7.0(Yurakucho) Build 7042
Error: gfbug89.f, line 10: Argumentless NULL() cannot be used with
assumed-length dummy
[NAG Fortran Compiler error termination, 1 error]

[vitti f95]$ifort -S -w gfbug89.f
gfbug89.f(10): error #8613: Intrinsic NULL() must have the MOLD argument if it
is an actual argument corresponding to a dummy argument with assumed type
parameters.
  call sub(null())  ! null() cannot be used with assumed length dummy
argument
---^
compilation aborted for gfbug89.f (code 1)

[Bug target/81319] ICE in output_operand_lossage at final.c

[zeccav at gmail dot com via Gcc-bugs]

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

Vittorio Zecca  changed:

   What|Removed |Added

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

--- Comment #4 from Vittorio Zecca  ---
Fixed in 10.1.1-1.

[Bug fortran/80774] [8/9/10/11 Regression][Coarray] ICE in gfc_conv_descriptor_data_get, at fortran/trans-array.c

[zeccav at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Vittorio Zecca  ---
Still in current trunk.

gfortran -S gfbug132.f -fcoarray=single
gfbug132.f:18:72:

   18 |   deallocate(obj%link)
  |   
1
internal compiler error: in gfc_get_descriptor_field, at
fortran/trans-array.c:140
0x623c3e gfc_get_descriptor_field
../../gcc-150221/gcc/fortran/trans-array.c:140
0x90990a gfc_conv_descriptor_data_get(tree_node*)
../../gcc-150221/gcc/fortran/trans-array.c:159
0x9078a4 gfc_deallocate_with_status(tree_node*, tree_node*, tree_node*,
tree_node*, tree_node*, bool, gfc_expr*, int, tree_node*, tree_node*)
../../gcc-150221/gcc/fortran/trans.c:1433
0x91bcad structure_alloc_comps
../../gcc-150221/gcc/fortran/trans-array.c:9031
0x91c93a gfc_deallocate_alloc_comp(gfc_symbol*, tree_node*, int, int)
../../gcc-150221/gcc/fortran/trans-array.c:9821
0x908132 gfc_deallocate_scalar_with_status(tree_node*, tree_node*, tree_node*,
bool, gfc_expr*, gfc_typespec, bool)
../../gcc-150221/gcc/fortran/trans.c:1652
0x992c69 gfc_trans_deallocate(gfc_code*)
../../gcc-150221/gcc/fortran/trans-stmt.c:7379
0x9042a7 trans_code
../../gcc-150221/gcc/fortran/trans.c:2098
0x932f53 gfc_generate_function_code(gfc_namespace*)
../../gcc-150221/gcc/fortran/trans-decl.c:6880
0x8afaae translate_all_program_units
../../gcc-150221/gcc/fortran/parse.c:6351
0x8afaae gfc_parse_file()
../../gcc-150221/gcc/fortran/parse.c:6620
0x9010ef gfc_be_parse_file
../../gcc-150221/gcc/fortran/f95-lang.c:212
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug rtl-optimization/85789] Signed integer overflow with nonzero optimization in cse.c

[zeccav at gmail dot com via Gcc-bugs]

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

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

~/local/gcc-150221-undefined/bin/gcc -S gccerr67.c -O
../../gcc-150221/gcc/cse.c:2204:34: runtime error: signed integer overflow: 1 -
-9223372036854775807 cannot be represented in type 'long int'

[Bug fortran/50541] gfortran should not accept a pointer as a generic-name (r178939)

[zeccav at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Vittorio Zecca  ---
The NAG nagfor and Intel ifort detect the issue.

gfortran -S gfbug81.f

[vitti f95]$nagfor -S gfbug81.f
NAG Fortran Compiler Release 7.0(Yurakucho) Build 7042
Error: gfbug81.f, line 4: Multiply defined symbol S
   detected at INTERFACE@S
Warning: gfbug81.f, line 10: Unused local variable S

[NAG Fortran Compiler pass 1 error termination, 1 error, 1 warning]
[vitti f95]$ifort -S gfbug81.f
gfbug81.f(3): error #6449: This name has already been used as a generic
procedure name   [S]
  pointer s! gfortran should complain here
--^
compilation aborted for gfbug81.f (code 1)

[Bug fortran/58224] -fcheck=pointer should detect that an unallocated allocatable data-target is forbidden

[zeccav at gmail dot com via Gcc-bugs]

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

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

The NAG nagfor compiler detects the issue at compile time.

nagfor gfbug103.f 
NAG Fortran Compiler Release 7.0(Yurakucho) Build 7042
Warning: gfbug103.f, line 8: Pointer Q never dereferenced
Error: gfbug103.f, line 8: ALLOCATABLE variable QQ used but never ALLOCATEd
[NAG Fortran Compiler pass 1 error termination, 1 error, 1 warning]

[Bug middle-end/82083] sanitizer detects signed integer overflow in tree-data-ref.c with -O3

[zeccav at gmail dot com via Gcc-bugs]

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

Vittorio Zecca  changed:

   What|Removed |Added

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

--- Comment #6 from Vittorio Zecca  ---
Fixed in version 10.

[Bug fortran/50525] gfortran should not allow early reference to entry dummy argument (r178939)

[zeccav at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Vittorio Zecca  ---
Still in trunk.

The NAG nagfor and Intel ifort compilers detect the issue.

ifort -S -w gfbug72.f
gfbug72.f(4): error #6482: An ENTRY dummy argument is referenced in an
executable statement before it appears in any ENTRY statement.   [X]
  f(y)=x ! this is wrong
---^
compilation aborted for gfbug72.f (code 1)

[vitti f95]$nagfor -S -w gfbug72.f
NAG Fortran Compiler Release 7.0(Yurakucho) Build 7042
Error: gfbug72.f, line 4: Dummy arg X used before first occurrence in an
argument list
[NAG Fortran Compiler error termination, 1 error]

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

[zeccav at gmail dot com via Gcc-bugs]

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

Vittorio Zecca  changed:

   What|Removed |Added

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

--- Comment #8 from Vittorio Zecca  ---
Fixed in current trunk.

[Bug other/63426] [meta-bug] Issues found with -fsanitize=undefined

[zeccav at gmail dot com via Gcc-bugs]

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

Bug 62058 Summary: Undefined behaviour in tree-data-ref.c with options -O1 
-ftree-loop-vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62058

   What|Removed |Added

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

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

[zeccav at gmail dot com via Gcc-bugs]

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

Vittorio Zecca  changed:

   What|Removed |Added

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

--- Comment #7 from Vittorio Zecca  ---
Fixed in current runk.

[Bug libfortran/81986] sanitizer detects negation of large number in string.c

[zeccav at gmail dot com via Gcc-bugs]

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

Vittorio Zecca  changed:

   What|Removed |Added

  Component|sanitizer   |libfortran

--- Comment #4 from Vittorio Zecca  ---
On current trunk with sanitized libgfortran.so.5 I get

gfortran gfbug142.f
ldd ./a.out

libgfortran.so.5 =>
/home/vitti/gcc-150221-undefined/x86_64-pc-linux-gnu/libgfortran/.libs/libgfortran.so.5
(0x14a739133000)
libubsan.so.1 =>
/home/vitti/local/gcc-150221-undefined/lib/../lib64/libubsan.so.1
(0x14a738293000)
libstdc++.so.6 =>
/home/vitti/local/gcc-150221-undefined/lib/../lib64/libstdc++.so.6


./a.out
../../../gcc-150221/libgfortran/io/write.c:835:7: runtime error: negation of
0x8000 cannot be represented in type '__int128';
cast to an unsigned type to negate this value to itself
../../../gcc-150221/libgfortran/runtime/string.c:199:11: runtime error:
negation of 0x8000 cannot be represented in type
'__int128'; cast to an unsigned type to negate this value to itself
8000

[Bug fortran/50402] ICE in gfc_conv_expr_descriptor

[zeccav at gmail dot com via Gcc-bugs]

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

--- Comment #9 from Vittorio Zecca  ---
Still in current trunk.

The compilers NAG nagfor and Intel ifort correctly detect a syntax error.

nagfor -S -w gfbug43.f
NAG Fortran Compiler Release 7.0(Yurakucho) Build 7042
Error: gfbug43.f, line 12: Scalar value for array pointer component P of type T
[NAG Fortran Compiler error termination, 1 error]

[vitti f95]$ifort -S -w gfbug43.f
gfbug43.f(12): error #6594: The rank of a component in a structure constructor
differs from the rank of the component of the derived type.   [F]
  u=t(f())
--^
compilation aborted for gfbug43.f (code 1)

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

[zeccav at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Vittorio Zecca  ---
Still present in current trunk.

The compilers NAG nagfor and Intel ifort detect the issue.

nagfor -S -w gfbug78.f
NAG Fortran Compiler Release 7.0(Yurakucho) Build 7042
Error: gfbug78.f, line 4: Dummy argument SUB has the same name as the
subprogram
   detected at (@SUB
[NAG Fortran Compiler pass 1 error termination, 1 error]
[vitti f95]$ifort -S -w gfbug78.f
gfbug78.f(4): error #6406: Conflicting attributes or multiple declaration of
name.   [SUB]
  entry e(sub)
--^
compilation aborted for gfbug78.f (code 1)

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

[zeccav at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Vittorio Zecca  ---
Still present in version 11.

The compilers NAG nagfor and Intel ifort detect the issue.

ifort -S -w gfbug82.f -warn stderrors
gfbug82.f(9): error #8252: A DATA implied-DO variable must be an array element
or scalar structure component that has at least one subscript list.
  data (u%g,j=1,1) /1/! violates R536: data-i-do-object cannot be a scalar
^
gfbug82.f(10): error #8252: A DATA implied-DO variable must be an array element
or scalar structure component that has at least one subscript list.
  data (ii,j=1,1) /1/ ! ditto
^
compilation aborted for gfbug82.f (code 1)
[vitti f95]$nagfor -S -w gfbug82.f
NAG Fortran Compiler Release 7.0(Yurakucho) Build 7042
Error: gfbug82.f, line 10: Syntax error
   detected at II@,
[NAG Fortran Compiler pass 1 error termination, 1 error]

[Bug fortran/50536] an input item shall not appear as the do-variable of any io-implied-do

[zeccav at gmail dot com via Gcc-bugs]

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

--- Comment #9 from Vittorio Zecca  ---
Still present in version 11.

Detected by NAG nagfor and Intel ifort.

[vitti f95]$nagfor -S -w gfbug74.f
NAG Fortran Compiler Release 7.0(Yurakucho) Build 7042
Error: gfbug74.f, line 4: Input item L cannot also be an I/O implied DO
variable
[NAG Fortran Compiler error termination, 1 error]
[vitti f95]$ifort -S -w gfbug74.f
gfbug74.f(4): error #8251: An input item must not appear as the implied-DO
variable of any implied-DO loop that contains the input item.   [L]
  read *,(l,l=1,2) 
--^
compilation aborted for gfbug74.f (code 1)

[Bug libgcc/67379] libgcc2.c negation of -2147483648 cannot be represented in type 'int'

[zeccav at gmail dot com via Gcc-bugs]

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

Vittorio Zecca  changed:

   What|Removed |Added

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

--- Comment #3 from Vittorio Zecca  ---
Fixed in bug 99236.

[Bug fortran/50377] gfortran must not accept an external formal argument not declared external

[zeccav at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Vittorio Zecca  ---
Still present at version 11.
The Intel ifort and NAG nagfor compilers decet the issue.

nagfor -S gfbug158.f -w
NAG Fortran Compiler Release 7.0(Yurakucho) Build 7042
Error: gfbug158.f, line 3: External procedure SUB used as actual argument but
does not have the EXTERNAL attribute
[NAG Fortran Compiler error termination, 1 error]

[vitti f95]$ifort -S gfbug158.f
gfbug158.f(3): error #7898: If an external or dummy procedure name is used as
an actual argument, its interface shall be explicit or it shall be explicitly 
declared to have the EXTERNAL attribute.   [SUB]
  call sub(sub)
---^
compilation aborted for gfbug158.f (code 1)

[Bug fortran/50535] transformational intrinsic functions not allowed in statement functions

[zeccav at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Vittorio Zecca  ---
Still in version 11.
Both Intel ifort and NAG nagfor detect the issue.

ifort -S gfbug73.f -w
gfbug73.f(5): error #6736: This transformational intrinsic function is invalid
in this context; statement functions cannot contain transformational intrinsic
functions.   [ALL]
  g(x)=all(l)
---^
compilation aborted for gfbug73.f (code 1)
[vitti f95]$nagfor -S gfbug73.f -w
NAG Fortran Compiler Release 7.0(Yurakucho) Build 7042
Error: gfbug73.f, line 5: Reference to transformational intrinsic ALL in
statement function
[NAG Fortran Compiler error termination, 1 error]

[Bug testsuite/44798] inconsistent interfaces

[zeccav at gmail dot com via Gcc-bugs]

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

Vittorio Zecca  changed:

   What|Removed |Added

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

--- Comment #4 from Vittorio Zecca  ---
This issue has been resolved by adjusting the array bounds.

[Bug fortran/50549] should detect different type parameters in structure constructors (r178939)

[zeccav at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Vittorio Zecca  ---
Still present on version 11.
NAG nagfor compiler detecs it.
nagfor -S gfbug87.f -w
NAG Fortran Compiler Release 7.0(Yurakucho) Build 7042
Error: gfbug87.f, line 13: Wrong character length (1 instead of 2) for pointer
component P2 in constructor for type T
Error: gfbug87.f, line 14: Wrong character length (1 instead of 2) for pointer
component P2 in constructor for type T
[NAG Fortran Compiler error termination, 2 errors]

[Bug testsuite/44922] undefined variable in execute/921202-1.c

[zeccav at gmail dot com via Gcc-bugs]

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

Vittorio Zecca  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #2 from Vittorio Zecca  ---
This issue is a corner case and will never be resolved.
So I am closing it.

[Bug fortran/99255] ICE in gfc_dt_upper_string, at fortran/module.c:441

[zeccav at gmail dot com via Gcc-bugs]

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

Vittorio Zecca  changed:

   What|Removed |Added

 CC||zeccav at gmail dot com

--- Comment #1 from Vittorio Zecca  ---
A sanitized version of the compiler fails earlier at class.c line 487
"if (derived->attr.unlimited_polymorphic)"

~/local/gcc-150221-sanitized/bin/gfortran -S z1.f90
=
==8457==ERROR: AddressSanitizer: heap-use-after-free on address 0x6040172d
at pc 0x00496c01 bp 0x7fffca9abcd0 sp 0x7fffca9abcc8
READ of size 1 at 0x6040172d thread T0
#0 0x496c00 in get_unique_type_string
../../gcc-150221/gcc/fortran/class.c:487
#1 0x4972c9 in get_unique_hashed_string
../../gcc-150221/gcc/fortran/class.c:524
#2 0x498610 in gfc_build_class_symbol(gfc_typespec*, symbol_attribute*,
gfc_array_spec**) ../../gcc-150221/gcc/fortran/class.c:672
#3 0x709d96 in copy_ts_from_selector_to_associate
../../gcc-150221/gcc/fortran/match.c:6237
#4 0x70dc8a in gfc_match_select_type()
../../gcc-150221/gcc/fortran/match.c:6431
#5 0x7f2b01 in match_word ../../gcc-150221/gcc/fortran/parse.c:65
#6 0x7f4b32 in decode_statement ../../gcc-150221/gcc/fortran/parse.c:428
#7 0x7fd6c8 in next_free ../../gcc-150221/gcc/fortran/parse.c:1316
#8 0x7fe845 in next_statement ../../gcc-150221/gcc/fortran/parse.c:1548
#9 0x80cb86 in parse_spec ../../gcc-150221/gcc/fortran/parse.c:3967
#10 0x81bef7 in parse_progunit ../../gcc-150221/gcc/fortran/parse.c:5896
#11 0x821732 in gfc_parse_file() ../../gcc-150221/gcc/fortran/parse.c:6437
#12 0xa64b7c in gfc_be_parse_file
../../gcc-150221/gcc/fortran/f95-lang.c:212
#13 0x33fa43d in compile_file ../../gcc-150221/gcc/toplev.c:457
#14 0x34097a2 in do_compile ../../gcc-150221/gcc/toplev.c:2197
#15 0x340a39f in toplev::main(int, char**)
../../gcc-150221/gcc/toplev.c:2336
#16 0x7f24cb9 in main ../../gcc-150221/gcc/main.c:39
#17 0x15054552b1e1 in __libc_start_main (/usr/lib64/libc.so.6+0x281e1)
#18 0x41958d in _start
(/home/vitti/1TB/local/gcc-150221-sanitized/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/f951+0x41958d)

0x6040172d is located 29 bytes inside of 48-byte region
[0x60401710,0x60401740)
freed by thread T0 here:
#0 0x15054647d797 in __interceptor_free
../../../../gcc-150221/libsanitizer/asan/asan_malloc_linux.cpp:127
#1 0xa1cd6f in gfc_delete_symtree(gfc_symtree**, char const*)
../../gcc-150221/gcc/fortran/symbol.c:2964
#2 0xa25801 in gfc_restore_last_undo_checkpoint()
../../gcc-150221/gcc/fortran/symbol.c:3706
#3 0xa25a5f in gfc_undo_symbols()
../../gcc-150221/gcc/fortran/symbol.c:3739
#4 0x80175f in reject_statement ../../gcc-150221/gcc/fortran/parse.c:2678
#5 0x7f2bb0 in match_word ../../gcc-150221/gcc/fortran/parse.c:70
#6 0x7f42d9 in decode_statement ../../gcc-150221/gcc/fortran/parse.c:361
#7 0x7fd6c8 in next_free ../../gcc-150221/gcc/fortran/parse.c:1316
#8 0x7fe845 in next_statement ../../gcc-150221/gcc/fortran/parse.c:1548
#9 0x8088f0 in parse_derived ../../gcc-150221/gcc/fortran/parse.c:3387
#10 0x80c81b in parse_spec ../../gcc-150221/gcc/fortran/parse.c:3928
#11 0x81bef7 in parse_progunit ../../gcc-150221/gcc/fortran/parse.c:5896
#12 0x821732 in gfc_parse_file() ../../gcc-150221/gcc/fortran/parse.c:6437
#13 0xa64b7c in gfc_be_parse_file
../../gcc-150221/gcc/fortran/f95-lang.c:212
#14 0x33fa43d in compile_file ../../gcc-150221/gcc/toplev.c:457
#15 0x34097a2 in do_compile ../../gcc-150221/gcc/toplev.c:2197
#16 0x340a39f in toplev::main(int, char**)
../../gcc-150221/gcc/toplev.c:2336
#17 0x7f24cb9 in main ../../gcc-150221/gcc/main.c:39
#18 0x15054552b1e1 in __libc_start_main (/usr/lib64/libc.so.6+0x281e1)

previously allocated by thread T0 here:
#0 0x15054647dc47 in __interceptor_calloc
../../../../gcc-150221/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0x83c3e31 in xcalloc ../../gcc-150221/libiberty/xmalloc.c:162
#2 0xa1cade in gfc_new_symtree(gfc_symtree**, char const*)
../../gcc-150221/gcc/fortran/symbol.c:2934
#3 0xa20eed in gfc_get_sym_tree(char const*, gfc_namespace*, gfc_symtree**,
bool) ../../gcc-150221/gcc/fortran/symbol.c:3384
#4 0xa21e11 in gfc_get_ha_sym_tree(char const*, gfc_symtree**)
../../gcc-150221/gcc/fortran/symbol.c:3469
#5 0x6df4b3 in gfc_match_sym_tree(gfc_symtree**, int)
../../gcc-150221/gcc/fortran/match.c:706
#6 0x84d6f7 in match_variable ../../gcc-150221/gcc/fortran/primary.c:4024
#7 0x84f424 in gfc_match_variable(gfc_expr**, int)
../../gcc-150221/gcc/fortran/primary.c:4168
#8 0x6e1a00 in gfc_match(char const*, ...)
../../gcc-150221/gcc/fortran/match.c:1162
#9 0x6e2894 in gfc_match_assignment()
../../gcc-150221/gcc/fortran/match.c:1340
#10 0x7f2b01 in match_word ../../gcc-15022

[Bug libgcc/99236] Undefined behaviour in libgcc

[zeccav at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Vittorio Zecca  ---
After patching libgcc2.c the test case runs fine without sanitizer messages.

[Bug libgcc/99236] New: Undefined behaviour in libgcc

[zeccav at gmail dot com via Gcc-bugs]

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

Bug ID: 99236
   Summary: Undefined behaviour in libgcc
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

! must be compiled and run
! It does not need sanitized compiler, but
! must be loaded with sanitized version of libgcc_s.so.1
! ldd a.out -> libgcc_s.so.1 =>
/home/vitti/local/gcc-150221-undefined/lib64/libgcc_s.so.1
!../../../gcc-150221/libgcc/libgcc2.c:1837:31: runtime error: negation of
-2147483648 cannot be represented in type 'int'; cast to an unsigned type to
negate this value to itself
! libgcc2.c:1837 -> "unsigned int n = m < 0 ? -m : m;"
  a = 3.0
  b = a**(-2147483647_4-1_4)
  end

[Bug sanitizer/99190] Undefined behaviour in libubsan

[zeccav at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Vittorio Zecca  ---
I can confirm the new libubsan works on my test case.

Keep up the good work!

[Bug libquadmath/99202] Undefined behaviour in libquadmath file rem_pio2q.c function __quadmath_rem_pio2q

[zeccav at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Vittorio Zecca  ---
I believe you need LD_PRELOAD if the object program uses the address sanitizer.

[Bug testsuite/44792] data.f90 accesses undefined variable

[zeccav at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Vittorio Zecca  ---
Still unmodified, I cannot see the modification of Tobias Burnus.
NAG nagfor compiler stll produces run time error message.

Runtime Error: gcc/testsuite/gfortran.fortran-torture/execute/data.f90, line
28: Reference to undefined variable TMP2(1)%T1(1)%A

[Bug sanitizer/99190] Undefined behaviour in libubsan

[zeccav at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Vittorio Zecca  ---
Sorry I meant libubsan, but I am building the whole gcc, g++, and gfortran
sanitized version.

[Bug libquadmath/99203] New: Undefined behaviour in libquadmath file print_fp.c function __quadmath_printf_fp

[zeccav at gmail dot com via Gcc-bugs]

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

Bug ID: 99203
   Summary: Undefined behaviour in libquadmath file print_fp.c
function __quadmath_printf_fp
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libquadmath
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

! from fmt_en.f90
! must be compiled and run
! gfortran compiler needs not be sanitized
! must load sanitized libquadmath.so.0
! ldd a.out -> libquadmath.so.0 =>
/home/vitti/local/gcc-150221-undefined/lib64/libquadmath.so.0
!../../../gcc-150221/libquadmath/printf/printf_fp.c:762:4: runtime error:
passing zero to ctz(), which is not a valid argument
!../../../gcc-150221/libquadmath/printf/printf_fp.c:762: runtime error: passing
zero to ctz(), which is not a valid argument
! printf_fp.c:762 -> "count_trailing_zeros (cnt_l, tmp[0]);"

  write(*, "(en15.2)") real(-.4,kind=10)
  write(*, "(en15.2)") real(-.4,kind=16)

  end

[Bug libquadmath/99202] New: Undefined behaviour in libquadmath file rem_pio2q.c function __quadmath_rem_pio2q

[zeccav at gmail dot com via Gcc-bugs]

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

Bug ID: 99202
   Summary: Undefined behaviour in libquadmath file rem_pio2q.c
function __quadmath_rem_pio2q
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libquadmath
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

! from dec_math.f90 
! must be compiled and run
! gfortran compiler needs not be sanitized
! must load sanitized libquadmath.so.0 as in ldd a.out -> libquadmath.so.0 =>
/home/vitti/local/gcc-150221-undefined/lib64/libquadmath.so.0
! ../../../gcc-150221/libquadmath/math/rem_pio2q.c:562:26: runtime error: left
shift of 4612846647631955497 by 23 places cannot be represented in type 'long
int'
! rem_pio2q.c:562 -> "tx [2] = (double)(((ix << 23) | (lx >> 41)) & 0xff);"
  real(16) :: q_i1,  q_oa

  q_i1 = 34.3774677078493908766176900826395_16

  q_oa = cotan (q_i1)

  end

[Bug sanitizer/99190] Undefined behaviour in libubsan

[zeccav at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Vittorio Zecca  ---
To generate a sanitized version of libgfortran I built whole sanitized
gcc with the following command:

CFLAGS="-g -O0 -fsanitize=undefined -lubsan" LIBS="-lubsan"
CXXFLAGS=$CFLAGS ../gcc-150221/configure
--prefix=/home/vitti/local/gcc-150221-undefined
--enable-languages=c,c++,fortran --disable-multilib --disable-lto
--disable-plugin
--disable-bootstrap

But I remember I had to tweak the build here and there.
It is not trivial.

[Bug libfortran/99191] New: sanitizer detects undefined behaviour in libgfortran

[zeccav at gmail dot com via Gcc-bugs]

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

Bug ID: 99191
   Summary: sanitizer detects undefined behaviour in libgfortran
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

! from pr66311.f90
! must be compiled and run with sanitized libgfortran
!../../../gcc-150221/libgfortran/io/write.c:835:7: runtime error: negation of
0x8000 cannot be represented in type '__int128';
cast to an unsigned type to negate this value to itself
!../../../gcc-150221/libgfortran/runtime/string.c:199:11: runtime error:
negation of 0x8000 cannot be represented in type
'__int128'; cast to an unsigned type to negate this value to itself
  use iso_fortran_env, only : ikinds => integer_kinds

  integer, parameter :: k = ikinds(size(ikinds))

  write(*,*) -huge(0_k)-1

  end

[Bug sanitizer/99190] New: Undefined behaviour in libubsan

[zeccav at gmail dot com via Gcc-bugs]

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

Bug ID: 99190
   Summary: Undefined behaviour in libubsan
   Product: gcc
   Version: 11.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: ---

// gcc -fsanitize=shift -w
// ldd a.out produces
// libubsan.so.1 => /home/vitti/local/gcc-150221-undefined/lib64/libubsan.so.1
// ./a.out produces
// ../../../../gcc-150221/libsanitizer/ubsan/ubsan_value.cpp:77:25: runtime
error: left shift of 0xfffb by 96 places cannot be
represented in type '__int128'
// ubsan_value.cpp:77 -> "return SIntMax(Val) << ExtraBits >> ExtraBits;"
int main (void)
{

  1 << -5;

  return 0;
}

[Bug libobjc/67516] class.c left shift of 1271241028 by 4 places cannot be represented in type 'int'

[zeccav at gmail dot com via Gcc-bugs]

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

Vittorio Zecca  changed:

   What|Removed |Added

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

--- Comment #2 from Vittorio Zecca  ---
Resolved.

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

[zeccav at gmail dot com via Gcc-bugs]

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

Vittorio Zecca  changed:

   What|Removed |Added

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

--- Comment #7 from Vittorio Zecca  ---
Resolved.

[Bug middle-end/61158] negative shift at fold-const.c:12095

[zeccav at gmail dot com via Gcc-bugs]

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

Vittorio Zecca  changed:

   What|Removed |Added

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

--- Comment #10 from Vittorio Zecca  ---
Resolved.

[Bug fortran/59065] questionable bounds for unassociated allocatable/pointer arrays?

[zeccav at gmail dot com via Gcc-bugs]

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

--- Comment #10 from Vittorio Zecca  ---
This issue seems to have been resolved in the trunk gfortran 11.0.0

gfortran gfbug109.f  -fcheck=pointer -g 
[vitti f95]$./a.out 
At line 9 of file gfbug109.f
Fortran runtime error: Allocatable argument 'aa' is not allocated

Error termination. Backtrace:
#0  0x1458cf822d74 in ???
#1  0x1458cf823849 in ???
#2  0x1458cf823e5a in ???
#3  0x401b94 in MAIN__
at /home/vitti/f95/gfbug109.f:9
#4  0x401eb1 in main
at /home/vitti/f95/gfbug109.f:11

[Bug libfortran/99148] sanitizer detects stack-buffer-overflow in unpack_generic.c

[zeccav at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Vittorio Zecca  ---
Reproduction of this issue requires an address sanitized version of
libgfortran.

I narrowed the issue to unpack0_char changing
{
  gfc_array_char tmp;

  if (unlikely(compile_options.bounds_check))
unpack_bounds (ret, vector, mask, NULL);

  memset (&tmp, 0, sizeof (tmp));
  GFC_DTYPE_CLEAR(&tmp);
  tmp.base_addr = field;
  unpack_internal (ret, vector, mask, &tmp, vector_length);

into 

{
  gfc_array_char tmp;

  if (unlikely(compile_options.bounds_check))
unpack_bounds (ret, vector, mask, NULL);

printf("sizeof(tmp)=%ld\n",sizeof(tmp));//vz
  memset (&tmp, 0, sizeof (tmp));
  GFC_DTYPE_CLEAR(&tmp);
  tmp.base_addr = field;
  int nvz=(&tmp)->dim[0]._stride;
  unpack_internal (ret, vector, mask, &tmp, vector_length);

I found sizeof(tmp)==40

and an address sanitizer error at the "int nvz" definition
This is the execution output:

LD_PRELOAD=~/libasan.so ./a.out
sizeof(tmp)=40
=
==44953==ERROR: AddressSanitizer: stack-buffer-overflow on address
0x7ffe78341c78 at pc 0x15270f525567 bp 0x7ffe78341bd0 sp 0x7ffe78341bc8
READ of size 8 at 0x7ffe78341c78 thread T0
#0 0x15270f525566 in _gfortran_unpack0_char
../../../gcc-150221/libgfortran/intrinsics/unpack_generic.c:630
#1 0x40139f in MAIN__ /home/vitti/f95/gfbug153.f:15
#2 0x40146d in main /home/vitti/f95/gfbug153.f:16
#3 0x15270eaa71e1 in __libc_start_main (/usr/lib64/libc.so.6+0x281e1)
#4 0x4010ad in _start (/home/vitti/1TB/f95/a.out+0x4010ad)

Address 0x7ffe78341c78 is located in stack of thread T0 at offset 88 in frame
#0 0x15270f5252a2 in _gfortran_unpack0_char
../../../gcc-150221/libgfortran/intrinsics/unpack_generic.c:620

  This frame has 1 object(s):
[48, 88) 'tmp' (line 621) <== Memory access at offset 88 overflows this
variable


I do not know if it is a false positive or a genuine bug.
But I hope this helps if you cannot generate a sanitized version of
libgfortran.

[Bug fortran/99145] gfortran LOOP

[zeccav at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Vittorio Zecca  ---
(In reply to Jerry DeLisle from comment #3)
> Initially it is creating the very large string in the frontend passes and
> then via resolution and translation phases, and finally into the middle-end
> and back end phases where it I am guessing the optimizers are realizing the
> simplifications.
> 
> It is a known that some of these special cases are not recognized in the
> front end and immediately reduced.  In this case it is creating a literal
> constant that big. Normally a program would be attempting to use the
> parameter in more than one place in which case it is literally substituted
> in.
> 
> Should we mark this as invalid?

Yes, please.

[Bug fortran/99147] Sanitizer detects heap-use-after-free in gfc_add_flavor

[zeccav at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Vittorio Zecca  ---
I ran the testsuite against the proposed fix and it was successful, no
sanitizer errors in symbol.c.

Only remaining error as in bug 99148.

[Bug fortran/99147] Sanitizer detects heap-use-after-free in gfc_add_flavor

[zeccav at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Vittorio Zecca  ---
I changed symbol.c as per your suggestion and now the address
sanitized gfortran compiles fine.
Now I am going to check it against the testsuite.
Results tomorow.

[Bug fortran/99145] gfortran LOOP

[zeccav at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Vittorio Zecca  ---
I am sorry I should have taken more time analyzing this issue.
Actually it is not and infinite loop, I clocked the compilation first
with the -S option,
then with the -c option.
The compiler takes 4'52" of real time, 2'47" user time, and 43" of sys time.
Same timings for -S and -c.
The workstation was dedicated, with 16GB RAM.
The output .s file is 1012 bytes, .o file 1776 bytes.

I do not understand how gfortran takes such a long time only to
produce a small object file.

Sorry again for having cried wolf.

[Bug libfortran/99148] New: sanitizer detects stack-buffer-overflow in unpack_generic.c

[zeccav at gmail dot com via Gcc-bugs]

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

Bug ID: 99148
   Summary: sanitizer detects stack-buffer-overflow in
unpack_generic.c
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

! from char_length_8.f90 
! address sanitizer detects stack-buffer-overflow in libgfortran 
! Must compile libgfortran with -fsanitize=address and link it 
! must appear in ldd a.out as in
! libgfortran.so.5 =>
/home/vitti/local/gcc-150221-address/lib64/libgfortran.so.5
(0x15384c11)
! compile with "gfortran p.f90 -g"
! execute with "LD_PRELOAD=/lib64/libasan.so.6 ./a.out"
!==32152==ERROR: AddressSanitizer: stack-buffer-overflow on address
0x7ffdd7a7e6a8 at pc 0x14916720908b bp 0x7ffdd7a7e210 sp 0x7ffdd7a7e208
!READ of size 8 at 0x7ffdd7a7e6a8 thread T0
!#0 0x14916720908a in unpack_internal
../../../gcc-150221/libgfortran/intrinsics/unpack_generic.c:122
! "fstride[n] = GFC_DESCRIPTOR_STRIDE_BYTES(field, n);"
  CHARACTER(LEN=3), DIMENSION(10) :: Z
  logical, dimension(5,2) :: mask
  Z(:)="hij"
  mask = .true.
  if (any (unpack(Z(:)(2:2),mask,' ') .ne. "i")) STOP 8
  END

[Bug fortran/99147] New: Sanitizer detects heap-use-after-free in gfc_add_flavor

[zeccav at gmail dot com via Gcc-bugs]

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

Bug ID: 99147
   Summary: Sanitizer detects heap-use-after-free in
gfc_add_flavor
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

! trunk 150221 gfortran -fdec
! ERROR: AddressSanitizer: heap-use-after-free
! READ of size 1 at 0x61301f18 thread T0
!#0 0xe1a258 in gfc_add_flavor(symbol_attribute*, sym_flavor, char const*,
locus*) ../../gcc/gcc/fortran/symbol.c:1775
! symbol.c:1775 "if (gfc_new_block && gfc_new_block->abr_modproc_decl"
  TYPE :: t
  END TYPE
  END

[Bug fortran/99146] New: ICE in gfc_find_specific_dtio_proc

[zeccav at gmail dot com via Gcc-bugs]

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

Bug ID: 99146
   Summary: ICE in gfc_find_specific_dtio_proc
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

! gfortran trunk 150221 ICE SIGSEGV 
  MODULE p
  TYPE :: person
  sequence
  END TYPE person
  INTERFACE READ(UNFORMATTED)
   MODULE PROCEDURE pruf
  END INTERFACE

  CONTAINS

  SUBROUTINE pruf (dtv,unit,iostat,iomsg)
   type(person), INTENT(INOUT) :: dtv
   INTEGER, INTENT(IN) :: unit
   INTEGER, INTENT(OUT) :: iostat
   CHARACTER (LEN=*), INTENT(INOUT) :: iomsg
  END SUBROUTINE pruf

  END MODULE p

  PROGRAM test
  USE p
  TYPE (person) :: chairman

  OPEN (UNIT=71, status = 'scratch', FORM='UNFORMATTED')

  read(71) chairman

  END PROGRAM test
!f951: internal compiler error: Segmentation fault
!0xe79f4f crash_signal
!   ../../gcc-150221/gcc/toplev.c:327
!0x85bb23 gfc_find_specific_dtio_proc(gfc_symbol*, bool, bool)
!   ../../gcc-150221/gcc/fortran/interface.c:5308
!0x8ce3fb resolve_transfer
!   ../../gcc-150221/gcc/fortran/resolve.c:9934
!0x8ce3fb gfc_resolve_code(gfc_code*, gfc_namespace*)
!   ../../gcc-150221/gcc/fortran/resolve.c:12154
!0x8cf8b7 gfc_resolve_blocks(gfc_code*, gfc_namespace*)
!   ../../gcc-150221/gcc/fortran/resolve.c:10834
!0x8ccea6 gfc_resolve_code(gfc_code*, gfc_namespace*)
!   ../../gcc-150221/gcc/fortran/resolve.c:11802
!0x8d13b7 resolve_codes
!   ../../gcc-150221/gcc/fortran/resolve.c:17378
!0x8bca0e gfc_resolve(gfc_namespace*)
!   ../../gcc-150221/gcc/fortran/resolve.c:17413
!0x8bca0e gfc_resolve(gfc_namespace*)
!   ../../gcc-150221/gcc/fortran/resolve.c:17392
!0x8af2f0 resolve_all_program_units
!   ../../gcc-150221/gcc/fortran/parse.c:6290
!0x8af2f0 gfc_parse_file()
!   ../../gcc-150221/gcc/fortran/parse.c:6542
!0x9010ef gfc_be_parse_file
!   ../../gcc-150221/gcc/fortran/f95-lang.c:212

[Bug fortran/99145] New: gfortran LOOP

[zeccav at gmail dot com via Gcc-bugs]

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

Bug ID: 99145
   Summary: gfortran LOOP
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

Loop compiling the following code:

! gfortran LOOP? 
  character (len=2_8**32_8+4_8), parameter :: s = ""
  end

[Bug fortran/85851] [8/9 Regression] ICE in gfc_conv_structure Segmentation fault at trans-expr.c:7810

[zeccav at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Vittorio Zecca  ---
Fixed in trung February 15th, 2021.

[Bug fortran/50550] does not recognize pointer variable at initialization (r178939)

[zeccav at gmail dot com via Gcc-bugs]

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

--- Comment #9 from Vittorio Zecca  ---
Intel ifort and ifx accept the test case without errors.

They both accept

pointer pi
integer :: pi=>null()

and

integer :: pi=>null()
pointer pi

Anyway, it's easy to transfom it into

integer, pointer :: pi=>null()

which is accepted by gfortran.

Evidently ifx and ifort have a different approach to symbol table and
compilation passes.

[Bug fortran/50392] SIGSEGV in gfc_trans_label_assign

[zeccav at gmail dot com]

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

--- Comment #23 from Vittorio Zecca  ---
The update proposed in comment #18 fixed the issue.

Thank you!

[Bug target/77273] 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

Vittorio Zecca  changed:

   What|Removed |Added

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

--- Comment #1 from Vittorio Zecca  ---
Fixed.

[Bug debug/61900] loc_descr_plus_const sanitizer runtime error in xgcc while building libgcc_s

[zeccav at gmail dot com]

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

Vittorio Zecca  changed:

   What|Removed |Added

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

--- Comment #3 from Vittorio Zecca  ---
Fixed.

[Bug debug/57933] function dwf_regno accesses dbx_register_map beyond its upper limit

[zeccav at gmail dot com]

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

Vittorio Zecca  changed:

   What|Removed |Added

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

--- Comment #1 from Vittorio Zecca  ---
Fixed.

[Bug testsuite/44791] data_3.f90 accesses uninitialized variable

[zeccav at gmail dot com]

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

Vittorio Zecca  changed:

   What|Removed |Added

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

--- Comment #2 from Vittorio Zecca  ---
Fixed.

[Bug fortran/50551] Argumentless NULL() cannot be used with assumed-length dummy (r178939)

[zeccav at gmail dot com]

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

--- Comment #2 from Vittorio Zecca  ---
Still present at 10.1.1-1

[Bug fortran/50410] [8/9/10/11 Regression] ICE in record_reference, pointer variable in data statement

[zeccav at gmail dot com]

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

Vittorio Zecca  changed:

   What|Removed |Added

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

--- Comment #38 from Vittorio Zecca  ---
Fixed in 10.1.1.
Closing the issue.

[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 50410, which changed state.

Bug 50410 Summary: [8/9/10/11 Regression] ICE in record_reference, pointer 
variable in data statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410

   What|Removed |Added

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

[Bug fortran/50410] [8/9/10/11 Regression] ICE in record_reference, pointer variable in data statement

[zeccav at gmail dot com]

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

--- Comment #37 from Vittorio Zecca  ---
Fixed in 10.1.1.

[Bug target/79636] [8/9/10/11 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

--- Comment #9 from Vittorio Zecca  ---
This issue has been fixed long ago.
It should be closed.

[Bug target/81319] ICE in output_operand_lossage at final.c

[zeccav at gmail dot com]

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

--- Comment #3 from Vittorio Zecca  ---
This issue has been fixed in gcc 10.1.1-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

--- Comment #3 from Vittorio Zecca  ---
On my test case the ICE disappeared and I am now having:

gfortran -S gfbug111.f
gfbug111.f:13:6:

   13 |   function abc_interface(this)
  |  1
Error: ABSTRACT INTERFACE ‘abc_interface’ at (1) must not have an assumed
character length result (F2008: C418)

[Bug c++/91350] New: ICE in gimple_call_arg, at gimple.h:3190 during GIMPLE pass: cddce with options -O1 -fipa-sra

[zeccav at gmail dot com]

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

Bug ID: 91350
   Summary: ICE in gimple_call_arg, at gimple.h:3190 during GIMPLE
pass: cddce with options -O1 -fipa-sra
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

Created attachment 46670
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46670&action=edit
Test case from chromium build

Compiling the attached code with options -O1 -fipa-sra I get the following:

g++ -S -O1 -fipa-sra  gccerr78.C
during GIMPLE pass: cddce
p.cpp: In destructor ‘virtual Ice::Inst::~Inst()’:
p.cpp:21:1: internal compiler error: in gimple_call_arg, at gimple.h:3190
0x7b0c53 gimple_call_arg
../../gcc/gcc/gimple.h:3190
0x7b0c53 gimple_call_arg
../../gcc/gcc/gimple.h:3198
0x7b0c53 propagate_necessity
../../gcc/gcc/tree-ssa-dce.c:813
0x7b0c53 perform_tree_ssa_dce
../../gcc/gcc/tree-ssa-dce.c:1663
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/89504] Checking ICE in 'gcc.dg/rtl/x86_64/pro_and_epilogue.c'

[zeccav at gmail dot com]

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

Vittorio Zecca  changed:

   What|Removed |Added

 CC||zeccav at gmail dot com

--- Comment #2 from Vittorio Zecca  ---
Is this one a duplicate of 79688 ?

[Bug tree-optimization/90242] [UBSAN]: in vn_reference_compute_hash

[zeccav at gmail dot com]

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

Vittorio Zecca  changed:

   What|Removed |Added

 CC||zeccav at gmail dot com

--- Comment #3 from Vittorio Zecca  ---
On this input file I got this one and two more undefined


~/local/gcc-270309-undefined/bin/gcc c-c++-common/Warray-bounds.c -S -O
../../gcc/gcc/poly-int.h:715:21: runtime error: signed integer overflow:
9223372036854775804 + 4 cannot be represented in type 'long int'
../../gcc/gcc/poly-int.h:753:21: runtime error: signed integer overflow:
-9223372036854775807 * 8 cannot be represented in type 'long int'
../../gcc/gcc/cse.c:2215:34: runtime error: signed integer overflow: 0 -
-9223372036854775808 cannot be represented in type 'long int'

Optimization -O would do.

[Bug middle-end/85164] poly-int.h:845:5: runtime error: signed integer overflow

[zeccav at gmail dot com]

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

--- Comment #16 from Vittorio Zecca  ---
On Saturday afternoon I had a power failure that probably damaged my disk,
so I cannot help you now.

[Bug middle-end/85164] poly-int.h:845:5: runtime error: signed integer overflow

[zeccav at gmail dot com]

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

--- Comment #12 from Vittorio Zecca  ---
Here are two more test cases with undefined behaviour in poly-int.h

Must be compiled with nonzero optimization

cat gccerr73.c
// must be compiled with nonzero optimization
// ../../gcc/gcc/poly-int.h:753:21: runtime error: signed integer
overflow: -5621332293356458048 * 8 cannot be represented in type 'long
int'
int a[4];
void f()
{
  long int b = 7818038963515661296;
  a[0xA699ECD2C348A3A0] = a[b];
}


[vitti cc]$cat gccerr74.c
// Must be compiled with nonzero optimization
// ../../gcc/gcc/poly-int.h:944:5: runtime error: signed integer
overflow: 162675373468811328 - -9060696663385964544 cannot be
represented in type 'long int'
long b[1][9];
typedef long V __attribute__((vector_size (16), may_alias));

void
foo ()
{
  V *c = (V *) ((char *) b + -9060696663385964544);
  *c = (V) { 1, 1 };
  long __attribute__((may_alias)) *d = (long *) ((char *) b +
162675373468811328);
  *d = 1;
}

[Bug middle-end/85164] poly-int.h:845:5: runtime error: signed integer overflow

[zeccav at gmail dot com]

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

--- Comment #11 from Vittorio Zecca  ---
After applying your fixes I still have overflow compiling the following

// Must be compiled with nonzero optimization
//../../gcc/gcc/poly-int.h:1095:5: runtime error: signed integer
overflow: 9223372036854775807 * 8 cannot be represented in type 'long
int'
// 87042
const char a[] = {};
int b() { '\0' == a[9223372036854775807]; }

../../gcc/gcc/poly-int.h:1095:5: runtime error: signed integer
overflow: 9223372036854775807 * 8 cannot be represented in type 'long
int'

Remember must be compiled with nonzero optimization

[Bug rtl-optimization/85789] Signed integer overflow with nonzero optimization in cse.c

[zeccav at gmail dot com]

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

--- Comment #1 from Vittorio Zecca  ---
I confirm it is still in trunk 270309, must be compiled with 
nonzero optimization

~/local/gcc-270309-undefined/bin/gcc -S -O gccerr67.c
../../gcc/gcc/cse.c:2215:34: runtime error: signed integer overflow: 1 -
-9223372036854775807 cannot be represented in type 'long int'

Bug now moved at line 2215

offset = (get_integer_term (x) - get_integer_term (p->exp));

[Bug tree-optimization/87042] UBSAN: poly-int.h:1095:5: runtime error: signed integer overflow: 9223372036854775807 * 8 cannot be represented in type 'long int'

[zeccav at gmail dot com]

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

Vittorio Zecca  changed:

   What|Removed |Added

 CC||zeccav at gmail dot com

--- Comment #4 from Vittorio Zecca  ---
Still in trunk 270309.

Requires optimization to reproduce.

/home/vitti/local/gcc-270309-undefined/bin/gcc -S gccerr72.c
[vitti cc]$/home/vitti/local/gcc-270309-undefined/bin/gcc -S gccerr72.c -O
../../gcc/gcc/poly-int.h:1095:5: runtime error: signed integer overflow:
9223372036854775807 * 8 cannot be represented in type 'long int'

[Bug middle-end/85164] poly-int.h:845:5: runtime error: signed integer overflow

[zeccav at gmail dot com]

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

Vittorio Zecca  changed:

   What|Removed |Added

 CC||zeccav at gmail dot com

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

Optimization at least -O1 needed to reproduce the bug.

/home/vitti/local/gcc-270309-undefined/bin/gcc -S gccerr70.c -O1
../../gcc/gcc/poly-int.h:845:5: runtime error: signed integer overflow:
9223372036854775804 + 4 cannot be represented in type 'long int'

[Bug rtl-optimization/87703] UBSAN: poly-int.h:1941:12: runtime error: negation of -9223372036854775808 cannot be represented in type 'long int'; cast to an unsigned type to negate this value to itsel

[zeccav at gmail dot com]

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

Vittorio Zecca  changed:

   What|Removed |Added

 CC||zeccav at gmail dot com

--- Comment #1 from Vittorio Zecca  ---
Still in trunk 270309 but requires optimization, at least -O1
to display the undefined behaviour.

First time found while building gcc compiling dwarf2out.c

[Bug libfortran/87247] New: intrinsic acosh violates 2008 Standard rule 13.7.5 line 5

[zeccav at gmail dot com]

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

Bug ID: 87247
   Summary: intrinsic acosh violates 2008 Standard rule 13.7.5
line 5
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

! Intrinsic acosh violates 2008 Standard rule 13.7.5 line 5
! "If the result is complex the imaginary part is expressed in radians and lies
! in the range 0<= AIMAG(ACOSH(X)) <= pi" pi is approx 3.14
! Imaginary part must be >=0 and <= pi so it may not be negative

  complex :: cc=(-1.0,-1.0)
  print *,acosh(cc) ! Imaginary part negative
  print *,log(cc+sqrt(cc**2-1)) ! this is correct acosh(cc)
  end


(1.06127512,-2.23703575)
(-1.06127524,2.23703575)

Fortran acosh provides negative of correct answer.

[Bug fortran/85851] New: trunk 260152 ICE in gfc_conv_structure Segmentation fault at trans-expr.c:7810

[zeccav at gmail dot com]

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

Bug ID: 85851
   Summary: trunk 260152 ICE in gfc_conv_structure Segmentation
fault at trans-expr.c:7810
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu

! trunk 260152 ICE in gfc_conv_structure Segmentation fault at
trans-expr.c:7810
! must be compiled with -finit-derived
! from test case pr35983
  use ISO_C_BINDING
  type, bind(C) :: descr
   type(C_PTR) :: address
  end type descr
  type(descr) :: DD
  double precision, target :: buf(1)

  DD = descr(c_loc(buf))
  end
!p.f90:4:0:
!
!   use ISO_C_BINDING
! 
!internal compiler error: Segmentation fault
!0xcedddf crash_signal
!   ../../gcc-260152/gcc/toplev.c:325
!0x153cd5c78fcf ???
!  
/usr/src/debug/glibc-2.27-37-g39071a5539/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
!0x855b53 gfc_conv_structure(gfc_se*, gfc_expr*, int)
!   ../../gcc-260152/gcc/fortran/trans-expr.c:7810
!0x855527 gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool,
bool, bool)
!   ../../gcc-260152/gcc/fortran/trans-expr.c:6951
!0x855aa5 gfc_conv_structure(gfc_se*, gfc_expr*, int)
!   ../../gcc-260152/gcc/fortran/trans-expr.c:7818
!0x855527 gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool,
bool, bool)
!   ../../gcc-260152/gcc/fortran/trans-expr.c:6951
!0x83cca4 gfc_get_symbol_decl(gfc_symbol*)
!   ../../gcc-260152/gcc/fortran/trans-decl.c:1835
!0x83fe37 generate_local_decl
!   ../../gcc-260152/gcc/fortran/trans-decl.c:5595
!0x8003e2 do_traverse_symtree
!   ../../gcc-260152/gcc/fortran/symbol.c:4165
!0x840b12 generate_local_vars
!   ../../gcc-260152/gcc/fortran/trans-decl.c:5795
!0x840b12 gfc_generate_function_code(gfc_namespace*)
!   ../../gcc-260152/gcc/fortran/trans-decl.c:6442
!0x7cc1c6 translate_all_program_units
!   ../../gcc-260152/gcc/fortran/parse.c:6121
!0x7cc1c6 gfc_parse_file()
!   ../../gcc-260152/gcc/fortran/parse.c:6324
!0x81243f gfc_be_parse_file
!   ../../gcc-260152/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/80657] [7/8/9 Regression] Loop in character function declaration

[zeccav at gmail dot com]

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

--- Comment #10 from Vittorio Zecca  ---
Just applied the fix: gfortran delivers an error message and exits. In
10 milliseconds!
Thank you for fixing this one.

[Bug tree-optimization/85814] [8/9 Regression] ICE Segmentation fault during GIMPLE pass: strlen -O3 and above

[zeccav at gmail dot com]

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

--- Comment #5 from Vittorio Zecca  ---
I confirm I get the ICE on trunk 260152 and on a sanitized version I also get

../../gcc/gcc/tree-ssa-strlen.c:721:11: runtime error: member access
within null pointer of type 'struct strinfo'

Thank you for the very useful reduction, Martin.

[Bug c/85814] New: ICE Segmentation fault during GIMPLE pass: strlen -O3 and above

[zeccav at gmail dot com]

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

Bug ID: 85814
   Summary: ICE Segmentation fault during GIMPLE pass: strlen -O3
and above
   Product: gcc
   Version: 9.0
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

Created attachment 44141
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44141&action=edit
Preprocessed C source to be compiled with -O3 or above

// gcc 9.0.0 trunk 260152 ICE Segmentation fault during GIMPLE pass: strlen
// must be compiled with option -O3 or above
//gcc -S ~/f95/cc/gccerr68.c -O3
//during GIMPLE pass: strlen
///home/vitti/f95/cc/gccerr68.c: In function
‘cp_units_MP_cp_basic_unit_desc.constprop’:
///home/vitti/f95/cc/gccerr68.c:6388:6: internal compiler error: Segmentation
fault
// void
cp_units_MP_cp_basic_unit_desc(res_,res_Len,basic_kind_,basic_unit_,power_,accept_undefined_)
//  ^~
//0xc74eaf crash_signal
//  ../../gcc-260152/gcc/toplev.c:325
//0x15440fa5ffcf ???
// 
/usr/src/debug/glibc-2.27-37-g39071a5539/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
//0xe2b8ee unshare_strinfo
//  ../../gcc-260152/gcc/tree-ssa-strlen.c:721
//0xe2dd5c get_stridx_plus_constant
//  ../../gcc-260152/gcc/tree-ssa-strlen.c:800
//0xe2e2c4 get_stridx
//  ../../gcc-260152/gcc/tree-ssa-strlen.c:325
//0xe3343b handle_pointer_plus
//  ../../gcc-260152/gcc/tree-ssa-strlen.c:2777
//0xe3343b strlen_check_and_optimize_stmt
//  ../../gcc-260152/gcc/tree-ssa-strlen.c:3237
//0xe3343b strlen_dom_walker::before_dom_children(basic_block_def*)
//  ../../gcc-260152/gcc/tree-ssa-strlen.c:3521
//0x13d1c02 dom_walker::walk(basic_block_def*)
//  ../../gcc-260152/gcc/domwalk.c:353
//0xe34822 execute
//  ../../gcc-260152/gcc/tree-ssa-strlen.c:3601
//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/85789] New: Signed integer overflow with nonzero optimization in cse.c

[zeccav at gmail dot com]

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

Bug ID: 85789
   Summary: Signed integer overflow with nonzero optimization in
cse.c
   Product: gcc
   Version: 9.0
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

// Signed integer overflow in sanitized version of gcc trunk 260152
// Taken from testcase pr82596.c
// Must be compiled with nonzero optimization 
// ../../gcc/gcc/cse.c:2194:34: runtime error: signed integer overflow: 1 -
-9223372036854775807 cannot be represented in type 'long int'
//
#define SSIZE_MAX __PTRDIFF_MAX__
#define SSIZE_MIN (-SSIZE_MAX - 1)

void s (int, ...);


void test (int i)
{
  s (""[SSIZE_MIN + 1]);
  s (""[1]);   
}

[Bug libfortran/85253] [8 Regression] asan detects heap-buffer-overflow in matmul_r4.c

[zeccav at gmail dot com]

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

--- Comment #8 from Vittorio Zecca  ---
Compiling and running under both 8.0.1 and 8.1.0
with MALLOC_CHECK_=1 (see man mallopt)

I get the following (notice "free(): invalid pointer" from mallopt)

/usr/bin/gfortran -g -O0 gfbug144.f 
[vitti f95]$./a.out
free(): invalid pointer

Program received signal SIGABRT: Process abort signal.

Backtrace for this error:
#0  0x1461bb3fffcf in ???
at
/usr/src/debug/glibc-2.27-37-g39071a5539/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
#1  0x1461bb3fff4b in __GI_raise
at ../sysdeps/unix/sysv/linux/raise.c:51
#2  0x1461bb3ea590 in __GI_abort
at /usr/src/debug/glibc-2.27-37-g39071a5539/stdlib/abort.c:79
#3  0x1461bb442b0a in __libc_message
at ../sysdeps/posix/libc_fatal.c:181
#4  0x1461bb44903b in malloc_printerr
at /usr/src/debug/glibc-2.27-37-g39071a5539/malloc/malloc.c:5350
#5  0x1461bb44cdfd in free_check
at /usr/src/debug/glibc-2.27-37-g39071a5539/malloc/hooks.c:274
#6  0x400920 in MAIN__
at /home/vitti/f95/gfbug144.f:11
#7  0x4009c4 in main
at /home/vitti/f95/gfbug144.f:12
Aborted (core dumped)

with valgrind:

valgrind ./a.out
==30798== Memcheck, a memory error detector
==30798== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==30798== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==30798== Command: ./a.out
==30798== 
==30798== Invalid write of size 4
==30798==at 0x4F0E903: matmul_i4_vanilla (matmul_i4.c:2035)
==30798==by 0x400920: MAIN__ (gfbug144.f:11)
==30798==by 0x4009C4: main (gfbug144.f:12)
==30798==  Address 0x6079ec4 is 0 bytes after a block of size 1,028 alloc'd
==30798==at 0x4C2DBAB: malloc (vg_replace_malloc.c:299)
==30798==by 0x4F0D24A: matmul_i4_vanilla (matmul_i4.c:1995)
==30798==by 0x400920: MAIN__ (gfbug144.f:11)
==30798==by 0x4009C4: main (gfbug144.f:12)
==30798== 
==30798== Invalid read of size 4
==30798==at 0x4F10EE6: matmul_i4_vanilla (matmul_i4.c:2197)
==30798==by 0x400920: MAIN__ (gfbug144.f:11)
==30798==by 0x4009C4: main (gfbug144.f:12)
==30798==  Address 0x6079ec4 is 0 bytes after a block of size 1,028 alloc'd
==30798==at 0x4C2DBAB: malloc (vg_replace_malloc.c:299)
==30798==by 0x4F0D24A: matmul_i4_vanilla (matmul_i4.c:1995)
==30798==by 0x400920: MAIN__ (gfbug144.f:11)
==30798==by 0x4009C4: main (gfbug144.f:12)
==30798== 
==30798== Conditional jump or move depends on uninitialised value(s)
==30798==at 0x506872E: write_decimal.constprop.10 (write.c:808)
==30798==by 0x5068B13: write_integer (write.c:1351)
==30798==by 0x5069AED: list_formatted_write_scalar (write.c:1865)
==30798==by 0x506A834: _gfortrani_list_formatted_write (write.c:1943)
==30798==by 0x400966: MAIN__ (gfbug144.f:11)
==30798==by 0x4009C4: main (gfbug144.f:12)
==30798== 
   7  10
==30798== 
==30798== HEAP SUMMARY:
==30798== in use at exit: 0 bytes in 0 blocks
==30798==   total heap usage: 22 allocs, 22 frees, 14,548 bytes allocated
==30798== 
==30798== All heap blocks were freed -- no leaks are possible
==30798== 
==30798== For counts of detected and suppressed errors, rerun with: -v
==30798== Use --track-origins=yes to see where uninitialised values come from
==30798== ERROR SUMMARY: 4 errors from 3 contexts (suppressed: 0 from 0)

[Bug fortran/85631] New: Runtime error message array bound mismatch with nonzero optimization

[zeccav at gmail dot com]

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

Bug ID: 85631
   Summary: Runtime error message array bound mismatch with
nonzero optimization
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu

! Runtime error message on good Fortran
! gfortran -O -g -fcheck=bounds
! must be compiled and run
!At line 20 of file pcp2k.f
!Fortran runtime error: Array bound mismatch for dimension 1 of array
'__var_1_mma' (0/2)

!Error termination. Backtrace:
!#0  0x1496530ec2de in ???
!#1  0x1496530ece89 in ???
!#2  0x1496530ed26b in ???
!#3  0x40082d in MAIN__
!   at /home/vitti/test/pcp2k.f:8
!#4  0x40086e in main
!   at /home/vitti/test/pcp2k.f:9
  integer, parameter :: N=2
  real, dimension(:,:), pointer :: block_1, block_2
  allocate(block_1(N,N),block_2(N,N))
  block_1=0
  block_2=0
  block_1 = MATMUL(TRANSPOSE(block_1), block_2)
  end

[Bug fortran/85387] New: incorrect output with optimization /= 0

[zeccav at gmail dot com]

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

Bug ID: 85387
   Summary: incorrect output with optimization /= 0
   Product: gcc
   Version: 8.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: ---
  Host: x86_64-pc-linux-gnu

! incorrect output with optimization /= 0
! on trunk 259205
real efg_pw(2,2)
efg_pw(1,1)=1
efg_pw(2,1)=2
efg_pw(1,2)=3
efg_pw(2,2)=4
! with optimization /= 0 displays nothing
print *,((efg_pw(i, j), i=1, j), j=1, 2) !should display 1.  3.
   4.
end

[Bug testsuite/85340] New: allocate_deferred_char_scalar_1.f03 dereferences null pointer

[zeccav at gmail dot com]

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

Bug ID: 85340
   Summary: allocate_deferred_char_scalar_1.f03 dereferences null
pointer
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

Testsuite program allocate_deferred_char_scalar_1.f03 at lines 68 and 69
dereferences pointer str4 which was nullified at line 66.
Same at lines 39 and 40.

This is wrong and should be detected by -fcheck=pointer option.

Putting "if(!s1)  runtime_error ("Dereferencing null pointer");" before line 90
of libgfortran/intrinsics/string_intrinsics_inc.c detects the bugs at lines 68
and 39.

On trunk 259205.

[Bug libfortran/85253] [8 Regression] asan detects heap-buffer-overflow in matmul_r4.c

[zeccav at gmail dot com]

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

--- Comment #7 from Vittorio Zecca  ---
You are welcome, very fast fix, keep up the good work!