NCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
I just tried a bootstrap build with ASAN & UBSAN switched on.
I got:
working $ grep "run
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116793
--- Comment #7 from David Binderman ---
Created attachment 59172
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59172&action=edit
gzipped C++ source code
A second test case. It crashes in the same place as
the first. Both are from package
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116793
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
Created attachment 59165
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59165&action=edit
gzipped C++ source code
The attached code does this
$ /home/dcb
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
This morning's gcc trunk doesn't seem to build:
sed -n -e 's/^#define \([^_][a-zA-Z0-9_]*\).*/\1/p' \
-e 's/^#define \(_[^_A-Z][a-zA-Z0-9_]*\).*/
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
This C code:
char excmap_def_0;
int gg_strescape_i;
void gg_strescape() {
for (; gg_strescape_i; gg_strescape_i++)
switch ((unsigned char)gg_strescape_i)
case '\\'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116458
--- Comment #11 from David Binderman ---
I confirm that the fix works for me.
On a more subtle note, if two functions are strongly related,
would it be wise to have them in the same file with some comments
and maybe even some asserts to ensure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116458
--- Comment #4 from David Binderman ---
(In reply to Alexander Monakov from comment #3)
> David, thanks for Cc'ing me and for running Valgrind builds!
You are welcome. Its a normal weekly part of gcc testing for me.
> "Wobbly values" aside, ju
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116458
David Binderman changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Comme
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
>From today's valgrind build of gcc trunk:
/usr/bin/valgrind -q build/genmatch --generic \
--header=tmp-generic-match-auto.h --include=generic-match-auto.h \
../../t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116409
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
While C files usually have extension .c, C++ files use
.C or .cc or .cpp or .cxx.
Indeed in the gcc/testsuite, there is some variation:
$ cd $HOME/gcc/trunk/gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90781
--- Comment #7 from David Binderman ---
(In reply to Sam James from comment #6)
> If you're still hitting this, please upload good+bad copies of a sample of
> differing files (usually just 1 is enough but let's do 2 to be safe).
I think this one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115876
--- Comment #13 from David Binderman ---
The problem seems to be getting worse this week:
$ grep error: mk.2.out | grep runtime | sort | uniq -c | sort -rn
118 ../../trunk/gcc/ext-dce.cc:740:15: runtime error: shift exponent 64 is
too larg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116079
--- Comment #4 from David Binderman ---
Created attachment 58755
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58755&action=edit
C source code
Original code. Produced by csmith.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116079
David Binderman changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
This C source code:
char g_132;
int g_701, g_1189, func_24___trans_tmp_15, func_24_l_2691;
long func_24___trans_tmp_9;
int *func_24_l_2684;
void func_24() {
for (; g_1189;) {
g_132 = 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115876
--- Comment #12 from David Binderman ---
(In reply to David Binderman from comment #3)
> I find doing a bootstrap build with -O3 -march=native, with
> asan & ubsan, is a useful weekly sanity check.
Today's sanity check shows this problem:
$ gr
ty: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
Static analyser cppcheck says:
libcpp/macro.cc:528:19: style: Obsolete function 'asctime' called. It is
recommen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115876
--- Comment #3 from David Binderman ---
I find doing a bootstrap build with -O3 -march=native, with
asan & ubsan, is a useful weekly sanity check.
I only have access to arm & x86_64, so the option exists
to extend this testing to other machine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115893
--- Comment #2 from David Binderman ---
(In reply to Georg-Johann Lay from comment #1)
> So I think this is invalid as a GCC PR. When you are annoyed by that
> warning, use a texinfo version with a fix.
It looks like you missed my point. Maybe
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
A native build on x86_64 produces warnings about avr documentation.
It is unclear to me that avr documentation is any use to an X86_64 developer.
Suggest avoid processing any avr files
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
For a bootstrap with this configure script:
../trunk/configure \
--disable-multilib \
--disable-werror
t: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
This C code:
long set_work_pending_p;
_Bool set_work_pending() {
_Bool __trans_tmp_1;
long mask = 1, old = __atomic_fetch_or(&set_work_pending_p, mask, 0);
__trans_tmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115602
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
nt: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
>From today's build of gcc with clang:
working $ grep Wunused /tmp/0
../../trunk/gcc/analyzer/call-summary.cc:727:21: warning: unused variable
'summary_cast_reg' [-Wunuse
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
This C code:
char __vsprintf_internal_string;
unsigned long __vsprintf_internal_maxlen, __vsprintf_internal_end;
void __vsprintf_internal() {
if (__builtin_add_overflow((unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115386
--- Comment #9 from David Binderman ---
I tried a release build and it seemed fine to me:
foundBugs $ ../results.20240610.release/bin/gcc -c -w -g -O3 bug1034.c
foundBugs $
I guess if both asan & ubsan together cause a stack overflow, it migh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115386
--- Comment #7 from David Binderman ---
(In reply to Richard Biener from comment #6)
> Are you using a compiler with release checking?
No, with asan & ubsan.
I tried running cc1 under gdb and got this backtrace:
#0 0x00b54615 in g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107141
--- Comment #7 from David Binderman ---
(In reply to anlauf from comment #6)
> Judging from the name of the testcase this could be a quite different issue.
>
> Please open a separate PR and attach the source there.
Done. See https://gcc.gnu.or
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
Created attachment 58387
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58387&action=edit
f90 source code
>From the flang testsuite, file ./Lower/derived-type-finali
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115391
--- Comment #5 from David Binderman ---
(In reply to Jonathan Wakely from comment #1)
> You really shouldn't ever need to start again, you can just do:
>
> git fetch origin && git reset --hard origin/master
Thanks for the tip. After more than
Component: web
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
On the web page for git (gcc.gnu.org/git.html),
it might be worth mentioning that the current git repository
for mainline is about 3 million objects and about 1.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115386
--- Comment #5 from David Binderman ---
I tried a git bisect and got this:
$ git bisect good 6fa4b0135439d64c
30cfdd6ff56972d9d1b9dbdd43a8333c85618775 is the first bad commit
commit 30cfdd6ff56972d9d1b9dbdd43a8333c85618775
Author: Robin Dapp
D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115386
--- Comment #3 from David Binderman ---
(In reply to Sam James from comment #1)
> I think it runs out of stack.
I tried running it under gdb, and all I got were lots of stack frames,
so I agree with your best advice.
It doesn't seem all that r
: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
Created attachment 58380
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58380&action=edit
C source code
The attached code does this with recent gcc trunk:
foundBugs $ ../results/bin/gcc -
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
For this F90 source code:
! RUN: %python %S/test_errors.py %s %flang_fc1
! Check for semantic errors in ALLOCATE statements
subroutine C933_a(b1, ca3, ca4, cp3, cp3mold
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
For this Fortran source code:
! RUN: %python %S/test_errors.py %s %flang_fc1
! Test section subscript
subroutine p1
real :: a(10,10)
real :: b(5,5)
real :: c
integer :: n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107141
--- Comment #5 from David Binderman ---
Bit more detail from valgrind:
/Lower/derived-type-finalization.f90
==687074== Invalid read of size 8
==687074==at 0x856D97: gfc_class_len_get(tree_node*) (trans-expr.cc:273)
==687074==by 0x86F37B
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-linu
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 >> trans_9;
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: trans_class_vptr_len_assignment
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
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&action=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
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 $ ~/gcc/results.12
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
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
foundBug
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
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-pat
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 b
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&action=edit
C source code
Another test case.
foundBugs $ (ulimit -t 60; time ~/gcc/results/bin/gcc -c -w -O3 bug1023.c)
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 s
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 volat
++
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&action=edit
F90 source code
>From the flang
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&action=edit
F90 source code
>From
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&action=edit
F90 source code
>From the flang test suite at
https://github.com/llvm/llvm-project
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_66 += 1)
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&action=edit
F90 source code
The attached code, from the flang test suite, does th
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&action=edit
F90 source code
For this F90 source code file:
./Lower/HLFIR/bindc-assumed-len
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
: 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&action=edit
F90 source code
>From the flang test suite at
https://github.com
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&action=edit
F90 source code
>From the flang test suite at
https://github.com/llvm/llvm-project
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://github.com/llvm/llvm-
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/propo
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&action=edit
F90 source code
The attached F
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&action=edit
F90 source code
For the attached F90 source code, I get this
test
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&action=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 -fsanitize=address,
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113727
David Binderman changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Commen
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:328745607c
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
1 - 100 of 1345 matches
Mail list logo
