[Bug target/27117] [4.2 Regression] gcc fails to build on sh64-elf targets
-- bonzini at gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bonzini at gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-12 07:11:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27117
[Bug target/27117] [4.2 Regression] gcc fails to build on sh64-elf targets
--- Comment #2 from bonzini at gnu dot org 2006-04-12 07:30 --- And the funny part is, it is again Dale's patch that causes the failure. I'm more and more inclined to revert that part, but it may be a latent bug as in the AIX case (note: David Edelsohn decided to "fix" the bug by making sure the problematic RTL is not produced, but it still was an rs6000 latent bug in some sense). So, if Joern wants to take a look... -- bonzini at gnu dot org changed: What|Removed |Added CC||amylaar at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27117
[Bug target/27117] [4.2 Regression] gcc fails to build on sh64-elf targets
--- Comment #9 from bonzini at gnu dot org 2006-04-18 08:13 --- I'm reverting the PR19653 regclass.c patch for now. Joern of course if you want to post your patch for testing, it'll help reinstating the patch in 4.3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27117
[Bug tree-optimization/26821] [4.1 Regression] ice in varasm.c with certain flags
--- Comment #7 from bonzini at gnu dot org 2006-04-18 13:25 --- patch committed. -- bonzini at gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work|4.0.3 4.2.0 |4.0.3 4.1.1 4.2.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26821
[Bug target/27117] [4.2 Regression] gcc fails to build on sh64-elf targets
--- Comment #11 from bonzini at gnu dot org 2006-04-18 13:26 --- bug is latent again :-) -- bonzini at gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27117
[Bug target/27158] [4.1/4.2 regression] ICE in extract_insn with -maltivec
--- Comment #8 from bonzini at gnu dot org 2006-04-18 13:47 --- Seems similar to PR24230, but cannot be fixed really in the same way. -- bonzini at gnu dot org changed: What|Removed |Added CC||bonzini at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27158
[Bug middle-end/26869] [4.1/4.2 Regression] Segfault in find_lattice_value() for complex operands.
--- Comment #4 from bonzini at gnu dot org 2006-04-18 13:55 --- richi: if bD.1520 does not have a default def because it is unused, your fix makes sense. Can you confirm that it is "b" and not "c" that does not have a default def, i.e. that "c" does have a default def? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26869
[Bug target/26600] [4.1/4.2 Regression] internal compiler error: in push_reload, at reload.c:1303
--- Comment #6 from bonzini at gnu dot org 2006-04-18 14:07 --- pinskia: You're right in some sense but, shudder, this will make things slw. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26600
[Bug middle-end/26643] [4.1 Regression] Linux matroxfb_probe miscompiled
--- Comment #15 from bonzini at gnu dot org 2006-04-18 14:12 --- running a 4.1 bootstrap. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26643
[Bug tree-optimization/20643] [4.0/4.1/4.2 Regression] Tree loop optimizer does worse job than RTL loop optimizer
--- Comment #8 from bonzini at gnu dot org 2006-04-18 14:15 --- Mark, I don't believe there is any chance that it be fixed in 4.0/4.1? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20643
[Bug middle-end/20983] [4.0/4.1/4.2 Regression] varargs functions force va_list variable to stack unnecessarily
--- Comment #7 from bonzini at gnu dot org 2006-04-18 14:16 --- Caused by removing ADDRESSOF. :-( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20983
[Bug middle-end/26643] [4.1 Regression] Linux matroxfb_probe miscompiled
--- Comment #18 from bonzini at gnu dot org 2006-04-18 14:23 --- patch committed to 4.1 too. -- bonzini at gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26643
[Bug target/27158] [4.1/4.2 regression] ICE in extract_insn with -maltivec
--- Comment #9 from bonzini at gnu dot org 2006-04-18 14:29 --- The mem is for a (const_vector:V4SF [ (const_double:SF -NaN [-NaN]) (const_double:SF -NaN [-NaN]) (const_double:SF -NaN [-NaN]) (const_double:SF -NaN [-NaN]) ]) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27158
[Bug target/27158] [4.1/4.2 regression] ICE in extract_insn with -maltivec
--- Comment #10 from bonzini at gnu dot org 2006-04-18 14:39 --- It's probably two different bugs, since the 4.1 bug is in loop.c. We need to add a can_assign_to_reg_p call before creating a movable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27158
[Bug target/27158] [4.1/4.2 regression] ICE in extract_insn with -maltivec
--- Comment #11 from bonzini at gnu dot org 2006-04-18 15:20 ---
... but then anyway the bug pops up in reload. So it is definitely the same
bug as PR24230, and here is a modified version of the PR24230 testcase:
/* Compile with -O2 -maltivec */
#define REGLIST \
"77", "78", "79", "80", "81", "82", "83", "84", "85", "86",\
"87", "88", "89", "90", "91", "92", "93", "94", "95", "96",\
"97", "98", "99", "100", "101", "102", "103", "104", "105", "106",\
"107", "108"
typedef __attribute__ ((vector_size (16))) float v4sf;
void
foo (int H)
{
volatile v4sf tmp;
while (H-- > 0)
{
asm ("" : : : REGLIST);
tmp = (v4sf) __builtin_altivec_vspltisw (1);
}
}
fails on 4.1, didn't test on 4.2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27158
[Bug c++/26534] [4.1/4.2 Regression] bitfield wrong optimize
--- Comment #4 from bonzini at gnu dot org 2006-04-18 15:27 --- And is the precision only encoded in FIELD_DECLs, for the C front-end as well? -- bonzini at gnu dot org changed: What|Removed |Added CC||bonzini at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26534
[Bug c++/27129] [4.1/4.2 Regression] ICE in get_expr_operands
--- Comment #3 from bonzini at gnu dot org 2006-04-18 16:12 --- Without getting in the merit of the bug, let me point out that GCC is *not* free to make hard errors at its own will. What is an error and what isn't is regulated by the standard, and GCC aims at adhering to the standard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27129
[Bug c++/26195] [4.0/4.1/4.2 regression] pragma interface no longer handles explicit names
--- Comment #10 from bonzini at gnu dot org 2006-04-18 16:18 --- No, except in the unlikely case that the fix is hard to backport to 4.0.x. Backports to older release branches (in this case 4.0.x) are evaluated on a case-by-case basis. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26195
[Bug rtl-optimization/26069] [4.0/4.1/4.2 Regression] Runtime endian-ness check is no longer optimized out.
--- Comment #8 from bonzini at gnu dot org 2006-04-18 16:22 --- Richard, Roger's patch for VIEW_CONVERT_EXPR folding hit mainline now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26069
[Bug middle-end/26869] [4.1 Regression] Segfault in find_lattice_value() for complex operands.
--- Comment #11 from bonzini at gnu dot org 2006-04-24 11:44 --- patch applied to 4.2, 4.1 still not working -- bonzini at gnu dot org changed: What|Removed |Added Known to fail|4.1.0 4.2.0 |4.1.0 Known to work|4.0.3 |4.0.3 4.2.0 Summary|[4.1/4.2 Regression]|[4.1 Regression] Segfault in |Segfault in |find_lattice_value() for |find_lattice_value() for|complex operands. |complex operands. | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26869
[Bug target/27282] [4.2 regression] ICE in final_scan_insn, at final.c:2448 - could not split insn
--- Comment #5 from bonzini at gnu dot org 2006-04-25 06:37 --- Sure. The code meant to do so using trunc_int_for_mode, but it does not work because constop is unsigned. The trunc_int_for_mode was introduced in http://gcc.gnu.org/ml/gcc-patches/2002-01/msg01397.html to cure a similar ICE; and the bug is latent on all branches since it dates back (through various changes, notably r49112 by amodra) to the dawn of the original old-gcc repository. Bootstrapping this patch on i686-pc-linux-gnu, ok if it passes? What about 4.1? Index: gcc-fwprop/gcc/combine.c === --- gcc-fwprop/gcc/combine.c(revision 113024) +++ gcc-fwprop/gcc/combine.c(working copy) @@ -8190,6 +8190,5 @@ simplify_and_const_int_1 (enum machine_m return NULL_RTX; /* Otherwise, return an AND. */ - constop = trunc_int_for_mode (constop, mode); - return simplify_gen_binary (AND, mode, varop, GEN_INT (constop)); + return simplify_gen_binary (AND, mode, varop, gen_int_mode (constop, mode)); } Paolo -- bonzini at gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bonzini at gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-04-25 00:53:57 |2006-04-25 06:37:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27282
[Bug target/27282] [4.2 regression] ICE in final_scan_insn, at final.c:2448 - could not split insn
--- Comment #11 from bonzini at gnu dot org 2006-04-26 07:13 --- unassigning since David and Andrew's patch works, but mine does not. My patch BTW could be a minor cleanup, but it is not even necessary because GEN_INT (trunc_int_for_mode (...)) does not drop sign bits (it just introduces unnecessary but harmless casts between unsigned and signed HOST_WIDE_INTs). -- bonzini at gnu dot org changed: What|Removed |Added AssignedTo|bonzini at gnu dot org |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27282
[Bug target/27390] [4.2 Regression] gcc.target/x86_64/abi/test_complex_returning.c execution fails at -O0
--- Comment #3 from bonzini at gnu dot org 2006-05-22 07:24 --- Hi richi, may I ask why I was added to the CC? Did I cause this bug? :-P -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27390
[Bug bootstrap/27674] [4.2 Regression] make -j3 all-gcc fails when building natively
--- Comment #1 from bonzini at gnu dot org 2006-05-25 08:21 --- Testing a patch. -- bonzini at gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bonzini at gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-05-25 08:21:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27674
[Bug bootstrap/27674] [4.2 Regression] make -j3 all-gcc fails when building natively
--- Comment #2 from bonzini at gnu dot org 2006-05-25 08:29 --- Created an attachment (id=11510) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11510&action=view) prototype patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27674
[Bug bootstrap/25453] [4.2 Regression] --disable-bootstrap is not documented
--- Comment #4 from bonzini at gnu dot org 2006-05-25 08:45 --- Created an attachment (id=11511) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11511&action=view) patch to document the option -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25453
[Bug target/27390] [4.2 Regression] gcc.target/x86_64/abi/test_complex_returning.c execution fails at -O0
--- Comment #6 from bonzini at gnu dot org 2006-05-26 07:46 ---
There are indeed differences in the generated code.
aj_f_times2 is equal without and with the patch.
aj_d_times2 has this (left = old, right = patched):
movsd %xmm0, -40(%rbp) | movsd %xmm0, -32(%rbp)
movq-40(%rbp), %rax | movsd %xmm1, -24(%rbp)
movsd %xmm1, -40(%rbp) <
movq-40(%rbp), %rdx <
movq%rax, -32(%rbp) <
movq%rdx, -24(%rbp) <
This is just better code.
The miscompiled function is aj_ld_times2, which is like this (some code moved
for clarity):
fldt16(%rbp) fldt16(%rbp)
fadd%st(0), %stfadd%st(0), %st
fstpt -48(%rbp) fstpt -48(%rbp)
So far so good.
movq-32(%rbp), %raxmovq-32(%rbp), %rax
movl-24(%rbp), %edxmovl-24(%rbp), %edx
movq%rax, -32(%rbp)movq%rax, -32(%rbp)
movl%edx, -24(%rbp)movl%edx, -24(%rbp)
Useless, and also accessing uninitialized memory, but this is -O0.
fldt32(%rbp) fldt32(%rbp)
fadd%st(0), %stfadd%st(0), %st
fstpt -32(%rbp) fstpt -32(%rbp)
Also good.
movq-48(%rbp), %raxmovq-48(%rbp), %rax
movl-40(%rbp), %edxmovl-40(%rbp), %edx
movq%rax, -48(%rbp)movq%rax, -48(%rbp)
movl%edx, -40(%rbp)movl%edx, -40(%rbp)
Useless.
movq-48(%rbp), %raxmovq-48(%rbp), %rax
movl-40(%rbp), %edxmovl-40(%rbp), %edx
movq-32(%rbp), %rcxmovq-32(%rbp), %rcx
movl-24(%rbp), %ebxmovl-24(%rbp), %ebx
These are -O0 stupidities.
flds.LC0(%rip) <
fstp%st(0) <
fstp%st(1) <
I don't have a clue what this is for. What is .LC0? The only thing I'm sure
about, is that this causes a stack underflow...
movq%rax, -64(%rbp)movq%rax, -64(%rbp)
movl%edx, -56(%rbp)movl%edx, -56(%rbp)
fldt-64(%rbp) fldt-64(%rbp)
movq%rcx, -64(%rbp)movq%rcx, -64(%rbp)
movl%ebx, -56(%rbp)movl%ebx, -56(%rbp)
fldt-64(%rbp) fldt-64(%rbp)
> flds.LC0(%rip)
> fstp%st(0)
> fstp%st(1)
... the bug is that it is moved afterwards, after the result was loaded on the
stack, and the underflowing fstp clobbers the return value.
The wrong instruction is produced by a (clobber (reg/i:XC 8 st)). The patched
GCC moves the clobber later. The RTL produced by the patched GCC is sane until
flow2, and the messed up by the stack register conversion pass:
(insn 41 57 58 3 (set (reg:XF 10 st(2) [orig:66 ] [66])
(mem/c:XF (plus:DI (reg/f:DI 6 bp)
(const_int -64 [0xffc0])) [0 S16 A8])) 99
{*movxf_integer} (nil)
(nil))
...
(insn 43 59 25 3 (set (reg:XF 11 st(3) [orig:67 +16 ] [67])
(mem/c:XF (plus:DI (reg/f:DI 6 bp)
(const_int -64 [0xffc0])) [0 S16 A8])) 99
{*movxf_integer} (nil)
(nil))
(note 25 43 28 3 NOTE_INSN_FUNCTION_END)
(insn 28 25 29 3 (clobber (reg/i:XC 8 st)) -1 (nil)
(nil))
(insn 29 28 30 3 (set (reg:XF 8 st [ ])
(reg:XF 10 st(2) [orig:66 ] [66])) 99 {*movxf_integer} (nil)
(nil))
(insn 30 29 35 3 (set (reg:XF 9 st(1) [+16 ])
(reg:XF 11 st(3) [orig:67 +16 ] [67])) 99 {*movxf_integer}
(nil)
(nil))
(insn 35 30 64 3 (use (reg/i:XC 8 st)) -1 (nil)
(nil))
Latent bug in stack, CCing sayle.
--
bonzini at gnu dot org changed:
What|Removed |Added
CC||sayle at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27390
[Bug target/27390] [4.2 Regression] gcc.target/x86_64/abi/test_complex_returning.c execution fails at -O0
--- Comment #7 from bonzini at gnu dot org 2006-05-29 07:24 --- The problem is that regstack is wrong when it comes to handling COMPLEX_FLOAT_MODEs. To handle clobbers, it calls move_nan_to_stack_reg twice on the same insn. But the second call does *not* add a new insn, so we get only one flds instead of two. There is also something wrong in emit_pop_insn of a complex float, because if we fix the above we get a flds .LC0 flds .LC0 fstp %st fstp %st(1) which is still wrong: we should have two fstps to %st. The solution is probably to emit two distinct clobbers with XFmode instead of one with a complex mode. Paolo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27390
[Bug target/27390] [4.2 Regression] gcc.target/x86_64/abi/test_complex_returning.c execution fails at -O0
--- Comment #8 from bonzini at gnu dot org 2006-05-29 09:38 --- Created an attachment (id=11527) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11527&action=view) patch to fix the bug I would appreciate testing this patch on x86_64, also because it touches some squeaky code that implements the x86-64 ABI. I am quite sure it does not change the ABI, but given that we are in stage3 I think more accurate testing is necessary. -- bonzini at gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bonzini at gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27390
[Bug tree-optimization/26830] [4.2 Regression] Repeated SSA update during loop header copying
--- Comment #40 from bonzini at gnu dot org 2006-05-30 06:20 --- We're on par with 4.0, we can close this now. The memory hog bug (27004) is still open. -- bonzini at gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26830
[Bug bootstrap/25453] [4.2 Regression] --disable-bootstrap is not documented
--- Comment #6 from bonzini at gnu dot org 2006-06-01 12:33 --- documentation committed. -- bonzini at gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25453
[Bug bootstrap/26582] [4.2 Regression] warning with cross build
--- Comment #6 from bonzini at gnu dot org 2006-06-05 07:10 --- This was fixed recently. -- bonzini at gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26582
[Bug target/27390] [4.2 Regression] gcc.target/x86_64/abi/test_complex_returning.c execution fails at -O0
--- Comment #10 from bonzini at gnu dot org 2006-06-05 07:23 --- Created an attachment (id=11594) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11594&action=view) a different attempt I don't like this patch, as I think it is based on too many assumptions. The idea is to assume that a clobber:XC is only present in the epilogue (at the beginning of the epilogue) and fix a couple of bugs in its handling. I will write more information as soon as I submit the patch to the mailing list; in the meanwhile, testing is appreciated. Thanks very much in advance. -- bonzini at gnu dot org changed: What|Removed |Added Attachment #11527|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27390
[Bug bootstrap/26188] [4.2 Regression] 4.2.0 fails to compile on FreeBSD 4.11
--- Comment #5 from bonzini at gnu dot org 2006-06-05 10:20 --- Created an attachment (id=11596) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11596&action=view) patch to test can anybody test this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26188
[Bug bootstrap/27674] [4.2 Regression] make -j3 all-gcc fails when building natively
--- Comment #5 from bonzini at gnu dot org 2006-06-05 17:17 --- thanks, committed. -- bonzini at gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27674
[Bug target/27390] [4.2 Regression] gcc.target/x86_64/abi/test_complex_returning.c execution fails at -O0
--- Comment #13 from bonzini at gnu dot org 2006-06-05 17:33 --- Created an attachment (id=11597) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11597&action=view) and a third one If this one works, I'd very much prefer it to the one I posted this morning. It fixes the testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27390
[Bug target/27390] [4.2 Regression] gcc.target/x86_64/abi/test_complex_returning.c execution fails at -O0
--- Comment #14 from bonzini at gnu dot org 2006-06-06 12:10 --- Patch pr27390-more.patch was bootstrapped/regtested and the approach was confirmed to be ok by Roger. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27390
[Bug bootstrap/26188] [4.2 Regression] 4.2.0 fails to compile on FreeBSD 4.11
--- Comment #7 from bonzini at gnu dot org 2006-06-07 12:01 --- Created an attachment (id=11623) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11623&action=view) updated libdecnumber configure script try this. don't forget to not include fortran because it includes stdint.m4 too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26188
[Bug target/27390] [4.2 Regression] gcc.target/x86_64/abi/test_complex_returning.c execution fails at -O0
--- Comment #16 from bonzini at gnu dot org 2006-06-07 12:08 --- fixed. -- bonzini at gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27390
[Bug bootstrap/26188] [4.2 Regression] 4.2.0 fails to compile on FreeBSD 4.11
--- Comment #9 from bonzini at gnu dot org 2006-06-08 06:10 --- Created an attachment (id=11630) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11630&action=view) a supposedly correct patch No, the patch was wrong. Also the original proposed patch was right that some messages mistake intptr_t with intmax_t. This patch adds the detection of intptr_t where it really belongs, i.e. where an incomplete stdint.h like FreeBSD's is detected. -- bonzini at gnu dot org changed: What|Removed |Added Attachment #11596|0 |1 is obsolete|| Attachment #11623|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26188
[Bug bootstrap/26188] [4.2 Regression] 4.2.0 fails to compile on FreeBSD 4.11
--- Comment #10 from bonzini at gnu dot org 2006-06-08 06:20 --- Created an attachment (id=11631) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11631&action=view) really a different patch Sorry, I attached the wrong patch again. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26188
[Bug target/15184] [4.0/4.1/4.2 Regression] Direct access to byte inside word not working with -march=pentiumpro
--- Comment #11 from bonzini at gnu dot org 2006-06-08 08:36 --- I would note, however, that Pentium Pro also means Pentium 2/3/M, Core, etc. In practice every Intel chip after the Pentium Pro, except the P4 and Nocona, is based on that pipeline. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15184
[Bug middle-end/27733] [4.1/4.2 Regression] Large compile time regression
--- Comment #10 from bonzini at gnu dot org 2006-06-08 12:08 ---
Reduced testcase:
long foo(long zz)
{
return zz * 15238614669586151335;
}
takes "ridiculously long" with -O2 -mdisable-fpregs.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27733
[Bug middle-end/27733] [4.1/4.2 Regression] Large compile time regression
--- Comment #11 from bonzini at gnu dot org 2006-06-08 12:24 --- OUCH! The number is stored as a unsigned int in the cache, which means that numbers > 2^32 never hit the cache! Besides that, it's wise to enlarge the cache for 64-bit hosts, because there every EXACT_DIV_EXPR will call synth_mult with a very large multiplier. Time for a -O0 compiler on the reduced testcase is down to 0.3s for 2069 cache entries, and 0.8s for 1031 cache entries. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27733
[Bug middle-end/27733] [4.1/4.2 Regression] Large compile time regression
--- Comment #12 from bonzini at gnu dot org 2006-06-08 12:26 --- Created an attachment (id=11634) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11634&action=view) proposed patch -- bonzini at gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bonzini at gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27733
[Bug middle-end/27733] [4.1/4.2 Regression] Large compile time regression
--- Comment #14 from bonzini at gnu dot org 2006-06-08 15:37 --- Well, it shouldn't. My guess could be that we are hitting the case where the logic is flawed. The we fill the cache with the algorithm for say 0x10085 (but then we only write 0x84 in the cache), and then use it for 0x85. The synth_mult logic then could be resilient enough to not generate wrong code but just code with wrong cost measures. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27733
[Bug target/27212] vec_cmplt followed by a vec_all_ge, gives two vcmpgtuh instructions
--- Comment #5 from bonzini at gnu dot org 2006-06-09 08:15 --- I'll give it a shot. If combine could, well, combine the two instructions, it would be quite easy to make a patch, and it would remove some most hackish aspects of the Altivec implemention. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27212
[Bug middle-end/27733] [4.1 Regression] Large compile time regression
--- Comment #19 from bonzini at gnu dot org 2006-06-13 13:06 --- Fixed, but we may want the patch on 4.0 too. -- bonzini at gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail|4.1.0 |4.1.1 Known to work|4.0.4 4.2.0 |4.0.4 4.1.2 4.2.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27733
[Bug other/27063] Fail to build gcc-core-4.2 snapshots
--- Comment #3 from bonzini at gnu dot org 2006-06-15 06:33 --- I agree it is a packaging issue, but we can work around it and it can be useful for other front ends as well. Taking the bug. -- bonzini at gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bonzini at gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-04-13 01:44:51 |2006-06-15 06:33:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27063
[Bug other/27063] Fail to build gcc-core-4.2 snapshots
--- Comment #4 from bonzini at gnu dot org 2006-06-15 06:35 --- Also, fixing this PR would allow us to ship Objective-C++ in the objc tarball. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27063
[Bug bootstrap/26188] [4.2 Regression] 4.2.0 fails to compile on FreeBSD 4.11
--- Comment #12 from bonzini at gnu dot org 2006-06-15 07:21 --- Created an attachment (id=11670) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11670&action=view) updated configure script for libdecnumber Gerald, here it is. Again, don't forget to disable fortran. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26188
[Bug other/27063] Fail to build gcc-core-4.2 snapshots
--- Comment #6 from bonzini at gnu dot org 2006-07-03 07:58 --- patch committed, should be ok. -- bonzini at gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27063
[Bug tree-optimization/28218] [4.1 Regression] ICE when building Inkscape with gcc-4.1 with -O2 -ffast-math
--- Comment #4 from bonzini at gnu dot org 2006-07-04 17:03 --- I don't know where I got the idea that you can do calculate_dominance_info (CDI_DOMINATORS | CDI_POST_DOMINATORS); instead of calculate_dominance_info (CDI_DOMINATORS); calculate_dominance_info (CDI_POST_DOMINATORS); -- bonzini at gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bonzini at gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-07-04 14:26:45 |2006-07-04 17:03:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28218
[Bug tree-optimization/28218] [4.1 Regression] ICE when building Inkscape with gcc-4.1 with -O2 -ffast-math
--- Comment #7 from bonzini at gnu dot org 2006-07-05 06:49 --- patch committed to 4.1 branch and mainline (where it was latent) -- bonzini at gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28218
[Bug tree-optimization/32306] [4.2/4.3/4.4 Regression] redundant && || not eliminated
--- Comment #13 from bonzini at gnu dot org 2008-11-20 08:48 --- I agree with Steven that the bug title does not make sense. It is the same as complaining that IRA has a regression because it disables regmove. OTOH, this *is* a regression and the bug should stay open. For example, it could be fixed by doing some of the tree optimizations with && not lowered to jumps (just shooting). -- bonzini at gnu dot org changed: What|Removed |Added CC| |bonzini at gnu dot org Summary|[4.2/4.3/4.4 Regression] DOM|[4.2/4.3/4.4 Regression] |jump threading no longer|redundant && || not |iterates|eliminated http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32306
[Bug middle-end/30521] "if (i == n) ++i;" or "i += i == n;"?
--- Comment #7 from bonzini at gnu dot org 2008-11-22 10:15 --- Subject: Re: "if (i == n) ++i;" or "i += i == n;"? > The form of the code before CSE is caught in noce_try_addcc. The second form > obviously not (because we don't know that the value of i.20 is "i + 1"). > > So this comes down to a pass ordering problem. I'll just point out that the df merge allowed much better freedom in pass ordering. Ifconv1 could be anticipated before CSE and fwprop. Paolo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30521
[Bug tree-optimization/35639] [4.3/4.4 Regression] -fprofile-generate + PRE = big compile-time
--- Comment #8 from bonzini at gnu dot org 2008-11-22 16:00 --- The problem was that without -fprofile-generate the time spent there was basically zero. Since the profiling code is building a MST of the control-flow graph, it should produce absolutely no PRE opportunity and it's a pity that it causes such a slowdown. I wonder if there is some low-hanging fruit to eliminate value numbers that cannot be redundant. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35639
[Bug c/38308] New: -Wformat does not work for wide strings
GCC does not warn for this:
int main()
{
wprintf (L"%s", 5);
}
GCC should try converting the string to single-byte (e.g. to UTF-8, which would
work for any wchar_t encoding in which 0-127 maps to char's encoding) and test
the format string.
--
Summary: -Wformat does not work for wide strings
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38308
[Bug c++/38334] pmf accesses violate strict-aliasing rules
--- Comment #1 from bonzini at gnu dot org 2008-12-01 07:31 --- Why a ref-all pointer? Why not put the cast after the dereference instead? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38334
[Bug tree-optimization/38405] [4.4 Regression] (silent failure) handling bitfield in ternary
--- Comment #4 from bonzini at gnu dot org 2008-12-05 09:02 --- I'll look at it in a couple of days. In the meanwhile, could you please attach the dumps of vrp and the pass just before it? -- bonzini at gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bonzini at gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-12-05 09:02:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38405
[Bug tree-optimization/38405] [4.4 Regression] (silent failure) handling bitfield in ternary
--- Comment #6 from bonzini at gnu dot org 2008-12-05 15:42 --- Subject: Re: [4.4 Regression] (silent failure) handling bitfield in ternary > Folding statement: D.1241_5 = D.1242_4 != 0; > Folded into: D.1241_5 = (int) D.1242_4; > > which is wrong for > >D.1242; > > because it sign-extends. So it's probably in fold-const.c and latent in 4.3 too... Paolo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38405
[Bug tree-optimization/33928] [4.3/4.4 Regression] 22% performance slowdown from 4.2.2 to 4.3/4.4.0 in floating-point code
--- Comment #40 from bonzini at gnu dot org 2008-12-07 02:55 --- IIUC this is a typical case in which CSE was fixing something that earlier passes messed up. Unfortunately fwprop does (better) what CSE was meant to do, but does not do what I assumed was already done before CSE. If the problem is aliasing/FRE, then I think Richi is the one who could fix it for good in the tree passes. If there is more to it, however, I can take a look at why fwprop is generating the ugly code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928
[Bug middle-end/38572] [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
--- Comment #18 from bonzini at gnu dot org 2008-12-19 06:05 --- mine. -- bonzini at gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bonzini at gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-12-18 23:20:57 |2008-12-19 06:05:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38572
[Bug middle-end/38572] [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
--- Comment #19 from bonzini at gnu dot org 2008-12-22 08:52 ---
Smaller testcase, without uninitialized variables too:
enum JSOp
{
JSOP_GETELEM = 5,
JSOP_LIMIT
};
extern void g ();
void
f (char *pc, char *endpc, int format, char ***fp, enum JSOp op)
{
while (pc <= endpc)
{
if ((fp && *fp && pc == **fp) || pc == endpc)
{
if (format == 1)
op = (JSOp) 256;
else if (format == 2)
op = (JSOp) 257;
else
op = JSOP_GETELEM;
}
if (op >= JSOP_LIMIT)
{
if (format)
g ();
}
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38572
[Bug middle-end/38572] [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
--- Comment #20 from bonzini at gnu dot org 2008-12-22 09:05 --- This is a latent bug in the handling of out-of-bounds values. It happens because a value changes from [256, 256] to [256, 257]. VRP then forces the upper bound to the max-value of the type, generating the invalid range [256, 7]. We should punt and give VARYING. Probably caused by the tree-ssa-propagate.c hunk of my patch, but also probably latent. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38572
[Bug middle-end/38572] [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
--- Comment #21 from bonzini at gnu dot org 2008-12-22 09:30 --- Created an attachment (id=16961) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16961&action=view) patch being tested Testing a patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38572
[Bug debug/26908] -g3 (-ggdb3) emits broken calls to asm-defined functions
--- Comment #7 from bonzini at gnu dot org 2008-12-29 12:25 --- reopening... -- bonzini at gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26908
[Bug inline-asm/33932] miscalculation of asm labels with -g3
--- Comment #20 from bonzini at gnu dot org 2008-12-29 12:26 --- *** Bug 26908 has been marked as a duplicate of this bug. *** -- bonzini at gnu dot org changed: What|Removed |Added CC||ed at catmur dot co dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33932
[Bug debug/26908] -g3 (-ggdb3) emits broken calls to asm-defined functions
--- Comment #8 from bonzini at gnu dot org 2008-12-29 12:26 --- ... to close as duplicate (since there's some discussion on the other bug) *** This bug has been marked as a duplicate of 33932 *** -- bonzini at gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26908
[Bug target/33604] [4.3/4.4 Regression] Revision 119502 causes significantly slower results with 4.3/4.4 compared to 4.2
--- Comment #46 from bonzini at gnu dot org 2008-12-30 08:02 --- What benchmark.cpp was that? And did you test -O2 or -O3? Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33604
[Bug middle-end/38572] [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
--- Comment #23 from bonzini at gnu dot org 2008-12-30 10:38 --- Fixed. However, you should check if the code is valid C++ at all, because out-of-range enum values are handled differently in C and C++ (the bug stemmed from the fact that op was set to a value that is beyond what the C++ front-end had set as the maximum value of the enum). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38572
[Bug middle-end/38572] [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
--- Comment #24 from bonzini at gnu dot org 2008-12-30 10:39 --- patch committed -- bug may be latent on 4.3, but there is no known testcase. -- bonzini at gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38572
[Bug tree-optimization/35805] [ira] error in start_allocno_priorities, at ira-color.c:1806
--- Comment #5 from bonzini at gnu dot org 2009-01-02 08:17 --- Subject: Re: [ira] error in start_allocno_priorities, at ira-color.c:1806 Kenneth Zadeck wrote: > 2009-01-01 Kenneth Zadeck > > PR rtl-optimization/35805 > * df-problems.c (df_lr_finalize): Add recursive call to resolve lr > problem if fast dce is able to remove any instructions. > * dce.c (dce_process_block): Fix dump message. > > This patch fixes the problem. The comment in the patch describes the > issue.Since this was not really a failure, it would be hard to make > this issue into a testcase. IIUC the bugzilla comment trail, this caused gcc.c-torture/compile/930523-1.c to fail with --enable-checking=df; that's already a testcase. > Ok to commit? Hmmm... I am not sure I like this patch, for two reasons. 1) it might incur a compile-time penalty for the sake of verification, even with df checking disabled. OTOH having possibly different code for checking and non-checking compilation is even worse. 2) there are already provisions in dce.c to redo the analysis. But they do not get to the least fixed point because they just rebuild the local bitmaps and iterate from the existing solution. Instead of iterating "while (global_changed)", we could try doing only one iteration (it's a fast DCE after all, and the pessimistic dataflow makes me guess that subsequent DCE iterations won't find much?) and zap the solution there. This has the advantage that we can skip the recomputation if global_changed is false. Did I miss anything? Paolo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35805
[Bug tree-optimization/35805] [ira] error in start_allocno_priorities, at ira-color.c:1806
--- Comment #7 from bonzini at gnu dot org 2009-01-02 14:26 --- Subject: Re: [ira] error in start_allocno_priorities, at ira-color.c:1806 > I think so. The global changed flag allows it to delete the case: > > loop: > ... <- x // This is dead. > x- <- ... > go to loop > > it just is not going to get rid of it if there is is no kill of x inside > the loop. I just don't think it's acceptable to load each and every "fast DCE" with the burden of a full df solution. We need to find a way to limit this to the cases when it is needed, or at least not to be too conservative in ascertaining *when* it is needed. Hence my first and foremost question is: does it happen that the solution is wrong and global_changed never became true? If the answer is "definitely no", then an alternative preferrable patch would be to move the code you added to df-problems.c into dce.c, so that the full analysis (including rebuilding the bitmaps and iterating possibly many times) is not run if it was to yield the same answer that was before in the bitmaps. Paolo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35805
[Bug tree-optimization/35805] [ira] error in start_allocno_priorities, at ira-color.c:1806
--- Comment #10 from bonzini at gnu dot org 2009-01-02 16:33 --- Subject: Re: [ira] error in start_allocno_priorities, at ira-color.c:1806 > I will test this patch, but we still need to resolve your issues with my > approach. The problem is that you're really doubling the cost of computing the live registers. I know that previously it was wrong, but at this point there's no difference with the full-blown pass... Despite the idea of DF_LR_RUN_DCE being that it was "free", now it would do the same work as a pass_fast_rtl_dce modulo some O(#bbs) work. At this point, if your patch costs say 0.3%, and removing all traces of DF_LR_RUN_DCE (instead scheduling a dozen more pass_fast_rtl_dce in passes.c) costs 0.5%, I'd rather see the latter, at least it's easier to look for opportunities to remove some useless DCE. If it wasn't for verification, we could just decide that DF_LR_RUN_DCE is only for passes that can tolerate a little inaccurate info... Paolo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35805
[Bug tree-optimization/35805] [ira] error in start_allocno_priorities, at ira-color.c:1806
--- Comment #12 from bonzini at gnu dot org 2009-01-02 18:38 --- Subject: Re: [ira] error in start_allocno_priorities, at ira-color.c:1806 > StevenB talked me out of this because he considered it wrong to have > the client pass get conservative info. I agreed with him but I am > willing to change my mind if you really want to push your case. If there was preexisting discussion outside bugzilla, it's of course okay for me, and I'll not push my opinion beyond, but I'd still like to see some numbers. You can commit the second patch either before or after, I don't care. >> At this point, if your patch costs say 0.3%, and removing all traces >> DF_LR_RUN_DCE (instead scheduling a dozen more pass_fast_rtl_dce in >> passes.c) costs 0.5%, I'd rather see the latter, at least it's easier to >> look for opportunities to remove some useless DCE. I'll try to do this for 4.5. Paolo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35805
[Bug bootstrap/35804] Bootstrap of combined gcc + binutils, with --enable-shared, with sysroot fails
--- Comment #9 from bonzini at gnu dot org 2009-01-19 06:05 --- I agree with Alan. -- bonzini at gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35804
[Bug middle-end/38868] [4.4 Regression] r143152 breaks output routines in xplor-nih
--- Comment #36 from bonzini at gnu dot org 2009-01-19 10:33 --- Would you please attach the assembler diff: 1) between -m32 -O1 and -m32 -O1 -fforward-propagate 2) between the latter and -m32 -O1 -fforward-propagate -fschedule-insns2? Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868
[Bug middle-end/38868] [4.4 Regression] r143152 breaks output routines in xplor-nih
--- Comment #37 from bonzini at gnu dot org 2009-01-19 10:36 --- This is the fishy part: notice that the %esi in the failing test case is completely bogus. - leal-680(%ebp), %esi - movb$32, (%esi) - movb$32, -679(%ebp) - movw$8224, -678(%ebp) + leal-176(%ebp), %ebx + leal-257(%ebp), %esi + movb$32, -176(%ebp) + movb$32, -175(%ebp) + movw$8224, -174(%ebp) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868
[Bug middle-end/38868] [4.4 Regression] r143152 breaks output routines in xplor-nih
--- Comment #39 from bonzini at gnu dot org 2009-01-19 11:04 --- Looks like a scheduling bug: -O1 -fforward-propagate has leal-676(%ebp), %edi movl$19, %ecx movl$538976288, %eax rep stosl movw$31096, -603(%ebp) movb$122, -601(%ebp) -O1 -fforward-propagate -fschedule-insns has leal-676(%ebp), %edi movl$19, %ecx movw$31096, -603(%ebp) movl$538976288, %eax rep stosl movb$122, -601(%ebp) and 676+19*4 = 600 so -603(%ebp) is 0x2020 in the bad code, 0x7978 in the good code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868
[Bug target/38868] [4.4 Regression] r143152 breaks output routines in xplor-nih
--- Comment #43 from bonzini at gnu dot org 2009-01-19 14:06 --- The bug is actually in target independent code. The code to change_address_1 in adjust_address_1 does nothing if the addr is simple, and this causes the creation of shared or wrong RTL. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868
[Bug target/38868] [4.4 Regression] r143152 breaks output routines in xplor-nih
--- Comment #44 from bonzini at gnu dot org 2009-01-19 15:03 --- Created an attachment (id=17146) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17146&action=view) patch under test testing this patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868
[Bug target/38868] [4.4 Regression] r143152 breaks output routines in xplor-nih
--- Comment #48 from bonzini at gnu dot org 2009-01-20 13:25 --- Fixed; the bug is latent in 4.3. -- bonzini at gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868
[Bug middle-end/38932] New: ICE in set_value_range, at tree-vrp.c:398
>From PR38572, but unrelated to it:
void f (long long int p)
{
int x;
static unsigned char g;
long long int min = -9223372036854775807LL - 1;
g = 1;
x = (signed char) (g | 249) / 4;
if (p >= min - (long long int) x)
p = 1;
if (p)
abort ();
}
gives
small.c: In function 'f':
small.c:3: internal compiler error: in set_value_range, at tree-vrp.c:398
Note that after FRE the code becomes the simpler
void f (long long int p)
{
long long int min = 9223372036854775807LL + 2; /*0x7fff */
if (min <= p)
p = 1;
if (p)
abort ();
}
but this does not ICE because in this testcase the "min <= p" is changed to "p
!= min - 1" by the first CCP pass, so this is also a missed folding in FRE.
I'm looking at the VRP failure though.
--
Summary: ICE in set_value_range, at tree-vrp.c:398
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38932
[Bug middle-end/38572] [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
--- Comment #26 from bonzini at gnu dot org 2009-01-22 08:08 --- This is a separate bug. The reduced testcase does not have a single && or || so it probably existed also before my patch. It is now bug 38932. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38572
[Bug middle-end/38932] ICE in set_value_range, at tree-vrp.c:398
-- bonzini at gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-01-22 08:08:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38932
[Bug middle-end/38932] ICE in set_value_range, at tree-vrp.c:398
--- Comment #1 from bonzini at gnu dot org 2009-01-22 08:09 --- Can anyone check if this is a regression, and if so from which version? -- bonzini at gnu dot org changed: What|Removed |Added CC||hjl dot tools at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38932
[Bug middle-end/38932] ICE in set_value_range, at tree-vrp.c:398
--- Comment #2 from bonzini at gnu dot org 2009-01-22 08:17 --- Actually, there is no overflow in -9223372036854775807LL - 1 so this is a third bug. :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38932
[Bug middle-end/38932] ICE in set_value_range, at tree-vrp.c:398
--- Comment #3 from bonzini at gnu dot org 2009-01-22 08:23 --- ah no there's no overflow bit on min -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38932
[Bug middle-end/38932] ICE in set_value_range, at tree-vrp.c:398
--- Comment #4 from bonzini at gnu dot org 2009-01-22 09:00 --- In PRE there is a fold_convert_const_int_from_int call simplifying "(signed char) 249" to -7, but setting the TREE_OVERFLOW flag in the meanwhile. I don't think it makes sense to set the overflow flag on a NOP: * `The result of, or the signal raised by, converting an integer to a signed integer type when the value cannot be represented in an object of that type (C90 6.2.1.2, C99 6.3.1.3).' For conversion to a type of width N, the value is reduced modulo 2^N to be within range of the type; no signal is raised. (Integers implementation, from the gcc manual). -- bonzini at gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38932
[Bug middle-end/38932] [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
--- Comment #7 from bonzini at gnu dot org 2009-01-22 11:04 --- mine. -- bonzini at gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bonzini at gnu dot org |dot org | Severity|normal |critical Status|NEW |ASSIGNED Known to fail||4.4.0 Known to work||4.2.3 Priority|P3 |P1 Last reconfirmed|2009-01-22 08:08:36 |2009-01-22 11:04:08 date|| Summary|ICE in set_value_range, at |[4.4 Regression] ICE in |tree-vrp.c:398 |set_value_range, at tree- ||vrp.c:398 Version|unknown |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38932
[Bug middle-end/38932] [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
--- Comment #8 from bonzini at gnu dot org 2009-01-22 12:10 ---
Fixing FRE still causes an ICE for this:
/* { dg-do compile } */
/* { dg-options "-O2 --std=gnu99" } */
/* This variable needed only to exercise FRE instead of CCP. */
unsigned char g;
extern void abort();
void f (long long int p)
{
g = 255;
/* { dg-warning "constant is" "" { target *-*-* } 14 } */
/* { dg-warning "overflow" "" { target *-*-* } 14 } */
if (p >= -9223372036854775808LL - (signed char) g)
p = 1;
if (p)
abort ();
}
Should I create a separate bug and submit what I have?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38932
[Bug middle-end/38934] New: [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
This failure is not "worked around" by FRE unlike 38932.
/* { dg-do compile } */
/* { dg-options "-O2 --std=gnu99" } */
/* This variable needed only to work around earlier optimizations than VRP. */
unsigned char g;
extern void abort();
void f (long long int p)
{
g = 255;
/* { dg-warning "constant is" "" { target *-*-* } 14 } */
/* { dg-warning "overflow" "" { target *-*-* } 14 } */
if (p >= -9223372036854775808LL - (signed char) g)
p = 1;
if (p)
abort ();
}
--
Summary: [4.4 Regression] ICE in set_value_range, at tree-
vrp.c:398
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, patch
Severity: critical
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
GCC target triplet: i686-pc-linux-gnu
BugsThisDependsOn: 38932
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38934
[Bug middle-end/38934] [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
-- bonzini at gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-01-22 13:17:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38934
[Bug middle-end/38932] [4.3 Regression] ICE in set_value_range, at tree-vrp.c:398
--- Comment #14 from bonzini at gnu dot org 2009-01-24 08:59 --- Regarding the target milestone, you mean I should apply a 4.3 patch before the release goes out, too? (I'm currently regtesting it). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38932
[Bug middle-end/38932] [4.3 Regression] ICE in set_value_range, at tree-vrp.c:398
--- Comment #16 from bonzini at gnu dot org 2009-01-24 09:54 --- changing milestone appropriately then, it did sound strange. -- bonzini at gnu dot org changed: What|Removed |Added Target Milestone|4.3.3 |4.3.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38932
[Bug rtl-optimization/37219] [4.3 Regression] fwprop1 is broken for addresses
--- Comment #7 from bonzini at gnu dot org 2009-01-24 10:28 --- Andrew, I'll do SPEC2000 soon so you can backport it to 4.3.4. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37219
[Bug rtl-optimization/36365] [4.3 Regression] Hang in df_analyze
--- Comment #19 from bonzini at gnu dot org 2009-01-25 07:39 --- no, it's waiting for a backport. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36365
[Bug middle-end/38932] [4.3 Regression] ICE in set_value_range, at tree-vrp.c:398
--- Comment #19 from bonzini at gnu dot org 2009-01-26 15:54 --- fixed on 4.3 branch too. -- bonzini at gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work|4.2.3 4.4.0 |4.2.3 4.4.0 4.3.4 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38932
[Bug middle-end/38934] [4.3/4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
--- Comment #4 from bonzini at gnu dot org 2009-01-26 15:56 --- > This only happens with 32bit HWI. Does this mean it is a front-end bug that TREE_OVERFLOW is set? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38934
