https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119803
--- Comment #4 from David Binderman ---
Another test case, from csmith, is:
long func_46___trans_tmp_17;
char(safe_rshift_func_int8_t_s_s)(char);
void(safe_lshift_func_int32_t_s_s)(int);
void(safe_mod_func_int64_t_s_s)(long);
static void func_4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119803
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119612
Bug ID: 119612
Summary: gcc.dg/pr106465.c newly re-broken
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
As
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101017
--- Comment #12 from David Binderman ---
(In reply to Hongtao Liu from comment #11)
> (In reply to David Binderman from comment #10)
> > Did this ever happen ?
> >
> > Similar test case gcc/testsuite/gcc.target/i386/avx10_1-26.c
> > still seems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119324
Bug ID: 119324
Summary: cppcheck meets /cobol/
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: cobol
Assignee:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119323
Bug ID: 119323
Summary: cppcheck meets libgcobol
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: cobol
Assigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98904
--- Comment #14 from David Binderman ---
I confirm that the problem seems to have gone away.
I used this configure script:
CC="gcc -g1 -O3 -march=znver3" CXX="g++ -g1 -O3 -march=znver3" \
../trunk/configure --prefix=$HOME/gcc/results.$DATE.valgr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115316
--- Comment #1 from David Binderman ---
As of today, 20250310, still broken.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119200
Bug ID: 119200
Summary: valgrind error in gfc_format_decoder
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119199
Bug ID: 119199
Summary: valgrind error in translate_common
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119157
Bug ID: 119157
Summary: ice in gfc_enforce_clean_symbol_state, at
fortran/symbol.cc:4459
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118801
--- Comment #8 from David Binderman ---
(In reply to Richard Biener from comment #7)
> Fixed.
Thanks for that. I notice that the commit doesn't seem
to add a test case to the test suite. Worth doing ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118756
--- Comment #7 from David Binderman ---
(In reply to GCC Commits from comment #6)
> The master branch has been updated by Martin Jambor :
>
> https://gcc.gnu.org/g:d05b64bdd048ffb7f72d97553888934a9bcd13fa
>
> commit r15-7792-gd05b64bdd048ffb7f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118819
--- Comment #11 from David Binderman ---
(In reply to David Binderman from comment #10)
> Another bootstrap with "-g -O3 -march=znver3" is now running.
That passed too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118819
--- Comment #10 from David Binderman ---
(In reply to David Binderman from comment #9)
> I will try to do the bootstrap over the weekend.
Bootstrap passed.
Another bootstrap with "-g -O3 -march=znver3" is now running.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118819
--- Comment #9 from David Binderman ---
(In reply to Jakub Jelinek from comment #8)
> Hopefully fixed (but haven't tried UBSAN bootstrap for this, please reopen
> if it is not fixed).
I don't seem able to reopen this bug.
If the bootstrap hasn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118847
--- Comment #5 from David Binderman ---
Reduced C code seems to be:
struct zw_value {
~zw_value();
};
void __trans_tmp_1() {
for (; auto val = __trans_tmp_1;) {
switch (0)
case 0:;
zw_value cst;
}
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118847
--- Comment #3 from David Binderman ---
(In reply to Sam James from comment #2)
> This is almost certainly a dupe of PR118822.
>
> Is there a `while ( x = y )` or similar on that line?
No. Just a "}" as the error message indicates.
Surroundin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118847
David Binderman changed:
What|Removed |Added
Keywords||needs-bisection,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118847
Bug ID: 118847
Summary: ice in pop, at vec.h:1056
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118819
--- Comment #3 from David Binderman ---
(In reply to Sam James from comment #1)
> With export
> UBSAN_OPTIONS="halt_on_error=1:abort_on_error=1:print_summary=1:
> print_stacktrace=1", you should be able to get a nice backtrace. You can
> drop th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116948
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118819
Bug ID: 118819
Summary: runtime error: signed integer overflow during
bootstrap
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118801
--- Comment #2 from David Binderman ---
(In reply to Andrew Pinski from comment #1)
> Note you might also want to use -fno-checking for the trunk.
Thanks for the tip. Still a 26 times expansion.
foundBugs $ time ../results/bin/gcc -c -w -g -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118801
Bug ID: 118801
Summary: Excessive compile time with -g -O2 -fpeel-loops
-fno-var-tracking
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118786
Bug ID: 118786
Summary: more wrong code with -finline-small-functions
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116600
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118758
--- Comment #7 from David Binderman ---
Bug seems to start sometime between 20241217 and 20241231:
foundBugs $ rm ./a.out ; ../results.20241217/bin/gcc -O3 -w bug1086.c &&
./a.out
checksum = E0BB38EE
foundBugs $ rm ./a.out ; ../results.20241231
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118758
--- Comment #6 from David Binderman ---
(In reply to David Binderman from comment #2)
> I will look into a bisection.
The problem seems to exist sometime before 20241231 with g:0b06abe027a78681
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118758
--- Comment #3 from David Binderman ---
The original code is from csmith, so:
foundBugs $ rm ./a.out && ../results/bin/gcc -w bug1086.c && ./a.out 1 > /tmp/0
foundBugs $ rm ./a.out && ../results/bin/gcc -w -O1 bug1086.c && ./a.out 1 >
/tmp/1
fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118758
--- Comment #2 from David Binderman ---
I will look into a bisection.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118758
Bug ID: 118758
Summary: [15 regression] ok code with -O2, but wrong code with
-O3
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118756
Bug ID: 118756
Summary: tree-ssa-loop-ivopts.cc:1156: Function defined but not
used
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118695
Bug ID: 118695
Summary: ice in gen_movsi, at config/arm/arm.md:6476
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: targ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118653
--- Comment #13 from David Binderman ---
Also before 2024-04-01:
foundBugs $ ../results.d8cf8917ed3d7e07/bin/gcc -c -w -g -O3 bug1083.c
during GIMPLE pass: vect
runData/keep/in.39468.c: In function ‘main’:
runData/keep/in.39468.c:1246:5: intern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118653
--- Comment #11 from David Binderman ---
Bug still exists some 8 weeks earlier at 2024-09-15:
foundBugs $ ../results.5f0a381801b754db/bin/gcc -c -g -O3 -w bug1083.c
during GIMPLE pass: vect
runData/keep/in.39468.c: In function ‘main’:
runData/k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118653
--- Comment #10 from David Binderman ---
Bug seems to exist at date 2024-11-10:
foundBugs $ ../results.32cf28ccc9e77ce0/bin/gcc -c -g -O3 -w bug1083.c
during GIMPLE pass: vect
runData/keep/in.39468.c: In function ‘main’:
runData/keep/in.39468.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118653
--- Comment #9 from David Binderman ---
Bug seems to exist two weeks earlier (2024-12-08):
foundBugs $ ../results.be8d1a358e3abc50/bin/gcc -c -g -O3 -w bug1083.c
during GIMPLE pass: vect
runData/keep/in.39468.c: In function ‘main’:
runData/keep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118653
--- Comment #7 from David Binderman ---
(In reply to David Binderman from comment #1)
> The bug seems to exist since before g:0b06abe027a78681
Bug seems to exist a week earlier with g:0b63840e07132f72.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118653
--- Comment #8 from David Binderman ---
(In reply to David Binderman from comment #7)
> (In reply to David Binderman from comment #1)
> > The bug seems to exist since before g:0b06abe027a78681
>
> Bug seems to exist a week earlier with g:0b6384
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118653
--- Comment #2 from David Binderman ---
Reduced code seems to be:
short g_72, g_173;
int g_100[];
int func_1___trans_tmp_9;
short(safe_sub_func_int16_t_s_s)(short si1, short si2) { return si1 - si2; }
void func_1() {
for (; g_173; g_173 = saf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118653
David Binderman changed:
What|Removed |Added
Keywords||needs-bisection,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118653
Bug ID: 118653
Summary: ice in vectorizable_live_operation, at
tree-vect-loop.cc:11573
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118629
Bug ID: 118629
Summary: ice in cp_parser_expression_statement, at
cp/parser.cc:13584
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118628
Bug ID: 118628
Summary: gcc/tree-vect-stmts.cc:10642: Possible read of
uninitialised data ?
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118627
Bug ID: 118627
Summary: gcc/omp-general.cc:4197: Possible read of
uninitialised data ?
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118606
--- Comment #3 from David Binderman ---
(In reply to Jakub Jelinek from comment #1)
> What is confusing about that?
It's a matter of style. Clang considers that some style boundary has been
stepped over in the original case.
> Is that any d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118606
Bug ID: 118606
Summary: gcc/omp-general.cc:3294: Possible precedence problem
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118605
Bug ID: 118605
Summary: gcc/tree-assume.cc:108: dangling field problem
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118604
Bug ID: 118604
Summary: gcc/cp/parser.cc:51316: Non clear code produces clang
warning
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118558
--- Comment #1 from David Binderman ---
Created attachment 60208
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60208&action=edit
C source code
Reduced C code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118558
Bug ID: 118558
Summary: csmith: another runtime error with march=znver3
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
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 /
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118333
Bug ID: 118333
Summary: gcc/config/i386/i386-expand.cc:24871: Pointless
condition ?
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
P
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118269
Bug ID: 118269
Summary: ice in vect_create_epilog_for_reduction, at
tree-vect-loop.cc:6901
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118181
Bug ID: 118181
Summary: gcc/lto-ltrans-cache.cc:312: Avoid call by value for
large objects
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118097
Bug ID: 118097
Summary: recent bug with -O2, but not -O1
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Ass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117258
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117893
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
--- Comment
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117828
Bug ID: 117828
Summary: -g and error: ‘TYPE_CANONICAL’ is not compatible
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117724
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
--- Comment
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117762
Bug ID: 117762
Summary: libgrust/libproc_macro_internal/tokenstream.cc: 3 *
performance issues ?
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117656
Bug ID: 117656
Summary: error: invalid types for ‘bit_ior_expr’
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117628
Bug ID: 117628
Summary: New gcc build failure on 32 bit ARM
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117524
Bug ID: 117524
Summary: Segmentation fault with -fipa-cp-clone
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117507
Bug ID: 117507
Summary: SIGSEGV in tree_strip_nop_conversions
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117476
Bug ID: 117476
Summary: bad generated code from -finline-small-functions
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117363
Bug ID: 117363
Summary: ice during GIMPLE pass: ldist
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117360
Bug ID: 117360
Summary: ext-dce.cc:573:15: runtime error: shift exponent 127
is too large for 64-bit type 'long long unsigned int'
Product: gcc
Version: 15.0
Status: UNC
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117343
Bug ID: 117343
Summary: valgrind error in
vect_optimize_slp_pass::decide_masked_load_lanes
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
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
1 - 100 of 1187 matches
Mail list logo
