--- Comment #3 from bonzini at gnu dot org 2007-03-30 08:23 ---
still occurs at -O2 (testing with checking disabled).
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #36 from rguenth at gcc dot gnu dot org 2007-03-30 09:18
---
Thanks for the analysis! This should help.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31169
--- Comment #37 from rguenth at gcc dot gnu dot org 2007-03-30 10:01
---
The (target) difference seems to be that I get (on x86_64)
mask_lo_45 = 0x0 D.33492_44;
with a value range of [0,64] for D.33492_44 and a resulting value range of
[0, +INF] for mask_lo_45, not
--- Comment #38 from rguenth at gcc dot gnu dot org 2007-03-30 10:15
---
Ok, got it now - the crucial point is where width comes from:
#define HOST_WIDE_INT long
#define HOST_BITS_PER_WIDE_INT (4*8)
struct tree_type
{
unsigned int precision : 9;
};
int
sign_bit_p (struct tree_type
--- Comment #3 from rakdver at gcc dot gnu dot org 2007-03-30 10:36 ---
Subject: Bug 31383
Author: rakdver
Date: Fri Mar 30 10:36:19 2007
New Revision: 123359
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123359
Log:
PR tree-optimization/31383
* tree-data-ref.c
--- Comment #39 from rguenth at gcc dot gnu dot org 2007-03-30 10:47
---
Created an attachment (id=13300)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13300action=view)
patch
The problem is that we in rshift_double() do
if (SHIFT_COUNT_TRUNCATED)
count %= prec;
which for
When trying to build the OOo code warning-free we turned all useful warnings on
and get rid of them.
But there is one warning that would be really useful missing. It is not
required for code correctness or safety at all, but it would be most useful to
have better understandable code.
What I/we at
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-03-30 11:00
---
We should also diagnostic better the cases of negative of too large NCOPIES
argument, for both parameters (in simplification routine) and non-parameters.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31304
Look out the output:
1. When no O2 option set, the output is:
send out: 50 Time: 1165250900
192.168.1.1 10
2. When -O2 option is set, the output is:
192.168.1.1 send out: 50 Time: 1165250934
10
It proves that the execution sequence has been changed. I think
--- Comment #1 from windows2000d at gmail dot com 2007-03-30 11:47 ---
Created an attachment (id=13301)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13301action=view)
The sample code show the bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31398
--
windows2000d at gmail dot com changed:
What|Removed |Added
Severity|normal |blocker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31398
$ cat a.f90
integer(kind=1) :: i
integer(kind=8) :: c = 0
do i = -huge(i), huge(i), 2
c = c + 1
end do
print *, c
end
$ gfortran a.f90 ./a.out
0
I think it has to do with the comment on top of gfc_trans_do:
TODO: Large loop counts
The code above
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Known
--- Comment #44 from manu at gcc dot gnu dot org 2007-03-30 12:25 ---
(In reply to comment #43)
A couple of days ago in irc I agreed to come up with a version of the patch
that just handles the C tests. So far it works fine with C but breaks
everything else, but I haven't forgotten
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-03-30 12:49
---
(In reply to comment #0)
the loop count should be
changed from
count = (to + step - from) / step
to something else that cannot overflow.
I think it should be:
unsigned count = (step0 ? tofrom : tofrom) ?
hello,
I am trying to build gcc-3.4.5 and gcc-3.4.6
for i960 as target.
my host machine:i686-pc-linux-gnu
target maccine:i960-unknown-coff
native compiler on my machine: gcc-4.0
operating system/gc version:gcc version 4.0.0 (Red Hat
4.0.0-8)on Fedora core-4
i have already installed
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-03-30 13:03 ---
You are relying on undefined behavior.
*** This bug has been marked as a duplicate of 11751 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #74 from rguenth at gcc dot gnu dot org 2007-03-30 13:03
---
*** Bug 31398 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
To deploy testing versions of applications built with (yet unreleased) versions
of gcc may be difficult due to linked in libraries as libgfortran and libgomp.
Similar to -static-libgcc, options like -static-libgfortran or -static-libgomp
would help to avoid problems. Especially for libgomp, one
--- Comment #2 from steven at gcc dot gnu dot org 2007-03-30 15:21 ---
Looks like the kind of bug that cfglayout mode might introduce.
Will investigate...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from steven at gcc dot gnu dot org 2007-03-30 15:21 ---
Looks like the kind of bug that cfglayout mode might introduce.
Will investigate...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from steven at gcc dot gnu dot org 2007-03-30 15:22 ---
Which target is this, BTW?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from tbm at gcc dot gnu dot org 2007-03-30 15:29 ---
I've seen it on x86_64 and ia64.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31391
--- Comment #1 from hjl at lucon dot org 2007-03-30 15:47 ---
You may want to look at
http://gcc.gnu.org/ml/gcc/2005-12/msg00783.html
--
hjl at lucon dot org changed:
What|Removed |Added
the following program demonstrates, what I think, a flaw in std::string find.
According to me and (see comp.lang.c++ and c.l.c++.moderated) many others,
find( astring, string::npos ) should always return string::npos.
But G++ seems to wrap around an start searching at the begin of the string.
--- Comment #40 from rth at gcc dot gnu dot org 2007-03-30 16:14 ---
The reason we do that is to match the way the arithmetic would be performed
on the host as much as possible. This could be important if someother part
of the compiler already relied on SHIFT_COUNT_TRUNCATED to
--- Comment #1 from pcarlini at suse dot de 2007-03-30 17:25 ---
Yes, this is stupid bug, it's an unintended behavior caused by unsigned
overflow. Will be fixed before the end of the day, but isn't a regression, thus
only in 4_2-branch and mainline.
--
pcarlini at suse dot de
--- Comment #41 from rth at gcc dot gnu dot org 2007-03-30 17:30 ---
Created an attachment (id=13302)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13302action=view)
alternate patch
I'm inclined to take this approach to the problem. Note that the result
range we get from this is
--
pcarlini at suse dot de changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31401
--- Comment #2 from paolo at gcc dot gnu dot org 2007-03-30 18:11 ---
Subject: Bug 31401
Author: paolo
Date: Fri Mar 30 18:10:50 2007
New Revision: 123361
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123361
Log:
2007-03-30 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #3 from paolo at gcc dot gnu dot org 2007-03-30 18:11 ---
Subject: Bug 31401
Author: paolo
Date: Fri Mar 30 18:11:22 2007
New Revision: 123362
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123362
Log:
2007-03-30 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #4 from pcarlini at suse dot de 2007-03-30 18:12 ---
Fixed for 4.2.0.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-03-30 18:41 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
Hello,
there seems to be a gcc problem with the target 'sh-elf':
/home/mstein/sim/sh-elf/build/./gcc/xgcc -B/home/mstein/sim/sh-elf/build/./gcc/
-nostdinc -B/home/mstein/sim/sh-elf/build/sh-elf/newlib/ -isystem
/home/mstein/sim/sh-elf/build/sh-elf/newlib/targ-include -isystem
--- Comment #11 from cvs-commit at developer dot classpath dot org
2007-03-30 18:58 ---
Subject: Bug 29869
CVSROOT:/cvsroot/classpath
Module name:classpath
Changes by: Tom Tromey tromey 07/03/30 17:57:44
Modified files:
. : ChangeLog
--- Comment #1 from mstein at phenix dot rootshell dot be 2007-03-30 19:15
---
Created an attachment (id=13303)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13303action=view)
preprocessed source file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31403
--- Comment #13 from fche at redhat dot com 2007-03-30 19:21 ---
Case 1, is also too hard to fix as it would make us lose a lot of
optimizations.
If aoliva is correct in comment# 11, then some information is being lost
that could be retained with some additional effort. That would
--- Comment #1 from eweddington at cso dot atmel dot com 2007-03-30 19:55
---
Dr. John,
Can you provide additional information:
- What AVR processor was this compiled for? You don't have the required -mmcu=
flag in your command line.
- Can you provide a disassembly listing showing
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |ASSIGNED
Last reconfirmed|2007-03-30 15:21:40 |2007-03-30
--- Comment #9 from paolo at gcc dot gnu dot org 2007-03-30 20:46 ---
Subject: Bug 26099
Author: paolo
Date: Fri Mar 30 20:45:57 2007
New Revision: 123366
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123366
Log:
gcc/
2007-03-30 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #1 from eweddington at cso dot atmel dot com 2007-03-30 20:58
---
The test program works for me for AVR GCC 4.1.1. (WinAVR distro 20070122)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29932
--- Comment #3 from steven at gcc dot gnu dot org 2007-03-30 21:05 ---
TREE_COMPLEXITY is history
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #45 from manu at gcc dot gnu dot org 2007-03-30 21:13 ---
I have fixed all failing testcases in the C front-end. I am going to send the
fixes to janis, if someone else is interested, let me know it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25241
--- Comment #6 from steven at gcc dot gnu dot org 2007-03-30 21:16 ---
At the end of loop2, the tryagain label is turned into a deleted label note.
This happens because the label has zero uses left in cfglayout. There are only
unconditional jumps to it, unconditional jumps are removed
--- Comment #3 from sdirkse at gams dot com 2007-03-30 21:36 ---
I installed gcc 20070329 and the problem I was having is solved. I suppose
that makes it a duplicate of PR30980.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31394
U:\vrao\fortrantype xlen_trim.f90
integer :: ic(1) = len_trim((/a/))
print*,ic=,ic
end
U:\vrao\fortrangfortran -v
Using built-in specs.
Target: i386-pc-mingw32
Configured with: ../trunk/configure --prefix=/mingw
--enable-languages=c,fortran --with-gmp=/home/coudert/local --disable-nls
--- Comment #4 from dominiq at lps dot ens dot fr 2007-03-30 21:56 ---
I suppose that makes it a duplicate of PR30980.
It would have been better to check it directly before updating. PR30980 was
related to g++ and gfortran and not gcc, so it seems that your platform
--- Comment #14 from pinskia at gcc dot gnu dot org 2007-03-30 22:04
---
(In reply to comment #13)
If aoliva is correct in comment# 11, then some information is being lost
that could be retained with some additional effort. That would make this
bug other than invalid - at best a
--- Comment #15 from fche at redhat dot com 2007-03-30 22:10 ---
(In reply to comment #14)
This is basically the same as case 1 (though a constant instead of a call to
rand()), now do we want not to prop x1 into x? I say we always do want that
because otherwise we get an extra
When you link two files that both #include wchar.h together you get:
t2.o: In function `wcstoul': /usr/include/wchar.h:540: multiple definition of
`wcstoul'
t1.o:/usr/include/wchar.h:540: first defined here
when you compile with -std=c99.
--
Summary: [4.3] fixincludes needed for
[sue32 layerOp] g++ -v
Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/specs
Configured with: ../configure --prefix=/usr
--with-gcc-version-trigger=/home/carolh/tools/gcc-3.3.6/gcc/version.c
--enable-threads=posix
Thread model: posix
gcc version 3.3.6
--- Comment #1 from h8_spam at sonic dot net 2007-03-30 22:30 ---
This is not an issue with v3.3.5.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31406
--- Comment #2 from wilson at gcc dot gnu dot org 2007-03-30 22:44 ---
I can reproduce the problem using the provided testcase.
It looks like all we have to do is mark the array type TYPE_DOMAIN as used, to
prevent it from being garbage collected. This just requires adding an
--- Comment #3 from wilson at gcc dot gnu dot org 2007-03-30 22:49 ---
Created an attachment (id=13304)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13304action=view)
Add equate_type_number_to_die call to prevent garbage collection.
This patch is untested, but works for the
--- Comment #10 from tromey at gcc dot gnu dot org 2007-03-30 22:53 ---
The fix went in a while back.
Really someone ought to port classpath's newer poll/epoll-based
nio selector to CNI. That would be more efficient than what
we have now.
--
tromey at gcc dot gnu dot org changed:
--- Comment #7 from steven at gcc dot gnu dot org 2007-03-30 23:29 ---
Index: cfgcleanup.c
===
--- cfgcleanup.c(revision 123362)
+++ cfgcleanup.c(working copy)
@@ -2034,6 +2034,8 @@ try_optimize_cfg (int
I'm not quite sure what's going on here. *Maybe* this is invalid code, but
I belive it's a compiler bug because the error goes away when I remove
completely
unrelated lines in the program. Anyway, I get the following with 4.3 (it
compiles with 4.1):
(sid)6870:[EMAIL PROTECTED]: ~] g++ -c -g -O
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-30 23:58 ---
There is no `#pragma implementation ' so I don't think this is a bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31407
--- Comment #2 from tbm at cyrius dot com 2007-03-31 00:01 ---
Any idea why it works when I remove completely unrelated lines, e.g.
if (c == -1)
break;
Is this just a coincidence?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31407
--- Comment #3 from tbm at cyrius dot com 2007-03-31 00:06 ---
(In reply to comment #1)
There is no `#pragma implementation ' so I don't think this is a bug.
This doesn't seem to help either.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31407
--- Comment #1 from fang at csl dot cornell dot edu 2007-03-31 00:43
---
Do you mean -Woverloaded-virtual? (see man page)
The diagostic reports when a derived class's method 'hides' the base class's.
--
fang at csl dot cornell dot edu changed:
What|Removed
--- Comment #6 from danglin at gcc dot gnu dot org 2007-03-31 00:51 ---
Fixed.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #42 from dave at hiauly1 dot hia dot nrc dot ca 2007-03-31
01:17 ---
Subject: Re: Bootstrap comparison error at revision 122821
+ /* We know that the range of input values covers the entire
+shift space. Reduce to canonical
--- Comment #8 from tbm at cyrius dot com 2007-03-31 01:44 ---
This patch works for me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31391
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-03-31 01:45
---
Michael sent me this excellent test case illustrating the problem.
PROGRAM test
CHARACTER(LEN=8) :: as_written, as_read
as_written = 12345678
OPEN (76, FILE=test.txt, ACCESS=DIRECT,
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-03-31 01:46
---
I just need to hit the right button in bugzilla.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from wilson at gcc dot gnu dot org 2007-03-31 02:23 ---
I was able to reproduce this on an x86_64-linux machine following the
instructions.
Assuming this is the same conceptual problem as 31230, I tried the same patch,
in another file. Just marking the array type domain
--- Comment #3 from wilson at gcc dot gnu dot org 2007-03-31 02:24 ---
Created an attachment (id=13305)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13305action=view)
Mark array TYPE_DOMAIN as used to prevent garbage collection.
This has been tested with a C only
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2007-03-31 06:06
---
Here is a preliminary patch for this.
Index: io/transfer.c
===
*** io/transfer.c (revision 123355)
--- io/transfer.c (working copy)
69 matches
Mail list logo
