--- 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/sh
--- 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
--- 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.
--- 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
--- 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
--- 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
--- 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
--- 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
---
--- 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 yo
--- 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.
-
--- 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
--- 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 @
--- 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
--- 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
--- 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 (
--- 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 ( [ fo
--- 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
--- 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
---
--- 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 n
--- 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
-
--- 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:
Wha
--- 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
---
--- 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:/
--- 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/AutovectBranchOptim
--- 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 allocato
--- 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
implement
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
--- 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
--- 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
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 tes
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 h
--- 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
--- 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
---
--- 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
--
--- 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 i
--- 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
--
--- 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
---
--- 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
--- 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 becau
--- 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_cat
--- 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
---
--- 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
--
--- 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 <
--- 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
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
--- 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
(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 translat
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
--- 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 m
--- 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.
--- 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.
--- 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.
--- 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
ht
--- 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 a
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];
#e
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(d
--
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
--- 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
--- 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
--- 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 second
--- 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 &&
--- 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
--- 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
--- 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
--- 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
--
--- 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_
--- 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
thi
--- 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
--- 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 (wo
--- 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
--- 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
--- 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
--- 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
--- 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
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
Ver
--- 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): Expan
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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 an
--- 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_encod
--- 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
--- 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_encod
--- 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
--- 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
---
--- 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|Re
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dannysmith at users dot
|dot org
--- 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/
--- 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 or
--
pcarlini at suse dot de changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31440
--- 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
--- 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 libstd
--- 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
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
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(in
97 matches
Mail list logo
