This approach seems reasonable. The current structure of the code
in simplify_replace_rtx is intended to handle RTL expressions rather
than patterns, so normally it would be passed just SET_SRC (pat),
instead of the whole set.
Which is why, OTOH, I would be *extremely* cautious doing such a
Maybe everyone else manages to get good code without something like
TER.
That's because we lack other things that people have, like a sane
instruction selection and expression reordering pass: other compilers
probably have something akin to TER as part of instruction selection.
Like many
The following code:
#include stdio.h
void Switch4(int x) {
switch (x 7) {
case 0: printf(0\n); break;
case 1: printf(1\n); break;
case 2: printf(2\n); break;
case 3: printf(3\n); break;
case 4: printf(4\n); break;
case 5: printf(5\n); break;
case 6: printf(6\n);
On 8/19/05, Jonathan Wakely [EMAIL PROTECTED] wrote:
WU Yongwei wrote:
Well, I see this in the gcc error message. Can someone here kindly
point to me which part of the Standard specified this behaviour? I
thought it should be in 5.3.4, but was not able to find the words
there.
[snipped]
Hi,
i just built GCC 4.0.1 on AIX 5.1 using the following commands:
../gcc-4.0.1/configure --with-libiconv-prefix=/usr --disable-nls
--disable-multilib
make bootstrap-lean
make install
$ config.guess
powerpc-ibm-aix5.1.0.0
$ gcc -v
Using built-in specs.
Target:
It looks like Jan's patch at
http://gcc.gnu.org/ml/gcc-patches/2005-07/msg02021.html is causing a
code size regression in i686. I'll consider a 32-bit target, and this
testcase
char **
VTallocbuf(char **allbuf, unsigned long savelines)
{
return allbuf[savelines];
}
For i686 we
I disbelieve you can get this in C or C++. The fragment above is a
syntax error. AFAIK, all of this is simple laziness in the Ada front
end: generating constructor is how things were done at the
beginning of time, and it was easier to change this in the gimplifier
than to
void Switch4(int x) {
switch (x 7) {
}
}
.globl _Switch4
.def _Switch4; .scl 2; .type 32; .endef
_Switch4:
pushl %ebp
movl %esp, %ebp
movl 8(%ebp), %eax
andl $7, %eax
cmpl $7, %eax
ja L12
jmp *L11(,%eax,4)
cmpl+ja are redundant in both cases.
Do you think it is possible for gcc to
Haren Visavadia wrote:
You missed The GCC team has been urged to drop
support for SCO Unix from GCC, as a protest against
SCO's irresponsible aggression against free software.
When starting my Unix learnings with SCO Xenix/286,
SCO Xenix/386 and SCO Unix (all some kind of trademarks),
I have
Hello,
I would like to know if someone knows a suitable branch for the sign
extension optimization pass.
This pass stands for itself. There are not many changes to the other
parts of the gcc.
For details see:
http://gcc.gnu.org/ml/gcc-patches/2005-08/msg01087.html
Thanks,
Leehod.
Paolo Bonzini [EMAIL PROTECTED] wrote on 22/08/2005 10:10:40:
I tried to use simplify_replace_rtx to replace any use of (reg r)
with[in]
the right-hand-side of the extension and simplify the result.
If he want to replace uses within the RHS of the extension, he should
pass SET_SRC
On Monday 22 August 2005 09:28, Paolo Bonzini wrote:
I think Zdenek's patch is fine, because *everything* in TER is a hack.
My thoughts exactly ;-)
Zdenek, maybe you could you try and see if enabling pre-regalloc
scheduling would also make this particular problem you're seeing go
away,
Note that I don't want to replace any *def* and uses may appear in the
LHS.
Ok, I see. But you have to cope with *def*s appearing in the LHS: you
don't want to replace them, yet your modified simplify_replace_rtx will!
My plan was to use: replace_regs () to replace every use of (reg r)
On Mon, Aug 22, 2005 at 03:37:27PM +0200, Paolo Bonzini wrote:
It may still make sense changing the default case of
simplify_replace_rtx to invoke replace_rtx rather than returning x. But
this is unrelated, because nobody is currently passing a SET to
simplify_replace_rtx (only
Mark Mitchell [EMAIL PROTECTED] writes:
My first comment is that we had a lot of bugs targeted at 4.1.0 that
should never have been so targeted. Please remember that bugs that do
not effect primary or secondary targets should not have a target
milestone. There are several PRs that seem to
Piotr Wyderski wrote:
I have disassembled my program produced by g++ 4.0.0
and I see a very strange behaviour -- the compiler doesn't
generate cmov-s (-O3 -march=pentium3). G++ 3.4 generates
them. So, how can I reactivate cmov-s in the newest version
of the compiler? fif-conversion doesn't
While researching who is really using flow's computed LOG_LINKS, I found
a define_split in the rs6000 back-end that uses them through
find_single_use. It turns out the only users are combine, this split,
and a function in regmove.
The split dates back to revision 1.5 of old-gcc.
;; If we
[EMAIL PROTECTED] wrote:
1. bootstrapping the gcc 4.0.1 under Sparc/Solaris I found that the
building in fixincludes uses the gcc (with no PATH specification)
instead of the xgcc build by the last stage. It may crash, it happens on
my environment, because I've migrated from Solaris 9 to
Paolo Bonzini writes:
Paolo I'm testing a patch that does this replacement, and I can post it
Paolo tomorrow morning. It has triggered only a dozen times so far (half in
Paolo libgcc, half in the compiler), but it may be worth keeping it.
It would be nice to keep this type of
Ian Lance Taylor wrote:
Mark Mitchell [EMAIL PROTECTED] writes:
My first comment is that we had a lot of bugs targeted at 4.1.0 that
should never have been so targeted. Please remember that bugs that do
not effect primary or secondary targets should not have a target
milestone. There are
I think that the structure 'struct loop_info' in loop.c could be shrinked a
bit if all the 'int has_XXX' fields where turned into a bitfield just as in
'struct iv_class' or 'struct induction' in the same file.
I don't know if it worse it (in term of memory usage reduction) neither the
impact in
On Sun, 2005-08-21 at 20:32 +0200, Falk Hueffner wrote:
Hi,
I'm trying to implement a tree pass that warns about bad array
accesses as suggested for PR 8268 by Jeff Law. However, I have trouble
with the following:
char digit_vector[5];
const char *ggc_alloc_string(int length) {
Warning for pointer generation is going to be a *lot* harder and I
suspect will always result in more false positives.
In order to increase the accuracy of the data dependence analysis, i do,
at some point, plan on tracking the sizes of malloc sites, and giving an
upper bound on them (for
There is some clever code in convert_to_real that converts
double d;
(float)floor(d)
to
floorf((float)d)
(on targets where floor and floorf are considered builtins.)
This is wrong, because the (float)d conversion normally uses
round-to-nearest and can round up to the next integer. For
This test assumes that integer constants passed as varargs are
promoted to a type at least as big as long, which is not valid on 16
bit hosts. For example:
void
f1 (int i, ...)
{
va_start (gap, i);
x = va_arg (gap, long);
int
main (void)
{
f1 (1, 79);
if (x != 79)
abort ();
I'm porting a back-end for gcc.
My back-end crached in the compile test pattern 990203-1.c, and
the error message is
main.c:7: internal compiler error: in purge_addressof, at
function.c:3423
for (insn = insns; insn; insn = NEXT_INSN (insn))
if (INSN_P (insn))
{
if (!
--- Additional Comments From dank at kegel dot com 2005-08-22 06:33 ---
Yes, Tommy mailed the patch, see
http://gcc.gnu.org/ml/gcc-patches/2005-08/msg01195.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23358
--- Additional Comments From dank at kegel dot com 2005-08-22 06:34 ---
I think the patch applies cleanly to gcc-4.0.x;
it's so small, seems like the target for this bug
ought to be gcc-4.0.2.
--
What|Removed |Added
gcc generates wrong code
command line: gcc -O2
works on: 3.4.4, 4.1.0-20050819
wrong code on: 4.0.1, 4.0.2-20050818
I am just guessing at the priority + severity levels.
Test program attached. It can be compiled and run standalone -- it succeeds
normally, and aborts if wrong-code is generated.
--- Additional Comments From mec at google dot com 2005-08-22 06:59 ---
Created an attachment (id=9551)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9551action=view)
source file to demonstrate wrong code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23512
--- Additional Comments From lars dot sonchocky-helldorf at hamburg dot de
2005-08-22 07:04 ---
(In reply to comment #3)
Objective-C is not release-critical.
Sadly so. This is a very cheap way to get the numbers of bugs down for a
release. :-(
--
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-22
08:37 ---
Subject: Bug 23089
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-08-22 08:37:18
Modified files:
gcc/cp : ChangeLog decl.c
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-22
08:48 ---
Subject: Bug 23089
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-08-22 08:48:06
Modified files:
gcc/cp :
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-08-22
08:49 ---
Fixed on mainline and the 4.0 branch.
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From micis at gmx dot de 2005-08-22 09:03 ---
This ICE is still present with the actual snapshot (20050819)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22480
This well-formed complete source is rejected by g++, but compiles fine
with comeau online 4.3.3 BETA August 4, 2003.
A related discussion on clc++ http://groups-beta.google.com/group/comp.
lang.c++/msg/1475f4e8f1ff9982
struct A
{
templateclass T void operator(T);
};
templateclass T struct B
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-22
09:48 ---
Subject: Bug 22233
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-08-22 09:48:26
Modified files:
gcc/cp : ChangeLog pt.c
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-22
09:55 ---
Subject: Bug 22233
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-08-22 09:54:43
Modified files:
gcc/cp :
--- Additional Comments From amodra at bigpond dot net dot au 2005-08-22
10:05 ---
http://gcc.gnu.org/ml/gcc-patches/2005-08/msg01277.html
--
What|Removed |Added
the bug should be only in windows OS
my test evnironment is win2k and win xp.
they are not work well.
I have try those compiler:
Gnat 3.15 p / mingw 3.42 / mingw 4.1
--the test code is
With Ada.Text_Io;
Procedure Trading Is
Type Price Is Delta 0.01 Digits 18;
Type PriceArray Is Array
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-22
10:49 ---
This is most likely a dup of PR 23326.
--
What|Removed |Added
Component|c++
--
What|Removed |Added
Keywords||ice-on-valid-code
Summary|Segfault in fold_binary |[4.1 Regression] Segfault in
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-08-22
11:01 ---
I'm not confident that using salq in Steven's test case is really a
pessimization. I'll consider a 32-bit target then, and this testcase
char **
VTallocbuf(char **allbuf, unsigned long savelines)
{
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-22
11:06 ---
Reducing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23511
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-08-22
11:17 ---
Fixed on mainline and 4.0 branch.
--
What|Removed |Added
Summary|[3.4/4.0/4.1
--
What|Removed |Added
Keywords||rejects-valid
Known to fail||4.0.2 4.1.0
Known to work|
--- Additional Comments From v dot haisman at sh dot cvut dot cz
2005-08-22 11:21 ---
I have tried it and successfully bootstrapped the compiler with. It works,
thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21268
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-22
11:46 ---
(In reply to comment #2)
How does the C front end represent this expression?
Using a COMPOUND_LITERAL_EXPR which should solve this and PR 23172.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23171
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-22
11:50 ---
Confirmed, reduced testcase:
struct locale_data {
int t;
union locale_data_value {
const char *string;
}values [];
};
void f(const char*);
extern const struct locale_data _nl_C_LC_TIME ;
--- Additional Comments From veldema at cs dot fau dot de 2005-08-22 12:03
---
1) I will file a bug report with SUN and see what they say and report back here
2) I read the comments with _dtoa and for floats the arg is interpretted as
single-precision if mode = 16 (seems for a double
--- Additional Comments From gcc-bugzilla2 at imperialviolet dot org
2005-08-22 12:11 ---
I have the same problem when building Gambit (a Scheme-C compiler). Since the
original reporter doesn't seem to have replied to the request for a -save-temps
file I thought that mine could be of
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-22
12:15 ---
Yes looking at the tree dumps comfirm that this is a dup of bug 23326 which
already have a patch for.
*** This bug has been marked as a duplicate of 23326 ***
--
What|Removed
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-22
12:15 ---
*** Bug 23512 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--
What|Removed |Added
Severity|normal |minor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17506
--- Additional Comments From veldema at cs dot fau dot de 2005-08-22 12:18
---
Confirmed, this is a bug in SUN's JDK since 2001.
Perhaps a a bug should be introduced to make libgcj/classpath bug compatible ?
if (double_string == 0.00x x != '0') return return 0.00x0
should do the
--
What|Removed |Added
Severity|normal |minor
GCC build triplet|i686-pc-linux-gnu |
GCC host triplet|i686-pc-linux-gnu |
GCC
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-22
12:25 ---
As I mentioned, this will be come a regression again once fixing PR 21559.
--
What|Removed |Added
--- Additional Comments From sebastian dot pop at cri dot ensmp dot fr
2005-08-22 12:34 ---
The following patch fixes the problem. However I cannot boot'n'regtest
it for the moment. I will commit it only tomorow once it is validated.
seb
*** tree-ssa-loop-niter.c.~2.39.~
--- Additional Comments From sebastian dot pop at cri dot ensmp dot fr
2005-08-22 12:38 ---
(In reply to comment #14)
(In reply to comment #9)
If we really wanted to tackle this better a compile-time, we'd run a
pass to look at all the ARRAY_REFs for those which have an
--
What|Removed |Added
Severity|critical|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23514
--
What|Removed |Added
Severity|critical|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11707
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-22
12:49 ---
Fixed, classpath should be merged soon too.
--
What|Removed |Added
Status|NEW
--- Additional Comments From robilad at kaffe dot org 2005-08-22 13:25
---
It seems to be clearly a bug in how some non-free implementation implements the
specifications.
Since Sun Microsystems has confirmed the bug in their implementation, and the
specification is clear on the matter,
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-22
13:35 ---
This is not a bug. You have a macro max which is defined and so you get:
std::(((size())(__n))?(size()):(__n)) which is a bug.
It is a bug in your code.
--
What|Removed
--- Additional Comments From gcc-bugzilla2 at imperialviolet dot org
2005-08-22 13:00 ---
An uncomfortable, but functional, solution this this problem is to replace
std::max with max on each of the erroring lines. Since the STL lives in the std
namespace anyway I think this should work
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |nathan at gcc dot gnu dot
|dot org |org
Status|NEW
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org |
URL|
--- Additional Comments From tromey at gcc dot gnu dot org 2005-08-22
15:00 ---
I would prefer to leave the PR open to address the _dtoa issue.
I've updated the PR synopsis to reflect this.
I agree that we should not change our toString output, as ours is
correct.
--
What
--- Additional Comments From amodra at bigpond dot net dot au 2005-08-22
15:24 ---
-m405 -many works for any gas later than 20030904. Versions earlier than that
date will suffer from the problem reported here. gcc (now) documents that
binutils 2.15 is needed for powerpc.
--
[EMAIL PROTECTED] mytests]# cat foo.f90 program foo
common /x/ a
a = 1
call bar ()
contains
subroutine bar ()
equivalence (a,b)
print *, b
end subroutine bar
end program foo
[EMAIL PROTECTED] mytests]# /gcc-4.0/bin/gfortran foo.f90
foo.f90: In function MAIN__:
foo.f90:8:
The following code does not compile
program bug
implicit none
double complex blop
double precision blopr
blopr=imag(blop)
blopr=sin(blop)
end
removing implicit none will let the code to compile. The compiler accepts sin
as a generic function but
not
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-22
16:21 ---
Subject: Bug 18175
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-08-22 16:21:19
Modified files:
gcc: ChangeLog c-common.c
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-22
16:21 ---
Subject: Bug 18715
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-08-22 16:21:19
Modified files:
gcc: ChangeLog c-common.c
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-22
16:23 ---
Ignore that commit, I got 7 and 1 switched around.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18175
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-22
16:26 ---
Subject: Bug 18715
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-08-22 16:26:06
Modified files:
gcc/testsuite : ChangeLog
Log message:
Fix
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-22
16:28 ---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-22
16:29 ---
Subject: Bug 18715
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-08-22 16:29:02
Modified files:
gcc:
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-08-22
16:31 ---
Let's go with the quick fix, for 4.0.2, for now. If we get a better fix, fine;
but let's not have this bug in 4.0.2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15248
--- Additional Comments From kargl at gcc dot gnu dot org 2005-08-22 16:47
---
IMAG() is neither a generic intrinsic procedure nor a specific
intrinsic procedure. You want AIMAG() or you need to explicitly
declare IMAG() and provide a function.
--
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-22
16:59 ---
Subject: Bug 23478
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-08-22 16:58:50
Modified files:
gcc: ChangeLog flow.c global.c regs.h
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-08-22
17:32 ---
Yes, I think it's a good idea to put this patch in 4.0.2, given that it is in
mainline, and given that it is so very simple. However, I don't think it's
critical either way.
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-22
17:40 ---
Confirmed.
Back trace:
#0 translate_common (common=0x9037228, var_list=Variable var_list is not
available.
) at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/fortran/trans-common.c:823
#1 0x0808ebf5 in
--- Additional Comments From tromey at gcc dot gnu dot org 2005-08-22
18:00 ---
No feedback in nearly a year.
--
What|Removed |Added
Status|ASSIGNED
--
What|Removed |Added
OtherBugsDependingO|15855 |
nThis||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23382
--- Additional Comments From tromey at gcc dot gnu dot org 2005-08-22
18:05 ---
Committed to 4.0 branch.
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-22
18:06 ---
Subject: Bug 21074
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-08-22 18:06:36
Modified files:
libjava:
--- Additional Comments From paulthomas2 at wanadoo dot fr 2005-08-22
18:18 ---
Subject: Re: ICE on correct code
pinskia at gcc dot gnu dot org wrote:
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-22
17:40 ---
Confirmed.
Back trace:
#0
On Aug 22, 2005, at 2:18 PM, paulthomas2 at wanadoo dot fr wrote:
PS peshtigo?
I don't know where it comes from for this machine, as I did not name
them.
It looks like where the deadest fire in American history happened.
http://www.peshtigofire.info/
-- Pinski
--- Additional Comments From pinskia at physics dot uc dot edu 2005-08-22
18:26 ---
Subject: Re: ICE on correct code
On Aug 22, 2005, at 2:18 PM, paulthomas2 at wanadoo dot fr wrote:
PS peshtigo?
I don't know where it comes from for this machine, as I did not name
them.
It looks
--- Additional Comments From amylaar at gcc dot gnu dot org 2005-08-22
18:51 ---
Created an attachment (id=9555)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9555action=view)
proposed patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23517
--- Additional Comments From tromey at gcc dot gnu dot org 2005-08-22
18:53 ---
I fixed this in classpath.
It will be brought in by the next merge.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23499
--- Additional Comments From tromey at gcc dot gnu dot org 2005-08-22
19:12 ---
Here is a test case that needs only libgcj:
abstract class B implements Runnable
{
public B() { }
abstract void run();
}
class C extends B
{
void run() { }
}
class A
{
private C c = null;
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-22
19:22 ---
It looks like it was caused by:
2004-07-22 Paolo Bonzini [EMAIL PROTECTED]
* stor-layout.c (layout_type): Pick a mode for vector types.
...
--
What|Removed
This has been tested on 3.3.6, 3.4.1 and 4.0.1
The following test is considered always false and the block is dropped but a
being int, (a + 1 0) is true.
[EMAIL PROTECTED] tmp]$ cat lim.c
#include stdio.h
#include limits.h
int main (void)
{
int a = INT_MAX;
if ((a 0) || (a + 1
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-22
19:45 ---
Note signed overflow is undefined unless you use -fwrapv except that does not
fix this.
This is a bug in fold, most likely build_range_check.
--
What|Removed |Added
--- Additional Comments From gdr at integrable-solutions dot net
2005-08-22 19:49 ---
Subject: Re: [4.1 regression] Bogus 'is used uninitialized...' warning about
std::complexT
pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| This is a bug in libstdc++ headers. Since
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-22
19:52 ---
Here is a java program (since -fwrapv is turned on by default for java
front-end unlike the C front-end
since it is undefined in C and defined in java):
class t
{
public static void main(String as[])
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bonzini at gcc dot gnu dot
|dot org |org
Status|NEW
--- Additional Comments From cvs-commit at developer dot classpath dot org
2005-08-22 19:56 ---
Subject: Bug 23499
CVSROOT:/cvsroot/classpath
Module name:classpath
Branch:
Changes by: Tom Tromey [EMAIL PROTECTED] 05/08/22 18:50:11
Modified files:
.
--- Additional Comments From laurent at guerby dot net 2005-08-22 20:01
---
With 4.1.0 20050822 (experimental) on x86-linux, I get as output
27 times average: 10.00 followed by three times average:error here!
which seems the correct behaviour since you do for the three last iterations
1 - 100 of 171 matches
Mail list logo
