[Bug rtl-optimization/88652] New: sel-sched.c:1545:11: runtime error: index 2 out of bounds for type 'long unsigned int [2]'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88652 Bug ID: 88652 Summary: sel-sched.c:1545:11: runtime error: index 2 out of bounds for type 'long unsigned int [2]' Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Blocks: 85099 Target Milestone: --- UBSAN GCC complains about: $ ./xgcc -B. /home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/pr87759.c -c -O -fschedule-insns -fselective-scheduling -fno-tree-dce /home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/pr87759.c: In function ‘rc’: /home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/pr87759.c:20:39: warning: initialization of ‘__int128 unsigned *’ from incompatible pointer type ‘int *’ [-Wincompatible-pointer-types] 20 | unsigned __int128 *ar = | ^ /home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/pr87759.c:29:54: warning: right shift count >= width of type [-Wshift-count-overflow] 29 | y5 = (cc + 1) == ((*ar /= *oi) << ((zp >>= 128) / cc)); | ^~~ ../../gcc/sel-sched.c:1545:11: runtime error: index 2 out of bounds for type 'long unsigned int [2]' #0 0x1ed74cb in verify_target_availability ../../gcc/sel-sched.c:1545 #1 0x1ed7faf in find_best_reg_for_expr ../../gcc/sel-sched.c:1679 #2 0x1ee4ef9 in fill_vec_av_set ../../gcc/sel-sched.c:3797 #3 0x1ee6629 in fill_ready_list ../../gcc/sel-sched.c:4027 #4 0x1ee88a5 in find_best_expr ../../gcc/sel-sched.c:4387 #5 0x1ef18bb in fill_insns ../../gcc/sel-sched.c:5548 #6 0x1ef9ffb in schedule_on_fences ../../gcc/sel-sched.c:7364 #7 0x1efafa2 in sel_sched_region_2 ../../gcc/sel-sched.c:7502 #8 0x1efb3f2 in sel_sched_region_1 ../../gcc/sel-sched.c:7544 #9 0x1efc11b in sel_sched_region(int) ../../gcc/sel-sched.c:7645 #10 0x1efc353 in run_selective_scheduling() ../../gcc/sel-sched.c:7731 #11 0x1e86883 in rest_of_handle_sched ../../gcc/sched-rgn.c:3717 #12 0x1e86bde in execute ../../gcc/sched-rgn.c:3827 #13 0x1ba25da in execute_one_pass(opt_pass*) ../../gcc/passes.c:2483 #14 0x1ba2e70 in execute_pass_list_1 ../../gcc/passes.c:2569 #15 0x1ba2f25 in execute_pass_list_1 ../../gcc/passes.c:2570 #16 0x1ba2fc4 in execute_pass_list(function*, opt_pass*) ../../gcc/passes.c:2580 #17 0xe3a3f6 in cgraph_node::expand() ../../gcc/cgraphunit.c:2196 #18 0xe3b9bd in expand_all_functions ../../gcc/cgraphunit.c:2334 #19 0xe3e02c in symbol_table::compile() ../../gcc/cgraphunit.c:2685 #20 0xe3ea92 in symbol_table::finalize_compilation_unit() ../../gcc/cgraphunit.c:2863 #21 0x1ffa639 in compile_file ../../gcc/toplev.c:481 #22 0x20019d5 in do_compile ../../gcc/toplev.c:2176 #23 0x2002003 in toplev::main(int, char**) ../../gcc/toplev.c:2311 #24 0x4333837 in main ../../gcc/main.c:39 #25 0x76246fea in __libc_start_main ../csu/libc-start.c:308 #26 0x85b559 in _start (/home/marxin/Programming/gcc2/objdir/gcc/cc1+0x85b559) Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85099 [Bug 85099] [meta-bug] selective scheduling issues
[Bug tree-optimization/88651] New: tree-data-ref.c:3764:26: runtime error: signed integer overflow: 9223372036854775802 - -6 cannot be represented in type 'long int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88651 Bug ID: 88651 Summary: tree-data-ref.c:3764:26: runtime error: signed integer overflow: 9223372036854775802 - -6 cannot be represented in type 'long int' Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: rguenth at gcc dot gnu.org Blocks: 63426 Target Milestone: --- Created attachment 45311 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45311=edit test-case UBSAN GCC compiler complains about: $ ./xgcc -B. -c -O -ftree-loop-vectorize final.f90 final.f90:65:8: 65 | DO m= 1,zone(1) |1 Warning: Deleted feature: End expression in DO loop at (1) must be integer ../../gcc/tree-data-ref.c:3764:26: runtime error: signed integer overflow: 9223372036854775802 - -6 cannot be represented in type 'long int' #0 0x457686a in analyze_subscript_affine_affine ../../gcc/tree-data-ref.c:3764 #1 0x4577d03 in analyze_siv_subscript ../../gcc/tree-data-ref.c:3915 #2 0x457935b in analyze_overlapping_iterations ../../gcc/tree-data-ref.c:4161 #3 0x457c7c1 in subscript_dependence_tester_1 ../../gcc/tree-data-ref.c:4702 #4 0x457cb57 in subscript_dependence_tester ../../gcc/tree-data-ref.c:4752 #5 0x457cf8a in compute_affine_dependence(data_dependence_relation*, loop*) ../../gcc/tree-data-ref.c:4811 #6 0x457d4ef in compute_all_dependences(vec, vec*, vec, bool) ../../gcc/tree-data-ref.c:4878 #7 0x45bb302 in vect_analyze_data_ref_dependences(_loop_vec_info*, unsigned int*) ../../gcc/tree-vect-data-refs.c:541 #8 0x2b52e3c in vect_analyze_loop_2 ../../gcc/tree-vect-loop.c:1851 #9 0x2b574c6 in vect_analyze_loop(loop*, _loop_vec_info*, vec_info_shared*) ../../gcc/tree-vect-loop.c:2270 #10 0x2be22b4 in try_vectorize_loop_1 ../../gcc/tree-vectorizer.c:873 #11 0x2be31b8 in try_vectorize_loop ../../gcc/tree-vectorizer.c:1019 #12 0x2be34ea in vectorize_loops() ../../gcc/tree-vectorizer.c:1101 #13 0x2831799 in execute ../../gcc/tree-ssa-loop.c:414 #14 0x1ec9ffa in execute_one_pass(opt_pass*) ../../gcc/passes.c:2483 #15 0x1eca890 in execute_pass_list_1 ../../gcc/passes.c:2569 #16 0x1eca945 in execute_pass_list_1 ../../gcc/passes.c:2570 #17 0x1eca945 in execute_pass_list_1 ../../gcc/passes.c:2570 #18 0x1eca9e4 in execute_pass_list(function*, opt_pass*) ../../gcc/passes.c:2580 #19 0x1162338 in cgraph_node::expand() ../../gcc/cgraphunit.c:2196 #20 0x11638ff in expand_all_functions ../../gcc/cgraphunit.c:2334 #21 0x1165f6e in symbol_table::compile() ../../gcc/cgraphunit.c:2685 #22 0x11669d4 in symbol_table::finalize_compilation_unit() ../../gcc/cgraphunit.c:2863 #23 0x22fe0f7 in compile_file ../../gcc/toplev.c:481 #24 0x2305493 in do_compile ../../gcc/toplev.c:2176 #25 0x2305ac1 in toplev::main(int, char**) ../../gcc/toplev.c:2311 #26 0x466210c in main ../../gcc/main.c:39 #27 0x7608cfea in __libc_start_main ../csu/libc-start.c:308 #28 0x872bd9 in _start (/home/marxin/Programming/gcc2/objdir/gcc/f951+0x872bd9) Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426 [Bug 63426] [meta-bug] Issues found with -fsanitize=undefined
[Bug tree-optimization/88650] [9 Regression] ICE in set_even_probabilities at gcc/predict.c:885 since r267485
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88650 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-01-02 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Mine.
[Bug tree-optimization/88650] New: [9 Regression] ICE in set_even_probabilities at gcc/predict.c:885 since r267485
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88650 Bug ID: 88650 Summary: [9 Regression] ICE in set_even_probabilities at gcc/predict.c:885 since r267485 Product: gcc Version: 9.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Target Milestone: --- Caused by my commit: $ gcc /home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/transfer_simplify_1.f90 -fno-tree-fre -fno-tree-ccp -Og during GIMPLE pass: profile_estimate /home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/transfer_simplify_1.f90:15:0: 15 | call pr31427 () | internal compiler error: Floating point exception 0xb3bd2f crash_signal /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-x86_64/build/gcc/toplev.c:326 0x76bc310f ??? /usr/src/debug/glibc-2.27-6.1.x86_64/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0 0x96966a safe_scale_64bit(unsigned long, unsigned long, unsigned long, unsigned long*) /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-x86_64/build/gcc/profile-count.h:81 0x96966a profile_probability::apply_scale(long, long) const /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-x86_64/build/gcc/profile-count.h:497 0x96966a profile_probability::apply_scale(long, long) const /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-x86_64/build/gcc/profile-count.h:489 0xa955d4 set_even_probabilities /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-x86_64/build/gcc/predict.c:885 0xa99f30 combine_predictions_for_bb /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-x86_64/build/gcc/predict.c:1237 0xa9a2e9 tree_estimate_probability(bool) /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-x86_64/build/gcc/predict.c:3091 0xa9a677 execute /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-x86_64/build/gcc/predict.c:4028 0xa9a677 execute /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-x86_64/build/gcc/predict.c:4011
[Bug fortran/88649] New: runtime error: load of value 137971008, which is not a valid value for type 'gfc_intrinsic_op'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88649 Bug ID: 88649 Summary: runtime error: load of value 137971008, which is not a valid value for type 'gfc_intrinsic_op' Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Blocks: 63426 Target Milestone: --- Using ubsan GCC compiler, one can see: $ ./xgcc -B. /home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/dec_bitwise_ops_1.f90 -O0 -fdec ../../gcc/fortran/resolve.c:4150:23: runtime error: load of value 137971008, which is not a valid value for type 'gfc_intrinsic_op' #0 0xb1362e in resolve_operator ../../gcc/fortran/resolve.c:4150 #1 0xb2ffce in gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.c:6825 #2 0xb61cfa in gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:11269 #3 0xb9cb84 in resolve_codes ../../gcc/fortran/resolve.c:16715 #4 0xb9cd8b in gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.c:16750 #5 0xad072e in resolve_all_program_units ../../gcc/fortran/parse.c:6067 #6 0xad1a20 in gfc_parse_file() ../../gcc/fortran/parse.c:6317 #7 0xc3694a in gfc_be_parse_file ../../gcc/fortran/f95-lang.c:204 #8 0x22fdf98 in compile_file ../../gcc/toplev.c:456 #9 0x2305493 in do_compile ../../gcc/toplev.c:2176 #10 0x2305ac1 in toplev::main(int, char**) ../../gcc/toplev.c:2311 #11 0x466210c in main ../../gcc/main.c:39 #12 0x7608cfea in __libc_start_main ../csu/libc-start.c:308 #13 0x872bd9 in _start (/home/marxin/Programming/gcc2/objdir/gcc/f951+0x872bd9) Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426 [Bug 63426] [meta-bug] Issues found with -fsanitize=undefined
[Bug c/79011] incorrect form of warning options listed in the manual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79011 --- Comment #1 from Eric Gallager --- (In reply to Martin Sebor from comment #0) > Section 3.8 of the manual, Options to Request or Suppress Warnings, states > that: > > "This manual lists only one of the two forms, whichever is not the > default." > > The following is a list of options listed in that section that, according to > the manual, are enabled by default (and thus should be listed in the > -Wno-xxx form). > ... > -Wno-endif-labels This one's already in -Wno-xxx form
[Bug c++/87729] Please include -Woverloaded-virtual in -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87729 --- Comment #1 from Eric Gallager --- (In reply to Daniel Fruzynski from comment #0) > clang includes -Woverloaded-virtual in -Wall. Please do same for gcc. I was looking for a testcase to check and tried g++.dg/warn/pr61945.C but clang doesn't warn on that with -Wall. Do you have a better testcase to show how clang warns but gcc doesn't?
[Bug target/65782] Assembly failure (invalid register for .seh_savexmm) with -O3 -mavx512f on mingw-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65782 --- Comment #5 from Daniel Fruzynski --- I got following link: https://stackoverflow.com/questions/53733624/is-xmm8-register-value-preserved-across-calls/53733767#53733767 Quote from it: "Any additional registers for newer instruction sets are volatile by default. This includes the upper parts of YMM0-15 and ZMM0-15 as well as ?MM16-31 if present.". So it looks that gcc should not generate .seh_savexmm for xmm16..31 at all.
[Bug c/88648] New: Force unified syntax for inline assembly not functional (-masm-syntax-unified)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88648 Bug ID: 88648 Summary: Force unified syntax for inline assembly not functional (-masm-syntax-unified) Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: stefan at agner dot ch Target Milestone: --- Forcing inline assembly to be unified syntax seems not to work properly E.g. compiling a c file with the following inline assembly using arm-none-eabi-gcc -marm -march=armv7-a -masm-syntax-unified test.c --save-temps asm ( "nop" ); leads to: .syntax divided @ 5 "test.c" 1 nop @ 0 "" 2
[Bug target/65782] Assembly failure (invalid register for .seh_savexmm) with -O3 -mavx512f on mingw-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65782 --- Comment #4 from Daniel Fruzynski --- I have found that I can use -ffixed-reg option for this. It allows to eliminate one register, so I have to use it 16 times to eliminate all xmm16..31 registers. It would be handy to have another option which would allow to disable all registers from this group together.
[Bug target/65782] Assembly failure (invalid register for .seh_savexmm) with -O3 -mavx512f on mingw-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65782 Daniel Fruzynski changed: What|Removed |Added CC||bugzilla@poradnik-webmaster ||a.com --- Comment #3 from Daniel Fruzynski --- Cygwin (x86_64-pc-cygwin) is also affected. I have encountered this bug on gcc 7.4.0. Could you add new option which would remove XMM16+ registers from available registers pool? It could be used as an easy to use workaround until you fix it properly.
[Bug fortran/19276] [meta-bug] CHARACTER related bugs in gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19276 Bug 19276 depends on bug 82743, which changed state. Bug 82743 Summary: uncaught character truncation in derived type initialization https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82743 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/82743] uncaught character truncation in derived type initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82743 Thomas Koenig changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Thomas Koenig --- Fixed on trunk, closing.
[Bug fortran/82743] uncaught character truncation in derived type initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82743 --- Comment #3 from Thomas Koenig --- Author: tkoenig Date: Tue Jan 1 21:19:53 2019 New Revision: 267499 URL: https://gcc.gnu.org/viewcvs?rev=267499=gcc=rev Log: 2019-01-01 Thomas Koenig PR fortran/82743 * primary.c (gfc_convert_to_structure_constructor): If a character in a constructor is too long, add a warning with -Wcharacter-truncation. 2019-01-01 Thomas Koenig PR fortran/82743 * gfortran.dg/structure_constructor_16.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/structure_constructor_16.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/primary.c trunk/gcc/testsuite/ChangeLog
[Bug c/88647] New: Rejects valid program dereferencing pointer with incomplete reference type.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88647
Bug ID: 88647
Summary: Rejects valid program dereferencing pointer with
incomplete reference type.
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Test case (prog.c):
struct S *p;
void f(void);
int main()
{
f();
*p;
}
struct S { int x; };
void f()
{
static struct S s = { 0 };
p =
}
Compilation command line:
gcc prog.c -Wall -Wextra -std=c11 -pedantic-errors
Observed behaviour:
The following error message was outputed:
prog.c: In function 'main':
prog.c:10:5: error: dereferencing pointer to incomplete type 'struct S'
10 | *p;
| ^~
Expected behaviour:
No error message outputed.
I can't find anything in the standard that makes the this program invalid.
[Bug testsuite/88041] gdc.test tests should include that prefix in test names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88041 Johannes Pfau changed: What|Removed |Added CC||johannespfau at gmail dot com --- Comment #5 from Johannes Pfau --- For reference, this makes running the testsuite on windows/msys2 hosts somewhat more complicated: On these systems, ln -s is implemented by copying SRC to DST instead of creating proper links [1]. (I'm not sure whether the TCL file link command actually calls ln on MSYS2, but it seems to do so, as the observed effect is just this: a copy of the directory). It is possible to configure MSYS2 to use proper NTFS symlinks instead [2], but then running the testuite will always require administrator privileges on older windows versions. On newer windows versions, mklink can now be used as normal user iff the windows developer mode is enabled [3]. However, the ln shipped with MSYS2 does not yet make use of this feature[4]. Not sure if this really is a problem or if there's a better solution. For now, configuring ln to use windows symlinks and building gcc as admin should work. An alternative is to just manually create that one symlink. The best solution is probably to just use a cross-compiler for testing and build on linux ;-) [1] https://sourceforge.net/p/msys2/tickets/41/ [2] https://www.joshkel.com/2018/01/18/symlinks-in-windows/ [3] https://www.wintellect.com/non-admin-users-can-now-create-symlinks-windows-10/ [4] https://github.com/Alexpux/MSYS2-packages/issues/1219
[Bug target/65342] [7/8/9 Regression] FAIL: gfortran.dg/intrinsic_(un)?pack_1.f90 -O1 execution test on powerpc-apple-darwin9 after r210201
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65342 --- Comment #22 from Dominique d'Humieres --- Is this still present on ppc?
[Bug target/52491] FAIL: gcc.dg/torture/pr52402.c at -O2 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52491 Dominique d'Humieres changed: What|Removed |Added CC||iains at gcc dot gnu.org --- Comment #2 from Dominique d'Humieres --- Is this still present on ppc?
[Bug target/88640] ICE in mark_reachable_handlers, at tree-eh.c:3926
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88640 --- Comment #3 from Segher Boessenkool --- It looks like a generic problem to me, fwiw.
[Bug c/88635] [8 Regression] Assembler error when building with "-g -O2 -m32"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88635
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-01-01
CC||jakub at gcc dot gnu.org
Target Milestone|--- |8.3
Summary|Assembler error when|[8 Regression] Assembler
|building with "-g -O2 -m32" |error when building with
||"-g -O2 -m32"
Ever confirmed|0 |1
--- Comment #1 from Jakub Jelinek ---
Started with r256580. Got fixed or went latent with r265677 on the trunk.
Reduced testcase with -m32 -dA -g -O2 -fpie -fvisibility=hidden:
void
foo (char *b)
{
unsigned c = 0;
--c;
do
if (++*b++ == 0)
break;
while (--c);
if (c == 0)
while (*b++)
;
}
void
bar (void)
{
foo ("");
}
[Bug target/88640] ICE in mark_reachable_handlers, at tree-eh.c:3926
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88640 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- With additional -mcpu=power8 already r20 ICEs, GCC 4.8-RH ICEs too, don't have anything powerpc64le-ish older than that.
[Bug c/88645] Don't assume functions are always nonnull if there's __attribute__((weak_import)), similar to __attribute__((weak))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88645 MCCCS changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from MCCCS --- *it works. This bug seemed to exit because of a missing weak_import in Apple's headers.
[Bug middle-end/88575] gcc got confused by different comparison operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88575 --- Comment #3 from Daniel Fruzynski --- I have tried to compile with -O3 -march=skylake -ffast-math and got this: [asm] test(double, double): vminsd xmm2, xmm0, xmm1 vcmplesdxmm0, xmm0, xmm1 vxorpd xmm1, xmm1, xmm1 vblendvpd xmm0, xmm1, xmm2, xmm0 ret test2(double, double): vminsd xmm2, xmm0, xmm1 vcmpltsdxmm0, xmm0, xmm1 vxorpd xmm1, xmm1, xmm1 vblendvpd xmm0, xmm1, xmm2, xmm0 ret [/asm] And this is for -O3 -march=skylake -funsafe-math-optimizations. As you can see, one instruction was eliminated from test2(). For some reason it was not eliminated from test() function. I checked that -ffinite-math-only present in -ffast-math prevented elimination of this extra instruction. [asm] test(double, double): vminsd xmm2, xmm0, xmm1 vcmplesdxmm0, xmm0, xmm1 vxorpd xmm1, xmm1, xmm1 vblendvpd xmm0, xmm1, xmm2, xmm0 ret test2(double, double): vcmpnltsd xmm1, xmm0, xmm1 vxorpd xmm2, xmm2, xmm2 vblendvpd xmm0, xmm0, xmm2, xmm1 ret [/asm]
[Bug middle-end/88575] gcc got confused by different comparison operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88575 --- Comment #2 from Daniel Fruzynski --- Code was compiled with -O3 -march=skylake. I have tried to add -fno-signed-zeros and -fsigned-zeros, and got the same output for both cases.
[Bug c++/88646] Optimizer failure on integer sum overflow cast to bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88646 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Andrew Pinski --- If you want signed integer overflow to be defined and be the same between different variables then use -fwrapv . Under defined behavior means gcc could produce this behavior. If you want to detect this behavior at runtime you can use -fsantizer=undefined option.
