[Bug target/19653] x87 reg allocated for constants for -mfpmath=sse
--- Additional Comments From paolo dot bonzini at lu dot unisi dot ch
2005-09-21 06:51 ---
Subject: Re: x87 reg allocated for constants for -mfpmath=sse
Note that in this pattern cost computation of MMX_REGS are all ignored ('*'
in front of y). So, the cost
which is computed is for 'r' which is GENERAL_REGS. This cost is too high and
eventually results in
memory cost to be lower than register cost. I tried the following simple patch
as experiment and got all
the performance back (it is now comparable with 4.0). Note that in this patch,
I removed the '*' in the
2nd alternative so cost of keeping the operand in mmx_regs class is factored
in. This resulted in a
lower cost than that of memory. Is this the way to go? This is just an
experiment which seems to work.
I think it makes sense. The x86 back-end is playing too many tricks
(such as the # classes) with the register allocator and regclass
especially, and they are biting back.
Still, I'd rather hear from an expert as to why the classes were written
like this.
Paolo
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19653
[Bug middle-end/23989] New: DCE removes a loop when it shouldn't
DCE (.t44.dce3) eliminates the third loop in the testcase below, although the print loop should be enough to keep it alive: == subroutine foo(a,b) real a,b type bzz real d(100) end type bzz type (bzz) e dimension a(100), b(100) read *,x,y a=log(x)--- loop 1 b=log(y)--- loop 2 e%d = a+b --- loop 3. eliminated print *,e%d end == See related thread here: http://gcc.gnu.org/ml/gcc/2005-09/msg00645.html -- Summary: DCE removes a loop when it shouldn't Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dorit at il dot ibm dot com CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: ppc64-yellowdog-linux GCC host triplet: ppc64-yellowdog-linux GCC target triplet: ppc64-yellowdog-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23989
[Bug tree-optimization/23948] [4.1 Regression] internal compiler error: verify_stmts failed
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bonzini at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-09-18 18:54:12 |2005-09-21 08:12:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23948
[Bug libstdc++/23990] New: compiling code with wchar_t .. gives linking error
Hi,
I am facing a problem while compiling following code with gcc.
When i compile ofstream with char, it compiles fine.
But it gives linking error with wchar_t.
I compile with command gcc test.cpp
Could someone please look into this and let me know if i need additional
library to compile with ? or what is the exact issue ?
=
#include iostream
#include istream
#include stdio.h
#include wchar.h
#include stdlib.h
#include fstream
#include string
#include iosfwd
using namespace std;
int main(void)
{
//typedef basic_ofstreamchar, char_traitschar wofstream;
typedef basic_ofstreamwchar_t, char_traitswchar_t wofstream;
wofstream wstr;
wstr.open(test.txt,ios::app);
char *abc=TEST;
//strabc;
string t = TEST1;
wchar_t *def=0;
def=(wchar_t*)t.c_str();
wprintf(L%s\n,def);
//print to file -start
wstr\nNEW RUN\n;
wstr(*def);
wstr\nEND\n;
//print to file -end
wstr.close();
return 0;
}
=
Thanks in advance.
Manish
--
Summary: compiling code with wchar_t.. gives linking error
Product: gcc
Version: 3.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: a_manish at yahoo dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23990
[Bug java/21418] Order of source files matters when compiling
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-09-21 09:55 --- Proposed patch: http://gcc.gnu.org/ml/java-patches/2005-q3/msg00401.html -- What|Removed |Added URL||http://gcc.gnu.org/ml/java- ||patches/2005- ||q3/msg00401.html Keywords||patch, rejects-valid http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21418
[Bug middle-end/23991] New: [4.1 Regression]: Gcc failed to build on ia64
This patch: http://gcc.gnu.org/ml/gcc-patches/2005-09/msg01279.html breaks ia64. I got /net/gnu-13/export/gnu/src/gcc/gcc/gcc/final.c: In function `get_attr_length': /net/gnu-13/export/gnu/src/gcc/gcc/gcc/final.c:454: error: `insn_default_length' undeclared (first use in this function) /net/gnu-13/export/gnu/src/gcc/gcc/gcc/final.c:454: error: (Each undeclared identifier is reported only once /net/gnu-13/export/gnu/src/gcc/gcc/gcc/final.c:454: error: for each function it appears in.) /net/gnu-13/export/gnu/src/gcc/gcc/gcc/final.c: In function `get_attr_min_length': /net/gnu-13/export/gnu/src/gcc/gcc/gcc/final.c:462: error: `insn_min_length' undeclared (first use in this function) -- Summary: [4.1 Regression]: Gcc failed to build on ia64 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org CC: gcc-bugs at gcc dot gnu dot org,joern dot rennecke at st dot com GCC build triplet: ia64-unknown-linux-gnu GCC host triplet: ia64-unknown-linux-gnu GCC target triplet: ia64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23991
[Bug c++/23992] New: warning at the time of compiling C++ code using gcc 2.95.3
/opt/gcc/lib/gcc-lib/hppa2.0n-hp-hpux11.00/2.95.3/include/stdio.h:30: warning: ` __va__list' redefined /usr/include/sys/stdsyms.h:422: warning: this is the location of the previous de finition In file included from ../../CommonClasses- C++/AIParser/../CommonHeader/StdHdr.h: 34, from ../../CommonClasses-C++/AIParser/AIParserUtils.h:27, from ../../CommonClasses-C++/AIParser/AIParserUtils.cpp:23: /opt/gcc/lib/gcc-lib/hppa2.0n-hp-hpux11.00/2.95.3/include/string.h:26: warning: `__va__list' redefined /opt/gcc/lib/gcc-lib/hppa2.0n-hp-hpux11.00/2.95.3/include/stdio.h:30: warning: t his is the location of the previous definition /opt/gcc/bin/g++ -c -Wall -O3 ../../CommonClasses- C++/AIParser/AIPars er.cpp -o ../../CommonClasses-C++/AIParser/AIParser.o In file included from ../../CommonClasses- C++/AIParser/../CommonHeader/StdHdr.h: 33, from ../../CommonClasses-C++/AIParser/AIParserUtils.h:27, from ../../CommonClasses-C++/AIParser/AIParser.h:43, from ../../CommonClasses-C++/AIParser/AIParser.cpp:43: /opt/gcc/lib/gcc-lib/hppa2.0n-hp-hpux11.00/2.95.3/include/stdio.h:30: warning: ` __va__list' redefined /usr/include/sys/stdsyms.h:422: warning: this is the location of the previous de finition In file included from ../../CommonClasses- C++/AIParser/../CommonHeader/StdHdr.h: 34, from ../../CommonClasses-C++/AIParser/AIParserUtils.h:27, from ../../CommonClasses-C++/AIParser/AIParser.h:43, from ../../CommonClasses-C++/AIParser/AIParser.cpp:43: /opt/gcc/lib/gcc-lib/hppa2.0n-hp-hpux11.00/2.95.3/include/string.h:26: warning: `__va__list' redefined /opt/gcc/lib/gcc-lib/hppa2.0n-hp-hpux11.00/2.95.3/include/stdio.h:30: warning: t his is the location of the previous definition /opt/gcc/bin/g++ -c -Wall -O3 ../../CommonClasses- C++/AIParser/MainSe ction.cpp -o ../../CommonClasses-C++/AIParser/MainSection.o In file included from ../../CommonClasses- C++/AIParser/../CommonHeader/StdHdr.h: 33, from ../../CommonClasses-C++/AIParser/MainSection.h:36, from ../../CommonClasses-C++/AIParser/MainSection.cpp:22: /opt/gcc/lib/gcc-lib/hppa2.0n-hp-hpux11.00/2.95.3/include/stdio.h:30: warning: ` __va__list' redefined /usr/include/sys/stdsyms.h:422: warning: this is the location of the previous de finition In file included from ../../CommonClasses- C++/AIParser/../CommonHeader/StdHdr.h: 34, from ../../CommonClasses-C++/AIParser/MainSection.h:36, from ../../CommonClasses-C++/AIParser/MainSection.cpp:22: /opt/gcc/lib/gcc-lib/hppa2.0n-hp-hpux11.00/2.95.3/include/string.h:26: warning: `__va__list' redefined /opt/gcc/lib/gcc-lib/hppa2.0n-hp-hpux11.00/2.95.3/include/stdio.h:30: warning: t his is the location of the previous definition /opt/gcc/bin/g++ -c -Wall -O3 ../../CommonClasses- C++/AIParser/DirSec tion.cpp -o ../../CommonClasses-C++/AIParser/DirSection.o In file included from ../../CommonClasses- C++/AIParser/../CommonHeader/StdHdr.h: 33, from ../../CommonClasses-C++/AIParser/DirSection.h:35, from ../../CommonClasses-C++/AIParser/DirSection.cpp:20: /opt/gcc/lib/gcc-lib/hppa2.0n-hp-hpux11.00/2.95.3/include/stdio.h:30: warning: ` __va__list' redefined /usr/include/sys/stdsyms.h:422: warning: this is the location of the previous de finition In file included from ../../CommonClasses- C++/AIParser/../CommonHeader/StdHdr.h: 34, from ../../CommonClasses-C++/AIParser/DirSection.h:35, from ../../CommonClasses-C++/AIParser/DirSection.cpp:20: /opt/gcc/lib/gcc-lib/hppa2.0n-hp-hpux11.00/2.95.3/include/string.h:26: warning: `__va__list' redefined /opt/gcc/lib/gcc-lib/hppa2.0n-hp-hpux11.00/2.95.3/include/stdio.h:30: warning: t his is the location of the previous definition /opt/gcc/bin/g++ -c -Wall -O3 ../../CommonClasses- C++/AIParser/Parser Process.cpp -o ../../CommonClasses-C++/AIParser/ParserProcess.o In file included from ../../CommonClasses- C++/AIParser/../CommonHeader/StdHdr.h: 33, from ../../CommonClasses-C++/AIParser/ParserProcess.h:13, from ../../CommonClasses-C++/AIParser/ParserProcess.cpp:20: /opt/gcc/lib/gcc-lib/hppa2.0n-hp-hpux11.00/2.95.3/include/stdio.h:30: warning: ` __va__list' redefined /usr/include/sys/stdsyms.h:422: warning: this is the location of the previous de finition In file included from ../../CommonClasses- C++/AIParser/../CommonHeader/StdHdr.h: 34, from ../../CommonClasses-C++/AIParser/ParserProcess.h:13, from ../../CommonClasses-C++/AIParser/ParserProcess.cpp:20: /opt/gcc/lib/gcc-lib/hppa2.0n-hp-hpux11.00/2.95.3/include/string.h:26: warning: `__va__list' redefined /opt/gcc/lib/gcc-lib/hppa2.0n-hp-hpux11.00/2.95.3/include/stdio.h:30: warning: t
[Bug libstdc++/23990] compiling code with wchar_t .. gives linking error
--- Additional Comments From a_manish at yahoo dot com 2005-09-21 10:10 --- compilation output errors: g++ test.cpp Undefined first referenced symbol in file std::char_traitswchar_t::to_char_type(unsigned long const)/var/tmp//cc984pNB. o std::char_traitswchar_t::copy(wchar_t*, wchar_t const*, unsigned)/var/tmp//cc9 84pNB.o std::char_traitswchar_t::not_eof(unsigned long const)/var/tmp//cc984pNB.o std::basic_filebufwchar_t, std::char_traitswchar_t ::_M_underflow_common(boo l)/var/tmp//cc984pNB.o std::char_traitswchar_t::eq_int_type(unsigned long const, unsigned long const )/var/tmp//cc984pNB.o std::char_traitswchar_t::assign(wchar_t, wchar_t const)/var/tmp//cc984pNB.o std::char_traitswchar_t::assign(wchar_t*, unsigned, wchar_t)/var/tmp//cc984pNB .o std::char_traitswchar_t::to_int_type(wchar_t const)/var/tmp//cc984pNB.o std::char_traitswchar_t::eq(wchar_t const, wchar_t const)/var/tmp//cc984pNB. o std::char_traitswchar_t::eof()/var/tmp//cc984pNB.o std::char_traitswchar_t::length(wchar_t const*)/var/tmp//cc984pNB.o ld: fatal: Symbol referencing errors. No output written to a.out collect2: ld returned 1 exit status -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23990
[Bug libstdc++/23990] compiling code with wchar_t .. gives linking error
--- Additional Comments From chris at bubblescope dot net 2005-09-21 10:13 --- Could you provide the output of g++ -v, and the operating system you are using? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23990
[Bug libstdc++/23990] compiling code with wchar_t .. gives linking error
--- Additional Comments From a_manish at yahoo dot com 2005-09-21 10:26 --- === i am compiling on sol9 machine g++ -v Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.3.2/specs Configured with: ../configure --with-as=/usr/ccs/bin/as --with- ld=/usr/ccs/bin/ld --disable-nls --disable-libgcj --enable-languages=c,c++ : (reconfigured) ../configure --with-as=/usr/ccs/bin/as --with- ld=/usr/ccs/bin/ld --disable-nls --disable-libgcj --enable-languages=c,c++ Thread model: posix gcc version 3.3.2 === -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23990
[Bug c++/23993] New: Misterious compiler error when accessing a 2d-array in a template class
The compiler will give the compile-time error: invalid lvalue in unary ''
The following code not only shows the bug, but also the non-template based
implementation that runs and compiles perfectly. The two dimensional array is
essential to observe the problem. The template code will run and
compile perfectly when the 2d array is replaced by a 1d array.
#include iostream
#include vector
/*
const int data[2][4] = {
{0, 1, 2, 3},
{4, 5, 6, 7}
};
*/
// For a one dimensional array the code compiles and runs in the policy based
// case
const int data[4] = {
4, 5, 6, 7
};
//This template implementation doesn't even compile due to some strange
//compile-time error.
// BEGIN TEMPLATE CODE ---
template typename T
class ExtremalInt {
private:
T extremal;
public:
ExtremalInt() : extremal(3) {
}
void operator()(int k) {
int candidate = data[k];
if (extremal candidate) {
extremal = candidate;
}
}
const int result() const {
return extremal;
}
};
typedef ExtremalIntint MaxExtremalInt;
// END TEMPLATE CODE ---
/*
// BEGIN EQUIVALENT CODE ---
class MaxExtremalInt {
private:
int extremal;
public:
MaxExtremalInt() : extremal(3) {
}
void operator()(int k) {
int candidate = data[1][k];
if (extremal candidate) {
extremal = candidate;
}
}
const int result() const {
return extremal;
}
};
// END EQUIVALENT CODE ---
*/
int main() {
int result;
std::vectorint array;
array.push_back(1); //5
array.push_back(3); //7
array.push_back(2); //6
MaxExtremalInt sMax;
result = std::for_each(array.begin(), array.end(), sMax).result();
std::cout Result: result \n;
}
--
Summary: Misterious compiler error when accessing a 2d-array in a
template class
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bdonner at physik dot tu-muenchen dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23993
[Bug c++/23993] Misterious compiler error when accessing a 2d-array in a template class
--- Additional Comments From bdonner at physik dot tu-muenchen dot de 2005-09-21 10:41 --- Created an attachment (id=9786) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9786action=view) Code to reproduce the bug -- correct version The inline posted version incorrectly shows the 1d instead of the 2d case. Sorry this is my fault. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23993
[Bug fortran/23994] New: PROTECTED attribute (F2003) is not implemented
Fortran 2003 defines the PROTECTED attribute for variables in modules. Example: --- MODULE temperature REAL,PROTECTED :: temp CONTAINS SUBROUTINE set_temperature temp = 0.0 END SUBROUTINE END MODULE use temperature call set_temperature print *, temp temp = 42 end --- The compiler should issue an error message on that code (temp cannot be modified from outside the module) but the code should compile fine without the temp = 42 line. The only compiler I know that behaves correctly right now is IBM's. -- Summary: PROTECTED attribute (F2003) is not implemented Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org OtherBugsDependingO 20585 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23994
[Bug fortran/20585] [meta-bug] Fortran 2003 support
-- What|Removed |Added BugsThisDependsOn||23994 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20585
[Bug ada/23995] New: GNAT BUG DETECTED
spr16hmf:spluser(568) ~/tmp gcc -v -gnatv -c test_gcc_4_0_1.ads Using built-in specs. Target: sparc-sun-solaris2.9 Configured with: /usr/local/src/tmp/GCC/4.0/gcc-4.0.1/configure --prefix=/usr/local/GCC/4.0/1 --enable-threads=posix --enable-languages=c,ada,c++,f95,java,objc,treelang --with-gmp=/usr/local/GNU/Maths/GMP/4.1/4/ --with-mpfr=/usr/local/GNU/Maths/GMP/4.1/4/ Thread model: posix gcc version 4.0.1 /usr/local/GCC/4.0/1/libexec/gcc/sparc-sun-solaris2.9/4.0.1/gnat1 -quiet -dumpbase test_gcc_4_0_1.ads -gnatv -mcpu=v7 test_gcc_4_0_1.ads -o /tmp/ccxtpfCn.s GNAT 4.0.1 Copyright 1992-2005 Free Software Foundation, Inc. Compiling: test_gcc_4_0_1.ads (source file time stamp: 2005-09-21 10:41:55) +===GNAT BUG DETECTED==+ | 4.0.1 (sparc-sun-solaris2.9) in expand_expr_addr_expr_1, at expr.c:6222 | | No source file position information available| | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. test_gcc_4_0_1.ads 24 lines: No errors compilation abandoned test_gcc_4_0_1.ads: package test_gcc_4_0_1 is type test1 is record b2 : BOOLEAN := TRUE ; b3 : BOOLEAN ; b4 : BOOLEAN ; b1 : BOOLEAN ; end record ; FOR test1 use record b1 at 0 range 00 .. 00 ; b2 at 0 range 01 .. 01 ; b3 at 0 range 02 .. 02 ; b4 at 0 range 03 .. 03 ; end record ; type test_A is record t1 : test1 ; end record ; for test_A use record -- t1 at 0 range 0 .. 3 ; t1 at 0 range 1 .. 4 ; end record ; end test_gcc_4_0_1 ; --- Additional informations: 1. if b2 has no default value, then compiling succeeds 2. if t1 starts at the first bit of a byte (commented line t1 at 0 range 0 .. 3 ;), then compiling succeeds. 3. the compiling succeeds with gcc 3.3 Thank you for your help With best regards Michael Foerster -- Summary: GNAT BUG DETECTED Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: critical Priority: P1 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: michael dot foerster at eads dot com CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: sparc-sun-solaris2.9 GCC host triplet: sparc-sun-solaris2.9 GCC target triplet: sparc-sun-solaris2.9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23995
[Bug fortran/23994] PROTECTED attribute (F2003) is not implemented
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-09-21 10:55:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23994
[Bug libstdc++/23990] compiling code with wchar_t .. gives linking error
--- Additional Comments From chris at bubblescope dot net 2005-09-21 11:01 --- Hopefully someone with more Solaris knowledge than me may come along (the code works fine on any OSes I can get my hands on) As a temporary fix, you might find putting template class char_traitswchar_t; in your code (just after using namespace std; should do) should force the generation of the missing functions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23990
[Bug libstdc++/23990] compiling code with wchar_t .. gives linking error
-- What|Removed |Added GCC target triplet||sparc-sun-solaris2.9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23990
[Bug middle-end/23991] [4.1 Regression]: Gcc failed to build on ia64
-- What|Removed |Added Keywords||build Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23991
[Bug c++/23992] warning at the time of compiling C++ code using gcc 2.95.3
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-21 11:08 --- 2.95.3 is not really supported any more. -- What|Removed |Added GCC target triplet||hppa2.0n-hp-hpux11.00 Summary|warning at the time of |warning at the time of |compiling C++ code using gcc|compiling C++ code using gcc |2.95.3 |2.95.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23992
[Bug libstdc++/23990] compiling code with wchar_t .. gives linking error
--- Additional Comments From a_manish at yahoo dot com 2005-09-21 11:21 --- Thanks for replying. But additing Fwd declaration did not help. I am still getting the errors : += g++ wofstream.cpp Undefined first referenced symbol in file std::char_traitswchar_t::to_char_type(unsigned long const)/var/tmp//cc2EXdA1.o std::char_traitswchar_t::copy(wchar_t*, wchar_t const*, unsigned)/var/tmp//cc2EXdA1.o std::char_traitswchar_t::not_eof(unsigned long const)/var/tmp//cc2EXdA1.o std::basic_filebufwchar_t, std::char_traitswchar_t ::_M_underflow_common (bool)/var/tmp//cc2EXdA1.o std::char_traitswchar_t::eq_int_type(unsigned long const, unsigned long const)/var/tmp//cc2EXdA1.o std::char_traitswchar_t::assign(wchar_t, wchar_t const)/var/tmp//cc2EXdA1.o std::char_traitswchar_t::assign(wchar_t*, unsigned, wchar_t)/var/tmp//cc2EXdA1.o std::char_traitswchar_t::to_int_type(wchar_t const)/var/tmp//cc2EXdA1.o std::char_traitswchar_t::eq(wchar_t const, wchar_t const)/var/tmp//cc2EXdA1.o std::char_traitswchar_t::eof()/var/tmp//cc2EXdA1.o std::char_traitswchar_t::length(wchar_t const*)/var/tmp//cc2EXdA1.o ld: fatal: Symbol referencing errors. No output written to a.out collect2: ld returned 1 exit status +== -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23990
[Bug c++/23993] [4.0/4.1 Regression] Misterious compiler error when accessing a 2d-array in a template class
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-21
11:24 ---
Confirmed, reduced testcase:
const int data[2][4] = {
{0, 1, 2, 3}
};
template typename T
void t(int k) {
int candidate = data[1][k];
}
--
What|Removed |Added
CC||mmitchel at gcc dot gnu dot
||org
Severity|normal |critical
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Keywords||rejects-valid
Known to fail||4.1.0 4.0.2
Known to work||4.0.0 4.0.1
Last reconfirmed|-00-00 00:00:00 |2005-09-21 11:24:24
date||
Summary|Misterious compiler error |[4.0/4.1 Regression]
|when accessing a 2d-array in|Misterious compiler error
|a template class|when accessing a 2d-array in
||a template class
Target Milestone|--- |4.0.2
Version|4.0.1 |4.0.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23993
[Bug fortran/23994] PROTECTED attribute (F2003) is not implemented
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-09-21 11:26 --- [in answer to pinskia, who added the keyword accepts-invalid] Currently, gfortran doesn't accept this code: $ gfortran -std=f2003 a.f90 In file a.f90:2 REAL,PROTECTED :: temp 1 Error: Syntax error in data declaration at (1) In the future, it should accept the PROTECTED attribute at line 2, and issue an error (or warning) at line 12. Removing keyword accordingly. -- What|Removed |Added Keywords|accepts-invalid | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23994
[Bug middle-end/23991] [4.1 Regression]: Gcc failed to build on ia64
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-21
11:28 ---
Confirmed, it is kinda of interesting that IA64 is one of the few targets which
does not have the length
attr (or have HAVE_ATTR_length defined).
The easy fix is the following:
int
get_attr_length (rtx insn)
{
#ifdef HAVE_ATTR_length
return get_attr_length_1 (insn, insn_default_length);
#else
return get_attr_length_1 (insn, 0);
#endif
}
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |2005-09-21 11:28:43
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23991
[Bug tree-optimization/23989] [4.1 Regression] DCE removes a loop when it shouldn't
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-21 11:30 --- This should be fixed by: http://gcc.gnu.org/ml/gcc-patches/2005-09/msg01294.html -- What|Removed |Added Component|middle-end |tree-optimization Keywords||wrong-code Known to fail||4.1.0 Known to work||4.0.0 4.0.1 Summary|DCE removes a loop when it |[4.1 Regression] DCE removes |shouldn't |a loop when it shouldn't Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23989
[Bug fortran/23994] PROTECTED attribute (F2003) is not implemented
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-21 11:32 --- I got this wrong because I thought from comment one it was accepting the attribute already but just ignoring it. -- What|Removed |Added Keywords||rejects-valid http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23994
[Bug c++/23993] [4.0/4.1 Regression] Misterious compiler error when accessing a 2d-array in a template class
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-21 12:19 --- I forgot to mention that this worked with 4.0.2 20050826 but failed with 4.0.2 20050915. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23993
[Bug c++/23993] [4.0/4.1 Regression] Misterious compiler error when accessing a 2d-array in a template class
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23993
[Bug tree-optimization/23989] [4.1 Regression] DCE removes a loop when it shouldn't
--- Additional Comments From dorit at il dot ibm dot com 2005-09-21 13:16 --- Indeed. This bug can be closed now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23989
[Bug tree-optimization/23989] [4.1 Regression] DCE removes a loop when it shouldn't
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-21 13:17 --- Fixed. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23989
[Bug libstdc++/23990] compiling code with wchar_t .. gives linking error
--- Additional Comments From pcarlini at suse dot de 2005-09-21 13:27 --- I'm afraid this is a WONTFIX for gcc3.3.x, which is not maintained anymore. Can you try a more recent release, like the forthcoming gcc4.0.2? According to the audit trail of libstdc++/6702, the issue has been fixed for gcc3.4.0. -- What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23990
[Bug middle-end/23997] New: DCE removes a loop when it shouldn't
DCE (.t44.dce3) eliminates the third loop in the testcase below, although the print loop should be enough to keep it alive: == subroutine foo(a,b) real a,b type bzz real d(100) end type bzz type (bzz) e dimension a(100), b(100) read *,x,y a=log(x)--- loop 1 b=log(y)--- loop 2 e%d = a+b --- loop 3. eliminated print *,e%d end == See related thread here: http://gcc.gnu.org/ml/gcc/2005-09/msg00645.html -- Summary: DCE removes a loop when it shouldn't Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dorit at il dot ibm dot com CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: ppc64-yellowdog-linux GCC host triplet: ppc64-yellowdog-linux GCC target triplet: ppc64-yellowdog-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23997
[Bug java/21418] Order of source files matters when compiling
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-21 13:34 --- Subject: Bug 21418 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-21 13:34:29 Modified files: gcc/java : ChangeLog class.c Log message: PR java/21418 * class.c (inherits_from_p): Try to lay out super class if it is not already laid out. (maybe_layout_super_class): Handle the case where SUPER_CLASS is a NULL_TREE. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/ChangeLog.diff?cvsroot=gccr1=1.1665r2=1.1666 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/class.c.diff?cvsroot=gccr1=1.240r2=1.241 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21418
[Bug tree-optimization/23989] [4.1 Regression] DCE removes a loop when it shouldn't
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-09-21 13:41 --- This is wrong. As I stated on IRC, that only fixes the problem as a side effect. There is a real latent bug here. We should be getting the right result regardless of whether points-to says it points to e or points to anything. -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23989
[Bug tree-optimization/23989] [4.1 Regression] DCE removes a loop when it shouldn't
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dberlin at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-09-21 13:42:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23989
[Bug java/23891] [4.0 Regression] Problem folding static fields across packages
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-21 13:45 --- Subject: Bug 23891 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-21 13:45:22 Modified files: libjava: ChangeLog libjava/testsuite/libjava.jacks: jacks.xfail Log message: * testsuite/libjava.jacks/jacks.xfail: Updated for PR java/23891. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gccr1=1.3742r2=1.3743 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/testsuite/libjava.jacks/jacks.xfail.diff?cvsroot=gccr1=1.31r2=1.32 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23891
[Bug middle-end/23997] DCE removes a loop when it shouldn't
--- Additional Comments From dorit at il dot ibm dot com 2005-09-21 13:46 --- I don't know how this happened - I didn't mean to open this PR again. This should be closed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23997
Re: [Bug middle-end/23997] DCE removes a loop when it shouldn't
On Sep 21, 2005, at 9:46 AM, dorit at il dot ibm dot com wrote: --- Additional Comments From dorit at il dot ibm dot com 2005-09-21 13:46 --- I don't know how this happened - I didn't mean to open this PR again. This should be closed. Daniel opened because there is a latent bug still. I had meant not really to close this but I did. -- Pinski
[Bug middle-end/23997] DCE removes a loop when it shouldn't
--- Additional Comments From pinskia at physics dot uc dot edu 2005-09-21 13:51 --- Subject: Re: DCE removes a loop when it shouldn't On Sep 21, 2005, at 9:46 AM, dorit at il dot ibm dot com wrote: --- Additional Comments From dorit at il dot ibm dot com 2005-09-21 13:46 --- I don't know how this happened - I didn't mean to open this PR again. This should be closed. Daniel opened because there is a latent bug still. I had meant not really to close this but I did. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23997
[Bug java/21418] Order of source files matters when compiling
-- What|Removed |Added OtherBugsDependingO||18131 nThis|| Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21418
[Bug java/21418] Order of source files matters when compiling
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-21 14:05 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21418
[Bug java/18131] [meta-bug] inner class problems in java front-end
-- Bug 18131 depends on bug 21418, which changed state. Bug 21418 Summary: Order of source files matters when compiling http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21418 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18131
[Bug middle-end/23991] [4.1 Regression]: Gcc failed to build on ia64
--- Additional Comments From joern dot rennecke at st dot com 2005-09-21
14:07 ---
Subject: Re: [4.1 Regression]: Gcc failed to build on ia64
pinskia at gcc dot gnu dot org wrote:
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-21
11:28 ---
Confirmed, it is kinda of interesting that IA64 is one of the few targets
which does not have the length
attr (or have HAVE_ATTR_length defined).
The easy fix is the following:
int
get_attr_length (rtx insn)
{
#ifdef HAVE_ATTR_length
return get_attr_length_1 (insn, insn_default_length);
#else
return get_attr_length_1 (insn, 0);
#endif
}
We have to cover both get_attr_length and get_attr_min_length.
I think the attached patch is a cleaner solution.
2005-09-21 Jorn Rennecke [EMAIL PROTECTED]
* final.c (get_attr_length_1): In !HAVE_ATTR_length case, define as
macro. Don't attach ATTRIBUTE_UNUSED to arguments.
(get_attr_length, get_attr_min_length): Add ATTRIBUTE_UNUSED.
--- final.c 2005-09-20 22:41:08.0 +0100
+++ final.c-fixed 2005-09-21 14:58:05.0 +0100
@@ -385,11 +385,10 @@ init_insn_lengths (void)
/* Obtain the current length of an insn. If branch shortening has been done,
get its actual length. Otherwise, use FALLBACK_FN to calcualte the
length. */
+#ifdef HAVE_ATTR_length
static inline int
-get_attr_length_1 (rtx insn ATTRIBUTE_UNUSED,
- int (*fallback_fn) (rtx) ATTRIBUTE_UNUSED)
+get_attr_length_1 (rtx insn, int (*fallback_fn) (rtx))
{
-#ifdef HAVE_ATTR_length
rtx body;
int i;
int length = 0;
@@ -441,15 +440,15 @@ get_attr_length_1 (rtx insn ATTRIBUTE_UN
ADJUST_INSN_LENGTH (insn, length);
#endif
return length;
+}
#else /* not HAVE_ATTR_length */
- return 0;
+#define get_attr_length_1(insn,fallback_fn) 0
#endif /* not HAVE_ATTR_length */
-}
/* Obtain the current length of an insn. If branch shortening has been done,
get its actual length. Otherwise, get its maximum length. */
int
-get_attr_length (rtx insn)
+get_attr_length (rtx insn ATTRIBUTE_UNUSED)
{
return get_attr_length_1 (insn, insn_default_length);
}
@@ -457,7 +456,7 @@ get_attr_length (rtx insn)
/* Obtain the current length of an insn. If branch shortening has been done,
get its actual length. Otherwise, get its minimum length. */
int
-get_attr_min_length (rtx insn)
+get_attr_min_length (rtx insn ATTRIBUTE_UNUSED)
{
return get_attr_length_1 (insn, insn_min_length);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23991
[Bug ada/23995] GNAT BUG DETECTED
-- What|Removed |Added Severity|critical|normal Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23995
[Bug c++/23992] warning at the time of compiling C++ code using gcc 2.95.3
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-21 14:12 --- Can you attach the preprocessed source? But from the looks of it, this is a bug in the headers of HPUX. Also can you try a newer GCC since 2.95.3 is 4 years old. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23992
[Bug tree-optimization/23948] [4.1 Regression] internal compiler error: verify_stmts failed
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-21 14:18 --- We insert the reciprocal computation correctly after the call to double prrs = potentially_runnable_resource_share(); but as this call may trap and is the last instruction in the basic block, inserting there is obviously bogous. We'd need to insert a new BB or need a way to insert on the EXIT_EDGE. And make sure critical edges are split. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23948
[Bug middle-end/23997] DCE removes a loop when it shouldn't
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-21 14:23 --- Oh, this is a dup. I missed the bug number change. *** This bug has been marked as a duplicate of 23989 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23997
[Bug tree-optimization/23989] [4.1 Regression] DCE removes a loop when it shouldn't
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-21 14:23 --- *** Bug 23997 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23989
[Bug tree-optimization/23989] [4.1 Regression] DCE removes a loop when it shouldn't
-- What|Removed |Added Target Milestone|4.1.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23989
[Bug java/23620] [4.0/4.1 Regression] Segfault compiling inner interfaces
--- Additional Comments From tromey at gcc dot gnu dot org 2005-09-21 14:29 --- I had to make the methods in B and C public in order to compile. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23620
[Bug c++/23984] [4.0/4.1 Regression] second operand of PLUS_EXPR is NULL (in constructor)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-21 14:32 --- : Search converges between 2004-08-30-trunk (#529) and 2004-08-31-trunk (#530). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23984
[Bug tree-optimization/23948] [4.1 Regression] internal compiler error: verify_stmts failed
--- Additional Comments From paolo dot bonzini at lu dot unisi dot ch 2005-09-21 14:33 --- Subject: Re: [4.1 Regression] internal compiler error: verify_stmts failed rguenth at gcc dot gnu dot org wrote: --- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-21 14:18 --- We insert the reciprocal computation correctly after the call to double prrs = potentially_runnable_resource_share(); but as this call may trap and is the last instruction in the basic block, inserting there is obviously bogous. We'd need to insert a new BB or need a way to insert on the EXIT_EDGE. And make sure critical edges are split. No, I think we have to rethink the place where we insert the division. It needs to be closer to the divide (just before), not right after the definition. When we have flag_trapping_math, this is quite hard to do (there may be even multiple places to insert the divide!). I also did not understand why you had to fiddle with postdominators :-) to fix PR23309. I have a prototype patch but it will probably be a while before I can sit, look if it really works, and test it properly. Paolo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23948
[Bug tree-optimization/23948] [4.1 Regression] internal compiler error: verify_stmts failed
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-21
14:44 ---
Fixing like the following, but inserting onto the right edge(s) -
single_succ_edge actually doesn't work here.
diff -c -3 -p -r2.5 tree-ssa-math-opts.c
*** tree-ssa-math-opts.c9 Aug 2005 03:28:32 - 2.5
--- tree-ssa-math-opts.c21 Sep 2005 14:43:08 -
*** execute_cse_reciprocals_1 (block_stmt_it
*** 111,117
if (where == PR_BEFORE_BSI)
bsi_insert_before (bsi, new_stmt, BSI_SAME_STMT);
else if (where == PR_AFTER_BSI)
! bsi_insert_after (bsi, new_stmt, BSI_NEW_STMT);
else if (where == PR_ON_ENTRY_EDGE)
bsi_insert_on_edge (single_succ_edge (ENTRY_BLOCK_PTR), new_stmt);
else
--- 111,122
if (where == PR_BEFORE_BSI)
bsi_insert_before (bsi, new_stmt, BSI_SAME_STMT);
else if (where == PR_AFTER_BSI)
! {
! if (stmt_ends_bb_p (bsi_stmt (*bsi)))
! bsi_insert_on_edge (single_succ_edge (bsi-bb), new_stmt);
! else
! bsi_insert_after (bsi, new_stmt, BSI_NEW_STMT);
! }
else if (where == PR_ON_ENTRY_EDGE)
bsi_insert_on_edge (single_succ_edge (ENTRY_BLOCK_PTR), new_stmt);
else
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23948
[Bug tree-optimization/23588] CCP not fully propagating constants
--- Additional Comments From steven at gcc dot gnu dot org 2005-09-21 15:02 --- Let's fix this. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-08-27 03:31:22 |2005-09-21 15:02:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23588
[Bug c++/17609] [3.4 Regression] spurious error message after using keyword
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-21 15:08 --- Subject: Bug 17609 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2005-09-21 15:08:00 Modified files: gcc/cp : ChangeLog lex.c name-lookup.c name-lookup.h gcc/testsuite : ChangeLog gcc/testsuite/g++.dg/lookup: ambig4.C koenig1.C used-before-declaration.C gcc/testsuite/g++.dg/ext: stmtexpr4.C gcc/testsuite/g++.dg/other: do1.C gcc/testsuite/g++.dg/overload: koenig1.C gcc/testsuite/g++.dg/parse: crash13.C error21.C Added files: gcc/testsuite/g++.dg/lookup: error1.C Log message: PR c++/17609 Backport: 2004-03-08 Mark Mitchell [EMAIL PROTECTED] * lex.c (unqualified_name_lookup_error): Create a dummy VAR_DECL in the innermost scope, rather than at namespace scope. * name-lookup.c (push_local_binding): Give it external linkage. * name-lookup.h (push_local_binding): Declare it. * g++.dg/lookup/error1.C: New test. * g++.dg/lookup/ambig4.C: Tweak error messages. * g++.dg/ext/stmtexpr4.C: Likewise. * g++.dg/parse/error21.C: Tweak testcase. Backport: 2004-03-02 Mark Mitchell [EMAIL PROTECTED] * g++.dg/lookup/koenig1.C: Tweak error messages. * g++.dg/lookup/used-before-declaration.C: Likewise. * g++.dg/other/do1.C: Likewise. * g++.dg/overload/koenig1.C: Likewise. * g++.dg/parse/crash13.C: Likewise. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.3892.2.242r2=1.3892.2.243 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/lex.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.323.2.4r2=1.323.2.5 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/name-lookup.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.34.2.24r2=1.34.2.25 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/name-lookup.h.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.15.2.3r2=1.15.2.4 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.3389.2.436r2=1.3389.2.437 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/lookup/error1.C.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=NONEr2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/lookup/ambig4.C.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.1.6.1r2=1.1.6.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/lookup/koenig1.C.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.1r2=1.1.22.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/lookup/used-before-declaration.C.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.1r2=1.1.12.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/stmtexpr4.C.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.1.4.1r2=1.1.4.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/other/do1.C.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.3r2=1.3.20.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/overload/koenig1.C.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.1r2=1.1.24.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/parse/crash13.C.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.1.14.1r2=1.1.14.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/parse/error21.C.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.1.2.1r2=1.1.2.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17609
[Bug c++/17609] [3.4 Regression] spurious error message after using keyword
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-09-21 15:12 --- This is now fixed in GCC 3.4.5. The new testcase g++.dg/lookup/error1.C will be added to mainline and the 4.0 branch. In the meantime I'll keep the PR open. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17609
[Bug middle-end/23999] New: DECL_SIZE set to NULL at times
Inserting the following code into get_inner_reference before if (size_tree != 0), causes bootstrap failures where DECL_SIZE is NULL but shouldn't be gcc_assert (size_tree != 0 || (TREE_CODE (exp) != COMPONENT_REF TREE_CODE (exp) != BIT_FIELD_REF)); -- Summary: DECL_SIZE set to NULL at times Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dberlin at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23999
[Bug c++/17609] [3.4 Regression] spurious error message after using keyword
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-21 15:21 --- Subject: Bug 17609 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-21 15:21:00 Modified files: gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/lookup: error1.C Log message: PR c++/17609 * g++.dg/lookup/error1.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.6090r2=1.6091 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/lookup/error1.C.diff?cvsroot=gccr1=1.1r2=1.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17609
[Bug c++/17609] [3.4 Regression] spurious error message after using keyword
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-09-21 15:23 --- Testcase now also in mainline. Waiting for 4.0 branch to unfreeze. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17609
[Bug c++/23965] [3.4/4.0/4.1 regression] Bogus error message: no matching function for call to 'foo(type error)'
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-21 15:34 --- Subject: Bug 23965 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-21 15:34:42 Modified files: gcc/cp : ChangeLog call.c gcc/testsuite : ChangeLog gcc/testsuite/g++.dg/template: error1.C Log message: PR c++/23965 * call.c (resolve_args): Return error_mark_node on arguments whose TREE_TYPE is error_mark_node. * g++.dg/template/error1.C: Reject no matching function message. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gccr1=1.4898r2=1.4899 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/call.c.diff?cvsroot=gccr1=1.552r2=1.553 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.6091r2=1.6092 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/error1.C.diff?cvsroot=gccr1=1.1r2=1.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23965
[Bug c++/23965] [3.4/4.0/4.1 regression] Bogus error message: no matching function for call to 'foo(type error)'
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-21 15:40 --- Subject: Bug 23965 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2005-09-21 15:39:53 Modified files: gcc/cp : ChangeLog call.c gcc/testsuite : ChangeLog gcc/testsuite/g++.dg/template: error1.C Log message: PR c++/23965 * call.c (resolve_args): Return error_mark_node on arguments whose TREE_TYPE is error_mark_node. * g++.dg/template/error1.C: Reject no matching function message. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.3892.2.243r2=1.3892.2.244 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/call.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.452.2.28r2=1.452.2.29 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.3389.2.437r2=1.3389.2.438 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/error1.C.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.1r2=1.1.22.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23965
[Bug c++/23965] [4.0 regression] Bogus error message: no matching function for call to 'foo(type error)'
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-09-21 15:41 --- Fixed on mainline and the 3.4 branch. Waiting for 4.0 branch to unfreeze. -- What|Removed |Added Summary|[3.4/4.0/4.1 regression]|[4.0 regression] Bogus error |Bogus error message: no |message: no matching |matching function for call |function for call to |to 'foo(type error)' |'foo(type error)' http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23965
[Bug c/24000] New: wrong constants allocation for altivec data type on PPC little-endian
vector constants are allocated in reversed order when building the test program
for a PowerPC little-endian executable.
Test case code, altivec_test.c
--
#include stdio.h
#if __GNUC__ = 3
#include altivec.h
#endif
int main(void)
{
#if __GNUC__ = 3
vector signed char vsc = (vector signed char) {'f', 'e', 'd', 'c', 'b', 'a',
'9', '8', '7', '6', '5', '4', '3', '2', '1', '0'} ;
vector unsigned short vus = (vector unsigned short) {1, 2, 3, 4, 5, 6, 7,
8} ;
vector float vf = (vector float){1.0, 2.0, 3.0, 4.0};
#else
vector signed char vsc = (vector signed char) ('f', 'e', 'd', 'c', 'b', 'a',
'9', '8', '7', '6', '5', '4', '3', '2', '1', '0') ;
vector unsigned short vus = (vector unsigned short) (1, 2, 3, 4, 5, 6, 7,
8) ;
vector float vf = (vector float) (1.0, 2.0, 3.0, 4.0) ;
#endif
printf(vsc=(%vc)\n, (vector signed char)vsc) ;
printf(vus=(%vhu)\n, (vector unsigned short)vus) ;
printf(vf=(%vf)\n, vf) ;
return 0 ;
---
The command line used to compile the test:
powerpc-eabi-gcc -maltivec -mlittle -c -o altivec_test.oppc_le altivec_test.c
The objdump -s altivec_test.oppc_le generated information is:
altivec_test.oppc_le: file format elf32-little
Contents of section .text:
60ff2194 a602087c 9c00e193 a4000190 `.!|
0010 780b3f7c 0148 203d 30002939 x.?|...H.. =0.)9
0020 ce48007c 4038 ce011f7c 4038 .H.|@..8...|@..8
0030 ce001f7c 3038 ce011f7c 203d ...|0..8...|.. =
0040 40002939 ce48007c 6038 ce011f7c @.)9.H.|`..8...|
0050 6038 ce001f7c 5038 ce011f7c `..8...|P..8...|
0060 203d 50002939 ce48007c 8038 .. =P.)9.H.|...8
0070 ce011f7c 8038 ce001f7c 7038 ...|...8...|p..8
0080 ce011f7c 08006039 3038 ce001f7c ...|..`90..8...|
0090 08002139 ce59097c 203d 6938 ..!9.Y.|.. =..i8
00a0 8231c64c 0148 08006039 5038 .1.L...H..`9P..8
00b0 ce001f7c 08002139 ce59097c 203d ...|..!9.Y.|.. =
00c0 0c006938 8231c64c 0148 08006039 ..i8.1.L...H..`9
00d0 7038 ce001f7c 08002139 ce59097c p..8...|..!9.Y.|
00e0 203d 18006938 8231c64c 0148 .. =..i8.1.L...H
00f0 0038 7803037c 6181 04000b80 ...8x..|..a.
0100 a603087c fcffeb83 785b617d 2000804e ...|x[a} ..N
Contents of section .data:
Contents of section .rodata:
7673633d 28257663 290a 7675733d vsc=(%vc)...vus=
0010 28257668 75290a00 76663d28 25766629 (%vhu)..vf=(%vf)
0020 0a00
0030 66656463 62613938 37363534 33323130 fedcba9876543210
0040 01000200 03000400 05000600 07000800
0050 803f 0040 4040 8040 [EMAIL PROTECTED]@@...@
Contents of section .comment:
00474343 3a202847 4e552920 332e342e .GCC: (GNU) 3.4.
0010 3400 4.
Note, in the .rodata section, the compiler generates reversed order codes for
0030 0040 and 0050. Actually the codes are the same as big-endian.
It should generate code like this:
0030 30313233 34353637 38396162 63646566 0123456789abcdef
0040 08000700 06000500 04000300 02000100
0050 8040 4040 0040 803f [EMAIL PROTECTED]@@[EMAIL PROTECTED]
I can also find the compiler generates reversed order codes from the assembly
codes:
.LC0:
.byte 102
.byte 101
.byte 100
.byte 99
.byte 98
.byte 97
.byte 57
.byte 56
.byte 55
.byte 54
.byte 53
.byte 52
.byte 51
.byte 50
.byte 49
.byte 48
.align 4
.LC1:
.short 1
.short 2
.short 3
.short 4
.short 5
.short 6
.short 7
.short 8
.align 4
.LC2:
.long 1065353216
.long 1073741824
.long 1077936128
.long 1082130432
.section.text
.align 2
.globl main
.type main, @function
--
Summary: wrong constants allocation for altivec data type on PPC
little-endian
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: xhliu at mc dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-cygwin
GCC host triplet: i686-pc-cygwin
GCC target triplet: powerpc-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24000
[Bug tree-optimization/24001] New: Simple redundancy not eliminated
For this code:
int f(int *ptr, int t) {
if (t)
return *ptr;
else
return *ptr;
}
the jump is not eliminated:
f: beq $17,$L2
ldl $0,0($16)
ret
$L2:ldl $0,0($16)
ret
This used to work with 2.95 (not sure whether that still counts as
regression...), but not with 3.3, 3.4, 4.0, or 4.1.0 20050915.
--
Summary: Simple redundancy not eliminated
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: falk at debian dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: alpha-linux-gnu
GCC host triplet: alpha-linux-gnu
GCC target triplet: alpha-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24001
[Bug libstdc++/23956] Class __mt_alloc overexerts __policy_type::_S_get_pool
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-09-21 16:09 --- I suspect this is an oversight from early patches of PR 17780. I'll look at this. -benjamin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23956
[Bug libstdc++/23956] Class __mt_alloc overexerts __policy_type::_S_get_pool
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bkoz at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23956
[Bug libstdc++/23990] compiling code with wchar_t .. gives linking error
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-09-21 16:13 --- Paolo is right: wchar_t specializations are only supported on solaris starting with gcc-3.4.0. I would suggest using either gcc-3.4.4 gcc-4.0.2 -benjamin -- What|Removed |Added GCC build triplet||sparc-sun-solaris2.9 GCC host triplet||sparc-sun-solaris2.9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23990
[Bug target/24000] wrong constants allocation for altivec data type on PPC little-endian
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-21 16:13 --- Note most poeple don't use little endian PPC. -- What|Removed |Added Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24000
[Bug libstdc++/23990] compiling code with wchar_t .. gives linking error
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-09-21 16:14 --- *** This bug has been marked as a duplicate of 6702 *** -- What|Removed |Added Status|WAITING |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23990
[Bug libstdc++/6702] requirements for wchar_t support are too restrictive for Solaris
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-09-21 16:14 --- *** Bug 23990 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||a_manish at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6702
[Bug target/24000] wrong constants allocation for altivec data type on PPC little-endian
--- Additional Comments From xhliu at mc dot com 2005-09-21 16:22 --- (In reply to comment #1) Note most poeple don't use little endian PPC. Yes, it is true. But Mercury supports little-endian PPC, and this is a bug in GCC 3.x and 4.x. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24000
[Bug tree-optimization/24001] Simple redundancy not eliminated
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-21 16:32 --- Try with -Os and you will see it is eliminated. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24001
[Bug middle-end/23971] [4.0/4.1 Regression] synth_mult running amok
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-21 16:48 --- Subject: Bug 23971 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-21 16:47:47 Modified files: gcc: ChangeLog Log message: PR middle-end/23971 * expmed.c (alg_code): Add alg_impossible. (alg_hash_entry): Add cost. (synth_mult): Record alg_impossible in the hash table if multiplication by a given integer is impossble within the limit. Speed up using alg_impossible. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.9997r2=2.9998 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23971
[Bug middle-end/23971] [4.0/4.1 Regression] synth_mult running amok
--- Additional Comments From kazu at gcc dot gnu dot org 2005-09-21 16:50 --- Just checked in a patch. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23971
[Bug tree-optimization/23942] [4.1 Regression] loop problem / testcase takes very long time to compile
--- Additional Comments From sebastian dot pop at cri dot ensmp dot fr
2005-09-21 17:02 ---
Subject: Re: [4.1 Regression] loop problem / testcase takes very long time to
compile
Random break stops things typically somewhere inside 140 nested calls in scev
(follow_ssa_edge and friends). I seem to recall there is some backtracking
involved, I will check.
A patch around these lines should fix the problem: it limits the
number of arcs that we walk before giving up. For the moment I'm
returning didn't found a path from P to P, when we give up. We have
to handle a don't know symbol for this case.
I'll test a patch similar to the following tomorow.
Index: Makefile.in
===
RCS file: /cvs/gcc/gcc/gcc/Makefile.in,v
retrieving revision 1.1541
diff -d -u -p -r1.1541 Makefile.in
--- Makefile.in 14 Sep 2005 09:26:41 - 1.1541
+++ Makefile.in 21 Sep 2005 16:51:48 -
@@ -767,7 +767,7 @@ TREE_SSA_LIVE_H = tree-ssa-live.h $(PART
PRETTY_PRINT_H = pretty-print.h input.h $(OBSTACK_H)
DIAGNOSTIC_H = diagnostic.h diagnostic.def $(PRETTY_PRINT_H)
C_PRETTY_PRINT_H = c-pretty-print.h $(PRETTY_PRINT_H) $(C_COMMON_H) $(TREE_H)
-SCEV_H = tree-scalar-evolution.h $(GGC_H) tree-chrec.h
+SCEV_H = tree-scalar-evolution.h $(GGC_H) tree-chrec.h $(PARAMS_H)
LAMBDA_H = lambda.h tree.h vec.h $(GGC_H)
TREE_DATA_REF_H = tree-data-ref.h $(LAMBDA_H)
VARRAY_H = varray.h $(MACHMODE_H) $(SYSTEM_H) coretypes.h $(TM_H)
Index: tree-scalar-evolution.c
===
RCS file: /cvs/gcc/gcc/gcc/tree-scalar-evolution.c,v
retrieving revision 2.38
diff -d -u -p -r2.38 tree-scalar-evolution.c
--- tree-scalar-evolution.c 20 Sep 2005 07:09:20 - 2.38
+++ tree-scalar-evolution.c 21 Sep 2005 16:51:48 -
@@ -251,6 +251,7 @@ Software Foundation, 51 Franklin Street,
#include tree-scalar-evolution.h
#include tree-pass.h
#include flags.h
+#include params.h
static tree analyze_scalar_evolution_1 (struct loop *, tree, tree);
static tree resolve_mixers (struct loop *, tree);
@@ -1022,17 +1023,14 @@ select_loops_exit_conditions (struct loo
/* Depth first search algorithm. */
-static bool follow_ssa_edge (struct loop *loop, tree, tree, tree *);
+static bool follow_ssa_edge (struct loop *loop, tree, tree, tree *, int);
/* Follow the ssa edge into the right hand side RHS of an assignment.
Return true if the strongly connected component has been found. */
static bool
-follow_ssa_edge_in_rhs (struct loop *loop,
- tree at_stmt,
- tree rhs,
- tree halting_phi,
- tree *evolution_of_loop)
+follow_ssa_edge_in_rhs (struct loop *loop, tree at_stmt, tree rhs,
+ tree halting_phi, tree *evolution_of_loop, int limit)
{
bool res = false;
tree rhs0, rhs1;
@@ -1050,7 +1048,7 @@ follow_ssa_edge_in_rhs (struct loop *loo
case NOP_EXPR:
/* This assignment is under the form a_1 = (cast) rhs. */
res = follow_ssa_edge_in_rhs (loop, at_stmt, TREE_OPERAND (rhs, 0),
- halting_phi, evolution_of_loop);
+ halting_phi, evolution_of_loop, limit);
*evolution_of_loop = chrec_convert (TREE_TYPE (rhs),
*evolution_of_loop, at_stmt);
break;
@@ -1063,7 +1061,7 @@ follow_ssa_edge_in_rhs (struct loop *loo
case SSA_NAME:
/* This assignment is under the form: a_1 = b_2. */
res = follow_ssa_edge
- (loop, SSA_NAME_DEF_STMT (rhs), halting_phi, evolution_of_loop);
+ (loop, SSA_NAME_DEF_STMT (rhs), halting_phi, evolution_of_loop, limit);
break;
case PLUS_EXPR:
@@ -1081,7 +1079,7 @@ follow_ssa_edge_in_rhs (struct loop *loo
a = b + c. */
res = follow_ssa_edge
(loop, SSA_NAME_DEF_STMT (rhs0), halting_phi,
-evolution_of_loop);
+evolution_of_loop, limit);
if (res)
*evolution_of_loop = add_to_evolution
@@ -1093,7 +1091,7 @@ follow_ssa_edge_in_rhs (struct loop *loo
{
res = follow_ssa_edge
(loop, SSA_NAME_DEF_STMT (rhs1), halting_phi,
-evolution_of_loop);
+evolution_of_loop, limit);
if (res)
*evolution_of_loop = add_to_evolution
@@ -1109,7 +1107,7 @@ follow_ssa_edge_in_rhs (struct loop *loo
a = b + */
res = follow_ssa_edge
(loop, SSA_NAME_DEF_STMT (rhs0), halting_phi,
-evolution_of_loop);
+evolution_of_loop, limit);
if (res)
*evolution_of_loop = add_to_evolution
(loop-num, chrec_convert (type_rhs,
[Bug fortran/19929] Deallocation of an allocated derived type component causes failure
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-21 17:05 --- Subject: Bug 19929 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-21 17:05:28 Modified files: gcc/fortran: trans-stmt.c ChangeLog gcc/testsuite : ChangeLog Added files: gcc/testsuite/gfortran.dg: der_ptr_component_1.f90 Log message: 2005-09-21 Erik Edelmann [EMAIL PROTECTED] PR fortran/19929 * trans-stmt.c (gfc_trans_deallocate): Check if the object to be deallocated is an array by looking at expr-rank instead of expr-symtree-n.sym-attr.dimension. 2005-09-21 Erik Edelmann [EMAIL PROTECTED] PR fortran/19929 * gfortran.dg/der_ptr_component_1.f90: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-stmt.c.diff?cvsroot=gccr1=1.41r2=1.42 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gccr1=1.563r2=1.564 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/der_ptr_component_1.f90.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.6092r2=1.6093 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19929
[Bug c++/23984] [4.0/4.1 Regression] second operand of PLUS_EXPR is NULL (in constructor)
--- Additional Comments From janis187 at us dot ibm dot com 2005-09-21 17:07 --- Reghunt found this patch from nathan: http://gcc.gnu.org/ml/gcc-cvs/2004-08/msg01511.html -- What|Removed |Added CC||nathan at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23984
[Bug target/19653] x87 reg allocated for constants for -mfpmath=sse
--- Additional Comments From dalej at gcc dot gnu dot org 2005-09-21 17:23 --- I agree with Paolo. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19653
[Bug ada/24003] New: ACATS FAIL 17 regressions on x86-linux, fixed and decimal arithmetic broken
They all fail at runtime on x86-linux only (work on x86_64-linux), it happened between LAST_UPDATED: Fri Sep 16 18:47:13 UTC 2005 LAST_UPDATED: Tue Sep 20 19:42:32 UTC 2005 It looks like it's all fixed point or decimal artihmetic that gets wrong code generated. One example ,.,. C45532J ACATS 2.5 05-09-21 10:53:40 C45532J FIXED POINT OPERATOR /. * C45532J RESULT OF / OUTSIDE RESULT MODEL INTERVAL WHEN USING NO MODEL NUMBERS. C45532J FAILED . Complete list: c45532j c45532l c45532m c45532n c45532o c45532p ce3806g ce3806h ce3810b cxaa008 cxf2001 cxf2002 cxf2003 cxf2004 cxf2005 cxf2a02 cxg2022 -- Summary: ACATS FAIL 17 regressions on x86-linux, fixed and decimal arithmetic broken Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P2 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: laurent at guerby dot net CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24003
[Bug target/23828] local calling convention not used when using --combine
--- Additional Comments From dann at godzilla dot ics dot uci dot edu 2005-09-21 17:43 --- (In reply to comment #8) (In reply to comment #4) Instead of the above check, change it to: if (local_regparm == 3 DECL_STRUCT_FUNCTION (fn)-static_chain_decl) local_regparm = 2; DECL_STRUCT_FUNCTION does not work, it ICEs when running the testsuite... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23828
[Bug target/22148] gcc.dg/vect/vect-reduc-1* fail
--- Additional Comments From sje at cup dot hp dot com 2005-09-21 18:09 --- (In reply to comment #1) does this ia64 reduction testcase failure still occur? I still see these failures in my nightly runs. -- What|Removed |Added CC||sje at cup dot hp dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22148
[Bug ada/23995] GNAT BUG DETECTED
--- Additional Comments From laurent at guerby dot net 2005-09-21 18:24 --- no ICE on x86 and x86_64, must be sparc specific. -- What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23995
[Bug target/22585] [4.0/4.1 regression] ICE with long doubles in expand_simple_unop
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-21 18:39 --- Subject: Bug 22585 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-21 18:39:10 Modified files: gcc: ChangeLog gcc/config/i386: i386.c Log message: PR target/22585 * config/i386/i386.c (ix86_prepare_fp_compare_args): Do not force integer op1 into register for XFmode compares. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.9998r2=2. http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386.c.diff?cvsroot=gccr1=1.859r2=1.860 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22585
[Bug target/22148] gcc.dg/vect/vect-reduc-1* fail
--- Additional Comments From sje at cup dot hp dot com 2005-09-21 18:43 --- The compile failures appear to be gone but I get an execution failure on IA64 HP-UX. There is a second PR (PR 23188) that looks like a duplicate of this and I *think* this might be the same bug as PR 23240, a litle-endian/big-endian bug in the IA64 vectorizor code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22148
[Bug libstdc++/13583] [3.4/4.0/4.1 Regression] __use_cache not threadsafe
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-09-21 18:54 --- Hey Ian. I haven't looked at this in a bit. The problem with the posted patch is that we should not be exporting the mutex objects. See the rest of the libstdc++ code for suggested usage. -benjamin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13583
[Bug target/22585] [4.0 regression] ICE with long doubles in expand_simple_unop
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-21 19:20 --- Fixed on the mainline. -- What|Removed |Added Known to fail|4.0.0 4.0.1 4.1.0 |4.0.0 4.0.1 Known to work|3.4.4 |3.4.4 4.1.0 Summary|[4.0/4.1 regression] ICE|[4.0 regression] ICE with |with long doubles in|long doubles in |expand_simple_unop |expand_simple_unop http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22585
[Bug middle-end/23991] [4.1 Regression]: Gcc failed to build on ia64
--- Additional Comments From ian at airs dot com 2005-09-21 19:21 --- Subject: Re: [4.1 Regression]: Gcc failed to build on ia64 Joern RENNECKE [EMAIL PROTECTED] writes: 2005-09-21 Jorn Rennecke [EMAIL PROTECTED] * final.c (get_attr_length_1): In !HAVE_ATTR_length case, define as macro. Don't attach ATTRIBUTE_UNUSED to arguments. (get_attr_length, get_attr_min_length): Add ATTRIBUTE_UNUSED. Ick, don't do that. Suppose you just #define insn_default_length and insn_min_length as macros ifndef HAVE_ATTR_length. Ian -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23991
[Bug middle-end/23991] [4.1 Regression]: Gcc failed to build on ia64
--- Additional Comments From pinskia at physics dot uc dot edu 2005-09-21 19:24 --- Subject: Re: [4.1 Regression]: Gcc failed to build on ia64 On Sep 21, 2005, at 3:20 PM, Ian Lance Taylor wrote: Joern RENNECKE [EMAIL PROTECTED] writes: 2005-09-21 Jorn Rennecke [EMAIL PROTECTED] * final.c (get_attr_length_1): In !HAVE_ATTR_length case, define as macro. Don't attach ATTRIBUTE_UNUSED to arguments. (get_attr_length, get_attr_min_length): Add ATTRIBUTE_UNUSED. Ick, don't do that. Suppose you just #define insn_default_length and insn_min_length as macros ifndef HAVE_ATTR_length. Of course both insn_default_length and insn_min_length are used as functions in this situation. Thanks, Andrew Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23991
[Bug middle-end/23971] [4.0/4.1 Regression] synth_mult running amok
-- What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23971
[Bug middle-end/23991] [4.1 Regression]: Gcc failed to build on ia64
--- Additional Comments From ian at airs dot com 2005-09-21 19:30 --- Subject: Re: [4.1 Regression]: Gcc failed to build on ia64 Andrew Pinski [EMAIL PROTECTED] writes: On Sep 21, 2005, at 3:20 PM, Ian Lance Taylor wrote: Joern RENNECKE [EMAIL PROTECTED] writes: 2005-09-21 Jorn Rennecke [EMAIL PROTECTED] * final.c (get_attr_length_1): In !HAVE_ATTR_length case, define as macro. Don't attach ATTRIBUTE_UNUSED to arguments. (get_attr_length, get_attr_min_length): Add ATTRIBUTE_UNUSED. Ick, don't do that. Suppose you just #define insn_default_length and insn_min_length as macros ifndef HAVE_ATTR_length. Of course both insn_default_length and insn_min_length are used as functions in this situation. Hmmm, right. Bother. Still doable, but uglier. Ian -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23991
[Bug ada/24003] ACATS FAIL 17 regressions on x86-linux, fixed and decimal arithmetic broken
--- Additional Comments From laurent at guerby dot net 2005-09-21 20:11 --- Here is a reduced Ada testcase. -gnatdg show use of 64 bits, but in original test case it was not the case, so it might be a slightly different bug. $ cat p.adb procedure P is type T is delta 1.0 / (2 ** 32) range -1.0 .. 1.0; A : T := 0.25; B : T := 0.75; C : T := A / B; begin if C = 0.0 then raise Program_Error; end if; end P; $ gnatmake p gcc -c p.adb gnatbind -x p.ali gnatlink p.ali $ ./p raised PROGRAM_ERROR : p.adb:8 explicit raise -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24003
[Bug ada/24003] ACATS FAIL 17 regressions on x86-linux, fixed and decimal arithmetic broken
--- Additional Comments From laurent at guerby dot net 2005-09-21 20:16 --- Created an attachment (id=9787) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9787action=view) -fdump-tree-all Andrew request. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24003
[Bug ada/24003] ACATS FAIL 17 regressions on x86-linux, fixed and decimal arithmetic broken
--- Additional Comments From laurent at guerby dot net 2005-09-21 20:26 --- but in original test case it was not the case: I missed but there's also a call to system.arith_64.scaled_divide in the original test case, so this is the likely miscompiled function. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24003
[Bug ada/24003] [4.1 Regression] ACATS FAIL 17 regressions on x86-linux, fixed and decimal arithmetic broken
-- What|Removed |Added CC||kenner at vlsi1 dot ultra ||dot nyu dot edu Summary|ACATS FAIL 17 regressions on|[4.1 Regression] ACATS FAIL |x86-linux, fixed and decimal|17 regressions on x86-linux, |arithmetic broken |fixed and decimal arithmetic ||broken http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24003
[Bug fortran/23843] Access restrictions on derived types in modules too strict.
--- Additional Comments From erik dot edelmann at iki dot fi 2005-09-21 20:36 --- Patch posted to the mailing list here: http://gcc.gnu.org/ml/gcc-patches/2005-09/msg01359.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23843
[Bug c/24004] New: gcc 4.0.1 gives bogus 'may be unused warnings' at -O3
$ cat /etc/fedora-release
Fedora Core release 4 (Stentz)
$ uname -a
Linux host 2.6.13.1 #4 Sat Sep 17 10:57:37 PDT 2005 x86_64 x86_64 x86_64
GNU/Linux
$ gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,java,f95,ada --enable-java-awt=gtk
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre
--host=x86_64-redhat-linux
Thread model: posix
gcc version 4.0.1 20050727 (Red Hat 4.0.1-5)
testcase.c:
===
#include math.h
typedef float vec_t;
typedef vec_t vec3_t[3];
void VectorSubtract( const vec3_t veca, const vec3_t vecb, vec3_t out ) {
out[0] = veca[0] - vecb[0];
out[1] = veca[1] - vecb[1];
out[2] = veca[2] - vecb[2];
}
void VectorCopy( const vec3_t in, vec3_t out ) {
out[0] = in[0];
out[1] = in[1];
out[2] = in[2];
}
vec_t VectorLength( const vec3_t v ) {
return sqrt (v[0]*v[0] + v[1]*v[1] + v[2]*v[2]);
}
float BG_SplineLength( void ) {
float i;
float granularity = 0.01f;
float dist = 0;
vec3_t vec[2];
vec3_t lastPoint;
vec3_t result;
for(i = 0; i = 1.f; i += granularity ) {
VectorSubtract( vec[1], vec[0], result );
if( i != 0 ) {
VectorSubtract( result, lastPoint, vec[0] );
dist += VectorLength( vec[0] );
}
VectorCopy( result, lastPoint );
}
return dist;
}
int main( void ) {
BG_SplineLength();
return 0;
}
$ gcc -O2 -Wall -o testcase testcase.c
$ gcc -O3 -Wall -o testcase testcase.c
testcase.c: In function BG_SplineLength:
testcase.c:26: warning: lastPoint[0] may be used uninitialized in this
function
testcase.c:26: warning: lastPoint[1] may be used uninitialized in this
function
testcase.c:26: warning: lastPoint[2] may be used uninitialized in this
function
testcase.c: In function main:
testcase.c:26: warning: lastPoint[0] may be used uninitialized in this
function
testcase.c:26: warning: lastPoint[1] may be used uninitialized in this
function
testcase.c:26: warning: lastPoint[2] may be used uninitialized in this
function
gcc3.2 and 3.3 don't produce these bogus warnings.
--
Summary: gcc 4.0.1 gives bogus 'may be unused warnings' at -O3
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: SLTxLQEc4vuR5kMzK at anime dot net
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24004
[Bug middle-end/24004] gcc 4.0.1 gives bogus 'may be unused warnings' at -O3
-- What|Removed |Added Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24004
[Bug c++/23958] collect2: ld terminated with signal 10 [Bus error] linking libstdc++.sl.6
--- Additional Comments From sje at cup dot hp dot com 2005-09-21 22:38 --- The Ada bug number in the previous comment should be PR 23957, not 2397. -- What|Removed |Added CC||sje at cup dot hp dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23958
[Bug fortran/24005] Ambiguous INTERFACE leads to seg fault
--- Additional Comments From kargl at gcc dot gnu dot org 2005-09-21 22:41 --- Created an attachment (id=9788) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9788action=view) ambiguous INTERFACE code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24005
[Bug fortran/24005] New: Ambiguous INTERFACE leads to seg fault
The mpfun90 package will cause gfortran to seg fault during compilation. The problem appears to be due to an ambiguous interface. I'll attach a cutdowen version of the code. -- Summary: Ambiguous INTERFACE leads to seg fault Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kargl at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: freebsd-*-amd64 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24005
