[Bug target/36079] [4.3/4.4 Regression] cld instruction is not emitted anymore.
--- Comment #5 from cnstar9988 at gmail dot com 2008-05-20 07:08 --- >>> >>>ISVs usually build with compilers from the stone-age to be able to run their >>>applications on all still supported OS versions. I agree! -- which Linux Kernel version has the bug? Kernel Version >=2.4.20, 2.6.4, ? Whe use Rehat AS 3.0 update2 for development enviroment. We compile all programs on Rehat AS 3.0 update2.(gcc 4.2.2 or newer). It can run well on all AS 3.0/4.0/5.0, or other OS versions... How to reopen the bug? Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36079
[Bug libstdc++/36270] New: A problem with STL map/vector/list whose key is a STL string in multi-threaded application
Hi,
While developing a multi-threaded application I've encountered a problem that
is reproduced in a testcase presented below.
The purpose of the sample is to create a large number of threads where each
thread uses stl strings. The threads execute consecutively and not in parallel.
The problem is that the program crashes with a segmentation fault at line 14
(string instantiation in the f function) in thread number 4095 which is the
4097-th created thread (including the main thread). The segmentation fault
doesn't happen if line 23 is removed (assignment of a value into
std::map in mt_test function). The problem is also reproduced
if the insertion into map is replaced with insertion into a
std::vector or std::list. I've found that
mt_allocator.h defines 4096 as the maximum number of threads in the freelist
(_S_max_threads enum) which seems to be related to the problem.
The source code:
#include
#include
#include
#include
#include
#include
#include
using namespace std;
void* f(void *arg)
{
int i = (int)arg;
string str = "foobar"; // <-- segmentation fault
cout << "finished:"<< i << endl;
return 0;
}
void mt_test()
{
string str1("f");
map myMap;
myMap[str1] = "akjshd"; // <-- if removed, no crash
const int NUM_THREADS = 6000;
void* ret=0;
for(int i=0;i search starts here:
/usr/lib/gcc/i386-redhat-linux/4.0.0/../../../../include/c++/4.0.0
/usr/lib/gcc/i386-redhat-linux/4.0.0/../../../../include/c++/4.0.0/i386-redhat-linux
/usr/lib/gcc/i386-redhat-linux/4.0.0/../../../../include/c++/4.0.0/backward
/usr/local/include
/usr/lib/gcc/i386-redhat-linux/4.0.0/include
/usr/include
End of search list.
GNU C++ version 4.0.0 20050519 (Red Hat 4.0.0-8) (i386-redhat-linux)
compiled by GNU C version 4.0.0 20050519 (Red Hat 4.0.0-8).
GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=129317
as -V -Qy -o /tmp/ccSuAMBj.o /tmp/ccCvBzFs.s
GNU assembler version 2.15.94.0.2.2 (i386-redhat-linux) using BFD version
2.15.94.0.2.2 20041220
/usr/libexec/gcc/i386-redhat-linux/4.0.0/collect2 --eh-frame-hdr -m elf_i386
-dynamic-linker /lib/ld-linux.so.2 -o testthread
/usr/lib/gcc/i386-redhat-linux/4.0.0/../../../crt1.o
/usr/lib/gcc/i386-redhat-linux/4.0.0/../../../crti.o
/usr/lib/gcc/i386-redhat-linux/4.0.0/crtbegin.o
-L/usr/lib/gcc/i386-redhat-linux/4.0.0 -L/usr/lib/gcc/i386-redhat-linux/4.0.0
-L/usr/lib/gcc/i386-redhat-linux/4.0.0/../../.. -lpthread /tmp/ccSuAMBj.o
-lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
/usr/lib/gcc/i386-redhat-linux/4.0.0/crtend.o
/usr/lib/gcc/i386-redhat-linux/4.0.0/../../../crtn.o
Libraries:
$ ldd testthread
linux-gate.so.1 => (0x0029e000)
libpthread.so.0 => /lib/libpthread.so.0 (0x0063b000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00795000)
libm.so.6 => /lib/libm.so.6 (0x00524000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00753000)
libc.so.6 => /lib/libc.so.6 (0x003f8000)
/lib/ld-linux.so.2 (0x003d6000)
Performing a backtrace with gdb gives:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208943696 (LWP 32755)]
0x007d7977 in __gnu_cxx::__pool::_M_get_thread_id () from
/usr/lib/libstdc++.so.6
(gdb) backtrace
#0 0x007d7977 in __gnu_cxx::__pool::_M_get_thread_id () from
/usr/lib/libstdc++.so.6
#1 0x007d7e0c in __gnu_cxx::__pool::_M_reclaim_block () from
/usr/lib/libstdc++.so.6
#2 0x0082227d in std::string::_Rep::_S_create () from /usr/lib/libstdc++.so.6
#3 0x0082625f in std::operator+,
std::allocator > () from /usr/lib/libstdc++.so.6
#4 0x00826e7c in std::basic_string,
std::allocator >::basic_string () from /usr/lib/libstdc++.so.6
#5 0x08049067 in f (arg=0xfff) at
/home/sveta-c/testthread/src/testthread.cpp:14
#6 0x00640b80 in start_thread () from /lib/libpthread.so.0
#7 0x004c2dee in clone () from /lib/libc.so.6
I would really appriciate any help on the subject.
Thanks in advance,
Sveta.
--
Summary: A problem with STL map/vector/list whose key is a STL
string in multi-threaded application
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sveta dot cher at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36270
[Bug target/35295] 64-bit host cross compile to 32-bit target differs from 32-bit host cross compile to 32-bit target
--- Comment #13 from benny at ammitzboell-consult dot dk 2008-05-20 07:32 --- Ok, we have verified that this bug is not present when using a 4.2.3 arm toolchain. -- benny at ammitzboell-consult dot dk changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35295
[Bug fortran/35846] ICE on nested character constructors
--- Comment #2 from d at domob dot eu 2008-05-20 07:33 --- Created an attachment (id=15655) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15655&action=view) Hackish patch It seems the problem lies in gfc_conv_string_length, that can be called with a gfc_charlen whose length is NULL. This patch is somewhat a prove of concept of this, just creating a dummy length if it is NULL there; this prevents the ICEs described above. Of course this is surely not the correct place to do this initialization, I'll try to find it out later and work out a real patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35846
[Bug target/35295] 64-bit host cross compile to 32-bit target differs from 32-bit host cross compile to 32-bit target
--- Comment #14 from benny at ammitzboell-consult dot dk 2008-05-20 07:33 --- Verified on gcc 4.2.3 -- benny at ammitzboell-consult dot dk changed: What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35295
[Bug fortran/36271] New: [4.3 regression] Missed error with assignment to INTENT(IN) argument
Hi, the following code used to throw an error with GNU Fortran 95 (GCC) 4.1.2 20070115 (prerelease) (SUSE Linux) GNU Fortran (GCC) 4.2.1 (SUSE Linux) gfcbug78.f90:12.10: obs(l)% x = 0! gfortran misses this illegal assignment 1 Error: Can't assign to INTENT(IN) variable 'obs' at (1) but fails to do so with 4.3.x: GNU Fortran (GCC) 4.3.0 20080218 (experimental) [trunk revision 132388] GNU Fortran (GCC) 4.3.1 20080519 (prerelease) module gfcbug78 implicit none type t_obs real, pointer :: x(:) => NULL() end type t_obs contains subroutine set_obs (obs) type (t_obs), intent(in) :: obs(:) integer :: l do l = 1, size (obs) obs(l)% x = 0! gfortran misses this illegal assignment end do end subroutine set_obs end module gfcbug78 -- Summary: [4.3 regression] Missed error with assignment to INTENT(IN) argument Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: anlauf at gmx dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36271
[Bug c/36272] New: Please add support for google-breakpad or build own system.
Currently I'm after full rebuild of Gentoo distribution with gcc 4.3.0 on amd64 platfrom and number of internal compiler errors was huge. First I try use brutal forse and generate report for each package but number of actins and build scripts levels (gentoo scripts, automake logic, etc) cold my "whishes" ;( Please consider usage of any automatic crash report system (like google-breakpad) when compiler crash. Such approch will be much more efficient then current once. -- Summary: Please add support for google-breakpad or build own system. Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bursig at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36272
[Bug middle-end/36206] [4.4 Regression] ice for legal code with -O3
--- Comment #10 from jv244 at cam dot ac dot uk 2008-05-20 08:09 --- I've tested the patches posted here for PR36198, and they appear to fix the problem. Did they pass on the gccfarm? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36206
[Bug fortran/36267] [4.2 only] Segfault ICE on assignment of a string pointer to a substring target
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2008-05-20 08:22 --- This bug is fixed in gfortran-4.3.0 and later. Please migrate to a more recent compiler version; binaries for common systems can be found at http://gcc.gnu.org/wiki/GFortranBinaries. Closing as we don't fix bugs in the 4.2 branch except for very special cases (no further release of the 4.2 branch is planned). -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work|4.4.0 |4.4.0 4.3.0 Resolution||WONTFIX Summary|Segfault ICE on assignment |[4.2 only] Segfault ICE on |of a string pointer to a|assignment of a string |substring target|pointer to a substring ||target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36267
[Bug pch/36273] New: Please add notyfication/warning when pch IS use
In scenarion when we have many pch files in *.gch diretory. Then currently we may get info about not used pch file but IMHO we need final confirmation that any pch were used (flags are OK). -- Summary: Please add notyfication/warning when pch IS use Product: gcc Version: 3.4.6 Status: UNCONFIRMED Severity: normal Priority: P3 Component: pch AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bursig at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36273
[Bug target/36079] [4.3/4.4 Regression] cld instruction is not emitted anymore.
--- Comment #6 from cnstar9988 at gmail dot com 2008-05-20 08:48 --- How to reopen bug 36079? Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36079
[Bug libstdc++/36270] A problem with STL map/vector/list whose key is a string in multi-threaded application
--- Comment #1 from paolo dot carlini at oracle dot com 2008-05-20 09:17 --- Some general comments: The 4.0.x series is not supported anymore, any future fix will only go in 4.3.x and maybe 4.2.x; I see that you are using mt_alloc, which, in the FSF official release of GCC is *not* the default allocator, it's still largely experimental these times and was much more so in 4.0.x times; in mt_alloc there is unfortunately a compile-time limit on the maximum number of threads (grep _S_max_threads in mt_allocator.h) and for your applications, before any other investigation, I think you should experiment with raising that number (see the ext/mt_allocator/tune-*.cc testcases about changing those defaults) -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING Summary|A problem with STL |A problem with STL |map/vector/list whose key is|map/vector/list whose key is |a STL string in multi- |a string in multi-threaded |threaded application|application http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36270
[Bug c++/36274] New: Please improve usage of template libs.
Currently when we want use template libs approach (and not instance template in all *.o files where it is included) we have to use -fno-implicit-templates flag. The problem is that this flag change total g++ behavior and "nuke" all templates which is problematic when we want store only own templates in own libs. Please consider "port" Sun CC functionality which allow fetching templates from external library (*.a/*.so/*.o) during compilation phase via "-instlib" flag. This flag request on compiler to not emit code for instantiated implicitly (i.e. by use) templates found in directed libs (-inslib=libXXX.a) and leave resolving of those code to linker. All libs/objects files added in -instlib=xxx flag have to be link with target. Such functionality will nice improve build time of project which heavily use templates from external libs (like on Sun CC) and not force us to totally change project like for -fno-implicit-templates flag. *.o files (example pch.o): - compiler should fetch global and local symbols list. *.a files: - compiler should fetch global and local symbols list. *.so - compiler should fetch global symbols list. -- Summary: Please improve usage of template libs. Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bursig at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36274
[Bug fortran/36275] Binding label can be any scalar char initialisation expression
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2008-05-20 10:09 --- And there is more to it (with import statements), see the rest of the thread at http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/148d078cda002dc1# -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-05-20 10:09:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36275
[Bug fortran/36276] New: possible issue with opening fortran files?
compiling the testcase file (derived from CP2K) as: valgrind --tool=memcheck /data03/vondele/gcc_trunk/build/libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/f951 lapack.f -march=k8 -quiet -dumpbase lapack.F -auxbase lapack -ffree-form -fpreprocessed -fintrinsic-modules-path /data03/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/finclude -o lapack.s yields the following error with valgrind: ==1593== Invalid read of size 1 ==1593==at 0xB51CD1: linemap_add (line-map.c:111) ==1593==by 0xB52040: linemap_line_start (line-map.c:227) ==1593==by 0x46F0CC: load_file (scanner.c:1872) ==1593==by 0x46F574: gfc_new_file (scanner.c:1912) ==1593==by 0x48630F: gfc_init (f95-lang.c:288) ==1593==by 0x7016E8: toplev_main (toplev.c:2041) ==1593==by 0x4C7F153: (below main) (in /lib64/libc-2.4.so) ==1593== Address 0x4F31628 is 0 bytes inside a block of size 47 free'd ==1593==at 0x4A2066B: free (vg_replace_malloc.c:233) ==1593==by 0x46ED61: preprocessor_line (scanner.c:1642) ==1593==by 0x46EE8C: load_file (scanner.c:1800) ==1593==by 0x46F574: gfc_new_file (scanner.c:1912) ==1593==by 0x48630F: gfc_init (f95-lang.c:288) ==1593==by 0x7016E8: toplev_main (toplev.c:2041) ==1593==by 0x4C7F153: (below main) (in /lib64/libc-2.4.so) -- Summary: possible issue with opening fortran files? Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36276
[Bug fortran/36275] New: Binding label can be any scalar char initialisation expression
The following is legal: function x(z) bind(C,name='x'//'f') integer :: z, x end function x as the Standard (F2003) only says: R509: language-binding-spec is BIND (C [, NAME = scalar-char-initialization-expr ]) C540: The scalar-char-initialization-expr shall be of default character kind. So, any scalar char initialisation expression of default character kind is fair game. This will require removing a good part of the code in gfc_match_bind_c(), and call more generic routines instead, so it's not really bad news (and it also requires remove the gfc_match_name_C function). -- Summary: Binding label can be any scalar char initialisation expression Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36275
[Bug fortran/36276] possible issue with opening fortran files?
--- Comment #1 from jv244 at cam dot ac dot uk 2008-05-20 10:16 --- Created an attachment (id=15656) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15656&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36276
[Bug pch/36277] New: Please allow directing pch file localization/usage via direct compiler flag.
Currently I maintain large C/C++ project (over 400 lib/bin targets and ~100 000 files). It is targeted and ported on Sun (with Sun CC), HPUX (with aCC), Linux (with gcc) and Windows (MSVC). The Sun, HP and Windows compilers have common flags syntax and usage logic of pch functionality (create and use flags, etc). The Gcc chose own way of pch usage (direct *.h compilation and auto finding on Includes path) which force users to complicate build rules for gcc exception. The creation part is not so problematic than usage because all issues could be solved in build logic (as exception) but usage require bigger influence. The usage is more problematic because typically projects are older that gcc pch support and pch files lay directly in project/targets dirs (plus may have same names in different projects: stdafx.h ;)) which force us to create pch.gch direct in sources (gcc first search *.c/*.cpp dir for includes and pch). This limitation (may) give us many other problems like read-only src's tree, src's tree on dynamic medias, ugly project's which share files :| , playing with pch.gch dir and his contents, etc. Good solution would be -fpch-use=path/file.gch flag which allow us create pch together with obj's files and simple tell gcc where it could be find. -- Summary: Please allow directing pch file localization/usage via direct compiler flag. Product: gcc Version: 3.4.6 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: pch AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bursig at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36277
[Bug ada/30740] Improper semantics in gnat's compilation of certain expressions involving modular arithmetic
--- Comment #3 from charlet at gcc dot gnu dot org 2008-05-20 12:38 --- About to commit proper patch from Robert Dewar. -- charlet at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|sam at gcc dot gnu dot org |charlet at gcc dot gnu dot ||org Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30740
[Bug c++/36274] Please improve usage of template libs.
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-05-20 12:42 --- -frepo is/was supposed to deal with this -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36274
[Bug ada/24533] FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 ***
--- Comment #23 from charlet at gcc dot gnu dot org 2008-05-20 12:44 --- Subject: Bug 24533 Author: charlet Date: Tue May 20 12:43:59 2008 New Revision: 135614 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135614 Log: 2008-05-20 Arnaud Charlet <[EMAIL PROTECTED]> * s-linux-hppa.ads (atomic_lock_t): Put back proper alignment now that the underlying issue with malloc/free has been fixed. Remove associated comments. Minor reformatting. Related to PR ada/24533 Modified: trunk/gcc/ada/s-linux-hppa.ads -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24533
[Bug ada/30740] Improper semantics in gnat's compilation of certain expressions involving modular arithmetic
--- Comment #4 from charlet at gcc dot gnu dot org 2008-05-20 12:45 --- Subject: Bug 30740 Author: charlet Date: Tue May 20 12:44:55 2008 New Revision: 135619 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135619 Log: 2008-05-20 Robert Dewar <[EMAIL PROTECTED]> PR ada/30740 * einfo.ads, einfo.adb (Non_Binary_Modulus): Applies to all types and subtypes, always False for non-modular types. Shared_Var_Assign_Proc (node22) and Shared_Var_Read_Proc (node 15) entry nodes have been replaced by Shared_Var_Procs_Instance (node22) for Shared_Storage package. (Is_RACW_Stub_Type): New entity flag. * exp_ch4.adb (Expand_N_Op_Expon): Avoid incorrect optimization of a*(2**b) in the case where we have a modular type with a non-binary modules. Comments reformattings. * sem_intr.adb: Simplify code not that Non_Binary_Modulus applies to all types. Modified: trunk/gcc/ada/einfo.adb trunk/gcc/ada/einfo.ads trunk/gcc/ada/exp_ch4.adb trunk/gcc/ada/sem_intr.adb -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30740
[Bug ada/17985] GNAT accepts extension aggregate where expexted type is not extension
--- Comment #4 from charlet at gcc dot gnu dot org 2008-05-20 12:50 --- Subject: Bug 17985 Author: charlet Date: Tue May 20 12:49:21 2008 New Revision: 135636 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135636 Log: 2008-05-20 Ed Schonberg <[EMAIL PROTECTED]> * sem_aggr.adb: Update comments. Improve previous change for PR ada/17985 Modified: trunk/gcc/ada/sem_aggr.adb -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17985
[Bug target/36079] [4.3/4.4 Regression] cld instruction is not emitted anymore.
--- Comment #7 from ubizjak at gmail dot com 2008-05-20 12:51 --- Patch v2 (with --enable-cld configure option) at: http://gcc.gnu.org/ml/gcc-patches/2008-05/msg01178.html -- ubizjak at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||05/msg01178.html Status|RESOLVED|REOPENED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36079
[Bug middle-end/36262] [4.3/4.4 Regression] Extreme memory usage of VRP compared to older versions
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-05-20 13:00 --- It is not safe. Probably the best thing would be to not ask SCEV during the propagation but instead at ASSERT_EXPR insertion time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36262
[Bug ada/30740] Improper semantics in gnat's compilation of certain expressions involving modular arithmetic
--- Comment #5 from charlet at gcc dot gnu dot org 2008-05-20 13:07 --- Fixed. -- charlet at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30740
[Bug c++/36274] Please improve usage of template libs.
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-05-20 13:10 --- Also you might want want to look into the GCC extension (to C++98/C++03) called extern template whch does the same thing. Note it is being added to C++0x already. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36274
[Bug testsuite/36272] Please add support for google-breakpad or build own system.
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-20 13:21 --- Redhat has patches that automatically tries to compile again and then produce a preprocessed source which makes this easier. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |testsuite http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36272
[Bug pch/36273] Please add notyfication/warning when pch IS use
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-20 13:22 --- -H will tell you that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36273
[Bug pch/36277] Please allow directing pch file localization/usage via direct compiler flag.
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-20 13:26 --- I really don't see the issue here really, if you don't setup your include pathes correctly to include the object directory first, that seems like your issue rather than a limitation of GCC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36277
[Bug c++/36278] New: [4.2 4.3 regression] ICE with typedef void in namespace and using the defined type in another when compiling with "-g"
The code snippet goes as follows:
*snip*
namespace Bar
{
typedef void MyVoid;
}
using Bar::MyVoid;
*snip*
Compiling with "g++-4.3.0 -save-temps -g -Wall -o simple simple.cc -c"
results in this:
simple.cc:6: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug fortran/36257] SPREAD gives wrong results with array CHARACTER parameters
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2008-05-20 13:33 --- (In reply to comment #3) > I wonder what else it breaks :) Apparently, nothing. It was apparently introduced by Paul and I during the efforts to fix PR31608, and is probably just copied from the lines above. Anyway, the testsuite regtests fine on x86_64-linux with it, and CP2K still compiles. As I don't see a logic for that line, let's just remove it! -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-05-18 10:03:00 |2008-05-20 13:33:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36257
[Bug c++/36278] [4.2/4.3 regression] ICE with typedef void in namespace and using the defined type in another when compiling with "-g"
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-20 13:36 --- Works for me with the trunk on both i686-linux-gnu and i386-apple-darwin. Also works with "4.3.0 20070729" and 4.3.0 20080128 on i386-apple-darwin. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.2 4.3 regression] ICE|[4.2/4.3 regression] ICE |with typedef void in|with typedef void in |namespace and using the |namespace and using the |defined type in another when|defined type in another when |compiling with "-g" |compiling with "-g" http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36278
[Bug c++/36278] [4.2/4.3/4.4 Regression] ICE with typedef void in namespace and using the defined type in another when compiling with "-g"
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-05-20 13:44 --- Confirmed. -g is the key. Program received signal SIGSEGV, Segmentation fault. 0x0081eed9 in prune_unused_types_mark (die=0x0, dokids=1) at /space/rguenther/src/svn/trunk/gcc/dwarf2out.c:14913 14913 if (die->die_mark == 0) -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Known to fail||4.2.3 4.3.0 4.4.0 Last reconfirmed|-00-00 00:00:00 |2008-05-20 13:44:25 date|| Summary|[4.2/4.3 regression] ICE|[4.2/4.3/4.4 Regression] ICE |with typedef void in|with typedef void in |namespace and using the |namespace and using the |defined type in another when|defined type in another when |compiling with "-g" |compiling with "-g" Target Milestone|--- |4.2.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36278
[Bug preprocessor/36279] New: division by zero in #if
$ cat argh.h #define __x(y) __NR_##y #define x(y) __x(y) /* define HAVE_FOO if __NR_XXX is defined: */ #define __NR_read 0 #undef __NR_write #ifdef BUG2 #define __NR_ac%scess 1 #endif #if defined XXX # if x(XXX) >= 0 # define HAVE_FOO 1 # warning HAVE_FOO # else # undef HAVE_FOO # warning no FOO # endif #endif $ echo | gcc-4.4-trunk -DXXX=acce%ss -include argh.h -c - -E -P In file included from :0: ./argh.h:11:13: error: division by zero in #if ./argh.h:13:4: warning: #warning HAVE_FOO Another (alleged) one, BUG2: $ echo | gcc-4.4-trunk -DBUG2 -DXXX=read -include argh.h -c - -E -P In file included from :0: ./argh.h:7:16: warning: missing whitespace after the macro name ./argh.h:13:4: warning: #warning HAVE_FOO And something that would be handy to have but that doesn't seem to work for me: This is Ok, __NR_read is defined: $ echo | gcc-4.4-trunk -DXXX=read -include argh.h -c - -E -P In file included from :0: ./argh.h:13:4: warning: #warning HAVE_FOO This is not OK, i'd expect this to be "no FOO" since __NR_write is *not* defined: $ echo | gcc-4.4-trunk -DXXX=write -include argh.h -c - -E -P In file included from :0: ./argh.h:13:4: warning: #warning HAVE_FOO -- Summary: division by zero in #if Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aldot at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36279
[Bug fortran/36271] [4.3 regression] Missed error with assignment to INTENT(IN) argument
--- Comment #1 from kargl at gcc dot gnu dot org 2008-05-20 14:19 --- Works for me with 4.4.0. Whether a back port from 4.4.0 to 4.3.0 is possible, I do not know. At a minimum, the submit code should be added to the testsuite to prevent future regressions. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Known to work||4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36271
[Bug preprocessor/36279] division by zero in #if
--- Comment #1 from schwab at suse dot de 2008-05-20 14:31 --- Undefined identifiers are replaced by 0 in #if. -- schwab at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36279
Bug found in libiberty by Coverity software
Coverity has found a long-standing potential issue in this file:
File: cp-demangle.c
Function: d_print_comp
The problem is that the while loop below executes until 'typed_name ==
NULL'. Then immediately after the loop, typed_name is dereferenced. If
the loop exits when typed_name is NULL, dereferencing it should cause a
crash.
It is possible that this condition is never encountered if the break at
line 2735 is always taken.
The fix would be a check for typed_name == NULL at the termination of
the while loop, and deal with it appropriately.
Best regards,
Kevin
-
2716typed_name = d_left (dc);
Event var_compare_op: Added "typed_name" due to comparison "typed_name
!= 0"
At conditional (1): "typed_name != 0" taking false path
2717while (typed_name != NULL)
2718 {
2719if (i >= sizeof adpm / sizeof adpm[0])
2720 {
2721d_print_error (dpi);
2722return;
2723 }
2724
2725adpm[i].next = dpi->modifiers;
2726dpi->modifiers = &adpm[i];
2727adpm[i].mod = typed_name;
2728adpm[i].printed = 0;
2729adpm[i].templates = dpi->templates;
2730++i;
2731
2732if (typed_name->type !=
DEMANGLE_COMPONENT_RESTRICT_THIS
2733&& typed_name->type !=
DEMANGLE_COMPONENT_VOLATILE_THIS
2734&& typed_name->type !=
DEMANGLE_COMPONENT_CONST_THIS)
2735 break;
2736
2737typed_name = d_left (typed_name);
2738 }
2739
2740/* If typed_name is a template, then it applies to the
2741 function type as well. */
Event var_deref_op: Variable "typed_name" tracked as NULL was
dereferenced.
2742if (typed_name->type == DEMANGLE_COMPONENT_TEMPLATE)
2743 {
2744dpt.next = dpi->templates;
2745dpi->templates = &dpt;
2746dpt.template_decl = typed_name;
2747 }
[Bug fortran/36205] Hangup with array_constructor_24.f90 at -O3
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2008-05-20 15:14 --- Jerry, could you recompile it with -fdump-tree-all and attach all the tree dumps? Then we can do the same on x86_64-linux and see if it's something in the code generation, or later. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36205
[Bug target/36079] [4.3/4.4 Regression] cld instruction is not emitted anymore.
--- Comment #8 from cnstar9988 at gmail dot com 2008-05-20 15:17 --- if configure gcc 4.3.1 with --enable-cld on Redhat AS 3.0 U2. The programs build with gcc 4.3.1 run well on all Redhat AS 3.0/4.0/5.0, SUSE 9/10 or other Linux OS versions, is it right? If no --enable-cld with gcc 4.3.1, what will happen with my programs, Thanks! GCC 4.2.4 works well on Rehat AS 3.0 U3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36079
[Bug fortran/36132] _gfortran_internal_pack on optional arguments
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2008-05-20 15:18 --- (In reply to comment #5) > this seems one of the few wrong-code bugs that affects Fortran95 in a system > independent way. Any chance to fix this, with a backport to 4.3(.2) ? I > believe > we could try to code around it for new versions of CP2K, but that would just > be > CP2K. I would guess that the fix is very localized and 'obvious'. This is not a regression, but I guess as you that the fix should be simple, so why not? I'll look into it. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-05-05 18:57:28 |2008-05-20 15:18:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36132
[Bug middle-end/36125] [4.4 Regression] FAIL: 26_numerics/complex/13450.cc: ICE in verify_gimple_expr, at tree-cfg.c:3962
--- Comment #5 from danglin at gcc dot gnu dot org 2008-05-20 15:23 --- This was introduced in r133479. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36125
[Bug target/36079] [4.3/4.4 Regression] cld instruction is not emitted anymore.
--- Comment #9 from cnstar9988 at gmail dot com 2008-05-20 15:23 --- GCC 4.2.4 works well on Rehat AS 3.0 U2. How can I use gcc 4.3.1 instead of gcc 4.2.X? I want to build my programs on Rehat AS 3.0 U2 with newer gcc, 4.2.4 or 4.3.1. At the same time, I want the compiled programs run well on all Redhat AS 3.0/4.0/5.0, SUSE 9/10, and other Linux OS versions(>=2.4.20, >=2.6.4). Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36079
[Bug fortran/36271] [4.3 regression] Missed error with assignment to INTENT(IN) argument
--- Comment #2 from burnus at gcc dot gnu dot org 2008-05-20 15:26 --- > Works for me with 4.4.0. Well, it also "works" for me with 4.3.1 and 4.4.0 (in the sense that _no_ error is shown). However, I would claim that the program is valid as neither obs nor objs(n)%x itself is changed, but only the target to which objs(n)%x points to. For completeness, the program is also accepted by NAG f95, g95. However, it is rejected by ifort, openf95 and sunf95. gfortran changed when my pointer intent patch was checked in around January 2007. (see PR29624) * * * If a dummy argument is a derived-type object with a pointer component, then the pointer as a pointer is a subobject of the dummy argument, but the target of the pointer is not. Therefore, the restrictions on subobjects of the dummy object apply to the pointer in contexts where it is used as a pointer, but not in contexts where it is dereferenced to indicate its target. Similarly, the INTENT restrictions on pointer dummy arguments apply only to the association of the dummy argument; they do not restrict the operations allowed on its target. A pointer object with the INTENT (IN) attribute shall not appear as (1) A pointer-object in a nullify-stmt, (2) A data-pointer-object or proc-pointer-object in a pointer-assignment-stmt, (3) An allocate-object in an allocate-stmt or deallocate-stmt, or (4) An actual argument in a reference to a procedure if the associated dummy argument is a pointer with the INTENT (OUT) or INTENT (INOUT) attribute. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36271
[Bug target/36079] [4.3/4.4 Regression] cld instruction is not emitted anymore.
--- Comment #10 from rguenther at suse dot de 2008-05-20 15:27 --- Subject: Re: [4.3/4.4 Regression] cld instruction is not emitted anymore. On Tue, 20 May 2008, cnstar9988 at gmail dot com wrote: > --- Comment #8 from cnstar9988 at gmail dot com 2008-05-20 15:17 --- > if configure gcc 4.3.1 with --enable-cld on Redhat AS 3.0 U2. > The programs build with gcc 4.3.1 run well on all Redhat AS 3.0/4.0/5.0, SUSE > 9/10 or other Linux OS versions, is it right? > > If no --enable-cld with gcc 4.3.1, what will happen with my programs, Thanks! Nothing will happen. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36079
[Bug fortran/36276] possible issue with opening fortran files?
--- Comment #2 from jv244 at cam dot ac dot uk 2008-05-20 15:28 --- Created an attachment (id=15657) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15657&action=view) an 8 line testcase valgrind --tool=memcheck /data03/vondele/gcc_trunk/build/libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/f951 bug.f small testcase, contains nearly no fortran -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36276
[Bug pch/36277] Please allow directing pch file localization/usage via direct compiler flag.
--- Comment #2 from bursig at gmail dot com 2008-05-20 15:42 --- (In reply to comment #1) > I really don't see the issue here really, if you don't setup your include > pathes correctly to include the object directory first, that seems like your > issue rather than a limitation of GCC. > Then please create simple pch.h (with stdlib.h included) and main.c (where you include pch.h) in same dir. Now create obj dir in pwd and build pch.h.gch (gcc -H -O2 -Iobj pch.h -c -o obj/pch.h.gch) there. Now build main.c as gcc -O2 -H -Iobj -c -o main.o main.c. As I know gcc search headers in *.c/*.cpp dir before touch -I search paths. In my case pch is not used... As I say may before projects already exist and changing source tree (moving pch headers outoff sources dir) for gcc is not good news for me because it will automatically disable pch with Sun CC (Sun require pch.h in source dir). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36277
[Bug pch/36277] Please allow directing pch file localization/usage via direct compiler flag.
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-05-20 15:44 --- >As I know gcc search headers in *.c/*.cpp dir before touch -I search paths. Only for "" include directories and you can disable that with at one point with -I- so ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36277
[Bug pch/36273] Please add notyfication/warning when pch IS use
--- Comment #2 from bursig at gmail dot com 2008-05-20 15:49 --- (In reply to comment #1) > -H will tell you that. > Ok that will work but will automatically drop tons of info into build output. IMHO better will be extension in "-Winvalid-pch" flag and printing info about used pch.h.gch when gcc detect another pch.gch which can't be used. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36273
[Bug pch/36273] Please add notyfication/warning when pch IS use
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-05-20 15:53 --- Considering that you can put many files inside a directory called *.gch and those will be used for the PCH at different optimization levels and options. I don't see why having an other option important. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36273
[Bug middle-end/36206] [4.4 Regression] ice for legal code with -O3
--- Comment #11 from spop at gcc dot gnu dot org 2008-05-20 16:06 --- Subject: Bug 36206 Author: spop Date: Tue May 20 16:05:09 2008 New Revision: 135663 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135663 Log: 2008-05-20 Jan Sjodin <[EMAIL PROTECTED]> Sebastian Pop <[EMAIL PROTECTED]> PR tree-optimization/36206 * tree-scalar-evolution.c: Remove enum INSERT_SUPERLOOP_CHRECS, FOLD_CONVERSIONS. (instantiate_scev_1): Rename flags to fold_conversions. Do not check for INSERT_SUPERLOOP_CHRECS, keep SSA_NAMEs defined outeside instantiation_loop. * tree-chrec.h (evolution_function_is_affine_in_loop): New. (evolution_function_is_affine_or_constant_p): Removed. * tree-data-ref.c (dr_analyze_indices): Replace resolve_mixers with instantiate_scev. (analyze_siv_subscript): Pass in the loop nest number. Call evolution_function_is_affine_in_loop instead of evolution_function_is_affine_p. (analyze_overlapping_iterations): Pass in the loop nest number. * tree-chrec.h (chrec_fold_op): New. * tree-data-ref.c (initialize_matrix_A): Traverse NOP_EXPR, PLUS_EXPR, and other trees. * testsuite/gfortran.dg/pr36206.f: New. Added: trunk/gcc/testsuite/gfortran.dg/pr36206.f Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-chrec.h trunk/gcc/tree-data-ref.c trunk/gcc/tree-scalar-evolution.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36206
[Bug c++/36274] Please improve usage of template libs.
--- Comment #3 from bursig at gmail dot com 2008-05-20 16:07 --- (In reply to comment #1) > -frepo is/was supposed to deal with this > As I know -frepo simple force -fno-implicit-templates which rip all template instantion from all objects and produce additional special files which are needed for new/additional pre-link compiler call which inject missing implementation. I'm not expert here but I suppose that gcc will simple build it even some of those symbols will be available during link. Sun propose simpler methodology... compiler know during build phase (via -instlib) what (and what not) templates instance will be available during link and simple don't emit code for it. There is no special pre-link phase, no special files only normal linking (and unknown symbols when you don't and proper -llibs flags). As I know Sun CC per-default add stl implementation library via -instlib which reduce build time of know/"prebuild in lib" stl templates instantions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36274
[Bug middle-end/36206] [4.4 Regression] ice for legal code with -O3
--- Comment #12 from spop at gcc dot gnu dot org 2008-05-20 16:07 --- Fixed. -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36206
[Bug pch/36277] Please allow directing pch file localization/usage via direct compiler flag.
--- Comment #4 from bursig at gmail dot com 2008-05-20 16:16 --- (In reply to comment #3) > >As I know gcc search headers in *.c/*.cpp dir before > touch -I search paths. > > Only for "" include directories and you can disable that with at one point > with > -I- so ... > hmm... 1) any pch.h is project specific file then should use "" and not <>. 2) -I- is deprecated and I don't know when it disappear. 3) Using it force me to review all project and secure all -I sequences and track of all not exit source dir on -I paths. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36277
[Bug c++/36274] Please improve usage of template libs.
--- Comment #4 from bursig at gmail dot com 2008-05-20 16:21 --- (In reply to comment #2) > Also you might want want to look into the GCC extension (to C++98/C++03) > called > extern template whch does the same thing. Note it is being added to C++0x > already. > > -- Pinski > Yes I know about it and I use it but in large project many libs come form another teams or another vendors who simple are not interested in such build time optimizations. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36274
[Bug tree-optimization/36198] [4.4 Regression] expected integer_cst, have mult_expr
--- Comment #7 from spop at gcc dot gnu dot org 2008-05-20 16:08 --- Fixed. -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36198
[Bug pch/36273] Please add notyfication/warning when pch IS use
--- Comment #4 from bursig at gmail dot com 2008-05-20 16:30 --- (In reply to comment #3) > Considering that you can put many files inside a directory called *.gch and > those will be used for the PCH at different optimization levels and options. > I > don't see why having an other option important. > And exactly this scenario is painful for me because current gcc inform (via -Winvalid-pch) only about not used pch files in *.gch dir. And finally reading logs you don't know if anyone of them was used. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36273
[Bug middle-end/35204] [4.3/4.4 Regression] crash by too deep recursion in DFS tree-ssa-sccvn.c:1898
--- Comment #25 from jakub at gcc dot gnu dot org 2008-05-20 16:32 --- Richard, could you reconsider that? I know it only affects Wine, but given how popular Wine is and there many people who compile it on their own, we have many dups for this in our bugzilla. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35204
[Bug fortran/36275] Binding label can be any scalar char initialisation expression
--- Comment #2 from burnus at gcc dot gnu dot org 2008-05-20 16:51 --- The other problem mentioned in the thread is the following bogus warning: procedure(stub), bind(C,name='cacosf') :: my_ACOS ! Compiles 1 Warning: Variable 'my_acos' at (1) may not be a C interoperable kind but it is bind(c) I think it appeared after 2008-05-01-Rev134843 and should be related to one of the procedure patches. Test case: module trig_sp use ISO_C_BINDING integer, parameter :: rkind = C_FLOAT integer, parameter :: ckind = C_FLOAT_COMPLEX abstract interface function stub(z) bind(C) import rkind, ckind complex(ckind), value :: z complex(ckind) stub end function stub end interface procedure(stub), bind(C,name='cacosf') :: my_ACOS ! Compiles end module trig_sp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36275
[Bug ada/35576] Ada HW Interrupt Task Enhancement
--- Comment #8 from joel at gcc dot gnu dot org 2008-05-20 16:59 --- Patch against SVN trunk still OK using 20080519 (experimental) [trunk revision 135528] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35576
[Bug rtl-optimization/323] optimized code gives strange floating point results
--- Comment #109 from pepalogik at seznam dot cz 2008-05-20 16:59 ---
I also encountered such problems and was going to report it as a bug in GCC...
But in the GCC bug (not) reporting guide, there is fortunately a link to this
page and here (comment #96) is a link to David Monniaux's paper about
floating-point computations. This explains it closely but it is maybe too long.
I have almost read it and hope I have understood it properly. So I'll give a
brief explanation (for those who don't know it yet) of the reasons of such a
strange behaviour. Then I'll assess where the bug actually is (in GCC or CPU).
Then I'll write the solution (!) and finally a few recommendations to the GCC
team.
EXPLANATION
The x87 FPU was originally designed in (or before) 1980. I think that's why it
is quite simple: it has only one unit for all FP data types. Of course, the
precision must be of the widest type, which is the 80-bit long double.
Consider you have a program, where all the FP variables are of the type double.
You perform some FP operations and one of them is e.g. 1e-300/1e300, which
results in 1e-600. Despite this value cannot be held by a "double", it is
stored in an 80-bit FPU register as the result. Consider you use the variable
"x" to hold that result. If the program has been compiled with optimization,
the value need not be stored in RAM. So, say, it is still in the register.
Consider you need x to be nonzero, so you perform the test x != 0. Since 1e-600
is not zero, the test yields true. While you perform some other computations,
the value is moved to RAM and converted to 0 because x is of type "double". Now
you want to use your certainly nonzero x... Hard luck :-(
Note that if the result doesn't have its corresponding variable and you perform
the test directly on an expression, the problem can come to light even without
optimization.
It could seem that performing all FP operations in extended precision can bring
benefits only. But it introduces a serious pitfall: moving a value may change
the value!!!
WHERE'S THE BUG
This is really not a GCC bug. The bug is actually in the x87 FPU because it
doesn't obey the IEEE standard.
SOLUTION
The x87 FPU is still present in contemporary processors (including AMD) due to
compatibility. I think most of PC software still uses it. But new processors
have also another FPU, called SSE, and this do obey the IEEE. GCC in 32-bit
mode compiles for x87 by default but it is able to compile for the SSE, too. So
the solution is to add these options to the compilation command:
-march=* -msse -mfpmath=sse
Yes, this definitely resolves the problem - but not for all processors. The *
can be one of the following: pentium3, pentium3m, pentium-m, pentium4,
pentium4m, prescott, nocona, athlon-4, athlon-xp, athlon-mp, k8, opteron,
athlon64, athlon-fx and c3-2 (I'm unsure about athlon and athlon-tbird). Beside
-msse, you can also add some of -mmmx, -msse2, -msse3 and -m3dnow, if the CPU
supports them (see GCC doc or CPU doc).
If you wish to compile for processors which don't have SSE, you have a few
possibilities:
(1) A very simple solution: Use long double everywhere. (But be careful when
transfering binary data in long double format between computers because this
format is not standardized and so the concrete bit representations vary between
different CPU architectures.)
(2) A partial but simple solution: Do comparisons on volatile variables only.
(3) A similar solution: Try to implement a "discard_extended_precision"
function suggested by Egon in comment #88.
(4) A complex solution: Before doing any mathematical operation or comparison,
put the operands into variables and put also the result to a variable (i.e.
don't use complex expressions). For example, instead of { c = 2*(a+b); } ,
write { double s = a+b; c = 2*s; } . I'm unsure about arrays but I think they
should be OK. When you have modified your code in this manner, then compile it
either without optimization or, when using optimization, use -ffloat-store. In
order to avoid double rounding (i.e. rounding twice), it is also good to
decrease the FPU precision by changing its control word in the beginning of
your program (see comment #60). Then you should also apply -frounding-math.
(5) A radical solution: Find a job/hobby where computers are not used at all.
RECOMMENDATIONS
I think this problem is really serious and general. Therefore, programmers
should be warned soon enough.
This recommendation should be addressed especially to authors of programming
coursebooks. But I think there could also be a paragraph about it in the GCC
documentation (I haven't read it wholly but it doesn't seem there's any warning
against x87). And, of course, there should be a warning in the bug reporting
guide (http://gcc.gnu.org/bugs.html). It's fine there's a link to this page
(Bug 323) but the example with (int)(a/b) is insufficient. It only demonstrates
that real numbers are often not represented exactly in the computer. It doesn't
demonstrat
[Bug c/36280] New: -fno-leading-underscore doesn't work
When compiling a static lib to be linked against with visual studio 2008 I needed to compile with -fno-leading-underscore (since vs2k8 expects symbol names from c static libraries to be "symname" instead of "_symname" as it currently exports). Adding -fno-leading-underscore didn't make a difference, all symbols still had a leading underscore. -- Summary: -fno-leading-underscore doesn't work Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jkolb at brandeis dot edu GCC target triplet: x86_64-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36280
[Bug c/36280] -fno-leading-underscore doesn't work
--- Comment #1 from jkolb at brandeis dot edu 2008-05-20 17:14 --- See https://sourceforge.net/forum/forum.php?thread_id=2044306&forum_id=723797 for more information. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36280
[Bug c++/33979] support for char16_t, char32_t
--- Comment #10 from paolo at gcc dot gnu dot org 2008-05-20 18:12 --- Subject: Bug 33979 Author: paolo Date: Tue May 20 18:11:34 2008 New Revision: 135668 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135668 Log: 2008-05-20 Paolo Carlini <[EMAIL PROTECTED]> PR c++/33979 (partial) * include/tr1_impl/functional_hash.h (hash, hash): Add specializations. * include/tr1_impl/type_traits (is_integral, is_integral): Likewise. * include/std/limits (numeric_limits, numeric_limits): Likewise. * src/limits_c++0x.cc: Add. * src/Makefile.am: Update. * testsuite/20_util/hash/requirements/explicit_instantiation.cc: Update. * testsuite/20_util/is_integral/value.cc: New. * testsuite/20_util/is_integral/requirements/typedefs.cc: Likewise. * testsuite/20_util/is_integral/requirements/ explicit_instantiation.cc: Likewise. * testsuite/18_support/numeric_limits/char16_32_t.cc: Likewise. * config/abi/pre/gnu.ver: Export new numeric_limits symbols at GLIBCXX_3.4.11. * configure: Regenerate. * src/Makefile.in: Likewise. * config.h.in: Likewise. Added: trunk/libstdc++-v3/src/limits_c++0x.cc trunk/libstdc++-v3/testsuite/18_support/numeric_limits/char16_32_t.cc trunk/libstdc++-v3/testsuite/20_util/is_integral/ trunk/libstdc++-v3/testsuite/20_util/is_integral/requirements/ trunk/libstdc++-v3/testsuite/20_util/is_integral/requirements/explicit_instantiation.cc trunk/libstdc++-v3/testsuite/20_util/is_integral/requirements/typedefs.cc trunk/libstdc++-v3/testsuite/20_util/is_integral/value.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/config.h.in trunk/libstdc++-v3/config/abi/pre/gnu.ver trunk/libstdc++-v3/configure trunk/libstdc++-v3/include/std/limits trunk/libstdc++-v3/include/tr1_impl/functional_hash.h trunk/libstdc++-v3/include/tr1_impl/type_traits trunk/libstdc++-v3/src/Makefile.am trunk/libstdc++-v3/src/Makefile.in trunk/libstdc++-v3/testsuite/20_util/hash/requirements/explicit_instantiation.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33979
[Bug middle-end/35204] [4.3/4.4 Regression] crash by too deep recursion in DFS tree-ssa-sccvn.c:1898
--- Comment #26 from rguenth at gcc dot gnu dot org 2008-05-20 18:28 --- Ok, I'll give it an updated round of testing. Even though it is still ugly as hell ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35204
[Bug middle-end/36194] [Regression] Truncation optimization in combine can remove necessary truncations
--- Comment #7 from nemet at gcc dot gnu dot org 2008-05-20 18:44 --- Fixed on all branches. -- nemet at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Summary|[4.2 Regression] Truncation |[Regression] Truncation |optimization in combine can |optimization in combine can |remove necessary truncations|remove necessary truncations http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36194
FW: sizeof() issue on gcc version 3.4.5
class base
{
public:
base(){};
~base(){};
};
class data : public base
{
public:
data(){};
~data(){};
private:
int member;
}__attribute__((__packed__));
class group : public base
{
public:
group(){};
~group(){};
private:
data d1;
data d2;
data d3;
} __attribute__((__packed__));
int main(int argc, char **argv)
{
std::cout << "base = " << sizeof(base) << std::endl;
std::cout << "data = " << sizeof(data) << std::endl;
std::cout << "group = " << sizeof(group) << std::endl;
return (0);
}
The output of the program is:
base = 1
data = 4
group = 13
The result of sizeof(group) is puzzling as it should be 12 if EBO (empty
base
optimization) worked for both class data and group. Apparently EBO kicked in
for
_ONLY_ one of them. If EBO didn't work at all, sizeof(group) should be 16.
Removing the extension of class base from either class group or data will
cause
sizeof(group) to return 12. It seems that gcc is unable to fully apply EBO
when a
class and its member inherits the same empty base class.
The same code had been tested on microsoft msvc compiler and realview arm
compiler, both correctly optimizes the code and give the correct value as
12.
Is this a known bug with gcc 3.4.5? (Note: I'm using MinGW) I dug through
the bugbase but couldn't come
up with anything. Maybe EBO isn't the problem at all.
Thanks!
[Bug fortran/36271] [4.3 regression] Missed error with assignment to INTENT(IN) argument
--- Comment #3 from anlauf at gmx dot de 2008-05-20 18:43 --- (In reply to comment #2) > However, I would claim that the program is valid as neither obs nor objs(n)%x > itself is changed, but only the target to which objs(n)%x points to. I see. If component x were an allocatable instead of a pointer, would I then get an error? It might be useful to emit a warning when -Wsurprising (or some other option turned on by -Wall) is enabled. In that case feel free to change the title appropriately, otherwise you may close this report as invalid. Sorry for the noise > * * * > > If a dummy argument is a derived-type object with a pointer component, then > the > pointer as a pointer is a subobject of the dummy argument, but the target of > the pointer is not. Therefore, the restrictions on subobjects of the dummy > object apply to the pointer in contexts where it is used as a pointer, but not > in contexts where it is dereferenced to indicate its target. > > Similarly, the INTENT restrictions on pointer dummy arguments apply only to > the > association of the dummy argument; they do not restrict the operations allowed > on its target. > > A pointer object with the INTENT (IN) attribute shall not appear as > (1) A pointer-object in a nullify-stmt, > (2) A data-pointer-object or proc-pointer-object in a pointer-assignment-stmt, > (3) An allocate-object in an allocate-stmt or deallocate-stmt, or > (4) An actual argument in a reference to a procedure if the associated dummy > argument is a pointer with the INTENT (OUT) or INTENT (INOUT) attribute. I could not yet find this wording in the standard. Do you by chance know the exact verse? The only thing I could find was: [F2003 draft] 5.1.2.7 INTENT attribute [...] The INTENT (IN) attribute for a nonpointer dummy argument specifies that it shall neither be defined nor become undefined during the execution of the procedure. The INTENT (IN) attribute for a pointer dummy argument specifies that during the execution of the procedure its association shall not be changed except that it may become undefined if the target is deallocated other than through the pointer (16.4.2.1.3). Thanks, -ha -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36271
[Bug middle-end/36194] [4.2 Regression] Truncation optimization in combine can remove necessary truncations
--- Comment #6 from nemet at gcc dot gnu dot org 2008-05-20 18:43 --- Subject: Bug 36194 Author: nemet Date: Tue May 20 18:42:09 2008 New Revision: 135670 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135670 Log: PR middle-end/36194 * combine.c (check_conversion): Rename to check_promoted_subreg. Don't call record_truncated_value from here. (record_truncated_value): Turn it into a for_each_rtx callback. (record_truncated_values): New function. (combine_instructions): Call note_uses with record_truncated_values. Change name of check_conversion to check_promoted_subreg. testsuite/ * gcc.dg/pr36194.c: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/gcc.dg/pr36194.c Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/combine.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36194
[Bug testsuite/36057] [4.3/4.4 Regression] struct-layout-1_generate.c uses non-ISO C '%n$' operand number formats
--- Comment #6 from uros at gcc dot gnu dot org 2008-05-20 19:02 --- Subject: Bug 36057 Author: uros Date: Tue May 20 19:01:46 2008 New Revision: 135671 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135671 Log: PR testsuite/36057 * g++.dg/compat/struct-layout-1_generate.c (DG_OPTIONS): Remove. (const char *dg_options): New array. (switchfiles): Loop through dg_options array to generate dg-options directives. Remove numbered arguments usage from fprintf format strings. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/compat/struct-layout-1_generate.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36057
[Bug testsuite/36057] [4.4 Regression] struct-layout-1_generate.c uses non-ISO C '%n$' operand number formats
--- Comment #7 from ubizjak at gmail dot com 2008-05-20 19:06 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Summary|[4.3/4.4 Regression] struct-|[4.4 Regression] struct- |layout-1_generate.c uses |layout-1_generate.c uses |non-ISO C '%n$' operand |non-ISO C '%n$' operand |number formats |number formats Target Milestone|4.3.1 |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36057
[Bug tree-optimization/36181] Simple for loop generates ICE with -ftree-parallelize-loops=2
--- Comment #2 from spop at gcc dot gnu dot org 2008-05-20 19:17 --- Subject: Bug 36181 Author: spop Date: Tue May 20 19:17:12 2008 New Revision: 135673 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135673 Log: 2008-05-20 Sebastian Pop <[EMAIL PROTECTED]> Jan Sjodin <[EMAIL PROTECTED]> PR tree-optimization/36181 * tree-parloops.c (loop_has_vector_phi_nodes): New. (parallelize_loops): Don't parallelize when the loop has vector phi nodes. * gcc.dg/tree-ssa/pr36181.c: New. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr36181.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-parloops.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36181
[Bug tree-optimization/36181] Simple for loop generates ICE with -ftree-parallelize-loops=2
--- Comment #3 from spop at gcc dot gnu dot org 2008-05-20 19:23 --- Fixed. -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36181
[Bug tree-optimization/36281] New: vectorized code not parallelized
The testcase of PR36181 should be parallelized after being vectorized.
/* { dg-do compile } */
/* { dg-options "-O3 -ftree-parallelize-loops=2" } */
int foo ()
{
int i, sum = 0, data[1024];
for(i = 0; i<1024; i++)
sum += data[i];
return sum;
}
The fix for PR36181 was to disable the parallelization of a loop when
one of the phi nodes had a vector type. This testcase should also be
parallelized. See also the comments from the fix for PR36181:
http://gcc.gnu.org/ml/gcc-patches/2008-05/msg01217.html
--
Summary: vectorized code not parallelized
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: spop at gcc dot gnu dot org
ReportedBy: spop at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36281
[Bug tree-optimization/36281] vectorized code not parallelized
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-20 19:42 ---
Even worse:
#define vector __attribute__((vector_size(16) ))
vector int foo ()
{
vector int i, sum = 0, data[1024];
for(i = 0; i<1024; i++)
sum += data[i];
return sum;
}
With -O2 -ftree-parallelize-loops=2, this does not get parallelized at all even
though we did not run the vectorizer.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36281
[Bug c/36282] New: Spurious warning "asm declaration ignored due to conflict with previous rename"
Just run "gcc -c test.c" on this:
#pragma weak __pthread_initialize
extern void *memcpy (void *__restrict __dest,
__const void *__restrict __src, int __n)
__attribute__ ((__nothrow__)) __attribute__ ((__nonnull__ (1, 2)));
extern __typeof (memcpy) memcpy __asm__ ("" "__GI_memcpy") __attribute__
((visibility ("hidden")));
void f(void) {}
$ gcc -c test.c
test.c:5: warning: asm declaration ignored due to conflict with previous rename
With "#pragma weak __pthread_initialize" line commented out, it does not
happen.
$ gcc -v
Using built-in specs.
Target: i386-pc-linux-gnu
Configured with: ../gcc-4.2.1/configure --prefix=/usr/app/gcc-4.2.1
--exec-prefix=/usr/app/gcc-4.2.1 --bindir=/usr/bin --sbindir=/usr/sbin
--libexecdir=/usr/app/gcc-4.2.1/libexec --datadir=/usr/app/gcc-4.2.1/share
--sysconfdir=/etc --sharedstatedir=/usr/app/gcc-4.2.1/var/com
--localstatedir=/usr/app/gcc-4.2.1/var --libdir=/usr/lib
--includedir=/usr/include --infodir=/usr/info --mandir=/usr/man
--with-slibdir=/usr/app/gcc-4.2.1/lib --with-local-prefix=/usr/local
--with-gxx-include-dir=/usr/app/gcc-4.2.1/include/g++-v3
--enable-languages=c,c++ --without-system-zlib --disable-nls
--enable-threads=posix i386-pc-linux-gnu
Thread model: posix
gcc version 4.2.1
--
Summary: Spurious warning "asm declaration ignored due to
conflict with previous rename"
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vda dot linux at googlemail dot com
GCC build triplet: i386-pc-linux-gnu
GCC host triplet: i386-pc-linux-gnu
GCC target triplet: i386-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36282
[Bug middle-end/36282] Spurious warning "asm declaration ignored due to conflict with previous rename"
--- Comment #1 from vda dot linux at googlemail dot com 2008-05-20 19:48
---
Simplified case:
#pragma weak __pthread_initialize
extern void *memcpy(void *dest, const void *src, int n);
extern typeof(memcpy) memcpy asm("__GI_memcpy");
void f(void) {}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36282
[Bug ada/30740] Improper semantics in gnat's compilation of certain expressions involving modular arithmetic
--- Comment #6 from sam at gcc dot gnu dot org 2008-05-20 20:25 --- Subject: Bug 30740 Author: sam Date: Tue May 20 20:24:33 2008 New Revision: 135675 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135675 Log: gcc/testsuite/ PR ada/30740 * gnat.dg/modular.adb: New test. Added: trunk/gcc/testsuite/gnat.dg/modular.adb Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30740
[Bug fortran/36167] ICE in gfc_conv_descriptor_dimension, at fortran/trans-array.c:242
--- Comment #4 from fmuldoo at me dot lsu dot edu 2008-05-20 20:40 --- Subject: Re: ICE in gfc_conv_descriptor_dimension, at fortran/trans-array.c:242 Hi Paul, Thanks for the work-around. I now have got my code built using gfortran. Frank On Sat, 2008-05-17 at 16:20 +, pault at gcc dot gnu dot org wrote: > > --- Comment #2 from pault at gcc dot gnu dot org 2008-05-17 16:20 --- > (In reply to comment #1) > > Created an attachment (id=15589) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15589&action=view) > --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15589&action=view) [edit] > > Very small code example > > > Frank, > > The problem arises because of the declaration of 'u' in 'overlap_1. gfortran > declares automatic arrays to be array types in TREE-SSA. For some reason, the > interface code in the function code is barfing when it tries to set the > dimensions of the result. The interface is assuming that there is a > descriptor > available for 'u' and this generates the ICE. I will investigate because it > is > legal code. In the mean time, a workaround is to declare 'u' as assumed > shape, > thusly: > > real, intent(in), dimension(:,:,:) :: u > > This forces the array to be represented as descriptor type and does not lose > anything from your code. It also is a bit easier on the eye:) > > Thanks for the report. > > Paul > > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36167
[Bug middle-end/35204] [4.3/4.4 Regression] crash by too deep recursion in DFS tree-ssa-sccvn.c:1898
--- Comment #27 from rguenth at gcc dot gnu dot org 2008-05-20 20:41 --- Subject: Bug 35204 Author: rguenth Date: Tue May 20 20:40:23 2008 New Revision: 135676 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135676 Log: 2008-05-20 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/35204 * tree-ssa-sccvn.c (extract_and_process_scc_for_name): New helper, split out from ... (DFS): ... here. Make the DFS walk non-recursive. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-sccvn.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35204
[Bug objc/36283] New: When a class method, pointed by id, returns float, it returns wrong value
(I don't know if this happens only to gcc 3.4.5 from the MingW and if it was
solved already in newer versions.)
I made two classes inherited from a common parent class in Objective-C.
The two children classes have methods, "- (float) data" and "- (int) data"
respectively. They are for returning data value contained in each classes, or
more accurately, their class instances.
I would like to show a code example.
@implementation GFloat : Generics
- (id) add:(id) aVal
{
float value, value2;
int value3;
value = [aVal data]; // This can't return a float value in "aVal"
correctly.
value2 = returnFloat(); // C function returns a float value correctly.
value3 = returnInt(); // C function returns a int value correctly.
printf("%f, %f and %d\n", value, value2, value3);
The method, "add", takes the aVal as an id type.
By sending "data" message to aVal, it calls GFloat's data method successfully.
So, inside of the data method/message, correct data value is fetched and
returned. However, from the caller's line, which is shown above, the returned
value is something other than what the "data" message returned.
When the aVal is casted to (GFloat *), its returned value is correct.
Is it weird because it returns wrong value although correct method is called.
I would like to test the code at home with my MacOS X machine.
--
Summary: When a class method, pointed by id, returns float, it
returns wrong value
Product: gcc
Version: 3.4.5
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: objc
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jongampark at sbcglobal dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36283
[Bug ada/35791] [Ada] V-table messed up with interface composition
--- Comment #2 from sam at gcc dot gnu dot org 2008-05-20 20:46 --- Subject: Bug 35791 Author: sam Date: Tue May 20 20:45:49 2008 New Revision: 135677 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135677 Log: gcc/testsuite/ PR ada/35791 * gnat.dg/check_displace_generation.adb: New. Added: trunk/gcc/testsuite/gnat.dg/check_displace_generation.adb Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35791
[Bug target/35658] [4.3/4.4 regression] Bad interaction on ia64 between -funroll-loops -fno-automatic -O2 and common block variable
--- Comment #2 from sje at cup dot hp dot com 2008-05-20 20:50 --- I cannot reproduce this error. I have compiled the test case with various options and always get output that includes Test# 1 ( C201 ): *** failed *** and Test# 1 ( GENT ): *** failed *** I get this when I use -fno-automatic -O2 -funroll-loops and when I use no optimization at all. This is with GCC 4.3 released bits and ToT bits on a Debian 3.1 IA64 system. -- sje at cup dot hp dot com changed: What|Removed |Added CC||sje at cup dot hp dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35658
[Bug ada/35791] [Ada] V-table messed up with interface composition
--- Comment #3 from sam at gcc dot gnu dot org 2008-05-20 20:55 --- This has been fixed by SVN commit 135638: 2008-05-20 Javier Miranda <[EMAIL PROTECTED]> Ed Schonberg <[EMAIL PROTECTED]> Hristian Kirtchev <[EMAIL PROTECTED]> * sem_ch3.adb (Analyze_Object_Declaration): Fix over-conservative condition restricting use of predefined assignment with tagged types that have convention CPP. (Analyze_Object_Declaration): Relax the check regarding deferred constants declared in scopes other than packages since they can be completed with pragma Import. Add missing escaping of all-caps word 'CPP' in error messages. (Build_Discriminated_Subtype): Do not inherit representation clauses from parent type if subtype already carries them, because they are inherited earlier during derivation and already include those that may come from a partial view. -- sam 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=35791
[Bug middle-end/35204] [4.3/4.4 Regression] crash by too deep recursion in DFS tree-ssa-sccvn.c:1898
--- Comment #28 from rguenth at gcc dot gnu dot org 2008-05-20 20:58 --- Subject: Bug 35204 Author: rguenth Date: Tue May 20 20:57:12 2008 New Revision: 135678 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135678 Log: 2008-05-20 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/35204 * tree-ssa-sccvn.c (extract_and_process_scc_for_name): New helper, split out from ... (DFS): ... here. Make the DFS walk non-recursive. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/tree-ssa-sccvn.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35204
[Bug middle-end/35204] [4.3/4.4 Regression] crash by too deep recursion in DFS tree-ssa-sccvn.c:1898
--- Comment #29 from rguenth at gcc dot gnu dot org 2008-05-20 20:58 --- 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=35204
[Bug target/35659] [4.3/4.4 Regression] Miscompiled code with -O2 (but not with -O2 -funroll-loops) on ia64
--- Comment #4 from sje at cup dot hp dot com 2008-05-20 21:01 --- I wonder if this is related to PR target/35695, the floating point division bug that Jim Wilson fixed. Could you try it with ToT or with the latest 4.3 branch, both of which have Jim's fix in them. -- sje at cup dot hp dot com changed: What|Removed |Added CC||sje at cup dot hp dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35659
[Bug objc/36283] When a class method, pointed by id, returns float, it returns wrong value
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-20 21:02 --- Actually I don't think this is a bug. What is happening is the id is a generic class type so the compiler needs to decide at compile time what the type is being returned. In this case it decides on the one the user did not want. The cast will chose the correct one. Now at runtime is selects the correct type but of course by the time you get there it is already messed up. -- Pinski -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36283
[Bug tree-optimization/34330] -ftree-parallelize-loops=4 ICE with the vectorizer also
--- Comment #16 from rguenth at gcc dot gnu dot org 2008-05-20 21:04 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|4.4.0 |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34330
[Bug middle-end/36244] -ftree-parallelize-loops=4, vectorizer enabled, ICE
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-05-20 21:04 --- Subject: Bug 36244 Author: rguenth Date: Tue May 20 21:03:59 2008 New Revision: 135680 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135680 Log: 2008-05-20 Richard Guenther <[EMAIL PROTECTED]> Backport from mainline: 2008-05-15 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/34330 * tree-ssa-alias.c (get_smt_for): Only assert that accesses through the pointer will alias the SMT. * gcc.dg/torture/pr34330.c: New testcase. PR middle-end/36244 * tree-ssa-alias.c (new_type_alias): Do not set TREE_READONLY. * tree-flow-inline.h (unmodifiable_var_p): Memory tags never represent unmodifiable vars. * gcc.dg/torture/pr36244.c: New testcase. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/torture/pr34330.c - copied unchanged from r135329, trunk/gcc/testsuite/gcc.dg/torture/pr34330.c branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/torture/pr36244.c - copied unchanged from r135336, trunk/gcc/testsuite/gcc.dg/torture/pr36244.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/testsuite/ChangeLog branches/gcc-4_3-branch/gcc/tree-flow-inline.h branches/gcc-4_3-branch/gcc/tree-ssa-alias.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36244
[Bug middle-end/36244] -ftree-parallelize-loops=4, vectorizer enabled, ICE
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-05-20 21:04 --- Subject: Bug 36244 Author: rguenth Date: Tue May 20 21:03:59 2008 New Revision: 135680 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135680 Log: 2008-05-20 Richard Guenther <[EMAIL PROTECTED]> Backport from mainline: 2008-05-15 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/34330 * tree-ssa-alias.c (get_smt_for): Only assert that accesses through the pointer will alias the SMT. * gcc.dg/torture/pr34330.c: New testcase. PR middle-end/36244 * tree-ssa-alias.c (new_type_alias): Do not set TREE_READONLY. * tree-flow-inline.h (unmodifiable_var_p): Memory tags never represent unmodifiable vars. * gcc.dg/torture/pr36244.c: New testcase. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/torture/pr34330.c - copied unchanged from r135329, trunk/gcc/testsuite/gcc.dg/torture/pr34330.c branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/torture/pr36244.c - copied unchanged from r135336, trunk/gcc/testsuite/gcc.dg/torture/pr36244.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/testsuite/ChangeLog branches/gcc-4_3-branch/gcc/tree-flow-inline.h branches/gcc-4_3-branch/gcc/tree-ssa-alias.c --- Comment #8 from rguenth at gcc dot gnu dot org 2008-05-20 21:05 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|4.4.0 |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36244
[Bug tree-optimization/34330] -ftree-parallelize-loops=4 ICE with the vectorizer also
--- Comment #17 from rguenth at gcc dot gnu dot org 2008-05-20 21:05 --- Subject: Bug 34330 Author: rguenth Date: Tue May 20 21:03:59 2008 New Revision: 135680 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135680 Log: 2008-05-20 Richard Guenther <[EMAIL PROTECTED]> Backport from mainline: 2008-05-15 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/34330 * tree-ssa-alias.c (get_smt_for): Only assert that accesses through the pointer will alias the SMT. * gcc.dg/torture/pr34330.c: New testcase. PR middle-end/36244 * tree-ssa-alias.c (new_type_alias): Do not set TREE_READONLY. * tree-flow-inline.h (unmodifiable_var_p): Memory tags never represent unmodifiable vars. * gcc.dg/torture/pr36244.c: New testcase. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/torture/pr34330.c - copied unchanged from r135329, trunk/gcc/testsuite/gcc.dg/torture/pr34330.c branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/torture/pr36244.c - copied unchanged from r135336, trunk/gcc/testsuite/gcc.dg/torture/pr36244.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/testsuite/ChangeLog branches/gcc-4_3-branch/gcc/tree-flow-inline.h branches/gcc-4_3-branch/gcc/tree-ssa-alias.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34330
[Bug objc/36283] When a class method, pointed by id, returns float, it returns wrong value
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-05-20 21:05 --- Try using -Wstrict-selector-match and see what you get. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36283
[Bug testsuite/29071] gcc.dg/20020919-1.c compilation test fails on powerpc-apple-darwin8 at -m64
--- Comment #4 from janis at gcc dot gnu dot org 2008-05-20 21:45 --- Isn't the proposal in comment #3 the same as this? Index: gcc/testsuite/gcc.dg/20020919-1.c === --- gcc/testsuite/gcc.dg/20020919-1.c (revision 135322) +++ gcc/testsuite/gcc.dg/20020919-1.c (working copy) @@ -41,7 +41,7 @@ || defined (__POWERPC__) || defined (PPC) || defined (_IBMR2) # define REG1 "6" # define REG2 "7" -# ifndef __powerpc64__ +# if !defined(__powerpc64__) && !defined(__LP64__) # define REG3 "8" # define REG4 "9" # endif We already know that this part is true: defined (__powerpc__) || defined (__PPC__) || defined (__ppc__) \ || defined (__POWERPC__) || defined (PPC) || defined (_IBMR2) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29071
[Bug testsuite/36284] New: gcc.dg-struct-layout fails AVR target - multiple reasons
gcc/testsuite/gcc/gcc.dg-struct-layout-1 fails multiple times for AVR target due to non-portable testcase. This test has 28 generated variants, all fail. Problems include: 1)Assumes int are 32 bit gcc/gcc.dg-struct-layout-1//t001_test.h:119: error: width of 'a' 2) Assumes availability of DF mode gcc.dg/compat/vector-defs.h:9: error: unable to emulate 'DF' 3) Some undefined problem - maybe size >32767? short_enums30131.c:3: error: size of array 's' is negative I will post snippet of log file to aid correction. -- Summary: gcc.dg-struct-layout fails AVR target - multiple reasons Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hutchinsonandy at aim dot com GCC host triplet: i686-pc-linux-gnu GCC target triplet: avr-unknown-none http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36284
[Bug testsuite/36284] gcc.dg-struct-layout fails AVR target - multiple reasons
--- Comment #1 from hutchinsonandy at aim dot com 2008-05-20 22:41 --- Created an attachment (id=15658) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15658&action=view) Extract from gcc.log Extract from gcc.log showing failure details. For economy, not all 28 tests are shown. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36284
[Bug testsuite/36285] New: gcc.dg/compat/struct-by-value-xxx improper test for AVR target
Most of the 21 variants of this test fail for AVR target. Issue noted appears to be excessive memory need and thus failure at link time. For example. PASS: gcc.dg/compat/struct-by-value-11 c_compat_y_tst.o compile Executing on host: /home/hutchia/Desktop/awhconf/gcc/xgcc -B/home/hutchia/Desktop/awhconf/gcc/ c_compat_main_tst.o c_compat_x_tst.o c_compat_y_tst.o-DSTACK_SIZE=2048 -DNO_TRAMPOLINES -fno-show-column -DSIGNAL_SUPPRESS -mmcu=atmega128 /home/hutchia/Desktop/dejagnuboards/exit.c -Wl,-u,vfprintf -lprintf_flt -Wl,-Tbss=0x802000,--defsym=__heap_end=0x80 -lm -o gcc-dg-compat-struct-by-value-11-01(timeout = 300) /home/hutchia/local/avr/lib/gcc/avr/4.4.0/../../../../avr/bin/ld: gcc-dg-compat-struct-by-value-11-01 section .text will not fit in region text /home/hutchia/local/avr/lib/gcc/avr/4.4.0/../../../../avr/bin/ld: region text overflowed by 353496 bytes compiler exited with status 1 output is: /home/hutchia/local/avr/lib/gcc/avr/4.4.0/../../../../avr/bin/ld: gcc-dg-compat-struct-by-value-11-01 section .text will not fit in region text /home/hutchia/local/avr/lib/gcc/avr/4.4.0/../../../../avr/bin/ld: region text overflowed by 353496 bytes -- Summary: gcc.dg/compat/struct-by-value-xxx improper test for AVR target Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hutchinsonandy at aim dot com GCC host triplet: i686-pc-linux-gnu GCC target triplet: avr-unknown-none http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36285
[Bug testsuite/22523] template/inline1.C does not test correctly on all targerts
--- Comment #2 from janis at gcc dot gnu dot org 2008-05-20 23:32 --- Subject: Bug 22523 Author: janis Date: Tue May 20 23:31:40 2008 New Revision: 135691 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135691 Log: PR testsuite/22523 * g++.dg/template/inline1.C: Handle syntax for more assemblers. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/template/inline1.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22523
[Bug testsuite/34889] gcc.c-torture/execute/builtins/pr23484-chk.c fails on 16 bit integer platforms
--- Comment #3 from hutchinsonandy at gcc dot gnu dot org 2008-05-20 23:57 --- Subject: Bug 34889 Author: hutchinsonandy Date: Tue May 20 23:56:28 2008 New Revision: 135694 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135694 Log: PR testsuite/34889 * gcc.c-torture/execute/builtins/pr23484-chk.c : Correct test for 16bit int target. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.c-torture/execute/builtins/pr23484-chk.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34889
[Bug testsuite/20771] Duplicate PCH test names
--- Comment #4 from janis at gcc dot gnu dot org 2008-05-21 00:05 --- Subject: Bug 20771 Author: janis Date: Wed May 21 00:04:45 2008 New Revision: 135696 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135696 Log: PR testsuite/20771 * lib/dg-pch.exp: Move a flag in arguments to dg-test to differentiate compile results for pch test lines in gcc.sum. * gcc.dg/pch/counter-2.c: Add comments to dg-error directives to make them unique in gcc.sum. * gcc.dg/pch/valid-1.c: Ditto. * gcc.dg/pch/valid-2.c: Ditto. * gcc.dg/pch/valid-3.c: Ditto. * gcc.dg/pch/warn-1.c: Same for dg-warning. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/pch/counter-2.c trunk/gcc/testsuite/gcc.dg/pch/valid-1.c trunk/gcc/testsuite/gcc.dg/pch/valid-2.c trunk/gcc/testsuite/gcc.dg/pch/valid-3.c trunk/gcc/testsuite/gcc.dg/pch/warn-1.c trunk/gcc/testsuite/lib/dg-pch.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20771
