[Bug fortran/46846] Warning of AINT as actual argument ain't right
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46846 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2010-12-09 08:05:31 UTC --- Another post by James about REAL: http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/991e2a17662a3bde
[Bug fortran/45081] [4.3/4.4 Regression] ICE in gfc_conv_array_initializer, at fortran/trans-array.c:4208
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45081 --- Comment #16 from Tobias Burnus burnus at gcc dot gnu.org 2010-12-09 08:09:59 UTC --- Author: burnus Date: Thu Dec 9 08:09:52 2010 New Revision: 167627 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=167627 Log: 2010-12-09 Paul Thomas pa...@gcc.gnu.org PR fortran/45081 * simplify.c (is_constant_array_expr): Allow structure array elements as well as constants. (gfc_simplify_reshape): Copy the derived type of source to the result. 2010-12-09 Paul Thomas pa...@gcc.gnu.org PR fortran/45081 * gfortran.dg/derived_array_intrinsics_1.f90 : New test. Added: branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/derived_array_intrinisics_1.f90 Modified: branches/gcc-4_4-branch/gcc/fortran/ChangeLog branches/gcc-4_4-branch/gcc/fortran/simplify.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
[Bug fortran/45081] [4.3 Regression] ICE in gfc_conv_array_initializer, at fortran/trans-array.c:4208
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45081 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.5.2 |4.3.6 Summary|[4.3/4.4 Regression] ICE in |[4.3 Regression] ICE in |gfc_conv_array_initializer, |gfc_conv_array_initializer, |at |at |fortran/trans-array.c:4208 |fortran/trans-array.c:4208 --- Comment #17 from Tobias Burnus burnus at gcc dot gnu.org 2010-12-09 08:11:58 UTC --- Regarding the backport to 4.4: It only handles RESHAPE; as the simplification for SPREAD, TRANSPOSE and (UN)PACK is not implemented in 4.4. TODO: Backport to 4.3.
[Bug target/41082] [4.5/4.6 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082 --- Comment #70 from Jakub Jelinek jakub at gcc dot gnu.org 2010-12-09 08:33:49 UTC --- Author: jakub Date: Thu Dec 9 08:33:45 2010 New Revision: 167629 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=167629 Log: PR target/41082 * config/rs6000/rs6000.c (rs6000_expand_vector_extract): Use stvx instead of stve*x. (altivec_expand_stv_builtin): For op0 use mode of operand 1 instead of operand 0. * config/rs6000/altivec.md (VI_scalar): New mode attr. (altivec_stveVI_charx, *altivec_stvesfx): Use scalar instead of vector mode for operand 0, put operand 1 into UNSPEC. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/altivec.md trunk/gcc/config/rs6000/rs6000.c
[Bug target/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2010.12.09 08:35:33 AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | Summary|[4.5/4.6 Regression] FAIL: |[4.5 Regression] FAIL: |gfortran.fortran-torture/ex |gfortran.fortran-torture/ex |ecute/where_2.f90 |ecute/where_2.f90 |execution, -O3 |execution, -O3 Ever Confirmed|0 |1 --- Comment #71 from Jakub Jelinek jakub at gcc dot gnu.org 2010-12-09 08:35:33 UTC --- Fixed on the trunk, 4.5 backport waiting until it is unfrozen after 4.5.2 release.
[Bug c/46853] gcc fails to warn about uninitialized variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46853 --- Comment #2 from gcc-bugs at nospam dot pz.podzone.net 2010-12-09 08:36:46 UTC --- The variable can be optimised away in the WHILE_LOOP test case so in effect the variable 'foo' is never used uninitialised. However with the FOR_LOOP test case it is not possible to optimise away the variable 'foo' and it is unclear what value the function will eventually return. In theory the for loop and the variable 'i' could be optimised away, but I doubt gcc actually does this. However imagine that gcc did so then the FOR_LOOP test case should generate the same warning as the basic test case, but it does not. Is it unreasonable to expect gcc to warn about uninitialised use of the variable in such cases where it is not optimised away?
[Bug rtl-optimization/46854] PowerPC optimization regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46854
--- Comment #1 from joakim.tjernlund at transmode dot se joakim.tjernlund at
transmode dot se 2010-12-09 09:10:50 UTC ---
Somewhat related observation:
It would be nice if gcc could optimize
static inline const char *test(int i)
{
const char *p = abc\0def\0gef;
for(; i; --i)
while(*++p);
return p;
}
const char * myfun(void)
{
return test(2);
}
into
const char * myfun(void)
{
return gef;
}
[Bug target/46861] alpha gcc 4.2 -fPIC visibility hidden = gp-relative relocation against dynamic symbol
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46861 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2010.12.09 10:12:22 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2010-12-09 10:12:22 UTC --- GCC 4.2.x is no longer maintained, please try newer GCC version(s).
[Bug fortran/46753] [4.4 Regression] ICE: OpenMP - in extract_omp_for_data, at omp-low.c:335
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46753 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org 2010-12-09 10:28:42 UTC --- Regressed in 4.4, 4.5 and 4.6 (trunk) - and a fix was committed for all those version. Thus: Close as FIXED. Thanks Bill for the report - and thanks Jakub for tracing the error and fixing it.
[Bug fortran/46753] [4.4 Regression] ICE: OpenMP - in extract_omp_for_data, at omp-low.c:335
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46753 --- Comment #7 from Bill Long longb at cray dot com 2010-12-09 10:29:19 UTC --- I am out of the office until Tuesday, December 21, 2010. Send technical questions to spsl...@cray.com.
[Bug c++/46701] [C++0x] ICE in build_data_member_initialization, at cp/semantics.c:5503
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46701 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #9 from Paolo Carlini paolo.carlini at oracle dot com 2010-12-09 10:31:57 UTC --- The patch for c++/46384 fixed this one too. *** This bug has been marked as a duplicate of bug 46384 ***
[Bug target/46384] ia64-linux: internal compiler error: in get_attr_first_insn, at config/ia64/itanium2.md:1909
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46384 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||miles at gnu dot org --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2010-12-09 10:31:57 UTC --- *** Bug 46701 has been marked as a duplicate of this bug. ***
[Bug c++/46701] [C++0x] ICE in build_data_member_initialization, at cp/semantics.c:5503
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46701 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||paolo.carlini at oracle dot ||com --- Comment #10 from Paolo Carlini paolo.carlini at oracle dot com 2010-12-09 10:32:53 UTC --- Sorry. *** This bug has been marked as a duplicate of bug 46348 ***
[Bug c++/46348] [C++0x] ICE with constexpr default constructor and array member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46348 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||miles at gnu dot org --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com 2010-12-09 10:32:53 UTC --- *** Bug 46701 has been marked as a duplicate of this bug. ***
[Bug debug/46102] ICE: SIGSEGV in dwarf2out_finish (dwarf2out.c:8490) with -feliminate-dwarf2-dups when using precompiled headers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46102 --- Comment #1 from Zdenek Sojka zsojka at seznam dot cz 2010-12-09 10:40:19 UTC --- GDB gives maybe better backtrace: Program received signal SIGSEGV, Segmentation fault. break_out_includes (filename=value optimized out) at /usr/portage/distfiles/svn-src/gcc/trunk/gcc/dwarf2out.c:9818 9818 unit = pop_compile_unit (unit); (gdb) bt #0 break_out_includes (filename=value optimized out) at /usr/portage/distfiles/svn-src/gcc/trunk/gcc/dwarf2out.c:9818 #1 dwarf2out_finish (filename=value optimized out) at /usr/portage/distfiles/svn-src/gcc/trunk/gcc/dwarf2out.c:23110 #2 0x00a21566 in compile_file (argc=15, argv=0x7fffdaa8) at /usr/portage/distfiles/svn-src/gcc/trunk/gcc/toplev.c:621 #3 do_compile (argc=15, argv=0x7fffdaa8) at /usr/portage/distfiles/svn-src/gcc/trunk/gcc/toplev.c:1874 #4 toplev_main (argc=15, argv=0x7fffdaa8) at /usr/portage/distfiles/svn-src/gcc/trunk/gcc/toplev.c:1937 #5 0x76586bbd in __libc_start_main () from /lib/libc.so.6 #6 0x004fdc6d in _start () I don't know if this belongs to debug or pch.
[Bug c++/46862] New: ICE on std::decimal::decimal32 without any fields
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46862
Summary: ICE on std::decimal::decimal32 without any fields
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
int foo ();
static __typeof (foo) bar __attribute__ ((__weakref__ (foo)));
namespace std
{
namespace decimal
{
class decimal32;
template class struct S { };
template struct S decimal32 { static const bool value = true; };
template class class T { };
class decimal32 : public T decimal32 { };
}
}
ICEs during mangling, as first_field returns NULL.
[Bug target/46861] alpha gcc 4.2 -fPIC visibility hidden = gp-relative relocation against dynamic symbol
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46861 --- Comment #2 from Jay jay.krell at cornell dot edu 2010-12-09 11:21:35 UTC --- Right, I already reported: no problem with 4.5.1. 4.2.4 is what Debian 5.0 has though. I'll stick with my workaround. I can try 4.3.x, 4.4.x if there is interest (i.e. in fixing them if they are broken; heck for that matter I should probably try stock 4.2.x, instead of Debian's)
[Bug fortran/46842] [4.6 Regression] 465.tonto test run miscompares (even with -O0)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46842
--- Comment #11 from Tobias Burnus burnus at gcc dot gnu.org 2010-12-09
11:22:14 UTC ---
I fear that debugging this will be not easy - especially as to my knowledge
none of the gfortran developers has access to SPEC CPU 2006.
* * *
I tried
http://sourceforge.net/projects/tonto-chem/files/tonto/2.3/tonto-2.3.1.tar.bz2/download
If I compile it with a version before the regression, namely
4.6.0 20100909 (experimental) [trunk revision 164046]
I get only failures with make tests - I have to recompile with
-fno-sign-zero to reduce the failures. However, I still get failures (=
differences) to the result of the Intel compiler.
I think one could still try to find differences between such a version and a
version after the TRANSPOSE committal.
Compiling notice: You need to remove the -std=f95 and - to speed up the very
slow compile a tiny bit - remove also -Wall -O. Additionally, as mentioned
above, consider using -fno-sign-zero. (In my case, the configuration is in
platforms/GNU-gfortran-on-LINUX.) Unfortunately, almost all changes trigger a
complete recompilation - and make -j5 does not work.
* * *
I could find TRANSPOSEs in the files mo_localiser.F90, molecule.F90,
vec{atom}.F90, marchingcube.F90, isosurface.F90, mat{cpx}.F90, mat3{real}.F90,
spacegroup.F90, periodic_fmm_level.F90, cluster.F90, mat{real}.F90,
run_mat{real}.F90, molecule.main.F90, unit_cell.F90 and crystal.F90. I tried to
create some failing test myself, but they were handled properly.
[Bug c++/46862] ICE on std::decimal::decimal32 without any fields
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46862 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2010-12-09 11:25:08 UTC --- Not sure if we should error out if a TYPE_TRANSPARENT_AGGR doesn't in the end have any fields, or simply mangle them normally if first_field returns NULL, but we shouldn't ICE on it.
[Bug c++/42083] [C++0x] ICE on invalid with tree check: expected aggr_init_expr, have error_mark in build_value_init
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42083 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2010.12.09 11:26:59 AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com Target Milestone|--- |4.6.0 Ever Confirmed|0 |1 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2010-12-09 11:26:59 UTC --- Seems simple.
[Bug target/46861] alpha gcc 4.2 -fPIC visibility hidden = gp-relative relocation against dynamic symbol
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46861 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2010-12-09 11:43:07 UTC --- (In reply to comment #2) Right, I already reported: no problem with 4.5.1. 4.2.4 is what Debian 5.0 has though. Then it should be reported to Debian if they're still maintaining their 4.2 I'll stick with my workaround. I can try 4.3.x, 4.4.x if there is interest (i.e. in fixing them if they are broken; heck for that matter I should probably try stock 4.2.x, instead of Debian's) If they're broken then there'll be interest, there's just no interest in fixing *anything* in 4.2
[Bug tree-optimization/46863] New: [4.6 Regression] Bogus memmove folding (?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46863
Summary: [4.6 Regression] Bogus memmove folding (?)
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: alias, wrong-code
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org
With -D_FORTIFY_SOURCE=2 memmove is folded to memcpy because of the restrict
qualified arguments of the memmove wrapper.
Miscompiled at -O1:
typedef __SIZE_TYPE__ size_t;
extern void *memmove (void *__dest, __const void *__src, size_t __n)
__attribute__ ((__nothrow__)) __attribute__ ((__nonnull__ (1, 2)));
extern __inline __attribute__ ((__always_inline__)) __attribute__
((__artificial__)) void *
__attribute__ ((__nothrow__)) memmove (void *__restrict __dest, __const void
*__restrict __src, size_t __len)
{
return __builtin___memmove_chk (__dest, __src, __len, __builtin_object_size
(__dest, 0));
}
extern void abort (void);
void __attribute__((noinline,noclone))
foo(void *p, void *q)
{
memmove (p, q, 13);
}
int main()
{
char a[32] = Hello World!;
foo (a[1], a);
if (strcmp (a, HHello World!) != 0)
abort ();
foo (a, a[1]);
if (strcmp (a, Hello World!) != 0)
abort ();
return 0;
}
But IMHO this is a serious glibc bug.
[Bug bootstrap/46856] [4.6 regression] internal compiler error in final_scan_insn breaks m68k-linux bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46856 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 CC||bernds at gcc dot gnu.org, ||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2010-12-09 11:53:06 UTC --- Seems this is caused by postreload being broken for HAVE_cc0 targets. reload_combine_recognize_const_pattern happily moves an add after a CC0 setter (but before CC0 user), breaking the requirement that CC0 setter immediately preceedes CC0 user. HAVE_cc0 targets should just be converted or die, but until that happens, postreload should be probably fixed. P4 as none of the primary/secondary targets is HAVE_cc0.
[Bug libfortran/46720] [4.6 Regression] missing quadmath_weak.h with --enable-maintainer-mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46720
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2010-12-09
13:16:19 UTC ---
if test -f ../libquadmath/libquadmath.la; then
LIBQUADLIB=../libquadmath/libquadmath.la
LIBQUADLIB_DEP=../libquadmath/libquadmath.la
LIBQUADINCLUDE='-I$(srcdir)/../libquadmath'
else
LIBQUADLIB=-lquadmath
LIBQUADLIB_DEP=
LIBQUADINCLUDE=
fi
Not sure why do we have this, when test x$libgfor_cv_have_float128 = xyes
then I'd say libquadmath should have been built always.
The dependencies in toplevel:
dependencies = { module=configure-target-libgfortran;
on=all-target-libquadmath; };
and thus
configure-target-libgfortran: maybe-all-target-libquadmath
should take care of it.
Anyway, Thomas, have you ever been able to reproduce it again?
[Bug middle-end/46823] [4.6 Regression] ICE: edge points to wrong declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46823 --- Comment #5 from Martin Jambor jamborm at gcc dot gnu.org 2010-12-09 13:28:32 UTC --- I could not reproduce the ICE with the ouin.cc source but I did with a.cc. So far I have no clue whatsoever how IPA-SRA comes into this (but it is true that switching it off makes the ICE go away) or how the MEM_REF patch makes anything any different (the IPA-SRA modification that seems to trigger this only removes a parameter, it does not build any memory references). Nevertheless, by adding verify_cgraph() calls all over the place, I figured out that the verification becomes unhappy after the following call in expand_call_inline. fn = cgraph_node (fn)-decl; cgraph_node creates a cgraph node if it does not find one so I guess that is a part of the problem.
[Bug fortran/45081] [4.3 Regression] ICE in gfc_conv_array_initializer, at fortran/trans-array.c:4208
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45081 --- Comment #18 from Tobias Burnus burnus at gcc dot gnu.org 2010-12-09 13:31:02 UTC --- Author: burnus Date: Thu Dec 9 13:30:59 2010 New Revision: 167637 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=167637 Log: 2010-12-09 Paul Thomas pa...@gcc.gnu.org PR fortran/45081 * simplify.c (is_constant_array_expr): Allow structure array elements as well as constants. (gfc_simplify_reshape): Copy the derived type of source to the result. 2010-12-09 Paul Thomas pa...@gcc.gnu.org PR fortran/45081 * gfortran.dg/derived_array_intrinsics_1.f90 : New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/derived_array_intrinisics_1.f90 Modified: branches/gcc-4_3-branch/gcc/fortran/ChangeLog branches/gcc-4_3-branch/gcc/fortran/simplify.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog
[Bug fortran/45081] [4.3/4.4/4.5/4.6 Regression] ICE in gfc_conv_array_initializer, at fortran/trans-array.c:4208
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45081 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Summary|[4.3 Regression] ICE in |[4.3/4.4/4.5/4.6 |gfc_conv_array_initializer, |Regression] ICE in |at |gfc_conv_array_initializer, |fortran/trans-array.c:4208 |at ||fortran/trans-array.c:4208 --- Comment #19 from Tobias Burnus burnus at gcc dot gnu.org 2010-12-09 13:31:38 UTC --- CLOSE as FIXED as the patch has been committed for 4.3, 4.4, 4.5 and 4.6. Thanks Thorsten for the report - and thanks Paul for the patch! (Note: For GCC 4.3 I get test suite failures for gfortran.dg/elemental_subroutine_7.f90; those are unrelated to the patch and are probably no regression. Here, they only show up either with GLIBC's MALLOC_PERTURB_ or in valgrind. As the issue does not occur on 4.4 to 4.6, I tacitly move on.)
[Bug libfortran/46720] [4.6 Regression] missing quadmath_weak.h with --enable-maintainer-mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46720 --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2010-12-09 13:34:38 UTC --- (In reply to comment #4) if test -f ../libquadmath/libquadmath.la; then [...] else LIBQUADLIB=-lquadmath LIBQUADLIB_DEP= LIBQUADINCLUDE= fi Not sure why do we have this, when test x$libgfor_cv_have_float128 = xyes then I'd say libquadmath should have been built always. Well, that was proposed by Ralf to allow optionally use a system installed libquadmath instead of the GCC build one. (This requires the patch for PR 46540 which disables the build of libquadmath (--disable-libquadmath) but which still builds gfortran/libgfortran with quadmath support.)
[Bug tree-optimization/46864] New: [4.5/4.6 Regression] ICE: verify_stmts failed: statement marked for throw, but doesn't with -fnon-call-exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46864 Summary: [4.5/4.6 Regression] ICE: verify_stmts failed: statement marked for throw, but doesn't with -fnon-call-exceptions Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 22690 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22690 reduced testcase Compiler output: $ g++ -O -fnon-call-exceptions pr46734.C pr46734.C: In function 'void foo()': pr46734.C:18:1: error: statement marked for throw, but doesn't s.2__k_lsm.4_28 = i_29; pr46734.C:18:1: internal compiler error: verify_stmts failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Tested revisions: r167621 - fail 4.5 r166509 - fail 4.4 r166509 - OK
[Bug fortran/46842] [4.6 Regression] 465.tonto test run miscompares (even with -O0)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46842 --- Comment #12 from Tobias Burnus burnus at gcc dot gnu.org 2010-12-09 13:42:57 UTC --- The following is wrongly compiled - however, it is not a regression as it occurs since GCC 4.1. The solution is the same as for gfc_trans_arrayfunc_assign, where the same issue can occur. Cf. PR 44582. Due to the missing temporary, the array contains 88 88 88 88 instead of 88 1 88 3; the test case works with ifort, NAG and g95. (There is a slim chance that this is also the problem for Tonto as there was a time window in 4.6 where this optimization was never applied; it should have then also failed with 4.1 to 4.6.) integer :: a(2,2) a = reshape([1,2,3,4], [2,2]) call sub(transpose(a)) contains subroutine sub(x) integer :: x(:,:) a(1,:) = 88 a(2,:) = x(:,1) if (any (a(:,1) /= [88, 1]) .or.any (a(:,2) /= [88, 3])) then print *, a call abort() end if end subroutine sub end
[Bug other/46865] New: Using -save-temps (or ccache, distcc) produces different results with multiline macros containing asm code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46865 Summary: Using -save-temps (or ccache, distcc) produces different results with multiline macros containing asm code Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: juha.kallioi...@nokia.com Created attachment 22691 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22691 example case See the attached example case. Also reported here: https://bugs.launchpad.net/gcc-linaro/+bug/687406 When a piece of code containing a multiline macro construct with embedded asm code is first preprocessed then compiled into an object or asm file, the results are different than directly compiling them into an object file or asm code. The preprocessor step could take place when using -save-temps. It also happens when using ccache or distcc. Linux kernel arm parts have this kind of code at least in local_irq_restore()[include/linux/irqflags.h] - raw_local_irq_restore() [arch/arm/include/asm/irqflags.h] Result of example case without -save-temps: .file test.c .text .globl optimized .type optimized, @function optimized: .LFB0: .cfi_startproc #APP # 15 /tmp/test.c 1 nop # 0 2 #NO_APP ret .cfi_endproc .LFE0: .size optimized, .-optimized .ident GCC: (GNU) 4.5.1 .section.note.GNU-stack,,@progbits Result of example case with -save-temps: .file test.c .text .globl optimized .type optimized, @function optimized: .LFB0: .cfi_startproc testb $1, flags(%rip) je .L2 #APP # 15 /tmp/test.c 1 nop # 0 2 #NO_APP ret .L2: #APP # 15 /tmp/test.c 1 nop # 0 2 #NO_APP ret .cfi_endproc .LFE0: .size optimized, .-optimized .ident GCC: (GNU) 4.5.1 .section.note.GNU-stack,,@progbits
[Bug fortran/46842] [4.6 Regression] 465.tonto test run miscompares (even with -O0)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46842 --- Comment #13 from Tobias Burnus burnus at gcc dot gnu.org 2010-12-09 14:15:13 UTC --- Another reason for the Tonto failure could be PR 45777. I have now looked through the TRANSPOSEs of Tonto (cf. comment 11) - and I did not see anything which looks as if it could go wrong. I think it would help if someone with access to SPEC CPU 2006 could debug this further - and tell which version of Tonto is included in CPU 2006. I have looked the the source of the latest (2.3.1) - maybe the crucial code is an an earlier version. The issue of comment 12 does not seem to apply to Tonto - but it should be fixed nevertheless.
[Bug tree-optimization/46864] [4.5/4.6 Regression] ICE: verify_stmts failed: statement marked for throw, but doesn't with -fnon-call-exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46864 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2010-12-09 14:18:57 UTC --- This is execute_sm's fault, rewrite_mem_ref_loc doesn't call maybe_clean_eh_stmt. Adding that call fixes the ICE, but a) gimple_purge_dead_eh_edges isn't called (and can't be called immediately), and I don't see how the correct eh edges would be added for the load and store stmts that are added by store motion. So, I wonder if execute_sm just shouldn't give up optimizing if the mem ref might throw.
[Bug tree-optimization/46866] New: [4.5/4.6 Regression] ICE: type mismatch in address expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46866
Summary: [4.5/4.6 Regression] ICE: type mismatch in address
expression
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: ice-checking
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org
extern void *malloc(__SIZE_TYPE__);
typedef struct T T;
struct T {
void (*destroy)(void *);
};
void destroy(union { void *this; } __attribute__((transparent_union)));
static const typeof(destroy) *_destroy = (const typeof(destroy)*)destroy;
void destroy(void *this);
static T *create_empty(void)
{
T *this = malloc(sizeof(*this));
*this = (typeof(*this)){ _destroy };
return this;
}
void openssl_crl_load(void)
{
T *this = create_empty();
destroy(this);
}
ICEs with
./cc1 -quiet openssl_crl.3.3.3.i -O
openssl_crl.3.3.3.i: In function 'openssl_crl_load':
openssl_crl.3.3.3.i:15:6: error: type mismatch in address expression
void (*T357) (union
{
void * this;
})
void T9d (void *)
_destroy.0_6 = destroy;
openssl_crl.3.3.3.i:15:6: internal compiler error: verify_stmts failed
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
because of the appearant mismatch of the function prototye of destroy
with regarting to the transparent_union attribute.
Appearantly the C frontend has the transparent union prototype type
in function create_empty () while it has the other prototype type
in effect after IPA inlining (after the address-expression is built).
The types are munged together without diagnostic here:
Old value = (tree) 0x75cfa738
New value = (tree) 0x77efe7e0
0x0049c987 in merge_decls (newdecl=0x75d16100,
olddecl=0x75d16000, newtype=0x77efe7e0, oldtype=0x75cfa738)
at /space/rguenther/src/svn/trunk/gcc/c-decl.c:2173
2172 /* Merge the data types specified in the two decls. */
2173 TREE_TYPE (newdecl)
2174= TREE_TYPE (olddecl)
2175= composite_type (newtype, oldtype);
but existing TYPE_POINTER/REFERENCE_TO are not merged.
(gdb) p newdecl-base.addressable_flag
$9 = 0
(gdb) p olddecl-base.addressable_flag
$10 = 1
with unit-at-a-time gimplification we try to fixup here, but we never
visit static initializers like
static const typeof(destroy) *_destroy = (const typeof(destroy)*)destroy;
I have a patch.
[Bug tree-optimization/46866] [4.5/4.6 Regression] ICE: type mismatch in address expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46866 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||4.4.4 Target Milestone|--- |4.5.2
[Bug tree-optimization/46864] [4.5/4.6 Regression] ICE: verify_stmts failed: statement marked for throw, but doesn't with -fnon-call-exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46864 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2010-12-09 14:35:36 UTC --- Caused by http://gcc.gnu.org/viewcvs?root=gccview=revrev=146776 I think, before that EH edges were EDGE_ABNORMAL and thus loop_suitable_for_sm disabled the optimization. So, one solution would be to test for (EDGE_ABNORMAL | EDGE_EH) there.
[Bug c/46853] gcc fails to warn about uninitialized variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46853
--- Comment #3 from Dmitry Gorbachev d.g.gorbachev at gmail dot com
2010-12-09 14:36:15 UTC ---
There are already many bug reports about missing used uninitialized warnings
(such as my PR42905). It seems that the GCC devs do not take them all to heart.
However with the FOR_LOOP test case it is not possible
to optimise away the variable 'foo' and it is unclear
what value the function will eventually return.
In theory the for loop and the variable 'i' could be
optimised away, but I doubt gcc actually does this.
In fact, GCC optimises func into
int func(void)
{
return 0xFF;
}
Undefined behavior, so it's correct.
[Bug c/46853] gcc fails to warn about uninitialized variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46853 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2010-12-09 14:40:12 UTC --- (In reply to comment #3) It seems that the GCC devs do not take them all to heart. No, they just don't have the resources to fix them all. It's not an easy problem.
[Bug c++/44641] Generated constructors and destructors get wrong debug location when a typedef uses a forward declaration of the type before the definition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44641 --- Comment #21 from John David Anglin danglin at gcc dot gnu.org 2010-12-09 14:43:09 UTC --- Author: danglin Date: Thu Dec 9 14:43:03 2010 New Revision: 167638 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=167638 Log: PR c++/44641 * lib/scanasm.exp (dg-function-on-line): Add match pattern for hppa*-*-*. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/lib/scanasm.exp
[Bug c/46853] gcc fails to warn about uninitialized variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46853
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC||manu at gcc dot gnu.org
Resolution||DUPLICATE
--- Comment #5 from Manuel López-Ibáñez manu at gcc dot gnu.org 2010-12-09
14:45:18 UTC ---
(In reply to comment #3)
There are already many bug reports about missing used uninitialized warnings
(such as my PR42905). It seems that the GCC devs do not take them all to
heart.
Fixing those bugs would require major work. There is no enough people to do
that work. And those bugs are not considered important by core devs.
You may have more luck with clang-analyzer, but I think it is still quite green
for C++ bugs.
In fact, GCC optimises func into
int func(void)
{
return 0xFF;
}
Undefined behavior, so it's correct.
Almost 99% sure this is PR 18501.
However your PR42905 seems a novel case to me, no idea why it was closed.
*** This bug has been marked as a duplicate of bug 18501 ***
[Bug tree-optimization/18501] [4.3/4.4/4.5/4.6 Regression] Missing 'used uninitialized' warning (CCP)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||gcc-bugs at nospam dot ||pz.podzone.net --- Comment #42 from Manuel López-Ibáñez manu at gcc dot gnu.org 2010-12-09 14:45:18 UTC --- *** Bug 46853 has been marked as a duplicate of this bug. ***
[Bug other/46865] Using -save-temps (or ccache, distcc) produces different results with multiline macros containing asm code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46865 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.12.09 14:46:05 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2010-12-09 14:46:05 UTC --- Cross jumping doesn't see instructions with different location as equivalent it seems. Comparing the 195r.csa dumps: --- test(3).c.195r.csa 2010-12-09 15:41:13.0 +0100 +++ tmp/test(3).c.195r.csa 2010-12-09 15:39:56.0 +0100 @@ -11,19 +11,50 @@ changing bb of uid 28 from 5 to 4 Merged 4 and 5 without moving. +Cross jumping from bb 3 to bb 4; 1 common insns +changing bb of uid 29 + unscanned insn +changing bb of uid 10 + from 3 to 6 +changing bb of uid 26 + from 3 to 6 +scanning new insn with uid = 30. +deleting insn with uid = 29. +deleting insn with uid = 10. +deleting insn with uid = 26. +deleting insn with uid = 22. +deleting block 6 Thus, confirmed.
[Bug middle-end/46747] invalid first operand of MEM_REF errors and ICEs with -fgraphite-identity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46747 Jack Howarth howarth at nitro dot med.uc.edu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #1 from Jack Howarth howarth at nitro dot med.uc.edu 2010-12-09 14:46:44 UTC --- This appears bug no longer exists at r167622.
[Bug fortran/46842] [4.6 Regression] 465.tonto test run miscompares (even with -O0)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46842 --- Comment #14 from H.J. Lu hjl.tools at gmail dot com 2010-12-09 14:48:46 UTC --- crystal.fppized.f90 is micompiled.
[Bug other/46865] [4.3/4.4/4.5/4.6 Regression] Using -save-temps (or ccache, distcc) produces different results with multiline macros containing asm code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46865 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Known to work||4.1.2 Target Milestone|--- |4.3.6 Summary|Using -save-temps (or |[4.3/4.4/4.5/4.6 |ccache, distcc) produces|Regression] Using |different results with |-save-temps (or ccache, |multiline macros containing |distcc) produces different |asm code|results with multiline ||macros containing asm code Known to fail||4.5.1, 4.6.0 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2010-12-09 14:50:45 UTC --- Works ok with 4.1.
[Bug c++/44641] Generated constructors and destructors get wrong debug location when a typedef uses a forward declaration of the type before the definition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44641 --- Comment #22 from John David Anglin danglin at gcc dot gnu.org 2010-12-09 14:51:41 UTC --- Test case fixed on hppa*-*-*.
[Bug tree-optimization/46864] [4.5/4.6 Regression] ICE: verify_stmts failed: statement marked for throw, but doesn't with -fnon-call-exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46864 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2010-12-09 14:51:59 UTC --- Yep, that sounds sensible to me.
[Bug c++/45646] ld: in partition2.o, section not found for address 0x696765625F617863
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45646 --- Comment #7 from Jack Howarth howarth at nitro dot med.uc.edu 2010-12-09 14:56:45 UTC --- This regression disappeared after r166079 but before r166156 on x86_64-apple-darwin10.
[Bug c++/44240] r159321 causes FAIL: g++.dg/ext/visibility/anon6.C scan-assembler 1BIiE1cE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44240 --- Comment #1 from Jack Howarth howarth at nitro dot med.uc.edu 2010-12-09 15:01:12 UTC --- This regression disappeared after r166839 but before r166929.
[Bug middle-end/46734] [4.5 Regression] ICE in create_tmp_var, at gimplify.c:505
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46734 --- Comment #7 from Martin Jambor jamborm at gcc dot gnu.org 2010-12-09 15:11:30 UTC --- Author: jamborm Date: Thu Dec 9 15:11:26 2010 New Revision: 167639 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=167639 Log: 2010-12-09 Martin Jambor mjam...@suse.cz PR middle-end/46734 * tree-sra.c (splice_param_accesses): Check that there are not multiple ADDRESSABLE types. * testsuite/g++.dg/tree-ssa/pr46734.C: New test. Added: trunk/gcc/testsuite/g++.dg/tree-ssa/pr46734.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-sra.c
[Bug testsuite/45068] g++.dg/debug/dwarf2/nested-2.C failed on Linux/ia64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45068 --- Comment #3 from John David Anglin danglin at gcc dot gnu.org 2010-12-09 15:15:30 UTC --- Author: danglin Date: Thu Dec 9 15:15:26 2010 New Revision: 167640 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=167640 Log: PR testsuite/45068 * g++.dg/debug/dwarf2/nested-2.C: Also match comments starting with ';'. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/debug/dwarf2/nested-2.C
[Bug tree-optimization/18501] [4.3/4.4/4.5/4.6 Regression] Missing 'used uninitialized' warning (CCP)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501 --- Comment #43 from Tom St Denis tstdenis at elliptictech dot com 2010-12-09 15:25:25 UTC --- Maybe it's high time someone address this shortcoming as opposed to adding additional language front ends. If you can't even get the core ones right... Just saying...
[Bug c/46859] Attribute depends on location
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46859
--- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2010-12-09 15:44:49
UTC ---
Shouldn't foo1/foo2 have the same alignment?
[...@gnu-6 pages-1]$ cat x.c
typedef int * ptr_t;
ptr_t
__attribute__((aligned(4096)))
foo1 ()
{
return 0;
}
int *
__attribute__((aligned(4096)))
foo2 ()
{
return 0;
}
[...@gnu-6 pages-1]$ gcc -S x.c
[...@gnu-6 pages-1]$ cat x.s
.filex.c
.text
.align 4096
.globl foo1
.typefoo1, @function
foo1:
.LFB0:
.cfi_startproc
pushq%rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
movl$0, %eax
leave
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE0:
.sizefoo1, .-foo1
.globl foo2
.typefoo2, @function
foo2:
.LFB1:
.cfi_startproc
pushq%rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
movl$0, %eax
leave
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE1:
.sizefoo2, .-foo2
[Bug fortran/46794] ICE on valid code involving power of small integer kinds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46794 --- Comment #6 from Daniel Kraft domob at gcc dot gnu.org 2010-12-09 15:55:16 UTC --- Author: domob Date: Thu Dec 9 15:55:13 2010 New Revision: 167644 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=167644 Log: 2010-12-09 Daniel Kraft d...@domob.eu PR fortran/46794 * trans-expr.c (gfc_conv_power_op): Handle kind of result expression correctly for integer kind 1 and 2 operands. 2010-12-09 Daniel Kraft d...@domob.eu PR fortran/46794 * gfortran.dg/power2.f90: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/power2.f90 Modified: branches/gcc-4_4-branch/gcc/fortran/ChangeLog branches/gcc-4_4-branch/gcc/fortran/trans-expr.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/18501] [4.3/4.4/4.5/4.6 Regression] Missing 'used uninitialized' warning (CCP)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501 --- Comment #44 from Jonathan Wakely redi at gcc dot gnu.org 2010-12-09 16:06:28 UTC --- (In reply to comment #43) Maybe it's high time someone address this shortcoming as opposed to adding additional language front ends. If you can't even get the core ones right... Generally the people who add front-ends aren't the people working on the middle-end and optimisers, so work on one doesn't take resources away from the other. Feel free to pay someone to fix it if this is important to you. Just sayin'
[Bug debug/46867] New: [4.6 Regression] ICE: in emit_note_insn_var_location, at var-tracking.c:7325 with -O -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46867 Summary: [4.6 Regression] ICE: in emit_note_insn_var_location, at var-tracking.c:7325 with -O -g Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 22692 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22692 reduced testcase Compiler output: $ gcc -O -g pr46867.c pr46867.c: In function 'foo': pr46867.c:29:1: internal compiler error: in emit_note_insn_var_location, at var-tracking.c:7325 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Tested revisions: r167621 - crash r165699 - crash r161659 - OK 4.5 r166509 - OK
[Bug debug/46867] [4.6 Regression] ICE: in emit_note_insn_var_location, at var-tracking.c:7325 with -O -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46867 --- Comment #1 from Zdenek Sojka zsojka at seznam dot cz 2010-12-09 16:26:46 UTC --- RTL checking is needed to reproduce this: #ifdef ENABLE_RTL_CHECKING ... old_vl = simplify_replace_fn_rtx (old_vl, NULL_RTX, strip_pointer_flags, NULL); new_vl = simplify_replace_fn_rtx (new_vl, NULL_RTX, strip_pointer_flags, NULL); gcc_assert (rtx_equal_p (old_vl, new_vl)); ... #endif
[Bug tree-optimization/18501] [4.3/4.4/4.5/4.6 Regression] Missing 'used uninitialized' warning (CCP)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501 --- Comment #45 from Manuel López-Ibáñez manu at gcc dot gnu.org 2010-12-09 16:34:46 UTC --- (In reply to comment #44) (In reply to comment #43) Maybe it's high time someone address this shortcoming as opposed to adding additional language front ends. If you can't even get the core ones right... Generally the people who add front-ends aren't the people working on the middle-end and optimisers, so work on one doesn't take resources away from the other. Moreover, the people that add new FEs are not the same people working on the C/C++ FEs. Anyway, in the comments above you can find the reasons why this is difficult, how Clang has solved it (or so they say, I haven't seen a comparison over many different testcases), and why you should not expect a fix in the medium term.
[Bug lto/45448] FAIL: gcc.dg/lto/20090116 c_lto_20090116_0.o-c_lto_20090116_0.o link, -O1 -fwhopr -fPIC (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45448 --- Comment #5 from Jack Howarth howarth at nitro dot med.uc.edu 2010-12-09 16:36:38 UTC --- Fixed after r165163 but before r165193.
[Bug c++/46868] New: [4.6 Regression] ICE: SIGSEGV splay_tree_splay (splay-tree.c:149) on invalid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46868
Summary: [4.6 Regression] ICE: SIGSEGV splay_tree_splay
(splay-tree.c:149) on invalid code
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
-- testcase.C --
template int struct S { S
valgrind output:
$ gcc testcase.C
testcase.C:1:31: error: template argument 1 is invalid
testcase.C:1:29: error: expected unqualified-id at end of input
testcase.C:1:29: error: expected '}' at end of input
cc1plus: error: expected ';' after struct definition
==15288== Invalid read of size 1
==15288==at 0x4C284A1: strcmp (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==15288==by 0x11F354A: splay_tree_splay (splay-tree.c:149)
==15288==by 0x11F3B9D: splay_tree_lookup (splay-tree.c:456)
==15288==by 0x6BE534: get_fileinfo (c-lex.c:110)
==15288==by 0x5C6770: cxx_make_type (lex.c:684)
==15288==by 0x5C6868: make_class_type (lex.c:695)
==15288==by 0x52B473: xref_tag (decl.c:11184)
==15288==by 0x5F454C: emit_support_tinfos (rtti.c:1485)
==15288==by 0x5B6982: cp_write_global_declarations (decl2.c:3668)
==15288==by 0xA21C45: toplev_main (toplev.c:591)
==15288==by 0x6369BBC: (below main) (in /lib64/libc-2.11.2.so)
==15288== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==15288==
cc1plus: 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.
Tested revisions:
r167621 - crash
4.5.1 - OK
[Bug debug/46867] [4.6 Regression] ICE: in emit_note_insn_var_location, at var-tracking.c:7325 with -O -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46867 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.0
[Bug fortran/46842] [4.6 Regression] 465.tonto test run miscompares (even with -O0)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46842 --- Comment #15 from Tobias Burnus burnus at gcc dot gnu.org 2010-12-09 16:40:56 UTC --- (In reply to comment #14) crystal.fppized.f90 is micompiled. If I compare 4.6.0 20100909 with today's GCC build for Tonto 2.3.1's crystal.F90, one sees in the original dump that the only TRANSPOSE relevant change is in the line: seitz = transpose(self%spacegroup%seitz(:,:,s)) (Older version: Call to _gfortran_transpose_r8, newer one not.) However, when I try to create an example out of it, it works as it should.
[Bug lto/45448] FAIL: gcc.dg/lto/20090116 c_lto_20090116_0.o-c_lto_20090116_0.o link, -O1 -fwhopr -fPIC (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45448 --- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr 2010-12-09 16:42:49 UTC --- On powerpc-apple-darwin9 at revision 167626 with -m64, I still see: FAIL: gcc.dg/lto/20090116 c_lto_20090116_0.o-c_lto_20090116_0.o link, -O1 -flto -flto-partition=1to1 -fPIC (internal compiler error)
[Bug c++/42083] [C++0x] ICE on invalid with tree check: expected aggr_init_expr, have error_mark in build_value_init
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42083 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Keywords||ice-on-invalid-code --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2010-12-09 16:43:34 UTC --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00743.html
[Bug libstdc++/46869] New: FAIL: 20_util/enable_shared_from_this/cons/constexpr.cc scan-assembler-not _ZNSt23enable_shared_from_thisIiEC2Ev
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46869 Summary: FAIL: 20_util/enable_shared_from_this/cons/constexpr.cc scan-assembler-not _ZNSt23enable_shared_from_thisIiEC2Ev Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ 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/./gcc/g++ -shared-libgcc -B/test/gnu/gcc /objdir/./gcc -nostdinc++ -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++ -v3/src -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/src/.libs -B/o pt/gnu/gcc/gcc-4.6/hppa2.0w-hp-hpux11.11/bin/ -B/opt/gnu/gcc/gcc-4.6/hppa2.0w-hp -hpux11.11/lib/ -isystem /opt/gnu/gcc/gcc-4.6/hppa2.0w-hp-hpux11.11/include -isy stem /opt/gnu/gcc/gcc-4.6/hppa2.0w-hp-hpux11.11/sys-include -B/test/gnu/gcc/objd ir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/src/.libs -g -O2 -D_GLIBCXX_ASSERT -fmes sage-length=0 -g -O2 -g -O2 -DLOCALEDIR=. -nostdinc++ -I/test/gnu/gcc/objdir/h ppa2.0w-hp-hpux11.11/libstdc++-v3/include/hppa2.0w-hp-hpux11.11 -I/test/gnu/gcc/ objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include -I/test/gnu/gcc/gcc/libstdc++- v3/libsupc++ -I/test/gnu/gcc/gcc/libstdc++-v3/include/backward -I/test/gnu/gcc/g cc/libstdc++-v3/testsuite/util /test/gnu/gcc/gcc/libstdc++-v3/testsuite/20_util/ enable_shared_from_this/cons/constexpr.cc -std=gnu++0x -fno-inline -save-temps -S -o constexpr.s(timeout = 600) PASS: 20_util/enable_shared_from_this/cons/constexpr.cc (test for excess errors) FAIL: 20_util/enable_shared_from_this/cons/constexpr.cc scan-assembler-not _ZNSt23enable_shared_from_thisIiEC2Ev FAIL: 20_util/enable_shared_from_this/cons/constexpr.cc scan-assembler-not _ZN7derivedC2Ev The symbols appear in .stabs directives: .stabs enable_shared_from_this:Tt3736=s8_M_weak_this:/03729,0,64;__bas e_ctor ::3737=#3736,3,3738=*3736,3;:_ZNSt23enable_shared_from_thisIiEC2Ev;1A.;__ comp_ctor ::3737:_ZNSt23enable_shared_from_thisIiEC1Ev;1A.;__base_ctor ::3739=#3 736,3,3738,3740=3741=k3742=3736,3;:_ZNSt23enable_shared_from_thisIiEC2ERKS0_;1A .;__comp_ctor ::3739:_ZNSt23enable_shared_from_thisIiEC1ERKS0_;1A.;operator=::37 43=#3736,3744=3742,3738,3740,3;:_ZNSt23enable_shared_from_thisIiEaSERKS0_;1A.;_ _base_dtor ::3737:_ZNSt23enable_shared_from_thisIiED2Ev;1A.;__comp_dtor ::3737:_ ZNSt23enable_shared_from_thisIiED1Ev;1A.;shared_from_this::3745=#3736,3733,3738, 3;:_ZNSt23enable_shared_from_thisIiE16shared_from_thisEv;2A.3746=#3736,3747=xssh ared_ptr:,3748=*3749=k3736,3;:_ZNKSt23enable_shared_from_thisIiE16shared_from_th isEv;2B.;;,128,0,472,0 .stabs derived:Tt3750=s8!1,020,3736;__base_ctor ::3751=#3750,3,3752=*3 750,3;:_ZN7derivedC2Ev;2A.;__comp_ctor ::3751:_ZN7derivedC1Ev;2A.;;,128,0,26,0 Based on test results, I would guess the fail was introduced by this change: 2010-11-23 Benjamin Kosnik b...@redhat.com Jason Merrill ja...@redhat.com * testsuite/lib/libstdc++.exp: Use scanasm. * testsuite/util/testsuite_common_types.h (constexpr_default_constructible): Add support for non-literal types. (constexpr_single_value_constructible): Same. * testsuite/20_util/enable_shared_from_this/cons/constexpr.cc: Remove xfail. * testsuite/20_util/shared_ptr/cons/constexpr.cc: Add. * testsuite/20_util/unique_ptr/cons/constexpr.cc: Add. * testsuite/20_util/weak_ptr/cons/constexpr.cc: Add. * testsuite/20_util/weak_ptr/comparison/cmp_neg.cc: Adjust line number. The following also fail: FAIL: 20_util/shared_ptr/cons/constexpr.cc scan-assembler-not _ZNSt10shared_ptrI iEC2Ev FAIL: 20_util/shared_ptr/cons/constexpr.cc scan-assembler-not _ZNSt10shared_ptrI iEC2EDn FAIL: 20_util/unique_ptr/cons/constexpr.cc scan-assembler-not _ZNSt10unique_ptrI iSt14default_deleteIiEEC2Ev FAIL: 20_util/unique_ptr/cons/constexpr.cc scan-assembler-not _ZNSt10unique_ptrI iSt14default_deleteIiEEC2EDn FAIL: 20_util/weak_ptr/cons/constexpr.cc scan-assembler-not _ZNSt8weak_ptrIiEC2E v
[Bug libstdc++/46869] FAIL: 20_util/enable_shared_from_this/cons/constexpr.cc scan-assembler-not _ZNSt23enable_shared_from_thisIiEC2Ev
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46869 --- Comment #1 from dave at hiauly1 dot hia.nrc.ca 2010-12-09 16:46:50 UTC --- Attached .ii.
[Bug lto/45448] FAIL: gcc.dg/lto/20090116 c_lto_20090116_0.o-c_lto_20090116_0.o link, -O1 -fwhopr -fPIC (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45448 --- Comment #7 from Dominique d'Humieres dominiq at lps dot ens.fr 2010-12-09 16:47:29 UTC --- See also http://gcc.gnu.org/ml/gcc-testresults/2010-12/msg00696.html for powerpc64-unknown-linux-gnu.
[Bug c++/46868] [4.6 Regression] ICE: SIGSEGV splay_tree_splay (splay-tree.c:149) on invalid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46868 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.0
[Bug c++/46870] New: [C++0x] ICE: SIGSEGV (too deep recursion) on invalid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46870
Summary: [C++0x] ICE: SIGSEGV (too deep recursion) on invalid
code
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
- testcase.C -
template int struct S
{
int foo ()
{
int b = b == b;
S b ();
}
};
--
Compiler output:
$ gcc -std=c++0x testcase.C
Program received signal SIGSEGV, Segmentation fault.
0x0054d5c2 in value_dependent_expression_p (expression=0x77eea1e0)
at /mnt/svn/gcc-trunk/gcc/cp/pt.c:17987
17987 {
(gdb) bt
#0 0x0054d5c2 in value_dependent_expression_p
(expression=0x77eea1e0) at /mnt/svn/gcc-trunk/gcc/cp/pt.c:17987
#1 0x0054df96 in value_dependent_expression_p (expression=value
optimized out)
at /mnt/svn/gcc-trunk/gcc/cp/pt.c:18155
#2 0x0054db85 in value_dependent_expression_p (expression=value
optimized out)
at /mnt/svn/gcc-trunk/gcc/cp/pt.c:18074
#3 0x0054df96 in value_dependent_expression_p (expression=value
optimized out)
at /mnt/svn/gcc-trunk/gcc/cp/pt.c:18155
#4 0x0054db85 in value_dependent_expression_p (expression=value
optimized out)
at /mnt/svn/gcc-trunk/gcc/cp/pt.c:18074
#5 0x0054df96 in value_dependent_expression_p (expression=value
optimized out)
at /mnt/svn/gcc-trunk/gcc/cp/pt.c:18155
...
[Bug middle-end/46844] [4.6 Regression] regrename.c:312:22: error: unused parameter 'reg'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46844 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2010-12-09 17:00:32 UTC --- Author: rguenth Date: Thu Dec 9 17:00:19 2010 New Revision: 167649 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=167649 Log: 2010-12-09 Richard Guenther rguent...@suse.de PR middle-end/46844 * gimple-fold.c (canonicalize_constructor_val): Canonicalize addresses. * gcc.c-torture/compile/pr46866.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr46866.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-fold.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/46866] [4.5/4.6 Regression] ICE: type mismatch in address expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46866 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.12.09 17:00:48 Known to work||4.6.0 Ever Confirmed|0 |1 Known to fail||4.5.2 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2010-12-09 17:00:48 UTC --- Fixed on trunk.
[Bug c++/46871] New: [C++0x] ICE: in cxx_eval_constant_expression, at cp/semantics.c:6686 on invalid code (+rejects valid)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46871
Summary: [C++0x] ICE: in cxx_eval_constant_expression, at
cp/semantics.c:6686 on invalid code (+rejects valid)
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
Testcase is similiar to PR46870:
testcase.C
template int struct S
{
void foo ()
{
//const int c = 0;
const int b = c c;
S b ();
}
};
Compiler output:
$ gcc testcase.C -std=c++0x
testcase.C: In member function 'void Sanonymous ::foo()':
testcase.C:6:19: error: 'c' was not declared in this scope
testcase.C:7:11: error: '(int)b' is not a valid template argument for type
'int' because it is a non-constant expression
testcase.C:7:11: error: the value of 'b' is not usable in a constant expression
testcase.C:7:11: internal compiler error: in cxx_eval_constant_expression, at
cp/semantics.c:6686
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
Backtrace is quite long (44 callers)
When the commented code is uncommented, it seems gcc rejects valid code (comeau
online accepts it):
testcase.C
template int struct S
{
void foo ()
{
const int c = 0;
const int b = c c;
S b ();
}
};
$ gcc testcase.C -std=c++0x
testcase.C: In member function 'void Sanonymous ::foo()':
testcase.C:7:11: error: could not convert template argument 'b' to 'int'
[Bug tree-optimization/18501] [4.3/4.4/4.5/4.6 Regression] Missing 'used uninitialized' warning (CCP)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501 --- Comment #46 from Tom St Denis tstdenis at elliptictech dot com 2010-12-09 17:03:37 UTC --- (In reply to comment #44) (In reply to comment #43) Maybe it's high time someone address this shortcoming as opposed to adding additional language front ends. If you can't even get the core ones right... Generally the people who add front-ends aren't the people working on the middle-end and optimisers, so work on one doesn't take resources away from the other. It still adds work to the project as a whole and serves as a distraction for new people who have the time to contribute. Feel free to pay someone to fix it if this is important to you. Just sayin' If fixing known bugs is not a priority then of what value is this project other than being free? I thought the whole point was to also be correct. Granted this isn't a show-stopper as far as bugs go, but the laissez-faire if you hate it fix it yourself trend in OSS is really annoying. When I ran my own OSS projects I never told the users nyah nyah fix it yourself! When I ran out of time to work on the OSS projects I gave them up, but so long as I called myself a maintainer I addressed issues as best as I could. I'd almost rather they leave it as WONTFIX then just leaving it open. I'd also be happier if they documented this class of SSA fail in the man page so people don't walk into it [as I and others have].
[Bug bootstrap/46812] Linux libgo compilation fails when a libnet is already installed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46812 Andi Kleen andi-gcc at firstfloor dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | --- Comment #4 from Andi Kleen andi-gcc at firstfloor dot org 2010-12-09 17:05:51 UTC --- The problem is still there as of trunk Dec9. I verified the patch below is in the Changelog. libtool: compile: /home/src/gcc/git/obj/./gcc/gccgo -B/home/src/gcc/git/obj/./gcc/ -B/pkg/gcc-4.6-101209/x86_64-unknown-linux-gnu/bin/ -B/pkg/gcc-4.6-101209/x86_64-unknown-linux-gnu/lib/ -isystem /pkg/gcc-4.6-101209/x86_64-unknown-linux-gnu/include -isystem /pkg/gcc-4.6-101209/x86_64-unknown-linux-gnu/sys-include -minline-all-stringops -O2 -g -c -fgo-prefix=libgo_crypto ../../../gcc/libgo/go/crypto/tls/alert.go ../../../gcc/libgo/go/crypto/tls/ca_set.go ../../../gcc/libgo/go/crypto/tls/common.go ../../../gcc/libgo/go/crypto/tls/conn.go ../../../gcc/libgo/go/crypto/tls/handshake_client.go ../../../gcc/libgo/go/crypto/tls/handshake_messages.go ../../../gcc/libgo/go/crypto/tls/handshake_server.go ../../../gcc/libgo/go/crypto/tls/prf.go ../../../gcc/libgo/go/crypto/tls/tls.go -fPIC -o crypto/.libs/libtls.a.o ../../../gcc/libgo/go/crypto/tls/conn.go:11:5: error: /usr/lib/../lib64/libnet.so exists but does not contain any Go export data Can someone please reopen the bug?
[Bug c++/46872] New: 'using' in templated inheritance makes protected member public
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46872 Summary: 'using' in templated inheritance makes protected member public Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: c...@informatik.uni-bremen.de Hi, I can compile the attached piece of code, which I think is illegal C++. I checked several other compilers which all reject it. Also, the same programm without templates fails in g++ (as expected), too. I'm not sure if this behaviour is somehow intended but it does not seem logical to me at all. Best regards, Christoph
[Bug c++/46872] 'using' in templated inheritance makes protected member public
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46872 --- Comment #1 from Christoph Hertzberg chtz at informatik dot uni-bremen.de 2010-12-09 17:21:37 UTC --- Created attachment 22694 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22694 code that should fail to compile
[Bug c++/46873] New: [C++0x] ICE: in build_data_member_initialization, at cp/semantics.c:5489
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46873
Summary: [C++0x] ICE: in build_data_member_initialization, at
cp/semantics.c:5489
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
-- testcase.C --
struct S
{
int i:1;
};
struct T
{
const S s;
constexpr T (S a = S ()) : s (a) { }
};
T t;
I don't know if the code is valid, but the original code was (unless there is
invalid code in system headers).
Compiler output:
$ gcc -std=c++0x testcase.C
gcc -std=c++0x testcase.C
testcase.C: In constructor 'constexpr T::T(S)':
testcase.C:9:38: internal compiler error: in build_data_member_initialization,
at cp/semantics.c:5489
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
Tested revisions:
r167621 - crash
[Bug fortran/46874] New: internal compiler error: in gfc_conv_descriptor_data_get, at fortran/trans-array.c:147
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46874 Summary: internal compiler error: in gfc_conv_descriptor_data_get, at fortran/trans-array.c:147 Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: kapi...@rz.rwth-aachen.de Created attachment 22695 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22695 reproducer code. Compiling the attached example code, got the error: - redukt.f90: In function 'a35_1': redukt.f90:5:0: internal compiler error: in gfc_conv_descriptor_data_get, at fortran/trans-array.c:147 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. - Reproducing: $ gfortran -fopenmp redukt.f90 -c Version: - $ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/snip.snap/4.5.1/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.5.1/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ./configure --prefix=/home/snip.snap/gcc451/bin --enable-lto --with-mpc=/home/snip.snap/gcc451/bin --with-ppl=/home/snip.snap/gcc451/bin --with-mpfr=/home/snip.snap/gcc451/bin --with-gmp=/home/snip.snap/gcc451/bin --with-mpfr=/home/snip.snap/gcc451/bin --with-cloog=/home/snip.snap/gcc451/bin --with-libelf=/home/snip.snap/gcc451/bin Thread model: posix gcc version 4.5.1 (GCC) - snip.snap is of course a existing path. System: Linux HOSTNAME 2.6.18-194.26.1.el5 #1 SMP Tue Nov 9 12:54:20 EST 2010 x86_64 x86_64 x86_64 GNU/Linux
[Bug fortran/46874] internal compiler error: in gfc_conv_descriptor_data_get, at fortran/trans-array.c:147
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46874 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2010-12-09 17:42:21 UTC --- Confirmed on 4.4.4, 4.5.0, and trunk r167642.
[Bug c++/46873] [C++0x] ICE: in build_data_member_initialization, at cp/semantics.c:5489
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46873
--- Comment #1 from Zdenek Sojka zsojka at seznam dot cz 2010-12-09 17:44:39
UTC ---
- original.C -
#include map
#include string
void foo()
{
const std::string s;
std::mapstd::string, std::string::value_type(s, s);
}
--
Original testcase, it should be valid.
$ g++ -std=gnu++0x original.C
In file included from
/mnt/svn/gcc-trunk/binary-167621-lto-fortran-checking-yes-rtl-df/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_algobase.h:65:0,
from
/mnt/svn/gcc-trunk/binary-167621-lto-fortran-checking-yes-rtl-df/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_tree.h:63,
from
/mnt/svn/gcc-trunk/binary-167621-lto-fortran-checking-yes-rtl-df/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/map:60,
from original.C:1:
/mnt/svn/gcc-trunk/binary-167621-lto-fortran-checking-yes-rtl-df/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_pair.h:
In constructor 'constexpr std::pair_T1, _T2::pair(const _T1, const _T2)
[with _T1 = const std::basic_stringchar, _T2 = std::basic_stringchar]':
original.C:7:53: instantiated from here
/mnt/svn/gcc-trunk/binary-167621-lto-fortran-checking-yes-rtl-df/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_pair.h:102:35:
internal compiler error: in build_data_member_initialization, at
cp/semantics.c:5502
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug c++/46873] [C++0x] ICE: in build_data_member_initialization, at cp/semantics.c:5489
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46873 --- Comment #2 from Zdenek Sojka zsojka at seznam dot cz 2010-12-09 17:47:50 UTC --- Now I noticed the line numbers of ICE differ, so it might be different problem. Let me know if you need to reduce original.C.
[Bug target/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #6 from H.J. Lu hjl.tools at gmail dot com 2010-12-09 17:55:41
UTC ---
Another test:
[...@gnu-6 pr46770]$ cat foo.c
#include stdio.h
int
main ()
{
printf (main\n);
return 0;
}
[...@gnu-6 pr46770]$ cat foo1.c
#include stdio.h
static void
init ()
{
printf (init_array\n);
}
static void (*const init_array []) ()
__attribute__ ((used, section (.init_array), aligned (sizeof (void *
= { init };
static void
fini ()
{
printf (fini_array\n);
}
static void (*const fini_array []) ()
__attribute__ ((used, section (.fini_array), aligned (sizeof (void *
= { fini };
[...@gnu-6 pr46770]$ cat foo2.c
#include stdio.h
static void
ctor ()
{
printf (ctor\n);
}
static void (*const ctors []) ()
__attribute__ ((used, section (.ctors), aligned (sizeof (void *
= { ctor };
static void
dtor ()
{
printf (dtor\n);
}
static void (*const dtors []) ()
__attribute__ ((used, section (.dtors), aligned (sizeof (void *
= { dtor };
[...@gnu-6 pr46770]$ make
gcc -O -fPIC -c -o foo.o foo.c
gcc -O -fPIC -c -o foo1.o foo1.c
gcc -O -fPIC -c -o foo2.o foo2.c
gcc -shared -o libfoo2.so foo2.o
gcc -o foo1 foo.o foo1.o libfoo2.so -Wl,-R,.
gcc -shared -o libfoo1.so foo1.o
gcc -o foo2 foo.o libfoo1.so foo2.o -Wl,-R,.
gcc -o foo3 foo.o foo1.o foo2.o
./foo1
ctor
init_array
main
fini_array
dtor
./foo2
init_array
ctor
main
dtor
fini_array
./foo3
ctor
init_array
main
fini_array
dtor
[...@gnu-6 pr46770]$
[Bug bootstrap/38788] gcc 4.4.0 20090109 - Configure with --enable-intermodule breaks build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38788 Sean McGovern gseanmcg at gmail dot com changed: What|Removed |Added CC||gseanmcg at gmail dot com --- Comment #10 from Sean McGovern gseanmcg at gmail dot com 2010-12-09 17:56:45 UTC --- Still any interest in removing this option?
[Bug rtl-optimization/46854] PowerPC optimization regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46854 Michael Meissner meissner at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.12.09 17:56:39 CC||meissner at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #2 from Michael Meissner meissner at gcc dot gnu.org 2010-12-09 17:56:39 UTC --- Note, -O2 generates mostly the code you want, except that it looks the address of the string twice: Here is the code generated with a 4.4.4 based compiler (the compiler happens to be the IBM advance toolchain, version 3.0-1) using -O2 -m32 (-O1/-O3 generate the same code): test: mr. 0,3 mtctr 0 beq 0,.L10 lis 3,.lanch...@ha la 3,.lanch...@l(3) .p2align 4,,15 .L8: lbzu 0,1(3) cmpwi 7,0,0 bne 7,.L8 bdnz .L8 blr .L10: lis 3,.lanch...@ha la 3,.lanch...@l(3) blr The SLES 11SP1 system compiler, which is based on GCC 4.3.4 generates the same code. However, the GCC 4.6 trunk seems to have regressed slightly with -O2 or -O3, in that it does not track that the lbzu updates the pointer, but maintains its own copy: mr. 0,3 mtctr 0 beq- 0,.L5 lis 3,.lanch...@ha la 3,.lanch...@l(3) .L4: mr 9,3 .L3: lbzu 0,1(9) addi 3,3,1 cmpwi 7,0,0 bne+ 7,.L3 bdnz .L4 blr .L5: lis 3,.lanch...@ha la 3,.lanch...@l(3) blr Trunk with -Os does generate the two comparisons: mr 9,3 lis 3,.lanch...@ha la 3,.lanch...@l(3) b .L2 .L5: mr 11,3 addi 3,3,1 lbz 0,1(11) cmpwi 7,0,0 bne+ 7,.L5 addi 9,9,-1 .L2: cmpwi 7,9,0 bne+ 7,.L5 blr So, there are two bugs in this. One that -Os generates larger code than -O2, and the code regression for GCC 4.6.
[Bug c++/46872] 'using' in templated inheritance makes protected member public
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46872 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.5.1, 4.6.0 Resolution||WORKSFORME --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2010-12-09 17:57:31 UTC --- Indeed it does, in current 4.5 branch and mainline. 4.3.x is not maintained anymore.
[Bug rtl-optimization/46875] New: [4.6 Regression] ICE: verify_flow_info failed: too many outgoing branch edges from bb 3 with -Os -fselective-scheduling2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46875 Summary: [4.6 Regression] ICE: verify_flow_info failed: too many outgoing branch edges from bb 3 with -Os -fselective-scheduling2 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 22696 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22696 reduced testcase (from gcc.c-torture/execute/20011219-1.c) Compiler output: $ gcc -Os -fselective-scheduling2 pr46875.c pr46875.c: In function 'foo': pr46875.c:24:1: error: too many outgoing branch edges from bb 3 pr46875.c:24:1: internal compiler error: verify_flow_info failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Tested revisions: r167621 - crash r167556 - crash r165699 - OK
[Bug c++/46873] [C++0x] ICE: in build_data_member_initialization, at cp/semantics.c:5489
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46873 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2010-12-09 18:04:26 UTC --- Yes, reducing it and filing a separate PR seems a good idea: for sure in map and string there are no bitfields.
[Bug tree-optimization/18501] [4.3/4.4/4.5/4.6 Regression] Missing 'used uninitialized' warning (CCP)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501 --- Comment #47 from Manuel López-Ibáñez manu at gcc dot gnu.org 2010-12-09 18:06:05 UTC --- (In reply to comment #46) It still adds work to the project as a whole and serves as a distraction for new people who have the time to contribute. The same could be said of any feature or bugfix. It depends on your priorities and viewpoint. In fact, the way GCC development works, making a new feature work (like a new FE) may provide the motivation for someone to fix an old bug. I'd almost rather they leave it as WONTFIX then just leaving it open. How is that a solution? People will keep reporting it. As said above, it took more than 8 years to solve some bugs, but someone came around and fixed them. There are much older bugs than this one that may get fixed in the next couple of releases. WONTFIX means GCC devs don't want a fix. This is not the case here. There are even ideas above about how to fix this. It is just that there is no enough motivation for anyone to deal with the probably huge amount of work it requires.
[Bug bootstrap/46876] New: libgo fails to compile on libtemplate.so
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46876 Summary: libgo fails to compile on libtemplate.so Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: 3dw...@verizon.net libtool: compile: /home/ed/obj-c++/./gcc/gccgo -B/home/ed/obj-c++/./gcc/ -B/home/ed/bin-c++/x86_64-unknown-linux-gnu/bin/ -B/home/ed/bin-c++/x86_64-unknown-linux-gnu/lib/ -isystem /home/ed/bin-c++/x86_64-unknown-linux-gnu/include -isystem /home/ed/bin-c++/x86_64-unknown-linux-gnu/sys-include -minline-all-stringops -O2 -g -c -fgo-prefix=libgo_rpc ../../../gcc_new/libgo/go/rpc/client.go ../../../gcc_new/libgo/go/rpc/debug.go ../../../gcc_new/libgo/go/rpc/server.go -fPIC -o rpc/.libs/librpc.a.o ../../../gcc_new/libgo/go/rpc/debug.go:16:10: error: /usr/lib/../lib64/libtemplate.so exists but does not contain any Go export data The configure is: ../gcc_new/configure --prefix=/home/ed/bin-c++ --enable-bootstrap-cxx --with-gmp=/usr/local --with-mpfr=/usr/local --with-mpc=/usr/local --enable-languages=c,c++,fortran,go,lto,objc,obj-c++ The bootstrap compiler is: [...@localhost obj-c++]$ gcc -v Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=x86_64-redhat-linux Thread model: posix gcc version 4.1.2 20080704 (Red Hat 4.1.2-44)
[Bug bootstrap/45573] --enable-build-with-cxx failures with ld: crtbegin.o: No such file: No such file or directory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45573 --- Comment #1 from Jack Howarth howarth at nitro dot med.uc.edu 2010-12-09 18:12:48 UTC --- This problem no longer exists on x86_64 Fedora10 with gcc trunk at r167647, however building with... ../gcc/configure --with-gmp=/usr --with-mpfr=/usr --with-mpc=/usr --prefix=/home/howarth/dist --enable-languages=c,c++ --enable-build-with-cxx also no longer results in cc1-dummy being built (whose linkage caused the previous bootstrap failure).
[Bug lto/45448] FAIL: gcc.dg/lto/20090116 c_lto_20090116_0.o-c_lto_20090116_0.o link, -O1 -fwhopr -fPIC (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45448 --- Comment #8 from Jack Howarth howarth at nitro dot med.uc.edu 2010-12-09 18:15:20 UTC --- (In reply to comment #7) See also http://gcc.gnu.org/ml/gcc-testresults/2010-12/msg00696.html for powerpc64-unknown-linux-gnu. My mistake.
[Bug rtl-optimization/46854] PowerPC optimization regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46854 --- Comment #3 from joakim.tjernlund at transmode dot se joakim.tjernlund at transmode dot se 2010-12-09 18:21:50 UTC --- (In reply to comment #2) Note, -O2 generates mostly the code you want, except that it looks the address of the string twice: Here is the code generated with a 4.4.4 based compiler (the compiler happens to be the IBM advance toolchain, version 3.0-1) using -O2 -m32 (-O1/-O3 generate the same code): test: mr. 0,3 mtctr 0 beq 0,.L10 lis 3,.lanch...@ha la 3,.lanch...@l(3) .p2align 4,,15 .L8: lbzu 0,1(3) cmpwi 7,0,0 bne 7,.L8 bdnz .L8 blr .L10: lis 3,.lanch...@ha la 3,.lanch...@l(3) blr The SLES 11SP1 system compiler, which is based on GCC 4.3.4 generates the same code. However, the GCC 4.6 trunk seems to have regressed slightly with -O2 or -O3, in that it does not track that the lbzu updates the pointer, but maintains its own I have seen more similar mistakes such as not using lwzu/stwu at all. Will add a copy of a mail I sent earlier about that. copy: mr. 0,3 mtctr 0 beq- 0,.L5 lis 3,.lanch...@ha la 3,.lanch...@l(3) .L4: mr 9,3 .L3: lbzu 0,1(9) addi 3,3,1 cmpwi 7,0,0 bne+ 7,.L3 bdnz .L4 blr .L5: lis 3,.lanch...@ha la 3,.lanch...@l(3) blr Trunk with -Os does generate the two comparisons: mr 9,3 lis 3,.lanch...@ha la 3,.lanch...@l(3) b .L2 .L5: mr 11,3 addi 3,3,1 lbz 0,1(11) cmpwi 7,0,0 bne+ 7,.L5 addi 9,9,-1 .L2: cmpwi 7,9,0 bne+ 7,.L5 blr So, there are two bugs in this. One that -Os generates larger code than -O2, and the code regression for GCC 4.6. And gcc 4.4.4/4.4.5. I suspect this started much earlier though.
[Bug c++/46872] 'using' in templated inheritance makes protected member public
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46872 Christoph Hertzberg chtz at informatik dot uni-bremen.de changed: What|Removed |Added Resolution|WORKSFORME |FIXED --- Comment #3 from Christoph Hertzberg chtz at informatik dot uni-bremen.de 2010-12-09 18:23:32 UTC --- (In reply to comment #2) Indeed it does, in current 4.5 branch and mainline. 4.3.x is not maintained anymore. Just checked it on a slightly more up-to-date machine, it seems to have been fixed at least in 4.4.1 already. Sorry for the noise.
[Bug rtl-optimization/46854] PowerPC optimization regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46854
--- Comment #4 from joakim.tjernlund at transmode dot se joakim.tjernlund at
transmode dot se 2010-12-09 18:23:59 UTC ---
Here is the copy an an earlier mail I sent to the list in November:
Using gcc 4.4.4 -Os on
loop(long *to, long *from, long len)
{
for (; len; --len)
*++to = *++from;
}
I get
/* gcc 4.4.4 -Os
loop:
addi 5,5,1
li 9,0
mtctr 5
b .L2
.L3:
lwzx 0,4,9
stwx 0,3,9
.L2:
addi 9,9,4
bdnz .L3
blr
*/
gcc 3.4.6 has:
/* gcc 3.4.6 -Os
loop:
mr. 0,5
mtctr 0
beqlr- 0
.L8:
lwzu 0,4(4)
stwu 0,4(3)
bdnz .L8
blr
*/
It doesn't matter which cpu type I use. It seems impossible
to make gcc produce small/faster code with newer gcc.
Perhaps lwzx/stwx is faster on bigger Power cpus but this
can't be true for all cpus, can it?
That should matter though because I asked gcc to produce smaller
code with -Os
[Bug c++/46862] ICE on std::decimal::decimal32 without any fields
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46862
--- Comment #2 from Janis Johnson janis at gcc dot gnu.org 2010-12-09
18:42:13 UTC ---
TYPE_TRANSPARENT_AGGR is set in begin_class_definition in semantics.c for the
classes std::decimal::decimal{32|64|128}. It assumes that they are defined as
in the GNU Standard C++ Library. That code should probably ICE with a good
message if there is no first field or if the first field doesn't have an
expected type. If that sounds appropriate I can write a patch.
The C++ compiler would have to know details of other implementations of the
decimal classes in order to pass them as the underlying scalar types.
[Bug c++/46862] ICE on std::decimal::decimal32 without any fields
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46862 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2010-12-09 18:46:28 UTC --- This got reported to us in https://bugzilla.redhat.com/show_bug.cgi?id=657606 but no details about whether it was pristine or modified libdecnumber and which version thereof. GCC shouldn't ICE even on invalid input (especially when it doesn't say that it is invalid), so some form of error message would be useful.
[Bug rtl-optimization/46865] [4.3/4.4/4.5/4.6 Regression] Using -save-temps (or ccache, distcc) produces different results with multiline macros containing asm code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46865 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||jakub at gcc dot gnu.org Component|other |rtl-optimization AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org |
[Bug c++/46862] ICE on std::decimal::decimal32 without any fields
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46862 --- Comment #4 from Janis Johnson janis at gcc dot gnu.org 2010-12-09 18:50:13 UTC --- This doesn't have anything to do with libdecnumber, it's about how std::decimal::decimalxx are defined in libstdc++. Instead of an ICE with a nice message it would be more appropriate to issue a warning (error?) that GCC can't pass the class the same as the associated scalar type as required by the ABI, and don't set TYPE_TRANSPARENT_AGGR.
[Bug c++/46877] New: [C++0x] ICE: in build_data_member_initialization, at cp/semantics.c:5502
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46877
Summary: [C++0x] ICE: in build_data_member_initialization, at
cp/semantics.c:5502
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
CC: ja...@gcc.gnu.org
Created attachment 22697
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22697
reduced testcase
+++ This bug was initially created as a clone of Bug #46873 +++
- original.C -
#include map
#include string
void foo()
{
const std::string s;
std::mapstd::string, std::string::value_type(s, s);
}
--
Hopefully correctly reduced testcase is attached.
Compiler output (for original.C):
$ gcc -std=c++0x original.C
In file included from
/mnt/svn/gcc-trunk/binary-167556-lto-fortran-checking-yes-rtl-df/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_algobase.h:65:0,
from
/mnt/svn/gcc-trunk/binary-167556-lto-fortran-checking-yes-rtl-df/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_tree.h:63,
from
/mnt/svn/gcc-trunk/binary-167556-lto-fortran-checking-yes-rtl-df/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/map:60,
from original.C:1:
/mnt/svn/gcc-trunk/binary-167556-lto-fortran-checking-yes-rtl-df/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_pair.h:
In constructor 'constexpr std::pair_T1, _T2::pair(const _T1, const _T2)
[with _T1 = const std::basic_stringchar, _T2 = std::basic_stringchar]':
original.C:7:53: instantiated from here
/mnt/svn/gcc-trunk/binary-167556-lto-fortran-checking-yes-rtl-df/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_pair.h:102:35:
internal compiler error: in build_data_member_initialization, at
cp/semantics.c:5502
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
Compiler output (for attached reduced testcase.C):
$ gcc -std=c++0x testcase.C
testcase.C: In constructor 'constexpr pair::pair()':
testcase.C:19:3: internal compiler error: in build_data_member_initialization,
at cp/semantics.c:5502
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
Tested revisions:
r167556 - crash
[Bug c++/46873] [C++0x] ICE: in build_data_member_initialization, at cp/semantics.c:5489
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46873 Zdenek Sojka zsojka at seznam dot cz changed: What|Removed |Added Keywords|ice-on-valid-code | --- Comment #4 from Zdenek Sojka zsojka at seznam dot cz 2010-12-09 18:54:34 UTC --- Opened PR46877 for the second issue.
