[Bug libstdc++/18053] __gnu_cxx::hash_setA uses return type of A::operator() instead of A
--- Additional Comments From pcarlini at suse dot de 2005-01-22 09:16 --- Ok.. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18053
[Bug ada/19526] Windows errorcodes wrong in Ada when tasking
-- What|Removed |Added CC||dannysmith at users dot ||sourceforge dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19526
[Bug middle-end/18008] [4.0 Regression] Duplicate mask on bitfield insertion
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-01-22 10:04 --- Combine ought to merge these two (insn 13 11 14 1 (parallel [ (set (reg:QI 60) (and:QI (subreg:QI (reg/v:SI 59 [ v ]) 0) (const_int 3 [0x3]))) (clobber (reg:CC 17 flags)) ]) -1 (nil) (nil)) (insn 15 14 16 1 (parallel [ (set (reg:SI 62) (zero_extend:SI (reg:QI 60))) (clobber (reg:CC 17 flags)) ]) -1 (nil) (nil)) into (insn 15 14 16 1 (parallel [ (set (reg:SI 62) (zero_extend:SI (and:QI (subreg:QI (reg/v:SI 59 [ v ]) 0) (const_int 3 [0x3] (clobber (reg:CC 17 flags)) ]) -1 (nil) (nil)) which can be simplified via the expand_compound_operation machinery to (insn 15 14 16 1 (parallel [ (set (reg:SI 62) (and:SI (reg/v:SI 59 [ v ]) (const_int 3 [0x3]))) (clobber (reg:CC 17 flags)) ]) -1 (nil) (nil)) and the set of (reg:SI 63) from (and:SI (reg:SI 62) (const_int 3)) should be taken care of by the nonzero_bits stuff. So it's feasible to have combine fix it, at least. Hum, but maybe the clobber is messing up combine? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18008
[Bug target/19571] floating point registers not preserved during function call
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-01-22
10:36 ---
The code generated looks correct to me.
The generated assembler that you've give for __cos is clearly saving and
restoring f4-f7.
__cos:
// Saves the integer registers
ca4c: e92d4070stmdb sp!, {r4, r5, r6, lr}
// Does some processing that does not involve floating point
ca50: e3c02102bic r2, r0, #-2147483648; 0x8000
ca54: e35205f9cmp r2, #1044381696 ; 0x3e40
ca58: e1a05001mov r5, r1
ca5c: e1a04000mov r4, r0
// Sets f0: OK, since f0 is call-clobbered.
ca60: be008189mvfltd f0, #1.0
// This instruction saves 4 floating point registers, starting with f4 on the
stack
ca64: ed2d420csfm f4, 4, [sp, #-48]!
... // Rest of function
// And this instruction loads them back again.
ccec: ecbd420clfm f4, 4, [sp], #48
ccf0: e8bd8070ldmia sp!, {r4, r5, r6, pc}
As far as I can see this is the only exit point from the generated code.
I think you need to check that the floating point emulator in your kernel is
functioning correctly. Particularly for lfm/sfm.
R.
--
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19571
[Bug target/19506] [4.0 Regression] PovRay produces wrong pictures with -mfpmath=sse -ffast-math.
--- Additional Comments From uros at kss-loka dot si 2005-01-22 11:34 --- Should patch to sse_comparison_operator (http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01087.html) be reverted in this case? It didn't fix the problem, and according to comment #9 the problem is not in this area. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19506
[Bug fortran/19574] New: specification expression failure
The following code (from
http://home.comcast.net/~kmbtib/gfortran_bugs/REF_JVB_GFTN_005.html) fails in
the following way (on i686-mingw and powerpc-apple-darwin):
-
module funcs
implicit none
contains
function f(x)
character(*), intent(in) :: x
integer f(len(x))
integer i
! do i=1,len(x)
! f(i) = 0
! end do
end function f
end module funcs
program spec_expr_test
use funcs
implicit none
write(*,*) size(f('test'))
end program spec_expr_test
-
$ gfortran reduced_spec.f90 ./a.out
reduced_spec.f90: In function 'f':
reduced_spec.f90:4: warning: Function does not return a value
At line 19 of file reduced_spec.f90
Fortran runtime error: Internal: Possible double free of temporary.
If you uncomment the three lines in the code above, you get a runtime segfault
(on powerpc-apple-darwin):
$ gfortran reduced_spec.f90 ./a.out
zsh: bus error ./a.out
I don't know if these two issues are related, but I post them both in one PR
just in case they can be debuggued altogether.
--
Summary: specification expression failure
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: coudert at clipper dot ens dot fr
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19574
[Bug libgcj/19512] Optional JNI error checking
--- Additional Comments From mark at gcc dot gnu dot org 2005-01-22 11:51 --- Working on a patch. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19512
[Bug fortran/19575] New: cdabs intrinsic incorrectly handled with -std=f95
The following code: program abs_test1 implicit none intrinsic cdabs ! write(*,*) cdabs((4,3)) ! Causes ICE, as well call sub(cdabs) end program abs_test1 subroutine sub(f) implicit none interface elemental function f(x) complex(kind(1.0d0)), intent(in) :: x real(kind(x)) :: f end function f end interface complex(kind(1.0d0)) x x = (4,3) write(*,*) f(x) end subroutine sub has an incorrect behavior when -std=f95 is specified (according to James Van Buskirk, see http://home.comcast.net/~kmbtib/gfortran_bugs/REF_JVB_GFTN_003.html). On powerpc-apple-darwin, I get: $ gfortran abs_test1.f90 ./a.out 5.00 $ gfortran abs_test1.f90 -std=f95 ./a.out 2.25 while on i686-mingw: $ gfortran abs_test1.f90 ./a.out 5.00 $ gfortran abs_test1.f90 -std=f95 ./a.out NaN Another related issue: when uncommenting the commented line, the behavior is correct without -std=f95 (error issued at compile-time), but -std=f95 causes ICE: $ gfortran abs_test1.f90 -std=f95 ./a.out abs_test1.f90: In function 'MAIN__': abs_test1.f90:12: internal compiler error: in gfc_typenode_for_spec, at fortran/trans-types.c:613 -- Summary: cdabs intrinsic incorrectly handled with -std=f95 Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: coudert at clipper dot ens dot fr CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19575
[Bug target/19571] floating point registers not preserved during function call
--- Additional Comments From jack at cs dot york dot ac dot uk 2005-01-22 12:06 --- Thankyou, that's most helpful. The problem is in the ARM simulator I am using. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19571
[Bug target/19549] Register allocation problem in inline asm on x86.
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-22
12:07 ---
Falk, sorry but Andrew is right.
First of all, it *does* compile for me at -O[123] on i686, but not
at -O0 because reload can't find a register. I tried GCC 3.3, 3.4,
and 4.0, and -march={i386,i686,athlon-xp,pentium4}, and all these
versions behave the same.
Second, both PRs concern a basically overly constrained asm. I am
sure I mentioned in PR11203 that any success in compiling such asm
is just luck.
Not a GCC bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19549
[Bug inline-asm/11203] source doesn't compile with -O0 but they compile with -O3
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-22 12:14 --- Martin, you should realize that this problem *cannot* be solved. Yes, there will perhaps be a time when this particular test case compiles, though I think that is unlikely. But anyway, then there will be other cases that fail. The reason is dead simple: register allocation is NP-complete, so it is even *theoretically* not possible to write register allocators that always find a coloring. That means any register allocator will always fail on some very constrained asm input. And you cannot allow it to run indefinitely until a coloring is found, because then you've turned the graph coloring problem into the halting problem because you can't prove that a coloring exists and that the register allocator algorithm will terminate. So really it doesn't matter at all whether or not your specific inline asm compiles or not. When yours does, someone else's will fail. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11203
[Bug fortran/19576] New: [ICE] achar in initialization
The following code: program achar_test implicit none integer i character(*), parameter :: y(0:31) = (/(achar(i),i=64,95)/) write(*,*) y end program achar_test causes ICE on i686-mingw and powerpc-apple-darwin: $ gfortran achar_test.f90 achar_test.f90: In function 'MAIN__': achar_test.f90:5: internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.c:827 -- Summary: [ICE] achar in initialization Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: coudert at clipper dot ens dot fr CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19576
[Bug target/19528] [4.0 regression] missing ra.h
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-22 12:19 --- Mark, while you're using your RM powers to move the target milestone on this one, could you also please use your GWP powers to approve the simple patch http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01258.html that fixes this bug? -- What|Removed |Added CC||mark at codesourcery dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19528
[Bug target/19528] [4.0 regression] missing ra.h
--- Additional Comments From joel at gcc dot gnu dot org 2005-01-22 12:57 --- (In reply to comment #10) Mark, while you're using your RM powers to move the target milestone on this one, could you also please use your GWP powers to approve the simple patch http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01258.html that fixes this bug? I can confirm that sh-rtems builds with this patch and won't without it. The resulting compiler will also build RTEMS. No sh target builds without this fix so I am also politely asking this to be committed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19528
[Bug target/19378] [4.0 Regression] ICE during bootstrap compiling __fixdfdi
--- Additional Comments From joel at gcc dot gnu dot org 2005-01-22 13:02 --- (In reply to comment #6) AVR is not a primary or secondary platform; removing target milestone. Understood but there is a patch from Rager Sayle and all it needs is to be reviewed and approved. He posted tests rules and an explanation here: http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00834.html He reports on avr-elf and I can confirm that this lets avr-rtems build. Please approve this patch. -- What|Removed |Added CC||mmitchel at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19378
[Bug fortran/19576] [ICE] achar in initialization
--- Additional Comments From Thomas dot Koenig at online dot de 2005-01-22 13:30 --- Same thing on i686-pc-linux-gnu. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19576
[Bug fortran/19576] achar in initialization
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-01-22 13:32 --- Please don't put ICE in the summary. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2005-01-22 13:32:02 date|| Summary|[ICE] achar in |achar in initialization |initialization | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19576
[Bug fortran/19194] Missing RECL parameter in OPEN statement
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-22 14:37 --- Subject: Bug 19194 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-22 14:37:39 Modified files: libgfortran: ChangeLog libgfortran/io : io.h gcc/fortran: ChangeLog trans-io.c Log message: gcc/fortran/ PR fortran/19194 * trans-io.c (ADD_STRING): Use gfc_charlen_type_node for string length parameters. (gfc_build_io_library_fndecls): 'rec' and 'recl_in' are not pointer fields. libgfortran/ PR fortran/19194 * io/io.h (st_parameter): Use 'GFC_INTEGER_4' instead of 'int', use CHARACTER macro for definition of string valued paramters. Also fix years in recent ChangeLog entries. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gccr1=1.148r2=1.149 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/io.h.diff?cvsroot=gccr1=1.14r2=1.15 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gccr1=1.304r2=1.305 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-io.c.diff?cvsroot=gccr1=1.26r2=1.27 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19194
[Bug fortran/19194] Missing RECL parameter in OPEN statement
--- Additional Comments From tobi at gcc dot gnu dot org 2005-01-22 14:40 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19194
[Bug target/19549] Register allocation problem in inline asm on x86.
--- Additional Comments From falk at debian dot org 2005-01-22 15:23 --- (In reply to comment #5) Second, both PRs concern a basically overly constrained asm. I am sure I mentioned in PR11203 that any success in compiling such asm is just luck. Not a GCC bug We do in fact completely agree, except for the interpretation of the words invalid and bug. I would have closed it as wontfix instead of invalid. Of course, the effect for the users is exactly the same :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19549
[Bug objc/18408] [4.0 Regression] ICE compiling code that involves casting classes
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-22 15:23 --- With --disable-checking, we get the correct code but we don't get an ICE. -- What|Removed |Added Keywords||ice-checking http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18408
[Bug fortran/19575] cdabs intrinsic incorrectly handled with -std=f95
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-22 15:48 --- sub (specific__abs_c8); sub (specific__abs_c4); Hmm, I don't know what should be happening with intrinsics at all in this case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19575
[Bug inline-asm/11203] source doesn't compile with -O0 but they compile with -O3
--- Additional Comments From stian at nixia dot no 2005-01-22 15:58 --- if you resolve all memory-referenses to temporary variables void *a=(src + 0*stride) and use those instead. Doesn't that lessen the stress the register-allocator is given? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11203
[Bug fortran/19577] New: initial padding for COMMON blocks - order of variables
Hello, short fortran software: === Program TEST_COMMON_BLOCKS implicit real*8 (a-h,o-z) common /common_block/ a,i a=1.25 i=-4 write(*,*) main prog:, i,a call subr stop 0 end subroutine subr implicit real*8 (a-h,o-z) C common /common_block/ a,i ! does compile perfectly C common /common_block2/ i,a ! does compile with warning... common /common_block/ i,a ! does NOT COMPILE - error with padding a=-2.585 i=8 write(*,*) subroutine :, i,a return end == It gives: g77 -fno-globals -Wno-globals -Wall tc.f tc.f: In subroutine `subr': tc.f:4: common /common_block/ a,i 1 tc.f:19: (continued): common /common_block/ i,a ! does NOT COMPILE - error with paddi 2 Initial padding for common block `common_block' is 4 bytes at (2) but 0 bytes at (1) -- consider reordering members, largest-type-size first The g77 is sensitive on the order of variable types. Commercial ifc does compile it well. Miro -- Summary: initial padding for COMMON blocks - order of variables Product: gcc Version: 3.3.3 Status: UNCONFIRMED Severity: minor Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ilias at utcpd dot sk CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: PC linux GCC target triplet: gcc/g77 version 3.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19577
[Bug tree-optimization/19038] [4.0 Regression] tree-ssa causing loops to have more than one BB
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-22 16:48 --- Subject: Bug 19038 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-22 16:48:24 Modified files: gcc: ChangeLog tree-ssa-dom.c Log message: 2005-01-20 Daniel Berlin [EMAIL PROTECTED] Fix PR tree-optimization/19038 * tree-ssa-dom.c (cprop_operand): Don't replace loop invaeriant copies with loop variant ones. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.7228r2=2.7229 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-dom.c.diff?cvsroot=gccr1=2.86r2=2.87 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19038
[Bug tree-optimization/19038] [4.0 Regression] tree-ssa causing loops to have more than one BB
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-01-22 16:49 --- Fixed -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19038
[Bug tree-optimization/18048] [4.0 Regression] mgrid loop performance regression with ivopts
-- Bug 18048 depends on bug 19038, which changed state. Bug 19038 Summary: [4.0 Regression] tree-ssa causing loops to have more than one BB http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19038 What|Old Value |New Value Status|NEW |ASSIGNED Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18048
[Bug inline-asm/11203] source doesn't compile with -O0 but they compile with -O3
--- Additional Comments From michaelni at gmx dot at 2005-01-22 17:10 --- (In reply to comment #14) In any case, just because code is syntactically valid GNU C doesn't mean gcc can always compile it. With this kind of inline asm, you're bound to confuse the register allocator. The fact that it works at O3 is pure luck and not a bug. well, you are the gcc developers so theres not much arguing about what you consider valid, but last time i checked the docs did not mention that asm statemts may fail to compile at random, and IMO as long as this is not clearly stated in the docs this bugreport really shouldnt be marked as invalid, say you dont want to fix it, say it would be too complicated to fix or whatever but its not invalid Note that you're hitting an *error*, not an ICE. no, at least one of the bugreports marked as duplicate of this ends in an ICE (In reply to comment #24) Martin, you should realize that this problem *cannot* be solved. Yes, there will perhaps be a time when this particular test case compiles, though I think that is unlikely. But anyway, then there will be other cases that fail. hmm, so the probelm cannot be solved but then maybe it will be solved but this doesnt count because there will be other unrelated bugs? i cant follow this reasoning or do u mean that u can never solve all bugs and so theres no need to fix any single one? The reason is dead simple: register allocation is NP-complete, so it is even *theoretically* not possible to write register allocators that always find a coloring. register allocation in general is NP-complete, yes, but it seems u forget that this is about finding the optimal solution while gcc fails finding any solution which in practice is a matter of assigning the registers beginning from the most constrained operands to the least, and copying a few things on the stack if gcc cant figure out howto access them, sure this method might fail in 0.001% of the practical cases and need a 2nd or 3rd pass where it tries different registers it might also happen that in some intentionally overconstrained cases it ends up searching the whole 5040 possible assignments of 7 registers onto 7 non memory operands but still it wont fail That means any register allocator will always fail on some very constrained asm input. now that statement is just false, not to mention irrelevant as none of these asm statemets are unreasonably constrained And you cannot allow it to run indefinitely until a coloring is found, because then you've turned the graph coloring problem into the halting problem because you can't prove that a coloring exists and that the register allocator algorithm will terminate. this is ridiculous, the number of possible colorings is finite, u can always try them all in finite time -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11203
Re: [Bug inline-asm/11203] source doesn't compile with -O0 but they compile with -O3
The reason is dead simple: register allocation is NP-complete, so it is even *theoretically* not possible to write register allocators that always find a coloring. register allocation in general is NP-complete, yes, but it seems u forget that this is about finding the optimal solution while gcc fails finding any solution which in practice is a matter of assigning the registers beginning from the most constrained operands to the least, and copying a few things on the stack if gcc cant figure out howto access them, sure this method might fail in 0.001% of the practical cases and need a 2nd or 3rd pass where it tries different registers it might also happen that in some intentionally overconstrained cases it ends up searching the whole 5040 possible assignments of 7 registers onto 7 non memory operands but still it wont fail Just to also point out, it doesn't appear to be NP complete for register interference graphs, because they all seem to be 1-perfect. Various papers have observed this, and i've actually compiled all of gcc, libstdc++, etc, and every package ever on my computer, and not once has a single non-1-perfect interference graph occurred [my compiler would abort if it was true]. On 1-perfect graphs you can solve this problem in O(time it takes to determine the max clique), and there already exists a polynomial time algorithm for max-clique on perfect graphs. That means any register allocator will always fail on some very constrained asm input. now that statement is just false, not to mention irrelevant as none of these asm statemets are unreasonably constrained You are correct, NP completeness does not imply impossiblity. There are only a finite number of possibilities. And you cannot allow it to run indefinitely until a coloring is found, because then you've turned the graph coloring problem into the halting problem because you can't prove that a coloring exists and that the register allocator algorithm will terminate. this is ridiculous, the number of possible colorings is finite, u can always try them all in finite time You are right, he is wrong.
[Bug inline-asm/11203] source doesn't compile with -O0 but they compile with -O3
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-01-22 17:21 --- Subject: Re: source doesn't compile with -O0 but they compile with -O3 The reason is dead simple: register allocation is NP-complete, so it is even *theoretically* not possible to write register allocators that always find a coloring. register allocation in general is NP-complete, yes, but it seems u forget that this is about finding the optimal solution while gcc fails finding any solution which in practice is a matter of assigning the registers beginning from the most constrained operands to the least, and copying a few things on the stack if gcc cant figure out howto access them, sure this method might fail in 0.001% of the practical cases and need a 2nd or 3rd pass where it tries different registers it might also happen that in some intentionally overconstrained cases it ends up searching the whole 5040 possible assignments of 7 registers onto 7 non memory operands but still it wont fail Just to also point out, it doesn't appear to be NP complete for register interference graphs, because they all seem to be 1-perfect. Various papers have observed this, and i've actually compiled all of gcc, libstdc++, etc, and every package ever on my computer, and not once has a single non-1-perfect interference graph occurred [my compiler would abort if it was true]. On 1-perfect graphs you can solve this problem in O(time it takes to determine the max clique), and there already exists a polynomial time algorithm for max-clique on perfect graphs. That means any register allocator will always fail on some very constrained asm input. now that statement is just false, not to mention irrelevant as none of these asm statemets are unreasonably constrained You are correct, NP completeness does not imply impossiblity. There are only a finite number of possibilities. And you cannot allow it to run indefinitely until a coloring is found, because then you've turned the graph coloring problem into the halting problem because you can't prove that a coloring exists and that the register allocator algorithm will terminate. this is ridiculous, the number of possible colorings is finite, u can always try them all in finite time You are right, he is wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11203
[Bug tree-optimization/19484] [4.0 Regression] function pointer propagation fails for noreturn functions
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-22 17:52 --- Subject: Bug 19484 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-22 17:52:44 Modified files: gcc: ChangeLog tree-cfg.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.c-torture/compile: 20050122-1.c 20050122-2.c Log message: PR tree-optimization/19484 * tree-cfg.c (remove_fallthru_edge): New function. (cleanup_control_flow): Remove fallthru edges from calls that are now known not to return. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.7229r2=2.7230 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-cfg.c.diff?cvsroot=gccr1=2.146r2=2.147 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.4922r2=1.4923 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/compile/20050122-1.c.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/compile/20050122-2.c.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19484
[Bug tree-optimization/18048] [4.0 Regression] mgrid loop performance regression with ivopts
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-22 17:54 --- (In reply to comment #8) Actually I think the remaining issues of the mgrid performance regression are caused by PR 19038. Well I looked the assembly and it looks like a regresiter allocator problem now because with -fno- ivopts we don't spill but with it turned we do. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18048
[Bug tree-optimization/19484] [4.0 Regression] function pointer propagation fails for noreturn functions
-- What|Removed |Added OtherBugsDependingO||19578 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19484
[Bug tree-optimization/19578] New: [4.0 Regression] function pointer propagation fails for noreturn functions (part 2)
I'm opening this issue to track the second testcase from PR19484: http://gcc.gnu.org/PR19484 since it needs a different patch from the first (original) testcase. -- Summary: [4.0 Regression] function pointer propagation fails for noreturn functions (part 2) Product: gcc Version: 4.0.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rsandifo at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu BugsThisDependsOn: 19484 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19578
[Bug tree-optimization/19578] [4.0 Regression] function pointer propagation fails for noreturn functions (part 2)
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rsandifo at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-01-22 17:57:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19578
[Bug tree-optimization/19484] [4.0 Regression] function pointer propagation fails for noreturn functions
--- Additional Comments From rsandifo at gcc dot gnu dot org 2005-01-22 17:58 --- Patch committed for the first testcase. Using PR19578 to track the second. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19484
[Bug tree-optimization/19578] [4.0 Regression] function pointer propagation fails for noreturn functions (part 2)
-- Bug 19578 depends on bug 19484, which changed state. Bug 19484 Summary: [4.0 Regression] function pointer propagation fails for noreturn functions http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19484 What|Old Value |New Value Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19578
[Bug tree-optimization/19578] [4.0 Regression] function pointer propagation fails for noreturn functions (part 2)
-- What|Removed |Added Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19578
[Bug tree-optimization/19578] [4.0 Regression] function pointer propagation fails for noreturn functions (part 2)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-22
18:00 ---
Just for the record (and for lazy people aka me), here is the testcase:
extern void foo (void) __attribute__((noreturn));
void g (void)
{
void (*f) (void) = foo;
f ();
f ();
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19578
[Bug fortran/19577] initial padding for COMMON blocks - order of variables
--- Additional Comments From ilias at utcpd dot sk 2005-01-22 18:02 --- Created an attachment (id=8038) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8038action=view) This is NOT bug I returned to this programm, and realized that this is NOT a bug, but this is good restrictive behaviour of the g77 compiler in comparison to the commercial INTEL compiler, ifc. The attached prorgamme can by compiled using ifc, but gives wrong results due to wrong order of variables in the common block of the subroutine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19577
[Bug tree-optimization/8681] Generates unneeded test
--- Additional Comments From kazu at cs dot umass dot edu 2005-01-22 18:14
---
Still not fixed at tree level.
sum (p)
{
unsigned int D.1166;
unsigned int D.1161;
int result;
int i;
bb 0:
result = 0;
i = 0;
goto bb 3 (L10);
L0:;
if (i 0) goto L11; else goto L10;
L11:;
result = 0;
L10:;
D.1161 = (unsigned int) i;
result = result + *(p + (int *) D.1161 * 4B);
D.1166 = D.1161 + 1;
i = (int) D.1166;
if (D.1166 != 1) goto L0; else goto L4;
L4:;
return result;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8681
[Bug fortran/19577] initial padding for COMMON blocks - order of variables
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-22 18:14 --- Just a note with gfortran we get a warning, not a error though. Closing as invalid as requested by the submitter. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19577
[Bug middle-end/18887] [4.0 Regression] libgcc2.h Improperly determines required built-in function size requirements.
--- Additional Comments From schlie at comcast dot net 2005-01-22 18:28 --- Subject: Re: [4.0 Regression] libgcc2.h Improperly determines required built-in function size requirements. Any reason that the milestone was removed vs. moved to 4.1 for tertiary platforms? From: mmitchel at gcc dot gnu dot org [EMAIL PROTECTED] --- Additional Comments From mmitchel at gcc dot gnu dot org 2005-01-21 There are no 8-bit or 16-bit targets in the primary or secondary platform lists; removing target milestone. -- What|Removed |Added Target Milestone|4.0.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18887 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18887
[Bug tree-optimization/19516] missed optimization (bool)
--- Additional Comments From kazu at cs dot umass dot edu 2005-01-22 18:34
---
This is what I get at the end of tree-ssa optimizations.
foo (flag)
{
int D.1318;
_Bool D.1317;
bb 0:
D.1317_2 = *flag_1;
if (D.1317_2 != 0) goto L0; else goto L1;
L0:;
bar ();
L1:;
D.1317_4 = *flag_1;
if (D.1317_4 != 0) goto L2; else goto L3;
L2:;
bar () [tail call];
L3:;
return;
}
Note that the load immediately after L1:; is partially redundant.
I remember Daniel Berlin saying that if PRE is extended to handle
partially redundant load, we can remove the load on one path
to L1 like so:
L0:;
bar ();
D.1317_5 = *flag_1;
D.1317_4 = PHI D.1317_2(...), D.1317_5(...)
L1:;
if (D.1317_4 != 0) goto L2; else goto L3;
At this point, DOM can thread one of the incoming edges to L1.
One problem is that PRE will probably be still disabled under -Os
when it is extended to handle partially redundant loads even though
PRE would improve this particular case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19516
[Bug c++/19569] no code for explicit instantiation of template class specialization
--- Additional Comments From bangerth at dealii dot org 2005-01-22 18:37 --- Why? The function you want is inline. I would rather claim that the instantiation of the function in the general template is wrong, although arguably it doesn't matter since it is marked weak. You will have to explain what kind of problem you have because the function you ask for isn't instantiated? W. -- What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19569
[Bug fortran/19575] cdabs intrinsic incorrectly handled with -std=f95
--- Additional Comments From sgk at troutmask dot apl dot washington dot edu 2005-01-22 19:25 --- Part of the problem is due to the following from intrinsic.c add_sym_1 (zabs, 1, 1, BT_REAL, dd, GFC_STD_GNU, NULL, gfc_simplify_abs, gfc_resolve_abs, a, BT_COMPLEX, dd, REQUIRED); make_alias (cdabs); make_alias() does not set the GFC_STD_GNU flag. If you change cdabs to zabs, you get kargl[216] gfc -o y -std=f95 y.f90 In file y.f90:3 intrinsic zabs 1 Error: Intrinsic at (1) does not exist which is the expected behavior. We still get the NaN if -std=f95 is removed from the command line. NAG's compiler states kargl[224] f95 -o y -dcfuns y.f90 Error: y.f90, line 5: Intrinsic CDABS cannot be an actual argument [f95 error termination] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19575
[Bug target/19528] [4.0 regression] missing ra.h
--- Additional Comments From mark at codesourcery dot com 2005-01-22 19:43 --- Subject: Re: [4.0 regression] missing ra.h joel at gcc dot gnu dot org wrote: --- Additional Comments From joel at gcc dot gnu dot org 2005-01-22 12:57 --- (In reply to comment #10) Mark, while you're using your RM powers to move the target milestone on this one, could you also please use your GWP powers to approve the simple patch http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01258.html that fixes this bug? I can confirm that sh-rtems builds with this patch and won't without it. The resulting compiler will also build RTEMS. No sh target builds without this fix so I am also politely asking this to be committed. The patch should says Returns true rather than Returns 1 in the comment; OK with that change. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19528
[Bug target/19378] [4.0 Regression] ICE during bootstrap compiling __fixdfdi
--- Additional Comments From mark at codesourcery dot com 2005-01-22 19:44 --- Subject: Re: [4.0 Regression] ICE during bootstrap compiling __fixdfdi joel at gcc dot gnu dot org wrote: --- Additional Comments From joel at gcc dot gnu dot org 2005-01-22 13:02 --- (In reply to comment #6) AVR is not a primary or secondary platform; removing target milestone. Understood but there is a patch from Rager Sayle and all it needs is to be reviewed and approved. He posted tests rules and an explanation here: http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00834.html He reports on avr-elf and I can confirm that this lets avr-rtems build. Please approve this patch. The AVR maintainer should review that patch; it's certainly fine to commit if approved by the AVR maintainer. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19378
[Bug libfortran/18982] open(status=new) does not generate an error if the file exists
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-22 19:49 --- Subject: Bug 18982 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-22 19:49:18 Modified files: gcc/testsuite : ChangeLog libgfortran: ChangeLog libgfortran/io : unix.c Added files: gcc/testsuite/gfortran.dg: open_new.f90 Log message: 2005-01-22 Thomas Koenig [EMAIL PROTECTED] PR libfortran/18982 * io/unix.c (regular_file): No need to change flags-action if an error occurs. Document this. No need to call stat() for STATUS_OLD, open() will fail anyway. For ACTION_UNSPECIFIED, try open for read-write, then for read-only if open fails with EACCES, then for write-only if that fails with EACCES again. * io/unix.c (open_external): Document changed behavior of regular_file. testsuite/ * gfortran.dg/open_new.f90: New file. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.4924r2=1.4925 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/open_new.f90.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gccr1=1.149r2=1.150 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/unix.c.diff?cvsroot=gccr1=1.19r2=1.20 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18982
[Bug fortran/19575] cdabs intrinsic incorrectly handled with -std=f95
--- Additional Comments From sgk at troutmask dot apl dot washington dot edu 2005-01-22 20:00 --- Patch to fix the nonstandard issue with -std=f95. http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01596.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19575
[Bug target/19378] [4.0 Regression] ICE during bootstrap compiling __fixdfdi
-- What|Removed |Added CC||denisc at overta dot ru AssignedTo|unassigned at gcc dot gnu |denisc at overta dot ru |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19378
[Bug target/19378] [4.0 Regression] ICE during bootstrap compiling __fixdfdi
--- Additional Comments From joel at gcc dot gnu dot org 2005-01-22 21:28 --- I just assigned it to one AVR maintainer and cc'ed the other. Could one of you review this patch and commit it per Mark's request. -- What|Removed |Added CC||marekm at amelek dot gda dot ||pl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19378
[Bug tree-optimization/18048] [4.0 Regression] mgrid loop performance regression with ivopts
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-22 21:37 --- If I have a smaller testcase but the loop is still looks like what is in mgrid can I paste it here, it is only 30 lines? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18048
[Bug fortran/19292] [meta-bug] g77 features lacking in gfortran
-- Bug 19292 depends on bug 18982, which changed state. Bug 18982 Summary: open(status=new) does not generate an error if the file exists http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18982 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19292
[Bug fortran/19575] cdabs intrinsic incorrectly handled with -std=f95
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-22 22:38 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||accepts-invalid Last reconfirmed|-00-00 00:00:00 |2005-01-22 22:38:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19575
[Bug libstdc++/19343] [4.0 Regression] New warnings in libstdc++-v3 since 2004-01-05
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-22 22:47 --- *** Bug 19573 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||hp at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19343
[Bug libstdc++/19573] [4.0 regression] g++.old-deja/g++.robertl/eb132.C, eb73.C failures
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-22
22:47 ---
Turns out this is correct warning and this is a dup of bug 19343 which has a
way to fix it.
pointer
allocate(size_type __n, const void* = 0)
{
if (__builtin_expect(__n this-max_size(), false))
std::__throw_bad_alloc(); -- this function does not have noreturn
on it.
return static_cast_Tp*(::operator new(__n * sizeof(_Tp)));
}
*** This bug has been marked as a duplicate of 19343 ***
--
What|Removed |Added
Status|NEW |RESOLVED
Component|c++ |libstdc++
Resolution||DUPLICATE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19573
[Bug libstdc++/19343] [4.0 Regression] New warnings in libstdc++-v3 since 2004-01-05
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19343
[Bug target/19506] [4.0 Regression] PovRay produces wrong pictures with -mfpmath=sse -ffast-math.
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-22 23:08 --- Subject: Bug 19506 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-22 23:07:57 Modified files: gcc: ChangeLog gcc/config/i386: i386.c i386.md Log message: PR target/19506 * config/i386/i386.md (movsfcc_1_sse_max): Use nonimmediate_operand in both compare operands. (movdfcc_1_sse_max): Likewise. (movsfcc_1_sse): Likewise. Add earlyclobber for scratch. (movdfcc_1_sse): Likewise. * config/i386/i386.c (ix86_split_sse_movcc): Emit copies into the scratch register as needed. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.7238r2=2.7239 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386.c.diff?cvsroot=gccr1=1.788r2=1.789 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386.md.diff?cvsroot=gccr1=1.609r2=1.610 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19506
[Bug libstdc++/19343] [4.0 Regression] New warnings in libstdc++-v3 since 2004-01-05
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-22
23:09 ---
I was about to send the following patch out for this.
Index: include/bits/functexcept.h
===
RCS file: /cvs/gcc/gcc/libstdc++-v3/include/bits/functexcept.h,v
retrieving revision 1.5
diff -u -p -r1.5 functexcept.h
--- include/bits/functexcept.h 24 Nov 2004 04:11:09 - 1.5
+++ include/bits/functexcept.h 22 Jan 2005 22:54:50 -
@@ -44,50 +44,50 @@ namespace std
{
// Helper for exception objects in except
void
- __throw_bad_exception(void);
+ __throw_bad_exception(void) __attribute__((noreturn));
// Helper for exception objects in new
void
- __throw_bad_alloc(void);
+ __throw_bad_alloc(void) __attribute__((noreturn));
// Helper for exception objects in typeinfo
void
- __throw_bad_cast(void);
+ __throw_bad_cast(void) __attribute__((noreturn));
void
- __throw_bad_typeid(void);
+ __throw_bad_typeid(void) __attribute__((noreturn));
// Helpers for exception objects in stdexcept
void
- __throw_logic_error(const char* __s);
+ __throw_logic_error(const char* __s) __attribute__((noreturn));
void
- __throw_domain_error(const char* __s);
+ __throw_domain_error(const char* __s) __attribute__((noreturn));
void
- __throw_invalid_argument(const char* __s);
+ __throw_invalid_argument(const char* __s) __attribute__((noreturn));
void
- __throw_length_error(const char* __s);
+ __throw_length_error(const char* __s) __attribute__((noreturn));
void
- __throw_out_of_range(const char* __s);
+ __throw_out_of_range(const char* __s) __attribute__((noreturn));
void
- __throw_runtime_error(const char* __s);
+ __throw_runtime_error(const char* __s) __attribute__((noreturn));
void
- __throw_range_error(const char* __s);
+ __throw_range_error(const char* __s) __attribute__((noreturn));
void
- __throw_overflow_error(const char* __s);
+ __throw_overflow_error(const char* __s) __attribute__((noreturn));
void
- __throw_underflow_error(const char* __s);
+ __throw_underflow_error(const char* __s) __attribute__((noreturn));
// Helpers for exception objects in basic_ios
void
- __throw_ios_failure(const char* __s);
+ __throw_ios_failure(const char* __s) __attribute__((noreturn));
} // namespace std
#endif
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19343
[Bug libstdc++/19343] [4.0 Regression] New warnings in libstdc++-v3 since 2004-01-05
--- Additional Comments From pcarlini at suse dot de 2005-01-22 23:16 --- I was about to send the following patch out for this. Thanks Andrew, I have already implemented and tested AJ original suggestion, will wait a bit for the list opinion. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19343
[Bug target/19506] [4.0 Regression] PovRay produces wrong pictures with -mfpmath=sse -ffast-math.
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-22 23:23 --- (In reply to comment #10) Should patch to sse_comparison_operator [...] be reverted in this case? Nah. As I said in that message, allowing these operators in this manner doesn't actually give the register allocator any more freedom, and therefore doesn't do what was hoped. See e.g. alpha's movsicc_internal for an example of how the comparisons would have to be reworked in order to give that freedom. Anyway, fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19506
[Bug target/19378] [4.0 Regression] ICE during bootstrap compiling __fixdfdi
--- Additional Comments From marekm at amelek dot gda dot pl 2005-01-23 00:14 --- I think the proposed avr_hard_regno_mode_ok patch may need a small fix for QImode in r29 - possible problem with frame pointer (see removed comment): - if (regno = REG_Y (regno + GET_MODE_SIZE (mode)) = (REG_Y + 1)) + if (regno = (REG_Y + 1) regno + GET_MODE_SIZE (mode) REG_Y) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19378
[Bug libfortran/19052] unit 0 not preconnected to standard error
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-23 00:15 --- Subject: Bug 19052 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-23 00:14:32 Modified files: libgfortran: ChangeLog libgfortran.h libgfortran/io : io.h open.c unit.c unix.c libgfortran/runtime: environ.c Log message: PR libgfortran/19052 * libgfortran.h (options_t): Add stderr_unit. * io/io.h (error_stream): Declare. * io/open.c (new_unit): Do not terminate abnormally if opening file preconnected to stdin, stdout, or stderr. * io/unit.c (init_units): Initialize stderr_unit. * io/unix.c (error_stream): New function. * runtime/environ.c (GFORTRAN_STDERR_UNIT): New environment variable. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gccr1=1.150r2=1.151 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/libgfortran.h.diff?cvsroot=gccr1=1.21r2=1.22 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/io.h.diff?cvsroot=gccr1=1.15r2=1.16 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/open.c.diff?cvsroot=gccr1=1.9r2=1.10 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/unit.c.diff?cvsroot=gccr1=1.7r2=1.8 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/unix.c.diff?cvsroot=gccr1=1.20r2=1.21 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/runtime/environ.c.diff?cvsroot=gccr1=1.6r2=1.7 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19052
[Bug libfortran/19052] unit 0 not preconnected to standard error
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dje at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2004-12-17 12:40:46 |2005-01-23 00:24:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19052
[Bug tree-optimization/18048] [4.0 Regression] mgrid loop performance regression with ivopts
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-23 00:24 --- The mgrid score on AMD64 jumps 30% with my patch for PR19464 applied. -- What|Removed |Added CC||mark at codesourcery dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18048
[Bug libfortran/19052] unit 0 not preconnected to standard error
--- Additional Comments From dje at gcc dot gnu dot org 2005-01-23 00:24 --- Patch committed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19052
[Bug fortran/19292] [meta-bug] g77 features lacking in gfortran
-- Bug 19292 depends on bug 19052, which changed state. Bug 19052 Summary: unit 0 not preconnected to standard error http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19052 What|Old Value |New Value Status|NEW |ASSIGNED Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19292
[Bug target/19378] [4.0 Regression] ICE during bootstrap compiling __fixdfdi
--- Additional Comments From schlie at comcast dot net 2005-01-23 00:25 --- (In reply to comment #10) have you had a chance to look at Roger's more recient patch: http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01181.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19378
[Bug c/19579] New: -march=i686 generates a bogus program
The following program:
/*--8---*/
int printf(const char *, ...);
int f(void)
{
return 0;
}
void g(int a[])
{
int n3, n0;
int even;
int diff = a[1] - a[0];
n3 = 3;
if ((n0 = f()) 0) {
even = diff + 2 * (n3 - n0);
} else {
even = diff + 2 * n3 + 1;
if (even 0) even++;
else if (even 0) even--;
}
if (even % 2 == 0) {
printf(OK! even = %d\n, even);
} else {
printf(WRONG! even = %d\n, even);
}
}
int main(void)
{
int a[2] = {46, 16};
g(a);
return 0;
}
/*--8---*/
when compiled with:
$ gcc-3.4.3 bug.c -o bug -O2 -march=i686
displays when executed:
WRONG! even = -23
whereas when compiled with:
$ gcc-3.4.3 bug.c -o bug -O2
gives the expected output:
OK! even = -24
The bug is also exhibited when some others -march options are used, like
-march=athlon-xp.
gcc-3.4.3 -v output is:
Reading specs from
/home/richard/programs/gcc-3.4.3/lib/gcc/i686-pc-linux-gnu/3.4.3/specs
Configured with: /home/richard/tmp/gcc/gcc-3.4.3/configure
--prefix=/home/richard/programs/gcc-3.4.3 --program-suffix=-3.4.3
--enable-threads=posix --enable-languages=c,c++
Thread model: posix
gcc version 3.4.3
bug.i:
# 1 bug.c
# 1 built-in
# 1 command line
# 1 bug.c
int printf(const char *, ...);
int f(void)
{
return 0;
}
void g(int a[])
{
int n3, n0;
int even;
int diff = a[1] - a[0];
n3 = 3;
if ((n0 = f()) 0) {
even = diff + 2 * (n3 - n0);
} else {
even = diff + 2 * n3 + 1;
if (even 0) even++;
else if (even 0) even--;
}
if (even % 2 == 0) {
printf(OK! even = %d\n, even);
} else {
printf(WRONG! even = %d\n, even);
}
}
int main(void)
{
int a[2] = {46, 16};
g(a);
return 0;
}
--
Summary: -march=i686 generates a bogus program
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: abulmo at club-internet dot fr
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: gcc-3.4.3/gentoo-linux/athlon-xp 2500+
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19579
[Bug target/19579] -march=i686 generates a bogus program
-- What|Removed |Added Component|c |target Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19579
[Bug rtl-optimization/19464] [3.3/3.4/4.0 Regression] gcse causes poor register allocation
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru
2005-01-23 00:42 ---
(In reply to comment #4)
This can be fixed at the tree level without any gcse or ra hacking:
http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01462.html
GCC generates poor code for this function even with that patch applied:
int r[6];
void g (int n)
{
while (-- n)
{
r [0] += r [5];
r [1] += r [0];
r [2] += r [1];
r [3] += r [2];
r [4] += r [3];
r [5] += r [4];
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19464
[Bug rtl-optimization/19464] [3.3/3.4/4.0 Regression] gcse causes poor register allocation
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-23 01:17 --- (In reply to comment #6) (In reply to comment #4) This can be fixed at the tree level without any gcse or ra hacking: http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01462.html GCC generates poor code for this function even with that patch applied: This looks like a different bug because with 3.3.3 we get the good code but not with 3.4.0. Good code meaning: .L5: addl%edi, %ebp addl%ebp, %esi addl%esi, %ecx addl%ecx, %edx addl%edx, %eax addl%eax, %edi decl%ebx jne .L5 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19464
[Bug rtl-optimization/19580] New: [3.4/4.0 Regression] poor register allocation
--
int r[6];
void f (int n)
{
while (-- n)
{
r [0] += r [5];
r [1] += r [0];
r [2] += r [1];
r [3] += r [2];
r [4] += r [3];
r [5] += r [4];
}
}
--
On i386 with -O2 -fomit-frame-pointer we get:
.L4:
movl20(%esp), %ebp
movl8(%esp), %eax
movl16(%esp), %ebx
incl24(%esp)
addl%edi, %ebp
leal(%ebp,%eax), %esi
movl12(%esp), %eax
movl%ebp, 20(%esp)
leal(%esi,%ebx), %ecx
movl4(%esp), %ebx
movl%esi, 8(%esp)
leal(%ecx,%eax), %edx
movl%ecx, 16(%esp)
leal(%edx,%ebx), %eax
movl24(%esp), %ebx
cmpl%ebx, 28(%esp)
movl%edx, 12(%esp)
leal(%eax,%edi), %edi
movl%eax, 4(%esp)
movl%edi, (%esp)
jne .L4
workaround: -fno-gcse
--
Summary: [3.4/4.0 Regression] poor register allocation
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: missed-optimization, ra
Severity: normal
Priority: P2
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: belyshev at depni dot sinp dot msu dot ru
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19580
[Bug rtl-optimization/19580] [3.4/4.0 Regression] poor register allocation
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-23 01:36 --- Confirmed, only a regression from 3.3.3 which gave the following good code: .L5: addl%edi, %ebp addl%ebp, %esi addl%esi, %ecx addl%ecx, %edx addl%edx, %eax addl%eax, %edi decl%ebx jne .L5 -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Known to fail||3.4.0 4.0.0 Known to work||3.3.3 Last reconfirmed|-00-00 00:00:00 |2005-01-23 01:36:57 date|| Target Milestone|--- |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19580
[Bug tree-optimization/19581] New: Missed store monition on the tree level (on PPC in general)
This is like PR 19580 but a request to optimize it on the tree level instead of
just on the RTL level.
Mainly because we don't catch it for PPC (with 3.3.3 or with -fno-gcse).
int r[6];
void f (int n)
{
while (-- n)
{
r [0] += r [5];
r [1] += r [0];
r [2] += r [1];
r [3] += r [2];
r [4] += r [3];
r [5] += r [4];
}
}
We should be able to pull out the load and stores for r[0] ... r[5].
If we do it on the tree level, we also just fix the problem for 4.0 also (but I
think this might need more
aliasing analysis or I could be wrong).
--
Summary: Missed store monition on the tree level (on PPC in
general)
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: missed-optimization, alias, TREE
Severity: enhancement
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19581
[Bug rtl-optimization/19464] [3.3/3.4/4.0 Regression] gcse causes poor register allocation
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru 2005-01-23 01:43 --- (In reply to comment #7) This looks like a different bug because with 3.3.3 we get the good code but not with 3.4.0. this is now bug 19580 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19464
[Bug tree-optimization/19581] Missed store monition on the tree level (on PPC in general)
-- What|Removed |Added OtherBugsDependingO||19580 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19581
[Bug tree-optimization/19581] Missed store monition on the tree level (on PPC in general)
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-01-23 01:47 --- This needs more alias analysis Structure aliasing could do this with a little work, so i'll take this for now -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dberlin at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-01-23 01:47:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19581
[Bug middle-end/19580] [3.4/4.0 Regression] poor register allocation
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-23 01:49 --- This is a tree-optimization bug for 4.0 and later. I think the problem is that we don't catch the store motion opportunity at the tree level because to the tree alias analyses arrays are opaque objects. On RTL we can distinguish the array members. If this is the problem, then Dan's sa-branch work should fix it... Dan? -- What|Removed |Added CC||dberlin at gcc dot gnu dot ||org Component|rtl-optimization|middle-end Keywords|ra |alias http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19580
[Bug libstdc++/19343] [4.0 Regression] New warnings in libstdc++-v3 since 2004-01-05
--- Additional Comments From hp at gcc dot gnu dot org 2005-01-23 01:52 --- I think you need to spell it __noreturn__, as a user should be free to #define noreturn in the program, before the include. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19343
[Bug rtl-optimization/19580] [3.4/4.0 Regression] missed load/store monition
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-23 01:53 --- (In reply to comment #2) This is a tree-optimization bug for 4.0 and later. I think the problem is that we don't catch the store motion opportunity at the tree level because to the tree alias analyses arrays are opaque objects. On RTL we can distinguish the array members. Then why don't we optimize in 3.4.0 while we did in 3.3.3. If this is the problem, then Dan's sa-branch work should fix it... Dan? I already filed PR 19581 for that because on PPC even in 3.3.3 we don't get optimial code. But someone should look into what happened to changed the behavor in 3.4.0. I am willing to bet it was the rewritten of the load/store monition. -- What|Removed |Added Component|middle-end |rtl-optimization Summary|[3.4/4.0 Regression] poor |[3.4/4.0 Regression] missed |register allocation |load/store monition http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19580
[Bug libstdc++/19343] [4.0 Regression] New warnings in libstdc++-v3 since 2004-01-05
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-23 01:56 --- (In reply to comment #8) I was about to send the following patch out for this. Thanks Andrew, I have already implemented and tested AJ original suggestion, will wait a bit for the list opinion. Actually this patch was the same patch as what you did :). Anyways makes sure that you take Hans- Peter's advice because it is correct (there was at least one bug report about this before but I had forgot about when writting the patch). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19343
[Bug rtl-optimization/19580] [3.4/4.0 Regression] missed load/store monition
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-01-23 02:08 --- Subject: Re: [3.4/4.0 Regression] poor register allocation On Sat, 23 Jan 2005, steven at gcc dot gnu dot org wrote: --- Additional Comments From steven at gcc dot gnu dot org 2005-01-23 01:49 --- This is a tree-optimization bug for 4.0 and later. I think the problem is that we don't catch the store motion opportunity at the tree level because to the tree alias analyses arrays are opaque objects. On RTL we can distinguish the array members. If this is the problem, then Dan's sa-branch work should fix it... Dan? It will once i handle constant index array refs (It currently punts on array refs entirely). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19580
[Bug libfortran/19451] Read after a write with a read only file
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-23 02:20 --- Subject: Bug 19451 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-23 02:18:34 Modified files: gcc/testsuite : ChangeLog libgfortran: ChangeLog libgfortran/io : transfer.c Added files: gcc/testsuite/gfortran.dg: open_readonly_1.f90 Log message: 2005-01-22 Thomas Koenig [EMAIL PROTECTED] PR libfortran/19451 * io/transfer.c (finalize_transfer): Don't do anything if there is an error condition. * open_readonly_1.f90: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.4925r2=1.4926 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/open_readonly_1.f90.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gccr1=1.151r2=1.152 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/transfer.c.diff?cvsroot=gccr1=1.28r2=1.29 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19451
[Bug c/19582] New: strtok and strtok_r do not work without -fwritable-strings
$ cat test.c
#include string.h
#include stdio.h
int main(void) {
char *tmp;
const char * const delim= ;
tmp=strtok(a b c, delim);
printf(%s\n,tmp);
return 0;
}
$ gcc -Wall test.c
$ ./a.out
Segmentation fault (core dumped)
$ gcc -Wall -fwritable-strings test.c
cc1: note: -fwritable-strings is deprecated; see documentation for details
$ ./a.out
a
$
--
Summary: strtok and strtok_r do not work without -fwritable-
strings
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: roger at systemroot dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19582
[Bug c/19582] strtok and strtok_r do not work without -fwritable-strings
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-23
03:00 ---
This is invalid, see the prototype for strtok{,_r}:
strtok_r(char *str, const char *sep, char **last);
And from the man page (from *BSD, well from darwin):
The strtok() function is used to isolate sequential tokens in a null-ter-
minated string, str.
So you need a writable string.
--
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19582
[Bug libstdc++/8670] Alignment problem in std::basic_string
--- Additional Comments From ncm-nospam at cantrip dot org 2005-01-23 03:52 --- Somebody mentioned that using unions for type punning was described in the textbooks as extremely bad form. That's how I always thought of it, too, but it seems, at least in Gcc, unions are now the right way to do type punning, instead of casting. For reference, see the notes under -fstrict-aliasing (which is turned on by -O2) in http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/Optimize-Options.html (Thanks to Robert Love for having pointed this out to me.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8670
[Bug rtl-optimization/19580] [3.4/4.0 Regression] missed load/store monition
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru 2005-01-23 04:34 --- Caused by this patch: 2003-04-01 Zdenek Dvorak [EMAIL PROTECTED] * gcse.c (struct ls_expr): Added pattern_regs field. (ldst_entry): Initialize it. (extract_mentioned_regs, extract_mentioned_regs_helper): New. (store_ops_ok): Use regs precomputed by them. (find_loads, store_killed_in_insn, load_kills_store): Change return type to bool. (store_killed_before, store_killed_after): Take position of register set in account. (reg_set_info): Store position of the setter. (gcse_main): Enable store motion. (mems_conflict_for_gcse_p): Enable load motion of non-symbol mems. (pre_insert_copy_insn, update_ld_motion_stores, insert_store): Prevent rtl sharing. (simple_mem): Enable store motion of non-symbol mems. (regvec): Type changed. (LAST_AVAIL_CHECK_FAILURE): New. (compute_store_table_current_insn): New. (build_store_vectors): Computation of availability and anticipatability moved ... (compute_store_table, find_moveable_store): ... here. (delete_store): Remove senseless comment. (store_motion): Reorganize. -- What|Removed |Added Keywords||ra http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19580
[Bug rtl-optimization/19580] [3.4/4.0 Regression] missed load/store motion
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-23 04:38 --- (In reply to comment #5) Caused by this patch: And I was right this was caused by the store motion rewrite. http://gcc.gnu.org/ml/gcc-patches/2003-02/msg02090.html -- What|Removed |Added Keywords|ra | Summary|[3.4/4.0 Regression] missed |[3.4/4.0 Regression] missed |load/store monition |load/store motion http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19580
[Bug rtl-optimization/19580] [3.4/4.0 Regression] missed load/store motion
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-23 04:39 --- Note this is not a register allocator problem any more but a missed optimization. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19580
[Bug target/19378] [4.0 Regression] ICE during bootstrap compiling __fixdfdi
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-23 04:51 --- Subject: Bug 19378 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-23 04:51:29 Modified files: gcc: ChangeLog gcc/config/avr : avr.c Log message: PR middle-end/19378 * config/avr/avr.c (avr_hard_regno_mode_ok): Rewrite. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.7239r2=2.7240 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/avr/avr.c.diff?cvsroot=gccr1=1.125r2=1.126 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19378
[Bug c++/19583] New: Incorrect diagnostic: control may reach end of non-void function '...' being inlined
$ /scratch/zack/i/gcc-vanilla/bin/g++ -v Using built-in specs. Configured with: /home/zack/src/gcc/HEAD/vanilla/configure --prefix=/scratch/zack/i/gcc-vanilla --disable-checking --enable-languages=c,c++ --disable-multilib Thread model: posix gcc version 4.0.0 20050122 (experimental) $ /scratch/zack/i/gcc-vanilla/bin/g++ -S -O2 -W -Wall testcase.cc testcase.cc: In function void finalize(): testcase.cc:29: warning: control may reach end of non-void function bool N::operator!=(N) const being inlined I will attach the testcase. -- Summary: Incorrect diagnostic: control may reach end of non-void function '...' being inlined Product: gcc Version: 4.0.0 Status: UNCONFIRMED Keywords: diagnostic Severity: minor Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zack at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19583
[Bug c++/19583] Incorrect diagnostic: control may reach end of non-void function '...' being inlined
--- Additional Comments From zack at gcc dot gnu dot org 2005-01-23 05:08 --- Created an attachment (id=8039) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8039action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19583
[Bug c++/19583] Incorrect diagnostic: control may reach end of non-void function '...' being inlined
--- Additional Comments From zack at gcc dot gnu dot org 2005-01-23 05:11 --- Created an attachment (id=8040) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8040action=view) shorter test case -- What|Removed |Added Attachment #8039 is|0 |1 obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19583
[Bug target/18402] [3.3 regression] ICE in gen_split_1204 on i686-pc-linux-gnu target
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-23 05:16 --- Subject: Bug 18402 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_3-branch Changes by: [EMAIL PROTECTED] 2005-01-23 05:16:15 Modified files: gcc: ChangeLog gcc/config/i386: i386.md gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg: 20030204-1.c Log message: PR target/18402 Backport from mainline 2003-02-05 Jakub Jelinek [EMAIL PROTECTED] PR optimization/8555 * config/i386/i386.md (sse_mov?fcc split): Handle op2 == op3 case instead of aborting. * gcc.dg/20030204-1.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_3-branchr1=1.16114.2.1055r2=1.16114.2.1056 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386.md.diff?cvsroot=gcconly_with_tag=gcc-3_3-branchr1=1.404.2.28r2=1.404.2.29 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_3-branchr1=1.2261.2.397r2=1.2261.2.398 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/20030204-1.c.diff?cvsroot=gcconly_with_tag=gcc-3_3-branchr1=NONEr2=1.3.6.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18402
[Bug rtl-optimization/8555] [3.2 regression] ICE in gen_split_1231
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-23 05:16 --- Subject: Bug 8555 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_3-branch Changes by: [EMAIL PROTECTED] 2005-01-23 05:16:15 Modified files: gcc: ChangeLog gcc/config/i386: i386.md gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg: 20030204-1.c Log message: PR target/18402 Backport from mainline 2003-02-05 Jakub Jelinek [EMAIL PROTECTED] PR optimization/8555 * config/i386/i386.md (sse_mov?fcc split): Handle op2 == op3 case instead of aborting. * gcc.dg/20030204-1.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_3-branchr1=1.16114.2.1055r2=1.16114.2.1056 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386.md.diff?cvsroot=gcconly_with_tag=gcc-3_3-branchr1=1.404.2.28r2=1.404.2.29 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_3-branchr1=1.2261.2.397r2=1.2261.2.398 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/20030204-1.c.diff?cvsroot=gcconly_with_tag=gcc-3_3-branchr1=NONEr2=1.3.6.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8555
[Bug c++/19583] [4.0 Regression] Incorrect diagnostic: control may reach end of non-void function '...' being inlined
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-23
05:21 ---
Here is the simplified testcase:
static inline bool f() throw()
{
return 0;
}
bool ff()
{
return f();
}
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |2005-01-23 05:21:08
date||
Summary|Incorrect diagnostic: |[4.0 Regression] Incorrect
|control may reach end of|diagnostic: control may
|non-void function '...' |reach end of non-void
|being inlined |function '...' being inlined
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19583
[Bug c++/19583] [4.0 Regression] Incorrect diagnostic: control may reach end of non-void function '...' being inlined
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-23 05:22 --- I think the problem is that we don't look passed eh_spec_block trees. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19583
[Bug target/18402] [3.3 regression] ICE in gen_split_1204 on i686-pc-linux-gnu target
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-23 05:28 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18402
