[Bug tree-optimization/51990] New: ICE in copy_reference_ops_from_ref
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51990
Bug #: 51990
Summary: ICE in copy_reference_ops_from_ref
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vr...@gcc.gnu.org
example test.c, based on gcc.c-torture/compile/20030224-1.c. Added pure to foo
and used result of foo to trigger visit_reference_op_call:
...
int
zzz (char *s1, char *s2, int len, int *q)
{
int z = 5;
unsigned int i, b;
struct s { char a[z]; };
struct s x;
extern int foo (struct s, struct s) __attribute__((pure));
for (i = 0; i < len; i++)
s1[i] = s2[i];
b = z & 0x3;
len += (b == 0 ? 0 : 1) + z;
*q = len;
return foo (x, x);
}
...
compile ICEs with trunk r183325:
...
$ gcc -O2 test.c -S
test.c: In function ‘zzz’:
test.c:21:1: internal compiler error: in copy_reference_ops_from_ref, at
tree-ssa-sccvn.c:738
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
...
backtrace:
...
(gdb) bt
#0 exit (status=4) at exit.c:49
#1 0x01f15ebb in diagnostic_action_after_output (context=0x2730620,
diagnostic=0x7fffd3e0) at /home/vries/devel/src/gcc/diagnostic.c:243
#2 0x01f16d8d in diagnostic_report_diagnostic (context=0x2730620,
diagnostic=0x7fffd3e0) at /home/vries/devel/src/gcc/diagnostic.c:552
#3 0x01f17dac in internal_error (gmsgid=0x225a7a7 "in %s, at %s:%d")
at /home/vries/devel/src/gcc/diagnostic.c:845
#4 0x01f17f34 in fancy_abort (file=0x2043eb0
"/home/vries/devel/src/gcc/tree-ssa-sccvn.c", line=738, function=0x2045000
"copy_reference_ops_from_ref") at /home/vries/devel/src/gcc/diagnostic.c:899
#5 0x00ef9dd8 in copy_reference_ops_from_ref (ref=0x7565eba0,
result=0x271b1d8) at /home/vries/devel/src/gcc/tree-ssa-sccvn.c:738
#6 0x00efaae1 in copy_reference_ops_from_call (call=0x7554a720,
result=0x271b1d8) at /home/vries/devel/src/gcc/tree-ssa-sccvn.c:951
#7 0x00efc906 in valueize_shared_reference_ops_from_call
(call=0x7554a720) at /home/vries/devel/src/gcc/tree-ssa-sccvn.c:1272
#8 0x00f018b4 in visit_reference_op_call (lhs=0x75664a00,
stmt=0x7554a720) at /home/vries/devel/src/gcc/tree-ssa-sccvn.c:2596
#9 0x00f04359 in visit_use (use=0x75664a00) at
/home/vries/devel/src/gcc/tree-ssa-sccvn.c:3364
#10 0x00f04b5f in process_scc (scc=0x27493f0) at
/home/vries/devel/src/gcc/tree-ssa-sccvn.c:3505
#11 0x00f052a0 in extract_and_process_scc_for_name
(name=0x75664a00) at /home/vries/devel/src/gcc/tree-ssa-sccvn.c:3589
#12 0x00f05466 in DFS (name=0x75664a00) at
/home/vries/devel/src/gcc/tree-ssa-sccvn.c:3643
#13 0x00f06028 in run_scc_vn (default_vn_walk_kind_=VN_WALKREWRITE) at
/home/vries/devel/src/gcc/tree-ssa-sccvn.c:3892
#14 0x00ee1f38 in execute_pre (do_fre=1 '\001') at
/home/vries/devel/src/gcc/tree-ssa-pre.c:4870
#15 0x00ee2192 in execute_fre () at
/home/vries/devel/src/gcc/tree-ssa-pre.c:4988
...
Cause of ICE: unhandled WITH_SIZE_EXPR in switch (temp.opcode):
...
#5 0x00ef9dd8 in copy_reference_ops_from_ref (ref=0x7565eba0,
result=0x271b1d8) at /home/vries/devel/src/gcc/tree-ssa-sccvn.c:738
738 gcc_unreachable ();
(gdb) call debug_generic_expr (ref)
WITH_SIZE_EXPR <*x.1_20, 5>
...
20030224-1.c.027t.esra (dump before 20030224-1.c.028t.fre1):
...
zzz (char * s1, char * s2, int len, int * q)
{
D.1744[5];
unsigned int i;
void * saved_stack.4;
int D.1739;
unsigned int len.2;
char D.1733;
char * D.1732;
char * D.1731;
sizetype D.1730;
struct s * x.1;
sizetype D.1724;
:
saved_stack.4_2 = __builtin_stack_save ();
D.1724_19 = 5;
x.1_20 = &D.1744;
i_21 = 0;
goto ;
:
D.1730_24 = (sizetype) i_1;
D.1731_26 = s1_25(D) + D.1730_24;
D.1730_27 = (sizetype) i_1;
D.1732_29 = s2_28(D) + D.1730_27;
D.1733_30 = *D.1732_29;
*D.1731_26 = D.1733_30;
i_31 = i_1 + 1;
:
# i_1 = PHI <0(2), i_31(3)>
len.2_23 = (unsigned int) len_22(D);
if (len.2_23 > i_1)
goto ;
else
goto ;
:
len_37 = len_22(D) + 6;
*q_38(D) = len_37;
D.1739_39 = foo (WITH_SIZE_EXPR <*x.1_20, 5>, WITH_SIZE_EXPR <*x.1_20, 5>);
D.1744 ={v} {CLOBBER};
__builtin_stack_restore (saved_stack.4_2);
return D.1739_39;
}
...
[Bug fortran/51966] [4.6/4.7 Regression] ICE in gfc_conv_array_constructor_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51966 --- Comment #6 from Tobias Burnus 2012-01-25 06:59:25 UTC --- Author: burnus Date: Wed Jan 25 06:59:21 2012 New Revision: 183510 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183510 Log: 2012-01-24 Tobias Burnus PR fortran/51966 * resolve.c (resolve_structure_cons): Only create an array constructors for nonscalars. 2012-01-24 Tobias Burnus PR fortran/51966 * gfortran.dg/derived_constructor_char_3.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/derived_constructor_char_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug c++/51989] std::deque::iterator recognised as container
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51989 --- Comment #3 from Leonid Volnitsky 2012-01-25 05:04:56 UTC --- Created attachment 26453 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26453 gcc error
[Bug c++/51989] std::deque::iterator recognised as container
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51989 --- Comment #2 from Leonid Volnitsky 2012-01-25 05:04:00 UTC --- Created attachment 26452 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26452 deque-bug.s
[Bug c++/51989] std::deque::iterator recognised as container
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51989 --- Comment #1 from Leonid Volnitsky 2012-01-25 05:03:14 UTC --- Created attachment 26451 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26451 deque-bug.ii
[Bug c++/51989] New: std::deque::iterator recognised as container
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51989
Bug #: 51989
Summary: std::deque::iterator recognised as container
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: leo...@volnitsky.com
Created attachment 26450
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26450
deque-bug.cc
I need is_container template which would recognize if T is a container.
Code below works as expected. With exception for std::deque::iterator - gcc
can not compile code below:
--
#include
#include
#include
#include
#include
#include
template
struct is_container {
template
static char test(
U* u,
typename U::const_iterator b = ((U*)0)->begin(),
typename U::const_iterator e = ((U*)0)->end()
);
template static long test(...);
enum { value = sizeof test(0) == 1 };
};
int main() {
std::cout << "void\t"<< is_container< void
>::value << '\n';
std::cout << "int\t"<< is_container< int >::value
<< '\n';
std::cout << "int*\t"<< is_container< int*
>::value << '\n';
std::cout << "vector\t"<< is_container< std::vector
>::value << '\n';
std::cout << "deque\t"<< is_container< std::deque
>::value << '\n';
std::cout << "set::iterator\t"<< is_container<
std::set::iterator >::value << '\n';
std::cout << "vector::iterator\t"<< is_container<
std::vector::iterator >::value << '\n';
// gcc error
std::cout << "deque::iterator\t"<< is_container<
std::deque::iterator >::value << '\n';
}
---
Compiling it with GCC (4.7.0-alpha20111203):
gcc -std=gnu++0x -Wall deque-bug.cc -o deque-bug
Produce following error:
deque-bug.cc: In instantiation of ‘struct
is_container >’:
deque-bug.cc:31:84: required from here
deque-bug.cc:18:7: error: ‘struct std::_Deque_iterator’ has no
member named ‘begin’
deque-bug.cc:18:7: error: ‘struct std::_Deque_iterator’ has no
member named ‘end’
Attached are source and -save-temps
[Bug c++/51917] [4.7 regression] g++.old-deja/g++.abi/vmihint.C FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51917 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Jason Merrill 2012-01-25 04:41:59 UTC --- Fixed.
[Bug c++/51917] [4.7 regression] g++.old-deja/g++.abi/vmihint.C FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51917 --- Comment #3 from Jason Merrill 2012-01-25 04:39:59 UTC --- Author: jason Date: Wed Jan 25 04:39:52 2012 New Revision: 183509 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183509 Log: PR c++/51917 * decl.c (xref_basetypes): Check VEC_length instead of VEC_space. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c
[Bug c++/51917] [4.7 regression] g++.old-deja/g++.abi/vmihint.C FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51917 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org |
[Bug c++/51370] [4.6/4.7 Regression] ICE with invalid template parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51370 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com --- Comment #3 from Paolo Carlini 2012-01-25 02:26:04 UTC --- Mine.
[Bug c++/51370] [4.6/4.7 Regression] ICE with invalid template parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51370 --- Comment #2 from Paolo Carlini 2012-01-25 02:05:19 UTC --- In mainline the second snippet doesn't ICE anymore.
[Bug tree-optimization/51988] value_replacement in PHIOPT should handle even the cases where there are other PHIs even with non equal value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51988
--- Comment #6 from Andrew Pinski 2012-01-25
00:58:45 UTC ---
I have a patch which fixes the testcases in comment #3 and comment #5. The
testcase in comment #0 will be fixed with the patch in
http://gcc.gnu.org/ml/gcc-patches/2012-01/msg01195.html and this new patch.
Here is a testcase which still cannot be done with the other patch:
int g(int,int);
int f(int t, int c)
{
int d = 0;
int e = 0;
if (t)
{
d = t;
if (c) e = 3;
}
else d = 0, e = 0;
return g(d,e);
}
--- CUT ---
I am going to submit the current patch after testing and leave this bug report
open for the above testcase (since the first one is fixed as the patch I
reference here is approved).
[Bug tree-optimization/51988] value_replacement in PHIOPT should handle even the cases where there are other PHIs even with non equal value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51988
--- Comment #5 from Andrew Pinski 2012-01-25
00:45:37 UTC ---
Here is another testcase which also fails:
int g(int,int);
int f(int t, int c)
{
int d = 0;
int e = 0;
if (t)
{
d = c+1;
e = t;
}
else d = 0, e = 0;
return g(d,e);
}
[Bug tree-optimization/51988] value_replacement in PHIOPT should handle even the cases where there are other PHIs even with non equal value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51988 --- Comment #4 from Andrew Pinski 2012-01-25 00:26:41 UTC --- The first testcase is still valid but is not handled currently without some changes dealing with how PHI-OPT works which I am fixing right now.
[Bug tree-optimization/51988] value_replacement in PHIOPT should handle even the cases where there are other PHIs even with non equal value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51988
--- Comment #3 from Andrew Pinski 2012-01-25
00:24:41 UTC ---
Here is a better testcase:
int g(int,int);
int f(int t, int c)
{
int d = 0;
int e = 0;
if (t)
{
d = 1;
e = t;
}
else d = 0, e = 0;
return g(d,e);
}
--- CUT ---
I have a simple patch now.
[Bug tree-optimization/51988] value_replacement in PHIOPT should handle even the cases where there are other PHIs even with non equal value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51988 --- Comment #2 from Andrew Pinski 2012-01-25 00:04:01 UTC --- Note this is like http://gcc.gnu.org/ml/gcc-patches/2012-01/msg01195.html but different as we should do this even if the arguments for the other PHIs are non equal.
[Bug tree-optimization/51988] value_replacement in PHIOPT should handle even the cases where there are other PHIs even with non equal value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51988 Andrew Pinski changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug tree-optimization/51988] value_replacement in PHIOPT should handle even the cases where there are other PHIs even with non equal value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51988 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-01-25 AssignedTo|unassigned at gcc dot |pinskia at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Andrew Pinski 2012-01-25 00:02:18 UTC --- I am working on this, I don't have a patch yet though.
[Bug tree-optimization/51988] New: value_replacement in PHIOPT should handle even the cases where there are other PHIs even with non equal value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51988
Bug #: 51988
Summary: value_replacement in PHIOPT should handle even the
cases where there are other PHIs even with non equal
value
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:
int g(int,int);
int f(int t, int c)
{
int d = 0;
int e = 0;
if (t)
{
d = t;
if (c) e = 1;
}
else d = 0, e = 0;
return g(d,e);
}
--- CUT ---
Currently we get:
:
if (t_5(D) != 0)
goto ;
else
goto ;
:
if (c_7(D) != 0)
goto ;
else
goto ;
:
:
# d_1 = PHI
# e_2 = PHI <3(4), 0(2), 0(3)>
But we could reduce it down to:
:
if (t_5(D) != 0)
goto ;
else
goto ;
:
if (c_7(D) != 0)
goto ;
else
goto ;
:
:
# d_1 = PHI
# e_2 = PHI <3(4), 0(2), 0(3)>
As t_5 on the edge from bb 2 to bb 5, t_5 is 0.
[Bug bootstrap/51985] [4.7 Regression] Bootstrap failure at revision 183497 on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51985 --- Comment #2 from Dominique d'Humieres 2012-01-24 23:16:45 UTC --- Looking at the log, I see copying selected object files to avoid basename conflicts... <--- :-( copying selected object files to avoid basename conflicts... libtool: link: ln allocator-inst.o .libs/libc++98convenience.lax/lt1-allocator-inst.o || cp allocator-inst.o .libs/libc++98convenience.lax/lt1-allocat or-inst.o libtool: link: ln concept-inst.o .libs/libc++98convenience.lax/lt2-concept-inst.o || cp concept-inst.o .libs/libc++98convenience.lax/lt2-concept-inst. o libtool: link: ln ext-inst.o .libs/libc++98convenience.lax/lt3-ext-inst.o || cp ext-inst.o .libs/libc++98convenience.lax/lt3-ext-inst.o libtool: link: ln ios-inst.o .libs/libc++98convenience.lax/lt4-ios-inst.o || cp ios-inst.o .libs/libc++98convenience.lax/lt4-ios-inst.olibtool: link: ln iostream-inst.o .libs/libc++98convenience.lax/lt5-iostream-inst.o || cp iostream-inst.o .libs/libc++98convenience.lax/lt5-iostream-inst.olibtool: link: ln allocator-inst.o .libs/libc++98.lax/lt1-allocator-inst.o || cp allocator-inst.o .libs/libc++98.lax/lt1-allocator-inst.olibtool: link: ln istream-inst.o .libs/libc++98convenience.lax/lt6-istream-inst.o || cp istream-inst.o .libs/libc++98convenience.lax/lt6-istream-inst.olibtool: link: ln concept-inst.o .libs/libc++98.lax/lt2-concept-inst.o || cp concept-inst.o .libs/libc++98.lax/lt2-concept-inst.olibtool: link: ln locale-inst.o .libs/libc++98convenience.lax/lt7-locale-inst.o || cp locale-inst.o .libs/libc++98convenience.lax/lt7-locale-inst.olibtool: link: ln ext-inst.o .libs/libc++98.lax/lt3-ext-inst.o || cp ext-inst.o .libs/libc++98.lax/lt3-ext-inst.olibtool: link: ln misc-inst.o .libs/libc++98convenience.lax/lt8-misc-inst.o || cp misc-inst.o .libs/libc++98convenience.lax/lt8-misc-inst.olibtool: link: ln ios-inst.o .libs/libc++98.lax/lt4-ios-inst.o || cp ios-inst.o .libs/libc++98.lax/lt4-ios-inst.o libtool: link: ln ostream-inst.o .libs/libc++98convenience.lax/lt9-ostream-inst.o || cp ostream-inst.o .libs/libc++98convenience.lax/lt9-ostream-inst. o libtool: link: ln iostream-inst.o .libs/libc++98.lax/lt5-iostream-inst.o || cp iostream-inst.o .libs/libc++98.lax/lt5-iostream-inst.o libtool: link: ln sstream-inst.o .libs/libc++98convenience.lax/lt10-sstream-inst.o || cp sstream-inst.o .libs/libc++98convenience.lax/lt10-sstream-inst.olibtool: link: ln istream-inst.o .libs/libc++98.lax/lt6-istream-inst.o || cp istream-inst.o .libs/libc++98.lax/lt6-istream-inst.olibtool: link: ln streambuf-inst.o .libs/libc++98convenience.lax/lt11-streambuf-inst.o || cp streambuf-inst.o .libs/libc++98convenience.lax/lt11-streambuf-inst.olibtool: link: ln locale-inst.o .libs/libc++98.lax/lt7-locale-inst.o || cp locale-inst.o .libs/libc++98.lax/lt7-locale-inst.olibtool: link: ln wlocale-inst.o .libs/libc++98convenience.lax/lt12-wlocale-inst.o || cp wlocale-inst.o .libs/libc++98convenience.lax/lt12-wlocale-inst.olibtool: link: ln misc-inst.o .libs/libc++98.lax/lt8-misc-inst.o || cp misc-inst.o .libs/libc++98.lax/lt8-misc-inst.olibtool: link: ln ostream-inst.o .libs/libc++98.lax/lt9-ostream-inst.o || cp ostream-inst.o .libs/libc++98.lax/lt9-ostream-inst.o libtool: link: ar rc .libs/libc++98convenience.a bitmap_allocator.o pool_allocator.o mt_allocator.o codecvt.o compatibility.o compatibility-debug_list.o compatibility-debug_list-2.o compatibility-list.o compatibility-list-2.o complex_io.o ctype.o globals_io.o hash_tr1.o hashtable_tr1.o ios.o ios_failure.o ios_init.o ios_locale.o list.o locale.o locale_init.o locale_facets.o localename.o math_stubs_float.o math_stubs_long_double.o stdexcept.o strstream.o tree.o istream.o streambuf.o valarray.o atomicity.o codecvt_members.o collate_members.o ctype_configure_char.o ctype_members.o messages_members.o monetary_members.o numeric_members.o time_members.o basic_file.o c++locale.o allocator-inst.o concept-inst.o ext-inst.o ios-inst.o iostream-inst.o istream-inst.o locale-inst.o misc-inst.o ostream-inst.o sstream-inst.o streambuf-inst.o wlocale-inst.o parallel_settings.o compatibility-parallel_list.o compatibility-parallel_list-2.o .libs/libc++98convenience.lax/lt1-allocator-inst.o .libs/libc++98convenience.lax/lt2-concept-inst.o .libs/libc++98convenience.lax/lt3-ext-inst.o .libs/libc++98convenience.lax/lt4-ios-inst.o .libs/libc++98convenience.lax/lt5-iostream-inst.o .libs/libc++98convenience.lax/lt6-istream-inst.o .libs/libc++98convenience.lax/lt7-locale-inst.o .libs/libc++98convenience.lax/lt8-misc-inst.o .libs/libc++98convenience.lax/lt9-ostream-inst.o .libs/libc++98convenience.lax/lt10-sstream-inst.o .libs/libc++98convenience.lax/lt11-streambuf-inst.o .libs/libc++98convenience.lax/lt12-wlocale-inst.o
[Bug libstdc++/51981] Missing uninitialized_move() implementation?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51981 Marc Glisse changed: What|Removed |Added CC||marc.glisse at normalesup ||dot org --- Comment #2 from Marc Glisse 2012-01-24 23:01:09 UTC --- It looks like it would be equivalent to uninitialized_copy with make_move_iterator, not so useful then.
[Bug target/43311] missed 'movw' optimization.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43311 --- Comment #2 from Andrew Pinski 2012-01-24 22:52:54 UTC --- This is dup of the merge loads from two adjacent memory location into one load bug. Which I don't remember the number of the bug right now.
[Bug bootstrap/51985] [4.7 Regression] Bootstrap failure at revision 183497 on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51985 Dominique d'Humieres changed: What|Removed |Added Target||x86_64-apple-darwin10 CC||bkoz at redhat dot com Host||x86_64-apple-darwin10 Build||x86_64-apple-darwin10 --- Comment #1 from Dominique d'Humieres 2012-01-24 22:40:55 UTC --- Likely due to revision 183457.
[Bug tree-optimization/51987] [4.7 Regression] Predictive commoning wrong-code with non-volatile asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51987 --- Comment #1 from Jakub Jelinek 2012-01-24 22:40:11 UTC --- Created attachment 26449 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26449 gcc47-pr51987.patch Untested fix.
[Bug fortran/51970] [OOP] gimplification failed for polymorphic MOVE_ALLOC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51970 --- Comment #4 from Dominique d'Humieres 2012-01-24 22:35:43 UTC --- The patch attached to comment #4 + the "hack" let the test compile without error (although I don't know if it is valid). I have noticed the following changes: For 51948, before the patch I had two errors [macbook] f90/bug% gfc pr51948.f90 pr51948.f90:14.24: call move_alloc (x, func) 1 Error: 'to' argument of 'move_alloc' intrinsic at (1) must be a variable pr51948.f90:7.24: call move_alloc (x, func) 1 Error: the 'from' and 'to' arguments of 'move_alloc' intrinsic at (1) must have the same rank 0/1 After the patch I have only one [macbook] f90/bug% gfc pr51948.f90 pr51948.f90:14.24: call move_alloc (x, func) 1 Error: 'to' argument of 'move_alloc' intrinsic at (1) must be a variable For another avatar and the test in pr51977, the error is replaced by an ICE: before the patch [macbook] f90/bug% gfc pr51948_db_1.f90 pr51948_db_1.f90:7.24: call move_alloc (x, func) 1 Error: the 'from' and 'to' arguments of 'move_alloc' intrinsic at (1) must have the same rank 0/1 after the patch [macbook] f90/bug% gfc pr51948_db_1.f90 pr51948_db_1.f90: In function 'func': pr51948_db_1.f90:9:0: internal compiler error: in fold_convert_loc, at fold-const.c:2016
[Bug tree-optimization/51987] [4.7 Regression] Predictive commoning wrong-code with non-volatile asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51987 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-01-24 Target Milestone|--- |4.7.0 Ever Confirmed|0 |1
[Bug tree-optimization/51987] New: [4.7 Regression] Predictive commoning wrong-code with non-volatile asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51987
Bug #: 51987
Summary: [4.7 Regression] Predictive commoning wrong-code with
non-volatile asm
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: ja...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
On s390 (31-bit) gcc 4.7 miscompiles _itoa.o and _itoa.os in glibc (which leads
to e.g. cc1 itself when using that glibc to crash on startup).
Here is a reduced testcase (for x86_64):
extern void abort (void);
union U { unsigned long l; struct { unsigned int l, h; } i; };
__attribute__((noinline, noclone)) void
foo (char *x, char *y)
{
int i;
for (i = 0; i < 64; i++)
{
union U u;
asm ("movl %1, %k0; salq $32, %0" : "=r" (u.l) : "r" (i));
x[i] = u.i.h;
union U v;
asm ("movl %1, %k0; salq $32, %0" : "=r" (v.l) : "r" (i));
y[i] = v.i.h;
}
}
int
main ()
{
char a[64], b[64];
int i;
foo (a, b);
for (i = 0; i < 64; i++)
if (a[i] != i || b[i] != i)
abort ();
return 0;
}
This is miscompiled at -O3, predictive commoning ignores the references in the
inline-asm and happily moves loads of u.i.h and v.i.h before the loop, even
when it is initialized only by the inline asm inside of the loop.
The problem is that tree-data-ref.c (get_references_in_stmt) gives up on
GIMPLE_ASM only if it is volatile, and for non-volatile GIMPLE_ASM it just
(incorrectly) assumes it doesn't have any references.
[Bug middle-end/51986] [4.7 regression] uninitialized variable warning regression prevents bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51986 --- Comment #1 from Matt Hargett 2012-01-24 22:31:05 UTC --- Created attachment 26448 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26448 pre-processed source of the file that triggers the regression
[Bug middle-end/51986] New: [4.7 regression] uninitialized variable warning regression prevents bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51986 Bug #: 51986 Summary: [4.7 regression] uninitialized variable warning regression prevents bootstrap Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: m...@use.net This just started in the last few days: /tmp/gcc-obj/./prev-gcc/g++ -B/tmp/gcc-obj/./prev-gcc/ -B/home/matt/x86_64-unknown-linux-gnu/bin/ -nostdinc++ -B/tmp/gcc-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/tmp/gcc-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -I/tmp/gcc-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/tmp/gcc-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include -I/home/matt/src/gcc-4.7.0/libstdc++-v3/libsupc++ -L/tmp/gcc-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/tmp/gcc-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -c -g -O2 -flto=jobserver -frandom-seed=1 -O2 -finline-functions -funswitch-loops -fpredictive-commoning -fgcse-after-reload -ftree-vectorize -ffast-math -floop-interchange -floop-strip-mine -floop-block -ftree-loop-distribution -ftree-loop-distribute-patterns -ftree-loop-im -ftree-loop-ivcanon -fivopts -fweb -DIN_GCC -fno-exceptions -fno-rtti -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I/home/matt/src/gcc-4.7.0/gcc -I/home/matt/src/gcc-4.7.0/gcc/. -I/home/matt/src/gcc-4.7.0/gcc/../include -I/home/matt/src/gcc-4.7.0/gcc/../libcpp/include -I/home/matt/src/gcc-4.7.0/gcc/../libdecnumber -I/home/matt/src/gcc-4.7.0/gcc/../libdecnumber/bid -I../libdecnumber /home/matt/src/gcc-4.7.0/gcc/sched-deps.c -o sched-deps.o /home/matt/src/gcc-4.7.0/gcc/sched-deps.c: In function ‘sched_get_condition_with_rev(rtx_def const*, bool*)’: /home/matt/src/gcc-4.7.0/gcc/sched-deps.c:599:33: error: ‘tmp’ may be used uninitialized in this function [-Werror=maybe-uninitialized] Verified that it is a false positive, as sched_get_condition_with_rev_uncached() always sets the contents of the bool in question (if it isn't NULL, and it isn't in this case). Can be reduced to -O2 -finline-functions, which probably isn't getting tested much since using the bootstrap-O3 config has been broken for months now. Pre-processed sources are attached.
[Bug bootstrap/51985] New: [4.7 Regression] Bootstrap failure at revision 183497 on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51985 Bug #: 51985 Summary: [4.7 Regression] Bootstrap failure at revision 183497 on x86_64-apple-darwin10 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr Bootstrapping revision 183497 on x86_64-apple-darwin10 fails with libtool: link: /opt/gcc/build_w/./gcc/xgcc -shared-libgcc -B/opt/gcc/build_w/./gcc -nostdinc++ -L/opt/gcc/build_w/x86_64-apple-darwin10.8.0/libstdc++-v3/src -L/opt/gcc/build_w/x86_64-apple-darwin10.8.0/libstdc++-v3/src/.libs -B/opt/gcc/gcc4.7w/x86_64-apple-darwin10.8.0/bin/ -B/opt/gcc/gcc4.7w/x86_64-apple-darwin10.8.0/lib/ -isystem /opt/gcc/gcc4.7w/x86_64-apple-darwin10.8.0/include -isystem /opt/gcc/gcc4.7w/x86_64-apple-darwin10.8.0/sys-include-dynamiclib -Wl,-undefined -Wl,dynamic_lookup -o .libs/libstdc++.6.dylib -Wl,-force_load,../libsupc++/.libs/libsupc++convenience.a -Wl,-force_load,../src/c++98/.libs/libc++98convenience.a -Wl,-force_load,../src/c++11/.libs/libc++11convenience.a -L/opt/gcc/build_w/x86_64-apple-darwin10.8.0/libstdc++-v3/src -L/opt/gcc/build_w/x86_64-apple-darwin10.8.0/libstdc++-v3/src/.libs -lm -Wl,-single_module -Wl,-exported_symbols_list -Wl,libstdc++-symbols.explist -install_name /opt/gcc/gcc4.7w/lib/libstdc++.6.dylib -compatibility_version 7 -current_version 7.17 -Wl,-single_module ld: duplicate symbol std::allocator::allocator() in ../src/c++98/.libs/libc++98convenience.a(lt1-allocator-inst.o) and ../src/c++98/.libs/libc++98convenience.a(allocator-inst.o) collect2: error: ld returned 1 exit status
[Bug middle-end/51984] ICE: SIGSEGV with -O2 -fgraphite-identity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51984 --- Comment #1 from Marcin Baczynski 2012-01-24 22:00:18 UTC --- Created attachment 26447 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26447 Reduced test case.
[Bug middle-end/51984] New: ICE: SIGSEGV with -O2 -fgraphite-identity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51984 Bug #: 51984 Summary: ICE: SIGSEGV with -O2 -fgraphite-identity Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: marb...@gmail.com With SVN rev 183488 I get the following ICE on attached code: ~ # LC_ALL=C gcc -O2 -fgraphite-identity -c ~/bug.c -o /tmp/bug.o /root/bug.c: In function 'pack_states': /root/bug.c:8: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. ~ # gcc -v Using built-in specs. COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.7.0-svn-183488-20120124/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.7.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-trunk/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.7.0-svn-183488-20120124 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0-svn-183488-20120124/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.7.0-svn-183488-20120124 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.7.0-svn-183488-20120124/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.7.0-svn-183488-20120124/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0-svn-183488-20120124/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --with-ppl --with-cloog --disable-ppl-version-check --with-cloog-include=/usr/include/cloog-ppl --enable-lto --enable-nls --without-included-gettext --with-system-zlib --disable-werror --enable-secureplt --disable-multilib --enable-libmudflap --enable-libssp --enable-libgomp --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.7.0-svn-183488-20120124/python --enable-checking=assert,fold,gc,misc,rtlflag,runtime,tree --disable-libgcj --disable-libquadmath --enable-languages=c,c++ --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-targets=all --with-pkgversion='svn 183488-20120124' --enable-build-with-cxx Thread model: posix
[Bug gcov-profile/51975] ICE in gcc in convert_move, at expr.c:326 with fprofile-use when source changes from fprofile-generate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51975 asharif at gcc dot gnu.org changed: What|Removed |Added Attachment #26445|0 |1 is obsolete|| --- Comment #3 from asharif at gcc dot gnu.org 2012-01-24 20:10:21 UTC --- Created attachment 26446 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26446 Proposed fix.
[Bug gcov-profile/51975] ICE in gcc in convert_move, at expr.c:326 with fprofile-use when source changes from fprofile-generate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51975 asharif at gcc dot gnu.org changed: What|Removed |Added Attachment #26439|0 |1 is obsolete|| --- Comment #2 from asharif at gcc dot gnu.org 2012-01-24 20:01:45 UTC --- Created attachment 26445 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26445 Proposed fix. Reused the counts_hash table.
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246 --- Comment #8 from Andrew Pinski 2012-01-24 19:48:16 UTC --- *** Bug 41895 has been marked as a duplicate of this bug. ***
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246 Andrew Pinski changed: What|Removed |Added CC||Greta.Yorsh at arm dot com --- Comment #9 from Andrew Pinski 2012-01-24 19:48:24 UTC --- *** Bug 51983 has been marked as a duplicate of this bug. ***
[Bug c/51983] Wrong line number in an uninitialized variable warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51983 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Andrew Pinski 2012-01-24 19:48:24 UTC --- Dup of bug 39246. *** This bug has been marked as a duplicate of bug 39246 ***
[Bug middle-end/41895] _Complex return type changes line numbers in diagnostics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41895 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #2 from Andrew Pinski 2012-01-24 19:48:16 UTC --- Dup of bug 39246. *** This bug has been marked as a duplicate of bug 39246 ***
[Bug c/51983] New: Wrong line number in an uninitialized variable warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51983
Bug #: 51983
Summary: Wrong line number in an uninitialized variable warning
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: greta.yo...@arm.com
CC: ram...@gcc.gnu.org
For uninitialized variables of type _Complex, arm and x86 compilers report
different line numbers in warning messages:
* if only the real part of a complex variable is uninitialized, arm compiler
reports the line number where the variable is declared.
* if only the imaginary part of a complex variable is uninitialized, arm
compiler reports the line number where the variable is used.
* if only one of the parts of a complex variable is uninitialized, x86 compiler
reports the line where the other part is initialized.
* if both parts of a complex variable are uninitialized, both arm and x86
compilers (correctly) report the line where the variable is used.
This behaviour causes a failure in gcc.dg/uninit-13.c test on arm target.
Note that in this test, dg-warning directive expects the warning message about
uninitialized variable to report the line in which the imaginary part of the
complex variable is initialized, and not the line where the uninitialized
variable is used. That is, the test passes on x86 target, even thought the line
number in the message is not what one would (perhaps naively) expect, based on
the behaviour of the compiler for other types of uninitialized variables.
I don't know if the problem is in the frontend, middle-end, target, or
testsuite.
$ cat -n /work/tmp/unin1.c
1typedef _Complex float C;
2C foo(int *p)
3{
4 C f;
5 int a = *p;
6 *p = 42 * a;
7 __imag__ f = 0;
8 return f;
9}
$ arm-none-eabi-gcc -O -Wuninitialized -S-o tmp.s /work/tmp/unin1.c
/work/tmp/unin1.c: In function 'foo':
/work/tmp/unin1.c:4:5: warning: '__real__ f' is used uninitialized in this
function [-Wuninitialized]
$ gcc -O -Wuninitialized -S-o tmp.s /work/tmp/unin1.c
/work/tmp/unin1.c: In function ‘foo’:
/work/tmp/unin1.c:7: warning: ‘__real__ f’ is used uninitialized in this
function
$ cat -n /work/tmp/unin2.c
1typedef _Complex float C;
2C foo(int *p)
3{
4 C f;
5 int a = *p;
6 *p = 42 * a;
7 __real__ f = 0;
8 return f;
9}
$ arm-none-eabi-gcc -O -Wuninitialized -S-o tmp.s /work/tmp/unin2.c
/work/tmp/unin2.c: In function 'foo':
/work/tmp/unin2.c:8:3: warning: '__imag__ f' is used uninitialized in this
function [-Wuninitialized]
$ gcc -O -Wuninitialized -S-o tmp.s /work/tmp/unin2.c
/work/tmp/unin2.c: In function ‘foo’:
/work/tmp/unin2.c:7: warning: ‘__imag__ f’ is used uninitialized in this
function
$ cat -n /work/tmp/unin3.c
1typedef _Complex float C;
2C foo(int *p)
3{
4 C f;
5 int a = *p;
6 *p = 42 * a;
7
8 return f;
9}
$ arm-none-eabi-gcc -O -Wuninitialized -S-o tmp.s /work/tmp/unin3.c
/work/tmp/unin3.c: In function 'foo':
/work/tmp/unin3.c:8:3: warning: 'f' is used uninitialized in this function
[-Wuninitialized]
$ gcc -O -Wuninitialized -S-o tmp.s /work/tmp/unin3.c
/work/tmp/unin3.c: In function ‘foo’:
/work/tmp/unin3.c:8: warning: ‘f’ is used uninitialized in this function
[Bug c++/51917] [4.7 regression] g++.old-deja/g++.abi/vmihint.C FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51917 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #2 from Jason Merrill 2012-01-24 19:41:44 UTC --- This seems to have to do with the host, rather than the target; a sparc64-unknown-linux-gnu native compiler has the bug, while a cross-compiler from i686-pc-linux-gnu does not.
[Bug libstdc++/51636] Thread-safeness of new and delete operators
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51636 --- Comment #2 from Andrew Pinski 2012-01-24 19:41:54 UTC --- >Guess: the new/new[] operators throwing std::bad_alloc have a MT-safeness problem. They should not as they are just wrappers around malloc.
[Bug c++/51973] [4.7 regression][C++11] Template parameter deduction fails for overloaded functions when template parameters have defaulted arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51973 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Jason Merrill 2012-01-24 19:07:59 UTC --- Fixed.
[Bug c++/51973] [4.7 regression][C++11] Template parameter deduction fails for overloaded functions when template parameters have defaulted arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51973 --- Comment #4 from Jason Merrill 2012-01-24 19:07:29 UTC --- Author: jason Date: Tue Jan 24 19:07:24 2012 New Revision: 183487 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183487 Log: PR c++/51973 * tree.c (called_fns_equal): Check template args. (cp_tree_equal): Call it. Added: trunk/gcc/testsuite/g++.dg/cpp0x/sfinae31.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/tree.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/51982] Shrink-wrapping opportunity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51982 Andrew Pinski changed: What|Removed |Added Depends on||10474 --- Comment #1 from Andrew Pinski 2012-01-24 19:02:33 UTC --- This is most likely the same reference problem as in PR 10474 comment #10.
[Bug middle-end/51982] Shrink-wrapping opportunity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51982 David Edelsohn changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2012-01-24 CC||amodra at gcc dot gnu.org Ever Confirmed|0 |1
[Bug middle-end/51982] New: Shrink-wrapping opportunity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51982 Bug #: 51982 Summary: Shrink-wrapping opportunity Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: d...@gcc.gnu.org Created attachment 26444 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26444 lookdict_string manually split equivalent to shrink-wrapping I realize that the shrink-wrapping implementation in GCC is preliminary and conservative. I tested it on an example that presents a good opportunity for shrink-wrapping and a large perforamnce improvement, but the current implementation was not able to apply the optimization. The attached file manually splits the CPython lookdict_string() into two functions where most of the prologue can be avoided on the slow path.
[Bug target/51968] gcc trunk (ARM) ICEs in final_scan_insn in final.c:2716, with "could not split insn" error msg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51968 Richard Henderson changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #8 from Richard Henderson 2012-01-24 17:41:33 UTC --- Fixed.
[Bug target/51968] gcc trunk (ARM) ICEs in final_scan_insn in final.c:2716, with "could not split insn" error msg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51968 --- Comment #7 from Richard Henderson 2012-01-24 17:33:46 UTC --- Author: rth Date: Tue Jan 24 17:33:41 2012 New Revision: 183480 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183480 Log: PR target/51968 * config/arm/arm.c (neon_split_vcombine): Emit deleted note to effect no-op split. Added: trunk/gcc/testsuite/gcc.target/arm/pr51968.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c
[Bug c++/51928] ICE: SIGSEGV in lookup_fnfields_idx_nolazy (search.c:1384) with -fgnu-tm on invalid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51928 Aldy Hernandez changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||aldyh at gcc dot gnu.org Resolution||FIXED --- Comment #2 from Aldy Hernandez 2012-01-24 16:50:39 UTC --- fixed
[Bug c++/51928] ICE: SIGSEGV in lookup_fnfields_idx_nolazy (search.c:1384) with -fgnu-tm on invalid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51928 --- Comment #1 from Aldy Hernandez 2012-01-24 16:47:43 UTC --- Author: aldyh Date: Tue Jan 24 16:47:24 2012 New Revision: 183478 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183478 Log: + PR c++/51928 + * class.c (set_method_tm_attributes): Use TARGET_THUNK instead of + thunk for set_one_vmethod_tm_attributes. Added: trunk/gcc/testsuite/g++.dg/tm/pr51928.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c
[Bug libstdc++/51981] Missing uninitialized_move() implementation?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51981 --- Comment #1 from Jonathan Wakely 2012-01-24 16:46:12 UTC --- Because it's non-standard
[Bug libstdc++/51981] New: Missing uninitialized_move() implementation?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51981 Bug #: 51981 Summary: Missing uninitialized_move() implementation? Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: valy...@gmail.com It's interesting to know why uninitialized_copy()'s counterpart - uninitialized_move() - is missing in http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/include/bits/stl_uninitialized.h?revision=177542&view=markup ? See boost's docs for details - http://www.boost.org/doc/libs/1_48_0/doc/html/boost/uninitialized_move.html .
[Bug libstdc++/51798] [4.7 regression] libstdc++ atomicity performance regression due to __sync_fetch_and_add
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51798 --- Comment #6 from Andrew Macleod 2012-01-24 16:02:03 UTC --- Others expressed concern about a change that could potentially affect all targets since its in libstdc++ code, especially considering this code is being deprecated. There are targets other than power that are also sensitive to the new semantics, both arm and alpha will change barrier emission based on the model used in fetch_and_add. I suggest acq-rel simply because it produces the same barrier structure power had in previous releases, is less intrusive, and is less likely to have an additional unforeseen impact anywhere else (other targets will also get the same barriers they had I believe.) You should see the same performance you had before wouldn't you? Im not arguing that using just release and acquire semantics instead wouldn't also be correct, merely that it is harder to prove the semantic change won't have unforeseen side effects in someones code. Its possible that relaxed mode might be also good enough, but again, harder to prove and comes with even greater risk. Anyway, just providing an option. It the libstdc++ guys that have to make the decision :-)
[Bug libgcj/50895] Build failure in jni.cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50895 --- Comment #2 from Ruben Van Boxem 2012-01-24 15:29:24 UTC --- With GCC 4.7, I get a different failure (and jni.cc hasn't been reached yet I think), which is pthread-related (I configured with --enable-threads=posix): libtool: compile: /home/ruben/mingw-w64/toolchain/linux64mingw32/gcc/./gcc/xgcc -shared-libgcc -B/home/ruben/mingw-w64/toolchain/linux64mingw32/gcc/./gcc -nostdinc++ -L/home/ruben/mingw-w64/toolchain/linux64mingw32/gcc/i686-w64-mingw32/libstdc++-v3/src -L/home/ruben/mingw-w64/toolchain/linux64mingw32/gcc/i686-w64-mingw32/libstdc++-v3/src/.libs -L/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/lib -L/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/mingw/lib -isystem /home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/include -isystem /home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/mingw/include -B/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/bin/ -B/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/lib/ -isystem /home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/include -isystem /home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/sys-include -DHAVE_CONFIG_H -I. -I/home/ruben/mingw-w64/toolchain/src/gcc/libjava -I./include -I./gcj -I/home/ruben/mingw-w64/toolchain/src/gcc/libjava -Iinclude -I/home/ruben/mingw-w64/toolchain/src/gcc/libjava/include -I/home/ruben/mingw-w64/toolchain/src/gcc/libjava/classpath/include -Iclasspath/include -I/home/ruben/mingw-w64/toolchain/src/gcc/libjava/classpath/native/fdlibm -I/home/ruben/mingw-w64/toolchain/src/gcc/libjava/../boehm-gc/include -I../boehm-gc/include -I/home/ruben/mingw-w64/toolchain/src/gcc/libjava/libltdl -I/home/ruben/mingw-w64/toolchain/src/gcc/libjava/libltdl -I/home/ruben/mingw-w64/toolchain/src/gcc/libjava/.././libjava/../libgcc -I/home/ruben/mingw-w64/toolchain/src/gcc/libjava/../zlib -I/home/ruben/mingw-w64/toolchain/src/gcc/libjava/../libffi/include -I../libffi/include -fno-rtti -fnon-call-exceptions -fdollars-in-identifiers -Wswitch-enum -D_FILE_OFFSET_BITS=64 -ffloat-store -fomit-frame-pointer -Usun -fno-omit-frame-pointer -Wextra -Wall -D_GNU_SOURCE -DPREFIX=\"/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32\" -DTOOLEXECLIBDIR=\"/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/lib/../lib\" -DJAVA_HOME=\"/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32\" -DBOOT_CLASS_PATH=\"/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/share/java/libgcj-4.7.0.jar\" -DJAVA_EXT_DIRS=\"/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/share/java/ext\" -DGCJ_ENDORSED_DIRS=\"/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/share/java/gcj-endorsed\" -DGCJ_VERSIONED_LIBDIR=\"/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/lib/../lib/gcj-4.7.0-13\" -DPATH_SEPARATOR=\":\" -DECJ_JAR_FILE=\"\" -DLIBGCJ_DEFAULT_DATABASE=\"/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/lib/../lib/gcj-4.7.0-13/classmap.db\" -DLIBGCJ_DEFAULT_DATABASE_PATH_TAIL=\"gcj-4.7.0-13/classmap.db\" -g -O2 -MT win32.lo -MD -MP -MF .deps/win32.Tpo -c /home/ruben/mingw-w64/toolchain/src/gcc/libjava/win32.cc -DDLL_EXPORT -DPIC -o .libs/win32.o /home/ruben/mingw-w64/toolchain/src/gcc/libjava/boehm.cc:60:8: warning: 'void GC_enable()' redeclared without dllimport attribute: previous dllimport ignored [-Wattributes] /home/ruben/mingw-w64/toolchain/src/gcc/libjava/boehm.cc:61:8: warning: 'void GC_disable()' redeclared without dllimport attribute: previous dllimport ignored [-Wattributes] /home/ruben/mingw-w64/toolchain/src/gcc/libjava/boehm.cc:716:1: warning: unused parameter 'thread' [-Wunused-parameter] /home/ruben/mingw-w64/toolchain/src/gcc/libjava/boehm.cc:725:1: warning: unused parameter 'thread' [-Wunused-parameter] /home/ruben/mingw-w64/toolchain/src/gcc/libjava/boehm.cc:734:1: warning: unused parameter 'thread' [-Wunused-parameter] /home/ruben/mingw-w64/toolchain/src/gcc/libjava/boehm.cc:73:12: warning: 'int _Jv_GC_has_static_roots(const char*, void*, size_t)' declared 'static' but never defined [-Wunused-function] depbase=`echo posix-threads.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\ /bin/sh ./libtool --tag=CXX --mode=compile /home/ruben/mingw-w64/toolchain/linux64mingw32/gcc/./gcc/xgcc -shared-libgcc -B/home/ruben/mingw-w64/toolchain/linux64mingw32/gcc/./gcc -nostdinc++ -L/home/ruben/mingw-w64/toolchain/linux64mingw32/gcc/i686-w64-mingw32/libstdc++-v3/src -L/home/ruben/mingw-w64/toolchain/linux64mingw32/gcc/i686-w64-mingw32/libstdc++-v3/src/.libs -L/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/lib -L/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/mingw/lib -isystem /home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/include -isystem /home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/mingw/include -B/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32
[Bug libstdc++/51798] [4.7 regression] libstdc++ atomicity performance regression due to __sync_fetch_and_add
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51798 --- Comment #5 from David Edelsohn 2012-01-24 15:29:44 UTC --- Are you suggesting that the existing atomicity support in libstdc++ should be changed to use ACQ_REL semantics? libstdc++ uses one function to both acquire and release a lock. It adds a positive value (increment) to acquire a lock and a negative value (decrement) to release a lock. POWER appears to be the most flexible and delicate platform with respect to atomic operations and we have been building and testing with my patch for weeks without problem. ACQUIRE, RELEASE, ACQ_REL and SEQ_CST does not make a practical difference in the emitted code on other platforms, so relaxing the semantics would not cause a problem.
[Bug fortran/51977] [OOP] MOVE_ALLOC: Bogus "must have the same rank 0/1" for same-rank arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51977 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus 2012-01-24 15:29:02 UTC --- See also PR 51970, which has a similar issue - and contains a fix for the follow-up issue (trans-intrinsic.c's conv_intrinsic_move_alloc).
[Bug fortran/51970] [OOP] gimplification failed for polymorphic MOVE_ALLOC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51970 --- Comment #3 from Tobias Burnus 2012-01-24 15:27:43 UTC --- Created attachment 26443 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26443 Draft patch for trans-intrinsic.c There are two issues: a) from_expr->rank *and* to_expr->rank are 0 instead of 1. That's a variant of the issue of PR 51977. b) trans-intrinsic.c's conv_move_alloc does not properly handle polymorphic arrays. For (b) a draft patch is attached. TODO: Regtest it, try combinations of TYPE and CLASS, try CLASS with allocatable components - and CLASS components. To use it, you need to either fix issue (a) or you can try the following hack: --- a/gcc/fortran/check.c +++ b/gcc/fortran/check.c @@ -2726,0 +2727,5 @@ gfc_check_move_alloc (gfc_expr *from, gfc_expr *to) + /* THIS IS A HACK! */ + if (from->ts.type == BT_CLASS && CLASS_DATA (from)->attr.dimension) +from->rank = CLASS_DATA (from)->as->rank; + if (to->ts.type == BT_CLASS && CLASS_DATA (to)->attr.dimension) +to->rank = CLASS_DATA (to)->as->rank;
[Bug target/51980] ARM - Neon code polluted by useless stores to the stack with vuzpq / vzipq / vtrnq
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51980 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-01-24 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther 2012-01-24 14:57:43 UTC --- It looks like the neon builtins are not properly marked as pure/const, that certainly is a road-block for optimizations. The heavy use of UNSPECs is another. Confirmed.
[Bug c++/51973] [4.7 regression][C++11] Template parameter deduction fails for overloaded functions when template parameters have defaulted arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51973 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-01-24 AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug target/51980] New: ARM - Neon code polluted by useless stores to the stack with vuzpq / vzipq / vtrnq
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51980
Bug #: 51980
Summary: ARM - Neon code polluted by useless stores to the
stack with vuzpq / vzipq / vtrnq
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: eric.ba...@allegorithmic.com
Created attachment 26442
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26442
Minimal repro case (C file)
When using UZP/ZIP/TRN Neon intrinsics, gcc-trunk generates a whole lot of
stack operations (and associated stack alignment operations) even if everything
can purely be done using Neon registers.
Compiler used is GCC trunk, rev 183468, compiled with Android's build-gcc.sh
(arm-linux-androideabi).
Command line is:
arm-linux-androideabi-g++ -c -march=armv7-a -mcpu=cortex-a9 -mfloat-abi=hard
-mfpu=vfp -flax-vector-conversions -mfpu=neon -O2 -o test.s test.c -S
Generated assembly code for attached C file is:
_Z13sqrlen4D_16u817__simd128_uint8_tS_:
vabd.u8q1, q0, q1
stmfdsp!, {r4, fp} <= Unnecessary
addfp, sp, #4 <= Unnecessary
subsp, sp, #48 <= Unnecessary
addr3, sp, #15 <= Unnecessary
vmull.u8q0, d2, d2
bicr3, r3, #15 <= Unnecessary
vmull.u8q8, d3, d3
vuzp.32q0, q8
vstmiar3, {d0-d1} <= Unnecessary, caused by vuzp.32
vstrd16, [r3, #16] <= Unnecessary, caused by vuzp.32
vstrd17, [r3, #24] <= Unnecessary, caused by vuzp.32
vpaddl.u16q0, q0
vpadal.u16q0, q8
subsp, fp, #4 <= Unnecessary
ldmfdsp!, {r4, fp} <= Unnecessary
bxlr
As no stack operation is needed in this function, ideally the following should
be generated instead:
_Z13sqrlen4D_16u817__simd128_uint8_tS_:
vabd.u8q1, q0, q1
vmull.u8q0, d2, d2
vmull.u8q8, d3, d3
vuzp.32q0, q8
vpaddl.u16q0, q0
vpadal.u16q0, q8
bxlr
This makes even tight Neon functions written with intrinsics much larger and
slower than necessary, and makes it very hard to write performance-oriented
code with intrinsics in arm-gcc.
gcc -v yields:
Using built-in specs.
COLLECT_GCC=/home/eb/android-ndk-r6/toolchains/arm-linux-androideabi-4.7.0/prebuilt/linux-x86/bin/arm-linux-androideabi-g++
COLLECT_LTO_WRAPPER=/home/eb/android-ndk-r6/toolchains/arm-linux-androideabi-4.7.0/prebuilt/linux-x86/libexec/gcc/arm-linux-androideabi/4.7.0/lto-wrapper
Target: arm-linux-androideabi
Configured with: /home/eb/android-ndk-r6/src/build/../gcc/gcc-4.7.0/configure
--prefix=/home/eb/android-ndk-r6/toolchains/arm-linux-androideabi-4.7.0/prebuilt/linux-x86
--target=arm-linux-androideabi --host=i386-linux-gnu --build=i386-linux-gnu
--with-gnu-as --with-gnu-ld --enable-languages=c,c++
--with-gmp=/tmp/ndk-eb/build/toolchain/temp-install
--with-mpfr=/tmp/ndk-eb/build/toolchain/temp-install
--with-mpc=/tmp/ndk-eb/build/toolchain/temp-install --disable-libssp
--enable-threads --disable-nls --disable-libmudflap --disable-libgomp
--disable-libstdc__-v3 --disable-sjlj-exceptions --disable-shared --disable-tls
--with-float=soft --with-fpu=vfp --with-arch=armv5te --enable-target-optspace
--enable-initfini-array --disable-nls
--prefix=/home/eb/android-ndk-r6/toolchains/arm-linux-androideabi-4.7.0/prebuilt/linux-x86
--with-sysroot=/home/eb/android-ndk-r6/toolchains/arm-linux-androideabi-4.7.0/prebuilt/linux-x86/sysroot
--with-binutils-version=2.21.53 --with-mpfr-version=3.0.1
--with-gmp-version=5.0.2 --with-gcc-version=4.7.0 --with-gdb-version=6.6
--with-mpc-version=0.9 --with-arch=armv5te --enable-libstdc__-v3
--program-transform-name='s,^,arm-linux-androideabi-,'
Thread model: posix
gcc version 4.7.0 20120124 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-c' '-march=armv7-a' '-mcpu=cortex-a9' '-mfloat-abi=hard'
'-mfpu=vfp' '-flax-vector-conversions' '-mfpu=neon' '-O2' '-o' 'test.s' '-S'
'-v' '-mtls-dialect=gnu'
/home/eb/android-ndk-r6/toolchains/arm-linux-androideabi-4.7.0/prebuilt/linux-x86/libexec/gcc/arm-linux-androideabi/4.7.0/cc1plus
-quiet -v -imultilib armv7-a -D_GNU_SOURCE test.c -mbionic -fPIC -quiet
-dumpbase test.c -march=armv7-a -mcpu=cortex-a9 -mfloat-abi=hard -mfpu=vfp
-mfpu=neon -mtls-dialect=gnu -auxbase-strip test.s -O2 -version
-flax-vector-conversions -o test.s -fno-exceptions -fno-rtti
GNU C++ (GCC) version 4.7.0 20120124 (experimental) (arm-linux-androideabi)
compiled by GNU C version 4.6.0 20110603 (Red Hat 4.6.0-10), GMP version
5.0.2, MPFR version 3.0.1, MPC version 0.9
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent di
[Bug bootstrap/49829] [4.7 Regression] --disable-static --enable-shared regression: cannot find -lstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49829 --- Comment #22 from Jakub Jelinek 2012-01-24 13:59:19 UTC --- On powerpc64-linux apparently a few symbols are gone since yesterday: _ZNSbIwSt11char_traitsIwESaIwEE4_Rep20_S_empty_rep_storageE@@GLIBCXX_3.4 OBJECT GLOBAL DEFAULT 16 _ZNSs4_Rep20_S_empty_rep_storageE@@GLIBCXX_3.4 OBJECT GLOBAL DEFAULT 16 _ZNSt8numpunctIcE2idE@@GLIBCXX_3.4 OBJECT GLOBAL DEFAULT 4 _ZNSt8numpunctIwE2idE@@GLIBCXX_3.4 OBJECT GLOBAL DEFAULT 4 in 32-bit libstdc++.so.6 and _ZNSbIwSt11char_traitsIwESaIwEE4_Rep20_S_empty_rep_storageE@@GLIBCXX_3.4 OBJECT GLOBAL DEFAULT 32 _ZNSs4_Rep20_S_empty_rep_storageE@@GLIBCXX_3.4 OBJECT GLOBAL DEFAULT 32 _ZNSt8numpunctIcE2idE@@GLIBCXX_3.4 OBJECT GLOBAL DEFAULT 8 _ZNSt8numpunctIwE2idE@@GLIBCXX_3.4 OBJECT GLOBAL DEFAULT 8 in 64-bit libstdc++.so.6.
[Bug driver/47249] [4.4/4.5/4.6 Regression] ICE in common_handle_option, at opts.c:1695 with unknown option passed to cc1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47249 Richard Guenther changed: What|Removed |Added Target Milestone|4.4.7 |4.7.0 --- Comment #7 from Richard Guenther 2012-01-24 13:49:55 UTC --- Agreed.
[Bug c++/51812] [4.7 regression] Virtual public inheritance and thunks leads to "undefined reference" in header files.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51812 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #8 from Jason Merrill 2012-01-24 13:38:13 UTC --- Fixed.
[Bug c++/51812] [4.7 regression] Virtual public inheritance and thunks leads to "undefined reference" in header files.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51812 --- Comment #7 from Jason Merrill 2012-01-24 13:37:43 UTC --- Author: jason Date: Tue Jan 24 13:37:38 2012 New Revision: 183475 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183475 Log: PR c++/51812 * cgraphunit.c (cgraph_decide_is_function_needed): Don't always output static aliases. Added: trunk/gcc/testsuite/g++.dg/inherit/covariant20.C Modified: trunk/gcc/ChangeLog trunk/gcc/cgraphunit.c trunk/gcc/testsuite/ChangeLog
[Bug driver/47249] [4.4/4.5/4.6 Regression] ICE in common_handle_option, at opts.c:1695 with unknown option passed to cc1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47249 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Summary|[4.4/4.5/4.6/4.7|[4.4/4.5/4.6 Regression] |Regression] ICE in |ICE in |common_handle_option, at|common_handle_option, at |opts.c:1695 with unknown|opts.c:1695 with unknown |option passed to cc1|option passed to cc1 --- Comment #6 from Jakub Jelinek 2012-01-24 13:24:06 UTC --- Fixed on the trunk. Not worth backporting I think.
[Bug driver/47249] [4.4/4.5/4.6/4.7 Regression] ICE in common_handle_option, at opts.c:1695 with unknown option passed to cc1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47249 --- Comment #5 from Jakub Jelinek 2012-01-24 13:18:16 UTC --- Author: jakub Date: Tue Jan 24 13:18:08 2012 New Revision: 183474 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183474 Log: PR driver/47249 * common.opt (-pie, -shared, pie, shared): Change from Common to Driver. * gcc.c (display_help): Display help for -pie and -shared. Modified: trunk/gcc/ChangeLog trunk/gcc/common.opt trunk/gcc/gcc.c
[Bug fortran/41823] gcc/fortran/trans-openmp.c: possible null pointer dereference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41823 --- Comment #4 from Jakub Jelinek 2012-01-24 13:18:18 UTC --- It is not, but it isn't that a big deal, gcc will optimize the test away.
[Bug bootstrap/51969] [4.6 regression] gcc 4.7 unable to build gcc 4.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51969 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.6.3 --- Comment #4 from Richard Guenther 2012-01-24 13:03:42 UTC --- Confirmed, I've seen this as well.
[Bug c/51971] unclear/unverified restrictions on attribute((const|pure))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51971
--- Comment #1 from Richard Guenther 2012-01-24
13:01:03 UTC ---
GCC explicitely allows you to use const/pure to enable CSE even if it would
not consider the function const/pure itself (thus, if you are happy to
loose a second assert (), or a debug printf).
About returning normally it wants to exclude side-effects that happen
via the return, such as if the function calls longjmp/fork (return twice).
It also wants to exclude functions that do not return because they loop
infinitely. For example
int foo (int b)
{
if (b) while (1);
return b;
}
is not const, as GCC would, if you declare it so, happily remove
foo (1);
as dead code (GCC will do so for all pure/const functions if the result
is not needed).
[Bug rtl-optimization/44174] [4.4/4.5/4.6 Regression] can't find a register in class 'CLOBBERED_REGS' while reloading 'asm'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44174 --- Comment #15 from ro at CeBiTec dot Uni-Bielefeld.DE 2012-01-24 12:55:38 UTC --- > --- Comment #14 from Andrew Pinski 2012-01-24 > 01:29:40 UTC --- > Since this was fixed on the trunk, can you remove the xfail? I already did so in April last year. Rainer
[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 #14 from Georg-Johann Lay 2012-01-24 12:38:59 UTC --- Author: gjl Date: Tue Jan 24 12:38:52 2012 New Revision: 183473 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183473 Log: PR target/49868 * doc/extend.texi (AVR Named Address Spaces): Move sample code up. Remove note on size/offset limitation. (AVR Variable Attributes): Add example how to read data located with progmem. Refer to named address spaces. * doc/invoke.texi (AVR Options): Fix typo. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/extend.texi trunk/gcc/doc/invoke.texi
[Bug libstdc++/51965] Redundant move constructions in heap algorithms
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51965 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-01-24 CC||paolo.carlini at oracle dot ||com Ever Confirmed|0 |1 --- Comment #8 from Paolo Carlini 2012-01-24 11:58:33 UTC --- I agree. Let's make sure we actually handle this, as soon as 4.7.0 is out.
[Bug c++/41933] [c++0x] lambdas and variadic templates don't work together
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41933 Paolo Carlini changed: What|Removed |Added CC||i.nixman at gmail dot com --- Comment #5 from Paolo Carlini 2012-01-24 11:56:18 UTC --- *** Bug 51979 has been marked as a duplicate of this bug. ***
[Bug c++/51979] variadic templates + lambda capture list = error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51979 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Paolo Carlini 2012-01-24 11:56:18 UTC --- Known issue. *** This bug has been marked as a duplicate of bug 41933 ***
[Bug fortran/42934] Bogus variable_check
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42934 --- Comment #1 from Dominique d'Humieres 2012-01-24 11:41:21 UTC --- > The following example shows this: For LOC(f) it prints the address of the > function, for LOC(f()) the result of the function call; but it fails for This is the case for gfortran 4.4 and 4.5, but 4.6 and trunk gives the following error pr42934.f90:14.13: print *, loc(f()) ! print 0 1 Error: 'x' argument of 'loc' intrinsic at (1) must be a variable What result do you expect? Is it a 4.6/4.7 regression?
[Bug target/51968] gcc trunk (ARM) ICEs in final_scan_insn in final.c:2716, with "could not split insn" error msg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51968 --- Comment #6 from Eric Batut 2012-01-24 11:17:33 UTC --- Our Neon codebase (lots of image processing filters) produce correct results with the patch applied to the latest trunk rev.
[Bug target/51959] [4.7 Regression] ICE in set_mem_alias_set, at emit-rtl.c:1884
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51959 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |ebotcazou at gcc dot |gnu.org |gnu.org --- Comment #4 from Eric Botcazou 2012-01-24 11:13:52 UTC --- Investigating.
[Bug target/51968] gcc trunk (ARM) ICEs in final_scan_insn in final.c:2716, with "could not split insn" error msg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51968 --- Comment #5 from Eric Batut 2012-01-24 11:12:23 UTC --- (In reply to comment #3) > Created attachment 26436 [details] > proposed patch > > I'll run this through a cross-build first, but I expect this will fix it. This patch makes gcc trunk no longer crash with our Neon files. Building right now to test for code correctness, although judging from the patch the functionality of the code should not be impacted. Thanks Richard !
[Bug rtl-optimization/51978] ext-elim-1.c ICE on powerpc64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51978 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-01-24 Ever Confirmed|0 |1 --- Comment #2 from Eric Botcazou 2012-01-24 11:11:17 UTC --- > The attached untested patch cures the ICE, still I wonder about the single_set > instead of note_stores, I'd expect the pass isn't really prepared to handle > multiple sets in parallel alongside with sign/zero extension anyway. The patch looks fine to me. Yes, single_set would probably be sufficient, as merge_def_and_ext punts if there are multiple sets. > Additionally, I wonder if some of the PR51667 additions couldn't be dropped > again (4.8 material) now that we keep the UD/DU links for the whole duration > of > the pass. There is a FIXME for this.
[Bug fortran/41823] gcc/fortran/trans-openmp.c: possible null pointer dereference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41823 --- Comment #3 from Dominique d'Humieres 2012-01-24 11:09:05 UTC --- > It is guaranteed to be non-NULL for omp parallel/do/task and many others, see > the ew_st.ext.omp_clauses = something lines in openmp.c. Then is the 'if (clauses)' necessary?
[Bug c++/51979] New: variadic templates + lambda capture list = error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51979
Bug #: 51979
Summary: variadic templates + lambda capture list = error
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: i.nix...@gmail.com
The following code:
template void foo(Args... args) {}
template void bar(Args... args) {
auto lambda = [=, args...]() {
foo(args...);
};
}
produce this error:
>g++ -std=c++0x lambd.cpp -olambd
lambd.cpp: In function 'void bar(Args ...)':
lambd.cpp:3:25: error: expected ',' before '...' token
lambd.cpp:3:25: error: expected identifier before '...' token
lambd.cpp:3:28: error: parameter packs not expanded with '...':
lambd.cpp:3:28: note: 'args'
lambd.cpp: In lambda function:
lambd.cpp:4:13: error: expansion pattern '((const bar(Args
...)::*)this)->bar(Args ...)args' contains no argument
packs
example from c++ draft 5.1.2.23:
template
void f(Args... args) {
auto lm = [&, args...] { return g(args...); };
lm();
}
[Bug fortran/41823] gcc/fortran/trans-openmp.c: possible null pointer dereference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41823 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek 2012-01-24 10:57:23 UTC --- It is guaranteed to be non-NULL for omp parallel/do/task and many others, see the ew_st.ext.omp_clauses = something lines in openmp.c.
[Bug fortran/42693] Missing gcc-internal-format on messages from gfc_arith_error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42693 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-01-24 CC||bur...@net-b.de Ever Confirmed|0 |1 --- Comment #2 from Dominique d'Humieres 2012-01-24 10:55:06 UTC --- > Confirm. One possibility would be to modify ... Tobias, Is it that simple?
[Bug target/51959] [4.7 Regression] ICE in set_mem_alias_set, at emit-rtl.c:1884
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51959 Jakub Jelinek changed: What|Removed |Added CC||ebotcazou at gcc dot ||gnu.org, jakub at gcc dot ||gnu.org --- Comment #3 from Jakub Jelinek 2012-01-24 10:49:51 UTC --- Started with http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182102
[Bug libstdc++/51965] Redundant move constructions in heap algorithms
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51965 --- Comment #7 from Marc Glisse 2012-01-24 10:49:38 UTC --- (In reply to comment #6) > But __pop_heap doesn't seem so straightforward to tweak, we also changed > a bit the interfaces. At first glance, I am not sure why pop_heap can end up calling push_heap, so I would need to really look at the code (no time...). > Marc can you submit a complete patch? Not now, sorry. Maybe in a few weeks... (no promise) I haven't reviewed Aliaksandr's patch, but the approach seems sensible. > Otherwise, so close to the branch for 4.7.0 I'm not sure I will be able to > work on this, It may be safer to patch it in 4.8.0 and backport to 4.7.1.
[Bug fortran/41823] gcc/fortran/trans-openmp.c: possible null pointer dereference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41823 Dominique d'Humieres changed: What|Removed |Added CC||jakub at redhat dot com --- Comment #1 from Dominique d'Humieres 2012-01-24 10:44:02 UTC --- On trunk at revision 183455, the code is now gfc_omp_clauses *clauses = code->ext.omp_clauses; int i, collapse = clauses->collapse; AFAICT so far there has been no case of gfc_trans_omp_do called with clauses==NULL. CCed Jakub.
[Bug c++/51223] [4.5/4.6 Regression] ICE with invalid function parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51223 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|4.5.4 |4.7.0 Summary|[4.5/4.6/4.7 Regression]|[4.5/4.6 Regression] ICE |ICE with invalid function |with invalid function |parameter |parameter --- Comment #4 from Paolo Carlini 2012-01-24 10:41:00 UTC --- Fixed for 4.7.0.
[Bug c++/51223] [4.5/4.6/4.7 Regression] ICE with invalid function parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51223 --- Comment #3 from paolo at gcc dot gnu.org 2012-01-24 10:39:08 UTC --- Author: paolo Date: Tue Jan 24 10:39:03 2012 New Revision: 183472 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183472 Log: /cp 2012-01-24 Paolo Carlini PR c++/51223 * call.c (build_over_call): Check for error_mark_node as TREE_VALUE when default arguments are processed. /testsuite 2012-01-24 Paolo Carlini PR c++/51223 * g++.dg/parse/crash58.C: New. Added: trunk/gcc/testsuite/g++.dg/parse/crash58.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/40060] [4.5/4.6/4.7 Regression] casts loose alignment info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40060 vries at gcc dot gnu.org changed: What|Removed |Added CC||vries at gcc dot gnu.org --- Comment #15 from vries at gcc dot gnu.org 2012-01-24 10:36:53 UTC --- (In reply to comment #13) > *** Bug 43814 has been marked as a duplicate of this bug. *** I submitted a patch for PR43814 ( http://gcc.gnu.org/ml/gcc-patches/2011-12/msg00571.html ). That patch works for that PR, since the test-case has a dereference to derive alignment info from, but it doesn't work for this PR, since gcc.target/powerpc/405-dlmzb-strlen-1.c doesn't contain such a dereference.
[Bug rtl-optimization/45678] [4.4/4.5 Regression] crash on vector code with -m32 -msse
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45678 --- Comment #33 from Richard Guenther 2012-01-24 10:23:19 UTC --- Author: rguenth Date: Tue Jan 24 10:23:14 2012 New Revision: 183471 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183471 Log: 2012-01-24 Richard Guenther Forward-port to branch 2010-09-21 Jakub Jelinek PR middle-end/45678 * expr.c (expand_expr_real_1) : If op0 isn't sufficiently aligned and there is movmisalignM insn for mode, use it to load op0 into a temporary register. Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/expr.c
[Bug fortran/51970] [OOP] gimplification failed for polymorphic MOVE_ALLOC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51970 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-01-24 Ever Confirmed|0 |1 --- Comment #2 from Dominique d'Humieres 2012-01-24 10:22:19 UTC --- > And it crashes in the same way with 4.7.0 2012-01-18 trunk revision 183273. So marked as NEW.
[Bug bootstrap/49829] [4.7 Regression] --disable-static --enable-shared regression: cannot find -lstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49829 --- Comment #21 from Jan Kratochvil 2012-01-24 10:17:14 UTC --- With r183465 it really builds for me now, thanks.
[Bug debug/51902] lexical_blocks inside inlined_subroutines generate duplicate debug_ranges
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51902 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |4.8.0 --- Comment #8 from Jakub Jelinek 2012-01-24 10:19:02 UTC --- http://gcc.gnu.org/ml/gcc-patches/2012-01/msg01171.html
[Bug other/51937] [meta-bug] GCC 4.8 pending patches
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51937 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug bootstrap/49829] [4.7 Regression] --disable-static --enable-shared regression: cannot find -lstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49829 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #20 from Jakub Jelinek 2012-01-24 10:12:51 UTC --- Should be fixed now.
[Bug tree-optimization/51879] Missed tail merging with non-const/pure calls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51879 vries at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |vries at gcc dot gnu.org |gnu.org | --- Comment #6 from vries at gcc dot gnu.org 2012-01-24 10:12:38 UTC --- Submitted: http://gcc.gnu.org/ml/gcc-patches/2012-01/msg01178.html
[Bug middle-end/48600] [4.6/4.7 Regression] ICE when using cold attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48600 --- Comment #13 from Jakub Jelinek 2012-01-24 10:09:38 UTC --- Honza, ping?
[Bug fortran/51966] [4.6/4.7 Regression] ICE in gfc_conv_array_constructor_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51966 --- Comment #5 from Tobias Burnus 2012-01-24 09:48:28 UTC --- (In reply to comment #4) > type(Deriv), save :: DepEcoSystem = Deriv(DEF_ECOSYSTEMS(1)) Here, the problem is that in #0 gfc_conv_string_init (length=0x2cf3b720, expr=0x16c1170) expr->type == EXPR_ARRAY. Hence, the following fails: gcc_assert (expr->expr_type == EXPR_CONSTANT); #1 in gfc_conv_initializer at fortran/trans-expr.c:4940 #2 in gfc_conv_structure at fortran/trans-expr.c:5396 #3 in gfc_conv_initializer at fortran/trans-expr.c:4933 #4 in gfc_get_symbol_decl at fortran/trans-decl.c:1476 Also that version works with GCC 4.5. (In reply to comment #3) > [2009-07-23] Revision 162456 is OK, > [2010-09-29] revision 164728 gives the ICE. Also 2010-08-28-r163612 fails. I wonder whether the patch for PR 44857 (2010-08-04, Rev. 162863) is the culprit: http://gcc.gnu.org/ml/fortran/2010-08/msg00034.html
[Bug fortran/51966] [4.6/4.7 Regression] ICE in gfc_conv_array_constructor_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51966 --- Comment #4 from Tobias Burnus 2012-01-24 09:26:56 UTC --- Reduced test case, which also illustrates another ICE: module EcoSystem_ml implicit none type, public:: Deriv character(len=10) :: name end type character(len=8), public, dimension(1), parameter :: & DEF_ECOSYSTEMS = (/ "Grid" /) type(Deriv), save :: DepEcoSystem != Deriv(DEF_ECOSYSTEMS(1)) ! ICE in gfc_conv_string_init contains subroutine Init_EcoSystems() DepEcoSystem = Deriv(DEF_ECOSYSTEMS(1)) ! ^^^ ICE in gfc_conv_array_constructor_expr end subroutine Init_EcoSystems end module EcoSystem_ml
[Bug rtl-optimization/45678] [4.4/4.5 Regression] crash on vector code with -m32 -msse
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45678 --- Comment #32 from Richard Guenther 2012-01-24 09:17:11 UTC --- Author: rguenth Date: Tue Jan 24 09:17:01 2012 New Revision: 183470 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183470 Log: 2012-01-24 Richard Guenther Forward-port to trunk 2010-09-21 Jakub Jelinek PR middle-end/45678 * expr.c (expand_expr_real_1) : If op0 isn't sufficiently aligned and there is movmisalignM insn for mode, use it to load op0 into a temporary register. Modified: trunk/gcc/ChangeLog trunk/gcc/expr.c
