[Bug target/44564] [avr] usage of LPM instruction combination with undefined result
--- Comment #4 from thomas-carsten dot franke at brunel dot de 2010-06-18 06:38 --- Created an attachment (id=20936) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20936action=view) extract of *.lss file shows the Z+ in lpm -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44564
[Bug target/44564] [avr] usage of LPM instruction combination with undefined result
--- Comment #5 from thomas-carsten dot franke at brunel dot de 2010-06-18 06:40 --- Created an attachment (id=20937) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20937action=view) extract of .s file (-save-temps) shows the lpm r31,Z, only -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44564
[Bug target/44575] __builtin_va_arg overwrites into adjacent stack location
--- Comment #1 from jakub at gcc dot gnu dot org 2010-06-18 07:04 --- Regressed with r146817 (SSA expand). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44575
[Bug fortran/44556] [4.5/4.6 Regression] incorrect error: Stat-variable at (1) shall not be DEALLOCATEd within the same DEALLOCATE statement
--- Comment #9 from burnus at gcc dot gnu dot org 2010-06-18 07:33 --- Patch: http://gcc.gnu.org/ml/fortran/2010-06/msg00191.html -- burnus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-06-16 12:21:06 |2010-06-18 07:33:34 date|| Summary|incorrect error: Stat- |[4.5/4.6 Regression] |variable at (1) shall not be|incorrect error: Stat- |DEALLOCATEd within the same |variable at (1) shall not be |DEALLOCATE statement|DEALLOCATEd within the same ||DEALLOCATE statement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44556
[Bug middle-end/44576] New: testsuite/gfortran.dg/zero_sized_1.f90 with huge compile time on prefetching+peeling
testsuite/gfortran.dg/zero_sized_1.f90 takes almost 11 minutes to compile on my notebook when combining aggressive loop prefetching with loop peeling: $ time gfortran-4.5 -O3 -march=core2 zero_sized_1.f90 -S -fprefetch-loop-arrays -funroll-loops --param max-completely-peeled-insns=2000 real10m54.594s user10m48.638s sys 0m0.393s The compiler is almost always in compute_miss_rate introduced by http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00641.html The problem is triggered by several things: - loop peeling creates thousands of references (with only a small delta) and each reference is compared with every other reference - for each comparison we iterate over all alignments - for each alignment we iterate over all distinct iterators As you can see this causes an exploding complexitiy. Furthermore,since the cache line size is passed in via an external variable, the compiler cannot optimize the integer division into shifts. I think the right solution would be to reduce the complexity of compute_miss_rate, but I have not found a good solution yet. -- Summary: testsuite/gfortran.dg/zero_sized_1.f90 with huge compile time on prefetching+peeling Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: borntraeger at de dot ibm dot com GCC host triplet: several, i486, s390.. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44576
[Bug middle-end/44576] testsuite/gfortran.dg/zero_sized_1.f90 with huge compile time on prefetching + peeling
--- Comment #1 from borntraeger at de dot ibm dot com 2010-06-18 07:59 --- 4.6 (trunk) is also affected -- borntraeger at de dot ibm dot com changed: What|Removed |Added Summary|testsuite/gfortran.dg/zero_s|testsuite/gfortran.dg/zero_s |ized_1.f90 with huge compile|ized_1.f90 with huge compile |time on prefetching+peeling |time on prefetching + ||peeling http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44576
[Bug target/44564] [avr] usage of LPM instruction combination with undefined result
--- Comment #6 from wvangulik at xs4all dot nl 2010-06-18 08:33 --- This bug can be closed it is a binutils bug. The dissambler is generating the wrong instruction. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44564
[Bug c++/44577] New: static local variables in class template methods are not optimized-away if not used
IMO, in the following test program the variable s within the class template may
be optimized-away in every case. Although, the variable is used as an argument
for a function call, it is omit-able due to the definition of function t1 as
static inline with its empty body. If I use instead of a class template a
function template, this contained static local variable will be optimized-away,
as expected.
[mschu...@teeth tst]$ cat test.cc
static inline void t1(const char* s) {}
template typename T
struct class_template {
class_template() {
static const char s[]=class_template;
t1(s);
}
};
template typename T
static inline void function_template() {
static const char s[]=function_template;
t1(s);
}
int main(int, char**) {
class_templateint t;
function_templateint();
return 0;
}
I compiled the program with
[mschu...@teeth tst]$ g++ -v
Using built-in specs.
Target: i586-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-ppl --with-cloog --with-tune=generic --with-arch=i586
--build=i586-redhat-linux
Thread model: posix
gcc version 4.4.1 20090725 (Red Hat 4.4.1-2) (GCC)
and then I used the string program to list the contained strings.
[mschu...@teeth tst]$ strings t
/lib/ld-linux.so.2
libstdc++.so.6
__gmon_start__
_Jv_RegisterClasses
__gxx_personality_v0
libm.so.6
libgcc_s.so.1
libc.so.6
_IO_stdin_used
__libc_start_main
CXXABI_1.3
GLIBC_2.0
PTRhP
QVhD
[^_]
class_template
[mschu...@teeth tst]$
The class_template string is present, but the function_template string not. If
I omit the static keyword, it will disappear, too.
Thanks in advance,
Michael
--
Summary: static local variables in class template methods are not
optimized-away if not used
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mschulze at ivs dot cs dot ovgu dot de
GCC build triplet: i586-redhat-linux
GCC host triplet: i586-redhat-linux
GCC target triplet: i586-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44577
[Bug c++/44577] static local variables in class template methods are not optimized-away if not used
--- Comment #1 from mschulze at ivs dot cs dot ovgu dot de 2010-06-18
10:11 ---
(In reply to comment #0)
IMO, in the following test program the variable s within the class template
may
be optimized-away in every case. Although, the variable is used as an argument
for a function call, it is omit-able due to the definition of function t1 as
static inline with its empty body. If I use instead of a class template a
function template, this contained static local variable will be
optimized-away,
as expected.
[mschu...@teeth tst]$ cat test.cc
static inline void t1(const char* s) {}
template typename T
struct class_template {
class_template() {
static const char s[]=class_template;
t1(s);
}
};
template typename T
static inline void function_template() {
static const char s[]=function_template;
t1(s);
}
int main(int, char**) {
class_templateint t;
function_templateint();
return 0;
}
I compiled the program with
[mschu...@teeth tst]$ g++ -Wall -Ostest.cc -o t
[mschu...@teeth tst]$ g++ -v
Using built-in specs.
Target: i586-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-ppl --with-cloog --with-tune=generic --with-arch=i586
--build=i586-redhat-linux
Thread model: posix
gcc version 4.4.1 20090725 (Red Hat 4.4.1-2) (GCC)
and then I used the string program to list the contained strings.
[mschu...@teeth tst]$ strings t
/lib/ld-linux.so.2
libstdc++.so.6
__gmon_start__
_Jv_RegisterClasses
__gxx_personality_v0
libm.so.6
libgcc_s.so.1
libc.so.6
_IO_stdin_used
__libc_start_main
CXXABI_1.3
GLIBC_2.0
PTRhP
QVhD
[^_]
class_template
[mschu...@teeth tst]$
The class_template string is present, but the function_template string not. If
I omit the static keyword, it will disappear, too.
Thanks in advance,
Michael
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44577
[Bug c/44517] improve diagnostic for mispelled typename in function declaration
--- Comment #1 from pzhao at gcc dot gnu dot org 2010-06-18 10:18 --- Confirmed. The diagnostic of clang is better. -- pzhao at gcc dot gnu dot org changed: What|Removed |Added CC||pzhao at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-18 10:18:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44517
[Bug target/44578] New: GCC generates MMX instructions but fails to generate emms
I'm using GCC to compile some code which uses SSE intrinsics. The code is being
compiled at -O3 -mfpmath=sse.
GCC decides to use MMX instructions for some of the operations (zeroing some
memory). There are no MMX intrinsics in the source, but an SSE _mm_setzero_ps
gets compiled into a pair of movq %mm0.
No emms instruction is emitted, possibly because gcc knows the FPU is not in
use because of the -mfpmath=sse switch, leaving the FPU in MMX mode.
However, the platform ABI specifies floating-point return values be returned in
FPU registers, so gcc moves return values from SSE registers to the FPU for
argument passing/returning. Since the FPU is in an invalid state because of the
lack of emms, this corrupts the floating-point values.
This behaviour seems to be very dependent on the exact version of gcc and the
exact source.
Here's a testcase:
#include stdio.h
#include emmintrin.h
// Since this is all in one file, we need to mark some functions
// noinline so that the interesting parts don't get compiled away
#define NOINLINE __attribute__((noinline))
struct OutputData
{
__m128 a, b;
};
struct InputData
{
float a, b;
};
// Something that uses an OutputData that won't be compiled away
__m128 ga, gb;
NOINLINE void doSomethingWith(const OutputData d){
ga = d.a;
gb = d.b;
}
NOINLINE void calc(const InputData in)
{
OutputData out;
// the next two lines are where the bug manifests
// gcc decides to use MMX instructions to write
// some zeros, but fails to clean up afterwards.
out.a = _mm_setr_ps(in.a, in.b, 0, 0);
out.b = _mm_setzero_ps();
// ensure the above is not optimised away
doSomethingWith(out);
}
NOINLINE float retFloat()
{
return 3;
}
int main()
{
InputData x = {3.4, 42};
// GCC emits MMX instructions for this function, but emits no emms
calc(x);
// This uses the FPU to return the value, which gets corrupted
printf(%f\n, retFloat());
return 0;
}
On my machine, this generates (for the function calc):
.globl _Z4calcRK9InputData
.type _Z4calcRK9InputData, @function
_Z4calcRK9InputData:
.LFB530:
.cfi_startproc
.cfi_personality 0x0,__gxx_personality_v0
pushl %ebp
.cfi_def_cfa_offset 8
pxor%mm0, %mm0
movl%esp, %ebp
.cfi_offset 5, -8
.cfi_def_cfa_register 5
subl$60, %esp
movl8(%ebp), %eax
movss 4(%eax), %xmm0
movss (%eax), %xmm1
movq%mm0, -48(%ebp) ; MMX instruction
movq%mm0, -24(%ebp) ; MMX instruction
leal-40(%ebp), %eax
movq%mm0, -16(%ebp) ; MMX instruction
movl%eax, (%esp)
unpcklps%xmm0, %xmm1
movaps %xmm1, %xmm0
xorps %xmm1, %xmm1
movlhps %xmm1, %xmm0
movlps %xmm0, -40(%ebp)
movhps %xmm0, -32(%ebp)
call_Z15doSomethingWithRK10OutputData
leave
ret ; FPU stack still in MMX mode and unusable for floating point
.cfi_endproc
.LFE530:
.size _Z4calcRK9InputData, .-_Z4calcRK9InputData
System:
Ubuntu Lucid (gcc 4:4.4.3-1ubuntu1)
GCC:
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.3-4ubuntu5'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--enable-multiarch --enable-linker-build-id --with-system-zlib
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-plugin --enable-objc-gc
--enable-targets=all --disable-werror --with-arch-32=i486 --with-tune=generic
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--target=i486-linux-gnu
Thread model: posix
gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5)
--
Summary: GCC generates MMX instructions but fails to generate
emms
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: stephen dot dolan at havok dot com
GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44578
[Bug c++/44579] New: Extern doesn work for const arrays
Given file foo.cc:
const
int arr[] = {0};
compiled to foo.o, and file bar.cc:
extern
const
int arr[];
int main() {
return arr[0];
}
compiled and linked with foo.o, you get:
s3:~/ootbc/personal/ivan$ g++ bar.cc foo.o
/tmp/ccsMPoJa.o: In function `main':
bar.cc:(.text+0x6): undefined reference to `arr'
collect2: ld returned 1 exit status
It works if the array isn't const.
--
Summary: Extern doesn work for const arrays
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44579
[Bug c++/44579] Extern doesn work for const arrays
--- Comment #1 from redi at gcc dot gnu dot org 2010-06-18 10:44 --- const objects at namespace scope are static by default, you need to declare it extern in foo.cc to prevent that -- redi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44579
[Bug target/44578] GCC generates MMX instructions but fails to generate emms
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-06-18 10:46 --- As -mfpmath=sse isn't supposed to change the ABI we should never emit MMX instructions automagically. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2010-06-18 10:46:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44578
[Bug c++/44577] static local variables in class template methods are not optimized-away if not used
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-06-18 10:51 --- 9.4.2/6 says that static data members of a class have external linkage. You should be able to adjust that by providing proper visibility attributes or pragmas. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44577
[Bug middle-end/44576] [4.5/4.6 Regression] testsuite/gfortran.dg/zero_sized_1.f90 with huge compile time on prefetching + peeling
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-06-18 10:52 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||compile-time-hog Last reconfirmed|-00-00 00:00:00 |2010-06-18 10:52:06 date|| Summary|testsuite/gfortran.dg/zero_s|[4.5/4.6 Regression] |ized_1.f90 with huge compile|testsuite/gfortran.dg/zero_s |time on prefetching + |ized_1.f90 with huge compile |peeling |time on prefetching + ||peeling Target Milestone|--- |4.5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44576
[Bug target/44575] [4.5/4.6 Regression] __builtin_va_arg overwrites into adjacent stack location
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||wrong-code Summary|__builtin_va_arg overwrites |[4.5/4.6 Regression] |into adjacent stack location|__builtin_va_arg overwrites ||into adjacent stack location Target Milestone|--- |4.5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44575
[Bug target/44573] ICE+seg11 when compiling GTK
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-06-18 10:56 --- Works on i?86-linux. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|tree-optimization |target GCC host triplet||i386-portbld-freebsd8.1 GCC target triplet||i386-portbld-freebsd8.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44573
[Bug c++/44580] New: inconsistent right-hand operand of comma has no effect
I have observed the following behavior on several generations of GCC (starting
at Apple's 4.0) and up to 4.6. Tested on OS X, but also GNU/Linux.
It's hard to write assert-like functions because GCC does not behave equally
when the context is that of a function template, or a simple function.
This passes with -Wall:
static
void
unreachable_1()
{
return;
(abort(), 0);
}
but this does not:
template typename T
static
void
unreachable_2(T)
{
return;
(abort(), 0);
}
$ g++-4.0 unreachable.cc -Wall
unreachable.cc: In function void unreachable_2(T):
unreachable.cc:19: warning: right-hand operand of comma has no effect
unreachable.cc: In function void unreachable_2(T) [with T = int]:
unreachable.cc:26: instantiated from here
unreachable.cc:19: warning: right-hand operand of comma has no effect
$ g++-mp-4.6 unreachable.cc -Wall
unreachable.cc: In function 'void unreachable_2(T) [with T = int]':
unreachable.cc:26:18: instantiated from here
unreachable.cc:19:3: warning: right-hand operand of comma has no effect
[-Wunused-value]
--
Summary: inconsistent right-hand operand of comma has no effect
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: akim dot demaille at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44580
[Bug c++/44580] inconsistent right-hand operand of comma has no effect
--- Comment #1 from akim dot demaille at gmail dot com 2010-06-18 11:49 --- Created an attachment (id=20938) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20938action=view) Test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44580
[Bug c++/44577] static local variables in class template methods are not optimized-away if not used
--- Comment #3 from mschulze at ivs dot cs dot ovgu dot de 2010-06-18 12:01 --- IMO, this is not a static member of a class itself, even it is defined inside of a member function, thus I think it has not to have external linkage. -- mschulze at ivs dot cs dot ovgu dot de changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44577
[Bug c++/44577] static local variables in class template methods are not optimized-away if not used
--- Comment #4 from redi at gcc dot gnu dot org 2010-06-18 13:25 --- If class_templateint::class_template is instantiated in another translation unit then it needs to refer to the same 's' ... but since the constructor calls a static function, an instantiation in another TU would violate the ODR, which would be undefined (no diagnostic required) so by that argument the compiler could assume no other instantiations and therefore no valid way for another TU to refer to 's' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44577
[Bug fortran/44568] [OOP] ICE with TBP of polymorphic derived type array
--- Comment #2 from boschmann at tp1 dot physik dot uni-siegen dot de 2010-06-18 13:29 --- Subject: Re: [OOP] ICE with TBP of polymorphic derived type array Hallo Janus, wird denn im Moment an diesem Feature gearbeitet? Eigentlich wollte ich diesen Sommer mein Code offiziell in das Whizard-Projekt einfügen. Wenn es keine Hoffnung gibt, dass gcc in vier Wochen polymorphe arrays versteht, dann muss ich mein Programm umbauen. LG, Hans Boschmann Am 18.06.2010 00:46, schrieb janus at gcc dot gnu dot org: --- Comment #1 from janus at gcc dot gnu dot org 2010-06-17 22:46 --- This is not expected to work right now, as polymorphic arrays are not really implemented yet. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44568
[Bug bootstrap/38607] AIX error messages about TOC during build
--- Comment #14 from michael dot haubenwallner at salomon dot at
2010-06-18 13:44 ---
(In reply to comment #13)
#include string
#include map
void foo()
{
std::mapstd::string, std::string bar;
}
Simply compiling this source code into an rtl-enabled shared library leads to
that linker warning, with both vanilla gcc-4.5.0 and gcc-4.4.4, configured to
use native as and ld each, on AIX5.3 TL8.
$ g++ -shared -Wl,-G -o libshare.so test.cpp
ld: 0711-768 WARNING: Object /tmp//ccIju3gQ.o, section 1, function *SNIP*:
The branch at address 0x618 is not followed by a recognized no-op
or TOC-reload instruction. The unrecognized instruction is 0x801F007C.
The warning isn't shown with the '-bsymbolic' linker flag, as this one
relocation is finally resolved locally and the subsequent 'nop' isn't needed.
But doing symbolic linking doesn't fit as workaround.
Thank you!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38607
[Bug c/44581] New: internal compiler error: in simplify_subreg
when trying to compile fftw3, I get the following error: gcc -O2 -g -mpa-risc-1-0 -c r2cf_16.i -fPIC r2cf_16.i: In function r2cf_16: r2cf_16.i:119:1: internal compiler error: in simplify_subreg, at simplify-rtx.c:5143 Please submit a full bug report, gcc is: gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/hppa2.0-suse-linux/4.5/lto-wrapper Target: hppa2.0-suse-linux Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib --enable-languages=c,c++,objc,fortran,obj-c++,java --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.5 --enable-ssp --disable-libssp --disable-plugin --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap --with-slibdir=/lib --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --program-suffix=-4.5 --enable-linux-futex --without-system-libunwind --build=hppa2.0-suse-linux Thread model: posix gcc version 4.5.0 20100604 [gcc-4_5-branch revision 160292] (SUSE Linux) attaching preprocessed source. -- Summary: internal compiler error: in simplify_subreg Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: b dot gunreben at web dot de GCC target triplet: hppa2.0-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44581
[Bug c/44581] internal compiler error: in simplify_subreg
--- Comment #1 from b dot gunreben at web dot de 2010-06-18 15:32 --- Created an attachment (id=20939) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20939action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44581
[Bug target/44575] [4.5/4.6 Regression] __builtin_va_arg overwrites into adjacent stack location
--- Comment #2 from matz at gcc dot gnu dot org 2010-06-18 15:58 ---
It's not SSA expand (might be exposed by it, don't know), but the
bug is pre-existing already in 4.3:
long unsigned int D.2219;
struct S116 va_arg_tmp.3;
...
addr.0 = va_arg_tmp.3;
addr.4 = (long unsigned int *) addr.0;
sse_addr.5 = (long unsigned int *) sse_addr.2;
D.2214 = *sse_addr.5;
*addr.4 = D.2214;
addr.6 = (long unsigned int *) addr.0;
D.2216 = addr.6 + 8;
sse_addr.7 = (long unsigned int *) sse_addr.2;
D.2218 = sse_addr.7 + 16;
D.2219 = *D.2218;
*D.2216 = D.2219;
Here the second store is also a 8-byte store at offset 8 of a struct only
12 bytes long. The problem is in ix86_gimplify_va_arg (and friends).
For the type in question (struct S116), we build this classes[] array:
(gdb) p regclass
$47 = {X86_64_SSE_CLASS, X86_64_SSE_CLASS, ...
That's okay, for such structs we really need two words, and both are passed
in registers (if available). But the construct_container constructs this
container:
(gdb) p debug_rtx(container)
(parallel:BLK [
(expr_list:REG_DEP_TRUE (reg:DI 21 xmm0)
(const_int 0 [0]))
(expr_list:REG_DEP_TRUE (reg:DI 22 xmm1)
(const_int 8 [0x8]))
])
So, we try to move the content at offset 0 in DImode (the register itself
will be irrelevant here, as we're needing a temporary), which is still fine.
But the register of slot 1 also has DImode, for moving the values at offset
8. This mode will be used to determine the type of the move instruction
generated, and is the one where things become wrong. See the loop in
ix86_gimplify_va_arg, starting here:
for (i = 0; i XVECLEN (container, 0); i++)
{
...
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
CC||hubicka at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44575
[Bug rtl-optimization/40900] redundant sign extend of short function returned value
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2010-06-18 16:39 --- Subject: Bug 40900 Author: ebotcazou Date: Fri Jun 18 16:38:29 2010 New Revision: 161006 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161006 Log: PR rtl-optimization/40900 * expr.c (expand_expr_real_1) SSA_NAME: Fix long line. Save the original expression for later reuse. expand_decl_rtl: Use promote_function_mode to compute the signedness of the promoted RTL for a SSA_NAME on the LHS of a call statement. Added: trunk/gcc/testsuite/gcc.target/arm/pr40900.c Modified: trunk/gcc/ChangeLog trunk/gcc/expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40900
[Bug rtl-optimization/40900] redundant sign extend of short function returned value
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2010-06-18 16:40 --- On the mainline. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40900
[Bug libstdc++/32618] std::vector calls uneccessary constructors instead of inplace construction of first object
--- Comment #11 from paolo at gcc dot gnu dot org 2010-06-18 18:08 --- Subject: Bug 32618 Author: paolo Date: Fri Jun 18 18:07:45 2010 New Revision: 161009 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161009 Log: 2010-06-18 Paolo Carlini paolo.carl...@oracle.com PR libstdc++/32618 * include/bits/stl_list.h (vector::_M_default_initialize, _M_default_append): Declare. (list::list(size_type), resize(size_type)): Add in C++0x mode, use the latter. * include/bits/list.tcc (list::resize, _M_default_append): Define. * include/bits/stl_vector.h (vector::_M_default_initialize, _M_default_append): Declare. (vector::vector(size_type), resize(size_type)): Add in C++0x mode, use the latter. * include/bits/vector.tcc (vector::_M_default_append): Define. * include/bits/stl_deque.h (deque::_M_default_initialize, _M_default_append): Declare. (deque::deque(size_type), resize(size_type)): Add in C++0x mode, use the latter. * include/bits/deque.tcc (deque::_M_default_append): Define. * include/debug/vector: Update. * include/debug/deque: Likewise. * include/debug/list: Likewise. * include/profile/vector: Likewise. * include/profile/deque: Likewise. * include/profile/list: Likewise. * include/bits/forward_list.h (_M_default_initialize, _M_default_insert_after): Declare. (forward_list::forward_list(size_type), resize(size_type)): Fix, use the latter. * include/bits/forward_list.tcc (forward_list::_M_default_append, _M_default_insert_after): Define. * testsuite/util/testsuite_api.h (NonCopyConstructible): Add. * testsuite/23_containers/forward_list/modifiers/6.cc: Move to... * testsuite/23_containers/forward_list/capacity/resize_size.cc: ... here. * testsuite/23_containers/forward_list/cons/10.cc: Move to... * testsuite/23_containers/forward_list/cons/cons_size.cc: ... here. * testsuite/23_containers/vector/resize/1.cc: Move to... * testsuite/23_containers/vector/capacity/resize/1.cc: ... here. * testsuite/23_containers/vector/resize/moveable.cc: Move to... * testsuite/23_containers/vector/resize/capacity/moveable.cc: ... here. * testsuite/23_containers/vector/cons/cons_size.cc: New. * testsuite/23_containers/vector/capacity/resize/resize_size.cc: Likewise. * testsuite/23_containers/deque/cons/cons_size.cc: Likewise. * testsuite/23_containers/deque/capacity/resize_size.cc: Likewise. * testsuite/23_containers/list/cons/cons_size.cc: Likewise. * testsuite/23_containers/list/capacity/resize_size.cc: Likewise. * testsuite/23_containers/vector/capacity/resize/moveable.cc: Adjust. * testsuite/23_containers/deque/capacity/moveable.cc: Likewise. * testsuite/23_containers/forward_list/requirements/dr438/ assign_neg.cc: Adjust dg-error line numbers. * testsuite/23_containers/forward_list/requirements/dr438/ insert_neg.cc: Likewise. * testsuite/23_containers/forward_list/requirements/dr438/ constructor_1_neg.cc: Likewise. * testsuite/23_containers/forward_list/requirements/dr438/ constructor_2_neg.cc: Likewise. * testsuite/23_containers/vector/requirements/dr438/ assign_neg.cc: Likewise. * testsuite/23_containers/vector/requirements/dr438/insert_neg.cc: Likewise. * testsuite/23_containers/vector/requirements/dr438/ constructor_1_neg.cc: Likewise. * testsuite/23_containers/vector/requirements/dr438/ constructor_2_neg.cc: Likewise. * testsuite/23_containers/deque/requirements/dr438/ assign_neg.cc: Likewise. * testsuite/23_containers/deque/requirements/dr438/insert_neg.cc: Likewise. * testsuite/23_containers/deque/requirements/dr438/ constructor_1_neg.cc: Likewise. * testsuite/23_containers/deque/requirements/dr438/ constructor_2_neg.cc: Likewise. * testsuite/23_containers/list/requirements/dr438/assign_neg.cc: Likewise. * testsuite/23_containers/list/requirements/dr438/insert_neg.cc: Likewise. * testsuite/23_containers/list/requirements/dr438/ constructor_1_neg.cc: Likewise. * testsuite/23_containers/list/requirements/dr438/ constructor_2_neg.cc: Likewise. Added: trunk/libstdc++-v3/testsuite/23_containers/deque/capacity/resize_size.cc trunk/libstdc++-v3/testsuite/23_containers/deque/cons/cons_size.cc trunk/libstdc++-v3/testsuite/23_containers/forward_list/capacity/resize_size.cc - copied, changed from r160898, trunk/libstdc++-v3/testsuite/23_containers/forward_list/modifiers/6.cc trunk/libstdc++-v3/testsuite/23_containers/forward_list/cons/cons_size.cc -
[Bug fortran/44582] New: Gfotran generates wrong results due to wrong ABI in function with array return
the function with array return must create a temporary array to hold the returned value and transfer the value to destination array after function call. Gfortran directly pass the destination array as the first fake argument. This is wrong because destination is supposed to assigned to a value from the call. If the function does nothing to the return array. the destination array will have a wrong value. This is a example to show the bug program sw integer,parameter:: M=500,N=60 double precision,dimension(M,N,3):: u double precision,dimension(M,N):: dudx dudx(1,1) = 5.0 dudx = ddx(u(:,:,1)) contains function ddx(array) implicit double precision (a-h,o-z) double precision:: array(:,:) double precision:: ddx(size(array,dim=1),size(array,dim=2)) print *, ddx(1,1) end function ddx end program sw gfortran returns 5.0 it should be 0.0 or a chaotic number. -- Summary: Gfotran generates wrong results due to wrong ABI in function with array return Product: gcc Version: fortran-dev Status: UNCONFIRMED Severity: critical Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: yin at absoft dot com GCC build triplet: x86-64 GCC host triplet: x86-64 GCC target triplet: x86-64 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44582
[Bug fortran/44582] Gfotran generates wrong results due to wrong ABI in function with array return
--- Comment #1 from yin at absoft dot com 2010-06-18 18:16 --- Created an attachment (id=20940) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20940action=view) bug example -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44582
[Bug libstdc++/32618] std::vector calls uneccessary constructors instead of inplace construction of first object
--- Comment #12 from paolo dot carlini at oracle dot com 2010-06-18 18:22 --- Done. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Severity|minor |normal Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32618
[Bug fortran/44582] Gfotran generates wrong results due to wrong ABI in function with array return
--- Comment #2 from yin at absoft dot com 2010-06-18 18:23 --- it should be 0.0 always, NOT to be chaotic number like C, because when ddx is declared, it has to be initialized to 0.0 by fortran standard. -- yin at absoft dot com changed: What|Removed |Added Summary|Gfotran generates wrong |Gfotran generates wrong |results due to wrong ABI in |results due to wrong ABI in |function with array return |function with array return http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44582
[Bug middle-end/44583] New: [4.6 Regression] c-c++-common/torture/complex-sign-add.c
On Linux/ia64, revision 160916 gave FAIL: c-c++-common/torture/complex-sign-add.c -O0 execution test FAIL: c-c++-common/torture/complex-sign-sub.c -O0 execution test Revision 160869 is OK. -- Summary: [4.6 Regression] c-c++-common/torture/complex-sign-add.c Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44583
[Bug middle-end/44584] New: [4.6 Regression] gfortran.dg/typebound_proc_15.f03
On Linux/ia64, revision 160858 gave FAIL: gfortran.dg/typebound_proc_15.f03 -O (internal compiler error) FAIL: gfortran.dg/typebound_proc_15.f03 -O (test for excess errors) Revision 160826 is OK. -- Summary: [4.6 Regression] gfortran.dg/typebound_proc_15.f03 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44584
[Bug c++/44585] New: Failure to warn about implicit conversion from double to int
The following code compiles without warning and has an exit value of 1, which
is correct according to the standard. However, an implicit conversion from
double to int happened without a corresponding warning. This seems incorrect to
me, and similar to bug 24525 (
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24525 ).
struct T {
double x;
explicit T(double x) : x(x) {
}
operator double() {
return x;
}
};
T f() {
return T(5.3);
}
int main() {
double t = false ? 0 : f();
return t == 5.0;
}
--
Summary: Failure to warn about implicit conversion from double to
int
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: alvaro dot begue at gmail dot com
GCC build triplet: x86_64-suse-linux
GCC host triplet: x86_64-suse-linux
GCC target triplet: x86_64-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44585
[Bug fortran/44582] gfortran generates wrong results due to wrong ABI in function with array return
--- Comment #3 from kargl at gcc dot gnu dot org 2010-06-18 18:49 --- (In reply to comment #2) it should be 0.0 always, NOT to be chaotic number like C, because when ddx is declared, it has to be initialized to 0.0 by fortran standard. Can you point the language in the Fortran Standard that supports your claim? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44582
[Bug fortran/44582] gfortran generates wrong results due to wrong ABI in function with array return
--- Comment #4 from yin at absoft dot com 2010-06-18 19:00 --- O.K. I doublechecked the standard. The array declared does not need to be initialized in this case. So the return value could be any number. However, this kind of implementation should fail in a certian case. I am trying to write a small example to prove this. I will post it later. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44582
[Bug fortran/44582] gfortran generates wrong results due to wrong ABI in function with array return
--- Comment #5 from kargl at gcc dot gnu dot org 2010-06-18 19:10 --- (In reply to comment #4) O.K. I doublechecked the standard. The array declared does not need to be initialized in this case. So the return value could be any number. However, this kind of implementation should fail in a certian case. I am trying to write a small example to prove this. I will post it later. Well, actually the array needs to be initialized, but not by the compiler. It is the responsibility of the programmer to initialize his/her variables. Techincally, your function is invalid because function ddx(array) implicit double precision (a-h,o-z) double precision:: array(:,:) double precision:: ddx(size(array,dim=1),size(array,dim=2)) print *, ddx(1,1) end function ddx the print statement references an undefined variable. See section 16.5.1: (1) An array is defined if and only if all of its elements are defined. A careful reading of 16.5 might be useful. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44582
[Bug c/44586] New: gcc does not warn about casting non-variadic types to variadic types
the folowing testcase does a casting which results in undefined behaviour but
gcc does not warn about it.
ypedef int (*bar_t)(int x, int y, ...);
int foo(int x, int y) {
return x+y;
}
void f(int x, int y) {
bar_t bar;
/* Cast foo to variadic type... undefined behaviour */
bar = (bar_t) foo;
(*bar)(x,y);
}
--
Summary: gcc does not warn about casting non-variadic types to
variadic types
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: raj dot khem at gmail dot com
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=44586
[Bug c++/44585] Failure to warn about implicit conversion from double to int
--- Comment #1 from alvaro dot begue at gmail dot com 2010-06-18 20:42 --- I just learned about -Wconversion and gcc does indeed warn about the implicit conversion from double to int when I specify it. Sorry for the false alarm. -- alvaro dot begue at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44585
[Bug c++/44587] New: [4.4/4.5/4.6 Regression] ICE in instantiate_decl
template const char *N struct A { };
template class T struct B { static const char c[1]; typedef ABT::c C; };
ICEs in instantiate_decl.
template const int N struct A { };
template class T struct B { static const int c; typedef ABT::c C; };
template class T const int BT c = sizeof (T);
ICEs too, while e.g.
template const int N struct A { };
template class T struct B { static const int c = sizeof (T); typedef
ABT::c C; };
does not.
--
Summary: [4.4/4.5/4.6 Regression] ICE in instantiate_decl
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44587
[Bug target/44129] Building linux kernel with gcc-4.5.0 and CONFIG_CC_OPTIMIZE_FOR_SIZE segfaults
--- Comment #16 from andi-gcc at firstfloor dot org 2010-06-18 21:11 --- This turned out to be a kernel bug, rdtsc_barrier() needed to be marked __force_inline, otherwise gcc would not inline this function. (although it's slightly fishy for gcc too not inline a function that only has two inline assembler statements even with -Os) http://lkml.org/lkml/2010/6/18/317 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44129
[Bug fortran/40628] Assignment using = trim(string): Optimize trim away
--- Comment #1 from tkoenig at gcc dot gnu dot org 2010-06-18 21:12 --- Mine. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2009-09-29 05:52:11 |2010-06-18 21:12:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40628
[Bug fortran/44584] gfortran.dg/typebound_proc_15.f03 failed
--- Comment #1 from janus at gcc dot gnu dot org 2010-06-18 21:18 --- Works for me on x86_64-unknown-linux-gnu at r160947. Can you show the backtrace for the ICE? -- janus at gcc dot gnu dot org changed: What|Removed |Added CC||janus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44584
[Bug fortran/40628] Assignment using = trim(string): Optimize trim away
--- Comment #2 from burnus at gcc dot gnu dot org 2010-06-18 21:19 --- In the link, one also finds trim(str1) == trim(str2) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40628
[Bug fortran/44584] gfortran.dg/typebound_proc_15.f03 failed
--- Comment #2 from janus at gcc dot gnu dot org 2010-06-18 21:24 --- (In reply to comment #0) On Linux/ia64, revision 160858 gave ... Revision 160826 is OK. The only Fortran-related change in this range is r160834 | janus | 2010-06-16 14:54:54 +0200 (Wed, 16 Jun 2010) | 17 lines This was the fix for PR44549, which was a follow-up to PR40117 (where typebound_proc_15.f03 came from). Can you confirm that this is the culprit? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44584
[Bug c++/44587] [4.4/4.5/4.6 Regression] ICE in instantiate_decl
--- Comment #1 from jakub at gcc dot gnu dot org 2010-06-18 21:54 --- Compiled fine until r144617, starting with r144618 gave R.ii:2: error: âBT::câ cannot appear in a constant-expression R.ii:2: error: template argument 1 is invalid and starting with r154042 started ICEing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44587
[Bug fortran/44584] gfortran.dg/typebound_proc_15.f03 failed
--- Comment #3 from hjl dot tools at gmail dot com 2010-06-18 22:11 ---
I got
Starting program: /export/gnu/import/svn/gcc-test/bld/gcc/f951
/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gfortran.dg/typebound_proc_15.f03
-quiet -dumpbase typebound_proc_15.f03 -auxbase typebound_proc_15 -std=f2003
-version -o typebound_proc_15.s -fintrinsic-modules-path finclude
GNU Fortran (GCC) version 4.6.0 20100618 (experimental) [trunk revision 161008]
(ia64-unknown-linux-gnu)
compiled by GNU C version 4.6.0 20100618 (experimental) [trunk revision
161008], GMP version 4.3.2, MPFR version 2.4.2-p3, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU Fortran (GCC) version 4.6.0 20100618 (experimental) [trunk revision 161008]
(ia64-unknown-linux-gnu)
compiled by GNU C version 4.6.0 20100618 (experimental) [trunk revision
161008], GMP version 4.3.2, MPFR version 2.4.2-p3, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gfortran.dg/typebound_proc_15.f03:15.23:
procedure :: bar, baz { dg-error PROCEDURE list }
1
Error: Fortran 2008: PROCEDURE list at (1)
Program received signal SIGSEGV, Segmentation fault.
0x401d4681 in resolve_fl_derived (sym=0x602cf0d0)
at ../../src-trunk/gcc/fortran/resolve.c:959
959 if (!a.implicit_type sym-ts.type != BT_UNKNOWN)
(gdb) bt
#0 0x401d4681 in resolve_fl_derived (sym=0x602cf0d0)
at ../../src-trunk/gcc/fortran/resolve.c:959
#1 0x401ce4b0 in resolve_symbol (sym=0x602cf0d0)
at ../../src-trunk/gcc/fortran/resolve.c:959
#2 0x401fec40 in traverse_ns (st=value optimized out,
func=value optimized out) at ../../src-trunk/gcc/fortran/symbol.c:1885
#3 0x401c9430 in resolve_types (ns=0x602cb520)
at ../../src-trunk/gcc/fortran/resolve.c:959
#4 0x401b92c0 in gfc_resolve (ns=0x602cb520)
at ../../src-trunk/gcc/fortran/resolve.c:959
#5 0x4019d3f0 in gfc_parse_file ()
at ../../src-trunk/gcc/fortran/parse.c:4223
#6 0x40224ee0 in gfc_be_parse_file (set_yydebug=0)
at ./gtype-fortran.h:278
#7 0x40966090 in toplev_main (argc=13, argv=0x6f8ab688)
at ../../src-trunk/gcc/toplev.c:1576
#8 0x402e7370 in main (argc=13, argv=0x6f8ab688)
at ../../src-trunk/gcc/main.c:36
(gdb)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44584
[Bug fortran/44584] gfortran.dg/typebound_proc_15.f03 failed
--- Comment #4 from hjl dot tools at gmail dot com 2010-06-18 22:14 ---
On x86, I got
valgrind --tool=memcheck ../f951
/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gfortran.dg/typebound_proc_15.f03
-quiet -dumpbase typebound_proc_15.f03 -mtune=generic -march=pentium4 -auxbase
typebound_proc_15 -std=f2003 -version -o typebound_proc_15.s
-fintrinsic-modules-path finclude
==22636== Memcheck, a memory error detector
==22636== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==22636== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==22636== Command: ../f951
/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gfortran.dg/typebound_proc_15.f03
-quiet -dumpbase typebound_proc_15.f03 -mtune=generic -march=pentium4 -auxbase
typebound_proc_15 -std=f2003 -version -o typebound_proc_15.s
-fintrinsic-modules-path finclude
==22636==
GNU Fortran (GCC) version 4.6.0 20100618 (experimental) [trunk revision 161010]
(i686-pc-linux-gnu)
compiled by GNU C version 4.6.0 20100618 (experimental) [trunk revision
161010], GMP version 4.3.2, MPFR version 2.4.2-p3, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU Fortran (GCC) version 4.6.0 20100618 (experimental) [trunk revision 161010]
(i686-pc-linux-gnu)
compiled by GNU C version 4.6.0 20100618 (experimental) [trunk revision
161010], GMP version 4.3.2, MPFR version 2.4.2-p3, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gfortran.dg/typebound_proc_15.f03:15.23:
procedure :: bar, baz { dg-error PROCEDURE list }
1
Error: Fortran 2008: PROCEDURE list at (1)
==22636== Invalid read of size 4
==22636==at 0x80DCE5B: add_proc_component.isra.0 (class.c:223)
==22636==by 0x80DD18F: add_procs_to_declared_vtab1 (class.c:251)
==22636==by 0x80DDDFD: add_procs_to_declared_vtab (class.c:386)
==22636==by 0x80DDC28: gfc_find_derived_vtab (class.c:626)
==22636==by 0x4147067: ???
==22636== Address 0x4143d7c is 20 bytes inside a block of size 24 free'd
==22636==at 0x40057F6: free (vg_replace_malloc.c:325)
==22636==by 0x815AD42: gfc_delete_symtree (symbol.c:2376)
==22636==by 0x815BCCC: gfc_undo_symbols (symbol.c:2843)
==22636==by 0x812AE6F: reject_statement (parse.c:1647)
==22636==by 0x812AED0: match_word (parse.c:70)
==22636==by 0x812BC3E: decode_statement (parse.c:423)
==22636==by 0x812CA7C: next_statement (parse.c:723)
==22636==by 0x812E17C: parse_spec (parse.c:1870)
==22636==by 0x8130969: gfc_parse_file (parse.c:4114)
==22636==
==22636== Invalid read of size 1
==22636==at 0x8145CEA: resolve_fl_derived (resolve.c:10789)
==22636==by 0x81440CE: resolve_symbol (resolve.c:11403)
==22636== Address 0x4143c38 is 48 bytes inside a block of size 300 free'd
==22636==at 0x40057F6: free (vg_replace_malloc.c:325)
==22636==by 0x815BE37: gfc_undo_symbols (symbol.c:2849)
==22636==by 0x812AE6F: reject_statement (parse.c:1647)
==22636==by 0x812AED0: match_word (parse.c:70)
==22636==by 0x812BC3E: decode_statement (parse.c:423)
==22636==by 0x812CA7C: next_statement (parse.c:723)
==22636==by 0x812E17C: parse_spec (parse.c:1870)
==22636==by 0x8130969: gfc_parse_file (parse.c:4114)
==22636==
==22636== Invalid read of size 1
==22636==at 0x8145CFA: resolve_fl_derived (resolve.c:10795)
==22636==by 0x81440CE: resolve_symbol (resolve.c:11403)
==22636== Address 0x4143c3d is 53 bytes inside a block of size 300 free'd
==22636==at 0x40057F6: free (vg_replace_malloc.c:325)
==22636==by 0x815BE37: gfc_undo_symbols (symbol.c:2849)
==22636==by 0x812AE6F: reject_statement (parse.c:1647)
==22636==by 0x812AED0: match_word (parse.c:70)
==22636==by 0x812BC3E: decode_statement (parse.c:423)
==22636==by 0x812CA7C: next_statement (parse.c:723)
==22636==by 0x812E17C: parse_spec (parse.c:1870)
==22636==by 0x8130969: gfc_parse_file (parse.c:4114)
==22636==
==22636== Invalid read of size 1
==22636==at 0x81461E0: resolve_fl_derived (resolve.c:10796)
==22636==by 0x81440CE: resolve_symbol (resolve.c:11403)
==22636== Address 0x4143c34 is 44 bytes inside a block of size 300 free'd
==22636==at 0x40057F6: free (vg_replace_malloc.c:325)
==22636==by 0x815BE37: gfc_undo_symbols (symbol.c:2849)
==22636==by 0x812AE6F: reject_statement (parse.c:1647)
==22636==by 0x812AED0: match_word (parse.c:70)
==22636==by 0x812BC3E: decode_statement (parse.c:423)
==22636==by 0x812CA7C: next_statement (parse.c:723)
==22636==by 0x812E17C: parse_spec (parse.c:1870)
==22636==by 0x8130969: gfc_parse_file (parse.c:4114)
==22636==
==22636== Invalid read of size 4
==22636==at 0x81461EA: resolve_fl_derived (resolve.c:10853)
==22636==by 0x81440CE: resolve_symbol (resolve.c:11403)
==22636== Address 0x4143c08 is 0 bytes inside a block of size 300
[Bug fortran/44556] [4.5/4.6 Regression] incorrect error: Stat-variable at (1) shall not be DEALLOCATEd within the same DEALLOCATE statement
--- Comment #10 from burnus at gcc dot gnu dot org 2010-06-18 22:24 --- Subject: Bug 44556 Author: burnus Date: Fri Jun 18 22:23:40 2010 New Revision: 161011 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161011 Log: 2010-06-18 Tobias Burnus bur...@net-b.de PR fortran/44556 * resolve.c (resolve_allocate_deallocate): Properly check part-refs in stat=/errmsg= for invalid use. 2010-06-18 Tobias Burnus bur...@net-b.de PR fortran/44556 * gfortran.dg/allocate_alloc_opt_11.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/allocate_alloc_opt_11.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44556
[Bug testsuite/43739] [4.5 Regression] FAIL: gcc.dg/pr43643.c (test for excess errors)
--- Comment #3 from danglin at gcc dot gnu dot org 2010-06-18 22:35 --- Subject: Bug 43739 Author: danglin Date: Fri Jun 18 22:34:42 2010 New Revision: 161012 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161012 Log: Backport from mainline 2010-04-14 Steve Ellcey s...@cup.hp.com PR testsuite/43739 * gcc.dg/pr43643.c: Use static link on hppa*-*-hpux*. Modified: branches/gcc-4_5-branch/gcc/testsuite/ChangeLog branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/pr43643.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43739
[Bug testsuite/43739] [4.5 Regression] FAIL: gcc.dg/pr43643.c (test for excess errors)
--- Comment #4 from danglin at gcc dot gnu dot org 2010-06-18 22:39 --- Subject: Bug 43739 Author: danglin Date: Fri Jun 18 22:38:32 2010 New Revision: 161013 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161013 Log: Backport from mainline 2010-04-14 Steve Ellcey s...@cup.hp.com PR testsuite/43739 * gcc.dg/pr43643.c: Use static link on hppa*-*-hpux*. Modified: branches/gcc-4_4-branch/gcc/testsuite/ChangeLog branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr43643.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43739
[Bug fortran/44584] gfortran.dg/typebound_proc_15.f03 failed
--- Comment #5 from janus at gcc dot gnu dot org 2010-06-18 23:54 ---
(In reply to comment #3)
/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gfortran.dg/typebound_proc_15.f03:15.23:
procedure :: bar, baz { dg-error PROCEDURE list }
1
Error: Fortran 2008: PROCEDURE list at (1)
Program received signal SIGSEGV, Segmentation fault.
0x401d4681 in resolve_fl_derived (sym=0x602cf0d0)
at ../../src-trunk/gcc/fortran/resolve.c:959
959 if (!a.implicit_type sym-ts.type != BT_UNKNOWN)
(gdb) bt
#0 0x401d4681 in resolve_fl_derived (sym=0x602cf0d0)
at ../../src-trunk/gcc/fortran/resolve.c:959
Ok, actually I also get an ICE. But for some reason only when compiling by
hand, not in the testsuite.
It is fixed by this patch:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 160948)
+++ gcc/fortran/resolve.c (working copy)
@@ -10850,7 +10850,7 @@
c-ts.u.cl = cl;
}
}
- else if (c-ts.interface-name[0] != '\0' !sym-attr.vtype)
+ else if (!sym-attr.vtype c-ts.interface-name[0] != '\0')
{
gfc_error (Interface '%s' of procedure pointer component
'%s' at %L must be explicit, c-ts.interface-name,
Does this fix the issue for you?
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2010-06-18 23:54:28
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44584
[Bug target/44129] Building linux kernel with gcc-4.5.0 and CONFIG_CC_OPTIMIZE_FOR_SIZE segfaults
--- Comment #17 from bdubbs at linuxfromscratch dot org 2010-06-19 00:05 --- I can confirm that changing inline to __always_inline in arch/x86/include/asm/system.h fixed the panic for me. I'm not sure if this fix is the result of an error in the kernel or gcc. Leaving the bug open for now, but it may be appropriate to close it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44129
[Bug target/44129] Building linux kernel with gcc-4.5.0 and CONFIG_CC_OPTIMIZE_FOR_SIZE segfaults
--- Comment #18 from kevin dot bowling at kev009 dot com 2010-06-19 00:07 --- Does it make sense for the default and distros to use an -Os kernel with modern systems (i.e. 2M-8M cache). If gcc 4.5 won't inline this at -Os, I wonder what other bad decisions are being made. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44129
[Bug c++/41090] [4.3/4.4/4.5/4.6 Regression] Using static label reference in c++ class constructor produces wrong code
--- Comment #12 from danglin at gcc dot gnu dot org 2010-06-19 00:28 --- Subject: Bug 41090 Author: danglin Date: Sat Jun 19 00:28:18 2010 New Revision: 161018 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161018 Log: PR c++/41090 * g++.dg/ext/label13.C: xfail on 32-bit hppa*-*-hpux*. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/ext/label13.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41090
[Bug fortran/44584] gfortran.dg/typebound_proc_15.f03 failed
--- Comment #6 from hjl dot tools at gmail dot com 2010-06-19 00:47 ---
(In reply to comment #5)
Ok, actually I also get an ICE. But for some reason only when compiling by
hand, not in the testsuite.
It is fixed by this patch:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 160948)
+++ gcc/fortran/resolve.c (working copy)
@@ -10850,7 +10850,7 @@
c-ts.u.cl = cl;
}
}
- else if (c-ts.interface-name[0] != '\0' !sym-attr.vtype)
+ else if (!sym-attr.vtype c-ts.interface-name[0] != '\0')
{
gfc_error (Interface '%s' of procedure pointer component
'%s' at %L must be explicit, c-ts.interface-name,
Does this fix the issue for you?
It will be while before I can check it on ia64. However if your patch fixes
valgrind issue on x86, it won't hurt to check it in. Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44584
[Bug target/44588] New: Very inefficient 8bit mod/div
On x86, I got
[...@gnu-6 divb]$ cat umod-2.c
extern unsigned char z;
unsigned char
foo (unsigned char x, unsigned char y)
{
z = x/y;
return x % y;
}
[...@gnu-6 divb]$ gcc -S -O3 umod-2.c
[...@gnu-6 divb]$ cat umod-2.s
.file umod-2.c
.text
.p2align 4,,15
.globl foo
.type foo, @function
foo:
.LFB0:
.cfi_startproc
movzbl %dil, %edi
movzbl %sil, %ecx
xorl%edx, %edx
movl%edi, %eax
divb%sil
movb%al, z(%rip)
movl%edi, %eax
divw%cx
movl%edx, %eax
ret
--
Summary: Very inefficient 8bit mod/div
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44588
[Bug target/44588] Very inefficient 8bit mod/div
--- Comment #1 from hjl dot tools at gmail dot com 2010-06-19 00:52 --- Created an attachment (id=20941) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20941action=view) A patch With this patch, I got foo: .LFB0: .cfi_startproc movl%edi, %eax divb%sil movb%al, z(%rip) movsbl %ah, %eax ret -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44588
[Bug fortran/44477] Sequential I/O with END FILE: File position should be at EoF
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2010-06-19 00:58 --- Subject: Bug 44477 Author: jvdelisle Date: Sat Jun 19 00:58:28 2010 New Revision: 161020 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161020 Log: 2010-06-18 Jerry DeLisle jvdeli...@gcc.gnu.org PR libfortran/44477 * io/file_pos.c (st_endfile): Add check for ENDFILE when file is already positioned after the EOF marker. Use find_or_create_unit instead of find_unit. If unit is not connected, connect it and create the file with default settings. * io/transfer.c (data_transfer_init): Add check for attempted READ or WRITE when file is already positioned after the EOF marker. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/file_pos.c trunk/libgfortran/io/transfer.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44477
[Bug fortran/44477] Sequential I/O with END FILE: File position should be at EoF
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2010-06-19 01:05 --- Subject: Bug 44477 Author: jvdelisle Date: Sat Jun 19 01:05:05 2010 New Revision: 161021 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161021 Log: 2010-06-18 Jerry DeLisle jvdeli...@gcc.gnu.org PR libfortran/44477 * gfortran.dg/eof_3.f90 * gfortran.dg/endfile_2.f90 * gfortran.dg/endfile_4.f90 * gfortran.dg/endfile_3.f90 Added: trunk/gcc/testsuite/gfortran.dg/endfile_3.f90 trunk/gcc/testsuite/gfortran.dg/endfile_4.f90 Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/endfile_2.f90 trunk/gcc/testsuite/gfortran.dg/eof_3.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44477
