[Bug classpath/27262] org.w3c.dom.Document.getElementById returns null after manual (setIdAttribute) identifying of element in Document instance.
--- Comment #2 from mark at gcc dot gnu dot org 2006-04-23 08:19 --- Can you take a look at this bug report chris? -- mark at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dog at gnu dot org |dot org | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27262
[Bug c/27266] New: syncronization primitives cause ICE with -march=pentium or better
Mainline is ICE'ing on testsuite/gcc.c-torture/compile/sync-1.c for some arguments to -march. For example: ./xgcc -B. -O2 /mnt/sysfs/rask/cvssrc/gcc/gcc/testsuite/gcc.c-torture/compile/sync-1.c -S -o /tmp/sync-1.s -march=pentium /mnt/sysfs/rask/cvssrc/gcc/gcc/testsuite/gcc.c-torture/compile/sync-1.c: In function 'test_lock': /mnt/sysfs/rask/cvssrc/gcc/gcc/testsuite/gcc.c-torture/compile/sync-1.c:261: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. It works with: i386, i486, winchip-c6, winchip2 and c3. It fails with: pentium, pentium-mmx, pentiumpro, pentium2, pentium3, pentium4, nocona, prescott, k6, k6-2, k6-3, k8, athlon, opteron and c3-2. The gcc-4.1.0-3 compiler shipped by Red Hat fails in the same way for the same arguments to -march. -- Summary: syncronization primitives cause ICE with -march=pentium or better Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rask at sygehus dot dk GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27266
[Bug java/8923] [4.0/4.1/4.2 Regression] ICE when modifying a variable decleared "final static"
--- Comment #6 from debian-gcc at lists dot debian dot org 2006-04-23
11:00 ---
test case from http://bugs.debian.org/351512
class gcjbug {
public static void main (String [] p) {
System.out.println(1++);
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8923
[Bug c/27267] New: Problems with creal in gcc 4.0.0 and 4.0.1
Dear all:
The command
creal(cpow(1.+I,I))
using complex arithmetic produces the double 0.
Presently, I have no other explanation for this
as assuming that this is a result of a bug in gcc
4.0.0 on Mac OSX, XCode.
I have now downloaded the version gcc 4.0.1,
and suddenly, the real part is no longer 0. It
could be that this bug has been fixed.
But now, the call of creal such as
printf("\n %f",creal(cpow(I,I)));
produces segmentation faults, and
printf("\n %f %f", creal(zz),creal(zz));
for a complex number zz the values
0.00 nan
Why nan, and why two different values for the same
thing? Is there a systematic problem with creal in
particular and the complex type in general?
All the best, Jens
--
Summary: Problems with creal in gcc 4.0.0 and 4.0.1
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jense at ic dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27267
[Bug libgcj/27268] New: gij could give a warning on senseless code
[forwarded from http://bugs.debian.org/340651]
$ gij test
Segmentation fault
$ cat test.java
public class test
{
public test()
{
test t = new test();
}
public static void main(String argv[])
{
new test();
}
}
while the blackdown runtime prints
Exception in thread "main" java.lang.StackOverflowError
at test.(test.java)
at test.(test.java:5)
at test.(test.java:5)
at test.(test.java:5)
[...]
and loops forever.
--
Summary: gij could give a warning on senseless code
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: debian-gcc at lists dot debian dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27268
[Bug tree-optimization/27236] [4.1/4.2 Regression] inliner creates an INDIRECT_REF without TREE_THIS_VOLATILE set for *a
--- Comment #5 from patchapp at dberlin dot org 2006-04-23 11:25 --- Subject: Bug number PR27236 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-04/msg00871.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27236
[Bug tree-optimization/27218] [4.1/4.2 regression] ICE in get_indirect_ref_operands, at tree-ssa-operands.c:1515, inlining produces non-gimple
--- Comment #9 from patchapp at dberlin dot org 2006-04-23 11:25 --- Subject: Bug number PR27218 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-04/msg00872.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27218
[Bug fortran/27269] New: Segfault with EQUIVALENCEs in modules together with ONLY clauses
[EMAIL PROTECTED]:~/src/work/bug> cat t.f90 module const ! Kind parameters integer, parameter :: dp = kind(1d0) double precision reimMUE(2), reMUE, imMUE equivalence (MUE, reimMUE) equivalence (reimMUE(1), reMUE), (reimMUE(2), imMUE) end module const module cross_section use const, only: dp end module cross_section use const use cross_section implicit none end program [EMAIL PROTECTED]:~/src/work/bug> ~/src/gcc/build/gcc/f951 t.f90 t.f90:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. [EMAIL PROTECTED]:~/src/work/bug> ~/src/gcc/build/gcc/f951 --version GNU F95 version 4.2.0 20060421 (experimental) (i686-pc-linux-gnu) compiled by GNU C version 4.2.0 20060421 (experimental). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 [EMAIL PROTECTED]:~/src/work/bug> gdb ~/src/gcc/build/gcc/f951 GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run t.f90 Starting program: /home/pcl331/schluter/src/gcc/build/gcc/f951 t.f90 Program received signal SIGSEGV, Segmentation fault. 0x0808dc3d in resolve_types (ns=0x870d288) at ../../gcc/fortran/resolve.c:5829 5829 last_ts = &eq->expr->symtree->n.sym->ts; (gdb) bt #0 0x0808dc3d in resolve_types (ns=0x870d288) at ../../gcc/fortran/resolve.c:5829 #1 0x080902bc in gfc_resolve (ns=0x870d288) at ../../gcc/fortran/resolve.c:6252 #2 0x08086059 in gfc_parse_file () at ../../gcc/fortran/parse.c:3179 #3 0x080a64dd in gfc_be_parse_file (set_yydebug=0) at ../../gcc/fortran/f95-lang.c:301 #4 0x08391fea in toplev_main (argc=2, argv=0xb984) at ../../gcc/toplev.c:999 #5 0x080d867f in main (argc=Cannot access memory at address 0x1 ) at ../../gcc/main.c:35 (gdb) p eq->expr->symtree $2 = (gfc_symtree *) 0x0 (gdb) For the bug to trigger both the direct and the indirect use as well as the ONLY clause are necessary. Note that the actual code location is in resolve_equivalence, so the bug is probably due to gfortran trying to understand an equivalence whose member variables have not been loaded, due to the ONLY clause. -- Summary: Segfault with EQUIVALENCEs in modules together with ONLY clauses Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobi at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27269
[Bug fortran/27269] Segfault with EQUIVALENCEs in modules together with ONLY clauses
--- Comment #1 from tobi at gcc dot gnu dot org 2006-04-23 11:45 --- Since I still have it on my screen: (gdb) p eq->expr->where->nextc-18 $6 = 0x8708de9 " use cross_section" -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27269
[Bug c/27267] Problems with creal in gcc 4.0.0 and 4.0.1
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-23 11:51 --- Please read the bug-reporting instructions and provide a preprocessed testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27267
[Bug fortran/25099] Conformance of arguments to ELEMENTAL subroutines
--- Comment #5 from pault at gcc dot gnu dot org 2006-04-23 11:56 --- Subject: Bug 25099 Author: pault Date: Sun Apr 23 11:56:37 2006 New Revision: 113194 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113194 Log: 2006-04-23 Paul Thomas <[EMAIL PROTECTED]> PR fortran/25099 * resolve.c (resolve_call): Check conformity of elemental subroutine actual arguments. 2006-04-23 Paul Thomas <[EMAIL PROTECTED]> PR fortran/25099 * gfortran.dg/elemental_subroutine_4.f90: New test. * gfortran.dg/assumed_size_refs_1.f90: Add error to non-conforming call sub (m, x). Added: trunk/gcc/testsuite/gfortran.dg/elemental_subroutine_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/assumed_size_refs_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25099
[Bug c/27266] syncronization primitives cause ICE with -march=pentium or better
--- Comment #1 from rask at sygehus dot dk 2006-04-23 14:46 --- Created an attachment (id=11317) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11317&action=view) Preprocessed source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27266
[Bug c++/27270] New: ICE in process_init_constructor_array, at cp/typeck2.c:788
with a recent gcc snapshot on i386:
c++ (GCC) 4.2.0 20060325 (experimental)
the following tst program program:
template
struct Array {
Entry *array[32];
Array () :
array ( (Entry*[1]) { 0, 0 } )
{}
};
Array a;
compiled with:
c++ -Wall arrayinit.cc
produces:
arrayinit.cc: In constructor 'Array::Array() [with Entry = void*]':
arrayinit.cc:8: instantiated from here
arrayinit.cc:5: internal compiler error: in process_init_constructor_array, at
cp/typeck2.c:788
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
--
Summary: ICE in process_init_constructor_array, at
cp/typeck2.c:788
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: timj at gtk dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27270
[Bug libstdc++/27199] ptrdiff_t and size_t outside of namespace std
--- Comment #2 from paolo at gcc dot gnu dot org 2006-04-23 14:54 --- Subject: Bug 27199 Author: paolo Date: Sun Apr 23 14:54:26 2006 New Revision: 113195 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113195 Log: 2006-04-23 Marc Glisse <[EMAIL PROTECTED]> PR libstdc++/27199 * ext/pool_allocator.h: Add using declarations for size_t, ptrdiff_t. * ext/bitmap_allocator.h: Likewise; qualify with std::. * ext/new_allocator.h: Likewise. * ext/malloc_allocator.h: Likewise. * ext/array_allocator.h: Likewise. * ext/mt_allocator.h: Likewise. * ext/functional: Likewise for size_t. * ext/debug_allocator.h: Likewise. * bits/char_traits.h: Qualify with std:: size_t. * debug/hash_multimap.h: Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/char_traits.h trunk/libstdc++-v3/include/debug/hash_multimap.h trunk/libstdc++-v3/include/ext/array_allocator.h trunk/libstdc++-v3/include/ext/bitmap_allocator.h trunk/libstdc++-v3/include/ext/debug_allocator.h trunk/libstdc++-v3/include/ext/functional trunk/libstdc++-v3/include/ext/malloc_allocator.h trunk/libstdc++-v3/include/ext/mt_allocator.h trunk/libstdc++-v3/include/ext/new_allocator.h trunk/libstdc++-v3/include/ext/pool_allocator.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27199
[Bug libstdc++/27199] ptrdiff_t and size_t outside of namespace std
--- Comment #3 from pcarlini at suse dot de 2006-04-23 14:55 --- Fixed. -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27199
[Bug c++/27270] [4.1/4.2 Regression]ICE in process_init_constructor_array, at cp/typeck2.c:788
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-23 15:47 --- Confirmed. We hit #1 0x080b0ffc in digest_init (type=, init=0xb7da6ed0) at /space/rguenther/src/svn/gcc/gcc/cp/typeck2.c:788 788 gcc_assert (VEC_length (constructor_elt, v) <= len); Also happens on the 4.1 branch. 4.0.3 tells us y.c: In constructor 'Array::Array() [with Entry = void*]': y.c:8: instantiated from here y.c:5: error: excess elements in aggregate initializer y.c:5: error: conversion from 'void** [1]' to non-scalar type 'void** [32]' requested -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-invalid-code Known to fail||4.1.0 4.2.0 Known to work||4.0.3 Last reconfirmed|-00-00 00:00:00 |2006-04-23 15:47:41 date|| Summary|ICE in |[4.1/4.2 Regression]ICE in |process_init_constructor_arr|process_init_constructor_arr |ay, at cp/typeck2.c:788 |ay, at cp/typeck2.c:788 Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27270
[Bug c/27267] Problems with creal in gcc 4.0.0 and 4.0.1
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-23 16:00 --- Also check with the C standard to what this is supposed to return. If you are not including complex.h and stdio.h, then this code is invalid, please use -Wall -W before posting the preprocessed source. Also you should report this to Apple first since you are using their compiler and not the FSF's GCC. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27267
[Bug target/27266] [4.2 Regression] syncronization primitives cause ICE with -march=pentium or better
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-23 16:09 --- Note Redhat's 4.1.0 is closer to 4.2.0 than 4.1.0. Anyways confirmed a regression in that it worked in 4.1.0. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Known to fail||4.2.0 Known to work||4.1.0 Last reconfirmed|-00-00 00:00:00 |2006-04-23 16:09:17 date|| Summary|syncronization primitives |[4.2 Regression] |cause ICE with -|syncronization primitives |march=pentium or better |cause ICE with - ||march=pentium or better Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27266
[Bug target/27266] [4.2 Regression] syncronization primitives cause ICE with -march=pentium or better
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-23 16:10 --- Also here is the backtrace: #0 split_di (operands=0xc0c768, num=0, lo_half=0x7f89ab58, hi_half=0x7f89ab48) at /home/pinskia/src/newtest/trunk/gcc/config/i386/i386.c:8037 #1 0x007ff0eb in ix86_expand_branch (code=, label=0x2ae037d0) at /home/pinskia/src/newtest/trunk/gcc/config/i386/i386.c:10196 #2 0x006c0ec6 in gen_bne (operand0=0x2ae037d0) at i386.md:12951 #3 0x00725a1b in expand_compare_and_swap_loop (mem=0x2afb3d20, old_reg=0x2afb3d40, new_reg=0x2afb3f60, seq=) at /home/pinskia/src/newtest/trunk/gcc/optabs.c:5960 #4 0x0072bfdc in expand_sync_operation (mem=0x2afb3d20, val=, code=AND) at /home/pinskia/src/newtest/trunk/gcc/optabs.c:6048 #5 0x00533587 in expand_builtin (exp=0x2ae03410, target=0xafafafafafafafaf, subtarget=0x0, mode=12633960, ignore=13) at /home/pinskia/src/newtest/trunk/gcc/builtins.c:6279 #6 0x005c37ae in expand_expr_real_1 (exp=, target=, tmode=, modifier=EXPAND_NORMAL, alt_rtl=0x0) at /home/pinskia/src/newtest/trunk/gcc/expr.c:7584 This proves this is a target specific bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27266
[Bug libgcj/27268] gij could give a warning on senseless code
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-23 16:16 --- *** This bug has been marked as a duplicate of 1373 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27268
[Bug libgcj/1373] recursion stress test causes segmentation fault
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-04-23 16:16 --- *** Bug 27268 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||debian-gcc at lists dot ||debian dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1373
[Bug libgcj/1373] recursion stress test causes segmentation fault
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-04-23 16:18
---
A better testcase comes from PR 27268 which seg faults at all optimizations
level currently (though this case can also be optimized out to be an infinite
loop really):
public class test
{
public test()
{
test t = new test();
}
public static void main(String argv[])
{
new test();
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1373
[Bug libgcj/27271] New: i/o error (java.util.zip.ZipException: Deflated stream ends early.)
The following code fails to run with the gij-4.1 runtime (4.1 branch 20060421),
works ok with the blackdown runtime (example distilled from FC's azureus-themed
patch by Stephan Michels).
$ cat TestLoadImage.java
import java.io.InputStream;
import org.eclipse.swt.graphics.Image;
import org.eclipse.swt.widgets.Display;
public class TestLoadImage {
public static void main(String[] args) {
final Display display = new Display();
InputStream is = TestLoadImage.class.getResourceAsStream("new.gif");
System.out.println("is="+is);
Image im = new Image(display, is);
System.out.println("im="+im);
}
}
$ gij -Djava.library.path=/usr/lib/jni -cp
/usr/lib/java/swt3.1-gtk.jar:test.jar TestLoadImage
[EMAIL PROTECTED]
Exception in thread "main" org.eclipse.swt.SWTException: i/o error
(java.util.zip.ZipException: Deflated stream ends early.)
at org.eclipse.swt.SWT.error(SWT.java:2942)
at org.eclipse.swt.SWT.error(SWT.java:2866)
at
org.eclipse.swt.internal.image.GIFFileFormat.readID(GIFFileFormat.java:138)
at
org.eclipse.swt.internal.image.GIFFileFormat.getExtensions(GIFFileFormat.java:150)
at
org.eclipse.swt.internal.image.GIFFileFormat.loadFromByteStream(GIFFileFormat.java:124)
at
org.eclipse.swt.internal.image.FileFormat.loadFromStream(FileFormat.java:47)
at org.eclipse.swt.internal.image.FileFormat.load(FileFormat.java:75)
at org.eclipse.swt.graphics.ImageLoader.load(ImageLoader.java:126)
at org.eclipse.swt.graphics.ImageDataLoader.load(ImageDataLoader.java:18)
at org.eclipse.swt.graphics.ImageData.(ImageData.java:327)
at org.eclipse.swt.graphics.Image.(Image.java:490)
at TestLoadImage.main(TestLoadImage.java:11)
Caused by: java.util.zip.ZipException: Deflated stream ends early.
at java.util.zip.InflaterInputStream.fill(InflaterInputStream.java:156)
at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:195)
at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:169)
at java.io.FilterInputStream.read(FilterInputStream.java:155)
at java.util.jar.JarFile$EntryInputStream.read(JarFile.java:974)
at
org.eclipse.swt.internal.image.LEDataInputStream.read(LEDataInputStream.java:76)
at
org.eclipse.swt.internal.image.GIFFileFormat.readID(GIFFileFormat.java:134)
...9 more
--
Summary: i/o error (java.util.zip.ZipException: Deflated stream
ends early.)
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: doko at ubuntu dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27271
[Bug libgcj/27271] i/o error (java.util.zip.ZipException: Deflated stream ends early.)
--- Comment #1 from doko at ubuntu dot com 2006-04-23 16:31 --- Created an attachment (id=11318) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11318&action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27271
[Bug c/27272] New: Strange order of components of multidimensional array pointer with the same cast
char *yn;
yn = (char *) malloc (sizeof (char) * x * y);
First subroutine included with {}:
char (*pointer)[x][y] = (char (*)[x][y]) yn;
&((*pointer)[0][0]) is 0x8052100
&((*pointer)[0][1]) is 0x8052107
Second routine independent function passed as pointer yn as parameter;
char (*pointer)[x][y] = (char (*)[x][y]) yn;
In second routine the pointers only is the same if (x) y replaced with (y) and
(y) with (x)
&((*pointer)[0][0]) with pointer 0x8052100
&((*pointer)[1][0]) with pointer 0x8052107
--
Summary: Strange order of components of multidimensional array
pointer with the same cast
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: prog1 at yobinario dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27272
[Bug target/16641] fr30-elf-gcc compiler error when building newlib-1.12.0
--- Comment #5 from sayle at gcc dot gnu dot org 2006-04-23 17:25 --- Subject: Bug 16641 Author: sayle Date: Sun Apr 23 17:25:30 2006 New Revision: 113196 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113196 Log: PR target/16641 * config/fr30/fr30.h (GO_IF_LEGITIMATE_ADDRESS): Check REGNO for STACK_POINTER_RTX and FRAME_POINTER_RTX instead of comparing the rtx to stack_pointer_rtx or frame_pointer_rtx directly. Modified: trunk/gcc/ChangeLog trunk/gcc/config/fr30/fr30.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16641
[Bug target/21283] [4.0/4.1/4.2 regression] ICE with doubles
--- Comment #3 from sayle at gcc dot gnu dot org 2006-04-23 17:44 --- Subject: Bug 21283 Author: sayle Date: Sun Apr 23 17:44:46 2006 New Revision: 113198 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113198 Log: PR target/21283 * config/fr30/fr30.md (define_split): Avoid calling gen_lowpart on a SImode SUBREG of a floating point register after no_new_pseudos. Modified: trunk/gcc/ChangeLog trunk/gcc/config/fr30/fr30.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21283
[Bug middle-end/27272] Strange order of components of multidimensional array pointer with the same cast
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-23 17:46 --- Can you provide a self contained example which actually compiles? As right now I (and others) can only guess at what the problem is. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27272
[Bug tree-optimization/20517] bit shift/mask optimization potential
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-23 18:01 --- For PowerPC, either way is implemented the same in that it uses the same two instructions (though with different operands). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20517
[Bug c++/26534] [4.1/4.2 Regression] bitfield wrong optimize
--- Comment #7 from mmitchel at gcc dot gnu dot org 2006-04-23 18:04 --- Subject: Bug 26534 Author: mmitchel Date: Sun Apr 23 18:04:33 2006 New Revision: 113199 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113199 Log: 2006-04-23 Mark Mitchell <[EMAIL PROTECTED]> PR c++/26534 * c-common.h (c_build_bitfield_integer_type): Declare. * c-decl.c (c_build_bitfield_integer_type): Move to ... * c-common.c (c_build_bitfield_integer_type): ... here. 2006-04-23 Mark Mitchell <[EMAIL PROTECTED]> PR c++/26534 * cp-tree.h (is_bitfield_expr_with_lowered_type): New function. * typeck.c (is_bitfield_expr_with_lowered_type): New function. (decay_conversion): Convert bitfield expressions to the correct type. (build_modify_expr): Remove spurious conversions. * class.c (layout_class_type): Modify the type of bitfields to indicate a limited range. * call.c (standard_conversion): Adjust the type of bitfield expressions used in an rvalue context. (build_conditional_expr): Likewise. 2006-04-23 Mark Mitchell <[EMAIL PROTECTED]> PR c++/26534 * g++.dg/opt/bitfield1.C: New test. * g++.dg/compat/abi/bitfield1_main.C: Add -w. * g++.dg/compat/abi/bitfield1_x.C: Likewise. * g++.dg/compat/abi/bitfield1_y.C: Likewise. * g++.dg/compat/abi/bitfield2_main.C: Likewise. * g++.dg/compat/abi/bitfield2_x.C: Likewise. * g++.dg/compat/abi/bitfield2_y.C: Likewise. * g++.dg/abi/bitfield1.C: Add dg-warning markers. * g++.dg/abi/bitfield2.C: Likewise. * g++.dg/init/bitfield1.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/opt/bitfield1.C Modified: trunk/gcc/ChangeLog trunk/gcc/c-common.c trunk/gcc/c-common.h trunk/gcc/c-decl.c trunk/gcc/configure trunk/gcc/configure.ac trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/class.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/typeck.c trunk/gcc/print-tree.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/abi/bitfield1.C trunk/gcc/testsuite/g++.dg/abi/bitfield2.C trunk/gcc/testsuite/g++.dg/compat/abi/bitfield1_main.C trunk/gcc/testsuite/g++.dg/compat/abi/bitfield1_x.C trunk/gcc/testsuite/g++.dg/compat/abi/bitfield1_y.C trunk/gcc/testsuite/g++.dg/compat/abi/bitfield2_main.C trunk/gcc/testsuite/g++.dg/compat/abi/bitfield2_x.C trunk/gcc/testsuite/g++.dg/compat/abi/bitfield2_y.C trunk/gcc/testsuite/g++.dg/init/bitfield1.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26534
[Bug c++/26534] [4.1] bitfield wrong optimize
--- Comment #8 from mmitchel at gcc dot gnu dot org 2006-04-23 18:05 --- Fixed in GCC 4.2. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.1/4.2 Regression]|[4.1] bitfield wrong |bitfield wrong optimize |optimize http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26534
[Bug c++/26757] [4.1/4.2 regression] C++ front-end producing two DECLs with the same UID
--- Comment #16 from mmitchel at gcc dot gnu dot org 2006-04-23 18:14
---
The correct fix for this issue is for the C++ front-end to save and restore
information about a declaration as scopes are entered and exited.
For example, given:
extern void f(int);
void g() {
extern void f(int = 7);
f();
}
void h() {
extern void f(int = 3);
f();
}
we should use a single FUNCTION_DECL (and a single DECL_UID), add the default
argument when the declaration is encountered in g, and then remove the default
argument when we exit that scope. This example shows why you can't just keep
calling duplicate_decls; you can actually change the values of the default
arguments in different scopes, and, in scopes with no default argument
declared, the user must supply all arguments.
Default arguments are only part of the problem; the same issue applies to
things like:
extern int a[];
void f() {
extern int a[10];
}
It will not be particularly entertaining to fix this in the C++ front-end,
though it is indeed something that should be done. It's probably doable for
4.2, but I'd think it to be a very risk change for 4.1.
Is there a work-around in the middle end that can be applied on the 4.1 branch?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26757
[Bug c++/26912] [4.0/4.1/4.2 Regression] friend const member function specialization fails to compile
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26912
[Bug c++/27235] goto crossing P.O.D. initialization
--- Comment #7 from falk at debian dot org 2006-04-23 19:05 --- I think this is a valid request. While random language extensions aren't useful, compatibility with C99 is. Maybe somebody else can comment on this... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27235
[Bug c/27273] New: tree check fail for legal code
I just tried to compile Linux kernel version 2.6.16.9 with a recent GNU C compiler version 4.2 snapshot 20060422. The compiler snapshot said /home/dcb/gnu/42-20060422/results/bin/gcc -g -O3 -Wall -Wp,-MD,drivers/char/.synclink_gt.o.d -nostdinc -isystem /home/dcb/gnu/42-20060422/results/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/include -D__KERNEL__ -Iinclude -include include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -ffreestanding -Os -fno-omit-frame-pointer -fno-optimize-sibling-calls -g -march=k8 -m64 -mno-red-zone -mcmodel=kernel -pipe -fno-reorder-blocks -Wno-sign-compare -fno-asynchronous-unwind-tables -funit-at-a-time -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -Wdeclaration-after-statement -Wno-pointer-sign -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(synclink_gt)" -D"KBUILD_MODNAME=KBUILD_STR(synclink_gt)" -c -o drivers/char/.tmp_synclink_gt.o drivers/char/synclink_gt.c drivers/char/synclink_gt.c: In function 'rx_async': drivers/char/synclink_gt.c:1774: internal compiler error: tree check: expected class 'constant', have 'binary' (bit_and_expr) in convert_and_check, at c-common.c:1083 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make[2]: *** [drivers/char/synclink_gt.o] Error 1 Preprocessed source code attached. No special flags required. -- Summary: tree check fail for legal code Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dcb314 at hotmail dot com GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27273
[Bug c/27273] tree check fail for legal code
--- Comment #1 from dcb314 at hotmail dot com 2006-04-23 19:12 --- Created an attachment (id=11319) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11319&action=view) C source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27273
[Bug c/27273] [4.2 regression] tree check fail for legal code
--- Comment #2 from falk at debian dot org 2006-04-23 19:34 ---
Confirmed. Test case:
unsigned char rx_async(unsigned char p) {
return p & 512;
}
--
falk at debian dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||ice-on-valid-code
Known to fail||4.2.0
Known to work||4.0.3 4.1.0
Summary|tree check fail for legal |[4.2 regression] tree check
|code|fail for legal code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27273
[Bug c++/12625] bitfields which have sizes that are powers of 8 missed by -Wparentheses
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-04-23 20:05 --- Fixed by: 2006-04-23 Mark Mitchell <[EMAIL PROTECTED]> PR c++/26534 * cp-tree.h (is_bitfield_expr_with_lowered_type): New function. * typeck.c (is_bitfield_expr_with_lowered_type): New function. (decay_conversion): Convert bitfield expressions to the correct type. (build_modify_expr): Remove spurious conversions. * class.c (layout_class_type): Modify the type of bitfields to indicate a limited range. * call.c (standard_conversion): Adjust the type of bitfield expressions used in an rvalue context. (build_conditional_expr): Likewise. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12625
[Bug c/27273] [4.2 regression] tree check fail for legal code when convert returns a constant from an expression that was not constant
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org GCC host triplet|i686-pc-linux-gnu | Summary|[4.2 regression] tree check |[4.2 regression] tree check |fail for legal code |fail for legal code when ||convert returns a constant ||from an expression that was ||not constant Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27273
[Bug middle-end/27272] Strange order of components of multidimensional array pointer with the same cast
--- Comment #2 from prog1 at yobinario dot com 2006-04-23 20:20 --- Created an attachment (id=11320) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11320&action=view) test_code OUTPUT: ./gcc_test Printing matrix... 0x804a008 MATRIX [0][0] = [1] with pointer 0x804a008 MATRIX [0][1] = [2] with pointer 0x804a00f MATRIX [0][2] = [3] with pointer 0x804a016 MATRIX [0][3] = [4] with pointer 0x804a01d MATRIX [0][4] = [5] with pointer 0x804a024 MATRIX [0][5] = [6] with pointer 0x804a02b MATRIX [0][6] = [7] with pointer 0x804a032 create call... MATRIX [0][0]=[1] with pointer 0x804a008 MATRIX [0][1]=[0] with pointer 0x804a009 MATRIX [0][2]=[0] with pointer 0x804a00a MATRIX [0][3]=[0] with pointer 0x804a00b MATRIX [0][4]=[0] with pointer 0x804a00c MATRIX [0][5]=[0] with pointer 0x804a00d MATRIX [0][6]=[0] with pointer 0x804a00e Inverse order MATRIX [0][0]=[1] with pointer 0x804a008 MATRIX [1][0]=[2] with pointer 0x804a00f MATRIX [2][0]=[3] with pointer 0x804a016 MATRIX [3][0]=[4] with pointer 0x804a01d MATRIX [4][0]=[5] with pointer 0x804a024 MATRIX [5][0]=[6] with pointer 0x804a02b MATRIX [6][0]=[7] with pointer 0x804a032 OK -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27272
[Bug c++/27235] goto crossing P.O.D. initialization
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-04-23 20:21 ---
(In reply to comment #7)
> I think this is a valid request. While random language extensions aren't
> useful,
> compatibility with C99 is. Maybe somebody else can comment on this...
There are a lot of differences between C and C++, this is just one of the
differences. Another would be where the variable is done inside a for/if
expression in that:
int g(void);
int f(void)
{
if (int t = g())
{
int t = g()+1;
}
}
is valid C but invalid C++ (though GCC gets it wrong for C++ but that is an
already filed bug report).
PR 27252 (aka PR 9278) is another example where C and C++ diff and in fact was
just fixed for 4.2.0 for a bug report. These are just some examples of where C
and C++ differ.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27235
[Bug c++/16376] Bit-field promotions
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-23 20:24 --- I just checked and this was fixed by: 2006-04-23 Mark Mitchell <[EMAIL PROTECTED]> PR c++/26534 * cp-tree.h (is_bitfield_expr_with_lowered_type): New function. * typeck.c (is_bitfield_expr_with_lowered_type): New function. (decay_conversion): Convert bitfield expressions to the correct type. (build_modify_expr): Remove spurious conversions. * class.c (layout_class_type): Modify the type of bitfields to indicate a limited range. * call.c (standard_conversion): Adjust the type of bitfield expressions used in an rvalue context. (build_conditional_expr): Likewise. In that we now get: ui3 promoted to int (value preserving) -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16376
[Bug c++/27235] goto crossing P.O.D. initialization
--- Comment #9 from acahalan at gmail dot com 2006-04-23 20:39 --- Regarding Comment #8: Of course I do not want g++ to be a perfect superset of gcc. That is unreasonable, because it would break legitimate standards-conforming C++ code. I only ask that C compatibility be provided for code that would otherwise fail to compile as C++. This makes code reuse much easier. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27235
[Bug middle-end/27272] Strange order of components of multidimensional array pointer with the same cast
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-23 20:49 --- *(pointer_yn)[0][6] is different from: (*pointer_yn)[0][6] In fact the first one is equivalant to: pointer_yn[0][6][0] While the second one is equivalant to: pointer_yn[0][0][6] so you are running into different ordering of array references. -- 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=27272
[Bug c++/27235] goto crossing P.O.D. initialization
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-04-23 20:53 --- (In reply to comment #9) > I only ask that C compatibility be provided for code that would otherwise fail > to compile as C++. This makes code reuse much easier. I showed two other examples which are (were) reproted saying GCC accepted invalid C++ (and the code was valid C and people actually used the second case already in patricte which is why I pointed it out). So if you want to modify the C++ front-end and to make an option, that is fine but GCC should (and does have) a pratice of not accepting new extensions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27235
[Bug target/16641] fr30-elf-gcc compiler error when building newlib-1.12.0
--- Comment #6 from roger at eyesopen dot com 2006-04-23 21:19 --- This should now be fixed on mainline. I've confirmed that a cross-compiler to fr30-elf currently builds newlib without problems. -- roger at eyesopen dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16641
[Bug target/21283] [4.0/4.1 regression] ICE with doubles
--- Comment #4 from roger at eyesopen dot com 2006-04-23 21:27 --- This has now been fixed on mainline. I've confirmed that a cross-compiler to fr30-elf can currently compile all of newlib without problems. If anyone has an fr30 board or a simulator to check the testsuite that would be great. -- roger at eyesopen dot com changed: What|Removed |Added Summary|[4.0/4.1/4.2 regression] ICE|[4.0/4.1 regression] ICE |with doubles|with doubles Target Milestone|4.1.1 |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21283
[Bug testsuite/27274] New: execution test of gcc.dg/i386-sse-9.c fails on non-SSE CPU
There is no check for SSE support in this test. -- Summary: execution test of gcc.dg/i386-sse-9.c fails on non-SSE CPU Product: gcc Version: 4.0.3 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: braichuk at tut dot by GCC host triplet: i586-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27274
[Bug c++/16376] Bit-field promotions
--- Comment #3 from mmitchel at gcc dot gnu dot org 2006-04-23 22:13 --- I agree that the C++ standard requires the behavior suggested by Joseph in Comment #1. However, my patch was not intended to fix this bug, and only does so by accident. In particular, the last lines of decay_conversion convert the expression to the TYPE_MAIN_VARIANT of the limited-precision type, rather than to the TYPE_MAIN_VARIANT of the declared type of the bitfield, as I had intended, although the original conversion from limited-precision type to declared type is present in the expression by this point. I am not sure if that original conversion is actually required, given that the testsuite is passing with the code in its current state. In earlier forms of the patch, it was definitely required; otherwise, for example, bitfields of enumeration type did not have the correct type elsewhere in the compiler. It may be that because of the changes I made to the conversion machinery in call.c, this is no longer a problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16376
[Bug c++/16376] Bit-field promotions
--- Comment #4 from joseph at codesourcery dot com 2006-04-23 22:22 ---
Subject: Re: Bit-field promotions
On Sun, 23 Apr 2006, mmitchel at gcc dot gnu dot org wrote:
> However, my patch was not intended to fix this bug, and only does so by
> accident. In particular, the last lines of decay_conversion convert the
> expression to the TYPE_MAIN_VARIANT of the limited-precision type, rather than
> to the TYPE_MAIN_VARIANT of the declared type of the bitfield, as I had
> intended, although the original conversion from limited-precision type to
> declared type is present in the expression by this point.
>
> I am not sure if that original conversion is actually required, given that the
> testsuite is passing with the code in its current state. In earlier forms of
> the patch, it was definitely required; otherwise, for example, bitfields of
> enumeration type did not have the correct type elsewhere in the compiler. It
> may be that because of the changes I made to the conversion machinery in
> call.c, this is no longer a problem.
The sort of case where you need to convert to the declared type is
#include
struct S {
unsigned long a : 33, b : 33;
} s = { 1UL << 32, 1UL << 32 };
int
main(void)
{
if (s.a + s.b != (1UL << 33))
abort();
}
(supposing 32-bit int, 64-bit long). But given that C++ doesn't define
LANG_HOOKS_REDUCE_BIT_FIELD_OPERATIONS, even if the addition is done on
the reduced types that might not reliably cause the test to fail.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16376
[Bug tree-optimization/26304] [4.2 Regression] 25_algorithms/prev_permutation/1.cc on powerpc{64,}-linux and powerpc-darwin
--- Comment #17 from pinskia at gcc dot gnu dot org 2006-04-23 23:14 --- Rewritting that loop like: [kudzu:local/trunk/gcc] pinskia% svn diff tree-ssa-loop-niter.c Index: tree-ssa-loop-niter.c === --- tree-ssa-loop-niter.c (revision 113199) +++ tree-ssa-loop-niter.c (working copy) @@ -1939,6 +1939,7 @@ scev_probably_wraps_p (tree type, tree b tree unsigned_type, valid_niter; tree base_plus_step, bpsps; int cps, cpsps; + bool known_not_to_wrap; /* FIXME: The following code will not be used anymore once http://gcc.gnu.org/ml/gcc-patches/2005-06/msg02025.html is @@ -2077,8 +2078,10 @@ scev_probably_wraps_p (tree type, tree b estimate_numbers_of_iterations_loop (loop); for (bound = loop->bounds; bound; bound = bound->next) -if (proved_non_wrapping_p (at_stmt, bound, type, valid_niter)) - return false; +if (!proved_non_wrapping_p (at_stmt, bound, type, valid_niter)) + known_not_to_wrap = false; + if (known_not_to_wrap) + return false; /* At this point we still don't have a proof that the iv does not overflow: give up. */ Makes it work, Now I am not going to say this is the "correct" fix or not. What I am going to say, this is the most logical fix in that we know one iv can not overflow does not mean all will not. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||spop at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26304
[Bug tree-optimization/26304] [4.2 Regression] 25_algorithms/prev_permutation/1.cc on powerpc{64,}-linux and powerpc-darwin
--- Comment #18 from pinskia at gcc dot gnu dot org 2006-04-23 23:15 --- Oh, I did not test the patch at all except on the testcase I gave in comment #7. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26304
[Bug target/27275] New: treelang test failures for biarch build
GCC configured with --enable-targets=powerpc-linux,powerpc64-linux
--with-cpu=default32 fails the treelang tests, when run with
RUNTESTFLAGS="--target_board=unix\{,-m64\}"
Matthias
Running target unix/-m64
FAIL: treelang/compile/badreturn.tree (test for errors, line 13)
FAIL: treelang/compile/badreturn.tree (test for excess errors)
FAIL: treelang/compile/exit.tree (test for excess errors)
FAIL: treelang/compile/extrafunc.tree (test for warnings, line 14)
FAIL: treelang/compile/extrafunc.tree (test for excess errors)
FAIL: treelang/compile/extravar.tree (test for warnings, line 5)
FAIL: treelang/compile/extravar.tree (test for excess errors)
FAIL: treelang/compile/extref.tree (test for excess errors)
FAIL: treelang/compile/full_unit.tree (test for excess errors)
ERROR: treelang/compile/full_unit.tree: error executing dg-final: couldn't open
"full_unit.s": no such file or directory
UNRESOLVED: treelang/compile/full_unit.tree: error executing dg-final: couldn't
open "full_unit.s": no such file or directory
FAIL: treelang/compile/function-1.tree (test for excess errors)
FAIL: treelang/compile/memory.tree (test for excess errors)
FAIL: treelang/compile/tabs.tree (test for excess errors)
FAIL: treelang/compile/unsigned.tree (test for excess errors)
FAIL: treelang/compile/var_defs.tree (test for warnings, line 17)
FAIL: treelang/compile/var_defs.tree (test for warnings, line 22)
FAIL: treelang/compile/var_defs.tree (test for excess errors)
FAIL: treelang/execute/funccall-2.tree (test for excess errors)
WARNING: treelang/execute/funccall-2.tree compilation failed to produce
executable
FAIL: treelang/execute/funccall.tree (test for excess errors)
WARNING: treelang/execute/funccall.tree compilation failed to produce
executableFAIL: treelang/execute/initial.tree (test for excess errors)
WARNING: treelang/execute/initial.tree compilation failed to produce executable
FAIL: treelang/execute/main.tree (test for excess errors)
WARNING: treelang/execute/main.tree compilation failed to produce executable
FAIL: treelang/execute/static.tree (test for excess errors)
WARNING: treelang/execute/static.tree compilation failed to produce executable
FAIL: treelang/output-1, {}
=== treelang Summary for unix/-m64 ===
# of expected passes20
# of unexpected failures22
# of unresolved testcases 1
--
Summary: treelang test failures for biarch build
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: debian-gcc at lists dot debian dot org
GCC host triplet: powerpc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27275
[Bug target/27275] treelang test failures for biarch build
--- Comment #1 from debian-gcc at lists dot debian dot org 2006-04-23 23:39 --- Created an attachment (id=11321) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11321&action=view) treelang.log -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27275
[Bug c++/9278] Illegal use of typedef to "void"
--- Comment #21 from ben at decadentplace dot org dot uk 2006-04-23 23:44 --- I have submitted a defect report about the difference from C in this respect; this is now C++ core DR 577: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#577 Please could the "fix" to GCC be reverted until this issue is settled? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9278
[Bug middle-end/23442] Compiler fails to build - internal compiler error: in do_SUBST, at combine.c:462
--- Comment #4 from tobutaz at gmail dot com 2006-04-23 23:57 --- This is annoying, all of these fail: 3.4.5, 3.4.6, 4.0.3, 4.1.0 I've tried to build from i386-linux-gnu instead of x86_64-linux-gnu by passing --host=i386 --target=m68k-elf to the configure script, to no avail. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23442
[Bug middle-end/25776] [4.2 Regression] ICE in cgraph after error at -O1 and above
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-04-24 00:38 --- here is the fix I came up with: Index: cgraphunit.c === --- cgraphunit.c(revision 113199) +++ cgraphunit.c(working copy) @@ -1404,7 +1404,8 @@ cgraph_optimize (void) fprintf (cgraph_dump_file, "Marked "); dump_cgraph (cgraph_dump_file); } - ipa_passes (); + if (errorcount == 0 && sorrycount == 0) +ipa_passes (); /* This pass remove bodies of extern inline functions we never inlined. Do this later so other IPA passes see what is really going on. */ cgraph_remove_unreachable_nodes (false, dump_file); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25776
[Bug c/27150] [4.2 Regression] ICE with &parm_decl != 0 in build_binary_op
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-24 00:38 ---
Here is the fix:
Index: c-typeck.c
===
--- c-typeck.c (revision 113199)
+++ c-typeck.c (working copy)
@@ -7978,7 +7978,8 @@ build_binary_op (enum tree_code code, tr
{
if (TREE_CODE (op0) == ADDR_EXPR
&& DECL_P (TREE_OPERAND (op0, 0))
- && !DECL_WEAK (TREE_OPERAND (op0, 0)))
+ && (TREE_CODE (TREE_OPERAND(op0, 0)) == PARM_DECL
+ || !DECL_WEAK (TREE_OPERAND (op0, 0
warning (OPT_Walways_true, "the address of %qD will never be NULL",
TREE_OPERAND (op0, 0));
result_type = type0;
@@ -7987,7 +7988,8 @@ build_binary_op (enum tree_code code, tr
{
if (TREE_CODE (op1) == ADDR_EXPR
&& DECL_P (TREE_OPERAND (op1, 0))
- && !DECL_WEAK (TREE_OPERAND (op1, 0)))
+ && (TREE_CODE (TREE_OPERAND(op1, 0)) == PARM_DECL
+ || !DECL_WEAK (TREE_OPERAND (op1, 0
warning (OPT_Walways_true, "the address of %qD will never be NULL",
TREE_OPERAND (op1, 0));
result_type = type1;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27150
[Bug c++/9278] Illegal use of typedef to "void"
--- Comment #22 from pinskia at gcc dot gnu dot org 2006-04-24 00:41 --- (In reply to comment #21) > Please could the "fix" to GCC be reverted until this issue is settled? Considering the orginal DR was rejected as not a defect, I doubt yours will have an effect also. See: http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_closed.html#18 Maybe it will be but as of right now GCC 4.2.0 follows the standard and it was settled already before. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9278
Re: [Bug tree-optimization/26304] [4.2 Regression] 25_algorithms/prev_permutation/1.cc on powerpc{64,}-linux and powerpc-darwin
On Sun, 2006-04-23 at 23:14 +, pinskia at gcc dot gnu dot org wrote: > > --- Comment #17 from pinskia at gcc dot gnu dot org 2006-04-23 23:14 > --- > Rewritting that loop like: > [kudzu:local/trunk/gcc] pinskia% svn diff tree-ssa-loop-niter.c > Index: tree-ssa-loop-niter.c > === > --- tree-ssa-loop-niter.c (revision 113199) > +++ tree-ssa-loop-niter.c (working copy) > @@ -1939,6 +1939,7 @@ scev_probably_wraps_p (tree type, tree b >tree unsigned_type, valid_niter; >tree base_plus_step, bpsps; >int cps, cpsps; > + bool known_not_to_wrap; > >/* FIXME: The following code will not be used anymore once > http://gcc.gnu.org/ml/gcc-patches/2005-06/msg02025.html is > @@ -2077,8 +2078,10 @@ scev_probably_wraps_p (tree type, tree b > >estimate_numbers_of_iterations_loop (loop); >for (bound = loop->bounds; bound; bound = bound->next) > -if (proved_non_wrapping_p (at_stmt, bound, type, valid_niter)) > - return false; > +if (!proved_non_wrapping_p (at_stmt, bound, type, valid_niter)) > + known_not_to_wrap = false; > + if (known_not_to_wrap) > + return false; > >/* At this point we still don't have a proof that the iv does not > overflow: give up. */ > known_to_wrap may be uninitialized at the if statement here. You need to init it to true.
[Bug tree-optimization/26304] [4.2 Regression] 25_algorithms/prev_permutation/1.cc on powerpc{64,}-linux and powerpc-darwin
--- Comment #19 from dberlin at gcc dot gnu dot org 2006-04-24 01:10
---
Subject: Re: [4.2 Regression]
25_algorithms/prev_permutation/1.cc on powerpc{64,}-linux and
powerpc-darwin
On Sun, 2006-04-23 at 23:14 +, pinskia at gcc dot gnu dot org wrote:
>
> --- Comment #17 from pinskia at gcc dot gnu dot org 2006-04-23 23:14
> ---
> Rewritting that loop like:
> [kudzu:local/trunk/gcc] pinskia% svn diff tree-ssa-loop-niter.c
> Index: tree-ssa-loop-niter.c
> ===
> --- tree-ssa-loop-niter.c (revision 113199)
> +++ tree-ssa-loop-niter.c (working copy)
> @@ -1939,6 +1939,7 @@ scev_probably_wraps_p (tree type, tree b
>tree unsigned_type, valid_niter;
>tree base_plus_step, bpsps;
>int cps, cpsps;
> + bool known_not_to_wrap;
>
>/* FIXME: The following code will not be used anymore once
> http://gcc.gnu.org/ml/gcc-patches/2005-06/msg02025.html is
> @@ -2077,8 +2078,10 @@ scev_probably_wraps_p (tree type, tree b
>
>estimate_numbers_of_iterations_loop (loop);
>for (bound = loop->bounds; bound; bound = bound->next)
> -if (proved_non_wrapping_p (at_stmt, bound, type, valid_niter))
> - return false;
> +if (!proved_non_wrapping_p (at_stmt, bound, type, valid_niter))
> + known_not_to_wrap = false;
> + if (known_not_to_wrap)
> + return false;
>
>/* At this point we still don't have a proof that the iv does not
> overflow: give up. */
>
known_to_wrap may be uninitialized at the if statement here.
You need to init it to true.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26304
[Bug libstdc++/27256] gcc 4.1.0 compilation fails on RHEL AS 3 (x86_64)
--- Comment #3 from ST at itsc dot cuhk dot edu dot hk 2006-04-24 01:30 --- Subject: RE: gcc 4.1.0 compilation fails on RHEL AS 3 (x86_64) Thanks a lot. -Original Message- From: pcarlini at suse dot de [mailto:[EMAIL PROTECTED] Sent: Saturday, April 22, 2006 4:50 PM To: ST Wong (ITSC) Subject: [Bug libstdc++/27256] gcc 4.1.0 compilation fails on RHEL AS 3 (x86_64) --- Comment #2 from pcarlini at suse dot de 2006-04-22 08:50 --- (In reply to comment #1) > > /usr/bin/ld: BFD 2.14.90.0.4 20030523 internal error, aborting at > As you can see, the problem affects ld, the linker, *not* libstdc++. > Please report it to the binutils project. Thanks. By the way, 2.14.90.* is *very* old: before reporting any bug anywhere about it, please consider an upgrade, in the first place. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27256
[Bug tree-optimization/27144] [4.2 regression] segfault with -O2 on x86_64 (and powerpc64)
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-24 01:50 --- The ICE is due to looking at the type of a freed SSA_NAME during IV-OPTs. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||rakdver at gcc dot gnu dot ||org Summary|[4.2 regression] segfault |[4.2 regression] segfault |with -O2 on x86_64 |with -O2 on x86_64 (and ||powerpc64) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27144
[Bug c++/26740] [4.2 regression] ICE taking the address of a bound member function
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-24 01:51 ---
This patch fixes the ICE for me but I don't know if it is the correct one:
Index: cp/typeck.c
===
--- cp/typeck.c (revision 113199)
+++ cp/typeck.c (working copy)
@@ -4208,6 +4208,7 @@ build_unary_op (enum tree_code code, tre
and the created OFFSET_REF. */
tree base = TYPE_MAIN_VARIANT (TREE_TYPE (TREE_OPERAND (arg, 0)));
tree fn = get_first_fn (TREE_OPERAND (arg, 1));
+ mark_used (fn);
if (! flag_ms_extensions)
{
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26740
[Bug middle-end/27088] [4.2 regression] Segfault with inlining producing negative shift count
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-24 01:52 --- I can no longer reproduce this. Does it reproduce for you still? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27088
[Bug c++/27210] [4.2 Regression] ICE on c++ template
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-24 01:54 --- This patch fixes the ICE for me but I don't know if it is the correct one: Index: tree.h === --- tree.h (revision 113199) +++ tree.h (working copy) @@ -3981,7 +3981,7 @@ extern bool contains_placeholder_p (tree case of a constant to save time. Also check for null. */ #define CONTAINS_PLACEHOLDER_P(EXP) \ - ((EXP) != 0 && ! TREE_CONSTANT (EXP) && contains_placeholder_p (EXP)) + ((EXP) != 0 && !TYPE_P (EXP) && !TREE_CONSTANT (EXP) && contains_placeholder_p (EXP)) /* Return 1 if any part of the computation of TYPE involves a PLACEHOLDER_EXPR. This includes size, bounds, qualifiers (for QUAL_UNION_TYPE) and field --- Basicially a type can never contain a placeholder expression and TREE_CONSTANT does not exist on a type. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27210
[Bug target/27275] treelang test failures for biarch build
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-24 01:56 --- This is a dup of bug 24955 which was closed as will not fix. *** This bug has been marked as a duplicate of 24955 *** -- 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=27275
[Bug target/24955] ICE: rs6000_output_function_epilogue, at config/rs6000/rs6000.c:15204
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-04-24 01:56 --- *** Bug 27275 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||debian-gcc at lists dot ||debian dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24955
[Bug testsuite/27274] execution test of gcc.dg/i386-sse-9.c fails on non-SSE CPU
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-24 02:01 --- Confirmed. The testcase was introduced by: 2004-08-03 H.J. Lu <[EMAIL PROTECTED]> PR target/16570 * gcc.dg/i386-sse-9.c: New test. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||hjl at gcc dot gnu dot org Severity|trivial |minor Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC host triplet|i586-pc-linux-gnu | GCC target triplet||i586-pc-linux-gnu Last reconfirmed|-00-00 00:00:00 |2006-04-24 02:01:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27274
[Bug c++/26912] [4.0/4.1/4.2 Regression] friend const member function specialization fails to compile
--- Comment #2 from mmitchel at gcc dot gnu dot org 2006-04-24 03:50 --- Subject: Bug 26912 Author: mmitchel Date: Mon Apr 24 03:50:31 2006 New Revision: 113213 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113213 Log: PR c++/26912 * cp-tree.h (build_this_parm): Declare. (grok_method_quals): Remove. (build_memfn_type): Declare. (build_artificial_parm): Declare. (do_friend): Remove quals parameter. * decl.c (build_this_parm): New function. (grokfndecl): Use it. Do not pass quals to grokclassfn. (grokdeclarator): Rename quals to memfn_quals. Avoid allocating unnecessary TYPE_DECLs. Correct qualification of member function types. Tidy. * method.c (implicitly_declare_fn): Use build_this_parm. * friend.c (do_friend): Remove quals parameter. * decl2.c (grok_method_quals): Remove. (build_memfn_type): New function. (build_artificial_parm): Give it external linkage. (grokclassfn): Remove quals parameter. Do not build "this" PARM_DECL here. PR c++/26912 * g++.dg/template/friend41.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/friend41.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl.c trunk/gcc/cp/decl2.c trunk/gcc/cp/friend.c trunk/gcc/cp/method.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26912
[Bug c++/26912] [4.0/4.1 Regression] friend const member function specialization fails to compile
--- Comment #3 from mmitchel at gcc dot gnu dot org 2006-04-24 03:55 --- Fixed in 4.2. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.0/4.1/4.2 Regression]|[4.0/4.1 Regression] friend |friend const member function|const member function |specialization fails to |specialization fails to |compile |compile http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26912
[Bug c++/27235] goto crossing P.O.D. initialization
--- Comment #11 from acahalan at gmail dot com 2006-04-24 04:10 --- When did gcc suddenly stop accepting new extensions? For years gcc has been more of a practical real-world compiler than a pedantic standards-only compiler. Many extensions have been added, both useful and useless. Just look at the list of them. Much of gcc's popularity has historically had to do with making things easy for programmers. Don't let us down now that the alternatives have gone extinct. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27235
[Bug target/21283] [4.0/4.1 regression] ICE with doubles
--- Comment #5 from sayle at gcc dot gnu dot org 2006-04-24 05:31 --- Subject: Bug 21283 Author: sayle Date: Mon Apr 24 05:31:28 2006 New Revision: 113215 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113215 Log: PR target/21283 * config/fr30/fr30.md (define_split): Avoid calling gen_lowpart on a SImode SUBREG of a floating point register after no_new_pseudos. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/config/fr30/fr30.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21283
