[Bug tree-optimization/48837] Wrong optimization of recursive function calls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48837 --- Comment #2 from e-maxx perso...@e-maxx.ru 2011-05-01 06:13:59 UTC --- It affects even 4.4.3.
[Bug tree-optimization/48795] -Warray-bounds false positive
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48795 --- Comment #2 from Dmitry Gorbachev d.g.gorbachev at gmail dot com 2011-05-01 06:33:06 UTC --- r1-data[1] = prm2 goes above char data[1] bounds. How it's a false positive?
[Bug tree-optimization/48837] Wrong optimization of recursive function calls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48837
--- Comment #1 from Dmitry Gorbachev d.g.gorbachev at gmail dot com
2011-05-01 05:52:09 UTC ---
Simpler testcase:
=== 8 ===
__attribute__((noinline))
int baz(void)
{
return 1;
}
inline const int bar(const int a, const int b)
{
return a ? a : b;
}
int foo(int a, int b)
{
return a || b ? baz() : foo(bar(a, b), 1) + foo(1, 0);
}
int main(void)
{
return foo(0, 0) != 2;
}
=== 8 ===
[Bug ada/48835] Porting GNAT to GNU/Linux/m68k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48835 --- Comment #6 from Andreas Schwab sch...@linux-m68k.org 2011-05-01 07:54:16 UTC --- That's not a problem because all pointer values are also returned in %d0 for compatibility.
[Bug target/48830] [4.4/4.5/4.6/4.7 Regression] unrecognized insn: storing invalid upper fp reg in SImode to stack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48830 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||ebotcazou at gcc dot ||gnu.org --- Comment #7 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-05-01 08:46:28 UTC --- The root problem seems to be that the SPARC port allows a change from DImode to SImode for regno 66 (%f34) (by CANNOT_CHANGE_MODE_CLASS) even though there's no %f35 and no way to move around such a small quantity, also specified through HARD_REGNO_MODE_OK(either of 66 and 67, SImode) being 0. Right, CANNOT_CHANGE_MODE_CLASS doesn't need to prohibit mode changes already forbidden by HARD_REGNO_MODE_OK. I'm a bit reluctant to tweak the macro on the release branches because this is a sensitive one. It seems wrong for the sparc CANNOT_CHANGE_MODE_CLASS to not refuse this change, but also wrong for subreg_get_info to not consult HARD_REGNO_MODE_OK when setting info.representable_p (as %f35 is flagged as representable, which it isn't according to the related field comment in rtl.h). There's a kludge involving the latter, that implies that such a non-representable register is expected to be flagged as representable (ugh!), see last return -1 in simplify_subreg_regno. Indeed, looks like SPARC gets bitten by its own laziness here. I think that we should first try to get rid of the kludge on the mainline. I'll investigate on my side.
[Bug tree-optimization/48795] -Warray-bounds false positive
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48795 --- Comment #3 from Nicolas Le Cam niko.lecam at gmail dot com 2011-05-01 10:11:47 UTC --- (In reply to comment #2) r1-data[1] = prm2 goes above char data[1] bounds. How it's a false positive? Because the structure is a kind of flexible array (code has to follow C89/C90 standard) and is big enough to handle a second member. (Or the warning has to be emitted even if you remove the call to p, which is not the case actually) This example is a deliberate use of overflow to circumvent the absence of flexible arrays in C89/C90, disabling Warray-bounds to avoid the flood it generates isn't the right solution IMHO.
[Bug libgcj/40947] Invalid flag usage: Wl,-rpath, -Wx,-option must appear after -_SYSTYPE_SVR4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40947 --- Comment #11 from Hin-Tak Leung htl10 at users dot sourceforge.net 2011-05-01 10:14:49 UTC --- This really looks like a libtool/automake/autoconf problem, and it seems that libjava has its own libtool bundle? Anyway, upgrading the system libtool to 2.4 does not improve.
[Bug target/48830] [4.4/4.5/4.6/4.7 Regression] unrecognized insn: storing invalid upper fp reg in SImode to stack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48830 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|NEW --- Comment #8 from Hans-Peter Nilsson hp at gcc dot gnu.org 2011-05-01 11:03:45 UTC --- (In reply to comment #7) The root problem seems to be that the SPARC port allows a change from DImode to SImode for regno 66 (%f34) (by CANNOT_CHANGE_MODE_CLASS) I'm a bit reluctant to tweak the macro on the release branches because this is a sensitive one. A quick vetting of uses will hopefully convince you like me: when CLASS is EXTRA_FP_REGS, for at least 4.4 and trunk all uses seem to be from testing an upper floating-point register number, for which TO has no reason to be SImode. Being a port-local change, this seems as safe as it can be. (Famous last words.) BTW incidentally-related: maybe a good time to introduce a register class that is actually the EXTRA_FP_REGS (the upper ones), with its current contents renamed to ALL_FP_REGS. See misnomer in the sparc.h enum reg_class comment. I'll investigate on my side. Very much appreciated. Feel free to take the bug; I'm unassigning myself as I can't commit to testing the patches (at least) the next few days.
[Bug target/48830] [4.4/4.5/4.6/4.7 Regression] unrecognized insn: storing invalid upper fp reg in SImode to stack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48830 --- Comment #9 from joseph at codesourcery dot com joseph at codesourcery dot com 2011-05-01 11:26:02 UTC --- It's probably a good idea to test patches to subreg_get_info on an e500 target such as powerpc-eabispe. I don't *think* e500 is doing anything that would be affected by the proposed patch, but what it does with subregs is fiddly enough (and is the reason for some of the code in subreg_get_info) that any changes to subreg_get_info could easily show up problems there.
[Bug libfortran/48787] Invalid UP rounding with F editing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48787 --- Comment #12 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2011-05-01 12:37:07 UTC --- Author: jvdelisle Date: Sun May 1 12:37:05 2011 New Revision: 173233 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173233 Log: 2011-05-01 Jerry DeLisle jvdeli...@gcc.gnu.org PR libgfortran/48787 * gfortran.dg/round_3.f08: Add more checks. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/round_3.f08
[Bug target/48830] [4.4/4.5/4.6/4.7 Regression] unrecognized insn: storing invalid upper fp reg in SImode to stack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48830 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |ebotcazou at gcc dot |gnu.org |gnu.org Target Milestone|--- |4.6.1 --- Comment #10 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-05-01 12:42:36 UTC --- A quick vetting of uses will hopefully convince you like me: when CLASS is EXTRA_FP_REGS, for at least 4.4 and trunk all uses seem to be from testing an upper floating-point register number, for which TO has no reason to be SImode. That's what I'm not convinced of. In 64-bit mode, the 'e' constraint is mapped to EXTRA_FP_REGS, not FP_REGS, so this class cannot be used to distinguish lower from upper regs in a bunch of FP insns. I don't think the bug is serious enough as to warrant any risk on old (4.4/4.5) release branches; a simple workaround is to replace -O2 with -O on the command line. But I agree that fixing it in 4.6.1 would be desirable. BTW incidentally-related: maybe a good time to introduce a register class that is actually the EXTRA_FP_REGS (the upper ones), with its current contents renamed to ALL_FP_REGS. See misnomer in the sparc.h enum reg_class comment. This would be sort of an earthquake in the back-end though. Very much appreciated. Feel free to take the bug; I'm unassigning myself as I can't commit to testing the patches (at least) the next few days. OK, I'm taking it.
[Bug libfortran/48787] Invalid UP rounding with F editing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48787 --- Comment #11 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2011-05-01 12:32:20 UTC --- Author: jvdelisle Date: Sun May 1 12:32:18 2011 New Revision: 173231 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173231 Log: 2011-05-01 Jerry DeLisle jvdeli...@gcc.gnu.org PR libgfortran/48787 * io/write_float.def (output_float): Gather up integer declarations and add new 'p' for scale factor. Use 'p' in place of the 'dtp' reference everywhere. For ROUND_UP scan the digit string and only perform rounding if something other than '0' is found. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/write_float.def
[Bug target/46261] avr-gcc: Segfaults when compiled with the -mint8 option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46261 --- Comment #4 from Iouri Kharon bc-info at styx dot cabel.net 2011-05-01 13:29:35 UTC --- Created attachment 24157 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24157 CHAR16 and CHAR32 in avr with -mint8 This patch correct bug 46261 in gcc-4.5.x
[Bug c++/48839] New: #error should terminate compilation - similar to missing #include
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48839 Summary: #error should terminate compilation - similar to missing #include Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: john.sal...@deshaw.com bug 15638 established the policy that a missing #include terminates a compilation. I would suggest that encountering an #error should be immediately fatal, in just the same way, and for exactly the same reasons. A specific use-case: I've used something autoconf-like to tell me whether C++0x-style auto is supported. Then I write this in my source file: #ifndef HAVE_CXX0X_AUTO #error This file requires the auto feature of C++0x #endif // lots of code that uses auto. When I compile it with -std=c++98, I get the initial error message, and then thousands of lines of complaints about syntax errors in the rest of the file. It would be far better to stop after the #error.
[Bug tree-optimization/48837] Wrong optimization of recursive function calls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48837 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.05.01 17:13:19 Ever Confirmed|0 |1 --- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2011-05-01 17:13:19 UTC --- It is caused by revision 127491: http://gcc.gnu.org/ml/gcc-cvs/2007-08/msg00384.html
[Bug target/46261] avr-gcc: Segfaults when compiled with the -mint8 option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46261 --- Comment #6 from Thibault North tnorth at fedoraproject dot org 2011-05-01 17:25:52 UTC --- (I seems that the file gcc/defaults.h is the one which must be patched by the second part of your patch)
[Bug target/46261] avr-gcc: Segfaults when compiled with the -mint8 option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46261 --- Comment #5 from Thibault North tnorth at fedoraproject dot org 2011-05-01 17:24:57 UTC --- Created attachment 24158 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24158 Attachment #24157 fixed to patch the right file
[Bug target/46261] avr-gcc: Segfaults when compiled with the -mint8 option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46261 --- Comment #7 from Thibault North tnorth at fedoraproject dot org 2011-05-01 17:27:20 UTC --- It works for me, thanks.
[Bug target/47509] avr-gcc error: could not split insn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47509 Thibault North tnorth at fedoraproject dot org changed: What|Removed |Added CC||tnorth at fedoraproject dot ||org --- Comment #1 from Thibault North tnorth at fedoraproject dot org 2011-05-01 17:59:13 UTC --- It works with -O1 though.
[Bug tree-optimization/48837] [4.4/4.5/4.6/4.6 Regression] Wrong optimization of recursive function calls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48837 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added CC||steven at gcc dot gnu.org --- Comment #4 from Steven Bosscher steven at gcc dot gnu.org 2011-05-01 19:01:45 UTC --- Works with -fno-optimize-sibling-calls. Looks like this has something to do with the accumulators optimization in tree-tailcall.c
[Bug libgomp/46967] lots of testsuite failures with libgomp on hppa-hp-hpux11.31
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46967 Hin-Tak Leung htl10 at users dot sourceforge.net changed: What|Removed |Added CC||htl10 at users dot ||sourceforge.net --- Comment #3 from Hin-Tak Leung htl10 at users dot sourceforge.net 2011-05-01 19:01:17 UTC --- Hmm, I was looking around for other bugs and wondering if I should fail one - just finished testing 4.4.6 on alphaev68-dec-osf5.1a and (my own previous result, on the same machine): http://gcc.gnu.org/ml/gcc-testresults/2010-12/msg01338.html 4.4.5: === libgomp Summary === # of expected passes2463 # of unexpected failures9 # of unsupported tests 2 and the new one in 4.4.6 (I'll post to gcc-testresults@gcc soon): === libgomp Summary === # of expected passes1610 # of unexpected failures466 # of unsupported tests2 so something has gone very wrong. with 4.4.6. Since HP owns Tru64 these days, I'd be interested in hppa-hp-hpux11.31's 4.4.6 's test result.
[Bug tree-optimization/48837] [4.4/4.5/4.6/4.6 Regression] Wrong optimization of recursive function calls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48837
--- Comment #5 from Steven Bosscher steven at gcc dot gnu.org 2011-05-01
19:24:06 UTC ---
Function foo from .143.expand dump:
;; Function int foo(int, int) (_Z3fooii)
int foo(int, int) (int a, int b)
{
int acc_tmp.13;
int add_acc.12;
int D.2091;
int D.2085;
int D.2081;
# BLOCK 2 freq:6950
# PRED: ENTRY [100.0%] (fallthru,exec)
# a_1 = PHI a_2(D)(0)
# b_7 = PHI b_3(D)(0)
# add_acc.12_21 = PHI 0(0)
# SUCC: 3 [100.0%] (fallthru)
# BLOCK 3 freq:1
# PRED: 2 [100.0%] (fallthru) 5 [100.0%] (fallthru,dfs_back,exec)
# a_14 = PHI a_1(2), a_23(5)
# b_22 = PHI b_7(2), b_25(5)
# add_acc.12_19 = PHI add_acc.12_21(2), add_acc.12_12(5)
D.2085_4 = b_22 | a_14;
if (D.2085_4 != 0)
goto bb 4;
else
goto bb 5;
# SUCC: 4 [39.0%] (true,exec) 5 [61.0%] (false,exec)
# BLOCK 4 freq:3900
# PRED: 3 [39.0%] (true,exec)
D.2081_5 = baz (); [tail call]
acc_tmp.13_10 = D.2081_5 + add_acc.12_19;
return acc_tmp.13_10;
# SUCC: EXIT [100.0%]
# BLOCK 5 freq:3050
# PRED: 3 [61.0%] (false,exec)
Invalid sum of incoming frequencies 6100, should be 3050
D.2091_8 = foo (0, 1);
add_acc.12_12 = add_acc.12_19 + D.2091_8;
a_23 = 1;
b_25 = 0;
goto bb 3;
# SUCC: 3 [100.0%] (fallthru,dfs_back,exec)
}
Invalid sum of incoming frequencies 3900, should be 6950
(Note, someone is not updating the CFG properly, see incorrect profile info.
This is caused by VRP, the mismatch appears first in the .vrp1 dump.)
The PHI nodes in basic block 3 show that the + foo(1,0) part of foo() has
been transformed from a recursive call into a loop inside foo.
We enter the function with a==0 and b==0 so control flow is as follows:
BB2 - BB3 - BB5 (because (a | b) == 0) -
D.2091_8 = foo(0, 1)// D.2091_8 = 1
add_acc = 0 (from the PHI in BB2) + 1 = 1
- BB3 with a=1 and b=0 - BB4 -
D.2081_5 = baz () [tail call] // D.2081_5 = 1
acc_tmp.13_10 = 1 + add_acc.12_19 = 1 + 1 = 2
return acc_tmp.13_10// return 2
That looks correct to me, but foo(0,0) returns 1 instead of 2. Both foo(0,1)
and foo(1,0) both return 1 as expected.
I think the problem is in RTL expansion of the tail call in basic block 4,
which doesn't look like a tail call to me. The RTL generated for basic block 4
is this:
;; Generating RTL for gimple basic block 4
;; D.2081_5 = baz (); [tail call]
(call_insn/u/j 13 12 14 4 (set (reg:SI 0 ax)
(call (mem:QI (symbol_ref:DI (_Z3bazv) [flags 0x3] function_decl
0x7722c100 baz) [0 baz S1 A8])
(const_int 0 [0]))) t.cc:14 -1
(expr_list:REG_EH_REGION (const_int 0 [0])
(nil))
(nil))
(barrier 14 13 0)
The acc_tmp.13_10 = D.2081_5 + add_acc.12_19; part is lost.
[Bug tree-optimization/48837] [4.4/4.5/4.6/4.6 Regression] Wrong optimization of recursive function calls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48837
--- Comment #6 from Steven Bosscher steven at gcc dot gnu.org 2011-05-01
19:56:37 UTC ---
In the tail recursion optimization:
Breakpoint 3, gimple_call_set_tail (s=0x77ed3680, tail_p=1 '\001') at
../../trunk/gcc/gimple.h:2241
2241 GIMPLE_CHECK (s, GIMPLE_CALL);
(gdb) bt 2
#0 gimple_call_set_tail (s=0x77ed3680, tail_p=1 '\001') at
../../trunk/gcc/gimple.h:2241
#1 0x00f6d5a3 in optimize_tail_call (t=0x1cd7820, opt_tailcalls=1
'\001') at ../../trunk/gcc/tree-tailcall.c:917
(More stack frames follow...)
(gdb) up
#1 0x00f6d5a3 in optimize_tail_call (t=0x1cd7820, opt_tailcalls=1
'\001') at ../../trunk/gcc/tree-tailcall.c:917
917 gimple_call_set_tail (stmt, true);
(gdb) l
912
913 if (opt_tailcalls)
914 {
915 gimple stmt = gsi_stmt (t-call_gsi);
916
917 gimple_call_set_tail (stmt, true);
918 if (dump_file (dump_flags TDF_DETAILS))
919 {
920 fprintf (dump_file, Found tail call );
921 print_gimple_stmt (dump_file, stmt, 0, dump_flags);
(gdb) disp debug_bb_n(5)
3: debug_bb_n (5) = ;; basic block 5, loop depth 0, count 0
;; prev block 4, next block 1
;; pred: 3 [100.0%] (fallthru,exec)
;; succ: EXIT [100.0%]
bb 5:
Invalid sum of incoming frequencies 3900, should be 6950
# D.2081_1 = PHI D.2081_5(3)
return D.2081_1;
(struct basic_block_def *) 0x77227548
(gdb) p debug_bb_n(3)
;; basic block 3, loop depth 0, count 0
;; prev block 2, next block 4
;; pred: 2 [39.0%] (true,exec)
;; succ: 5 [100.0%] (fallthru,exec)
bb 3:
D.2081_5 = baz (); [tail call]
goto bb 5;
$9 = (struct basic_block_def *) 0x77227478
(gdb)
So far so good. But now compensation code must be inserted for the
recursive-call-turned-loop:
(gdb)
3: debug_bb_n (5) = ;; basic block 5, loop depth 0, count 0
;; prev block 4, next block 1
;; pred: 3 [100.0%] (fallthru,exec)
;; succ: EXIT [100.0%]
bb 5:
Invalid sum of incoming frequencies 3900, should be 6950
# D.2081_1 = PHI D.2081_5(3)
return D.2081_1;
(struct basic_block_def *) 0x77227548
(gdb)
1040adjust_return_value (e-src, m_acc, a_acc);
3: debug_bb_n (5) = ;; basic block 5, loop depth 0, count 0
;; prev block 4, next block 1
;; pred: 3 [100.0%] (fallthru,exec)
;; succ: EXIT [100.0%]
bb 5:
Invalid sum of incoming frequencies 3900, should be 6950
# D.2081_1 = PHI D.2081_5(3)
return D.2081_1;
(struct basic_block_def *) 0x77227548
(gdb)
1034 FOR_EACH_EDGE (e, ei, EXIT_BLOCK_PTR-preds)
3: debug_bb_n (5) = ;; basic block 5, loop depth 0, count 0
;; prev block 4, next block 1
;; pred: 3 [100.0%] (fallthru,exec)
;; succ: EXIT [100.0%]
bb 5:
Invalid sum of incoming frequencies 3900, should be 6950
# D.2081_1 = PHI D.2081_5(3)
acc_tmp.13_10 = add_acc.12_19 + D.2081_1;
return acc_tmp.13_10;
(struct basic_block_def *) 0x77227548
(gdb)
(I don't see now r127491 can be the cause of this, FWIW.)
[Bug tree-optimization/48837] [4.4/4.5/4.6/4.6 Regression] Wrong optimization of recursive function calls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48837 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added CC||rakdver at kam dot ||mff.cuni.cz --- Comment #7 from Steven Bosscher steven at gcc dot gnu.org 2011-05-01 20:24:11 UTC --- Zdenek, this problem is caused by your work to handle addends/multiplicands in tree-tailcall.c. It looks like an interaction problem between tail-calls and tail-recursion, where elimination tail recursion turns a tail-call into a normal call.
[Bug libgomp/46967] lots of testsuite failures with libgomp on hppa-hp-hpux11.31
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46967 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011.05.01 21:28:15 Ever Confirmed|0 |1 --- Comment #4 from John David Anglin danglin at gcc dot gnu.org 2011-05-01 21:28:15 UTC --- This should be fixed. Albert, can you confirm that the pthread active changes fixed this problem? Regarding comment #3, look at the libgomp test log file to see why the tests are failing on alphaev68-dec-osf5.1a. I'm certain the problem is different from the hppa2.0w-hp-hpux11.31 issue, so a new PR should be opened.
[Bug target/48840] New: [4.4/4.7 Regression] ICE, gcc_assert (old_frame_size == get_frame_size ()) maybe fp/vis-related
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48840 Summary: [4.4/4.7 Regression] ICE, gcc_assert (old_frame_size == get_frame_size ()) maybe fp/vis-related Product: gcc Version: 4.4.5 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: h...@gcc.gnu.org Created attachment 24159 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24159 Preprocessed, trivially reduced test-case For gcc-4.4.0 and gcc-4.4.5, observe the following ICE for the attachment, running cc1 -fpreprocessed ~/rcf3.i -mptr64 -mstack-bias -mlong-double-128 -mcpu=ultrasparc -m64 -mvis -O2 -funroll-loops -fPIC -o rc_filter.s: /home/hp/rcf3.i: In function 'rc_filter_sobel_3x3_horz_u8': /home/hp/rcf3.i:26: internal compiler error: in reload, at reload1.c:1170 where that line has a gcc_assert (old_frame_size == get_frame_size ()). Similarly for trunk revision 172690 (same line, different number) though not for revision 170836 (now the 4.6 branch) and not for gcc-4.3.5.
[Bug target/48840] [4.4/4.7 Regression] ICE, gcc_assert (old_frame_size == get_frame_size ()) maybe fp/vis-related
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48840 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.05.01 22:02:32 Known to work||4.3.5 Ever Confirmed|0 |1 Known to fail||4.4.5
[Bug libgomp/46967] lots of testsuite failures with libgomp on hppa-hp-hpux11.31
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46967 --- Comment #5 from Hin-Tak Leung htl10 at users dot sourceforge.net 2011-05-01 22:02:03 UTC --- (In reply to comment #4) Regarding comment #3, look at the libgomp test log file to see why the tests are failing on alphaev68-dec-osf5.1a. I'm certain the problem is different from the hppa2.0w-hp-hpux11.31 issue, so a new PR should be opened. Will do. am checking bug 40894 for 4.4.6 at the moment. When I finish updating the status of that I'll send the test result to test-results, and file a new bug.
[Bug libgomp/46967] lots of testsuite failures with libgomp on hppa-hp-hpux11.31
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46967 --- Comment #6 from Hin-Tak Leung htl10 at users dot sourceforge.net 2011-05-01 22:24:08 UTC --- Filed Bug 48841 for the alphaev68 libgomp failure and attached my test summary, in case somebody wants to compare to hppa 4.4.6.
[Bug bootstrap/40894] [4.4/4.5/4.6/4.7 Regression] bootstrap4-lean failed crtfastmath.o comparision
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40894 Hin-Tak Leung htl10 at users dot sourceforge.net changed: What|Removed |Added Known to fail||4.4.6 --- Comment #9 from Hin-Tak Leung htl10 at users dot sourceforge.net 2011-05-01 22:27:42 UTC --- 4.4.6 failed at same place. make[2]: Entering directory `/home/htl10/tmp-build/gcc-446-obj-2' make[3]: Entering directory `/home/htl10/tmp-build/gcc-446-obj-2' rm -f stage_current make[3]: Leaving directory `/home/htl10/tmp-build/gcc-446-obj-2' Comparing stages 3 and 4 Bootstrap comparison failure! ./crtfastmath.o differs make[2]: *** [compare3] Error 1 make[2]: Leaving directory `/home/htl10/tmp-build/gcc-446-obj-2' make[1]: *** [stage4-bubble] Error 2 make[1]: Leaving directory `/home/htl10/tmp-build/gcc-446-obj-2' make: *** [bootstrap4-lean] Error 2 bash-2.05a# objdump -Dxzs stage3-gcc/crtfastmath.o stage3-dump bash-2.05a# objdump -Dxzs stage4-gcc/crtfastmath.o stage4-dump bash-2.05a# diff -u stage3-dump stage4-dump --- stage3-dump2011-05-01 23:14:28.0 +0100 +++ stage4-dump2011-05-01 23:14:41.0 +0100 @@ -1,6 +1,6 @@ -stage3-gcc/crtfastmath.o: file format ecoff-littlealpha -stage3-gcc/crtfastmath.o +stage4-gcc/crtfastmath.o: file format ecoff-littlealpha +stage4-gcc/crtfastmath.o architecture: alpha, flags 0x0035: HAS_RELOC, HAS_LINENO, HAS_SYMS, HAS_LOCALS start address 0x @@ -70,7 +70,7 @@ 0010 00301f22 10807da7 00405b6b 0100ba27 .0...}..@[k...' 0020 2480bd23 5ea7 1000de23 0180fa6b $..#..^#...k Contents of section .xdata: - 0030 3100 02000204 1... + 0030 0100 02000204 Contents of section .pdata: 0040 ecff Contents of section .lita: @@ -100,7 +100,7 @@ Disassembly of section .xdata: 0030 .xdata: - 30:31 00 00 00 call_pal0x31 + 30:01 00 00 00 call_pal0x1 34:02 00 02 04 .long 0x4020002 38:00 00 00 00 halt 3c:00 00 00 00 halt bash-2.05a#
[Bug bootstrap/40894] [4.4/4.5/4.6/4.7 Regression] bootstrap4-lean failed crtfastmath.o comparision
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40894 --- Comment #10 from Hin-Tak Leung htl10 at users dot sourceforge.net 2011-05-01 22:30:55 UTC --- Could this be some kind of text-num conversion bug? I can't help but thinking 0x31 is '1' in ascii character, which is 0x01 in value.
[Bug go/47726] language go can not build for mingw target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47726 Ruben Van Boxem vanboxem.ruben at gmail dot com changed: What|Removed |Added CC||vanboxem.ruben at gmail dot ||com --- Comment #1 from Ruben Van Boxem vanboxem.ruben at gmail dot com 2011-05-01 22:38:55 UTC --- I can confirm this problem. I concur with Dongsheng's proposal.
[Bug libgomp/48841] New: [regression] lot more libgomp testsuite failures compared to 4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48841 Summary: [regression] lot more libgomp testsuite failures compared to 4.4.5 Product: gcc Version: 4.4.6 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp AssignedTo: unassig...@gcc.gnu.org ReportedBy: ht...@users.sourceforge.net Created attachment 24160 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24160 The full soon-to-post-to-gcc-testresults test summary My 4.4.5 result, on the same machine: http://gcc.gnu.org/ml/gcc-testresults/2010-12/msg01338.html 4.4.5: === libgomp Summary === # of expected passes2463 # of unexpected failures9 # of unsupported tests 2 === libgomp Summary === # of expected passes1610 # of unexpected failures466 # of unsupported tests2 so something has gone very wrong with 4.4.6.
[Bug libgomp/48841] [regression] lot more libgomp testsuite failures compared to 4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48841 --- Comment #1 from Hin-Tak Leung htl10 at users dot sourceforge.net 2011-05-01 22:46:34 UTC --- attachment posted as: http://gcc.gnu.org/ml/gcc-testresults/2011-05/msg00074.html after prepending with some notes. Mentioned the issue but forgot to mention the actual bug number, but I am sure somebody will find this report if they need to.
[Bug target/48840] [4.4/4.7 Regression] ICE, gcc_assert (old_frame_size == get_frame_size ()) maybe fp/vis-related
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48840 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added Target||sparc64-unknown-linux-gnu --- Comment #1 from Hans-Peter Nilsson hp at gcc dot gnu.org 2011-05-01 23:45:57 UTC --- Ouch, forgot target field...
[Bug libfortran/48787] Invalid UP rounding with F editing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48787 --- Comment #13 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2011-05-02 03:29:49 UTC --- Fixed on trunk
