https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117342
--- Comment #13 from David Binderman ---
(In reply to Sam James from comment #12)
> Please include the .s file referenced, config.log for the corresponding GCC,
> and `as --version`.
Problem seems to have gone away:
~ $ vi cq.cc
~ $ for i in /
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
Static analyser cppcheck says:
gcc/config/i386/i386-expand.cc:24871:35: warning: Identical condition
'!TARGET_AVX512BW', second
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118269
David Binderman changed:
What|Removed |Added
CC||rguenther at suse dot de
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118269
--- Comment #4 from David Binderman ---
Newest range is g:32a3f46ca5437261 .. g:a54aa75ab30eb1a1,
which is 30 commits.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118269
--- Comment #3 from David Binderman ---
(In reply to David Binderman from comment #2)
> gcc trunk seems to break sometime between g:3e89a4d5138,
> dated 2024-11-18 and g:e1009b3de2d, dated 2024-12-02.
>
> This is 476 commits. I will run a bisec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118269
--- Comment #2 from David Binderman ---
gcc trunk seems to break sometime between g:3e89a4d5138,
dated 2024-11-18 and g:e1009b3de2d, dated 2024-12-02.
This is 476 commits. I will run a bisection.
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
For this reduced C code:
cvise $ more bug1073.c
short g_113;
int func_1_l_1273, func_1_l_1370, func_1_l_1258;
void func_1() {
int
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
Static analyser cppcheck says:
gcc/lto-ltrans-cache.cc:312:44: performance: Function parameter 'checksum'
should be passe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118097
--- Comment #22 from David Binderman ---
(In reply to Andrew Pinski from comment #21)
> Try -fno-ipa-cp
As expected, that avoids the problem too:
foundBugs $ ../results/bin/gcc -O1 -w bug1071.c && ./a.out 1 > /tmp/0
foundBugs $ ../results/bin/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118097
--- Comment #20 from David Binderman ---
>From the See also bug report, # 118138,
I tried out -fno-inline and, for the two test cases here,
the problem seemed to go away.
foundBugs $ ../results/bin/gcc -O1 -w bug1071.c && ./a.out 1 > /tmp/0
fou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118097
--- Comment #17 from David Binderman ---
(In reply to Xi Ruoyao from comment #12)
> AFAIK -w suppresses -Werror=uninitialized.
-w also appears to switch off -Werror=overflow.
This makes csmith a lot less useful.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118097
--- Comment #15 from David Binderman ---
For the first test case, the reduced code seems to be:
void printf(...);
int crc32_tab[256];
int crc32_context = 4294967295, g_27, g_64, g_90 = 3, func_2___trans_tmp_4,
main_i, main_j, main_l_1486_0_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118097
David Binderman changed:
What|Removed |Added
CC||mjambor at suse dot cz
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118097
--- Comment #13 from David Binderman ---
(In reply to David Binderman from comment #11)
> I have a bisection running.
Current bisect range seems to be g:7f4f49687b1f1b7a .. g:40e5636e086e51f5
This is 22 commits. Most of it seems to be RISC-V r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118097
--- Comment #11 from David Binderman ---
Created attachment 59917
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59917&action=edit
C source code
Second test case from more runs of csmith.
It has the same fault in the same git range.
I ha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118097
--- Comment #10 from David Binderman ---
(In reply to Sam James from comment #9)
> Ah, sorry, I see it on the original with -O2. I don't see it on the reduced
> one (though it was invalid anyway). OK.
It looks as if my reduction was invalid. My
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118097
--- Comment #6 from David Binderman ---
(In reply to Sam James from comment #3)
> ... ditto the original. So maybe fixed already?
I think not. I just checked today's gcc trunk and the problem
seems to still exist in the original code.
The git
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118097
--- Comment #1 from David Binderman ---
Reduced C code:
void printf(...);
int crc32_tab[256];
int crc32_context = 4294967295, g_27, g_64, g_90 = 3, func_2___trans_tmp_4,
main_i, main_j;
int *g_26 = &g_27;
char g_76 = 232;
void crc32_byte(ch
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
Created attachment 59901
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59901&action=edit
C source code
For the attached C code, from csmith:
foundBugs $ /home/dcb40b/gcc/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117258
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117893
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117724
--- Comment #11 from David Binderman ---
(In reply to Andrew Pinski from comment #10)
> That is a different issue unrelated to this issue here can you file it
> seperately?
Done:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117828
: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
For this much reduced C source code:
struct {
struct {
int Reserved : 32
}
};
struct {
struct {
int Reserved
}
};
seems to go wrong with recent gcc trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117724
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117762
--- Comment #1 from David Binderman ---
Five more little problems in libgrust:
trunk/libgrust/libproc_macro_internal/group.cc:28:32: performance: Function
parameter 'stream' should be passed by const reference. [passedByValue]
trunk/libgrust/li
: normal
Priority: P3
Component: rust
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
CC: dkm at gcc dot gnu.org, gcc-rust at gcc dot gnu.org,
pierre-emmanuel.patry at embecosm dot com
Target Milestone
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
This C code:
int **sres_cache_set_srv_priority_iter, **sres_htable_next_ht_0,
**sres_htable_next_ee;
int **sres_htable_next();
void sres_cache_set_srv_priority() {
for
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
A couple of days ago a gcc trunk build on a Raspberry PI 5
worked fine. Today, not.
New error is
../trunk/libgcc/config/arm/linux-atomic.c:252:23: error: two or more data types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97323
--- Comment #16 from David Binderman ---
This C code also seems to generate the same error on 32 bit ARM:
void test_incomplete_array_fam() {
struct FAM {
char c;
int data[]
};
}
void test_single_element_array_possible_fam() {
struc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70800
--- Comment #10 from David Binderman ---
(In reply to Eric Gallager from comment #4)
> (In reply to David Binderman from comment #3)
> > I just discovered that clang++ can be made to find this bug by
> > adding flag -Wtautological-compare.
> >
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70800
--- Comment #6 from David Binderman ---
(In reply to Eric Gallager from comment #5)
> keeping bug open for the enhancement to -Wtautological-compare
I tried out the code in comment 1 on recent gcc trunk
and the problem seems to be fixed:
Alpha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117476
--- Comment #29 from David Binderman ---
(In reply to Sam James from comment #28)
> Jeff, can you push the revert for now, given that?
+1
My usual gcc testing has mostly been on hold for five days
awaiting version 2 of the fix or a revert.
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
Created attachment 59574
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59574&action=edit
C source code
For the attached C code with -O2 -fipa-cp-clone
foundBugs $ /home
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117507
--- Comment #3 from David Binderman ---
After most of the reduction:
typedef int u_int;
static void z900_vstoreb();
int z900_edit_x_edit_and_mark_regs;
unsigned long z900_edit_x_edit_and_mark_regs_1_0_0;
u_int z900_edit_x_edit_and_mark_regs_0_0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117507
--- Comment #2 from David Binderman ---
-O2 can be replaced by -O1 -fcode-hoisting -fexpensive-optimizations.
I have a reduction running.
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
Created attachment 59566
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59566&action=edit
gzipped C source code
For the attached C code, when run with -O2 -w
on recent vers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117476
--- Comment #18 from David Binderman ---
(In reply to Alexey Merzlyakov from comment #16)
> So, I am agree, that wrapping-out
> the checks/macros - is a good idea, but not sure, whether we really need it
> for this particular case?
I am gratef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117476
--- Comment #12 from David Binderman ---
(In reply to Alexey Merzlyakov from comment #11)
> To verify the "outside mode N" part, we need to change
>
> & ~GET_MODE_MASK (mode)) == 0)
>
> to the:
>
> & ~GET_MODE_MASK(GET_MODE (op))) =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117476
--- Comment #5 from David Binderman ---
(In reply to Sam James from comment #3)
> Please reduce with something like: -Werror=uninitialized
> -Werror=aggressive-loop-optimizations -Werror=sequence-point.
Thanks. Second try:
void printf ();
voi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117476
--- Comment #2 from David Binderman ---
Partially reduced code:
void printf ();
void
platform_main_end(int crc)
{
printf ("checksum = %X\n", crc);
}
int crc32_tab[6];
int crc32_context = 4294967295;
void
crc32_byte (char b) {
crc32_context
: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
Created attachment 59552
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59552&action=edit
C source code
For the attached C code:
foundBugs $ ~/gcc/results/bin/g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109996
--- Comment #4 from David Binderman ---
(In reply to Sam James from comment #3)
> Which commit did you hit this with?
I only know sometime before 20220515. Someone with more
git knowledge than me might be able to make progress in
bisection.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117360
--- Comment #2 from David Binderman ---
(In reply to Jakub Jelinek from comment #1)
> While you're at it, the ULL uses in ext-dce.cc should be
> HOST_WIDE_INT_UC () or 1ULL should be HOST_WIDE_INT_1U.
It might also be a wise idea in these cases
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
Sometime between g:e320846fec00aaa3 and g:91577f0c8d955bc6,
this C code
long negate_v1_0;
unsigned long negate___trans_tmp_1;
int *negate_v_1;
void negate() {
negate___trans_tmp_1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
I tried a bootstrap and got the runtime error in the title.
The line of code is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117342
--- Comment #11 from David Binderman ---
(In reply to Andreas Schwab from comment #10)
> Can you provide an example of the evidence?
Sure. For this C++ source code:
void s61() { static char extra_special_characters[] = "\n\t\b\r\f\\\'"; }
com
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
This week's gcc build with valgrind produced:
==238602== Invalid read of size 4
==238602==at 0x10D14A3: vect_optimize_slp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117342
--- Comment #7 from David Binderman ---
Created attachment 59485
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59485&action=edit
log file from config
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117342
--- Comment #8 from David Binderman ---
gcc $ grep BASE auto-host.h
#define HAVE_DECL_BASENAME 1
/* #undef HAVE_GAS_BASE64 */
/* #undef HAVE_LD_PE_DISABLE_DYNAMICBASE */
gcc $
So either I get a different gas when I compile gcc with clang,
or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117342
--- Comment #3 from David Binderman ---
No mention of base64 in the config.log:
working.2 $ grep base64 config.log
working.2 $
What's a combined build ?
My usual configure line is:
CC="clang" CXX="clang++" \
../trunk/configure --prefix=$HO
nt: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
.base64 is a new feature in gas in binutils.
I see some new evidence that gcc is emitting .base64
statements into the assembler file *.s. Trouble is,
my current version o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117313
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89786
--- Comment #4 from David Binderman ---
(In reply to Eric Botcazou from comment #3)
> I'll have a look.
Did anything happen about this ?
Bug still seems to be present.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117258
--- Comment #4 from David Binderman ---
Even more mysterious:
elk-9.2.12 $ find . -name \*.f90 -print | xargs grep xc_f03_lib_m
./src.orig/libxcifc.f90:use xc_f03_lib_m
./src/libxcifc.f90:use xc_f03_lib_m
elk-9.2.12 $
I even tried:
elk-9.2.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101017
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117258
--- Comment #2 from David Binderman ---
I had a quick look:
BUILD $ find elk* -name libxcifc.f90 -print
elk-9.2.12/src.orig/libxcifc.f90
elk-9.2.12/src/libxcifc.f90
BUILD $ find elk-9.2.12 -name xc_f03_lib_m.mod -print
BUILD $
So where shoul
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
Created attachment 59408
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59408&action=edit
fortran source co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117176
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
>From the gcc testsuite:
testsuite $ /home/dcb40b/gcc/results.20241012.asan.ubsan/bin/gfortran -c
./gfortran.dg/typebound_operator_11.f90
testsuite $ /home/dcb40b/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117116
David Binderman changed:
What|Removed |Added
CC||rguenther at suse dot de
--- Comment
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
This C code:
typedef int (*StmFct)();
typedef struct {
StmFct fct_getc;
StmFct fct_putc;
StmFct fct_flush;
StmFct fct_close
} StmInf;
StmInf TTY_Getc_pstm;
int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117050
David Binderman changed:
What|Removed |Added
CC||rguenther at suse dot de
--- Comment
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
This reduced C code:
typedef struct {
char *data
} song_sample_t;
typedef struct {
int right_ramp;
int left_ramp
} song_voice_t;
song_sample_t *csf_stop_sample_smp, *csf_stop_sample_v_3
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
1 - 100 of 1408 matches
Mail list logo
