[Bug libfortran/26893] kinds.h not generated, causing failure
--- Comment #32 from fxcoudert at gcc dot gnu dot org 2007-01-19 07:12 --- Subject: Bug 26893 Author: fxcoudert Date: Fri Jan 19 07:12:16 2007 New Revision: 120949 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120949 Log: PR libfortran/26893 * acinclude.m4 (LIBGFOR_WORKING_GFORTRAN): New check. * configure.ac: Add call to LIBGFOR_WORKING_GFORTRAN. * configure: Regenerate. * config.h.in: Regenerate because it was forgottent in the last commit. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/acinclude.m4 trunk/libgfortran/config.h.in trunk/libgfortran/configure trunk/libgfortran/configure.ac -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26893
[Bug fortran/30507] error trying to exec 'f951': execvp: No such file
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-19 06:23 --- We the FSF does not support any binary releases so we cannot fix this. Yes the binaries are referenced from the wiki but they are not supported by us. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30507
[Bug c++/30508] Inherited inner template classes cannot access protected base data members
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-19 06:21 --- Yes and this is not a bug, GCC is correct i is not defined as i is not a dependent name so it gets bound at parsing time instead of doing instatitation. You might think because the base class is an inner template but you can specialize those too. Also read: http://gcc.gnu.org/gcc-3.4/changes.html Under "In a template definition, unqualified names will no longer find members of a dependent base (as specified by [temp.dep]/3 in the C++ standard). For example," -- 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=30508
[Bug c++/30508] New: Inherited inner template classes cannot access protected base data members
The code between the dashed lines generates these errors:
test2.cpp: In member function 'void outer_t::inner_derived_t::f2()':
test2.cpp:20: error: 'i' was not declared in this scope
command line:
$ cc -o test2 test2.cpp
If i is accessed through "this" pointer, the code compiles:
template
void outer_t::inner_derived_t::f2(void)
{
int i2 = this->i; // <-- this works
}
class outer_t {
public:
template
class inner_t {
protected:
int i;
};
template
class inner_derived_t : public inner_t {
public:
void f2(void);
};
};
template
void outer_t::inner_derived_t::f2(void)
{
int i2 = i; // <-- error
}
int main(int argc, char* argv[])
{
outer_t::inner_derived_t id;
id.f2();
return 0;
}
--
Summary: Inherited inner template classes cannot access protected
base data members
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: support at stonesteps dot ca
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30508
[Bug fortran/30507] New: error trying to exec 'f951': execvp: No such file
I downloaded the new I386 version of gfortran for the Mac, cloverm:>gfortran -v Using built-in specs. Target: i386-apple-darwin8.8.1 Configured with: ../gcc/configure --prefix=/usr/local/gfortran --enable-languages=c,fortran --with-gmp=/tmp/gfortran-20070104/gfortran_libs --enable-bootstrap Thread model: posix gcc version 4.3.0 20070104 (experimental) and tried to compile a program and got an error about f951 (which pattern is not in any of the files in the directory). I tried a second program and got the same result. I then went and downloaded the powerpc version of the compiler, and got the same error message. I get it with any *.f90 file I try. cloverm:~/bin/dplotr8_dir:[32]>gfortran -c -o dplotr8.o dplotr8.f gfortran: error trying to exec 'f951': execvp: No such file or directory I reverted to the earlier i386 version, >gfortran -v Using built-in specs. Target: i386-apple-darwin8.6.1 Configured with: ../gcc/configure --prefix=/usr/local/gfortran --enable-languages=c,f95 Thread model: posix gcc version 4.2.0 20060522 (experimental) and this version proceeded to compile the source just fine. -- Summary: error trying to exec 'f951': execvp: No such file Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mclover at san dot rr dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30507
[Bug middle-end/30503] ICE using phase 2 bootstrap output cc1 on tree.c
--- Comment #8 from dberlin at gcc dot gnu dot org 2007-01-19 03:55 --- Okay, well, this is pretty simple. If we can't reproduce the bug (and i can't, and andrew can't), we can't fix it. So this bug is just going to stay open forever until then, regardless of whether it's a hardware failure, a kernel bug, or a gcc bug. -- dberlin at gcc dot gnu dot org changed: What|Removed |Added CC|dberlin at gcc dot gnu dot | |org | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30503
[Bug middle-end/20218] Can't use __attribute__ ((visibility ("hidden"))) to hide a symbol
--- Comment #51 from redfive at songbirdnest dot com 2007-01-19 03:25 --- I believe I'm seeing this bug using a redhat build: gcc4.1.1-1 (shows up all the way through -51). It's only on 64bit FC5, 32bit is okay and am installing FC6 to test. Building XULRunner with --enable-canvas causes the problem, greater description of what I'm seeing is in their bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=367208 Basically a hidden symbol from .o to .a to linking in a .so gives the error listed by the reporter here. I can't tell from the comments which build will carry this patch. It looks like it would be in 4.1, but the last comment re: backporting makes me wonder. Also I wonder if this patch would have been pulled in to the Redhat build; I'm not familiar with the relationship to the main gcc tree. Thanks! -- redfive at songbirdnest dot com changed: What|Removed |Added CC||redfive at songbirdnest dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20218
[Bug tree-optimization/29516] gfortran miscompiled
--- Comment #35 from howarth at nitro dot med dot uc dot edu 2007-01-19 03:02 --- It appears that r118856, r119854 and r120156 be backported for the context of the patch for r120695 to be correct in gcc 4.2 branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29516
[Bug middle-end/30503] ICE using phase 2 bootstrap output cc1 on tree.c
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-01-19 00:24 --- (In reply to comment #6) > Mr Pinski > I do not appreciate your comment. But my point was I know if you having hardware issues you will have some issues with segfaults and other random internal compiler errors. In fact my machine overheats all the time and I get a random segfault. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30503
[Bug middle-end/30503] ICE using phase 2 bootstrap output cc1 on tree.c
--- Comment #6 from malitzke at metronets dot com 2007-01-19 00:20 --- Mr Pinski I do not appreciate your comment. My comment 3 was really addressed to people like you who want to garner points as beiong the big killers of problem reports by using cheap tactics. With four processors and 3 Gigabytes of error correcting menory it is highly unlikely that the test cases I ran started each time at the same location to cause consistently repeatable failures. Remember what a fellow gcc.gnu.org mantainer recently said about your attitude. I can only aver that he was right. I was hoping you would have learned a lesson. You actually used a PR I filed about glibc to make a point like this one to the glibc people. If you want a flame war let me say that have collected a number of cases concerning your behaviour. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30503
[Bug libgcj/30454] [4.3 Regression] classpath/gnu/javax/crypto/jce/GnuCrypto.java:431: error: cannot find file for class gnu.javax.crypto.jce.mac.HMacSHA512Spi
--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2007-01-19 00:08 --- Subject: Re: [4.3 Regression] classpath/gnu/javax/crypto/jce/GnuCrypto.java:431: error: cannot find file for class gnu.javax.crypto.jce.mac.HMacSHA512Spi > I'd like to see more of the build log, in particular what happened > before the failing command. Attached. > Does the failing gcj invocation work if you try it from the command > line? Try it with -v, too, since that may be interesting. No. Also attached is output using gcj -v. > > cannot find file for class gnu.javax.crypto.jce.mac.HMacSHA512Spi > > Look in trunk/libjava/classpath/lib/gnu/javax/crypto/jce/mac. > Does HMacSHA512Spi.class exist? Yes. Dave --- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2007-01-19 00:08 --- Created an attachment (id=12921) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12921&action=view) --- Comment #8 from dave at hiauly1 dot hia dot nrc dot ca 2007-01-19 00:08 --- Created an attachment (id=12922) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12922&action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30454
[Bug libgcj/27823] Found a problem with the JNI methods declared and implemented
--- Comment #23 from rob1weld at aol dot com 2007-01-18 23:52 --- I compiled 4.1.1 on Windows XP (Cygwin) a couple of days ago and did not have the "Found a problem with the JNI methods declared and implemented." message occur. Last week when I compiled gcc-4_2-branch (SVN) the error did not occur. Today, when I recompiled 4.2.0 it DID occur. I am using the same parameters to configure (and compiling in a different directory than the source) as I did previously so either the SVN source breakage is recent (for i686-pc-cygwin platform) or my system had something occur recently to change things. I am using the same (lengthy) parameters for both 4.1.1 and 4.2.0 (though 4.2.0 has more implemented when these same parameters are used). I am concerned that the list is rather long, here is part of it: make[6]: Entering directory `/cygdrive/c/gcc-4_2-branch-build/i686-pc-cygwin/libjava/classpath/native/jni' cd /cygdrive/C/makecygwin/gcc-4_2-branch/libjava/classpath && /bin/sh ./scripts/check_jni_methods.sh Found a problem with the JNI methods declared and implemented. (-) missing in implementation, (+) missing in header files +Java_gnu_java_awt_peer_gtk_CairoGraphics2D_cairoArc +Java_gnu_java_awt_peer_gtk_CairoGraphics2D_cairoClip +Java_gnu_java_awt_peer_gtk_CairoGraphics2D_cairoClosePath +Java_gnu_java_awt_peer_gtk_CairoGraphics2D_cairoCurveTo +Java_gnu_java_awt_peer_gtk_CairoGraphics2D_cairoDrawGlyphVector +Java_gnu_java_awt_peer_gtk_CairoGraphics2D_cairoDrawLine ... +Java_gnu_xml_libxmlj_sax_GnomeLocator_systemId +Java_gnu_xml_libxmlj_sax_GnomeXMLReader_parseStream +Java_gnu_xml_libxmlj_transform_GnomeTransformerFactory_freeLibxsltGlobal +Java_gnu_xml_libxmlj_transform_GnomeTransformer_free +Java_gnu_xml_libxmlj_transform_GnomeTransformer_newStylesheet +Java_gnu_xml_libxmlj_transform_GnomeTransformer_newStylesheetFromDoc +Java_gnu_xml_libxmlj_transform_GnomeTransformer_newStylesheetFromStream +Java_gnu_xml_libxmlj_transform_GnomeTransformer_transformDocToDoc +Java_gnu_xml_libxmlj_transform_GnomeTransformer_transformDocToSAX +Java_gnu_xml_libxmlj_transform_GnomeTransformer_transformDocToStream +Java_gnu_xml_libxmlj_transform_GnomeTransformer_transformStreamToDoc +Java_gnu_xml_libxmlj_transform_GnomeTransformer_transformStreamToSAX +Java_gnu_xml_libxmlj_transform_GnomeTransformer_transformStreamToStream make[6]: *** [all-local] Error 1 Looking through the long list I noticed this group and set out to find it: +Java_gnu_java_util_prefs_gconf_GConfNativePeer_gconf_1client_1add_1dir +Java_gnu_java_util_prefs_gconf_GConfNativePeer_gconf_1client_1dir_1exists +Java_gnu_java_util_prefs_gconf_GConfNativePeer_gconf_1client_1gconf_1client_1all_1keys +Java_gnu_java_util_prefs_gconf_GConfNativePeer_gconf_1client_1gconf_1client_1all_1nodes +Java_gnu_java_util_prefs_gconf_GConfNativePeer_gconf_1client_1get_1string +Java_gnu_java_util_prefs_gconf_GConfNativePeer_gconf_1client_1remove_1dir +Java_gnu_java_util_prefs_gconf_GConfNativePeer_gconf_1client_1set_1string +Java_gnu_java_util_prefs_gconf_GConfNativePeer_gconf_1client_1suggest_1sync +Java_gnu_java_util_prefs_gconf_GConfNativePeer_gconf_1client_1unset I found it in my SOURCE directory (not my build directry). It is odd that make runs commands that toss files into your source directory - seems to run against general principles of having the directories seperate. I looked at this file that gcjh had created - /cygdrive/C/makecygwin/gcc-4_2-branch/libjava/classpath/include/gnu_java_util_prefs_gconf_GConfNativePeer.h and found this in it: extern JNIEXPORT void JNICALL Java_gnu_java_util_prefs_gconf_GConfNativePeer_init_1id_1cache (JNIEnv *env, jclass); extern JNIEXPORT void JNICALL Java_gnu_java_util_prefs_gconf_GConfNativePeer_init_1class (JNIEnv *env, jclass); extern JNIEXPORT void JNICALL Java_gnu_java_util_prefs_gconf_GConfNativePeer_finalize_1class (JNIEnv *env, jclass); extern JNIEXPORT jboolean JNICALL Java_gnu_java_util_prefs_gconf_GConfNativePeer_gconf_1client_1dir_1exists (JNIEnv *env, jclass, jstring); extern JNIEXPORT void JNICALL Java_gnu_java_util_prefs_gconf_GConfNativePeer_gconf_1client_1add_1dir (JNIEnv *env, jclass, jstring); extern JNIEXPORT void JNICALL Java_gnu_java_util_prefs_gconf_GConfNativePeer_gconf_1client_1remove_1dir (JNIEnv *env, jclass, jstring); extern JNIEXPORT jboolean JNICALL Java_gnu_java_util_prefs_gconf_GConfNativePeer_gconf_1client_1set_1string (JNIEnv *env, jclass, jstring, jstring); extern JNIEXPORT jstring JNICALL Java_gnu_java_util_prefs_gconf_GConfNativePeer_gconf_1client_1get_1string (JNIEnv *env, jclass, jstring); extern JNIEXPORT jboolean JNICALL Java_gnu_java_util_prefs_gconf_GConfNativePeer_gconf_1client_1unset (JNIEnv *env, jclass, jstring); extern JNIEXPORT void JNICALL Java_gnu_java_util_prefs_gconf_GConfNativePeer_gconf_1client_1suggest_1sync (JNIEnv *env, jclass); extern JNIEXPORT jobject JNICALL Java_gnu_java_util_prefs_gconf_GConfNativePeer_gconf_1client_1gconf_1client_1all_1nodes (JNIEnv *env, jclass, j
[Bug fortran/30481] Accepts namelist-group object with assumed character length
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-01-18 23:50 --- Tobias, let me know if you don't have time and I will take care of this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30481
[Bug middle-end/30503] ICE using phase 2 bootstrap output cc1 on tree.c
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-01-18 23:45 --- Are you sure you don't have bad memory? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30503
[Bug c/30503] ICE using phase 2 bootstrap output cc1 on tree.c
--- Comment #4 from malitzke at metronets dot com 2007-01-18 23:40 --- Well , the mistery continues. First when I referred to patchlevels I left out a 0 (zero); 12900 should read 120900. Second I repeated the bootstrap because a number of patches from Daniel Berlin looked promising to me. Now instead o just hanging at "checking for i686-pc-linux-gnu-pcc" in gearing up for pass 3 in "i686-pc-linux-gnu/libgcc" it allocated itself 2.7G of memory before going on to "checking for suffix of object files ..." it grabbed 2.8 G memory of my 3+G and issued "configure: error: cannot compute suffix of objectfiles: cannot compile. The memory grabbing was checked with the utility "top". Checking cc1 with tree.i gave essentially the same results as before. I could send in the details if wanted. -- malitzke at metronets dot com changed: What|Removed |Added CC||dnovillo at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30503
[Bug target/30506] not sibcalling a function
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30506
[Bug target/30506] not sibcalling a function
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-01-18 23:26 --- (In reply to comment #2) > hmm, you've a right, so could we rework the bug to some kind > of feature-request? i'd love to see the stack cleanup before f() call. Actually for this case, we just need to have f sibcalled and now the reason why it is not sibcalled is a different reason and target dependent issue now because it is sibcalled on ppc. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|middle-end |target GCC target triplet||x86-64-linux-gnu Summary|violation of automatic |not sibcalling a function |storage duration| |[basic.stc.auto 3.7.2/1]. | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30506
[Bug middle-end/30506] violation of automatic storage duration [basic.stc.auto 3.7.2/1].
--- Comment #2 from pluto at agmk dot net 2007-01-18 23:23 --- (In reply to comment #1) > This is not really a violation of that rule at all. What that rule is stating > is that if you access that array again outside of the block where it was > created, you invoke undefined behavior. hmm, you've a right, so could we rework the bug to some kind of feature-request? i'd love to see the stack cleanup before f() call. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30506
[Bug middle-end/30506] violation of automatic storage duration [basic.stc.auto 3.7.2/1].
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-18 23:15 --- This is not really a violation of that rule at all. What that rule is stating is that if you access that array again outside of the block where it was created, you invoke undefined behavior. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30506
[Bug middle-end/30506] New: violation of automatic storage duration [basic.stc.auto 3.7.2/1].
consider following testcase:
void f( char );
void g( char c )
{
{
char buf[ 128 * 1024 ];
__builtin_memset( buf, 0, sizeof( buf ) );
c = buf[ 0 ];
}
f( c );
}
3.7.2/1:
"(...) the storage for these objects lasts until the block
in which they are created exits."
in fact gcc-4.2 keeps allocated storage until the end of function.
such situation may lead to stack overflow during few recursive f->g calls.
$ g++ local_buf.cpp -O2 -Wall -S
g(char):
subq$131080, %rsp
movl$131072, %edx
xorl%esi, %esi
movq%rsp, %rdi
callmemset
movsbl (%rsp),%edi
callf(char)
addq$131080, %rsp
ret
--
Summary: violation of automatic storage duration [basic.stc.auto
3.7.2/1].
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at agmk dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30506
[Bug inline-asm/30505] [4.2 regression] asm operand has impossible constraints.
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-01-18 22:41 --- Except we did not do that in 3.3.x either. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30505
[Bug inline-asm/30505] [4.2 regression] asm operand has impossible constraints.
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-18 22:40 ---
I think the problem is that we don't combine
(subreg:SI (reg:DI 63) 0)
with
(insn 11 10 12 2 (parallel [
(set (reg:DI 63)
(lshiftrt:DI (reg:DI 61 [ dividend.0 ])
(const_int 32 [0x20])))
(clobber (reg:CC 17 flags))
]) 322 {*lshrdi3_1} (insn_list:REG_DEP_TRUE 10 (nil))
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
into:
(subreg:SI (reg:DI 63) 4)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30505
[Bug inline-asm/30505] New: [4.2 regression] asm operand has impossible constraints.
following testcase works fine with gcc-3.3/4.1:
typedef unsigned long long uint64;
typedef unsigned uint32;
uint64 dividend;
uint32 divisor;
uint64 quotient;
uint32 remainder;
void div643264( )
{
uint32 hQuotient;
uint32 lQuotient;
__asm__(
"divl %5""\n\t"
"movl %%eax, %0" "\n\t"
"movl %4, %%eax" "\n\t"
"divl %5"
: "=&rm" (hQuotient), //0 r/m
"=a" (lQuotient), //1 eax
"=d" (remainder) //2 edx
: "1" ((uint32)(dividend >> 32)), //3 eax
"g" ((uint32)dividend), //4 r/m
"rm" (divisor), //5 r/m
"2" (0) //6 edx
: "cc"
);
quotient = (uint64)hQuotient << 32 | lQuotient;
}
e.g. 4.1 produces:
$ gcc div.c -fno-builtin -S -O2 && cat div.s
div643264:
pushl %ebp
movl%esp, %ebp
subl$12, %esp
movldividend, %ecx
movl%ebx, (%esp)
movldividend+4, %ebx
movl%esi, 4(%esp)
xorl%esi, %esi
movl%edi, 8(%esp)
movl%esi, %edx
movl4(%esp), %esi
movl%ebx, %ecx
xorl%ebx, %ebx
movl%ecx, %eax
#APP
divl divisor
movl %eax, %edi
movl dividend, %eax
divl divisor
#NO_APP
movl%eax, %ebx
movl%edi, %eax
movl%edx, remainder
xorl%edx, %edx
movl%eax, %edx
movl%ebx, quotient
movl%edx, quotient+4
movl(%esp), %ebx
movl$0, %eax
movl8(%esp), %edi
leave
ret
4.2 rejects such code.
div.c: In function ‘div643264’:
div.c:15: error: ‘asm’ operand has impossible constraints
--
Summary: [4.2 regression] asm operand has impossible constraints.
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at agmk dot net
GCC target triplet: i686
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30505
[Bug c++/30504] Error when linking. Trying to create a library
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-18 22:12 --- How are you creating a library with -static? The command line you posted looks more like you are linking in all of libc, libgcc, libstdc++ which all seems wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30504
[Bug c++/30504] New: Error when linking. Trying to create a library
Hi, I am trying to create a C++ library and when doing a linking I am getting the following error. Here is the command g++ -static -static-libgcc -Wl,-bexpfull,-bnoentry,-brtl -o libAllocation.so *.o -L/vol.rtk/compilers/aix5.1.gcc-3.3/lib/gcc-lib/powerpc-ibm-aix5.1.0.0/3.3 -lgcc -lstdc++ -lc -lm The error reported is ld: 0711-317 ERROR: Undefined symbol: .std::basic_string, std::allocator >::size() const ld: 0711-317 ERROR: Undefined symbol: .std::allocator::allocator() ld: 0711-317 ERROR: Undefined symbol: .std::allocator::~allocator() ld: 0711-317 ERROR: Undefined symbol: .std::basic_string, std::allocator >::c_str() const ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. When I am using the -bnoquiet option addition messages for error ld: 0711-317 ERROR: Undefined symbol: .std::basic_string, std::allocator >::size() const .std::basic_string, std::allocator >::size() const[2] ER PR VersionUtil.cpp(VersionUtil.o) 002c .textR_RBR[22] .VersionUtil::getRevision(std::basic_string, std::allocator > const&) 00dc .textR_RBR[24] .VersionUtil::getModtime(std::basic_string, std::allocator > const&) ld: 0711-317 ERROR: Undefined symbol: .std::allocator::allocator() .std::allocator::allocator()[70]ER PR casepack_cp_heur.cpp(casepack_cp_heur.o) 00012154 .textR_RBR[594] .casePackAllocation_CP(bool, int, int, int, double**, double**, bool, int**, int**, int**, int**, int*, int**, int**, int*, bool&, int*, int*, double*) .std::allocator::allocator()[8] ER PR VersionUtil.cpp(VersionUtil.o) 01c0 .textR_RBR[26] .VersionUtil::getArchive(std::basic_string, std::allocator > const&) 02c4 .textR_RBR[26] .VersionUtil::getArchive(std::basic_string, std::allocator > const&) Could you please let me know what needs to be done to solve this error. Thanks Dham -- Summary: Error when linking. Trying to create a library Product: gcc Version: 3.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dams_napp at hotmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30504
[Bug libfortran/30415] MINLOC, MAXLOC missing for integer kinds 1 and 2
--- Comment #5 from tkoenig at gcc dot gnu dot org 2007-01-18 21:58 --- Fixed on trunk and 4.2. Closing. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30415
[Bug libfortran/30415] MINLOC, MAXLOC missing for integer kinds 1 and 2
--- Comment #4 from tkoenig at gcc dot gnu dot org 2007-01-18 21:57 --- Subject: Bug 30415 Author: tkoenig Date: Thu Jan 18 21:56:53 2007 New Revision: 120932 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120932 Log: 2007-01-18 Thomas Koenig <[EMAIL PROTECTED]> Backport from trunk PR libfortran/30415 * iresolve.c (gfc_resolve_maxloc): If the rank of the return array is nonzero and we process an integer array smaller than default kind, coerce the array to default integer. * iresolve.c (gfc_resolve_minloc): Likewise. 2007-01-18 Thomas Koenig <[EMAIL PROTECTED]> Backport from trunk PR libfortran/30415 * minmaxloc_integer_kinds_1.f90: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/minmaxloc_integer_kinds_1.f90 Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/iresolve.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30415
[Bug bootstrap/30136] bootstrap fail for 4.3-20061209
--- Comment #7 from rkrylov at mail dot ru 2007-01-18 19:53 --- I got same result with --with-cpu=athlon64 on gcc-4.3-20070112 snapshot. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30136
[Bug libfortran/22423] Warnings when building libgfortran
--- Comment #11 from fxcoudert at gcc dot gnu dot org 2007-01-18 19:32 --- (In reply to comment #10) >So are you going to use the fix I proposed in comment 8? Yes. > Do you want me to > submit it to the patch mailing list first? No, it's been posted a few times already, and I've also discussed it on IRC a few times with other people, so it can be considered approved (or, to have someone accountable in case of trouble: I approve it :) I'll commit it when I get to it (over the week-end?) Anyone feel free to do it (after bootstrap and regesteing) if you don't see it commited in the next few days. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22423
[Bug c/30502] compiler inlines slightly invalid function without warning
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-01-18 19:25 --- (In reply to comment #2) > > With '-fno-inline' compiler generates very useful warning - the return > stmt has been missing. > > This is my point. Right and this was fixed in 4.0.0 and above as shown by the warnings output I gave. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30502
[Bug c/30502] compiler inlines slightly invalid function without warning
--- Comment #2 from yakov at emc dot com 2007-01-18 19:18 --- Subject: Re: compiler inlines slightly invalid function without warning gcc -O2 -Wall -c -fno-inline rtv.c rtv.c: In function `compute_tables_error_code': rtv.c:18: warning: control reaches end of non-void function gcc -O2 -Wall -c rtv.c <-- no warning here With '-fno-inline' compiler generates very useful warning - the return stmt has been missing. This is my point. sincerely, yakov pinskia at gcc dot gnu dot org wrote: >--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-18 18:00 >--- >I think you mean the following options: >-O2 -Wall -Winline >and with 4.0.0 and above I get: >t.c:9: warning: control may reach end of non-void function >'compute_tables_error_code' being inlined >or: >t.c: In function 'compute_tables_error_code': >t.c:19: warning: control reaches end of non-void function > >PS this is not really invalid code, just undefined code. > > > > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30502
[Bug libfortran/22423] Warnings when building libgfortran
--- Comment #10 from howarth at nitro dot med dot uc dot edu 2007-01-18 19:18 --- FX, So are you going to use the fix I proposed in comment 8? Do you want me to submit it to the patch mailing list first? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22423
[Bug c/30503] ICE using phase 2 bootstrap output cc1 on tree.c
--- Comment #3 from malitzke at metronets dot com 2007-01-18 18:52 --- Prior to patclevel 12900 (about 12880) bootstrap failed even with O1 with segment error. For those dismissive folks who either say "It works for me" or claim that it is the submitters harware fault I can only aver the following: The work was done on a four processor server with 3G error correcting memory andover the last three weeks similar Segmentation errors occured; I have tried different binutils and different versions of glibc. I realize GCC-main is undergoing drastic changes right now. day before yesterday cc1 (from phse 1) worked with O1 and bombed out with O2. I doubt this cand be reduced to a simple test case as it occurs when trying to optimize across procedures. Glad to cooperate further. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30503
[Bug libfortran/30007] libgfortran doesn't build for sh-elf
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-01-18 18:49
---
(In reply to comment #5)
> __USER_LABEL_PREFIX__ should be a string already.
>
> so you just need:
> extern void bar (void);
> extern __typeof(bar) bar __asm__(__USER_LABEL_PREFIX__ "foo");
> void bar (void) { ; }
> extern __typeof(bar) gee __attribute__((__alias__("foo")));
That one gives: c.c:2: error: expected string literal before _
__USER_LABEL_PREFIX__ is a string in the compiler config macros. For user code,
the macro expands to the underscore itself.
Actually, the problem with libgfortran is that it uses __USER_LABEL_PREFIX__
already, but it uses it for both __asm__ and __attribute__((__alias__(...))),
which is wrong. I'm testing the following patch, but I should really test it on
a machine that has a non-empty __USER_LABEL_PREFIX__. Any idea?
Index: libgfortran.h
===
--- libgfortran.h (revision 120891)
+++ libgfortran.h (working copy)
@@ -126,10 +126,10 @@
# define export_proto(x) sym_rename(x, PREFIX(x))
# define export_proto_np(x)extern char swallow_semicolon
# define iexport_proto(x) internal_proto(x)
-# define iexport(x)iexport1(x, __USER_LABEL_PREFIX__, IPREFIX(x))
-# define iexport1(x,p,y) iexport2(x,p,y)
-# define iexport2(x,p,y) \
- extern __typeof(x) PREFIX(x) __attribute__((__alias__(#p #y)))
+# define iexport(x)iexport1(x, IPREFIX(x))
+# define iexport1(x,y) iexport2(x,y)
+# define iexport2(x,y) \
+ extern __typeof(x) PREFIX(x) __attribute__((__alias__(#y)))
/* ??? We're not currently building a dll, and it's wrong to add dllexport
to objects going into a static library archive. */
#elif 0 && defined(HAVE_ATTRIBUTE_DLLEXPORT)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30007
[Bug c/30503] ICE using phase 2 bootstrap output cc1 on tree.c
--- Comment #2 from malitzke at metronets dot com 2007-01-18 18:38 --- Created an attachment (id=12920) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12920&action=view) Standard preprocessed file This file was created using the xgcc resulting from phase 2. I have another file tree.i using the phase 1 xgcc this differs on in the includes referenced. The includes diff equal for phase 1 and 2 (spot checks only) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30503
[Bug c/30503] ICE using phase 2 bootstrap output cc1 on tree.c
--- Comment #1 from malitzke at metronets dot com 2007-01-18 18:31 --- Created an attachment (id=12919) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12919&action=view) Detailed out using different optimization levels I also have similar output using Phase 1 cc1 (also at different otimization levels). In another attachment I am submitting tree.i. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30503
[Bug c/30503] New: ICE using phase 2 bootstrap output cc1 on tree.c
Using the phase 2 cc1 on tree.c results in a segmentation error. Phase 1 cc1 does not result in segmentation faults. This is on main at patchlevel 12900. Command: /var/tmp/gcc_r43/gcc.build.lnx14/gcc/xgcc -v -save-temps -B/var/tmp/gcc_r43/gcc.build.lnx14/gcc/ -B/usr/i686-pc-linux-gnu/bin/ -c -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute-DHAVE_CONFIG_H -I. -I. -I../../gcc-4.3.0/gcc -I../../gcc-4.3.0/gcc/. -I../../gcc-4.3.0/gcc/../include -I../../gcc-4.3.0/gcc/../libcpp/include -I../../gcc-4.3.0/gcc/../libdecnumber -I../libdecnumber../../gcc-4.3.0/gcc/tree.c -o tree.o Output: Reading specs from /var/tmp/gcc_r43/gcc.build.lnx14/gcc/specs Target: i686-pc-linux-gnu Configured with: ../gcc-4.3.0/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.3.0 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.3.0/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.3.0 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.3.0/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.3.0/info --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.3.0/include/g++-v4 --enable-version-specific-runtime-libs --disable-nls --disable-checking --disable-werror --disable-multilib --disable-libgcj --disable-dssi --disable-checking --enable-shared --enable-threads=posix --enable-bootstrap --enable-__cxa_atexit --enable-languages=c,c++,fortran --with-cpu=pentium2 --with-system-zlib --enable-clocale=gnu Thread model: posix gcc version 4.3.0 20070118 (experimental) /var/tmp/gcc_r43/gcc.build.lnx14/gcc/cc1 -E -quiet -v -I. -I. -I../../gcc-4.3.0/gcc -I../../gcc-4.3.0/gcc/. -I../../gcc-4.3.0/gcc/../include -I../../gcc-4.3.0/gcc/../libcpp/include -I../../gcc-4.3.0/gcc/../libdecnumber -I../libdecnumber -iprefix /var/tmp/gcc_r43/gcc.build.lnx14/gcc/../../../lib/gcc/i686-pc-linux-gnu/4.3.0/ -isystem /var/tmp/gcc_r43/gcc.build.lnx14/gcc/include -DIN_GCC -DHAVE_CONFIG_H ../../gcc-4.3.0/gcc/tree.c -mtune=pentium2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -O2 -fpch-preprocess -o tree.i ignoring nonexistent directory "/var/tmp/gcc_r43/gcc.build.lnx14/gcc/../../../lib/gcc/i686-pc-linux-gnu/4.3.0/include" ignoring nonexistent directory "/var/tmp/gcc_r43/gcc.build.lnx14/gcc/../../../lib/gcc/i686-pc-linux-gnu/4.3.0/../../../../i686-pc-linux-gnu/include" ignoring nonexistent directory "/var/tmp/gcc_r43/gcc.build.lnx14/gcc/../../../lib/gcc//lib/gcc/i686-pc-linux-gnu/4.3.0/include" ignoring nonexistent directory "/var/tmp/gcc_r43/gcc.build.lnx14/gcc/../../../lib/gcc//lib/gcc/i686-pc-linux-gnu/4.3.0/../../../../i686-pc-linux-gnu/include" ignoring duplicate directory "." ignoring duplicate directory "../../gcc-4.3.0/gcc/." #include "..." search starts here: #include <...> search starts here: . ../../gcc-4.3.0/gcc ../../gcc-4.3.0/gcc/../include ../../gcc-4.3.0/gcc/../libcpp/include ../../gcc-4.3.0/gcc/../libdecnumber ../libdecnumber /var/tmp/gcc_r43/gcc.build.lnx14/gcc/include /usr/local/include /usr/include End of search list. /var/tmp/gcc_r43/gcc.build.lnx14/gcc/cc1 -fpreprocessed tree.i -quiet -dumpbase tree.c -mtune=pentium2 -auxbase-strip tree.o -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -version -o tree.s GNU C version 4.3.0 20070118 (experimental) (i686-pc-linux-gnu) compiled by GNU C version 4.3.0 20070118 (experimental). GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 43ce5038e422d0a4c380c402a468014e ../../gcc-4.3.0/gcc/tree.c: In function 'int_cst_hash_hash': ../../gcc-4.3.0/gcc/tree.c:8131: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- Summary: ICE using phase 2 bootstrap output cc1 on tree.c Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: malitzke at metronets dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30503
[Bug middle-end/30421] incorrect warning when using firstprivate and lastprivate clauses
--- Comment #4 from jakub at gcc dot gnu dot org 2007-01-18 18:23 --- Testing a fix. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-01-18 18:23:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30421
[Bug c++/17854] Accept statement expressions at top level
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-01-18 18:10 --- *** Bug 30496 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||csandu4096 at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17854
[Bug c++/30496] Compilation errors when compiled with optimization flags
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-01-18 18:10 --- Ok, what is happening here is that gettext is defined to be a statement expression with optimization. And in C++, right now, we don't allow a statement expression not be in a function (this is a silly constraint). The silly constraint is recorded as PR 17854, I am marking this as a dup of that bug. In a way this is a gettext bug and should reported to them also. *** This bug has been marked as a duplicate of 17854 *** -- 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=30496
[Bug c++/30499] gcc segfault on linux kernel 2.6.17.10
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-01-18 18:06 --- Can you rerun the command which is failing and add -save-temps and then attach the resulting .i file if the segfault appears? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30499
[Bug c/29521] Confusing warning for return with expression in function returning void
--- Comment #2 from patchapp at dberlin dot org 2007-01-18 18:05 --- Subject: Bug number PR 29521 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/2007-01/msg01533.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29521
[Bug c/30502] compiler inlines slightly invalid function without warning
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-18 18:00 --- I think you mean the following options: -O2 -Wall -Winline and with 4.0.0 and above I get: t.c:9: warning: control may reach end of non-void function 'compute_tables_error_code' being inlined or: t.c: In function 'compute_tables_error_code': t.c:19: warning: control reaches end of non-void function PS this is not really invalid code, just undefined code. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30502
[Bug libfortran/30498] Support traceback (backtrace) on errors
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-01-18 17:59 --- (In reply to comment #0) > "It was mentionned on IRC tonight that Daniel Berlin has a library that > extracts line and file information from DWARF2 info. It's internal to Google, > but he > said he'll see if he can get it released. We'll have to get back to him in > some > time..." I since spoke to him again, and we'd better go ahead with our current plan. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-01-18 17:59:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30498
[Bug libfortran/30007] libgfortran doesn't build for sh-elf
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-01-18 17:52 ---
__USER_LABEL_PREFIX__ should be a string already.
so you just need:
extern void bar (void);
extern __typeof(bar) bar __asm__(__USER_LABEL_PREFIX__ "foo");
void bar (void) { ; }
extern __typeof(bar) gee __attribute__((__alias__("foo")));
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30007
[Bug libfortran/22423] Warnings when building libgfortran
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2007-01-18 17:45 --- Once that last warning is fixed, I'd really like libgfortran to be built with -Werror by default, at least on linux systems (it's known to issue tons of warnings on some non-C99 systems, so we can't make it the default unconditionaly). -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-10-01 07:43:53 |2007-01-18 17:45:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22423
[Bug bootstrap/30495] can't compile on AIX
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-01-18 17:44 --- > I mean genattrtab is trying to allocate 4 gigs of mem No, that is how much it allocated overall, not how much is actually still in use. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30495
[Bug c/30475] assert(int+100 > int) optimized away
--- Comment #29 from pinskia at gcc dot gnu dot org 2007-01-18 17:36 --- Oh and I meant "at", not get or []. at does bounds checking. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
[Bug libfortran/30007] libgfortran doesn't build for sh-elf
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-01-18 17:28
---
So, the reduced code looks like this:
extern void bar (void);
extern __typeof(bar) bar __asm__("foo");
void bar (void) { ; }
extern __typeof(bar) gee __attribute__((__alias__("foo")));
Ian Lance Taylor gave me the solution on IRC, which is: on SH, all symbol names
are preprended an underscore, but in the above code __asm__("foo") does not
prepend it for us. The macro defined for this underscore (and other such
prefixes on other targets, although I don't any in particular) is
__USER_LABEL_PREFIX__, so the final fix is:
#define stringize(x) expand_macro(x)
#define expand_macro(x) # x
extern void bar (void);
extern __typeof(bar) bar __asm__(stringize(__USER_LABEL_PREFIX__) "foo");
void bar (void) { ; }
extern __typeof(bar) gee __attribute__((__alias__("foo")));
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
Last reconfirmed|2007-01-05 10:10:35 |2007-01-18 17:28:42
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30007
[Bug tree-optimization/30440] internal compiler error: in find_or_generate_expression, at tree-ssa-pre.c:1472
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-01-18 17:20 --- (In reply to comment #11) > Any help? Yes to compile the snapshot (and SVN) you need bision. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30440
[Bug c/30502] New: compiler inlines slightly invalid function without warning
Reading specs from /bin/../lib/gcc/i686-pc-linux-gnu/3.4.6/specs
Configured with: gcc/configure --enable-languages=c,c++ --disable-nls
--disable-c-mbchar --disable-multilib --with-gnu-as --with-gnu-ld
rtv.c ---
extern int putchar (int c);
static int __inline__ compute_tables_error_code ( int ots );
int main (void)
{
int err_code = putchar('z');
if (compute_tables_error_code (err_code))
return 1;
else
return 0;
}
static int __inline__ compute_tables_error_code ( int ots )
{
if ( ots )
return 0x85;
}
rtv.c ---
gcc -Wall -O2 -fno-inline -Winline rtv.c
rtv.c: In function `compute_tables_error_code':
rtv.c:18: warning: control reaches end of non-void function
rtv.c: In function `main':
rtv.c:15: warning: inlining failed in call to `compute_tables_error_code'
rtv.c:8: warning: called from here
--
Summary: compiler inlines slightly invalid function without
warning
Product: gcc
Version: 3.4.6
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yakov at emc dot com
GCC target triplet: gcc version 3.4.6 (SuSE Linux)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30502
[Bug target/30485] ICE in rs6000_emit_vector_compare when building with -fno-trapping-math
--- Comment #2 from jconner at gcc dot gnu dot org 2007-01-18 16:45 --- Subject: Bug 30485 Author: jconner Date: Thu Jan 18 16:44:50 2007 New Revision: 120903 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120903 Log: 2007-01-18 Josh Conner <[EMAIL PROTECTED]> PR target/30485 * gcc.dg/vect/vect.exp: Add support for no-trapping-math tests. * gcc.dg/vect/no-trapping-math-1: New. * gcc.dg/vect/no-trapping-math-2: New. Added: trunk/gcc/testsuite/gcc.dg/vect/no-trapping-math-1.c trunk/gcc/testsuite/gcc.dg/vect/no-trapping-math-2.c Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/vect.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30485
[Bug target/30485] ICE in rs6000_emit_vector_compare when building with -fno-trapping-math
--- Comment #1 from jconner at gcc dot gnu dot org 2007-01-18 16:44 --- Subject: Bug 30485 Author: jconner Date: Thu Jan 18 16:44:03 2007 New Revision: 120902 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120902 Log: 2007-01-18 Josh Conner <[EMAIL PROTECTED]> PR target/30485 * config/rs6000/rs6000.c (rs6000_emit_vector_compare): Add support for UNLE, UNLT, UNGE, and UNGT. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30485
[Bug ada/30501] New: GNAT BUG BOX: 16-bit target & Standard.Integer
[EMAIL PROTECTED]:~/tmp/GNAT_Test$ m32c-elf-gcc -v -gnatv -gnatS -S --RTS=rts integer_test.ads Using built-in specs. Target: m32c-elf Configured with: ../gcc-4.2-20070110/configure --target=m32c-elf --prefix=/home/psch/tmp/GNAT_Test/localinst --enable-languages=c,ada --disable-nls --disable-multilib --disable-libada --disable-libssp --program-prefix=m32c-elf- Thread model: single gcc version 4.2.0 20070110 (prerelease) /home/psch/tmp/GNAT_Test/localinst/libexec/gcc/m32c-elf/4.2.0/gnat1 -quiet -dumpbase integer_test.ads -fRTS=rts -gnatv -gnatS integer_test.ads -o integer_test.s GNAT 4.2.0 20070110 (prerelease) Copyright 1992-2006, Free Software Foundation, Inc. -- Representation of package Standard -- This is not accurate Ada, since new base types cannot be -- created, but the listing shows the target dependent -- characteristics of the Standard types for this compiler package Standard is pragma Pure(Standard); type Boolean is (False, True); for Boolean'Size use 1; for Boolean use (False => 0, True => 1); type Integer is range -(2 **15) .. +(2 **15 - 1); for Integer'Size use 16; subtype Natural is Integer range 0 .. Integer'Last; subtype Positive is Integer range 1 .. Integer'Last; type Short_Short_Integer is range -(2 **7) .. +(2 **7 - 1); for Short_Short_Integer'Size use 8; type Short_Integer is range -(2 **15) .. +(2 **15 - 1); for Short_Integer'Size use 16; type Long_Integer is range -(2 **31) .. +(2 **31 - 1); for Long_Integer'Size use 32; type Long_Long_Integer is range -(2 **63) .. +(2 **63 - 1); for Long_Long_Integer'Size use 64; type Short_Float is digits 6 range -16#0._FF#E+32 .. 16#0._FF#E+32; for Short_Float'Size use 32; type Float is digits 6 range -16#0._FF#E+32 .. 16#0._FF#E+32; for Float'Size use 32; type Long_Float is digits 15 range -16#0.___F8#E+256 .. 16#0.___F8#E+256; for Long_Float'Size use 64; type Long_Long_Float is digits 15 range -16#0.___F8#E+256 .. 16#0.___F8#E+256; for Long_Long_Float'Size use 64; type Character is (...) for Character'Size use 8; -- See RM A.1(35) for details of this type type Wide_Character is (...) for Wide_Character'Size use 16; -- See RM A.1(36) for details of this type type Wide_Wide_Character is (...) for Wide_Character'Size use 32; -- See RM A.1(36) for details of this type type String is array (Positive range <>) of Character; pragma Pack (String); type Wide_String is array (Positive range <>) of Wide_Character; pragma Pack (Wide_String); type Wide_Wide_String is array (Positive range <>) of Wide_Wide_Character; pragma Pack (Wide_Wide_String); type Duration is delta 0.1 range -((2 ** 63 - 1) * 0.1) .. +((2 ** 63 - 1) * 0.1); for Duration'Small use 0.1; Constraint_Error : exception; Program_Error: exception; Storage_Error: exception; Tasking_Error: exception; Numeric_Error: exception renames Constraint_Error; end Standard; Compiling: integer_test.ads (source file time stamp: 2007-01-18 16:23:40) +===GNAT BUG DETECTED==+ | 4.2.0 20070110 (prerelease) (m32c-unknown-elf) GCC error:| | in gnat_to_gnu, at ada/trans.c:2675 | | No source file position information available| | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. integer_test.ads 14 lines: No errors compilation abandoned -- The bug also occures with avr-elf. -- integer_test.ads: package Integer_Test is -- type Int_Type is new Short_Short_Integer; -- OK -- type Int_Type is new Short_Integer;-- GNAT BUG BOX type Int_Type is new Integer; -- GNAT BUG BOX (M32C: same as Short_Integer) -- type Int_Type is new Long_Integer; -- OK -- type Int_Type is new Long_Long_Integer;-- OK -- type Int_Type is range -(2 **15) .. +(2 **15 - 1); -- OK (M32C: same as Integer) -- for Int_Type'Size use 16; Var : Int_Type; end Integer_Test; -
[Bug rtl-optimization/323] optimized code gives strange floating point results
--- Comment #88 from egon at heaven dot industries dot cz 2007-01-18 16:29
---
> const volatile double y2 = x + 1.0;
I'd also favor this "selective" approach, because the instability is harmless
in most cases. But it is dangerous sometimes, as mentioned in the binary
search or when sorting, where the faulty cmpfn() could turn the sort function
to infinite loop.
So, could you please advise a body of hypothetical
double discard_extended_precision(double a);
function (possibly some 387 FP insn?) that reliably truncates the argument to
64bit? Would
inline double discard_extended_precision(volatile double a) { return a; }
do the trick?
--
egon at heaven dot industries dot cz changed:
What|Removed |Added
CC||egon at heaven dot
||industries dot cz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
[Bug c++/30500] New: pragma GCC system_header vs templates
I don't think we have an open PR for this "well known" issue so... As you can
see, in the example below, the pragma is totally ineffective with templates,
even when the involved types are non dependent.
By the way, sad to say that, but the way ICC implements the GCC pragma for
compatibility sake is, once more, better than the original: no warning from ICC
(-Wall on ICC as a switch, excellent warnings without the pragma).
paolo:~/Work> more test.h
#pragma GCC system_header
int f()
{
double d = 0.0;
return d;
}
template
int g()
{
double d = 0.0;
return d;
}
template
T h()
{
double d = 0.0;
return d;
}
paolo:~/Work> more test.cc
#include "test.h"
int main()
{
f();
g();
h();
}
paolo:~/Work> g++ -c -Wconversion test.cc
test.h: In function 'int g() [with T = int]':
test.cc:6: instantiated from here
test.h:13: warning: converting to 'int' from 'double'
test.h:13: warning: conversion to 'int' from 'double' may alter its value
test.h: In function 'T h() [with T = int]':
test.cc:7: instantiated from here
test.h:20: warning: converting to 'int' from 'double'
test.h:20: warning: conversion to 'int' from 'double' may alter its value
--
Summary: pragma GCC system_header vs templates
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pcarlini at suse dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30500
[Bug bootstrap/30495] can't compile on AIX
--- Comment #2 from mircea_lutic at yahoo dot com 2007-01-18 15:54 --- out of memory allocating 16 bytes after a total of 4161654796 bytes /etc/security/limits: default: fsize = 2097151 core = 2097151 cpu = -1 data = 262144 rss = 65536 stack = 65536 nofiles = 2000 I had someone add memory to the machine and still : build/genattrtab ../../gcc/config/rs6000/rs6000.md > tmp-attrtab.c out of memory allocating 16 bytes after a total of 4161654796 bytes On a closer look that's 4161654796 =F80D-D00Ch I mean genattrtab is trying to allocate 4 gigs of mem I think this is a bit too much for anything a compiler might want to do. I suspect it's allocating storage in a loop Fortunately I found the gcc binaries for my machine (as a matter of fact I used gcc 4.1.1 to compile itself). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30495
[Bug c/30475] assert(int+100 > int) optimized away
--- Comment #28 from felix-gcc at fefe dot de 2007-01-18 15:23 --- Mhh, so I wondered, how can it be that the code is exactly as fast. So I disassembled the binary. You know what? IT'S THE EXACT SAME CODE. So, my conjecture is, again: your "optimization" does exactly NO good whatsoever, it just breaks code that tries to defend against integer overflows. Please remove it. Now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
[Bug c/30475] assert(int+100 > int) optimized away
--- Comment #27 from felix-gcc at fefe dot de 2007-01-18 15:20 --- Oh, so C++ code using vector gets faster, you say? Let's see... This is vector.C from http://ptrace.fefe.de/vector.C It does some assignments to a vector. It runs the loop 10 times and takes the minimum cycle counter. $ g++ -O2 -o vector vector.C $ ./vector 20724 cycles $ g++ -O2 -o vector vector.C -fwrapv $ ./vector 20724 cycles $ And AGAIN you are proven wrong by the facts. Do you have some more "proof" where this came from? Man, this is ridiculous. Just back out that optimization and I'll shut up. -- felix-gcc at fefe dot de changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WONTFIX | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
[Bug middle-end/20623] ICE: fold check: original tree changed by fold with --enable-checking=fold
--- Comment #13 from ghazi at gcc dot gnu dot org 2007-01-18 14:42 --- 4.1.x branch still has the fold checking errors with labels: http://gcc.gnu.org/ml/gcc-testresults/2007-01/msg00699.html http://gcc.gnu.org/ml/gcc-testresults/2007-01/msg00700.html -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.0.4 |4.0.4 4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20623
[Bug fortran/30283] [4.2 and 4.1 only] Specification expression not properly recognized in declaration
-- 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|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-01-18 14:33:46 date|| Summary|Specification expression not|[4.2 and 4.1 only] |properly recognized in |Specification expression not |declaration |properly recognized in ||declaration http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30283
[Bug c++/30499] gcc segfault on linux kernel 2.6.17.10
--- Comment #1 from dronord at gmail dot com 2007-01-18 14:32 --- version of compiler not exactly -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30499
[Bug c++/30499] New: gcc segfault on linux kernel 2.6.17.10
Kernel was download from www.kernel.org Compile command is "fakeroot make-kpkg --initrd --append-to-version=-custom1 kernel_image kernel_headers" Error is: drivers/video/cirrusfb.c: In function â˜cirrusfb_set_par_fooâ: drivers/video/cirrusfb.c:1573: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. For Debian GNU/Linux specific bug reporting instructions, see . The bug is not reproducible, so it is likely a hardware or OS problem. make[3]: *** [drivers/video/cirrusfb.o] Error 1 make[2]: *** [drivers/video] Error 2 make[1]: *** [drivers] Error 2 make[1]: Leaving directory `/usr/src/linux-2.6.17.10' make: *** [debian/stamp-build-kernel] Error 2 -- Summary: gcc segfault on linux kernel 2.6.17.10 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dronord at gmail dot com GCC host triplet: Linux kubuntu Edgy;gcc version is default http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30499
[Bug fortran/30481] Accepts namelist-group object with assumed character length
--- Comment #2 from pault at gcc dot gnu dot org 2007-01-18 14:27 ---
Confirmed.
With this patch:
Index: gcc/fortran/match.c
===
*** gcc/fortran/match.c (revision 120859)
--- gcc/fortran/match.c (working copy)
*** gfc_match_namelist (void)
*** 2600,2605
--- 2600,2612
gfc_error_check ();
}
+ if (sym->ts.type == BT_CHARACTER && sym->ts.cl->length == NULL)
+ {
+ gfc_error ("Assumed character length '%s' in namelist '%s' at "
+"%C is not allowed", sym->name, group_name->name);
+ gfc_error_check ();
+ }
+
if (sym->as && sym->as->type == AS_ASSUMED_SHAPE
&& gfc_notify_std (GFC_STD_GNU, "Assumed shape array '%s' in "
"namelist '%s' at %C is an extension.",
you now get
pr30481.f90:3.18:
namelist /abc/ c
1
Error: Assumed character length 'c' in namelist 'abc' at (1) is not allowed
If you feel like submitting/committing, please feel free.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2007-01-18 14:27:38
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30481
[Bug tree-optimization/30440] internal compiler error: in find_or_generate_expression, at tree-ssa-pre.c:1472
--- Comment #11 from jasonmbechtel at gmail dot com 2007-01-18 13:48 --- I'm trying to build a more recent 4.1.2 so I can get this program compiled. Unfortunately, I am running into the same problem with the SVN checkout (as of 11pm 1/17/07, EST) and with the last two weekly snapshots (gcc-core-4.1-20070108 and gcc-core-4.1-20070115). I installed gmp and mpfr. I create a subdir of the top-level 'gcc' directory named "localtarget" and cd into it. I run ../configure without any special arguments and it completes without error. I run 'make bootstrap-lean' and they all die at the following: gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -fno-common -Wno-error -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../gcc -I../../gcc/build -I../../gcc/../include -I../../gcc/../libcpp/include -I../../gcc/../libdecnumber -I../libdecnumber-o build/gengtype-lex.o gengtype-lex.c gcc: gengtype-lex.c: No such file or directory gcc: no input files make[3]: *** [build/gengtype-lex.o] Error 1 make[3]: *** Waiting for unfinished jobs rm fsf-funding.pod gcov.pod gfdl.pod cpp.pod gpl.pod gcc.pod make[3]: Leaving directory `/home/jason/gcc/gcc/localtarget/gcc' make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory `/home/jason/gcc/gcc/localtarget' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/home/jason/gcc/gcc/localtarget' make: *** [bootstrap-lean] Error 2 Doing a regular 'make' also results in the error: gcc: gengtype-lex.c: No such file or directory Any help? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30440
[Bug c/8268] no compile time array index checking
--- Comment #44 from mueller at gcc dot gnu dot org 2007-01-18 13:12 --- Fixed for 4.3. -- mueller at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||4.3.0 Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug c/8268] no compile time array index checking
--- Comment #43 from mueller at gcc dot gnu dot org 2007-01-18 13:00 --- Subject: Bug 8268 Author: mueller Date: Thu Jan 18 13:00:33 2007 New Revision: 120898 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120898 Log: 2007-01-18 Dirk Mueller <[EMAIL PROTECTED]> · Richard Guenther <[EMAIL PROTECTED]> · PR diagnostic/8268 · * doc/invoke.texi (Warray-bounds): Document -Warray-bounds. · * common.opt (Warray-bounds): Add new warning option. · * c-opts.c (c_common_handle_option): Define -Warray-bounds · if -Wall is given. * Makefile.in: make tree-vrp.o depend on toplev.h · * tree-vrp.c (vrp_finalize): Call check_array_refs if -Warray-bounds · is enabled. · (check_array_refs, check_array_bounds, check_array_ref): New. · * gcc.dg/Warray-bounds.c: New testcase. * gcc.dg/Warray-bounds-2.c: New testcase. * g++.dg/warn/Warray-bounds.C: New testcase. * g++.dg/warn/Warray-bounds-2.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/warn/Warray-bounds-2.C trunk/gcc/testsuite/g++.dg/warn/Warray-bounds.C trunk/gcc/testsuite/gcc.dg/Warray-bounds-2.c trunk/gcc/testsuite/gcc.dg/Warray-bounds.c Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/c-opts.c trunk/gcc/common.opt trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug libfortran/29649] Force core dump on runtime library errors
--- Comment #15 from burnus at gcc dot gnu dot org 2007-01-18 12:56 --- Fixed in the trunk. Creating a backtrace is now PR 30498. -- burnus at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn|5773| Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29649
[Bug libfortran/29649] Force core dump on runtime library errors
--- Comment #14 from burnus at gcc dot gnu dot org 2007-01-18 12:54 --- Subject: Bug 29649 Author: burnus Date: Thu Jan 18 12:54:11 2007 New Revision: 120897 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120897 Log: 2007-01-18 Francois-Xavier Coudert <[EMAIL PROTECTED]> Tobias Burnus <[EMAIL PROTECTED]> PR libfortran/29649 * gfortran.h (gfc_option_t): Add flag_dump_core. * lang.opt: Add -fdump-core option. * invoke.texi: Document the new options. * trans-decl.c (gfc_build_builtin_function_decls): Add new options to the call to set_std. * options.c (gfc_init_options, gfc_handle_option): Set the new options. 2007-01-18 Francois-Xavier Coudert <[EMAIL PROTECTED]> Tobias Burnus <[EMAIL PROTECTED]> PR libfortran/29649 * runtime/environ.c (variable_table): New GFORTRAN_ERROR_DUMPCORE environment variable. * runtime/compile_options.c (set_std): Add new argument. * runtime/error.c (sys_exit): Move from io/unix.c. Add coredump functionality. * libgfortran.h (options_t): New dump_core and backtrace members. (sys_exit): Move prototype. * io/unix.c (sys_exit): Move to runtime/error.c. * configure.ac: Add check for getrlimit. * configure: Regenerate. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/invoke.texi trunk/gcc/fortran/lang.opt trunk/gcc/fortran/options.c trunk/gcc/fortran/trans-decl.c trunk/libgfortran/ChangeLog trunk/libgfortran/configure trunk/libgfortran/configure.ac trunk/libgfortran/io/unix.c trunk/libgfortran/libgfortran.h trunk/libgfortran/runtime/compile_options.c trunk/libgfortran/runtime/environ.c trunk/libgfortran/runtime/error.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29649
[Bug libfortran/30498] New: Support traceback (backtrace) on errors
+++ This bug was initially created as a clone of Bug #29649 +++ Running an application I got the following error Fortran runtime error: Attempt to allocate negative amount of memory. Possible integer overflow This is not very helpful in debugging, as it gives no clue as to where in the code it occurred. It would be extremely helpful to have a way to force a backtrace produced, either explicitly via stderr (as Intel Fortran does for code compiled with -traceback), or implicitly by producing a core dump. The core dump has been implemented in bug #29649. A draft patch, containing both the now-checked in core dumping and the traceback can be found at http://gcc.gnu.org/ml/fortran/2006-11/msg00634.html That patch calls the addr2line to translate the address to the file/line number. The library used by addr2line cannot be used as it is GPL. (Cf. PR 5773 for gcj.) FX wrote in the initial PR: "It was mentionned on IRC tonight that Daniel Berlin has a library that extracts line and file information from DWARF2 info. It's internal to Google, but he said he'll see if he can get it released. We'll have to get back to him in some time..." -- Summary: Support traceback (backtrace) on errors Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org BugsThisDependsOn: 29649 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30498
[Bug c/30497] compiling binutils 2.17 on aix fails with gcc 4.1.1
--- Comment #1 from jorgen dot moth at uni-c dot dk 2007-01-18 11:54 --- Created an attachment (id=12918) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12918&action=view) readelf.i -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30497
[Bug c/30497] New: compiling binutils 2.17 on aix fails with gcc 4.1.1
-bash-3.00$ gcc -v Using built-in specs. Target: powerpc-ibm-aix5.3.0.0 Configured with: /data1/JM/gcc-4.1.1/configure --prefix=/usr/unic/libexec/gcc/4.1.1 --enable-languages=c,c++ --disable-nls Thread model: aix gcc version 4.1.1 -bash-3.00$ gcc -save-temps -DHAVE_CONFIG_H -I. -I.././binutils -I. -D_GNU_SOURCE -I. -I.././binutils -I../bfd -I.././binutils/../bfd \ > -I.././binutils/../include -I.././binutils/../intl -I../intl > -DLOCALEDIR="\"/usr/unic/libexec/binutils/2.17/share/locale\"" \ > -Dbin_dummy_emulation=bin_aix5_emulation -W -Wall -Wstrict-prototypes > -Wmissing-prototypes -Werror -g -O2 -c readelf.c readelf.c: In function 'get_dynamic_data': readelf.c:6882: error: unrecognizable insn: (insn 190 186 191 9 readelf.c:6877 (parallel [ (set (mem:SI (plus:SI (reg:SI 29 29 [orig:123 ivtmp.1079 ] [123]) (const_int 4294967288 [0xfff8])) [0 S4 A8]) (reg:SI 3 3)) (set (reg:SI 29 29 [orig:123 ivtmp.1079 ] [123]) (plus:SI (reg:SI 29 29 [orig:123 ivtmp.1079 ] [123]) (const_int 4294967288 [0xfff8]))) ]) -1 (nil) (nil)) readelf.c:6882: internal compiler error: in extract_insn, at recog.c:2084 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- Summary: compiling binutils 2.17 on aix fails with gcc 4.1.1 Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: major Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jorgen dot moth at uni-c dot dk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30497
[Bug tree-optimization/22415] [4.0 Regression] ICE in coalesce_abnormal_edges
--- Comment #11 from gdr at gcc dot gnu dot org 2007-01-18 11:45 --- fixed in GCC-4.1.0 not release critical for GCC-4.0.x -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|4.0.4 |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22415
[Bug tree-optimization/22360] [4.0 Regression] upper_bound_in_type and lower_bound_in_type are buggy
--- Comment #7 from gdr at gcc dot gnu dot org 2007-01-18 11:44 --- Fixed in GCC-4.1.1 not release critcal for GCC-4.0.x -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|4.0.4 |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22360
[Bug c/22297] [4.0/4.1/4.2/4.3 Regression] missing uninitialization warning
--- Comment #5 from gdr at gcc dot gnu dot org 2007-01-18 11:43 --- nnot release critical for GCC-4.0.x -- gdr at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.0.4 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22297
[Bug c++/22252] [4.0 Regression] pragma interface/implementation still break synthesized methods
--- Comment #12 from gdr at gcc dot gnu dot org 2007-01-18 11:42 --- not release critical for GCC-4.0.x -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|4.0.4 |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22252
[Bug target/22077] [4.0 Regression] vec_all_eq does not produce good result
--- Comment #16 from gdr at gcc dot gnu dot org 2007-01-18 11:42 --- not release critical for GCC-4.0.x -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|4.0.4 |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22077
[Bug c/21659] [4.0/4.1/4.2/4.3 Regression] [unit-at-a-time] "weak declaration must precede definition" error missing at >= O1
--- Comment #5 from gdr at gcc dot gnu dot org 2007-01-18 11:41 --- not release critical for GCC-4.0.x -- gdr at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.0.4 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21659
[Bug tree-optimization/21548] [4.0 regression] Wrong warning about uninitialized variable
--- Comment #15 from gdr at gcc dot gnu dot org 2007-01-18 11:40 --- Won't fix for GCC-4.0.x -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21548
[Bug c++/30496] Compilation errors when compiled with optimization flags
--- Comment #2 from csandu4096 at gmail dot com 2007-01-18 10:51 --- Created an attachment (id=12917) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12917&action=view) Error.s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30496
[Bug c++/30496] Compilation errors when compiled with optimization flags
--- Comment #1 from csandu4096 at gmail dot com 2007-01-18 10:51 --- Created an attachment (id=12916) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12916&action=view) Error.ii -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30496
[Bug c++/30496] New: Compilation errors when compiled with optimization flags
When I compile the following code with optimization flags (O1, O2, O3, Os) I
get compilation errors. If the code is compiled without optimizations (-g, -O0)
then everything is ok.
Error.cpp :
#include
#define _(x) gettext(x)
typedef struct
{
int code;
const char* p_str;
} ErrorStr;
static ErrorStr g_errorStrTab[] =
{
{ 1,_("Success") },
{ 2,_("Invalid error code") },
{ 3,_("Invalid argument") },
{ 4,_("Convertion error") }
};
The platform is : Debian 2.2 Potato, glibc 2.1.3
The output of "gcc -v -save-temps -Os -c Error.cpp" is :
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ./configure --enable-languages=c,c++
Thread model: posix
gcc version 4.1.1
/usr/local/libexec/gcc/i686-pc-linux-gnu/4.1.1/cc1plus -E -quiet -v
-D_GNU_SOURCE Error.cpp -mtune=pentiumpro -Os -fpch-preprocess -o Erro
r.ii
ignoring nonexistent directory "NONE/include"
ignoring nonexistent directory
"/usr/local/lib/gcc/i686-pc-linux-gnu/4.1.1/../../../../i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/lib/gcc/i686-pc-linux-gnu/4.1.1/../../../../include/c++/4.1.1
/usr/local/lib/gcc/i686-pc-linux-gnu/4.1.1/../../../../include/c++/4.1.1/i686-pc-linux-gnu
/usr/local/lib/gcc/i686-pc-linux-gnu/4.1.1/../../../../include/c++/4.1.1/backward
/usr/local/include
/usr/local/lib/gcc/i686-pc-linux-gnu/4.1.1/include
/usr/include
End of search list.
/usr/local/libexec/gcc/i686-pc-linux-gnu/4.1.1/cc1plus -fpreprocessed Error.ii
-quiet -dumpbase Error.cpp -mtune=pentiumpro -auxbase Error
-Os -version -o Error.s
GNU C++ version 4.1.1 (i686-pc-linux-gnu)
compiled by GNU C version 4.1.1.
GGC heuristics: --param ggc-min-expand=38 --param ggc-min-heapsize=15901
Compiler executable checksum: 6b1156c38beeebd4aa05553feb32ed24
Error.cpp:13: error: statement-expressions are allowed only inside functions
Error.cpp:14: error: statement-expressions are allowed only inside functions
Error.cpp:14: error: redefinition of 'char* __result'
Error.cpp:13: error: 'char* __result' previously declared here
Error.cpp:14: error: redefinition of 'char* __translation__'
Error.cpp:13: error: 'char* __translation__' previously declared here
Error.cpp:14: error: redefinition of 'int __catalog_counter__'
Error.cpp:13: error: 'int __catalog_counter__' previously declared here
Error.cpp:15: error: statement-expressions are allowed only inside functions
Error.cpp:15: error: redefinition of 'char* __result'
Error.cpp:13: error: 'char* __result' previously declared here
Error.cpp:15: error: redefinition of 'char* __translation__'
Error.cpp:13: error: 'char* __translation__' previously declared here
Error.cpp:15: error: redefinition of 'int __catalog_counter__'
Error.cpp:13: error: 'int __catalog_counter__' previously declared here
Error.cpp:16: error: statement-expressions are allowed only inside functions
Error.cpp:16: error: redefinition of 'char* __result'
Error.cpp:13: error: 'char* __result' previously declared here
Error.cpp:16: error: redefinition of 'char* __translation__'
Error.cpp:13: error: 'char* __translation__' previously declared here
Error.cpp:16: error: redefinition of 'int __catalog_counter__'
Error.cpp:13: error: 'int __catalog_counter__' previously declared here
--
Summary: Compilation errors when compiled with optimization flags
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: csandu4096 at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30496
[Bug bootstrap/30495] can't compile on AIX
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-18 10:18 --- >From http://gcc.gnu.org/install/specific.html: out of memory bootstrap failures may indicate a problem with process resource limits (ulimit). Hard limits are configured in the /etc/security/limits system configuration file. Did you read that page and does changing the limits help? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30495
[Bug middle-end/30494] ICE with VLA and openmp
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-18 10:13 ---
Confirmed, reduced testcase (I thought I had asked about this interaction
before):
int Birkhoff_with_Vol_para(int n)
{
int I;
#pragma omp for
for(I = 0; I < 6; I++)
{
int v[n];
}
}
This ICEs for both the C and C++ front-ends. Considering VLA is C99, we should
support this. Also I bet you can produce a fortran code which also ICEs.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|c++ |middle-end
Ever Confirmed|0 |1
GCC build triplet|4.2.0 20070102 (prerelease) |
GCC host triplet|x86_64-unknown-linux-gnu|
GCC target triplet|x86_64-unknown-linux-gnu|
Keywords||openmp
Last reconfirmed|-00-00 00:00:00 |2007-01-18 10:13:33
date||
Summary|internal compiler error: in |ICE with VLA and openmp
|gimplify_expr, at |
|gimplify.c:5979 [-fopenmp] |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30494
[Bug bootstrap/30495] New: can't compile on AIX
with both 4.1.0 and 4.1.1. at cc -g -DIN_GCC -DHAVE_CONFIG_H -DGENERATOR_FILE -o build/genattrtab \ build/genattrtab.o build/genautomata.o \ build/rtl.o build/read-rtl.o build/ggc-none.o build/min-insn-modes.o build/gensupport.o build/insn-conditions.o build/print-rtl.o build/errors.o \ build/varray.o ../build-powerpc-ibm-aix5.3.0.0/libiberty/libiberty.a -lm build/genattrtab ../../gcc/config/rs6000/rs6000.md > tmp-attrtab.c I get : out of memory allocating 4072 bytes after a total of 416165366 -- Summary: can't compile on AIX Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mircea_lutic at yahoo dot com GCC build triplet: powerpc-ibm-aix5.3.0.0 GCC host triplet: powerpc-ibm-aix5.3.0.0 GCC target triplet: powerpc-ibm-aix5.3.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30495
[Bug middle-end/28071] [4.1 regression] A file that can not be compiled in reasonable time/space
--- Comment #59 from hubicka at ucw dot cz 2007-01-18 09:51 --- Subject: Re: [4.1 regression] A file that can not be compiled in reasonable time/space Hi, just as heads up, the early inlining change made inliner to now fully inline to the function at -O2 (orignally we stopped because of inline unit growth doing just few of inlines). This enables more optimizations and reduces memory usage of all other passes except for scheduler, that increases. So we have roughly peak of 60MB GGC memory without scheduling, 360MB with scheduling, so this patch would be even more greatly appreciated ;) http://www.suse.de/~aj/SPEC/amd64/memory/pr28071-O2.rep Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28071
