[Bug fortran/22304] gfortran silently changes values in equilvanence'd variables
--- Additional Comments From pault at gcc dot gnu dot org 2005-08-05 06:08 --- This is amusing. integer o(4), b, c COMMON /IBM/ o EQUIVALENCE (o(1),b),(C,o(4)) o(3)=1 CALL MYSUB1 CALL MYSUB2 END subroutine MYSUB1 integer o (4), b, c COMMON /IBM/ o EQUIVALENCE (o(1), b), (o(4), c) WRITE (6,*) "IN MYSUB1: o(3)= ", o(3) RETURN END subroutine MYSUB2 integer o (4), b, c COMMON /IBM/ o EQUIVALENCE (o(1), b), (c, o(4)) WRITE (6,*) "IN MYSUB2: o(3)= ", o(3) RETURN END IN MYSUB1: o(3)=0 IN MYSUB2: o(3)=134519416 The code shows that SUB1 references the common block, whereas SUB2 goes for a home grown equivalence. This is a good clue as to where things are failing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22304
[Bug fortran/22304] gfortran silently changes values in equilvanence'd variables
--- Additional Comments From pault at gcc dot gnu dot org 2005-08-05 05:47 --- > I am a little busy, but I might be able to try some more. > However, I have no real experience programming compilers, > and I don't think I understand the Join the club! > intended logic of the algorithms in the code which > I tweaked. Is there something I should have read > that would give me a clue? Unfortunately, no. I think that it is gong to take me a week or two to come to grips with how this should work. There are many other problems with modules/equivalences/common, which need to be sorted out together. Thank you again for your help. Paul T -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22304
[Bug libstdc++/15910] can't compile self defined void distance(std::vector, std::vector)
--- Additional Comments From adah at netstd dot com 2005-08-05 05:41 --- (In reply to comment #44) > | However, I still believe it is the problem of the compilers. > Please take ti to the C++ standard committee. The behaviour is that > described by the standard. If you don't like it, have the committee The behaviour I wanted is at least not *against* the standard, while being more natural and user-friendly. As James Kanze quoted §14.7.1/5 in comp.lang.c++.moderated: "If the overload resolution process can determine the correct function to call without instantiating a class template definition, it is unspecified whether that instantiation actually takes place." BTW, proposal N1799 directly addresses this problem and, if adopted, will make the program we are discussing legal instead of unspecified behaviour. > change it. If you think name lookup is an easy exercise, give it a try. I never thought any part of a C++ compiler is easy. I just try to express my opinions on this subject, as a common gcc user (I myself do *not* define any functions named distance). > -- Gaby Yongwei -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910
[Bug fortran/22010] Namelists defined in modules not handled properly
--- Additional Comments From pault at gcc dot gnu dot org 2005-08-05 05:36 --- I think that 4.0 opened and closed more than once since I promised to complete this! Fixed on mainline and 4.02 -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22010
[Bug fortran/22010] Namelists defined in modules not handled properly
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-05 05:32 --- Subject: Bug 22010 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-08-05 05:31:44 Modified files: gcc/fortran: module.c ChangeLog gcc/testsuite : ChangeLog Added files: gcc/testsuite/gfortran.dg: namelist_use.f90 namelist_use_only.f90 Log message: 2005-08-05 Tobias Schlueter <[EMAIL PROTECTED]> Paul Thomas <[EMAIL PROTECTED]> PR fortran/22010 Port from g95. * module.c (mio_namelist): New function. Correct to set namelist_tail and to give error on renaming namelist by use association. (mio_symbol): Call mio_namelist. 2005-08-05 Paul Thomas <[EMAIL PROTECTED]> PR fortran/22010 * gfortran.dg/namelist_use.f90: New. * gfortran.dg/namelist_use_only.f90: New. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/module.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.31&r2=1.31.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.335.2.98&r2=1.335.2.99 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/namelist_use.f90.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.14.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/namelist_use_only.f90.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.14.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.317&r2=1.5084.2.318 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22010
[Bug c++/22487] C++ front-end produces mis-match types in EQ_EXPR (array constructor)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-05 05:13 --- Confirmed: t.cc:14: error: types mismatch in comparsion long intD.5 intD.2 D.1753 != -1; -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-08-05 05:13:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22487
[Bug c++/22451] C++ front-end produces mis-match types in MODIFY_EXPR (pointer to member functions)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-05 05:11 --- Confirmed; t.cc:10: error: statement types mismatch # VUSE ; # VUSE ; iftmp.0D.1797_19 = *D.1804_18; sD.1725:: * const intD.2 (*__vtbl_ptr_typeD.1484) (void) -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-08-05 05:11:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22451
[Bug middle-end/22375] fold_builtins creates mis-matched types
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-05 05:10 --- Confirmed. There is also another fortran front bug/tree-opt: store-ccp does not remove the extra load: # j.0_2 = V_MUST_DEF ; j.0 = -1; # j.1_4 = V_MUST_DEF ; j.1 = &__label_001000; # SFT.5_6 = V_MUST_DEF ; foo.j = 5; # VUSE ; j.2_7 = j.0; D.471_8 = j.2_7 != -1; But I don't know why. -- What|Removed |Added Status|UNCONFIRMED |NEW Component|tree-optimization |middle-end Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-08-05 05:10:03 date|| Summary|DOM (or fold_builtins) |fold_builtins creates mis- |creates mis-matched types |matched types http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22375
[Bug c++/22374] C++ front-end produces mis-match types in MODIFY_EXPR (dynamic_cast)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-05 04:50 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-08-05 04:50:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22374
[Bug tree-optimization/22373] loop linear produces type mis-match
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-05 04:47 --- Confirmed, -O1 -ftree-loop-linear is needed to reproduce the bug. The full error: t.c: In function 'foo': t.c:3: error: statement types mismatch lletmp.33D.1335_13 = 0; unsigned intD.3 intD.0 t.c:3: error: statement types mismatch lletmp.37D.1339_6 = 0; unsigned intD.3 intD.0 t.c:3: error: statement types mismatch lbvtmp.41D.1343_47 = 0; unsigned intD.3 intD.0 t.c:3: error: statement types mismatch lbvtmp.39D.1341_41 = 0; unsigned intD.3 intD.0 t.c:3: error: statement types mismatch lbvtmp.40D.1342_44 = 0; unsigned intD.3 intD.0 t.c:3: error: statement types mismatch lletmp.34D.1336_26 = 0; unsigned intD.3 intD.0 t.c:3: error: statement types mismatch lbvtmp.38D.1340_38 = 0; unsigned intD.3 intD.0 t.c:3: error: statement types mismatch lletmp.36D.1338_5 = 0; unsigned intD.3 intD.0 -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-08-05 04:47:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22373
[Bug middle-end/23241] [3.4/4.0/4.1 Regression] Invalid code generated for comparison of uchar to 255
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-08-05 04:46 --- > Just a note for fullness, this was caused by the patch which fixed PR 19296. Right. The annoying thing is that it is in 3.3.6 too so I think someone should fix the typo on the 3.3 branch too. -- What|Removed |Added BugsThisDependsOn||19296 Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23241
[Bug middle-end/22370] Vec lower produces mis-match types
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-05 04:46 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-08-05 04:46:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22370
[Bug c++/22369] C++ produces mis-matched types with pointers to member functions
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-05 04:46 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-08-05 04:46:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22369
[Bug tree-optimization/22526] vectorizer produces mis-match types in conditionals
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-05 04:25 --- Fixed. Thanks Ira. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22526
[Bug other/22368] [meta-bugs] mis-match types in GCC
-- Bug 22368 depends on bug 22526, which changed state. Bug 22526 Summary: vectorizer produces mis-match types in conditionals http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22526 What|Old Value |New Value Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22368
[Bug testsuite/22523] template/inline1.C does not test correctly on all targerts
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-05 04:24 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-08-05 04:24:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22523
[Bug tree-optimization/22401] DOM messes up the profiling info
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-05
04:22 ---
(In reply to comment #1)
> DOM seems to be innocent here.
Hmm, VRP gets it correct, in that there are no warnings for the following code:
void __show_backtrace(void *rw)
{
if (rw == 0) return;
L0:;
if (rw != 0) goto L0;
}
Which is equivalent to the what the trees look when it gets to DOM but then
again VRP happens before
profile happens.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22401
[Bug c/22297] [4.0/4.1 Regression] missing uninitialization warning
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-05 04:10 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-08-05 04:10:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22297
[Bug java/22166] 0x80000000/-1 is wrong in java
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-08-05 04:09:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22166
[Bug c++/23227] SFINAE bug
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-05 04:02 --- I don't think this is a bug as A will be tried to be instantiating while trying to convert it from float. ICC gives the same result as GCC, an error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23227
[Bug c++/20589] error: '' is/uses anonymous type'
--- Additional Comments From mark at codesourcery dot com 2005-08-05 03:49 --- Subject: Re: error: '' is/uses anonymous type' sethml at google dot com wrote: > --- Additional Comments From sethml at google dot com 2005-08-05 03:43 > --- > The C++ working group examined this issue in April as core language issue 488: > http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#488 > > They tentatively concluded that type deduction should fail in this case, > leaving > the built-in operator==(int,int) version as the only viable candidate and thus > the code attached to this bug report would compile. > > It seems likely that this decision will hold, that the standard will be > clarified, making this code valid. > > Can we get this bug re-opened, and perhaps change GCC 4 to accept this code in > anticipation of the C++ standard changing to explicitly allow it? Our normal practice has been not to do that until the issue is in at least WP status. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20589
[Bug c++/20589] error: '' is/uses anonymous type'
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-05 03:48 --- To suspend it as the DR is still in drafting. -- What|Removed |Added Status|REOPENED|SUSPENDED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20589
[Bug c++/20589] error: '' is/uses anonymous type'
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-05 03:48 --- Reopening to ... -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20589
[Bug c++/20589] error: '' is/uses anonymous type'
--- Additional Comments From sethml at google dot com 2005-08-05 03:43 --- The C++ working group examined this issue in April as core language issue 488: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#488 They tentatively concluded that type deduction should fail in this case, leaving the built-in operator==(int,int) version as the only viable candidate and thus the code attached to this bug report would compile. It seems likely that this decision will hold, that the standard will be clarified, making this code valid. Can we get this bug re-opened, and perhaps change GCC 4 to accept this code in anticipation of the C++ standard changing to explicitly allow it? -- What|Removed |Added CC||sethml at google dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20589
[Bug gcov/profile/23148] [4.1 Regression] gcov test failures
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-05 03:43 --- Fixed by: 2005-08-04 Jan Hubicka <[EMAIL PROTECTED]> * profile.c (branch_prob): Split edges with goto locus on them to get proper line counts. * tree-cfg.c (make_cond_expr_edges): Record user goto locuses, if any. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23148
[Bug middle-end/23241] [3.4/4.0/4.1 Regression] Invalid code generated for comparison of uchar to 255
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-05 03:40 --- Just a note for fullness, this was caused by the patch which fixed PR 19296. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23241
[Bug middle-end/23241] [3.4/4.0/4.1 Regression] Invalid code generated for comparison of uchar to 255
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-05 03:35 --- Confirmed. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org, ebotcazou at gcc dot ||gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed||1 GCC build triplet|powerpc-apple-darwin8.2.0 | GCC host triplet|powerpc-apple-darwin8.2.0 | GCC target triplet|arm-none-elf|arm-*-elf Last reconfirmed|-00-00 00:00:00 |2005-08-05 03:35:24 date|| Summary|Invalid code generated for |[3.4/4.0/4.1 Regression] |comparison of uchar to 255 |Invalid code generated for ||comparison of uchar to 255 Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23241
[Bug inline-asm/23242] Invalid %sil register chosen when dereferenced pointer used in inline asm with -O0
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-05 03:32 --- *** Bug 23243 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23242
[Bug inline-asm/23242] Invalid %sil register chosen when dereferenced pointer used in inline asm with -O0
--- Additional Comments From rth at gcc dot gnu dot org 2005-08-05 03:14 --- No, because you still need to use "Q" to get a register that may be used with a low-part. Even on i486. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23242
[Bug libstdc++/23244] __gnu_cxx::hash_map inconsistent iterator behavior
--- Additional Comments From jzampier at gmail dot com 2005-08-05 02:58 --- Created an attachment (id=9434) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9434&action=view) The offending code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23244
[Bug libstdc++/23244] New: __gnu_cxx::hash_map inconsistent iterator behavior
The iterators over hash_map behave in a manner inconsistent with the other
std::map, std::list, etc... data structures. This can cause segfaults which are
hard to root-cause. Sample Code Included with additional information:
Specifically, the iterators over hash_map require the 'first' datamember to
be valid until the iterator has advanced past that point. (see code for clarity)
The iterator operator++ should not depend on being able to call the
hash functor on that data member to advance. Because, as in the example,
you can't call the functor when the pointer has been deleted.
This behavior happens on other hosts of g++ (tested on 3.4.3, linux). (I just
have cygwin on here...)
The offending code is placed in #if 0 and #endif directives.
While this isn't a bug per se, it is a problem with the behavior of
hash_map that should at least be documented in LARGE letters
in the hash_map, if not fixed to work like the rest of the stl.
// $Id$
// Program: hashbroke
// Purpose: To demonstrate how __gnu_cxx::hash_map is broken. (sorta)
// Author: Jeffrey Zampieron
// License: GPL.
#include
#include
#include
using namespace std;
using namespace __gnu_cxx;
typedef struct {
size_t operator()( const string* str ) const {
return __gnu_cxx::__stl_hash_string( str->c_str() );
}
} strptrhash;
typedef struct {
bool operator()( const string* lhs, const string* rhs ) const {
return *lhs == *rhs;
}
} strptrequal;
typedef struct {
bool operator()( const string* lhs, const string* rhs ) const {
return *lhs < *rhs;
}
} strptrless;
typedef hash_map< string*, string*, strptrhash, strptrequal > StringPtrHash;
typedef std::map< string*, string*, strptrless > StringPtrMap;
int main() {
StringPtrHash testhash;
// test keys
string* k1 = new string( "key1" );
string* k2 = new string( "key2" );
string* k3 = new string( "key3" );
string* k4 = new string( "key4" );
string* k5 = new string( "key5" );
string* k6 = new string( "key6" );
// test vals
string* v1 = new string( "val1" );
string* v2 = new string( "val2" );
string* v3 = new string( "val3" );
string* v4 = new string( "val4" );
string* v5 = new string( "val5" );
string* v6 = new string( "val6" );
testhash[ k1 ] = v1;
testhash[ k2 ] = v2;
testhash[ k3 ] = v3;
testhash[ k4 ] = v4;
testhash[ k5 ] = v5;
testhash[ k6 ] = v6;
cout << "Hash:\n";
for( StringPtrHash::iterator iter = testhash.begin();
iter != testhash.end();
iter++ ) {
cout << "Key: " << *( iter->first ) << endl;
cout << "Val: " << *( iter->second ) << endl;
}
// this SHOULD be valid.
// and is for std::map
// but causes a segfault here.
#if 0
for( StringPtrHash::iterator iter = testhash.begin();
iter != testhash.end();
iter++ ) {
delete( iter->first );
delete( iter->second );
}
#endif
// Work around:
string* prev = __null;
for( StringPtrHash::iterator iter = testhash.begin();
iter != testhash.end();
iter++ ) {
delete( prev );
delete( iter->second );
prev = iter->first;
}
delete( prev );
// That this works with map:
StringPtrMap testmap;
k1 = new string( "key1" );
k2 = new string( "key2" );
k3 = new string( "key3" );
k4 = new string( "key4" );
k5 = new string( "key5" );
k6 = new string( "key6" );
// test vals
v1 = new string( "val1" );
v2 = new string( "val2" );
v3 = new string( "val3" );
v4 = new string( "val4" );
v5 = new string( "val5" );
v6 = new string( "val6" );
testmap[ k1 ] = v1;
testmap[ k2 ] = v2;
testmap[ k3 ] = v3;
testmap[ k4 ] = v4;
testmap[ k5 ] = v5;
testmap[ k6 ] = v6;
cout << "\nMap:\n";
for( StringPtrMap::iterator iter = testmap.begin();
iter != testmap.end();
iter++ ) {
cout << "Key: " << *( iter->first ) << endl;
cout << "Val: " << *( iter->second ) << endl;
}
// works like map should.
for( StringPtrMap::iterator iter = testmap.begin();
iter != testmap.end();
iter++ ) {
delete( iter->first );
delete( iter->second );
}
// The problem seems to be that the
// operator++ in the hash_map iterator
// needs to call the function provided
// by strptrhash in order to advance...
// but in my example that pointer has been deleted...
// hence the segfault.
// This is apparent if you run valgrind on the exec.
// (I don't have it on this machine, or I'd include the output)
// Why is this the case? Iterating over a map
// should not require computation of a hash key.
// While not really a bug, this is a caveat that should
// be documented somewhere, or ideally fixed
// Notice that map does not call strptrcmp to advance the iterator
}
--
Summary: __gnu_cxx::hash_map inconsistent iterator behavior
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libstdc++
AssignedTo: unassigned
[Bug middle-end/21529] [4.0/4.1 Regression] code size regression (+40%) with -Os from GCC-3.4.3 to 4.1
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-05 02:42 --- Subject: Bug 21529 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-08-05 02:42:07 Modified files: gcc: ChangeLog params.def params.h tree-sra.c Log message: PR 21529 * params.def (PARAM_SRA_MAX_STRUCTURE_COUNT): New. * params.h (SRA_MAX_STRUCTURE_COUNT): New. * tree-sra.c (decide_block_copy): Use it. Disable element copy if we'd have to instantiate too many members. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.9660&r2=2.9661 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/params.def.diff?cvsroot=gcc&r1=1.65&r2=1.66 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/params.h.diff?cvsroot=gcc&r1=1.31&r2=1.32 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-sra.c.diff?cvsroot=gcc&r1=2.69&r2=2.70 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21529
[Bug middle-end/21291] [4.0/4.1 Regression] can't find a register in class 'GENERAL_REGS' while reloading 'asm'
--- Additional Comments From rth at gcc dot gnu dot org 2005-08-05 02:34 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21291
[Bug middle-end/21291] [4.0/4.1 Regression] can't find a register in class 'GENERAL_REGS' while reloading 'asm'
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-05 02:33 --- Subject: Bug 21291 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-08-05 02:33:11 Modified files: gcc: ChangeLog tree-outof-ssa.c Added files: gcc/testsuite/gcc.target/i386: pr21291.c Log message: PR 21291 * tree-outof-ssa.c (coalesce_asm_operands): New. (coalesce_ssa_name): Use it. Split out ... (coalesce_phi_operands, coalesce_result_decls): ... these. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.352&r2=2.7592.2.353 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-outof-ssa.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.47&r2=2.47.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.target/i386/pr21291.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21291
[Bug inline-asm/23242] Invalid %sil register chosen when dereferenced pointer used in inline asm with -O0
--- Additional Comments From ianw at gelato dot unsw dot edu dot au
2005-08-05 02:17 ---
Subject: Re: Invalid %sil register chosen when dereferenced pointer used in
inline asm with -O0
On Fri, Aug 05, 2005 at 01:35:51AM -, pinskia at physics dot uc dot edu
wrote:
> On Aug 4, 2005, at 8:32 PM, ianw at gelato dot unsw dot edu dot au
> wrote:
>
> > /* this one doesn't */
> > __asm__ __volatile__("xchgb %0, %1"
> > : "=r"(old), "=m"(*newp)
> > : "0"(0xff), "m"(*newp) : "memory");
>
> This is not a bug.
>
> r is selecting %sil which is a valid register for x86_64.
Sorry if I'm missing something, I don't work with x86-64 much, but
isn't it a wrong to consider that register when I'm building for i486?
-i
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23242
[Bug inline-asm/23242] Invalid %sil register chosen when dereferenced pointer used in inline asm with -O0
--- Additional Comments From pinskia at physics dot uc dot edu 2005-08-05
01:35 ---
Subject: Re: New: Invalid %sil register chosen when dereferenced pointer used
in inline asm with -O0
On Aug 4, 2005, at 8:32 PM, ianw at gelato dot unsw dot edu dot au
wrote:
> /* this one doesn't */
> __asm__ __volatile__("xchgb %0, %1"
> : "=r"(old), "=m"(*newp)
> : "0"(0xff), "m"(*newp) : "memory");
This is not a bug.
r is selecting %sil which is a valid register for x86_64.
"r" is assuming that it is a full size register.
Use "Q" instead.
-- Pinski
PS The reason why I am CC you instead of writing this into bugzilla is
because
bugzilla seems dead.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23242
Re: [Bug inline-asm/23242] New: Invalid %sil register chosen when dereferenced pointer used in inline asm with -O0
On Aug 4, 2005, at 8:32 PM, ianw at gelato dot unsw dot edu dot au
wrote:
/* this one doesn't */
__asm__ __volatile__("xchgb %0, %1"
: "=r"(old), "=m"(*newp)
: "0"(0xff), "m"(*newp) : "memory");
This is not a bug.
r is selecting %sil which is a valid register for x86_64.
"r" is assuming that it is a full size register.
Use "Q" instead.
-- Pinski
PS The reason why I am CC you instead of writing this into bugzilla is
because
bugzilla seems dead.
[Bug inline-asm/23242] New: Invalid %sil register chosen when dereferenced pointer used in inline asm with -O0
Hi,
See the following snippet
[EMAIL PROTECTED]:~$ gcc-snap -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f95,objc,obj-c++,ada,treelang
--prefix=/usr/lib/gcc-snapshot --enable-shared --with-system-zlib --disable-nls
--enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu
--enable-libstdcxx-debug --enable-java-gc=boehm --enable-java-awt=gtk
--with-java-home=/usr/lib/gcc-snapshot/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre
--enable-mpfr --disable-werror i486-linux-gnu
Thread model: posix
gcc version 4.1.0 20050719 (experimental)
[EMAIL PROTECTED]:~$ cat test.c
int main()
{
volatile unsigned char old, new, *newp;
newp = &new;
/* this one works OK */
__asm__ __volatile__("xchgb %0, %1"
: "=r"(old), "=m"(new)
: "0"(0xff), "m"(new) : "memory");
#ifdef DEREF
/* this one doesn't */
__asm__ __volatile__("xchgb %0, %1"
: "=r"(old), "=m"(*newp)
: "0"(0xff), "m"(*newp) : "memory");
#endif
return 0;
}
[EMAIL PROTECTED]:~$ gcc-snap -Wall -o test test.c
[EMAIL PROTECTED]:~$ gcc-snap -DDEREF -Wall -o test test.c
/tmp/cc8YTeKG.s: Assembler messages:
/tmp/cc8YTeKG.s:30: Error: bad register name `%sil'
[EMAIL PROTECTED]:~$ gcc-snap -O2 -DDEREF -Wall -o test test.c
I believe this to be the cause of Debian bug #321291
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=321291) filed against the
libatomic_ops package (original author CC'd)
--
Summary: Invalid %sil register chosen when dereferenced pointer
used in inline asm with -O0
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ianw at gelato dot unsw dot edu dot au
CC: Hans dot Boehm at hp dot com,gcc-bugs at gcc dot gnu dot
org
GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23242
[Bug middle-end/23241] Invalid code generated for comparison of uchar to 255
--- Additional Comments From jconner at apple dot com 2005-08-05 00:17 --- I believe I have tracked down the root of this behavior to an invalid transformation in simplify_comparison (from combine.c). See email thread starting here: http://gcc.gnu.org/ml/gcc/2005-08/msg00159.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23241
[Bug middle-end/23241] Invalid code generated for comparison of uchar to 255
-- What|Removed |Added Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23241
[Bug middle-end/23241] New: Invalid code generated for comparison of uchar to 255
The following test code incorrectly generates an assertion failure on gcc
mainline and 4.0.1:
#include
struct fbs {
unsigned char uc8;
} fbs1 = {255};
void testfn ( struct fbs *fbs_ptr )
{
if ((fbs_ptr->uc8 != 255) && (fbs_ptr->uc8 != 0))
assert(0);
}
int main (int argc, char *argv[])
{
testfn (&fbs1);
return 0;
}
--
Summary: Invalid code generated for comparison of uchar to 255
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jconner at apple dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: powerpc-apple-darwin8.2.0
GCC host triplet: powerpc-apple-darwin8.2.0
GCC target triplet: arm-none-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23241
[Bug target/23224] Severe outages with -fPIC
--- Additional Comments From steven at gcc dot gnu dot org 2005-08-04 23:55 --- Known. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-08-04 23:55:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23224
[Bug middle-end/21291] [4.0/4.1 Regression] can't find a register in class 'GENERAL_REGS' while reloading 'asm'
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-04 23:37 --- Subject: Bug 21291 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-08-04 23:37:00 Modified files: gcc: ChangeLog tree-outof-ssa.c Added files: gcc/testsuite/gcc.target/i386: pr21291.c Log message: PR 21291 * tree-outof-ssa.c (coalesce_asm_operands): New. (coalesce_ssa_name): Use it. Split out ... (coalesce_phi_operands, coalesce_result_decls): ... these. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.9659&r2=2.9660 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-outof-ssa.c.diff?cvsroot=gcc&r1=2.65&r2=2.66 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.target/i386/pr21291.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21291
[Bug target/20126] [3.4 Regression] Inlined memcmp makes one argument null on entry
-- Bug 20126 depends on bug 22425, which changed state. Bug 22425 Summary: [4.1 regression] ICE in loop_givs_rescan, at loop.c:5521 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22425 What|Old Value |New Value Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20126
[Bug rtl-optimization/22425] [4.1 regression] ICE in loop_givs_rescan, at loop.c:5521
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru 2005-08-04 23:09 --- Fixed by this patch: 2005-07-14 Alexandre Oliva <[EMAIL PROTECTED]> Ulrich Weigand <[EMAIL PROTECTED]> PR target/20126 * loop.c (loop_givs_rescan): Do not ICE if unable to reduce an IV in some insn. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Summary|ICE in loop_givs_rescan, at |[4.1 regression] ICE in |loop.c:5521 |loop_givs_rescan, at ||loop.c:5521 Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22425
[Bug middle-end/21529] [4.0/4.1 Regression] code size regression (+40%) with -Os from GCC-3.4.3 to 4.1
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-05-12 10:39:02 |2005-08-04 22:54:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21529
[Bug target/22432] Wrong code generation using MMX intrinsics on amd64
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04 22:49 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Known to fail||4.1.0 Last reconfirmed|-00-00 00:00:00 |2005-08-04 22:49:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22432
[Bug rtl-optimization/22425] ICE in loop_givs_rescan, at loop.c:5521
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04 22:41 --- This works in "4.1.0 20050802". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22425
[Bug inline-asm/23200] [4.0/4.1 regression] rejects "i"(&var + 1)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04 22:11 --- TER will not work at -O0 though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200
[Bug java/23230] Wrong "this" used when call made to superclass which is also superclass of enclosing class
--- Additional Comments From greenrd at greenrd dot org 2005-08-04 22:03 --- I'm testing a patch. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |greenrd at greenrd dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23230
[Bug inline-asm/23200] [4.0/4.1 regression] rejects "i"(&var + 1)
--- Additional Comments From rth at gcc dot gnu dot org 2005-08-04 22:03 --- Andrew, can you have a look at why this isn't being TER'ed back into the asm_expr? It's not a 100% ideal solution to this problem, but I'll guess that it'll handle at least some of the cases including this one. -- What|Removed |Added CC||amacleod at redhat dot com AssignedTo|rth at gcc dot gnu dot org |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200
[Bug target/23239] gcc.dg/tree-prof/val-prof-5.c scan-tree-dump Div.mod by constant b..=997 transformation on insn fails
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04 21:57 --- This looks like a target issue. -- What|Removed |Added Component|tree-optimization |target GCC target triplet||hppa*-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23239
[Bug target/23240] gcc.c-torture/execute/pr23135.c execution fails
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04 21:56 --- This looks like a target issue. -- What|Removed |Added Component|tree-optimization |target GCC target triplet||ia64-hp-hpux11.23 Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23240
[Bug classpath/22580] [4.1 Regression] 'make -j' doesn't affect source->bytecode compilation
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04 21:45 --- This is a classpath issue -- What|Removed |Added CC||bug-classpath at gnu dot org Component|libgcj |classpath Product|gcc |classpath Target Milestone|4.1.0 |--- Version|4.1.0 |0.15 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22580
[Bug classpath/23238] split-for-gcj.sh should use CONFIG_SHELL
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04 21:41 --- I think the easy fix would change Makefile.am. The following line: JAVAC = $(srcdir)/split-for-gcj.sh && $(MAKE) -f $(srcdir)/Makefile.gcj \ GCJ='$(GCJ)' compile_classpath='$(top_builddir):$(compile_classpath)' can be changed to: JAVAC = $(CONFIG_SHELL) $(srcdir)/split-for-gcj.sh && $(MAKE) -f $(srcdir)/Makefile.gcj \ GCJ='$(GCJ)' compile_classpath='$(top_builddir):$(compile_classpath)' That should make it work. -- What|Removed |Added Keywords||build http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23238
[Bug classpath/23238] split-for-gcj.sh should use CONFIG_SHELL
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04 21:38 --- CC tromey. -- What|Removed |Added CC||tromey at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23238
[Bug classpath/23238] split-for-gcj.sh should use CONFIG_SHELL
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04 21:38 --- Oh, this is truely part of classpath. -- What|Removed |Added CC||gcc-bugs at gcc dot gnu dot ||org, java-prs at gcc dot gnu ||dot org Status|UNCONFIRMED |NEW Component|libgcj |classpath Ever Confirmed||1 Product|gcc |classpath Last reconfirmed|-00-00 00:00:00 |2005-08-04 21:38:06 date|| Target Milestone|4.1.0 |--- Version|4.1.0 |0.17 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23238
[Bug middle-end/23237] [4.1 Regression] -O1 rejects valid code (xxx causes a section type conflict).
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04
21:32 ---
Confirmed, reduced testcase:
static __attribute__ ((__section__ (".init.data"))) char *message;
static __attribute__ ((__section__ (".init.data"))) int (*actions[])(void) = {};
void unpack_to_rootfs(void)
{
while (!message)
{
if(!actions[0])
return;
}
}
--
What|Removed |Added
CC||hubicka at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Component|c |middle-end
Ever Confirmed||1
Keywords||rejects-valid
Known to fail||4.1.0
Known to work||4.0.0
Last reconfirmed|-00-00 00:00:00 |2005-08-04 21:32:27
date||
Summary|-funit-at-a-time reject |[4.1 Regression] -O1 rejects
|valid code (xxx causes a|valid code (xxx causes a
|section type conflict). |section type conflict).
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23237
[Bug tree-optimization/23239] New: gcc.dg/tree-prof/val-prof-5.c scan-tree-dump Div.mod by constant b..=997 transformation on insn fails
FAIL: gcc.dg/tree-prof/val-prof-5.c scan-tree-dump Div.mod by constant b..=997 transformation on insn (a new test) appeared on mainline on 20050802 on hppa2.0w-hpux and hppa64-hpux. gcc-testresults shows it also failing on hppa-linux. -- Summary: gcc.dg/tree-prof/val-prof-5.c scan-tree-dump Div.mod by constant b..=997 transformation on insn fails Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jsm28 at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23239
[Bug tree-optimization/23240] New: gcc.c-torture/execute/pr23135.c execution fails
FAIL: gcc.c-torture/execute/pr23135.c execution, -O0 FAIL: gcc.c-torture/execute/pr23135.c execution, -O1 FAIL: gcc.c-torture/execute/pr23135.c execution, -O2 FAIL: gcc.c-torture/execute/pr23135.c execution, -O3 -fomit-frame-pointer FAIL: gcc.c-torture/execute/pr23135.c execution, -O3 -g FAIL: gcc.c-torture/execute/pr23135.c execution, -Os (a new test) have appeared on mainline on 20050804 on ia64-hp-hpux11.23, both -mlp64 and -milp32. -- Summary: gcc.c-torture/execute/pr23135.c execution fails Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jsm28 at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23240
[Bug middle-end/21291] [4.0/4.1 Regression] can't find a register in class 'GENERAL_REGS' while reloading 'asm'
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-04-29 21:58:36 |2005-08-04 20:59:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21291
[Bug c/23237] -funit-at-a-time reject valid code (xxx causes a section type conflict).
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04 20:58 --- Reducing. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Component|other |c GCC build triplet|ppc-pld-linux | GCC host triplet|ppc-pld-linux | GCC target triplet|ppc-pld-linux | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23237
[Bug middle-end/21291] [4.0/4.1 Regression] can't find a register in class 'GENERAL_REGS' while reloading 'asm'
--- Additional Comments From rth at gcc dot gnu dot org 2005-08-04 20:48
---
The reason that we're rejecting the "m" alternative is that we've expanded
"+mr"(blen) to
(set (reg/v:SI 60 [ blen.25 ])
(asm_operands:SI ("") ("=mr") 2 [
(mem/i:SI (plus:SI (reg/f:SI 16 argp)
(const_int 16 [0x10])) [0 d+0 S4 A32])
(reg/v/f:SI 65 [ a ])
(reg/v/f:SI 67 [ b ])
(reg/v:SI 68 [ blen ])
Note reg 60 as output and reg 68 as input. Probably out-of-ssa is
missing the fact that we'd like these variables to be unified.
--
What|Removed |Added
CC||amacleod at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21291
[Bug other/23237] -funit-at-a-time reject valid code (xxx causes a section type conflict).
--- Additional Comments From pluto at agmk dot net 2005-08-04 20:40 --- Created an attachment (id=9433) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9433&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23237
[Bug other/23237] New: -funit-at-a-time reject valid code (xxx causes a section type conflict).
$ gcc initramfs.i -O2 -c -funit-at-a-time (...) init/initramfs.c: At top level: init/initramfs.c:10: error: message causes a section type conflict init/initramfs.c:33: error: head causes a section type conflict init/initramfs.c:80: error: ino causes a section type conflict init/initramfs.c:80: error: major causes a section type conflict init/initramfs.c:80: error: minor causes a section type conflict init/initramfs.c:80: error: nlink causes a section type conflict init/initramfs.c:81: error: mode causes a section type conflict init/initramfs.c:82: error: body_len causes a section type conflict init/initramfs.c:82: error: name_len causes a section type conflict init/initramfs.c:83: error: uid causes a section type conflict init/initramfs.c:84: error: gid causes a section type conflict init/initramfs.c:85: error: rdev causes a section type conflict init/initramfs.c:121: error: state causes a section type conflict init/initramfs.c:121: error: next_state causes a section type conflict init/initramfs.c:123: error: victim causes a section type conflict init/initramfs.c:124: error: count causes a section type conflict init/initramfs.c:125: error: this_header causes a section type conflict init/initramfs.c:125: error: next_header causes a section type conflict init/initramfs.c:127: error: dry_run causes a section type conflict init/initramfs.c:138: error: collected causes a section type conflict init/initramfs.c:139: error: remains causes a section type conflict init/initramfs.c:140: error: collect causes a section type conflict init/initramfs.c:156: error: header_buf causes a section type conflict init/initramfs.c:156: error: symlink_buf causes a section type conflict init/initramfs.c:156: error: name_buf causes a section type conflict init/initramfs.c:239: error: wfd causes a section type conflict -- Summary: -funit-at-a-time reject valid code (xxx causes a section type conflict). Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pluto at agmk dot net CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: ppc-pld-linux GCC host triplet: ppc-pld-linux GCC target triplet: ppc-pld-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23237
[Bug tree-optimization/23046] [4.1 Regression] ICE in set_value_range, at tree-vrp.c:191
--- Additional Comments From dnovillo at redhat dot com 2005-08-04 19:24 --- Subject: Re: [4.1 Regression] ICE in set_value_range, at tree-vrp.c:191 On Thu, Aug 04, 2005 at 07:18:13PM -, dank at kegel dot com wrote: > In general, once a ten-line testcase is found, do these get added > to the gcc regression testsuite as a matter of course? > No. Only after a fix has been created for the failure. > We would be happy to submit patches to add these to the test suite, but > we don't have copyright assignments in. Let us know if we > should submit such patches anyway. > I don't know whether test cases require copyright assignments. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23046
[Bug tree-optimization/23046] [4.1 Regression] ICE in set_value_range, at tree-vrp.c:191
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04 19:23 --- (In reply to comment #8) > In general, once a ten-line testcase is found, do these get added > to the gcc regression testsuite as a matter of course? In general once the fix is found, it will be added to the testsuite. If it was already fixed, it will be added. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23046
[Bug tree-optimization/23046] [4.1 Regression] ICE in set_value_range, at tree-vrp.c:191
--- Additional Comments From phython at gcc dot gnu dot org 2005-08-04 19:22 --- When the patch that fixes a bug is put into GCC the testcases go in as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23046
[Bug tree-optimization/23046] [4.1 Regression] ICE in set_value_range, at tree-vrp.c:191
--- Additional Comments From dank at kegel dot com 2005-08-04 19:18 --- In general, once a ten-line testcase is found, do these get added to the gcc regression testsuite as a matter of course? We would be happy to submit patches to add these to the test suite, but we don't have copyright assignments in. Let us know if we should submit such patches anyway. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23046
[Bug rtl-optimization/22563] [3.4/4.0/4.1 Regression] performance regression for gcc newer than 2.95
--- Additional Comments From danalis at cis dot udel dot edu 2005-08-04 19:16 --- For the record the reduced test case was derived from h07.cpp of bench++ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22563
[Bug tree-optimization/23046] [4.1 Regression] ICE in set_value_range, at tree-vrp.c:191
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04
18:43 ---
Reduced testcase:
enum eumtype { ENUM1, ENUM2 };
void g(const eumtype kind );
void f(long i);
void g(const eumtype kind)
{
if ((kind != ENUM1) && (kind != ENUM2))
f(kind);
}
--- the tree before VRP:
void g(eumtype) (kind)
{
long int kind.0;
:
if (kind_1 > 1) goto ; else goto ;
:;
kind.0_2 = (long int) kind_1;
f (kind.0_2);
:;
return;
}
--
What|Removed |Added
CC||phython at gcc dot gnu dot
||org, dnovillo at gcc dot gnu
||dot org
Last reconfirmed|2005-08-04 18:31:51 |2005-08-04 18:43:23
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23046
[Bug tree-optimization/23046] [4.1 Regression] ICE in set_value_range, at tree-vrp.c:191
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04 18:31 --- Confirmed, reducing a little further. -- What|Removed |Added Status|WAITING |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-08-04 18:31:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23046
[Bug tree-optimization/22037] [4.1 Regression] internal compiler error: verify_ssa failed
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-08-04 18:17 --- Fixed. http://gcc.gnu.org/ml/gcc-patches/2005-08/msg00283.html. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22037
[Bug tree-optimization/22037] [4.1 Regression] internal compiler error: verify_ssa failed
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-04 18:16 --- Subject: Bug 22037 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-08-04 18:16:41 Modified files: gcc: ChangeLog passes.c tree-cfg.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/tree-ssa: pr22037.C Log message: PR 22037 * tree-cfg.c (replace_uses_by): Call mark_new_vars_to_rename. (tree_merge_blocks): Propagate anything allowed by may_propagate_copy. Clarify documentation. * passes.c (execute_todo): If cleanup_tree_cfg invalidated the SSA form, schedule an update if necessary. testsuite/ChangeLog PR 22037 * g++.dg/tree-ssa/pr22037.C: Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.9654&r2=2.9655 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/passes.c.diff?cvsroot=gcc&r1=2.108&r2=2.109 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-cfg.c.diff?cvsroot=gcc&r1=2.213&r2=2.214 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5877&r2=1.5878 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/tree-ssa/pr22037.C.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22037
[Bug pch/14940] PCH largefile test fails on various platforms
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca 2005-08-04 18:04 --- Subject: Re: PCH largefile test fails on various platforms > My patch added the largefile test to the 3.4 branch. I don't think that > failing > a new test can be called a regression. I expect that the compiler would have > failed the test before, too, it's just that nobody knew about it. Ok. > I would be in favor of backporting to 3.4 any HP/UX fix which fixes the > largefile test. But since I don't think it's a regression I don't think it's > on > my plate to do that. I will probably do it if nobody else does, but not very > soon. I'll try to find the time to test the change in the next few days. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14940
[Bug tree-optimization/23234] [4.1 Regression] ICE in verify_flow_info()
--- Additional Comments From uttamp at us dot ibm dot com 2005-08-04 17:57
---
(In reply to comment #1)
> Confirmed, reduced testcase:
> double func ( double a, double b, double c)
> {
> double y0;
> if(a==0.0) {
> y0 = -c/b;
> return y0;
> }
> y0 = -c/b;
> return y0;
> }
nice. ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23234
[Bug tree-optimization/23234] [4.1 Regression] ICE in verify_flow_info()
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04
17:55 ---
Confirmed, reduced testcase:
double func ( double a, double b, double c)
{
double y0;
if(a==0.0) {
y0 = -c/b;
return y0;
}
y0 = -c/b;
return y0;
}
--
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed||1
GCC build triplet|powerpc-linux |
GCC host triplet|powerpc-linux |
GCC target triplet|powerpc-linu|
Keywords||ice-on-valid-code
Known to fail||4.1.0
Known to work||4.0.0
Last reconfirmed|-00-00 00:00:00 |2005-08-04 17:55:39
date||
Summary|ICE in verify_flow_info() |[4.1 Regression] ICE in
||verify_flow_info()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23234
[Bug pch/14940] PCH largefile test fails on various platforms
--- Additional Comments From ian at airs dot com 2005-08-04 17:54 --- My patch added the largefile test to the 3.4 branch. I don't think that failing a new test can be called a regression. I expect that the compiler would have failed the test before, too, it's just that nobody knew about it. Failing the largefile test means that pre-compiled headers will fail occasionally and effectively unpredictably. That's why I added the test: so that at least people will know for which targets PCH is unreliable. I would be in favor of backporting to 3.4 any HP/UX fix which fixes the largefile test. But since I don't think it's a regression I don't think it's on my plate to do that. I will probably do it if nobody else does, but not very soon. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14940
[Bug tree-optimization/23234] New: ICE in verify_flow_info()
Following test program causes an internal compiler error,
$ cat y.c
double func ( double a, double b, double c)
{
double x0, x1, y0, y1;
int type = 0;
double ar;
if(b==0.0){
x0 = -c/a;
return( x0 > 1.0? 1.0 : ( x0 < 0.0 ? 0.0: x0));
}
if(a==0.0) {
y0 = -c/b;
return( y0 > 1.0? 1.0 : ( y0 < 0.0 ? 0.0: y0));
}
x0 = -c/a;
y0 = -c/b;
type = ((y0>=1.0)&&(y1>=1.0) ? 16 : type);
switch(type){
case 3: ar = (0.5*(y0+y1)); break;
}
return ar;
}
$ /opt/mline-20050802/bin/gcc -c -ffast-math -O2 y.c
$ y.c: In function âfuncâ:
y.c:2: error: control flow in the middle of basic block 0
y.c:2: internal compiler error: verify_flow_info failed
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
This test case works with gcc_cvs code till 20050801. This is also a reason to
fail eon benchmark.
--
Summary: ICE in verify_flow_info()
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uttamp at us dot ibm dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: powerpc-linux
GCC host triplet: powerpc-linux
GCC target triplet: powerpc-linu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23234
[Bug pch/14940] PCH largefile test fails on various platforms
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca 2005-08-04 17:41 --- Subject: Re: PCH largefile test fails on various platforms > Log message: > ./ > PR pch/14400 > Backport from mainline: With this change largefile.c now fails on hppa2.0w-hp-hpux11.00 on 3.4. So, we now have a 3.4 regression. I guess the 4.0 PA fix needs to be backported. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14940
[Bug target/23102] extra XORs generated on i686
--- Additional Comments From dann at godzilla dot ics dot uci dot edu 2005-08-04 17:06 --- (In reply to comment #3) > Try killing the peephole2 for this. Somebody elses cost-metric should force > the constant into a register for the move ... Killing the peephole2 would just produce the code produced for i386 as shown in the original report. What we want is something like xorl %ecx, %ecx movl%ecx, 3144(%eax) movl%ecx, 3124(%eax) ... etc etc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23102
[Bug rtl-optimization/23233] Loop optimisation ICE for subreg addresses
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04 16:15 --- Confirmed, I wish loop.c would go away. -- What|Removed |Added Known to fail||4.0.0 3.3.3 3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23233
[Bug rtl-optimization/23233] Loop optimisation ICE for subreg addresses
-- What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-08-04 16:06:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23233
[Bug rtl-optimization/23233] New: Loop optimisation ICE for subreg addresses
This testcase causes an ICE at -O2:
void foo (volatile long long *x)
{
while (*x)
{
*x = 0;
*((volatile char *) 0) = 0;
}
}
with:
error: unrecognizable insn:
(insn:HI 25 21 27 2 (set (mem/v:QI (subreg:SI (reg:DI 124) 4) [0 S1 A8])
(subreg:QI (reg:DI 124) 7)) -1 (nil)
(expr_list:REG_EQUAL (const_int 0 [0x0])
(nil)))
The bug is in the loop,c movables code. There are two loop-invariant
registers with the value 0, one SImode and one DImode. loop decides
to combine them and replaces uses of the SImode register with the DImode
one. This turns the address in the MEM from an SImode REG to an
SImode SUBREG of a DImode reg, and powerpc's GO_IF_LEGITIMATE_ADDRESS
doesn't allow that.
--
Summary: Loop optimisation ICE for subreg addresses
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P2
Component: rtl-optimization
AssignedTo: rsandifo at gcc dot gnu dot org
ReportedBy: rsandifo at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: powerpc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23233
[Bug fortran/23232] DATA implied DO variables
--- Additional Comments From rofi at ya dot com 2005-08-04 15:59 --- Created an attachment (id=9431) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9431&action=view) Failing case with an optional commented checking part -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23232
[Bug fortran/23232] New: DATA implied DO variables
gcc version 4.1.0 20050730 (experimental) The following two DATA statements are rejected by gfortran because "J" is not considered a valid primary in those expressions although it is the variable of another enclosing data-implied-do. PROGRAM p REAL :: ONE_ARRAY(100, 100) INTEGER :: K, J DATA ((ONE_ARRAY (K, J), K = 1, J-1), J = 1, 100) /4950 * 1.0/ DATA ((ONE_ARRAY (K, J), K = J, 100), J = 1, 100) /5050 * 0.0/ END PROGRAM $ gfortran -fsyntax-only snippet.f90 In file snippet.f90:5 DATA ((ONE_ARRAY (K, J), K = 1, J-1), J = 1, 100) /4950 * 1.0/ 1 Error: Variable 'j' at (1) cannot appear in an initialization expression In file snippet.f90:6 DATA ((ONE_ARRAY (K, J), K = J, 100), J = 1, 100) /5050 * 0.0/ 1 Error: Variable 'j' at (1) cannot appear in an initialization expression -- Summary: DATA implied DO variables Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rofi at ya dot com CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23232
[Bug bootstrap/23231] New: cross compiling fails for mips-sgi-irix6.5
when cross compiling the gcc 4.0.2 on a i686-pc-linux-gnu with intel: binutils 2.16.1 - compiled with gcc 4.1.0 mips: binutils 2.16.1 - compiled with gcc 4.1.0 the following error occures: /home/pfl/gnu/mips-sgi-irix6.5/bin/ld: unrecognized option '-_SYSTYPE_SVR4' /home/pfl/gnu/mips-sgi-irix6.5/bin/ld: use the --help option for usage information collect2: ld returned 1 exit status and the compilation exits. The same problem occures when the binutils are: intel: binutils 2.16.1 - compiled with gcc 4.0.2 mips: binutils 2.16.1 - compiled with gcc 4.0.2 I get also the same problem when compiling on an apple mac - tiger 10.4.2. -- Summary: cross compiling fails for mips-sgi-irix6.5 Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: normal Priority: P2 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pfl at iis dot fhg dot de CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: mips-sgi-irix6.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23231
[Bug bootstrap/17777] AIX bootstrap comparison failure with xlc6
--- Additional Comments From jlquinn at gcc dot gnu dot org 2005-08-04 15:34 --- Unfortunately, I no longer have access to the test box, so I can't verify if it's working now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1
[Bug java/23230] Wrong "this" used when call made to superclass which is also superclass of enclosing class
--- Additional Comments From greenrd at greenrd dot org 2005-08-04 15:26 --- The relevant part of the JLS is section 15.12.1 @ http://java.sun.com/docs/books/jls/second_edition/html/expressions.doc.html#20448 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23230
[Bug java/23230] Wrong "this" used when call made to superclass which is also superclass of enclosing class
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04 15:23 --- Confirmed. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-08-04 15:23:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23230
[Bug java/23220] [3.4/4.0/4.1 Regression] ICE in a specific doubly-nested class
--- Additional Comments From greenrd at greenrd dot org 2005-08-04 15:07 --- Backtrace: #0 0x08066846 in java_complete_lhs (node=0x0) at /var/tmp/portage/gcc-4.1.0_beta20050730/work/gcc-4.1-20050730/gcc/java/parse.y:11665 #1 0x08066757 in java_complete_tree (node=0x0) at /var/tmp/portage/gcc-4.1.0_beta20050730/work/gcc-4.1-20050730/gcc/java/parse.y:11628 #2 0x0806518b in maybe_use_access_method (is_super_init=0, mdecl=0xbfc1365c, this_arg=0xbfc13658) at /var/tmp/portage/gcc-4.1.0_beta20050730/work/gcc-4.1-20050730/gcc/java/parse.y:10971 #3 0x08064991 in patch_method_invocation (patch=0xb7c39e60, primary=0x0, where=0x0, from_super=0, is_static=0x0, ret_decl=0xbfc1371c) at /var/tmp/portage/gcc-4.1.0_beta20050730/work/gcc-4.1-20050730/gcc/java/parse.y:10754 #4 0x080679a8 in java_complete_lhs (node=0xb7c39e60) at /var/tmp/portage/gcc-4.1.0_beta20050730/work/gcc-4.1-20050730/gcc/java/parse.y:12130 #5 0x08066757 in java_complete_tree (node=0xb7c39e60) at /var/tmp/portage/gcc-4.1.0_beta20050730/work/gcc-4.1-20050730/gcc/java/parse.y:11628 #6 0x08067666 in java_complete_lhs (node=0xb7c39e88) at /var/tmp/portage/gcc-4.1.0_beta20050730/work/gcc-4.1-20050730/gcc/java/parse.y:12038 #7 0x08066757 in java_complete_tree (node=0xb7c39e88) at /var/tmp/portage/gcc-4.1.0_beta20050730/work/gcc-4.1-20050730/gcc/java/parse.y:11628 #8 0x08066aa0 in java_complete_lhs (node=0xb7c090d0) at /var/tmp/portage/gcc-4.1.0_beta20050730/work/gcc-4.1-20050730/gcc/java/parse.y:11748 #9 0x08066757 in java_complete_tree (node=0xb7c090d0) at /var/tmp/portage/gcc-4.1.0_beta20050730/work/gcc-4.1-20050730/gcc/java/parse.y:11628 #10 0x0805f911 in java_complete_expand_method (mdecl=0xb7c38480) at /var/tmp/portage/gcc-4.1.0_beta20050730/work/gcc-4.1-20050730/gcc/java/parse.y:8191 #11 0x0805effe in java_complete_expand_methods (class_decl=0xb7c172d8) at /var/tmp/portage/gcc-4.1.0_beta20050730/work/gcc-4.1-20050730/gcc/java/parse.y:7885 #12 0x0805ef5d in java_complete_expand_class (outer=0xb7c172d8) at /var/tmp/portage/gcc-4.1.0_beta20050730/work/gcc-4.1-20050730/gcc/java/parse.y:7846 #13 0x0805ef44 in java_complete_expand_class (outer=0xb7c17208) at /var/tmp/portage/gcc-4.1.0_beta20050730/work/gcc-4.1-20050730/gcc/java/parse.y:7844 #14 0x0805ef44 in java_complete_expand_class (outer=0xb7c17138) at /var/tmp/portage/gcc-4.1.0_beta20050730/work/gcc-4.1-20050730/gcc/java/parse.y:7844 #15 0x0805ef15 in java_complete_expand_classes () at /var/tmp/portage/gcc-4.1.0_beta20050730/work/gcc-4.1-20050730/gcc/java/parse.y:7827 #16 0x080618cb in java_expand_classes () at /var/tmp/portage/gcc-4.1.0_beta20050730/work/gcc-4.1-20050730/gcc/java/parse.y:9243 #17 0x080a99eb in java_parse_file (set_yydebug=0) at /var/tmp/portage/gcc-4.1.0_beta20050730/work/gcc-4.1-20050730/gcc/java/jcf-parse.c:1309 #18 0x08373b6d in compile_file () at /var/tmp/portage/gcc-4.1.0_beta20050730/work/gcc-4.1-20050730/gcc/toplev.c:971 #19 0x08375271 in do_compile () at /var/tmp/portage/gcc-4.1.0_beta20050730/work/gcc-4.1-20050730/gcc/toplev.c:1914 #20 0x083752d3 in toplev_main (argc=14, argv=0xbfc13c54) at /var/tmp/portage/gcc-4.1.0_beta20050730/work/gcc-4.1-20050730/gcc/toplev.c:1946 #21 0x080babea in main (argc=14, argv=0xbfc13c54) at /var/tmp/portage/gcc-4.1.0_beta20050730/work/gcc-4.1-20050730/gcc/main.c:35 -- What|Removed |Added OtherBugsDependingO||18131 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23220
[Bug java/23230] Wrong "this" used when call made to superclass which is also superclass of enclosing class
-- What|Removed |Added OtherBugsDependingO||18131, 23220 nThis|| Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23230
[Bug java/23230] New: Wrong "this" used when call made to superclass which is also superclass of enclosing class
The following file is miscompiled by gcj -C:
public class Outer extends Thread {
public class Inner extends Thread {
private Inner () {
start ();
}
}
}
It uses the wrong "this" to call start():
Outer$Inner(Outer);
Code:
0: aload_0
1: aload_1
2: putfield#12; //Field this$0:LOuter;
5: aload_0
6: invokespecial #15; //Method java/lang/Thread."":()V
9: aload_1
10: invokevirtual #18; //Method java/lang/Thread.start:()V
13: return
}
Sun's compiler outputs correct code:
private Outer$Inner(Outer);
Code:
0: aload_0
1: aload_1
2: putfield#1; //Field this$0:LOuter;
5: aload_0
6: invokespecial #2; //Method java/lang/Thread."":()V
9: aload_0
10: invokevirtual #3; //Method start:()V
13: return
}
The difference is at 9.
Note: The bug does not occur if you just replace start() (which is declared in
java.lang.Thread) with notify() (which is declared in java.lang.Object).
--
Summary: Wrong "this" used when call made to superclass which is
also superclass of enclosing class
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: greenrd at greenrd dot org
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23230
[Bug rtl-optimization/20969] unrolling does not take target register pressure into account.
--- Additional Comments From amylaar at gcc dot gnu dot org 2005-08-04 13:36 --- (In reply to comment #13) > Strength reduction already happens before loop unrolling, but I guess > there could still be new opportunities after loop unrolling. Not sure > how significant that would be. Unrolling really works best when it can directly work with the strength reduction information. Besides better counting and modifying DEST_ADDR givs, there is also the issue of throttling prefetching to use less preftches per cache line. E.g. whenyou have a loop with stride 4 and a cache line size of 32, when you unroll the loop by a factor of eight, instead of prefetching every cache line 8 times, you only need to prefetch it once. > > For the number of loop iterations, the plan was always that loops would > be preserved down from the tree level, and that the number of iterations > would be computed there. This hasn't happened yet, sadly. The problem is not only that we are not passed the information that was computed earlier, but also that we currently only have exact information or none at all. When there is an array access inside the loop, we might not be able to prove what the exact iteration count is, although we can make a guess that will be exact or close with a high probability. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20969
[Bug c++/23227] SFINAE bug
--- Additional Comments From gdr at integrable-solutions dot net 2005-08-04 13:26 --- Subject: Re: SFINAE bug "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | IIRC SFINAE does not mean not instantiating the template class. That is true. However, the real issue has nothing to do with SFINAE. The compiler is just plain buggy. Sylvain -- don't describe a plain compiler bug as SFINAE, otherwise people might be sidetracked :-) -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23227
[Bug target/15247] gas complains "There are only 32 single precision f registers; [0-31]" when compiling glibc-2.3.2/math/dosincos.c
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04 13:14 --- *** Bug 23222 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15247
[Bug c/23222] gcc optimization error for sparc with xine/ffmpeg, bad assembly generated
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04 13:14 --- fmovdne %fcc1, %f50, %f8 Yep this is still a dup of bug 15247. *** This bug has been marked as a duplicate of 15247 *** -- What|Removed |Added Status|WAITING |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23222
[Bug rtl-optimization/20969] unrolling does not take target register pressure into account.
--- Additional Comments From steven at gcc dot gnu dot org 2005-08-04 13:10 --- Strength reduction already happens before loop unrolling, but I guess there could still be new opportunities after loop unrolling. Not sure how significant that would be. For the number of loop iterations, the plan was always that loops would be preserved down from the tree level, and that the number of iterations would be computed there. This hasn't happened yet, sadly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20969
[Bug c++/23227] SFINAE bug
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04 13:07 --- IIRC SFINAE does not mean not instantiating the template class. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23227
[Bug c/23228] [3.4/4.0/4.1 Regression] Silly "unused variable" warning after redeclaration of a local variable
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04 13:04 --- Confirmed, a regression from 3.0.4 and 2.95.3. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Known to fail||3.3 3.2.3 3.4.0 4.0.0 4.1.0 Known to work||3.0.4 2.95.3 Last reconfirmed|-00-00 00:00:00 |2005-08-04 13:04:17 date|| Summary|Silly "unused variable" |[3.4/4.0/4.1 Regression] |warning after redeclaration |Silly "unused variable" |of a local variable |warning after redeclaration ||of a local variable Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23228
