--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-05-23
06:38 ---
(In reply to comment #5)
My patch removes vect-none.c, so it's impossible to get failures on this
testcase. I guess, there is a problem either in how I created the patch (I
did 'cvs remove' and 'cvs
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-05-23
07:45 ---
outer_field_access_p(), build_outer_field_access(), etc. are only for non-static
fields (instance variables). Even for some simple testcases, I could not get GCJ
to emit correct bytecode for non-static
During recent performance testing I have identified a number of small code
fragments where gcc 4.x produces worse code than gcc 3.4.3. Some of these may be
target specific, and I plan to gradually enter such small performance
regressions into the bug database unless there is a better way to report
--
What|Removed |Added
Keywords||missed-optimization
Known to fail||4.0.0 4.1.0
Known to work|
--- Additional Comments From nickc at redhat dot com 2005-05-23 08:46
---
Hi Guys,
I have checked in a patch which restores Kazuhiro's original patch and which
should stop the testsuite from complaining.
Cheers
Nick
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21707
Attached testcase ICEs at -m32 -march=i386 -O2 -ffast-math in
swap_rtx_condition.
Cross jumping there merges testqi_ext_0/jcc_1 from 2 different BB's, but keeps
the %ax setters (cmpfp_2_df_1) in the original blocks.
(insn:HI 2037 4155 2038 55 (set (reg:HI 0 ax [783])
(unspec:HI [
--- Additional Comments From jakub at gcc dot gnu dot org 2005-05-23 09:02
---
Created an attachment (id=8950)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8950action=view)
pr21716.c
Testcase (too large though).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21716
--- Additional Comments From P dot Schaffnit at access dot rwth-aachen dot
de 2005-05-23 09:05 ---
Hi!
I was trying to read some binary data written by a GFortran binary with binaries
written with other compilers (LF, SGI), and I couldn't get anywhere, so I just
started to poke around
--- Additional Comments From hubicka at gcc dot gnu dot org 2005-05-23
09:09 ---
I am having problems to reproduce it on my machines (i686,x86-64,powerpc64) so
I need some help debugging the problem (at least backtrace to start with)
Honza
--
What|Removed
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-05-23
09:13 ---
I will regression test it, later on to confirm it is really fixed.
If all goes well, I'll change the resolution to FIXED and status
to RESOLVED.
--
What|Removed
The ACATS tests c95085a, c95085b and c95086a fail with an endless stream of
exceptions.
$ tail ./c9/c95086a/c95086a.log
* NO_NAME EXCEPTION RAISED IN ACCEPT E1.
* NO_NAME EXCEPTION RAISED IN ACCEPT E1.
* NO_NAME EXCEPTION RAISED IN ACCEPT E1.
* NO_NAME EXCEPTION RAISED IN
--- Additional Comments From antonvys at mail dot ru 2005-05-23 09:40
---
I think if I use ./configure with flags --with-mpfr=[PATH] --with-gmp=[PATH]
libgmp should be automatically added to LD_LIBRARY_PATH for building.
Otherwise it should be mentioned in docs that setting flags
--- Additional Comments From hubicka at ucw dot cz 2005-05-23 09:44 ---
Subject: Re: [4.1 Regression] gcc.dg/pch/inline-4.c fails
Hi,
I finally reproduced it on IA-64 machine. I am testing the attached
fix. Can you please try if it fixes your problem too?
2005-05-23 Jan Hubicka
--
What|Removed |Added
CC||matz at suse dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20297
--
What|Removed |Added
CC||pluto at agmk dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20297
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-05-23
10:11 ---
More compact testcase:
===
templateint struct A
{
void foo();
};
templateint N void bar()
{
AN a;
struct B { B() { a.foo(); } } b;
}
template void
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-05-23
10:46 ---
This got fixed by Diego's reorganization of the initial optimization passes:
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00955.html
http://gcc.gnu.org/ml/gcc-cvs/2005-05/msg00529.html
--
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-05-23
11:29 ---
I'll re-run the regression test later on.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21630
--- Additional Comments From giovannibajo at libero dot it 2005-05-23
12:23 ---
The best way is to use Bugzilla, yes. Please use different bug reports for each
code fragment, thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21715
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-23
12:44 ---
Fixed.
--
What|Removed |Added
Status|WAITING |RESOLVED
--
What|Removed |Added
Keywords||ra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21715
--
What|Removed |Added
Status|WAITING |NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21654
--
What|Removed |Added
Status|NEW |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21654
When compiled with -Wall,
int foo (void) { if (9007199254740991.45 ==
9007199254740991.5) return 1;}
does not complain about a missing return statement, showing that GCC is folding
the comparison to true. However, the LHS should round down.
With one less 9 GCC
--
What|Removed |Added
Component|c |middle-end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21718
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-23
13:52 ---
Confirmed.
--
What|Removed |Added
URL|
Tracing down a problem with sudo receiving a stack corruption on one machine,
I've found out that a minimal program gets a stack corruption when compiled with
gcc-3.4.3, but not when being compiled with HP's bundled cc. See details here:
http://www.sudo.ws/bugs/show_bug.cgi?id=170#c26
The minimal
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-23
14:02 ---
This really sounds like a HP C library bug or bug in the code but I don't know
for sure. You are using
old style KR C, can you use -Wall -W and fix all the warnings?
--
--
What|Removed |Added
Component|c |target
Keywords||wrong-code
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-05-23
14:32 ---
Ivan, this looks like a duplicate of your PR 20789 to me.
Or is there any major difference?
--
What|Removed |Added
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-05-23 14:50
---
We probably don't even get it right for all cases with DECIMAL_DIG digits for
all long double formats (required by Annex F).
--
What|Removed |Added
Unlike decimal floats, correctly rounding hex floats is easy and cheap, so we
should do it. Moreover the standard requires it.
With -Wall GCC complains that the following function is missing a return
statement because it has incorrectly folded the comparison to false.
int foo(void) { if
--- Additional Comments From kristerw at netbsd dot org 2005-05-23 15:31
---
Subject: Re: libjava bootstrap failure in
java/lang/natConcreteProcess.cc
On Sun, 22 May 2005, pinskia at gcc dot gnu dot org wrote:
--- Additional Comments From pinskia at gcc dot gnu dot org
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-23
15:39 ---
Yes I was told late last night the same thing.
This was caused by:
2004-08-12 David Daney [EMAIL PROTECTED]
PR libgcj/11801
* java/lang/PosixProcess.java: Rewrote.
*
--- Additional Comments From bh at techhouse dot brown dot edu 2005-05-23
15:41 ---
(In reply to comment #2)
*** Bug 21156 has been marked as a duplicate of this bug. ***
I have a pair of attachments on #21156 that may be relevant; I don't know the
appropriate way to link them in to
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-23
15:44 ---
This has now been fixed.
--
What|Removed |Added
Status|NEW
--
What|Removed |Added
OtherBugsDependingO||16989
nThis||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21720
--- Additional Comments From joseph at codesourcery dot com 2005-05-23
15:46 ---
Subject: Re: [4.1 Regression] gcc.dg/pch/inline-4.c fails
On Mon, 23 May 2005, hubicka at ucw dot cz wrote:
I finally reproduced it on IA-64 machine. I am testing the attached
fix. Can you please try
--- Additional Comments From daney at gcc dot gnu dot org 2005-05-23 15:47
---
I don't think we should revert it as Process et al. were broken on many pthread
targets before the patch.
Since NetBSD is not posix, perhaps it should not be using PosixProcess. I am
not a BSD hacker so I
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-05-23
16:00 ---
Looks like there is another memory allocation issue:
$ cat unpack.f90
program main
real, dimension(5) :: a
a = (/(real(i),i=1,5)/)
print *, unpack(a(:), a(:)0, 0.)
end
$ gfortran unpack.f90
$ ./a.out
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-05-23
16:39 ---
Here's a reduced testcase that might be appropriate for the testsuite:
==
/* PR target/21716 */
/* { dg-do compile } */
/* { dg-options
4.0 CVS 20050522 on ia64-linux, binutils-2.15, glibc-2.3.5,
works with 3.3.6 and 3.4.4 releases
$ gcc -O2 -g -c writet1.i
writet1.c: In function 'load_enc':
writet1.c:348: warning: pointer targets in assignment differ in signedness
writet1.c: In function 't1_open_fontfile':
writet1.c:1000:
--- Additional Comments From doko at debian dot org 2005-05-23 16:48
---
Created an attachment (id=8951)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8951action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21721
--- Additional Comments From doko at debian dot org 2005-05-23 16:49
---
Created an attachment (id=8952)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8952action=view)
assembler file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21721
--
What|Removed |Added
Known to fail||3.3.6 3.4.4
Known to work||4.0.1
Below I attached a tarball which contains two packages with one class each.
B.java defines a static final String initilized to foo, and A.java
tries to call the 'equals' method on that object (and another string).
This actually is reduced from trang. The problem happens when this is
compiled
--- Additional Comments From matz at suse dot de 2005-05-23 16:52 ---
Created an attachment (id=8953)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8953action=view)
tarball showing the problem
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21722
--
What|Removed |Added
CC||skh at suse dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21722
--
What|Removed |Added
CC||schwab at suse dot de
Known to fail|3.3.6 3.4.4 |4.0.1
Known to work|4.0.1
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-23
16:59 ---
Related to PR 1259.
--
What|Removed |Added
BugsThisDependsOn|
This is based on a cvs snapshot of gcc 4.0 from 2005/05/20 from the src rpm in
fedora development.
Reference: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=158453
/home/mgalgoci/rpm/BUILD/gcc-4.0.0-20050520/obj-hppa-redhat-linux/gcc/xgcc
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-05-23
17:12 ---
Good news for this PR. I located the root of the problem, which is that when the
library ends, we close() the stdout file descriptor, while the last line of
output (without newline trailing character) is
--
What|Removed |Added
GCC build triplet||hppa-redhat-linux
GCC host triplet||hppa-redhat-linux
GCC target triplet|
--- Additional Comments From mgalgoci at redhat dot com 2005-05-23 17:14
---
Created an attachment (id=8954)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8954action=view)
Preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21723
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-23
17:14 ---
The code is C.
--
What|Removed |Added
Component|fortran
When doing something like:
make install includedir=/foo/bar/baz
in gcc 4.0.0 you get the following error:
test -z /include || mkdir -p -- /include
/usr/bin/install -c -m 644
'/home/ams/gsc/devel/gcc/src/libmudflap/mf-runtime.h' '/include/mf-runtime.h'
/usr/bin/install: cannot create regular
--- Additional Comments From schwab at suse dot de 2005-05-23 17:21 ---
Seems to be fixed in 4.1.
--
What|Removed |Added
Known to work|3.3.6 3.4.4
--
What|Removed |Added
Component|target |c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21723
--
What|Removed |Added
Component|c |target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21723
--- Additional Comments From ams at gnu dot org 2005-05-23 17:28 ---
Created an attachment (id=8955)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8955action=view)
Fix for bug 21724
The following patch fixes the bug.
libmudflap/ChangeLog
2005-05-23 Alfred M. Szmidt [EMAIL
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-23
17:49 ---
Confirmed, reduced testcase:
void pow_c4_i4 (_Complex float a) {}
Only -mpa-risc-1-0 is needed to reproduce this.
--
What|Removed |Added
we should look into replacing or augmenting
libjava/sysdep/*/locks.h with a generic version
based on the new sync built-ins. This would remove
one more step when doing a new port of libgcj.
--
Summary: use new sync built-ins
Product: gcc
Version: 4.1.0
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-23
17:51 ---
Confirmed,
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21725
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-23
17:59 ---
This testcase works in 3.4.4 so it is a regression.
--
What|Removed |Added
Known to
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-23
18:03 ---
Confirmed, I don't get a seg fault but a NPE (NullPointerException) instead.
--
What|Removed |Added
--
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
Keywords|
--- Additional Comments From tromey at gcc dot gnu dot org 2005-05-23
18:06 ---
I agree, we should definitely not revert this.
Instead someone should make this file compile and try to work ok
when no threads are available. Or, if that can't be done,
make a new natBSDProcess.cc.
--
--- Additional Comments From igodard at pacbell dot net 2005-05-23 18:10
---
Looks like it to me too, and I easily could have fallen into the same hole
twice
because it comes from a use of a shared library. Does a single fix make both go
away?
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-23
18:17 ---
Confirmed.
This is just a RA issue, I don't know how much we can fix for 4.0.x.
--
What|Removed |Added
--- Additional Comments From jblomqvi at cc dot hut dot fi 2005-05-23
18:22 ---
The ICE seems to have disappeared, but it still doesn't work correctly. E.g.
implicit none
real(4) :: r = 42.0
r = aint (r,kind=8)
print *, r
end
Prints out 0.00
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-23
18:25 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-05-23
18:58 ---
After analysing my build log carefully, there is problem with the patch:
patching file ChangeLog
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file ChangeLog.rej
patching file
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-05-23
19:01 ---
I have regression tested it, the test summary is available at
http://gcc.gnu.org/ml/gcc-testresults/2005-05/msg01512.html
Now the testsuite failure, I get is :
FAIL: gcc.dg/vect/vect-106.c (test for
A reminder for a simple issue: we are missing a 3.4.0 abi baseline for
powerpc64,
instead that for powerpc is used for powerpc64 too and abi_check fails (very
misleading)
--
Summary: baseline_symbols.txt for powerpc64 missing
Product: gcc
Version: 4.0.0
--
What|Removed |Added
GCC target triplet||powerpc64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21726
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-23
19:29 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--
What|Removed |Added
CC||rth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21692
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-05-23
19:46 ---
They fail for me on x86_64, too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21692
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-23
20:04 ---
Subject: Bug 21075
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-05-23 20:03:53
Modified files:
libgfortran:
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-23
20:04 ---
Subject: Bug 21075
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-05-23 20:03:53
Modified files:
libgfortran:
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-23
20:04 ---
Subject: Bug 21354
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-05-23 20:03:53
Modified files:
libgfortran:
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-05-23
20:05 ---
Fixed in 4.0. Closing.
--
What|Removed |Added
Status|ASSIGNED
--
What|Removed |Added
Summary|unexpected |[4.1 Regression] unexpected
|java.lang.NoClassDefFoundErr|java.lang.NoClassDefFoundErr
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-05-23
20:10 ---
According to a discussion on the fortran mailing
list, some initial work seems to have been done:
http://gcc.gnu.org/ml/fortran/2005-04/msg00071.html
--
--- Additional Comments From cato at df dot lth dot se 2005-05-23 20:55
---
Subject: Re: [4.0/4.1 Regression] libjava bootstrap failure
in java/lang/natConcreteProcess.cc
This is not a BSD problem -- it is just that NetBSD 1.6 is old enough
that threads were not as pervasive as they
The code:
templatetypename T
struct foo { void check(); };
voidfoobool::check() {}
compiles without error even though it needs a template before the
specialization.
--
Summary: accepts specialization without template
Product: gcc
Version: 3.4.0
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-23
21:57 ---
Fixed in 4.0.0.
--
What|Removed |Added
Status|UNCONFIRMED
The following program:
void f(void)
{
void p(void)
{
__label__ l1;
void q(void)
{
goto l1;
}
l1:;
}
p();
}
int
main (void)
{
f();
return 0;
}
compiled using the following command line:
../gcc-lin/gcc/xgcc -B../gcc-lin/gcc/ c_jump2.c
gives me:
/tmp/ccSrSccf.o: In function
module modice
interface
real function foo ()
end function
end interface
end module modice
function foo ()
use modice
implicit none
! foo = 6
end function foo
ICEs in:
internal compiler error: in gfc_typenode_for_spec, at fortran/trans-types.c:631
--
Summary: ICE in
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-23
22:52 ---
tree-cfg is removing the BB for some reason. I have no looked into why yet.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-23
22:57 ---
Fixed since 4.0.0, someone forgot to close the bug.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-23
23:00 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-05-23 23:55
---
Here is the example requested on IRC showing that we don't get it right with
DECIMAL_DIG digits and IEEE quad long double. Tested with current mainline on
sparc-sun-solaris2.10 as an example target where
character*2 a
character*4 b
parameter(a=12)
parameter (b = a)
write (*, *) b
end
gfortran output: 12
correct output: 12
--
Summary: Character length incorrect.
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
--
What|Removed |Added
BugsThisDependsOn||21730
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19276
The code:
class A {};
extern A* a;
namespace {
A* a;
}
int main() {
a = 0;
}
gets you:
~/ootbc/members/src$ g++ foo.cc
foo.cc: In function `int main()':
foo.cc:9: error: `a' undeclared (first use this function)
foo.cc:9: error: (Each undeclared identifier is reported only once
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-05-24 04:22
---
Dudes, just a quick pass at this.
a.out:
/usr/lib/gcc/i386-redhat-linux/3.4.3/../../../../include/c++/3.4.3/bits/basic_string.h:643:
typename _Alloc::reference std::basic_string_CharT, _Traits,
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-05-24 04:34
---
for 4.x and mainline, this is ok:
%g++ -c -g -O2 t2.cc
%g++ -c -g -O2 t1.cc
%g++ t1.o t2.o
For 3.4, I get:
t2.o(.bss+0x0): In function `main':
/home/bkoz/t2.cc:4: multiple definition of
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-05-24 04:36
---
Downgrade from critical, which extension allocators certainly are not.
-benjamin
--
What|Removed |Added
100 matches
Mail list logo
