[Bug fortran/31201] Too large unit number generates wrong code
--- Comment #7 from patchapp at dberlin dot org 2007-04-04 05:55 --- Subject: Bug number PR31201 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-04/msg00126.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31201
[Bug target/27192] call through function pointer goes to wrong address
--- Comment #4 from eweddington at cso dot atmel dot com 2007-04-04 00:38 --- Confirmed bug. shifty3.i is a test case showing the problem. Compiled with avr-gcc 4.1.2, with: avr-gcc -Os shifty.c -o shifty.o shifty3.dis is a disassembly of shifty.o (with avr-objdump -d shifty.o). The problem is exhibited here: 005a : 5a: 89 e2 ldi r24, 0x29 ; 41 5c: 90 e0 ldi r25, 0x00 ; 0 5e: 90 93 61 00 sts 0x0061, r25 62: 80 93 60 00 sts 0x0060, r24 66: 82 e5 ldi r24, 0x52 ; 82 68: 92 e0 ldi r25, 0x02 ; 2 6a: 90 93 64 00 sts 0x0064, r25 6e: 80 93 63 00 sts 0x0063, r24 72: e0 91 60 00 lds r30, 0x0060 76: f0 91 61 00 lds r31, 0x0061 7a: 09 95 icall 7c: e0 91 63 00 lds r30, 0x0063 80: f0 91 64 00 lds r31, 0x0064 84: 09 95 icall The correct word address of the function foo is taken and stored (address 5a to 62), but then the *byte* address of the function foo is taken, and an offset added, and stored (address 66 to 6e). The following indirect call (address 7c to 84) is then incorrect. The PC has to be a *word* address. Adding a fixed offset to a function pointer, and then doing an indirect call, is valid in an AVR application as it is possible to copy or place functions at fixed offsets like this. Please mark this bug as NEW. Known to fail: 4.1.1, 4.1.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27192
[Bug c++/29365] Unnecessary anonymous namespace warnings
--- Comment #11 from crowl at google dot com 2007-04-04 00:30 --- (In reply to comment #5) > Yes, sorry, I should have said if foo::bar is used in multiple TUs, rather > than > foo itself. If foo::bar is defined in only one TU, and is used as an opaque > type in other TUs, you're fine. > > Perhaps we should suppress this warning in the main input file. The only remaining insecurity is when the same source is compiled twice in the same program or when a source is also include. These cases are probably rare enough to not warrant an option. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29365
[Bug fortran/31466] spurious error message when inner parentheses of a FORMAT statement are empty
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-04-04 00:28 --- Lahey reports this as a fatal syntax error. Checking file SOURCE.F90. Checking program unit TEST134 at line 1. Line 2, file SOURCE.F90 1 FORMAT(()) | | FATAL -- Essential LF90 requires that defined labels be referenced. FATAL -- Syntax error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31466
[Bug target/27192] call through function pointer goes to wrong address
--- Comment #3 from eweddington at cso dot atmel dot com 2007-04-04 00:25 --- Created an attachment (id=13325) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13325&action=view) Disassembly of the shifty3.i test case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27192
[Bug target/27192] call through function pointer goes to wrong address
--- Comment #2 from eweddington at cso dot atmel dot com 2007-04-04 00:24 --- Created an attachment (id=13324) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13324&action=view) Pre-processed testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27192
[Bug c++/31103] [4.3 Regression] same canonical type node for VLAs
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-04-04 00:21 --- *** Bug 31104 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31103
[Bug c++/31104] [4.3 Regression] same canonical type node for different types with anonymous
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-04-04 00:21 --- This is the same problem as PR 31103, VLAs. *** This bug has been marked as a duplicate of 31103 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31104
[Bug c++/29365] Unnecessary anonymous namespace warnings
--- Comment #10 from spark at gcc dot gnu dot org 2007-04-04 00:18 --- (In reply to comment #9) > (In reply to comment #8) > > The following patch addresses the problem. > > Do we want to add a flag to control this ? > > Except if you look at the file name, you could get a case where you are no > longer warning about. That's why I asked if we want to add a flag to enable/disable this - although I think my patch is a reasonable compromise as a default, it's not perfect (it can never be perfect unless we do whole-program analysis). The patch prevents the warning IF the anonymous namespace was in the same main source file that it's currently compiling (e.g. *.cc file). I think this covers bulk of the false positives with very small number of the false negatives. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29365
[Bug c++/29365] Unnecessary anonymous namespace warnings
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-04-04 00:11 --- (In reply to comment #8) > The following patch addresses the problem. > Do we want to add a flag to control this ? Except if you look at the file name, you could get a case where you are no longer warning about. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29365
[Bug c++/31449] [4.1/4.2/4.3 regression] static_cast can remove const-ness
--- Comment #1 from reichelt at gcc dot gnu dot org 2007-04-04 00:06 --- Confirmed. The regression was introduced between GCC 4.0.2 and 4.0.3. Mark, it looks like the following patch of yours is responsible for the regression: 2006-01-21 Mark Mitchell <[EMAIL PROTECTED]> PR c++/25895 * class.c (build_base_path): Generate a NOP_EXPR instead of a COMPONENT_REF if the base and derived classes are at the same address. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added CC||mark at codesourcery dot ||com, reichelt at gcc dot gnu ||dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||accepts-invalid, monitored Known to fail||4.0.3 Known to work||4.0.2 Last reconfirmed|-00-00 00:00:00 |2007-04-04 00:06:46 date|| Summary|static_cast can remove |[4.1/4.2/4.3 regression] |const-ness |static_cast can remove ||const-ness Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31449
[Bug c++/29365] Unnecessary anonymous namespace warnings
--- Comment #8 from spark at gcc dot gnu dot org 2007-04-03 23:50 ---
The following patch addresses the problem.
Do we want to add a flag to control this ?
--- a/gcc/cp/decl2.cMon Apr 02 15:48:00 2007 +
+++ b/gcc/cp/decl2.cTue Apr 03 22:45:49 2007 +
@@ -1860,9 +1860,13 @@ constrain_class_visibility (tree type)
int subvis = type_visibility (ftype);
if (subvis == VISIBILITY_ANON)
- warning (0, "\
+ {
+ if (strcmp (main_input_filename,
+ DECL_SOURCE_FILE (TYPE_MAIN_DECL (ftype
+ warning (0, "\
%qT has a field %qD whose type uses the anonymous namespace",
- type, t);
+ type, t);
+ }
else if (IS_AGGR_TYPE (ftype)
&& vis < VISIBILITY_HIDDEN
&& subvis >= VISIBILITY_HIDDEN)
@@ -1877,9 +1881,13 @@ constrain_class_visibility (tree type)
int subvis = type_visibility (TREE_TYPE (t));
if (subvis == VISIBILITY_ANON)
- warning (0, "\
+{
+ if (strcmp (main_input_filename,
+ DECL_SOURCE_FILE (TYPE_MAIN_DECL (TREE_TYPE (t)
+ warning (0, "\
%qT has a base %qT whose type uses the anonymous namespace",
-type, TREE_TYPE (t));
+type, TREE_TYPE (t));
+ }
else if (vis < VISIBILITY_HIDDEN
&& subvis >= VISIBILITY_HIDDEN)
warning (OPT_Wattributes, "\
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29365
[Bug bootstrap/31344] [4.3 Regression] bootstrap broken on i[345]86-linux
--- Comment #16 from hjl at lucon dot org 2007-04-03 23:22 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01764.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31344
[Bug fortran/31304] REPEAT argument NCOPIES is not converted as it should
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-04-03 22:07 --- Fixed on mainline, closing. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Known to fail|4.1.3 4.2.0 4.3.0 |4.2.0 4.1.3 Known to work||4.3.0 Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31304
[Bug fortran/31304] REPEAT argument NCOPIES is not converted as it should
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-04-03 22:05 --- Subject: Bug 31304 Author: fxcoudert Date: Tue Apr 3 22:05:14 2007 New Revision: 123481 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123481 Log: PR fortran/31304 * fortran/gfortran.h (gfc_charlen_int_kind): New prototype. * fortran/trans-types.c (gfc_charlen_int_kind): New variable. (gfc_init_types): Define gfc_charlen_int_kind. * fortran/trans.h (gfor_fndecl_string_repeat): Remove prototype. * fortran/trans-decl.c (gfor_fndecl_string_repeat): Delete. (gfc_build_intrinsic_function_decls): Don't set gfor_fndecl_string_repeat. * fortran/trans-intrinsic.c (gfc_conv_intrinsic_repeat): Rewrite so that we don't have to call a library function. * fortran/simplify.c (gfc_simplify_repeat): Perform the necessary checks on the NCOPIES argument, and work with arbitrary size arguments. * intrinsics/string_intrinsics.c (string_repeat): Remove. * gfortran.dg/repeat_2.f90: New test. * gfortran.dg/repeat_3.f90: New test. * gfortran.dg/repeat_4.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/repeat_2.f90 trunk/gcc/testsuite/gfortran.dg/repeat_3.f90 trunk/gcc/testsuite/gfortran.dg/repeat_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/simplify.c trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/fortran/trans-types.c trunk/gcc/fortran/trans.h trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/intrinsics/string_intrinsics.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31304
[Bug fortran/31466] spurious error message when inner parentheses of a FORMAT statement are empty
--- Comment #1 from burnus at gcc dot gnu dot org 2007-04-03 21:58 --- I believe this bug is invalid as the format string is invalid. NAG f95 also claims: *** Malformed format specification Reasoning: R1001 format-stmt is FORMAT format-specification R1002 format-specification is ( [ format-item-list ] ) Thus the question is whether "()" is a valid format-item(-list). R1003 format-item is [ r ] data-edit-desc or control-edit-desc or char-string-edit-desc or [ r ] ( format-item-list ) R1004 r is int-literal-constant I would claim that "()" is not - a data-edit-desc - a char-string-edit-desc It matches however, "( format-item-list )", but then I would claim that "" is not: - a data-edit-desc - a char-string-edit-desc - ( format-item-list ) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31466
[Bug target/31334] Bad codegen for vector initializer with constants prop'd into a vector initializer
--- Comment #8 from dorit at il dot ibm dot com 2007-04-03 20:46 --- (In reply to comment #7) > Something like: > (define_insn_and_split "altivec_dup" > [(set (match_operand:V 0 "register_operand" "v") > (vec_duplicate: (match_operand: 0 "r"))) >(clobber (match_operand:V 3 "memory_operand" "=Z"))] > "TARGET_ALTIVEC" > "#" > "&& reload_completed" > > Which then will be generated from rs6000_expand_vector_init. I can write this > if you want, it is just I cannot test this until Monday. yes, please... I'll be very happy to see this fixed. (thanks!!) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31334
[Bug tree-optimization/25553] Missed removal of load
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-04-03 20:40 --- Micha, this one is "similar" to hmmer -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||matz at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25553
[Bug target/25413] wrong alignment or incorrect address computation in vectorized code on Pentium 4 SSE
--- Comment #6 from dorit at il dot ibm dot com 2007-04-03 20:22 --- So I see Devang had sent a patch for this over a year ago: http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00167.html I don't know what ever happened to it. Maybe you want to give it a try? (you may need to implement the new target hook for Pentium4). If you have problems applying the patch (it is a bit old) - I could try to help update the patch (not before next week though). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25413
[Bug c++/25915] use ODR rules to make C++ objects not be TREE_PUBLIC
--- Comment #14 from pinskia at gcc dot gnu dot org 2007-04-03 20:03 --- *** Bug 31462 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||guillaume dot melquiond at ||ens-lyon dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25915
[Bug c++/31462] Unnamed namespace and exported symbols
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-03 20:03 --- This has already been implemented for 4.2.0. See PR 25915 which I am closing this as a dup of. *** This bug has been marked as a duplicate of 25915 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31462
[Bug tree-optimization/25553] Missed removal of load
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-04-03 20:00 --- *** Bug 31460 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25553
[Bug tree-optimization/31460] if(a) a[i] = xxx; else a[i] = yyy; is not converted to if (a) ddd= xxx; else ddd = yyy; a[i] = ddd;
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-04-03 20:00 --- (In reply to comment #4) > yes, this is indeed a known problem (I don't know if there's a PR open for > it). > It is one of the tree-ifcvt enhancements that Victor was going to tackle for > 4.3 (item (2.3) in http://gcc.gnu.org/wiki/AutovectBranchOptimizations?). Plus it was mentioned before this does not belong in tree-ifcvt either. See http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00494.html And there is already a bug about this, see PR25553 *** This bug has been marked as a duplicate of 25553 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31460
[Bug tree-optimization/31460] if(a) a[i] = xxx; else a[i] = yyy; is not converted to if (a) ddd= xxx; else ddd = yyy; a[i] = ddd;
--- Comment #4 from dorit at il dot ibm dot com 2007-04-03 19:56 --- yes, this is indeed a known problem (I don't know if there's a PR open for it). It is one of the tree-ifcvt enhancements that Victor was going to tackle for 4.3 (item (2.3) in http://gcc.gnu.org/wiki/AutovectBranchOptimizations?). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31460
[Bug libstdc++/31464] Extension request: publicly visible forward-declaration headers for and all STL containers
--- Comment #1 from fang at csl dot cornell dot edu 2007-04-03 19:45
---
Funny you mention this, I've done exactly this in my own utility headers:
create forward-declaration-only headers of STL containers and algorithms.
"STL/allocator_fwd.h":
namespace std {
template
class allocator;
}
"STL/list_fwd.h"
#include "STL/allocator_fwd.h"
namespace std {
template >
class list;
}
etc...
I've even made typedef templates in some cases:
namespace std {
template
struct default_vector {
typedef vector > type;
}
}
Another possible advantage of doing this would be to facilitate separate
template compilation of STL containers and their methods *without* relying on
the "extern template" extension. (Has worked for me.) I've never sought to
push this idea, as it might create a minor headache for co-developers who might
suddenly find that including a header that only uses a forward-declared
template class suddenly needs to include the full-definition header on the side
to be able to use it. e.g.
#include
template
void
some_func(const std::list& l) {
...
}
Uses of the header that don't instantiate some_func will compile fine, whereas
instantiations will require the rest of . I don't necessarily find this
a bad idea, but it can be a source of problems.
FWIW, I use autoconf to detect and conditionally include headers that we're not
supposed to include directly, such as .
#if HAVE_BITS_STRINGFWD_H
#include
#endif
Compilation speedups have been noticeable.
--
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=31464
[Bug libstdc++/8670] Alignment problem in std::basic_string
--- Comment #21 from pcarlini at suse dot de 2007-04-03 19:26 --- A few issues of the current std::string should be really in suspended status, thus clarifying that cannot be fixed within the current ABI. Anyway, in the meanwhile, people are encouraged to try , a new, versatile implementation which provides both a non-reference-counted-type implementation (by default), or an improved reference-counted one (no alignment issues at all). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8670
[Bug fortran/31466] New: spurious error message when inner parentheses of a FORMAT statement are empty
When I compile the program listed below I receive a spurious error message: test134.f90:2.11: 1 FORMAT(()) 1 Error: Unexpected element in format string at (1) PROGRAM test134 1 FORMAT(()) END -- Summary: spurious error message when inner parentheses of a FORMAT statement are empty Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: michael dot a dot richmond at nasa dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31466
[Bug fortran/31427] TRANSFER with mold kind /= lval kind: ICE on ia64, i686; no warning
--- Comment #8 from dfranke at gcc dot gnu dot org 2007-04-03 19:01 ---
PROGRAM test
INTEGER(KIND=K) :: i(1)
i = (/ TRANSFER("a", 0_L) /)
print *, i
END PROGRAM test
Above snippet works on i686 and ia64 if K==L, if K/=L, it crashes, no matter
which is the larger kind.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31427
[Bug fortran/31463] gfortran prints no warning message when an unset return value is an array
--- Comment #1 from michael dot a dot richmond at nasa dot gov 2007-04-03 18:45 --- The following functions should produce a similar warning message: function test97() result(ps) character :: ps end function test97 CHARACTER(*) FUNCTION test105() i = LEN(test105) END FUNCTION test105 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31463
[Bug fortran/31465] New: spurious error: Implicitly typed PARAMETER doesn't match a later IMPLICIT type
The program listed below produces a spurious error message: test.f90:2.11: PARAMETER(C = 0.0D0) 1 Error: Implicitly typed PARAMETER 'c' at (1) doesn't match a later IMPLICIT type The message will disappear if I put the IMPLICIT declaration before the PARAMETER declaration. PROGRAM test PARAMETER(C = 0.0D0) IMPLICIT REAL*8 (C) END -- Summary: spurious error: Implicitly typed PARAMETER doesn't match a later IMPLICIT type Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: michael dot a dot richmond at nasa dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31465
[Bug libstdc++/31464] New: Extension request: publicly visible forward-declaration headers for and all STL containers
It would be nice if there were publicly visible headers analogous to for and all the STL headers. To be more concrete: for every STL header there should be a that contains *only* forward declarations of the types with complete declarations in . The existing is an example of exactly what I have in mind, and should be promoted to . The value of these headers would be primarily in writing application headers; it is common to need to include or or whatever solely to be able to refer to the types it defines in function prototypes. By providing forward-declaration headers, the application headers would not need to drag in the full text of the STL headers. Application source files could then include the complete-declaration headers only for the types they actually used. -- Summary: Extension request: publicly visible forward-declaration headers for and all STL containers Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zackw at panix dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31464
[Bug fortran/31427] TRANSFER with mold kind /= lval kind: ICE on ia64, i686; no warning
--- Comment #7 from michael dot a dot richmond at nasa dot gov 2007-04-03 18:08 --- (In reply to comment #6) > Could you try the following code in ia64 and i686? It works under i686. I do not have an ia64 machine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31427
[Bug rtl-optimization/23684] Combine stores for non strict alignment targets
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-04-03 17:54 --- *** Bug 19726 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||yuri at tsoft dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23684
[Bug rtl-optimization/19726] suboptimal constructor generated, consecutive stores should be done in a biggest mode
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-04-03 17:54 --- *** This bug has been marked as a duplicate of 23684 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19726
[Bug fortran/31427] TRANSFER with mold kind /= lval kind: ICE on ia64, i686; no warning
--- Comment #6 from burnus at gcc dot gnu dot org 2007-04-03 17:54 ---
Could you try the following code in ia64 and i686?
PROGRAM test
INTEGER(KIND=1) :: i(1)
i = (/ TRANSFER("a", 0_1) /)
print *, i
END PROGRAM test
I think this will compile and print "97". Is this indeed the case on ia64 adb
i686?
The original program has one problem:
i = (/ TRANSFER("a", 0_1) /)
is not well defined as "i" is kind=1 whereas "0" is kind=4.
gfortran should follow NAG f95 and print the following warning:
Warning: x.f90, line 3: Intrinsic TRANSFER has partly undefined result
Additionally, gfortran seems to generate questionable code for "0": "i" is "0"
(under x86-64) and not the expected "97". While the result is not well defined,
using "97" as do NAG f95, g95 and ifort would be highly desirable.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||diagnostic, ice-on-valid-
||code, wrong-code
Last reconfirmed|-00-00 00:00:00 |2007-04-03 17:54:10
date||
Summary|When I compile the following|TRANSFER with mold kind /=
|program I get the message |lval kind: ICE on ia64,
|"GNU MP: Cannot reallocate |i686; no warning
|memory" |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31427
[Bug rtl-optimization/14613] Fails to convert byte loads/stores to word/long loads/stores
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-04-03 17:53 --- *** This bug has been marked as a duplicate of 23684 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14613
[Bug rtl-optimization/23684] Combine stores for non strict alignment targets
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-04-03 17:53 --- *** Bug 14613 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||cesarb at cesarb dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23684
[Bug rtl-optimization/323] optimized code gives strange floating point results
--- Comment #95 from guillaume dot melquiond at ens-lyon dot fr 2007-04-03 17:51 --- > I think that Uros' patch to add a -mpc switch for precision control would > "fix" this. > The real fix would be to automatically insert fldcw instructions before > float/double operations, in order to limit the precision of the operations. > But I think that it would kill speed even more than -ffloat-store. Unfortunately, it is not that simple. The -mpc switch and the fldcw instructions control the size of the significant, but they don't control the range of the exponent. So it will solve the issue with the first testcase of this bug-report, but you could still build examples where two execution paths that perform the same floating-point computations produce completely different results. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
[Bug tree-optimization/31460] if(a) a[i] = xxx; else a[i] = yyy; is not converted to if (a) ddd= xxx; else ddd = yyy; a[i] = ddd;
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-04-03 17:49 --- This is not the vectorizer's fault. >tree level if-conversion for the vectorizer _should_ be able to recognize this > case. It may be that it's just not set up to deal with x86* insns of this > kind. It cannot because there is a store there and no other pass sinks the store. So basically if(a) a[i] = xxx; else a[i] = yyy; is not converted to if (a) ddd= xxx; else ddd = yyy; a[i] = ddd; Which means this is really a dup of another bug. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Summary|vectorizer failed to work on|if(a) a[i] = xxx; else a[i] |simple loop |= yyy; is not converted to ||if (a) ddd= xxx; else ddd = ||yyy; a[i] = ddd; http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31460
[Bug objc/31281] ICE on ObjC try-catch blocks with next runtime
--- Comment #4 from stuart at gcc dot gnu dot org 2007-04-03 17:43 --- Subject: Bug 31281 Author: stuart Date: Tue Apr 3 17:43:15 2007 New Revision: 123478 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123478 Log: PR 31281 * objc/objc-act.c (next_sjlj_build_catch_list): Delete volatile from rethrow decl. * cse.c (record_jump_equiv): Bail out on CCmode comparisons. * testsuite/objc/execute/exceptions/pr31281.m: New. Added: branches/gcc-4_2-branch/gcc/testsuite/objc/execute/exceptions/pr31281.m Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/cse.c branches/gcc-4_2-branch/gcc/objc/objc-act.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31281
[Bug middle-end/30473] [4.1 Regression] Internal Compiler Error with a sprintf with few arguments for format %s
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-04-03 17:38 --- *** Bug 31458 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||sharybin at nm dot ru http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30473
[Bug c/31458] gcc:internal compiler error: Segmentation fault on sprintf (buf, "%s");
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-04-03 17:38 --- *** This bug has been marked as a duplicate of 30473 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31458
[Bug tree-optimization/31460] vectorizer failed to work on simple loop
--- Comment #2 from hjl at lucon dot org 2007-04-03 17:37 ---
For code:
typedef short vec_t;
extern __attribute__((aligned(16))) vec_t x [64];
extern __attribute__((aligned(16))) vec_t y [64];
extern __attribute__((aligned(16))) vec_t m [64];
void
foo ()
{
int i;
for (i = 0; i < 64; i++)
if (x [i] < y [i])
m [i] = y [i];
else
m [i] = x [i];
}
I am expecting:
.globl foo
.type foo, @function
foo:
.LFB2:
movdqa y(%rip), %xmm0
movl$16, %eax
pmaxsw x(%rip), %xmm0
movdqa %xmm0, m(%rip)
.p2align 4,,7
.L2:
movdqa y(%rax), %xmm0
pmaxsw x(%rax), %xmm0
movdqa %xmm0, m(%rax)
addq$16, %rax
cmpq$128, %rax
jne .L2
rep ; ret
.LFE2:
.size foo, .-foo
But I got
.globl foo
.type foo, @function
foo:
.LFB2:
xorl%ecx, %ecx
.p2align 4,,7
.L2:
movzwl x(%rcx,%rcx), %edx
movzwl y(%rcx,%rcx), %eax
cmpw%ax, %dx
cmovge %edx, %eax
movw%ax, m(%rcx,%rcx)
addq$1, %rcx
cmpq$64, %rcx
jne .L2
rep ; ret
.LFE2:
.size foo, .-foo
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31460
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Comment #103 from pinskia at gcc dot gnu dot org 2007-04-03 17:37 --- *** Bug 31459 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||rjarrett at mathworks dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug fortran/31463] New: gfortran prints no warning message when an unset return value is an array
When I compile the function listed below I receive no diagnostics. It should say: test.f90: In function 'test': test.f90:1: warning: Function return value not set FUNCTION test() RESULT(f) REAL, DIMENSION(1) :: f END FUNCTION test -- Summary: gfortran prints no warning message when an unset return value is an array Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: michael dot a dot richmond at nasa dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31463
[Bug c++/31459] No #pragma GCC visibility {push/pop} (default) in and
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-03 17:37 --- Actually this is fixed in 4.2.0, see PR 19664. *** This bug has been marked as a duplicate of 19664 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31459
[Bug c++/31462] New: Unnamed namespace and exported symbols
(NB: I'm not suggesting to change the linkage of functions in an unnamed namespace to internal.) Unless specified otherwise, functions in an unnamed namespace have external linkage. Does that mean that g++ has to export the corresponding symbol? As the function cannot be used from another translation unit, it seems to me it is a waste of space, and perhaps of inter-procedural optimization opportunities too. If there is a case where it matters for the symbol to be exported, please disregard this enhancement-request (but please provide an example as it interests me). The reason for this request is that I recently come across a program where forcefully removing the export of these symbols in the object files sped up executable linking by more than 15%. So it would provide a nice gain if GCC was not exporting the symbols. -- Summary: Unnamed namespace and exported symbols Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: guillaume dot melquiond at ens-lyon dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31462
[Bug fortran/31461] New: warn about entities in USE, ONLY statement not later used
I request that gfortran optionally warn about entities appearing in a USE, ONLY statement that are not later referenced in the program block where the USE appears. For example, for the code module util_mod integer :: i,j end module util_mod program main use util_mod, only: i,j j = 1 print*,"j=",j end program main g95 -Wall -Wextra -c says In file xunused_simple.f90:6 use util_mod, only: i,j 1 Warning (136): Module variable 'i' at (1) is never used In file xunused_simple.f90:6 use util_mod, only: i,j 1 Warning (109): ONLY variable 'i' USE-d at (1) is never used or set -- Summary: warn about entities in USE, ONLY statement not later used Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: vivekrao4 at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31461
[Bug debug/31412] [4.3] inf loop/long compile time, time spent in var-tracking.c
--- Comment #14 from zadeck at naturalbridge dot com 2007-04-03 16:47 --- Subject: Re: [4.3] inf loop/long compile time, time spent in var-tracking.c steven at gcc dot gnu dot org wrote: > --- Comment #13 from steven at gcc dot gnu dot org 2007-04-03 16:40 > --- > So this may be a non-monotonous dataflow problem...? > > Do we have the dataflow equations of the var-tracking problem somewhere? It'd > be interesting to check them against the actual implementation. > > > this is a pretty complex problem. I gave it a cursory once over and it looks like the problem may not terminate if the location (stack offset) of a variable is not the same on all paths into a block. (the code may be different than the comments and i did just scan this) I assume that this case has a "bug" where a variable appears to be at a different location coming across an exception edge. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31412
[Bug debug/31412] [4.3] inf loop/long compile time, time spent in var-tracking.c
--- Comment #13 from steven at gcc dot gnu dot org 2007-04-03 16:40 --- So this may be a non-monotonous dataflow problem...? Do we have the dataflow equations of the var-tracking problem somewhere? It'd be interesting to check them against the actual implementation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31412
[Bug tree-optimization/31460] vectorizer failed to work on simple loop
--- Comment #1 from steven at gcc dot gnu dot org 2007-04-03 16:36 --- Maybe you can show the assembly output you're expecting? tree level if-conversion for the vectorizer _should_ be able to recognize this case. It may be that it's just not set up to deal with x86* insns of this kind. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31460
[Bug target/29953] [SH-4] Perfomance regression in loops. cmp/eq used instead of dt
--- Comment #5 from steven at gcc dot gnu dot org 2007-04-03 16:34 --- Re. comment #4: Answer: Go ahead and implement it in loop.c. If you want to fix it only for GCC 4.1, that is. There is no loop.c in GCC 4.2 and later. So does it make sense? Depends on what you want to achieve. -- steven 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-04-03 16:34:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29953
[Bug libstdc++/8670] Alignment problem in std::basic_string
--- Comment #20 from jamesc at dspsrv dot com 2007-04-03 16:30 --- I can see this problem, solaris 10 and gcc 4.1.1. The workaround suggested by the following person works: Margarita Manterola http://www.mail-archive.com/debian-bugs-rc@lists.debian.org/msg67774.html via Darren Long http://mailman.dtnrg.org/pipermail/dtn-users/2007-January/000448.html // include iostream before string to avoid stdc++ bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8670 #include #include -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8670
[Bug target/29953] [SH-4] Perfomance regression in loops. cmp/eq used instead of dt
--- Comment #4 from christian dot bruel at st dot com 2007-04-03 15:30
---
This missed optimisation appears with all counted loops. The ir in gimple
produces
j = 0;
:;
j = j + 1;
if (j <= 999)
{
goto ;
}
The transformation to do ( j=1000; j=j-1; if (j)...) will allow the decrement
and test pattern to be catched by combine.
Since this transformation needs to know about code selection (and is only
useful if the number of issued instructions is > 1), it seems best to do it in
rtl. I'm thinking about strength_reduce in loop.c when we optimize bivs.
Question: does it make sense to do this transformation in loop.c ? I'm thinking
at strength_reduce.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29953
[Bug tree-optimization/31460] New: vectorizer failed to work on simple loop
bash-3.1$ cat pmaxsw.c
typedef short vec_t;
extern __attribute__((aligned(16))) vec_t x [64];
extern __attribute__((aligned(16))) vec_t y [64];
extern __attribute__((aligned(16))) vec_t m [64];
void
foo ()
{
int i;
for (i = 0; i < 20; i++)
#if 0
m [i] = (x [i] < y [i]) ? y [i] : x[i];
#else
if (x [i] < y [i])
m [i] = y [i];
else
m [i] = x[i];
#endif
}
bash-3.1$ make
/usr/gcc-4.3/bin/gcc -O2 -mssse3 -ftree-vectorize -ftree-vectorizer-verbose=1
-S pmaxsw.c
pmaxsw.c:9: note: for a in pmaxsw.s; do \
insn=`basename $a .s`; \
echo Check vectorizer on $insn.c:; \
grep $insn $a | grep xmm; \
done
Check vectorizer on pmaxsw.c:
make: *** [all] Error 1
bash-3.1$
bash-3.1$ cat pmaxsw.c
typedef short vec_t;
extern __attribute__((aligned(16))) vec_t x [64];
extern __attribute__((aligned(16))) vec_t y [64];
extern __attribute__((aligned(16))) vec_t m [64];
void
foo ()
{
int i;
for (i = 0; i < 20; i++)
#if 1
m [i] = (x [i] < y [i]) ? y [i] : x[i];
#else
if (x [i] < y [i])
m [i] = y [i];
else
m [i] = x[i];
#endif
}
bash-3.1$ make
/usr/gcc-4.3/bin/gcc -O2 -mssse3 -ftree-vectorize -ftree-vectorizer-verbose=1
-S pmaxsw.c
pmaxsw.c:12: note: LOOP VECTORIZED.
pmaxsw.c:9: note: vectorized 1 loops in function.
for a in pmaxsw.s; do \
insn=`basename $a .s`; \
echo Check vectorizer on $insn.c:; \
grep $insn $a | grep xmm; \
done
Check vectorizer on pmaxsw.c:
pmaxsw x(%rip), %xmm0
pmaxsw x+16(%rip), %xmm0
bash-3.1$
Why can't vectorizer recognize
if (x [i] < y [i])
m [i] = y [i];
else
m [i] = x[i];
is the same as
m [i] = (x [i] < y [i]) ? y [i] : x[i];
--
Summary: vectorizer failed to work on simple loop
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31460
[Bug c++/31459] New: No #pragma GCC visibility {push/pop} (default) in and
Generic header defect observed on both x86 and x86_64
Missing "#pragma GCC visibility push(default)" and "#pragma GCC visibility
pop" directives wrapped around the versions of and that
ship with GCC 4.0 - 4.2. See for example or , which are
properly encased.
Add #pragma GCC visibility push(default) and
#pragma GCC visibility pop(default) to string and stdexcept
>From new
...
#pragma GCC visibility push(default)
extern "C++" {
...
} // extern "C++"
#pragma GCC visibility pop
Workaround:
create a include directory with files 'string' and 'stdexcept' and alter your
include path to ssearch this directory first.
string:
#pragma GCC system_header
#pragma GCC visibility push(default)
#include_next
#pragma GCC visibility pop
--
Summary: No #pragma GCC visibility {push/pop} (default) in
and
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rjarrett at mathworks dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31459
[Bug fortran/31395] Colon edit descriptor is ignored unless preceded by a comma or a slash
-- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-03-31 23:01:58 |2007-04-03 14:52:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31395
[Bug fortran/31201] Too large unit number generates wrong code
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2007-04-03 14:50 --- I have a patch testing -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31201
[Bug debug/31412] [4.3] inf loop/long compile time, time spent in var-tracking.c
--- Comment #12 from paolo dot bonzini at lu dot unisi dot ch 2007-04-03 13:59 --- Subject: Re: [4.3] inf loop/long compile time, time spent in var-tracking.c > With dataflow branch that was compiled with profiling the testcase finishes > not too slow: This suggest that it is a bug in the dataflow computation, causing it to oscillate and not terminate. Different RTL just causes the bug not to trigger. Paolo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31412
[Bug debug/31412] [4.3] inf loop/long compile time, time spent in var-tracking.c
--- Comment #11 from rguenth at gcc dot gnu dot org 2007-04-03 13:56 --- With dataflow branch that was compiled with profiling the testcase finishes not too slow: Each sample counts as 0.01 seconds. % cumulative self self total time seconds secondscalls s/call s/call name 7.48 1.07 1.073 0.36 1.37 vt_find_locations 5.59 1.87 0.80 6339766 0.00 0.00 variable_union 4.69 2.54 0.67 3617450 0.00 0.00 htab_find_with_hash 4.06 3.12 0.58 14114686 0.00 0.00 htab_find_slot_with_hash 2.80 3.52 0.40 810633 0.00 0.00 bitmap_ior_into 2.73 3.91 0.39 65064909 0.00 0.00 int_tree_map_eq 1.61 4.14 0.23 8049101 0.00 0.00 bitmap_elt_insert_after 1.54 4.36 0.22 271906 0.00 0.00 htab_traverse_noresize 1.50 4.58 0.22 10925677 0.00 0.00 bitmap_bit_p 1.40 4.78 0.20 12645563 0.00 0.00 pool_alloc 1.33 4.97 0.19 431 0.00 0.00 add_location_or_const_valu e_attribute 1.19 5.14 0.17 3991364 0.00 0.00 mark_insn 1.12 5.30 0.16 101241 0.00 0.00 df_chain_create_bb_process _use 1.12 5.46 0.16 94 0.00 0.01 df_worklist_dataflow 1.05 5.61 0.15 13657110 0.00 0.00 variable_htab_eq 0.98 5.75 0.14 6126572 0.00 0.00 variable_htab_hash -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31412
[Bug debug/31412] [4.3] inf loop/long compile time, time spent in var-tracking.c
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-04-03 13:50
---
At least all the attr_list stuff is O(N) as it uses a linked list for
static attrs
attrs_list_member (attrs list, tree decl, HOST_WIDE_INT offset)
{
for (; list; list = list->next)
if (list->decl == decl && list->offset == offset)
return list;
return NULL;
}
static void
attrs_list_union (attrs *dstp, attrs src)
{
for (; src; src = src->next)
{
if (!attrs_list_member (*dstp, src->decl, src->offset))
attrs_list_insert (dstp, src->decl, src->offset, src->loc);
}
}
(thats quadratic already, ugh)
it's a map of mapping to a rtx location.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31412
[Bug debug/31412] [4.3] inf loop/long compile time, time spent in var-tracking.c
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-04-03 13:45 --- If I ignore abnormal edges the computation finishes. Of course I have no idea what happens in that case ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31412
[Bug debug/31412] [4.3] inf loop/long compile time, time spent in var-tracking.c
--- Comment #8 from bonzini at gnu dot org 2007-04-03 13:38 --- I wouldn't say so. If there is a bug and the df solver oscillates, that's the reason for the infinite loop. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31412
[Bug rtl-optimization/19780] Floating point computation far slower for -mfpmath=sse
--- Comment #10 from bonzini at gnu dot org 2007-04-03 13:36 --- I would look at the lreg output, which contains the results of regclass. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19780
[Bug debug/31412] [4.3] inf loop/long compile time, time spent in var-tracking.c
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-04-03 13:36 --- Ok, let's defer a solution to after the df merge. Certainly something to look at. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||zadeck at naturalbridge dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31412
[Bug debug/31412] [4.3] inf loop/long compile time, time spent in var-tracking.c
--- Comment #6 from bonzini at gnu dot org 2007-04-03 13:33 --- anyway, the code looks well written. the dataflow_set_* functions look inefficient, though. maybe it's also possible to replace hash tables with pointer maps (there is a 1:1 relationships between decl nodes and their DECL_UID, right?) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31412
[Bug rtl-optimization/19780] Floating point computation far slower for -mfpmath=sse
--- Comment #9 from ubizjak at gmail dot com 2007-04-03 13:32 --- (In reply to comment #8) > what's the generated code for -ffast-math? in principle i don't see a reason > why it should make any difference... Trying to answer your question, I have played a bit with compile flags and things are getting really strange: [EMAIL PROTECTED] test]$ gcc -O2 -mfpmath=387 pr19780.c [EMAIL PROTECTED] test]$ time ./a.out Start? Stop! Result = 0.00, 0.00, 1.00 real0m1.211s user0m1.212s sys 0m0.004s [EMAIL PROTECTED] test]$ gcc -O2 -mfpmath=387 -msse pr19780.c [EMAIL PROTECTED] test]$ time ./a.out Start? Stop! Result = 0.00, 0.00, 1.00 real0m0.555s user0m0.552s sys 0m0.004s Note that -msse should have no effect on calculations. The difference between asm dumps is: --- pr19780.s 2007-04-03 14:28:14.0 +0200 +++ pr19780.s_ 2007-04-03 14:28:01.0 +0200 @@ -17,69 +17,61 @@ pushl %ebp movl%esp, %ebp pushl %ecx - subl$84, %esp + subl$100, %esp movl$.LC0, (%esp) callputs xorl%eax, %eax - fldz fld1 fsts-16(%ebp) + fldz + fsts-12(%ebp) + fld %st(0) fld %st(1) - fld %st(2) - fld %st(3) jmp .L2 .p2align 4,,7 .L7: - fstp%st(5) - fstp%st(0) - fxch%st(1) - fxch%st(2) - fxch%st(3) - fxch%st(4) fxch%st(3) + fxch%st(2) .L2: - fld %st(1) + fld %st(2) addl$1, %eax - fmul%st(3), %st + fmul%st(1), %st cmpl$1, %eax - fstps -12(%ebp) + flds-12(%ebp) + fmul%st(5), %st + fsubrp %st, %st(1) + flds-12(%ebp) + fmul%st(3), %st flds-16(%ebp) - fmul%st(1), %st - fsubrs -12(%ebp) - fstps -12(%ebp) - fmul%st(4), %st - fld %st(3) fmul%st(3), %st fsubrp %st, %st(1) flds-16(%ebp) - fmulp %st, %st(4) - fxch%st(1) + fmul%st(6), %st + fxch%st(5) fmul%st(4), %st - fsubrp %st, %st(3) - flds-16(%ebp) - fld %st(3) + fsubrp %st, %st(5) fxch%st(2) - fsts-16(%ebp) - flds-12(%ebp) + fstps -12(%ebp) + fxch%st(2) + fstps -16(%ebp) jne .L7 - fstp%st(0) - fstp%st(5) - fstp%st(0) - fstp%st(0) - fstp%st(0) + fstp%st(3) + fxch%st(1) movl$.LC3, (%esp) fstps -40(%ebp) + fxch%st(1) fstps -56(%ebp) + fstps -72(%ebp) callputs flds-40(%ebp) fstpl 20(%esp) flds-56(%ebp) fstpl 12(%esp) - flds-12(%ebp) + flds-72(%ebp) fstpl 4(%esp) movl$.LC4, (%esp) callprintf - addl$84, %esp + addl$100, %esp xorl%eax, %eax popl%ecx popl%ebp where (+++) is with -msse. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19780
[Bug debug/31412] [4.3] inf loop/long compile time, time spent in var-tracking.c
--- Comment #5 from bonzini at gnu dot org 2007-04-03 13:31 --- well, for sure it would be possible to use df and a good example of that too. But I'm not *that* knowledgeable about the df-*.c implementation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31412
[Bug debug/31412] [4.3] inf loop/long compile time, time spent in var-tracking.c
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-04-03 13:30 ---
The easiest thing is probably to ignore abnormal edges:
Index: var-tracking.c
===
*** var-tracking.c (revision 123450)
--- var-tracking.c (working copy)
*** vt_find_locations (void)
*** 1855,1861
dataflow_set_clear (&VTI (bb)->in);
FOR_EACH_EDGE (e, ei, bb->preds)
{
! dataflow_set_union (&VTI (bb)->in, &VTI (e->src)->out);
}
changed = compute_bb_dataflow (bb);
--- 1855,1862
dataflow_set_clear (&VTI (bb)->in);
FOR_EACH_EDGE (e, ei, bb->preds)
{
! if (!(e->flags & EDGE_ABNORMAL))
! dataflow_set_union (&VTI (bb)->in, &VTI (e->src)->out);
}
changed = compute_bb_dataflow (bb);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31412
[Bug debug/31412] [4.3] inf loop/long compile time, time spent in var-tracking.c
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-04-03 13:24 --- Well, vt_find_locations is quadratic in the number of edges and basic blocks which we have a _lot_ in this testcase. Now, with the dataflow rewrite there may be an easier way to compute the df problem. Maybe Paolo has a suggestion here... -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||bonzini at gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-04-03 13:24:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31412
[Bug rtl-optimization/19780] Floating point computation far slower for -mfpmath=sse
--- Comment #8 from bonzini at gnu dot org 2007-04-03 12:43 --- what's the generated code for -ffast-math? in principle i don't see a reason why it should make any difference... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19780
[Bug c++/30847] [4.1/4.2/4.3 regression] ICE with invalid statement expression
--- Comment #5 from jakub at gcc dot gnu dot org 2007-04-03 12:34 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30847
[Bug middle-end/30704] [4.2/4.3 Regression] Incorrect constant generation for long long
--- Comment #16 from jakub at gcc dot gnu dot org 2007-04-03 12:33 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30704
[Bug c/31458] gcc:internal compiler error: Segmentation fault on sprintf (buf, "%s");
--- Comment #1 from sharybin at nm dot ru 2007-04-03 12:02 --- Created an attachment (id=13323) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13323&action=view) File generated by -save-temps flag -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31458
[Bug c/31458] New: gcc:internal compiler error: Segmentation fault on sprintf (buf, "%s");
When I'm trying to compile simple program
#include
void main () {
char buf[1024];
sprintf (buf, "%s");
}
gcc catchs segmentation fault.
--
Summary: gcc:internal compiler error: Segmentation fault on
sprintf (buf, "%s");
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sharybin at nm dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31458
[Bug target/31175] isinf incorrectly expanded
--- Comment #3 from uros at gcc dot gnu dot org 2007-04-03 11:21 --- Subject: Bug 31175 Author: uros Date: Tue Apr 3 11:20:53 2007 New Revision: 123465 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123465 Log: PR target/31175 * config/i386/i386.md (isinf2): Expand only when TARGET_C99_FUNCTIONS is set. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31175
[Bug libstdc++/5291] Bad reference to build directory in libstdc++.la
--- Comment #23 from peb at mppmu dot mpg dot de 2007-04-03 10:29 --- Created an attachment (id=13322) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13322&action=view) patch (3 of 3) as described in comment #20 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5291
[Bug c++/30847] [4.1/4.2/4.3 regression] ICE with invalid statement expression
--- Comment #4 from jakub at gcc dot gnu dot org 2007-04-03 10:28 --- Subject: Bug 30847 Author: jakub Date: Tue Apr 3 10:28:35 2007 New Revision: 123462 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123462 Log: PR c++/30847 * typeck.c (build_modify_expr): For COND_EXPR on LHS, if RHS has void type issue error and return early. * g++.dg/parse/cond3.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/parse/cond3.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/typeck.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30847
[Bug libstdc++/5291] Bad reference to build directory in libstdc++.la
--- Comment #22 from peb at mppmu dot mpg dot de 2007-04-03 10:28 --- Created an attachment (id=13321) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13321&action=view) patch (2 of 3) as described in comment #20 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5291
[Bug libstdc++/5291] Bad reference to build directory in libstdc++.la
--- Comment #21 from peb at mppmu dot mpg dot de 2007-04-03 10:27 --- Created an attachment (id=13320) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13320&action=view) patch (1 of 3) as described in comment #20 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5291
[Bug c++/30847] [4.1/4.2/4.3 regression] ICE with invalid statement expression
--- Comment #3 from jakub at gcc dot gnu dot org 2007-04-03 10:25 --- Subject: Bug 30847 Author: jakub Date: Tue Apr 3 10:25:31 2007 New Revision: 123461 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123461 Log: PR c++/30847 * typeck.c (build_modify_expr): For COND_EXPR on LHS, if RHS has void type issue error and return early. * g++.dg/parse/cond3.C: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/parse/cond3.C Modified: branches/gcc-4_2-branch/gcc/cp/ChangeLog branches/gcc-4_2-branch/gcc/cp/typeck.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30847
[Bug libstdc++/5291] Bad reference to build directory in libstdc++.la
--- Comment #20 from peb at mppmu dot mpg dot de 2007-04-03 10:24 --- After some investigation I found that the problem of libtool & build paths has three aspects: (1) Build paths stored in installed c++ libraries (libstdc++.la and libsupc++.la) and then propagated to other libraries and possibly as rpath/runpath into binaries (2) Build paths stored in installed java libraries (libgij.la) (3) Missing LD_LIBRARY_PATH when running gcj-dbtool to produce classmap.db (this may fail resulting in an empty classmap.db file) (1) and (2) are due to (A) explicit -L's when building libraries or executables (B) implicit -L's due to ltcf-cxx.sh when building libraries For (3) gcj-bdtool (and others) should use some run-time environment as used for the test suite. Attached are three patches addressing (A) and (B), i.e., (1) and (2) without making (3) any worse than at present. I have successfully tested them in a bootstrap build for i686-linux-gnu as well as x86_64-linux-gnu but more testing would certainly be required. Here a short description: 1. patch-03-libstdc++-lt-paths-root introduces a new make variable RAW_CXX_FOR_TARGET_LIB (as RAW_CXX_FOR_TARGET but without explicit -L's) in the toplevel Makefile, to be passed as CXX_FOR_TARGET_LIB to the libstdc++ and libjava modules. 2. patch-03-libstdc++-lt-paths-libstdc++ Initialize CXX_FOR_LIB from CXX_FOR_TARGET_LIB (as passed from toplevel) and use it to build libraries. Replace --tag CXX by --tag CC when building libraries. 3. patch-03-libstdc++-lt-paths-libjava Initialize CXX_FOR_LIB as above Replace --tag CXX as above Replace dependencies, e.g., -L$(here)/.libs libgcj.la by libgcj.la when building libgij -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5291
[Bug middle-end/30704] [4.2/4.3 Regression] Incorrect constant generation for long long
--- Comment #15 from jakub at gcc dot gnu dot org 2007-04-03 10:23 --- Subject: Bug 30704 Author: jakub Date: Tue Apr 3 10:23:03 2007 New Revision: 123460 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123460 Log: PR middle-end/30704 * fold-const.c (native_encode_real): Encode real.c provided longs as a series of 32-bit native integers. (native_interpret_real): Interpret buffer as a series of 32-bit native integers. * gcc.c-torture/execute/ieee/pr30704.c: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/gcc.c-torture/execute/ieee/pr30704.c Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/fold-const.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30704
[Bug c++/30847] [4.1/4.2/4.3 regression] ICE with invalid statement expression
--- Comment #2 from jakub at gcc dot gnu dot org 2007-04-03 10:08 --- Subject: Bug 30847 Author: jakub Date: Tue Apr 3 10:08:00 2007 New Revision: 123456 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123456 Log: PR c++/30847 * typeck.c (build_modify_expr): For COND_EXPR on LHS, if RHS has void type issue error and return early. * g++.dg/parse/cond3.C: New test. Added: trunk/gcc/testsuite/g++.dg/parse/cond3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30847
[Bug middle-end/30704] [4.2/4.3 Regression] Incorrect constant generation for long long
--- Comment #14 from jakub at gcc dot gnu dot org 2007-04-03 10:05 --- Subject: Bug 30704 Author: jakub Date: Tue Apr 3 10:05:38 2007 New Revision: 123455 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123455 Log: PR middle-end/30704 * fold-const.c (native_encode_real): Encode real.c provided longs as a series of 32-bit native integers. (native_interpret_real): Interpret buffer as a series of 32-bit native integers. * gcc.c-torture/execute/ieee/pr30704.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/ieee/pr30704.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30704
[Bug libstdc++/31456] stringstream behaves unexpectedly
--- Comment #2 from cmertes at techfak dot uni-bielefeld dot de 2007-04-03 10:03 --- (In reply to comment #1) > And this is the correct behavior, which you can see also in many other > implementations. All right. It's strange anyway, I guess anybody who looked onto the two versions of main() above without knowing about the depth of the C++ standard would expect them to do exactly the same thing. But I guess for that the ISO would be the right place to go ;) Thank you for looking into this and kind regards, Christian -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31456
[Bug target/29826] __attribute__ dllimport makes optimization crash on cygwin
--- Comment #10 from dannysmith at users dot sourceforge dot net 2007-04-03 09:54 --- *** Bug 31457 has been marked as a duplicate of this bug. *** -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added CC||henman at it dot to-be dot ||co dot jp http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29826
[Bug c/31457] Internal Compiler Error
--- Comment #1 from dannysmith at users dot sourceforge dot net 2007-04-03 09:54 --- Duplicate of 29826 which is fixed on 4.2.0 and trunk. Danny *** This bug has been marked as a duplicate of 29826 *** -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||DUPLICATE Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31457
[Bug c/31457] Internal Compiler Error
-- dannysmith at users dot sourceforge dot net changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dannysmith at users dot |dot org |sourceforge dot net Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-04-03 09:52:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31457
[Bug fortran/31427] When I compile the following program I get the message "GNU MP: Cannot reallocate memory"
--- Comment #5 from dfranke at gcc dot gnu dot org 2007-04-03 09:37 --- For i686/SuSE 10.1 valgrind-3.2.2 gives: ==13209== Warning: set address range perms: large range 568154688 (undefined) ==13209== Invalid read of size 4 ==13209==at 0x40849CD: __gmpn_copyi (in /h/franke/packages/i686-pc-linux-gnu/gmp-4.2.1/lib/libgmp.so.3.4.1) ==13209== Address 0x42051E4 is 0 bytes after a block of size 67,524 alloc'd ==13209==at 0x40213D0: malloc (vg_replace_malloc.c:149) ==13209==by 0x86969F5: xmalloc (xmalloc.c:147) ==13209==by 0x39662E36: ??? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31427
[Bug fortran/31427] When I compile the following program I get the message "GNU MP: Cannot reallocate memory"
--- Comment #4 from dfranke at gcc dot gnu dot org 2007-04-03 09:34 --- Neither can I (gcc-4.2, gcc-svn). x86_64 seems to be immune. Another i686 machine again crashes (gcc-4.2, gcc-svn), so does an ia64 (gcc-4.2). All boxes have gmp-4.2.1 installed. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31427
[Bug libstdc++/31440] [4.3 Regression] libstdc++-g++-v3 discarded qualifiers
-- pcarlini at suse dot de changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31440
[Bug libstdc++/31440] [4.3 Regression] libstdc++-g++-v3 discarded qualifiers
--- Comment #3 from pcarlini at suse dot de 2007-04-03 09:33 --- Fixed for 4.3.0. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31440
[Bug libstdc++/31440] [4.3 Regression] libstdc++-g++-v3 discarded qualifiers
--- Comment #2 from paolo at gcc dot gnu dot org 2007-04-03 09:32 --- Subject: Bug 31440 Author: paolo Date: Tue Apr 3 09:32:31 2007 New Revision: 123452 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123452 Log: 2007-04-03 Paolo Carlini <[EMAIL PROTECTED]> PR libstdc++/31440 * include/bits/stl_tree.h (_M_lower_bound(_Link_type, _Link_type, const _Key&), _M_upper_bound(_Link_type, _Link_type, const _Key&)): Add. (_M_equal_range(const _Key&) const): Remove. (lower_bound(const key_type&), lower_bound(const key_type&) const, upper_bound(const key_type&), upper_bound(const key_type&) const, equal_range(const key_type&), equal_range(const key_type&) const): Adjust. (find(const _Key&), find(const _Key&) const): Tweak. * testsuite/23_containers/map/operations/31440.cc: New. Added: trunk/libstdc++-v3/testsuite/23_containers/map/operations/31440.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/stl_tree.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31440
[Bug libstdc++/31456] stringstream behaves unexpectedly
--- Comment #1 from pcarlini at suse dot de 2007-04-03 09:20 ---
(In reply to comment #0)
> the output changes to: 123de. So the initialization string gets overwritten
> instead of appending the data.
And this is the correct behavior, which you can see also in many other
implementations.
Inserting name.seekp(0, ios::end); helps, but
> only for compiler version 4.0, not for 4.1 (at least I think so, I couldn't
> test this enough ATM).
It helps on any recent GCC at least, gcc4.1.1, current 4.2 pre, mainline.
> Now trying to get the right behaviour by using stringstream name("abcde",
> ios::app); or stringstream name("abcde", ios::ate); leads to another
> interesting output: abcde. The input gets completely ignored.
In this case, passing only ios::app or whatelse, you are not telling at all the
stream whether you want to write or read. ios::out | ios::app works.
Really, there is nothing to fix here. One last remark: the ultimate reference
for the behavior which is implemented is the ISO C++03 Standard (+ any
implemented DR resolution), therefore always confer to it in case of doubt
about minute details, not books or manuals.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Component|c++ |libstdc++
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31456
[Bug c/31457] New: Internal Compiler Error
Error: unrecognizable insn
(1) $ /usr/local/bin/gcc -v
Using built-in specs.
Target: i686-pc-cygwin
Configured with: ../configure --enable-languages=c,c++,objc,fortran,java
--cache-file=build_cache.dat
Thread model: single
gcc version 4.1.3 20070402 (prerelease)
(2) system type: CYGWIN_NT-5.1 1.5.24(0.156/4/2) 2007-01-31 10:57
(3) The options given when GCC was configured/built:
../configure --enable-languages=c,c++,objc,fortran,java
--cache-file=build_cache.dat
(4) The complete command line that triggers the bug
/usr/local/bin/gcc -c -I. -DHAVE_CONFIG_H -DMODULE -Wall -Wmissing-prototypes
-O2 -o rlimits..o rlimits.c
(5)the compiler output (error messages, warnings, etc.):
rlimits.c: In function 'bin_unlimit':
rlimits.c:663: error: unrecognizable insn:
(insn 45 44 46 5 (set (reg:SI 84)
(const:SI (plus:SI (mem:SI (symbol_ref:SI ("#i.current_limits")
) [0 S4 A8])
(const_int 4 [0x4] -1 (nil)
(nil))
rlimits.c:663: internal compiler error: in extract_insn, at recog.c:2084
Please submit a full bug report,
with preprocessed source if appropriate.
(6) The preprocessed file (*.i*) that triggers the bug, generated by adding
-save-temps to the above command line which triggers the bug.
Line# 633 of "rlimits.c" is:
for (; *argv; argv++) {
--- This occurred while trying to compile
zsh VERS=4.3.2
zsh source at: ftp://ftp.zsh.org/zsh
Hopefully this information helps.
Regards,
d. henman
--
Summary: Internal Compiler Error
Product: gcc
Version: 4.1.3
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: henman at it dot to-be dot co dot jp
GCC target triplet: i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31457
[Bug c++/31456] New: stringstream behaves unexpectedly
First of all some code that behaves as expected:
#include
#include
using namespace std;
int main(int argc, char argv[])
{
stringstream name;
name << "abcde";
name << 123;
cout << name.str() << endl;
}
Output: abcde123
Now if we change the first two lines of main() to get:
int main(int argc, char argv[])
{
stringstream name("abcde");
name << 123;
cout << name.str() << endl;
}
the output changes to: 123de. So the initialization string gets overwritten
instead of appending the data. Inserting name.seekp(0, ios::end); helps, but
only for compiler version 4.0, not for 4.1 (at least I think so, I couldn't
test this enough ATM).
Now trying to get the right behaviour by using stringstream name("abcde",
ios::app); or stringstream name("abcde", ios::ate); leads to another
interesting output: abcde. The input gets completely ignored.
In my Stroustrup I only found a specification for the behaviour of
ostringstream, not for stringstream but using ostringstream instead of
stringstream doesn't change anything and I don't think stringstream should
behave like this anyway (especially in contrast to the first example).
I hope I didn't waste your time because the bug already got fixed in 4.3 or
something, but I couldn't find anything neither in Bugzilla nor via Google.
Many thanks and kind regards,
Christian
PS: I tested this with g++ 4.0.3 on Ubuntu GNU/Linux, with g++ 4.1 on some SuSE
and with g++ 3.4.3 on SunOS 5.10, all Intel CPUs.
--
Summary: stringstream behaves unexpectedly
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: cmertes at techfak dot uni-bielefeld dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31456
