[Bug debug/45015] ICE in cselib.c caused by fix for PR43051
--- Comment #5 from mkuvyrkov at gcc dot gnu dot org 2010-07-21 18:20 --- Subject: Re: ICE in cselib.c caused by fix for PR43051 On 7/21/10 10:05 PM, jakub at gcc dot gnu dot org wrote: --- Comment #4 from jakub at gcc dot gnu dot org 2010-07-21 18:05 --- Can't reproduce that. Were you testing the patch attached here, or the one posted to gcc-patches? The one attached here won't work when not ENABLE_CHECKING... That fixes the SIGSEGV. Regtesting on m68k didn't show any regressions. Thanks for fixing this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45015
[Bug fortran/40766] this fortran program is too slow
--- Comment #20 from mkuvyrkov at gcc dot gnu dot org 2010-05-10 10:46 --- Subject: Re: this fortran program is too slow On 5/7/10 1:38 AM, steven at gcc dot gnu dot org wrote: --- Comment #19 from steven at gcc dot gnu dot org 2010-05-06 21:38 --- One possibility is to see if the glibc patches for this issue can be merged into eglibc... Maxim what do you think? I'll look into this when I have a minute. I'm hesitant to merging patches to EGLIBC that were not submitted to either GLIBC or EGLIBC mailing lists. There are copyright assignment issues with extracting patches from (open)SUSE's GLIBC and committing them in to EGLIBC. Copyright assignment is not an absolutely blocking issue, but it is one of the concerns. The plan of action is to find out who the author of the patch is and ask him or her to submit the patch to EGLIBC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40766
[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90
--- Comment #23 from mkuvyrkov at gcc dot gnu dot org 2010-05-06 15:07 --- Subject: Re: [4.6 Regression] Revision 158105 miscompiles doduc.f90 On 5/6/10 6:59 PM, dominiq at lps dot ens dot fr wrote: ... Now the questions are: (1) why a change dealing with the propagation of minus signs interferes with reciprocal-math? (2) why moving VEC_safe_push from negate_value to eliminate_plus_minus_pair trigger the miscompilation? Just to be clear, I do not think there is a miscompilation here. The patch that [among other things] moved VEC_safe_push from negate_value to eliminate_plus_minus_pair did that to enable (a + (-b)) - (a - b) optimization in more cases. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
[Bug rtl-optimization/43804] [4.5/4.6 regression] ICE in reload_cse_simplify_operands
--- Comment #8 from mkuvyrkov at gcc dot gnu dot org 2010-04-22 07:09 --- Subject: Re: [4.5/4.6 regression] ICE in reload_cse_simplify_operands On 4/22/10 3:40 AM, schwab at linux-m68k dot org wrote: --- Comment #7 from schwab at linux-m68k dot org 2010-04-21 23:40 --- I think 'T' should accept tls references like 's' does. Do you mean the following? == (define_constraint T Used for operands that satisfy 's' when -mpcrel is not in effect. (and (match_code symbol_ref,label_ref,const) (match_test !flag_pic || m68k_tls_reference_p (op, true == Yes, that should fix this particular problem, but one could equally successfully argue that T then should then accept usual PIC GOT references too. I just do not understand the background behind T constraint. Sigh. Maybe, it was introduced as an optimization to stop GCC from putting addresses (symbol_refs, etc) into data registers and then reloading them into address registers. Most probably, current GCC register allocator will do a just that without this kind of manual tweaking on the backend side. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43804
[Bug rtl-optimization/43804] [4.5/4.6 regression] ICE in reload_cse_simplify_operands
--- Comment #5 from mkuvyrkov at gcc dot gnu dot org 2010-04-21 19:43 --- Subject: Re: [4.5/4.6 regression] ICE in reload_cse_simplify_operands On 4/21/10 5:23 PM, schwab at linux-m68k dot org wrote: --- Comment #4 from schwab at linux-m68k dot org 2010-04-21 13:22 --- Introduced in r27576. Presumably the first alternative is supposed to catch this case, through T+g, but T does not match if flag_pic, contrary to its documentation (introduced in r120961). Documentation for T seems correct to me, assuming -mpcrel and -fpic are equivalent: Operands that satisfy s (const, symbol_ref, ...) when -mpcrel is not in effect. It is clear that constants with unknown at compile time values are not welcome in data registers, but I cannot guess why. What can possibly be the difference between an arbitrary constant known at compile time (the n constraint) and a constant known at assembly / link time (the i constraint). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43804
[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90
--- Comment #18 from mkuvyrkov at gcc dot gnu dot org 2010-04-14 10:02 --- Subject: Re: [4.6 Regression] Revision 158105 miscompiles doduc.f90 On 4/14/10 1:55 PM, dominiq at lps dot ens dot fr wrote: --- Comment #17 from dominiq at lps dot ens dot fr 2010-04-14 09:55 --- Well, it indeed looks invalid if there is NaNs involved and you use -ffinite-math-only. The NaN appears in the miscompiled executable. Note that I am not the author of the doduc test, but it has been compiled by gfortran with -O3 -ffast-math for years and ran without failure. Can you track where the NaN comes from and if it is indeed unexpected even with -ffast-math -ffinite-math-only? While I will not argue that my patch is 100% bug-free, this seems to be an invalid testcase. It may happen that the changes in revision 158105 is exposing a latent bug. That is always a possibility. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
[Bug target/43675] [m68k] Wrong code due to missing sign extension
--- Comment #2 from maxim at codesourcery dot com 2010-04-07 15:24 --- The problem is in 68k_extendhisi2 pattern, second alternative: (define_insn *68k_extendhisi2 [(set (match_operand:SI 0 nonimmediate_operand =*d,a) (sign_extend:SI (match_operand:HI 1 nonimmediate_src_operand 0,rmS)))] !ISA_HAS_MVS_MVZ @ ext%.l %0 move%.w %1,%0 [(set_attr type ext,move)]) Move.w instruction on ColdFire indeed preserves the upper bits, I found out that by luck in the coldfire uclinux kernel port, no reference manual that I know of spells out this behavior. I have a serious suspicion, though, that move.w on classic m68k does perform sign extension. Can anyone confirm this? If this is so, then the fix is to disable the second alternative when compiling for ColdFire, e.g., by setting attribute ok_for_coldfire to no. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43675
[Bug target/43675] [m68k] Wrong code due to missing sign extension
--- Comment #4 from maxim at codesourcery dot com 2010-04-07 16:04 --- Hm, move.w preserving upper bits seems to apply only if destination is a data register then. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43675
[Bug target/35659] [4.3/4.4 Regression] Miscompiled code with -O2 (but not with -O2 -funroll-loops) on ia64
--- Comment #20 from maxim at codesourcery dot com 2008-06-26 09:21 --- Subject: Re: [4.3/4.4 Regression] Miscompiled code with -O2 (but not with -O2 -funroll-loops) on ia64 jakub at gcc dot gnu dot org wrote: --- Comment #19 from jakub at gcc dot gnu dot org 2008-06-26 08:41 --- To be more precise, the problem is in speculating conditional store: ld4.a r18 = [r44] st4 [r59] = r14, -60 ... cmp4.ge p6, p7 = r22, r18 (p7) ld4 r14 = [r62] ... (p7) st4 [r77] = r14 chk.a.clr r18, .L69 .L70: ... .L69: ld4 r18 = [r44] ;; cmp4.ge p6, p7 = r22, r18 ;; (p7) ld4 r14 = [r62] ;; (p7) st4 [r77] = r14 br .L70 Now, ld4.a returns the stale value in r18 (0x20202020), $r22 is 2 and so in the code before chk.a.clr p7 is 1, so [r62] is loaded into r14 and stored into [r77] (i.e. MR = M in IF (K.GT.M1) MR = M is executed). Then chk.a.clr realizes the [r44] memory changed, so branches to .L69 to do the speculated stuff again. This time r18 is 1, so p7 will be 0 and MR = M is not done. But this really doesn't and can't undo the st4 [r77] = r14 store that already happened before chk.a.clr and wasn't supposed to happen. Oh, now I see the problem. I need some time to check what the best fix would be. Probably, the fix will be to exclude predicated instructions from speculation set, but I'd like to consider alternatives. Thanks, Maxim -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35659
[Bug middle-end/33670] [4.3 Regression] cc1 segfault with -O2 -fsched-stalled-insns=0 for twolf
--- Comment #4 from maxim at codesourcery dot com 2007-11-03 07:45 ---
Subject: Re: [4.3 Regression] cc1 segfault with -O2
-fsched-stalled-insns=0 for twolf
jakub at gcc dot gnu dot org wrote:
--- Comment #3 from jakub at gcc dot gnu dot org 2007-11-02 23:17 ---
Fixed for ppc64.
I haven't added the requested stop at the start of bb, Maxim, if you want to
do that, please go ahead.
Also, I have just found that this testcase fails on ia64 native for a
different
reason (wonder why I haven't reproduced that with cross ia64 before).
On ia64 the problem is that the backend sets DO_SPECULATION in flags
in ia64_set_sched_flags - mflag_sched_ar_data_spec is 1 by default and
when user asks for -fsched-stalled-insns=5 (or =0), then
/* Perform a few consistency checks of flags in different data structures. */
static void
check_sched_flags (void)
{
unsigned int f = current_sched_info-flags;
if (flag_sched_stalled_insns)
gcc_assert (!(f DO_SPECULATION));
if (f DO_SPECULATION)
gcc_assert (!flag_sched_stalled_insns
spec_info
spec_info-mask);
}
fails. It compiles with -O2 -fno-sched-stalled-insns or -O2
-fsched-stalled-insns=0 -mno-sched-ar-data-spec
I see no code that would try to do anything to satisfy this assert, should
ia64 disallow -fsched-stalled-insns by setting flag_sched_stalled_insns = 0?
Or if it is non-zero don't set DO_SPECULATION? Something else?
I don't really remember why I enforced this check. I believe,
-fsched-stalled-insns doesn't make sense for ia64, but, anyway, if user
wants to do that, compiler should deal with it.
There is no code in ia64 backend that will turn off either of the flags
depending on presence of the other. I think, this check (the whole
function) should be simply removed, given that compiler won't ICE
somewhere else.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33670
[Bug rtl-optimization/33922] [4.3 Regression] slow compilation on ia64 (postreload scheduling)
--- Comment #17 from maxim at codesourcery dot com 2007-10-28 20:04 --- Subject: Re: [4.3 Regression] slow compilation on ia64 (postreload scheduling) jakub at gcc dot gnu dot org wrote: --- Comment #15 from jakub at gcc dot gnu dot org 2007-10-28 19:10 --- Compared to 20070803 with -O3 -fno-tree-vectorize there are now 100 times more calls to rtx_needs_barrier and 44 times more calls to safe_group_barrier_needed. E.g. the latter is horribly expensive, e.g. copying around 401 * sizeof (struct reg_write_state) == 1604 bytes several times. The underlying problem is that list of ready to schedule instructions now became larger than it was before and the scheduler tends to slow down with the size of the list growing. There already is a workaround for this problem (limiting ready list in case it is too large; see PARAM_MAX_SCHED_READY_INSNS) but it doesn't seem to do best in this case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33922
