gcc-bug-report- Tuesday May 08 - Portugal
According to http://gcc.gnu.org/bugs.html here is what is requested for a bug report. Regards, Miguel Luis. ## the exact version of GCC; $ gcc --version gcc (GCC) 4.1.2 (Ubuntu 4.1.2-0ubuntu4) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ ## the system type; $ uname -a Linux m0x 2.6.20-15-386 #2 Sun Apr 15 07:34:00 UTC 2007 i686 GNU/Linux $ ## the options given when GCC was configured/built; - Sorry but this is a binary package of gcc installed with build-essentials package in ubuntu and I don't know how to answer ## the complete command line that triggers the bug; $gcc -v -save-temps -c -g -ansi -Wall -O3 system.c ## the compiler output (error messages, warnings, etc.); $ make gcc -v -save-temps -c -g -ansi -Wall -O3 system.c Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-checking=release i486-linux-gnu Thread model: posix gcc version 4.1.2 (Ubuntu 4.1.2-0ubuntu4) /usr/lib/gcc/i486-linux-gnu/4.1.2/cc1 -E -quiet -v system.c -mtune=generic -ansi -Wall -fworking-directory -O3 -fpch-preprocess -o system.i ignoring nonexistent directory /usr/local/include/i486-linux-gnu ignoring nonexistent directory /usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../i486-linux-gnu/include ignoring nonexistent directory /usr/include/i486-linux-gnu #include ... search starts here: #include ... search starts here: /usr/local/include /usr/lib/gcc/i486-linux-gnu/4.1.2/include /usr/include End of search list. /usr/lib/gcc/i486-linux-gnu/4.1.2/cc1 -fpreprocessed system.i -quiet -dumpbase system.c -mtune=generic -ansi -auxbase system -g -O3 -Wall -ansi -version -fstack-protector -fstack-protector -o system.s GNU C version 4.1.2 (Ubuntu 4.1.2-0ubuntu4) (i486-linux-gnu) compiled by GNU C version 4.1.2 (Ubuntu 4.1.2-0ubuntu4). GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=129470 Compiler executable checksum: c0d954aeefbb96d795ff3f6b3b72ef51 system.c: In function ‘system_verbose’: system.c:80: warning: implicit declaration of function ‘get_item_id_max_lenght’ system.c:80: internal compiler error: in fold_convert, at fold-const.c:1956 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. For Debian GNU/Linux specific bug reporting instructions, see URL:file:///usr/share/doc/gcc-4.1/README.Bugs. Preprocessed source stored into /tmp/ccWfv49C.out file, please attach this to your bugreport. make: *** [system.o] Error 1 $ ## the /preprocessed/ file (|*.i*|) that triggers the bug, generated by adding |-save-temps| to the complete compilation command # 1 system.c # 1 /home/myk0n/symlink/xrtdb/current// # 1 built-in # 1 command line # 1 system.c # 1 /usr/include/stdio.h 1 3 4 # 28 /usr/include/stdio.h 3 4 # 1 /usr/include/features.h 1 3 4 # 323 /usr/include/features.h 3 4 # 1 /usr/include/sys/cdefs.h 1 3 4 # 313 /usr/include/sys/cdefs.h 3 4 # 1 /usr/include/bits/wordsize.h 1 3 4 # 314 /usr/include/sys/cdefs.h 2 3 4 # 324 /usr/include/features.h 2 3 4 # 346 /usr/include/features.h 3 4 # 1 /usr/include/gnu/stubs.h 1 3 4 # 1 /usr/include/bits/wordsize.h 1 3 4 # 5 /usr/include/gnu/stubs.h 2 3 4 # 1 /usr/include/gnu/stubs-32.h 1 3 4 # 8 /usr/include/gnu/stubs.h 2 3 4 # 347 /usr/include/features.h 2 3 4 # 29 /usr/include/stdio.h 2 3 4 # 1 /usr/lib/gcc/i486-linux-gnu/4.1.2/include/stddef.h 1 3 4 # 214 /usr/lib/gcc/i486-linux-gnu/4.1.2/include/stddef.h 3 4 typedef unsigned int size_t; # 35 /usr/include/stdio.h 2 3 4 # 1 /usr/include/bits/types.h 1 3 4 # 28 /usr/include/bits/types.h 3 4 # 1 /usr/include/bits/wordsize.h 1 3 4 # 29 /usr/include/bits/types.h 2 3 4 # 1 /usr/lib/gcc/i486-linux-gnu/4.1.2/include/stddef.h 1 3 4 # 32 /usr/include/bits/types.h 2 3 4 typedef unsigned char __u_char; typedef unsigned short int __u_short; typedef unsigned int __u_int; typedef unsigned long int __u_long; typedef signed char __int8_t; typedef unsigned char __uint8_t; typedef signed short int __int16_t; typedef unsigned short int __uint16_t; typedef signed int __int32_t; typedef unsigned int __uint32_t; __extension__ typedef signed long long int __int64_t; __extension__ typedef unsigned long long int __uint64_t; __extension__ typedef long long int __quad_t; __extension__ typedef unsigned long long int __u_quad_t; # 134 /usr/include/bits/types.h 3 4 # 1 /usr/include/bits/typesizes.h 1 3 4 # 135 /usr/include/bits/types.h 2 3 4 __extension__ typedef __u_quad_t __dev_t; __extension__ typedef unsigned int __uid_t; __extension__ typedef
[Bug other/31858] Hey gcc-bugs@ does not recieve this bug
--- Comment #7 from cgf at gcc dot gnu dot org 2007-05-08 13:04 --- reverting spamassassin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31858
[Bug other/31858] Hey gcc-bugs@ does not recieve this bug
--- Comment #8 from cgf at gcc dot gnu dot org 2007-05-08 13:06 --- I reverted spamassassin to v3.1.8. Comments on the net seemed to indicate that 3.2.0 was slower anyway and it certainly doesn't seem ready for prime time yet. -- cgf at gcc dot gnu dot org changed: What|Removed |Added CC||overseers at gcc dot gnu dot ||org Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31858
[Bug tree-optimization/31866] New: [4.3 Regression] ICE with tree check error: expected ssa_name, have var_decl in create_outofssa_var_map
With -O1, the following testcase
int
foo (void)
{
return ({
unsigned int resultvar = ({
long int arg = (long int) 0;
register long int reg asm (eax) = arg;
asm volatile (nop
: =a (resultvar)
: 0 (reg)
:memory);
(int) resultvar;});
(int) resultvar;});
}
fails with an ICE:
foo.c: In function 'foo':
foo.c:3: internal compiler error: tree check: expected ssa_name, have var_decl
in create_outofssa_var_map, at tree-ssa-coalesce.c:1051
--
Summary: [4.3 Regression] ICE with tree check error: expected
ssa_name, have var_decl in create_outofssa_var_map
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-checking
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kkojima at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31866
[Bug fortran/31692] Wrong code when passing function name as result to procedures
--- Comment #5 from pault at gcc dot gnu dot org 2007-05-08 13:45 --- Subject: Bug 31692 Author: pault Date: Tue May 8 12:45:31 2007 New Revision: 124546 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124546 Log: 2007-05-08 Paul Thomas [EMAIL PROTECTED] PR fortran/31692 * trans-array.c (gfc_conv_array_parameter): Convert full array references to the result of the procedure enclusing the call. 2007-05-08 Paul Thomas [EMAIL PROTECTED] PR fortran/31692 * gfortran.dg/actual_array_result_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/actual_array_result_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31692
[Bug fortran/31692] Wrong code when passing function name as result to procedures
--- Comment #6 from pault at gcc dot gnu dot org 2007-05-08 13:49 --- Fixed on trunk Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31692
[Bug fortran/30876] Array valued recursive function rejected
--- Comment #7 from pault at gcc dot gnu dot org 2007-05-08 13:51 --- I'll submit a fix tonight. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30876
[Bug fortran/30878] Rejects function f1; namelist /nml/ f1
--- Comment #3 from pault at gcc dot gnu dot org 2007-05-08 13:51 --- I'll submit a fix tonight. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-03-23 21:41:09 |2007-05-08 13:51:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30878
[Bug fortran/30876] Array valued recursive function rejected
--- Comment #8 from pault at gcc dot gnu dot org 2007-05-08 13:52 --- Oops! -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30876
[Bug fortran/30876] Array valued recursive function rejected
-- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|REOPENED|ASSIGNED Last reconfirmed|2007-02-21 17:03:09 |2007-05-08 13:53:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30876
[Bug tree-optimization/31862] Loop IM and other optimizations harmful for -fopenmp
--- Comment #1 from dnovillo at acm dot org 2007-05-08 14:10 --- Subject: Re: New: Loop IM and other optimizations harmful for -fopenmp On 8 May 2007 07:59:03 -, jakub at gcc dot gnu dot org [EMAIL PROTECTED] wrote: See http://openmp.org/pipermail/omp/2007/000840.html and the rest of the lengthy threads: Yes, I've been following the thread and I agree that we need to do something to avoid the problem. The real solution is, unfortunately, quite a bit of work. In the meantime, we should probably annotate the shared variables and consider them volatile. This should prevent most optimizers from messing things up inadvertently. This should be done within OMP regions. Orphaned functions may become a problem, so this should be implemented as an IPA pass. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31862
[Bug target/27067] Compile errors with multiple inheritance where the stdcall attribute is applied to virtual functions.
--- Comment #12 from angray at beeb dot net 2007-05-08 15:07 --- (In reply to comment #11) MSC includes the calling convention as part of its C++ name mangling. Would this bug be easier to solve if the calling convention was also included as part of the C++ name mangling in GCC, instead of done afterwards? If so, it might be worth this small ABI breaking change in some future release of MinGW. Does this bug effect Firefox and Thunderbirds XPCOM ? Aaron -- angray at beeb dot net changed: What|Removed |Added CC||angray at beeb dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27067
[Bug tree-optimization/31862] Loop IM and other optimizations harmful for -fopenmp
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-08 15:30 --- WTF, this is just sad we have to disable optimizations because openmp folks don't know how to program threaded code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31862
[Bug tree-optimization/31866] [4.3 Regression] ICE with tree check error: expected ssa_name, have var_decl in create_outofssa_var_map
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Keywords||ice-on-valid-code Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31866
[Bug c++/986] g++ misses warning for on temporary
--- Comment #13 from bangerth at dealii dot org 2007-05-08 15:34 --- (In reply to comment #12) The summary says g++ misses warning for on temporary. But something that is always an error can be called a warning? The point is that the standard doesn't call it an error, but undefined behavior. It's perfectly legal to keep a reference to a temporary, it may just not yield the result you had hoped for. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=986
[Bug c++/31860] Spurious error on udecl to class 'n' with object 'n' in the current scope
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-05-08 15:35 --- EDG accepts this. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||rejects-valid http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31860
[Bug middle-end/31865] Internal compiler error: in build_int_cst_wide, at tree.c:864 when compiling MPlayer from SVN
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-05-08 15:36 --- *** This bug has been marked as a duplicate of 31793 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c |middle-end Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31865
[Bug middle-end/31793] [4.3 Regression] internal compiler error in build_int_cst_wide tree.c:902
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-05-08 15:36 --- *** Bug 31865 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||ismail at pardus dot org dot ||tr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31793
[Bug tree-optimization/31862] Loop IM and other optimizations harmful for -fopenmp
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-05-08 15:37 --- OMP is not a good generic programming model for threaded code. Exactly because of this issues. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31862
[Bug tree-optimization/31862] Loop IM and other optimizations harmful for -fopenmp
--- Comment #4 from dnovillo at acm dot org 2007-05-08 15:39 --- Subject: Re: Loop IM and other optimizations harmful for -fopenmp On 8 May 2007 14:30:45 -, pinskia at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-08 15:30 --- WTF, this is just sad we have to disable optimizations because openmp folks don't know how to program threaded code. No need to be insulting. Another possibility is to require shared variables to be declared volatile. It depends on the wording in the standard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31862
[Bug fortran/31630] [4.3 regression] ICE on nasty derived types code
--- Comment #6 from pault at gcc dot gnu dot org 2007-05-08 15:41 --- Subject: Bug 31630 Author: pault Date: Tue May 8 14:40:58 2007 New Revision: 124550 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124550 Log: 2007-05-08 Paul Thomas [EMAIL PROTECTED] PR fortran/31630 * resolve.c (resolve_symbol): Remove the flagging mechanism from the formal namespace resolution and instead check that the formal namespace is not the current namespace. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31630
[Bug tree-optimization/31862] Loop IM and other optimizations harmful for -fopenmp
--- Comment #5 from dnovillo at acm dot org 2007-05-08 15:44 --- Subject: Re: Loop IM and other optimizations harmful for -fopenmp On 8 May 2007 14:37:05 -, rguenth at gcc dot gnu dot org [EMAIL PROTECTED] wrote: OMP is not a good generic programming model for threaded code. Exactly because of this issues. No. This is wrong. The model simply requires the compiler to be smarter. Sequential compilers are not aware of parallel semantics. If the compiler was thread-aware, these issues would be transparent to the user (as they should be). The original code did not have a race condition. The compiler transformations introduced a race-condition. This *is* a compiler bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31862
[Bug tree-optimization/31863] g++-4.1: out of memory with -O1/-O2
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-05-08 15:45 --- Created an attachment (id=13530) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13530action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31863
[Bug tree-optimization/31863] g++-4.1: out of memory with -O1/-O2
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-05-08 15:47 --- This is related to PR29433, but still unresolved. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||compile-time-hog, memory-hog Known to fail||4.1.2 4.3.0 Last reconfirmed|-00-00 00:00:00 |2007-05-08 15:47:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31863
[Bug c++/31863] g++-4.1: out of memory with -O1/-O2
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-05-08 15:52 --- Until I killed cc1plus we have (mainline): samples %symbol name 5011528.3000 push_fields_onto_fieldstack 12370 6.9853 bitpos_of_field 10174 5.7453 tree_low_cst 8825 4.9835 host_integerp 5204 2.9387 walk_tree 3666 2.0702 pointer_set_insert 2434 1.3745 cp_walk_subtrees 2199 1.2418 comptypes 2039 1.1514 ggc_alloc_stat which suspiciously hints at aliasing...!? Need to go for a bigger machine... -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|tree-optimization |c++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31863
Re: [Bug tree-optimization/31862] Loop IM and other optimizations harmful for -fopenmp
On 8 May 2007 14:44:16 -, dnovillo at acm dot org [EMAIL PROTECTED] wrote: The original code did not have a race condition. The compiler transformations introduced a race-condition. This *is* a compiler bug. Actually the original code has a race condition, if another thread is reading from var and then acting on that and writting back. This is why threading programming is considered hard.
[Bug tree-optimization/31862] Loop IM and other optimizations harmful for -fopenmp
--- Comment #6 from pinskia at gmail dot com 2007-05-08 15:59 --- Subject: Re: Loop IM and other optimizations harmful for -fopenmp On 8 May 2007 14:44:16 -, dnovillo at acm dot org [EMAIL PROTECTED] wrote: The original code did not have a race condition. The compiler transformations introduced a race-condition. This *is* a compiler bug. Actually the original code has a race condition, if another thread is reading from var and then acting on that and writting back. This is why threading programming is considered hard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31862
[Bug c++/31863] g++-4.1: out of memory with -O1/-O2
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-05-08 16:01 --- cc1plus: out of memory allocating 1764584 bytes after a total of 16482304 bytes so this actually killed even the 16GB box. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31863
[Bug c++/31863] g++-4.1: out of memory with -O1/-O2
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-05-08 16:03 --- Danny, push_fields_onto_fieldstack is going crazy on this. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||dberlin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31863
[Bug libstdc++/21334] Lack of Posix compliant thread safety in std::basic_string
--- Comment #37 from james dot kanze at gmail dot com 2007-05-08 16:11 --- Subject: Re: Lack of Posix compliant thread safety in std::basic_string On 7 May 2007 21:08:05 -, gianni at mariani dot ws [EMAIL PROTECTED] wrote: --- Comment #35 from gianni at mariani dot ws 2007-05-07 22:08 --- Is this really a bug ? Any discussion in the upcoming standardization of threads that talks about calling a non-const begin() on a std::string ? If we take James's code and replace the g definition like so: std::string g_modifyable ; const std::string g = g_modifyable; ... there is no race condition. Who said that calling begin() on a non const std::string should be thread safe ? Posix and common sense. Just as using a char* (rather than a char const*) to access a char[] is thread safe. But let's not start that again. The ISO committee is discussing the issue, and will doubtlessly decide one way or another. (Before they get that far, they have to agree on what a thread means:-).) In the meantime, all of the other implementations work (but have other disadvantages); the g++ implementation doesn't. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334
[Bug libstdc++/21334] Lack of Posix compliant thread safety in std::basic_string
--- Comment #38 from james dot kanze at gmail dot com 2007-05-08 16:21 --- Subject: Re: Lack of Posix compliant thread safety in std::basic_string On 8 May 2007 05:24:35 -, gianni at mariani dot ws [EMAIL PROTECTED] wrote: --- Comment #36 from gianni at mariani dot ws 2007-05-08 06:24 --- BTW - you don't need a multi-threaded test to make this problem show up. The code below is plain old C++ and breaks. Again, I hesitate in calling this one a bug because begin() on a non-const object make be allowed to invalidate previous const iterators, I'm not sure. In this case, the standard specifically says that the code is invalid. (For all of the standard containers, the standard specifies what operations invalidate iterators.) If it is not allowed to then this is a legitimate bug - no threads needed. BTW, this test works on: Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.42 As does my example:-). Different implementations will behave differently. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334
[Bug c++/31863] g++-4.1: out of memory with -O1/-O2
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-05-08 16:21 --- Note the interesting debuggable testcase is if you remove from getInstance() all template params from ClassSpecKey, A020, 21 on. Around that one you'll clearly see exponential behavior in memory use ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31863
[Bug fortran/31867] New: function result with character LEN computed at run time
The program module util_mod implicit none contains function join(words,sep) result(str) ! trim and concatenate a vector of character variables, ! inserting sep between them character (len=*), intent(in):: words(:),sep character (len=(size(words)-1)*len(sep) + sum(len_trim(words))) :: str integer :: i,nw nw = size(words) str = if (nw 1) then return else str = words(1) end if do i=2,nw str = trim(str) // sep // words(i) end do end function join end module util_mod ! program xjoin use util_mod, only: join implicit none character (len=5) :: words(2) = (/two ,three/) write (*,(1x,'words = ',a)) '//join(words, )//' end program xjoin gives words = 'two threeg9' but I think it should give words = 'two three' gfortran -v says Using built-in specs. Target: i386-pc-mingw32 Configured with: ../trunk/configure --prefix=/mingw --enable-languages=c,fortran,c++,objc,obj-c++ --with-gmp=/home/coudert/local --disable-nls --with-ld=/mingw/bin/ld --with-as=/mingw/bin/as --disable-werror --enable-bootstrap --enable-threads --build=i386-pc-mingw32 --disable-shared --enable-libgomp Thread model: win32 gcc version 4.3.0 20070406 (experimental) -- Summary: function result with character LEN computed at run time Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: beliavsky at aol dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31867
[Bug tree-optimization/31847] [4.3 Regression] Printing to dump file broken
--- Comment #3 from simartin at gcc dot gnu dot org 2007-05-08 16:34 --- Subject: Bug 31847 Author: simartin Date: Tue May 8 15:33:56 2007 New Revision: 124551 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124551 Log: 2007-05-08 Simon Martin [EMAIL PROTECTED] PR 31847 * tree-dump.c (dump_options): Don't use TDF_DIAGNOSTIC in *-all tree dumps. Added: trunk/gcc/testsuite/gcc.dg/pr31847.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-dump.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31847
[Bug tree-optimization/31847] [4.3 Regression] Printing to dump file broken
--- Comment #4 from simartin at gcc dot gnu dot org 2007-05-08 16:47 --- This should be fixed (see http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00527.html for an explanation of the patch). -- simartin at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |simartin at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-05-08 16:47:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31847
[Bug c++/986] g++ misses warning for on temporary
--- Comment #14 from raf2 at msux dot cjb dot net 2007-05-08 17:18 --- I first was hit by an error using MinGW... when I compiled and executed the first attached file, it wrote: John drives a: bus Otto drives a: bus Which was wrong, I reported the bug and a guy from MinGW kindly explained that if it worked then that would be purely by accident and added: When you declare the argument without '' then it will make a temporary copy of the Automobile object on the stack, but it is wrong to store a reference to a temporary object because it will be invalid after the constructor returns.. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=986
[Bug c++/986] g++ misses warning for on temporary
--- Comment #15 from raf2 at msux dot cjb dot net 2007-05-08 17:22 --- Created an attachment (id=13531) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13531action=view) File with wrong code that leads to an unexpected result -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=986
[Bug c++/986] g++ misses warning for on temporary
--- Comment #16 from bangerth at dealii dot org 2007-05-08 17:25 --- (In reply to comment #14) Which was wrong, I reported the bug and a guy from MinGW kindly explained that if it worked then that would be purely by accident and added: When you declare the argument without '' then it will make a temporary copy of the Automobile object on the stack, but it is wrong to store a reference to a temporary object because it will be invalid after the constructor returns.. You misunderstand my point: the international C++ standard quite clearly specifies under what circumstances a program is what it calls ill-formed and when a compiler has to issue an error. Taking the address of a temporary is completely valid according to this standard (i.e. it conforms to the *syntax* of the C++ language), and consequently a compiler can't issue an error. The fact that the program does something you may not expect, i.e. that the *semantics* are not what you want, is an entirely different matter. In this case, the C++ standard says that the behavior of your program is undefined. Compilers may warn about this, but they may not issue an error. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=986
[Bug target/31868] New: Non-Linux DWARF EH x86-64 targets have broken crtend.o
X86-64 crtend.o with DWARF EH is broken when compiled with -fasynchronous-unwind-tables, which is the default: http://gcc.gnu.org/ml/gcc/2002-11/msg00799.html It was fixed for Linux only: http://gcc.gnu.org/ml/gcc-patches/2002-11/msg01671.html That leaves all non-Linux x86-64 with DWARF EH have a broken crtend.o. -- Summary: Non-Linux DWARF EH x86-64 targets have broken crtend.o Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31868
[Bug target/31868] Non-Linux DWARF EH x86-64 targets have broken crtend.o
--- Comment #1 from hjl at lucon dot org 2007-05-08 18:12 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00557.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31868
[Bug middle-end/31793] [4.3 Regression] internal compiler error in build_int_cst_wide tree.c:902
--- Comment #5 from ismail at pardus dot org dot tr 2007-05-08 18:48 --- I had to apply http://gcc.gnu.org/viewcvs?view=revrevision=122255 to the 4.2.0 branch to be able to bootstrap, else I get : from gcc-4.2.0-20070430/libstdc++-v3/include/precompiled/stdc++.h:71: gcc-4.2.0-20070430/build-default-i686-pc-linux-gnu/i686-pc-linux-gnu/libstdc++-v3/include/bits/stl_tree.h:337: error: declaration of 'typedef struct std::_Rb_tree_node_Val std::_Rb_tree_Key, _Val, _KeyOfValue, _Compare, _Alloc::_Rb_tree_node' gcc-4.2.0-20070430/build-default-i686-pc-linux-gnu/i686-pc-linux-gnu/libstdc++-v3/include/bits/stl_tree.h:134: error: changes meaning of '_Rb_tree_node' from 'struct std::_Rb_tree_node_Val' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31793
[Bug target/31868] Non-Linux DWARF EH x86-64 targets have broken crtend.o
--- Comment #2 from hjl at lucon dot org 2007-05-08 18:55 --- Patches against 4.1, 4.2 and 4.3 are at http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00563.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31868
[Bug middle-end/31793] [4.3 Regression] internal compiler error in build_int_cst_wide tree.c:902
--- Comment #6 from ismail at pardus dot org dot tr 2007-05-08 19:02 --- Never mind my last comment, it was a local patch causing the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31793
[Bug tree-optimization/31862] Loop IM and other optimizations harmful for -fopenmp
--- Comment #7 from jakub at gcc dot gnu dot org 2007-05-08 19:08 ---
This really is not specific to OpenMP, I believe the following is valid
threaded program:
#define _XOPEN_SOURCE 600
#include pthread.h
#include stdlib.h
int v;
pthread_mutex_t m = PTHREAD_MUTEX_INITIALIZER;
pthread_barrier_t b;
void
foo (int x, int y)
{
int i;
for (i = 0; i 100; i++)
{
if (i x)
v = y;
}
}
void *
tf (void *arg)
{
pthread_barrier_wait (b);
if (arg == NULL)
{
pthread_mutex_lock (m);
if (v != 0)
abort ();
foo (50, 10);
pthread_mutex_unlock (m);
pthread_barrier_wait (b);
foo (120, 30);
}
else
{
foo (100, 20);
pthread_barrier_wait (b);
pthread_mutex_lock (m);
if (v != 10)
abort ();
foo (80, 40);
if (v != 40)
abort ();
pthread_mutex_unlock (m);
}
return NULL;
}
int
main (void)
{
pthread_t th[2];
pthread_barrier_init (b, NULL, 2);
if (pthread_create (th[0], NULL, tf, NULL)
|| pthread_create (th[1], NULL, tf, (void *) 1L))
return 1;
pthread_join (th[0], NULL);
pthread_join (th[1], NULL);
return 0;
}
and at -O0 works just fine and has no races in it, it is quite easy to show
the shared variable is only ever read or written inside of the critical
section.
But loop IM creates a race even when there is none in the code originally, if I
compile this with -O2 (both 4.1.x and trunk) it will abort after a couple of
attempts.
That's why I think we should have a generic option that disables optimizations
which are safe only in sequential programs (and -fopenmp would imply that
option).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31862
[Bug tree-optimization/31862] Loop IM and other optimizations harmful for -fopenmp
--- Comment #8 from pinskia at gmail dot com 2007-05-08 19:45 --- Subject: Re: Loop IM and other optimizations harmful for -fopenmp On 8 May 2007 18:08:26 -, jakub at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #7 from jakub at gcc dot gnu dot org 2007-05-08 19:08 --- This really is not specific to OpenMP, I believe the following is valid threaded program: This is not a valid program. You have to introduce mutexes to get it to be a valid program with threads. This is a common misunderstanding of thread programming. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31862
[Bug libstdc++/21334] Lack of Posix compliant thread safety in std::basic_string
-- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-01-20 00:55:27 |2007-05-08 19:47:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334
[Bug libstdc++/21334] Lack of Posix compliant thread safety in std::basic_string
--- Comment #39 from pcarlini at suse dot de 2007-05-08 19:50 --- The proper status of this PR is SUSPENDED. Today, mid of 2007, we all more or less concur that string is better implemented without reference-counting, optimized for short strings, and, of course, exploiting rvalue references. Indeed, we are already providing the first two features in ext/vstring.h, and the latter will be added ASAP. As for changing string itself, of course we have to wait for the first ABI break. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|SUSPENDED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334
[Bug target/27067] Compile errors with multiple inheritance where the stdcall attribute is applied to virtual functions.
--- Comment #13 from mark at codesourcery dot com 2007-05-08 20:11 --- Subject: Re: Compile errors with multiple inheritance where the stdcall attribute is applied to virtual functions. rridge at csclub dot uwaterloo dot ca wrote: --- Comment #11 from rridge at csclub dot uwaterloo dot ca 2007-05-08 12:25 --- MSC includes the calling convention as part of its C++ name mangling. Would this bug be easier to solve if the calling convention was also included as part of the C++ name mangling in GCC, instead of done afterwards? If so, it might be worth this small ABI breaking change in some future release of MinGW. I think that would be fine, from a C++ perspective. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27067
[Bug preprocessor/31869] New: stringifying empty macros
#include stdio.h
#define MKSTR(x) STR(x)
#define STR(x) #x
#define EMPTY /* nothing */
int main(void) {
puts(MKSTR(.EMPTY.));
puts(MKSTR(.EMPTY .));
}
Using gcc 4.1.2, configured with
../gcc-4.1.2/configure --prefix=$HOME/gcc --enable-languages=c,c++
--disable-multilib, on x86_64-pc-linux-gnu, this program prints out
..
..
rather than
..
. .
as I would expect.
--
Summary: stringifying empty macros
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: truedfx at gentoo dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31869
[Bug c++/11764] [DR147] g++ does not treat injected class name correctly.
--- Comment #7 from fang at csl dot cornell dot edu 2007-05-08 20:44 --- Still accepts-invalid as of 4.2-20070430 (RC2). -- fang at csl dot cornell dot edu changed: What|Removed |Added CC||fang at csl dot cornell dot ||edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11764
[Bug c++/11814] Code with missing template keyword wrongly accepted
--- Comment #9 from fang at csl dot cornell dot edu 2007-05-08 20:48 --- Still accepts-invalid with 4.2-20070430 (RC2). -- fang at csl dot cornell dot edu changed: What|Removed |Added CC||fang at csl dot cornell dot ||edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11814
[Bug middle-end/31738] Fortran dot product vectorization is restricted
--- Comment #2 from dorit at il dot ibm dot com 2007-05-08 21:00 --- Here is what happens in the three loops that don't get vectorized: (1) the loop in testvectdp2: This is the loop we analyze: # prephitmp.192_37 = PHI storetmp.191_30(3), D.1443_42(5) # i_1 = PHI 1(3), i_44(5) L15:; D.1437_32 = prephitmp.192_37; D.1438_33 = (int8) i_1; D.1439_34 = D.1438_33 + -1; D.1440_36 = (*a_35(D))[D.1439_34]; D.1441_40 = (*b_39(D))[D.1439_34]; D.1442_41 = D.1441_40 * D.1440_36; D.1443_42 = prephitmp.192_37 + D.1442_41; storetmp.191_38 = D.1443_42; c__lsm.199_17 = D.1443_42; i_44 = i_1 + 1; if (i_1 == D.1429_5) goto bb 6 (L21); else goto bb 5 (L20); We recognize the reduction, but we think that it is used in the loop: pr31738.f90:14: note: reduction used in loop. and indeed, prephitmp.192_37 is used in: D.1443_42 = prephitmp.192_37 + D.1442_41; which is ok, because this is the reduction stmt, but also used here: D.1437_32 = prephitmp.192_37; which is indeed something that we normally don't allow. so the vectorizer is ok, except that in this case D.1437_32 doesn't seem to be used anywhere in the function, so this stmt looks dead to me, but for some reason it is not cleaned away before the vectorizer... Still need to investigate why. (2) the loop in testvecm: This looks like the problem reported in PR31756: failed to compute offset or step for (*a.0_11)[D.1559_52] create_data_ref: failed to create a dr for (*a.0_11)[D.1559_52] pr31738.f90:24: note: not vectorized: unhandled data-ref (3) the loop in testvecm2 Same story (the PR31756 problem): failed to compute offset or step for (*a.0_10)[D.1509_52] create_data_ref: failed to create a dr for (*a.0_10)[D.1509_52] pr31738.f90:32: note: not vectorized: unhandled data-ref -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31738
[Bug target/31850] gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf
--- Comment #2 from sje at cup dot hp dot com 2007-05-08 21:18 --- I am seeing this slow compile too. It compiles OK on HPPA in 32 bit mode (1.5 minutes) but takes over 30 minutes in 64 bit mode. It also takes 6+ minutes on IA64 HP-UX. On an X86 box it took less than 1 minute. Using gprof on HPPA 64 bit mode I see 2.6 Billion (2614726712) calls to loc_mentioned_in_p. I think most are coming from remove_address_replacements but I am still trying to understand the problem. -- 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=31850
[Bug tree-optimization/25371] -ftree-vectorize results in internal compiler error on AMD64
--- Comment #7 from spop at gcc dot gnu dot org 2007-05-08 21:19 --- Subject: Re: -ftree-vectorize results in internal compiler error on AMD64 On 5/8/07, Sjodin, Jan [EMAIL PROTECTED] wrote: Okay, I looked at the code, and the problem is that we have to pass to force_gimple_operand an expression that is not a chain of recurrence, ie. a real expression that can be used to be decomposed in 3 addr code by the gimplifier. Thanks! That was the answer I was looking for. Sounds like the vectorizer is biting off more than it can chew :) Perhaps there is a check missing for chrecs somewhere. Yes, I also think that the quick fix is to add to the vectorizer the missing checks for simple enough expressions. I went back to look at the testcase, and I saw these nested loops, and we are trying to vectorize the innermost ones. So for avoiding a failed vectorization, and making the vectorizer to produce the right code, we want to generate some code for the base address in the outer loop. Sebastian -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25371
[Bug tree-optimization/25371] -ftree-vectorize results in internal compiler error on AMD64
--- Comment #8 from Jan dot Sjodin at amd dot com 2007-05-08 21:30 --- Subject: RE: -ftree-vectorize results in internal compiler error on AMD64 I would prefer to make it work instead of disabling the vectorizer for these cases. - Jan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sebastian Pop Sent: Tuesday, May 08, 2007 3:19 PM To: [EMAIL PROTECTED] Cc: Sjodin, Jan Subject: Re: [Bug tree-optimization/25371] -ftree-vectorize results in internal compiler error on AMD64 On 5/8/07, Sjodin, Jan [EMAIL PROTECTED] wrote: Okay, I looked at the code, and the problem is that we have to pass to force_gimple_operand an expression that is not a chain of recurrence, ie. a real expression that can be used to be decomposed in 3 addr code by the gimplifier. Thanks! That was the answer I was looking for. Sounds like the vectorizer is biting off more than it can chew :) Perhaps there is a check missing for chrecs somewhere. Yes, I also think that the quick fix is to add to the vectorizer the missing checks for simple enough expressions. I went back to look at the testcase, and I saw these nested loops, and we are trying to vectorize the innermost ones. So for avoiding a failed vectorization, and making the vectorizer to produce the right code, we want to generate some code for the base address in the outer loop. Sebastian -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25371
[Bug target/31850] gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf
--- Comment #3 from sje at cup dot hp dot com 2007-05-08 21:55 --- I now think the loc_mentioned_in_p calls are coming from the checking code at the top of subst_reload. I commented out this checking code and my compile speed up by more than 10X. -- sje at cup dot hp dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-05-08 21:55:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31850
[Bug target/27067] Compile errors with multiple inheritance where the stdcall attribute is applied to virtual functions.
--- Comment #14 from angray at beeb dot net 2007-05-08 22:02 --- (In reply to comment #13) Subject: Re: Compile errors with multiple inheritance where the stdcall attribute is applied to virtual functions. rridge at csclub dot uwaterloo dot ca wrote: --- Comment #11 from rridge at csclub dot uwaterloo dot ca 2007-05-08 12:25 --- MSC includes the calling convention as part of its C++ name mangling. Would this bug be easier to solve if the calling convention was also included as part of the C++ name mangling in GCC, instead of done afterwards? If so, it might be worth this small ABI breaking change in some future release of MinGW. I think that would be fine, from a C++ perspective. If indeed XPCOM is dependant upon this then making an ABI namemangling change would break Firefox and Thunderbird addons. Aaron -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27067
[Bug pch/14940] PCH largefile test fails on various platforms
--- Comment #35 from mmitchel at gcc dot gnu dot org 2007-05-08 22:05 --- Ian Taylor suggests: The way to fix this is to add a HOST_HOOKS_GT_PCH_GET_ADDRESS to host-solaris.c. That hook should try to allocate the space in some address area that is normally free on Solaris. See the use of TRY_EMPTY_VM_SPACE in host-linux.c. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14940
[Bug fortran/31202] Incorrect rounding generated for NINT
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-05-08 23:08 --- Created an attachment (id=13532) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13532action=view) New patch Here's a new patch from a completely different perspective, using C99 lround and llround functions (and their float and long double variants). -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Attachment #13228|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31202
[Bug rtl-optimization/28011] [SH] g++ generates wrong code, if '-fno-exceptions' and '-O' options are specified
--- Comment #2 from kkojima at gcc dot gnu dot org 2007-05-08 23:11 --- It turned out that this is a generic reload issue rather than a target problem. See http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00476.html -- kkojima at gcc dot gnu dot org changed: What|Removed |Added CC||kkojima at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Component|target |rtl-optimization Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-05-08 23:11:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28011
[Bug middle-end/30905] [dataflow] Fails to cross-jump
--- Comment #3 from steven at gcc dot gnu dot org 2007-05-08 23:15 ---
This patch would fix it, but it's brute-force and it causes a ~1.5% slowdown.
Some form of DCE a little more delicate than this will be necessary to fix this
bug, though.
Index: cfgcleanup.c
===
--- cfgcleanup.c(revision 124550)
+++ cfgcleanup.c(working copy)
@@ -2286,10 +2286,10 @@ cleanup_cfg (int mode)
{
delete_unreachable_blocks (), changed = true;
if (!(mode CLEANUP_NO_INSN_DEL)
- (mode CLEANUP_EXPENSIVE)
- !reload_completed)
+ (mode (CLEANUP_EXPENSIVE | CLEANUP_CROSSJUMP)))
{
- if (!delete_trivially_dead_insns (get_insns (), max_reg_num ()))
+ gcc_assert (df);
+ if (! run_fast_dce ())
break;
}
else
@@ -2343,10 +2343,9 @@ static unsigned int
rest_of_handle_jump2 (void)
{
delete_trivially_dead_insns (get_insns (), max_reg_num ());
+ delete_unreachable_blocks ();
if (dump_file)
dump_flow_info (dump_file, dump_flags);
- cleanup_cfg ((optimize ? CLEANUP_EXPENSIVE : 0)
- | (flag_thread_jumps ? CLEANUP_THREADING : 0));
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30905
[Bug rtl-optimization/28011] [SH] g++ generates wrong code, if '-fno-exceptions' and '-O' options are specified
--- Comment #3 from kkojima at gcc dot gnu dot org 2007-05-08 23:23 --- Subject: Bug 28011 Author: kkojima Date: Tue May 8 22:22:49 2007 New Revision: 124557 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124557 Log: PR rtl-optimization/28011 * reload.c (push_reload): Set dont_share if IN appears in OUT also when IN is a PLUS rtx. (reg_overlap_mentioned_for_reload_p): Return true if X and IN are same PLUS rtx. Modified: trunk/gcc/ChangeLog trunk/gcc/reload.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28011
[Bug c/31870] New: Failure to diagnose taking address of register variable
int d (void) { register int a[2]; return a, 1; }
--
Summary: Failure to diagnose taking address of register variable
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: neil at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31870
[Bug c/31871] New: C99 failure to diagnose non-integer cast
Casts to void * are not permitted in integer constant expressions. Therefore this code violates constraint 6.7.5.2p2 of C99 (C90 is u.b.) and so must be diagnosed. extern int c[1 + ((int) (void *) 0)]; -- Summary: C99 failure to diagnose non-integer cast Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: neil at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31871
[Bug debug/31872] New: Duplicate file numbers for .file directive with -g3 -O0
Compiling 27_io/basic_istream/extractors_arithmetic/char/12.cc with -g3 -O0, I get the error: /var/tmp//ccLYgR4g.s: Assembler messages: /var/tmp//ccLYgR4g.s:424: Error: file number 1 already allocated This is the full compilation command: /test/gnu/gcc/objdir/./gcc/g++ -shared-libgcc -B/test/gnu/gcc/objdir/./gcc -nostdinc++ -L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/src -L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/src/.libs -B/opt/gnu64/gcc/gcc-4.3.0/hppa64-hp-hpux11.11/bin/ -B/opt/gnu64/gcc/gcc-4.3.0/hppa64-hp-hpux11.11/lib/ -isystem /opt/gnu64/gcc/gcc-4.3.0/hppa64-hp-hpux11.11/include -isystem /opt/gnu64/gcc/gcc-4.3.0/hppa64-hp-hpux11.11/sys-include -g3 -O0 -D_GLIBCXX_ASSERT -ffunction-sections -fdata-sections -fmessage-length=0 -g3 -O0 -DLOCALEDIR=. -nostdinc++ -I/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/hppa64-hp-hpux11.11 -I/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include -I/test/gnu/gcc/gcc/libstdc++-v3/libsupc++ -I/test/gnu/gcc/gcc/libstdc++-v3/include/backward -I/test/gnu/gcc/gcc/libstdc++-v3/testsuite/util /test/gnu/gcc/gcc/libstdc++-v3/testsuite/27_io/basic_istream/extractors_arithmetic/char/12.cc -include bits/stdc++.h -c -o ./12.c I see in the assembler output: .LEVEL 2.0w .file 12.cc .version01.01 .section.debug_abbrev,,@progbits L$debug_abbrev: .section.debug_info,,@progbits L$debug_info: .section.debug_line,,@progbits L$debug_line: .section.debug_macinfo,,@progbits L$debug_macinfo: .text L$text: .file 1 /test/gnu/gcc/gcc/libstdc++-v3/testsuite/27_io/basic_istream/ex tractors_arithmetic/char/12.cc ... .uleb128 0x0 .stringzLOCALEDIR . .file 1 /test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/i stream .section.debug_macinfo,,@progbits ... -- Summary: Duplicate file numbers for .file directive with -g3 -O0 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa64-hp-hpux11.11 GCC host triplet: hppa64-hp-hpux11.11 GCC target triplet: hppa64-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31872
[Bug debug/31872] Duplicate file numbers for .file directive with -g3 -O0
--- Comment #1 from danglin at gcc dot gnu dot org 2007-05-09 00:52 --- Oops, this is against 4.3. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Version|4.2.0 |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31872
[Bug fortran/31867] function result with character LEN computed at run time
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-05-09 01:10 --- I will look this over tonight. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31867
[Bug fortran/31867] function result with character LEN computed at run time
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-05-09 01:33 --- I get: words = 'two three' On x86-64-gnu/linux with latest 4.3 I wonder if this is one that we recently fixed. Can you try with a more recent build? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31867
[Bug other/31852] Missing __builtin_memchr
--- Comment #2 from pcarlini at suse dot de 2007-05-09 01:34 --- I have a draft... -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-05-07 12:04:29 |2007-05-09 01:34:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31852
[Bug tree-optimization/31866] [4.3 Regression] ICE with tree check error: expected ssa_name, have var_decl in create_outofssa_var_map
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-09 01:45 ---
Here is a shorter testcase:
int
foo (void)
{
unsigned int resultvar;
long int arg = (long int) 0;
register long int reg asm (eax) = arg;
asm (nop
: =r (resultvar)
: 0 (reg)
);
return resultvar;
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |blocker
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2007-05-09 01:45:25
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31866
[Bug libstdc++/21334] Lack of Posix compliant thread safety in std::basic_string
--- Comment #40 from gianni at mariani dot ws 2007-05-09 01:54 --- Paolo writes: ... concur that string is better implemented without reference-counting ... Could I ask you to enumerate the reasons why you come to this conclusion ? I just want understand better why (royal) we came to this conclusion. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334
[Bug libstdc++/21334] Lack of Posix compliant thread safety in std::basic_string
-- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|pcarlini at suse dot de |unassigned at gcc dot gnu ||dot org Status|SUSPENDED |NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334
[Bug libstdc++/21334] Lack of Posix compliant thread safety in std::basic_string
-- pcarlini at suse dot de changed: What|Removed |Added Status|NEW |SUSPENDED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334
[Bug c/31864] need -print-includes-dirs option
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-09 02:17 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-05-09 02:17:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31864
[Bug c/31871] C99 failure to diagnose non-integer cast
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-09 03:07 --- Related to PR 29116. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31871
[Bug preprocessor/31869] stringifying empty macros
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-09 03:14 --- I don't see a problem with this .. are two different tokens (.) so getting rid of the space is ok here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31869
[Bug middle-end/31862] Loop IM and other optimizations harmful for -fopenmp
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-05-09 03:19 --- That's why I think we should have a generic option that disables optimizations which are safe only in sequential programs (and -fopenmp would imply that option). So it sounds like you don't any thing about threading programming. People have to use mutexes and such to get safe code storing/accessing in globals no matter what, even if it looks like it is thread safe or not because of the way threads act. I don't see how this is different from knowning when programs access memory in some random way. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Component|tree-optimization |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31862
[Bug fortran/19925] Implied do-loop in an initialization expression is broken
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2007-05-09 04:02 --- Apparently the magic limit here is 65535, not 10 as stated previously. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19925
[Bug preprocessor/31869] stringifying empty macros
--- Comment #2 from neil at gcc dot gnu dot org 2007-05-09 05:01 --- The space is required by the standard. Is this a regression? I believe GCC used to get this right but I could be wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31869
