Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
For this C code:
$ more bug1029.c
typedef enum { SERVER_HELLO_DONE } message_type_t;
message_type_t handshakes[256][32], tls13_handshakes
: plugins
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
I have just tried a linux kernel build with this morning's gcc trunk compiler
and I got this:
home/dcb40b/gcc/results.20240530.asan.ubsan/lib/gcc/x86_64-pc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115243
--- Comment #3 from David Binderman ---
Looks fixed to me.
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
This reduced C code:
int g_6, func_11;
void func_8();
void func_39( int * p_41, long p_42)
{
char trans_9;
func_11 = trans_9 >= 32 ? p_42 : p_42 >>
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/
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
: 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, d
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
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 =
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
: 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
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
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 voi
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
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 {
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
++
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
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 tes
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 flan
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.
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93814
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
--- Comment
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_6
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
: 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 rec
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
f
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
: 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/llv
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/flan
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
>
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 d
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 &g
: 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/
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
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
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 optimisat
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.
: 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
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
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
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
: 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
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
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
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 |
++
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:
$ ~/
: 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 $ /h
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.
++
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
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, doe
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
: 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
1 - 100 of 2878 matches
Mail list logo
