[Bug c/37611] New: invalid relocation R_386_GOTOFF when using protected function pointers
When I try to use protected function pointers in a shared library, I experience strange behaviour: directly passing a function name triggers an invalid relocation during linking stage while it works when assigning the function name to a global variable first. This report might be a duplicate to the old bug 19520, but I'm not sure as my knowledge about ELF internals is rather limited and I don't understand most of the discussion there, sorry. If this is a duplicate, please excuse. Here's the output during compilation. Sources will follow in a few seconds: $ LANG="" gcc -v -save-temps -Wall test2.c -o libtest2.so -shared -fPIC -fvisibility=hidden Using built-in specs. Target: i686-pc-linux-gnu Configured with: ./configure --enable-languages=c,c++ Thread model: posix gcc version 4.3.2 (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-o' 'libtest2.so' '-shared' '-fPIC' '-fvisibility=hidden' '-mtune=generic' /usr/local/libexec/gcc/i686-pc-linux-gnu/4.3.2/cc1 -E -quiet -v test2.c -mtune=generic -Wall -fPIC -fvisibility=hidden -fpch-preprocess -o test2.i ignoring nonexistent directory "/usr/local/lib/gcc/i686-pc-linux-gnu/4.3.2/../../../../i686-pc-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/local/lib/gcc/i686-pc-linux-gnu/4.3.2/include /usr/local/lib/gcc/i686-pc-linux-gnu/4.3.2/include-fixed /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-o' 'libtest2.so' '-shared' '-fPIC' '-fvisibility=hidden' '-mtune=generic' /usr/local/libexec/gcc/i686-pc-linux-gnu/4.3.2/cc1 -fpreprocessed test2.i -quiet -dumpbase test2.c -mtune=generic -auxbase test2 -Wall -version -fPIC -fvisibility=hidden -o test2.s GNU C (GCC) version 4.3.2 (i686-pc-linux-gnu) compiled by GNU C version 4.3.2, GMP version 4.2.2, MPFR version 2.3.1. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 53913b99eaa90e1de01474d5b5d32b19 COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-o' 'libtest2.so' '-shared' '-fPIC' '-fvisibility=hidden' '-mtune=generic' as -V -Qy -o test2.o test2.s GNU assembler version 2.18.0 (i486-linux-gnu) using BFD version (GNU Binutils for Ubuntu) 2.18.0.20080103 COMPILER_PATH=/usr/local/libexec/gcc/i686-pc-linux-gnu/4.3.2/:/usr/local/libexec/gcc/i686-pc-linux-gnu/4.3.2/:/usr/local/libexec/gcc/i686-pc-linux-gnu/:/usr/local/lib/gcc/i686-pc-linux-gnu/4.3.2/:/usr/local/lib/gcc/i686-pc-linux-gnu/ LIBRARY_PATH=/usr/local/lib/gcc/i686-pc-linux-gnu/4.3.2/:/usr/local/lib/gcc/i686-pc-linux-gnu/4.3.2/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-o' 'libtest2.so' '-shared' '-fPIC' '-fvisibility=hidden' '-mtune=generic' /usr/local/libexec/gcc/i686-pc-linux-gnu/4.3.2/collect2 --eh-frame-hdr -m elf_i386 -shared -o libtest2.so /usr/lib/crti.o /usr/local/lib/gcc/i686-pc-linux-gnu/4.3.2/crtbeginS.o -L/usr/local/lib/gcc/i686-pc-linux-gnu/4.3.2 -L/usr/local/lib/gcc/i686-pc-linux-gnu/4.3.2/../../.. test2.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/local/lib/gcc/i686-pc-linux-gnu/4.3.2/crtendS.o /usr/lib/crtn.o /usr/bin/ld: test2.o: relocation R_386_GOTOFF against protected function `f2' can not be used when making a shared object /usr/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status -- Summary: invalid relocation R_386_GOTOFF when using protected function pointers Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gernot dot hillier at siemens dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37611
[Bug c/37611] invalid relocation R_386_GOTOFF when using protected function pointers
--- Comment #1 from gernot dot hillier at siemens dot com 2008-09-22 07:19 --- Created an attachment (id=16375) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16375&action=view) C file showing the problem See the body of f1 for the two cases. Using "f3( f2)" triggers the problem while "f3 (x)" works. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37611
[Bug c/37611] invalid relocation R_386_GOTOFF when using protected function pointers
--- Comment #2 from gernot dot hillier at siemens dot com 2008-09-22 07:21 --- Created an attachment (id=16376) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16376&action=view) preprocessed version of the code triggering the bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37611
[Bug tree-optimization/37482] [4.4 Regression] definition in block 51 follows the use for SSA_NAME with -maltivec
--- Comment #4 from irar at gcc dot gnu dot org 2008-09-22 07:57 --- Subject: Bug 37482 Author: irar Date: Mon Sep 22 07:55:39 2008 New Revision: 140544 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140544 Log: PR tree-optimization/37482 * tree-vectorizer.h (struct _slp_instance): Add new field. (SLP_INSTANCE_FIRST_LOAD_STMT): New. (get_earlier_stmt): New function. * tree-vect-analyze.c (vect_find_first_load_in_slp_instance): New function. (vect_analyze_slp_instance): Set SLP_INSTANCE_FIRST_LOAD_STMT. * tree-vect-transform.c (vect_finish_stmt_generation): Remove the asserts that GSI points to the scalar statement being vectorized. Set new statement location according to GSI. (vect_schedule_slp_instance): Use GSI of SLP_INSTANCE_FIRST_LOAD_STMT when vectorizing loads. Added: trunk/gcc/testsuite/gcc.dg/vect/pr37482.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-analyze.c trunk/gcc/tree-vect-transform.c trunk/gcc/tree-vectorizer.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37482
[Bug c++/14912] Do not print default template arguments in error messages
--- Comment #38 from pluto at agmk dot net 2008-09-22 09:21 --- (In reply to comment #37) > Created an attachment (id=16361) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16361&action=view) [edit] > Updated patch > > Could someone test updated patch? > it doesn't build. ../../gcc/cp/error.c: In function 'dump_template_argument': ../../gcc/cp/error.c:144: warning: passing argument 2 of 'dump_template_argument_list' makes pointer from integer without a cast ../../gcc/cp/error.c:144: error: too few arguments to function 'dump_template_argument_list' ../../gcc/cp/error.c: In function 'count_non_default_template_args': ../../gcc/cp/error.c:159: error: expected declaration specifiers before ')' token ../../gcc/cp/error.c:184: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token ../../gcc/cp/error.c:212: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token ../../gcc/cp/error.c:258: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token ../../gcc/cp/error.c:302: error: expected declaration specifiers before '}' token ../../gcc/cp/error.c:309: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token ../../gcc/cp/error.c:463: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token ../../gcc/cp/error.c:478: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token ../../gcc/cp/error.c:494: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token ../../gcc/cp/error.c:562: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token ../../gcc/cp/error.c:671: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token (...) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
[Bug middle-end/37491] [4.4 Regression] Revision 140257 causes vectorizer tests failures
--- Comment #14 from irar at il dot ibm dot com 2008-09-22 09:24 --- This patch causes the following failures on ppc: FAIL: gcc.dg/vect/pr35821-altivec.c scan-tree-dump-times vect "vectorized 1 loops" 1 FAIL: gcc.dg/vect/slp-perm-1.c scan-tree-dump-times vect "vectorized 1 loops" 1 FAIL: gcc.dg/vect/slp-perm-1.c scan-tree-dump-times vect "vectorizing stmts using SLP" 1 FAIL: gcc.dg/vect/slp-perm-2.c scan-tree-dump-times vect "vectorized 1 loops" 1 FAIL: gcc.dg/vect/slp-perm-2.c scan-tree-dump-times vect "vectorizing stmts using SLP" 1 FAIL: gcc.dg/vect/slp-perm-3.c scan-tree-dump-times vect "vectorized 1 loops" 1 FAIL: gcc.dg/vect/slp-perm-3.c scan-tree-dump-times vect "vectorizing stmts using SLP" 1 FAIL: gcc.dg/vect/slp-perm-5.c scan-tree-dump-times vect "vectorized 1 loops" 1 FAIL: gcc.dg/vect/slp-perm-5.c scan-tree-dump-times vect "vectorizing stmts using SLP" 2 FAIL: gcc.dg/vect/slp-perm-6.c scan-tree-dump-times vect "vectorized 1 loops" 1 FAIL: gcc.dg/vect/slp-perm-6.c scan-tree-dump-times vect "vectorizing stmts using SLP" 2 FAIL: gcc.dg/vect/slp-perm-7.c scan-tree-dump-times vect "vectorized 1 loops" 1 FAIL: gcc.dg/vect/slp-perm-7.c scan-tree-dump-times vect "vectorizing stmts using SLP" 1 For example, for slp-perm-1.c: slp-perm-1.c:23: note: ==> examining statement: a_7 = *pInput_40; slp-perm-1.c:23: note: get vectype with 4 units of type unsigned int slp-perm-1.c:23: note: vectype: __vector unsigned int ... slp-perm-1.c:23: note: ??? vector type does not alias scalar type ... slp-perm-1.c:23: note: not vectorized: relevant stmt not supported: a_7 = *pInput_40; pInput_40 is unsigned int* (a_7 is unsigned int) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37491
[Bug target/37584] -ftree-ch causes stack corruption on mingw32
--- Comment #4 from sherpya at netfarm dot it 2008-09-22 09:51 --- I've also seen crashes in alloca(), at least according to gdb backtrace -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37584
[Bug fortran/37486] alignment of data in COMMON blocks
-- 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|NEW |ASSIGNED Last reconfirmed|2008-09-12 20:42:06 |2008-09-22 10:00:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37486
[Bug middle-end/37491] [4.4 Regression] Revision 140257 causes vectorizer tests failures
--- Comment #15 from rguenth at gcc dot gnu dot org 2008-09-22 10:07 --- This is because the original access is through a restricted pointer, so the check is conservatively correct at this point. We can move it to the point where the vector pointer is created (but somehow I cannot make a cross-compiler go past the support check for strided loads - what are the commandline options required?). So, can you check the following? A similar change to vectorizable_store would be needed. Index: tree-vect-transform.c === *** tree-vect-transform.c (revision 140544) --- tree-vect-transform.c (working copy) *** vectorizable_load (gimple stmt, gimple_s *** 6388,6404 return false; } - /* If accesses through a pointer to vectype do not alias the original - memory reference we have a problem. This should never happen. */ - if (get_alias_set (vectype) != get_alias_set (gimple_assign_rhs1 (stmt)) - && !alias_set_subset_of (get_alias_set (vectype), -get_alias_set (gimple_assign_rhs1 (stmt - { - if (vect_print_dump_info (REPORT_DETAILS)) - fprintf (vect_dump, "??? vector type does not alias scalar type"); - return false; - } - /* The vector component type needs to be trivially convertible to the scalar lhs. This should always be the case. */ if (!useless_type_conversion_p (TREE_TYPE (scalar_dest), TREE_TYPE (vectype))) --- 6388,6393 *** vectorizable_load (gimple stmt, gimple_s *** 6662,6667 --- 6651,6663 default: gcc_unreachable (); } + + /* If accesses through a pointer to vectype do not alias the original +memory reference we have a problem. This should never happen. */ + gcc_assert (get_alias_set (data_ref) != get_alias_set (gimple_assign_rhs1 (stmt)) + && !alias_set_subset_of (get_alias_set (data_ref), + get_alias_set (gimple_assign_rhs1 (stmt; + vec_dest = vect_create_destination_var (scalar_dest, vectype); new_stmt = gimple_build_assign (vec_dest, data_ref); new_temp = make_ssa_name (vec_dest, new_stmt); Note that this _does_ show that we create wrong alias information as the pointer type vect_create_data_ref_ptr creates is _not_ marked restrict which makes us emit wrong code (wrong code in the sense that our handling of restrict pointers is not exactly correct). So in the end we probably shouldn't open this can of worms and go back to check the alias compatibility based on the types... I will prepare a patch for this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37491
[Bug middle-end/37491] [4.4 Regression] Revision 140257 causes vectorizer tests failures
--- Comment #16 from irar at il dot ibm dot com 2008-09-22 10:33 --- (In reply to comment #15) > This is because the original access is through a restricted pointer, so the > check is conservatively correct at this point. We can move it to the > point where the vector pointer is created But this way we move the check to the transformation and we don't have a mechanism to stop in the middle of transformation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37491
[Bug c/37612] New: libgcc/configure (as script)fail with "line 77 exec : : not found."
I get configure error in libgcc/configure. the new gcc compiler seem build and here, but the script as(attached) does exec a empty name in line 77 and report exec : : not found. this happen too when i want compile a program by hand and type xgcc test.c where test.c contain this main() { } so something seem wrong with the files that start as or the linker here is my config.log and as file Please help whats going wrong with the build of gcc -- This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by GNU C Runtime Library configure 1.0, which was generated by GNU Autoconf 2.59. Invocation command line was $ /w/gcc-4.3.2/libgcc/configure --cache-file=./config.cache --enable-multilib --with-cross-host=i686-pc-cygwin --with-cpu=68040 --enable-languages=c,c++ --program-transform-name=s,^,amigaos-, --with-target-subdir=amigaos --build=i686-pc-cygwin --host=amigaos --target=amigaos --srcdir=/w/gcc-4.3.2/libgcc ## - ## ## Platform. ## ## - ## hostname = bernd uname -m = i686 uname -r = 1.5.25(0.156/4/2) uname -s = CYGWIN_NT-5.1 uname -v = 2008-06-12 19:34 /usr/bin/uname -p = unknown /bin/uname -X = unknown /bin/arch = i686 /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: /w/obj_68k_4/gcc PATH: /usr/local/bin PATH: /usr/bin PATH: /bin PATH: /usr/X11R6/bin PATH: /cygdrive/f/Programme/Microsoft DirectX SDK (March 2008)/Utilities/Bin/x86 PATH: /cygdrive/c/Programme/PC Connectivity Solution/ PATH: /cygdrive/c/WINDOWS/system32 PATH: /cygdrive/c/WINDOWS PATH: /cygdrive/c/WINDOWS/System32/Wbem PATH: /cygdrive/e/Programme/QuickTime/QTSystem/ PATH: /cygdrive/c/WINDOWS/system32/kktools PATH: /cygdrive/e/Programme/TortoiseSVN/bin PATH: /cygdrive/c/PROGRA~1/CVSFOR~1 PATH: /cygdrive/c/WINDOWS PATH: /cygdrive/c/WINDOWS/COMMAND PATH: /cygdrive/c/PROGRAMME/GEMEINSAME PATH: DATEIEN/GIS/TOOLS PATH: "C PATH: /PROGRAMME/GEMEINSAME DATEIEN/GIS/TOOLS" PATH: /usr/lib/lapack ## --- ## ## Core tests. ## ## --- ## configure:1190: loading cache ./config.cache configure:1373: checking for --enable-version-specific-runtime-libs configure:1388: result: no configure:1420: checking for a BSD-compatible install configure:1475: result: /usr/bin/install -c configure:1491: checking for gawk configure:1507: found /usr/bin/gawk configure:1517: result: gawk configure:1540: checking build system type configure:1558: result: i686-pc-cygwin configure:1566: checking host system type configure:1580: result: m68k-unknown-amigaos configure:1639: checking for amigaos-ar configure:1665: result: amigaos-ar configure:1718: checking for amigaos-lipo configure:1744: result: amigaos-lipo configure:1798: checking for amigaos-nm configure:1824: result: /w/obj_68k_4/./gcc/nm configure:1877: checking for amigaos-ranlib configure:1903: result: amigaos-ranlib configure:1957: checking for amigaos-strip configure:1983: result: amigaos-strip configure:2034: checking whether ln -s works configure:2038: result: yes configure:2055: checking for amigaos-gcc configure:2081: result: /w/obj_68k_4/./gcc/xgcc -B/w/obj_68k_4/./gcc/ -B/usr/local/amigaos/bin/ -B/usr/local/amigaos/lib/ -isystem /usr/local/amigaos/include -isystem /usr/local/amigaos/sys-include configure:2363: checking for C compiler version configure:2366: /w/obj_68k_4/./gcc/xgcc -B/w/obj_68k_4/./gcc/ -B/usr/local/amigaos/bin/ -B/usr/local/amigaos/lib/ -isystem /usr/local/amigaos/include -isystem /usr/local/amigaos/sys-include --version &5 xgcc (GCC) 4.3.2 Copyright (C) 2008 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. configure:2369: $? = 0 configure:2371: /w/obj_68k_4/./gcc/xgcc -B/w/obj_68k_4/./gcc/ -B/usr/local/amigaos/bin/ -B/usr/local/amigaos/lib/ -isystem /usr/local/amigaos/include -isystem /usr/local/amigaos/sys-include -v &5 Reading specs from /w/obj_68k_4/./gcc/specs Target: amigaos Configured with: /w/gcc-4.3.2/configure --target=amigaos --with-cpu=68040 Thread model: single gcc version 4.3.2 (GCC) configure:2374: $? = 0 configure:2376: /w/obj_68k_4/./gcc/xgcc -B/w/obj_68k_4/./gcc/ -B/usr/local/amigaos/bin/ -B/usr/local/amigaos/lib/ -isystem /usr/local/amigaos/include -isystem /usr/local/amigaos/sys-include -V &5 xgcc: '-V' must come at the start of the command line configure:2379: $? = 1 configure:2398: /w/obj_68k_4/./gcc/xgcc -B/w/obj_68k_4/./gcc/ -B/usr/local/amigaos/bin/ -B/usr/local/amigaos/lib/ -isystem /usr/local/amigaos/include -isystem /usr/local/amigaos/sys-include -o conftest -O2 -g -g -O2 conftest.c >&5 /w/obj_68k_4/./gcc/as: line 77: exec: : not found configure:2401
[Bug middle-end/37491] [4.4 Regression] Revision 140257 causes vectorizer tests failures
--- Comment #17 from rguenther at suse dot de 2008-09-22 11:14 --- Subject: Re: [4.4 Regression] Revision 140257 causes vectorizer tests failures On Mon, 22 Sep 2008, irar at il dot ibm dot com wrote: > --- Comment #16 from irar at il dot ibm dot com 2008-09-22 10:33 --- > (In reply to comment #15) > > This is because the original access is through a restricted pointer, so the > > check is conservatively correct at this point. We can move it to the > > point where the vector pointer is created > > But this way we move the check to the transformation and we don't have a > mechanism to stop in the middle of transformation. Right, but if we correctly base the vectorized access on the scalar one we never should fail this test (so I made it an assert - though logically inverted :(). WRT vect_create_data_ref_ptr not only we have to build a correctly restrict qualified type but also the decl (vect_get_new_vect_var) needs to have its DECL_POINTER_ALIAS_SET set correctly. So, like the following (which seems to work on x86_64, but it looks like all the testcases with restricted pointers are not supported on x86_64). Index: gcc/tree-vect-transform.c === *** gcc/tree-vect-transform.c (revision 140544) --- gcc/tree-vect-transform.c (working copy) *** vect_create_data_ref_ptr (gimple stmt, s *** 1077,1084 --- 1077,1095 else vect_ptr_type = build_pointer_type (vectype); + if (TREE_CODE (DR_BASE_ADDRESS (dr)) == SSA_NAME + && TYPE_RESTRICT (TREE_TYPE (DR_BASE_ADDRESS (dr + vect_ptr_type = build_qualified_type (vect_ptr_type, TYPE_QUAL_RESTRICT); vect_ptr = vect_get_new_vect_var (vect_ptr_type, vect_pointer_var, get_name (base_name)); + if (TREE_CODE (DR_BASE_ADDRESS (dr)) == SSA_NAME + && TYPE_RESTRICT (TREE_TYPE (DR_BASE_ADDRESS (dr + { + get_alias_set (base_name); + DECL_POINTER_ALIAS_SET (vect_ptr) + = DECL_POINTER_ALIAS_SET (SSA_NAME_VAR (DR_BASE_ADDRESS (dr))); + } + add_referenced_var (vect_ptr); /** (2) Add aliasing information to the new vector-pointer: *** vectorizable_load (gimple stmt, gimple_s *** 6388,6404 return false; } - /* If accesses through a pointer to vectype do not alias the original - memory reference we have a problem. This should never happen. */ - if (get_alias_set (vectype) != get_alias_set (gimple_assign_rhs1 (stmt)) - && !alias_set_subset_of (get_alias_set (vectype), -get_alias_set (gimple_assign_rhs1 (stmt - { - if (vect_print_dump_info (REPORT_DETAILS)) - fprintf (vect_dump, "??? vector type does not alias scalar type"); - return false; - } - /* The vector component type needs to be trivially convertible to the scalar lhs. This should always be the case. */ if (!useless_type_conversion_p (TREE_TYPE (scalar_dest), TREE_TYPE (vectype))) --- 6399,6404 *** vectorizable_load (gimple stmt, gimple_s *** 6662,6667 --- 6662,6672 default: gcc_unreachable (); } + /* If accesses through a pointer to vectype do not alias the original +memory reference we have a problem. This should never happen. */ + gcc_assert (get_alias_set (data_ref) == get_alias_set (gimple_assign_rhs1 (stmt)) + || alias_set_subset_of (get_alias_set (data_ref), + get_alias_set (gimple_assign_rhs1 (stmt; vec_dest = vect_create_destination_var (scalar_dest, vectype); new_stmt = gimple_build_assign (vec_dest, data_ref); new_temp = make_ssa_name (vec_dest, new_stmt); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37491
[Bug c/37612] libgcc/configure (as script)fail with "line 77 exec : : not found."
--- Comment #1 from brian at dessent dot net 2008-09-22 11:15 --- Subject: Re: New: libgcc/configure (as script)fail with "line 77 exec : : not found." The error means you don't have a cross-assembler installed correctly prior to configuring gcc. gcc is just a compiler, you need the assembler and linker from elsewhere (normally binutils.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37612
[Bug c/37613] New: probelm with optmization and local variable stored in an asm register
in this simple function bug.c: void restore() { register long reg_ebx asm ("ebx"); reg_ebx = saved_ebx; } $ gcc -v Utilisation des specs internes. Target: i386-redhat-linux Configuré avec: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-cpu=generic --build=i386-redhat-linux Modèle de thread: posix gcc version 4.3.2 20080905 (Red Hat 4.3.2-3) (GCC) $ uname -a Linux lima.univ-paris1.fr 2.6.24-0.83.rc5.fc9 #1 SMP Tue Dec 11 12:04:08 EST 2007 i686 i686 i386 GNU/Linux $ gcc -O -S -ffixed-ebx -fomit-frame-pointer bug.c $ cat bug.c restore: rep ret .size restore, .-restore .comm saved_ebx,4,4 the function is empty: the assignment to reg_ebx has been discarded (because considered as a local variable). In the presence of asm it should be kept. It is OK if -O is not given. Maybe there is a way do it differently (btw I cannot declare the var as global nor static in my application). -- Summary: probelm with optmization and local variable stored in an asm register Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: daniel dot diaz at univ-paris1 dot fr GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37613
[Bug c/37613] probelm with optmization and local variable stored in an asm register
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-09-22 11:27 --- reg_ebx is obviously unused in your function so the assignment is DCEd. I guess what you try to do is not really possible with C. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37613
[Bug fortran/37486] alignment of data in COMMON blocks
--- Comment #9 from janus at gcc dot gnu dot org 2008-09-22 11:46 --- Subject: Bug 37486 Author: janus Date: Mon Sep 22 11:45:02 2008 New Revision: 140546 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140546 Log: 2008-09-22 Janus Weil <[EMAIL PROTECTED]> PR fortran/37486 * gfortran.h (gfc_option_t): New members flag_align_commons and warn_align_commons. * lang.opt: New options falign-commons and Walign-commons. * invoke.texi: Documentation for new options. * options.c (gfc_init_options): Initialize new options. (gfc_handle_options): Handle new options. * trans-common.c (translate_common): Implement new options. (gfc_trans_common): Set correct locus. 2008-09-22 Janus Weil <[EMAIL PROTECTED]> PR fortran/37486 * gfortran.dg/common_align_1.f90: New. * gfortran.dg/warn_align_commons.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/common_align_1.f90 trunk/gcc/testsuite/gfortran.dg/warn_align_commons.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/invoke.texi trunk/gcc/fortran/lang.opt trunk/gcc/fortran/options.c trunk/gcc/fortran/trans-common.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37486
[Bug tree-optimization/37145] [4.4 Regression] XFAILs from PRE rewrite
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-09-22 11:54 --- Technically gcc.dg/tree-ssa/ssa-fre-10.c also fails (or rather it doesn't properly test for what it is supposed to). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37145
[Bug tree-optimization/37145] [4.4 Regression] XFAILs from PRE rewrite
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-09-22 11:54 --- Subject: Bug 37145 Author: rguenth Date: Mon Sep 22 11:53:29 2008 New Revision: 140547 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140547 Log: 2008-09-22 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/37145 * tree-ssa-pre.c (fully_constant_expression): Simplify builtin calls. (phi_translate_1): Constant fold references. * gcc.dg/tree-ssa/ssa-pre-15.c: Remove XFAIL. Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-pre-15.c trunk/gcc/tree-ssa-pre.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37145
[Bug fortran/37486] alignment of data in COMMON blocks
--- Comment #10 from janus at gcc dot gnu dot org 2008-09-22 11:50 --- Fixed with r140546. Closing. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37486
[Bug middle-end/37491] [4.4 Regression] Revision 140257 causes vectorizer tests failures
--- Comment #18 from rguenth at gcc dot gnu dot org 2008-09-22 11:48 --- Created an attachment (id=16377) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16377&action=view) patch Actually this one vectorizes slp-perm-1.c for me on a ppc64 cross. It also passes the x86_64 vect testsuite. I will give it full testing on x86_64, can you test it on ppc? Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37491
[Bug c++/34624] valid c++ code doesn't compile for x86_64, but for i386
--- Comment #5 from tim at klingt dot org 2008-09-22 12:11 --- i have the same issue with both gcc-4.3 and gcc-4.4 ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34624
[Bug tree-optimization/37542] [4.4 Regression] PRE doesn't simplify during phi-translation
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-09-22 12:20 --- Current PRE simplifies only a subset of previous PRE - see tree-ssa-pre.c:fully_constant_expression. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37542
[Bug tree-optimization/37145] [4.4 Regression] XFAILs from PRE rewrite, SCCVN union optimization disabled
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-09-22 12:22 --- All XFAILs left are due to the SCCVN union value-numbering optimization being disabled: #if FIXME /* If this is a reference to a union member, record the union member size as operand. Do so only if we are doing expression insertion (during FRE), as PRE currently gets confused with this. */ if (may_insert && TREE_CODE (DECL_CONTEXT (TREE_OPERAND (ref, 1))) == UNION_TYPE && integer_zerop (DECL_FIELD_OFFSET (TREE_OPERAND (ref, 1))) && integer_zerop (DECL_FIELD_BIT_OFFSET (TREE_OPERAND (ref, 1 temp.op0 = TYPE_SIZE (TREE_TYPE (TREE_OPERAND (ref, 1))); else #endif if you simply enable it it miscompiles GCC. The testsuites of all languages are clean though. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.4 Regression] XFAILs from|[4.4 Regression] XFAILs from |PRE rewrite |PRE rewrite, SCCVN union ||optimization disabled http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37145
[Bug middle-end/37491] [4.4 Regression] Revision 140257 causes vectorizer tests failures
--- Comment #19 from irar at il dot ibm dot com 2008-09-22 12:32 --- (In reply to comment #18) > Created an attachment (id=16377) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16377&action=view) [edit] > patch > > Actually this one vectorizes slp-perm-1.c for me on a ppc64 cross. It also > passes the x86_64 vect testsuite. > > I will give it full testing on x86_64, can you test it on ppc? Thanks. > It passes the vectorizer testsuite on ppc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37491
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #52 from rguenth at gcc dot gnu dot org 2008-09-22 12:40 --- Can we please have "1) -fno-exceptions This flag turns off C++ exception handling support, which is indicated at compile time by __GXX_EXCEPTIONS being undefined. Use of the keywords try, catch, or throw produces an error. As a result, use of most C++ includes will fail." of comment #46 simply by the original suggestion, make the standard library use __try and __catch and change libsupc++/exception_defines.h accordingly? Appearantly the library wants to work without exception support, but this support needs to be implemented in a way not messing with standard C++ keywords. Note the frontend already undefines __EXCEPTIONS for -fno-exceptions: >g++ -dD -E t.C | grep EXCE #define __EXCEPTIONS 1 > g++ -dD -E t.C -fno-exceptions | grep EXCE The frontend also produces an error if try or catch are used with -fno-exceptions, but the _standard library implementation_ causes this error do disappear(!) Which is what this bug is about really. It seems the library maintainers are not willing to see this problem. Asking for a new C++ frontend feature as an excuse to not fix the library problem is very lame IMHO. So can we please - finally - do something about this? Thank you very much. Richard. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.1.3 4.3.0 |4.1.3 4.3.0 4.4.0 Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug middle-end/37491] [4.4 Regression] Revision 140257 causes vectorizer tests failures
--- Comment #20 from irar at il dot ibm dot com 2008-09-22 12:41 --- (In reply to comment #18) > Created an attachment (id=16377) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16377&action=view) [edit] > patch > > Actually this one vectorizes slp-perm-1.c for me on a ppc64 cross. It also > passes the x86_64 vect testsuite. > > I will give it full testing on x86_64, can you test it on ppc? Thanks. > I am fully testing it now, but I'll be able to update you about the results only tomorrow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37491
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #53 from rguenth at gcc dot gnu dot org 2008-09-22 12:41 --- CCing C++ FE maintainers. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||jason at gcc dot gnu dot ||org, mark at codesourcery ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug c++/37615] New: terminate called after throwing and instance of 'XXX' c++ testsuite failures
Ran gcc testsuite and got a lot of c++ testsuite failures like for g++.dg/eh/cond1.C: ... terminate called after throwing an instance of 'int' terminate called recursively ... Compiler details: Target: arm-linux-gnueabi Configured with: /work/psl/eldk-builds/arm-2008-09-10/work/usr/src/denx/BUILD/crosstool-0.43/build/gcc-4.2.2-glibc-20070515T2025-eldk/arm-linux-gnueabi/gcc-4.2.2/configure --target=arm-linux-gnueabi --host=i686-host_pc-linux-gnu --prefix=/var/tmp/eldk.tL5647/usr/crosstool/gcc-4.2.2-glibc-20070515T2025-eldk/arm-linux-gnueabi --disable-hosted-libstdcxx --with-headers=/var/tmp/eldk.tL5647/usr/crosstool/gcc-4.2.2-glibc-20070515T2025-eldk/arm-linux-gnueabi/arm-linux-gnueabi/include --with-local-prefix=/var/tmp/eldk.tL5647/usr/crosstool/gcc-4.2.2-glibc-20070515T2025-eldk/arm-linux-gnueabi/arm-linux-gnueabi --disable-nls --enable-threads=posix --enable-symvers=gnu --enable-__cxa_atexit --enable-languages=c,c++,java --enable-shared --enable-c99 --enable-long-long --without-x Thread model: posix gcc version 4.2.2 It's interesting that statically-built binary run OK. Also, according to testresults in http://gcc.gnu.org/ml/gcc-testresults/2007-09/msg00570.html , this should work, unless got broken in release version. Known to work on powerpc, toolchain is the same. -- Summary: terminate called after throwing and instance of 'XXX' c++ testsuite failures Product: gcc Version: 4.2.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sposelenov at emcraft dot com GCC host triplet: i386-linux GCC target triplet: arm-linux-gnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37615
[Bug fortran/37614] New: Change position of padding for aligned COMMONs
Follow up to PR 37486. see also http://gcc.gnu.org/ml/fortran/2008-09/msg00366.html The following program should print "5" but it prints "0" with default options in gfortran. The problem is that in the program, the common object is padded as <4bytes padding> + i + r8 and then in the subroutine, only the first 4 bytes are read and assigned to the local variable "i". The program is valid as "Named common blocks of the same name shall be of the same size in all scoping units of a program in which they appear, but blank common blocks may be of different sizes." As tests with NAG f95, Portland pgf95 and Pathscale pathf95 show, these compilers use i + <4bytes padding> + r8 which allows this program to run correctly without sacrificing the alignment. (ifort, sunf95 and g95 - and "gfortran -fno-align-commons" work as no padding is added.) There are still used but not standard conform versions which fail (cf. examples in PR 37486) but for those, gfortran has -fno-align-commons. Test program: subroutine one() integer :: i, j common i print *, i ! shall print "5", in gfortran it is "0" ! ! Testing alternative (invalid standard Fortran): ! common i,j ! print *, i,j end subroutine one program test integer :: i real*8 r8 common i, r8 i = 5 r8 = 123457891234d88 call one() end program test If one enables the "common i, j" and runs the program with several compilers, details about their implementation is revealed: - gfortran and g77 print "0 5" - ifort, sunf95 and g95 print "5 1267487353" (= gfortran -fno-align-commons) - pathscale, pgi, and NAG f95 print "5 0" << expected result when PR is fixed -- Summary: Change position of padding for aligned COMMONs Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: wrong-code 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=37614
[Bug c/37591] suppress "signed and unsigned" warnings when signed value known to be positive
--- Comment #4 from manu at gcc dot gnu dot org 2008-09-22 13:28 --- I don't understand why this is not closed as wontfix. These warnings are coming from the front-end. Unless we do one of the following: a) some CCP and VRP in the FE, or b) move the warnings to the middle-end, this cannot be fixed. And the consensus seems to be that we do not want to do either of them. And from the many problems we see with Wuninitialized, we already know that moving the warnings to the middle-end causes a lot of problems. Also, VRP is only enabled at -O2. And it does not work with sets, only ranges, so the following will still not work: adj = (flag) ? 0 : 2; return MIN(adj, limit); (I am sure that we have already, probably closed, a PR about this). -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37591
[Bug c++/37615] terminate called after throwing and instance of 'XXX' c++ testsuite failures
--- Comment #1 from sposelenov at emcraft dot com 2008-09-22 13:32 --- Created an attachment (id=16378) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16378&action=view) Reduced testcase Build as: arm-linux-gnueabi-g++ -o cond1 cond1.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37615
[Bug c/37613] probelm with optmization and local variable stored in an asm register
--- Comment #2 from daniel dot diaz at univ-paris1 dot fr 2008-09-22 14:08 --- Richard Guenther says it is impossible in C... In C maybe but not in GNU C :-) This worked perfectly under older versions (may gcc 3.x.x) and it is a pitty if this feature is lost now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37613
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #54 from paolo dot carlini at oracle dot com 2008-09-22 14:08 --- (In reply to comment #52) > It seems the library maintainers are not willing to see this problem. > Asking for a new C++ frontend feature as an excuse to not fix the > library problem is very lame IMHO. For the record, speaking of myself, see Comments #43 and #45. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug middle-end/37608] [4.4 Regression] libgcc2.c:1981: ICE: vector VEC(m em_ref_p,base) index domain error, in create_vop_ref_mapping_loop at tree-ssa-lo op-im.c:1519
--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2008-09-22 14:11 --- Subject: Re: [4.4 Regression] libgcc2.c:1981: ICE: vector VEC(m em_ref_p,base) index domain error, in create_vop_ref_mapping_loop at tree-ssa-lo op-im.c:1519 Attached .i. Dave --- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2008-09-22 14:11 --- Created an attachment (id=16379) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16379&action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37608
[Bug c++/14912] Do not print default template arguments in error messages
--- Comment #39 from b0ntrict0r at yandex dot ru 2008-09-22 15:12 --- Created an attachment (id=16380) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16380&action=view) Updated fixed -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
[Bug rtl-optimization/33642] unrecognizable insn for -frtl-abstract-sequences
--- Comment #30 from dje at gcc dot gnu dot org 2008-09-22 15:17 --- Subject: Bug 33642 Author: dje Date: Mon Sep 22 15:15:56 2008 New Revision: 140551 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140551 Log: PR rtl-optimization/33642 * gcc.c-torture/compile/pr11832.c: Extend XFAIL to powerpc*-*-*. * gcc.c-torture/compile/pr33009.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.c-torture/compile/pr11832.c trunk/gcc/testsuite/gcc.c-torture/compile/pr33009.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33642
[Bug c++/37590] g++ should emit different debug info for variable's type
--- Comment #5 from tromey at gcc dot gnu dot org 2008-09-22 15:19 --- No, I think we have to record what the user actually wrote. For instance, consider: #include using namespace std; std::string x1; string x2; If we record the fully qualified name, we can't distinguish these two cases. I would prefer a solution not relying on heuristics in the debugger. (And can we even "undo" using directives this way correctly? I am not sure.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37590
[Bug c++/37590] g++ should emit different debug info for variable's type
--- Comment #6 from jan dot kratochvil at redhat dot com 2008-09-22 15:32 --- Tom, could you elaborate why x1 and x2 should be printed differently? I do not say they should not but I do not see a clear reason for either way. Should we also try to record the source name of this variable? #define OBJECT_VAR(object, var) object ## _ ## var int OBJECT_VAR (window, width); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37590
[Bug c/37591] suppress "signed and unsigned" warnings when signed value known to be positive
--- Comment #5 from zackw at panix dot com 2008-09-22 15:46 --- I'm not monitoring consensus of developers anymore, but I think we *should* either move these warnings to the middle end or do some CCP/VRP in the front ends. The -Wuninitialized warnings are a lot less trouble than the signed/unsigned warnings, right now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37591
Periodic Account Update
Dear Nrao Email Account User, We wrote to you on 29 july 2008 advising that you change the password on your account in order to prevent any unauthorised account access following the network instruction we previously communicated. All Mailhub systems will undergo regularly scheduled maintenance. Access to your e-mail via the Webmail client will be unavailable for some time during this maintenance period. We are currently upgrading our data base and e-mail account center i.e homepage view. We shall be deleting old [Nrao] email accounts which are no longer active to create more space for new accounts users. we have also investigated a system wide security audit to improve and enhance our current security. In order to continue using our services you are require to update and re-comfirmed your email account details as requested below. To complete your account re-comfirmation,you must reply to this email immediately and enter your account details as requested below. Username : () Password : () Date of Birth : (2/2/48) Future Password : (**)(Option) Failure to do this will immediately render your account deactivated from our database and service will not be interrupted as important messages may as well be lost due to your declining to re-comfirmed to us your account account details. We apologise for the inconvenience that this will cause you during this period, but trusting that we are here to serve you better and providing more technology which revolves around Secured Email. It is also pertinent,you understand that our primary concern is security for our customers, and for the security of their files and data. COMFIRMATION CODE: Nrao /93-1A388-480 Technical Support Team Regards Nrao Support/Maintainance Team TSR.
[Bug target/37381] [4.4 Regression] ICE in ia64_speculate_insn, at config/ia64/ia64.c:6902
--- Comment #8 from sje at cup dot hp dot com 2008-09-22 16:35 --- I'll try to review the IA64 sel-sched patch over the next couple of weeks. I can't approve the workaround since it is not IA64 specific (it is in haifa-sched.c). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37381
[Bug c/37591] suppress "signed and unsigned" warnings when signed value known to be positive
--- Comment #6 from manu at gcc dot gnu dot org 2008-09-22 16:43 --- Then, try to raise the issue in GCC and outline a clear plan. Otherwise, I assure you this is going to stay as-is for the next 5-10 years because nobody has a clear idea on how to tackle this in a way that pleases a majority. Also, because it has an easy workaround: use a casting to unsigned. Some starting points: * Moving the warning to the middle-end is not going to avoid warning in this testcase unless VRP is enabled. For -O0 and -O1, we will keep warning. * Moving the warning to the middle-end means that we will warn/not warn depending on the ordering of passes, missed optimisations, etc. * Clang people claim that they can do a simple CCP pass very efficiently in the FE. Perhaps we could do the same. However, we are currently moving optimizations (such as folding) to later stages. In any case, VRP in the front-end is what would be needed for this testcase. Is that even possible? Can be done efficiently? The same issues apply to many warnings: -Wconversion, -Wuninitialized, -Wtype-limits. As Richard said: This is the usual trade-off of doing warnings from the frontends versus from the middle-end. One gives consistency and speed but frequent false positives, and the other gives more precision at the cost of consistent results and more compilation time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37591
[Bug fortran/36592] F2003: Procedure pointer in COMMON
--- Comment #1 from janus at gcc dot gnu dot org 2008-09-22 16:50 --- Created an attachment (id=16381) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16381&action=view) patch The attached patch is as far as I got with this up to now. It regtests fine and makes the following modified version of the test case in comment #0 compile (I think in the original test case there was a "p" missing in the first common block): subroutine one() implicit none integer :: a,b procedure(real), pointer :: p common /com/ a,p,b print *,a,b,p(0.0) end subroutine one program main implicit none integer :: x,y intrinsic cos procedure(real), pointer :: func1 common /com/ x,func1,y x = 5 y = -9 func1 => cos call one() end program main Although this test case compiles without error, it gives the wrong output: 5 -9 NaN -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36592
[Bug debug/37616] New: Lines with 'break', 'goto', and 'continue' are not available for debugging.
Lines with 'break', 'goto', and 'continue' are not available for debugging. On GCC compilers, one can not set a breakpoint on lines with 'goto', 'break', or 'continue' statements. This is incorrect, since these lines contain user statements. Also, for example IBM XLC compilers on AIX 6.1 have these lines available for setting breakpoints when debugging. This fails both when using gdb and TotalView debugger. The root problem seems to be that the GCC DWARF explicitly tells the debugger to skip the lines in question. > uname -a Linux rhel52-x8664.totalviewtech.com 2.6.18-92.el5 #1 SMP Tue Apr 29 13:16:15 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux > cat /etc/*-rel* cat: /etc/lsb-release.d: Is a directory Red Hat Enterprise Linux Server release 5.2 (Tikanga) > rpm -q glibc glibc-2.5-24 glibc-2.5-24 g++ -g -O0 -v -o a_g_gcc.out e24018.cxx gcc version 4.1.2 20071124 (Red Hat 4.1.2-42) totalview ./a_g_gcc.out => looking at the source code pane, we see that lines #12 (continue), #14 (goto), and #16 (break) are not available for setting breakpoints. How to reproduce using gdb: > gdb a_g_gcc.out GNU gdb Red Hat Linux (6.5-37.el5rh) Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu"...Using host libthread_db library "/lib64/libthread_db.so.1". (gdb) break 12 Breakpoint 1 at 0x40071b: file e24018.cxx, line 12. (gdb) run Starting program: /nfs/netapp0/user/home/seppo/Bugs/Bug_11496/a_g_gcc.out Breakpoint 1, main () at e24018.cxx:13 13 if (jj == 7) (gdb) list 8 9 for (jj = 0; jj < 10; jj++) 10{ 11 if (jj == 5) 12continue; 13 if (jj == 7) 14goto exit; 15 if (jj == 9) 16break; 17 mm = jj; (gdb) print jj $1 = 0 (gdb) cont Continuing. Breakpoint 1, main () at e24018.cxx:13 13 if (jj == 7) (gdb) print jj $2 = 1 (gdb) => notice how the debugger stopped at line #13, although the breakpoint was set at line #12. Also the stopping happened at the wrong point in execution, since jj=0 (and not jj=5, as the user wanted). XXX Analysis: readelf -wl ./a_g_gcc.out > ! readelf_gcc.txt ... Set File Name to entry 1 in the File Name Table Advance Line by -71 to 5 Special opcode 173: advance Address by 12 to 0x400704 and Line by 0 to 5 Special opcode 121: advance Address by 8 to 0x40070c and Line by 4 to 9 Special opcode 133: advance Address by 9 to 0x400715 and Line by 2 to 11 Special opcode 91: advance Address by 6 to 0x40071b and Line by 2 to 13 Special opcode 91: advance Address by 6 to 0x400721 and Line by 2 to 15 Special opcode 91: advance Address by 6 to 0x400727 and Line by 2 to 17 Advance Line by -8 to 9 => notice how lines #12, 14, and #16 are skipped in DWARF X reproducer #include using namespace std; int main() { int jj, mm; for (jj = 0; jj < 10; jj++) { if (jj == 5) continue; if (jj == 7) goto exit; if (jj == 9) break; mm = jj; } exit: printf("About to exit\n"); return(0); } XX -- Summary: Lines with 'break', 'goto', and 'continue' are not available for debugging. Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: seppo at totalviewtech dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37616
[Bug libstdc++/32422] Problem reading floats with exponent marker but no exponent
--- Comment #3 from paolo dot carlini at oracle dot com 2008-09-22 17:25 --- I'm fixing this, together with DR 23. -- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle |dot org |dot com Status|SUSPENDED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32422
[Bug libstdc++/37391] examples not accessible online (non existing URLs)
--- Comment #2 from bkoz at gcc dot gnu dot org 2008-09-22 19:06 --- All the test and example links in pb_ds that point to source files are broken. These include links linked to from these pages: libstdc++-v3/doc/html/ext/pb_ds/assoc_examples.html libstdc++-v3/doc/html/ext/pb_ds/pq_examples.html libstdc++-v3/doc/html/ext/pb_ds/assoc_tests.html libstdc++-v3/doc/html/ext/pb_ds/pq_tests.html These links are fine when browsed in the source tree, but the on-line version does not include the sources that these links point to, so thus the broken links. The way to fix this would be to include the example files inline in the documentation, or link to cvsweb or other web versions of the pages. -benjamin -- bkoz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bkoz at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-09-22 19:06:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37391
[Bug tree-optimization/37145] [4.4 Regression] XFAILs from PRE rewrite, SCCVN union optimization disabled
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-09-22 19:17 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37145
[Bug tree-optimization/37145] [4.4 Regression] XFAILs from PRE rewrite, SCCVN union optimization disabled
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-09-22 19:17 --- Subject: Bug 37145 Author: rguenth Date: Mon Sep 22 19:15:43 2008 New Revision: 140562 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140562 Log: 2008-09-22 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/37145 * tree-ssa-sccvn.c (copy_reference_ops_from_ref): Re-enable value-numbering union accesses with their offset and size only. (visit_reference_op_load): Fix simplification of inserted conversions. * tree-ssa-pre.c (find_or_generate_expression): Do not recursively generate expressions if running FRE. * gcc.c-torture/compile/20080922-1.c: New testcase. * gcc.dg/tree-ssa/ssa-fre-7.c: Remove XFAIL. * gcc.dg/tree-ssa/ssa-fre-8.c: Likewise. * gcc.dg/tree-ssa/ssa-fre-9.c: Likewise. Added: trunk/gcc/testsuite/gcc.c-torture/compile/20080922-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-7.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-8.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-9.c trunk/gcc/tree-ssa-pre.c trunk/gcc/tree-ssa-sccvn.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37145
[Bug tree-optimization/37537] mfcr is produced when a branch should be done
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37537
[Bug debug/37616] Lines with 'break', 'goto', and 'continue' are not available for debugging.
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-09-22 19:39 --- Related to PR 29609. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37616
[Bug debug/37616] Lines with 'break', 'goto', and 'continue' are not available for debugging.
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-09-22 19:44 --- Also related to PR 36690. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37616
[Bug bootstrap/37612] libgcc/configure (as script)fail with "line 77 exec : : not found."
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Component|c |bootstrap GCC host triplet|Cygwin 686 (amigaos 68k)|Cygwin 686 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37612
[Bug target/37593] -mlong-calls doesn't affect calls to _mcount generated with -pg
--- Comment #3 from daney at gcc dot gnu dot org 2008-09-22 19:49 --- Subject: Bug 37593 Author: daney Date: Mon Sep 22 19:48:09 2008 New Revision: 140563 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140563 Log: 2008-09-22 David Daney <[EMAIL PROTECTED]> PR target/37593 * config/mips/mips.h (FUNCTION_PROFILER): Call _mcount via a register if TARGET_LONG_CALLS. 2008-09-22 David Daney <[EMAIL PROTECTED]> PR target/37593 * gcc.target/mips/long-calls-pg.c: New test. Added: trunk/gcc/testsuite/gcc.target/mips/long-calls-pg.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/mips/mips.h trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37593
[Bug target/37593] -mlong-calls doesn't affect calls to _mcount generated with -pg
--- Comment #4 from daney at gcc dot gnu dot org 2008-09-22 19:52 --- Fix committed. -- daney at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37593
[Bug c/37609] Pointer arithmetic yields strange result
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-09-22 19:54 --- This is invalid code as the difference between ((EDIDDetailed *) &pExt->checksum) - pDTD is 88 which is not a multiple of 18. This happens the same way on powerpc. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Component|target |c Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37609
[Bug c++/37582] [4.3 Regression] std::pow strange overload resolution
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-09-22 19:55 --- Is && part of GNU C++98 now? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37582
[Bug middle-end/37601] [4.4 Regression] gcc-4.4-20080919 ada build failure
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-09-22 19:57 --- Can you try this again? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|blocker |normal Component|ada |middle-end Summary|gcc-4.4-20080919 ada build |[4.4 Regression] gcc-4.4- |failure |20080919 ada build failure Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37601
[Bug libgcj/18266] GCJ: Using references drops finalizers causing all apps to eventually crash ( SIGSEGV in GC_register_finalizer_inner () )
--- Comment #16 from daney at gcc dot gnu dot org 2008-09-22 20:08 --- This is biting me now. Perhaps I may look at fixing it (or maybe not...). -- daney at gcc dot gnu dot org changed: What|Removed |Added CC||daney at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18266
[Bug rtl-optimization/37617] New: gcc 4.4 regression: ICE on valid code
I get an ICE using SVN version 140562: ~/gcc_inst/bin/gcc testcase-min.i -O1 testcase-min.i: In function test_token_dval: testcase-min.i:19: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. This does not happen with my previous build of gcc 4.4 SVN r140456: $ x86_64-unknown-linux-gnu-gcc-4.4.0 -O1 test.i -c $ $ ~/gcc_inst/bin/gcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --enable-languages=c --disable-multilib --disable-bootstrap --disable-static --prefix=/home/edwin/gcc_inst/ Thread model: posix gcc version 4.4.0 20080922 (experimental) (GCC) $ x86_64-unknown-linux-gnu-gcc-4.4.0 -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --enable-languages=c --disable-multilib Thread model: posix gcc version 4.4.0 20080918 (experimental) (GCC) -- Summary: gcc 4.4 regression: ICE on valid code Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: edwintorok at gmail dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37617
[Bug rtl-optimization/37617] gcc 4.4 regression: ICE on valid code
--- Comment #1 from edwintorok at gmail dot com 2008-09-22 20:18 --- /* testcase compile this with -O1 */ typedef struct TCase TCase; typedef void (*TFun) (int); typedef struct Suite Suite; void _tcase_add_test (TCase * tc, TFun tf, const char *fname, int signal, int start, int end); void _fail_unless (int result, const char *file, int line, const char *expr, ...); enum val_type { vtype_undefined, vtype_cstring, vtype_string, vtype_scope, vtype_dval, vtype_ival }; typedef struct token { union { char *string; double dval; } val; enum val_type vtype; } yystype; static int vtype_compatible (enum val_type orig, enum val_type req) { } static void test_token_dval (int _i __attribute__ ((unused))) { { int val = 0.12345; yystype tok; do { (&tok)->val.dval = (val); } while (0); _fail_unless ((vtype_compatible ((&tok)->vtype, vtype_string) ? (&tok)-> val.string : ((void *) 0)) == ((void *) 0), "../../../trunk/unit_tests/check_jsnorm.c", 150, "Assertion '" "TOKEN_GET(&tok, string) == NULL" "' failed", "token dval->string", ((void *) 0)); } } Suite * test_jsnorm_suite (void) { TCase *tc_jsnorm_gperf, *tc_jsnorm_token, *tc_jsnorm_api, *tc_jsnorm_tokenizer, *tc_jsnorm_bugs, *tc_screnc_infloop; _tcase_add_test ((tc_jsnorm_token), (test_token_dval), "" "test_token_dval" "", (0), 0, 1); } -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37617
[Bug fortran/36592] F2003: Procedure pointer in COMMON
--- Comment #2 from burnus at gcc dot gnu dot org 2008-09-22 20:22 --- (In reply to comment #1) > Created an attachment (id=16381) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16381&action=view) [edit] > Although this test case compiles without error, it gives the wrong output: If you had used -fdump-tree-original, you knew that you created a simple local procedure pointer, which is not in common and thus a NaN or a crash or ... makes sense. Not surprisingly the culprit is the if (proc_pointer) {one line} else { lots of lines } in trans-common.c. How about the following patch? $ svn revert trans-common.c $ patchattr.proc_pointer = 0; + type = build_pointer_type (gfc_get_function_type (sym)); + sym->attr.proc_pointer = 1; + return type; +} + EOF PS: You should reorder the items in COMMON as on x86-64 the pointers are 8-bytes wide, which causes a alignment/padding warning be printed. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-09-22 20:22:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36592
[Bug rtl-optimization/37617] [4.4 Regression] ICE on valid code
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-valid-code Summary|gcc 4.4 regression: ICE on |[4.4 Regression] ICE on |valid code |valid code Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37617
[Bug c/37609] Pointer arithmetic yields strange result
--- Comment #5 from john dot spelis at 3dlabs dot com 2008-09-22 20:40 --- Subject: Re: Pointer arithmetic yields strange result Apologies; never realised that pointer arithmetic was defined in that fashion (i.e. must always be a multiple of the object size). Sorry to have bothered you. Best Regards. On 22 Sep 2008, pinskia at gcc dot gnu dot org wrote: > > > --- Comment #4 from pinskia at gcc dot gnu dot org 2008-09-22 19:54 > --- > This is invalid code as the difference between ((EDIDDetailed *) > &pExt->checksum) - pDTD is 88 which is not a multiple of 18. This happens the > same way on powerpc. > > > -- > > pinskia at gcc dot gnu dot org changed: > >What|Removed |Added > > Status|NEW |RESOLVED > Component|target |c > Resolution||INVALID > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37609 > > --- You are receiving this mail because: --- > You reported the bug, or are watching the reporter. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37609
[Bug libstdc++/37391] examples not accessible online (non existing URLs)
--- Comment #3 from bkoz at gcc dot gnu dot org 2008-09-22 20:56 --- Should be fixed now. -- bkoz at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37391
[Bug libstdc++/37391] examples not accessible online (non existing URLs)
--- Comment #4 from bkoz at gcc dot gnu dot org 2008-09-22 20:57 --- Subject: Bug 37391 Author: bkoz Date: Mon Sep 22 20:56:08 2008 New Revision: 140564 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140564 Log: 2008-09-22 Benjamin Kosnik <[EMAIL PROTECTED]> PR libstdc++/37391 * doc/html/ext/pb_ds/*.html: Fix external links. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/doc/html/ext/pb_ds/assoc_container_traits.html trunk/libstdc++-v3/doc/html/ext/pb_ds/assoc_examples.html trunk/libstdc++-v3/doc/html/ext/pb_ds/assoc_regression_tests.html trunk/libstdc++-v3/doc/html/ext/pb_ds/associative_container_tag.html trunk/libstdc++-v3/doc/html/ext/pb_ds/basic_hash_table.html trunk/libstdc++-v3/doc/html/ext/pb_ds/basic_hash_tag.html trunk/libstdc++-v3/doc/html/ext/pb_ds/basic_invalidation_guarantee.html trunk/libstdc++-v3/doc/html/ext/pb_ds/basic_tree.html trunk/libstdc++-v3/doc/html/ext/pb_ds/basic_tree_tag.html trunk/libstdc++-v3/doc/html/ext/pb_ds/binary_heap_tag.html trunk/libstdc++-v3/doc/html/ext/pb_ds/binomial_heap_tag.html trunk/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_max_collision_check_resize_trigger.html trunk/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_table.html trunk/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_tag.html trunk/libstdc++-v3/doc/html/ext/pb_ds/container_base.html trunk/libstdc++-v3/doc/html/ext/pb_ds/container_tag.html trunk/libstdc++-v3/doc/html/ext/pb_ds/counter_lu_policy.html trunk/libstdc++-v3/doc/html/ext/pb_ds/direct_mask_range_hashing.html trunk/libstdc++-v3/doc/html/ext/pb_ds/direct_mod_range_hashing.html trunk/libstdc++-v3/doc/html/ext/pb_ds/exceptions.html trunk/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_table.html trunk/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_tag.html trunk/libstdc++-v3/doc/html/ext/pb_ds/hash_exponential_size_policy.html trunk/libstdc++-v3/doc/html/ext/pb_ds/hash_load_check_resize_trigger.html trunk/libstdc++-v3/doc/html/ext/pb_ds/hash_prime_size_policy.html trunk/libstdc++-v3/doc/html/ext/pb_ds/hash_random_int_erase_mem_usage_test.html trunk/libstdc++-v3/doc/html/ext/pb_ds/hash_random_int_find_find_timing_test.html trunk/libstdc++-v3/doc/html/ext/pb_ds/hash_random_int_subscript_find_timing_test.html trunk/libstdc++-v3/doc/html/ext/pb_ds/hash_random_int_subscript_insert_timing_test.html trunk/libstdc++-v3/doc/html/ext/pb_ds/hash_standard_resize_policy.html trunk/libstdc++-v3/doc/html/ext/pb_ds/hash_text_find_find_timing_test.html trunk/libstdc++-v3/doc/html/ext/pb_ds/hash_zlob_random_int_find_find_timing_test.html trunk/libstdc++-v3/doc/html/ext/pb_ds/insert_error.html trunk/libstdc++-v3/doc/html/ext/pb_ds/join_error.html trunk/libstdc++-v3/doc/html/ext/pb_ds/linear_probe_fn.html trunk/libstdc++-v3/doc/html/ext/pb_ds/list_update.html trunk/libstdc++-v3/doc/html/ext/pb_ds/list_update_tag.html trunk/libstdc++-v3/doc/html/ext/pb_ds/motivation.html trunk/libstdc++-v3/doc/html/ext/pb_ds/move_to_front_lu_policy.html trunk/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_large.html trunk/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_small.html trunk/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large.html trunk/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_small.html trunk/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_large.html trunk/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_small.html trunk/libstdc++-v3/doc/html/ext/pb_ds/null_hash_fn.html trunk/libstdc++-v3/doc/html/ext/pb_ds/null_lu_metadata.html trunk/libstdc++-v3/doc/html/ext/pb_ds/null_mapped_type.html trunk/libstdc++-v3/doc/html/ext/pb_ds/null_probe_fn.html trunk/libstdc++-v3/doc/html/ext/pb_ds/null_tree_node_update.html trunk/libstdc++-v3/doc/html/ext/pb_ds/null_trie_node_update.html trunk/libstdc++-v3/doc/html/ext/pb_ds/ov_tree_tag.html trunk/libstdc++-v3/doc/html/ext/pb_ds/pairing_heap_tag.html trunk/libstdc++-v3/doc/html/ext/pb_ds/pat_trie_tag.html trunk/libstdc++-v3/doc/html/ext/pb_ds/point_invalidation_guarantee.html trunk/libstdc++-v3/doc/html/ext/pb_ds/pq_container_traits.html trunk/libstdc++-v3/doc/html/ext/pb_ds/pq_examples.html trunk/libstdc++-v3/doc/html/ext/pb_ds/pq_regression_tests.html trunk/libstdc++-v3/doc/html/ext/pb_ds/priority_queue.html trunk/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_random_int_push_pop_timing_test.html trunk/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_random_int_push_timing_test.html trunk/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_tag.html trunk/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_join_timing_test.html trunk/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_down_timing_test.html trunk/libstdc++-v3/doc/html/ext/pb_ds/prio
[Bug tree-optimization/37617] [4.4 Regression] ICE on valid code
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-09-22 21:00 --- This worked with: gcc version 4.4.0 20080917 (experimental) [trunk revision 140434] (GCC) But fails with: GNU C (GCC) version 4.4.0 20080922 (experimental) [trunk revision 140563] (i386-apple-darwin8.11.1) The ICE is in bitmap_insert_into_set_1. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org, pinskia at gcc dot gnu ||dot org Component|rtl-optimization|tree-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37617
[Bug tree-optimization/37617] [4.4 Regression] ICE on valid code
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-09-22 21:09 --- Reduced even further and will reproduce with both LP32 and LP64 targets (as long as float is 32bits and double is 64bits): typedef union { char *string; double dval; float fval; } yystype; char *f(void) { yystype tok; tok.dval = 0; return (tok.string); } char *f1(void) { yystype tok; tok.fval = 0; return (tok.string); } --- CUT --- This was most likely introduced with the value numbering of unions. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-09-22 21:09:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37617
[Bug c++/37558] [4.4 regression] rev 140120 changes the accessibility of a friend decl.
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 Version|lto |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37558
[Bug target/37603] [4.3/4.4 Regression] FAIL: gcc.c-torture/compile/pr36141.c at -O1 and above
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37603
[Bug c++/14912] Do not print default template arguments in error messages
--- Comment #40 from pluto at agmk dot net 2008-09-22 21:54 --- (In reply to comment #39) > Created an attachment (id=16380) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16380&action=view) [edit] > Updated fixed > 1). still there is a warning: ../../gcc/cp/error.c: In function 'dump_template_argument_list': ../../gcc/cp/error.c:190: warning: signed and unsigned type in conditional expression 2). seems to work, but... #include #include template < typename T, typename S = std::set< std::string >, int N = 1 > struct X { virtual ~X() = 0; }; void f() { X< float > x; // error here. } $ g++ d2.cpp -c d2.cpp: In function ‘void f()’: d2.cpp:10: error: cannot declare variable ‘x’ to be of abstract type ‘X’ d2.cpp:5: note: because the following virtual functions are pure within ‘X’: d2.cpp:6: note: X::~X() [with T = float, S = std::set >, int N = 1] d2.cpp:6: note could look like 'X::~X() [with T = float]' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
[Bug tree-optimization/37449] [4.4 Regression] calculix gets wrong answer for -O1 -ffast-math
--- Comment #8 from janis at gcc dot gnu dot org 2008-09-22 22:12 --- Created an attachment (id=16382) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16382&action=view) small C testcase that fails with current trunk This version of the small C testcase fails with current mainline with "-O1 -ffast-math" and its behavior changed between r134831 and r134933. -- janis at gcc dot gnu dot org changed: What|Removed |Added Attachment #16365|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37449
[Bug tree-optimization/37449] [4.4 Regression] calculix gets wrong answer for -O1 -ffast-math
--- Comment #9 from pinskia at gcc dot gnu dot org 2008-09-22 22:45 --- The one thing I noticed is that fsel is used in the -ffast-math case and it does a subtraction. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37449
[Bug middle-end/37535] [4.4 Regression] gcc/libgcc2.c:404: internal compiler error: Floating point exception
--- Comment #13 from hjl at gcc dot gnu dot org 2008-09-22 22:46 --- Subject: Bug 37535 Author: hjl Date: Mon Sep 22 22:44:53 2008 New Revision: 140568 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140568 Log: 2008-09-22 Vladimir Makarov <[EMAIL PROTECTED]> PR middle-end/37535 * ira-lives.c (mark_reg_live, mark_reg_dead): New functions. (mark_ref_live, mark_ref_dead): Use them. (def_conflicts_with_inputs_p): Remove. (mark_early_clobbers): New function. (process_bb_node_lives): Call preprocess_constraints and mark_early_clobbers. Modified: branches/ira-merge/gcc/ChangeLog.ira branches/ira-merge/gcc/ira-lives.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37535
[Bug tree-optimization/37449] [4.4 Regression] calculix gets wrong answer for -O1 -ffast-math
--- Comment #10 from janis at gcc dot gnu dot org 2008-09-22 23:08 --- The new testcase passes with "-O1 -funsafe-math-optimizations -fno-tree-dominator-opts". The dom1 dump for "-O1 -funsafe-math-optimizations" twice reports "Invalid sum of incoming frequencies". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37449
[Bug libgcj/18266] GCJ: Using references drops finalizers causing all apps to eventually crash ( SIGSEGV in GC_register_finalizer_inner () )
--- Comment #17 from daney at gcc dot gnu dot org 2008-09-22 23:56 --- For me the testcase always gets a ConcurrentModificationException in w.clear() very soon after starting. This is on GCC trunk 140563 on x86_64-pc-linux-gnu. If I synchronize(w) for accesses to w there is no ConcurrentModificationException, but I have not seen it crash yet either. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18266
[Bug libstdc++/32422] Problem reading floats with exponent marker but no exponent
--- Comment #4 from paolo at gcc dot gnu dot org 2008-09-23 00:47 --- Subject: Bug 32422 Author: paolo Date: Tue Sep 23 00:47:02 2008 New Revision: 140574 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140574 Log: 2008-09-23 Paolo Carlini <[EMAIL PROTECTED]> PR libstdc++/32422, DR 23 [Ready in R60] * config/locale/gnu/c_locale.cc (__convert_to_v(const char*, float&, ios_base::iostate&, const __c_locale&), __convert_to_v(const char*, double&, ios_base::iostate&, const __c_locale&), __convert_to_v(const char*, long double&, ios_base::iostate&, const __c_locale&)): Implement DR 23 and deal correctly with broken exponents. * config/locale/generic/c_locale.cc (__convert_to_v(const char*, float&, ios_base::iostate&, const __c_locale&), __convert_to_v(const char*, double&, ios_base::iostate&, const __c_locale&), __convert_to_v(const char*, long double&, ios_base::iostate&, const __c_locale&)): Likewise. * include/bits/locale_facets.tcc (num_get<>::_M_extract_int(_InIter, _InIter, ios_base&, ios_base::iostate&, _ValueT&)): Likewise. (num_get<>::_M_extract_float(_InIter, _InIter, ios_base&, ios_base::iostate&, string&): Change grouping check to set instead of OR failbit; do not check for eofbit here... (num_get<>::do_get(iter_type, iter_type, ios_base&, ios_base::iostate&, float&), num_get<>::do_get(iter_type, iter_type, ios_base&, ios_base::iostate&, double&), num_get<>::do_get(iter_type, iter_type, ios_base&, ios_base::iostate&, long double&), num_get<>::__do_get(iter_type, iter_type, ios_base&, ios_base::iostate&, double&)): ... do it here instead. (num_get<>::do_get(iter_type, iter_type, ios_base&, ios_base::iostate&, bool&)): Implement DR 23. (num_get<>::do_get(iter_type, iter_type, ios_base&, ios_base::iostate&, void*&)): Adjust. * doc/xml/manual/intro.xml: Add and entry for DR 23. * testsuite/27_io/basic_istream/extractors_arithmetic/wchar_t/10.cc: Adjust. * testsuite/27_io/basic_istream/extractors_arithmetic/char/10.cc: Likewise. * testsuite/22_locale/num_get/get/wchar_t/22131.cc: Likewise. * testsuite/22_locale/num_get/get/wchar_t/10.cc: Likewise. * testsuite/22_locale/num_get/get/wchar_t/12.cc: Likewise. * testsuite/22_locale/num_get/get/wchar_t/15.cc: Likewise. * testsuite/22_locale/num_get/get/wchar_t/16.cc: Likewise. * testsuite/22_locale/num_get/get/char/22131.cc: Likewise. * testsuite/22_locale/num_get/get/char/10.cc: Likewise. * testsuite/22_locale/num_get/get/char/12.cc: Likewise. * testsuite/22_locale/num_get/get/char/15.cc: Likewise. * testsuite/22_locale/num_get/get/char/16.cc: Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/config/locale/generic/c_locale.cc trunk/libstdc++-v3/config/locale/gnu/c_locale.cc trunk/libstdc++-v3/doc/xml/manual/intro.xml trunk/libstdc++-v3/include/bits/locale_facets.tcc trunk/libstdc++-v3/testsuite/22_locale/num_get/get/char/10.cc trunk/libstdc++-v3/testsuite/22_locale/num_get/get/char/12.cc trunk/libstdc++-v3/testsuite/22_locale/num_get/get/char/15.cc trunk/libstdc++-v3/testsuite/22_locale/num_get/get/char/16.cc trunk/libstdc++-v3/testsuite/22_locale/num_get/get/char/22131.cc trunk/libstdc++-v3/testsuite/22_locale/num_get/get/wchar_t/10.cc trunk/libstdc++-v3/testsuite/22_locale/num_get/get/wchar_t/12.cc trunk/libstdc++-v3/testsuite/22_locale/num_get/get/wchar_t/15.cc trunk/libstdc++-v3/testsuite/22_locale/num_get/get/wchar_t/16.cc trunk/libstdc++-v3/testsuite/22_locale/num_get/get/wchar_t/22131.cc trunk/libstdc++-v3/testsuite/27_io/basic_istream/extractors_arithmetic/char/10.cc trunk/libstdc++-v3/testsuite/27_io/basic_istream/extractors_arithmetic/wchar_t/10.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32422
[Bug libstdc++/32422] Problem reading floats with exponent marker but no exponent
--- Comment #5 from paolo dot carlini at oracle dot com 2008-09-23 00:49 --- Fixed for 4.4.0. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32422
[Bug fortran/37498] [4.4 Regression] Incorrect array value returned - 4.3 ABI Broken
--- Comment #16 from jvdelisle at gcc dot gnu dot org 2008-09-23 03:53 --- Subject: Bug 37498 Author: jvdelisle Date: Tue Sep 23 03:52:19 2008 New Revision: 140576 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140576 Log: 2008-09-22 Jerry DeLisle <[EMAIL PROTECTED] PR fortran/37498 * trans-io.c (gfc_build_io_library_fndecls): Bump pad size. (build_dt): Set mask bit for IOPARM_dt_f2003. * ioparm.def: Add IOPARM_dt_f2003. 2008-09-22 Jerry DeLisle <[EMAIL PROTECTED] PR libfortran/37498 * file_pos (st_endfile): Clear memory only for libfortran 4.3 private area. * list_read.c (eat_separator): Only access F2003 I/O parameters if IOPARM_DT_HAS_F2003 bit is set. (parse_real): Ditto. (read_real): Ditto. * read.c (read_a): Likewise. (read_a_char4): Likewise though not strictly necessary. (read_f): Likewise. * io.h (unit_sign_s): New enumerator to allow duplication of st_parameter structures. (IOPARM_DT_HAS_F2003): New mask bit. (st_parameter_43): New structure copied from 4.3 version of st_paramater_dt private section. (st_parameter_44): New structure with F2003 items added. (st_parameter_dt): Modified to create union of new and old structures to allow correct memory setting for 4.3 ABI compatibility. Bumped the pad size. * transfer.c (read_sf): Do not use F2003 I/O memory areas unless IOPARM_DT_HAS_F2003 bit has been set. (read_block_form): Ditto. (formatted_transfer_scalar): Ditto. (data_transfer_init): Ditto and add comment, fix formatting. * write.c (write_default_char4): Likewise though not strictly necessary. (write_utf8_char4): Ditto. (write_character): Ditto. (write_real_g0): Ditto. (list_formatted_write_scalar): Ditto. (nml_write_obj): Ditto. (namelist_write): Ditto. * write_float.def (calculate_sign): Eliminate warning by including all cases in switch. (output_float): Output only decimal point of F2003 flag is not set. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/ioparm.def trunk/gcc/fortran/trans-io.c trunk/libgfortran/ChangeLog trunk/libgfortran/io/file_pos.c trunk/libgfortran/io/io.h trunk/libgfortran/io/list_read.c trunk/libgfortran/io/read.c trunk/libgfortran/io/transfer.c trunk/libgfortran/io/write.c trunk/libgfortran/io/write_float.def -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37498
[Bug middle-end/37587] ICE when use graphite
--- Comment #1 from linuxl4 at sohu dot com 2008-09-23 05:06 --- can anybody comfirm it? I built gcc ppl polylib cloog mpfr gmp with CFLAGS="-pipe -O3 -ftree-vectorize -march=pentium4 -mfpmath=sse" glibc and binutils are of my gentoo 2008.0 hosts' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37587
[Bug fortran/37498] [4.4 Regression] Incorrect array value returned - 4.3 ABI Broken
--- Comment #17 from jvdelisle at gcc dot gnu dot org 2008-09-23 06:26 --- I was doing some additional testing after the above patch and see that it breaks other things w.r.t 4.3 ABI. An example is namelist_14.f90 which fails with a 4.3 executable and 4.4 library. I am keeping this PR open while I sort this issue out further. 4.3 kept delim_status in unit_flags instead of in the st_parameter_dt of 4.4 Stay tuned. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37498
[Bug fortran/36374] nested module inclusion fails
--- Comment #6 from pault at gcc dot gnu dot org 2008-09-23 06:27 --- Subject: Bug 36374 Author: pault Date: Tue Sep 23 06:25:39 2008 New Revision: 140578 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140578 Log: 2008-09-23 Paul Thomas <[EMAIL PROTECTED]> PR fortran/37274 PR fortran/36374 * module.c (check_for_ambiguous): New function to test loaded symbol for ambiguity with fixup symbol. (read_module): Call check_for_ambiguous. (write_symtree): Do not write the symtree for symbols coming from an interface body. PR fortran/36374 * resolve.c (count_specific_procs ): New function to count the number of specific procedures with the same name as the generic and emit appropriate errors for and actual argument reference. (resolve_assumed_size_actual): Add new argument no_formal_args. Correct logic around passing generic procedures as arguments. Call count_specific_procs from two locations. (resolve_function): Evaluate and pass no_formal_args. (resolve call): The same and clean up a bit by using csym more widely. PR fortran/36454 * symbol.c (gfc_add_access): Access can be updated if use associated and not private. 2008-09-23 Paul Thomas <[EMAIL PROTECTED]> PR fortran/37274 * gfortran.dg/used_types_22.f90: New test. * gfortran.dg/used_types_23.f90: New test. PR fortran/36374 * gfortran.dg/generic_17.f90: New test. * gfortran.dg/ambiguous_specific_2.f90: New test. * gfortran.dg/generic_actual_arg.f90: Add test for case that is not ambiguous. PR fortran/36454 * gfortran.dg/access_spec_3.f90: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/access_spec_3.f90 branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/ambiguous_specific_2.f90 branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/generic_17.f90 branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/used_types_22.f90 branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/used_types_23.f90 Modified: branches/gcc-4_3-branch/gcc/fortran/ChangeLog branches/gcc-4_3-branch/gcc/fortran/module.c branches/gcc-4_3-branch/gcc/fortran/resolve.c branches/gcc-4_3-branch/gcc/fortran/symbol.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/generic_actual_arg.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36374
[Bug fortran/36454] too cautionous alias checking with renamed variables/types from modules (Error: ACCESS specification already specified)
--- Comment #6 from pault at gcc dot gnu dot org 2008-09-23 06:27 --- Subject: Bug 36454 Author: pault Date: Tue Sep 23 06:25:39 2008 New Revision: 140578 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140578 Log: 2008-09-23 Paul Thomas <[EMAIL PROTECTED]> PR fortran/37274 PR fortran/36374 * module.c (check_for_ambiguous): New function to test loaded symbol for ambiguity with fixup symbol. (read_module): Call check_for_ambiguous. (write_symtree): Do not write the symtree for symbols coming from an interface body. PR fortran/36374 * resolve.c (count_specific_procs ): New function to count the number of specific procedures with the same name as the generic and emit appropriate errors for and actual argument reference. (resolve_assumed_size_actual): Add new argument no_formal_args. Correct logic around passing generic procedures as arguments. Call count_specific_procs from two locations. (resolve_function): Evaluate and pass no_formal_args. (resolve call): The same and clean up a bit by using csym more widely. PR fortran/36454 * symbol.c (gfc_add_access): Access can be updated if use associated and not private. 2008-09-23 Paul Thomas <[EMAIL PROTECTED]> PR fortran/37274 * gfortran.dg/used_types_22.f90: New test. * gfortran.dg/used_types_23.f90: New test. PR fortran/36374 * gfortran.dg/generic_17.f90: New test. * gfortran.dg/ambiguous_specific_2.f90: New test. * gfortran.dg/generic_actual_arg.f90: Add test for case that is not ambiguous. PR fortran/36454 * gfortran.dg/access_spec_3.f90: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/access_spec_3.f90 branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/ambiguous_specific_2.f90 branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/generic_17.f90 branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/used_types_22.f90 branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/used_types_23.f90 Modified: branches/gcc-4_3-branch/gcc/fortran/ChangeLog branches/gcc-4_3-branch/gcc/fortran/module.c branches/gcc-4_3-branch/gcc/fortran/resolve.c branches/gcc-4_3-branch/gcc/fortran/symbol.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/generic_actual_arg.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36454
[Bug fortran/37274] [Regression on 4.3?] error: type name is ambiguous.
--- Comment #20 from pault at gcc dot gnu dot org 2008-09-23 06:27 --- Subject: Bug 37274 Author: pault Date: Tue Sep 23 06:25:39 2008 New Revision: 140578 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140578 Log: 2008-09-23 Paul Thomas <[EMAIL PROTECTED]> PR fortran/37274 PR fortran/36374 * module.c (check_for_ambiguous): New function to test loaded symbol for ambiguity with fixup symbol. (read_module): Call check_for_ambiguous. (write_symtree): Do not write the symtree for symbols coming from an interface body. PR fortran/36374 * resolve.c (count_specific_procs ): New function to count the number of specific procedures with the same name as the generic and emit appropriate errors for and actual argument reference. (resolve_assumed_size_actual): Add new argument no_formal_args. Correct logic around passing generic procedures as arguments. Call count_specific_procs from two locations. (resolve_function): Evaluate and pass no_formal_args. (resolve call): The same and clean up a bit by using csym more widely. PR fortran/36454 * symbol.c (gfc_add_access): Access can be updated if use associated and not private. 2008-09-23 Paul Thomas <[EMAIL PROTECTED]> PR fortran/37274 * gfortran.dg/used_types_22.f90: New test. * gfortran.dg/used_types_23.f90: New test. PR fortran/36374 * gfortran.dg/generic_17.f90: New test. * gfortran.dg/ambiguous_specific_2.f90: New test. * gfortran.dg/generic_actual_arg.f90: Add test for case that is not ambiguous. PR fortran/36454 * gfortran.dg/access_spec_3.f90: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/access_spec_3.f90 branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/ambiguous_specific_2.f90 branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/generic_17.f90 branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/used_types_22.f90 branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/used_types_23.f90 Modified: branches/gcc-4_3-branch/gcc/fortran/ChangeLog branches/gcc-4_3-branch/gcc/fortran/module.c branches/gcc-4_3-branch/gcc/fortran/resolve.c branches/gcc-4_3-branch/gcc/fortran/symbol.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/generic_actual_arg.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37274
[Bug fortran/37274] [Regression on 4.3?] error: type name is ambiguous.
--- Comment #21 from pault at gcc dot gnu dot org 2008-09-23 06:28 --- Fixed on trunk and 4.3. Thanks for the report Paul PS The original problem was not present in 4.3 but the reduced version was. -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37274
[Bug fortran/36454] too cautionous alias checking with renamed variables/types from modules (Error: ACCESS specification already specified)
--- Comment #7 from pault at gcc dot gnu dot org 2008-09-23 06:28 --- Fixed on trunk and 4.3. Thanks for the report Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36454
[Bug fortran/36374] nested module inclusion fails
--- Comment #7 from pault at gcc dot gnu dot org 2008-09-23 06:29 --- Fixed on trunk and 4.3. Thanks for the report Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36374