[Bug c/29511] New: 0x80000000/-1 causes FPE on Intel/AMD
The division of 0x8000 by -1 gives FPE on both Intel and AMD Processors...
I have checked that with the following simple program on both Fedora core 3's
GCC 3.4.4 and debian sarge's gcc-3.3.5...
I also had someone check it with gcc 4.1.2 and FreeBSD too...
int divide(int a,int b)
{
return a/b;
}
int main(void)
{
return divide(0x8000,-1);
}
and what I get is:
./test
Floating point exception
And GDB says "Program received signal SIGFPE, Arithmetic exception."
--
Summary: 0x8000/-1 causes FPE on Intel/AMD
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Eric dot Deplagne at nerim dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29511
[Bug c/29511] 0x80000000/-1 causes FPE on Intel/AMD
--- Comment #1 from schwab at suse dot de 2006-10-19 08:39 --- That's not a bug, the result of -2147483648/-1 is overflowing the range of int, thus invokes undefined behaviour. -- schwab at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29511
[Bug c/29511] 0x80000000/-1 causes FPE on Intel/AMD
--- Comment #2 from Eric dot Deplagne at nerim dot net 2006-10-19 08:58 --- Should I assume that 40+40 can FPE my ass too, then ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29511
[Bug other/29512] New: compile time hog / deadloop.
[4.1] mem usage: ~120MB, compile time: +inf? (canceled after 980 minutes). [4.2] mem usage: ~90MB, compile time: +inf? (similiar). -- Summary: compile time hog / deadloop. Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pluto at agmk dot net GCC target triplet: x86_64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29512
[Bug other/29512] compile time hog / deadloop.
--- Comment #1 from pluto at agmk dot net 2006-10-19 09:00 --- Created an attachment (id=12458) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12458&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29512
[Bug fortran/29489] LBOUND (array) and LBOUND (array, DIM) give different results.
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2006-10-19 09:07 --- So that it doesn't get lost, here's another UBOUND problem: $ cat a.f90 subroutine foo (x,n) integer x(7,n,2,*) print *, ubound(x,1) print *, ubound(x,2) print *, ubound(x,3) ! print *, ubound(x,4) ! print *, ubound(x) end integer i(7,4,2,9) call foo(i,4) end $ ifort a.f90 && ./a.out 7 4 2 $ gfortran a.f90 && ./a.out In file a.f90:5 print *, ubound(x,2) 1 Error: The upper bound in the last dimension must appear in the reference to the assumed size array 'x' at (1). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29489
[Bug other/29512] compile time hog / deadloop.
--- Comment #2 from pluto at agmk dot net 2006-10-19 09:35 --- 4.1 backtrace: #0 0x005a65ad in mul_double () #1 0x005a70e2 in int_const_binop () #2 0x005b0796 in size_binop () #3 0x00717d9a in bit_from_pos () #4 0x00725157 in bit_position () #5 0x00725165 in int_bit_position () #6 0x0075474e in classify_argument () #7 0x00754785 in classify_argument () #8 0x00754785 in classify_argument () #9 0x00754785 in classify_argument () #10 0x00754785 in classify_argument () #11 0x0075463b in classify_argument () #12 0x00754785 in classify_argument () #13 0x00754785 in classify_argument () #14 0x00754785 in classify_argument () #15 0x00754785 in classify_argument () #16 0x00754785 in classify_argument () #17 0x0075463b in classify_argument () #18 0x00754785 in classify_argument () #19 0x0075463b in classify_argument () #20 0x00754785 in classify_argument () #21 0x00754785 in classify_argument () #22 0x00754785 in classify_argument () #23 0x00754785 in classify_argument () #24 0x00754785 in classify_argument () #25 0x0075463b in classify_argument () #26 0x00754785 in classify_argument () #27 0x0075463b in classify_argument () #28 0x00754785 in classify_argument () #29 0x0075463b in classify_argument () #30 0x00754785 in classify_argument () #31 0x0075463b in classify_argument () #32 0x00754785 in classify_argument () #33 0x0075463b in classify_argument () #34 0x00754785 in classify_argument () #35 0x00754785 in classify_argument () #36 0x00754785 in classify_argument () #37 0x00754785 in classify_argument () #38 0x00754785 in classify_argument () #39 0x0075463b in classify_argument () #40 0x00754785 in classify_argument () #41 0x00754785 in classify_argument () #42 0x00754c72 in examine_argument () #43 0x00755627 in construct_container () #44 0x0075621c in ix86_function_value () #45 0x0057d938 in hard_function_value () #46 0x005bb8aa in aggregate_value_p () #47 0x004c130e in gimplify_modify_expr_rhs () #48 0x004c1550 in gimplify_modify_expr () #49 0x004c1dd5 in gimplify_expr () #50 0x004c3fcf in gimplify_target_expr () #51 0x004c2a55 in gimplify_expr () #52 0x004c1f19 in gimplify_expr () #53 0x004c4719 in gimplify_arg () #54 0x004c48af in gimplify_call_expr () #55 0x004c1d51 in gimplify_expr () #56 0x004c331d in gimplify_stmt () #57 0x004c3655 in gimplify_to_stmt_list () #58 0x004c2947 in gimplify_expr () #59 0x004c331d in gimplify_stmt () #60 0x004c2b02 in gimplify_expr () #61 0x004c331d in gimplify_stmt () #62 0x004c3655 in gimplify_to_stmt_list () #63 0x004c28e9 in gimplify_expr () #64 0x004c331d in gimplify_stmt () #65 0x004c2b02 in gimplify_expr () #66 0x004c331d in gimplify_stmt () #67 0x004c3655 in gimplify_to_stmt_list () #68 0x004c28e9 in gimplify_expr () #69 0x004c331d in gimplify_stmt () #70 0x004c2b02 in gimplify_expr () #71 0x004c331d in gimplify_stmt () #72 0x004c3655 in gimplify_to_stmt_list () #73 0x004c28e9 in gimplify_expr () #74 0x004c331d in gimplify_stmt () #75 0x004c2b02 in gimplify_expr () #76 0x004c331d in gimplify_stmt () #77 0x004c3655 in gimplify_to_stmt_list () #78 0x004c28e9 in gimplify_expr () #79 0x004c331d in gimplify_stmt () #80 0x004c2b02 in gimplify_expr () #81 0x004c331d in gimplify_stmt () #82 0x004c3655 in gimplify_to_stmt_list () #83 0x004c28e9 in gimplify_expr () #84 0x004c331d in gimplify_stmt () #85 0x004c2b02 in gimplify_expr () #86 0x004c331d in gimplify_stmt () #87 0x004c3655 in gimplify_to_stmt_list () #88 0x004c28e9 in gimplify_expr () #89 0x004c331d in gimplify_stmt () #90 0x004c2b02 in gimplify_expr () #91 0x004c331d in gimplify_stmt () #92 0x004c3655 in gimplify_to_stmt_list () #93 0x004c28e9 in gimplify_expr () #94 0x004c331d in gimplify_stmt () #95 0x004c2b02 in gimplify_expr () #96 0x004c331d in gimplify_stmt () #97 0x004c3655 in gimplify_to_stmt_list () #98 0x004c28e9 in gimplify_expr () #99 0x004c331d in gimplify_stmt () #100 0x004c2b02 in gimplify_expr () #101 0x004c331d in gimplify_stmt () #102 0x004c3655 in gimplify_to_stmt_list () #103 0x004c28e9 in gimplify_expr () #104 0x004c331d in gimplify_stmt () #105 0x004c2b02 in gimplify_expr () #106 0x004c331d in gimplify_stmt () #107 0x004c3655 in
[Bug c++/29514] New: A member variable named 'not' is intrepreted by the compiler as the '!' sign.
Look at the source file first, its very short. $ g++ -c -save-temps main.cpp main.cpp:4: error: expected unqualified-id before ! token $ g++ --version g++ (GCC) 4.0.2 20051125 (Red Hat 4.0.2-8) Copyright (C) 2005 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. $ cat /proc/version Linux version 2.6.17-1.2142_FC4smp ([EMAIL PROTECTED]) (gcc version 4.0.2 20051125 (Red Hat 4.0.2-8)) #1 SMP Tue Jul 11 22:57:02 EDT 2006 -- Summary: A member variable named 'not' is intrepreted by the compiler as the '!' sign. Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: selalerer at nana dot co dot il http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29514
[Bug c++/29514] A member variable named 'not' is intrepreted by the compiler as the '!' sign.
--- Comment #1 from selalerer at nana dot co dot il 2006-10-19 10:05 --- Created an attachment (id=12459) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12459&action=view) Source file for the code that created the bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29514
[Bug c++/29514] A member variable named 'not' is intrepreted by the compiler as the '!' sign.
--- Comment #2 from selalerer at nana dot co dot il 2006-10-19 10:06 --- Created an attachment (id=12460) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12460&action=view) The *.ii file created by the compiler from the source file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29514
[Bug c++/29514] A member variable named 'not' is intrepreted by the compiler as the '!' sign.
--- Comment #3 from pcarlini at suse dot de 2006-10-19 10:26 --- not a bug: per section 2.5 of the Standard 'not' is an alternative token for '!' -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29514
[Bug tree-optimization/26969] [4.1 Regression] ICE with -O1 -funswitch-loops -ftree-vectorize
--- Comment #16 from irar at gcc dot gnu dot org 2006-10-19 11:18 --- Subject: Bug 26969 Author: irar Date: Thu Oct 19 11:18:25 2006 New Revision: 117883 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117883 Log: Backport from mainline: 2006-08-07 Victor Kaplansky <[EMAIL PROTECTED]> PR tree-optimization/26969 * tree-vect-analyze.c (vect_analyze_loop_form): Add check of latch with an empty list of PHIs. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/vect/unswitch-loops-pr26969.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/vect/vect.exp branches/gcc-4_1-branch/gcc/tree-vect-analyze.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26969
[Bug other/29515] New: [reject-valid] error: forming reference to reference type X.
comeau reports no error, and with stlport5 testcase works fine. $ g++ -I/usr/include/stlport main.cpp -o main -lstlport && ./main Hello 1 Hello 2 with libstdc++ i get: $ g++ main.cpp -o main && ./main /usr/include/c++/4.1.2/bits/stl_function.h: In instantiation of ‘std::binder2nd >’: main.cpp:13: instantiated from here /usr/include/c++/4.1.2/bits/stl_function.h:435: error: forming reference to reference type ‘const std::string&’ /usr/include/c++/4.1.2/bits/stl_function.h: In function ‘std::binder2nd<_Operation> std::bind2nd(const _Operation&, const _Tp&) [with _Operation = std::pointer_to_binary_function, _Tp = std::basic_string, std::allocator >]’: main.cpp:13: instantiated from here /usr/include/c++/4.1.2/bits/stl_function.h:455: error: no matching function for call to ‘std::binder2nd >::binder2nd(const std::pointer_to_binary_function&, const std::basic_string, std::allocator >&)’ /usr/include/c++/4.1.2/bits/stl_function.h:429: note: candidates are: std::binder2nd >::binder2nd(const std::binder2nd >&) -- Summary: [reject-valid] error: forming reference to reference type X. Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pluto at agmk dot net GCC target triplet: x86_64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29515
[Bug other/29515] [reject-valid] error: forming reference to reference type X.
--- Comment #1 from pluto at agmk dot net 2006-10-19 11:54 --- Created an attachment (id=12461) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12461&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29515
[Bug fortran/29387] ICE on character array function of variable length
--- Comment #4 from patchapp at dberlin dot org 2006-10-19 12:21 --- Subject: Bug number PR29387 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/2006-10/msg00982.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29387
[Bug fortran/29516] New: Bug in character transpose
The following program (adapted from our testsuite): $ cat char_transpose_1.f90 program main implicit none integer, parameter :: n1 = 3, n2 = 4, slen = 9 character (len = slen), dimension (n1, n2) :: a integer :: i1, i2 do i2 = 1, n2 do i1 = 1, n1 a (i1, i2) = 'ab'(i1:i1) // 'cde'(i2:i2) // 'cantrip' end do end do call test (transpose (a)) contains subroutine test (b) character (len = slen), dimension (:, :) :: b print *, size (b, 1), "==", n2 print *, size(b,2), "==", n1 do i2 = 1, n2 do i1 = 1, n1 print *, b (i2, i1), "==", a (i1, i2) end do end do end subroutine test end program main gives incorrect results on i386-apple-darwin, with both -m32 and -m64: $ gfortran char_transpose_1.f90 -g -m32 && ./a.out 4 == 4 4 == 3 accantrip==accantrip adcantrip==bccantrip aecantrip==cccantrip adcantrip==adcantrip aecantrip==bdcantrip aacantrip==cdcantrip aecantrip==aecantrip aacantrip==becantrip ,��l���==cecantrip aacantrip==aacantrip ,��l���==bacantrip �""==cacantrip $ gfortran char_transpose_1.f90 -m64 && ./a.out 4 == 4 4 == 3 accantrip==accantrip adcantrip==bccantrip aecantrip==cccantrip adcantrip==adcantrip aecantrip==bdcantrip aacantrip==cdcantrip aecantrip==aecantrip aacantrip==becantrip �==cecantrip aacantrip==aacantrip �==bacantrip ���==cacantrip This is with mainline gfortran: $ gfortran -v Using built-in specs. Target: i386-apple-darwin8.8.1 Configured with: /gcc/configure --enable-languages=c,fortran Thread model: posix gcc version 4.2.0 20061019 (experimental) The corresponding test results can be found here: http://gcc.gnu.org/ml/gcc-testresults/2006-10/msg00952.html (and they don't look too good). -- Summary: Bug in character transpose Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org GCC target triplet: i386-apple-darwin8.8.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29516
[Bug fortran/29490] internal compiler error: in fold_binary, at fold-const.c:8239
--- Comment #4 from patchapp at dberlin dot org 2006-10-19 12:35 --- Subject: Bug number PR29490 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/2006-10/msg00983.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29490
[Bug fortran/29507] INDEX in an array initialization causes ICE
--- Comment #1 from patchapp at dberlin dot org 2006-10-19 12:50 --- Subject: Bug number PR29507 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/2006-10/msg00984.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29507
[Bug libstdc++/29515] error: forming reference to reference type X.
--- Comment #2 from pcarlini at suse dot de 2006-10-19 13:10 --- This is a well knows issue with the current standard binders, see, for example: http://gcc.gnu.org/ml/libstdc++/2000-06/msg00210.html It is possible to extend the implementation, but the real way to go is moving to the new generalized bind facility, which will be in C++0x and we are already providing as part of our tr1 delivery. It would be (modulo tr1 namespace decorations...): bind(std::ptr_fun( print ), _1, str) -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29515
[Bug libstdc++/29496] _M_invalidate function is not thread-safe in GLIBCXX_DEBUG mode
--- Comment #7 from l_heldt at poczta dot onet dot pl 2006-10-19 13:51 --- (In reply to comment #2) > Please attach a complete test case, not a sketch. > > -benjamin > This bug is a pure race-condition. There is no test case which would reveal it with a 100% certainty. I have noticed the bug after receiving strange SIGSEGV in _M_invalidate() function. After reviewing the code I found the problem stated in this bug report. Of course you can say: "No test case - no bug" but I guess this would be a very naive approach. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29496
[Bug other/29512] compile time hog / deadloop.
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-10-19 14:31 --- I can confirm this. We are gimplifying some large tree(s) like #150 0x005257ff in gimplify_stmt (stmt_p=0x7fffcff543e8) at /space//rguenther/src/svn/gcc-4_1-branch/gcc/gimplify.c:4028 4028 gimplify_expr (stmt_p, NULL, NULL, is_gimple_stmt, fb_none); (gdb) call debug_generic_expr (*stmt_p) operator= (&TARGET_EXPR , &((struct definition, boost::spirit::match_policy, boost::spirit::action_policy> > >D.98251 *) thisD.100424)->hex_digit_ntD.101683) and thus spend a lot of time in #60 0x00524020 in gimplify_modify_expr_rhs (expr_p=0x7fffcff50c60, from_p=0x2ac5e2795090, to_p=0x2ac5e2795088, pre_p=0x7fffcff542e8, post_p=0x7fffcff50f40, want_value=0 '\0') at /space//rguenther/src/svn/gcc-4_1-branch/gcc/gimplify.c:3183 3183if (!CALL_EXPR_RETURN_SLOT_OPT (*from_p) which in turn dispatches to i386.c:classify_argument at some point which is a nice (*cough*) O(n^m) with m >= 2 complexity function. And for some reason we won't return from frame #55, which is the topmost classify_argument frame: #57 0x008ed590 in ix86_return_in_memory (type=0x2ac5dfd980b0) at /space//rguenther/src/svn/gcc-4_1-branch/gcc/config/i386/i386.c:3531 3531return !examine_argument (mode, type, 1, &needed_intregs, &needed_sseregs); (gdb) down #56 0x008ebf29 in examine_argument (mode=BLKmode, type=0x2ac5dfd980b0, in_return=1, int_nregs=0x7fffcff509c4, sse_nregs=0x7fffcff509c0) at /space//rguenther/src/svn/gcc-4_1-branch/gcc/config/i386/i386.c:2882 2882 int n = classify_argument (mode, type, class, 0); (gdb) #55 0x008eb47a in classify_argument (mode=BLKmode, type=0x2ac5dfd980b0, classes=0x7fffcff50980, bit_offset=0) at /space//rguenther/src/svn/gcc-4_1-branch/gcc/config/i386/i386.c:2637 2637 num = classify_argument (TYPE_MODE (type), (gdb) finish Run till exit from #55 0x008eb47a in classify_argument (mode=BLKmode, type=0x2ac5dfd980b0, classes=0x7fffcff50980, bit_offset=0) at /space//rguenther/src/svn/gcc-4_1-branch/gcc/config/i386/i386.c:2637 (it's probably not really dead here, just taking a long time to complete, as finishing earlier frames takes more and more time) -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29512
[Bug other/29512] compile time hog / deadloop.
--- Comment #4 from pluto at agmk dot net 2006-10-19 14:46 --- (In reply to comment #3) > (it's probably not really dead here, just taking a long time to complete, as > finishing earlier frames takes more and more time) compilation for i486 target takes ~20 seconds and ~300MB of memory. for x86_64 target the 16 hours in not enough. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29512
[Bug libstdc++/29515] error: forming reference to reference type X.
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-19 14:51 --- Actually this is valid C++ via DR 106. Reopening to ... -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29515
[Bug libstdc++/29515] error: forming reference to reference type X.
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-19 14:52 --- To close as a dup of bug 7412. *** This bug has been marked as a duplicate of 7412 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29515
[Bug c++/7412] [DR 106] References to references
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-19 14:52 --- *** Bug 29515 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pluto at agmk dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7412
[Bug tree-optimization/26969] [4.1 Regression] ICE with -O1 -funswitch-loops -ftree-vectorize
--- Comment #17 from pinskia at gcc dot gnu dot org 2006-10-19 14:58 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26969
[Bug other/29512] compile time hog / deadloop.
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-10-19 15:15 --- It _looks_ like we're needlessly recursing into the BINFOs in the i386 backend. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|target |other http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29512
[Bug target/29413] -EB / -EL don't properly affect endian for Linux on MIPS
--- Comment #9 from rsandifo at gcc dot gnu dot org 2006-10-19 15:45 --- Subject: Bug 29413 Author: rsandifo Date: Thu Oct 19 15:45:46 2006 New Revision: 117886 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117886 Log: gcc/ Backport from mainline: 2006-10-17 Andrew Pinsiki <[EMAIL PROTECTED]> Richard Sandiford <[EMAIL PROTECTED]> PR target/29413 * config/mips/linux.h (SUBTARGET_CC1_SPEC): Override. * config/mips/mips.h (CC1_SPEC): Override any earlier definition. Added: branches/csl/sourcerygxx-4_1/gcc/ChangeLog.csl Modified: branches/csl/sourcerygxx-4_1/gcc/config/mips/linux.h branches/csl/sourcerygxx-4_1/gcc/config/mips/mips.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29413
[Bug middle-end/28116] [4.1 Regression] ICE when building konverter with gcc-4.1 with -O3 [RSO]
--- Comment #9 from janis at gcc dot gnu dot org 2006-10-19 16:35 --- I wasn't able to do a regression hunt for the fix on the mainline because I didn't find any revision for which the test failed on the mainline. A regression hunt on the 4.1 branch using the testcase from comment #7 with an i686-linux cross compiler identified this patch where the test starts getting the ICE: http://gcc.gnu.org/viewcvs?view=rev&rev=110838 r110838 | jason | 2006-02-10 17:32:10 + (Fri, 10 Feb 2006) The mainline didn't ICE when that patch was added. -- janis at gcc dot gnu dot org changed: What|Removed |Added CC||jason at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28116
[Bug c++/29517] New: Exception handling not thread-safe on AIX5.x with Gnu compilers
The attached code crashes under AIX5.2 and AIX5.3 when compiled with g++ 4.1.1. The effect also occurs using g++ 4.0.3. It seems that throwing exceptions is not completely thread safe. The crash symptom is one of: 1. segmentation fault (core dumped) 2. illegal instruction (core dumped) 3. terminate called after throwing an instance of 'int' (core dumped). The effect cannot clearly be reproduced. However when running the test program (crashme.cpp) with rather big parameter values one can proove that the program crashes very often after some time if the params are choosen big enough. The program was build with following command: g++ crashme.cpp -o crashme -lpthread Usage: crashme For example 'crashme 50 1000' was enough to crash it on our box almost every time. -- Summary: Exception handling not thread-safe on AIX5.x with Gnu compilers Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Ulrich dot Beingesser at t-systems dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29517
[Bug c++/29517] Exception handling not thread-safe on AIX5.x with Gnu compilers
--- Comment #1 from Ulrich dot Beingesser at t-systems dot com 2006-10-19 16:45 --- Created an attachment (id=12462) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12462&action=view) Test program that demonstrates the bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29517
[Bug c++/29517] Exception handling not thread-safe on AIX5.x with Gnu compilers
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-19 16:51 --- -lpthread I think that is your problem, you should be using -pthread instead. Can you try using -pthread instead of -lpthread? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29517
[Bug java/29509] gcj MetalLookAndFeel.java causes gcj to SIGILL on PPC Linux
--- Comment #2 from billt at tutsys dot com 2006-10-19 17:01 --- "make bootstrap" produces a different error; I'll try building just the C compiler next (even if gcj is what I'm really after). /tmp/gcc-4.1.1/820/./gcc/xgcc -shared-libgcc -B/tmp/gcc-4.1.1/820/./gcc -nostdinc++ -L/tmp/gcc-4.1.1/820/powerpc-unknown-linux-gnu/nof/libstdc++-v3/src -L/tmp/gcc-4.1.1/820/powerpc-unknown-linux-gnu/nof/libstdc++-v3/src/.libs -B/usr/local/gcc411/powerpc-unknown-linux-gnu/bin/ -B/usr/local/gcc411/powerpc-unknown-linux-gnu/lib/ -isystem /usr/local/gcc411/powerpc-unknown-linux-gnu/include -isystem /usr/local/gcc411/powerpc-unknown-linux-gnu/sys-include -msoft-float -fPIC -mstrict-align -DHAVE_CONFIG_H -I. -I../../../../libjava -I./include -I./gcj -I../../../../libjava -Iinclude -I../../../../libjava/include -I../../../../libjava/classpath/include -I../../../../libjava/classpath/native/fdlibm -I../../../../libjava/../boehm-gc/include -I../boehm-gc/include -I../../../../libjava/libltdl -I../../../../libjava/libltdl -I../../../../libjava/.././libjava/../gcc -I../../../../libjava/../zlib -I../../../../libjava/../libffi/include -I../libffi/include -fno-rtti -fnon-call-exceptions -fdollars-in-identifiers -Wswitch-enum -D_FILE_OFFSET_BITS=64 -Wextra -Wall -D_GNU_SOURCE -DPREFIX=\"/usr/local/gcc411\" -DLIBDIR=\"/usr/local/gcc411/lib\" -DJAVA_HOME=\"/usr/local/gcc411\" -DBOOT_CLASS_PATH=\"/usr/local/gcc411/share/java/libgcj-4.1.1.jar\" -DJAVA_EXT_DIRS=\"/usr/local/gcc411/share/java/ext\" -DGCJ_ENDORSED_DIRS=\"/usr/local/gcc411/share/java/gcj-endorsed\" -DLIBGCJ_DEFAULT_DATABASE=\"/usr/local/gcc411/lib/nof/gcj-4.1.1/classmap.db\" -DLIBGCJ_DEFAULT_DATABASE_PATH_TAIL=\"gcj-4.1.1/classmap.db\" -DTOOLEXECLIBDIR=\"/usr/local/gcc411/lib/nof\" -g -O2 -D_GNU_SOURCE -msoft-float -fPIC -mstrict-align -MT interpret.lo -MD -MP -MF .deps/interpret.Tpo -c ../../../../libjava/interpret.cc -fPIC -DPIC -o .libs/interpret.o ../../../../libjava/java/lang/Class.h: In member function 'java::lang::Class* java::lang::Class::getComponentType()': ../../../../libjava/java/lang/Class.h:354: warning: dereferencing type-punned pointer will break strict-aliasing rules ../../../../libjava/interpret.cc: In static member function 'static void _Jv_InterpMethod::run(void*, ffi_raw*, _Jv_InterpMethod*)': ../../../../libjava/interpret.cc:808: warning: dereferencing type-punned pointer will break strict-aliasing rules /tmp/ccr05ku5.s: Assembler messages: /tmp/ccr05ku5.s:27467: Error: bignum invalid make[6]: *** [interpret.lo] Error 1 make[6]: Leaving directory `/tmp/gcc-4.1.1/820/powerpc-unknown-linux-gnu/nof/libjava' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29509
[Bug c++/29517] Exception handling not thread-safe on AIX5.x with Gnu compilers
--- Comment #3 from Ulrich dot Beingesser at t-systems dot com 2006-10-19 17:02 --- (In reply to comment #2) > -lpthread > I think that is your problem, you should be using -pthread instead. > Can you try using -pthread instead of -lpthread? Using -pthread instead of -lpthread shows the same results. gcc was configured using (taken from g++ -v): Using built-in specs. Target: powerpc-ibm-aix5.3.0.0 Configured with: /tools/gnu/gcc/gcc-4.1.1/configure --prefix=/newtools/OS_AIX53/gcc4.1.1 --enable-threads=posix --enable-languages=c,c++ Thread model: aix gcc version 4.1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29517
[Bug bootstrap/29509] gcj MetalLookAndFeel.java causes gcj to SIGILL on PPC Linux
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-19 17:14 --- (In reply to comment #2) > "make bootstrap" produces a different error; I'll try building just the C > compiler next (even if gcj is what I'm really after). After that finishes, you should bootstrap the compiler with the newer compiler and that might actually fix the issue. If that does not work, try using compiling 3.3.6 first and then 4.1.1. What is most likely happening now is 2.95.3 is miscompiling badly the newly compiled 4.1.1 so you get these errors. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29509
[Bug c++/29517] Exception handling not thread-safe on AIX5.x with Gnu compilers
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|blocker |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29517
[Bug c++/21976] Incomplete types are not detected at template definition time
--- Comment #3 from ppluzhnikov at charter dot net 2006-10-19 17:34 ---
Here is another (very similar) test case:
template struct Dict {
struct Iterator;
Iterator begin() { return Iterator(); } // incomplete
};
template struct Dict::Iterator { Iterator() { } };
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21976
[Bug c++/28358] ICE on valide template code using -O1 or -O2, but *not* with -O0 or -O3
--- Comment #3 from fang at csl dot cornell dot edu 2006-10-19 18:03 --- ping? ice-on-valid in boost -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28358
[Bug c++/28358] ICE on valide template code using -O1 or -O2, but *not* with -O0 or -O3
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-19 18:06 --- This is most likely a dup of bug 28116 anyways. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28358
[Bug fortran/28176] FAIL: gfortran.dg/actual_array_constructor_1.f90 -O0 (ICE)
--- Comment #8 from sje at cup dot hp dot com 2006-10-19 18:09 --- Well, I found that the TImode is getting introduced in layout_type. For an ARRAY_TYPE tree there is this line: TYPE_SIZE (type) = size_binop (MULT_EXPR, element_size, fold_convert (bitsizetype, length)); If you look at bitsizetype, you will find that it is TImode and thus the resulting expression is TImode. bitsizetype is set in set_sizetype based on 2 * BITS_PER_UNIT_LOG which is 64 for hppa64. Thus our problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28176
[Bug target/29512] compile time hog / deadloop.
--- Comment #6 from hubicka at ucw dot cz 2006-10-19 19:36 --- Subject: Re: compile time hog / deadloop. > > > --- Comment #5 from rguenth at gcc dot gnu dot org 2006-10-19 15:15 > --- > It _looks_ like we're needlessly recursing into the BINFOs in the i386 > backend. What that code is shooting for is to interpret the class hiearchy as an union - each base class is walked and classified. This is not exactly my area, but does the testcase really have so deep nesting of base classes to this shows up in profiles? Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29512
[Bug target/29512] compile time hog / deadloop.
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-10-19 20:45 --- I wonder why we walk the class hierarchy using the BINFOs at all. It contains lots of recursively empty structures - maybe better just walk the TYPE_FIELDS list recursively? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29512
[Bug target/29512] compile time hog / deadloop.
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-10-19 20:47 --- Btw. - completely killing the BINFO walking bootstraps and regtests ok... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29512
[Bug c++/29518] New: incorrect "
Regression from gcc 3.4.4; under gcc 4.1.1 it produces the diagnostic "error:
'N::okay' is not a valid template argument for type 'bool' because it is a
non-constant expression" -- and I am informed (by gdr) that the bug is still
present in gcc 4.2.0.
The code below makes use of the Boost library; I can also provide the
preprocessed version of the same code, if requested, but it's on the order of
1000 lines long:
#include "boost/mpl/assert.hpp"
template< class T >
struct N
{
static bool const okay = true;
BOOST_MPL_ASSERT_MSG( okay, message_goes_here, (T) );
};
int
main()
{
N n;
}
--
Summary: incorrect "
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wb at fnal dot gov
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29518
[Bug c++/29518] incorrect "
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-19 21:19 --- Yes we need the preprocessed source. You can attach it to the bug report instead of just copying and pasting it. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29518
[Bug c++/29518] incorrect "
--- Comment #2 from wb at fnal dot gov 2006-10-19 21:22 --- Created an attachment (id=12463) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12463&action=view) preprocessed version of test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29518
[Bug c++/29518] incorrect "
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-19 21:27 ---
I tried a simple testcase and variations on it (changing (T)(ok) to just ok and
such):
template class b{};
template class t
{
static bool const ok = true;
b<(T)(ok)> c;
};
int main(void)
{
t a;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29518
[Bug c++/29518] incorrect "
--- Comment #4 from gdr at cs dot tamu dot edu 2006-10-19 21:32 --- Subject: Re: incorrect " On Thu, 19 Oct 2006, pinskia at gcc dot gnu dot org wrote: | I tried a simple testcase and variations on it (changing (T)(ok) to just ok and | such): yes, the parens don't change anything -- I've tried that. I attempted to reduce the testcase, but I did not have time. My first attempt was too broad and did not reproduce the bug, so I left it to the original form. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29518
[Bug c++/29518] diagnostic on correct code; regression from 3.4.4
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-10-19 21:42 --- Reducing through a nice trick of using delta and using 3.3.x as the base compiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29518
[Bug libfortran/27895] problem with SPREAD and zero-sized arrays
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2006-10-19 21:49 --- Subject: Bug 27895 Author: fxcoudert Date: Thu Oct 19 21:48:50 2006 New Revision: 117890 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117890 Log: PR libfortran/27895 * intrinsics/cshift0.c: Special cases for zero-sized arrays. * intrinsics/pack_generic.c: Likewise. * intrinsics/spread_generic.c: Likewise. * gfortran.dg/zero_sized_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/zero_sized_1.f90 Modified: trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/intrinsics/cshift0.c trunk/libgfortran/intrinsics/pack_generic.c trunk/libgfortran/intrinsics/spread_generic.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27895
[Bug c++/29518] diagnostic on correct code; regression from 3.4.4
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-10-19 21:54 ---
Reduced testcase:
template< bool C > int assertion_failed( int);
template< class >
struct N
{
static bool const okay = true;
enum {
t = sizeof( assertion_failed( 0))
};
};
main()
{
N n;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29518
[Bug c++/29518] diagnostic on correct code; regression from 3.4.4
--- Comment #7 from gdr at cs dot tamu dot edu 2006-10-19 21:57 ---
Subject: Re: diagnostic on correct code; regression from
3.4.4
On Thu, 19 Oct 2006, pinskia at gcc dot gnu dot org wrote:
| Reduced testcase:
Very nice.
| template< bool C > int assertion_failed( int);
| template< class >
| struct N
| {
| static bool const okay = true;
| enum {
| t = sizeof( assertion_failed( 0))
| };
| };
| main()
missing "int".
| {
| N n;
| }
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29518
[Bug c++/29518] [4.0/4.1/4.2 Regression] rejects valid template argument, enums vs templates
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||rejects-valid Known to fail||4.0.2 4.1.0 4.2.0 Known to work||3.4.0 Summary|diagnostic on correct code; |[4.0/4.1/4.2 Regression] |regression from 3.4.4 |rejects valid template ||argument, enums vs templates Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29518
[Bug libfortran/27895] problem with RESHAPE and zero-sized arrays
--- Comment #11 from fxcoudert at gcc dot gnu dot org 2006-10-19 21:59 --- It's still not working for RESHAPE. Uncomment the test_reshape line in the newly added zero_sized_1.f90 test and see how it fails :) -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added URL|http://gcc.gnu.org/ml/gcc- | |patches/2006- | |07/msg01103.html| Keywords|patch | Summary|problem with SPREAD and |problem with RESHAPE and |zero-sized arrays |zero-sized arrays http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27895
[Bug c/29519] New: [4.2 Regression] Bad code on MIPS with -fnon-call-exceptions
This is a reduced testcase from a failure I am seeing on libgcj testsuite.
java.lang.Class.isPrimitive() is being compiled incorrectly.
This is a regression from 3.4.3.
Configured as: ../clean/configure --target=mipsel-linux
--with-sysroot=/usr/local/mipsel-linux-test
--prefix=/usr/local/mipsel-linux-test --with-arch=mips32 --with-float=soft
--with-system-zlib --disable-java-awt --without-x --disable-libmudflap
--disable-libgomp --disable-jvmpi --disable-tls --enable-languages=c,c++,java
on i686-pc-linux-gnu
Here is the test case in C isprim.c:
-8<
struct F;
struct C
{
struct F *f13;
};
int isM1(struct C *t)
{
return t->f13 == (struct F*)-1;
}
-8<
$ mipsel-linux-gcc -O1 -S isprim.c -o isprim.s
Generates this correct code:
lw $2,0($4)
addiu $2,$2,1
j $31
sltu$2,$2,1
$ mipsel-linux-gcc -fnon-call-exceptions -O1 -S isprim.c -o isprim.s
Generates this incorrect code that unconditionally returns 0:
lw $2,0($4)
.setnoreorder
.setnomacro
j $31
move$2,$0
.setmacro
.setreorder
--
Summary: [4.2 Regression] Bad code on MIPS with -fnon-call-
exceptions
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: daney at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: mipsel-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29519
[Bug target/27363] ARM gcc 4.1 optimization bug
--- Comment #18 from likewise at gmx dot net 2006-10-19 22:01 --- Created an attachment (id=12464) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12464&action=view) Fix. Copied from http://www.freaknet.org/martin/crosstool/patches/gcc-4.1.1/gcc-4.1.1-bugfix-27363.patch so that it linked to this report. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27363
[Bug target/29519] [4.2 Regression] Bad code on MIPS with -fnon-call-exceptions
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29519
[Bug c++/29518] [4.0/4.1/4.2 Regression] rejects valid template argument, enums vs templates
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-10-19 21:58 ---
Note bool has nothing to do with the problem, the following testcase shows
that:
template< int C > int assertion_failed( int);
template< class >
struct N
{
static int const okay = 1;
enum {
t = sizeof( assertion_failed( 0))
};
};
int main()
{
N n;
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2006-10-19 21:58:50
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29518
[Bug c++/29518] [4.0/4.1/4.2 Regression] rejects valid template argument, enums vs templates
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-10-19 21:59 --- (In reply to comment #7) > missing "int". That is because we did not error out on it in 3.3.3 or 3.4.0 for that matter, I wonder why. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29518
[Bug fortran/29516] Bug in character transpose
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-10-19 22:16 --- The generated code emitted for the TRANSPOSE for i386-darwin is stupid: atmp.13.dtype = parm.12.dtype; atmp.13.dim[0].stride = parm.12.dim[1].stride; atmp.13.dim[0].lbound = parm.12.dim[1].lbound; atmp.13.dim[0].ubound = parm.12.dim[1].ubound; atmp.13.dim[1].stride = parm.12.dim[1].stride; atmp.13.dim[1].lbound = parm.12.dim[1].lbound; atmp.13.dim[1].ubound = parm.12.dim[1].ubound; atmp.13.data = parm.12.data; atmp.13.offset = parm.12.offset; when you compare it to the (correct) code emitted on x86-linux: atmp.13.dtype = parm.12.dtype; atmp.13.dim[0].stride = parm.12.dim[1].stride; atmp.13.dim[0].lbound = parm.12.dim[1].lbound; atmp.13.dim[0].ubound = parm.12.dim[1].ubound; atmp.13.dim[1].stride = parm.12.dim[0].stride; atmp.13.dim[1].lbound = parm.12.dim[0].lbound; atmp.13.dim[1].ubound = parm.12.dim[0].ubound; atmp.13.data = parm.12.data; atmp.13.offset = parm.12.offset; -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|target |fortran Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-10-19 22:16:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29516
[Bug libstdc++/29520] New: tr1: discrete_distributions vs large floating point values
This is an internal reminder for an issue which must be fixed before delivering the discrete distributions (geometric, poisson, binomial, in particular): when, in operator(), the floating point result exceeds the max integer value of the return type the value must be rejected. -- Summary: tr1: discrete_distributions vs large floating point values Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pcarlini at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29520
[Bug libstdc++/29520] tr1: discrete_distributions vs large floating point values
--- Comment #1 from pcarlini at suse dot de 2006-10-19 22:22 --- Will fix as soon as I'm nack from a travel... -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-10-19 22:22:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29520
[Bug fortran/29516] Bug in character transpose
--- Comment #2 from echristo at apple dot com 2006-10-19 22:24 --- I'll take a look at this. -- echristo at apple dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |echristo at apple dot com |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-10-19 22:16:23 |2006-10-19 22:24:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29516
[Bug target/29519] [4.2 Regression] Bad code on MIPS with -fnon-call-exceptions
--- Comment #1 from daney at gcc dot gnu dot org 2006-10-19 22:54 --- Created an attachment (id=12465) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12465&action=view) Dumps from -da with and without -fnon-call-exceptions The dump files in da-dumps.tgz named isprimb.c.* are from: $ mipsel-linux-gcc -fnon-call-exceptions -da -O1 -S isprimb.c -o isprimb.s Where isprimb.c is the exact same testcase as isprim.c The 'b' suffix indicating bad. The files named isprim.c.* are from: $ mipsel-linux-gcc -da -O1 -S isprim.c -o isprim.s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29519
[Bug tree-optimization/29156] [4.2 Regression] Misscompilation with structs due to new struct alias
--- Comment #8 from dberlin at gcc dot gnu dot org 2006-10-19 23:06 --- Subject: Bug 29156 Author: dberlin Date: Thu Oct 19 23:05:53 2006 New Revision: 117891 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117891 Log: 2006-10-19 Daniel Berlin <[EMAIL PROTECTED]> Fix PR tree-optimization/28778 Fix PR tree-optimization/29156 Fix PR tree-optimization/29415 * tree.h (DECL_PTA_ARTIFICIAL): New macro. (tree_decl_with_vis): Add artificial_pta_var flag. * tree-ssa-alias.c (is_escape_site): Remove alias info argument, pushed into callers. * tree-ssa-structalias.c (nonlocal_for_type): New variable. (nonlocal_all): Ditto. (struct variable_info): Add directly_dereferenced member. (var_escaped_vars): New variable. (escaped_vars_tree): Ditto. (escaped_vars_id): Ditto. (nonlocal_vars_id): Ditto. (new_var_info): Set directly_dereferenced. (graph_size): New variable (build_constraint_graph): Use graph_size. (solve_graph): Don't process constraints that cannot change the solution, don't try to propagate an empty solution to our successors. (process_constraint): Set directly_dereferenced. (could_have_pointers): New function. (get_constraint_for_component_ref): Don't process STRING_CST. (nonlocal_lookup): New function. (nonlocal_insert): Ditto. (create_nonlocal_var): Ditto. (get_nonlocal_id_for_type): Ditto. (get_constraint_for): Allow results vector to be empty in the case of string constants. Handle results of calls properly. (update_alias_info): Update alias info stats on number and type of calls. (find_func_aliases): Use could_have_pointers. (make_constraint_from_escaped): Renamed from make_constraint_to_anything, and changed to make constraints from escape variable. (make_constraint_to_escaped): New function. (find_global_initializers): Ditto. (create_variable_info_for): Make constraint from escaped to any global variable, and from any global variable to the set of escaped vars. (intra_create_variable_infos): Deal with escaped instead of pointing to anything. (set_uids_in_ptset): Do type pruning on directly dereferenced variables. (find_what_p_points_to): Adjust call to set_uids_with_ptset. (init_base_vars): Fix comment, and initialize escaped_vars. (need_to_solve): Removed. (find_escape_constraints): New function. (expand_nonlocal_solutions): Ditto. (compute_points_to_sets): Call find_escape_constraints and expand_nonlocal_solutions. (delete_points_to_sets): Don't fall off the end of the graph. (init_alias_heapvars): Initialize nonlocal_for_type and nonlocal_all. (delete_alias_heapvars): Free nonlocal_for_type and null out nonlocal_all. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr28778.c trunk/gcc/testsuite/gcc.c-torture/execute/pr29156.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/pta-fp.c trunk/gcc/tree-ssa-alias.c trunk/gcc/tree-ssa-operands.c trunk/gcc/tree-ssa-structalias.c trunk/gcc/tree-ssa-structalias.h trunk/gcc/tree.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29156
[Bug tree-optimization/29415] [4.2 Regression] bad code reordering around inline asm block
--- Comment #11 from dberlin at gcc dot gnu dot org 2006-10-19 23:06 --- Subject: Bug 29415 Author: dberlin Date: Thu Oct 19 23:05:53 2006 New Revision: 117891 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117891 Log: 2006-10-19 Daniel Berlin <[EMAIL PROTECTED]> Fix PR tree-optimization/28778 Fix PR tree-optimization/29156 Fix PR tree-optimization/29415 * tree.h (DECL_PTA_ARTIFICIAL): New macro. (tree_decl_with_vis): Add artificial_pta_var flag. * tree-ssa-alias.c (is_escape_site): Remove alias info argument, pushed into callers. * tree-ssa-structalias.c (nonlocal_for_type): New variable. (nonlocal_all): Ditto. (struct variable_info): Add directly_dereferenced member. (var_escaped_vars): New variable. (escaped_vars_tree): Ditto. (escaped_vars_id): Ditto. (nonlocal_vars_id): Ditto. (new_var_info): Set directly_dereferenced. (graph_size): New variable (build_constraint_graph): Use graph_size. (solve_graph): Don't process constraints that cannot change the solution, don't try to propagate an empty solution to our successors. (process_constraint): Set directly_dereferenced. (could_have_pointers): New function. (get_constraint_for_component_ref): Don't process STRING_CST. (nonlocal_lookup): New function. (nonlocal_insert): Ditto. (create_nonlocal_var): Ditto. (get_nonlocal_id_for_type): Ditto. (get_constraint_for): Allow results vector to be empty in the case of string constants. Handle results of calls properly. (update_alias_info): Update alias info stats on number and type of calls. (find_func_aliases): Use could_have_pointers. (make_constraint_from_escaped): Renamed from make_constraint_to_anything, and changed to make constraints from escape variable. (make_constraint_to_escaped): New function. (find_global_initializers): Ditto. (create_variable_info_for): Make constraint from escaped to any global variable, and from any global variable to the set of escaped vars. (intra_create_variable_infos): Deal with escaped instead of pointing to anything. (set_uids_in_ptset): Do type pruning on directly dereferenced variables. (find_what_p_points_to): Adjust call to set_uids_with_ptset. (init_base_vars): Fix comment, and initialize escaped_vars. (need_to_solve): Removed. (find_escape_constraints): New function. (expand_nonlocal_solutions): Ditto. (compute_points_to_sets): Call find_escape_constraints and expand_nonlocal_solutions. (delete_points_to_sets): Don't fall off the end of the graph. (init_alias_heapvars): Initialize nonlocal_for_type and nonlocal_all. (delete_alias_heapvars): Free nonlocal_for_type and null out nonlocal_all. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr28778.c trunk/gcc/testsuite/gcc.c-torture/execute/pr29156.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/pta-fp.c trunk/gcc/tree-ssa-alias.c trunk/gcc/tree-ssa-operands.c trunk/gcc/tree-ssa-structalias.c trunk/gcc/tree-ssa-structalias.h trunk/gcc/tree.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29415
[Bug tree-optimization/28778] [4.0/4.1/4.2 Regression] alias bug with cast and call clobbered
--- Comment #43 from dberlin at gcc dot gnu dot org 2006-10-19 23:06 --- Subject: Bug 28778 Author: dberlin Date: Thu Oct 19 23:05:53 2006 New Revision: 117891 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117891 Log: 2006-10-19 Daniel Berlin <[EMAIL PROTECTED]> Fix PR tree-optimization/28778 Fix PR tree-optimization/29156 Fix PR tree-optimization/29415 * tree.h (DECL_PTA_ARTIFICIAL): New macro. (tree_decl_with_vis): Add artificial_pta_var flag. * tree-ssa-alias.c (is_escape_site): Remove alias info argument, pushed into callers. * tree-ssa-structalias.c (nonlocal_for_type): New variable. (nonlocal_all): Ditto. (struct variable_info): Add directly_dereferenced member. (var_escaped_vars): New variable. (escaped_vars_tree): Ditto. (escaped_vars_id): Ditto. (nonlocal_vars_id): Ditto. (new_var_info): Set directly_dereferenced. (graph_size): New variable (build_constraint_graph): Use graph_size. (solve_graph): Don't process constraints that cannot change the solution, don't try to propagate an empty solution to our successors. (process_constraint): Set directly_dereferenced. (could_have_pointers): New function. (get_constraint_for_component_ref): Don't process STRING_CST. (nonlocal_lookup): New function. (nonlocal_insert): Ditto. (create_nonlocal_var): Ditto. (get_nonlocal_id_for_type): Ditto. (get_constraint_for): Allow results vector to be empty in the case of string constants. Handle results of calls properly. (update_alias_info): Update alias info stats on number and type of calls. (find_func_aliases): Use could_have_pointers. (make_constraint_from_escaped): Renamed from make_constraint_to_anything, and changed to make constraints from escape variable. (make_constraint_to_escaped): New function. (find_global_initializers): Ditto. (create_variable_info_for): Make constraint from escaped to any global variable, and from any global variable to the set of escaped vars. (intra_create_variable_infos): Deal with escaped instead of pointing to anything. (set_uids_in_ptset): Do type pruning on directly dereferenced variables. (find_what_p_points_to): Adjust call to set_uids_with_ptset. (init_base_vars): Fix comment, and initialize escaped_vars. (need_to_solve): Removed. (find_escape_constraints): New function. (expand_nonlocal_solutions): Ditto. (compute_points_to_sets): Call find_escape_constraints and expand_nonlocal_solutions. (delete_points_to_sets): Don't fall off the end of the graph. (init_alias_heapvars): Initialize nonlocal_for_type and nonlocal_all. (delete_alias_heapvars): Free nonlocal_for_type and null out nonlocal_all. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr28778.c trunk/gcc/testsuite/gcc.c-torture/execute/pr29156.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/pta-fp.c trunk/gcc/tree-ssa-alias.c trunk/gcc/tree-ssa-operands.c trunk/gcc/tree-ssa-structalias.c trunk/gcc/tree-ssa-structalias.h trunk/gcc/tree.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28778
[Bug tree-optimization/28778] [4.0/4.1/4.2 Regression] alias bug with cast and call clobbered
--- Comment #44 from dberlin at gcc dot gnu dot org 2006-10-19 23:07 --- Fixed. -- dberlin at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28778
[Bug tree-optimization/29156] [4.2 Regression] Misscompilation with structs due to new struct alias
--- Comment #9 from dberlin at gcc dot gnu dot org 2006-10-19 23:07 --- Fixed. -- dberlin at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29156
[Bug tree-optimization/29415] [4.2 Regression] bad code reordering around inline asm block
--- Comment #12 from dberlin at gcc dot gnu dot org 2006-10-19 23:07 --- Fixed. -- dberlin at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29415
[Bug middle-end/29519] [4.2 Regression] Bad code on MIPS with -fnon-call-exceptions
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-19 23:10 ---
Expand does:
;; return t->f13 == 4294967295B
(insn 10 9 11 (set (reg/f:SI 196)
(mem/s/f/j:SI (reg/v/f:SI 194 [ t ]) [0 .f13+0 S4 A32])) -1
(nil)
(nil))
(insn 11 10 12 (set (reg:SI 198)
(plus:SI (reg/f:SI 196)
(const_int 1 [0x1]))) -1 (nil)
(nil))
(insn 12 11 13 (set (reg:SI 197)
(eq:SI (reg:SI 198)
(const_int 0 [0x0]))) -1 (nil)
(nil))
(insn 13 12 14 (set (reg:SI 193 [ ])
(reg:SI 197)) -1 (nil)
(nil))
(jump_insn 14 13 15 (set (pc)
(label_ref 0)) -1 (nil)
(nil))
And then CSE1 changes that into:
(insn 6 8 7 2 (set (reg/v/f:SI 194 [ t ])
(reg:SI 4 $4 [ t ])) 213 {*movsi_internal} (nil)
(expr_list:REG_EQUIV (mem/f/c/i:SI (reg/f:SI 77 $arg) [0 t+0 S4 A32])
(nil)))
(note 7 6 10 2 NOTE_INSN_FUNCTION_BEG)
(insn 10 7 16 2 (set (reg/f:SI 196 [ .f13 ])
(mem/s/f/j:SI (reg/v/f:SI 194 [ t ]) [0 .f13+0 S4 A32])) 213
{*movsi_internal} (nil)
(nil))
(note 16 10 19 2 NOTE_INSN_FUNCTION_END)
(insn 19 16 20 2 (asm_input ("")) -1 (nil)
(nil))
(insn 20 19 26 2 (set (reg/i:SI 2 $2 [ ])
(const_int 0 [0x0])) 213 {*movsi_internal} (nil)
(nil))
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|target |middle-end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29519
[Bug middle-end/29519] [4.2 Regression] Bad code on MIPS with -fnon-call-exceptions
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-19 23:16 --- The difference between with and without -fnon-call-exceptions is: insn 10 9 11 3 (set (reg/f:SI 196) (mem/s/f/j:SI (reg/v/f:SI 194 [ t ]) [0 .f13+0 S4 A32])) -1 (nil) (nil)) vs: (insn 10 9 11 3 (set (reg:SI 196) (mem/s/f/j:SI (reg/v/f:SI 194 [ t ]) [0 .f13+0 S4 A32])) -1 (nil) (nil)) Note in the case where it is set, we record 196 as a pointer so we know that pointers don't wrap so we decide that pointer+1 can never be 0 in CSE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29519
[Bug libstdc++/29515] error: forming reference to reference type X.
--- Comment #5 from pcarlini at suse dot de 2006-10-19 23:29 --- Ah, interesting! Therefore, if I understand correctly DR 106, when the C++ front-end will implement the resolution, this kind of bind2nd usage will magically start working without changing at all the library... On the other hand, Bjarne' observation in DR 106 is also interesting, because maintains that the library is mainly at fault for the binders... and this is already fixed in tr1::bind! Making progress everywhere! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29515
[Bug target/29512] compile time hog / deadloop.
--- Comment #9 from hubicka at ucw dot cz 2006-10-19 23:32 --- Subject: Re: compile time hog / deadloop. Just for a record, we discussed this a bit on IRC. I origionally wrote that loop copying logic from alias.c just to be sure that all the fields from base clases are merged into the result. It seems that TYPE_FIELDS should already contain all of them and if this is true, I think it is safe to drop the first loop as Richard suggest, since we should not worry about other properties of the base class, like aliasing does. The merging does slightly more than just dump merging of all fields into the classes array. For instance it might be convinced that something is missaligned and dump whole thing to memory, so I would preffer that that the patch is tested by comparing assembly of some non-trivial C++ code. But looking at the function, I can't come with scenario, where this would change ABI behaviour. Honza PS: Thianks for looking into this obviously my failure! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29512
[Bug middle-end/29519] [4.2 Regression] Bad code on MIPS with -fnon-call-exceptions
--- Comment #4 from daney at gcc dot gnu dot org 2006-10-20 01:10 --- Caused by commit r117143 Thanks to Andrew Pinski for helping me find it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29519
[Bug fortran/27954] ICE on garbage in DATA statement
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2006-10-20 03:24
---
I believe this is a duplicate of PR18923. What I am finding is that under some
error conditions, we end up with empty symbols. When gfc resolve is executed
we are bumping into this arror because the sym->name is equal to '\0'. With
this patch the call to gfc_get_default_type is avoided and we get a clean exit.
This begs the question, should these empty symbols be left to begin with.
This "fixes" both bugs. I have found another bug, playing with variations on
the test case that gives a similar error in gfc_typename.
Index: symbol.c
===
--- symbol.c(revision 117876)
+++ symbol.c(working copy)
@@ -223,6 +223,9 @@ gfc_set_default_type (gfc_symbol * sym,
if (sym->ts.type != BT_UNKNOWN)
gfc_internal_error ("gfc_set_default_type(): symbol already has a type");
+
+ if (*sym->name == '\0')
+return FAILURE;
ts = gfc_get_default_type (sym, ns);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954
[Bug fortran/18923] segfault after subroutine name confusion
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2006-10-20 03:26 --- *** This bug has been marked as a duplicate of 27954 *** -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18923
[Bug fortran/27954] ICE on garbage in DATA statement
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2006-10-20 03:26 --- *** Bug 18923 has been marked as a duplicate of this bug. *** -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added CC||Thomas dot Koenig at online ||dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954
[Bug middle-end/29519] [4.2 Regression] Bad code on MIPS with -fnon-call-exceptions
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-10-20 03:51:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29519
[Bug fortran/27954] ICE on garbage in DATA statement
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2006-10-20 03:54 --- Another test case with similar error: program friend character*20 y, x 0 data y /'abcdef'/, x /'jbnhjk'/ o print *, "basketcase" end program friend $ gfc pr27954.f90 In file pr27954.f90:2 character*20 y, x 0 1 Error: Syntax error in data declaration at (1) In file pr27954.f90:3 data y /'abcdef'/, x /'jbnhjk'/ o 1 Error: Syntax error in DATA statement at (1) In file pr27954.f90:6 end program friend 1 Internal Error at (1): gfc_typespec(): Undefined type This actually is error in gfc_typename () The error message has a typo in it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954
[Bug fortran/27954] ICE on garbage in DATA statement
--- Comment #15 from pault at gcc dot gnu dot org 2006-10-20 04:50 --- Jerry, I got your message and will reply later - I have to run for the bus! I have been aware that there is a problem with empty symbols for some little while. Whilst on the way to the lab, I will contemplate how to diagnose it. I think they arise out of the commit_symbol mechanism but I am not entirely sure. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added CC||paul dot richard dot thomas ||at cea dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954
[Bug c/29521] New: Confusing warning for return with expression in function returning void
Consider the following code:
void func ()
{
}
void func2 ()
{
return func ();
}
gcc -pedantic correctly warns about "return func();", but the warning text is
very confusing:
'return' with a value, in function returning void
It talks about "value" where there is no value involved.
It took me a while to understand what exactly is wrong. Warning says "value",
so I obviously checked signatures first; then I looked for a problem with
includes; then I asked in comp.lang.c.
It would be better if gcc said something like
'return' with an expression, in function returning void
or
ISO C forbids ...
The latter would be the best, I guess.
--
Summary: Confusing warning for return with expression in function
returning void
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: muntyan at tamu dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29521
