[Bug fortran/28335] [4.1 only] flush() / write() statement on closed units - error?
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-07-26 06:22 --- Hum... don't we want to backport that fix to 4.1? -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||jvdelisle at verizon dot net Known to fail||4.1.2 Known to work||4.2.0 Summary|flush() / write() statement |[4.1 only] flush() / write() |on closed units - error?|statement on closed units - ||error? http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28335
[Bug middle-end/28476] msp430-gcc with -Wunreachable-code Segmentation fault
--- Comment #5 from stefano dot franzoni at marposs dot com 2006-07-26 07:13 --- Subject: Re: msp430-gcc with -Wunreachable-code Segmentation fault I think this was fixed in 3.3 and I think this is a dup of bug 11142 or even PR 10660 or PR 10580. I believe you are correct Can you try a 3.3 release? I could try it. I need some help to dowload the right sources and recompile them for msp430. As an alternative I can point out the bug in the msp430 forum (http://sourceforge.net/mailarchive/forum.php?forum_id=7539) waiting for a msp430 guru. What do you suggest? pinskia at gcc dot gnu dot org [EMAIL PROTECTED] To .gnu.org [EMAIL PROTECTED] cc 26/07/2006 02:40 Subject [Bug middle-end/28476] msp430-gcc Please respond to with -Wunreachable-code [EMAIL PROTECTED] Segmentation fault gnu.org --- Comment #4 from pinskia at gcc dot gnu dot org 2006-07-26 00:40 --- I think this was fixed in 3.3 and I think this is a dup of bug 11142 or even PR 10660 or PR 10580. Can you try a 3.3 release? Also msp430 is not part of the FSF GCC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28476 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28476
[Bug c/28488] incorrect warning says signed and unsigned type in conditional expression
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-07-26 08:03 --- It says warning: signed and unsigned type in conditional expression and that is the case: unsigned int found_len = 0 ? a - b : foo; because a - b is signed and foo is unsigned. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28488
[Bug tree-optimization/28489] [4.2 regression] ICE in move_insn, at haifa-sched.c:1968
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-07-26 08:05 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-07-26 08:05:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28489
[Bug target/28490] [4.2 regression] ICE in ia64_expand_move, at config/ia64/ia64.c:1088
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-07-26 08:06 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-07-26 08:06:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28490
[Bug libfortran/27895] problem with SPREAD and zero-sized arrays
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2006-07-26 08:34 --- A patch for the library functions CSHIFT, PACK and SPREAD has been submitted: http://gcc.gnu.org/ml/gcc-patches/2006-07/msg01103.html The only one that is still not working is thus RESHAPE; it's proving difficult to fix! -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||07/msg01103.html Keywords|diagnostic | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27895
[Bug tree-optimization/26948] ICE: tree check: expected ssa_name, with -ftree-vectorize
--- Comment #4 from micis at gmx dot de 2006-07-26 09:04 --- The patch http://gcc.gnu.org/ml/gcc-patches/2006-07/msg01043.html fixes that bug for the reduced source as well as for the original source. Many thanks! Michael Cieslinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26948
[Bug rtl-optimization/28489] [4.2 regression] ICE in move_insn, at haifa-sched.c:1968
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Component|tree-optimization |rtl-optimization Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28489
[Bug target/28490] [4.2 regression] ICE in ia64_expand_move, at config/ia64/ia64.c:1088
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28490
[Bug libstdc++/28457] ext/pb_ds/regression/tree_data_map_rand.cc fails with a particular random seed.
--- Comment #1 from pcarlini at suse dot de 2006-07-26 11:26 --- Out of curiosity, can you try whether changing the optimization level has any effect? I'm asking because we are also seeing random failures of ext/pb_ds/regression/priority_queue_rand.cc on ia64-linux which go away at -O0 and -O1... In that case, I'm suspecting some sort of miscompilation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28457
[Bug c++/28250] [4.2 regression] ICE with invalid catch
--- Comment #9 from patchapp at dberlin dot org 2006-07-26 11:30 --- Subject: Bug number PR c++/28250 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-07/msg01108.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28250
[Bug c/28488] incorrect warning says signed and unsigned type in conditional expression
--- Comment #5 from gurganbl at rose-hulman dot edu 2006-07-26 11:42 --- That would be a problem in assignment, not in the conditional. Additionally, if I do unsigned int baz = 0; signed int bar = -1; baz = bar; I get no warning. I agree with what you say about there being a problem and what the problem is, but it should give the same warning as for the above code. Currently, the ?: syntax gives a misleading warning since the problem is not in the conditional but in the assignment and strictly having the assignment problem is not generating a warning. -- gurganbl at rose-hulman dot edu changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28488
[Bug c/28488] incorrect warning says signed and unsigned type in conditional expression
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-07-26 11:47 --- No, you are incorrect. Anyways the warnings about ?: are to make sure that you know that they are different signedness, which might change the behavior slightly than what you are expecting. unsigned int baz = 0; signed int bar = -1; baz = bar; This is a different issue and I think is being fixed by the -Wcoercion work. -- 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=28488
[Bug fortran/19292] [meta-bug] g77 features lacking in gfortran
--- Comment #27 from fxcoudert at gcc dot gnu dot org 2006-07-26 12:07 --- I just got the missing g77 intrinsics list down to: Access, fcn, Check file accessibility. ChMod,sub, Change file modes. FSeek,fcn, Position file (low-level). GMTime, fcn, Convert time to GMT time info. LShift, fcn, Left-shift bits LTime,sub, Convert time to local time info. RShift, fcn, Right-shift bits. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2005-11-12 23:29:51 |2006-07-26 12:07:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19292
[Bug debug/27574] [4.1 Regression] MIssing debug info at -O0 for a local variable in a C++ constructor
--- Comment #11 from amylaar at gcc dot gnu dot org 2006-07-26 12:30 --- (In reply to comment #10) If I had to guess I'd say that this was a C++ front end problem, or maybe a recent change in cgraph. It can't have been a particularly recent change, since it already failed with GNU C++ version 4.1.0 20050323 (experimental) (sh-elf) . It worked with GNU C++ version 4.1.0 20050314 (experimental) (sh-elf) . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27574
[Bug target/27075] [4.1/4.2 Regression] Compiler generate incorrect assembler for __sync_fetch-* builtins on e500 aka SPE
--- Comment #15 from dtemirbulatov at gmail dot com 2006-07-26 12:53 --- As Andrew posted, the question is the impact on other targets... Looking at the patch, it is only about e500(TARGET_E500 defined only for e500), so it should not impact other targets -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27075
[Bug libgcj/28491] New: NetworkInterface.getNetworkInterfaces() doesn't report ipv6 interfaces.
$ cat IPv6Test.java
import java.net.InetAddress;
import java.net.NetworkInterface;
import java.util.Enumeration;
public class IPv6Test
{
public static void main( String args[] ) throws Exception
{
Enumeration nics = NetworkInterface.getNetworkInterfaces();
while ( nics.hasMoreElements() )
{
NetworkInterface ni = (NetworkInterface)nics.nextElement();
System.out.println(ni);
}
}
}
$ gcj IPv6Test.java -C
$ java IPv6Test // java-sun-1.5.0.06
name:eth0 (eth0) index: 2 addresses:
/fe80:0:0:0:20f:eaff:fed3:1f6d%2;
/10.0.2.35;
name:lo (lo) index: 1 addresses:
/0:0:0:0:0:0:0:1%1;
/127.0.0.1;
$ gij IPv6Test
name: lo (lo) addresses:
/127.0.0.1;
name: eth0 (eth0) addresses:
/10.0.2.35;
$ /sbin/ip a l
1: lo: LOOPBACK,UP mtu 16436 qdisc noqueue
(...)
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
(...)
2: eth0: BROADCAST,MULTICAST,UP mtu 1500 qdisc pfifo_fast qlen 1000
(...)
inet 10.0.2.35/24 brd 10.0.2.255 scope global eth0
inet6 fe80::20f:eaff:fed3:1f6d/64 scope link
(...)
--
Summary: NetworkInterface.getNetworkInterfaces() doesn't report
ipv6 interfaces.
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at agmk dot net
GCC build triplet: x86_64-linux
GCC host triplet: x86_64-linux
GCC target triplet: x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28491
[Bug libstdc++/28457] ext/pb_ds/regression/tree_data_map_rand.cc fails with a particular random seed.
--- Comment #2 from drow at gcc dot gnu dot org 2006-07-26 13:11 --- Subject: Re: ext/pb_ds/regression/tree_data_map_rand.cc fails with a particular random seed. On Wed, Jul 26, 2006 at 11:26:01AM -, pcarlini at suse dot de wrote: Out of curiosity, can you try whether changing the optimization level has any effect? I'm asking because we are also seeing random failures of ext/pb_ds/regression/priority_queue_rand.cc on ia64-linux which go away at -O0 and -O1... In that case, I'm suspecting some sort of miscompilation. Fails at -O1 in the same way. Fails differently at -O0. Failure at /space/fsf/commit/gcc/libstdc++-v3/testsuite/util/regression/rand/assoc/detail/insert_fn_imps.hpp: 71 container: aabaaab bccadab aacdbc dab more... native container: ...more... Uncaught exception: insert Failed at index 297 Test failed with seed 1153519516 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28457
[Bug target/28490] [4.2 regression] ICE in ia64_expand_move, at config/ia64/ia64.c:1088
--- Comment #4 from tbm at cyrius dot com 2006-07-26 13:26 --- Created an attachment (id=11945) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11945action=view) test case Testcase from application dcraw -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28490
[Bug target/28490] [4.2 regression] ICE in ia64_expand_move, at config/ia64/ia64.c:1088
--- Comment #5 from tbm at cyrius dot com 2006-07-26 13:26 --- Created an attachment (id=11946) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11946action=view) test case Testcase from application dump -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28490
[Bug libstdc++/28457] ext/pb_ds/regression/tree_data_map_rand.cc fails with a particular random seed.
--- Comment #3 from pcarlini at suse dot de 2006-07-26 13:27 --- Thanks a lot for your feedback. Then, I think we should look first for things like uninitialized variables and/or miscompilations. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28457
[Bug middle-end/28402] [4.0/4.1 Regression] Doubleword shifts implemented using word_mode libcalls
--- Comment #5 from rsandifo at gcc dot gnu dot org 2006-07-26 13:30 --- Subject: Bug 28402 Author: rsandifo Date: Wed Jul 26 13:30:34 2006 New Revision: 115755 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115755 Log: gcc/ PR middle-end/28402 * optabs.c (expand_binop): Pass next_methods rather than methods to expand_doubleword_shift. gcc/testsuite/ PR middle-end/28402 * gcc.dg/pr28402.c: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/pr28402.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/optabs.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28402
[Bug middle-end/28403] [4.0/4.1 Regression] Missed argument pop after doubleword shift
--- Comment #5 from rsandifo at gcc dot gnu dot org 2006-07-26 13:32 --- Subject: Bug 28403 Author: rsandifo Date: Wed Jul 26 13:32:01 2006 New Revision: 115756 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115756 Log: gcc/ PR middle-end/28403 * optabs.c (expand_doubleword_shift): Wrap the call to do_compare_rtx_and_jump with NO_DEFER_POP and OK_DEFER_POP. gcc/testsuite/ PR middle-end/28403 * gcc.c-torture/execute/pr28403.c: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.c-torture/execute/pr28403.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/optabs.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28403
[Bug middle-end/28402] [4.0/4.1 Regression] Doubleword shifts implemented using word_mode libcalls
--- Comment #6 from rsandifo at gcc dot gnu dot org 2006-07-26 13:34 --- Subject: Bug 28402 Author: rsandifo Date: Wed Jul 26 13:34:17 2006 New Revision: 115757 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115757 Log: gcc/ PR middle-end/28402 * optabs.c (expand_binop): Pass next_methods rather than methods to expand_doubleword_shift. gcc/testsuite/ PR middle-end/28402 * gcc.dg/pr28402.c: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/gcc.dg/pr28402.c Modified: branches/gcc-4_0-branch/gcc/ChangeLog branches/gcc-4_0-branch/gcc/optabs.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28402
[Bug middle-end/28403] [4.0/4.1 Regression] Missed argument pop after doubleword shift
--- Comment #6 from rsandifo at gcc dot gnu dot org 2006-07-26 13:35 --- Subject: Bug 28403 Author: rsandifo Date: Wed Jul 26 13:35:34 2006 New Revision: 115758 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115758 Log: gcc/ PR middle-end/28403 * optabs.c (expand_doubleword_shift): Wrap the call to do_compare_rtx_and_jump with NO_DEFER_POP and OK_DEFER_POP. gcc/testsuite/ PR middle-end/28403 * gcc.c-torture/execute/pr28403.c: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/gcc.c-torture/execute/pr28403.c Modified: branches/gcc-4_0-branch/gcc/ChangeLog branches/gcc-4_0-branch/gcc/optabs.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28403
[Bug middle-end/28402] [4.0/4.1 Regression] Doubleword shifts implemented using word_mode libcalls
--- Comment #7 from rsandifo at gcc dot gnu dot org 2006-07-26 13:38 --- Patch applied to branches. -- rsandifo at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail|4.0.4 4.1.2 | Known to work|3.4.4 4.2.0 |3.4.4 4.0.4 4.1.2 4.2.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28402
[Bug middle-end/28403] [4.0/4.1 Regression] Missed argument pop after doubleword shift
--- Comment #7 from rsandifo at gcc dot gnu dot org 2006-07-26 13:39 --- Patch applied to branches -- rsandifo at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail|4.0.4 4.1.2 | Known to work|3.4.4 4.2.0 |3.4.4 4.0.4 4.1.2 4.2.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28403
[Bug c/28492] New: -Wmissing-format-attribute causes warning for vsnprintf()
The options -Wformat -Wmissing-format-attribute causes the
warning: function might be possible candidate for `printf' format attribute
for a call to vsnprintf() even though its prototype already
has the printf format attribute.
This is observed with the
preinstalled gcc 4.1.0 on SUSE Linux 10.1 (AMD64) and with a
manually installed gcc 4.1.0 on Scientific Linux 4.0 (Xeon) (and also with the
preinstalled gcc 3.2.2 on Red Hat Linux 9.0 (i686))
with this command:
gcc -save-temps -c vsnprintf_one.c -Wformat -Wmissing-format-attribute
The vsnprintf_one.i produced on Scientific Linux is pasted here:
# 1 vsnprintf_one.c
# 1 built-in
# 1 command line
# 1 vsnprintf_one.c
# 1 /usr/include/stdio.h 1 3 4
# 28 /usr/include/stdio.h 3 4
# 1 /usr/include/features.h 1 3 4
# 314 /usr/include/features.h 3 4
# 1 /usr/include/sys/cdefs.h 1 3 4
# 315 /usr/include/features.h 2 3 4
# 337 /usr/include/features.h 3 4
# 1 /usr/include/gnu/stubs.h 1 3 4
# 338 /usr/include/features.h 2 3 4
# 29 /usr/include/stdio.h 2 3 4
# 1 /usr/lib/gcc/i386-redhat-linux/3.4.3/include/stddef.h 1 3 4
# 213 /usr/lib/gcc/i386-redhat-linux/3.4.3/include/stddef.h 3 4
typedef unsigned int size_t;
# 35 /usr/include/stdio.h 2 3 4
# 1 /usr/include/bits/types.h 1 3 4
# 28 /usr/include/bits/types.h 3 4
# 1 /usr/include/bits/wordsize.h 1 3 4
# 29 /usr/include/bits/types.h 2 3 4
# 1 /usr/lib/gcc/i386-redhat-linux/3.4.3/include/stddef.h 1 3 4
# 32 /usr/include/bits/types.h 2 3 4
typedef unsigned char __u_char;
typedef unsigned short int __u_short;
typedef unsigned int __u_int;
typedef unsigned long int __u_long;
typedef signed char __int8_t;
typedef unsigned char __uint8_t;
typedef signed short int __int16_t;
typedef unsigned short int __uint16_t;
typedef signed int __int32_t;
typedef unsigned int __uint32_t;
__extension__ typedef signed long long int __int64_t;
__extension__ typedef unsigned long long int __uint64_t;
__extension__ typedef long long int __quad_t;
__extension__ typedef unsigned long long int __u_quad_t;
# 129 /usr/include/bits/types.h 3 4
# 1 /usr/include/bits/typesizes.h 1 3 4
# 130 /usr/include/bits/types.h 2 3 4
__extension__ typedef __u_quad_t __dev_t;
__extension__ typedef unsigned int __uid_t;
__extension__ typedef unsigned int __gid_t;
__extension__ typedef unsigned long int __ino_t;
__extension__ typedef __u_quad_t __ino64_t;
__extension__ typedef unsigned int __mode_t;
__extension__ typedef unsigned int __nlink_t;
__extension__ typedef long int __off_t;
__extension__ typedef __quad_t __off64_t;
__extension__ typedef int __pid_t;
__extension__ typedef struct { int __val[2]; } __fsid_t;
__extension__ typedef long int __clock_t;
__extension__ typedef unsigned long int __rlim_t;
__extension__ typedef __u_quad_t __rlim64_t;
__extension__ typedef unsigned int __id_t;
__extension__ typedef long int __time_t;
__extension__ typedef unsigned int __useconds_t;
__extension__ typedef long int __suseconds_t;
__extension__ typedef int __daddr_t;
__extension__ typedef long int __swblk_t;
__extension__ typedef int __key_t;
__extension__ typedef int __clockid_t;
__extension__ typedef int __timer_t;
__extension__ typedef long int __blksize_t;
__extension__ typedef long int __blkcnt_t;
__extension__ typedef __quad_t __blkcnt64_t;
__extension__ typedef unsigned long int __fsblkcnt_t;
__extension__ typedef __u_quad_t __fsblkcnt64_t;
__extension__ typedef unsigned long int __fsfilcnt_t;
__extension__ typedef __u_quad_t __fsfilcnt64_t;
__extension__ typedef int __ssize_t;
typedef __off64_t __loff_t;
typedef __quad_t *__qaddr_t;
typedef char *__caddr_t;
__extension__ typedef int __intptr_t;
__extension__ typedef unsigned int __socklen_t;
# 37 /usr/include/stdio.h 2 3 4
typedef struct _IO_FILE FILE;
# 62 /usr/include/stdio.h 3 4
typedef struct _IO_FILE __FILE;
# 72 /usr/include/stdio.h 3 4
# 1 /usr/include/libio.h 1 3 4
# 32 /usr/include/libio.h 3 4
# 1 /usr/include/_G_config.h 1 3 4
# 14 /usr/include/_G_config.h 3 4
# 1 /usr/lib/gcc/i386-redhat-linux/3.4.3/include/stddef.h 1 3 4
# 325 /usr/lib/gcc/i386-redhat-linux/3.4.3/include/stddef.h 3 4
typedef long int wchar_t;
# 354 /usr/lib/gcc/i386-redhat-linux/3.4.3/include/stddef.h 3 4
typedef unsigned int wint_t;
# 15 /usr/include/_G_config.h 2 3 4
# 24 /usr/include/_G_config.h 3 4
# 1 /usr/include/wchar.h 1 3 4
# 48 /usr/include/wchar.h 3 4
# 1 /usr/lib/gcc/i386-redhat-linux/3.4.3/include/stddef.h 1 3 4
# 49 /usr/include/wchar.h 2 3 4
# 1 /usr/include/bits/wchar.h 1 3 4
# 51 /usr/include/wchar.h 2 3 4
# 76 /usr/include/wchar.h 3 4
typedef struct
{
int __count;
union
{
wint_t __wch;
char __wchb[4];
} __value;
} __mbstate_t;
# 25 /usr/include/_G_config.h 2 3 4
typedef struct
{
__off_t __pos;
__mbstate_t __state;
} _G_fpos_t;
typedef struct
{
__off64_t __pos;
__mbstate_t __state;
} _G_fpos64_t;
# 44 /usr/include/_G_config.h 3 4
# 1 /usr/include/gconv.h 1 3 4
# 28 /usr/include/gconv.h 3 4
# 1 /usr/include/wchar.h 1 3 4
# 48
[Bug rtl-optimization/28489] [4.2 regression] ICE in move_insn, at haifa-sched.c:1968
--- Comment #4 from tbm at cyrius dot com 2006-07-26 13:48 --- Created an attachment (id=11947) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11947action=view) test case Testcase from application 'john'. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28489
[Bug debug/27574] [4.1 Regression] MIssing debug info at -O0 for a local variable in a C++ constructor
--- Comment #12 from drow at gcc dot gnu dot org 2006-07-26 13:59 --- It is a cgraph change. There were several patches affecting cgraph_remove_node during this time period; it was probably one of those. The problem is that we throw away the body of the abstract copy of the constructor, before we get around to emitting debug information for it. There's already a debug hook at what looks like the right time. It's just not used for dwarf2: deferred_inline_function. It was replaced by outlining_inline_function, which is called only when we know we'll generate a concrete instance. There's a couple of things we could do: - Not throw away the body. - Try to generate the debug info earlier, and then prune it if it isn't needed. - Try to treat one of the concrete clones (whose bodies we need) as the origin. I think the first one is going to be safest for now. I don't really see how to do it. Jan, do you have a suggestion? -- drow at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27574
[Bug libstdc++/28457] ext/pb_ds/regression/tree_data_map_rand.cc fails with a particular random seed.
--- Comment #4 from pcarlini at suse dot de 2006-07-26 14:55 --- Confirmed on x86-linux. I did: Index: rand_regression_test.hpp === --- rand_regression_test.hpp(revision 115714) +++ rand_regression_test.hpp(working copy) @@ -111,7 +111,7 @@ // Sane defaults. size_t n = iter; size_t m = keys; -size_t sd = 0; // 0 = time-determined arbitrary +size_t sd = 1153519516; // 0 = time-determined arbitrary double tp = 0.2; double ip = 0.6; double ep = 0.2; -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-07-26 14:55:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28457
[Bug c++/28493] New: Wrong address of stack object used for destructor call on PPC
-- sample program --
struct Command {
Command() {}
virtual ~Command() {}
};
void tryfunc() {
Command cmd;
for (;;) { throw 1; }
}
-- end sample program --
Disassembly of tryfunc():
(notice at 58-5c, constructor is called on r1+8, but at
88-90, destructor is called on r1+0)
tryfunc():
0: 94 21 ff 60 stwur1,-160(r1)
4: 7c 08 02 a6 mflrr0
8: 3d 20 00 00 lis r9,0
a: R_PPC_ADDR16_HA __gxx_personality_sj0
c: 39 29 00 00 addir9,r9,0
e: R_PPC_ADDR16_LO __gxx_personality_sj0
10: 7d 80 00 26 mfcrr12
14: 91 21 00 30 stw r9,48(r1)
18: 3d 20 00 00 lis r9,0
1a: R_PPC_ADDR16_HA .gcc_except_table
1c: 38 61 00 18 addir3,r1,24
20: 90 01 00 a4 stw r0,164(r1)
24: 39 29 00 00 addir9,r9,0
26: R_PPC_ADDR16_LO .gcc_except_table
28: 80 01 00 00 lwz r0,0(r1)
2c: 91 21 00 34 stw r9,52(r1)
30: 3d 20 00 00 lis r9,0
32: R_PPC_ADDR16_HA .text+0x84
34: 39 29 00 84 addir9,r9,132
36: R_PPC_ADDR16_LO .text+0x84
38: 90 01 00 40 stw r0,64(r1)
3c: 38 01 00 08 addir0,r1,8
40: 90 01 00 38 stw r0,56(r1)
44: 91 81 00 54 stw r12,84(r1)
48: 91 21 00 3c stw r9,60(r1)
4c: bd c1 00 58 stmwr14,88(r1)
50: 90 21 00 44 stw r1,68(r1)
54: 48 00 00 01 bl 54 tryfunc()+0x54
54: R_PPC_REL24 _Unwind_SjLj_Register
58: 38 61 00 08 addir3,r1,8
5c: 48 00 00 01 bl 5c tryfunc()+0x5c
5c: R_PPC_REL24 Command::Command()
60: 38 60 00 04 li r3,4
64: 48 00 00 01 bl 64 tryfunc()+0x64
64: R_PPC_REL24 __cxa_allocate_exception
68: 38 00 00 01 li r0,1
6c: 3c 80 00 00 lis r4,0
6e: R_PPC_ADDR16_HA typeinfo for int
70: 90 03 00 00 stw r0,0(r3)
74: 38 84 00 00 addir4,r4,0
76: R_PPC_ADDR16_LO typeinfo for int
78: 38 a0 00 00 li r5,0
7c: 90 01 00 1c stw r0,28(r1)
80: 48 00 00 01 bl 80 tryfunc()+0x80
80: R_PPC_REL24 __cxa_throw
84: 80 01 00 20 lwz r0,32(r1)
88: 7c 23 0b 78 mr r3,r1
8c: 90 01 00 4c stw r0,76(r1)
90: 48 00 00 01 bl 90 tryfunc()+0x90
90: R_PPC_REL24 Command::~Command()
94: 38 00 ff ff li r0,-1
98: 80 61 00 4c lwz r3,76(r1)
9c: 90 01 00 1c stw r0,28(r1)
a0: 48 00 00 01 bl a0 tryfunc()+0xa0
a0: R_PPC_REL24 _Unwind_SjLj_Resume
Program was compiled with the following command line options:
g++ -Os -msoft-float -fno-inline sample-program.cc -c
The -msoft-float and -Os aren't necessary to reproduce this problem,
but reduce clutter.
The optimization level doesn't matter. Looking at a disassembly at
-O0 may shed more light on the problem:
Disassembly of tryfunc() at -O0 (all other CL arguments unchanged):
tryfunc():
0: 94 21 ff 50 stwur1,-176(r1)
4: 7c 08 02 a6 mflrr0
8: 7d 80 00 26 mfcrr12
c: 91 c1 00 68 stw r14,104(r1)
10: 91 e1 00 6c stw r15,108(r1)
14: 92 01 00 70 stw r16,112(r1)
18: 92 21 00 74 stw r17,116(r1)
1c: 92 41 00 78 stw r18,120(r1)
20: 92 61 00 7c stw r19,124(r1)
24: 92 81 00 80 stw r20,128(r1)
28: 92 a1 00 84 stw r21,132(r1)
2c: 92 c1 00 88 stw r22,136(r1)
30: 92 e1 00 8c stw r23,140(r1)
34: 93 01 00 90 stw r24,144(r1)
38: 93 21 00 94 stw r25,148(r1)
3c: 93 41 00 98 stw r26,152(r1)
40: 93 61 00 9c stw r27,156(r1)
44: 93 81 00 a0 stw r28,160(r1)
48: 93 a1 00 a4 stw r29,164(r1)
4c: 93 c1 00 a8 stw r30,168(r1)
50: 93 e1 00 ac stw r31,172(r1)
54: 90 01 00 b4 stw r0,180(r1)
58: 91 81 00 64 stw r12,100(r1)
5c: 7c 3f 0b 78 mr r31,r1
60: 3d 20 00 00 lis r9,0
62: R_PPC_ADDR16_HA __gxx_personality_sj0
64: 38 09 00 00 addir0,r9,0
66: R_PPC_ADDR16_LO __gxx_personality_sj0
68: 90 1f 00 30 stw r0,48(r31)
6c: 3d 20 00 00 lis r9,0
6e: R_PPC_ADDR16_HA .gcc_except_table
70: 38 09 00 00 addir0,r9,0
72: R_PPC_ADDR16_LO .gcc_except_table
74: 90 1f 00 34 stw r0,52(r31)
78: 39 7f 00 38 addir11,r31,56
7c: 38 1f 00 08 addir0,r31,8
80: 90 0b 00 00 stw
[Bug target/28493] Wrong address of stack object used for destructor call on PPC
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Component|c++ |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28493
[Bug target/28102] [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared
--- Comment #15 from tbm at cyrius dot com 2006-07-26 15:25 --- One of our (Debian's) Hurd porters has confirmed that this patch works. Alfred, can you please clean it up and submit it to gcc-patches. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28102
[Bug target/28102] [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared
--- Comment #16 from ams at gnu dot org 2006-07-26 15:35 --- Subject: Re: [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared I'll try to get around it as soon as I can. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28102
[Bug target/28493] Wrong address of stack object used for destructor call on PPC
--- Comment #1 from atgraham at gmail dot com 2006-07-26 15:42 ---
Actually, the for loop is unnecessary. Here's a shorter version that displays
the same problem:
struct Command {
virtual ~Command() {}
};
void tryfunc() {
Command cmd;
throw 1;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28493
[Bug fortran/28494] New: Unclear run time error message
I received the run time error message upper bound of dimension 1 exceeded. I initially thought that I had an array with an upper bound of 1, and that the array index was larger than that. I now think that the error message tells me that I have a rank-2 array, and that the upper bound of the first rank was exceeded. The error message could be improved to read rank 1 or index 1 instead. -- Summary: Unclear run time error message Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: schnetter at aei dot mpg dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28494
[Bug c++/28495] New: [4.2 regression] ICE in final_scan_insn, at final.c:2448
I get the following ICE with gcc 4.2 on ia64. The reduced testcase fails on
gcc 4.0/4.1 with an error but the original file compiles fine and only produces
an ICE with gcc 4.2 at -O.
[EMAIL PROTECTED]:~$ /usr/lib/gcc-snapshot/bin/g++ -c -O xstow-tree.cpp
xstow-tree.cpp: In member function 'bool Tree::check(RefNode, RefNode,
Refstd::vectorTree::Link, std::allocatorTree::Link )':
xstow-tree.cpp:718: error: could not split insn
(call_insn 359 358 360 24 (parallel [
(call (mem:DI (const:DI (plus:DI (symbol_ref:DI
(_ZTV14VecStringValue) [flags 0x40] var_decl 0x204fca50
_ZTV14VecStringValue)
(const_int 16 [0x10]))) [0 S8 A64])
(const_int 1 [0x1]))
(clobber (reg:DI 320 b0))
(clobber (scratch:DI))
(clobber (scratch:DI))
]) 322 {call_gp} (insn_list:REG_DEP_TRUE 354 (insn_list:REG_DEP_TRUE
357 (insn_list:REG_DEP_TRUE 358 (nil
(expr_list:REG_DEAD (reg:DI 120 r120)
(expr_list:REG_DEAD (reg:DI 121 r121)
(expr_list:REG_UNUSED (scratch:DI)
(expr_list:REG_UNUSED (scratch:DI)
(expr_list:REG_UNUSED (reg:DI 320 b0)
(nil))
(expr_list:REG_DEP_TRUE (use (reg:DI 1 r1))
(expr_list:REG_DEP_TRUE (use (reg:DI 121 r121))
(expr_list:REG_DEP_TRUE (use (reg:DI 120 r120))
(nil)
xstow-tree.cpp:718: internal compiler error: in final_scan_insn, at
final.c:2448
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see URL:file:///usr/share/doc/gcc-4.1/README.Bugs.
[EMAIL PROTECTED]:~$ /usr/lib/gcc-snapshot/bin/g++ -c xstow-tree.cpp
[EMAIL PROTECTED]:~$
Here's proof that the original source is valid code. ;)
[EMAIL PROTECTED]:~/src/xstow-0.5.1/src$ /usr/lib/gcc-snapshot/bin/g++
-DHAVE_CONFIG_H -I.. -g -O2 -DNDEBUG -DNFORMAT -DSYSCONFDIR='/etc/xstow'
-c -o tree.o tree.cpp
tree.cpp: In member function 'bool Tree::check(RefNode, RefNode,
Refstd::vectorTree::Link, std::allocatorTree::Link )':
tree.cpp:613: error: could not split insn
(call_insn 4695 32617 32618 444 tree.cpp:468 (parallel [
(call (mem:DI (const:DI (plus:DI (symbol_ref:DI
(_ZTV14VecStringValue) [flags 0x40] var_decl 0x224fd340
_ZTV14VecStringValue)
(const_int 80 [0x50]))) [0 S8 A64])
(const_int 1 [0x1]))
(clobber (reg:DI 320 b0))
(clobber (scratch:DI))
(clobber (scratch:DI))
]) 322 {call_gp} (nil)
(expr_list:REG_DEAD (reg:DI 120 r120)
(expr_list:REG_DEAD (reg:DI 121 r121)
(expr_list:REG_UNUSED (scratch:DI)
(expr_list:REG_UNUSED (scratch:DI)
(expr_list:REG_UNUSED (reg:DI 320 b0)
(expr_list:REG_EH_REGION (const_int 145 [0x91])
(nil)))
(expr_list:REG_DEP_TRUE (use (reg:DI 1 r1))
(expr_list:REG_DEP_TRUE (use (reg:DI 121 r121))
(expr_list:REG_DEP_TRUE (use (reg:DI 120 r120))
(nil)
tree.cpp:613: internal compiler error: in final_scan_insn, at final.c:2448
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see URL:file:///usr/share/doc/gcc-4.1/README.Bugs.
[EMAIL PROTECTED]:~/src/xstow-0.5.1/src$ g++-4.1 -DHAVE_CONFIG_H -I.. -g -O2
-DNDEBUG -DNFORMAT -DSYSCONFDIR='/etc/xstow' -c -o tree.o tree.cpp
[EMAIL PROTECTED]:~/src/xstow-0.5.1/src$ g++-4.0 -DHAVE_CONFIG_H -I.. -g -O2
-DNDEBUG -DNFORMAT -DSYSCONFDIR='/etc/xstow' -c -o tree.o tree.cpp
[EMAIL PROTECTED]:~/src/xstow-0.5.1/src$
--
Summary: [4.2 regression] ICE in final_scan_insn, at final.c:2448
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbm at cyrius dot com
GCC host triplet: ia64-linux-gnu
GCC target triplet: ia64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28495
[Bug target/28495] [4.2 regression] ICE in final_scan_insn, at final.c:2448
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c++ |target Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28495
[Bug target/28495] [4.2 regression] ICE in final_scan_insn, at final.c:2448
--- Comment #1 from tbm at cyrius dot com 2006-07-26 16:22 --- Created an attachment (id=11948) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11948action=view) test case Testcase from application xstow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28495
[Bug fortran/28494] Unclear run time error message
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-26 16:22 --- dimension 1 means to me, the first dimension. I don't see why it was not hard to understand, in fact I did not read the rest of your message until I already said to myself this was the first dimension. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28494
[Bug target/28495] [4.2 regression] ICE in final_scan_insn, at final.c:2448
--- Comment #2 from tbm at cyrius dot com 2006-07-26 16:30 --- Huh, the testcase fails at -O but works at -O2. (But the original sources failed at -O2). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28495
[Bug target/28495] [4.2 regression] ICE in final_scan_insn, at final.c:2448
--- Comment #3 from tbm at cyrius dot com 2006-07-26 16:36 --- This bug got introduced between 20051122 and 20060218. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28495
[Bug target/27907] [4.2 regression] ICE in expand_simple_unop, at optabs.c:2307
--- Comment #4 from rakdver at gcc dot gnu dot org 2006-07-26 16:47 --- Subject: Bug 27907 Author: rakdver Date: Wed Jul 26 16:47:28 2006 New Revision: 115760 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115760 Log: PR rtl-optimization/27907 * expr.c (force_operand): Use convert_move to handle FLOAT_EXTEND and FLOAT_TRUNCATE. * gcc.c-torture/compile/pr27907.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr27907.c Modified: trunk/gcc/ChangeLog trunk/gcc/expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27907
[Bug target/27907] [4.2 regression] ICE in expand_simple_unop, at optabs.c:2307
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-07-26 17:02 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27907
[Bug fortran/28496] New: Error during array initialization with gfortran
When using the following test : === CODE BEGIN == ::: test.f90 ::: program test implicit none integer, dimension(3), parameter :: a=(/1,2,3/) integer, dimension(3), parameter :: b=(/4,5,6/) !integer, dimension(6), parameter :: y=(/ a(1), a(2), a(3), b(1), b(2), b(3) /) integer, dimension(6), parameter :: y=(/ a(:), b(:) /) print *, a= , a print *, b= , b print *, y= , y end === CODE END == compilation with gfortran fails whith the following message : $ gfortran test.f90 In file test.f90:9 integer, dimension(6), parameter :: y=(/ a(:), b(:) /) 1 Internal Error at (1): In file test.f90:9 integer, dimension(6), parameter :: y=(/ a(:), b(:) /) 1 Initialization expression didn't reduce (1) __ When the initialization expression is replaced by the commented way. All works properly. Did I misunderstand something ? Or this way of initializing is not supported yet ? I also tried the loop initialization way, but obtained the same message. i.e. integer, dimension(6), parameter :: y=(/ (a(i),i=1,size(a)), (b(i),i=1,size(b) /) Thanks for help -- Summary: Error during array initialization with gfortran Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: snordin_ng at yahoo dot fr GCC build triplet: x86_64-redhat-linux GCC host triplet: x86_64-redhat-linux GCC target triplet: x86_64-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28496
[Bug bootstrap/28497] New: /usr/ccs/bin/ld: Unrecognized argument: +init
It appears that GCC is assuming that the system linker can accept the +init option. In the ld(1) man page, +init appears under the heading 64 Bit (ELF) Link Editor options, and the system is 32-bit-only---might that have something to do with it? (begin build log excerpt) ranlib libbackend.a stage1/xgcc -Bstage1/ -B/opt/tg/hppa2.0w-hp-hpux11.00/bin/ -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -Wmissing-format-attribute -DHAVE_CONFIG_H -o cc1-dummy c-lang.o stub-objc.o attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o c-semantics.o c-incpath.o cppdefault.o c-ppoutput.o c-cppbuiltin.o prefix.o c-objc-common.o c-dump.o c-pch.o c-parser.o c-gimplify.o tree-mudflap.o c-pretty-print.o dummy-checksum.o \ main.o libbackend.a ../libcpp/libcpp.a ../libcpp/libcpp.a ../libiberty/libiberty.a /usr/ccs/bin/ld: (Warning) At least one PA 2.0 object file (c-lang.o) was detected. The linked output may not run on a PA 1.x system. /usr/ccs/bin/ld: Unrecognized argument: +init /usr/ccs/bin/ld: Usage: /usr/ccs/bin/ld flags... files... collect2: ld returned 1 exit status gmake[2]: *** [cc1-dummy] Error 1 gmake[2]: Leaving directory `/home/cport/tmp/gcc--4.1.1.build/gcc' gmake[1]: *** [stage2_build] Error 2 gmake[1]: Leaving directory `/home/cport/tmp/gcc--4.1.1.build/gcc' gmake: *** [bootstrap-lean] Error 2 (end build log excerpt) Output of /usr/ccs/bin/ld -V: 92453-07 linker command s800.sgs ld B.11.13 REL 990903 /usr/ccs/bin/ld: 92453-07 linker linker ld B.11.13 990903 /usr/ccs/bin/ld: Usage: /usr/ccs/bin/ld flags... files... Output of uname -a: HP-UX hrdygrdy B.11.00 A 9000/785 2003934647 two-user license -- Summary: /usr/ccs/bin/ld: Unrecognized argument: +init Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: skunk at iskunk dot org GCC build triplet: hppa2.0w-hp-hpux11.00 GCC host triplet: hppa2.0w-hp-hpux11.00 GCC target triplet: hppa2.0w-hp-hpux11.00 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28497
[Bug c++/28498] New: fstack-protector causes crash in combination with -Os
When compiling c++ code, you can get an error similar to this one: /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/../../../../include/c++/4.1.1/bits/stl_algo.h: In function '_RandomAccessIterator std::__unguarded_partition(_RandomAccessIterator, _RandomAccessIterator, _Tp) [with _RandomAccessIterator = __gnu_cxx::__normal_iteratorQRect*, std::vectorQRect, std::allocatorQRect , _Tp = QRect]': /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/../../../../include/c++/4.1.1/bits/stl_algo.h:2182: internal compiler error: Segmentation fault according to gcc -v, cc1plus was run with /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/cc1plus -quiet -v -D_GNU_SOURCE -D__PIC__ -DPIC windowgrabber.cc -fPIC -fstack-protector-all -quiet -dumpbase windowgrabber.cc -mtune=pentiumpro -auxbase windowgrabber -Os -version -fPIC -fstack-protector-all -o /tmp/cchIBKrS.s I'll attach source -- Summary: fstack-protector causes crash in combination with -Os Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: m dot b dot lankhorst at gmail dot com 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=28498
[Bug middle-end/28498] fstack-protector causes crash in combination with -Os
--- Comment #1 from m dot b dot lankhorst at gmail dot com 2006-07-26 17:42 --- Created an attachment (id=11949) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11949action=view) The source mentioned in description Source that won't compile -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28498
[Bug bootstrap/28497] /usr/ccs/bin/ld: Unrecognized argument: +init
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-26 17:42 --- I think GCC needs the GNU binutils linker now. Also how did you configure GCC? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28497
[Bug bootstrap/28497] /usr/ccs/bin/ld: Unrecognized argument: +init
--- Comment #2 from skunk at iskunk dot org 2006-07-26 17:55 --- (In reply to comment #1) I think GCC needs the GNU binutils linker now. It certainly needs the GNU assembler (explicit configure-time error to that effect), and I built binutils 2.17. That one said that (GNU) ld is not supported in this configuration... moreover, the documentation for GCC's HPPA-specific options list a few relevant to the HP linker. Also how did you configure GCC? .../configure --disable-dependency-tracking --disable-maintainer-mode --disable-shared --disable-nls --enable-version-specific-runtime-libs --with-arch=2.0 --with-gnu-as --with-as=/usr/local/bin/gnu-as --enable-languages=c,c++ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28497
[Bug c++/27668] [4.0/4.1/4.2 regression] ICE with invalid template parameter
-- lmillward at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |lmillward at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-05-26 15:06:09 |2006-07-26 18:04:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27668
[Bug bootstrap/28499] New: Bogus whitespace in preprocessor directives breaks bootstrap
The file in question here is gcc-4.1.1/gcc/tree-vectorizer.h, though I notice
there are many more instances of this issue in the GCC tree:
find gcc-4.1.1 -name '*.[ch]' -exec pcregrep
'^\s+#\s*(define|undef|if|endif)' {} \; | wc -l
326
(same command, but with pcregrep -l)
62
I know that the topic of whitespace before the # has been discussed here
before, that the applicable standards allow it and compilers that don't are
broken, etc. ... but I do believe the bootstrapping process, by its nature, has
to accomodate quirks such as these.
(begin build log excerpt)
make[2]: Entering directory `/usr/home/cport/tmp/gcc--4.1.1.build/gcc'
cc -c -g -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING -DIN_GCC
-DHAVE_CONFIG_H -I. -I. -I/tg/freeport/src/gcc/gcc--4.1.1/gcc
-I/tg/freeport/src/gcc/gcc--4.1.1/gcc/.
-I/tg/freeport/src/gcc/gcc--4.1.1/gcc/../include
-I/tg/freeport/src/gcc/gcc--4.1.1/gcc/../libcpp/include
/tg/freeport/src/gcc/gcc--4.1.1/gcc/tree-vectorizer.c -o tree-vectorizer.o
cc: Warning: /tg/freeport/src/gcc/gcc--4.1.1/gcc/tree-vectorizer.h, line 33: #
not in column 1 is ignored, skipping to end of line. (ignoretokens)
#define UNKNOWN_LOC NULL
--^
cc: Warning: /tg/freeport/src/gcc/gcc--4.1.1/gcc/tree-vectorizer.h, line 34: #
not in column 1 is ignored, skipping to end of line. (ignoretokens)
#define EXPR_LOC(e) EXPR_LOCUS(e)
--^
cc: Warning: /tg/freeport/src/gcc/gcc--4.1.1/gcc/tree-vectorizer.h, line 35: #
not in column 1 is ignored, skipping to end of line. (ignoretokens)
#define LOC_FILE(l) (l)-file
--^
cc: Warning: /tg/freeport/src/gcc/gcc--4.1.1/gcc/tree-vectorizer.h, line 36: #
not in column 1 is ignored, skipping to end of line. (ignoretokens)
#define LOC_LINE(l) (l)-line
--^
cc: Error: /tg/freeport/src/gcc/gcc--4.1.1/gcc/tree-vectorizer.c, line 813: In
this statement, UNKNOWN_LOC is not declared. (undeclared)
if (loop_loc != UNKNOWN_LOC)
--^
cc: Error: /tg/freeport/src/gcc/gcc--4.1.1/gcc/tree-vectorizer.c, line 1112: In
this statement, UNKNOWN_LOC is not declared. (undeclared)
if (loop_loc != UNKNOWN_LOC)
--^
cc: Error: /tg/freeport/src/gcc/gcc--4.1.1/gcc/tree-vectorizer.c, line 1236: In
this statement, UNKNOWN_LOC is not declared. (undeclared)
return UNKNOWN_LOC;
---^
cc: Warning: /tg/freeport/src/gcc/gcc--4.1.1/gcc/tree-vectorizer.c, line 1242:
In this statement, EXPR_LOC(...) of type int, is being converted to
pointer to struct location_s. (cvtdiftypes)
return EXPR_LOC (node);
---^
cc: Warning: /tg/freeport/src/gcc/gcc--4.1.1/gcc/tree-vectorizer.c, line 1256:
In this statement, EXPR_LOC(...) of type int, is being converted to
pointer to struct location_s. (cvtdiftypes)
return EXPR_LOC (node);
---^
cc: Error: /tg/freeport/src/gcc/gcc--4.1.1/gcc/tree-vectorizer.c, line 1330: In
this statement, UNKNOWN_LOC is not declared. (undeclared)
if (vect_loop_location == UNKNOWN_LOC)
^
make[2]: *** [tree-vectorizer.o] Error 1
make[2]: Leaving directory `/usr/home/cport/tmp/gcc--4.1.1.build/gcc'
make[1]: *** [stage1_build] Error 2
make[1]: Leaving directory `/usr/home/cport/tmp/gcc--4.1.1.build/gcc'
make: *** [bootstrap-lean] Error 2
(end build log excerpt)
--
Summary: Bogus whitespace in preprocessor directives breaks
bootstrap
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: skunk at iskunk dot org
GCC build triplet: alphaev56-dec-osf4.0g
GCC host triplet: alphaev56-dec-osf4.0g
GCC target triplet: alphaev56-dec-osf4.0g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28499
[Bug bootstrap/28499] Bogus whitespace in preprocessor directives breaks bootstrap
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-26 18:23 --- Your compiler is not ANSI/ISO C complaint. And in GCC 4.1.0 and above (maybe it was 4.0.0), we require an ISO C90 compiler which this is valid ISO C90. -- 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=28499
[Bug bootstrap/28499] Bogus whitespace in preprocessor directives breaks bootstrap
--- Comment #2 from skunk at iskunk dot org 2006-07-26 18:36 --- I was under the impression that the bootstrapping process would first build an intermediate compiler, itself written in a safe subset of C, that would then build the full GCC, which could use modern features as needed. Was it decided to no longer support bootstrapping on systems with dumb C compilers? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28499
[Bug boehm-gc/25652] Java support for amd64-pc-freebsd
--- Comment #5 from arno at heho dot snv dot jussieu dot fr 2006-07-26 18:36 --- Created an attachment (id=11950) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11950action=view) take-II this one works at -head as well Bon, apparently I'm (almost) the only one who uses gcj on freebsd-amd64, but here's another patch; the basic differences with the first one are removal of unneeded diffs (apart non-tested gcconfig.h support for freebsd-[arm|powerpc]) and explicitly using FREEBSD_STACKBOTTOM as well as GC_FreeBSDGetDataStart(). === libjava Summary === # of expected passes6887 # of unexpected failures21 # of expected failures 12 # of untested testcases 28 Failures are : FAIL: PR16923.c FAIL: PR27908 FAIL: Throw_2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25652
[Bug c/28500] New: DBL_RADIX missing
$ cat radix.c
#include stdio.h
#include float.h
int main()
{
printf(FLT_RADIX = %i\n,FLT_RADIX);
printf(DBL_RADIX = %i\n,DBL_RADIX);
return 0;
}
$ gcc radix.c
radix.c: In function 'main':
radix.c:7: error: 'DBL_RADIX' undeclared (first use in this function)
radix.c:7: error: (Each undeclared identifier is reported only once
radix.c:7: error: for each function it appears in.)
$ gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../../gcc/trunk/configure --prefix=/home/ig25
--enable-languages=c,fortran
Thread model: posix
gcc version 4.2.0 20060723 (experimental)
--
Summary: DBL_RADIX missing
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tkoenig at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28500
[Bug c/28500] DBL_RADIX missing
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-26 18:50 --- only FLT_RADIX exists in the C99 standard. -- 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=28500
[Bug c/28500] DBL_RADIX missing
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-07-26 18:52 --- FLT_RADIX is for all of float, double and long double. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28500
[Bug bootstrap/28499] Bogus whitespace in preprocessor directives breaks bootstrap
--- Comment #3 from skunk at iskunk dot org 2006-07-26 19:00 --- I'm sorry; I meant to write Why was it decided to...? What strikes me as odd about this, moreover, is that the incompatibility appears gratuitous; the extra whitespace doesn't help anything. Is this a case of wanting to (eventually) use modern C features in the intermediate compiler? More importantly, what is the support status for systems like the one in question? Is it to build 3.4.x first, and then use that to build 4.x? Or is 4.x not intended to support it at all, hacks notwithstanding? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28499
[Bug bootstrap/28499] Bogus whitespace in preprocessor directives breaks bootstrap
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-07-26 19:02 --- (In reply to comment #3) What strikes me as odd about this, moreover, is that the incompatibility appears gratuitous; the extra whitespace doesn't help anything. Is this a case of wanting to (eventually) use modern C features in the intermediate compiler? Modern C as in 15 years is a joke. 15 years is enough for vendors to provide a new C compiler. More importantly, what is the support status for systems like the one in question? Is it to build 3.4.x first, and then use that to build 4.x? Or is 4.x not intended to support it at all, hacks notwithstanding? Build 3.4.x first. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28499
[Bug fortran/28496] Error during array initialization with gfortran
--- Comment #1 from kargl at gcc dot gnu dot org 2006-07-26 19:15 --- First, you'll want to upgrade to at least 4.1.1 form 4.0.2. Second, yes, it appears to be a bug. These lines work as expected. integer, dimension(6), parameter :: y=(/ a(1:3), b(1:3) /) integer, dimension(6), parameter :: y=(/ a, b /) It appears the (:) in a(:) and b(:) is not handled correctly. I haven't looked into the implicit do loop method. -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||kargl at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28496
[Bug tree-optimization/28364] poor optimization choices when iterating over a std::string (probably not c++-specific)
--- Comment #27 from rakdver at gcc dot gnu dot org 2006-07-26 19:38 --- Patch for the wrong choice of induction variable: http://gcc.gnu.org/ml/gcc-patches/2006-07/msg01125.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28364
[Bug libfortran/28452] __gfortran_random_r10 not found
--- Comment #7 from tkoenig at gcc dot gnu dot org 2006-07-26 19:49 --- Created an attachment (id=11951) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11951action=view) Current status of patch Here's the current patch. It regtests fine, and seems to do the Right Thing. I haven't been able to test it on a system with REAL(16), nor on an S/360 where FLT_RADIX == 16. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Attachment #11929|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28452
[Bug fortran/28496] Error during array initialization
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-07-26 19:52 --- gfortran 4.0 series is seriously broken and shouldn't be considered for production use. Indeed, your testcase and variations work with the gfortran 4.2 branch, except for the following: $ cat a.f90 integer, dimension(3), parameter :: a=(/1,2,3/) integer, dimension(3), parameter :: b=(/a(:)/) end $ gfortran a.f90 a.f90:0: internal compiler error: Segmentation fault which is an ICE. Removing the (:) makes it work. The backtrace for the ICE is: Program received signal SIGSEGV, Segmentation fault. 0xb7ee5473 in __gmpz_set () from /usr/lib/libgmp.so.3 (gdb) where #0 0xb7ee5473 in __gmpz_set () from /usr/lib/libgmp.so.3 #1 0x08061c04 in simplify_const_ref (p=0x8729548) at ../../../trunk/gcc/fortran/expr.c:1089 #2 0x0806260d in gfc_simplify_expr (p=0x8729548, type=1) at ../../../trunk/gcc/fortran/expr.c:1499 #3 0x08062bb4 in simplify_parameter_variable (p=0x8729420, type=1) at ../../../trunk/gcc/fortran/expr.c:1374 #4 0x080625ee in gfc_simplify_expr (p=0x8729420, type=1) at ../../../trunk/gcc/fortran/expr.c:1470 #5 0x0804f4da in expand_constructor (c=0x8728c68) at ../../../trunk/gcc/fortran/array.c:1375 #6 0x0804f66b in gfc_array_size (array=0x87293c8, result=0xbf919208) at ../../../trunk/gcc/fortran/array.c:1968 #7 0x0808d4ff in expression_rank (e=0x87293c8) at ../../../trunk/gcc/fortran/resolve.c:2798 #8 0x0808e7f8 in gfc_resolve_expr (e=0x87293c8) at ../../../trunk/gcc/fortran/resolve.c:3026 #9 0x08062e16 in gfc_match_init_expr (result=0xbf919444) at ../../../trunk/gcc/fortran/expr.c:1843 #10 0x0805b49a in variable_decl (elem=Variable elem is not available. ) at ../../../trunk/gcc/fortran/decl.c:1268 #11 0x0805ba4a in gfc_match_data_decl () at ../../../trunk/gcc/fortran/decl.c:2316 #12 0x08084b0a in match_word (str=Variable str is not available. ) at ../../../trunk/gcc/fortran/parse.c:65 #13 0x080850ad in decode_statement () at ../../../trunk/gcc/fortran/parse.c:134 #14 0x08085a3e in next_statement () at ../../../trunk/gcc/fortran/parse.c:493 #15 0x080876ec in parse_spec (st=ST_DATA_DECL) at ../../../trunk/gcc/fortran/parse.c:1870 #16 0x08087c09 in parse_progunit (st=Variable st is not available. ) at ../../../trunk/gcc/fortran/parse.c:2870 #17 0x080880d1 in gfc_parse_file () at ../../../trunk/gcc/fortran/parse.c:3206 #18 0x080a91fd in gfc_be_parse_file (set_yydebug=0) at ../../../trunk/gcc/fortran/f95-lang.c:303 #19 0x0839d14a in toplev_main (argc=13, argv=0xbf919744) at ../../../trunk/gcc/toplev.c:999 #20 0x080dcd6f in main (argc=1, argv=0x1) at ../../../trunk/gcc/main.c:35 -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Severity|blocker |major Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|x86_64-redhat-linux | GCC host triplet|x86_64-redhat-linux | GCC target triplet|x86_64-redhat-linux | Last reconfirmed|-00-00 00:00:00 |2006-07-26 19:52:36 date|| Summary|Error during array |Error during array |initialization with gfortran|initialization Version|4.0.2 |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28496
[Bug bootstrap/28499] Bogus whitespace in preprocessor directives breaks bootstrap
--- Comment #5 from skunk at iskunk dot org 2006-07-26 19:53 --- (In reply to comment #4) Modern C as in 15 years is a joke. 15 years is enough for vendors to provide a new C compiler. Sometimes, you can't get a newer version (e.g. licensing issues). Sometimes, you don't want to (e.g. backward compatibility problems). I can't imagine why plain ANSI C89 wasn't good enough for the intermediate compiler. Whatever newer features were desired, they can't have been worth breaking the bootstrap process for older systems. (I'd have been more inclined to agree if the change was to drop KR compatibility, though even then there would have been a good argument against. And there's always ansi2knr and other workarounds.) Build 3.4.x first. A six-stage bootstrap, then... I'll do that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28499
[Bug bootstrap/28499] Bogus whitespace in preprocessor directives breaks bootstrap
--- Comment #6 from schwab at suse dot de 2006-07-26 20:03 --- This _is_ plain ANSI C89. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28499
[Bug tree-optimization/27742] [4.2 regression] ICE with -ftree-vectorizer-verbose
--- Comment #8 from reichelt at gcc dot gnu dot org 2006-07-26 20:08
---
Here's a reduced testcase:
Compile (on x86_64-unknown-linux-gnu) with:
g++ -O -ftree-vectorize -ftree-vectorizer-verbose=1 --param ggc-min-expand=0
--param ggc-min-heapsize=0
On i686-pc-linux-gnu you'll probably have to add -march=pentium4 or so.
void foo() {}
void bar(int *p)
{
for (int i = 0; i 4; i++)
p[i] = 0;
}
inline void baz(int i)
{
while (i) ++i;
}
struct A
{
A() { baz(3); }
};
A a, b;
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27742
[Bug tree-optimization/27882] [4.1/4.2 regression] segfault in ipa-inline.c, if (e-callee-local.disregard_inline_limits
--- Comment #28 from hubicka at gcc dot gnu dot org 2006-07-26 20:17 --- Subject: Bug 27882 Author: hubicka Date: Wed Jul 26 20:17:32 2006 New Revision: 115763 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115763 Log: PR tree-optimization/27882 * cgraph.c (cgraph_remove_node): Clear needed, reachable, next, previous and decl fields. * cgraphunit.c (cgraph_reset_node): Expect cgraph_remove_node to kill next pointer (cgraph_analyze_compilation_unit): Likewise. * ipa.c (cgraph_remove_unreachable_nodes): Likewise. * ipa-inline.c (cgraph_decide_recursive_inlining): Likewise. (cgraph_early_inlinine): Make order garbage collected. * Makefile.in (gt-ipa-inline): New garbagecollected file. Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/cgraph.c trunk/gcc/cgraphunit.c trunk/gcc/ipa-inline.c trunk/gcc/ipa.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27882
[Bug target/28170] [4.1 Regression] Wrong result after swap byte in one word when compiled in 64-bit mode
--- Comment #16 from dje at gcc dot gnu dot org 2006-07-26 20:22 ---
Subject: Bug 28170
Author: dje
Date: Wed Jul 26 20:21:49 2006
New Revision: 115764
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115764
Log:
Backport from mainline
2006-07-14 Eliot Dresselhaus [EMAIL PROTECTED]
PR target/27287
* config/rs6000/spe.md (frob_di_df_2): Add m-r alternative.
2006-07-06 David Edelsohn [EMAIL PROTECTED]
PR target/28150
* config/rs6000/rs6000.c (rs6000_legitimate_address): Do not allow
PRE_{INC,DEC} of TFmode.
2006-07-06 David Edelsohn [EMAIL PROTECTED]
Alan Modra [EMAIL PROTECTED]
PR target/28170
* config/rs6000/rs6000.c (insvdi_rshift_rlwimi_p): Correct shiftop
bounds. Simplify.
Modified:
branches/gcc-4_1-branch/gcc/ChangeLog
branches/gcc-4_1-branch/gcc/config/rs6000/rs6000.c
branches/gcc-4_1-branch/gcc/config/rs6000/spe.md
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28170
[Bug target/28150] ICE in reload_cse_simplify_operands, at postreload.c:394
--- Comment #9 from dje at gcc dot gnu dot org 2006-07-26 20:22 ---
Subject: Bug 28150
Author: dje
Date: Wed Jul 26 20:21:49 2006
New Revision: 115764
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115764
Log:
Backport from mainline
2006-07-14 Eliot Dresselhaus [EMAIL PROTECTED]
PR target/27287
* config/rs6000/spe.md (frob_di_df_2): Add m-r alternative.
2006-07-06 David Edelsohn [EMAIL PROTECTED]
PR target/28150
* config/rs6000/rs6000.c (rs6000_legitimate_address): Do not allow
PRE_{INC,DEC} of TFmode.
2006-07-06 David Edelsohn [EMAIL PROTECTED]
Alan Modra [EMAIL PROTECTED]
PR target/28170
* config/rs6000/rs6000.c (insvdi_rshift_rlwimi_p): Correct shiftop
bounds. Simplify.
Modified:
branches/gcc-4_1-branch/gcc/ChangeLog
branches/gcc-4_1-branch/gcc/config/rs6000/rs6000.c
branches/gcc-4_1-branch/gcc/config/rs6000/spe.md
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28150
[Bug target/27287] [4.1 Regression] returning constant double
--- Comment #19 from dje at gcc dot gnu dot org 2006-07-26 20:22 ---
Subject: Bug 27287
Author: dje
Date: Wed Jul 26 20:21:49 2006
New Revision: 115764
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115764
Log:
Backport from mainline
2006-07-14 Eliot Dresselhaus [EMAIL PROTECTED]
PR target/27287
* config/rs6000/spe.md (frob_di_df_2): Add m-r alternative.
2006-07-06 David Edelsohn [EMAIL PROTECTED]
PR target/28150
* config/rs6000/rs6000.c (rs6000_legitimate_address): Do not allow
PRE_{INC,DEC} of TFmode.
2006-07-06 David Edelsohn [EMAIL PROTECTED]
Alan Modra [EMAIL PROTECTED]
PR target/28170
* config/rs6000/rs6000.c (insvdi_rshift_rlwimi_p): Correct shiftop
bounds. Simplify.
Modified:
branches/gcc-4_1-branch/gcc/ChangeLog
branches/gcc-4_1-branch/gcc/config/rs6000/rs6000.c
branches/gcc-4_1-branch/gcc/config/rs6000/spe.md
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27287
[Bug target/27287] [4.1 Regression] returning constant double
--- Comment #20 from dje at gcc dot gnu dot org 2006-07-26 20:25 --- patch backported -- dje at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27287
[Bug target/28150] ICE in reload_cse_simplify_operands, at postreload.c:394
--- Comment #10 from dje at gcc dot gnu dot org 2006-07-26 20:26 --- patch backported -- dje at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28150
[Bug target/28170] [4.1 Regression] Wrong result after swap byte in one word when compiled in 64-bit mode
--- Comment #17 from dje at gcc dot gnu dot org 2006-07-26 20:27 --- patch backported -- dje at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28170
[Bug c++/28501] New: ICE with __real__ and implicit type conversion
The following testcase triggers an ICE since at least GCC 2.95.3:
=
struct A
{
operator int();
};
int i = __real__ A();
=
bug.cc:6: internal compiler error: in add_builtin_candidate, at cp/call.c:1979
Please submit a full bug report, [etc.]
The code is probably invalid, but I'm not sure.
--
Summary: ICE with __real__ and implicit type conversion
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28501
[Bug c/28502] New: ICE with invalid declaration after definition
The following testcase triggers an ICE since at least GCC 2.95.3:
=
void foo() {}
void foo(void[]);
=
bug.c:2: error: declaration of 'type name' as array of voids
bug.c:2: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in validate_proto_after_old_defn, at c-decl.c:1087
Please submit a full bug report, [etc.]
Will post a patch soon.
--
Summary: ICE with invalid declaration after definition
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28502
[Bug c/28503] New: ICE on invalid arguments for inline-asm
The following testcase triggers an ICE since at least GCC 2.95.3:
=
void i;
void foo()
{
__asm__ ( : +r (i));
}
=
bug.c: In function 'foo':
bug.c:5: internal compiler error: in gimplify_expr, at gimplify.c:5902
Please submit a full bug report, [etc.]
The C++ frontend emits a proper error message.
--
Summary: ICE on invalid arguments for inline-asm
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, monitored
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28503
[Bug bootstrap/28499] Bogus whitespace in preprocessor directives breaks bootstrap
--- Comment #7 from skunk at iskunk dot org 2006-07-26 20:57 --- (In reply to comment #6) This _is_ plain ANSI C89. ISO C90 was specified. Yes, my bad, ANSI does allow whitespace before the #---but what of it? It's good practice anyhow to place the mark first, and the Tru64 compiler isn't exactly alone in enforcing this convention. (Is there _any_ good reason for having the whitespace? I don't mean a defense of but the standard allows it, your compiler sucks---I mean, a hard, technical reason for doing it that way instead of placing the # first?) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28499
[Bug target/28490] [4.2 regression] ICE in ia64_expand_move, at config/ia64/ia64.c:1088
--- Comment #6 from tbm at cyrius dot com 2006-07-26 20:58 --- Created an attachment (id=11952) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11952action=view) test case Testcase from application yorick. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28490
Re: [Bug bootstrap/28499] Bogus whitespace in preprocessor directives breaks bootstrap
--- Comment #7 from skunk at iskunk dot org 2006-07-26 20:57 --- (In reply to comment #6) This _is_ plain ANSI C89. ISO C90 was specified. Yes, my bad, ANSI does allow whitespace before the #---but what of it? It's good practice anyhow to place the mark first, and the Tru64 compiler isn't exactly alone in enforcing this convention. ISO C90 is ANSI C89 :). -- Pinski
[Bug bootstrap/28499] Bogus whitespace in preprocessor directives breaks bootstrap
--- Comment #8 from pinskia at physics dot uc dot edu 2006-07-26 20:59 --- Subject: Re: Bogus whitespace in preprocessor directives breaks bootstrap --- Comment #7 from skunk at iskunk dot org 2006-07-26 20:57 --- (In reply to comment #6) This _is_ plain ANSI C89. ISO C90 was specified. Yes, my bad, ANSI does allow whitespace before the #---but what of it? It's good practice anyhow to place the mark first, and the Tru64 compiler isn't exactly alone in enforcing this convention. ISO C90 is ANSI C89 :). -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28499
[Bug c/28504] New: [4.0/4.1/4.2 regression] ICE with variable sized array
The following testcase triggers an ICE since GCC 4.0.0:
==
void foo(void (*p)(int n, int x[n])) {}
==
bug.c: In function 'foo':
bug.c:1: internal compiler error: in make_decl_rtl, at varasm.c:1005
Please submit a full bug report, [etc.]
I'm not sure whether the code is invalid as an extension or not.
void bar(int n, int x[n]) {}
is accepted as well as
void foo(void (*p)(int n, int x[n]));
The C++ frontend rejects it, see also
http://gcc.gnu.org/ml/gcc/2006-07/msg00479.html
--
Summary: [4.0/4.1/4.2 regression] ICE with variable sized array
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, monitored
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28504
[Bug c++/28505] New: [4.0/4.1/4.2 regression] ICE with invalid constructors
The following invalid code snippet triggers an ICE since GCC 3.4.0:
=
struct A
{
A : ();
A : (int);
};
A a = (A){0};
=
bug.cc:3: error: expected primary-expression before ')' token
bug.cc:3: error: name 'A' has incomplete type
bug.cc:4: error: expected primary-expression before 'int'
bug.cc:4: error: expected `)' before 'int'
bug.cc:4: error: name 'A' has incomplete type
bug.cc:7: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in process_init_constructor_record, at
cp/typeck2.c:911
Please submit a full bug report, [etc.]
--
Summary: [4.0/4.1/4.2 regression] ICE with invalid constructors
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28505
[Bug c++/28505] [4.0/4.1/4.2 regression] ICE with invalid constructors
--- Comment #1 from reichelt at gcc dot gnu dot org 2006-07-26 21:35
---
A similar testcase crashes in a different position:
==
struct A
{
A : ();
A : (int);
};
struct B
{
char c;
A a;
};
B b = (B){0};
==
On mainline it causes a segfault, on the 4.1 branch an ICE in
count_type_elements, at expr.c:4647
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.0.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28505
[Bug c++/28506] New: [4.0/4.1/4.2 regression] ICE with initializers for functions
The following code snippet causes an ICE since GCC 4.0.0:
struct A
{
virtual void* foo() = 1;
};
bug.cc:3: internal compiler error: in grokfield, at cp/decl2.c:850
Please submit a full bug report, [etc.]
A similar code snippet causes an ICE in the same place since GCC 4.1.1:
struct A
{
void operator()()() = 1;
};
bug.cc:3: error: 'operator()' declared as function returning a function
bug.cc:3: internal compiler error: in grokfield, at cp/decl2.c:850
Please submit a full bug report, [etc.]
The 4.1.1 regression in probably fallout from PR 26122.
--
Summary: [4.0/4.1/4.2 regression] ICE with initializers for
functions
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
BugsThisDependsOn: 26122
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28506
[Bug target/28495] [4.2 regression] ICE in final_scan_insn, at final.c:2448
--- Comment #4 from schwab at suse dot de 2006-07-26 21:47 --- Broken since r111459: 2006-02-26 Steven Bosscher [EMAIL PROTECTED] * common.opt (-floop-optimize, -frerun-loop-opt): Remove. * tree-pass.h (pass_loop_optimize): Remove. * passes.c (pass_loop_optimize): Never run it. * toplev.c (backend_init): Don't call init_loop. * opts.c (flag_loop_optimize_set): Remove. (decode_options): Never set flag_loop_optimize or flag_rerun_loop_opt. (common_handle_option) OPT_floop_optimize: Remove. Don't disable the old RTL loop optimizer when profiling enabled. * predict.c (tree_estimate_probability): Always strip builtin_expect. * cfgcleanup.c (try_forward_edges): Don't avoid killing loop pre-headers for the sake of the old RTL loop optimizer. * Makefile.in: Remove all references to loop.o. * doc/invoke.texi: Remove all references to -floop-optimize and -frerun-loop-opt. -- schwab at suse dot de changed: What|Removed |Added CC||steven at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-07-26 21:47:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28495
[Bug target/28495] [4.2 regression] ICE in final_scan_insn, at final.c:2448
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-07-26 21:54 --- (In reply to comment #4) Broken since r111459: That would mean it was a latent bug. In fact you can most likely reproduce the failure with -fno-loop-optimize. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28495
[Bug c++/27962] [4.0/4.1 regression] ICE with invalid template parameter in specialization
-- lmillward at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |lmillward at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-06-16 23:02:33 |2006-07-26 22:31:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27962
[Bug rtl-optimization/28071] [4.1/4.2 regression] A file that can not be compiled in reasonable time/space
--- Comment #23 from hubicka at gcc dot gnu dot org 2006-07-26 22:52 --- Subject: Bug 28071 Author: hubicka Date: Wed Jul 26 22:51:56 2006 New Revision: 115765 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115765 Log: PR rtl-optimization/28071 * regmove.c (reg_is_remote_constant_p): Avoid quadratic behaviour. (reg_set_in_bb, max_reg_computed): New static variables. (regmove_optimize): Free the new array. (fixup_match_1): Update call of reg_is_remote_constant_p. Modified: trunk/gcc/ChangeLog trunk/gcc/regmove.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28071
[Bug c/28502] ICE with invalid declaration after definition
--- Comment #1 from patchapp at dberlin dot org 2006-07-26 23:35 --- Subject: Bug number PR c/28502 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-07/msg01128.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28502
[Bug c++/27668] [4.0/4.1/4.2 regression] ICE with invalid template parameter
--- Comment #3 from patchapp at dberlin dot org 2006-07-26 23:35 --- Subject: Bug number PR c++/27668 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-07/msg01130.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27668
[Bug c++/28507] New: can't getline with basic_ifstream unsigned char
I haven't had much experience with basic_ifstream, so please forgive me if this
is expected gcc behavior.
Observed behavior:
getline on an instance of basic_ifstream unsigned char fails to copy a line
of the source file to the buffer.
Expected behavior:
basic_ifstream unsigned char getline should work just like basic_ifstream
char 's getline (except for the difference in buffer character types).
Please save the example as main.cpp and just g++ main.cpp and execute ./a.out.
Here's the code example:
#include fstream
#include iostream
int main ( int argC, char ** const argV )
{
std::cout file content with std::basic_ifstream char, std::char_traits
char :\n std::endl;
std::basic_ifstream char, std::char_traits char source( main.cpp,
std::ios_base::in | std::ios_base::binary );
char buffer[ 8096 ] = {0};
while( source.getline( buffer, sizeof( buffer ), '\n' ) )
{
std::cout buffer std::endl;
}
source.close();
std::cout \n...END basic_ifstream char FILE...\n std::endl;
std::cout file content with std::basic_ifstream unsigned char,
std::char_traits unsigned char :\n std::endl;
std::basic_ifstream unsigned char, std::char_traits unsigned char
uchar_source( main.cpp, std::ios_base::in | std::ios_base::binary );
unsigned char uchar_buffer[ 8096 ] = {0};
while( uchar_source.getline( uchar_buffer, sizeof( uchar_buffer ), '\n' ) )
{
std::cout uchar_buffer std::endl;
}
uchar_source.close();
std::cout \n...END basic_ifstream unsigned char FILE...\n
std::endl;
return 0;
}
I reproduced this behavior on a mac-mini OSX 10.4.7 with an intel processor
(gcc V 4.0.1) and also with an older intel freebsd box (gcc V 3.4.4).
--
Summary: can't getline with basic_ifstream unsigned char
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: antonw03 at yahoo dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28507
[Bug fortran/28335] [4.1 only] flush() / write() statement on closed units - error?
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2006-07-27 01:01 --- OK , simple enough. Will do shortly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28335
[Bug c/28508] New: Assembler Error: operand out of ragne (145 not between -128 and 127) form m32r-target
e have often gotten the following assembler error with -g option since m32r-linux-gnu-gcc-4.0 released. /tmp/cch1oLgA.s: Assembler messages: /tmp/cch1oLgA.s:2591: Error: operand out of range (145 not between -128 and 127)/tmp/cch1oLgA.s:3358: Error: operand out of range (145 not between -128 and 127)/tmp/cch1oLgA.s:5195: Error: operand out of range (-130 not between -128 and 127) We have been using DWARF2 since gcc-4.0. It creates many local label symbols and makes pnop codes for code aligments. We have no idia to avoid this error on compiling. So we propose to change the range for using short bransh format code. -- Summary: Assembler Error: operand out of ragne (145 not between - 128 and 127) form m32r-target Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: inaoka dot kazuhiro at renesas dot com GCC target triplet: m32r http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28508
[Bug c/28508] Assembler Error: operand out of ragne (145 not between -128 and 127) form m32r-target
--- Comment #1 from inaoka dot kazuhiro at renesas dot com 2006-07-27 01:48 --- Created an attachment (id=11953) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11953action=view) test case bc.s and bnc.s have the range (form -512 to 508) of PC-relative. If all 2byte instruction have alignment code (pnop)of debug information, we must use 254/508. But it's rare case. FAIL Sample m32r-linux-gnu-gcc -S -g -O2 -o line_test.s.ng line_test.c /tmp/ccHkZoqt.s: Assembler messages: /tmp/ccHkZoqt.s:22: Error: operand out of range (198 not between -128 and 127) PASS Sample without -g option m32r-linux-gnu-gcc -S -O2 -o line_test.s line_test.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28508
[Bug c/28508] Assembler Error: operand out of ragne (145 not between -128 and 127) form m32r-target
--- Comment #2 from inaoka dot kazuhiro at renesas dot com 2006-07-27 01:52 --- Created an attachment (id=11954) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11954action=view) workaround patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28508
[Bug libstdc++/28507] can't getline with basic_ifstream unsigned char
--- Comment #1 from pcarlini at suse dot de 2006-07-27 01:53 --- This is a well known source of puzzlement. The point is that, according to the C++ standard, the external (on disk) representation is in any case made of *chars*. Therefore, in general, conversions from/to that representation to an internal representation (unsigned chars, in this PR, or int, or anything else) must be carried out by an appropriate codecvt locale facet. Versions of it for pairs of internal, external types char, char and wchar_t, char are provided in the library, anything else must be explicitely provided by the user, because in general a mapping for unsigned char, char is not portable, changes from system to system (at variance, e.g., with an identity mapping for char, char or a standardized mapping for wchar_t, char such as UTF-8). -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28507
[Bug target/28493] Wrong address of stack object used for destructor call on PPC
--- Comment #2 from atgraham at gmail dot com 2006-07-27 02:47 --- This bug appears to only happen when the compiler is built with SjLj exceptions. When the compiler is built for dwarf2 exceptions, this test case (and my original problem area) are both correct: tryfunc(): 0: 94 21 ff d0 stwur1,-48(r1) 4: 7c 08 02 a6 mflrr0 8: 38 61 00 08 addir3,r1,8 c: 90 01 00 34 stw r0,52(r1) 10: bf a1 00 24 stmwr29,36(r1) 14: 48 00 00 01 bl 14 tryfunc()+0x14 14: R_PPC_REL24 Command::Command() 18: 38 60 00 04 li r3,4 1c: 48 00 00 01 bl 1c tryfunc()+0x1c 1c: R_PPC_REL24 __cxa_allocate_exception 20: 38 00 00 01 li r0,1 24: 3c 80 00 00 lis r4,0 26: R_PPC_ADDR16_HA typeinfo for int 28: 90 03 00 00 stw r0,0(r3) 2c: 38 84 00 00 addir4,r4,0 2e: R_PPC_ADDR16_LO typeinfo for int 30: 38 a0 00 00 li r5,0 34: 48 00 00 01 bl 34 tryfunc()+0x34 34: R_PPC_REL24 __cxa_throw 38: 7c 7d 1b 78 mr r29,r3 3c: 38 61 00 08 addir3,r1,8 40: 48 00 00 01 bl 40 tryfunc()+0x40 40: R_PPC_REL24 Command::~Command() 44: 7f a3 eb 78 mr r3,r29 48: 48 00 00 01 bl 48 tryfunc()+0x48 48: R_PPC_REL24 _Unwind_Resume -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28493
[Bug c++/28506] [4.0/4.1/4.2 regression] ICE with initializers for functions
-- 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=28506
