[Bug tree-optimization/14792] ((int)b & 1) != 0 is not folded to b & 1 != 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14792 Andrew Pinski changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |pinskia at gcc dot gnu.org |gnu.org | --- Comment #10 from Andrew Pinski 2012-02-12 09:21:00 UTC --- This is fixed on the trunk as we fold ((int)a) & 1 into (int)(a&1) in forwprop though that causes other issues so I am disabling that folding and am going to implement the folding of (((int)a) & 1) != 0 in forwprop.
[Bug tree-optimization/14541] [tree-ssa] built-in math functions are not fully optimized at tree level
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14541 Andrew Pinski changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |pinskia at gcc dot gnu.org |gnu.org | --- Comment #15 from Andrew Pinski 2012-02-12 09:23:28 UTC --- I will implement this combing in forwprop (since that is where we are doing all the combing optimizations now).
[Bug target/52205] SPARC Solaris 2.11 unwind through signal handler fails with -fnon-call-exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52205 Eric Botcazou changed: What|Removed |Added Status|REOPENED|ASSIGNED AssignedTo|unassigned at gcc dot |ebotcazou at gcc dot |gnu.org |gnu.org --- Comment #4 from Eric Botcazou 2012-02-12 10:06:07 UTC --- Fixing.
[Bug c++/52213] New: Add chunk of memory if array is size is divisable with 8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52213
Bug #: 52213
Summary: Add chunk of memory if array is size is divisable with
8
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jovica.sa...@gmail.com
When i create array of chars and before using I initialize char to some special
char value, like _. If char array size is divisible with 8, array became bigger
and filled with chunk of memory data. If you run attached sample code, you will
see. Interesting thing that is happened only with 8 divisors.
int main(){
for (int i = 1; i < 100; i++){
char* name = new char[i];
for (int j=0; j
[Bug middle-end/52214] New: [4.7 Regression] FAIL: g++.dg/tree-ssa/pr44706.C -std=gnu++* scan-tree-dump-not fnsplit "Splitting function"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52214 Bug #: 52214 Summary: [4.7 Regression] FAIL: g++.dg/tree-ssa/pr44706.C -std=gnu++* scan-tree-dump-not fnsplit "Splitting function" Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: hubi...@gcc.gnu.org The test g++.dg/tree-ssa/pr44706.C fails since revision 184089 (see http://gcc.gnu.org/ml/gcc-regression/2012-02/msg00024.html ).
[Bug libstdc++/52215] New: [4.7 Regression] FAIL: ext/profile/mutex_extensions_neg.cc (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52215 Bug #: 52215 Summary: [4.7 Regression] FAIL: ext/profile/mutex_extensions_neg.cc (test for excess errors) Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: b...@redhat.com, jwakely@gmail.com Between revisions 184107 (OK) and 184111 (see http://gcc.gnu.org/ml/gcc-regression/2012-02/msg00033.html and http://gcc.gnu.org/ml/gcc-regression/2012-02/msg00035.html , likely r184110), the test ext/profile/mutex_extensions_neg.cc has started to fail with -m32. The error is FAIL: ext/profile/mutex_extensions_neg.cc (test for excess errors) Excess errors: /opt/gcc/build_w/x86_64-apple-darwin10.8.0/i386/libstdc++-v3/include/profile/impl/profiler_state.h:52:28: error: conversion from 'enum __gnu_profile::__state_type*' to 'enum __gnu_profile::__state_type' [-fpermissive]
[Bug c++/52212] friend declaration doesn't see previous friend of same function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52212 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #2 from Daniel Krügler 2012-02-12 13:26:04 UTC --- My reading of 11.3 p9, "A name nominated by a friend declaration shall be accessible in the scope of the class containing the friend declaration." tends to be that the example should ill-formed (D has no access to the name D::E::F).
[Bug c++/52213] Add chunk of memory if array is size is divisable with 8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52213
--- Comment #1 from Jonathan Wakely 2012-02-12
13:44:17 UTC ---
Please provide *complete* testcases, this code is missing and
, since you already wrote it so it compiles why should we have to add
headers again to test it?
(In reply to comment #0)
>
> int main(){
>
> for (int i = 1; i < 100; i++){
> char* name = new char[i];
the array elements will be uninitialized
> for (int j=0; j int length = strlen(name);
This is undefined behaviour, there is no null terminator in the array, how is
strlen supposed to find the length?
[Bug libstdc++/52215] [4.7 Regression] FAIL: ext/profile/mutex_extensions_neg.cc (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52215 --- Comment #1 from Jonathan Wakely 2012-02-12 13:57:32 UTC --- It makes no sense unless the signature of __atomic_compare_exchange_n is different when -m32 is used! Looking into it ...
[Bug c/52190] question about atomic intrinsics -- test and documentation vary -- please clarify
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52190 --- Comment #4 from Jonathan Wakely 2012-02-12 14:02:42 UTC --- The docs for __atomic_compare_exchange_n say: "True is returned if *desired is written into *ptr" but desired is not a pointer, that asterisk should go, right?
[Bug c++/52213] Add chunk of memory if array is size is divisable with 8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52213 --- Comment #2 from Jovica 2012-02-12 14:03:33 UTC --- I know this should be undefined behaviour but i drew attention to it only happens when there is a length divided by 8. That's why I wrote this bug, to pay attention to this.
[Bug c++/52215] [4.7 Regression] FAIL: ext/profile/mutex_extensions_neg.cc (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52215
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-02-12
CC||amacleod at redhat dot com
Component|libstdc++ |c++
Ever Confirmed|0 |1
--- Comment #2 from Jonathan Wakely 2012-02-12
14:13:38 UTC ---
Confirmed, this works with -m64 but fails with -m32
enum E { EE };
int main()
{
E e = EE;
__atomic_compare_exchange_n(&e, &e, e, true, __ATOMIC_ACQ_REL,
__ATOMIC_RELAXED);
}
cas.cc:6:82: error: conversion from ‘enum E*’ to ‘enum E’ [-fpermissive]
[Bug c++/52213] Add chunk of memory if array is size is divisable with 8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52213 --- Comment #3 from Jonathan Wakely 2012-02-12 14:19:13 UTC --- You ask for some memory, you get some memory of at least that size, you look at bytes after the allocated memory and get weird behaviour. That's a bug in your program not G++.
[Bug c++/52213] Add chunk of memory if array is size is divisable with 8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52213 Jovica changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #4 from Jovica 2012-02-12 14:22:49 UTC --- Not a bug.
[Bug c++/52215] __atomic_compare_exchange_n for enumeration type changes signature with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52215 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid CC|jwakely.gcc at gmail dot|redi at gcc dot gnu.org |com | Summary|[4.7 Regression] FAIL: |__atomic_compare_exchange_n |ext/profile/mutex_extension |for enumeration type |s_neg.cc (test for excess |changes signature with -m32 |errors) | --- Comment #3 from Jonathan Wakely 2012-02-12 14:23:54 UTC --- It's the second parameter which has the wrong type, this works with -m32: __atomic_compare_exchange_n(&e, e, e, true, __ATOMIC_ACQ_REL, __ATOMIC_RELAXED);
[Bug c++/52216] New: [C++11][noexcept] Wrong exception deduction for some forms of placement new
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52216
Bug #: 52216
Summary: [C++11][noexcept] Wrong exception deduction for some
forms of placement new
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.krueg...@googlemail.com
gcc 4.7.0 20111210 (experimental) rejects the following program:
//--
#include
int n;
static_assert(!noexcept(::new (std::nothrow) int[n]), "");
//--
Further the following program aborts even though it shouldn't:
//---
#include
extern "C" void abort();
void test_too_small(int n) {
new (std::nothrow) int[n]{1,2,3,4};
}
int main()
{
bool f = false;
try {
test_too_small(3);
} catch (...) {
f = true;
}
if (!f)
abort();
}
//---
Rationale: According to [expr.new] p7:
"[..] if the new-initializer is a bracedinit-list for which the number of
initializer-clauses exceeds the number of elements to initialize, no storage
is obtained and the new-expression terminates by throwing an exception of a
type that would match a handler (15.3) of type std::bad_array_new_length
(18.6.2.2)."
I guess that part of the problem is due to the currently missing support of
type std::bad_array_new_length.
[Bug boehm-gc/52217] New: [boehm-gc] revision 184100 causes segmentation fault in mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52217 Bug #: 52217 Summary: [boehm-gc] revision 184100 causes segmentation fault in mingw32 Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: critical Priority: P3 Component: boehm-gc AssignedTo: unassig...@gcc.gnu.org ReportedBy: jojel...@gmail.com Created attachment 26642 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26642 proposed fix with gcc built on trunk git-a40d9b7c, and tried testing ExtraClassLoader and got segmentation fault with following backtrace (gdb) bt #0 0x69cee9b6 in GC_is_black_listed (h=h@entry=0xa4a000, len=len@entry=0x1000) at ../.././boehm-gc/blacklst.c:242 #1 0x69cecbf2 in GC_allochblk_nth (sz=0x2, kind=0x1, flags=0x0, n=0x6) at ../.././boehm-gc/allchblk.c:646 #2 0x69ced06c in GC_allochblk (sz=sz@entry=0x2, kind=kind@entry=0x1, flags=flags@entry=0x0) at ../.././boehm-gc/allchblk.c:561 #3 0x69cf6c93 in GC_new_hblk (sz=sz@entry=0x2, kind=kind@entry=0x1) at ../.././boehm-gc/new_hblk.c:253 #4 0x69cee57e in GC_allocobj (sz=sz@entry=0x2, kind=kind@entry=0x1) at ../.././boehm-gc/alloc.c:1078 #5 0x69cf2546 in GC_generic_malloc_inner (lb=0x4, k=0x1) at ../.././boehm-gc/malloc.c:136 #6 0x69cf2609 in GC_generic_malloc_inner_ignore_off_page (lb=lb@entry=0x4, k=k@entry=0x1) at ../.././boehm-gc/malloc.c:173 #7 0x69cf0502 in GC_grow_table (table=table@entry=0x6a3b3fa8, log_size_ptr=log_size_ptr@entry=0x6a029d60) at ../.././boehm-gc/finalize.c:112 #8 0x69cf09d4 in GC_register_finalizer_inner (obj=obj@entry=0xa47fa0, fn=fn@entry=0x696d2530 , cd=cd@entry=0x696c9580, ofn=ofn@entry=0x0, ocd=ocd@entry=0x0, mp=mp@entry=0x69cf0330 ) at ../.././boehm-gc/finalize.c:361 #9 0x69cf0bc7 in GC_register_finalizer_no_order (obj=0xa47fa0, fn=0x696d2530 , cd=0x696c9580, ofn=0x0, ocd=0x0) at ../.././boehm-gc/finalize.c:519 #10 0x696d2df0 in _Jv_RegisterFinalizer (object=0xa47fa0, meth=0x696c9580 <_Jv_FinalizeString(java::lang::Object*)>) at ../.././libjava/boehm.cc:421 #11 0x696c987c in _Jv_NewStringUtf8Const (str=0x6a0456b4) at ../.././libjava/java/lang/natString.cc:312 #12 0x696922b2 in _Jv_Linker::ensure_class_linked (klass=0x69d50180) at ../.././libjava/link.cc:1761 #13 0x69690d04 in _Jv_Linker::wait_for_state (klass=0x69d50180, state=0x9) at ../.././libjava/link.cc:2076 #14 0x696c5407 in java::lang::Class::initializeClass (this=0x69d50180) at ../.././libjava/java/lang/natClass.cc:728 #15 0x696c54fc in _Jv_InitClass (klass=) at ../.././libjava/java/lang/Class.h:742 #16 java::lang::Class::initializeClass (this=0x69d503c0) at ../.././libjava/java/lang/natClass.cc:769 #17 0x69682879 in _Jv_InitClass (klass=0x69d503c0) at ../.././libjava/java/lang/Class.h:742 #18 _Jv_AllocObjectNoFinalizer (klass=klass@entry=0x69d503c0) at ../.././libjava/prims.cc:585 #19 0x696827b7 in _Jv_AllocObject (klass=0x69d503c0) at ../.././libjava/prims.cc:596 #20 0x696c671b in _Jv_NewClass (name=0xa47fc0, superclass=0x69d50180, loader=0x0) at ../.././libjava/java/lang/natClassLoader.cc:572 #21 0x696c683d in _Jv_NewArrayClass (element=0x69d503c0, loader=0x0, array_vtable=0x0) at ../.././libjava/java/lang/natClassLoader.cc:642 #22 0x69682ffd in _Jv_GetArrayClass (loader=0x0, klass=) at ../.././libjava/java/lang/Class.h:754 #23 _Jv_FindClassFromSignature (sig=, sig@entry=0x6a045dd6 "[Ljava.lang.Class;", loader=loader@entry=0x0, endp=endp@entry=0x0) at ../.././libjava/prims.cc:923 #24 0x6968302f in _Jv_FindClassFromSignatureNoException ( sig=0x6a045dd6 "[Ljava.lang.Class;", loader=0x0, endp=0x0) at ../.././libjava/prims.cc:936 #25 0x696920b7 in _Jv_Linker::resolve_pool_entry ( klass=klass@entry=0x69d503c0, index=index@entry=0x16, lazy=lazy@entry=0x1) at ../.././libjava/link.cc:438 #26 0x696923dd in _Jv_Linker::ensure_class_linked (klass=0x69d503c0) at ../.././libjava/link.cc:1748 #27 0x69690d04 in _Jv_Linker::wait_for_state (klass=0x69d503c0, state=0x9) at ../.././libjava/link.cc:2076 #28 0x696c5407 in java::lang::Class::initializeClass (this=0x69d503c0) at ../.././libjava/java/lang/natClass.cc:728 #29 0x69682879 in _Jv_InitClass (klass=0x69d503c0) at ../.././libjava/java/lang/Class.h:742 #30 _Jv_AllocObjectNoFinalizer (klass=klass@entry=0x69d503c0) at ../.././libjava/prims.cc:585 #31 0x696827b7 in _Jv_AllocObject (klass=0x69d503c0) at ../.././libjava/prims.cc:596 #32 0x696c671b in _Jv_NewClass (name=0xa47fe0, superclass=0x69d50180, loader=0x0) at ../.././libjava/java/lang/natClassLoader.cc:572 #33 0x696c683d in _Jv_NewArrayClass (element=0x69d50180, loader=0x0, array_vtable=0x0) at ../.././libjava/java/lang/natClassLoader.cc:642 #34 0x69682ffd in _Jv_GetArrayClass (loader=0x0, klass=) at ../.././libjava/java/lang/Class.h:754 #35 _Jv_FindClassFr
[Bug lto/48094] ld: warning: section has unexpectedly large size errors in objc/obj-c++ lto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48094 --- Comment #15 from Iain Sandoe 2012-02-12 14:43:49 UTC --- this var is a two element array consisting of two integer constants. the var is marked 'preserve' (because it is read by the OBJC runtime, but not referenced from the code). we get one instance of the var per input object file to LTO. we would like one instance in the output (assuming that the values are really identical). so, if we: mark the section as SECTION_MERGE mark the decl as TREE_READONLY would we reasonably expect lto to merge them? if that is not enough, what additional constraints could be specified?
[Bug c++/52212] friend declaration doesn't see previous friend of same function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52212 --- Comment #3 from Daniel Krügler 2012-02-12 15:02:22 UTC --- My quoted phrase doesn't actually say that (nominated refers to the befriended name). But 11 p4 can be applied here: "Access control is applied uniformly to all names, whether the names are referred to from declarations or expressions."
[Bug c++/52212] friend declaration doesn't see previous friend of same function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52212
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
--- Comment #4 from Jonathan Wakely 2012-02-12
15:04:41 UTC ---
http://open-std.org/JTC1/SC22/WG21/docs/cwg_closed.html#209
you can make it valid by making D a friend of E, so that it can access the name
E::F
class D {
class E{
class F{};
friend void foo1(D::E::F& q);
friend class D;
};
friend void foo1(D::E::F& q);
};
works with G++ and Comeau online and the online clang demo
[Bug c++/52212] friend declaration doesn't see previous friend of same function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52212 --- Comment #5 from Jonathan Wakely 2012-02-12 15:08:14 UTC --- (In reply to comment #0) > Note that the same function was earlier made a friend of class E, and so can > see F. If you leave out the second friending, you get: > foo.cc: In function âvoid foo1(D::E::F&)â: > foo.cc:2:8: error: âclass D::Eâ is private > foo.cc:9:21: error: within this context > which is correct; foo1 cannot see E without the second friend. But with both > friends foo1 should see everybody. Just to be clear, the problem is not that foo can't access the names, it's that the second declaration of foo appears in the scope of class D, and D cannot access the name D::E::F so you can't even declare foo there. Adding the extra friend decl allows foo to be declared there.
[Bug testsuite/50076] FAIL: c-c++-common/cxxbitfields-3.c scan-assembler movl.*, var on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50076 --- Comment #6 from Iain Sandoe 2012-02-12 15:20:50 UTC --- Author: iains Date: Sun Feb 12 15:20:46 2012 New Revision: 184140 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184140 Log: gcc/testsuite: PR testsuite/50076 * c-c++-common/cxxbitfields-3.c: Adjust scan assembler for nonpic cases. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/cxxbitfields-3.c
[Bug testsuite/50076] FAIL: c-c++-common/cxxbitfields-3.c scan-assembler movl.*, var on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50076 Iain Sandoe changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #7 from Iain Sandoe 2012-02-12 15:22:08 UTC --- sorry it took so long to apply the fix .. assuming this to be fixed now.
[Bug target/52205] SPARC Solaris 2.11 unwind through signal handler fails with -fnon-call-exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52205 --- Comment #5 from Eric Botcazou 2012-02-12 15:33:17 UTC --- Created attachment 26643 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26643 Tentative fix Would you mind giving it a try on the Solaris 11 machine? TIA.
[Bug fortran/50981] [4.4/4.5/4.6 Regression] Wrong-code for scalarizing ELEMENTAL call with absent OPTIONAL argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50981 --- Comment #37 from Mikael Morin 2012-02-12 15:46:18 UTC --- Author: mikael Date: Sun Feb 12 15:46:14 2012 New Revision: 184142 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184142 Log: gcc/fortran/ PR fortran/50981 * trans-stmt.c (gfc_get_proc_ifc_for_call): New function. (gfc_trans_call): Use gfc_get_proc_ifc_for_call. gcc/testsuite/ PR fortran/50981 * gfortran.dg/elemental_optional_args_5.f03: New test. Added: trunk/gcc/testsuite/gfortran.dg/elemental_optional_args_5.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-stmt.c trunk/gcc/testsuite/ChangeLog
[Bug boehm-gc/52217] [boehm-gc] revision 184100 causes segmentation fault in mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52217 Kai Tietz changed: What|Removed |Added CC||ktietz at gcc dot gnu.org --- Comment #1 from Kai Tietz 2012-02-12 16:10:19 UTC --- Sorry, to revert this patch is the wrong fix. The patch just corrects an old-standing issue, and shouldn't affect mingw.org compiled stuff at all, as _DLL isn't defined by this header-set. The only effective difference is for -w64, which is defining _DLL as msdn describes. So the issue here you noticed might be caused by static/shared instead.
[Bug go/52218] New: [4.7 Regression] libgo ftbfs on arm-linux-gnueabi (unknown case for SETCONTEXT_CLOBBERS_TLS)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52218 Bug #: 52218 Summary: [4.7 Regression] libgo ftbfs on arm-linux-gnueabi (unknown case for SETCONTEXT_CLOBBERS_TLS) Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go AssignedTo: i...@airs.com ReportedBy: d...@gcc.gnu.org built with 20120205, fails with 20120210: ../../../src/libgo/runtime/proc.c:105:4: error: #error unknown case for SETCONTEXT_CLOBBERS_TLS ../../../src/libgo/runtime/proc.c: In function 'runtime_gogo': ../../../src/libgo/runtime/proc.c:299:2: error: implicit declaration of function 'fixcontext' [-Werror=implicit-function-declaration] ../../../src/libgo/runtime/proc.c: In function 'runtime_schedinit': ../../../src/libgo/runtime/proc.c:366:2: error: implicit declaration of function 'initcontext' [-Werror=implicit-function-declaration] cc1: all warnings being treated as errors make[6]: *** [proc.lo] Error 1
[Bug ada/52219] New: [4.7 Regression] FAIL: cxg2001
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52219 Bug #: 52219 Summary: [4.7 Regression] FAIL: cxg2001 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: ebotca...@libertysurf.fr, ia...@gcc.gnu.org Host: x86_64-apple-darwin10 Target: x86_64-apple-darwin10 Build: x86_64-apple-darwin10 The test cxg2001 has started to fail between revisions 184022 (OK) and 184112 on x86_64-apple-darwin10, but not on powerpc-apple-darwin9.
[Bug c++/52212] friend declaration doesn't see previous friend of same function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52212 --- Comment #6 from Ivan Godard 2012-02-12 17:14:34 UTC --- I'll put in a report to clang. One of you guys is right- are you well enough connected to jointly figure out who it is?
[Bug ada/52219] [4.7 Regression] FAIL: cxg2001
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52219 --- Comment #1 from Iain Sandoe 2012-02-12 17:16:53 UTC --- OK on x86_64-darwin10 and i686-darwin9 @ 184085 ... ... test is running @184140 on i686-darwin9.
[Bug c++/52212] friend declaration doesn't see previous friend of same function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52212 --- Comment #7 from Daniel Krügler 2012-02-12 17:18:38 UTC --- I'd say that comment 3 and comment 5 are equivalent. Jonathan additionally provided a way to fix the code.
[Bug libitm/52220] New: FAIL: libitm.c++/eh-1.C execution test due to Xcode 4 weakref linker bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52220 Bug #: 52220 Summary: FAIL: libitm.c++/eh-1.C execution test due to Xcode 4 weakref linker bug Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libitm AssignedTo: unassig...@gcc.gnu.org ReportedBy: howa...@nitro.med.uc.edu The test suite failures at -m32/-m64 for... FAIL: libitm.c++/eh-1.C execution test are due to... radar Problem ID: 10466868, "-undefined dynamic_lookup linker bug as described in... http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00329.html when building gcc trunk against Xcode 4.0-4.2 under x86_64-apple-darwin10 or Xcode 4.0-4.2.1 under x86_64-apple-darwin11. This can be confirmed by building gcc trunk against Xcode 3.2.6, which doesn't have the weakref linker bug, on x86_64-apple-darwin10 and thus doesn't show the eh-1.C execution failure. This weakref linker bug has been fixed upstream but won't be deployed until Xcode > 4.3. Since it is unlikely such a weakref fix will back ported to the Xcode 4.x on Snow Leopard, a generic fix of avoiding the use of weakref in libitm is best.
[Bug libffi/52221] New: [libffi] r184021 needs to be fixed.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52221
Bug #: 52221
Summary: [libffi] r184021 needs to be fixed.
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libffi
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jojel...@gmail.com
Host: i686-pc-cygwin
Target: i686-pc-mingw32
Build: i686-pc-cygwin
tried libjava with r184135, but got SIGSEGV because of following.
in libffi/src/x86/ffi.c,
#define FFI_INIT_TRAMPOLINE_THISCALL(TRAMP,FUN,CTX,SIZE) \
{ unsigned char *__tramp = (unsigned char*)(TRAMP); \
unsigned int __fun = (unsigned int)(FUN); \
unsigned int __ctx = (unsigned int)(CTX); \
unsigned int __dis = __fun - (__ctx + 22); \
49
and fixing above didn't succeed ExtraClassLoader testcase
Starting program: /tmp/gcc/i686-pc-mingw32/libjava/testsuite/ExtraClassLoader
[New Thread 412.0xa24]
[New Thread 412.0x1398]
Program received signal SIGSEGV, Segmentation fault.
0x696c8140 in java::lang::Class* java::lang::Object::getClass() ()
from /cygdrive/d/cygwin/tmp/gcc/i686-pc-mingw32/libjava/.libs/libgcj-13.dll
(gdb) i r
eax0xe 0xe
ecx0x8df4458b 0x8df4458b
edx0x22f9c4 0x22f9c4
ebx0x1 0x1
esp0x22f9c4 0x22f9c4
ebp0x22f9c8 0x22f9c8
esi0xc01b24 0xc01b24
edi0xc01b3c 0xc01b3c
eip0x696c8140 0x696c8140
eflags 0x10202 [ IF RF ]
cs 0x1b 0x1b
ss 0x23 0x23
ds 0x23 0x23
es 0x23 0x23
fs 0x3b 0x3b
gs 0x0 0x0
(gdb) set height 1000
(gdb) bt
#0 0x696c8140 in java::lang::Class* java::lang::Object::getClass() ()
from /cygdrive/d/cygwin/tmp/gcc/i686-pc-mingw32/libjava/.libs/libgcj-13.dll
#1 0x69ce1735 in ffi_call_win32 () at ../.././libffi/src/x86/win32.S:464
#2 0x69ce1608 in ffi_raw_call (cif=0xc01b24,
fn=0x696c8140 ,
rvalue=0x22fbe8, fake_avalue=0x22fa54) at ../.././libffi/src/x86/ffi.c:832
#3 0x6969bd0e in _Jv_InterpMethod::run (retp=0x22fd50, args=0x22fd70,
meth=0xac9e10) at ../.././libjava/interpret-run.cc:611
#4 0x69ce1905 in ffi_closure_raw_SYSV () at ../.././libffi/src/x86/win32.S:749
#5 0x00fa0039 in ?? ()
#6 0x004087bf in ExtraClassLoader.main(java.lang.String[])void ()
at ExtraClassLoader.java:9
#7 0x696bd642 in gnu::java::lang::MainThread::call_main (this=0xc0ef60)
at ../.././libjava/gnu/java/lang/natMainThread.cc:54
#8 0x696fa4d6 in gnu.java.lang.MainThread.run()void (this=@c0ef60)
at /tmp/gcc/libjava/gnu/java/lang/MainThread.java:106
#9 0x696cc062 in _Jv_ThreadRun (thread=0xc0ef60)
at ../.././libjava/java/lang/natThread.cc:335
#10 0x69683f5d in _Jv_RunMain (vm_args=0x0, klass=klass@entry=0x40a160,
name=name@entry=0x0, argc=argc@entry=0x1, argv=argv@entry=0x3d8958,
is_jar=is_jar@entry=0x0) at ../.././libjava/prims.cc:1795
#11 0x69684156 in _Jv_RunMain (klass=klass@entry=0x40a160,
name=name@entry=0x0, argc=argc@entry=0x1, argv=argv@entry=0x3d8958,
is_jar=is_jar@entry=0x0) at ../.././libjava/prims.cc:1820
#12 0x696841bf in JvRunMain (klass=0x40a160, argc=0x1, argv=0x3d8958)
at ../.././libjava/prims.cc:1826
#13 0x00401402 in _fu0___Jv_Compiler_Properties () at /tmp/cckDh2w0.i:11
#14 0x004010fd in __mingw_CRTStartup () at ../../.././winsup/mingw/crt1.c:244
#15 0x0408 in ?? ()
#16 0x7ffd7000 in ?? ()
#17 0x in ?? ()
Warning: the current language does not match this frame.
(gdb)
it seems that thiscall trampoline works correctly.
0x00fa0022 in ?? ()
4: $ebx = 0x696c5603
3: $ecx = 0x696c5603
2: $eax = 0xfa0008
1: x/i $eip
=> 0xfa0022:call 0x69ce18be
(gdb)
0x69ce18be in ffi_closure_SYSV () at ../.././libffi/src/x86/win32.S:715
715 ret
4: $ebx = 0x696c5603
3: $ecx = 0x696c5603
2: $eax = 0xfa0008
1: x/i $eip
=> 0x69ce18be :
jbe0x69ce18c0
(gdb) si
ffi_closure_raw_SYSV () at ../.././libffi/src/x86/win32.S:734
734 pushl %ebp
4: $ebx = 0x696c5603
3: $ecx = 0x696c5603
2: $eax = 0xfa0008
1: x/i $eip
=> 0x69ce18c0 : push %ebp
(gdb) b ffi_call_win32
Breakpoint 4 at 0x69ce16e3: file ../.././libffi/src/x86/win32.S, line 433.
(gdb) c
Continuing.
Breakpoint 4, ffi_call_win32 () at ../.././libffi/src/x86/win32.S:433
433 movl 20(%ebp),%ecx
4: $ebx = 0x1
3: $ecx = 0xe
2: $eax = 0x22fa0c
1: x/i $eip
=> 0x69ce16e3 : mov0x14(%ebp),%ecx
(gdb) bt
#0 ffi_call_win32 () at ../.././libffi/src/x86/win32.S:433
#1 0x69ce15e8 in ffi_raw_call (cif=0xc01bec, fn=
0x696d4940 , rvalue=0x22fbf0,
fake_avalue=0x22fa58) at ../.././libffi/src/x86/ffi.c:827
#2 0x6969bd0e in _Jv_InterpMethod::run (retp=0x22fd58, args=0x22fd
[Bug c++/52212] friend declaration doesn't see previous friend of same function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52212 --- Comment #8 from Jonathan Wakely 2012-02-12 17:47:47 UTC --- (In reply to comment #7) > I'd say that comment 3 and comment 5 are equivalent. Agreed.
[Bug libffi/52221] [libffi] r184021 needs to be fixed.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52221
Kai Tietz changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-02-12
CC||ktietz at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #1 from Kai Tietz 2012-02-12 17:58:27
UTC ---
Yes, I missed to adjust displacement. Following hunk
@@ -614,7 +614,7 @@
{ unsigned char *__tramp = (unsigned char*)(TRAMP); \
unsigned int __fun = (unsigned int)(FUN); \
unsigned int __ctx = (unsigned int)(CTX); \
- unsigned int __dis = __fun - (__ctx + 22); \
+ unsigned int __dis = __fun - (__ctx + 49); \
unsigned short __size = (unsigned short)(SIZE); \
*(unsigned int *) &__tramp[0] = 0x8324048b; /* mov (%esp), %eax */ \
*(unsigned int *) &__tramp[4] = 0x4c890cec; /* sub $12, %esp */ \
fixes it.
[Bug go/52218] [4.7 Regression] libgo ftbfs on arm-linux-gnueabi (unknown case for SETCONTEXT_CLOBBERS_TLS)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52218 --- Comment #1 from Ian Lance Taylor 2012-02-12 19:34:43 UTC --- Please look at the test case for SETCONTEXT_CLOBBERS_TLS in libgo/configure.ac and figure out why it fails on arm-linux-gnueabi. That test case should not fail on any GNU/Linux system, so I am surprised that SETCONTEXT_CLOBBERS_TLS is being defined. It may simply be some oversight in the test case.
[Bug target/52205] SPARC Solaris 2.11 unwind through signal handler fails with -fnon-call-exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52205 --- Comment #6 from Ian Lance Taylor 2012-02-12 19:52:02 UTC --- The patch fixes the test case and also passes some relevant Go tests. Rainer, if OK, I'd like to leave it to you to comment on the patch and do a full testsuite run.
[Bug c++/52126] [4.7 Regression] compilation error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52126 fabien at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |fabien at gcc dot gnu.org |gnu.org |
[Bug ada/52219] [4.7 Regression] FAIL: cxg2001
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52219 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-02-12 CC||ebotcazou at gcc dot ||gnu.org Ever Confirmed|0 |1 --- Comment #2 from Eric Botcazou 2012-02-12 20:17:54 UTC --- x86-64/Linux is still clean (as of revision 184143). What's in the log file?
[Bug target/52205] SPARC Solaris 2.11 unwind through signal handler fails with -fnon-call-exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52205 --- Comment #7 from Eric Botcazou 2012-02-12 20:24:56 UTC --- > The patch fixes the test case and also passes some relevant Go tests. Great. For the records, it was also tested on 5 different versions of Solaris 8, 9 and 10, covering all the cases in the code, both 32-bit and 64-bit.
[Bug middle-end/52214] [4.7 Regression] FAIL: g++.dg/tree-ssa/pr44706.C -std=gnu++* scan-tree-dump-not fnsplit "Splitting function"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52214 Hans-Peter Nilsson changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-02-12 CC||hp at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Hans-Peter Nilsson 2012-02-12 20:34:05 UTC --- Same for cris-elf appearing in the range 184085:184095. Probably everywhere except the system type Honza used to test.
[Bug c++/52215] __atomic_compare_exchange_n for enumeration type changes signature with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52215 Hans-Peter Nilsson changed: What|Removed |Added CC||hp at gcc dot gnu.org --- Comment #4 from Hans-Peter Nilsson 2012-02-12 20:48:25 UTC --- Presumably universal for ilp32 machines, at least for cris-elf too.
[Bug ada/52219] [4.7 Regression] FAIL: cxg2001
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52219 --- Comment #3 from Iain Sandoe 2012-02-12 21:05:11 UTC --- acats & gnat is clean on x86_64-darwin10 @184143 (and, I think, 184127). perhaps a temporary glitch?
[Bug ada/52219] [4.7 Regression] FAIL: cxg2001
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52219 --- Comment #4 from Dominique d'Humieres 2012-02-12 21:16:10 UTC --- > What's in the log file? splitting /opt/gcc/build_w/gcc/testsuite/ada/acats/tests/cxg/cxg2001.a into: cxg2001.adb BUILD cxg2001.adb gnatmake --GCC="/opt/gcc/build_w/gcc/xgcc -B/opt/gcc/build_w/gcc/" -gnatws -O2 -I/opt/gcc/build_w/gcc/testsuite/ada/acats/support cxg2001.adb -largs --GCC="/opt/gcc/build_w/gcc/xgcc -B/opt/gcc/build_w/gcc/" /opt/gcc/build_w/gcc/xgcc -c -B/opt/gcc/build_w/gcc/ -gnatws -O2 -I/opt/gcc/build_w/gcc/testsuite/ada/acats/support cxg2001.adb gnatbind -I/opt/gcc/build_w/gcc/testsuite/ada/acats/support -x cxg2001.ali gnatlink cxg2001.ali -O2 --GCC=/opt/gcc/build_w/gcc/xgcc -B/opt/gcc/build_w/gcc/ RUN cxg2001 ^M FAIL: cxg2001
[Bug ada/52219] [4.7 Regression] FAIL: cxg2001
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52219 --- Comment #5 from Dominique d'Humieres 2012-02-12 21:49:46 UTC --- > acats & gnat is clean on x86_64-darwin10 @184143 (and, I think, 184127). > perhaps a temporary glitch? Apparently!-(the tests pass without failure @184143 when run with check-ada, full test for tonight). Bugs that pops up and disappears are quite unpleasant.
[Bug tree-optimization/14792] ((int)b & 1) != 0 is not folded to b & 1 != 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14792 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #11 from Andrew Pinski 2012-02-12 21:59:23 UTC --- Actually just closing this as fixed.
[Bug rtl-optimization/2962] inefficient code with and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2962 --- Comment #13 from owner at bugs dot debian.org 2012-02-12 22:09:22 UTC --- Thank you for the additional information you have supplied regarding this Bug report. This is an automatically generated reply to let you know your message has been received. Your message has not been forwarded to the package maintainers or other interested parties; you should ensure that the developers are aware of the problem you have entered into the system - preferably quoting the Bug reference number, #95318. If you wish to submit further information on this problem, please send it to 95318-qu...@bugs.debian.org. Please do not send mail to ow...@bugs.debian.org unless you wish to report a problem with the Bug-tracking system.
[Bug rtl-optimization/2962] inefficient code with and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2962 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #14 from Andrew Pinski 2012-02-12 22:20:27 UTC --- Fixed on the trunk.
[Bug rtl-optimization/2962] inefficient code with and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2962 --- Comment #15 from owner at bugs dot debian.org 2012-02-12 22:24:21 UTC --- Thank you for the additional information you have supplied regarding this Bug report. This is an automatically generated reply to let you know your message has been received. Your message has not been forwarded to the package maintainers or other interested parties; you should ensure that the developers are aware of the problem you have entered into the system - preferably quoting the Bug reference number, #95318. If you wish to submit further information on this problem, please send it to 95318-qu...@bugs.debian.org. Please do not send mail to ow...@bugs.debian.org unless you wish to report a problem with the Bug-tracking system.
[Bug middle-end/31531] A microoptimization of isnegative of signed integer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31531
--- Comment #9 from Andrew Pinski 2012-02-12
22:58:41 UTC ---
(In reply to comment #8)
> forwprop already handles:
> int f(int a)
> {
> int b = ~a;
> return b<0;
> }
>
> It just needs to handle:
> int f(unsigned a)
> {
> int b = ~a;
> return b<0;
> }
forward_propagate_into_comparison only handles combing of two SSA_NAMEs, it
could handle dealing with a conversion also.
[Bug testsuite/50076] FAIL: c-c++-common/cxxbitfields-3.c scan-assembler movl.*, var on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50076 Jack Howarth changed: What|Removed |Added CC||howarth at nitro dot ||med.uc.edu --- Comment #8 from Jack Howarth 2012-02-12 23:02:59 UTC --- I can confirm that r184140 fixes the c-c++-common/cxxbitfields-3.c failures on x86_64-apple-darwin11.
[Bug ada/52120] [Ada] Compiler assertion in iterator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52120 nicolas.boulenguez at free dot fr changed: What|Removed |Added CC||nicolas.boulenguez at free ||dot fr --- Comment #1 from nicolas.boulenguez at free dot fr 2012-02-12 23:11:32 UTC --- I had the same arch/gnat/cargs/failure with a shorter example. with Ada.Containers.Vectors; procedure Proc is package Vect is new Ada.Containers.Vectors (Positive, Integer); type Reco is record V : Vect.Vector; end record; R : Reco; begin for E of R.V loop null; end loop; end Proc;
[Bug ada/52222] New: 4.6.2 (x86_64-pc-linux-gnu) Assert_Failure sinfo.adb:2947
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5 Bug #: 5 Summary: 4.6.2 (x86_64-pc-linux-gnu) Assert_Failure sinfo.adb:2947 Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassig...@gcc.gnu.org ReportedBy: nicolas.bouleng...@free.fr Toggled with gnatmake bug.adb (-gnat2012 does not change much). procedure Bug is B : Boolean; Suffix : String := (case B is when False => Boolean'Image (B), when True => ""); begin null; end Bug;
[Bug libffi/52223] New: [4.5,4.6,4.7 regression] libffi's man page install breaks with multilibs and overridden mandir
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52223 Bug #: 52223 Summary: [4.5,4.6,4.7 regression] libffi's man page install breaks with multilibs and overridden mandir Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libffi AssignedTo: unassig...@gcc.gnu.org ReportedBy: mi...@it.uu.se libffi installs three man pages during 'make install'. If a) the target has multilibs enabled, and b) the configure-time --mandir= is overridden by make install with mandir=, then libffi's man page install step in its multilib subdirs will ignore the overridden mandir and use the configure-time mandir instead, which may clobber an unexpected destination, or may cause the entire install to fail if that destination isn't currently writable by the user. The problem reproduces easily on x86_64-linux: /path/to/gcc-4.7/configure --prefix=/usr --mandir=/usr/share/man --enable-languages=c,c++,java --enable-multilib make # the following must be done as a regular user with no write access to # /usr/share/man make prefix=/tmp/buildroot/usr mandir=/tmp/buildroot/usr/share/man install ... Making install in man make[5]: Entering directory `/tmp/objdir/x86_64-unknown-linux-gnu/32/libffi/man' make[6]: Entering directory `/tmp/objdir/x86_64-unknown-linux-gnu/32/libffi/man' make[6]: Nothing to be done for `install-exec-am'. test -z "/usr/share/man/man3" || /bin/mkdir -p "/usr/share/man/man3" /usr/bin/install -c -m 644 /tmp/gcc-4.7-20120211/libffi/man/ffi.3 /tmp/gcc-4.7-20120211/libffi/man/ffi_call.3 /tmp/gcc-4.7-20120211/libffi/man/ffi_prep_cif.3 '/usr/share/man/man3' /usr/bin/install: cannot create regular file `/usr/share/man/man3/ffi.3': Permission denied /usr/bin/install: cannot create regular file `/usr/share/man/man3/ffi_call.3': Permission denied /usr/bin/install: cannot create regular file `/usr/share/man/man3/ffi_prep_cif.3': Permission denied make[6]: *** [install-man3] Error 1 make[6]: Leaving directory `/tmp/objdir/x86_64-unknown-linux-gnu/32/libffi/man' make[5]: *** [install-am] Error 2 make[5]: Leaving directory `/tmp/objdir/x86_64-unknown-linux-gnu/32/libffi/man' make[4]: *** [install-recursive] Error 1 make[4]: Leaving directory `/tmp/objdir/x86_64-unknown-linux-gnu/32/libffi' make[3]: *** [multi-do] Error 1 make[3]: Leaving directory `/tmp/objdir/x86_64-unknown-linux-gnu/libffi' make[2]: *** [install-multi] Error 2 make[2]: Leaving directory `/tmp/objdir/x86_64-unknown-linux-gnu/libffi' make[1]: *** [install-target-libffi] Error 2 make[1]: Leaving directory `/tmp/objdir' make: *** [install] Error 2 If multilibs are disabled then the man-page install step does use the overridden mandir=, but that clearly isn't a solution when multilibs are essential. I currently work around it by patching libffi's makefiles to delete "man" from "SUBDIRS". The problem is present in 4.5, 4.6, and 4.7, for (at least) x86_64-linux and m68k-linux. 4.4 did not have those man pages or this problem. The build procedure (configure with --prefix= and --mandir= pointing to system directories, but make install with prefix= and mandir= pointing to a local staging area) is taken verbatim from Fedora's gcc src rpm, so I'm assuming it's something that should work.
[Bug c++/52224] New: [C++0x] Generic operator gets pulled into compile-time expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52224
Bug #: 52224
Summary: [C++0x] Generic operator gets pulled into compile-time
expression
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: solo...@mail.com
Created attachment 26644
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26644
Code reproducing bug
Hi,
I have a piece of code that crashes gcc 4.5.2 and runs out of template
instantiation depth in 4.6.1, while I believe it should be well formed. The
command line I used for both compilers is: g++ -std=c++0x gcc_bug_mini.cpp
#include
#include
// I can have multiple my_... classes,
template struct my_class {};
// Which is why for convenience I introduce this predicate
template struct is_mine{ enum { value = false };
};
template struct is_mine> { enum { value = true }; };
// Note the use of || here, use of + would make things compile
template
struct either_is_mine
{ enum { value = is_mine::value || is_mine::value }; };
// Generic || that should only be used when one of arguments is my_...
template
inline auto operator||(E1&& e1, E2&& e2) throw() -> typename
std::enable_if::value, int>::type;
template
auto test(E1&& e1, E2&& e2) -> typename
std::enable_if::value, int>::type;
int main()
{
test(3,12);
}
The problem is in || in the definition of either_is_mine: for some reason the
generic operator enabled only when one of the arguments is from my_... set is
considered as a possible overload (note that there is no constexpr on generic
operator, just inline).
GCC in both cases is running under MinGW on Windows 7 laptop.
Thanks,
Yuriy
[Bug middle-end/31531] A microoptimization of isnegative of signed integer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31531 --- Comment #10 from Andrew Pinski 2012-02-13 00:44:11 UTC --- I have a patch which adds this optimization to fold. And a partial patch which adds some of it to forwprop but that fails because we have to create a temp variable.
[Bug c++/44783] implement -ftemplate-backtrace-limit=
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44783 Gabriel Redner changed: What|Removed |Added CC||gredner at gmail dot com --- Comment #4 from Gabriel Redner 2012-02-13 01:06:56 UTC --- Is there any progress on this issue? This bug is a major impediment when debugging template-heavy code.
[Bug middle-end/52214] [4.7 Regression] FAIL: g++.dg/tree-ssa/pr44706.C -std=gnu++* scan-tree-dump-not fnsplit "Splitting function"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52214 Jan Hubicka changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |hubicka at gcc dot gnu.org |gnu.org | --- Comment #2 from Jan Hubicka 2012-02-13 02:12:45 UTC --- mine.
[Bug middle-end/31531] A microoptimization of isnegative of signed integer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31531 --- Comment #11 from Andrew Pinski 2012-02-13 06:30:29 UTC --- I have a full patch now which also handles PR 14792 once that folding is included in fold.
[Bug tree-optimization/14792] ((int)b & 1) != 0 is not folded to b & 1 != 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14792 Andrew Pinski changed: What|Removed |Added Status|RESOLVED|ASSIGNED Depends on||31531 Resolution|FIXED | --- Comment #12 from Andrew Pinski 2012-02-13 06:32:37 UTC --- (In reply to comment #11) > Actually just closing this as fixed. Actually reopen for now, I have a partly better patch where we don't depend on forwprop folding (int)b & 1 into (int)(b&1).
[Bug rtl-optimization/2962] inefficient code with and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2962 --- Comment #16 from owner at bugs dot debian.org 2012-02-13 06:36:24 UTC --- Thank you for the additional information you have supplied regarding this Bug report. This is an automatically generated reply to let you know your message has been received. Your message has not been forwarded to the package maintainers or other interested parties; you should ensure that the developers are aware of the problem you have entered into the system - preferably quoting the Bug reference number, #95318. If you wish to submit further information on this problem, please send it to 95318-qu...@bugs.debian.org. Please do not send mail to ow...@bugs.debian.org unless you wish to report a problem with the Bug-tracking system.
[Bug tree-optimization/52210] vect_model_simple_cost: reading uninitialised memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52210 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-02-13 CC||jakub at gcc dot gnu.org AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.7.0 Ever Confirmed|0 |1
[Bug middle-end/31531] A microoptimization of isnegative of signed integer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31531 --- Comment #12 from Andrew Pinski 2012-02-13 07:46:45 UTC --- Created attachment 26645 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26645 Patch which fixes the problem (well the fold-const.c is really only needed for the original testcase) ChangeLog: * fold-const.c (fold_comparison): Handle ((CAST)~X). * tree-ssa-forwprop.c (combine_cond_expr_cond): Swap operands so that fold_binary_loc would not return a non-folded tree. Don't call canonicalize_cond_expr_cond. (forward_propagate_into_comparison_1): Also combine casts into the comparisons. (expand_possible_comparison): New function. (forward_propagate_into_comparison): Call expand_possible_comparison. (forward_propagate_into_gimple_cond): Take also a gsi. Call expand_possible_comparison. (forward_propagate_into_cond): Call expand_possible_comparison. (ssa_forward_propagate_and_combine): Update call to forward_propagate_into_gimple_cond.
