[Bug fortran/40869] New: [F03] PPC assignment checking
This PR is meant to track one leftover item related to procedure pointer components: No pointer assignment checking is performed yet when a PPC is involved, cf. the TODO comment in expr.c (gfc_check_pointer_assign). Short test case: implicit none type :: t1 procedure(integer), pointer, nopass :: ppc end type type :: t2 procedure(real), pointer, nopass :: ppc end type type(t1) :: o1 type(t2) :: o2 procedure(logical),pointer :: pp1 procedure(complex),pointer :: pp2 pp1 = pp2 o1%ppc = pp1 pp2 = o2%ppc o1%ppc = o2%ppc end All four pointer assignments in this example are invalid, but only the first one is caught. -- Summary: [F03] PPC assignment checking Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: janus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40869
[Bug fortran/40870] New: [F03] include formal args in backend_decl of PPCs
Another PPC leftover item, cf. trans-types.c (gfc_get_ppc_type): When translating the Fortran frontend structures to a backend tree, the argument list of procedure pointer components is currently not being used. This becomes visible in a test case like this: implicit none procedure(foo), pointer :: pp type :: t procedure(foo), pointer, nopass :: ppc end type type(t)::o pp = foo o%ppc = foo pp = o%ppc contains integer function foo(a,b) integer, intent(in) :: a,b foo = a + b end function end Compiling with -fdump-tree-original shows the following code for the three pointer assignments: pp = foo; o.ppc = (integer(kind=4) (*T3c6) (void)) foo; pp = (integer(kind=4) (*T3c8) (integer(kind=4) , integer(kind=4) )) o.ppc; The first one is ok, but the last two involve type casting, although they have exactly the same interface (simply because the arguments of the PPC are missing). -- Summary: [F03] include formal args in backend_decl of PPCs Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: janus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40870
[Bug c++/40871] New: g++ does not find lstdc++ on AIX
On AIX 5.3, g++ version 4.4.0 and 4.4.1 cannot find the libstdc++ in default location. This did not occur with 4.3.x. The problem has been already discussed on the mailing list in this thread: http://gcc.gnu.org/ml/gcc-help/2009-06/msg00092.html and a patch was issued. It was supposedly committed to the main branch after 4.4.0, but for some reason was not present (or did not solve the issue) in 4.4.1. I have compiled gcc with --disable-shared and use the AIX linker ld, not the GNU linker. This is the verbose compilation output of a simple Hello World program written in C++: Using built-in specs. Target: powerpc-ibm-aix5.3.0.0 Configured with: /hpc/work/fernandz/gnusrc/gcc-4.4.1/configure --enable-threads --enable-languages=c,c++ --prefix=/hpc/work/fernandz/gnu --enable-threads --disable-shared --enable-version-specific-runtime-libs --disable-nls --with-gmp=/hpc/work/fernandz/gnu --with-mpfr=/hpc/work/fernandz/gnu --with-ppl=/hpc/work/fernandz/gnu --with-cloog=/hpc/work/fernandz/gnu Thread model: aix gcc version 4.4.1 (GCC) COLLECT_GCC_OPTIONS='-v' '-o' 'hello' /hpc/work/fernandz/gnu/libexec/gcc/powerpc-ibm-aix5.3.0.0/4.4.1/cc1plus -quiet -v -D_ALL_SOURCE hellow.cpp -quiet -dumpbase hellow.cpp -auxbase hellow -version -o /hpc/home/fernandz/User-Tmp/ccrprayy.s ignoring nonexistent directory /hpc/work/fernandz/gnu/lib/gcc/powerpc-ibm-aix5.3.0.0/4.4.1/../../../../powerpc-ibm-aix5.3.0.0/include #include ... search starts here: #include ... search starts here: /hpc/work/fernandz/gnu/lib/gcc/powerpc-ibm-aix5.3.0.0/4.4.1/include/c++ /hpc/work/fernandz/gnu/lib/gcc/powerpc-ibm-aix5.3.0.0/4.4.1/include/c++/powerpc-ibm-aix5.3.0.0 /hpc/work/fernandz/gnu/lib/gcc/powerpc-ibm-aix5.3.0.0/4.4.1/include/c++/backward /usr/local/include /hpc/work/fernandz/gnu/include /hpc/work/fernandz/gnu/lib/gcc/powerpc-ibm-aix5.3.0.0/4.4.1/include /hpc/work/fernandz/gnu/lib/gcc/powerpc-ibm-aix5.3.0.0/4.4.1/include-fixed /usr/include End of search list. GNU C++ (GCC) version 4.4.1 (powerpc-ibm-aix5.3.0.0) compiled by GNU C version 4.4.1, GMP version 4.3.1, MPFR version 2.4.1-p5. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: f579180f2de70dc0754151f494907fb7 COLLECT_GCC_OPTIONS='-v' '-o' 'hello' as -u -mppc -o /hpc/home/fernandz/User-Tmp/ccwslsmj.o /hpc/home/fernandz/User-Tmp/ccrprayy.s COMPILER_PATH=/hpc/work/fernandz/gnu/libexec/gcc/powerpc-ibm-aix5.3.0.0/4.4.1/:/hpc/work/fernandz/gnu/libexec/gcc/powerpc-ibm-aix5.3.0.0/4.4.1/:/hpc/work/fernandz/gnu/libexec/gcc/powerpc-ibm-aix5.3.0.0/:/hpc/work/fernandz/gnu/lib/gcc/powerpc-ibm-aix5.3.0.0/4.4.1/:/hpc/work/fernandz/gnu/lib/gcc/powerpc-ibm-aix5.3.0.0/ LIBRARY_PATH=/hpc/work/fernandz/gnu/lib/gcc/powerpc-ibm-aix5.3.0.0/4.4.1/:/hpc/work/fernandz/gnu/lib/gcc/powerpc-ibm-aix5.3.0.0/4.4.1/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-o' 'hello' /hpc/work/fernandz/gnu/libexec/gcc/powerpc-ibm-aix5.3.0.0/4.4.1/collect2 -bpT:0x1000 -bpD:0x2000 -btextro -bnodelcsect -o hello /lib/crt0.o -L/hpc/work/fernandz/gnu/lib/gcc/powerpc-ibm-aix5.3.0.0/4.4.1 -L/hpc/work/fernandz/gnu/lib/gcc/powerpc-ibm-aix5.3.0.0/4.4.1/../../.. /hpc/home/fernandz/User-Tmp/ccwslsmj.o -lstdc++ -lsupc++ -lm /hpc/work/fernandz/gnu/lib/gcc/powerpc-ibm-aix5.3.0.0/4.4.1/libgcc.a -lc /hpc/work/fernandz/gnu/lib/gcc/powerpc-ibm-aix5.3.0.0/4.4.1/libgcc.a collect2: library libstdc++ -lsupc++ not found -- Summary: g++ does not find lstdc++ on AIX Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: efernandez at physiomics-plc dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40871
[Bug fortran/31067] MINLOC should sometimes be inlined (gas_dyn is sooooo sloooow)
--- Comment #34 from irar at il dot ibm dot com 2009-07-27 08:36 --- (In reply to comment #33) Using the example from comment 23 with ... gfortran shows: test.f90:12: note: not vectorized: unsupported use in stmt. and needs 2.272s. (By comparison. 4.4 needs 3.688s.) This is for the inner loop vectorization. For the outer loop we get: tmp.f90:11: note: not vectorized: control flow in loop. because of the if's. Maybe loop unswitching can help us. Vectorizable outer-loops look like this: (pre-header) | header ---+ | | inner-loop | | | tail --+ | (exit-bb) Does ifort vectorize the exact same implemantion of minloc? Ira -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31067
[Bug libfortran/40187] c_f_pointer with stride in SHAPE
--- Comment #10 from tkoenig at gcc dot gnu dot org 2009-07-27 09:11 --- Closing (fixed). -- 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=40187
[Bug c++/40866] [4.5 Regression] ICE in create_tmp_var, at gimplify.c:504
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-27 09:13 --- Reducing. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40866
[Bug fortran/31067] MINLOC should sometimes be inlined (gas_dyn is sooooo sloooow)
--- Comment #35 from burnus at gcc dot gnu dot org 2009-07-27 09:18 --- (In reply to comment #34) Does ifort vectorize the exact same implemantion of minloc? I tried to convert the minloc implementation into Fortran loops - and the result is at http://users.physik.fu-berlin.de/~tburnus/tmp/vect-PR31067/maxloc2.f90 $ ifort -O3 -xHost -diag-enable all maxloc2.f90 maxloc2.f90(25): (col. 5) remark: LOOP WAS VECTORIZED. [timing: 0m1.384s] $ gfortran -O3 -ffast-math -march=native -ftree-vectorize -ftree-vectorizer-verbose=5 maxloc2.f90 maxloc2.f90:1: note: vectorized 0 loops in function. [timing: 0m2.212s] In case it helps: I put the ifort assembler output at: http://users.physik.fu-berlin.de/~tburnus/tmp/vect-PR31067/maxloc2.s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31067
[Bug libfortran/40863] [4.5 Regression] Build failure in libgfortran
--- Comment #10 from burnus at gcc dot gnu dot org 2009-07-27 09:24 --- Subject: Bug 40863 Author: burnus Date: Mon Jul 27 09:24:41 2009 New Revision: 150107 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150107 Log: 2009-07-27 Tobias Burnus bur...@net-b.de PR fortran/40863 * c99_functions.c: Define complex I, if not defined. Create prototypes for C99 functions to silence warnings. * gfortran.map: Add missing functions to GFORTRAN_C99_1.0 and new GFORTRAN_C99_1.1. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/gfortran.map trunk/libgfortran/intrinsics/c99_functions.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40863
[Bug libfortran/40863] [4.5 Regression] Build failure in libgfortran
--- Comment #11 from burnus at gcc dot gnu dot org 2009-07-27 09:27 --- FIXED on the trunk (4.5). Thanks for the bug report and sorry for the breakage. Feel free to open a PR if build warnings show up in libgfortran. In principle, there should be none. (I have forgotten why we cannot use -Werror.) -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40863
[Bug fortran/40851] problem with deallocation of pointers
--- Comment #3 from burnus at gcc dot gnu dot org 2009-07-27 09:32 --- Subject: Bug 40851 Author: burnus Date: Mon Jul 27 09:32:20 2009 New Revision: 150108 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150108 Log: 2009-07-26 Tobias Burnus bur...@net-b.de PR fortran/40851 * resolve.c (resolve_symbol): Do not initialize pointer * derived-types. * trans-decl.c (init_intent_out_dt): Ditto. (generate_local_decl): No need to set attr.referenced for DT pointers. 2009-07-26 Tobias Burnus bur...@net-b.de PR fortran/40851 * gfortran.dg/derived_init_3.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/derived_init_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40851
[Bug fortran/40851] [4.3/4.4] problem with deallocation of pointers
--- Comment #4 from burnus at gcc dot gnu dot org 2009-07-27 09:33 --- Thanks for the report. FIXED on the trunk (4.5); I will soon backport it to 4.4/4.3. (Workaround: Do not use INTENT for pointers [which is a Fortran 2003 feature].) -- burnus at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|4.5.0 v149701 | GCC host triplet|Linux x86. x86-64 and MAC OS| |X | GCC target triplet|gfortran| Summary|problem with deallocation of|[4.3/4.4] problem with |pointers|deallocation of pointers http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40851
[Bug libstdc++/40497] invalid std::next / std::prev declaration
--- Comment #21 from paolo dot carlini at oracle dot com 2009-07-27 09:34 --- Thanks Jason. I'm tentatively recategorizing as libstdc++, then. In general, I'm not at all sure what we should do about it, however, now that Concepts are gone. I don't think we can hope to avoid, here and elsewhere, all the typical problems caused by unconstrained templates. Certainly, having the two separate overloads: templatetypename InputIterator, typename Distance InputIterator next(InputIterator, Distance); templatetypename InputIterator InputIterator next(InputIterator); would lead to cleaner error messages in case of ambiguities, but I'm not sure we can in general achieve much more than this. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Component|c++ |libstdc++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40497
[Bug fortran/40853] I/O: Namelist read error
--- Comment #2 from burnus at gcc dot gnu dot org 2009-07-27 09:40 --- Confirmed. Fails with gfortran 4.1 to 4.5 and is thus no regression, but it works with ifort, g95, openf95, and NAG f95. -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Known to fail||4.1.3 4.2.1 4.3.3 4.4.1 ||4.5.0 Last reconfirmed|-00-00 00:00:00 |2009-07-27 09:40:04 date|| Summary|Namelist read error |I/O: Namelist read error http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40853
[Bug fortran/40847] [4.3/4.4/4.5 Regression] segfault bogus warning
--- Comment #2 from burnus at gcc dot gnu dot org 2009-07-27 10:08 --- The following looks wrong: gfc_resolve_transfer (gfc_expr *f, gfc_expr *source ATTRIBUTE_UNUSED, gfc_expr *mold, gfc_expr *size) [...] if (mold-ts.type == BT_CHARACTER !mold-ts.cl-length !(mold-expr_type == EXPR_VARIABLE mold-symtree-n.sym-attr.dummy)) mold-ts.cl-length = gfc_int_expr (mold-value.character.length); For the testcase: mold-ts.type == BT_CHARACTER mold-ts.cl-length == NULL mold-expr_type == EXPR_VARIABLE mold-symtree == NULL (!) and mold-value.character.length == 19532032 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40847
[Bug c++/40872] New: String not extracted for translation
On line 9382 of gcc/cp/decl.c there is this code error (funcdef_flag ? %qs defined in a non-class scope : %qs declared in a non-class scope, name); Normally the first argument of error will be extracted for translation. Apparently the extractor is not smart enough to extract both branches of this conditional expression, so only the first (defined) part is available for translation. The second version (declared) is not included. -- Summary: String not extracted for translation Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: goeran at uddeborg dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40872
[Bug fortran/31067] MINLOC should sometimes be inlined (gas_dyn is sooooo sloooow)
--- Comment #36 from jakub at gcc dot gnu dot org 2009-07-27 11:02 ---
Here is the loop in C and vectorized by hand as well:
#include emmintrin.h
float arr[1024];
unsigned int
foo (unsigned int end)
{
unsigned int pos = 1;
unsigned int i;
float limit = __FLT_MAX__;
for (i = 0; i end; i++)
if (arr[i] limit)
{
limit = arr[i];
pos = i + 1;
}
return pos;
}
unsigned int
bar (unsigned int end)
{
__m128 pos = (__m128) _mm_set1_epi32 (1);
__m128 limit = _mm_set1_ps (__FLT_MAX__);
__m128i curi = _mm_set_epi32 (4, 3, 2, 1);
__m128i inc = _mm_set1_epi32 (4);
unsigned int i = 0;
if (end 4)
{
for (; i end - 4; i += 4)
{
__m128 val = _mm_loadu_ps (arr + i);
__m128 mask = _mm_cmplt_ps (val, limit);
limit = _mm_min_ps (limit, val);
pos = _mm_andnot_ps (mask, pos);
pos = _mm_or_ps (pos, _mm_and_ps (mask, (__m128) curi));
curi = _mm_add_epi32 (curi, inc);
}
/* Reduction. */
__m128 tmp1 = _mm_movehl_ps (limit, limit);
__m128 tmp2 = _mm_movehl_ps (pos, pos);
__m128 mask = _mm_cmplt_ps (tmp1, limit);
limit = _mm_min_ps (tmp1, limit);
tmp2 = _mm_and_ps (mask, tmp2);
pos = _mm_or_ps (tmp2, _mm_andnot_ps (mask, pos));
tmp1 = _mm_shuffle_ps (limit, limit, _MM_SHUFFLE (1, 1, 1, 1));
tmp2 = _mm_shuffle_ps (pos, pos, _MM_SHUFFLE (1, 1, 1, 1));
mask = _mm_cmplt_ps (tmp1, limit);
limit = _mm_min_ps (tmp1, limit);
tmp2 = _mm_and_ps (mask, tmp2);
pos = _mm_or_ps (tmp2, _mm_andnot_ps (mask, pos));
}
float limit_ = _mm_cvtss_f32 (limit);
unsigned int pos_ = (unsigned int) _mm_cvtsi128_si32 ((__m128i) pos);
for (; i end; i++)
if (arr[i] limit_)
{
limit_ = arr[i];
pos_ = i + 1;
}
return pos_;
}
int
main (void)
{
unsigned int k;
arr[0] = -1;
arr[2] = -3;
arr[8] = -5;
arr[9] = -6;
if (foo (32) != bar (32))
__builtin_abort ();
for (k = 10; k 32; k++)
{
arr[k] = -k;
if (foo (32) != bar (32))
__builtin_abort ();
}
return 0;
}
Don't know how hard would be to vectorize this in the vectorizer, but clearly
icc manages to handle that.
The loop is:
bb 4:
# pos_22 = PHI pos_1(7), 1(3)
# i_23 = PHI i_15(7), 0(3)
# limit_24 = PHI limit_4(7), 3.4028234663852885981170418348451692544e+38(3)
limit_11 = arr[i_23];
D.2700_12 = limit_11 limit_24;
pos_1 = [cond_expr] D.2700_12 ? i_23 : pos_22;
limit_4 = [cond_expr] D.2700_12 ? limit_11 : limit_24;
i_15 = i_23 + 1;
D.2703_9 = (long unsigned int) i_15;
if (D.2703_9 end_10(D))
goto bb 7;
else
goto bb 8;
bb 7:
goto bb 4;
before vectorization.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31067
[Bug fortran/31067] MINLOC should sometimes be inlined (gas_dyn is sooooo sloooow)
--- Comment #37 from jakub at gcc dot gnu dot org 2009-07-27 11:10 --- Oh, and on 64-bit arches and float or 32-bit arches and double there is another complication - the comparison has different mode size from the cond_expr for pos. For 32-bit pos and 64-bit double it could perhaps just do the computation in 64-bit integers (vector of 2 (resp. 4 for avx)), for the other case it would need to shuffle the max and compute the pos in 2 vectors, or e.g. the Fortran FE could hand in the common case, emit a likely look for the case where array size is smaller than 4GB, using 32-bit pos zero extended to 64-bits at the end. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31067
[Bug c++/40872] String not extracted for translation
--- Comment #1 from paolo dot carlini at oracle dot com 2009-07-27 11:24 --- I think this is a pervasive issue and we have at least another couple of PRs about it in Bugzilla. Please check / commonize, thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40872
[Bug testsuite/40829] gcc.dg/vect/no-scevccp-noreassoc-outer-2.c can segv
--- Comment #1 from simon_baldwin at yahoo dot com 2009-07-27 12:08 --- Committed revision 150109. -- simon_baldwin at yahoo dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40829
[Bug bootstrap/39849] segfault for '__divtf3' during bootstrap and non-bootstrap install
--- Comment #18 from dennis dot wassel at googlemail dot com 2009-07-27 12:40 --- It still happens in 4.4.1: /localdata/install/gcc/objdir-gcc-4.4.1/./gcc/xgcc -B/localdata/install/gcc/objdir-gcc-4.4.1/./gcc/ -B/localdata/i686-pc-linux-gnu/bin/ -B/localdata/i686-pc-linux-gnu/lib/ -isystem /localdata/i686-pc-linux-gnu/include -isystem /localdata/i686-pc-linux-gnu/sys-include -g -O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../.././gcc -I../../../gcc-4.4.1/libgcc -I../../../gcc-4.4.1/libgcc/. -I../../../gcc-4.4.1/libgcc/../gcc -I../../../gcc-4.4.1/libgcc/../include -I../../../gcc-4.4.1/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_TLS -Wno-missing-prototypes -Wno-type-limits -o divtf3.o -MT divtf3.o -MD -MP -MF divtf3.dep -fexceptions -c ../../../gcc-4.4.1/libgcc/../gcc/config/soft-fp/divtf3.c -fvisibility=hidden -DHIDE_EXPORTS ' In function '__divtf3': Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[3]: *** [divtf3.o] Error 1 make[3]: Leaving directory `/localdata/install/gcc/objdir-gcc-4.4.1/i686-pc-linux-gnu/libgcc' make[2]: *** [all-stage1-target-libgcc] Error 2 make[2]: Leaving directory `/localdata/install/gcc/objdir-gcc-4.4.1' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/localdata/install/gcc/objdir-gcc-4.4.1' make: *** [profiledbootstrap] Error 2 Host compiler: $ gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.3.3/configure --prefix=/localdata --program-suffix=-4.3.3 --enable-languages=c,c++,fortran --with-gmp=/localdata --with-mpfr=/localdata --enable-version-specific-runtime-libs Thread model: posix gcc version 4.3.3 (GCC) Configured with: $../gcc-4.4.1/configure --prefix=/localdata --with-gmp=/localdata --with-mpfr=/localdata --with-ppl=/localdata --with-cloog=/localdata --enable-version-specific-runtime-libs --program-suffix=-4.4.1 --enable-checking=release --with-system-zlib --enable-languages=c,c++,fortran --with-arch=athlon64 --enable-__cxa_atexit $make profiledbootstrap gdb output (seems to be the same spot as before): $gdb /localdata/install/gcc/objdir-gcc-4.4.1/./gcc/cc1 GNU gdb 6.8 Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as i686-pc-linux-gnu... -Wno-missing-prototypes -Wno-type-limits -version -fPIC -fexceptions -fvisibility=hidden -o /tmp/ccJeES8y.s Starting program: /localdata/install/gcc/objdir-gcc-4.4.1/gcc/cc1 -quiet -v -I. -I. -I../.././gcc -I../../../gcc-4.4.1/libgcc -I../../../gcc-4.4.1/libgcc/. -I../../../gcc-4.4.1/libgcc/../gcc -I../../../gcc-4.4.1/libgcc/../include -I../../../gcc-4.4.1/libgcc/config/libbid -iprefix /localdata/install/gcc/objdir-gcc-4.4.1/gcc/../lib/gcc/i686-pc-linux-gnu/4.4.1/ -isystem /localdata/install/gcc/objdir-gcc-4.4.1/./gcc/include -isystem /localdata/install/gcc/objdir-gcc-4.4.1/./gcc/include-fixed -MD divtf3.d -MF divtf3.dep -MP -MT divtf3.o -DIN_GCC -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_TLS -DHIDE_EXPORTS -isystem /localdata/i686-pc-linux-gnu/include -isystem /localdata/i686-pc-linux-gnu/sys-include -isystem ./include ../../../gcc-4.4.1/libgcc/../gcc/config/soft-fp/divtf3.c -quiet -dumpbase divtf3.c -mtune=generic -march=athlon64 -auxbase-strip divtf3.o -g -g -g -O2 -O2 -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wcast-qual -Wold-style-definition -Wno-missing-prototypes -Wno-type-limits -version -fPIC -fexceptions -fvisibility=hidden -o /tmp/ccJeES8y.s Failed to read a valid object file image from memory. ignoring nonexistent directory /localdata/i686-pc-linux-gnu/include ignoring nonexistent directory /localdata/i686-pc-linux-gnu/sys-include ignoring nonexistent directory ./include ignoring nonexistent directory /localdata/install/gcc/objdir-gcc-4.4.1/gcc/../lib/gcc/i686-pc-linux-gnu/4.4.1/include ignoring nonexistent directory /localdata/install/gcc/objdir-gcc-4.4.1/gcc/../lib/gcc/i686-pc-linux-gnu/4.4.1/include-fixed ignoring nonexistent directory /localdata/install/gcc/objdir-gcc-4.4.1/gcc/../lib/gcc/i686-pc-linux-gnu/4.4.1/../../../../i686-pc-linux-gnu/include ignoring nonexistent directory /localdata/lib/gcc/i686-pc-linux-gnu/4.4.1/include ignoring nonexistent directory /localdata/lib/gcc/i686-pc-linux-gnu/4.4.1/include-fixed ignoring nonexistent directory /localdata/lib/gcc/i686-pc-linux-gnu/../../../i686-pc-linux-gnu/include ignoring duplicate directory . ignoring duplicate directory ../../../gcc-4.4.1/libgcc/. #include
[Bug fortran/31067] MINLOC should sometimes be inlined (gas_dyn is sooooo sloooow)
--- Comment #38 from irar at il dot ibm dot com 2009-07-27 12:44 ---
I am not sure that that kind of computation can be generated automatically,
since in general the order of caclulation of cond_expr cannot be changed.
However, the loop can be split:
for (i = 0; i end; i++)
if (arr[i] limit)
limit = arr[i];
for (i = 0; i end; i++)
if (arr[i] == limit)
{
pos = i + 1;
break;
}
making the first loop vectorizable (inner-most loop vectorization).
Ira
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31067
[Bug fortran/31067] MINLOC should sometimes be inlined (gas_dyn is sooooo sloooow)
--- Comment #39 from burnus at gcc dot gnu dot org 2009-07-27 13:15 --- (In reply to comment #38) However, the loop can be split: [..] making the first loop vectorizable (inner-most loop vectorization). OK. I tried it with a Fortran program: http://users.physik.fu-berlin.de/~tburnus/tmp/vect-PR31067/maxloc.f90 http://users.physik.fu-berlin.de/~tburnus/tmp/vect-PR31067/maxloc2.f90 http://users.physik.fu-berlin.de/~tburnus/tmp/vect-PR31067/maxloc3.f90 maxloc.f90 is the program from comment 34 (maxloc.s = intel assembler) maxloc2.f90 models what gfortran does for maxloc (maxloc.s = intel assembler) maxloc3.f90 models what has a split loop The splitting plus vectorization makes the calculation 5% faster - 0m2.152s (maxloc3) vs 0m2.260s (maxloc2). Still, that's 35% more than ifort needs. For some reason, maxloc2 with -fno-tree-vectorize takes only 0m1.840s.(Identical to intel's result for maxloc2/maxloc3. While for the original maxloc.f90, there is no performance effect, and for maxloc3 vectorization makes it faster.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31067
[Bug fortran/40873] New: -fwhole-file -fwhole-program: Wrong decls cause too much to be optimized away
The option -fwhole-programs marks all functions in that file as local to that file, which facilitates inlining and dead-code elimination. That of cause assumes that all declarations are properly unified, which should be the case with -fwhole-file. However, the following Polyhedron testcases fail ac, aermod, doduc, gas_dyn, linpk, mdbx, rnflow and test_fpu at link time as too many functions have been elimated: $ gfortran -fwhole-program -O1 linpk.f90 /tmp/ccWhxrXN.o: In function `MAIN__': linpk.f90:(.text+0x759): undefined reference to `daxpy_' linpk.f90:(.text+0x7c7): undefined reference to `daxpy_' -- Summary: -fwhole-file -fwhole-program: Wrong decls cause too much to be optimized away Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40873
[Bug testsuite/40459] g++.dg/abi/mangle*.C fail on darwin
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2009-07-27 14:01 --- Not having much luck regression testing this one. Revision 148492 and 148493 both fail to bootstrap on x86_64-apple-darwin. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40459
[Bug debug/39706] namespaces represented incorrectly in debug_pubnames
-- dodji at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-07-27 14:32:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39706
[Bug debug/39708] add a debug_privnames section
-- dodji at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-07-27 14:32:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39708
[Bug debug/39705] enum constants don't appear in debug_pubnames
-- dodji at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-07-27 14:36:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39705
[Bug fortran/40873] -fwhole-file -fwhole-program: Wrong decls cause too much to be optimized away
--- Comment #1 from burnus at gcc dot gnu dot org 2009-07-27 14:47 --- (Note: -fwhole-program implies -fwhole-file; the -On option is required.) Test case. Run with -O1 -fwhole-program. Fails with: test.f90:(.text+0x1b): undefined reference to `three_' program prog call one() call two() end program prog subroutine one() call three() end subroutine one subroutine two() call three() end subroutine two subroutine three() end subroutine three -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||pault at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40873
[Bug fortran/31067] MINLOC should sometimes be inlined (gas_dyn is sooooo sloooow)
--- Comment #40 from jakub at gcc dot gnu dot org 2009-07-27 14:51 --- If the cond_expr compute a minimum or maximum and the other cond_exprs compute something based on the IV at the extremum, then I don't see why it couldn't be vectorized by computing extremes of odd/even and corresponding values based on the IV at those points, then merging them in the final step, and similarly for bigger vectorization steps. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31067
[Bug target/40783] inefficient code to accumulate function return values
--- Comment #2 from ramana at gcc dot gnu dot org 2009-07-27 15:05 ---
This seems to be related to the other reassoc + register pressure bugs reported
in the database. I am not sure if this is a dup of either PR28481 or PR27855
but they appear to be related.
With -fno-tree-reassoc I get the same code for both loops.
time_math:
push{r4, r5, r6, lr}
bl dumm
mov r4, #0
mov r6, #99
add r5, r0, #0
.L2:
add r0, r5, #0
bl __aeabi_f2iz
add r5, r5, #1
add r4, r4, r0
add r0, r5, #0
bl __aeabi_f2iz
add r5, r5, #1
add r4, r4, r0
add r0, r5, #0
bl __aeabi_f2iz
add r5, r5, #1
add r4, r4, r0
add r0, r5, #0
bl __aeabi_f2iz
add r5, r5, #1
add r4, r4, r0
sub r6, r6, #1
bcs .L2
bl dumm
mov r6, #99
add r5, r0, #0
.L3:
add r0, r5, #0
bl MyConvert
add r5, r5, #1
add r4, r4, r0
add r0, r5, #0
bl MyConvert
add r5, r5, #1
add r4, r4, r0
add r0, r5, #0
bl MyConvert
add r5, r5, #1
add r4, r4, r0
add r0, r5, #0
bl MyConvert
add r5, r5, #1
add r4, r4, r0
sub r6, r6, #1
bcs .L3
mov r0, r4
@ sp needed for prologue
pop {r4, r5, r6, pc}
.size time_math, .-time_math
.ident GCC: (GNU) 4.5.0 20090727 (experimental)
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
CC||dberlin at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-07-27 15:05:21
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40783
[Bug c++/40874] New: Function object abstraction penalty
The following program shows that wrapping a simple class around a function
pointer costs important optimizations. If you change the #if 1 to #if 0,
you'll see that the call is completely optimized away.
#if 1
struct pf
{
inline pf(int(*x)(int)) : x(x) {}
inline int operator()(int a) const
{
return x(a);
}
int (*x)(int);
};
#else
typedef int(*pf)(int);
#endif
inline int g(int x) { return x/x - 1; }
int main(int argc, char* argv[])
{
pf f(g);
return f(3);
}
--
Summary: Function object abstraction penalty
Product: gcc
Version: 4.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dave at boost-consulting dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40874
[Bug tree-optimization/39355] [4.4/4.5 Regression] Revision 144529: ICE due to missing or incorrectly relocated DECL_VALUE_EXPR in PCH header for PARM_DECL
--- Comment #51 from danglin at gcc dot gnu dot org 2009-07-27 15:10 --- Doesn't occur if I configure with --disable-libstdcxx-pch. This problem also causes the following fails (4.4.2): FAIL: 26_numerics/complex/pow.cc (test for excess errors) FAIL: tr1/8_c_compatibility/complex/overloads_float.cc (test for excess errors) FAIL: tr1/8_c_compatibility/complex/overloads_int.cc (test for excess errors) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355
[Bug java/40731] Failure to bootstrap GCJ 4.4.0
--- Comment #2 from ludo at gnu dot org 2009-07-27 15:25 --- All this was due to our build script building the `configure-gcc' target early on, which apparently confused the build process. Sigh. This bug can be closed now. Sorry for the noise. Ludo'. -- ludo at gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40731
[Bug tree-optimization/40874] Function object abstraction penalty
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-07-27 15:36 --- So one problem is that nothing after SRA (before inlining) constant props g into the call expression. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|normal |enhancement Status|UNCONFIRMED |NEW Component|c++ |tree-optimization Ever Confirmed|0 |1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2009-07-27 15:36:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40874
[Bug translation/32637] Swedish translation error
--- Comment #3 from goeran at uddeborg dot se 2009-07-27 15:41 --- (In reply to comment #2) Translation fixes goto the translation team which is not part of the GCC team really. Indeed. In this case that would be tp...@listor.tp-sv.se. But fortunately, I happened to stumble on this bug report today, and I will fix it in the next translation. -- goeran at uddeborg dot se changed: What|Removed |Added CC||goeran at uddeborg dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32637
[Bug tree-optimization/40874] Function object abstraction penalty with inline functions.
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-07-27 15:45 --- (In reply to comment #1) So one problem is that nothing after SRA (before inlining) constant props g into the call expression. So there is no abstraction penalty really just a missing inlining. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|Function object abstraction |Function object abstraction |penalty |penalty with inline ||functions. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40874
[Bug fortran/40875] New: ICE with illegal type conversion
When I compile the module listed below with gfortran 4.5 I get the message:
f951: internal compiler error: in gfc_set_constant_character_len, at
fortran/decl.c:1112
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
gfortran 4.2, 4.3, and 4.4 produce similar messages. g95 produces the message:
In file crash.f90:6
CHARACTER, PARAMETER :: the_beta = (/one_parameter('c')/)
1
Error: Can't convert TYPE(one_parameter) to CHARACTER(1) at (1)
MODULE cdf_aux_mod
PUBLIC
TYPE :: one_parameter
CHARACTER :: name
END TYPE one_parameter
CHARACTER, PARAMETER :: the_beta = (/one_parameter('c')/)
END MODULE cdf_aux_mod
--
Summary: ICE with illegal type conversion
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: michael dot a dot richmond at nasa dot gov
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40875
[Bug c++/40872] String not extracted for translation
--- Comment #2 from goeran at uddeborg dot se 2009-07-27 16:00 --- (In reply to comment #1) I think this is a pervasive issue and we have at least another couple of PRs about it in Bugzilla. Please check / commonize, thanks! I'm not sure exactly what you mean with this. This particular error message, calls of error() where the first argument is a conditional expression, or problems with translating GCC in general. I tried to look for more similar cases. But I couldn't find anything. Not that it is all that easy to search for. Neither error nor ? are particularly good search terms. :-) So I may very well have missed something. Previously, I have reported a couple of instances where things can't be properly translated. But that has mostly been cases where the code needs a small rewrite. I'm not sure how to commonize those; they typically have to be handled case-by-case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40872
[Bug tree-optimization/40874] Function object abstraction penalty with inline functions.
--- Comment #3 from dave at boost-consulting dot com 2009-07-27 16:26 --- The missing inlining is the cause, abstraction penalty is the symptom. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40874
[Bug translation/40872] String not extracted for translation
--- Comment #3 from manu at gcc dot gnu dot org 2009-07-27 16:55 --- (In reply to comment #2) I tried to look for more similar cases. But I couldn't find anything. Not that it is all that easy to search for. Neither error nor ? are particularly good search terms. :-) So I may very well have missed something. Try grep -e ' error ([^]' gcc/*.c -A 1 I am sure you can come up with smart regexp for warning, warning_at, error_at, inform and the other diagnostic functions. Previously, I have reported a couple of instances where things can't be properly translated. But that has mostly been cases where the code needs a small rewrite. I'm not sure how to commonize those; they typically have to be handled case-by-case. In this case, the string just have to be surrounded by G_() so: error (funcdef_flag ? G_(%qs defined in a non-class scope) : G_(%qs declared in a non-class scope), name); Care to contribute a patch for this and other cases? Thanks, Manuel. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |NEW Component|c++ |translation Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-07-27 16:55:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40872
[Bug translation/40872] String not extracted for translation
--- Comment #4 from goeran at uddeborg dot se 2009-07-27 17:01 --- (In reply to comment #3) Try grep -e ' error ([^]' gcc/*.c -A 1 Ah, ok. I tried to search for similar BUGZILLA reports. Not for similar cases in the code. But sure, I can search the code instead. BRB -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40872
[Bug translation/40872] String not extracted for translation
--- Comment #5 from manu at gcc dot gnu dot org 2009-07-27 17:08 --- (In reply to comment #4) (In reply to comment #3) Try grep -e ' error ([^]' gcc/*.c -A 1 Ah, ok. I tried to search for similar BUGZILLA reports. Not for similar cases in the code. Sorry, I didn't understand that was what you wanted. If you want to search in bugzilla, translated OR translation is probably what you want. But sure, I can search the code instead. BRB I don't want you to show me something that anyone can get (up-to-date) whenever one wants. I provided the information just in case you (or someone) wants to find (and fix) the code. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40872
[Bug translation/40872] String not extracted for translation
--- Comment #6 from goeran at uddeborg dot se 2009-07-27 17:11 --- (In reply to comment #5) Sorry, I didn't understand that was what you wanted. What I WANTED was to do what Paolo Carlini asked about in comment 1. I'm not sure if I understood him correctly either. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40872
[Bug fortran/40876] New: OpenMP private variable referenced in a statement function
Beginning with the OpenMP API Version 2.5, this case should fail at compile-time. The gfortran compiler does not reject this case, but gets a segmentation fault at run-time. The OpenMP API Version 3.0 (May 2008) lists the following restriction to a private clause on p 91. lines 29-30: * Variables that appear in ... expressions for statement function definitions, may not appear in a private clause. Test case: cat ISU3136.f90 ! derived from OpenMP test omp1/F2_6_2_1_2a.f90 ! According to OpenMP API Ver 2.5 May 2005 p. 75 lines 19/20 ! this is a negative test that should fail at compile-time. use omp_lib implicit none integer, parameter :: NT = 4 integer :: nThreads(NT) integer :: a, st_func, i st_func() = a + 1 !$call omp_set_dynamic(.false.) !$call omp_set_num_threads(NT) !$omp parallel private(a) a = omp_get_thread_num() !$omp barrier nThreads(omp_get_thread_num()+1) = st_func() !$omp end parallel do i = 1, NT if(nThreads(i) /= i) then print*, 'FAIL: non-private copy is used in a statement function.' endif enddo END ftn -o x -fopenmp ISU3136.f90 aprun -n 1 ./x Application 1190869 exit signals: Segmentation fault Application 1190869 resources: utime 0, stime 0 Expected output (using the Cray compiler) with a compile-time message: module swap PrgEnv-gnu PrgEnv-cray ftn -o x -h omp ISU3136.f90 !$omp parallel private(a) ^ ftn-1760 crayftn: ERROR $MAIN, File = ISU3136.f90, Line = 14, Column = 24 A is referenced in a statement function expression, so it must not be specified in the PRIVATE, FIRSTPRIVATE or LASTPRIVATE clause. -- Summary: OpenMP private variable referenced in a statement function Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: longb at cray dot com GCC build triplet: x86_64-suse-linux GCC host triplet: x86_64-suse-linux GCC target triplet: x86_64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40876
[Bug translation/40872] String not extracted for translation
--- Comment #7 from paolo dot carlini at oracle dot com 2009-07-27 17:53 --- never mind, you are just lazy, then say it more explicitly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40872
[Bug tree-optimization/40874] Function object abstraction penalty with inline functions.
--- Comment #4 from paolo dot carlini at oracle dot com 2009-07-27 17:57 --- I would say let's add Martin (and Honza) in CC, he did a lot of improvements for similar issues (which I pointed out a lot of time ago to Honza). -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||hubicka at ucw dot cz, ||jamborm at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40874
[Bug translation/40872] String not extracted for translation
--- Comment #8 from paolo dot carlini at oracle dot com 2009-07-27 18:04 --- Sorry about some harshness on my part, but in my opinion we should really have a single PR about this issue and PR34836, PR29917, PR29017, and maybe a few more... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40872
[Bug translation/40872] String not extracted for translation
--- Comment #9 from manu at gcc dot gnu dot org 2009-07-27 18:06 --- I am not going to work on this. Unsubscribing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40872
[Bug translation/40872] String not extracted for translation
--- Comment #10 from goeran at uddeborg dot se 2009-07-27 18:22 --- (In reply to comment #8) ... but in my opinion we should really have a single PR about this issue and PR34836, PR29917, PR29017 Then I did misunderstand you. These are examples of what meant needed to be handled on a case-by-case basis. If I was to handle this, I would definitely NOT wanted to have them merged. In my view one problem per report is much better than bundling a lot of bugs together. So I didn't think you meant reports like that. But this is your project, not mine, and you manage it any way you want. If you want a list of bugzillas about translation issues in general, you could start with all bugs I have submitted (including the ones you mentioned above): http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advancedbug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=SUSPENDEDbug_status=WAITINGbug_status=REOPENEDemailreporter1=1emailtype1=exactemail1=goeran%40uddeborg.se -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40872
[Bug fortran/40848] [4.5 Regression] ICE with alternate returns
--- Comment #3 from janus at gcc dot gnu dot org 2009-07-27 18:26 --- Subject: Bug 40848 Author: janus Date: Mon Jul 27 18:26:34 2009 New Revision: 150134 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150134 Log: 2009-07-27 Janus Weil ja...@gcc.gnu.org PR fortran/40848 * interface.c (gfc_compare_interfaces): Call 'count_types_test' before 'generic_correspondence', and only if checking a generic interface. 2009-07-27 Janus Weil ja...@gcc.gnu.org PR fortran/40848 * gfortran.dg/altreturn_7.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/altreturn_7.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/interface.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40848
[Bug translation/40872] String not extracted for translation
--- Comment #11 from paolo dot carlini at oracle dot com 2009-07-27 18:27 --- Yes, in similar cases either we have a single PR or at least we have a dummy Bugzilla PR bundling together related issues as blocking it. You can find many examples. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40872
[Bug c++/35535] stl_vector.h Compilation error
--- Comment #4 from paolo dot carlini at oracle dot com 2009-07-27 18:30 --- preprocessed source not forthcoming -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35535
[Bug translation/40872] String not extracted for translation
--- Comment #12 from paolo dot carlini at oracle dot com 2009-07-27 18:40 --- Such dummy PRs have the summary starting with [Meta] and all the related issues it groups are listed in the field depends on (sorry I confused depends/blocks in my previous message). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40872
[Bug libgcj/40867] [4.5 Regression] FAIL: StackTrace2 output - source compiled test
--- Comment #1 from hjl dot tools at gmail dot com 2009-07-27 19:07 --- I also see it on Linux/x86. It is an known issue: http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00266.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||hjl dot tools at gmail dot ||com, rguenth at gcc dot gnu ||dot org, aph at redhat dot ||com GCC build triplet|hppa*-*-* (32 bit) | GCC host triplet|hppa*-*-* (32 bit) | GCC target triplet|hppa*-*-* (32 bit) | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40867
[Bug fortran/40877] New: memory leaks with gfc_charlen?
This PR is a reminder to check some places where a new gfc_charlen is allocated without properly setting it into a namelist (ns-cl_list). Each of them may potentially produce a memory leak (though I'm not completely sure): * expr.c (simplify_const_ref) * symbol.c (gfc_set_default_type, generate_isocbinding_symbol) * trans-decl.c (create_function_arglist) I noticed them while working on PR40822, where I also introduced the function gfc_new_charlen, which should be used instead of gfc_get_charlen to avoid memory leaks. -- Summary: memory leaks with gfc_charlen? Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: janus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40877
[Bug translation/40872] String not extracted for translation
--- Comment #13 from goeran at uddeborg dot se 2009-07-27 19:27 --- If I can give any useful help, I'm certainly willing to do so. I'll search for bugs to add to a meta-bug if you wish. What would the criteria for inclusion be? Just anything having to do with translation? Anything with code that needs to be changed for translation, thus excluding translation errors as such? Or do you mean a grouping of bugs where the code changes are similar in some way? This meta bug would stay open forever, I assume. New errors of this kind turn up in approximately the same rate old are fixed. But that is ok then? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40872
[Bug fortran/40878] New: !$omp collapse(m) with non-constant m should give error
These test cases illustrate that gfortran ignores the COLLAPSE(M) clause on an !$OMP DO when the value given is not a constant (or declared as a variable having the parameter attribute. Other compilers supporting OpenMP API 3.0 raise an error when the primary test case is compiled. The expected output should be an error similar to that raised by either the Intel or PGI compilers. cat ISU3102.f90 ! collapse not having a constant value program test use omp_lib implicit none integer :: j,k integer :: m = 2 ! integer,parameter :: m = 2 !$omp parallel num_threads(2) private(j,k) !$omp do collapse(m) schedule (static,1) do k = 1,2 do j = 1,6 print *, k, j, omp_get_thread_num() enddo enddo !$omp end do !$omp end parallel end diff ISU3102.f90 ISU3102p.f90 6,7c6,7 integer :: m = 2 ! integer,parameter :: m = 2 --- ! integer :: m = 2 integer,parameter :: m = 2 diff ISU3102.f90 ISU3102noc.f90 9c9 !$omp do collapse(m) schedule (static,1) --- !$omp do schedule (static,1) BAD - The collapse clause is ignored rather than having an error detected: setenv OMP_NUM_THREADS 2 gfortran -o x -fopenmp ISU3102.f90 ./x | sort 1 1 0 1 2 0 1 3 0 1 4 0 1 5 0 1 6 0 2 1 1 2 2 1 2 3 1 2 4 1 2 5 1 2 6 1 Expected output when value m has parameter attribute (constant): gfortran -o xp -fopenmp ISU3102p.f90 ./xp | sort 1 1 0 1 2 1 1 3 0 1 4 1 1 5 0 1 6 1 2 1 0 2 2 1 2 3 0 2 4 1 2 5 0 2 6 1 Output when no collapse clause is present: ./xnoc | sort 1 1 0 1 2 0 1 3 0 1 4 0 1 5 0 1 6 0 2 1 1 2 2 1 2 3 1 2 4 1 2 5 1 2 6 1 Ifort (intel) raises an error: ifort -openmp -o ix ISU3102.f90 -liomp5 ISU3102.f90(9): error #8167: COLLAPSE operand must be an integer expression !$omp do collapse(m) schedule (static,1) -^ compilation aborted for ISU3102.f90 (code 1) PGI raises an error: pgf90 -mp -o px ISU3102.f90 PGF90-S-0155-The COLLAPSE expression must be a positive integer constant (ISU3102.f90: 9) 0 inform, 0 warnings, 1 severes, 0 fatal for test ifort (intel) o.k. with a value that is a parameter: ifort -openmp -o ixp ISU3102p.f90 -liomp5 ISU3102p.f90(9): (col. 7) remark: OpenMP DEFINED LOOP WAS PARALLELIZED. ISU3102p.f90(8): (col. 7) remark: OpenMP DEFINED REGION WAS PARALLELIZED. PGI o.k. with a value that is a parameter: pgf90 -mp -o pxp ISU3102p.f90 -- Summary: !$omp collapse(m) with non-constant m should give error Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: longb at cray dot com GCC build triplet: x86_64-suse-linux GCC host triplet: x86_64-suse-linux GCC target triplet: x86_64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40878
[Bug c/40879] New: stdarg.h does not define va_copy when building for C89+POSIX
POSIX 2001 specifies that va_copy (http://www.opengroup.org/onlinepubs/009695399/functions/va_copy.html) is defined by stdarg.h. However, when compiling with -std=c89 -D_POSIX_C_SOURCE=200112L this does not happen. I've encountered this in 4.3.2, but a quick peek in svn makes it look this this is current. I'll attach the source and preprocessed output. Command line: gcc -std=c89 -D_POSIX_C_SOURCE=200112L -Wall -c no_va_copy.c -save-temps no_va_copy.c: In function copy_va_list: no_va_copy.c:8: warning: implicit declaration of function va_copy gcc -v: Using built-in specs. Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.3.2-r3/work/gcc-4.3.2/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.2 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.2 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.2/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.2/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --enable-secureplt --enable-multilib --enable-libmudflap --disable-libssp --enable-libgomp --disable-libgcj --enable-languages=c,c++,treelang,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.3.2-r3 p1.6, pie-10.1.5' Thread model: posix gcc version 4.3.2 (Gentoo 4.3.2-r3 p1.6, pie-10.1.5) -- Summary: stdarg.h does not define va_copy when building for C89+POSIX Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bmerry at gmail dot com GCC build triplet: x86_64-pc-linux-gnu GCC host triplet: x86_64-pc-linux-gnu GCC target triplet: x86_64-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40879
[Bug c/40880] New: stdarg.h does not define va_copy when building for C89+POSIX
POSIX 2001 specifies that va_copy (http://www.opengroup.org/onlinepubs/009695399/functions/va_copy.html) is defined by stdarg.h. However, when compiling with -std=c89 -D_POSIX_C_SOURCE=200112L this does not happen. I've encountered this in 4.3.2, but a quick peek in svn makes it look this this is current. I'll attach the source and preprocessed output. Command line: gcc -std=c89 -D_POSIX_C_SOURCE=200112L -Wall -c no_va_copy.c -save-temps no_va_copy.c: In function copy_va_list: no_va_copy.c:8: warning: implicit declaration of function va_copy gcc -v: Using built-in specs. Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.3.2-r3/work/gcc-4.3.2/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.2 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.2 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.2/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.2/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --enable-secureplt --enable-multilib --enable-libmudflap --disable-libssp --enable-libgomp --disable-libgcj --enable-languages=c,c++,treelang,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.3.2-r3 p1.6, pie-10.1.5' Thread model: posix gcc version 4.3.2 (Gentoo 4.3.2-r3 p1.6, pie-10.1.5) -- Summary: stdarg.h does not define va_copy when building for C89+POSIX Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bmerry at gmail dot com GCC build triplet: x86_64-pc-linux-gnu GCC host triplet: x86_64-pc-linux-gnu GCC target triplet: x86_64-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40880
[Bug c/40880] stdarg.h does not define va_copy when building for C89+POSIX
--- Comment #1 from bmerry at gmail dot com 2009-07-27 19:46 --- Created an attachment (id=18258) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18258action=view) Source file illustrating the problem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40880
[Bug c/40880] stdarg.h does not define va_copy when building for C89+POSIX
--- Comment #2 from bmerry at gmail dot com 2009-07-27 19:47 --- Created an attachment (id=18259) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18259action=view) Preprocessed file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40880
[Bug c/40879] stdarg.h does not define va_copy when building for C89+POSIX
--- Comment #1 from bmerry at gmail dot com 2009-07-27 19:48 --- System threw an HTTP error 500 but managed to create a bug, so now there are two copies. Rejecting this one, bug 40880 is the real one. -- bmerry at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40879
[Bug c/40879] stdarg.h does not define va_copy when building for C89+POSIX
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-07-27 19:48 --- *** This bug has been marked as a duplicate of 40880 *** *** This bug has been marked as a duplicate of 40880 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Resolution|INVALID |DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40879
[Bug c/40880] stdarg.h does not define va_copy when building for C89+POSIX
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-07-27 19:48 --- *** Bug 40879 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40880
[Bug translation/40872] String not extracted for translation
--- Comment #14 from paolo dot carlini at oracle dot com 2009-07-27 19:50 --- First, thanks for your help. I went quickly through your own bugs, and indeed, I don't think they could reasonably all belong to the same meta-bug. However, I think a meta-bug is definitely in order grouping together all the bugs (maybe not just yours) having to do with translation problems due to trivial issues like use of conditionals, passing around and pasting C strings, etc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40872
[Bug fortran/40881] New: warn for obsolescent features
gfortran should have a flag (-Wobsolescent or similar) to turn on warnings about obsolescent features. These features are listed in chapter B.2 in the Fortran standard. They are not forbidden by the standard, but are redundant and can be replaced by newer and better features. The standard also notes the possibility that they may be removed in the future. Therefore gfortran should discourage their usage, just like the standard does. Obsolescent features in Fortran 2003 are: (1) Arithmetic IF (2) Shared DO termination and termination on a statement other than END DO or CONTINUE (3) Alternate return (4) Computed GO TO statement (5) Statement functions (6) DATA statements amongst executable statements (7) Assumed length character functions (8) Fixed form source (9) CHARACTER* form of CHARACTER declaration The -Wobsolescent flag does not have to go into -Wall (maybe -Wextra?) -- Summary: warn for obsolescent features Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: janus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40881
[Bug fortran/40882] New: [F03] infinite recursion in gfc_get_derived_type with PPC returning derived type
The following test program induces an infinite recursion in gfc_get_derived_type: implicit none type :: t real :: data procedure(foo), pointer, nopass :: ppc end type type(t) :: o,o2 o%ppc = foo o2 = o%ppc() contains function foo() type(t) :: foo foo%data = 5. foo%ppc = NULL() end function end -- Summary: [F03] infinite recursion in gfc_get_derived_type with PPC returning derived type Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: janus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40882
[Bug translation/40883] New: [meta-bug] Translation breakage with trivial fixes
Meta bug to collect cases where proper translation isn't possible, but where it would be, with fairly trivial modifications of the source code. This was requested in the discussion of bug 40872. -- Summary: [meta-bug] Translation breakage with trivial fixes Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: translation AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: goeran at uddeborg dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40883
[Bug translation/40872] String not extracted for translation
--- Comment #15 from goeran at uddeborg dot se 2009-07-27 20:43 --- Bug 40872 created as a tracker bug, with almost all my own bugs, and a few others that also seemed to qualify as trivial. I excluded bugs that referred to errors in the actual translations (l10n rather than i18n). (While probably trivial, they should have been reported to the respective team instead.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40872
[Bug debug/39706] namespaces represented incorrectly in debug_pubnames
--- Comment #1 from dodji at gcc dot gnu dot org 2009-07-27 20:43 --- Subject: Re: New: namespaces represented incorrectly in debug_pubnames I am regression testing this patchlet that seems to fix the problem in trunk ... --- Comment #2 from dodji at gcc dot gnu dot org 2009-07-27 20:43 --- Created an attachment (id=18260) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18260action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39706
[Bug translation/40883] [meta-bug] Translation breakage with trivial fixes
-- jsm28 at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||34836 Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-07-27 20:56:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40883
[Bug c/40880] stdarg.h does not define va_copy when building for C89+POSIX
--- Comment #4 from joseph at codesourcery dot com 2009-07-27 21:02 --- Subject: Re: New: stdarg.h does not define va_copy when building for C89+POSIX On Mon, 27 Jul 2009, bmerry at gmail dot com wrote: POSIX 2001 specifies that va_copy (http://www.opengroup.org/onlinepubs/009695399/functions/va_copy.html) is defined by stdarg.h. However, when compiling with -std=c89 -D_POSIX_C_SOURCE=200112L this does not happen. I've encountered this in 4.3.2, but a quick peek in svn makes it look this this is current. POSIX 2001 is based on C99 and does not have any C89 language bindings, so it is not meaningful to say it imposes any requirements when not building in C99 mode. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40880
[Bug fortran/40882] [F03] infinite recursion in gfc_get_derived_type with PPC returning derived type
--- Comment #1 from janus at gcc dot gnu dot org 2009-07-27 21:05 ---
Here is a preliminary patch which makes the test case compile:
Index: gcc/fortran/trans-types.c
===
--- gcc/fortran/trans-types.c (revision 150133)
+++ gcc/fortran/trans-types.c (working copy)
@@ -1894,7 +1894,12 @@ gfc_get_ppc_type (gfc_component* c)
{
tree t;
if (c-attr.function !c-attr.dimension)
-t = gfc_typenode_for_spec (c-ts);
+{
+ if (c-ts.type == BT_DERIVED)
+ t = c-ts.derived-backend_decl;
+ else
+ t = gfc_typenode_for_spec (c-ts);
+}
else
t = void_type_node;
/* TODO: Build argument list. */
@@ -1974,7 +1979,8 @@ gfc_get_derived_type (gfc_symbol * deriv
if (c-ts.type != BT_DERIVED)
continue;
- if (!c-attr.pointer || c-ts.derived-backend_decl == NULL)
+ if ((!c-attr.pointer !c-attr.proc_pointer)
+ || c-ts.derived-backend_decl == NULL)
c-ts.derived-backend_decl = gfc_get_derived_type (c-ts.derived);
if (c-ts.derived c-ts.derived-attr.is_iso_c)
@@ -2003,10 +2009,10 @@ gfc_get_derived_type (gfc_symbol * deriv
fieldlist = NULL_TREE;
for (c = derived-components; c; c = c-next)
{
- if (c-ts.type == BT_DERIVED)
-field_type = c-ts.derived-backend_decl;
- else if (c-attr.proc_pointer)
+ if (c-attr.proc_pointer)
field_type = gfc_get_ppc_type (c);
+ else if (c-ts.type == BT_DERIVED)
+field_type = c-ts.derived-backend_decl;
else
{
if (c-ts.type == BT_CHARACTER)
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org
|dot org |
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-07-27 21:05:09
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40882
[Bug translation/40884] New: error messages in .md files not translated
arm/neon.md, cris/cris.md, mmix/mmix.md, spu/spu-builtins.md and stormy16/predicates.md contain calls to the functions error or internal_error, whose operands would normally be extracted for translation, but exgettext does not process .md files. Since gettext doesn't know about .md files it might be simpler to fix this by moving the errors into separate functions in the relevant .c files. -- Summary: error messages in .md files not translated Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: translation AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jsm28 at gcc dot gnu dot org OtherBugsDependingO 40883 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40884
[Bug c/40885] New: build_indirect_ref i18n problems
c-typeck.c:build_indirect_ref takes an argument errorstring, which may be array indexing, unary * or - and is not translated. It should instead take an enum and pass three distinct full sentences to error_at. -- Summary: build_indirect_ref i18n problems Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jsm28 at gcc dot gnu dot org OtherBugsDependingO 40883 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40885
[Bug translation/40872] String not extracted for translation
--- Comment #16 from paolo dot carlini at oracle dot com 2009-07-27 21:19 --- Many thanks again! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40872
[Bug libstdc++/40841] Application segfaults when throwing an exception that destroys an fstream
--- Comment #9 from zlynx at acm dot org 2009-07-27 21:26 --- I built GCC using libunwind and binutils 2.19.1 and there is the same problem. The registers are *not* being restored to the right values after the exception return. In the following assembly code you can clearly see that it expects the value in r37 to remain useful after the call to f. It doesn't. mov r37=r1 addl r38=112,r1;; ld8 r38=[r38] nop.i 0x0 nop.m 0x0 nop.i 0x0 br.call.sptk.many b0=4f80 f(char const*) mov r1=r37 nop.i 0x0 br.few 40001210 main+0x190;; (Well, ok, it actually jumps to the exception catch block, but that block also does mov r1=r37 to get a PLT offset.) -- zlynx at acm dot org changed: What|Removed |Added Known to fail||4.4.1 4.4.2 Known to work||4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40841
[Bug regression/40886] New: No loop counter reversal for simple loops anymore
Given this simple program:
main()
{
int i;
for (i = 0; i 10; i++)
f2();
}
compiled with -O2
gcc33-hammer detects that the loop index is not used in the loop body
and rewrites it to a downwards counting loop, elimitinating one instruction
(inc/cmp - dec)
movl$9, %ebx
.p2align 4,,7
.L6:
xorl%eax, %eax
callf2
decl%ebx
jns .L6
popq%rbx
but gcc 4.0 - 4.3 don't anymore (tried 4.1, 4.3 and 4.4):
xorl%ebx, %ebx
.p2align 4,,7
.L2:
xorl%eax, %eax
incl%ebx
callf2
cmpl$10, %ebx
jne .L2
--
Summary: No loop counter reversal for simple loops anymore
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andi-gcc at firstfloor dot org
GCC host triplet: x86_64-linux
GCC target triplet: x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40886
[Bug fortran/40878] !$omp collapse(m) with non-constant m should give error
-- 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 Keywords||openmp Last reconfirmed|-00-00 00:00:00 |2009-07-27 22:46:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40878
[Bug fortran/40876] OpenMP private variable referenced in a statement function
-- 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 Keywords||openmp Last reconfirmed|-00-00 00:00:00 |2009-07-27 22:47:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40876
[Bug libstdc++/21769] per-file control over PCH inclusion
--- Comment #2 from janis at gcc dot gnu dot org 2009-07-27 23:51 ---
Changing dg-do would be very messy. Instead, use the existing dg-add-options.
Add the following to libstdc++-v3/testsuite/dg-options.exp:
---
# Add to FLAGS all the target-specific flags needed to disable PCH.
proc add_options_for_no_pch { flags } {
# This forces any generated and possibly included PCH to be invalid.
return $flags -D__GLIBCXX__=
}
---
In a test that should disable PCH, use
// { dg-add-options no_pch }
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21769
[Bug fortran/40853] I/O: Namelist read error
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2009-07-28 02:00 --- I will get started on this. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2009-07-27 09:40:04 |2009-07-28 02:00:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40853
[Bug fortran/40853] I/O: Namelist read error
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2009-07-28 03:09 --- As a work-around, re-arranging the derived type like this: type tao_plot_page_struct real size(2) real shape_height_max type (tao_title_struct) title end type May help, until I get this sorted out. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40853
[Bug middle-end/40887] New: GCC generates suboptimal code for indirect function calls on ARM
Consider the following code:
int (*indirect_func)();
int indirect_call()
{
return indirect_func();
}
gcc 4.4.0 generates the following with -O2 -mcpu=cortex-a8 -S:
indirect_call:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
movwr3, #:lower16:indirect_func
stmfd sp!, {r4, lr}
movtr3, #:upper16:indirect_func
mov lr, pc
ldr pc, [r3, #0]
ldmfd sp!, {r4, pc}
The problem is that the instruction ldr pc, [r3, #0] is not considered a
function call by the Cortex-A8's branch predictor, as noted in DDI0344J section
5.2.1, Return stack predictions. Thus, the return from the called function is
mispredicted resulting in a penalty of 13 cycles compared to a direct call.
Rather than doing
mov lr, pc
ldr pc, [r3]
it should instead use the blx instruction as so:
ldr lr, [r3]
blx lr
which is considered a function call by the branch predictor, and has an
overhead of only one cycle compared to a direct call.
gcc -v:
Using built-in specs.
Target: arm-none-linux-gnueabi
Configured with: ../gcc-4.4.0/configure --target=arm-none-linux-gnueabi
--prefix=/usr/local/arm --enable-threads
--with-sysroot=/usr/local/arm/arm-none-linux-gnueabi/libc
Thread model: posix
gcc version 4.4.0 (GCC)
--
Summary: GCC generates suboptimal code for indirect function
calls on ARM
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lessen42 at gmail dot com
GCC host triplet: i386-apple-darwin
GCC target triplet: arm-none-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40887
[Bug middle-end/40887] GCC generates suboptimal code for indirect function calls on ARM
--- Comment #1 from lessen42 at gmail dot com 2009-07-28 05:14 --- Created an attachment (id=18261) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18261action=view) Use blx for indirect function calls on armv5+ This fixes the test case and the obvious cases of this I found in x264; there may be more instances of not calling/returning from a function that doesn't match Cortex-A8 and A9's branch predictors (and maybe more) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40887
