[Bug fortran/36825] F2008: libgfortran I/O+intrinsics: Rank 7 arrays [will break presumably break library ABI]
--- Comment #8 from burnus at gcc dot gnu dot org 2008-07-28 06:41 --- I see only one place in the I/O library that uses GFC_DTYPE_RANK_MASK. There are many many places in the intrinsics. Hmm, true. Maybe one should disable the rank 15 in the frontend again. I see GFC_DESCRIPTOR used in: associated.c, cshift0.c, date_and_time.c, eoshift0.c, eoshift2.c, iso_c_binding.c, move_alloc.c, pack_generic.c, random.c, reshape_generic.c, size.c, spread_generic.c, stat.c, transpose_generic.c, unpack_generic.c, transfer.c, unit.c, in_pack_generic.c, in_unpack_generic.c, cshift1.m4, eoshift1.m4, eoshift3.m4, iforeach.m4, ifunction_logical.m4, ifunction.m4, in_pack.m4, in_unpack.m4, matmull.m4, matmul.m4, pack.m4, reshape.m4, shape.m4, spread.m4, transpose.m4, unpack.m4. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Summary|F2008: I/O with rank 7|F2008: libgfortran |arrays [will break |I/O+intrinsics: Rank 7 |presumably break library|arrays [will break |ABI]|presumably break library ||ABI] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36825
[Bug c++/36767] [4.3/4.4 Regression] Segmentation fault with -fprofile-arcs -O2
--- Comment #10 from dodji at gcc dot gnu dot org 2008-07-28 07:19 --- Created an attachment (id=15968) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15968action=view) try scanning DECL_EXPR instead of VAR_DECLs directly. @Jason: I have tried scanning DECL_EXPR and setting only VAR_DECL that are children of DECL_EXPR. It does not work. This patch is what I have done. Maybe I have done something bad ? My understanding is that by walking DECL_EXPRs and getting their associated VAR_DECL (using DECL_EXPR_DECL), all VAR_DECLs should be touched because every single variable must be declared at least once. So, are there cases where a VAR_DECL has never had a parent DECL_EXPR ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36767
[Bug fortran/36825] F2008: libgfortran I/O+intrinsics: Rank 7 arrays [will break presumably break library ABI]
--- Comment #9 from tkoenig at gcc dot gnu dot org 2008-07-28 09:46 --- See http://gcc.gnu.org/wiki/ArrayDescriptorUpdate -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added CC||tkoenig at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-07-28 09:46:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36825
[Bug fortran/36931] unneeded temporary for array intrinsic binop scalar
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-07-28 09:52 --- Another test case: $ cat foo.f90 program main real, dimension(2,2) :: a real, dimension(2) :: b call random_number(a) b = sum(a,dim=1) + 0.4 end program main $ gfortran -Warray-temporaries foo.f90 foo.f90:5.6: b = sum(a,dim=1) + 0.4 1 Warning: Creating array temporary at (1) -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Summary|unneeded temporary |unneeded temporary for array ||intrinsic binop scalar http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36931
[Bug fortran/36933] unneeded temporary with derived type containing an array as argument
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-07-28 10:38 --- No temporary is done if the first argument of the matmul intrinsic is a (3,3) array. Interesting. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Summary|unneeded temporary |unneeded temporary with ||derived type containing an ||array as argument http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36933
[Bug fortran/36915] Unneccessary array temporary for same_array_ptr = const * same_array_ptr
--- Comment #4 from tkoenig at gcc dot gnu dot org 2008-07-28 10:38 --- Confirmed. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-07-28 10:38:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36915
[Bug fortran/36874] Add shape checks to cshift/eoshift
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-07-28 10:48 --- Why a run-time check? AFAIK, we can always determine the rank at runtime, so unless somebody messes with our array descriptors big time, we should be safe. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added CC||tkoenig at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-07-28 10:48:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36874
[Bug c++/36767] [4.3/4.4 Regression] Segmentation fault with -fprofile-arcs -O2
--- Comment #11 from dodji at gcc dot gnu dot org 2008-07-28 10:52 --- Created an attachment (id=15969) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15969action=view) update vars more specifically, adding BIND_EXPR After talking with Jakub, it appeared that I was forgetting to update VAR_DECLS that were attached to a BIND_EXPR. Walking those VAR_DECLS appears to fix the problem. Regtesting now. Will update the patch with a proper testcase when regtesting passes. Please feel free to comment in the meantime. -- dodji at gcc dot gnu dot org changed: What|Removed |Added Attachment #15968|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36767
[Bug middle-end/32581] make profiledbootstrap - stageprofile - gcc/ada/a-except.adb:1301: error: control flow in the middle of basic block 20
--- Comment #8 from tim at bishnet dot net 2008-07-28 10:52 --- For what it's worth, I just wanted to add a me too. I'm building on Solaris 9 sparc using gcc 4.2.4 to build with. The error occurs with 4.3.1 and the 20080724 snapshot. /u1/src/garstow/devel/gcc/work/build/./prev-gcc/xgcc -B/u1/src/garstow/devel/gcc/work/build/./prev-gcc/ -B/usr/local/sparc-sun-solaris2.9/bin/ -c -g -O2 -fprofile-generate -gnatpg -gnata -g -O1 -fno-inline \ -nostdinc -I- -I. -Iada -I../../../work/gcc-4.3-20080724/gcc/ada ../../../work/gcc-4.3-20080724/gcc/ada/a-except.adb -o ada/a-except.o ../../../work/gcc-4.3-20080724/gcc/ada/a-except.adb: In function 'Ada.Exceptions.Raise_From_Controlled_Operation': ../../../work/gcc-4.3-20080724/gcc/ada/a-except.adb:1305: error: control flow in the middle of basic block 20 ../../../work/gcc-4.3-20080724/gcc/ada/a-except.adb:1305: error: control flow in the middle of basic block 20 ../../../work/gcc-4.3-20080724/gcc/ada/a-except.adb:1305: error: control flow in the middle of basic block 20 ../../../work/gcc-4.3-20080724/gcc/ada/a-except.adb:1305: error: control flow in the middle of basic block 20 ../../../work/gcc-4.3-20080724/gcc/ada/a-except.adb:1305: error: control flow in the middle of basic block 20 +===GNAT BUG DETECTED==+ | 4.3.2 20080724 (prerelease) (sparc-sun-solaris2.9) GCC error:| | verify_flow_info failed | | Error detected around ../../../work/gcc-4.3-20080724/gcc/ada/a-except.adb:1305| | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:398 make[4]: *** [ada/a-except.o] Error 1 make[4]: Leaving directory `/u1/src/garstow/devel/gcc/work/build/gcc' make[3]: *** [all-stageprofile-gcc] Error 2 make[3]: Leaving directory `/u1/src/garstow/devel/gcc/work/build' make[2]: *** [stageprofile-bubble] Error 2 make[2]: Leaving directory `/u1/src/garstow/devel/gcc/work/build' make[1]: *** [profiledbootstrap] Error 2 make[1]: Leaving directory `/u1/src/garstow/devel/gcc/work/build' make: *** [build-work/build/Makefile] Error 2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32581
[Bug tree-optimization/36952] New: Optimizer generates faulty assembler code when estimating max. floating point value in a for loop
Hello, I am working on a larger project processing audio signals in double format. As I needed to estimate the max. Amplitude of a buffer, it returned a faulty value. I debugged the assembler code and realized, that the optimizer created a faulty computation of the maximum. By only changing one instruction, the computation is correct. I've reduced the code to a minimum of code supplementing function calls that fill the buffer with a simple memcpy function. The code is standalone. I'll include the factor.ii which is also a command line program demonstrating the error. I've compiled it with the command line found below. I also tried out leaving the compiler flag -march=i686 away. It just changed my assembler code but didn't get rid of the error. Further down I'll include my analysis of the assembler code. g++ -o factor -Wall -v -O2 -march=i686 factor.cpp: Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --disable-libmudflap --enable-targets=all --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.2.3 (Debian 4.2.3-3) /usr/lib/gcc/i486-linux-gnu/4.2.3/cc1plus -E -quiet -v -D_GNU_SOURCE factor.cpp -march=i686 -Wall -O2 -fpch-preprocess -o factor.ii ignoring nonexistent directory /usr/local/include/i486-linux-gnu ignoring nonexistent directory /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../i486-linux-gnu/include ignoring nonexistent directory /usr/include/i486-linux-gnu #include ... search starts here: #include ... search starts here: /usr/include/c++/4.2 /usr/include/c++/4.2/i486-linux-gnu /usr/include/c++/4.2/backward /usr/local/include /usr/lib/gcc/i486-linux-gnu/4.2.3/include /usr/include End of search list. /usr/lib/gcc/i486-linux-gnu/4.2.3/cc1plus -fpreprocessed factor.ii -quiet -dumpbase factor.cpp -march=i686 -auxbase factor -O2 -Wall -version -o factor.s GNU C++ version 4.2.3 (Debian 4.2.3-3) (i486-linux-gnu) compiled by GNU C version 4.2.3 (Debian 4.2.3-3). GGC heuristics: --param ggc-min-expand=45 --param ggc-min-heapsize=29241 Compiler executable checksum: f63294e1c8ecc1bf2473a5bae1642fbe as -V -Qy -o factor.o factor.s GNU assembler version 2.18.0 (i486-linux-gnu) using BFD version (GNU Binutils for Debian) 2.18.0.20080103 /usr/lib/gcc/i486-linux-gnu/4.2.3/collect2 --eh-frame-hdr -m elf_i386 --hash-style=both -dynamic-linker /lib/ld-linux.so.2 -o factor /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/crt1.o /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/crti.o /usr/lib/gcc/i486-linux-gnu/4.2.3/crtbegin.o -L/usr/lib/gcc/i486-linux-gnu/4.2.3 -L/usr/lib/gcc/i486-linux-gnu/4.2.3 -L/usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/i486-linux-gnu/4.2.3/../../.. factor.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/i486-linux-gnu/4.2.3/crtend.o /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/crtn.o The optimizer generates the error with the following line of code: for (unsigned long i = 0; i insize; ++i) _factor = std::max(_factor, std::max(-data[i], data[i])); with double * data; (Audio Data) unsigned long insize; (number of doubles in the buffer) double _factor; (currently estimated, global factor) Generated Assembler code from factor.s: // Load data Buffer pointer to eax movl-36(%ebp), %eax // Clear edx (that's our i) xorl%edx, %edx // Load _factor on FP-Stack fldl(%esi) // Have _factor twice on the FP-Stack (Stack: (original)_factor, (current)_factor) fld %st(0) // Start the for-loop jmp .L45 .p2align 4,,7 .L64: // This at the beginning of every iteration i = 1 // This is the actual consistency error // At this pointer we have the following on the FP-Stack: st(0): _factor(current), st(1): _factor(original) // After executing this, we'll have st(0): _factor(original), st(1): _factor(current), which creates a problem further down // To show what is actually going wrong, I'll label _factor fxch%st(1) .L45: fldl(%eax) fchs fstl-16(%ebp) fldl(%eax) fucomi %st(1), %st fcmovbe %st(1), %st fstp%st(1) fucomi %st(2), %st fstp%st(2) fxch%st(1) fcmovbe %st(1), %st addl$1, %edx addl$8, %eax cmpl%ebx, %edx jne .L64 fstp%st(1) fstpl (%esi) .L43: cmpb$0, 8(%esi) je .L53 -- Summary: Optimizer generates faulty assembler code when estimating max. floating point value in a for loop
[Bug fortran/36652] Internal compiler error: in gfc_conv_expr
--- Comment #2 from j dot wookey at bristol dot ac dot uk 2008-07-28 11:02 --- Updating gfortran to 4.4.0 (20080728) on i386-apple-darwin9.4.0 fixes problem. Thanks for looking at it! -- j dot wookey at bristol dot ac dot uk changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36652
[Bug tree-optimization/36953] New: Optimizer generates faulty assembler code when estimating max. floating point value in a for loop
Hello, I am working on a larger project processing audio signals in double format. As I needed to estimate the max. Amplitude of a buffer, it returned a faulty value. I debugged the assembler code and realized, that the optimizer created a faulty computation of the maximum. By only changing one instruction, the computation is correct. I've reduced the code to a minimum of code supplementing function calls that fill the buffer with a simple memcpy function. The code is standalone. I'll include the factor.ii which is also a command line program demonstrating the error. I've compiled it with the command line found below. I also tried out leaving the compiler flag -march=i686 away. It just changed my assembler code but didn't get rid of the error. Further down I'll include my analysis of the assembler code. g++ -o factor -Wall -v -O2 -march=i686 factor.cpp: Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --disable-libmudflap --enable-targets=all --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.2.3 (Debian 4.2.3-3) /usr/lib/gcc/i486-linux-gnu/4.2.3/cc1plus -E -quiet -v -D_GNU_SOURCE factor.cpp -march=i686 -Wall -O2 -fpch-preprocess -o factor.ii ignoring nonexistent directory /usr/local/include/i486-linux-gnu ignoring nonexistent directory /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../i486-linux-gnu/include ignoring nonexistent directory /usr/include/i486-linux-gnu #include ... search starts here: #include ... search starts here: /usr/include/c++/4.2 /usr/include/c++/4.2/i486-linux-gnu /usr/include/c++/4.2/backward /usr/local/include /usr/lib/gcc/i486-linux-gnu/4.2.3/include /usr/include End of search list. /usr/lib/gcc/i486-linux-gnu/4.2.3/cc1plus -fpreprocessed factor.ii -quiet -dumpbase factor.cpp -march=i686 -auxbase factor -O2 -Wall -version -o factor.s GNU C++ version 4.2.3 (Debian 4.2.3-3) (i486-linux-gnu) compiled by GNU C version 4.2.3 (Debian 4.2.3-3). GGC heuristics: --param ggc-min-expand=45 --param ggc-min-heapsize=29241 Compiler executable checksum: f63294e1c8ecc1bf2473a5bae1642fbe as -V -Qy -o factor.o factor.s GNU assembler version 2.18.0 (i486-linux-gnu) using BFD version (GNU Binutils for Debian) 2.18.0.20080103 /usr/lib/gcc/i486-linux-gnu/4.2.3/collect2 --eh-frame-hdr -m elf_i386 --hash-style=both -dynamic-linker /lib/ld-linux.so.2 -o factor /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/crt1.o /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/crti.o /usr/lib/gcc/i486-linux-gnu/4.2.3/crtbegin.o -L/usr/lib/gcc/i486-linux-gnu/4.2.3 -L/usr/lib/gcc/i486-linux-gnu/4.2.3 -L/usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/i486-linux-gnu/4.2.3/../../.. factor.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/i486-linux-gnu/4.2.3/crtend.o /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/crtn.o The optimizer generates the error with the following line of code: for (unsigned long i = 0; i insize; ++i) _factor = std::max(_factor, std::max(-data[i], data[i])); with double * data; (Audio Data) unsigned long insize; (number of doubles in the buffer) double _factor; (currently estimated, global factor) Generated Assembler code from factor.s: // Load data Buffer pointer to eax movl-36(%ebp), %eax // Clear edx (that's our i) xorl%edx, %edx // Load _factor on FP-Stack fldl(%esi) // Have _factor twice on the FP-Stack (Stack: (original)_factor, (current)_factor) fld %st(0) // Start the for-loop jmp .L45 .p2align 4,,7 .L64: // This at the beginning of every iteration i = 1 // This is the actual consistency error // At this pointer we have the following on the FP-Stack: st(0): (current)_factor, st(1): (original)_factor // After executing this, we'll have st(0): (original)_factor, st(1): (current)_factor, which creates a problem further down // To show what is actually going wrong, I'll label _factor // with original for the original factor that was present when the // for-loop was started and current for the value, that is actually the // correct factor. // Note: To fix the bug, this instruction needs to be fstl %st(1) to have // the current factors in BOTH st(0) and st(1) fxch%st(1) .L45: // Load the Value from the current data Buffer Position onto the stack // FP-Stack: st(0): data[i], st(1): (orig)_factor, st(2): (curr)_factor fldl(%eax) // Negate // FP-Stack: st(0): -data[i], st(1): (orig)_factor, st(2): (curr)_factor fchs // Safe -data[i] to ??? - (why???) fstl-16(%ebp) //
[Bug tree-optimization/36953] Optimizer generates faulty assembler code when estimating max. floating point value in a for loop
--- Comment #1 from tcm dot home at gmx dot de 2008-07-28 11:15 --- Created an attachment (id=15970) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15970action=view) File generated with g++ -o factor -v -save-temps -Wall -O2 -march=i686 factor.cpp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36953
[Bug fortran/36874] Add shape checks to cshift/eoshift
--- Comment #3 from burnus at gcc dot gnu dot org 2008-07-28 11:21 --- Why a run-time check? Because the shape might not be known at compile time? And a compile-time check because compile-time checks are nicer ;-) AFAIK, we can always determine the rank at runtime Yes, the RANK should be known (even) at compile time, but the SHAPE might be only be known at run time. (Shape = how many elements per dimension; rank = number of dimensions.) (By the way, the rank is already checked.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36874
[Bug fortran/36652] Internal compiler error: in gfc_conv_expr
-- dfranke at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36652
[Bug tree-optimization/36952] Optimizer generates faulty assembler code when estimating max. floating point value in a for loop
--- Comment #1 from tcm dot home at gmx dot de 2008-07-28 11:49 --- *** This bug has been marked as a duplicate of 36953 *** -- tcm dot home at gmx dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36952
[Bug tree-optimization/36953] Optimizer generates faulty assembler code when estimating max. floating point value in a for loop
--- Comment #2 from tcm dot home at gmx dot de 2008-07-28 11:49 --- *** Bug 36952 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36953
[Bug bootstrap/36908] bootstrap forever with BOOT_CFLAGS=-O2 -ftree-loop-distribution
--- Comment #1 from tomby at gcc dot gnu dot org 2008-07-28 11:53 --- Created an attachment (id=15971) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15971action=view) Testcase where loop distribution enabled makes run of binary forever Compilation with CFLAGS=-O2 and running of testcase is ok (it finish). Compilation with CLFLAGS=-O2 -ftree-loop-distribution and running testcase makes it run forever (last loop cycles). Inlined loop from free_alt_states is wrongly distributed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36908
[Bug target/36919] [4.4 regression] Bootstrap failure on IRIX 6.5: unrecognizable insn in errors.c
--- Comment #1 from michael dot a dot richmond at nasa dot gov 2008-07-28 12:23 --- I get the same error in gcc-4.4-20080725 under MIPS Linux. My last successful bootstrap was 20080718. -- michael dot a dot richmond at nasa dot gov changed: What|Removed |Added CC||michael dot a dot richmond ||at nasa dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36919
[Bug c++/36954] New: Wrong warning with -Wlogical-op
compiling the following functions with g++ -Wlogical-op leads to a wrong
warning
-
templateclass C void Test()
{
if ((1 == 2) || (true)) { // warning: logical #8216;||#8217; with
non-zero constant will always evaluate as true
}
if ((1 == 2) || (!false)) {
}
if (false || true) {
}
}
int main() {
if ((1 == 2) || (true)) {
}
}
-
Warning occurs only in the first if inside the template.
g++-4.3 -v
Using built-in specs.
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --with-local-prefix=/usr/local
--infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64
--libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.3
--enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/
--with-pkgversion='SUSE Linux' --disable-libgcj --with-slibdir=/lib64
--with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new
--disable-libstdcxx-pch --program-suffix=-4.3
--enable-version-specific-runtime-libs --enable-linux-futex
--without-system-libunwind --with-cpu=generic --build=x86_64-suse-linux
Thread model: posix
gcc version 4.3.2 20080715 (prerelease) [gcc-4_3-branch revision 137837] (SUSE
Linux)
--
Summary: Wrong warning with -Wlogical-op
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: olaf at bonorden dot de
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=36954
[Bug tree-optimization/36953] Optimizer generates faulty assembler code when estimating max. floating point value in a for loop
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-07-28 13:12 --- I can reproduce this with 4.2.4, but not with 4.1.3 or 4.3.1. -fno-strict-aliasing fixes it, so I suspect it's a dup of one of the known wrong-code bugs with GCC 4.2.x -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.2.4 Known to work||4.1.3 4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36953
[Bug target/36919] [4.4 regression] Bootstrap failure on IRIX 6.5: unrecognizable insn in errors.c
--- Comment #2 from hjl dot tools at gmail dot com 2008-07-28 13:42 --- Have you tried revision 138154 or newer? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36919
[Bug target/36919] [4.4 regression] Bootstrap failure on IRIX 6.5: unrecognizable insn in errors.c
--- Comment #3 from michael dot a dot richmond at nasa dot gov 2008-07-28 13:49 --- (In reply to comment #2) Have you tried revision 138154 or newer? I don't know what that is -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36919
[Bug c++/36767] [4.3/4.4 Regression] Segmentation fault with -fprofile-arcs -O2
--- Comment #12 from jakub at gcc dot gnu dot org 2008-07-28 15:00 ---
There are unneeded {} pairs, when there is just one statement in for/if, you
should just write
if (something)
DECL_CONTEXT (x) = current_function_decl;
and similar for
for (.)
if (something)
DECL_CONTEXT (var) = current_function_decl.
Also, I think it is unnecessary to pass current_function_decl as data to the
callback, current_function_decl is accessible in the callback too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36767
[Bug tree-optimization/36792] [4.4 Regression] Revision 137631 causes many failures
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-07-28 15:35 --- They have been all XFAILed, with the tuples merge we now get XPASS: gcc.dg/tree-ssa/data-dep-1.c scan-tree-dump-times ltrans 4, \\+, 1 0 XPASS: gcc.dg/tree-ssa/ltrans-3.c scan-tree-dump-times ltrans transformed loop 1 XPASS: gcc.dg/tree-ssa/ssa-fre-13.c scan-tree-dump fre Inserted .* a XPASS: gcc.dg/tree-ssa/ssa-fre-13.c scan-tree-dump fre Replaced tmp1_.\\(D\\)-data XPASS: gcc.dg/tree-ssa/ssa-fre-14.c scan-tree-dump fre Inserted .* a XPASS: gcc.dg/tree-ssa/ssa-fre-14.c scan-tree-dump fre Replaced tmp1.data XPASS: gcc.dg/tree-ssa/ssa-fre-17.c scan-tree-dump fre Replaced f.doms\\[0\\].dom with i_ instead which leaves FAIL: gcc.dg/tree-ssa/ssa-fre-7.c scan-tree-dump-times fre Inserted pretmp 1 FAIL: gcc.dg/tree-ssa/ssa-fre-7.c scan-tree-dump-times fre Replaced a.u.f with pretmp 3 FAIL: gcc.dg/tree-ssa/ssa-fre-7.c scan-tree-dump-times fre Replaced a.u.k with j 1 FAIL: gcc.dg/tree-ssa/ssa-fre-7.c scan-tree-dump fre = VIEW_CONVERT_EXPRfloat\\(j_ FAIL: gcc.dg/tree-ssa/ssa-fre-7.c scan-tree-dump optimized return j FAIL: gcc.dg/tree-ssa/ssa-fre-8.c scan-tree-dump-times fre Replaced u.f with pretmp 2 FAIL: gcc.dg/tree-ssa/ssa-fre-8.c scan-tree-dump-times fre Inserted pretmp 2 FAIL: gcc.dg/tree-ssa/ssa-fre-9.c scan-tree-dump-times fre Eliminated: 1 2 FAIL: gcc.dg/tree-ssa/ssa-fre-9.c scan-tree-dump-times fre Insertions: 1 2 FAIL: gcc.dg/tree-ssa/ssa-pre-15.c scan-tree-dump optimized = 0; unfixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||xfail http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36792
[Bug tree-optimization/36766] [4.4 Regression] natGC.cc:229: internal compiler error: Segmentation fault
--- Comment #20 from rguenth at gcc dot gnu dot org 2008-07-28 16:15 --- I can reproduce this on the trunk after the tuples merge (i686). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2008-07-20 11:15:21 |2008-07-28 16:15:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36766
[Bug target/36919] [4.4 regression] Bootstrap failure on IRIX 6.5: unrecognizable insn in errors.c
--- Comment #4 from michael dot a dot richmond at nasa dot gov 2008-07-28 16:23 --- (In reply to comment #2) Have you tried revision 138154 or newer? Revision 138154 fixed the problem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36919
[Bug c++/36767] [4.3/4.4 Regression] Segmentation fault with -fprofile-arcs -O2
--- Comment #13 from dodji at gcc dot gnu dot org 2008-07-28 17:01 --- Created an attachment (id=15972) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15972action=view) reworked patch Reworked patch to walk BIND_EXPR_VARs only. I think there is no need to walk VAR_DECLs via DECL_EXPR() if we walk BIND_EXPR_VARs. The patch seems to work, regtested on trunk, x86_64. @jakub: thanks for your comments. I did fix the patch accordingly. -- dodji at gcc dot gnu dot org changed: What|Removed |Added Attachment #15957|0 |1 is obsolete|| Attachment #15969|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36767
[Bug target/36955] New: TLS LIBCALL change breaks libstdc++ built with older binutils
This testcase (yes, it's actually huge):
#include iostream
int
main ()
{
std::cerr writing to cerr std::endl;
}
segfaults in libstdc++ when powerpc-linux mainline GCC is configured with
--enable-secureplt and uses 2.16 binutils (specifically, I used 2.16.91.0.5
20051219 (SUSE Linux)). It works fine with 2.18 binutils or without
--enable-secureplt.
The failure begins with this patch:
http://gcc.gnu.org/viewcvs?view=revrev=135961
r135961 | zadeck | 2008-05-26 23:37:05 + (Mon, 26 May 2008) | 14 lines
2008-05-26 Steven Bosscher [EMAIL PROTECTED]
* config/rs6000/rs6000.c (rs6000_legitimize_tls_address): Generate
new tls_gd_* and tls_ld_* insns instead of an insn sequence.
* config/rs6000/rs6000.md (TLSmode, tls_abi_suffix, tls_insn_suffix,
tls_sysv_suffix): New mode and mode attribute iterators.
(tls_gd_32, tls_gd_64, tls_ld_32, tls_ld_64): Remove.
(lts_gd_aix*, tls_gd_sysv*, tls_ld_aix*, tls_ld_sysv*): New patterns.
(tls_dtprel_*, tls_dtprel_ha_*, tls_dtprel_lo_*, tls_got_dtprel_*,
tls_tprel_*, tls_tprel_ha_*, tls_tprel_lo_*, tls_got_tprel_*,
tls_tls_*): Merge 32 bit and 64 bit variants using aforementioned
iterators.
--
Summary: TLS LIBCALL change breaks libstdc++ built with older
binutils
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janis at gcc dot gnu dot org
GCC target triplet: powerpc-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36955
[Bug target/36955] TLS LIBCALL change breaks libstdc++ built with older binutils
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-07-28 17:47 --- Blah. This makes little sense really though, the generated code should be exactly the same before and after. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36955
[Bug tree-optimization/36956] New: [4.4 Regression] Revision 138207 causes some regressions
On Linux/x86, revision 138207 causes +FAIL: gcc.dg/format/bitfld-1.c -DWIDE (test for excess errors) +FAIL: gcc.dg/format/bitfld-1.c (test for excess errors) +FAIL: gcc.dg/matrix/matrix-1.c scan-ipa-dump-times matrix-reorg Flattened 3 dimensions 1: dump file does not exist +FAIL: gcc.dg/matrix/matrix-2.c scan-ipa-dump-times matrix-reorg Flattened 2 dimensions 1: dump file does not exist +FAIL: gcc.dg/matrix/matrix-3.c scan-ipa-dump-times matrix-reorg Flattened 2 dimensions 1: dump file does not exist +FAIL: gcc.dg/matrix/matrix-4.c scan-ipa-dump-times matrix-reorg Flattened 0: dump file does not exist +FAIL: gcc.dg/matrix/matrix-5.c scan-ipa-dump-times matrix-reorg Flattened 0: dump file does not exist +FAIL: gcc.dg/matrix/matrix-6.c scan-ipa-dump-times matrix-reorg Flattened 2 dimensions 1: dump file does not exist +FAIL: gcc.dg/matrix/transpose-1.c scan-ipa-dump-times matrix-reorg Flattened 3 dimensions 1: dump file does not exist +FAIL: gcc.dg/matrix/transpose-1.c scan-ipa-dump-times matrix-reorg Transposed 3: dump file does not exist +FAIL: gcc.dg/matrix/transpose-2.c scan-ipa-dump-times matrix-reorg Flattened 3 dimensions 1: dump file does not exist +FAIL: gcc.dg/matrix/transpose-2.c scan-ipa-dump-times matrix-reorg Transposed 0: dump file does not exist +FAIL: gcc.dg/matrix/transpose-3.c scan-ipa-dump-times matrix-reorg Flattened 2 dimensions 1: dump file does not exist +FAIL: gcc.dg/matrix/transpose-3.c scan-ipa-dump-times matrix-reorg Transposed 2: dump file does not exist +FAIL: gcc.dg/matrix/transpose-4.c scan-ipa-dump-times matrix-reorg Flattened 3 dimensions 1: dump file does not exist +FAIL: gcc.dg/matrix/transpose-4.c scan-ipa-dump-times matrix-reorg Transposed 2: dump file does not exist +FAIL: gcc.dg/matrix/transpose-5.c scan-ipa-dump-times matrix-reorg Flattened 3 dimensions 1: dump file does not exist +FAIL: gcc.dg/matrix/transpose-5.c scan-ipa-dump-times matrix-reorg Transposed 0: dump file does not exist +FAIL: gcc.dg/matrix/transpose-6.c scan-ipa-dump-times matrix-reorg Flattened 3 dimensions 1: dump file does not exist +FAIL: gcc.dg/matrix/transpose-6.c scan-ipa-dump-times matrix-reorg Transposed 0: dump file does not exist -- Summary: [4.4 Regression] Revision 138207 causes some regressions Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization 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=36956
[Bug tree-optimization/36956] [4.4 Regression] Revision 138207 causes some regressions
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-07-28 18:15 --- The matrix ones are expected. I guess you really don't read the mailing list about the trunk being frozen. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36956
[Bug ada/36957] New: ACATS ce3801b ICE emit_move_insn, at expr.c:3381 post tuple merge
Post tuple merge, was working at rev 138205 fails at rev 138209
gnatmake -v -v --GCC=/home/guerby/build/gcc/xgcc -B/home/guerby/build/gcc/
-gnatws -O1 -I/home/guerby/build/gcc/testsuite/ada/acats/support ce3801b.adb
-largs --GCC=/home/guerby/build/gcc/xgcc -B/home/guerby/build/gcc/ -cargs -v
gcc version 4.4.0 20080728 (experimental) [trunk revision 138209] (GCC)
COLLECT_GCC_OPTIONS='-c' '-B/home/guerby/build/gcc/' '-gnatws' '-O1'
'-I/home/guerby/build/gcc/testsuite/ada/acats/support' '-v' '-gnatez'
'-mtune=generic'
/home/guerby/build/gcc/gnat1
-I/home/guerby/build/gcc/testsuite/ada/acats/support -quiet -dumpbase
ce3801b.adb -O1 -gnatws -gnatez -mtune=generic ce3801b.adb -o /tmp/ccJ0tLNs.s
+===GNAT BUG DETECTED==+
| 4.4.0 20080728 (experimental) [trunk revision 138209]
(x86_64-unknown-linux-gnu) GCC error:|
| in emit_move_insn, at expr.c:3381|
| Error detected around
/n/14/guerby/install-trunk/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/adainclude/a-tifiio.adb:316|
(gdb) r -I/home/guerby/build/gcc/testsuite/ada/acats/support -quiet -dumpbase
ce3801b.adb -O1 -gnatws -gnatez -mtune=generic ce3801b.adb
Starting program: /home/guerby/build/gcc/gnat1
-I/home/guerby/build/gcc/testsuite/ada/acats/support -quiet -dumpbase
ce3801b.adb -O1 -gnatws -gnatez -mtune=generic ce3801b.adb
(gdb) r -I/home/guerby/build/gcc/testsuite/ada/acats/support -quiet -dumpbase
ce3801b.adb -O1 -gnatws -gnatez -mtune=generic ce3801b.adb
Starting program: /home/guerby/build/gcc/gnat1
-I/home/guerby/build/gcc/testsuite/ada/acats/support -quiet -dumpbase
ce3801b.adb -O1 -gnatws -gnatez -mtune=generic ce3801b.adb
Breakpoint 1, internal_error (gmsgid=0xdac5dc in %s, at %s:%d) at
../../trunk/gcc/diagnostic.c:629
629 {
(gdb) bt
#0 internal_error (gmsgid=0xdac5dc in %s, at %s:%d) at
../../trunk/gcc/diagnostic.c:629
#1 0x007314cc in fancy_abort (file=value optimized out, line=3381,
function=0xdb7aaf emit_move_insn) at ../../trunk/gcc/diagnostic.c:689
#2 0x007886d4 in emit_move_insn (x=0x2b6f9e60, y=0x2b6f9d40)
at ../../trunk/gcc/expr.c:3380
#3 0x008d4a57 in expand_value_return (val=0x2b6f9d40) at
../../trunk/gcc/stmt.c:1539
#4 0x008d5f00 in expand_return (retval=0x2b7009c0) at
../../trunk/gcc/stmt.c:1723
#5 0x0077abbd in expand_expr_real_1 (exp=0x2b700a00, target=0x0,
tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at
../../trunk/gcc/expr.c:9118
#6 0x00786fe4 in expand_expr_real (exp=0x2b700a00,
target=0x2b5a1b00, tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at
../../trunk/gcc/expr.c:7086
#7 0x008d4cb9 in expand_expr_stmt (exp=0xdac5dc) at
../../trunk/gcc/expr.h:517
#8 0x00c48f78 in expand_gimple_basic_block (bb=0x2b68ed80) at
../../trunk/gcc/cfgexpand.c:1907
#9 0x00c49c7a in gimple_expand_cfg () at
../../trunk/gcc/cfgexpand.c:2218
#10 0x00862575 in execute_one_pass (pass=0x1141da0) at
../../trunk/gcc/passes.c:1282
#11 0x008627a5 in execute_pass_list (pass=0x1141da0) at
../../trunk/gcc/passes.c:1330
#12 0x00932a1c in tree_rest_of_compilation (fndecl=0x2b5b9200) at
../../trunk/gcc/tree-optimize.c:418
#13 0x00a9f1e0 in cgraph_expand_function (node=0x2b5b9b00) at
../../trunk/gcc/cgraphunit.c:1038
#14 0x00aa0e64 in cgraph_optimize () at
../../trunk/gcc/cgraphunit.c:1100
#15 0x00422da9 in gnat_write_global_declarations () at
../../trunk/gcc/ada/utils.c:4208
#16 0x008e46bf in toplev_main (argc=value optimized out, argv=value
optimized out) at ../../trunk/gcc/toplev.c:972
#17 0x2ad1d4ca in __libc_start_main () from /lib/libc.so.6
#18 0x0040474a in _start () at ../sysdeps/x86_64/elf/start.S:113
at -O0 it compiles but the generated code SEGV so wrong-code
--
Summary: ACATS ce3801b ICE emit_move_insn, at expr.c:3381 post
tuple merge
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: wrong-code, ice-on-valid-code
Severity: normal
Priority: P3
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: laurent at guerby dot net
GCC host triplet: x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36957
[Bug ada/36957] ACATS ce3801b ICE emit_move_insn, at expr.c:3381 post tuple merge
--- Comment #1 from laurent at guerby dot net 2008-07-28 18:29 --- (gdb) f 2 #2 0x007886d4 in emit_move_insn (x=0x2b6f9e60, y=0x2b6f9d40) at ../../trunk/gcc/expr.c:3380 3380 gcc_assert (mode != BLKmode (gdb) debug_rtx(x) Undefined command: debug_rtx. Try help. (gdb) call debug_rtx(x) (reg:QI 64 [ result ]) (gdb) call debug_rtx(y) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36957
[Bug ada/36957] ACATS ce3801b ICE emit_move_insn, at expr.c:3381 post tuple merge
--- Comment #2 from laurent at guerby dot net 2008-07-28 18:29 --- (reg:HI 59 [ T12b ]) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36957
[Bug fortran/36403] [4.4 Regression] Some fortran tests using eoshift fail on SH
--- Comment #4 from domob at gcc dot gnu dot org 2008-07-28 18:41 --- Thanks for all the hints, Tobias! I've had a look through the F2003 standard about intrinsics taking optional char arguments, and it seems as though PACK and RESHAPE would suffer from the same problem as EOSHIFT does (optional string argument whose type is not even specified as to be always string), and tests showed that here too the call to the library function has one less argument when the optional string argument is not present... This is probably a problem there, too, isn't it? None of those have their own conv_intrinsic_ functions at the moment (for all of them the if matches, as they all return non-scalar values). Is it ok if I try to write one generic conv-function for this case and call it for all the three intrinsics? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36403
[Bug fortran/36403] [4.4 Regression] Some fortran tests using eoshift fail on SH
-- domob at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-06-02 11:29:59 |2008-07-28 18:41:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36403
[Bug tree-optimization/36861] [4.3 Regression] boost's compressed avl confuses GCC
--- Comment #19 from lothar at tradescape dot biz 2008-07-28 18:55 --- Created an attachment (id=15973) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15973action=view) oprofile logs I compiled optimized executables with and without -fno-strict-aliasing and generated an oprofile log for them: /opt2/linux/ix86/bin/g++-4.3.1 -m64 -O3 -no-strict-aliasing -g -I/opt2/linux/x86_64/include/boost-1_35 -DUSE_OPTIMIZATION=0 -o ./avltest-non ./avltest.cpp /opt2/linux/ix86/bin/g++-4.3.1 -m64 -O3 -fno-strict-aliasing -g -I/opt2/linux/x86_64/include/boost-1_35 -DUSE_OPTIMIZATION=0 -o ./avltest-non ./avltest.cpp sudo opcontrol --reset; sudo opcontrol --start; ./avltest-no; ./avltest-non ; sudo opcontrol --stop opannotate --source --assembly --demangle=smart --threshold=1 ./avltest-no ./avltest-no.oprofile.txt opannotate --source --assembly --demangle=smart --threshold=1 ./avltest-non ./avltest-non.oprofile.txt diff -u ./avltest-no.oprofile.txt ./avltest-non.oprofile.txt ./avltest-diff.oprofile.txt $ time ./avltest-non sizeof(Node)=72 sizeof(NodeSet)=40 creating file ./avltest.img done region.get_address()=0x7f4d43ed1000 region.get_size()=3600056 p_set=0x7f4d43ed1000 p_values=0x7f4d43ed1030 created/inserted 5 entries region.get_address()=0x7f4d43b62000 region.get_size()=3600056 p_set=0x7f4d43b62000 p_values=0x7f4d43b62030 checked 5 entries, result=1249975000 real0m0.614s user0m0.140s sys 0m0.016s $ time ./avltest-no sizeof(Node)=72 sizeof(NodeSet)=40 creating file ./avltest.img done region.get_address()=0x7f7fdce43000 region.get_size()=3600056 p_set=0x7f7fdce43000 p_values=0x7f7fdce43030 created/inserted 5 entries region.get_address()=0x7f7fdcad4000 region.get_size()=3600056 p_set=0x7f7fdcad4000 p_values=0x7f7fdcad4030 checked 5 entries, result=1249975000 real0m22.634s user0m22.277s sys 0m0.120s I hope these tests aid in finding the problem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36861
[Bug ada/36957] ACATS ce3801b ICE emit_move_insn, at expr.c:3381 post tuple merge
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-07-28 19:19 --- The problem is that the cast in item = (ce3801b__B_1__fix_io__num___XF_1_10_1_16) iftmp.130; is stripped away. item (QImode) is of type type integer_type 0xb7da3000 ce3801b__B_1__fix_io__num___XF_1_10_1_16 type integer_type 0xb7d9de38 ce3801b__B_1__TfixB___XF_1_10_1_16 sizes-gimplified public HI size integer_cst 0xb7cc055c constant 16 unit size integer_cst 0xb7cc0578 constant 2 align 16 symtab 0 alias set -1 canonical type 0xb7d9de38 precision 16 min integer_cst 0xb7d9e348 -32768 max integer_cst 0xb7d9e47c 32767 RM size integer_cst 0xb7cc055c 16 sizes-gimplified unsigned QI size integer_cst 0xb7cc047c constant 8 unit size integer_cst 0xb7cc0498 constant 1 align 8 symtab 0 alias set 0 canonical type 0xb7da3000 precision 8 min integer_cst 0xb7d9e4d0 16 max integer_cst 0xb7d9e4ec 160 RM size integer_cst 0xb7cc047c 8 and iftmp.130 is of its base-type (HImode). This happens in fold_gimple_assign case GIMPLE_UNARY_RHS: result = fold_unary (subcode, gimple_expr_type (stmt), gimple_assign_rhs1 (stmt)); where gimple_expr_type always returns the base-type and so makes this a no-op cast. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36957
[Bug ada/36957] ACATS ce3801b ICE emit_move_insn, at expr.c:3381 post tuple merge
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-07-28 19:21 --- Mine. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-07-28 19:21:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36957
[Bug fortran/36403] [4.4 Regression] Some fortran tests using eoshift fail on SH
--- Comment #5 from burnus at gcc dot gnu dot org 2008-07-28 20:04 --- and it seems as though PACK and RESHAPE would suffer from the same problem as EOSHIFT does Seems so. I glanced through F2008 CD but I could not find more potential problems. Is it ok if I try to write one generic conv-function for this case and call it for all the three intrinsics? Yes, of cause. Seemingly all of them have the pattern type of the first argument = type of one of the latter arguments. -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36403
[Bug libstdc++/36949] [C++0x] make_shared does not initialize enable_shared_from_this' internal shared_count
--- Comment #3 from jwakely dot gcc at gmail dot com 2008-07-28 20:27 --- (In reply to comment #2) Jonathan, can you have a look? If you can confirm the issue, is it just matter of adding a call to __enable_shared_from_this_helper(_M_refcount, _M_ptr, _M_ptr) to __shared_ptr(_Sp_make_shared_tag, _Alloc, _Args...) ?? Yes, that's the right fix. PS: I'm going to adjust some arguments around from _Alloc to const _Alloc... Cool. Thanks for catching this, Daniel. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36949
[Bug ada/36957] ACATS ce3801b ICE emit_move_insn, at expr.c:3381 post tuple merge
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-07-28 20:33 --- Subject: Bug 36957 Author: rguenth Date: Mon Jul 28 20:32:32 2008 New Revision: 138217 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138217 Log: 2008-07-28 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/36957 * tree-flow.h (tree_ssa_useless_type_conversion): Remove. (useless_type_conversion_p): Remove. (types_compatible_p): Remove. * gimple.h (tree_ssa_useless_type_conversion): Declare. (useless_type_conversion_p): Declare. (types_compatible_p): Declare. (gimple_expr_type): Return the base type only if it is trivially convertible to the subtype. Modified: trunk/gcc/ChangeLog trunk/gcc/gimple.h trunk/gcc/tree-flow.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36957
[Bug ada/36957] ACATS ce3801b ICE emit_move_insn, at expr.c:3381 post tuple merge
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-07-28 20:33 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36957
[Bug target/36955] TLS LIBCALL change breaks libstdc++ built with older binutils
--- Comment #2 from steven at gcc dot gnu dot org 2008-07-28 20:41 --- Like Pinski said: the code before and after the patch should be identical w.r.t. TLS addresses. Without a more specific test case I'm not even going to look at this. -- steven at gcc dot gnu dot org changed: What|Removed |Added CC|stevenb dot gcc at gmail dot| |com | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36955
[Bug translation/36958] New: typos in french translation.
There are many fr.po files in which the word sans has been misleadingly typed
sasn.
:!find . -name fr.po -exec grep -in sasn {} /dev/null \;
./gcc/po/fr.po:18353:msgstr %Jd#65533;claration de #65533; %D #65533; sasn
lien suivant une d#65533;claration externe
./gcc/po/fr.po:21788:msgstr %Hd#65533;claration sasn effet
./gcc/po/fr.po:27906:msgstr %Hd#65533;claration sasn effet
./libcpp/po/fr.po:1471:#~ msgstr %Jd#65533;claration de #65533; %D #65533;
sasn lien suivant une d#65533;claration externe
./libcpp/po/fr.po:5057:#~ msgstr %Hd#65533;claration sasn effet
--
Summary: typos in french translation.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: translation
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dodji at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36958
[Bug translation/36958] typos in french translation.
-- dodji at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-07-28 20:47:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36958
[Bug translation/36958] typos in french translation.
--- Comment #1 from joseph at codesourcery dot com 2008-07-28 20:53 --- Subject: Re: typos in french translation. Translation fixes must go to the language teams. We make no local changes to the .po files, only import unmodified new versions from the TP. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36958
[Bug target/36955] TLS LIBCALL change breaks libstdc++ built with older binutils
--- Comment #3 from janis at gcc dot gnu dot org 2008-07-28 21:17 --- Created an attachment (id=15974) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15974action=view) disassembly of eh_globals.o before aptch File libstdc++-v3/libsupc++/eh_globals.cc is compiled differently before and after the patch. This attachment is from before the patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36955
[Bug target/36955] TLS LIBCALL change breaks libstdc++ built with older binutils
--- Comment #4 from janis at gcc dot gnu dot org 2008-07-28 21:19 --- Created an attachment (id=15975) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15975action=view) disassembly of eh_globals.o after patch This attachment is the disassembly with the patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36955
[Bug target/36955] TLS LIBCALL change breaks libstdc++ built with older binutils
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-07-28 21:28 --- Hmm, is this with the relocs? The first thing I noticed is that the loading of the global address is different. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36955
[Bug target/36955] TLS LIBCALL change breaks libstdc++ built with older binutils
--- Comment #6 from janis at gcc dot gnu dot org 2008-07-28 21:32 --- The attachments are the output of objdump -d (2.16 objdump) of eh_globals.o in the build trees for r135960 and r135961. Let me know if there are things you'd like me to try. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36955
[Bug target/36955] TLS LIBCALL change breaks libstdc++ built with older binutils
--- Comment #7 from janis at gcc dot gnu dot org 2008-07-28 22:26 ---
Smaller testcase, in C:
int*
get_global()
{
static __thread int global;
return global;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36955
[Bug target/36955] [4.4 Regression] TLS LIBCALL change breaks libstdc++ built with older binutils
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-07-28 22:29 --- The difference is the saving/restoring of r30. r30 is not used at all as far as I can tell. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|TLS LIBCALL change breaks |[4.4 Regression] TLS LIBCALL |libstdc++ built with older |change breaks libstdc++ |binutils|built with older binutils Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36955
[Bug translation/36958] typos in french translation.
--- Comment #2 from dodji at gcc dot gnu dot org 2008-07-28 22:40 --- Ah okay. So what is the email address to send the translation fixes to ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36958
[Bug libstdc++/36949] [C++0x] make_shared does not initialize enable_shared_from_this' internal shared_count
--- Comment #4 from paolo dot carlini at oracle dot com 2008-07-28 23:09 --- Thanks, fix forthcoming. -- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle |dot org |dot com Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-07-28 23:09:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36949
[Bug target/36955] [4.4 Regression] TLS LIBCALL change breaks libstdc++ built with older binutils
--- Comment #9 from janis at gcc dot gnu dot org 2008-07-28 23:21 --- The difference is in setting up r30 before branching to __tls_get_addr, which probably uses r30. -- janis at gcc dot gnu dot org changed: What|Removed |Added CC||amodra at gcc dot gnu dot ||org Target Milestone|4.4.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36955
[Bug target/36955] [4.4 Regression] TLS LIBCALL change breaks libstdc++ built with older binutils
--- Comment #10 from pinskia at gcc dot gnu dot org 2008-07-28 23:27 --- From http://sourceware.org/ml/binutils/2005-05/msg00391.html: Also, the ld support doesn't allow registers other than r30 as a GOT pointer. booo. -- Pinski -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36955
[Bug libstdc++/36949] [C++0x] make_shared does not initialize enable_shared_from_this' internal shared_count
--- Comment #5 from paolo at gcc dot gnu dot org 2008-07-28 23:29 --- Subject: Bug 36949 Author: paolo Date: Mon Jul 28 23:28:16 2008 New Revision: 138219 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138219 Log: 2008-07-28 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/36949 * include/tr1_impl/boost_shared_ptr.h (__shared_ptr(_Sp_make_shared_tag, _Alloc, _Args...): Call __enable_shared_from_this_helper. * testsuite/20_util/shared_ptr/creation/36949.cc: New. Added: trunk/libstdc++-v3/testsuite/20_util/shared_ptr/creation/36949.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/tr1_impl/boost_shared_ptr.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36949
[Bug libstdc++/36949] [C++0x] make_shared does not initialize enable_shared_from_this' internal shared_count
--- Comment #6 from paolo dot carlini at oracle dot com 2008-07-28 23:30 --- Fixed. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36949
[Bug c++/36959] New: [4.2/4.3/4.4 Regression] C++ front-end causing a static inline function to be emitted
Take:
static inline int *fromSlotB(void)
{
static int shuf_BZZZ = 1;
return shuf_BZZZ;
}
int main(void)
{
return (int)fromSlotB();
}
--- CUT ---
At -O2, fromSlotB is still being emitted even though it is unused.
It is being marked in cxx_callgraph_analyze_expr:
else if (DECL_CONTEXT (t)
TREE_CODE (DECL_CONTEXT (t)) == FUNCTION_DECL)
/* If we need a static variable in a function, then we
need the containing function. */
mark_decl_referenced (DECL_CONTEXT (t));
For -frepo this might be true but I don't think this is true in general.
This regression was introduced to do unit-at-a-time always for C++:
http://gcc.gnu.org/ml/gcc-patches/2004-07/msg02615.html
--
Summary: [4.2/4.3/4.4 Regression] C++ front-end causing a static
inline function to be emitted
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36959
[Bug c++/36959] [4.2/4.3/4.4 Regression] C++ front-end causing a static inline function to be emitted
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.1.1 4.4.0 Known to work||3.4.0 Target Milestone|--- |4.2.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36959
[Bug c++/36960] New: Reference variable in virtually inherited base corrupted under optimization
Apologies if this is a duplicate: I searched existing reports and found tons
of hits on virtual inheritance and reference, but couldn't find anything
like this. The following program illustrates the problem:
struct Lower {
const int ref;
Lower(const int ref) : ref(ref) { }
};
struct Middle : public virtual Lower {
Middle(const int ref) : Lower(ref) { }
};
struct Upper : public Middle {
Upper(const int ref) : Lower(ref), Middle(ref) { }
int get()
{
return ref;
}
};
int main()
{
int i = 0;
Upper upper(i);
return upper.get();
}
Compiling this using 4.2.2 or 4.2.3 with -O2 or higher causes the resulting
binary to return a non-zero value; 3.4.2 produces a bug-free binary. I've
seen the same effect in more complex code, where gdb gives an obviously wrong
address for the ref member. Dropping to -O fixes the problem, as do several
other changes:
* Making ref an int (as opposed to an int)
* Making Middle inherit non-virtually from Lower
* Accessing ref from Middle instead of Upper
The constness of the reference has no effect.
Issued command-line:
g++ -Wall -W -Wundef -Wpointer-arith -g -O2 VirtuallyInheritedReference.cpp
Full output from running with -v --save-temps is as follows:
g++ -v -save-temps -Wall -W -Wundef -Wpointer-arith -g -O2 -c -o /dev/null
VirtuallyInheritedReference.cpp
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /mnt/taw/usr/Taw/tmp/gcc-4.2.2/configure --prefix=/usr
--disable-nls --libexecdir=/usr/lib --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu --enable-languages=c,c++
--disable-bootstrap
Thread model: posix
gcc version 4.2.2
/usr/lib/gcc/i686-pc-linux-gnu/4.2.2/cc1plus -E -quiet -v -D_GNU_SOURCE
VirtuallyInheritedReference.cpp -mtune=generic -Wall -W -Wundef -Wpointer-arith
-fworking-directory -O2 -fpch-preprocess -o VirtuallyInheritedReference.ii
ignoring nonexistent directory
/usr/lib/gcc/i686-pc-linux-gnu/4.2.2/../../../../i686-pc-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/usr/lib/gcc/i686-pc-linux-gnu/4.2.2/../../../../include/c++/4.2.2
/usr/lib/gcc/i686-pc-linux-gnu/4.2.2/../../../../include/c++/4.2.2/i686-pc-linux-gnu
/usr/lib/gcc/i686-pc-linux-gnu/4.2.2/../../../../include/c++/4.2.2/backward
/usr/local/include
/usr/lib/gcc/i686-pc-linux-gnu/4.2.2/include
/usr/include
End of search list.
/usr/lib/gcc/i686-pc-linux-gnu/4.2.2/cc1plus -fpreprocessed
VirtuallyInheritedReference.ii -quiet -dumpbase VirtuallyInheritedReference.cpp
-mtune=generic -auxbase-strip /dev/null -g -O2 -Wall -W -Wundef -Wpointer-arith
-version -o VirtuallyInheritedReference.s
GNU C++ version 4.2.2 (i686-pc-linux-gnu)
compiled by GNU C version 4.2.2.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 6ba594205d388e98f3b46dee442d61ac
as -V -Qy -o /dev/null VirtuallyInheritedReference.s
GNU assembler version 2.18 (i686-pc-linux-gnu) using BFD version (GNU Binutils)
2.18
Contents of VirtuallyInheritedReference.ii:
# 1 VirtuallyInheritedReference.cpp
# 1 /home/raymond/src/C++/gcc-bugs//
# 1 built-in
# 1 command-line
# 1 VirtuallyInheritedReference.cpp
struct Lower {
int ref;
virtual ~Lower() { }
Lower(int ref) : ref(ref) { }
};
struct Middle : public virtual Lower {
Middle(int ref) : Lower(ref) { }
};
struct Upper : public Middle {
Upper(int ref) : Lower(ref), Middle(ref) { }
int get()
{
return ref;
}
};
int main()
{
int i = 0;
Upper upper(i);
return upper.get();
}
--
Summary: Reference variable in virtually inherited base corrupted
under optimization
Product: gcc
Version: 4.2.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: raymond at corvil dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36960
[Bug c++/36960] Reference variable in virtually inherited base corrupted under optimization
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-07-29 00:01 --- i = 0; upper.D.2127.ref = i; upper.D.2125._vptr$Middle = _ZTV5Upper + 12; return *((struct Lower *) upper + (long unsigned int) *(int *) _ZTV5Upper)-ref; This works on the trunk correctly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36960
[Bug c++/36960] Reference variable in virtually inherited base corrupted under optimization
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-07-29 00:02 --- Likewise for 4.3.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36960
[Bug c++/36943] [c++0x] Use of nested C++0x initializer list for non-aggregate rejected
--- Comment #2 from jason at gcc dot gnu dot org 2008-07-29 00:06 --- Subject: Bug 36943 Author: jason Date: Tue Jul 29 00:06:08 2008 New Revision: 138221 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138221 Log: PR c++/36943 * decl.c (reshape_init_r): Allow C++0x initializer lists. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/g++.dg/cpp0x/initlist1.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36943
[Bug c++/36943] [c++0x] Use of nested C++0x initializer list for non-aggregate rejected
--- Comment #3 from jason at gcc dot gnu dot org 2008-07-29 00:07 --- fixed, thanks. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36943
[Bug target/36955] [4.4 Regression] TLS LIBCALL change breaks libstdc++ built with older binutils
--- Comment #11 from amodra at bigpond dot net dot au 2008-07-29 00:20 --- When -fPIC, r30 needs to be set to point into the .got2 section for the function, so that r30 is valid for the __tls_get_addr plt call stub. Note that this is a different GOT pointer than that used by @[EMAIL PROTECTED], which points into the .got section (as for the -fpic GOT). If there's anything to boo about it's this, rather than using a particular register for .got2 addressing. -fPIC tls really ought to use the .got2 section too. -- amodra at bigpond dot net dot au changed: What|Removed |Added CC|amodra at bigpond dot net | |dot au | Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-07-29 00:20:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36955
[Bug target/36955] [4.4 Regression] TLS LIBCALL change breaks libstdc++ built with older binutils
--- Comment #12 from amodra at bigpond dot net dot au 2008-07-29 00:37
---
So, the easy fix for this bug is (totally untested, not even compiled)
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c (revision 138134)
+++ gcc/config/rs6000/rs6000.c (working copy)
@@ -3940,7 +3940,12 @@ rs6000_legitimize_tls_address (rtx addr,
else if (DEFAULT_ABI == ABI_AIX !TARGET_64BIT)
insn = gen_tls_gd_aix32 (r3, got, addr, tga, const0_rtx);
else if (DEFAULT_ABI == ABI_V4)
- insn = gen_tls_gd_sysvsi (r3, got, addr, tga, const0_rtx);
+ {
+ insn = gen_tls_gd_sysvsi (r3, got, addr, tga, const0_rtx);
+ if (TARGET_SECURE_PLT flag_pic == 2)
+ use_reg (CALL_INSN_FUNCTION_USAGE (insn),
+pic_offset_table_rtx);
+ }
else
gcc_unreachable ();
@@ -3962,7 +3967,12 @@ rs6000_legitimize_tls_address (rtx addr,
else if (DEFAULT_ABI == ABI_AIX !TARGET_64BIT)
insn = gen_tls_ld_aix32 (r3, got, tga, const0_rtx);
else if (DEFAULT_ABI == ABI_V4)
- insn = gen_tls_ld_sysvsi (r3, got, tga, const0_rtx);
+ {
+ insn = gen_tls_ld_sysvsi (r3, got, tga, const0_rtx);
+ if (TARGET_SECURE_PLT flag_pic == 2)
+ use_reg (CALL_INSN_FUNCTION_USAGE (insn),
+pic_offset_table_rtx);
+ }
else
gcc_unreachable ();
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36955
[Bug c++/36961] New: fails to identify template
enum A{a};
enum B{b};
class bottom {};
templatetypename E class attr {
public: E v;
operator E() { return v;}
};
templatetemplatetypename class node, typename attr, typename next
class attrNode : public nodeattr, public next {};
templatetemplatetypename class node
class list1 : public
attrNodenode, A,
attrNodenode, B,
bottom {};
class foo : public list1attr {};
list1attr v1;
foo v2;
templatetypename E, templatetypenameclass node,
templatetemplatetypename class class nodeList
nodeEatt(nodeListnode v) { return v; }
int main() {
A x1 = attA(v1);
B x2 = attB(v1);
A x3 = attA(foo);
}
gets you:
~/ootbc/personal/ivan$ g++ foo.cc
foo.cc: In function int main():
foo.cc:31: error: expected primary-expression before ) token
--
Summary: fails to identify template
Product: gcc
Version: 4.3.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=36961
[Bug c++/36961] fails to identify template
--- Comment #1 from igodard at pacbell dot net 2008-07-29 00:52 ---
Oops - sorry, posted wrong test case:
enum A{a};
enum B{b};
enum C{c};
enum D{d};
class bottom {};
templatetypename E class attr {
public: E v;
operator E() { return v;}
};
templatetemplatetypename class node, typename attr, typename next
class attrNode : public nodeattr, public next {};
templatetemplatetypename class node
class list1 : public
attrNodenode, A,
attrNodenode, B,
bottom {};
class foo : public list1attr {};
list1attr v1;
foo v2;
templatetypename E, templatetypenameclass node,
templatetemplatetypename class class nodeList
nodeEatt(nodeListnode v) { return v; }
int main() {
A x1 = attA(v1);
B x2 = attB(v1);
A x3 = attA(v2);
}
gets you:
~/ootbc/personal/ivan$ g++ foo.cc
foo.cc: In function int main():
foo.cc:33: error: no matching function for call to att(foo)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36961
[Bug c++/36961] fails to identify template
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-07-29 00:53 --- A x3 = attA(foo); foo is a class. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36961
[Bug c++/36961] fails to identify template
--- Comment #3 from igodard at pacbell dot net 2008-07-29 00:54 --- p.s. Comeau likes the (correct, second) test case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36961
[Bug c++/36961] fails to identify template
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-07-29 01:01 --- The error is correct as the type of v2 is foo so it cannot figure out the rest of the template agruments from that type. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36961
[Bug target/36955] [4.4 Regression] TLS LIBCALL change breaks libstdc++ built with older binutils
--- Comment #13 from amodra at bigpond dot net dot au 2008-07-29 01:04 --- Blah, of course that's the wrong place to add the use_reg. Needs to be a few lines lower. I guess I may as well take this bug and go thru a boot/regress cycle. -- amodra at bigpond dot net dot au changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |amodra at bigpond dot net |dot org |dot au Status|NEW |ASSIGNED Last reconfirmed|2008-07-29 00:20:29 |2008-07-29 01:04:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36955
[Bug c++/36961] fails to identify template
--- Comment #5 from igodard at pacbell dot net 2008-07-29 01:07 --- Please confirm that it is an error with your associates. First, Comeau likes it. Second, other template functions have no trouble identifying a template base class given a derived class. What is different about this case is that the base class is one that takes a template rather than a class or constant. Templates taking templates are unusual, and I'd be not surprised that g++ was insufficiently tested in this area. -- igodard at pacbell dot net changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36961
[Bug translation/36958] typos in french translation.
--- Comment #3 from joseph at codesourcery dot com 2008-07-29 02:02 --- Subject: Re: typos in french translation. On Mon, 28 Jul 2008, dodji at gcc dot gnu dot org wrote: Ah okay. So what is the email address to send the translation fixes to ? See the Language-Team entry in the .po file: Language-Team: French [EMAIL PROTECTED]\n -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36958
[Bug c++/36961] fails to identify template
--- Comment #6 from igodard at pacbell dot net 2008-07-29 02:32 --- FWIW, Visual Studio has been reported to me as accepting the test case too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36961
