[Bug fortran/43062] NAMELIST attribute conflicts with ALLOCATABLE attribute
--- Comment #4 from zazzou at gmail dot com 2010-02-15 08:17 --- (In reply to comment #3) I've posted a question to c.l.f about this code. I believe the language of the standard is contradictory and as such the code can be interpreted as illegal or legal. http://groups.google.com/group/comp.lang.fortran/browse_frm/thread/76b23c9927b52161# Into the final committee draft J3/03-007R2, section 5.4, I found : C574 (R553) A namelist-group-object shall not be an assumed-size array. It was not the case in F95. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43062
[Bug c/43073] New: building arm cross-compiler fails when attempting to build regex library
I can bootstrap a cross-compiler with no target system library with GCC 4.3.3,
but using the same configuration options causes a failure when building GCC
4.4.3. It appears to be attempting to build the regex function of libiberty
for the target, and failing because there isn't a target system library
available. I'm not sure why 4.4.3 wants to build that when 4.3.3 did not. My
configuration options are based on what Codesourcery uses for arm-none-eabi in
their 2009q3 toolchain.
Configuration:
../gcc-%{version}/configure \
--prefix=/usr \
--mandir=/usr/share/man \
--infodir=/usr/share/info \
--target=arm-none-eabi \
--disable-libmudflap \
--disable-libssp \
--disable-libstdcxx-pch \
--enable-extra-sgxxlite-multilibs \
--with-gnu-as \
--with-gnu-ld \
'--with-specs=%{O2:%{!fno-remove-local-statics: -fremove-local-statics}}
%{O*:%{O|O0|O1|O2|Os:;:%{!fno-remove-local-statics: -fremove-local-statics}}}'
\
--enable-languages=c \
--enable-shared \
--disable-lto \
--with-newlib \
--disable-nls \
--disable-libgomp \
--without-headers \
--disable-decimal-float \
--disable-libffi \
--with-system-zlib \
--enable-version-specific-runtime-libs \
--enable-interwork \
--enable-poison-system-directories
Failure when building 4.4.3:
checking for a 64-bit type... unsigned long long
checking for pid_t... no
checking for working strncmp... no
updating cache ./config.cache
configure: creating ./config.status
config.status: creating Makefile
config.status: creating testsuite/Makefile
config.status: creating config.h
config.status: executing default commands
Adding multilib support to Makefile in ../../../../gcc-4.4.3/libiberty
with_multisubdir=thumb
make[2]: Entering directory
`/home/eric/rpmbuild/BUILD/arm-none-eabi-gcc-bootstrap-4.4.3/gcc-arm-none-eabi/arm-none-eabi/libiberty'
if [ x-fPIC != x ] [ ! -d pic ]; then \
mkdir pic; \
else true; fi
touch stamp-picdir
if [ x-fPIC != x ]; then \
/home/eric/rpmbuild/BUILD/arm-none-eabi-gcc-bootstrap-4.4.3/gcc-arm-none-eabi/./gcc/xgcc
-B/home/eric/rpmbuild/BUILD/arm-none-eabi-gcc-bootstrap-4.4.3/gcc-arm-none-eabi/./gcc/
-B/usr/arm-none-eabi/bin/ -B/usr/arm-none-eabi/lib/ -isystem
/usr/arm-none-eabi/include -isystem /usr/arm-none-eabi/sys-include -c
-DHAVE_CONFIG_H -g -O2-I. -I../../../gcc-4.4.3/libiberty/../include -W
-Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic -fPIC
../../../gcc-4.4.3/libiberty/regex.c -o pic/regex.o; \
else true; fi
../../../gcc-4.4.3/libiberty/regex.c:51:25: error: sys/types.h: No such file or
directory
[...lots more errors due to missing sys/types.h omitted here...]
../../../gcc-4.4.3/libiberty/regex.c:8112: warning: incompatible implicit
declaration of built-in function 'free'
../../../gcc-4.4.3/libiberty/regex.c:8121: error: 'regex_t' has no member named
'fastmap_accurate'
make[2]: *** [regex.o] Error 1
make[2]: Leaving directory
`/home/eric/rpmbuild/BUILD/arm-none-eabi-gcc-bootstrap-4.4.3/gcc-arm-none-eabi/arm-none-eabi/libiberty'
make[1]: *** [all-target-libiberty] Error 2
make[1]: Leaving directory
`/home/eric/rpmbuild/BUILD/arm-none-eabi-gcc-bootstrap-4.4.3/gcc-arm-none-eabi'
make: *** [all] Error 2
--
Summary: building arm cross-compiler fails when attempting to
build regex library
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eric at brouhaha dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: arm-none-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43073
[Bug lto/43071] ICE: SIGSEGV with -fwhopr -fcompare-debug
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-02-15 09:30 --- Ha, you fool! C++ debug information is one thing that doesn't really work with LTO. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||lto http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43071
[Bug c++/43070] [4.5 Regression] g++.dg/ext/label2.C fails to compile at -O1
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|tree-optimization |c++ Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43070
[Bug tree-optimization/43068] [4.5 Regression] ICE: in estimate_operator_cost, at tree-inline.c:3141 with -freorder-blocks -ftracer
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-02-15 09:39 --- Whoo, a NON_LVALUE_EXPR. From /* PTR +p 0 - PTR */ if (integer_zerop (arg1)) return non_lvalue_loc (loc, fold_convert_loc (loc, type, arg0)); bah. I have a patch. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-02-15 09:39:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43068
[Bug tree-optimization/43074] New: [4.4/4.5 Regression] ICE in vectorizable_reduction, at tree-vect-loop.c:3491
float
pvslockprocess(float *fout, float *fin, int framesize)
{
int i;
float mag=0.0f, diff;
for (i = 0; i framesize; i += 2) {
mag += fin[i];
fout[i] = fin[i];
fout[i+1] = fin[i+1];
}
return mag;
}
gcc-4.5 -O3 -ffast-math t.3.3.i
t.3.3.i: In function 'pvslockprocess':
t.3.3.i:2:1: internal compiler error: in vectorizable_reduction, at
tree-vect-loop.c:3491
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
gcc-4.4 -O3 -ffast-math t.3.3.i
t.3.3.i: In function pvslockprocess:
t.3.3.i:2: internal compiler error: in vect_get_vec_def_for_operand, at
tree-vect-transform.c:1999
Please submit a full bug report,
with preprocessed source if appropriate.
See http://bugs.opensuse.org/ for instructions.
--
Summary: [4.4/4.5 Regression] ICE in vectorizable_reduction, at
tree-vect-loop.c:3491
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43074
[Bug tree-optimization/43074] [4.4/4.5 Regression] ICE in vectorizable_reduction, at tree-vect-loop.c:3491
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||irar at gcc dot gnu dot org Target Milestone|--- |4.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43074
[Bug target/40667] [4.4/4.5 Regression] stack frames are generated even with -fomit-frame-pointer
--- Comment #26 from mikulas at artax dot karlin dot mff dot cuni dot cz 2010-02-15 10:34 --- Comment #25: I don't understand your logic, what does attribute((noreturn)) have to do with a stack frame? The only valid reasons for generating a stack frame are alloca() or needed stack realignment. Other functions calls, either returning or noreturn don't need a frame. Note that attribute((noreturn)) functions normally don't trigger a stack frame. That example function was actually carefully minimized from a larger real-world function. If you change the content of the loop, the stack frame won't be generated. It looks like there is something rotten in gcc. -- mikulas at artax dot karlin dot mff dot cuni dot cz changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40667
[Bug libstdc++/43075] New: [4.5 Regression] 20_util/bind/ref2.cc FAILs at -O0
make check-target-libstdc++-v3 RUNTESTFLAGS=--target_board=unix/-O0 conformance.exp=20_util/bind/ref2.cc FAIL: 20_util/bind/ref2.cc execution test === libstdc++ Summary === # of expected passes1 # of unexpected failures1 -- Summary: [4.5 Regression] 20_util/bind/ref2.cc FAILs at -O0 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43075
[Bug libstdc++/43075] [4.5 Regression] 20_util/bind/ref2.cc FAILs at -O0
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43075
[Bug lto/43071] ICE: SIGSEGV with -fwhopr -fcompare-debug
--- Comment #3 from zsojka at seznam dot cz 2010-02-15 11:27 --- Created an attachment (id=19876) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19876action=view) reduced testcase Seems I forgot the testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43071
[Bug tree-optimization/43068] [4.5 Regression] ICE: in estimate_operator_cost, at tree-inline.c:3141 with -freorder-blocks -ftracer
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-02-15 11:28 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43068
[Bug tree-optimization/43068] [4.5 Regression] ICE: in estimate_operator_cost, at tree-inline.c:3141 with -freorder-blocks -ftracer
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-02-15 11:28 --- Subject: Bug 43068 Author: rguenth Date: Mon Feb 15 11:27:54 2010 New Revision: 156770 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156770 Log: 2010-02-15 Richard Guenther rguent...@suse.de PR middle-end/43068 * cgraphunit.c (thunk_adjust): Skip adjusting by fixed_offset if that is zero. * g++.dg/torture/pr43068.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/torture/pr43068.C Modified: trunk/gcc/ChangeLog trunk/gcc/cgraphunit.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43068
[Bug libstdc++/43075] [4.5 Regression] 20_util/bind/ref2.cc FAILs at -O0
--- Comment #1 from paolo dot carlini at oracle dot com 2010-02-15 11:44 --- If you really think this is a purely libstdc++ issue we gonna need *a lot* of help from the compiler people. Also consider that Jonathan, the author of the recent improvements to std::bind, will be in vacations for 2 weeks. Anyway, how can this be a [4.5 Regression] if the testcase didn't exist in 4.4 and, more specifically, uses C++0x features which do not make sense together with the 4.4 std::bind, which is just was the std::tr1::bind in the std:: namespace? -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||jwakely dot gcc at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43075
[Bug fortran/41869] ICE segfault when reading module file
--- Comment #7 from pault at gcc dot gnu dot org 2010-02-15 11:57 --- Since Tobias and I already did the business on trunk, I suppose that one of us should take ownership of it. Do we backport to 4.4 or just close it? I would go for the backporting. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2009-12-06 15:18:49 |2010-02-15 11:57:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41869
[Bug libstdc++/43075] [4.5 Regression] 20_util/bind/ref2.cc FAILs at -O0
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-02-15 12:19 --- (In reply to comment #1) If you really think this is a purely libstdc++ issue we gonna need *a lot* of help from the compiler people. Also consider that Jonathan, the author of the recent improvements to std::bind, will be in vacations for 2 weeks. Well, usually FAILs at -O0 but not -O2 hint at lifetime problems such as references to local vars being returned. Note that a patch of mine exposes this issue at -O2 ... so it's blocked by this issue. Anyway, how can this be a [4.5 Regression] if the testcase didn't exist in 4.4 and, more specifically, uses C++0x features which do not make sense together with the 4.4 std::bind, which is just was the std::tr1::bind in the std:: namespace? So the testcase is bogus? Then please remove it. I marked it as a regression prematurely because the patch I really want to apply will expose it at -O2 - which then makes it a regression against an earlier revision of trunk. And I'm quite lost in the myriads of variadic templates when trying to figure out what is going wrong (I tried for several hours already). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43075
[Bug debug/43051] [4.5 Regression] VTA causes a stack living parameter unavailable in most of the function
--- Comment #4 from jakub at gcc dot gnu dot org 2010-02-15 12:21 --- Created an attachment (id=19877) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19877action=view) gcc45-pr43051.patch Patch that fixes this issue and I'm going to bootstrap/regtest now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43051
[Bug libstdc++/43075] [4.5 Regression] 20_util/bind/ref2.cc FAILs at -O0
--- Comment #3 from paolo dot carlini at oracle dot com 2010-02-15 12:27 --- So the testcase is bogus? Then please remove it. Nobody said is bogus. I said it didn't exist in 4.4, thus can't be a regression. Maybe we should xfail it, if we cannot understand in time what's going on. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43075
[Bug c++/43076] New: ICE: SIGSEGV with invalid C++ code after giving diagnostics
Command line:
g++ testcase.cpp
--- testcase.cpp ---
struct S;
template typename struct T
{
template typename
template bool struct T S
{
void f () {
Tested revisions:
trunk r156745 - crash
trunk r153685 - crash
4.4 r156256 - crash
4.4 r155365 - crash
==9549== Memcheck, a memory error detector
==9549== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==9549== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==9549== Command:
/mnt/svn/gcc-trunk/binary-156745-lto/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/cc1plus
-quiet -D_GNU_SOURCE testcase.cpp -quiet -dumpbase testcase.cpp -mtune=generic
-auxbase testcase -o /tmp/cczcVQ4e.s
==9549==
testcase.cpp:5:28: error: specialization of 'templateclass struct T' must
appear at namespace scope
testcase.cpp:5:28: error: template parameters not used in partial
specialization:
testcase.cpp:5:28: error: 'anonymous'
testcase.cpp:7:15: error: expected '}' at end of input
testcase.cpp:7:15: error: expected unqualified-id at end of input
testcase.cpp:7:15: error: expected '}' at end of input
==9549== Invalid read of size 2
==9549==at 0x4F146F: push_template_decl_real (pt.c:4482)
==9549==by 0x4CF96F: start_preparsed_function (decl.c:11778)
==9549==by 0x566DD1: cp_parser_type_specifier (parser.c:19210)
==9549==by 0x572D61: cp_parser_decl_specifier_seq (parser.c:9214)
==9549==by 0x57C5AD: cp_parser_single_declaration (parser.c:18824)
==9549==by 0x57CB72: cp_parser_template_declaration_after_export
(parser.c:18735)
==9549==by 0x5824B9: cp_parser_declaration (parser.c:8702)
==9549==by 0x581DC9: cp_parser_declaration_seq_opt (parser.c:8633)
==9549==by 0x5830C4: c_parse_file (parser.c:3090)
==9549==by 0x64ACDE: c_common_parse_file (c-opts.c:1279)
==9549==by 0x8F664B: toplev_main (toplev.c:1053)
==9549==by 0x658EBBC: (below main) (in /lib64/libc-2.11.so)
==9549== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==9549==
testcase.cpp:7:15: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
==9549==
--
Summary: ICE: SIGSEGV with invalid C++ code after giving
diagnostics
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zsojka at seznam dot cz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43076
[Bug tree-optimization/43074] [4.4/4.5 Regression] ICE in vectorizable_reduction, at tree-vect-loop.c:3491
-- irar at il dot ibm dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |irar at il dot ibm dot com |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-02-15 12:39:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43074
[Bug libstdc++/43075] [4.5 Regression] 20_util/bind/ref2.cc FAILs at -O0
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-02-15 13:16 ---
It also fails with -O1 and -O2 -fno-strict-aliasing and with -O2 -fno-inline.
Assembler differences for -O2 vs. -O2 with my patch (which effectively
makes us see more must-aliases, thus accept slightly invalid
strict-aliasing violating code):
--- ref2.s.good 2010-02-15 13:47:03.0 +0100
+++ ref2.s.bad 2010-02-15 13:46:34.0 +0100
@@ -90,15 +90,16 @@
.cfi_startproc
subq$40, %rsp
.cfi_def_cfa_offset 48
- leaq28(%rsp), %rsi
+ leaq28(%rsp), %rdx
movl$1, 28(%rsp)
movq$_ZNK3Inc1fERi, (%rsp)
movq$0, 8(%rsp)
leaq16(%rsp), %rdi
- movq%rsi, 16(%rsp)
+ movq%rdx, 16(%rsp)
movb%al, 16(%rsp)
movl$_ZNK3Inc1fERi, %eax
testb $1, %al
+ movq16(%rsp), %rsi
je .L10
movq_ZNK3Inc1fERi-1(%rsi), %rax
.L10:
that's _Z6test02v. You can see the aliasing byte-store to 16(%rsp) and
the probably seemingly redundant load from 16(%rsp) that we maybe remove
with strict-aliasing on.
The tree code for the above is at .optimize time:
bb 2:
counter = 1;
D.29754 = {};
__bound_args#0 = D.29754;
D.25693._M_f.__pmf.__pfn = f;
D.25693._M_f.__pmf.__delta = 0;
D.25693._M_bound_args.D.25507.D.25257.D.25050._M_head_impl._M_data =
counter;
this.24_34 = (struct Inc *) D.25693._M_bound_args.D.25507;
*this.24_34 = __bound_args#0;
D.29831_51 =
D.25693._M_bound_args.D.25507.D.25257.D.25050._M_head_impl._M_data;
iftmp.27_55 = D.25693._M_f.__pmf.__pfn;
D.29837_56 = (long int) iftmp.27_55;
D.29838_57 = D.29837_56 1;
if (D.29838_57 != 0)
goto bb 3;
else
goto bb 4;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43075
[Bug debug/43077] New: VTA issues caused by SSA expand
In the following testcase in both foo and baz functions var[abc] debuginfo
is lost during SSA expansion (unlike e.g. with redhat/gcc-4_4-branch VTA which
doesn't do SSA expansion):
int varb;
int __attribute__((noinline))
foo (void)
{
int vara = (varb == 3);
asm volatile ( : : g (vara));
return 0;
}
int __attribute__((noinline))
bar (unsigned long *p, unsigned long *q)
{
int ret;
asm volatile ( : =r (ret), =r (*p), =r (*q) : 0 (1), 1 (2), 2
(3));
return ret;
}
int __attribute__((noinline))
baz (void)
{
unsigned long a = 0, b = 0, c = 0;
a = bar (b, c);
unsigned long vara = a;
unsigned long varb = b;
unsigned long varc = c;
__asm__ volatile ( : : g (vara), g (varb), g (varc));
return a;
}
int
main (void)
{
foo ();
baz ();
return 0;
}
In *.optimized we have on redhat/gcc-4_4-branch:
foo
# DEBUG vara = varb == 3
__asm__ __volatile__( : : g varb == 3);
baz:
D.1615D.1615 = bar (b, c);
# DEBUG D#1 = (long unsigned int) D.1615D.1615
# DEBUG a = D#1
# DEBUG vara = D#1
# DEBUG D#2 = b
# DEBUG varb = D#2
# DEBUG D#3 = c
# DEBUG varc = D#3
__asm__ __volatile__( : : g (long unsigned int) D.1615D.1615, g b, g
c);
and on the trunk:
foo:
varb.0_1 = varb;
vara_2 = varb.0_1 == 3;
# DEBUG vara = vara_2
__asm__ __volatile__( : : g vara_2);
baz:
D.2742_2 = bar (b, c);
a_3 = (long unsigned int) D.2742_2;
# DEBUG a = a_3
# DEBUG vara = a_3
varb_5 = b;
# DEBUG varb = varb_5
varc_6 = c;
# DEBUG varc = varc_6
__asm__ __volatile__( : : g a_3, g varb_5, g varc_6);
On redhat/gcc-4_4-branch then expansion has debug insns which still track where
the variables really live:
foo:
(debug_insn 5 4 6 3 P.c:6 (var_location:SI vara (eq:SI (mem/c/i:SI
(symbol_ref:DI (varb) var_decl 0x7f668363e820 varb) [2 varb+0 S4 A32])
(const_int 3 [0x3]))) -1 (nil))
baz:
(debug_insn 14 13 15 3 P.c:23 (var_location:DI D.4294967295 (zero_extend:DI
(reg:SI 58 [ D.1615 ]))) -1 (nil))
(debug_insn 15 14 16 3 P.c:23 (var_location:DI a (debug_expr:DI D#1)) -1 (nil))
(debug_insn 16 15 17 3 P.c:24 (var_location:DI vara (debug_expr:DI D#1)) -1
(nil))
(debug_insn 17 16 18 3 P.c:25 (var_location:DI D.4294967294 (mem/c/i:DI
(plus:DI (reg/f:DI 54 virtual-stack-vars) (const_int -8 [0xfff8]))
[3 b+0 S8 A64])) -1 (nil))
(debug_insn 18 17 19 3 P.c:25 (var_location:DI varb (debug_expr:DI D#2)) -1
(nil))
(debug_insn 19 18 20 3 P.c:26 (var_location:DI D.4294967293 (mem/c/i:DI
(plus:DI (reg/f:DI 54 virtual-stack-vars) (const_int -16 [0xfff0]))
[3 c+0 S8 A64])) -1 (nil))
(debug_insn 20 19 21 3 P.c:26 (var_location:DI varc (debug_expr:DI D#3)) -1
(nil))
but on the trunk in *.expand we have:
foo:
(debug_insn 5 4 6 3 P.c:6 (var_location:SI vara (reg/v:SI 59 [ vara ])) -1
(nil))
(insn 6 5 7 3 P.c:7 (set (reg:CCZ 17 flags) (compare:CCZ (mem/c/i:SI
(symbol_ref:DI (varb) var_decl 0x7f158a318000 varb) [2 varb+0 S4 A32])
(const_int 3 [0x3]))) -1 (nil))
(insn 7 6 8 3 P.c:7 (set (reg:QI 62) (eq:QI (reg:CCZ 17 flags) (const_int 0
[0x0]))) -1 (nil))
(insn 8 7 9 3 P.c:7 (parallel [(set (reg:SI 61) (zero_extend:SI (reg:QI 62)))
(clobber (reg:CC 17 flags))]) -1 (nil))
(insn 9 8 10 3 P.c:7 (parallel [(asm_operands/v () () 0 [(reg:SI 61)]...
baz:
(debug_insn 14 13 15 3 P.c:23 (var_location:DI a (reg/v:DI 59 [ a ])) -1 (nil))
(debug_insn 15 14 16 3 P.c:24 (var_location:DI vara (reg/v:DI 59 [ a ])) -1
(nil))
(debug_insn 16 15 17 3 P.c:25 (var_location:DI varb (reg/v:DI 60 [ varb ])) -1
(nil))
(debug_insn 17 16 18 3 P.c:26 (var_location:DI varc (reg/v:DI 61 [ varc ])) -1
(nil))
(insn 18 17 19 3 P.c:27 (set (reg:DI 65) (sign_extend:DI (reg:SI 58 [ D.2742
]))) -1 (nil))
(insn 19 18 20 3 P.c:27 (parallel [(asm_operands/v () () 0 [(reg:DI 65)
(mem/c/i:DI (plus:DI (reg/f:DI 54 virtual-stack-vars) (const_int -8
[0xfff8])) [3 b+0 S8 A64]) (mem/c/i:DI (plus:DI (reg/f:DI 54
virtual-stack-vars) (const_int -16 [0xfff0])) [3 c+0 S8 A128])]...
The problem is that pseudo 59 in foo resp. pseudos in 59/60/61 in baz are only
referenced in the debug_insns, never initialized or used in actual code and
therefore are pretty soon just changed into (clobber (const_int 0)). I believe
this is because SSA expansion in some cases (e.g. for the asm operand g) does
a TER, so DECL_RTL of the SSA_NAME isn't actually used. I guess we'd need to
TER in this case also into the DEBUG_INSN locations, but not sure when exactly
to do that.
This is quite important e.g. for SystemTap, as asm g input operands with some
short lived vars in a macro is something that is used in user probes, and
SystemTap then expects to find the values of those vars in the debuginfo.
--
Summary: VTA issues caused by SSA expand
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: wrong-debug
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu
[Bug c++/42911] [4.5 Regression] huge compile time with -g -O2
--- Comment #4 from jakub at gcc dot gnu dot org 2010-02-15 13:52 --- This is something http://gcc.gnu.org/ml/gcc-patches/2010-01/msg01015.html patch with a default limit like 5000 cures. The function is simple too huge after all the inlining for var-tracking purposes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42911
[Bug fortran/43078] New: gfortran: spurious warning of line truncation at col 72
ANSI X3.9-1978 defines Fortran line length as 72. But gfortran permits only 71
characters before issuing a warning. For example, this valid Fortran source
code:
WRITE ( *, '(1X,A3,F15.6,'' ='',F15.6,''+'',F14.6,'' =''' //
: 'I5,2(''/'',I2.2),I3,2('':'',I2.2),''.'',I6.6)' )
: SCALE, D1+D2, D1, D2, IY, IM, ID, IHMSF
produces this warning:
: SCALE, D1+D2, D1, D2, IY, IM, ID, IHMSF
1
Warning: Line truncated at (1)
--
Summary: gfortran: spurious warning of line truncation at col 72
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: patrick dot wallace at stfc dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43078
[Bug libstdc++/43075] [4.5 Regression] 20_util/bind/ref2.cc FAILs at -O0
--- Comment #5 from paolo dot carlini at oracle dot com 2010-02-15 14:02 --- What I see right now is that Inc::f is called but i != counter. Instead, in the first test, that at line #53 of ref2.cc, Inc::operator() is called with i == counter, and everything is fine. I also tried moving out of line the member functions at lines #540 and #570 of functional, and also Int::f, and nothing changes at -O2, still doesn't fail, thus it's the inlining of something earlier in the call chain which makes a difference, and where we have to chase the temporary, it looks like. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43075
[Bug debug/43051] [4.5 Regression] VTA causes a stack living parameter unavailable in most of the function
--- Comment #5 from jakub at gcc dot gnu dot org 2010-02-15 14:10 --- While the patch bootstrapped/regtested on i686-linux (all,obj-c++,lto but no ada) and resulted in quite substantial changes on .debug_info/.debug_loc - .debug_info on cc1 grew by ~ 11.1% from 16513941 to 18581214 bytes and .debug_loc grew by 48.1% from 6749001 to 13013048 bytes (one would hope that is better debug info quality), it unfortunately didn't bootstrap on x86_64-linux (all,obj-c++,lto,ada), with an ICE while compiling 32-bit g-sehash.adb in delete_slot_part - the gcc_assert (changed) line. p debug_rtx (loc) (mem/c:SI (value/s/u:SI 175:3747 @0x1f4c4b8/0x1f4d2e0) [22 %sfp+-332 S4 A32]) p debug_rtx (var-var_part[0].cur_loc) (mem/c:SI (value/s/u:SI 148:3703 @0x1f4c170/0x1f4be30) [26 S4 A32]) I guess this is related to the patch, the two VALUEs probably either at some point or even currently point to the same thing. The question is what should we do about it, easiest would be just not to assert changed is true, but just set it if the location list is empty. Is that the only spot that needs changing though? E.g. dataflow_set_remove_mem_locs does something similar... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43051
[Bug libstdc++/43075] [4.5 Regression] 20_util/bind/ref2.cc FAILs at -O0
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-02-15 14:15 ---
D.25693._M_bound_args.D.25507.D.25257.D.25050._M_head_impl._M_data =
counter;
this.24_34 = (struct Inc *) D.25693._M_bound_args.D.25507;
*this.24_34 = __bound_args#0;
D.29831_51 =
D.25693._M_bound_args.D.25507.D.25257.D.25050._M_head_impl._M_data;
Thus with my patch we no longer CSE the load from _M_data with counter but
instead load it again because the store to D.25693._M_bound_args.D.25507
aliases it.
Note that appearantly struct Inc D.29754 has zero size (and is packed to
overlap with _M_data), and we expand it like
;; D.29754 = {};
(insn 6 5 0
/abuild/rguenther/trunk-g/x86_64-unknown-linux-gnu/libstdc++-v3/include/functional:1377
(clobber (reg:QI 77 [ D.29754 ])) -1 (nil))
;; __bound_args#0 = D.29754;
(insn 7 6 0
/abuild/rguenther/trunk-g/x86_64-unknown-linux-gnu/libstdc++-v3/include/functional:1377
(set (reg/v:QI 78 [ __bound_args#0 ])
(reg:QI 77 [ D.29754 ])) -1 (nil))
but the copy and later the indirect store transfers 1 byte of garbage.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43075
[Bug c++/43079] New: [4.5 Regression] ICE with incompatible pointer-to-member-function as template parameter
The following invalid code snippet triggers an ICE on trunk:
===
struct A {};
struct B
{
void foo() const;
void foo();
};
templatevoid (A::*)() void bar();
void baz()
{
barB::foo();
}
===
bug.cc: In function 'void baz()':
bug.cc:13:16: internal compiler error: in convert_nontype_argument, at
cp/pt.c:5132
Please submit a full bug report, [etc.]
--
Summary: [4.5 Regression] ICE with incompatible pointer-to-
member-function as template parameter
Product: gcc
Version: 4.5.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=43079
[Bug c++/43079] [4.5 Regression] ICE with incompatible pointer-to-member-function as template parameter
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43079
[Bug libstdc++/43075] [4.5 Regression] 20_util/bind/ref2.cc FAILs at -O0
--- Comment #7 from paolo dot carlini at oracle dot com 2010-02-15 14:21 --- For sure Inc doesn't have any non-static data members... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43075
[Bug c++/43080] New: ICE with anonymous union and -flto
The following valid code snippet triggers an ICE on trunk when compiled with
-flto -g:
===
inline int foo()
{
static union { int i; };
return i;
}
void bar()
{
foo();
}
===
bug.cc: In function 'foo()':
bug.cc:5:1: internal compiler error: in gimple_decl_printable_name, at
gimple.c:4610
Please submit a full bug report, [etc.]
--
Summary: ICE with anonymous union and -flto
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, monitored, lto
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=43080
[Bug c++/43081] New: [c++0x] ICE with invalid use of lambda expression
The following invalid code snippet triggers an ICE on trunk:
===
struct A
{
typedef void (F)();
F f = []{};
};
===
bug.cc:4:12: internal compiler error: in grokfield, at cp/decl2.c:911
Please submit a full bug report, [etc.]
--
Summary: [c++0x] ICE with invalid use of lambda expression
Product: gcc
Version: 4.5.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=43081
[Bug libstdc++/15047] libstdc++ testing does not work remotely
--- Comment #15 from drow at gcc dot gnu dot org 2010-02-15 14:34 --- I no longer care whether this works; I don't do build-tree testing. It's probably still broken, but with no one using it, closing as WONTFIX. -- drow at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15047
[Bug c++/41997] [C++0x] constant initializer_list not optimised
--- Comment #5 from jason at gcc dot gnu dot org 2010-02-15 14:50 --- Fixed for 4.5. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41997
[Bug c++/42060] [4.4 Regression] [c++0x] ICE throwing array with initializer list
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |paolo at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42060
[Bug c++/42060] [4.4 Regression] [c++0x] ICE throwing array with initializer list
--- Comment #3 from jason at gcc dot gnu dot org 2010-02-15 14:51 --- Marking as fixed. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42060
[Bug libstdc++/43075] [4.5 Regression] 20_util/bind/ref2.cc FAILs at -O0
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-02-15 14:53 ---
The issue _seems_ to be that the indirect assignment
;; *this.24_34 = __bound_args#0;
is from
;; Function std::_Head_base_Idx, _Head, true::_Head_base(_UHead) [with
_UHead = Inc, long unsigned int _Idx = 0ul, _Head = Inc] (null)
;; enabled by -tree-original
{
cleanup_point Unknown tree: expr_stmt
(void) (*(struct Inc *) this = *(const struct Inc ) (const struct Inc *)
std::forwardInc ((struct type ) (struct Inc *) __h))
;
}
where we do not see its zero-sizeness(?) and thus end up not removing the
zero-sized assignment during cp_genericize_r.
Bah, because it's an INIT_EXPR, not a MODIFY_EXPR.
I have a patch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot
|dot org |org
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2010-02-15 14:53:16
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43075
[Bug c++/43080] ICE with anonymous union and -flto
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-02-15 15:03 --- We remove anonymous names to not break cross-TU merging. Looks like we need to resurrect them or mark them as anonymous for merging instead of throwing them away. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43080
[Bug c++/43036] [4.3/4.4/4.5 Regression] c++ compilation hang
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-02-13 10:45:17 |2010-02-15 15:22:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43036
[Bug c++/43036] [4.3/4.4/4.5 Regression] c++ compilation hang
--- Comment #15 from jason at gcc dot gnu dot org 2010-02-15 15:29 --- Further reduced: typedef char T6[2][8]; const T6* p1; typedef char T[8]; typedef T T2[2]; typedef T T3[2]; typedef char T5[2][8]; const T2* p2; const T5* p3; const T3* p4; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43036
[Bug libgcj/40860] [4.4/4.5 regression] regressions in libjava testsuite on arm-linux
--- Comment #7 from doko at ubuntu dot com 2010-02-15 15:32 --- this seems to be the patch for the ARM unwind table linker processing? if yes, see http://sourceware.org/bugzilla/show_bug.cgi?id=10695 for some comments. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40860
[Bug other/43082] New: ICE in tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p
seen with 4.3, 4.4 and trunk: $ gcc -c main.i main.c: In function 'main': main.c:22:5: error: void value not ignored as it ought to be main.c:22:5: error: void value not ignored as it ought to be main.c:22:8: internal compiler error: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at tree-ssa.c:1233 Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-snapshot/README.Bugs for instructions. -- Summary: ICE in tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: doko at ubuntu dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43082
[Bug other/43082] ICE in tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p
--- Comment #1 from doko at ubuntu dot com 2010-02-15 15:47 --- Created an attachment (id=19878) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19878action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43082
[Bug libstdc++/23271] Members of ctype_base appear not to be integral constant expressions.
--- Comment #6 from paolo dot carlini at oracle dot com 2010-02-15 15:53 --- Dave, any hints about this cygwin issue? -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||dave dot korn dot cygwin at ||gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23271
[Bug c++/43079] [4.5 Regression] ICE with incompatible pointer-to-member-function as template parameter
--- Comment #1 from hjl dot tools at gmail dot com 2010-02-15 15:55 --- It is caused by revision 154336: http://gcc.gnu.org/ml/gcc-cvs/2009-11/msg00557.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||jason at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43079
[Bug debug/43051] [4.5 Regression] VTA causes a stack living parameter unavailable in most of the function
--- Comment #6 from jakub at gcc dot gnu dot org 2010-02-15 16:13 --- Created an attachment (id=19879) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19879action=view) additional patch With this incremental patch it bootstrapped/regtested even on x86_64-linux. On x86_64-linux cc1 there are almost no debuginfo differences, but as I said earlier on i686-linux it matters a lot: number of dies with DW_AT_location attribute before/after: readelf -wi obj598/gcc/cc1 | grep DW_AT_location | wc -l; readelf -wi obj600/gcc/cc1 | grep DW_AT_location | wc -l 158673 226078 number of location lists in .debug_loc before/after: readelf -wo obj598/gcc/cc1 | grep 'End of' | wc -l; readelf -wo obj600/gcc/cc1 | grep 'End of' | wc -l 116508 182037 and number of ranges with a valid location before/after: readelf -wo obj598/gcc/cc1 | grep DW_OP_ | wc -l; readelf -wo obj600/gcc/cc1 | grep DW_OP_ | wc -l 495513 980535 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43051
[Bug c++/43036] [4.3/4.4/4.5 Regression] c++ compilation hang
--- Comment #16 from hjl dot tools at gmail dot com 2010-02-15 16:44
---
I have no idea if this patch makes any senses:
---
diff --git a/gcc/cp/tree.c b/gcc/cp/tree.c
index d2ab4f0..5ac5f09 100644
--- a/gcc/cp/tree.c
+++ b/gcc/cp/tree.c
@@ -822,7 +822,7 @@ cp_build_qualified_type_real (tree type,
{
t = build_cplus_array_type_1 (element_type, TYPE_DOMAIN (type));
- if (TYPE_MAIN_VARIANT (t) != TYPE_MAIN_VARIANT (type))
+ if (!same_type_ignoring_top_level_qualifiers_p (t, type))
{
/* Set the main variant of the newly-created ARRAY_TYPE
(with cv-qualified element type) to the main variant of
---
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43036
[Bug rtl-optimization/43058] [4.5 Regression] var-tracking uses up all virtual memory
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-02-15 16:57 ---
The following doesn't make too much sense:
static bool
cgraph_mark_inline_edge (struct cgraph_edge *e, bool update_original,
VEC (cgraph_edge_p, heap) **new_edges)
{
...
/* Now update size of caller and all functions caller is inlined into. */
for (;e !e-inline_failed; e = e-caller-callers)
{
to = e-caller;
old_size = e-caller-global.size;
new_size = cgraph_estimate_size_after_inlining (1, to, what);
to-global.size = new_size;
to-global.time = cgraph_estimate_time_after_inlining (freq, to, what);
}
gcc_assert (what-global.inlined_to == to);
if (new_size old_size)
overall_size += new_size - old_size;
so we adjust inlined callers size but do not accumulate those changes to
overall_size. And in ...
static bool
cgraph_check_inline_limits (struct cgraph_node *to, struct cgraph_node *what,
cgraph_inline_failed_t *reason, bool one_only)
{
...
if (to-global.inlined_to)
to = to-global.inlined_to;
we seem to adjust for this effect by taking to-global.inlined_to, but that's
obviously not the same.
Also when deciding function called once inlining we should use
cgraph_check_inline_limits (..., true) and cgraph_mark_inline_edge.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43058
[Bug fortran/43062] NAMELIST attribute conflicts with ALLOCATABLE attribute
--- Comment #5 from kargl at gcc dot gnu dot org 2010-02-15 17:04 --- (In reply to comment #4) (In reply to comment #3) I've posted a question to c.l.f about this code. I believe the language of the standard is contradictory and as such the code can be interpreted as illegal or legal. http://groups.google.com/group/comp.lang.fortran/browse_frm/thread/76b23c9927b52161# Into the final committee draft J3/03-007R2, section 5.4, I found : C574 (R553) A namelist-group-object shall not be an assumed-size array. It was not the case in F95. Your code doesn't contain an assumed-sized array. -- steve -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43062
[Bug debug/42918] [4.5 Regression] -fcompare-debug failure with -O2 -ftracer (2)
--- Comment #3 from jakub at gcc dot gnu dot org 2010-02-15 17:06 ---
The problem here is missing INSN location on insn generated by insert_restore
with -g (without -g it has one).
Before IRA we have:
(note 26 25 27 5 [bb 5] NOTE_INSN_BASIC_BLOCK)
(call_insn 27 26 28 5 pr42918.c:14 (call (mem:QI (symbol_ref:DI (fv) [flags
0x41] function_decl 0x7feab75d6b00 fv) [0 S1 A8])
(const_int 0 [0x0])) 638 {*call_0} (nil)
(nil))
(note 28 27 30 5 (lab) NOTE_INSN_DELETED_LABEL 3)
(debug_insn 30 28 34 5 (var_location:SI i (reg/v:SI 59 [ i ])) -1 (nil))
at the end of a basic block (obviously with -g0 the debug_insn is missing).
Now save_call_clobbered_regs restores all still saved regs at the end of a
basic block, when the bb doesn't end with a jump, it restores after the last
insn mentioned in reload_insn_chain for that bb, when it is a jump, then before
it.
As DEBUG_INSNs are included in reload_insn_chain, that is for -g after the
DEBUG_INSN (and as insert_restore inserts after that insn, the insn has no
location as DEBUG_INSN has no location either). For -g0 that is after the call
insn, which has location and thus the restore insn gets the location of the
call.
Although emit_insn_after ignores DEBUG_INSNs, it doesn't ignore notes and there
is this deleted label note in between.
Changing save_call_clobbered_regs to restore all regs after the last non-debug
insn in a bb wouldn't work well, as the restore insn invalidates the hard regs
that could still hold something in the debug insn.
I guess we could remember the INSN_LOCATOR of the last non-debug insn in the
reload chain and use emit_insn_after_setloc in insert_restore (going to test it
now), but wonder whether the fact that the deleted label is now after the hard
reg restore insn in the -g0 case and before it in the -g case couldn't
introduce other -fcompare-debug differences on other testcases.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42918
[Bug fortran/43078] gfortran: spurious warning of line truncation at col 72
--- Comment #1 from kargl at gcc dot gnu dot org 2010-02-15 17:10 --- Works for me with both 4.4.2 and trunk. Can you attach a small self-contained example that fails? The single line of code you posted may have been mangled during the submission. PS: Does the line of code you submitted contain tab characters? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43078
[Bug libstdc++/23271] Members of ctype_base appear not to be integral constant expressions.
--- Comment #7 from davek at gcc dot gnu dot org 2010-02-15 17:30 --- (In reply to comment #3) Confirmed, this is either a cygwin/newlib bug or a libstdc++ bug: reduced testcase for the error: Reduced reduced testcase: static const char print = 0x97; -- davek at gcc dot gnu dot org changed: What|Removed |Added CC||davek at gcc dot gnu dot org Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23271
[Bug libstdc++/23271] Members of ctype_base appear not to be integral constant expressions.
--- Comment #8 from davek at gcc dot gnu dot org 2010-02-15 17:31 --- Oops, that was slightly premature. I meant to add that the error (from the original testcase) doesn't happen with the 4.3.4 system compiler nor with 4.5.0 head, and that I'm afraid there aren't going to be any bugs fixed in 3.4.4, the entire 3 series is long dead. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23271
[Bug libstdc++/23271] Members of ctype_base appear not to be integral constant expressions.
--- Comment #9 from davek at gcc dot gnu dot org 2010-02-15 17:32 --- (In reply to comment #5) Is the print member really already overflowed? It has a value of 0200 which is 0x80: so if char is signed (it is on cygwin) then it's setting the sign bit, which should be OK I think. No, it isn't. A signed char can contain values between 0x7f and -0x80. Assigning a value of +0x80 to it results in overflow. You could assign (char)0x80 to it and it would be ok, but 0x80 by itself isn't a constant that will fit in a signed char, so it does need the cast (or to be expressed as the negative equivalent.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23271
[Bug libstdc++/23271] Members of ctype_base appear not to be integral constant expressions.
--- Comment #10 from davek at gcc dot gnu dot org 2010-02-15 17:35 --- (still here - only de-cc'd one of my two addresses) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23271
[Bug objc/43061] 47 new GCC h...@156527 regressions
--- Comment #24 from mikestump at comcast dot net 2010-02-15 17:38 --- Yes, I think IainS is on the right track, all things in objc_cls_refs escape and can be read and written to in unexpected ways by the runtime. Setting TREE_ADDRESSABLE sounds like a reasonable step forward. -- mikestump at comcast dot net changed: What|Removed |Added CC||mikestump at comcast dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43061
[Bug libstdc++/23271] Members of ctype_base appear not to be integral constant expressions.
--- Comment #11 from paolo dot carlini at oracle dot com 2010-02-15 17:44 --- Ah, thanks Dave! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23271
[Bug tree-optimization/43083] New: [4.5 Regression] ICE: SIGSEGV with -fgraphite-identity
Command line: gcc -O1 -fgraphite-identity testcase.c (fails at all -O1, -O2, -O3 levels) Tested revisions: r156745 - crash r153685 - crash 4.4 r156256 - OK Output: $ /mnt/svn/gcc-trunk/binary-156745-lto/bin/gcc -O3 -fgraphite-identity testcase.c testcase.c: In function 'foo': testcase.c:9:5: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Valgrind: ==14930== Invalid write of size 8 ==14930==at 0x563054: link_block (cfg.c:153) ==14930==by 0x7CD121: create_bb (tree-cfg.c:444) ==14930==by 0x572672: create_basic_block (cfghooks.c:621) ==14930==by 0x7CDF84: gimple_split_block (tree-cfg.c:4812) ==14930==by 0x5720BE: split_block (cfghooks.c:433) ==14930==by 0x572970: make_forwarder_block (cfghooks.c:737) ==14930==by 0xBFB572: create_sese_edges (graphite-scop-detection.c:965) ==14930==by 0xBFD4BA: build_scops (graphite-scop-detection.c:1327) ==14930==by 0xBF036F: graphite_transform_loops (graphite.c:260) ==14930==by 0x8968C6: graphite_transforms (tree-ssa-loop.c:300) ==14930==by 0x7233EA: execute_one_pass (passes.c:1561) ==14930==by 0x723674: execute_pass_list (passes.c:1616) ==14930== Address 0x30 is not stack'd, malloc'd or (recently) free'd -- Summary: [4.5 Regression] ICE: SIGSEGV with -fgraphite-identity Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zsojka at seznam dot cz GCC host triplet: x86_64-pc-linux-gnu GCC target triplet: x86_64-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43083
[Bug tree-optimization/43083] [4.5 Regression] ICE: SIGSEGV with -fgraphite-identity
--- Comment #1 from zsojka at seznam dot cz 2010-02-15 18:45 --- Created an attachment (id=19880) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19880action=view) reduced testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43083
[Bug tree-optimization/43084] New: [4.5 Regression] ICE: in find_new_var_of_type, at ipa-struct-reorg.c:604 with -fipa-struct-reorg -g
Command line: gcc -O1 -fipa-struct-reorg -fwhole-program -fipa-type-escape -g testcase.c Tested revisions: r156745 - crash r153685 - crash 4.4 r156256 - OK (with checking) Output: $ /mnt/svn/gcc-trunk/binary-156745-lto/bin/gcc -O1 -fipa-struct-reorg -fwhole-program -fipa-type-escape -g testcase.c testcase.c: In function #8216;main#8217;: testcase.c:10:1: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:604 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Valgrind: no errors reported -- Summary: [4.5 Regression] ICE: in find_new_var_of_type, at ipa- struct-reorg.c:604 with -fipa-struct-reorg -g Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zsojka at seznam dot cz GCC host triplet: x86_64-pc-linux-gnu GCC target triplet: x86_64-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43084
[Bug tree-optimization/43084] [4.5 Regression] ICE: in find_new_var_of_type, at ipa-struct-reorg.c:604 with -fipa-struct-reorg -g
--- Comment #1 from zsojka at seznam dot cz 2010-02-15 18:50 --- Created an attachment (id=19881) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19881action=view) reduced testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43084
[Bug fortran/43078] gfortran: spurious warning of line truncation at col 72
--- Comment #2 from patrick dot wallace at stfc dot ac dot uk 2010-02-15 19:10 --- Subject: RE: gfortran: spurious warning of line truncation at col 72 Hi, Thanks for your rapid response. Works for me with both 4.4.2 and trunk. The fault was reported by a collaborator in Australia who is a leading software developer - but I'm beginning to wonder if he has the latest gfortran. He reported the version as gfortran 4.x. (This was a series of tests involving four compilers on at least four hosts.) Having seen the fault myself (though as long ago as May last year), and having searched the gcc-bugzilla archive, I just assumed the problem would still be there. But 5 minutes ago, on a just-built Ubuntu system, and using last year's example, I got no warning. I've asked the original reporter to do some more delving. Please stand by - and apologies in advance if this is just an old version problem. PS: Does the line of code you submitted contain tab characters? Definitely not. Totally vanilla Fortran characters. It's always possible some helpful piece of software en route has messed with what I thought I sent. Patrick Wallace Space Science Technology Department+44-1235-445372 tel STFC / Rutherford Appleton Laboratory+44-1235-446362 fax Harwell Science and Innovation Campus p...@star.rl.ac.uk Didcot, Oxfordshire, OX11 0QX, UK patrick.wall...@stfc.ac.uk -- Scanned by iCritical. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43078
[Bug other/43085] New: Make profiledbootstrap fails with cc1plus catching SIGSEGV
I configured GCC rev. 156770 with the following options: ../gcc/configure --prefix=/home/artem/testing/gcc45 --enable-shared --enable-bootstrap --enable-languages=c,c++ --enable-threads=posix --enable-checking=release --with-system-zlib --disable-libunwind-exceptions --enable-__cxa_atexit --enable-libssp --with-gnu-ld --with-lto --disable-nls --verbose --with-arch=i686 --target=i686-slackware-linux --build=i686-slackware-linux --host=i686-slackware-linux With this configuration 'make' completes successfully, but 'make profiledbootstrap' fails. The last command which gets executed is /home/artem/testing/gcc-build/./gcc/xgcc -shared-libgcc -B/home/artem/testing/gcc-build/./gcc -nostdinc++ -L/home/artem/testing/gcc-build/i686-slackware-linux/libstdc++-v3/src -L/home/artem/testing/gcc-build/i686-slackware-linux/libstdc++-v3/src/.libs -B/home/artem/testing/gcc45/i686-slackware-linux/bin/ -B/home/artem/testing/gcc45/i686-slackware-linux/lib/ -isystem /home/artem/testing/gcc45/i686-slackware-linux/include -isystem /home/artem/testing/gcc45/i686-slackware-linux/sys-include -I/home/artem/testing/gcc-build/i686-slackware-linux/libstdc++-v3/include/i686-slackware-linux -I/home/artem/testing/gcc-build/i686-slackware-linux/libstdc++-v3/include -I/home/artem/testing/gcc/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -c ../../../../gcc/libstdc++-v3/src/pool_allocator.cc -fPIC -DPIC -o .libs/pool_allocator.o While compiling pool_allocator.o, cc1plus catches SIGSEGV: In file included from ../../../../gcc/libstdc++-v3/src/pool_allocator.cc:31:0: /home/artem/testing/gcc-build/i686-slackware-linux/libstdc++-v3/include/ext/pool_allocator.h: In constructor '__gnu_cxx::__pool_alloc_Tp::__pool_alloc() [with _Tp = char]': ../../../../gcc/libstdc++-v3/src/pool_allocator.cc:171:18: instantiated from here /home/artem/testing/gcc-build/i686-slackware-linux/libstdc++-v3/include/ext/pool_allocator.h:140:30: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Here is the backtrace: #0 0xb6ff08c7 in raise () from /lib/libc.so.6 #1 0xb6ff2132 in abort () from /lib/libc.so.6 #2 0x08269204 in real_abort () at ../../gcc/gcc/diagnostic.c:738 #3 diagnostic_action_after_output () at ../../gcc/gcc/diagnostic.c:201 #4 0x08269b09 in diagnostic_report_diagnostic (context=0x89ee8e0, diagnostic=0xbfcbfa94) at ../../gcc/gcc/diagnostic.c:423 #5 0x0826986a in internal_error (gmsgid=0x885c7ad %s) at ../../gcc/gcc/diagnostic.c:674 #6 0x083fefe0 in crash_signal (signo=11) at ../../gcc/gcc/toplev.c:629 #7 signal handler called #8 0x080c8ea4 in build_new_method_call (instance=0xb6aaf508, fns=0x0, args=0xbfcc019c, conversion_path=0xb6c886c8, flags=3, complain=3, fn_p=0x0) at ../../gcc/gcc/cp/call.c:6209 #9 0x080ca084 in build_special_member_call (instance=0xb6aaf508, name=0xb6cf90d0, args=0xbfcc019c, binfo=value optimized out, flags=3, complain=3) at ../../gcc/gcc/cp/call.c:6115 #10 0x0817aa69 in expand_default_init (binfo=value optimized out, true_exp=value optimized out, exp=value optimized out, init=value optimized out, flags=3, complain=3) at ../../gcc/gcc/cp/init.c:1355 #11 expand_aggr_init_1 (binfo=value optimized out, true_exp=value optimized out, exp=value optimized out, init=value optimized out, flags=3, complain=3) at ../../gcc/gcc/cp/init.c:1441 #12 0x0817e8f7 in emit_mem_initializers (mem_inits=0xb6abade0) at ../../gcc/gcc/cp/init.c:836 #13 0x080fd327 in tsubst_expr (t=value optimized out, args=value optimized out, complain=value optimized out, in_decl=0xb6a9b1a0, integral_constant_expression_p=0 '\000') at ../../gcc/gcc/cp/pt.c:11392 #14 0x080fc6b7 in tsubst_expr (t=value optimized out, args=0xb6ab1768, complain=3, in_decl=0xb6a9b1a0, integral_constant_expression_p=0 '\000') at ../../gcc/gcc/cp/pt.c:11387 #15 0x080fd225 in tsubst_expr (t=0xb6c900fc, args=0xb6ab1768, complain=3, in_decl=0xb6a9b1a0, integral_constant_expression_p=0 '\000') at ../../gcc/gcc/cp/pt.c:11543 #16 0x0810b73d in instantiate_decl (d=value optimized out, defer_ok=value optimized out, expl_inst_class_mem_p=0 '\000') at ../../gcc/gcc/cp/pt.c:16710 #17 0x08116630 in instantiate_pending_templates (retries=0) at ../../gcc/gcc/cp/pt.c:16807 #18 0x08130ca8 in cp_write_global_declarations () at ../../gcc/gcc/cp/decl2.c:3538 #19 0x083fe4d0 in compile_file (argc=41, argv=0xbfcc0674) at ../../gcc/gcc/toplev.c:1065 #20 do_compile (argc=41, argv=0xbfcc0674) at ../../gcc/gcc/toplev.c:2405 #21 toplev_main (argc=41, argv=0xbfcc0674) at ../../gcc/gcc/toplev.c:2447 #22 0x081fee3b in main (argc=41, argv=0xbfcc0674) at ../../gcc/gcc/main.c:35 -- Summary: Make profiledbootstrap fails with cc1plus catching SIGSEGV Product: gcc Version: 4.5.0
[Bug objc/43061] 47 new GCC h...@156527 regressions
--- Comment #25 from developer at sandoe-acoustics dot co dot uk 2010-02-15 19:54 --- Hm. I tried this trivial patch: Index: gcc/objc/objc-act.c === --- gcc/objc/objc-act.c (revision 156760) +++ gcc/objc/objc-act.c (working copy) @@ -2533,7 +2533,8 @@ sprintf (buf, _OBJC_SELECTOR_REFERENCES_%d, selector_reference_idx++); decl = start_var_decl (objc_selector_type, buf); - + if (flag_next_runtime) +TREE_ADDRESSABLE (decl) = 1; return decl; } @@ -2733,6 +2734,8 @@ sprintf (buf, _OBJC_CLASS_REFERENCES_%d, class_reference_idx++); decl = start_var_decl (objc_class_type, buf); + if (flag_next_runtime) +TREE_ADDRESSABLE (decl) = 1; return decl; } and when I check in gdb the trees are marked as addressable [checking in objc-act.c/finish_var_decl() ]. ... but something is un-doing this later - and _OBJC_CLASS_REFERENCES_0 is ending up marked as not tree addressable according to the ipa dump. any ideas where I'm going wrong? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43061
[Bug fortran/43062] NAMELIST attribute conflicts with ALLOCATABLE attribute
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2010-02-15 20:33 --- What is this? REAL, DIMENSION(:), ALLOCATABLE :: TAB If not assumed size? Also, assuming it is something else, would it be invalid to use the namelist anywhere if TAB has not been allocated before it is used? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43062
[Bug middle-end/17308] nonnull attribute not as useful as it could
--- Comment #5 from msebor at gmail dot com 2010-02-15 20:51 ---
I second Ulrich's request.
Besides nonnull, this enhancement would be useful in attribute printf
as well. For example, in the program below, both calls to printf() have
undefined behavior in C99 and should be diagnosed:
$ cat t.c gcc -Wformat -pedantic -std=c99 -O3 t.c
int printf(const char*, ...)
__attribute__((__nonnull__((1
__attribute__ ((__format__ (__printf__, 1, 2)));
int main() {
char *s = 0;
printf(s, );
printf(%s, s);
}
$
--
msebor at gmail dot com changed:
What|Removed |Added
CC||msebor at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17308
[Bug debug/42918] [4.5 Regression] -fcompare-debug failure with -O2 -ftracer (2)
--- Comment #4 from jakub at gcc dot gnu dot org 2010-02-15 20:55 --- Created an attachment (id=19882) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19882action=view) gcc45-pr42918.patch Patch I've bootstrapped/regtested on x86_64-linux and i686-linux. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42918
[Bug objc/43061] 47 new GCC h...@156527 regressions
--- Comment #26 from jakub at gcc dot gnu dot org 2010-02-15 21:09 --- Addressability is recomputed several times. What you probably want is mark the decl with the used attribute (i.e. add used attribute to it, set TREE_USED (decl) = 1 and DECL_PRESERVE_P (decl) = 1). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43061
[Bug bootstrap/42666] xgcc: Internal error: segmentation violation (program cc1)
--- Comment #3 from norbert dot huebsch at gmx dot de 2010-02-15 21:30 --- (In reply to comment #2) Have you tried building in a different directory than the source directory? Do you have any environment variables set like CFLAGS, etc? No, I compieled directly in the source directory. I didn´t try any CFLAGS either. I have absolutely no idea from what the error comes. But I know QNX isn´t a very common operating System, perhaps it never works on this platform. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42666
[Bug fortran/43062] NAMELIST attribute conflicts with ALLOCATABLE attribute
--- Comment #7 from kargl at gcc dot gnu dot org 2010-02-15 21:47 --- (In reply to comment #6) What is this? REAL, DIMENSION(:), ALLOCATABLE :: TAB If not assumed size? Also, assuming it is something else, would it be invalid to use the namelist anywhere if TAB has not been allocated before it is used? It's a deferred-shape array. 5.1.2.5.3 Deferred-shape array A deferred-shape array is an allocatable array or an array pointer. 5.1.2.5.4 Assumed-size array An assumed-size array is a dummy argument array whose size is assumed from that of an associated actual argument. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43062
[Bug fortran/43062] NAMELIST attribute conflicts with ALLOCATABLE attribute
--- Comment #8 from kargl at gcc dot gnu dot org 2010-02-15 21:50 --- (In reply to comment #6) Also, assuming it is something else, would it be invalid to use the namelist anywhere if TAB has not been allocated before it is used? I forgot to reply to this part. See comment #2 where I quote 9.5.3.6 form F2003. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43062
[Bug objc/43061] 47 new GCC h...@156527 regressions
--- Comment #27 from developer at sandoe-acoustics dot co dot uk 2010-02-15 21:51 --- (In reply to comment #26) Addressability is recomputed several times. What you probably want is mark the decl with the used attribute (i.e. add used attribute to it, set TREE_USED (decl) = 1 and DECL_PRESERVE_P (decl) = 1). finish_var_decl() contains: mark_decl_referenced(var); - although this doesn't do anything for csts. and TREE_USED (var) = 1; adding DECL_PRESERVE_P (decl) = 1 doesn't solve the problem either.. I'll have to dig deeper into what's actually happening/required. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43061
[Bug java/43086] New: PR16923 fails with Assertion failed: (class_id)
On x86_64-apple-darwin9/10, the PR16923 libjava testcase, when linked to the proper libiconv, fails with... Assertion failed: (class_id), function main, file /sw/src/fink.build/gcc44-4.4.2-1000/gcc-4.4.2/libjava/testsuite/libjava.jni/invocation/PR16923.c, line 35. Abort A build of gcc-4.4.2 with the libgcc built with -O0 shows a backtrace of this failure as... #0 _Jv_AllocPtrFreeObj [inlined] () at java-gc.h:55 #1 _Jv_AllocString (len=Cannot access memory at address 0xf ) at ../../../gcc-4.4.2/libjava/prims.cc:627 Cannot access memory at address 0xf -- Summary: PR16923 fails with Assertion failed: (class_id) Product: gcc Version: 4.4.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: howarth at nitro dot med dot uc dot edu GCC build triplet: x86_64-apple-darwin* GCC host triplet: x86_64-apple-darwin* GCC target triplet: x86_64-apple-darwin* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43086
[Bug java/43086] PR16923 fails with Assertion failed: (class_id)
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2010-02-15 22:12 --- Created an attachment (id=19883) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19883action=view) gdb walk for PR16923 failure -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43086
[Bug libgcj/40860] [4.4/4.5 regression] regressions in libjava testsuite on arm-linux
--- Comment #8 from mikpe at it dot uu dot se 2010-02-15 22:26 --- I've identified http://sourceware.org/ml/binutils-cvs/2009-05/msg00021.html as the source of this regression. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40860
[Bug objc/43061] 47 new GCC h...@156527 regressions
--- Comment #28 from jakub at gcc dot gnu dot org 2010-02-15 22:37 --- DECL_ATTRIBUTES (decl) = tree_cons (get_identifier (used), NULL, DECL_ATTRIBUTES (decl)); is also needed (no idea why ipa*.c/cgraphunit.c use lookup_attribute instead of testing DECL_PRESERVED_P, but they do). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43061
[Bug c++/43031] [4.5 Regression] internal compiler error: verify_gimple failed after non-trivial conversion error when crosscompiling Firefox
--- Comment #4 from jason at gcc dot gnu dot org 2010-02-15 22:43 --- Right, the stdcall attribute prevents us from using TYPE_CANONICAL, so it's not clear to useless_type_conversion that the type of T::A is the same as P::F. Specifically, they are distinct because P::F uses a typedef for L, whereas T::A does not. I guess we need to insert an explicit conversion, provide TYPE_CANONICAL even in the presence of strong attributes, or both. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43031
[Bug objc/43061] 47 new GCC h...@156527 regressions
--- Comment #29 from developer at sandoe-acoustics dot co dot uk 2010-02-15 23:10 --- Created an attachment (id=19884) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19884action=view) attach used attribute as well as marking vars used. Jakub's comment seems to do the trick - thanks. I've applied a used attribute in the same place that the TREE_USED is placed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43061
[Bug tree-optimization/43084] [4.5 Regression] ICE: in find_new_var_of_type, at ipa-struct-reorg.c:604 with -fipa-struct-reorg -g
--- Comment #2 from steven at gcc dot gnu dot org 2010-02-15 23:25 --- The ipa-struct-reorg pass is broken and should be disabled for gcc 4.5 and later, until someone gives it the TLC that it needs so badly. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-02-15 23:25:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43084
[Bug target/42854] [4.4/4.5 Regression] FAIL: gcc.dg/darwin-weakimport-[13].c scan-assembler-not *
--- Comment #13 from jakub at gcc dot gnu dot org 2010-02-15 23:53 --- Subject: Bug 42854 Author: jakub Date: Mon Feb 15 23:52:53 2010 New Revision: 156786 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156786 Log: PR target/42854 * config/darwin.h (ASM_WEAKEN_DECL): Don't check weak attribute if weak_import attribute is present. * config/darwin.c (machopic_select_section): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/darwin.c trunk/gcc/config/darwin.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42854
[Bug lto/43071] ICE: SIGSEGV with -fwhopr -fcompare-debug
--- Comment #4 from zsojka at seznam dot cz 2010-02-16 00:17 --- How comes it crashes with -fcompare-debug, but not with -g? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43071
[Bug c++/43087] New: ICE
j...@shade:~/software/itk/InsightToolkit-3.16.0/Testing/Code/BasicFilters$ /usr/local/gcc-svn/bin/c++ -v -save-temps -ftemplate-depth-50 -Wall -Wextra -Wno-deprecated -msse2 -g -c itkBasicFiltersPrintTest.i Using built-in specs. COLLECT_GCC=/usr/local/gcc-svn/bin/c++ COLLECT_LTO_WRAPPER=/usr/local/gcc-svn/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/usr/local/gcc-svn --with-gmp=/usr/local/gmp --with-mpfr=/usr/local/mpfr --with-mpc=/usr/local/mpc --disable-multilib --enable-languages=c,c++ Thread model: posix gcc version 4.5.0 20100214 (experimental) (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-ftemplate-depth-50' '-Wall' '-Wextra' '-Wno-deprecated' '-msse2' '-g' '-c' '-shared-libgcc' '-mtune=generic' /usr/local/gcc-svn/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/cc1plus -fpreprocessed itkBasicFiltersPrintTest.i -quiet -dumpbase itkBasicFiltersPrintTest.i -msse2 -mtune=generic -auxbase itkBasicFiltersPrintTest -g -Wall -Wextra -Wno-deprecated -version -ftemplate-depth-50 -o itkBasicFiltersPrintTest.s GNU C++ (GCC) version 4.5.0 20100214 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.5.0 20100214 (experimental), GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU C++ (GCC) version 4.5.0 20100214 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.5.0 20100214 (experimental), GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: f29f0d47dc304f45577b6b757a338046 /home/jd/software/itk/InsightToolkit-3.16.0/Testing/Code/BasicFilters/itkBasicFiltersPrintTest.cxx: In function int itkBasicFiltersPrintTest(int, char**): /home/jd/software/itk/InsightToolkit-3.16.0/Testing/Code/BasicFilters/itkBasicFiltersPrintTest.cxx:375:54: internal compiler error: tree check: accessed elt 3 of tree_vec with 2 elts in tsubst, at cp/pt.c:9923 Please submit a full bug report, -- Summary: ICE Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jeffrey dot donner at gmail dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43087
[Bug c++/43087] ICE
--- Comment #1 from jeffrey dot donner at gmail dot com 2010-02-16 02:51 --- Created an attachment (id=19885) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19885action=view) bz2 of pre-processed offending code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43087
[Bug c++/43087] ICE
--- Comment #2 from hjl dot tools at gmail dot com 2010-02-16 05:04 --- It is caused by revision 155363: http://gcc.gnu.org/ml/gcc-cvs/2009-12/msg00507.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||dseketel at redhat dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-02-16 05:04:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43087
[Bug c++/43087] [4.5 Regression] ICE
-- hjl dot tools at gmail dot com changed: What|Removed |Added Summary|ICE |[4.5 Regression] ICE Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43087
[Bug c/43088] New: [avr] Suspect optimizer missed code in gcc 4.4.3..
I just built a recent toolchain (avr-gcc 4.4.3, binutils
2.20) in hopes of eliminating what appeared to be
a few artifacts apparently escaping optimization even
with -Os relative to a 4.0.2 version. Referencing the dump
below, use of r25 is superfluous as it is cleared at 0x14c,
ANDed with zero at 0x150, and then participates in an
additionally unneeded word wide test operation at 0x152:
0142 foo:
void foo(void)
{
static unsigned char count;
if (++count 0x3f)
142: 80 91 01 01 lds r24, 0x0101
146: 8f 5f subir24, 0xFF ; 255
148: 80 93 01 01 sts 0x0101, r24
14c: 90 e0 ldi r25, 0x00 ; 0
14e: 8f 73 andir24, 0x3F ; 63
150: 90 70 andir25, 0x00 ; 0
150: 90 70 andir25, 0x00 ; 0
152: 00 97 sbiwr24, 0x00 ; 0
154: 11 f0 breq.+4 ; 0x15a foo+0x18
PORTC = ~0x1;
156: 40 98 cbi 0x08, 0 ; 8
158: 08 95 ret
else
PORTC |= 0x1;
15a: 40 9a sbi 0x08, 0 ; 8
15c: 08 95 ret
}
This is slightly different (although appearing to derive
from the same code generation logic) than I'd seen with a
4.0.2 toolchain where the first two operations above are
followed by an OR of r25 into r24 as a word width test:
013c foo:
void foo(void)
{
static unsigned char count;
if (++count 0x3f)
13c: 80 91 00 01 lds r24, 0x0100
140: 8f 5f subir24, 0xFF ; 255
142: 80 93 00 01 sts 0x0100, r24
146: 99 27 eor r25, r25
148: 8f 73 andir24, 0x3F ; 63
14a: 90 70 andir25, 0x00 ; 0
14c: 89 2b or r24, r25
14e: 11 f0 breq.+4 ; 0x154 foo+0x18
PORTC = ~0x1;
150: 40 98 cbi 0x08, 0 ; 8
152: 08 95 ret
else
PORTC |= 0x1;
154: 40 9a sbi 0x08, 0 ; 8
156: 08 95 ret
}
Both examples above were compiled with:
-mmcu=atmega48 -nostdlib -Os -funsigned-char
FWIW -O2 and -O3 give the same results. It seems to be
an artifact of a scalar widening operation during code
generation although can be quietly eliminated post-code
generation given the char width type.
I've seen some similar bug reports but not specifically
related to a bitwise-and operation where more than one
set bit exists in the constant operand. Note if the
constant '3' is replaced with an 'unsigned char'
variable of the same value, the expected minimal
code sequence results (sans the fetch of the added
variable from memory).
---
Per requested bug report boilerplate:
/home/john/avr/gnu/toolbin//bin/avr-gcc -v -save-temps -c -o rt1.o -c
-mmcu=atmega48 -nostdlib -Os -funsigned-char -D__BUILD_GAS__
-DDATE=\100215200656\ -g rt1.c
Using built-in specs.
Target: avr
Configured with: ../configure --prefix=/home/john/avr/gnu/toolbin --target=avr
--enable-languages=c,c++ --disable-nls --disable-libssp --with-dwarf2
Thread model: single
gcc version 4.4.3 (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-o' 'rt1.o' '-c' '-mmcu=atmega48'
'-nostdlib' '-Os' '-funsigned-char' '-D__BUILD_GAS__' '-DDATE=100215200656'
'-g'
/home/john/avr/gnu/toolbin/libexec/gcc/avr/4.4.3/cc1 -E -quiet -v -imultilib
avr4 -D__BUILD_GAS__ -DDATE=100215200656 rt1.c -mmcu=atmega48 -funsigned-char
-g -fworking-directory -Os -fpch-preprocess -o rt1.i
ignoring nonexistent directory
/home/john/avr/gnu/toolbin/lib/gcc/avr/4.4.3/../../../../avr/sys-include
#include ... search starts here:
#include ... search starts here:
/home/john/avr/gnu/toolbin/lib/gcc/avr/4.4.3/include
/home/john/avr/gnu/toolbin/lib/gcc/avr/4.4.3/include-fixed
/home/john/avr/gnu/toolbin/lib/gcc/avr/4.4.3/../../../../avr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-o' 'rt1.o' '-c' '-mmcu=atmega48'
'-nostdlib' '-Os' '-funsigned-char' '-D__BUILD_GAS__' '-DDATE=100215200656'
'-g'
/home/john/avr/gnu/toolbin/libexec/gcc/avr/4.4.3/cc1 -fpreprocessed rt1.i
-quiet -dumpbase rt1.c -mmcu=atmega48 -auxbase-strip rt1.o -g -Os -version
-funsigned-char -o rt1.s
GNU C (GCC) version 4.4.3 (avr)
compiled by GNU C version 4.4.2 20091222 (Red Hat 4.4.2-20), GMP
version 4.3.1, MPFR version 2.4.1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 2cb821fe223eaff7cfe636a2c880b1cc
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-o' 'rt1.o' '-c' '-mmcu=atmega48'
'-nostdlib' '-Os' '-funsigned-char' '-D__BUILD_GAS__' '-DDATE=100215200656'
'-g'
/home/john/avr/gnu/toolbin/lib/gcc/avr/4.4.3/../../../../avr/bin/as
-mmcu=atmega48 -o rt1.o rt1.s
[Bug c++/43031] [4.5 Regression] internal compiler error: verify_gimple failed after non-trivial conversion error when crosscompiling Firefox
--- Comment #5 from jason at gcc dot gnu dot org 2010-02-16 06:05 --- Fixed. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43031
[Bug c++/43036] [4.3/4.4/4.5 Regression] c++ compilation hang
--- Comment #17 from jason at gcc dot gnu dot org 2010-02-16 06:05 --- Subject: Bug 43036 Author: jason Date: Tue Feb 16 06:05:09 2010 New Revision: 156792 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156792 Log: PR c++/43036 * tree.c (build_cplus_array_type): Set TYPE_MAIN_VARIANT to strip cv-quals from element here. (cp_build_qualified_type_real): Not here. Preserve typedef name. Added: trunk/gcc/testsuite/g++.dg/other/array6.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/tree.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43036
[Bug c++/43031] [4.5 Regression] internal compiler error: verify_gimple failed after non-trivial conversion error when crosscompiling Firefox
--- Comment #6 from jason at gcc dot gnu dot org 2010-02-16 06:05 --- Subject: Bug 43031 Author: jason Date: Tue Feb 16 06:05:20 2010 New Revision: 156793 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156793 Log: PR c++/43031 * cp-gimplify.c (cp_gimplify_expr) [MODIFY_EXPR]: Use VIEW_CONVERT_EXPR for conversions between structural equality types that the back end can't tell are the same. Added: trunk/gcc/testsuite/g++.dg/ext/attrib36.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-gimplify.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43031
[Bug c++/43036] [4.3/4.4/4.5 Regression] c++ compilation hang
--- Comment #18 from jason at gcc dot gnu dot org 2010-02-16 06:08 --- Fixed for 4.5.0. I'll attach the patch in case you want to apply it to your 4.4 compiler. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|4.3.5 |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43036
[Bug c++/43036] [4.3/4.4/4.5 Regression] c++ compilation hang
--- Comment #19 from jason at gcc dot gnu dot org 2010-02-16 06:09 --- Created an attachment (id=19886) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19886action=view) patch for 4.4 branch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43036
[Bug fortran/41869] ICE segfault when reading module file
--- Comment #8 from burnus at gcc dot gnu dot org 2010-02-16 07:39 --- (In reply to comment #7) Do we backport to 4.4 or just close it? I would go for the backporting. Ditto. (Don't forget gfc_symbol *sym; as I did in my posted patch as I failed to split three patches correctly.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41869
please help me
hi everybody, I want to analyse the gcc source code. i have code but i am not getting it. So please help me by providing any documentation for the code or with any suggetions -- View this message in context: http://old.nabble.com/please-help-me-tp27604613p27604613.html Sent from the gcc - bugs mailing list archive at Nabble.com.
[Bug target/42894] [4.5 Regression] Invalid rtl sharing in Thumb1.
--- Comment #8 from abel at gcc dot gnu dot org 2010-02-16 07:51 ---
I needed explicit --enable-tls to reproduce this. The problem seems to be in
dump_minipool. We are gathering values to fix in the Mnode structures and then
we are issuing insns with those values. However, when a value is a constant,
we get two insns with the same CONST: parts of the pattern, which is not
permitted and is caught by the verifier.
To fix this, it is enough to unshare the values before emitting. The below
patch does this only for CONSTANT_P rtxes and fixes the bug. Is it fine or do
we want to unconditionally unshare the rtx to be absolutely sure this will not
happen again? I do not know ARM backend good enough to judge.
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 466981a..2edae15 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -10917,6 +10917,8 @@ dump_minipool (rtx scan)
{
if (mp-refcount 0)
{
+ rtx value;
+
if (dump_file)
{
fprintf (dump_file,
@@ -10927,35 +10929,36 @@ dump_minipool (rtx scan)
fputc ('\n', dump_file);
}
+ value = CONSTANT_P (mp-value) ? copy_rtx (mp-value) : mp-value;
switch (mp-fix_size)
{
#ifdef HAVE_consttable_1
case 1:
- scan = emit_insn_after (gen_consttable_1 (mp-value), scan);
+ scan = emit_insn_after (gen_consttable_1 (value), scan);
break;
#endif
#ifdef HAVE_consttable_2
case 2:
- scan = emit_insn_after (gen_consttable_2 (mp-value), scan);
+ scan = emit_insn_after (gen_consttable_2 (value), scan);
break;
#endif
#ifdef HAVE_consttable_4
case 4:
- scan = emit_insn_after (gen_consttable_4 (mp-value), scan);
+ scan = emit_insn_after (gen_consttable_4 (value), scan);
break;
#endif
#ifdef HAVE_consttable_8
case 8:
- scan = emit_insn_after (gen_consttable_8 (mp-value), scan);
+ scan = emit_insn_after (gen_consttable_8 (value), scan);
break;
#endif
#ifdef HAVE_consttable_16
case 16:
- scan = emit_insn_after (gen_consttable_16 (mp-value), scan);
+ scan = emit_insn_after (gen_consttable_16 (value), scan);
break;
#endif
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42894
