[Bug c++/32121] [4.1/4.2/4.3 Regression] C++ front-end accepts invalid __label__ declarations
--- Comment #4 from jakub at gcc dot gnu dot org 2007-10-12 07:08 --- Subject: Bug 32121 Author: jakub Date: Fri Oct 12 07:07:46 2007 New Revision: 129253 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129253 Log: PR c++/32121 * parser.c (cp_parser_compound_statement): Handle label-declarations at the beginning of the compound statement. (cp_parser_block_declaration): Issue diagnostics about __label__ not at the beginning of a block. * g++.dg/ext/label4.C: Adjust error regexp. * g++.dg/ext/label6.C: Adjust error regexp. * g++.dg/ext/label7.C: New test. * g++.dg/ext/label8.C: New test. * g++.dg/ext/label9.C: New test. Added: trunk/gcc/testsuite/g++.dg/ext/label7.C trunk/gcc/testsuite/g++.dg/ext/label8.C trunk/gcc/testsuite/g++.dg/ext/label9.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/ext/label4.C trunk/gcc/testsuite/g++.dg/ext/label6.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32121
[Bug tree-optimization/33645] [4.3 Regression] undefined static variable in vortex for -fno-unit-at-a-time
--- Comment #1 from jakub at gcc dot gnu dot org 2007-10-12 07:10 --- Subject: Bug 33645 Author: jakub Date: Fri Oct 12 07:10:22 2007 New Revision: 129254 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129254 Log: PR tree-optimization/33645 * tree-ssa-live.c (mark_all_vars_used): Add data argument, pass it to walk_tree. (mark_all_vars_used_1): Pass data through to mark_all_vars_used. When calling set_is_used on a VAR_DECL, if data is not NULL and its DECL_UID is in the bitmap, call mark_all_vars_used on its DECL_INITIAL after clearing the bit in bitmap. (remove_unused_locals): Adjust mark_all_vars_used callers. Instead of removing unused global vars from unexpanded_var_list immediately record them in bitmap, call mark_all_vars_used on all used global vars from unexpanded_var_list and only purge global vars that weren't found used even during that step. * gcc.dg/pr33645-1.c: New test. * gcc.dg/pr33645-2.c: New test. * gcc.dg/pr33645-3.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr33645-1.c trunk/gcc/testsuite/gcc.dg/pr33645-2.c trunk/gcc/testsuite/gcc.dg/pr33645-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-live.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33645
[Bug target/33743] unwinding through signal frame
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2007-10-12 08:25 --- > gcc-4.1 with patch from PR26208 doesn't support > unwinding through signal frames. > > $ uname -a > SunOS hermes 5.9 Generic_117171-07 sun4u sparc SUNW,Sun-Blade-1500 This is not supported on Solaris. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet||*-*-solaris2.* GCC host triplet||*-*-solaris2.* GCC target triplet|sparc*-sun-solaris2.9 |*-*-solaris2.* Last reconfirmed|-00-00 00:00:00 |2007-10-12 08:25:13 date|| Summary|problem with unwinding |unwinding through signal |through signal frame. |frame http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33743
[Bug middle-end/26198] Unfolded comparison after cfg_cleanup
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-10-12 08:42 --- Subject: Bug 26198 Author: rguenth Date: Fri Oct 12 08:42:13 2007 New Revision: 129256 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129256 Log: 2007-10-12 Richard Guenther <[EMAIL PROTECTED]> PR middle-end/26198 * tree-ssa-forwprop.c (can_propagate_from): Do not propagate from a rhs with side-effects or which is a load. (forward_propagate_into_cond): Also try combining both operands. * gcc.dg/tree-ssa/forwprop-3.c: New testcase. * gcc.c-torture/execute/20071011-1.c: Likewise. * gcc.dg/tree-ssa/ssa-pre-9.c: Adjust. Added: trunk/gcc/testsuite/gcc.c-torture/execute/20071011-1.c trunk/gcc/testsuite/gcc.dg/tree-ssa/forwprop-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-pre-9.c trunk/gcc/tree-ssa-forwprop.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26198
[Bug c++/32121] [4.1/4.2 Regression] C++ front-end accepts invalid __label__ declarations
--- Comment #5 from jakub at gcc dot gnu dot org 2007-10-12 08:36 --- Fixed on the trunk. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.0.1 4.1.0 4.2.0 4.3.0 |4.0.1 4.1.0 4.2.0 Known to work|3.3.3 |3.3.3 4.3.0 Summary|[4.1/4.2/4.3 Regression] C++|[4.1/4.2 Regression] C++ |front-end accepts invalid |front-end accepts invalid |__label__ declarations |__label__ declarations http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32121
[Bug tree-optimization/33645] [4.3 Regression] undefined static variable in vortex for -fno-unit-at-a-time
--- Comment #2 from jakub at gcc dot gnu dot org 2007-10-12 08:33 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33645
[Bug tree-optimization/33619] [4.1/4.2/4.3 Regression] TER breaks some inline-asm code (again)
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||10/msg00688.html Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-10-12 08:35:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33619
[Bug tree-optimization/33742] Segfault in vectorizable_operation
--- Comment #3 from uros at gcc dot gnu dot org 2007-10-12 08:37 --- Subject: Bug 33742 Author: uros Date: Fri Oct 12 08:37:17 2007 New Revision: 129255 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129255 Log: PR tree-optimization/33742 * tree-vect-transform.c (vectorizable_operation): Return false if get_vectype_for_scalar_type for scalar_dest can't be determined. (vectorizable_call): Same for rhs_type and lhs_type. testsuite/ChangeLog: PR tree-optimization/33742 * gcc.dg/pr33742.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/pr33742.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-transform.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33742
[Bug middle-end/26198] Unfolded comparison after cfg_cleanup
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-10-12 08:42 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26198
[Bug tree-optimization/33742] Segfault in vectorizable_operation
--- Comment #4 from ubizjak at gmail dot com 2007-10-12 09:08 --- Fixed. [Let's see if this patch also fixes 174.gcc PEAK failure at http://vmakarov.fedorapeople.org/spec/index.html] -- ubizjak at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33742
[Bug tree-optimization/33742] Segfault in vectorizable_operation
-- ubizjak at gmail dot com changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33742
[Bug middle-end/24639] [meta-bug] bug to track all uninit variable issues
--- Comment #6 from manu at gcc dot gnu dot org 2007-10-12 09:44 --- I am collecting all info about Wuninitialized issues and proposals to solve them here: http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings Feel free to comment and contribute. The Summer of Code passed (unfortunately, I didn't have enough time to succeed) but the project goes on. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug c++/33744] function-style cast not allowed in template argument
--- Comment #1 from bangerth at dealii dot org 2007-10-12 12:52 --- It's not the parentheses or the greater-than sign, but the cast that triggers the error. I will have to look up whether a cast is allowed here. For reference, icc accepts the code. W. -- bangerth at dealii dot org changed: What|Removed |Added Summary|> within function-style cast|function-style cast not |incorrectly parsed as |allowed in template argument |closing template angle | |bracket | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33744
[Bug c/33748] format warnings don't take input charset into account
--- Comment #1 from jsm28 at gcc dot gnu dot org 2007-10-12 12:39 --- Remember that as an additional complication, format strings are a mixture of bytes and multibyte characters rather than simple sequences of multibyte characters. http://groups.google.com/group/comp.std.c/msg/64e8f56eb1697a4d -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added CC|jsm28 at gcc dot gnu dot org| BugsThisDependsOn||20110 Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-10-12 12:39:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33748
[Bug debug/33739] Failure of gfortran.dg/literal_character_constant_1_*.F with -m64 -g on Darwin
--- Comment #3 from dominiq at lps dot ens dot fr 2007-10-12 13:44 --- > Have you tried building gcc trunk with the Xcode 2.5 Developer Preview ...? No, I am at 2.4.1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33739
[Bug target/31990] udivdi3 not found for linux kernel
--- Comment #12 from rguenth at gcc dot gnu dot org 2007-10-12 13:44 --- *** This bug has been marked as a duplicate of 32044 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31990
[Bug fortran/33686] FORALL loop gives wrong result
--- Comment #10 from pault at gcc dot gnu dot org 2007-10-12 13:26 --- (In reply to comment #9) > Are the codes in #7 and #8 supposed to behave differently? In the case where the FORALL only fills part of the array P, yes. Paul PS I am just about to prepare a corresponding PR for assignments. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33686
[Bug debug/33739] Failure of gfortran.dg/literal_character_constant_1_*.F with -m64 -g on Darwin
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2007-10-12 13:08 --- This problem doesn't exist on powerpc-apple-darwin9. Have you tried building gcc trunk with the Xcode 2.5 Developer Preview under powerpc-apple-darwin8 to see if its cctools solves the issue there? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33739
[Bug c++/33744] [4.1/4.2/4.3 regression] function-style cast and '>' not allowed in template argument
--- Comment #4 from bangerth at dealii dot org 2007-10-12 15:21 ---
(In reply to comment #3)
> (I'm told that) these two function-style casts compile fine on 4.2.1:
>
> template
> struct A {
> };
>
> A y;
> A z;
Uh, indeed, I see. This is weird indeed. So in other words, these codes
compile:
--
template struct A {};
A a;
A b;
A<(bool)(1>2)> c;
--
but this one doesn't:
--
template struct A {};
A2)> b;
--
This is indeed very weird: it only fails with the function-style cast
and the greater-than sign...
Since this worked in gcc 3.3, this is a regression.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||rejects-valid
Known to fail||4.1.2 4.2.0 4.3.0
Known to work||3.3.6
Last reconfirmed|-00-00 00:00:00 |2007-10-12 15:21:49
date||
Summary|function-style cast not |[4.1/4.2/4.3 regression]
|allowed in template argument|function-style cast and '>'
||not allowed in template
||argument
Target Milestone|--- |4.2.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33744
[Bug c++/33750] initialization of non-integral member constant not rejected
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-10-12 15:20 --- What probably adds to the confusion is that C++ defaults to give errors for pedwarns but has pedantic = 0. But it is only possible to re-set pedantic-errors with -fpermissive. So to get plain -pedantic you need -pedantic -fpermissive for C++ while -pedantic-errors works as expected. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33750
[Bug fortran/33749] Wrong evaluation of expressions in lhs of assignment statements
--- Comment #1 from burnus at gcc dot gnu dot org 2007-10-12 15:18 --- I want to add that I cannot reproduce it on x86-64/Linux with -m64 -- only with -m32. Other than that, I agree that this is a bug. -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-10-12 15:18:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33749
[Bug c++/33750] initialization of non-integral member constant not rejected
--- Comment #7 from bangerth at dealii dot org 2007-10-12 15:16 --- This used to be a GCC extension in the old days, which may explain why it isn't rejected by default. I believe it was deprecated several releases ago, you may find something to that effect in release notes... W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33750
[Bug c++/33750] initialization of non-integral member constant not rejected
--- Comment #6 from manu at gcc dot gnu dot org 2007-10-12 15:09 --- (In reply to comment #4) > We should also warn by default with -std=c++98 or -std=c++0x. > Why? Note that gnu++98 rejects more programs than c++98, sine the latter admits constructions that conflict with the GNU C++ language. Joseph explained it in PR28368. That is how "-std" works right now, but that PR is still open. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33750
[Bug c++/33744] [4.1/4.2/4.3 regression] function-style cast and '>' not allowed in template argument
--- Comment #5 from mdorey at bluearc dot com 2007-10-12 17:11 --- Adding extra parentheses, such that "bool (2 > 1)" becomes "bool ((2 > 1 ))", is a work-around. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33744
[Bug c++/33754] New: Default argument of type list < pair < A, B > > compiles only when typedef is used
The following code does not compile:
#include
#include
using namespace std;
class A
{
typedef list < pair > PairList;
// Works
void f1 ( list < pair > arg = PairList() )
{
}
// Does not work
void f2 ( list < pair > arg = list < pair > () )
{
}
};
testcase.cpp:14: error: expected , or ... before > token
testcase.cpp:14: error: wrong number of template arguments (1, should be 2)
/usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../include/c++/4.1.2/bits/stl_pair.h:68:
error: provided for template struct std::pair
testcase.cpp:14: error: template argument 1 is invalid
testcase.cpp:14: error: template argument 2 is invalid
testcase.cpp:14: error: default argument missing for parameter 2 of void
A::f2(std::list, std::allocator > >,
int)
--
Summary: Default argument of type list < pair < A, B > > compiles
only when typedef is used
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: photon at seznam dot cz
GCC host triplet: Ubuntu Linux 7.04
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33754
[Bug c++/26698] [4.0/4.1/4.2/4.3 Regression] g++ accepts const-incorrect code due to conversion function
--- Comment #13 from simartin at gcc dot gnu dot org 2007-10-12 18:43 --- Subject: Bug 26698 Author: simartin Date: Fri Oct 12 18:43:33 2007 New Revision: 129274 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129274 Log: gcc/cp/ 2007-10-12 Simon Martin <[EMAIL PROTECTED]> PR c++/26698 * call.c (build_user_type_conversion_1): Do not consider conversion functions to convert a (possibly cv-qualified) object to the (possibly cv-qualified) same object type (or a reference to it), to a (possibly cv-qualified) base class of that type (or a reference to it). gcc/testsuite/ 2007-10-12 Simon Martin <[EMAIL PROTECTED]> PR c++/26698 * g++.dg/conversion/op4.C: New test. Added: trunk/gcc/testsuite/g++.dg/conversion/op4.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26698
[Bug target/33755] New: Gcc 4.2.2 broken for mips linux kernel builds
As noted in: http://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-mips&i=20071012172254.GA10835%40linux-mips.org GCC + binutils-2.18 cannot build the mips linux kernel. There is the possibility of this being a binutils bug. -- Summary: Gcc 4.2.2 broken for mips linux kernel builds Product: gcc Version: 4.2.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: daney at gcc dot gnu dot org GCC target triplet: mipsel-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33755
[Bug c++/33754] Default argument of type list < pair < A, B > > compiles only when typedef is used
--- Comment #1 from pcarlini at suse dot de 2007-10-12 18:31 --- *** This bug has been marked as a duplicate of 57 *** -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33754
[Bug fortran/33542] gfortran does not detect ambigious specific names if they are the same as generic names
--- Comment #9 from pault at gcc dot gnu dot org 2007-10-12 16:52 --- Subject: Bug 33542 Author: pault Date: Fri Oct 12 16:51:53 2007 New Revision: 129268 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129268 Log: 2007-10-12 Paul Thomas <[EMAIL PROTECTED]> PR fortran/33542 * resolve.c (resolve_actual_arglist): If the actual argument is ambiguous, then there is an error. 2007-10-12 Paul Thomas <[EMAIL PROTECTED]> PR fortran/33542 * gfortran.dg/ambiguous_specific_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/ambiguous_specific_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33542
[Bug fortran/33664] crash on invalid program
--- Comment #5 from pault at gcc dot gnu dot org 2007-10-12 16:45 --- Subject: Bug 33664 Author: pault Date: Fri Oct 12 16:45:46 2007 New Revision: 129267 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129267 Log: 2007-10-12 Paul Thomas <[EMAIL PROTECTED]> PR fortran/33664 * expr.c (gfc_specification_expr): If a function is not external, intrinsic or pure is an error. Set the symbol pure to prevent repeat errors. 2007-10-12 Paul Thomas <[EMAIL PROTECTED]> PR fortran/33664 * gfortran.dg/impure_spec_expr_1.f90: New test. * gfortran.dg/char_result_7.f90: Remove illegal test. Added: trunk/gcc/testsuite/gfortran.dg/impure_spec_expr_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/char_result_7.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33664
[Bug c++/33750] initialization of non-integral member constant not rejected
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-10-12 16:31 --- try a dup of bu 11393? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33750
[Bug c++/33750] initialization of non-integral member constant not rejected
--- Comment #10 from pcarlini at suse dot de 2007-10-12 16:29 --- Related to PR11393 ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33750
[Bug fortran/33753] New: gfortran treads known-to-be-contiguous array as having strides
Assume a module with the following definitions:
(a) real, allocatable, dimension(:) :: array
or
(b) real, dimension(500) :: array
Both arrays are contiguous as one cannot allocate strides
allocate(array(1:1000:2)) ! invalid
Thus: Only pointers or dummy arguments can have strides.
If one accesses the array in a loop, this can slow down the calculation
considerably.
Test case:
module a
implicit none
real, dimension(500) :: array
! real, allocatable, dimension(:) :: array
contains
subroutine test(x,n)
integer :: n, i
real :: x(n)
!allocate(array(1:500))
do i = 1, n
x(i) = array(i)
end do
end subroutine test
end module a
end
>From the dump difference:
- (*x)[(int8) i + -1] = array[(int8) i + -1];
+ (*x)[(int8) i + -1] = (*(real4[0:] *) array.data)[(int8) i *
array.dim[0].stride + array.offset];
Full example, see:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/8fac8fcf6e93fba7/
("Program slowdown when calling function with dynamic arrays" by Paul Hilscher)
--
Summary: gfortran treads known-to-be-contiguous array as having
strides
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33753
[Bug rtl-optimization/11001] global register %edi versus string builtins
--- Comment #13 from froydnj at gcc dot gnu dot org 2007-10-12 16:12 --- Subject: Bug 11001 Author: froydnj Date: Fri Oct 12 16:12:45 2007 New Revision: 129265 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129265 Log: gcc/ PR 11001 * config/i386/i386.md (strmov): Check for esi and edi usage. * config/i386/i386.c (decide_alg): Check whether we can use a rep prefix and adjust algorithm choice accordingly. (ix86_expand_strlen): Check for eax, ecx, and edi usage. gcc/testsuite/ PR 11001 * gcc.target/i386/pr11001-strlen-1.c: New testcase. * gcc.target/i386/pr11001-strlen-2.c: New testcase. * gcc.target/i386/pr11001-strlen-3.c: New testcase. * gcc.target/i386/pr11001-memset-1.c: New testcase. * gcc.target/i386/pr11001-memset-2.c: New testcase. * gcc.target/i386/pr11001-memset-3.c: New testcase. * gcc.target/i386/pr11001-memcpy-1.c: New testcase. * gcc.target/i386/pr11001-memcpy-2.c: New testcase. * gcc.target/i386/pr11001-memcpy-3.c: New testcase. Added: trunk/gcc/testsuite/gcc.target/i386/pr11001-memcpy-1.c trunk/gcc/testsuite/gcc.target/i386/pr11001-memcpy-2.c trunk/gcc/testsuite/gcc.target/i386/pr11001-memcpy-3.c trunk/gcc/testsuite/gcc.target/i386/pr11001-memset-1.c trunk/gcc/testsuite/gcc.target/i386/pr11001-memset-2.c trunk/gcc/testsuite/gcc.target/i386/pr11001-memset-3.c trunk/gcc/testsuite/gcc.target/i386/pr11001-strlen-1.c trunk/gcc/testsuite/gcc.target/i386/pr11001-strlen-2.c trunk/gcc/testsuite/gcc.target/i386/pr11001-strlen-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/i386.md trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11001
[Bug c++/33752] New: gcc forgets about noreturn in this code
In the attached program, Beta::~Beta() is noreturn. gcc is smart enough to figure out the noreturn in DeltaOne and DeltaTwo, but forgets about noreturn in DeltaThree and issues an unwanted warning. [EMAIL PROTECTED]:~/exp-non-void$ /home/mec/gcc-4.1.1/install/bin/g++ -Wall -c z4.cc z4.cc: In function 'bool DeltaTwo(bool)': z4.cc:28: warning: unused variable 'b2' z4.cc: In function 'bool DeltaThree(bool)': z4.cc:42: warning: control reaches end of non-void function [EMAIL PROTECTED]:~/exp-non-void$ /home/mec/gcc-4.2.1/install/bin/g++ -Wall -c z4.cc z4.cc: In function 'bool DeltaTwo(bool)': z4.cc:28: warning: unused variable 'b2' z4.cc: In function 'bool DeltaThree(bool)': z4.cc:42: warning: control reaches end of non-void function [EMAIL PROTECTED]:~/exp-non-void$ /home/mec/gcc-4.3-20070914/install/bin/g++ -Wall -c z4.cc z4.cc: In function 'bool DeltaTwo(bool)': z4.cc:28: warning: unused variable 'b2' z4.cc: In function 'bool DeltaThree(bool)': z4.cc:42: warning: control reaches end of non-void function -- Summary: gcc forgets about noreturn in this code Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mec at google dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33752
[Bug rtl-optimization/33676] libgfortran bootstrap failure: selected_int_kind.f90:22: Segmentation fault, wrong code with -fomit-frame-pointer
--- Comment #25 from gerald at pfeifer dot com 2007-10-12 15:40 --- Confirming as fixed on i386-unknown-freebsd54, the originally failing platform. -- gerald at pfeifer dot com changed: What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33676
[Bug fortran/33749] Wrong evaluation of expressions in lhs of assignment statements
--- Comment #2 from dominiq at lps dot ens dot fr 2007-10-12 15:23 --- The same on PPC Darwin: pr33749 with -m64 gives the expected result, but pr33686 gives the same result for 32 and 64 bit modes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33749
[Bug rtl-optimization/33638] [4.3 regression] wrong code with -O2 -fforce-addr
--- Comment #27 from manfred99 at gmx dot ch 2007-10-12 15:28 --- With gcc of today (patched tree-ssa-forwprop.c to make it bootstrap): # gfortran -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gfortran-source/gcc/configure --enable-languages=fortran --disable-nls --disable-multilib --enable-checking=release --prefix=/usr/local/gfortran-test Thread model: posix gcc version 4.3.0 20071012 (experimental) [trunk revision 129260] (GCC) The original program works fine now, the bugzilla testcase too, both with and without "-fforce-addr". I'm not able to trigger this wrong-code issue with this new version now. Note: the testcase gives different output, as meanwhile in gfortran the default precision for outputs has been increased. The actual values are the same though. Thanks a lot! -- manfred99 at gmx dot ch changed: What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33638
[Bug c++/33750] initialization of non-integral member constant not rejected
--- Comment #5 from manu at gcc dot gnu dot org 2007-10-12 14:59 ---
(In reply to comment #3)
>
> the first error message is always an error:
>
> static bool
> cp_parser_non_integral_constant_expression (cp_parser *parser,
> const char *thing)
> {
> parser->non_integral_constant_expression_p = true;
> if (parser->integral_constant_expression_p)
> {
> if (!parser->allow_non_integral_constant_expression_p)
> {
> error ("%s cannot appear in a constant-expression", thing);
> return true;
>
It seems that "-pedantic" is affecting
parser->allow_non_integral_constant_expression_p somehow. Weird.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33750
[Bug c++/33750] initialization of non-integral member constant not rejected
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-10-12 14:45 ---
>From diagnostic.c:
/* A "pedantic" warning: issues a warning unless -pedantic-errors was
given on the command line, in which case it issues an error. Use
this for diagnostics required by the relevant language standard,
if you have chosen not to make them errors.
Note that these diagnostics are issued independent of the setting
of the -pedantic command-line switch. To get a warning enabled
only with that switch, write "if (pedantic) pedwarn (...);" */
void
pedwarn (const char *gmsgid, ...)
{
But from c-opts.c:
/* Adjust various flags for C++ based on command-line settings. */
if (c_dialect_cxx ())
{
if (!flag_permissive)
{
flag_pedantic_errors = 1;
cpp_opts->pedantic_errors = 1;
}
the first error message is always an error:
static bool
cp_parser_non_integral_constant_expression (cp_parser *parser,
const char *thing)
{
parser->non_integral_constant_expression_p = true;
if (parser->integral_constant_expression_p)
{
if (!parser->allow_non_integral_constant_expression_p)
{
error ("%s cannot appear in a constant-expression", thing);
return true;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33750
[Bug rtl-optimization/33676] libgfortran bootstrap failure: selected_int_kind.f90:22: Segmentation fault, wrong code with -fomit-frame-pointer
--- Comment #24 from zadeck at naturalbridge dot com 2007-10-12 14:38
---
Subject: Re: libgfortran bootstrap failure: selected_int_kind.f90:22:
Segmentation fault, wrong code with -fomit-frame-pointer
Eric Botcazou wrote:
>> 2007-10-11 Kenneth Zadeck <[EMAIL PROTECTED]>
>>
>> PR middle-end/33676
>> * global.c (build_insn_chain): Include insn that occur between
>> basic blocks.
>>
>
> Who approved this patch?
>
>
>> However, the reload_insn_chain actually needs the insns that appear
>> between basic blocks, in particular the labels in front of branch
>> tables. I added code here to check for insns that may be in front of a
>> basic block after scanning that block.
>>
>> There are a lot of ways that I could have done this, for instance, I
>> could have just written in terms of the PREV_INSN as the old code was.
>> I think that in doing it the way that i have done it, it is obvious what
>> needs to be done if someone really does get rid of the branch tables
>> between the blocks.
>>
>
> Sure, but the code in build_insn_chain is now more convoluted than in the
> original version (and twice as big). And, please, fix the formatting.
>
>
it was approved by seonbae, a register allocation reviewer.The
reason that it is longer is that it is more precise. The code to
properly handle subregs, as well as properly dealing with registers live
thru insns, accounts for most of the expansion over the old code.
formatting fixes committed as revision 129262.
kenny
Index: global.c
===
--- global.c(revision 129260)
+++ global.c(working copy)
@@ -1358,6 +1358,8 @@ mark_elimination (int from, int to)
}
}
+/* Print chain C to FILE. */
+
static void
print_insn_chain (FILE *file, struct insn_chain *c)
{
@@ -1366,6 +1368,9 @@ print_insn_chain (FILE *file, struct ins
bitmap_print (file, &c->dead_or_set, "dead_or_set: ", "\n");
}
+
+/* Print all reload_insn_chains to FILE. */
+
static void
print_insn_chains (FILE *file)
{
@@ -1373,8 +1378,11 @@ print_insn_chains (FILE *file)
for (c = reload_insn_chain; c ; c = c->next)
print_insn_chain (file, c);
}
+
+
/* Walk the insns of the current function and build reload_insn_chain,
and record register life information. */
+
static void
build_insn_chain (void)
{
@@ -1450,7 +1458,7 @@ build_insn_chain (void)
{
if (regno < FIRST_PSEUDO_REGISTER)
{
- if (! fixed_regs[regno])
+ if (!fixed_regs[regno])
bitmap_set_bit (&c->dead_or_set, regno);
}
else if (reg_renumber[regno] >= 0)
@@ -1461,16 +1469,20 @@ build_insn_chain (void)
&& (!DF_REF_FLAGS_IS_SET (def, DF_REF_CONDITIONAL)))
{
rtx reg = DF_REF_REG (def);
+
/* We can model subregs, but not if they are
wrapped in ZERO_EXTRACTS. */
if (GET_CODE (reg) == SUBREG
&& !DF_REF_FLAGS_IS_SET (def, DF_REF_EXTRACT))
{
unsigned int start = SUBREG_BYTE (reg);
- unsigned int last = start + GET_MODE_SIZE (GET_MODE
(reg));
+ unsigned int last = start
+ + GET_MODE_SIZE (GET_MODE (reg));
- ra_init_live_subregs (bitmap_bit_p
(live_relevant_regs, regno),
- live_subregs,
live_subregs_used,
+ ra_init_live_subregs (bitmap_bit_p
(live_relevant_regs,
+ regno),
+ live_subregs,
+ live_subregs_used,
regno, reg);
/* Ignore the paradoxical bits. */
if ((int)last > live_subregs_used[regno])
@@ -1535,7 +1547,7 @@ build_insn_chain (void)
{
if (regno < FIRST_PSEUDO_REGISTER)
{
- if (! fixed_regs[regno])
+ if (!fixed_regs[regno])
bitmap_set_bit (&c->dead_or_set, regno);
}
else if (reg_renumber[regno] >= 0)
@@ -1548,10 +1560,13 @@ build_insn_chain (void)
&& !DF_REF_FLAGS_IS_SET (use, DF_REF_EXTRACT))
{
unsigned int start = SUBREG_BYTE (reg);
- unsigned int last = start + GET_MODE_SIZE (GET_MODE
(reg));
+ unsigned int last =
[Bug fortran/33686] FORALL loop gives wrong result
--- Comment #11 from dominiq at lps dot ens dot fr 2007-10-12 13:47 --- > In the case where the FORALL only fills part of the array P, yes. If you mean, say "FORALL(I=2:3)", you are right! I overlooked this possibility. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33686
[Bug middle-end/32044] udivdi3 counterproductive, unwarranted use
--- Comment #17 from rguenth at gcc dot gnu dot org 2007-10-12 13:44 --- *** Bug 31990 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
[Bug tree-optimization/33434] [4.3 Regression] -fipa-cp miscompilation
--- Comment #2 from jakub at gcc dot gnu dot org 2007-10-12 13:38 ---
Doesn't seem to look like a problem in ipa-cp to me, more like an inlining bug.
ipa-cp creates:
T.1 (a, b)
{
_Bool D.1565;
:
if (1)
goto ;
else
goto ;
:
# b_3 = PHI <1(2)>
goto ;
:
k ={v} 1;
:
# b_2 = PHI
b_1 = b_2 + -1;
if (b_2 != 0)
goto ;
else
goto ;
:
if (0)
goto ;
else
goto ;
:
__builtin_abort ();
:
return;
}
and even the first dump during apply_inline looks correct, inside of main we
have:
...
# BLOCK 4 freq:4999
# b_6 = PHI <1(3)>
goto ;
# BLOCK 5 freq:1
k ={v} 1;
# BLOCK 6 freq:1
# b_5 = PHI
b_4 = b_5 + -1;
if (b_5 != 0)
goto ;
else
goto ;
But during inlining both a and b are mark_sym_for_renaming and when update_ssa
is called, rewrite_update_stmt -> maybe_replace_use changes that
if (b_5 != 0)
into incorrect:
if (b_4 != 0)
so k is never set to 1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33434
[Bug c++/33750] New: initialization of non-integral member constant not rejected
struct foo
{
static const float bar = 1.2;
};
is accepted without a warning. It is rejected with -pedantic.
from cp/decl.c:
else if (pedantic && !INTEGRAL_TYPE_P (type))
pedwarn ("ISO C++ forbids initialization of member constant "
"%qD of non-integral type %qT", decl, type);
why do we guard the pedwarn with if (pedantic)??
--
Summary: initialization of non-integral member constant not
rejected
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: accepts-invalid, diagnostic
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33750
[Bug target/33704] AIX runs c++ constructors in incorrect order
--- Comment #18 from dje at gcc dot gnu dot org 2007-10-12 12:56 --- I think your patch would be okay as an option. Do you plan to support lazy binding as well? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33704
[Bug rtl-optimization/33676] libgfortran bootstrap failure: selected_int_kind.f90:22: Segmentation fault, wrong code with -fomit-frame-pointer
--- Comment #23 from ebotcazou at libertysurf dot fr 2007-10-12 12:56 --- Subject: Re: libgfortran bootstrap failure: selected_int_kind.f90:22: Segmentation fault, wrong code with -fomit-frame-pointer > 2007-10-11 Kenneth Zadeck <[EMAIL PROTECTED]> > > PR middle-end/33676 > * global.c (build_insn_chain): Include insn that occur between > basic blocks. Who approved this patch? > However, the reload_insn_chain actually needs the insns that appear > between basic blocks, in particular the labels in front of branch > tables. I added code here to check for insns that may be in front of a > basic block after scanning that block. > > There are a lot of ways that I could have done this, for instance, I > could have just written in terms of the PREV_INSN as the old code was. > I think that in doing it the way that i have done it, it is obvious what > needs to be done if someone really does get rid of the branch tables > between the blocks. Sure, but the code in build_insn_chain is now more convoluted than in the original version (and twice as big). And, please, fix the formatting. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33676
[Bug c/33748] New: format warnings don't take input charset into account
The following program should not fail with "-Werror -Wformat
-finput-charset=ISO-2022-JP -fexec-charset=ISO-2022-JP":
#include
int main()
{
printf ("\x1B$B%s\x1B(B");
}
because the %s is part of a multi-byte character sequence representing the
Unicode character U+3263 (KATAKANA LETTER BI).
--
Summary: format warnings don't take input charset into account
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33748
[Bug rtl-optimization/33676] libgfortran bootstrap failure: selected_int_kind.f90:22: Segmentation fault, wrong code with -fomit-frame-pointer
--- Comment #22 from zadeck at naturalbridge dot com 2007-10-12 11:59 --- it seems to be clean now. -- zadeck at naturalbridge dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33676
[Bug c++/14912] Do not print default template arguments in error messages
--- Comment #35 from pcarlini at suse dot de 2007-10-12 11:04 --- *** Bug 33747 has been marked as a duplicate of this bug. *** -- pcarlini at suse dot de changed: What|Removed |Added CC||pluto at agmk dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
[Bug c++/33747] [diagnostics] don't report default template parameters.
--- Comment #1 from pcarlini at suse dot de 2007-10-12 11:04 --- *** This bug has been marked as a duplicate of 14912 *** -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33747
[Bug c++/33747] New: [diagnostics] don't report default template parameters.
please consider following testcase:
$ cat t.cpp
#include
#include
template < typename T, typename S = std::set< std::string >, int N = 1 >
struct X
{
virtual ~X() = 0;
};
void f()
{
X< float > x; // error here.
}
in the standard way g++ reports all template arguments
in diagnostics messages.
$ g++ t.cpp -Wall -c
t.cpp: In function 'void f()':
t.cpp:10: error: cannot declare variable 'x' to be of abstract type 'X, std::allocator >,
1>'
t.cpp:5: note: because the following virtual functions are pure within
'X,
std::allocator >, 1>':
t.cpp:6: note: X::~X() [with T = float, S = std::set, std::allocator >, int N = 1]
it hurts my eyes to read this.
tons of expanded arguments in boost/stlport diagnostics aren't so funny ;)
it would nice to see a magic -Whuman-readable;) option to enable more
human readable reporting, e.g.:
t.cpp: In function 'void f()':
t.cpp:10: error: cannot declare variable 'x' to be of abstract
type 'X'
t.cpp:5: note: because the following virtual functions are pure
within 'X':
t.cpp:6: note: X::~X() [with T = float, [defaults]]
is it possible to implement this in easy way?
--
Summary: [diagnostics] don't report default template parameters.
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at agmk dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33747
[Bug tree-optimization/23449] vortex fails without -fno-strict-aliasing
--- Comment #3 from ubizjak at gmail dot com 2007-10-12 10:16 --- *** Bug 31024 has been marked as a duplicate of this bug. *** -- ubizjak at gmail dot com changed: What|Removed |Added CC||kenneth dot hoste at elis ||dot ugent dot be http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23449
[Bug java/29587] jc1: out of memory allocating 4072 bytes after a total of 708630224 bytes
--- Comment #19 from cnstar9988 at gmail dot com 2007-10-12 09:56 --- (In reply to comment #18) > Created an attachment (id=13090) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13090&action=view) [edit] > A short java file, known to compile under jikes and NetBeans 5.5 > Simple test file demonstrating the bug gcc-4.2.2 $ gcc -v Using built-in specs. Target: hppa1.1-hp-hpux11.11 Configured with: ../src/configure --build=hppa1.1-hp-hpux11.11 --host=hppa1.1-hp-hpux11.11 --target=hppa1.1-hp-hpux11.11 --prefix=/opt/gcc-4.2.2/ilp32 --with-as=/opt/gcc-4.2.2/ilp32/bin/as --with-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld --disable-shared --disable-nls --enable-threads=posix --enable-languages=c,c++ Thread model: posix gcc version 4.2.2 I want to build gcj. jc1: out of memory allocating 4072 bytes after a total of 390681928 bytes -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29587
[Bug c++/57] [DR 325] GCC can't parse a non-parenthesized comma in a template-id within a default argument
--- Comment #34 from pcarlini at suse dot de 2007-10-12 18:31 --- *** Bug 33754 has been marked as a duplicate of this bug. *** -- pcarlini at suse dot de changed: What|Removed |Added CC||photon at seznam dot cz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57
[Bug c/31024] segfault for SPEC CPU2000 vortex with -O2
--- Comment #1 from ubizjak at gmail dot com 2007-10-12 10:16 --- *** This bug has been marked as a duplicate of 23449 *** -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31024
[Bug c++/33750] initialization of non-integral member constant not rejected
--- Comment #9 from gdr at cs dot tamu dot edu 2007-10-12 16:19 --- Subject: Re: initialization of non-integral member constant not rejected "rguenth at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | We should also warn by default with -std=c++98 or -std=c++0x. I agree that we should do something for -std=c++98. For -std=c++0x, I introduced the notion of `literal type' in C++0x so that you can actually do more folding at compile time (including objects of class types), and you can initialize constexpr static data member objects of literal type in class definition. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33750
[Bug c++/33756] New: make error compiling snes9x-1.51
* the exact version of GCC; (gcc -v) Reading specs from /usr/lib/gcc/i486-slackware-linux/4.1.2/specs Target: i486-slackware-linux Configured with: ../gcc-4.1.2/configure --prefix=/usr --enable-shared --enable-languages=ada,c,c++,fortran,java,objc --enable-threads=posix --enable-__cxa_atexit --disable-checking --with-gnu-ld --verbose --with-arch=i486 --target=i486-slackware-linux --host=i486-slackware-linux Thread model: posix gcc version 4.1.2 * the system type; (uname -a) Linux slackware 2.6.22.5 #1 Wed Aug 29 22:00:56 BRT 2007 i686 Intel(R) Celeron(R) M CPU440 @ 1.86GHz GenuineIntel GNU/Linux * the options given when GCC was configured/built; snes9x-1.51-src$ ./configure --with-netplay snes9x-1.51-src$ make * the complete command line that triggers the bug; * the compiler output (error messages, warnings, etc.); and g++ -fno-rtti -I. -Iunzip -Ii386 -c -O2 -fomit-frame-pointer -fno-exceptions -Wall -W -pedantic -Wno-unused-parameter -pipe -I. -Iunzip -Ii386 -DMITSHM -DCPU_SHUTDOWN -DSPC700_SHUTDOWN -DZSNES_FX -DEXECUTE_SUPERFX_PER_LINE -DZSNES_C4 -DUSE_THREADS -DSPC700_C -DNETPLAY_SUPPORT -DUNZIP_SUPPORT -DJMA_SUPPORT-DMMX -DSDD1_DECOMP -DCORRECT_VRAM_READS -DJOYSTICK_SUPPORT -DNO_INLINE_SET_GET -DNEW_COLOUR_BLENDING -DZLIB -DHAVE_LIBPNG -DHAVE_MKSTEMP -DUSE_DGA_EXTENSION -DUSE_VIDMODE_EXTENSION -DHAVE_STRINGS_H -DHAVE_SYS_IOCTL_H -DHAVE_STDINT_H -DRIGHTSHIFT_int8_IS_SAR -DRIGHTSHIFT_int16_IS_SAR -DRIGHTSHIFT_int32_IS_SAR -DRIGHTSHIFT_int64_IS_SAR -DRIGHTSHIFT_IS_SAR '-DACCEPT_SIZE_T=socklen_t' tile.cpp -o tile.o g++: Internal error: Morto (program cc1plus) Please submit a full bug report. See http://gcc.gnu.org/bugs.html> for instructions. make: ** [tile.o] Erro * the preprocessed file (*.i*) that triggers the bug, generated by adding -save-temps to the complete compilation command, or, in the case of a bug report for the GNAT front end, a complete set of source files (see below). Dont have this files. -- Summary: make error compiling snes9x-1.51 Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: joenio at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33756
[Bug fortran/33749] Wrong evaluation of expressions in lhs of assignment statements
--- Comment #3 from pault at gcc dot gnu dot org 2007-10-12 19:09 --- (In reply to comment #2) > The same on PPC Darwin: pr33749 with -m64 gives the expected result, but > pr33686 gives the same result for 32 and 64 bit modes. > Tobias and Dominique, You're right. The assignment even produces the temporary for the lhs index that it should. Now why on earth does this happen in 64bit mode an not in 32bit?? Try it; first you see it and then you don't Still worse, I failed to find any code that would make this possible!! OK I've got airport lounges and hotel rooms next week; I'll investigate then. Cheers Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33749
[Bug c++/33750] initialization of non-integral member constant not rejected
--- Comment #1 from manu at gcc dot gnu dot org 2007-10-12 14:27 --- (In reply to comment #0) > why do we guard the pedwarn with if (pedantic)?? > -pedantic Issue all the warnings demanded by strict ISO C and ISO C++ (...) Valid ISO C and ISO C++ programs should compile properly with or without this option (...). However, without this option, certain GNU extensions and traditional C and C++ fea‐ tures are supported as well. With this option, they are rejected. So I guess that the program compiles and does what it is intended (thus we don't warn by default) but ISO C++ requires a warning, thus -pedantic gives the warning. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33750
[Bug c++/33744] function-style cast not allowed in template argument
--- Comment #3 from mdorey at bluearc dot com 2007-10-12 13:19 ---
(I'm told that) these two function-style casts compile fine on 4.2.1:
template
struct A {
};
A y;
A z;
This is why I suggest the greater-than is a necessary part of the bug. Do you
have a counter-example, Wolfgang - where the greater-than sign isn't necessary
to cause the same failure?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33744
[Bug c++/33744] function-style cast not allowed in template argument
--- Comment #2 from bangerth at dealii dot org 2007-10-12 13:04 --- The rule for template non-type arguments of integral type is 14.3.2/1: 1 A template-argument for a non-type, non-template template-parameter shall be one of: -- an integral constant-expression of integral or enumeration type; ... Integral constant-expressions are dealt with in 5.19/1: Anintegral constant-expression can involve only literals (_lex.literal_), enumerators, const variables or static data members of integral or enumeration types initialized with constant expressions (_dcl.init_), non-type template parameters of integral or enumeration types, and sizeof expressions. Floating literals (_lex.fcon_) can appear only if they are cast to integral or enumeration types. Only type conversions to integral or enumeration types can be used. In particular, except in sizeof expressions, functions, class objects, pointers, or references shall not be used, and assignment, increment, decrement, function-call, or comma operators shall not be used. I do not know whether bool(1) is considered a function-call. Gcc rejects it as a template argument. However, it does accept (bool)1. W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33744
[Bug target/33755] Gcc 4.2.2 broken for mips linux kernel builds
--- Comment #2 from tbm at cyrius dot com 2007-10-12 19:30 --- Reducing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33755
[Bug debug/33739] Failure of gfortran.dg/literal_character_constant_1_*.F with -m64 -g on Darwin
--- Comment #4 from dominiq at lps dot ens dot fr 2007-10-12 19:51 --- > No, I am at 2.4.1. I have installed Xcode 2.5 and rebuilt gcc and gfortran, but it did not help!-(though I may have missed something else). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33739
[Bug tree-optimization/33757] [4.3 regression]: Revision 126149 fails gcc.dg/tree-ssa/ssa-fre-4.c
--- Comment #1 from hjl at lucon dot org 2007-10-12 19:41 --- Revision 128251 removed xfail, but didn't address Linux/ia64. -- hjl at lucon dot org changed: What|Removed |Added CC||rguenther at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33757
[Bug fortran/33749] New: Wrong evaluation of expressions in lhs of assignment statements
This is a similar problem to PR33686. $ cat test.f90 integer :: p(4) = (/2,4,1,3/) p(p) = (/(i, i = 1, 4)/) print *, p end $ ./a 3 1 4 3 7.5.1.5 Interpretation of intrinsic assignments Execution of an intrinsic assignment causes, in effect, the evaluation of the expression expressions within variable (7.1.7), the possible conversion of expr to the type and type of variable (Table 7.10), and the definition of variable with the resulting value. The execution assignment shall have the same effect as if the evaluation of all operations in expr occurred before any portion of variable is defined by the assignment. The evaluation within variable shall neither affect nor be affected by the evaluation of expr. No value variable if variable is of type character and zero length, or is an array of size zero. snip The processor may perform the element-by-element assignment in any order. I take all this to mean that expressions within variable must be evaluated before the assignment, so that the correct result should be $ ./a 3 1 4 2 Paul -- Summary: Wrong evaluation of expressions in lhs of assignment statements Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pault at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33749
[Bug tree-optimization/33757] New: [4.3 regression]: Revision 126149 fails gcc.dg/tree-ssa/ssa-fre-4.c
Revision 126149 fails gcc.dg/tree-ssa/ssa-fre-4.c on Linux/ia64: FAIL: gcc.dg/tree-ssa/ssa-fre-4.c scan-tree-dump Replaced \(char\) .*with -- Summary: [4.3 regression]: Revision 126149 fails gcc.dg/tree- ssa/ssa-fre-4.c Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org GCC target triplet: ia64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33757
[Bug tree-optimization/33757] [4.3 regression]: Revision 126149 fails gcc.dg/tree-ssa/ssa-fre-4.c
--- Comment #2 from hjl at lucon dot org 2007-10-12 19:45 ---
ssa-fre-4.c has
/* If the target returns false for TARGET_PROMOTE_PROTOTYPES, then there
will be no casts for FRE to eliminate and the test will fail. */
/* { dg-skip-if "no promotion to eliminate" { cris-*-* mmix-*-* } { "*" } { ""
}
} */
and ia64/ia64.c has
/* ??? Investigate. */
#if 0
#undef TARGET_PROMOTE_PROTOTYPES
#define TARGET_PROMOTE_PROTOTYPES hook_bool_tree_true
#endif
It looks like ia64 should be xfailed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33757
[Bug c++/33750] initialization of non-integral member constant not rejected
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-10-12 14:38 --- No, -pedantic gives an error. -pedantic -fpermissive gives a warning on the initialization but still an error on the FP literal: tmp> g++-4.3 -c t.C tmp> g++-4.3 -c t.C -pedantic t.C:3: error: floating-point literal cannot appear in a constant-expression t.C:3: error: ISO C++ forbids initialization of member constant 'bar' of non-integral type 'const float' tmp> g++-4.3 -c t.C -pedantic -fpermissive t.C:3: error: floating-point literal cannot appear in a constant-expression t.C:3: warning: ISO C++ forbids initialization of member constant 'bar' of non-integral type 'const float' so I cannot get only warnings for this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33750
[Bug target/33393] floatsisf2_sse_vector_nointernunit doesn't work on 32bit
--- Comment #2 from hjl at lucon dot org 2007-10-12 14:41 --- Fixed. -- hjl at lucon dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33393
[Bug c++/33750] initialization of non-integral member constant not rejected
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-10-12 14:46 --- We should also warn by default with -std=c++98 or -std=c++0x. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33750
[Bug target/33755] Gcc 4.2.2 broken for mips linux kernel builds
--- Comment #1 from tbm at cyrius dot com 2007-10-12 19:19 --- Created an attachment (id=14350) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14350&action=view) preprocessed source (sid)160:[EMAIL PROTECTED]: ~] gcc-4.2 -c -O2 -march=mips32r2 33755.i (sid)161:[EMAIL PROTECTED]: ~] ld -m elf32ltsmip -r 33755.o ld: 33755.o: Can't find matching LO16 reloc against `$LC6' for R_MIPS_GOT16 at 0x521490 in section `.text' (sid)162:[EMAIL PROTECTED]: ~] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33755
[Bug c++/33752] gcc forgets about noreturn in this code
--- Comment #1 from mec at google dot com 2007-10-12 16:08 --- Created an attachment (id=14349) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14349&action=view) Test program Compile with: g++ -Wall -c z4.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33752
[Bug fortran/31608] wrong types in character array/scalar binop
--- Comment #32 from pault at gcc dot gnu dot org 2007-10-12 17:32 --- (In reply to comment #31) > Works as advertised without regression so far (PPC Darwin, 32 bit mode close > to > complete), but for the codelets in #30. > > I wonder if the code in #28 is valid: the line(s) > > merge(transfer(string,"x",len(string)), string, .true.) > > does not seems to obey: > > 13.7.75 MERGE (TSOURCE, FSOURCE, MASK) > > ... > FSOURCE shall be of the same type and type parameters as TSOURCE. > > If I am not mistaken transfer(string,"x",len(string)) is an array of > characters > of rank one, size len(string), of character(1), while string is a scalar > character(20) (13.7.121 TRANSFER (SOURCE, MOLD [, SIZE]) ... Case (iii): If > SIZE is present, the result is an array of rank one and size SIZE.). > > The patched gfortran, Intel, and g95 accept the code and give the same result; > xlf accept the code, but gives some garbage in the first and fourth lines of > the output; Portland Group compiler rejects the code with: > > PGF90-S-0074-Illegal number or type of arguments to merge - keyword argument > fsource (pr31608_4.f90: 16) > > Should I fill another PR? > Yes, please It's an easy fix but let's do one thing at a time:-) Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608
[Bug tree-optimization/33383] [4.3 Regression] Revision 128092 miscompiles 400.perlbench
--- Comment #12 from jakub at gcc dot gnu dot org 2007-10-12 20:22 --- Trying to create self-contained testcase from it. So far I have found which function is miscompiled at -O2 (and not -O2 -fno-strict-aliasing) if only 3 other functions are inlined into it, the rest is noinline. Unfortunately the function is quite large. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33383
[Bug fortran/33745] -fbounds-check: Bogus out-of-bounds run-time error for assumed-size array
--- Comment #2 from burnus at gcc dot gnu dot org 2007-10-12 20:20 --- There is another bug (accepts-invalid): integer, intent(out) :: jp(2,*) jp(3,2:4)=0 which is not diagnosed at compile time. The wrong-code bug is fixed by the followed patch. Index: trans-array.c === --- trans-array.c (revision 129272) +++ trans-array.c (working copy) @@ -2870,7 +2870,7 @@ gfc_conv_ss_startstride (gfc_loopinfo * if (info->ref->u.ar.dimen_type[dim] != DIMEN_RANGE) continue; - if (n == info->ref->u.ar.dimen - 1 + if (n == info->ref->u.ar.dimen - 2 && (info->ref->u.ar.as->type == AS_ASSUMED_SIZE || info->ref->u.ar.as->cp_was_assumed)) check_upper = false; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33745
[Bug fortran/33753] gfortran treads known-to-be-contiguous array as having strides
--- Comment #1 from jb at gcc dot gnu dot org 2007-10-12 20:17 --- Gfortran should know that stride==1 for allocatables, as was suggested by Tomas Koenig in #32131, comment 5. *** This bug has been marked as a duplicate of 32131 *** -- jb at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33753
[Bug c++/33758] New: g++: Internal error
Target: i686-pc-linux-gnu Configured with: ../configure --prefix=/usr --enable-shared --enable-languages=c,c++ --enable-threads=posix --enable-__cxa_atexit --disable-multilib --libdir=/usr/lib --libexecdir=/usr/lib --enable-clocale=gnu --disable-libstdcxx-pch --with-tune=generic Thread model: posix gcc version 4.2.2 Command line g++ -v -save-temps -DHAVE_CONFIG_H -I. -I. -I../.. -I..-g -O2 -MT execute.lo -MD -MP -MF ".deps/execute.Tpo" -c -o execute.lo execute.cpp Output -- Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../configure --prefix=/usr --enable-shared --enable-languages=c,c++ --enable-threads=posix --enable-__cxa_atexit --disable-multilib --libdir=/usr/lib --libexecdir=/usr/lib --enable-clocale=gnu --disable-libstdcxx-pch --with-tune=generic Thread model: posix gcc version 4.2.2 /usr/lib/gcc/i686-pc-linux-gnu/4.2.2/cc1plus -E -quiet -v -I. -I. -I../.. -I.. -MD execute.d -MF .deps/execute.Tpo -MP -MT execute.lo -MQ execute.lo -D_GNU_SOURCE -DHAVE_CONFIG_H execute.cpp -mtune=generic -fworking-directory -O2 -fpch-preprocess -o execute.ii ignoring nonexistent directory "/usr/lib/gcc/i686-pc-linux-gnu/4.2.2/../../../../i686-pc-linux-gnu/include" ignoring duplicate directory "." ignoring duplicate directory "." #include "..." search starts here: #include <...> search starts here: . ../.. .. /home/ryuta/Development/include /usr/lib/gcc/i686-pc-linux-gnu/4.2.2/../../../../include/c++/4.2.2 /usr/lib/gcc/i686-pc-linux-gnu/4.2.2/../../../../include/c++/4.2.2/i686-pc-linux-gnu /usr/lib/gcc/i686-pc-linux-gnu/4.2.2/../../../../include/c++/4.2.2/backward /usr/local/include /usr/lib/gcc/i686-pc-linux-gnu/4.2.2/include /usr/include End of search list. /usr/lib/gcc/i686-pc-linux-gnu/4.2.2/cc1plus -fpreprocessed execute.ii -quiet -dumpbase execute.cpp -mtune=generic -auxbase-strip execute.lo -g -O2 -version -o execute.s GNU C++ version 4.2.2 (i686-pc-linux-gnu) compiled by GNU C version 4.2.2. GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=129240 Compiler executable checksum: d9c13861058dba829762c132b7d23093 In file included from execute.cpp:49: texture.h: In member function ‘virtual char* CTexture::getTextureType()’: texture.h:82: warning: deprecated conversion from string constant to ‘char*’ texture.h: In member function ‘virtual char* CEnvironment::getTextureType()’: texture.h:109: warning: deprecated conversion from string constant to ‘char*’ In file included from execute.cpp:538: scriptFunctions.h: In member function ‘void CShadingContext::execute(CProgrammableShaderInstance*, float**)’: scriptFunctions.h:923: warning: deprecated conversion from string constant to ‘char*’ scriptFunctions.h:993: warning: deprecated conversion from string constant to ‘char*’ In file included from scriptFunctions.h:1126, from execute.cpp:538: shaderFunctions.h:352: warning: deprecated conversion from string constant to ‘char*’ shaderFunctions.h:816: warning: deprecated conversion from string constant to ‘char*’ shaderFunctions.h:876: warning: deprecated conversion from string constant to ‘char*’ shaderFunctions.h:948: warning: deprecated conversion from string constant to ‘char*’ shaderFunctions.h:1017: warning: deprecated conversion from string constant to ‘char*’ In file included from shaderFunctions.h:2441, from scriptFunctions.h:1126, from execute.cpp:538: giFunctions.h:488: warning: deprecated conversion from string constant to ‘char*’ execute.cpp:540: warning: deprecated conversion from string constant to ‘char*’ In file included from execute.cpp:640: scriptFunctions.h:923: warning: deprecated conversion from string constant to ‘char*’ scriptFunctions.h:993: warning: deprecated conversion from string constant to ‘char*’ In file included from scriptFunctions.h:1126, from execute.cpp:640: shaderFunctions.h:352: warning: deprecated conversion from string constant to ‘char*’ In file included from shaderFunctions.h:2441, from scriptFunctions.h:1126, from execute.cpp:640: giFunctions.h:488: warning: deprecated conversion from string constant to ‘char*’ execute.cpp:642: warning: deprecated conversion from string constant to ‘char*’ In file included from execute.cpp:730: scriptFunctions.h:923: warning: deprecated conversion from string constant to ‘char*’ scriptFunctions.h:993: warning: deprecated conversion from string constant to ‘char*’ In file included from scriptFunctions.h:1126, from execute.cpp:730: shaderFunctions.h:352: warning: deprecated conversion from string constant to ‘char*’ In file included from shaderFunctions.h:2441, from scriptFunctions.h:1126, from execute.cpp:730: giFunctions.h:488: warning: deprecated conversion from string constant to ‘char*’ execute.cpp:732: warning: deprecated conversion from string constant to ‘char*’ g++: Internal error: Killed (program cc1plus) Please
[Bug c++/33758] g++: Internal error
--- Comment #1 from Oroppas at gmail dot com 2007-10-12 20:15 --- Created an attachment (id=14351) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14351&action=view) preprocessed file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33758
[Bug fortran/32131] knowing that stride==1 when using allocated arrays and escaping allocatable arrays
--- Comment #9 from jb at gcc dot gnu dot org 2007-10-12 20:17 --- *** Bug 33753 has been marked as a duplicate of this bug. *** -- jb at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32131
[Bug c++/33758] g++: Internal error
--- Comment #2 from Oroppas at gmail dot com 2007-10-12 20:17 --- cc1plus consumes more than 700MB of memory and eventually crashes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33758
[Bug fortran/31608] wrong types in character array/scalar binop
--- Comment #33 from dominiq at lps dot ens dot fr 2007-10-12 20:31 --- > It's an easy fix but let's do one thing at a time:-) Sure! I have filled PR33759 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608
[Bug target/33755] Gcc 4.2.2 broken for mips linux kernel builds
--- Comment #4 from daney at gcc dot gnu dot org 2007-10-12 20:44 --- Not that I have looked into the problem, but this sounds similar to this problem: http://sourceware.org/ml/binutils/2006-11/msg00059.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33755
[Bug fortran/33759] New: Unequal character lengths in MERGE intrinsic not detected in contained function.
In my comment 31 of PR31608, I have questionned the validity of the test case
in comment 28. Now I think the test is invalid, but not detected. First
consider the code:
character(len=20) :: string
character(len=1) :: tmp(20)
string = ""
tmp = ""
tmp = transfer(string,"x",len(string))
tmp = merge(tmp, string, .true.)
end
gfortran gives:
tmp = merge(tmp, string, .true.)
1
Error: Unequal character lengths (1 and 20) in MERGE intrinsic at (1)
Note that an error based on the shape would probably better. When using arrays
of real, I get:
Error: Different shape for arguments 'tsource' and 'fsource' for intrinsic
'merge' at (1) on dimension 1 (3 and 2)
Now consider the code
character(len=1) :: string = "z"
character(len=20) :: tmp = ""
tmp = Upper ("abcdefg")
print *, "'", tmp, "'"
contains
Character (len=20) Function Upper (string)
Character(len=*) string
character(len=1) :: tmp(20) = ""
tmp = transfer(string,"x",len(string))
tmp = merge(tmp, string, .true.)
Upper = transfer(tmp, "x")
return
end function Upper
end
gfortran compiles it without complain and gives
'a '
I think the above code is invalid in two counts:
(1) transfer(string,"x",len(string)) is a rank one array of size 7 and should
not be assigned to an array of size 20. I think this is quite difficult to
detect at compile time, but it would be nice to have it at runtime.
(2) merge(tmp, string, .true.) try to merge a rank one character array with a
rank zero string. If this invalid and detected in the first test above, it
should also be detected in the function, unless I am missing something.
--
Summary: Unequal character lengths in MERGE intrinsic not
detected in contained function.
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
GCC build triplet: powerpc-apple-darwin8
GCC host triplet: powerpc-apple-darwin8
GCC target triplet: powerpc-apple-darwin8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33759
[Bug target/33755] Gcc 4.2.2 broken for mips linux kernel builds
--- Comment #3 from tbm at cyrius dot com 2007-10-12 20:32 ---
/* Testcase by Martin Michlmayr <[EMAIL PROTECTED]> */
struct mtd_blktrans_ops
{
int (*readsect) (void);
int exiting;
};
static void do_blktrans_request (struct mtd_blktrans_ops *tr, long flags)
{
switch (flags & 1)
{
case 0:
if (tr->readsect ())
return;
case 1:
return;
default:
printk ("foo\n");
}
}
mtd_blktrans_thread (struct mtd_blktrans_ops *tr)
{
long flags;
while (!tr->exiting)
do_blktrans_request (tr, flags);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33755
[Bug target/33755] Gcc 4.2.2 broken for mips linux kernel builds
--- Comment #6 from daney at gcc dot gnu dot org 2007-10-12 21:06 --- >From the reduced testcase could you post the result of: objdump -r -j .text 33755.o Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33755
[Bug c++/33758] g++: Internal error
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-10-12 21:05 --- It doesn't crash but gets killed by your operating system kernel. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33758
[Bug c++/33756] make error compiling snes9x-1.51
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-10-12 21:03 --- You ran out of memory and the kernel decided to kill g++. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33756
[Bug target/33755] Gcc 4.2.2 broken for mips linux kernel builds
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-10-12 20:56 --- This does sound like an gas/ld issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33755
[Bug fortran/33759] Unequal character lengths in MERGE intrinsic not detected at run time
--- Comment #1 from burnus at gcc dot gnu dot org 2007-10-12 20:54 ---
> (1) transfer(string,"x",len(string)) is a rank one array of size 7 and should
> not be assigned to an array of size 20. I think this is quite difficult to
> detect at compile time, but it would be nice to have it at runtime.
NAG f95 agrees with this and prints at run time:
Rank 1 of array operand has extent 7 instead of 20
In UPPER, line 9 of test.f90
> (2) merge(tmp, string, .true.) try to merge a rank one character array with a
> rank zero string. If this invalid and detected in the first test above, it
> should also be detected in the function, unless I am missing something.
I think the rank is not a problem as MERGE is an ELEMENTAL function and a
scalar ("string") is conformable with any array (such as "tmp"). However, there
is the problem that the string length is not the same (1 and 7); NAG f95 prints
at run time:
Differing character lengths (1 and 7) in MERGE
In UPPER, line 10 of test.f90
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO||27766
nThis||
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
GCC build triplet|powerpc-apple-darwin8 |
GCC host triplet|powerpc-apple-darwin8 |
GCC target triplet|powerpc-apple-darwin8 |
Keywords||diagnostic
Last reconfirmed|-00-00 00:00:00 |2007-10-12 20:54:19
date||
Summary|Unequal character lengths in|Unequal character lengths in
|MERGE intrinsic not detected|MERGE intrinsic not detected
|in contained function. |at run time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33759
[Bug c++/33758] g++: Internal error
--- Comment #4 from Oroppas at gmail dot com 2007-10-12 21:36 --- Correct. A bug triggers g++ to eat up extremely large amount of memory. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33758
[Bug target/33755] Gcc 4.2.2 broken for mips linux kernel builds
--- Comment #7 from daney at gcc dot gnu dot org 2007-10-12 22:08 --- The reduced testcase is different than the reported problem. At a minimum the relocation types are different. Also the kernel is compiled with -G 0 -mno-abicalls If we compile the reduced testcase thusly: (sid)[EMAIL PROTECTED]:~/junk$ gcc-4.2 -c -O2 -G0 -mno-abicalls -march=mips32r2 j.c (sid)[EMAIL PROTECTED]:~/junk$ objdump -r j.o j.o: file format elf32-tradlittlemips RELOCATION RECORDS FOR [.text]: OFFSET TYPE VALUE 0068 R_MIPS_26 printk 0024 R_MIPS_HI16 $LC0 006c R_MIPS_LO16 $LC0 007c R_MIPS_26 .text (sid)[EMAIL PROTECTED]:~/junk$ ld -m elf32ltsmip -r j.o No errors. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33755
[Bug fortran/33759] Unequal character lengths in MERGE intrinsic not detected at run time
--- Comment #2 from dominiq at lps dot ens dot fr 2007-10-12 22:18 ---
Subject: Re: Unequal character lengths in MERGE intrinsic
not detected at run time
> scalar ("string") is conformable with any array (such as "tmp")
Yes, I missed that, so if the length of string is only known at runtime,
it can only be caught at run time, however the Portland Group Fortran
detects it at compile time (constant folding?).
Now I have another odd result: the following code
character(len=1) :: string = "z"
character(len=20) :: tmp = ""
tmp = Upper ("abcdefgh")
print *, tmp
contains
Character (len=20) Function Upper (string)
Character(len=*) string
print *, len(string)
print *, size(transfer(string,"xy",len(string)))
Upper = ""
Upper(1:2) =
&
transfer(merge(transfer(string,"xy",len(string)),&
string(1:2), .true.), "xy")
return
end function Upper
end
gives
8
8
ab
with xlf, g95, Intel and PGF, but gfortran gives:
8
4
ab
a bug or an ambiguity of the transfer definition?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33759
[Bug target/33755] Gcc 4.2.2 broken for mips linux kernel builds
--- Comment #8 from daney at gcc dot gnu dot org 2007-10-12 22:35 --- It appears to be a GCC bug not binutils: If you look at the assembly output for gcc-4.2, we emit: lui $2,%hi($LC6) But there is no corresponding %lo($LC6) to be found. No amount of relocation sorting could overcome this problem. The corresponding printk calls are also missing. Very strange. This is fixed in 4.3. (sid)[EMAIL PROTECTED]:~/junk$ gcc -c -O2 -G0 -mno-abicalls -march=mips32r2 33755.i (sid)[EMAIL PROTECTED]:~/junk$ ld -m elf32ltsmip -r 33755.o (sid)[EMAIL PROTECTED]:~/junk$ gcc --version gcc (GCC) 4.3.0 20071011 (experimental) [trunk revision 129239] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33755
[Bug middle-end/33714] [4.2 Regression] ivopts miscompiles insn-output.c
--- Comment #4 from rakdver at gcc dot gnu dot org 2007-10-12 22:27 --- Subject: Bug 33714 Author: rakdver Date: Fri Oct 12 22:26:47 2007 New Revision: 129277 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129277 Log: PR tree-optimization/33714 * tree-ssa-loop-ivopts.c (constant_multiple_of): Pass the arguments to division in the correct order. * gcc.dg/tree-ssa/pr33714.c: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/gcc.dg/tree-ssa/pr33714.c Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/testsuite/ChangeLog branches/gcc-4_2-branch/gcc/tree-ssa-loop-ivopts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33714
[Bug objc/24777] objc needs to use normal builtins for functions it declares
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-10-12 23:47 --- I am going to try to fix this over the weekend. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24777
[Bug target/33545] [4.3 regression] Bootstrap failure/broken exceptions on alpha/Tru64
--- Comment #1 from roger at eyesopen dot com 2007-10-13 04:14 --- Many thanks to Eric Botcazou! It turns out that this bug was a duplicate of PR target/32325. I can confirm that with Eric's fix, and once I'd committed my libstdc++ patch for the EOVERFLOW issue (mentioned by Eric in PR23225's comment #6), and Alex's SRA fixes stop miscompiling mips-tfile, that I can once again bootstrap mainline on alphaev67-dec-osf5.1! Thanks again to Eric for a speedy fix. I'm sorry that this was a dupe, and that it took a while for mainline to stablize to the point that I could confirm the problem is resolved. *** This bug has been marked as a duplicate of 32325 *** -- roger at eyesopen dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33545
[Bug target/32325] [4.3 Regression] cc1plus ICE configuring libstdc++ on Tru64 UNIX V5.1B: SEGV in rtl_verify_flow_info
--- Comment #7 from roger at eyesopen dot com 2007-10-13 04:14 --- *** Bug 33545 has been marked as a duplicate of this bug. *** -- roger at eyesopen dot com changed: What|Removed |Added CC||roger at eyesopen dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32325
[Bug c++/26698] [4.0/4.1/4.2/4.3 Regression] g++ accepts const-incorrect code due to conversion function
--- Comment #14 from simartin at gcc dot gnu dot org 2007-10-13 06:05 --- Subject: Bug 26698 Author: simartin Date: Sat Oct 13 06:04:57 2007 New Revision: 129282 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129282 Log: gcc/cp/ 2007-10-13 Simon Martin <[EMAIL PROTECTED]> PR c++/26698 * call.c (build_user_type_conversion_1): Do not consider conversion functions to convert a (possibly cv-qualified) object to the (possibly cv-qualified) same object type (or a reference to it), to a (possibly cv-qualified) base class of that type (or a reference to it). gcc/testsuite/ 2007-10-13 Simon Martin <[EMAIL PROTECTED]> PR c++/26698 * g++.dg/conversion/op4.C: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/conversion/op4.C Modified: branches/gcc-4_2-branch/gcc/cp/ChangeLog branches/gcc-4_2-branch/gcc/cp/call.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26698
[Bug c++/26698] [4.0/4.1/4.2/4.3 Regression] g++ accepts const-incorrect code due to conversion function
--- Comment #15 from simartin at gcc dot gnu dot org 2007-10-13 06:17 --- Fixed on all the active branches. -- simartin at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26698
