--- 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, no
--- 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=gcc&view=rev&rev=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=13300&action=view)
patch
The problem is that we in rshift_double() do
if (SHIFT_COUNT_TRUNCATED)
count %= prec;
which fo
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 it'
--- 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=13301&action=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 assu
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Known t
--- 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 forgotte
--- 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 = (step>0 ? tofrom) ? 0 : 1
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 binutil
--- 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 ca
--- 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.
sa
--- 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 eliminat
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-30 16:22 ---
In general this is wrong. There are reasons why you don't want static linking.
code size/memory usage is one of them.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31400
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-03-30 16:30 ---
Andrew, I agree that static linking should not be overused. But there are valid
cases where one may want to do it anyway. Deploying a testing application may
be one of them. Asking the user to compile gcc from scratc
--- Comment #24 from dberlin at gcc dot gnu dot org 2007-03-30 16:58
---
This is fixed now, rihgt?
I forgot to add the PR number to the changelog.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30089
--- 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 changed
--- 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=13302&action=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=gcc&view=rev&rev=123361
Log:
2007-03-30 Paolo Carlini <[EMAIL PROTECTED]>
PR libstd
--- 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=gcc&view=rev&rev=123362
Log:
2007-03-30 Paolo Carlini <[EMAIL PROTECTED]>
PR libstd
--- 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
/n/07/mstein/combine
--- 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 07/03/30 17:57:44
Modified files:
. : ChangeLog
java/ut
--- 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=13303&action=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 the
--
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 20
--- 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=gcc&view=rev&rev=123366
Log:
gcc/
2007-03-30 Paolo Carlini <[EMAIL PROTECTED]>
PR c
--- 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 w
--- 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\fortran>type xlen_trim.f90
integer :: ic(1) = len_trim((/"a"/))
print*,"ic=",ic
end
U:\vrao\fortran>gfortran -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
--wi
--- 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
(i386-pc-solaris2
--- 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 ass
When you link two files that both #include 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 wchar from
[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
equate_ty
--- 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=13304&action=view)
Add equate_type_number_to_die call to prevent garbage collection.
This patch is untested, but works for the test
--- 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 mode
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
Status|UNCONFIRM
--- 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 [0,width-1].
--- 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=13305&action=view)
Mark array TYPE_DOMAIN as used to prevent garbage collection.
This has been tested with a C only BOOT_CFLAGS=-gs
--- 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)
***
> please tell me about the bug or error.Now i am already
> stuk i am unable to understand what to do next???
> so please help me!!
Ada is not supported for this target.
--
Eric Botcazou
--- Comment #7 from tkoenig at alice-dsl dot net 2007-03-31 08:11 ---
Subject: Re: Last record truncated for read after short
write, direct access file
On Sat, 2007-03-31 at 00:45 +, jvdelisle at gcc dot gnu dot org
wrote:
> Michael sent me this excellent test case illustra
--- Comment #4 from schwab at suse dot de 2007-03-31 08:56 ---
You need to put it at the top of the file.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31407
74 matches
Mail list logo
