[Bug fortran/114871] New: valgrind error in gfc_class_vptr_get

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 114871
   Summary: valgrind error in gfc_class_vptr_get
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

>From the flang test suite at
https://github.com/llvm/llvm-project/tree/main/flang/test,
the file ./Lower/Intrinsics/spread.f90, does this:

$ ~/gcc/results.20240427.valgrind/bin/gfortran -c -w
./Lower/Intrinsics/spread.f90
==1511945== Invalid read of size 2
==1511945==at 0x86B811: gfc_class_vptr_get(tree_node*) (trans-expr.cc:247)
==1511945==by 0x883366: trans_class_vptr_len_assignment(stmtblock_t*,
gfc_expr*, gfc_expr*, gfc_se*, tree_node**, tree_node**, tree_node**)
(trans-expr.cc:10146)
==1511945==by 0x8863A2: trans_class_assignment (trans-expr.cc:11969)
==1511945==by 0x8863A2: gfc_trans_assignment_1(gfc_expr*, gfc_expr*, bool,
bool, bool, bool) (trans-expr.cc:12435)

[Bug fortran/113917] ice in gfc_class_vptr_get

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #2 from David Binderman  ---
Bit more detail from valgrind:

==1450005== Invalid read of size 2
==1450005==at 0x86B811: gfc_class_vptr_get(tree_node*) (trans-expr.cc:247)
==1450005==by 0x883366: trans_class_vptr_len_assignment(stmtblock_t*,
gfc_expr*, gfc_expr*, gfc_se*, tree_node**, tree_node**, tree_node**)
(trans-expr.cc:10146)
==1450005==by 0x8863A2: trans_class_assignment (trans-expr.cc:11969)
==1450005==by 0x8863A2: gfc_trans_assignment_1(gfc_expr*, gfc_expr*, bool,
bool, bool, bool) (trans-expr.cc:12435)

[Bug fortran/93814] [11/12/13/14/15 Regression] ICE in build_entry_thunks, at fortran/trans-decl.c:2898

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #12 from David Binderman  ---
Bit more detail:

./Lower/HLFIR/bindc-entry-stmt.f90:5:0:

5 | function foo() bind(c)
Warning: Variable ‘foo’ at (1) may not be a C interoperable kind but it is
BIND(C) [-Wc-binding-type]
./Lower/HLFIR/bindc-entry-stmt.f90:39:28:

   39 |   character(1) :: foo2, bar2
  |1
Warning: Variable ‘bar2’ at (1) may not be a C interoperable kind but it is
BIND(C) [-Wc-binding-type]
==1442522== Invalid read of size 8
==1442522==at 0x862E5E: quick_push (vec.h:1043)
==1442522==by 0x862E5E: vec_safe_push (vec.h:835)
==1442522==by 0x862E5E: build_entry_thunks (trans-decl.cc:3002)
==1442522==by 0x862E5E: gfc_create_function_decl(gfc_namespace*, bool)
(trans-decl.cc:3157)

[Bug fortran/114739] [14 Regression] ice in gfc_find_derived_types, at fortran/symbol.cc:2458

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #2 from David Binderman  ---
Created attachment 57959
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57959=edit
F90 source code

[Bug fortran/114739] New: [14 Regression] ice in gfc_find_derived_types, at fortran/symbol.cc:2458

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 114739
   Summary: [14 Regression] ice in gfc_find_derived_types, at
fortran/symbol.cc:2458
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

>From the flang testsuite at

https://github.com/llvm/llvm-project/tree/main/flang/test

file ./Semantics/symbol07.f90, does this with gfortran 13.2:

$ ~/gcc/results.13.2.asan.ubsan/bin/gfortran -c -w ./Semantics/symbol07.f90
./Semantics/symbol07.f90:28:5:

   28 |  z2%re = x
  | 1
Error: Symbol ‘z2’ at (1) has no IMPLICIT type
./Semantics/symbol07.f90:31:5:

   31 |  z2%im = y
  | 1
Error: Symbol ‘z2’ at (1) has no IMPLICIT type
$

and this with yesterday's gfortran:

$ ~/gcc/results.20240415.asan.ubsan/bin/gfortran -c -w ./Semantics/symbol07.f90
f951: internal compiler error: in gfc_find_derived_types, at
fortran/symbol.cc:2458
0x6f3ca3 gfc_find_derived_types(gfc_symbol*, gfc_namespace*, char const*, bool)
../../trunk.20210101/gcc/fortran/symbol.cc:2458
0x9e1686 gfc_match_varspec(gfc_expr*, int, bool, bool)
../../trunk.20210101/gcc/fortran/primary.cc:2246
0x9e1916 match_variable
../../trunk.20210101/gcc/fortran/primary.cc:4309
0x99a364 gfc_match(char const*, ...)
../../trunk.20210101/gcc/fortran/match.cc:1144

[Bug libstdc++/114721] New: libstdc++-v3/include/ext/codecvt_specializations.h: 2 * small performance tweeks

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 114721
   Summary: libstdc++-v3/include/ext/codecvt_specializations.h: 2
* small performance tweeks
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Static analyser cppcheck says:

1.

libstdc++-v3/include/ext/codecvt_specializations.h:142:5: performance: Function
'external_encoding()' should return member '_M_ext_enc' by const reference.
[returnByReference]

Source code is

const std::string
external_encoding() const
{ return _M_ext_enc; }

2.

libstdc++-v3/include/ext/codecvt_specializations.h:134:5: performance: Function
'internal_encoding()' should return member '_M_int_enc' by const reference.
[returnByReference]

Duplicate.

[Bug libgcc/114689] [14 Regression] libgcc/config/m68k/fpgnulib.c:305: Suspicious coding ?

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #6 from David Binderman  ---
(In reply to Jakub Jelinek from comment #5)
> And does
> extern void g( int);
> 
> void f( int mant, int sticky)
> {
>   mant = mant >> 1 ;
>   mant = mant >> 1 | (mant & 1);
>   mant = mant >> 1 | (mant & 1) | (!!sticky);
>   mant = !!sticky;
>   mant = (mant & 1) | (!!sticky);
>   g( mant);
> }
> shut up those warnings?

Yes.

[Bug libgcc/114689] [14 Regression] libgcc/config/m68k/fpgnulib.c:305: Suspicious coding ?

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #4 from David Binderman  ---
I tried this code:

extern void g( int);

void f( int mant, int sticky)
{
mant = mant >> 1 ;
mant = mant >> 1 | (mant & 1);
mant = mant >> 1 | (mant & 1) | !!sticky;
mant = !!sticky;
mant = (mant & 1) | !!sticky;
g( mant);
}

Cppcheck says:

$ ~/cppcheck/trunk/cppcheck --enable=all apr12a.cc
apr12a.cc:8:32: style: Boolean result is used in bitwise operation. Clarify
expression with parentheses. [clarifyCondition]
 mant = mant >> 1 | (mant & 1) | !!sticky;
   ^
apr12a.cc:10:20: style: Boolean result is used in bitwise operation. Clarify
expression with parentheses. [clarifyCondition]
 mant = (mant & 1) | !!sticky;
   ^
so it appears to be the combination of bitwise operation (mant & 1) 
and the boolean result !!sticky.

[Bug libgcc/114689] New: [14 Regression] libgcc/config/m68k/fpgnulib.c:305: Suspicious coding ?

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 114689
   Summary: [14 Regression] libgcc/config/m68k/fpgnulib.c:305:
Suspicious coding ?
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Static analyser cppcheck says:

libgcc/config/m68k/fpgnulib.c:305:37: style: Boolean result is used in bitwise
operation. Clarify expression with parentheses. [clarifyCondition]

Source code is

 mant = mant >> 1 | (mant & 1) | !!sticky;

Perhaps

 mant = (mant >> 1) | (mant & 1) | !!sticky;

was intended. 

This problem doesn't exist in the source code of gcc-13.2

[Bug libstdc++/114680] New: libstdc++-v3/include/ext/mt_allocator.h:142: possible performance problem ?

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 114680
   Summary: libstdc++-v3/include/ext/mt_allocator.h:142: possible
performance problem ?
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Static analyser cppcheck says:

libstdc++-v3/include/ext/mt_allocator.h:142:26: performance: Function parameter
'__t' should be passed by const reference. [passedByValue]

Source code is

_M_set_options(_Tune __t)

AFAIK sizeof( _Tune) >= 6 * sizeof( size_t) + sizeof( bool), so it might
well be worthwhile to take the advice of the static analyser.

[Bug fortran/113956] [14 Regression] ice in gfc_trans_pointer_assignment, at fortran/trans-expr.cc:10524

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

Summary|ice in  |[14 Regression] ice in
   |gfc_trans_pointer_assignmen |gfc_trans_pointer_assignmen
   |t, at   |t, at
   |fortran/trans-expr.cc:10524 |fortran/trans-expr.cc:10524

--- Comment #1 from David Binderman  ---
It looks like a regression from gcc-13.2:

test $ ~/gcc/results.13.2.asan.ubsan/bin/gfortran -c -w
./Lower/pointer-assignments.f90
test $ ~/gcc/results.20240327.asan.ubsan/bin/gfortran -c -w
./Lower/pointer-assignments.f90
./Lower/pointer-assignments.f90:54:8:

   54 |   p => x
  |1
internal compiler error: in gfc_trans_pointer_assignment, at
fortran/trans-expr.cc:10539

[Bug middle-end/113396] [13/14 Regression] csmith: differences from -O2 to -O3

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #19 from David Binderman  ---
gcc 12.3 seems to get it right:

foundBugs $ ~/gcc/results.12.3.asan.ubsan/bin/gcc -w -O2
--param=max-inline-insns-auto=23 bug998.c &&  valgrind -q ./a.out
checksum = 77A231E6
foundBugs $ ~/gcc/results.12.3.asan.ubsan/bin/gcc -w -O2
--param=max-inline-insns-auto=24 bug998.c &&  valgrind -q ./a.out
checksum = 77A231E6
foundBugs $ ~/gcc/results.12.3.asan.ubsan/bin/gcc -w -O2
--param=max-inline-insns-auto=30 bug998.c &&  valgrind -q ./a.out
checksum = 77A231E6
foundBugs $ ~/gcc/results.12.3.asan.ubsan/bin/gcc -w -O3  bug998.c &&  valgrind
-q ./a.out
checksum = 77A231E6
foundBugs $

[Bug middle-end/113396] [13/14 Regression] csmith: differences from -O2 to -O3

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #18 from David Binderman  ---
(In reply to David Binderman from comment #17)
> I tried out gcc-13.2 and got the following results:
> 
> foundBugs $ ~/gcc/results.13.2.asan.ubsan/bin/gcc -w -O2
> --param=max-inline-insns-auto=23 bug998.c &&  valgrind -q ./a.out
> checksum = 77A231E6
> foundBugs $ ~/gcc/results.13.2.asan.ubsan/bin/gcc -w -O2
> --param=max-inline-insns-auto=24 bug998.c &&  valgrind -q ./a.out
> checksum = 130B5204
> foundBugs $ 
> 
> so it is something that has been going wrong since before gcc-13.2.

Similarly with 13.1:

foundBugs $ ~/gcc/results.13.1.asan.ubsan/bin/gcc -w -O2
--param=max-inline-insns-auto=23 bug998.c &&  valgrind -q ./a.out
checksum = 77A231E6
foundBugs $ ~/gcc/results.13.1.asan.ubsan/bin/gcc -w -O2
--param=max-inline-insns-auto=24 bug998.c &&  valgrind -q ./a.out
checksum = 130B5204
foundBugs $

[Bug middle-end/113396] [13/14 Regression] csmith: differences from -O2 to -O3

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #17 from David Binderman  ---
I tried out gcc-13.2 and got the following results:

foundBugs $ ~/gcc/results.13.2.asan.ubsan/bin/gcc -w -O2
--param=max-inline-insns-auto=23 bug998.c &&  valgrind -q ./a.out
checksum = 77A231E6
foundBugs $ ~/gcc/results.13.2.asan.ubsan/bin/gcc -w -O2
--param=max-inline-insns-auto=24 bug998.c &&  valgrind -q ./a.out
checksum = 130B5204
foundBugs $ 

so it is something that has been going wrong since before gcc-13.2.

[Bug middle-end/113396] [13/14 Regression] csmith: differences from -O2 to -O3

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #16 from David Binderman  ---
(In reply to David Binderman from comment #15)
> So it looks like one or more of the --param flags is to blame.

foundBugs $ ~/gcc/results/bin/gcc -w -O2 bug998.c &&  ./a.out
checksum = 77A231E6
foundBugs $ ~/gcc/results/bin/gcc -w -O2 --param=max-inline-insns-auto=30
bug998.c &&  ./a.out
checksum = 130B5204
foundBugs $ 

It seems to break sometime between 23 and 24.

foundBugs $ ~/gcc/results/bin/gcc -w -O2 --param=max-inline-insns-auto=23
bug998.c &&  ./a.out
checksum = 77A231E6
foundBugs $ ~/gcc/results/bin/gcc -w -O2 --param=max-inline-insns-auto=24
bug998.c &&  ./a.out
checksum = 130B5204
foundBugs $

[Bug middle-end/113396] [13/14 Regression] csmith: differences from -O2 to -O3

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #15 from David Binderman  ---
(In reply to Jakub Jelinek from comment #14)
> So, that is -O2 -fgcse-after-reload -fipa-cp-clone -floop-interchange
> -floop-unroll-and-jam -fpeel-loops -fpredictive-commoning -fsplit-loops
> -fsplit-paths -ftree-loop-distribution -ftree-partial-pre -funswitch-loops
> -fvect-cost-model=dynamic -fversion-loops-for-strides
> --param=max-inline-insns-auto=30 --param=early-inlining-insns=14
> --param=inline-heuristics-hint-percent=600 --param=inline-min-speedup=15
> --param=max-inline-insns-single=200

Thanks for that. None of the -f flags seems to affect anything.

foundBugs $ cat flag.list
--param=early-inlining-insns=14
--param=inline-heuristics-hint-percent=600
--param=inline-min-speedup=15
--param=max-inline-insns-auto=30
--param=max-inline-insns-single=200
-O2
foundBugs $ ~/gcc/results/bin/gcc -w -O2 bug998.c &&  ./a.out
checksum = 77A231E6
foundBugs $ ~/gcc/results/bin/gcc -w `cat flag.list` bug998.c &&  ./a.out
checksum = 130B5204
foundBugs $ 

So it looks like one or more of the --param flags is to blame.

[Bug middle-end/113396] [13/14 Regression] csmith: differences from -O2 to -O3

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #13 from David Binderman  ---
I had another look at the original source code and got this with
recent gcc trunk:

foundBugs $ ~/gcc/results/bin/gcc -w bug998.c && ./a.out
checksum = 77A231E6

foundBugs $ ~/gcc/results/bin/gcc -w -O2 bug998.c && ./a.out
checksum = 77A231E6

foundBugs $ ~/gcc/results/bin/gcc -w -O3 bug998.c && ./a.out
checksum = 130B5204

foundBugs $ ~/gcc/results/bin/gcc -w -O3 -fno-strict-aliasing
-fno-loop-interchange bug998.c && ./a.out
checksum = 130B5204

foundBugs $ ~/gcc/results/bin/gcc -w -O3 -fno-strict-aliasing
-fno-loop-interchange bug998.c && valgrind -q ./a.out
checksum = 130B5204

foundBugs $ ~/gcc/results/bin/gcc -w -O3 -fno-strict-aliasing
-fno-loop-interchange -fsanitize=address bug998.c &&  ./a.out
checksum = 77A231E6

foundBugs $ ~/gcc/results/bin/gcc -w -O3 -fno-strict-aliasing
-fno-loop-interchange -fsanitize=undefined bug998.c &&  ./a.out
checksum = 77A231E6
foundBugs $ 

Case 3 looks suspicious. I guess if I knew the which flags -O3 switches on,
that aren't in -O2, I could find out which ones are causing trouble.
I don't know a -O2.5

Case 4 makes it look like aliasing and loop interchange aren't at fault.

Cases 5, 6 & 7 show that the usual tools find nothing wrong.

Cases 6 & 7 make it looks like switching on a sanitizer makes the code work. 
I don't understand why that would be.

[Bug debug/108843] timeout with -g -O3 since r9-2635-g78ea9abc2018243a

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #5 from David Binderman  ---
Created attachment 57711
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57711=edit
C source code

Another test case.

foundBugs $ (ulimit -t 60; time ~/gcc/results/bin/gcc -c -w -O3 bug1023.c)
real0m0.456s
user0m0.435s
sys 0m0.019s

foundBugs $ (ulimit -t 60; time ~/gcc/results/bin/gcc -c -w -g -O3 bug1023.c)
gcc: fatal error: Killed signal terminated program cc1
compilation terminated.
real1m0.363s
user0m59.555s
sys 0m0.524s

foundBugs $ (ulimit -t 60; time ~/gcc/results/bin/gcc -c -w -g -O3
-fno-var-tracking bug1023.c)
real0m6.269s
user0m5.620s
sys 0m0.502s
foundBugs $

[Bug c++/114297] New: Yet more problems with "definition in block does not dominate use in block"

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 114297
   Summary: Yet more problems with "definition in block does not
dominate use in block"
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

For this C++ code:

void __assert_fail(char *, int, const char *) __attribute__((__noreturn__));
template  void max(T, T);
template  struct SimpleVector {
  T array;
  int num;
  T *getRef(int i) {
num - i ? void() : __assert_fail("", 7, __PRETTY_FUNCTION__);
return  + i;
  }
};
struct Extremes {
  int minWidth;
  int maxWidth;
};
int forceCalcColumnExtremes_cs;
struct Table {
  SimpleVector colExtremes;
  void forceCalcColumnExtremes();
};
void Table::forceCalcColumnExtremes() {
  int minSumCols, maxSumCols;
  for (int i; i; ++i) {
minSumCols += colExtremes.getRef(i)->minWidth;
maxSumCols += colExtremes.getRef(i)->maxWidth;
  }
  max(forceCalcColumnExtremes_cs, minSumCols);
  max(forceCalcColumnExtremes_cs, maxSumCols);
}

compiled by recent gcc trunk, does this:

cvise $ ~/gcc/results/bin/g++ -c -w -O3 bug1022.cc
cvise $ ~/gcc/results/bin/g++ -c -w -O3 -march=znver3 bug1022.cc
bug1022.cc: In member function ‘void Table::forceCalcColumnExtremes()’:
bug1022.cc:20:6: error: definition in block 5 does not dominate use in block 3
   20 | void Table::forceCalcColumnExtremes() {
  |  ^
for SSA_NAME: vect_maxSumCols_16.16_76 in statement:
vect_maxSumCols_16.16_90 = PHI 
PHI argument
vect_maxSumCols_16.16_76
for PHI node
vect_maxSumCols_16.16_90 = PHI 
during GIMPLE pass: vect
bug1022.cc:20:6: internal compiler error: verify_ssa failed
0x159e432 verify_ssa(bool, bool)
../../trunk.20210101/gcc/tree-ssa.cc:1203
0x1204a9d execute_function_todo
../../trunk.20210101/gcc/passes.cc:2095

The bug first seems to occur sometime between g:71244316cf714725
and g:10cbfcd60f9e5bdb, which is a distance of 43 commits.

[Bug middle-end/105533] UBSAN: gcc/expmed.cc:3272:26: runtime error: signed integer overflow: -9223372036854775808 - 1 cannot be represented in type 'long int'

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #13 from David Binderman  ---
Seems fixed to me. 

I built a bootstrap with ASAN and UBSAN
for languages C, C++ and Fortran and changed the usual
-O2 for -O3 -march=znver3 and the bootstrap passed.

I hadn't realised a bootstrap was such a good test of the compiler.

[Bug middle-end/105533] UBSAN: gcc/expmed.cc:3272:26: runtime error: signed integer overflow: -9223372036854775808 - 1 cannot be represented in type 'long int'

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #5 from David Binderman  ---
The problem with expmed.c happens with -O2 -march=znver3,
so it's more prevalent than I thought.

The problem with poly-int.h seems to require -O3.

So they look like two separate problems.

[Bug middle-end/105533] UBSAN: gcc/expmed.cc:3272:26: runtime error: signed integer overflow: -9223372036854775808 - 1 cannot be represented in type 'long int'

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #3 from David Binderman  ---
Asan, most of the checking flags, fortran and the -march setting not required.

Current configure script is:

../trunk.20210101/configure \
--disable-multilib \
--disable-werror \
--with-pkgversion=$HASH \
--with-build-config=bootstrap-ubsan \
--enable-checking=yes \
--enable-languages=c,c++

sed 's;-O2;-O3;' < Makefile > Makefile.tmp
diff Makefile Makefile.tmp
mv Makefile.tmp Makefile

>From the output of the bootstrap:

Configuring stage 2 in x86_64-pc-linux-gnu/libgcc
../../trunk.20210101/gcc/poly-int.h:1089:5: runtime error: left shift of
negative value -8
../../trunk.20210101/gcc/poly-int.h:1089:5: runtime error: left shift of
negative value -8
../../trunk.20210101/gcc/expmed.cc:3288:26: runtime error: signed integer
overflow: -9223372036854775808 - 1 cannot be represented in type 'long int'
Configuring stage 2 in x86_64-pc-linux-gnu/libgomp

[Bug middle-end/105533] UBSAN: gcc/expmed.cc:3272:26: runtime error: signed integer overflow: -9223372036854775808 - 1 cannot be represented in type 'long int'

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #2 from David Binderman  ---
I see something similar when attempting a bootstrap with asan & ubsan on
current gcc trunk:

gcc/expmed.cc:3288:26: runtime error: signed integer overflow:
-9223372036854775808 - 1 cannot be represented in type 'long int'

Configure is:

../trunk/configure \
--disable-multilib \
--disable-werror \
--with-build-config=bootstrap-asan \
--with-build-config=bootstrap-ubsan \
--enable-checking=df,extra,fold,rtl,yes \
--enable-languages=c,c++,fortran

And there are extra flags added to the top level Makefile:

sed 's;-O2;-O3 -march=native;' < Makefile > Makefile.tmp
diff Makefile Makefile.tmp
mv Makefile.tmp Makefile

I wonder if this is a regression for gcc-14.

[Bug c/114239] New: ice: error: definition in block does not dominate use in block

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 114239
   Summary: ice: error: definition in block does not dominate use
in block
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

For this C code:

int ip4_getbit_a, ip4_getbit_pos, ip4_clrbit_pos;
void ip4_clrbit(int *a) { *a &= ip4_clrbit_pos; }
typedef struct {
  char pxlen;
  int prefix
} net_addr_ip4;
void fib_get_chain();
int trie_match_longest_ip4();
int trie_match_next_longest_ip4(net_addr_ip4 *n) {
  int __trans_tmp_1;
  while (n->pxlen) {
n->pxlen--;
ip4_clrbit(>prefix);
__trans_tmp_1 = ip4_getbit_a >> ip4_getbit_pos;
if (__trans_tmp_1)
  return 1;
  }
  return 0;
}
void net_roa_check_ip4_trie_tab() {
  net_addr_ip4 px0;
  for (int _n = trie_match_longest_ip4(); _n;
   _n = trie_match_next_longest_ip4())
fib_get_chain();
}

on x86_64, does this:

$ ../results/bin/gcc -c -O3 -march=znver3 -w ~/cvise/bug1021.c
/home/dcb38/cvise/bug1021.c: In function ‘net_roa_check_ip4_trie_tab’:
/home/dcb38/cvise/bug1021.c:20:6: error: definition in block 19 does not
dominate use in block 14
   20 | void net_roa_check_ip4_trie_tab() {
  |  ^~
for SSA_NAME: _117 in statement:
px0__lsm.22_47 = PHI <_117(14), _117(19)>
PHI argument
_117
for PHI node
px0__lsm.22_47 = PHI <_117(14), _117(19)>
during GIMPLE pass: vect
/home/dcb38/cvise/bug1021.c:20:6: internal compiler error: verify_ssa failed

The bug first seems to occur sometime between g:1e74ce8983fd4926
and g:71244316cf714725, which is 42 commits.

[Bug tree-optimization/114234] [14 Regression] verify_ssa failure with early-break vectorisation

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #1 from David Binderman  ---

For this C code:

int ip4_getbit_a, ip4_getbit_pos, ip4_clrbit_pos;
void ip4_clrbit(int *a) { *a &= ip4_clrbit_pos; }
typedef struct {
  char pxlen;
  int prefix
} net_addr_ip4;
void fib_get_chain();
int trie_match_longest_ip4();
int trie_match_next_longest_ip4(net_addr_ip4 *n) {
  int __trans_tmp_1;
  while (n->pxlen) {
n->pxlen--;
ip4_clrbit(>prefix);
__trans_tmp_1 = ip4_getbit_a >> ip4_getbit_pos;
if (__trans_tmp_1)
  return 1;
  }
  return 0;
}
void net_roa_check_ip4_trie_tab() {
  net_addr_ip4 px0;
  for (int _n = trie_match_longest_ip4(); _n;
   _n = trie_match_next_longest_ip4())
fib_get_chain();
}

on x86_64, does this:

$ ../results/bin/gcc -c -O3 -march=znver3 -w ~/cvise/bug1021.c
/home/dcb38/cvise/bug1021.c: In function ‘net_roa_check_ip4_trie_tab’:
/home/dcb38/cvise/bug1021.c:20:6: error: definition in block 19 does not
dominate use in block 14
   20 | void net_roa_check_ip4_trie_tab() {
  |  ^~
for SSA_NAME: _117 in statement:
px0__lsm.22_47 = PHI <_117(14), _117(19)>
PHI argument
_117
for PHI node
px0__lsm.22_47 = PHI <_117(14), _117(19)>
during GIMPLE pass: vect
/home/dcb38/cvise/bug1021.c:20:6: internal compiler error: verify_ssa failed

The bug first seems to occur sometime between g:1e74ce8983fd4926
and g:71244316cf714725, which is 42 commits.

[Bug c++/114128] ice with -fstrub=internal

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #2 from David Binderman  ---
(In reply to Richard Biener from comment #1)
> incomplete bugreport

Sorry, my mistake. I created a new one, when an
old one is a better place.

See # 112938 for more details.

[Bug middle-end/112938] ice with -fstrub=internal

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #9 from David Binderman  ---
The reduced source code of comment 1 seems to compile ok, but the original 
attached source code doesn't.

[Bug middle-end/112938] ice with -fstrub=internal

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #8 from David Binderman  ---
(In reply to Alexandre Oliva from comment #7)
> Fixed.

Seems to have reappeared:

$ ~/gcc/results/bin/gcc -c -fstrub=internal bug988.cc
bt2_locks.cpp: In function ‘void mcs_lock::spin_while_eq(const volatile
std::atomic_bool&, bool)’:
bt2_locks.cpp:36:1: error: invalid address operand in ‘mem_ref’
*expected;

# VUSE <.MEM_8>
expected.8_3 ={v} *expected;
during IPA pass: strub
bt2_locks.cpp:36:1: internal compiler error: verify_gimple failed
0x11f4a92 verify_gimple_in_cfg(function*, bool, bool)
/home/dcb38/gcc/working/gcc/../../trunk.20210101/gcc/tree-cfg.cc:5663
0x1065788 execute_function_todo(function*, void*)
/home/dcb38/gcc/working/gcc/../../trunk.20210101/gcc/passes.cc:2088

I would be grateful if someone could confirm what I am seeing here.

[Bug c++/114128] New: ice with -fstrub=internal

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 114128
   Summary: ice with -fstrub=internal
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

[Bug fortran/114102] New: ice in matching_typebound_op, at fortran/interface.cc:4564

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 114102
   Summary: ice in matching_typebound_op, at
fortran/interface.cc:4564
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 57528
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57528=edit
F90 source code

>From the flang testsuite at

https://github.com/llvm/llvm-project/tree/main/flang/test

source code file ./Semantics/modfile35.f90, does this with recent 
gcc trunk:

test $ ~/gcc/results/bin/gfortran -c -w ./Semantics/modfile35.f90
f951: internal compiler error: in matching_typebound_op, at
fortran/interface.cc:4564
0x7768f6 matching_typebound_op(gfc_expr**, gfc_actual_arglist*,
gfc_intrinsic_op, char const*, char const**)
   
/home/dcb38/gcc/working/gcc/../../trunk.20210101/gcc/fortran/interface.cc:4564

This bug has existed since sometime before 20240126.

[Bug fortran/113956] New: ice in gfc_trans_pointer_assignment, at fortran/trans-expr.cc:10524

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 113956
   Summary: ice in gfc_trans_pointer_assignment, at
fortran/trans-expr.cc:10524
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 57435
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57435=edit
F90 source code

>From the flang test suite at

https://github.com/llvm/llvm-project/tree/main/flang/test,

the file ./Lower/pointer-assignments.f90 does this:

test $ ~/gcc/results/bin/gfortran -c -w ./Lower/dummy-procedure-character.f90
./Lower/dummy-procedure-character.f90:183:4:

  183 | function bar10(n)
  |1
internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.cc:1629
0x861f00 gfc_get_symbol_decl(gfc_symbol*)
   
/home/dcb38/gcc/working/gcc/../../trunk.20210101/gcc/fortran/trans-decl.cc:1629
0x8911b5 gfc_conv_variable(gfc_se*, gfc_expr*)
   
/home/dcb38/gcc/working/gcc/../../trunk.20210101/gcc/fortran/trans-expr.cc:3049

[Bug fortran/107141] ICE: Segmentation fault (in contains_struct_check)

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #4 from David Binderman  ---
Similar thing happens with file ./Lower/derived-type-finalization.f90
from the same test suite:

test $ /home/dcb38/gcc/results.20240214.asan.ubsan/bin/gfortran -c -w
./Lower/derived-type-finalization.f90
./Lower/derived-type-finalization.f90:227:37:

  227 | allocate(up(10), source=copy(10))
  | 1
internal compiler error: Segmentation fault
0xf55039 crash_signal(int)
/home/dcb38/gcc/working/gcc/../../trunk.20210101/gcc/toplev.cc:317
0x87a0ab contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../../trunk.20210101/gcc/tree.h:3757

[Bug fortran/107143] ICE: 'verify_gimple' failed (Error: non-trivial conversion in 'mem_ref')

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #2 from David Binderman  ---
(In reply to Arseny Solokha from comment #0)
> gfortran 13.0.0 20220925 snapshot
> (g:77bbf69d2981dafc2ef3e59bfbefb645d88bab9d) ICEs when compiling the
> following testcase w/ -fchecking, reduced from
> test/Lower/forall/array-pointer.f90 from the flang 15.0.1 test suite:

I can confirm that this is still happening on recent gfortran.

test $ /home/dcb38/gcc/results.20240214.asan.ubsan/bin/gfortran -c -w
./Lower/forall/array-pointer.f90
./Lower/forall/array-pointer.f90:486:13:

  486 | subroutine s5(x,y,z,n1,n2)
  | ^
Error: non-trivial conversion in ‘mem_ref’
struct array02_integer(kind=4)
struct array01_integer(kind=4)
parm.85 = *_86;
./Lower/forall/array-pointer.f90:486:13: internal compiler error:
‘verify_gimple’ failed

[Bug fortran/113917] ice in gfc_class_vptr_get

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #1 from David Binderman  ---
(In reply to David Binderman from comment #0)
>The problem seems to exist since sometime before 2024016.

That should be 20240116.

[Bug fortran/113917] New: ice in gfc_class_vptr_get

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 113917
   Summary: ice in gfc_class_vptr_get
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 57420
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57420=edit
F90 source code

>From the flang test suite at

https://github.com/llvm/llvm-project/tree/main/flang/test

the file ./Lower/HLFIR/elemental-array-ops.f90 does this:

test $ ~/gcc/results/bin/gfortran -c -w ./Lower/HLFIR/elemental-array-ops.f90
./Lower/HLFIR/elemental-array-ops.f90:247:9:

  247 |   x = (y)
  | 1
internal compiler error: Segmentation fault
0xf58d89 crash_signal(int)
/home/dcb38/gcc/working/gcc/../../trunk.20210101/gcc/toplev.cc:317
0x87ade1 gfc_class_vptr_get(tree_node*)
   
/home/dcb38/gcc/working/gcc/../../trunk.20210101/gcc/fortran/trans-expr.cc:247
0x8944ea trans_class_vptr_len_assignment(stmtblock_t*, gfc_expr*, gfc_expr*,
gfc_se*, tree_node**, tree_node**, tree_node**)

with recent gfortran. The problem seems to exist since sometime before 2024016.

[Bug fortran/93814] [11/12/13/14 Regression] ICE in build_entry_thunks, at fortran/trans-decl.c:2898

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #11 from David Binderman  ---
>From the flang testsuite file ./Lower/HLFIR/bindc-entry-stmt.f90, 
these two should work:

function foo() bind(c)
  character(1) :: foo, bar
entry bar()
  bar = "a"
end function

and

function foo2()
  character(1) :: foo2, bar2
entry bar2() bind(c)
  bar2 = "a"
end function

Instead, I get:

internal compiler error: Segmentation fault
0xf580a9 crash_signal(int)
/home/dcb38/gcc/working/gcc/../../trunk.20210101/gcc/toplev.cc:317
0x866511 build_entry_thunks(gfc_namespace*, bool)
   
/home/dcb38/gcc/working/gcc/../../trunk.20210101/gcc/fortran/trans-decl.cc:0
0x866511 gfc_create_function_decl(gfc_namespace*, bool)

[Bug c/113902] New: ice in find_uses_to_rename_use

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 113902
   Summary: ice in find_uses_to_rename_use
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

For this C source code:

int g_66, g_80_2;
void func_1func_41(int p_43) {
lbl_1434:
  g_80_2 = 0;
  for (; g_80_2 <= 7; g_80_2 += 1) {
g_66 = 0;
for (; g_66 <= 7; g_66 += 1)
  if (p_43)
goto lbl_1434;
  }
}

compiled by recent gcc trunk, does this:

cvise $ ~/gcc/results/bin/gcc -c -O2 -march=znver3 bug1012.c 
during GIMPLE pass: vect
bug1012.c: In function ‘func_1func_41’:
bug1012.c:2:6: internal compiler error: Segmentation fault
2 | void func_1func_41(int p_43) {
  |  ^
0xed49f9 crash_signal(int)
/home/dcb38/gcc/working/gcc/../../trunk.20210101/gcc/toplev.cc:317
0x106b7e8 find_uses_to_rename_use(basic_block_def*, tree_node*, bitmap_head**,
b
itmap_head*)
   
/home/dcb38/gcc/working/gcc/../../trunk.20210101/gcc/tree-ssa-loop-manip
.cc:414

The bug first seems to occur sometime between g:48207a5f00d6ae7c
and g:39d989022dd0eacf.

[Bug c/113895] New: ice in in copy_reference_ops_from_ref, at tree-ssa-sccvn.cc:1144

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 113895
   Summary: ice in in copy_reference_ops_from_ref, at
tree-ssa-sccvn.cc:1144
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

This C source code:

int main_i;
void transparent_crc();
#pragma pack(1)
struct {
  signed : 17;
  signed : 6;
  unsigned : 13;
  unsigned f6 : 12
} g_20[];
void main() { transparent_crc(g_20[main_i].f6); }

when compiled by recent gcc, does this:

cvise $ ~/gcc/results/bin/gcc -c -O1 bug1011.c
bug1011.c:9:1: warning: no semicolon at end of struct or union
9 | } g_20[];
  | ^
bug1011.c:9:3: warning: array ‘g_20’ assumed to have one element
9 | } g_20[];
  |   ^~~~
during GIMPLE pass: fre
bug1011.c: In function ‘main’:
bug1011.c:10:1: internal compiler error: in copy_reference_ops_from_ref, at
tree-ssa-sccvn.cc:1144
   10 | void main() { transparent_crc(g_20[main_i].f6); }
  | ^~~~
0x10e922a copy_reference_ops_from_ref(tree_node*, vec*)
   
/home/dcb38/gcc/working/gcc/../../trunk.20210101/gcc/tree-ssa-sccvn.cc:1144

The bug first seems to appear sometime between g:48207a5f00d6ae7c
and g:39d989022dd0eacf.

[Bug fortran/113885] New: ice in gimplify_expr, at gimplify.cc:18658

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 113885
   Summary: ice in gimplify_expr, at gimplify.cc:18658
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 57392
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57392=edit
F90 source code

The attached code, from the flang test suite, does this with recent gcc trunk:

test $ ~/gcc/results/bin/gfortran -c -w
./Lower/HLFIR/elemental-call-with-finalization.f90
./Lower/HLFIR/elemental-call-with-finalization.f90:27:13:

   27 |   x = elem(x)
  | ^
internal compiler error: in gimplify_expr, at gimplify.cc:18658
xb99d5e gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/dcb38/gcc/working/gcc/../../trunk.20210101/gcc/gimplify.cc:18658
0xb857bd gimplify_stmt(tree_node**, gimple**)
/home/dcb38/gcc/working/gcc/../../trunk.20210101/gcc/gimplify.cc:7480
0xb8fdd5 gimplify_modify_expr(tree_node**, gimple**, gimple**, bool)
/home/dcb38/gcc/working/gcc/../../trunk.20210101/gcc/gimplify.cc:6377
0xb8fdd5 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)


The flang test suite is at:

https://github.com/llvm/llvm-project/tree/main/flang/test

[Bug fortran/113866] New: ice in generic_simplify_COND_EXPR

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 113866
   Summary: ice in generic_simplify_COND_EXPR
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 57380
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57380=edit
F90 source code

For this F90 source code file:

./Lower/HLFIR/bindc-assumed-length.f90

from the flang testsuite at

https://github.com/llvm/llvm-project/tree/main/flang/test

when compiled by recent gfortran, does this:

est $ ~/gcc/results.20240210.asan.ubsan/bin/gfortran -c -w
./Lower/HLFIR/bindc-assumed-length.f90
./Lower/HLFIR/bindc-assumed-length.f90:39:29:

   39 |   call bindc_optional(c1, c3)
  | 1
internal compiler error: Segmentation fault
0xf57d79 crash_signal(int)
/home/dcb38/gcc/working/gcc/../../trunk.20210101/gcc/toplev.cc:317
0x17bdf2f generic_simplify_COND_EXPR(unsigned int, tree_code, tree_node*,
tree_node*, tree_node*, tree_node*)
/home/dcb38/gcc/working/gcc/generic-match-4.cc:0
0xaecbf8 fold_ternary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*, tree_node*)

Here is a valgrind version of the same gfortran providing some clues:

test $ ~/gcc/results.20240210.valgrind/bin/gfortran -c -w
./Lower/HLFIR/bindc-assumed-length.f90
==3757741== Invalid read of size 2
==3757741==at 0x17793EF: generic_simplify_COND_EXPR(unsigned int,
tree_code, tree_node*, tree_node*, tree_node*, tree_node*)
(generic-match-4.cc:10061)
==3757741==by 0xB082BB: fold_ternary_loc(unsigned int, tree_code,
tree_node*, tree_node*, tree_node*, tree_node*) (fold-const.cc:13144)

[Bug fortran/113846] ice in fold_convert_loc, at fold-const.cc:2757

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #2 from David Binderman  ---
>From the same flang test suite, the following files seem to crash in the
same routine:

./Lower/HLFIR/structure-constructor.f90
./Lower/HLFIR/convert-mbox-to-value.f90
./Lower/polymorphic-temp.f90
./Lower/structure-constructors-alloc-comp.f90

It might be worth making sure any fix for this bug also fixes these four.

[Bug fortran/113846] New: ice in fold_convert_loc, at fold-const.cc:2757

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 113846
   Summary: ice in fold_convert_loc, at fold-const.cc:2757
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 57369
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57369=edit
F90 source code

>From the flang test suite at
https://github.com/llvm/llvm-project/tree/main/flang/test,
file ./Lower/HLFIR/elemental-polymorphic-merge.f90, does this with recent
gfortran:

test $ ~/gcc/results.20240208.asan.ubsan/bin/gfortran -c
./Lower/HLFIR/elemental-polymorphic-merge.f90
./Lower/HLFIR/elemental-polymorphic-merge.f90:10:20:

   10 |   r = merge(x, y, m)
  |1
internal compiler error: in fold_convert_loc, at fold-const.cc:2757
0xac84c2 fold_convert_loc(unsigned int, tree_node*, tree_node*)
/home/dcb38/gcc/working/gcc/../../trunk.20210101/gcc/fold-const.cc:2757
0x8ade4d gfc_conv_intrinsic_merge(gfc_se*, gfc_expr*)
   
/home/dcb38/gcc/working/gcc/../../trunk.20210101/gcc/fortran/trans-intrinsic.cc:7589

[Bug fortran/113845] New: ice in gfc_get_array_ss

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 113845
   Summary: ice in gfc_get_array_ss
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 57368
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57368=edit
F90 source code

>From the flang test suite at
https://github.com/llvm/llvm-project/tree/main/flang/test, file
./Lower/HLFIR/elemental-intrinsics.f90 does this with recent gfortran:

test $ ~/gcc/results.20240208.asan.ubsan/bin/gfortran -c -O1
./Lower/HLFIR/elemental-intrinsics.f90 
gfortran: internal compiler error: Segmentation fault signal terminated program
f951
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.
test $ 

gdb on f951 says:

#0  0x0228f236 in xcalloc (nelem=1, elsize=696)
at ../../trunk.20210101/libiberty/xmalloc.c:158
#1  0x008588ec in gfc_get_array_ss (
next=0x3221ae8 , expr=0x9423af0, dimen=1, 
type=GFC_SS_SECTION) at ../../trunk.20210101/gcc/fortran/trans-array.cc:724
#2  gfc_walk_array_ref (ss=0x3221ae8 , expr=0x9423af0, 
ref=0x9423c20) at ../../trunk.20210101/gcc/fortran/trans-array.cc:11750
#3  0x00858cd8 in gfc_walk_elemental_function_args (
ss=0x3221ae8 , arg=0x9423a90, 
intrinsic_sym=0x77a66610, type=)
at ../../trunk.20210101/gcc/fortran/trans-array.cc:12015

[Bug fortran/113823] ice in gfc_get_element_type, at fortran/trans-types.cc:1286

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #6 from David Binderman  ---
(In reply to Steve Kargl from comment #5)
> That's not what I meant.  There is no bug1006.f90 in
> the llvm-project repo.  What is the actual URL to the
> actual testcase?  It should look something like
> 
> https://github.com/llvm/llvm-project/tree/main/flang/test/bug1006.f90

bug1006.f90 is my local file name for it. 

It is just a copy of the original file
Lower/HLFIR/array-ctor-derived.f90 in the flang test suite.

That has an URL of 
https://github.com/llvm/llvm-project/tree/main/flang/test/Lower/HLFIR/array-ctor-derived.f90

[Bug fortran/113823] ice in gfc_get_element_type, at fortran/trans-types.cc:1286

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #4 from David Binderman  ---
(In reply to kargl from comment #3)
> If you do post the others, is it possible to include a URL to LLVM
> repository?  This will allow us to give proper credit for the code.

https://github.com/llvm/llvm-project/

[Bug fortran/113823] ice in gfc_get_element_type, at fortran/trans-types.cc:1286

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #2 from David Binderman  ---
(In reply to kargl from comment #1)
> (In reply to David Binderman from comment #0)
> >
> > This is the second ice from the flang test suite. 
> 
> If you're keep score
> https://discourse.llvm.org/t/proposal-rename-flang-new-to-flang/69462/57

Interesting. Thanks.

32 more ice to be reported. There are probably some duplicates
amongst that group.

Hopefully I can report most or all of these before the next release.

[Bug fortran/113823] New: ice in gfc_get_element_type, at fortran/trans-types.cc:1286

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 113823
   Summary: ice in gfc_get_element_type, at
fortran/trans-types.cc:1286
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 57355
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57355=edit
F90 source code

The attached F90 code does this with trunk:

foundBugs $ ../results.20240206.asan.ubsan/bin/gfortran -c bug1006.f90
bug1006.f90:43:31:

   43 | call takes_simple([s1, s2])
  |   1
internal compiler error: in gfc_get_element_type, at
fortran/trans-types.cc:1286
0x8f8b51 gfc_get_element_type(tree_node*)
   
/home/dcb38/gcc/working/gcc/../../trunk.20210101/gcc/fortran/trans-types.cc:1286

This is the second ice from the flang test suite. 
bug1006.f90 is a copy of Lower/HLFIR/array-ctor-derived.f90.

[Bug c/113817] New: ice in move_early_exit_stmts

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 113817
   Summary: ice in move_early_exit_stmts
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

For this C code:

char enc_int_dst_orig;
long main_val;
char main_buf[20];
char *enc_int(char *dst, char *end, long value) {
  while (value)
if (dst < end)
  *dst++ = value >>= 7;
else
  return _int_dst_orig;
  *dst = 7;
}
void main() { enc_int(main_buf, main_buf + sizeof(main_buf), main_val); }

compiles ok as follows:

$ /home/dcb38/gcc/results.20240202.asan.ubsan/bin/gcc -c -O3 -march=znver3
~/cvise/bug1005.c
$

But a few days later:

$ /home/dcb38/gcc/results.20240205.asan.ubsan/bin/gcc -c -O3 -march=znver3
~/cvise/bug1005.c
during GIMPLE pass: vect
/home/dcb38/cvise/bug1005.c: In function ‘main’:
/home/dcb38/cvise/bug1005.c:12:6: internal compiler error: Segmentation fault
   12 | void main() { enc_int(main_buf, main_buf + sizeof(main_buf), main_val); 
}
  |  ^~~~
0xed44e9 crash_signal(int)
/home/dcb38/gcc/working/gcc/../../trunk.20210101/gcc/toplev.cc:317
0x1186bd3 gsi_prev(gimple_stmt_iterator*)
../../trunk.20210101/gcc/gimple-iterator.h:236
0x1186bd3 move_early_exit_stmts(_loop_vec_info*)
   
/home/dcb38/gcc/working/gcc/../../trunk.20210101/gcc/tree-vect-loop.cc:1
1804

$ /home/dcb38/gcc/results.20240202.asan.ubsan/bin/gcc -v 2>&1 | grep exp
gcc version 14.0.1 20240202 (experimental) (639bd5e9b759a6d7)
$ /home/dcb38/gcc/results.20240205.asan.ubsan/bin/gcc -v 2>&1 | grep exp
gcc version 14.0.1 20240205 (experimental) (5b281946c4b51132)

The git range is 40 commits.

[Bug fortran/113799] New: gfc_replace_expr: double free detected ?

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 113799
   Summary: gfc_replace_expr: double free detected ?
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 57350
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57350=edit
F90 source code

For the attached F90 source code, I get this 

test $ ~/gcc/results/bin/gfortran -c ./Evaluate/folding20.f90
free(): double free detected in tcache 2
f951: internal compiler error: Aborted
0xf581f9 crash_signal(int)
/home/dcb38/gcc/working/gcc/../../trunk.20210101/gcc/toplev.cc:317
0x7658aa gfc_replace_expr(gfc_expr*, gfc_expr*)
   
/home/dcb38/gcc/working/gcc/../../trunk.20210101/gcc/fortran/expr.cc:640
0x7658aa simplify_intrinsic_op(gfc_expr*, int)
   
/home/dcb38/gcc/working/gcc/../../trunk.20210101/gcc/fortran/expr.cc:1324
0x7658aa gfc_simplify_expr(gfc_expr*, int)
   
/home/dcb38/gcc/working/gcc/../../trunk.20210101/gcc/fortran/expr.cc:2317

The source code is from the flang testsuite in clang.

The bug has existed since sometime before 20240107.

[Bug c++/113786] New: cppcheck: return value from find_if not properly checked ?

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 113786
   Summary: cppcheck: return value from find_if not properly
checked ?
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Consider the following newish C++ code:

#include 
#include 
#include 

int main()
{
auto is_even = [](int i) { return i % 2 == 0; };

for (auto const& w : {std::array{3, 1, 4}, {1, 3, 5}})
if (std::find_if(begin(w), end(w), is_even))
std::cout << "w contains an even number " << '\n';
else
std::cout << "w does not contain even numbers\n"; 
}

Here is static analyser cppcheck finding the problem with the find_if:

bug1003.cc:11:13: warning: Suspicious condition. The result of find() is an
iterator, but it is not properly checked. [stlIfFind]

Recent Gcc and clang have little to say:

Alphasrc $ ~/gcc/results/bin/g++ -g -O2 -Wall -Wextra -pedantic
-D_FORTIFY_SOURCE=3 bug1003.cc
Alphasrc $ ~/llvm/results/bin/clang++ -g -O2 -Wall -Wextra -pedantic
-D_FORTIFY_SOURCE=3 bug1003.cc
Alphasrc $ 

I guess any C++ STL function that returns something non-zero (in this case
end(w) )
on error is liable to this problem.

I found this problem in the source code of flang, the clang Fortran compiler,
so it does occur in practice.

[Bug c/113727] csmith: differences from nothing to -O1

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #11 from David Binderman  ---
Created attachment 57310
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57310=edit
C source code

[Bug c/113727] csmith: differences from nothing to -O1

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #10 from David Binderman  ---
(In reply to Sam James from comment #7)
> Can you try produce a testcase without UB please?

I have some partly reduced code that seems to have no UB.

cvise $ ~/gcc/results/bin/gcc -w -fsanitize=address,undefined bug1002.c
cvise $ ./a.out 1 > 0
cvise $ ~/gcc/results/bin/gcc -w -fsanitize=address,undefined -O1 bug1002.c
cvise $ ./a.out 1 > 1
cvise $ diff 0 1
469c469
< ...checksum after hashing g_994.f3 : 5F99C263
---
> ...checksum after hashing g_994.f3 : 3D4A5D24
cvise $

[Bug c/113727] csmith: differences from nothing to -O1

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #6 from David Binderman  ---
As expected:

trunk.20210101 $ git bisect good 35b5bb475375dba4
6decda1a35be5764101987c210b5693a0d914e58 is the first bad commit
commit 6decda1a35be5764101987c210b5693a0d914e58
Author: Richard Biener 
Date:   Thu Oct 12 11:34:57 2023 +0200

tree-optimization/111779 - Handle some BIT_FIELD_REFs in SRA

[Bug c/113727] csmith: differences from nothing to -O1

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #5 from David Binderman  ---
(In reply to David Binderman from comment #4)
> Current range seems to be g:578aa2f80056175b .. g:328745607c5d403a,
> some 155 commits.

Current range seems to be g:0f40e59f193f96f1 to g:6decda1a35be5764.

Of those 5 commits, 3 are for RISC-V and look unrelated and these two:

g:6decda1a35be5764101987c210b5693a0d914e58
g:35b5bb475375dba4ea9101d6db13a6012c4e84ca

look likely candidates, both by Richard. Adding Richard for their opinion.

My first attempt at a reduction didn't work. 
I will have another go sometime over the weekend.

[Bug c/113727] csmith: differences from nothing to -O1

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #4 from David Binderman  ---
(In reply to David Binderman from comment #3)
> (In reply to David Binderman from comment #2)
> > I have a bisection running too. I am trying out g:0f2e2080685e7509
> 
> That seems bad. Trying g:328745607c5d403a.

Current range seems to be g:578aa2f80056175b .. g:328745607c5d403a,
some 155 commits.

[Bug c/113727] csmith: differences from nothing to -O1

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #3 from David Binderman  ---
(In reply to David Binderman from comment #2)
> I have a bisection running too. I am trying out g:0f2e2080685e7509

That seems bad. Trying g:328745607c5d403a.

[Bug c/113727] csmith: differences from nothing to -O1

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #2 from David Binderman  ---
I have a bisection running too. I am trying out g:0f2e2080685e7509

[Bug c/113727] New: csmith: differences from nothing to -O1

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 113727
   Summary: csmith: differences from nothing to -O1
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 57298
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57298=edit
C source code

The attached C code seems to produce different answers
between no optimisation flags and -O1:

foundBugs $ ../results/bin/gcc -w bug1002.c
foundBugs $ valgrind -q ./a.out 1 > 0
foundBugs $ ../results/bin/gcc -w -O1 bug1002.c
foundBugs $ valgrind -q ./a.out 1 > 1
foundBugs $ diff 0 1 
469,478c469,478
< ...checksum after hashing g_994.f3 : 5F99C263
< ...checksum after hashing g_994.f4 : 6E61EEE1
< ...checksum after hashing g_994.f5 : 8A4973F3
< ...checksum after hashing g_994.f6 : 1A47F5E1
< ...checksum after hashing g_994.f7 : CD2C240E
< ...checksum after hashing g_994.f8 : 7E61A9F
< ...checksum after hashing g_1368 : 74B15A31
< ...checksum after hashing g_1659 : 322B1FCB
< ...checksum after hashing g_1720 : 65F2763C
< checksum = 65F2763C
---
> ...checksum after hashing g_994.f3 : 3D4A5D24
> ...checksum after hashing g_994.f4 : 23E1696C
> ...checksum after hashing g_994.f5 : B115BFA4
> ...checksum after hashing g_994.f6 : E3A4BBDA
> ...checksum after hashing g_994.f7 : D44B3E01
> ...checksum after hashing g_994.f8 : 656901A2
> ...checksum after hashing g_1368 : 3B45689
> ...checksum after hashing g_1659 : EBA715C1
> ...checksum after hashing g_1720 : BDD5FC31
> checksum = BDD5FC31

I have a reduction running. 

The bug first seems to occur sometime between dates 20231001 and 20231119. 
Git hashes are g:5f3da480e7541a9c and eaeaad3fcac4d7a3.

[Bug c++/81271] gcc/cp/lex.c:116: wrong condition ?

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #5 from David Binderman  ---
(In reply to Jason Merrill from comment #4)
> What tool did this warning come from?

Looks like cppcheck to me.

[Bug c/113561] New: yet more verify_ssa fails

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 113561
   Summary: yet more verify_ssa fails
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

For this C source code:

char LZ4_decompress_generic_source;
void LZ4_decompress_generic_endOnInput() {
  char *ip = _decompress_generic_source;
  while (1) {
long length;
if (length) {
  unsigned s;
  do {
if (ip > -5)
  goto _output_error;
s = *ip++;
length += s;
  } while (s);
}
  }
_output_error:
}

cvise $ /home/dcb38/gcc/results.20240119.asan.ubsan/bin/gcc -c -w -O3 bug1001.c
cvise $ /home/dcb38/gcc/results.20240119.asan.ubsan/bin/gcc -c -w -O3
-march=znver3 bug1001.c
bug1001.c: In function ‘LZ4_decompress_generic_endOnInput’:
bug1001.c:2:6: error: definition in block 7 does not dominate use in block 5
2 | void LZ4_decompress_generic_endOnInput() {
  |  ^

The bug first seems to exist sometime between g:484f48f03cf9a382
and g:5a22bb250d8f4ad2

[Bug c/113555] Yet another failure in verify_ssa

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #2 from David Binderman  ---
For the first source code, the bug seems to exist sometime between 20231119
and 20231227.

Git hashes are g:eaeaad3fcac4d7a3 and g:f19ceb2d49afdfa5

Please ignore the second source code - it is a separate bug.

[Bug c/113555] Yet another failure in verify_ssa

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #1 from David Binderman  ---
Second test case:

char LZ4_decompress_generic_source;
void LZ4_decompress_generic_endOnInput() {
  char *ip = _decompress_generic_source;
  while (1) {
long length;
if (length) {
  unsigned s;
  do {
if (ip > -5)
  goto _output_error;
s = *ip++;
length += s;
  } while (s);
}
  }
_output_error:
}

cvise $ ~/gcc/results/bin/gcc -c -w -O3 bug1000B.c
cvise $ ~/gcc/results/bin/gcc -c -w -O3 -march=znver3 bug1000B.c
bug1000B.c: In function ‘LZ4_decompress_generic_endOnInput’:
bug1000B.c:2:6: error: definition in block 7 does not dominate use in block 5
2 | void LZ4_decompress_generic_endOnInput() {
  |  ^

[Bug c/113555] New: Yet another failure in verify_ssa

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 113555
   Summary: Yet another failure in verify_ssa
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Today's gcc trunk says:

$ ~/gcc/results.20240123.asan.ubsan/bin/gcc -c -O3 -w bug1000.c
$ ~/gcc/results.20240123.asan.ubsan/bin/gcc -c -O3 -w -march=znver3 bug1000.c
bug1000.c: In function ‘net_roa_check_ip4_trie_tab’:
bug1000.c:20:6: error: definition in block 4 does not dominate use in block 5
   20 | void net_roa_check_ip4_trie_tab() {
  |  ^~
for SSA_NAME: vect__14.32_111 in statement:
vect__14.32_112 = PHI 
PHI argument
vect__14.32_111
for PHI node
vect__14.32_112 = PHI 
during GIMPLE pass: vect
bug1000.c:20:6: internal compiler error: verify_ssa failed

Reduced source code is

int ip4_getbit_a, ip4_getbit_pos, ip4_clrbit_pos;
void ip4_clrbit(int *a) { *a &= ip4_clrbit_pos; }
typedef struct {
  char pxlen;
  int prefix
} net_addr_ip4;
void fib_get_chain();
int trie_match_longest_ip4();
int trie_match_next_longest_ip4(net_addr_ip4 *n) {
  int __trans_tmp_1;
  while (n->pxlen) {
n->pxlen--;
ip4_clrbit(>prefix);
__trans_tmp_1 = ip4_getbit_a >> ip4_getbit_pos;
if (__trans_tmp_1)
  return 1;
  }
  return 0;
}
void net_roa_check_ip4_trie_tab() {
  net_addr_ip4 px0;
  for (int _n = trie_match_longest_ip4(); _n;
   _n = trie_match_next_longest_ip4())
fib_get_chain();
}

The bug seems to have existed since at least 20231227.

On a side note, 1000 bug reports and enhancement requests in 11 years.

[Bug other/94629] 10 issues located by the PVS-studio static analyzer

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #29 from David Binderman  ---
(In reply to Martin Jambor from comment #28)
> And is there already a bugzilla bug about these (or should I create one)?

Done. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113528

[Bug c/113528] New: gcc-13 meets PVS-studio

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 113528
   Summary: gcc-13 meets PVS-studio
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

The following article describes using static analyser PVS-studio to find
potential problems in gcc-13.

https://pvs-studio.com/en/blog/posts/cpp/1067/

It might be worth checking the ten problems listed. It might also be
worth checking that gcc trunk has no new problems, compared to gcc-13.

[Bug other/94629] 10 issues located by the PVS-studio static analyzer

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #27 from David Binderman  ---
The original article checked gcc-10.
gcc-13 is checked in the following article:

https://pvs-studio.com/en/blog/posts/cpp/1067/

I suspect it would be most unwise if any release of gcc after 13 
introduced new bugs that were known to pvs-studio.

[Bug middle-end/113396] [13/14 Regression] csmith: differences from -O2 to -O3

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #10 from David Binderman  ---
Created attachment 57117
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57117=edit
C source code

After many hours, cvise appears incapable of reducing the code 
much beyond this version.

[Bug middle-end/113396] [13/14 Regression] csmith: differences from -O2 to -O3

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

 CC||aldyh at redhat dot com

--- Comment #8 from David Binderman  ---
As expected:

$ git bisect good fc259b522c0f8b7bbca8e7adcd3da63330094a34
8c99e307b20c502e55c425897fb3884ba8f05882 is the first bad commit
commit 8c99e307b20c502e55c425897fb3884ba8f05882
Author: Aldy Hernandez 
Date:   Sat Jun 25 18:58:02 2022 -0400

Over to Aldy for their best opinion.

[Bug middle-end/113396] [13/14 Regression] csmith: differences from -O2 to -O3

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #7 from David Binderman  ---
Current range seems to be g:54a5f478487a955c3ffaec3e9164a72599bc1cfb ..
g:1edfc8f2d3307a3ffa077a605f432832d7715462, which is 4 commits.

Of those 4, this one

commit 8c99e307b20c502e55c425897fb3884ba8f05882
Author: Aldy Hernandez 
Date:   Sat Jun 25 18:58:02 2022 -0400

looks a likely candidate.

[Bug middle-end/113396] [13/14 Regression] csmith: differences from -O2 to -O3

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #6 from David Binderman  ---
Reduced bisect range seems to be g:2c11662391bafd74c9d19bf7626b7bcef41c1323 ..
g:9e0d5db3e04afd2d030ace4ccb5c1af5e9f05a8f, which is 462 commits.

[Bug middle-end/113396] [13/14 Regression] csmith: differences from -O2 to -O3

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #5 from David Binderman  ---
Bisect range seems to be g:e03a0a4d73a478928b26213363fa5dbb9fc8695f ..
g:4e1914625dec4aa09a5671c6294e877dbf4518f5, which is 1850 commits.

I will continue the bisection.

[Bug middle-end/113396] [13/14 Regression] csmith: differences from -O2 to -O3

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #4 from David Binderman  ---
foundBugs $ ../results.20220116/bin/gcc -w -O2 bug998.c
foundBugs $ ./a.out
checksum = 77A231E6
foundBugs $ ../results.20220116/bin/gcc -w -O3 bug998.c
foundBugs $ ./a.out
checksum = 77A231E6
foundBugs $ ../results.20230205/bin/gcc -w -O2 bug998.c
foundBugs $ ./a.out
checksum = 77A231E6
foundBugs $ ../results.20230205/bin/gcc -w -O3 bug998.c
foundBugs $ ./a.out
checksum = 130B5204
foundBugs $ 

So it goes wrong sometime between g:90045c5df5b3c8853e7740fb72a11aead1c489bb
and g:d042f118798ae0648b45f97e63b0e5ab7c82c8ef, a distance of 7403 commits.

[Bug c/113396] csmith: differences from -O2 to -O3

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #3 from David Binderman  ---
Created attachment 57089
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57089=edit
C source code

Partly reduced C source code.

[Bug c/113396] csmith: differences from -O2 to -O3

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #2 from David Binderman  ---
The bug seems to exist from sometime before
g:d042f118798ae0648b45f97e63b0e5ab7c82c8ef, dated 20230205.

[Bug c/113396] csmith: differences from -O2 to -O3

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #1 from David Binderman  ---
foundBugs $ ~/gcc/results/bin/gcc -w  -O2  bug998.c -o two.exe
foundBugs $ ~/gcc/results/bin/gcc -w  -O3  bug998.c -o three.exe
foundBugs $ ./two.exe 1 > two.out
foundBugs $ ./three.exe 1 > three.out
foundBugs $ diff two.out three.out  | head -20
510,520c510,520
< ...checksum after hashing g_179.f2 : F8C8E936
< ...checksum after hashing g_179.f3 : 22C7AEC4
< ...checksum after hashing g_179.f4 : E057A6AE
< ...checksum after hashing g_179.f5 : 494E34F0
< ...checksum after hashing g_179.f6 : 72F55A7C
< ...checksum after hashing g_179.f7 : 9B53D63F
< ...checksum after hashing g_179.f8 : DD10C49F
< ...checksum after hashing g_179.f9 : 979E03A7
< ...checksum after hashing g_195 : 63EDBCE7
< ...checksum after hashing g_196 : C1F2B26B
< ...checksum after hashing g_226[i][j] : 835FC1
---
> ...checksum after hashing g_179.f2 : A0B13872
> ...checksum after hashing g_179.f3 : A6EAB221
> ...checksum after hashing g_179.f4 : 744D7BAB
> ...checksum after hashing g_179.f5 : 4D71F83C
> ...checksum after hashing g_179.f6 : 54EDEE43
> ...checksum after hashing g_179.f7 : B280A60F
> ...checksum after hashing g_179.f8 : ECCE643D
foundBugs $

[Bug c/113396] New: csmith: differences from -O2 to -O3

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 113396
   Summary: csmith: differences from -O2 to -O3
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 57082
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57082=edit
C source code

The attached Csmith generated code does this:

foundBugs $ ~/gcc/results/bin/gcc -w bug998.c
foundBugs $ valgrind -q ./a.out
checksum = 77A231E6
foundBugs $ ~/gcc/results/bin/gcc -w -O2 bug998.c
foundBugs $ valgrind -q ./a.out
checksum = 77A231E6
foundBugs $ ~/gcc/results/bin/gcc -w -O3 bug998.c
foundBugs $ valgrind -q ./a.out
checksum = 130B5204
foundBugs $ ~/gcc/results/bin/gcc -w -O3 -fno-strict-aliasing
-fno-loop-interchange bug998.c
foundBugs $ valgrind -q ./a.out
checksum = 130B5204
foundBugs $

[Bug tree-optimization/113373] [14 regression] ICE in verify_ssa

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #3 from David Binderman  ---
Reduced C++ code seems to be:

void __assert_fail(char *, char *, int, const char *)
__attribute__((__noreturn__));
template  struct asCArray {
  asCArray(int);
  T [](unsigned);
  T *array;
  int length;
};
template  T ::operator[](unsigned index) {
  index < length ? void() : __assert_fail("", "", 8, __PRETTY_FUNCTION__);
  return array[index];
}
unsigned asCReaderTranslateFunction_bc_1;
int asCReaderTranslateFunction_bcLength;
void asCReaderTranslateFunction() {
  asCArray bcSizes(asCReaderTranslateFunction_bcLength);
  int offset, size;
  for (int num; offset--; num++)
size += bcSizes[num];
  asCReaderTranslateFunction_bc_1 = size;
}

[Bug tree-optimization/113373] [14 regression] ICE in verify_ssa

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #2 from David Binderman  ---
Reducing ...

[Bug tree-optimization/113374] [14 regression] ICE in find_uses_to_rename_use

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #1 from David Binderman  ---
trunk.20210101 $ ~/gcc/results.20240112.asan.ubsan/bin/gcc -v 2>&1 | grep exp
gcc version 14.0.0 20240112 (experimental) (72b3495dfdddc277) 
trunk.20210101 $ ~/gcc/results.20240113.asan.ubsan/bin/gcc -v 2>&1 | grep exp
gcc version 14.0.1 20240113 (experimental) (34a827039fabcf24) 
trunk.20210101 $ git log 72b3495dfdddc277..34a827039fabcf24 | grep -c "^commit"
52
trunk.20210101 $

[Bug tree-optimization/113373] [14 regression] ICE in verify_ssa

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #1 from David Binderman  ---
$  /home/dcb38/gcc/results.20231221.asan.ubsan/bin/g++  -v 2>&1 | grep exp
gcc version 14.0.0 20231221 (experimental) (514ea1df444ca7f6) 
$  /home/dcb38/gcc/results.20231227.asan.ubsan/bin/g++  -v 2>&1 | grep expgcc
version 14.0.0 20231227 (experimental) (f19ceb2d49afdfa5) 
$ git log 514ea1df444ca7f6..f19ceb2d49afdfa5 | grep -c "^commit"
83
$

[Bug c++/113374] New: new breakage in find_uses_to_rename_use

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 113374
   Summary: new breakage in find_uses_to_rename_use
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 57070
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57070=edit
C++ source code

In the last 24 hours or so, the attached code seems to have broken:

$ ~/gcc/results.20240112.asan.ubsan/bin/gcc -c -w -O3 -march=znver2 bug997.cc
$ ~/gcc/results.20240113.asan.ubsan/bin/gcc -c -w -O3 -march=znver2 bug997.cc
during GIMPLE pass: vect
bug997.cc: In member function ‘Botan::BER_Decoder&
Botan::BER_Decoder::decode(Botan::BigInt&, Botan::ASN1_Tag, Botan::ASN1_Tag)’:
bug997.cc:26093:14: internal compiler error: Segmentation fault
26093 | BER_Decoder& BER_Decoder::decode(BigInt& out,
  |  ^~~
0x11e8ad9 crash_signal(int)
../../trunk.20210101/gcc/toplev.cc:317
0x1388e28 find_uses_to_rename_use(basic_block_def*, tree_node*, bitmap_head**,
bitmap_head*)

[Bug c++/113373] New: ice in verify_ssa

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 113373
   Summary: ice in verify_ssa
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 57069
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57069=edit
C++ source code

Still some fallout from recent gcc trunk changes.

The attached code does this:

foundBugs $ /home/dcb38/gcc/results.20231221.asan.ubsan/bin/g++ -c -w -O3
-march=znver3 bug996.cc
foundBugs $ /home/dcb38/gcc/results.20231227.asan.ubsan/bin/g++ -c -w -O3
-march=znver3 bug996.cc
../sdk/angelscript/source/as_restore.cpp: In member function ‘void
asCReader::TranslateFunction(asCScriptFunction*)’:
../sdk/angelscript/source/as_restore.cpp:2824:6: error: definition in block 453
does not dominate use in block 457
for SSA_NAME: _1244 in statement:
size_1336 = PHI <_1244(457), 0(227)>
PHI argument
_1244
for PHI node
size_1336 = PHI <_1244(457), 0(227)>
during GIMPLE pass: vect
../sdk/angelscript/source/as_restore.cpp:2824:6: internal compiler error:
verify_ssa failed

[Bug tree-optimization/113137] [14 regression] Failed bootstrap with -O3 -march=znver2

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #14 from David Binderman  ---
(In reply to Tamar Christina from comment #13)
> Patch submitted

Two weeks have elapsed and the patch doesn't seem to appear in git.

Is it perhaps stuck somewhere ?

[Bug target/113045] armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #22 from David Binderman  ---
(In reply to Richard Earnshaw from comment #21)
> commit e75b54a2d932929a9b2e940c5aad1ef33a86c008
> Author: Richard Earnshaw 
> Date:   Thu Mar 22 17:54:55 2012 +
> 
> * lex.c (search_line_fast): Provide Neon-optimized version for ARM.

Is the optimization still worthwhile some 12 years later ?

[Bug tree-optimization/113178] [14 Regression] ice in find_uses_to_rename_use

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

 CC||tamar.christina at arm dot com

--- Comment #4 from David Binderman  ---
Reduced range seems to be g:0994ddd86f9c3d82 to g:a657c7e3518fcfc7.

All commits in this range are by Tamar.

[Bug tree-optimization/113178] [14 Regression] ice in find_uses_to_rename_use

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #3 from David Binderman  ---
After some bisection, range seems to be g:2902300340928989
to g:ed60b2868abdb793, a range of 21 commits.

[Bug tree-optimization/113178] [14 Regression] ice in find_uses_to_rename_use

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #2 from David Binderman  ---
The bug first seems to occur sometime between git:514ea1df444ca7f6
and git:f19ceb2d49afdfa5, a distance of 83 commits.

[Bug c++/113178] New: ice in find_uses_to_rename_use

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 113178
   Summary: ice in find_uses_to_rename_use
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

This C++ source code:

struct PixelWeight {
  int m_SrcStart;
  int m_Weights[];
};
struct CWeightTable {
  int *GetValueFromPixelWeight(PixelWeight *, int) const;
};
char ContinueStretchHorz_dest_scan;
struct CStretchEngine {
  bool ContinueStretchHorz();
  CWeightTable m_WeightTable;
};
int *CWeightTable::GetValueFromPixelWeight(PixelWeight *pWeight,
   int index) const {
  long __trans_tmp_1;
  if (index < pWeight->m_SrcStart)
return __trans_tmp_1 ? >m_Weights[pWeight->m_SrcStart] : nullptr;
}
bool CStretchEngine::ContinueStretchHorz() {
  {
PixelWeight pPixelWeights;
int dest_g_m;
for (int j; j; j++) {
  int pWeight = *m_WeightTable.GetValueFromPixelWeight(, j);
  dest_g_m += pWeight;
}
ContinueStretchHorz_dest_scan = dest_g_m;
  }
}

when compiled by recent gcc trunk, does this:

cvise $ ~/gcc/results.20231227.asan.ubsan/bin/g++ -c -O3 -w  bug995.cc
cvise $ ~/gcc/results.20231227.asan.ubsan/bin/g++ -c -O3 -w -march=znver3
bug995.cc
during GIMPLE pass: vect
bug995.cc: In member function ‘bool CStretchEngine::ContinueStretchHorz()’:
bug995.cc:19:6: internal compiler error: Segmentation fault
   19 | bool CStretchEngine::ContinueStretchHorz() {
  |  ^~
0x11e1b39 crash_signal(int)
../../trunk.20210101/gcc/toplev.cc:316
0x1381b98 find_uses_to_rename_use(basic_block_def*, tree_node*, bitmap_head**,
bitmap_head*)
../../trunk.20210101/gcc/tree-ssa-loop-manip.cc:414

[Bug c/113172] New: ice in move_early_exit_stmts

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 113172
   Summary: ice in move_early_exit_stmts
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

For this C code:

int tswchp_2;
short cpy_buf[8];
void ts_endcmd() {
  int i = 0;
  for (; i < 8 && i < tswchp_2; i++)
cpy_buf[i] = i;
}

compiled by recent gcc trunk, does this:

cvise $ ~/gcc/results/bin/gcc -c -O3  bug994.c
cvise $ ~/gcc/results/bin/gcc -c -O3 -march=znver3 bug994.c
during GIMPLE pass: vect
bug994.c: In function ‘ts_endcmd’:
bug994.c:3:6: internal compiler error: Segmentation fault
3 | void ts_endcmd() {
  |  ^
0xeeade9 crash_signal(int)
../../trunk.20210101/gcc/toplev.cc:316
0x11a8e63 gsi_prev(gimple_stmt_iterator*)
../../trunk.20210101/gcc/gimple-iterator.h:236
0x11a8e63 move_early_exit_stmts(_loop_vec_info*)
../../trunk.20210101/gcc/tree-vect-loop.cc:11807

[Bug tree-optimization/113144] [14 regression] ICE when building dpkg-1.21.15 in verify_dominators (error: dominator of 9 should be 48, not 12)

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #7 from David Binderman  ---
I see this one also, while building libmpg.

foundBugs $ ../results/bin/gcc -c -w -O3 bug993.c
foundBugs $ ../results/bin/gcc -c -w -O3 -march=znver3 bug993.c
src/libmpg123/format.c: In function ‘enc_chan_fit’:
src/libmpg123/format.c:188:12: error: dominator of 70 should be 206, not 3
src/libmpg123/format.c:188:12: error: dominator of 71 should be 206, not 3
during GIMPLE pass: vect
src/libmpg123/format.c:188:12: internal compiler error: in verify_dominators,
at dominance.cc:1194

[Bug tree-optimization/113137] [14 regression] Failed bootstrap with -O3 -march=znver2

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #8 from David Binderman  ---
I see this one also in a build of package LFSC.

$ ~/gcc/results/bin/gcc -c -w -O3 bug992.cc
foundBugs $ ~/gcc/results/bin/gcc -c -w -O3 -march=znver2 bug992.cc 
/home/dcb38/rpmbuild/BUILD/LFSC-bbc1798864dbc328092356d4c01f02ddc39ea6bd/src/code.cpp:
In function ‘Expr* read_code()’:
/home/dcb38/rpmbuild/BUILD/LFSC-bbc1798864dbc328092356d4c01f02ddc39ea6bd/src/code.cpp:112:7:
error: PHI node with wrong VUSE on edge from BB 114
  112 | Expr *read_code()
  |   ^
.MEM_824 = PHI <.MEM_1387(114)>
expected .MEM_1042

[Bug target/113045] armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #18 from David Binderman  ---
(In reply to Mark Wielaard from comment #17)
> I am surprised valgrind memcheck doesn't produce more output, normally it
> would tell you why & where it found the address invalid. 

The valgrind output I gave originally looks to be in the usual valgrind format
to me.
Perhaps you are assuming some other debugging tool like asan or ubsan ?

> I assume somehow
> valgrind memcheck believes it is reading past the end of a data buffer,
> while the code assumes this is fine because it will mask off the bits it
> won't use.

valgrind doesn't normally produce an error for copying around un-initialised
bytes.

However, it will produce an error if those bytes are used in a decision
like an if statement.

Your unconfirmed assumption agrees with mine, though.

[Bug target/113045] armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #15 from David Binderman  ---
(In reply to Jonathan Wakely from comment #12)
> Because otherwise I'm going to get blamed for every bug older than
> 2022-11-01!
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111270#c1

My apologies for this. AFAIK sheer fluke git produced your name twice.

I have extended my local history out to 20210101, nearly three years.
That should reduce the size of the problem and I now know where to
get full history.

[Bug target/113045] armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #14 from David Binderman  ---
(In reply to Andrew Pinski from comment #9)
> Does it work correctly without valgrind?

Yes. No one has yet attempted to reproduce my results.

vld1q_u8 is a 128 bit ARM hardware instruction.
I assume that the requirements for this instruction are
not being met in some way by some data.

Maybe a short string ?

[Bug tree-optimization/113069] gimple-ssa-sccopy.cc:143:12: warning: private field 'curr_generation' is not used [-Wunused-private-field]

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

 CC||fkastl at suse dot cz

--- Comment #1 from David Binderman  ---
git blame has this:

cd794c39610 (Filip Kastl 2023-12-14 11:29:31 +0100 143)   unsigned
curr_generation = 0;

Adding author for their opinion.

[Bug c/113069] New: gimple-ssa-sccopy.cc:143:12: warning: private field 'curr_generation' is not used [-Wunused-private-field]

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 113069
   Summary: gimple-ssa-sccopy.cc:143:12: warning: private field
'curr_generation' is not used [-Wunused-private-field]
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

>From today's build of gcc trunk with clang:

gcc $ grep curr_generation gimple-ssa-sccopy.cc 
  unsigned curr_generation = 0;
gcc $

[Bug target/113045] armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #7 from David Binderman  ---
I tried:

$ git fetch --shallow-since=1/1/2021

and the blame still has ^ on the front of it.

^abca670596 libcpp/lex.c  (Ian Lance Taylor  2020-12-31 11:23:30 -0800  869)  
/* Align the source pointer.  */
^abca670596 libcpp/lex.c  (Ian Lance Taylor  2020-12-31 11:23:30 -0800  870)  
misalign = (uintptr_t)s & 15;
^abca670596 libcpp/lex.c  (Ian Lance Taylor  2020-12-31 11:23:30 -0800  871)  
p = (const uint8_t *)((uintptr_t)s & -16);
^abca670596 libcpp/lex.c  (Ian Lance Taylor  2020-12-31 11:23:30 -0800  872)  
data = vld1q_u8 (p);

IMHO, most ARM bugs seem to land in the in-tray of Richard Sandiford.
Maybe Richard might recognise the code ?

[Bug target/113045] armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #6 from David Binderman  ---
(In reply to Jonathan Wakely from comment #4)
> That's what the ^ on the commit suggests is happening.

Righto.

> You can fix your history with:
> git fetch --unshallow

trunk.year $ git fetch --unshallow
remote: Enumerating objects: 1072084
^C
trunk.year $ 

It is not practical for me to download more than a million objects.

I think it would be a reasonable git enhancement if it could
handle the last (year, 3 years, 5 years, 10 years) of commits
without having to download 30+ years of commits.

[Bug target/113045] armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #5 from David Binderman  ---
(In reply to Jonathan Wakely from comment #3)
> I don't recognise that code, are you sure I wrote it?  d4ba3b369c did not
> touch that code.

No idea. git blame is known to lie from time to time. I am no
expert at it.

> Do you have a shallow clone, which happens to have my d4ba3b369c as the
> oldest commit?

No idea. I know the gcc project is over 30 years old and it is not
feasible for me to download the entire history, it is too large.

I have the last 18 months or so history and that's a whopping
3.8 Gig on it's own.

[Bug target/113045] armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

 CC||redi at gcc dot gnu.org

--- Comment #2 from David Binderman  ---
The source code in lex.cc is

  /* Align the source pointer.  */
  misalign = (uintptr_t)s & 15;
  p = (const uint8_t *)((uintptr_t)s & -16);
  data = vld1q_u8 (p);

git blame has 

^d4ba3b369c (Jonathan Wakely   2022-11-01 09:48:41 +  869)   /* Align the
source pointer.  */
^d4ba3b369c (Jonathan Wakely   2022-11-01 09:48:41 +  870)   misalign =
(uintptr_t)s & 15;
^d4ba3b369c (Jonathan Wakely   2022-11-01 09:48:41 +  871)   p = (const
uint8_t *)((uintptr_t)s & -16);
^d4ba3b369c (Jonathan Wakely   2022-11-01 09:48:41 +  872)   data =
vld1q_u8 (p);

Adding author of code for their opinion.