[Bug c++/50303] [C++0x] Segfault with variadic template template parameters
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50303 Markus Trippelsdorf markus at trippelsdorf dot de changed: What|Removed |Added CC||markus at trippelsdorf dot ||de --- Comment #5 from Markus Trippelsdorf markus at trippelsdorf dot de 2011-09-15 07:06:19 UTC --- Program received signal SIGSEGV, Segmentation fault. [Switching to process 30771] tsubst_template_parms (parms=0x0, args=0x777a6d98, complain=3) at ../../gcc/gcc/cp/pt.c:9507 9507 TMPL_PARMS_DEPTH (parms) TMPL_ARGS_DEPTH (args); (gdb) bt #0 tsubst_template_parms (parms=0x0, args=0x777a6d98, complain=3) at ../../gcc/gcc/cp/pt.c:9507 #1 0x004c6d9a in tsubst_decl (t=0x777a7e60, args=0x777a6d98, complain=3) at ../../gcc/gcc/cp/pt.c:9789 #2 0x004c3ce5 in tsubst (in_decl=optimized out, complain=3, args=0x777a6d98, t=0x777a7e60) at ../../gcc/gcc/cp/pt.c:10851 #3 tsubst (t=0x777a7e60, args=0x777a6d98, complain=3, in_decl=optimized out) at ../../gcc/gcc/cp/pt.c:10836 #4 0x004c821f in tsubst_pack_expansion (t=0x777afe70, args=0x777a6f78, complain=3, in_decl=0x777a7f18) at ../../gcc/gcc/cp/pt.c:9298 #5 0x004c656b in tsubst_template_args (t=0x777a6ac8, args=0x777a6d98, complain=3, in_decl=0x777a7f18) at ../../gcc/gcc/cp/pt.c:9400 #6 0x004c1e46 in tsubst_copy_and_build (t=0x77fd9a50, args=0x777a6d98, complain=3, in_decl=0x777a7f18, function_p=1 '\001', integral_constant_expression_p=optimized out) at ../../gcc/gcc/cp/pt.c:13035 #7 0x004c1c9e in tsubst_copy_and_build (t=0x777bd038, args=0x777a6d98, complain=3, in_decl=0x777a7f18, function_p=0 '\000', integral_constant_expression_p=0 '\000') at ../../gcc/gcc/cp/pt.c:13390 #8 0x004bd239 in tsubst_expr (t=0x777bd038, args=0x777a6d98, complain=3, in_decl=0x777a7f18, integral_constant_expression_p=0 '\000') at ../../gcc/gcc/cp/pt.c:12935 #9 0x004bdc70 in tsubst_expr (t=0x777a6b40, args=0x777a6d98, complain=3, in_decl=0x777a7f18, integral_constant_expression_p=0 '\000') at ../../gcc/gcc/cp/pt.c:12467 #10 0x004bd2b1 in tsubst_expr (t=0x777bd000, args=0x777a6d98, complain=3, in_decl=0x777a7f18, integral_constant_expression_p=0 '\000') at ../../gcc/gcc/cp/pt.c:12632 #11 0x004d0ccc in instantiate_decl (d=0x777aee00, defer_ok=optimized out, expl_inst_class_mem_p=optimized out) at ../../gcc/gcc/cp/pt.c:18305 #12 0x004d34dc in instantiate_pending_templates (retries=optimized out) at ../../gcc/gcc/cp/pt.c:18402 #13 0x004e8a4d in cp_write_global_declarations () at ../../gcc/gcc/cp/decl2.c:3713 #14 0x007f11c2 in compile_file () at ../../gcc/gcc/toplev.c:564 #15 do_compile () at ../../gcc/gcc/toplev.c:1886 #16 toplev_main (argc=13, argv=0x7fffdf28) at ../../gcc/gcc/toplev.c:1962 #17 0x77b81f82 in __libc_start_main (main=0x5a11b0 main, argc=13, ubp_av=0x7fffdf28, init=optimized out, fini=optimized out, rtld_fini=optimized out, stack_end=0x7fffdf18) at libc-start.c:226 #18 0x0048cf89 in _start () at ../sysdeps/x86_64/elf/start.S:113 (gdb)
[Bug c++/50400] New: compiler accepts invalid X::Impl::Impl::Impl::.....::foo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50400
Bug #: 50400
Summary: compiler accepts invalid
X::Impl::Impl::Impl::.::foo
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pl...@agmk.net
struct X { struct Impl; };
struct X::Impl {
Impl();
void foo();
};
X::Impl::Impl() {
void ( X::Impl::* ptr )() = X::Impl::Impl::Impl::Impl::Impl::foo;
}
gcc-4.6-20110908 and clang++ accept this code while e.g. MSVC reports
an error: C3083: '{ctor}': the symbol to the left of a '::' must be a type
[Bug fortran/50401] New: SIGSEGV in resolve_transfer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50401 Bug #: 50401 Summary: SIGSEGV in resolve_transfer Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com Created attachment 25277 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25277 just compile it SIGSEGV in resolve_transfer
[Bug fortran/50402] New: ICE in gfc_conv_expr_descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50402 Bug #: 50402 Summary: ICE in gfc_conv_expr_descriptor Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com Created attachment 25278 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25278 just compile it ICE in gfc_conv_expr_descriptor
[Bug fortran/50403] New: SIGSEGV in gfc_use_derived
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50403 Bug #: 50403 Summary: SIGSEGV in gfc_use_derived Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com Created attachment 25279 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25279 just compile it SIGSEGV in gfc_use_derived
[Bug fortran/50404] New: SIGSEGV in gfc_resolve_close
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50404 Bug #: 50404 Summary: SIGSEGV in gfc_resolve_close Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com Created attachment 25280 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25280 just compile it SIGSEGV in gfc_resolve_close
[Bug fortran/50405] New: allocation LOOP or SIGSEGV
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50405 Bug #: 50405 Summary: allocation LOOP or SIGSEGV Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com Created attachment 25281 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25281 just compile it allocation LOOP or SIGSEGV
[Bug fortran/50406] New: ld undefined reference to __MOD_str
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50406 Bug #: 50406 Summary: ld undefined reference to __MOD_str Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com Created attachment 25282 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25282 just compile and link ld undefined reference to __MOD_str
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 vladimir penev vovata at gmail dot com changed: What|Removed |Added CC||vovata at gmail dot com --- Comment #32 from vladimir penev vovata at gmail dot com 2011-09-15 08:30:55 UTC --- An update on this subject at my side. After some interactions with IBM AIX support there is a fix https://www-304.ibm.com/support/docview.wss?uid=isg1IV06344 and after that the assembler doesn't crash any more and works as well in the same time. It has been validated on AIX 6.1 with GCC 4.5.2
[Bug fortran/50407] New: compiler confused by .operator.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50407 Bug #: 50407 Summary: compiler confused by .operator. Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com Created attachment 25283 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25283 just compile it compiler confused by .operator.
[Bug fortran/50408] New: ICE in transfer_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50408 Bug #: 50408 Summary: ICE in transfer_expr Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com Created attachment 25284 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25284 just compile it ICE in transfer_expr
[Bug fortran/50409] New: SIGSEGV in gfc_simplify_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50409 Bug #: 50409 Summary: SIGSEGV in gfc_simplify_expr Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com Created attachment 25285 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25285 just compile it SIGSEGV in gfc_simplify_expr
[Bug fortran/50410] New: ICE in record_reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410 Bug #: 50410 Summary: ICE in record_reference Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com Created attachment 25286 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25286 just compile it ICE in record_reference
[Bug fortran/50411] New: gfortran -Ofast SIGSEGV in vect_recog_dot_prod_pattern
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50411 Bug #: 50411 Summary: gfortran -Ofast SIGSEGV in vect_recog_dot_prod_pattern Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com Created attachment 25287 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25287 please compile it with -Ofast gfortran -Ofast SIGSEGV in vect_recog_dot_prod_pattern
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 --- Comment #33 from vladimir penev vovata at gmail dot com 2011-09-15 08:44:04 UTC --- An update on this subject at my side. After some interactions with IBM AIX support there is a fix https://www-304.ibm.com/support/docview.wss?uid=isg1IV06344 and after that the assembler doesn't crash any more and works as well in the same time. It has been validated on AIX 6.1 TL6 with GCC 4.5.2
[Bug fortran/50412] New: gfortran -Ofast ICE in vect_do_peeling_for_loop_bound
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50412 Bug #: 50412 Summary: gfortran -Ofast ICE in vect_do_peeling_for_loop_bound Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com Created attachment 25288 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25288 please compile it with -Ofast gfortran -Ofast ICE in vect_do_peeling_for_loop_bound
[Bug tree-optimization/50413] Incorrect instruction is used to shift value of 128 bit xmm0 registrer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50413 --- Comment #1 from Anatoly aries.nah at gmail dot com 2011-09-15 08:44:57 UTC --- Created attachment 25289 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25289 C++ source code
[Bug fortran/50415] New: gfortran -Ofast SIGSEGV in find_uses_to_rename_use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50415 Bug #: 50415 Summary: gfortran -Ofast SIGSEGV in find_uses_to_rename_use Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com Created attachment 25291 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25291 please compile it with -Ofast gfortran -Ofast SIGSEGV in find_uses_to_rename_use
[Bug tree-optimization/50413] New: Incorrect instruction is used to shift value of 128 bit xmm0 registrer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50413 Bug #: 50413 Summary: Incorrect instruction is used to shift value of 128 bit xmm0 registrer Classification: Unclassified Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: aries@gmail.com After compilation an attached code with -O2 and -ftree-vectorize flags, it doesn't work properly. Assembler code shows that G++ tries to replace the following code V.uint128.uint64_lower = (V.uint128.uint64_lower 1); V.bitmap.b63 = V.bitmap.b64; V.uint128.uint64_upper = (V.uint128.uint64_upper 1); with SSE instructions: 400a10: movdqa 0x103d8(%rip),%xmm0# 410df0 V 400a17: and$0x1,%edi 400a1b: psrlq $0x1,%xmm0 400a20: movdqa %xmm0,0x103c8(%rip)# 410df0 V But psrlq shifts 64 bit value, it's necessary to use psrldq here
[Bug fortran/50414] New: gfortran -Ofast SIGSEGV in store_constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50414 Bug #: 50414 Summary: gfortran -Ofast SIGSEGV in store_constructor Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com Created attachment 25290 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25290 please compile it with -Ofast gfortran -Ofast SIGSEGV in store_constructor
[Bug fortran/50416] New: gfortran -O1 ICE MPFR assertion failed: 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50416 Bug #: 50416 Summary: gfortran -O1 ICE MPFR assertion failed: 0 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com Created attachment 25292 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25292 please compile it with -O1 gfortran -O1 ICE MPFR assertion failed: 0 I have mpfr 2.4.2-1
[Bug tree-optimization/50417] New: regression: memcpy with known alignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50417
Bug #: 50417
Summary: regression: memcpy with known alignment
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: wouter.vermae...@scarlet.be
Consider these functions:
void copy1(char* d, const char* s) {
memcpy(d, s, 256);
}
void copy2(short* d, const short* s) {
memcpy(d, s, 256);
}
void copy3(int* d, const int* s) {
memcpy(d, s, 256);
}
void copy4(long* d, const long* s) {
memcpy(d, s, 256);
}
g++-4.5.2 is able to generate better code for the later functions. But when I
test with a recent snapshot (SVN revision 178875 on linux x86_64) it generates
the same code for all versions (same as copy1()).
[Bug c++/50418] New: nested class typedef with same name and pointing to parent class typedef
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50418
Bug #: 50418
Summary: nested class typedef with same name and pointing to
parent class typedef
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: frrr...@gmail.com
struct A
{
typedef int T;
struct B
{
typedef T T;
};
};
test.cpp:6:19: error: declaration of ‘typedef A::T A::B::T’
test.cpp:3:17: error: changes meaning of ‘T’ from ‘typedef int A::T’
It works with Comeau, Clang and VC++, gcc workaround is the following:
struct A
{
typedef int T;
struct B
{
typedef A::T T;
};
};
[Bug tree-optimization/50413] Incorrect instruction is used to shift value of 128 bit xmm0 registrer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50413 --- Comment #2 from Anatoly aries.nah at gmail dot com 2011-09-15 09:05:03 UTC --- Forgot to mention: Intel(R) Core(TM) i5 CPU 760 @ 2.80GHz LGA1156 And there's no such bug in GCC 4.3.4
[Bug libstdc++/41816] ldconfig warnings vs. libstdc++.so.6.0.14-gdb.py
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41816
Markus Trippelsdorf markus at trippelsdorf dot de changed:
What|Removed |Added
CC||markus at trippelsdorf dot
||de
--- Comment #6 from Markus Trippelsdorf markus at trippelsdorf dot de
2011-09-15 09:06:16 UTC ---
Why don't we just install this file in
/usr/share/gdb/auto-load/usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.0/ instead of
$(DESTDIR)$(toolexeclibdir)/ by default?
BTW Gentoo does this by default:
# Move pretty-printers to gdb datadir to shut ldconfig up
gdbdir=/usr/share/gdb/auto-load${LIBPATH/\/lib\//\/$(get_libdir)\/}
for i in ${D}${LIBPATH}{,/32}/*-gdb.py; do
if [[ -e ${i} ]]; then
basedir=$(dirname ${i/${D}${LIBPATH}/})
sed -i -e s:^\(libdir = \).*:\1'${LIBPATH}${basedir}': ${i}
#348128
insinto ${gdbdir}${basedir}
doins ${i}
rm ${i}
fi
done
[Bug c++/50399] [c++11] Lookup error w/ enums
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50399 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-09-15 09:21:30 UTC --- I think G++ is correct, see [basic.lookup.qual] In C++03 a nested-name-specifier can only refer to a class or namespace, in C++11 it can also refer to an enumeration.
[Bug c++/50399] [c++11] Lookup error w/ enums
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50399 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-09-15 09:26:38 UTC --- C++03 says During the lookup for a name preceding the :: scope resolution operator, object, function, and enumerator names are ignored. So in -std=c++98 mode G++ is correct to ignore A::C::B and so finds B::F (Clang gets this wrong) In C++11 the enumeration is not ignored (because a nested-name-specifier could refer to a scoped enumeration) so name lookup finds B in the enclosing namespace, i.e. A::C::B
[Bug c++/50400] compiler accepts invalid X::Impl::Impl::Impl::.....::foo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50400 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-09-15 09:34:52 UTC --- EDG accepts it too, are you suggesting MSVC is right and all the others wrong? That would be a first ;) See http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#318 Because the constructor Impl::Impl is not an acceptable lookup result in the expression X::Impl::Impl::foo the second Impl names the class itself, and so the code is valid and G++ is correct
[Bug tree-optimization/50414] gfortran -Ofast SIGSEGV in store_constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50414
Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch changed:
What|Removed |Added
Component|fortran |tree-optimization
--- Comment #1 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch
2011-09-15 09:59:37 UTC ---
Breakpoint 2, internal_error (gmsgid=0xf3ffe8 gimple check: expected %s(%s),
have %s(%s) in %s, at %s:%d) at ../../gcc/gcc/diagnostic.c:833
833 {
(gdb) bt
#0 internal_error (gmsgid=0xf3ffe8 gimple check: expected %s(%s), have %s(%s)
in %s, at %s:%d) at ../../gcc/gcc/diagnostic.c:833
#1 0x0079a306 in gimple_check_failed (gs=0x75b58580,
file=Unhandled dwarf expression opcode 0xf3
) at ../../gcc/gcc/gimple.c:1156
#2 0x00aa8f9f in gimple_phi_arg (op=value optimized out,
vec_oprnds=0x7fffd5e8, op_num=0, number_of_vectors=1, reduc_index=2,
slp_node=Unhandled dwarf expression opcode 0xfa
)
at ../../gcc/gcc/gimple.h:3369
#3 gimple_phi_arg_imm_use_ptr (op=value optimized out,
vec_oprnds=0x7fffd5e8, op_num=0, number_of_vectors=1, reduc_index=2,
slp_node=Unhandled dwarf expression opcode 0xfa
)
at ../../gcc/gcc/tree-flow-inline.h:452
#4 vect_get_constant_vectors (op=value optimized out,
vec_oprnds=0x7fffd5e8, op_num=0, number_of_vectors=1, reduc_index=2,
slp_node=Unhandled dwarf expression opcode 0xfa
)
at ../../gcc/gcc/tree-vect-slp.c:2013
#5 0x00aab177 in vect_get_slp_defs (op0=0x75b55910, op1=0x0,
slp_node=0x16d5d70, vec_oprnds0=0x7fffd5e8, vec_oprnds1=0x0, reduc_index=2)
at ../../gcc/gcc/tree-vect-slp.c:2145
#6 0x00a983cb in vect_create_epilog_for_reduction
(vect_defs=0x16d6260, stmt=0x75b58580, ncopies=1,
reduc_code=REDUC_MAX_EXPR,
reduction_phis=0x16d66c0, reduc_index=2, double_reduc=false,
slp_node=0x16d5d70) at ../../gcc/gcc/tree-vect-loop.c:3541
#7 0x00a9cf8d in vectorizable_reduction (stmt=0x7fff0001,
gsi=0x7fffd900, vec_stmt=0x7fffd878, slp_node=0x16d5d70)
at ../../gcc/gcc/tree-vect-loop.c:4902
#8 0x00a91805 in vect_transform_stmt (stmt=0x75b58580,
gsi=0x7fffd900, strided_store=0x7fffd8ff, slp_node=0x16d5d70,
slp_node_instance=Unhandled dwarf expression opcode 0xf3
)
at ../../gcc/gcc/tree-vect-stmts.c:5218
#9 0x00aa7b40 in vect_schedule_slp_instance (node=0x16d5d70,
instance=0x16d5ed0, vectorization_factor=Unhandled dwarf expression opcode 0xf3
) at ../../gcc/gcc/tree-vect-slp.c:2574
#10 0x00aadbc8 in vect_schedule_slp (loop_vinfo=Unhandled dwarf
expression opcode 0xf3
) at ../../gcc/gcc/tree-vect-slp.c:2604
#11 0x00aa1a5c in vect_transform_loop (loop_vinfo=0x16ff380) at
../../gcc/gcc/tree-vect-loop.c:5317
#12 0x00aae7e3 in vectorize_loops () at
../../gcc/gcc/tree-vectorizer.c:214
#13 0x00876d37 in execute_one_pass (pass=0x1498f00) at
../../gcc/gcc/passes.c:2063
[Bug tree-optimization/50415] gfortran -Ofast SIGSEGV in find_uses_to_rename_use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50415 Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-15 Component|fortran |tree-optimization Ever Confirmed|0 |1 --- Comment #1 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-09-15 10:03:10 UTC --- #0 find_uses_to_rename_use (bb=0x77eae7b8, use=0x75b56910, use_blocks=Unhandled dwarf expression opcode 0xf3 ) at ../../gcc/gcc/tree-ssa-loop-manip.c:1267 #1 find_uses_to_rename_use (bb=0x77eae7b8, use=0x75b56910, use_blocks=Unhandled dwarf expression opcode 0xf3 ) at ../../gcc/gcc/tree-ssa-loop-manip.c:232 #2 0x00a06d10 in find_uses_to_rename_bb (bb=0x77eae7b8, use_blocks=0x16d83c0, need_phis=0x16dfcd0) at ../../gcc/gcc/tree-ssa-loop-manip.c:302 #3 0x00a07506 in find_uses_to_rename (changed_bbs=Unhandled dwarf expression opcode 0xf3 ) at ../../gcc/gcc/tree-ssa-loop-manip.c:331 #4 rewrite_into_loop_closed_ssa (changed_bbs=Unhandled dwarf expression opcode 0xf3 ) at ../../gcc/gcc/tree-ssa-loop-manip.c:391 #5 0x0096bad4 in ldist_gen (loop=Unhandled dwarf expression opcode 0xf3 ) at ../../gcc/gcc/tree-loop-distribution.c:1134 #6 distribute_loop (loop=Unhandled dwarf expression opcode 0xf3 ) at ../../gcc/gcc/tree-loop-distribution.c:1216 #7 distribute_loop (loop=Unhandled dwarf expression opcode 0xf3 ) at ../../gcc/gcc/tree-loop-distribution.c:1158 #8 0x0096c895 in tree_loop_distribution () at ../../gcc/gcc/tree-loop-distribution.c:1272 #9 0x00876d37 in execute_one_pass (pass=0x1497f40) at ../../gcc/gcc/passes.c:2063 #10 0x008770a5 in execute_pass_list (pass=0x1497f40) at ../../gcc/gcc/passes.c:2118 #11 0x008770b7 in execute_pass_list (pass=0x14990e0) at ../../gcc/gcc/passes.c:2119
[Bug tree-optimization/50414] gfortran -Ofast SIGSEGV in store_constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50414 Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-15 Ever Confirmed|0 |1
[Bug libstdc++/41816] ldconfig warnings vs. libstdc++.so.6.0.14-gdb.py
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41816 --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org 2011-09-15 10:04:18 UTC --- (In reply to comment #6) Why don't we just install this file in /usr/share/gdb/auto-load/usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.0/ instead of $(DESTDIR)$(toolexeclibdir)/ by default? Who's we? I have several versions of GDB and GCC installed, which GDB data dir should I put the printers in, all of them? That would need root access in some cases. BTW Gentoo does this by default: Gentoo is a distro and can decide to put the system compiler's files in the system debugger's data dir, not everyone who installs GCC can do that.
[Bug tree-optimization/50412] gfortran -Ofast ICE in vect_do_peeling_for_loop_bound
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50412 Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-15 Component|fortran |tree-optimization Ever Confirmed|0 |1 --- Comment #1 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-09-15 10:05:27 UTC --- #0 internal_error (gmsgid=0x117c39a in %s, at %s:%d) at ../../gcc/gcc/diagnostic.c:833 #1 0x00e3f394 in fancy_abort (file=Unhandled dwarf expression opcode 0xf3 ) at ../../gcc/gcc/diagnostic.c:893 #2 0x00aa5fce in vect_do_peeling_for_loop_bound (loop_vinfo=0x16e3870, ratio=0x7fffda58, cond_expr=0x0, cond_expr_stmt_list=0x0) at ../../gcc/gcc/tree-vect-loop-manip.c:1931 #3 0x00aa1c7c in vect_transform_loop (loop_vinfo=0x16e3870) at ../../gcc/gcc/tree-vect-loop.c:5161 #4 0x00aae7e3 in vectorize_loops () at ../../gcc/gcc/tree-vectorizer.c:214 #5 0x00876d37 in execute_one_pass (pass=0x1498f00) at ../../gcc/gcc/passes.c:2063
[Bug c++/50344] friend declaration confused by const qualifier
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50344 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2011-09-15 10:06:31 UTC --- Thanks Paolo - I forgot to add a follow-up comment to say I'd tested it
[Bug tree-optimization/50414] [4.7 Regression] gfortran -Ofast SIGSEGV in store_constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50414 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Summary|gfortran -Ofast SIGSEGV in |[4.7 Regression] gfortran |store_constructor |-Ofast SIGSEGV in ||store_constructor --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-09-15 10:27:53 UTC --- This is a regression that occurred between revisions 173852 (OK) and 175707 (ICE). If needed, I'll be able to narrow the range later today.
[Bug tree-optimization/50415] [4.7 Regression] gfortran -Ofast SIGSEGV in find_uses_to_rename_use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50415 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Summary|gfortran -Ofast SIGSEGV in |[4.7 Regression] gfortran |find_uses_to_rename_use |-Ofast SIGSEGV in ||find_uses_to_rename_use --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-09-15 10:33:01 UTC --- This is a regression that occurred in the same range as pr50414 (between revisions 173852 (OK) and 175707 (ICE)).
[Bug fortran/50416] gfortran -O1 ICE MPFR assertion failed: 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50416 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-09-15 10:39:12 UTC --- It works for me with -O1, -Ofast, and -m32 -Ofast. I used x86_64-apple-darwin10 with GMP version 5.0.2, MPFR version 3.0.1, MPC version 0.9 Likely a MPFR (or its use) bug. I suggest to close this pr as invalid.
[Bug libstdc++/41816] ldconfig warnings vs. libstdc++.so.6.0.14-gdb.py
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41816 --- Comment #8 from Markus Trippelsdorf markus at trippelsdorf dot de 2011-09-15 10:50:37 UTC --- (In reply to comment #7) (In reply to comment #6) Why don't we just install this file in /usr/share/gdb/auto-load/usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.0/ instead of $(DESTDIR)$(toolexeclibdir)/ by default? Who's we? The big other :-) I have several versions of GDB and GCC installed, which GDB data dir should I put the printers in, all of them? That would need root access in some cases. All versions of GDB would look into the same directory structure. And there would be one subdirectory for each different GCC version. And of course you'll need root access in this case, but *we* could fall back to the current location for a installation without root access.
[Bug fortran/50411] gfortran -Ofast SIGSEGV in vect_recog_dot_prod_pattern
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50411 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-09-15 10:55:19 UTC --- Likely a duplicate of pr50343 fixed by revision 178775. I use this pr for some general comments: (1) follow the Mikael Morin's advice in pr50375 comment #4: Please paste the code content directly instead of attaching for small (say, less than around 10-20 lines) files. (2) try to give the revision of the gfortran against which your report the bug. (3) use the free form for the code (i.e. ! instead of c).
[Bug fortran/50409] SIGSEGV in gfc_simplify_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50409 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-15 Ever Confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-09-15 11:04:05 UTC --- On x86_64-apple-darwin10 from gfortran 4.4 to 4.7 I had to interrupt the compilation after several minutes. Sampling the compilation yielded: Sampling process 55479 for 3 seconds with 1 millisecond of run time between samples Sampling completed, processing symbols... Analysis of sampling f951 (pid 55479) every 1 millisecond Process: f951 [55479] Path: /opt/gcc/gcc4.7w/libexec/gcc/x86_64-apple-darwin10.8.0/4.7.0/f951 Load Address:0x1 Identifier: f951 Version: ??? (???) Code Type: X86-64 (Native) Parent Process: gfortran [55477] Date/Time: 2011-09-15 11:05:43.420 +0200 OS Version: Mac OS X 10.6.8 (10K549) Report Version: 6 Call graph: 2366 Thread_2859011 DispatchQueue_1: com.apple.main-thread (serial) 2366 gfc_simplify_expr(gfc_expr*, int) 2366 __memcpy 2366 _sigtramp 2366 crash_signal(int) 2366 internal_error(char const*, ...) 2366 diagnostic_set_info(diagnostic_info*, char const*, __va_list_tag (*) [1], unsigned int, diagnostic_t) 2366 libintl_dcigettext 2366 strcmp Total number in stack (recursive counted multiple, when =5): Sort by top of stack, same collapsed (when = 5): strcmp2366 Binary Images: 0x1 -0x100d5bfef +f951 ??? (???) 69BA1A11-FFE8-2BE9-0157-915E87E95F7C /opt/gcc/gcc4.7w/libexec/gcc/x86_64-apple-darwin10.8.0/4.7.0/f951 0x14145b000 -0x141462fff +libintl.8.dylib 9.2.0 (compatibility 9.0.0) 77764503-B558-C86F-5C9D-0896504B2BA5 /sw64/lib/libintl.8.dylib 0x141467000 -0x141562fe7 +libiconv.2.dylib 7.0.0 (compatibility 7.0.0) 2F723465-84E7-77FB-F9FD-572D6A0DBBCC /sw64/lib/libiconv.2.dylib 0x14157e000 -0x14159aff7 +libcloog-isl.2.dylib 3.0.0 (compatibility 3.0.0) E60A7BC6-03C5-DD6E-A6EF-27B85411B2A4 /opt/sw64/lib/libcloog-isl.2.dylib 0x1415a5000 -0x141646ff7 +libisl.7.dylib 8.0.0 (compatibility 8.0.0) B502B39E-85E7-4346-20F6-AE72BC5E44D9 /opt/sw64/lib/libisl.7.dylib 0x141668000 -0x141ac1ff7 +libppl_c.4.dylib 5.0.0 (compatibility 5.0.0) E05D2529-6FEB-6511-7B01-474FF91FD359 /opt/sw64/lib/libppl_c.4.dylib 0x141c45000 -0x141d1fff7 +libppl.9.dylib 10.0.0 (compatibility 10.0.0) A5F94C60-C0C2-B343-F8C3-5C04EA05A356 /opt/sw64/lib/libppl.9.dylib 0x141d92000 -0x141d94fff +libgmpxx.4.dylib 7.2.0 (compatibility 7.0.0) 0AAF15CD-F0FC-E622-38E0-06C422E3ED95 /opt/sw64/lib/libgmpxx.4.dylib 0x141d98000 -0x141da8fff +libmpc.2.dylib 3.0.0 (compatibility 3.0.0) 306CC750-3595-7C0D-5FAE-286A1A7BA40E /opt/sw64/lib/libmpc.2.dylib 0x141dad000 -0x141df9ff7 +libmpfr.4.dylib 5.1.0 (compatibility 5.0.0) 99C678CB-35EA-1551-2921-8FAA54300718 /opt/sw64/lib/libmpfr.4.dylib 0x141e04000 -0x141e62ff7 +libgmp.10.dylib 11.2.0 (compatibility 11.0.0) B66ADC3C-CB23-AA46-1E5D-38009780079D /opt/sw64/lib/libgmp.10.dylib 0x141e73000 -0x141e74fff +libpwl.5.dylib 6.0.0 (compatibility 6.0.0) 6A4D7AF5-89E9-6E5E-1062-2DDA1628C121 /opt/sw64/lib/libpwl.5.dylib 0x7fff5fc0 - 0x7fff5fc3bdef dyld 132.1 (???) B536F2F1-9DF1-3B6C-1C2C-9075EA219A06 /usr/lib/dyld 0x7fff802f4000 - 0x7fff802f8ff7 libmathCommon.A.dylib 315.0.0 (compatibility 1.0.0) 95718673-FEEE-B6ED-B127-BCDBDB60D4E5 /usr/lib/system/libmathCommon.A.dylib 0x7fff82201000 - 0x7fff8224dfff libauto.dylib ??? (???) F7221B46-DC4F-3153-CE61-7F52C8C293CF /usr/lib/libauto.dylib 0x7fff83667000 - 0x7fff83828fef libSystem.B.dylib 125.2.11 (compatibility 1.0.0) 9AB4F1D1-89DC-0E8A-DC8E-A4FE4D69DB69 /usr/lib/libSystem.B.dylib 0x7fff8387e000 - 0x7fff83934ff7 libobjc.A.dylib 227.0.0 (compatibility 1.0.0) 03140531-3B2D-1EBA-DA7F-E12CC8F63969 /usr/lib/libobjc.A.dylib 0x7fff85fd5000 - 0x7fff86052fef libstdc++.6.dylib 7.9.0 (compatibility 7.0.0) 35ECA411-2C08-FD7D-11B1-1B7A04921A5C /usr/lib/libstdc++.6.dylib 0x7fff87636000 - 0x7fff877adfe7 com.apple.CoreFoundation 6.6.5 (550.43) 31A1C118-AD96-0A11-8BDF-BD55B9940EDC /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 0x7fff87c6f000 - 0x7fff87e2dfff libicucore.A.dylib 40.0.0 (compatibility 1.0.0) 4274FC73-A257-3A56-4293-5968F3428854 /usr/lib/libicucore.A.dylib 0x7fff899ad000 - 0x7fff899beff7 libz.1.dylib 1.2.3 (compatibility 1.0.0) FB5EE53A-0534-0FFA-B2ED-486609433717 /usr/lib/libz.1.dylib
[Bug fortran/50410] [4.6/4.7 Regression] ICE in record_reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-15 Summary|ICE in record_reference |[4.6/4.7 Regression] ICE in ||record_reference Ever Confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-09-15 11:08:55 UTC --- Confirmed on 4.6.1 and trunk: pr50410.f90:7:0: internal compiler error: in record_reference, at cgraphbuild.c:67 no ICE on 4.4.6 and 4.5.3 (no error). g95 gives the following error: In file pr50410.f90:6 data u%g /1/ 1 Error: Can't dereference POINTER in DATA statement at (1)
[Bug testsuite/50076] FAIL: c-c++-common/cxxbitfields-3.c scan-assembler movl.*, var on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50076 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||iains at gcc dot gnu.org --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-09-15 11:16:14 UTC --- Could someone look at this pr and decide if the code movq_var@GOTPCREL(%rip), %rdx movl(%rdx), %eax is buggy (in this case I cannot help) or if the dg-final has to be adjusted for darwin (then I can try to find a suitable regexp).
[Bug fortran/50401] SIGSEGV in resolve_transfer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50401
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Keywords||ice-on-invalid-code
Last reconfirmed||2011-09-15
CC||janus at gcc dot gnu.org
AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment #1 from janus at gcc dot gnu.org 2011-09-15 11:17:16 UTC ---
The obvious fix:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 178876)
+++ gcc/fortran/resolve.c (working copy)
@@ -8222,7 +8222,7 @@
}
}
- if (sym-as != NULL sym-as-type == AS_ASSUMED_SIZE
+ if (sym-as != NULL sym-as-type == AS_ASSUMED_SIZE exp-ref
exp-ref-type == REF_ARRAY exp-ref-u.ar.type == AR_FULL)
{
gfc_error (Data transfer element at %L cannot be a full reference to
[Bug middle-end/50315] Regression on Atom after fix #49958
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50315 --- Comment #7 from Sergey Ostanevich sergos.gnu at gmail dot com 2011-09-15 11:24:27 UTC --- Richard, I believe your test should be reading as So you can go from (a +no b) +no c to a + no (b + c), dropping overflow knowledge on re-association. And let me re-phrase what's Joseph said (just to be sure I got the idea): we have to preserve the overflow semantics at GIMPLE level to avoid possible problems during translation into RTL. Consider we have situation without overflow in 32-bit with particular calculation order and can use either 32-bit or 64-bit operations to perform that. But after reassociation in GIMPLE we can introduce overflow for 32-bit, that will lead to wrong result in case we use 64-bit operations. Being aware of such situation during traslation we can evade error, but it requires too much effort (or even impossible) to provide this data to the translator. Is it right?
[Bug tree-optimization/50414] [4.7 Regression] gfortran -Ofast SIGSEGV in store_constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50414 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-09-15 11:27:35 UTC --- This is a regression that occurred between revisions 173852 (OK) and 175707 (ICE). If needed, I'll be able to narrow the range later today. 173817 is OK 173917 gives the ICE
[Bug tree-optimization/50415] [4.7 Regression] gfortran -Ofast SIGSEGV in find_uses_to_rename_use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50415 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-09-15 11:30:14 UTC --- This is a regression that occurred in the same range as pr50414 (between revisions 173852 (OK) and 175707 (ICE)). r174030 is OK r174283 gives the ICE.
[Bug tree-optimization/50415] [4.7 Regression] gfortran -Ofast SIGSEGV in find_uses_to_rename_use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50415 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-09-15 11:33:16 UTC --- '-O2 -ftree-vectorize' is OK, '-O3' gives the ICE.
[Bug libstdc++/41816] ldconfig warnings vs. libstdc++.so.6.0.14-gdb.py
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41816 --- Comment #9 from Jonathan Wakely redi at gcc dot gnu.org 2011-09-15 11:33:50 UTC --- Hmm yes, this is only really an issue for people who install libstdc++ into a directory that ldconfig searches, which for most people means it only affects the system compiler, which means distros can fix it for their users as Gentoo does. For everyone who installs GCC themselves without root access, they probably don't get the ldconfig warnings anyway, so don't care. A config option allowing that to be automated would make things a little easier for those who do want to move the file.
[Bug tree-optimization/50412] gfortran -Ofast ICE in vect_do_peeling_for_loop_bound
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50412
Ira Rosen irar at il dot ibm.com changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC||irar at il dot ibm.com
AssignedTo|unassigned at gcc dot |irar at il dot ibm.com
|gnu.org |
--- Comment #2 from Ira Rosen irar at il dot ibm.com 2011-09-15 11:40:59 UTC
---
The problem is that we don't support loop peeling for outer loops, but we
support single element interleaving that may require peeling. I'll test this
patch:
Index: tree-vect-data-refs.c
===
--- tree-vect-data-refs.c (revision 178780)
+++ tree-vect-data-refs.c (working copy)
@@ -2055,6 +2059,10 @@ vect_analyze_group_access (struct data_r
HOST_WIDE_INT dr_step = TREE_INT_CST_LOW (step);
HOST_WIDE_INT stride, last_accessed_element = 1;
bool slp_impossible = false;
+ struct loop *loop = NULL;
+
+ if (loop_vinfo)
+loop = LOOP_VINFO_LOOP (loop_vinfo);
/* For interleaving, STRIDE is STEP counted in elements, i.e., the size of
the
interleaving group (including gaps). */
@@ -2085,11 +2093,17 @@ vect_analyze_group_access (struct data_r
if (loop_vinfo)
{
- LOOP_VINFO_PEELING_FOR_GAPS (loop_vinfo) = true;
-
if (vect_print_dump_info (REPORT_DETAILS))
fprintf (vect_dump, Data access with gaps requires scalar
epilogue loop);
+ if (loop-inner)
+{
+ if (vect_print_dump_info (REPORT_DETAILS))
+fprintf (vect_dump, Peeling for outer loop is not
supported);
+ return false;
+}
+
+ LOOP_VINFO_PEELING_FOR_GAPS (loop_vinfo) = true;
}
return true;
@@ -2272,10 +2286,17 @@ vect_analyze_group_access (struct data_r
/* There is a gap in the end of the group. */
if (stride - last_accessed_element 0 loop_vinfo)
{
- LOOP_VINFO_PEELING_FOR_GAPS (loop_vinfo) = true;
if (vect_print_dump_info (REPORT_DETAILS))
fprintf (vect_dump, Data access with gaps requires scalar
epilogue loop);
+ if (loop-inner)
+{
+ if (vect_print_dump_info (REPORT_DETAILS))
+fprintf (vect_dump, Peeling for outer loop is not
supported);
+ return false;
+}
+
+ LOOP_VINFO_PEELING_FOR_GAPS (loop_vinfo) = true;
}
}
[Bug fortran/50403] SIGSEGV in gfc_use_derived
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50403 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Keywords||ice-on-invalid-code Last reconfirmed||2011-09-15 CC||janus at gcc dot gnu.org AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from janus at gcc dot gnu.org 2011-09-15 11:41:06 UTC --- This one is also obvious: Index: gcc/fortran/symbol.c === --- gcc/fortran/symbol.c(revision 178876) +++ gcc/fortran/symbol.c(working copy) @@ -1945,6 +1945,8 @@ gfc_symtree *st; int i; + if (!sym) return NULL; + if (sym-components != NULL || sym-attr.zero_comp) return sym; /* Already defined. */ Btw: Where do you get this enormous amount of invalid Fortran code?
[Bug c++/50418] nested class typedef with same name and pointing to parent class typedef
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50418 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-09-15 12:17:48 UTC --- [basic.scope.class] A name N used in a class S shall refer to the same declaration in its context and when re-evaluated in the completed scope of S. No diagnostic is required for a violation of this rule. Which implies the program is ill-formed.
[Bug c++/50418] nested class typedef with same name and pointing to parent class typedef
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50418 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-09-15 12:29:38 UTC --- you can use -fpermissive to make G++ accept the code
[Bug tree-optimization/50414] [4.7 Regression] gfortran -Ofast SIGSEGV in store_constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50414 Ira Rosen irar at il dot ibm.com changed: What|Removed |Added Status|NEW |ASSIGNED CC||irar at il dot ibm.com AssignedTo|unassigned at gcc dot |irar at il dot ibm.com |gnu.org | --- Comment #4 from Ira Rosen irar at il dot ibm.com 2011-09-15 12:36:04 UTC --- Looks like a mix up in the order of stmts in reduction SLP node. I'll take a better look next week.
[Bug tree-optimization/50413] Incorrect instruction is used to shift value of 128 bit xmm0 registrer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50413 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #3 from Uros Bizjak ubizjak at gmail dot com 2011-09-15 13:29:23 UTC --- (In reply to comment #0) After compilation an attached code with -O2 and -ftree-vectorize flags, it doesn't work properly. Assembler code shows that G++ tries to replace the following code V.uint128.uint64_lower = (V.uint128.uint64_lower 1); V.bitmap.b63 = V.bitmap.b64; V.uint128.uint64_upper = (V.uint128.uint64_upper 1); with SSE instructions: 400a10: movdqa 0x103d8(%rip),%xmm0# 410df0 V 400a17: and$0x1,%edi 400a1b: psrlq $0x1,%xmm0 400a20: movdqa %xmm0,0x103c8(%rip)# 410df0 V But psrlq shifts 64 bit value, it's necessary to use psrldq here You are wrong. The code above describes shift of two 64bit elements, each by one, so psrlq [1] is correct. [1] http://www.rz.uni-karlsruhe.de/rz/docs/VTune/reference/vc259.htm
[Bug fortran/50411] gfortran -Ofast SIGSEGV in vect_recog_dot_prod_pattern
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50411 Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #2 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-09-15 13:37:54 UTC --- dup fixed *** This bug has been marked as a duplicate of bug 50343 ***
[Bug middle-end/50343] [4.7 Regression] FAIL: gfortran.dg/graphite/id-22.f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50343 Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch changed: What|Removed |Added CC||zeccav at gmail dot com --- Comment #10 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-09-15 13:37:54 UTC --- *** Bug 50411 has been marked as a duplicate of this bug. ***
[Bug fortran/50408] ICE in transfer_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50408 Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-15 Ever Confirmed|0 |1 --- Comment #1 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-09-15 13:40:45 UTC --- a beauty :-) #0 internal_error (gmsgid=0x117c39a in %s, at %s:%d) at ../../gcc/gcc/diagnostic.c:833 #1 0x00e3f394 in fancy_abort (file=Unhandled dwarf expression opcode 0xf3 ) at ../../gcc/gcc/diagnostic.c:893 #2 0x005db4ce in transfer_expr (se=0x7fffd400, ts=Unhandled dwarf expression opcode 0xf3 ) at ../../gcc/gcc/fortran/trans-io.c:2156 #3 0x005dfe31 in gfc_trans_transfer (code=0x16cf1e0) at ../../gcc/gcc/fortran/trans-io.c:2305 #4 0x005956b8 in trans_code (code=0x16cf1e0, cond=0x77fef6f0) at ../../gcc/gcc/fortran/trans.c:1397 #5 0x005dd90b in build_dt (function=0x75b4d200, code=0x16cf450) at ../../gcc/gcc/fortran/trans-io.c:1832 #6 0x005dfbfd in gfc_trans_write (code=Unhandled dwarf expression opcode 0xf3 ) at ../../gcc/gcc/fortran/trans-io.c:1871 #7 0x005956d8 in trans_code (code=0x16cf450, cond=0x0) at ../../gcc/gcc/fortran/trans.c:1369 #8 0x005b999c in gfc_generate_function_code (ns=Unhandled dwarf expression opcode 0xf3 ) at ../../gcc/gcc/fortran/trans-decl.c:5211 #9 0x005578c7 in translate_all_program_units () at ../../gcc/gcc/fortran/parse.c:4404 #10 gfc_parse_file () at ../../gcc/gcc/fortran/parse.c:4617 #11 0x00590ac6 in gfc_be_parse_file () at ../../gcc/gcc/fortran/f95-lang.c:250
[Bug tree-optimization/50413] Incorrect instruction is used to shift value of 128 bit xmm0 registrer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50413 Anatoly aries.nah at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | --- Comment #4 from Anatoly aries.nah at gmail dot com 2011-09-15 13:42:05 UTC --- It's not serious. Yes, I'm not an expert in SSE instructions (and in ASM at all), and it seems you're right about shifting. But, the bug is a real. GCC losts lower bit of upper quadword during shifting by psrlq. Try to compile my code and check it out. We have V.bitmap.b63 = V.bitmap.b64; to shift a lower bit of the upper quadword but GCC has decided not to do this.
[Bug fortran/50406] ld undefined reference to __MOD_str
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50406 Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-15 Ever Confirmed|0 |1
[Bug fortran/50405] allocation LOOP or SIGSEGV
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50405 Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-15 Ever Confirmed|0 |1
[Bug fortran/50404] SIGSEGV in gfc_resolve_close
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50404 Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-15 Ever Confirmed|0 |1
[Bug fortran/50402] ICE in gfc_conv_expr_descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50402 Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-15 Ever Confirmed|0 |1
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 --- Comment #34 from Daniel Richard G. skunk at iskunk dot org 2011-09-15 14:01:36 UTC --- (In reply to comment #33) Vladimir, this [GCC] bug report has nothing to do with the assembler segfaulting. The problem is that the linker can't link what the assembler is producing (ld: 0711-593 SEVERE ERROR).
[Bug c++/50418] nested class typedef with same name and pointing to parent class typedef
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50418 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org 2011-09-15 14:07:04 UTC --- Invalid as noted in comment #1 .
[Bug c++/50365] [4.7 Regression] non-static data member error on valid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50365 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org |
[Bug tree-optimization/50419] New: Bad interaction between data-ref and disambiguation with restrict pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50419
Bug #: 50419
Summary: Bad interaction between data-ref and disambiguation
with restrict pointers
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@gcc.gnu.org
% cat predcom-fail.c
#define INFTY 987654321
#define Ra /*__restrict*/
#define Rv __restrict
void
P7Viterbi(int * Ra _dc, int * Ra _mc, int * Ra _tpdd, int * Ra _tpmd, int M)
{
int i,k;
int sc;
int * Rv dc = _dc;
int * Rv mc = _mc;
int * Rv tpdd = _tpdd;
int * Rv tpmd = _tpmd;
dc[0] = -INFTY;
for (k = 1; k M; k++) {
dc[k] = dc[k-1] + tpdd[k-1];
if ((sc = mc[k-1] + tpmd[k-1]) dc[k]) dc[k] = sc;
if (dc[k] -INFTY) dc[k] = -INFTY;
}
}
./cc1 -Ofast predcom-fail.c should be able to predcom the loop. It doesn't
because it doesn't see that the (first) dc[] write doesn't conflict with the
mc/tpmd[] reads. It should be able to see that because all the int pointers
are created with new restrict sets. If you defined Ra as also __restrict
(making the arguments already restrict qualified) you get the transformation.
The problem is an interaction between creating the datarefs and the
disambiguator. The data-ref base objects contain the casted inputs:
#(Data Ref:
# bb: 4
# stmt: D.2741_19 = *D.2740_18;
# ref: *D.2740_18;
# base_object: *(int * restrict) _dc_2(D);
# Access function 0: {0B, +, 4}_1
#)
vs
#(Data Ref:
# bb: 4
# stmt: D.2743_24 = *D.2742_23;
# ref: *D.2742_23;
# base_object: *(int * restrict) _tpdd_6(D);
# Access function 0: {0B, +, 4}_1
#)
The disambiguator used is ptr_derefs_may_alias_p on those two (casted)
pointers. But the first thing it does is to remove all conversions.
Remembering the original type wouldn't help as we need to look into the
points-to info of the restrict qualified object (i.e. the LHS of that
conversion).
Hence when creating the data-ref we shouldn't look through such casts, that
introduce useful information. I have a patch.
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 --- Comment #35 from vladimir penev vovata at gmail dot com 2011-09-15 14:14:16 UTC --- Yes, it's true. And using the mentioned efix for AIX the problem doesn't exist any more, the assembler generates correct code and the linker links it as well. Nothing to do at GCC side. I just inform the affected people about the existing of a fix.
[Bug tree-optimization/50419] Bad interaction between data-ref and disambiguation with restrict pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50419 --- Comment #1 from Michael Matz matz at gcc dot gnu.org 2011-09-15 14:16:54 UTC --- Created attachment 25293 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25293 (untested) patch Potential fix for this. As yet untested.
[Bug tree-optimization/50413] Incorrect instruction is used to shift value of 128 bit xmm0 registrer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50413 --- Comment #5 from Uros Bizjak ubizjak at gmail dot com 2011-09-15 14:17:34 UTC --- (In reply to comment #4) We have V.bitmap.b63 = V.bitmap.b64; to shift a lower bit of the upper quadword but GCC has decided not to do this. Ah, I didn't see the purpose of this assignment. I will investigate this a bit more.
[Bug tree-optimization/50413] [4.6/4.7 Regression] Incorrect instruction is used to shift value of 128 bit xmm0 registrer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50413 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-15 CC||irar at il dot ibm.com Target Milestone|--- |4.6.2 Summary|Incorrect instruction is|[4.6/4.7 Regression] |used to shift value of 128 |Incorrect instruction is |bit xmm0 registrer |used to shift value of 128 ||bit xmm0 registrer Ever Confirmed|0 |1 --- Comment #6 from Uros Bizjak ubizjak at gmail dot com 2011-09-15 14:29:42 UTC --- SLP pass fails to notice one-bit assignment.
[Bug c++/50361] [C++0x] [4.7 Regression] ICE with std::initializer_list and nullptr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50361 --- Comment #6 from Jason Merrill jason at gcc dot gnu.org 2011-09-15 14:33:29 UTC --- Author: jason Date: Thu Sep 15 14:33:24 2011 New Revision: 178882 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178882 Log: PR c++/50361 * expr.c (count_type_elements): Handle NULLPTR_TYPE. Added: trunk/gcc/testsuite/g++.dg/cpp0x/nullptr23.C Modified: trunk/gcc/ChangeLog trunk/gcc/expr.c trunk/gcc/testsuite/ChangeLog
[Bug c++/50365] [4.7 Regression] non-static data member error on valid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50365 --- Comment #8 from Jason Merrill jason at gcc dot gnu.org 2011-09-15 14:33:42 UTC --- Author: jason Date: Thu Sep 15 14:33:37 2011 New Revision: 178883 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178883 Log: PR c++/50365 * parser.c (cp_parser_late_return_type_opt): Check quals parameter for clearing current_class_ptr, too. Added: trunk/gcc/testsuite/g++.dg/cpp0x/trailing7.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog
[Bug c++/50365] [4.7 Regression] non-static data member error on valid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50365 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #9 from Jason Merrill jason at gcc dot gnu.org 2011-09-15 14:34:06 UTC --- Fixed.
[Bug c++/50361] [C++0x] [4.7 Regression] ICE with std::initializer_list and nullptr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50361 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #7 from Jason Merrill jason at gcc dot gnu.org 2011-09-15 14:34:21 UTC --- Fixed.
[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394 --- Comment #3 from Jan Hubicka hubicka at gcc dot gnu.org 2011-09-15 15:39:18 UTC --- Thanks a lot! is there any chance to get those fixes into official git so we don't need to cummulate local patches? :)
[Bug fortran/50404] SIGSEGV in gfc_resolve_close
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50404
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- Comment #1 from kargl at gcc dot gnu.org 2011-09-15 15:47:33 UTC ---
Program received signal SIGSEGV, Segmentation fault.
0x004d17e9 in gfc_resolve_close (close=0x202007220)
at ../../gcc4x/gcc/fortran/io.c:2298
2298 if (close-unit-expr_type == EXPR_CONSTANT
(gdb) bt
#0 0x004d17e9 in gfc_resolve_close (close=0x202007220)
at ../../gcc4x/gcc/fortran/io.c:2298
#1 0x00501bbf in resolve_code (code=0x2020a6300, ns=0x2021bb200)
at ../../gcc4x/gcc/fortran/resolve.c:9382
#2 0x005028f9 in resolve_codes (ns=0x2021bb200)
at ../../gcc4x/gcc/fortran/resolve.c:13665
#3 0x00502a24 in gfc_resolve (ns=0x2021bb200)
at ../../gcc4x/gcc/fortran/resolve.c:13692
#4 0x004f5d04 in resolve_all_program_units ()
at ../../gcc4x/gcc/fortran/parse.c:4336
#5 gfc_parse_file () at ../../gcc4x/gcc/fortran/parse.c:4602
#6 0x0052cdce in gfc_be_parse_file ()
at ../../gcc4x/gcc/fortran/f95-lang.c:250
#7 0x008c806b in compile_file () at ../../gcc4x/gcc/toplev.c:548
#8 do_compile () at ../../gcc4x/gcc/toplev.c:1886
#9 0x008c8c95 in toplev_main (argc=2, argv=0x7fffd508)
at ../../gcc4x/gcc/toplev.c:1962
#10 0x004900dc in _start ()
(gdb) print close
$1 = (gfc_close *) 0x202007220
(gdb) print *close
$2 = {unit = 0x0, status = 0x0, iostat = 0x2020a6180, iomsg = 0x0, err = 0x0}
From f2003
C907 (R909) A file-unit-number shall be specified; if the optional
characters UNIT= are omitted, the file-unit-number shall be the
first item in the close-spec-list.
troutmask:sgk[256] gfc4x -c a.f
a.f:5.72:
close(iostat=i)
1
Error: CLOSE statement at (1) requires a UNIT number
Index: io.c
===
--- io.c(revision 178782)
+++ io.c(working copy)
@@ -2295,6 +2295,12 @@ gfc_resolve_close (gfc_close *close)
if (gfc_reference_st_label (close-err, ST_LABEL_TARGET) == FAILURE)
return FAILURE;
+ if (close-unit == NULL)
+{
+ gfc_error (CLOSE statement at %C requires a UNIT number);
+ return FAILURE;
+}
+
if (close-unit-expr_type == EXPR_CONSTANT
close-unit-ts.type == BT_INTEGER
mpz_sgn (close-unit-value.integer) 0)
[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394 --- Comment #4 from Markus Trippelsdorf markus at trippelsdorf dot de 2011-09-15 16:48:37 UTC --- (In reply to comment #3) Thanks a lot! is there any chance to get those fixes into official git so we don't need to cummulate local patches? :) It looks like some libreoffice developers are monitoring this meta-bug. Issue 2) is already fixed: http://cgit.freedesktop.org/libreoffice/core/commit/?id=87891c1c8bb82904fd68c523cb1aa11ddcfaaa3d
[Bug target/50182] Performance degradation from gcc 4.1 (x86_64)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50182 --- Comment #13 from oleg at smolsky dot net 2011-09-15 16:53:26 UTC --- David, it looks like we are seeing different things with v4.7... See my comment 11 - I am still observing the slowdown. Do you have access to v4.1 and v4.6? Could you try reproducing my test please?
[Bug fortran/50407] compiler confused by .operator.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50407 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org 2011-09-15 16:55:12 UTC --- I believe the code is invalid due to the recursive IO. Don't have time now to verify this. gfortran is looking for a comma because it sees 2 in 2.ip.8 as a statement label. I think gfortran may be correct in its behavior.
[Bug c++/2316] g++ fails to overload on language linkage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316 --- Comment #34 from Marc Glisse marc.glisse at normalesup dot org 2011-09-15 16:53:33 UTC --- I posted a related demangler patch on gcc-patches a couple weeks ago, let me just link it from here so it doesn't get lost: http://gcc.gnu.org/ml/gcc-patches/2011-09/msg00231.html
[Bug fortran/50420] New: [Coarray] lcobound doesn't accept coarray subcomponents
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50420 Bug #: 50420 Summary: [Coarray] lcobound doesn't accept coarray subcomponents Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: mik...@gcc.gnu.org This code is modified from coarray/alloc_comp_1.f90: type t integer :: i end type t type(t), allocatable :: a[:] allocate(a[3:*]) a%i = 7 if (a%i /= 7) call abort print *, lcobound(a%i) end With (patched) trunk, I get: f951: internal compiler error: in simplify_cobound, at fortran/simplify.c:3552
[Bug libgcj/50421] New: [4.7 Regression] GC Warning: Out of Memory! Returning NIL!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50421 Bug #: 50421 Summary: [4.7 Regression] GC Warning: Out of Memory! Returning NIL! Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassig...@gcc.gnu.org ReportedBy: dang...@gcc.gnu.org Host: hppa2.0w-hp-hpux11.11 Target: hppa2.0w-hp-hpux11.11 Build: hppa2.0w-hp-hpux11.11 Executing on host: /test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libjava/testsuite/ ../libtool --silent --tag=GCJ --mode=link /test/gnu/gcc/objdir/./gcc/gcj -B/test /gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libjava/ -B/test/gnu/gcc/objdir/./gcc/ -B/ opt/gnu/gcc/gcc-4.7/hppa2.0w-hp-hpux11.11/bin/ -B/opt/gnu/gcc/gcc-4.7/hppa2.0w-h p-hpux11.11/lib/ -isystem /opt/gnu/gcc/gcc-4.7/hppa2.0w-hp-hpux11.11/include -is ystem /opt/gnu/gcc/gcc-4.7/hppa2.0w-hp-hpux11.11/sys-include --encoding=UTF-8 -B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libjava/testsuite/../ /test/gnu/gc c/gcc/libjava/testsuite/libjava.lang/FileHandleGcTest.jar -w -no-install --mai n=FileHandleGcTest -O3 -g -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libjav a/.libs -lm -o /test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libjava/testsuite/Fi leHandleGcTest.exe(timeout = 300) PASS: FileHandleGcTest -O3 compilation from source set_ld_library_path_env_vars: ld_library_path=.:/test/gnu/gcc/objdir/hppa2.0w-hp -hpux11.11/./libjava/.libs invoke: /test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libjava/testsuite/FileHandleG cTest.exe Setting LD_LIBRARY_PATH to .:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libjav a/.libs:.:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libjava/.libs PASS: FileHandleGcTest -O3 execution - source compiled test PASS: FileHandleGcTest -O3 output - source compiled test set_ld_library_path_env_vars: ld_library_path=.:/test/gnu/gcc/objdir/hppa2.0w-hp -hpux11.11/./libjava/.libs Executing on host: /test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libjava/testsuite/ ../libtool --silent --tag=GCJ --mode=link /test/gnu/gcc/objdir/./gcc/gcj -B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libjava/ -B/test/gnu/gcc/objdir/./gcc/ -B/opt/gnu/gcc/gcc-4.7/hppa2.0w-hp-hpux11.11/bin/ -B/opt/gnu/gcc/gcc-4.7/hppa2.0w-hp-hpux11.11/lib/ -isystem /opt/gnu/gcc/gcc-4.7/hppa2.0w-hp-hpux11.11/include -isystem /opt/gnu/gcc/gcc-4.7/hppa2.0w-hp-hpux11.11/sys-include--encoding=UTF-8 -B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libjava/testsuite/../ /test/gnu/gcc/gcc/libjava/testsuite/libjava.lang/FileHandleGcTest.jar -w -no-install --main=FileHandleGcTest -O3 -findirect-dispatch -g -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libjava/.libs -lm -o /test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libjava/testsuite/FileHandleGcTest.exe (timeout = 300) PASS: FileHandleGcTest -O3 -findirect-dispatch compilation from source set_ld_library_path_env_vars: ld_library_path=.:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libjava/.libs invoke: /test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libjava/testsuite/FileHandleGcTest.exe Setting LD_LIBRARY_PATH to .:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libjava/.libs:.:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libjava/.libs GC Warning: Out of Memory! Returning NIL! GC Warning: Out of Memory! Returning NIL! WARNING: program timed out. FAIL: FileHandleGcTest -O3 -findirect-dispatch execution - source compiled test UNTESTED: FileHandleGcTest -O3 -findirect-dispatch output - source compiled test Similar fails: FAIL: PR19870_2 -O3 -findirect-dispatch execution - source compiled test FAIL: PR19921 -O3 -findirect-dispatch execution - source compiled test FAIL: PR29013 -O3 -findirect-dispatch execution - source compiled test FAIL: PR31264 -O3 -findirect-dispatch execution - source compiled test FAIL: PR7482 -O3 -findirect-dispatch execution - source compiled test FAIL: bclink -O3 execution - source compiled test FAIL: bclink -O3 -findirect-dispatch execution - source compiled test FAIL: initexc -O3 -findirect-dispatch execution - source compiled test FAIL: pr13107_2 -O3 -findirect-dispatch output - source compiled test FAIL: verify -O3 -findirect-dispatch execution - source compiled test
[Bug target/50182] Performance degradation from gcc 4.1 (x86_64)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50182 --- Comment #14 from davidxl xinliangli at gmail dot com 2011-09-15 17:28:10 UTC --- (In reply to comment #13) David, it looks like we are seeing different things with v4.7... See my comment 11 - I am still observing the slowdown. Do you have access to v4.1 and v4.6? Could you try reproducing my test please? Sorry for the delay -- I am pretty swamped these days (till mid October). I will try to look at the problem more then. David
[Bug c/50422] New: -Wswitch warns about unhandled cases in nested switches
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50422
Bug #: 50422
Summary: -Wswitch warns about unhandled cases in nested
switches
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: de...@fresse.org
Linux plutos 2.6.37.6-0.7-desktop #1 SMP PREEMPT 2011-07-21 02:17:24 +0200
x86_64 x86_64 x86_64 GNU/Linux
freundt@clyde:pts/10:~ gcc --version
gcc (GCC) 4.7.0 20110811 (experimental)
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Recipe to reproduce:
freundt@clyde:pts/10:~ gcc -x c -c -Wall -o /dev/null - EOF
typedef enum {
NAUGHT,
ONE,
TWO,
} foo_t;
int
test(foo_t arg)
{
switch (arg) {
case NAUGHT:
case ONE:
switch (arg) {
case NAUGHT:
return 0;
case ONE:
return 1;
}
break;
case TWO:
return 2;
}
return -1;
}
EOF
stdin: In function 'test':
stdin:13:3: warning: enumeration value 'TWO' not handled in switch [-Wswitch]
This is _similar_ to bug 23577 but not quite as nested switches should be
easier to handle than separate fragments.
[Bug fortran/50401] SIGSEGV in resolve_transfer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50401 --- Comment #2 from janus at gcc dot gnu.org 2011-09-15 17:48:36 UTC --- Author: janus Date: Thu Sep 15 17:48:27 2011 New Revision: 178889 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178889 Log: 2011-09-15 Janus Weil ja...@gcc.gnu.org PR fortran/50401 * resolve.c (resolve_transfer): Check if component 'ref' is defined. PR fortran/50403 * symbol.c (gfc_use_derived): Check if argument 'sym' is defined. 2011-09-15 Janus Weil ja...@gcc.gnu.org PR fortran/50401 PR fortran/50403 * gfortran.dg/function_types_3.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/function_types_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/50403] SIGSEGV in gfc_use_derived
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50403 --- Comment #2 from janus at gcc dot gnu.org 2011-09-15 17:48:36 UTC --- Author: janus Date: Thu Sep 15 17:48:27 2011 New Revision: 178889 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178889 Log: 2011-09-15 Janus Weil ja...@gcc.gnu.org PR fortran/50401 * resolve.c (resolve_transfer): Check if component 'ref' is defined. PR fortran/50403 * symbol.c (gfc_use_derived): Check if argument 'sym' is defined. 2011-09-15 Janus Weil ja...@gcc.gnu.org PR fortran/50401 PR fortran/50403 * gfortran.dg/function_types_3.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/function_types_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/50401] SIGSEGV in resolve_transfer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50401 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from janus at gcc dot gnu.org 2011-09-15 17:50:04 UTC --- Fixed on trunk with r178889. Closing.
[Bug fortran/50403] SIGSEGV in gfc_use_derived
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50403 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from janus at gcc dot gnu.org 2011-09-15 17:50:25 UTC --- Fixed on trunk with r178889. Closing.
[Bug c++/50423] New: error: ‘getpid’ was not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50423 Bug #: 50423 Summary: error: ‘getpid’ was not declared in this scope Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: howa...@nitro.med.uc.edu Created attachment 25294 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25294 bzip2 compressed preprocessed source for common/semaphore.cc Current gcc trunk produces a compile time error for common/semaphore.cc in xplor-nih 2.27... g++-fsf-4.7 -c semaphore.cc -O3 -ffast-math -funroll-loops -g -fpermissive -DX_MMAP_FLAGS=0 -DFORTRAN_INIT -fno-common -DDARWIN -D_REENTRANT -DNDEBUG -I/Users/howarth/xplor-nih-2.27/common/ -I/Users/howarth/xplor-nih-2.27/arch/Darwin_11_x86_64/include -I/Users/howarth/xplor-nih-2.27/CDSlib -I/Users/howarth/xplor-nih-2.27/intVar -I/Users/howarth/xplor-nih-2.27/pcre -DCPLUSPLUS -DUSE_CDS_NAMESPACE -I/Users/howarth/xplor-nih-2.27/common/ -I/Users/howarth/xplor-nih-2.27/arch/Darwin_11_x86_64/include semaphore.cc: In constructor ‘CDS::Semaphore::Semaphore(bool)’: semaphore.cc:111:30: error: ‘getpid’ was not declared in this scope semaphore.cc: In destructor ‘CDS::Semaphore::~Semaphore()’: semaphore.cc:124:36: error: ‘getpid’ was not declared in this scope semaphore.cc:126:9: warning: deleting ‘void*’ is undefined [enabled by default] which doesn't occur with gcc-4_6-branch... [MacPro:~/xplor-nih-2.27/common/bin.Darwin_11_x86_64] howarth% g++-fsf-4.6 -c semaphore.cc -O3 -ffast-math -funroll-loops -g -fpermissive -DX_MMAP_FLAGS=0 -DFORTRAN_INIT -fno-common -DDARWIN -D_REENTRANT -DNDEBUG -I/Users/howarth/xplor-nih-2.27/common/ -I/Users/howarth/xplor-nih-2.27/arch/Darwin_11_x86_64/include -I/Users/howarth/xplor-nih-2.27/CDSlib -I/Users/howarth/xplor-nih-2.27/intVar -I/Users/howarth/xplor-nih-2.27/pcre -DCPLUSPLUS -DUSE_CDS_NAMESPACE -I/Users/howarth/xplor-nih-2.27/common/ -I/Users/howarth/xplor-nih-2.27/arch/Darwin_11_x86_64/include semaphore.cc: In destructor ‘CDS::Semaphore::~Semaphore()’: semaphore.cc:126:9: warning: deleting ‘void*’ is undefined [enabled by default]
[Bug c++/50423] error: ‘getpid’ was not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50423 --- Comment #1 from Jack Howarth howarth at nitro dot med.uc.edu 2011-09-15 17:57:08 UTC --- Attached bzip2 compressed preprocessed source for common/semaphore.cc reproduces this issue... [MacPro:~/xplor-nih-2.27/common/bin.Darwin_11_x86_64] howarth% g++-fsf-4.7 -c semaphore.ii -O3 -ffast-math -funroll-loops -g -fpermissive -DX_MMAP_FLAGS=0 -DFORTRAN_INIT -fno-common -DDARWIN -D_REENTRANT -DNDEBUGsemaphore.cc: In constructor ‘CDS::Semaphore::Semaphore(bool)’:semaphore.cc:111:30: error: ‘getpid’ was not declared in this scope semaphore.cc: In destructor ‘CDS::Semaphore::~Semaphore()’: semaphore.cc:124:36: error: ‘getpid’ was not declared in this scope semaphore.cc:126:9: warning: deleting ‘void*’ is undefined [enabled by default]
[Bug c++/50423] error: ‘getpid’ was not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50423 --- Comment #2 from Jack Howarth howarth at nitro dot med.uc.edu 2011-09-15 17:57:45 UTC --- Note that -fpermissive doesn't eliminate the regression.
[Bug c++/50424] New: G++ doesn't notice possible throw from default argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50424
Bug #: 50424
Summary: G++ doesn't notice possible throw from default
argument
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
This testcase ends up calling terminate because G++ doesn't notice that h() can
throw because of the f() default argument used in the call to g().
int f() { throw 1; }
void g( int = f() ) { }
void h() { g(); }
int main()
{
try { h(); } catch (int) { }
}
This issue also affects the implementation of C++11 non-static data member
initializers that I'm working on.
[Bug c++/50423] error: ‘getpid’ was not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50423 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org 2011-09-15 18:01:34 UTC --- This is expected you are not including unistd.h in your source which is required if you want to use getpid. It was a bug before GCC 4.7 that some of the C++ headers included that header file.
[Bug fortran/50409] SIGSEGV in gfc_simplify_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50409 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #2 from kargl at gcc dot gnu.org 2011-09-15 18:05:11 UTC --- I suspect that this chunk of code in gfc_simplify_expr stating at line 1859 needs to special case zero-sized strings: s = gfc_get_wide_string (end - start + 2); memcpy (s, p-value.character.string + start, (end - start) * sizeof (gfc_char_t)); s[end - start + 1] = '\0'; /* TODO: C-style string. */ free (p-value.character.string); p-value.character.string = s; p-value.character.length = end - start; p-ts.u.cl = gfc_new_charlen (gfc_current_ns, NULL); p-ts.u.cl-length = gfc_get_int_expr (gfc_default_integer_kind, NULL, p-value.character.length);
[Bug c/50425] New: precedence rule for pre/post increamet/decreament and effect of white spaces
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50425 Bug #: 50425 Summary: precedence rule for pre/post increamet/decreament and effect of white spaces Classification: Unclassified Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: grj...@gmail.com Hi, I was trying to understand precedence of pre/post increment/decrement operators. But it seems to be very confusing. According to precedence rule pre increment has higher precedence than addition(+) and lower precedence than post lineament. But when I use any expression like j= i + ++i + i + ++i; according to precedence rule pre icrements will be performed first and then remaining statement. suppose value of i=2, according to precedence rule pre increments will be performed first and then addition. So after two pre increments value of i becomes four and this value should be used in evaluation of complete statement and it should be 16 but it is not. What is correct rule of precedence in this case ?? Similarly in C, generally white spaces does not make any sense but in following case they are they are behaving differently.consider following statements: j = i +++ i; j= i++ + i; j=i + ++i; j=i + + + i; Please let me know, how are white space treated in this case? please follow a consistent rule. Also clarify precedence rule of these operators.
[Bug c/50425] precedence rule for pre/post increamet/decreament and effect of white spaces
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50425 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2011-09-15 18:21:31 UTC --- This is not a good place to learn C/C++ really. But anyways the order of evulating of the operands of + is not specified and could happen in either order as there is no sequence point. Read http://c-faq.com/expr/seqpoints.html .
[Bug target/50341] calls via function pointer wrongly scheduled giving invalid TOC pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50341
Michael Meissner meissner at gcc dot gnu.org changed:
What|Removed |Added
CC||meissner at gcc dot gnu.org
--- Comment #3 from Michael Meissner meissner at gcc dot gnu.org 2011-09-15
18:32:45 UTC ---
From the example in the bug, it is the 3rd cpu_fprintf, where it decides to
move loading up an address into register 27, and move the load of the address
before the call, since register 27 is preserved across calls.
void cpu_dump_state (struct CPUPPCState *env, FILE *f, fprintf_function
cpu_fprintf,
int flags)
{
int i;
cpu_fprintf(f, NIP %016 l xLR %016 l x CTR
%016 l x XER %016 l x \n,
env-nip, env-lr, env-ctr, env-xer);
cpu_fprintf(f, MSR %016 l x HID0 %016 l x HF
%016 l x idx %d\n, env-msr, env-spr[(0x3F0)],
env-hflags, env-mmu_idx);
cpu_fprintf(f, TB %08 u %08 l u
DECR %08 u
\n,
cpu_ppc_load_tbu(env), cpu_ppc_load_tbl(env)
, cpu_ppc_load_decr(env)
);
These are the insns that are moved before the call:
(insn 1105 153 203 2 (set (reg/f:DI 27 27 [603])
(const:DI (plus:DI (reg:DI 2 2)
(high:DI (const:DI (unspec:DI [
(symbol_ref/f:DI (*.LC5) [flags 0x82]
var_decl 0xfff931e6360 *.LC5)
] UNSPEC_TOCREL)) 513 {largetoc_high}
(expr_list:REG_EQUIV (const:DI (plus:DI (reg:DI 2 2)
(high:DI (const:DI (unspec:DI [
(symbol_ref/f:DI (*.LC5) [flags 0x82]
var_decl 0xfff931e6360 *.LC5)
] UNSPEC_TOCREL)
(nil)))
(insn 1107 161 204 2 (set (reg/f:DI 27 27 [601])
(lo_sum:DI (reg/f:DI 27 27 [603])
(const:DI (unspec:DI [
(symbol_ref/f:DI (*.LC5) [flags 0x82] var_decl
0xfff931e6360 *.LC5)
] UNSPEC_TOCREL 514 {largetoc_low}
(expr_list:REG_EQUIV (symbol_ref/f:DI (*.LC5) [flags 0x82] var_decl
0xfff931e6360 *.LC5)
(nil)))
The RTL logic is not looking into the const.
This is triggered by Alan's patch in June:
2011-06-20 Alan Modra amo...@gmail.com
* config/rs6000/rs6000.c (create_TOC_reference): Wrap high part
of toc-relative address in CONST.
(rs6000_delegitimize_address): Recognize changed address.
(rs6000_legitimize_reload_address): Likewise.
(rs6000_emit_move): Don't force these constants to memory.
* config/rs6000/rs6000.md (tls_gd, tls_gd_high): Wrap high part of
toc-relative address in CONST.
(tls_ld, tls_ld_high, tls_got_dtprel, tls_got_dtprel_high): Likewise.
(tls_got_tprel, tls_got_tprel_high, largetoc_high): Likewise.
Now, I anticipate that the patch in 4.7 will be temporary until we are
confident that we have the right solution, but it is better to put a bandaid on
the patch to limit the damage.
[Bug target/50341] calls via function pointer wrongly scheduled giving invalid TOC pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50341 --- Comment #4 from Michael Meissner meissner at gcc dot gnu.org 2011-09-15 18:34:11 UTC --- Created attachment 25295 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25295 Patch for GCC 4.6 that disables the split of the load of the new TOC
[Bug target/50341] calls via function pointer wrongly scheduled giving invalid TOC pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50341 --- Comment #5 from Michael Meissner meissner at gcc dot gnu.org 2011-09-15 18:34:44 UTC --- Created attachment 25296 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25296 Patch for GCC 4.7 that disables the split of the load of the new TOC
[Bug plugins/45348] cp/cp-tree.h in plugin header does not work.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45348
--- Comment #2 from eraman at gcc dot gnu.org 2011-09-15 19:18:30 UTC ---
Author: eraman
Date: Thu Sep 15 19:18:26 2011
New Revision: 178892
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178892
Log:
Backport r176741 from trunk.
2011-09-15 Easwaran Raman era...@google.com
Backport r176741 from trunk.
2011-07-22 Romain Geissler romain.geiss...@gmail.com
PR plugins/45348
PR plugins/48425
PR plugins/46577
* Makefile.in: Do not flatten c-family directory when installing
plugin headers.
gcc/c-family/ChangeLog.google-4_6:
2011-09-15 Easwaran Raman era...@google.com
Backport r176741 from trunk.
2011-07-25 Romain Geissler romain.geiss...@gmail.com
* c-pretty-print.h: Search c-common.h in c-family.
Added:
branches/google/gcc-4_6/gcc/c-family/ChangeLog.google-4_6
Modified:
branches/google/gcc-4_6/ (props changed)
branches/google/gcc-4_6/gcc/ChangeLog.google-4_6
branches/google/gcc-4_6/gcc/Makefile.in
branches/google/gcc-4_6/gcc/c-family/c-pretty-print.h
Propchange: branches/google/gcc-4_6/
('svn:mergeinfo' modified)
