[Bug target/29139] GCC produces wrong code with SSE / inline functions
--- Comment #3 from jespdj at hotmail dot com 2006-09-22 06:51 --- I've been looking at my code some more time, and I noticed that there are bugs in it. For example, I'm not using the '' early clobber modifier in the embedded asm, which is necessary if the output operand is modified before the input operands are used. I don't believe it's a bug in GCC after all. Sorry. Please don't use the code I added in the attachments, it has more issues besides what I mentioned above. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29139
[Bug target/29139] GCC produces wrong code with SSE / inline functions
--- Comment #4 from jespdj at hotmail dot com 2006-09-22 06:51 --- Marking this bug as invalid. -- jespdj at hotmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29139
[Bug target/28635] Interaction between different asm statements
--- Comment #6 from Martin dot vGagern at gmx dot net 2006-09-22 07:14 --- Comparing this issue here with bug 28686 I noticed that the code of the functions before the one containing both assembly blocks is completely irrelevant. So even if you only have one empty function in the DO_SINGLE block, enabling that part still makes things compile whereas disabling it causes the described error. So there probably is no interaction between assembly statements in different functions. However inline assembly compiles differently if there is another function preceding the one with the assembly code. An empty function following the one with the asm statement does not have this effect. And there is still some interference between the two asm statements in function both(), as this function containing both of them fails while in the original test case, the function f1() containing only the one where the error is reported, again without preceding function, compiles cleanly. So two asm statements in one function still do interact in some nonintuitive way. (In reply to comment #5) IMHO you should have at least 7 registers available. Some of this is discussed in bug 11807. I'd agree it would be nice to have all registers. But I'd not want this problem report here turn into yet another discussion of which registers should be usable by asm and which not. I'd rather stick to the point, that allocating a given number of registers sometimes works and sometimes does not, for exactly the same asm statement and even the same optimization flags, depending on bizarre outer circumstances like a preceding function or a following second asm statement. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28635
[Bug c/29154] [4.0/4.1/4.2 Regression] *(* ppointer++)++ = *pointer++ generates bad code
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29154
[Bug target/29169] sse3-not-fisttp.c scan-assembler-not fisttp FAILs on i386-pc-solaris2.10
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-22 07:32 --- Fails also on Freebsd is currently a primary target: http://gcc.gnu.org/ml/gcc-testresults/2006-09/msg01174.html -- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|i386-pc-solaris2.10 | GCC host triplet|i386-pc-solaris2.10 | GCC target triplet|i386-pc-solaris2.10 |i386-pc-solaris2.10, i386- ||pc-freebsd http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29169
[Bug other/29176] New: Seg fault in demangler
Testcase:
#include demangle.h
int main(void)
{
cplus_demangle(SASDASDFASDF_sdfsdf, DMGL_PARAMS | DMGL_TYPES | DMGL_AUTO);
}
I cannot figure out how to fix this bug correctly because we are getting some
overflow involved with the integer.
Also I cannot figure out how to get c++filt to reproduce this bug.
--
Summary: Seg fault in demangler
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29176
[Bug libstdc++/27993] Compile error: .libs/complex_io.o: could not read symbols: Bad value
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-22 07:52 --- GNU Ld does not support AIX 5.2 at all because of weak symbol support is not there. Please remove GNU binutils and try again. And yes GCC defaults to picking up things from the --prefix. Also there has been no feedback in 3 months on this bug so closing as invalid. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27993
[Bug c++/29177] New: Wrongly rejects non-template function default arguments in later declarations
8.3.6/4 dcl.fct.default: For non-template functions, default arguments can
be added in later declarations of a function in the same scope.
(there's a detailed example).
gcc 3.4.0 compiled the following code with no problem but release 4.1.1 rejects
it
(with or without the -ansi and -pedantic flags btw), with:
[EMAIL PROTECTED]:~/c++$ g++ -ansi -pedantic x.c
x.c:5: error: default argument missing for parameter 2 of 'int f(int, int)'
x.c:5: error: default argument given for parameter 2 of 'int f(int, int)'
x.c:1: error: after previous specification in 'int f(int, int)'
[EMAIL PROTECTED]:~/c++$ cat x.c
int f (int a, int b = 1)
{
return a + b;
}
int f(int a = 6, int b); // can add default arguments - 8.3.6/4 page 142
[EMAIL PROTECTED]:~/c++$
[EMAIL PROTECTED]:~/c++$ gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /home/sjh/gcc/gcc-4.1.1/configure
--prefix=/home/sjh/gcc/prefix/ --enable-languages=c,c++
Thread model: posix
gcc version 4.1.1
[EMAIL PROTECTED]:~/c++$
--
Summary: Wrongly rejects non-template function default arguments
in later declarations
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: greifel at megatop200 dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29177
[Bug c++/29177] Wrongly rejects non-template function default arguments in later declarations
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-22 08:04 --- *** This bug has been marked as a duplicate of 28274 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29177
[Bug c++/28274] [4.0/4.1/4.2 Regression] Redeclaration with extra default argument doesn't work
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-09-22 08:04 --- *** Bug 29177 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||greifel at megatop200 dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28274
[Bug libgcj/29178] New: CharsetEncoder.canEncode() gives different results than Sun version
The following test program gives different results with gcj and Sun JDK:
// A.java
import java.nio.charset.Charset;
import java.nio.charset.CharsetEncoder;
public class A {
public static void main(String[] args) throws java.io.IOException
{
CharsetEncoder enc = Charset.forName(US-ASCII).newEncoder();
System.out.println(enc.canEncode('\u00e4'));
}
}
// end
$ javac A.java
$ /usr/lib/jvm/java-1.5.0-sun/bin/java A
false
$ /usr/lib/jvm/java-gcj/bin/java A
true
The Sun version seems to return something like (c 31 c 127),
which makes sense, whereas gcj apparently always returns true.
This breaks lots of code, such as Apache JaxMe 2 version 0.51
(specifically the MarshallerTest in the test suite, which generated
invalid XML with gcj).
This was tested on Debian (testing, i386).
~$ gcj --version
gcj (GCC) 4.1.2 20060901 (prerelease) (Debian 4.1.1-13)
The bug was also reported to Debian's bug tracking system:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=388596
--
Summary: CharsetEncoder.canEncode() gives different results than
Sun version
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: marcus at better dot se
GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29178
[Bug tree-optimization/28888] [4.1/4.2 regression] ICE in tree check: expected cond_expr, have label_expr in simplify_using_initial_conditions, at tree-ssa-loop-niter.c
--- Comment #3 from rakdver at gcc dot gnu dot org 2006-09-22 10:03 --- Subject: Bug 2 Author: rakdver Date: Fri Sep 22 10:02:47 2006 New Revision: 117135 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117135 Log: PR tree-optimization/2 * tree-if-conv.c (combine_blocks): Rewritten. * tree-cfg.c (tree_verify_flow_info): Check that edges with EDGE_TRUE/FALSE_VALUE follow COND_EXPR. * gcc.dg/pr2.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr2.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-cfg.c trunk/gcc/tree-if-conv.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
[Bug middle-end/28964] [4.0/4.1/4.2 Regression] partition_stack_vars uses unstable sort
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-09-22 10:09 --- I have a patch. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-09-13 06:21:02 |2006-09-22 10:09:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28964
[Bug c++/29179] New: bugs in mt_allocator
This example will demonstrate 2 problems in mt_allocator.cc:
typedef __gnu_cxx::__mt_allocchar allocator_type;
typedef __gnu_cxx::__pool_base::_Tune tune_type;
allocator_type mt_char;
tune_type t(8, 4, 8, (5 - 4 * sizeof(void*)), 4096, 10, false);
mt_char._M_set_options(t);
allocator_type::pointer pc = mt_char.allocate(4);
First bug in __pool..::_M_initialize():
Binmap_type __bin_max = _M_options._M_min_bin; // not correct.
size_t __bin_max = _M_options._M_min_bin; // correct.
Second bug in __pool..::_M_reserve_block():
while (--__block_count 0) // not correct because __block_count may be equal
0(and size_t is unsigned)
{
__c += __bin_size;
__block-_M_next = reinterpret_cast_Block_record*(__c);
__block = __block-_M_next;
}
while (__block_count 0) // correct
{
__c += __bin_size;
__block-_M_next = reinterpret_cast_Block_record*(__c);
__block = __block-_M_next;
--__block_count;
}
--
Summary: bugs in mt_allocator
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: random at adriver dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29179
[Bug libstdc++/29179] bugs in mt_allocator
--- Comment #1 from pcarlini at suse dot de 2006-09-22 11:19 --- The first bug simply doesn't exist given the comment at the beginning of __pool_base. The second one is at most a documentation issue: _M_chunk_size shall be always much bigger than _M_max_bytes, thus __block_count always 0. -- pcarlini at suse dot de changed: What|Removed |Added Component|c++ |libstdc++ Keywords||documentation http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29179
[Bug middle-end/28964] [4.0/4.1/4.2 Regression] partition_stack_vars uses unstable sort
--- Comment #4 from patchapp at dberlin dot org 2006-09-22 11:25 --- Subject: Bug number PR28964 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-09/msg00976.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28964
[Bug fortran/28600] [4.2 regression] ICE on character pointer assignment
--- Comment #10 from jakub at gcc dot gnu dot org 2006-09-22 11:48 --- Subject: Bug 28600 Author: jakub Date: Fri Sep 22 11:48:18 2006 New Revision: 117137 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117137 Log: 2006-08-09 Paul Thomas [EMAIL PROTECTED] PR fortran/28600 * trans-decl.c (gfc_get_symbol_decl): Ensure that the DECL_CONTEXT of the length of a character dummy is the same as that of the symbol declaration. * gfortran.dg/assumed_charlen_function_4.f90: New test. Added: branches/redhat/gcc-4_1-branch/gcc/testsuite/gfortran.dg/assumed_charlen_function_4.f90 Modified: branches/redhat/gcc-4_1-branch/gcc/fortran/ChangeLog branches/redhat/gcc-4_1-branch/gcc/fortran/trans-decl.c branches/redhat/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28600
[Bug tree-optimization/25737] ACATS c974001 c974013 hang with struct aliasing
--- Comment #36 from dberlin at gcc dot gnu dot org 2006-09-22 12:55 --- Subject: Re: ACATS c974001 c974013 hang with struct aliasing On 21 Sep 2006 16:53:49 -, ebotcazou at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #35 from ebotcazou at gcc dot gnu dot org 2006-09-21 16:53 --- I suspect the reality is there is some fundamental misunderstanding of how aliasing or addressability works on the part of the Ada folks (no offense to them, it's just the arguments they keep offering are, well, strange to anyone who understands aliasing). I suspect that we were simply not on the same page, you being at a general level about aliasing/addressability and I being at the implementation level about DECL_NONADDRESSABLE_P and TYPE_NONALIASED_COMPONENT. No, really, you don't seem to understand. If you respect these DECL_NONADDRESSABLE_P or TYPE_NONALIASED_COMPONENT flags, you are going to make them unaliased. Your whole bug report is that they are not aliased and should be, and that the loads and stores currently don't interfere but should. This is what everyone has told you so far. I've copied Diego, and I expect he will tell you the same thing. Diego, the short summary is that Eric has some Ada testcases where we end up with less V_MAY_DEF's than he thinks should. He believes that respecting these flags, which specify you cannot form the address of a certain component, etc, will somehow cause him to end up with more aliasing and fix his testcase by anything other than luck. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25737
[Bug boehm-gc/29180] New: boehm-gc/darwin_stop_world.c not 64-bit clean
Currently boehm-gc/darwin_stop_world.c generates the compiler warning...
../../../../gcc-4.2-20060920/boehm-gc/darwin_stop_world.c:76: warning: cast to
pointer from integer of different size
The following fix has been discussed on the gcc mailing...
http://gcc.gnu.org/ml/gcc/2006-09/msg00409.html
http://gcc.gnu.org/ml/gcc/2006-09/msg00410.html
http://gcc.gnu.org/ml/gcc/2006-09/msg00413.html
and I am currently testing it. The change does allow
boehm-gc/darwin_stop_world.c to compile without warnings at both -m32 and -m64
on Darwin PPC.
Index: boehm-gc/darwin_stop_world.c
===
--- boehm-gc/darwin_stop_world.c(revision 117142)
+++ boehm-gc/darwin_stop_world.c(working copy)
@@ -61,7 +61,7 @@
unsigned longsavedRTOC;
} StackFrame;
-unsigned long FindTopOfStack(unsigned int stack_start) {
+unsigned long FindTopOfStack(unsigned long stack_start) {
StackFrame *frame;
if (stack_start == 0) {
--
Summary: boehm-gc/darwin_stop_world.c not 64-bit clean
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: boehm-gc
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: howarth at nitro dot med dot uc dot edu
GCC build triplet: powerpc-apple-darwin8
GCC host triplet: powerpc-apple-darwin8
GCC target triplet: powerpc-apple-darwin8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29180
[Bug libstdc++/29179] bugs in mt_allocator
--- Comment #2 from random at adriver dot ru 2006-09-22 13:32 ---
(In reply to comment #1)
The first bug simply doesn't exist given the comment at the beginning of
__pool_base
In the beginning of __pool_base we see:
// Using short int as type for the binmap implies we are never
// caching blocks larger than 65535 with this allocator.
So, it says that I can cache blocks of up to 65535 bytes, while in reality
limit is 32768.
Code below will generate sigfault:
//
int main()
{
typedef __gnu_cxx::__mt_allocchar allocator_type;
typedef __gnu_cxx::__pool_base::_Tune tune_type;
//3.4: typedef __gnu_cxx::__mt_allocchar::_Tune tune_type;
allocator_type mt_char;
tune_type t(8, 5, 8, (20 - 4 * sizeof(void*)), 4096, 10, false);
mt_char._M_set_options(t);
allocator_type::pointer pc = mt_char.allocate(4);
return 0;
}
_Binmap_type* __bp = _M_binmap;
_Binmap_type __bin_max = _M_options._M_min_bin; // not correct since you cast
size_t into u_short
//^^
_Binmap_type __bint = 0;
for (_Binmap_type __ct = 0; __ct = _M_options._M_max_bytes; ++__ct)
{
if (__ct __bin_max)
{
__bin_max = 1;
++__bint;
}
printf(__ct %d __bint %d __bin_max %d\n, __ct, __bint, __bin_max);
*__bp++ = __bint;
}
__ct 32757 __bint 12 __bin_max 32768
__ct 32758 __bint 12 __bin_max 32768
__ct 32759 __bint 12 __bin_max 32768
__ct 32760 __bint 12 __bin_max 32768
__ct 32761 __bint 12 __bin_max 32768
__ct 32762 __bint 12 __bin_max 32768
__ct 32763 __bint 12 __bin_max 32768
__ct 32764 __bint 12 __bin_max 32768
__ct 32765 __bint 12 __bin_max 32768
__ct 32766 __bint 12 __bin_max 32768
__ct 32767 __bint 12 __bin_max 32768
__ct 32768 __bint 12 __bin_max 32768
__ct 32769 __bint 13 __bin_max 0// incorrect values start here
__ct 32770 __bint 14 __bin_max 0
__ct 32771 __bint 15 __bin_max 0
__ct 32772 __bint 16 __bin_max 0
__ct 32773 __bint 17 __bin_max 0
__ct 32774 __bint 18 __bin_max 0
__ct 32775 __bint 19 __bin_max 0
__ct 32776 __bint 20 __bin_max 0
__ct 32777 __bint 21 __bin_max 0
__ct 32778 __bint 22 __bin_max 0
__ct 32779 __bint 22 __bin_max 0
so we have incorrect binmap array.
The second one is at most a documentation issue: _M_chunk_size
shall be always much bigger than _M_max_bytes, thus __block_count always 0.
would it not be easier to do a post increment and not have a problem with
people never reading documentation? especially considering that it's so easy to
fix?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29179
[Bug libffi/29181] New: libffi/src/powerpc/ffi_darwin.c not 64-bit clean
When compiled at -m64 on Darwin PPC, we get the warning... ../../../../gcc-4.2-20060915/libffi/src/powerpc/ffi_darwin.c: In function 'ffi_prep_args': ../../../../gcc-4.2-20060915/libffi/src/powerpc/ffi_darwin.c:117: warning: cast from pointer to integer of different size for the line... *next_arg++ = (unsigned)(char *)ecif-rvalue; It would appear that we should be doing the same thing as in libffi.c... === --- ffi_darwin.c(revision 117142) +++ ffi_darwin.c(working copy) @@ -114,7 +114,7 @@ Return values are referenced by r3, so r4 is the first parameter. */ if (flags FLAG_RETVAL_REFERENCE) -*next_arg++ = (unsigned)(char *)ecif-rvalue; +*next_arg++ = (unsigned long)(char *)ecif-rvalue; /* Now for the arguments. */ for (; I will be testing this fix tonight and seeing if it improves the current level of failures for the libffi testsuite at -m64 on Darwin PPC. -- Summary: libffi/src/powerpc/ffi_darwin.c not 64-bit clean Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libffi AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: howarth at nitro dot med dot uc dot edu GCC build triplet: powerpc-apple-darwin8 GCC host triplet: powerpc-apple-darwin8 GCC target triplet: powerpc-apple-darwin8 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29181
[Bug libstdc++/29179] bugs in mt_allocator
--- Comment #3 from pcarlini at suse dot de 2006-09-22 13:42 --- (In reply to comment #2) would it not be easier to do a post increment and not have a problem with people never reading documentation? especially considering that it's so easy to fix? No, for the simple reason that the allocator does not work is __block_count turns out to be zero. The problem with your PR is that you are doing sort of syntactical analysis of the code without understandind the functioning of the allocator. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29179
[Bug other/29176] Seg fault in demangler
--- Comment #1 from ian at gcc dot gnu dot org 2006-09-22 13:52 --- Subject: Bug 29176 Author: ian Date: Fri Sep 22 13:52:29 2006 New Revision: 117144 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117144 Log: PR other/29176 * cp-demangle.c (d_substitution): Check for overflow when computing substitution index. Modified: trunk/libiberty/ChangeLog trunk/libiberty/cp-demangle.c trunk/libiberty/testsuite/demangle-expected -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29176
[Bug other/29176] Seg fault in demangler
--- Comment #2 from ian at airs dot com 2006-09-22 13:55 --- Fixed on mainline. I haven't tested the 4.1 branch yet. -- ian at airs dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ian at airs dot com |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Known to work||4.2.0 Last reconfirmed|-00-00 00:00:00 |2006-09-22 13:55:30 date|| Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29176
[Bug c++/29182] New: ICE in make_decl_rtl, at varasm.c:890
While building mico-2.3.11 on hppa2.0w-hp-hpux11.11, got this error: $ c++ -I../include -O2 -Wall -g -pthread -D_REENTRANT -DPIC -fPIC -c valuetype_impl.cc -o valuetype_impl.pic.o ../include/mico/valuetype_impl.h: In member function 'void CORBA::DataOutputStream_impl::_ZTv0_n68_N5CORBA21DataOutputStream_impl16write_longdoubleEe(CORBA::LongDouble)': ../include/mico/valuetype_impl.h:44: warning: 'value___2332' is used uninitialized in this function valuetype_impl.cc:638: internal compiler error: in make_decl_rtl, at varasm.c:890 Please submsnip It is independent of at least those compilerflags: -g/-O*/-pthread/-fPIC Strange: If I remove all the #line directions from preprocessor output, the error is different: $ c++ -c valuetype_impl.ii -o valuetype_impl.o valuetype_impl.ii:32: error: redeclaration of C++ built-in type 'wchar_t' valuetype_impl.ii: In static member function 'static wchar_t std::numeric_limitswchar_t::min()': valuetype_impl.ii:6640: warning: left shift count = width of type valuetype_impl.ii: In static member function 'static wchar_t std::numeric_limitswchar_t::max()': valuetype_impl.ii:6642: warning: left shift count = width of type valuetype_impl.ii:49485: confused by earlier errors, bailing out Attached is the preprocessor output, from original command with '-save-temps'. I have it bzip2'ed, as I'm unable to reduce it to a small testcase. Have built gcc with one patch, found here: http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00171.html $ g++ -v Using built-in specs. Target: hppa2.0w-hp-hpux11.11 Configured with: /mnt/toolsjunk/snapshot/src/sasrvb/toolsbox-3.5.1.6pre.20060921/buildroot/gcc/gcc-4.1.1/configure --enable-threads=posix --with-gnu-as --with-as=/tools/snapshot/toolsbox-3.5.1.6pre.20060921/hppa2.0w-hp-hpux11.11/hppa2.0w-hp-hpux11.11/bin/as --without-gnu-ld --with-local-prefix=/tools/snapshot/toolsbox-3.5.1.6pre.20060921/hppa2.0w-hp-hpux11.11 --disable-nls --enable-version-specific-runtime-libs --prefix=/tools/snapshot/toolsbox-3.5.1.6pre.20060921/hppa2.0w-hp-hpux11.11 Thread model: posix gcc version 4.1.1 $ /tools/snapshot/toolsbox-3.5.1.6pre.20060921/hppa2.0w-hp-hpux11.11/hppa2.0w-hp-hpux11.11/bin/as --version GNU assembler 2.16.1 Copyright 2005 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. This assembler was configured for a target of `hppa2.0w-hp-hpux11.11'. -- Summary: ICE in make_decl_rtl, at varasm.c:890 Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: michael dot haubenwallner at salomon dot at GCC build triplet: hppa2.0w-hp-hpux11.11 GCC host triplet: hppa2.0w-hp-hpux11.11 GCC target triplet: hppa2.0w-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29182
[Bug c++/29182] ICE in make_decl_rtl, at varasm.c:890
--- Comment #1 from michael dot haubenwallner at salomon dot at 2006-09-22 13:59 --- Created an attachment (id=12307) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12307action=view) valuetype_impl.ii.bz2 (1.5MB unpacked) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29182
[Bug libffi/29181] libffi/src/powerpc/ffi_darwin.c not 64-bit clean
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2006-09-22 14:27 --- Opps. Looks like the proposed patch is incomplete. http://gcc.gnu.org/ml/gcc/2006-09/msg00428.html I will be testing... Index: ffi_darwin.c === --- ffi_darwin.c(revision 117142) +++ ffi_darwin.c(working copy) @@ -94,7 +94,7 @@ /* 'next_arg' grows up as we put parameters in it. */ - unsigned *next_arg = stack + 6; /* 6 reserved positions. */ + unsigned long *next_arg = stack + 6; /* 6 reserved positions. */ int i = ecif-cif-nargs; double double_tmp; @@ -114,7 +114,7 @@ Return values are referenced by r3, so r4 is the first parameter. */ if (flags FLAG_RETVAL_REFERENCE) -*next_arg++ = (unsigned)(char *)ecif-rvalue; +*next_arg++ = (unsigned long)(char *)ecif-rvalue; /* Now for the arguments. */ for (; ,,,instead. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29181
[Bug libstdc++/29179] bugs in mt_allocator
--- Comment #4 from random at adriver dot ru 2006-09-22 14:40 --- (In reply to comment #3) No, for the simple reason that the allocator does not work is __block_count turns out to be zero. The problem with your PR is that you are doing sort of syntactical analysis of the code without understandind the functioning of the allocator. ok, perhaps this is not really a bug, however segfault is not very user friendly. could ASSERT solve it? about the first one, I take it you agree that it is a real bug? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29179
[Bug c++/29182] ICE when using long double with virtual inheritance and virtual methods
--- Comment #2 from michael dot haubenwallner at salomon dot at 2006-09-22
14:46 ---
was playing around somewhat after posting and indeed found the small testcase:
$ cat aa.cc
class A {
virtual void f(long double);
};
class B : virtual public A
{
void f(long double);
};
void B::f(long double x)
{
}
$ c++ -c aa.cc
aa.cc: In member function 'void B::_ZTv0_n12_N1B1fEe(long double)':
aa.cc:7: internal compiler error: in make_decl_rtl, at varasm.c:890
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
--
michael dot haubenwallner at salomon dot at changed:
What|Removed |Added
Summary|ICE in make_decl_rtl, at|ICE when using long double
|varasm.c:890|with virtual inheritance and
||virtual methods
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29182
[Bug libstdc++/29179] bugs in mt_allocator
--- Comment #5 from pcarlini at suse dot de 2006-09-22 14:48 --- (In reply to comment #4) ok, perhaps this is not really a bug, however segfault is not very user friendly. could ASSERT solve it? No, we don't have asserts anywhere, for various reasons. Really, the documentation must be asjusted and then the user *must* carefully follow it. This piece of code is only for espert usage, not for novices, this should be clear. about the first one, I take it you agree that it is a real bug? Yes, the documentation must be slightly adjusted to 32767. -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-09-22 14:48:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29179
[Bug libstdc++/29118] [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites
--- Comment #10 from dave at hiauly1 dot hia dot nrc dot ca 2006-09-22 14:49 --- Subject: Re: [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites Does hpux use the hppa atomics config, or the generic layer? If it uses the hppa atomics config, why isn't this a problem on hpux? I believe they use the same atomics. I think it points to a pthread issue. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29118
[Bug c/29183] New: cc1: internal compiler error: Segmentation Fault
titan sydev :: EG make -f unix26.mak gcc -g -Wall -D -I . -I ../Common/MemMgmt -I ../Common/StringMgmt -I ../Common/DateTime -I ../Common/FileMgmt -I ../Common/OSWrapper -I ../Common/ProcessMgmt -I ../Common/ErrorLog -I ../Common/SocketBase -I ../Common/MiscMgmt -I ../Common/LinkedList ReqFile.c -c -o Unix/ReqFile.o gcc: .: linker input file unused because linking not done cc1: .: No such file or directory cc1: internal compiler error: Segmentation Fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. make: *** [Unix/ReqFile.o] Error 1 FYI: titan sydev :: EG uname -a SunOS titan 5.7 Generic_106541-34 sun4u sparc SUNW,Ultra-4 I can truss/strace it if necessary, but I'm afraid that I can't provide the source as it is for a proprietry product. -- Summary: cc1: internal compiler error: Segmentation Fault Product: gcc Version: 3.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zaniyah at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29183
[Bug middle-end/26983] [4.0 Regression] Missing label with builtin_setjmp/longjmp
--- Comment #16 from roger at eyesopen dot com 2006-09-22 15:40 --- Fixed everywhere. Eric even has an improved patch/fix for mainline, but the backports of this change are sufficient to resolve the current PR. Thanks to Steven for coming up with the solution. -- roger at eyesopen dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26983
[Bug boehm-gc/29180] boehm-gc/darwin_stop_world.c not 64-bit clean
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-22 15:42 --- An import from upstream for boehm-gc will fix this IIRC. Also I don't think the version that is in the SVN has been ported yet. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29180
[Bug middle-end/28964] [4.0/4.1/4.2 Regression] partition_stack_vars uses unstable sort
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-09-22 15:43 --- Subject: Bug 28964 Author: rguenth Date: Fri Sep 22 15:43:27 2006 New Revision: 117146 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117146 Log: 2006-09-22 Richard Guenther [EMAIL PROTECTED] PR middle-end/28964 * cfgexpand.c (stack_var_size_cmp): Use DECL_UID to make sort of stack variables stable. Modified: trunk/gcc/ChangeLog trunk/gcc/cfgexpand.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28964
[Bug middle-end/28964] [4.0/4.1 Regression] partition_stack_vars uses unstable sort
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-09-22 15:43 --- Fixed on the mainline. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.0/4.1/4.2 Regression]|[4.0/4.1 Regression] |partition_stack_vars uses |partition_stack_vars uses |unstable sort |unstable sort http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28964
[Bug c++/29182] ICE when using long double with virtual inheritance and virtual methods
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-22 15:44 --- *** This bug has been marked as a duplicate of 26957 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29182
[Bug c++/26957] [4.0/4.1 regression] ICE in make_decl_rtl, at varasm.c:871
--- Comment #19 from pinskia at gcc dot gnu dot org 2006-09-22 15:44 --- *** Bug 29182 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||michael dot haubenwallner at ||salomon dot at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26957
[Bug libstdc++/29179] bugs in mt_allocator
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29179
[Bug c/29183] cc1: internal compiler error: Segmentation Fault
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-22 16:08 --- (In reply to comment #0) gcc: .: linker input file unused because linking not done cc1: .: No such file or directory cc1: internal compiler error: Segmentation Fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. This error message does not make sense and your command line that you invoked makes even less sense for the error you gave. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet||sparc-sun-solaris2.7 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29183
[Bug boehm-gc/29180] boehm-gc/darwin_stop_world.c not 64-bit clean
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2006-09-22
16:11 ---
Andrew,
Do you mean from the cvs for bdwgc at
http://www.hpl.hp.com/personal/Hans_Boehm/gc/?
If so the answer is no, since the cvs code there still has...
unsigned long FindTopOfStack(unsigned int stack_start) {
...in darwin_stop_world.c.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29180
[Bug c++/29184] New: member template function of template class can't access some private members
-- Summary: member template function of template class can't access some private members Product: gcc Version: 4.0.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: paul dot otto at canfieldsci dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29184
[Bug target/9539] [Windows] builtin [long/set]jmp not working properly with signals
--- Comment #8 from pascal dot obry at wanadoo dot fr 2006-09-22 16:21 --- Subject: Re: [Windows] builtin [long/set]jmp not working properly with signals dannysmith at users dot sourceforge dot net a écrit : --- Comment #7 from dannysmith at users dot sourceforge dot net 2006-09-20 09:52 --- (In reply to comment #6) I think this is fixed on 4.2: Its still broken on my machine Try after compiling the testcase with optimization turned on. Thanks Danny for the testing, I'm not myself setup to build 4.2 at the moment. Pascal. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9539
[Bug c++/29184] member template function of template class can't access some private members
--- Comment #1 from paul dot otto at canfieldsci dot com 2006-09-22 16:22 --- Created an attachment (id=12308) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12308action=view) Preprocessed file exhibiting the problem The templated member contructor is unable to access the private class members of its const ref argument. Since that argument is an instance of the same class, my understanding is that it should be able to. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29184
[Bug c++/29184] member template function of template class can't access some private members
--- Comment #2 from paul dot otto at canfieldsci dot com 2006-09-22 16:23 --- Created an attachment (id=12309) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12309action=view) output from gcc -v -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29184
[Bug c++/29184] member template function of template class can't access some private members
--- Comment #3 from paul dot otto at canfieldsci dot com 2006-09-22 16:24 --- Created an attachment (id=12310) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12310action=view) copy of the error message from gcc on the example input -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29184
[Bug c++/29184] member template function of template class can't access some private members
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-09-22 16:27 --- No, template classes can only access their own types in that Aint can only access the private variables of Aint and not Afloat. If you want Aint to access Afloat's private variables add to the class: templateclass T2 friend class A; Which says that AT is a friend to AT2. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29184
[Bug middle-end/28690] [4.2 Regression] Performace problem with indexed load/stores on powerpc
--- Comment #12 from bergner at vnet dot ibm dot com 2006-09-22 16:30
---
Anton dicovered that we don't get multiple dimensioned arrays like the
following test case:
int indexedload(int ***base, int idx0, int idx1, int idx2)
{
return base[idx0][idx1][idx2];
}
This one leads to 3 indexed loads. We transform the first indexed load ok, but
the other two we don't. I tracked that down to force_reg (called from
break_out_memory_refs) doesn't propagate the MEM_POINTER flag to a REG_POINTER
flag on the reg it creates. I posted/commited a fix which was approved:
http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00941.html
We now successfully transform all of the indexed loads in this test case now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28690
[Bug middle-end/28790] ICE in initialize_inlined_parameters
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||09/msg00988.html Status|NEW |ASSIGNED Keywords||patch Last reconfirmed|2006-09-03 05:44:34 |2006-09-22 16:34:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28790
[Bug middle-end/25261] [gomp] Nested function calls in #pragma omp parallel blocks
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||09/msg00988.html Status|NEW |ASSIGNED Keywords||patch Last reconfirmed|2006-08-21 12:35:42 |2006-09-22 16:35:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25261
[Bug c++/29185] New: inconsistent warning: deleting array
Gcc 4.1.0 warns about the (ill-fomed?) delete expression on line 5 but fails
to issue a diagnostic for the similar expressions on lines 6 and 7. I would
like to request that it consistently diagnose all such cases.
$ cat t.cpp gcc -c t.cpp
/* 1 */ int a [1];
/* 2 */ struct S { int a [1]; } s;
/* 3 */
/* 4 */ void foo (S *p) {
/* 5 */ delete a;
/* 6 */ delete s.a;
/* 7 */ delete p-a;
/* 8 */ }
t.cpp: In function 'void foo(S*)':
t.cpp:5: warning: deleting array 'int a [1]'
--
Summary: inconsistent warning: deleting array
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
GCC build triplet: all
GCC host triplet: all
GCC target triplet: all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29185
[Bug c++/29185] inconsistent warning: deleting array
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-22 16:43 --- (ill-fomed?) I think it is valid because of how arrays decay to pointers (EDG also accepts the code). Confirmed, we just do the warning for array type decls: /* An array can't have been allocated by new, so complain. */ if (TREE_CODE (exp) == VAR_DECL TREE_CODE (TREE_TYPE (exp)) == ARRAY_TYPE) warning (0, deleting array %q#D, exp); -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |minor Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|all | GCC host triplet|all | GCC target triplet|all | Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2006-09-22 16:43:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29185
[Bug c++/29185] inconsistent warning: deleting array
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|minor |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29185
[Bug debug/29132] [4.1 Regression] Mips exception handling broken.
--- Comment #7 from roger at eyesopen dot com 2006-09-22 16:51 --- Fixed on mainline (confirmed on mips-sgi-irix6.5). It'll take another day or two to backport to the 4.1 branch, as bootstrap and regtest on MIPS takes a while. -- roger at eyesopen dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |roger at eyesopen dot com |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Known to fail|4.1.2 4.2.0 |4.1.2 Known to work|4.1.1 |4.1.1 4.2.0 Last reconfirmed|-00-00 00:00:00 |2006-09-22 16:51:25 date|| Summary|[4.1/4.2 Regression] Mips |[4.1 Regression] Mips |exception handling broken. |exception handling broken. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29132
[Bug libffi/29181] libffi/src/powerpc/ffi_darwin.c not 64-bit clean
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-22 16:51 --- *** This bug has been marked as a duplicate of 29152 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29181
[Bug libffi/29152] 64-bit darwin ppc port needed for libffi
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-22 16:51 --- *** Bug 29181 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29152
[Bug middle-end/28690] [4.2 Regression] Performace problem with indexed load/stores on powerpc
--- Comment #13 from bergner at vnet dot ibm dot com 2006-09-22 16:56
---
Yet another test case from Anton we don't catch. Will they never end?!?! ;)
int indexedload(int *base, int len)
{
int i, sum = 0;
for (i=0; i len; i++)
sum += base[i];
return sum;
}
In this case, LEGITIMIZE_ADDRESS cannot help, because it is never passed an
operand that includes the base pointer. Instead, we're passed a pseudo
register that was set previously to calculation using the base pointer, so in
this case, we can't propagate the REG_POINTER flag.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28690
[Bug c++/16625] Discarded Linkonce sections in .rodata
--- Comment #31 from kai dot engert at gmx dot de 2006-09-22 16:57 --- Just FYI, I attempted to compile Mozilla 1.8 using gcc 3.3.6 on a Fedora Core 5 system. I ran into this bug. The only patch in this bug that applies to 3.3.6 is the patch found in comment 0. With that patch applied to gcc the Mozilla build completed ok. I'm posting this comment using a Mozilla compiled that way. -- kai dot engert at gmx dot de changed: What|Removed |Added CC||kai dot engert at gmx dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16625
[Bug c++/29185] inconsistent warning: deleting array
--- Comment #2 from sebor at roguewave dot com 2006-09-22 16:57 --- Yes, but 5.3.5, p1 says The operand shall have a pointer type, or a class type having a single conversion function (12.3.2) to a pointer type. and not shall be convertible to a pointer type. Note that gcc issues a hard error for a dynamic_cast expression whose argument is an array, so I would expect it to treat the delete expression the same since they both have the same requirement WRT pointers. Btw., I sent an email to EDG to request that they at least warn and to find out whether they think it's well-formed. I'll update the incident with their response. Also note that both IBM XLC++ and HP aCC issue an error for the test case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29185
[Bug middle-end/28690] [4.2 Regression] Performace problem with indexed load/stores on powerpc
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-09-22 17:05 --- (In reply to comment #13) Yet another test case from Anton we don't catch. Will they never end?!?! ;) I bet a beer or a shot of vodka, that this is caused by MEM_REF not expanding with a REG_POINTER. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28690
Re: [Bug middle-end/28690] [4.2 Regression] Performace problem with indexed load/stores on powerpc
On Fri, 2006-09-22 at 17:05 +, pinskia at gcc dot gnu dot org wrote: --- Comment #14 from pinskia at gcc dot gnu dot org 2006-09-22 17:05 --- (In reply to comment #13) Yet another test case from Anton we don't catch. Will they never end?!?! ;) I bet a beer or a shot of vodka, that this is caused by MEM_REF not expanding with a REG_POINTER. And I lost because we have: ;; sum = sum + MEM[base: base, index: (int *) i * 4B] (insn 29 27 30 (set (reg:SI 128) (ashift:SI (reg/v:SI 123 [ i ]) (const_int 2 [0x2]))) -1 (nil) (nil)) (insn 30 29 31 (set (reg:SI 129) (mem:SI (plus:SI (reg:SI 128) (reg/v/f:SI 125 [ base ])) [0 S4 A32])) -1 (nil) (nil)) (insn 31 30 0 (set (reg/v:SI 122 [ sum ]) (plus:SI (reg/v:SI 122 [ sum ]) (reg:SI 129))) -1 (nil) (nil)) -- Pinski
[Bug middle-end/28690] [4.2 Regression] Performace problem with indexed load/stores on powerpc
--- Comment #15 from pinskia at physics dot uc dot edu 2006-09-22 17:09 --- Subject: Re: [4.2 Regression] Performace problem with indexed load/stores on powerpc On Fri, 2006-09-22 at 17:05 +, pinskia at gcc dot gnu dot org wrote: --- Comment #14 from pinskia at gcc dot gnu dot org 2006-09-22 17:05 --- (In reply to comment #13) Yet another test case from Anton we don't catch. Will they never end?!?! ;) I bet a beer or a shot of vodka, that this is caused by MEM_REF not expanding with a REG_POINTER. And I lost because we have: ;; sum = sum + MEM[base: base, index: (int *) i * 4B] (insn 29 27 30 (set (reg:SI 128) (ashift:SI (reg/v:SI 123 [ i ]) (const_int 2 [0x2]))) -1 (nil) (nil)) (insn 30 29 31 (set (reg:SI 129) (mem:SI (plus:SI (reg:SI 128) (reg/v/f:SI 125 [ base ])) [0 S4 A32])) -1 (nil) (nil)) (insn 31 30 0 (set (reg/v:SI 122 [ sum ]) (plus:SI (reg/v:SI 122 [ sum ]) (reg:SI 129))) -1 (nil) (nil)) -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28690
[Bug libgcj/29178] CharsetEncoder.canEncode() gives different results than Sun version
-- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-09-22 17:27:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29178
[Bug middle-end/28690] [4.2 Regression] Performace problem with indexed load/stores on powerpc
--- Comment #16 from sabre at nondot dot org 2006-09-22 17:27 --- Out of curiosity, which powerpc processors are affected by this? -Chris -- sabre at nondot dot org changed: What|Removed |Added CC||sabre at nondot dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28690
[Bug libstdc++/29134] Has there been a serious attempt to define the max_size() member functions?
--- Comment #18 from paolo at gcc dot gnu dot org 2006-09-22 17:51 --- Subject: Bug 29134 Author: paolo Date: Fri Sep 22 17:51:01 2006 New Revision: 117148 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117148 Log: 2006-09-22 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/29134 (vectorbool bits) * include/bits/stl_bvector.h (vectorbool::max_size): Use allocator' max_size. * testsuite/23_containers/vector/bool/capacity/29134.cc: New. * testsuite/23_containers/deque/capacity/29134-2.cc: Minor tweak. * testsuite/23_containers/vector/capacity/29134-2.cc: Likewise. Added: trunk/libstdc++-v3/testsuite/23_containers/vector/bool/capacity/29134.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/stl_bvector.h trunk/libstdc++-v3/testsuite/23_containers/deque/capacity/29134-2.cc trunk/libstdc++-v3/testsuite/23_containers/vector/capacity/29134-2.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29134
[Bug libffi/29152] 64-bit darwin ppc port needed for libffi
--- Comment #2 from andreast at gcc dot gnu dot org 2006-09-22 18:19 --- For the 64-bit Darwin PPC port of libffi you have to follow the 64-bit calling conventions: http://developer.apple.com/documentation/DeveloperTools/Conceptual/LowLevelABI/index.html Also, take a look at src/powerpc/ffi.c on how it is done for linux ppc 32 vs. 64-bit. It does not help to make the 32-bit port compilable with -m64. You need to write the 64-bit part! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29152
[Bug c/29186] New: optimzation breaks floating point exception flag reading
See http://gcc.gnu.org/ml/gcc-help/2006-09/msg00232.html. Disassembling the code suggests that, using gcc-4.1,2, both calls to fetestexcept(3) mysteriously happened before the division when optimization is turned on. This was not the case with earlier versions of gcc, where the calls to fetestexcept(3) bracket the fdivl instruction. -- Summary: optimzation breaks floating point exception flag reading Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kreckel at ginac dot de GCC build triplet: i486-linux-gnu GCC host triplet: i486-linux-gnu GCC target triplet: i486-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29186
[Bug c/29186] optimzation breaks floating point exception flag reading
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-22 19:24 --- This is not really a bug in C99 unless you use: #pragma STDC FENV_ACCESS on But then again we don't implement that pramgma yet -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29186
[Bug c/29186] optimzation breaks floating point exception flag reading
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-22 19:25 --- PR 20785 has a patch but it has not been applied. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||20785 Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29186
[Bug c/29186] optimzation breaks floating point exception flag reading
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-22 19:27 --- So this is not a bug except for the fact GCC does not implement #pragma STDC FENV_ACCESS *** This bug has been marked as a duplicate of 20785 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29186
[Bug c/20785] Pragma STDC * (FP) unimplemented
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-09-22 19:27 --- *** Bug 29186 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||kreckel at ginac dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20785
[Bug c/29154] [4.0/4.1/4.2 Regression] *(* ppointer++)++ = *pointer++ generates bad code
--- Comment #3 from jakub at gcc dot gnu dot org 2006-09-22 20:25 ---
I wonder if we just shouldn't ensure that for postfix exprs post_p statements
of the inner expression are put after, not before the +=/-=.
Something like:
--- gimplify.c.jj2 2006-09-02 08:47:25.0 +0200
+++ gimplify.c 2006-09-22 22:21:29.0 +0200
@@ -1896,7 +1896,7 @@ gimplify_self_mod_expr (tree *expr_p, tr
bool want_value)
{
enum tree_code code;
- tree lhs, lvalue, rhs, t1;
+ tree lhs, lvalue, rhs, t1, post = NULL, *orig_post_p = post_p;
bool postfix;
enum tree_code arith_code;
enum gimplify_status ret;
@@ -1913,6 +1913,9 @@ gimplify_self_mod_expr (tree *expr_p, tr
else
postfix = false;
+ if (postfix)
+post_p = post;
+
/* Add or subtract? */
if (code == PREINCREMENT_EXPR || code == POSTINCREMENT_EXPR)
arith_code = PLUS_EXPR;
@@ -1943,7 +1946,8 @@ gimplify_self_mod_expr (tree *expr_p, tr
if (postfix)
{
- gimplify_and_add (t1, post_p);
+ gimplify_and_add (t1, orig_post_p);
+ append_to_statement_list (post, orig_post_p);
*expr_p = lhs;
return GS_ALL_DONE;
}
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
CC||dnovillo at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29154
[Bug c++/29187] New: Comparison with Pointer to Template Function Requires Explicit Cast
When I try to compile the code below, g++ reports error: assuming cast to type
'bool (*)(evaluator)' from overloaded function on the line indicated. I have
isolated the comparison to the pointer to the template function stop as the
source of the problem. Is this the correct behavior?
#include iostream
struct evaluator { bool (*eval)(evaluator); };
template typename T
bool stop(T e) { return true; }
bool eval(evaluator e) { return true; }
int main() {
typedef bool (*evalf)(evaluator);
struct evaluator e = { stopevaluator };
// error: assuming cast to type 'bool (*)(evaluator)' from
// overloaded function
std::cout (e.eval == stopevaluator) '\n';
// ok--eval is not templated
std::cout (e.eval == eval) '\n';
// ok--explicitly cast to correct type
std::cout (e.eval == static_castevalf(stopevaluator)) '\n';
return 0;
}
I compiled this using the MinGW port of g++ 3.4.2 on W2kSP4. I unfortunately do
not have easy access to g++ 4.1.1, however Kai-Uwe Bux reports the same result
from that version via comp.lang.c++ (discussion archived at
http://groups.google.com/group/comp.lang.c++/browse_frm/thread/b25fee316ec891b6).
--
Summary: Comparison with Pointer to Template Function Requires
Explicit Cast
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: justin dot piper at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29187
[Bug c/29186] optimzation breaks floating point exception flag reading
--- Comment #4 from kreckel at ginac dot de 2006-09-22 22:34 --- (In reply to comment #1) This is not really a bug in C99 unless you use: #pragma STDC FENV_ACCESS on But then again we don't implement that pramgma yet Okay, I was not aware of that pragma. Thank you for pointing it out. But what I find hard to grasp is why it works with previous releases. We have this library call fetestexcept(3) and with gcc 4.1 it basically stopped working. I would say this even qualifies as a regression, right? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29186
[Bug target/13685] Building simple test application with -march=pentium3 -Os gives SIGSEGV (unaligned sse instruction)
--- Comment #24 from jason at gcc dot gnu dot org 2006-09-22 22:42 --- This has been fixed for a while. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13685
[Bug target/13685] Building simple test application with -march=pentium3 -Os gives SIGSEGV (unaligned sse instruction)
--- Comment #25 from vapier at gentoo dot org 2006-09-22 22:54 --- is forcing the alignment to an even larger value really the fix ? is there no way to do such things on the fly ? after all, if someone turns around and tries to do a custom alignment on the stack that is larger than 16 bytes, that will fail (but i guess this issue will be handled at PR28069 ?) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13685
[Bug c++/28996] [4.0/4.1 Regression] ICE with statement forming unused static member function reference
--- Comment #4 from jason at gcc dot gnu dot org 2006-09-22 23:23 --- Subject: Bug 28996 Author: jason Date: Fri Sep 22 23:23:08 2006 New Revision: 117155 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117155 Log: PR c++/28996 * cvt.c (convert_to_void): Strip COMPONENT_REF to functions. Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/cvt.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28996
[Bug c++/28996] [4.0/4.1 Regression] ICE with statement forming unused static member function reference
--- Comment #5 from jason at gcc dot gnu dot org 2006-09-22 23:28 --- Subject: Bug 28996 Author: jason Date: Fri Sep 22 23:28:13 2006 New Revision: 117157 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117157 Log: PR c++/28996 * cvt.c (convert_to_void): Strip COMPONENT_REF to functions. Modified: branches/gcc-4_0-branch/gcc/cp/ChangeLog branches/gcc-4_0-branch/gcc/cp/cvt.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28996
[Bug c++/29187] Comparison with Pointer to Template Function Requires Explicit Cast
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-22 23:33 --- There was a defect report about this problem to the C++ standard. Anyways this is a dup of bug 11407. The C++ standard committee decided this was valid thing to do. *** This bug has been marked as a duplicate of 11407 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29187
[Bug c++/11407] [DR 115] Function cannot be resolved
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-09-22 23:33 --- *** Bug 29187 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||justin dot piper at gmail ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11407
[Bug c++/28996] [4.0/4.1 Regression] ICE with statement forming unused static member function reference
--- Comment #6 from jason at gcc dot gnu dot org 2006-09-22 23:45 --- fixed on branches, too -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28996
[Bug c++/29188] New: accepts-invalid ambiguous between conversion function/constructor. related to const
g++ release 4.1.1 compiles the following invalid code without detecting an
error.
It does correctly find the error with -pedantic. Interestingly (perhaps), it
also correctly detects the ambiguous call where the argument involved is const
- as demonstrated by the second compilation below with the macro C2 defined:
[EMAIL PROTECTED]:~/c++/compiler$ g++ -c conversion.ambig.c
[EMAIL PROTECTED]:~/c++/compiler$ cat conversion.ambig.c
class Source;
class Destination
{
public:
Destination() {}
Destination (const Source source) {}
};
class Source
{
public:
Source() {}
operator Destination() const { return Destination();}
};
Source source;
Destination wolf = source; // ambiguous
#ifdef C2
const Source source2;
Destination wolf2 = source2; // ambiguous
#endif
[EMAIL PROTECTED]:~/c++/compiler$ g++ -D C2 conversion.ambig.c
conversion.ambig.c:22: error: conversion from 'const Source' to 'Destination'
is ambiguous
conversion.ambig.c:14: note: candidates are: Source::operator Destination()
const
conversion.ambig.c:7: note: Destination::Destination(const
Source)
[EMAIL PROTECTED]:~/c++/compiler$
[EMAIL PROTECTED]:~/c++/compiler$
[EMAIL PROTECTED]:~/c++/compiler$ gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /home/sjh/gcc/gcc-4.1.1/configure
--prefix=/home/sjh/gcc/prefix/ --enable-languages=c,c++
Thread model: posix
gcc version 4.1.1
[EMAIL PROTECTED]:~/c++/compiler$
--
Summary: accepts-invalid ambiguous between conversion
function/constructor. related to const
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: greifel at megatop200 dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29188
[Bug c++/29188] undocumented extension with ambiguous between conversion function/constructor. related to const
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-22 23:58 --- I changed the summary since this is undocumented extension and we reject it with -pedantic already, I don't know if this is useful extension or not. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail||2.95.3 3.0.4 4.0.0 4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29188
[Bug libfortran/27964] Wrong line ends on windows (XP)
--- Comment #11 from dannysmith at gcc dot gnu dot org 2006-09-23 01:57 --- Subject: Bug 27964 Author: dannysmith Date: Sat Sep 23 01:56:55 2006 New Revision: 117166 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117166 Log: PR libfortran/27964 * configure.ac: Check for setmode() function. * configure: Regenerate. * config.h.in: Regenerate. * io/unix.c (output_stream): Force stdout to binary mode. (error_stream): Force stderr to binary mode. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/config.h.in trunk/libgfortran/configure trunk/libgfortran/configure.ac trunk/libgfortran/io/unix.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27964
[Bug libfortran/27964] Wrong line ends on windows (XP)
-- dannysmith at users dot sourceforge dot net changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dannysmith at users dot |dot org |sourceforge dot net Status|NEW |ASSIGNED Last reconfirmed|2006-06-08 19:14:51 |2006-09-23 02:00:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27964
[Bug libfortran/27964] Wrong line ends on windows (XP)
--- Comment #12 from dannysmith at users dot sourceforge dot net 2006-09-23 02:00 --- Fixed on trunk -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27964
[Bug c++/29189] New: Error during CPP build of Mozilla
Bug on Mozilla side for Reference https://bugzilla.mozilla.org/show_bug.cgi?id=342472 When trying to build any mozllia program with GCC 4.0 and greater build fails c++ -save-temps -I/usr/X11R7/include -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wno-long-long -pedantic -mcpu=G3 -mtune=G3 -fshort-wchar -pthread -pipe -DNDEBUG -DTRIMMED -mcpu=G3 -mtune=G3 -fno-strict-aliasing -O1 -fPIC -shared -Wl,-h -Wl,libxpcom_compat.so -o libxpcom_compat.so nsFileSpec.o nsFileStream.o nsIFileStream.o nsFileSpecImpl.o nsSpecialSystemDirectory.o -Wl,--whole-archive ../../dist/lib/libmozreg_s.a -Wl,--no-whole-archive -L../../dist/bin -lxpcom -lxpcom_core -L../../dist/bin -L/usr/lib -lplds4 -lplc4 -lnspr4 -lpthread -ldl -ldl -lm c++: warning: -pipe ignored because -save-temps specified nsSpecialSystemDirectory.o: In function `nsSpecialSystemDirectory::Set(nsSpecialSystemDirectory::SystemDirectories, nsFileSpec*)': nsSpecialSystemDirectory.cpp:(.text+0x1d0): undefined reference to `nsHashtable::nsHashtable(unsigned int, int)' nsSpecialSystemDirectory.cpp:(.text+0x204): undefined reference to `nsHashtable::Put(nsHashKey*, void*)' nsSpecialSystemDirectory.cpp:(.text+0x214): undefined reference to `nsHashKey::~nsHashKey()' nsSpecialSystemDirectory.o: In function `nsSpecialSystemDirectory::operator=(nsSpecialSystemDirectory::SystemDirectories)': nsSpecialSystemDirectory.cpp:(.text+0x3d0): undefined reference to `nsHashtable::Get(nsHashKey*)' nsSpecialSystemDirectory.cpp:(.text+0x3fc): undefined reference to `nsHashtable::Get(nsHashKey*)' nsSpecialSystemDirectory.cpp:(.text+0x448): undefined reference to `nsHashtable::Get(nsHashKey*)' nsSpecialSystemDirectory.cpp:(.text+0x474): undefined reference to `nsHashtable::Get(nsHashKey*)' nsSpecialSystemDirectory.cpp:(.text+0x4c0): undefined reference to `nsHashtable::Get(nsHashKey*)' nsSpecialSystemDirectory.cpp:(.text+0x52c): undefined reference to `nsHashKey::~nsHashKey()' nsSpecialSystemDirectory.cpp:(.text+0x538): undefined reference to `nsHashKey::~nsHashKey()' nsSpecialSystemDirectory.o: In function `SystemDirectoriesKey::~SystemDirectoriesKey()': nsSpecialSystemDirectory.cpp:(.text._ZN20SystemDirectoriesKeyD0Ev[SystemDirectoriesKey::~SystemDirectoriesKey()]+0x34): undefined reference to `nsHashKey::~nsHashKey()' nsSpecialSystemDirectory.o: In function `SystemDirectoriesKey::~SystemDirectoriesKey()': nsSpecialSystemDirectory.cpp:(.text._ZN20SystemDirectoriesKeyD1Ev[SystemDirectoriesKey::~SystemDirectoriesKey()]+0x2c): undefined reference to `nsHashKey::~nsHashKey()' collect2: ld returned 1 exit status make[2]: *** [libxpcom_compat.so] Error 1 make[2]: Leaving directory `/usr/src/seamonkey-build/xpcom/obsolete' make[1]: *** [tier_2] Error 2 make[1]: Leaving directory `/usr/src/seamonkey-build' make: *** [default] Error 2 -- Summary: Error during CPP build of Mozilla Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: giffordj at linkline dot com GCC build triplet: powerpc-unknown-linux-gnu GCC host triplet: powerpc-unknown-linux-gnu GCC target triplet: powerpc-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29189
[Bug c++/29189] Error during CPP build of Mozilla
--- Comment #1 from giffordj at linkline dot com 2006-09-23 04:26 --- Created an attachment (id=12311) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12311action=view) All files in Dir with -save-temps -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29189
[Bug c++/29189] Error during CPP build of Mozilla
--- Comment #2 from giffordj at linkline dot com 2006-09-23 04:26 --- Failures only occur on PPC, no other architecture seems to be affected. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29189
[Bug c++/29189] Error during CPP build of Mozilla
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-23 04:33 --- Well the bzip file is messed up, can you reattach it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29189
[Bug c++/29189] Error during CPP build of Mozilla
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29189
[Bug c++/29189] Error during CPP build of Mozilla
--- Comment #4 from giffordj at linkline dot com 2006-09-23 05:44 --- Created an attachment (id=12312) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12312action=view) All files from -save-temp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29189
[Bug c++/29189] Error during CPP build of Mozilla
--- Comment #5 from giffordj at linkline dot com 2006-09-23 05:44 --- If that doesn't work, try http://ftp.jg555.com/obsolete.tar.bz2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29189
[Bug c++/29189] Error during CPP build of Mozilla
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-09-23 05:59 --- I still get: bzip2: Compressed file ends unexpectedly; perhaps it is corrupted? *Possible* reason follows. bzip2: No such file or directory Input file = /tmp/fr-GRhwUv/obsolete.tar-1.bz2, output file = /tmp/fr-GRhwUv/obsolete.tar-1 It is possible that the compressed file(s) have become corrupted. You can use the -tvv option to test integrity of such files. You can use the `bzip2recover' program to attempt to recover data from undamaged sections of corrupted files. bzip2: Deleting output file /tmp/fr-GRhwUv/obsolete.tar-1, if it exists. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29189
[Bug c++/29189] Error during CPP build of Mozilla
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-09-23 05:59 --- (In reply to comment #6) I still get: Even with the link in comment #5. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29189
