[Bug middle-end/21538] [4.0/4.1 Regression] g++.dg/opt/temp1.C execution test fails
--- Additional Comments From mark at codesourcery dot com 2005-05-13 06:18 --- Subject: Re: [4.0/4.1 Regression] g++.dg/opt/temp1.C execution test fails pinskia at gcc dot gnu dot org wrote: > --- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-12 > 21:59 --- > Confirmed, though I think the testcase is wrong though if we use memcpy > before main. Why do you think that's wrong? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21538
[Bug bootstrap/21542] gcc 4.0.0 assumes all i386-pc-solaris2.10 platforms have 64-bit processors
--- Additional Comments From Daniel dot Davies at xerox dot com 2005-05-13 02:27 --- Created an attachment (id=8883) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8883&action=view) libcpp configuration file Detects 32-bit processors running Solaris 2.10 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21542
[Bug bootstrap/21542] gcc 4.0.0 assumes all i386-pc-solaris2.10 platforms have 64-bit processors
--- Additional Comments From Daniel dot Davies at xerox dot com 2005-05-13 02:25 --- Created an attachment (id=8882) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8882&action=view) GCC configuration file Modified to detect 32-bit processors running Solaris 2.10 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21542
[Bug bootstrap/21542] New: gcc 4.0.0 assumes all i386-pc-solaris2.10 platforms have 64-bit processors
I've been trying to build GCC 4.0.0 on an ordinary Intel PC running Solaris
2.10. The base compiler is gcc3.4.2 from Sun's Companion CD. I'm using
binutils-2.16 and fetched bison 2.0 (though that probably wasn't necessary).
GCC 4.0.0 assumes all i386-pc-solaris2.10 boxes have 64-bit processors. The
problems occur when you try to build libcpp. First, you get problems because
the new xgcc generates 64-bit opcodes which the assembler can't assemble and a
Pentium can't execute. Once you fix that, you have very odd problems in which
the new xgcc thinks all bitfield lengths equal to 0.
This problem arises because uname won't tell you whether the current platform
has a 32-bit or 64-bit processor. isalist can (sort of) in that it lists
"amd64" as one of the instruction sets supported when running on 64-bit
platforms. The modifications shown below should probably look for instruction
sets other than "amd64". I have not tested the fix described below on a real
64-bit platform because I don't have one. I found out about "amd64" by asking a
friend what happened when he typed "isalist" on his 64-bit Solaris box.
I only compiled gcc-core and gcc-g++. I don't know if there are similar
problems with the other members of the compiler suite.
I had to make the following changes to make things work:
1. Modify gcc-4.0.0/gcc/config.gcc
I changed
case ${target} in
*-*-solaris2.1[0-9]*)
tm_file="${tm_file} i386/x86-64.h i386/sol2-10.h"
tm_defines="${tm_defines} TARGET_BI_ARCH=1"
tmake_file="$tmake_file i386/t-sol2-10"
need_64bit_hwint=yes
# Solaris 2.10 provides crt1.o, crti.o, crtn.o, and gcrt1.o as
# part of the base system.
extra_parts="gmon.o crtbegin.o crtend.o"
;;
*)
extra_parts="crt1.o crti.o crtn.o gcrt1.o gmon.o crtbegin.o
crtend.o"
;;
to
case ${target} in
*-*-solaris2.1[0-9]*)
# If this is a 32-bit platform, i.e. does not execute the
# amd64 instruction set, do not include the 64-bit extensions.
case `isalist | grep -c amd64` in
0)
tm_file="${tm_file} i386/sol2-10.h"
tmake_file="$tmake_file i386/t-sol2-10-32"
;;
1)
tm_file="${tm_file} i386/x86-64.h i386/sol2-10.h"
tm_defines="${tm_defines} TARGET_BI_ARCH=1"
tmake_file="$tmake_file i386/t-sol2-10"
need_64bit_hwint=yes
;;
esac
# Solaris 2.10 provides crt1.o, crti.o, crtn.o, and gcrt1.o as
# part of the base system.
extra_parts="gmon.o crtbegin.o crtend.o"
;;
*)
extra_parts="crt1.o crti.o crtn.o gcrt1.o gmon.o crtbegin.o
crtend.o"
;;
2, I added gcc-4.0.0/gcc/config/i386/t-sol2-10-32. It contains
MULTILIB_OPTIONS = m32
MULTILIB_DIRNAMES = 32
MULTILIB_OSDIRNAMES = .
LIBGCC = stmp-multilib
INSTALL_LIBGCC = install-multilib
# GCC contains i386 assembler sources for some of the startfiles
# which aren't appropriate for amd64. Just use the installed
# versions of: crt1.o crti.o crtn.o gcrt1.o
EXTRA_MULTILIB_PARTS=gmon.o crtbegin.o crtend.o
This may or may not have been necessary, but it seems tidy.
3. Those two changes convinced the new compiler to only emit 32-bit opcodes.
The next problem was that the new compiler thought all bitfield lengths were 0.
That's because it thought all constants encountered in source files had a value
of 0. Boy, was that a lot of fumbling in the dark! The cause of this was that
HOST_WIDE_INT was set to "long long" instead of "long". To fix this, I changed
gcc-4.0.0/libgcc/configure and gcc-4.0.0/libgcc/configure.ac as follows:
-
case $target in
alpha*-*-* | \
arm*-*-eabi* | \
arm*-*-symbianelf* | \
x86_64-*-* | \
ia64-*-* | \
hppa*64*-*-* | parisc*64*-*-* | \
i[34567]86-*-solaris2.1[0-9]* | \
mips*-*-* | \
mmix-*-* | \
powerpc*-*-* | \
rs6000*-*-* | \
s390*-*-* | \
sparc64*-*-* | ultrasparc-*-freebsd* | \
sparcv9-*-solaris2* | \
sparc-*-solaris2.[789] | sparc-*-solaris2.1[0-9]* | \
sh[123456789l]*-*-*)
need_64bit_hwint=yes ;;
*)
need_64bit_hwint=no ;;
esac
-
becomes
-
need_64bit_hwint=no
case $target in
alpha*-*-* | \
arm*-*-eabi* | \
arm*-*-symbianelf* | \
x86_64-*-* | \
ia64-*-* | \
hppa*64*-*-* | parisc*64*-*-* | \
mips*-*-* | \
mmix-*-* | \
[Bug libstdc++/21523] [4.0 Regression] 3.4.4 RC1 fails libstdc++ install on powerpc64-linux
--- Additional Comments From mark at codesourcery dot com 2005-05-13 01:01
---
Subject: Re: [4.0 Regression] 3.4.4 RC1 fails libstdc++
install on powerpc64-linux
mmitchel at gcc dot gnu dot org wrote:
> --- Additional Comments From mmitchel at gcc dot gnu dot org 2005-05-13
> 00:57 ---
> Fixed in 3.4.4.
Janis, if you would be so kind as to test again, here is a proposed
patch for 4.0.
Thanks,
Index: testsuite/Makefile.am
===
RCS file: /cvs/gcc/gcc/libstdc++-v3/testsuite/Makefile.am,v
retrieving revision 1.42.6.1
diff -c -5 -p -r1.42.6.1 Makefile.am
*** testsuite/Makefile.am 9 May 2005 18:16:56 - 1.42.6.1
--- testsuite/Makefile.am 13 May 2005 00:46:29 -
*** libv3test_a_SOURCES = \
*** 48,66
testsuite_abi.cc \
testsuite_allocator.cc \
testsuite_character.cc \
testsuite_hooks.cc
- ## Build support utilities.
- if GLIBCXX_TEST_ABI
- noinst_PROGRAMS = abi_check
- else
- noinst_PROGRAMS =
- endif
- abi_check_SOURCES = testsuite_abi_check.cc
- abi_check_DEPENDENCIES = libv3test.a
-
all-local: stamp_wchar stamp_thread testsuite_files
# Enable wchar_t tests if capable.
if GLIBCXX_TEST_WCHAR_T
stamp_wchar:
--- 48,57
*** site.exp: Makefile
*** 106,132
@echo 'set host_triplet $(host_triplet)' >>site.tmp
@echo 'set target_alias "$(target_alias)"' >>site.tmp
@echo 'set target_triplet $(target_triplet)' >>site.tmp
@echo 'set target_triplet $(target_triplet)' >>site.tmp
@echo 'set libiconv "$(LIBICONV)"' >>site.tmp
@echo '## All variables above are generated by configure. Do Not Edit
##' >>site.tmp
@test ! -f site.exp || \
sed '1,/^## All variables above are.*##/ d' site.exp >> site.tmp
@-rm -f site.bak
@test ! -f site.exp || mv site.exp site.bak
@mv site.tmp site.exp
- # This is automatically run after the generated check-DEJAGNU rule.
- check-local: check-abi
-
-
baseline_file = ${baseline_dir}/baseline_symbols.txt
extract_symvers = $(glibcxx_srcdir)/scripts/extract_symvers
- current_symbols.txt: ${extract_symvers} ../src/.libs/libstdc++.so
- -@(${extract_symvers} ../src/.libs/libstdc++.so current_symbols.txt)
-
baseline_symbols:
-@(output=${baseline_file}; \
if test ! -f $${output}; then \
echo "Baseline file doesn't exist."; \
echo "Try 'make new-abi-baseline' to create it."; \
--- 97,117
@echo 'set host_triplet $(host_triplet)' >>site.tmp
@echo 'set target_alias "$(target_alias)"' >>site.tmp
@echo 'set target_triplet $(target_triplet)' >>site.tmp
@echo 'set target_triplet $(target_triplet)' >>site.tmp
@echo 'set libiconv "$(LIBICONV)"' >>site.tmp
+ @echo 'set baseline_file "$(baseline_file)"' >> site.tmp
@echo '## All variables above are generated by configure. Do Not Edit
##' >>site.tmp
@test ! -f site.exp || \
sed '1,/^## All variables above are.*##/ d' site.exp >> site.tmp
@-rm -f site.bak
@test ! -f site.exp || mv site.exp site.bak
@mv site.tmp site.exp
baseline_file = ${baseline_dir}/baseline_symbols.txt
extract_symvers = $(glibcxx_srcdir)/scripts/extract_symvers
baseline_symbols:
-@(output=${baseline_file}; \
if test ! -f $${output}; then \
echo "Baseline file doesn't exist."; \
echo "Try 'make new-abi-baseline' to create it."; \
*** new-abi-baseline:
*** 144,166
${extract_symvers} ../src/.libs/libstdc++.so $${output})
if GLIBCXX_TEST_ABI
# Use 'new-abi-baseline' to create an initial symbol file. Then run
# 'check-abi' to test for changes against that file.
! check-abi: abi_check baseline_symbols current_symbols.txt
! [EMAIL PROTECTED]/abi_check --check ./current_symbols.txt
${baseline_file} \
! 2>&1 | tee libstdc++-abi.sum
! [EMAIL PROTECTED] libstdc++-abi.sum libstdc++-abi.log
!
! check-abi-verbose: abi_check baseline_symbols current_symbols.txt
! [EMAIL PROTECTED]/abi_check --check-verbose ./current_symbols.txt
${baseline_file} \
! 2>&1 | tee libstdc++-abi.sum
! [EMAIL PROTECTED] libstdc++-abi.sum libstdc++-abi.log
!
else
check-abi:
- check-abi-verbose:
endif
# Runs the testsuite, but in compile only mode.
# Can be used to test sources with non-GNU FE's at various warning
# levels and for checking compile time across releases.
--- 129,142
${extract_symvers} ../src/.libs/libstdc++.so $${output})
if GLIBCXX_TEST_ABI
# Use 'new-abi-baseline' to create an initial symbol file. Then run
# 'check-abi' to test for changes against that file.
! check-abi: baseline_symbols current_symbols.txt site.exp
! [EMAIL PROTECTED] --tool libstdc++ abi.exp
else
check-abi:
endif
# Runs th
[Bug libstdc++/21523] [4.0 Regression] 3.4.4 RC1 fails libstdc++ install on powerpc64-linux
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-05-13 00:57 --- Fixed in 3.4.4. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|UNCONFIRMED |ASSIGNED Summary|[3.4/4.0 Regression] 3.4.4 |[4.0 Regression] 3.4.4 RC1 |RC1 fails libstdc++ install |fails libstdc++ install on |on powerpc64-linux |powerpc64-linux Target Milestone|3.4.4 |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21523
[Bug libstdc++/21526] libstdc++-v3 testsuite hangs on cygwin
--- Additional Comments From mark at codesourcery dot com 2005-05-13 00:37 --- Subject: Re: libstdc++-v3 testsuite hangs on cygwin david dot billinghurst at comalco dot riotinto dot com dot au wrote: > --- Additional Comments From david dot billinghurst at comalco dot > riotinto dot com dot au 2005-05-13 00:32 --- > Subject: RE: libstdc++-v3 testsuite hangs on cygwin > > I can test Mark's patch on cygwin and irix. I assume it is OK > to commit it to 4.0 and 4.1 once tested. Yes, certainly! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21526
[Bug libstdc++/21526] libstdc++-v3 testsuite hangs on cygwin
--- Additional Comments From david dot billinghurst at comalco dot riotinto dot com dot au 2005-05-13 00:32 --- Subject: RE: libstdc++-v3 testsuite hangs on cygwin I can test Mark's patch on cygwin and irix. I assume it is OK to commit it to 4.0 and 4.1 once tested. David NOTICE This e-mail and any attachments are private and confidential and may contain privileged information. If you are not an authorised recipient, the copying or distribution of this e-mail and any attachments is prohibited and you must not read, print or act in reliance on this e-mail or attachments. This notice should not be removed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21526
[Bug libstdc++/21523] [3.4/4.0 Regression] 3.4.4 RC1 fails libstdc++ install on powerpc64-linux
--- Additional Comments From janis187 at us dot ibm dot com 2005-05-13 00:13 --- Subject: Re: [3.4/4.0 Regression] 3.4.4 RC1 fails libstdc++ install on powerpc64-linux Bootstrap with the patch went fine with -j 8, test results look good. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21523
[Bug testsuite/21539] [4.1 Regression] gcc.dg/tree-ssa/ltrans-5.c fails
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-05-12
23:59 ---
Subject: Re: New: [4.1 Regression]
gcc.dg/tree-ssa/ltrans-5.c fails
On Thu, 2005-05-12 at 19:59 +, jsm28 at gcc dot gnu dot org wrote:
> FAIL: gcc.dg/tree-ssa/ltrans-5.c scan-tree-dump-times Linear expression:
> constant: 1 invariants: denominator: 1 1
> FAIL: gcc.dg/tree-ssa/ltrans-5.c scan-tree-dump-times transformed loop 1
>
> have appeared on mainline between 20050511 and 20050512 on platforms including
> at least i686-pc-linux-gnu and hppa{2.0w,64}-hp-hpux11.{11,23}.
> gcc-testresults
> shows other platforms as well.
>
This test should be xfail'd or removed, as sebastian explained in the
patch but apparently did not to.
We can't interchange this loop anymore because we don't know enough
about set_mem_alias_set.
If you annotate it with pure or something of the sort, gcc just removes
all the loads and stores so there is nothing left to interchange :)
Thus, the test is not useful anymore.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21539
[Bug rtl-optimization/17935] Two consecutive movzbl are generated
-- Bug 17935 depends on bug 21520, which changed state. Bug 21520 Summary: missing PRE opportunity with operand after operand http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21520 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17935
[Bug tree-optimization/21520] missing PRE opportunity with operand after operand
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-05-12 23:34 --- Foxed -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21520
[Bug tree-optimization/21520] missing PRE opportunity with operand after operand
-- Bug 21520 depends on bug 21532, which changed state. Bug 21532 Summary: ICE caused by PRE dead instruction removal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21532 What|Old Value |New Value Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21520
[Bug tree-optimization/21532] ICE caused by PRE dead instruction removal
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-05-12 23:33 --- Foxed -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21532
[Bug tree-optimization/21532] ICE caused by PRE dead instruction removal
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-12 23:33 --- Subject: Bug 21532 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-05-12 23:33:30 Modified files: gcc: ChangeLog tree-ssa-pre.c Log message: 2005-05-12 Daniel Berlin <[EMAIL PROTECTED]> Fix PR tree-optimization/21532 * tree-ssa-pre.c (create_expression_by_pieces): stmt needs to go onto the inserted_exprs list. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.242&r2=2.7592.2.243 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-pre.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.65.4.3&r2=2.65.4.4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21532
[Bug tree-optimization/21520] missing PRE opportunity with operand after operand
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-12 22:13 --- Subject: Bug 21520 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-05-12 22:13:00 Modified files: gcc: ChangeLog tree-ssa-pre.c Added files: gcc/testsuite/gcc.c-torture/compile: pr21532.c Log message: Fix PR tree-optimization/21520 * tree-ssa-pre.c (phi_translate): Use fully_constant_expression to attempt to fold constants. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8751&r2=2.8752 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-pre.c.diff?cvsroot=gcc&r1=2.85&r2=2.86 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/compile/pr21532.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21520
[Bug middle-end/21538] [4.0/4.1 Regression] g++.dg/opt/temp1.C execution test fails
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-12 21:59 --- Confirmed, though I think the testcase is wrong though if we use memcpy before main. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-05-12 21:59:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21538
[Bug tree-optimization/21541] [4.1 Regression] gcc.c-torture/execute/20031215-1.c compilation fails
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-12 21:57 --- This is why I hate the type system of GCC and what is consider compatible and such for the tree optimizers -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2005-05-12 21:57:33 date|| Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21541
[Bug testsuite/21539] [4.1 Regression] gcc.dg/tree-ssa/ltrans-5.c fails
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-12 21:51 --- The testcase is wrong and should be removed. -- What|Removed |Added Status|UNCONFIRMED |NEW Component|tree-optimization |testsuite Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-05-12 21:51:19 date|| Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21539
[Bug java/21540] switch stmt problem
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-12
21:49 ---
Confirmed, here is another example:
public class bug
{
public static final long xxx = 555;
public static final int xxx1 = (int)(xxx >>> 32);
public int fn (int v)
{
switch (v)
{
case (xxx1):
return 1;
}
return 0;
}
}
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Keywords||rejects-valid
Known to fail||3.0.4 3.2.3 3.2.2 3.3.3
||3.4.0 4.0.0 4.1.0
Last reconfirmed|-00-00 00:00:00 |2005-05-12 21:49:59
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21540
[Bug debug/20967] g++ generates same DW_AT_ranges info for two different functions
--- Additional Comments From wilson at gcc dot gnu dot org 2005-05-12 20:37 --- Created an attachment (id=8881) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8881&action=view) Emit DW_AT_call_file and DW_AT_call_line for inlined subroutines. -- What|Removed |Added Attachment #8760 is|0 |1 obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20967
[Bug tree-optimization/21541] New: [4.1 Regression] gcc.c-torture/execute/20031215-1.c compilation fails
FAIL: gcc.c-torture/execute/20031215-1.c compilation, -O2
FAIL: gcc.c-torture/execute/20031215-1.c compilation, -O3 -fomit-frame-pointer
FAIL: gcc.c-torture/execute/20031215-1.c compilation, -O3 -g
FAIL: gcc.c-torture/execute/20031215-1.c compilation, -Os
UNRESOLVED: gcc.c-torture/execute/20031215-1.c execution, -O2
UNRESOLVED: gcc.c-torture/execute/20031215-1.c execution, -O3
-fomit-frame-pointer
UNRESOLVED: gcc.c-torture/execute/20031215-1.c execution, -O3 -g
UNRESOLVED: gcc.c-torture/execute/20031215-1.c execution, -Os
have appeared on mainline between 20050511 and 20050512 on platforms including
at least i686-pc-linux-gnu and hppa{2.0w,64}-hp-hpux11.{11,23}. gcc-testresults
shows other platforms as well.
/home/gcc/nightlies/src-mainline-2005-05-12/gcc-mainline-2005-05-12/gcc/testsuite/gcc.c-torture/execute/20031215-1.c:
In function 'test1':
/home/gcc/nightlies/src-mainline-2005-05-12/gcc-mainline-2005-05-12/gcc/testsuite/gcc.c-torture/execute/20031215-1.c:11:
error: Statement makes a memory store, but has no V_MAY_DEFS nor V_MUST_DEFS
# VUSE ;
ao.ch[2] = 0;
/home/gcc/nightlies/src-mainline-2005-05-12/gcc-mainline-2005-05-12/gcc/testsuite/gcc.c-torture/execute/20031215-1.c:11:
internal compiler error: verify_ssa failed.
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
--
Summary: [4.1 Regression] gcc.c-torture/execute/20031215-1.c
compilation fails
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jsm28 at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21541
[Bug java/21540] switch stmt problem
--- Additional Comments From green at redhat dot com 2005-05-12 20:03 --- Created an attachment (id=8880) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8880&action=view) Test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21540
[Bug java/21540] New: switch stmt problem
Compiling the attached results in: [EMAIL PROTECTED] tmp]$ gcj -C bug.java bug.java: In class 'bug': bug.java: In method 'bug.fn(int)': bug.java:9: error: Constant expression required. case ((int) xxx >>> 32): ^ 1 error -- Summary: switch stmt problem Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: green at redhat dot com CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21540
[Bug tree-optimization/21539] New: [4.1 Regression] gcc.dg/tree-ssa/ltrans-5.c fails
FAIL: gcc.dg/tree-ssa/ltrans-5.c scan-tree-dump-times Linear expression:
constant: 1 invariants: denominator: 1 1
FAIL: gcc.dg/tree-ssa/ltrans-5.c scan-tree-dump-times transformed loop 1
have appeared on mainline between 20050511 and 20050512 on platforms including
at least i686-pc-linux-gnu and hppa{2.0w,64}-hp-hpux11.{11,23}. gcc-testresults
shows other platforms as well.
--
Summary: [4.1 Regression] gcc.dg/tree-ssa/ltrans-5.c fails
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jsm28 at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21539
[Bug middle-end/21538] [4.0/4.1 Regression] g++.dg/opt/temp1.C execution test fails
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-12 19:57 --- CCing Mark as he wrote the code to fix this testcase in the first place. -- What|Removed |Added CC||mmitchel at gcc dot gnu dot ||org Component|tree-optimization |middle-end Keywords||missed-optimization Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21538
[Bug tree-optimization/21538] New: [4.0/4.1 Regression] g++.dg/opt/temp1.C execution test fails
FAIL: g++.dg/opt/temp1.C execution test has appeared on mainline between 20050511 and 20050512 on multiple targets. In <http://gcc.gnu.org/ml/gcc-patches/2005-05/msg01158.html> Jakub Jelinek notes it appears on 4.0 branch as well and blames > 2005-04-28 Richard Guenther <[EMAIL PROTECTED]> > > * fold-const.c (fold_indirect_ref_1): Avoid removing > NOP_EXPRs with type qualifiers like const. -- Summary: [4.0/4.1 Regression] g++.dg/opt/temp1.C execution test fails Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jsm28 at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org,jakub at gcc dot gnu dot org,rguenth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21538
[Bug c++/21537] A templatized struct's member function can't call another templatized struct's templatized member function
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-12 19:32 --- This is correct. You need: inner ().template test(); -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21537
[Bug rtl-optimization/20211] autoincrement generation is poor
--- Additional Comments From joern dot rennecke at st dot com 2005-05-12 19:30 --- Subject: Re: autoincrement generation is poor pinskia at gcc dot gnu dot org wrote: >--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-12 >18:59 --- >The only change is the following: >before: >bzip2-1.0.2,compress,9408 >bzip2-1.0.2,decompress,10604 >after: >bzip2-1.0.2,compress,9428 >bzip2-1.0.2,decompress,10640 > > > Well, there were also lots of small changes. As said before, if you add it all up, the net difference is just four bytes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20211
[Bug c++/21537] New: A templatized struct's member function can't call another templatized struct's templatized member function
In the following code, one templatized struct's member function calls another
templatized struct's templatized member function. GCC 3.3.3 reports a parse
error in the line labeled "This doesn't work!". I've found that if I change the
instantiation of struct inner to use an 'int' rather than 'T', GCC will
compile. Is this correct behavior, or is it a GCC bug?
= CODE FOLLOWS =
template
struct inner
{
template void test() { }
};
template
struct outer
{
void go()
{
//inner ().test(); // This works!
inner ().test(); // This doesn't work!
}
};
= END OF CODE =
--
Summary: A templatized struct's member function can't call
another templatized struct's templatized member function
Product: gcc
Version: 3.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mrstephengross at hotmail dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21537
[Bug libstdc++/21523] [3.4/4.0 Regression] 3.4.4 RC1 fails libstdc++ install on powerpc64-linux
--- Additional Comments From janis187 at us dot ibm dot com 2005-05-12 19:25 --- Subject: Re: [3.4/4.0 Regression] 3.4.4 RC1 fails libstdc++ install on powerpc64-linux > Would you please try the attached patch for 3.4? I have a similar patch > for 4.0 which I will attach soon. With GCC 3.4.4 RC1 the following on an 8-proc powerpc64-linux system: $src/configure --enable-languages=c++ ... make -j 8 bootstrap make install failed without the patch, succeeded with the patch. I'm running the same thing again for good measure and then will build all languages (except Ada) and run the testsuites. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21523
[Bug libfortran/21324] #undef GFC_CLEAR_MEMORY causes testsuite failures
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-05-12 19:12 --- Fixed in mainline and 4.0. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21324
[Bug libfortran/21324] #undef GFC_CLEAR_MEMORY causes testsuite failures
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-12 19:11 --- Subject: Bug 21324 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-05-12 19:10:59 Modified files: libgfortran: ChangeLog libgfortran/io : open.c unit.c unix.c libgfortran/runtime: memory.c Log message: 2005-05-12 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/21324 * runtime/memory.c: Don't define GFC_CLEAR_MEMORY (it's a performance hog). * io/open.c (new_unit): Zero freshly allocated memory for unit structure. * io/unit.c (init_units): Zero freshly allocated memory for STDIN, STDOUT and STDERR. * io/unix.c (open_internal): Zero freshly allocated memory for unix_stream. (fd_to_stream): Likewise. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.163.2.28&r2=1.163.2.29 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/open.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.10.10.3&r2=1.10.10.4 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/unit.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.8&r2=1.8.10.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/unix.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.21.10.3&r2=1.21.10.4 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/runtime/memory.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.6&r2=1.6.12.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21324
[Bug rtl-optimization/20211] autoincrement generation is poor
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-12 18:59 --- The only change is the following: before: bzip2-1.0.2,compress,9408 bzip2-1.0.2,decompress,10604 after: bzip2-1.0.2,compress,9428 bzip2-1.0.2,decompress,10640 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20211
[Bug libgcj/21524] Cancelling a TimerTask puts Timer binary heap in inconsistent state
--- Additional Comments From jradel at 2wire dot com 2005-05-12 18:32 --- (From update of attachment 8868) Ignore this first proposed fix... it's buggy. Working on a new version. -- What|Removed |Added Attachment #8868 is|0 |1 obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21524
[Bug target/21535] Empty inline assembly cause the generated code to be wrong?
-- What|Removed |Added Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21535
[Bug c/21536] [3.4/4.0/4.1 Regression] C99 array of variable length use causes segmentation fault
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-12 18:07 --- Confirmed, I really thought I saw this before. Anyways this is a regression from 2.95.3. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||wrong-code Known to fail||3.0.4 3.2.3 3.2.2 3.3.3 ||3.4.0 4.0.0 Known to work||2.95.3 Last reconfirmed|-00-00 00:00:00 |2005-05-12 18:07:43 date|| Summary|C99 array of variable length|[3.4/4.0/4.1 Regression] C99 |use causes segmentation |array of variable length use |fault |causes segmentation fault Target Milestone|--- |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21536
[Bug libstdc++/21523] [3.4/4.0 Regression] 3.4.4 RC1 fails libstdc++ install on powerpc64-linux
--- Additional Comments From mark at codesourcery dot com 2005-05-12 18:06
---
Subject: Re: New: 3.4.4 RC1 fails libstdc++ install
on powerpc64-linux
Janis --
Would you please try the attached patch for 3.4? I have a similar patch
for 4.0 which I will attach soon.
If this doesn't work, I'm going to revert my previous backport, so as to
avoid holding up 3.4.4.
Thanks,
2005-05-12 Mark Mitchell <[EMAIL PROTECTED]>
2005-04-04 Mark Mitchell <[EMAIL PROTECTED]>
* testsuite/Makefile.am (check-local): Remove.
(curent_symbols.txt): Likewise.
(check-abi): Do not depend on current_symbols.txt.
* testsuite/Makefile.in: Regenerated.
* testsuite/libstdc++-abi/abi.exp: Build current_symbols.txt.
2005-04-01 Mark Mitchell <[EMAIL PROTECTED]>
* testsuite/Makefile.am (noinst_PROGRAMS): Remove.
(site.exp): Write out the path to the baseline file.
(check-abi): Use DejaGNU.
(check-abi-verbose): Remove.
* testsuite/Makefile.in: Regenerated.
* testsuite/abi_check.cc (main): Check the return value from
compare_symbols.
* testsuite/testsuite_abi.cc (compare_symbols): Return a value.
* testsuite/testsuite_abi.h (compare_symbols): Adjust prototype.
* testsuite/libstdc++-abi/abi.exp: New file.
2004-03-19 Phil Edwards <[EMAIL PROTECTED]>
* testsuite/Makefile.am (site.exp): New target, based on that
created by automake. Also set libiconv.
Index: testsuite/Makefile.am
===
RCS file: /cvs/gcc/gcc/libstdc++-v3/testsuite/Makefile.am,v
retrieving revision 1.33.4.3
diff -c -5 -p -r1.33.4.3 Makefile.am
*** testsuite/Makefile.am 15 May 2004 20:44:13 - 1.33.4.3
--- testsuite/Makefile.am 12 May 2005 17:22:43 -
*** noinst_LIBRARIES = libv3test.a
*** 46,64
libv3test_a_SOURCES = \
testsuite_abi.cc \
testsuite_allocator.cc \
testsuite_hooks.cc
- ## Build support utilities.
- if GLIBCXX_TEST_ABI
- noinst_PROGRAMS = abi_check
- else
- noinst_PROGRAMS =
- endif
- abi_check_SOURCES = abi_check.cc
- abi_check_DEPENDENCIES = libv3test.a
-
all-local: stamp_wchar testsuite_files
# Enable wchar_t tests if capable.
if GLIBCXX_TEST_WCHAR_T
stamp_wchar:
--- 46,55
*** lists_of_files = \
*** 76,85
--- 67,103
# This is automatically run after the generated check-DEJAGNU rule.
check-local: check-abi
+ # We need more things in site.exp, but automake completely controls the
+ # creation of that file; there's no way to append to it without messing up
+ # the dependancy chains. So we overrule automake. This rule is exactly
+ # what it would have generated, plus our own additions.
+ site.exp: Makefile
+ @echo 'Making a new site.exp file...'
+ @echo '## these variables are automatically generated by make ##'
>site.tmp
+ @echo '# Do not edit here. If you wish to override these values'
>>site.tmp
+ @echo '# edit the last section' >>site.tmp
+ @echo 'set srcdir $(srcdir)' >>site.tmp
+ @echo "set objdir `pwd`" >>site.tmp
+ @echo 'set build_alias "$(build_alias)"' >>site.tmp
+ @echo 'set build_triplet $(build_triplet)' >>site.tmp
+ @echo 'set host_alias "$(host_alias)"' >>site.tmp
+ @echo 'set host_triplet $(host_triplet)' >>site.tmp
+ @echo 'set target_alias "$(target_alias)"' >>site.tmp
+ @echo 'set target_triplet $(target_triplet)' >>site.tmp
+ @echo 'set target_triplet $(target_triplet)' >>site.tmp
+ @echo 'set libiconv "$(LIBICONV)"' >>site.tmp
+ @echo 'set baseline_file "$(baseline_file)"' >> site.tmp
+ @echo '## All variables above are generated by configure. Do Not Edit
##' >>site.tmp
+ @test ! -f site.exp || \
+ sed '1,/^## All variables above are.*##/ d' site.exp >> site.tmp
+ @-rm -f site.bak
+ @test ! -f site.exp || mv site.exp site.bak
+ @mv site.tmp site.exp
+
baseline_file = ${baseline_dir}/baseline_symbols.txt
extract_symvers = $(glibcxx_srcdir)/scripts/extract_symvers
current_symbols.txt: ${extract_symvers} ../src/.libs/libstdc++.so
-@(${extract_symvers} ../src/.libs/libstdc++.so current_symbols.txt)
*** new-abi-baseline:
*** 103,125
${extract_symvers} ../src/.libs/libstdc++.so $${output})
if GLIBCXX_TEST_ABI
# Use 'new-abi-baseline' to create an initial symbol file. Then run
# 'check-abi' to test for changes against that file.
! check-abi: abi_check baseline_symbols current_symbols.txt
! [EMAIL PROTECTED]/abi_check --check ./current_symbols.txt
${baseline_file} \
! 2>&1 | tee libstdc++-abi.sum
! [EMAIL PROTECTED] libstdc++-abi.sum libstdc++-abi.log
!
! check-abi-verbose: abi_check baseline_symbols current_symbols.txt
! [EMAIL PROTECTED]/abi_check --check-verbose ./current
[Bug c/21533] C99 array of variable length use causes segmentation fault
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-12 18:06 --- *** This bug has been marked as a duplicate of 21536 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21533
[Bug c/21536] C99 array of variable length use causes segmentation fault
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-12 18:06 --- *** Bug 21533 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21536
[Bug c/21536] C99 array of variable length use causes segmentation fault
--- Additional Comments From shane256 at hotmail dot com 2005-05-12 18:05 --- Created an attachment (id=8874) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8874&action=view) Contains test case code, intermediate files, etc. demonstrating the issue -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21536
[Bug c/21536] New: C99 array of variable length use causes segmentation fault
Platform: Linux GCC x86. I have generated a test case where the code I have using a C99 array with variable length causes a segmentation fault. The thing is, if I comment out an unrelated line of code that is impossible to be executed and not in the execution pathway (it's in the body of an if statement that can not be executed because of the conditional anyway and added to that, I put a return 0; in front of the line of code so if it did happen to get in there, it would return before executing the line of code) the segmentation fault does not happen. Also, if I don't do that, but I do comment out an unused automatic variable defined in the main() function (which calls the test function), the segmentation fault does not happen. The test code is ~40 lines long and contains all the temporary files requested, the version information, and a more detailed explanation of how to reproduce the segmentation fault. This is all in a tar.gz file that you can get from http://www.sinistershane.net/~shane/files/testcase.tar.gz The segv appears in both x86_64 and x86 (32bit) executables. -- Summary: C99 array of variable length use causes segmentation fault Product: gcc Version: 3.3.4 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: shane256 at hotmail dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21536
[Bug target/21412] ICE loading TLS address
--- Additional Comments From rth at gcc dot gnu dot org 2005-05-12 17:56 --- ia64 fixed; sparc still broken. But I'm not planning to work on that. -- What|Removed |Added AssignedTo|rth at gcc dot gnu dot org |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW GCC target triplet|ia64-*-*, sparc*-*-*|sparc*-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21412
[Bug c/21535] New: Empty inline assembly cause the generated code to be wrong?
Two C file (p.c and q.c) attached bellows. With an inline assembly
line (even just a comment), the code sequence is different. As a
result, the function foo() in q.c is working OK but not the foo()
in p.c.
*** Command line ***
$ /utils/gcc/3.4.3/mipsel-linux-uclibc/i386/bin/mipsel-linux-gcc -v
Reading specs from
/utils/gcc/3.4.3/mipsel-linux-uclibc/i386/lib/gcc/mipsel-linux-uclibc/3.4.3/specs
Configured with:
/home/YH/MIPS/BR/buildroot/toolchain_build_mipsel/gcc-3.4.3/configure
--prefix=/utils/gcc/3.4.3/mipsel-linux-uclibc/i386 --build=i386-pc-linux-gnu
--host=i386-pc-linux-gnu --target=mipsel-linux-uclibc --enable-languages=c,c++
--enable-shared --disable-__cxa_atexit --enable-target-optspace --with-gnu-ld
--disable-nls --enable-multilib --enable-sjlj-exceptions
Thread model: posix
gcc version 3.4.3
$ /utils/gcc/3.4.3/mipsel-linux-uclibc/i386/bin/mipsel-linux-gcc -mno-abicalls
-O2 -c -o p.o p.c
$ /utils/gcc/3.4.3/mipsel-linux-uclibc/i386/bin/mipsel-linux-objdump -S p.o >
p.dasm
$ /utils/gcc/3.4.3/mipsel-linux-uclibc/i386/bin/mipsel-linux-gcc -mno-abicalls
-O2 -c -o q.o q.c
$ /utils/gcc/3.4.3/mipsel-linux-uclibc/i386/bin/mipsel-linux-objdump -S q.o >
q.dasm
p.c
int foo(int x, int y, int z)
{
__asm__ __volatile__ ("/* TEST */\n");
return((x + y) / z);
}
end of p.c
q.c
int foo(int x, int y, int z)
{
// __asm__ __volatile__ ("/* TEST */\n");
return((x + y) / z);
}
end of q.c
> with the inline assembly (p.dasm)
p.o: file format elf32-tradlittlemips
Disassembly of section .text:
:
0: 00851021adduv0,a0,a1
4: 14c2bneza2,10
8: 0046001adiv zero,v0,a2
c: 0007000dbreak 0x7
10: 1012mflov0
14: 03e8jr ra
18: nop
1c: nop
> without the inline assembly (q.dasm)
q.o: file format elf32-tradlittlemips
Disassembly of section .text:
:
0: 00851021adduv0,a0,a1
4: 0046001adiv zero,v0,a2
8: 14c2bneza2,14
c: nop
10: 0007000dbreak 0x7
14: 1012mflov0
18: 03e8jr ra
1c: nop
> assembly file (p.s)
.file 1 "p.c"
.section .mdebug.abi32
.previous
.text
.align 2
.globl foo
.entfoo
.type foo, @function
foo:
.frame $sp,0,$31 # vars= 0, regs= 0/0, args= 0, gp= 0
.mask 0x,0
.fmask 0x,0
#APP
/* TEST */
#NO_APP
addu$2,$4,$5
div $0,$2,$6
bne $6,$0,1f
break 7
1:
mflo$2
j $31
.endfoo
.ident "GCC: (GNU) 3.4.3"
> assembly file (q.s)
.file 1 "q.c"
.section .mdebug.abi32
.previous
.text
.align 2
.globl foo
.entfoo
.type foo, @function
foo:
.frame $sp,0,$31 # vars= 0, regs= 0/0, args= 0, gp= 0
.mask 0x,0
.fmask 0x,0
.setnoreorder
.setnomacro
addu$2,$4,$5
div $0,$2,$6
bne $6,$0,1f
nop
break 7
1:
mflo$2
j $31
nop
.setmacro
.setreorder
.endfoo
.ident "GCC: (GNU) 3.4.3"
--
Summary: Empty inline assembly cause the generated code to be
wrong?
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yhlin at sdesigns dot com
CC: gcc-bugs at gcc dot gnu dot org,yhlin at sdesigns dot
com
GCC build triplet: i686-pc-linux
GCC host triplet: i686-pc-linux
GCC target triplet: mipsel-linux-gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21535
[Bug c++/21534] Declaration in wrong namespace not rejected
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-12 17:55 --- Confirmed, I thought I saw something like this before (and not in PR 21515). -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Known to fail||2.95.3 3.0.4 3.2.3 3.3.3 ||3.4.0 4.0.0 4.1.0 Last reconfirmed|-00-00 00:00:00 |2005-05-12 17:55:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21534
[Bug libstdc++/21523] [3.4/4.0 Regression] 3.4.4 RC1 fails libstdc++ install on powerpc64-linux
-- What|Removed |Added Priority|P2 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21523
[Bug rtl-optimization/17935] Two consecutive movzbl are generated
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-12 17:52 --- With the patch for PR 21520, we will get better code. Right now on the mainline we get: bar: movl4(%esp), %eax testb $1, (%eax) jne .L7 movl8(%esp), %eax movb(%eax), %al andl$1, %eax xorl$1, %eax movzbl %al, %eax ret .p2align 2,,3 .L7: xorl%eax, %eax movzbl %al, %eax ret but after that patch we should be able to remove the extra movzbl in the second branch. -- What|Removed |Added BugsThisDependsOn||21520 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17935
[Bug c++/21534] New: Declaration in wrong namespace not rejected
This code isn't rejected, though it should be:
namespace NS
{
template void f();
}
template void NS::f (int);
---
It _is_ rejected if NS::f is not a template.
FWIW, icc says this to the snippet:
tmp/y> icc -Xc -ansi -c x.cc
x.cc(6): error: function template "NS::f" may not be redeclared in the current
scope
template void NS::f (int);
^
W.
--
Summary: Declaration in wrong namespace not rejected
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bangerth at dealii dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21534
[Bug target/21412] ICE loading TLS address
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-12 17:50 --- Subject: Bug 21412 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-05-12 17:50:26 Modified files: gcc: ChangeLog gcc/config/ia64: ia64-protos.h ia64.c ia64.h ia64.md predicates.md Log message: PR target/21412 * config/ia64/ia64.c (TARGET_CANNOT_FORCE_CONST_MEM): New. (ia64_cannot_force_const_mem): New. (tls_symbolic_operand_type): New. (ia64_legitimate_constant_p): New. (ia64_expand_load_address): Return true on success. Improve checks for when we should not split. (ia64_expand_tls_address): New addend operand. Distribute it as appropriate to the tls_kind. Delay referencing gp. (ia64_expand_move): Split symbolic addend as necessary. Handle tls symbols with addends. * config/ia64/ia64-protos.h: Update. * config/ia64/ia64.h (CALL_REALLY_USED_REGISTERS): False for r0, p0, f0, f1, and r13. (LEGITIMATE_CONSTANT_P): Move to ia64_legitimate_constant_p. * config/ia64/ia64.md (UNSPEC_DTPMOD): New. (symbolic_operand splitter): Pass everything through ia64_expand_load_address and FAIL or DONE as appropriate. (load_fptr): Only accept after reload. (load_fptr_internal1, gprel64_offset, load_gprel64, load_symptr_high, load_symptr_low, load_ltoff_dtpmod, (load_dtpmod): New. (load_dtprel): Only accept tls symbols. (load_dtprel64, load_dtprel22): Likewise. (load_tprel, load_tprel64, load_tprel22): Likewise. (load_dtprel_gd, load_ltoff_dtprel, load_tprel_ie): New. (add_dtprel): Only accept tls symbols. Canonicalize PLUS. (add_dtprel14, add_dtprel22): Likewise. (add_tprel, add_tprel14, add_tprel22): Likewise. * config/ia64/predicates.md (small_addr_symbolic_operand): New. (any_offset_symbol_operand, aligned_offset_symbol_operand): New. (got_symbolic_operand): Check CONST offsets. (tls_symbolic_operand, ld_tls_symbolic_operand): New. (ie_tls_symbolic_operand, le_tls_symbolic_operand): New. (move_operand): Don't handle tls here. Check CONST offsets. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.241&r2=2.7592.2.242 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/ia64/ia64-protos.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.70&r2=1.70.8.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/ia64/ia64.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.347.2.4&r2=1.347.2.5 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/ia64/ia64.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.193&r2=1.193.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/ia64/ia64.md.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.146.8.2&r2=1.146.8.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/ia64/predicates.md.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5&r2=1.5.10.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21412
[Bug libfortran/21324] #undef GFC_CLEAR_MEMORY causes testsuite failures
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-12 17:50 --- Subject: Bug 21324 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-05-12 17:50:35 Modified files: libgfortran: ChangeLog libgfortran/io : open.c unit.c unix.c libgfortran/runtime: memory.c Log message: 2005-05-12 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/21324 * runtime/memory.c: Don't define GFC_CLEAR_MEMORY (it's a performance hog). * io/open.c (new_unit): Zero freshly allocated memory for unit structure. * io/unit.c (init_units): Zero freshly allocated memory for STDIN, STDOUT and STDERR. * io/unix.c (open_internal): Zero freshly allocated memory for unix_stream. (fd_to_stream): Likewise. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcc&r1=1.214&r2=1.215 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/open.c.diff?cvsroot=gcc&r1=1.13&r2=1.14 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/unit.c.diff?cvsroot=gcc&r1=1.8&r2=1.9 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/unix.c.diff?cvsroot=gcc&r1=1.24&r2=1.25 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/runtime/memory.c.diff?cvsroot=gcc&r1=1.6&r2=1.7 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21324
[Bug c++/21515] problem with template and template function compilation in a namespace
--- Additional Comments From bangerth at dealii dot org 2005-05-12 17:49
---
You can't do this:
template
std::ostream & std::operator<< (std::ostream &, a::A const &);
If you want to overload something in namespace std, you have to open that
namespace, put the declaration in it, and close it again. If you do this
everything is fine, i.e. like so:
namespace std
{
template
ostream & operator<< (ostream &, a::A const &);
}
The fact that we don't reject the declaration is a bug in gcc in itself,
for which I'll open a PR in a minute.
W.
--
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21515
[Bug c++/21515] problem with template and template function compilation in a namespace
-- What|Removed |Added Summary|problem with tempalte and |problem with template and |tempalte function |template function |compilation in a namespace |compilation in a namespace http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21515
[Bug tree-optimization/17272] Extra store emitted when concatenating inline assembly sections.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-12 17:43 --- I mean on the setting side of the inline-asm. Otherwise we have a ra issue. -- What|Removed |Added Component|rtl-optimization|tree-optimization Keywords||ra Last reconfirmed|2005-03-03 02:54:36 |2005-05-12 17:43:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17272
[Bug c/21533] New: C99 array of variable length use causes segmentation fault
Platform: Linux GCC x86. I have generated a test case where the code I have using a C99 array with variable length causes a segmentation fault. The thing is, if I comment out an unrelated line of code that is impossible to be executed and not in the execution pathway (it's in the body of an if statement that can not be executed because of the conditional anyway and added to that, I put a return 0; in front of the line of code so if it did happen to get in there, it would return before executing the line of code) the segmentation fault does not happen. Also, if I don't do that, but I do comment out an unused automatic variable defined in the main() function (which calls the test function), the segmentation fault does not happen. The test code is ~40 lines long and contains all the temporary files requested, the version information, and a more detailed explanation of how to reproduce the segmentation fault. This is all in a tar.gz file that you can get from http://www.sinistershane.net/~shane/files/testcase.tar.gz The segv appears in both x86_64 and x86 (32bit) executables. -- Summary: C99 array of variable length use causes segmentation fault Product: gcc Version: 3.3.4 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: shane256 at hotmail dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21533
[Bug rtl-optimization/16541] code quality issue for bit manipulations with 64bit
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-12 17:40 --- Looks like a register allocation issue. -- What|Removed |Added Keywords||ra http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16541
[Bug rtl-optimization/10624] unroll-loops can't unroll nested constant loops
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-12 17:36 --- *** Bug 15513 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||kunert at physik dot tu- ||dresden dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10624
[Bug rtl-optimization/15513] loop peeling failed becuase of non-constant start
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-12 17:36 --- Actually this is a dup of bug 10624. *** This bug has been marked as a duplicate of 10624 *** -- What|Removed |Added Status|SUSPENDED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15513
[Bug tree-optimization/21532] ICE caused by PRE dead instruction removal
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-12 17:11 --- Subject: Bug 21532 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-05-12 17:11:20 Modified files: gcc: ChangeLog tree-ssa-pre.c Log message: 2005-05-12 Daniel Berlin <[EMAIL PROTECTED]> Fix PR tree-optimization/21532 * tree-ssa-pre.c (create_expression_by_pieces): stmt needs to go onto the inserted_exprs list. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8746&r2=2.8747 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-pre.c.diff?cvsroot=gcc&r1=2.84&r2=2.85 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21532
Re: Internal compiler error in finish_function gcc version 2.96
Mark Weyer <[EMAIL PROTECTED]> wrote:
> Command:
>
> gcc bug.cpp
>
> Output (indented):
>
> bug.cpp: In function `int _ ()':
> bug.cpp:1: parse error before `0'
> bug.cpp:1: Internal error #122.
> bug.cpp:1: Internal compiler error in finish_function, at
> ../gcc/cp/decl.c:14422
> Please submit a full bug report.
> See http://www.gnu.org/software/gcc/bugs.html> for instructions.
>
> Version:
>
> Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
> gcc version 2.96 2731 (Red Hat Linux 7.0)
Thank you, but gcc 2.96 is not even an official FSF version of GCC.
Moreover, GCC 2.x is totally unsupported at this point, since already 3-4
years at least. You should try updating to a newer GCC version, like the
stable 3.4.4 (to be released in a few days), or the brand new GCC 4.0.0.
With GCC 3.4.3, I get this error trying to compile bug.cc:
bug.cc: In function `int _()':
bug.cc:1: error: expected `(' before numeric constant
--
Giovanni Bajo
Internal compiler error in finish_function gcc version 2.96
Command:
gcc bug.cpp
Output (indented):
bug.cpp: In function `int _ ()':
bug.cpp:1: parse error before `0'
bug.cpp:1: Internal error #122.
bug.cpp:1: Internal compiler error in finish_function, at
../gcc/cp/decl.c:14422
Please submit a full bug report.
See http://www.gnu.org/software/gcc/bugs.html> for instructions.
Version:
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
gcc version 2.96 2731 (Red Hat Linux 7.0)
File bug.cpp (also attached):
int _() {if 0 -> {};}
Yours,
Mark Weyer
int _() {if 0 -> {};}
[Bug tree-optimization/21532] ICE caused by PRE dead instruction removal
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dberlin at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-05-12 15:35:29 |2005-05-12 15:46:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21532
[Bug tree-optimization/21532] ICE caused by PRE dead instruction removal
-- What|Removed |Added OtherBugsDependingO||21520 nThis|| Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-05-12 15:35:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21532
[Bug libstdc++/21526] libstdc++-v3 testsuite hangs on cygwin
--- Additional Comments From mark at codesourcery dot com 2005-05-12 15:32 --- Subject: Re: libstdc++-v3 testsuite hangs on cygwin pcarlini at suse dot de wrote: > --- Additional Comments From pcarlini at suse dot de 2005-05-12 15:23 > --- > Thanks a lot Mark. At this point, since your suggestion is complete as-is, > I would ask David to try it himself. Then, if everything goes well on > cygwin (which I don't have) I will take care of regtesting it on x86-linux > too, and so on. Thanks again. If you don't have time to do that, it's certainly my responsibility. Thanks, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21526
[Bug tree-optimization/21532] ICE caused by PRE dead instruction removal
--- Additional Comments From drow at gcc dot gnu dot org 2005-05-12 15:31 --- Created an attachment (id=8873) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8873&action=view) Testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21532
[Bug tree-optimization/21532] New: ICE caused by PRE dead instruction removal
The attached unreduced testcase from glibc generates an ICE using today's CVS. The only necessary option is -O2. regcomp.c: In function 'build_equiv_class': regcomp.c:3462: error: Missing definition for SSA_NAME: pretmp.2916_545 in statement: D.26795_433 = () pretmp.2916_545; regcomp.c:3462: internal compiler error: verify_ssa failed. -- Summary: ICE caused by PRE dead instruction removal Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: drow at gcc dot gnu dot org CC: dberlin at gcc dot gnu dot org,gcc-bugs at gcc dot gnu dot org,pinskia at gcc dot gnu dot org,stevenb at suse dot de GCC target triplet: arm-none-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21532
[Bug libstdc++/21526] libstdc++-v3 testsuite hangs on cygwin
--- Additional Comments From pcarlini at suse dot de 2005-05-12 15:23 --- Thanks a lot Mark. At this point, since your suggestion is complete as-is, I would ask David to try it himself. Then, if everything goes well on cygwin (which I don't have) I will take care of regtesting it on x86-linux too, and so on. Thanks again. -- What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21526
[Bug libstdc++/21526] libstdc++-v3 testsuite hangs on cygwin
--- Additional Comments From mark at codesourcery dot com 2005-05-12 15:15
---
Subject: Re: libstdc++-v3 testsuite hangs on cygwin
pcarlini at suse dot de wrote:
> --- Additional Comments From pcarlini at suse dot de 2005-05-12 10:02
> ---
> In other terms, we should tell DejaGNU that all the tests involving fifos must
> be skipped on such platform, because fifos are available but not completely
> ok.
Sorry; I assumed Cygwin must not have mkfifo, given that the test was
disabled there; I didn't consider has-mkfifo-but-broken!
The fix for this will be to modify target-supports.exp to check the
platform as well.
If you change check_mkfifo_available in target-supports.exp to do:
proc check_mkfifo_available {} {
if {[istarget *-*-cygwin*]} {
# Cygwin has mkfifo, but support is incomplete.
return 0
}
return [check_function_available "mkfifo"]
}
that should fix it. Would you mind trying that?
Thanks,
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21526
[Bug middle-end/21474] missed optimizations when comparing address to NULL
--- Additional Comments From trt at acm dot org 2005-05-12 15:08 --- I think it is reasonable to assume the address of an auto variable is non-NULL, and so the address of anything in the local "int x[10];" is non-NULL. So gcc can (and does) fold "if (x) ..." and "if (&x[0]) ..." gcc does not fold "if (&x[3]) ..." due to the the quirk that that it is represented as x+3 and fold does not recognize that to be non-NULL. Now consider "if (&x[i])". The only legal values for i are 0..10, which precludes any value of `i' that might cause &x[i] to be NULL. I suppose if x were a pointer, instead of an array, then we wouldn't know the legal range of values for `i'. But whatever the legal range happens to be would still (I think) preclude values which could cause &x[i] to be NULL. The argument for 'if (&p->b[3])' is more convoluted. Suppose p is non-NULL, then surely this address should be considered non-NULL for basically the same reason that &x[3] above is considered to be non-NULL. Suppose instead that p is NULL, then surely a non-zero offset added to p yields a non-NULL value. That leaves "if (&p->a)" which gcc folds even though a's offset is zero. I think this is arguably a bug. But if no one reports it as a bug ... well I think this one could be argued either way. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21474
[Bug target/14563] new/delete much slower than malloc/free because of sjlj exceptions
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-12 14:54 --- If you used the non throw new, it would become faster. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14563
[Bug target/14563] new/delete much slower than malloc/free because of sjlj exceptions
-- What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14563
[Bug java/17845] [4.1 Regression] More problems with simple type names as superclasses
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-05-12 14:10 --- Not fixing the hunk -- removing it actually! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17845
[Bug middle-end/21529] [4.0/4.1 Regression] code size regression (+40%) with -Os from GCC-3.4.3 to 4.1
-- What|Removed |Added Known to fail||4.0.0 4.1.0 Known to work||3.4.3 Summary|code size regression (+40%) |[4.0/4.1 Regression] code |with -Os from GCC-3.4.3 to |size regression (+40%) with |4.1 |-Os from GCC-3.4.3 to 4.1 Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21529
[Bug middle-end/21528] [4.0 Regression] Boost shared_ptr_test.cpp fails with -O3
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-12 13:38 --- Also the other major difference is: mainline: - # pi_503 = V_MAY_DEF ; - pi.pn.pi_ = this_45; 4.0.0: + # TMT.242_3 = V_MAY_DEF ; + pi.pn.pi_ = this_99; See how we used a TMT in 4.0.0 case and pi on the mainline. -- What|Removed |Added CC||dnovillo at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21528
[Bug middle-end/21528] [4.0 Regression] Boost shared_ptr_test.cpp fails with -O3
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-12 13:35 --- The difference between the mainline and the 4.0.0 branch is the following additional SRA in 4.0.x: +Initial instantiation for pv + pv.pn.pi_ -> pv$pn$pi_ + pv.px -> pv$px +Initial instantiation for pi2 + pi2.pn.pi_ -> pi2$pn$pi_ + pi2.px -> pi2$px + -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21528
[Bug middle-end/21528] [4.0 Regression] Boost shared_ptr_test.cpp fails with -O3
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-12 13:28 --- Hmm, I am starting to think there is an alias bug in 4.0.0 somewhere. -- What|Removed |Added Summary|Boost shared_ptr_test.cpp |[4.0 Regression] Boost |fails with -O3 |shared_ptr_test.cpp fails ||with -O3 Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21528
[Bug middle-end/21528] Boost shared_ptr_test.cpp fails with -O3
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-12 13:17 --- Hmm, -fno-sra works around the issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21528
[Bug middle-end/21528] Boost shared_ptr_test.cpp fails with -O3
-- What|Removed |Added Component|c++ |middle-end Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21528
[Bug bootstrap/21230] [4.0/4.1 Regression] bootstrap failed unless bootstrap compiler is gcc.
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-05-12 12:27 --- See http://gcc.gnu.org/ml/gcc-patches/2005-05/msg01116.html -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21230
[Bug bootstrap/21230] [4.0/4.1 Regression] bootstrap failed unless bootstrap compiler is gcc.
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-12 12:24 --- Subject: Bug 21230 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-05-12 12:24:15 Modified files: config : ChangeLog warnings.m4 libcpp : ChangeLog configure Log message: config/ PR bootstrap/21230 * warnings.m4 (ACX_PROG_CC_WARNING_ALMOST_PEDANTIC): Add doubles quotes around GCC variable. libcpp/ PR bootstrap/21230 * configure: Regenerate. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/config/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.59.8.2&r2=1.59.8.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/config/warnings.m4.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.2&r2=1.2.10.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libcpp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.56.2.7&r2=1.56.2.8 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libcpp/configure.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.13.6.2&r2=1.13.6.3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21230
[Bug c++/21528] Boost shared_ptr_test.cpp fails with -O3
--- Additional Comments From redi at gcc dot gnu dot org 2005-05-12 12:22
---
Also, I *do* still see the failure if I replace BOOST_TEST() with assert().
This still fails with -finline-functions -finline-limit=80
#include
#include
int main()
{
boost::shared_ptr pi(new int);
boost::shared_ptr pv(pi);
boost::shared_ptr pi2 = boost::static_pointer_cast(pv);
assert(pi.get() == pi2.get());
assert(pi.use_count() == 3); // fails here
return 0;
}
*however* if I remove the first assertion it succeeds.
--
What|Removed |Added
Known to fail||4.0.0 4.0.1
Known to work||3.4.3 4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21528
[Bug bootstrap/21230] [4.0/4.1 Regression] bootstrap failed unless bootstrap compiler is gcc.
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-12 12:22 --- Subject: Bug 21230 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-05-12 12:22:09 Modified files: config : ChangeLog warnings.m4 libcpp : ChangeLog configure Log message: config/ PR bootstrap/21230 * warnings.m4 (ACX_PROG_CC_WARNING_ALMOST_PEDANTIC): Add double quotes around GCC variable. libcpp/ PR bootstrap/21230 * configure: Regenerate. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/config/ChangeLog.diff?cvsroot=gcc&r1=1.64&r2=1.65 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/config/warnings.m4.diff?cvsroot=gcc&r1=1.2&r2=1.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libcpp/ChangeLog.diff?cvsroot=gcc&r1=1.69&r2=1.70 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libcpp/configure.diff?cvsroot=gcc&r1=1.15&r2=1.16 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21230
[Bug tree-optimization/21531] 4.0/4.1 Regression __builtin_expect
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-12 12:12 --- Can you attached the preprocessed source code (The only reason why I did not ask for PR 21513 is because I figured out to compile it and reproduce it without it). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21531
[Bug target/21518] [4.0/4.1 Regression] unable to find a register to spill in class 'Q_REGS' with -fPIC and -O2
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-12 12:02 --- The code around: /* We can't use regparm(3) for nested functions as these use static chain pointer in third argument. */ if (DECL_CONTEXT (decl) && !DECL_NO_STATIC_CHAIN (decl)) regparm = 2; else regparm = 3; should be changed to take -fPIC into effect. -- What|Removed |Added Status|REOPENED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21518
[Bug target/21518] [4.0/4.1 Regression] unable to find a register to spill in class 'Q_REGS' with -fPIC and -O2
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-12 12:00 --- But the orginal code did not have regparm so we should not be changing the function to regparm 3 then. -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX | Summary|unable to find a register to|[4.0/4.1 Regression] unable |spill in class 'Q_REGS' with|to find a register to spill |-fPIC and -O2 |in class 'Q_REGS' with -fPIC ||and -O2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21518
[Bug c++/21528] Boost shared_ptr_test.cpp fails with -O3
--- Additional Comments From redi at gcc dot gnu dot org 2005-05-12 11:56 --- Using 4.0.1 20050509 on x86-64 Linux -O2 -finline-functions -finline-limit=79 is OK -O2 -finline-functions -finline-limit=80 is not -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21528
[Bug libffi/21285] gij fails to handle NullPointerException exception
-- What|Removed |Added Severity|critical|normal Component|libgcj |libffi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21285
[Bug c/21529] code size regression (+40%) with -Os from GCC-3.4.3 to 4.1
--- Additional Comments From giovannibajo at libero dot it 2005-05-12 11:48 --- Maybe SRA could be tuned differently for -Os. RTH, do you think it is feasable, or is it only a register allocator problem and should not be handled at the tree level at all? -- What|Removed |Added CC||rth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21529
[Bug rtl-optimization/20972] [4.0/4.1 Regression] Can't describe an early-clobber by an auto-inc
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-05-12 11:36 --- The ARM ARM says that STR Rd, [Rn], #4 and STR Rd, [Rn, #4]! are unpredictable if Rd == Rn. That is, the auto-inc side effect is permitted to take place before Rd is read. There's currently no way for a back-end to describe that an auto-inc operation might be an early-clobber. The obvious '&<>' in the constraint doesn't work, causing an abort in find_reloads(). This bug isn't really a regression (the limitation has always been there), but the vagaries of register allocation means that it is only recently that it's started doing this (either that, or the assembler has only recently started whining about it :-). -- What|Removed |Added CC||rearnsha at gcc dot gnu dot ||org Component|target |rtl-optimization Last reconfirmed|2005-04-12 17:08:16 |2005-05-12 11:36:06 date|| Summary|[4.0/4.1 Regression]|[4.0/4.1 Regression] Can't |Compiler-generated code |describe an early-clobber by |produces an assembler |an auto-inc |warning | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20972
[Bug target/21518] unable to find a register to spill in class 'Q_REGS' with -fPIC and -O2
--- Additional Comments From steven at gcc dot gnu dot org 2005-05-12 10:59 --- Andrew's test case shows that it is easy to make this fail with other GCC releases, and Jakub's comment #3 it seems that when constructs like this work, it only does so by luck. So, this is not really a regression, and it is also not really going to be fixed in GCC. -- What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX Summary|[4.0/4.1 Regression] error: |unable to find a register to |unable to find a register to|spill in class 'Q_REGS' with |spill in class 'Q_REGS' with|-fPIC and -O2 |-fPIC and -O2 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21518
[Bug tree-optimization/21531] New: 4.0/4.1 Regression __builtin_expect
GNU C - maybe related to my bugreport 21513 but different.
Error:
src/aie_sql_meta.c: In Funktion aie_sql_meta_create_index:
src/aie_sql_meta.c:258: Warnung: tableid koennte in dieser Funktion
uninitialisiert verwendet werden
src/aie_sql_meta.c:259: Warnung: index_typ koennte in dieser Funktion
uninitialisiert verwendet werden
make: *** [obj/aie_sql_meta.o] Fehler 1
int tableid;
int index_typ;
could be unitilized in this function. It can but if not it's not used.
Difference to GCC 3.4.3. It is set but within another function. The function
itself resides in the same sourcefile so imo gcc would be able to figure out
that they are either initilized or not used. Especially when compiled with the
compiler switch -funit-at-a-time . btw if the initialisation would be in another
C sourcefile then the warning is ok imo because the compiler cannot know the
content - as tody - of two sourcefiles at the same time.
The function is to create a SQL Index out of a predefined structure. The two
variables are set within the function aie_sql_meta_get_index_def_from_id - see
below.
The function it is as follows:
bool aie_sql_meta_create_index(int indexid, struct aie_sql_meta_db
*aie_sql_meta_db)
{
bool rc = true;
const char *index_name = aie_sql_meta_get_index_name_from_id(indexid,
aie_sql_meta_db);
if (__builtin_expect((index_name != NULL),true))
{
unsigned int size_index_def = 0;
int tableid;
int index_typ;
struct aie_sql_index_def *index_def =
aie_sql_meta_get_index_def_from_id(indexid, &tableid, &index_typ,
&size_index_def,
aie_sql_meta_db);
if (__builtin_expect(((index_def == NULL) ||
(size_index_def <= 0) ||
(tableid <= 0)),false))
{
sys_log("%s(%d):Fehler Meta SQL Table Def Create index "
"IndexID[%d] index [%s] TableID[%d]!",
__FILE__,
__LINE__,
indexid,
index_name,
tableid);
rc = false;
}
else
{
const char *table_name = aie_sql_meta_get_table_name_from_id(tableid,
aie_sql_meta_db);
if (__builtin_expect((table_name != NULL),true))
{
if (__builtin_expect(
(!aie_sql_create_index(aie_sql_meta_db->aie_sql_data,
table_name,
index_name,
index_typ,
true,
index_def,
size_index_def)),false))
{
sys_log("%s(%d):Fehler Meta SQL Create index "
"IndexID[%d] index [%s] Tableid[%d]!",
__FILE__,
__LINE__,
indexid,
index_name,
tableid);
rc = false;
}
}
else
{
sys_log("%s(%d):Fehler Meta SQL Create index Table nicht gefunden "
"IndexID[%d] index [%s] Tableid[%d]!",
__FILE__,
__LINE__,
indexid,
index_name,
tableid);
rc = false;
}
}
}
else
{
sys_log("%s(%d): Create Table ID[%d] Table ID nicht gefunden!",
__FILE__,
__LINE__,
indexid);
rc = false;
}
return(rc);
}
struct aie_sql_index_def *aie_sql_meta_get_index_def_from_id(int indexid,
int *tableid,
[Bug libstdc++/21530] New: libstdc++ not supported on this target
libstdc++ is not supported on h8300-hitachi-hms, so main configure should
skip it (as it does for h8500-*-*), otherwise sub-configure will bail out later.
Suggested patch:
--- gcc-3.4.3/configure
+++ gcc-3.4.3/configure
@@ -1232,7 +1232,7 @@
noconfigdirs="$noconfigdirs ${libgcj}"
;;
h8300*-*-*)
-noconfigdirs="$noconfigdirs target-libgloss ${libgcj} target-libf2c"
+noconfigdirs="$noconfigdirs target-libstdc++-v3 target-libgloss ${libgcj}
target-libf2c"
;;
h8500-*-*)
noconfigdirs="$noconfigdirs target-libstdc++-v3 target-libgloss ${libgcj}
target-libf2c"
--
Summary: libstdc++ not supported on this target
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc at mailinator dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux
GCC host triplet: i686-pc-linux
GCC target triplet: h8300-hitachi-hms
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21530
[Bug target/21501] [4.1 regression] ICE in extract_insn, at recog.c:2082
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-05-12 10:40 --- Now fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21501
[Bug c/21529] code size regression (+40%) with -Os from GCC-3.4.3 to 4.1
--- Additional Comments From steven at gcc dot gnu dot org 2005-05-12 10:39 --- Yada yada yada, you know the drill. SRA, out-of-ssa, and register allocation all working against each other: :; D.1605 = DI.IDE_found + (struct IDE_found_str *) ((long unsigned int) i * 8); tmp$reserved = D.1605->reserved; tmp$bios_order = D.1605->bios_order; tmp$irq = D.1605->irq; tmp$ideIOctrladr = D.1605->ideIOctrladr; tmp$ideIOadr = D.1605->ideIOadr; D.1605->reserved = save$reserved; D.1605->bios_order = save$bios_order; D.1605->irq = save$irq; D.1605->ideIOctrladr = save$ideIOctrladr; D.1605->ideIOadr = save$ideIOadr; i = i + 1; save$reserved = tmp$reserved; save$bios_order = tmp$bios_order; save$irq = tmp$irq; save$ideIOctrladr = tmp$ideIOctrladr; save$ideIOadr = tmp$ideIOadr; Wouldn't a block move be more efficient here than moving things one-by-one? -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||ra Last reconfirmed|-00-00 00:00:00 |2005-05-12 10:39:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21529
[Bug target/21501] [4.1 regression] ICE in extract_insn, at recog.c:2082
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-12 10:36 --- Subject: Bug 21501 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-05-12 10:36:15 Modified files: gcc: ChangeLog gcc/config/arm : arm.c Log message: PR target/21501 * arm.c (arm_gen_constant): Sign-extend intermediate values when synthesizing a constant of the difference of two immediates. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8743&r2=2.8744 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/arm/arm.c.diff?cvsroot=gcc&r1=1.456&r2=1.457 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21501
[Bug tree-optimization/21520] missing PRE opportunity with operand after operand
--- Additional Comments From steven at gcc dot gnu dot org 2005-05-12
10:23 ---
The failure I mentioned in comment #7 is caused by remove_dead_inserted_code,
which removes the statement setting that SSA name:
In the .pre dump file:
Removing unnecessary insertion:pretmp.308_35 = (unsigned char *)pretmp.307_36;
And the ICE message:
error: Missing definition for SSA_NAME: pretmp.308_35 in statement:
That remove_dead_inserted_code passlet doesn't work very well anyway, for
the original test case we also have dead code in the .pre dump:
do_locator1 (call)
{
int prephitmp.4;
int pretmp.3;
char prephitmp.2;
char pretmp.1;
int type;
char D.1566;
int D.1565;
:
if (call_3 != 0B) goto ; else goto ;
:;
goto ();
:;
type_7 = *call_3;
pretmp.1_2 = (char) type_7;
pretmp.3_10 = (int) pretmp.1_2;
# prephitmp.4_11 = PHI <1(3), pretmp.3_10(1)>;
# prephitmp.2_9 = PHI <1(3), pretmp.1_2(1)>;
# type_1 = PHI <1(3), type_7(1)>;
:;
D.1566_4 = prephitmp.2_9;
D.1565_5 = prephitmp.4_11;
return D.1565_5;
}
It may be better to just not have this ad-hoc DCE and move a real DCE pass
up in the pass schedule -- something like this:
Index: tree-optimize.c
===
RCS file: /cvs/gcc/gcc/gcc/tree-optimize.c,v
retrieving revision 2.90
diff -u -3 -p -r2.90 tree-optimize.c
--- tree-optimize.c 11 May 2005 02:24:42 - 2.90
+++ tree-optimize.c 12 May 2005 09:09:53 -
@@ -405,10 +405,10 @@ init_tree_optimization_passes (void)
NEXT_PASS (pass_split_crit_edges);
NEXT_PASS (pass_pre);
NEXT_PASS (pass_sink_code);
+ NEXT_PASS (pass_dce);
NEXT_PASS (pass_loop);
NEXT_PASS (pass_dominator);
NEXT_PASS (pass_copy_prop);
- NEXT_PASS (pass_dce);
/* FIXME: If DCE is not run before checking for uninitialized uses,
we may get false warnings (e.g., testsuite/gcc.dg/uninit-5.c).
However, this also causes us to misdiagnose cases that should be
@@ -418,8 +418,8 @@ init_tree_optimization_passes (void)
account for the predicates protecting the set and the use of each
variable. Using a representation like Gated Single Assignment
may help. */
- NEXT_PASS (pass_late_warn_uninitialized);
NEXT_PASS (pass_cd_dce);
+ NEXT_PASS (pass_late_warn_uninitialized);
NEXT_PASS (pass_dse);
NEXT_PASS (pass_forwprop);
NEXT_PASS (pass_phiopt);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21520
[Bug c++/21447] internal compiler error: output_operand
--- Additional Comments From dannysmith at users dot sourceforge dot net
2005-05-12 10:14 ---
(In reply to comment #4)
The patch for 21275 failed to take care of C++ class members which "inherit" a
dllimport attribute from the class type definition.
Here is a C++ testcase:
struct __attribute__ ((dllimport)) Foo
{
static int bar (void);
};
typedef int(*foobar)(void);
foobar my_foobar = (foobar) &Foo::bar;
int my_bar()
{
return my_foobar();
}
The code that marks Foo::bar as NON_ADDR_CONSTANT_P in winnt.c happens too
late.
I have a more invasive patch that fixes C and C++, replacing NON_ADDR_CONST_P
with a target hook (dll-supporting targets are currently the only ones that set
the tree_decl.non_addr_const_p flag). I'll submit as soon as I can access a
machine that will build and regtest Java on mingw.
Danny
--
What|Removed |Added
CC||dannysmith at users dot
||sourceforge dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21447
[Bug libstdc++/21526] libstdc++-v3 testsuite hangs on cygwin
--- Additional Comments From pcarlini at suse dot de 2005-05-12 10:02 --- In other terms, we should tell DejaGNU that all the tests involving fifos must be skipped on such platform, because fifos are available but not completely ok. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21526
[Bug c++/21510] Possible bug
--- Additional Comments From sven at clio dot in-berlin dot de 2005-05-12 09:48 --- (In reply to comment #1) > I don't think you used SFINF correctly. The substitution of the formal parameter with the actual argument fails, thus it is a form of substitution failure. I do not know, if the example is conforming to the standard. It would be a working method to distinguish between classes and non classes. On the other hand the more stricter interpretation is more safe. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21510
[Bug c/21529] New: code size regression (+40%) with -Os from GCC-3.4.3 to 4.1
Compiling this code with -Os is more than 40 % bigger in size with GCC-4.1
compared to GCC-3.4.3.
See also thread: http://gcc.gnu.org/ml/gcc/2005-05/msg00532.html
struct disk_interface_str {
unsignednb_IDE_found;
struct IDE_found_str {
unsigned short ideIOadr;
unsigned short ideIOctrladr;
unsigned char irq;
unsigned char bios_order;
unsigned short reserved;
} *IDE_found;
} DI;
void reorder_IDE_for_linux (void)
{
static const unsigned short idearray[] = {
0x1F0, 0x170,
0x1E8, 0x168,
0x1E0, 0x160,
};
unsigned short cpt, order;
for (order = 0; order < sizeof(idearray)/sizeof(idearray[0]); order++) {
for (cpt = order + 1; cpt < DI.nb_IDE_found; cpt++)
if (DI.IDE_found[cpt].ideIOadr == idearray[order])
break;
if (cpt < DI.nb_IDE_found) {
struct IDE_found_str save = DI.IDE_found[cpt];
unsigned short i;
for (i = order; i < cpt; i++) {
struct IDE_found_str tmp = DI.IDE_found[i];
DI.IDE_found[i] = save;
save = tmp;
}
DI.IDE_found[cpt] = save;
}
}
}
--
Summary: code size regression (+40%) with -Os from GCC-3.4.3 to
4.1
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: etienne_lorrain at yahoo dot fr
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i486-pc-linux-gnu
GCC host triplet: i486-pc-linux-gnu
GCC target triplet: i486-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21529
[Bug libstdc++/21526] libstdc++-v3 testsuite hangs on cygwin
--- Additional Comments From pcarlini at suse dot de 2005-05-12 09:41
---
Hum, this problem appear to imply that something is not completely ok
with the recent try_mkfifo -> dg-require-mkfifo switch. If I understand
correctly, before the latter we effectively skipped at runtime this test
on cygwin (and mingw):
int
try_mkfifo (const char* filename, mode_t mode)
{
#if defined (_NEWLIB_VERSION) || defined (__MINGW32_VERSION)
/* Newlib and MinGW32 do not have mkfifo. */
exit(0);
#else
return mkfifo(filename, mode);
#endif
}
Now the compile-type DejaGNU check *enables* the test... Mark?
--
What|Removed |Added
CC||mmitchel at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21526
