[Bug tree-optimization/52631] New: VN does not use simplified expression for lookup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52631
Bug #: 52631
Summary: VN does not use simplified expression for lookup
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pins...@gcc.gnu.org
Take:
unsigned f(unsigned a)
{
unsigned b = a 31;
return b1;
}
--- CUT ---
Even though we have a simplified expression of a31 for b, VN does not use it.
SCC consists of: a_1(D)
Setting value number of a_1(D) to a_1(D)
SCC consists of: b_2
Value numbering b_2 stmt = b_2 = a_1(D) 31;
Setting value number of b_2 to b_2 (changed)
SCC consists of: D.1708_3
Value numbering D.1708_3 stmt = D.1708_3 = b_2 1;
RHS b_2 1 simplified to a_1(D) 31 has constants 1
Setting value number of D.1708_3 to D.1708_3 (changed)
This is a regression from 4.3.
[Bug tree-optimization/52631] [4.6/4.7/4.8 Regression] VN does not use simplified expression for lookup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52631 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Keywords||missed-optimization Last reconfirmed||2012-03-20 AssignedTo|unassigned at gcc dot |pinskia at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 Summary|VN does not use simplified |[4.6/4.7/4.8 Regression] VN |expression for lookup |does not use simplified ||expression for lookup Target Milestone|--- |4.7.1 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-03-20 06:09:18 UTC --- I am working on a fix. Note I did not find this because a performance issue but rather I found this while working on my gimple SSA combiner/simplifer patches.
[Bug tree-optimization/52631] [4.6/4.7/4.8 Regression] VN does not use simplified expression for lookup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52631 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2012-03-20 06:57:51 UTC --- Created attachment 26927 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26927 Patch which fixes the problem
[Bug c++/52625] Incorrect specialization semantics of friend class template declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52625
Nikolka tsoae at mail dot ru changed:
What|Removed |Added
CC||tsoae at mail dot ru
--- Comment #1 from Nikolka tsoae at mail dot ru 2012-03-20 07:34:03 UTC ---
G++ issues the same diagnostic message for the following example:
templateclass
class base {};
class derived : public basederived
{
// error: specialization of 'basederived' after instantiation
templateclass
friend class basederived;
};
It seems that in the original example g++ incorrectly treats the
injected-class-name ::basederived::base as template specialization
basederived, while according to 14.6.1/1 it shall be refer to class template
base. Note that g++ does not issue an error in the following case:
templateclass
class base {};
class derived : public basederived
{
templateclass
friend class ::base;
};
int main() {}
[Bug middle-end/37780] Conditional expression with __builtin_clz() should be optimized out
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37780 --- Comment #2 from amker.cheng amker.cheng at gmail dot com 2012-03-20 07:58:09 UTC --- the special case could be easily detected when gimplifying. but actually I am not sure whether it can be done even in middle end, since the middle end should not depend on any target information, like CLZ_DEFINED_VALUE_AT_ZERO, right?
[Bug fortran/52606] Confusing diagnostics for long identifiers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52606 Janne Blomqvist jb at gcc dot gnu.org changed: What|Removed |Added CC||jb at gcc dot gnu.org --- Comment #3 from Janne Blomqvist jb at gcc dot gnu.org 2012-03-20 08:30:08 UTC --- (In reply to comment #1) Ideally, we'd just accept long identifiers, but the maximum name length is hard-coded (GFC_MAX_SYMBOL_LEN) and already way too large. I want to change this to string pointers (probably using a string pool, maybe the GCC common implementation, TBD). Like Steve says, the Fortran standard puts an upper limit on the length of valid identifiers. For F95 that's 31 characters, for newer standards this has been bumped up to 63, which is the reason for the value of the GFC_MAX_SYMBOL_LEN macro. So regardless of whether the strings are internally stored in statically or dynamically sized buffers, we need to generate an error for identifiers that exceed the limit. For BIND(C) binding labels, I did basically the change you're proposing, switching from static arrays to storing the labels in the symbol table. But that is slightly different, as bind(C) binding labels are not Fortran identifiers, and are thus allowed to be arbitrarily long. See PR 51808. Finally, before attacking static GFC_MAX_SYMBOL_LEN buffers, I suggest getting rid of static buffers of GFC_MAX_MANGLED_SYMBOL_LEN size. We should get rid of that macro altogether. Also, FWIW, the value for that macro is too small at the moment, as it's easy to construct examples were the mangled name exceeds that value. See e.g. PR 51802 for inspiration. ;-)
[Bug fortran/52622] ICE in gfortran 4.6.3, x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52622 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Attachment #26922|application/octet-stream|text/plain mime type|| --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-03-20 08:34:26 UTC --- Comment on attachment 26922 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26922 delta-reduced testcase With GCC 4.8 I don't get an ICE. (I cannot test 4.6 at the moment.)
[Bug fortran/52621] ICE when compiling Fortran77 code with optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52621 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2012-03-20 08:38:27 UTC --- Seems to work without ICE using GCC 4.8 (on x86-64-linux) with your options. (I can currently not test 4.6). You could try a newer version to see whether it has been fixed in the mean time. See for instance http://gcc.gnu.org/wiki/GFortranBinaries
[Bug fortran/51802] [OOP] Duplicate mangling for OOP symbols
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51802 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-03-20 08:42:11 UTC --- That that changing this will break the ABI. Thus, it can only be done when we have to break the ABI. That will happen for the new array descriptor. (This bug is listed at http://gcc.gnu.org/wiki/LibgfortranAbiCleanup)
[Bug c++/52625] Incorrect specialization semantics of friend class template declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52625 --- Comment #2 from Daniel Krügler daniel.kruegler at googlemail dot com 2012-03-20 08:41:48 UTC --- (In reply to comment #1) If this is indeed related to the injected-class-name, this should have been clarified by http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1004 to not apply in this case.
[Bug c/52632] New: GCC compfail on O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52632
Bug #: 52632
Summary: GCC compfail on O0
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vbyakov...@gmail.com
Test case a.c gives following compfail when compiling with O0
gcc –O0 –c a.c
a.c: In function 'foo':
a.c:4:1: error: size of unnamed array is negative
For higher opt level it's ok.
gcc version 4.8.0 20120319 (experimental) (GCC)
The failure happened because FE on –O0 replaces builtin call by zero if it is
not folded. See gcc/builtins.c, fold_builtin_1(), line 10270
switch (fcode)
{
case BUILT_IN_CONSTANT_P:
{
tree val = fold_builtin_constant_p (arg0);
/* Gimplification will pull the CALL_EXPR for the builtin out of
an if condition. When not optimizing, we'll not CSE it back.
To avoid link error types of regressions, return false now. */
if (!val !optimize)
val = integer_zero_node;
return val;
}
It may be fixed by a patch that disabled error message in case of not optimize.
diff --git a/gcc/c-decl.c b/gcc/c-decl.c
index 160d393..1ba3f51 100644
--- a/gcc/c-decl.c
+++ b/gcc/c-decl.c
@@ -5345,7 +5345,7 @@ grokdeclarator (const struct c_declarator *declarator,
if (TREE_CODE (size) == INTEGER_CST size_maybe_const)
{
constant_expression_warning (size);
- if (tree_int_cst_sgn (size) 0)
+ if ((pedantic || optimize) tree_int_cst_sgn (size) 0)
{
if (name)
error_at (loc, size of array %qE is negative,
name);
[Bug tree-optimization/52633] New: Compiler ICE in vect_is_simple_use_1 (ARM)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52633 Bug #: 52633 Summary: Compiler ICE in vect_is_simple_use_1 (ARM) Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: juha.kallioi...@nokia.com Created attachment 26928 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26928 Failing test case Here's another instance of the failure that has been reported before. The attached test case fails when built with -O1 -ftree-vectorize -mfpu=neon This was tested with a compiler built from gcc-4.7-20120225.tar.bz2 sources. ... bin/armv7hl-pc-linux-gnueabi-gcc -O1 -ftree-vectorize -mfpu=neon minimal-testcase.i -c minimal-testcase.i: In function 'lsp_quant_nb': minimal-testcase.i:14:6: internal compiler error: in vect_is_simple_use_1, at tree-vect-stmts.c:6057 Please submit a full bug report, with preprocessed source if appropriate. ... This does not fail with gcc 4.6.3.
[Bug c/52632] GCC compfail on O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52632 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-03-20 09:09:14 UTC --- Testcase?
[Bug fortran/52606] Confusing diagnostics for long identifiers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52606 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2012-03-20 09:10:13 UTC --- (In reply to comment #3) Finally, before attacking static GFC_MAX_SYMBOL_LEN buffers, I suggest getting rid of static buffers of GFC_MAX_MANGLED_SYMBOL_LEN size. We should get rid of that macro altogether. Also, FWIW, the value for that macro is too small at the moment, as it's easy to construct examples were the mangled name exceeds that value. See e.g. PR 51802 for inspiration. ;-) Indeed, one can construct examples which exceed the length: Namely module procedures or module variables. The problem is that GFC_MAX_MANGLED_SYMBOL_LEN allows for GFC_MAX_SYMBOL_LEN*2+4 = 130 characters but one has the prefix __ plus _MOD_ which is not 4 but 7 characters long. Thus, if one goes to the limit, one can create symbols which have the same mangled name. Though, using both the maximal length for the module name and for the symbol name is a very constructed example. On the other hand, PR 51802 does not inspire at all: That PR is about polymorphism-related names. And those are hashed if they don't fit. Example module Very_long_module_name_having_a_length_of_63_characters_really_x contains subroutine an_extremely_long_subroutine_name_which_looks_rather_ugly123456 contains subroutine an_extremely_long_internal_subroutine_name_which_looks_ugly type plus_a_very_very_very_long_type_name_of_almost_the_same_length end type class(plus_a_very_very_very_long_type_name_of_almost_the_same_length), allocatable :: t end subroutine end subroutine end module According to nm, one then gets the following symbols - the last one should end in 123456 but only ends in 123. __very_long_module_name_having_a_length_of_63_characters_really_x_MOD___copy_1169DDF __very_long_module_name_having_a_length_of_63_characters_really_x_MOD___def_init_1169DDF __very_long_module_name_having_a_length_of_63_characters_really_x_MOD___vtab_1169DDF __very_long_module_name_having_a_length_of_63_characters_really_x_MOD_an_extremely_long_subroutine_name_which_looks_rather_ugly123
[Bug target/52607] v4df __builtin_shuffle with {0,2,1,3} or {1,3,0,2}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52607
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-03-20
Ever Confirmed|0 |1
--- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org 2012-03-20
09:17:41 UTC ---
Testing the 3 patches now (AVX2 improvements, expand_vselect and #c8 with
further comments). For 3/4 insn sequences, I agree with the proposal to
attempt to handle d-op0 == d-op1 cross-lane shuffles as two operand in-lane
shuffles
after vperm2f128 swapping the lanes. Two insn expanders could be groupped into
expand_vec_perm_2 and three insn expanders into expand_vec_perm_3.
We need to write some further 2 and 3 insn in-lane expanders though, as shown
by:
typedef double V4DF __attribute__((vector_size (4 * sizeof (double;
typedef long V4DI __attribute__((vector_size (4 * sizeof (long;
#define A(a, b, c, d) \
__attribute__((noinline, noclone)) V4DF \
f##a##b##c##d (V4DF x, V4DF y) \
{\
V4DI m = { a, b, c, d }; \
return __builtin_shuffle (x, y, m); \
}
#define B(b, c, d) A(0, b, c, d) A(1, b, c, d) A(4, b, c, d) A(5, b, c, d)
#define C(c, d) B(0, c, d) B(1, c, d) B(4, c, d) B(5, c, d)
#define D(d) C(2, d) C(3, d) C(6, d) C(7, d)
#define E D(2) D(3) D(6) D(7)
E
int
main ()
{
V4DF x = { 0.5, 1.5, 2.5, 3.5 }, y = { 4.5, 5.5, 6.5, 7.5 }, z;
#undef A
#define A(a, b, c, d) \
z = f##a##b##c##d (x, y); \
if (z[0] != a + .5 || z[1] != b + .5 || z[2] != c + .5 || z[3] != d + .5) \
__builtin_abort ();
E
return 0;
}
[Bug bootstrap/52601] Gcc build fails at Making all in tools with find: bad option -path and find: path-list predicate-list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52601 --- Comment #3 from birender.singh at hotmail dot com 2012-03-20 09:26:01 UTC --- Thanks Eric Botcazou for the valuable suggestion. I downloaded,findutils-4.4.0.tar from gnu website, compiled and installed on my machine. After the installation of gnu find i compiled gcc-4.4.4 again. This time it took more then 4 hour to compile, and at last throws error as mentioned below, But still i installed this and checked the binnaries, found all the required binnaries were available at prefixed location. Currentlly am able to use this gcc and g++ binnaries but not sure about the complete compilation and installation of gcc-4.4.4 Is this correct or should i again compiled gcc-4.4.4 to get complete successful compilation ? . . . . libtool: link: ranlib .libs/libgfortran.a libtool: link: ( cd .libs rm -f libgfortran.la ln -s ../libgfortran.la libgfortran.la ) true DO=all multi-do # make make[6]: Leaving directory `/els/install/gccbuild/gcc4/sparc-sun-solaris2.9/sparcv9/libgfortran' make[5]: Leaving directory `/els/install/gccbuild/gcc4/sparc-sun-solaris2.9/sparcv9/libgfortran' make[4]: Leaving directory `/els/install/gccbuild/gcc4/sparc-sun-solaris2.9/libgfortran' make[3]: Leaving directory `/els/install/gccbuild/gcc4/sparc-sun-solaris2.9/libgfortran' make[2]: Leaving directory `/els/install/gccbuild/gcc4/sparc-sun-solaris2.9/libgfortran' Checking multilib configuration for boehm-gc... Configuring in sparc-sun-solaris2.9/boehm-gc configure: loading cache ./config.cache configure: error: `CXX' has changed since the previous run: configure: former value: `/els/install/gccbuild/gcc4/./gcc/g++ -B/els/install/gccbuild/gcc4/./gcc/ -nostdinc++ -L/els/install/gccbuild/gcc4/sparc-sun-solaris2.9/libstdc++-v3/src -L/els/install/gccbuild/gcc4/sparc-sun-solaris2.9/libstdc++-v3/src/.libs -B/els/install/biru/local/gcc/sparc-sun-solaris2.9/bin/ -B/els/install/biru/local/gcc/sparc-sun-solaris2.9/lib/ -isystem /els/install/biru/local/gcc/sparc-sun-solaris2.9/include -isystem /els/install/biru/local/gcc/sparc-sun-solaris2.9/sys-include' configure: current value: `/els/install/gccbuild/gcc4/./gcc/g++ -B/els/install/gccbuild/gcc4/./gcc/ -nostdinc++ -nostdinc++ -I/els/install/gccbuild/gcc4/sparc-sun-solaris2.9/libstdc++-v3/include/sparc-sun-solaris2.9 -I/els/install/gccbuild/gcc4/sparc-sun-solaris2.9/libstdc++-v3/include -I/els/install/biru/gcc444/gcc-4.4.4/libstdc++-v3/libsupc++ -I/els/install/biru/gcc444/gcc-4.4.4/libstdc++-v3/include/backward -I/els/install/biru/gcc444/gcc-4.4.4/libstdc++-v3/testsuite/util -L/els/install/gccbuild/gcc4/sparc-sun-solaris2.9/libstdc++-v3/src -L/els/install/gccbuild/gcc4/sparc-sun-solaris2.9/libstdc++-v3/src/.libs -B/els/install/biru/local/gcc/sparc-sun-solaris2.9/bin/ -B/els/install/biru/local/gcc/sparc-sun-solaris2.9/lib/ -isystem /els/install/biru/local/gcc/sparc-sun-solaris2.9/include -isystem /els/install/biru/local/gcc/sparc-sun-solaris2.9/sys-include' configure: error: in `/els/install/gccbuild/gcc4/sparc-sun-solaris2.9/boehm-gc': configure: error: changes in the environment can compromise the build configure: error: run `make distclean' and/or `rm ./config.cache' and start over make[1]: *** [configure-target-boehm-gc] Error 1 make[1]: Leaving directory `/els/install/gccbuild/gcc4' make: *** [all] Error 2
[Bug gcov-profile/52627] [4.8 Regression] Build of libgcc fails w/o __GTHREAD_MUTEX_INIT: error: 'mx' undeclared
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52627
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2012-03-20
AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org
|gnu.org |
Target Milestone|--- |4.8.0
Ever Confirmed|0 |1
--- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-03-20
09:46:57 UTC ---
Oops. Can you try
Index: libgcc/libgcov.c
===
--- libgcc/libgcov.c(revision 185562)
+++ libgcc/libgcov.c(working copy)
@@ -713,7 +713,7 @@ __gthread_mutex_t __gcov_flush_mx ATTRIB
static void
init_mx (void)
{
- __GTHREAD_MUTEX_INIT_FUNCTION (mx);
+ __GTHREAD_MUTEX_INIT_FUNCTION (__gcov_flush_mx);
}
static void
init_mx_once (void)
?
[Bug testsuite/52563] FAIL: gcc.dg/tree-ssa/scev-[3,4].c scan-tree-dump-times optimized a 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52563 --- Comment #7 from rguenther at suse dot de rguenther at suse dot de 2012-03-20 09:51:00 UTC --- On Tue, 20 Mar 2012, liujiangning at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52563 --- Comment #6 from Jiangning Liu liujiangning at gcc dot gnu.org 2012-03-20 02:32:12 UTC --- We cannot fix it without relaxing the POINTER_PLUS_EXPR constraints. I was working on that, but as usual the TYPE_IS_SIZETYPE removal has priority. Do you mean you are also working on removing TYPE_IS_SIZETYPE? Yes. Please consider fixing/XFAILing the testcases as they still FAIL and you are responsible for this. You can open a new enhancement PR covering this. I think 64-bit mode should also have this optimization enabled. XFAIL implies the missing of this optimization is a correct behavior. But I think this is not what I expected. So I don't think we should add XFAIL for this case. Instead I want to add a new test case scev-5.c to cover 64-bit testing. XFAIL says it's a known failure. Richard.
[Bug c/52632] GCC compfail on O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52632 --- Comment #2 from Vladimir Yakovlev vbyakovl23 at gmail dot com 2012-03-20 10:03:47 UTC --- Created attachment 26929 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26929 Test case
[Bug fortran/52606] Confusing diagnostics for long identifiers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52606 --- Comment #5 from Janne Blomqvist jb at gcc dot gnu.org 2012-03-20 10:27:33 UTC --- (In reply to comment #4) Indeed, one can construct examples which exceed the length: Namely module procedures or module variables. The problem is that GFC_MAX_MANGLED_SYMBOL_LEN allows for GFC_MAX_SYMBOL_LEN*2+4 = 130 characters but one has the prefix __ plus _MOD_ which is not 4 but 7 characters long. Thus, if one goes to the limit, one can create symbols which have the same mangled name. Yes. I suspect this bug dates back to the patch that introduced the _MOD_ scheme. Previously gfortran just used _ to separate the module and procedure name, allowing a cleverly named external procedure to clash with a module procedure. Though, using both the maximal length for the module name and for the symbol name is a very constructed example. Indeed. If my suspicion above is correct, the bug has been present for ages, and no PR has been filed. On the other hand, PR 51802 does not inspire at all: That PR is about polymorphism-related names. And those are hashed if they don't fit. Ah, I forgot about the hashing scheme, and assumed that as per the PR identifiers appears up to three times in the mangled name, the factor *2 in the calculation of GFC_MAX_MANGLED_SYMBOL_LEN would be incorrect (in addition to the additive factor being incorrect). What was the motivation for this hashing scheme, BTW? Linkers already support 1) long symbol names (I read somewhere that OpenOffice has symbols up to 4000 (!!!) characters long) 2) various symbol hashing schemes (see e.g. DT_GNU_HASH).
[Bug fortran/51802] [OOP] Duplicate mangling for OOP symbols
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51802 --- Comment #2 from Paul Thomas pault at gcc dot gnu.org 2012-03-20 10:52:45 UTC --- (In reply to comment #1) That that changing this will break the ABI. Thus, it can only be done when we have to break the ABI. That will happen for the new array descriptor. (This bug is listed at http://gcc.gnu.org/wiki/LibgfortranAbiCleanup) I agree completely. However, once 4.7 is released, should we be excessively pristine about ABI breakage in trunk? It is, after all, the development version and, to some degree, if people use the development version for production code they should be mindful of the risks Cheers Paul
[Bug c++/52619] ICE/segmentation fault in lambda function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52619 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-03-20 Ever Confirmed|0 |1 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2012-03-20 10:54:16 UTC --- Confirmed. We should figure out a reduced testcase not including anything (note: the internals of atomic are completely different in 4.7 vs 4.6)
[Bug c/52632] GCC compfail on O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52632 --- Comment #3 from Mikael Pettersson mikpe at it dot uu.se 2012-03-20 10:55:49 UTC --- The test case, obviously based on the Linux kernel's BUILD_BUG_ON() macro, behaves exactly as intended: since `offset' is not in fact a constant it causes either a compile-time error or a link-time error (the latter because gcc erroneously omits the compile-time error for an invalid type in an unused sizeof() when optimizing).
[Bug fortran/52606] Confusing diagnostics for long identifiers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52606 --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org 2012-03-20 10:58:13 UTC --- (In reply to comment #5) What was the motivation for this hashing scheme, BTW? Linkers already support 1) long symbol names (I read somewhere that OpenOffice has symbols up to 4000 (!!!) characters long) 2) various symbol hashing schemes (see e.g. DT_GNU_HASH). I think the idea was to have legible dumps (i.e. avoid hashing everything) but also to fit them into the various name[GFC_MAX_SYMBOL_LEN] variables which simply do not take longer names. If you think one can/should improve the scheme, feel free to propose something better. (Only) when switching to the new descriptor, we can change it.
[Bug c++/52619] ICE/segmentation fault in lambda function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52619 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2012-03-20 11:03:00 UTC --- The crash happens in lvalue_kind: an INDIRECT_REF with no TREE_TYPE.
[Bug c++/52596] [4.7/4.8 Regression] [C++11] internal compiler error: in lvalue_kind, at cp/tree.c:153
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52596 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2012-03-20 11:06:40 UTC --- No ICE anymore in mainline for the reduced testcase in Comment #1. Instead, with -std=c++11 only we reject it with: 52596.C: In member function ‘T* zone::allocate()’: 52596.C:14:35: error: lvalue required as decrement operand
[Bug c/52632] GCC compfail on O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52632 --- Comment #4 from joseph at codesourcery dot com joseph at codesourcery dot com 2012-03-20 11:09:43 UTC --- On Tue, 20 Mar 2012, mikpe at it dot uu.se wrote: either a compile-time error or a link-time error (the latter because gcc erroneously omits the compile-time error for an invalid type in an unused sizeof() when optimizing). I'm not aware of such a bug. Please file a separate bug report in Bugzilla with a testcase for this erroneously omits the compile-time error for an invalid type in an unused sizeof() when optimizing.
[Bug tree-optimization/52633] [4.7 Regression] Compiler ICE in vect_is_simple_use_1 (ARM)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52633 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target||armv7hl-*-gnueabi Known to work||4.6.3 Target Milestone|--- |4.7.1 Summary|Compiler ICE in |[4.7 Regression] Compiler |vect_is_simple_use_1 (ARM) |ICE in vect_is_simple_use_1 ||(ARM)
[Bug c++/52613] [C++11] ICE with noexcept in lambda expression in member function of class template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52613 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-03-20 CC||jason at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2012-03-20 11:13:31 UTC --- Confirmed. Here too, like in PR52619, the crash happens in lvalue_kind when an INDIRECT_REF has no TREE_TYPE. And a lambda is also involved. Jason, are we dealing with the same issue?
[Bug tree-optimization/52631] [4.6/4.7/4.8 Regression] VN does not use simplified expression for lookup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52631 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2012-03-20 11:13:57 UTC --- Hmm, but then you'd pessimize the case where b_2 1 were available? Thus, don't you need to do the lookup with the original expression anyway if the lookup for the simplified expression fails? Oh, and doesn't the testcase show a missed canonicalization?
[Bug gcov-profile/52627] [4.8 Regression] Build of libgcc fails w/o __GTHREAD_MUTEX_INIT: error: 'mx' undeclared
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52627 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-03-20 11:19:01 UTC --- Author: rguenth Date: Tue Mar 20 11:18:57 2012 New Revision: 185569 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=185569 Log: 2012-03-20 Richard Guenther rguent...@suse.de PR gcov-profile/52627 * libgcov.c (init_mx): Fix mutex name. Modified: trunk/libgcc/ChangeLog trunk/libgcc/libgcov.c
[Bug target/52630] [4.7 regression] ICE when compiling ppl-0.12 testsuite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52630 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.1 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-03-20 11:19:24 UTC --- Works on x86_64.
[Bug gcov-profile/52627] [4.8 Regression] Build of libgcc fails w/o __GTHREAD_MUTEX_INIT: error: 'mx' undeclared
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52627 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2012-03-20 11:19:25 UTC --- Fixed.
[Bug fortran/51802] [OOP] Duplicate mangling for OOP symbols
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51802 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2012-03-20 11:22:37 UTC --- (In reply to comment #2) I agree completely. However, once 4.7 is released, should we be excessively pristine about ABI breakage in trunk? It is, after all, the development version and, to some degree, if people use the development version for production code they should be mindful of the risks Well, the point is that code (e.g. libraries) compiled with GCC 4.3/4.4/4.5/4.6/4.7 shall be linkable with code compiled with GCC 4.8. In particular, ABI changes relative to Fortran 77 ABIs should be avoided. (libblas, liblapack, ...) - as they are truly used with many applications and as there also no .mod file is involved. For experimental code - such as -fcoarray=lib -, we have more leeway, but for code which is used in production, we shouldn't break the ABI. As the .mod format changes with every release, the chance that the user runs into ABI problems is a bit reduced as for type declarations, one has to recompile to get a new .mod file. However, one can still construct cases where ABI issues also occur in that case. (libA and libB compiled with 4.7; libB uses libA; libA recompiled with 4.8 and then linking libA, libB and the application. If libA and libB use a feature for which the ABI has changed, it will break at link or run time.) The g++ compiler - where the .mod issue does not exist and where many more application use C++ libraries, the ABI issue is much greater. g++ has the -fabi-version=... flag to toggle between different ABIs and -Wabi to warn about such issues. In case of the new array descriptor, the ABI change is so big and affecting many programs, that it cannot be avoided. Thus, doing so, bumping the .so version number and using the opportunity for a clean up should be done. However, afterwards, we have to try hard to avoid any ABI breakage and it would be good if .mod files from a previous compiler version would continue to work. Thus, we should either have the modifications in an upward compatible way - or we should build in some way to read old versions, by explicitly skipping new features during read in. (As we know the version number - we can make use of it!) The .mod part is not an issue for the first version with the new descriptor - as we have to break the ABI. If we include the new array descriptor in 4.8, I think for 4.9 we should already have the policy that no module.c change is allowed, unless it is done such that .mod files from 4.8 continue to work.
[Bug testsuite/52614] [4.8 Regression] Test failures in gcc.dg/vect: vectorizing unaligned access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52614 --- Comment #2 from Greta Yorsh Greta.Yorsh at arm dot com 2012-03-20 11:24:41 UTC --- The tests reported in PR52603 are still failing on arm (last tested on trunk r185474).
[Bug c++/52595] [DR 325] commas and non-static data member initializers don't mix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52595 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2012-03-20 11:29:49 UTC --- I'm a bit confused here. If this is Core/325 should be duplicate of PR51666, right? But, maybe too quickly, I closed the latter as fixed upon Jason commit (see also http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00062.html). So, what's going on? Was the commit for PR51666 incomplete, so to speak?
[Bug target/49868] Implement named address space to place/access data in flash memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49868 --- Comment #18 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-03-20 11:32:59 UTC --- Author: gjl Date: Tue Mar 20 11:32:54 2012 New Revision: 185570 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=185570 Log: PR target/49868 * gcc.target/avr/torture/addr-space-2.h: New file. * gcc.target/avr/torture/addr-space-2-g.h: New test. * gcc.target/avr/torture/addr-space-2-0.h: New test. * gcc.target/avr/torture/addr-space-2-1.h: New test. * gcc.target/avr/torture/addr-space-2-x.h: New test. Added: trunk/gcc/testsuite/gcc.target/avr/torture/addr-space-2-0.c trunk/gcc/testsuite/gcc.target/avr/torture/addr-space-2-1.c trunk/gcc/testsuite/gcc.target/avr/torture/addr-space-2-g.c trunk/gcc/testsuite/gcc.target/avr/torture/addr-space-2-x.c trunk/gcc/testsuite/gcc.target/avr/torture/addr-space-2.h Modified: trunk/gcc/testsuite/ChangeLog
[Bug bootstrap/52601] Gcc build fails at Making all in tools with find: bad option -path and find: path-list predicate-list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52601 --- Comment #4 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-03-20 11:48:47 UTC --- Is this correct or should i again compiled gcc-4.4.4 to get complete successful compilation ? If you still have the build tree around, do rm -rf sparc-sun-solaris2.9/boehm-gc sparc-sun-solaris2.9/sparcv9/boehm-gc make all-target-boehm-gc If this still yields an error, try to do a full build after configuring with an absolute path to the source directory (as recommended in the documentation).
[Bug c++/52618] Explicit template specialization ignores access rights
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52618
--- Comment #2 from blobbyvolley at mailmetrash dot com 2012-03-20 11:53:29 UTC
---
If it can be of any help, I noticed that for partial specializations everything
works as intended (the compiler reports an error).
class B {
typedef double type; // this is a private member
};
templateclass T, class U struct get_type;
templateclass U struct get_typeB, U { // partial specialization
typedef typename B::type type; // error here
};
typedef typename get_typeB, int::type sometype;
[Bug lto/52634] New: multiple definition error when using alias
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52634
Bug #: 52634
Summary: multiple definition error when using alias
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: tian...@cernet.edu.cn
When compiling a project which have 11 cpp files with -flto, g++-4.7 reports
the following error
--
xxx.ltrans25.ltrans.o:(.bss+0x0): multiple definition of `cfliteKeyCallBacks'
xxx.ltrans15.ltrans.o:(.bss+0x0): first defined here
xxx.ltrans29.ltrans.o:(.data+0xc80): multiple definition of
`cfliteKeyCallBacks'
xxx.ltrans15.ltrans.o:(.bss+0x0): first defined here
in xxx.ltrans25.s, I found
.hidden cfliteKeyCallBacks
.globl cfliteKeyCallBacks
.bss
.align 32
.type cfliteKeyCallBacks, @object
.size cfliteKeyCallBacks, 48
cfliteKeyCallBacks:
.zero 48
.setcfliteArrayCallBacks.4936,cfliteKeyCallBacks
in xxx.ltrans15.s, I found
.hidden cfliteKeyCallBacks
.globl cfliteKeyCallBacks
.bss
.align 32
.type cfliteKeyCallBacks, @object
.size cfliteKeyCallBacks, 48
cfliteKeyCallBacks:
.zero 48
.setcfliteValueCallBacks.3513,cfliteKeyCallBacks
in xxx.ltrans29.s, I found
.hidden cfliteKeyCallBacks
.globl cfliteKeyCallBacks
.data
.align 32
.type cfliteKeyCallBacks, @object
.size cfliteKeyCallBacks, 48
cfliteKeyCallBacks:
.quad 0
.quad _ZL17cflite_key_retainPK13__CFAllocatorPKv.19440
.quad _ZL18cflite_key_releasePK13__CFAllocatorPKv.19434
.quad _ZL21cflite_key_copy_descrPKv.19447
.quad _ZL16cflite_key_equalPKvS0_.19429
.quad _ZL15cflite_key_hashPKv.19425
And in cflite.cpp, the corespond source is
---
...
CFDictionaryKeyCallBacks cfliteKeyCallBacks = {
0,
cflite_key_retain,
cflite_key_release,
cflite_key_copy_descr,
cflite_key_equal,
cflite_key_hash,
};
extern CFDictionaryValueCallBacks cfliteValueCallBacks
__attribute__((alias(cfliteKeyCallBacks)));
extern CFArrayCallBacks cfliteArrayCallBacks
__attribute__((alias(cfliteKeyCallBacks)));
The project compiles ok without -flto.
[Bug libstdc++/52604] mt allocator crashes on multi-threaded
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52604 --- Comment #3 from Laurent Aflonsi laurent.alfonsi at st dot com 2012-03-20 12:31:31 UTC --- Well, in fact I am facing a runtime crash on another target (SH4). The crash is fixed by the patch proposed previously. On the other hand, I ve tried to reproduce on x86, to easily report on gcc bugs. and I ve discovered this valgrind error. I first thought both issues were the same, but they are not. And you are right, my patch doesn't fix the valgrind error. Sorry for confusion. The _M_thread_freelist might also be set to NULL at some point. (may be also in ~__freelist()). Setting _M_thread_freelist to NULL at ~__freelist() is solves the valgrind error, but I m not sure this is the right place to do it. Thanks
[Bug c++/52596] [4.7/4.8 Regression] [C++11] internal compiler error: in lvalue_kind, at cp/tree.c:153
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52596 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2012-03-20 12:33:16 UTC --- Oops, sorry, mainline still ICEs, had checking disabled.
[Bug libstdc++/52604] mt allocator crashes on multi-threaded
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52604 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2012-03-20 12:48:20 UTC --- In principle I have no problem with such zeroings, make sense, but it's been a while since the last time I looked into this code and I fear races. In any case, please try to fully run the testsuite (check-performance too, which exercised mt_allocator quite a bit) on the affected targets. Jakub, any comments on this?
[Bug lto/52634] multiple definition error when using alias
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52634 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||lto CC||hubicka at gcc dot gnu.org --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-03-20 12:55:45 UTC --- Can you provide a testcase? You can try reducing the number of input sources required by performing a partial link (-r -nostdlib), and use -flto-partition=1to1 to make that reduction more reliable (if the bug reproduces with that option). Does the error reproduce with -flto-partition=none? It seems to me that assembing the target is broken (and thus partitioning).
[Bug c/52635] New: gcc fails to diagnose invalid type in unused sizeof() when optimizing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52635
Bug #: 52635
Summary: gcc fails to diagnose invalid type in unused sizeof()
when optimizing
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mi...@it.uu.se
Created attachment 26930
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26930
test case
cat bug.c
extern int bar;
void foo(void)
{
(void)sizeof(char[1 - 2 * !__builtin_constant_p(bar)]);
}
objdir/gcc/xgcc -Bobjdir/gcc -O1 -S bug.c
objdir/gcc/xgcc -Bobjdir/gcc -O0 -S bug.c
bug.c: In function 'foo':
bug.c:4:5: error: size of unnamed array is negative
The test case deliberately contains an invalid type expression, but gcc only
diagnoses it at -O0, at -O1 and above there is no error or warning.
Reproduced on x86_64-linux with gcc 4.8-20120318, 4.7.0-RC-20120314, every
4.x.latest release, 3.3.6, and 3.2.3. gcc-3.4.6 fails to diagnose also at -O0.
The test case is based on the Linux kernel's BUILD_BUG_ON() macro.
[Bug c/52632] GCC compfail on O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52632 --- Comment #5 from Mikael Pettersson mikpe at it dot uu.se 2012-03-20 13:18:00 UTC --- (In reply to comment #4) I'm not aware of such a bug. Please file a separate bug report in Bugzilla with a testcase for this erroneously omits the compile-time error for an invalid type in an unused sizeof() when optimizing. Done, see PR52635.
[Bug go/52583] Several new go testsuite failues on Solaris
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52583 --- Comment #15 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2012-03-20 13:48:51 UTC --- --- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2012-03-16 09:55:26 UTC --- [...] I'm now running into --- FAIL: net.TestMulticastListener (0.00 seconds) sockoptip.go:118: 224.0.0.254:12345 not found in RIB still looking what's going on here. And the This is caused by Solaris using go/net/interface_stub.go. After some investigation, it turns out that while the interfaceTable and interfaceAddrTable functions could be implemented in several different ways (e.g. routing sockets and SIOCGLIFNUM, SIOCGLIFCONF ioctls), interfaceMulticastAddrTable requires the use of the SNMP MIB-2 functionality described in inet/mib2.h, which also covers the other two. I'll try to come up with something, based on the code in net-snmp and the OpenSolaris netstat.c. Rainer
[Bug libstdc++/52604] mt allocator crashes on multi-threaded
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52604 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2012-03-20 14:03:41 UTC --- It surprises me. The destructors of libstdc++, on which the binary depends on, should be run after the destructors of the binary, not before it.
[Bug c++/52487] [4.6/4.7/4.8 Regression] [C++11] ICE at cp/semantics.c:5613 with lambda capturing reference to incomplete type by value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52487 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2012-03-20 14:04:23 UTC --- Looking into it.
[Bug bootstrap/52623] 4.7.0-RC-20120314: bootstrap failure on AIX due to multilib and using C++ in post-stage1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52623 David Edelsohn dje at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-03-20 Ever Confirmed|0 |1 --- Comment #2 from David Edelsohn dje at gcc dot gnu.org 2012-03-20 14:12:00 UTC --- We should disable libquadmath on AIX. It is not needed or useful there. Have you tried adding --disable-libquadmath when configuring GCC?
[Bug lto/52634] multiple definition error when using alias
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52634 --- Comment #2 from Bin Tian tianbin at cernet dot edu.cn 2012-03-20 14:16:02 UTC --- Created attachment 26931 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26931 patch for make-3.82
[Bug lto/52634] multiple definition error when using alias
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52634 --- Comment #3 from Bin Tian tianbin at cernet dot edu.cn 2012-03-20 14:16:49 UTC --- The bug is reproducable with -r -flto-partition=1to1, and not with -r -flto-partition=none. My project is hard to reduce because of complex dependencies. It seems that if the call graph is too simple, the bug never shows up. Finally, I make a testcase based on make-3.82 (http://ftp.gnu.org/gnu/make/make-3.82.tar.gz). Please apply the attached patch on make-3.82, and compile it with the following instructions: $ autoreconf -vif $ ./configure CFLAGS='-g -O2 -flto' CC=gcc-4.7 $ make The patch is produced with git format-patch.
[Bug c/52635] gcc fails to diagnose invalid type in unused sizeof() when optimizing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52635 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 2012-03-20 14:31:16 UTC --- I don't think this is a bug. For -std=c89 -pedantic-errors you get a proper error - C89 doesn't have VLAs, but otherwise when optimizing the type is considered just as a VLA type. You don't get any diagnostic even when you actually use the sizeof (e.g. return it from the function), negative VLA size doesn't have any diagnostic (most often it isn't even possible to diagnose it at compile time).
[Bug lto/52634] multiple definition error when using alias
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52634
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-03-20
Ever Confirmed|0 |1
--- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2012-03-20
14:42:33 UTC ---
Reduced testcase:
t1.c
extern int cfliteValueCallBacks;
void baz (int *);
int main () { baz(cfliteValueCallBacks); }
t2.c
int cfliteKeyCallBacks = 5;
extern int cfliteValueCallBacks __attribute__((alias(cfliteKeyCallBacks)));
fails as:
gcc-4.7 -flto -flto-partition=1to1 t1.c t2.c -r -nostdlib
/tmp/ccPs2Uvd.ltrans1.ltrans.o:(.bss+0x0): multiple definition of
`cfliteKeyCallBacks'
/tmp/ccPs2Uvd.ltrans0.ltrans.o:(.data+0x0): first defined here
collect2: error: ld returned 1 exit status
Not sure if the source is valid by design.
[Bug lto/52634] multiple definition error when using alias
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52634 --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2012-03-20 14:55:42 UTC --- 2 t1.o 3 164 2f48a666878dc458 PREVAILING_DEF_IRONLY_EXP main 169 2f48a666878dc458 UNDEF baz 173 2f48a666878dc458 RESOLVED_IR cfliteValueCallBacks t2.o 2 164 9f18e45b84a4baf8 PREVAILING_DEF_IRONLY_EXP cfliteValueCallBacks 176 9f18e45b84a4baf8 PREVAILING_DEF_IRONLY_EXP cfliteKeyCallBacks looks sane, but the partitioning not: Callgraph/varpool at WPA time: baz/1 @0x75a257e0 (asm: baz) availability:not_available reachable called by: main/0 (1.00 per call) calls: References: Refering this function: main/0 @0x75a256c0 (asm: main) availability:available analyzed needed reachable externally_visible prevailing_def_ironly_exp finalized called by: calls: baz/1 (1.00 per call) References: var:cfliteValueCallBacks (addr) Refering this function: cfliteKeyCallBacks: availability:overwritable (asm: cfliteKeyCallBacks) initialized needed analyzed finalized externally_visible prevailing_def_ironly_exp References: Refering this var: var:cfliteValueCallBacks (alias) cfliteValueCallBacks: availability:overwritable (asm: cfliteValueCallBacks) needed analyzed finalized externally_visible prevailing_def_ironly_exp References: var:cfliteKeyCallBacks (alias) Refering this var: fn:main/0 (addr) Partitions: Writing partition t2.o to file /tmp/ccZbL7rX.ltrans0.o, 0 insns cgraph nodes: varpool nodes: cfliteKeyCallBacks Writing partition t1.o to file /tmp/ccZbL7rX.ltrans1.o, 5 insns cgraph nodes: main/0 varpool nodes: where is the varpool/alias node for cfliteValueCallBacks?
[Bug middle-end/52636] New: [4.8 Regression] ICE: tree check: expected integer_cst, have string_cst in tree_to_double_int, at tree.h:4324
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52636 Bug #: 52636 Summary: [4.8 Regression] ICE: tree check: expected integer_cst, have string_cst in tree_to_double_int, at tree.h:4324 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: bur...@net-b.de, rgue...@gcc.gnu.org Host: x86_64-apple-darwin10 Target: x86_64-apple-darwin10 Build: x86_64-apple-darwin10 Since revision 185466, compiling aermod.f90 from the polyhedron test suite with '-O3 --param max-inline-insns-auto=51' and above gives an ICE: [macbook] lin/test% /opt/gcc/gcc4.8w-185465p4/bin/gfortran -O3 --param max-inline-insns-auto=51 aermod.f90 [macbook] lin/test% /opt/gcc/gcc4.8w-185466p4/bin/gfortran -O3 --param max-inline-insns-auto=50 aermod.f90 [macbook] lin/test% /opt/gcc/gcc4.8w-185466p4/bin/gfortran -O3 --param max-inline-insns-auto=51 aermod.f90 aermod.f90: In function 'preinclud_.part.28': aermod.f90:4628:0: internal compiler error: tree check: expected integer_cst, have string_cst in tree_to_double_int, at tree.h:4324 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. So far my attempts to reduce the code have not been successful.
[Bug c/52635] gcc fails to diagnose invalid type in unused sizeof() when optimizing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52635
--- Comment #2 from joseph at codesourcery dot com joseph at codesourcery dot
com 2012-03-20 15:13:13 UTC ---
On Tue, 20 Mar 2012, mikpe at it dot uu.se wrote:
cat bug.c
extern int bar;
void foo(void)
{
(void)sizeof(char[1 - 2 * !__builtin_constant_p(bar)]);
}
objdir/gcc/xgcc -Bobjdir/gcc -O1 -S bug.c
objdir/gcc/xgcc -Bobjdir/gcc -O0 -S bug.c
bug.c: In function 'foo':
bug.c:4:5: error: size of unnamed array is negative
The test case deliberately contains an invalid type expression, but gcc only
diagnoses it at -O0, at -O1 and above there is no error or warning.
Do you have an example not involving __builtin_constant_p? When
optimizing, this array will be considered a VLA (i.e. the size will be
considered nonconstant) as __builtin_constant_p is only evaluated later
(after inlining, for example), long after decisions about whether arrays
are VLAs have to be made.
[Bug testsuite/52614] [4.8 Regression] Test failures in gcc.dg/vect: vectorizing unaligned access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52614 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-03-20 Ever Confirmed|0 |1 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-03-20 15:16:45 UTC --- The tests reported in PR52603 are still failing on arm (last tested on trunk r185474). When asked on IRC, Richard Guenther said he preferred a new PR rather than reopening PR52603. He also asked me to test the addition of -fno-common to DEFAULT_VECTCFLAGS in gcc/testsuite/gcc.dg/vect/vect.exp (patch in comment #0). Could some of you test it on your favorite plaforms (it is enough to vect.exp only)?
[Bug middle-end/52636] [4.8 Regression] ICE: tree check: expected integer_cst, have string_cst in tree_to_double_int, at tree.h:4324
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52636 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-03-20 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.8.0 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-03-20 15:22:02 UTC --- Confirmed.
[Bug tree-optimization/52571] vectorizer changes alignment of common symbols
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52571 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED CC||ro at gcc dot gnu.org Resolution|FIXED | --- Comment #8 from Rainer Orth ro at gcc dot gnu.org 2012-03-20 15:27:48 UTC --- Unfortunately, the patch caused many testsuite failures on both sparc-sun-solaris and powerpc-apple-darwin, as can be seen e.g. at http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02102.html Should I file a separate PR for this? Rainer
[Bug c++/52637] New: ICE producing debug info for c++11 code using templates/decltype/lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52637
Bug #: 52637
Summary: ICE producing debug info for c++11 code using
templates/decltype/lambda
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: scov...@gmail.com
The following code snippet produces an ICE when compiled by gcc-4.7.0-RC1 with
flags `-std=gnu++11 -g -c' (gcc-4.6.2 and 4.5.3 accept it):
=== bug.cpp ===
template typename T
struct foo {
foo(T fn) { }
};
template class T, typename V
void bar(T*, V) {
auto x = [] { };
auto y = foodecltype(x)(x);
}
template typename T
void bar(T* t) { bar(t, [] { }); }
struct baz {
void bar() { ::bar(this); }
};
===
$ ~/apps/gcc-4.7-RC1/bin/g++ -std=gnu++11 -g bug.cpp
bug.cpp:17:2: internal compiler error: in output_die, at dwarf2out.c:8463
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
The testcase was distilled from a multi-thousand line app with help from
multidelta.
My platform is i686-pc-cygwin, in case that matters.
[Bug fortran/52622] ICE in gfortran 4.6.3, x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52622
--- Comment #2 from Adrian Prantl adrian at llnl dot gov 2012-03-20 15:33:40
UTC ---
I'm getting the error with both gcc 4.6.2 and 4.6.3
Below is the stack trace.
Program received signal SIGSEGV, Segmentation fault.
resolve_symbol (sym=0x14091b0) at ../../gcc-4.6.2/gcc/fortran/resolve.c:12412
12412 sym-formal_ns-refs++;
(gdb) l
12407formal = formal-next;
12408
12409 if (formal)
12410{
12411 sym-formal_ns = formal-sym-ns;
12412 sym-formal_ns-refs++;
12413}
12414}
12415
12416 /* Check threadprivate restrictions. */
(gdb) bt
#0 resolve_symbol (sym=0x14091b0)
at ../../gcc-4.6.2/gcc/fortran/resolve.c:12412
#1 0x0052f157 in traverse_ns (st=value optimized out,
func=0x511340 resolve_symbol)
at ../../gcc-4.6.2/gcc/fortran/symbol.c:
#2 0x0052f146 in traverse_ns (st=value optimized out,
func=0x511340 resolve_symbol)
at ../../gcc-4.6.2/gcc/fortran/symbol.c:3330
#3 0x0051bd4c in resolve_types (ns=0x14087b0)
at ../../gcc-4.6.2/gcc/fortran/resolve.c:13543
#4 0x0051be28 in resolve_types (ns=0x13cd6e0)
at ../../gcc-4.6.2/gcc/fortran/resolve.c:13554
#5 0x00510bf4 in gfc_resolve (ns=0x13cd6e0)
at ../../gcc-4.6.2/gcc/fortran/resolve.c:13642
#6 gfc_resolve (ns=0x13cd6e0) at ../../gcc-4.6.2/gcc/fortran/resolve.c:13630
#7 0x00506229 in gfc_parse_file ()
at ../../gcc-4.6.2/gcc/fortran/parse.c:4404
#8 0x0053f366 in gfc_be_parse_file ()
at ../../gcc-4.6.2/gcc/fortran/f95-lang.c:250
#9 0x0079d6fc in compile_file (argc=13, argv=0x7fffdfc8)
at ../../gcc-4.6.2/gcc/toplev.c:579
#10 do_compile (argc=13, argv=0x7fffdfc8)
at ../../gcc-4.6.2/gcc/toplev.c:1900
---Type return to continue, or q return to quit---
#11 toplev_main (argc=13, argv=0x7fffdfc8)
at ../../gcc-4.6.2/gcc/toplev.c:1963
#12 0x77874c4d in __libc_start_main (main=value optimized out,
argc=value optimized out, ubp_av=value optimized out,
init=value optimized out, fini=value optimized out,
rtld_fini=value optimized out, stack_end=0x7fffdfb8)
at libc-start.c:226
#13 0x0049f9b5 in _start ()
(gdb)
[Bug tree-optimization/52571] vectorizer changes alignment of common symbols
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52571 --- Comment #9 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-03-20 15:55:23 UTC --- Unfortunately, the patch caused many testsuite failures on both sparc-sun-solaris and powerpc-apple-darwin, as can be seen e.g. at http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02102.html Should I file a separate PR for this? PR52603. Could you test the patch?
[Bug tree-optimization/52636] [4.8 Regression] ICE: tree check: expected integer_cst, have string_cst in tree_to_double_int, at tree.h:4324
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52636
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Component|middle-end |tree-optimization
--- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-03-20
15:56:42 UTC ---
Patch:
2012-03-20 Richard Guenther rguent...@suse.de
PR tree-optimizer/52636
* tree-vect-slp.c (vect_get_constant_vectors): Convert constants
to the appropriate type.
Index: gcc/tree-vect-slp.c
===
*** gcc/tree-vect-slp.c (revision 185563)
--- gcc/tree-vect-slp.c (working copy)
*** vect_get_constant_vectors (tree op, slp_
*** 2363,2368
--- 2363,2374
/* Create 'vect_ = {op0,op1,...,opn}'. */
number_of_places_left_in_vector--;
+ if (constant_p
+ !types_compatible_p (TREE_TYPE (vector_type), TREE_TYPE (op)))
+ {
+ op = fold_unary (VIEW_CONVERT_EXPR, TREE_TYPE (vector_type), op);
+ gcc_assert (op CONSTANT_CLASS_P (op));
+ }
elts[number_of_places_left_in_vector] = op;
if (number_of_places_left_in_vector == 0)
[Bug tree-optimization/52571] vectorizer changes alignment of common symbols
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52571 --- Comment #10 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-03-20 15:56:55 UTC --- PR52603. Could you test the patch? Sorry, pr52614.
[Bug testsuite/52614] [4.8 Regression] Test failures in gcc.dg/vect: vectorizing unaligned access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52614 --- Comment #4 from Greta Yorsh Greta.Yorsh at arm dot com 2012-03-20 16:01:02 UTC --- These tests pass on arm-none-eabi with the option -fno-common. Thank you, Greta
[Bug c++/52625] Incorrect specialization semantics of friend class template declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52625 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-03-20 Ever Confirmed|0 |1 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2012-03-20 16:08:26 UTC --- confirmed
[Bug tree-optimization/51737] [4.6 Regression] g++ crashes (internal compiler error: Segmentation fault) when compiling quickbook
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51737 --- Comment #18 from Jan Hubicka hubicka at gcc dot gnu.org 2012-03-20 16:19:55 UTC --- Created attachment 26932 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26932 patch in testing I am testing the attached patch. It basically delays removal of the clone until after the body saving process is finished. The problem is still on trunk, just the testcase passes because we optimize it too early.
[Bug middle-end/51893] Wrong subword index computation in store_bit_field_1 on BIG_ENDIAN targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51893 --- Comment #9 from Aurelien Buhrig aurelien.buhrig.gcc at gmail dot com 2012-03-20 16:22:52 UTC --- Do you need additional information about this bug? Any comment about the provided patch?
[Bug target/52607] v4df __builtin_shuffle with {0,2,1,3} or {1,3,0,2}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52607 --- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org 2012-03-20 16:26:08 UTC --- Author: jakub Date: Tue Mar 20 16:25:54 2012 New Revision: 185577 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=185577 Log: PR target/52607 * config/i386/i386.md (isa attribute): Add avx2 and noavx2. (enabled attribute): Handle avx2 and noavx2 isas. * config/i386/sse.md (avx2_vec_dupv8sf_1, avx2_pbroadcastmode_1): New insns. (vec_dupmode): Add avx2 =x,x alternative. (vec_dupmode splitter): Don't split if TARGET_AVX2. (*avx_vperm_broadcast_mode): Don't split V4DFmode if TARGET_AVX2. For TARGET_AVX2, V8SFmode and elt == 0 split into vbroadcastss. * config/i386/i386.c (expand_vec_perm_pshufb): Emit also vpermps for V8SFmode. (expand_vec_perm_1): For broadcasts, use avx2_pbroadcastmode_1 if possible, handle also V8SFmode. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/i386.md trunk/gcc/config/i386/sse.md
[Bug c/51206] Building Cross-Compiler for Linux/x86_64 multilibs fails due to FLAGS_FOR_TARGET
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51206 Ian Lance Taylor ian at airs dot com changed: What|Removed |Added CC||ian at airs dot com, ktietz ||at gcc dot gnu.org --- Comment #2 from Ian Lance Taylor ian at airs dot com 2012-03-20 16:26:29 UTC --- Problem with multilibs building mingw. Adding Kai Tietz who approved the patch for these lines (http://gcc.gnu.org/ml/gcc-patches/2009-11/msg00262.html).
[Bug testsuite/52614] [4.8 Regression] Test failures in gcc.dg/vect: vectorizing unaligned access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52614 --- Comment #5 from Rainer Orth ro at gcc dot gnu.org 2012-03-20 16:37:04 UTC --- For the single testcase I've been using for the reghunt (gcc.dg/vect/vect-109.c), adding -fno-common fixes the failure. On SPARC, one probably also has to add -fno-common to gcc.target/sparc/fpmul-2.c. I'll now run a full bootstrap with those changes. Rainer
[Bug lto/51663] LTO does not reclaim comdat-local statics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51663 --- Comment #3 from Jan Hubicka hubicka at gcc dot gnu.org 2012-03-20 16:49:44 UTC --- OK, the funny inconsistency comes from the fact that we always eliminate COMDAT variables, but we keep around static variables with -fno-toplevel-reorder. -O0 imply -fno-toplevel-reorder and -fwhole-program brings COMDAT variables local, just like in this case. This all envolved for historical reasons. I wonder how we really want to behave here... I am looking into the LTO case. With new plugin API it should just work. Honza
[Bug target/52607] v4df __builtin_shuffle with {0,2,1,3} or {1,3,0,2}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52607 --- Comment #14 from Jakub Jelinek jakub at gcc dot gnu.org 2012-03-20 16:51:50 UTC --- Author: jakub Date: Tue Mar 20 16:51:41 2012 New Revision: 185579 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=185579 Log: PR target/52607 * config/i386/i386.c (expand_vec_perm_vperm2f128): New function. (ix86_expand_vec_perm_const_1): Call it. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c
[Bug lto/52634] multiple definition error when using alias
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52634 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |hubicka at gcc dot gnu.org |gnu.org | --- Comment #6 from Jan Hubicka hubicka at gcc dot gnu.org 2012-03-20 16:55:40 UTC --- mine. The alias node should go along with the variable into the appropriate partition. It seems that the partitioning logic is confused by fact that the variable is static but alias is not, so it decides to put alias into both units and the alias drags variable with it.
[Bug testsuite/52614] [4.8 Regression] Test failures in gcc.dg/vect: vectorizing unaligned access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52614 --- Comment #6 from Pat Haugen pthaugen at gcc dot gnu.org 2012-03-20 17:21:21 UTC --- Adding -fno-common fixes the failures on powerpc64 also.
[Bug c/52635] gcc fails to diagnose invalid type in unused sizeof() when optimizing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52635
--- Comment #3 from Mikael Pettersson mikpe at it dot uu.se 2012-03-20
17:26:23 UTC ---
(In reply to comment #2)
Do you have an example not involving __builtin_constant_p?
Unfortunately no. The example is just a cleaned up and reduced version of the
one from PR52632. I've tried a few variations with __builtin_offsetof() and
sizeof(), but they all work, i.e., generate diagnostics at all optimization
levels.
When
optimizing, this array will be considered a VLA (i.e. the size will be
considered nonconstant) as __builtin_constant_p is only evaluated later
(after inlining, for example), long after decisions about whether arrays
are VLAs have to be made.
I see. The Linux kernel also uses the following variation:
#define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:-!!(e); })
which seems to work with all of __builtin_constant_p, __builtin_offsetof,
sizeof, at both -O0 and -O2.
Perhaps I ought to submit a kernel patch to make BUILD_BUG_ON() use the struct
trick rather than the array size trick?
[Bug c++/52638] New: ice in build_vector_from_val
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52638 Bug #: 52638 Summary: ice in build_vector_from_val Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: dcb...@hotmail.com Created attachment 26933 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26933 C++ source code I just tried to compile the package lpg-1.1.0 on gcc-4.8 trunk dated 20120319 on an AMD x86_64 box. The compiler said In file included from generator.h:4:0, from generator.cpp:1: tuple.h: In constructor 'ArrayT::Array(int, T) [with T = bool]': tuple.h:28:5: internal compiler error: in build_vector_from_val, at tree.c:1386 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Preprocessed source code attached. Flag -O3 required.
[Bug c/52635] gcc fails to diagnose invalid type in unused sizeof() when optimizing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52635 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2012-03-20 18:06:33 UTC --- Not sure what kernel you are looking at, but in current kernel at least since 2009-09 BUILD_BUG_ON is BUILD_BUG_ON_ZERO and only MAYBE_BUILD_BUG_ON macro is using this sizeof and from the description it sounds like it wants the warnings only if the condition is known to be false already during parsing.
[Bug c/52639] New: ice in supportable_widening_operation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52639 Bug #: 52639 Summary: ice in supportable_widening_operation Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: dcb...@hotmail.com Created attachment 26934 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26934 C source code I just tried to compile the package mpfr-3.1.0 on gcc-4.8 trunk dated 20120319 on an AMD x86_64 box. The compiler said set_f.c: In function 'mpfr_set_f': set_f.c:27:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Here is a valgrind dump ==19223== Invalid read of size 8 ==19223==at 0xCC7B08: supportable_widening_operation(tree_code, gimple_statement_d*, tree_node*, tree_node*, tree_node**, tree_node**, tree_code*, tree_code*, int*, VEC_tree_heap**) (tree-vect-stmts.c:6096) ==19223==by 0x1082547: vect_recog_widen_mult_pattern(VEC_gimple_heap**, tree_node**, tree_node**) (tree-vect-patterns.c:664) ==19223==by 0x1087A57: vect_pattern_recog(_loop_vec_info*, _bb_vec_info*) (tree-vect-patterns.c:2553) ==19223==by 0xCEBA85: vect_slp_analyze_bb(basic_block_def*) (tree-vect-slp.c:2020) ==19223==by 0xCECA55: execute_vect_slp() (tree-vectorizer.c:265) ==19223==by 0xA52D6C: execute_one_pass(opt_pass*) (passes.c:2084) ==19223==by 0xA532E6: execute_pass_list(opt_pass*) (passes.c:2139) ==19223==by 0xB91E4D: tree_rest_of_compilation(tree_node*) (tree-optimize.c:422) ==19223==by 0x7EBD7D: cgraph_expand_function(cgraph_node*) (cgraphunit.c:1837) ==19223==by 0x7EFB4B: cgraph_optimize() (cgraphunit.c:1904) ==19223==by 0x7F01F9: cgraph_finalize_compilation_unit() (cgraphunit.c:1344) ==19223==by 0x5F3B1A: cp_write_global_declarations() (decl2.c:4074) ==19223== Address 0x10 is not stack'd, malloc'd or (recently) free'd Preprocessed source code attached. Flag -O3 required.
[Bug c/52640] New: performance bottleneck: gcc/tree.c;value_member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52640
Bug #: 52640
Summary: performance bottleneck: gcc/tree.c;value_member
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ncahill_...@yahoo.com
Created attachment 26935
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26935
source, output, profiling data indicating problem
It was made known to me that the code provided takes a long time to compile.
Looking into it, the culprit seems to be the value_member function of
gcc/tree.c. Here is that code (preprocessed):
tree value_member (tree elem, tree list)
{
while (list)
{
if (elem == ((list)-list.value))
return list;
list = ((list)-common.chain);
}
return (tree) ((void *)0);
}
A sample of profiling data, from OProfile and using gcc 4.6.2:
samples %image name symbol name
1995543.1814 cc1 value_member
1179 2.5513 cc1 record_reference
1122 2.4279 cc1 insert_aux
With a table of 1 rows, it takes ~40% of the execution time, and with
20 rows, ~90%. The former takes 5 seconds, the later is not finished in 20
minutes.
Provided is a sample source file with output from cc1 and profiling data as
above.
Thank you.
Neil.
[Bug tree-optimization/52636] [4.8 Regression] ICE: tree check: expected integer_cst, have string_cst in tree_to_double_int, at tree.h:4324
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52636 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-03-20 18:35:50 UTC --- The patch in comment #2 fixes the PR without side effect on the polyhedron test suite (AFAICT;-). Currently bootstrapping r185584, regtesting scheduled for tonight. Thanks for the quick fix.
[Bug c++/52639] ice in supportable_widening_operation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52639 dcb dcb314 at hotmail dot com changed: What|Removed |Added Component|c |c++ --- Comment #1 from dcb dcb314 at hotmail dot com 2012-03-20 18:50:21 UTC --- The source code is C++, not C. My mistake, sorry.
[Bug target/52607] v4df __builtin_shuffle with {0,2,1,3} or {1,3,0,2}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52607 --- Comment #15 from Marc Glisse marc.glisse at normalesup dot org 2012-03-20 19:00:32 UTC --- If I am not mistaken, the V8SF shuffle 22022246 is doable by a vperm2f128 that takes 01234567 to 01230123, followed by a vshufps (mask 138 maybe). Was your patch supposed to handle it?
[Bug target/52607] v4df __builtin_shuffle with {0,2,1,3} or {1,3,0,2}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52607 --- Comment #16 from Marc Glisse marc.glisse at normalesup dot org 2012-03-20 19:05:22 UTC --- (In reply to comment #15) If I am not mistaken, the V8SF shuffle 22022246 is doable by a vperm2f128 that takes 01234567 to 01230123, followed by a vshufps (mask 138 maybe). Was your patch supposed to handle it? Uh, no it isn't supposed to handle it (there would be redundancy and it wouldn't know where to take elements from), sorry, forget that comment.
[Bug c/52635] gcc fails to diagnose invalid type in unused sizeof() when optimizing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52635 --- Comment #5 from Mikael Pettersson mikpe at it dot uu.se 2012-03-20 19:09:01 UTC --- (In reply to comment #4) Not sure what kernel you are looking at, but in current kernel at least since 2009-09 BUILD_BUG_ON is BUILD_BUG_ON_ZERO and only MAYBE_BUILD_BUG_ON macro is using this sizeof and from the description it sounds like it wants the warnings only if the condition is known to be false already during parsing. I'm looking at the 3.3 kernel released only a few days ago. It's kernel.h doesn't define BUILD_BUG_ON in terms of BUILD_BUG_ON_ZERO (which perhaps it should be) and there is no MAYBE_BUILD_BUG_ON anywhere.
[Bug c++/52510] [4.8 regression] libitm/config/posix/rwlock.cc doesn't compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52510 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org 2012-03-20 19:14:33 UTC --- Author: jason Date: Tue Mar 20 19:14:29 2012 New Revision: 185587 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=185587 Log: PR c++/52510 * decl.c (reshape_init_class): Handle repeated reshaping. * search.c (lookup_field_1): Add sanity check. Added: trunk/gcc/testsuite/g++.dg/cpp0x/initlist66.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/cp/search.c trunk/gcc/testsuite/ChangeLog
[Bug testsuite/52641] New: Test cases fail for 16-bit int targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52641 Bug #: 52641 Summary: Test cases fail for 16-bit int targets Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassig...@gcc.gnu.org ReportedBy: g...@gcc.gnu.org Target: avr, m32c, m68k, stormy16, cr16, pdp11, h8300, rl78 Many test cases fail because they assume sizeof(int) = 4. This PR is not for one specific test case, it's to have a PR to file respective fixes as new test cases enter the test suite.
[Bug testsuite/52641] Test cases fail for 16-bit int targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52641 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P5 Status|UNCONFIRMED |NEW Last reconfirmed||2012-03-20 Ever Confirmed|0 |1 Severity|normal |minor
[Bug testsuite/52641] Test cases fail for 16-bit int targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52641 --- Comment #1 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-03-20 19:38:57 UTC --- Author: gjl Date: Tue Mar 20 19:38:51 2012 New Revision: 185588 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=185588 Log: PR testsuite/52641 * gcc.dg/torture/pr48124-1.c: Add dg-require-effective-target int32plus. * gcc.dg/torture/pr48124-4.c: Ditto: * gcc.dg/torture/pr52530.c: Use long instead of int if int=16. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/torture/pr48124-1.c trunk/gcc/testsuite/gcc.dg/torture/pr48124-4.c trunk/gcc/testsuite/gcc.dg/torture/pr52530.c
[Bug target/52642] New: SH Target: libstdc++ failures due to call insn swapped before prologue frame insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52642 Bug #: 52642 Summary: SH Target: libstdc++ failures due to call insn swapped before prologue frame insns Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: olege...@gcc.gnu.org CC: kkoj...@gcc.gnu.org Target: sh*-*-* Carry over from PR 51244 comment #33 ... Looking into the libstdc++ failures for sh4-unknown-linux-gnu, it seems that the call insn was swapped before prologue frame insns and then it makes unwinder confused. -fno-delayed-branch also stops that swapping for these failing cases. The patch below works for me. * config/sh/sh.c (sh_expand_prologue): Emit blockage at the end of prologue for unwinder and profiler. --- ORIG/trunk/gcc/config/sh/sh.c2012-03-06 10:28:32.0 +0900 +++ trunk/gcc/config/sh/sh.c2012-03-14 20:22:15.0 +0900 @@ -7234,6 +7234,13 @@ sh_expand_prologue (void) emit_insn (gen_shcompact_incoming_args ()); } + /* If we are profiling, make sure no instructions are scheduled before + the call to mcount. Similarly if some call instructions are swapped + before frame related insns, it'll make unwinder confused because + currently SH has no unwind info for function epilogues. */ + if (crtl-profile || flag_exceptions || flag_unwind_tables) +emit_insn (gen_blockage ()); + if (flag_stack_usage_info) current_function_static_stack_size = stack_usage; }
[Bug target/51244] SH Target: Inefficient conditional branch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244 --- Comment #36 from Oleg Endo olegendo at gcc dot gnu.org 2012-03-20 20:33:30 UTC --- I have created a new PR 52642 for the libstdc++ failures.
[Bug target/52642] SH Target: libstdc++ failures due to call insn swapped before prologue frame insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52642 Oleg Endo olegendo at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-03-20 Ever Confirmed|0 |1
[Bug c++/52643] New: Stack overflow ICE in cc1plus when templates, exceptions, and continue out of try used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52643 Bug #: 52643 Summary: Stack overflow ICE in cc1plus when templates, exceptions, and continue out of try used Classification: Unclassified Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: ak.mil...@auckland.ac.nz Created attachment 26936 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26936 Reduced testcase that crashes cc1plus The minimal testcase attached seems to trigger a stack overflow in cc1plus (confirmed on both x86_64 and MinGW x86). This doesn't seem to happen on any gcc 4.7 or 4.4 compilers I've tried, only the 4.6 series.
[Bug target/5360] [SH] Useless address inc-dec sequence for DFmode access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5360 Oleg Endo olegendo at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed|2004-01-01 21:00:39 |2012-03-20 CC||kkojima at gcc dot gnu.org Summary|[SH-4] NON_OPTIMAL CODE |[SH] Useless address |GENERATED FOR SH4 |inc-dec sequence for DFmode ||access --- Comment #5 from Oleg Endo olegendo at gcc dot gnu.org 2012-03-20 21:06:16 UTC --- As of rev 18 this issue can still be reproduced with -O3. It doesn't happen with -O2 though.
[Bug bootstrap/52644] New: RTL check: expected elt 1 type 'i' or 'n', have '0' (rtx reg) in ix86_decompose_address, at config/i386/i386.c:11522[4.8 Regression] ICE in stage2:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52644 Bug #: 52644 Summary: RTL check: expected elt 1 type 'i' or 'n', have '0' (rtx reg) in ix86_decompose_address, at config/i386/i386.c:11522[4.8 Regression] ICE in stage2: Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz This ICE happens probably only with RTL checking enabled. Compiler output: /mnt/svn/gcc-trunk/libgcc/unwind-dw2.c: In function 'execute_stack_op': /mnt/svn/gcc-trunk/libgcc/unwind-dw2.c:902:1: internal compiler error: RTL check: expected elt 1 type 'i' or 'n', have '0' (rtx reg) in ix86_decompose_address, at config/i386/i386.c:11522 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[5]: *** [unwind-dw2.o] Error 1 make[5]: *** Waiting for unfinished jobs /mnt/svn/gcc-trunk/libgcc/unwind-dw2-fde-dip.c: In function '_Unwind_IteratePhdrCallback': /mnt/svn/gcc-trunk/libgcc/unwind-dw2-fde-dip.c:432:1: internal compiler error: RTL check: expected elt 1 type 'i' or 'n', have '0' (rtx mem) in ix86_decompose_address, at config/i386/i386.c:11522 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. $ ./build-185559-lto-fortran-checking-yes-rtl-df/gcc/xgcc -v Using built-in specs. COLLECT_GCC=./build-185559-lto-fortran-checking-yes-rtl-df/gcc/xgcc Target: x86_64-unknown-linux-gnu Configured with: /mnt/svn/gcc-trunk//configure --enable-checking=yes,rtl,df --enable-languages=c,c++,lto,fortran --prefix=/mnt/svn/gcc-trunk/binary-185559-lto-fortran-checking-yes-rtl-df/ --with-cloog --with-ppl --with-cloog-include=/usr/include/cloog-ppl/ --disable-ppl-version-check Thread model: posix gcc version 4.8.0 20120320 (experimental) (GCC) Tested revisions: r185535 - OK r185545 - crash r185559 - crash
[Bug bootstrap/52644] RTL check: expected elt 1 type 'i' or 'n', have '0' (rtx reg) in ix86_decompose_address, at config/i386/i386.c:11522[4.8 Regression] ICE in stage2:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52644 --- Comment #1 from Zdenek Sojka zsojka at seznam dot cz 2012-03-20 21:42:26 UTC --- Created attachment 26937 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26937 preprocessed source $ /home/smatz/build-185559-lto-fortran-checking-yes-rtl-df/./gcc/xgcc -B/home/smatz/build-185559-lto-fortran-checking-yes-rtl-df/./gcc/ unwind-dw2.i -O -m32 -c -fpic /mnt/svn/gcc-trunk/libgcc/unwind-dw2.c: In function ‘execute_stack_op’: /mnt/svn/gcc-trunk/libgcc/unwind-dw2.c:902:1: internal compiler error: RTL check: expected elt 1 type 'i' or 'n', have '0' (rtx reg) in ix86_decompose_address, at config/i386/i386.c:11522 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug target/52607] v4df __builtin_shuffle with {0,2,1,3} or {1,3,0,2}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52607 Marc Glisse marc.glisse at normalesup dot org changed: What|Removed |Added Attachment #26912|0 |1 is obsolete|| --- Comment #17 from Marc Glisse marc.glisse at normalesup dot org 2012-03-20 21:50:40 UTC --- Created attachment 26938 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26938 intra-lane shuffle in 3 insn This (mostly untested) patch is a reformulation of the generic v8sf single vector shuffle in 4 insn as a generic intra-lane 2 vector shuffle in at most 3 insn. Reformulating __builtin_shuffle(x,m) as __builtin_shuffle(x,vperm2f128(x,1),mm) would then guarantee a maximum size of 4. Note that the strategy of doing a 2-vector shuffle by shuffling (not restricted to one vpermilp*) each vector and blending the results gives a maximum of 9 insn, whereas the current code often generates twice that number. By the way, I have trouble understanding this comment: /* For d-op0 == d-op1 the only useful vperm2f128 permutation is 0x10. */ Is it really 0x10, or is there a stray 0 at the end and it is really just 1?
[Bug middle-end/51893] Wrong subword index computation in store_bit_field_1 on BIG_ENDIAN targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51893 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW --- Comment #10 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-03-20 22:03:27 UTC --- Do you need additional information about this bug? Any comment about the provided patch? No, I think the patch is correct. Please post it on gcc-patches@.
[Bug c++/52595] [DR 325] commas and non-static data member initializers don't mix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52595 --- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org 2012-03-20 23:00:19 UTC --- (In reply to comment #3) So, what's going on? Was the commit for PR51666 incomplete, so to speak? Maybe it was incomplete but then again the Defect report is still open though there has been some changes to the dr about the change and such.
