[Bug libfortran/79612] missing space in diagnostic: Incorrect rank of return array in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79612 --- Comment #3 from Thomas Koenig --- I cannot think of this happening with normal code. An internal error might be better, but internal_error does not take printf-style arguments.
[Bug middle-end/79396] [5/6/7 Regression] ICE (verify_flow_info failed) with -fnon-call-exceptions -O2 -march=haswell
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79396 --- Comment #14 from janus at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #13) > Author: jakub > Date: Sat Feb 25 10:17:31 2017 > New Revision: 245735 Works like a charm. Thanks for fixing! :)
[Bug libfortran/51119] MATMUL slow for large matrices
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51119 --- Comment #49 from Thomas Koenig --- Author: tkoenig Date: Sun Feb 26 13:22:43 2017 New Revision: 245745 URL: https://gcc.gnu.org/viewcvs?rev=245745&root=gcc&view=rev Log: 2017-02-26 Thomas Koenig PR fortran/51119 * options.c (gfc_post_options): Set default limit for matmul inlining to 30. * invoke.texi: Document change. 2017-02-26 Thomas Koenig PR fortran/51119 * gfortran.dg/inline_matmul_1.f90: Scan optimized dump instead of original. * gfortran.dg/inline_matmul_11.f90: Likewise. * gfortran.dg/inline_matmul_9.f90: Likewise. * gfortran.dg/matmul_13.f90: New test. * gfortran.dg/matmul_14.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/matmul_13.f90 trunk/gcc/testsuite/gfortran.dg/matmul_14.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/invoke.texi trunk/gcc/fortran/options.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/inline_matmul_1.f90 trunk/gcc/testsuite/gfortran.dg/inline_matmul_11.f90 trunk/gcc/testsuite/gfortran.dg/inline_matmul_9.f90
[Bug middle-end/79720] New: floating point result depends on optimization level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79720 Bug ID: 79720 Summary: floating point result depends on optimization level Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: tkoenig at gcc dot gnu.org Target Milestone: --- The following test case $ cat recip.f90 module try implicit none contains complex function r1(a) complex, value :: a r1 = 1./a; end function r1 complex function r2(a) complex, value :: a real :: a_real, a_imag; real :: v_6, v_7, v_9, v_10, v_11, v_12, v_13, v_14, v_15, v_16, v_17, & & v_18, v_19, v_20, v_21, v_22, v_23, v_24, v_27, v_28, & & v_29, v_30, v_31, v_32 logical :: v_8 a_real = real(a) a_imag = aimag(a) v_6 = abs(a_real); v_7 = abs(a_imag) v_8 = v_6 < v_7; if (.not.v_8) then v_9 = a_real / a_imag; v_10 = a_real * v_9; v_11 = a_imag + v_10; v_12 = v_9 + 0.0; v_13 = v_9 * 0.0; v_14 = v_13 - 1.0e+0; v_15 = v_12 / v_11; v_16 = v_14 / v_11; v_31 = v_15; v_32 = v_16; v_27 = v_31; v_28 = v_32; else v_17 = a_imag / a_real; v_18 = a_imag * v_17; v_19 = a_real + v_18; v_20 = v_17 * 0.0; v_21 = v_20 + 1.0e+0; v_22 = 0.0 - v_17; v_23 = v_21 / v_19; v_24 = v_22 / v_19; v_29 = v_23; v_30 = v_24; v_27 = v_29; v_28 = v_30; end if r2 = cmplx(v_27, v_28); end function r2 end module try program main use try implicit none complex :: c, a1, a2 c = (1.2e10, -3.2) a1 = r1(c) a2 = r2(c) print *,a1, a2 print *,a1-a2 end program main gives different results without optimization and with -O on x86_64 with a reasonably current trunk: ig25@linux-d6cw:~/Krempel/Complex> gfortran recip.f90 && ./a.out (8.33329E-11,2.22170E-20) (8.33329E-11,2.22331E-20) (0.,-1.615587134E-27) ig25@linux-d6cw:~/Krempel/Complex> gfortran -O recip.f90 && ./a.out (8.33329E-11,2.22331E-20) (8.33329E-11,2.22331E-20) (0.,0.) It does not appear to be processor-specific, POWER7 exhibits the same behavior: [tkoenig@gcc1-power7 ~]$ gfortran recip.f90 && ./a.out ( 8.E-11, 2.2217E-20) ( 8.E-11, 2.2233E-20) ( 0., -1.61558713E-27) [tkoenig@gcc1-power7 ~]$ gfortran -O recip.f90 && ./a.out ( 8.E-11, 2.2233E-20) ( 8.E-11, 2.2233E-20) ( 0., 0.) In the absence of -funsafe-math-optimizations, this is not supposed to happen. I would assume that this is not a dup of PR 72824; at least -fno-tree-loop-distribute-patterns has no effect.
[Bug fortran/71838] ICE with OpenCoarrays on submodule
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71838 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #12 from Paul Thomas --- Created attachment 40834 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40834&action=edit Fix for the PR The attached is a patch for the PR which is regtesting right now and will be submitted if all is well. Anton, if you are in a position to do so, I would be grateful if you would check that your code now compiles and runs correctly... well, that this bug is no longer a problem, anyway :-) Paul
[Bug testsuite/79427] g++.dg/tls/thread_local-order2.C fails starting with r245249
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79427 John David Anglin changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #7 from John David Anglin --- I don't think this can be fixed on hppa-hpux due to the way destructors are handled.
[Bug middle-end/79720] floating point result depends on optimization level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79720 --- Comment #1 from Andrew Pinski --- v_10 = a_real * v_9; v_11 = a_imag + v_10; This can produce either a multiple and an add or a fused multiply add depending on if the target supports fused multiple add. See https://gcc.gnu.org/onlinedocs/gcc-6.3.0/gcc/Optimize-Options.html#index-ffp-contract-715: -ffp-contract=style -ffp-contract=off disables floating-point expression contraction. -ffp-contract=fast enables floating-point expression contraction such as forming of fused multiply-add operations if the target has native support for them. -ffp-contract=on enables floating-point expression contraction if allowed by the language standard. This is currently not implemented and treated equal to -ffp-contract=off. The default is -ffp-contract=fast. Try again with -ffp-contract=off .
[Bug middle-end/79720] floating point result different at compile time / runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79720 Thomas Koenig changed: What|Removed |Added Summary|floating point result |floating point result |depends on optimization |different at compile time / |level |runtime --- Comment #2 from Thomas Koenig --- Ah... constant folding happens with -O: From the .optimized dump: a1 = __complex__ (8.333289470346016969415359199047088623046875e-11, 2.2233121084274117421693446605690525075260666199028492e-20); a2 = __complex__ (8.333289470346016969415359199047088623046875e-11, 2.2233121084274117421693446605690525075260666199028492e-20); If constant folding is suppressed by hiding the opportunities to do so via -fno-inline, this happens: $ gfortran -O recip-orig.f90 && ./a.out (8.33329E-11,2.22331E-20) (8.33329E-11,2.22331E-20) (0.,0.) $ gfortran -fno-inline -O recip-orig.f90 && ./a.out (8.33329E-11,2.22170E-20) (8.33329E-11,2.22331E-20) (0.,-1.615587134E-27) $ gfortran recip-orig.f90 && ./a.out (8.33329E-11,2.22170E-20) (8.33329E-11,2.22331E-20) (0.,-1.615587134E-27) -ffp-contract has no effect: $ gfortran -fno-inline -ffp-contract=off -O recip-orig.f90 && ./a.out (8.33329E-11,2.22170E-20) (8.33329E-11,2.22331E-20) (0.,-1.615587134E-27) $ gfortran -ffp-contract=off -O recip-orig.f90 && ./a.out (8.33329E-11,2.22331E-20) (8.33329E-11,2.22331E-20) (0.,0.) So, the question becomes why the contant folding gets a different result from the runtime evaluation.
[Bug middle-end/79720] floating point result different at compile time / runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79720 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2017-02-26 Ever confirmed|0 |1 --- Comment #3 from Dominique d'Humieres --- Where is computed 1./a? AFAICT the roundoff errors difference with optimization is restricted to this computation.
[Bug middle-end/79720] floating point result different at compile time / runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79720 --- Comment #4 from Thomas Koenig --- (In reply to Dominique d'Humieres from comment #3) > Where is computed 1./a? AFAICT the roundoff errors difference with > optimization is restricted to this computation. Yep, you're right... seems that constant of complex division is off. So here is a new, much shorter test case: $ cat r3.f90 program main complex :: c1, c2, r1, r2 character(len=50) :: inp c1 = (12e10, -3.2) inp = '(12e10, -3.2)' read (unit=inp, fmt=*) c2 ! Hide the assignment from the optimizer print *,'c1 - c2 = ', c1-c2 ! Should be zero r1 = 1/c1 ! Compile-time assignment r2 = 1/c2 ! Run-time assignment print *,'r1 = ', r1 print *,'r2 = ', r2 print *,'r1 - r2 = ', r1-r2 ! Should be zero, but is not. end program main $ gfortran -O r3.f90 $ ./a.out c1 - c2 = (0.,0.) r1 =(8.33155E-12,2.22180E-22) r2 =(8.33155E-12,2.21927E-22) r1 - r2 = (0.,2.524354897E-29)
[Bug middle-end/79720] [6/7 Regression] complex division different at compile time / runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79720
Thomas Koenig changed:
What|Removed |Added
Keywords||wrong-code
Status|WAITING |NEW
Target Milestone|--- |7.0
Summary|floating point result |[6/7 Regression] complex
|different at compile time / |division different at
|runtime |compile time / runtime
--- Comment #5 from Thomas Koenig ---
Here's a C test case. I chose the %a format for
printf to better show what is going on:
#include
#include
#include
char input[] = "1.2e10 -3.2";
int main()
{
float complex c1, c2, r1, r2;
float re, im;
c1 = 1.2e10f - 3.2f*I;
sscanf(input,"%f %f", &re, &im);
c2 = re + im*I;
printf("c1 = (%a, %a) c2 = (%a, %a)\n", crealf(c1), cimagf(c1),
crealf(c2), cimagf(c2));
printf("c1 - c2 = (%a, %a)\n", crealf(c1)-crealf(c2),
cimagf(c1)-cimagf(c2));
r1 = 1/c1;
r2 = 1/c2;
printf("r1 = (%a, %a) r2 = (%a, %a)\n", crealf(r1), cimagf(r1),
crealf(r2), cimagf(r2));
printf("r1 - r2 = (%a, %a)\n", crealf(r1)-crealf(r2),
cimagf(r1)-cimagf(r2));
return 0;
}
$ gcc -O re.c && ./a.out
c1 = (0x1.65a0bcp+33, -0x1.9ap+1) c2 = (0x1.65a0bcp+33, -0x1.9ap+1)
c1 - c2 = (0x0p+0, 0x0p+0)
r1 = (0x1.6e80fep-34, 0x1.a3c414p-66) r2 = (0x1.6e80fep-34, 0x1.a3c412p-66)
r1 - r2 = (0x0p+0, 0x1p-89)
So, two ULP difference.
There is no difference with gcc 4.3.2:
tkoenig@gcc12:~$ gcc -O re.c
tkoenig@gcc12:~$ ./a.out
c1 = (0x1.65a0bcp+33, -0x1.9ap+1) c2 = (0x1.65a0bcp+33, -0x1.9ap+1)
c1 - c2 = (0x0p+0, 0x0p+0)
r1 = (0x1.6e80fep-34, 0x1.a3c412p-66) r2 = (0x1.6e80fep-34, 0x1.a3c412p-66)
r1 - r2 = (0x0p+0, 0x0p+0)
tkoenig@gcc12:~$ gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3
--program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --enable-cld --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.3.2 (Debian 4.3.2-1.1)
but gcc 6 and 7 fail.
[Bug middle-end/79720] [6/7 Regression] complex division different at compile time / runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79720 --- Comment #6 from Dominique d'Humieres --- > but gcc 6 and 7 fail. So does 4.8, 4.9, and 5. IMO this PR should be closed as invalid: the assumption that the roundoff errors don't depend on the optimization level is wrong.
[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
--- Comment #12 from Bernd Edlinger ---
Hi,
I don't know if it helps, but on the assembler level there are only two
instructions that need to be moved to make the test case pass:
diff -u rh1422456-orig.s rh1422456.s
--- rh1422456-orig.s2017-02-26 22:46:30.068919262 +0100
+++ rh1422456.s 2017-02-26 22:46:56.445920712 +0100
@@ -2046,10 +2046,10 @@
ldr ip, [r4, #100]
add lr, sp, #52
movwr3,
#:lower16:_ZZN5boost9function4IbRN9__gnu_cxx17__normal_iteratorIPKcNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcERKSB_RNS_6spirit7contextINS_6fusion4consIRSA_NSH_4nil_EEENSH_6vectorIJERKNSF_2qi10char_classINSF_3tag9char_codeINSS_5spaceENSF_13char_encoding13standard_wideEE9assign_toINSQ_6detail13parser_binderINSQ_4plusINSQ_10differenceINSR_INST_INSS_5char_ESW_NSQ_12literal_charINSV_8standardELb1ELb0EEEN4mpl_5bool_ILb1EEEvT_E13stored_vtable
+ strbr6, [sp, #293]
ldm r5, {r0, r1, r2}
cmp ip, #0
movtr3,
#:upper16:_ZZN5boost9function4IbRN9__gnu_cxx17__normal_iteratorIPKcNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcERKSB_RNS_6spirit7contextINS_6fusion4consIRSA_NSH_4nil_EEENSH_6vectorIJERKNSF_2qi10char_classINSF_3tag9char_codeINSS_5spaceENSF_13char_encoding13standard_wideEE9assign_toINSQ_6detail13parser_binderINSQ_4plusINSQ_10differenceINSR_INST_INSS_5char_ESW_NSQ_12literal_charINSV_8standardELb1ELb0EEEN4mpl_5bool_ILb1EEEvT_E13stored_vtable
- strbr6, [sp, #293]
orr r3, r3, #1
str r7, [sp, #288]
str r3, [sp, #48]
@@ -2062,10 +2062,10 @@
ldr ip, [r4, #144]
add lr, sp, #68
movwr3,
#:lower16:_ZZN5boost9function4IbRN9__gnu_cxx17__normal_iteratorIPKcNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcERKSB_RNS_6spirit7contextINS_6fusion4consIRSA_NSH_4nil_EEENSH_6vectorIJERKNSF_11unused_typeEE9assign_toINSF_2qi6detail13parser_binderINSV_16lexeme_directiveINSV_4plusINSV_10differenceINSV_10char_classINSF_3tag9char_codeINS12_5char_ENSF_13char_encoding13standard_wideENSV_12literal_charINS15_8standardELb1ELb0EN4mpl_5bool_ILb1EEEvT_E13stored_vtable
+ strbr6, [sp, #293]
ldm r5, {r0, r1, r2}
cmp ip, #0
movtr3,
#:upper16:_ZZN5boost9function4IbRN9__gnu_cxx17__normal_iteratorIPKcNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcERKSB_RNS_6spirit7contextINS_6fusion4consIRSA_NSH_4nil_EEENSH_6vectorIJERKNSF_11unused_typeEE9assign_toINSF_2qi6detail13parser_binderINSV_16lexeme_directiveINSV_4plusINSV_10differenceINSV_10char_classINSF_3tag9char_codeINS12_5char_ENSF_13char_encoding13standard_wideENSV_12literal_charINS15_8standardELb1ELb0EN4mpl_5bool_ILb1EEEvT_E13stored_vtable
- strbr6, [sp, #293]
orr r3, r3, #1
str r7, [sp, #288]
str r3, [sp, #64]
=> r5 = sp+292, so strb and ldm overlap.
In the reload pass I can find the sp+293 mem rtx:
(insn 593 1693 598 67 (parallel [
(set (reg:SI 0 r0)
(mem/c:SI (reg/f:SI 5 r5 [680]) [19 MEM[(struct
function4D.541978 *)&D.615141].D.542200.functorD.466600+0 S4 A32]))
(set (reg:SI 1 r1)
(mem/c:SI (plus:SI (reg/f:SI 5 r5 [680])
(const_int 4 [0x4])) [19 MEM[(struct function4D.541978
*)&D.615141].D.542200.functorD.466600+4 S4 A32]))
(set (reg:SI 2 r2)
(mem/c:SI (plus:SI (reg/f:SI 5 r5 [680])
(const_int 8 [0x8])) [19 MEM[(struct function4D.541978
*)&D.615141].D.542200.functorD.466600+8 S4 A32]))
]) "rh1422456.cc":151826 364 {*ldm3_}
(nil))
(insn 598 593 586 67 (set (reg:CC 100 cc)
(compare:CC (reg/f:SI 12 ip [orig:181 _251 ] [181])
(const_int 0 [0]))) "rh1422456.cc":151823 196 {*arm_cmpsi_insn}
(nil))
(insn 586 598 591 67 (set (mem/c:QI (plus:SI (reg/f:SI 13 sp)
(const_int 293 [0x125])) [101 MEM[(struct parser_binderD.572000
*)&D.615141 + 5B]+0 S1 A8])
(reg:QI 6 r6 [493])) 192 {*arm_movqi_insn}
(nil))
... and:
(insn 878 1691 883 99 (parallel [
(set (reg:SI 0 r0)
(mem/c:SI (reg/f:SI 5 r5 [680]) [19 MEM[(struct
function4D.546780 *)&D.615194].D.547000.functorD.466600+0 S4 A32]))
(set (reg:SI 1 r1)
(mem/c:SI (plus:SI (reg/f:SI 5 r5 [680])
(const_int 4 [0x4])) [19 MEM[(struct function4D.546780
*)&D.615194].D.547000.functorD.466600+4 S4 A32]))
(set (reg:SI 2 r2)
(mem/c:SI (plus:SI (reg/f:SI 5 r5 [680])
(const_int 8 [0x8])) [19 MEM[(struct function4D.546780
[Bug middle-end/79720] [5/6/7 Regression] complex division different at compile time / runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79720 Thomas Koenig changed: What|Removed |Added Summary|[6/7 Regression] complex|[5/6/7 Regression] complex |division different at |division different at |compile time / runtime |compile time / runtime --- Comment #7 from Thomas Koenig --- (In reply to Dominique d'Humieres from comment #6) > IMO this PR should be closed as invalid: the assumption that the roundoff > errors don't depend on the optimization level is wrong. There are very many optimizations that we do not do in order not to change floating point results from what the user wrote. For example, the flag -freciprocal-math to control if x / y can be replaced by x * (1 / y). This can lose you around one to two ULP, same as we have here. We also do a quite complex (sorry for the pun) and expensive division routine, just in order not to lose any bits of precision. If the compile-time simplification does not match that, it is simply buggy.
[Bug middle-end/79720] [5/6/7 Regression] complex division different at compile time / runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79720
--- Comment #8 from Thomas Koenig ---
Test case for double complex:
$ cat re-d.c
#include
#include
#include
char input[] = "1.2e20 -3.2";
int main()
{
double complex c1, c2, r1, r2;
double re, im;
c1 = 1.2e20 - 3.2*I;
sscanf(input,"%lf %lf", &re, &im);
c2 = re + im*I;
printf("c1 = (%a, %a)\nc2 = (%a, %a)\n", creal(c1), cimag(c1),
creal(c2), cimag(c2));
printf("c1 - c2 = (%a, %a)\n", creal(c1)-creal(c2),
cimag(c1)-cimag(c2));
r1 = 1/c1;
r2 = 1/c2;
printf("r1 = (%a, %a) r2 = (%a, %a)\n", creal(r1), cimag(r1),
creal(r2), cimag(r2));
printf("r1 - r2 = (%a, %a)\n", creal(r1)-creal(r2),
cimag(r1)-cimag(r2));
return 0;
}
$ gcc -O -Wall -Wextra re.c && ./a.out
c1 = (0x1.a055690d9db8p+66, -0x1.ap+1)
c2 = (0x1.a055690d9db8p+66, -0x1.ap+1)
c1 - c2 = (0x0p+0, 0x0p+0)
r1 = (0x1.3ad30dfcf371dp-67, 0x1.35bb89da10c03p-132) r2 =
(0x1.3ad30dfcf371dp-67, 0x1.35bb89da10c04p-132)
r1 - r2 = (0x0p+0, -0x1p-184)
[Bug middle-end/79720] [5/6/7 Regression] complex division different at compile time / runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79720 --- Comment #9 from Andrew Pinski --- Most likely related to PR 59714.
[Bug libgcc/59714] complex division is surprising on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59714 --- Comment #5 from Andrew Pinski --- Also see PR 19974.
[Bug middle-end/79720] [5/6/7 Regression] complex division different at compile time / runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79720 --- Comment #10 from Marc Glisse --- (In reply to Thomas Koenig from comment #7) > We also do a quite complex (sorry for the pun) and expensive > division routine, just in order not to lose any bits of precision. > If the compile-time simplification does not match that, it is > simply buggy. If anything, I expect that the compile-time evaluation (using MPC) is more precise than what you get by chaining real add/sub/mul/div, even if that's a relatively expensive routine to reduce errors.
[Bug tree-optimization/79721] New: Scalar evolution introduces signed overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79721
Bug ID: 79721
Summary: Scalar evolution introduces signed overflow
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: krister.walfridsson at gmail dot com
Target Milestone: ---
The function
int foo(int a, int b)
{
int sum = 0;
for (int i = 0; i < 6; i++)
{
sum += a + i * b;
}
return sum;
}
is transformed to
int _11;
int _12;
int _13;
int _16;
[...]
_16 = b_7(D) + a_8(D);
_13 = _16 * 5;
_12 = b_7(D) * 1799910001;
_11 = _12 + _13;
sum_17 = _11 + a_8(D);
return sum_17;
by scalar evolution when compiled as "gcc -O3 -c bug.c". The original function
could calculate foo(-3, 2) without any signed integer overflow, but the
transformed function will overflow in the multiplication _12.
