Re: Regression in LAPACK with -O3
Jerry DeLisle wrote: Paul Thomas wrote: Andrew, and the testcase here. ¿Que? Paul See attachment in PR26001 LAPACK tests run OK with the patch. Thanks to Dominique Dhumieres for initial reduced case and Andrew Pinski for squeezing this in. Hope we can get it committed to 4.1 and trunk soon. Jerry
[Bug middle-end/26001] [4.1/4.2 Regression] expand uses the wrong part of the string for array accesses
--- Comment #19 from jvdelisle at gcc dot gnu dot org 2006-01-31 06:39 --- I ran the full LAPACK test suite and it successfully passes with the patch in comment #17. Results are pretty good/typical for -O3. $ grep fail *.out cgd.out: CGV drivers: 67 out of 1092 tests failed to pass the threshold csep.out: CST:2 out of 4662 tests failed to pass the threshold csep.out: CST drivers: 1 out of 11664 tests failed to pass the threshold dgd.out: DXV drivers:200 out of 5000 tests failed to pass the threshold sgd.out: SXV drivers: 37 out of 5000 tests failed to pass the threshold ssep.out: SST:1 out of 4662 tests failed to pass the threshold ssep.out: SST drivers: 1 out of 14256 tests failed to pass the threshold ssvd.out: SBD: 1 out of 5510 tests failed to pass the threshold zgd.out: ZGV drivers: 66 out of 1092 tests failed to pass the threshold zgd.out: ZXV drivers: 24 out of 5000 tests failed to pass the threshold -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26001
[Bug middle-end/26001] [4.1/4.2 Regression] expand uses the wrong part of the string for array accesses
--- Comment #18 from pinskia at gcc dot gnu dot org 2006-01-31 05:33 --- Note if PR 22303 was fixed, then the code in expr.c could be removed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26001
[Bug middle-end/26001] [4.1/4.2 Regression] expand uses the wrong part of the string for array accesses
--- Comment #17 from pinskia at gcc dot gnu dot org 2006-01-31 05:19 --- Created an attachment (id=10765) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10765&action=view) Patch which still needs to bootstrap/tested but it works on my simple example ChangeLog: * expr.c (expand_expr_real_1) : Use the corrected index for the character out of the string constant. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26001
[Bug fortran/26041] FORTRAN compiler won't compile the valid code
--- Comment #2 from hjl at lucon dot org 2006-01-31 04:58 --- How about this? [EMAIL PROTECTED] cpu2006-465b]$ !cat cat foo.f90 module foo publicbar_ interface bar_ module procedure bar end interface publicxxx_ interface xxx_ module procedure xxx end interface contains subroutine bar(self, z) interface function self(z) result(res) real z real(kind=kind(1.0d0)) :: res end function end interface end subroutine subroutine xxx(self,z) interface function self(z) result(res) real z real(kind=kind(1.0d0)) :: res end function end interface call bar_(self, z) end subroutine end [EMAIL PROTECTED] cpu2006-465b]$ make /export/build/gnu/gcc/build-x86_64-linux/gcc/gfortran -B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -O2 -S foo.f90 In file foo.f90:26 call bar_(self, z) 1 Error: Generic subroutine 'bar_' at (1) is not an intrinsic subroutine make: *** [foo.s] Error 1 [EMAIL PROTECTED] cpu2006-465b]$ If I swap the order of xxx and bar, it compiles: [EMAIL PROTECTED] cpu2006-465b]$ !cat cat foo.f90 module foo publicbar_ interface bar_ module procedure bar end interface publicxxx_ interface xxx_ module procedure xxx end interface contains subroutine xxx(self,z) interface function self(z) result(res) real z real(kind=kind(1.0d0)) :: res end function end interface call bar_(self, z) end subroutine subroutine bar(self, z) interface function self(z) result(res) real z real(kind=kind(1.0d0)) :: res end function end interface end subroutine end [EMAIL PROTECTED] cpu2006-465b]$ make /export/build/gnu/gcc/build-x86_64-linux/gcc/gfortran -B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -O2 -S foo.f90 [EMAIL PROTECTED] cpu2006-465b]$ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26041
[Bug middle-end/26001] [4.1/4.2 Regression] expand uses the wrong part of the string for array accesses
--- Comment #16 from pinskia at gcc dot gnu dot org 2006-01-31 04:56 --- The bug is around expr.c:7128. Working on this. -- 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=26001
[Bug objc++/26044] lookup-2.mm:40: error: cannot convert 'objc_object*' to 'MyWidget*' in initialization
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-31 04:05 --- *** This bug has been marked as a duplicate of 23614 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26044
[Bug objc++/23614] obj-c++.dg/lookup-2.mm fails with the GNU runtime
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-31 04:05 --- *** Bug 26044 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||danglin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23614
[Bug testsuite/23613] obj-c++.dg/isa-field-1.mm fails with the GNU runtime
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-31 04:05 --- *** Bug 26043 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||danglin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23613
[Bug objc++/26043] isa-field-1.mm:17: error: 'struct objc_object' has no member named 'isa'
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-31 04:05 --- *** This bug has been marked as a duplicate of 23613 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26043
[Bug objc++/26044] New: lookup-2.mm:40: error: cannot convert 'objc_object*' to 'MyWidget*' in initialization
Executing on host: /home/dave/gnu/gcc-4.1/objdir/gcc/testsuite/../g++ -B/home/da ve/gnu/gcc-4.1/objdir/gcc/testsuite/../ /home/dave/gnu/gcc-4.1/gcc/gcc/testsuite /obj-c++.dg/lookup-2.mm -nostdinc++ -I/home/dave/gnu/gcc-4.1/objdir/hppa-linux/ libstdc++-v3/include/hppa-linux -I/home/dave/gnu/gcc-4.1/objdir/hppa-linux/libst dc++-v3/include -I/home/dave/gnu/gcc-4.1/gcc/libstdc++-v3/libsupc++ -I/home/dave /gnu/gcc-4.1/gcc/libstdc++-v3/include/backward -I/home/dave/gnu/gcc-4.1/gcc/libs tdc++-v3/testsuite -fmessage-length=0 -ansi -pedantic-errors -Wno-long-long -I /home/dave/gnu/gcc-4.1/gcc/gcc/testsuite/../../libobjc -L/home/dave/gnu/gcc-4 .1/objdir/hppa-linux/./libstdc++-v3/src/.libs -L/home/dave/gnu/gcc-4.1/objdir/h ppa-linux/./libstdc++-v3/src/.libs -L/home/dave/gnu/gcc-4.1/objdir/hppa-linux/./ libiberty -L/home/dave/gnu/gcc-4.1/objdir/hppa-linux/./libobjc/.libs -lobjc -lm -o ./lookup-2.exe(timeout = 300) /home/dave/gnu/gcc-4.1/gcc/gcc/testsuite/obj-c++.dg/lookup-2.mm: In function 'My Widget* _c_Container__elementForView_(objc_object*, const objc_selector*, Foo*)' : /home/dave/gnu/gcc-4.1/gcc/gcc/testsuite/obj-c++.dg/lookup-2.mm:40: error: canno t convert 'objc_object*' to 'MyWidget*' in initialization compiler exited with status 1 output is: /home/dave/gnu/gcc-4.1/gcc/gcc/testsuite/obj-c++.dg/lookup-2.mm: In function 'My Widget* _c_Container__elementForView_(objc_object*, const objc_selector*, Foo*)' : /home/dave/gnu/gcc-4.1/gcc/gcc/testsuite/obj-c++.dg/lookup-2.mm:40: error: canno t convert 'objc_object*' to 'MyWidget*' in initialization FAIL: obj-c++.dg/lookup-2.mm (test for excess errors) -- Summary: lookup-2.mm:40: error: cannot convert 'objc_object*' to 'MyWidget*' in initialization Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: objc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa-unknown-linux-gnu GCC host triplet: hppa-unknown-linux-gnu GCC target triplet: hppa-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26044
[Bug objc++/26043] New: isa-field-1.mm:17: error: 'struct objc_object' has no member named 'isa'
Executing on host: /home/dave/gnu/gcc-4.1/objdir/gcc/testsuite/../g++ -B/home/da ve/gnu/gcc-4.1/objdir/gcc/testsuite/../ /home/dave/gnu/gcc-4.1/gcc/gcc/testsuite /obj-c++.dg/isa-field-1.mm -nostdinc++ -I/home/dave/gnu/gcc-4.1/objdir/hppa-lin ux/libstdc++-v3/include/hppa-linux -I/home/dave/gnu/gcc-4.1/objdir/hppa-linux/li bstdc++-v3/include -I/home/dave/gnu/gcc-4.1/gcc/libstdc++-v3/libsupc++ -I/home/d ave/gnu/gcc-4.1/gcc/libstdc++-v3/include/backward -I/home/dave/gnu/gcc-4.1/gcc/l ibstdc++-v3/testsuite -fmessage-length=0 -ansi -pedantic-errors -Wno-long-long -I/home/dave/gnu/gcc-4.1/gcc/gcc/testsuite/../../libobjc -S -o isa-field-1.s (timeout = 300) /home/dave/gnu/gcc-4.1/gcc/gcc/testsuite/obj-c++.dg/isa-field-1.mm: In function 'objc_class* test1(objc_object*)': /home/dave/gnu/gcc-4.1/gcc/gcc/testsuite/obj-c++.dg/isa-field-1.mm:17: error: 's truct objc_object' has no member named 'isa' /home/dave/gnu/gcc-4.1/gcc/gcc/testsuite/obj-c++.dg/isa-field-1.mm: In function 'objc_class* _i_Object_Test_test1_(Object*, const objc_selector*, objc_object*)' : /home/dave/gnu/gcc-4.1/gcc/gcc/testsuite/obj-c++.dg/isa-field-1.mm:21: error: 's truct objc_object' has no member named 'isa' /home/dave/gnu/gcc-4.1/gcc/gcc/testsuite/obj-c++.dg/isa-field-1.mm: In function 'objc_class* test2(objc_object*)': /home/dave/gnu/gcc-4.1/gcc/gcc/testsuite/obj-c++.dg/isa-field-1.mm:30: error: 's truct objc_object' has no member named 'isa' /home/dave/gnu/gcc-4.1/gcc/gcc/testsuite/obj-c++.dg/isa-field-1.mm: In function 'objc_class* _i_Derived__test2_(Derived*, const objc_selector*, objc_object*)': /home/dave/gnu/gcc-4.1/gcc/gcc/testsuite/obj-c++.dg/isa-field-1.mm:34: error: 's truct objc_object' has no member named 'isa' /home/dave/gnu/gcc-4.1/gcc/gcc/testsuite/obj-c++.dg/isa-field-1.mm: In function 'objc_class* test3(objc_object*)': /home/dave/gnu/gcc-4.1/gcc/gcc/testsuite/obj-c++.dg/isa-field-1.mm:41: error: 's truct objc_object' has no member named 'isa' compiler exited with status 1 -- Summary: isa-field-1.mm:17: error: 'struct objc_object' has no member named 'isa' Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: objc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa-unknown-linux-gnu GCC host triplet: hppa-unknown-linux-gnu GCC target triplet: hppa-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26043
[Bug target/25603] [4.1/4.2 Regression]: Miscompiled FORTRAN program
--- Comment #7 from wilson at gcc dot gnu dot org 2006-01-31 03:49 --- Things start going wrong in the reload inheritance code. For reload 0, for insn 11, we choose to inherit the value already in r14 in an inner loop in choose_reload_regs. Near the end, we double check to make sure we can still inherit it, and notice we can't because the reload_reg_unavailable test fails. We cancel the inheritance, but we continue to use r14 as the reload reg. We then have to reload the value into r14, possibly hoping that post reload cse can simplify the code. Unfortunately, r14 is used in an auto-inc address in this instruction which gets reloaded, so we have two reloads using the same reg, one of which modifies the reg, and this fails miserably. The inheritance code is calling find_equiv_reg, and then doing a number of validity tests on the returned result. One of the tests it does is to call regno_clobbered_p. This makes sure the reg isn't used in a clobber or set, but it makes no attempt to look for other kinds of side-effects, such as auto-inc addresses. I think this is where the error lies. If we modify regno_clobberred_p to handle a REG_INC note the same as a clobber, then we would get the right result here for this testcase, as reload 0 is RELOAD_FOR_OPERAND_ADDRESS. I'm not sure if this works in general though. We might need to be more strict for regs used in a REG_INC note, e.g. we might need to disallow them always. I'm curious whether Bernd's new reload-branch works for this testcase. I don't have a post-svn-conversion copy, so I had to check out a new copy and I'm doing a build now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25603
[Bug java/26042] ICE in mark_reference_fields, at java/boehm.c:105
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-31 03:16 --- Confirmed on powerpc-darwin also. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC host triplet|powerpc-linux | GCC target triplet|powerpc-linux |powerpc-* Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2006-01-31 03:16:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26042
[Bug java/26042] New: ICE in mark_reference_fields, at java/boehm.c:105
This source file, when compiled with gcj produces an ICE:
package x;
class One
{
long l;// no ICE if this is int, not long
int b; // no ICE if this line is gone; type doesn't matter
}
class Two
{
class Three extends One { }
Three three () { return new Three (); }
}
The assertion failure is due to:
/* If this reference slot appears to overlay a slot we think
we already covered, then we are doomed. */
if (offset <= *last_view_index)
abort ();
--
Summary: ICE in mark_reference_fields, at java/boehm.c:105
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bje at gcc dot gnu dot org
GCC host triplet: powerpc-linux
GCC target triplet: powerpc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26042
[Bug tree-optimization/26026] power of 2 mod missing optimisation
-- amodra at bigpond dot net dot au changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |amodra at bigpond dot net |dot org |dot au Status|NEW |ASSIGNED Last reconfirmed|2006-01-30 10:20:23 |2006-01-31 02:45:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26026
[Bug c++/26036] [4.0/4.1/4.2 Regression] Treating a class object as a function with member variables causes hang
--- Comment #3 from mmitchel at gcc dot gnu dot org 2006-01-31 02:44 --- This is a relatively low priority regression; we get valid errors before the crash. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26036
[Bug fortran/26041] FORTRAN compiler won't compile the valid code
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-31 02:04 --- This does not look like valid code. As the types of the dummy z are different. The error message is bogus but that is a different bug. PR 20067. Arrays have nothing to do with it by the way, you can reproduce the error with: module foo publicbar_ interface bar_ module procedure bar end interface publicxxx_ interface xxx_ module procedure xxx end interface contains subroutine xxx(self,z) interface function self(z) result(res) integer :: z real :: res end function end interface call bar_(self) end subroutine subroutine bar(self) interface function self(z) result(res) real :: z real :: res end function end interface end subroutine end And it is obvious from there that bar_ cannot be called from xxx. (Intel's fortran compiler accepts this too which I find weird as this is obvious broken code). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26041
[Bug fortran/26038] FORTRAN segfault
--- Comment #7 from hjl at lucon dot org 2006-01-31 01:52 --- The original code looks like subroutine foo(self) character(*) :: self pointer :: self nullify(self) allocate(self) self = " " end subroutine Is this code valid? How can I make it valid? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26038
[Bug fortran/26041] New: FORTRAN compiler won't compile the valid code
[EMAIL PROTECTED] cpu2006-465]$ cat foo.f90 module foo publicbar_ interface bar_ module procedure bar end interface publicxxx_ interface xxx_ module procedure xxx end interface contains subroutine xxx(self,z) interface function self(z) result(res) real(kind=kind(1.0d0)), dimension(:) :: z real(kind=kind(1.0d0)) :: res end function end interface call bar_(self) end subroutine subroutine bar(self) interface function self(z) result(res) real(kind=kind(1.0d0)) :: res end function end interface end subroutine end [EMAIL PROTECTED] cpu2006-465]$ make /export/build/gnu/gcc/build-x86_64-linux/gcc/gfortran -B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -O2 -S foo.f90 In file foo.f90:18 call bar_(self) 1 Error: Generic subroutine 'bar_' at (1) is not an intrinsic subroutine make: *** [foo.s] Error 1 [EMAIL PROTECTED] cpu2006-465]$ Intel FORTRAN compiler has no problem. If I remove real(kind=kind(1.0d0)), dimension(:) :: z gfortran can compile it. -- Summary: FORTRAN compiler won't compile the valid code Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26041
[Bug c++/9925] ostrstream (buf, size) << "..." does not work properly
--- Comment #20 from pinskia at gcc dot gnu dot org 2006-01-31 01:21 --- More comments about this issue can be found in the following libstdc++ thread: http://gcc.gnu.org/ml/libstdc++/2006-01/msg00177.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9925
[Bug c++/9925] ostrstream (buf, size) << "..." does not work properly
--- Comment #19 from pinskia at gcc dot gnu dot org 2006-01-31 01:20 --- *** Bug 26040 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||Raimund dot Merkert at ||baesystems dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9925
[Bug c++/26040] funny ::std::ostream behavior when using a temporary
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-31 01:20 --- *** This bug has been marked as a duplicate of 9925 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26040
[Bug c++/26040] New: funny ::std::ostream behavior when using a temporary
I'm having trouble understanding what's going on here. Is this a bug in G++ or
possible is the C++ standard a little bit funny, or is it STL?
Perhaps, the result of this code undefined due to the temporary?
I would have expected as output
Hello
Hello
The rationale for this example is the following: I'd like to write a log class
that extends an ostream and I want to use roughly like this:
LogEntry(INFO) << "MyMessage" << LogEntry::commit;
#include
#include
int main()
{
::std::ostringstream ss;
ss << "Hello" ;
::std::cerr << ss.str() << ::std::endl;
::std::string s = static_cast< ::std::ostringstream&>(::std::ostringstream()
<< "Hello2").str();
::std::cerr << s << ::std::endl;
return 0;
}
--
Summary: funny ::std::ostream behavior when using a temporary
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Raimund dot Merkert at baesystems dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26040
[Bug fortran/26038] FORTRAN segfault
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-01-31 01:15 --- Subject: Re: FORTRAN segfault On Jan 30, 2006, at 7:45 PM, hjl at lucon dot org wrote: > Intel FORTRAN compiler has no problem with it. Intel's Fortran compiler does not detect a lot of invalid code, that does not make this code valid. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26038
Re: [Bug fortran/26038] FORTRAN segfault
On Jan 30, 2006, at 7:45 PM, hjl at lucon dot org wrote: Intel FORTRAN compiler has no problem with it. Intel's Fortran compiler does not detect a lot of invalid code, that does not make this code valid. -- Pinski
[Bug target/26018] Assembler errors with -march=z900 compiling glibc
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26018
[Bug target/26018] Assembler errors with -march=z900 compiling glibc
--- Comment #13 from uweigand at gcc dot gnu dot org 2006-01-31 01:11 --- Fixed in mainline and 4.1. -- uweigand at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26018
[Bug tree-optimization/17064] -falias-noargument-global doesn't eliminate dead stores/loads
--- Comment #15 from pinskia at gcc dot gnu dot org 2006-01-31 01:11 --- The other time pi->pt_global_mem is set to 1 is when vi->is_artificial_var and vi->is_heap_var is set. now trying to turn off is_artificial_var and what David pointed out does not work, because we don't have a way to say this is used after the function is done so DCE removes the both sets in the testcase in comment #13. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17064
[Bug target/26018] Assembler errors with -march=z900 compiling glibc
--- Comment #12 from uweigand at gcc dot gnu dot org 2006-01-31 01:09 --- Subject: Bug 26018 Author: uweigand Date: Tue Jan 31 01:09:36 2006 New Revision: 110423 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110423 Log: PR target/26018 * config/s390/s390.c (struct machine_function): New flag decomposed_literal_pool_addresses_ok_p. (s390_reorg): Set it before final stage of literal pool transforms. (s390_decompose_address): Only accept displacements of the form (minus (label_ref ...) (label_ref ...)) if that flag is set. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/config/s390/s390.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26018
[Bug target/26018] Assembler errors with -march=z900 compiling glibc
--- Comment #11 from uweigand at gcc dot gnu dot org 2006-01-31 01:06 --- Subject: Bug 26018 Author: uweigand Date: Tue Jan 31 01:06:16 2006 New Revision: 110422 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110422 Log: PR target/26018 * config/s390/s390.c (struct machine_function): New flag decomposed_literal_pool_addresses_ok_p. (s390_reorg): Set it before final stage of literal pool transforms. (s390_decompose_address): Only accept displacements of the form (minus (label_ref ...) (label_ref ...)) if that flag is set. Modified: trunk/gcc/ChangeLog trunk/gcc/config/s390/s390.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26018
[Bug driver/26021] [4.2 Regression] gcc.c:3866: warning: comparison between signed and unsigned
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2006-01-31 01:04 --- Subject: Re: [4.2 Regression] gcc.c:3866: warning: comparison between signed and unsigned > These show up when MODIFY_TARGET_NAME is defined. This is a macro that I hadn't noticed before. It seems the PA is the only port to define it. The driver options for it don't appear to be documented. It was added by Richard Kenner in 2000 at the request of HP. I doubt it works very well as the default target names in use now don't allow the arbitrary addition and removal of 64 to select between 32 and 64-bit targets. Thus, I'm wondering whether this macro shouldn't just be deleted. I'll ping Steve. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26021
[Bug fortran/26038] FORTRAN segfault
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-01-31 00:59 --- Subject: Re: FORTRAN segfault > > > > --- Comment #4 from hjl at lucon dot org 2006-01-31 00:45 --- > This code is extracted from a much larger program. Intel FORTRAN compiler > has no problem with it. And what should it allocate a zero sized string? -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26038
Re: [Bug fortran/26038] FORTRAN segfault
> > > > --- Comment #4 from hjl at lucon dot org 2006-01-31 00:45 --- > This code is extracted from a much larger program. Intel FORTRAN compiler > has no problem with it. And what should it allocate a zero sized string? -- Pinski
[Bug tree-optimization/17064] -falias-noargument-global doesn't eliminate dead stores/loads
--- Comment #14 from dje at gcc dot gnu dot org 2006-01-31 00:49 --- The parameter is considered global because it is marked DECL_EXTERNAL. And it is marked EXTERNAL in tree-ssa-structalias.c: heapvar = create_tmp_var_raw (TREE_TYPE (TREE_TYPE (t)), PARM_NOALIAS"); DECL_EXTERNAL (heapvar) = 1; Should the temp variable always be marked external? -- dje at gcc dot gnu dot org changed: What|Removed |Added CC||dje at gcc dot gnu dot org, ||dberlin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17064
[Bug fortran/26038] FORTRAN segfault
--- Comment #4 from hjl at lucon dot org 2006-01-31 00:45 --- This code is extracted from a much larger program. Intel FORTRAN compiler has no problem with it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26038
[Bug fortran/26039] ICE with maxval
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-31 00:06 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|-00-00 00:00:00 |2006-01-31 00:06:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26039
[Bug fortran/26038] FORTRAN segfault
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-30 23:59 --- If I change the program to use a constant size string, it works. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||19276 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26038
[Bug fortran/26038] FORTRAN segfault
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-30 23:48 --- This code is meaning less as far as I can tell but it is accepted by Lahey's compilers. Oh don't try redhat's branch please it is not something that is just wrong to do with a modifed compiler at least in bug reports. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26038
[Bug c/22421] problems with -Wformat and bit-fields
--- Comment #11 from wilson at tuliptree dot org 2006-01-30 23:24 ---
Subject: Re: problems with -Wformat and bit-fields
On Mon, 2006-01-23 at 16:06, tony dot luck at intel dot com wrote:
> u64 den : 32, num : 32; /* numerator & denominator */
> printf("den=%lx num=%lx\n", x.den, x.num);
> u.c:9: warning: format %lx expects type long unsigned int, but argument 2
> has type unsigned int
This is deliberate, as per our interpretation of the ISO C99 rules for
integer conversions. If a bit-field has 32-bits, int is a 32-bit type,
and long is a 64-bit type, then the bit-field promotes to int/unsigned
int, even if declared with a long or unsigned long type. If long is a
32-bit type, then the bit-field promotes to long if declared with long
type.
This is mentioned in Joseph's response in comment #2.
See also the testcase that was added for this PR. You can click on the
testsuite link in comment #8 to see it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22421
[Bug fortran/26039] ICE with maxval
--- Comment #1 from tkoenig at gcc dot gnu dot org 2006-01-30 23:16 --- Created an attachment (id=10764) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10764&action=view) patch Same problem (lack of check) with min/maxloc, product and sum, although with different results. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26039
[Bug fortran/26039] New: ICE with maxval
I'm onto this. $ cat maxval.f90 program main integer, dimension(2) :: a logical, dimension(2,1) :: lo a = (/ 1, 2 /) lo = .true. print *,maxval(a,mask=lo) end program main $ gfortran maxval.f90 maxval.f90: In function 'MAIN__': maxval.f90:5: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. $ gdb ~/libexec/gcc/i686-pc-linux-gnu/4.2.0/f951 GNU gdb 6.4-debian Copyright 2005 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486-linux-gnu"...Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (gdb) r maxval.f90 Starting program: /home/ig25/libexec/gcc/i686-pc-linux-gnu/4.2.0/f951 maxval.f90 MAIN__ Program received signal SIGSEGV, Segmentation fault. 0x080a7066 in gfc_conv_loop_setup (loop=0xbfb063b4) at ../../../gcc/t2/gcc/fortran/trans-array.c:2758 2758 if (cshape && INTEGER_CST_P (info->start[n]) (gdb) bt #0 0x080a7066 in gfc_conv_loop_setup (loop=0xbfb063b4) at ../../../gcc/t2/gcc/fortran/trans-array.c:2758 #1 0x080bb11b in gfc_conv_intrinsic_minmaxval (se=0xbfb06bd4, expr=, op=101) at ../../../gcc/t2/gcc/fortran/trans-intrinsic.c:1781 #2 0x080b60ff in gfc_conv_function_expr (se=0xbfb06bd4, expr=0x0) at ../../../gcc/t2/gcc/fortran/trans-expr.c:2251 #3 0x080b25f9 in gfc_conv_expr (se=0xbfb06bd4, expr=0x86df098) at ../../../gcc/t2/gcc/fortran/trans-expr.c:2614 #4 0x080b3c1c in gfc_conv_expr_reference (se=0xbfb06bd4, expr=0x86de5c0) at ../../../gcc/t2/gcc/fortran/trans-expr.c:2724 #5 0x080bde4f in gfc_trans_transfer (code=0x86df440) at ../../../gcc/t2/gcc/fortran/trans-io.c:1835 #6 0x0809fdb1 in gfc_trans_code (code=0x86df440) at ../../../gcc/t2/gcc/fortran/trans.c:579 #7 0x080bfdff in build_dt (function=0xb7b05000, code=0x86df500) at ../../../gcc/t2/gcc/fortran/trans-io.c:1478 #8 0x0809fd8f in gfc_trans_code (code=0x86df500) at ../../../gcc/t2/gcc/fortran/trans.c:555 #9 0x080b0672 in gfc_generate_function_code (ns=0x86de120) at ../../../gcc/t2/gcc/fortran/trans-decl.c:2639 #10 0x08082d6d in gfc_parse_file () at ../../../gcc/t2/gcc/fortran/parse.c:2686 #11 0x0809efad in gfc_be_parse_file (set_yydebug=0) at ../../../gcc/t2/gcc/fortran/f95-lang.c:287 #12 0x0839ba3a in toplev_main (argc=2, argv=0xbfb06eb4) ---Type to continue, or q to quit--- at ../../../gcc/t2/gcc/toplev.c:990 #13 0x080ca5ef in main (argc=2, argv=0x1) at ../../../gcc/t2/gcc/main.c:35 (gdb) q The program is running. Exit anyway? (y or n) Please answer y or n. The program is running. Exit anyway? (y or n) y $ gfortran -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../../gcc/t2/configure --prefix=/home/ig25 --enable-languages=c,fortran Thread model: posix gcc version 4.2.0 20060127 (experimental) -- Summary: ICE with maxval Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26039
[Bug fortran/26038] FORTRAN segfault
--- Comment #1 from hjl at lucon dot org 2006-01-30 22:39 --- It happens on gcc 4.2, 4.1 and 4.0. But gcc-4.1-redhat is fine: [EMAIL PROTECTED] cpu2006]$ /usr/gcc-4.1-redhat/bin/gcc -S foo.f90 -O2 [EMAIL PROTECTED] cpu2006]$ /usr/gcc-4.1-redhat/bin/gcc --version gcc (GCC) 4.1.0 20060128 (Red Hat 4.1.0-0.17) [redhat/gcc-4_1-branch revision 110368 clean] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26038
[Bug fortran/26038] New: FORTRAN segfault
[EMAIL PROTECTED] cpu2006]$ cat foo.f90 subroutine foo(self) character(*) :: self pointer :: self allocate(self) end subroutine [EMAIL PROTECTED] cpu2006]$ /usr/gcc-4.2/bin/gcc -S foo.f90 -m32 foo.f90: In function foo: foo.f90:4: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. [EMAIL PROTECTED] cpu2006]$ /usr/gcc-4.2/bin/gcc --version gcc (GCC) 4.2.0 20060119 (experimental) [trunk revision 109972 clean] -- Summary: FORTRAN segfault Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26038
[Bug target/25384] gcc 4.0.2 compile fails on AIX 5.2: target bigtoc not found
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-30 22:29 --- (In reply to comment #2) > I CAN COMPILE binutils-2.16.1 successfully, but why can't I use them? Because it has not been ported to AIX 5 yet. > What is if i need to compile apps, which need binutils ? Ask the app not here. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25384
[Bug tree-optimization/25413] wrong alignment or incorrect address computation in vectorized code on Pentium 4 SSE
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-01-30 22:24 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|target |tree-optimization Ever Confirmed|0 |1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2006-01-30 22:24:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25413
[Bug fortran/24266] ICE when writing to array of strings that is an elements of a user defined type
--- Comment #4 from eedelman at gcc dot gnu dot org 2006-01-30 22:24 --- Subject: Bug 24266 Author: eedelman Date: Mon Jan 30 22:23:57 2006 New Revision: 110412 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110412 Log: fortran/ 2005-01-30 Erik Edelmann <[EMAIL PROTECTED]> PR fortran/24266 * trans-io.c (set_internal_unit): Check the rank of the expression node itself instead of its symbol. testsuite/ 2005-01-30 Erik Edelmann <[EMAIL PROTECTED]> PR fortran/24266 * gfortran.dg/arrayio_derived_2.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/arrayio_derived_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-io.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24266
[Bug c++/26029] [3.4 Regression] Member initialization by constructor parameter object method calls
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-01-30 22:11 --- Ok, I have now tried a 3.4.x and also a 3.3.x. and found some interesting results. Well it is a regression only in 3.4.1 and above and 3.3.5 and above. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Keywords||wrong-code Known to fail||3.3.6 3.4.5 Known to work||3.4.0 3.3.3 Last reconfirmed|-00-00 00:00:00 |2006-01-30 22:11:57 date|| Summary|Member initialization by|[3.4 Regression] Member |constructor parameter object|initialization by |method calls|constructor parameter object ||method calls Target Milestone|--- |3.4.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26029
[Bug middle-end/25335] [4.1/4.2 Regression] reload leaves insns from earlier passes around: fatal for postinc
--- Comment #7 from hp at gcc dot gnu dot org 2006-01-30 21:53 --- Re: "needing two rounds". Looks like you're hung up on my choice of words. I suggest ignore that and instead just run the test-case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25335
[Bug c++/26029] Member initialization by constructor parameter object method calls
--- Comment #4 from brainchild at skyler dot com 2006-01-30 21:42 --- Sorry, just realized that's not what you asked for. Here is output of gcc -v: $ ./gcc -v Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs Configured with: /gcc/gcc-3.4.4/gcc-3.4.4-1/configure --verbose --prefix=/usr -- exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib --man dir=/usr/share/man --infodir=/usr/share/info --enable-languages=c,ada,c++,d,f77, java,objc --enable-nls --without-included-gettext --enable-version-specific-runt ime-libs --without-x --enable-libgcj --disable-java-awt --with-system-zlib --ena ble-interpreter --disable-libgcj-debug --enable-threads=posix --enable-java-gc=b oehm --disable-win32-registry --enable-sjlj-exceptions --enable-hash-synchroniza tion --enable-libstdcxx-debug : (reconfigured) Thread model: posix gcc version 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26029
[Bug c++/26029] Member initialization by constructor parameter object method calls
--- Comment #3 from brainchild at skyler dot com 2006-01-30 21:40 --- Per your request, the --version output: g++ (GCC) 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125) Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26029
[Bug c++/26029] Member initialization by constructor parameter object method calls
--- Comment #2 from brainchild at skyler dot com 2006-01-30 21:36 --- The gcc version is 3.4.4, the one in the current Cygwin distribution. It must have been fixed since then, though. I downloaded and built gcc 4.0.2 and it gives the correct output, i_=1. So, I guess you can consider it resolved. If it worked on 3.4.0, maybe it was broken between 3.4.0 and 3.4.4, then fixed between 3.4.4 and 4.0.2? If so, may be useful info to have on file for future reference, at least until Cygwin's distribution includes a later version. BTW, I am [EMAIL PROTECTED]; just posting from work instead of home. Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26029
[Bug c++/26029] Member initialization by constructor parameter object method calls
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26029
[Bug middle-end/25335] [4.1/4.2 Regression] reload leaves insns from earlier passes around: fatal for postinc
--- Comment #6 from amylaar at gcc dot gnu dot org 2006-01-30 20:24 --- > Reload seems to need two rounds, but the emitted reload insns for each pass > is left around. This is exposed but not actually caused by the fix for > PR middle-end/24912. Reload should be only called once per function compilation. It iterates till it has a stable set of spills and reloads, and only then does it emit reload insns. So what do you mean with reload needing two rounds? -- amylaar at gcc dot gnu dot org changed: What|Removed |Added CC||joern dot rennecke at st dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25335
[Bug middle-end/26001] [4.1/4.2 Regression] expand uses the wrong part of the string for array accesses
--- Comment #14 from tobi at gcc dot gnu dot org 2006-01-30 19:37 --- (In reply to comment #13) > (In reply to comment #12) > > > this (t02.original) looks like a possible off-by-one error. > > > > [1] here is correct, the arrary bounds is 1:1 and not the C array bounds > > starting at 0. > > I should mention the off by the one error is in expand, where it forgets to > take into account the lower bound of the array. (In reply to comment #13) > (In reply to comment #12) > > > this (t02.original) looks like a possible off-by-one error. > > > > [1] here is correct, the arrary bounds is 1:1 and not the C array bounds > > starting at 0. > > I should mention the off by the one error is in expand, where it forgets to > take into account the lower bound of the array. Sounds like the tree-optimizers should have replaced "0"[1] with '0'. This also sounds like it was pure chance that the bug didn't trigger at -O0. > I will be fixing this after my current bootstrap/test finishes for a different > expand bug. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26001
[Bug middle-end/26001] [4.1/4.2 Regression] expand uses the wrong part of the string for array accesses
--- Comment #15 from pinskia at gcc dot gnu dot org 2006-01-30 19:39 --- (In reply to comment #14) > Sounds like the tree-optimizers should have replaced "0"[1] with '0'. This > also sounds like it was pure chance that the bug didn't trigger at -O0. Yes they should have but that is a tottally different issue which was filed (I forgot the number). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26001
[Bug middle-end/26001] [4.1/4.2 Regression] expand uses the wrong part of the string for array accesses
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-01-30 19:32 --- (In reply to comment #12) > > this (t02.original) looks like a possible off-by-one error. > > [1] here is correct, the arrary bounds is 1:1 and not the C array bounds > starting at 0. I should mention the off by the one error is in expand, where it forgets to take into account the lower bound of the array. I will be fixing this after my current bootstrap/test finishes for a different expand bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26001
[Bug middle-end/26001] [4.1/4.2 Regression] expand uses the wrong part of the string for array accesses
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-01-30 19:27
---
(In reply to comment #11)
> I'm not sure what you're trying to say, so let me rephrase: given the advanced
> state of 4.1 in the relase cycle, it may make sense to revert Feng Wang's
> patch
> in 4.1, and to fix the underlying bug only in the trunk.
That might be a good idea, I was just not thinking too well today for some
reason.
> > Here is the reduced testcase that passes at -O0 but fails at -O1.
> > CHARACTER*10 INTSTR
> > CHARACTER C1
> > DATA INTSTR / '0123456789' /
> >
> > C1 = INTSTR(1:1)
> > print *, C1
> > if(C1 .ne. '0') call abort()
> >
> > end
>
> Thanks, do you still get '1' in the RTL dump if you change INSTR? IOW, does
> it
> address the elements of the string incorrectly,
>
> if (c1[1]{lb: 1 sz: 1} != "0"[1]{lb: 1 sz: 1})
>^^^
> this (t02.original) looks like a possible off-by-one error.
[1] here is correct, the arrary bounds is 1:1 and not the C array bounds
starting at 0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26001
[Bug middle-end/26001] [4.1/4.2 Regression] expand uses the wrong part of the string for array accesses
--- Comment #11 from tobi at gcc dot gnu dot org 2006-01-30 19:23 ---
(In reply to comment #10)
> (In reply to comment #8)
> > Did the regression also happen on 4.1? We should probably revert Feng
> > Wang's
> > patch there.
>
> But there is a latent bug. I don't know a way to reproduce this without
> Feng's
> patch in C or C++, maybe Ada. But the bug is still there.
I'm not sure what you're trying to say, so let me rephrase: given the advanced
state of 4.1 in the relase cycle, it may make sense to revert Feng Wang's patch
in 4.1, and to fix the underlying bug only in the trunk.
> Here is the reduced testcase that passes at -O0 but fails at -O1.
> CHARACTER*10 INTSTR
> CHARACTER C1
> DATA INTSTR / '0123456789' /
>
> C1 = INTSTR(1:1)
> print *, C1
> if(C1 .ne. '0') call abort()
>
> end
Thanks, do you still get '1' in the RTL dump if you change INSTR? IOW, does it
address the elements of the string incorrectly,
if (c1[1]{lb: 1 sz: 1} != "0"[1]{lb: 1 sz: 1})
^^^
this (t02.original) looks like a possible off-by-one error.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26001
[Bug middle-end/26001] [4.1/4.2 Regression] LAPACK testsuite failure with optimization
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-01-30 19:13 --- (In reply to comment #8) > Did the regression also happen on 4.1? We should probably revert Feng Wang's > patch there. But there is a latent bug. I don't know a way to reproduce this without Feng's patch in C or C++, maybe Ada. But the bug is still there. Here is the reduced testcase that passes at -O0 but fails at -O1. CHARACTER*10 INTSTR CHARACTER C1 DATA INTSTR / '0123456789' / C1 = INTSTR(1:1) print *, C1 if(C1 .ne. '0') call abort() end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26001
[Bug middle-end/26001] [4.1/4.2 Regression] LAPACK testsuite failure with optimization
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-01-30 19:08 ---
Actually it is not complete unrolling that is going wrong but expand.
static char intstr[1:10] = "0123456789";
;; if (c1$1 == intstr[1]{lb: 1 sz: 1}) (void) 0; else goto ;
(insn 85 83 86 (set (reg:CCZ 17 flags)
(compare:CCZ (reg:QI 68 [ c1$1 ])
(const_int 49 [0x31]))) -1 (nil)
(nil))
See how we compare that again '1' and not '0'.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|tree-optimization |middle-end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26001
[Bug tree-optimization/26001] [4.1/4.2 Regression] LAPACK testsuite failure with optimization
--- Comment #8 from tobi at gcc dot gnu dot org 2006-01-30 19:07 --- Did the regression also happen on 4.1? We should probably revert Feng Wang's patch there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26001
[Bug tree-optimization/26001] [4.1/4.2 Regression] LAPACK testsuite failure with optimization
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-01-30 19:02 --- Complete unrolling is causing it but I have not looked why. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||rakdver at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26001
[Bug tree-optimization/26001] [4.1/4.2 Regression] LAPACK testsuite failure with optimization
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-01-30 18:59 --- It was the patch which changed string(c:c) == string1(c:c) to be inlined but it is a latent bug from looking at the tree dumps. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|fortran |tree-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26001
[Bug fortran/24266] ICE when writing to array of strings that is an elements of a user defined type
-- eedelman at gcc dot gnu dot org changed: What|Removed |Added CC||eedelman at gcc dot gnu dot ||org AssignedTo|unassigned at gcc dot gnu |eedelman at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24266
[Bug fortran/26001] [4.1/4.2 Regression] LAPACK testsuite failure with optimization
--- Comment #5 from tobi at gcc dot gnu dot org 2006-01-30 18:51 --- There were not many changes to the tree during that time. I think the only possible culprit is Feng Wang's patch for length-one characters. -- tobi at gcc dot gnu dot org changed: What|Removed |Added CC||tobi at gcc dot gnu dot org, ||fengwang at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-01-30 18:51:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26001
[Bug fortran/26001] [4.1/4.2 Regression] LAPACK testsuite failure with optimization
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-01-30 18:49 --- I have a feeling it is one of the string patches that went in around the 8th. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Component|regression |fortran Summary|LAPACK testsuite failure|[4.1/4.2 Regression] LAPACK |with optimization |testsuite failure with ||optimization Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26001
[Bug regression/26001] LAPACK testsuite failure with optimization
--- Comment #3 from kargl at gcc dot gnu dot org 2006-01-30 18:42 --- For a reduced testscase see http://gcc.gnu.org/ml/fortran/2006-01/msg00407.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26001
[Bug c/26004] [4.1/4.2 Regression] gcc errors on valid code [SVO]
--- Comment #6 from amylaar at gcc dot gnu dot org 2006-01-30 18:38 --- (In reply to comment #2) > Strange - both on mainline and the 4.1 branch, I can reproduce this (albeit > with > a more sensible variable name of "u") for i686-pc-linux-gnu native, but not > for > a cross to sh-elf. Yet the failing mark_addressable call is done for i686 > from > the gimplifier. FWIW, the optimization that malfunctions applies to calls of functions that return their value in memory. Because the s_1 type is not returned in memory on sh-elf, the testcase doesn't trigger there. For the test to trigger, s_1 has to be an aggregate (to satisfy the gimple test that this is not a register) which is returned in memory (so that the optimization is relevant), and the return value must be assigne to a variable that is declared as register. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26004
[Bug target/26018] Assembler errors with -march=z900 compiling glibc
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-01-30 18:38 --- (In reply to comment #9) > The problem is the construct &&label1 - &&label2 used in the > source (b.t.w. is this usage of the GCC &&label extension > valid in the first place? It is "correct" but not does could mean something different than what the programmer meant as labels are moved around by the scheduler and maybe for 4.2 by the tree level (if I get my way). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26018
[Bug target/26018] Assembler errors with -march=z900 compiling glibc
--- Comment #9 from uweigand at gcc dot gnu dot org 2006-01-30 18:32 --- This appears to be a pre-existing bug in s390_decompose_address, that happens to be triggered by this particular glibc code. The problem is the construct &&label1 - &&label2 used in the source (b.t.w. is this usage of the GCC &&label extension valid in the first place?), which causes GCSE to generate RTL of the form (minus (label_ref ..) (label_ref ..)) s390_decompose_address accepts those, because I thought the only time this construct could ever be generated is from within the s390 machine-dependent reorg code ... I'm currently testing a fix. -- uweigand at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |uweigand at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-01-30 18:32:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26018
[Bug c/26004] [4.1/4.2 Regression] gcc errors on valid code [SVO]
--- Comment #5 from amylaar at gcc dot gnu dot org 2006-01-30 18:31 --- > It appears we actually don't have any way to query from the > frontend-indenpendent code if we can mark something as > safely. ^ addressable -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26004
[Bug c/26004] [4.1/4.2 Regression] gcc errors on valid code [SVO]
--- Comment #4 from amylaar at gcc dot gnu dot org 2006-01-30 18:29 ---
(In reply to comment #3)
> This is caused by the following code in gimplifier:
> 3297if (use_target)
> 3298 {
> 3299CALL_EXPR_RETURN_SLOT_OPT (*from_p) = 1;
> 3300lang_hooks.mark_addressable (*to_p);
> 3301 }
>
>
> Should we really be calling lang_hooks.mark_addressable, here?
>
I think the problem is actually not testing properly if the value is a
register variable first.
A few lines before in gimplify.c:gimplify_modify_expr_rhs, we have:
else if (is_gimple_reg_type (TREE_TYPE (*to_p)))
/* Also don't force regs into memory. */
use_target = false;
However, is_gimple_reg_type merely looks if the type is an aggregate.
The test that c-typeck.c:c_mark_addressable uses tests C_DECL_REGISTER .
It appears we actually don't have any way to query from the
frontend-indenpendent code if we can mark something as
safely.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26004
[Bug c++/7049] Overloading "cout <<" in one namespace obscures similar functions in a different namespace
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-01-30 18:17 --- *** Bug 21924 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||andre dot maute at gmx dot ||de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7049
[Bug c++/21924] namespace ignored
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-30 18:17 --- Mark as a dup of bug 7049. *** This bug has been marked as a duplicate of 7049 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21924
[Bug c++/21924] namespace ignored
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-30 18:17 --- Reopening to ... -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21924
[Bug c++/26037] no match for 'operator<<'
--- Comment #4 from gdr at integrable-solutions dot net 2006-01-30 18:14 --- Subject: Re: no match for 'operator<<' "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | I should note this is called argument dependent lookup (or ADL, there is | another name for it after a person but he no longer wants to be | associated with this). yup. The printing is a bit ugly though. Should be fixed (not the PR, the printing). -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26037
[Bug c++/26036] [4.0/4.1/4.2 Regression] Treating a class object as a function with member variables causes hang
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-30 18:07 --- I don't get a hang but I do get an ICE after some errors. Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|i686-pc-linux-gnu | GCC host triplet|i686-pc-linux-gnu | GCC target triplet|i686-pc-linux-gnu | Keywords||error-recovery, ice-on- ||invalid-code Known to fail||4.0.3 4.1.0 4.2.0 Known to work||3.4.0 3.3.3 Last reconfirmed|-00-00 00:00:00 |2006-01-30 18:07:47 date|| Summary|Treating a class object as a|[4.0/4.1/4.2 Regression] |function with member|Treating a class object as a |variables causes hang |function with member ||variables causes hang Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26036
[Bug java/21428] [3.4/4.0 Regression] bogus warning: unused parameter 'this'
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-01-30 18:05 --- Fixed for 4.1.0 and 4.2.0 at least. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail||3.4.0 4.0.0 Known to work||4.1.0 4.2.0 3.3.3 Summary|[3.4/4.0/4.1/4.2 Regression]|[3.4/4.0 Regression] bogus |bogus warning: unused |warning: unused parameter |parameter 'this'|'this' Target Milestone|4.1.0 |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21428
[Bug testsuite/25318] [4.1/4.2 Regression] g++.dg/other/pr22003.C (test for excess errors) fails
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-01-30 18:04 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25318
[Bug c++/26037] no match for 'operator<<'
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-30 18:03 --- I should note this is called argument dependent lookup (or ADL, there is another name for it after a person but he no longer wants to be associated with this). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26037
[Bug c/26004] [4.1/4.2 Regression] gcc errors on valid code [SVO]
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-30 18:01 ---
This is caused by the following code in gimplifier:
3297if (use_target)
3298 {
3299CALL_EXPR_RETURN_SLOT_OPT (*from_p) = 1;
3300lang_hooks.mark_addressable (*to_p);
3301 }
Should we really be calling lang_hooks.mark_addressable, here?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||jason at gcc dot gnu dot org
Summary|[4.1/4.2 Regression] gcc|[4.1/4.2 Regression] gcc
|errors on valid code|errors on valid code [SVO]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26004
[Bug c++/7049] Overloading "cout <<" in one namespace obscures similar functions in a different namespace
--- Comment #9 from pcarlini at suse dot de 2006-01-30 18:01 --- ... invalid. -- pcarlini at suse dot de changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7049
[Bug c++/7049] Overloading "cout <<" in one namespace obscures similar functions in a different namespace
--- Comment #8 from pcarlini at suse dot de 2006-01-30 18:00 --- Reopen to adjust to... -- pcarlini at suse dot de changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7049
[Bug c++/26037] no match for 'operator<<'
--- Comment #2 from pcarlini at suse dot de 2006-01-30 18:00 --- Not a bug, this is how name lookup works. And any conforming, up to date, compiler behaves in the same way. You can fix your code moving operator<< inside namespace MyNameSpace. I'm sure there are many duplicates, I'm going to link C++/7049 (see Comment #6) *** This bug has been marked as a duplicate of 7049 *** -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26037
[Bug c++/7049] Overloading "cout <<" in one namespace obscures similar functions in a different namespace
--- Comment #7 from pcarlini at suse dot de 2006-01-30 18:00 --- *** Bug 26037 has been marked as a duplicate of this bug. *** -- pcarlini at suse dot de changed: What|Removed |Added CC||tony dot luu at baesystems ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7049
[Bug c/26004] [4.1/4.2 Regression] gcc errors on valid code
--- Comment #2 from amylaar at gcc dot gnu dot org 2006-01-30 17:42 --- Strange - both on mainline and the 4.1 branch, I can reproduce this (albeit with a more sensible variable name of "u") for i686-pc-linux-gnu native, but not for a cross to sh-elf. Yet the failing mark_addressable call is done for i686 from the gimplifier. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26004
[Bug c++/26036] Treating a class object as a function with member variables causes hang
--- Comment #1 from ben at pc-doctor dot com 2006-01-30 17:41 --- (In reply to comment #0) > Please note that "i" is also undeclared. Err, i is not a variable so ignore that statement. I am assuming gcc is treating the "WrapperClass wrapper0(TestClass(i));" as a declaration instead of instantiation. Still, the compiler should not hang. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26036
[Bug c++/26037] no match for 'operator<<'
--- Comment #1 from tony dot luu at baesystems dot com 2006-01-30 17:31 --- Created an attachment (id=10763) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10763&action=view) test code fail to compile with g++ 3.4.5. compiles ok with other compilers (SGI, SUN). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26037
[Bug c++/26037] New: no match for 'operator<<'
The following stripped-down code fails to compile in g++3.4.5 (compiles fine
with other compilers).
// CODE SNIPPET.
#include
#include
#include
#include
namespace MyNameSpace {
struct Point
{
double x;
double y;
double z;
};
} // namespace
std::ostream&
operator<< (std::ostream& os, const MyNameSpace::Point& src)
{
return os;
}
int
main (void)
{
std::vector polygons;
copy (polygons.begin (), polygons.end (),
std::ostream_iterator (std::cout, " ")); // ERROR
return 0;
}
and g++ generates the following error message:
error: no match for 'operator<<' in
'*((std::ostream_iterator
>*)this)->std::ostream_iterator >::_M_stream << __value'
Note: the code compiles if I removed the namespace.
--
Summary: no match for 'operator<<'
Product: gcc
Version: 3.4.5
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tony dot luu at baesystems dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26037
[Bug target/14798] [3.4/4.0/4.1/4.2 Regression] In case of SH target with -O2 option #pragma interrupt doesn't get resetted.
--- Comment #23 from amylaar at gcc dot gnu dot org 2006-01-30 17:22 --- Fixed on mainline and the 4.1 branch. -- amylaar at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14798
[Bug testsuite/25318] [4.1/4.2 Regression] g++.dg/other/pr22003.C (test for excess errors) fails
--- Comment #3 from sje at gcc dot gnu dot org 2006-01-30 17:06 --- Subject: Bug 25318 Author: sje Date: Mon Jan 30 17:06:16 2006 New Revision: 110405 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110405 Log: PR testsuite/25318 * lib/target-supports.exp (check_effective_target_freorder): Check to see if target supports -freorder-blocks-and-partition. * g++.dg/other/pr22003.C: Use "dg-require-effective-target freorder" instead of "dg-require-named-sections". Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/other/pr22003.C trunk/gcc/testsuite/lib/target-supports.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25318
[Bug testsuite/25318] [4.1/4.2 Regression] g++.dg/other/pr22003.C (test for excess errors) fails
--- Comment #4 from sje at gcc dot gnu dot org 2006-01-30 17:08 --- Subject: Bug 25318 Author: sje Date: Mon Jan 30 17:08:10 2006 New Revision: 110406 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110406 Log: PR testsuite/25318 * lib/target-supports.exp (check_effective_target_freorder): Check to see if target supports -freorder-blocks-and-partition. * g++.dg/other/pr22003.C: Use "dg-require-effective-target freorder" instead of "dg-require-named-sections". Modified: branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/g++.dg/other/pr22003.C branches/gcc-4_1-branch/gcc/testsuite/lib/target-supports.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25318
[Bug c++/26036] New: Treating a class object as a function with member variables causes hang
The following code, while invalid, causes g++ >= 4.0.0 to hang while compiling.
Please note that "i" is also undeclared. GCC 3.4.4 errors out as expected.
class TestClass {
public:
int m_z;
};
class WrapperClass {
public:
TestClass m_test;
};
int main()
{
WrapperClass wrapper0(TestClass(i));
return wrapper0().m_test.m_z++;
}
--
Summary: Treating a class object as a function with member
variables causes hang
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ben at pc-doctor 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=26036
[Bug boehm-gc/25652] Java support for amd64-pc-freebsd
--- Comment #4 from tromey at gcc dot gnu dot org 2006-01-30 16:37 --- You may want to send the GC patch upstream, to the GC list. -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25652
[Bug java/21428] [3.4/4.0/4.1/4.2 Regression] bogus warning: unused parameter 'this'
--- Comment #10 from aph at gcc dot gnu dot org 2006-01-30 16:25 ---
Subject: Bug 21428
Author: aph
Date: Mon Jan 30 16:25:40 2006
New Revision: 110402
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110402
Log:
2006-01-30 Andrew Haley <[EMAIL PROTECTED]>
PR java/21428
* parse.y (source_start_java_method): Mark DECL_ARTIFICIAL("this").
Modified:
branches/gcc-4_1-branch/gcc/java/ChangeLog
branches/gcc-4_1-branch/gcc/java/parse.y
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21428
[Bug target/14798] [3.4/4.0/4.1/4.2 Regression] In case of SH target with -O2 option #pragma interrupt doesn't get resetted.
--- Comment #22 from amylaar at gcc dot gnu dot org 2006-01-30 16:19 --- Subject: Bug 14798 Author: amylaar Date: Mon Jan 30 16:19:11 2006 New Revision: 110401 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110401 Log: PR target/14798: gcc: * sh.c (pragma_interrupt, trap_exit, sp_switch): Remove variable. (pragma_trap, pragma_nosave_low_regs): Likewise. (current_function_anonymous_args): Likewise. (sh_deferred_function_attributes): New variable. (sh_deferred_function_attributes_tail): Likewise. (print_operand): For '@', look up trap_exit attribute. (calc_live_regs): Look up trapa_handler attribute. For trapa handlers, save/restore fpscr, but don't do any other interrupt-specific saves. Don't save r0..r7 if the nosave_low_regs attribute is in effect. Fix check for partially saved registers to check for SHmedia. (sh_expand_prologue, sh_expand_epilogue): Look up sp_switch attribute. (sh_output_function_epilogue): Don't clear any of the removed variables. (sh_insert_attributes): Don't check pragma_interrupt. Insert deferred attributes. Check that interrupt attribute is present for other attributes that require its presence. (sh_attribute_table): Add new attributes trapa_handler and nosave_low_regs. (sh_handle_sp_switch_attribute, sh_handle_trap_exit_attribute): Don't check for pragma_interrupt. Don't store argument. * sh.h (pragma_interrupt, sp_switch): Don't declare. (sh_deferred_function_attributes): Declare. (sh_deferred_function_attributes_tail): Likewise. * sh.md (sp_switch_1): Add operand. Change generator caller. (sh_pr_interrupt, sh_pr_trapa, sh_pr_nosave_low_regs): Remove. (*return_i): Don't use when trap_exit attribute is in effect. (*return_trapa): New insn pattern. * sh-c.c: New file. * config.gcc (sh[123456ble]*-* | sh-*-*): New trailer stanza, setting c_target_objs and cxx_target_objs. * t-sh: Add rule for sh-c.o. * config/sh/sh.c (sh_cfun_trap_exit_p): New function. * sh-protos.h (sh_cfun_trap_exit_p): Declare. gcc/testsuite: * gcc.dg/pragma-isr.c: Added target sh[1234ble]*-*-*. * gcc.dg/pragma-isr2.c, gcc.dg/pragma-isr-trapa.c: New tests. * gcc.dg/pragma-isr-trapa2.c: Likewise. * gcc.dg/pragma-isr-nosave_low_regs.c: Likewise. * gcc.dg/pragma-isr-trap_exit.c: Likewise. * gcc.dg/attr-isr.c, gcc.dg/attr-isr-trapa.c: Likewise. * gcc.dg/attr-isr-trap_exit.c: Likewise. * gcc.dg/attr-isr-nosave_low_regs.c: Likewise. Added: branches/gcc-4_1-branch/gcc/config/sh/sh-c.c - copied unchanged from r110398, trunk/gcc/config/sh/sh-c.c branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/attr-isr-nosave_low_regs.c - copied unchanged from r110398, trunk/gcc/testsuite/gcc.dg/attr-isr-nosave_low_regs.c branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/attr-isr-trap_exit.c - copied unchanged from r110398, trunk/gcc/testsuite/gcc.dg/attr-isr-trap_exit.c branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/attr-isr-trapa.c - copied unchanged from r110398, trunk/gcc/testsuite/gcc.dg/attr-isr-trapa.c branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/attr-isr.c - copied unchanged from r110398, trunk/gcc/testsuite/gcc.dg/attr-isr.c branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/pragma-isr-nosave_low_regs.c - copied unchanged from r110398, trunk/gcc/testsuite/gcc.dg/pragma-isr-nosave_low_regs.c branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/pragma-isr-trap_exit.c - copied unchanged from r110398, trunk/gcc/testsuite/gcc.dg/pragma-isr-trap_exit.c branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/pragma-isr-trapa.c - copied unchanged from r110398, trunk/gcc/testsuite/gcc.dg/pragma-isr-trapa.c branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/pragma-isr-trapa2.c - copied unchanged from r110398, trunk/gcc/testsuite/gcc.dg/pragma-isr-trapa2.c branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/pragma-isr2.c - copied unchanged from r110398, trunk/gcc/testsuite/gcc.dg/pragma-isr2.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/config.gcc branches/gcc-4_1-branch/gcc/config/sh/sh-protos.h branches/gcc-4_1-branch/gcc/config/sh/sh.c branches/gcc-4_1-branch/gcc/config/sh/sh.h branches/gcc-4_1-branch/gcc/config/sh/sh.md branches/gcc-4_1-branch/gcc/config/sh/t-sh branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/pragma-isr.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14798
[Bug java/21428] [3.4/4.0/4.1/4.2 Regression] bogus warning: unused parameter 'this'
--- Comment #9 from aph at gcc dot gnu dot org 2006-01-30 15:40 ---
Subject: Bug 21428
Author: aph
Date: Mon Jan 30 15:40:14 2006
New Revision: 110400
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110400
Log:
2006-01-30 Andrew Haley <[EMAIL PROTECTED]>
PR java/21428
* parse.y: (source_start_java_method): Mark DECL_ARTIFICIAL("this").
Modified:
trunk/gcc/java/ChangeLog
trunk/gcc/java/parse.y
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21428
[Bug target/14798] [3.4/4.0/4.1/4.2 Regression] In case of SH target with -O2 option #pragma interrupt doesn't get resetted.
--- Comment #21 from amylaar at gcc dot gnu dot org 2006-01-30 15:07 --- Subject: Bug 14798 Author: amylaar Date: Mon Jan 30 15:07:43 2006 New Revision: 110398 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110398 Log: PR target/14798: gcc: * sh.c (pragma_interrupt, trap_exit, sp_switch): Remove variable. (pragma_trap, pragma_nosave_low_regs): Likewise. (current_function_anonymous_args): Likewise. (sh_deferred_function_attributes): New variable. (sh_deferred_function_attributes_tail): Likewise. (print_operand): For '@', look up trap_exit attribute. (calc_live_regs): Look up trapa_handler attribute. For trapa handlers, save/restore fpscr, but don't do any other interrupt-specific saves. Don't save r0..r7 if the nosave_low_regs attribute is in effect. Fix check for partially saved registers to check for SHmedia. (sh_expand_prologue, sh_expand_epilogue): Look up sp_switch attribute. (sh_output_function_epilogue): Don't clear any of the removed variables. (sh_insert_attributes): Don't check pragma_interrupt. Insert deferred attributes. Check that interrupt attribute is present for other attributes that require its presence. (sh_attribute_table): Add new attributes trapa_handler and nosave_low_regs. (sh_handle_sp_switch_attribute, sh_handle_trap_exit_attribute): Don't check for pragma_interrupt. Don't store argument. * sh.h (pragma_interrupt, sp_switch): Don't declare. (sh_deferred_function_attributes): Declare. (sh_deferred_function_attributes_tail): Likewise. * sh.md (sp_switch_1): Add operand. Change generator caller. (sh_pr_interrupt, sh_pr_trapa, sh_pr_nosave_low_regs): Remove. (*return_i): Don't use when trap_exit attribute is in effect. (*return_trapa): New insn pattern. * sh-c.c: New file. * config.gcc (sh[123456ble]*-* | sh-*-*): New trailer stanza, setting c_target_objs and cxx_target_objs. * t-sh: Add rule for sh-c.o. gcc/testsuite: * gcc.dg/pragma-isr.c: Added target sh[1234ble]*-*-*. * gcc.dg/pragma-isr2.c, gcc.dg/pragma-isr-trapa.c: New tests. * gcc.dg/pragma-isr-trapa2.c: Likewise. * gcc.dg/pragma-isr-nosave_low_regs.c: Likewise. * gcc.dg/pragma-isr-trap_exit.c: Likewise. * gcc.dg/attr-isr.c, gcc.dg/attr-isr-trapa.c: Likewise. * gcc.dg/attr-isr-trap_exit.c: Likewise. * gcc.dg/attr-isr-nosave_low_regs.c: Likewise. Added: trunk/gcc/config/sh/sh-c.c trunk/gcc/testsuite/gcc.dg/attr-isr-nosave_low_regs.c trunk/gcc/testsuite/gcc.dg/attr-isr-trap_exit.c trunk/gcc/testsuite/gcc.dg/attr-isr-trapa.c trunk/gcc/testsuite/gcc.dg/attr-isr.c trunk/gcc/testsuite/gcc.dg/pragma-isr-nosave_low_regs.c trunk/gcc/testsuite/gcc.dg/pragma-isr-trap_exit.c trunk/gcc/testsuite/gcc.dg/pragma-isr-trapa.c trunk/gcc/testsuite/gcc.dg/pragma-isr-trapa2.c trunk/gcc/testsuite/gcc.dg/pragma-isr2.c Modified: trunk/gcc/ChangeLog trunk/gcc/config.gcc trunk/gcc/config/sh/sh.c trunk/gcc/config/sh/sh.h trunk/gcc/config/sh/sh.md trunk/gcc/config/sh/t-sh trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/pragma-isr.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14798
[Bug target/26014] linking against libgcj results in strange unresolved symbols
--- Comment #7 from alex at milivojevic dot org 2006-01-30 14:50 --- (In reply to comment #5) > ld from binutils 2.16.1 does not resolve this issue. > GNU assembler version 2.16.1 (sparc-sun-solaris2.10) using BFD version 2.16.1 > sparc-sun-solaris2.10 I used recent weekly snapshot of binutils (060124). It works. Now I'm just waiting if Sun is going to include 64bit version of libart_lgpl (either in next beta or in final) and I'm going to be as happy as a pig in a mud ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26014
