[Bug libfortran/30533] minval, maxval missing for kind=1 and kind=2
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-02-07 08:09 --- (In reply to comment #3) I'm not yet sure how to deal with matmul, wether by converting its arguments or by creating kind=1 and kind=2 versions. I think converting wil have a huge performance hit, so we'd better havec kind=1 and kind=2 versions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30533
[Bug fortran/30420] [4.1 and 4.2] IBCLR() fails to properly handle clearing the sign bit.
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-02-07 08:11 --- Brooks, maybe it's time to backport them to 4.2? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30420
[Bug fortran/30389] [4.2, 4.1 only] ACHAR() intrinsic gives erroneous errors in constant-folding.
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-02-07 08:14 --- Time for a 4.2 backport? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30389
[Bug libfortran/30498] Support traceback (backtrace) on errors
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-02-07 09:08 --- Created an attachment (id=13019) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13019action=view) Patch implementing the -fbacktrace option Here's an updated version of the patch I submitted some time ago. I don't have enough time to submit it, but if someone wants to take it and do whatever you want to do with it, go ahead! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30498
[Bug libfortran/30617] recursive I/O hangs under OSX 10.3
--- Comment #12 from brooks at gcc dot gnu dot org 2007-02-07 09:10 --- (In reply to comment #7) If I read the F2003 standrad correctly, then your program conforms to F2003. You may want to change this to an enhancement request. This is incorrect -- the code does not conform to F2003 either. Section 9.11, paragraph 3, says that a recursive I/O statement -- that is, one that occurs while another is in progress, such as the print *, 'test' in this code -- may not identify an external unit, unless it is a child I/O statement. Section 9.5.3.7.1, paragarph 2, defines a child I/O statement as one that's occuring within a user-defined derived-type I/O function -- which is definitely not applicable here. Therefore, I believe that this bug should be closed as INVALID, but given the amount of commentary (and the fact that hanging is an unfortunate response even to invalid code), I'll let someone else make that call. -- brooks at gcc dot gnu dot org changed: What|Removed |Added CC||brooks at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
[Bug libfortran/30617] recursive I/O hangs under OSX 10.3
--- Comment #13 from dominiq at lps dot ens dot fr 2007-02-07 09:24 --- Subject: Re: recursive I/O hangs under OSX 10.3 Section 9.5.3.7.1, paragarph 2, defines a child I/O statement as one that's occuring within a user-defined derived-type I/O function -- which is definitely not applicable here. Could you please translate this in plain English? I have looked at the standard draft and have been unable to figure out a single conforming example, not speaking about a single useful one. If someone can give me such example(s), I am ready to test it (them) on both OSX and Linux. From the above quotation, am I correct to infer that replacing * by 6 will not make the code standard conforming? TIA -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
[Bug libfortran/30498] Support traceback (backtrace) on errors
--- Comment #3 from burnus at gcc dot gnu dot org 2007-02-07 09:47 --- Patch implementing the -fbacktrace option I think one should add also some userhandler signal(SIGSEGV, my_segv_handler); which calls show_backtrace and exits/coredumps then. That way we calso get a backtrace for signalling arithmetic errors or for wrong pointer accesses etc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30498
[Bug c++/30716] recursive templates compilation fault
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-02-07 09:55 --- note the size of class cls grows exponentially with its template parameter. -- 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=30716
[Bug fortran/30723] Freeing memory doesn't need to call a library function
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-02-07 09:58 --- Confirmed. Note we already NULLify the pointer in the caller for _gfortran_deallocate (but I missed to fix the comment before that function as well). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30723
[Bug testsuite/28870] [4.2/4.3 Regression] configuring, over-riding timeout values in testsuite
--- Comment #10 from hp at gcc dot gnu dot org 2007-02-07 10:09 --- Subject: Bug 28870 Author: hp Date: Wed Feb 7 10:09:41 2007 New Revision: 121684 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121684 Log: PR testsuite/28870 * testsuite/27_io/basic_stringbuf/overflow/char/1.cc: Use only 1 iterations for simulator targets. * testsuite/ext/pb_ds/regression/tree_data_map_rand.cc: Use only 5 iterations for simulator targets. * testsuite/ext/pb_ds/regression/tree_no_data_map_rand.cc: Ditto. * testsuite/ext/pb_ds/regression/trie_data_map_rand.cc: Ditto. * testsuite/ext/pb_ds/regression/trie_no_data_map_rand.cc: Ditto. * testsuite/ext/pb_ds/regression/hash_no_data_map_rand.cc: Ditto. * testsuite/ext/pb_ds/regression/hash_data_map_rand.cc: Ditto. * testsuite/ext/pb_ds/regression/priority_queue_rand.cc: Ditto. * testsuite/23_containers/set/modifiers/16728.cc: Use only 10 iterations for simulator targets. Modified: trunk/libstdc++-v3/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28870
[Bug testsuite/28870] [4.2/4.3 Regression] configuring, over-riding timeout values in testsuite
--- Comment #11 from hp at gcc dot gnu dot org 2007-02-07 10:12 --- Subject: Bug 28870 Author: hp Date: Wed Feb 7 10:12:21 2007 New Revision: 121686 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121686 Log: PR testsuite/28870 * testsuite/27_io/basic_stringbuf/overflow/char/1.cc: Use only 1 iterations for simulator targets. * testsuite/ext/pb_ds/regression/tree_data_map_rand.cc: Use only 5 iterations for simulator targets. * testsuite/ext/pb_ds/regression/tree_no_data_map_rand.cc: Ditto. * testsuite/ext/pb_ds/regression/trie_data_map_rand.cc: Ditto. * testsuite/ext/pb_ds/regression/trie_no_data_map_rand.cc: Ditto. * testsuite/ext/pb_ds/regression/hash_no_data_map_rand.cc: Ditto. * testsuite/ext/pb_ds/regression/hash_data_map_rand.cc: Ditto. * testsuite/ext/pb_ds/regression/priority_queue_rand.cc: Ditto. * testsuite/23_containers/set/modifiers/16728.cc: Use only 10 iterations for simulator targets. Modified: branches/gcc-4_2-branch/libstdc++-v3/ChangeLog branches/gcc-4_2-branch/libstdc++-v3/testsuite/23_containers/set/modifiers/16728.cc branches/gcc-4_2-branch/libstdc++-v3/testsuite/27_io/basic_stringbuf/overflow/char/1.cc branches/gcc-4_2-branch/libstdc++-v3/testsuite/ext/pb_ds/regression/hash_data_map_rand.cc branches/gcc-4_2-branch/libstdc++-v3/testsuite/ext/pb_ds/regression/hash_no_data_map_rand.cc branches/gcc-4_2-branch/libstdc++-v3/testsuite/ext/pb_ds/regression/priority_queue_rand.cc branches/gcc-4_2-branch/libstdc++-v3/testsuite/ext/pb_ds/regression/tree_data_map_rand.cc branches/gcc-4_2-branch/libstdc++-v3/testsuite/ext/pb_ds/regression/tree_no_data_map_rand.cc branches/gcc-4_2-branch/libstdc++-v3/testsuite/ext/pb_ds/regression/trie_data_map_rand.cc branches/gcc-4_2-branch/libstdc++-v3/testsuite/ext/pb_ds/regression/trie_no_data_map_rand.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28870
[Bug testsuite/28870] [4.2/4.3 Regression] configuring, over-riding timeout values in testsuite
--- Comment #12 from hp at gcc dot gnu dot org 2007-02-07 10:16 --- The checked-in changes marked with this PR don't solve the timeout issue by far, but hint of a way to solve timeout problems for specific tests, for specific (classes of) systems, in another way than changing the default timeout. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28870
[Bug c++/30703] ICE Segmentation fault on using OpenMP
--- Comment #3 from jakub at gcc dot gnu dot org 2007-02-07 12:16 --- Subject: Bug 30703 Author: jakub Date: Wed Feb 7 12:16:22 2007 New Revision: 121688 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121688 Log: PR c++/30703 * gimplify.c (gimplify_scan_omp_clauses): Remove special casing of INDIRECT_REF RESULT_DECL. * cp-gimplify.c (cp_genericize_r): Don't dereference invisiref parameters and result decls in omp clauses. (cxx_omp_privatize_by_reference): Pass also invisiref PARM_DECLs by reference. * testsuite/libgomp.c++/pr30703.C: New test. Added: trunk/libgomp/testsuite/libgomp.c++/pr30703.C Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-gimplify.c trunk/gcc/gimplify.c trunk/libgomp/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30703
[Bug libgomp/28468] OpenMP-parallelized program crashes when OMP_NUM_THREADS 1
--- Comment #4 from jakub at gcc dot gnu dot org 2007-02-07 13:35 ---
Subject: Bug 28468
Author: jakub
Date: Wed Feb 7 13:35:17 2007
New Revision: 121689
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121689
Log:
2007-02-07 Bruno Haible [EMAIL PROTECTED]
config/
PR libgomp/28468
* config/tls.m4 (GCC_CHECK_TLS): Also check whether the libc supports
TLS via __thread.
2007-02-07 Jakub Jelinek [EMAIL PROTECTED]
{libgomp,libstdc++-v3,libmudflap,libjava}/
PR libgomp/28468
* configure: Regenerate.
Modified:
trunk/config/ChangeLog
trunk/config/tls.m4
trunk/libgomp/ChangeLog
trunk/libgomp/configure
trunk/libjava/ChangeLog
trunk/libjava/configure
trunk/libmudflap/ChangeLog
trunk/libmudflap/configure
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/configure
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28468
[Bug c++/30703] ICE Segmentation fault on using OpenMP
--- Comment #4 from jakub at gcc dot gnu dot org 2007-02-07 13:37 --- Subject: Bug 30703 Author: jakub Date: Wed Feb 7 13:37:29 2007 New Revision: 121690 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121690 Log: PR c++/30703 * gimplify.c (gimplify_scan_omp_clauses): Remove special casing of INDIRECT_REF RESULT_DECL. * cp-gimplify.c (cp_genericize_r): Don't dereference invisiref parameters and result decls in omp clauses. (cxx_omp_privatize_by_reference): Pass also invisiref PARM_DECLs by reference. * testsuite/libgomp.c++/pr30703.C: New test. Added: branches/gcc-4_2-branch/libgomp/testsuite/libgomp.c++/pr30703.C Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/cp/ChangeLog branches/gcc-4_2-branch/gcc/cp/cp-gimplify.c branches/gcc-4_2-branch/gcc/gimplify.c branches/gcc-4_2-branch/libgomp/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30703
[Bug libgomp/28468] OpenMP-parallelized program crashes when OMP_NUM_THREADS 1
--- Comment #5 from jakub at gcc dot gnu dot org 2007-02-07 13:39 --- Approved offline by Alex Oliva, committed so far on the trunk. Will backport to 4.2 branch after a week or so on the trunk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28468
[Bug libgomp/28296] [4.2/4.3 Regression] libgomp fails to configure on Tru64 UNIX
--- Comment #10 from jakub at gcc dot gnu dot org 2007-02-07 13:42 --- Should be fixed on the trunk and 4.2 branch now, thanks Roger. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28296
[Bug c/30727] New: Argument list to long when compiling gcc
Got the following error message when compiling gcc itself: --- TARGET_CPU_DEFAULT= \ HEADERS=auto-host.h ansidecl.h config/i386/xm-mingw32.h DEFINES= \ /bin/sh ../../gcc-4.2-20070131/gcc/mkconfig.sh config.h TARGET_CPU_DEFAULT= \ HEADERS=options.h config/i386/i386.h config/i386/unix.h config/i386/bsd.h config/i386/gas.h config/dbxcoff.h config/i386/cygming.h config/i386/mingw32.h defaults.h DEFINES= \ /bin/sh ../../gcc-4.2-20070131/gcc/mkconfig.sh tm.h gawk -f ../../gcc-4.2-20070131/gcc/opt-gather.awk ../../gcc-4.2-20070131/gcc/ada/lang.opt ../../gcc-4.2-20070131/gcc/fortran/lang.opt ../../gcc-4.2-20070131/gcc/java/lang.opt ../../gcc-4.2-20070131/gcc/treelang/lang.opt ../../gcc-4.2-20070131/gcc/c.opt ../../gcc-4.2-20070131/gcc/common.opt ../../gcc-4.2-20070131/gcc/config/i386/i386.opt ../../gcc-4.2-20070131/gcc/config/i386/cygming.opt tmp-optionlist /bin/sh ../../gcc-4.2-20070131/gcc/../move-if-change tmp-optionlist optionlist echo timestamp s-options gawk -f ../../gcc-4.2-20070131/gcc/opt-functions.awk -f ../../gcc-4.2-20070131/gcc/opth-gen.awk \ optionlist tmp-options.h /bin/sh ../../gcc-4.2-20070131/gcc/../move-if-change tmp-options.h options.h echo timestamp s-options-h TARGET_CPU_DEFAULT= \ HEADERS=auto-host.h ansidecl.h config/i386/xm-mingw32.h DEFINES= \ /bin/sh ../../gcc-4.2-20070131/gcc/mkconfig.sh bconfig.h gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../gcc-4.2-20070131/gcc -I../../gcc-4.2-20070131/gcc/build -I../../gcc-4.2-20070131/gcc/../include -I./../intl -I../../gcc-4.2-20070131/gcc/../libcpp/include -I../../gcc-4.2-20070131/gcc/../libdecnumber -I../libdecnumber-o build/genmodes.o ../../gcc-4.2-20070131/gcc/genmodes.c make[4]: execvp: gcc: Argument list too long make[4]: *** [build/genmodes.o] Fehler 127 make[4]: Leaving directory `/work/gnuada/rpm/BUILD/gnat-gcc/pentium4-pc-mingw32msv/gcc' make[3]: *** [all-stage1-gcc] Fehler 2 make[3]: Leaving directory `/work/gnuada/rpm/BUILD/gnat-gcc/pentium4-pc-mingw32msv' make[2]: *** [stage1-bubble] Fehler 2 make[2]: Leaving directory `/work/gnuada/rpm/BUILD/gnat-gcc/pentium4-pc-mingw32msv' make[1]: *** [all] Fehler 2 make[1]: Leaving directory `/work/gnuada/rpm/BUILD/gnat-gcc/pentium4-pc-mingw32msv' Fehler: Bad exit status from /var/tmp/rpm-tmp.26737 (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.26737 (%build) - Martin -- Summary: Argument list to long when compiling gcc Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: krischik at users dot sourceforge dot net GCC build triplet: pentium4-pc-mingw32msv GCC host triplet: pentium4-pc-mingw32msv GCC target triplet: pentium4-pc-mingw32msv http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30727
[Bug c/30719] gcc should probably warn if users compile without -O
--- Comment #4 from tvb at gnome dot org 2007-02-07 14:59 --- (In reply to comment #3) What is there to warn about? If you do -Winitialize without -O, you get a warning so ... I just tried the explicit -Wuninitialized, very good, and I noticed at least its documented in the man pages. But who ever uses -Wuninitialized ? People expect to get -Wuninitialized with -Wall, everyone uses -Wall, it would be great if any expectable warnings are disabled you should get the same warning message. So to recap, it would be much more usefull if I got this message when compiling with -Wall but no -O : cc1: warning: -Wuninitialized is not supported without -O This would make sence because to specify -Wall, *is* to explicitly mention -Wuninitialized. -- tvb at gnome dot org changed: What|Removed |Added CC||tvb at gnome dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30719
[Bug c/30719] gcc should probably warn if users compile without -O
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-02-07 16:39 --- To me a warning should not be emitted while using -Wall -O0 as it will break all the programs which use -Werror which is a lot of them. Also this is already documented, if people don't read documentation, why would they read warnings? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30719
[Bug libstdc++/17012] [DR 526] std::list's function, remove, looks like it is reading memory that has been freed.
--- Comment #12 from hhinnant at apple dot com 2007-02-07 16:46 ---
At the ad-hoc LWG meeting in Batavia, Jan 22-24, 2007, the LWG decided that
self referencing code in list::remove must work. Here is a preview of the
issue which is currently set to become official at the Spring '07 meeting:
http://home.twcny.rr.com/hinnant/cpp_extensions/issues_preview/lwg-active.html#526
Here is a patch to mainline to make it work. I believe the approach taken by
this patch is superior to copying the value as it currently looks like a future
standard will not require that the value_type be copyable. Additionally the
cost of copying the value_type can be arbitrarily large.
If we have a utility similar to boost::address_of, that might be better than
using operator to get the address of the value_type (to accommodate types
which overload operator).
Index: libstdc++-v3/include/bits/list.tcc
===
--- libstdc++-v3/include/bits/list.tcc (revision 121691)
+++ libstdc++-v3/include/bits/list.tcc (working copy)
@@ -176,14 +176,22 @@
{
iterator __first = begin();
iterator __last = end();
+ iterator __extra = __last;
while (__first != __last)
{
iterator __next = __first;
++__next;
if (*__first == __value)
- _M_erase(__first);
+ {
+ if (__value != *__first)
+ _M_erase(__first);
+ else
+ __extra = __first;
+ }
__first = __next;
}
+ if (__extra != __last)
+_M_erase(__extra);
}
templatetypename _Tp, typename _Alloc
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17012
[Bug c/30719] gcc should probably warn if users compile without -O
--- Comment #6 from tvb at gnome dot org 2007-02-07 16:48 --- (In reply to comment #5) To me a warning should not be emitted while using -Wall -O0 as it will break all the programs which use -Werror which is a lot of them. Also this is already documented, if people don't read documentation, why would they read warnings? If they are using -Werror and insist on using -O0, then they can go ahead and specify what warnings they want to ignore, they asked for it by specifying -Werror. If documentation were enough, I'm sure there wouldnt be a warning for -Wuninitialized -O0, but there is, for obvious reasons - people generally use a build system which typically uses -Wall by default and generally people dont interface with gcc directly. - Most of the time people need to be warned - People compiling with -Werror have a closer relationship to the compiler and are better situated to deal with the warning that should be appearing for -Wall -O0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30719
[Bug libstdc++/17012] [DR 526] std::list's function, remove, looks like it is reading memory that has been freed.
--- Comment #13 from hhinnant at apple dot com 2007-02-07 16:59 ---
(In reply to comment #12)
If we have a utility similar to boost::address_of, that might be better than
using operator to get the address of the value_type (to accommodate types
which overload operator).
Oops, I forgot about allocator::address and:
http://home.twcny.rr.com/hinnant/cpp_extensions/issues_preview/lwg-active.html#580
New patch uses allocator::address:
Index: libstdc++-v3/include/bits/list.tcc
===
--- libstdc++-v3/include/bits/list.tcc (revision 121691)
+++ libstdc++-v3/include/bits/list.tcc (working copy)
@@ -176,14 +176,23 @@
{
iterator __first = begin();
iterator __last = end();
+ iterator __extra = __last;
+ allocator_type __a = get_allocator();
while (__first != __last)
{
iterator __next = __first;
++__next;
if (*__first == __value)
- _M_erase(__first);
+ {
+ if (__a.address(__value) != __a.address(*__first))
+ _M_erase(__first);
+ else
+ __extra = __first;
+ }
__first = __next;
}
+ if (__extra != __last)
+_M_erase(__extra);
}
templatetypename _Tp, typename _Alloc
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17012
[Bug libstdc++/17012] [DR 526] std::list's function, remove, looks like it is reading memory that has been freed.
--- Comment #14 from chris at bubblescope dot net 2007-02-07 17:12 --- Unless __value comes from the list, does the standard require __a.address(__value) to work? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17012
[Bug libstdc++/17012] [DR 526] std::list's function, remove, looks like it is reading memory that has been freed.
--- Comment #15 from hhinnant at apple dot com 2007-02-07 17:22 --- (In reply to comment #14) Unless __value comes from the list, does the standard require __a.address(__value) to work? That's a good question Chris. The way I read the current draft, I believe the answer is no. This looks like another defect report to me. In the definition of r and s in [allocator.requirements] I see no reason to have the clause obtained by the expression *p. But I'll open a DR (635) and let the LWG decide. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17012
[Bug driver/30728] New: Building a 32-bit compiler on a 64-bit system should pass --32 flag to the assembler
If you configure to build a 32-bit compiler on a 64-bit Linux system with:
CC='gcc -m32' /src/trunk/configure --{target,host,build}=i686-pc-linux-gnu ...
the compiler fails because it defaults to 32-bit code but the standard
assembler is 64 bit, and it fails in building libgcc. If you are building in
such an environment, the compiler should be modified to pass --32 to the
assembler.
Note, there is the work around of putting a 32-bit assembler in the --prefix
directory so that it builds correctly, but it would be nice to have it fixed.
--
Summary: Building a 32-bit compiler on a 64-bit system should
pass --32 flag to the assembler
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: michael dot meissner at amd dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30728
[Bug fortran/30720] runtime: check for empty array slices before allocating a negative amount of memory
--- Comment #5 from tkoenig at gcc dot gnu dot org 2007-02-07 17:52 --- Hi FX, do you remember why always performing that check (ie, turn function to be always true) is not the right thing to do? When working on this, I hit numerous testsuite regressions when always checking for negative extents, and I couldn't find out why. So I only fixed the code path for the particular PR. If you find something that works without that argument (which is a bit of a kudge), so much the better. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30720
[Bug libfortran/30694] minval/maxval with +/-Inf
--- Comment #8 from tkoenig at gcc dot gnu dot org 2007-02-07 17:54 --- The status of the other patch is: Waiting for review. http://gcc.gnu.org/ml/gcc-patches/2007-02/msg00260.html I can't do any regression-testing right now, because PR 30678 :-( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30694
[Bug target/30728] Building a 32-bit compiler on a 64-bit system should pass --32 flag to the assembler
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-07 18:05 --- It might be better to do something like powerpc64-linux-gnu does and define a --with-cpu=default32 which compiles a 64bit capable compiler but defaults to 32bits. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|driver |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30728
[Bug fortran/30720] runtime: check for empty array slices before allocating a negative amount of memory
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-02-07 19:10 --- (In reply to comment #5) If you find something that works without that argument (which is a bit of a kudge), so much the better. The patch I attached removes this argument, and it gives no regression on the testsuite. I also simplified the conditional expression by using a COND_EXPR instead of generating different blocks. Would you mind looking at it to see if you spot anything odd? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30720
[Bug fortran/30723] Freeing memory doesn't need to call a library function
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-02-07 19:22 --- Created an attachment (id=13020) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13020action=view) Patch to not generate calls to internal_free any more -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30723
[Bug libfortran/30617] recursive I/O hangs under OSX
--- Comment #14 from dominiq at lps dot ens dot fr 2007-02-07 19:55 --- The test is known to fail on OSX 10.3 (gcc 4.3.0 20070202) and 10.4 (PPC with gcc 4.2.0 20070124 and MacIntel gcc unknown). When I have filled the PR I have forgotten to say that the same bug was present in http://gcc.gnu.org/viewcvs/trunk/gcc/testsuite/gfortran.dg/actual_array_interface_1.f90 see http://gcc.gnu.org/ml/fortran/2006-11/msg00394.html and following mails in the thread for details. Note that the slightly modified code: external fun real fun character(10) :: string real a a = fun() print *, a write(string,*) fun() print *, string end real function fun() print *, 'test' fun = 1.0 end gives test 1.00 test At line 7 of file recursive_io.f90 Fortran runtime error: End of record on both OSX and Linux. -- dominiq at lps dot ens dot fr changed: What|Removed |Added Summary|recursive I/O hangs under |recursive I/O hangs under |OSX 10.3|OSX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
[Bug bootstrap/30678] [4.3 regression] sysmacros.h get currupt from Fixincludes with updated glibc.
--- Comment #12 from tkoenig at gcc dot gnu dot org 2007-02-07 20:05 --- According to http://gcc.gnu.org/ml/gcc/2007-02/msg00067.html, this was caused by 2007-02-03 Bruce Korb [EMAIL PROTECTED] * inclhack.def (glibc_c99_inline_4): replace extern only if surrounded by space characters. As this blocks a good deal of gfortran development right now, would it be appropriate to reverse this patch? -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Summary|sysmacros.h get currupt from|[4.3 regression] sysmacros.h |Fixincludes with updated|get currupt from Fixincludes |glibc. |with updated glibc. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30678
[Bug libfortran/30533] minval, maxval missing for kind=1 and kind=2
--- Comment #5 from tkoenig at gcc dot gnu dot org 2007-02-07 20:08 ---
I think converting wil have a huge performance hit, so we'd better havec
kind=1
and kind=2 versions.
I agree, here's a patch to do this.
For speed reasons, we should also reverse the conversions
through the intrinsics that only make one pass through the data
(such as sum, product, or minmaxloc).
Index: Makefile.am
===
--- Makefile.am (revision 121423)
+++ Makefile.am (working copy)
@@ -176,6 +176,8 @@ generated/maxloc1_8_r16.c \
generated/maxloc1_16_r16.c
i_maxval_c= \
+generated/maxval_i1.c \
+generated/maxval_i2.c \
generated/maxval_i4.c \
generated/maxval_i8.c \
generated/maxval_i16.c \
@@ -231,6 +233,8 @@ generated/minloc1_8_r16.c \
generated/minloc1_16_r16.c
i_minval_c= \
+generated/minval_i1.c \
+generated/minval_i2.c \
generated/minval_i4.c \
generated/minval_i8.c \
generated/minval_i16.c \
Index: libgfortran.h
===
--- libgfortran.h (revision 121423)
+++ libgfortran.h (working copy)
@@ -224,6 +224,10 @@ internal_proto(l8_to_l4_offset);
#define GFOR_POINTER_L8_TO_L4(p8) \
(l8_to_l4_offset + (GFC_LOGICAL_4 *)(p8))
+#define GFC_INTEGER_1_HUGE \
+ (GFC_INTEGER_1)GFC_UINTEGER_1)1) 7) - 1)
+#define GFC_INTEGER_2_HUGE \
+ (GFC_INTEGER_1)GFC_UINTEGER_1)1) 15) - 1)
#define GFC_INTEGER_4_HUGE \
(GFC_INTEGER_4)GFC_UINTEGER_4)1) 31) - 1)
#define GFC_INTEGER_8_HUGE \
@@ -283,6 +287,8 @@ struct {\
/* Commonly used array descriptor types. */
typedef GFC_ARRAY_DESCRIPTOR (GFC_MAX_DIMENSIONS, void) gfc_array_void;
typedef GFC_ARRAY_DESCRIPTOR (GFC_MAX_DIMENSIONS, char) gfc_array_char;
+typedef GFC_ARRAY_DESCRIPTOR (GFC_MAX_DIMENSIONS, GFC_INTEGER_1) gfc_array_i1;
+typedef GFC_ARRAY_DESCRIPTOR (GFC_MAX_DIMENSIONS, GFC_INTEGER_2) gfc_array_i2;
typedef GFC_ARRAY_DESCRIPTOR (GFC_MAX_DIMENSIONS, GFC_INTEGER_4) gfc_array_i4;
typedef GFC_ARRAY_DESCRIPTOR (GFC_MAX_DIMENSIONS, GFC_INTEGER_8) gfc_array_i8;
#ifdef HAVE_GFC_INTEGER_16
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30533
[Bug c/30729] New: [4.1/4.2/4.3 Regression] value computed is not used warning with unused result of va_arg
#include stdarg.h
int f(int t, ...)
{
va_list a;
va_start (a, t);
va_arg(a, int);
int t1 = va_arg(a, int);
va_end(a);
return t1;
}
-
We get a warning on the line which just contains va_arg(a, int);
Even though the value is not used, a is still incremented so the result is not
unused after all.
t.c:7: warning: value computed is not used
--
Summary: [4.1/4.2/4.3 Regression] value computed is not used
warning with unused result of va_arg
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30729
[Bug c/30729] [4.1/4.2/4.3 Regression] value computed is not used warning with unused result of va_arg
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30729
[Bug c/30730] New: -Wunsafe-loop-optimizations gives too many warnings
$ cat warning.c
#if 0
gcc-4.1.1 -c -Os warning.c -Wunsafe-loop-optimizations
exit 0
#endif
void foo(unsigned int n)
{
while (n 10)
n -= 2;
}
^D
$ sh warning.c
warning.c: In function 'foo':
warning.c:8: warning: cannot optimize loop, the loop counter may overflow
warning.c:8: warning: cannot optimize loop, the loop counter may overflow
...
This warning seems to be wrong to me, or at least badly worded. Furthermore,
gcc should notice that the condition states n = 10, and n is decremented by
only 2 in each iteration, so the loop _will_ terminate. There won't be any
overflow.
It would also be nice if this warning were only printed once instead of 9
times.
--
Summary: -Wunsafe-loop-optimizations gives too many warnings
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: roland dot illig at gmx dot de
GCC build triplet: any
GCC host triplet: any
GCC target triplet: any
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30730
[Bug fortran/30720] runtime: check for empty array slices before allocating a negative amount of memory
--- Comment #7 from tkoenig at gcc dot gnu dot org 2007-02-07 20:49 --- (In reply to comment #6) The patch I attached removes this argument, and it gives no regression on the testsuite. I also simplified the conditional expression by using a COND_EXPR instead of generating different blocks. Would you mind looking at it to see if you spot anything odd? From eyballing the patch, it looks OK. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30720
[Bug bootstrap/30678] [4.3 regression] sysmacros.h get currupt from Fixincludes with updated glibc.
--- Comment #13 from bkorb at gnu dot org 2007-02-07 21:02 --- The problem was supposed to have been fixed: http://gcc.gnu.org/ml/gcc-cvs/2007-02/msg00194.html http://gcc.gnu.org/ml/gcc-cvs/2007-02/msg00172.html If you are still having problems, please show the nature of the difficulty. Specifically, the text that is mistakenly reformed or text that should be reformed but is not. THank you. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30678
[Bug target/29599] [4.1/4.2/4.3 Regression] ICE when building the kernel on SH4
--- Comment #3 from patchapp at dberlin dot org 2007-02-07 21:40 --- Subject: Bug number PR target/29599 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-02/msg00646.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29599
[Bug libstdc++/30578] array_allocator can't be safely copied
--- Comment #3 from skottmckay at gmail dot com 2007-02-07 21:58 --- Doesn't it need to be copy constructable for the rebinding to work for _Vector_base::_Vector_impl::_Tp_alloc_type? I agree that making it mt-safe doesn't quite fit with its intended usage. Possibly the array_allocator and backing array should be wrapped with a non-copyable class. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30578
[Bug fortran/30478] FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error)
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-02-07 22:31 --- Reduced testcase: enum, bind (c) integer :: x enumerator blue end enum end It fails under valgrind for both i686-linux and x86_64-linux: ==5651== Invalid read of size 4 ==5651==at 0x9DBD13: __gmpz_add_ui (in /utmp/coudert/gfortran/irun/libexec/gcc/x86_64-unknown-linux-gnu/4.3.0/f951) ==5651==by 0x403EC2: gfc_enum_initializer (arith.c:2422) ==5651==by 0x4135A0: variable_decl (decl.c:1366) ==5651==by 0x413886: gfc_match_enumerator_def (decl.c:4497) ==5651==by 0x43F792: match_word (parse.c:63) ==5651==by 0x43FD59: decode_statement (parse.c:133) ==5651==by 0x4407AA: next_statement (parse.c:499) ==5651==by 0x441955: parse_spec (parse.c:1645) ==5651==by 0x442DB5: parse_progunit (parse.c:2886) ==5651==by 0x44304F: gfc_parse_file (parse.c:3224) ==5651==by 0x4613ED: gfc_be_parse_file (f95-lang.c:307) ==5651==by 0x652942: toplev_main (toplev.c:1021) ==5651== Address 0x4AA00C4 is 100 bytes inside a block of size 160 free'd ==5651==at 0x4905A18: free (vg_replace_malloc.c:233) ==5651==by 0x458644: gfc_free_symbol (symbol.c:2005) ==5651==by 0x458A1C: gfc_undo_symbols (symbol.c:2326) ==5651==by 0x43F743: reject_statement (parse.c:1323) ==5651==by 0x441950: parse_spec (parse.c:1669) ==5651==by 0x442DB5: parse_progunit (parse.c:2886) ==5651==by 0x44304F: gfc_parse_file (parse.c:3224) ==5651==by 0x4613ED: gfc_be_parse_file (f95-lang.c:307) ==5651==by 0x652942: toplev_main (toplev.c:1021) ==5651==by 0x3FF241C4BA: (below main) (in /lib64/tls/libc-2.3.4.so) Adding Tobias to the CC list, as I think he was the one who wrote the ENUMERATOR support. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||Tobias dot Schlueter at ||physik dot uni-muenchen dot ||de Last reconfirmed|2007-02-05 22:23:02 |2007-02-07 22:31:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30478
[Bug libobjc/30731] New: Warnings while compiling libobjc on spu-elf with the uleb128 changes
/home/apinski/src/fsf/gcc/gcc/libobjc/exception.c: In function 'parse_lsda_header': /home/apinski/src/fsf/gcc/gcc/libobjc/exception.c:94: warning: passing argument 2 of 'read_uleb128' from incompatible pointer type /home/apinski/src/fsf/gcc/gcc/libobjc/exception.c:103: warning: passing argument 2 of 'read_uleb128' from incompatible pointer type /home/apinski/src/fsf/gcc/gcc/libobjc/exception.c: In function '__gnu_objc_personality_sj0': /home/apinski/src/fsf/gcc/gcc/libobjc/exception.c:211: warning: passing argument 2 of 'read_uleb128' from incompatible pointer type /home/apinski/src/fsf/gcc/gcc/libobjc/exception.c:212: warning: passing argument 2 of 'read_uleb128' from incompatible pointer type /home/apinski/src/fsf/gcc/gcc/libobjc/exception.c:279: warning: passing argument 2 of 'read_sleb128' from incompatible pointer type /home/apinski/src/fsf/gcc/gcc/libobjc/exception.c:280: warning: passing argument 2 of 'read_sleb128' from incompatible pointer type -- Summary: Warnings while compiling libobjc on spu-elf with the uleb128 changes Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: libobjc AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30731
[Bug libobjc/30731] Warnings while compiling libobjc on spu-elf with the uleb128 changes
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-07 22:50 --- Mine for both being the spu maintainer and the libobjc maintainer. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-02-07 22:50:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30731
[Bug tree-optimization/28778] [4.0/4.1 Regression] alias bug with cast and call clobbered
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.1.3 |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28778
[Bug c++/25156] [4.0/4.1/4.2/4.3 Regression] wrong error message (int instead of bool)
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.1.3 |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25156
[Bug libstdc++/28125] Cannot build cross compiler for Solaris: configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.1.3 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28125
[Bug c++/26573] [4.0/4.1 regression] Duplicate message for static member in local class
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.1.3 |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26573
[Bug tree-optimization/30562] [4.3 Regression] remove unused variable is removing a referenced variable (in STORED_SYMS or LOADED_SYMS)
--- Comment #5 from dnovillo at gcc dot gnu dot org 2007-02-07 23:33 --- I cannot reproduce this bug with mainline as of 2007-02-06. The bug is still latent though, so I will commit a variant of this patch to fix it. Essentially, we should leave every TREE_ADDRESSABLE variable alone so that it can be removed by a subsequent may_alias pass: Index: tree-ssa-live.c === --- tree-ssa-live.c (revision 121699) +++ tree-ssa-live.c (working copy) @@ -502,18 +502,20 @@ cell = TREE_CHAIN (*cell); } - /* Remove unused variables from REFERENCED_VARs. As an special exception - keep the variables that are believed to be aliased. Those can't be - easily removed from the alias sets and and operand caches. - They will be removed shortly after next may_alias pass is performed. */ + /* Remove unused variables from REFERENCED_VARs. As a special + exception keep the variables that are believed to be aliased. + Those can't be easily removed from the alias sets and operand + caches. They will be removed shortly after the next may_alias + pass is performed. */ FOR_EACH_REFERENCED_VAR (t, rvi) if (!is_global_var (t) !MTAG_P (t) TREE_CODE (t) != PARM_DECL TREE_CODE (t) != RESULT_DECL !(ann = var_ann (t))-used -!ann-is_aliased !is_call_clobbered (t) !ann-symbol_mem_tag) -remove_referenced_var (t); +!ann-symbol_mem_tag +!TREE_ADDRESSABLE (t)) + remove_referenced_var (t); } -- dnovillo at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30562
[Bug fortran/30478] FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error)
--- Comment #9 from tobi at gcc dot gnu dot org 2007-02-08 00:44 --- I reviewed the patch which introduced ENUM support, will take a look at this tomorrow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30478
[Bug libfortran/30617] recursive I/O hangs under OSX
--- Comment #15 from jvdelisle at gcc dot gnu dot org 2007-02-08 03:12 --- Try : external fun real fun character(10) :: string real a a = fun() print *, a,a write(string,'(f10.6)') fun() print *, string end real function fun() print *, 'test' fun = 1.0 end Or increase the size of string. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
[Bug c/30682] [4.3 Regression] Generation of gcc.1 manpage broken (texi2pod fails)
--- Comment #2 from burnus at gcc dot gnu dot org 2007-02-08 07:32 --- Seemingly fixed -- 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=30682
