http://blog.gmane.org/gmane.comp.gcc.devel hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.comp.gcc.devel/101555 Hi, We have built a cross compiled toolchain for SH target using the following sources, gcc-4.3.1 [released], newlib-1.16.0 [released] binutils-2.18.50 [snapshot dated 30th July 2008], We have experienced following error, when building a C++ application using a toolchain built with the above mentioned sources, //////////////////////////////////////////////////////////////////////// ///// "sh-elf-ld.exe: sh-elf\lib\gcc\sh-elf\4.3.1\ml\m2\libgcc-Os-4-200.a (unwind-dw2-Os-4-200.o): compiled for a big endian system and target is little endian sh-elf-ld.exe: \sh-elf\lib\gcc\sh-elf\4.3.1\ml\m2\libgcc-Os-4-200.a (unwind-dw2-Os-4-200.o): uses instructions which are incompatible with instructions used in previous modules sh-elf-ld.exe: failed to merge target specific data of file sh-elf\lib\gcc\sh-elf\4.3.1\ml\m2\libgcc-Os-4-200.a(unwind-dw2-Os-4-200. o)" //////////////////////////////////////////////////////////////////////// ///// The libgcc-Os-4-200.a archive built for SH target consists of the following object files, udivsi3_i4i-Os-4-200.o sdivsi3_i4i-Os-4-200.o unwind-dw2-Os-4-200.o It has been observed that the object file "unwind-dw2-Os-4-200.o" gets built for big endian instead of little endian target.Whereas the other two object files, "udivsi3_i4i-Os-4-200.o" and "sdivsi3_i4i-Os-4-200.o" from the same archive are successfully built for little endian target of SH. The libraries built for little endian SH-2/SH-3 target series resides at the following path, sh-elf/lib/gcc/sh-elf/4.3.1/ml/m2 We have also observed that the target specific options such as ml, m2, ml m2 etc are not passed to the compiler while building the "unwind-dw2-Os-4-200" object. It appears that, somewhere in the GCC makefiles, the required options have been missed while building the "unwind-dw2-Os-4-200.o" component. Has anyone faced a similar problem? Any possible workaround? Regards, Cecilia Rodrigues KPIT Cummins Infosystems Ltd. Pune, India Cecilia Rodrigues 2008-10-07T11:08:38 http://comments.gmane.org/gmane.comp.gcc.devel/101553 Hello, Is there a general way to recognize a nop insn in RTL (using attributes?), or should I add a target hook for that? For example, I would like to recognize the following spu insn as a nop:?), (insn 555 210 203 11 (unspec_volatile [ (const_int 0 [0x0]) ] 14) 393 {lnop} (nil)) Thanks, Revital Revital1 Eres 2008-10-07T09:44:37 http://comments.gmane.org/gmane.comp.gcc.devel/101552 Dear gcc developers, I am new to this list. I tried to use the auto-vectorization (4.2.1 (SUSE Linux)) but unfortunately with limited success. My code is bassically a matrix library in C++. The vectorizer does not like the member variables. Consider this code compiled with gcc -ftree-vectorize -msse2 -ftree-vectorizer-verbose=5 -funsafe-math-optimizations.... that gives basically "not vectorized: unhandled data-ref" <C++ code snippet> class P{ public: P() : m(5),n(3) { double *d = data; for (int i=0; i<m*n; i++) d[i] = i/10.2; } void test(const double& sum); private: int m; int n; double data[15]; }; void P::test(const double& sum) { double *d = this->data; for(int i=0; i<m*n; i++){ d[i]+=sum; } } </C++ code snippet> whereas the more or less equivalent C version works just fine: <C code snippet> int m=5; int n=3; double data[15]; void test(const double& sum) { int mn = m*n; for(int i=0; i<mn; i++){ data[i]+=sum; } } </C code snippet> Is there a fundamental problem in using the vectorizer in C++? Regards! Georg Georg Martius 2008-10-07T08:48:29 http://comments.gmane.org/gmane.comp.gcc.devel/101546 I have been looking at why g++.dg/tree-prof/indir-call-prof.C fails on IA64 (HP-UX and Linux). It looks like the optimization (turning an indirect call into a direct call) does not happen because the initial run with -fprofile-generate is not generating any count data about indirect calls. Comparing x86 (where things work) and IA64 (where they do not), I see the test case, when compiled with -fprofile-generate, has calls __gcov_indirect_call_profiler in both cases. But on IA64, cur_func is never equal to callee_func and so __gcov_one_value_profiler_body is never called. On x86 we do have cur_func equal to callee_func and so __gcov_one_value_profiler_body is called to write out profile information. This is about as far as I have gotten. I am not sure why there is this difference or how to fix it. I *think* it may be related to the fact that IA64 GCC defines TARGET_VTABLE_USES_DESCRIPTORS but my only reason for thinking that is that IA64 is the only platform that defines this macro and I think that the profiler must be getting callee addresses out of the vtable (though I am not sure about that and I don't know where it would be doing it from). So this is a request to anyone who might know the profiling code to help me with some advise about what I should look at next or about how to go about fixing this bug. Steve Ellcey sje< at >cup.hp.com Steve Ellcey 2008-10-06T23:18:32 http://comments.gmane.org/gmane.comp.gcc.devel/101541 Currently in Practice: Medical Doctors in the USA Featuring the most accurate contact information in many different areas of medicine you can sort by many different fields Reduced to only: $392 ()()() Also you will get this data below with your purchase: ()()() ==> Dentists ==> Veterinarians ==> Physical Therapists ==> Visiting Nurses & RN's area representative:: BrettCarlton< at >idockey.com during this week only ```````````````````````````````````````````````` Send email to xne456< at >idockey.com for deleted status Mcelroy F Omar 2008-10-06T20:24:24 http://comments.gmane.org/gmane.comp.gcc.devel/101535 Guten Tag, Inwieweit beherrscht der G-C-Übersetzer Unicode? Umlaute sind z.B. noch nicht gestattet? Übersetzungsvorstellung: "Übersetzerkarteien mit z.B. den reservierten Wörtern der Programmbausprache C." Kartei besetzte_Wörter_deutsch: 1 Falls 2 Dann 3 Andernfalls 4 rückgeben Kartei besetzte_Wörter_englisch: 1 if 2 then 3 else 4 return Weiterhin wäre es praktisch eingebaute "Zeichensetzung", wie z.B. Ausgabe f1(Eingabe) ändern zu können, in z.B. (Eingabe)f2(Ausgabe). Das würde schon die Grammatik beeinflußen. Wünschenswert wäre da z.B. eine Kartei: XML-Kartei Zeichensetzung_C: <Funktion>Ausgabe Funktionsname(Eingabe)</Funktion> änderbar z.B. in <Funktion>(Eingabe) Funktionsname (Ausgabe)</Funktion> . In wie weit sind solche Ansätze (Fragestellungen) zu realisieren? Als "Grundgerüst" könnte man doch eventuell "eindeutige" Zahlen anstatt "Ziffernfolgen" einsetzen. Vorstellung eines Beispielprogramms: ---- Lingua=Deutsch #Hinzufügen "Sprachen.Bauteil" (a,b)Einsprung(c Ganzzahl){ (1)Zahlganz(a); (2)Zahlganz(b); ("Orbitum, te salute! %d, %d",a,b)Zifferausgabe(); /////Ausgabe soll sein: " Orbitum, te salute! 1, 2 " (a)Ausgeben; } ---- Mit wieviel Aufwand könnte man den "G-C-Übersetzer" dementsprechend anpassen? Vorschlag für Lokalisierung einer Funktion. int Nachricht_senden(a,b,c) ///Übersetzer_Funktion(Nachricht_senden, Übersetzung: "Scribus emittere".) In etwa war das die Zielbeschreibung: 1. Reservierte Wörter lokalisieren. 2. Lokalisierung von Funktionsnamen, Parametern, und Variablen (z.B. im Funktionskontext.) 3. Flexible Einstellung der Bedeutungsziffern. (Also statt f1(), auch ()f1 möglich.) Wer hat Erfahrung mit diesem Thema? Wer kann dabei helfen, die Zielsetzung ins Englische zu übersetzen? M.f.G. R. Müller _______________________________________________________________________ Jetzt neu! Schützen Sie Ihren PC mit McAfee und WEB.DE. 30 Tage kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc=022220 Rüdiger Müller 2008-10-06T16:55:18 http://comments.gmane.org/gmane.comp.gcc.devel/101533 Hi I was wondering if there was a version of gcc that would produce output to be ran on an LC3 simulator. Much help would be appreciated. kanegr 2008-10-06T00:27:50 http://comments.gmane.org/gmane.comp.gcc.devel/101526 Since we're in stage3, I'm raising the issue of the MPFR version we require for GCC, just as in last year's stage3 for gcc-4.3: http://gcc.gnu.org/ml/gcc/2007-12/msg00298.html I'd like to increase the "minimum" MPFR version to 2.3.0, (which has been released since Aug 2007). The "recommended" version of MPFR can be bumped to the latest which is 2.3.2. Doing this will allow me to remove several MPFR cpp conditionals in the middle-end as well as in the fortran frontend. It also helps for future work I plan to do with folding c99 complex number math functions, as that work will require mpfr-2.3.0. Patch bootstrapped on x86_64-unknown-linux-gnu using mpfr-2.3.2, no regresions. I also configured with mpfr-2.2.0 to ensure that GCC still fails the relevant checks with older versions of mpfr. If approved, I'll again wait a week before installing so people can upgrade their regtesters if necessary. Okay for mainline? Thanks, --Kaveh 2008-10-04 Kaveh R. Ghazi <ghazi< at >caip.rutgers.edu> * configure.ac (MPFR check): Bump minimum version to 2.3.0 and recommended version to 2.3.2. * builtins.c: Remove MPFR_VERSION_NUM(2,3,0) conditionals. * doc/install.texi: Bump recommended MPFR to 2.3.2. * configure: Regenerate. fortran: * simplify.c: Remove MPFR_VERSION_NUM(2,3,0) conditionals. diff -rup orig/egcc-SVN20081001/configure.ac egcc-SVN20081001/configure.ac --- orig/egcc-SVN20081001/configure.ac2008-09-06 02:00:10.000000000 +0200 +++ egcc-SVN20081001/configure.ac2008-10-04 20:19:15.000000000 +0200 < at >< at > -1267,11 +1267,11 < at >< at > if test -d ${srcdir}/gcc && test "x$have if test x"$have_gmp" = xyes; then saved_LIBS="$LIBS" LIBS="$LIBS $gmplibs" - dnl MPFR 2.2.1 is acceptable, but MPFR 2.3.0 is better. + dnl MPFR 2.3.0 is acceptable, but MPFR 2.3.2 is better. AC_MSG_CHECKING([for correct version of mpfr.h]) AC_TRY_LINK([#include <gmp.h> #include <mpfr.h>],[ - #if MPFR_VERSION < MPFR_VERSION_NUM(2,2,1) + #if MPFR_VERSION < MPFR_VERSION_NUM(2,3,0) choke me #endif mpfr_t n; < at >< at > -1284,7 +1284,7 < at >< at > if test -d ${srcdir}/gcc && test "x$have mpfr_subnormalize (x, t, GMP_RNDN); ], [AC_TRY_LINK([#include <gmp.h> #include <mpfr.h>],[ - #if MPFR_VERSION < MPFR_VERSION_NUM(2,3,0) + #if MPFR_VERSION < MPFR_VERSION_NUM(2,3,2) choke me #endif mpfr_t n; mpfr_init(n); < at >< at > -1295,7 +1295,7 < at >< at > if test -d ${srcdir}/gcc && test "x$have CFLAGS="$saved_CFLAGS" if test x$have_gmp != xyes; then - AC_MSG_ERROR([Building GCC requires GMP 4.1+ and MPFR 2.3.0+. + AC_MSG_ERROR([Building GCC requires GMP 4.1+ and MPFR 2.3.2+. Try the --with-gmp and/or --with-mpfr options to specify their locations. Copies of these libraries' source code can be found at their respective hosting sites as well as at ftp://gcc.gnu.org/pub/gcc/infrastructure/. diff -rup orig/egcc-SVN20081001/gcc/builtins.c egcc-SVN20081001/gcc/builtins.c --- orig/egcc-SVN20081001/gcc/builtins.c2008-08-30 02:00:13.000000000 +0200 +++ egcc-SVN20081001/gcc/builtins.c2008-10-04 20:22:06.000000000 +0200 < at >< at > -231,13 +231,11 < at >< at > static tree do_mpfr_arg2 (tree, tree, tr static tree do_mpfr_arg3 (tree, tree, tree, tree, int (*)(mpfr_ptr, mpfr_srcptr, mpfr_srcptr, mpfr_srcptr, mp_rnd_t)); static tree do_mpfr_sincos (tree, tree, tree); -#if MPFR_VERSION >= MPFR_VERSION_NUM(2,3,0) static tree do_mpfr_bessel_n (tree, tree, tree, int (*)(mpfr_ptr, long, mpfr_srcptr, mp_rnd_t), const REAL_VALUE_TYPE *, bool); static tree do_mpfr_remquo (tree, tree, tree); static tree do_mpfr_lgamma_r (tree, tree, tree); -#endif /* Return true if NODE should be considered for inline expansion regardless of the optimization level. This means whenever a function is invoked with < at >< at > -10112,7 +10110,6 < at >< at > fold_builtin_1 (tree fndecl, tree arg0, &dconstm1, NULL, false); break; -#if MPFR_VERSION >= MPFR_VERSION_NUM(2,3,0) CASE_FLT_FN (BUILT_IN_J0): if (validate_arg (arg0, REAL_TYPE)) return do_mpfr_arg1 (arg0, type, mpfr_j0, < at >< at > -10136,7 +10133,6 < at >< at > fold_builtin_1 (tree fndecl, tree arg0, return do_mpfr_arg1 (arg0, type, mpfr_y1, &dconst0, NULL, false); break; -#endif CASE_FLT_FN (BUILT_IN_NAN): case BUILT_IN_NAND32: < at >< at > -10252,7 +10248,6 < at >< at > fold_builtin_2 (tree fndecl, tree arg0, switch (fcode) { -#if MPFR_VERSION >= MPFR_VERSION_NUM(2,3,0) CASE_FLT_FN (BUILT_IN_JN): if (validate_arg (arg0, INTEGER_TYPE) && validate_arg (arg1, REAL_TYPE)) < at >< at > -10279,7 +10274,6 < at >< at > fold_builtin_2 (tree fndecl, tree arg0, && validate_arg(arg1, POINTER_TYPE)) return do_mpfr_lgamma_r (arg0, arg1, type); break; -#endif CASE_FLT_FN (BUILT_IN_ATAN2): if (validate_arg (arg0, REAL_TYPE) < at >< at > -10436,14 +10430,12 < at >< at > fold_builtin_3 (tree fndecl, tree arg0, return do_mpfr_arg3 (arg0, arg1, arg2, type, mpfr_fma); break; -#if MPFR_VERSION >= MPFR_VERSION_NUM(2,3,0) CASE_FLT_FN (BUILT_IN_REMQUO): if (validate_arg (arg0, REAL_TYPE) && validate_arg(arg1, REAL_TYPE) && validate_arg(arg2, POINTER_TYPE)) return do_mpfr_remquo (arg0, arg1, arg2); break; -#endif case BUILT_IN_MEMSET: return fold_builtin_memset (arg0, arg1, arg2, type, ignore); < at >< at > -13054,7 +13046,6 < at >< at > do_mpfr_sincos (tree arg, tree arg_sinp, return result; } -#if MPFR_VERSION >= MPFR_VERSION_NUM(2,3,0) /* If argument ARG1 is an INTEGER_CST and ARG2 is a REAL_CST, call the two-argument mpfr order N Bessel function FUNC on them and return the resulting value as a tree with type TYPE. The mpfr precision < at >< at > -13239,7 +13230,6 < at >< at > do_mpfr_lgamma_r (tree arg, tree arg_sg, return result; } -#endif /* FIXME tuples. The functions below provide an alternate interface for folding diff -rup orig/egcc-SVN20081001/gcc/doc/install.texi egcc-SVN20081001/gcc/doc/install.texi --- orig/egcc-SVN20081001/gcc/doc/install.texi2008-09-14 02:00:04.000000000 +0200 +++ egcc-SVN20081001/gcc/doc/install.texi2008-10-04 20:20:03.000000000 +0200 < at >< at > -309,7 +309,7 < at >< at > library search path, you will have to co < at >option{--with-gmp} configure option. See also < at >option{--with-gmp-lib} and < at >option{--with-gmp-include}. -< at >item MPFR Library version 2.3.0 (or later) +< at >item MPFR Library version 2.3.2 (or later) Necessary to build GCC< at >. It can be downloaded from < at >uref{http://www.mpfr.org/}. The version of MPFR that is bundled with diff -rup orig/egcc-SVN20081001/gcc/fortran/simplify.c egcc-SVN20081001/gcc/fortran/simplify.c --- orig/egcc-SVN20081001/gcc/fortran/simplify.c2008-09-12 02:00:04.000000000 +0200 +++ egcc-SVN20081001/gcc/fortran/simplify.c2008-10-04 20:22:58.000000000 +0200 < at >< at > -668,7 +668,6 < at >< at > gfc_simplify_atan2 (gfc_expr *y, gfc_exp gfc_expr * gfc_simplify_bessel_j0 (gfc_expr *x ATTRIBUTE_UNUSED) { -#if MPFR_VERSION >= MPFR_VERSION_NUM(2,3,0) gfc_expr *result; if (x->expr_type != EXPR_CONSTANT) < at >< at > -678,16 +677,12 < at >< at > gfc_simplify_bessel_j0 (gfc_expr *x ATTR mpfr_j0 (result->value.real, x->value.real, GFC_RND_MODE); return range_check (result, "BESSEL_J0"); -#else - return NULL; -#endif } gfc_expr * gfc_simplify_bessel_j1 (gfc_expr *x ATTRIBUTE_UNUSED) { -#if MPFR_VERSION >= MPFR_VERSION_NUM(2,3,0) gfc_expr *result; if (x->expr_type != EXPR_CONSTANT) < at >< at > -697,9 +692,6 < at >< at > gfc_simplify_bessel_j1 (gfc_expr *x ATTR mpfr_j1 (result->value.real, x->value.real, GFC_RND_MODE); return range_check (result, "BESSEL_J1"); -#else - return NULL; -#endif } < at >< at > -707,7 +699,6 < at >< at > gfc_expr * gfc_simplify_bessel_jn (gfc_expr *order ATTRIBUTE_UNUSED, gfc_expr *x ATTRIBUTE_UNUSED) { -#if MPFR_VERSION >= MPFR_VERSION_NUM(2,3,0) gfc_expr *result; long n; < at >< at > -719,16 +710,12 < at >< at > gfc_simplify_bessel_jn (gfc_expr *order mpfr_jn (result->value.real, n, x->value.real, GFC_RND_MODE); return range_check (result, "BESSEL_JN"); -#else - return NULL; -#endif } gfc_expr * gfc_simplify_bessel_y0 (gfc_expr *x ATTRIBUTE_UNUSED) { -#if MPFR_VERSION >= MPFR_VERSION_NUM(2,3,0) gfc_expr *result; if (x->expr_type != EXPR_CONSTANT) < at >< at > -738,16 +725,12 < at >< at > gfc_simplify_bessel_y0 (gfc_expr *x ATTR mpfr_y0 (result->value.real, x->value.real, GFC_RND_MODE); return range_check (result, "BESSEL_Y0"); -#else - return NULL; -#endif } gfc_expr * gfc_simplify_bessel_y1 (gfc_expr *x ATTRIBUTE_UNUSED) { -#if MPFR_VERSION >= MPFR_VERSION_NUM(2,3,0) gfc_expr *result; if (x->expr_type != EXPR_CONSTANT) < at >< at > -757,9 +740,6 < at >< at > gfc_simplify_bessel_y1 (gfc_expr *x ATTR mpfr_y1 (result->value.real, x->value.real, GFC_RND_MODE); return range_check (result, "BESSEL_Y1"); -#else - return NULL; -#endif } < at >< at > -767,7 +747,6 < at >< at > gfc_expr * gfc_simplify_bessel_yn (gfc_expr *order ATTRIBUTE_UNUSED, gfc_expr *x ATTRIBUTE_UNUSED) { -#if MPFR_VERSION >= MPFR_VERSION_NUM(2,3,0) gfc_expr *result; long n; < at >< at > -779,9 +758,6 < at >< at > gfc_simplify_bessel_yn (gfc_expr *order mpfr_yn (result->value.real, n, x->value.real, GFC_RND_MODE); return range_check (result, "BESSEL_YN"); -#else - return NULL; -#endif } < at >< at > -2459,7 +2435,6 < at >< at > gfc_simplify_len_trim (gfc_expr *e, gfc_ gfc_expr * gfc_simplify_lgamma (gfc_expr *x ATTRIBUTE_UNUSED) { -#if MPFR_VERSION >= MPFR_VERSION_NUM(2,3,0) gfc_expr *result; int sg; < at >< at > -2471,9 +2446,6 < at >< at > gfc_simplify_lgamma (gfc_expr *x ATTRIBU mpfr_lgamma (result->value.real, &sg, x->value.real, GFC_RND_MODE); return range_check (result, "LGAMMA"); -#else - return NULL; -#endif } Kaveh R. GHAZI 2008-10-05T01:33:48 http://comments.gmane.org/gmane.comp.gcc.devel/101524 The following problem is very common when dealing with iterators, function objects and/or algorithms in C++. This is a simple test case: #include <iostream> #include <iterator> #include <string> int main() { using namespace std; typedef istreambuf_iterator<char> isbi; string str(isbi(cin), isbi()); // Line 8 cout << str << endl; // Line 9 } The code above, even though it looks correct to experienced C++ programmer and compiles fine, does definitely not do what the programmer intended it to. The program was meant to read all characters from std::cin, until EOF, into str. Instead, it reads nothing from there and just prints value 1 to std::cout, as also suggested this warning message (enabled by -Wall): test.cpp:9: warning: the address of ‘std::string str(main()::isbi, main()::isbi (*)())’ will always evaluate as ‘true’ This message may tell an experienced C++ programmer what the actual problem is, but even then it points at the wrong line. Depending on how str is used, there might be even more obscure errors, especially if str is passed to a template function. The problem here is that the C++ standard requires line 8 to be interpreted as a declaration of a function named str, returning string and taking two arguments of type isbi (the first one is named cin and the second one is anonymous). The extra parenthesis around variable names are ignored. However, since it is not conventional to use parenthesis around variable names in function declarations, this problem could be analyzed by GCC, issuing a proper warning. My suggestion: Whenever a function declaration with parenthesis around parameter names is seen, issue a warning: <file>:<lineno>: warning: '<symbolname>' is interpreted as a function declaration, but it looks like a variable definition (put parenthesis around '<first argument>' to make it so) E.g. in the above case: test.cc:8: warning: 'str' is interpreted as a function declaration, but it looks like a variable definition (put parenthesis around 'isbi(cin)' to make it so) Note: the case of variable initialization without arguments (also interpreted as a function declaration) cannot be diagnosed in this manner. Therefore no warning should be issued on this: string str(); People generally learn to write just string str; rather quickly. Lasse Kärkkäinen 2008-10-04T15:45:23 http://comments.gmane.org/gmane.comp.gcc.devel/101515 Snapshot gcc-4.4-20081003 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20081003/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 140862 You'll find: gcc-4.4-20081003.tar.bz2 Complete GCC (includes all of below) gcc-core-4.4-20081003.tar.bz2 C front end and core compiler gcc-ada-4.4-20081003.tar.bz2 Ada front end and runtime gcc-fortran-4.4-20081003.tar.bz2 Fortran front end and runtime gcc-g++-4.4-20081003.tar.bz2 C++ front end and runtime gcc-java-4.4-20081003.tar.bz2 Java front end and runtime gcc-objc-4.4-20081003.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.4-20081003.tar.bz2 The GCC testsuite Diffs from 4.4-20080926 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way. gccadmin< at >gcc.gnu.org 2008-10-03T22:46:46 http://comments.gmane.org/gmane.comp.gcc.devel/101513 Hi! I am inetested to setup a FTP mirror for the GCC distribution in Germany. How much disk space/bandwith does it need to provide a mirror? is it also possible to mirror through rsync? Thanks and best regards. Thomas Lepping Thomas Lepping 2008-10-03T20:07:11 http://comments.gmane.org/gmane.comp.gcc.devel/101509 After upgrading to gcc-4.2.1 from a 3.4 version, I see that gcc now complains about uninitialized variables even when their address is passed to another function. Now that we get a warning about that variable being possibly initialized, I'm forced to add an instruction or two to initialize it (after I determine an appropriate value) or declare the function like this: foo( __attribute__((must_assign)) long *ptr); { *ptr = _base_address_; } bar() { int *p; foo( &p); *p = ... } There's two things I really like about this: 1) In the caller, my warning goes away without having to determine an appropriate value in each caller of foo 2) In the callee, gcc can give a warning if there are any paths which leave that parm uninitialized. If there's some other mechanism to achieve this functionality, I'd be interested in hearing about it. And if this is a new idea, I offer it to the gcc community. John jbbachky< at >aim.com 2008-10-03T18:00:59 http://comments.gmane.org/gmane.comp.gcc.devel/101505 Hi, Is there a structure/array/macro to access all the variables (something like a variable table) in the back-end after the instantiation of the virtual registers (vregs pass from function.c) ? Some info about variable + its virtual register and so on. Thanks, Thomas Thomas A.M. Bernard 2008-10-03T10:17:07 http://comments.gmane.org/gmane.comp.gcc.devel/101499 Snapshot gcc-4.3-20081002 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20081002/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch revision 140843 You'll find: gcc-4.3-20081002.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20081002.tar.bz2 C front end and core compiler gcc-ada-4.3-20081002.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20081002.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20081002.tar.bz2 C++ front end and runtime gcc-java-4.3-20081002.tar.bz2 Java front end and runtime gcc-objc-4.3-20081002.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20081002.tar.bz2 The GCC testsuite Diffs from 4.3-20080925 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way. gccadmin< at >gcc.gnu.org 2008-10-02T22:45:33 http://comments.gmane.org/gmane.comp.gcc.devel/101497 Hi All, Shouldn't this macro: #define REAL_VALUE_TO_TARGET_DOUBLE(IN, OUT) \ real_to_target (OUT, &(IN), mode_for_size (64, MODE_FLOAT, 0)) be using DOUBLE_TYPE_SIZE instead of the hard coded '64'? Am I missing something here? In the target I am currently working, DOUBLE_TYPE_SIZE is defined as 32-bit, so the hard-coded '64' is causing trouble. I am planning on doing this change on my local source tree, but wanted to discuss with the community to see if there is some implementations details somewhere that I need to consider as well. Best regards, -Omar Omar Torres 2008-10-02T22:39:02 http://comments.gmane.org/gmane.comp.gcc.devel/101496 Jan, I was wondering if you could help me figure out how to fix the tests g++.old-deja/g++.other/static14.C and g++.old-deja/g++.other/static20.C which started failing on IA64 HP-UX at version 138150 when you checked in the C++ inlining change. Here is a minimal test: struct basic_string { ~basic_string() {} }; struct Side { void name() { static basic_string sname; } }; int main () { Side x; } Before your checkin this would compile and link correctly, now it gives me an undefined symbol for Side::name()::sname. This bug only occurs when no optimization is used. The difference is that before your change, the C++ cleanup function _tcf_0 was not output (and was not called). After the change this cleanup function is output (though there are still no calls to it) and it contains a reference to Side::name()::sname but the variable sname is not output. Interestingly, before and after the change, even though the variable Side::name()::sname was not output, the guard variable for it is output in a comdat. If the test is optimized at all then the problem goes away because the optimizer recognizes that _tcf_0 is not needed and doesn't output it and thus the reference to Side::name()::sname goes away. I don't see this problem on IA64 Linux where the _tcf_0 function is not output even when no optimization is done. I am not sure why there is this difference between IA64 Linux and HP-UX. Any help or advice you could give me would be appreciated. Steve Ellcey sje< at >cup.hp.com sje< at >cup.hp.com 2008-10-02T22:13:19 http://comments.gmane.org/gmane.comp.gcc.devel/101472 Snapshot gcc-4.2-20081001 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20081001/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.2 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_2-branch revision 140822 You'll find: gcc-4.2-20081001.tar.bz2 Complete GCC (includes all of below) gcc-core-4.2-20081001.tar.bz2 C front end and core compiler gcc-ada-4.2-20081001.tar.bz2 Ada front end and runtime gcc-fortran-4.2-20081001.tar.bz2 Fortran front end and runtime gcc-g++-4.2-20081001.tar.bz2 C++ front end and runtime gcc-java-4.2-20081001.tar.bz2 Java front end and runtime gcc-objc-4.2-20081001.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.2-20081001.tar.bz2 The GCC testsuite Diffs from 4.2-20080924 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.2 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way. gccadmin< at >gcc.gnu.org 2008-10-01T22:42:08 http://comments.gmane.org/gmane.comp.gcc.devel/101466 Hi, I appreciate if someone can help me with my linking error: In my "c++" options , i already have ' -L/usr/local/lib -lgnet-2.0'. I get a number of '7: undefined reference to `gnet_conn_readline'' errors. Can you please tell me why the linking fails? I have the 'gnet.h' include in my .cpp and I apparently compile fine. c++ -fno-rtti -fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-long-long -pedantic -fno-strict-aliasing -fshort-wchar -pthread -pipe -DDEBUG -D_DEBUG -DDEBUG_scheung -DTRACING -g -fno-inline -Os -freorder-blocks -fno-reorder-functions -finline-limit=50 -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/pixman-1 -I/usr/include/gtk-unix-print-2.0 -o TestGNet TestGNet.o -lpthread -Wl,-rpath-link,/media/sdb3/src/tracemonkey/src/firefox-objdir/dist/bin -Wl,-rpath-link,/lib -L../../../../dist/bin -L../../../../dist/lib -lX11 /media/sdb3/src/tracemonkey/src/firefox-objdir/dist/lib/libxpcomglue.a -lasound -ldl -lm -L/usr/local/lib -lgnet-2.0 -lgtk-x11-2.0 -latk-1.0 -lgdk-x11-2.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 TestGNet.o: In function `main': /media/sdb3/src/tests/TestGNet.cpp:304: undefined reference to `gnet_conn_new' /media/sdb3/src/tests/TestGNet.cpp:310: undefined reference to `gnet_conn_connect' /media/sdb3/src/tests/TestGNet.cpp:312: undefined reference to `gnet_conn_set_watch_error' /media/sdb3/src/tests/TestGNet.cpp:314: undefined reference to `gnet_conn_timeout' TestGNet.o: In function `ob_sig_int': /media/sdb3/src/tests/TestGNet.cpp:1380: undefined reference to `gnet_conn_write' /media/sdb3/src/tests/TestGNet.cpp:1382: undefined reference to `gnet_conn_readline' TestGNet.o: In function `ob_conn_func': /media/sdb3/src/tests/TestGNet.cpp:1307: undefined reference to `gnet_conn_readline' /media/sdb3/src/tests/TestGNet.cpp:1344: undefined reference to `gnet_conn_delete' /media/sdb3/src/tests/TestGNet.cpp:1212: undefined reference to `gnet_conn_timeout' /media/sdb3/src/tests/TestGNet.cpp:1227: undefined reference to `gnet_conn_write' /media/sdb3/src/tests/TestGNet.cpp:1229: undefined reference to `gnet_conn_readline' /media/sdb3/src/tests/TestGNet.cpp:1315: undefined reference to `gnet_conn_delete' /media/sdb3/src/tests/TestGNet.cpp:1330: undefined reference to `gnet_conn_delete' /media/sdb3/src/tests/TestGNet.cpp:1251: undefined reference to `gnet_conn_delete' /usr/bin/ld: TestGNet: hidden symbol `gnet_conn_connect' isn't defined /usr/bin/ld: final link failed: Nonrepresentable section on output collect2: ld returned 1 exit status gmake[5]: *** [TestGNet] Error 1 Thank you for any help. ying lcs 2008-10-01T21:25:10 http://comments.gmane.org/gmane.comp.gcc.devel/101462 /*solution provided by kermi3 from this web posting http://cboard.cprogramming.com/archive/index.php/t-27714.html*/ #include <termios.h> #include <unistd.h> int mygetch(void) { struct termios oldt, newt; int ch; tcgetattr( STDIN_FILENO, &oldt ); newt = oldt; newt.c_lflag &= ~( ICANON | ECHO ); tcsetattr( STDIN_FILENO, TCSANOW, &newt ); ch = getchar(); tcsetattr( STDIN_FILENO, TCSANOW, &oldt ); return ch; } /*this point down was coded by Brandon Camadine*/ void mygetchs(int length,char array[],int display) { int x; array[length-1]='\0'; while(array[x]!='\0') { array[x]=mygetch(); if(display !=0) { putchar(array[x]); } x++; } } /*solution provided by kermi3 from this web posting http://cboard.cprogramming.com/archive/index.php/t-27714.html*/ #include <termios.h> #include <unistd.h> int mygetch(void) { struct termios oldt, newt; int ch; tcgetattr( STDIN_FILENO, &oldt ); newt = oldt; newt.c_lflag &= ~( ICANON | ECHO ); tcsetattr( STDIN_FILENO, TCSANOW, &newt ); ch = getchar(); tcsetattr( STDIN_FILENO, TCSANOW, &oldt ); return ch; } /*this point down was coded by Brandon Camadine*/ void mygetchs(int length,char array[],int display) { int x; array[length-1]='\0'; while(array[x]!='\0') { array[x]=mygetch(); if(display !=0) { putchar(array[x]); } x++; } } Brandon 2008-10-01T19:02:21 http://comments.gmane.org/gmane.comp.gcc.devel/101444 Hi , Based on the conversation in the thread at http://gcc.gnu.org/ml/gcc/2008-03/msg00513.html , we've tried to get a pass trying to undo final value replacement going. The initial implementation was done by Pranav Bhandarkar when he was employed at Azingo as part of work sponsored by Icera Semiconductor. I've been trying to get this working with my private port over here. We intend to contribute this back once our copyright assignments are sorted and if this will be acceptable to all. I've been getting a few compile time ICEs with this approach and haven't been able to resolve them well enough yet. Whilst doing so, I wanted to check on the approach as outlined below and ask if there's anything that we might have missed or any problem that one can see with us going along these lines. Thanks for your time and patience. cheers Ramana 1) Understanding what scalar evolution does. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Consider the following pseudo code. function memcpy (src_pointer, dst_pointer) src_1 = src_pointer; dst_1 = dst_pointer; L1: *dst_1 = *src_1 (Word copy) dst++; src++; <---- Inc by 4 bytes i.e 1 word. conditional jump to L1 <fallthrough edge> /* This is the exit block of loop 1. The following PHI nodes are added by loopinit pass to convert the SSA form into "closed loop SSA" (see rewrite_into_loop_closed_ssa" in tree-ssa-loop-manip.c */ src_2 = PHI <src_1> dst_2 = PHI <dst_1> <fall through edge> L2: *dst_2 = *src_2 (Byte Copy) dst++; src++; <conditional jump to L2> Now scalar evolution convertes this into Function memcpy (src_pointer, dst_pointer) src_1 = src_pointer; dst_1 = dst_pointer; L1: *dst_1 = *src_1 (Word copy) dst++; src++; <---- Inc by 4 bytes i.e 1 word. conditional jump to L1 <fallthrough edge> /* This is the exit block of loop 1. The following PHI nodes are added by loopinit pass to convert the SSA form into "closed loop SSA" (see rewrite_into_loop_closed_ssa" in tree-ssa-loop-manip.c */ D.1234_11 = 4 * n (where 'n' is the number of iterations of L1) src_2 = src_pointer + D.1234_11 D.1235_22 = 4 * n dst_2 = dst_pointer + D.1235_22 <fallthrough edge> L2: *dst_2 = *src_2 (Byte Copy) dst++; src++; <conditional jump to L2> Therefore a PHI Node is replaced by the final value of src_1 and dst_1, thus introducing extra computations. 2) How to undo what scalar evolution does. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ To undo what scalar evolution does, we need to record the changes that scalar evolution makes and then after the loop optimizations are run we need to replace the PHI nodes that were removed earlier in place of the computations introduced by scalar evolution. A high level description of the process is listed here. (see tree-scalar-evolution.c and grep for DXP_SPECIFIC) Explanation of this sub-pass. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Part 1: Record Final Value replacement related changes. ~~~~~~ Final value replacement replaces PHI nodes at the exits of loops with computations based on the number of iterations of the loop. For e.g. <bb 1> L1: x_1 = src + 4 ... ... conditional jump to L1. <bb 2> (Loop Exit) x_2 = PHI <x_1> <---- Phi node added by rewrite_into_loop_closed_ssa. (see the loopinit pass). Final Value replacement replaces the PHI node in <bb 2> by ssa_temp_var = 4 * no_of_iterations_of_loop x_2 = src + ssa_temp_var; Therefore a PHI node is replaced by computations. Recording final value replacement related changes is controlled by the variable record_scalar_evolution_changes. When set to a non-zero value the function record_changed_stmts records the changes made. The changes are recorded in a hashtable changed_stmts_table. The hashtable contains the stmt added, the PHI node for which this stmt was added and hashcodes for both the stmt and the phi_node. We also note how many computations have been added for each of the removed PHI nodes. This is done in a link list pointed to by phi_nodes_info_head. Part 2: Undo Final value replacement related changes ~~~~~~ This is the part where the new computations are removed and the PHI nodes that they are replaced are inserted back in. This replacement is contingent to a few conditions. a) All the computations that were added are still present in the basic block. i.e all the computations are still present in the form in which they were added and havent been touched by any of the loop optimizations passes that run between the scalar evolution pass (i.e the pass when Part 1 is executed) and the 'loopdone' pass. We go through the exit basic block and look up each stmt in changed_stmt_table. If found we lookup the corresponding PHI node in the phi_node_info link list and decrement its count by 1 (count here denotes the number of computations added. When count it 0 it means all the computatins added in the scalar evolution pass have been found in the same form in the loop done pass such a PHI node can be inserted back in if 'b' is also true). b) If any PHI node has count zero it can be inserted back and its corresponding computations removed, iff the argument of the PHI node still exists as an SSA variable. This means that we can insert a_1 = PHI <D.10_1> if D.10_1 still exists and hasnt been removed by any of the passes between the scalar evolution pass and the loopdone pass. 3) Implementation details including the issues in 2. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 3.1} Recording the Changes made by scalar evolution. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ a) We record changes in tree-scalar-evolution.c in the scalar evolution pass (see function scev_const_prop). We visit the exit block of each loop and If we find a PHI node with only one argument then we set 'record_scalar_evolution_changes' to 1. We also set 'current_phi_node' to this particular PHI node. Then via a call to 'record_changed_stmts' from 'force_gimple_operand_bsi' in gimplify.c we record the new statement added for this PHI node. This information is recorded in a hash table 'changed_stmts_table'. We hash on the new statement that is added and store the statement along with the PHI node for which this statement was added. b) Along with this, we also maintain a 'phi_nodes_info' link list (pointed to by 'phi_nodes_info_head'). Each node in this list contains a unique PHI node (representing a PHI node that was removed by scalar evolution) and a 'count' that denotes the number of statements added for that PHI node. 'record_changed_stmts' calls 'record_stmt_for_current_phi_node' so that the 'count' for the 'current_phi_node' is incremented in its corresponding 'phi_nodes_info' node. Therefore in the above memcpy example. We would have four entries in 'changed_stmts_table', each containing the following tuple. <new_stmt_added, hashvalue, PHI_node, PHI_id,hashvalue_for_phi_node> i.e the changed_stmts_table would look like 1. D.1234_11 = 4 * n , Hashval, src_2 = PHI <src_1>, 1,Hashval_phi_node 2. src_2 = src_pointer + D.1234_11,Hashval, src_2 = PHI <src_1>, 1,Hashval_phi_node 3. D.1235_22 = 4 * n , Hashval, dst_2 = PHI <dst_1>, 2,Hashval_phi_node 2. dst_2 = dst_pointer + D.1235_22,Hashval, dst_2 = PHI <dst_1>, 2,Hashval_phi_node The phi_nodes_info link list would look like __________________________________ ________________________________ | phi_node = dst_2 = PHI <dst_1> | |phi_node = src_2 = PHI <src_1>| | count = 2 |--->|count = 2 | _________________________________ ________________________________ ^ | | phi_nodes_info_head. c) The need for hashvalue_for_phi_node: Since we dont release the PHI node, sometimes, the PHI node that we have stored itself gets changed (Trees are finally pointers and so are their operands). Therefore while inserting we rehash the PHI node and check the hashvalue with the stored hashvalue of the PHI node. If it is the same only then we reinsert the PHI node. The hashvalue for the phi node is generated by 'generate_phi_node_hashcode' d) Notes about removing PHI nodes: When -ftree-fvr-undo is enabled, then we alter slightly the way a PHI node is removed. Each Basic block contains a chain of PHI nodes. When removing a PHI node say 'A', 'A' is removed from this chain and also 'released' i.e the SSA NAMES in 'A' are released for reuse. When -ftree-fvr-undo is enabled, we remove 'A' from the chain of PHI nodes for the particular block but we _donot_ 'release' it. This also helps preserve the immediate uses of PHI node. 3.2) Using the recorded information and undoing final value replacement ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ a) This happens in the function 'scev_finalize'. We again visit the exit block of each loop. In the exit block of each loop we go through each statement and try to find its corresponding entry in 'changed_stmts_table'. If found we extract the PHI node that it had replaced and find the node for this phi node in phi_nodes_info. We then decrement the 'count' member of this node (denoting that one statement that was added for this PHI node still exists). If this count decrements to Zero we should be able to remove these statemens and reinsert the phi nodes if b is true. This is done by 'traverse_exit_block_match_instructions' and 'dec_phi_node_count'. b) We again go through all the statements of the block. For each statement we extract the PHI node it had replaced from the 'changed_stmts_table'. We then look up this PHI node in the phi_nodes_info link list and if the count is zero and if the argument of the PHI node still exists as a gimple variable we remove the current statement. If the argument of the PHI node doesnt exist anymore as a gimple variable (This is possible because a number of passes run between the time that we record scalar evolution informations and now when we are undoing final value replacement) then we just increment the count of the PHI node to indicate that this PHI node shouldnt be reinserted and the current statement is not removed. c) Once we have reached the end of the basic block we simply travers the phi_nodes_info link list and insert the PHI nodes that have 'count' zero. b and c are done by 'check_mark_phi_nodes_insert' and 'remove_stmts_insert_phi_nodes'. 4) Summary of key datastructures. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ a) changed_stmts_table - Hash table to record scalar evolution changes. b) phi_nodes_info - Link list, whose each node contains a PHI node and a count indicating the number of statements that replaced this phi node as a result of scalar evolution analysis. -- Ramana Radhakrishnan Ramana Radhakrishnan 2008-10-01T13:22:22 http://comments.gmane.org/gmane.comp.gcc.devel/101438 Hi! Processor ARM920T, chip Atmel at91rm9200. Simple C code: char c[30]; unsigned short *pN = &c[1]; *pN = 0x1234; causes hardware exeption - memory aborts (used to implement memory protection or virtual memory). We have a lot of source code, with pieces of code like this, which must be ported from x86 to ARM9. Are there any compiler options to handle this exception? I compile it by using arm-elf-gcc 4.3.2 under Linux. binutils-2.18. Thanks. Best regrads, Vladimir Vladimir Sterjantov 2008-10-01T07:34:29 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.gcc.devel