--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-11-20
10:24 ---
Mine.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |ebotcazou at
--- Additional Comments From toon at moene dot indiv dot nluug dot nl
2004-11-20 12:03 ---
(In reply to comment #0)
> z2 = conjg (z1)
>1
> Error: Type of argument 'z' in call to 'conjg' at (1) should be COMPLEX(4),
> not
> COMPLEX(8)
Yep, I think this in intrinsic.c:
ad
--- Additional Comments From toon at moene dot indiv dot nluug dot nl
2004-11-20 12:10 ---
Hmmm, I do not get this on my powerpc-unknown-linux-gnu:
[EMAIL PROTECTED]:~/g95-bugs$ /usr/snp/bin/gfortran -O2 18518.f90
[EMAIL PROTECTED]:~/g95-bugs$ (LD_LIBRARY_PATH=/usr/snp/lib export
LD_LI
--- Additional Comments From toon at moene dot indiv dot nluug dot nl
2004-11-20 12:16 ---
I agree too, that's why I changed the status of this bug report to "NEW", i.e.,
confirmed :-)
Toon.
--
What|Removed |Added
l/gcc/native --enable-__cxa_atexit
--enable-languages=c,c++,objc,f95,java
--enable-checking=assert,misc,tree,rtl,rtlflag --disable-libmudflap
Thread model: posix
gcc version 4.0.0 20041120 (experimental)
However, I'm seeing a bootstrap comparison failure on sparc-sun-solaris2.5.1:
Bootstrap
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-20
13:15 ---
Subject: Bug 16135
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-11-20 13:15:17
Modified files:
libgfortran: ChangeLog acinclude.m4 config.h.in co
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-20
13:15 ---
Subject: Bug 17999
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-11-20 13:15:17
Modified files:
libgfortran: ChangeLog acinclude.m4 config.h.in co
: ../gcc/configure --prefix=/home/ig25
--enable-languages=c,c++,f95
Thread model: posix
gcc version 4.0.0 20041120 (experimental)
$ cat pr18518-test2.f90
subroutine foo
integer i,g,h
data i/0/
equivalence (g,h)
save g
if (i == 0) then
i = 1
h = 12345
end if
print *,h
end su
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-11-20
13:21 ---
See http://gcc.gnu.org/ml/fortran/2004-11/msg00127.html
--
What|Removed |Added
--
Bug 16991 depends on bug 16135, which changed state.
Bug 16135 Summary: [4.0 Regression] libfortran doesn't build, use of C99 types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16135
What|Old Value |New Value
--
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-11-20
13:21 ---
See http://gcc.gnu.org/ml/fortran/2004-11/msg00127.html
--
What|Removed |Added
--
Bug 16135 depends on bug 17999, which changed state.
Bug 17999 Summary: [4.0 Regression] libfortran: uses some C99 functions
(snprintf)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17999
What|Old Value |New Value
-
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-11-20
13:40 ---
> However, I'm seeing a bootstrap comparison failure on sparc-sun-solaris2.5.1:
>
> Bootstrap comparison failure!
> ./fold-const.o differs
> cp/typeck.o differs
>
> and sparc-sun-solaris2.6:
>
> Bootstr
--- Additional Comments From belyshev at lubercy dot com 2004-11-20 14:01
---
I can confirm this on i686-pc-linux-gnu:
Bootstrap comparison failure!
./fold-const.o differs
./loop.o differs
--
What|Removed |Added
-
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-11-20
14:12 ---
At this point we can say that there is a problem somewhere.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-20
15:45 ---
This is __NOT__ fixed by (because alpha is a LP64 target) but it makes it
easier to fix:
* acinclude.m4 (LIBGFOR_TARGET_ILP32): New check.
* configure.ac: Include LIBGFOR_TARGET_ILP32.
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-20
15:46 ---
Arm is fixed but not all targets which use newlib by (because some targets are
LP64 aka MMIX):
* acinclude.m4 (LIBGFOR_TARGET_ILP32): New check.
* configure.ac: Include LIBGFOR_TARGET_ILP32.
--- Additional Comments From andreast at gcc dot gnu dot org 2004-11-20
15:47 ---
I get differs too on powerpc-apple-darwin7.6.0 with --enable-checking (and
without):
Bootstrap comparison failure!
./combine.o differs
./convert.o differs
./fold-const.o differs
cp/parser.o differs
cp/type
Test case:
static float tfcos12[3];
__attribute__((noinline)) double f(double x) { return x; }
int g;
int main(void) {
int i, j;
for (i = 0; i < 1; i++)
tfcos12[i] = 0.5;
for (i = 0; i < 1; i++) {
tfcos12[i] = 0.5 * f(i);
for (j = 0; j < 12; j++)
--
What|Removed |Added
Target Milestone|--- |3.3.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18577
--- Additional Comments From steven at gcc dot gnu dot org 2004-11-20
16:44 ---
Confirmed, I see similar code on x86:
.L4:
xorl%ebx, %ebx
.L7:
xorl%edx, %edx
testb %bl, %bl
jne .L2
--
What|Removed
--- Additional Comments From mrs at apple dot com 2004-11-20 16:46 ---
This patch is ok.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18102
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-20
16:49 ---
And now this is fixed on the mainline.
--
What|Removed |Added
Status|SUSPENDED
--
Bug 13246 depends on bug 11292, which changed state.
Bug 11292 Summary: [new-ra] causes sibcalling to go wrong.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11292
What|Old Value |New Value
--
--- Additional Comments From steven at gcc dot gnu dot org 2004-11-20
17:01 ---
I have the following in the .optimized dump:
flow_bb_inside_loop_p (loop, source_loop)
{
unsigned char D.1171;
struct loop * D.1170;
struct loop * * D.1169;
struct loop * * D.1168;
unsigned
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-20
17:11 ---
Note changing flow_loop_nested_p to return an int instead of unsigned char, the
jump threading works
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18576
$ gfortran -v
Reading specs from /home/ig25/lib/gcc/i686-pc-linux-gnu/4.0.0/specs
Configured with: ../gcc/configure --prefix=/home/ig25
--enable-languages=c,c++,f95
Thread model: posix
gcc version 4.0.0 20041120 (experimental)
$ cat vary.f90
program main
call foo(3.0)
contains
subroutine foo
--- Additional Comments From steven at gcc dot gnu dot org 2004-11-20
17:11 ---
Situation in DOM3:
# BLOCK 4
# PRED: 3 [100.0%] (fallthru,exec) 2 [81.0%] (true,exec) 1 [50.0%]
(true,exec)
# iftmp.0_1 = PHI <0(2), 1(3), 0(1)>;
:;
D.1171_13 = (unsigned char) iftmp
gfortran -v
Reading specs from /home/ig25/lib/gcc/i686-pc-linux-gnu/4.0.0/specs
Configured with: ../gcc/configure --prefix=/home/ig25
--enable-languages=c,c++,f95
Thread model: posix
gcc version 4.0.0 20041120 (experimental)
$ cat vary2.f90
program main
real :: b
call foo(b)
contains
This PR is aimed at tracking the vectorizer failures on the SPARC. As of today,
we have 11 failures on SPARC 32-bit:
FAIL: gcc.dg/vect/vect-13.c scan-tree-dump-times vectorized 1 loops 1
FAIL: gcc.dg/vect/vect-27.c scan-tree-dump-times vectorized 1 loops 1
FAIL: gcc.dg/vect/vect-27a.c scan-tree-d
--- Additional Comments From hjl at lucon dot org 2004-11-20 17:33 ---
I have verified that this patch
http://gcc.gnu.org/ml/gcc-patches/2004-11/msg01624.html
is the cause.
--
What|Removed |Added
--
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-20
17:34 ---
Subject: Bug 18580
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-11-20 17:34:28
Modified files:
gcc/testsuite : ChangeLog
gcc/testsuite/gcc.
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-20
17:44 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
E
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-20
17:46 ---
I assume you are talking about:
call foo(3.0)
if so confirmed, there should be a warning about this being undefined.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-20
17:48 ---
Confirmed.
--
What|Removed |Added
Severity|normal |minor
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-11-20
17:53 ---
We have one additional failure on SPARC 64-bit:
FAIL: gcc.dg/vect/pr18425.c scan-tree-dump-times vectorized 1 loops 1
The pr18425.c.t50.vect logfile contains:
loop at pr18425.c:15: not vectorized: can'
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-20
17:56 ---
Hmm, this is 3.4 and 4.0 Regression, 3.3.3 produced:
flow_bb_inside_loop_p:
pushl %ebp
movl%esp, %ebp
movl8(%ebp), %ecx
pushl %ebx
movl12(%ebp), %eax
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-20
17:59 ---
gcc.dg/vect/pr18425.c also fails on ppc64 IIRC, see PR 18403.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18580
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-11-20
18:26 ---
> Testcase pr18425.c can't be vectorized with -m64 because there's no vector
> support for 64bit elements. This testcase should also xfail (not temporarily)
> when -m64 is used or if the compiler is conf
The following snippet compiles fine with GCC versions prior to 3.4.3
and aborts with an ICE with 3.4.3:
struct S {
int i;
int a[];
};
S v = { 0, {} };
$ g++ -V 3.4.3 -c bug.cc
bug.cc:6: internal compiler error: in tree_low_cst, at tree.c:3313
Please submit a full bug report,
with preprocesse
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-20
18:33 ---
*** This bug has been marked as a duplicate of 18384 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-20
18:33 ---
*** Bug 18581 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-20
18:40 ---
This is a mygwin bug as I only just get a call to fmod:
callfmod
--
What|Removed |Added
-
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-20
18:41 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
E
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-20
18:42 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
E
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-20
18:43 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
E
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-20
18:45 ---
Confirmed, this is minor as the problem is that you need a new binutils as
reported before.
--
What|Removed |Added
--
--- Additional Comments From bothner at gcc dot gnu dot org 2004-11-20
19:30 ---
It's minor if we accept that people who run Darwin without the
updated binutils and try to build from source will get an error message
without any clue about what to do. Perhaps we can hope there aren't ver
--- Additional Comments From phython at gcc dot gnu dot org 2004-11-20
20:00 ---
http://gcc.gnu.org/ml/gcc-patches/2004-11/msg01653.html
--
What|Removed |Added
Key
Using
gcc -c ice.c
with the following file "ice.c"
typedef double v2df __attribute__((mode(V2DF)));
void
sse_interpolate_kernel()
{
double x2[2];
v2df xs[2];
xs[0] = __builtin_ia32_loadupd(x2);
}
leads to the following internal compiler error:
ice.c: In function `sse_
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-20
20:21 ---
: Search converges between 2003-01-27-trunk (#173) and 2003-02-03-trunk (#174).
: Search converges between 2003-01-28-3.3 (#19) and 2003-02-04-3.3 (#20).
Fixed on the mainline by the merge of the tree-ssa:
--- Additional Comments From ebotcazou at libertysurf dot fr 2004-11-20
20:32 ---
Subject: Re: [4.0 Regression] jump threading on trees is slow with switch
statements with large # of cases
> [ Yes, I got the message regarding the bootstrap comparison failure
> on darwin. I'm going
--- Additional Comments From law at redhat dot com 2004-11-20 20:39 ---
Subject: Re: [4.0 Regression] jump threading
on trees is slow with switch statements with large # of cases
On Sat, 2004-11-20 at 21:33 +0100, Eric Botcazou wrote:
> > [ Yes, I got the message regarding the b
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-20
20:42 ---
Fixed on the mainline by:
2004-11-20 Joseph S. Myers <[EMAIL PROTECTED]>
* c-typeck.c (build_array_ref): Don't check for index == 0. Make
checks for neither argument being an array or poi
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-20
20:48 ---
Oh, it is not fixed by that patch.
--
What|Removed |Added
Status|RESOLVED
--- Additional Comments From hjl at lucon dot org 2004-11-20 21:47 ---
FYI, I saw the same problem on Linux/ia64, Linux/ia32 and Linux/x86_64. I am
using the last binutils from CVS if that matters.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18574
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-20
21:56 ---
I see it on i686-pc-linux-gnu, i686-pc-openbsd3.1 and powerpc-darwin. My linux
box has 1GB of
memory, maybe this is a GC problem but I really dout it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18
If you try to have a constant array of vectors on gcc-3.4.3 you you may get
parse errors when they shouldn't.
All seems related to the vector definition and where you place the const
attribute.
If you define each array element constant and vector is defined as __vector ->
__attribute__((altivec(__
--
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
Component|c
--- Additional Comments From lu_zero at gentoo dot org 2004-11-20 22:09
---
Created an attachment (id=7573)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7573&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18583
--
What|Removed |Added
Known to fail||3.4.3
Known to work||4.0.0 3.4.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-20
22:35 ---
Confirmed.
The problem is:
unit size
align 16 symtab 0 alias set -1 precision 16 min max
pointer_to_this >
V8HI
size
unit size
align
--- Additional Comments From law at redhat dot com 2004-11-20 23:20 ---
Subject: Re: [4.0 Regression] bootstrap comprison
failed
On Sat, 2004-11-20 at 21:56 +, pinskia at gcc dot gnu dot org wrote:
> --- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-20
F is a modern subset of Fortran that does away with a lot
of historical cruft (that Fortran has more than enough of).
I personally would like to use it for new developments, and a
--std=f switch would come in very handy for this.
--
Summary: --std=f would be nice
Product: g
Sun:
java:
-classpath
-cp
javac:
-classpath
GNU:
gij:
-classpath
-cp
gcj:
--classpath=
While gij is unified to java, so is gcj neither to javac or to any other.
What look better?
--cp
--classpath
which has some style, or
-cp
-classpath
which would be equal to java and gij. I prefer the
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-21
00:02 ---
Confirmed, related to PR 1374.
--
What|Removed |Added
OtherBugsDependingO|
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-21
00:03 ---
What is the difference between f and the standardized versions of fortran?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18584
--- Additional Comments From bojan at antonovic dot com 2004-11-21 01:16
---
Subject: Re: uniform passing of the classpath parameter
pinskia at gcc dot gnu dot org wrote:
>--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-21
>00:02 ---
>Confirmed, related t
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-21
01:39 ---
The reason why I say this can never even happen on 4.0 is because the loop
notes are not done until
after the "new" rtl-loop pass is done.
--
What|Removed |Added
--
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-11-21
01:40 ---
There seems to be some conflict between the names "__ct", "__dt" and the
constructor and destructor of the class. Just compile the following code
snippet with "-Wshadow":
==
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-21
01:50 ---
There were only two patches to the C++ front-end during that time period. Both
were by the same
person and they both touched the namelookup code.
2004-07-14 Mark Mitchell <[EMAIL PROTECTED]>
2004-07-13
--
What|Removed |Added
Target Milestone|4.0.0 |---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16307
The following code snippet causes an ICE on mainline:
==
template struct A
{
template int A::i;
};
==
bug.cc:3: error: type 'A' is not derived from type 'A< >'
bug.cc:3: internal compiler error: Segmentation fault
Please submit a
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-21
02:02 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
E
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-11-21
02:21 ---
Mark, it was in fact your patch
http://gcc.gnu.org/ml/gcc-cvs/2004-07/msg00730.html
that caused the regression.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18530
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-21
02:29 ---
Confirmed, here is the backtrace:
#0 0x001f2ad8 in pop_scope (t=0x0) at ../../gcc/cp/name-lookup.c:2571
#1 0x0013cde8 in cp_parser_init_declarator (parser=0x41e9a30c,
decl_specifiers=0xb410,
function
--- Additional Comments From falk at debian dot org 2004-11-21 02:33
---
The bug seems to be caused by the loop unroller making a pseudo local
to be able to duplicate it while it is still needed outside of the loop.
Reverting Eric Botcazou's patch for rtl-optimization/11841, which is
als
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-21
03:18 ---
I am almost certain this was caused by:
http://gcc.gnu.org/ml/gcc-patches/2004-08/msg00212.html
--
What|Removed |Added
---
--- Additional Comments From law at redhat dot com 2004-11-21 04:24 ---
Subject: Re: [4.0 Regression] bootstrap comprison
failed
On Sat, 2004-11-20 at 21:56 +, pinskia at gcc dot gnu dot org wrote:
> --- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-20
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-21
04:53 ---
With the mainline on ppc-darwin we have a huge problem in the scheduler:
scheduling: 131.99 (44%) usr 52.35 (75%) sys 231.63 (46%) wall
PRE (GCSE) is also a problem too:
PRE
--- Additional Comments From law at redhat dot com 2004-11-21 05:15 ---
I've found something that might be of interest. It's certainly odd, but
I don't yet know if the odd behavior I'm could explain the bootstrap
comparison failures yet. I'm still poking...
Jeff
--
http://gcc.gnu
For PR 15855 we see that the tree aliasing analysis is slow:
tree alias analysis : 24.22 ( 6%) usr 0.75 ( 2%) sys 26.57 ( 5%) wall
9% of the total time is spent looking at for if something is in either
build_v_may_defs or build_vuses.
--
Summary: build_v_may_defs and build_vus
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-21
05:33 ---
These part are 4.0 regressions:
tree alias analysis : 24.22 ( 6%) usr 0.75 ( 2%) sys 26.57 ( 5%) wall
tree PHI insertion: 7.71 ( 2%) usr 1.26 ( 3%) sys 9.24 ( 2%) wall
tree SSA rewrite
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-21
05:54 ---
The combiner problem comes from the distrubute_notes loop.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15855
--
What|Removed |Added
OtherBugsDependingO||15855
nThis||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18587
--- Additional Comments From law at redhat dot com 2004-11-21 06:31 ---
OK. I can see a way that we might be getting these comparison failures.
We're hashing on pointers, then doing table traversals. If the memory
layout changes, the ordering of objects in the hash table can change.
Ch
--- Additional Comments From ebotcazou at libertysurf dot fr 2004-11-21
07:12 ---
Subject: Re: [4.0 Regression] jump threading on trees is slow with switch
statements with large # of cases
> I haven't seen the comparison failure on i686 -- if I had I never
> would have checked in the
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-11-21
07:14 ---
> The bug seems to be caused by the loop unroller making a pseudo local
> to be able to duplicate it while it is still needed outside of the loop.
> Reverting Eric Botcazou's patch for rtl-optimization/118
88 matches
Mail list logo
