--- Additional Comments From rguenth at gcc dot gnu dot org 2005-08-28
08:11 ---
Works on powerpc-unknown-linux-gnu and i686-pc-linux-gnu with g++-4.0 (GCC)
4.0.2 20050821 (prerelease) (Debian 4.0.1-6).
Can you try reproducing with a recent snapshot from the 4.0 branch? This may
still
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-28
10:09 ---
Subject: Bug 23081
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-08-28 10:09:09
Modified files:
libstdc++-v3 : Change
--- Additional Comments From pcarlini at suse dot de 2005-08-28 10:10
---
Fixed for 4.0.2.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
Seen as an ia64 bootstrap failure as of 20050828 in
libjava/java/lang/reflect/natMethod.cc, though the problem could affect
any target.
The observed problem is that reload chooses a reg/reg alternative for
reloading a memory (for unknown reasons). This causes the insn stream
to be changed from
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-28
11:01 ---
Subject: Bug 23593
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-08-28 11:01:32
Modified files:
gcc: ChangeLog builtins.c
Log message:
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot
|dot org |org
URL|
--- Additional Comments From laurent at guerby dot net 2005-08-28 11:05
---
Thanks for fixing this.
--
What|Removed |Added
Status|ASSIGNED|RE
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-28
11:09 ---
Subject: Bug 23593
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-08-28 11:08:57
Modified files:
gcc: Change
--
What|Removed |Added
Keywords||EH
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23601
--
What|Removed |Added
Target Milestone|--- |4.0.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23593
--- Additional Comments From dorit at il dot ibm dot com 2005-08-28 13:47
---
The patch below fixes the problem.
We fail on this assert:
gcc_assert (evolution_part != NULL_TREE);
in 'vect_update_ivs_after_vectorizer'.
This happens because we assume that 'vect_update_ivs_after_v
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-28
15:14 ---
Subject: Bug 23508
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-08-28 15:14:14
Modified files:
gcc: Change
--- Additional Comments From danglin at gcc dot gnu dot org 2005-08-28
15:21 ---
Fixed in 4.0 and mainline.
--
What|Removed |Added
Status|NEW
--
What|Removed |Added
Component|libgcj |target
Target Milestone|--- |4.0.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2350
configuring HEAD 20050828 for i486-linux (instead of the default i686-linux),
libjava fails with 1081 test failures (instead of two with i686-linux).
apparently all the execution tests fail. I don't see any additional information
from the test log (attached). Compiling the a testcase by hand
--- Additional Comments From debian-gcc at lists dot debian dot org
2005-08-28 16:41 ---
Created an attachment (id=9602)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9602&action=view)
test log
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23602
Example:
int f(int i)
{
int t = i == 1;
int g = t == 2;
int h = g == 3;
return h;
}
We should convert this to return 0 on the tree level but currently we get:
return i == 1 == 2 == 3;
in final_cleanup
--
Summary: VRP does not say range for a in a = b == c; is [0,1]
P
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-28
17:22 ---
The fix would be instead of setting the range to varrying in
extract_range_from_comparison, set it to
[0,1].
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23603
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-28
17:25 ---
I have a fix.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pinskia
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org |
Status|NEW
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-08-28
18:11 ---
The fundamental problem here is that G++ is not honoring [temp.inst], which
requires that:
"in particular, the initialization (and any associated side-effects) of a static
data member does not occur unless
--
What|Removed |Added
BugsThisDependsOn||23604
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23603
The following should not abort but does at -O2.
int g(int i, int j)
{
if (i>-1)
if (i<2)
{
if (i != j)
{
if (j != 0)
return 0;
}
}
return 1;
}
int main(void)
{
if (!g(1, 0))
abort ();
return 0;
}
---
I found this w
--
What|Removed |Added
CC||phython at gcc dot gnu dot
||org, dnovillo at gcc dot gnu
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-08-28
19:59 ---
I have a patch for this
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-08-28
20:00 ---
I have a patch for this
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu
I have a bit of a disagreement with the optimization toward memset()
calls. In one of my libraries, libteklti, I have a function named
ucharempty(), which frees a uchar_t (unique character structure) from
memory. If the user elects to have the memory erased prior to calling
free(), memset() is su
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-28
20:08 ---
Are you compiling your source at -O0 or GCC at -O0? If the former, then this
is most likely not a bug.
--
What|Removed |Added
--
--- Additional Comments From phython at gcc dot gnu dot org 2005-08-28
20:16 ---
Created an attachment (id=9603)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9603&action=view)
initial patch (untested)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23604
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |2005-08-
--- Additional Comments From kevin at planetsaphire dot com 2005-08-28
20:18 ---
Created an attachment (id=9604)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9604&action=view)
Testcases and .i Files of uchar.*
This attatchment contains only the source files of my project, as well
--- Additional Comments From kevin at planetsaphire dot com 2005-08-28
20:26 ---
(In reply to comment #1)
> Are you compiling your source at -O0 or GCC at -O0? If the former, then this
is most likely not a bug.
-O2 does not do any optimization at all, and -O0 optimizes the code to a ce
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-28
20:28 ---
You are compiling at -O0 so this is not a bug and we don't care that much about
code generation at
-O0.
--
What|Removed |Added
-
--- Additional Comments From kevin at planetsaphire dot com 2005-08-28
20:34 ---
(In reply to comment #4)
> You are compiling at -O0 so this is not a bug and we don't care that much
about code generation at
> -O0.
So you're invalidating this bug because -O0 optimizes this and -O2 does
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-28
20:37 ---
inlining memset is not an optimization as most OS's memsets are better than the
inlined version, using
sse registers,etc.
--
What|Removed |Added
---
--
What|Removed |Added
Keywords||wrong-code
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=
--- Additional Comments From kevin at planetsaphire dot com 2005-08-28
21:58 ---
(In reply to comment #6)
> inlining memset is not an optimization as most OS's memsets are better than
the inlined version, using
> sse registers,etc.
I have finished reviewing over the glibc memset.* sour
--- Additional Comments From wmahan at gmail dot com 2005-08-28 22:18
---
Hi, I submitted a different patch to the upstream FastJar sources at
http://sourceforge.net/tracker/index.php?func=detail&aid=1275036&group_id=426&atid=300426
before I noticed this bug. (It doesn't apply to the gc
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-28
22:21 ---
First it is not our bug your distro installs i686 versions, go bug them instead.
Second glibc not using SSE is its bug and not ours, report it to them instead.
--
What|Removed
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-28
23:00 ---
Oh, I forgot to mention if you want to inline all string functions, use
-minline-all-stringops.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23605
I don't have a testcase for this one as convert already does it though with my
tree combiner (or when
TER folds), you can reproduce it with:
int f(int i, int j)
{
_Bool a = i == j;
int t = a;
return t;
}
--
Summary: fold does not fold (type)(a == b) into a == b (with type
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-28
23:04 ---
I have a patch which I will be submitting after I do a bootstrap/test.
--
What|Removed |Added
--- Additional Comments From ian at airs dot com 2005-08-28 23:15 ---
I didn't realize that this was at -O0. Extra register moves at -O0 are not a
bug. -O0 means no optimization.
I think it is odd that we open code memset at -O0 but not at -O1. I don't know
the rationale behind that.
--- Additional Comments From greenrd at greenrd dot org 2005-08-28 23:25
---
memcmp (which is compiled for i686 in fedora because it is part of glibc) is
actually less efficient than the current code on my athlon! I was so surprised,
I ran the memcmp benchmark again, and the results diff
On Aug 28, 2005, at 7:25 PM, greenrd at greenrd dot org wrote:
--- Additional Comments From greenrd at greenrd dot org
2005-08-28 23:25 ---
memcmp (which is compiled for i686 in fedora because it is part of
glibc) is
actually less efficient than the current code on my athlon! I was
--- Additional Comments From pinskia at physics dot uc dot edu 2005-08-28
23:32 ---
Subject: Re: java.lang.String.equals is suboptimal
On Aug 28, 2005, at 7:25 PM, greenrd at greenrd dot org wrote:
>
> --- Additional Comments From greenrd at greenrd dot org
> 2005-08-28 23:25 -
--- Additional Comments From ian at airs dot com 2005-08-28 23:36 ---
The generated code for your second test case doesn't look too bad to me. The
bulk of the code is checking the alignment of the buffer in order to get an
efficient rep; stosl. What would you recommend as faster code?
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-28
23:42 ---
Note, type and TREE_CODE (op0) are swapped in the patch (as I did not even
build the orginal patch).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23606
--
Bug 21180 depends on bug 22455, which changed state.
Bug 22455 Summary: [4.1 regression] ICE tree check: expected function_decl,
have type_decl in fold_checksum_tree, at fold-const.c:10282
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22455
What|Old Value |Ne
--
Bug 20623 depends on bug 22455, which changed state.
Bug 22455 Summary: [4.1 regression] ICE tree check: expected function_decl,
have type_decl in fold_checksum_tree, at fold-const.c:10282
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22455
What|Old Value |Ne
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-08-29
00:12 ---
Fixed
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-29
00:12 ---
Subject: Bug 22455
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-08-29 00:12:21
Modified files:
gcc: ChangeLog fold-const.c
Log message:
--- Additional Comments From kevin at planetsaphire dot com 2005-08-29
00:16 ---
err... I meant "get rid of the pushpop instructions for ebx" because ebx
wouldn't be used (probably taken care of automatically anyway)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23605
--- Additional Comments From kevin at planetsaphire dot com 2005-08-29
00:36 ---
Also, is setting %eax to $0 once per memset good enough? I don't think the
"stos" instruction would reset %eax... the resulting assembly code in
tektester.386.s is the same in -O3 and -O2...
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-29
00:49 ---
This really does depend on PR 23604 as it exposes that latent bug while
bootstrapping.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23603
gcc.target/i386/pr23575.c fails with the following message:
/home/pinskia/src/onetest/gcc/gcc/testsuite/gcc.target/i386/pr23575.c:1: error:
CPU you selected
does not support x86-64 instruction set
/home/pinskia/src/onetest/gcc/gcc/testsuite/gcc.target/i386/pr23575.c:1: error:
CPU you selected
d
Compiling
#define FIVE 5
int main()
{
int i = 5;
int const ic = 5;
i < 5u;
ic < 5u;
FIVE < 5u; // line 10
}
with -Wsign-compare produces the output
pp.cpp:8: warning: comparison between signed and unsigned integer expressions
pp.cpp:9: warning: comparison between signed an
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-29
02:34 ---
ic by the C++ standard does not need to propagate its value into ic < 5u so I
think the warning is
warranted.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23608
--- Additional Comments From qiyaoltc at cn dot ibm dot com 2005-08-29
02:57 ---
OK.
GCC version: 3.4.3 20050227 (Red Hat 3.4.3-22.1)
GNU C Library: stable release version 2.3.4
OS : Red Hat Enterprise Linux AS release 4 (Nahant Update 1)
I write a small example named overflow-test.c, h
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-29
03:10 ---
I think there are some real interesting issues here.
First with -pedantic we get a warning for line 9 but nothing more. If we add f
to the end of the
constant on line 5, we then get a warning.
And yes
All obj-c++ execute tests fails with the GNU runtime:
Setting LD_LIBRARY_PATH to
.:/home/pinskia/src/onetest/gcc/objdir/x86_64-unknown-linux-gnu/./
libstdc++-v3/src/.libs:/home/pinskia/src/onetest/gcc/objdir/gcc:/home/pinskia/src/onetest/gcc/
objdir/gcc:.:/home/pinskia/src/onetest/gcc/objdir/x86_6
obj-c++.dg/bitfield-1.mm fails by giving these extra warnings:
In file included from :0:
:0: warning: padding struct to align '::'
:0: warning: padding struct to align '::'/home/pinskia/
src/onetest/gcc/gcc/testsuite/obj-c++.dg/bitfield-1.mm:40: warning: padding
struct size to
alignment
boundary
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-29
03:37 ---
Likewise for obj-c++.dg/bitfield-4.mm:
In file included from :0:
:0: warning: padding struct to align '::'
:0: warning: padding struct to align '::'
/home/pinskia/src/onetest/gcc/gcc/testsuite/obj-c++.dg/bit
obj-c++.dg/encode-4.mm fails with the following error message:
/home/pinskia/src/onetest/gcc/gcc/testsuite/obj-c++.dg/encode-4.mm:35: error:
declaration of 'int
sscanf(const char*, const char*, ...)' throws different
exceptions/usr/include/stdio.h:402: error: than
previous declaration 'int ssc
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-29
03:40 ---
Likewise for encode-5.mm:
/home/pinskia/src/onetest/gcc/gcc/testsuite/obj-c++.dg/encode-5.mm:17: error:
declaration of 'int
sscanf(const char*, const char*, ...)' throws different exceptions
/usr/include/s
obj-c++.dg/encode-6.mm fails with:
/home/pinskia/src/onetest/gcc/gcc/testsuite/obj-c++.dg/encode-6.mm:57: error:
invalid use of
undefined type 'struct
objc_ivar'/home/pinskia/src/onetest/gcc/gcc/testsuite/../../libobjc/objc/objc-
api.h:216: error: forward declaration of 'struct objc_ivar'
/home/
obj-c++.dg/isa-field-1.mm fails with:
/home/pinskia/src/onetest/gcc/gcc/testsuite/obj-c++.dg/isa-field-1.mm:17:
error: 'struct
objc_object' has no member named 'isa'
/home/pinskia/src/onetest/gcc/gcc/testsuite/obj-c++.dg/isa-field-1.mm:21:
error: 'struct
objc_object' has no member named 'isa'
/
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-29
03:42 ---
obj-c++.dg/layout-1.mm fails the same way:
In file included from :0:
:0: warning: padding struct to align '::'
:0: warning: padding struct to align '::'
--
What|Removed |
obj-c++.dg/lookup-2.mm fails with:
/home/pinskia/src/onetest/gcc/gcc/testsuite/obj-c++.dg/lookup-2.mm:40: error:
cannot convert
'objc_object*' to 'MyWidget*' in initialization
--
Summary: obj-c++.dg/lookup-2.mm fails with the GNU runtime
Product: gcc
Version: 4.
obj-c++.dg/method-19.mm fails with:
/home/pinskia/src/onetest/gcc/gcc/testsuite/obj-c++.dg/method-19.mm:19: error:
declaration of
'int strcmp(const char*, const char*)' throws different exceptions
/usr/include/string.h:97: error: than previous declaration 'int strcmp(const
char*, const char*) th
obj-c++.dg/try-catch-2.mm fails with:
/tmp/ccYlrE11.o(.gcc_except_table+0x18): undefined reference to `typeinfo for
Frob*'
Which means we are trying to use the C++ style exceptions instead of objc
exceptions.
Though this is harder to fix correctly (I have to look into how the C++
front-end im
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-29
03:48 ---
try-catch-9.mm fails the same way:
/tmp/ccgh94EZ.o(.gcc_except_table+0x14): undefined reference to `typeinfo for
Object*'
--
What|Removed |Added
---
When trying to compile a file with Debian's gcj 4.0.1-2, I got an error like
this:
HelloWorld.java:0: error: malformed .zip archive in CLASSPATH:
/usr/lib/j2re1.5-sun/lib/ext/localedata.jar/
jc1: out of memory allocating 1342179073 bytes after a total of 389120 bytes
It turns out the .jar file
--- Additional Comments From wmahan at gmail dot com 2005-08-29 04:53
---
Created an attachment (id=9611)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9611&action=view)
Possible fix for gcc/java/zextract.c against latest CVS
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2361
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |2005-08-
--- Additional Comments From aj at gcc dot gnu dot org 2005-08-29 04:55
---
Taking it.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |aj at gcc dot g
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-29
04:56 ---
Confirmed, I thought there was already a bug about this (not the fast jar one
you pointed out) but looks
like there is not.
Could you sent your patch to java-patches@ and gcc-patches@ with a changelog
an
--- Additional Comments From qiyaoltc at cn dot ibm dot com 2005-08-29
05:00 ---
I add suffix f to the end of float constants at line 5 and line 7, and add
option -pedantic, the output from gcc is like this:
overflow-test.c:5: warning: floating constant exceeds range of "float"
overflow
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-29
05:18 ---
I am wrong, in saying that if fold does it, we will automatic get the
optimization but after fold doing the
simplification, I think this turns into the same issue as PR 23588.
--
What|Remo
On Aug 29, 2005, at 1:18 AM, pinskia at gcc dot gnu dot org wrote:
--- Additional Comments From pinskia at gcc dot gnu dot org
2005-08-29 05:18 ---
I am wrong, in saying that if fold does it, we will automatic get the
optimization but after fold doing the
simplification, I think th
--- Additional Comments From pinskia at physics dot uc dot edu 2005-08-29
05:19 ---
Subject: Re: Missed ccp optimization
On Aug 29, 2005, at 1:18 AM, pinskia at gcc dot gnu dot org wrote:
>
> --- Additional Comments From pinskia at gcc dot gnu dot org
> 2005-08-29 05:18 ---
--- Additional Comments From aj at gcc dot gnu dot org 2005-08-29 05:31
---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
R
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-29
05:31 ---
Subject: Bug 23607
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-08-29 05:31:49
Modified files:
gcc/testsuite : ChangeLog
Log message:
Add
--- Additional Comments From wmahan at gmail dot com 2005-08-29 06:02
---
Done. I expected a bug to already have been reported about this, but I couldn't
find one. Thanks for the fast response!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23617
84 matches
Mail list logo
