[Bug java/25239] gij failed to execute JREProperties.java
--- Comment #9 from chat95 at mac dot com 2005-12-23 08:07 --- Hello, Pawel Sikora! I tried with (2005/12/23) svn co svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch revision 109008 and this problem has been solved!! thank you very much!! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25239
[Bug java/25239] gij failed to execute JREProperties.java
--- Comment #10 from chat95 at mac dot com 2005-12-23 08:07 --- . -- chat95 at mac dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25239
[Bug libgcj/24154] Make requires too much memory building libjava
--- Comment #4 from chat95 at mac dot com 2005-12-23 08:10 --- hi all, i tried with gmake (GNU Make 3.81beta4) as Arno told, build and installs file for me. uname -a FreeBSD debussy.private.org 6.0-RELEASE FreeBSD 6.0-RELEASE #0: Mon Nov 21 09:36:37 JST 2005 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/MAHO i386 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24154
[Bug libgcj/24154] Make requires too much memory building libjava
--- Comment #5 from chat95 at mac dot com 2005-12-23 08:13 --- sorry file for me -> fine for me -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24154
[Bug bootstrap/25543] New: Bootstrap fails with *** No rule to make target `../build-x86_64-unknown-linux-gnu/libiberty/libiberty.a', needed by `build/genmodes'.
$ uname -a Linux hertz 2.6.7-gentoo-r14 #8 SMP Mon Sep 6 16:08:44 BST 2004 x86_64 AMD Opteron(tm) Processor 844 AuthenticAMD GNU/Linux gcc-4.2.0 svn revision 108950. $ cd build_hertz $ rm -rf * $ ../trunk/gcc/configure --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=x86_64-unknown-linux-gnu --prefix=/usr/local/gcc-svn --enable-languages=c,c++,fortran checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking target system type... x86_64-unknown-linux-gnu checking LIBRARY_PATH variable... ok checking GCC_EXEC_PREFIX variable... ok checking whether to place generated files in the source directory... no checking whether a default linker was specified... no checking whether a default assembler was specified... no checking for x86_64-unknown-linux-gnu-gcc... x86_64-unknown-linux-gnu-gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether x86_64-unknown-linux-gnu-gcc accepts -g... yes checking for x86_64-unknown-linux-gnu-gcc option to accept ANSI C... none needed checking whether x86_64-unknown-linux-gnu-gcc and cc understand -c and -o together... yes checking how to run the C preprocessor... x86_64-unknown-linux-gnu-gcc -E checking for inline... inline checking for egrep... grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for void *... yes checking size of void *... 8 checking for short... yes checking size of short... 2 checking for int... yes checking size of int... 4 checking for long... yes checking size of long... 8 checking for long long... yes checking for long long... (cached) yes checking size of long long... 8 checking for __int64... no checking whether x86_64-unknown-linux-gnu-gcc accepts -Wno-long-long... yes checking whether x86_64-unknown-linux-gnu-gcc accepts -Wno-variadic-macros... yes checking whether x86_64-unknown-linux-gnu-gcc accepts -Wold-style-definition... yes checking whether x86_64-unknown-linux-gnu-gcc accepts -Wmissing-format-attribute... yes checking valgrind.h usability... no checking valgrind.h presence... no checking for valgrind.h... no checking whether make sets $(MAKE)... yes checking for gawk... gawk checking whether ln -s works... yes checking whether ln works... yes checking for x86_64-unknown-linux-gnu-ranlib... no checking for ranlib... ranlib checking for a BSD compatible install... /usr/bin/install -c checking for cmp's capabilities... gnucompare checking for mktemp... yes checking for makeinfo... makeinfo checking for modern makeinfo... yes checking for recent Pod::Man... yes checking for flex... flex checking for bison... bison checking for nm... nm checking for ar... ar checking for GNU C library... yes checking for ANSI C header files... (cached) yes checking whether time.h and sys/time.h may both be included... yes checking whether string.h and strings.h may both be included... yes checking for sys/wait.h that is POSIX.1 compatible... yes checking for limits.h... yes checking for stddef.h... yes checking for string.h... (cached) yes checking for strings.h... (cached) yes checking for stdlib.h... (cached) yes checking for time.h... yes checking for iconv.h... yes checking for fcntl.h... yes checking for unistd.h... (cached) yes checking for sys/file.h... yes checking for sys/time.h... yes checking for sys/mman.h... yes checking for sys/resource.h... yes checking for sys/param.h... yes checking for sys/times.h... yes checking for sys/stat.h... (cached) yes checking for direct.h... no checking for malloc.h... yes checking for langinfo.h... yes checking for ldfcn.h... no checking for locale.h... yes checking for wchar.h... yes checking for thread.h... no checking for pthread.h... yes checking for CHAR_BIT... yes checking whether byte ordering is bigendian... no checking for collect2 libraries... none required checking for library containing exc_resume... no checking for library containing ldexp... none required checking for inttypes.h... yes checking for times... yes checking for clock... yes checking for kill... yes checking for getrlimit... yes checking for setrlimit... yes checking for atoll... yes checking for atoq... no checking for sysconf... yes checking for strsignal... yes checking for getrusage... yes checking for nl_langinfo... yes checking for scandir... yes checking for alphasort... yes checking for gettimeofday... yes checking for mbstowcs... yes checking for wcswidth... yes checking for mmap... yes checking for mincore... yes checking for setlocale
[Bug bootstrap/25543] Bootstrap fails with *** No rule to make target `../build-x86_64-unknown-linux-gnu/libiberty/libiberty.a', needed by `build/genmodes'.
--- Comment #1 from eesrjhc at bath dot ac dot uk 2005-12-23 08:55 --- Argh -- how embarassing. I'd been looking at it for ages and never seen my error. I should have used "../trunk/configure " not "../trunk/gcc/configure " etc. Sorry for the noise. -- eesrjhc at bath dot ac dot uk changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID Summary|Bootstrap fails with *** No|Bootstrap fails with *** No |rule to make target |rule to make target |`../build-x86_64-unknown- |`../build-x86_64-unknown- |linux- |linux- |gnu/libiberty/libiberty.a', |gnu/libiberty/libiberty.a', |needed by `build/genmodes'. |needed by `build/genmodes'. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25543
[Bug target/25005] [4.1/4.2 regression] ICE in extract_constrain_insn_cached, at recog.c:2002
--- Comment #9 from jakub at gcc dot gnu dot org 2005-12-23 09:43 --- Subject: Bug 25005 Author: jakub Date: Fri Dec 23 09:43:36 2005 New Revision: 109013 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109013 Log: PR target/25005 * regrename.c (replace_oldest_value_reg): Use validate_change with IN_GROUP set to 1 instead of doing direct modifications. (copyprop_hardreg_forward_1): Likewise. If any replace_oldest_* replacements have been performed on an instruction, use apply_change_group (). * g++.dg/opt/pr25005.C: New test. Added: trunk/gcc/testsuite/g++.dg/opt/pr25005.C Modified: trunk/gcc/ChangeLog trunk/gcc/regrename.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25005
[Bug target/25005] [4.1/4.2 regression] ICE in extract_constrain_insn_cached, at recog.c:2002
--- Comment #10 from jakub at gcc dot gnu dot org 2005-12-23 09:44 --- Subject: Bug 25005 Author: jakub Date: Fri Dec 23 09:44:41 2005 New Revision: 109014 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109014 Log: PR target/25005 * regrename.c (replace_oldest_value_reg): Use validate_change with IN_GROUP set to 1 instead of doing direct modifications. (copyprop_hardreg_forward_1): Likewise. If any replace_oldest_* replacements have been performed on an instruction, use apply_change_group (). * g++.dg/opt/pr25005.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/opt/pr25005.C Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/regrename.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25005
[Bug target/25005] [4.1/4.2 regression] ICE in extract_constrain_insn_cached, at recog.c:2002
--- Comment #11 from jakub at gcc dot gnu dot org 2005-12-23 09:49 --- Fixed in SVN. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25005
[Bug c++/25544] New: internal compiler error: in write_type, at cp/mangle.c:1645
$ cat >driver.cxx
template
struct Ref
{
};
namespace Bits
{
template
X&
x ();
}
template
typeof (Bits::x () + Bits::x ())
operator+ (Ref const& x, Ref const& y)
{
return X (0) + Y (0);
}
int
main ()
{
Ref ra;
Ref rb;
int j = ra + rb;
}
$ g++-4.0 --version
g++-4.0 (GCC) 4.0.3 20051201 (prerelease) (Debian 4.0.2-5)
$ g++-4.0 driver.cxx
driver.cxx: In function '__typeof__ ((x() + x())) operator+(const
Ref&, const Ref&) [with X = int, Y = int]':
driver.cxx:17: internal compiler error: in write_type, at cp/mangle.c:1645
--
Summary: internal compiler error: in write_type, at
cp/mangle.c:1645
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: boris at kolpackov dot net
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25544
[Bug libfortran/25545] New: internal file and dollar edit descriptor
We should probably issue a warning or error here, or else blank out the rest of the line (g77 and ifort do so). This is a corner case of an extension, so I don't think this merits anything more than "enhancement". $ cat dollar.f program main character*20 line line = '1234567890ABCDEFGHIJ' write (line, '(A$)') 'asdf' print *,line end $ gfortran dollar.f $ ./a.out asdf567890ABCDEFGHIJ $ g77 dollar.f $ ./a.out asdf $ gfortran -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../../gcc/trunk/configure --prefix=/home/ig25 --enable-languages=c,fortran Thread model: posix gcc version 4.2.0 20051220 (experimental) -- Summary: internal file and dollar edit descriptor Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25545
[Bug c++/25546] New: Wrong-type destructor call accepted in template with no error
Hi all. g++ 3.4.4 seems to accept calling a destructor ~T() on a char * pointer
if you're inside a template in certain cases. Obviously not very serious in the
grand scheme of things! Apologies if this has been fixed - I couldn't find it
in the bug list, though.
--- START EXAMPLE ---
class Foo {};
struct Bing
{
char *GetChar() { return new char; }
};
template struct Bar
{
void Wibble()
{
bing.GetChar()->~T(); // How can this be legal if T isn't char?
}
Bing bing;
};
int main()
{
Bar fooBar;
fooBar.Wibble();
}
--- END EXAMPLE ---
You can see that the (char *) return from GetChar() has ~Foo() called on it,
but g++ 3.4.4 happily accepts this. It doesn't actually enter the destructor
for Foo - I guess it's calling the char destructor. If you split the call to
GetChar into "char *p = bing.GetChar(); p->~T();", then the compiler spots that
there's something wrong:
gccbug.cpp: In member function `void Bar::Wibble() [with T = Foo]':
gccbug.cpp:21: instantiated from here
gccbug.cpp:12: error: `*p' is not of type `Foo'
Haven't tried it on g++ 3.4.5 or 4.0.x - I don't have time before Xmas
(sorry). Command line is "g++ -o gccbug gccbug.cpp", g++ -v gives:
Reading specs from
/space/azuro2/i686-pc-linux-gnu/toolset/lib/gcc/i686-pc-linux-gnu/3.4.4/specs
Configured with: ../gcc-3.4.4/configure --with-gnu-as --with-gnu-ld
--prefix=/space/azuro2/i686-pc-linux-gn/toolset -v : (reconfigured)
../gcc-3.4.4/configure --with-gnu-as --with-gnu-ld
--prefix=/space/azuro2/i686-pc-linux-gnu/toolset -v
Thread model: posix
gcc version 3.4.4
Hope this helps. Have a good Xmas y'all, regards Steev
--
Summary: Wrong-type destructor call accepted in template with no
error
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: steev at azuro dot com
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25546
[Bug c/25547] New: 3 * dead data in compiler source code
I just tried to compile the gcc-4.2 snapshot 20051217 with the Intel C compiler. It said 1. ../../src/gcc-4.2-20051217/gcc/builtins.c(1155): remark #593: variable "apply_args_reg_offset" was set but never used The source code is static int apply_args_reg_offset[FIRST_PSEUDO_REGISTER]; I have read the source code, and I agree with the compiler. The data is only ever written to. Suggest delete dead data. 2. ../../src/gcc-4.2-20051217/gcc/gcse.c(290): remark #593: variable "debug_stderr" was set but never used The source code is static FILE *debug_stderr; I have read the source code, and I agree with the compiler. The data is only ever written to. Suggest delete dead data. 3. ../../src/gcc-4.2-20051217/gcc/ggc-common.c(68): remark #593: variable "ggc_stats" was set but never used The source code is static ggc_statistics *ggc_stats; I have read the source code, and I agree with the compiler. The data is only ever written to. Suggest delete dead data. -- Summary: 3 * dead data in compiler source code Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dcb314 at hotmail dot com GCC host triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25547
[Bug libfortran/25139] [4.1/4.2 regression] "Invalid argument" error on I/O
--- Comment #31 from dir at lanl dot gov 2005-12-23 15:14 --- Hi Jerry, Would you go ahead and commit this ? A test case something like that in Comment #9 shows the problem before and the fix after or may be you have a better one from NIST. The change suggest in comment #14 fixes the problem that started all of this for me. There are other bugs, that I have hit looking into this, but I think that they should be in seperate bug reports. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25139
[Bug middle-end/25547] 3 * dead data in compiler source code
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-23 15:19 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|c |middle-end Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-12-23 15:19:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25547
[Bug c++/25544] internal compiler error: in write_type, at cp/mangle.c:1645
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-23 15:52 --- *** This bug has been marked as a duplicate of 11078 *** -- 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=25544
[Bug c++/11078] [ABI] ICE in write_type with typeof and templates
--- Comment #25 from pinskia at gcc dot gnu dot org 2005-12-23 15:52 --- *** Bug 25544 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11078
system.h: #define INTTYPE_MAXIMUM - Bug
If you compile by non GCC compiler change: #define INTTYPE_MAXIMUM(t) ((t) (~ (t) 0 - INTTYPE_MINIMUM (t))) to: #define INTTYPE_MAXIMUM(t) ((t) (~ ((t) 0 - INTTYPE_MINIMUM (t gcc-4.1-20051008 -- Sent from the gcc - bugs forum at Nabble.com: http://www.nabble.com/system.h%3A-define-INTTYPE_MAXIMUM---Bug-t797993.html#a2076765
[Bug c++/25546] [3.4 Regression] Wrong-type destructor call accepted in template with no error
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-23 15:57 --- Confirmed, only a 3.4 regression. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||accepts-invalid Known to fail||3.4.0 3.4.5 Known to work||4.0.2 4.1.0 4.2.0 3.3.3 Last reconfirmed|-00-00 00:00:00 |2005-12-23 15:57:07 date|| Summary|Wrong-type destructor call |[3.4 Regression] Wrong-type |accepted in template with no|destructor call accepted in |error |template with no error http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25546
[Bug c++/25548] New: Rejects dependent deconstructor on a non depdendent name (for basic types) too late
Testcase:
class Foo {};
struct Bing
{
char *GetChar();
};
template struct Bar
{
void Wibble()
{
bing.GetChar()->~T(); // How can this be legal if T isn't char?
}
Bing bing;
};
-
If we change the return type of GetChar() to Foo * (from char*), we get an
error:
t.cc: In member function void Bar::Wibble():
t.cc:12: error: the type being destroyed is Foo, but the destructor refers to
T
--
Summary: Rejects dependent deconstructor on a non depdendent name
(for basic types) too late
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: minor
Priority: P3
Component: c++
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=25548
[Bug c++/25546] [3.4 Regression] Wrong-type destructor call accepted in template with no error
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-23 16:03 --- I should note that we should reject this earlier, so I filed PR 25548. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25546
[Bug libfortran/25550] New: file data corrupted after reading end of file
After the end of file is read, the file data is corrupted - [dranta:~/tests/gfortran-D] dir% gfortran -o write17 write17.f [dranta:~/tests/gfortran-D] dir% write17 538976288 Abort [dranta:~/tests/gfortran-D] dir% cat write17.f integer data data=-1 open(unit=11,status='scratch',form='unformatted') write(11)data read(11,end=1000 )data 1000 continue rewind 11 read(11,end=1001 )data 1001 continue if(data.ne.-1)then write(6,*)data call abort endif close(11) end -- Summary: file data corrupted after reading end of file Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dir at lanl dot gov GCC host triplet: powerpc-apple-darwin8.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25550
[Bug fortran/25532] [gfortran, regression] ICE in gfc_conv_component_ref, at fortran/trans-expr.c:269
--- Comment #3 from eedelman at gcc dot gnu dot org 2005-12-23 17:58 --- (In reply to comment #2) > So it seems the problem was introduced within the last 24 hours. To be a bit more precise: works with revision 108902, ICE:s with revision 108943. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25532
[Bug rtl-optimization/21041] [4.0/4.1/4.2 Regression] ICE: output_operand: Cannot decompose address
--- Comment #13 from uweigand at gcc dot gnu dot org 2005-12-23 18:38 --- Subject: Bug 21041 Author: uweigand Date: Fri Dec 23 18:38:43 2005 New Revision: 109019 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109019 Log: PR rtl-optimization/21041 * reload.c (find_reloads_subreg_address): Replace paradoxical subreg of MEM by widened access only if the resulting memory is properly aligned, even on !STRICT_ALIGNMENT targets. PR rtl-optimization/21041 * gcc.dg/pr21041.c: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/pr21041.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/reload.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21041
[Bug rtl-optimization/21041] [4.0/4.1/4.2 Regression] ICE: output_operand: Cannot decompose address
--- Comment #14 from uweigand at gcc dot gnu dot org 2005-12-23 18:44 --- Subject: Bug 21041 Author: uweigand Date: Fri Dec 23 18:44:07 2005 New Revision: 109020 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109020 Log: PR rtl-optimization/21041 * reload.c (find_reloads_subreg_address): Replace paradoxical subreg of MEM by widened access only if the resulting memory is properly aligned, even on !STRICT_ALIGNMENT targets. PR rtl-optimization/21041 * gcc.dg/pr21041.c: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/gcc.dg/pr21041.c Modified: branches/gcc-4_0-branch/gcc/ChangeLog branches/gcc-4_0-branch/gcc/reload.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21041
[Bug rtl-optimization/21041] [4.0/4.1/4.2 Regression] ICE: output_operand: Cannot decompose address
--- Comment #15 from uweigand at gcc dot gnu dot org 2005-12-23 18:45 --- Fixed. -- uweigand at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21041
[Bug other/25551] New: gcov incorrect count for lone return in block
gcov incorrectly shows that a lone return statement inside a block
has executed when in fact it has not
Environment:
System: Linux mercury.acucorp.com 2.4.18-27.8.0smp #1 SMP Fri Mar 14 07:13:13
EST 2003 i686 athlon i386 GNU/Linux
Architecture: i686
host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: ../gcc-4.0.2/configure --prefix=/usr/local/gcc-4.0.2
How-To-Repeat:
Compile the following program, run it, then run gcov on the source:
gcc -fprofile-arcs -ftest-coverage -o foo foo.c
./foo
gcov -b foo.c
--- foo.c:
#include
static void
foo(int num)
{
if (num <= 1) {
/* uncomment following line to get correct results */
// printf("num <= 1\n");
/* this return is never executed, but gcov says it is */
return;
}
printf("num > 1\n");
} /* foo */
int
main(void)
{
foo(3);
foo(3);
foo(3);
foo(3);
foo(3);
foo(3);
foo(3);
return 0;
}
--- foo.c.gcov:
-:0:Source:foo.c
-:0:Graph:foo.gcno
-:0:Data:foo.gcda
-:0:Runs:1
-:0:Programs:1
-:1:#include
-:2:
-:3:static void
-:4:foo(int num)
function foo called 7 returned 100% blocks executed 100%
7:5:{
7:6:if (num <= 1) {
branch 0 taken 100% (fallthrough)
branch 1 taken 0%
-:7:/* uncomment following line to get correct results */
-:8:// printf("num <= 1\n");
-:9:
-: 10:/* this return is never executed, but gcov says it is
*/
7: 11:return;
-: 12:}
-: 13:
7: 14:printf("num > 1\n");
call0 returned 100%
-: 15:} /* foo */
-: 16:
-: 17:
-: 18:int
-: 19:main(void)
function main called 1 returned 100% blocks executed 100%
1: 20:{
1: 21:foo(3);
call0 returned 100%
1: 22:foo(3);
call0 returned 100%
1: 23:foo(3);
call0 returned 100%
1: 24:foo(3);
call0 returned 100%
1: 25:foo(3);
call0 returned 100%
1: 26:foo(3);
call0 returned 100%
1: 27:foo(3);
call0 returned 100%
1: 28:return 0;
-: 29:}
--- Comment #1 from mark at acucorp dot com 2005-12-23 18:57 ---
Fix:
unknown
--
Summary: gcov incorrect count for lone return in block
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mark at acucorp dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25551
[Bug libstdc++/16611] Terrible code generated for vector
--- Comment #9 from pcarlini at suse dot de 2005-12-23 20:12 --- FWIW, on x86-linux at least, we are making progress on the compiler side. With 4.0.2 I get (-O2): <_Z1fRKSt6vectorIbSaIbEEj>: 0: 55 push %ebp 1: 89 e5 mov%esp,%ebp 3: 53 push %ebx 4: 8b 5d 08mov0x8(%ebp),%ebx 7: 8b 55 0cmov0xc(%ebp),%edx a: 8b 43 04mov0x4(%ebx),%eax d: 01 d0 add%edx,%eax f: 89 c1 mov%eax,%ecx 11: c1 f9 1fsar$0x1f,%ecx 14: c1 e9 1bshr$0x1b,%ecx 17: 8d 04 01lea(%ecx,%eax,1),%eax 1a: 89 c2 mov%eax,%edx 1c: 83 e0 1fand$0x1f,%eax 1f: c1 fa 05sar$0x5,%edx 22: c1 e2 02shl$0x2,%edx 25: 03 13 add(%ebx),%edx 27: 29 c8 sub%ecx,%eax 29: 89 c1 mov%eax,%ecx 2b: 78 13 js 40 <_Z1fRKSt6vectorIbSaIbEEj+0x40> 2d: b8 01 00 00 00 mov$0x1,%eax 32: d3 e0 shl%cl,%eax 34: 85 02 test %eax,(%edx) 36: 5b pop%ebx 37: 5d pop%ebp 38: 0f 95 c0setne %al 3b: 83 e0 01and$0x1,%eax 3e: c3 ret 3f: 90 nop 40: 83 c1 20add$0x20,%ecx 43: b8 01 00 00 00 mov$0x1,%eax 48: d3 e0 shl%cl,%eax 4a: 83 ea 04sub$0x4,%edx 4d: 85 02 test %eax,(%edx) 4f: 5b pop%ebx 50: 5d pop%ebp 51: 0f 95 c0setne %al 54: 83 e0 01and$0x1,%eax 57: c3 ret With current 4_1-branch: <_Z1fRKSt6vectorIbSaIbEEj>: 0: 55 push %ebp 1: 89 e5 mov%esp,%ebp 3: 53 push %ebx 4: 8b 5d 08mov0x8(%ebp),%ebx 7: 8b 45 0cmov0xc(%ebp),%eax a: 8b 53 04mov0x4(%ebx),%edx d: 01 d0 add%edx,%eax f: 89 c1 mov%eax,%ecx 11: c1 f9 1fsar$0x1f,%ecx 14: c1 e9 1bshr$0x1b,%ecx 17: 8d 04 01lea(%ecx,%eax,1),%eax 1a: 89 c2 mov%eax,%edx 1c: 83 e0 1fand$0x1f,%eax 1f: c1 fa 05sar$0x5,%edx 22: c1 e2 02shl$0x2,%edx 25: 03 13 add(%ebx),%edx 27: 29 c8 sub%ecx,%eax 29: 89 c1 mov%eax,%ecx 2b: 78 13 js 40 <_Z1fRKSt6vectorIbSaIbEEj+0x40> 2d: b8 01 00 00 00 mov$0x1,%eax 32: d3 e0 shl%cl,%eax 34: 85 02 test %eax,(%edx) 36: 5b pop%ebx 37: 5d pop%ebp 38: 0f 95 c0setne %al 3b: 83 e0 01and$0x1,%eax 3e: c3 ret 3f: 90 nop 40: 83 c1 20add$0x20,%ecx 43: 83 ea 04sub$0x4,%edx 46: eb e5 jmp2d <_Z1fRKSt6vectorIbSaIbEEj+0x2d> -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16611
[Bug libfortran/25139] [4.1/4.2 regression] "Invalid argument" error on I/O
--- Comment #32 from jvdelisle at gcc dot gnu dot org 2005-12-23 20:21 --- Yes, I will work this up with a proper test case and submit for approval. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25139
[Bug gcov/profile/25551] [4.0 Regression] gcov incorrect count for lone return in block
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-23 20:53 --- Confirmed, only a 4.0 regression. Works in 4.1.0 and 3.4.0. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|other |gcov/profile Ever Confirmed|0 |1 Known to fail||4.0.2 4.0.0 Known to work||4.1.0 4.2.0 Last reconfirmed|-00-00 00:00:00 |2005-12-23 20:53:05 date|| Summary|gcov incorrect count for|[4.0 Regression] gcov |lone return in block|incorrect count for lone ||return in block Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25551
[Bug libgcj/19132] InputStreamReader constructor missing
--- Comment #2 from tromey at gcc dot gnu dot org 2005-12-23 20:54 --- I'm working on a patch. -- tromey at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-03-23 03:11:50 |2005-12-23 20:54:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19132
[Bug libgcj/9715] Not all required character encodings are supported
--- Comment #3 from tromey at gcc dot gnu dot org 2005-12-23 20:55 --- My PR 19132 fix should fix this as well. -- tromey at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-07-23 05:27:06 |2005-12-23 20:55:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9715
[Bug libstdc++/16611] Terrible code generated for vector
--- Comment #10 from pcarlini at suse dot de 2005-12-23 21:13 --- Well, I'm not sure that, besides code size, 4_1 is doing better than 4.0.2, but both are certainly better than 3.4.x. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16611
[Bug c++/25552] New: [4.0/4.1/4.2 regression] Invalid destructor name accepted in friend declaration
The following invalid code snippet is not rejected:
struct A {};
struct B
{
friend A::~B();
};
The problem appeared in gcc 4.0.0.
--
Summary: [4.0/4.1/4.2 regression] Invalid destructor name
accepted in friend declaration
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: accepts-invalid, monitored, patch
Severity: normal
Priority: P3
Component: c++
AssignedTo: reichelt at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25552
[Bug c++/25552] [4.0/4.1/4.2 regression] Invalid destructor name accepted in friend declaration
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||12/msg01712.html Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25552
[Bug c++/24671] [4.0/4.1/4.2 regression] ICE with zero-sized arrays
--- Comment #3 from mmitchel at gcc dot gnu dot org 2005-12-23 23:16 --- Subject: Bug 24671 Author: mmitchel Date: Fri Dec 23 23:16:12 2005 New Revision: 109022 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109022 Log: PR c++/24671 * pt.c (instantiate_template): Handle SFINAE. PR c++/24671 * g++.dg/template/sfinae3.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/sfinae3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24671
[Bug c++/24671] [4.0/4.1/4.2 regression] ICE with zero-sized arrays
--- Comment #4 from mmitchel at gcc dot gnu dot org 2005-12-23 23:17 --- Subject: Bug 24671 Author: mmitchel Date: Fri Dec 23 23:17:12 2005 New Revision: 109023 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109023 Log: PR c++/24671 * pt.c (instantiate_template): Handle SFINAE. PR c++/24671 * g++.dg/template/sfinae3.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/sfinae3.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/pt.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24671
[Bug c++/24671] [4.0/4.1/4.2 regression] ICE with zero-sized arrays
--- Comment #5 from mmitchel at gcc dot gnu dot org 2005-12-23 23:18 --- Subject: Bug 24671 Author: mmitchel Date: Fri Dec 23 23:18:06 2005 New Revision: 109024 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109024 Log: PR c++/24671 * pt.c (instantiate_template): Handle SFINAE. PR c++/24671 * g++.dg/template/sfinae3.C: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/g++.dg/template/sfinae3.C Modified: branches/gcc-4_0-branch/gcc/cp/ChangeLog branches/gcc-4_0-branch/gcc/cp/pt.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24671
[Bug c++/24671] [4.0/4.1/4.2 regression] ICE with zero-sized arrays
--- Comment #6 from mmitchel at gcc dot gnu dot org 2005-12-23 23:24 --- Fixed in 4.0.3. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24671
[Bug middle-end/25522] zero-initialized constants are place in .bss
--- Comment #4 from geoffk at geoffk dot org 2005-12-23 23:33 --- Subject: Re: New: zero-initialized constants are place in .bss "drepper at redhat dot com" <[EMAIL PROTECTED]> writes: > const struct foo f; > > The compiler will mark the variable f in .bss instead of, as the const > indicates, into .rodata. What happens if you use -fno-common? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25522
[Bug c++/23171] [4.1/4.2 Regression] ICE on pointer initialization with C99 initializer
--- Comment #13 from mmitchel at gcc dot gnu dot org 2005-12-23 23:40 --- I've finally figured out a tractable solution to this problem: just treat these as dynamic initializations. That will be slightly less efficient than what the C front end does, and result in a different initialization order, but so be it. Testing a patch now. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23171
[Bug tree-optimization/25553] New: Missed removal of load
I don't know what this optimization is called but we miss the removal of the
load of a global variable:
int t;
int g(int);
int f(int tt)
{
if (tt)
t = 2;
else
t = 3;
return g(t);
}
I should note I found this while looking at LAPACK.
--
Summary: Missed removal of load
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
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=25553
[Bug tree-optimization/25553] Missed removal of load
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-24 01:51 --- I should mention this shows up semi a lot in fortran code as what happens is that t is not really a global variable but instead a local variable which is passed to another function. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25553
[Bug tree-optimization/25554] New: [4.0 Regression] unrecognizable insn on x86_64 with -O2 -ftracer
When compiling the supplied test case with `gcc -c -O2 -ftracer test.c` with
gcc-4.0.3 the following error occurs:
test.c: In function mpfr_pow_ui:
test.c:18: error: unrecognizable insn:
(insn 96 44 46 6 (set (reg:CCZ 17 flags)
(compare:CCZ (and:DI (reg/v:DI 66 [ n ])
(const_int 4611686018427387904 [0x4000]))
(const_int 0 [0x0]))) -1 (nil)
(expr_list:REG_DEAD (reg/v:DI 66 [ n ])
(nil)))
test.c:18: internal compiler error: in extract_insn, at recog.c:2020
This does not occur in 3.4, 4.1, or 4.2. Revision 98597 on gcc-4_1-branch
seems to be where it was fixed for 4.1. Here is the testcase I am using:
unsigned int __gmpfr_flags;
int
mpfr_pow_ui (unsigned long int n)
{
unsigned long m;
int inexact;
int i;
for (m = n, i = 0; m; i++, m >>= 1)
;
((void) (__gmpfr_flags &= 31 ^ 1));
if (n & (1UL << (i-2)))
return 0;
}
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4/configure --prefix=/home/halcy0n/gcc-test/bin-4/
--enable-languages=c,c++ --disable-multilib
Thread model: posix
gcc version 4.0.3 20051222 (prerelease)
--
Summary: [4.0 Regression] unrecognizable insn on x86_64 with -O2
-ftracer
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: halcy0n at gentoo dot org
GCC build triplet: x86_64-pc-linux-gnu
GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25554
[Bug tree-optimization/25554] [3.4/4.0/4.1/4.2 Regression] unrecognizable insn on x86_64 with -O2 -ftracer ( -fno-tree-dominator-opts on the mainline)
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-24 04:38 ---
Better testcase which shows it also on the 3.4 branch:
unsigned int __gmpfr_flags;
int
f (unsigned long int n)
{
int prephitmp3;
int i;
long unsigned int m;
if (n == 0)
prephitmp3 = -2;
else
{
m = n;
i = 0;
do {
i = i + 1;
m = m >> 1;
} while (m != 0);
prephitmp3 = i - 2;
}
__gmpfr_flags = __gmpfr_flags & 30;
if (((int) (n >> prephitmp3) & 1) != 0) return 0;
}
This also shows up on the mainline with "-O2 -ftracer
-fno-tree-dominator-opts".
Confirmed, 3.3.6 actually worked fully with -O2 -ftracer so this is a
regression from that version.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||ice-on-valid-code
Known to fail|4.0.3 |4.0.3 3.4.5 4.1.0 4.2.0
Known to work|3.4.5 4.1.0 4.2.0 |3.3.6
Last reconfirmed|-00-00 00:00:00 |2005-12-24 04:38:07
date||
Summary|[4.0 Regression]|[3.4/4.0/4.1/4.2 Regression]
|unrecognizable insn on |unrecognizable insn on
|x86_64 with -O2 -ftracer|x86_64 with -O2 -ftracer ( -
||fno-tree-dominator-opts on
||the mainline)
Target Milestone|--- |4.0.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25554
[Bug tree-optimization/23134] Address escapes even though the called function does not cause it to escape
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-12-24 07:54 --- ICC does not even do this optimization. I should note that Fortran code has something like this, except you don't need to know about the function that is being called, just the variable and if it has TARGET on it or not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23134
