-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
cc -c -I../libvo -I../../libvo -I/usr/X11R6/include -fno-PIC -O -pipe
- -funroll-loops -march=pentium3 -fno-force-addr -D_LARGEFILE_SOURCE
- -D_FILE_OFFSET_BITS=64 -I/usr/local/include/freetype2
- -I/usr/local/include -I/usr/X11R6/include/gtk12
- -I/u
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org
--- Comment #7 from mmitchel at gcc dot gnu dot org 2006-06-16 07:15
---
Fixed in 4.1.2.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Stat
--- Comment #8 from mmitchel at gcc dot gnu dot org 2006-06-16 07:15
---
Subject: Bug 27689
Author: mmitchel
Date: Fri Jun 16 07:15:39 2006
New Revision: 114707
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114707
Log:
PR c++/27689
* cp-tree.h (CLASSTYPE_SPECIA
--- Comment #11 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-06-16 08:15 ---
Subject: Re: [4.2 Regression] segfault in fold_convert with -ftree-vectorize
> You said that you had a fix in predcom, is that fix in your local
> tree, or have you sent a patch to gcc-patche
--- Comment #8 from anlauf at gmx dot de 2006-06-16 08:23 ---
(In reply to comment #7)
Paul,
thanks for looking into this!
> program gfortran_bug2
[...]
> integer, parameter :: m(4) = (/1,2,3,4/)
You might wish to extend this to m(5) = ..., because:
> integer, parameter :: p(8)
--- Comment #1 from reichelt at gcc dot gnu dot org 2006-06-16 08:28
---
With Mark's patch for PR 27665 the testcase is now correclty rejected,
but we still ICE with the following one:
=
template struct A {};
template struct B :
The following invalid code is accepted on mainline and 4.1 branch:
===
enum A {};
void foo() { A::bar(); }
===
Mark, this was caused by your patch for PR27665.
Would you mind havin a look?
--
Summary: [4.1/4.2 regression] enum accepted
--- Comment #12 from sebastian dot pop at cri dot ensmp dot fr 2006-06-16
08:55 ---
Subject: Re: [4.2 Regression] segfault in fold_convert with -ftree-vectorize
rakdver at atrey dot karlin dot mff dot cuni dot cz wrote:
> The patch is in predcom branch.
I should have missed this pa
--- Comment #2 from tonyg-gccbugzilla at lshift dot net 2006-06-16 09:07
---
Created an attachment (id=11678)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11678&action=view)
Test case (cleaned for -Wall) from Wolfgang's page
Identical (and still failing) test case to that given
--- Comment #3 from tonyg-gccbugzilla at lshift dot net 2006-06-16 09:07
---
Jun 16 10:07:17 [EMAIL PROTECTED]
~$ gcc -Wall -O0 -o is_small is_small.c
Jun 16 10:07:29 [EMAIL PROTECTED]
~$ ./is_small
0
Jun 16 10:07:32 [EMAIL PROTECTED]
~$ gcc -Wall -O1 -o is_small is_small.c
Jun 16 1
--- Comment #8 from bob at digilink dot net 2006-06-16 09:13 ---
(In reply to comment #6)
> > I fixed this problem. But, as I don't have a Solaris box,
> > I can't test whether this means that the build works.
>
> This report was actually invalid, we don't support /bin/sh on Solaris.
>
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2006-06-16 09:24
---
> My simple question is why not support /bin/sh on Solaris?
Because we're not in the business of working around bugs in antiquated shells.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28024
--- Comment #4 from tonyg-gccbugzilla at lshift dot net 2006-06-16 09:28
---
Even better, if you remove the redundant parens, so that the program reads
...
if ((integerValue >= 0)
&& (integerValue >= -1073741824) && (integerValue < 1073741824)) {
...
then the optimizer g
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-06-16 10:13 ---
Fold simply drops the && (integerValue >= -1073741824) && (integerValue <
1073741824) part. Works if using 2**29 instead of 2**30.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-06-16 10:24 ---
So, we fold
int foo(int i)
{
return i>=0 && (i>=-1073741824 && i<1073741824);
}
into return i>=0. Or more precise, we fold
int foo(int i)
{
return i>=0 && i - -1073741824 >= 0;
}
to return i>=0 (4.2 does thi
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
GCC host triplet|solaris-8 x86 |
GCC target triplet|solaris-8 x86 |
Keywords
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-06-16 10:37 ---
Janis, can you hunt this?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-06-16 10:42 ---
Confirmed:
Program received signal SIGSEGV, Segmentation fault.
0x081c916f in perform_or_defer_access_check (binfo=0x0, decl=0xa7c21af8)
at /home/richard/src/trunk/gcc/cp/semantics.c:315
warning: Source file is
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-06-16 10:47 ---
Otherwise, this is not a regression, so possibly just RESOLVED FIXED with a
target milestone of 4.1.x. Up to the RM of 4.0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28042
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-06-16 12:03
---
Subject: Bug 27830
Author: rguenth
Date: Fri Jun 16 12:03:24 2006
New Revision: 114716
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114716
Log:
2006-06-16 Richard Guenther <[EMAIL PROTECTED]>
--- Comment #11 from rguenth at gcc dot gnu dot org 2006-06-16 12:07
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #2 from gcc dot gnu dot org at chosenones dot dyndns dot org
2006-06-16 12:59 ---
I'm not entirely sure myself, but:
Section 14.6.7
"When looking for the declaration of a name used in a template function
definition or static data member template definition, the usual lookup
struct A {};
template
struct B : public T
{
B ();
};
B *
foo ()
{
return new B();
}
template
B::B ()
{
}
template <>
B::B ()
{
}
ICEs at -O3 i inline_forbidden_p:
1448 FOR_EACH_BB_FN (bb, DECL_STRUCT_FUNCTION (fndecl))
as fndecl (B ctor) doesn't have cfg set (DECL_STRUCT_FUNCTION (f
The attached source file (UTF-8 encoded) demonstrates that codecvt
is broken for the simplest of transformations (UTF-8 to UCS-4).
This is pretty basic, and the underlying gconf stuff works correctly,
so the bug is either in libstdc++6 or somewhere inline in the headers.
$ ./wide
wide: ../iconv/lo
--- Comment #1 from rleigh at debian dot org 2006-06-16 13:09 ---
Created an attachment (id=11679)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11679&action=view)
Testcase to show codecvt crash
Compile with
g++ -o wide wide.cc
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=
--- Comment #2 from sayle at gcc dot gnu dot org 2006-06-16 13:21 ---
Subject: Bug 27802
Author: sayle
Date: Fri Jun 16 13:21:45 2006
New Revision: 114721
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114721
Log:
PR middle-end/27802
* reg-stack.c (subst_stack_r
--- Comment #2 from pcarlini at suse dot de 2006-06-16 13:30 ---
Humm, this is really puzzling because nothing non-trivial changed in that area
going from 3.4 to 4.0 and of course we all run daily the testsuite which
includes quite a few codecvt tests, which always pass smoothly. Could y
--- Comment #3 from rleigh at debian dot org 2006-06-16 13:41 ---
The source is UTF-8 encoded, and it assumes you are going to run it in a UTF-8
locale. That might possibly be why you get odd output.
The expected output should be as per the GCC 3.4 output in the original report:
$ g++
--- Comment #1 from jakub at gcc dot gnu dot org 2006-06-16 13:47 ---
The problem seems to be that cp_cannot_inline_tree_fn changes *fnp to
whatever instantiate_decl returned and that function has not been lowered yet.
Not sure if it is at all possible to cgraph_lower_function from withi
--- Comment #4 from pcarlini at suse dot de 2006-06-16 13:49 ---
(In reply to comment #3)
> The source is UTF-8 encoded, and it assumes you are going to run it in a UTF-8
> locale. That might possibly be why you get odd output.
>
> The expected output should be as per the GCC 3.4 outpu
--- Comment #5 from rleigh at debian dot org 2006-06-16 13:57 ---
$ g++ --version
g++ (GCC) 4.1.2 20060613 (prerelease) (Debian 4.1.1-5)
$ g++ -o wide wide.cc
$ time ./wide
wide: ../iconv/loop.c:425: utf8_internal_loop_single: Assertion `inptr -
bytebuf > (state->__count & 7)' failed.
A
--- Comment #6 from rleigh at debian dot org 2006-06-16 13:59 ---
en_US.UTF-8 doesn't work for me either.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28059
--- Comment #7 from pcarlini at suse dot de 2006-06-16 14:09 ---
(In reply to comment #6)
> en_US.UTF-8 doesn't work for me either.
Nope, I just tried with "en_GB.utf8" too and everything works fine in that case
too. Everything considered I don't think it's likely that libstdc++ can be
--- Comment #8 from pcarlini at suse dot de 2006-06-16 14:13 ---
(In reply to comment #5)
> All that run time is spent in __gconv_transform_utf8_internal, before it blows
> up.
Isn't that a strong hint that something is wrong with the glibc? When you say
3.4 is fine you mean on the very
--- Comment #9 from pcarlini at suse dot de 2006-06-16 14:17 ---
Humm, wait, I'm working on x86-linux! Is that target specific? You can see the
issue only on powerpc?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28059
--- Comment #10 from rleigh at debian dot org 2006-06-16 14:20 ---
Yes, this is all on the same Debian installation. 3.3, 3.4, 4.0, 4.1 and 4.2
(snapshot) are available. All but 3.4 exhibit this problem.
I will test on an i686 system in a moment to check if it's powerpc-only.
--
--- Comment #11 from pcarlini at suse dot de 2006-06-16 14:20 ---
(In reply to comment #9)
> Humm, wait, I'm working on x86-linux! Is that target specific? You can see the
> issue only on powerpc?
Well, in any case all the codecvt regression tests are always fine on powerpc
and powerpc6
--- Comment #12 from rleigh at debian dot org 2006-06-16 14:39 ---
Testing on i486-linux-gnu, the results are:
3.3: fail
3.4: OK
4.0: OK
4.1: OK
4.2 snapshot: OK
So 4.0, 4.1 and 4.2 snapshot are OK on i486-linux-gnu but not on
powerpc-linux-gnu.
--
http://gcc.gnu.org/bugzilla/show
On mainline, when building with no checking enabled, the stage 2
compiler is segfaulting when building crtbegin.o :
make[3]: Entering directory `/build/gcc/out-branchpoint-nc/gcc'
/build/gcc/out-branchpoint-nc/./gcc/xgcc -B/build/gcc/out-branchpoint-nc/./gcc/
-B/install/gcc-nc/i686-pc-linux-gnu/
--- Comment #13 from pcarlini at suse dot de 2006-06-16 14:46 ---
(In reply to comment #12)
> So 4.0, 4.1 and 4.2 snapshot are OK on i486-linux-gnu but not on
> powerpc-linux-gnu.
Ok. In the meanwhile I double checked and in fact **nothing** changed in the
codecvt code going from 3.4 to
--- Comment #5 from tbm at cyrius dot com 2006-06-16 14:46 ---
This also fails with 4.1 from SVN. The problem got introduced between 20060530
and 20060613.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28016
--- Comment #6 from tbm at cyrius dot com 2006-06-16 14:47 ---
(In reply to comment #4)
> boostjam get segfault to build boost with gcc-4.2
I can confirm this, but this is a completely different issue. Unfortunately, I
don't know if this is a bug in boost or gcc, but I suspect the form
--- Comment #22 from rguenth at gcc dot gnu dot org 2006-06-16 14:56
---
Subject: Bug 27116
Author: rguenth
Date: Fri Jun 16 14:56:34 2006
New Revision: 114723
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114723
Log:
2006-06-16 Richard Guenther <[EMAIL PROTECTED]>
--- Comment #23 from rguenth at gcc dot gnu dot org 2006-06-16 14:57
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #14 from pcarlini at suse dot de 2006-06-16 15:09 ---
Can you please tell us the glibc version? I'm asking because I can reproduce on
an ia64 machine using glibc2.4, not on all the glibc2.3.6 systems I tried.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28059
--- Comment #7 from tbm at cyrius dot com 2006-06-16 15:11 ---
This was caused by this commit:
2006-06-04 Mark Mitchell <[EMAIL PROTECTED]>
PR c++/27819
* decl.c (cp_finish_decl): Process initializers for static data
members with non-dependent initializers, ev
--- Comment #13 from gerald at pfeifer dot com 2006-06-16 15:25 ---
Thanks, Paolo!
I got confirmation by two testers who experienced the original problem that
your latest patch addresses the issue, and they managed to bootstrap now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26
[ forwarded from http://bugs.debian.org/373820 ]
We're seeing the following ICE, both with gcc 4.1 and latest 4.2 (but 4.0
works). Apparently it only happens on x86_64. It works when you drop the
optimization flag.
(sid)75:[EMAIL PROTECTED]: ~/delta/bin] /usr/lib/gcc-snapshot/bin/gcc -c -O2
mi
--- Comment #1 from tbm at cyrius dot com 2006-06-16 15:51 ---
Created an attachment (id=11681)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11681&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28062
--- Comment #15 from rleigh at debian dot org 2006-06-16 16:16 ---
$ uname -a
Linux hardknott 2.6.16.17 #7 Sun May 21 15:39:23 BST 2006 ppc GNU/Linux
$ /lib/libc.so.6
GNU C Library stable release version 2.3.6, by Roland McGrath et al.
Copyright (C) 2005 Free Software Foundation, Inc.
T
--- Comment #9 from paulthomas2 at wanadoo dot fr 2006-06-16 16:18 ---
Subject: Re: rejects valid array initialization expression
Harald,
>You might wish to extend this to m(5) = ..., because:
>
>
>
>> integer, parameter :: p(8) = (/(m(i:i+1), i = 1,4)/)
>>
>>
>
>the last acce
On Fri, 2006-06-16 at 10:45 -0400, Andrew MacLeod wrote:
> On mainline, when building with no checking enabled, the stage 2
> compiler is segfaulting when building crtbegin.o :
>
>
> make[3]: Entering directory `/build/gcc/out-branchpoint-nc/gcc'
> /build/gcc/out-branchpoint-nc/./gcc/xgcc
> -B/b
--- Comment #2 from sje at cup dot hp dot com 2006-06-16 16:44 ---
Changing the C to a ! would probably work but the point is that a C should
work. Or C should be documented as not working.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28032
--- Comment #16 from pcarlini at suse dot de 2006-06-16 16:56 ---
I can reproduce on an ia64-linux machine, so confirmed, but very puzzling on
the libstdc++-v3 side, no idea how/when we are going to deal with it...
--
pcarlini at suse dot de changed:
What|Removed
--- Comment #17 from rleigh at debian dot org 2006-06-16 16:59 ---
Created an attachment (id=11682)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11682&action=view)
Use mbsnrtowcs directly.
This testcase is similar to the original, with the exception that it uses
mbsnrtowcs in pla
The patch in revision 113012 broke reference counting. It adds this:
+ /* Set the string's refcount to 0 so that prune_unused_types_mark
+accounts properly for it. */
+ if (AT_class (a) == dw_val_class_str)
+ a->dw_attr_val.v.val_str->refcount = 0;
But something in this
--- Comment #18 from pcarlini at suse dot de 2006-06-16 17:03 ---
Ok, thanks. Before I go completely crazy, let's agree at least about a detail:
let's not involve 3.3: in 3.3 codecvt is known to be broken and was completely
rewritten for 3.4.
--
http://gcc.gnu.org/bugzilla/show_bug.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org |
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-06-16 17:03
---
Subject: Bug 27965
Author: fxcoudert
Date: Fri Jun 16 17:03:43 2006
New Revision: 114724
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114724
Log:
PR fortran/27965
* trans-array.c (gfc_co
String merging is conditionalized on -fmerge-constants, which is turned off for
-O0. This is wasteful of space in .debug_info with optimization disabled, on
targets which support string merging. I don't know if it's faster or not; in
the long run, I suspect it's slower, because binaries get so mu
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|pcarlini at suse dot de |unassigned at gcc dot gnu
||do
--- Comment #1 from reichelt at gcc dot gnu dot org 2006-06-16 17:11
---
Testing a patch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Assigne
--- Comment #19 from rleigh at debian dot org 2006-06-16 17:26 ---
Created an attachment (id=11683)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11683&action=view)
C example using mbsnrtowcs
This testcase is the same as the last, but uses C only.
It looks like this:
GCC ver
--- Comment #20 from rleigh at debian dot org 2006-06-16 17:28 ---
> Before I go completely crazy, let's agree at least about a detail:
> let's not involve 3.3: in 3.3 codecvt is known to be broken and was
> completely rewritten for 3.4.
Agreed :)
--
http://gcc.gnu.org/bugzilla/sho
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-06-16 17:43 ---
(In reply to comment #1)
> Looks invalid, as I think default arguments need to be bound immediately(?)
No they don't, if they did then all of STL with allocators would be broken :).
--
pinskia at gcc dot gnu dot
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |minor
Target Milestone|--- |4.1.2
http://
--
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
Severity|normal |minor
Target Milestone|--- |4.0.4
http://
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |minor
Target Milestone|--- |4.2.0
http://
--
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=28053
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |minor
Target Milestone|--- |4.2.0
http://
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-16 17:50 ---
*** This bug has been marked as a duplicate of 27781 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-06-16 17:50 ---
*** Bug 28055 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from ro at gcc dot gnu dot org 2006-06-16 17:53 ---
Subject: Bug 27540
Author: ro
Date: Fri Jun 16 17:53:03 2006
New Revision: 114726
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114726
Log:
PR target/27540
* configure.in: Only enable libgomp on
--
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=28056
--- Comment #5 from ro at gcc dot gnu dot org 2006-06-16 17:53 ---
Fixed for 4.2.0.
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-06-16 17:55 ---
This is a dup of another bug which I fixed for 4.1.0 so closing as fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|tree-optimization |c++
Target Milestone|--- |4.1.2
http://gc
--
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.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28063
--- Comment #21 from pcarlini at suse dot de 2006-06-16 18:10 ---
Ok, I think I have something meaningful to say: seems definitely a
miscompilation. I would ask you to check on powerpc-linux what I'm seeing on
ia64-linux: the problem goes away if I both build libstdc++ and eventually the
--- Comment #22 from rleigh at debian dot org 2006-06-16 18:19 ---
Just to summarise the current tests:
wide wide2 wide3
GCC ver ppc i386 ppc i386 ppc i386
3.4OK OKOK OKOK fail
4.0fail OKOK fail OK fail
4.1fail OKO
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.1.2 4.2.0
Summary|[4.2 Regression] emitting |[4.1/4.2
I ran into a problem using Boost C++ (CVS HEAD 2006-06-16) with gcc 4.2.0
20060610 (and newer). Basically, filenames are not longer encoded in
the mangled name of certain symbols (possibly related to anonymous
namespaces?),
though they should be. Since the issue did not occur with gcc
4.2.0 2006060
--- Comment #7 from mmitchel at gcc dot gnu dot org 2006-06-16 18:46
---
Subject: Bug 27884
Author: mmitchel
Date: Fri Jun 16 18:45:50 2006
New Revision: 114727
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114727
Log:
PR c++/27884
* decl.c (have_extern_spec):
--- Comment #8 from mmitchel at gcc dot gnu dot org 2006-06-16 18:53
---
Fixed in 4.2.0.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Summa
--- Comment #10 from janis at gcc dot gnu dot org 2006-06-16 18:59 ---
The regression hunt to find when the testcase starts passing identified this
mainline patch:
http://gcc.gnu.org/viewcvs?view=rev&rev=106400
r106400 | rth | 2005-11-02 21:44:17 + (Wed, 02 Nov 2005)
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-16 19:01 ---
No, this is different problem than you think it is. The problem is we are
emitting a constant that does not make sense at all.
*** This bug has been marked as a duplicate of 28016 ***
--
pinskia at gcc dot gnu
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-06-16 19:01 ---
*** Bug 28065 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2006-06-16 19:31
---
I'm currently regtesting the following patch:
Index: trans-intrinsic.c
===
--- trans-intrinsic.c (revision 114721)
+++ trans-intrinsic.c (workin
--- Comment #15 from tkoenig at gcc dot gnu dot org 2006-06-16 19:47
---
(In reply to comment #14)
> Thomas, could you backport your patch to 4.1? (when you have some time, of
> course)
Hi FX,
I have a few major RL concerns next week (a few critical presentations to
give, ...) and wil
--- Comment #6 from leisner at rochester dot rr dot com 2006-06-16 20:03
---
It seems the specs file for solaris is also wrong -- I had to add -lrt to
enable
pthreads (on solaris 2.8 anyway and gcc 3.4.x).
--
leisner at rochester dot rr dot com changed:
What|Removed
I do not think this is bug 5291 from the Most Frequently Reported Bugs page
HOST SYSTEM: HP ProLiant DL385G1 with Dual Opteron 254 running RedHat
Enterprise v4u3
KERNEL: 2.6.9-34.ELsmp
COMPILER USED TO BOOTSTRAP (this is bundled with RHELv4u3):
$ gcc --version
gcc (GCC) 3.4.5 20051201 (Red Hat 3
--- Comment #4 from janis at gcc dot gnu dot org 2006-06-16 21:12 ---
A regression hunt confirmed that this was fixed by:
http://gcc.gnu.org/viewcvs?view=rev&rev=114119
r114119 | mmitchel | 2006-05-25 20:18:26 + (Thu, 25 May 2006)
--
http://gcc.gnu.org/bugzilla/show_bu
--- Comment #3 from tromey at gcc dot gnu dot org 2006-06-16 21:22 ---
I don't think we'll ever fix this.
GCC's -o option is probably sufficient.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-16 21:27 ---
/usr/bin/ld: BFD 2.15.92.0.2 20040927 internal error, aborting at
../../bfd/elf64-x86-64.c line 1912 in elf64_x86_64_relocate_section
But this is a binutils bug and not a GCC one and it has been fixed too.
--
pi
All gcj bugs fixed on the ecj branch will be listed
as dependencies of this bug.
--
Summary: [meta-bug] Tracking bug for ecj fixes
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ja
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot
|dot org
1 - 100 of 141 matches
Mail list logo
