[Bug tree-optimization/31847] [4.3 Regression] Printing to dump file broken
--- Comment #5 from patchapp at dberlin dot org 2007-05-10 08:12 --- Subject: Bug number PR31847 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00527.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31847
[Bug fortran/30876] Array valued recursive function rejected
--- Comment #9 from patchapp at dberlin dot org 2007-05-10 08:13 --- Subject: Bug number Pr30876 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00579.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30876
[Bug middle-end/30250] Evaluate lgamma/gamma at compile-time
--- Comment #4 from patchapp at dberlin dot org 2007-05-10 08:14 --- Subject: Bug number PR middle-end/30250 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00619.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30250
[Bug fortran/30878] Rejects function f1; namelist /nml/ f1
--- Comment #4 from patchapp at dberlin dot org 2007-05-10 08:14 --- Subject: Bug number PR30878 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00623.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30878
[Bug target/30987] [4.3 Regression] Problem while compiling gcc for score
--- Comment #6 from liqin at gcc dot gnu dot org 2007-05-10 08:18 ---
Index: gcc/config/score/predicates.md
===
--- gcc/config/score/predicates.md (revision 124567)
+++ gcc/config/score/predicates.md (working copy)
@@ -75,14 +75,3 @@
return IMM_IN_RANGE (INTVAL (op), 15, 1);
})
-(define_predicate "const_pow2"
- (match_code "const_int")
-{
- return IMM_IS_POW_OF_2 ((unsigned HOST_WIDE_INT) INTVAL (op), 0, 31);
-})
-
-(define_predicate "const_npow2"
- (match_code "const_int")
-{
- return IMM_IS_POW_OF_2 (~(unsigned HOST_WIDE_INT) INTVAL (op), 0, 31);
-})
Index: gcc/config/score/misc.md
===
--- gcc/config/score/misc.md(revision 124567)
+++ gcc/config/score/misc.md(working copy)
@@ -380,38 +380,3 @@
[(set_attr "type" "arith")
(set_attr "mode" "SI")])
-(define_insn "bitclr_c"
- [(set (match_operand:SI 0 "register_operand" "=e,d")
-(and:SI (match_operand:SI 1 "register_operand" "0,d")
-(match_operand:SI 2 "const_npow2")))
- (clobber (reg:CC CC_REGNUM))]
- ""
- "@
- bitclr!%0, %F2
- bitclr.c %0, %1, %F2"
- [(set_attr "type" "arith")
- (set_attr "mode" "SI")])
-
-(define_insn "bitset_c"
- [(set (match_operand:SI 0 "register_operand" "=e,d")
-(ior:SI (match_operand:SI 1 "register_operand" "0,d")
-(match_operand:SI 2 "const_pow2")))
- (clobber (reg:CC CC_REGNUM))]
- ""
- "@
- bitset!%0, %E2
- bitset.c %0, %1, %E2"
- [(set_attr "type" "arith")
- (set_attr "mode" "SI")])
-
-(define_insn "bittgl_c"
- [(set (match_operand:SI 0 "register_operand" "=e,d")
-(xor:SI (match_operand:SI 1 "register_operand" "0,d")
-(match_operand:SI 2 "const_pow2")))
- (clobber (reg:CC CC_REGNUM))]
- ""
- "@
- bittgl!%0, %E2
- bittgl.c %0, %1, %E2"
- [(set_attr "type" "arith")
- (set_attr "mode" "SI")])
--
liqin at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2007-05-10 08:18:55
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30987
[Bug target/30474] Bad 16bit constant code generation on 64bit host
--- Comment #1 from liqin at gcc dot gnu dot org 2007-05-10 08:21 ---
Index: gcc/config/score/score.c
===
--- gcc/config/score/score.c(revision 124567)
+++ gcc/config/score/score.c(working copy)
@@ -1167,7 +1167,7 @@ score_print_operand (FILE *file, rtx op,
{
gcc_assert (code == CONST_INT);
fprintf (file, HOST_WIDE_INT_PRINT_HEX,
- (unsigned HOST_WIDE_INT) INTVAL (op) >> 16);
+ (INTVAL (op) >> 16) & 0x);
}
else if (c == 'D')
{
@@ -1175,7 +1175,7 @@ score_print_operand (FILE *file, rtx op,
{
rtx temp = gen_lowpart (SImode, op);
gcc_assert (GET_MODE (op) == SFmode);
- fprintf (file, HOST_WIDE_INT_PRINT_HEX, INTVAL (temp));
+ fprintf (file, HOST_WIDE_INT_PRINT_HEX, INTVAL (temp) & 0x);
}
else
output_addr_const (file, op);
--
liqin at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2007-05-10 08:21:37
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30474
[Bug tree-optimization/25371] -ftree-vectorize results in internal compiler error on AMD64
--- Comment #9 from spop at gcc dot gnu dot org 2007-05-10 08:24 --- Subject: Re: -ftree-vectorize results in internal compiler error on AMD64 I was still thinking about how to fix this, and the solution seems to me to not instantiate the initial value of the induction variable if it is a chrec, i.e. keep the base_offset with references to the variable that varies in the outer loop instead of analyzing that variable and replacing it with its evolution. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25371
[Bug driver/30972] Call to _access has invalid parameter when linked with msvcrt (for vista)
--- Comment #3 from zackw at panix dot com 2007-05-10 08:36 --- What the heck are we doing calling access() in the first place? We should just go ahead and try to execute .../cc1.exe for all relevant paths. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30972
[Bug debug/23551] dwarf records for inlines appear incomplete
--- Comment #16 from patchapp at dberlin dot org 2007-05-10 08:40 --- Subject: Bug number PR 23551 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00703.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23551
[Bug fortran/30746] 50th Anniversary Bug - Forward reference to contained function
--- Comment #3 from pault at gcc dot gnu dot org 2007-05-10 09:11 ---
The patch below does the job. Before submitting, I want to check how much the
compile time is hit. If it is a lot, I will try to streamline detection of the
wrong host association.
Paul
Index: gcc/fortran/gfortran.h
===
*** gcc/fortran/gfortran.h (révision 124567)
--- gcc/fortran/gfortran.h (copie de travail)
*** bool gfc_check_access (gfc_access, gfc_a
*** 2160,2165
--- 2160,2166
/* primary.c */
symbol_attribute gfc_variable_attr (gfc_expr *, gfc_typespec *);
symbol_attribute gfc_expr_attr (gfc_expr *);
+ match gfc_match_rvalue (gfc_expr **);
/* trans.c */
void gfc_generate_code (gfc_namespace *);
Index: gcc/fortran/resolve.c
===
*** gcc/fortran/resolve.c (révision 124567)
--- gcc/fortran/resolve.c (copie de travail)
*** resolve_variable (gfc_expr *e)
*** 3204,3209
--- 3204,3274
}
+ /* Checks to see that the correct symbol has been host associated.
+The only situation where this arises is that in which a contained
+function is parsed after the host association is made. Therefore,
+on detecting this, the line is rematched, having got rid of the
+existing references and actual_arg_list. */
+ static bool
+ check_host_association (gfc_expr *e)
+ {
+ gfc_symbol *sym, *old_sym;
+ locus temp_locus;
+ gfc_expr *expr;
+
+ old_sym = e->symtree->n.sym;
+ if (!old_sym->attr.use_assoc && old_sym->ns != gfc_current_ns)
+ {
+ gfc_find_symbol (old_sym->name, gfc_current_ns->parent, 1, &sym);
+ if (sym && old_sym != sym && sym->attr.flavor == FL_PROCEDURE)
+ {
+ temp_locus = gfc_current_locus;
+ gfc_current_locus = e->where;
+
+ gfc_buffer_error (1);
+
+ gfc_free_ref_list (e->ref);
+ e->ref = NULL;
+
+ if (e->expr_type == EXPR_FUNCTION)
+ {
+ gfc_free_actual_arglist (e->value.function.actual);
+ e->value.function.actual = NULL;
+ }
+
+ if (e->shape != NULL)
+ {
+ for (n = 0; n < e->rank; n++)
+ mpz_clear (e->shape[n]);
+
+ gfc_free (e->shape);
+ }
+
+
+ gfc_match_rvalue (&expr);
+
+ gcc_assert (expr && sym == expr->symtree->n.sym);
+
+ *e = *expr;
+ gfc_free (expr);
+ sym->refs++;
+
+ /* Free the old symbol. */
+ if (old_sym->ns->proc_name->attr.flavor != FL_MODULE)
+ {
+ old_sym->refs--;
+ if (old_sym->refs == 0)
+ gfc_free_symbol (old_sym);
+ }
+
+ gfc_current_locus = temp_locus;
+ }
+ }
+
+ return e->expr_type == EXPR_FUNCTION;
+ }
+
+
/* Resolve an expression. That is, make sure that types of operands agree
with their operators, intrinsic operators are converted to function calls
for overloaded types and unresolved function references are resolved. */
*** gfc_resolve_expr (gfc_expr *e)
*** 3223,3235
break;
case EXPR_FUNCTION:
- t = resolve_function (e);
- break;
-
case EXPR_VARIABLE:
! t = resolve_variable (e);
! if (t == SUCCESS)
! expression_rank (e);
break;
case EXPR_SUBSTRING:
--- 3288,3303
break;
case EXPR_FUNCTION:
case EXPR_VARIABLE:
!
! if (check_host_association (e))
! t = resolve_function (e);
! else
! {
! t = resolve_variable (e);
! if (t == SUCCESS)
! expression_rank (e);
! }
break;
case EXPR_SUBSTRING:
Index: gcc/fortran/match.h
===
*** gcc/fortran/match.h (révision 124567)
--- gcc/fortran/match.h (copie de travail)
*** match gfc_match_volatile (void);
*** 153,159
/* primary.c */
match gfc_match_structure_constructor (gfc_symbol *, gfc_expr **);
- match gfc_match_rvalue (gfc_expr **);
match gfc_match_variable (gfc_expr **, int);
match gfc_match_equiv_variable (gfc_expr **);
match gfc_match_actual_arglist (int, gfc_actual_arglist **);
--- 153,158
Index: gcc/testsuite/gfortran.dg/host_assoc_function_1.f90
===
*** gcc/testsuite/gfortran.dg/host_assoc_function_1.f90 (révision 0)
--- gcc/testsuite/gfortran.dg/host_assoc_function_1.f90 (révision 0)
***
*** 0
--- 1,26
+ ! { dg-do run }
+ ! Tests the fix for the bug PR30746, in which the reference to 'x'
+ ! in 'inner' wrongly host-associated with the variable 'x' rather
+ ! than the function.
+ !
+ ! Testcase is due to Malcolm Cohen, NAG.
+ !
+ MODULE m
+ REAL :: x(3) = (/ 1.5, 2.5, 3.5 /)
+ CONTAINS
+ SUBROUTINE s
+ CALL inner
+ CONTAINS
+
[Bug tree-optimization/25371] -ftree-vectorize results in internal compiler error on AMD64
--- Comment #10 from sebastian dot pop at cri dot ensmp dot fr 2007-05-10 09:32 --- Subject: Re: -ftree-vectorize results in internal compiler error on AMD64 Zdenek's patch for cleaning the dataref analysis is also fixing this bug. http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00634.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25371
[Bug rtl-optimization/31848] [4.3 regression] Invalid loop optimization causes bootstrap failure in genautomata
--- Comment #6 from rakdver at kam dot mff dot cuni dot cz 2007-05-10
09:42 ---
Subject: Re: [4.3 regression] Invalid loop optimization causes bootstrap
failure in genautomata
> Now, imagine the representative of a class of invariant insns is this one:
>
> (gdb) next
> 1161 reorder_insns (inv->insn, inv->insn, BB_END (preheader));
> (gdb) p debug_rtx(inv->insn)
> (insn 552 551 644 57 foo.c:11152 (set (reg:SI 323)
> (reg/v/f:SI 170 [ compressed_min_issue_delay_vect ])) 161
> {*arm_movsi_insn} (nil)
> (expr_list:REG_EQUAL (const_int 0 [0x0])
> (nil)))
> $7 = void
The heuristics may need some tweaking... moving reg-reg moves out of
loop seems unnecessary. Anyway,
> ...and we've moved the insn with note and all out of the loop, even though the
> note is not valid anymore.
> Index: loop-invariant.c
> ===
> --- loop-invariant.c(revision 124576)
> +++ loop-invariant.c(working copy)
> @@ -1156,9 +1156,21 @@ move_invariant_reg (struct loop *loop, u
> to let emit_move_insn produce a valid instruction stream. */
>if (REG_P (dest) && !HARD_REGISTER_P (dest))
> {
> + rtx note;
> +
> emit_insn_after (gen_move_insn (dest, reg), inv->insn);
> SET_DEST (set) = reg;
> reorder_insns (inv->insn, inv->insn, BB_END (preheader));
> +
> + /* If there is a REG_EQUAL note on the insn we just moved, and
> +insn is in a basic block that is not always executed, the note
> +may no longer be valid after we move the insn.
> +Note that uses in REG_EQUAL notes are taken into account in
> +the computation of invariants. Hence it is safe to retain the
> +note even if the note contains register references. */
> + if (! inv->always_executed
> + && (note = find_reg_note (inv->insn, REG_EQUAL, NULL_RTX)))
> + remove_note (inv->insn, note);
> }
>else
> {
>
>
> Zdenek, what do you think about this?
the patch looks OK.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31848
[Bug libgomp/28482] Cannot use libgomp in shared library
--- Comment #4 from mozilla at weilbacher dot org 2007-05-10 09:44 --- Thanks Jakub. I downloaded snapshot "4.3.0 20070503 (experimental)" (the gcc-4.3-20070504.tar.bz2 package) and confirmed that the issue with my data processing plugins is fixed when compiling with this gcc and libgomp. Not sure what the GCC policy is for marking bugs fixed but I am happy. :-) Any chance to get this into 4.2 (or one of the later 4.2.x releases)? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28482
[Bug middle-end/31892] New: optimization: Loop not optimized away
Expected: The following loop is optimized way using gfortran -O3.
program prova
implicit none
integer :: i, j, Nx, Ny
parameter(Nx=1,Ny=1)
real(8) :: A(Nx,Ny)
do j=1,Ny
do i=1,Nx
A(i,j)=sin(1.d0+i+j);
end do
end do
end program
In an equivalent C program the loop is optimized away and the run time drops
from 10.927s to 0.001s: gcc -O3
#include
#define NX 1
#define NY 1
int main() {
double A[NX][NY];
int i, j;
for(i = 0; i < NX; i++)
for(j = 0; j < NY; j++)
A[i][j] = sin(3.0+i+j);
return 0;
}
--
Summary: optimization: Loop not optimized away
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31892
[Bug ada/31877] Imported variables marked "volatile" in Ada
--- Comment #4 from baldrick at gcc dot gnu dot org 2007-05-10 10:11 --- I'm reopening this as an enhancement request. I agree that the code currently produced is correct, i.e. executes as required by the RM. However it is suboptimal and in my opinion (and apparently in Eric's opinion too) the code quality can be improved in gcc 4 with reasonable effort. -- baldrick at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31877
[Bug tree-optimization/25371] -ftree-vectorize results in internal compiler error on AMD64
--- Comment #11 from rakdver at gcc dot gnu dot org 2007-05-10 10:46
---
Simplified testcase:
void
slow_close(int n)
{
int i;
double *mm;
for (i=0;i<2*n;i++)
for (i=0;i<2*n;i++)
*(mm+i*2*n+i) = 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25371
[Bug c/31893] New: Please provide an "inout" attribute for function parameters.
Here is what I mean. When you write code like:
int foo(void) {
static bar_t bar;
call_some_function(&bar);
return 0;
}
gcc assumes that call_some_function will initialize bar properly. Though,
sometimes call_some_function is a function that will modify 'bar' but also need
it to be properly initialized. In that case, the parameter is inout. (I must
say I'm unsure what gcc thinks if call_some_function prototype is: void
call_some_function(const bar_t *); maybe it suffers from the same problem).
That'd be great to have an __attribute__((inout(1,2,3...))) to say that the
1st, 2nd, 3rd, ... variables of the function need their argument to be
initialized. That would make gcc issue warning about variables beeing used
uninitialized properly.
Maybe "inout" is a very lousy name, and I don't care much about it. My point
is, I'd really like to be able to express in the function prototypes that a
structure needs to be initialized before that function can be called. WIth this
attribute, the call_some_function prototype would be:
int call_some_function(bar_t *) __attribute__((inout(1)));
--
Summary: Please provide an "inout" attribute for function
parameters.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: madcoder at debian dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31893
[Bug tree-optimization/31885] Not removing empty loop, scev not finding the correct result
--- Comment #1 from rakdver at gcc dot gnu dot org 2007-05-10 11:01 --- This gets fixed by the scev changes of http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00634.html (the part about "chrec_contains_undetermined considers NULL_TREE to be a special automatically generated chrec... However, NULL_TREE is a valid argument of some of the tree nodes, so chrec_contains_undetermined ould for example return true for &a[5](which causes some of the analyses to stop consider such expressions and fail).") I will commit those separately. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31885
[Bug c/31886] (different from bug report c/31077 and 29241) C handling of always_inline attribute error and a solution
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-05-10 11:04 --- Confirmed. Either we should not accept always_inline on a function not declared inline (or warn in that case), or a function marked always_inline should be considered for inlining always. Second, the t.i:3: sorry, unimplemented: inlining failed in call to 'alloc_null_binding1': function body not available is fixed in 4.1.2. Which leaves us with t.i:3: sorry, unimplemented: inlining failed in call to 'alloc_null_binding1': function not inlinable with the function not marked inline (but only for -O0, not -O). I guess we want to make that behavior at least consistent. Note with -O0 -finline we get t.i:3: sorry, unimplemented: inlining failed in call to 'alloc_null_binding1': function body not available again ;) -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org, hubicka at gcc dot gnu ||dot org Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-05-10 11:04:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31886
[Bug c/31893] Please provide an "inout" attribute for function parameters.
--- Comment #1 from madcoder at debian dot org 2007-05-10 11:12 ---
It seems that even if the argument is declared const foo_t * gcc assumes the
function will initialize the data, which is rather ... erm... strange. Here is
the testcase:
==
struct foo { int toto; };
void do_bar(const struct foo *);
int main(void) {
struct foo foo;
do_bar(&foo);
return 0;
}
==
gcc -Wall -Wextra -O2 -Wuninitialized -c -o foo.o foo.c
gives no warning while I'd expect to have one as do_bar takes a const foo_t *
hence should not initialize it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31893
[Bug rtl-optimization/31523] bootstrap failure with -O2 -finline-functions
--- Comment #17 from ebotcazou at gcc dot gnu dot org 2007-05-10 12:16
---
Reduced C++ testcase:
typedef enum { _B_FALSE, _B_TRUE } boolean_t;
typedef union { int i; } u;
cp/lex.c:make_aggr_type is miscompiled when cxx_make_type is inlined into it.
Amazingly enough, this is the same problem as PR rtl-optimization/31691.
*** This bug has been marked as a duplicate of 31691 ***
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Component|bootstrap |rtl-optimization
Resolution||DUPLICATE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31523
[Bug rtl-optimization/31691] [4.1 regression] optimized code taking the wrong branch
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2007-05-10 12:16 --- *** Bug 31523 has been marked as a duplicate of this bug. *** -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||anirkko at insel dot ch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31691
[Bug fortran/30746] 50th Anniversary Bug - Forward reference to contained function
--- Comment #4 from pault at gcc dot gnu dot org 2007-05-10 12:19 --- (In reply to comment #3) > The patch below does the job. Not quite - apart from 'n' not being declared, this patch causes a couple of regressions. These are easily fixed. However, if the function x has a different number of arguments to the rank of variable 'x', an error ensues. This is going to require a bit more work but it is promising. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30746
[Bug fortran/31867] function result with character LEN computed at run time
--- Comment #5 from burnus at gcc dot gnu dot org 2007-05-10 12:34 --- Reduced test case, which gives still the same valgrind error. In addition, len(join(words)) should give 8 not 10. Using "len=5" instead of "len=*" or "words(2)" instead of "words(:) fixes both. (=> "8" and no valgrind error) program xjoin implicit none character (len=5) :: words(2) = (/"two ","three"/) write (*,*) len(join(words)) ! should be 8 is 10 write (*,*) join(words) ! valgrind error contains function join(words) result(str) character (len=*), intent(in):: words(:) character (len=sum(len_trim(words))) :: str str = '' end function join end program xjoin -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2007-05-10 12:34:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31867
[Bug ada/31894] New: Latest gcc srpm from Fedora doesn't build on alpha / ada error
gnat1: note: -freorder-blocks-and-partition does not work with exceptions ../../gcc/ada/debug.adb: In function 'Debug.Get_Debug_Flag_K': ../../gcc/ada/debug.adb:580: error: coverage mismatch for function 'debug__get_debug_flag_k' while reading counter 'arcs' ../../gcc/ada/debug.adb:580: error: checksum is 8f519c91 instead of ae23faaa ../../gcc/ada/debug.adb: In function 'Debug.Set_Debug_Flag': ../../gcc/ada/debug.adb:666: error: coverage mismatch for function 'debug__set_debug_flag' while reading counter 'arcs' ../../gcc/ada/debug.adb:666: error: checksum is 1d01628a instead of 4ebf24e0 ../../gcc/ada/debug.adb: In function 'Debug.Set_Dotted_Debug_Flag': ../../gcc/ada/debug.adb:751: error: coverage mismatch for function 'debug__set_dotted_debug_flag' while reading counter 'arcs' ../../gcc/ada/debug.adb:751: error: checksum is 50c8a279 instead of ad6a9e1e Ideas? -- Summary: Latest gcc srpm from Fedora doesn't build on alpha / ada error Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: oliver at linux-kernel dot at GCC build triplet: alpha-redhat-linux GCC host triplet: alpha-redhat-linux GCC target triplet: alpha-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31894
[Bug libfortran/31880] [4.2 only] silent data corruption in gfortran read statement
--- Comment #9 from roconnor at health dot usf dot edu 2007-05-10 12:50 --- (In reply to comment #7) > Russel, thanks for finding this and reporting it. I assume you do not have > copyright assignment. I committed the patch because it is very small and > simple. > You're welcome. Thank you for the prompt response. You're right about the copyright assignment. But even with the test case, it comes in under the FSF's 15-line threshold for legally significant. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31880
[Bug testsuite/31884] priority_queue_dijkstra.cc operates on deallocated memory
--- Comment #1 from amylaar at gcc dot gnu dot org 2007-05-10 15:02 --- I find that the failure goes away when I assign a_it[0] to the iterator for the current node before p.pop, and make the loop skip an iteration when it finds that the iterator for the current neighbor is a_it[0]. Does that also work for you on powerpc? -- amylaar at gcc dot gnu dot org changed: What|Removed |Added CC||dje at watson dot ibm dot ||com, bkoz at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31884
[Bug c/31878] Spurious warnings generated due to not optimizing first
--- Comment #3 from manu at gcc dot gnu dot org 2007-05-10 15:50 ---
(In reply to comment #2)
> So are you saying that it is the case that the f() function below might return
> without a value? Since that is what the warning suggests.
assert() does not return a value and it is the last . So, yes, as far as GCC
knows when it emits the warning, f() may return without a value. Another
example:
int f(int x)
{
int y = 1;
if(y)
return x;
}
> (My interpretation re the optimizer may be completely off, I don't know GCC
> internals, but I have a hard time believing that GCC warning about something
> that cannot possibly happen is not a bug)
You may know that it cannot possibly happen but GCC may not know it. In the
general case, it is the halting problem. In practice, there should be a limit
to how much effort GCC should do. The current limit is that warnings (in
general) are given by front-ends and should be the same with and without
optimisation. But even if that weren't the case, the warning currently comes
before optimisation and changing this is not simple at all. Finally, you could
always build a testcase where GCC is not smart enough.
I agree with Andrew: this is not a bug. At most, it is an enhancement request
that conflicts with the current general rule that front-end warnings should be
the same with and without optimisation.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31878
[Bug ada/31894] Latest gcc srpm from Fedora doesn't build on alpha / ada error
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-05-10 16:08 --- That's a fedora problem then. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31894
[Bug target/31897] New: [Regression 4.3] 30% speed regression with -m32 on Opteron with rnflow
The Polyhedron test case rnflow is runs since 20 April 30% slower than before. gfortran -m32 -march=opteron -ffast-math -funroll-loops -ftree-vectorize -ftree-loop-linear -O3 rnflow.f90 Today's gfortran: real0m58.205s / user0m56.600s gfortran 2007-04-20 (r123986): real0m58.237s / user0m56.396s gfortran 2007-04-16 (r123859): real0m43.912s / user0m42.403s gfortran 4.2.0: real0m45.449s / user0m43.859s This only affects that compiliation with that options. Using the following option: gfortran -m32 -march=opteron -ffast-math -funroll-loops -ftree-loop-linear -ftree-vectorize -mfpmath=sse -msse3 -O3 or compiling for a 64bit system does not show this slowdown. See also: http://physik.fu-berlin.de/~tburnus/gcc-trunk/benchmark/run-rnflow.png http://physik.fu-berlin.de/~tburnus/gcc-trunk/benchmark/ and for x86-64 which is not affected, see also: http://www.suse.de/~gcctest/c++bench/polyhedron/polyhedron-summary.txt-2-0.html The benchmark can be obtained from: http://www.polyhedron.co.uk/pb05/polyhedron_benchmark_suite.html directory: pb05/lin/source -- Summary: [Regression 4.3] 30% speed regression with -m32 on Opteron with rnflow Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31897
[Bug ada/31894] Latest gcc srpm from Fedora doesn't build on alpha / ada error
--- Comment #2 from oliver at linux-kernel dot at 2007-05-10 16:58 --- Richard. It might be a Fedora problem. Yes. But can you help me to track it down? gcc maintainer from Fedora will not really help me, as Fedora doesn't have support for Alpha, that's part of the AlphaCore team. And in case you don't know; I'm part of it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31894
[Bug libfortran/31880] [4.2 only] silent data corruption in gfortran read statement
--- Comment #10 from patchapp at dberlin dot org 2007-05-10 17:25 --- Subject: Bug number PR31880 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00728.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31880
[Bug testsuite/25352] xfail within dg-do command has no effect
--- Comment #7 from ghazi at gcc dot gnu dot org 2007-05-10 17:44 --- Ben, Janis, Would you please offer an update on the status of this PR? I'm running into another situation where I need to xfail a dg-do link, and due to the issues discussed in this PR it doesn't work. Has dejagnu cvs sources been fixed to handle this case? Has 1.4.5 been released? (I don't see it on ftp.gnu.org). Thanks, --Kaveh -- ghazi at gcc dot gnu dot org changed: What|Removed |Added CC||bje at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25352
[Bug c/31878] Spurious warnings generated due to not optimizing first
--- Comment #4 from lloyd at randombit dot net 2007-05-10 17:51 ---
Manuel,
For your example code, GCC _is_ aware that the function always returns, since
the code it generates for it (with optimization) is:
f:
movl%edi, %eax
ret
So obviously it knows, at the level of the code generator, it's just a question
of propagating that information back to the frontend.
Speaking of the same warnings with-or-without optimizations - should I then
file a bug about:
int f(int x)
{
int y;
if(x)
return y;
return 0;
}
No warning about y being used uninitialized unless I compile with
optimizations...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31878
[Bug tree-optimization/31797] [4.2/4.3 Regression] infinite loop in tree-ssa-pre or ICE
--- Comment #10 from dberlin at gcc dot gnu dot org 2007-05-10 19:59 --- Ugh, so operand_equal_p claims two side-effecting component_refs are never the same, unless they are pointer equal. For non-sideeffects ones, it checks whether the operands are the same. This causes PRE to continually make the value over and over again, and think something is changing. We only care whether they are performing the exact same operation, which they are. I guess i'm going to have to make expressions_equal_p that only ensures they are the exact same operation with the same flags (IE both have side-effects, etc). Would any middle-end person have a problem with this? -- dberlin at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org AssignedTo|unassigned at gcc dot gnu |dberlin at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-05-07 00:22:33 |2007-05-10 19:59:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31797
[Bug rtl-optimization/31691] [4.1 regression] optimized code taking the wrong branch
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2007-05-10 20:30 --- Created an attachment (id=13540) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13540&action=view) Fix for the 4.1 branch. I'm waiting for the 4.2 branch to reopen in order to install it on all branches. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31691
[Bug fortran/30746] 50th Anniversary Bug - Forward reference to contained function
--- Comment #5 from patchapp at dberlin dot org 2007-05-10 21:10 --- Subject: Bug number PR30746 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00746.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30746
[Bug fortran/31474] ENTRY & procedural pointer: insert_bbt(): Duplicate key found!
--- Comment #3 from patchapp at dberlin dot org 2007-05-10 21:30 --- Subject: Bug number PR31474 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00748.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31474
[Bug rtl-optimization/31889] compiler misses opportunity to combine multiple identical function return paths
--- Comment #3 from raeburn at raeburn dot org 2007-05-10 22:25 --- Subject: Re: compiler misses opportunity to combine multiple identical function return paths On May 10, 2007, at 2:13, steven at gcc dot gnu dot org wrote: > --- Comment #2 from steven at gcc dot gnu dot org 2007-05-10 > 07:13 --- > Try compiling with "--param min-crossjump-insns=1". I'm curious to > hear if > that fixes this problem for you. Yes, with that option, the second path loads the pointer to the string to be displayed, and jumps to the puts call. Actually, it does for both versions of the code, the hairier form and the simpler form, which were producing different (but functionally equivalent) less-optimal code before. Ken -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31889
[Bug tree-optimization/31885] Not removing empty loop, scev not finding the correct result
--- Comment #2 from rakdver at gcc dot gnu dot org 2007-05-10 22:33 --- Subject: Bug 31885 Author: rakdver Date: Thu May 10 21:33:11 2007 New Revision: 124602 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124602 Log: PR tree-optimization/31885 * tree-chrec.c (chrec_contains_undetermined): Do not consider NULL_TREE to be undetermined. (automatically_generated_chrec_p): Return false for NULL. * gcc.dg/tree-ssa/loop-29.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/loop-29.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-chrec.c trunk/gcc/tree-chrec.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31885
[Bug c/31893] Please provide an "inout" attribute for function parameters.
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-10 23:00 --- What are you doing, writting Fortran code in C? :) (really I am serious about this one too) > It seems that even if the argument is declared const foo_t * gcc assumes the > function will initialize the data, which is rather ... erm... strange. Why do you think it is strange? you can remove the const part in do_bar anyways. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31893
[Bug tree-optimization/31885] Not removing empty loop, scev not finding the correct result
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-05-10 23:09 --- Fixed, thanks Zdenek. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31885
[Bug target/17390] missing floating point compare optimization
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2007-05-10 23:15 --- ping -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17390
[Bug fortran/20896] [4.2 and 4.1 only] ambiguous interface not detected
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-05-10 23:20 --- Paul, what is the status on this one? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20896
[Bug c/31887] bad warning converting qualified void* to qualified array pointer
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-11 00:00 --- I think only "void*" can be done with an implicat cast so we go from const void* to void* and then to const block*. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31887
[Bug rtl-optimization/31848] [4.3 regression] Invalid loop optimization causes bootstrap failure in genautomata
--- Comment #7 from steven at gcc dot gnu dot org 2007-05-11 00:14 --- Patch posted... Waiting for Richard Earnshaw to confirm whether this fixes his problem, and also waiting for some performance numbers. -- steven at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||05/msg00768.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31848
[Bug testsuite/25352] xfail within dg-do command has no effect
--- Comment #8 from janis at gcc dot gnu dot org 2007-05-11 00:51 --- I had forgotten all about this. Today I checked to see how older versions of DejaGnu and GCC tests handled xfail for dg-do keywords other than "run". I only went back as far as GCC 3.0.4 and DejaGnu 1.4, but they also ignored xfail in dg-do for preprocess/compile/assemble/link. There are currently 27 tests that use this construct: three in libstdc++-v3 and 24 in gcc. My recommendations are to document, in the description of test directives in the GCC Internals manual, that xfail for dg-do is only honored for dg-do run and ignored for other keywords, recommending the use of dg-xfail-if instead; and to remove the xfail section from the 27 tests that use it when it's ignored. I'll do these if it sounds reasonable. I don't think this is worth working around in the GCC testsuite support or fixing in DejaGnu. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25352
[Bug libfortran/31880] [4.2 only] silent data corruption in gfortran read statement
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2007-05-11 01:34 --- Subject: Bug 31880 Author: jvdelisle Date: Fri May 11 00:34:41 2007 New Revision: 124609 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124609 Log: 2007-05-10 Jerry DeLisle <[EMAIL PROTECTED]> PR libfortran/31880 * io/unix.c (fd_alloc_r_at): Fix calculation of physical offset. 2007-05-10 Jerry DeLisle <[EMAIL PROTECTED]> PR libfortran/31880 * gfortran.dg/unf_read_corrupted_2.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/unf_read_corrupted_2.f90 Modified: branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/libgfortran/ChangeLog branches/gcc-4_1-branch/libgfortran/io/unix.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31880
ld / gcc crashes (segmentation fault) while linking cpp shared objects
Symptom: ld crashes if map file generation is specified. Without map-file generation (without -Map, ... ) the link process works fine. Language: C++ Version: sh-3.1$ gcc-4.1 --version gcc-4.1 (GCC) 4.1.3 20070429 (prerelease) (Debian 4.1.2-6) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Command line: (Sorry for long line.) gcc-4.1 -shared -ggdb -Wl,-Map,../../lib/lib.linux_gcc4_i686/libMADCore.so.map ../../.build/linux_gcc4_i686/lib/core/o/pi_cAbstractClassLoader.cpp.o ../../.build/linux_gcc4_i686/lib/core/o/pi_cAbstractPlatformInfo.cpp.o ../../.build/linux_gcc4_i686/lib/core/o/pi_cPIExceptions.cpp.o ../../.build/linux_gcc4_i686/lib/core/o/pi_cPlatform.cpp.o ../../.build/linux_gcc4_i686/lib/core/o/pi_cSystem.cpp.o ../../.build/linux_gcc4_i686/lib/core/o/pi_cSysTime.cpp.o ../../.build/linux_gcc4_i686/lib/core/o/pi_cUnsupportedPlatformException.cpp.o ../../.build/linux_gcc4_i686/lib/core/o/pi_piBreakPoint.cpp.o ../../.build/linux_gcc4_i686/lib/core/o/pi_piGlobals.cpp.o ../../.build/linux_gcc4_i686/lib/core/o/pi_piStackTrace.cpp.o ../../.build/linux_gcc4_i686/lib/core/o/pi_piTypeSerialize.cpp.o ../../.build/linux_gcc4_i686/lib/core/o/pi_piVoid.cpp.o ../../.build/linux_gcc4_i686/lib/core/o/pi_piThread_cAbstractMutexImpl.cpp.o ../../.build/linux_gcc4_i686/lib/core/o/pi_piThread_cAbstractRunnableImpl.cpp.o ../../.build/linux_gcc4_i686/lib/core/o/pi_piDebug_cAbstractTTYOut.cpp.o ../../.build/linux_gcc4_i686/lib/core/o/pi_piDebug_piDebug.cpp.o ../../.build/linux_gcc4_i686/lib/core/o/pi_platform_dependend_native_linux_cLinuxBreakPoint.cpp.o ../../.build/linux_gcc4_i686/lib/core/o/pi_platform_dependend_native_linux_cLinuxClassLoader.cpp.o ../../.build/linux_gcc4_i686/lib/core/o/pi_platform_dependend_native_linux_cLinuxDirImpl.cpp.o ../../.build/linux_gcc4_i686/lib/core/o/pi_platform_dependend_native_linux_cLinuxFileImpl.cpp.o ../../.build/linux_gcc4_i686/lib/core/o/pi_platform_dependend_native_linux_cLinuxFileInfoImpl.cpp.o ../../.build/linux_gcc4_i686/lib/core/o/pi_platform_dependend_native_linux_cLinuxFsImpl.cpp.o ../../.build/linux_gcc4_i686/lib/core/o/pi_platform_dependend_native_linux_cLinuxMutexImpl.cpp.o ../../.build/linux_gcc4_i686/lib/core/o/pi_platform_dependend_native_linux_cLinuxPlatformInfo.cpp.o ../../.build/linux_gcc4_i686/lib/core/o/pi_platform_dependend_native_linux_cLinuxThreadImpl.cpp.o ../../.build/linux_gcc4_i686/lib/core/o/pi_platform_dependend_native_win32_cWin32ClassLoader.cpp.o ../../.build/linux_gcc4_i686/lib/core/o/pi_platform_dependend_native_win32_cWin32FileImpl.cpp.o ../../.build/linux_gcc4_i686/lib/core/o/pi_platform_dependend_native_win32_cWin32PlatformInfo.cpp.o ../../.build/linux_gcc4_i686/lib/core/o/std_cAbstractException.cpp.o ../../.build/linux_gcc4_i686/lib/core/o/std_cAbstractTokenSpec.cpp.o ../../.build/linux_gcc4_i686/lib/core/o/std_cAsciiString.cpp.o ../../.build/linux_gcc4_i686/lib/core/o/std_cAsciiStringStream.cpp.o ../../.build/linux_gcc4_i686/lib/core/o/std_cAsciiStringTokenizer.cpp.o ../../.build/linux_gcc4_i686/lib/core/o/std_cBugException.cpp.o ../../.build/linux_gcc4_i686/lib/core/o/std_cBuildInfo.cpp.o ../../.build/linux_gcc4_i686/lib/core/o/std_cByteArray.cpp.o ../../.build/linux_gcc4_i686/lib/core/o/std_cByteArrayRef.cpp.o ../../.build/linux_gcc4_i686/lib/core/o/std_cConstCStringRef.cpp.o ../../.build/linux_gcc4_i686/lib/core/o/std_cDate.cpp.o ../../.build/linux_gcc4_i686/lib/core/o/std_cDateTime.cpp.o ../../.build/linux_gcc4_i686/lib/core/o/std_cNumberConversion.cpp.o ../../.build/linux_gcc4_i686/lib/core/o/std_cNumberConversionException.cpp.o ../../.build/linux_gcc4_i686/lib/core/o/std_cNumberConversionFormat.cpp.o ../../.build/linux_gcc4_i686/lib/core/o/std_cOSErrorException.cpp.o ../../.build/linux_gcc4_i686/lib/core/o/std_cOutOfBoundsException.cpp.o ../../.build/linux_gcc4_i686/lib/core/o/std_cOutOfRangeException.cpp.o ../../.build/linux_gcc4_i686/lib/core/o/std_cRuntimeException.cpp.o ../../.build/linux_gcc4_i686/lib/core/o/std_cSTDExceptions.cpp.o ../../.build/linux_gcc4_i686/lib/core/o/std_cTextParseException.cpp.o ../../.build/linux_gcc4_i686/lib/core/o/std_cTime.cpp.o ../../.build/linux_gcc4_i686/lib/core/o/std_cUTF8StringTokenizer.cpp.o ../../.build/linux_gcc4_i686/lib/core/o/std_tSharedObject.cpp.o ../../.build/linux_gcc4_i686/lib/core/o/rmi_cAbstractRMIFactory.cpp.o ../../.build/linux_gcc4_i686/lib/core/o/rmi_cAbstractSignal.cpp.o ../../.build/linux_gcc4_i686/lib/core/o/rmi_cAbstractSlotCall.cpp.o ../../.build/linux_gcc4_i686/lib/core/o/rmi_cConnectable.cpp.o ../../.build/linux_gcc4_i686/lib/core/o/rmi_cNoSuchSignalException.cpp.o ../../.build/linux_gcc4_i686/lib/core/o/rmi_cNoSuchSlotException.cpp.o ../../.build/linux_gcc4_i686/lib/core/o/rmi_cPu
[Bug target/31876] SH: ICE in gen_lowpart_general, at rtlhooks.c:59
--- Comment #4 from kkojima at gcc dot gnu dot org 2007-05-11 05:53 --- Subject: Bug 31876 Author: kkojima Date: Fri May 11 04:53:19 2007 New Revision: 124611 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124611 Log: PR target/31876 * config/sh/sh.md (andsi3): Avoid calling gen_lowpart on a SImode SUBREG of a floating point register. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/config/sh/sh.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31876
[Bug libfortran/31409] [4.1 only, regression] Reading after ERROR_SHORT_RECORD
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-05-11 06:40 --- Subject: Bug 31409 Author: jvdelisle Date: Fri May 11 05:40:37 2007 New Revision: 124612 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124612 Log: 2007-05-10 Jerry DeLisle <[EMAIL PROTECTED]> PR libfortran/31409 * io/transfer.c (read_block_direct): Backport from 4.3 trunk. Modified: branches/gcc-4_1-branch/libgfortran/ChangeLog branches/gcc-4_1-branch/libgfortran/io/transfer.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31409
[Bug libfortran/31409] [4.1 only, regression] Reading after ERROR_SHORT_RECORD
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2007-05-11 06:41 --- Fixed on 4.1. Not a bug on 4.2 or 4.3 -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31409
[Bug rtl-optimization/31848] [4.3 regression] Invalid loop optimization causes bootstrap failure in genautomata
--- Comment #8 from bonzini at gnu dot org 2007-05-11 07:19 --- I started bootstrap and SPEC2000 on i686-pc-linux-gnu, I'll post the result tomorrow hopefully (if the weekend swamps me it I might delay that). :-( -- bonzini at gnu dot org changed: What|Removed |Added CC||bonzini at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31848
[Bug fortran/31474] ENTRY & procedural pointer: insert_bbt(): Duplicate key found!
--- Comment #4 from pault at gcc dot gnu dot org 2007-05-11 07:20 --- Subject: Bug 31474 Author: pault Date: Fri May 11 06:19:57 2007 New Revision: 124613 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124613 Log: 2007-05-11 Paul Thomas <[EMAIL PROTECTED]> PR fortran/31474 * decl.c (get_proc_name): If an entry has already been declared as a module procedure, pick up the symbol and the symtree and use them for the entry. 2007-05-11 Paul Thomas <[EMAIL PROTECTED]> PR fortran/31474 * gfortran.dg/entry_10.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/entry_10.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31474
[Bug fortran/31474] ENTRY & procedural pointer: insert_bbt(): Duplicate key found!
--- Comment #5 from pault at gcc dot gnu dot org 2007-05-11 07:20 --- Fixed on trunk Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31474
[Bug target/31876] SH: ICE in gen_lowpart_general, at rtlhooks.c:59
--- Comment #5 from kkojima at gcc dot gnu dot org 2007-05-11 07:13 --- Fixed. -- kkojima at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31876
