[Bug fortran/35892] gfortran lost memory blocks
--- Comment #22 from KnowlesPJ at Cardiff dot ac dot uk 2008-04-25 08:10 --- Yes, this was the silver bullet. With Using built-in specs. Target: i386-apple-darwin9.2.2 Configured with: ../configure --prefix=/opt/gcc Thread model: posix gcc version 4.4.0 20080424 (experimental) (GCC) we now get through the regression tests on our code that were failing before. Thank you to those who have contributed to this - the final piece that was needed for our code (http://www.molpro.net) to work with gfortran on both linux and mac. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35892
[Bug middle-end/36041] Speed up builtin_popcountll
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-04-25 08:44 --- The implementation is written so it is also reasonable on targets like the AVR which only has 8bit registers... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36041
[Bug target/36040] Using %rsi instead of %esi for a u32 in generated code
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-04-25 08:42 --- Also the ABI specifies that function arguments in registers are sign/zero extended according to their sign to the full width of the registers, maybe what calles this function is not adhering to this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36040
[Bug middle-end/36013] [4.1/4.3/4.4 Regression] Wrong code involving restricted pointers to non-restricted pointers
--- Comment #2 from jakub at gcc dot gnu dot org 2008-04-25 09:21 --- The alias sets seem to be wrong already in the *.expand dump: (insn 7 6 8 3 pr36013.c:6 (set (reg/f:DI 58 [ D.1430 ]) (mem/f:DI (reg/v/f:DI 59 [ p ]) [4 S8 A64])) -1 (nil)) (insn 8 7 9 3 pr36013.c:6 (set (mem:SI (reg/f:DI 58 [ D.1430 ]) [4 S4 A32]) (const_int 1 [0x1])) -1 (nil)) (insn 9 8 10 3 pr36013.c:7 (set (reg/f:DI 61) (mem/f:DI (reg/v/f:DI 60 [ q ]) [5 S8 A64])) -1 (nil)) (insn 10 9 11 3 pr36013.c:7 (set (mem:SI (reg/f:DI 61) [3 S4 A32]) (const_int 2 [0x2])) -1 (nil)) (insn 11 10 12 3 pr36013.c:8 (set (reg:CCZ 17 flags) (compare:CCZ (mem:SI (reg/f:DI 58 [ D.1430 ]) [4 S4 A32]) (const_int 2 [0x2]))) -1 (nil)) (jump_insn 12 11 13 3 pr36013.c:8 (set (pc) (if_then_else (eq (reg:CCZ 17 flags) (const_int 0 [0x0])) (label_ref 16) (pc))) -1 (expr_list:REG_BR_PROB (const_int 9900 [0x26ac]) (nil))) Note *p and **p uses the same alias set 4 (bad) and *q uses alias set 5 (that's ok, it should be different from *p as they can't alias) and **q uses 3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36013
[Bug tree-optimization/36038] [4.4 Regression] miscompiled loop in perlbmk for -Os
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-04-25 09:24 --- We seem to use some interesting pointer induction variable for the exit test... -fno-ivopts fixes it I suppose. The loop in question ends up being expanded from : # VUSE D.1307_34 = MEM[base: stack_base.2_4, offset: 40]; # SMT.26_42 = VDEF MEM[base: sp_31] = D.1307_34; ivtmp.36_16 = ivtmp.36_25 + -8; : # ivtmp.36_25 = PHI <0B(2), ivtmp.36_16(3)> # SMT.26_37 = PHI D.1372_15 = D.1349_10 + 6; D.1373_17 = (long unsigned int) D.1372_15; D.1374_18 = D.1373_17 * 0x0fff8; D.1375_19 = (long long int *) D.1374_18; if (ivtmp.36_25 != D.1375_19) goto ; else goto ; and this testcase btw also fails on x86_64. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC target triplet|powerpc64-unknown-linux-gnu | Last reconfirmed|-00-00 00:00:00 |2008-04-25 09:24:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36038
[Bug c/36043] New: gcc reads 8 bytes for a struct of size 6 which leads to sigsegv
For the following programm gcc produces wrong code. To pass the struct colour
by value gcc reads 8 bytes although the struct has a size of 6. This causes
reads after allocated memory. In the example program the memory is mmap'ed and
the last element passed. The 8 byte read crosses page boundaries and causes a
segmentation violation. The code in question is:
movq-8(%rbp), %rax
addq$12282, %rax
movq(%rax), %rdi
callprint_colour
The error also occurs if you malloc the memory in question but it is harder to
provoke a segmentation violation.
The error occurs only in 64bit mode. It does not depend on the optimization
level. However if you want to reproduce it with higher optimization, you have
to move print_colour to a different compilation unit.
It could be reproduced on different gcc versions up to 4.3.0
#include
#include
struct colour
{
unsigned short red;
unsigned short green;
unsigned short blue;
};
void print_colour(struct colour col)
{
printf( "colour is %d %d %d\n",
col.red, col.green, col.blue);
}
int main(void)
{
struct colour * c = mmap(NULL, sizeof(struct colour) * 2048,
PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, 0, 0);
if (c != MAP_FAILED) {
c[2047].red = 115;
c[2047].green = 122;
c[2047].blue = 98;
print_colour(c[2047]);
munmap(c, sizeof(struct colour) * 2048);
}
return 0;
}
Here is the whole command line:
-bash-3.00$ LANG=C /lfs/user/bartosch/software/gcc/bin/gcc -v -save-temps -Wall
-W -pedantic gls.c
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.3.0/configure
--prefix=/lfs/user/bartosch/software/gcc --enable-languages=c,c++
--with-mpfr=/lfs/user/bartosch/software/gcc
Thread model: posix
gcc version 4.3.0 (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-W' '-pedantic'
'-mtune=generic'
/lfs/user/bartosch/software/gcc/libexec/gcc/x86_64-unknown-linux-gnu/4.3.0/cc1
-E -quiet -v gls.c -mtune=generic -Wall -W -pedantic -fpch-preprocess -o gls.i
ignoring nonexistent directory
"/lfs/user/bartosch/software/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.3.0/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/lfs/user/bartosch/software/gcc/include
/lfs/user/bartosch/software/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.3.0/include
/lfs/user/bartosch/software/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.3.0/include-fixed
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-W' '-pedantic'
'-mtune=generic'
/lfs/user/bartosch/software/gcc/libexec/gcc/x86_64-unknown-linux-gnu/4.3.0/cc1
-fpreprocessed gls.i -quiet -dumpbase gls.c -mtune=generic -auxbase gls -Wall
-W -pedantic -version -o gls.s
GNU C (GCC) version 4.3.0 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.3.0, GMP version 4.2.1, MPFR version 2.3.0.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 261e5a68fb24a56eb3beaa6eb43384e4
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-W' '-pedantic'
'-mtune=generic'
as -V -Qy -o gls.o gls.s
GNU assembler version 2.15.92.0.2 (x86_64-redhat-linux) using BFD version
2.15.92.0.2 20040927
COMPILER_PATH=/lfs/user/bartosch/software/gcc/libexec/gcc/x86_64-unknown-linux-gnu/4.3.0/:/lfs/user/bartosch/software/gcc/libexec/gcc/x86_64-unknown-linux-gnu/4.3.0/:/lfs/user/bartosch/software/gcc/libexec/gcc/x86_64-unknown-linux-gnu/:/lfs/user/bartosch/software/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.3.0/:/lfs/user/bartosch/software/gcc/lib/gcc/x86_64-unknown-linux-gnu/
LIBRARY_PATH=/lfs/user/bartosch/software/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.3.0/:/lfs/user/bartosch/software/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.3.0/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/lfs/user/bartosch/software/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.3.0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-W' '-pedantic'
'-mtune=generic'
/lfs/user/bartosch/software/gcc/libexec/gcc/x86_64-unknown-linux-gnu/4.3.0/collect2
--eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2
/usr/lib/../lib64/crt1.o /usr/lib/../lib64/crti.o
/lfs/user/bartosch/software/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.3.0/crtbegin.o
-L/lfs/user/bartosch/software/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.3.0
-L/lfs/user/bartosch/software/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.3.0/../../../../lib64
-L/lib/../lib64 -L/usr/lib/../lib64
-L/lfs/user/bartosch/software/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.3.0/../../..
gls.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s
--no-as-needed
/lfs/user/bartosch/software/gcc/lib/gcc/x86_64-unknown-linux-gnu/4.3.0/crtend.o
/usr/lib/../lib64/crtn.o
-bash-3.00$ ./a.out
Speicherzugriffsfehler
-bash-3.00$
--
Summary: gcc reads 8 bytes for a struct of size 6 which leads to
[Bug tree-optimization/36038] [4.4 Regression] miscompiled loop in perlbmk for -Os
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-04-25 09:51 --- > D.1374_18 = D.1373_17 * 0x0fff8; > D.1375_19 = (long long int *) D.1374_18; This looks wrong. So does this: > # ivtmp.36_25 = PHI <0B(2), ivtmp.36_16(3)> Both of those really should be in unsigned long long and not a pointer type. Thanks, Andrew Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36038
[Bug target/34163] 10% performance regression since Nov 1 on Polyhedron's "NF" on AMD64
--- Comment #8 from ubizjak at gmail dot com 2008-04-25 09:55 --- The problem is indeed in trisolve: subroutine trisolve(x,i1,i2) integer :: i1 , i2 real(dpkind),dimension(i2)::x integer :: i x(i1) = gi(i1)* x(i1) do i = i1+1 , i2 x(i) = gi(i)*(x(i)-au1(i-1)*x(i-1)) enddo do i = i2-1 , i1 , -1 x(i) = x(i) - gi(i)*au1(i)*x(i+1) enddo end subroutine trisolve Please note two very tight loops that calculate x[n] from the value x[n-1], where x[n-1] is the result of a previous step. .127t.optimized tree dump for the the first loop (the second loop is the same, only going from last to first element) in non-regressed case shows: : MEM[base: ivtmp.297] = MEM[base: ivtmp.295] * ((MEM[base: ivtmp.297] - MEM[base: ivtmp.300] * MEM[base: ivtmp.297, offset: 0x0fff8])); ivtmp.295 = ivtmp.295 + D.3347; ivtmp.297 = ivtmp.297 + 8; ivtmp.300 = ivtmp.300 + 8; ivtmp.304 = ivtmp.304 + 1; if ((integer(kind=4)) ivtmp.304 == D.1652) goto ; else goto ; this code results in: .L3: movsd (%r9), %xmm10 addl$4, %edx movsd (%rcx), %xmm9 X+> mulsd -8(%rcx), %xmm10 movsd 8(%rcx), %xmm7 movsd 16(%rcx), %xmm5 movsd 24(%rcx), %xmm3 subsd %xmm10, %xmm9 mulsd (%rax), %xmm9 addq%r10, %rax 1-> movsd %xmm9, (%rcx) movsd 8(%r9), %xmm8 1+> mulsd %xmm9, %xmm8 subsd %xmm8, %xmm7 mulsd (%rax), %xmm7 addq%r10, %rax 2-> movsd %xmm7, 8(%rcx) movsd 16(%r9), %xmm6 2+> mulsd %xmm7, %xmm6 subsd %xmm6, %xmm5 mulsd (%rax), %xmm5 addq%r10, %rax 3-> movsd %xmm5, 16(%rcx) movsd 24(%r9), %xmm4 addq$32, %r9 3+> mulsd %xmm5, %xmm4 subsd %xmm4, %xmm3 mulsd (%rax), %xmm3 addq%r10, %rax X-> movsd %xmm3, 24(%rcx) addq$32, %rcx cmpl%ebp, %edx jne .L3 In the code above, it can be seen how unrolled iterations are linked together. The result from previous iteration (marked with N->) enters next iteration (marked with N+>). BTW: Optimizer could also link X-> and X+> but this is probably too much... Patched gcc regressed in this area: : MEM[base: ivtmp.297] = MEM[base: ivtmp.295] * ((MEM[base: ivtmp.297] - MEM[base: ivtmp.300] * MEM[base: ivtmp.302])); ivtmp.295 = ivtmp.295 + D.3349; ivtmp.297 = ivtmp.297 + 8; ivtmp.300 = ivtmp.300 + 8; ivtmp.302 = ivtmp.302 + 8; ivtmp.304 = ivtmp.304 + 1; if ((integer(kind=4)) ivtmp.304 == D.1652) goto ; else goto ; this code results in: .L3: movsd (%r9), %xmm10 addl$4, %edx movsd (%rcx), %xmm9 X-> mulsd (%r8), %xmm10 movsd 8(%rcx), %xmm7 movsd 16(%rcx), %xmm5 movsd 24(%rcx), %xmm3 subsd %xmm10, %xmm9 mulsd (%rax), %xmm9 addq%rbx, %rax 1-> movsd %xmm9, (%rcx) movsd 8(%r9), %xmm8 1+> mulsd 8(%r8), %xmm8 subsd %xmm8, %xmm7 mulsd (%rax), %xmm7 addq%rbx, %rax 2-> movsd %xmm7, 8(%rcx) movsd 16(%r9), %xmm6 2+> mulsd 16(%r8), %xmm6 subsd %xmm6, %xmm5 mulsd (%rax), %xmm5 addq%rbx, %rax 3-> movsd %xmm5, 16(%rcx) movsd 24(%r9), %xmm4 addq$32, %r9 3+> mulsd 24(%r8), %xmm4 addq$32, %r8 subsd %xmm4, %xmm3 mulsd (%rax), %xmm3 addq%rbx, %rax X-> movsd %xmm3, 24(%rcx) addq$32, %rcx cmpl%r12d, %edx jne .L3 In the code above, the links are broken. In ".+>" case, gcc reloads from memory the same value that is otherwise available in the register, marked with ".->". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34163
[Bug target/34163] 10% performance regression since Nov 1 on Polyhedron's "NF" on AMD64
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-04-25 10:23 --- Not hoisting the load from x(i) is a missed PRE opportunity. Complete testcase for the second loop: subroutine trisolve2(x,i1,i2,nxyz) integer :: nxyz real,dimension(nxyz):: au1 real,allocatable,dimension(:) :: gi integer :: i1 , i2 real,dimension(i2)::x integer :: i allocate(gi(nxyz)) do i = i1+1 , i2 x(i) = gi(i)*(x(i)-au1(i-1)*x(i-1)) enddo end subroutine trisolve2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34163
[Bug middle-end/36013] [4.1/4.3/4.4 Regression] Wrong code involving restricted pointers to non-restricted pointers
--- Comment #3 from jakub at gcc dot gnu dot org 2008-04-25 10:06 --- if (u && TREE_CODE (u) == VAR_DECL && DECL_BASED_ON_RESTRICT_P (u)) u = DECL_GET_RESTRICT_BASE (u); in internal_get_tmp_var looks wrong to me. That together with find_single_pointer_decl not respecting indirection/array_ref barriers means that any depth of dereferences as long as they are gimplified one level at a time are all marked DECL_BASED_ON_RESTRICT_P. CCing Ian as he introduced that in 2005. -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||ian at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36013
[Bug c++/35331] [4.3/4.4 regression] ICE with invalid specialization of variadic template
--- Comment #3 from pcarlini at suse dot de 2008-04-25 10:35 --- Patch: http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01064.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35331
[Bug target/34163] 10% performance regression since Nov 1 on Polyhedron's "NF" on AMD64
--- Comment #10 from ubizjak at gmail dot com 2008-04-25 11:07 --- (In reply to comment #9) > Not hoisting the load from x(i) is a missed PRE opportunity. Complete > testcase > for the second loop: This is actually the first loop. Just for reference: "-O2 -funroll-loops" flags are needed. -- ubizjak at gmail dot com changed: What|Removed |Added CC||ubizjak at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34163
[Bug middle-end/36013] [4.1/4.3/4.4 Regression] Wrong code involving restricted pointers to non-restricted pointers
--- Comment #4 from jakub at gcc dot gnu dot org 2008-04-25 11:37 --- The patch didn't come with any testcases, so it is hard to find out what exactly is supposed to mean DECL_BASED_ON_RESTRICT_P on a decl. Is that supposed to be on the same level of indirection as some TYPE_RESTRICT pointer (i.e. say for int *** restrict p; formal decl initialized to p + 32 has DECL_GET_RESTRICT_BASE p), or is it supposed to be one indirection different, (e.g. formal decl initialized to *p + 32 has DECL_GET_RESTRICT_BASE p)? >From the use in find_decl_base I'd think that it should be the same level, as it will share the alias set with the pointer. ATM gimplify.c sets this as "somehow related to a restricted pointer". Wonder if just making sure that types_compatible_p between the DECL_GET_RESTRICT_BASE and the original decl in find_decl_base and only returning the restrict base if they have compatible types would be sufficient, though that still sounds dangerous. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36013
[Bug libstdc++/35942] Self Reference In Dynamic Linked Library builds for building Cross-Compiler
--- Comment #3 from earthengine at gmail dot com 2008-04-25 11:53 --- (In reply to comment #1) > Since there is no 4.3.1 release, only 4.3.0, can I assume you mean 4.3.0 for > the "Reported Against" field? > > libtool issues should be fixed in libtool if possible, and not hacked around > in > src/Makefile.am. Editing src/Makefile.in is incorrect, as this is a generated > file. > I tested with a snapshot gcc-4.3-20080410, and the internal version is 4.3.1 This is why I reported this issue with 4.3.1 I post the hacked code is only for you to find out what happen I meet. I also know that the files are generated, but I am new to gcc source code and I need time to find out which file should be update. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35942
[Bug libstdc++/35942] Self Reference In Dynamic Linked Library builds for building Cross-Compiler
--- Comment #4 from Ralf dot Wildenhues at gmx dot de 2008-04-25 12:05 --- Please post the link commands that expose the self reference (the libtool --mode=link stuff and whatever it generates). Also how exactly you configure GCC. Also please post cd $host/libstdc++-v3 && ./libtool --tag=CXX --config Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35942
[Bug libfortran/36044] New: user-requested backtrace
It would be nice to have an intrinsic function to generate a user-requested backtrace, like ifort's TRACEBACKQQ. Of course this would be a non-standard extension, but a useful one which many other compilers also provide. There has already been some discussion on this in PR30498, with suggested workarounds like producing an FPE with "1.0/0.0" or calling 'kill' via ISO_C_BINDING to generate a backtrace. But these of course terminate the program. For debugging purposes it can be helpful to generate a backtrace at some point while keeping the program running, which is what e.g. TRACEBACKQQ does. -- Summary: user-requested backtrace Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jaydub66 at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36044
[Bug middle-end/36041] Speed up builtin_popcountll
--- Comment #4 from intvnut at gmail dot com 2008-04-25 12:29 --- Is there a mechanism to provide different implementations based on the target (or in this case, class of target)? The byte count approach certainly is more appropriate for 8-bit targets, sure, but what about the rest of us? How are targets handled that might have this as an instruction? FWIW, I'd be happy to write a 32-bit version to complement the 64-bit version I provided with my report if there's a way to build a different implementation based on the class of target being compiled for. That way, embedded 8/16 bit, 32 bit and 64 bit targets can each have a version that's appropriate for that class of target. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36041
[Bug c++/36045] New: [4.3 regression] returning result of sqrt() can cause wrong return value, invalid reads
Compile as g++ -O2 -m64 h.ii && ./a.out The code should print "2"; it does so with GCC 3.4.6, GCC 4.1.2 and GCC 4.2.1. It prints "1.27688e-161" (or any other random value) with GCC 4.3; valgrind complains about ==14214== Invalid read of size 8 ==14214==at 0x4007F0: HD::e(int) const (in a.out) ==14214== Address 0x4D50028 is 8 bytes before a block of size 8 alloc'd ==14214==at 0x4905665: operator new[](unsigned long) (vg_replace_malloc.c:199) Output of g++ -v -O2 -m64 h.ii: Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /build/LCG/gcc-4.3.0/configure --prefix=/afs/cern.ch/sw/lcg/contrib/gcc/4.3.0/slc4_amd64_gcc34 --with-mpfr=/afs/cern.ch/sw/lcg/contrib/mpfr/2.3.1/slc4_amd64_gcc34 : (reconfigured) /build/LCG/gcc-4.3.0/configure --prefix=/afs/cern.ch/sw/lcg/contrib/gcc/4.3.0/slc4_amd64_gcc34 --with-mpfr=/afs/cern.ch/sw/lcg/contrib/mpfr/2.3.1/slc4_amd64_gcc34 Thread model: posix gcc version 4.3.0 (GCC) COLLECT_GCC_OPTIONS='-v' '-O2' '-m64' '-shared-libgcc' '-mtune=generic' /afs/cern.ch/sw/lcg/contrib/gcc/4.3.0/slc4_amd64_gcc34/libexec/gcc/x86_64-unknown-linux-gnu/4.3.0/cc1plus -fpreprocessed h.ii -quiet -dumpbase h.ii -m64 -mtune=generic -auxbase h -O2 -version -o /tmp/axel/ccFq5mLH.s GNU C++ (GCC) version 4.3.0 (x86_64-unknown-linux-gnu) compiled by GNU C version 4.3.0, GMP version 4.1.4, MPFR version 2.3.1. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: a1d58d96913e85190a50d3b74e2cfdbe COLLECT_GCC_OPTIONS='-v' '-O2' '-m64' '-shared-libgcc' '-mtune=generic' as -V -Qy --64 -o /tmp/axel/cc6ubWDk.o /tmp/axel/ccFq5mLH.s GNU assembler version 2.15.92.0.2 (x86_64-redhat-linux) using BFD version 2.15.92.0.2 20040927 COMPILER_PATH=/afs/cern.ch/sw/lcg/contrib/gcc/4.3.0/slc4_amd64_gcc34/libexec/gcc/x86_64-unknown-linux-gnu/4.3.0/:/afs/cern.ch/sw/lcg/contrib/gcc/4.3.0/slc4_amd64_gcc34/libexec/gcc/x86_64-unknown-linux-gnu/4.3.0/:/afs/cern.ch/sw/lcg/contrib/gcc/4.3.0/slc4_amd64_gcc34/libexec/gcc/x86_64-unknown-linux-gnu/:/afs/cern.ch/sw/lcg/contrib/gcc/4.3.0/slc4_amd64_gcc34/lib/gcc/x86_64-unknown-linux-gnu/4.3.0/:/afs/cern.ch/sw/lcg/contrib/gcc/4.3.0/slc4_amd64_gcc34/lib/gcc/x86_64-unknown-linux-gnu/ LIBRARY_PATH=/afs/cern.ch/sw/lcg/contrib/gcc/4.3.0/slc4_amd64_gcc34/lib/gcc/x86_64-unknown-linux-gnu/4.3.0/:/afs/cern.ch/sw/lcg/contrib/gcc/4.3.0/slc4_amd64_gcc34/lib/gcc/x86_64-unknown-linux-gnu/4.3.0/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/afs/cern.ch/sw/lcg/contrib/gcc/4.3.0/slc4_amd64_gcc34/lib/gcc/x86_64-unknown-linux-gnu/4.3.0/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-O2' '-m64' '-shared-libgcc' '-mtune=generic' /afs/cern.ch/sw/lcg/contrib/gcc/4.3.0/slc4_amd64_gcc34/libexec/gcc/x86_64-unknown-linux-gnu/4.3.0/collect2 --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 /usr/lib/../lib64/crt1.o /usr/lib/../lib64/crti.o /afs/cern.ch/sw/lcg/contrib/gcc/4.3.0/slc4_amd64_gcc34/lib/gcc/x86_64-unknown-linux-gnu/4.3.0/crtbegin.o -L/afs/cern.ch/sw/lcg/contrib/gcc/4.3.0/slc4_amd64_gcc34/lib/gcc/x86_64-unknown-linux-gnu/4.3.0 -L/afs/cern.ch/sw/lcg/contrib/gcc/4.3.0/slc4_amd64_gcc34/lib/gcc/x86_64-unknown-linux-gnu/4.3.0/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/afs/cern.ch/sw/lcg/contrib/gcc/4.3.0/slc4_amd64_gcc34/lib/gcc/x86_64-unknown-linux-gnu/4.3.0/../../.. /tmp/axel/cc6ubWDk.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /afs/cern.ch/sw/lcg/contrib/gcc/4.3.0/slc4_amd64_gcc34/lib/gcc/x86_64-unknown-linux-gnu/4.3.0/crtend.o /usr/lib/../lib64/crtn.o Please change the summary if you can think of anything more appropriate. -- Summary: [4.3 regression] returning result of sqrt() can cause wrong return value, invalid reads Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gcc at axel-naumann dot de GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36045
[Bug c++/36045] [4.3 regression] returning result of sqrt() can cause wrong return value, invalid reads
--- Comment #1 from gcc at axel-naumann dot de 2008-04-25 13:41 --- Created an attachment (id=15530) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15530&action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36045
[Bug c++/36046] New: Demangler fails on templates with non-type reference parameters
See attached test case. -- Summary: Demangler fails on templates with non-type reference parameters Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jjk at acm dot org GCC host triplet: x86_64-redhat-linux GCC target triplet: x86_64-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36046
[Bug c++/36046] Demangler fails on templates with non-type reference parameters
--- Comment #1 from jjk at acm dot org 2008-04-25 13:57 --- Created an attachment (id=15531) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15531&action=view) Test case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36046
[Bug libstdc++/35942] Self Reference In Dynamic Linked Library builds for building Cross-Compiler
--- Comment #5 from earthengine at gmail dot com 2008-04-25 14:12 ---
(In reply to comment #4)
> Please post the link commands that expose the self reference
> (the libtool --mode=link stuff and whatever it generates).
> Also how exactly you configure GCC. Also please post
> cd $host/libstdc++-v3 && ./libtool --tag=CXX --config
>
> Thanks.
>
Error Report-
libtool: link: x86_64-unknown-linux-gnu-g++ -shared -nostdlib
/mnt/clfs/usr/lib/../lib64/crti.o
/cross-tools/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.1/crtbeginS.o
.libs/bitmap_allocator.o .libs/pool_allocator.o .libs/mt_allocator.o
.libs/codecvt.o .libs/compatibility.o .libs/complex_io.o .libs/ctype.o
.libs/debug.o .libs/functexcept.o .libs/hash.o .libs/hash_c++0x.o
.libs/globals_io.o .libs/hashtable.o .libs/hashtable_c++0x.o .libs/ios.o
.libs/ios_failure.o .libs/ios_init.o .libs/ios_locale.o .libs/limits.o
.libs/list.o .libs/debug_list.o .libs/locale.o .libs/locale_init.o
.libs/locale_facets.o .libs/localename.o .libs/stdexcept.o .libs/strstream.o
.libs/tree.o .libs/allocator-inst.o .libs/concept-inst.o .libs/fstream-inst.o
.libs/ext-inst.o .libs/ios-inst.o .libs/iostream-inst.o .libs/istream-inst.o
.libs/istream.o .libs/locale-inst.o .libs/misc-inst.o .libs/ostream-inst.o
.libs/sstream-inst.o .libs/streambuf-inst.o .libs/streambuf.o
.libs/string-inst.o .libs/valarray-inst.o .libs/wlocale-inst.o
.libs/wstring-inst.o .libs/atomicity.o .libs/codecvt_members.o
.libs/collate_members.o .libs/ctype_members.o .libs/messages_members.o
.libs/monetary_members.o .libs/numeric_members.o .libs/time_members.o
.libs/basic_file.o .libs/c++locale.o .libs/parallel_list.o
.libs/parallel_settings.o -Wl,--whole-archive ../libmath/.libs/libmath.a
../libsupc++/.libs/libsupc++convenience.a -Wl,--no-whole-archive
-L/cross-tools/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.1
-L/cross-tools/bin/../lib/gcc
-L/cross-tools/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.1/../../../../x86_64-unknown-linux-gnu/lib/../lib64
-L/mnt/clfs/lib/../lib64 -L/mnt/clfs/usr/lib/../lib64
-L/cross-tools/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.1/../../../../x86_64-unknown-linux-gnu/lib
-L/mnt/clfs/lib -L/mnt/clfs/usr/lib -lstdc++ -lm -lc -lgcc_s
/cross-tools/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.1/crtendS.o
/mnt/clfs/usr/lib/../lib64/crtn.o -Wl,-O1 -Wl,-z -Wl,relro -Wl,--gc-sections
-Wl,--version-script=libstdc++-symbols.ver -Wl,-soname -Wl,libstdc++.so.6
-o .libs/libstdc++.so.6.0.10
/cross-tools/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.1/../../../../x86_64-unknown-linux-gnu/bin/ld:
cannot find -lstdc++
--Configure & build script-
CLFS_TAEGET=x86_64-unknown-linux-gnu
CLFS_HOST=x86_64-cross-linux-gnu
CLFS=/mnt/clfs
AR=ar CXX_FOR_TARGET="$CLFS_TARGET-g++" CC_FOR_TARGET="$CLFS_TARGET-gcc"
../gcc-4.3-20080417/configure --prefix=${CLFS}/cross-tools \
--host=${CLFS_HOST} --target=${CLFS_TARGET} \
--with-sysroot=${CLFS} --disable-nls --enable-shared \
--enable-languages=c,c++ --enable-__cxa_atexit \
--enable-c99 --enable-long-long --enable-threads=posix \
--with-gmp=$CLFS/cross-tools --with-mpfr=$CLFS/cross-tools &&
#I have only a static built gcc and if use it to build libgcc will fail
make all-gcc && make install-gcc &&
#I do not have the share library installed, which is needed to built libstdc++
make all-target-libgcc && make install-target-libgcc &&
#the error is on the make command
make && make install
--Output of Libtool config
# Which release of libtool.m4 was used?
macro_version=2.1a
macro_revision=1.2435
# Whether or not to build shared libraries.
build_libtool_libs=yes
# Whether or not to build static libraries.
build_old_libs=yes
# What type of objects to build.
pic_mode=default
# Whether or not to optimize for fast installation.
fast_install=yes
# The host system.
host_alias=x86_64-unknown-linux-gnu
host=x86_64-unknown-linux-gnu
host_os=linux-gnu
# The build system.
build_alias=x86_64-unknown-linux-gnu
build=x86_64-unknown-linux-gnu
build_os=linux-gnu
# A sed program that does not truncate output.
SED="/bin/sed"
# Sed that helps us avoid accidentally triggering echo(1) options like -n.
Xsed="$SED -e 1s/^X//"
# A grep program that handles long lines.
GREP="grep"
# An ERE matcher.
EGREP="grep -E"
# A literal string matcher.
FGREP="grep -F"
# A BSD- or MS-compatible name lister.
NM="/cross-tools/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.1/../../../../x86_64-unknown-linux-gnu/bin/nm"
# Whether we need soft or hard links.
LN_S="ln -s"
# What is the maximum length of a command?
max_cmd_len=98304
# Object file suffix (normally "o").
objext=o
# Executable file suffix (normally "").
exeext=
# whether the shell understands "unset".
lt_unset=unset
# turn spaces into newlines.
SP2NL="tr \\040 \\012"
# turn newlines into spaces.
NL2SP="tr \\015\\012 \\040\\040"
# How to create reloadable object files.
reload_flag=" -r"
reload_cmds="\$LD\$reload_flag -o \$output
[Bug c++/36045] [4.3 regression] returning result of sqrt() can cause wrong return value, invalid reads
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-04-25 14:49 --- *** This bug has been marked as a duplicate of 36017 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36045
[Bug rtl-optimization/36017] [4.3/4.4 Regression] Miscompilation of tail call sqrt
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-04-25 14:49 --- *** Bug 36045 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||gcc at axel-naumann dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36017
[Bug middle-end/36041] Speed up builtin_popcountll
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-04-25 14:52 --- It should be possible to have an alternate implementation in libgcc2.c by means of just selecting on a proper architecture define or the size of the argument mode. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36041
[Bug target/36043] gcc reads 8 bytes for a struct of size 6 which leads to sigsegv
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-04-25 14:55 --- Hmm, didn't we fix this? ... movw$115, (%rax) movw$122, 2(%rax) movw$98, 4(%rax) movq(%rax), %rdi callprint_colour -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org, matz at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2008-04-25 14:55:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36043
[Bug target/36043] gcc reads 8 bytes for a struct of size 6 which leads to sigsegv
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-04-25 14:59 ---
Ahm, not exactly a dup of PR31309.
Shorter (non-runtime) testcase:
struct colour
{
unsigned short red;
unsigned short green;
unsigned short blue;
};
void print_colour(struct colour col);
void foo(struct colour *c)
{
print_colour(*c);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36043
[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared
--- Comment #57 from oblivian at users dot sourceforge dot net 2008-04-25 15:00 --- I don't have permissions to change the status, but it looks like bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33503 is a dup or at least related if someone wants to clean it up. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752
[Bug c/36047] New: -pg does not work on large binaries and m68k
[EMAIL PROTECTED]:~/cc$ echo 'int main(void) { return 0; }' > file.c
[EMAIL PROTECTED]:~/cc$ m68k-linux-gnu-gcc -o file file.c -static -pg
/tmp/ccw33VYP.o: In function `main':
file.c:(.text+0x6): relocation truncated to fit: R_68K_PC16 against `.data'
collect2: ld returned 1 exit status
It works fine with a small binary (without -static).
I don't really know what the label is used for. I patched my gcc with:
|--- a/gcc/config/m68k/linux.h
|+++ b/gcc/config/m68k/linux.h
|@@ -143,7 +143,6 @@ along with GCC; see the file COPYING3.
| #undef FUNCTION_PROFILER
| #define FUNCTION_PROFILER(FILE, LABELNO) \
| { \
|- asm_fprintf (FILE, "\tlea (%LLP%d,%Rpc),%Ra1\n", (LABELNO));\
| if (flag_pic) \
| fprintf (FILE, "\tbsr.l [EMAIL PROTECTED]");\
| else\
|--- a/gcc/config/m68k/m68k.h
|+++ b/gcc/config/m68k/m68k.h
|@@ -576,7 +576,7 @@ extern enum reg_class regno_reg_class[];
| #define FUNCTION_ARG(CUM, MODE, TYPE, NAMED) 0
|
| #define FUNCTION_PROFILER(FILE, LABELNO) \
|- asm_fprintf (FILE, "\tlea %LLP%d,%Ra0\n\tjsr mcount\n", (LABELNO))
|+ asm_fprintf (FILE, "\tjsr mcount\n", (LABELNO))
|
| #define EXIT_IGNORE_STACK 1
|
I'm not using glibc's mcount function but my own in which I unwind the stack in
order to obtain caller's address (that's the purpose of the label I guess).
I checked gcc-core-4.3.0.tar.bz2 and the two lea lines are unchanged so the bug
should be still there.
Now how do we fix this? Removing the label or allowing larger distances?
--
Summary: -pg does not work on large binaries and m68k
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc at breakpoint dot cc
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: m68k-uclinux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36047
[Bug target/36043] gcc reads 8 bytes for a struct of size 6 which leads to sigsegv
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-04-25 15:08 --- The problem is that struct colour is laid out like arg 0 unsigned DI size unit size align 64 symtab 0 alias set -1 canonical type 0x2b4f85160780> used unsigned DI file t.c line 10 col 25 size unit size align 64 context initial (reg/v/f:DI 58 [ c ]) arg-type incoming-rtl (reg:DI 5 di [ c ])>> which doesn't match its natural alignment nor size. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36043
[Bug target/36043] gcc reads 8 bytes for a struct of size 6 which leads to sigsegv
--- Comment #4 from matz at gcc dot gnu dot org 2008-04-25 15:12 --- That's the layout of 'c', a pointer variable. We don't see the layout of the record_type here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36043
[Bug target/36043] gcc reads 8 bytes for a struct of size 6 which leads to sigsegv
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-04-25 15:17 ---
Forget that. load_register_parameters converts
(mem/s:BLK (reg/v/f:DI 58 [ c ]) [0 S6 A16])
to
(mem/s:BLK (reg/v/f:DI 58 [ c ]) [0 S6 A16])
here:
else if (partial == 0 || args[i].pass_on_stack)
{
rtx mem = validize_mem (args[i].value);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36043
[Bug bootstrap/33503] Can not build gcc from combined tree - bug in libtool
--- Comment #1 from bonzini at gnu dot org 2008-04-25 15:21 --- *** This bug has been marked as a duplicate of 35752 *** -- bonzini at gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33503
[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared
--- Comment #58 from bonzini at gnu dot org 2008-04-25 15:21 --- *** Bug 33503 has been marked as a duplicate of this bug. *** -- bonzini at gnu dot org changed: What|Removed |Added CC||s_pyptev at ipmce dot ru http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752
[Bug target/36043] gcc reads 8 bytes for a struct of size 6 which leads to sigsegv
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-04-25 15:29 --- Errm. change_address_1 simply builds a DImode mem (with alignment info properly retained) #0 0x005e80c2 in adjust_address_1 (memref=0x2b0751d81520, mode=DImode, offset=0, validate=0, adjust=1) at /space/rguenther/src/svn/gcc-4_3-branch/gcc/emit-rtl.c:1910 #1 0x005e396c in operand_subword (op=0x2b0751d81520, offset=0, validate_address=1, mode=BLKmode) at /space/rguenther/src/svn/gcc-4_3-branch/gcc/emit-rtl.c:1346 #2 0x005e3a28 in operand_subword_force (op=0x2b0751d81520, offset=0, mode=BLKmode) at /space/rguenther/src/svn/gcc-4_3-branch/gcc/emit-rtl.c:1374 #3 0x0060fd27 in move_block_to_reg (regno=5, x=0x2b0751d81520, nregs=1, mode=BLKmode) at /space/rguenther/src/svn/gcc-4_3-branch/gcc/expr.c:1560 #4 0x0054f7b9 in load_register_parameters (args=0x7fff59711810, num_actuals=1, call_fusage=0x7fff597119d0, flags=0, is_sibcall=0, sibcall_failure=0x7fff597119ac) at /space/rguenther/src/svn/gcc-4_3-branch/gcc/calls.c:1681 #5 0x005526b4 in expand_call (exp=0x2b075142d460, target=0x0, ignore=1) at /space/rguenther/src/svn/gcc-4_3-branch/gcc/calls.c:2763 no idea if that is supposed to work (and thus *movdi_1_rex64 shouldn't match) or if not ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36043
[Bug testsuite/36035] [4.4 Regression]: FAIL: gcc.dg/vect/vect-vfa-slp.c
--- Comment #3 from sje at cup dot hp dot com 2008-04-25 15:34 --- Fixed with patch that removes the bad check. -- sje at cup dot hp dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36035
[Bug target/36043] gcc reads 8 bytes for a struct of size 6 which leads to sigsegv
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-04-25 15:43 --- So, the problem is in move_block_to_reg that copies the argument piecewise to regs like for (i = 0; i < nregs; i++) emit_move_insn (gen_rtx_REG (word_mode, regno + i), operand_subword_force (x, i, mode)); not accounting for the fact that the last reg may be only partially filled from the memory. But the necessary information to deal with this is also not available in this function currently. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36043
[Bug target/36043] gcc reads 8 bytes for a struct of size 6 which leads to sigsegv
--- Comment #8 from matz at gcc dot gnu dot org 2008-04-25 16:15 --- FWIW, I think the error is in the caller of move_block_to_reg. move_block_to_reg can make use of a load_multiple instruction, which really loads full regs. I.e. it would be unreasonable to require changes in move_block_to_reg to handle non-power-of-2 sizes. Hence the caller (load_register_parameters) needs to handle this. I'm not sure if the n_aligned_regs thingy could be misused for this, or if one simply should opencode the special case of the last register being partial. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36043
[Bug target/36043] gcc reads 8 bytes for a struct of size 6 which leads to sigsegv
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-04-25 16:20 --- Index: calls.c === --- calls.c (revision 134659) +++ calls.c (working copy) @@ -2708,7 +2708,7 @@ expand_call (tree exp, rtx target, int i and whose alignment does not permit a direct copy into registers, make a group of pseudos that correspond to each register that we will later fill. */ - if (STRICT_ALIGNMENT) + if (1 || STRICT_ALIGNMENT) store_unaligned_arguments_into_pseudos (args, num_actuals); /* Now store any partially-in-registers parm. also fixes this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36043
[Bug libstdc++/35887] stl parallel includes installed for --disable-libgomp
--- Comment #7 from bkoz at gcc dot gnu dot org 2008-04-25 16:53 --- Subject: Bug 35887 Author: bkoz Date: Fri Apr 25 16:52:57 2008 New Revision: 134671 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134671 Log: 2008-05-25 Benjamin Kosnik <[EMAIL PROTECTED]> Revert PR libstdc++/35887 * configure.ac: Revert. * acinclude.m4: Same. * configure: Regenerate. * include/Makefile.am: Revert. * include/Makefile.in: Regenerate. Modified: branches/gcc-4_3-branch/libstdc++-v3/ChangeLog branches/gcc-4_3-branch/libstdc++-v3/acinclude.m4 branches/gcc-4_3-branch/libstdc++-v3/configure branches/gcc-4_3-branch/libstdc++-v3/configure.ac branches/gcc-4_3-branch/libstdc++-v3/include/Makefile.am branches/gcc-4_3-branch/libstdc++-v3/include/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35887
[Bug target/36018] [4.3/4.4 Regression] powerpc64: ICE in copy_to_mode_reg, at explow.c:621
--- Comment #4 from bunk at stusta dot de 2008-04-25 17:38 --- Works with 4.3-20080424, so whatever it was it seems to be already fixed. -- bunk at stusta dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36018
[Bug libstdc++/35887] stl parallel includes installed for --disable-libgomp
--- Comment #8 from bkoz at gcc dot gnu dot org 2008-04-25 18:38 --- Subject: Bug 35887 Author: bkoz Date: Fri Apr 25 18:37:22 2008 New Revision: 134675 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134675 Log: 2008-04-25 Benjamin Kosnik <[EMAIL PROTECTED]> PR libstdc++/35887 * acinclude.m4: (GLIBCXX_ENABLE_PARALLEL): Check for thread support. * configure.ac: Re-order compiler macros. * configure: Regenerated. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/acinclude.m4 trunk/libstdc++-v3/configure trunk/libstdc++-v3/configure.ac -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35887
[Bug inline-asm/36048] New: wrong assumption about registers used in asm statements
The code snippet below compiles correctly without optimization, but with the
optimization flag turned on (at least with -O2) the compiler wrongly assumes
that the register %edx was not modified by the inline assembly statement.
The bug can be reproduced by issuing the following command.
To reproduce the bug, compile the code snippet bellow with the command
gcc -S -O2 file.c
and look the file file.s in the lines between the to #APP sections.
See bellow, after the source file, the assembly code produced with and without
optimization.
/* file.c */
#define rsmpl8b(addr, d1, d2) __asm__ __volatile__(\
"outb %%al, %%dx\n\t" \
"movb %%cl, %%al\n\t" \
"addw $2, %%dx\n\t" \
"outb %%al, %%dx\n\t" \
: : "a" (d1), "c" (d2), "d" (addr))
void teste()
{
int i;
unsigned short base_addr = 0x378;
for (i = 0; i < 0x1000; i++) {
rsmpl8b(base_addr, 0xFF, 0xFE);
rsmpl8b(base_addr, 0xFD, 0xFC);
}
}
/*** file.s compiled with gcc -S -O2 file.c */
.file "file.c"
.text
.globl teste
.type teste, @function
teste:
pushl %ebp
movl$888, %edx
movl%esp, %ebp
pushl %edi
movl$255, %edi
pushl %esi
movl$254, %esi
pushl %ebx
movl$253, %ebx
subl$4, %esp
movl$0, -16(%ebp)
.p2align 4,,15
.L2:
movl%edi, %eax
movl%esi, %ecx
#APP
outb%al, %dx
movb%cl, %al
addw$2, %dx
outb%al, %dx
#NO_APP
movl$252, %ecx
movl%ebx, %eax
#APP
outb%al, %dx
movb%cl, %al
addw$2, %dx
outb%al, %dx
#NO_APP
incl-16(%ebp)
cmpl$4096, -16(%ebp)
jne .L2
popl%eax
popl%ebx
popl%esi
popl%edi
popl%ebp
ret
.size teste, .-teste
.ident "GCC: (GNU) 4.1.2 20070214 ( (gdc 0.24, using dmd
1.020)(Gentoo 4.1.2p1.0.2)"
.section.note.GNU-stack,"",@progbits
/*** file.s compiled with gcc -S file.c */
.file "file.c"
.text
.globl teste
.type teste, @function
teste:
pushl %ebp
movl%esp, %ebp
subl$16, %esp
movw$888, -2(%ebp)
movl$0, -8(%ebp)
jmp .L2
.L3:
movl$255, %eax
movl$254, %ecx
movzwl -2(%ebp), %edx
#APP
outb%al, %dx
movb%cl, %al
addw$2, %dx
outb%al, %dx
#NO_APP
movl$253, %eax
movl$252, %ecx
movzwl -2(%ebp), %edx
#APP
outb%al, %dx
movb%cl, %al
addw$2, %dx
outb%al, %dx
#NO_APP
incl-8(%ebp)
.L2:
cmpl$4095, -8(%ebp)
jle .L3
leave
ret
.size teste, .-teste
.ident "GCC: (GNU) 4.1.2 20070214 ((gdc 0.24, using dmd 1.020))
(Gentoo 4.1.2p1.0.2)"
.section.note.GNU-stack,"",@progbits
--
Summary: wrong assumption about registers used in asm statements
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jlima at sim dot ul dot pt
GCC host triplet: i386-linux-gnu
GCC target triplet: i386-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36048
[Bug inline-asm/36048] wrong assumption about registers used in asm statements
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-04-25 19:01 --- >that the register %edx was not modified by the inline assembly statement. Yes that is because your constraints only say the inline-asm reads the value and not modifies it. >: : "a" (d1), "c" (d2), "d" (addr)) Those are only input constraints, you don't have any output constraints. -- 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=36048
[Bug fortran/35960] run time abort with assignment of RESHAPEd zero sized array
--- Comment #6 from tkoenig at gcc dot gnu dot org 2008-04-25 20:12 --- Subject: Bug 35960 Author: tkoenig Date: Fri Apr 25 20:11:19 2008 New Revision: 134677 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134677 Log: 2008-04-25 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/35960 * m4/reshape.m4: Fix typo in last commit. * generated/reshape_i4.c: Regererated. * generated/reshape_i8.c: Regenerated. * generated/reshape_i16.c: Regenerated. * generated/reshape_r4.c: Regenerated. * generated/reshape_r8.c: Regenerated. * generated/reshape_r10.c: Regenerated. * generated/reshape_r16.c: Regenerated. * generated/reshape_c4.c: Regenerated. * generated/reshape_c8.c: Regenerated. * generated/reshape_c10.c: Regenerated. * generated/reshape_c16.c: Regenerated. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/generated/reshape_c10.c trunk/libgfortran/generated/reshape_c16.c trunk/libgfortran/generated/reshape_c4.c trunk/libgfortran/generated/reshape_c8.c trunk/libgfortran/generated/reshape_i16.c trunk/libgfortran/generated/reshape_i4.c trunk/libgfortran/generated/reshape_i8.c trunk/libgfortran/generated/reshape_r10.c trunk/libgfortran/generated/reshape_r16.c trunk/libgfortran/generated/reshape_r4.c trunk/libgfortran/generated/reshape_r8.c trunk/libgfortran/m4/reshape.m4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35960
[Bug middle-end/34226] [4.3/4.4 Regression][frv] ICE in default_secondary_reload, at targhooks.c:612
--- Comment #13 from bunk at stusta dot de 2008-04-25 20:46 --- Rask, what is the status of your patch? It would be nice if this bug was fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34226
[Bug c/30043] __attribute__((nonull(...))) and silent optimizations
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-04-25 20:52 --- *** This bug has been marked as a duplicate of 17308 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30043
[Bug middle-end/17308] nonnull attribute not as useful as it could
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-04-25 20:52 --- *** Bug 30043 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||madcoder at debian dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17308
[Bug inline-asm/36048] wrong assumption about registers used in asm statements
--- Comment #2 from jlima at sim dot ul dot pt 2008-04-25 20:56 --- If this is the expected behavior... then ok. I saw this as a bug because it is not possible to add the register to the clobbered registers list (gcc will complain with: "error: can't find a register in class 'DREG' while reloading 'asm'") and it is not elegant to define the register as an output register when the result is to be disregarded. Even if the optimizing compiler can detect that and suppress the unused code. It often required to modify/reuse an input register inside the inline assembly statement. In such cases, if I understood well, one must restore the register to its original value if optimization is to be used. But this may imply a suboptimal code since it will always be restored regardless of being required or not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36048
[Bug inline-asm/36048] wrong assumption about registers used in asm statements
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-04-25 20:59 --- >It often required to modify/reuse an input register inside the inline assembly statement. Just a temporary variable then. The compiler will do its job. Make sure you mark it as an early clobber too :). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36048
[Bug fortran/35156] [patch] Deprecate -M
--- Comment #2 from dfranke at gcc dot gnu dot org 2008-04-25 21:15 --- Subject: Bug 35156 Author: dfranke Date: Fri Apr 25 21:14:49 2008 New Revision: 134680 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134680 Log: 2008-04-25 Tobias Burnus <[EMAIL PROTECTED]> Daniel Franke <[EMAIL PROTECTED]> PR fortran/35156 * gfortranspec.c (lang_specific_driver): Deprecate -M option; fix ICE when "-M" is last argument and make "-M" work. * options.c (gfc_handle_module_path_options): Use -J instead of -M in error messages. * invoke.texi: Mark -M as depecated. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortranspec.c trunk/gcc/fortran/invoke.texi trunk/gcc/fortran/options.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35156
[Bug fortran/35156] [patch] Deprecate -M
--- Comment #3 from dfranke at gcc dot gnu dot org 2008-04-25 21:24 --- Fixed on trunk. Closing. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35156
[Bug rtl-optimization/35404] ra-conflict does not handle subregs optimally
--- Comment #7 from zadeck at naturalbridge dot com 2008-04-25 21:34 --- any regressions, if any exist at all, must be addressed by vlad's new register allocator. -- zadeck at naturalbridge dot com changed: What|Removed |Added CC||vmakarov at gcc dot gnu dot ||org AssignedTo|zadeck at naturalbridge dot |vmakarov at gcc dot gnu dot |com |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35404
[Bug c/36049] New: m68k outputs bad assembly comment
The m68k build outputs bad assembly code around an inline assembly block. Compiling the attached file with gcc 4.3.0 and binutils 2.18 for --target=m68k-unknown-uclinux-uclibc on --host=i486-linux-gnu, I get: Error: junk at end of line, first unrecognized character is `|' I won't attach the assembly generated by gcc...but I'll tell you that it contains what looks like an attempted comment before and after the inline assembly block. The apparent comment is prefixed by "|" instead of the usual "#". The ASM_COMMENT_START is #define'd as "|" for most of the m68k builds. I think that this is wrong, at least for "linux" builds. ASM_COMMENT_START has been "|" for a long time, but it seems that only recent gcc versions put comments around __asm__() blocks. A simple fix that worked for me was to change ASM_COMMENT_START to "#" in gcc/config/m68k/linux.h. This might also be appropriate for other m68k platforms. I couldn't find any other bugs reporting this problem. This bug seems a little too serious and a little too easy to fix, so maybe I'm missing something. My apologies if that's the case. -- Summary: m68k outputs bad assembly comment Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kendallc at vxitech dot com GCC build triplet: i486-linux-gnu GCC host triplet: i486-linux-gnu GCC target triplet: m68k-unknown-uclinux-uclibc http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36049
[Bug c/36049] m68k outputs bad assembly comment
--- Comment #1 from kendallc at vxitech dot com 2008-04-25 21:56 --- Created an attachment (id=15532) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15532&action=view) test code that exhibits the problem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36049
[Bug c/36050] New: Ternary operator warning on assignment used as truth value
Hi,
It would be great if ? warned when it got a (presumably accidental) assignment
like if statements do; e.g.
$ cat test.c
int main (void)
{
int i;
return (i = 20) ? 10 : 15;
}
$ gcc-4.3 -Wall test.c
It seems like this would be quite a common mistake?
--
Summary: Ternary operator warning on assignment used as truth
value
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ianw at vmware dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36050
[Bug inline-asm/36051] New: wrong assumption about registers used in asm statements
The code snippet below compiles correctly without optimization, but with the
optimization flag turned on (at least with -O2) the compiler wrongly assumes
that the register %edx was not modified by the inline assembly statement.
The bug can be reproduced by issuing the following command.
To reproduce the bug, compile the code snippet bellow with the command
gcc -S -O2 file.c
and look the file file.s in the lines between the to #APP sections.
See bellow, after the source file, the assembly code produced with and without
optimization.
/* file.c */
#define rsmpl8b(addr, d1, d2) __asm__ __volatile__(\
"outb %%al, %%dx\n\t" \
"movb %%cl, %%al\n\t" \
"addw $2, %%dx\n\t" \
"outb %%al, %%dx\n\t" \
: : "a" (d1), "c" (d2), "d" (addr))
void teste()
{
int i;
unsigned short base_addr = 0x378;
for (i = 0; i < 0x1000; i++) {
rsmpl8b(base_addr, 0xFF, 0xFE);
rsmpl8b(base_addr, 0xFD, 0xFC);
}
}
/*** file.s compiled with gcc -S -O2 file.c */
.file "file.c"
.text
.globl teste
.type teste, @function
teste:
pushl %ebp
movl$888, %edx
movl%esp, %ebp
pushl %edi
movl$255, %edi
pushl %esi
movl$254, %esi
pushl %ebx
movl$253, %ebx
subl$4, %esp
movl$0, -16(%ebp)
.p2align 4,,15
.L2:
movl%edi, %eax
movl%esi, %ecx
#APP
outb%al, %dx
movb%cl, %al
addw$2, %dx
outb%al, %dx
#NO_APP
movl$252, %ecx
movl%ebx, %eax
#APP
outb%al, %dx
movb%cl, %al
addw$2, %dx
outb%al, %dx
#NO_APP
incl-16(%ebp)
cmpl$4096, -16(%ebp)
jne .L2
popl%eax
popl%ebx
popl%esi
popl%edi
popl%ebp
ret
.size teste, .-teste
.ident "GCC: (GNU) 4.1.2 20070214 ( (gdc 0.24, using dmd
1.020)(Gentoo 4.1.2p1.0.2)"
.section.note.GNU-stack,"",@progbits
/*** file.s compiled with gcc -S file.c */
.file "file.c"
.text
.globl teste
.type teste, @function
teste:
pushl %ebp
movl%esp, %ebp
subl$16, %esp
movw$888, -2(%ebp)
movl$0, -8(%ebp)
jmp .L2
.L3:
movl$255, %eax
movl$254, %ecx
movzwl -2(%ebp), %edx
#APP
outb%al, %dx
movb%cl, %al
addw$2, %dx
outb%al, %dx
#NO_APP
movl$253, %eax
movl$252, %ecx
movzwl -2(%ebp), %edx
#APP
outb%al, %dx
movb%cl, %al
addw$2, %dx
outb%al, %dx
#NO_APP
incl-8(%ebp)
.L2:
cmpl$4095, -8(%ebp)
jle .L3
leave
ret
.size teste, .-teste
.ident "GCC: (GNU) 4.1.2 20070214 ((gdc 0.24, using dmd 1.020))
(Gentoo 4.1.2p1.0.2)"
.section.note.GNU-stack,"",@progbits
--
Summary: wrong assumption about registers used in asm statements
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jlima at sim dot ul dot pt
GCC host triplet: i386-linux-gnu
GCC target triplet: i386-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36051
[Bug inline-asm/36051] wrong assumption about registers used in asm statements
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-04-25 22:23 --- *** This bug has been marked as a duplicate of 36048 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36051
[Bug inline-asm/36048] wrong assumption about registers used in asm statements
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-04-25 22:23 --- *** Bug 36051 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36048
[Bug testsuite/35843] [4.4 Regression]: -fdump-rtl-expand does not exist anymore
--- Comment #9 from hubicka at gcc dot gnu dot org 2008-04-25 23:15 --- Subject: Bug 35843 Author: hubicka Date: Fri Apr 25 23:14:40 2008 New Revision: 134682 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134682 Log: PR testsuite/35843 * cfgexpand.c (pass_expand): Turn into RTL pass. * passes.c (execute_one_pass): Do pass typechecking after execution. * tree-pass.h (pass_expand): Turn into RTL pass. * function.h (struct rtl_data): Move here fields accesses_prior_frames, calls_eh_return, saves_all_registers, has_nonlocal_goto, has_asm_statement, is_thunk, all_throwers_are_sibcalls, limit_stack, profile, uses_const_pool, uses_pic_offset_table, uses_eh_lsda, tail_call_emit, arg_pointer_save_area_init from struct function; turn into bool. (struct function): Move calls_eh_return, saves_all_registers, has_nonlocal_goto, has_asm_statement, is_thunk, all_throwers_are_sibcalls, limit_stack, profile, uses_const_pool, uses_pic_offset_table, uses_eh_lsda, tail_call_emit, arg_pointer_save_area_init into struct rtl_data. Remove recursive_call_emit and gimplified flags. (current_function_returns_struct, current_function_returns_pcc_struct, current_function_calls_setjmp, current_function_calls_alloca, current_function_accesses_prior_frames, current_function_calls_eh_return, current_function_is_thunk, current_function_stdarg, current_function_profile, current_function_limit_stack, current_function_uses_pic_offset_table, current_function_uses_const_pool, current_function_has_nonlocal_label, current_function_saves_all_registers, current_function_has_nonlocal_goto, current_function_has_asm_statement): Remove accesor macros. * ra-conflict.c (global_conflicts): Update. * tree-tailcall.c (suitable_for_tail_opt_p): Update. (suitable_for_tail_call_opt_p): Update. * builtins.c (expand_builtin_return_addr): Update. (expand_builtin_setjmp_setup): Update. (expand_builtin_nonlocal_goto): Update. * final.c (final_start_function): Update. (profile_function): Update. (leaf_function_p): Update. (only_leaf_regs_used): Update. * df-scan.c (df_get_exit_block_use_set): Update. * dojump.c (clear_pending_stack_adjust): Update. * tree-stdarg.c (gate_optimize_stdarg): Update. * gimple-low.c (lower_function_body): Update. * global.c (compute_regsets): Update. (global_alloc): Update. * dwarf2out.c (dwarf2out_begin_prologue): Update. * expr.c (expand_assignment): Update. * dse.c (dse_step0): Update. (dse_step1): Update. * c-decl.c (store_parm_decls): Update. * local-alloc.c (combine_regs): Update. (find_free_reg): Update. * function.c (assign_parms_augmented_arg_list): Update. (assign_parm_find_data_types): Update. (assign_parms): Update. (allocate_struct_function): Update. (expand_function_start): Update. (expand_function_end): Update. (get_arg_pointer_save_area): Update. (thread_prologue_and_epilogue_insns): Update. (rest_of_match_asm_constraints): Update. * stor-layout.c (variable_size): Update. * gcse.c (gcse_main): Update. (bypass_jumps): Update. * gimplify.c (gimplify_function_tree): Update. * calls.c (emit_call_1): Update. (expand_call): Update. * bt-load.c (compute_defs_uses_and_gen): Update. * except.c (sjlj_assign_call_site_values): Update. (sjlj_emit_function_enter): Update. (can_throw_external): Update. (set_nothrow_function_flags): Update. (expand_builtin_unwind_init): Update. (expand_eh_return): Update. (convert_to_eh_region_ranges): Update. (output_function_exception_table): Update. * emit-rtl.c (gen_tmp_stack_mem): Update. * cfgexpand.c (expand_used_vars): Update. (tree_expand_cfg): Update. * cfgcleanup.c (rest_of_handle_jump): Update. * explow.c (allocate_dynamic_stack_space): Update. * varasm.c (assemble_start_function): Update. (force_const_mem): Update. (mark_constant_pool): Update. * tree-optimize.c (tree_rest_of_compilation): Update. * stack-ptr-mod.c (notice_stack_pointer_modification): Update. * tree-cfg.c (notice_special_calls): Update. (is_ctrl_altering_stmt): Update. (tree_can_make_abnormal_goto): Update. (tree_purge_dead_abnormal_call_edges): Update. * config/alpha/predicates.md: Update. * config/alpha/alpha.c (alpha_sa_mask): Update. (alpha_sa_size): Update. (alpha_does_function_need_gp): Update. (alpha_expand_prologue): Update. (alpha_start_function): Update.
[Bug c++/36052] New: [4.3/4.4 regression] bogus "type qualifiers ignored" warning
Here's an annoying regression:
-
struct S {
typedef double value_type;
};
template struct Traits {
typedef const typename T::value_type dereference_type;
};
template struct ConstIterator {
typedef typename Traits::dereference_type
dereference_type;
dereference_type operator * () const { return 0; }
};
template class ConstIterator;
-
For this, we get:
deal.II/lac> g++ -W -Wall -c a.cc
a.cc: In instantiation of 'ConstIterator':
a.cc:16: instantiated from here
a.cc:13: warning: type qualifiers ignored on function return type
We didn't use to produce this warning. I also think it's hard to avoid:
if the class S would declare its value_type as a reference, then the
addition of the 'const' in the Traits class would matter; here, it doesn't,
but that's only because of chance.
What's worse is that the warning is also inconsistent: if we replace
template struct ConstIterator {
typedef typename Traits::dereference_type
dereference_type;
by
template struct ConstIterator {
typedef const typename BlockVectorType::value_type dereference_type;
then the warning goes away despite the fact that the actual types are
exactly the same. Weird.
W.
--
Summary: [4.3/4.4 regression] bogus "type qualifiers ignored"
warning
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bangerth at dealii dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36052
[Bug c++/36052] "type qualifiers ignored" warning
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-04-25 23:55 --- This warning is correct, and not really bogus as the qualification is ignored on the return value here even though not explicitly written by the user in the function declaration. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Summary|[4.3/4.4 regression] bogus |"type qualifiers ignored" |"type qualifiers ignored" |warning |warning | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36052
[Bug c++/36052] "type qualifiers ignored" warning
--- Comment #2 from bangerth at math dot tamu dot edu 2008-04-26 00:01 --- Subject: Re: "type qualifiers ignored" warning > This warning is correct, and not really bogus as the qualification is ignored > on the return value here even though not explicitly written by the user in the > function declaration. No, sure, I fully understand that the 'const' is ignored here. What I'm saying is that this just happens to be a harmless side effect of the way I write the template. The point is that I need to write it this way so I can use classes in place of S that define value_type not as PODs, but as references or similar things. This is one of those warnings that simply make no sense with templates. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36052
[Bug other/36046] Demangler fails on templates with non-type reference parameters
--- Comment #2 from bangerth at dealii dot org 2008-04-26 00:22 --- Confirmed. The demangler gets a valid symbol it can't demangle. W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-04-26 00:22:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36046
[Bug other/36046] Demangler fails on templates with non-type reference parameters
--- Comment #3 from bangerth at dealii dot org 2008-04-26 00:25 --- By the way, the return code of __cxa_demangle is -2: mangled_name is not a valid name under the C++ ABI mangling rules. as per http://docs.mandragor.org/files/Programming_languages/Cpp/libstdcpp_v3_Source_Documentation/namespaceabi.html The string that can't be demangled is "3barILZ3bazEE". W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36046
[Bug other/36046] Demangler fails on templates with non-type reference parameters
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-04-26 00:39 --- This is expected, we should not be demangling types with __cxa_demangle. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36046
[Bug other/36046] Demangler fails on templates with non-type reference parameters
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-04-26 00:47 --- Ok, this is a generic demangler issue, we don't demangle _Z1f3barILZ3bazEE either. Which is f(bar) but only because it is mangled incorrectly in the first place. So the real issue here is that the demangle only handles correctly mangled names. _Z1f3barIL_Z3bazEE is the correct mangling. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36046
[Bug other/36046] Demangler fails on templates with non-type reference parameters
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-04-26 00:53 --- so all three versions mangle it differently if we have f(bar) 1: _Z1f3barIXadL_Z3bazEEE 2: _Z1f3barILZ3bazEE 3: _Z1f3barIL_Z3bazEE I think 3 is correct as the underscore is needed and the address is not supplied.. but the default value is 2 right now I don't know if we should "fix" up the mangler to accept version 2 at all. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36046
[Bug other/36046] Demangler fails on templates with non-type reference parameters
--- Comment #7 from ian at airs dot com 2008-04-26 00:57 --- See bug #16240 for some background. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36046
[Bug target/36049] m68k assembly comment causes assembler error
--- Comment #2 from kendallc at vxitech dot com 2008-04-26 01:40 --- Marking my own bug as invalid because it looks like gas should accept "|" as a comment. I guess this is a binutils problem. -- kendallc at vxitech dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID Summary|m68k outputs bad assembly |m68k assembly comment causes |comment |assembler error http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36049
[Bug libstdc++/35922] std::unordered_map missing in debug mode
--- Comment #6 from bkoz at gcc dot gnu dot org 2008-04-26 02:22 --- Subject: Bug 35922 Author: bkoz Date: Sat Apr 26 02:21:37 2008 New Revision: 134693 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134693 Log: 2008-04-25 Benjamin Kosnik <[EMAIL PROTECTED]> PR libstdc++/35922 * include/std/unordered_map: Include debug/unordered_map if _GLIBCXX_DEBUG. * testsuite/23_containers/unordered_map/requirements/debug.cc: Move... * testsuite/23_containers/unordered_map/requirements/ debug_container.cc: ...here. * testsuite/23_containers/unordered_map/requirements/debug_mode.cc: New. * testsuite/23_containers/unordered_set/requirements/debug.cc: Move... * testsuite/23_containers/unordered_set/requirements/ debug_container.cc: ...here. * testsuite/23_containers/unordered_set/requirements/debug_mode.cc: New. Added: trunk/libstdc++-v3/testsuite/23_containers/unordered_map/requirements/debug_container.cc - copied unchanged from r134683, trunk/libstdc++-v3/testsuite/23_containers/unordered_map/requirements/debug.cc trunk/libstdc++-v3/testsuite/23_containers/unordered_map/requirements/debug_mode.cc trunk/libstdc++-v3/testsuite/23_containers/unordered_set/requirements/debug_container.cc - copied unchanged from r134683, trunk/libstdc++-v3/testsuite/23_containers/unordered_set/requirements/debug.cc trunk/libstdc++-v3/testsuite/23_containers/unordered_set/requirements/debug_mode.cc Removed: trunk/libstdc++-v3/testsuite/23_containers/unordered_map/requirements/debug.cc trunk/libstdc++-v3/testsuite/23_containers/unordered_set/requirements/debug.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/std/unordered_map -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35922
[Bug debug/33155] _stdcall assembler names in win32 vs gdb
--- Comment #2 from dannysmith at users dot sourceforge dot net 2008-04-26 03:17 --- (In reply to comment #1) > What is the status on this? Does reverting the langhooks.c change remanifest > PR27067? > No. PR27067 is fixed by cp/mangle.c (mangle_decl): Call targetm.mangle_decl_assembler_name. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33155
[Bug debug/33155] _stdcall assembler names in win32 vs gdb
--- Comment #3 from aaronavay62 at aaronwl dot com 2008-04-26 04:13 --- (In reply to comment #2) > (In reply to comment #1) > > What is the status on this? Does reverting the langhooks.c change > > remanifest > > PR27067? > > > No. PR27067 is fixed by > cp/mangle.c (mangle_decl): Call targetm.mangle_decl_assembler_name. I see; then should the langhooks.c bit be reverted to fix this bug, or do you think it will be able to be solved soon some other way? -- aaronavay62 at aaronwl dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-04-26 04:13:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33155
[Bug fortran/35993] [4.3/4.4 regression] wrong answer for PRODUCT with scalar mask
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2008-04-26 04:27 --- This problem is worse then thought. It also extends to the SUM intrinsic which uses a similar code pattern. When MASK is a scalar and false the code that should traverse the destination array and set the values to 1 for PRODUCT and 0 for SUM just flat does not do that. It does not traverse each element of the return array (dest) for (n = 0; n < rank; n++) dest[n * dstride] = 1 ; Also the rank is set to the source array rank rather than the return array array rank, which is also wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35993
[Bug target/36040] Using %rsi instead of %esi for a u32 in generated code
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-04-26 05:20 --- (In reply to comment #2) > Also the ABI specifies that function arguments in registers are sign/zero > extended according to their sign to the full width of the registers, maybe > what > calles > this function is not adhering to this? > That is what I was thinking too after looking at it again. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36040
[Bug fortran/35993] [4.3/4.4 regression] wrong answer for all array intrinsics with scalar mask
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2008-04-26 06:14 --- I am also seeing this same issue with all the array intrinsics that accept a mask if it is scalar and .false. At this point I am calling for some second opinions here. The bad code is in the "s" version of each of the generated array intrinsics. Am I missing something or is this really a hole? -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.3/4.4 regression] wrong |[4.3/4.4 regression] wrong |answer for PRODUCT with |answer for all array |scalar mask |intrinsics with scalar mask http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35993
[Bug fortran/35993] [4.3/4.4 regression] wrong answer for all array intrinsics with scalar mask
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2008-04-26 06:17 --- I am going to un assign myself. I think we need a team effort here. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|jvdelisle at gcc dot gnu dot|unassigned at gcc dot gnu |org |dot org Severity|normal |major Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35993
