[Bug target/19645] PPC64 64-bit build failure
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-28 08:11 --- I'm starting to think there's something wrong with the system 64-bit libc. Lets close for now, and I'll report again if I can find something reproducible. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19645
[Bug target/19663] LINK_GCC_C_SEQUENCE_SPEC doesn't play nice with RTEMS
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-01-28 08:16 --- IMO, sparc.h's LINK_GCC_C_SEQUENCE_SPEC probably is specific to solaris and not generally applicable. May-be, it's an historic artefact. As I already said, it is generally applicable and not specific to Solaris, in that it should be the default behaviour for a generic linker. And it is not an historic artifact either (it was added relatively recently, see the link I already pointed at). -- What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |RESOLVED Resolution||FIXED Summary|sparc.h's |LINK_GCC_C_SEQUENCE_SPEC |LINK_GCC_C_SEQUENCE_SPEC|doesn't play nice with RTEMS |lacks generality| Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19663
[Bug target/19663] LINK_GCC_C_SEQUENCE_SPEC doesn't play nice with RTEMS
--- Additional Comments From ralf dot corsepius at rtems dot org 2005-01-28 09:17 --- (In reply to comment #2) IMO, sparc.h's LINK_GCC_C_SEQUENCE_SPEC probably is specific to solaris and not generally applicable. May-be, it's an historic artefact. As I already said, it is generally applicable RTEMS-gcc proves this statement is to be incorrect. Anyway, I have applied a work-around to the rtems, so thanks for closing this PR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19663
[Bug c++/19665] New: Can access private member function if it is virtual
I was doing some experiments and I discovered that I can access a private member
function if I make it virtual and do few other tricks. The code is below.
The Base class called is printed. So, basically when someone wants to access
a virtual function (by explicit type casting), there is no check whether that
virtual function is private or not. But if I try to call it directly, it checks
that it is a private member function. May be g++ compiler needs to be modified.
#includeiostream
using namespace std;
class A {
private:
virtual void abc()
{
cout Base Class called\n;
}
};
class B : public A {
public:
void abc()
{
cout Derived Class called\n;
}
};
int main()
{
A a;
B *b = static_castB *(a);
b-abc();
}
[amit]$ g++ c++-bug.cpp
c++-bug.cpp:6: warning: all member functions in class `A' are private
[amit]$ ./a.out
Base Class called
[amit]$
--
Summary: Can access private member function if it is virtual
Product: gcc
Version: 3.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amit_choudhary at mindtree dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: g++ c++-bug.cpp c++-bug.cpp:6: warning: all member
functions in
GCC host triplet: gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7)
GCC target triplet: Configured with: ../configure --prefix=/usr --
mandir=/usr/share/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19665
[Bug tree-optimization/19333] [4.0 Regression] Compilation SEGFAULTs with -O1 -finline-functions on the x86_64 architecture.
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-28 09:25 --- With the patch from comment #10 I get the following extra failures: gcc.c-torture/compile/20011130-1.c -O0 (test for excess errors) gcc.c-torture/compile/20011130-1.c -O1 (test for excess errors) gcc.c-torture/compile/20011130-1.c -O2 (test for excess errors) gcc.c-torture/compile/20011130-1.c -O3 -fomit-frame-pointer (test for excess errors) gcc.c-torture/compile/20011130-1.c -O3 -g (test for excess errors) gcc.c-torture/compile/20011130-1.c -Os (test for excess errors) gcc.dg/20030815-1.c (test for excess errors) gcc.dg/array-7.c (test for errors, line 14) gcc.dg/array-7.c (test for excess errors) gcc.dg/noncompile/2901-1.c -O0 (test for excess errors) gcc.dg/noncompile/2901-1.c -O1 (test for excess errors) gcc.dg/noncompile/2901-1.c -O2 (test for excess errors) gcc.dg/noncompile/2901-1.c -O3 -fomit-frame-pointer (test for excess errors) gcc.dg/noncompile/2901-1.c -O3 -g (test for excess errors) gcc.dg/noncompile/2901-1.c -Os (test for excess errors) gcc.dg/noncompile/init-2.c -O0 (test for excess errors) gcc.dg/noncompile/init-2.c -O1 (test for excess errors) gcc.dg/noncompile/init-2.c -O2 (test for excess errors) gcc.dg/noncompile/init-2.c -O3 -fomit-frame-pointer (test for excess errors) gcc.dg/noncompile/init-2.c -O3 -g (test for excess errors) gcc.dg/noncompile/init-2.c -Os (test for excess errors) Much appreciated if a C language guru could see if these are not false positives. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19333
[Bug c++/19665] Can access private member function if it is virtual
--- Additional Comments From amit_choudhary at mindtree dot com 2005-01-28 09:29 --- Created an attachment (id=8088) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8088action=view) Preprocessed file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19665
[Bug c++/19666] New: ICE in fold_convert
struct L { void *a; };
struct S {
static S *foo (L *x)
{
return (S *) ((char *) x - (unsigned long) (((S *) 0)-*S::a));
}
L a;
};
causes ICE in fold_convert (abort at the very end of the function).
Works fine with G++ 3.2.3-RH and HEAD.
Breakpoint 2, fold_convert (type=0x2a97b66d00, arg=0x2a97d65c60) at
../../gcc/fold-const.c:1917
1917 abort ();
(gdb) p debug_tree(type)
integer_type 0x2a97b66d00 long int DI
size integer_cst 0x2a97b64930 type integer_type 0x2a97b78410
bit_size_type
constant 64
unit size integer_cst 0x2a97b64a80 type integer_type 0x2a97b78340 long
unsigned int constant 8
align 64 symtab 0 alias set -1 precision 64 min integer_cst 0x2a97b64a20
-9223372036854775808 max integer_cst 0x2a97b64a50 9223372036854775807
$1 = void
(gdb) p debug_tree(arg)
negate_expr 0x2a97d65c60
type offset_type 0x2a97d63820
type record_type 0x2a97d58680 L type_1 type_5 DI
size integer_cst 0x2a97b749c0 constant 64
unit size integer_cst 0x2a97b74a80 constant 8
align 64 symtab 0 alias set -1 fields field_decl 0x2a97d589c0 a
X() X(constX) this=(X) n_parents 0 use_template=0
interface-unknown
member-functions tree_vec 0x2a97d5d980
elt 0 overload 0x2a97d50fc0
elt 2 function_decl 0x2a97d5fa90 operator=
elt 3 overload 0x2a97d61040
elt 4 overload 0x2a97d61000
pointer_to_this pointer_type 0x2a97d58750 reference_to_this
reference_type 0x2a97d5f680 chain type_decl 0x2a97d58820 L
DI size integer_cst 0x2a97b749c0 64 unit size integer_cst
0x2a97b74a80
8
align 64 symtab 0 alias set -1 basetype record_type 0x2a97d604e0 S
constant
arg 0 ptrmem_cst 0x2a97d658a0 type offset_type 0x2a97d63820
constant
$2 = void
--
Summary: ICE in fold_convert
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19666
[Bug c++/19665] Can access private member function if it is virtual
--- Additional Comments From falk at debian dot org 2005-01-28 09:41 --- Since this cast has undefined behaviour, as a is not actually a B, any behaviour of the program is acceptable, including what you get. Note that private was never meant as a security feature, there are lots of ways to circumvent it. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19665
[Bug c++/19666] ICE in fold_convert
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-28 09:49 --- Hmm, what target, what options did you use? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19666
[Bug c++/19664] -fvisibility-inlines-hidden fails with gcc's extern template extension on amd64
--- Additional Comments From pcarlini at suse dot de 2005-01-28 09:56 --- Thanks for the nice testcase. Is this really a GCC bug, or a binutils bug: http://bugs.gentoo.org/show_bug.cgi?id=79711 ??? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19642] streaming doubles is very slow compared to sprintf
--- Additional Comments From pcarlini at suse dot de 2005-01-28 09:58 --- Thanks. We are now reasonably confident that the patch is safe, besides providing a good performance improvement. Most probably we shall apply it soon, I'll take care of the next steps. Thanks again. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19642
[Bug c++/19666] ICE in fold_convert
--- Additional Comments From jakub at gcc dot gnu dot org 2005-01-28 10:01
---
Any target I have tried, any options.
It fails at least on {i386,x86_64,ppc,ppc64,s390,s390x}-redhat-linux,
with -O{0,1,2,3,s}.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19666
[Bug target/19663] LINK_GCC_C_SEQUENCE_SPEC doesn't play nice with RTEMS
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-01-28 10:16 --- As I already said, it is generally applicable RTEMS-gcc proves this statement is to be incorrect. Please quote the whole sentence, not a random chunk out of context. Anyway, I have applied a work-around to the rtems, so thanks for closing this PR. You're welcome. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19663
[Bug fortran/19654] compilation crashes when variable is too large instead of showing error
--- Additional Comments From coudert at clipper dot ens dot fr 2005-01-28 10:37 --- It seems that, above a given size, gfortran declares the array as non-static: $ cat a.f90 program kk implicit none integer, parameter :: N=32768**2 real, dimension(N) :: input call random_number(input) end program kk $ diff a.f90 b.f90 3c3 integer, parameter :: N=32768**2 --- integer, parameter :: N=32765**2 $ diff a.f90.t02.original b.f90.t02.original 3c3 real4 input[1073741824]; --- static real4 input[1073545225]; 10c10 parm.0.dim[0].ubound = 1073741824; --- parm.0.dim[0].ubound = 1073545225; $ gfortran -fdump-tree-original a.f90 a.f90: In function MAIN__: a.f90:5: internal compiler error: in tree_low_cst, at tree.c:3816 $ gfortran -fdump-tree-original b.f90 b.f90: In function MAIN__: b.f90:4: error: size of variable input is too large Maybe this information will be useful to our gfortran gurus. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19654
[Bug c++/19667] New: ICE on (very trivial) invalid
Is this ICE well known? (4.0.0 20050127)
struct integral_constant { };
templatetypename _Tp
struct is_function
: public integral_constant { };
template
struct is_function
: public integral_constant { };
--
Summary: ICE on (very trivial) invalid
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pcarlini at suse dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19667
[Bug tree-optimization/19333] [4.0 Regression] Compilation SEGFAULTs with -O1 -finline-functions on the x86_64 architecture.
--- Additional Comments From joseph at codesourcery dot com 2005-01-28 11:09 --- Subject: Re: [4.0 Regression] Compilation SEGFAULTs with -O1 -finline-functions on the x86_64 architecture. On Fri, 28 Jan 2005, steven at gcc dot gnu dot org wrote: gcc.c-torture/compile/20011130-1.c -O0 (test for excess errors) gcc.c-torture/compile/20011130-1.c -O1 (test for excess errors) gcc.c-torture/compile/20011130-1.c -O2 (test for excess errors) gcc.c-torture/compile/20011130-1.c -O3 -fomit-frame-pointer (test for excess errors) gcc.c-torture/compile/20011130-1.c -O3 -g (test for excess errors) gcc.c-torture/compile/20011130-1.c -Os (test for excess errors) gcc.dg/20030815-1.c (test for excess errors) Correct, I don't know whether it's useful to reorder the testcases minimally to avoid arrays of incomplete types. gcc.dg/array-7.c (test for errors, line 14) gcc.dg/array-7.c (test for excess errors) gcc.dg/noncompile/2901-1.c -O0 (test for excess errors) gcc.dg/noncompile/2901-1.c -O1 (test for excess errors) gcc.dg/noncompile/2901-1.c -O2 (test for excess errors) gcc.dg/noncompile/2901-1.c -O3 -fomit-frame-pointer (test for excess errors) gcc.dg/noncompile/2901-1.c -O3 -g (test for excess errors) gcc.dg/noncompile/2901-1.c -Os (test for excess errors) gcc.dg/noncompile/init-2.c -O0 (test for excess errors) gcc.dg/noncompile/init-2.c -O1 (test for excess errors) gcc.dg/noncompile/init-2.c -O2 (test for excess errors) gcc.dg/noncompile/init-2.c -O3 -fomit-frame-pointer (test for excess errors) gcc.dg/noncompile/init-2.c -O3 -g (test for excess errors) gcc.dg/noncompile/init-2.c -Os (test for excess errors) For these I think the testcases should be updated to expect the additional or changed diagnostics. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19333
[Bug libfortran/19668] New: endless loop on read(10,*) with DOS file
$ cat dosfile.f90 program main character(len=1), parameter :: cr = achar(13) write(10,'(2A)') '1',cr ! Generate CR-LF on Unix rewind(10) read (*,*) n end $ gfortran dosfile.f90 $ time ./a.out (^C here, or this loops forever) real0m1.260s user0m0.000s sys 0m0.005s $ gfortran -v ; gfortran -dumpmachine Using built-in specs. Configured with: ../gcc-4.0-20050123/configure --prefix=/home/zfkts --enable-languages=c,f95 Thread model: posix gcc version 4.0.0 20050123 (experimental) ia64-unknown-linux-gnu $ od -c fort.10 000 1 \r \n 003 Thomas -- Summary: endless loop on read(10,*) with DOS file Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P2 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Thomas dot Koenig at online dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19668
[Bug fortran/19669] New: [gfortran] ICE (segfault) on legal (?) code
Current gfortran ICEs when compiling the attached testcase. As far as I could make out, the code should be valid. Reduction of the testcase seems very tricky, since the problem goes away even if I remove code after the reported line number of the error. ~/tmpgfortran -c -v bug.f90 Using built-in specs. Configured with: /scratch/gcc/configure --quiet --prefix=/afs/mpa/data/martin/ugcc --enable-languages=c++,f95 --with-gmp=/afs/mpa/data/martin/mygmp Thread model: posix gcc version 4.0.0 20050128 (experimental) /afs/mpa/data/martin/ugcc/libexec/gcc/i686-pc-linux-gnu/4.0.0/f951 bug.f90 -quiet -dumpbase bug.f90 -mtune=pentiumpro -auxbase bug -version -o /tmp/ccArzq3H.s GNU F95 version 4.0.0 20050128 (experimental) (i686-pc-linux-gnu) compiled by GNU C version 4.0.0 20050128 (experimental). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 bug.f90:3846: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. Sorry if this is a duplicate, but for a non-bugmaster it is hard to be sure with this kind of error. -- Summary: [gfortran] ICE (segfault) on legal (?) code Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: martin at mpa-garching dot mpg dot de CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19669
[Bug libfortran/19668] endless loop on read(10,*) with DOS file
--- Additional Comments From Thomas dot Koenig at online dot de 2005-01-28 11:14 --- This bug is shared by both g77 3.2.3 and ifort 8.1. Good company, at least :-) Thomas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19668
[Bug fortran/19669] [gfortran] ICE (segfault) on legal (?) code
--- Additional Comments From martin at mpa-garching dot mpg dot de 2005-01-28 11:14 --- Created an attachment (id=8089) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8089action=view) compressed testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19669
[Bug fortran/19669] [gfortran] ICE (segfault) on legal (?) code
-- What|Removed |Added Keywords||ice-on-valid-code Known to fail||4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19669
[Bug fortran/19669] [gfortran] ICE (segfault) on legal (?) code
--- Additional Comments From coudert at clipper dot ens dot fr 2005-01-28 11:49 --- As always with modules, reducing is indeed painful. There are already many bugs reported with modules and gfortran (some of them even very basic), and this could probably be one of those. Unless you have spare time to reduce this, I advise getting others module-related bugs fixed before. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19669
[Bug fortran/19669] [gfortran] ICE (segfault) on legal (?) code
-- What|Removed |Added CC||coudert at clipper dot ens ||dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19669
[Bug fortran/18714] Runtime hang in LAPACK routine SLAMC1 - in Quetzal benchmark suite
--- Additional Comments From coudert at clipper dot ens dot fr 2005-01-28 12:19 --- Did you try to compile this file without optimization (as is indicated in: http://www.netlib.org/lapack/faq.html#1.26)? The code in the ?lam*.f files is used to determine the machine precision (which could be done easily in Fortran 77), and any level of optimization other than -O0 usually causes infinite loops. -- What|Removed |Added CC||coudert at clipper dot ens ||dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18714
[Bug target/19663] LINK_GCC_C_SEQUENCE_SPEC doesn't play nice with RTEMS
--- Additional Comments From joel at oarcorp dot com 2005-01-28 12:24 --- Subject: Re: LINK_GCC_C_SEQUENCE_SPEC doesn't play nice with RTEMS ebotcazou at gcc dot gnu dot org wrote: --- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-01-28 08:16 --- IMO, sparc.h's LINK_GCC_C_SEQUENCE_SPEC probably is specific to solaris and not generally applicable. May-be, it's an historic artefact. As I already said, it is generally applicable and not specific to Solaris, in that it should be the default behaviour for a generic linker. And it is not an historic artifact either (it was added relatively recently, see the link I already pointed at). We agreed with you and the patch doesn't impact any target beside RTEMS. Our link rules are not those of Solaris. --joel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19663
[Bug c++/19664] -fvisibility-inlines-hidden fails with gcc's extern template extension on amd64
--- Additional Comments From lanius at gentoo dot org 2005-01-28 13:02 --- It may be related to this change in binutils: http://sources.redhat.com/ml/libc-alpha/2004-12/msg00062.html Changes from binutils 2.15.91.0.1: 2. Fix the x86_64 linker to prevent non-PIC code in shared library. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug c++/19664] -fvisibility-inlines-hidden fails with gcc's extern template extension on amd64
-- What|Removed |Added CC||lanius at gentoo dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug target/19663] LINK_GCC_C_SEQUENCE_SPEC doesn't play nice with RTEMS
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-01-28 13:08 --- We agreed with you and the patch doesn't impact any target beside RTEMS. Our link rules are not those of Solaris. OK. Note that the current default was originally added for Linux, not Solaris. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19663
[Bug c++/19664] -fvisibility-inlines-hidden fails with gcc's extern template extension on amd64
--- Additional Comments From pcarlini at suse dot de 2005-01-28 13:13 --- I think HJ may be interested... -- What|Removed |Added CC||hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug target/19663] LINK_GCC_C_SEQUENCE_SPEC doesn't play nice with RTEMS
--- Additional Comments From ralf dot corsepius at rtems dot org 2005-01-28 13:31 --- Then I don't understand, why it's exactly them which apply a similar work-around as RTEMS does: # grep LINK_GCC_C_SEQUENCE_SPEC *.h linux64.h:#undef LINK_GCC_C_SEQUENCE_SPEC linux64.h:#define LINK_GCC_C_SEQUENCE_SPEC \ linux.h:#undef LINK_GCC_C_SEQUENCE_SPEC linux.h:#define LINK_GCC_C_SEQUENCE_SPEC \ rtemself.h:#undef LINK_GCC_C_SEQUENCE_SPEC I.e. linux* and rtems are having this issue, while others don't seem to have this issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19663
[Bug c++/19664] -fvisibility-inlines-hidden fails with gcc's extern template extension on amd64
--- Additional Comments From simon dot strandman at telia dot com 2005-01-28 13:35 --- Thanks for the nice testcase. Is this really a GCC bug, or a binutils bug: http://bugs.gentoo.org/show_bug.cgi?id=79711 Downgrading binutils from 2.15.92.0.2 to 2.15.90.0.1.1 fixed the compilation for all KDE packages except kdepim. But kdepim failed with another probably not related error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug target/18977] [4.0 regression] LAPACK test xeigtsts segfaults with optimization
--- Additional Comments From Thomas dot Koenig at online dot de 2005-01-28 13:47 --- Created an attachment (id=8090) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8090action=view) Simpler example of failing C source code This is a simpler example of failing C code (which won't make peoples' eyes cross from looking at converted Fortran DO loops and array indices), and which also has its variables initialized. The error is the same: $ gcc -O1 sl4-error.c $ ./a.out Segmentation fault $ gcc -v ; gcc -dumpmachine Using built-in specs. Configured with: ../gcc-4.0-20050123/configure --prefix=/home/zfkts --enable-languages=c,f95 Thread model: posix gcc version 4.0.0 20050123 (experimental) ia64-unknown-linux-gnu -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18977
[Bug c++/19667] [4.0 Regression] ICE on (very trivial) invalid
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-28 13:53 --- : Search converges between 2004-11-25-014001-trunk (#656) and 2004-11-25-161001-trunk (#657). Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||ice-on-invalid-code Last reconfirmed|-00-00 00:00:00 |2005-01-28 13:53:53 date|| Summary|ICE on (very trivial) |[4.0 Regression] ICE on |invalid |(very trivial) invalid Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19667
[Bug c++/19662] [FEATURE REQUEST] Need an option preventing any atexit object destructions
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-28 14:00 --- So this is invalid, closing as such. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19662
[Bug c++/19666] [3.4 Regression] ICE in fold_convert
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-28 14:06 --- Started to be rejected (on the mainline at the time): : Search converges between 2003-07-23-trunk (#302) and 2003-07-24-trunk (#303). Started to ICE: : Search converges between 2004-02-02-3.4 (#1) and 2004-03-01-3.4 (#2). : Search converges between 2004-02-01-trunk (#445) and 2004-03-01-trunk (#446). Started to pass on the mainline: : Search converges between 2004-06-08-trunk (#463) and 2004-06-10-trunk (#464). -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||ice-on-valid-code, rejects- ||valid Last reconfirmed|-00-00 00:00:00 |2005-01-28 14:06:07 date|| Summary|ICE in fold_convert |[3.4 Regression] ICE in ||fold_convert Target Milestone|--- |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19666
[Bug c++/19666] [3.4 Regression] ICE in fold_convert
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-28 14:07 --- I think this patch fixes the problem but I don't have time to back port it: 2004-06-08 Andrew Pinski [EMAIL PROTECTED] * fold-const.c (fold_convert): Treat OFFSET_TYPE like POINTER_TYPE and INTEGER_TYPE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19666
[Bug target/16719] [ColdFire] Illegal move of byte itno address register causes compiler to ICE
--- Additional Comments From ralf dot corsepius at rtems dot org
2005-01-28 14:11 ---
The patch contained in
http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00405.html
doesn't seem to work for me, rsp. triggers another ICE, at least the error
message seems to have changed:
With today's gcc/cvs-trunk + your patch applied:
# m68k-rtems4.7-gcc -W -Wno-unused -Wshadow -m5206e -O3 -fomit-frame-pointer
-funroll-loops -S -o tmp.s /tmp/safer.c
/tmp/safer.c: In function 'safer_ecb_encrypt':
/tmp/safer.c:2494: error: unable to find a register to spill in class
'ADDR_REGS'
/tmp/safer.c:2494: error: this is the insn:
(insn 95 94 97 10 (set (reg:SI 8 %a0 [95])
(plus:SI (subreg:SI (mem/s/u:QI (plus:SI (reg/f:SI 13 %a5 [189])
(reg:SI 0 %d0 [91])) [0 safer_ebox S1 A8]) 0)
(subreg:SI (mem:QI (plus:SI (reg/v/f:SI 10 %a2 [orig:39 key.78 ]
[39])
(const_int 9 [0x9])) [0 S1 A8]) 0))) 96 {*addsi3_5200}
(insn_list:REG_DEP_TRUE 91 (nil))
(expr_list:REG_DEAD (reg:SI 0 %d0 [91])
(nil)))
/tmp/safer.c:2494: internal compiler error: in spill_failure, at reload1.c:1872
Also I am seeing a new ICE during building RTEMS, but I am not sure if this is
related to your patch.
--
What|Removed |Added
CC||joel at oarcorp dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16719
[Bug libfortran/19647] inquire(delim=) returns garbage
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-28 14:15 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-01/msg02117.html. -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19647
[Bug target/19664] -fvisibility-inlines-hidden fails with gcc's extern template extension on amd64
-- What|Removed |Added Component|c++ |target GCC build triplet|x86_64-pc-linux-gnu | GCC host triplet|x86_64-pc-linux-gnu | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug tree-optimization/19639] Funny (horrible) code for empty destructor
--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen dot de 2005-01-28 14:21 --- Folding x.foo[2] == x.foo to false does not help the testcase, as fold never sees this comparison. Instead the initial code the C++ frontend creates for ctor and dtor of arrays contains temporaries for these already. It seems the C++ frontend tries to be clever here, creating pointer IVs for the loop and doing too much manual optimizing. What other pass than fold() is supposed to handle this sort of simplification? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19639
[Bug tree-optimization/17640] empty loop not removed after optimization
--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen dot de 2005-01-28 14:26 --- One patch for empty-loop removal was posted here by Zdenek http://gcc.gnu.org/ml/gcc-patches/2004-07/msg01679.html -- What|Removed |Added CC||rguenth at tat dot physik ||dot uni-tuebingen dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17640
[Bug tree-optimization/15524] [4.0 Regression] jump threading on trees is slow with switch statements with large # of cases
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-28 14:27 --- The timings for 3.3.2 and 4.0.0 are the same are faster for 4.0.0 so closing as fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15524
[Bug target/18977] [4.0 regression] LAPACK test xeigtsts segfaults with optimization
--- Additional Comments From Thomas dot Koenig at online dot de 2005-01-28
14:29 ---
The inner loop does not terminate in this example,
until a segfault is hit.
$ cat sl5-error.c
#include stdio.h
void foo(float * x);
int main()
{
float x[4];
foo (x);
return 0;
}
void foo (float *x)
{
int i,j,k;
float temp;
static float t16[16]={1.,2.,3.,4.,5.,6.,7.,8.,9.,
10.,11.,12.,13.,14.,15.,16.};
static float tmp[4]={0.,0.,0.,0.};
for (i=0; i4; i++) {
k = 3 - i;
temp = t16[5*k];
for(j=k+1; j4; j++) {
printf(i=%d, j=%d, k=%d\n,i,j,k);
tmp[k] = t16[k+ j*4] * temp;
}
}
x[0] = tmp[0];
x[1] = tmp[1];
x[2] = tmp[2];
x[3] = tmp[3];
}
$ gcc sl5-error.c
$ ./a.out
i=1, j=3, k=2
i=2, j=2, k=1
i=2, j=3, k=1
i=3, j=1, k=0
i=3, j=2, k=0
i=3, j=3, k=0
$ gcc -O1 sl5-error.c
$ ./a.out
i=1, j=3, k=2
i=2, j=2, k=1
i=2, j=3, k=1
i=2, j=4, k=1
i=2, j=5, k=1
i=2, j=6, k=1
... and so on, until
i=2, j=803, k=1
i=2, j=804, k=1
i=2, j=805, k=1
i=2, j=806, k=1
i=2, j=807, k=1
i=2, j=808, k=1
Segmentation fault
$ gcc -v ; gcc -dumpmachine
Using built-in specs.
Configured with: ../gcc-4.0-20050123/configure --prefix=/home/zfkts
--enable-languages=c,f95
Thread model: posix
gcc version 4.0.0 20050123 (experimental)
ia64-unknown-linux-gnu
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18977
[Bug target/19670] New: [4.0 regression] mmix-knuth-mmixware testsuite failure: gcc.c-torture/execute/builtins/strlen-3.c compilation, -O1
With LAST_UPDATED: Fri Jan 28 05:05:32 UTC 2005 I get:
Running
/home/hp/combined/combined/gcc/testsuite/gcc.c-torture/execute/builtins/builtins.exp
...
FAIL: gcc.c-torture/execute/builtins/strlen-3.c compilation, -O1
With the message in the gcc.log being:
Executing on host: /home/hp/combined/mmixware-sim/gcc/xgcc
-B/home/hp/combined/mmixware-sim/gcc/ /home/hp/combined/combined/gcc/t\
estsuite/gcc.c-torture/execute/builtins/strlen-3.c
/home/hp/combined/combined/gcc/testsuite/gcc.c-torture/execute/builtins/strlen\
-3-lib.c
/home/hp/combined/combined/gcc/testsuite/gcc.c-torture/execute/builtins/lib/main.c
gcc_tg.o -w -O1 -isystem /home/hp\
/combined/mmixware-sim/mmix-knuth-mmixware/./newlib/targ-include -isystem
/home/hp/combined/combined/newlib/libc/include -L/home/\
hp/combined/mmixware-sim/ld
-B/home/hp/combined/mmixware-sim/mmix-knuth-mmixware/./newlib/
-L/home/hp/combined/mmixware-sim/mmix-\
knuth-mmixware/./newlib -Wl,--defsym,__Stack_start=0x1680a000
-Wl,-wrap,exit -Wl,-wrap,_exit -Wl,-wrap,main -Wl,-wrap,ab\
ort -lm -o /home/hp/combined/mmixware-sim/gcc/testsuite/strlen-3.x1
(timeout = 300)
/home/hp/combined/combined/gcc/testsuite/gcc.c-torture/execute/builtins/strlen-3.c:
In function 'main_test':^M
/home/hp/combined/combined/gcc/testsuite/gcc.c-torture/execute/builtins/strlen-3.c:20:
error: Pointers with a memory tag, should \
have points-to sets or point to malloc^M
foo_28, name memory tag: NMT::4, points-to vars: { }^M
foo, UID 8, const char *^M
/home/hp/combined/combined/gcc/testsuite/gcc.c-torture/execute/builtins/strlen-3.c:20:
internal compiler error: verify_flow_sensi\
tive_alias_info failed.^M
Last known to work on: Thu Jan 27 12:35:41 UTC 2005.
--
Summary: [4.0 regression] mmix-knuth-mmixware testsuite failure:
gcc.c-torture/execute/builtins/strlen-3.c compilation,
-O1
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hp at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: mmix-knuth-mmixware
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19670
[Bug fortran/19669] [gfortran] ICE (segfault) on legal (?) code
--- Additional Comments From martin at mpa-garching dot mpg dot de 2005-01-28 14:41 --- OK, I managed to reduce the testcase (phew!). Here it is: module ModelData implicit none Type ClTransferData integer :: NumSources end Type ClTransferData Type(ClTransferData) :: CTransScal end module ModelData module GaugeInterface implicit none contains subroutine output(sources) use ModelData real sources(CTransScal%NumSources) end subroutine output end module GaugeInterface module CAMBmain use GaugeInterface end module CAMBmain ~/tmprm *.mod ; gfortran -c bug.F90 bug.F90:16: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19669
[Bug tree-optimization/19670] [4.0 regression] mmix-knuth-mmixware testsuite failure: gcc.c-torture/execute/builtins/strlen-3.c compilation, -O1
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-28 14:42 --- Confirmed, happens every where. -- What|Removed |Added Status|UNCONFIRMED |NEW Component|target |tree-optimization Ever Confirmed||1 GCC host triplet|i686-pc-linux-gnu | GCC target triplet|mmix-knuth-mmixware | Last reconfirmed|-00-00 00:00:00 |2005-01-28 14:42:13 date|| Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19670
[Bug fortran/19669] [gfortran] ICE (segfault) on legal (?) code
--- Additional Comments From martin at mpa-garching dot mpg dot de 2005-01-28 14:43 --- (From update of attachment 8089) a reduced testcase can be found in the comments -- What|Removed |Added Attachment #8089 is|0 |1 obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19669
[Bug rtl-optimization/8361] [3.3/3.4/4.0 regression] C++ compile-time performance regression
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-28 14:48 --- Can someone do the timings again on x86, I think we are faster at -O1 now than previous versions and faster for all other optimization levels? On ppc-darwin we speed up about 3% (-O2/-O3) to 16% (-O1) between the 15th and now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8361
[Bug target/19671] New: [4.0 regression] mmix-knuth-mmixware testsuite failure: gcc.dg/tree-ssa/20030711-2.c scan-tree-dump-times rtmem 1
With LAST_UPDATED: Fri Jan 28 05:05:32 UTC 2005 I get: Running /home/hp/combined/combined/gcc/testsuite/gcc.dg/tree-ssa/tree-ssa.exp ... FAIL: gcc.dg/tree-ssa/20030711-2.c scan-tree-dump-times rtmem 1 With the message in the .log being: Executing on host: /home/hp/combined/mmixware-sim/gcc/xgcc -B/home/hp/combined/mmixware-sim/gcc/ /home/hp/combined/combined/gcc/t\ estsuite/gcc.dg/tree-ssa/20030711-2.c -O1 -fdump-tree-dom3 -S -isystem /home/hp/combined/mmixware-sim/mmix-knuth-mmixware/./ne\ wlib/targ-include -isystem /home/hp/combined/combined/newlib/libc/include -o 20030711-2.s(timeout = 300) PASS: gcc.dg/tree-ssa/20030711-2.c (test for excess errors) PASS: gcc.dg/tree-ssa/20030711-2.c scan-tree-dump-not make_decl_rtl \(\) PASS: gcc.dg/tree-ssa/20030711-2.c scan-tree-dump-times if 3 PASS: gcc.dg/tree-ssa/20030711-2.c scan-tree-dump-times decl\.rtl 1 PASS: gcc.dg/tree-ssa/20030711-2.c scan-tree-dump-times code 1 FAIL: gcc.dg/tree-ssa/20030711-2.c scan-tree-dump-times rtmem 1 PASS: gcc.dg/tree-ssa/20030711-2.c scan-tree-dump-times -alias 1 Last known to work on: Thu Jan 27 12:35:41 UTC 2005. -- Summary: [4.0 regression] mmix-knuth-mmixware testsuite failure: gcc.dg/tree-ssa/20030711-2.c scan-tree-dump-times rtmem 1 Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hp at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: i686-pc-linux-gnu GCC target triplet: mmix-knuth-mmixware http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19671
[Bug libstdc++/19567] dynamic_cast failure in dlopen-ed shared object
--- Additional Comments From chris at bubblescope dot net 2005-01-28 14:53 --- I don't think this bug has anything to do with libstdc++ (which over covers errors in the c++ standard library). I would suggest changing the Component to c++, which I suspect a closer match for where the bug lives (although I'm not certain I will admit). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19567
[Bug tree-optimization/19671] [4.0 regression] mmix-knuth-mmixware testsuite failure: gcc.dg/tree-ssa/20030711-2.c scan-tree-dump-times rtmem 1
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-28 14:59 --- Already fixed by: 2005-01-26 Steven Bosscher [EMAIL PROTECTED] * gcc.dg/tree-ssa/20030711-2.c: Run at -O2, not -O1. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|target |tree-optimization Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19671
[Bug fortran/19669] [gfortran] ICE (segfault) on legal (?) code
--- Additional Comments From coudert at clipper dot ens dot fr 2005-01-28 14:59 --- I think this is a duplicate of PR16861 (probably the most annoying bug on scientific codes these days, since they do use modules a lot). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19669
[Bug fortran/19669] [gfortran] ICE (segfault) on legal (?) code
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-28 15:02 --- (In reply to comment #5) I think this is a duplicate of PR16861 (probably the most annoying bug on scientific codes these days, since they do use modules a lot). This is not a duplicate of PR16861. Here is the backtrace: #0 mio_ref (rp=0x416049e0) at /Users/pinskia/src/local3/gcc/gcc/fortran/module.c:1810 #1 0x0002fb9c in mio_expr (ep=0x41601b14) at /Users/pinskia/src/local3/gcc/gcc/fortran/ module.c:2201 #2 0x000301b8 in mio_array_spec (asp=0x416049a8) at /Users/pinskia/src/local3/gcc/gcc/fortran/ module.c:1693 #3 0x00030b20 in mio_symbol (sym=0x41604890) at /Users/pinskia/src/local3/gcc/gcc/fortran/ module.c:2685 #4 0x00031088 in load_needed (p=0x48d7c4) at /Users/pinskia/src/local3/gcc/gcc/fortran/ module.c:2892 #5 0x00031004 in load_needed (p=0x48d7c4) at /Users/pinskia/src/local3/gcc/gcc/fortran/ module.c:2858 #6 0x00031004 in load_needed (p=0x48d7c4) at /Users/pinskia/src/local3/gcc/gcc/fortran/ module.c:2858 #7 0x0003102c in load_needed (p=0x48d7c4) at /Users/pinskia/src/local3/gcc/gcc/fortran/ module.c:2860 #8 0x00031538 in gfc_use_module () at /Users/pinskia/src/local3/gcc/gcc/fortran/module.c:3099 #9 0x00033e78 in accept_statement (st=1115684864) at /Users/pinskia/src/local3/gcc/gcc/fortran/ parse.c:1014 #10 0x0003444c in parse_spec (st=ST_USE) at /Users/pinskia/src/local3/gcc/gcc/fortran/parse.c:1581 #11 0x00035eec in gfc_parse_file () at /Users/pinskia/src/local3/gcc/gcc/fortran/parse.c:2454 #12 0x0004c444 in gfc_be_parse_file (set_yydebug=1115684864) at /Users/pinskia/src/local3/gcc/ gcc/fortran/f95-lang.c:265 -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-01-28 15:02:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19669
[Bug libstdc++/19567] dynamic_cast failure in dlopen-ed shared object
--- Additional Comments From daveregs at rsaisp dot com 2005-01-28 15:10 --- Hi Chris, I beleive that this problem may be related to the typeinfo header or other related headers that are involved with RTTI. I have also refered to an older bug that involved this same problem which was posted under libstdc++ and appeared to have been resolved in this category: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4292 However, I could be wrong, so if you are positive I have this in the wrong category I will move it. Thank you, - Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19567
[Bug rtl-optimization/8361] [3.3/3.4/4.0 regression] C++ compile-time performance regression
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-28 15:15 --- I will do timings with a bunch of gcc3.x compilers and gcc4.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8361
[Bug tree-optimization/19671] [4.0 regression] mmix-knuth-mmixware testsuite failure: gcc.dg/tree-ssa/20030711-2.c scan-tree-dump-times rtmem 1
--- Additional Comments From hp at gcc dot gnu dot org 2005-01-28 15:15 --- The date is wrong in ChangeLog entry quoted in comment #1 (just checked). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19671
[Bug target/19663] LINK_GCC_C_SEQUENCE_SPEC doesn't play nice with RTEMS
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-01-28 15:17 --- Then I don't understand, why it's exactly them which apply a similar work-around as RTEMS does: # grep LINK_GCC_C_SEQUENCE_SPEC *.h linux64.h:#undef LINK_GCC_C_SEQUENCE_SPEC linux64.h:#define LINK_GCC_C_SEQUENCE_SPEC \ linux.h:#undef LINK_GCC_C_SEQUENCE_SPEC linux.h:#define LINK_GCC_C_SEQUENCE_SPEC \ rtemself.h:#undef LINK_GCC_C_SEQUENCE_SPEC I.e. linux* and rtems are having this issue, while others don't seem to have this issue. Because the others don't use (a recent) GNU libc according to: http://gcc.gnu.org/ml/gcc-patches/2003-09/msg00799.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19663
[Bug tree-optimization/17640] empty loop not removed after optimization
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-28 15:18 --- That patch is just gross. Come on, builtin_maybe_infinite_loop?! There are better and easier ways to kill dead loops. Like, a loop optimizer that simply removes dead loops ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17640
[Bug tree-optimization/19671] [4.0 regression] mmix-knuth-mmixware testsuite failure: gcc.dg/tree-ssa/20030711-2.c scan-tree-dump-times rtmem 1
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-28 15:23 --- I fixed the date. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19671
[Bug middle-end/19402] __builtin_powi? still missing
--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen dot de 2005-01-28 15:29 --- Looking into it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19402
[Bug tree-optimization/19670] [4.0 regression] testsuite failure: gcc.c-torture/execute/builtins/strlen-3.c compilation, -O1
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dnovillo at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19670
[Bug tree-optimization/14741] missing transformations lead to poorly optimized code
--- Additional Comments From jv244 at cam dot ac dot uk 2005-01-28 15:59 --- Hi Steven, I now ( gcc version 4.0.0 20050128 (experimental) )get the following, where the first number is the timing. multgen/basic_mult gfortran -O3 -ffast-math mult.f90 multgen/basic_mult ./a.out 59.0300010.24000 which is good as compared to multgen/basic_mult ifort -O3 mult.f90 multgen/basic_mult ./a.out 64.8900010.23998 but very bad (factor 20) as compared to multgen/basic_mult ifort -O3 -xN mult.f90 mult.f90(4) : (col. 0) remark: LOOP WAS VECTORIZED. mult.f90(5) : (col. 0) remark: LOOP WAS VECTORIZED. mult.f90(6) : (col. 0) remark: LOOP WAS VECTORIZED. multgen/basic_mult ./a.out 2.1310.23998 I'll try to attach the relevant asm for this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14741
[Bug regression/19672] New: Performance regression in simple loop code
In the following C source file test.c,
int compare(char const * p1, int n1, char const * p2, int n2) {
char const * q1 = p1 + n1;
char const * q2 = p2 + n2;
while (p1 q1 p2 q2) {
int n = *--q1 - *--q2;
if (n) {
return n;
}
}
return n1 - n2;
}
int main(void) {
char str[1000];
int i;
for (i = 0; i 100; ++i) {
compare(str, 1000, str, 1000);
}
}
compiled with
gcc -O2 test.c
the loop body within compare takes 14 instructions on GCC 3.4.3 Linux x86,
compared to only 11 instructions on GCC 3.2.2 Linux x86 (see disassemblies
below), and the GCC 3.4.3 output takes substantially longer to run than the GCC
3.2.2 output:
3.4.3 time ./a.out
4.690u 0.001s 0:04.71 99.5%
3.2.2 time ./a.out
3.533u 0.002s 0:03.55 99.4%
This seems to bite us on OpenOffice.org, which contains an oft-called function
similar to compare above, and new versions of OOo (built with GCC 3.4) run
slower than old versions (built with GCC 3.2). The question that remains for us
is whether this performance loss is specific to the given function, or could be
a general problem.
The dissasemblies:
08048360 compare: ! gcc 3.4.3
8048360: 55 push %ebp
8048361: 89 e5 mov%esp,%ebp
8048363: 57 push %edi
8048364: 56 push %esi
8048365: 53 push %ebx
8048366: 8b 45 0cmov0xc(%ebp),%eax
8048369: 8b 7d 08mov0x8(%ebp),%edi
804836c: 8b 75 10mov0x10(%ebp),%esi
804836f: 8d 1c 07lea(%edi,%eax,1),%ebx
8048372: 8b 45 14mov0x14(%ebp),%eax
8048375: 8d 0c 06lea(%esi,%eax,1),%ecx
8048378: 90 nop
8048379: 8d b4 26 00 00 00 00lea0x0(%esi),%esi
8048380: 39 df cmp%ebx,%edi ! -+
8048382: 0f 92 c0setb %al! |
8048385: 31 d2 xor%edx,%edx ! |
8048387: 39 ce cmp%ecx,%esi ! |
8048389: 0f 92 c2setb %dl! |
804838c: 85 d0 test %edx,%eax ! |
804838e: 74 13 je 80483a3! |
8048390: 4b dec%ebx ! |
8048391: 49 dec%ecx ! |
8048392: 0f be 01movsbl (%ecx),%eax! |
8048395: 0f be 13movsbl (%ebx),%edx! |
8048398: 29 c2 sub%eax,%edx ! |
804839a: 89 d0 mov%edx,%eax ! |
804839c: 74 e2 je 8048380! --+
804839e: 5b pop%ebx
804839f: 5e pop%esi
80483a0: 5f pop%edi
80483a1: 5d pop%ebp
80483a2: c3 ret
80483a3: 5b pop%ebx
80483a4: 8b 45 0cmov0xc(%ebp),%eax
80483a7: 8b 55 14mov0x14(%ebp),%edx
80483aa: 5e pop%esi
80483ab: 29 d0 sub%edx,%eax
80483ad: 5f pop%edi
80483ae: 5d pop%ebp
80483af: c3 ret
08048370 compare: ! gcc 3.2.2
8048370: 55 push %ebp
8048371: 89 e5 mov%esp,%ebp
8048373: 57 push %edi
8048374: 8b 45 0cmov0xc(%ebp),%eax
8048377: 56 push %esi
8048378: 8b 7d 08mov0x8(%ebp),%edi
804837b: 53 push %ebx
804837c: 8b 75 10mov0x10(%ebp),%esi
804837f: 8d 1c 38lea(%eax,%edi,1),%ebx
8048382: 8b 45 14mov0x14(%ebp),%eax
8048385: 39 df cmp%ebx,%edi
8048387: 8d 0c 30lea(%eax,%esi,1),%ecx
804838a: 73 1a jae80483a6
804838c: 39 ce cmp%ecx,%esi
804838e: 73 16 jae80483a6
8048390: 4b dec%ebx ! -+
8048391: 49 dec%ecx ! |
8048392: 0f be 01movsbl (%ecx),%eax! |
8048395: 0f be 13movsbl (%ebx),%edx! |
8048398: 29 c2 sub%eax,%edx ! |
804839a: 89 d0 mov%edx,%eax ! |
804839c: 75 10 jne80483ae! |
804839e: 39 df cmp%ebx,%edi ! |
80483a0: 73 04 jae80483a6! |
80483a2: 39 ce cmp%ecx,%esi ! |
80483a4: 72 ea jb 8048390! --+
80483a6: 8b 45 0cmov0xc(%ebp),%eax
80483a9: 8b 55 14mov0x14(%ebp),%edx
80483ac: 29 d0 sub%edx,%eax
80483ae: 5b pop%ebx
80483af: 5e
[Bug tree-optimization/14741] missing transformations lead to poorly optimized code
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-28 16:23 --- The -xN you add make ifort specialize the code for Pentium 4. So far, nobody has cared to make GCC produce good code for the good old Pentium 4 so I would not be terribly surprised if we lose a lot just on the normal code generation. Add to that the fact that -xN enables a lot of extra optimizations in ifort that gcc does not have yet (vectorization is one example in your case), it is not a surprise at all that we are that much slower. I don't know if the mainline vectorizer is already smart enough to handle the loop in your code. Probably it is not. You could try gfortran -O3 -mtune=pentium4 -ffast-math -mfpmath=sse -ftree-loop-linear -ftree-vectorize yourcode.f90 and see if it helps. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14741
[Bug tree-optimization/14741] missing transformations lead to poorly optimized code
--- Additional Comments From jv244 at cam dot ac dot uk 2005-01-28 16:31 --- You could try gfortran -O3 -mtune=pentium4 -ffast-math -mfpmath=sse -ftree-loop-linear -ftree-vectorize yourcode.f90 and see if it helps. Unhappily, seems to make things slower: multgen/basic_mult gfortran -O3 -mtune=pentium4 -ffast-math -mfpmath=sse -ftree-loop-linear -ftree-vectorize mult.f90 mult.f90:0: warning: SSE instruction set disabled, using 387 arithmetics multgen/basic_mult ./a.out 60.3900010.24000 whereas removing some of these flags helps a little multgen/basic_mult gfortran -O3 -mtune=pentium4 -ffast-math mult.f90 multgen/basic_mult ./a.out 56.4700010.24000 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14741
[Bug tree-optimization/19643] 0 % variable isn't optimized to 0 at tree level
--- Additional Comments From law at redhat dot com 2005-01-28 16:36 --- Should be fixed with today's change to fold-const.c. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19643
[Bug fortran/19673] New: pointer function with RESULT specified returns pointer to ptr rather than *ptr
This is a bug that is specific to functions where RESULT is specified in the function statement(function foo). In this case, the pointer itself is printed. Where RESULT is not specified, functions return a pointer result correctly(function bar). Here the value pointed too is printed. $ cat return_pointer.f90 ! Test the return of pointer program ret_ptr print *, foo (99) , from function foo (arg) result (ptr) print *, bar (99) , from function bar (arg) contains function foo (arg) result(ptr) integer :: arg integer, pointer :: ptr allocate (ptr) ptr = arg end function foo function bar (arg) integer :: arg integer, pointer :: bar allocate (bar) bar = arg end function bar end program ret_ptr $ ./a 168034328 from function foo (arg) result (ptr) 99 from function bar (arg) -- Summary: pointer function with RESULT specified returns pointer to ptr rather than *ptr Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: paulthomas2 at wanadoo dot fr CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19673
[Bug c++/19661] unnecessary atexit calls emitted for static objects with empty destructors
--- Additional Comments From bangerth at dealii dot org 2005-01-28 17:01 --- atexit only takes a pointer to a function to be run on exit of the program. The fact that this is an empty function is unbeknownst to it, and probably the code in the middle-end that has to deal with that. I therefore believe that the front-end has to take care of the fact that we have may run an empty function; it would also logically make sense to guard the call to atexit with a check whether the destructor is empty or not. I'll move this bug back to the C++ component. W. -- What|Removed |Added Component|middle-end |c++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19661
[Bug fortran/18714] Runtime hang in LAPACK routine SLAMC1 - in Quetzal benchmark suite
--- Additional Comments From prthomas at drfccad dot cea dot fr 2005-01-28 17:02 --- Subject: RE: Runtime hang in LAPACK routine SLAMC1 - i n Quetzal benchmark suite Bon soir François-Xavier, Tu as raison! Même -O1 fait coincer le programme. Je suis étonné quand-même que le fix est d'injecter d'un PRINT *, n'importe quoi et, aussi, qu'il est légèrement impossible isoler le bogue. Tu as des explications là-dessous? Je vais afficher une réponse sur Bugzilla, avant de sortir. Paul -Message d'origine- De : coudert at clipper dot ens dot fr [mailto:[EMAIL PROTECTED] Envoyé : vendredi 28 janvier 2005 13:20 À : [EMAIL PROTECTED] Objet : [Bug fortran/18714] Runtime hang in LAPACK routine SLAMC1 - in Quetzal benchmark suite --- Additional Comments From coudert at clipper dot ens dot fr 2005-01-28 12:19 --- Did you try to compile this file without optimization (as is indicated in: http://www.netlib.org/lapack/faq.html#1.26)? The code in the ?lam*.f files is used to determine the machine precision (which could be done easily in Fortran 77), and any level of optimization other than -O0 usually causes infinite loops. -- What|Removed |Added CC||coudert at clipper dot ens ||dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18714 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18714
[Bug fortran/18714] Runtime hang in LAPACK routine SLAMC1 - in Quetzal benchmark suite
--- Additional Comments From paulthomas2 at wanadoo dot fr 2005-01-28 17:08 --- Francois-Xavier Coudert's comment is spot on. Reducing the optimisation to -O0 removes the need for this peculiar fix. We could do with a repository for funnies that are not quite bugs. I SAY REMOVE THIS ONE. I am still left bemused, as I accidently posted in french, by the fact that a print statement releases the programme for any optimisation level and that when the section of code is isolated it runs perfectly. Does anybody have an explanation? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18714
[Bug fortran/18714] Runtime hang in LAPACK routine SLAMC1 - in Quetzal benchmark suite
--- Additional Comments From coudert at clipper dot ens dot fr 2005-01-28 17:20 --- (reply to comments #3 and #4) The print statement in the code induces I/O, which in some sense disrupt the flow of code and has the effect of making unaware of possible optimizations. I can't offer a deeper explanation than this statement, only dictated by experience and not actual knowledge of the in-depths of compilers. Removed the wrong-code keyword and the blocking of PR18714, since this is actually not a bug. -- What|Removed |Added OtherBugsDependingO|19292 | nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18714
Re: [Bug tree-optimization/14741] missing transformations lead to poorly optimized code
On Fri, 28 Jan 2005, jv244 at cam dot ac dot uk wrote: --- Additional Comments From jv244 at cam dot ac dot uk 2005-01-28 16:31 --- You could try gfortran -O3 -mtune=pentium4 -ffast-math -mfpmath=sse -ftree-loop-linear -ftree-vectorize yourcode.f90 and see if it helps. Unhappily, seems to make things slower: multgen/basic_mult gfortran -O3 -mtune=pentium4 -ffast-math -mfpmath=sse -ftree-loop-linear -ftree-vectorize mult.f90 mult.f90:0: warning: SSE instruction set disabled, using 387 arithmetics You'd need -msse2 or -msse (or is it -march=pentium4 that enables these?)
[Bug tree-optimization/14741] missing transformations lead to poorly optimized code
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-01-28 17:22 --- Subject: Re: missing transformations lead to poorly optimized code On Fri, 28 Jan 2005, jv244 at cam dot ac dot uk wrote: --- Additional Comments From jv244 at cam dot ac dot uk 2005-01-28 16:31 --- You could try gfortran -O3 -mtune=pentium4 -ffast-math -mfpmath=sse -ftree-loop-linear -ftree-vectorize yourcode.f90 and see if it helps. Unhappily, seems to make things slower: multgen/basic_mult gfortran -O3 -mtune=pentium4 -ffast-math -mfpmath=sse -ftree-loop-linear -ftree-vectorize mult.f90 mult.f90:0: warning: SSE instruction set disabled, using 387 arithmetics You'd need -msse2 or -msse (or is it -march=pentium4 that enables these?) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14741
[Bug middle-end/19583] [4.0 Regression] Incorrect diagnostic: control may reach end of non-void function '...' being inlined
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-28 17:33 --- Subject: Bug 19583 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-28 17:32:58 Modified files: gcc: ChangeLog gimple-low.c Log message: PR middle-end/16558 PR middle-end/19583 * gimple-low.c (block_may_fallthru): TRY_FINALLY_EXPR only falls through if both operands fall through. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.7319r2=2.7320 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/gimple-low.c.diff?cvsroot=gccr1=2.20r2=2.21 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19583
[Bug middle-end/16558] [4.0 Regression]: bogus missing-return warning
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-28 17:33 --- Subject: Bug 16558 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-28 17:32:58 Modified files: gcc: ChangeLog gimple-low.c Log message: PR middle-end/16558 PR middle-end/19583 * gimple-low.c (block_may_fallthru): TRY_FINALLY_EXPR only falls through if both operands fall through. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.7319r2=2.7320 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/gimple-low.c.diff?cvsroot=gccr1=2.20r2=2.21 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16558
[Bug middle-end/16558] [4.0 Regression]: bogus missing-return warning
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-28 17:34 --- Subject: Bug 16558 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-28 17:33:54 Modified files: gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/warn: Wreturn-type-2.C Log message: PR middle-end/16558 * g++.dg/warn/Wreturn-type-2.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.4950r2=1.4951 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/warn/Wreturn-type-2.C.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16558
[Bug libgcj/19649] java.util.Date.getTimezoneOffset returns negated output
--- Additional Comments From marco at gnome dot org 2005-01-28 17:35 --- Colin, is this one the cause of the setTimeStamp/getTimeStamp mismatch with postgre jdbc? I have a testcase for that one in case it's of any use... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19649
[Bug middle-end/16558] [4.0 Regression]: bogus missing-return warning
--- Additional Comments From ian at airs dot com 2005-01-28 17:35 --- Fixed in mainline. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16558
[Bug target/16201] Assembler messages:Error: bad immediate value for offset (4116)
-- What|Removed |Added Attachment #6629|text/plain |application/x-zip mime type|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16201
[Bug java/19674] New: Empty declaration through semicolon (;) causes compile failure
The following program doesn't compile:
public interface OutSideInterface
{
public interface InsideInterface
{
void m(int p, int p2);
};
}
Note the empty statement (semicolon) on line 6.
This is legal (jikes accepts it) but deprecated.
Compiling with -C gives:
OutSideInterface.java:6: error: '{' expected.
};
^
OutSideInterface.java:7: error: Class or interface declaration expected.
}
^
2 errors
Reported by Jerry Haltom.
With -Wextraneous-semicolon the compiler does see that this is just an
declaration:
OutSideInterface.java:6: warning: An empty declaration is a deprecated feature
that should not be used.
--
Summary: Empty declaration through semicolon (;) causes compile
failure
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mark at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19674
[Bug java/19674] Empty declaration through semicolon (;) causes compile failure
--- Additional Comments From dog at bluezoo dot org 2005-01-28 18:19 --- The relevant JLS production is ClassMemberDeclaration: http://java.sun.com/docs/books/jls/second_edition/html/classes.doc.html#18988 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19674
[Bug c++/19675] New: wrong double comparison result if taken from function result.
Hi,
The small example below gives an incorrect result on 32 bit platforms. Both
tests should lead to the same result, but one is false, the other is true.
tested with the following compilers, all of them exhibiting the bug:
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
gcc version 2.96 2731 (Red Hat Linux 7.1 2.96-98)
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.3/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--host=i386-redhat-linux
Thread model: posix
gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-34)
Reading specs from /usr/lib/gcc-lib/x86_64-redhat-linux/3.2.3/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--host=x86_64-redhat-linux
Thread model: posix
gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-42)
Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.3.1/specs
Configured with: ../configure --prefix=/usr --libdir=/usr/lib
--with-slibdir=/lib --mandir=/usr/share/man --infodir=/usr/share/info
--enable-shared --enable-threads=posix --disable-checking --enable-long-long
--enable-__cxa_atexit --enable-languages=c,c++,ada,f77,objc,java,pascal
--host=i586-mandrake-linux-gnu --with-system-zlib
Thread model: posix
gcc version 3.3.1 (Mandrake Linux 9.2 3.3.1-2mdk)
Reading specs from /usr/lib/gcc/x86_64-redhat-linux/3.4.2/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-languages=c,c++,objc,java,f77
--enable-java-awt=gtk --host=x86_64-redhat-linux
Thread model: posix
gcc version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)
Compilation command, on 32 bits systems:
gcc -o testgcc testgcc.cpp -lstdc++
Compilation command, on 64 bits systems:
gcc -m32 -o testgcc testgcc.cpp -lstdc++
NOTE: on 64 bits systems, 64bit executable run as expected.
Regards,
Richard.
--testgcc.cpp---
#include iostream
using std::cerr ;
class BugMe {
public:
BugMe( double start, double step ) ;
double value( int i ) const ;
bool bugme( const BugMe* other ) ;
private:
double start_ ;
double step_ ;
} ;
BugMe::BugMe(double start, double step) : start_(start), step_(step) {
}
double BugMe::value(int i) const {
return start_ + i*step_ ;
}
bool BugMe::bugme( const BugMe* other ) {
bool b1 = (value(44) == other-value(44)) ;
double v1 = value(44) ;
double v2 = other-value(44) ;
bool b2 = (v1==v2) ;
return b1 != b2 ;
}
main() {
BugMe* b1 = new BugMe(123, 2345.54) ;
BugMe* b2 = new BugMe(123, 2345.54) ;
if( b1-bugme(b2) ) {
cerr BUG!\n ;
}
}
--testgcc.cpp---
--
Summary: wrong double comparison result if taken from function
result.
Product: gcc
Version: 3.4.2
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: cognot at earthdecision dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19675
[Bug c++/19675] wrong double comparison result if taken from function result.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-28 18:47 --- This is a dup of bug 323. The problem is excessive precission. *** This bug has been marked as a duplicate of 323 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19675
[Bug rtl-optimization/323] optimized code gives strange floating point results
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-28 18:47 --- *** Bug 19675 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||cognot at earthdecision dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
[Bug rtl-optimization/13931] [3.3/3.4/4.0 Regression] combiner much slower on big basic blocks
--- Additional Comments From ian at airs dot com 2005-01-28 18:49 --- We aren't waiting for anything, so move out of WAITING state. -- What|Removed |Added CC||ian at airs dot com Status|WAITING |NEW Last reconfirmed|2005-01-15 12:25:26 |2005-01-28 18:49:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13931
[Bug middle-end/19661] unnecessary atexit calls emitted for static objects with empty destructors
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-28
18:53 ---
(In reply to comment #5)
I'll move this bug back to the C++ component.
Consider the following C++ code:
struct Foo { ~Foo() {} int i; };
struct A { Foo foo[2]; };
void foo () {
static A a;
}
We don't know the deconstructor for A is empty until we remove the empry loop
and do optimizations
on it. So this is again a job for the midde-end/tree-optimizations. We can
then mark the function as
empty and then have a pass (or really fold or something like that) remove calls
to atexit (and similar
functions) which just references empty functions. This is the correct way of
doing this.
--
What|Removed |Added
Component|c++ |middle-end
GCC build triplet|n/a |
GCC target triplet|n/a |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19661
[Bug c++/19675] wrong double comparison result if taken from function result.
--- Additional Comments From cognot at earthdecision dot com 2005-01-28 18:54 --- (In reply to comment #1) This is a dup of bug 323. The problem is excessive precission. *** This bug has been marked as a duplicate of 323 *** Hi, Looking at the thread for bug #323 it would seem to happen only if optimization is turned on. in my case the bug is there even with -g2 -O0 -ffloat-store added to the compile line. Regards, Richard. -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19675
[Bug target/19675] wrong double comparison result if taken from function result.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-28 18:59 --- Only happens on x86. -- What|Removed |Added Severity|critical|minor Component|c++ |target GCC target triplet||i?86-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19675
[Bug regression/19672] [3.4/4.0? Regression] Performance regression in simple loop code
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-28 19:03 --- I cannot test this right now but this might be fixed on the mainline. -- What|Removed |Added Keywords||missed-optimization Summary|Performance regression in |[3.4/4.0? Regression] |simple loop code|Performance regression in ||simple loop code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19672
[Bug java/19674] Empty declaration through semicolon (;) causes compile failure
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-28 19:04 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||diagnostic, rejects-valid Last reconfirmed|-00-00 00:00:00 |2005-01-28 19:04:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19674
[Bug target/19675] wrong double comparison result if taken from function result.
--- Additional Comments From cognot at earthdecision dot com 2005-01-28 19:04 --- (In reply to comment #3) Only happens on x86. True. But only with gcc. Under Windows M$ .NET and DevStudio 6 give a correct result if Improve float consitency is turned on. Haven't tried with the Intel compiler yet. Will do from home. Regards, Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19675
[Bug target/19675] wrong double comparison result if taken from function result.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-28 19:07 --- Really comparing two floating point with equallity is not a good thing to do. This again is a dup of bug 323. *** This bug has been marked as a duplicate of 323 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19675
[Bug rtl-optimization/323] optimized code gives strange floating point results
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-28 19:07 --- *** Bug 19675 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
[Bug c/19676] New: Loop optimizer fails to reverse simple loop
AVR Target 20041205 snapshot
gcc version 4.0.0 20041205 (experimental)
/avrdev/libexec/gcc/avr/4.0.0/cc1.exe -quiet -v looprv.c -quiet -dumpbase
looprv.c -mmcu=atmega169 -auxbase looprv -Os -Wall -version -funsigned-char
-funsigned-bitfields -fpack-struct -fshort-enums -o looprv.s
Loop optimiser fails to reverse simple loop. Example
void testloop5(void)
{
int i;
for (i=0;i100;i++)
{
if (!value)
{
foo();
}
}
}
generates RTL setting index to 100 then using decrement/branch at end of loop as
expected. However, adding any kind of while/for loop inside outer loop leaves
index unoptimised. For example
void testloop3(void)
{
int i;
for (i=0;i100;i++)
{
while (!value)
{
foo();
}
}
}
Here index starts at 0 and increments to 99.
Problem seems to be related to maybe_multiple being set in loop scan. However,
since 'i' is never used inside loop there would seem to be no need to check for
multiple setting.
This was tested with AVR target but looks like it will affect any target - I can
provide RTL etc on demand.
--
Summary: Loop optimizer fails to reverse simple loop
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andrewhutchinson at cox dot net
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19676
[Bug middle-end/19661] unnecessary atexit calls emitted for static objects with empty destructors
--- Additional Comments From bangerth at dealii dot org 2005-01-28 19:11 --- Why do you think the front-end doesn't know that the destructor is empty? It sees its definition, and it knows about potential destructors of member objects and base classes, so it should have all the information. That being said, I don't consider this to be such an important case as to pour a lot of passion into this discussion :-) W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19661
[Bug c/19676] Loop optimizer fails to reverse simple loop
--- Additional Comments From andrewhutchinson at cox dot net 2005-01-28 19:12 --- Created an attachment (id=8092) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8092action=view) Testcase c source Testloop3() is NOT reversed. Others for reference are. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19676
[Bug c/19676] Loop optimizer fails to reverse simple loop
--- Additional Comments From andrewhutchinson at cox dot net 2005-01-28 19:13 --- Created an attachment (id=8093) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8093action=view) Expanded RTL Expanded RTL from looprv testcase source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19676
[Bug target/19676] Loop optimizer fails to reverse simple loop
-- What|Removed |Added Component|c |target Keywords||missed-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19676
[Bug target/19676] Loop optimizer fails to reverse simple loop
--- Additional Comments From andrewhutchinson at cox dot net 2005-01-28 19:14 --- Created an attachment (id=8094) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8094action=view) Optimised RTL Final Optimised RTL before asm code generation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19676
[Bug libgcj/19677] New: invalid may not have been initialized error
Following Eclipse code snippet that fails:
protected void join(InternalJob job) {
final IJobChangeListener listener;
synchronized (lock) {
listener = new JobChangeAdapter() {
public void done(IJobChangeEvent event) {
barrier.release();
}
};
job.addJobChangeListener(listener);
}
}
The error reports the line containing listener = as the problem.
--
Summary: invalid may not have been initialized error
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wasabi at larvalstage dot net
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19677
