On 6/16/06, Mike Stump [EMAIL PROTECTED] wrote:
foo() {
int i = 99;
__builtin_setjmp(A)
if (i) {
print i
--i;
__builtin_longjump(A);
}
It used to not infinite loop, now it does.
We had an example just like this on IRC only a few weeks ago. ISTR it
was decided that
Gabriel Dos Reis [EMAIL PROTECTED] writes:
while looking into a recent mismatch between GCC-4.x and a C dialect
EH implemented as setjmp/longjmp, I recalled there was a talk about
extending GNU C with __try/__finally construct:
http://gcc.gnu.org/ml/gcc-patches/2002-11/msg00239.html
Hi,
On Wed, 14 Jun 2006, Joe Buck wrote:
On Wed, Jun 14, 2006 at 11:34:33AM -0700, Mike Stump wrote:
I'd welcome the issue be addressed by the SC. I'd favor more timely
reviews. Maybe auto approval for a patch that sits for more than a
week? :-)
I see your smilie, Mike, but GCC
Richard Kenner wrote:
I haven't had to to do this with the new mechanism for a while, but now I
need to do the equivalent of the old make unstage1 and can't find
any documentation on how to do that (I thought this would be discussed
inside Makefile.tpl).
No, Makefile.tpl only discusses a few
Steven Bosscher wrote:
On 6/16/06, Mike Stump [EMAIL PROTECTED] wrote:
foo() {
int i = 99;
__builtin_setjmp(A)
if (i) {
print i
--i;
__builtin_longjump(A);
}
It used to not infinite loop, now it does.
We had an example just like this on IRC only a few weeks
I actually like the existing behaviour, which I'm pretty sure hasn't
changed for many years. I often find myself typing
Hum, I think I need another patch.
Paolo
Hi,
I'm somewhat stuck with debugging GCC+Boehm's GC bootstrap failure. At
one point cpplib starts producing cpp_string objects with len = 0.
They crash cpp_interpret_string. I'd like to add some assertions to
the code to catch zero-length cpp_strings as early as possible, but I
don't see any
hi,
I'm trying to cross compile gcc-4.1.0 for mipsel
platform.Following is the sequence of commands which i'm using
../gcc-4.1.0/configure --target=mipsel --without-headres
--prefix=/home/shahzad/install/ --with-newlib --enable-languages=c
make
But following error is generated
If you want exactly what make unstage1 did, make stage1-start. There
is also make restrap as in the old scheme.
Thanks.
A side note: I've always been extremely confused by the unstageN and
stageN targets in the gcc directory. The double usage of stage as
noun and verb
Steven Bosscher [EMAIL PROTECTED] writes:
| On 6/16/06, Mike Stump [EMAIL PROTECTED] wrote:
| foo() {
| int i = 99;
| __builtin_setjmp(A)
| if (i) {
| print i
| --i;
| __builtin_longjump(A);
| }
|
| It used to not infinite loop, now it does.
|
|
| We had an
The discussion kind of wandered off, but I'd like to note that I am in
favor of adding __try/__finally as a GNU extension for both C and C++.
It's true, of course, that it's just syntactic sugar which can be
implemented in other ways, but sometimes sugar is sweet.
How would this mesh with a
On 16 June 2006 09:38, Laurynas Biveinis wrote:
Hi,
I'm somewhat stuck with debugging GCC+Boehm's GC bootstrap failure. At
one point cpplib starts producing cpp_string objects with len = 0.
They crash cpp_interpret_string. I'd like to add some assertions to
the code to catch zero-length
On 16 June 2006 02:02, Mike Stump wrote:
Here are just a few more issues I was wondering about for VLAs:
static int i;
static int new_i() { i++; return i; }
static int bar(int a[new_i()][new_i()]);
If that isn't a sequence point violation, it probably ought to be, shouldn't
it?
Eric Botcazou writes:
I actually like the existing behaviour, which I'm pretty sure hasn't
changed for many years.
Eric It has, at least for make quickstrap.
Yes, exactly. Prior to the top-level bootstrap changes, I
explicitly would need to use make CFLAGS=-g to recompile a
Dan == Daniel Berlin [EMAIL PROTECTED] writes:
Dan It can also tell you who to copy on a ping email to make sure it
Dan actually goes to a maintainer.
Dan the interface is under construction, but okay for casual use.
Dan http://www.dberlin.org/patches/patches/maintainer_list/745 would be the
Dan
kernel coder wrote:
hi,
I'm trying to cross compile gcc-4.1.0 for mipsel
platform.Following is the sequence of commands which i'm using
../gcc-4.1.0/configure --target=mipsel --without-headres
--prefix=/home/shahzad/install/ --with-newlib --enable-languages=c
Perhaps you should try to
On 16 June 2006 16:47, David Daney wrote:
kernel coder wrote:
hi,
I'm trying to cross compile gcc-4.1.0 for mipsel
platform.Following is the sequence of commands which i'm using
../gcc-4.1.0/configure --target=mipsel --without-headres
--prefix=/home/shahzad/install/ --with-newlib
The RDHWR instruction is used to support TLS on Linux/MIPS. For now
it is always emulated by kernel (on Reserved Instruction exception
handler), the instruction will be quite expensive.
If I compile this code with gcc 4.1.1 (-O2),
extern __thread int x;
int foo(int arg)
{
if (arg)
On Thu, 15 Jun 2006, Mike Stump wrote:
Here are just a few more issues I was wondering about for VLAs:
static int i;
static int new_i() { i++; return i; }
static int bar(int a[new_i()][new_i()]);
Same as static int bar(int a[*][*]);. (In a definition, the two calls to
new_i() happen in
Ok, good, you gave the same answers I was hoping for. :-)
On Jun 16, 2006, at 10:51 AM, Joseph S. Myers wrote:
But the definition in terms of contained declarators hardly makes
things clear. I would say, however, that while VM-ness shouldn't
propagate out from function argument types to
On Jun 16, 2006, at 6:57 AM, Dave Korn wrote:
static int bar(int a[new_i()][new_i()]);
If that isn't a sequence point violation, it probably ought to be,
shouldn't
it?
No, the text has no meaning (in this case (non (const int))), read it
as `'*' and you'll have a better mental model for
On Jun 16, 2006, at 5:54 AM, Gabriel Dos Reis wrote:
For the bootstrapping problem I mentioned earlier, they added volatile
to variables in the scope but it did not change anything.
For the problem I am thinking of, volatile should go a long way in
working around the compiler bug, assuming
On Jun 16, 2006, at 12:47 AM, Paolo Bonzini wrote:
I think that every variable you do weird things with in C, must
be declared volatile.
The C++/Objective-C/Objective-C++ language standards ensures that you
don't have to mark all variables volatile in the presence of EH.
These builtins
I'm pretty sure this is stepping into deep quicksand, but I'll ask
anyway...I'm interested in writing an FE for a language that has
stackable coroutines (Lua-style, where you can yield and resume
arbitrarily far down the call stack). I'm trying to wrap my head around
what would be involve and how
On Jun 16, 2006, at 1:41 PM, Dustin Laurence wrote:
I'm pretty sure this is stepping into deep quicksand
No, just hard work. It is only quicksand, if you start, but never
finish.
The mechanism I might favor would be to handle all the fun inside the
language front end. Objective-C does
Atsushi Nemoto [EMAIL PROTECTED] writes:
If I compile this code with gcc 4.1.1 (-O2),
extern __thread int x;
int foo(int arg)
{
if (arg)
return x;
return 0;
}
I got this output.
foo:
.frame $sp,0,$31 # vars= 0, regs= 0/0, args= 0,
On 6/16/06, Dustin Laurence [EMAIL PROTECTED] wrote:
I'm pretty sure this is stepping into deep quicksand, but I'll ask
anyway...I'm interested in writing an FE for a language that has
stackable coroutines (Lua-style, where you can yield and resume
arbitrarily far down the call stack). I'm
Snapshot gcc-4.1-20060616 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20060616/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Dustin Laurence [EMAIL PROTECTED] writes:
I'm pretty sure this is stepping into deep quicksand, but I'll ask
anyway...I'm interested in writing an FE for a language that has
stackable coroutines (Lua-style, where you can yield and resume
arbitrarily far down the call stack). I'm trying to
Hi all,
I'd like to catch automatically over/underflows on floating point and
integer arithmetic. I thought -ftrapv would do the trick but I don't
really understand how it works. From the latest manual online:
-ftrapv
This option generates traps for signed overflow on addition,
subtraction,
[Jakub, see below for question.]
There are presently 200 P3 or higher regressions open against 4.2. We
remain in regression-only mode on the mainline.
I have half a mind to see if I can bribe AJH to lock everyone in the
conference hall until they have fixed at least 1 PR. :-)
I'm not sure the
On Jun 16, 2006, at 5:43 PM, Paulo J. Matos wrote:
int main() {
unsigned int maxi = std::numeric_limitsunsigned int::max();
maxi++;
This is well defined as unsigned overflow is defined as wrapping.
-- Pinski
On Fri, Jun 16, 2006 at 02:05:13PM -0700, Mike Stump wrote:
On Jun 16, 2006, at 1:41 PM, Dustin Laurence wrote:
I'm pretty sure this is stepping into deep quicksand
No, just hard work. It is only quicksand, if you start, but never
finish.
It's quicksand if it turns out to vastly exceed
On Fri, Jun 16, 2006 at 05:34:41PM -0500, David Nicol wrote:
On 6/16/06, Dustin Laurence [EMAIL PROTECTED] wrote:
...
is. :-) OTOH if it is possible I'd consider trying to write it, if my
GCC-fu ever reaches the requisite level (my rank is somewhere below
pale piece of pigs ear right now).
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-06-16 06:08
---
Subject: Bug 27689
Author: mmitchel
Date: Fri Jun 16 06:08:49 2006
New Revision: 114703
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114703
Log:
PR c++/27689
* cp-tree.h
--- Comment #7 from mmitchel at gcc dot gnu dot org 2006-06-16 06:09
---
Subject: Bug 27666
Author: mmitchel
Date: Fri Jun 16 06:09:14 2006
New Revision: 114704
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114704
Log:
PR c++/27666
* call.c
--- Comment #8 from mmitchel at gcc dot gnu dot org 2006-06-16 06:10
---
Subject: Bug 27666
Author: mmitchel
Date: Fri Jun 16 06:09:55 2006
New Revision: 114705
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114705
Log:
PR c++/27666
* call.c
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|mark at codesourcery dot com|unassigned at gcc dot gnu
|
--- Comment #6 from mmitchel at gcc dot gnu dot org 2006-06-16 06:25
---
Fixed in 4.2.0.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
-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
-
--
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
--- 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=gccview=revrev=114707
Log:
PR c++/27689
* cp-tree.h
--- 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
--- 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:
=
templateint struct A {};
templateint N
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
--- 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
--- 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=11678action=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
--- 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.
I
--- 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
--- 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 i1073741824);
}
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 this as well),
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
GCC host triplet|solaris-8 x86 |
GCC target triplet|solaris-8 x86 |
--- 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=gccview=revrev=114716
Log:
2006-06-16 Richard Guenther [EMAIL PROTECTED]
PR
--- 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
--- 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 class T
struct B : public T
{
B ();
};
BA *
foo ()
{
return new BA();
}
template class T
BT::B ()
{
}
template
BA::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
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:
--- 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=11679action=view)
Testcase to show codecvt crash
Compile with
g++ -o wide wide.cc
--
--- 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=gccview=revrev=114721
Log:
PR middle-end/27802
* reg-stack.c
--- 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
--- 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:
$
--- 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
--- 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 output
--- 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.
--- 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 at
--- 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
--- 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.
--
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/
--- 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
--- 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=gccview=revrev=114723
Log:
2006-06-16 Richard Guenther [EMAIL PROTECTED]
PR
--- 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
--- 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,
--- 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.
--
[ 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
--- 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=11681action=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.
--- 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 accessed
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
--- 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=11682action=view)
Use mbsnrtowcs directly.
This testcase is similar to the original, with the exception that it uses
mbsnrtowcs in
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.
--
--
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=gccview=revrev=114724
Log:
PR fortran/27965
* trans-array.c
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
1 - 100 of 177 matches
Mail list logo
