--- Comment #4 from pault at gcc dot gnu dot org 2006-02-23 06:27 ---
and with "4.2.0 20060222".
Where's the bug, chaps?
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26409
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-02-23 04:02
---
I should also point out you did not follow the instructions on
http://gcc.gnu.org/bugs.html
Which explicitly point out what is requested of you for filing a bug report.
1. Source code that will compile (your exam
--- Comment #10 from bugzilla-gcc at thewrittenword dot com 2006-02-23
03:02 ---
Sure. It might take a few days.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26436
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-02-23 02:56 ---
Can you try 3.4.5?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summa
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-02-23 02:52
---
Now also fixed on the 4.0 branch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from bugzilla-gcc at thewrittenword dot com 2006-02-23
02:41 ---
gcc-4.0.2 with either as 2.16/2.16.1 generates no warning.
gcc-3.4.3 with either as 2.16/2.16.1 generates the warning.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26436
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-02-23 02:39
---
Subject: Bug 26291
Author: reichelt
Date: Thu Feb 23 02:39:24 2006
New Revision: 111380
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111380
Log:
PR c++/26291
* decl.c (grok_op_properties)
--- Comment #7 from bugzilla-gcc at thewrittenword dot com 2006-02-23
02:39 ---
Created an attachment (id=10897)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10897&action=view)
.i file (gcc-4.0.2 with as 2.16.1)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26436
--- Comment #6 from bugzilla-gcc at thewrittenword dot com 2006-02-23
02:38 ---
Created an attachment (id=10896)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10896&action=view)
.s file (gcc-4.0.2 with as 2.16.1)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26436
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2006-02-23 02:24
---
Well its at the 8192 boundary again similar to pr25835. In that case we needed
to flush the buffers at the end of a read. I will look further.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26423
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2006-02-23 02:12
---
Thought we had this fixed. Will have to look again.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26423
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-23 01:47 ---
Does -O2 -fno-strict-aliasing works?
Does -O2 -fno-tree-vrp works?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-23 01:44 ---
Confirmed, a regression from 3.3.
In 4.0 and above we get either the following two errors:
On GNU/Linux:
/tmp/cc9KVEBk.o: In function
`Test::Test()':t.cc:(.gnu.linkonce.t._ZN4TestIiEC1Ev[Test::Test()]+0x33):
undefine
--- Comment #5 from bugzilla-gcc at thewrittenword dot com 2006-02-23
01:39 ---
Looking at gas/Changelog between 2.16 and 2.16.1, I see:
2005-05-19 Jan Beulich <[EMAIL PROTECTED]>
* config/tc-ia64.c (dot_endp): Don't use global symbol for unwind
relocations in u
--- Comment #4 from bugzilla-gcc at thewrittenword dot com 2006-02-23
01:38 ---
$ /opt/TWWfsw/gcc343/ia64-hp-hpux11.23/bin/as --version
GNU assembler 2.16
Copyright 2005 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU Gene
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-23 01:38 ---
I bet this is really just PR 25937 again exposed with a different testcase and
improvements to other parts of GCC.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Adde
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-23 01:34 ---
What version of binutils are you using?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26436
--- Comment #1 from quanah at stanford dot edu 2006-02-23 01:25 ---
Oh, and here are my configure options:
configure '--datadir=${prefix}/lib' '--libexecdir=${prefix}/lib'
'--sharedstatedir=${prefix}/lib' --prefix=/usr/pubsw --enable-threads --wi
th-gnu-as --with-as=/usr/pubsw/bin/as
I've been trying to get gcc-4.0.2 to build on our AMD64 box. I'm using gcc-3.4
to bootstrap it. After successfully completing the first 3 stages, gcc fails
in building the java area with:
/afs/ir/src/pubsw/languages/gcc-build/@sys/gcc/xgcc -shared-libgcc
-B/afs/ir/src/pubsw/languages/gcc-build/@
--- Comment #22 from amodra at bigpond dot net dot au 2006-02-23 01:08
---
Richard, aren't you confusing MD_FALLBACK_FRAME_STATE_FOR with
MD_FROB_UPDATE_CONTEXT? The former only happens when we have no unwind, the
latter on each uw_update_context.
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #21 from rth at gcc dot gnu dot org 2006-02-23 01:01 ---
No. MFUC only applies when there is no unwind information available. When
the vdso is present, unwind information is available.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26208
--- Comment #20 from amodra at bigpond dot net dot au 2006-02-23 00:41
---
Created an attachment (id=10895)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10895&action=view)
updated for powerpc and powerpc64
Jakub of course is correct that the vdso eh_frame dwarf2 can't increment
--- Comment #2 from bugzilla-gcc at thewrittenword dot com 2006-02-23
00:16 ---
Created an attachment (id=10894)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10894&action=view)
.i file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26436
--- Comment #1 from bugzilla-gcc at thewrittenword dot com 2006-02-23
00:16 ---
Created an attachment (id=10893)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10893&action=view)
.s file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26436
While trying to build matplotlib-0.87 on HP-UX 11.23/IA-64 with gcc-3.4.3:
gcc -fno-strict-aliasing -DNDEBUG -D_FILE_OFFSET_BITS=64 -O2
-I/opt/TWWfsw/python235p/include/python2.3 -fPIC -I/opt/TWWfsw/libttf21/include
-I/opt/TWWfsw/libpng12/include -I/opt/TWWfsw/zlib11/include -I.
-I/opt/TWWfsw/pytho
--- Comment #3 from pault at gcc dot gnu dot org 2006-02-23 00:06 ---
(In reply to comment #1)
> Confirmed.
> It worked with "4.2.0 20060215".
>
It works with GNU Fortran 95 (GCC) 4.2.0 20060219 on FC3/Athlon
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26409
Hi,
Following code gets ICE.
elm3b11:/home/pawar> cat test.c
typedef struct _A2 A2;
struct _A2 {
int type ;
int n1 ;
int n2 ;
int inc1 ;
int inc2 ;
double *entries ;
};
double
A2_infinityNorm (
A2 *mtx
) {
double norm ;
int ncol, nrow ;
if ( (nrow = mtx->n1) <= 0 || (ncol
--- Comment #3 from bugzilla-gcc at thewrittenword dot com 2006-02-22
23:43 ---
Any plans to add _LARGE_FILES support to g++/libstdc++ for AIX?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20366
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-02-22 23:29
---
(In reply to comment #10)
> am i crazy?
Can you read:
http://portal.acm.org/citation.cfm?id=103163
Before replying again?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26428
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-22 23:04 ---
*** Bug 26429 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-22 23:04 ---
Then this is a dup of bug 23384.
*** This bug has been marked as a duplicate of 23384 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
Syntax error when attempting to use the built-in macro __FUNCTION__ in the
catch handler of a try/catch block where the try/catch wraps a template class'
constructor and includes the member initializer list.
-
gcc configure:
Configur
--- Comment #21 from mmitchel at gcc dot gnu dot org 2006-02-22 22:51
---
Set back to P3 so that I will be sure to reconsider it.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-02-22 22:28 ---
Ah, and that is even correct. Because the objects escape here, so we cannot do
better (without IP escape analysis).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26429
--- Comment #1 from dberlin at gcc dot gnu dot org 2006-02-22 22:21 ---
Actually, the problem you are describing is that call clobbering is not per
call (IE context-sensitive), so that it believes something clobbered somewhere
means it is clobbered everywhere.
--
dberlin at gcc dot g
--- Comment #1 from olh at suse dot de 2006-02-22 22:14 ---
what I have found so far is: -O2 and -Os fails, -O1 boots
another thing:
I moved the kernel tree around, and after this move and a clean rebuild with
the very
same gcc41 sources, the kernel boots again. I'm using O=../somdir, wh
--- Comment #24 from mrs at apple dot com 2006-02-22 22:11 ---
Submitted patch to fix this
http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01705.html
--
mrs at apple dot com changed:
What|Removed |Added
--- Comment #12 from law at redhat dot com 2006-02-22 21:45 ---
Subject: Re: Fowardprop does harm for VRP to
figure out if a point is non zero
On Wed, 2006-02-22 at 20:55 +, rguenth at gcc dot gnu dot org wrote:
>
> --- Comment #11 from rguenth at gcc dot gnu dot org
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-02-22 21:32 ---
Patch posted, but now stdarg-5.c ICEs.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
our current kernel does does boot ok on G4 systems (PowerMac, Pegasos2),
but it locksup early (before the atyfb init) on a G3 ibook, no idea where
exactly.
gcc33 hammer as shipped with SLES9 works ok, gcc-4_0-branch works ok,
gcc-4_1-branch does not boot.
cant test gcc-mainline because make does n
--- Comment #7 from law at redhat dot com 2006-02-22 21:30 ---
Subject: Re: [4.2 Regression] ice on valid C
code with flag -Os
On Wed, 2006-02-22 at 18:07 +, pinskia at gcc dot gnu dot org wrote:
>
> --- Comment #5 from pinskia at gcc dot gnu dot org 2006-02-22 18:07
--- Comment #1 from g dot delaportas at gmail dot com 2006-02-22 21:15
---
There is no EXCUSES for higher or lower bitsthe numbers are WRONG and this
should be fixed
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26431
--- Comment #12 from pcarlini at suse dot de 2006-02-22 21:16 ---
*** Bug 26431 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26428
--- Comment #2 from pcarlini at suse dot de 2006-02-22 21:16 ---
*** This bug has been marked as a duplicate of 26428 ***
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #11 from pcarlini at suse dot de 2006-02-22 21:15 ---
*** Bug 26430 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26428
--- Comment #1 from pcarlini at suse dot de 2006-02-22 21:15 ---
*** This bug has been marked as a duplicate of 26428 ***
--
pcarlini at suse dot de changed:
What|Removed |Added
When using g++ as a compiler and my program is trying to substract to floats
that have the same ending digits, after comma, or even when the digits are not
even or odd at the same time the returned number is buged!
For example:
105.8 - 108.5 ===> 2.67
1583.5- 583.4 ===> 1000.099976
The sam
When using g++ as a compiler and my program is trying to substract to floats
that have the same ending digits, after comma, or even when the digits are not
even or odd at the same time the returned number is buged!
For example:
105.8 - 108.5 ===> 2.67
1583.5- 583.4 ===> 1000.099976
The sam
For
typedef struct {
int i;
int j;
int k;
} Foo;
void bar(Foo*);
void foo(void)
{
{
Foo a;
bar(&a);
}
{
Foo b;
bar(&b);
}
}
we have in the alias1 dump:
foo ()
{
struct Foo b;
struct Foo a;
:
# a_3 = V_MAY_DEF ;
# b_4 = V_MAY_DEF ;
bar (&a);
# a_5
--- Comment #10 from g dot delaportas at gmail dot com 2006-02-22 20:56
---
If u don't understand that this is not right then u have a big problem in
mathematics cause bc,xcalc or whatever and all the other compilers i have
tested in other operating systems returned the actual and right
--- Comment #11 from rguenth at gcc dot gnu dot org 2006-02-22 20:55
---
So I suppose VRP cannot see "backwards" for
i_2 = j_1;
if (i_2 == 0)
return j_1;
? (of course copyprop would clean this up, but suppose for a moment this
gets to VRP)
If it can see that i_1 is zero at t
--- Comment #9 from g dot delaportas at gmail dot com 2006-02-22 20:53
---
(In reply to comment #7)
> (In reply to comment #6)
> > TEST CASE
> I mean some source code.
>
Oh the source code is rather simple
float Val1,Val2,Val3;
Val1=1583.5;
Val2=583.4;
Val3=Val2-Val1;
printf("Value:
--- Comment #8 from steven at gcc dot gnu dot org 2006-02-22 20:50 ---
User doesn't understand number representations in computers.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-02-22 20:50
---
Confirmed on i686-linux (trunk) too:
$ cat testio.f
integer :: a(8476)
a(1) = 1
write(2) a
a(1) = 2
write(2) a
rewind 2
read(2) a
write(*,*) a(1)
read(2) a
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-02-22 20:48 ---
(In reply to comment #6)
> TEST CASE
I mean some source code.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from g dot delaportas at gmail dot com 2006-02-22 20:46
---
(In reply to comment #5)
> Well the caculator is using higher precission (maybe even unlimited) floating
> point than what your testcase would look like.
>
> Again where is the testcase?
>
> Also you should go
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-02-22 20:44 ---
Well the caculator is using higher precission (maybe even unlimited) floating
point than what your testcase would look like.
Again where is the testcase?
Also you should go read some papers about floating point in
--- Comment #4 from g dot delaportas at gmail dot com 2006-02-22 20:34
---
(In reply to comment #3)
> (In reply to comment #2)
> > It is abdolutely true and well known that 1583.5-583.4=1000.1
>
> Who said that 1000.1 can be repesented exactly in the computer?
>
okso explain to m
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-22 20:31 ---
(In reply to comment #2)
> It is abdolutely true and well known that 1583.5-583.4=1000.1
Who said that 1000.1 can be repesented exactly in the computer?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26428
--- Comment #2 from g dot delaportas at gmail dot com 2006-02-22 20:29
---
It is abdolutely true and well known that 1583.5-583.4=1000.1
Its defenate. Simple mathematics
Its not my problem if u have problems with maths!
Try your calculators and pleas do not reply stupid thing!
CRI
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-22 20:24 ---
And why do you think this is a bug?
Floating point is not the same as math as you would do on paper.
Also where is the testcase?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26428
When using g++ as a compiler and my program is trying to substract to floats
that have the same ending digits, after comma, or even when the digits are not
even or odd at the same time the returned number is buged!
For example:
105.8 - 108.5 ===> 2.67
583.4 - 1583.4 ===> 1000.099976
The sam
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-22 19:19 ---
Patch posted:
http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01774.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-22 19:00 ---
This causes a lot of the gfortran testsuite to fail.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26427
Testcase:
struct a {};
static const int d = 1;
static const struct a b = {};
static const int c = 1;
int f(const int *, const struct a *, const int*, const int*);
int g(void)
{
return f(&c, &b, &d, &c);
}
int f(const int *b, const struct a *c, const int *d, const int *e)
{
return *b == *d;
}
in
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-22 18:57 ---
I am working on this again.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from mueller at gcc dot gnu dot org 2006-02-22 18:53 ---
Yes, thanks.
--
mueller at gcc dot gnu dot org changed:
What|Removed |Added
Status|RE
Consider:
struct A { virtual ~A(); }; // 4
struct B { virtual ~B(); }; // 4
struct X : virtual public A,
virtual public B { // 8
};
struct Y : virtual public B { // 4
virtual ~Y();
};
struct Z : virtual public X, public Y { // 8
Z();
};
Z::Z() {}
In th
--- Comment #6 from law at redhat dot com 2006-02-22 18:18 ---
Subject: Re: [4.2 Regression] ice on valid C
code with flag -Os
On Wed, 2006-02-22 at 18:07 +, pinskia at gcc dot gnu dot org wrote:
>
> --- Comment #5 from pinskia at gcc dot gnu dot org 2006-02-22 18:07
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-22 18:11 ---
But not with 4.2.0 on x86_64-linux so confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-22 18:10 ---
Hmm, this worked in 4.0.3 at least on x86_64-linux-gnu.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26423
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-02-22 18:07 ---
Hmm, for some reason the Type's TYPE_MAX_VALUE is null.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26425
--- Comment #3 from pcarlini at suse dot de 2006-02-22 18:01 ---
... something considered "obvious" in the literature is that the size policy
goes together with the range-hashing function: e.g., an exponential size-policy
would not work well together with our default modulo range-hashing
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-22 17:59 ---
Reduced testcase:
struct keyring_list {
struct key *keys[0];
};
void keyring_destroy(struct keyring_list *keyring, unsigned short a)
{
int loop;
for (loop = a - 1; loop >= 0; loop--)
key_put(keyring->keys[loop
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-22 17:55 ---
It is ICEing in the last VRP.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-02-22 17:35
---
Fixed on mainline.
Waiting for the 4.1 branch to reopen.
Testing on the 4.0 and 3.4 branch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-22 17:34 ---
Reducing (which means I can reproduce this ICE).
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from bkoz at gcc dot gnu dot org 2006-02-22 17:26 ---
HP, I also don't know what is going on here, but it seems unlikely that the
libstdc++ code is to blame, just because there's been no change to this part of
libstdc++ in quite a while.
One thing you could check, if you
--- Comment #2 from pcarlini at suse dot de 2006-02-22 17:23 ---
(In reply to comment #1)
> Just curious: is the assumption of prime-size buckets hardwired in the TR?
> Otherwise, the obvious alternative would be to use power-of-two sizes, which
> are much faster in access.
Yes. Really,
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-02-22 17:22
---
Subject: Bug 26291
Author: reichelt
Date: Wed Feb 22 17:22:08 2006
New Revision: 111367
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111367
Log:
PR c++/26291
* decl.c (grok_op_properties)
--- Comment #8 from bkoz at gcc dot gnu dot org 2006-02-22 17:17 ---
This is now fixed to my satisfaction.
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from falk at debian dot org 2006-02-22 17:11 ---
Just curious: is the assumption of prime-size buckets hardwired in the TR?
Otherwise, the obvious alternative would be to use power-of-two sizes, which
are much faster in access.
--
http://gcc.gnu.org/bugzilla/show_bug.
--- Comment #1 from dcb314 at hotmail dot com 2006-02-22 17:06 ---
Created an attachment (id=10892)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10892&action=view)
C source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26425
--- Comment #1 from paolo at gcc dot gnu dot org 2006-02-22 17:06 ---
Subject: Bug 26132
Author: paolo
Date: Wed Feb 22 17:05:58 2006
New Revision: 111366
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111366
Log:
2006-02-22 Paolo Carlini <[EMAIL PROTECTED]>
PR libstd
I just tried to compile a recent Linux kernel with a recent
GNU C++ compiler version 4.2 snapshot 20060218.
The compiler snapshot said
/home/dcb/gnu/42-20060218/results/bin/gcc -g -O3 -Wall
-Wp,-MD,security/keys/.keyring.o.d -nostdinc -isystem
/home/dcb/gnu/42-20060218/results/lib/gcc/x86_64
--- Comment #20 from hjl at lucon dot org 2006-02-22 17:04 ---
I don't want to see this patch hold up 4.1.0 release. I will ask it be
applied to the 4.1 branch when it is open. But it is Mark's call.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25603
--- Comment #19 from hjl at gcc dot gnu dot org 2006-02-22 16:59 ---
Subject: Bug 25603
Author: hjl
Date: Wed Feb 22 16:59:45 2006
New Revision: 111365
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111365
Log:
2006-02-22 H.J. Lu <[EMAIL PROTECTED]>
PR target/25603
The number of buckets is currently limited to ~2^32 (see X<>::primes). This is
a serious issue: for correctness, rehash(n) for n > 2^32 should throw and do
nothing, in order not to violate the post-conditions in Table 21.
We have various options: as suggested by Howard off-line, we could well comp
Configured with: ../gcc/configure --prefix=/Users/dir/gfortran
--enable-languages=c,f95
Thread model: posix
gcc version 4.2.0 20060222 (experimental)
[dranta:~/tests/gfortran-D] dir% cat testio7.f
program test
implicit real*8 (a-h,o-z)
dimension a(8476)
istoh=8476
do 10 j
--- Comment #18 from rguenth at gcc dot gnu dot org 2006-02-22 16:30
---
As this is a wrong-code regression for 4.1 (albeit on ia64-linux), Mark should
re-consider the priority and maybe allow this patch in. And the patch
submitter should have asked for that in the first place (and can
--
pcarlini at suse dot de changed:
What|Removed |Added
Target Milestone|--- |4.1.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26132
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-02-22 16:23 ---
I get
:
# SFT.0D.1534_2 = V_MUST_DEF ;
aD.1532.iD.1521 = 1;
# SFT.0D.1534_3 = V_MAY_DEF ;
bar (&aD.1532);
# SFT.0D.1534_4 = V_MAY_DEF ;
bar2 (aD.1532);
for this case.
--
http://gcc.gnu.org/bu
--- Comment #10 from law at redhat dot com 2006-02-22 16:22 ---
Subject: Re: Fowardprop does harm for VRP to
figure out if a point is non zero
On Wed, 2006-02-22 at 12:47 +, rguenth at gcc dot gnu dot org wrote:
A little history...
DOM was pretty clever in that it had the
--- Comment #3 from sabre at nondot dot org 2006-02-22 16:11 ---
Fair enough. Shouldn't this be diagnosed with an error though?
-Chris
--
sabre at nondot dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-22 16:02 ---
Really for this example:
For this case V_MAY_DEF's are dead anyways at least for the other SFT's besides
the one for a.i.
Try thinking what about:
typedef struct {
int i;
int j;
int k;
} Foo;
void bar(Foo*);
The function in question should ignore ADDR_EXPRs that appear inside CALL_EXPR
parameter lists so that we, for
typedef struct {
int i;
int j;
int k;
} Foo;
void bar(Foo*);
void foo(void)
{
Foo a;
a.i = 1;
bar(&a);
}
do not create SFTs for all elements of a, but only for the first. T
--- Comment #9 from law at redhat dot com 2006-02-22 15:24 ---
Subject: Re: Fowardprop does harm for VRP to
figure out if a point is non zero
On Wed, 2006-02-22 at 10:32 +, rguenth at gcc dot gnu dot org wrote:
>
> --- Comment #4 from rguenth at gcc dot gnu dot org 20
--- Comment #5 from danglin at gcc dot gnu dot org 2006-02-22 15:22 ---
The libiberty version is documented as unsigned and has been this
way for many years. The Open Group has a strawman proposal which may
be submitted to the Austin Group for addition to POSIX in its next
release. It
--- Comment #1 from reichelt at gcc dot gnu dot org 2006-02-22 15:10
---
Confirmed.
Even shorter testcase:
==
int i=0;
#pragma omp threadprivate (i)
void foo()
{
i=0;
}
==
--
reichelt at gcc dot gnu dot org change
--- Comment #2 from rootkit85 at yahoo dot it 2006-02-22 14:40 ---
I have broken RAM.
Sorry for complaining gcc
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26407
1 - 100 of 137 matches
Mail list logo
