[Bug bootstrap/55388] [4.8 regression] ICE in int_mode_for_mode at stor-layout.c:423 breaks sparc64-linux bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55388 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-22 CC||ebotcazou at gcc dot ||gnu.org Ever Confirmed|0 |1 --- Comment #8 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-11-22 08:32:51 UTC --- Thanks. After trying and failing to convince it to fail in cross environment, it finally dawned on me that the failure was during stage 2, so presumably this is a miscompile of cc1plus. Sorry for the runaround. Yes, this looks like a miscompilation. I'll try to reproduce the failure on gcc62, but I'm guessing it will take a while to reach the failure point. This reproduces only with Mikael's configure options, i.e. in release mode, so it isn't that long.
[Bug other/55313] libsanitizer cannot be installed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55313 --- Comment #9 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-11-22 09:08:57 UTC --- OK, the problem is that we change the prefix at installation time (by setting the prefix variable on the make install command line). This works fine for all other libraries, but libasan.la has the relink_command thing, which triggers the check in libtool: if test -n $relink_command; then # Determine the prefix the user has applied to our future dir. inst_prefix_dir=`$ECHO $destdir | $SED -e s%$libdir\$%%` # Don't allow the user to place us outside of our expected # location b/c this prevents finding dependent libraries that # are installed to the same prefix. # At present, this check doesn't affect windows .dll's that # are installed into $libdir/../bin (currently, that works fine) # but it's something to keep an eye on. test $inst_prefix_dir = $destdir \ func_fatal_error error: cannot install \`$file' to a directory not ending in $libdir
[Bug tree-optimization/38785] [4.5/4.6/4.7/4.8 Regression] huge performance regression on EEMBC bitmnp01
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38785
Jan Hubicka hubicka at gcc dot gnu.org changed:
What|Removed |Added
CC||vmakarov at redhat dot com
--- Comment #37 from Jan Hubicka hubicka at gcc dot gnu.org 2012-11-22
09:50:52 UTC ---
Yes, agreed. It is overall problem of SSA form to assume that reg-reg copies in
PHIs will be optimized away by smart regalloc. Moreover we assume the same for
constants.
This case is hard to fix later since the values are path sensitive...
Vladimir, I guess there is not much to do on regalloc side, right?
Why the problem do not reproduce on simplified testcase:
void
f (int i, long *a, long *b)
{
int sum = 0;
b[i] = 0;
#define PART(I) if (t()) sum++;
PART (1);
PART (2);
PART (3);
PART (4);
PART (5);
PART (6);
tt (sum);
}
here we somehow do not consider the partial redundancies on sum...
[Bug c++/55432] Too much constexpr makes the compiler crash
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55432 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-22 09:54:07 UTC --- It is, in mainline and 4.7.2. To be safe, I'm adding the testcase and then will close the PR.
[Bug c++/55434] const array with elements initialized by constructor marked non-const in debug info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55434 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-22 09:57:02 UTC --- Note that in any case patches should be posted to gcc-patches.
[Bug target/54222] [avr] Implement fixed-point support
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54222 --- Comment #8 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-11-22 10:00:24 UTC --- Author: gjl Date: Thu Nov 22 10:00:13 2012 New Revision: 193721 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193721 Log: libgcc/ Adjust decimal point of signed accum mode to GCC default. PR target/54222 * config/avr/t-avr (LIB1ASMFUNCS): Add _fractsfsq _fractsfusq, _divqq_helper. * config/avr/lib1funcs-fixed.S (__fractqqsf, __fracthqsf) (__fractsasf, __fractsfha, __fractusqsf, __fractsfsa) (__mulha3, __mulsa3) (__divqq3, __divha3, __divsa3): Adjust to new position of decimal point of signed accum types. (__mulusa3_round): New function. (__mulusa3): Use it. (__divqq_helper): New function. (__udivuqq3): Use it. gcc/ Adjust decimal point of signed accum mode to GCC default. PR target/54222 * config/avr/avr-modes.def (HA, SA, DA): Remove mode adjustments. (TA): Move decimal point one bit to the right. * config/avr/avr.c (avr_out_fract): Rewrite. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr-modes.def trunk/gcc/config/avr/avr.c trunk/libgcc/ChangeLog trunk/libgcc/config/avr/lib1funcs-fixed.S trunk/libgcc/config/avr/t-avr
[Bug testsuite/55429] new UNRESOLVED: 20_util/enable_shared_from_this/cons/constexpr.cc scan-assembler on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55429 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-22 10:06:05 UTC --- Me: I very often run the testsuite serially on Linux.
[Bug c++/55432] Too much constexpr makes the compiler crash
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55432 --- Comment #3 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2012-11-22 10:23:07 UTC --- Author: paolo Date: Thu Nov 22 10:23:03 2012 New Revision: 193723 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193723 Log: 2012-11-22 Paolo Carlini paolo.carl...@oracle.com PR c++/55432 * g++.dg/cpp0x/constexpr-55432.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-55432.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/55432] Too much constexpr makes the compiler crash
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55432 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-22 10:23:58 UTC --- Done.
[Bug sanitizer/55289] darwin bootstrap fails due to missing libsanitizer/interception/mach_override directory and files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55289 --- Comment #49 from Alexander Potapenko glider at google dot com 2012-11-22 10:43:03 UTC --- The new interposition library should work on 10.6. But ASan itself doesn't work on 10.5, at least I remember some problems with its compilation. We're not really interested in supporting 10.5, as it's completely unsupported by Apple.
[Bug c++/55418] Valgrind: Conditional jump or move depends on uninitialised value(s) in implicitly_declare_fn() method.c:1623
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55418 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-22 10:46:31 UTC --- The issue seems indeed trivial, but note that we are already assigning false to trivial_p in the conditional, thus I guess we should remove the latter. Maybe also move the declaration itself right before the conditional, in my opinion it adds clarity. Please send a patch to the mailing list.
[Bug bootstrap/55388] [4.8 regression] ICE in int_mode_for_mode at stor-layout.c:423 breaks sparc64-linux bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55388 --- Comment #9 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-11-22 11:02:43 UTC --- Richard, did you already start to investigate seriously? If no, I can take it over if you want, it's SPARC and I have a big share in the problematic patch.
[Bug sanitizer/55379] -static -static-libasan pass -Bdynamic to linker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55379 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-22 11:14:18 UTC --- For -static one could perhaps use --wrap ld option to wrap various symbols, but we'd need special libasan_static.a for that. Not worth it.
[Bug sanitizer/55379] -static -static-libasan pass -Bdynamic to linker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55379
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-11-22
Ever Confirmed|0 |1
--- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-22
11:30:55 UTC ---
So we need %{static:%e-fsanitize=address requires dynamic linking} or similar
in LIBASAN_SPEC.
[Bug target/54895] the compiler treats '__cdecl' '__stdcall' as the same.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54895 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added CC||ktietz at gcc dot gnu.org --- Comment #4 from Kai Tietz ktietz at gcc dot gnu.org 2012-11-22 11:47:12 UTC --- This is most likely a duplicate of already fixed PR/55268.
[Bug testsuite/55429] new UNRESOLVED: 20_util/enable_shared_from_this/cons/constexpr.cc scan-assembler on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55429 --- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-11-22 12:27:58 UTC --- Me: I very often run the testsuite serially on Linux. Does this mean that you have run a serial testsuite of libstdc++-v3 after r193542 and you did not get the UNRESOLVED cases?
[Bug c++/55437] Non-const copy constructor causes error - even if not called
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55437 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-11-22 12:48:09 UTC --- The program is ill-formed. String S = (char*)Test; is equivalent to String S = String((char*)Test); which requires an accessible copy constructor (or in C++11 move constructor) that takes an rvalue argument (i.e. temporary). A non-const reference cannot bind to a temporary, so your copy constructor is not viable. The copy constructor must be accessible and viable even if the copy is elided and the copy constructor is not used. You'll get the same error from any conforming C++ compiler.
[Bug c++/55436] g++ compiles invalid code with child class of nested class in template class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55436 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-22 Ever Confirmed|0 |1 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-11-22 12:53:54 UTC --- Yes, AT::B is a dependent base of AT::C, so lookup should find A::m not B::m
[Bug c++/55436] g++ compiles invalid code with child class of nested class in template class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55436
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Keywords||rejects-valid, wrong-code
--- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2012-11-22
12:58:19 UTC ---
This is also a wrong-code and rejects-valid bug.
This correct program shows the wrong m() being called (and so results in a
linker error)
templatetypename T
struct A
{
static void m() { }
struct B
{
void m();
};
struct C : B
{
void x() { m(); }
};
};
int main()
{
Adouble::C c;
c.x();
}
and if we make B::m private we get rejects-valid
.cc: In member function ‘void AT::C::x() [with T = double]’:
x.cc:21:7: instantiated from here
x.cc:9:10: error: ‘void AT::B::m() [with T = double]’ is private
x.cc:14:16: error: within this context
[Bug tree-optimization/38785] [4.5/4.6/4.7/4.8 Regression] huge performance regression on EEMBC bitmnp01
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38785
--- Comment #38 from Jan Hubicka hubicka at gcc dot gnu.org 2012-11-22
13:05:38 UTC ---
yet another variant...
void
f (int i, long *a, long *b)
{
int sum = 0;
for (; --i = 0; a++, b++)
{
b[i] = 0;
#define PART(I) if (t()) sum+=100+I;
PART (1);
PART (2);
PART (3);
PART (4);
PART (5);
PART (6);
tt (sum);
}
}
leads to...
Starting insert iteration 1
Could not find SSA_NAME representative for expression:{plus_expr,sum_8,101}
Created SSA_NAME representative pretmp_98 for expression:{plus_expr,sum_8,101}
Could not find SSA_NAME representative for expression:{plus_expr,pretmp_98,102}
Created SSA_NAME representative pretmp_99 for
expression:{plus_expr,pretmp_98,102}
Could not find SSA_NAME representative for expression:{plus_expr,pretmp_99,103}
Created SSA_NAME representative pretmp_100 for
expression:{plus_expr,pretmp_99,103}
Could not find SSA_NAME representative for
expression:{plus_expr,pretmp_100,104}
Created SSA_NAME representative pretmp_101 for
expression:{plus_expr,pretmp_100,104}
Could not find SSA_NAME representative for
expression:{plus_expr,pretmp_101,105}
Created SSA_NAME representative pretmp_102 for
expression:{plus_expr,pretmp_101,105}
Could not find SSA_NAME representative for
expression:{plus_expr,pretmp_100,105}
Created SSA_NAME representative pretmp_103 for
expression:{plus_expr,pretmp_100,105}
Could not find SSA_NAME representative for expression:{plus_expr,pretmp_99,104}
Created SSA_NAME representative pretmp_104 for
expression:{plus_expr,pretmp_99,104}
Could not find SSA_NAME representative for
expression:{plus_expr,pretmp_104,105}
Created SSA_NAME representative pretmp_105 for
expression:{plus_expr,pretmp_104,105}
Could not find SSA_NAME representative for expression:{plus_expr,pretmp_99,105}
Created SSA_NAME representative pretmp_106 for
expression:{plus_expr,pretmp_99,105}
Could not find SSA_NAME representative for expression:{plus_expr,pretmp_98,103}
Created SSA_NAME representative pretmp_107 for
expression:{plus_expr,pretmp_98,103}
Could not find SSA_NAME representative for
expression:{plus_expr,pretmp_107,104}
Created SSA_NAME representative pretmp_108 for
expression:{plus_expr,pretmp_107,104}
Could not find SSA_NAME representative for
expression:{plus_expr,pretmp_108,105}
Created SSA_NAME representative pretmp_109 for
expression:{plus_expr,pretmp_108,105}
Could not find SSA_NAME representative for
expression:{plus_expr,pretmp_107,105}
Created SSA_NAME representative pretmp_110 for
expression:{plus_expr,pretmp_107,105}
Could not find SSA_NAME representative for expression:{plus_expr,pretmp_98,104}
Created SSA_NAME representative pretmp_111 for
expression:{plus_expr,pretmp_98,104}
Could not find SSA_NAME representative for
expression:{plus_expr,pretmp_111,105}
that eventually leads to a lot of unused pretmp vars.
[Bug sanitizer/55313] libsanitizer cannot be installed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55313 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|REOPENED|WAITING --- Comment #10 from H.J. Lu hjl.tools at gmail dot com 2012-11-22 14:15:14 UTC --- (In reply to comment #9) OK, the problem is that we change the prefix at installation time (by setting the prefix variable on the make install command line). Does make install DESTDIR==foobar work for you?
[Bug c++/55137] [4.8 Regression] Unexpected static structure initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55137 --- Comment #12 from Jason Merrill jason at gcc dot gnu.org 2012-11-22 14:42:06 UTC --- Author: jason Date: Thu Nov 22 14:42:00 2012 New Revision: 193727 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193727 Log: PR c++/55137 * semantics.c (verify_constant): Track overflow separately. (reduced_constant_expression_p): Don't check it here. (cxx_eval_constant_expression): Check it on CSTs. (cxx_eval_outermost_constant_expr): Treat overflows as non-constant at this point, but still return the folded version. (potential_constant_expression_1): Don't check overflow. Added: trunk/gcc/testsuite/g++.dg/init/static-init3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c
[Bug c++/55355] internal compiler error: in tree_low_cst, at tree.c:6415
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55355 Richard Perrin rcp at sentientmeat dot ca changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WORKSFORME | --- Comment #10 from Richard Perrin rcp at sentientmeat dot ca 2012-11-22 14:52:43 UTC --- I am re-opening given comment 9 which provides an additional and apparently necessary reproduction ingredient, namely an i386 platform build. Let me know if there's other info necessary, or if you still cannot reproduce.
[Bug c++/55355] internal compiler error: in tree_low_cst, at tree.c:6415
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55355 --- Comment #11 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-22 15:04:23 UTC --- Still, you reported the issue as fixed in 4_7-branch, thus unless you think it's a regression, it seems highly unlikely that it will be fixed in that branch too, unless you volunteer to actively work on the issue. But by now I think you know that.
[Bug sanitizer/55379] -static -static-libasan pass -Bdynamic to linker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55379 --- Comment #7 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2012-11-22 15:17:26 UTC --- Author: hjl Date: Thu Nov 22 15:17:21 2012 New Revision: 193728 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193728 Log: Issue an error for -static with fsanitize=address PR sanitizer/55379 * gcc.c (LINK_COMMAND_SPEC): Issue an error for -static with -fsanitize=address. Modified: trunk/gcc/ChangeLog trunk/gcc/gcc.c
[Bug sanitizer/55379] -static -static-libasan pass -Bdynamic to linker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55379 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Target Milestone|--- |4.8.0 --- Comment #8 from H.J. Lu hjl.tools at gmail dot com 2012-11-22 15:18:26 UTC --- Fixed.
[Bug sanitizer/55379] -static -static-libasan pass -Bdynamic to linker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55379 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #9 from H.J. Lu hjl.tools at gmail dot com 2012-11-22 15:19:00 UTC --- Fixed.
[Bug c++/55137] [4.8 Regression] Unexpected static structure initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55137 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|4.7.4 |4.8.0 Known to fail|4.8.0 | --- Comment #13 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-22 16:23:36 UTC --- Fixed then, great.
[Bug c++/55442] New: G++ uses up all my RAM when compiling a constexpr with exponential call graph
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55442
Bug #: 55442
Summary: G++ uses up all my RAM when compiling a constexpr with
exponential call graph
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: da...@aitellu.com
I have compiled the following program on GCC 4.7.2 and the latest 4.8, using
Ubuntu 12.10 with Linux kernel 3.5.0:
const int MAXD = 24;
constexpr int count(int n, int depth=1){
return depth == MAXD ? n + 1: count(count(n, depth + 1), depth + 1) + 1;
}
#includeiostream
int main(){
constexpr int i = count(0);
std::cout i std::endl;
}
Both versions of GCC will use over 3.3 gig RAM in about 30 seconds. For each
step I increase MAXD, the RAM usage will double until my computer swaps or the
kernel kills the process.
It will never reach a recursion depth of more than 24, but the call graph is
sort of a binary tree, so it will visit 2^MAXD - 1 nodes. Since the recursion
is so shallow, it should not have to use any memory. Clang 3.1 compiles it
without using any memory.
Before posting this report, I asked on Stackoverflow, where it was suggested I
report it here.
My guess is that this has something to do with unlimited memoization?
[Bug c++/55442] G++ uses up all my RAM when compiling a constexpr with exponential call graph
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55442 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-22 CC||hubicka at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Jan Hubicka hubicka at gcc dot gnu.org 2012-11-22 17:01:08 UTC --- This seems to be frontend issue We spend a lot of time in #102 0x0069ea86 in cxx_eval_constant_expression(constexpr_call const*, tree_node*, bool, bool, bool*) [clone .part.62] () at ../../gcc/cp/semantics.c:7676 #103 0x0069f869 in cxx_eval_constant_expression(constexpr_call const*, tree_node*, bool, bool, bool*) [clone .part.62] () at ../../gcc/cp/semantics.c:6789 #104 0x0069f6ab in cxx_eval_constant_expression(constexpr_call const*, tree_node*, bool, bool, bool*) [clone .part.62] () at ../../gcc/cp/semantics.c:7793 #105 0x0069f1b5 in cxx_eval_constant_expression(constexpr_call const*, tree_node*, bool, bool, bool*) [clone .part.62] () at ../../gcc/cp/semantics.c:7697 #106 0x006a5b5f in cxx_eval_call_expression(constexpr_call const*, tree_node*, bool, bool, bool*) () at ../../gcc/cp/semantics.c:6676 #107 0x0069ea86 in cxx_eval_constant_expression(constexpr_call const*, tree_node*, bool, bool, bool*) [clone .part.62] () at ../../gcc/cp/semantics.c:7676 #108 0x006a55b1 in cxx_eval_call_expression(constexpr_call const*, tree_node*, bool, bool, bool*) () at ../../gcc/cp/semantics.c:6489 #109 0x0069ea86 in cxx_eval_constant_expression(constexpr_call const*, tree_node*, bool, bool, bool*) [clone .part.62] () at ../../gcc/cp/semantics.c:7676 #110 0x0069f869 in cxx_eval_constant_expression(constexpr_call const*, tree_node*, bool, bool, bool*) [clone .part.62] () at ../../gcc/cp/semantics.c:6789 #111 0x0069f6ab in cxx_eval_constant_expression(constexpr_call const*, tree_node*, bool, bool, bool*) [clone .part.62] () at ../../gcc/cp/semantics.c:7793 #112 0x0069f1b5 in cxx_eval_constant_expression(constexpr_call const*, tree_node*, bool, bool, bool*) [clone .part.62] () at ../../gcc/cp/semantics.c:7697 #113 0x006a5b5f in cxx_eval_call_expression(constexpr_call const*, tree_node*, bool, bool, bool*) () at ../../gcc/cp/semantics.c:6676 #114 0x0069ea86 in cxx_eval_constant_expression(constexpr_call const*, tree_node*, bool, bool, bool*) [clone .part.62] () at ../../gcc/cp/semantics.c:7676 #115 0x0069f869 in cxx_eval_constant_expression(constexpr_call const*, tree_node*, bool, bool, bool*) [clone .part.62] () at ../../gcc/cp/semantics.c:6789 #116 0x0069f6ab in cxx_eval_constant_expression(constexpr_call const*, tree_node*, bool, bool, bool*) [clone .part.62] () at ../../gcc/cp/semantics.c:7793 #117 0x0069f1b5 in cxx_eval_constant_expression(constexpr_call const*, tree_node*, bool, bool, bool*) [clone .part.62] () at ../../gcc/cp/semantics.c:7697 #118 0x006a5b5f in cxx_eval_call_expression(constexpr_call const*, tree_node*, bool, bool, bool*) () at ../../gcc/cp/semantics.c:6676 #119 0x0069ea86 in cxx_eval_constant_expression(constexpr_call const*, tree_node*, bool, bool, bool*) [clone .part.62] () at ../../gcc/cp/semantics.c:7676 #120 0x0069f869 in cxx_eval_constant_expression(constexpr_call const*, tree_node*, bool, bool, bool*) [clone .part.62] () at ../../gcc/cp/semantics.c:6789 #121 0x0069f6ab in cxx_eval_constant_expression(constexpr_call const*, tree_node*, bool, bool, bool*) [clone .part.62] () at ../../gcc/cp/semantics.c:7793 #122 0x0069f1b5 in cxx_eval_constant_expression(constexpr_call const*, tree_node*, bool, bool, bool*) [clone .part.62] () at ../../gcc/cp/semantics.c:7697 #123 0x006a5b5f in cxx_eval_call_expression(constexpr_call const*, tree_node*, bool, bool, bool*) () at ../../gcc/cp/semantics.c:6676 #124 0x0069ea86 in cxx_eval_constant_expression(constexpr_call const*, tree_node*, bool, bool, bool*) [clone .part.62] () at ../../gcc/cp/semantics.c:7676 #125 0x006a1c1d in cxx_eval_outermost_constant_expr(tree_node*, bool) () at ../../gcc/cp/semantics.c:7976 #126 0x006a2104 in maybe_constant_value(tree_node*) () at ../../gcc/cp/semantics.c:8080 #127 0x006a2259 in maybe_constant_init(tree_node*) () at ../../gcc/cp/semantics.c:8097 #128 0x005ba0f8 in store_init_value(tree_node*, tree_node*, vectree_node*, va_gc, vl_embed**, int) () at ../../gcc/cp/typeck2.c:717 #129 0x0053cca1 in check_initializer(tree_node*, tree_node*, int, vectree_node*, va_gc, vl_embed**) () at ../../gcc/cp/decl.c:5715 #130 0x0054f816 in cp_finish_decl(tree_node*,
[Bug bootstrap/55388] [4.8 regression] ICE in int_mode_for_mode at stor-layout.c:423 breaks sparc64-linux bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55388 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |ebotcazou at gcc dot |gnu.org |gnu.org Target Milestone|--- |4.8.0 --- Comment #10 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-11-22 17:47:38 UTC --- It's caused by r193599: http://gcc.gnu.org/ml/gcc-cvs/2012-11/msg00546.html Yep, the problem is that alias.c:nonoverlapping_component_refs_p considers that accesses to bitfields never overlap with accesses to other components... I also think that the size handling in set_mem_attributes_minus_bitpos might need to be further refined, now that bitfields are handled: /* Respect mode size. */ attrs.size_known_p = defattrs-size_known_p; attrs.size = defattrs-size; /* ??? Is this really necessary? We probably should always get the size from the type below. */ I don't see how the final size can be smaller than the mode size.
[Bug c++/55443] New: ICE for some placement new expressions inside noexcept operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55443
Bug #: 55443
Summary: ICE for some placement new expressions inside noexcept
operator
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vlu...@gmx.de
Created attachment 28762
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28762
Preprocessed c++ source using placement new inside noexcept
The attached code causes an ICE with both GCC 4.7.2 and a GCC 4.8.0 prerelease.
Output of c++ -v for the latter is:
---
Using built-in specs.
COLLECT_GCC=/home/lima/vanilla_installs/gcc_and_tools/bin/c++
COLLECT_LTO_WRAPPER=/home/lima/vanilla_installs/gcc_and_tools/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc_svn/configure
--prefix=/home/lima/vanilla_installs/gcc_and_tools --enable-__cxa_atexit
--enable-languages=c,c++ --disable-nls --disable-multilib
Thread model: posix
gcc version 4.8.0 20121122 (experimental) (GCC)
---
The command line was:
c++ -std=c++0x noexcept_operator_constexpr.ice.ii
That triggers the following output:
---
noexcept_operator_constexpr.ice.cc: In function 'int main()':
noexcept_operator_constexpr.ice.cc:9:30: in constexpr expansion of
'((X*)anonymous)-X::X()'
noexcept_operator_constexpr.ice.cc:9:31: internal compiler error: in
cxx_eval_call_expression, at cp/semantics.c:6687
};
^
0x6b742f cxx_eval_call_expression
../../gcc_svn/gcc/cp/semantics.c:6686
0x6b05bb cxx_eval_constant_expression
../../gcc_svn/gcc/cp/semantics.c:7672
0x6b1f28 is_sub_constant_expr(tree_node*)
../../gcc_svn/gcc/cp/semantics.c:8047
0x6732a7 check_noexcept_r
../../gcc_svn/gcc/cp/except.c:1162
0xcaa5bb walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, pointer_set_t*, tree_node* (*)(tree_node**, int*, tree_node*
(*)(tree_node**, int*, void*), void*, pointer_set_t*))
../../gcc_svn/gcc/tree.c:10655
0xcaaa9d walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, pointer_set_t*, tree_node* (*)(tree_node**, int*, tree_node*
(*)(tree_node**, int*, void*), void*, pointer_set_t*))
../../gcc_svn/gcc/tree.c:10909
0xcaaa9d walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, pointer_set_t*, tree_node* (*)(tree_node**, int*, tree_node*
(*)(tree_node**, int*, void*), void*, pointer_set_t*))
../../gcc_svn/gcc/tree.c:10909
0xcaa0e4 walk_tree_without_duplicates_1(tree_node**, tree_node*
(*)(tree_node**, int*, void*), void*, tree_node* (*)(tree_node**, int*,
tree_node* (*)(tree_node**, int*, void*), void*, pointer_set_t*))
../../gcc_svn/gcc/tree.c:10936
0x672e6d expr_noexcept_p(tree_node*, int)
../../gcc_svn/gcc/cp/except.c:1239
0x673004 finish_noexcept_expr(tree_node*, int)
../../gcc_svn/gcc/cp/except.c:1224
0x62d116 cp_parser_unary_expression
../../gcc_svn/gcc/cp/parser.c:6554
0x62db17 cp_parser_binary_expression
../../gcc_svn/gcc/cp/parser.c:7344
0x62dfb6 cp_parser_assignment_expression
../../gcc_svn/gcc/cp/parser.c:7569
0x62fee2 cp_parser_expression
../../gcc_svn/gcc/cp/parser.c:7720
0x6305fe cp_parser_expression_statement
../../gcc_svn/gcc/cp/parser.c:9000
0x626557 cp_parser_statement
../../gcc_svn/gcc/cp/parser.c:8852
0x6277de cp_parser_statement_seq_opt
../../gcc_svn/gcc/cp/parser.c:9118
0x627926 cp_parser_compound_statement
../../gcc_svn/gcc/cp/parser.c:9072
0x638e33 cp_parser_function_body
../../gcc_svn/gcc/cp/parser.c:17648
0x638e33 cp_parser_ctor_initializer_opt_and_function_body
../../gcc_svn/gcc/cp/parser.c:17684
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
---
Some variations of the attached code crash the compiler too. One of them is:
#include stddef.h
struct X {
X() = default;
X(int);
void* operator new(size_t, void*) noexcept;
};
X x;
bool b = noexcept(new(0) X);
-
With respect to the code snippet immediately above, the compiler does not
produce an ICE when any single item of the following is applied:
1. Removing the variable definition of x.
2. Changing the variable definition to X x{0};.
3. Removing
[Bug bootstrap/55388] [4.8 regression] ICE in int_mode_for_mode at stor-layout.c:423 breaks sparc64-linux bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55388 --- Comment #11 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-11-22 18:26:05 UTC --- In fact the miscompilation is already eliminated by replacing the call to adjust_address with adjust_bitfield_address in store_bit_field. Not clear what I was thinking when I left this one out...
[Bug target/54895] the compiler treats '__cdecl' '__stdcall' as the same.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54895 --- Comment #5 from niXman i.nixman at gmail dot com 2012-11-22 18:37:55 UTC --- (In reply to comment #4) This is most likely a duplicate of already fixed PR/55268. I checked upon the 193725 revision. The first test gives the same result. The second test now gives the wrong result(1). Before this the result of the second test was right.
[Bug target/54895] the compiler treats '__cdecl' '__stdcall' as the same.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54895 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-22 Ever Confirmed|0 |1 --- Comment #6 from Kai Tietz ktietz at gcc dot gnu.org 2012-11-22 18:48:18 UTC --- (In reply to comment #5) (In reply to comment #4) This is most likely a duplicate of already fixed PR/55268. I checked upon the 193725 revision. The first test gives the same result. The second test now gives the wrong result(1). Before this the result of the second test was right. Well, the first test fails due the calling-convention isn't part of the signature in C++. For C you will get for this code simply a double-definition. Issue here is that we don't get an error for g++ as it detects that a types are different for both myfoo functions. The second case checks something different. That it now returns 1 is correct due types are different due different calling-convention used. So remaining testcase is the first one.
[Bug c++/55014] ICE: Segmentation fault while compiling complex_io.cc on x86_64-w64-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55014 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-22 CC||ktietz at gcc dot gnu.org Component|target |c++ Ever Confirmed|0 |1 Known to fail||4.4.0, 4.5.0, 4.6.0, 4.7.0 --- Comment #7 from Kai Tietz ktietz at gcc dot gnu.org 2012-11-22 18:51:35 UTC --- it is actual not a target issue. it is more a general c++ issue as calling-convention (call-abi attributes) aren't part of signature.
[Bug c++/55014] ICE: Segmentation fault while compiling complex_io.cc on x86_64-w64-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55014 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|NEW |UNCONFIRMED Ever Confirmed|1 |0 Known to fail|4.4.0, 4.5.0, 4.6.0, 4.7.0 | --- Comment #8 from Kai Tietz ktietz at gcc dot gnu.org 2012-11-22 18:53:30 UTC --- Ups, wrong bug. please ignore last comment here
[Bug c++/54895] the compiler treats '__cdecl' '__stdcall' as the same.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54895 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Component|target |c++ Known to work||4.4.0, 4.5.0, 4.6.0, 4.7.0, ||4.8.0 --- Comment #7 from Kai Tietz ktietz at gcc dot gnu.org 2012-11-22 18:55:40 UTC --- it is actual not a target issue. it is more a general c++ issue as calling-convention (call-abi attributes) aren't part of signature.
[Bug c++/55443] ICE for some placement new expressions inside noexcept operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55443 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-22 CC||jason at gcc dot gnu.org, ||paolo.carlini at oracle dot ||com Ever Confirmed|0 |1 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-22 19:06:42 UTC --- I find this disturbing. How the evaluation of: noexcept(new(0) X); can possibly be affected be a previous: X x; ??? Jason, any tip?
[Bug c++/54895] the compiler treats '__cdecl' '__stdcall' as the same.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54895 --- Comment #8 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-22 19:08:14 UTC --- So it works everywhere? ;)
[Bug c++/54895] the compiler treats '__cdecl' '__stdcall' as the same.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54895 --- Comment #9 from Kai Tietz ktietz at gcc dot gnu.org 2012-11-22 19:11:12 UTC --- (In reply to comment #8) So it works everywhere? ;) Well, it doesn't work for all targets providing different calling-conventions for functions. Eg functions with regparm, stdcall, etc That the sample is architecture specific, doesn't make it there for target specific, isn't it? ;)
[Bug c++/54895] the compiler treats '__cdecl' '__stdcall' as the same.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54895 --- Comment #10 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-22 19:14:03 UTC --- I don't know, I'm still finding the Known to work field pretty weird, to be honest.
[Bug c++/54895] the compiler treats '__cdecl' '__stdcall' as the same.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54895 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Known to work|4.4.0, 4.5.0, 4.6.0, 4.7.0, | |4.8.0 | Known to fail||4.4.0, 4.5.0, 4.6.0, 4.7.0, ||4.8.0 --- Comment #11 from Kai Tietz ktietz at gcc dot gnu.org 2012-11-22 19:15:49 UTC --- heh, oh duhh :}
[Bug c++/55355] internal compiler error: in tree_low_cst, at tree.c:6415
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55355 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #12 from Mikael Pettersson mikpe at it dot uu.se 2012-11-22 23:25:45 UTC --- It's a HWI32 bug. The ICE reproduces on x86 with 4.6 branch if you build a 32-bit compiler that targets 32-bit x86; passing -m32 to a 64-bit compiler won't trigger it. The ICE was silenced on 32-bit x86 for 4.7 by r176871: http://gcc.gnu.org/ml/gcc-cvs/2011-07/msg01139.html which is when HJ made 32-bit x86 HWI64. The ICE reproduces with current 4.7 and 4.8 in 32-bit compilers with HWI32 targets; for instance an i686 to m68k linux cross says: pr55355.cc: In member function 'void C::funcC()': pr55355.cc:34:1: internal compiler error: in tree_low_cst, at tree.c:6603 } ^ 0x856174f tree_low_cst(tree_node const*, int) /mnt/scratch/gcc-4.8-20121118/gcc/tree.c:6603 0x856179e int_bit_position(tree_node const*) /mnt/scratch/gcc-4.8-20121118/gcc/tree.c:2480 0x846af0b type_internals_preclude_sra_p /mnt/scratch/gcc-4.8-20121118/gcc/tree-sra.c:719 0x846af0b type_internals_preclude_sra_p /mnt/scratch/gcc-4.8-20121118/gcc/tree-sra.c:678 0x8471e1f find_param_candidates /mnt/scratch/gcc-4.8-20121118/gcc/tree-sra.c:3627 0x8471e1f ipa_early_sra /mnt/scratch/gcc-4.8-20121118/gcc/tree-sra.c:4928 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions.
[Bug fortran/55444] New: Rejects valid code with USE ISO_C_BINDING in BLOCK DATA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55444 Bug #: 55444 Summary: Rejects valid code with USE ISO_C_BINDING in BLOCK DATA Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org Reported by at Henrik Holst athttps://groups.google.com/forum/?fromgroups=#!topic/comp.lang.fortran/aOMi2iZ-2c8 The following program prints bogus errors of the form: USE ISO_C_BINDING ! FAILS 1 Error: INTENT attribute not allowed in BLOCK DATA program unit at (1) Error: EXTERNAL attribute not allowed in BLOCK DATA program unit at (1) BLOCKDATA ! USE ISO_C_BINDING, ONLY: C_INT, C_FLOAT ! WORKS USE :: ISO_C_BINDING ! FAILS INTEGER(C_INT) X REAL(C_FLOAT) Y COMMON /FOO/ X,Y BIND(C,NAME='fortranStuff') /FOO/ DATA X /1/ DATA Y /2.0/ END BLOCKDATA * * * The message is printed in check_conflict where the following is true: if (gfc_current_state () == COMP_BLOCK_DATA) The caller is resolve_contained_functions – the question is why the symbols end up there (seemingly also functions like c_backspace of flavour parameter)? The message is printed for the SHAPE= argument of c_f_pointer.
[Bug middle-end/55198] [4.8 Regression] libquadmath/math/fmaq.c:233:7: internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55198 --- Comment #4 from John David Anglin danglin at gcc dot gnu.org 2012-11-23 00:39:12 UTC --- Created attachment 28763 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28763 Testcase
[Bug middle-end/55198] [4.8 Regression] libquadmath/math/fmaq.c:233:7: internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55198 --- Comment #5 from John David Anglin danglin at gcc dot gnu.org 2012-11-23 00:40:06 UTC --- Created attachment 28764 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28764 Patch Testing.
[Bug middle-end/55438] [4.8 Regression]: tmpdir-gcc.dg-struct-layout-1/t001 - t028, gcc.c-torture/execute/991118-1.c, gcc.c-torture/execute/bf64-1.c, ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55438 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added Summary|[4.8 Regression]: |[4.8 Regression]: |tmpdir-gcc.dg-struct-layout |tmpdir-gcc.dg-struct-layout |-1/t001 - t028 ICE |-1/t001 - t028, ||gcc.c-torture/execute/99111 ||8-1.c, ||gcc.c-torture/execute/bf64- ||1.c, ICE --- Comment #1 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-11-23 00:44:36 UTC --- Actually, there are two more regressions: Running /tmp/hpautotest-gcc0/gcc/gcc/testsuite/gcc.c-torture/execute/execute.exp ... FAIL: gcc.c-torture/execute/991118-1.c compilation, -O0 (internal compiler error) FAIL: gcc.c-torture/execute/991118-1.c compilation, -O1 (internal compiler error) FAIL: gcc.c-torture/execute/991118-1.c compilation, -O2 (internal compiler error) FAIL: gcc.c-torture/execute/991118-1.c compilation, -O3 -fomit-frame-pointer (internal compiler error) FAIL: gcc.c-torture/execute/991118-1.c compilation, -O3 -g (internal compiler error) FAIL: gcc.c-torture/execute/991118-1.c compilation, -Os (internal compiler error) FAIL: gcc.c-torture/execute/991118-1.c compilation, -Og -g (internal compiler error) FAIL: gcc.c-torture/execute/991118-1.c compilation, -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error) FAIL: gcc.c-torture/execute/bf64-1.c compilation, -O0 (internal compiler error) FAIL: gcc.c-torture/execute/bf64-1.c compilation, -O1 (internal compiler error) FAIL: gcc.c-torture/execute/bf64-1.c compilation, -O2 (internal compiler error) FAIL: gcc.c-torture/execute/bf64-1.c compilation, -O3 -fomit-frame-pointer (internal compiler error) FAIL: gcc.c-torture/execute/bf64-1.c compilation, -O3 -g (internal compiler error) FAIL: gcc.c-torture/execute/bf64-1.c compilation, -Os (internal compiler error) FAIL: gcc.c-torture/execute/bf64-1.c compilation, -Og -g (internal compiler error) FAIL: gcc.c-torture/execute/bf64-1.c compilation, -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error) Similar messages in gcc.log as for the struct-layout-1 regressions.
[Bug middle-end/55430] [4.8 Regression] LRA miscompilation of ree.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55430 --- Comment #2 from Vladimir Makarov vmakarov at gcc dot gnu.org 2012-11-23 01:29:13 UTC --- Author: vmakarov Date: Fri Nov 23 01:29:07 2012 New Revision: 193742 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193742 Log: 2012-11-22 Vladimir Makarov vmaka...@redhat.com PR middle-end/55430 * lra.c: Move #include hard-reg-set.h before #include rtl.h. (new_insn_reg): Update biggest_mode. (collect_non_operand_hard_regs): Check eliminable regs too. (initialize_lra_reg_info_element): Initialize biggest_mode. (add_regs_to_insn_regno_info): Ignore non-allocatable non-eliminable hard regs. (lra.c): Move setting lra_no_alloc_regs before init_insn_recog_data. * lra-constraints.c (simplify_operand_subreg): Add a comment. (lra_constraints): Ignore equivalent memory of regs occuring in paradoxical subregs. * lra-lives.c (lra_create_live_ranges): Add a comment. Modified: trunk/gcc/ChangeLog trunk/gcc/lra-constraints.c trunk/gcc/lra-lives.c trunk/gcc/lra.c
[Bug target/55445] New: Always defined __SEH__ when build from trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55445
Bug #: 55445
Summary: Always defined __SEH__ when build from trunk
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: alex...@gmail.com
When I try to build gcc from trunk with mingw-w64 I successfully build
only 64bit with seh exceptions. Other builds stop on error:
../../../../../../mingw-sources/gcc-trunk/libgcc/unwind-c.c:238:1:
warning: no previous prototype for '__gcc_personality_seh0'
[-Wmissing-prototypes]
__gcc_personality_seh0 (PEXCEPTION_RECORD ms_exc, void *this_frame,
^
../../../../../../mingw-sources/gcc-trunk/libgcc/unwind-c.c: In
function '__gcc_personality_seh0':
../../../../../../mingw-sources/gcc-trunk/libgcc/unwind-c.c:242:14:
error: '__gcc_personality_imp' undeclared (first use in this function)
ms_disp, __gcc_personality_imp);
^
../../../../../../mingw-sources/gcc-trunk/libgcc/unwind-c.c:242:14:
note: each undeclared identifier is reported only once for each
function it appears in
../../../../../../mingw-sources/gcc-trunk/libgcc/unwind-c.c: At top level:
../../../../../../mingw-sources/gcc-trunk/libgcc/unwind-c.c:94:33:
warning: '__gcc_personality_sj0' defined but not used
[-Wunused-function]
#define PERSONALITY_FUNCTION__gcc_personality_sj0
^
../../../../../../mingw-sources/gcc-trunk/libgcc/unwind-c.c:120:1:
note: in expansion of macro 'PERSONALITY_FUNCTION'
PERSONALITY_FUNCTION (int version,
^
../../../../../../mingw-sources/gcc-trunk/libgcc/unwind-c.c: In
function '__gcc_personality_seh0':
../../../../../../mingw-sources/gcc-trunk/libgcc/unwind-c.c:243:1:
warning: control reaches end of non-void function [-Wreturn-type]
}
^
make[4]: *** [unwind-c.o] Error 1
make[4]: *** Waiting for unfinished jobs
I find that __SEH__ defined in gcc/config/i386/cygming.h as
.
#undef TARGET_SEH
#define TARGET_SEH (TARGET_64BIT_MS_ABI flag_unwind_tables)
#define TARGET_OS_CPP_BUILTINS() \
do \
{ \
if (!TARGET_64BIT) \
builtin_define (_X86_=1); \
if (TARGET_SEH) \
builtin_define (__SEH__);
.
As I think __SEH__ is always defined that leads to error.
[Bug sanitizer/55354] [asan] by default, the asan run-time should be linked statically, not dynamically
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55354 --- Comment #22 from Dmitry Vyukov dvyukov at google dot com 2012-11-23 07:16:14 UTC --- For dynamic libraries that are loaded into a non-instrumented executable (e.g. swig so preloaded into python process), we statically link the tsan runtime into the so. And you don't get linker errors from that? That must be by pure luck. Why must I get errors in this case?
[Bug sanitizer/55354] [asan] by default, the asan run-time should be linked statically, not dynamically
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55354 --- Comment #23 from Dmitry Vyukov dvyukov at google dot com 2012-11-23 07:27:27 UTC --- (In reply to comment #21) (In reply to comment #20) What I see is that it also affect code generation (register allocation). Do we need to file a bug on that? If you see a code generation difference even with -ftls-model=local-exec -fPIC vs. -fPIE, then it must mean you don't have visibility attributes on the symbols used in the fast path. For initial-exec, the RA effects should be minimal, the TLS offset load from got is usually very close to the actual TLS memory load (or lea), and thus it will just pick up some short lived scratch register. Generally in GCC, -fPIE sets flag_pic and not flag_shlib, while -fPIC sets flag_pic and flag_shlib. flag_pic is about whether position independent code needs to be generated, flag_shlib is about whether locally defined symbols can be interposed (plus it affects TLS model default choice). When I compile with -fvisibility=hidden, it does not affect generated code. It's not that we access a lot of symbols in the function, there is one thread-local and one static global var. That minimal RA effects do have effect in our case. We don't have a reserve to squeeze another register for tls access: // -fPIE 0009ca30 __tsan_write2: 9ca30: 64 48 8b 04 25 40 1fmov%fs:0xffeb1f40,%rax 9ca37: eb ff 9ca39: 48 8b 0c 24 mov(%rsp),%rcx 9ca3d: a8 01 test $0x1,%al 9ca3f: 0f 85 d3 00 00 00 jne9cb18 __tsan_write2+0xe8 9ca45: 48 83 e8 80 sub$0xff80,%rax 9ca49: 48 89 femov%rdi,%rsi 9ca4c: 48 89 c2mov%rax,%rdx 9ca4f: 64 48 89 04 25 40 1fmov%rax,%fs:0xffeb1f40 9ca56: eb ff // -fPIC -ftls-model=initial-exec 000969f0 __tsan_write2: 969f0: 48 c7 c2 40 1f eb ffmov$0xffeb1f40,%rdx 969f7: 53 push %rbx 969f8: 48 8b 4c 24 08 mov0x8(%rsp),%rcx 969fd: 64 48 8b 02 mov%fs:(%rdx),%rax 96a01: a8 01 test $0x1,%al 96a03: 0f 85 c7 00 00 00 jne96ad0 __tsan_write2+0xe0
[Bug target/52910] xop-mul-1:f13 miscompiled on bulldozer (-mxop)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52910 --- Comment #2 from Uros Bizjak ubizjak at gmail dot com 2012-11-23 07:42:38 UTC --- Current mainline compiles f13 to: f13: vpxor%xmm0, %xmm0, %xmm0 xorl%eax, %eax .L36: vmovdqac2(%rax), %xmm2 addq$16, %rax vpmacsdqh%xmm0, c3-16(%rax), %xmm2, %xmm0 vpmacsdql%xmm0, c3-16(%rax), %xmm2, %xmm0 cmpq$2048, %rax jne.L36 vpsrldq$8, %xmm0, %xmm1 vpaddq%xmm0, %xmm1, %xmm0 vpextrq$0, %xmm0, %rax ret Does this work OK?
[Bug target/53071] Wrong instruction replacement when compiling for xop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53071 --- Comment #1 from Uros Bizjak ubizjak at gmail dot com 2012-11-23 07:49:41 UTC --- Resulting asm is quite different w/ current mainline: _Z4testU8__vectorxS_S_: vmovdqa%xmm2, -24(%rsp) vpsrlq$32, %xmm0, %xmm3 vpmuldq%xmm1, %xmm0, %xmm2 vpmuldq%xmm1, %xmm3, %xmm1 vpand.LC0(%rip), %xmm1, %xmm1 vpsrlq$32, %xmm2, %xmm2 vmovd-24(%rsp), %xmm4 vpor%xmm1, %xmm2, %xmm1 vpaddd%xmm0, %xmm1, %xmm1 vpsrad$31, %xmm0, %xmm0 vpsrad%xmm4, %xmm1, %xmm1 vpsubd%xmm0, %xmm1, %xmm0 ret _Z5test2U8__vectorxS_S_: vpxor%xmm3, %xmm3, %xmm3 vmovdqa%xmm2, -24(%rsp) vpmuldq%xmm1, %xmm0, %xmm2 vpsrlq$32, %xmm2, %xmm2 vpmacsdqh%xmm3, %xmm1, %xmm0, %xmm1 vpand.LC0(%rip), %xmm1, %xmm1 vmovd-24(%rsp), %xmm4 vpor%xmm1, %xmm2, %xmm1 vpaddd%xmm0, %xmm1, %xmm1 vpsrad$31, %xmm0, %xmm0 vpsrad%xmm4, %xmm1, %xmm1 vpsubd%xmm0, %xmm1, %xmm0 ret
[Bug rtl-optimization/55388] [4.8 regression] ICE in int_mode_for_mode at stor-layout.c:423
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55388 --- Comment #12 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org 2012-11-23 07:55:56 UTC --- (In reply to comment #9) Richard, did you already start to investigate seriously? If no, I can take it over if you want, it's SPARC and I have a big share in the problematic patch. Sorry, was away yesterday, so it would have been not yet. But it looks like you've already pinned it, thanks!
