--- Comment #2 from gaojianbin at 263 dot net 2005-11-23 07:42 ---
1:
I use xls,ibm visual age 6.0 c compiler.
2:configure options is as follows:
../gcc-4.0.2/configure --prefix=/swtdata/emv_emu/emu1/jbgao/gccbin
--enable-threads=aix --enable-languages=c,c++
3:i have read the instal
--- Comment #3 from gdr at gcc dot gnu dot org 2005-11-23 07:12 ---
Fixed on mainline.
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
tivec -DHAVE_AV_CONFIG_H -I.. -I/home/jim/cvs/mplayer/ffmpeg/libavutil
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_GNU_SOURCE -c -o wmadec.o
/home/jim/cvs/mplayer/ffmpeg/libavcodec/wmadec.c
The gcc-snapshot is from the debian package version 20051122-1, the ice also
occurs in earlier versions of the pa
--- Comment #2 from gdr at gcc dot gnu dot org 2005-11-23 07:07 ---
Subject: Bug 21668
Author: gdr
Date: Wed Nov 23 07:07:33 2005
New Revision: 107401
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107401
Log:
PR c/21668
* c-decl.c (grokdeclarator): Don't warn fo
--- Comment #4 from bangerth at dealii dot org 2005-11-23 05:31 ---
I don't have chapter and verse to justify this, but icc and gcc agree
that they should reject this code
--
namespace N {
class C {};
void foo(C) {};
}
using namespace N;
void foo(long) {};
void bar() {
--- Comment #6 from bangerth at dealii dot org 2005-11-23 05:25 ---
Given the literal meaning of the word "void", it is amusing to think
about what one might want to mean when one says "const void"...
--
bangerth at dealii dot org changed:
What|Removed
--- Comment #2 from bangerth at dealii dot org 2005-11-23 05:22 ---
Confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #3 from bangerth at dealii dot org 2005-11-23 05:21 ---
The second constructor is definitely bogus, but its mere existence
does no harm. We should only perform the check for sensibility when
we actually instantiate the second constructor.
W.
--
bangerth at dealii dot or
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-23 05:09 ---
Reduced testcase:
struct allocator {
~allocator();
};
struct string {
string(int, const allocator& __a = allocator());
};
struct logic_error {
logic_error(const string& __arg);
};
void foo(bool b) {
throw b ?
--- Comment #4 from kkojima at gcc dot gnu dot org 2005-11-23 04:55 ---
I've proposed a patch to this PR in
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01648.html
Does it solve PR 24995?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24982
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
GCC build triplet|i686-pc-linux-gnu |
GCC host triplet|i686-pc-linux-gnu |
Target Milestone
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-23 04:18 ---
Reducing.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords|
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-23 04:14 ---
Reconfirm (it is a little easlier to see with the tree dumps):
jmain.main(java.lang.String[]) (args)
{
[jmain.java : 4] _Jv_InitClass (&jmain.class);
[jmain.java : 4] {
[jmain.java : 5] return;
}
}
--
p
Got ICE with latest cvs (but also with 4.0.1 release) on this code:
---
#include
void foo(bool b)
{
throw b ? std::logic_error("") : std::logic_error("");
}
---
Preprocessed file: http://napalm.sf.cz/throw.ii.gz
ICE:
# g++ ./throw.cpp
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-23 04:04 ---
This actually has a xfail testcase associated with it (I think I forgot to file
the bug when I added the testcase).
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Add
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-23 03:59 ---
This looks related to PR 24995 which is the same ICE on the primary/secondary
target.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-23 03:58 ---
Independently found in:
http://gcc.gnu.org/ml/gcc-testresults/2005-11/msg01074.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
/home/pinskia/src/checkin/trunk/gcc/testsuite/gcc.dg/vect/vect-10.c: In
function 'foo':^M
/home/pinskia/src/checkin/trunk/gcc/testsuite/gcc.dg/vect/vect-10.c:24:
internal compiler error: in refers_to_regno_for_reload_p, at reload.c:6281^M
Please submit a full bug report,^M
with preprocessed source
../../xgcc -B../../ -c -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmis
sing-prototypes -fno-common -mdisable-indexing -gnatpg -gnata -I- -I../rts
-
I. -I/xxx/gnu/gcc-3.3/gcc/gcc/ada /xxx/gnu/gcc-3.3/gcc/gcc/ada/make.adb -o
make.
o
raised STORAGE_ERROR : stack overflow or erroneous me
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2005-11-23
03:07 ---
Subject: Re: [4.1/4.2 Regression] make[7]: rc: Command not found
> > I'm not sure either. I did notice that the build that had a problem
> > was using an old version of make (3.79.1). I removed this and
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2005-11-23 02:30
---
Subject: Bug 24794
Author: jvdelisle
Date: Wed Nov 23 02:30:23 2005
New Revision: 107399
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107399
Log:
2005-11-22 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2005-11-23 02:28
---
Subject: Bug 24794
Author: jvdelisle
Date: Wed Nov 23 02:28:44 2005
New Revision: 107397
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107397
Log:
2005-11-22 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2005-11-23 02:14
---
Subject: Bug 24794
Author: jvdelisle
Date: Wed Nov 23 02:14:26 2005
New Revision: 107396
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107396
Log:
2005-11-22 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2005-11-23 02:02
---
Subject: Bug 24794
Author: jvdelisle
Date: Wed Nov 23 02:02:31 2005
New Revision: 107394
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107394
Log:
2005-11-22 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #1 from kargl at gcc dot gnu dot org 2005-11-23 01:22 ---
Have you read http://www.netlib.org/lapack/faq.html#1.23?
Did you update your blas? A scan of the libgfortran source
tree shows no references to s_copy or s_cmp. Try pipe with
only -O as the only flag. You may also
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-23 00:39 ---
What compiler are you starting with?
Also what options did you use to do a configure with.
Also could you make sure that you have read:
http://gcc.gnu.org/install/specific.html#x-ibm-aix
--
pinskia at gcc dot gnu
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|Bootstrap failure with ICE |[4.1/4.2 Regression]
|in |
--- Comment #18 from wilson at gcc dot gnu dot org 2005-11-23 00:20 ---
Created an attachment (id=10320)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10320&action=view)
Turn off partitioning optimization when flag_unwind_tables true.
Suggested untested patch. Gives different mes
--- Comment #17 from wilson at gcc dot gnu dot org 2005-11-23 00:16 ---
The hot/cold section partitioning stuff has no support for generating unwind
info.
See for instance in opts.c where this is turned off when flag_exceptions is
true, which means it is always turned off by default for
--- Comment #16 from joel at gcc dot gnu dot org 2005-11-23 00:00 ---
Checking in on this one. Target m68k-rtems4.7 still fails to compile paranoia
using 4.0.1 with many patches between 4.0.1 and 4.0.2.
Moving to both the head and 4.1 branch as of today, m68k-rtems4.7 compiles
parano
--- Comment #11 from gdr at gcc dot gnu dot org 2005-11-22 23:20 ---
No longer a regression.
Set bug back at "normal" state -- no milestone.
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from fxcoudert at gcc dot gnu dot org 2005-11-22 22:59
---
(In reply to comment #10)
> The following changes in transfer.c appear to fix the problem in Linux
Well, this patch is actually not OK, since it causes regression in the handling
of EOR (like eor_handling_3.f90
--- Comment #4 from amylaar at gcc dot gnu dot org 2005-11-22 22:57 ---
Subject: Bug 21623
Author: amylaar
Date: Tue Nov 22 22:57:35 2005
New Revision: 107381
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107381
Log:
Preparatory work for PR target/21623:
* alpha
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2005-11-22 22:41
---
See http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01642.html
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2005-11-22 22:37
---
Subject: Bug 22561
Author: ebotcazou
Date: Tue Nov 22 22:37:35 2005
New Revision: 107378
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107378
Log:
PR middle-end/22561
* tree-ssa-structal
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2005-11-22 22:35
---
Subject: Bug 22561
Author: ebotcazou
Date: Tue Nov 22 22:35:55 2005
New Revision: 107377
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107377
Log:
PR middle-end/22561
* tree-ssa-structali
--- Comment #1 from laurent at guerby dot net 2005-11-22 22:34 ---
Confirmed everywhere. I assume this is invalid since conceptually this is an
infinite recursion :).
| 4.2.0 20051121 (experimental) (i686-pc-linux-gnu) GCC error: |
| in save_gnu_tree, at ada/utils.c:163
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2005-11-22 22:30
---
Recategorizing.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Compo
I recently upgraded form gcc-3.4.4 to 4.0.2 on an athlon-mp box. I have a c++
program that links to lapack (which was built some time ago under the 3.4.x
series). I use g77 to link the final objects together; however after
upgrading, (and switching g77->gfortran) the link died, basically because
--- Comment #10 from gdr at gcc dot gnu dot org 2005-11-22 22:27 ---
Subject: Bug 22238
Author: gdr
Date: Tue Nov 22 22:27:52 2005
New Revision: 107376
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107376
Log:
PR c++/22238
* error.c (resolve_virtual_fun_from_obj
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-11-22 22:24 ---
I think the first one is harder, I think part of this is already done for int
type but not boolean_type maybe that is a hint on how to fix it.
--
pinskia at gcc dot gnu dot org changed:
What|Remov
procedure Main is
type Bar(E : Integer) is null record;
type CurrentType(D : Integer) is
record
Field : Bar(CurrentType'Size);
-- not sure if this is valid but the compiler shouldn't crash
end record;
begin
null;
end Main;
command line is
gcc -c main.adb
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||jakub at gcc dot gnu dot org
Severity|normal
With a new download of gfortran, the build now fails while building libgfortran
with -
make all-am
/bin/sh ./libtool --mode=compile
/Users/dir/gfortran/gcc/host-powerpc-apple-darwin8.3.0/gcc/xgcc
-B/Users/dir/gfortran/gcc/host-powerpc-apple-darwin8.3.0/gcc/
-B/Users/dir/gfortran/powerpc-apple-dar
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-22 21:12 ---
== and != should be handled the same. Change the summary to reflect the
testcase in comment #0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-22 21:00 ---
The current issue with f4 is that (~((int)a)) != 0 is not converted to ((int)a
!= (~0)) which will then fold to 1, this issue with ~a != 0 not being convert
to a != ~0 is PR 24990 which I am working on a fix.
Then
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-22 20:58 ---
This is done on the RTL level already but would be nice to get it at the TREE
level so that it can fix if we have bools which is PR 18908.
Mine working on a patch.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-22 20:57 ---
f3 problem is PR 24989 which I have a fix for already, testing it right now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18908
--- Comment #10 from kazu at gcc dot gnu dot org 2005-11-22 20:56 ---
Just checked in a patch.
--
kazu at gcc dot gnu dot org changed:
What|Removed |Added
Sta
Take the following couple functions:
int f(int a)
{
return (~a) != 0;
}
int f1(int a)
{
return a != (~0);
}
int f2(int a)
{
return (~a) != 1;
}
int f3(int a)
{
return a != (~1);
}
f and f1 should be the same. Likewise for f2 and f3.
--
Summary: fold should convert ~a == C
--- Comment #9 from kazu at gcc dot gnu dot org 2005-11-22 20:53 ---
Subject: Bug 23435
Author: kazu
Date: Tue Nov 22 20:53:08 2005
New Revision: 107374
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107374
Log:
gcc/
PR target/23435
* m68k.md (zero_extendsidi2):
--- Comment #8 from kazu at gcc dot gnu dot org 2005-11-22 20:42 ---
Subject: Bug 23435
Author: kazu
Date: Tue Nov 22 20:42:54 2005
New Revision: 107373
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107373
Log:
gcc/
PR target/23435
* m68k.md (zero_extendsidi2):
--- Comment #17 from pault at gcc dot gnu dot org 2005-11-22 20:16 ---
I have started to see a light at the end of the tunnel. Going back to easier
but related things, I have found that this is broken, as is its character
cousin:
integer, DIMENSION(:), POINTER :: ptr
allocate (
--- Comment #6 from hp at gcc dot gnu dot org 2005-11-22 19:46 ---
FWIW, I can help narrowing the range of revisions:
XFAILed for cris-*-* and mmix-knuth-mmixware with
"Mon Nov 21 03:58:26 UTC 2005 (revision 107276M)", XPASSing since
"Tue Nov 22 00:42:24 UTC 2005 (revision 107345M)".
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-22 19:41 ---
I am working on a patch to fix this. This should also fix f3 in PR 18908.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
The following two function should be the same:
_Bool f(_Bool a)
{
return a!=1;
}
_Bool f1(_Bool a)
{
_Bool b = !a;
return b;
}
Right now f1 is the most optimal.
--
Summary: boolvar != 1 is not converted to !boolvar
Product: gcc
Version: 4.1.0
S
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-22 19:22 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-22 19:22 ---
Subject: Bug 23606
Author: pinskia
Date: Tue Nov 22 19:22:21 2005
New Revision: 107370
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107370
Log:
2005-11-22 Andrew Pinski <[EMAIL PROTECTED]>
PR mi
2005-11-22 15:39 ---
> This test has changed from XFAIL to XPASS for me on i686-pc-linux-gnu between
> 20051120 (I don't have the exact revision number; the datestamp implies 107240
> or later) and 20051122 (revision 107356). gcc-testresults shows it XPASSing
> in
> various
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-22 18:58 ---
Fixed, thanks for the report.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-22 18:58 ---
Subject: Bug 24988
Author: pinskia
Date: Tue Nov 22 18:58:05 2005
New Revision: 107368
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107368
Log:
2005-11-22 Andrew Pinski <[EMAIL PROTECTED]>
PR ta
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-22 18:44 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|norma
--- Comment #9 from gdr at gcc dot gnu dot org 2005-11-22 18:08 ---
Subject: Bug 22238
Author: gdr
Date: Tue Nov 22 18:08:17 2005
New Revision: 107367
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107367
Log:
PR c++/22238
* error.c (resolve_virtual_fun_from_obj_
--- Comment #20 from pcarlini at suse dot de 2005-11-22 18:00 ---
An observation: while I don't know all the details of current GCC alias
analysis, I'm fairly optimistic that this specific issue with basic_string is
not serious. The reason is that _S_empty_rep_storage, of which we are ta
--- Comment #6 from kazu at gcc dot gnu dot org 2005-11-22 17:42 ---
Andreas,
Thanks for spotting the typo. I also updated the patch to ensure that
we are giving an address register indirect to clr.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19201
--- Comment #8 from gdr at gcc dot gnu dot org 2005-11-22 17:04 ---
Subject: Bug 22238
Author: gdr
Date: Tue Nov 22 17:04:12 2005
New Revision: 107366
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107366
Log:
PR c++/22238
* error.c (resolve_virtual_fun_from_obj_
--- Comment #11 from pinskia at gcc dot gnu dot org 2005-11-22 17:01
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #19 from pcarlini at suse dot de 2005-11-22 16:59 ---
(In reply to comment #18)
> Well, yes. That would at least silence the warning (which would be annoying,
> if we apply the C++ warning patch).
It would be more than annoying, it would be awful, because would be also
emit
--- Comment #10 from hubicka at gcc dot gnu dot org 2005-11-22 16:56
---
Subject: Bug 24653
Author: hubicka
Date: Tue Nov 22 16:56:48 2005
New Revision: 107365
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107365
Log:
PR tree-optimization/24653
* tree-ssa-ccp.c
--- Comment #18 from rguenth at gcc dot gnu dot org 2005-11-22 16:40
---
Well, yes. That would at least silence the warning (which would be annoying,
if we apply the C++ warning patch).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24975
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-22 16:19 ---
Confirmed via:
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01593.html
Anyways this is unrelated to fortran at all.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Ad
--- Comment #17 from pcarlini at suse dot de 2005-11-22 16:14 ---
(In reply to comment #15)
> So that leaves us with basic_string and it's problems. What do you suggest to
> vendors needing ABI compatibility?
Richard, something we *can* safely apply (safely from the ABI point of view)
An attemped build of gfortran from a fresh down load failed with Undefined
symbols
-
rm -rf libbackend.a
ar rc libbackend.a tree-chrec.o tree-scalar-evolution.o tree-data-ref.o
tree-cfg.o tree-dfa.o tree-eh.o tree-ssa.o tree-optimize.o tree-gimple.o
gimplify.o tree-pretty-print.o tree-into-ssa.o
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24951
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24909
--- Comment #4 from jsm28 at gcc dot gnu dot org 2005-11-22 15:39 ---
This test has changed from XFAIL to XPASS for me on i686-pc-linux-gnu between
20051120 (I don't have the exact revision number; the datestamp implies 107240
or later) and 20051122 (revision 107356). gcc-testre
--- Comment #16 from pcarlini at suse dot de 2005-11-22 15:17 ---
(In reply to comment #15)
> So that leaves us with basic_string and it's problems. What do you suggest to
> vendors needing ABI compatibility?
I'm still trying to figure out whether we can do something not breaking the
A
--- Comment #15 from rguenth at gcc dot gnu dot org 2005-11-22 15:09
---
So that leaves us with basic_string and it's problems. What do you suggest to
vendors needing ABI compatibility?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24975
--- Comment #14 from paolo at gcc dot gnu dot org 2005-11-22 14:55 ---
Subject: Bug 24975
Author: paolo
Date: Tue Nov 22 14:55:09 2005
New Revision: 107363
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107363
Log:
2005-11-22 Paolo Carlini <[EMAIL PROTECTED]>
PR libst
--- Comment #13 from paolo at gcc dot gnu dot org 2005-11-22 14:53 ---
Subject: Bug 24975
Author: paolo
Date: Tue Nov 22 14:53:03 2005
New Revision: 107362
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107362
Log:
2005-11-22 Paolo Carlini <[EMAIL PROTECTED]>
PR libst
--- Comment #10 from amodra at gcc dot gnu dot org 2005-11-22 14:24 ---
Subject: Bug 24954
Author: amodra
Date: Tue Nov 22 14:24:42 2005
New Revision: 107360
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107360
Log:
PR target/24954
* config/rs6000/predicates.md
--- Comment #9 from amodra at gcc dot gnu dot org 2005-11-22 14:23 ---
Subject: Bug 24954
Author: amodra
Date: Tue Nov 22 14:23:01 2005
New Revision: 107359
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107359
Log:
PR target/24954
* config/rs6000/predicates.md (
Hi,
I'm using "gcc version 3.4.3 (Mandrakelinux 10.2 3.4.3-7mdk)". (but same
thing occurs on a older version).
I fall into an "invalid covariant return type" during a project
development. I didn't manage to reproduce this error, in a short
example... But, while trying, I fall into a very
--- Comment #8 from amodra at gcc dot gnu dot org 2005-11-22 13:18 ---
Subject: Bug 24950
Author: amodra
Date: Tue Nov 22 13:18:01 2005
New Revision: 107355
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107355
Log:
PR middle-end/24950
* expmed.c (store_bit_field
--- Comment #7 from amodra at gcc dot gnu dot org 2005-11-22 13:16 ---
Subject: Bug 24950
Author: amodra
Date: Tue Nov 22 13:16:29 2005
New Revision: 107354
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107354
Log:
PR middle-end/24950
* expmed.c (store_bit_field
--- Comment #8 from amodra at bigpond dot net dot au 2005-11-22 13:03
---
Fixed trunk and 4,1
--
amodra at bigpond dot net dot au changed:
What|Removed |Added
--- Comment #7 from amodra at gcc dot gnu dot org 2005-11-22 13:01 ---
Subject: Bug 24954
Author: amodra
Date: Tue Nov 22 13:01:40 2005
New Revision: 107353
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107353
Log:
PR target/24954
* config/rs6000/predicated.md (
--- Comment #6 from amodra at gcc dot gnu dot org 2005-11-22 13:00 ---
Subject: Bug 24954
Author: amodra
Date: Tue Nov 22 13:00:06 2005
New Revision: 107352
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107352
Log:
PR target/24954
* config/rs6000/predicated.md (
--- Comment #4 from eedelman at gcc dot gnu dot org 2005-11-22 12:40
---
*** Bug 24966 has been marked as a duplicate of this bug. ***
--
eedelman at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from eedelman at gcc dot gnu dot org 2005-11-22 12:40
---
*** This bug has been marked as a duplicate of 22146 ***
--
eedelman at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from relf at os2 dot ru 2005-11-22 12:10 ---
(In reply to comment #2)
> I don't think this is a bug as what is happening is that :: is a qualified
> name
> and qualified namelookup (IIRC) does not find decls which are injected via
> using.
>
It does find. The following
--- Comment #5 from jakub at gcc dot gnu dot org 2005-11-22 10:58 ---
Subject: Bug 14943
Author: jakub
Date: Tue Nov 22 10:58:47 2005
New Revision: 107351
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107351
Log:
gcc/fortran/
PR fortran/14943
PR fortran/21647
--- Comment #5 from jakub at gcc dot gnu dot org 2005-11-22 10:58 ---
Subject: Bug 24774
Author: jakub
Date: Tue Nov 22 10:58:47 2005
New Revision: 107351
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107351
Log:
gcc/fortran/
PR fortran/14943
PR fortran/21647
--- Comment #7 from jakub at gcc dot gnu dot org 2005-11-22 10:58 ---
Subject: Bug 21647
Author: jakub
Date: Tue Nov 22 10:58:47 2005
New Revision: 107351
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107351
Log:
gcc/fortran/
PR fortran/14943
PR fortran/21647
--- Comment #19 from ebotcazou at gcc dot gnu dot org 2005-11-22 10:44
---
Investigating.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2005-11-22 10:25
---
Investigating again.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #23 from bonzini at gcc dot gnu dot org 2005-11-22 09:21
---
Dale, can you please take care of merging this into 4.2?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19653
--- Comment #4 from gcc at microbizz dot nl 2005-11-22 09:12 ---
Subject: Trampolines fail on i686-apple-darwin because stack is not executable
Clarification - I forgot to mention that the code above (the
ENABLE_EXECUTE_STACK macro) must be added to gcc/config/i386/darwin.h
not to gc
--- Comment #10 from jb at gcc dot gnu dot org 2005-11-22 08:59 ---
With the fix by rth, it seems to work again on Solaris (#9) and Darwin (
http://gcc.gnu.org/ml/fortran/2005-11/msg00571.html ); closing the bug.
--
jb at gcc dot gnu dot org changed:
What|Removed
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2005-11-22 08:24
---
(In reply to comment #6)
> I've change the error message so that it doesn't use the expression "kind"
> where it shouldn't. I also changed the other error message that is a few
> lines
> further down in the same
1 - 100 of 101 matches
Mail list logo
