--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-18
07:58 ---
Subject: Bug 16968
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED] 2004-12-18 07:58:12
Modified files:
gcc: Change
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-18
07:55 ---
Subject: Bug 16968
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-12-18 07:55:42
Modified files:
gcc: ChangeLog loop.c
gcc/testsui
--
What|Removed |Added
Priority|P2 |P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18863
--
What|Removed |Added
Summary|[4.0 Regression] MOVE_RATIO |[4.0 Regression] MOVE_RATIO
|should be tweaked |should be tweaked on ppc
http://g
--- Additional Comments From zack at gcc dot gnu dot org 2004-12-18 06:42
---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-18
06:38 ---
Subject: Bug 18897
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-12-18 06:38:26
Modified files:
gcc: ChangeLog toplev.c
Log message:
--- Additional Comments From lars dot sonchocky-helldorf at hamburg dot de
2004-12-18 05:38 ---
please note (I might not have stated this clearly enough in comment #4):
the bootstrap doesn't fail if:
'-fomit-frame-pointer' is omitted (by specifying BOOT_CFLAGS="-O2 -g" instead
of BOO
--- Additional Comments From lars dot sonchocky-helldorf at hamburg dot de
2004-12-18 05:22 ---
Created an attachment (id=7776)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7776&action=view)
diff between stage2 and stage3 reload.o otool -tV output
--
http://gcc.gnu.org/bugzil
--- Additional Comments From lars dot sonchocky-helldorf at hamburg dot de
2004-12-18 05:21 ---
Created an attachment (id=7775)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7775&action=view)
reload.o of stage3 mangled through otool
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?
--- Additional Comments From lars dot sonchocky-helldorf at hamburg dot de
2004-12-18 05:20 ---
Created an attachment (id=7774)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7774&action=view)
reload.o of stage2 mangled through otool
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?
--- Additional Comments From lars dot sonchocky-helldorf at hamburg dot de
2004-12-18 05:18 ---
(In reply to comment #6)
> (In reply to comment #5)
> > Indeed a Heisenbug:
> >
> > Does anyone know how I could disassemble those .o files to get something
> > more
> > human readable?
>
>
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-18
04:13 ---
(In reply to comment #39)
> Here is the current results for 3.3.2 vs the mainline:
Now I am getting results that -O3 is faster than -O2, that is not right.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=
--
What|Removed |Added
Severity|critical|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19004
--
What|Removed |Added
Known to fail||3.4.4 4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19051
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-18
03:50 ---
Thanks for testing, closing as fixed.
--
What|Removed |Added
Status|WAITING
--- Additional Comments From jasonp at boo dot net 2004-12-18 03:48 ---
(In reply to comment #1)
> I could reproduce it with 20041208 but with 20041214 it is fixed, can you test
a newer GCC?
Latest CVS works fine.
Ticket can close.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1905
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-18
03:48 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
E
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-18
03:43 ---
Does this happen in 3.4.3?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17471
--
What|Removed |Added
Component|c |other
Keywords||documentation
Last reconfirmed|2004-09-18 01:21:22
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-18
02:29 ---
*** Bug 19066 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-18
02:29 ---
This is a dup of bug 14009 which is fixed on the mainline.
*** This bug has been marked as a duplicate of 14009 ***
--
What|Removed |Added
--
--
What|Removed |Added
Component|java|libgcj
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19066
1. create B.java:
import java.io.*;
import java.net.*;
public class B {
public static void main(String[] args) {
URL javacodingURL = null;
try {
javacodingURL = new URL(args[0]);
System.out.println("protocol = " + javacodingURL.getProtocol());
System.out.println("host = "
--- Additional Comments From fjahanian at apple dot com 2004-12-18 01:46
---
And this is the patch that I had in mind. Can this break ABI compatibily? My
limited testing shows
that it does not.
Index: rs6000.c
===
RCS fil
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-12-18
01:36 ---
Patch here:
http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01329.html
--
What|Removed |Added
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-18
01:28 ---
Obvious patch posted here:
http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01328.html
This is not a wrong-code bug. At worst it will crash the compiler,
but probably it just works by luck, because of stack
--- Additional Comments From austern at apple dot com 2004-12-18 01:17
---
The code in the C front end that handles this is in finish_decl, in c-decl.c:
if (TREE_CODE (decl) == FUNCTION_DECL && asmspec)
{
if (DECL_BUILT_IN_CLASS (decl) == BUILT_IN_NORMAL)
{
--- Additional Comments From fjahanian at apple dot com 2004-12-18 00:43
---
Followin patch fixes the alignment problem. But it cannot be applied because it
breaks ABI
compatibilty.
A possible solution is to relax alignment of the type in question (with
alignment of 128) to that of t
--
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |200
This is a FIXME that I need to free a constraint letter (probably the existing
R) as a constraint for (MEM reg), or more to the point, a side-effect-free
memory constraint: the libstdc++ asms are buggy and could get autoincrement.
Actually, there should be a generic constraint letter for that: ju
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-18
00:38 ---
(In reply to comment #6)
> Andrew, your testcase is invalid. You cannot access a variable of long type
> through a pointer to int. I know the original code disables strict aliasing,
> but I did not test if
tions/hb.html.
Additional information:
"gfortran -v" gives:
Reading specs from
/auto/home0/rmunk/temp_gfortran/irun/bin/../lib/gcc/i686-pc-linux-gnu/4.0.0/specs
Configured with: ../gcc/configure --enable-languages=c,f95
--prefix=/usr/work/2004352/irun
Thread model: posix
gcc version
--- Additional Comments From giovannibajo at libero dot it 2004-12-18
00:33 ---
Andrew, your testcase is invalid. You cannot access a variable of long type
through a pointer to int. I know the original code disables strict aliasing,
but I did not test if your testcase also aborts with
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-18
00:30 ---
My patch for Bug 18191 includes Andrew's patch for this bug.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-18
00:24 ---
Note the fixed up patch is here with the fix for 18191 also:
http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01322.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18999
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-18
00:22 ---
Posted a patch:
http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01322.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18191
--- Additional Comments From giovannibajo at libero dot it 2004-12-18
00:12 ---
The program is correct, because you are still accessing a MGS object through a
MGS pointer, so GCC should not segfault here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19061
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-18
00:02 ---
Here is at least a testcase for the MAX_EXPR problem:
Compile with -O0, works, compiling with -O2 -fno-tree-lrs does not.
long fff[10];
long f(long a, long b)
{
long crcc = b;
long d = *((int*)(a+1));
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-12-18
00:02 ---
It's indeed not a regression.
Testing patch.
--
What|Removed |Added
AssignedTo|un
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-12-18
00:00 ---
Testing patch.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |reic
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17
23:50 ---
(In reply to comment #3)
> We expanding this:
Yes it is, here is an small example of where we produce wrong code, I have to
think of a full working
testcase which we can run:
int *fff;
int f(int a, int b)
--- Additional Comments From giovannibajo at libero dot it 2004-12-17
23:48 ---
Yes, that's the problem. The whole point is that the parser does not have
enough context information to fully check for the number of template headers:
there is an off-by-one possible error it has to allow.
--- Additional Comments From giovannibajo at libero dot it 2004-12-17
23:35 ---
Some discussion about how this warning interacts with the tree-ssa framework
can be found here:
http://gcc.gnu.org/ml/gcc/2004-12/msg00681.html
http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01309.html
--
--- Additional Comments From belyshev at lubercy dot com 2004-12-17 23:28
---
We expanding this:
___r2.303 = MAX_EXPR <___r3.316, *((int *) ___r2.303 + 1B)>;
into this:
(insn 12778 12777 12779 1127 (set (reg/v:SI 1280 [ ___r2.303 ])
(reg/v:SI 1273 [ ___r3.316 ])) -1 (nil)
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17
23:25 ---
: Search converges between 2004-11-25-014001-trunk (#656) and
2004-11-25-161001-trunk
(#657).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19030
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17
23:20 ---
: Search converges between 2002-12-14-trunk (#159) and 2002-12-29-trunk (#160).
Confirmed.
--
What|Removed |Added
---
The following testcase causes an ICE since gcc 3.4.0:
===
template struct A {};
===
PR13268B.cc:5: error: expected identifier before 'operator'
PR13268B.cc:5: error: declaration of 'operator>' as non-function
PR13268B.cc:5: internal
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17
23:13 ---
*** Bug 19062 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17
23:12 ---
So closing as a dup then.
*** This bug has been marked as a duplicate of 5035 ***
--
What|Removed |Added
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dnovillo at gcc dot gnu dot
|dot org |org
Status|SUSPENDED
--- Additional Comments From dnovillo at redhat dot com 2004-12-17 22:54
---
Subject: Re: -Wuninitialized tricked by conditional
assignments
pinskia at gcc dot gnu dot org wrote:
> --- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17
> 22:41 ---
> Isn't thi
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17
22:41 ---
Isn't this just a dup of the long standing bug 5035?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19062
--- Additional Comments From dnovillo at gcc dot gnu dot org 2004-12-17
22:21 ---
Fix: http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01314.html
--
What|Removed |Added
With the fix for PR 18501 we are now emitting false positives on
gcc.dg/uninit-5.c and gcc.dg/uninit-9.c.
Analysis of problem:
http://gcc.gnu.org/ml/gcc/2004-12/msg00681.html
http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01309.html
--
Summary: -Wuninitialized tricked by conditional as
--
What|Removed |Added
GCC host triplet||ia64-hp-hpux11.23
Summary|ia64-hp-hpux11.23 |IA64 GCC pointer confusion
--- Additional Comments From dberlin at dberlin dot org 2004-12-17 21:12
---
Subject: Re: ICE with -O1 -ftree-loop-linear
on small test case
Because the submitted patch has not yet been approved and applied.
On Fri, 17 Dec 2004, fjahanian at apple dot com wrote:
>
> --- Additio
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-12-17
20:59 ---
Nathan, this was caused by your patch
http://gcc.gnu.org/ml/gcc-cvs/2003-06/msg00871.html
Apparently we have a tcc_exceptional in the last switch
statement of cp_tree_equal so that we hit gcc_unreachable.
--- Additional Comments From phython at gcc dot gnu dot org 2004-12-17
20:42 ---
I haven't tested this yet, but perhaps something as simple as
Index: trans-common.c
===
RCS file: /cvsroot/gcc/gcc/gcc/fortran/trans-common.c,v
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17
20:15 ---
Confirming as and removing regression marker as suggested by David.
--
What|Removed |Added
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-12-17
19:44 ---
Indeed, this can be demonstrated with the following testcase:
===
struct A;
namespace N
{
struct A;
}
using namespace N;
int A::i;
int A::i;
namespace N
{
struct C;
--- Additional Comments From fjahanian at apple dot com 2004-12-17 19:40
---
Why hasn't been there be a resolution of this PR? It seems that all issues,
including elimination of
loop numbers, etc. have been taken care of. Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18792
--- Additional Comments From nathan at codesourcery dot com 2004-12-17
19:38 ---
Subject: Re: [4.0 Regression] ice on tree check
reichelt at gcc dot gnu dot org wrote:
> --- Additional Comments From reichelt at gcc dot gnu dot org 2004-12-17
> 19:02 ---
> Please ignore my pre
--- Additional Comments From Thomas dot Koenig at online dot de 2004-12-17
19:32 ---
The assertion failure happens for me on
an i686-pc-linux-gnu, as well. Looks like
different bugs on different architectures for
the same test case. (The assertion failure
is a bug, too!)
--
http://
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-12-17
19:02 ---
Please ignore my previous comment.
The fix is not that easy. :-(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19030
The included program coredumps during execution when compiled with -O2 but not
when compiled with -O0. The problem appears to be with combine and the use of
the ptr_extend_plus_2 instruction. GCC is losing track of what is and isn't a
pointer. I am not entirely sure if the program is legal given
--- Additional Comments From wanderer at rsu dot ru 2004-12-17 18:44
---
First time i see this problem in september-october.
Now i only fill PR.
Program work for me only if it used gcc 3.4.x shared libraries.
~/pkg/gcc/bin/g++ test.cc
setenv LD_LIBRARY_PATH $HOME/pkg/gcc_34/lib
./a.out
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17
18:33 ---
Hmm, it works for me on ppc-darwin with the mainline (20041215 and 20041214 and
20041213).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19060
--- Additional Comments From wanderer at rsu dot ru 2004-12-17 18:31
---
Created an attachment (id=7773)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7773&action=view)
.s file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19060
--- Additional Comments From wanderer at rsu dot ru 2004-12-17 18:31
---
Created an attachment (id=7772)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7772&action=view)
.ii file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19060
Program:
---8X---
#include
int main() {
std::ofstream file("test.txt");
std::streampos startpos = file.tellp();
file << 10;
std::streampos endpos = file.tellp();
assert(endpos != startpos);
return 0;
}
---X8---
compile at g++ 3.4.3 and
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-12-17
18:14 ---
Patch at http://gcc.gnu.org/ml/fortran/2004-12/msg00177.html
--
What|Removed |Added
--- Additional Comments From pmcnary at cameron dot net 2004-12-17 18:07
---
I have same problems building on OSR5 with UP3 and MP3.
math.h unmatch #ENDIF
same error as above for eh_alloc.cc
Exact problem building 3.4.2
Building 3.3.x problem with math.h and unmatched #ENDIF
and build s
*A -- gcc 4.0.0 20041217 compiled by gcc 3.4.4 20041217
*B -- gcc 4.0.0 20041217 compiled by itself.
All errors are within 0.05 .. 0.5 %
--
What|Removed |Added
Last reconfirmed|2004-1
AtTiny13 and AtTiny2313 are considered as avr4 architecture. But they do not
support all the instructions of avr4.
For example the "mul" instruction does not exist. See bellow a test case for
mul.
avr-gcc -mmcu=attiny2313 test_mul.c
int main(void) {
uint8_t a, b;
uint16_t res;
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17
17:24 ---
Fixed on the mainline.
--
What|Removed |Added
Status|ASSIGNED
--
What|Removed |Added
Keywords||rejects-valid
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-17
17:21 ---
Nathan, this is stage3, you *are* allowed to apply non-regression fixes.
By not applying it there you've just created a new 4.0 regression...
--
What|Removed |Added
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-12-17
17:12 ---
Hi Nathan, the following patch fixes the ICE for me:
Index: gcc/gcc/cp/name-lookup.c
===
RCS file: /home/reichelt/GCC/CVS/gcc-cvs/gcc/gcc/cp/
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-12-17
17:11 ---
Present on x86 and x86-64 too as of today on 3.4 branch.
--
What|Removed |Added
GCC targe
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |nathan at gcc dot gnu dot
|dot org |org
Status|NEW
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2004-12-17
16:44 ---
The patch looks correct although the code is messy. With the patch,
when is_friend is true and processing_specialization is false, we
no longer count the number of template header to see if there are
too
--- Additional Comments From bangerth at dealii dot org 2004-12-17 16:34
---
Nathan, if this isn't a regression but a patch has been applied to the
3.4 branch, then you should also apply it to mainline. Otherwise you have
just created a regression (3.4.4 will work as expected, but 4.0.
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-17
16:19 ---
Subject: Bug 18975
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED] 2004-12-17 16:19:24
Modified files:
gcc/cp : Change
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17
16:18 ---
This is because sum is not used outside of the loop with optimization turned
on. We always use 0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19058
--- Additional Comments From nathan at gcc dot gnu dot org 2004-12-17
16:17 ---
fixed
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From nathan at gcc dot gnu dot org 2004-12-17
16:10 ---
Fix for 3.4 branch
2004-12-17 Nathan Sidwell <[EMAIL PROTECTED]>
PR c++/18975
* method.c (do_build_copy_constructor): Refactor. Don't const
qualify a mutable field.
(do_buil
In the code that follows, gcc-3.4.1 says:
> gcc -W -Wall -Wno-unused-parameter qux.c -O2
qux.c:13: warning: variable 'x' might be clobbered by `longjmp' or `vfork'
gcc-4.0 with those same options gives no warning.
Note that neither version warns about 'sum' being clobbered.
#include
#include
--- Additional Comments From nathan at gcc dot gnu dot org 2004-12-17
16:00 ---
2004-12-17 Nathan Sidwell <[EMAIL PROTECTED]>
PR c++/18721
* class.c (add_method): Do not push conversion operators into a
binding level.
--
http://gcc.gnu.org/bugzilla/show_bug
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-17
15:58 ---
Subject: Bug 17821
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-12-17 15:58:05
Modified files:
gcc/cp : ChangeLog class.c cp-tree.h error.c
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-12-17
15:35 ---
Oooops. That was the error message. ;-)
Here's the testcase:
===
struct A;
namespace N
{
struct A;
}
using namespace N;
int A
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-12-17
15:34 ---
Here's a reduced testcase:
===
PR19030.cc:10: error: 'A' has not been declared
PR19030.cc:11: error: 'A' has not been declared
PR1903
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17
15:32 ---
*** Bug 19057 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17
15:32 ---
This is a dup of bug 18932, which got fixed on the 12th.
*** This bug has been marked as a duplicate of 18932 ***
*** This bug has been marked as a duplicate of 18932 ***
--
What|Removed
--- Additional Comments From bero at arklinux dot org 2004-12-17 15:31
---
Created an attachment (id=7769)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7769&action=view)
Preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19057
CC [M] fs/ncpfs/inode.o
fs/ncpfs/inode.c: In function `ncp_notify_change':
fs/ncpfs/inode.c:202: error: insn does not satisfy its constraints:
(insn 1089 333 335 19 include/asm/string.h:410 (parallel [
(set (reg:CCNO 17 flags)
(compare:CCNO (and:QI (reg:QI 5 d
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17
15:18 ---
The code is undefined, once you get into that, anything can happen so closing
as invalid.
We just optimize away the add and the load since the load is no longer needed.
--
What|Removed
A minimized test case:
int main() {
int y = 1;
int *x = &y;
volatile int sum = 0;
while(1) {
sum += *x;
x++;
}
return 0;
}
Clearly, this should crash; under 3.4.1 it does. Under my checkout of a few
hours ago, however, it does not: instead, it enters an in
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-17
15:13 ---
Subject: Bug 15001
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-12-17 15:13:44
Modified files:
libjava: ChangeLog
libjava/java/lang/
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-17
15:09 ---
Subject: Bug 18931
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-12-17 15:09:12
Modified files:
gcc/java : ChangeLog convert.h expr.c typeck.c
--- Additional Comments From jbeulich at novell dot com 2004-12-17 14:28
---
Now that I have an Itanium2 system to test with, I can confirm that the problem
still exists in 3.4.3, and looking at the delta to 4.0.0's ia64.md there is no
reason to believe the problem would have been fixed
1 - 100 of 141 matches
Mail list logo
