--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
Version|unknown |4.2.0
http://
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-09 07:25 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-09 07:31 ---
--combine is not tested that well. In fact for this case, the decls should be
combined into one and not warned about but it looks like GCC combines these two
variables.
--
http://gcc.gnu.org/bugzilla/show_bug.c
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27897
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-06-09 07:37
---
(In reply to comment #10)
> implicit COMPLEX (a-z)
Does that actually declare the variables in MAIN or just say after the first
use, they are declared in that function as complex?
(this should be noted as a sepe
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27922
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27936
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||build
Summary|s-taprop.adb:66:06: warning:|[4.2 Regression
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-06-09 07:45 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27958
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-06-09 07:49 ---
Can you also attach the preprocessed source?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27970
--
ayers at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |ayers at gcc dot gnu dot org
|dot org
--- Comment #6 from ayers at gcc dot gnu dot org 2006-06-09 08:01 ---
Patch posted at:
http://gcc.gnu.org/ml/gcc-patches/2006-06/msg00410.html
and waiting for approval.
--
ayers at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from bonzini at gnu dot org 2006-06-09 08:15 ---
I'll give it a shot. If combine could, well, combine the two instructions, it
would be quite easy to make a patch, and it would remove some most hackish
aspects of the Altivec implemention.
--
http://gcc.gnu.org/bugzil
--- Comment #12 from paul dot richard dot thomas at cea dot fr 2006-06-09
08:50 ---
(In reply to comment #11)
> (In reply to comment #10)
> > implicit COMPLEX (a-z)
> Does that actually declare the variables in MAIN or just say after the first
> use, they are declared in that function
--- Comment #2 from jakub at gcc dot gnu dot org 2006-06-09 08:56 ---
Works just fine in GCC 3.4.x (in that case with -O2 -mtune=z990 which fails
in 4.1.x as well) and works on the trunk too (but it is unclear whether that's
just because reload chooses different registers by accident or
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2006-06-09 09:06
---
I ran into it some time ago too.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2006-06-09 09:08
---
Confirmed, this happens when the compiler is configured for SJLJ exceptions.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #13 from rguenth at gcc dot gnu dot org 2006-06-09 09:34
---
This no longer blocks 27116 because I was able to fix that differently.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from jakub at gcc dot gnu dot org 2006-06-09 09:42 ---
This has been fixed by the PR20103 changes.
*** This bug has been marked as a duplicate of 20103 ***
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #55 from jakub at gcc dot gnu dot org 2006-06-09 09:42 ---
*** Bug 27129 has been marked as a duplicate of this bug. ***
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #13 from tbm at cyrius dot com 2006-06-09 09:57 ---
This segfault also shows up when compiling thunderbird-1.5.0.2 with gcc 4.2 on
Alpha.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27082
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-06-09 10:24 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|rguenth at gcc dot gnu dot |unassigned at gcc dot gnu
|org
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|rguenth at gcc dot gnu dot |unassigned at gcc dot gnu
|org
gcc/cp/call.c build_now_op, emits a warning for comparison of different enum
types. It seems to be neither controlled by any warning option nor documented.
I don't want to fix all thoose warnings (a large amount in our code) right now,
and at the same time turn on -Werror and fix other warnings. T
--- Comment #3 from krebbel at gcc dot gnu dot org 2006-06-09 11:41 ---
On s390 we use a trick to make the literal pool base register
available "on demand". It is defined as eliminable register
which can be eliminated to itself with offset 0. When a reload round
finds a r13 (literal pool
--- Comment #14 from rguenth at gcc dot gnu dot org 2006-06-09 12:39
---
Subject: Bug 26998
Author: rguenth
Date: Fri Jun 9 12:39:11 2006
New Revision: 114507
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114507
Log:
2006-06-09 Richard Guenther <[EMAIL PROTECTED]>
--- Comment #15 from rguenth at gcc dot gnu dot org 2006-06-09 12:39
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #21 from patchapp at dberlin dot org 2006-06-09 12:55 ---
Subject: Bug number PR27116
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-06/msg00457.html
--
http://gcc.gnu.org/bugzilla/s
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-06-09 13:14 ---
WAITING is used to get feed back from the reporter.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
The following code makes the compiler to consume infinite stack memory during
compilation. Obviously the code is invalid.
struct a {
a() {}
a std::b;
};
This problem does occur with any gcc 4.0.2 or later, not with gcc 3.3.5 or
older. I have not checked versions in between.
std can be re
--- Comment #5 from paul dot richard dot thomas at cea dot fr 2006-06-09
15:19 ---
Created an attachment (id=11647)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11647&action=view)
An experimental fix for the PR
This was to have been the second of the two approaches, described ab
--- Comment #2 from ro at techfak dot uni-bielefeld dot de 2006-06-09
15:36 ---
Subject: Re: [4.2 Regression] Ada bootstrap failure on Solaris 10/x86
ebotcazou at gcc dot gnu dot org writes:
> Confirmed, this happens when the compiler is configured for SJLJ exceptions.
But this seem
I'm attaching the code which demonstates the bug.
If to compile the attached code with:
cc -fPIC -S testlib.c
you can see, that symbol "foo" is referenced, but no code with "foo" is
generated (even label "foo" is missing in assembler code)
(Workaround is to compile with -O flag, with -O code for
--- Comment #1 from ykar at list dot ru 2006-06-09 16:08 ---
Created an attachment (id=11648)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11648&action=view)
test case to demonstrate the bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27978
I think the following "invalid conversion" error, which is believe is wrong.
When I remove the bitfield, the program compile fine. In any case, the error
message isn't really optimal. :)
(sid)4502:[EMAIL PROTECTED]: ~/src] cat test.cpp
class Ast
{
enum AstKind { };
const AstKind kind :
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-06-09 16:52 ---
*** Bug 27978 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-09 16:52 ---
This is already fixed in 4.1.2 and the mainline.
*** This bug has been marked as a duplicate of 27758 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-09 16:56 ---
Confirmed, 4.1.0 accepted this code.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from tromey at gcc dot gnu dot org 2006-06-09 17:09 ---
Teting a patch.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|un
--- Comment #15 from jbwaters at gmail dot com 2006-06-09 17:29 ---
As an FYI:
I was able to build 4.0.3 just fine. 4.1.0 and 4.1.1 both fail as per this
ticket. So whatever changed to break building on NetBSD happened between 4.0.3
and 4.1.0.
--
http://gcc.gnu.org/bugzilla/show_
>From a posting to comp.lang.fortran:
program xint_func
implicit none
integer, parameter :: n=3,ii(n)=(/2,0,-1/)
integer:: i
character(len=80) :: line
do i=1,n
write (line,'(10I5)'), int_func(ii(i))
end do
contains
function int_func(n) result(ivec)
integer, inte
--- Comment #2 from tbm at cyrius dot com 2006-06-09 17:47 ---
The following, related example, fails with gcc 4.2 20060508 but works with
20060530. It would be great if whoever works on this PR could check what
change was responsible to get this working, and if it was just an accidental
--- Comment #3 from tbm at cyrius dot com 2006-06-09 18:03 ---
It wasn't accidentally fixed. It was fixed by Mark Mitchell for PR c++/27506,
which contain the same test case as my 2nd example. In any case, the first
test case wasn't fixed by the fix for PR 27506.
--
tbm at cyrius d
--- Comment #12 from janis at gcc dot gnu dot org 2006-06-09 18:10 ---
The reduced testcase from comment #7 doesn't fail with my i686 cross compilers
on powerpc-linux, so I did a regression hunt using the testcase from comment
#4. It identified this patch as the fix on mainline:
htt
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot
|dot org
--- Comment #10 from martinol at nrlssc dot navy dot mil 2006-06-09 18:30
---
gcc-4.1-20060331 snapshots compiles successfully.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27878
--- Comment #13 from janis at gcc dot gnu dot org 2006-06-09 18:44 ---
The test starts failing on mainline with this patch:
http://gcc.gnu.org/viewcvs?view=rev&rev=83858
r83858 | rth | 2004-06-29 16:25:28 + (Tue, 29 Jun 2004)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
The programme
program longint
real x
if (.true.) x = 12345678901
end program longint
contains an integer constant that does not fit into 32 bits. The compiler
gives the following error message:
$ ~/gcc/bin/gfortran -Wall -c longint.f90
In file longint.f90:3
if (.true.) x = 12345678901
--- Comment #6 from pault at gcc dot gnu dot org 2006-06-09 19:40 ---
I seem to be on the way to fixing this, so I had beter assign it to myself!
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #11 from pcarlini at suse dot de 2006-06-09 19:42 ---
For comparison, please provide the config.log of that snapshot. Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27878
--- Comment #4 from jakub at gcc dot gnu dot org 2006-06-09 21:13 ---
Subject: Bug 27748
Author: jakub
Date: Fri Jun 9 21:13:25 2006
New Revision: 114519
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114519
Log:
PR preprocessor/27746
* directives.c (do_pragma):
--- Comment #13 from jakub at gcc dot gnu dot org 2006-06-09 21:13 ---
Subject: Bug 27746
Author: jakub
Date: Fri Jun 9 21:13:25 2006
New Revision: 114519
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114519
Log:
PR preprocessor/27746
* directives.c (do_pragma)
--- Comment #4 from jakub at gcc dot gnu dot org 2006-06-09 21:13 ---
Subject: Bug 27747
Author: jakub
Date: Fri Jun 9 21:13:25 2006
New Revision: 114519
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114519
Log:
PR preprocessor/27746
* directives.c (do_pragma):
--- Comment #2 from jakub at gcc dot gnu dot org 2006-06-09 21:18 ---
Subject: Bug 27916
Author: jakub
Date: Fri Jun 9 21:18:42 2006
New Revision: 114520
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114520
Log:
PR fortran/27916
* trans-openmp.c (gfc_omp_clause
--- Comment #3 from jakub at gcc dot gnu dot org 2006-06-09 21:25 ---
Should be fixed in SVN.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Sta
--- Comment #14 from jakub at gcc dot gnu dot org 2006-06-09 21:26 ---
Should be fixed in SVN.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
St
--- Comment #5 from jakub at gcc dot gnu dot org 2006-06-09 21:26 ---
Should be fixed in SVN.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Sta
--- Comment #5 from jakub at gcc dot gnu dot org 2006-06-09 21:27 ---
Should be fixed in SVN.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Sta
--- Comment #2 from tromey at gcc dot gnu dot org 2006-06-09 21:36 ---
Fixed.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from tromey at gcc dot gnu dot org 2006-06-09 21:37 ---
Subject: Bug 27730
Author: tromey
Date: Fri Jun 9 21:37:32 2006
New Revision: 114524
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114524
Log:
PR libgcj/27730:
* java/lang/Thread.java (threa
There are some optimization ideas in this e-mail thread (especially in the
leaves or the thread).
http://gcc.gnu.org/ml/java/2006-06/msg00030.html
Basically, Buffers have no accessable constructors, so the compiler knows that
there can be no user classes derived from Buffer. Buffers can be treat
--- Comment #8 from vapier at gentoo dot org 2006-06-09 22:01 ---
unless i did something wrong, it's still broken with gcc-4.1.1 ... except now i
get an ICE:
[EMAIL PROTECTED] 0 ~ $ alpha-unknown-linux-gnu-gcc -c alpha-hidden-weak.c
alpha-hidden-weak.c: In function '_start':
alpha-hidde
--- Comment #6 from pault at gcc dot gnu dot org 2006-06-09 22:16 ---
Subject: Bug 24558
Author: pault
Date: Fri Jun 9 22:16:08 2006
New Revision: 114526
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114526
Log:
2006-06-10 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #3 from pault at gcc dot gnu dot org 2006-06-09 22:16 ---
Subject: Bug 25047
Author: pault
Date: Fri Jun 9 22:16:08 2006
New Revision: 114526
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114526
Log:
2006-06-10 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #3 from pault at gcc dot gnu dot org 2006-06-09 22:16 ---
Subject: Bug 20877
Author: pault
Date: Fri Jun 9 22:16:08 2006
New Revision: 114526
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114526
Log:
2006-06-10 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
byte compile: /mnt/gnu/gcc/objdir/gcc/gcj
-B/mnt/gnu/gcc/objdir/hppa2.0w-hp-hpux
11.11/libjava/ -B/mnt/gnu/gcc/objdir/gcc/ --encoding=UTF-8 -C
-I/mnt/gnu/gcc/obj
dir/hppa2.0w-hp-hpux11.11/libjava/testsuite/../libgcj-4.2.0.jar -g
/mnt/gnu/gcc/
gcc/libjava/testsuite/libjava.lang/md5test.java -d
/mnt/
--- Comment #3 from wilson at gcc dot gnu dot org 2006-06-10 01:19 ---
This is a C front end bug. The C front end is creating a circular symbol
table, where the function h is defined both in the external scope and inside
itself. The dwarf2out.c code then goes into an infinite recursion
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-10 02:21 ---
Why is this that bad of a warning, really it could prove useful to make sure
that you don't end up with always true comparisons because enums are not the
same as their under lieing type in C++.
--
http://gcc.gnu
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-10 02:47 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #5 from wilson at gcc dot gnu dot org 2006-06-10 02:49 ---
If a combination is successful, we will delete i1 and i2, so it doesn't matter
if they changed accidentally.
If a combination fails, then we go through undobuf and revert all changes, so
it doesn't matter if i1 or i2
--- Comment #1 from kargl at gcc dot gnu dot org 2006-06-10 05:03 ---
Erik,
Thanks for the report. This is yet another example of gfortran's
error handling code getting confused. If you remove the "if (.true.)"
then you get the error message you want. If the if statement, the
error i
74 matches
Mail list logo
