--- Comment #41 from anlauf at gmx dot de 2007-04-02 08:42 ---
(In reply to comment #40)
> New Revision: 123404
>
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123404
> Log:
> 2007-04-01 Jerry DeLisle <[EMAIL PROTECTED]>
Jerry,
thanks so far, but now I am back to the situa
I get the following ICE:
test.f90: In function MAIN__:
test.f90:29: internal compiler error: in gfc_get_symbol_decl, at
fortran/trans-decl.c:877
Please submit a full bug report,
when compiling this code:
module InternalCompilerError
type Byte
private
character(len=1) ::
Motohisa Moriya wrote:
-#if defined (__SH3E__) || defined (__SH4__)
+#if defined (__SH4E__) || defined (__SH4__)
There's no such thing as an SH4E. There is an SH3E and it shares the
same single-precision support as SH4, thus there are some places where I
would expect to see such an #if.
I d
--- Comment #65 from bkoz at redhat dot com 2007-04-02 09:49 ---
Subject: Re: __cplusplus defined to 1, should be 199711L
> Weird, when solaris is the easiest one.
That's certainly a matter of perspective.
>> Based on Solaris 11 x86, I don't see a way for say cstdlib to have only th
Andrew STUBBS wrote:
>There's no such thing as an SH4E. There is an SH3E and it shares the
>same single-precision support as SH4, thus there are some places where I
>would expect to see such an #if.
It is said that the libgcc.a multi-library cannot be made because an impossible
register is ref
--- Comment #4 from pluto at agmk dot net 2007-04-02 10:13 ---
attached testcase works fine with vs2k3/boost-1.33/stlport.
it also works with g++-4.0.0/20050519(RH 4.0.0-8)/boost/libstdc++
on x86_64-gnu-linux. in the other. indeed, it fails with 4.1.2
and 4.2.0 (4.3 not tested).
--
Motohisa Moriya wrote:
Andrew STUBBS wrote:
There's no such thing as an SH4E. There is an SH3E and it shares the
same single-precision support as SH4, thus there are some places where I
would expect to see such an #if.
It is said that the libgcc.a multi-library cannot be made because an imp
--- Comment #11 from pcarlini at suse dot de 2007-04-02 10:32 ---
Ok, therefore we cannot consider anymore the issue a libstdc++ issue.
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #5 from paolo at gcc dot gnu dot org 2007-04-02 11:09 ---
Subject: Bug 31401
Author: paolo
Date: Mon Apr 2 11:08:50 2007
New Revision: 123422
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123422
Log:
2007-04-02 Paolo Carlini <[EMAIL PROTECTED]>
PR libstd
--- Comment #6 from paolo at gcc dot gnu dot org 2007-04-02 11:09 ---
Subject: Bug 31401
Author: paolo
Date: Mon Apr 2 11:09:07 2007
New Revision: 123423
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123423
Log:
2007-04-02 Paolo Carlini <[EMAIL PROTECTED]>
PR libstd
--- Comment #9 from paolo at gcc dot gnu dot org 2007-04-02 11:16 ---
Subject: Bug 31370
Author: paolo
Date: Mon Apr 2 11:15:50 2007
New Revision: 123424
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123424
Log:
2007-04-02 Matthew Levine <[EMAIL PROTECTED]>
Paolo
--- Comment #10 from pcarlini at suse dot de 2007-04-02 11:19 ---
Fixed for 4.3.0.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from pault at gcc dot gnu dot org 2007-04-02 11:33 ---
(In reply to comment #0)
> As indicated in the comments, the ICE is caused by the line passing a function
Sort of: In order to find out the size of the function result, gfortran
evaluates transfer(user, BytesPrototyp
Andrew STUBBS wrote:
>Sorry, I find this very hard to read. I think you found it very hard to
>write. :)
>I do not say that the code is right. I say that changing SH3E to SH4E is
>wrong. It might be that completely removing SH3E is right. Perhaps the
>error is somewhere else.
>Kaz, I don't know
Motohisa Moriya wrote:
I am wishing that all of SH2,SH2E, SH3, SH3E, SH4, and SH4E can be compiled with
sh-unknown-linux-gnu-gcc.
SH4E does not exist.
Perhaps you mean SH4A?
--- Comment #2 from pault at gcc dot gnu dot org 2007-04-02 12:51 ---
To my amazement, the brute force:
Index: gcc/fortran/trans-decl.c
===
*** gcc/fortran/trans-decl.c(révision 122688)
--- gcc/fortran/trans-decl.c(
Hi All,
I am trying to compile cfengine. I was using gcc version 4.0.2 and was facing
an error. I found that the my problem is due to a bug that has been fixed and
in version 4.1 onwards.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26189
I rebuild it with gcc version 4.1.2 (binary available on
ht
Andrew STUBBS wrote:
>Perhaps you mean SH4A?
yes
Because my debian environment has crashed, -m option cannot be confirmed
Please point it out if the mistake is found in my idea.
SH2A Core
SH2,SH3
SH4A Core
SH4
(SH5 is unknown)
Motohisa
Hi Andrew,
Andrew STUBBS <[EMAIL PROTECTED]> wrote:
> I do not say that the code is right. I say that changing SH3E to SH4E is
> wrong. It might be that completely removing SH3E is right. Perhaps the
> error is somewhere else.
>
> Kaz, I don't know if you have already seen this message. Perhaps
--- Comment #42 from jvdelisle at gcc dot gnu dot org 2007-04-02 14:35
---
Will keep open until we get them all!. Looks like I need another test case. :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31052
--- Comment #3 from pault at gcc dot gnu dot org 2007-04-02 14:43 ---
(In reply to comment #2)
> an ICE in the same place, but it appears it isn't fixed. Paul, since the
> previous PRs were really related, you might understand this one easily?
I had hoped so, but the problem here turns
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
When the compiler is provided with -std=c++0x to enable the experimental C++0x
mode, includes of TR1 facilities (e.g., tr1/tuple) do not put TR1 functionality
into namespace std::tr1, breaking backward compatibility. Here's an example
program that compiles without -std=c++0x but does not compile wi
--- Comment #3 from hjl at gcc dot gnu dot org 2007-04-02 15:54 ---
Subject: Bug 31380
Author: hjl
Date: Mon Apr 2 15:53:48 2007
New Revision: 123428
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123428
Log:
2007-04-02 H.J. Lu <[EMAIL PROTECTED]>
* Backport from mai
--- Comment #4 from hjl at gcc dot gnu dot org 2007-04-02 15:55 ---
Subject: Bug 31380
Author: hjl
Date: Mon Apr 2 15:55:17 2007
New Revision: 123429
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123429
Log:
2007-04-02 H.J. Lu <[EMAIL PROTECTED]>
* Backport from mai
--- Comment #5 from hjl at lucon dot org 2007-04-02 15:57 ---
Fixed in gcc 4.1.3 and 4.2.0.
--
hjl at lucon dot org changed:
What|Removed |Added
Status|UNCONF
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-04-02 16:18 ---
isn't that a feature?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31426
--- Comment #94 from bonzini at gnu dot org 2007-04-02 16:20 ---
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
--- Comment #7 from bonzini at gnu dot org 2007-04-02 16:21 ---
Reopened...
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|RESOLVED
--- Comment #8 from bonzini at gnu dot org 2007-04-02 16:22 ---
... because GCC now has -mpc to limit precision for float/double operations.
Even as far as x86 is concerned, this is a "special case" of PR323, and thus
I'm closing it as fixed.
--
bonzini at gnu dot org changed:
--- Comment #2 from dgregor at gcc dot gnu dot org 2007-04-02 16:32 ---
I don't think it is a feature.
In C++0x mode, if one includes , one should get std::tuple. That's what
the C++0x working paper says.
In any mode, if one includes , one should get std::tr1::tuple.
That's what TR1 s
--- Comment #31 from sje at cup dot hp dot com 2007-04-02 16:36 ---
When configuring with --with-system-libunwind, GCC should not include
unwind-compat.o (or any unwind code) in the build of libgcc_s. Then the
configure check will work correctly.
--
http://gcc.gnu.org/bugzilla/show
--- Comment #2 from pault at gcc dot gnu dot org 2007-04-02 16:38 ---
This fixes the problem and regtests:
Index: gcc/fortran/parse.c
===
*** gcc/fortran/parse.c (révision 123426)
--- gcc/fortran/parse.c (copie de travail)
--- Comment #1 from bangerth at dealii dot org 2007-04-02 17:09 ---
Confirmed.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
CC|
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-04-02 17:26 ---
Ah, I see.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #3 from eweddington at cso dot atmel dot com 2007-04-02 17:41
---
Can someone please commit this patch? I need this for mingw-hosted cross
toolchains.
--
eweddington at cso dot atmel dot com changed:
What|Removed |Added
---
--- Comment #14 from tkoenig at gcc dot gnu dot org 2007-04-02 17:44
---
I'll give this another shot.
Maybe inlining isn't even necessary for good performance...
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
-
When I compile the following program I get the message "GNU MP: Cannot
reallocate memory"
PROGRAM test
INTEGER(KIND=1) :: i(1)
i = (/ TRANSFER("a", 0) /)
END PROGRAM test
--
Summary: When I compile the following program I get the message
"GNU MP: Cannot reallocate
--- Comment #7 from jason at gcc dot gnu dot org 2007-04-02 18:49 ---
Subject: Bug 31187
Author: jason
Date: Mon Apr 2 18:49:21 2007
New Revision: 123432
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123432
Log:
PR c++/31187
When I compile the following program I get the message "GNU MP: Cannot
reallocate memory"
PROGRAM test
INTEGER(KIND=1) :: i(1)
i = (/ TRANSFER("a", 0) /)
END PROGRAM test
--
Summary: When I compile the following program I get the message
"GNU MP: Cannot reallocate
--- Comment #1 from kargl at gcc dot gnu dot org 2007-04-02 19:06 ---
*** Bug 31428 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31427
--- Comment #1 from kargl at gcc dot gnu dot org 2007-04-02 19:06 ---
*** This bug has been marked as a duplicate of 31427 ***
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--
--
Summary: Is anybody monitoring the daily regression tests on
Darwin 8.5?
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at
(~100) of regressions: gcc.c-torture/execute/builtins/memcpy-chk.c, ...,
gcc.c-torture/execute/built-in-setjmp.c. Looking at the list, I have found
that this has started on 20070325 for Darwin8:
http://gcc.gnu.org/ml/gcc-testresults/2007-03/msg01225.html
Note that the errors are all of the follo
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-02 20:05 ---
This was caused by the conversion of "l" constaint to hard registers. I sent a
patch to Andreas T. to test as I don't have an up todate sources on my
ppc-darwin machine that I use to test patches.
--
pinskia at
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-02 20:05 ---
*** This bug has been marked as a duplicate of 31429 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-04-02 20:05 ---
*** Bug 31430 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31429
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-04-02 20:10 ---
Can confirm a crash in f951. Since there were quite a lot of TRANSFER related
reports lately, I can not tell if this a new one.
Backtrace:
Starting program:
/home/daniel/i686-pc-linux-gnu/gcc/libexec/gcc/i686-pc-lin
--- Comment #8 from jason at gcc dot gnu dot org 2007-04-02 20:12 ---
Subject: Bug 31187
Author: jason
Date: Mon Apr 2 20:12:15 2007
New Revision: 123434
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123434
Log:
PR c++/31187
The following (IMHO invalid) code snippet triggers an ICE on mainline:
===
template void foo();
void bar()
{
foo();
}
===
bug.cc: In function 'void bar()':
bug.cc:5: internal compile
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31431
More fallout from the variadic templates on mainline:
===
template struct A
{
enum { N };
};
A a;
===
bug.cc:1: error: parameter pack '' must be at the end
of the template parameter
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-04-02 20:27 ---
Adding this to TRANSFER meta-bug, as frame 3 in the backtrace indicates a
relation. No confirmation as I can not tell whether it is a dupe or not.
(gdb) bt
#0 fancy_abort (file=0x86e4fec "../../../gcc/gcc/fortran/t
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31432
More fallout from the variadic templates on mainline:
===
template struct A
{
static int i;
};
A a;
A b;
===
bug.cc:1: error: parameter pack '' must be at the end
of the template par
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31433
More fallout from the variadic templates on mainline:
===
template void foo(const T...) {}
void bar()
{
foo(0);
}
===
bug.cc: In function 'void foo(T ...) [with T = int]':
bug.cc:5:
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31434
--- Comment #9 from malitzke at metronets dot com 2007-04-02 20:39 ---
I believe this report can be closed. I was able to find the start date
(2061125)
or a day later when I could no longer bootstrap. It disappeared towards the end
of January 2007. It prevented bootstrapping on x86 but n
--- Comment #32 from schwab at suse dot de 2007-04-02 20:42 ---
unwind-compat is _required_ for the system libunwind.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26792
More fallout from the variadic templates on mainline:
===
template void foo(T) {}
void bar()
{
foo(0);
}
===
bug.cc:1: error: parameter packs not expanded with `...':
bug.cc:1: note:
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31435
More fallout from the variadic templates on mainline:
===
template int foo(const T&)
{
union { T t; };
return t;
}
void bar()
{
foo(0);
}
===
bug.cc:1: error: parameter packs not
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31436
More fallout from the variadic templates on mainline:
===
template struct A
{
A(T* p) { (A*)(p); }
};
A a(0);
===
bug.cc:3: error: parameter packs not expanded with `...':
bug.cc:3:
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31437
More fallout from the variadic templates on mainline:
===
template struct A;
template struct A
{
template A(X);
};
A a(0);
===
bug.cc:3: error: parameter packs not expanded with `..
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31438
More fallout from the variadic templates on mainline:
===
template struct A;
template struct A<> {};
template struct A : A {};
A a;
===
bug.cc:3: error: template parameters not used
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31439
Making all in Core
make[3]: Entering directory
`/var/tmp/portage/dev-lang/maude-2.1.1-r2/work/maude-2.1.1/src/Core'
if g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../../src/Utility
-I../../src/Interface -I../../src/Variable -I../../src/FullCompiler -O2 -pipe
-mcpu=G4 -fomit-frame-pointer -Wno-deprecat
More fallout from the variadic templates on mainline:
===
template struct A;
template struct A {};
A a;
===
bug.cc:3: error: cannot expand 'T ...' into a fixed-length argument list
bu
--- Comment #15 from tkoenig at gcc dot gnu dot org 2007-04-02 21:00
---
The library version doesn't do too badly compared
to the inline version:
$ cat benchmark-inline.f90
program main
implicit none
integer, dimension(1) :: n
real, allocatable :: a(:)
integer :: i
allocate
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31441
More fallout from the variadic templates on mainline:
===
template struct A {};
struct B
{
template class C> B(C);
};
B b = A();
===
bug.cc:1: error: parameter packs not expanded w
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31442
More fallout from the variadic templates on mainline:
===
template struct A
{
template void foo(A);
};
void bar()
{
A<0,int>().foo(A<0,int>());
};
===
bug.cc:3: error: parameter pa
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31443
More fallout from the variadic templates on mainline:
===
template struct A
{
template void foo(A);
};
void bar()
{
A().foo<0>(A());
};
===
bug.cc:3: error: parameter packs not exp
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31444
--- Comment #3 from ramiro at lisha dot ufsc dot br 2007-04-02 21:24
---
Hello,
That and many other combinations fix the issue. Including changing the code
around the inline asm, or using different optimizations.
What seems wrong is that gcc uses the same register for 2 outputs. Maybe
More fallout from the variadic templates on mainline:
===
template struct A
{
void foo(T...);
A(T... t) { foo(t); }
};
A a(0);
===
This is only a diagnostic problem in the second
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31445
--- Comment #8 from maskva at searxhmash dot com 2007-04-02 21:27 ---
Created an attachment (id=13319)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13319&action=view)
ned
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=192
The following invalid code snippet triggers an ICE on mainline and 4.2 branch:
===
template struct A
{
template friend void foo();
};
void bar()
{
foo<0>();
}
===
bug.cc:1: error:
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31446
--- Comment #1 from pcarlini at suse dot de 2007-04-02 21:41 ---
Thanks for your report. Luckily you have been able to notice this before the
release of 4.3.0...
--
pcarlini at suse dot de changed:
What|Removed |Added
--
It would be nice if gfortran had an option to set intent(out) arguments to NaN
or some random values, so that code mistakenly relying on intent(out) arguments
starting with the same value as in the caller would be detected. This is
related to the question of detecting on uninitialized variables.
F
--- Comment #5 from reichelt at gcc dot gnu dot org 2007-04-02 21:52
---
Any news on this one?
The bug makes tree vectorization on pentium 4 totally useless. :-(
Btw, here's a smaller code snippet for testing. Just compile it with
gcc -O -msse2 -ftree-vectorize
on a pentium 4 and see
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-04-02 22:13
---
> It seems that many maintainers ar not doing the complete (and quite time
> consuming bootstrapping) during the non-regression period.
I think that is wrong as most are, just some forgot to double check. Like a
typedef struct _st {
int iIndex : 24;
} st;
void f(void)
{
st *next = 0;
int nIndx;
const static int constreg[] = { 0,};
nIndx = 0;
next->iIndex = constreg[nIndx];
}
[EMAIL PROTECTED]:~$ ~/x86-linux-4.0.2/bin/gcc t2.c -O1
t2.c: In function 'f':
t2.c:10: internal compiler
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.0.4 4.1.2 4.2.0 4.3.0
Known to work|
--- Comment #2 from aesok at gcc dot gnu dot org 2007-04-02 22:44 ---
Subject: Bug 31137
Author: aesok
Date: Mon Apr 2 22:43:53 2007
New Revision: 123437
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123437
Log:
PR target/31137
* config/avr/avr.c (avr_rtx_costs
--- Comment #7 from giovannibajo at libero dot it 2007-04-02 22:47 ---
Anatoly, can you have a look? It's a regression in 4.2 for AVR!
--
giovannibajo at libero dot it changed:
What|Removed |Added
---
--- Comment #18 from burnus at gcc dot gnu dot org 2007-04-02 22:49 ---
Is this PR fixed or not? Looking at the initial and the additional example, it
seems to be fixed both in 4.2 and in 4.3. Can this PR be closed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31099
--- Comment #3 from aesok at gcc dot gnu dot org 2007-04-02 22:53 ---
Subject: Bug 31137
Author: aesok
Date: Mon Apr 2 22:53:14 2007
New Revision: 123438
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123438
Log:
PR target/31137
* config/avr/avr.c (avr_rtx_costs
--- Comment #4 from aesok at gcc dot gnu dot org 2007-04-02 23:00 ---
Subject: Bug 31137
Author: aesok
Date: Mon Apr 2 23:00:28 2007
New Revision: 123439
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123439
Log:
PR target/31137
* config/avr/avr.c (avr_rtx_costs
--- Comment #5 from aesok at gcc dot gnu dot org 2007-04-02 23:03 ---
Fixed.
--
aesok at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #3 from burnus at gcc dot gnu dot org 2007-04-02 23:10 ---
Hmm, I cannot reproduce this on x86_64-unknown-linux-gnu/openSUSE 10.2 with
either gcc 4.2 (vanilla) nor with gcc 4.3 (current SVN, very mildly patched)
and with neither -m32 nor -m64 running under valgrind. (This is
--- Comment #8 from manu at gcc dot gnu dot org 2007-04-02 23:25 ---
Fixed in GCC 4.3, if someone wants to backport it to old branches, go ahead,
the patch should apply cleanly and the Changelog would be similar.
--
manu at gcc dot gnu dot org changed:
What|Removed
1 - 100 of 121 matches
Mail list logo
