[Bug libfortran/31052] [4.2 only] Bad IOSTAT values when readings NAMELISTs past EOF
--- Comment #41 from anlauf at gmx dot de 2007-04-02 08:42 --- (In reply to comment #40) New Revision: 123404 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123404 Log: 2007-04-01 Jerry DeLisle [EMAIL PROTECTED] Jerry, thanks so far, but now I am back to the situation described in comment #23. I will try to produce a new reduced testcase that leads to this crash in the next days. I'd like to ask you to keep this PR open for a few more days until we know whether the other problem is related or unrelated to this PR. Thanks, -ha -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31052
[Bug fortran/31424] New: ICE involving transfer function, and passing function return to subroutine
I get the following ICE: test.f90: In function MAIN__: test.f90:29: internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.c:877 Please submit a full bug report, when compiling this code: module InternalCompilerError type Byte private character(len=1) :: singleByte end type type (Byte) :: BytesPrototype(1) type UserType real :: r end type contains function UserTypeToBytes(user) result (bytes) type(UserType) :: user type(Byte) :: bytes(size(transfer(user, BytesPrototype))) bytes = transfer(user, BytesPrototype) end function subroutine DoSomethingWithBytes(bytes) type(Byte), intent(in) :: bytes(:) end subroutine end module program main use InternalCompilerError type (UserType) :: user ! The following line causes the ICE call DoSomethingWithBytes( UserTypeToBytes(user) ) end program As indicated in the comments, the ICE is caused by the line passing a function result to a subroutine. Kind regards, Drew -- Summary: ICE involving transfer function, and passing function return to subroutine Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: drewmccormack at mac dot com GCC build triplet: gcc version 4.3.0 20070325 (experimental) GCC target triplet: powerpc-apple-darwin8 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31424
Re: gcc-3.4.6 and sh-unknown-linux-gnu build error
Motohisa Moriya wrote: -#if defined (__SH3E__) || defined (__SH4__) +#if defined (__SH4E__) || defined (__SH4__) There's no such thing as an SH4E. There is an SH3E and it shares the same single-precision support as SH4, thus there are some places where I would expect to see such an #if. I don't understand what your problem really is, but it isn't what you think it is. Andrew
[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L
--- Comment #65 from bkoz at redhat dot com 2007-04-02 09:49 --- Subject: Re: __cplusplus defined to 1, should be 199711L Weird, when solaris is the easiest one. That's certainly a matter of perspective. Based on Solaris 11 x86, I don't see a way for say cstdlib to have only the namespace std versions of functions, and not also the global scoped ones. #include iso/stdlib_iso.h (this is how sun studio compiler does it) If you also want the C99 functions, then you have to wait for the next c++ standard to actually exist before solaris changes its headers accordingly. Ah. Thanks for pointing this out to me. Figuring out how to map these files correctly just for solaris will be interesting. My RFC message about C++0x headers had the details on my implementation plan, I think. Sorry for the dumb question, but where is it? Sorry, I cannot find this at the moment. The plan is to correct the includes/c implementation. -benjamin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773
RE: gcc-3.4.6 and sh-unknown-linux-gnu build error
Andrew STUBBS wrote: There's no such thing as an SH4E. There is an SH3E and it shares the same single-precision support as SH4, thus there are some places where I would expect to see such an #if. It is said that the libgcc.a multi-library cannot be made because an impossible register is referred for SH3 if I say easily. It is said that it makes an error of making the multi library in sh-unknown-linux-gnu on the way so that the register definition of 2.4 factions Linux may refer to an impossible combination for this because define is done with SH4E and SH4. Therefore, if this patch is put away without recapitulating as -- target=sh-unknown-linux-gnu, it is sure to become an error. The header file was made here based on crosstools 0.84, and it succeeded in making of all libraries since it had it of seeing the header file. It ..said extent alone.. is not thought that the SH architecture can be basic in my understanding big endian and set little endian to the end. Endian is not seen on the linux side but the SH3 architecture or the SH4 architecture is not passed though the register for SH4 is referred when the header file on the linux side sees the register of SH4 ..seeing... At least, only refer to SH4E SH4 when you see the register added with SH4 on the linux side.
[Bug c++/31164] Problem with GCC 4.1 and Boost signals
--- Comment #4 from pluto at agmk dot net 2007-04-02 10:13 --- attached testcase works fine with vs2k3/boost-1.33/stlport. it also works with g++-4.0.0/20050519(RH 4.0.0-8)/boost/libstdc++ on x86_64-gnu-linux. in the other. indeed, it fails with 4.1.2 and 4.2.0 (4.3 not tested). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31164
Re: gcc-3.4.6 and sh-unknown-linux-gnu build error
Motohisa Moriya wrote: Andrew STUBBS wrote: There's no such thing as an SH4E. There is an SH3E and it shares the same single-precision support as SH4, thus there are some places where I would expect to see such an #if. It is said that the libgcc.a multi-library cannot be made because an impossible register is referred for SH3 if I say easily. It is said that it makes an error of making the multi library in sh-unknown-linux-gnu on the way so that the register definition of 2.4 factions Linux may refer to an impossible combination for this because define is done with SH4E and SH4. Therefore, if this patch is put away without recapitulating as -- target=sh-unknown-linux-gnu, it is sure to become an error. The header file was made here based on crosstools 0.84, and it succeeded in making of all libraries since it had it of seeing the header file. It ..said extent alone.. is not thought that the SH architecture can be basic in my understanding big endian and set little endian to the end. Endian is not seen on the linux side but the SH3 architecture or the SH4 architecture is not passed though the register for SH4 is referred when the header file on the linux side sees the register of SH4 ..seeing... At least, only refer to SH4E SH4 when you see the register added with SH4 on the linux side. Sorry, I find this very hard to read. I think you found it very hard to write. :) I do not say that the code is right. I say that changing SH3E to SH4E is wrong. It might be that completely removing SH3E is right. Perhaps the error is somewhere else. Kaz, I don't know if you have already seen this message. Perhaps you can help Motohisa, both with the compiler and the language barrier? Andrew
[Bug libstdc++/31413] FAIL: 22_locale/time_get/get_date/wchar_t/4.cc execution test
--- Comment #11 from pcarlini at suse dot de 2007-04-02 10:32 --- Ok, therefore we cannot consider anymore the issue a libstdc++ issue. -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31413
[Bug libstdc++/31401] string find behaves strange when searching from npos
--- Comment #5 from paolo at gcc dot gnu dot org 2007-04-02 11:09 --- Subject: Bug 31401 Author: paolo Date: Mon Apr 2 11:08:50 2007 New Revision: 123422 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123422 Log: 2007-04-02 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/31401 (vstring bits) * include/ext/vstring.tcc (find(const _CharT*, size_type, size_type)): Avoid unsigned overflow. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/ext/vstring.tcc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31401
[Bug libstdc++/31401] string find behaves strange when searching from npos
--- Comment #6 from paolo at gcc dot gnu dot org 2007-04-02 11:09 --- Subject: Bug 31401 Author: paolo Date: Mon Apr 2 11:09:07 2007 New Revision: 123423 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123423 Log: 2007-04-02 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/31401 (vstring bits) * include/ext/vstring.tcc (find(const _CharT*, size_type, size_type)): Avoid unsigned overflow. Modified: branches/gcc-4_2-branch/libstdc++-v3/ChangeLog branches/gcc-4_2-branch/libstdc++-v3/include/ext/vstring.tcc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31401
[Bug libstdc++/31370] resizing bugs in std::vectorbool
--- Comment #9 from paolo at gcc dot gnu dot org 2007-04-02 11:16 --- Subject: Bug 31370 Author: paolo Date: Mon Apr 2 11:15:50 2007 New Revision: 123424 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123424 Log: 2007-04-02 Matthew Levine [EMAIL PROTECTED] Paolo Carlini [EMAIL PROTECTED] PR libstdc++/31370 * include/bits/stl_bvector.h (vectorbool::max_size): Fix. (vectorbool::_M_check_len): Add. * include/bits/vector.tcc (_M_fill_insert(iterator, size_type, bool), _M_insert_range(iterator, _ForwardIterator, _ForwardIterator, std::forward_iterator_tag), _M_insert_aux(iterator, bool)): Use it. * testsuite/23_containers/vector/bool/modifiers/insert/31370.cc: New. * testsuite/23_containers/vector/bool/capacity/29134.cc: Adjust. * include/bits/stl_vector.h (vector::_M_check_len): Add. * include/bits/vector.tcc (_M_insert_aux(iterator, const _Tp), _M_fill_insert(iterator, size_type, const value_type), _M_range_insert(iterator, _ForwardIterator, _ForwardIterator, std::forward_iterator_tag)): Use it. Added: trunk/libstdc++-v3/testsuite/23_containers/vector/bool/modifiers/insert/31370.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/stl_bvector.h trunk/libstdc++-v3/include/bits/stl_vector.h trunk/libstdc++-v3/include/bits/vector.tcc trunk/libstdc++-v3/testsuite/23_containers/vector/bool/capacity/29134.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31370
[Bug libstdc++/31370] resizing bugs in std::vectorbool
--- Comment #10 from pcarlini at suse dot de 2007-04-02 11:19 --- Fixed for 4.3.0. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31370
[Bug fortran/31424] ICE involving transfer function, and passing function return to subroutine
--- Comment #1 from pault at gcc dot gnu dot org 2007-04-02 11:33 --- (In reply to comment #0) As indicated in the comments, the ICE is caused by the line passing a function Sort of: In order to find out the size of the function result, gfortran evaluates transfer(user, BytesPrototype). Since BytesPrototype is not referenced in the main program, the ICE Results. Strangely, if we do reference BytesPrototype in MAIN, the program compiles but segfaults at run-time. This appears to be a double bug:) A workaround that is neat and gives the correct result is: module InternalCompilerError type Byte private integer(1) :: singleByte end type type (Byte) :: BytesPrototype(1) type UserType real :: r end type contains function UserTypeToBytes(user) result (bytes) type(UserType) :: user type(Byte) :: bytes(size_of_user (user)) bytes = transfer(user, BytesPrototype) end function subroutine DoSomethingWithBytes(bytes) type(Byte), intent(in) :: bytes(:) print *, bytes end subroutine pure integer function size_of_user ( arg ) type(UserType), intent(in) :: arg size_of_user = size(transfer(arg, BytesPrototype)) end function size_of_user end module program main use InternalCompilerError type (UserType) :: user = UserType (1.0) ! The following line causes the ICE call DoSomethingWithBytes( UserTypeToBytes(user) ) end program Thanks for the report Paul Thomas -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-04-02 11:33:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31424
RE: gcc-3.4.6 and sh-unknown-linux-gnu build error
Andrew STUBBS wrote: Sorry, I find this very hard to read. I think you found it very hard to write. :) I do not say that the code is right. I say that changing SH3E to SH4E is wrong. It might be that completely removing SH3E is right. Perhaps the error is somewhere else. Kaz, I don't know if you have already seen this message. Perhaps you can help Motohisa, both with the compiler and the language barrier? Sorry. I am not good at English. I do not think that it is correct to detach SH3E. I transplanted linux to TMM-1000 and TMM-1200. I am wishing that all of SH2,SH2E, SH3, SH3E, SH4, and SH4E can be compiled with sh-unknown-linux-gnu-gcc. Sorry Mr. Kojima.
Re: gcc-3.4.6 and sh-unknown-linux-gnu build error
Motohisa Moriya wrote: I am wishing that all of SH2,SH2E, SH3, SH3E, SH4, and SH4E can be compiled with sh-unknown-linux-gnu-gcc. SH4E does not exist. Perhaps you mean SH4A?
[Bug fortran/31424] ICE involving transfer function, and passing function return to subroutine
--- Comment #2 from pault at gcc dot gnu dot org 2007-04-02 12:51 --- To my amazement, the brute force: Index: gcc/fortran/trans-decl.c === *** gcc/fortran/trans-decl.c(révision 122688) --- gcc/fortran/trans-decl.c(copie de travail) *** gfc_get_symbol_decl (gfc_symbol * sym) *** 874,879 --- 874,880 int byref; gcc_assert (sym-attr.referenced +|| sym-attr.use_assoc || sym-ns-proc_name-attr.if_source == IFSRC_IFBODY); if (sym-ns sym-ns-proc_name-attr.function) fixes the problem. I have just set it regtesting. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31424
[Bug libf2c/31425] New: gcc 3.4.6 and gcc 4.1.2 on HP 11.23 Itinium (ia64)URGENT
Hi All, I am trying to compile cfengine. I was using gcc version 4.0.2 and was facing an error. I found that the my problem is due to a bug that has been fixed and in version 4.1 onwards. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26189 I rebuild it with gcc version 4.1.2 (binary available on http://hpux.connect.org.uk/) I recompiled, however the issue didnt go off.. -- I decided to build a lower version of gcc . Was able to build gcc-3.4.6 with gnu binutils-2.14., flex and bison(latest GNU versions). My machine does'nt have yacc or lex. I ensured i have gnu make (2.18)too. I got a Warning message while compiling this gcc version as gcc -g -O2 -Wreturn-type -Wmissing-prototypes -Wuninitialized -D_REENTRANT -pthread -g -O2 -I/home/soetest1/cfengine/db-install/include -D_REENTRANT -pthread -g -O2 -I/home/soetest1/cfengine/db-install/include -L/home/soetest1/cfengine/db-install/lib -L/home/soetest1/cfengine/openssl-install/lib -L/opt/dce/lib -L/opt/dce/lib -o cfshow cfshow.o globals.o popen.o log.o errors.o filenames.o patches.o -ll -ll -ldb -lcrypto -L../pub -lpub -lpthread -lm -lc ld: (Warning) Unsatisfied symbol yyleng in file /usr/lib/hpux32/libl.so ld: (Warning) Unsatisfied symbol yylenguc in file /usr/lib/hpux32/libl.so ld: (Warning) Unsatisfied symbol yyinput in file /usr/lib/hpux32/libl.so ld: (Warning) Unsatisfied symbol yyunput in file /usr/lib/hpux32/libl.so ld: (Warning) Unsatisfied symbol yyolsp in file /usr/lib/hpux32/libl.so ld: (Warning) Unsatisfied symbol yytext in file /usr/lib/hpux32/libl.so ld: (Warning) Unsatisfied symbol yyoutput in file /usr/lib/hpux32/libl.so ld: (Warning) Unsatisfied symbol yytextuc in file /usr/lib/hpux32/libl.so ld: (Warning) Unsatisfied symbol yyextra in file /usr/lib/hpux32/libl.so ld: (Warning) Unsatisfied symbol yyfnd in file /usr/lib/hpux32/libl.so ld: (Warning) Unsatisfied symbol yyprevious in file /usr/lib/hpux32/libl.so ld: (Warning) Unsatisfied symbol yylex in file /usr/lib/hpux32/libl.so ld: (Warning) Unsatisfied symbol yylsp in file /usr/lib/hpux32/libl.so ld: (Warning) Unsatisfied symbol yyout in file /usr/lib/hpux32/libl.so ld: (Warning) Unsatisfied symbol yylstate in file /usr/lib/hpux32/libl.so ld: (Warning) Unsatisfied symbol yytextarr in file /usr/lib/hpux32/libl.so ld: (Warning) Unsatisfied symbol yyback in file /usr/lib/hpux32/libl.so 17 warnings. -- I was able to compile cfengine with above however the binaries do not seem to work and give me same error. # /opt/soe/local/soe_cfengine/sbin/cfagent /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yylsp' in load module '/usr/lib/hpux32/libl.so.1'. /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yyolsp' in load module '/usr/lib/hpux32/libl.so.1'. /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yyfnd' in load module '/usr/lib/hpux32/libl.so.1'. /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yytextuc' in load module '/usr/lib/hpux32/libl.so.1'. /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yylenguc' in load module '/usr/lib/hpux32/libl.so.1'. /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yylstate' in load module '/usr/lib/hpux32/libl.so.1'. /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yyprevious' in load module '/usr/lib/hpux32/libl.so.1'. /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yytextarr' in load module '/usr/lib/hpux32/libl.so.1'. /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yyextra' in load module '/usr/lib/hpux32/libl.so.1'. Killed I noticed there is another bug raised and fixed in gcc version 3.4. 3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24718 However it should not give me any issue with 3.4.6. why am I getting the same error? Please advice? Neetee -- Summary: gcc 3.4.6 and gcc 4.1.2 on HP 11.23 Itinium (ia64)URGENT Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libf2c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: npawa at csc dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31425
RE: gcc-3.4.6 and sh-unknown-linux-gnu build error
Andrew STUBBS wrote: Perhaps you mean SH4A? yes Because my debian environment has crashed, -m option cannot be confirmed Please point it out if the mistake is found in my idea. SH2A Core SH2,SH3 SH4A Core SH4 (SH5 is unknown) Motohisa
Re: gcc-3.4.6 and sh-unknown-linux-gnu build error
Hi Andrew, Andrew STUBBS [EMAIL PROTECTED] wrote: I do not say that the code is right. I say that changing SH3E to SH4E is wrong. It might be that completely removing SH3E is right. Perhaps the error is somewhere else. Kaz, I don't know if you have already seen this message. Perhaps you can help Motohisa, both with the compiler and the language barrier? I've missed it. Moriya-san, could you write your real problem in japanese to me. Regards, kaz
[Bug libfortran/31052] [4.2 only] Bad IOSTAT values when readings NAMELISTs past EOF
--- Comment #42 from jvdelisle at gcc dot gnu dot org 2007-04-02 14:35 --- Will keep open until we get them all!. Looks like I need another test case. :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31052
[Bug fortran/31213] ICE on valid code with gfortran
--- Comment #3 from pault at gcc dot gnu dot org 2007-04-02 14:43 --- (In reply to comment #2) an ICE in the same place, but it appears it isn't fixed. Paul, since the previous PRs were really related, you might understand this one easily? I had hoped so, but the problem here turns out to be in resolution. I can fix the reduced testcase but the original is still eluding me. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31213
[Bug middle-end/30704] [4.2/4.3 Regression] Incorrect constant generation for long long
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-02-05 19:43:22 |2007-04-02 14:58:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30704
[Bug libstdc++/31426] New: TR1 includes do not work with -std=c++0x
When the compiler is provided with -std=c++0x to enable the experimental C++0x
mode, includes of TR1 facilities (e.g., tr1/tuple) do not put TR1 functionality
into namespace std::tr1, breaking backward compatibility. Here's an example
program that compiles without -std=c++0x but does not compile with it:
#include tr1/tuple
int main()
{
std::tr1::tupleint, double x(17, 3.14);
return 0;
}
--
Summary: TR1 includes do not work with -std=c++0x
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dgregor at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31426
[Bug target/31380] [4.1/4.2]: Typo in gcc/config/i386/sse.md
--- Comment #3 from hjl at gcc dot gnu dot org 2007-04-02 15:54 --- Subject: Bug 31380 Author: hjl Date: Mon Apr 2 15:53:48 2007 New Revision: 123428 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123428 Log: 2007-04-02 H.J. Lu [EMAIL PROTECTED] * Backport from mainline: 2007-03-28 Grigory Zagorodnev [EMAIL PROTECTED] PR target/31380 * config/i386/sse.md (uminv16qi3): Use UMIN instead of UMAX. Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/config/i386/sse.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31380
[Bug target/31380] [4.1/4.2]: Typo in gcc/config/i386/sse.md
--- Comment #4 from hjl at gcc dot gnu dot org 2007-04-02 15:55 --- Subject: Bug 31380 Author: hjl Date: Mon Apr 2 15:55:17 2007 New Revision: 123429 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123429 Log: 2007-04-02 H.J. Lu [EMAIL PROTECTED] * Backport from mainline: 2007-03-28 Grigory Zagorodnev [EMAIL PROTECTED] PR target/31380 * config/i386/sse.md (uminv16qi3): Use UMIN instead of UMAX. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/config/i386/sse.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31380
[Bug target/31380] [4.1/4.2]: Typo in gcc/config/i386/sse.md
--- Comment #5 from hjl at lucon dot org 2007-04-02 15:57 --- Fixed in gcc 4.1.3 and 4.2.0. -- hjl at lucon dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31380
[Bug libstdc++/31426] TR1 includes do not work with -std=c++0x
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-04-02 16:18 --- isn't that a feature? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31426
[Bug rtl-optimization/323] optimized code gives strange floating point results
--- Comment #94 from bonzini at gnu dot org 2007-04-02 16:20 --- I think that Uros' patch to add a -mpc switch for precision control would fix this. The real fix would be to automatically insert fldcw instructions before float/double operations, in order to limit the precision of the operations. But I think that it would kill speed even more than -ffloat-store. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
[Bug fortran/31114] Consistent floating point arithmetic model option
--- Comment #7 from bonzini at gnu dot org 2007-04-02 16:21 --- Reopened... -- bonzini at gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31114
[Bug fortran/31114] Consistent floating point arithmetic model option
--- Comment #8 from bonzini at gnu dot org 2007-04-02 16:22 --- ... because GCC now has -mpc to limit precision for float/double operations. Even as far as x86 is concerned, this is a special case of PR323, and thus I'm closing it as fixed. -- bonzini at gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.3.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31114
[Bug libstdc++/31426] TR1 includes do not work with -std=c++0x
--- Comment #2 from dgregor at gcc dot gnu dot org 2007-04-02 16:32 --- I don't think it is a feature. In C++0x mode, if one includes tuple, one should get std::tuple. That's what the C++0x working paper says. In any mode, if one includes tr1/tuple, one should get std::tr1::tuple. That's what TR1 says (well, TR1 might say that you get std::tr1::tuple from including tuple; different vendors have done different things, here). I don't think support for C++0x precludes support for TR1. They coexist very well, especially because TR1 was designed to be compatible with C++0x. For example, C++0x-conforming implementations of the TR1 facilities also meet the requirements of TR1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31426
[Bug target/26792] [4.2 Regression] need to use autoconf when using newly-added libgcc functions
--- Comment #31 from sje at cup dot hp dot com 2007-04-02 16:36 --- When configuring with --with-system-libunwind, GCC should not include unwind-compat.o (or any unwind code) in the build of libgcc_s. Then the configure check will work correctly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26792
[Bug fortran/31293] Implicit character and array returning functions
--- Comment #2 from pault at gcc dot gnu dot org 2007-04-02 16:38 ---
This fixes the problem and regtests:
Index: gcc/fortran/parse.c
===
*** gcc/fortran/parse.c (révision 123426)
--- gcc/fortran/parse.c (copie de travail)
*** static void
*** 2896,2901
--- 2896,2902
parse_progunit (gfc_statement st)
{
gfc_state_data *p;
+ gfc_symbol *proc = NULL;
int n;
st = parse_spec (st);
*** parse_progunit (gfc_statement st)
*** 2913,2918
--- 2914,2940
default:
break;
+ }
+
+ proc = gfc_current_ns-proc_name;
+ if (gfc_current_state () == COMP_FUNCTION
+proc-attr.contained
+(proc-attr.implicit_type
+ || proc-result-ts.type == BT_UNKNOWN))
+ {
+ if (gfc_set_default_type (proc-result, 0, gfc_current_ns)
+ == SUCCESS)
+ {
+ if (proc-result != proc)
+ proc-ts = proc-result-ts;
+ }
+ else
+ {
+ gfc_error (unable to implicitly type the function result
+'%s' at %L, proc-result-name,
+proc-result-declared_at);
+ proc-result-attr.untyped = 1;
+ }
}
loop:
It has the same behaviour as LF95, in respect of interface1.f90 - ie. no errors
or warnings, in respect of explcit typing being needed for the function. This
is just a matter of getting the condition right.
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org
|dot org |
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2007-04-02 16:38:36
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31293
[Bug c++/31423] Improve upon invalid use of member (did you forget the '' ?)
--- Comment #1 from bangerth at dealii dot org 2007-04-02 17:09 --- Confirmed. W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-04-02 17:09:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31423
[Bug libstdc++/31426] TR1 includes do not work with -std=c++0x
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-04-02 17:26 --- Ah, I see. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-04-02 17:26:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31426
[Bug preprocessor/29851] Need to strip trailing slashes on include pathnames
--- Comment #3 from eweddington at cso dot atmel dot com 2007-04-02 17:41 --- Can someone please commit this patch? I need this for mingw-hosted cross toolchains. -- eweddington at cso dot atmel dot com changed: What|Removed |Added CC||eweddington at cso dot atmel ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29851
[Bug fortran/31067] MINLOC should sometimes be inlined (gas_dyn is sooooo sloooow)
--- Comment #14 from tkoenig at gcc dot gnu dot org 2007-04-02 17:44 --- I'll give this another shot. Maybe inlining isn't even necessary for good performance... -- 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|NEW |ASSIGNED Last reconfirmed|2007-03-07 21:09:53 |2007-04-02 17:44:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31067
[Bug fortran/31427] New: When I compile the following program I get the message GNU MP: Cannot reallocate memory
When I compile the following program I get the message GNU MP: Cannot reallocate memory PROGRAM test INTEGER(KIND=1) :: i(1) i = (/ TRANSFER(a, 0) /) END PROGRAM test -- Summary: When I compile the following program I get the message GNU MP: Cannot reallocate memory Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: michael dot a dot richmond at nasa dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31427
[Bug c++/31187] [4.2/4.3 regression] extern declaration of variable in anonymous namespace prevents use of its address as template argument
--- Comment #7 from jason at gcc dot gnu dot org 2007-04-02 18:49 --- Subject: Bug 31187 Author: jason Date: Mon Apr 2 18:49:21 2007 New Revision: 123432 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123432 Log: PR c++/31187 * typeck.c (cp_type_readonly): New fn. * cp-tree.h: Declare it. * decl.c (start_decl): Set implicit DECL_THIS_STATIC here. (cp_finish_decl): Not here. * g++.dg/ext/visibility/anon3.C: New test. Added: trunk/gcc/testsuite/g++.dg/ext/visibility/anon3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl.c trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31187
[Bug fortran/31428] New: When I compile the following program I get the message GNU MP: Cannot reallocate memory
When I compile the following program I get the message GNU MP: Cannot reallocate memory PROGRAM test INTEGER(KIND=1) :: i(1) i = (/ TRANSFER(a, 0) /) END PROGRAM test -- Summary: When I compile the following program I get the message GNU MP: Cannot reallocate memory Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: michael dot a dot richmond at nasa dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31428
[Bug fortran/31427] When I compile the following program I get the message GNU MP: Cannot reallocate memory
--- Comment #1 from kargl at gcc dot gnu dot org 2007-04-02 19:06 --- *** Bug 31428 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31427
[Bug fortran/31428] When I compile the following program I get the message GNU MP: Cannot reallocate memory
--- Comment #1 from kargl at gcc dot gnu dot org 2007-04-02 19:06 --- *** This bug has been marked as a duplicate of 31427 *** -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31428
[Bug c/31429] New: Is anybody monitoring the daily regression tests on Darwin 8.5?
-- Summary: Is anybody monitoring the daily regression tests on Darwin 8.5? Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC target triplet: powerpc-apple-darwin7 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31429
[Bug c/31430] New: Is anybody monitoring the daily regression tests on Darwin 8.5?
(~100) of regressions: gcc.c-torture/execute/builtins/memcpy-chk.c, ..., gcc.c-torture/execute/built-in-setjmp.c. Looking at the list, I have found that this has started on 20070325 for Darwin8: http://gcc.gnu.org/ml/gcc-testresults/2007-03/msg01225.html Note that the errors are all of the following kind: output is: /var/tmp//cceFaqh1.s:2000:non-relocatable subtraction expression, L006$pb minus LSJR191 /var/tmp//cceFaqh1.s:2000:symbol: LSJR191 can't be undefined in a subtraction expression ... -- Summary: Is anybody monitoring the daily regression tests on Darwin 8.5? Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC target triplet: powerpc-apple-darwin7 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31430
[Bug target/31429] [4.3 Regression] __builtin_setjmp/__builtin_longjmp is broken on ppc-darwin
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-02 20:05 --- This was caused by the conversion of l constaint to hard registers. I sent a patch to Andreas T. to test as I don't have an up todate sources on my ppc-darwin machine that I use to test patches. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Component|c |target Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-04-02 20:05:27 date|| Summary|Is anybody monitoring the |[4.3 Regression] |daily regression tests on |__builtin_setjmp/__builtin_l |Darwin 8.5? |ongjmp is broken on ppc- ||darwin Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31429
[Bug c/31430] Is anybody monitoring the daily regression tests on Darwin 8.5?
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-02 20:05 --- *** This bug has been marked as a duplicate of 31429 *** -- 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=31430
[Bug target/31429] [4.3 Regression] __builtin_setjmp/__builtin_longjmp is broken on ppc-darwin
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-04-02 20:05 --- *** Bug 31430 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31429
[Bug fortran/31427] When I compile the following program I get the message GNU MP: Cannot reallocate memory
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-04-02 20:10 --- Can confirm a crash in f951. Since there were quite a lot of TRANSFER related reports lately, I can not tell if this a new one. Backtrace: Starting program: /home/daniel/i686-pc-linux-gnu/gcc/libexec/gcc/i686-pc-linux-gnu/4.3.0/f951 -g -Wall 31427.f90 Program received signal SIGSEGV, Segmentation fault. 0xb7f36571 in __gmpn_copyi () from /usr/lib/libgmp.so.3 (gdb) bt #0 0xb7f36571 in __gmpn_copyi () from /usr/lib/libgmp.so.3 #1 0xb7f238b4 in __gmpz_set () from /usr/lib/libgmp.so.3 #2 0x0804d9d6 in gfc_int2int (src=0x8894930, kind=1) at ../../../gcc/gcc/fortran/arith.c:2006 #3 0x0809b1dd in gfc_convert_constant (e=0x8894758, type=BT_INTEGER, kind=1) at ../../../gcc/gcc/fortran/simplify.c:4035 #4 0x08068134 in do_simplify (specific=0x888a3f8, e=0x8894898) at ../../../gcc/gcc/fortran/intrinsic.c:3112 #5 0x08068305 in gfc_convert_type_warn (expr=0x8894898, ts=0x88945ac, eflag=1, wflag=1) at ../../../gcc/gcc/fortran/intrinsic.c:3579 #6 0x08068578 in gfc_convert_type (expr=0x8894898, ts=0x88945ac, eflag=1) at ../../../gcc/gcc/fortran/intrinsic.c:3491 #7 0x0809633f in resolve_code (code=value optimized out, ns=0x885a1e8) at ../../../gcc/gcc/fortran/resolve.c:5163 #8 0x08097a24 in gfc_resolve (ns=0x885a1e8) at ../../../gcc/gcc/fortran/resolve.c:7343 #9 0x0808c0ca in gfc_parse_file () at ../../../gcc/gcc/fortran/parse.c:3245 #10 0x080ab660 in gfc_be_parse_file (set_yydebug=0) at ../../../gcc/gcc/fortran/f95-lang.c:305 #11 0x0830042d in toplev_main (argc=4, argv=0xbfd587f4) at ../../../gcc/gcc/toplev.c:1050 #12 0x080ed162 in main (argc=49, argv=0xa000) at ../../../gcc/gcc/main.c:35 -- dfranke at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||31237 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31427
[Bug c++/31187] [4.2/4.3 regression] extern declaration of variable in anonymous namespace prevents use of its address as template argument
--- Comment #8 from jason at gcc dot gnu dot org 2007-04-02 20:12 --- Subject: Bug 31187 Author: jason Date: Mon Apr 2 20:12:15 2007 New Revision: 123434 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123434 Log: PR c++/31187 * typeck.c (cp_type_readonly): New fn. * cp-tree.h: Declare it. * decl.c (start_decl): Set implicit DECL_THIS_STATIC here. (cp_finish_decl): Not here. * g++.dg/ext/visibility/anon3.C: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/ext/visibility/anon3.C - copied unchanged from r123432, trunk/gcc/testsuite/g++.dg/ext/visibility/anon3.C Modified: branches/gcc-4_2-branch/gcc/cp/ChangeLog branches/gcc-4_2-branch/gcc/cp/cp-tree.h branches/gcc-4_2-branch/gcc/cp/decl.c branches/gcc-4_2-branch/gcc/cp/typeck.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31187
[Bug c++/31431] New: [4.3 regression] ICE with invalid parameter pack
The following (IMHO invalid) code snippet triggers an ICE on mainline:
===
templatetypename..., typename void foo();
void bar()
{
fooint();
}
===
bug.cc: In function 'void bar()':
bug.cc:5: internal compiler error: tree check: expected class 'expression',
have 'type' (integer_type) in fn_type_unification, at cp/pt.c:11058
Please submit a full bug report, [etc.]
The slightly modified version below triggers a segfault:
===
templatetypename, typename..., typename void foo();
void bar()
{
fooint();
}
===
bug.cc: In function 'void bar()':
bug.cc:5: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]
Doug, looks like fallout from your variadic template patch.
Btw., although it's not easter yet, I found a couple of more
variadic easter eggs. They should appear on bugzilla soon. ;-)
--
Summary: [4.3 regression] ICE with invalid parameter pack
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31431
[Bug c++/31431] [4.3 regression] ICE with invalid parameter pack
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31431
[Bug c++/31432] New: [4.3 regression] ICE with invalid parameter pack for template struct
More fallout from the variadic templates on mainline:
===
templatetypename..., typename struct A
{
enum { N };
};
Aint,int a;
===
bug.cc:1: error: parameter pack 'template-parameter-1-1' must be at the end
of the template parameter list
bug.cc: In instantiation of 'Aint, int':
bug.cc:6: instantiated from here
bug.cc:2: error: template argument 1 is invalid
bug.cc:2: error: template argument 1 is invalid
bug.cc:3: error: template argument 1 is invalid
bug.cc:3: error: template argument 1 is invalid
bug.cc:3: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in tsubst_decl, at cp/pt.c:7889
Please submit a full bug report, [etc.]
Btw, why do we have to emit error: template argument 1 is invalid
four times?
--
Summary: [4.3 regression] ICE with invalid parameter pack for
template struct
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31432
[Bug fortran/31257] ICE in gfc_conv_expr_descriptor
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-04-02 20:27 --- Adding this to TRANSFER meta-bug, as frame 3 in the backtrace indicates a relation. No confirmation as I can not tell whether it is a dupe or not. (gdb) bt #0 fancy_abort (file=0x86e4fec ../../../gcc/gcc/fortran/trans-array.c, line=4472, function=0x86e54c7 gfc_conv_expr_descriptor) at ../../../gcc/gcc/diagnostic.c:656 #1 0x080baf5c in gfc_conv_expr_descriptor (se=0xbfa27ad4, expr=0x8894850, ss=0x8895b80) at ../../../gcc/gcc/fortran/trans-array.c:4472 #2 0x080bc19f in gfc_conv_array_parameter (se=0xbfa27ad4, expr=0x8894850, ss=0x8895b80, g77=1) at ../../../gcc/gcc/fortran/trans-array.c:4786 #3 0x080d68fa in gfc_conv_intrinsic_transfer (se=0xbfa281ec, expr=0x8894770) at ../../../gcc/gcc/fortran/trans-intrinsic.c:3111 #4 0x080cc3c2 in gfc_conv_function_expr (se=0xbfa281ec, expr=0x8894850) at ../../../gcc/gcc/fortran/trans-expr.c:2689 #5 0x080cc8e9 in gfc_conv_expr (se=0xbfa281ec, expr=0x8894770) at ../../../gcc/gcc/fortran/trans-expr.c:3129 #6 0x080ce928 in gfc_trans_assignment (expr1=0x8894270, expr2=0x8894770, init_flag=0 '\0') at ../../../gcc/gcc/fortran/trans-expr.c:3823 #7 0x080cf131 in gfc_trans_assign (code=0x8895af8) at ../../../gcc/gcc/fortran/trans-expr.c:3985 #8 0x080b07dd in gfc_trans_code (code=0x8895af8) at ../../../gcc/gcc/fortran/trans.c:473 #9 0x080c7d06 in gfc_generate_function_code (ns=0x885a1e8) at ../../../gcc/gcc/fortran/trans-decl.c:3217 #10 0x0808c2b4 in gfc_parse_file () at ../../../gcc/gcc/fortran/parse.c:3261 #11 0x080ab660 in gfc_be_parse_file (set_yydebug=0) at ../../../gcc/gcc/fortran/f95-lang.c:305 #12 0x0830042d in toplev_main (argc=4, argv=0xbfa284c4) at ../../../gcc/gcc/toplev.c:1050 #13 0x080ed162 in main (argc=2, argv=0x6) at ../../../gcc/gcc/main.c:35 -- dfranke at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||31237 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31257
[Bug c++/31432] [4.3 regression] ICE with invalid parameter pack for template struct
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31432
[Bug c++/31433] New: [4.3 regression] ICE with invalid parameter pack for template struct
More fallout from the variadic templates on mainline:
===
templatetypename..., typename struct A
{
static int i;
};
Aint, int a;
Achar,int b;
===
bug.cc:1: error: parameter pack 'template-parameter-1-1' must be at the end
of the template parameter list
bug.cc: In instantiation of 'Aint, int':
bug.cc:6: instantiated from here
bug.cc:2: error: template argument 1 is invalid
bug.cc:2: error: template argument 1 is invalid
bug.cc:3: error: template argument 1 is invalid
bug.cc: In instantiation of 'Achar, int':
bug.cc:7: instantiated from here
bug.cc:2: error: template argument 1 is invalid
bug.cc:2: error: template argument 1 is invalid
bug.cc:3: error: template argument 1 is invalid
bug.cc:3: internal compiler error: in finish_member_declaration, at
cp/semantics.c:2270
Please submit a full bug report, [etc.]
This is very similar to PR31432, but needs two instantiations of
the template to trigger an ICE.
--
Summary: [4.3 regression] ICE with invalid parameter pack for
template struct
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31433
[Bug c++/31433] [4.3 regression] ICE with invalid parameter pack for template struct
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31433
[Bug c++/31434] New: [4.3 regression] ICE with invalid use of parameter pack in function arg
More fallout from the variadic templates on mainline:
===
templatetypename... T void foo(const T...) {}
void bar()
{
foo(0);
}
===
bug.cc: In function 'void foo(T ...) [with T = int]':
bug.cc:5: instantiated from here
bug.cc:1: internal compiler error: tree check: expected tree_vec, have
error_mark in regenerate_decl_from_template, at cp/pt.c:13791
Please submit a full bug report, [etc.]
The code is (IMHO wrongfully) accepted if I replace the definition of foo by a
declaration.
--
Summary: [4.3 regression] ICE with invalid use of parameter pack
in function arg
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, accepts-invalid, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31434
[Bug c++/31434] [4.3 regression] ICE with invalid use of parameter pack in function arg
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31434
[Bug middle-end/30503] ICE using phase 2 bootstrap output cc1 on tree.c
--- Comment #9 from malitzke at metronets dot com 2007-04-02 20:39 --- I believe this report can be closed. I was able to find the start date (2061125) or a day later when I could no longer bootstrap. It disappeared towards the end of January 2007. It prevented bootstrapping on x86 but not on powerpc. It has not reappeared and was consistent on three x86 machines. It seems that many maintainers ar not doing the complete (and quite time consuming bootstrapping) during the non-regression period. -- malitzke at metronets dot com changed: What|Removed |Added CC||pinskia at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30503
[Bug target/26792] [4.2 Regression] need to use autoconf when using newly-added libgcc functions
--- Comment #32 from schwab at suse dot de 2007-04-02 20:42 --- unwind-compat is _required_ for the system libunwind. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26792
[Bug c++/31435] New: [4.3 regression] ICE with invalid use of parameter pack in function arg
More fallout from the variadic templates on mainline:
===
templatetypename... T void foo(T) {}
void bar()
{
foo(0);
}
===
bug.cc:1: error: parameter packs not expanded with `...':
bug.cc:1: note: 'T'
bug.cc: In function 'void foo(T) [with T = expression error]':
bug.cc:5: instantiated from here
bug.cc:1: internal compiler error: in dependent_type_p, at cp/pt.c:14773
Please submit a full bug report, [etc.]
Similar to PR31434 as this is also invalid use of a parameter pack in a
function argument.
--
Summary: [4.3 regression] ICE with invalid use of parameter pack
in function arg
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31435
[Bug c++/31435] [4.3 regression] ICE with invalid use of parameter pack in function arg
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31435
[Bug c++/31436] New: [4.3 regression] ICE with invalid use of parameter pack in function arg
More fallout from the variadic templates on mainline:
===
templatetypename... T int foo(const T)
{
union { T t; };
return t;
}
void bar()
{
foo(0);
}
===
bug.cc:1: error: parameter packs not expanded with `...':
bug.cc:1: note: 'T'
bug.cc: In function 'int foo(const T) [with T = expression error]':
bug.cc:9: instantiated from here
bug.cc:4: internal compiler error: tree check: expected record_type or
union_type or qual_union_type, have template_type_parm in lookup_conversions,
at cp/search.c:2432
Please submit a full bug report, [etc.]
Similar to PR31434 and PR31435 as this is also invalid use of a
parameter pack in a function argument.
--
Summary: [4.3 regression] ICE with invalid use of parameter pack
in function arg
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31436
[Bug c++/31436] [4.3 regression] ICE with invalid use of parameter pack in function arg
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31436
[Bug c++/31437] New: [4.3 regression] ICE with invalid use of parameter pack in member function arg
More fallout from the variadic templates on mainline:
===
template typename... T struct A
{
A(T* p) { (AT...*)(p); }
};
Aint a(0);
===
bug.cc:3: error: parameter packs not expanded with `...':
bug.cc:3: note: 'T'
bug.cc:3: error: parameter packs not expanded with `...':
bug.cc:3: note: 'T'
bug.cc: In constructor 'AT::A(T*) [with T = int]':
bug.cc:6: instantiated from here
bug.cc:3: internal compiler error: tree check: expected record_type or
union_type or qual_union_type, have template_type_parm in lookup_base, at
cp/search.c:213
Please submit a full bug report, [etc.]
Similar to PR31436 as this is also invalid use of a parameter pack
in a function argument and triggers an ICE in a lookup_* function.
--
Summary: [4.3 regression] ICE with invalid use of parameter pack
in member function arg
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31437
[Bug c++/31437] [4.3 regression] ICE with invalid use of parameter pack in member function arg
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31437
[Bug c++/31438] New: [4.3 regression] ICE with invalid use of parameter pack in specialization
More fallout from the variadic templates on mainline:
===
templatetypename struct A;
templatetypename T, typename... U struct AT(U)
{
templatetypename X A(X);
};
Avoid(int) a(0);
===
bug.cc:3: error: parameter packs not expanded with `...':
bug.cc:3: note: 'U'
bug.cc:4: error: parameter packs not expanded with `...':
bug.cc:4: note: 'U'
bug.cc:5: error: parameter packs not expanded with `...':
bug.cc:5: note: 'U'
bug.cc:8: internal compiler error: tree check: expected tree_vec, have
error_mark in expand_template_argument_pack, at cp/pt.c:2647
Please submit a full bug report, [etc.]
--
Summary: [4.3 regression] ICE with invalid use of parameter pack
in specialization
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31438
[Bug c++/31438] [4.3 regression] ICE with invalid use of parameter pack in specialization
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31438
[Bug c++/31439] New: [4.3 regression] ICE with variadic template and broken specialization
More fallout from the variadic templates on mainline:
===
templatetypename... struct A;
templatechar struct A {};
templatetypename T, typename... U struct AT, U... : AU... {};
Aint a;
===
bug.cc:3: error: template parameters not used in partial specialization:
bug.cc:3: error: 'anonymous'
bug.cc: In instantiation of 'Aint':
bug.cc:7: instantiated from here
bug.cc:1: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]
--
Summary: [4.3 regression] ICE with variadic template and broken
specialization
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31439
[Bug c++/31439] [4.3 regression] ICE with variadic template and broken specialization
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31439
[Bug libstdc++/31440] New: libstdc++-g++-v3 discarded qualifiers
Making all in Core make[3]: Entering directory `/var/tmp/portage/dev-lang/maude-2.1.1-r2/work/maude-2.1.1/src/Core' if g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../../src/Utility -I../../src/Interface -I../../src/Variable -I../../src/FullCompiler -O2 -pipe -mcpu=G4 -fomit-frame-pointer -Wno-deprecated -MT libcore_a-memoTable.o -MD -MP -MF .deps/libcore_a-memoTable.Tpo \ -c -o libcore_a-memoTable.o `test -f 'memoTable.cc' || echo './'`memoTable.cc; \ then mv .deps/libcore_a-memoTable.Tpo .deps/libcore_a-memoTable.Po; \ else rm -f .deps/libcore_a-memoTable.Tpo; exit 1; \ fi /usr/lib/gcc/powerpc-unknown-linux-gnu/4.3.0/include/g++-v3/bits/stl_tree.h: In member function 'typename std::_Rb_tree_Key, _Val, _KeyOfValue, _Compare, _Alloc::iterator std::_Rb_tree_Key, _Val, _KeyOfValue, _Compare, _Alloc::_M_lower_bound(const std::_Rb_tree_node_Val*, const std::_Rb_tree_node_Val*, const _Key) const [with _Key = DagNode*, _Val = std::pairDagNode* const, DagNode*, _KeyOfValue = std::_Select1ststd::pairDagNode* const, DagNode* , _Compare = MemoTable::dagNodeLt, _Alloc = std::allocatorstd::pairDagNode* const, DagNode* ]': /usr/lib/gcc/powerpc-unknown-linux-gnu/4.3.0/include/g++-v3/bits/stl_tree.h:1302: instantiated from 'typename std::_Rb_tree_Key, _Val, _KeyOfValue, _Compare, _Alloc::iterator std::_Rb_tree_Key, _Val, _KeyOfValue, _Compare, _Alloc::find(const _Key) [with _Key = DagNode*, _Val = std::pairDagNode* const, DagNode*, _KeyOfValue = std::_Select1ststd::pairDagNode* const, DagNode* , _Compare = MemoTable::dagNodeLt, _Alloc = std::allocatorstd::pairDagNode* const, DagNode* ]' /usr/lib/gcc/powerpc-unknown-linux-gnu/4.3.0/include/g++-v3/bits/stl_map.h:541: instantiated from 'typename std::_Rb_tree_Key, std::pairconst _Key, _Tp, std::_Select1ststd::pairconst _Key, _Tp , _Compare, typename _Alloc::rebindstd::pairconst _Key, _Tp ::other::iterator std::map_Key, _Tp, _Compare, _Alloc::find(const _Key) [with _Key = DagNode*, _Tp = DagNode*, _Compare = MemoTable::dagNodeLt, _Alloc = std::allocatorstd::pairDagNode* const, DagNode* ]' memoTable.cc:76: instantiated from here /usr/lib/gcc/powerpc-unknown-linux-gnu/4.3.0/include/g++-v3/bits/stl_tree.h:938: error: passing 'const MemoTable::dagNodeLt' as 'this' argument of 'bool MemoTable::dagNodeLt::operator()(const DagNode*, const DagNode*)' discards qualifiers make[3]: *** [libcore_a-memoTable.o] Error 1 make[3]: Leaving directory `/var/tmp/portage/dev-lang/maude-2.1.1-r2/work/maude-2.1.1/src/Core' Without direction I am not swift enough to characterize this further. -- Summary: libstdc++-g++-v3 discarded qualifiers Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: malitzke at metronets dot com GCC build triplet: powerpc-unknown-linux-gnu GCC host triplet: powerpc-unknown-linux-gnu GCC target triplet: powerpc-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31440
[Bug c++/31441] New: [4.3 regression] ICE with variadic template and specialization
More fallout from the variadic templates on mainline:
===
templatetypename struct A;
templatetypename... T struct AT... {};
Aint a;
===
bug.cc:3: error: cannot expand 'T ...' into a fixed-length argument list
bug.cc:5: internal compiler error: in unify, at cp/pt.c:12654
Please submit a full bug report, [etc.]
--
Summary: [4.3 regression] ICE with variadic template and
specialization
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31441
[Bug fortran/31067] MINLOC should sometimes be inlined (gas_dyn is sooooo sloooow)
--- Comment #15 from tkoenig at gcc dot gnu dot org 2007-04-02 21:00 --- The library version doesn't do too badly compared to the inline version: $ cat benchmark-inline.f90 program main implicit none integer, dimension(1) :: n real, allocatable :: a(:) integer :: i allocate (a(100)) call random_number(a) do i=1, 1000 n = minloc(a, dim=1) end do end program main $ cat benchmark-library.f90 program main implicit none integer, dimension(1) :: n real, allocatable :: a(:) integer :: i allocate (a(100)) call random_number(a) do i=1, 1000 n = minloc(a) end do end program main $ gfortran -O3 -static benchmark-inline.f90 ./a.out time ./a.out real0m6.941s user0m5.232s sys 0m0.016s $ gfortran -O3 -static benchmark-library.f90 ./a.out time ./a.out real0m5.720s user0m5.472s sys 0m0.004s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31067
[Bug c++/31441] [4.3 regression] ICE with variadic template and specialization
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31441
[Bug c++/31442] New: [4.3 regression] ICE with variadic template and default argument
More fallout from the variadic templates on mainline:
===
templatetypename... T, T = 0 struct A {};
struct B
{
template template typename... class C B(Cint);
};
B b = Aint();
===
bug.cc:1: error: parameter packs not expanded with `...':
bug.cc:1: note: 'T'
bug.cc:1: error: parameter pack 'T' must be at the end of the template
parameter list
bug.cc: In instantiation of 'Aint':
bug.cc:8: instantiated from here
bug.cc:1: error: template argument 1 is invalid
bug.cc:1: error: template argument 1 is invalid
bug.cc:8: internal compiler error: tree check: expected class 'expression',
have 'type' (integer_type) in unify, at cp/pt.c:12616
Please submit a full bug report, [etc.]
Although this ICE is also in unify as PR31441, it's in a different location.
--
Summary: [4.3 regression] ICE with variadic template and default
argument
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31442
[Bug c++/31442] [4.3 regression] ICE with variadic template and default argument
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31442
[Bug c++/31443] New: [4.3 regression] ICE with invalid use of parameter pack in member template
More fallout from the variadic templates on mainline:
===
templateint, typename... T struct A
{
templateint N void foo(AN,T);
};
void bar()
{
A0,int().foo(A0,int());
};
===
bug.cc:3: error: parameter packs not expanded with `...':
bug.cc:3: note: 'T'
bug.cc: In function 'void bar()':
bug.cc:8: internal compiler error: tree check: accessed elt 2 of tree_vec with
1 elts in unify, at cp/pt.c:12126
Please submit a full bug report, [etc.]
Although this ICE is also in unify as PR31441 and PR31442,
it's in a different location.
--
Summary: [4.3 regression] ICE with invalid use of parameter pack
in member template
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31443
[Bug c++/31443] [4.3 regression] ICE with invalid use of parameter pack in member template
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31443
[Bug c++/31444] New: [4.3 regression] ICE with invalid use of parameter pack in member template
More fallout from the variadic templates on mainline:
===
templatetypename... T struct A
{
templateint void foo(AT);
};
void bar()
{
Aint().foo0(Aint());
};
===
bug.cc:3: error: parameter packs not expanded with `...':
bug.cc:3: note: 'T'
bug.cc: In function 'void bar()':
bug.cc:8: internal compiler error: in tsubst, at cp/pt.c:8466
Please submit a full bug report, [etc.]
This is a slightly simpler testcase than PR31443, but it ICE's in tsubst
instead of unify.
--
Summary: [4.3 regression] ICE with invalid use of parameter pack
in member template
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31444
[Bug c++/31444] [4.3 regression] ICE with invalid use of parameter pack in member template
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31444
[Bug inline-asm/31386] wrong registers used in cmov instruction
--- Comment #3 from ramiro at lisha dot ufsc dot br 2007-04-02 21:24 --- Hello, That and many other combinations fix the issue. Including changing the code around the inline asm, or using different optimizations. What seems wrong is that gcc uses the same register for 2 outputs. Maybe on that specific register pressure it allocates the same register for 2 outputs. Is gcc ever supposed to allow 2 output operands to use the same register? Ramiro Polla -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31386
[Bug c++/31445] New: [4.3 regression] type_argument_pack not supported by dump_type
More fallout from the variadic templates on mainline:
===
template typename... T struct A
{
void foo(T...);
A(T... t) { foo(t); }
};
Aint a(0);
===
This is only a diagnostic problem in the second to last line:
bug.cc: In constructor 'AT::A(T ...)':
bug.cc:4: error: parameter packs not expanded with `...':
bug.cc:4: note: 't'
bug.cc: In constructor 'AT::A(T ...) [with T = int]':
bug.cc:7: instantiated from here
bug.cc:4: error: no matching function for call to
'Aint::foo(#'type_argument_pack' not supported by dump_type#type error)'
bug.cc:3: note: candidates are: void AT::foo(T ...) [with T = int]
--
Summary: [4.3 regression] type_argument_pack not supported by
dump_type
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: diagnostic, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31445
[Bug c++/31445] [4.3 regression] type_argument_pack not supported by dump_type
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31445
[Bug middle-end/192] String literals don't obey -fdata-sections
--- Comment #8 from maskva at searxhmash dot com 2007-04-02 21:27 --- Created an attachment (id=13319) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13319action=view) ned -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=192
[Bug c++/31446] New: [4.2/4.3 regression] ICE with invalid template parameter
The following invalid code snippet triggers an ICE on mainline and 4.2 branch:
===
templatevoid struct A
{
templateint friend void foo();
};
void bar()
{
foo0();
}
===
bug.cc:1: error: 'void' is not a valid type for a template constant parameter
bug.cc: In function 'void bar()':
bug.cc:8: internal compiler error: in retrieve_specialization, at cp/pt.c:856
Please submit a full bug report, [etc.]
--
Summary: [4.2/4.3 regression] ICE with invalid template parameter
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31446
[Bug c++/31446] [4.2/4.3 regression] ICE with invalid template parameter
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31446
[Bug libstdc++/31440] libstdc++-g++-v3 discarded qualifiers
--- Comment #1 from pcarlini at suse dot de 2007-04-02 21:41 --- Thanks for your report. Luckily you have been able to notice this before the release of 4.3.0... -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-04-02 21:41:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31440
[Bug fortran/31447] New: set intent(out) arguments to uninitialized
It would be nice if gfortran had an option to set intent(out) arguments to NaN or some random values, so that code mistakenly relying on intent(out) arguments starting with the same value as in the caller would be detected. This is related to the question of detecting on uninitialized variables. For example, the code subroutine unset(i) integer, intent(out) :: i i = i*2 end subroutine unset program xunset integer :: i i = 1 call unset(i) print*,i=,i end program xunset gives i = 2 but the standard does not require that it do so, since argument i has intent(out). Vivek Rao -- Summary: set intent(out) arguments to uninitialized Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: vivekrao4 at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31447
[Bug tree-optimization/25413] wrong alignment or incorrect address computation in vectorized code on Pentium 4 SSE
--- Comment #5 from reichelt at gcc dot gnu dot org 2007-04-02 21:52
---
Any news on this one?
The bug makes tree vectorization on pentium 4 totally useless. :-(
Btw, here's a smaller code snippet for testing. Just compile it with
gcc -O -msse2 -ftree-vectorize
on a pentium 4 and see the resulting executable segfault:
struct
{
char c;
double d[2];
} a;
int main()
{
int i;
for ( i=0; i2; ++i )
a.d[i]=0;
return 0;
}
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
Keywords||monitored
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25413
[Bug middle-end/30503] ICE using phase 2 bootstrap output cc1 on tree.c
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-04-02 22:13 --- It seems that many maintainers ar not doing the complete (and quite time consuming bootstrapping) during the non-regression period. I think that is wrong as most are, just some forgot to double check. Like at one point -fkeep-inline-functions were broken so if someone bootstrapped their patch before that and posted it and then applied after that was fixed, you would get a bootstrap failure. Also I and many others actually bootstrap on many different targets all the time. I do powerpc64-linux-gnu and i686-linux-gnu as those are the two machines I have access to (well and a cross to spu-elf). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|WAITING |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30503
[Bug middle-end/31448] New: [4.1/4.2/4.3 Regression] ICE in expand_shift with bit fields and expand inlining constants
typedef struct _st {
int iIndex : 24;
} st;
void f(void)
{
st *next = 0;
int nIndx;
const static int constreg[] = { 0,};
nIndx = 0;
next-iIndex = constreg[nIndx];
}
[EMAIL PROTECTED]:~$ ~/x86-linux-4.0.2/bin/gcc t2.c -O1
t2.c: In function 'f':
t2.c:10: internal compiler error: in expand_shift, at expmed.c:2316
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
[EMAIL PROTECTED]:~$ ~/mainlineppc64/bin/powerpc64-linux-gnu-gcc t2.c -O1
t2.c: In function 'f':
t2.c:10: internal compiler error: in expand_shift, at expmed.c:2322
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
--
Summary: [4.1/4.2/4.3 Regression] ICE in expand_shift with bit
fields and expand inlining constants
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31448
[Bug middle-end/31448] [4.1/4.2/4.3 Regression] ICE in expand_shift with bit fields and expand inlining constants
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.0.4 4.1.2 4.2.0 4.3.0 Known to work||3.3.3 Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31448
[Bug target/31137] missing break in switch for MULT in avr_rtx_costs
--- Comment #2 from aesok at gcc dot gnu dot org 2007-04-02 22:44 --- Subject: Bug 31137 Author: aesok Date: Mon Apr 2 22:43:53 2007 New Revision: 123437 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123437 Log: PR target/31137 * config/avr/avr.c (avr_rtx_costs): Add missing 'break' statements. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31137
[Bug target/29524] [4.2/4.3 Regression] Too much RAM used: __clz_tab[] linked
--- Comment #7 from giovannibajo at libero dot it 2007-04-02 22:47 --- Anatoly, can you have a look? It's a regression in 4.2 for AVR! -- giovannibajo at libero dot it changed: What|Removed |Added CC||aesok at pautinka dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29524
[Bug libfortran/31099] [4.3/4.2 regression] Runtime error on legal code using RECL
--- Comment #18 from burnus at gcc dot gnu dot org 2007-04-02 22:49 --- Is this PR fixed or not? Looking at the initial and the additional example, it seems to be fixed both in 4.2 and in 4.3. Can this PR be closed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31099
[Bug target/31137] missing break in switch for MULT in avr_rtx_costs
--- Comment #3 from aesok at gcc dot gnu dot org 2007-04-02 22:53 --- Subject: Bug 31137 Author: aesok Date: Mon Apr 2 22:53:14 2007 New Revision: 123438 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123438 Log: PR target/31137 * config/avr/avr.c (avr_rtx_costs): Add missing 'break' statements. Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/config/avr/avr.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31137
[Bug target/31137] missing break in switch for MULT in avr_rtx_costs
--- Comment #4 from aesok at gcc dot gnu dot org 2007-04-02 23:00 --- Subject: Bug 31137 Author: aesok Date: Mon Apr 2 23:00:28 2007 New Revision: 123439 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123439 Log: PR target/31137 * config/avr/avr.c (avr_rtx_costs): Add missing 'break' statements. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/config/avr/avr.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31137
[Bug target/31137] missing break in switch for MULT in avr_rtx_costs
--- Comment #5 from aesok at gcc dot gnu dot org 2007-04-02 23:03 --- Fixed. -- aesok at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31137
[Bug fortran/31427] When I compile the following program I get the message GNU MP: Cannot reallocate memory
--- Comment #3 from burnus at gcc dot gnu dot org 2007-04-02 23:10 --- Hmm, I cannot reproduce this on x86_64-unknown-linux-gnu/openSUSE 10.2 with either gcc 4.2 (vanilla) nor with gcc 4.3 (current SVN, very mildly patched) and with neither -m32 nor -m64 running under valgrind. (This is with gmp 4.2.1.) -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31427
[Bug rtl-optimization/14737] Purge political statement from -ffast-math docs
--- Comment #8 from manu at gcc dot gnu dot org 2007-04-02 23:25 --- Fixed in GCC 4.3, if someone wants to backport it to old branches, go ahead, the patch should apply cleanly and the Changelog would be similar. -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14737
