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
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:
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]
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
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:
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
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
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 =
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
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:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113956
David Binderman changed:
What|Removed |Added
Summary|ice in |[14 Regression] ice in
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 $
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
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
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
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
>
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
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)
real
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:
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
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.
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 \
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105533
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114234
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
---
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112938
David Binderman changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
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
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++
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107141
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107143
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
---
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.
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93814
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
--- Comment
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
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
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:
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
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
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:
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
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://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://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://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
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
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:
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
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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113727
David Binderman changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
---
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
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.
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
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
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.
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:
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
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
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
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
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:
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
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113396
David Binderman changed:
What|Removed |Added
CC||aldyh at redhat dot com
--- Comment
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
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.
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.
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 $
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.
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.
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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113373
--- Comment #2 from David Binderman ---
Reducing ...
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
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 |
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++
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:
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 ?
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):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113178
David Binderman changed:
What|Removed |Added
CC||tamar.christina at arm dot com
---
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.
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.
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++
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113144
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113137
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
---
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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113069
David Binderman changed:
What|Removed |Added
CC||fkastl at suse dot cz
--- Comment #1
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:
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.
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
David Binderman changed:
What|Removed |Added
CC||redi at gcc dot gnu.org
--- Comment
1 - 100 of 1060 matches
Mail list logo
