[Bug bootstrap/29937] New: bootstrap failure on Linux AMD64
I tried to install gcc-4.2-20061121 and gcc-4.3-20061118. Both failed at exactly the same point. The steps I used to install them were: # cd /common/src # tar xjf gcc-4.2-20061121.tar.bz2 # cd /common/compilers/linux/gcc-4.2 # /common/src/gcc-4.2-20061121/configure --prefix=/common/compilers/linux/gcc-4.2/ --program-suffix=-4.2 --enable-languages=c,c++,fortran # make -j5 CFLAGS='-O' LIBCFLAGS='-g -O2' LIBCXXFLAGS='-g -O2 -fno-implicit-templates' bootstrap-lean the same for gcc-4.3.X both failed at: === x-gnu/bits/stdtr1c++.h.gch/O2g.gch /common/src/gcc-4.2-20061121/libstdc++-v3/include/precompiled/stdtr1c++.h:30:25: warning: /common/compilers/linux/gcc-4.2/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu/bits/stdc++.h.gch/O0g.gch: not used because `__NO_INLINE__' not defined touch ./x86_64-unknown-linux-gnu/bits/stdtr1c++.h if [ ! -d "./x86_64-unknown-linux-gnu/bits/extc++.h.gch" ]; then \ mkdir -p ./x86_64-unknown-linux-gnu/bits/extc++.h.gch; \ fi; \ /common/compilers/linux/gcc-4.2/./gcc/xgcc -shared-libgcc -B/common/compilers/linux/gcc-4.2/./gcc -nostdinc++ -L/common/compilers/linux/gcc-4.2/x86_64-unknown-linux-gnu/libstdc++-v3/src -L/common/compilers/linux/gcc-4.2/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/common/compilers/linux/gcc-4.2//x86_64-unknown-linux-gnu/bin/ -B/common/compilers/linux/gcc-4.2//x86_64-unknown-linux-gnu/lib/ -isystem /common/compilers/linux/gcc-4.2//x86_64-unknown-linux-gnu/include -isystem /common/compilers/linux/gcc-4.2//x86_64-unknown-linux-gnu/sys-include -Winvalid-pch -Wno-deprecated -x c++-header -g -O2 -D_GNU_SOURCE -I/common/compilers/linux/gcc-4.2/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/common/compilers/linux/gcc-4.2/x86_64-unknown-linux-gnu/libstdc++-v3/include -I/common/src/gcc-4.2-20061121/libstdc++-v3/libsupc++ -O2 -g /common/src/gcc-4.2-20061121/libstdc++-v3/include/precompiled/extc++.h -o x86_64-unknown-linux-gnu/bits/extc++.h.gch/O2g.gch touch ./x86_64-unknown-linux-gnu/bits/extc++.h make[2]: Leaving directory `/common/compilers/linux/gcc-4.2/x86_64-unknown-linux-gnu/libstdc++-v3/include' make[1]: Leaving directory `/common/compilers/linux/gcc-4.2' make: *** [bootstrap-lean] Error 2 === Are we, or aren't we allowed to compile bootstrap with make -jX when building gcc? Then, I reconfigured and recompiled using a single CPU. For both I got the following error: = multidirs=32 with_multisubdir= Running configure in multilib subdirs 32 pwd: /common/compilers/linux/gcc-4.2/x86_64-unknown-linux-gnu/libmudflap Running configure in multilib subdir 32 pwd: /common/compilers/linux/gcc-4.2/x86_64-unknown-linux-gnu configure: creating cache ./config.cache checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking target system type... x86_64-unknown-linux-gnu checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for --enable-version-specific-runtime-libs... no checking whether to enable maintainer-specific portions of Makefiles... no checking for x86_64-unknown-linux-gnu-gcc... /common/compilers/linux/gcc-4.2/./gcc/xgcc -B/common/compilers/linux/gcc-4.2/./gcc/ -B/common/compilers/linux/gcc-4.2//x86_64-unknown-linux-gnu/bin/ -B/common/compilers/linux/gcc-4.2//x86_64-unknown-linux-gnu/lib/ -isystem /common/compilers/linux/gcc-4.2//x86_64-unknown-linux-gnu/include -isystem /common/compilers/linux/gcc-4.2//x86_64-unknown-linux-gnu/sys-include -m32 checking for C compiler default output file name... a.out checking whether the C compiler works... configure: error: cannot run C compiled programs. If you meant to cross compile, use `--host'. See `config.log' for more details. make[1]: *** [configure-target-libmudflap] Error 1 make[1]: Leaving directory `/common/compilers/linux/gcc-4.2' make: *** [bootstrap-lean] Error 2 # gcc --version gcc (GCC) 4.1.1 (Gentoo 4.1.1) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. = here is the config.log == This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. configure:614: checking host system type configure:635: checking target system type configure:653: checking build system type configure:708: checking for a BSD compatible install configure:761: checking whether ln works configure:785: checking whether ln -s works configure:1850: checking for gcc configure:1963: checking whether the C compiler (gcc ) works configure:1979: gcc -o conftestconftest.c 1>&5 configure:2005: checking whether the C compiler (gcc ) is a cross-compiler co
gcc3.3.3 vs gcc4.0.0
Hello, I have a proc file which I compile with the proc compiler and link it with gcc. The .pc file as well as makefile is same in two m/c's. In one m/c with gcc3.3.3 installed, I have no problem in compiling and linking. In another m/c with gcc4.0.0 installed, I was getting the following error: p15.c:4857: error: conflicting types for 'logerror' p15.c:4812: error: previous implicit declaration of 'logerror' was here logerror() was not declared in the p15.pc file. So I changed the code and declared the method before my main routine and it solved my problem. What I would like to know is that why is this giving me such different results with the different versions. Or is there something wrong in the makefile. However my makefile is same in both the m/c's Or maybe my 2nd m/c doen't have the requisite libraries in the paths mentioned. Somebody please help in dipersing these doubts. FYI: Snapshot of makefile : p15.o: p15.pc $(PROC) $(PROCPLSFLAGS) iname=p15.pc userid=$(USERID) $(CC) $(CFLAGS) -I $(INCLUDEPATH) -c p15.c p15: unxfns.o rpg_fns.o p15.o cfarerr.o cfarsms.o $(CC) $(CFLAGS) -o p15 p15.o unxfns.o rpg_fns.o cfarsms.o cfarerr.o -Wl,-L/usr/lib/ -L$(LIBPATH) -L$(LIBLOCAL) Note* unxfns.o, rpg_fns.o, cfarsms.o, cfarerr.o : all are properly compiled and linked objects. Variables : USERID=cfar/[EMAIL PROTECTED] NETWORKHOME=$(ORACLE_HOME)/network/ PLSQLHOME=$(ORACLE_HOME)/plsql/ INCLUDEPATH=./ -I $(ORACLE_HOME)/precomp/public LIBPATH=$(ORACLE_HOME)/lib32/ -lnsl -lclntsh -lgeneric9 LIBLOCAL$ = ./ Regards Jayashree Nair This e-Mail may contain proprietary and confidential information and is sent for the intended recipient(s) only. If by an addressing or transmission error this mail has been misdirected to you, you are requested to delete this mail immediately. You are also hereby notified that any use, any form of reproduction, dissemination, copying, disclosure, modification, distribution and/or publication of this e-mail message, contents or its attachment other than by its intended recipient/s is strictly prohibited. Visit us at http://www.polaris.co.in
[Bug c/29938] New: [3.4.4/3.4.6/4.1.1] ARM structure pointer alignment problem with optimization
Hi.
I've a reduced test case showing that a function like:
struct x {
uint8_t a;
uint16_t b;
};
f(struct x *y)
...
will expect that 'y' is correctly aligned: it uses 'ldrh' to access y->b and
ldrh documentation says "if the memory is not halfworld-aligned and no data
abort occurs, the value written to the destination register is unpredictable."
Test case:
typedef unsigned char uint8_t;
typedef unsigned short int uint16_t;
struct x {
uint16_t d;
uint8_t c;
};
int f(struct x *y)
{
diag_printf("y=%p y->c=%d(0x%x) y->d=%d(0x%x)\n\r",y,y->c,y->c,y->d,y->d);
}
int main(int argc,char **argv )
{
void *s=malloc(sizeof(struct x)+1);
struct x *y;
s++; // <- problem origin
y=s;
y->c=0xAA;
y->d=0xBBCC;
f(y);
while(1);
}
Without "s++;":
y=0x88e0 y->c=170(0xaa) y->d=48076(0xbbcc)
With "s++;":
y=0x88e1 y->c=170(0xaa) y->d=-872415045(0xccbb)
Generated code with -Os is:
int f(struct x *y)
{
4698: b500push{lr}
diag_printf("y=%p y->c=%d(0x%x) y->d=%d(0x%x)\n\r",y,y->c,y->c,y->d,y->d);
469a: 7883ldrbr3, [r0, #2]
469c: 8802ldrhr2, [r0, #0] <--- *HERE*
469e: b082sub sp, #8
46a0: 9200str r2, [sp, #0]
46a2: 9201str r2, [sp, #4]
46a4: 1c01mov r1, r0 (add r1, r0, #0)
46a6: 1c1amov r2, r3 (add r2, r3, #0)
46a8: 4802ldr r0, [pc, #8](46b4
<.text+0x674>)
46aa: ff4ff002bl 4000354c
}
46ae: b002add sp, #8
46b0: bc02pop {r1}
46b2: 4708bx r1
46b4: 98e4ldr r0, [sp, #912]
46b6: 4000and r0, r0
Tested on arm-elf-gcc 3.4.4, 3.4.6, 4.1.1, the latest two with and without the
patch related to bug 29373.
Thanks for your help.
--
Summary: [3.4.4/3.4.6/4.1.1] ARM structure pointer alignment
problem with optimization
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bernard dot fouche at kuantic dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29938
[Bug c/29938] [3.4.4/3.4.6/4.1.1] ARM structure pointer alignment problem with optimization
--- Comment #1 from rearnsha at gcc dot gnu dot org 2006-11-22 10:50 --- The compiler expects 'y' to be correctly aligned because the ABI says that it can expect this to be so. If you write a program that then provides an unaligned value, then the behaviour is undefined and you can get any result the compiler feels like giving you. Hint: don't increment void* pointers (it's a gcc extension that permits this anyway) and then try to assign them to a structure. Malloc provides memory that is correctly aligned for direct assignment to any structure type. -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29938
[Bug middle-end/28752] bootstrap comparision fails with "-ftree-vectorize -maltivec" on ppc and i386
--- Comment #27 from irar at il dot ibm dot com 2006-11-22 11:15 --- I committed the patch that enables vectorization of strided accesses (http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01679.html), and now bootstrap with vectorization fails also on x86 with the same error as in comment #3. Here, the offending loop is cfgloopanal.c:153. Ira -- irar at il dot ibm dot com changed: What|Removed |Added GCC build triplet|powerpc64-linux |powerpc64-linux and and ||i386-linux GCC host triplet|powerpc64-linux |powerpc64-linux and i386- ||linux GCC target triplet|powerpc64-linux |powerpc64-linux and and ||i386-linux Summary|bootstrap comparision fails |bootstrap comparision fails |with "-ftree-vectorize -|with "-ftree-vectorize - |maltivec" on ppc|maltivec" on ppc and i386 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28752
[Bug c/29938] [3.4.4/3.4.6/4.1.1] ARM structure pointer alignment problem with optimization
--- Comment #2 from bernard dot fouche at kuantic dot com 2006-11-22 11:32 --- Subject: Re: [3.4.4/3.4.6/4.1.1] ARM structure pointer alignment problem with optimization rearnsha at gcc dot gnu dot org wrote: > --- Comment #1 from rearnsha at gcc dot gnu dot org 2006-11-22 10:50 > --- > The compiler expects 'y' to be correctly aligned because the ABI says that it > can expect this to be so. If you write a program that then provides an > unaligned value, then the behaviour is undefined and you can get any result > the > compiler feels like giving you. > > Hint: don't increment void* pointers (it's a gcc extension that permits this > anyway) and then try to assign them to a structure. Malloc provides memory > that is correctly aligned for direct assignment to any structure type. > > > Sorry for having taken your time for nothing. I'll read the ABI spec better next time. Too bad my target does not have alignment traps, I've fallen in the problem while building a packet with an odd size header. Regards, Bernard -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29938
[Bug c++/29433] using boost::MPL requires lots of memory
--- Comment #17 from rguenth at gcc dot gnu dot org 2006-11-22 12:39 --- Created an attachment (id=12666) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12666&action=view) testcase run through uninclude unincluded so it's 64bit clean also. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29433
[Bug fortran/29912] Gfortran: string array functions behaving incorrectly...
--- Comment #7 from pault at gcc dot gnu dot org 2006-11-22 13:42 --- I have just submitted a patch to the gfortran list. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-11-20 15:45:09 |2006-11-22 13:42:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29912
[Bug fortran/29912] Gfortran: string array functions behaving incorrectly...
--- Comment #8 from patchapp at dberlin dot org 2006-11-22 13:45 --- Subject: Bug number PR29912 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01561.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29912
[Bug c++/29939] New: Please implement rvalue references
Rvalue references as described in http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2118.html were voted into the C++0x working draft at the 2006 Portland meeting, and I'd like to use them. -- Summary: Please implement rvalue references Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jyasskin at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29939
[Bug tree-optimization/29891] [4.3 Regression] libgcc2.c: In function '__gcc_bcmp': ICE: Segmentation fault
--- Comment #5 from kkojima at gcc dot gnu dot org 2006-11-22 14:20 --- Sorry for my slow reply. I have no easy way to look this issue quickly. I'd like to revert the reorg part of 118746 to fix the build failure on hppa. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29891
[Bug fortran/17711] Wrong operator name in error message
--- Comment #4 from tobi at gcc dot gnu dot org 2006-11-22 14:48 --- A possible solution is to add entries for the symbolic forms (e.g. '==') of the intrinsic operators to the enum gfc_intrinsic_op, and then use them interchangeably, except when matching the operators, and when printing error messages. -- tobi at gcc dot gnu dot org changed: What|Removed |Added CC||tobi at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17711
[Bug tree-optimization/29921] [4.3 regression]: internal compiler error: in set_lattice_value, at tree-ssa-ccp.c:437
--- Comment #5 from hjl at lucon dot org 2006-11-22 14:50 --- Another testcase: [EMAIL PROTECTED] build_base_o2.]$ cat bar.f90 SUBROUTINE foo(DPRS,LBOT,LTOP,KTS,KTE) IMPLICIT NONE INTEGER,INTENT(IN) :: KTS,KTE INTEGER,INTENT(OUT) :: LBOT,LTOP REAL,DIMENSION(KTS:KTE),INTENT(IN) :: DPRS REAL,DIMENSION(KTS:KTE) :: FPK,TREFK REAL :: PSUM, QOTSUM, POTSUM, SUMDP, TRFKL,DPKL,DST REAL :: FPTK, RDPSUM, RTBAR, DEN, DQREF INTEGER :: L SUMDP=0. DO L=LTOP,LBOT SUMDP=SUMDP+DPRS(L) ENDDO RDPSUM=1./SUMDP DO L=LTOP,LBOT TREFK(L)=TRFKL ENDDO PSUM =0. QOTSUM=0. DST =0. FPTK =FPK(LTOP) DO L=LTOP,LBOT DPKL =FPK(L)-FPTK PSUM =DPKL *DPRS(L)+PSUM POTSUM=DPKL*RTBAR*DPRS(L)+POTSUM ENDDO PSUM =PSUM*RDPSUM IF(DST.GT.0.)THEN GO TO 800 ENDIF IF(-DEN/PSUM.LT.5.E-5)THEN LBOT=0 GO TO 800 ENDIF IF(DQREF.LT.0.)THEN GO TO 800 ENDIF 800 CONTINUE END SUBROUTINE foo [EMAIL PROTECTED] build_base_o2.]$ /usr/gcc-4.3/bin/gfortran -c -o module_cu_bmj.fppized.o -I. -I./netcdf/include -O2 -ffast-math -DSPEC_CPU_LINUX -DSPEC_CPU_CASE_FLAG -DSPEC_CPU_LOGICAL_STRICT -frecord-marker=4 bar.f90 bar.f90: In function âfooâ: bar.f90:1: internal compiler error: in set_lattice_value, at tree-ssa-ccp.c:437 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. [EMAIL PROTECTED] build_base_o2.]$ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29921
[Bug c++/29927] template instantiation with function type
--- Comment #3 from s__nakayama at infoseek dot jp 2006-11-22 14:57 ---
(In reply to comment #2)
(In reply to comment #2)
> What exactly do you expect the code to do?
> foo();
> leads to an instantiation of foo with
> T= int()()
> i.e. reference to "no-arg function returning int". From
> thereon I am a bit confused what exactly you intend to
> do in foo()...
I expected that the compiler reject it.
But Comeau compiler also accepted this code.
gcc 2.95.3 don't generate code that causes segmentation fault.(LINK error)
another test case:
following invalid code causes ICE.
template
void foo()
{
T bar = 0;
bar();
}
int main()
{
foo();
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29927
[Bug fortran/29441] non-constant parameter (constant) accepted
--- Comment #3 from tobi at gcc dot gnu dot org 2006-11-22 15:01 --- I have a one-line patch for this. -- tobi at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tobi at gcc dot gnu dot org |dot org | Severity|normal |enhancement Status|NEW |ASSIGNED Last reconfirmed|2006-10-12 15:10:40 |2006-11-22 15:01:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29441
[Bug c++/29940] New: A variable named _S exists without declaration
This program compiles:
#include
int main()
{
std::cout << _S << std::endl;
return 0;
}
If started, it outputs : 8
output of my g++ -v:
Reading specs from /opt/csw/gcc4/lib/gcc/i386-pc-solaris2.8/4.0.2/specs
Target: i386-pc-solaris2.8
Configured with: ../sources/gcc-4.0.2/configure --prefix=/opt/csw/gcc4
--with-local-prefix=/opt/csw --with-gnu-as --with-as=/opt/csw/bin/gas
--without-gnu-ld --with-ld=/usr/ccs/bin/ld --enable-threads=posix
--enable-shared --enable-multilib --enable-nls --with-included-gettext
--with-libiconv-prefix=/opt/csw --with-x --enable-java-awt=xlib
--with-system-zlib --enable-languages=c,c++,f95,java,objc,ada
Thread model: posix
gcc version 4.0.2
--
Summary: A variable named _S exists without declaration
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: boris dot breidenbach at physik dot uni-erlangen dot de
GCC build triplet: i386-pc-solaris2.8
GCC host triplet: i386-pc-solaris2.8
GCC target triplet: i386-pc-solaris2.8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29940
[Bug c++/29940] A variable named _S exists without declaration
--- Comment #1 from boris dot breidenbach at physik dot uni-erlangen dot de 2006-11-22 15:05 --- Created an attachment (id=12667) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12667&action=view) output of g++ -E -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29940
[Bug c++/29939] Please implement rvalue references
--- Comment #1 from fang at csl dot cornell dot edu 2006-11-22 15:07 --- There was some (suspended) discussion about support for rvalue references in PR 24803. Is there a plan for them somewhere in the pipeline? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29939
[Bug tree-optimization/29891] [4.3 Regression] libgcc2.c: In function '__gcc_bcmp': ICE: Segmentation fault
--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2006-11-22 15:11 --- Subject: Re: [4.3 Regression] libgcc2.c: In function '__gcc_bcmp': ICE: Segmentation fault > Sorry for my slow reply. I have no easy way to look this > issue quickly. I'd like to revert the reorg part of 118746 > to fix the build failure on hppa. That sounds fine. It would be quite a bit of work to find what's actually wrong given that the symptoms aren't directly related to the change. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29891
[Bug fortran/29941] New: gfortran reports error with len of assumed size character array
With this subroutine: subroutine whatever(str) character(len=*), dimension(*) :: str integer :: i i = len(str) end subroutine whatever gfortran reports: i = len(str) 1 Error: The upper bound in the last dimension must appear in the reference to the assumed size array 'str' at (1) The subroutine is valid -- you can pass an assumed size whole array to any subroutine that does not need to know the shape of the array, and len can accept either a scalar or an array. The subroutine compiles if either an explicit length is given, i.e. character(len=10), or the array is assumed shape, i.e. dimension(:). -- Summary: gfortran reports error with len of assumed size character array Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: william dot mitchell at nist dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29941
[Bug c++/29942] New: Template parameter refused as a template parameter.
The following code produce a compilation error at the unique line of the
function named "visit" below (it is a basic implementation of a visitor
pattern) :
# 1 "test.cpp"
# 1 ""
# 1 ""
# 1 "test.cpp"
template
struct Toto
{
template
void visit(T2 * o)
{
o->eval();
}
};
template
struct Titi
{
template
void eval()
{ }
};
int main()
{
Toto toto;
Titi titi;
toto.visit(& titi);
return 0;
}
g++ test.cpp -o test
test.cpp: In member function «void Toto::visit(T2*)»:
test.cpp:7: erreur: expected primary-expression before «>» token
test.cpp:7: erreur: expected primary-expression before «)» token
make: *** [test] Erreur 1
I tried this with g++-3.4.6 too (it compiles and run well with msvc 8.0).
Here is the output of the command "g++ -v -save-temps test.cpp" :
Utilisation des specs internes.
Cible : i486-linux-gnu
Configuré avec: ../src/configure -v
--enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.0 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-java-awt=gtk-default --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr
--disable-werror --with-tune=pentium4 --enable-checking=release i486-linux-gnu
Modèle de thread: posix
version gcc 4.0.3 (Ubuntu 4.0.3-1ubuntu5)
/usr/lib/gcc/i486-linux-gnu/4.0.3/cc1plus -E -quiet -v -D_GNU_SOURCE test.cpp
-mtune=pentium4 -fpch-preprocess -o test.ii
le répertoire « /usr/local/include/i486-linux-gnu » est ignoré car inexistant
le répertoire « /usr/include/i486-linux-gnu » est ignoré car inexistant
la recherche pour #include "..." débute ici :
la recherche pour #include <...> débute ici:
/usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../include/c++/4.0.3
/usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../include/c++/4.0.3/i486-linux-gnu
/usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../include/c++/4.0.3/backward
/usr/local/include
/usr/lib/gcc/i486-linux-gnu/4.0.3/include
/usr/include
Fin de la liste de recherche.
/usr/lib/gcc/i486-linux-gnu/4.0.3/cc1plus -fpreprocessed test.ii -quiet
-dumpbase test.cpp -mtune=pentium4 -auxbase test -version -o test.s
GNU C++ version 4.0.3 (Ubuntu 4.0.3-1ubuntu5) (i486-linux-gnu)
compiled by GNU C version 4.0.3 (Ubuntu 4.0.3-1ubuntu5).
heuristiques GGC: --param ggc-min-expand=64 --param ggc-min-heapsize=64420
test.cpp: In member function «void Toto::visit(T2*)»:
test.cpp:7: erreur: expected primary-expression before «>» token
test.cpp:7: erreur: expected primary-expression before «)» token
--
Summary: Template parameter refused as a template parameter.
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: samuel dot hangouet at free dot fr
GCC host triplet: Ubuntu 4.0.3-1ubuntu5
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29942
[Bug c++/29927] template instantiation with function type
--- Comment #4 from bangerth at dealii dot org 2006-11-22 15:31 --- (In reply to comment #3) > I expected that the compiler reject it. > But Comeau compiler also accepted this code. As does icc. I can't see why the code would be invalid if one accepts that T bar; is the declaration of a function pointer 'bar'. In that case, you simply have an invalid function pointer and calling it should yield a segfault, just as you get. Now, here's a different interpretation that icc actually takes: it says that T bar; is the declaration for a function with name and signature int bar(); and the code will yield a linker error when compiled. In any case, can you clarify why exactly you think the code should be rejected? W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29927
[Bug tree-optimization/29891] [4.3 Regression] libgcc2.c: In function '__gcc_bcmp': ICE: Segmentation fault
--- Comment #7 from kkojima at gcc dot gnu dot org 2006-11-22 15:40 --- Indeed. I've reverted it now. Sorry again for the breakage. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29891
[Bug libgomp/28898] OpenMP-parallelized program crashes after a parallel for loop
--- Comment #4 from jakub at gcc dot gnu dot org 2006-11-22 15:58 --- Too old glibc or configured without TLS support? Try building gcc with --disable-tls. Works just fine here. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28898
[Bug c++/29939] Please implement rvalue references
--- Comment #2 from hhinnant at apple dot com 2006-11-22 16:21 --- If there is a plan, I don't know about it. Russell Yanofsky has a prototype implementation here: http://russ.yanofsky.org/rref/ I haven't looked at it enough to know how complete it is. It was done a couple of years ago. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29939
[Bug bootstrap/29937] bootstrap failure on Linux AMD64
--- Comment #1 from hjl at lucon dot org 2006-11-22 16:32 --- Please try # make -j5 bootstrap-lean -- hjl at lucon dot org changed: What|Removed |Added CC||hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29937
[Bug target/29943] New: gcc generate incorrect alias symbols for PPC
The following example(reduced from glibc) compiles differently for ppc target
when using gcc 4.2 as compared to gcc 4.1
It generates the alias symbol as a real symbol instead of creating it as alias.
I get this correct using gcc 4.2 for arm so the problem seems to be affecting
only ppc. This also works ok with gcc 4.1
to reproduce compile the example with -O2
testcase.c
extern char **_dl_argv
__attribute__ ((section (".data.rel.ro")))
;
extern char **_dl_argv_internal __attribute__ ((visibility ("hidden")))
__attribute__ ((section (".data.rel.ro")))
;
char **_dl_argv __attribute__ ((section (".data.rel.ro"))) = ((void *)0);
extern __typeof (_dl_argv) _dl_argv_internal __attribute__ ((alias
("_dl_argv")));
char* foo (){
return _dl_argv_internal[0];
}
=
glibc segfaults in ld.so currently when compiled with gcc 4.2 for ppc due to
this issue.
--
Summary: gcc generate incorrect alias symbols for PPC
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: raj dot khem at gmail dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: powerpc-*-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29943
[Bug bootstrap/29937] bootstrap failure on Linux AMD64
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-11-22 16:42 --- /common/compilers/linux/gcc-4.2//x86_64-unknown-linux-gnu/sys-include -m32 checking for C compiler default output file name... a.out checking whether the C compiler works... configure: error: cannot run C compiled programs. Do you have the 32bit libc installed? Also you looked at the wrong config.log. You should look at the one in the libstdc++ subdirectory. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|blocker |normal Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29937
[Bug c++/29939] Add rvalue references (C++0x)
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Priority|P3 |P5 Last reconfirmed|-00-00 00:00:00 |2006-11-22 16:43:53 date|| Summary|Please implement rvalue |Add rvalue references |references |(C++0x) Version|unknown |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29939
[Bug c++/29940] A variable named _S exists without declaration
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-11-22 16:45 --- _S is in the reserved identifiers for implemenation so ... Closing as invalid. -- 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=29940
[Bug c++/29942] Template parameter refused as a template parameter.
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-22 16:47 --- Instead of: o->eval(); You want: o->template eval(); Which is required by the C++ standard. read: http://gcc.gnu.org/gcc-3.4/changes.html -- 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=29942
[Bug tree-optimization/29921] [4.3 regression]: internal compiler error: in set_lattice_value, at tree-ssa-ccp.c:437
--- Comment #6 from hjl at lucon dot org 2006-11-22 16:56 --- A simpler testcase: [EMAIL PROTECTED] 29921]$ cat bar.f90 SUBROUTINE foo(DPRS,FPK,LBOT,LTOP,KTS,KTE) IMPLICIT NONE INTEGER,INTENT(IN) :: KTS,KTE INTEGER,INTENT(OUT) :: LBOT,LTOP REAL,DIMENSION(KTS:KTE),INTENT(IN) :: DPRS,FPK REAL,DIMENSION(KTS:KTE) :: TREFK REAL :: PSUM, QOTSUM, SUMDP, TRFKL,DPKL,DST REAL :: FPTK, RDPSUM, RTBAR, DEN, DQREF INTEGER :: L SUMDP=0. DO L=LTOP,LBOT SUMDP=SUMDP+DPRS(L) ENDDO RDPSUM=1./SUMDP DO L=LTOP,LBOT TREFK(L)=TRFKL ENDDO PSUM =0. QOTSUM=0. DST =0. FPTK =FPK(LTOP) DO L=LTOP,LBOT DPKL =FPK(L)-FPTK PSUM =DPKL *DPRS(L)+PSUM ENDDO PSUM =PSUM*RDPSUM IF(-DEN/PSUM.LT.5.E-5)THEN LBOT=0 ENDIF END SUBROUTINE foo [EMAIL PROTECTED] 29921]$ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29921
[Bug tree-optimization/29944] New: should do more loops transformations to enable more biv widening
At the moment, we only do biv (basic induction variable) widening when we
can argue that overflow cuases undefined behaviour, as in:
int
f (int start, int end, int x, int y)
{
short i;
for (i = start; i < end; i++)
x <<= y;
return x;
}
However, for -ftrapv, we get the wrong result (it doesn't trap in case of
overflow), and for -fwrapv, no biv widening is done.
Likewise, if the biv is unsigned, as in:
int
f (int start, int end, int x, int y)
{
unsigned short i;
for (i = start; i < end; i++)
x <<= y;
return x;
}
we fail to do any biv widening.
Using suitable loop transformations, biv widening can be done safely without
a change in observable program behaviour.
If a cheap vector addition is available that adds units as wide as the
original biv size, proper updates of a narrow unsigned biv can be obtained
by making sure the biv is properly zero-extended at the loop entry,
and using the vector addition to do the increment.
If no cheap vector addition is available, or if defined operation on a
narrow signed biv is required, biv widening can be done safely by
transforming the loop into two nested loops, where end value of the inner
loop is calculated so that if the biv should overflow, the value of the biv
during the last iteration will be the value prior to the overflow.
The outer loop can then, if required, trap, calculate the new biv
value to archive wrap-around semantics, and continue looping.
--
Summary: should do more loops transformations to enable more biv
widening
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
OtherBugsDependingO 29842
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29944
[Bug tree-optimization/29944] should do more loops transformations to enable more biv widening
--- Comment #1 from amylaar at gcc dot gnu dot org 2006-11-22 19:23 --- Created an attachment (id=12668) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12668&action=view) 3.4.3 patch For illustration, this patch implements this optimization in a 3.4.3 based compiler. Because the 4.x series uses a completely different infrastructure, we must re-implement this from scratch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29944
[Bug target/29945] New: ICE in simplify_subreg with simple code in libgfortran
The code from libgfortran ICEs:
extern const char *__ctype_ptr;
parse_real (unsigned char c)
{
if ((__ctype_ptr[c]&04) &&c != '.')
unget_char ( c);
}
-
t.c: In function 'parse_real':
t.c:6: internal compiler error: in simplify_subreg, at simplify-rtx.c:4470
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
--
Summary: ICE in simplify_subreg with simple code in libgfortran
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, build
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
GCC target triplet: spu-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29945
[Bug tree-optimization/29921] [4.3 regression]: internal compiler error: in set_lattice_value, at tree-ssa-ccp.c:437
--- Comment #7 from hjl at lucon dot org 2006-11-22 19:34 --- Reduced: [EMAIL PROTECTED] 29921]$ cat bar.f90 SUBROUTINE foo(DPRS,DEN,LBOT,LTOP,KTS,KTE) IMPLICIT NONE INTEGER,INTENT(IN) :: KTS,KTE INTEGER,INTENT(OUT) :: LBOT,LTOP REAL,DIMENSION(KTS:KTE),INTENT(IN) :: DPRS REAL, INTENT(IN) :: DEN REAL :: PSUM, SUMDP INTEGER :: L SUMDP=0. DO L=LTOP,LBOT SUMDP=SUMDP+DPRS(L) ENDDO SUMDP=1./SUMDP PSUM =0. DO L=LTOP,LBOT PSUM=PSUM+DPRS(L) ENDDO PSUM =PSUM*SUMDP IF(-DEN/PSUM.LT.5.E-5)THEN LBOT=0 ENDIF END SUBROUTINE foo [EMAIL PROTECTED] 29921]$ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29921
[Bug tree-optimization/29946] New: inept unrolling for small iteration counts
When profile based feedback indicates that a loop has a low iteration count, it will often refuse to unroll even though unrolling is still useful. Moreover, while it knows about the average loop iteration count, it lacks the concept of a prevalent iteration count. In particular, the header checksumming of the EEMBC packetflow benchmark usually has ten iterations. With gcc 3.x, unrolling was by a factor of four, which was mediocre. With the introduction of the new loop unroller in 4.0, unrolling when doing profile feedback was no longer done at all. The proper thing to do would be to unroll this loop five times. When the case of a loop that is not a multiple of the chosen unroll factor is deemed sufficiently unlikely, that case can be taken care of by generating a non-unrolled loop after the unrolled loop. The unrolled loop can use a suitably transformed unequality check for the loop start and end to verify that a sufficient number of iterations is outstanding, so that no casesi / tablejump code is needed. See also: http://gcc.gnu.org/ml/gcc-patches/2004-09/msg02373.html -- Summary: inept unrolling for small iteration counts Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amylaar at gcc dot gnu dot org OtherBugsDependingO 29842 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29946
[Bug fortran/17711] Wrong operator name in error message
-- tobi at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tobi at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-12-30 18:46:39 |2006-11-22 19:49:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17711
[Bug tree-optimization/29946] inept unrolling for small iteration counts
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-22 19:49 --- > With the introduction of the new loop unroller in 4.0, I think you mean 3.4.0 because the new unroller was in 3.4.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29946
[Bug tree-optimization/29921] [4.3 regression]: internal compiler error: in set_lattice_value, at tree-ssa-ccp.c:437
--- Comment #8 from hjl at lucon dot org 2006-11-22 20:02 ---
A testcase in C:
int
foo (float *array, int end)
{
int i;
float sum1, sum2;
sum2=0;
for (i=0; i < end; i++)
sum2=sum2+array[i];
sum2=1./sum2;
sum1 =0.;
for (i=0; i < end; i++)
sum1=sum1+array[i];
sum1 =sum1*sum2;
if (-10.0/sum1 < 5.E-5)
end=0;
return end;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29921
[Bug bootstrap/29937] bootstrap failure on Linux AMD64
--- Comment #3 from dkouroun at cc dot uoi dot gr 2006-11-22 20:07 --- Subject: Re: bootstrap failure on Linux AMD64 Quoting pinskia at gcc dot gnu dot org <[EMAIL PROTECTED]>: > > > --- Comment #2 from pinskia at gcc dot gnu dot org 2006-11-22 16:42 > --- > /common/compilers/linux/gcc-4.2//x86_64-unknown-linux-gnu/sys-include -m32 > checking for C compiler default output file name... a.out > checking whether the C compiler works... configure: error: cannot run C > compiled programs. > > > Do you have the 32bit libc installed? > > Also you looked at the wrong config.log. You should look at the one in the > libstdc++ subdirectory I use the latest Gentoo Linux and as I see the following libraries are installed: app-emulation/emul-linux-x86-baselibs Latest version available: 2.5.2 Latest version installed: 2.5.2 Size of files: 5,457 kB Homepage: http://www.gentoo.org/ Description: Base libraries for emulation of 32bit x86 on amd64 License: GPL-2 app-emulation/emul-linux-x86-compat Latest version available: 1.0-r1 Latest version installed: 1.0-r1 Size of files: 1,200 kB Homepage: http://www.gentoo.org/ Description: emul-linux-x86 version of lib-compat, with the addition of a 32bit libgcc_s and the libstdc++ versions provided by gcc 3.3 and 3.4 for non-multilib systems. License: GPL-2 what else can I do to check manually the glibc libraries? I never learned how can somebody check the version of glibc installed on his system. How can I do that? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29937
[Bug tree-optimization/29946] inept unrolling for small iteration counts
--- Comment #2 from amylaar at gcc dot gnu dot org 2006-11-22 20:10 --- (In reply to comment #1) > > With the introduction of the new loop unroller in 4.0, > I think you mean 3.4.0 because the new unroller was in 3.4.0. > You're right, it was introduced then. Although the old loop unroller was still present in 3.4.0 and could be selected with a flag - which was useful to get avoid performance regressions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29946
[Bug bootstrap/29937] bootstrap failure on Linux AMD64
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-11-22 20:14 --- (In reply to comment #3) > what else can I do to check manually the glibc libraries? > I never learned how can somebody check the version of glibc installed > on his system. How can I do that? for one where does gentoo install their 32bit libc? I would try configuring with --disable-multilib and try again. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29937
[Bug target/29945] ICE in simplify_subreg with simple code in libgfortran
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-22 20:16 --- I have a fix. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-11-22 20:16:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29945
[Bug bootstrap/29937] bootstrap failure on Linux AMD64
--- Comment #5 from dkouroun at cc dot uoi dot gr 2006-11-22 20:18 --- Subject: Re: bootstrap failure on Linux AMD64 # ls /usr/ -l total 72 lrwxrwxrwx 1 root root 6 Nov 21 12:59 X11R6 -> ../usr drwxr-xr-x 2 root root 16384 Nov 22 17:21 bin drwxr-xr-x 61 root root 8192 Nov 22 06:19 include lrwxrwxrwx 1 root root 5 Nov 21 08:29 lib -> lib64 drwxr-xr-x 5 root root 4096 Nov 21 15:10 lib32 drwxr-xr-x 24 root root 16384 Nov 22 17:20 lib64 drwxr-xr-x 5 root root 4096 Nov 21 14:03 libexec drwxr-xr-x 10 root root 4096 Nov 21 12:00 local drwxr-xr-x 157 root root 4096 Nov 21 10:39 portage drwxr-xr-x 2 root root 4096 Nov 22 06:19 sbin drwxr-xr-x 70 root root 4096 Nov 22 06:36 share drwxr-xr-x 3 root root 4096 Nov 21 09:09 src lrwxrwxrwx 1 root root 8 Nov 21 08:29 tmp -> /var/tmp drwxr-xr-x 6 root root 4096 Aug 3 14:01 x86_64-pc-linux-gnu # ls /usr/lib32/ Mcrt1.o libGL.so libcidn.so libmcheck.a libpthread.alibsandbox.so Scrt1.o libanl.a libcrypt.a libnsl.a libpthread.so libsandbox.so.0 crt1.o libanl.so libcrypt.so libnsl.so libpthread_nonshared.a libsandbox.so.0.0.0 crti.o libbsd-compat.a libdl.a libnss_compat.so libresolv.a libthread_db.so crtn.o libbsd.a libdl.so libnss_dns.so libresolv.solibutil.a gconv libc.alibg.a libnss_files.so librpcsvc.a libutil.so gcrt1.o libc.so libieee.alibnss_hesiod.so librt.a locale libBrokenLocale.a libc_nonshared.a libm.a libnss_nis.so librt.so misc libBrokenLocale.so libc_stubs.a libm.so libnss_nisplus.so libsandbox.la opengl hope this helps -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29937
[Bug libfortran/29936] Missed constraint on RECL=specifier in unformatted sequential WRITE
--- Comment #3 from tkoenig at gcc dot gnu dot org 2006-11-22 20:48 --- (In reply to comment #0) > The following example should give an EOR error. This is one of the things that the programmer has to get right, a processor may do anything (including silently ignoring the error, as gfortran and ifort 8 did, and raising an error). Oh well, in order not to cause a regression, I will have to adjust my large record patch accordingly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29936
[Bug fortran/29941] gfortran reports error with len of assumed size character array
--- Comment #1 from burnus at gcc dot gnu dot org 2006-11-22 21:04 --- Confirmed. Accepted without warning by NAG f95, g95,sunf95 and ifort. In order to determine the length of a character array, the size or shape of the array does not matter. -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||rejects-valid Last reconfirmed|-00-00 00:00:00 |2006-11-22 21:04:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29941
[Bug bootstrap/29937] bootstrap failure on Linux AMD64
--- Comment #6 from dkouroun at cc dot uoi dot gr 2006-11-22 21:23 --- Subject: Re: bootstrap failure on Linux AMD64 > --- Comment #1 from hjl at lucon dot org 2006-11-22 16:32 --- > Please try > > # make -j5 bootstrap-lean > again it stops at the same point as it did initially. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29937
[Bug bootstrap/29937] bootstrap failure on Linux AMD64
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-11-22 21:27 --- (In reply to comment #5) > Subject: Re: bootstrap failure on Linux AMD64 > hope this helps Yes gentoo is installing libc in the wrong directory. lib should be a symbol link (or really what is currently lib32) to lib32. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29937
[Bug bootstrap/29937] bootstrap failure on Linux AMD64
--- Comment #8 from dkouroun at cc dot uoi dot gr 2006-11-22 21:39 --- Subject: Re: bootstrap failure on Linux AMD64 Quoting pinskia at gcc dot gnu dot org <[EMAIL PROTECTED]>: > > > --- Comment #7 from pinskia at gcc dot gnu dot org 2006-11-22 21:27 > --- > (In reply to comment #5) > > Subject: Re: bootstrap failure on Linux AMD64 > > hope this helps > > Yes gentoo is installing libc in the wrong directory. lib should be a symbol > link (or really what is currently lib32) to lib32. I do not think that the directory is wrong. I think you mean that it install's in a directory which is not the one gcc expects it to be. So I guess that gcc expects the 32bit libraries to be found under the directory /lib, while gentoo there installs the 64bit libraries. Well, in a 32bit system the libraries are found under /lib. Shouldn't this /lib directory contains the native 64bit libraries in a 64bit system. Don't forget that the 32bit are provided just for convenience, they are not necessary at all for the 64bit system's functionality! So I suggest since the directory where Gentoo installs is not wrong but the directory where gcc expects the 32bit libraries to reside is wrong, it would be nice that gcc provides an option at the configure script where one instructs it where to find the 32bit and the 64bit libraries. Currently I am running with --disable-multilib. I hope it works but I will not have 32bit compatibility. What do you think? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29937
[Bug bootstrap/29937] bootstrap failure on Linux AMD64
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-11-22 21:44 --- (In reply to comment #8) > I do not think that the directory is wrong. I think you mean that it > install's in a directory which is not the one gcc expects it to be. > So I guess that gcc expects the 32bit libraries to be found under the > directory /lib, while gentoo there installs the 64bit libraries. The library structure which GCC uses is the standard directory layout for x86_64 if you have something different, then you have a broken install. > So I suggest since the directory where Gentoo installs is not wrong but > the directory where gcc expects the 32bit libraries to reside is wrong, > it would be nice that gcc provides an option at the configure script where > one instructs it where to find the 32bit and the 64bit libraries. Again what GCC does is the standard directory layout and yes there is a standard. */lib/ should contain the 32bit libraries while */lib64/ should contain the 64bit libraries. This is so you can move a program compiled for x86 on to a x86_64 machine without having to recompile it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29937
[Bug bootstrap/29937] bootstrap failure on Linux AMD64
--- Comment #10 from dkouroun at cc dot uoi dot gr 2006-11-22 21:47 --- Subject: Re: bootstrap failure on Linux AMD64 Quoting pinskia at gcc dot gnu dot org <[EMAIL PROTECTED]>: > > > --- Comment #9 from pinskia at gcc dot gnu dot org 2006-11-22 21:44 > --- > (In reply to comment #8) > > I do not think that the directory is wrong. I think you mean that it > > install's in a directory which is not the one gcc expects it to be. > > So I guess that gcc expects the 32bit libraries to be found under the > > directory /lib, while gentoo there installs the 64bit libraries. > > The library structure which GCC uses is the standard directory layout for > x86_64 if you have something different, then you have a broken install. > > > So I suggest since the directory where Gentoo installs is not wrong but > > the directory where gcc expects the 32bit libraries to reside is wrong, > > it would be nice that gcc provides an option at the configure script where > > one instructs it where to find the 32bit and the 64bit libraries. > > Again what GCC does is the standard directory layout and yes there is a > standard. > > */lib/ should contain the 32bit libraries while */lib64/ should contain the > 64bit libraries. This is so you can move a program compiled for x86 on to a > x86_64 machine without having to recompile it. Is it so hard to provide an option in the configure script to specify where those libraries reside? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29937
[Bug bootstrap/29937] bootstrap failure on Linux AMD64
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-11-22 21:58 --- Again this is a bug in the distro and not a bug in GCC, if gentoo wants that directory layout, they are not going to be compatible with any other distros or even most newer closed source software. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29937
[Bug c/29947] New: OpenMP parallel for fails for reversed loop range
The following test program works as expected when compiled without -fopenmp.
In some cases, such as shown below, it fails when the loop termination
condition is already satisfied on entry:
[EMAIL PROTECTED] tmp]$ uname -a
Linux carmenere.cfa.harvard.edu 2.6.18-1.2200.fc5 #1 SMP Sat Oct 14 16:59:56
EDT 2006 x86_64 x86_64 x86_64 GNU/Linux
[EMAIL PROTECTED] tmp]$ gcc --version
gcc (GCC) 4.1.1 20060525 (Red Hat 4.1.1-1)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[EMAIL PROTECTED] tmp]$ cat example.c
#include
int main(int argc, char *argv[])
{
int i, j, k;
j = atoi(argv[1]);
k = atoi(argv[2]);
#pragma omp parallel for
for (i = j; i <= k; ++i)
printf("%d ", i);
printf("done\n");
return 0;
}
[EMAIL PROTECTED] tmp]$ gcc -o example example.c
[EMAIL PROTECTED] tmp]$ ./example 1 5
1 2 3 4 5 done
[EMAIL PROTECTED] tmp]$ ./example 5 1
done
[EMAIL PROTECTED] tmp]$ gcc -o example -fopenmp -lgomp example.c
[EMAIL PROTECTED] tmp]$ ./example 1 5
4 5 1 2 3 done
[EMAIL PROTECTED] tmp]$ ./example 5 1
-2147483644 -2147483643 -2147483642 -2147483641 -2147483640 -2147483639
-2147483638 -2147483637 -2147483636 -2147483635 -2147483634 -2147483633
-2147483632 -2147483631 -2147483630 -2147483629 -2147483628 -2147483627
-2147483626 -2147483625 -2147483624 -2147483623 -2147483622 -2147483621
-2147483620 -2147483619 -2147483618 -2147483617 -2147483616 -2147483615
-2147483614 -2147483613 -2147483612 -2147483611 -2147483610 -2147483609
-2147483608 -2147483607 -2147483606 -2147483605 -2147483604 -2147483603 .
etc.
--
Summary: OpenMP parallel for fails for reversed loop range
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: spaine at cfa dot harvard dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29947
[Bug fortran/29441] non-constant parameter (constant) accepted
--- Comment #4 from tobi at gcc dot gnu dot org 2006-11-22 22:09 --- Subject: Bug 29441 Author: tobi Date: Wed Nov 22 22:09:14 2006 New Revision: 119101 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119101 Log: fortran/ PR fortran/29441 * intrinsic.c (gfc_intrinsic_func_interface): Always check if intrinsic is allowed in initialization expression. testsuite/ PR fortran/29441 * gfortran.dg/initialization_4.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/initialization_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/intrinsic.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29441
[Bug middle-end/29947] OpenMP parallel for fails for reversed loop range
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-22 22:11 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|c |middle-end Ever Confirmed|0 |1 Keywords||openmp, wrong-code Last reconfirmed|-00-00 00:00:00 |2006-11-22 22:11:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29947
[Bug c++/29948] New: G++ OOM's when compiling kmail
When compiling kmail with Debian's dpkg-buildpackage, cc1plus is killed by the kernel due to memory shortage. This shows when using either g++ 4.0 or 4.1. Files (including .ii files) are on the following URL: http://errors.linuxonly.nl/gcc/ G++ version: g++-4.0 (GCC) 4.0.4 20060904 (prerelease) (Debian 4.0.3-7) g++ (GCC) 4.1.2 20061028 (prerelease) (Debian 4.1.1-19) System type: Linux sjord 2.6.15-1-amd64-k8 #2 Wed Jan 4 06:25:54 CET 2006 x86_64 GNU/Linux Compiling file: libkmailprivate_la.all_cpp.cpp -- Summary: G++ OOM's when compiling kmail Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sjoerd-gcc at linuxonly dot nl 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=29948
[Bug target/29943] [4.2 Regression] gcc generate incorrect alias symbols for PPC
--- Comment #1 from amodra at bigpond dot net dot au 2006-11-22 22:21 --- relevant -O2 assembly is .globl _dl_argv .globl _dl_argv_internal .hidden _dl_argv_internal .set_dl_argv_internal,_dl_argv .section.data.rel.ro,"aw",@progbits .align 2 .set.LANCHOR0,. + 0 .type _dl_argv_internal, @object .size _dl_argv_internal, 4 _dl_argv_internal: .zero 4 .type _dl_argv, @object .size _dl_argv, 4 _dl_argv: .zero 4 -fno-section-anchors generates good code -- amodra at bigpond dot net dot au changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-11-22 22:21:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29943
[Bug c++/29948] G++ OOM's when compiling kmail
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-22 22:24 --- Can you report what options you are using to compile? Actually just copy and paste the exact command that is running out of memory. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29948
[Bug tree-optimization/29921] [4.3 regression]: internal compiler error: in set_lattice_value, at tree-ssa-ccp.c:437
--- Comment #9 from hjl at lucon dot org 2006-11-22 22:26 --- Is HONOR_NANS missing somwhere? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29921
[Bug target/29943] [4.2/4.3 Regression] gcc generate incorrect alias symbols for PPC
--- Comment #2 from amodra at bigpond dot net dot au 2006-11-22 22:27
---
Removing __attribute__ ((section (".data.rel.ro"))) from _dl_argv_internal also
generates good code.
--
amodra at bigpond dot net dot au changed:
What|Removed |Added
Component|middle-end |target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29943
[Bug c++/29948] G++ OOM's when compiling kmail
--- Comment #2 from sjoerd-gcc at linuxonly dot nl 2006-11-22 22:27 --- Command line: g++ -save-temps -DHAVE_CONFIG_H -I. -I/home/sjoerd0/dev/dist/bla/kdepim-3.5.5.dfsg.1/./kmail -I.. -I/home/sjoerd0/dev/dist/bla/kdepim-3.5.5.dfsg.1/./libkmime -I/home/sjoerd0/dev/dist/bla/kdepim-3.5.5.dfsg.1/./libkpgp -I/home/sjoerd0/dev/dist/bla/kdepim-3.5.5.dfsg.1/./libkdenetwork -I/home/sjoerd0/dev/dist/bla/kdepim-3.5.5.dfsg.1/./libkdepim -I/home/sjoerd0/dev/dist/bla/kdepim-3.5.5.dfsg.1/./libkpimidentities -I/home/sjoerd0/dev/dist/bla/kdepim-3.5.5.dfsg.1/./libemailfunctions -I/home/sjoerd0/dev/dist/bla/kdepim-3.5.5.dfsg.1/./libksieve -I/home/sjoerd0/dev/dist/bla/kdepim-3.5.5.dfsg.1/./mimelib -I/home/sjoerd0/dev/dist/bla/kdepim-3.5.5.dfsg.1/./certmanager/lib -I/home/sjoerd0/dev/dist/bla/kdepim-3.5.5.dfsg.1/./certmanager/lib/ui -I/home/sjoerd0/dev/dist/bla/kdepim-3.5.5.dfsg.1/./indexlib -I/home/sjoerd0/dev/dist/bla/kdepim-3.5.5.dfsg.1/. -I/home/sjoerd0/dev/dist/bla/kdepim-3.5.5.dfsg.1/./libkdepim -I/usr/include/kde -I/usr/share/qt3/include -I. -DQT_THREAD_SUPPORT -D_REENTRANT -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wconversion -Wchar-subscripts -Wall -W -Wpointer-arith -DNDEBUG -DNO_DEBUG -O2 -g -Wall -O2 -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions -fno-check-new -fno-common -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -c libkmailprivate_la.all_cpp.cpp -fPIC -DPIC -o .libs/libkmailprivate_la.all_cpp.o Which originates from a libtool command: /bin/bash ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I/home/sjoerd0/dev/dist/bla/kdepim-3.5.5.dfsg.1/./kmail -I.. -I/home/sjoerd0/dev/dist/bla/kdepim-3.5.5.dfsg.1/./libkmime -I/home/sjoerd0/dev/dist/bla/kdepim-3.5.5.dfsg.1/./libkpgp -I/home/sjoerd0/dev/dist/bla/kdepim-3.5.5.dfsg.1/./libkdenetwork -I/home/sjoerd0/dev/dist/bla/kdepim-3.5.5.dfsg.1/./libkdepim -I/home/sjoerd0/dev/dist/bla/kdepim-3.5.5.dfsg.1/./libkpimidentities -I/home/sjoerd0/dev/dist/bla/kdepim-3.5.5.dfsg.1/./libemailfunctions -I/home/sjoerd0/dev/dist/bla/kdepim-3.5.5.dfsg.1/./libksieve -I/home/sjoerd0/dev/dist/bla/kdepim-3.5.5.dfsg.1/./mimelib -I/home/sjoerd0/dev/dist/bla/kdepim-3.5.5.dfsg.1/./certmanager/lib -I/home/sjoerd0/dev/dist/bla/kdepim-3.5.5.dfsg.1/./certmanager/lib/ui -I/home/sjoerd0/dev/dist/bla/kdepim-3.5.5.dfsg.1/./indexlib -I/home/sjoerd0/dev/dist/bla/kdepim-3.5.5.dfsg.1/. -I/home/sjoerd0/dev/dist/bla/kdepim-3.5.5.dfsg.1/./libkdepim -I/usr/include/kde -I/usr/share/qt3/include -I. -DQT_THREAD_SUPPORT -D_REENTRANT -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wconversion -Wchar-subscripts -Wall -W -Wpointer-arith -DNDEBUG -DNO_DEBUG -O2 -g -Wall -O2 -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions -fno-check-new -fno-common -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -c -o libkmailprivate_la.all_cpp.lo libkmailprivate_la.all_cpp.cpp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29948
[Bug target/29943] [4.2/4.3 Regression] gcc generate incorrect alias symbols for PPC
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-11-22 22:30 --- .data.rel.ro, isn't that a special section? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29943
[Bug target/29943] [4.2/4.3 Regression] gcc generate incorrect alias symbols for PPC
--- Comment #4 from amodra at bigpond dot net dot au 2006-11-22 22:41 --- Not particularly. s/.data.rel.ro/.mysect/ does the same thing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29943
[Bug libgomp/29949] New: implement argument checking for user accessable runtime routines
Arguments for omp_set_num_threads/OMP_NUM_THREADS are used without checking for validity, i.e. $> cat omp_set_num_threads.f90 PROGRAM main USE OMP_LIB CALL omp_set_num_threads(-3) !$OMP PARALLEL WRITE(*,*) "thread:", omp_get_thread_num() !$OMP END PARALLEL END PROGRAM $> gfortran-4.3 -g -Wall -fbounds-check omp_set_num_threads.f90 $> ./a.out -3 libgomp: Out of memory allocating 4294967288 bytes Segmentation Fault The specifications v2.5, section 3.2.1, state: "If the number of threads requested exceeds the number the implementation can support, or is not a positive integer, the behavior of this routine is implementation defined." Although crashing is a form of "implementation", it is not very user friendly. -- Summary: implement argument checking for user accessable runtime routines Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libgomp AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: franke dot daniel at gmail dot com GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29949
[Bug rtl-optimization/29950] New: Generated code changes after unrelated edits in source.
I noticed that sizes of functions in generated code change when I do simple
unrelated changes. Example:
# diff -u vi_small.c vi_big.c
--- vi_small.c 2006-11-22 23:35:39.0 +0100
+++ vi_big.c2006-11-22 23:35:42.0 +0100
@@ -3414,6 +3414,8 @@
} sockaddr_inet;
extern int dotted2sockaddr(const char *dotted, struct sockaddr* sp, int
socklen);
extern int create_and_bind_socket_ip4or6(const char *hostaddr, int port);
+extern int setsockopt_reuseaddr(int fd);
+extern int setsockopt_reuseaddr2(int fd);
extern char *xstrdup(const char *s);
extern char *xstrndup(const char *s, int n);
extern char *safe_strncpy(char *dst, const char *src, size_t size);
Both .c files have this simple function at the end:
Byte *find_pair(Byte * p, Byte c)
{
Byte match, *q;
int dir, level;
match = ')';
level = 1;
dir = 1;
switch (c) {
case '(':
match = ')';
break;
case '[':
match = ']';
break;
case '{':
match = '}';
break;
case ')':
match = '(';
dir = -1;
break;
case ']':
match = '[';
dir = -1;
break;
case '}':
match = '{';
dir = -1;
break;
}
for (q = p + dir; text <= q && q < end; q += dir) {
if (*q == c)
level++;
if (*q == match)
level--;
if (level == 0)
break;
}
if (level != 0)
q = ((void *)0);
return (q);
}
which is obviously does not depend on setsockopt_reuseaddr[2].
I made two extra copies of it, just for fun, but it happens without copies too.
Okay, when I compile those:
#!/bin/sh
function compile() {
gcc -fno-builtin-strlen -Os "$@"
}
compile -c -o vi_small.o vi_small.c
compile -c -o vi_big.o vi_big.c
nm --size-sort vi_small.o | grep find_pair
nm --size-sort vi_big.o | grep find_pair
I am getting:
00a9 T find_pair (vi_small.c)
00a9 T find_pairB
00a9 T find_pairC
00a9 T find_pairB (vi_big.c)
00a9 T find_pairC
00b9 T find_pair <- different??
How come gcc generates different code for identical source files?
You saw the diff, it cannot matter at all...
How come gcc generates different code for identical functions???
(vi_big.c:find_pairB is the same as vi_big.c:find_pair to the last byte)
# gcc -v
Using built-in specs.
Target: i386-pc-linux-gnu
Configured with: ../gcc-4.1.1.org/configure --prefix=/usr/app/gcc-4.1.1.org
--exec-prefix=/usr/app/gcc-4.1.1.org --bindir=/usr/bin --sbindir=/usr/sbin
--libexecdir=/usr/app/gcc-4.1.1.org/libexec
--datadir=/usr/app/gcc-4.1.1.org/share --sysconfdir=/etc
--sharedstatedir=/usr/app/gcc-4.1.1.org/var/com
--localstatedir=/usr/app/gcc-4.1.1.org/var --libdir=/usr/lib
--includedir=/usr/include --infodir=/usr/info --mandir=/usr/man
--with-slibdir=/usr/app/gcc-4.1.1.org/lib --with-local-prefix=/usr/local
--with-gxx-include-dir=/usr/app/gcc-4.1.1.org/include/g++-v3
--enable-languages=c,c++ --with-system-zlib --disable-nls
--enable-threads=posix i386-pc-linux-gnu
Thread model: posix
gcc version 4.1.1
--
Summary: Generated code changes after unrelated edits in source.
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vda dot linux at googlemail dot com
GCC build triplet: i386-pc-linux-gnu
GCC host triplet: i386-pc-linux-gnu
GCC target triplet: i386-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29950
[Bug rtl-optimization/29950] Generated code changes after unrelated edits in source.
--- Comment #1 from vda dot linux at googlemail dot com 2006-11-22 22:57 --- Created an attachment (id=12669) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12669&action=view) Visual comparison of assembly -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29950
[Bug rtl-optimization/29950] Generated code changes after unrelated edits in source.
--- Comment #2 from vda dot linux at googlemail dot com 2006-11-22 22:58 --- Created an attachment (id=12670) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12670&action=view) Complete testcase with .c, .o and .s files -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29950
[Bug tree-optimization/29921] [4.3 regression]: internal compiler error: in set_lattice_value, at tree-ssa-ccp.c:437
--- Comment #10 from rakdver at gcc dot gnu dot org 2006-11-22 23:11 --- Subject: Bug 29921 Author: rakdver Date: Wed Nov 22 23:11:15 2006 New Revision: 119102 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119102 Log: PR tree-optimization/29921 * fold-const.c (operand_equal_p): Without HONOR_SIGNED_ZEROS, consider signed and unsigned zero equal. * gcc.dg/pr29921.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr29921.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29921
[Bug libgomp/29949] implement argument checking for user accessable runtime routines
--- Comment #1 from franke dot daniel at gmail dot com 2006-11-22 23:12 --- Correction: checks are already implemented for environment variables. In above report OMP_NUM_THREADS is not affected, but omp_set_num_threads still is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29949
[Bug tree-optimization/29921] [4.3 regression]: internal compiler error: in set_lattice_value, at tree-ssa-ccp.c:437
--- Comment #11 from rakdver at gcc dot gnu dot org 2006-11-22 23:43 --- (In reply to comment #9) > Is HONOR_NANS missing somwhere? Not really, it is basically the same problem as the one with -0 -- for some time, ccp may believe that there might be a NaN (due to division by zero in case end were 0) even in this completely NaN-free program, and we end up changing the value of NaN in the lattice to a different constant (0). I am working on the fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29921
[Bug target/24036] [e500] ICE in subreg_offset_representable_p, at rtlanal.c:3143
--- Comment #6 from jsm28 at gcc dot gnu dot org 2006-11-23 00:16 --- Patch was discussed at http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00451.html and had some objections from Geoff Keating. I've come across another problem case and am testing another possible patch to address both cases. If you take an SImode subreg of a DFmode register, offset 4, that is the low word of the register and so is representable and subreg_regno_offset should return 0. But the conversion to integer units means that it acts like taking an SImode subreg of a DImode value (and so returns 1, taking the wrong register). I think the conversion to integer units is simply wrong in these cases. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added CC||jsm28 at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24036
[Bug target/29840] build/genconditions ../../gcc/gcc/config/pa/pa.md > tmp-condmd.c: /bin/sh: 13354 Memory fault(coredump)
--- Comment #2 from danglin at gcc dot gnu dot org 2006-11-23 00:25 --- Introduced by r118475. However, it wasn't fixed by Andrew's fwprop.c patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29840
[Bug target/29840] [4.3 Regression] build/genconditions ../../gcc/gcc/config/pa/pa.md > tmp-condmd.c: /bin/sh: 13354 Memory fault(coredump)
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|build/genconditions |[4.3 Regression] |../../gcc/gcc/config/pa/pa.m|build/genconditions |d > tmp-condmd.c: /bin/sh: |../../gcc/gcc/config/pa/pa.m |13354 Memory fault(coredump)|d > tmp-condmd.c: /bin/sh: ||13354 Memory fault(coredump) Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29840
[Bug fortran/17711] Wrong operator name in error message
--- Comment #5 from patchapp at dberlin dot org 2006-11-23 00:35 --- Subject: Bug number PR17711 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01590.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17711
[Bug libfortran/29936] Missed constraint on RECL=specifier in unformatted sequential WRITE
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2006-11-23 02:10 --- Actually the problem was that gfortran was failing to set the record length to the value requested in the OPEN statement. Now as far as emitting an error or warning I have a concern. If the user specifies a RECL= and the size of the output list in a WRITE exceeds that value, we should not lengthen the record. That implies truncating the output list. Based on that I think we should issue a runtime error. If the output list is shorter then RECL= then the balance of the record is undefined and we can just continue on. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29936
[Bug target/29943] [4.2/4.3 Regression] gcc generate incorrect alias symbols for PPC
-- 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|2006-11-22 22:21:39 |2006-11-23 02:12:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29943
[Bug target/29943] [4.2/4.3 Regression] gcc generate incorrect alias symbols for PPC
--- Comment #5 from dje at gcc dot gnu dot org 2006-11-23 02:31 --- If GCC is not creating the alias correctly, that is a bug. However, we previously agreed in PR 28598 that changing sections behind GCC's back is not guaranteed to work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29943
[Bug tree-optimization/29891] [4.3 Regression] libgcc2.c: In function '__gcc_bcmp': ICE: Segmentation fault
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-11-23 03:12 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29891
[Bug rtl-optimization/29924] [4.3 Regression] pr24626-4.c fails on powerpc-aix and others
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-11-23 03:13 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29924
[Bug target/29943] [4.2/4.3 Regression] gcc generate incorrect alias symbols for PPC
--- Comment #6 from richard at codesourcery dot com 2006-11-23 05:04 --- Subject: Re: [4.2/4.3 Regression] gcc generate incorrect alias symbols for PPC "amodra at bigpond dot net dot au" <[EMAIL PROTECTED]> writes: > AssignedTo|unassigned at gcc dot gnu |amodra at bigpond dot net >|dot org |dot au Thanks for taking this Alan. I'm happy to look at it if you like though. If it's section-anchor related, then it's my bug. Richard -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29943
